IRC channel logs

2014-03-19.log

back to list of logs

<rigelk>civodul: it seems that it is gcc-cross-boot0-4.8.2's builder that fails each time I try to compile.
<civodul>oh?
<civodul>oh i just saw your proposal on melange, cool!
<rigelk>civodul: I admit I don't know what part of the log has to be shown. verbosity=5 is just so confusing ^^'
<civodul>yeah, don't use --verbosity
<civodul>but you didn't reply to my message, did you?
<rigelk>the one about my compilation failure ?
<civodul>you posted a backtrace, which was not a compilation failure
<civodul>and i replied
<civodul>on guix-devel@gnu.org, i mean
<civodul> https://lists.gnu.org/archive/html/guix-devel/2014-03/msg00187.html
<ph4n70m4s>civodul: I am almost there :-D
<ph4n70m4s>I am getting the error
<ph4n70m4s><stdin>:7:83: error: invalid use of undefined type 'struct pthread'
<ph4n70m4s>but this is because there is an error while running autoconf at the libpthread path
<rigelk>ah ! i mean, no, i didn't reply ; I had to compile to verify. Twice.
<ph4n70m4s>part*
<ph4n70m4s>fixing that now
<civodul>ph4n70m4s: sounds good :-)
<civodul>rigelk: ok, well do reply then ;-)
<civodul>otherwise i get lost
<civodul>i'm like a goldfish: i can forget everyone's build issues very quickly
<civodul>:-)
<ph4n70m4s>:P
<rigelk>x)
<rigelk>sure ! don't get lost because of me ; it's not worth it
<civodul>heh, fixing user problems is sometimes uneasy, but always worth it
<rigelk>hum. could take some time ; what part of the log do you what, btw ? And is there a command option/other that enables log files, or do I just get the stdout log?
<civodul>rigelk: https://lists.gnu.org/archive/html/guix-devel/2014-03/msg00187.html asks a specific question, and doesn't mention any log
<rigelk>I need glasses.
<civodul>:-)
<rigelk>the question stays still, though ;)
<civodul>hmm dunno, please reply on guix-devel
<civodul>for now -> bed
<civodul>good night/day!
<rigelk>same here.
<ph4n70m4s>good morning guix
<ph4n70m4s>mark_weaver: any idea why I am getting "autoreconf: failed to run libtoolize: No such file or directory"
<ph4n70m4s>?
<ph4n70m4s>I have included #:use-module (gnu packages autotools)
<ph4n70m4s>and I have ("libtool" ,libtool) as a native input
<ph4n70m4s>the build log http://pastebin.com/raw.php?i=2xLGssCw
<mark_weaver>ph4n70m4s: libtoolize is in the 'bin' output, not the default 'out' output of libtool.
<mark_weaver>ph4n70m4s: so the native input should be specified as: ("libtool" ,libtool "bin")
<mark_weaver>'guile-ssh' in ssh.scm is an example of a package that does this.
<bavier>I'm getting a test failure building pulseaudio
<bavier>the failure message is: "shm_open() failed: Function not implemented"
<bavier>I checked the make logs, and -lrt is being linked in
<mark_weaver>bavier: I'm not sure if this is the problem you're facing, but there's an issue on some systems (e.g. debian+derivatives) where /dev/shm is a symlink to /run/shm
<mark_weaver>is that the case on your system/
<mark_weaver>?
<bavier>yes, /dev/shm is in fact a symlink to /run/shm
<bavier>so, that would be a build chroot problem then
<mark_weaver>one solution is to make that a bind mount instead. as root: rm /dev/shm && mkdir /dev/shm && mount --bind /run/shm /dev/shm
<mark_weaver>right, the chroot includes a bind mount for /dev, and then the symlink is broken.
<mark_weaver>the best solution, IMO, is to change the daemon so that it doesn't inherit /dev from the host system, but instead creates a barebones one from scratch.
<mark_weaver>but that has yet to be done.
<bavier>your suggestion of bind-mounting /dev/shm works
<bavier>it would be nice in terms of reproducibility to have the daemon handle that transparently
<mark_weaver>yep, there are a lot of things left to be done.
*civodul migrated his laptop to /gnu/store, yay!
<mark_weaver>nice! I'm working on that too, but am still waiting for my YeeLoong to build everything I need. perhaps unwisely, I choose to keep master on /nix/store and am building core-updates for /gnu/store, but I keep having to start over.
<mark_weaver>and now it seems I will soon have to start over again for Guile 2.0.11.
<civodul>yeah
<mark_weaver>civodul: btw, when I run "guix package -i" for the first time, using a Guix based on /gnu/store (and also a different localstatedir), how will that work? will it read the manifest from the profile directory and use that as the original profile to modify, or will it consult something else and assume that I'm starting from an empty profile?
<civodul>mark_weaver: i thought it would read the old manifest, but actually no :-)
<civodul>because if you have different $localestatedir, the default manifest is in a different location
<civodul>*default profile
<civodul>i'll send my recipe to migrate the profile
<mark_weaver>I don't mind, I was just curious. I'll just reinstall everything I need.
<mark_weaver>I want to make sure I'm not using anything from /nix/store anyway.
<civodul>it's not possible to build a profile that refers to stuff outside of the store
<mark_weaver>ah, good.
<mark_weaver>civodul: can tzdata be updated in master, or only core-updates?
<civodul>master is OK
<mark_weaver>thanks
<ph4n70m4s>civodul: any ideas on the autoconf issue?
<ph4n70m4s>I was looking for the same error outside guix and I found that it apears when libtool isn't normally installed
<civodul>ph4n70m4s: i think i replied to your message, didn't i?
<ph4n70m4s>I will check the configure scipts of libpthread to see where it is used
<ph4n70m4s>I sent a new one
<civodul>ah ok
<mark_weaver>ph4n70m4s: is this the libtoolize thing? if so, I replied here on channel.
<ph4n70m4s>it doesn't work, it brings up another error
<mark_weaver>so you specified the native input as ("libtool" ,libtool "bin") ?
<ph4n70m4s>the same as if I hadn't included libtool as an input at all
<ph4n70m4s>yes
<mark_weaver>okay
<civodul>ph4n70m4s: ok, just replied :-)
<civodul>you need both
<ph4n70m4s>okay
<ph4n70m4s>it works
<ph4n70m4s>I feel really stupid right now :P
<civodul>excellent
<civodul>don't!
<ph4n70m4s>now let's me see how it handles libpthread building