IRC channel logs

<jmd>make is telling me that 'dot' is missing. Where do I get 'dot' ?

<dfsfgfsg>jmd, jmd`: You should install Graphviz.

<dfsfgfsg>See "Building from Git" in 'HACKING'.

<jmd>dfsfgfsg, Thanks.

<civodul>Hello Guix!

<civodul>i think i just fixed cross-bootstrap in core-updates

<civodul>the branch is looking OK: http://hydra.gnu.org/jobset/gnu/core-updates

<civodul>so i think i'll be merging Real Soon Now

<civodul>mark_weaver: fine with you?

<gzg>civodul: I think everything is done, for the revised slim patch. But fyi, the "non-static binary" referred to the "changing hash" problem found on individually generated tarballs, I mentioned earlier.

<civodul>ah, ok

<gzg>Too, do you want me to upload a paste -- you can quickly skim over of slim.scm over real quick?

<civodul>yes, but we can also do that by email

<civodul>well as you prefer

<civodul>we'll need the final version by email so i can use "git am" and be done

<gzg>civodul: http://paste.lisp.org/display/140141

<gzg>newpaste.el is lovely, btw. :^)

<gzg>I guess it should just be "set-etc-location" for this new phase.

<jmd`>Why was the --daemon flag deprecated?

<civodul>gzg: looks good to me! the indentation of string-append still needs to be tweaked, as i wrote

<civodul>jmd`: which --daemon flag?

<gzg>civodul: Gotcha.

<jmd`>civodul: nix-daemon.cc:905

<jmd`>if (arg == "--daemon") /* ignored for backwards compatibility */;

<mark_weaver>civodul: hi! core-updates is mostly looking quite good on Loongson, fwiw. However, did just get a strange build failure on the Loongson 2F.

<mark_weaver>civodul: here's what I see at the end of the build log: http://paste.lisp.org/+304U

<mark_weaver>If we had Guile 2.0.10, then we'd have much nicer 'match-error' reports.

<mark_weaver>this is with core-updates v0.4-269-gd321bf4

<jmd`>deamonLoop contains the code:

<jmd`>chdir (somewhere);

<jmd`>....

<jmd`>if (...) throw ;

<jmd`>chdir ("/");

<jmd`>This means that the chdir ("/"); will be forgotten if the throw occurs.

<jmd`>Similarly for the unlink a few lines above.

<jmd`>Would you guys accept a patch?

<mark_weaver>civodul: no need to hold up the merge though; the core stuff all works. e.g. I built emacs on both the 2F and 3A, and many more things on the 3A.

<gzg>civodul: Sent/Posted.

<civodul>hi mark_weaver!

<civodul>mark_weaver: that net-tools thing doesn't seem serious

<civodul>jmd`: that's Nix history

<civodul>ancient history, even ;-)

<civodul>and we don't use that argument parsing function anyway

<jmd`>well the whole loop does seem rather pointless.

<jmd`>in fact, the compiler probably optimises it away.

<jmd`>I'm kindof worried that the guix-daemon could be used as an attack vector, since it runs as root and accepts commands via a socket from a non-root.

<jmd`>In effect it acts like a setuid program.

<civodul>well yes, it runs as root

<civodul>but dunno, you'd need to be more specific about possible issues, i guess :-)

<davexunit>hey civodul .

<davexunit>when you say that sdl should be explicitly linked against libxext, do you mean that libxext should just be placed in the inputs list?

<civodul>davexunit: not sure if that's enough; perhaps we need to pass LDFLAGS=-lXext

<civodul>apparently it purposefully dlopens it

<davexunit>I'm a little weak on what some of these flags and such are doing.

<davexunit>libxext doesn't appear in the .pc file for sdl or anything.

<davexunit>I'll make the change, I just want to understand what's going on a bit better. :)

<civodul>my understanding/guess is that SDL has several back-ends, one of which is libXext

<civodul>and it only tries to dlopen them at run time

<civodul>which fails by default, because users don't necessarily have libXext in the search path by default

<civodul>so we need to make that work by default

<civodul>hence the two solutions i proposed

<davexunit>ah, I see.

<davexunit>which do you think is the better route?

<davexunit>explicitly link against it?

<davexunit>setting the LDFLAGS at compile time is enough to fix it?

<civodul>explicitly linking against it, yeah

<civodul>passing LDFLAGS=-lXext as #:configure-flags may work

<civodul>if it uses Auto{conf,make}, and uses it correctly ;-)

<davexunit>I will give it a try. how will I know if it worked?

<civodul>you can build an SDL app and launch it

<civodul>perhaps QEMU is the only one currently

<davexunit>okay I will look into that.

<davexunit>I don't have guix very well hooked up to my actual operating system. I keep it sort of isolated at the moment.

<civodul>don't be afraid ;-)

*civodul merged core-updates

<davexunit>woo!

<zacts>lo guix!

