On 2021-08-14 at 19:15, Greg Wooledge wrote: > On Sat, Aug 14, 2021 at 06:26:07PM -0400, The Wanderer wrote: > >> > E: Repository 'http://ftp.us.debian.org/debian stable 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. >> >> If you used the label 'buster' instead of 'stable' in your sources.list, >> you may see complaints about a change in the 'Suite' value instead. > > Hmm... after reading your message again, I think we're talking about > two separate problems that have very similar symptoms. > > I've never actually *heard* of your problem before, nor have I seen it.
See bug #879786, and the various bugs that have been merged into it (listed near the very bottom, IIRC). > In all cases, whenever I've had a machine that ran *only* stable > releases, this symptom has never happened to me. All > stable-to-stable release upgrades have gone smoothly for me, at least > as far as the "apt-get update" step goes. I'm not sure what you're > doing differently, or why it's not working properly for you. Some of the discussion in the bug report seems to imply that this is only expected to happen if you have a repository which has some aspect which isn't properly configured as trusted on your system. I'm guessing that the exact details of how I access the same repositories which would normally be considered trusted makes them not be so. > What *I* saw (and put on the wiki), was that a machine which ran > buster *as testing* (i.e. was upgraded from stretch to testing, prior > to buster's release) ran into the problem you describe, except that > it said the suite name changed from "testing" to "stable". That sounds like the situation I'm in; I typically dist-upgrade against testing once a day during the weeks after a new release, and then about once a week after that, till it's time to repeat the cycle with the next release. I've been running testing (specified by that name in sources.list) for... long enough that I don't actually remember when I started; it was probably over a decade ago. That said, I *did* somewhat-recently (around the end of June, I think) install a new machine to the same specifications as the old one - using, IIRC, the then-release-candidate installer version - and immediately switch it to target testing, using the same sources.list as on the previous machine. I never ran this '--allow-releaseinfo-change' on the new machine, although I had done it on the old; maybe somehow there's a flag involved other than just the release info itself being different, which hadn't been set previously on this new machine? > When I upgraded my buster-to-testing-to-bullseye machine today, I did > not see this same problem. I got a bunch of warnings, and I > *thought* I was seeing the same problem as last time, but it turns > out I didn't actually have to run "apt update". The "apt-get update" > had worked in the first place. The warnings I'd be OK with; I might even be OK with the errors, except for the fact that they point not to anything with useful information but to a place which doesn't actually tell you anything helpful. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
