Dear Maintainer, ============================================================================================== I use only 2 packages from ubuntu (which are not available in debian): chromium-codecs-ffmpeg-extra, oxideqt-codecs-extra. For this I have the ubuntu repository in sources.list along with an apt_preferences file to allow only those 2 packages (with priority 476 < 500 for all debian). This recently gave these errors during apt-get update: W: Conflicting distribution: http://archive.ubuntu.com/ubuntu devel InRelease (expected devel but got bionic) N: Repository 'http://archive.ubuntu.com/ubuntu devel InRelease' changed its 'Version' value from '17.10' to '18.04' E: Repository 'http://archive.ubuntu.com/ubuntu devel InRelease' changed its 'Suite' value from 'artful' to 'bionic' E: Repository 'http://archive.ubuntu.com/ubuntu devel InRelease' changed its 'Codename' value from 'artful' to 'bionic' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. The apt-secure man page is of no help in resolving this (see bottom). The apt-secure man page should be expanded to mention the apt options needed for what it alludes to: "the user must therefore explicitly confirm changes to signal...": apt-get update --allow-releaseinfo-change (and related apt.conf) I was able to get around the lack of detail in the man page through a search that yielded only one page with the needed info: https://fossies.org/linux/misc/apt-1.5.tar.gz/apt-1.5/test/integration/test-apt-update-releaseinfo-changes 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). USER ... ==============================================================================================
Thanks,
"BTW, your pinning and sources.list is extreme. That's not really a sensible thing to do and can cause a lotof trouble. "
If you can be more explicit, I'd very much appreciate the feedback.
As it is, the pinning I use is to prevent unintentional changes to nvidia drivers, linux kernel, and to block all ubuntu packages other than the 2 codecs not available in debian.Plus block versions of some packages, like vivaldi browser, that no longer work well with the latest codecs.
It there's a better way to achieve these goals, I'd very much like to learn about it.
thanks,--jack
From: Julian Andres Klode <jak@debian.org>
To: js <em2jacks@yahoo.com>; 879786@bugs.debian.org
Sent: Wednesday, October 25, 2017 4:23 PM
Subject: Re: Bug#879786: apt-secure man page needs to provide useful pointers for Release file info changes
The first one does not make much sense, Debian's chromium should already contain all codecs.
That's somewhat true. You likely want to use apt instead of apt-get, that would ask
the question interactively. apt-get is mostly for scripting.
BTW, your pinning and sources.list is extreme. That's not really a sensible thing to do and can cause a lot
of trouble. Also, well, it took me a minute to clean them out for the reply - it can only delete one line
at a time :/
The first one does not make much sense, Debian's chromium should already contain all codecs. That's somewhat true. You likely want to use apt instead of apt-get, that would ask the question interactively. apt-get is mostly for scripting. BTW, your pinning and sources.list is extreme. That's not really a sensible thing to do and can cause a lot of trouble. Also, well, it took me a minute to clean them out for the reply - it can only delete one line at a time :/
I second that apt-secure should mention the use of "apt" and, in detail, "apt-get --allow-releaseinfo-change" as well (pointing to apt-get for more details on the various finger-graned flags) since the manpage of apt(1) doesn't include any relevant information on metadata changes. I don't ever use "apt", I mostly use "aptitude" or directly "apt-get" when needed. aptitude doesn't have support for prompting for releaseinfo changes, and apt-get does neither. The error message is somewhat puzzling, since apt-secure(8) contains mostly redundand information for those who know already something about the signing infrastructure and just want to acknowledge the change. Thanks.
Just ran into this issue with chrome package from Google:
E: Repository 'http://dl.google.com/linux/chrome/deb stable
Release' changed its 'Origin' value from 'Google, Inc.' to 'Google
LLC'
N: This must be accepted explicitly before updates for this
repository can be applied. See apt-secure(8) manpage for details.
Rather than adding information to apt-secure's man page, I think it
would be more helpful to output the command the user needs to accept
the change:
E: Repository 'http://dl.google.com/linux/chrome/deb stable
Release' changed its 'Origin' value from 'Google, Inc.' to 'Google
LLC'
N: If you would like to accept this change, please rerun apt-get
update with the `--allow-releaseinfo-change` flag
If you run it interactive, you get asked directly, and don't need the flag. Just recommending the flag is probably not a good idea, as it makes people add them to update scripts without thinking.
What do you mean by running interactively? I ran `apt-get update` in my terminal and I was not prompted, it just showed those error messages. I also don't see why showing the flag is not helpful, that was the only way I was able to confirm the change?
Oh, you might have to use apt instead of apt-get. IMO, the right answer would be to run "apt update" and confirm the change when asked.
I find it strange to recommend another tool, when there is a flag to confirm the change with apt-get. If the intent is to deprecate using apt-get interactively entirely, then that should be done at a more holistic level, such as a warning on every invocation, rather than when a specific error appears.
Dear Maintainer,
I've had to spend far too much time to figure this out due the release
yesterday. I'm running apt-get, and apt-get tells me nothing except
| E: The repository 'http://security.debian.org testing/updates Release' no longer has a Release file.
| N: Updating from such a repository can't be done securely, and is therefore disabled by default.
| N: See apt-secure(8) manpage for repository creation and user configuration details.
| 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.
| E: Repository 'http://deb.debian.org/debian-debug testing-debug InRelease' changed its 'Codename' value from 'buster-debug' to 'bullseye-debug'
| N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
, and then apt-secure(8) yabbers on about how to create secure
repositiories and whatever, but doesn't give a hint about how I would
explicitly accept the change.
This really sucks.
Searching for the error string then turns up various "solutions" on the
web that recommend deleting files from /var/lib/apt , or marking
repositories as [Trusted=yes] or [Allow-Insecure=yes] in sources.list ,
so this is obviously a real problem that causes users to compromise the
security of their machines.
I think the message displayed should directly mention both
"--allow-releaseinfo-change" and running "apt update" interactively.
(apt-get knows it's not apt!)
At the very least it needs to be prominently explained in apt-secure(8).
Thanks for maintaining apt-get,
Jan
I just had to update a machine running (now) oldstable. It was last
updated before the release of bullseye, so it is not oldstabel.
Running apt-get update, I get lots of:
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.
…
This is expected, and I read apt-secure(8) how to deal with this.
However, the man page simply says:
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).
However, there is no link how to do this, what steps are necessary.
After a quick online search, I found that:
apt-get update --allow-releaseinfo-change
does the trick.
Since this is a common use case, please describe it, e.g. in an
EXAMPLE section. Possibly examples from other frontends (like apt,
aptitutude, dselect, …) could be added as well.
This would greatly reduce the workload for a part time administrator
(and would avoid trusing "random" web sources).
Before sending I found this bug (#879786) and I think it would be a
really good idea handling this, the EXAMPLE section should be fairly
quickly written.
Control: notfound -1 2.2.4 Control: merge 879786 -1 This was fixed in 1.8.2.3 and 2.1.10, see Bug#931566 But why did you report a duplicate?
I have now realized that you did not, just used a full bug report template to comment on an old bug so it *looked* like you reported a new one. BTS is hard. Also the subject changed, so conversation tracking in gmail broke, but then I only looked at gmail after I looked in mutt, so well, wouldn't have helped anyway. Could have expanded the thread in notmuch, but was so sure it was a new one. Sigh! Apologies!
Hello Julian,
I read the man page on stable, i.e. 2.2.4. if I'm not mistaken, thus
the version. (The system in question is different, though).
I just did this upgrade on an (now oldstable) machine and got the
described output (no longer reproducible). This machine is,
unfortunately, rarely updated.
Apologies, after discovering the missing content in apt-secure(8) I
searched for the solution and intended to report this (hiding errors
is no good) as new bug. Then I saw #879786 and instead of reporting a
new bug, I send this to this bug, which seemed applicable.
So if apt in Testing/Unstable has an expanded apt-secure(8), then this
bug can be of course closed, otherwise the content should IMHO be
added there (it's probably just a few lines). I skimmed over #931566,
if this implies the error will not occur in the future, then of course
this could be closed without action (but then the error message
pointing to apt-secure(8) might need to be updated as well).
I personally would prefere an update of apt-secure(8).
Greetings
Helge