[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guix now in Debian experimental!

From: Ludovic Courtès
Subject: Re: Guix now in Debian experimental!
Date: Thu, 12 Nov 2020 22:32:35 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)


Vagrant Cascadian <> skribis:

> It's been a long haul getting all the build dependencies of guix into
> Debian, but it has finally paid off:
> 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:
> 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):

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:

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:

Could be an option!

> It actually builds on both amd64 and i386 with some of the above
> mentioned tests disabled:
> 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:

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!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]