IRC channel logs

<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?

<sriharsha>s/temp/tmp

<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>bash

<jmd>source environment-variables

<jmd>cd zzzzz

<jmd>from there you have your environment set as it was during the build.

<sriharsha>ok

<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: http://pastebin.ca/2554521

<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

<sriharsha>sure

<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

<zacts>:-)

<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 http://www.gnu.org/software/guix/package-list.html

<civodul>it's updated daily

<zacts>oh cool!

<ggrant>zacts: The Hurd wiki mentions Guix in a few places, fyi :^)

<ggrant> http://www.gnu.org/software/hurd/community/gsoc/project_ideas/package_manager.html

<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 http://www.gnu.org/software/guix/manual/guix.html#Bootstrapping

<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

<sriharsha>ok

<civodul>sriharsha: got it, that's a silly bug in Guile

<jmd>Is sed part of coreutils ?

<civodul>jmd: no, http://gnu.org/s/sed

<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 http://www.gnu.org/software/guix/manual/guix.html#Defining-Packages

<jmd>oh

<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>yes

<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>ok

<sriharsha>looks like we don't have to worry about that message; my changes were applied :)

<zerwas>yes

<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>cool

<civodul>BTW, not that, since you use a different store dir name, you won't be able to use substitutes

<civodul>*note

<sriharsha>oh!

<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: http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/)

<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! :-)

<sriharsha>indeed.

<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: http://pastebin.ca/2554707

<sriharsha>figured out, have to add the patch to gnu-system.am

<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>ok

<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: http://pastebin.com/NzhYAvfJ

<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!

<zerwas>bye!

<civodul>ooh, nice, a libgnurl package :-)

<zerwas>almost

<civodul>good

IRC channel logs

2014-01-17.log