Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #238927 > unrolled thread

Buster to Bullseye upgrade problem

Back to article view | Back to linux.debian.user

Contents

  Buster to Bullseye upgrade problem "Gareth Evans" <donotspam@fastmail.fm> - 2021-08-18 01:50 +0200
    Re: Buster to Bullseye upgrade problem "Gareth Evans" <donotspam@fastmail.fm> - 2021-08-18 17:20 +0200
      Re: Buster to Bullseye upgrade problem piorunz <piorunz@gmx.com> - 2021-08-19 00:40 +0200
        Re: Buster to Bullseye upgrade problem "Gareth Evans" <donotspam@fastmail.fm> - 2021-08-19 05:10 +0200
          Re: Buster to Bullseye upgrade problem David Wright <deblis@lionunicorn.co.uk> - 2021-08-19 07:00 +0200
            Re: Buster to Bullseye upgrade problem "Gareth Evans" <donotspam@fastmail.fm> - 2021-08-19 08:50 +0200
              Re: Buster to Bullseye upgrade problem David Wright <deblis@lionunicorn.co.uk> - 2021-08-20 05:50 +0200
                Re: Buster to Bullseye upgrade problem Greg Wooledge <greg@wooledge.org> - 2021-08-20 13:40 +0200
                  Re: Buster to Bullseye upgrade problem "Gareth Evans" <donotspam@fastmail.fm> - 2021-08-20 14:40 +0200
                Re: Buster to Bullseye upgrade problem "Gareth Evans" <donotspam@fastmail.fm> - 2021-08-20 15:20 +0200
                  Re: Buster to Bullseye upgrade problem Sven Hartge <sven@svenhartge.de> - 2021-08-21 14:50 +0200
                    Re: Buster to Bullseye upgrade problem "Gareth Evans" <donotspam@fastmail.fm> - 2021-08-21 18:00 +0200
                  Re: Buster to Bullseye upgrade problem David Wright <deblis@lionunicorn.co.uk> - 2021-08-22 06:40 +0200
                    Re: Buster to Bullseye upgrade problem "Gareth Evans" <donotspam@fastmail.fm> - 2021-08-22 14:20 +0200
                      Re: Buster to Bullseye upgrade problem "Gareth Evans" <donotspam@fastmail.fm> - 2021-08-22 14:30 +0200
                      Re: Buster to Bullseye upgrade problem David Wright <deblis@lionunicorn.co.uk> - 2021-08-22 16:40 +0200
                        Re: Buster to Bullseye upgrade problem "Gareth Evans" <donotspam@fastmail.fm> - 2021-08-23 09:30 +0200

#238927 — Buster to Bullseye upgrade problem

Hello,

I upgraded from Buster stable to Bullseye stable last night, with apparent success eventually, but it went less than smoothly and I would be grateful for any advice as to why that may have been.

I followed the preparation advice at

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html

and it seemed to me that there were no non-Debian packages in apt-forktracer output, although I'm afraid I didn't save the list.

The upgrade process stopped abruptly a couple of times, once without any indication as to why.

$ cat /etc/apt/sources.list
deb http://deb.debian.org/debian/ bullseye main contrib non-free
deb http://deb.debian.org/debian/ bullseye-updates main contrib non-free
#deb http://deb.debian.org/debian bullseye-proposed-updates main contrib non-free
deb http://deb.debian.org/debian-security/ bullseye-security main contrib non-free
deb http://deb.debian.org/debian/ bullseye-backports main contrib non-free


>From script output:

# apt full-upgrade
[...]
Errors were encountered while processing:
 /tmp/apt-dpkg-install-2vllSE/09-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
<upgrade stopped, etckeeper output snipped>
E: Sub-process /usr/bin/dpkg returned an error code (1)

# apt install --fix-broken
[...]
Setting up zfs-initramfs (2.0.3-9) ...
Processing triggers for initramfs-tools (0.133+deb10u1) ...
update-initramfs: Generating /boot/initrd.img-4.19.0-17-amd64

# apt full-upgrade
[...]
Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
<upgrade stopped, etckeeper output snipped>
W: APT had planned for dpkg to do more than it reported back (8974 vs 9007).
   Affected packages: texlive-fonts-recommended:amd64 texlive-lang-greek:amd64 texlive-latex-base:amd64 texlive-latex-extra:amd64 texlive-latex-recommended:amd64 texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64

# apt full-upgrade
[...]

Apparent success...

$ apt policy *gir*bad*
gir1.2-gst-plugins-bad-1.0:
  Installed: 1.18.4-3
  Candidate: 1.18.4-3
  Version table:
 *** 1.18.4-3 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        100 /var/lib/dpkg/status

$ cat /etc/debian_version
11.0

$ uname -a
Linux <hostname> 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 GNU/Linux

Reboots without issue. 

Is there any way to verify an upgrade completed properly?  Would there be obvious errors on exit if it didn't?

Thanks,
Gareth

[toc] | [next] | [standalone]

#238972

On Wed 18 Aug 2021, at 00:44, Gareth Evans <donotspam@fastmail.fm> wrote:
> Hello,
> 
> I upgraded from Buster stable to Bullseye stable last night, with 
> apparent success eventually, but it went less than smoothly and I would 
> be grateful for any advice as to why that may have been.
> 
> I followed the preparation advice at
> 
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html
> 
> and it seemed to me that there were no non-Debian packages in 
> apt-forktracer output, although I'm afraid I didn't save the list.
> 
> The upgrade process stopped abruptly a couple of times, once without 
> any indication as to why.
> 
> $ cat /etc/apt/sources.list
> deb http://deb.debian.org/debian/ bullseye main contrib non-free
> deb http://deb.debian.org/debian/ bullseye-updates main contrib non-free
> #deb http://deb.debian.org/debian bullseye-proposed-updates main 
> contrib non-free
> deb http://deb.debian.org/debian-security/ bullseye-security main 
> contrib non-free
> deb http://deb.debian.org/debian/ bullseye-backports main contrib 
> non-free
> 
> 
> >From script output:
> 
> # apt full-upgrade
> [...]
> Errors were encountered while processing:
>  /tmp/apt-dpkg-install-2vllSE/09-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb
> <upgrade stopped, etckeeper output snipped>
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> # apt install --fix-broken
> [...]
> Setting up zfs-initramfs (2.0.3-9) ...
> Processing triggers for initramfs-tools (0.133+deb10u1) ...
> update-initramfs: Generating /boot/initrd.img-4.19.0-17-amd64
> 
> # apt full-upgrade
> [...]
> Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> <upgrade stopped, etckeeper output snipped>
> W: APT had planned for dpkg to do more than it reported back (8974 vs 
> 9007).
>    Affected packages: texlive-fonts-recommended:amd64 
> texlive-lang-greek:amd64 texlive-latex-base:amd64 
> texlive-latex-extra:amd64 texlive-latex-recommended:amd64 
> texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
> 
> # apt full-upgrade
> [...]
> 
> Apparent success...
> 
> $ apt policy *gir*bad*
> gir1.2-gst-plugins-bad-1.0:
>   Installed: 1.18.4-3
>   Candidate: 1.18.4-3
>   Version table:
>  *** 1.18.4-3 500
>         500 http://deb.debian.org/debian bullseye/main amd64 Packages
>         100 /var/lib/dpkg/status
> 
> $ cat /etc/debian_version
> 11.0
> 
> $ uname -a
> Linux <hostname> 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) 
> x86_64 GNU/Linux
> 
> Reboots without issue. 
> 
> Is there any way to verify an upgrade completed properly?  Would there 
> be obvious errors on exit if it didn't?
> 
> Thanks,
> Gareth
> 
> 

