GNU bug report logs - #49855
Problem with GNU ELPA build of :core package (Re: [GNU ELPA] So-Long version 1.1)

Previous Next

To reply to this bug, email your comments to 49855 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: bug-gnu-emacs <at> gnu.org
Cc: monnier <at> iro.umontreal.ca
Subject: Problem with GNU ELPA build of :core package (Re: [GNU ELPA]
 So-Long version 1.1)
Date: Wed, 04 Aug 2021 12:17:23 +1200

Yesterday I merged[1] so-long v1.1 to the Emacs master branch, and
per the GNU ELPA config[2] I subsequently got a notification email
to say that v1.1 was now on ELPA too; but I've noticed that the
ELPA version is wrong -- the tar file provided at the ELPA page[3]
does not contain the same version that is in Emacs.

It looks like it's taken one of the new commits and made a build
from that, but it's not the revision from the merge, so it's
missing many of the changes.

[1] 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3a56d4eea93e2fe832021a0685e2d9fe5bbd034b
[2] 
https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-packages?id=06e26055b3377#n346
[3] https://elpa.gnu.org/packages/so-long.html

Could someone (Stefan?) fix the ELPA version, and see if you can
figure out what went awry here?

I suppose the version may need a bump in case anyone has installed
this already.  Preferably something like 1.1.1 rather than 1.2.


-Phil


On 2021-08-04 09:02, ELPA update wrote:
> Version 1.1 of package So-Long has just been released in GNU ELPA.
> You can now find it in M-x package-list RET.
> 
> So-Long describes itself as:
>   Say farewell to performance problems with minified code.
> 
> More at https://elpa.gnu.org/packages/so-long.html

Message #8 received at 49855 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: 49855 <at> debbugs.gnu.org
Cc: monnier <at> iro.umontreal.ca
Subject: Re: bug#49855: Problem with GNU ELPA build of :core package (Re:
 [GNU ELPA] So-Long version 1.1)
Date: Wed, 04 Aug 2021 12:39:33 +1200

On 2021-08-04 12:17, Phil Sainty wrote:
> Could someone (Stefan?) fix the ELPA version, and see if you can
> figure out what went awry here?

I now see that it specifically used the commit in which the
version number changed, and ignored everything which followed,
so I understand what happened now.

That didn't gel very well with my workflow (which was to bump
the version before adding new functionality, and then add the
new features (associating each one with the new version as I
went), and finally merge the branch for the completed release).

I'm not sure if ELPA could be made to recognise that scenario,
or if I'll need to ensure that the final commit always includes
a version bump.

I do understand that it's useful to be able to push changes
without changing the version on ELPA, so that you only create
a new release at the time you intend to, so I'm not asking for
every commit to create a new build; just wondering whether it's
possible to account for the branch merge scenario, where the
merge commit was intended to be the version bump commit.

In the meantime I guess I should commit this change to the
Emacs master branch?

-;; Version: 1.1
+;; Version: 1.1.1


-Phil

Message #11 received at 49855 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 49855 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#49855: Problem with GNU ELPA build of :core package (Re:
 [GNU ELPA] So-Long version 1.1)
Date: Wed, 04 Aug 2021 01:59:23 +0100

Phil Sainty <psainty <at> orcon.net.nz> writes:

> On 2021-08-04 12:17, Phil Sainty wrote:
>> Could someone (Stefan?) fix the ELPA version, and see if you can
>> figure out what went awry here?
>
> I now see that it specifically used the commit in which the
> version number changed, and ignored everything which followed,
> so I understand what happened now.
>
> That didn't gel very well with my workflow (which was to bump
> the version before adding new functionality, and then add the
> new features (associating each one with the new version as I
> went), and finally merge the branch for the completed release).
>
> I'm not sure if ELPA could be made to recognise that scenario,
> or if I'll need to ensure that the final commit always includes
> a version bump.
>
> I do understand that it's useful to be able to push changes
> without changing the version on ELPA, so that you only create
> a new release at the time you intend to, so I'm not asking for
> every commit to create a new build; just wondering whether it's
> possible to account for the branch merge scenario, where the
> merge commit was intended to be the version bump commit.

IIUC, something similar was brought up earlier this year:
https://lists.gnu.org/r/emacs-devel/2021-03/msg00490.html

Thanks,

-- 
Basil

Message #14 received at 49855 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 49855 <at> debbugs.gnu.org
Subject: Re: bug#49855: Problem with GNU ELPA build of :core package (Re:
 [GNU ELPA] So-Long version 1.1)
Date: Tue, 03 Aug 2021 23:23:51 -0400

