Emacs 29.3 released

Emacs 29.3 released

[Eli Zaretskii]

Hi!

Version 29.3 of Emacs, the extensible text editor, should now
be available from your nearest GNU mirror:

   https://ftpmirror.gnu.org/emacs/emacs-29.3.tar.xz
   https://ftpmirror.gnu.org/emacs/emacs-29.3.tar.gz

The tarballs are signed; you can get the corresponding PGP signature
files at:

   https://ftpmirror.gnu.org/emacs/emacs-29.3.tar.xz.sig
   https://ftpmirror.gnu.org/emacs/emacs-29.3.tar.gz.sig

You can choose a mirror explicitly from the list at:
  https://www.gnu.org/prep/ftp.html

Mirrors may take some time to update; the main GNU ftp server is at:
  https://ftp.gnu.org/gnu/emacs/

To verify that the downloaded tarball is intact, download both the
tarball and the corresponding .sig file, and run this command:

  gpg --verify emacs-29.3.tar.xz.sig

(and similarly for emacs-29.3.tar.gz, if you download that format).

If the GPG command fails because you don't have the required PGP
public key, run this command to import the key:

  gpg --keyserver keyserver.ubuntu.com --recv-keys \
    17E90D521672C04631B1183EE78DAE0F3115E06B

Alternative keyservers to try are pgp.mit.edu and keys.openpgp.org.

You can also run sha1sum or sha256sum and confirm that these
checksums match:

SHA1 emacs-29.3.tar.gz
8000d5e99a568d985d04da8e94977f835e9ae932
SHA1 emacs-29.3.tar.xz
876fe639e4841c29550d94ed869f1d6754626002

SHA256 emacs-29.3.tar.gz
2de8df5cab8ac697c69a1c46690772b0cf58fe7529f1d1999582c67d927d22e4
SHA256 emacs-29.3.tar.xz
c34c05d3ace666ed9c7f7a0faf070fea3217ff1910d004499bd5453233d742a0

Emacs 29.3 is an emergency bugfix release; it includes no new features
except a small number of changes intended to resolve security
vulnerabilities uncovered in Emacs 29.2.  See the file etc/NEWS in the
tarball; you can view it from Emacs by typing 'C-h n', or by clicking
Help->Emacs News from the menu bar.

You can also browse NEWS on-line using this URL:

  https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-29

For the complete list of changes and the people who made them, see the
various ChangeLog files in the source distribution.  For a summary of
all the people who have contributed to Emacs, see the etc/AUTHORS
file.

For more information about Emacs, see:
  https://www.gnu.org/software/emacs

Re: Emacs 29.3 released

[Corwin Brust]

Hi Eli :)

On Sun, Mar 24, 2024 at 9:14 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> The tarballs are signed; you can get the corresponding PGP signature
> files at:
>
>    https://ftpmirror.gnu.org/emacs/emacs-29.3.tar.xz.sig
>    https://ftpmirror.gnu.org/emacs/emacs-29.3.tar.gz.sig
>

I have been working on creating the WIndows binary distributions for
Emacs 29.3.  I typically make these using AOT native compilation (for
the benefit of users without libgccjit etc) however I'm not able to
get that to happen using the emacs-29.3 release tarball.

This is my configure + build formula:

./configure --with-modules --without-dbus
--with-native-compilation=aot --without-compress-install
--with-sqlite3 --with-tree-sitter CFLAGS=-O2 && make install V=1 -j 20
NATIVE_FULL_AOT=1 prefix=/rel/build/emacs-29.3 2>&1 | tee
../emacs-29.3_1.log

But I see relatively few ELN files:

  $ (cd /rel/build/emacs-29.3; find ./ -name '*.eln' | wc -l)
  155

Compare this with the number of ELN files when I build the emacs-29
branch from git (using ./configac && configure && make, rather than a
tarball provided configure script).

  $ (cd $( ls -1trd /h/install/emacs-30* | tail -1 ); find ./ -name
'*.eln' | wc -l)
  1589

Can you see something I'm doing wrong, or might there be a problem
here which prevents with-native-compilation=aot from doing it's thing
for a build from a release tarball?

Re: Emacs 29.3 released

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Sun, 24 Mar 2024 12:52:21 -0500
> Cc: emacs-devel@gnu.org
> 
> I have been working on creating the WIndows binary distributions for
> Emacs 29.3.  I typically make these using AOT native compilation (for
> the benefit of users without libgccjit etc) however I'm not able to
> get that to happen using the emacs-29.3 release tarball.
> 
> This is my configure + build formula:
> 
> ./configure --with-modules --without-dbus
> --with-native-compilation=aot --without-compress-install
> --with-sqlite3 --with-tree-sitter CFLAGS=-O2 && make install V=1 -j 20
> NATIVE_FULL_AOT=1 prefix=/rel/build/emacs-29.3 2>&1 | tee
> ../emacs-29.3_1.log
> 
> But I see relatively few ELN files:
> 
>   $ (cd /rel/build/emacs-29.3; find ./ -name '*.eln' | wc -l)
>   155
> 
> Compare this with the number of ELN files when I build the emacs-29
> branch from git (using ./configac && configure && make, rather than a
> tarball provided configure script).
> 
>   $ (cd $( ls -1trd /h/install/emacs-30* | tail -1 ); find ./ -name
> '*.eln' | wc -l)
>   1589
> 
> Can you see something I'm doing wrong, or might there be a problem
> here which prevents with-native-compilation=aot from doing it's thing
> for a build from a release tarball?

I have no idea.  Comparing the configure script for Emacs 29.2 and
Emacs 29.3 doesn't show any differences, and neither does comparing
the various Makefile's.

