Heya,
Mark H Weaver writes:
> merge 35181 34157
> thanks
I'm closing this old forgotten issue since we are no longer using
hydra. Let's focus on our guix deploy/offload and cuirass-related
problems :-).
--
Thanks,
Maxim
Hi Ludovic,
Ludovic Courtès writes:
> The problem is that this is an ancient Guix. In the meantime,
> offloading has seen relevant changes, in particular things like commit
> ed7b44370f71126087eb953f36aad8dc4c44109f which address stability issues
> with Guile-SSH (ssh dist node) that was previo
Mark H Weaver 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 m
Hi Mark,
Mark H Weaver skribis:
> Ludovic Courtès writes:
>
>> Mark H Weaver skribis:
>>
>>> The source checkout currently being transferred for build 3432472
>>> (/gnu/store/…-font-google-material-design-icons-3.0.1-checkout) is 176
>>> megabytes uncompressed, as measured by "du -s --si", whi
merge 35181 34157
thanks
I looked more closely at the 'mozjs-60' failures, and I'm convinced that
it's an instance of the same problem that's currently affecting these
large font builds.
Mozjs-60 was pushed to the master branch on 2019-01-18. It has _never_
successfully built on x86_64 or i686,
Hi Ludovic,
Ludovic Courtès writes:
> Mark H Weaver skribis:
>
>> The source checkout currently being transferred for build 3432472
>> (/gnu/store/…-font-google-material-design-icons-3.0.1-checkout) is 176
>> megabytes uncompressed, as measured by "du -s --si", which is not
>> precisely same as
Hi Mark,
Mark H Weaver skribis:
> The source checkout currently being transferred for build 3432472
> (/gnu/store/…-font-google-material-design-icons-3.0.1-checkout) is 176
> megabytes uncompressed, as measured by "du -s --si", which is not
> precisely same as NAR size, but hopefully close enoug
The same jobs that are consistently getting stuck offloading to
hydra.gnunet.org (Hydra's only functional x86 build slave at present)
built successfully on armhf, with build times of 1-2 hours.
With only one x86 build slave and all armhf build slaves on the same
network and running the same ancien
Hi Efraim,
Efraim Flashner writes:
> For these two specifically it's possible that they are just really
> really big.
The source checkout currently being transferred for build 3432472
(/gnu/store/…-font-google-material-design-icons-3.0.1-checkout) is 176
megabytes uncompressed, as measured by "d
On Sun, Apr 07, 2019 at 12:45:57PM -0400, Mark H Weaver wrote:
> I wrote earlier:
>
> > It has become extremely frequent for builds offloaded by hydra.gnu.org
> > to its x86 build slave hydra.gnunet.org to get stuck indefinitely while
> > exporting prerequisites for the build to the build slave.
>
I wrote earlier:
> It has become extremely frequent for builds offloaded by hydra.gnu.org
> to its x86 build slave hydra.gnunet.org to get stuck indefinitely while
> exporting prerequisites for the build to the build slave.
>
> As I write this, both of hydra.gnunet.org's build slots (one for
> x8
It has become extremely frequent for builds offloaded by hydra.gnu.org
to its x86 build slave hydra.gnunet.org to get stuck indefinitely while
exporting prerequisites for the build to the build slave.
As I write this, both of hydra.gnunet.org's build slots (one for
x86_64-linux, and one for i686-l
12 matches
Mail list logo
