unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Vagrant Cascadian <vagrant@debian.org>
Cc: guix-devel@gnu.org
Subject: Re: Guix now in Debian experimental!
Date: Thu, 12 Nov 2020 22:32:35 +0100	[thread overview]
Message-ID: <87d00ifeh8.fsf@gnu.org> (raw)
In-Reply-To: <875z6atqic.fsf@yucca> (Vagrant Cascadian's message of "Thu, 12 Nov 2020 09:48:59 -0800")

Hi!

Vagrant Cascadian <vagrant@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’.


  parent reply	other threads:[~2020-11-12 21:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-12 17:48 Guix now in Debian experimental! Vagrant Cascadian
2020-11-12 18:19 ` Pierre Neidhardt
2020-11-12 21:32 ` Ludovic Courtès [this message]
2020-11-12 21:46 ` Christopher Lemmer Webber
2020-11-13  5:40 ` Jan Nieuwenhuizen
2020-11-14  2:51 ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d00ifeh8.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=vagrant@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).