If you build Emacs 29.2 in this manner, do you get all the *.el files
compiled into *.eln, or do you see the same problem with Emacs 29.2?
If the latter, perhaps the reason has nothing to do with the new
tarball, but with something else on your system?

One note, though: if you say --with-native-compilation=aot, you don't
need the NATIVE_FULL_AOT=1 part.  Not sure if this is relevant or not.

Re: Emacs 29.3 released

[Corwin Brust]

On Sun, Mar 24, 2024 at 1:46 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Corwin Brust <corwin@bru.st>
> > Date: Sun, 24 Mar 2024 12:52:21 -0500
> > Cc: emacs-devel@gnu.org
> > Can you see something I'm doing wrong, or might there be a problem
> > here which prevents with-native-compilation=aot from doing it's thing
> > for a build from a release tarball?
>
> I have no idea.  Comparing the configure script for Emacs 29.2 and
> Emacs 29.3 doesn't show any differences, and neither does comparing
> the various Makefile's.
>
> If you build Emacs 29.2 in this manner, do you get all the *.el files
> compiled into *.eln, or do you see the same problem with Emacs 29.2?

No, Building 29.2 from the release tarball (so, without running
autogen.sh) successfully precompiles all the ELNs as expected.

> If the latter, perhaps the reason has nothing to do with the new
> tarball, but with something else on your system?
>

I try to avoid making changes to my system between iterations of the
same version of Emacs (291. .. 29.3 are all built using the same
versions of things MSYS/MINGW, on my end)

> One note, though: if you say --with-native-compilation=aot, you don't
> need the NATIVE_FULL_AOT=1 part.  Not sure if this is relevant or not.
>

A good point.  I haven't tried removing this to see if anything
changes; 29.2 works properly, so I suspect this is a read herring but
I'll try removing it, nevertheless.

I do get all full AOT build if I add ./autogen.sh to the start of my
recipe -- which is really weird.  I find no differences between the
configure script provided with emacs-29.3 tarball and the one created
by running autogen.sh against the unpacked release tarball sources.  I
have no idea why AOT is working in the latter case but not the first.

I'm inclined to go ahead and publish using the version where I run
autogen.sh -- let me know if we prefer  that we track this issue down
first, instead.

Re: Emacs 29.3 released

[Eli Zaretskii]

> From: Corwin Brust <corwin@bru.st>
> Date: Sun, 24 Mar 2024 14:36:08 -0500
> Cc: emacs-devel@gnu.org
> 
> > I have no idea.  Comparing the configure script for Emacs 29.2 and
> > Emacs 29.3 doesn't show any differences, and neither does comparing
> > the various Makefile's.
> >
> > If you build Emacs 29.2 in this manner, do you get all the *.el files
> > compiled into *.eln, or do you see the same problem with Emacs 29.2?
> 
> No, Building 29.2 from the release tarball (so, without running
> autogen.sh) successfully precompiles all the ELNs as expected.

Strange.  I don't see this problem.

> > One note, though: if you say --with-native-compilation=aot, you don't
> > need the NATIVE_FULL_AOT=1 part.  Not sure if this is relevant or not.
> >
> 
> A good point.  I haven't tried removing this to see if anything
> changes; 29.2 works properly, so I suspect this is a read herring but
> I'll try removing it, nevertheless.
> 
> I do get all full AOT build if I add ./autogen.sh to the start of my
> recipe -- which is really weird.  I find no differences between the
> configure script provided with emacs-29.3 tarball and the one created
> by running autogen.sh against the unpacked release tarball sources.  I
> have no idea why AOT is working in the latter case but not the first.

FWIW, I've just built the 29.3 release tarball with the
"--with-native-compilation=aot" option (and without
NATIVE_FULL_AOT=1), and it builds all the *.eln files just fine.  I
didn't need to run autogen.sh.

> I'm inclined to go ahead and publish using the version where I run
> autogen.sh -- let me know if we prefer  that we track this issue down
> first, instead.

I don't think autogen.sh can do any harm, but I cannot be sure without
understanding why you see this weird problem.

Re: Emacs 29.3 released

[Eli Zaretskii]

> Date: Sun, 24 Mar 2024 21:46:03 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> FWIW, I've just built the 29.3 release tarball with the
> "--with-native-compilation=aot" option (and without
> NATIVE_FULL_AOT=1), and it builds all the *.eln files just fine.  I
> didn't need to run autogen.sh.
> 
> > I'm inclined to go ahead and publish using the version where I run
> > autogen.sh -- let me know if we prefer  that we track this issue down
> > first, instead.
> 
> I don't think autogen.sh can do any harm, but I cannot be sure without
> understanding why you see this weird problem.

