Subject: Re: bug#40650: guix test suite failures building Debian package

From: Vagrant Cascadian <[email-masked]>
Date: Fri, 21 Feb 2025 18:12:27 -0800

On 2025-02-21, Simon Tournier wrote:
> For reference: https://issues.guix.gnu.org/issue/40650
> On Sat, 18 Apr 2020 at 22:02, Ludovic Courtès <[email-masked]> wrote:
>>> actual-value: #f
>>> actual-error:
>>> + (match-error "match" "no matching pattern" #f)
>>> result: FAIL
>>
>> Same story here: if you provide a ‘bash’ other than Guix’ bash, this
>> test is bound to fail.
>
> What’s the status of this old bug?  It’s marked as moreinfo since 1
> year, 49 weeks, 3 days.

Great timing to be asking this question, as I have just refreshed the
packaging for Debian from a recent git snapshot of guix!

There are tons of failures on the Debian packaging. I mostly got
exhausted and just patched many of them out. And every new release, I
patch out more. And when build dependencies change in Debian, I
sometimes have to patch out even more though nothing has changed in the
guix source in Debian...

There are probably a few categories of issues:

* Tests that require network access fail, as Debian requires builds to
  not access the network during the build.

  They are typically patched out with:

    (unless (network-reachable?) (test-skip 1))

  These are arguably upstreamable.

* Effectively every test that depends on bootstrap binaries of one form
  or another requires network access, so are usually disabled in a
  similar way.

  These probably do not make sense to upstream, as bootstrap binaries
  can generally be assumed to be present when needed on Guix System or
  even a foreign distro install via guix-install.sh (I think?). But it
  might be nice to figure out a programmatic way to disable them with a
  build flag or enviuronment variable or something, so I do not need to
  patch all relevent tests!

  Many of the tests/*.sh also effectively are in this category, either
  directly or indirectly depending on bootstrap binaries, and are
  patched to be treated as "skip if no network".

* Architecture-specific failures, such as the one I commented on today:

    https://issues.guix.gnu.org/74862

  Could probably sum up that bug as: the page size of the architecture
  affects the results in some cases (e.g. /tmp on tmpfs).

* Debian-specific patches (e.g use the system guix-daemon, guix-publish,
  use the system locale, etc.).

  Probably fine to leave patched in Debian, although if anything could
  be made simpler by upstreaming it, so much the better!

* Broken things with "make dist" produced tarballs (e.g. missing
  po/doc/po4a.cfg, missing patches, etc.) and related yak-shaving.

  This obviously ought to get fixed upstream, and more regularly
  monitored somehow so that things are caught and fixed earlier rather
  than waiting for a release...

* Inscrutible (to me) failures. I suspect some current ones are due to
  Debian using guile 3.0.10 rather than older guile in guix (3.0.9?) or
  other build dependency or runtime versions that are skewed. I suspect
  the guile packages that Guix depends on that use C bindings
  (e.g. guile-zlib, guile-gnutls, etc.) may need to be rebuilt more
  often in Debian(something Guix handles by design). These need to be
  looked into by someone who knows what they are doing (e.g. Halp!) or
  at least finds different things to be inscrutible than me. :)

Unfortunately, I have done a poor job of categorizing all the different
patches that disable tests ... so this is a case of putting off work
creating more work. :/

For 1.4.0 the current set of disabled patches:

  https://salsa.debian.org/debian/guix/-/tree/debian/latest/debian/patches

I also just started working on an updated version based on a recent git
snapshot:

  https://salsa.debian.org/debian/guix/-/tree/debian/experimental/debian/patches?ref_type=heads

If someone was able to help upstream some of these patches in a useful
way, that would be great!

> Closing?

Maybe not?

Pretty sure the original issues are at best worked around, and are still
problems, although reviewing and properly categorizing which patches are
which would be a great project to tackle... and maybe, maybe some of
them are no longer needed!

Well, that sure turned into a longer email.

Thanks for prodding!

live well,
  vagrant