Bug#931536: aptitude update fails to cope with changed release info

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#931536: aptitude update fails to cope with changed release info

Francesco Poli (wintermute)
Package: aptitude
Version: 0.8.11-7
Severity: normal

Hello!

As you know, Debian buster has been released yesterday and the current
Debian testing has just been renamed from 'buster' to 'bullseye'.

Good, but... today I tried to update the repository lists and upgrade
my Debian testing boxes with aptitude:

  # cat /etc/apt/sources.list
  deb http://deb.debian.org/debian testing main
  deb http://deb.debian.org/debian unstable main
 
  deb http://deb.debian.org/debian-security testing-security main
  # aptitude update && aptitude --purge-unused safe-upgrade
  Get: 1 http://deb.debian.org/debian testing InRelease [87.0 kB]
  Hit http://deb.debian.org/debian unstable InRelease
  Get: 2 http://deb.debian.org/debian-security testing-security InRelease [26.1 kB]
  Fetched 26.1 kB in 0s (57.2 kB/s)
  E: Repository 'http://deb.debian.org/debian testing InRelease' changed its 'Codename' value from 'buster' to 'bullseye'
  E: Failed to download some files
  W: Failed to fetch http://deb.debian.org/debian/dists/testing/InRelease: 
  E: Some index files failed to download. They have been ignored, or old ones used instead.


OK, it's telling me that the codename has changed, so I have to be
sure I want to continue to use that repository.
This is useful in cases where the user has configured something
like "deb http://deb.debian.org/debian stable main" and does not
want to be caught unprepared by a new stable release.

But for Debian testing, I really want to continue tracking testing
and the codename change is not an actual discontinuity.

I had to do the following:

  # apt update
  Get:1 http://deb.debian.org/debian testing InRelease [87.0 kB]
  Hit:2 http://deb.debian.org/debian unstable InRelease
  E: Repository 'http://deb.debian.org/debian testing InRelease' changed its 'Codename' value from 'buster' to 'bullseye'
  N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
  Do you want to accept these changes and continue updating from this repository? [y/N] y
  Hit:3 http://deb.debian.org/debian-security testing-security InRelease
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  All packages are up to date.

and then resume my usual upgrading procedure:

  # aptitude update && aptitude --purge-unused safe-upgrade
  Hit http://deb.debian.org/debian testing InRelease
  Hit http://deb.debian.org/debian unstable InRelease
  Hit http://deb.debian.org/debian-security testing-security InRelease
 
  No packages will be installed, upgraded, or removed.
  0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
  Need to get 0 B of archives. After unpacking 0 B will be used.


I think this is a bug in aptitude: it should interactively ask the user
to explicitly confirm the will to go on with the new codename, like apt
does, and also provide a command line option to do so
("--allow-releaseinfo-change", see the apt-get(8) man page).

Please implement this feature.
Thanks for your time and dedication!

Bye.


-- Package-specific info:
Terminal: xterm
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.11
Compiler: g++ 8.2.0
Compiled against:
  apt version 5.0.2
  NCurses version 6.1
  libsigc++ version: 2.10.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.1.20181013
  cwidget version: 0.5.17
  Apt version: 5.0.2

aptitude linkage:
        linux-vdso.so.1 (0x00007ffcea27c000)
        libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x00007f3eb711a000)
        libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x00007f3eb70e0000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f3eb70b2000)
        libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x00007f3eb70a9000)
        libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x00007f3eb6fa3000)
        libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f3eb6e81000)
        libboost_iostreams.so.1.67.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x00007f3eb6e61000)
        libboost_system.so.1.67.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x00007f3eb6e5a000)
        libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 (0x00007f3eb6c2e000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3eb6c0d000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3eb6a89000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3eb6906000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3eb68ea000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3eb6729000)
        libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f3eb670f000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f3eb64f1000)
        libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f3eb64de000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f3eb64b6000)
        liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f3eb6495000)
        libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f3eb63f5000)
        libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f3eb63cf000)
        libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f3eb632e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3eb7750000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3eb6329000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3eb631d000)
        libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f3eb6314000)
        libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f3eb61f6000)
        libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f3eb61d3000)

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages aptitude depends on:
ii  aptitude-common           0.8.11-7
ii  libapt-pkg5.0             1.8.2
ii  libboost-iostreams1.67.0  1.67.0-13
ii  libboost-system1.67.0     1.67.0-13
ii  libc6                     2.28-10
ii  libcwidget3v5             0.5.17-11
ii  libgcc1                   1:8.3.0-6
ii  libncursesw6              6.1+20181013-2
ii  libsigc++-2.0-0v5         2.10.1-2
ii  libsqlite3-0              3.27.2-3
ii  libstdc++6                8.3.0-6
ii  libtinfo6                 6.1+20181013-2
ii  libxapian30               1.4.11-1

Versions of packages aptitude recommends:
ii  libparse-debianchangelog-perl  1.2.0-13
ii  sensible-utils                 0.0.12

