GNU bug report logs -
#40650
guix test suite failures building Debian package
Previous Next
Full log
Message #40 received at 40650 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <ludo <at> gnu.org> 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
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 111 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.