emacs-24.5-rc3.tar.xz modified in place

emacs-24.5-rc3.tar.xz modified in place

[Mark H Weaver]

I've downloaded emacs-24.5-rc3.tar.xz and the corresponding .sig from
alpha.gnu.org twice, and they are different.  Both are signed by Nicolas
Petton's public key (7C207910).  See below for the differences.

It's bad practice to modify tarball releases without changing the
version number.  Please don't do it.  Among other things, it breaks
distributions such as GNU Guix that include cryptographic hashes of all
source tarballs.

      Mark


Binary files emacs-24.5-rc3-old/lisp/cedet/srecode/insert.elc and emacs-24.5-rc3-new/lisp/cedet/srecode/insert.elc differ
Binary files emacs-24.5-rc3-old/lisp/gnus/auth-source.elc and emacs-24.5-rc3-new/lisp/gnus/auth-source.elc differ
Binary files emacs-24.5-rc3-old/lisp/gnus/message.elc and emacs-24.5-rc3-new/lisp/gnus/message.elc differ
Binary files emacs-24.5-rc3-old/lisp/gnus/mm-decode.elc and emacs-24.5-rc3-new/lisp/gnus/mm-decode.elc differ
Binary files emacs-24.5-rc3-old/lisp/org/ob-C.elc and emacs-24.5-rc3-new/lisp/org/ob-C.elc differ
Binary files emacs-24.5-rc3-old/lisp/progmodes/antlr-mode.elc and emacs-24.5-rc3-new/lisp/progmodes/antlr-mode.elc differ
Binary files emacs-24.5-rc3-old/lisp/textmodes/rst.elc and emacs-24.5-rc3-new/lisp/textmodes/rst.elc differ
diff -ru emacs-24.5-rc3-old/lisp/calendar/cal-loaddefs.el emacs-24.5-rc3-new/lisp/calendar/cal-loaddefs.el
--- emacs-24.5-rc3-old/lisp/calendar/cal-loaddefs.el	2015-04-05 08:03:02.000000000 -0400
+++ emacs-24.5-rc3-new/lisp/calendar/cal-loaddefs.el	2015-04-08 13:16:08.000000000 -0400
@@ -958,7 +958,7 @@
 \f
 ;;;### (autoloads nil nil ("appt.el" "cal-dst.el" "cal-menu.el" "calendar.el"
 ;;;;;;  "icalendar.el" "parse-time.el" "time-date.el" "timeclock.el"
-;;;;;;  "todo-mode.el") (21793 9333 249114 55000))
+;;;;;;  "todo-mode.el") (21797 25175 415462 803000))
 
 ;;;***
 \f
diff -ru emacs-24.5-rc3-old/lisp/calendar/diary-loaddefs.el emacs-24.5-rc3-new/lisp/calendar/diary-loaddefs.el
--- emacs-24.5-rc3-old/lisp/calendar/diary-loaddefs.el	2015-04-05 08:03:03.000000000 -0400
+++ emacs-24.5-rc3-new/lisp/calendar/diary-loaddefs.el	2015-04-08 13:16:09.000000000 -0400
@@ -345,7 +345,7 @@
 ;;;### (autoloads nil nil ("appt.el" "cal-dst.el" "cal-html.el" "cal-loaddefs.el"
 ;;;;;;  "cal-menu.el" "cal-move.el" "cal-tex.el" "cal-x.el" "calendar.el"
 ;;;;;;  "diary-lib.el" "icalendar.el" "parse-time.el" "time-date.el"
-;;;;;;  "timeclock.el" "todo-mode.el") (21793 9334 413566 738000))
+;;;;;;  "timeclock.el" "todo-mode.el") (21797 25176 655034 61000))
 
 ;;;***
 \f
diff -ru emacs-24.5-rc3-old/lisp/calendar/hol-loaddefs.el emacs-24.5-rc3-new/lisp/calendar/hol-loaddefs.el
--- emacs-24.5-rc3-old/lisp/calendar/hol-loaddefs.el	2015-04-05 08:03:04.000000000 -0400
+++ emacs-24.5-rc3-new/lisp/calendar/hol-loaddefs.el	2015-04-08 13:16:10.000000000 -0400
@@ -165,7 +165,7 @@
 ;;;;;;  "cal-mayan.el" "cal-menu.el" "cal-move.el" "cal-persia.el"
 ;;;;;;  "cal-tex.el" "cal-x.el" "calendar.el" "diary-lib.el" "diary-loaddefs.el"
 ;;;;;;  "holidays.el" "icalendar.el" "lunar.el" "parse-time.el" "time-date.el"
