guix-devel
[Top][All Lists]
Advanced

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

Re: Guix on aarch64


From: Ludovic Courtès
Subject: Re: Guix on aarch64
Date: Fri, 24 Aug 2018 12:32:38 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hello Mark,

Mark H Weaver <address@hidden> skribis:

> If I'm not mistaken, I believe I have confirmed with the test below that
> a substitute for binutils from early commencement on aarch64 is not
> available on berlin.

[...]

> It occurs to me that on Hydra, I have implemented a system to ensure
> that *all* derivations from a certain set of _evaluations_ (the most
> recent release and the last two weeks of 'master' evaluations) are
> permanently kept as GC roots, regardless of how long ago they were
> built.  Among other things, this ensures that even the early
> commencement derivations are kept even if they were built a long time
> ago.
>
> Berlin.guixsd.org may not have any similar mechanism in place.  It may
> still be using the old policy, where old GC roots are deleted based
> solely on their timestamps in the filesystem, which indicate when the GC
> root symlinks were first installed, long ago during the last core
> updates build-out.  This could result in the early commencement
> derivations and corresponding outputs being deleted prematurely.

Correct.  Berlin uses ‘guix publish’ with a TTL of 45 days: if a nar is
not requested within 45 days, and if its corresponding store item was
GC’d in the meantime, it disappears.

I think there are two problems that made that happen: our two aarch64
build machines have been offline for several weeks so nothing new gets
built, and aarch64 substitutes are probably unpopular and thus more
likely to disappear given the above policy.

We’ll probably need a mechanism similar to what Hydra and you are doing
on hydra.gnu.org, to explicitly retain derivations from certain
evaluations; we can implement that in Cuirass.

In addition, Ricardo has a plan to throw more storage at berlin (we
currently have 1TB for the store).  That would allow us to increase the
TTL and generally worry less, though it’s no substitute for the GC root
mechanism above.

(That said, the error Benjamin reported appears to be a build failure,
which is surely worth investigating in its own right.)

Thanks,
Ludo’.



reply via email to

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