Re: Shepherd in Debian

[Simon Josefsson]

Vagrant Cascadian <vagrant@debian.org> writes:

> On 2024-12-15, Ludovic Courtès wrote:
>> Simon Josefsson via "Development of GNU Guix and the GNU System
>> distribution." <guix-devel@gnu.org> 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

signature.asc
Description: PGP signature