IRC channel logs


back to list of 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:
<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>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`>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:
<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`>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
<zacts>lo guix!
<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>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 :)
<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>viric: lots of progress on the eo front:
<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>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:
<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.
<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>i've been dreaming of that for some time
<civodul>it lacks 'sexp-patch' though
<civodul>oh he maintains a copy of s3 too:
<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