-;;;;;;  "timeclock.el" "todo-mode.el") (21793 9335 649079 278000))
+;;;;;;  "timeclock.el" "todo-mode.el") (21797 25177 772254 754000))
 
 ;;;***
 \f
diff -ru emacs-24.5-rc3-old/lisp/ChangeLog emacs-24.5-rc3-new/lisp/ChangeLog
--- emacs-24.5-rc3-old/lisp/ChangeLog	2015-04-05 07:04:42.000000000 -0400
+++ emacs-24.5-rc3-new/lisp/ChangeLog	2015-04-06 14:20:05.000000000 -0400
@@ -12,10 +12,6 @@
 	* net/tramp.el (tramp-handle-unhandled-file-name-directory):
 	Return nil when required by the spec.  (Bug#20233)
 
-2015-04-01  Nicolas Petton  <nicolas@petton.fr>
-
-	* Version 24.5 released.
-
 2015-03-26  Stefan Monnier  <monnier@iro.umontreal.ca>
 
 	* emacs-lisp/smie.el (smie-backward-sexp-command)
diff -ru emacs-24.5-rc3-old/lisp/loaddefs.el emacs-24.5-rc3-new/lisp/loaddefs.el
--- emacs-24.5-rc3-old/lisp/loaddefs.el	2015-04-05 08:03:22.000000000 -0400
+++ emacs-24.5-rc3-new/lisp/loaddefs.el	2015-04-08 13:16:25.000000000 -0400
@@ -31986,8 +31986,8 @@
 ;;;;;;  "vc/ediff-ptch.el" "vc/ediff-vers.el" "vc/ediff-wind.el"
 ;;;;;;  "vc/pcvs-info.el" "vc/pcvs-parse.el" "vc/pcvs-util.el" "vc/vc-dav.el"
 ;;;;;;  "vcursor.el" "vt-control.el" "vt100-led.el" "w32-common-fns.el"
-;;;;;;  "w32-fns.el" "w32-vars.el" "x-dnd.el") (21793 9339 497325
-;;;;;;  252000))
+;;;;;;  "w32-fns.el" "w32-vars.el" "x-dnd.el") (21797 25181 196533
+;;;;;;  800000))
 
 ;;;***
 \f
diff -ru emacs-24.5-rc3-old/lisp/mh-e/mh-loaddefs.el emacs-24.5-rc3-new/lisp/mh-e/mh-loaddefs.el
--- emacs-24.5-rc3-old/lisp/mh-e/mh-loaddefs.el	2015-04-05 08:03:06.000000000 -0400
+++ emacs-24.5-rc3-new/lisp/mh-e/mh-loaddefs.el	2015-04-08 13:16:11.000000000 -0400
@@ -3084,7 +3084,7 @@
 ;;;***
 \f
 ;;;### (autoloads nil nil ("mh-buffers.el" "mh-compat.el" "mh-e.el"
-;;;;;;  "mh-gnus.el" "mh-tool-bar.el") (21793 9337 17234 666000))
+;;;;;;  "mh-gnus.el" "mh-tool-bar.el") (21797 25178 891602 773000))
 
 ;;;***
 \f
diff -ru emacs-24.5-rc3-old/lisp/net/tramp-loaddefs.el emacs-24.5-rc3-new/lisp/net/tramp-loaddefs.el
--- emacs-24.5-rc3-old/lisp/net/tramp-loaddefs.el	2015-04-05 08:03:07.000000000 -0400
+++ emacs-24.5-rc3-new/lisp/net/tramp-loaddefs.el	2015-04-08 13:16:13.000000000 -0400
@@ -750,8 +750,8 @@
 ;;;;;;  "rcirc.el" "rlogin.el" "sasl-cram.el" "sasl-digest.el" "sasl-ntlm.el"
 ;;;;;;  "sasl.el" "secrets.el" "shr-color.el" "shr.el" "snmp-mode.el"
 ;;;;;;  "soap-client.el" "soap-inspect.el" "socks.el" "telnet.el"
