unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Vagrant Cascadian <vagrant@debian.org>
To: "Ludovic Courtès" <ludo@gnu.org>, guix-devel@gnu.org
Cc: Simon Josefsson <simon@josefsson.org>, rlb@defaultvalue.org
Subject: Re: Shepherd in Debian
Date: Sun, 29 Dec 2024 13:37:19 -0800	[thread overview]
Message-ID: <87ttamjhm8.fsf@wireframe> (raw)
In-Reply-To: <877c81ke4v.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2611 bytes --]

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.

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


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

  parent reply	other threads:[~2024-12-29 21:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-12 16:10 Shepherd in Debian Simon Josefsson via Development of GNU Guix and the GNU System distribution.
2024-12-12 17:25 ` Tobias Alexandra Platen
2024-12-15  0:01 ` Ludovic Courtès
2024-12-15  1:06   ` Simon Josefsson via Development of GNU Guix and the GNU System distribution.
2024-12-29 21:37   ` Vagrant Cascadian [this message]
2024-12-29 22:41     ` Simon Josefsson via Development of GNU Guix and the GNU System distribution.
2024-12-30 12:04       ` Pjotr Prins
2024-12-30 18:31       ` Rob Browning
2024-12-31 12:30         ` Simon Josefsson via Development of GNU Guix and the GNU System distribution.
2024-12-30 18:25     ` Rob Browning

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ttamjhm8.fsf@wireframe \
    --to=vagrant@debian.org \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    --cc=rlb@defaultvalue.org \
    --cc=simon@josefsson.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).