GNU bug report logs - #35181
Hydra offloads often get stuck while exporting build requisites

Previous Next

Package: guix;

Reported by: Mark H Weaver <mhw <at> netris.org>

Date: Sun, 7 Apr 2019 16:44:02 UTC

Severity: normal

Merged with 34157

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #34 received at 35181 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 35181 <at> debbugs.gnu.org
Subject: Re: bug#35181: Hydra offloads often get stuck while exporting build
 requisites
Date: Tue, 09 Apr 2019 12:56:20 +0200
Mark H Weaver <mhw <at> netris.org> skribis:

> Also of note: So far, all known instances of this problem have occurred
> while transferring a large directory, as opposed to a tarball.
>
> We have several packages with source tarballs _much_ larger than these
> problematic source checkouts, and which are updated more much
> frequently, and yet I've *never* seen an instance of this problem while
> exporting a plain file to a build slave.  For example, the upstream
> IceCat and Firefox ESR tarballs are ~270 megabytes compressed, whereas
> 'font-google-material-design-icons-3.0.1' source is only ~176 megabytes
> _uncompressed_.
>
> I have no explanation for why the superficial form of the store item
> should matter here, but maybe it's a clue.  I know that plain
> non-executable files in the store are handled somewhat differently in
> the Nix model than directories or executable files, the latter
> associated with the word "recursive", and requiring an additional layer
> of encoding for purposes of serialization, but I'm not sufficiently
> familiar with the details or relevant code.
>
> Ludovic, can you think of a reason why the file/directory distinction
> could be relevant to this issue?

No, I can’t see why it could make a difference.

Ludo’.




This bug report was last modified 2 years and 38 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.