> That didn't gel very well with my workflow (which was to bump
> the version before adding new functionality, and then add the
> new features (associating each one with the new version as I
> went), and finally merge the branch for the completed release).

What I can suggest in that case is to do:

1- bump the version from `AA.BB` to `CC.DD-git`
2- hack hack hack
3- when done, bump the version from `CC.DD-git` to `CC.DD`


        Stefan

Message #17 received at 49855 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 49855 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#49855: Problem with GNU ELPA build of :core package (Re:
 [GNU ELPA] So-Long version 1.1)
Date: Wed, 04 Aug 2021 10:10:49 +0200

Phil Sainty <psainty <at> orcon.net.nz> writes:

> I do understand that it's useful to be able to push changes
> without changing the version on ELPA, so that you only create
> a new release at the time you intend to, so I'm not asking for
> every commit to create a new build; just wondering whether it's
> possible to account for the branch merge scenario, where the
> merge commit was intended to be the version bump commit.

I don't really think there's any way to determine the intention here.
The developer may be working in a branch, fix something, bump the
number, fix some more (but doesn't want that to land in ELPA yet), and
then merge, for instance.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #20 received at 49855 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 49855 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#49855: Problem with GNU ELPA build of :core package (Re:
 [GNU ELPA] So-Long version 1.1)
Date: Thu, 05 Aug 2021 00:31:20 +1200

On 2021-08-04 20:10, Lars Ingebrigtsen wrote:
> I don't really think there's any way to determine the intention here.
> The developer may be working in a branch, fix something, bump the
> number, fix some more (but doesn't want that to land in ELPA yet), and
> then merge, for instance.

I guess so.  It seems a less-likely workflow to my mind, but that may
just be my own habits and biases talking.

Still, it would be good if we could at least reduce the chances of 
people
getting tripped up by this.  Taking a different tack, perhaps we just 
need
a more detailed (or an additional) notification email.

At present I'm sent this:

> Subject: [GNU ELPA] So-Long version 1.1.1
> From: ELPA update <do.not.reply <at> elpa.gnu.org>
> To: gnu-emacs-sources <at> gnu.org
> Cc: Phil Sainty <psainty <at> orcon.net.nz>
> Reply-To: help-gnu-emacs <at> gnu.org
> 
> Version 1.1.1 of package So-Long has just been released in GNU ELPA.
> You can now find it in M-x package-list RET.
> 
> So-Long describes itself as:
>   Say farewell to performance problems with minified code.
> 
> More at https://elpa.gnu.org/packages/so-long.html


If in addition to that information, it also showed the commit hash and
message which was used to build the release, I would have immediately
seen that I'd messed up.  Something like:

> Build details:
> Commit 359a8e4eda047b7dcb7e64faff7f8eaacf5d937c
> ; * lisp/so-long.el: Bump to version 1.1

I'm not sure whether it's appropriate to include such details in that
particular notification, or if it would be better to send a separate
message to the maintainer; but either way these details would provide
direct confirmation as to whether the thing you thought had happened
had actually happened.

As it was, I thought I'd released "version 1.1", and the notification
told me that I'd done exactly that, and so I was completely confident
that everything was correct until I found that it wasn't.  I suspect
that if I hadn't done a sanity-check then I might not realised anything
was wrong until someone else told me.


-Phil

Message #23 received at 49855 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 49855 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#49855: Problem with GNU ELPA build of :core package (Re:
 [GNU ELPA] So-Long version 1.1)
Date: Thu, 05 Aug 2021 10:24:00 +1200

On 2021-08-05 00:31, Phil Sainty wrote:
> At present I'm sent this:
>> Subject: [GNU ELPA] So-Long version 1.1.1

Please pretend that I'd shown the 1.1 notification message there,
rather than 1.1.1, so that the rest of that email makes better sense :)

Message #26 received at 49855 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 49855 <at> debbugs.gnu.org
Subject: Re: bug#49855: Problem with GNU ELPA build of :core package (Re:
 [GNU ELPA] So-Long version 1.1)
Date: Wed, 04 Aug 2021 18:33:18 -0400

> If in addition to that information, it also showed the commit hash and
> message which was used to build the release, I would have immediately
> seen that I'd messed up.  Something like:
>
>> Build details:
>> Commit 359a8e4eda047b7dcb7e64faff7f8eaacf5d937c
>> ; * lisp/so-long.el: Bump to version 1.1

Makes sense and sounds good.

> I'm not sure whether it's appropriate to include such details in that
> particular notification, or if it would be better to send a separate
> message to the maintainer;

