bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#71729: Emacs 29.4 emergency bugfix release


From: Liliana Marie Prikler
Subject: bug#71729: Emacs 29.4 emergency bugfix release
Date: Thu, 27 Jun 2024 21:27:23 +0200
User-agent: Evolution 3.48.4

Hi Adam,

Am Donnerstag, dem 27.06.2024 um 08:57 -0500 schrieb Adam Porter:
> Thanks.
> 
> If I may ask here, as it seems relevant and might help other users in
> the future:
> 
> A few minutes ago I ran "guix pull", but after it finished, "guix
> show emacs" still shows:
> 
>    name: emacs
>    version: 29.3
> 
> Am I missing something?  e.g. the equivalents in Debian, like "apt
> show emacs" or "apt policy emacs", show both installed and available
> versions.
You're missing the graft, which apparently does not show up in "guix
show".  

> So as a user, how am I to know whether I'm using the latest version
> of a package?  I also tried "guix upgrade -n" (which updates
> substitute lists from the network, which can significantly delay its
> finishing for a simple check like this), and it shows:
> 
>    The following packages would be upgraded:
>     emacs             (dependencies or package changed)
> 
> But maybe that's affected by the workaround I'm using (see below).
FWIW, with emacs you can check (emacs-version).  More generally, this
is a bug – replacements ought to be announced somehow.

> > > FWIW, I had hoped that I could install it by running:
> > > 
> > >     guix install --with-version=emacs=29.4 emacs
> > > 
> > > But that fails the validate-comp-integrity phase, showing that
> > > all of
> > > its tests fail, with every function being loaded in byte-compiled
> > > form instead of native-compiled.
> 
> > Ah, yes, that is not something you can do with --with-version, as
> > it
> > disregards our patches and everything.
> 
> Ah, I wish I had known that.  FWIW, looking at 
> <
> https://guix.gnu.org/manual/en/html_node/Package-Transformation-Option
> s.html>, I can't even find "--with-version" documented at all.  But
> besides that, none of them seem to explain that such options may
> discard parts of the package definition, such as patches (if any of
> those other options do--is it only "--with-version" that does?). 
> Does a documentation bug need to be filed about this?
The info manual (which you can read locally) has both, as well as the
warning you seek.

> > As for how to work around this, you can do a more elaborate package
> > definition:
> > 
> >    (package
> >      (inherit emacs)
> >      (version NEW_VERSION)
> >      (source (origin (inherit (package-source emacs))
> >                      (uri NEW_URI))))
> > 
> > This should automatically apply our patches.  Or, you can locally
> > run `guix refresh -u emacs'.
> 
> Thanks for the pointer.  I defined a package called "emacs-jit" (and
> a corresponding "emacs-minimal-jit") that comments out the
> JIT-disabling patches, so that I can still JIT-compile packages
> installed through Emacs, and it seems to be working fine.
> 
> Would you be willing to accept some kind of package definition like
> that being added to Guix, as an alternative to the main "emacs"
> package? (I won't quibble over the name.)  I think that there are a
> significant number of users who would like to use Guix to keep Emacs
> up-to-date without sacrificing the ability to native-compile packages
> installed from within Emacs.  It would be nice to have this in Guix
> so that I wouldn't have to manually update the package definition
> according to upstream changes.
But then you'd be shifting the maintenance burden to us Guix.  We
already have enough Emacs variants to keep track of as-is, and adding
yet another orthogonal angle is not going to scale well.  Plus, for
this variant you'd lose all the benefits that Guix provides – I don't
see this as a reasonable thing to ship, to be honest.

Cheers





reply via email to

[Prev in Thread] Current Thread [Next in Thread]