Christopher Baines 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