Janneke Nieuwenhuizen writes: > Marius found that building the updated "guix" package on the > just-rebased hurd-team branch failed. > > It turns out that the packages.scm test on master fails notably: > package-transitive-supported-systems, implicit inputs > > test-name: package-transitive-supported-systems, implicit inputs > location: /home/janneke/src/guix/master/tests/packages.scm:496 > source: > + (test-equal > + "package-transitive-supported-systems, implicit inputs" > + %supported-systems > + (let ((p (dummy-package > + "foo" > + (build-system gnu-build-system) > + (supported-systems > + `("does-not-exist" "foobar" ,@%supported-systems))))) > + (parameterize > + ((%current-system "armhf-linux")) > + (package-transitive-supported-systems p)))) > expected-value: ("x86_64-linux" "mips64el-linux" "aarch64-linux" "powerpc64le-linux" "riscv64-linux" "i686-linux" "armhf-linux" "i586-gnu" "powerpc-linux") > actual-value: ("x86_64-linux" "mips64el-linux" "aarch64-linux" "powerpc64le-linux" "riscv64-linux" "i686-linux" "armhf-linux" "powerpc-linux") > result: FAIL I would say interesting, but I've struggled with the supported system stuff for years. The data service does use package-transitive-supported-systems, but in a very weird way. To check if a package supports a system, you call package-transitive-supported-systems with the package and system (as the second optional argument), then check if that system is present in the returned list. This is to say that in my uninformed opinion, the presence of the system which you pass to package-transitive-supported-systems in the returned list seems to mean something, but I wouldn't be able to say anything else about the returned value. I don't think there's anything wrong with adjusting the expectation to have the test pass, but to me the longer term thing to do is look at changing the code around supported systems. On not breaking tests when making changes though, I don't generally run make check unless I'm changing code in guix/ but it would be nice to start QA doing that for every patch series. We should also probably try to avoid tests that break when making changes to packages.