bug#44370: Cuirass fails building (some) packages from a custom-packages input

["Ludovic Courtès" <ludo@gnu.org>]

Hi Mathieu,

Mathieu Othacehe <othacehe@gnu.org> skribis:

>> Now, why is David’s use case influenced by the way (gnu ci) handles
>> licenses?
>
> David has some custom packages with the license set to "#f", causing the
> following backtrace:
>
> guix/inferior.scm:247:2: ERROR:
>   1. &inferior-exception:
>       arguments: (quit 1)
>       inferior: #<<inferior> pid: pipe socket: #<input-output: string
>       7f1b3d1dabd0> close: #<procedure close-pipe (p)> version: (0 1 1) 
> packages: #<promise #<procedure 7f1b3d1de940 at guix/inferior.scm:162:32 ()>>
> table: #<promise #<procedure 7f1b46b3a780 at guix/inferior.scm:163:32 ()>>>
>       stack: ((#f ("ice-9/boot-9.scm" 1763 13)) (raise-exception
>       ("ice-9/boot-9.scm" 1666 16)) (raise-exception ("ice-9/boot-9.scm" 1668 
> 16)) (map1 ("srfi/srfi-1.scm" 585 17)) (map1 ("srfi/srfi-1.scm" 585 29)) (map1
> ("srfi/srfi-1.scm" 585 29)) (map1 ("srfi/srfi-1.scm" 585 29)) (map1
> ("srfi/srfi-1.scm" 585 29)) (map1 ("srfi/srfi-1.scm" 585 29)) (map1
> ("srfi/srfi-1.scm" 585 29)) (map1 ("srfi/srfi-1.scm" 585 29)) (map1
> ("srfi/srfi-1.scm" 585 29)) (#f ("gnu/ci.scm" 552 38)) (map1
> ("srfi/srfi-1.scm" 585 17)) (append-map ("srfi/srfi-1.scm" 672 15)) 
> (hydra-jobs ("gnu/ci.scm" 516 4)) (#f ("ice-9/eval.scm" 158 9)) (#f
> ("ice-9/eval.scm" 158 9)) (with-exception-handler ("ice-9/boot-9.scm" 
> 1735 10)) (call-with-prompt ("ice-9/boot-9.scm" 717 2)) (dynamic-wind
> ("ice-9/boot-9.scm" 141 2)) (#f (#f #f #f)) (#f ("guix/repl.scm" 92 21)) 
> (with-exception-handler ("ice-9/boot-9.scm" 1735 10)) (with-exception-handler
> ("ice-9/boot-9.scm" 1730 15)) (#f ("guix/repl.scm" 119 7)))
>
> As the alist fields such as "description", "long-description",
> "license", "home-page", "maintainers" are ignored by Cuirass anyway,
> what would you think of removing them?
>
> This should allow custom packages to be built by Cuirass even if they
> are not fully defined.

Yes, I agree it would be nice to allow for that, but I think (gnu ci) is
maybe not the right place.  As I see it, (gnu ci) is meant to be used
for the packages that live in (gnu packages …).

Perhaps we could provide a more generic (guix ci jobs) module that would
convert packages and manifests to the alists that Cuirass expects,
without imposing much policy?

In fact, thinking about it, it might make sense for Cuirass to interpret
its inputs as channels so that it can do the directly build channels
similar to what ‘gnu-system.scm’ currently does.

Thanks,
Ludo’.