I have been digging/experimenting a bit more and have reverted to Buster several times by rolling back zfs snapshots to retry upgrading with different approaches:


(1) Minimal system upgrade, then full-upgrade, per

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-upgrading.en.html#minimal-upgrade

Minimal upgrade completed without issue, but the same problems with the same solutions as in my first email appeared in the full-upgrade part of the process.


(2) Single-line sources.list:

deb http://deb.debian.org/debian/ bullseye main contrib non-free

Same approach as in (1), same problems and solutions.


(3) Minimal upgrade followed by "apt upgrade" (not full-upgrade) - this is apparently not to be recommended! (I know this is what full/dist-upgrade is for, but I thought I'd see what happened.)  Fwiw...

There were no breakages in the upgrade process in this approach, but then the system dropped to initramfs on reboot due to lack of zfs modules (much building having been conspicuous by its absence).  Booting into a previous kernel at this stage got to graphical login, all Bullseye themed so far, but no desktop appeared after successful login, and *Buster* shutdown screen appeared after holding power off.  


So whatever way I approach it, the upgrade doesn't run smoothly at all, though it seems to succeed eventually using a combination of 

[optionally...] apt upgrade --without-new-pkgs
apt full-upgrade
apt install --fix-broken
apt full-upgrade x2


As for causes...

syslog is silent on the issues

/var/log/apt/term.log shows:

--
Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
[1mdpkg:[0m error processing archive /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which is also in package pitivi 0.999-1+b1
[1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal (Broken pipe)
--

However it gives no clue as to why the upgrade stops again later, with things for apt still to do, after the second (of three) "apt full-upgrade"s, saying merely:

--
Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
Log ended: 2021-08-18  11:09:56
--


A quick google shows etckeeper causes problems at times, but nothing along these lines afaics, and at least one person appears to succeed in using it while upgrading Buster -> Bullseye 

https://chris.hofstaedtler.name/blog/2021/04/bullseye-upgrade-notes.html


So afaict, I have an upgraded system:

$ cat /etc/debian_version
11.0

$ uname -a
Linux <hostname> 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 GNU/Linux

$ sudo apt update
[...]
All packages are up to date.

$ sudo apt full-upgrade
[...]
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.


But I would like to understand what's going wrong with this.

If anyone has theories/suggestions for me to test I would be happy to report results, especially if it might help others.  Is any of this bug report-worthy?  If so, against what?  

Thanks,
Gareth 

[toc] | [prev] | [next] | [standalone]

#238984

On 18/08/2021 16:14, Gareth Evans wrote:
> Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> [1mdpkg:[0m error processing archive /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb (--unpack):
>   trying to overwrite '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which is also in package pitivi 0.999-1+b1
> [1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal (Broken pipe)

IMO that's the source of your problem.
You have two packages fighting to overwrite the same file. You should
inspect them.
Are you sure they come from buster, not from foreign repository?

You have commands to check for this:

check if any packages are newer than repository (possibly foreign)
apt-show-versions | grep newer

check if any packages are foreign (not from Debian)
aptitude search '~i(!~ODebian)'


--

With kindest regards, piorunz.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

[toc] | [prev] | [next] | [standalone]

#238997

On Wed 18 Aug 2021, at 23:33, piorunz <piorunz@gmx.com> wrote:
> On 18/08/2021 16:14, Gareth Evans wrote:
> > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > [1mdpkg:[0m error processing archive /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb (--unpack):
> >   trying to overwrite '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which is also in package pitivi 0.999-1+b1
> > [1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal (Broken pipe)
>
 
> IMO that's the source of your problem.
> You have two packages fighting to overwrite the same file. You should
> inspect them.
> Are you sure they come from buster, not from foreign repository?

Apparently they are both from Buster.  Removing pitivi before upgrading improves things, but not completely plain sailing.

On Buster:

# aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
#

# apt-forktracer | sort 
libck0 (0.6.0-1.2~bpo10+1) [Debian Backports: 0.6.0-1.2~bpo10+1]
libnvpair3linux (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1]
libuutil3linux (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1]
libzfs4linux (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1]
libzpool4linux (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1]
sane-airscan (0.99.19-1~bpo10+1) [Debian Backports: 0.99.19-1~bpo10+1]
sysbench (1.0.18+ds-1~bpo10+1) [Debian Backports: 1.0.18+ds-1~bpo10+1]
zfs-dkms (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1 2.0.3-9~bpo10+1] [Debian: 0.7.12-2+deb10u2 0.7.12-2+deb10u2]
zfs-initramfs (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1 2.0.3-9~bpo10+1] [Debian: 0.7.12-2+deb10u2 0.7.12-2+deb10u2]
zfsutils-linux (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1] [Debian: 0.7.12-2+deb10u2]
zfs-zed (2.0.3-9~bpo10+1) [Debian Backports: 2.0.3-9~bpo10+1] [Debian: 0.7.12-2+deb10u2]

# aptitude search '~o'
#

# apt policy pitivi
pitivi:
  Installed: 0.999-1+b1
  Candidate: 0.999-1+b1
  Version table:
 *** 0.999-1+b1 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status

# apt-show-versions | grep newer
#

# aptitude search '~i(!~ODebian)'
#

# apt remove --purge pitivi

# apt upgrade --without-new-pkgs
(completes)

# apt full-upgrade
[...]
Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
<upgrade interrupted, etckeeper output snipped>
W: APT had planned for dpkg to do more than it reported back (7510 vs 7543).
   Affected packages: texlive-fonts-recommended:amd64 texlive-lang-greek:amd64 texlive-latex-base:amd64 texlive-latex-extra:amd64 texlive-latex-recommended:amd64 texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64

# apt full-upgrade
(completes)

Oh well.  Thanks.
G


> 
> You have commands to check for this:
> 
> check if any packages are newer than repository (possibly foreign)
> apt-show-versions | grep newer
> 
> check if any packages are foreign (not from Debian)
> aptitude search '~i(!~ODebian)'
> 
> 
> --
> 
> With kindest regards, piorunz.
> 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄⠀⠀⠀⠀
> 
> 

[toc] | [prev] | [next] | [standalone]

#238999

On Thu 19 Aug 2021 at 04:00:04 (+0100), Gareth Evans wrote:
> On Wed 18 Aug 2021, at 23:33, piorunz <piorunz@gmx.com> wrote:
> > On 18/08/2021 16:14, Gareth Evans wrote:
> > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > [1mdpkg:[0m error processing archive /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb (--unpack):
> > >   trying to overwrite '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which is also in package pitivi 0.999-1+b1
> > > [1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal (Broken pipe)
> >
>  
> > IMO that's the source of your problem.
> > You have two packages fighting to overwrite the same file. You should
> > inspect them.
> > Are you sure they come from buster, not from foreign repository?
> 
> Apparently they are both from Buster.

I'm afraid not. You need to check the version numbers more carefully.

$ apt policy gir1.2-gst-plugins-bad-1.0
gir1.2-gst-plugins-bad-1.0:
  Installed: (none)
  Candidate: 1.14.4-1+deb10u2
  Version table:
     1.14.4-1+deb10u2 990
        990 http://deb.debian.org/debian buster/main amd64 Packages
        990 http://security.debian.org/debian-security buster/updates/main amd64 Packages
$ apt-file list gir1.2-gst-plugins-bad-1.0 
gir1.2-gst-plugins-bad-1.0: /usr/lib/x86_64-linux-gnu/girepository-1.0/GstInsertBin-1.0.typelib
gir1.2-gst-plugins-bad-1.0: /usr/lib/x86_64-linux-gnu/girepository-1.0/GstMpegts-1.0.typelib
gir1.2-gst-plugins-bad-1.0: /usr/lib/x86_64-linux-gnu/girepository-1.0/GstPlayer-1.0.typelib
gir1.2-gst-plugins-bad-1.0: /usr/lib/x86_64-linux-gnu/girepository-1.0/GstWebRTC-1.0.typelib
gir1.2-gst-plugins-bad-1.0: /usr/share/doc/gir1.2-gst-plugins-bad-1.0/AUTHORS
gir1.2-gst-plugins-bad-1.0: /usr/share/doc/gir1.2-gst-plugins-bad-1.0/NEWS.gz
gir1.2-gst-plugins-bad-1.0: /usr/share/doc/gir1.2-gst-plugins-bad-1.0/README.Debian
gir1.2-gst-plugins-bad-1.0: /usr/share/doc/gir1.2-gst-plugins-bad-1.0/README.gz
gir1.2-gst-plugins-bad-1.0: /usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.Debian.gz
gir1.2-gst-plugins-bad-1.0: /usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.gz
gir1.2-gst-plugins-bad-1.0: /usr/share/doc/gir1.2-gst-plugins-bad-1.0/copyright
$ 

File list of package gir1.2-gst-plugins-bad-1.0 in bullseye of architecture amd64

/usr/lib/x86_64-linux-gnu/girepository-1.0/GstBadAudio-1.0.typelib
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstCodecs-1.0.typelib
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstInsertBin-1.0.typelib
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstMpegts-1.0.typelib
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstPlayer-1.0.typelib
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib ← new in bullseye
/usr/lib/x86_64-linux-gnu/girepository-1.0/GstWebRTC-1.0.typelib
/usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.Debian.gz
/usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.gz
/usr/share/doc/gir1.2-gst-plugins-bad-1.0/copyright

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#239009

On Thu 19 Aug 2021, at 05:50, David Wright <deblis@lionunicorn.co.uk> wrote:
> On Thu 19 Aug 2021 at 04:00:04 (+0100), Gareth Evans wrote:
> > On Wed 18 Aug 2021, at 23:33, piorunz <piorunz@gmx.com> wrote:
> > > On 18/08/2021 16:14, Gareth Evans wrote:
> > > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > > [1mdpkg:[0m error processing archive /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb (--unpack):
> > > >   trying to overwrite '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which is also in package pitivi 0.999-1+b1
> > > > [1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal (Broken pipe)
> > >
> >  
> > > IMO that's the source of your problem.
> > > You have two packages fighting to overwrite the same file. You should
> > > inspect them.
> > > Are you sure they come from buster, not from foreign repository?
> > 

Hi David,

> > Apparently they are both from Buster.
> 
> I'm afraid not. You need to check the version numbers more carefully.

I meant the packages (gir1.2-gst-plugins-bad-1.0, pitivi) being upgraded, rather than the versions replacing them, were both from Buster at the point of the upgrade (weren't they?)

On Bullseye now:

$ apt policy *gir*bad*
gir1.2-gst-plugins-bad-1.0:
  Installed: 1.18.4-3
  Candidate: 1.18.4-3
  Version table:
 *** 1.18.4-3 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        100 /var/lib/dpkg/status

$ aptitude why gir1.2-gst-plugins-bad-1.0
i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)

(having installed pitivi again after removing it before upgrading to see what difference it made)

I don't understand what the problem is/was - shouldn't apt just have handled this?

Have I misunderstood what you have shown/what you are saying?

Thanks,
Gareth

> 
> $ apt policy gir1.2-gst-plugins-bad-1.0
> gir1.2-gst-plugins-bad-1.0:
>   Installed: (none)
>   Candidate: 1.14.4-1+deb10u2
>   Version table:
>      1.14.4-1+deb10u2 990
>         990 http://deb.debian.org/debian buster/main amd64 Packages
>         990 http://security.debian.org/debian-security 
> buster/updates/main amd64 Packages
> $ apt-file list gir1.2-gst-plugins-bad-1.0 
> gir1.2-gst-plugins-bad-1.0: 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstInsertBin-1.0.typelib
> gir1.2-gst-plugins-bad-1.0: 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstMpegts-1.0.typelib
> gir1.2-gst-plugins-bad-1.0: 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstPlayer-1.0.typelib
> gir1.2-gst-plugins-bad-1.0: 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstWebRTC-1.0.typelib
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/AUTHORS
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/NEWS.gz
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/README.Debian
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/README.gz
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.Debian.gz
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.gz
> gir1.2-gst-plugins-bad-1.0: 
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/copyright
> $ 
> 
> File list of package gir1.2-gst-plugins-bad-1.0 in bullseye of 
> architecture amd64
> 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstBadAudio-1.0.typelib
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstCodecs-1.0.typelib
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstInsertBin-1.0.typelib
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstMpegts-1.0.typelib
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstPlayer-1.0.typelib
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib ← 
> new in bullseye
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstWebRTC-1.0.typelib
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.Debian.gz
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/changelog.gz
> /usr/share/doc/gir1.2-gst-plugins-bad-1.0/copyright
> 
> Cheers,
> David.
> 
> 

[toc] | [prev] | [next] | [standalone]

#239075

On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> On Thu 19 Aug 2021, at 05:50, David Wright <deblis@lionunicorn.co.uk> wrote:
> > On Thu 19 Aug 2021 at 04:00:04 (+0100), Gareth Evans wrote:
> > > On Wed 18 Aug 2021, at 23:33, piorunz <piorunz@gmx.com> wrote:
> > > > On 18/08/2021 16:14, Gareth Evans wrote:
> > > > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > > > [1mdpkg:[0m error processing archive /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb (--unpack):
> > > > >   trying to overwrite '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which is also in package pitivi 0.999-1+b1
> > > > > [1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal (Broken pipe)
> > > >
> > > > IMO that's the source of your problem.
> > > > You have two packages fighting to overwrite the same file. You should
> > > > inspect them.
> > > > Are you sure they come from buster, not from foreign repository?
> > > 
> > > Apparently they are both from Buster.
> > 
> > I'm afraid not. You need to check the version numbers more carefully.
> 
> I meant the packages (gir1.2-gst-plugins-bad-1.0, pitivi) being upgraded, rather than the versions replacing them, were both from Buster at the point of the upgrade (weren't they?)

One might assume so, but only you can check that. There are two logs
of the upgrade. /var/log/apt/history.log (and its predecessors) shows
the command issued, followed by the packages affected, with the old
and new version numbers in parentheses. /var/log/apt/term.log (and its
predecessors) shows the various packages being unpacked and then set
up. Again, there are old and new version numbers. And it's all timestamped.

BTW I can't immediately see why you would have
gir1.2-gst-plugins-bad-1.0 installed in buster (as a dependency),
because the only package that depends on it is
libgstreamer-plugins-bad1.0-dev, and I can't find anything that
depends on that.

> On Bullseye now:
> 
> $ apt policy *gir*bad*
> gir1.2-gst-plugins-bad-1.0:
>   Installed: 1.18.4-3
>   Candidate: 1.18.4-3
>   Version table:
>  *** 1.18.4-3 500
>         500 http://deb.debian.org/debian bullseye/main amd64 Packages
>         100 /var/lib/dpkg/status
> 
> $ aptitude why gir1.2-gst-plugins-bad-1.0
> i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)
> 
> (having installed pitivi again after removing it before upgrading to see what difference it made)
> 
> I don't understand what the problem is/was - 

To summarise,

/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib included
↓↙
↓

yes  buster    0.999-1+b1        pitivi
no   bullseye  2020.09.2-3       pitivi

no   buster    1.14.4-1+deb10u2  gir1.2-gst-plugins-bad-1.0
yes  bullseye  1.18.4-3          gir1.2-gst-plugins-bad-1.0

pitivi/bullseye depends on gir1.2-gst-plugins-bad-1.0 (>= 1.18.0) so
it can't be installed while buster's gir1.2-gst-plugins-bad-1.0 is there.

pitivi/buster must be removed before gir1.2-gst-plugins-bad-1.0/bullseye
is installed, to avoid having two versions of that file.

> shouldn't apt just have handled this?

AFAIK, assuming that buster was up-to-date at the start of the
dist-upgrade, and there were no "foreign" packages etc.
(I don't know anything about apt-forktracer.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#239084

On Thu, Aug 19, 2021 at 10:45:57PM -0500, David Wright wrote:
> One might assume so, but only you can check that. There are two logs
> of the upgrade. /var/log/apt/history.log (and its predecessors) shows
> the command issued, followed by the packages affected, with the old
> and new version numbers in parentheses. /var/log/apt/term.log (and its
> predecessors) shows the various packages being unpacked and then set
> up.

Huh.  I didn't know about the terminal session logs.  Nifty.

'Twould be nice if it showed the command which was typed before each
logged session, but still... nifty.

[toc] | [prev] | [next] | [standalone]

#239086

On Fri 20 Aug 2021, at 12:32, Greg Wooledge <greg@wooledge.org> wrote:
> On Thu, Aug 19, 2021 at 10:45:57PM -0500, David Wright wrote:
> > One might assume so, but only you can check that. There are two logs
> > of the upgrade. /var/log/apt/history.log (and its predecessors) shows
> > the command issued, followed by the packages affected, with the old
> > and new version numbers in parentheses. /var/log/apt/term.log (and its
> > predecessors) shows the various packages being unpacked and then set
> > up.
> 
> Huh.  I didn't know about the terminal session logs.  Nifty.
> 

> 'Twould be nice if it showed the command which was typed before each
> logged session, but still... nifty.

You may be aware of "script" which I have found useful for that. You have to overlook gibberishy characters though, as backspace and other special chars are included in the output file.

https://linux.die.net/man/1/script

You can set it up to run with new terminals, but I can't find the instructions to do so.

Kind regards
Gareth

[toc] | [prev] | [next] | [standalone]

#239087

On Fri 20 Aug 2021, at 04:45, David Wright <deblis@lionunicorn.co.uk> wrote:
> On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> > On Thu 19 Aug 2021, at 05:50, David Wright <deblis@lionunicorn.co.uk> wrote:
> > > On Thu 19 Aug 2021 at 04:00:04 (+0100), Gareth Evans wrote:
> > > > On Wed 18 Aug 2021, at 23:33, piorunz <piorunz@gmx.com> wrote:
> > > > > On 18/08/2021 16:14, Gareth Evans wrote:
> > > > > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > > > > [1mdpkg:[0m error processing archive /tmp/apt-dpkg-install-Un4rDW/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb (--unpack):
> > > > > >   trying to overwrite '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which is also in package pitivi 0.999-1+b1
> > > > > > [1mdpkg-deb:[0m [1;31merror:[0m paste subprocess was killed by signal (Broken pipe)
> > > > >
> > > > > IMO that's the source of your problem.
> > > > > You have two packages fighting to overwrite the same file. You should
> > > > > inspect them.
> > > > > Are you sure they come from buster, not from foreign repository?
> > > > 
> > > > Apparently they are both from Buster.
> > > 
> > > I'm afraid not. You need to check the version numbers more carefully.
> > 

Hello again,

Thanks David, for your clear explanation of the problem.

> > I meant the packages (gir1.2-gst-plugins-bad-1.0, pitivi) being upgraded, rather than the versions replacing them, were both from Buster at the point of the upgrade (weren't they?)
> 
> One might assume so, but only you can check that ...

I was mistaken in thinking that gir1.2-gst-plugins-bad-1.0 was installed in Buster in the first place.

[Buster]
$ apt policy gir*bad*
gir1.2-gst-plugins-bad-1.0:
  Installed: (none)
  Candidate: 1.14.4-1+deb10u2
  Version table:
     1.14.4-1+deb10u2 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        500 http://security.debian.org/debian-security buster/updates/main amd64 Packages

$ aptitude why gir1.2-gst-plugins-bad-1.0
Not currently installed
The candidate version 1.14.4-1+deb10u2 has priority optional
No dependencies require to install gir1.2-gst-plugins-bad-1.0

$ apt policy pitivi
pitivi:
  Installed: 0.999-1+b1
  Candidate: 0.999-1+b1
  Version table:
 *** 0.999-1+b1 500
        500 http://deb.debian.org/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status

So pitivi 0.999 as installed is a Buster package, and gir* is installed during the upgrade as a dependency of Bullseye's newer pitivi version.

[Bullseye] 
$ aptitude why gir1.2-gst-plugins-bad-1.0
i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)


The first upgrade interruption issue (repeated here for clarity):

--
Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
dpkg: error processing archive /tmp/apt-dpkg-install-YeCJ7K/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which is also in package pitivi 0.999-1+b1
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
--

appears to be a file conflict, per 

https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#file-conflicts

which includes that "File conflicts should not occur if you upgrade from a “pure” buster system..."

So I would like to know if apt is not handling this properly, or if the scenario of a file changing packages (see David's previous email) is an expected exception to the (sort of) rule.

Shouldn't pitivi 0.999 be disregarded anyway as it's being upgraded?  It's not a conflict involving two Bullseye packages, nor with one from Bullseye and one held/pinned etc, so I don't see why it should happen.

FWIW I followed s4.2 of the release notes ("start from pure Debian") meticulously
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#system-status

as well as running the commands kindly suggested by piorunz:

> On Wed 18 Aug 2021, at 23:33, piorunz <piorunz@gmx.com> wrote:
> [...]
> check if any packages are newer than repository (possibly foreign)
> apt-show-versions | grep newer
> 
> check if any packages are foreign (not from Debian)
> aptitude search '~i(!~ODebian)'

There is also no explanation in term.log, syslog or dpkg.log for the second interruption:

--
Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
[upgrade interrupted...]
W: APT had planned for dpkg to do more than it reported back (5014 vs 5047).
   Affected packages: texlive-fonts-recommended:amd64 texlive-lang-greek:amd64 texlive-latex-base:amd64 texlive-latex-extra:amd64 texlive-latex-recommended:amd64 texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
---

which occurs even if pitivi is removed before upgrading, and the warning doesn't appear in term.log either.

If anyone can shed further light, I would be interested, but it's not ultimately a roadblock to upgrading so possibly not worth worrying about.

Thanks,
Gareth


> ... There are two logs
> of the upgrade. /var/log/apt/history.log (and its predecessors) shows
> the command issued, followed by the packages affected, with the old
> and new version numbers in parentheses. /var/log/apt/term.log (and its
> predecessors) shows the various packages being unpacked and then set
> up. Again, there are old and new version numbers. And it's all timestamped.
> 
> BTW I can't immediately see why you would have
> gir1.2-gst-plugins-bad-1.0 installed in buster (as a dependency),
> because the only package that depends on it is
> libgstreamer-plugins-bad1.0-dev, and I can't find anything that
> depends on that.
> 
> > On Bullseye now:
> > 
> > $ apt policy *gir*bad*
> > gir1.2-gst-plugins-bad-1.0:
> >   Installed: 1.18.4-3
> >   Candidate: 1.18.4-3
> >   Version table:
> >  *** 1.18.4-3 500
> >         500 http://deb.debian.org/debian bullseye/main amd64 Packages
> >         100 /var/lib/dpkg/status
> > 
> > $ aptitude why gir1.2-gst-plugins-bad-1.0
> > i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)
> > 
> > (having installed pitivi again after removing it before upgrading to see what difference it made)
> > 
> > I don't understand what the problem is/was - 
> 
> To summarise,
> 
> /usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib included
> ↓↙
> ↓
> 
> yes  buster    0.999-1+b1        pitivi
> no   bullseye  2020.09.2-3       pitivi
> 
> no   buster    1.14.4-1+deb10u2  gir1.2-gst-plugins-bad-1.0
> yes  bullseye  1.18.4-3          gir1.2-gst-plugins-bad-1.0
> 
> pitivi/bullseye depends on gir1.2-gst-plugins-bad-1.0 (>= 1.18.0) so
> it can't be installed while buster's gir1.2-gst-plugins-bad-1.0 is there.
> 
> pitivi/buster must be removed before gir1.2-gst-plugins-bad-1.0/bullseye
> is installed, to avoid having two versions of that file.
> 
> > shouldn't apt just have handled this?
> 
> AFAIK, assuming that buster was up-to-date at the start of the
> dist-upgrade, and there were no "foreign" packages etc.
> (I don't know anything about apt-forktracer.)
> 
> Cheers,
> David.
> 
> 

[toc] | [prev] | [next] | [standalone]

#239114

Gareth Evans <donotspam@fastmail.fm> wrote:

> So I would like to know if apt is not handling this properly, or if
> the scenario of a file changing packages (see David's previous email)
> is an expected exception to the (sort of) rule.

> Shouldn't pitivi 0.999 be disregarded anyway as it's being upgraded?

No, because Debian Policy says that partial upgrades are supported and
must work.

> It's not a conflict involving two Bullseye packages, nor with one from
> Bullseye and one held/pinned etc, so I don't see why it should happen.

This might be a genuine bug in one of the two packages here, where a
Conflict/Breaks/Replaces dependendy was needed to move a file from one
package to another.

I think https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007 is part
of that problem.

Grüße,
S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#239120

On Sat 21 Aug 2021, at 13:42, Sven Hartge <sven@svenhartge.de> wrote:
> Gareth Evans <donotspam@fastmail.fm> wrote:
> 
> > So I would like to know if apt is not handling this properly, or if
> > the scenario of a file changing packages (see David's previous email)
> > is an expected exception to the (sort of) rule.
> 

Hi Sven,

> > Shouldn't pitivi 0.999 be disregarded anyway as it's being upgraded?
> 
> No, because Debian Policy says that partial upgrades are supported and
> must work.

Interesting, thanks.  I will have a look at [1,2,3] which seem relevant - any good refs would be appreciated, even for other distros if the concepts/techniques are similar.

Many thanks,
Gareth

[1] https://www.debian.org/doc/debian-policy/policy.pdf

[2] https://wiki.debian.org/Packaging/Intro

[3] https://www.debian.org/doc/manuals/developers-reference/index.en.html

> 
> > It's not a conflict involving two Bullseye packages, nor with one from
> > Bullseye and one held/pinned etc, so I don't see why it should happen.
> 
> This might be a genuine bug in one of the two packages here, where a
> Conflict/Breaks/Replaces dependendy was needed to move a file from one
> package to another.
> 
> I think https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007 is part
> of that problem.
> 
> Grüße,
> S°
> 
> -- 
> Sigmentation fault. Core dumped.
> 
> 

[toc] | [prev] | [next] | [standalone]

#239134

On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> On Fri 20 Aug 2021, at 04:45, David Wright <deblis@lionunicorn.co.uk> wrote:
> > On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:

> $ apt policy pitivi
> pitivi:
>   Installed: 0.999-1+b1
>   Candidate: 0.999-1+b1
>   Version table:
>  *** 0.999-1+b1 500
>         500 http://deb.debian.org/debian buster/main amd64 Packages
>         100 /var/lib/dpkg/status
> 
> So pitivi 0.999 as installed is a Buster package, and gir* is installed during the upgrade as a dependency of Bullseye's newer pitivi version.
> 
> [Bullseye] 
> $ aptitude why gir1.2-gst-plugins-bad-1.0
> i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)
> 
> 
> The first upgrade interruption issue (repeated here for clarity):
> 
> --
> Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> dpkg: error processing archive /tmp/apt-dpkg-install-YeCJ7K/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb (--unpack):
>  trying to overwrite '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which is also in package pitivi 0.999-1+b1
> dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> --
> 
> appears to be a file conflict, per 
> 
> https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#file-conflicts
> 
> which includes that "File conflicts should not occur if you upgrade from a “pure” buster system..."
> 
> So I would like to know if apt is not handling this properly, or if the scenario of a file changing packages (see David's previous email) is an expected exception to the (sort of) rule.

As Sven posted, it looks as if #965007 is the cause. A snag is
that, because the bug has been closed, it no longer shows up on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007
Moral: for major upgrades, always set "Archived and Unarchived"
on https://www.debian.org/Bugs/ because these sorts of bug are
likely to have been fixed by the time unstable→stable arrives.

But the workaround is to recall reading (!) § 4.5.4 in the Release
Notes, and force things as shown there.

> There is also no explanation in term.log, syslog or dpkg.log for the second interruption:
> 
> --
> Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> [upgrade interrupted...]
> W: APT had planned for dpkg to do more than it reported back (5014 vs 5047).
>    Affected packages: texlive-fonts-recommended:amd64 texlive-lang-greek:amd64 texlive-latex-base:amd64 texlive-latex-extra:amd64 texlive-latex-recommended:amd64 texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
> ---
> 
> which occurs even if pitivi is removed before upgrading, and the warning doesn't appear in term.log either.
> 
> If anyone can shed further light, I would be interested, but it's not ultimately a roadblock to upgrading so possibly not worth worrying about.

I'm no help here, as I've never seen output like that,
neither the "[ … ]", nor the "W: APT had planned …".
Is that output, with [upgrade interrupted...], a verbatim
copy/paste? Did this message appear spontaneously, or
because you yourself interrupted the process?

ISTR that history.log records intent, not achievement, whereas
term.log can obviously /only/ log achievement, so a comparison
of their two lists of packages for the interrupted step might give
a clue, perhaps a more fruitful one than just the list of Affected
packages quoted above.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#239164

On Sun 22 Aug 2021, at 05:36, David Wright <deblis@lionunicorn.co.uk> wrote:
> On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> > On Fri 20 Aug 2021, at 04:45, David Wright <deblis@lionunicorn.co.uk> wrote:
> > > On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> 
> > $ apt policy pitivi
> > pitivi:
> >   Installed: 0.999-1+b1
> >   Candidate: 0.999-1+b1
> >   Version table:
> >  *** 0.999-1+b1 500
> >         500 http://deb.debian.org/debian buster/main amd64 Packages
> >         100 /var/lib/dpkg/status
> > 
> > So pitivi 0.999 as installed is a Buster package, and gir* is installed during the upgrade as a dependency of Bullseye's newer pitivi version.
> > 
> > [Bullseye] 
> > $ aptitude why gir1.2-gst-plugins-bad-1.0
> > i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)
> > 
> > 
> > The first upgrade interruption issue (repeated here for clarity):
> > 
> > --
> > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > dpkg: error processing archive /tmp/apt-dpkg-install-YeCJ7K/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb (--unpack):
> >  trying to overwrite '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which is also in package pitivi 0.999-1+b1
> > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> > --
> > 
> > appears to be a file conflict, per 
> > 
> > https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#file-conflicts
> > 
> > which includes that "File conflicts should not occur if you upgrade from a “pure” buster system..."
> > 
> > So I would like to know if apt is not handling this properly, or if the scenario of a file changing packages (see David's previous email) is an expected exception to the (sort of) rule.
> 

Hi David,

> As Sven posted, it looks as if #965007 is the cause. A snag is
> that, because the bug has been closed, it no longer shows up on
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007
> Moral: for major upgrades, always set "Archived and Unarchived"
> on https://www.debian.org/Bugs/ because these sorts of bug are
> likely to have been fixed by the time unstable→stable arrives.
> 
> But the workaround is to recall reading (!) § 4.5.4 in the Release
> Notes, and force things as shown there.

I did see that but had already managed to make progress with apt install --fix-broken before twigging a file conflict (which is obvious once realised!)

> 
> > There is also no explanation in term.log, syslog or dpkg.log for the second interruption:
> > 
> > --
> > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > [upgrade interrupted...]
> > W: APT had planned for dpkg to do more than it reported back (5014 vs 5047).
> >    Affected packages: texlive-fonts-recommended:amd64 texlive-lang-greek:amd64 texlive-latex-base:amd64 texlive-latex-extra:amd64 texlive-latex-recommended:amd64 texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
> > ---
> > 
> > which occurs even if pitivi is removed before upgrading, and the warning doesn't appear in term.log either.
> > 
> > If anyone can shed further light, I would be interested, but it's not ultimately a roadblock to upgrading so possibly not worth worrying about.
> 
> I'm no help here, as I've never seen output like that,
> neither the "[ … ]", nor the "W: APT had planned …".
> Is that output, with [upgrade interrupted...], a verbatim
> copy/paste? Did this message appear spontaneously, or
> because you yourself interrupted the process?

"[...]" was just my way of showing output until this point has not been included in the paste, or that the paste includes gaps in output.  I use this by habit from academic writing but perhaps <snip> might be better for this purpose?  

The interrupt and following "W: APT had planned..." appeared spontaneously.  The upgrade stops, and [...] here stands in for etckeeper output, which I removed as noisy.

> 
> ISTR that history.log records intent, not achievement, whereas
> term.log can obviously /only/ log achievement, so a comparison
> of their two lists of packages for the interrupted step might give
> a clue, perhaps a more fruitful one than just the list of Affected
> packages quoted above.

I have just noticed that the logged action after which it trips up:

Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...

is related to what may be another problem of sorts.  php7.3 packages are removed as part of the upgrade but the config (mods-available) isn't changed.  Apache2 won't start after upgrading until I

a2dismod *php*7.3*

>From /var/log/syslog: 
Aug 22 00:29:58 qwerty systemd[1]: Starting The Apache HTTP Server...
Aug 22 00:29:58 qwerty apachectl[59333]: apache2: Syntax error on line 146 of /etc/apache2/apache2.conf: Syntax error on line 3 of /etc/apache2/mods-enabled/php7.3.load: Cannot load /usr/lib/apache2/modules/libphp7.3.so into server: /usr/lib/apache2/modules/libphp7.3.so: cannot open shared object file: No such file or directory
Aug 22 00:29:58 qwerty apachectl[59330]: Action 'start' failed.

Is it normal to have to do this sort of thing after a major upgrade?  If not, could a hiccup here be related to the upgrade breaking?

Thanks
Gareth




> 
> Cheers,
> David.
> 
> 

[toc] | [prev] | [next] | [standalone]

#239165

On Sun 22 Aug 2021, at 13:18, Gareth Evans <donotspam@fastmail.fm> wrote:
> On Sun 22 Aug 2021, at 05:36, David Wright <deblis@lionunicorn.co.uk> wrote:
> > On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> > > On Fri 20 Aug 2021, at 04:45, David Wright <deblis@lionunicorn.co.uk> wrote:
> > > > On Thu 19 Aug 2021 at 07:42:56 (+0100), Gareth Evans wrote:
> > 
> > > $ apt policy pitivi
> > > pitivi:
> > >   Installed: 0.999-1+b1
> > >   Candidate: 0.999-1+b1
> > >   Version table:
> > >  *** 0.999-1+b1 500
> > >         500 http://deb.debian.org/debian buster/main amd64 Packages
> > >         100 /var/lib/dpkg/status
> > > 
> > > So pitivi 0.999 as installed is a Buster package, and gir* is installed during the upgrade as a dependency of Bullseye's newer pitivi version.
> > > 
> > > [Bullseye] 
> > > $ aptitude why gir1.2-gst-plugins-bad-1.0
> > > i   pitivi Depends gir1.2-gst-plugins-bad-1.0 (>= 1.18.0)
> > > 
> > > 
> > > The first upgrade interruption issue (repeated here for clarity):
> > > 
> > > --
> > > Unpacking gir1.2-gst-plugins-bad-1.0:amd64 (1.18.4-3) ...
> > > dpkg: error processing archive /tmp/apt-dpkg-install-YeCJ7K/28-gir1.2-gst-plugins-bad-1.0_1.18.4-3_amd64.deb (--unpack):
> > >  trying to overwrite '/usr/lib/x86_64-linux-gnu/girepository-1.0/GstTranscoder-1.0.typelib', which is also in package pitivi 0.999-1+b1
> > > dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
> > > --
> > > 
> > > appears to be a file conflict, per 
> > > 
> > > https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#file-conflicts
> > > 
> > > which includes that "File conflicts should not occur if you upgrade from a “pure” buster system..."
> > > 
> > > So I would like to know if apt is not handling this properly, or if the scenario of a file changing packages (see David's previous email) is an expected exception to the (sort of) rule.
> > 
> 
> Hi David,
> 
> > As Sven posted, it looks as if #965007 is the cause. A snag is
> > that, because the bug has been closed, it no longer shows up on
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965007
> > Moral: for major upgrades, always set "Archived and Unarchived"
> > on https://www.debian.org/Bugs/ because these sorts of bug are
> > likely to have been fixed by the time unstable→stable arrives.
> > 
> > But the workaround is to recall reading (!) § 4.5.4 in the Release
> > Notes, and force things as shown there.
> 
> I did see that but had already managed to make progress with apt 
> install --fix-broken before twigging a file conflict (which is obvious 
> once realised!)
> 
> > 
> > > There is also no explanation in term.log, syslog or dpkg.log for the second interruption:
> > > 
> > > --
> > > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > > [upgrade interrupted...]
> > > W: APT had planned for dpkg to do more than it reported back (5014 vs 5047).
> > >    Affected packages: texlive-fonts-recommended:amd64 texlive-lang-greek:amd64 texlive-latex-base:amd64 texlive-latex-extra:amd64 texlive-latex-recommended:amd64 texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
> > > ---
> > > 
> > > which occurs even if pitivi is removed before upgrading, and the warning doesn't appear in term.log either.
> > > 
> > > If anyone can shed further light, I would be interested, but it's not ultimately a roadblock to upgrading so possibly not worth worrying about.
> > 
> > I'm no help here, as I've never seen output like that,
> > neither the "[ … ]", nor the "W: APT had planned …".
> > Is that output, with [upgrade interrupted...], a verbatim
> > copy/paste? Did this message appear spontaneously, or
> > because you yourself interrupted the process?
> 
> "[...]" was just my way of showing output until this point has not been 
> included in the paste, or that the paste includes gaps in output.  I 
> use this by habit from academic writing but perhaps <snip> might be 
> better for this purpose?  
> 
> The interrupt and following "W: APT had planned..." appeared 
> spontaneously.  The upgrade stops, and [...] here stands in for 
> etckeeper output, which I removed as noisy.
> 
> > 
> > ISTR that history.log records intent, not achievement, whereas
> > term.log can obviously /only/ log achievement, so a comparison
> > of their two lists of packages for the interrupted step might give
> > a clue, perhaps a more fruitful one than just the list of Affected
> > packages quoted above.
> 
> I have just noticed that the logged action after which it trips up:
> 
> Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> 
> is related to what may be another problem of sorts.  php7.3 packages 
> are removed as part of the upgrade but the config (mods-available) 
> isn't changed.  Apache2 won't start after upgrading until I
> 
> a2dismod *php*7.3*
> 
> >From /var/log/syslog: 
> Aug 22 00:29:58 qwerty systemd[1]: Starting The Apache HTTP Server...
> Aug 22 00:29:58 qwerty apachectl[59333]: apache2: Syntax error on line 
> 146 of /etc/apache2/apache2.conf: Syntax error on line 3 of 
> /etc/apache2/mods-enabled/php7.3.load: Cannot load 
> /usr/lib/apache2/modules/libphp7.3.so into server: 
> /usr/lib/apache2/modules/libphp7.3.so: cannot open shared object file: 
> No such file or directory
> Aug 22 00:29:58 qwerty apachectl[59330]: Action 'start' failed.
> 
> Is it normal to have to do this sort of thing after a major upgrade?  
> If not, could a hiccup here be related to the upgrade breaking?
> 
> Thanks
> Gareth
> 
> 
> 
> 
> > 
> > Cheers,
> > David.
> > 
> > 
> 
> 

> but the config (mods-available) isn't changed.

I meant mods-enabled

[toc] | [prev] | [next] | [standalone]

#239180

On Sun 22 Aug 2021 at 13:18:38 (+0100), Gareth Evans wrote:
> On Sun 22 Aug 2021, at 05:36, David Wright <deblis@lionunicorn.co.uk> wrote:
> > On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:

> > > There is also no explanation in term.log, syslog or dpkg.log for the second interruption:
> > > 
> > > --
> > > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > > [upgrade interrupted...]
> > > W: APT had planned for dpkg to do more than it reported back (5014 vs 5047).
> > >    Affected packages: texlive-fonts-recommended:amd64 texlive-lang-greek:amd64 texlive-latex-base:amd64 texlive-latex-extra:amd64 texlive-latex-recommended:amd64 texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
> > > ---

[ … ]

> > I'm no help here, as I've never seen output like that,
> > neither the "[ … ]", nor the "W: APT had planned …".
> > Is that output, with [upgrade interrupted...], a verbatim
> > copy/paste? Did this message appear spontaneously, or
> > because you yourself interrupted the process?
> 
> "[...]" was just my way of showing output until this point has not been included in the paste, or that the paste includes gaps in output.  I use this by habit from academic writing but perhaps <snip> might be better for this purpose?  
> 
> The interrupt and following "W: APT had planned..." appeared spontaneously.  The upgrade stops, and [...] here stands in for etckeeper output, which I removed as noisy.

Both the < … > and [ … ] are fine; it's just that "upgrade
interrupted", in a passive construction, avoids specifying the agent,
which is what we need to know: was it you or APT whodunit.

[ … ]

> I have just noticed that the logged action after which it trips up:
> 
> Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> 
> is related to what may be another problem of sorts.  php7.3 packages are removed as part of the upgrade but the config (mods-[enabled]) isn't changed.  Apache2 won't start after upgrading until I
> 
> a2dismod *php*7.3*
> 
> >From /var/log/syslog: 
> Aug 22 00:29:58 qwerty systemd[1]: Starting The Apache HTTP Server...
> Aug 22 00:29:58 qwerty apachectl[59333]: apache2: Syntax error on line 146 of /etc/apache2/apache2.conf: Syntax error on line 3 of /etc/apache2/mods-enabled/php7.3.load: Cannot load /usr/lib/apache2/modules/libphp7.3.so into server: /usr/lib/apache2/modules/libphp7.3.so: cannot open shared object file: No such file or directory
> Aug 22 00:29:58 qwerty apachectl[59330]: Action 'start' failed.
> 
> Is it normal to have to do this sort of thing after a major upgrade?  If not, could a hiccup here be related to the upgrade breaking?

Well, the apache version is upgraded from 2.4.38 to 2.4.46 during the
transition from buster to bullseye, and although APT will look after
upgrading its conffiles, "conffiles" are those configuring the apache
software, not the mods-available/enabled that configure the service.

People who run apache servers may have their own opinions on the
correct procedure. My own would be that you should be sure a
configuration is correct before you run that service, and testing
it is not best done during a major upgrade, but when the dust has
settled.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#239237

On Sun 22 Aug 2021, at 15:37, David Wright <deblis@lionunicorn.co.uk> wrote:
> On Sun 22 Aug 2021 at 13:18:38 (+0100), Gareth Evans wrote:
> > On Sun 22 Aug 2021, at 05:36, David Wright <deblis@lionunicorn.co.uk> wrote:
> > > On Fri 20 Aug 2021 at 14:13:55 (+0100), Gareth Evans wrote:
> 
> > > > There is also no explanation in term.log, syslog or dpkg.log for the second interruption:
> > > > 
> > > > --
> > > > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > > > [upgrade interrupted...]
> > > > W: APT had planned for dpkg to do more than it reported back (5014 vs 5047).
> > > >    Affected packages: texlive-fonts-recommended:amd64 texlive-lang-greek:amd64 texlive-latex-base:amd64 texlive-latex-extra:amd64 texlive-latex-recommended:amd64 texlive-pictures:amd64 texlive-plain-generic:amd64 texlive-science:amd64
> > > > ---
> 
> [ … ]
> 
> > > I'm no help here, as I've never seen output like that,
> > > neither the "[ … ]", nor the "W: APT had planned …".
> > > Is that output, with [upgrade interrupted...], a verbatim
> > > copy/paste? Did this message appear spontaneously, or
> > > because you yourself interrupted the process?
> > 
> > "[...]" was just my way of showing output until this point has not been included in the paste, or that the paste includes gaps in output.  I use this by habit from academic writing but perhaps <snip> might be better for this purpose?  
> > 
> > The interrupt and following "W: APT had planned..." appeared spontaneously.  The upgrade stops, and [...] here stands in for etckeeper output, which I removed as noisy.
> 
> Both the < … > and [ … ] are fine; it's just that 

> [...] "upgrade
> interrupted", in a passive construction, avoids specifying the agent,
> which is what we need to know: was it you or APT whodunit.

It wasn't me, but an apparent breakage.

> 
> [ … ]
> 
> > I have just noticed that the logged action after which it trips up:
> > 
> > Processing triggers for libapache2-mod-php7.4 (7.4.21-1+deb11u1) ...
> > 
> > is related to what may be another problem of sorts.  php7.3 packages are removed as part of the upgrade but the config (mods-[enabled]) isn't changed.  Apache2 won't start after upgrading until I
> > 
> > a2dismod *php*7.3*
> > 
> > >From /var/log/syslog: 
> > Aug 22 00:29:58 qwerty systemd[1]: Starting The Apache HTTP Server...
> > Aug 22 00:29:58 qwerty apachectl[59333]: apache2: Syntax error on line 146 of /etc/apache2/apache2.conf: Syntax error on line 3 of /etc/apache2/mods-enabled/php7.3.load: Cannot load /usr/lib/apache2/modules/libphp7.3.so into server: /usr/lib/apache2/modules/libphp7.3.so: cannot open shared object file: No such file or directory
> > Aug 22 00:29:58 qwerty apachectl[59330]: Action 'start' failed.
> > 
> > Is it normal to have to do this sort of thing after a major upgrade?  If not, could a hiccup here be related to the upgrade breaking?
> 
> Well, the apache version is upgraded from 2.4.38 to 2.4.46 during the
> transition from buster to bullseye, and although APT will look after
> upgrading its conffiles, "conffiles" are those configuring the apache
> software, not the mods-available/enabled that configure the service.
> 
> People who run apache servers may have their own opinions on the
> correct procedure. My own would be that you should be sure a
> configuration is correct before you run that service, and testing
> it is not best done during a major upgrade, but when the dust has
> settled.

What do you mean by "when the dust has settled" in this context?  

Thanks,
Gareth

> 
> Cheers,
> David.
> 
> 

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web