Subject: apt: E: Repository # changed its 'Suite' value from 'buster' to 'testing'; but how to accept?
Date: Sun, 19 May 2019 23:37:57 +0200
Package: apt
Version: 1.8.0
Severity: normal
(but ought to be release-critical, see last paragraph)
E: Repository 'http://debs.tarent.de buster InRelease' changed its 'Suite' value from 'buster' to 'testing'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Sure, but the apt-secure(8) manpage is 8 screen pages, and while
I eventually (took me some time) found the right section, it does
not document *how* one would accept this change:
INFORMATION CHANGES
A Release file contains beside the checksums for the files in the
repository also general information about the repository like the
origin, codename or version number of the release.
This information is shown in various places so a repository owner
should always ensure correctness. Further more user configuration like
apt_preferences(5) can depend and make use of this information. Since
version 1.5 the user must therefore explicitly confirm changes to
signal that the user is sufficiently prepared e.g. for the new major
release of the distribution shipped in the repository (as e.g.
indicated by the codename).
Nothing in here shows the correct way, so people will duckduckgo for
answers and likely find things like “sudo chmod 777 somefile” on
ask*buntu, or something…
… for the record, I *believe* that adding --allow-releaseinfo-change
to apt-get update is right, but this appears only in the apt-get(8)
manpage, not in apt(8) which some people believe is the new tool, and
especially not in apt-secure(8) where the user is directed to.
As such, this is a rather severe documentation bug that I believe
ought to be fixed before buster.
-- Package-specific info:
-- (no /etc/apt/preferences present) --
-- (/etc/apt/preferences.d/dash-mksh.pref present, but not submitted) --
-- (/etc/apt/sources.list present, but not submitted) --
-- (no /etc/apt/sources.list.d/* present) --
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
Versions of packages apt depends on:
ii adduser 3.118
ii debian-archive-keyring 2018.1
ii gpgv 2.2.12-1
ii libapt-pkg5.0 1.8.0
ii libc6 2.28-8
ii libgcc1 1:8.3.0-6
ii libgnutls30 3.6.6-2
ii libseccomp2 2.3.3-4
ii libstdc++6 8.3.0-6
Versions of packages apt recommends:
ii ca-bundle [ca-certificates] 20181220tarent1
Versions of packages apt suggests:
pn apt-doc <none>
pn aptitude | synaptic | wajig <none>
ii dpkg-dev 1.19.6
ii gnupg 2.2.12-1
ii gnupg1 1.4.23-1
pn powermgmt-base <none>
-- no debconf information
Acknowledgement sent
to David Kalnischkies <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Mon, 10 Jun 2019 13:27:03 GMT) (full text, mbox, link).
Hi,
On Sun, May 19, 2019 at 11:37:57PM +0200, Thorsten Glaser wrote:
> Sure, but the apt-secure(8) manpage is 8 screen pages, and while
> I eventually (took me some time) found the right section, it does
> not document *how* one would accept this change:
Well, apt-secure manpage is supposed to be generic information for all
APT-based clients. I really don't look forward to describing which
buttons must be clicked to perform this magic in e.g. synaptics and the
gazillion other clients apt and apt-get are just the most prominent of.
> … for the record, I *believe* that adding --allow-releaseinfo-change
> to apt-get update is right, but this appears only in the apt-get(8)
> manpage, not in apt(8) which some people believe is the new tool, and
> especially not in apt-secure(8) where the user is directed to.
1. apt(8) is documented to not document every nook and cranny.
2. "apt" asks an interactive question in this situation,
for "apt-get" this is disabled by default, because, I am told,
people hate changes.
3. the user is directed to "apt-secure" for details on the why,
how to use the client in question is a matter of client manpages
4. The client manpage apt-get(8) indeed mentions the option framed by
the other security related options.
> As such, this is a rather severe documentation bug that I believe
> ought to be fixed before buster.
While I might agree the behaviour of apt-get could be more revealing,
I don't think this would belong in apt-secure. I guess we could add
another N: for apt-get, but I haven't looked at where to add that it is
generated only for apt-get not for other clients where that hint would
make no sense as a graphical software center likely doesn't accept that
flag…
Or we could babble about the underlying config options like in the
insecure repository case as it would effect all clients then, but that
feels a bit dirty and wrong.
On a sidenote: The Release file can include a "Release-Notes" field
which is then displayed as "More information about this can be found
online in the Release notes at: %s" so that a repository owner can
provide an explanation for this change.
In summary, I don't believe in this being a severe problem. Legit
changes of these fields should be really really rare given we teach
users to use Codename in configuration rather than Suite.
Best regards
David Kalnischkies
Acknowledgement sent
to Thorsten Glaser <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Mon, 10 Jun 2019 14:33:03 GMT) (full text, mbox, link).
Subject: Re: Bug#929248: apt: E: Repository # changed its 'Suite' value from
'buster' to 'testing'; but how to accept?
Date: Mon, 10 Jun 2019 14:22:46 +0000 (UTC)
David Kalnischkies dixit:
>While I might agree the behaviour of apt-get could be more revealing,
>I don't think this would belong in apt-secure. I guess we could add
>another N: for apt-get, but I haven't looked at where to add that it is
That sounds agreeable as well.
>On a sidenote: The Release file can include a "Release-Notes" field
>which is then displayed as "More information about this can be found
>online in the Release notes at: %s" so that a repository owner can
>provide an explanation for this change.
Oh, interesting. I may have a look into that.
bye,
//mirabilos
--
"Using Lynx is like wearing a really good pair of shades: cuts out
the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
-- Henry Nelson, March 1999
Acknowledgement sent
to Osamu Aoki <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Sun, 07 Jul 2019 13:36:03 GMT) (full text, mbox, link).
Subject: changed its 'Suite' value from 'buster' to 'testing' ...
Date: Sun, 7 Jul 2019 22:34:49 +0900
Hi,
So I am not the only one ;-)
But why we point people to apt-secure manpage? It was cryptic for me.
Why not simply say:
Probably, a new Debian Stable release has happened as you tried to
update your system. If this is the case, please update "Release-Notes"
field by executing "sudo apt-get --allow-releaseinfo-change update".
Osamu
Acknowledgement sent
to Adam Borowski <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Sun, 07 Jul 2019 15:27:07 GMT) (full text, mbox, link).
Subject: Re: Bug#929248: changed its 'Suite' value from 'buster' to 'testing'
...
Date: Sun, 7 Jul 2019 17:26:27 +0200
On Sun, Jul 07, 2019 at 10:34:49PM +0900, Osamu Aoki wrote:
> But why we point people to apt-secure manpage? It was cryptic for me.
I did not manage to find the information there either. At this moment, I
did intentionally stop -- while I might be not the brightest bulb in the
knife drawer, I believe my ability to read man pages is a wee bit better
than that of an average user. And _those_ will not manage futher research.
My particular question was:
Given a pipeline that's basically:
for x in `lxc-ls --running`;do echo ...;lxc-attach -n "$x" -- apt-get update;done
have apt do its job.
None of the containers in question refer to any codenames that have changed,
thus apt's reluctance to continue is irrelevant or harmful. All of these
referred to either "unstable", "buster" or "stretch". I would understand
your reasoning if I had referred to "stable".
But, it's worse than merely annoying users of unstable and testing. Two
years from now, millions of boxes will have "buster" change to "oldstable",
and, with cron mails currently being null-routed by default, no one will see
that[1]. Thus, a significant part of users will have security updates
suddenly stopped despite nothing relevant to them happening.
And this particular piece deserves a high severity.
> Why not simply say:
>
> Probably, a new Debian Stable release has happened as you tried to
> update your system. If this is the case, please update "Release-Notes"
> field by executing "sudo apt-get --allow-releaseinfo-change update".
Yes, thank you! This particular bit is what I was looking for in this case.
But, I'm afraid that a documentation change is nowhere near enough.
Meow!
[1]. How many times have you been called to recover a server whose mail
spool has a couple of years of notifications about degraded RAID -- which
then worked until the second disk failed? And so on...
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned
⢿⡄⠘⠷⠚⠋ by a hacker". So what's the problem?
⠈⠳⣄⠀⠀⠀⠀
Acknowledgement sent
to Julian Andres Klode <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Sun, 07 Jul 2019 16:30:03 GMT) (full text, mbox, link).
Subject: Re: Bug#929248: changed its 'Suite' value from 'buster' to 'testing'
...
Date: Sun, 7 Jul 2019 18:27:02 +0200
On Sun, Jul 07, 2019 at 05:26:27PM +0200, Adam Borowski wrote:
> On Sun, Jul 07, 2019 at 10:34:49PM +0900, Osamu Aoki wrote:
> > But why we point people to apt-secure manpage? It was cryptic for me.
>
> I did not manage to find the information there either. At this moment, I
> did intentionally stop -- while I might be not the brightest bulb in the
> knife drawer, I believe my ability to read man pages is a wee bit better
> than that of an average user. And _those_ will not manage futher research.
>
> My particular question was:
> Given a pipeline that's basically:
> for x in `lxc-ls --running`;do echo ...;lxc-attach -n "$x" -- apt-get update;done
> have apt do its job.
>
> None of the containers in question refer to any codenames that have changed,
> thus apt's reluctance to continue is irrelevant or harmful. All of these
> referred to either "unstable", "buster" or "stretch". I would understand
> your reasoning if I had referred to "stable".
There are two reasons for these checks:
(1) Your pinning can break (or -t switches in your script)
(2) Your system can accidentally upgrade to a new stable release
In your case, (1) applies.
>
> But, it's worse than merely annoying users of unstable and testing. Two
> years from now, millions of boxes will have "buster" change to "oldstable",
> and, with cron mails currently being null-routed by default, no one will see
> that[1]. Thus, a significant part of users will have security updates
> suddenly stopped despite nothing relevant to them happening.
>
> And this particular piece deserves a high severity.
Luckily we have about two years to deal with this (well, let's say 18
months or so, gotta give people time to update before the new stable).
>
> > Why not simply say:
> >
> > Probably, a new Debian Stable release has happened as you tried to
> > update your system. If this is the case, please update "Release-Notes"
> > field by executing "sudo apt-get --allow-releaseinfo-change update".
You're not supposed to be using apt-get, use apt. We can't tell people to
use that flag or apt-get as they might be using a different frontend -
refering them to the manpage is the best we can do if they insist on
using the apt-get frontend.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Acknowledgement sent
to Helge Kreutzmann <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Sun, 07 Jul 2019 20:21:04 GMT) (full text, mbox, link).
Package: apt
Version: 1.8.2
Severity: normal
I added buster a few days ago in my sources.list. Now I get the
following error:
root@samd:~# LC_ALL=C apt-get update
Get:1 http://security.debian.org/debian-security buster/updates InRelease [39.1 kB]
Get:2 http://172.16.18.51:9999/ftp.de.debian.org/debian buster InRelease [118 kB]
Reading package lists... Done
N: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Version' value from '' to '10'
E: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Suite' value from 'testing' to 'stable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
N: Repository 'http://172.16.18.51:9999/ftp.de.debian.org/debian buster InRelease' changed its 'Version' value from '' to '10.0'
E: Repository 'http://172.16.18.51:9999/ftp.de.debian.org/debian buster InRelease' changed its 'Suite' value from 'testing' to 'stable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
I read apt-secure(8), but it does not say how to accept explcitly
to use buster, i.e. the new stable. It only tells me how to turn the
error in a warning (which I don't want, I want to use this properly).
Now off duckduckgo'ing, what I need to do …
Ok, I found this bug and I belive it is severe.
a) On purpose I did not use "stable" but "buster", so the meaning is clear
b) I explicitly chose to use "buster" before the relase, so that I
would no longer keep tracking "testing" by accident
c) It does not matter, if apt-get is deprecated or not, it only
changes the error.
So either: "This cannot be done with apt-get, use …"
or explain where the information can befound, actually for apt-get.
The fix described in this bug (apt-get --allow-releaseinfo-change
update) worked for me as well.
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.1.15 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages apt depends on:
ii adduser 3.118
ii debian-archive-keyring 2019.1
ii gpgv 2.2.12-1
ii libapt-pkg5.0 1.8.2
ii libc6 2.28-10
ii libgcc1 1:8.3.0-6
ii libgnutls30 3.6.7-4
ii libseccomp2 2.3.3-4
ii libstdc++6 8.3.0-6
Versions of packages apt recommends:
ii ca-certificates 20190110
Versions of packages apt suggests:
ii apt-doc 1.8.2
pn aptitude | synaptic | wajig <none>
ii dpkg-dev 1.19.7
ii gnupg 2.2.12-1
ii gnupg2 2.2.12-1
pn powermgmt-base <none>
-- no debconf information
--
Dr. Helge Kreutzmann [email protected]
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Acknowledgement sent
to Julian Andres Klode <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Mon, 08 Jul 2019 09:27:03 GMT) (full text, mbox, link).
Subject: Re: Bug#929248: apt: E: Repository # changed its 'Suite' value from
'buster' to 'testing'; but how to accept?
Date: Mon, 8 Jul 2019 11:25:31 +0200
Control: forcemerge 879786 -1
On Sun, May 19, 2019 at 11:37:57PM +0200, Thorsten Glaser wrote:
> Package: apt
> Version: 1.8.0
> Severity: normal
>
> (but ought to be release-critical, see last paragraph)
>
>
> E: Repository 'http://debs.tarent.de buster InRelease' changed its 'Suite' value from 'buster' to 'testing'
> N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
>
> Sure, but the apt-secure(8) manpage is 8 screen pages, and while
> I eventually (took me some time) found the right section, it does
> not document *how* one would accept this change:
>
> INFORMATION CHANGES
> A Release file contains beside the checksums for the files in the
> repository also general information about the repository like the
> origin, codename or version number of the release.
>
> This information is shown in various places so a repository owner
> should always ensure correctness. Further more user configuration like
> apt_preferences(5) can depend and make use of this information. Since
> version 1.5 the user must therefore explicitly confirm changes to
> signal that the user is sufficiently prepared e.g. for the new major
> release of the distribution shipped in the repository (as e.g.
> indicated by the codename).
>
> Nothing in here shows the correct way, so people will duckduckgo for
> answers and likely find things like “sudo chmod 777 somefile” on
> ask*buntu, or something…
>
> … for the record, I *believe* that adding --allow-releaseinfo-change
> to apt-get update is right, but this appears only in the apt-get(8)
> manpage, not in apt(8) which some people believe is the new tool, and
> especially not in apt-secure(8) where the user is directed to.
>
> As such, this is a rather severe documentation bug that I believe
> ought to be fixed before buster.
Merging this into the other bug
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Acknowledgement sent
to Csillag Tamas <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Sun, 15 Aug 2021 14:18:03 GMT) (full text, mbox, link).
Subject: Re: Bug#929248: changed its 'Suite' value from 'buster' to 'testing'
...
Date: Sun, 15 Aug 2021 16:08:33 +0200
Hi,
On Sun, Jul 07, 2019 at 06:27:02PM +0200, Julian Andres Klode wrote:
> On Sun, Jul 07, 2019 at 05:26:27PM +0200, Adam Borowski wrote:
> >
> > But, it's worse than merely annoying users of unstable and testing. Two
> > years from now, millions of boxes will have "buster" change to "oldstable",
> > and, with cron mails currently being null-routed by default, no one will see
> > that[1]. Thus, a significant part of users will have security updates
> > suddenly stopped despite nothing relevant to them happening.
> >
> > And this particular piece deserves a high severity.
>
> Luckily we have about two years to deal with this (well, let's say 18
> months or so, gotta give people time to update before the new stable).
fwiw. what Adam predicted is exactly what happened today:
# apt-get update
Get:1 http://security.debian.org buster/updates InRelease [65.4 kB]
Get:2 http://deb.debian.org/debian buster InRelease [122 kB]
Get:3 http://ftp.de.debian.org/debian buster InRelease [122 kB]
Reading package lists... Done
E: Repository 'http://security.debian.org buster/updates InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
E: Repository 'http://deb.debian.org/debian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
E: Repository 'http://ftp.de.debian.org/debian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
100 # cat /etc/debian_version
10.9
why I use apt-get instead of apt you ask?
Because that is what ansible does.
I can solve this for myself, but everyone needs to deal with it on its own.
(I have no idea if other cfg management systems deal with this any better or not)
Looking at the manpages to check if apt-get is deprecated I found that apt-get
is still preferred for scripting in general.
I usually run an ad-hoc command on all hosts with: "apt-get --allow-releaseinfo-change update".
What should ansible do? What is a better solution than running this after every release?
Regards,
cstamas
--
Acknowledgement sent
to "Adam D. Barratt" <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Sun, 15 Aug 2021 15:03:03 GMT) (full text, mbox, link).
Subject: Re: Bug#929248: changed its 'Suite' value from 'buster' to
'testing' ...
Date: Sun, 15 Aug 2021 16:00:07 +0100
On Sun, 2021-08-15 at 16:08 +0200, Csillag Tamas wrote:
> Hi,
>
> On Sun, Jul 07, 2019 at 06:27:02PM +0200, Julian Andres Klode wrote:
> > On Sun, Jul 07, 2019 at 05:26:27PM +0200, Adam Borowski wrote:
> > > But, it's worse than merely annoying users of unstable and
> > > testing. Two
> > > years from now, millions of boxes will have "buster" change to
> > > "oldstable",
> > > and, with cron mails currently being null-routed by default, no
> > > one will see
> > > that[1]. Thus, a significant part of users will have security
> > > updates
> > > suddenly stopped despite nothing relevant to them happening.
> > >
> > > And this particular piece deserves a high severity.
> >
> > Luckily we have about two years to deal with this (well, let's say
> > 18
> > months or so, gotta give people time to update before the new
> > stable).
>
> fwiw. what Adam predicted is exactly what happened today:
>
> # apt-get update
> Get:1 http://security.debian.org buster/updates InRelease [65.4 kB]
> Get:2 http://deb.debian.org/debian buster InRelease [122 kB]
> Get:3 http://ftp.de.debian.org/debian buster InRelease [122 kB]
> Reading package lists... Done
> E: Repository 'http://security.debian.org buster/updates InRelease'
> changed its 'Suite' value from 'stable' to 'oldstable'
> N: This must be accepted explicitly before updates for this
> repository can be applied. See apt-secure(8) manpage for details.
> E: Repository 'http://deb.debian.org/debian buster InRelease' changed
> its 'Suite' value from 'stable' to 'oldstable'
> N: This must be accepted explicitly before updates for this
> repository can be applied. See apt-secure(8) manpage for details.
> E: Repository 'http://ftp.de.debian.org/debian buster InRelease'
> changed its 'Suite' value from 'stable' to 'oldstable'
> N: This must be accepted explicitly before updates for this
> repository can be applied. See apt-secure(8) manpage for details.
>
> 100 # cat /etc/debian_version
> 10.9
At the risk of asking a possibly silly question, why are you not
running 10.*10*, which was released in June and contained an APT
package that downgraded that particular change to a notice?
Regards,
Adam
Acknowledgement sent
to Csillag Tamas <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Sun, 15 Aug 2021 15:36:03 GMT) (full text, mbox, link).
Subject: Re: Bug#929248: changed its 'Suite' value from 'buster' to 'testing'
...
Date: Sun, 15 Aug 2021 17:33:18 +0200
On Sun, Aug 15, 2021 at 04:00:07PM +0100, Adam D. Barratt wrote:
> On Sun, 2021-08-15 at 16:08 +0200, Csillag Tamas wrote:
[...]
> > E: Repository 'http://security.debian.org buster/updates InRelease'
> > changed its 'Suite' value from 'stable' to 'oldstable'
> > N: This must be accepted explicitly before updates for this
> > repository can be applied. See apt-secure(8) manpage for details.
> > E: Repository 'http://deb.debian.org/debian buster InRelease' changed
> > its 'Suite' value from 'stable' to 'oldstable'
> > N: This must be accepted explicitly before updates for this
> > repository can be applied. See apt-secure(8) manpage for details.
> > E: Repository 'http://ftp.de.debian.org/debian buster InRelease'
> > changed its 'Suite' value from 'stable' to 'oldstable'
> > N: This must be accepted explicitly before updates for this
> > repository can be applied. See apt-secure(8) manpage for details.
> >
> > 100 # cat /etc/debian_version
> > 10.9
>
> At the risk of asking a possibly silly question, why are you not
> running 10.*10*, which was released in June and contained an APT
> package that downgraded that particular change to a notice?
That is a fair question and the reason is:
I have machines auto upgrading and rebooting when they have their uptime over 30
days however this automation was temporary disabled for a few weeks because
I had my wedding.
(It is staggered and made with some ansible and a cronjob.)
If 10.10 fixes apt-get that explains why I see this only on a handful of machines (most are on 10.10).
This also means that indeed the ad-hoc fix should be only needed once and last,
but not for future releases. This is good.
Thanks,
cstamas
--