Christopher Baines <[email protected]> writes: > To confirm that this is an issue with the supported systems as reported > by Guix, I had the data service print out the transitive supported > systems for the guix package: > > debug: Starting getting derivations for (i686-linux . #f) > looking at guix package (supported systems: (), system supported: #f, > target supported: #t > debug: Finished getting derivations for (i686-linux . #f), took 12 seconds > > debug: Starting getting derivations for (armhf-linux . #f) > looking at guix package (supported systems: (), system supported: #f, > target supported: #t > debug: Finished getting derivations for (armhf-linux . #f), took 41 seconds
I realised that this could be non-deterministic because the order in
which the data service processes derivations is non-deterministic, from
the order of the systems returned by (guix platforms).
That led me to a reproducer:
(use-modules (gnu packages) (guix packages) (gnu packages package-management))
(fold-packages (lambda (pkg result)
(package-transitive-supported-systems pkg "i586-gnu")
#f)
#f)
(peek "guix package supported systems" (package-transitive-supported-systems
guix "i686-linux"))
If you look at the %final-inputs packages, there's an issue with libc:
(use-modules (ice-9 match)
(gnu packages) (guix packages) (gnu packages package-management)
(gnu packages commencement))
(fold-packages (lambda (pkg result)
(package-transitive-supported-systems pkg "i586-gnu")
#f)
#f)
(for-each
(match-lambda
((name pkg rest ...)
(peek name
(package-transitive-supported-systems
pkg
"i686-linux"))))
(%final-inputs "i686-linux"))
I think this could be because %final-inputs is cached based on system,
but doesn't seem to use system. Setting %current-system to system seems
to help, so I've sent a patch for that [1].
1: https://issues.guix.gnu.org/64763
signature.asc
Description: PGP signature
