Bug#1035757: unblock: org-mode/9.5.2+dfsh-5
Hi, On 01-06-2023 13:50, David Bremner wrote: Uploaded and built: And unblocked. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1035757: unblock: org-mode/9.5.2+dfsh-5
Paul Gevers 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: https://buildd.debian.org/status/fetch.php?pkg=org-mode=9.5.2%2Bdfsh-5=all=1685619895 d
Bug#1035757: unblock: org-mode/9.5.2+dfsh-5
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 OpenPGP_signature Description: OpenPGP digital signature
Bug#1035757: unblock: org-mode/9.5.2+dfsh-5
David Bremner 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
Bug#1035757: unblock: org-mode/9.5.2+dfsh-5
Hello, On Mon 15 May 2023 at 09:21PM +02, Paul Gevers wrote: > Hmm, OK. Can you please share the debdiff? Unless I see very weird > things, I'll approve it. Thanks. David Bremner is hoping to work on this shortly. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035757: unblock: org-mode/9.5.2+dfsh-5
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. 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 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 OpenPGP_signature Description: OpenPGP digital signature
Bug#1035757: unblock: org-mode/9.5.2+dfsh-5
control: tag -1 - moreinfo Hello, Thanks for looking. On Mon 08 May 2023 at 09:33PM +02, Paul Gevers wrote: > What's the plan for the future? Is this a one-off exercise or do you > intent to pull this trick more often? 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 generate the required Provides values from the Emacs source. -- Sean Whitton signature.asc Description: PGP signature
Bug#1035757: unblock: org-mode/9.5.2+dfsh-5
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 OpenPGP_signature Description: OpenPGP digital signature
Bug#1035757: unblock: org-mode/9.5.2+dfsh-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: 1033...@bugs.debian.org, 1035...@bugs.debian.org, em...@packages.debian.org We (the Debian Emacsen team) would like to modify bin:elpa-org in bookworm to 1. install no files outside of /usr/share/doc; and 2. newly hard-depend on bin:emacs. A debdiff doesn't seem very useful for review purposes in this case, so I'm not attaching one, but one of us can prepare one if wanted. Nothing has been uploaded yet. (Thank you to bug reporter Maxim Nikulin for suggesting shipping an empty package.) [ Reason ] 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. [ Impact ] If a user installs one of elpa-org's rdeps, such as elpa-org-contrib, then currently this has the effect of *downgrading* the version of Org-mode that Emacs will actually load. This could break all kinds of other things the user has installed, or their own Emacs Lisp code. It also creates confusion, because outside of Debian, you have to try extra hard to create a situation in which you have an older version of Org-mode loaded than the one that ships with Emacs. So users might report bugs to upstreams that are caused only by this strange situation in Debian. [ Tests ] The test would be to 'apt-get install elpa-org-contrib', start Emacs, and use 'M-x org-version' to confirm that you get version 9.5.5. We'd want to run all possible piuparts tests too. [ Risks ] This might expose bugs in other leaf packages that turn out not to be compatible with the newer Org-mode. However, that's preferable to the current situation. The emacsen-common scripts might not like the situation in which a package suddenly ships nothing. piuparts testing would reveal whether this is actually a problem. I'm sorry that this hasn't been done yet: I don't myself have time to do anything other than write up this unblock request, and I thought it would be appropriate to ask for your opinion on the basic idea before doing anything else. unblock org-mode/9.5.2+dfsh-5 -- Sean Whitton signature.asc Description: PGP signature
