GNU bug report logs -
#71729
Emacs 29.4 emergency bugfix release
Previous Next
Reported by: Adam Porter <adam <at> alphapapa.net>
Date: Sun, 23 Jun 2024 00:55:01 UTC
Severity: normal
Done: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#71729: Emacs 29.4 emergency bugfix release
which was filed against the guix package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 71729 <at> debbugs.gnu.org.
--
71729: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71729
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Am Samstag, dem 22.06.2024 um 19:52 -0500 schrieb Adam Porter:
> Hello,
>
> Today an emergency bugfix release was made of Emacs v29.4. It fixes
> an important security vulnerability.
Note: Security bugs should go to guix-security instead. But thanks for
pointing out the new Emacs release, I've pushed an update. (Thus
marking this done)
> 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.
> And despite my best efforts at comparing the emacs.git tags for 29.3
> and 29.4 to look for any relevant changes, and digging through the
> relevant source code, and scanning through the build logs, I can't
> find a cause for this problem.
>
> Is this failure expected? If so, is it something unique to the Emacs
> packaging, and could it be fixed? (Before Emacs 28 was released, I
> was able to use a similar "--with-commit" option to build and install
> what was then the emacs-next package to get native-compilation
> support, keeping it updated with Emacs's master branch at the time.
> It would be helpful if that could still be used by users rather than
> having to wait for an update to the package definition, especially in
> a case like this.)
I understand your pain, but I doubt there is a reasonable fix to this.
Perhaps the check should honour tests?, but then you'd disable all the
other tests as well as part of the build. Maybe a --without-phase
option to the Guix CLI would be better?
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'.
Cheers
[Message part 3 (message/rfc822, inline)]
Hello,
Today an emergency bugfix release was made of Emacs v29.4. It fixes an
important security vulnerability.
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.
And despite my best efforts at comparing the emacs.git tags for 29.3 and
29.4 to look for any relevant changes, and digging through the relevant
source code, and scanning through the build logs, I can't find a cause
for this problem.
Is this failure expected? If so, is it something unique to the Emacs
packaging, and could it be fixed? (Before Emacs 28 was released, I was
able to use a similar "--with-commit" option to build and install what
was then the emacs-next package to get native-compilation support,
keeping it updated with Emacs's master branch at the time. It would be
helpful if that could still be used by users rather than having to wait
for an update to the package definition, especially in a case like this.)
Thanks for your work on Emacs in Guix.
--Adam
This bug report was last modified 1 year and 56 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.