I think we can keep it as a single message.
We could add something giving the commit id, the date of the commit
(personally, commit ids don't speak to me, but the commit date
might tip me off), and the first line of the commit message.
Seems short enough that it can fit before the NEWS without bothering
those readers who don't care about it.

Do you think you can come up with a patch against `elpa-admin.el`
doing that?


        Stefan

Message #29 received at 49855 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 49855 <at> debbugs.gnu.org
Subject: Re: bug#49855: Problem with GNU ELPA build of :core package (Re:
 [GNU ELPA] So-Long version 1.1)
Date: Fri, 06 Aug 2021 01:11:27 +1200

On 2021-08-05 10:33, Stefan Monnier wrote:
> Do you think you can come up with a patch against `elpa-admin.el`
> doing that?

Yes, I think I can take a stab at that.

My initial foray has raised one item of potential interest:

Git 2.22 Release Notes
======================
 * "git log -L<from>,<to>:<path>" with "-s" did not suppress the patch
   output as it should.  This has been corrected.
   (merge 05314efaea jk/line-log-with-patch later to maint).

I don't know whether there's any reason to support older git
versions, but I'm using git 2.17.1 and so the command generated
by `elpaa--get-release-revision' gives me this:

$ git log -n1 --no-patch --pretty=format:%H -L '/^;;* 
*\(Package-\)\?Version:/,+1:lisp/so-long.el'
b84986af52d4e9debace2850a5ec106f51e38e61
diff --git a/lisp/so-long.el b/lisp/so-long.el
--- a/lisp/so-long.el
+++ b/lisp/so-long.el
@@ -11,1 +11,1 @@
-;; Version: 1.1
+;; Version: 1.1.1

I didn't twig initially that I wasn't seeing the intended
output, and spent a while fruitlessly wondering where in the
elisp that got trimmed down to a single line...


-Phil

Message #32 received at 49855 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 49855 <at> debbugs.gnu.org
Subject: Re: bug#49855: Problem with GNU ELPA build of :core package (Re:
 [GNU ELPA] So-Long version 1.1)
Date: Thu, 05 Aug 2021 10:32:12 -0400

> Git 2.22 Release Notes
> ======================
>  * "git log -L<from>,<to>:<path>" with "-s" did not suppress the patch
>    output as it should.  This has been corrected.
>    (merge 05314efaea jk/line-log-with-patch later to maint).
>
> I don't know whether there's any reason to support older git
> versions, but I'm using git 2.17.1 and so the command generated
> by `elpaa--get-release-revision' gives me this:
>
> $ git log -n1 --no-patch --pretty=format:%H -L '/^;;*
> *\(Package-\)\?Version:/,+1:lisp/so-long.el'
> b84986af52d4e9debace2850a5ec106f51e38e61
> diff --git a/lisp/so-long.el b/lisp/so-long.el
> --- a/lisp/so-long.el
> +++ b/lisp/so-long.el
> @@ -11,1 +11,1 @@
> -;; Version: 1.1
> +;; Version: 1.1.1
>
> I didn't twig initially that I wasn't seeing the intended
> output, and spent a while fruitlessly wondering where in the
> elisp that got trimmed down to a single line...

Interesting.  `elpa.gnu.org` is running a more recent version of Git
because the older Git crashed in this same `elpaa--get-release-revision`
in some cases :-(

Debian stable is still on Git-2.20 so it might be worth adding
a workaround in `elpaa--get-release-revision` (tho a new Debian release
is due any day now, IIUC).


        Stefan

Message #35 received at 49855 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Phil Sainty <psainty <at> orcon.net.nz>, 49855 <at> debbugs.gnu.org
Subject: Re: bug#49855: Problem with GNU ELPA build of :core package (Re:
 [GNU ELPA] So-Long version 1.1)
Date: Mon, 22 Aug 2022 13:07:58 +0200

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Debian stable is still on Git-2.20 so it might be worth adding
> a workaround in `elpaa--get-release-revision` (tho a new Debian release
> is due any day now, IIUC).

This was a year ago, so perhaps the machine has been updated now?

Anyway -- Phil, did you get any further with the proposed changes to
elpa-admin.el?

Message #38 received at 49855 <at> debbugs.gnu.org (full text, mbox):

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 49855 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#49855: Problem with GNU ELPA build of :core package (Re:
 [GNU ELPA] So-Long version 1.1)
Date: Mon, 22 Aug 2022 23:24:34 +1200

On 2022-08-22 23:07, Lars Ingebrigtsen wrote:
> Anyway -- Phil, did you get any further with the proposed changes
> to elpa-admin.el?

I have work-in-progress for that on this machine, yes.

I'll have to try to get back to it.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.