IRC channel logs

2013-12-10.log

back to list of logs

<bavier>I'm trying to use gcc from guix, but getting this error message from ld, any ideas? "~/.guix-profile/bin/ld: cannot find crt1.o: No such file or directory"
<civodul>bavier: yes, you need to do: guix package --install={gcc,glibc,ld-wrapper,binutils}
<civodul>the important thing is is that ~/.guix-profile/bin/ld must be ld-wrapper, not the real 'ld'
<civodul>ld-wrapper is the thing that adds RUNPATHs, etc.
*civodul goes to bed
<civodul>HTH!
<bavier>ok, I'll try that
***jxself_ is now known as jxself
***sea` is now known as sea
<civodul>Hello Guix!
<klrr_>civodul: hello
<civodul>hey
***sea` is now known as sea
<jmd>Is there an easy way to see the dependencies of a particular package?
<mark_weaver>jmd: "guix gc --help" shows that there are some options that might do what you want, but I confess I don't know precisely what they do.
<mark_weaver>-R aka --requisites might be the thing...
<mark_weaver>or --references, depending on whether you want the transitive closure or not.
<civodul>damn, we don't have xterm
<civodul>that's terrible
<a_e>What an oversight!
<a_e>I think when packaging x, I contented myself with xeyes as a test program...
<civodul>which reminds me: we don't have xsnow!
<civodul>this is terrible for our hemisphere
<a_e>xsnow? Something I apparently missed in my youth. Oh yes, xsnow!
<civodul> http://dropmix.xs4all.nl/rick/Xsnow/
<civodul>even a Wikipedia page: http://en.wikipedia.org/wiki/Xsnow
<a_e>And it is KDE enabled. Now we just need kdelibs...
<civodul>oh it wasn't free software apparently
<civodul>:-)
<civodul>i don't KDE still looks like on the screenshot, does it? :-)
<a_e>More or less, yes.
<a_e>Which reminds me that even after propagating all of perl and some more, raptor does not pass its tests. Probably time for yet another bug report. So yet another login to create on some website.
<a_e>Sorry, rasql, not raptor.
<civodul>oh
<civodul>bugzilla & co. are annoying for that
<a_e>Worse here, "make check" succeeds outside the chroot!
<a_e>Inside, I get the following cryptic error message:
<a_e>improve: Running testsuites sparql-query in /tmp/nix-build-rasqal-0.9.30.drv-0/rasqal-0.9.30/tests/sparql/bugs
<a_e>Use of uninitialized value $count in concatenation (.) or string at ./../../improve line 426.
<a_e>Use of uninitialized value $count in concatenation (.) or string at ./../../improve line 426.
<a_e>Use of uninitialized value $count in concatenation (.) or string at ./../../improve line 426.
<a_e>Use of uninitialized value $count in concatenation (.) or string at ./../../improve line 426.
<a_e>Use of uninitialized value $count in concatenation (.) or string at ./../../improve line 426.
<a_e> improve: Suite sparql-query failed preparation - No testsuite plan file sparql-query-plan.ttl could be created in /tmp/nix-build-rasqal-0.9.30.drv-0/rasqal-0.9.30/tests/sparql/bugs
<a_e> Testsuites summary:
<a_e> Passed: Failed: Skipped: Xfailed: Uxpassed:
<a_e>Makefile:486: recipe for target 'check-local' failed
<a_e>I think the critical line is the "failed preparation"; the perl error is just because no test was run, so the number of successful and failed tests cannot be counted.
<civodul>what's in improve:426?
<a_e>Code counting the tests.
<civodul>and how's $count initialized?
<civodul>nothing that could relate to the chroot env?
<a_e>Lots of other tests in other subdirectories work.
<a_e>The place where the real failure probably occurs looks like this:
<a_e>sub prepare_testsuite($) {
<a_e> my($testsuite)=@_;
<a_e> my $dir = $testsuite->{dir};
<a_e> my $name = $testsuite->{name};
<a_e>
<a_e> my $plan_file=$name."-plan.ttl";
<a_e> $testsuite->{plan}=$plan_file;
<a_e> unlink $plan_file;
<a_e> if(!-r $plan_file) {
<a_e>...
<a_e> return { status => 'fail',
<a_e> details => "No testsuite plan file $plan_file could be created in $dir"
<a_e> }
<a_e> unless -r $plan_file && !-z $plan_file;
<civodul>hmm
<a_e>There should be "}" after "...", which I meant to stand for the interior of the "if", that ends with a "return ...". So it is apparently false.
<a_e>The file sparql-query-plan.ttl exists and is empty.
<civodul>maybe if you run it in "strace -f" outside the chroot you'll see bits of /usr/bin and whatnot?
<a_e>The failing test has:
<a_e>[pid 5415] unlink("sparql-query-plan.ttl") = -1 EACCES (Permission denied)
<a_e>[pid 5415] stat("sparql-query-plan.ttl", {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
<a_e>Outside the chroot, one get instead:
<a_e>[pid 5466] unlink("sparql-query-plan.ttl") = 0
<a_e>[pid 5466] stat("sparql-query-plan.ttl", 0x2b811147adc0) = -1 ENOENT (No such file or directory)
<civodul>oh, and what's the current directory when that runs?
<a_e>Okay, I ran the failing test as the normal user, not as the guix build user; so it must fail here, I think.
<civodul>ah right, you need to "chown -R $USER /tmp/nix-build-XXX" before you start playing with it
<a_e>Yes, I just did it,
<a_e>now the tests pass. Even after sourcing the environment variables.
<civodul>thanks for reviewing NEWS, BTW
<civodul>and so does strace reveal use of /usr/something, say?
<a_e>There are quite a few
<a_e>open("/usr/lib/locale/locale-archive"
<a_e>I give up for tonight.
<a_e>The strange thing is that "improve" is the generic test script, that is executed in each and every test subdirectory. Things work in other directories.
<civodul>/usr/lib/locale/locale-archive ?
<civodul>oh
<civodul>fishy
<civodul>is it using the right libc?
<a_e>There is also a line such as
<a_e>open("/nix/store/jwd1hc3i3pmnsxf2347r4k2c77nbr9vw-glibc-2.18/lib/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
<civodul>that's ok