[Cuirass] Doesn't honor 'timeout' nor 'max-silent-time' leading to mising substitutes

DoneSubmitted by Brice Waegeneire.
Details
4 participants
  • Brice Waegeneire
  • Leo Famulari
  • Ludovic Courtès
  • Mathieu Othacehe
Owner
unassigned
Severity
normal
B
B
Brice Waegeneire wrote on 2 Jun 2020 15:15
(address . bug-guix@gnu.org)
095b8c544efa2b37c1ff385a9fca0760@waegenei.re
Hello Guix,

Unlike Hydra, Curiass don't honor 'timeout' and 'max-silent-time'
properties[0]. This lead to some packages never having substitutes, in
particular for the 'armhf-linux' system for example 'linux-libre' or
'guile-static-stripped'[1]. Which mean it's really difficult to use such
systems since each users need to build thoses really long running[2]
packages. We also don't know if thoses package may fail for a reason
other
than timing out.

[1]:
[2]:

- Brice
L
L
Leo Famulari wrote on 2 Jun 2020 19:44
(name . Brice Waegeneire)(address . brice@waegenei.re)(address . 41661@debbugs.gnu.org)
20200602174459.GC19317@jasmine.lan
On Tue, Jun 02, 2020 at 01:15:19PM +0000, Brice Waegeneire wrote:
Toggle quote (16 lines)
> Hello Guix,
>
> Unlike Hydra, Curiass don't honor 'timeout' and 'max-silent-time'
> properties[0]. This lead to some packages never having substitutes, in
> particular for the 'armhf-linux' system for example 'linux-libre' or
> 'guile-static-stripped'[1]. Which mean it's really difficult to use such
> systems since each users need to build thoses really long running[2]
> packages. We also don't know if thoses package may fail for a reason other
> than timing out.
>
> [0]: https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00209.html
> [1]: http://ci.guix.gnu.org/search?query=guile-static-stripped%20system:armhf-linux
> [2]: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/guile.scm?id=f51fd97ec54a98668d63c52d8a6bd75d8dc3292e#n257
>
> - Brice

We really need to improve our CI so that it's possible to discover these
build failures. Currently it's quite hard to monitor if they get built
unless you just do `guix build foo`.

The last time this came up [0] it was said that maybe it's not really
correct to make these properties of the package, but rather of the CI
jobs. It makes sense but we need a solution, or stop supporting
underpowered architectures like armhf, because most of those machines
can't build this stuff themselves, and it's not good to advertise
support to people who will just be disappointed later.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAl7WkBgACgkQJkb6MLrK
fwj1Ng/9FyZmUNB+++ec5Nz0zCHjSg05Tt7tMyu3+p0QAhAq9AeHKQ06ZVFh14Fi
OUhU/bBFd2RiPuyLaWi6wXcZSVaOTvJKG4LGbiXyqp/nknO+aB0pMNxsPLh0vFZa
rtTNnZ72gKUN2WhAL2QLr9Ee4GCMKYD4enKBSXVCCpQvM8VfnETsdyC3SKfTCwiZ
SoNuiWk3CQTCgJITaQRwxmag0Fi2ALo3xcXpPkVif2lpCPD+fqz2mt1IoESf4DvF
BTqtUWIUXhqQTLj9VJcMBlT/Un0bD4N1Pbub6YWxNzQyRA3CQIaRfY9FrXUm4bRg
l1JjS/8XXhpbEfXBUI8LMkGmCJn5nJbaqPQkxXDAr3K24r3hRwl4l+4M7RHWAi04
+XSEwYSqA8WlVaDbLn87IMmQi84tBfwX7H59NA2FCxLHQnNVsojZVxjGw7aC18nt
+ilQ2weUfq0uaTLBbD4pwmDKZt1t64qGQMphAxDlParYENFrd4ViZnelUvR30dh8
fHzu0D08+o5Kj32AszTR0wMJsh2U3HXGL8LXSjSgNNNniKNmXohNU5S3Dz9uyPPG
OgTvIdrEKqN8XZQaub3nTg9OiO0hfX6qZfjAjJQBrBMr8BrJbEZees2evUMSG/wW
i7Zlq2u0URvoSsQzngpA1FYspXLQdsWRMX9flxT3RTCInjdRQrw=
=YA4p
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 4 Jun 2020 14:16
(name . Leo Famulari)(address . leo@famulari.name)
87mu5jauvq.fsf@gnu.org
Hi,

Leo Famulari <leo@famulari.name> skribis:

Toggle quote (4 lines)
> We really need to improve our CI so that it's possible to discover these
> build failures. Currently it's quite hard to monitor if they get built
> unless you just do `guix build foo`.

Or ‘guix weather’, which is not worse than a web UI IMO.

Toggle quote (7 lines)
> The last time this came up [0] it was said that maybe it's not really
> correct to make these properties of the package, but rather of the CI
> jobs. It makes sense but we need a solution, or stop supporting
> underpowered architectures like armhf, because most of those machines
> can't build this stuff themselves, and it's not good to advertise
> support to people who will just be disappointed later.

Yeah. I think we need to look at these on a case-by-case basis. Guile
is one of those packages known to hit the max-silent-time of 1h (?)
that’s configured on berlin. Hopefully it will no longer be the case
starting from 3.0.3.

What about Linux-libre? Does it hit the max absolute build time on
armhf?

As I wrote elsewhere, I think it makes more sense in a way to have
those timeouts configured system-wide. But yeah, we need to be
pragmatic.

Thanks,
Ludo’.
B
B
Brice Waegeneire wrote on 4 Jun 2020 15:02
(name . Ludovic Courtès)(address . ludo@gnu.org)
eca4f8cc0d9d0efabf89318eac0f1fb8@waegenei.re
Hello,

On 2020-06-04 12:16, Ludovic Courtès wrote:
Toggle quote (11 lines)
> Hi,
>
> Leo Famulari <leo@famulari.name> skribis:
>
>> We really need to improve our CI so that it's possible to discover
>> these
>> build failures. Currently it's quite hard to monitor if they get built
>> unless you just do `guix build foo`.
>
> Or ‘guix weather’, which is not worse than a web UI IMO.

+1 for CLI tools!

Toggle quote (15 lines)
>> The last time this came up [0] it was said that maybe it's not really
>> correct to make these properties of the package, but rather of the CI
>> jobs. It makes sense but we need a solution, or stop supporting
>> underpowered architectures like armhf, because most of those machines
>> can't build this stuff themselves, and it's not good to advertise
>> support to people who will just be disappointed later.
>
> Yeah. I think we need to look at these on a case-by-case basis. Guile
> is one of those packages known to hit the max-silent-time of 1h (?)
> that’s configured on berlin. Hopefully it will no longer be the case
> starting from 3.0.3.
>
> What about Linux-libre? Does it hit the max absolute build time on
> armhf?

I misdiagnosed the issue, substitutes for it are available now and
previous
seems to be there too. IDK why it wasn't available before nor why I
couldn't manage to built it myself.

Toggle quote (7 lines)
> As I wrote elsewhere, I think it makes more sense in a way to have
> those timeouts configured system-wide. But yeah, we need to be
> pragmatic.
>
> Thanks,
> Ludo’.

- Brice
M
M
Mathieu Othacehe wrote on 25 Mar 2021 14:02
(address . 41661-done@debbugs.gnu.org)
875z1f5quu.fsf@gnu.org
Hello,

Cuirass now honors those properties, closing this one.

Thanks,

Mathieu
Closed
?
Your comment

This issue is archived.

To comment on this conversation send email to 41661@debbugs.gnu.org