Bug#1040690: Bug#1030394: Bug#1040690: reassign bug to correct package

[Richard Lewis]

On Mon, 24 Jul 2023, 11:35 David Bremner,  wrote:

> Richard Lewis  writes:
> > On Sun, 23 Jul 2023, 12:34 David Bremner,  wrote:
> >
>
> As far as the actual bug with failing to clean up, I ran
>
> % systemd-nspawn --machine bullseye /usr/lib/dh-elpa/helper/remove emacs
> dash 2.17.0
>
> and that cleans up the directory
>
> /usr/share/emacs/site-lisp/elpa/dash-2.17.0
>
> so the bug is at some other level of the stack. I guess I will have to
> look at the log from the upgrade, but I haven't had a chance to do that
> yet.
>

I was trying to understand when (and how ) your command above was intended
to be run as part of the upgrade. I cna see that in bullseye
/usr/lib/emacsen-common/packages/remove/elpa-dash would do it if called
with 'emacs'. but this is never called:

What happens in the 'apt upgrade' is:

the old emacsen-common prerm is called (' upgrade
'):

/var/lib/dpkg/info/emacsen-common.prerm upgrade 3.0.5

This calls:
/usr/lib/emacsen-common/emacs-package-remove --prerm emacsen-common

This calls:
/usr/lib/emacsen-common/packages/remove/emacsen-common

and at the end it _unlinks_:
/var/lib/emacsen-common/state/package/installed/emacsen-common

Then, apt prepares to unpack elpa-dash:

The elpa-dash prerm (from bullseye) is called as:
/var/lib/dpkg/info/elpa-dash.prerm upgrade
2.19.1+git20220608.1.0ac1ecf+dfsg-1)

but this starts with:

if [ -e /var/lib/emacsen-common/state/package/installed/emacsen-common -a
-x
  /usr/lib/emacsen-common/emacs-package-remove ] ; then
/usr/lib/emacsen-common/emacs-package-remove --prerm elpa-dash

fi

... and so does nothing,
because /var/lib/emacsen-common/state/package/installed/emacsen-common is
gone.

I couldnt add debug statements to the new maintainer scripts, but: reading
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

I think we are now at step 3: ' upgrade 
'

the elpa-dash preinst starts with
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove"
  ] ; then

so this does nothing.

then elpa-dash files are unpacked (step 4)
now /usr/lib/emacsen-common/packages/remove/elpa-dash contains
'usr/lib/dh-elpa/helper/remove $1 dash 2.19.1' so we can no longer remove
the old version


So the issue is that emacsen-common is unpacked before the elpa-dash package

Bug#1040690: Bug#1030394: Bug#1040690: reassign bug to correct package

[David Bremner]

Richard Lewis  writes:

> On Sun, 23 Jul 2023, 12:34 David Bremner,  wrote:
>
>> Did you start from a clean debootstrap here?  Because I don't see where
>> in your second reproducer the addon packages get installed.
>>
>
> no, i reused the chroot from the "first attempt" reproducer
> A clean recipe, not requiring any 'login' is:
>
> mkdir -p /tmp/bullseye
> cd /tmp/bullseye
> debootstrap bullseye . https://deb.debian.org/debian
> ln -s /tmp/bullseye /var/lib/machines/bullseye

btw, there is no need to use a symlink here (depends on space in /var I guess)

> systemd-nspawn --machine bullseye apt install emacs elpa-helpful

A smaller set of packages is just emacs and elpa-dash.


> sed -i /bullseye/bookworm/ tmp/bullseye/apt/sources.list

There are a couple of typos here, but I get what you meant. Should be
more like

 sed -i s/bullseye/bookworm/ /var/lib/machines/bullseye/etc/apt/sources.list


> systemd-nspawn --machine bullseye apt update
> systemd-nspawn --machine bullseye apt upgrade

I checked that changing this to full-upgrade does not change anything
> # this all works, including upgrading emacs :)

OK, this downgrades the importance of the crash when upgrading emacs in
a chroot, I agree.

