IRC channel logs


back to list of logs

<sriharsha>Hi Guixers!
<jmd>sriharsha: Hello
<sriharsha>jmd, do you know if the guix-daemons are supposed to be run in a chroot? If so, what is that directory by default?
<jmd>No the daemons don't run in a chroot.
<jmd>They create chroots in which to run the build processes.
<sriharsha>jmd, I have the guile package failing to build. So I tried: guix build -e '(@ (gnu packages base) guile-final)' -K
<sriharsha>now I have a directory in temp with the failed build. Do you know if I can restore the build time chroot somehow to debug why it fails?
<jmd>Not exactly.
<jmd>But what I do in these situations is as follows:
<civodul>Hello Guix!
<jmd>sudo chown -R john.john /tmp/nix-build-xxxx
<jmd>cd /tmp/nix-build-xxxx
<jmd>source environment-variables
<jmd>cd zzzzz
<jmd>from there you have your environment set as it was during the build.
<jmd>The existence of the chroot *shouldn't* make any difference.
<jmd>But you have to watch out, because some stupid packages explicitly call stuff like /usr/bin/grep
<jmd>civodul: Hello Ludo
<sriharsha>jmd, thanks! I shall have a look
*ggrant is actually packaging xterm, finally. Should xinit be it's own module, or is xorg.scm fine?
<civodul>ggrant: xterm can go in xorg.scm
<jmd>I thought xinit was a script to start the x server
<ggrant>jmd: It is, I finished packing it (Still need to test and see if I can get my Parabola-hybrid box, to boot guile-wm without there xorg metapackage though.
<ggrant>We should probably have some sort of rule-of-thumb established, for some of these packages -- besides "what feels right". But yeah, I suppose xinit works for xorg.scm too. :^P
<ggrant>their metapackage*
<jmd>ggrant: You are right. I can forsee that sometime in the future, a big re-arrangement of the files will be required.
<jmd>Actually, there are some which I am not sure ought to be in gnu/packages at all.
<civodul>like what?
*ggrant is trying to think of what landmark packages still needs to be done, before he can seriously use the Upstream distro around 1.0. kbd and wpa_supplicant are the only big system tools he acknowledges thusfar.
<ggrant>I have libnl, I just need to bother with wpa_supplicant again one of these days.
<ggrant>Kbd still has that odd unicode thing, iirc
<jmd>civodul: For example, tor it's neither a gnu package, not part of the gnu system so far as I'm aware.
<civodul>by definition, if it's in this repo, then it's part of the GNU sytem :-)
<civodul>of course it didn't exist in 1983
<civodul>as most free software packages
<ggrant>civodul: I think some of the concern lays in the aptitude some have to blame GNU as trying to "take credit" for other packages?
<jmd>I think that is a strange definition!
<jmd>Let me ask this question: Which free software packages are NOT part of the gnu system ?
<sriharsha>civodul, I was able to reproduce the guile bug manually from the guile derivation build directory. Here's the output:
<ggrant>jmd: I think the question is part of the GNU Project, the GNU system is a bit a wide spectrum.
<civodul>ggrant: yeah, (gnu packages ...) is meant to read as "packages in GNU", not "GNU packages", but i can understand the problem
<civodul>it's a naming scheme
<civodul>noone would find it surprising if it were (debian packages ...), right?
<civodul>jmd: those not yet packaged, and those "uninteresting" or conflicting
<civodul>the goal is to make the GNU system a reality
<civodul>so we should stop thinking in terms of "what was it supposed to look like in 83?"
<civodul>well that's obviously important
<civodul>but the situation has evolved
<ggrant>civodul: I understand, but I'm afraid of critics to spread this attitude as-if it was an intentional claim to ownership. I've already seen this a lot, with a common response to the assertion of the system classification "GNU+Linux" or "GNU/Linux".
<jmd>So why do we need the gnu directory at all? We could move everything in it down one level.
<civodul>sriharsha: oh good that you could reproduce it
<civodul>could you run that process in "strace -f", and send the output?
<civodul>ideally mail that to the bug report
<civodul>(as a reply to my message)
<zacts>civodul: is the plan to package gnu/hurd with guix?
<zacts>(along with gnu/linux)
<ggrant>civodul: Overall, I get the reasoning of why -- I'm just a bin unnerved by the social aspect/response to it. :^P
<ggrant>zacts: I'm sure, but too I'm sure it will not be the recommended distro, for some time... :^U
<civodul>zacts: yes
<civodul>ggrant: for the social aspect, i think our attitude matters more than the module naming convention, really
<zacts>I want to see a new more modern gnu system become a reality
<civodul>jmd: traditionally, Guile packages put their modules in a hierarchy of their own, like (guix ...), (pspp ...), (guile-wm ...), etc.
<zacts>is there a web interface to the packages that have been ported to guix?
<civodul>zacts: not really a "web interface" ;-), but see
<civodul>it's updated daily
<zacts>oh cool!
<ggrant>zacts: The Hurd wiki mentions Guix in a few places, fyi :^)
<ggrant>civodul: Yeah, I suppose.
<zacts>I wonder what is needed to port gnunet to guix
<zacts>I should look into it
<zacts>what was the inital bootstrap of guix like? was it cool bootstrapping guix?
<zacts>and a mini guix would be cool. so I can install packages on ssh/mosh servers that I only have user access to.
<civodul>zacts: see
<civodul>Andreas has tried to package GNUnet, but there were some issues with the test suite, i thihnk
<ggrant>zacts: A general/flexible profile generator, via EDSL, I'm really excited for. Right now, you can experiment with the vm generator, for such a build, but it's not the prettiest to play with from what I can tell. I never was able to generate a bigger vm image... :^P
<sriharsha>GNUnet test cases require networking over loopback to be enabled, but that seems to be forbidden in guix
<civodul>no, that's OK
<civodul>but resolv.conf is missing
<jmd>Presumably it needs only to be a very trivial resolv.conf ?
<civodul>yes, but it cannot be written to from the builder
<sriharsha>civodul, I do not get that test case failure if I build guile-2.0.9 manually on my system. Instead I get this and the test case passes:
<sriharsha>nautophone:~/build/guile-2.0.9/test-suite/standalone$ GUILE_INSTALL_LOCALE=1 GUILE_AUTO_COMPILE=0 ../../meta/uninstalled-env ./test-command-line-encoding2
<sriharsha>/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US)
<sriharsha>guile: warning: failed to install locale
<civodul>yeah, that's OK
<sriharsha>civodul, search for '/nix/store/eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee-glibc-2.18-locales/share/locale/locale-archive' in the trace file
<sriharsha>this is strange
<jmd>Isn't there a way to specify an alternate resolv.conf ?
<civodul>sriharsha: that's normal, it's from the bootstrap Guile, not from the one being built
<civodul>sriharsha: got it, that's a silly bug in Guile
<jmd>Is sed part of coreutils ?
<civodul>jmd: no,
<jmd>That's what I thought. So I am surprised that it is coming up in the path of a build when sed is not a dependency
<civodul>that's part of the implicit inputs when using gnu-build-system: see the second bullet at
<sriharsha>what does "search-path" here do: (patches (list (search-patch "guile-1.8-cpp-4.5.patch")))
<civodul>it returns the absolute file name of the given patch
<civodul>which is stored in gnu/packages/patches
<civodul>sriharsha: so did you work around that bug?
<sriharsha>now building with the patch, will let you know soon
<civodul>which patch?
<civodul>ah, utf-8, right?
<sriharsha>so I modified guile.scm and I get a warning:
<sriharsha> source file /home/totakura/repos/guix/gnu/packages/guile.scm
<sriharsha>;;; newer than compiled /home/totakura/repos/guix/gnu/packages/guile.go
<sriharsha>should I be concerned that my changes are not applied?
<zerwas>if you run "make" again you won't get that message
<zerwas>(and will be informed if the .scm file you edited has a valid or invalid syntax)
<sriharsha>looks like we don't have to worry about that message; my changes were applied :)
<sriharsha>compiling is such a drag.. these times I wish I have a supercomputer..
<zerwas>Yeah, compiling Guile took hours on my computer, too.
<civodul>sriharsha: Guile is just telling you that there's a stale pre-compiled file, so it's not using it
<civodul>Guile is chatty :-)
<sriharsha>civodul, the patch seems to have worked - compilation continuing post the tests
<civodul>BTW, not that, since you use a different store dir name, you won't be able to use substitutes
<sriharsha>can we migrate the store?
<civodul>no, because file names are embedded in binaries
<civodul>so when you change, you have to rebuild everything
<civodul>but note that within a month or so we'll switch from /nix/store to /gnu/store
<civodul>so you could just as well wait for that
<sriharsha>but /gnu will not adhere to standard file hierarchy. Any reasons for not putting it into /usr/gnu?
<viric>usr uses not to be in a different device, to be it a mount point different than /
<viric>since some years
<civodul>sriharsha: we do not adhere to the FHS
<civodul>rather we adhere to it locally, within each /nix/store subdir
<sriharsha>but it is usually advised to be on the same device as / (see this from systemd:
<sriharsha>the problem is many users, including myself, partitioned system according to FHS and may be left with few space on /
<sriharsha>if there was lvm, the situation can be salvaged, if not, then they have to use a custom store path.
<sriharsha>is it common for guile to be built several times? I think i saw it building twice already.
<civodul>i think it's built exactly twice during bootstrap
<sriharsha>phew, it built successfully :-)
<civodul>a relief! :-)
<civodul>we're in the deterministic build business, aren't we? ;-)
<sriharsha>Yes. I have a question now, i fixed the guile package recipe in the guix git sources and used guix build
<sriharsha>Now, should I install this changed one with make install OR since guile is already in the store now, will it be used next time if any package requires it?
<civodul>you must keep the changes in your tree
<civodul>every time you run "guix build", Guix traverses the whole dependency tree to compute the store file name
<civodul>so if you remove the changes, it will want to build the broken Guile
<civodul>you can think of "guix build" as a pure function
<civodul>the store just caches its results
<sriharsha>I did not understand
<sriharsha>I mean, I have 2 trees now: the one is guix source dir and the other in /usr/local/share/guile...
<sriharsha>I believe if I use "guix package --install=hello" the tree from /usr/local/share/guile.. is used
<sriharsha>Now I get this error related to patches:
<sriharsha>figured out, have to add the patch to
<sriharsha>for it to get installed at the correct place
<civodul>sriharsha: yes, the "guix" command uses the installed tree
<civodul>if you want to use the uninstalled tree, use "./pre-inst-env guix ..."
<civodul>and yes, the patch has to be installed as well
<sriharsha>Which module should I have to include to address this error: failed to evaluate expression `(@ (gnu packages gnunet) libgnurl)': (unbound-variable #f "Unbound variable: ~S" (search-patch) #f)
<sriharsha>figured it, have to include (gnu packages)
<sriharsha>later guys!
<sriharsha>zerwas, give me your email. I will update you with the libgnurl patch
<sriharsha>ah, wait, I shall try to paste it somewhere
<sriharsha>zerwas, here you go:
<sriharsha>the tests still fail though, I am running a build again but won't be able to be online until late tomorrow.
<zerwas>sriharsha: nice work, thanks!
<zerwas>sriharsha: hm, shouldn't libgnurl itself be patched instead of providing a patch for Guix?
<sriharsha>yes indeed, i wrote an email to grothoff asking him to update libgnurl
<sriharsha>but for the time being, this should give us some progress
<sriharsha>I also noticed that some test cases try to access /etc/hostname file and they fail as there is no such fail in the chroot
<zerwas>:) true
<zerwas>Ah, I see. civodul already mentioned this issue
<sriharsha>i wonder how libcurl tests pass, the recipe doesn't seem to do anything unusual there..
<zerwas>Yeah, that's strange
<sriharsha>till then, bye!
<civodul>ooh, nice, a libgnurl package :-)