guix-devel
[Top][All Lists]
Advanced

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

Re: guix weather exit status?


From: Ludovic Courtès
Subject: Re: guix weather exit status?
Date: Sat, 10 Jul 2021 16:41:44 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hi!

Leo Famulari <leo@famulari.name> skribis:

> When a substitute is not available for all specified substitute servers,
> `guix weather` exits with a return code of '1', signaling failure.
>
> For example:
>
> ------
> $ ./pre-inst-env guix weather linux-libre; echo $?
> computing 1 package derivations for x86_64-linux...
> looking for 1 store items on http://ci.guix.gnu.org...
> http://ci.guix.gnu.org
>   100.0% substitutes available (1 out of 1)
>   at least 234.8 MiB of nars (compressed)
>   86.3 MiB on disk (uncompressed)
>
>   38 queued builds
>       aarch64-linux: 31 (81.6%)
>       powerpc64le-linux: 1 (2.6%)
>       armhf-linux: 1 (2.6%)
>       i686-linux: 5 (13.2%)
>   build rate: .00 builds per hour
>       x86_64-linux: 0.00 builds per hour
>       aarch64-linux: 0.00 builds per hour
>       i686-linux: 0.00 builds per hour
> looking for 1 store items on http://bordeaux.guix.gnu.org...
> http://bordeaux.guix.gnu.org
>   0.0% substitutes available (0 out of 1)
>   unknown substitute sizes
>   0.0 MiB on disk (uncompressed)
>   (continuous integration information unavailable)
> 1
> ------
>
> I expected it to return successfully because a substitute is available,
> but I see that it could also make sense if "success" means that a
> substitute is available from all servers.

Quoth the manual (info "(guix) Invoking guix weather"):

  ‘guix weather’ exits with a non-zero code when the fraction of
  available substitutes is below 100%.

> However, the current behaviour breaks the use case of "wait until a
> substitute is available and then download it", like this for example:
>
> $ while true; do guix weather linux-libre && break; sleep 600; done; guix 
> build --no-grafts linux-libre
>
> I'm not sure if this topic was discussed previously... your thoughts?

I agree we could change (or rather refine) semantics to exit with
non-zero when overall coverage is below 100%.  In the example above, it
should return 0.

Thanks,
Ludo’.



reply via email to

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