As far as the actual bug with failing to clean up, I ran

% systemd-nspawn --machine bullseye /usr/lib/dh-elpa/helper/remove emacs  dash 
2.17.0

and that cleans up the directory

/usr/share/emacs/site-lisp/elpa/dash-2.17.0

so the bug is at some other level of the stack. I guess I will have to
look at the log from the upgrade, but I haven't had a chance to do that yet.

Bug#1030394: Bug#1040690: Bug#1030394: Bug#1040690: reassign bug to correct package

[Richard Lewis]

On Sun, 23 Jul 2023, 12:34 David Bremner,  wrote:

> Richard Lewis  writes:
>
> > I suspect a plain chroot isnt 'enough', i had success with
> systemd-nspawn:
> >
> > ln -s /tmp/bullseye/ /var/lib/machines
> >
> > # im sure there is a better way than these two lines
> > cp /etc/passwd bullseye/etc/passwd
> > cp /etc/shadow bullseye/etc/shadow
> >
> > systemd-nspawn --ephemeral --boot --machine bullseye
> > # (you dont really need --ephemeral of course)
> >
> > log into the container as root:
> > # apt install emacs-gtk
> >
> > (and say yes to allow the installation to finish)
> >
> > # ls /usr/share/emacs/site-lisp/elpa
> > dash-2.17.0  dash-functional-1.2.0  elisp-refs-1.4  helpful-0.18
> loop-1.3
> > dash-2.19.1  elisp-refs-1.3 f-0.20.0helpful-0.19
> s-1.12.0
> >
> > Shows the 'duplicate' dirs for the old versions of elpa-dash and
> elpa-helpful
> >
>
> Did you start from a clean debootstrap here?  Because I don't see where
> in your second reproducer the addon packages get installed.
>

no, i reused the chroot from the "first attempt" reproducer
A clean recipe, not requiring any 'login' is:

mkdir -p /tmp/bullseye
cd /tmp/bullseye
debootstrap bullseye . https://deb.debian.org/debian
ln -s /tmp/bullseye /var/lib/machines/bullseye
systemd-nspawn --machine bullseye apt install emacs elpa-helpful
# at this stage we have:
# $ ls /tmp/bullseye/usr/share/emacs/site-lisp/elpa/
# dash-2.17.0  dash-functional-1.2.0  elisp-refs-1.3  f-0.20.0
 helpful-0.18  loop-1.3  s-1.12.0
sed -i /bullseye/bookworm/ tmp/bullseye/apt/sources.list
#
systemd-nspawn --machine bullseye apt update
systemd-nspawn --machine bullseye apt upgrade
# this all works, including upgrading emacs :)
# but, old directories for elpa-dash and elpa-helpful and elpa-elisp-refs
have not been removed:
# $ ls /tmp/bullseye/usr/share/em$ ls
/tmp/bullseye/usr/share/emacs/site-lisp/elpa{,-src}
/tmp/bullseye/usr/share/emacs/site-lisp/elpa:
dash-2.17.0  dash-functional-1.2.0  elisp-refs-1.4  helpful-0.18  loop-1.3
dash-2.19.1  elisp-refs-1.3 f-0.20.0helpful-0.19  s-1.12.0

/tmp/bullseye/usr/share/emacs/site-lisp/elpa-src:
dash-2.19.1  dash-functional-1.2.0  elisp-refs-1.4  f-0.20.0  helpful-0.19
 loop-1.3  s-1.12.0

# nb: on the host /tmp/bullseye and the symlink /var/lib/machine/bullseye
should be removed once finished!

>

Bug#1030394: Bug#1040690: Bug#1030394: Bug#1040690: reassign bug to correct package

[David Bremner]

Richard Lewis  writes:

> I suspect a plain chroot isnt 'enough', i had success with systemd-nspawn:
>
> ln -s /tmp/bullseye/ /var/lib/machines
>
> # im sure there is a better way than these two lines
> cp /etc/passwd bullseye/etc/passwd
> cp /etc/shadow bullseye/etc/shadow
>
> systemd-nspawn --ephemeral --boot --machine bullseye
> # (you dont really need --ephemeral of course)
>
> log into the container as root:
> # apt install emacs-gtk
>
> (and say yes to allow the installation to finish)
>
> # ls /usr/share/emacs/site-lisp/elpa
> dash-2.17.0  dash-functional-1.2.0  elisp-refs-1.4  helpful-0.18  loop-1.3
> dash-2.19.1  elisp-refs-1.3 f-0.20.0helpful-0.19  s-1.12.0
>
> Shows the 'duplicate' dirs for the old versions of elpa-dash and elpa-helpful
>

Did you start from a clean debootstrap here?  Because I don't see where
in your second reproducer the addon packages get installed.

Bug#1040690: Bug#1030394: Bug#1040690: reassign bug to correct package

[Richard Lewis]

I suspect a plain chroot isnt 'enough', i had success with systemd-nspawn:

ln -s /tmp/bullseye/ /var/lib/machines

# im sure there is a better way than these two lines
cp /etc/passwd bullseye/etc/passwd
cp /etc/shadow bullseye/etc/shadow

systemd-nspawn --ephemeral --boot --machine bullseye
# (you dont really need --ephemeral of course)

log into the container as root:
# apt install emacs-gtk

(and say yes to allow the installation to finish)

# ls /usr/share/emacs/site-lisp/elpa
dash-2.17.0  dash-functional-1.2.0  elisp-refs-1.4  helpful-0.18  loop-1.3
dash-2.19.1  elisp-refs-1.3 f-0.20.0helpful-0.19  s-1.12.0

Shows the 'duplicate' dirs for the old versions of elpa-dash and elpa-helpful

Additionally:
# echo "(require 'helpful nil t)" > ~/.emacs
# emacs --no-init-file --batch --eval "(byte-compile-file \".emacs\")"

# reproduces the warnings:

Loading /etc/emacs/site-start.d/00debian.el (source)...
Warning (comp): Cannot look-up eln file as no source file was found
for /usr/share/emacs/site-lisp/elpa/helpful-0.18/helpful.elc
Warning (comp): Cannot look-up eln file as no source file was found
for /usr/share/emacs/site-lisp/elpa/elisp-refs-1.3/elisp-refs.elc
Warning (comp): Cannot look-up eln file as no source file was found
for /usr/share/emacs/site-lisp/elpa/dash-2.17.0/dash.elc
Warning (comp): Cannot look-up eln file as no source file was found
for /usr/share/emacs/site-lisp/elpa/loop-1.3/loop.elc
Warning (comp): Cannot look-up eln file as no source file was found
for /usr/share/emacs/site-lisp/elpa/dash-functional-1.2.0/dash-functional.elc

## to cleanup:
# close the container by pressing C-] several times
# rm /var/lib/machines/bullseye and /tmp/bullseye

Bug#1030394: Bug#1040690: reassign bug to correct package

[David Bremner]

David Bremner  writes:

>>
>> chroot . apt install emacs elpa-helpful

Try the same set of steps without elpa-helpful, and the upgrade still
fails with

Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
>>Error occurred processing /usr/share/emacs/site-lisp/debian-s
tartup.el: File error (("Doing chmod" "Operation not supported"
 "/usr/share/emacs/site-lisp/debian-startup.elc90iTVh"))

At this point dh-elpa is not involved. It seems most likely to be an
Emacs 28 bug, but I guess it could also be an issue with
emacsen-common.

Bug#1030394: Bug#1040690: reassign bug to correct package

[David Bremner]

Richard Lewis  writes:

> An attempt to reproduce - partially successful, maybe reveals deeper issues!
>
> su -
> mkdir /tmp/bullseye
> cd /tmp/bullseye
> debootstrap bullseye . https://deb.debian.org/debian
>
> chroot . apt install emacs elpa-helpful
>
> sed -i s/bullseye/bookworm/ ./etc/apt/sources.list
> chroot . apt update
> chroot . apt upgrade

Thanks Richard that does seem like progress.