Versions of packages aptitude suggests:
pn  apt-xapian-index                <none>
pn  aptitude-doc-en | aptitude-doc  <none>
pn  debtags                         <none>
ii  tasksel                         3.53

-- no debconf information

Reply | Threaded
Open this post in threaded view
|

Bug#915246: [Aptitude-devel] Bug#931536: aptitude update fails to cope with changed release info

Axel Beckert-8
Hi Francesco, Michael and Sven,

Francesco Poli (wintermute) wrote:
> As you know, Debian buster has been released yesterday and the current
> Debian testing has just been renamed from 'buster' to 'bullseye'.
>
> Good, but... today I tried to update the repository lists and upgrade
> my Debian testing boxes with aptitude:
[…]
>   E: Repository 'http://deb.debian.org/debian testing InRelease' changed its 'Codename' value from 'buster' to 'bullseye'
>   E: Failed to download some files
>   W: Failed to fetch http://deb.debian.org/debian/dists/testing/InRelease: 
>   E: Some index files failed to download. They have been ignored, or old ones used instead.

Indeed. This also seems to have an impact where buster changed from
"testing" to "stable", see https://bugs.debian.org/931543.

That's actually prompted by a change in libapt (as Sven already
pointed out in #931543) which aptitude indeed hasn't been updated a
for.

I though must admit that we actually were aware of this issue as I ran
into it with a third-party repo a few months ago, see
https://bugs.debian.org/915246. But admittedly I totally
underestimated its severity and especially also its impact at release
time as I didn't think of that exactly the same will happen when
Debian shifts all suite names at release time. Sorry for that.

I hope that Manuel (CCc'ed) can provide a fix which we then can also
apply to aptitude in Buster in the first minor update which is
expected in about a month.

The official workaround is to use "apt update" once inbetween, answer
its questions (with "y" :-) and then continue to use aptitude.

                Regards, Axel
--
 ,''`.  |  Axel Beckert <[hidden email]>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Reply | Threaded
Open this post in threaded view
|

Bug#915246: [Aptitude-devel] Bug#931536: aptitude update fails to cope with changed release info

Francesco Poli (wintermute)
On Sun, 7 Jul 2019 15:54:04 +0200 Axel Beckert wrote:

> Hi Francesco, Michael and Sven,

Hello Axel, thanks for chiming in!

[...]
> I though must admit that we actually were aware of this issue
[...]
> But admittedly I totally underestimated its severity
[...]
> Sorry for that.

It's OK, luckily we have the simple "apt update" workaround (although
many people will have to be informed about it...).

>
> I hope that Manuel (CCc'ed) can provide a fix which we then can also
> apply to aptitude in Buster in the first minor update which is
> expected in about a month.

I am looking forward to seeing this fix implemented.

Bye!


--
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

attachment0 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#915246: Bug#931536: aptitude update fails to cope with changed release info

David Kalnischkies-4
In reply to this post by Axel Beckert-8
On Sun, Jul 07, 2019 at 03:54:04PM +0200, Axel Beckert wrote:
> I hope that Manuel (CCc'ed) can provide a fix which we then can also
> apply to aptitude in Buster in the first minor update which is
> expected in about a month.

It was two years ago, so my memory was spotty, but now that I am looking
into extending the reporting let me add some implementation hints:
(Note that this is against apt/master which has some API changes, but in
that case that means ABI-compat classes where folded into another, so
backports should be rather trivial – adding virtual methods is ABI
breaking, so in buster the class to derive from has the creative name
pkgAcquireStatus2 as it is itself derived from pkgAcquireStatus)

libapt has a pkgAcquireStatus class which gained a new virtual method:
ReleaseInfoChanges – kinda similar to the existing MediaChange. aptitude
subclasses this a few times, just pick the right one I guess.

See apt{,-get}s implementation:
https://salsa.debian.org/apt-team/apt/blob/master/apt-private/acqprogress.cc#L334

I guess you want to work directly with the parameter
std::vector<ReleaseInfoChange> &&Changes rather than do the trickery to
make "proper" apt error messages out of it and then print them directly
by wrap-calling the default implementation I did there – aka it is
probably simpler for you.

See the doc for the struct in the method in the header:
https://salsa.debian.org/apt-team/apt/blob/master/apt-pkg/acquire.h#L797

And the code generating the messages you can reuse via the struct:
https://salsa.debian.org/apt-team/apt/blob/master/apt-pkg/acquire-item.cc#L1806

If I could make a wish I would suggest featuring the messages which
don't need confirmation (in apt N: lines) not too prominently – as in
don't make them a popup dialog with an OK button (while the other type
is a popup dialog with yes and no buttons). 😉


I can't speak for aptitude folks and I am not too good with aptitude
code, but if I would be that might be a good bug for tagging +newcomer.
Happy to help in case there are {lib,}apt questions in any case – although
I have insane reply delays currently.


Best regards

David "breaking the world one feature at a time" Kalnischkies

signature.asc (849 bytes) Download Attachment