Hi! Vagrant Cascadian <vagr...@debian.org> skribis:
> It's been a long haul getting all the build dependencies of guix into > Debian, but it has finally paid off: > > https://tracker.debian.org/pkg/guix > > So now you can install guix from Debian's experimental distribution! Yay! Quite an achievement, thumbs up, party time! :-) > There are many tests that make use of bootstrap binaries which attempt > to download them during running the tests, despite networking not being > available. I have patched these tests to also not run when the network > is unreachable: > > https://salsa.debian.org/debian/guix/-/tree/debian/devel/debian/patches > > My guess is these bootstrap binaries are available as inputs during the > guix package builds of guix? Yes, there’s a phase that copies the bootstrap Guile tarball and the bootstrap executables (bash, mkdir, tar, and xz): https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/package-management.scm#n225 More precisely, it adds them to the temporary store used for the tests, in a way that’s similar to “guix download file://$PWD/mkdir” etc. That way, running “./test-env guix build guile-bootstrap” won’t try to download ‘guile-bootstrap-2.0.tar.xz’ because it’ll notice that it’s already in store, with the right hash. Those binaries are listed as inputs further below: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/package-management.scm#n375 On IRC I mentioned that perhaps you could use Debian’s /bin/mkdir etc., but I was wrong: the hashes really all have to match those that appear in gnu/packages/bootstrap.scm. > I've also patched out a few tests that seemed non-deterministic, and a > few that were simply inscrutible as to why they failed. Probably need to > file bugs about those at some point... :) Yup. :-) > In all, this ends up disabling about 200 out of 1100 tests in the Debian > packages. I will explore another option to run those tests outside of > the build, where network can be used, against the installed package > using: > > https://ci.debian.net Could be an option! > > It actually builds on both amd64 and i386 with some of the above > mentioned tests disabled: > > https://buildd.debian.org/status/package.php?p=guix&suite=experimental > > On armhf (ARMv7), it successfully built, but failed some test suites > that passed on amd64/i386. > > On armel (ARMv4t?), where it probably shouldn't even attempt to build, > it failed in the same way it failed on armhf... > > On arm64, guile-gnutls isn't available for guile-3.0, so it cannot > build: > > https://bugs.debian.org/966714 Bah. :-/ > An alternative would be to build guix against guile-2.2, which has > guile-gnutls, although I did manage to find... more test suite failures > on guile-2.2 (tests/lint.scm), including one which seemed to run > indefinitely(tests/swh.scm), an infinitely thorough test! > > If the guile-gnutls issues do not get sorted out soon, building against > guile-2.2 is a plausible backup plan for getting guix 1.2 into the next > Debian release (speculated to be released mid 2021)... Do you think Andreas (or you?) could give us the backtrace of the GnuTLS test that hangs? > For other architectures, it would require considerably more courage, > though there has been work on a few of those architectures in guix > recently (e.g. hurd-i386, mips64el, powerpc, ppc64, ppc64el, and even > talk of riscv64). Would it be interesting to run guix on one of the > more exotic architectures, Debian GNU/kFreeBSD? :) It would! But that’d also meaning porting Guix (the packages) there. :-) > Well, thanks for reading the status update from your entirely unofficial > Debian-Guix or Guix-Debian ambassador. Congrats on your diplomatic efforts, dear ambassador, and a huge thank you! Ludo’.
