On Sun 22 Aug 2021, at 13:18, Gareth Evans <donots...@fastmail.fm> wrote: > On Sun 22 Aug 2021, at 05:36, David Wright <deb...@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 <deb...@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