-;;;;;;  "tls.el" "tramp-compat.el" "webjump.el" "zeroconf.el") (21793
-;;;;;;  9338 174254 825000))
+;;;;;;  "tls.el" "tramp-compat.el" "webjump.el" "zeroconf.el") (21797
+;;;;;;  25180 4990 764000))
 
 ;;;***
 \f

Re: emacs-24.5-rc3.tar.xz modified in place

[Nicolas Petton]

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


Mark H Weaver writes:

> I've downloaded emacs-24.5-rc3.tar.xz and the corresponding .sig from
> alpha.gnu.org twice, and they are different.  Both are signed by Nicolas
> Petton's public key (7C207910).  See below for the differences.
>
> It's bad practice to modify tarball releases without changing the
> version number.  Please don't do it.  Among other things, it breaks
> distributions such as GNU Guix that include cryptographic hashes of all
> source tarballs.

I'm sorry, that's my fault.

The previous tarball had a small issue that was fixed, and I just
updated the tarball without increasing the version number.  I won't do
that again.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

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

Re: emacs-24.5-rc3.tar.xz modified in place

[Eli Zaretskii]

> From: Nicolas Petton <nicolas@petton.fr>
> Date: Fri, 10 Apr 2015 00:36:19 +0200
> Cc: emacs-devel@gnu.org
> 
> > I've downloaded emacs-24.5-rc3.tar.xz and the corresponding .sig from
> > alpha.gnu.org twice, and they are different.  Both are signed by Nicolas
> > Petton's public key (7C207910).  See below for the differences.
> >
> > It's bad practice to modify tarball releases without changing the
> > version number.  Please don't do it.  Among other things, it breaks
> > distributions such as GNU Guix that include cryptographic hashes of all
> > source tarballs.
> 
> I'm sorry, that's my fault.

No, it isn't.  There's no fault to begin with.

Thank you for your work.

Re: emacs-24.5-rc3.tar.xz modified in place

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Nicolas Petton <nicolas@petton.fr>
>> Date: Fri, 10 Apr 2015 00:36:19 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> > I've downloaded emacs-24.5-rc3.tar.xz and the corresponding .sig from
>> > alpha.gnu.org twice, and they are different.  Both are signed by Nicolas
>> > Petton's public key (7C207910).  See below for the differences.
>> >
>> > It's bad practice to modify tarball releases without changing the
>> > version number.  Please don't do it.  Among other things, it breaks
>> > distributions such as GNU Guix that include cryptographic hashes of all
>> > source tarballs.
>> 
>> I'm sorry, that's my fault.
>
> No, it isn't.  There's no fault to begin with.

Yes, there is.  If a tarball needs to be replaced for whatever reason,
it *must* get a new file name.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: emacs-24.5-rc3.tar.xz modified in place

[Eli Zaretskii]

> From: Mark H Weaver <mhw@netris.org>
> Date: Thu, 09 Apr 2015 17:27:02 -0400
> 
> I've downloaded emacs-24.5-rc3.tar.xz and the corresponding .sig from
> alpha.gnu.org twice, and they are different.  Both are signed by Nicolas
> Petton's public key (7C207910).  See below for the differences.
> 
> It's bad practice to modify tarball releases without changing the
> version number.  Please don't do it.  Among other things, it breaks
> distributions such as GNU Guix that include cryptographic hashes of all
> source tarballs.

Thanks.

It was done on purpose, to shorten the release time.  Nicolas did as
instructed.  Distributions should not pick up alpha releases without
asking first.

Re: emacs-24.5-rc3.tar.xz modified in place

[Ulrich Mueller]

>>>>> On Fri, 10 Apr 2015, Eli Zaretskii wrote:

> It was done on purpose, to shorten the release time.  Nicolas did as
> instructed.

What sort of excuse is this?

