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 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