<rekado>looks like static-bash-for-glibc ignores the replacement field for some reason <rekado>I can build patched-static-bash-for-glibc just fine, but the build is not triggered when building static-bash-for-glibc. <efraim>Interesting thing I've found so far, when I was using xfce the kernel would panic while compiling unless I was in TTY1, haven't had to do that with enlightenment <efraim>After I reboot with EFL and ibus I think I'm going to submit my enlightenment service. It needs work but it's at a usable state <buenouanq>are we still having the dbus and service order problems? <buenouanq>I haven't had a machine to test it on in a while. <efraim>Not so useful, but I haven't been having troubles ***lanlink_ is now known as lanlink
<thorwil>hi! where do i find the definition of %desktop-services? <nckx>thorwil: gnu/services/desktop.scm:(define %desktop-services <OriansJ`>thorwil: grep -iR %desktop-services . is the pattern you may wish to leverage in the future to find definitions of such things <thorwil>ty! oh the things i know in principal, yet forget in the heat of the moment! <thorwil>if weston has elogind as build-time dependency, one might expect it being a runtime dependency, too, right? <efraim>Are you thinking of making a Weston desktop service? <thorwil>efraim: no, still struggling with getting weston to work. the plan was to get a minimal system with a floating-window wayland compositor, just to see if things work in general <thorwil>to then *maybe* write a scheme-and-wlroots compositor of my own. bbl <pmikkelsen>hi guix, with the latest version from git, there is an error about <pmikkelsen>alist-delete unbound variable in gnu/packages/base.scm <thomassgn>good noon guix! back after disk fail. Lucky I had an ssd here. :P <risciii>guix pull is giving 'Uncaught exception:' <risciii>I wanna contribute to Guix too, how do I get started? <risciii>I am reading Guile and guix manuals and reading through source <rekado>risciii: the best way to start is to get the Guix source code and to add a package definition. <rekado>civodul: I also get “Uncaught exception” now when building simple derivations. <rekado>e.g. guix build /gnu/store/dif77mrmwpd2vvk1zn83p1ldfq003hfr-module-import.drv <rekado>the log file only contains “Uncaught exception:” <rekado>building r-minimal worked fine, but some derivations throw “Uncaught exception” now. <rekado>I have the same problem on my laptop when doing “guix environment guix” – it fails after grafting some packages. <rekado>on the cluster it succeeded in building the derivation for java-testng, but then it moved on to building module-import.drv and failed with “Uncaught exception:”. <rekado>I’ll try to run the derivation manually. <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. <rekado>c4fb2b9f4e9ca1c5b586090b765b51b2a5042eff is the bad commit. <roelj>Oh. Is it related to the CentOS 6 breakage? <roelj>Right. Thanks for pointing out the commit. <rekado>c4fb2b9f4e9ca1c5b586090b765b51b2a5042eff was supposed to be the fix, but it breaks *some* derivations. <roelj>Is there a way around it other than reverting that commit? <rekado>I’m trying but it’s really tricky. <rekado>I think we may have to revert this. <roelj>Well, reverting works fine for me. But that probably doesn't fix your issue. <rekado>I don’t know why this happens and “Uncaught exception:” isn’t very useful. <civodul>so "make clean-go && make" triggers the build issue? <rekado>I get it when doing “guix environment guix”, for example. <rekado>but also for other build actions. <rekado>some derivations can be built just fine but then there are some that abort with “Uncaught exception”. <rekado>my naive guess is that this might be related to “package-with-bootstrap-guile” or “package-with-explicit-inputs”. <rekado>is “Uncaught exception” indicative of a derivation loop? ***tilpner_ is now known as tilpner
<civodul>roelj: i'm at v0.14.0-3288-g2b5c5f03c and "guix environment guix" works for me <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>this fails directly: guix build /gnu/store/yxhm6gkls1gy8l43i26bdwszz76m445j-module-import.drv <rekado>this also fails: guix build /gnu/store/l18qglllykpdbjj04603f6fhvby8b0p6-module-import-compiled.drv <rekado>it looks like these module-import and module-import-compiled derivations are the only derivations that trigger this error. <roelj>These derivations do not exist in my store. Does Guix throw away derivations that didn't succesfully build? <rekado>roelj: do you get them when running guix pull? <rekado>but it *does* graft a couple of things successfully. <civodul>rekado: can you confirm that "cat $(guix build --log-file /gnu/store/l18qglllykpdbjj04603f6fhvby8b0p6-module-import-compiled.drv)" shows the "Uncaught exception"? <civodul>what's --cores on the machine that built this derivation? <roelj>civodul: 48 on the cluster, 4 on my laptop. <civodul>rekado: you don't have access to the build log? <rekado>the build doesn’t end and I need to abort it. <roelj>(my laptop is building bash now after running 'guix pull', followed by 'guix environment guix') <rekado>“Uncaught exception” is the last thing that appears; it doesn’t terminate. <civodul>but it appears in the build log, right? <rekado>roelj: building bash is expected, because we need to build the replacement. <civodul>i want to make sure the error comes from the guile that builds the grafting drv <roelj>rekado: Sure, that means I cannot see whether it'll run into the “Uncaught exception” until it has been built :) <rekado>the module-import-compiled.drv depends on module-import.drv and that’s the one that fails. <rekado>bzcat $(guix build --log-file /gnu/store/yxhm6gkls1gy8l43i26bdwszz76m445j-module-import.drv) <civodul>could you paste the contents of that .drv? <civodul>we should try running it manually with additional debugging stuff <rekado>Derive([("out","/gnu/store/80ik20w6ac4gfvd02imc5z3gajhx2ymq-module-import","","")],[("/gnu/store/mya901yw084g0c17wy4ag0fm7iqg6dbf-guile-2.2.3.drv",["out"])],["/gnu/store/2dnmm8qgqy6692hmvw2rqd2zb28pszk9-profiling.scm","/gnu/store/649l9llq03gx6wiw8j1r5zajc46gzr17-modules.scm","/gnu/store/6m80sb3ak3544s2hj0zq5zg06mss91pa-module-import-builder","/gnu/store/by91xfbd2sicbbkljsm0ya0vylbralgz-memoization.scm","/gnu/store/cj6bzq5g8m3l6g9lxsilq2iszi0 <rekado>see, I did run the module-import-builder manually, but there’s no problem at all. <rekado>(oops, this looked shorted with guix-prettify-mode; sorry) <rekado>this works fine when run run with “out=/tmp/foo” <rekado>i.e. it creates the directory and places the files there. <civodul>and with "guix build", does it fail systematically? <civodul>rekado: could you "strace -f -s 345 -p $(pidof guix-daemon)" and then "guix build ...drv"? <rekado>heh, I tried that but now I can’t terminate the strace process any more… <civodul>at this point i'm running out of ideas so... :-) <civodul>32560 open("/gnu/store/al8dihvfrcwl6gn7dsmcmz89q9vqbq61-glibc-2.26.105-g0890d5379c/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory) <civodul>32560 open("/gnu/store/4sqaib7c2dfjv62ivrg9b8wa7bh226la-glibc-2.26.105-g0890d5379c/lib/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) <civodul>mthl reported something like that a few weeks ago <civodul>what happens here is that we lack gconv-modules, so libc cannot do iconv, so Guile borks <civodul>i have the latter but not the former <civodul>rekado: should we revert, open a bug, and start from there? <civodul>you'd still have a bit of pressure tough, i understand <civodul>perhaps we should sidestep the issue with a local hack in r-minimal or something <rekado>yeah, at least it isn’t borked for everyone when we revert. <civodul>well i hope we'll fix soon, but we should first reduce pressure <rekado>the problem is with *all* software on the cluster; R is just a symptom. <rekado>and rebuilding that with a fix is … a lot of effort. <rekado>I’ll revert c4fb2b9f4e9ca1c5b586090b765b51b2a5042eff now. <rekado>pushed the reverts for all three commits. Better remove them all together to avoid confusion. <civodul>could you check where "/gnu/store/mya901yw084g0c17wy4ag0fm7iqg6dbf-guile-2.2.3.drv" comes from? <rekado>it says ("preferLocalBuild","1"), so it probably is. <rekado>the builder script is for grafting. <rekado>/gnu/store/8r36k39wmdqamf2k3vndfgra2ypj2r1q-guile-2.2.3.drv, i.e. /gnu/store/z2i9srf64afxina1g2bd7k7y8cjqsxrr-guile-2.2.3 <civodul>nscd in the grafted libc contains a "chunked" reference to the original libc <civodul>ah no, that's the smart hack we do in nscd_stat.c ***pkill9_ is now known as pkill9
<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) <efraim>gawk@4.2.1 built succesfully on core-updates <mbakke>efraim: Great, I was about to test it. I believe it has fixed the bug that caused a gettext test failure too. <efraim>I also didn't fail while building tar <efraim>parallel tests also seem to work <mbakke>"the FAQ section is worse than Buffy fanfic" :P <rekado>civodul: so, on core-updates I’ll apply the patch to glibc, then remove all the glibc grafting stuff, and in a couple of days we can merge core-updates? <efraim>I'm going to try cross-compiling from aarch64->i686 with gawk before pushing <civodul>rekado: yes, though it'll probably be more than a couple of days <civodul>we also need to coordinate with 'staging' <civodul>it's clear we need to get more people on board and do that calmly <rekado>would it make sense to start building a new branch on berlin that only contains the glibc change? <rekado>another workaround for CentOS 6 until the rebuild might be to LD_PRELOAD the glibc replacement. <civodul>rekado: berlin is already building the "core" subset of core-updates <civodul>core-updates only contains harmless-looking changes <civodul>so i don't think we need to create a separate branch <civodul>for your lab, is it an option to switch to core-updates before we've merged it? <civodul>maybe using a local branch or somethign <rekado>I could announce this to the whole institute that they should switch to “guix pull --branch=core-updates” <civodul>ok, i thought you were running it on their behalf <rekado>I always encouraged them to take matters into their own hands, but the majority prefers not to use guix pull. <civodul>alternately, you could create a special "mdc" branch until things stabilize, and set GUIX_PULL_URL cluster-wide <civodul>we'd need a GUIX_PULL_BRANCH variable as well, but that's ok <rekado>is it fine for me to add the patch to glibc to core-updates? Or would you prefer I wait. <rekado>I’m merging master into core-updates. <civodul>make sure to take a break at some point too :-) <rekado>heh, I was trying to do just that a couple of hours ago :) <nckx>civodul: it needed a master → core-updates merge which I didn't know I could just... do. <nckx>So that's now solved :-) <nckx>Hah. It was really ready to go. Pushed. <efraim>i pushed the gawk update to core-updates <rekado>could I merge the python-updates branch into core-updates? Or should I stop mentioning that branch…? :) ***lostcoffee is now known as atw
<mbakke>Do you think it's safe to change the buffer size to "tost->st_size + 2"? <mbakke>rekado: Merging python-updates to core-updates sounds good to me. Since it's only one patch, might as well cherry-pick it. <mbakke>I wonder if we can add a system test for the strmov issue. <efraim>I saw that with glibc-2.27, I think debian has a similar patch and they changed it to 2 <rekado>hmm, I can’t build ghc on core-updates <rekado>it’s because of that ncurses string-take thing. Will try to patch it. <bavier`>here we go, 676 package builds until icecat... <efraim>no errors from 'guix lint -c source-file-name' now <thorwil>are users meant to edit ~/.bash_profile directly? <thorwil>on one hand that's nice and easy, on the other, one additional file required to restore the whole "system" <rekado>thorwil: why would they edit ~/.bash_profile? <rekado>it is usually enough to just do “source ~/.guix-profile/etc/profile” <rekado>instead of recording each and every environment variable in ~/.bash_profile <thorwil>rekado: the specific case here is setting XDG_RUNTIME_DIR <thorwil>along with a mkdir in /tmp and chmod <thorwil>though maybe i should just call weston-launch within a script <thorwil>ACTION is tired of pasting: export XDG_RUNTIME_DIR=/tmp/${UID}-runtime-dir; mkdir "${XDG_RUNTIME_DIR}"; chmod 0700 "${XDG_RUNTIME_DIR} <rekado>it sounds like this should be a service. <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 :/ <civodul>once things have settled down, we should discuss things we could do better next time <civodul>mbakke: re the patch patch (!), i think st_size + 1 is correct, so all we need to add is buffer[r]='\\0' <civodul>do you think you could update the patch? <mbakke>civodul: Thanks for checking! I've built pretty far with that change, so I'll go ahead and commit it. <civodul>ACTION builds gcc@5 with an adjusted strmov patch, hoping they won't have to dive into gcc again <mbakke>civodul: Just wait until we're forced to deal with the C_INCLUDE_PATH/-Isystem issue.... <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? <mbakke>Haven't seen it before though, and I use offloading a lot :) <mbakke>At least it reminded me to update automake in core-updates. <civodul>mbakke: BTW, you sure the C_INCLUDE_PATH issue is also for GCC 6? <civodul>the upgrade from 5 to 6 as the default gcc is going to be painful <civodul>oh yes, it will be nice as well, no doubt :-) <civodul>yes, packages are compiled with gcc5 by default <mbakke>efraim: Did you have any luck with the glibc 2.27 upgrade? <mbakke>Is it worth explicitly propagating inputs that are mentioned in pkg-config files, when they are already propagated from another propagated-input? <mbakke>In this case, I'm thinking of pango, which needs glib, freetype and fontconfig; but they are already propagated from cairo. <civodul>mbakke: in theory re-propagating them is clearer IMO, but it's no big deal <mbakke>I'm leaning towards the same, and will adjust for clarity. It also helps if cairo suddenly does things differently.