IRC channel logs
2015-03-01.log
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>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" <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. <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. <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 <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 :) <iyzsong>davexunit: thanks for the xfce notify, patches just sent for reviews ;-) <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>building the apache module for php is frustrating. I just can't quite get it to build. <davexunit>trying to build httpd with different configure flags has so far not lead to any success. <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>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. <civodul>bugs become clearer through fresh eyes *civodul understands the encoding issue <sirgazil>Anyone here using duckduckgo.com 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? <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>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. <sirgazil>mark_weaver: It's odd. I enabled LibreJS again, and DDG works. <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. <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. <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>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>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. <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>it shouldn't even have any way of knowing whether it is being built as a dependency or not. <taylanub>Debian patches libid3tag and libmad to include .pc files. Perhaps we should do the same. <davexunit>taylanub: is there a configure flag we need to set or something? <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 <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: we may have to add support for an environment variable to the code. <mark_weaver>another option would be to make a wrapper that inserts the command-line argument before the user-provided arguments <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. <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 <mark_weaver>well, you could just try experimenting and see what happens <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 <mark_weaver>yeah, if it were me I'd probably try to patch the source. <toothbrush0>mark_weaver: sort of -- it's mainly that i'm not sure what the conventions etc are <toothbrush0>and if so, which value would you hard-code? ~/.guix-profile/lib/.. ? <mark_weaver>I wouldn't hard-code anything. I'd invent an environment variable for it, and use that. <toothbrush0>I see that their Makefile does support setting a default via a -D flag <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. <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. <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'. <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>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? <rekado>found a fix for the solfege issue. <rekado>it's now failing in just the same manner as it does on Fedora. (I think that's good.) <toothbrush0>phew, looks like Zathura is finally packaged. I guess nobody else here uses that? :p <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