<mbuf>mark_weaver, can you please point me to any documentation on packaging Free Software for guix?
<mark_weaver>such a list would not be specific to Guix though. such a list would be applicable to all FSDG-compliant distros. the fact that the FSF doesn't already maintain such a list makes me suspect that they consider it counterproductive.
<abnegate>and i guess i was wrong about uninstalling the original urxvt that i got through debian's own package manager
<abnegate>it's still there, and i can run both the original urxvt and the guix urxvt, and only the guix one exhibits this problem
<mark_weaver>presumably the debian glibc is built to look for locales in /usr/share/locale if LOCPATH is not set. Guix does not look there.
<abnegate>and i think it's the guix perl that's the problem
<abnegate>when i run the guix perl from within the /gnu/store, i see the issue
<abnegate>both weechat and urxvt load perl, i think
<mark_weaver>this is a shot in the dark, but you know that environment variables are passed from parent to child processes, right? so if you export a variable in one shell that has no effect on other sibling shells.
<mark_weaver>ideally, you shouldn't have to set LD_LIBRARY_PATH to run qjackctl
<mark_weaver>did you install 'gcc-toolchain', or did you install things like 'glibc', 'binutils', and 'gcc' separately?
<mark_weaver>the reason I ask is that we have a package called 'ld-wrapper' which arranges to embed rpaths into programs and libraries that are linked, so that they can find their shared libraries when run without relying on LD_LIBRARY_PATH
<mark_weaver>and 'gcc-toolchain' includes 'ld-wrapper' and takes care that it takes precedence over the 'ld' that's in 'binutils'.
<mark_weaver>you should consider just adding qjackctl as a guix package.
<abnegate>hmm.. i think i just lost my network connection
<abnegate>i was wondering why it got so quiet in here all of a sudden.. :)
<abnegate>mark_weaver: could you repeat your last response, please? i'm afraid i may have missed it
<mark_weaver>when building package X, you need to ensure that package X's build system does auto-configure a mixture of code from Debian and Guix. you need to ensure that only components from one system get used.
<abnegate>and when i tried to install gcc, i ran out of memory and swap
<abnegate>btw, regarding what you said about "you should consider just adding qjackctl as a guix package"
<abnegate>what i'd said when my network died, before i realized it was: "so i guess when i build qjackctl i have to make sure it only links in guix libraries" "and probably the easiest way of ensuring that is by just writing my own guix recipe for qjackctl"
<abnegate>so yeah, i figured that'd probably be the case
<abnegate>i think i might need some more simple examples of guix recipes
<mark_weaver>it is problematic to build software in an environment that contains a mixture of Debian and Guix software.
<mark_weaver>it is okay to use such a hybrid for non-development purposes
<mark_weaver>but if you want to compile something based on Guix libraries, then you must ensure that nothing from Debian is picked up
<mark_weaver>the nice thing about the git repo approach is that you can also make arbitrary changes to any part of guix, and yet easily rebase your locale changes onto our upstream (or merge our upstream into your branch, if you prefer)
<abnegate>i think i'm going to have to read over that pdf and the guix docs again
<abnegate>and then read over your suggestions once more
<mark_weaver>so it would be easy to apply a suboptimal fix, namely to pass LDFLAGS=-Wl,-rpath=/gnu/store/.../lib to 'configure', but really we need to investigate what went wrong to make a *proper* fix.
<mark_weaver>a related question is: how is it that the package author didn't notice these problems?
<mark_weaver>maybe they did their testing in an environment with LD_LIBRARY_PATH=$HOME/.guix-profile/lib
<rekado>I'm the author of jack2. libjackserver.so.0 is installed to .guix-profile/lib, but jackdbus does not contain the rpath to this library. At that time I must have had some environment variable set. I'll take a look at how to fix this.
<Sleep_Walker>patching service code is tricky - I brought my dmd to crash and kernel to panic :(
<rekado_>is it normal for the ATLAS tuning process to take several hours...?
<rekado_>I'm building ATLAS on a virtual machine with lots of memory and 8 CPUs.
<bavier>rekado_: yes, atlas can take quite a while
<bavier>I would personally prefer to use something like openblas or blis instead.
<rekado_>in principle it should be possible to swap out blas libraries. I would like not to use ATLAS in this shared environment at all, because the tuning is rather pointless when the library will be used on cluster nodes and workstations alike.
<Sleep_Walker>I tried methods I usually use - interpret the piece of code, add some debug printing
<Sleep_Walker>I tried even simple things like adding (when (file-exists? ...) (format #t ...))
<Sleep_Walker>when the file existed, it ended somehow leading to kernel panic thanks to dead init
<taylanub>mark_weaver: I couldn't find out much more than https://bugreports.qt.io/browse/QTBUG-45205 specifically I can't figure out how the presence of libxfixes/libxshmfence is even relevant. best I can think of is patching this in some hacky but straightforward way like adding an "#ifndef __glext_h_" around the two problematic typedefs.
<taylanub>*than what I describe in that bug report
<civodul>Sleep_Walker: ideally this is not how we'd address the stale PID file issue