<civodul>hey!

<mark_weaver>nice!

<mark_weaver>civodul: I guess I should get moving on setting up Loongson 2F machines for Hydra.

<mark_weaver>civodul: what needs to be done for that, assuming that we use several Loongson 2F machines?

<civodul>mark_weaver: the main thing is writing the daemon hook so it can offload builds

<civodul>and so writing the thing to transfer closures

<mark_weaver>nix already has this functionality, right? I'm surprised that didn't come with the nix-daemon that we inherited.

<civodul>it has this functionality, but it's written in Perl

<civodul>and guideline #1 was: get rid of Perl

<civodul>:-)

<civodul>it's not really difficult to implement though

<civodul>just needs to be done

<civodul>i was planning to look into it after 0.5

<mark_weaver>getting rid of perl sounds good to me :)

<civodul>:-)

<mark_weaver>okay, I guess I'll wait for you to look into it.

<mark_weaver>I guess maybe I should delete the 'loongson' branch now.

<civodul>prolly

<mark_weaver>done

<civodul>viric: lots of progress on the eo front: http://sourceware.org/bugzilla/show_bug.cgi?id=16190

<civodul>what a different project glibc has become

<civodul>it's a relief

<mark_weaver>civodul: you recommended that jmd use 'guix package' to install guile and gnutls, but how can he do that if he hasn't yet successfully compiled guix? :)

<viric>hehe

<viric>eo_ZZ then?

<viric>I've used once eo_XX. Fun that they go for ZZ

<civodul>mark_weaver: ah right, that's a good point :-)

<civodul>i had overlooked that

<mark_weaver>we seem to have a serious problem on debian systems.

<civodul>viric: i think XX is widespread (Debian & co.)

<civodul>allowing to dismiss country codes would be better

<civodul>mark_weaver: well Debian seems to have serious problems ;-)

<civodul>other than that, we have problems because it's an old Guile

<civodul>but i think Guix now has all the workarounds it takes to support it

<civodul>the Debian maintainers have recently switched guile-gnutls to Guile 2.0: http://packages.debian.org/experimental/guile-gnutls

<mark_weaver>nice!

<mark_weaver>I wonder if we could convince rlb to produce some newer guile packages for wheezy-backports

<mark_weaver>fwiw, I've also had problems with libgcrypt on debian wheezy.

<civodul>do you remember what problems?

<mark_weaver>configure concluded that libgcrypt was unusable.

<mark_weaver>sorry, this is not enough info. I'll have to investigate again.

<mark_weaver>I worked around the problem on the Loongson 3A by bootstrapping guix using the guix packages I had already built on the Loongson 2F.

<civodul>ok

<zacts>I remember I had to do some workarounds to get guix installed on debian based systems..

<zacts>I installed an earlier guix -release and then I upgraded from there

<mark_weaver>given the fact that most people are using debian or debian-derived systems, we should probably try to make it easier for them to install guix.

<civodul>yes, sure

<civodul>in fact, that's the reason why we support 2.0.5

<mark_weaver>would it be possible to avoid using gcrypt or gnutls from outside of the guix daemon?

<zacts>I'm going to be installing guix this weekend on debian 7.2

<zacts>so I'll let you guys know what problems I encounter, I guess.. :-)

<civodul>mark_weaver: no

<mark_weaver>maybe we could use weinholt's industria package instead?

<civodul>that would be too slow, i think

<civodul>well, outside the daemon we just need sha256 from gcrypt

<civodul>but that has to be fast because 'derivation' uses it a lot

<civodul>if you look at the history of utils.scm, at the beginning it could call out to coreutils' 'sha256'

<civodul>sha256sum, even

<civodul>commit dba6b34bdd21c4c03895f6eddf461a440ee3b13a

<mark_weaver>okay. I guess I don't see why there would be problems with debian's libgcrypt, so I'll have to investigate further.

<civodul>yeah, dunno

<civodul>oh! http://planet.racket-lang.org/package-source/stamourv/sexp-diff.plt/1/0/main.rkt

<civodul>i've been dreaming of that for some time

<mark_weaver>nice!

<civodul>it lacks 'sexp-patch' though

<civodul>oh he maintains a copy of s3 too: https://github.com/stamourv/s3

<civodul>perhaps we could use something based on that instead of inetutils & co.

<zacts>mark_weaver: when adding guix users how can I prevent them from being displayed in GDM?

<zacts>(if by chance you just happen to know..) :-)

<mark_weaver>zacts: well, one way is that GDM excludes all UIDs below a certain number value.

<mark_weaver>there might be another way also.

<zacts>ok, I'll check it out thanks

<mark_weaver>zacts: ah, check out the [greeter] section of /etc/gdm3/daemon.conf

<mark_weaver>you can give it an explicit list of users to include in the greeter.

<zacts>oh sweet! I see thanks

IRC channel logs

2013-11-23.log