Please, never ever modify a distfile in place without updating its
version number. It would have been no problem to use -rc4 here. The
modified file in question, emacs-24.5-rc3.tar.xz, had already been
fetched by the Gentoo mirror system. I have updated it now (and the
checksums recorded in our package's manifest), but it will take some
time for the new files to propagate, so in the mean time users will
get checksum failures.

What do you do if you receive a bug report for rc3? You don't know if
it was for the old or the new rc3. (Oh, it doesn't matter because
there were only cosmetic changes? Then there was no need to update the
distfile, in the first place.)

Also this isn't the first time that such a thing has happened:
http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00028.html

> Distributions should not pick up alpha releases without asking
> first.

It is entirely the decision of a distro what they include and what
they don't. The release candidate is distributed under the GPL-3, so
why should anyone have to ask before redistributing it? And it's not
an alpha release but supposedly the final release candidate, so it
should be in everyone's interest if it gets as much testing as
possible. Certainly, Gentoo won't include any rc in stable, but we
have an unstable/testing branch for such purposes.

Ulrich

Re: emacs-24.5-rc3.tar.xz modified in place

[Eli Zaretskii]

> Date: Fri, 10 Apr 2015 11:21:57 +0200
> Cc: Mark H Weaver <mhw@netris.org>, emacs-devel@gnu.org
> From: Ulrich Mueller <ulm@gentoo.org>
> 
> >>>>> On Fri, 10 Apr 2015, Eli Zaretskii wrote:
> 
> > It was done on purpose, to shorten the release time.  Nicolas did as
> > instructed.
> 
> What sort of excuse is this?

It's not an excuse, it's an explanation of what happened.

> Please, never ever modify a distfile in place without updating its
> version number. It would have been no problem to use -rc4 here. The
> modified file in question, emacs-24.5-rc3.tar.xz, had already been
> fetched by the Gentoo mirror system. I have updated it now (and the
> checksums recorded in our package's manifest), but it will take some
> time for the new files to propagate, so in the mean time users will
> get checksum failures.

I'm sorry for the effort you had to invest, but I don't see how it is
relevant to what we do during the release process.  These tarballs are
only there for the last-minute testing of the tarball, so you are
well-advised not to carry them.

> What do you do if you receive a bug report for rc3?

We will handle it.

> Also this isn't the first time that such a thing has happened:
> http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00028.html

And probably also not the last, as much as we want to avoid that.

> > Distributions should not pick up alpha releases without asking
> > first.
> 
> It is entirely the decision of a distro what they include and what
> they don't.

Then you should be prepared for such contingencies.  I can assure you
this last-minute omission is not something that was done on purpose,
so the probability of its happening again is very low.  But we cannot
promise it won't happen.

> And it's not an alpha release but supposedly the final release
> candidate, so it should be in everyone's interest if it gets as much
> testing as possible.

No, that's not true.  The only reason for that RC's existence is that
Nicolas does this job the first time, so he is naturally uncertain
about his procedures (which look just fine from my POV).  We had all
the testing we needed before the first RC.

Re: emacs-24.5-rc3.tar.xz modified in place

[Ulrich Mueller]

>>>>> On Fri, 10 Apr 2015, Eli Zaretskii wrote:

>> Also this isn't the first time that such a thing has happened:
>> http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00028.html

> And probably also not the last, as much as we want to avoid that.

Natural numbers aren't a limited resource, so I don't understand why
you cannot increase the version number. It has zero cost and would
easily avoid all the trouble.

Ulrich

Re: emacs-24.5-rc3.tar.xz modified in place

[Eli Zaretskii]

> Date: Fri, 10 Apr 2015 13:19:07 +0200
> Cc: mhw@netris.org, emacs-devel@gnu.org
> From: Ulrich Mueller <ulm@gentoo.org>
> 
> >>>>> On Fri, 10 Apr 2015, Eli Zaretskii wrote:
> 
> >> Also this isn't the first time that such a thing has happened:
> >> http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00028.html
> 
> > And probably also not the last, as much as we want to avoid that.
> 
> Natural numbers aren't a limited resource, so I don't understand why
> you cannot increase the version number. It has zero cost and would
> easily avoid all the trouble.

It's not zero cost, because each candidate needs to be reflected in
the repository, and potentially also in the ChangeLog files.

Which is not to say these incidents shouldn't be avoided, just that
there might be valid reasons sometimes not to go through all that
stuff.