Vagrant Cascadian writes: > On 2024-12-15, Ludovic Courtès wrote: >> Simon Josefsson via "Development of GNU Guix and the GNU System >> distribution." skribis: >>> Btw, running 'herd --help' prints a lot of warnings like below. Any >>> ideas where these come from and/or how to silence them? Salsa used >>> Guile 3.0.9 and my laptop has Guile 3.0.7, if that matters. >>> >>> ;;; WARNING: loading compiled file /usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/shepherd/scripts/herd.go failed: >>> ;;; In procedure load-thunk-from-memory: incompatible bytecode version >> >> That indicates a discrepancy between the Guile used to build the >> Shepherd and the one used at run time. Object files built by 3.0.9 (as >> is the case here) cannot be understood by 3.0.7. >> >> How’s that handled for other Guile packages in Debian? Vagrant must >> know. :-) > > In short, poorly. :( > > To avoid noise like that, it may require rebuilding the package, and the > usual detection mechanisms in Debian for things that require rebuilds > (e.g. ABI bumps in C libraries) do not appear to trigger in any way with > guile packages. I think my error can be written off because I installed the Debian packages on my Trisquel laptop. The packages are still in the NEW queue but I'll look into if any of these errors remain later on. > This seems especially important with packages that have guile bindings > to C libraries (e.g. guile-git, guile-ssh, guile-zlib, etc.) which may > break in even more significant ways. > > So, the only answer I have come up with is that I periodically rebuild > stuff when it seems like it breaks. > > I suspect a fair number of the test suite failures in the Debian > packages of Guix might be due to issues along these lines. Many of the > tests are disabled for good reason (e.g. network-dependent tests or > tests that assume bootstrap binaries are available) but honestly, many > of them are just disabled to keep me from pulling my hair out. :/ > > On a good day I am happy to keep Guix and the many necessary > guile-specific packages working in Debian! On a bad day I wonder pretty > hard if it is worth the effort. I maintain quite a few guile packages in > Debian, despite being at best ambivalent to guile itself. :) > > There was a big change in Debian recently where guile was downgraded > from 3.10.x back to 3.9.x. That was a little bit exciting. > > I am not sure how to better automate or detect that sort of thing... > Guix avoids ABI issues entirely by rebuilding everything whenever > anything in the dependency chain changes, and is also perhaps a > significant driver of Guile usage ... so I can see how this might be > deprioritized in cases where ABI actually matters, though most > distributions still do largely use ABI to limit rebuilds to only when > "necessary". For what it's worth, I am happy you do maintain Guix in Debian and find it useful, and on all Debian-derived machines I run I install Guix from packaging. When I packaged guile-fibers and shepherd one idea to me was that it would be nice with a Debian Guile Maintainers team to collaborate on Guile-related packages. All these packages share similar quirky hacks in debian/rules and I noticed the error messages and cut'n'pasted the same workarounds for them that everyone else has discovered. Would this help to bridge Debian and Guix a bit? If I had seen about the guile 3.0.10 32-bit bug earlier I could have some ideas, I'm struggling with fixing some low-level packages like priv-wrapper and socket-wrapper for i386/armhf too. It is really unfortunate if guile is stuck on 3.0.9 in Debian just because of i386/armhf issues. Or is there a Debian Guile group already that I don't know about? It would be nice if the subset of people who know Guile and Debian packaging could collaborate more easily.. is talking about that on guile-devel appropriate, or should we ask for a debian-guile@lists.debian.org? Assuming we can do an inventory of guile-* maintainers in Debian and large number of them think it is a good idea. /Simon