IRC channel logs


back to list of logs

<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.
<rekado>Hi Guix!
<janneke>Hi rekado :-)
<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
<civodul>Hello Guix!
<nckx>Hullo civodul.
<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
<pmikkelsen>just wanted to let you know :)
<thomassgn>good noon guix! back after disk fail. Lucky I had an ssd here. :P
<risciii>Hi Guix
<risciii>guix pull is giving 'Uncaught exception:'
<risciii>And then blank
<rekado>yeah, I also see this now.
<rekado>working on it
<risciii>I wanna contribute to Guix too, how do I get started?
<risciii>I am reading Guile and guix manuals and reading through source
<risciii>way over my head
<rekado>risciii: the best way to start is to get the Guix source code and to add a package definition.
<risciii>Ok, i do want way-cooler on guix
<rekado>civodul: I also get “Uncaught exception” now when building simple derivations.
<rekado>e.g. guix build /gnu/store/dif77mrmwpd2vvk1zn83p1ldfq003hfr-module-import.drv
<rekado>gah, this is horrible.
<rekado>the log file only contains “Uncaught exception:”
<rekado>this is very strange.
<rekado>building r-minimal worked fine, but some derivations throw “Uncaught exception” now.
<rekado>building all related drvs 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: that's pretty neat timing :)
<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>I broke it.
<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.
<rekado>ACTION is not happy
<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>(in static-bash-for-glibc)
<rekado>is “Uncaught exception” indicative of a derivation loop?
<rekado>ACTION –> off to a meeting :(
<civodul>grr crashed my laptop with OOM
***tilpner_ is now known as tilpner
<civodul>roelj: i'm at v0.14.0-3288-g2b5c5f03c and "guix environment guix" works for me
<civodul>how can i reproduce the probleM?
<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>I ran it on my laptop just now and this is the output:
<rekado>civodul: ^
<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?
<roelj>I'm running that now.
<civodul>ACTION is back
<civodul>so it's grafting that fails
<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?
<civodul>same question for you, roelj :-)
<rekado>it’s my laptop :(
<rekado>4 cores
<roelj>civodul: 48 on the cluster, 4 on my laptop.
<civodul>rekado: you don't have access to the build log?
<rekado>there is no 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')
<civodul>ACTION tries 'guix pull'
<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.
<civodul>oh module-import.drv fails?
<rekado>bzcat $(guix build --log-file /gnu/store/yxhm6gkls1gy8l43i26bdwszz76m445j-module-import.drv)
<rekado>Uncaught exception:
<civodul>could you paste the contents of that .drv?
<civodul>we should try running it manually with additional debugging stuff
<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)
<civodul>it's truncated also
<rekado>huh, really?
<civodul>yeah, better use :-)
<rekado>and this is the builder:
<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?
<rekado>every time
<civodul>rekado: could you "strace -f -s 345 -p $(pidof guix-daemon)" and then "guix build ...drv"?
<civodul>"-o log" too
<rekado>heh, I tried that but now I can’t terminate the strace process any more…
<civodul>"pkill -9 strace" :-)
<civodul>or power button, dunno
<rekado>so violent!
<civodul>at this point i'm running out of ideas so... :-)
<civodul>could you paste the strace log?
<rekado>ACTION pastes
<rekado>bah, too long
<rekado>will upload elsewhere
<civodul>yeah or just the second half
<rekado>it starts executing at 1045
<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>there’s also Python.
<rekado>and rebuilding that with a fix is … a lot of effort.
<rekado>I’ll revert c4fb2b9f4e9ca1c5b586090b765b51b2a5042eff now.
<rekado>the other commits seem fine.
<rekado>pushed the reverts for all three commits. Better remove them all together to avoid confusion.
<civodul>ok, thanks!
<civodul>could you check where "/gnu/store/mya901yw084g0c17wy4ag0fm7iqg6dbf-guile-2.2.3.drv" comes from?
<civodul>i don't have it here
<civodul>is it a grafting derivation or not?
<rekado>it says ("preferLocalBuild","1"), so it probably is.
<rekado>yes, it is.
<rekado>the builder script is for grafting.
<civodul>and what's the thing being grafted?
<rekado>/gnu/store/8r36k39wmdqamf2k3vndfgra2ypj2r1q-guile-2.2.3.drv, i.e. /gnu/store/z2i9srf64afxina1g2bd7k7y8cjqsxrr-guile-2.2.3
<civodul>ok that's guile-final
<civodul>Houston, we have a problem
<civodul>well we already knew that
<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
<civodul>but 'sln' definitely does
***pkill9_ is now known as pkill9
<civodul> as well, we're doomed
<rekado>civodul: where do you see the references to the original libc? I have the grafted 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)
<civodul>so we'll have to rebuild
<rekado>oh, yeah I see.
<civodul>i'm trying to reproduce the problem with an example like that of
<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
<Sleep_Walker> :)
<Sleep_Walker>bavier`: ^
<efraim>parallel tests also seem to work
<bavier`>Sleep_Walker: thanks, another good one was posted on HN today:
<Sleep_Walker>ah, thanks
<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>yes, it’s possible.
<rekado>I could announce this to the whole institute that they should switch to “guix pull --branch=core-updates”
<civodul>do people use 'guix pull' directly?
<rekado>some of them.
<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.
<rekado>for those it’s easy.
<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.
<civodul>the 2.6.32 patch, definitely
<civodul>i thought it was already there
<civodul>nckx: could you merge the cURL/HTTP2 patch? apparently some other patches need it:
<rekado>I’m merging master into core-updates.
<civodul>great, thanks
<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 :)
<civodul>yeah :-/
<nckx>civodul: it needed a master → core-updates merge which I didn't know I could just... do.
<nckx>So that's now solved :-)
<civodul>heheh :-)
<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
<atw>y'all read ? Makes me think of Ludo's slide that had "scheme!" labels on everything :)
<mbakke>civodul: "patch-hurd-path-max.patch" conflicts with this upstream commit:
<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
<mbakke>Interesting. Debian only has this for GNU patch:
<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?
<bavier`>thorwil: yes
<wigust->thorwil: it's even prefered than ~/.bashrc sometimes, see
<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>rekado: yep, i agree!
<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>Wait, what?
<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>rekado: Probably.
<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>heheh :-)
<civodul>mbakke: BTW, you sure the C_INCLUDE_PATH issue is also for GCC 6?
<mbakke>civodul: Yes.
<civodul>the upgrade from 5 to 6 as the default gcc is going to be painful
<bavier`>it could be nice too
<civodul>oh yes, it will be nice as well, no doubt :-)
<jonsger[m]>is guix still compiled with gcc5?
<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.
<civodul>good night!