[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal: prefetch tarballs in a batch

From: Ludovic Courtès
Subject: Re: Proposal: prefetch tarballs in a batch
Date: Thu, 08 May 2014 18:35:48 +0200
User-agent: Gnus/5.130009 (Ma Gnus v0.9) Emacs/24.3 (gnu/linux)

Nikita Karetnikov <address@hidden> skribis:

>> The SRFI-64 log files of the failing tests, plus test-suite.log.  Test
>> failures must not remain uncorrected!  ;-)
> Attached.


>> What Guile and libgc version is this, and what platform?
> 2.0.9; 1:7.1-8ubuntu0.12.04.1 (from Trisquel); i686.
>> Does the installation seem sane, basically?  Do ‘guix build’, ‘guix
>> package’ etc. work somehow, or not even?
> Turns out I can’t even build ‘hello’

Please say exactly why you “can’t”.

> (though the build succeeded in the logs).  I didn’t expect this
> because Guix had worked on this machine previously.  IIRC, I did the
> following: deleted ‘/gnu/store’ and ‘/usr/local/var/guix/*’, cloned,
> and ran ‘./bootstrap’ & co.

Why the hell do you keep deleting the store?  :-)

>> substitute-binary: warning: authentication and authorization of substitutes 
>> disabled!
> How can I enable them?  Are they specifically disabled for testing
> purposes?

Exactly, see

>> SQLite header and source version mismatch
>> 2011-11-01 00:52:41 c7c6050ef060877ebe77b41d959e9df13f8c9b5e
>> 2013-09-03 17:11:13 7dd4968f235d6e1ca9547cda9cf3bd570e1609ef
> This was discussed before and should be fixed by upgrading SQLite.

OK.  Can you report how things go one that is fixed?

> Test end:
>   result-kind: fail
>   actual-value: #f
>   actual-error: (srfi-34 #<condition &nix-protocol-error [message: "closing 
> file descriptor 1599602736: Bad file descriptor" status: 1] 8a62798>)

That one occurs many times.  I suspect this has to do with the daemon
features enabled by c0412fedf, though I don’t see which one.

Could you try to:

  1. Run ‘git show c0412fedf | patch -p1 -R’, and then confirm that the
     problem disappears.

  2. Run ‘git reset --hard’, edit config.h, and comment out the HAVE_
     macros corresponding to the functions listed in c0412fedf, one at a

     Alternately, you could strace guix-daemon to see where EBADF comes

     Or, even better, run guix-daemon in gdb, run ‘catch throw’, and get
     a backtrace of the thing that throws.

We can chat on IRC to help.

Thanks in advance,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]