I chrooted into to "bullseye" after the upgrade failure, and narrowed
the failing command down to

$ emacs --quick --batch -l package --eval "(setq package-user-dir 
\"/nonexistent\")" --eval "(add-to-list 'package-directory-list 
\"/usr/share/emacs/site-lisp/elpa-src\")" -f package-initialize -f 
batch-byte-compile *.el

I'm not sure why that command should be be failing, certainly I can
chmod the file manually (as root).

Bug#1030394: Bug#1040690: reassign bug to correct package

[Richard Lewis]

An attempt to reproduce - partially successful, maybe reveals deeper issues!

su -
mkdir /tmp/bullseye
cd /tmp/bullseye
debootstrap bullseye . https://deb.debian.org/debian

chroot . apt install emacs elpa-helpful

sed -i s/bullseye/bookworm/ ./etc/apt/sources.list
chroot . apt update
chroot . apt upgrade

# This fails with:
Setting up tasksel-data (3.73) ...
[15/1797]
Setting up emacs-common (1:28.2+1-15) ...
Setting up emacs-bin-common (1:28.2+1-15) ...
Setting up emacs-gtk (1:28.2+1-15) ...
tsort: -: input contains a loop:
tsort: elpa-dash
tsort: emacsen-common
tsort: -: input contains a loop:
tsort: elpa-s
tsort: emacsen-common
Install elpa-dash for emacs
install/dash-2.19.1: Handling install of emacsen flavor emacs
install/dash-2.19.1: byte-compiling for emacs
>>Error occurred processing dash.el: File error (("Doing chmod" "Operation not 
>>supported" "/usr/share/emacs/site-lisp/elpa/dash-2.19.1/dash.
elceCdFwM"))
ERROR: install script from elpa-dash package failed
dpkg: error processing package emacs-gtk (--configure):
 installed emacs-gtk package post-installation script subprocess
returned error exit status 1
dpkg: dependency problems prevent configuration of emacs:
 emacs depends on emacs-gtk (>= 1:27.1) | emacs-lucid (>= 1:27.1) |
emacs-nox (>= 1:27.1); however:
  Package emacs-gtk is not configured yet.
  Package emacs-lucid is not installed.
  Package emacs-nox is not installed.
dpkg: error processing package emacs (--configure):
 dependency problems - leaving unconfigured
Processing triggers for hicolor-icon-theme (0.17-2) ...
Processing triggers for libc-bin (2.36-9+deb12u1) ...
Processing triggers for debianutils (5.7-0.4) ...
Processing triggers for install-info (6.8-6+b1) ...
Processing triggers for ca-certificates (20230311) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
Processing triggers for libgdk-pixbuf-2.0-0:amd64 (2.42.10+dfsg-1+b1) ...
Errors were encountered while processing:
 emacs-gtk
 emacs
E: Sub-process /usr/bin/dpkg returned an error code (1)

BUT, /tmp/bullseye/usr/share/emacs/site-lisp/elpa/helpful-0.18/  has
the broken symlinks - and presumably should not exist at all. so maybe
this helps narrow it down!

Bug#1030394: Bug#1040690: reassign bug to correct package

[Nikolaus Rath]

Hi,

In case it helps, I also still have the "apt dist-upgrade" output for an 
affected system.

I don't remember installing any elpa packages from non-stable, but I can't rule 
it out either.

Best,
-Nikolaus

Bug#1030394: Bug#1040690: reassign bug to correct package

[Richard Lewis]

On Fri, 21 Jul 2023 at 23:39, Nicholas D Steeves  wrote:

> retitle 1030394 dh-elpa: elpa-csv-mode 1.20 not cleaned up

important to note that it's not just this one package, but many elpa
packages (but not all) which were either upgraded or purged as part of
the upgrade: I get the same set of warnings on two separate systems.
(I have elpa-csv-mode and no issue, but i don't know if i had it
installed in bullseye)

Warnings i have:
Warning (comp): Cannot look-up eln file as no source file was found
for /usr/share/emacs/site-lisp/elpa/helpful-0.18/helpful.elc
Warning (comp): Cannot look-up eln file as no source file was found
for /usr/share/emacs/site-lisp/elpa/elisp-refs-1.3/elisp-refs.elc
Warning (comp): Cannot look-up eln file as no source file was found
for /usr/share/emacs/site-lisp/elpa/dash-2.17.0/dash.elc
Warning (comp): Cannot look-up eln file as no source file was found
for /usr/share/emacs/site-lisp/elpa/loop-1.3/loop.elc
Warning (comp): Cannot look-up eln file as no source file was found
for /usr/share/emacs/site-lisp/elpa/dash-functional-1.2.0/

But i also have duplicate subdirectories in
/usr/share/emacs/site-lisp/elpa for dash,elisp-refs,git-commit,
helpful, magit and with-editor
Lots of broken symlinks, eg
/usr/share/emacs/site-lisp/elpa/transient-0.2.0.30 has
transient-autoloads.el ->
/usr/share/emacs/site-lisp/elpa-src/transient-0.2.0.30//transient-autoloads.el
which doesnt exist
Lots of 'empty' (32-byte) Install.log.gz files such as
/usr/share/emacs/site-lisp/elpa/rainbow-delimiters-2.1.5/Install.log.gz
-- which unzul to an empty file

Current versions of packages
elpa-helpful:all/bookworm 0.19-2 uptodate
elpa-elisp-refs:all/bookworm 1.4-1 uptodate
elpa-dash:all/bookworm 2.19.1+git20220608.1.0ac1ecf+dfsg-1 uptodate
elpa-loop:all not installed # was installed as a recommends of
something in bullseye i assume
elpa-csv-mode:all/bookworm 1.22-1 uptodate # i dont know if i had this
via dependencies in bullseye

> To all affected users: Do you remember if you ever manually installed an
> affected elpa-package from sid/unstable or from testing?  I'm curious if
> this might be part of the trigger condition.  Likewise, do you remember
> if you installed dh-elpa from backports?  While I think both of these
> cases are unlikely to have caused problems, one might as well be
> thorough!

I have never installed anything emacs-related from anywhere other than stable.
All systems have only run stable, and have been upgraded from stable
to stable (from stretch i think).

While I havn't tried to make it reproducible, i did reproduce it in
the sense that two separate systems which had the same set of
emacs-related packages installed ended up with the same warnings. I
have the upgrade log for one - are there bits that are helpful to look
at - i didnt see anything complain, but the new emacs and new dh-elpa
were unpacked before the other elpa- packages (i think)

I can see dh-elpa tried to purge the old files, but presumably this
did not actualy work, although there is no error message:

dh-elpa: purging flavor specific files for emacs^M
Remove elpa-helpful for emacs^M
remove/helpful-0.19: Handling removal of emacsen flavor emacs^M
dh-elpa: purging flavor specific files for emacs^M

(i was surprised it says removing 0.19 not 0.18 but all the other elpa
packages have the new version here too.
this bit came after new emacs and dh-elpa were unpacked but before
they were 'Set up' (configured?))

Later there is some tsort issue,

Setting up elpa-helpful (0.19-2) ...^M
tsort: -: input contains a loop:^M
tsort: elpa-dash^M
tsort: emacsen-common^M
tsort: -: input contains a loop:^M
tsort: emacsen-common^M
tsort: elpa-s^M


My emacs-related packages: all would have been at the previous
bullseye point-release/security upgrade before upgrading:
  emacs-gtk, emacs-el
  emacs-common-non-dfsg, emacs-goodies-el, bbdb3,  elpa-debian-el,
  elpa-dpkg-dev-el, elpa-org, elpa-org-bullets, elpa-company,
elpa-dumb-jump, elpa-flycheck, elpa-helpful, elpa-systemd,
  elpa-magit, elpa-ag, elpa-rainbow-delimiters, elpa-rich-minority

(Plus all recommends. And a couple of locally packaged variants -
which were not changed on upgrade but did use dh-elpa).
I used aptitude to upgrade to bookworm, and set anything removed to be purged.