What happens if instead of saying "make install" you say just "make",
and then "make install" in a separate step?  (I never do "make
install" from the get-go, only after the build completes.)

Re: Emacs 29.3 released

[Corwin Brust]

On Sun, Mar 24, 2024 at 2:46 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Corwin Brust <corwin@bru.st>
> > Date: Sun, 24 Mar 2024 14:36:08 -0500
> > I'm inclined to go ahead and publish using the version where I run
> > autogen.sh -- let me know if we prefer  that we track this issue down
> > first, instead.
>
> I don't think autogen.sh can do any harm, but I cannot be sure without
> understanding why you see this weird problem.
>

Windows binaries for 29.3 are now pushed.  Please let me know if you hit snags.

https://ftpmirror.gnu.org/gnu/emacs/windows/emacs-29/?C=M;O=D

I will continue trying to figure out what I ran into here, replying
next to your question/suggestion down thread.

Meanwhile, I didn't want people who might be waiting for these
binaries to upgrade a work computer or something to wait any longer.

Many thanks to libera.chat user IsoLinCHiP for help testing this
round, especially as this caught a problem I'd missed with the fullzip
and installer in the first set I made, yesterday.  (I inadvertently
picked up libgccjit when packing DLLs to include, meaning there are
still issues with my patches for build-dep-zips.py.)

Re: Emacs 29.3 released

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> Hi!

Hi Eli,

> Emacs 29.3 is an emergency bugfix release; it includes no new features
> except a small number of changes intended to resolve security
> vulnerabilities uncovered in Emacs 29.2.  See the file etc/NEWS in the
> tarball; you can view it from Emacs by typing 'C-h n', or by clicking
> Help->Emacs News from the menu bar.

I know, an emergency release is an emergency release. But w/o any hint
that it will happen, we have inconsistencies. For example, Emacs 29.3
claims to carry Tramp 2.6.3-pre, which is unfortune.

A short warning that the release will happen, with a short timeout until
it happens, would have been appreciated.

Or did I miss such an announcement?

Best regards, Michael.

Re: Emacs 29.3 released

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Sun, 24 Mar 2024 19:48:40 +0100
> 
> > Emacs 29.3 is an emergency bugfix release; it includes no new features
> > except a small number of changes intended to resolve security
> > vulnerabilities uncovered in Emacs 29.2.  See the file etc/NEWS in the
> > tarball; you can view it from Emacs by typing 'C-h n', or by clicking
> > Help->Emacs News from the menu bar.
> 
> I know, an emergency release is an emergency release. But w/o any hint
> that it will happen, we have inconsistencies. For example, Emacs 29.3
> claims to carry Tramp 2.6.3-pre, which is unfortune.

How did that happen?  Which change to emacs-29 branch caused that, and
why was that change installed on the release branch?

> A short warning that the release will happen, with a short timeout until
> it happens, would have been appreciated.
> 
> Or did I miss such an announcement?

You didn't.  Since this was due to security issues, there was no
advance announcement.

Re: Emacs 29.3 released

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> How did that happen?  Which change to emacs-29 branch caused that, and
> why was that change installed on the release branch?

commit 115908469d30f8c40689673312f72b44c1631c6b

Best regards, Michael.

Re: Emacs 29.3 released

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Sun, 24 Mar 2024 21:10:42 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> Hi Eli,
> 
> > How did that happen?  Which change to emacs-29 branch caused that, and
> > why was that change installed on the release branch?
> 
> commit 115908469d30f8c40689673312f72b44c1631c6b

Thanks, but why was the release branch synchronized with a pre-release
of Tramp?

Re: Emacs 29.3 released

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> > How did that happen?  Which change to emacs-29 branch caused that, and
>> > why was that change installed on the release branch?
>>
>> commit 115908469d30f8c40689673312f72b44c1631c6b
>
> Thanks, but why was the release branch synchronized with a pre-release
> of Tramp?

Tramp 2.6 collects bug fixes. During pretest of Emacs 29.2, only serious
bugs, which are a regression, were merged to the emacs-29 branch. After
the Emacs 29.2 release, the current state of the tramp-2-6-stable branch
(from the Tramp git repo) was merged to the emacs-29 branch, in order to
have the other bug fixes there as well.

This is the usual procedure Tramp applies for years.

Best regards, Michael.

Re: Emacs 29.3 released

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Tue, 26 Mar 2024 09:48:30 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > How did that happen?  Which change to emacs-29 branch caused that, and
> >> > why was that change installed on the release branch?
> >>
> >> commit 115908469d30f8c40689673312f72b44c1631c6b
> >
> > Thanks, but why was the release branch synchronized with a pre-release
> > of Tramp?
> 
> Tramp 2.6 collects bug fixes. During pretest of Emacs 29.2, only serious
> bugs, which are a regression, were merged to the emacs-29 branch. After
> the Emacs 29.2 release, the current state of the tramp-2-6-stable branch
> (from the Tramp git repo) was merged to the emacs-29 branch, in order to
> have the other bug fixes there as well.
> 
> This is the usual procedure Tramp applies for years.

I see.  FWIW, I wasn't aware of this.  My mental model of the release
branch is that it is ready for an immediate release at all times.

Would it be possible to modify the Tramp revision on the release
branch so that it would not have the "-pre" suffix, and otherwise
leave intact the procedure by which you collect and merge fixes to the
release branch?  That would mean that if such an emergency release
does happen, you then advance the Tramp version to the next one (say,
from 2.6.3 to 2.6.4), and keep updating the release branch with any
further fixes.  If that is possible for you, I think it will be the
easiest solution for the future, if we ever need to make such
emergency releases again (something that I think is quite probable,
given that it happened both for Emacs 28 and Emacs 29).
Alternatively, we could record in make-tarball.txt the fact that such
releases must be coordinated with you.  From where I stand, this is
less desirable (as it adds a non-trivial prerequisite for such
releases, which could mean a delay if you are unavailable for some
reason), but still possible.

Thanks.

Re: Emacs 29.3 released

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> Tramp 2.6 collects bug fixes. During pretest of Emacs 29.2, only serious
>> bugs, which are a regression, were merged to the emacs-29 branch. After
>> the Emacs 29.2 release, the current state of the tramp-2-6-stable branch
>> (from the Tramp git repo) was merged to the emacs-29 branch, in order to
>> have the other bug fixes there as well.
>>
>> This is the usual procedure Tramp applies for years.
>
> I see.  FWIW, I wasn't aware of this.  My mental model of the release
> branch is that it is ready for an immediate release at all times.
>
> Would it be possible to modify the Tramp revision on the release
> branch so that it would not have the "-pre" suffix, and otherwise
> leave intact the procedure by which you collect and merge fixes to the
> release branch?  That would mean that if such an emergency release
> does happen, you then advance the Tramp version to the next one (say,
> from 2.6.3 to 2.6.4), and keep updating the release branch with any
> further fixes.  If that is possible for you, I think it will be the
> easiest solution for the future, if we ever need to make such
> emergency releases again (something that I think is quite probable,
> given that it happened both for Emacs 28 and Emacs 29).

It would be possible. I could change the Tramp version in the release
branch to the next anticipated release number. So I could change it now
to "2.6.3.29.4". However, I see at least two problems:

- The Tramp version doesn't guarantee any longer uniqueness. Tramp
  2.6.3.29.4 would differ today and tomorrow. That was the reason to use
  such an ambiguous version like 2.6.3-pre.

- We might run into problems on ELPA. A user sees a builtin version of
  Tramp 2.6.3.29.4, but in order to fix something for her there is also
  Tramp 2.6.2.9 (let's say). I fear we'll have a hard time to explain,
  that 2.6.2.9 is newer than 2.6.3.29.4.

> Alternatively, we could record in make-tarball.txt the fact that such
> releases must be coordinated with you.  From where I stand, this is
> less desirable (as it adds a non-trivial prerequisite for such
> releases, which could mean a delay if you are unavailable for some
> reason), but still possible.

Perhaps it must not be coordinated with "me" only. A single
announcement, that there will be an emergency release within two days
would have helped. Usually, I scan Emacs related messages every single day.

If I am unavailable that time, so be it. Not worse than now.

(FWIW, I don't understand yet why 29.3 was such an emergency that it was
released w/o any warning in advance.)

> Thanks.

Best regards, Michael.

Re: Emacs 29.3 released

[Ihor Radchenko]

Michael Albinus <michael.albinus@gmx.de> writes:

>> Would it be possible to modify the Tramp revision on the release
>> branch so that it would not have the "-pre" suffix, and otherwise
>> leave intact the procedure by which you collect and merge fixes to the
>> release branch? ...
>
> It would be possible. I could change the Tramp version in the release
> branch to the next anticipated release number. So I could change it now
> to "2.6.3.29.4". However, I see at least two problems:
>
> - The Tramp version doesn't guarantee any longer uniqueness. Tramp
>   2.6.3.29.4 would differ today and tomorrow. That was the reason to use
>   such an ambiguous version like 2.6.3-pre.
>
> - We might run into problems on ELPA. A user sees a builtin version of
>   Tramp 2.6.3.29.4, but in order to fix something for her there is also
>   Tramp 2.6.2.9 (let's say). I fear we'll have a hard time to explain,
>   that 2.6.2.9 is newer than 2.6.3.29.4.

May it be an option to follow what Org mode does?
We have a stable branch that we periodically tag as a bugfix release
(weekly, if there are new commits).
Only tagged bugfix releases are merged to Emacs upstream.
The same bugfix releases go to ELPA.

> (FWIW, I don't understand yet why 29.3 was such an emergency that it was
> released w/o any warning in advance.)

CVE.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Emacs 29.3 released

[Michael Albinus]

Ihor Radchenko <yantar92@posteo.net> writes:

Hi Ihor,

> May it be an option to follow what Org mode does?
> We have a stable branch that we periodically tag as a bugfix release
> (weekly, if there are new commits).
> Only tagged bugfix releases are merged to Emacs upstream.
> The same bugfix releases go to ELPA.

Tramp does something similar on GNU ELPA. It pushes bug fix releases
with a dedicated version. It happens monthly only, submissions to Tramp
happen less frequently.

However, it doesn't push the same bugfix release to the emacs-29 branch,
because not every bug fix is essential while Emeca is in pretest.

>> (FWIW, I don't understand yet why 29.3 was such an emergency that it was
>> released w/o any warning in advance.)
>
> CVE.

I haven't seen any CVE number in the announcement.

Best regards, Michael.

Re: Emacs 29.3 released

[Ihor Radchenko]

Michael Albinus <michael.albinus@gmx.de> writes:

>> May it be an option to follow what Org mode does?
>> We have a stable branch that we periodically tag as a bugfix release
>> (weekly, if there are new commits).
>> Only tagged bugfix releases are merged to Emacs upstream.
>> The same bugfix releases go to ELPA.
>
> Tramp does something similar on GNU ELPA. It pushes bug fix releases
> with a dedicated version. It happens monthly only, submissions to Tramp
> happen less frequently.
>
> However, it doesn't push the same bugfix release to the emacs-29 branch,
> because not every bug fix is essential while Emeca is in pretest.

I see. So, you effectively have to "bugfix" versions - one with
hand-picked commits for Emacs pretest and one with more commits for
ELPA.

Maybe you can split the versions into Emacs-only and, fuller, proper
bugfix. Say, something like
Tramp 2.6.2.<emacs>.<N> and Tramp 2.6.2.<elpa>.<N>
Then, if emacs=1 and elpa=2, you will always get ELPA version to be
newer compared to Emacs pretest version.

But it is getting complicated... Not sure if it is worth layering the
versions that much.

>>> (FWIW, I don't understand yet why 29.3 was such an emergency that it was
>>> released w/o any warning in advance.)
>>
>> CVE.
>
> I haven't seen any CVE number in the announcement.

https://security-tracker.debian.org/tracker/CVE-2024-30203

The Emacs release was the announcement, and the first public disclosure
of the vulnerability.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Emacs 29.3 released

[Michael Albinus]

Ihor Radchenko <yantar92@posteo.net> writes:

Hi Ihor,

> Maybe you can split the versions into Emacs-only and, fuller, proper
> bugfix. Say, something like
> Tramp 2.6.2.<emacs>.<N> and Tramp 2.6.2.<elpa>.<N>
> Then, if emacs=1 and elpa=2, you will always get ELPA version to be
> newer compared to Emacs pretest version.
>
> But it is getting complicated... Not sure if it is worth layering the
> versions that much.

And don't forget, Tramp is almost a one-man-show.

>> I haven't seen any CVE number in the announcement.
>
> https://security-tracker.debian.org/tracker/CVE-2024-30203
>
> The Emacs release was the announcement, and the first public disclosure
> of the vulnerability.

So we would have had time alerting Emacs developers about the new
release in advance, wouldn't we?

Best regards, Michael.

Re: Emacs 29.3 released

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Tue, 26 Mar 2024 15:28:26 +0100
> 
> > Would it be possible to modify the Tramp revision on the release
> > branch so that it would not have the "-pre" suffix, and otherwise
> > leave intact the procedure by which you collect and merge fixes to the
> > release branch?  That would mean that if such an emergency release
> > does happen, you then advance the Tramp version to the next one (say,
> > from 2.6.3 to 2.6.4), and keep updating the release branch with any
> > further fixes.  If that is possible for you, I think it will be the
> > easiest solution for the future, if we ever need to make such
> > emergency releases again (something that I think is quite probable,
> > given that it happened both for Emacs 28 and Emacs 29).
> 
> It would be possible. I could change the Tramp version in the release
> branch to the next anticipated release number. So I could change it now
> to "2.6.3.29.4". However, I see at least two problems:
> 
> - The Tramp version doesn't guarantee any longer uniqueness. Tramp
>   2.6.3.29.4 would differ today and tomorrow. That was the reason to use
>   such an ambiguous version like 2.6.3-pre.
> 
> - We might run into problems on ELPA. A user sees a builtin version of
>   Tramp 2.6.3.29.4, but in order to fix something for her there is also
>   Tramp 2.6.2.9 (let's say). I fear we'll have a hard time to explain,
>   that 2.6.2.9 is newer than 2.6.3.29.4.

Then perhaps make-tarball.txt needs to say that the version of Tramp
should be changed from X.Y.Z-pre to X.Y.Z as part of preparing the
release?  Or even do this automatically in admin/admin.el, as part of
set-version?

> > Alternatively, we could record in make-tarball.txt the fact that such
> > releases must be coordinated with you.  From where I stand, this is
> > less desirable (as it adds a non-trivial prerequisite for such
> > releases, which could mean a delay if you are unavailable for some
> > reason), but still possible.
> 
> Perhaps it must not be coordinated with "me" only. A single
> announcement, that there will be an emergency release within two days
> would have helped. Usually, I scan Emacs related messages every single day.
> 
> If I am unavailable that time, so be it. Not worse than now.

Preparation of a release tarball is a precarious job: since we don't
lock the Git repository while the release is being worked on, it must
be done very quickly; any commits someone does during the time it
takes to do all the steps necessary for producing the tarball is a
setback that requires to go back several steps and start anew.  So any
additional dependency is a disadvantage I'd like to avoid.

> (FWIW, I don't understand yet why 29.3 was such an emergency that it was
> released w/o any warning in advance.)

Because it makes no sense to announce in advance that Emacs has
security vulnerabilities.  It's akin to waving the proverbial red flag
at a bull.

Re: Emacs 29.3 released

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> It would be possible. I could change the Tramp version in the release
>> branch to the next anticipated release number. So I could change it now
>> to "2.6.3.29.4". However, I see at least two problems:
>>
>> - The Tramp version doesn't guarantee any longer uniqueness. Tramp
>>   2.6.3.29.4 would differ today and tomorrow. That was the reason to use
>>   such an ambiguous version like 2.6.3-pre.
>>
>> - We might run into problems on ELPA. A user sees a builtin version of
>>   Tramp 2.6.3.29.4, but in order to fix something for her there is also
>>   Tramp 2.6.2.9 (let's say). I fear we'll have a hard time to explain,
>>   that 2.6.2.9 is newer than 2.6.3.29.4.
>
> Then perhaps make-tarball.txt needs to say that the version of Tramp
> should be changed from X.Y.Z-pre to X.Y.Z as part of preparing the
> release?  Or even do this automatically in admin/admin.el, as part of
> set-version?

No. Release X.Y.Z would attribute the full release of Tramp, not only
the part which is integrated into Emacs.

>> Perhaps it must not be coordinated with "me" only. A single
>> announcement, that there will be an emergency release within two days
>> would have helped. Usually, I scan Emacs related messages every single day.
>>
>> If I am unavailable that time, so be it. Not worse than now.
>
> Preparation of a release tarball is a precarious job: since we don't
> lock the Git repository while the release is being worked on, it must
> be done very quickly; any commits someone does during the time it
> takes to do all the steps necessary for producing the tarball is a
> setback that requires to go back several steps and start anew.  So any
> additional dependency is a disadvantage I'd like to avoid.

You could start the prepare the release tarball after the grace period.

>> (FWIW, I don't understand yet why 29.3 was such an emergency that it was
>> released w/o any warning in advance.)
>
> Because it makes no sense to announce in advance that Emacs has
> security vulnerabilities.  It's akin to waving the proverbial red flag
> at a bull.

I haven't proposed that such an announcement shall happen. I have only
proposed to send an alert like "Heads up! The next Emacs release will
happen on Sunday!".

Btw, I've got already the first rant that "Tramp 2.6.3-pre" is useless
for determining, whether a given patch is contained in Emacs 29.3. Right
they are!

<https://github.com/magit/magit/issues/3624#issuecomment-2022167445>

Best regards, Michael.

Re: Emacs 29.3 released

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Wed, 27 Mar 2024 09:27:40 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> It would be possible. I could change the Tramp version in the release
> >> branch to the next anticipated release number. So I could change it now
> >> to "2.6.3.29.4". However, I see at least two problems:
> >>
> >> - The Tramp version doesn't guarantee any longer uniqueness. Tramp
> >>   2.6.3.29.4 would differ today and tomorrow. That was the reason to use
> >>   such an ambiguous version like 2.6.3-pre.
> >>
> >> - We might run into problems on ELPA. A user sees a builtin version of
> >>   Tramp 2.6.3.29.4, but in order to fix something for her there is also
> >>   Tramp 2.6.2.9 (let's say). I fear we'll have a hard time to explain,
> >>   that 2.6.2.9 is newer than 2.6.3.29.4.
> >
> > Then perhaps make-tarball.txt needs to say that the version of Tramp
> > should be changed from X.Y.Z-pre to X.Y.Z as part of preparing the
> > release?  Or even do this automatically in admin/admin.el, as part of
> > set-version?
> 
> No. Release X.Y.Z would attribute the full release of Tramp, not only
> the part which is integrated into Emacs.

So what is it that you do with Tramp to make its parts in Emacs ready
for a release?  If I'd alerted you to the imminent release, what would
you have done before telling me that Tramp is ready?

> >> Perhaps it must not be coordinated with "me" only. A single
> >> announcement, that there will be an emergency release within two days
> >> would have helped. Usually, I scan Emacs related messages every single day.
> >>
> >> If I am unavailable that time, so be it. Not worse than now.
> >
> > Preparation of a release tarball is a precarious job: since we don't
> > lock the Git repository while the release is being worked on, it must
> > be done very quickly; any commits someone does during the time it
> > takes to do all the steps necessary for producing the tarball is a
> > setback that requires to go back several steps and start anew.  So any
> > additional dependency is a disadvantage I'd like to avoid.
> 
> You could start the prepare the release tarball after the grace period.

Theoretically, maybe.

> >> (FWIW, I don't understand yet why 29.3 was such an emergency that it was
> >> released w/o any warning in advance.)
> >
> > Because it makes no sense to announce in advance that Emacs has
> > security vulnerabilities.  It's akin to waving the proverbial red flag
> > at a bull.
> 
> I haven't proposed that such an announcement shall happen. I have only
> proposed to send an alert like "Heads up! The next Emacs release will
> happen on Sunday!".

Without any explanation, that wouldn't be accepted by the community as
we know it.  There would be a flood of questions, and what could I
possibly say in response? "I can tell you, but then I'll have to have
you taken out and shot"?

> Btw, I've got already the first rant that "Tramp 2.6.3-pre" is useless
> for determining, whether a given patch is contained in Emacs 29.3. Right
> they are!
> 
> <https://github.com/magit/magit/issues/3624#issuecomment-2022167445>

If you think this is bad enough, we can always release Emacs 29.4.

Re: Emacs 29.3 released

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> So what is it that you do with Tramp to make its parts in Emacs ready
> for a release?  If I'd alerted you to the imminent release, what would
> you have done before telling me that Tramp is ready?

I would change the Tramp version from "2.6.3-pre" to "2.6.3.29.3", and I
would update `customize-package-emacs-version-alist'.

The Tramp version happens on several places in Emacs, so I have a small
automation which runs on my laptop. See lisp/net/trampver.el and
doc/misc/trampver.texi.

>> I haven't proposed that such an announcement shall happen. I have only
>> proposed to send an alert like "Heads up! The next Emacs release will
>> happen on Sunday!".
>
> Without any explanation, that wouldn't be accepted by the community as
> we know it.  There would be a flood of questions, and what could I
> possibly say in response? "I can tell you, but then I'll have to have
> you taken out and shot"?

If it doesn't bother you too much, an alert just to me would be OK.

>> Btw, I've got already the first rant that "Tramp 2.6.3-pre" is useless
>> for determining, whether a given patch is contained in Emacs 29.3. Right
>> they are!
>>
>> <https://github.com/magit/magit/issues/3624#issuecomment-2022167445>
>
> If you think this is bad enough, we can always release Emacs 29.4.

No. As I've said already in another message, this ship has sailed. And
it happened already in the past: Emacs 22.3 came with Tramp 2.0.58-pre,
and Emacs 23.4 came with Tramp 2.1.21-pre.

Best regards, Michael.

Re: Emacs 29.3 released

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Wed, 27 Mar 2024 15:07:30 +0100
> 
> > So what is it that you do with Tramp to make its parts in Emacs ready
> > for a release?  If I'd alerted you to the imminent release, what would
> > you have done before telling me that Tramp is ready?
> 
> I would change the Tramp version from "2.6.3-pre" to "2.6.3.29.3", and I
> would update `customize-package-emacs-version-alist'.
> 
> The Tramp version happens on several places in Emacs, so I have a small
> automation which runs on my laptop. See lisp/net/trampver.el and
> doc/misc/trampver.texi.

Would it make sense to make this part of admin/admin.el, called from
"M-x set-version"?  Or at least add some text to make-tarball.txt to
verify that these changes are done before preparing the tarball?

Re: Emacs 29.3 released

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> I would change the Tramp version from "2.6.3-pre" to "2.6.3.29.3", and I
>> would update `customize-package-emacs-version-alist'.
>>
>> The Tramp version happens on several places in Emacs, so I have a small
>> automation which runs on my laptop. See lisp/net/trampver.el and
>> doc/misc/trampver.texi.
>
> Would it make sense to make this part of admin/admin.el, called from
> "M-x set-version"?  Or at least add some text to make-tarball.txt to
> verify that these changes are done before preparing the tarball?

I'll think about when I'm back.

Best regards, Michael.

Re: Emacs 29.3 released

[Michael Albinus]

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

Michael Albinus <michael.albinus@gmx.de> writes:

Hi Eli,

>>> I would change the Tramp version from "2.6.3-pre" to "2.6.3.29.3", and I
>>> would update `customize-package-emacs-version-alist'.
>>>
>>> The Tramp version happens on several places in Emacs, so I have a small
>>> automation which runs on my laptop. See lisp/net/trampver.el and
>>> doc/misc/trampver.texi.
>>
>> Would it make sense to make this part of admin/admin.el, called from
>> "M-x set-version"?  Or at least add some text to make-tarball.txt to
>> verify that these changes are done before preparing the tarball?
>
> I'll think about when I'm back.

What about this:


[-- Attachment #2: Type: text/plain, Size: 1612 bytes --]

diff --git a/admin/make-tarball.txt b/admin/make-tarball.txt
index 5704e8e8922..6ea22220928 100644
--- a/admin/make-tarball.txt
+++ b/admin/make-tarball.txt
@@ -134,6 +134,9 @@ General steps (for each step, check for possible errors):
     Before a release candidate is made, the tasks listed in
     admin/release-process must be completed.

+    If this is an emergency release without a prior pretest, inform
+    the concerned package maintainers.  See admin/notes/versioning.
+
     Set the version number to that of the actual release (commit in
     one, as described above).  Pick a date about a week from now when
     you intend to make the release.  Use M-x add-release-logs from
diff --git a/admin/notes/versioning b/admin/notes/versioning
index 9428dc76710..a86e2a1b9d5 100644
--- a/admin/notes/versioning
+++ b/admin/notes/versioning
@@ -27,3 +27,12 @@ unexpected last-minute problem occurs.
 The development version for a new major release has "minor" = 0.
 The development version for a new minor release has "minor" = that of
 the previous release.
+
+Emacs contains built-in packages with an own version number, which
+could be different from the natural version number of this package
+(for example, Tramp).  Usually, they are adjusted by the respective
+maintainers prior an Emacs release.  If a new Emacs version will be
+released without a pretest release, for example an emergency release
+due to security problems, inform the respective package maintainers in
+advance by email, and give them a short period (one day) to adjust the
+package version number.

[-- Attachment #3: Type: text/plain, Size: 25 bytes --]



Best regards, Michael.

Re: Emacs 29.3 released

[Robert Pluim]

>>>>> On Wed, 03 Apr 2024 14:03:51 +0200, Michael Albinus <michael.albinus@gmx.de> said:
    Michael> +
    Michael> +Emacs contains built-in packages with an own version number, which
    Michael> +could be different from the natural version number of this package
    Michael> +(for example, Tramp).  Usually, they are adjusted by the respective
    Michael> +maintainers prior an Emacs release.  If a new Emacs version will be
    Michael> +released without a pretest release, for example an emergency release
    Michael> +due to security problems, inform the respective package maintainers in
    Michael> +advance by email, and give them a short period (one day) to adjust the
    Michael> +package version number.

Itʼs not just the version number, itʼs also the fact that (some of) the
development of built-in packages happens outside the emacs repository
and is then synced (eg org-mode). Itʼs that syncing we need to ensure
is in a sane state, as  well as the updating of the version number
(although I realize in practise this is probably a weak argument: both
the tramp and org-mode maintainers are pretty conscientious about
ensuring the code in the emacs tree is healthy).

Robert
-- 

Re: Emacs 29.3 released

[Michael Albinus]

Robert Pluim <rpluim@gmail.com> writes:

Hi Robert,

>     Michael> +Emacs contains built-in packages with an own version number, which
>     Michael> +could be different from the natural version number of this package
>     Michael> +(for example, Tramp).  Usually, they are adjusted by the respective
>     Michael> +maintainers prior an Emacs release.  If a new Emacs version will be
>     Michael> +released without a pretest release, for example an emergency release
>     Michael> +due to security problems, inform the respective package maintainers in
>     Michael> +advance by email, and give them a short period (one day) to adjust the
>     Michael> +package version number.
>
> Itʼs not just the version number, itʼs also the fact that (some of) the
> development of built-in packages happens outside the emacs repository
> and is then synced (eg org-mode). Itʼs that syncing we need to ensure
> is in a sane state, as  well as the updating of the version number
> (although I realize in practise this is probably a weak argument: both
> the tramp and org-mode maintainers are pretty conscientious about
> ensuring the code in the emacs tree is healthy).

Usually, this happens automatically if there is a pretest prior a
release. We're discussing the fact that a pretest didn't happen, due to
an emergency release. And in that case, it might not be desirable to
sync built-in packages from their repos.

However, I believe the proposal of Eli is better than mine (see the
other messages), which doesn't emphasize versioning either.

> Robert

Best regards, Michael.

Re: Emacs 29.3 released

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Wed, 03 Apr 2024 14:03:51 +0200
> 
> >> Would it make sense to make this part of admin/admin.el, called from
> >> "M-x set-version"?  Or at least add some text to make-tarball.txt to
> >> verify that these changes are done before preparing the tarball?
> >
> > I'll think about when I'm back.
> 
> What about this:

I'm not sure we need to emphasize the version aspect.  For Tramp, this
is the only/main issue, but maybe other packages need something else,
now or in the future.

So perhaps something more general, directly in make-tarball.txt, would
be better?  For example:

  If this is an emergency release without a prior pretest, inform
  the maintainers of bundled packages to make sure they install
  adjustments required for an official release.  Currently, these
  packages include:

    . Tramp

WDYT?

Re: Emacs 29.3 released

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> So perhaps something more general, directly in make-tarball.txt, would
> be better?  For example:
>
>   If this is an emergency release without a prior pretest, inform
>   the maintainers of bundled packages to make sure they install
>   adjustments required for an official release.  Currently, these
>   packages include:
>
>     . Tramp
>
> WDYT?

Fine by me, thanks. Perhaps we need also to mention Org, but this I
don't now for sure.

Best regards, Michael.

Re: Emacs 29.3 released

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Wed, 03 Apr 2024 16:56:22 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> Hi Eli,
> 
> > So perhaps something more general, directly in make-tarball.txt, would
> > be better?  For example:
> >
> >   If this is an emergency release without a prior pretest, inform
> >   the maintainers of bundled packages to make sure they install
> >   adjustments required for an official release.  Currently, these
> >   packages include:
> >
> >     . Tramp
> >
> > WDYT?
> 
> Fine by me, thanks.

Thanks, installed (but in a different place in the file, as I believe
this is one of the preliminary steps, not part of the procedure
itself).

> Perhaps we need also to mention Org, but this I don't now for sure.

Ihor will tell, but I believe the Org version on the release branch is
already kept in a ready state.

Re: Emacs 29.3 released

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> Thanks, installed (but in a different place in the file, as I believe
> this is one of the preliminary steps, not part of the procedure
> itself).

Thanks!

Best regards, Michael.

Re: Emacs 29.3 released

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Perhaps we need also to mention Org, but this I don't now for sure.
>
> Ihor will tell, but I believe the Org version on the release branch is
> already kept in a ready state.

Yup. On Emacs (bugfix) release branch, we are careful to sync only the
latest stable (bugfix) Org version that does not contain any risky
changes.

Occasionally, we may have risky changes if they are themselves critical
(like fixing complete breakage). So, having a notification that new
Emacs release is imminent might still be of use, so that we can sync the
critical changes in the rare situations when there is both urgent Emacs
release, urgent Org mode release, and the urgent Org mode release is not
yet in sync (e.g. if Kyle is busy with something and delayed sync).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Emacs 29.3 released

[Corwin Brust]

On Wed, Mar 27, 2024 at 7:42 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> If you think this is bad enough, we can always release Emacs 29.4.
>

On the chance this happens I have an important fix for the Windows
installer (NSI) script that I would like to be sure to include.  The
patch is attached to bug #67667 and corrects a problem where the
uninstaller (by default, without warning) removes all versions of
Emacs (rather than the one installed with the given uninstaller).

Re: Emacs 29.3 released

[Ulrich Mueller]

>>>>> On Sun, 24 Mar 2024, Michael Albinus wrote:

> I know, an emergency release is an emergency release. But w/o any hint
> that it will happen, we have inconsistencies. For example, Emacs 29.3
> claims to carry Tramp 2.6.3-pre, which is unfortune.

Does this cause any specific problems for Tramp in Emacs 29.3, apart
from its "unfortunate" version number?

If yes, is there any patch that distros could apply to the released
version?

Re: Emacs 29.3 released

[Michael Albinus]

Ulrich Mueller <ulm@gentoo.org> writes:

Hi Ulrich,

>> I know, an emergency release is an emergency release. But w/o any hint
>> that it will happen, we have inconsistencies. For example, Emacs 29.3
>> claims to carry Tramp 2.6.3-pre, which is unfortune.
>
> Does this cause any specific problems for Tramp in Emacs 29.3, apart
> from its "unfortunate" version number?

No. The "unfortunate" version number is a problem on ELPA, though. The
built-in Tramp reports tramp-version "2.6.3-pre". In GNU ELPA, Tramp is
listed with built-in version "2.6.3pre". It might be problematic to
explain to users, that a bug release "2.6.2.9" would be better than the
built-in version. Good chances to confuse people.

However, this ship has sailed. We shouldn't increae the confusion by
adding further Tramp versions, which mean the same existing Tramp.

Best regards, Michael.

Re: Emacs 29.3 released

[Lynn Winebarger]

On Sun, Mar 24, 2024 at 10:16 AM Eli Zaretskii <eliz@gnu.org> wrote:
> Version 29.3 of Emacs, the extensible text editor, should now
> be available from your nearest GNU mirror:
> [....]
> Emacs 29.3 is an emergency bugfix release; it includes no new features
> except a small number of changes intended to resolve security
> vulnerabilities uncovered in Emacs 29.2.  See the file etc/NEWS in the
> tarball; you can view it from Emacs by typing 'C-h n', or by clicking
> Help->Emacs News from the menu bar.
>
Given the conservative nature of changes in minor releases, is it safe
to assume the configure script options for a major release won't
change in a minor release after X.1?  You've been explicit here about
no new features being added, but it would be nice to know in general
if I can just use the same configure options from one minor release to
the next without missing out on something new.

Thanks,
Lynn

Re: Emacs 29.3 released

[Eli Zaretskii]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Sat, 6 Apr 2024 11:45:58 -0400
> Cc: emacs-devel@gnu.org
> 
> On Sun, Mar 24, 2024 at 10:16 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > Version 29.3 of Emacs, the extensible text editor, should now
> > be available from your nearest GNU mirror:
> > [....]
> > Emacs 29.3 is an emergency bugfix release; it includes no new features
> > except a small number of changes intended to resolve security
> > vulnerabilities uncovered in Emacs 29.2.  See the file etc/NEWS in the
> > tarball; you can view it from Emacs by typing 'C-h n', or by clicking
> > Help->Emacs News from the menu bar.
> >
> Given the conservative nature of changes in minor releases, is it safe
> to assume the configure script options for a major release won't
> change in a minor release after X.1?

They shouldn't, not unless we discover some serious bug in those
options.

> You've been explicit here about no new features being added, but it
> would be nice to know in general if I can just use the same
> configure options from one minor release to the next without missing
> out on something new.

There are no changes in the configure script in Emacs 29.3.  You can
review all the changes by looking at the logs, whether Git logs or
ChangeLog.4 file in the top-level directory.