(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.

Hi,

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.

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.
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

David Kalnischkies dixit:

That sounds agreeable as well.

Oh, interesting. I may have a look into that.

bye,
//mirabilos

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

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.

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...

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.

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).

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.

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.

Control: forcemerge 879786 -1

Merging this into the other bug

Hi,

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

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

[...]

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