<rekado>running the builder manually (after setting “out” to some directory) works fine.
<efraim>I didn't realize slim recognized kodi as a WM, makes it easier with my kids
<rekado>reverting c4fb2b9f4e9ca1c5b586090b765b51b2a5042eff removes the problem.
<runejuhl>Hi all. I'm playing around with guix on RHEL6 with a 2.6.32 kernel. I can see that others have had the same problems with glibc and "kernel too old" that I have right now, but I'm a bit uncertain about what I can do *right now* to make it work? The mailing list talks about grafts -- is there something I can apply manually, should I wait a bit for a newer release, or..?
<rekado>runejuhl: it should have been fixed about an hour ago, but then we discovered that this introduces another error.
<rekado>I also have RHEL6 here (on a cluster) and I’m trying to fix this asap.
<runejuhl>rekado: thank you for your work then -- I'll just wait a bit and try again later
<roelj>Has anyone experienced a hanging Guix after upgrading a profile? It grafts packages, and the displays "Uncaught exception:" four times, and gets stuck there. The load of the machine is 0.00, so I don't think it's doing anything anymore.
<efraim>civodul: did the crash come with a kernel backtrace?
<efraim>Actually I think mine used to come with a kernel dump, not backtrace
<civodul>it's an OOM, but i have enough problems on my plate, i'm happy to ignore this one :-)
<efraim>Mine seem to have stopped when I switched from xfce to enlightenment
<roelj>civodul: I have a profile with guix nss nss-certs glibc-utf8-locales and "guixr" (which is not in guix upstream). I simply tried upgrading that profile: guix package --upgrade -p /path/to/the/profile.
<roelj>civodul: So I'd guess “guix environment guix glibc-utf8-locales” would trigger the problm.
<castilma>hey, I forgot to add [PATCH] to the subject of a patch I sent to guix-patches. should I close the bug and resend it?
<roelj>civodul: I solved it on our cluster by reverting to 295fbbd75d753ffbb84fb78edd2d92c0275c170f.
<rekado>civodul: let me try to give you a recipe for reproducing this.
<rekado>it’s pretty fatal and appears in many places.
<rekado>when you “make clean-go” and then run “guix environment guix” – does that work for you?
<rekado>I have a user here who ran “guix pull” and it grafted *one* thing and then printed “Uncaught exception”.
<rekado>(and it doesn’t crash, it just sits there)
<rekado>looks like a simple reproducer is “guix pull”.
<rekado>civodul: where do you see the references to the original libc? I have the grafted libc-2.26.so open in hexl-mode and searched for /gnu – all I can find is references (some chunked, some not) to the grafted libc.
<civodul>rekado: yes, see the example in the message i just sent
<civodul>at the very least, this means we can't reliably graft glibc (and perhaps other packages)
<thorwil>could it be that elogind would take care of that?
<thorwil>in freedesktop.scm, (define-public weston ...) there's a (setenv "XDG_RUNTIME_DIR" (getcwd))
<efraim>building efl with ibus didn't change the language not changing on keybinding
<efraim>actually switching it on the map icon at the bottom didn't do anything either
<rekado>civodul: thanks again for all your help and your patience in figuring this out!
<rekado>it may not seem like this but I’m really happy to have been exposed to these tricky core packages; and although grafting the glibc didn’t work out as planned, I’m glad that it had at least a positive side-effect of confirming a bug.
<thorwil>reading about the service extension business, i can't make the connection to wanting to set one environment variable and creating one directory with specific chmod :/
<mbakke> guix offload: error: build failed: hash of path `/gnu/store/48jik08njmdaaixbry4rz3rrh74acq39-automa ke-1.16.tar.xz' has changed from `c9ef7cfba74524fb1be00d7ed59af928ce9c59915e9d78a3574e7c98b0e4c4f4' to `77ac62e2629d8e45f624589c0c8bf99e24b3a722349bf1e79bc186008534e246'!
<rekado>mbakke: that’s not an upstream problem but an offloading/store corruption error, isn’t it?