Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1035757: unblock: org-mode/9.5.2+dfsh-5
0 views
Skip to first unread message
Paul Gevers
May 8, 2023, 3:40:04 PM5/8/23
to
Control: tags -1 moreinfo
Hi,
I haven't thought this trough, but it immediately triggered questions:
On 08-05-2023 20:46, Sean Whitton wrote:
> A number of Emacs addon packages which have their own source packages also
> have versions shipped in src:emacs's binary packages (upstream calls these
> "core" ELPA packages). We have them separately packaged mainly because of how
> Emacs's release cadence does not line up well with Debian's. So having them
> separately packaged means we can ship newer versions of the addons even if
> we're having to ship an older version of Emacs.
>
> This scheme requires, however, that we don't allow it to ever transpire that
> the version in src:emacs is newer than the version in the separate source
> package, because Emacs prefers to load the separately installed version to the
> bundled version, even when the latter has a higher version number.
> Unfortunately, src:org-mode is undermaintained, and so precisely that
> situation has arisen in bookworm.
>
> We can resolve this by temporarily changing bin:elpa-org as described above,
> for bookworm, and then populating it again after the freeze.
What's the plan for the future? Is this a one-off exercise or do you
intent to pull this trick more often?
IIRC other ecosystems (like ruby) have the main package also (versioned)
Provides these add-ons, such that when packages Depend on it, the main
package can provide it without needing the add-on. That way, you could
prevent shipping the package in a stable release when it's behind and
have a newer version if it's available. Has such a scheme been
considered? If yes, what's the drawback?
Paul
Hi,
I haven't thought this trough, but it immediately triggered questions:
On 08-05-2023 20:46, Sean Whitton wrote:
> A number of Emacs addon packages which have their own source packages also
> have versions shipped in src:emacs's binary packages (upstream calls these
> "core" ELPA packages). We have them separately packaged mainly because of how
> Emacs's release cadence does not line up well with Debian's. So having them
> separately packaged means we can ship newer versions of the addons even if
> we're having to ship an older version of Emacs.
>
> This scheme requires, however, that we don't allow it to ever transpire that
> the version in src:emacs is newer than the version in the separate source
> package, because Emacs prefers to load the separately installed version to the
> bundled version, even when the latter has a higher version number.
> Unfortunately, src:org-mode is undermaintained, and so precisely that
> situation has arisen in bookworm.
>
> We can resolve this by temporarily changing bin:elpa-org as described above,
> for bookworm, and then populating it again after the freeze.
What's the plan for the future? Is this a one-off exercise or do you
intent to pull this trick more often?
IIRC other ecosystems (like ruby) have the main package also (versioned)
Provides these add-ons, such that when packages Depend on it, the main
package can provide it without needing the add-on. That way, you could
prevent shipping the package in a stable release when it's behind and
have a newer version if it's available. Has such a scheme been
considered? If yes, what's the drawback?
Paul
Paul Gevers
May 15, 2023, 3:30:06 PM5/15/23
to
Control: tag -1 moreinfo
Hi,
On 10-05-2023 17:21, Sean Whitton wrote:
> We don't have a real plan for the future, aside from trying to keep
> these packages up-to-date. It would be good to have a script that we
> could run right after uploading new versions of Emacs, that would find
> addons that are now behind.
> So, we'd like it to be one-off, but due to limited manpower on the team,
> I can't pretend that it couldn't happen again.
>
> Ultimately I think that the correct fix is for Emacs to learn to load
> the version of the package that has the highest version number.
> So, I think this is, at bottom, an upstream limitation. But I might be
> wrong about that.
> generate the required Provides values from the Emacs source.
Hmm, OK. Can you please share the debdiff? Unless I see very weird
things, I'll approve it.
Paul
Hi,
On 10-05-2023 17:21, Sean Whitton wrote:
> We don't have a real plan for the future, aside from trying to keep
> these packages up-to-date. It would be good to have a script that we
> could run right after uploading new versions of Emacs, that would find
> addons that are now behind.
> So, we'd like it to be one-off, but due to limited manpower on the team,
> I can't pretend that it couldn't happen again.
>
> Ultimately I think that the correct fix is for Emacs to learn to load
> the version of the package that has the highest version number.
> So, I think this is, at bottom, an upstream limitation. But I might be
> wrong about that.
>
>> IIRC other ecosystems (like ruby) have the main package also
>> (versioned) Provides these add-ons, such that when packages Depend on
>> it, the main package can provide it without needing the add-on. That
>> way, you could prevent shipping the package in a stable release when
>> it's behind and have a newer version if it's available. Has such a
>> scheme been considered? If yes, what's the drawback?
>
> We haven't considered it. It would be a case of writing a script to
>> IIRC other ecosystems (like ruby) have the main package also
>> (versioned) Provides these add-ons, such that when packages Depend on
>> it, the main package can provide it without needing the add-on. That
>> way, you could prevent shipping the package in a stable release when
>> it's behind and have a newer version if it's available. Has such a
>> scheme been considered? If yes, what's the drawback?
>
> generate the required Provides values from the Emacs source.
Hmm, OK. Can you please share the debdiff? Unless I see very weird
things, I'll approve it.
Paul
David Bremner
May 20, 2023, 9:40:05 AM5/20/23
to
David Bremner <da...@tethera.net> writes:
> 1m1.2s ERROR: FAIL: Package purging left files on system:
> /root/.ssh/ not owned
> /var/cache/private/ not owned
> /var/lib/private/ not owned
> /var/lib/systemd/coredump/ not owned
> /var/lib/systemd/pstore/ not owned
> /var/log/private/ not owned
>
I dove down this rabbit-hole a bit, not enough to figure the ultimate
cause, but enough to notice these files are also because of
"apt install systemd". So no related to org-mode. FWIW, systemd is
pulled in by emacs-gtk.
d
> 1m1.2s ERROR: FAIL: Package purging left files on system:
> /root/.ssh/ not owned
> /var/cache/private/ not owned
> /var/lib/private/ not owned
> /var/lib/systemd/coredump/ not owned
> /var/lib/systemd/pstore/ not owned
> /var/log/private/ not owned
>
I dove down this rabbit-hole a bit, not enough to figure the ultimate
cause, but enough to notice these files are also because of
"apt install systemd". So no related to org-mode. FWIW, systemd is
pulled in by emacs-gtk.
d
Paul Gevers
Jun 1, 2023, 5:20:06 AM6/1/23
to
Dear David,
On 20-05-2023 15:34, David Bremner wrote:
> I dove down this rabbit-hole a bit, not enough to figure the ultimate
> cause, but enough to notice these files are also because of
> "apt install systemd". So no related to org-mode. FWIW, systemd is
> pulled in by emacs-gtk.
Earlier this week you asked about this unblock request on IRC, but the
bug is not actionable for us.
elbrus@respighi:~$ rmadison org-mode -sunstable,testing
org-mode | 9.5.2+dfsh-4 | testing | source, all
org-mode | 9.5.2+dfsh-4 | unstable | source, all
Aha, wait, I think you were still waiting for the ACK on the debdiff.
Sorry, I got confused by your last reply and I lost track of that.
The debdiff in message #36 looks OK. If the upload happens very soon, as
in today, than we'll see if we can have it migrate in time.
Paul
On 20-05-2023 15:34, David Bremner wrote:
> I dove down this rabbit-hole a bit, not enough to figure the ultimate
> cause, but enough to notice these files are also because of
> "apt install systemd". So no related to org-mode. FWIW, systemd is
> pulled in by emacs-gtk.
bug is not actionable for us.
elbrus@respighi:~$ rmadison org-mode -sunstable,testing
org-mode | 9.5.2+dfsh-4 | testing | source, all
org-mode | 9.5.2+dfsh-4 | unstable | source, all
Aha, wait, I think you were still waiting for the ACK on the debdiff.
Sorry, I got confused by your last reply and I lost track of that.
The debdiff in message #36 looks OK. If the upload happens very soon, as
in today, than we'll see if we can have it migrate in time.
Paul
David Bremner
Jun 1, 2023, 8:00:04 AM6/1/23
to
Paul Gevers <elb...@debian.org> writes:
>
> The debdiff in message #36 looks OK. If the upload happens very soon, as
> in today, than we'll see if we can have it migrate in time.
>
> Paul
Uploaded and built:
>
> The debdiff in message #36 looks OK. If the upload happens very soon, as
> in today, than we'll see if we can have it migrate in time.
>
> Paul
https://buildd.debian.org/status/fetch.php?pkg=org-mode&ver=9.5.2%2Bdfsh-5&arch=all&stamp=1685619895
d
0 new messages