IRC channel logs


back to list of logs

<mark_weaver>civodul: to be more concrete: the copyright symbol (©) is represented as 0xC2 0xA9 in UTF-8. So when that's read using read-char, it gets put in the narrow string buffer as 0xA9 which is its ISO-8859-1 representation.
<mark_weaver>when regexp-exec tries to convert this narrow string to a "locale string", it interprets the bare 0xA9 as UTF-8. but 0xA9 is in the range of bytes that's only allowed as a non-initial byte of a multi-byte sequence. so it will raise an error.
<mark_weaver>I guess that what was happening before is that all non-ASCII Latin-1 characters were getting turned into ?
<mark_weaver>well, most of them anyway.
<mark_weaver>some groups of latin-1 characters will form valid UTF-8 multi-byte sequences.
<civodul>mark_weaver: this explanation makes a lot of sense, yes
<civodul>before we probably ended up with question marks, indeed
<civodul>still, i fail to understand why it doesn't happen when i try it "manually"
<mark_weaver>yeah, that's mysterious
<sirgazil>I just installed emacs-no-x-toolkit and it opens in a window when I run it, is this supposed to happen?
<sirgazil>By the way, a million thanks to the persons who packaged Emacs :)
<civodul>sirgazil: yes, it's just a plain X11 Emacs
<mark_weaver>sirgazil: -no-x-toolkit doesn't mean -no-x. it just means no GTK.
<sirgazil>Ah ok.
<civodul>we should add -no-x
<mark_weaver>also, all of the things that use emacs as an input should use the most minimal emacs we have.
<mark_weaver>while bootstrapping armhf, I started by wanting just emacs-no-x-toolkit, to get there faster.
<mark_weaver>and then noticed that all of the other emacs packages used the full 'emacs' as input.
<civodul>yeah, agreed
<sirgazil>Curious thing: IceCat's logo is shown correctly in GNOME Shell, but Inkscape's is not.
<mark_weaver>sirgazil: the same is true in XFCE on GuixSD itself.
<mark_weaver>I started a thread on guix-devel to discuss how best to fix it, but then got distracted by other things. I need to pick that back up.
*civodul pushes the kludge & goes to bed
<civodul>good night/day!
<sirgazil>mark_weaver: sometimes I don't understand how you all manage to do all the work you do.
<sirgazil>Thanks for all the work you do, by the way :)
<mark_weaver>you're welcome! thanks for the kind words :)
<iyzsong>davexunit: thanks for the xfce notify, patches just sent for reviews ;-)
<davexunit>iyzsong: thanks for all of the patches!
<davexunit>I haven't yet tried xfce on guix. how is it?
<davexunit>bleh, sorry for the noise. I sent emails for all the patches, and after I did that I received emails from you and Andreas
<davexunit>where you said you already pushed them.
<davexunit>building the apache module for php is frustrating. I just can't quite get it to build.
<davexunit>seems like a problem with httpd's apxs tool
<davexunit>trying to build httpd with different configure flags has so far not lead to any success.
<davexunit>looks like I got it
<davexunit>too bad all the tests fail, though.
<rekado>is there any pattern to the failures?
<davexunit>can't tell yet, it just tells me that they fail
<davexunit>yet the return code is 0 so the build is successful...
<davexunit>I want to add something to guix to make it easy to apply an arbitrary build phase outside of the build container
<davexunit>in a guix environment, for example.
<davexunit>would make troubleshooting this easier
<civodul>Hello Guix!
<davexunit>hey civodul
<davexunit>hmmm... stack overflow when converting a bag to a derivation
<davexunit>adding openldap as an input to apr-util causes it.
<davexunit>I guess it's a circular dependency, but I can't find it...
<sirgazil>Packagers of GIMP and mercurial, thanks a million. I'm using that software now :)
<civodul>davexunit: could you paste the backtrace?
<rekado>"GC Warning: Out of Memory! Heap size: 6 MiB. Returning NULL!"
<rekado>getting this while attempting to install texlive.
<rekado>I certainly have memory left.
<civodul>rekado: is it while downloading it?
<civodul>bugs become clearer through fresh eyes
*civodul understands the encoding issue
<rekado>yes, while downloading.
<rekado>already submitted a bug report.
<sirgazil>Anyone here using on IceCat? When I perform a search, the page keeps loading and never shows any results. Google works fine.
<rekado>sirgazil: I do. Is librejs enabled?
<davexunit>sirgazil: yeah, if librejs is enabled, it won't load
<sirgazil>rekado: no, I disabled it because many website don't work with it.
<rekado>oh. ddg works for me whti disabled librejs. I didn't have to do anything else to make it work.
<rekado>I'm not making any progress with solfege.
<rekado>I have pygtk's site-packages path in my PYTHONPATH, yet it still complains about "No module named gtk".
<rekado>only when I add the site-packages/gtk-2.0 path I can get past this error.
<rekado>shouldn't the pygtk.pth file take care of this?
<civodul>davexunit: hmm, no so informative; and the patch?
<civodul>rekado: not sure exactly
<rekado>I thought the pth files are there to add subdirs to the search path.
<mark_weaver>sirgazil: I've been using duckduckgo with Icecat in LibreJS enabled and even through Tor, and it works for me. However, I'm finding it to be quite slow right now.
<mark_weaver>I'm not sure if the slowness is from Tor or DDG.
<mark_weaver>s/with Icecat in/in Icecat with/
<mark_weaver>davexunit: I've been using XFCE in GuixSD for several weeks now. I like it, although I had to change the default panel configuration to get rid of that horrible big one on the bottom.
<mark_weaver>I just have one thin panel at the top
<davexunit>mark_weaver: cool. I should try it out.
<sirgazil>mark_weaver: It's odd. I enabled LibreJS again, and DDG works.
<davexunit>if anyone would like to upvote, I submitted civodul's FOSDEM talk to hacker news:
<davexunit>I don't quite understand how HN works, but sometimes a small number of upvotes is all it takes to send something to the front page.
<rekado>davexunit: upvoted
*davexunit goes afk
<civodul>upvoted too
<civodul>i hope that talk is not too lame
<toothbrush0>Hello Guix!
<toothbrush0>What would you do if a build complains that /usr/bin/tput is unavailable? It seems to be something for terminal capabilities? <>
<sirgazil>civodul: I just pushed the slim and grub themes I forgot to push before (
<mark_weaver>toothbrush0: tput is part of the 'ncurses' package. you need to add 'ncurses' to either native-inputs or inputs (depending on whether it is used during the build or after installation, an important distinction when cross-compiling), and then you'll need to arrange for it to not look for it in /usr/bin
<mark_weaver>toothbrush0: is tput needed at run time or build time?
<mark_weaver>if "/usr/bin/tput" is hardcoded in the source, you'll probably need to patch it with 'substitute*'.
<mark_weaver>if it's only used at build-time, then you could just change it to "tput", since it will be found in PATH during the build if ncurses is in native-inputs.
<mark_weaver>if it's needed at run-time by the user, then "/usr/bin/tput" should be replaced with the absolute path "/gnu/store/.../bin/tput".
<toothbrush0>mark_weaver: ah, thanks for the info. It's only build-time, i believe.
<rekado>hmm, the guix-packaged solfege starts with the Fedora phython (with the Guix pygtk in the PYTHONPATH), but with the Guix python it won't work.
<rekado>the error with Guix python is "ImportError: could not import gio" (after explicitly adding site-packages/gtk-2.0 to the PYTHONPATH).
<mark_weaver>rekado: it might need to load an .so file as well. maybe run it under 'strace' to find out what it's looking for but failing to find?
<mark_weaver>if it's looking for a *.so, setting LTDL_LIBRARY_PATH to include the directory with the *.so might be the answer. it could be added with a wrapper.
<rekado>thanks for the clues
<mark_weaver>or better yet, if it's looking for a *.so, patching the relevant python code to use an absolute path to the *.so would be ideal. but that's probably more work, and it needn't be done now.
<rekado>the problem appears to be that the pth files are ignored.
<rekado>I have a PYTHONPATH containing all required site-packages directory (but not going any further to specifically mention subdirs).
<rekado>the libs for pygtk are located in the gtk-2.0 subdir.
<rekado>same goes for gio, which is in pygobject's site-packages/gtk-2.0 subdi.r
<rekado>python isn't looking at these subdirs, even though they are declared in the pth files that *are* in the PYTHONPATH.
*mark_weaver is mostly ignorant of python
<toothbrush0>Is there a "general" way of handling applications and plugins which are bundled/compiled separately? They're all rather interdependent: the application builds, but the plugin depends on the application and says it cannot be built as a dependency...
<mark_weaver>toothbrush0: what do you mean by "the plugin depends on the application and says it cannot be built as a dependency..." ?
<mark_weaver>normally the application is an input for the plugin
<mark_weaver>xfce4-battery-plugin is an example
<mark_weaver>typically there is an environment variable to tell the application where to look for plugins
<mark_weaver>and we declare search path specifications to handle setting those variables automatically during builds and to remind the user to set those variables.
<mark_weaver>typically such an environment variable would contain $HOME/.guix-profile/???/
<mark_weaver>all the plugin packages would install in <%output>/???/ and those will all be merged together into a single directory in the user's profile, which is then found via the environment variable.
<mark_weaver>toothbrush0: does that all make sense?
<toothbrush0>mark_weaver: right, i think so, thanks!
<mark_weaver>I suppose you could think of python libraries sort of like plugins, so for example look at the search-path-specification for PYTHONPATH in the python package.
<toothbrush0>to clarify what i meant, i'd figured out that indeed the application is an input to the plugin, but when trying to build the plugin, guix tries to build the application, which fails.
<davexunit>HN front page :)
<toothbrush0>mark_weaver: okay will bear it in mind :)
<davexunit>discussion not very good, though.
<mark_weaver>toothbrush0: well you need to get the application building first. then worry about the plugins :)
<toothbrush0>mark_weaver: the application builds, but only standalone. when it's built as a dependency, it doesn't :/
<mark_weaver>toothbrush0: that doesn't make any sense.
<toothbrush0>i agree.
<mark_weaver>each build happens in an isolated container.
<toothbrush0>will debug more, more info later.
<mark_weaver>it shouldn't even have any way of knowing whether it is being built as a dependency or not.
<toothbrush0>indeed, i would think so.
<toothbrush0>probably PEBKAC
<mark_weaver>heh :)
<toothbrush0>okay, got it building.
<toothbrush0>was indeed pebkac
<toothbrush0>now to figure out if the plugins work.
<taylanub>Debian patches libid3tag and libmad to include .pc files. Perhaps we should do the same.
<taylanub>(Audacity relies on it.)
<davexunit>taylanub: is there a configure flag we need to set or something?
<davexunit>that stuff is real easy to miss.
<Sleep_Walker>civodul`: I really verified that the shell substitution is needed workaround for build error
<Sleep_Walker>IOW unless we'll provide /bin/sh, this workaround is required
<civodul`>Sleep_Walker: hmm, ok, then you can keep it
<taylanub>davexunit: Debian just adds self-written .pc files. so I added them as patches too.
<taylanub>are .pc files patched automatically by the way? I grepped packages to see the customary way of patching the prefix= line in a .pc file but couldn't find anything
<Sleep_Walker>btw. I tried `guix lint' for the packages but it didn't warn about too long lines, comments with single collon, using capitalized punctuated sentences...
<civodul>Sleep_Walker: that's because it doesn't nitpick as much as i do ;-)
<civodul>Sleep_Walker: more seriously, it processes the package object, not the actual source code
<civodul>so it cannot see these things
<toothbrush0>So i have an application which only has two options for specifying plugin directory: command-line or hard-coded... It feels smelly to hard-code something like $HOME/.guix-profile/lib/.. as the plugin dir, but it's also rather uncool to force users to use a cmdline arg every time...
<toothbrush0>I've looked around in the code and it looks as if it doesn't support ENV variables.
<mark_weaver>toothbrush0: $HOME is also an environment variable
<mark_weaver>toothbrush0: we may have to add support for an environment variable to the code.
<toothbrush0>Hm, ok. That sounds involved.
<mark_weaver>I had to do that for XFCE to find its plugins
<toothbrush0>Did you get upstream to accept it?
<toothbrush0>Or i guess it's a local patch.
<mark_weaver>I haven't tried yet
<mark_weaver>another option would be to make a wrapper that inserts the command-line argument before the user-provided arguments
<toothbrush0>sounds easier
<mark_weaver>but we'd want to make sure that it's still possible for the user to override the one that gets auto-inserted.
<toothbrush0>Fair enough.
<mark_weaver>what happens if you pass the command argument twice? does the latter one take precedence?
<toothbrush0>I'll have to experiment, the code uses GOptionEntry for commandline parsing it seems
<toothbrush0>GLib/gstdio.h if i'm not mistaken
<mark_weaver>well, you could just try experimenting and see what happens
<toothbrush0>ok, will do that then.
<toothbrush0>know an examle of such a wrapper off the top of your head?
<mark_weaver>not a very close fit to this, but 'ccl' in lisp.scm writes a little shell script
<mark_weaver>usually we use a utility called 'wrap-program' in guix/build/utils.scm
<mark_weaver>but that just sets environment variables, it doesn't add command-line arguments.
<mark_weaver>you'll want to use 'rename-file' to rename program "foo" to something like ".foo-real"
<toothbrush0>mark_weaver: ok, the last instance of "-p" (that is, set plugin dir) takes precedence
<toothbrush0>first bit of good news today :p
<toothbrush0>feels very hacky though, such a wrapper
<mark_weaver>yeah, if it were me I'd probably try to patch the source.
<mark_weaver>are you uncomfortable with C ?
<toothbrush0>mark_weaver: sort of -- it's mainly that i'm not sure what the conventions etc are
<toothbrush0>but i can try my hand at it.
<toothbrush0>and if so, which value would you hard-code? ~/.guix-profile/lib/.. ?
<toothbrush0>or something more intelligent?
<mark_weaver>I wouldn't hard-code anything. I'd invent an environment variable for it, and use that.
<toothbrush0>Ah right.
<toothbrush0>I see that their Makefile does support setting a default via a -D flag
<mark_weaver>right, but that won't work for us.
<mark_weaver>because it can't accommodate any environment variable, not even $HOME as part of it.
<mark_weaver>you can look at gnu/packages/patches/xfce4-panel-plugins.patch for the modifications I made to xfce4-panel, but don't be scared off by it. xfce4-panel turned out to be quite a bit more complex than should be needed here, for various reasons.
<toothbrush0>okay. I will look. Thank you.
<mark_weaver>but for a Glib-based program, use 'g_getenv' to get the environment variable.
<mark_weaver>I had to concatenate strings and iterate over lists and things, which was a pain.
<mark_weaver>hopefully in your case you can simply use the result of 'g_getenv' in place of the constant string literal.
<toothbrush0>yeah it should be something like that i think
<mark_weaver>beware though that the result buffer of 'g_getenv' only lasts until the next call to 'g_getenv'.
<mark_weaver>you can use 'g_strdup' to make a freshly allocated copy of that string.
<mark_weaver>but if you do that, hopefully it is in code that is only run once, maybe when the program is first run.
<mark_weaver>or else you'll have to take care to free it with 'g_free'.
<toothbrush0>It's only run on startup, so i think i'm okay.
<toothbrush0>I'll verify that though.
<mark_weaver>I remember thinking, when making those changes to 'xfce4-panel', how glad I am to be working with garbage-collected languages now.
<toothbrush0>yeah i can imagine
<toothbrush0>mark_weaver: great, my modifications seem to work. Now to make Guix output a wrapper.
<toothbrush0>$deity, this is going to be the ugliest package ever!
<mark_weaver>toothbrush0: well, if you modify the C code, then I guess you won't need a wrapper, right?
<toothbrush0>Uh, it's late here :/
<toothbrush0>but indeed!
<mark_weaver>don't forget to add the patch to
<rekado>found a fix for the solfege issue.
<toothbrush0>mark_weaver: ah okay
<rekado>it's now failing in just the same manner as it does on Fedora. (I think that's good.)
<mark_weaver>iyzsong: we seem to have lost xfce4-terminal and xfce4-battery-plugin:
<mark_weaver>(and xfconf also failed on mips64el)
<mark_weaver>rekado: sounds like progress!
<toothbrush0>phew, looks like Zathura is finally packaged. I guess nobody else here uses that? :p
<davexunit>never heard of it :)
<davexunit>I'm currently trying to figure out why php's test suite fails in the build container
<toothbrush0>davexunit: Good luck! I just got my hands dirty with C, i'm glad i have no PHP to do on top of that :p
<davexunit>I ran it in a guix environment and it is working a lot better
<davexunit>so there's something about the isolation of the container that is breaking it