Re: Debian home page -> Download link broken:
On Mon 12 Jun 2023 at 19:26:41 (-0400), The Wanderer wrote: > On 2023-06-12 at 18:55, David Wright wrote: > > On Sun 11 Jun 2023 at 19:18:15 (-0400), The Wanderer wrote: > >> On 2023-06-11 at 17:36, David Wright wrote: > > >>> There are several sources: > > > > [ snipped the back and forth ] > > > > I'm sorry, but I just can't take seriously your not being acquainted > > with the term "release". > > Please don't put words in my mouth. Of course I'm familiar with that > term. I just don't think of it when updating, perhaps in part because I > update routinely when a release has not happened. I was surprised; sorry to exaggerate. > Either blocking updates which would change this information protects > against something, or it doesn't. > > This is the only meaningful thing that I can think of that it could be > protecting against, aside from cases where people didn't realize that > what they were using was a symbolic name. > > If it does meaningfully protect against something that applies in my > case, then I want to retain that protection. If it doesn't, then that's > one less argument for why it should be done at all. Perhaps one way to deal with this is to modify your earlier alias suggestion to alias apt-get-change 'apt-get --allow-releaseinfo-change' which has no effect during normal use, but allows you to circumvent the problem when you next encounter the error message. > I think this just reflects how wide the gap between the way you think > about these things and the way I think about these things is. I guess so; takes all sorts. > As before, however, every time I've tried to put a reason why - or an > alternate explanation of my perspective on this, which might make more > sense - into words, I've run into some kind or another of wall. > > I suppose I should just stop trying to argue for my perspective on these > mailing lists at all; I can't even remember the last time it went > anywhere positive, or even necessarily didn't go somewhere unfortunate. That would be disappointing; I read and keep many of your posts, and would put misunderstandings down to the lack of nuance in emails, as opposed to face-to-face conversations; I'd hate to cause any offence. Cheers, David.
Re: Debian home page -> Download link broken:
David Wright wrote: ... > That's just plain wrong. What was added to bookworm, > the current stable release, on Release Day was a an > official number (12 in this instance). Please stop > trying to sow confusion about codenames. ok. songbird
Re: Debian home page -> Download link broken:
David Wright wrote: > songbird wrote: ... > I can't understand that paragraph. Too many "this", "that" > and "it"s to know what refers to what. haha, that's ok, just let it go. >> release notes may not be written and some cases may >> even be forgotten about. > > Which release doesn't have any Notes? Forgotten about > by whom? it isn't the release which happens in testing, when a package is updated in testing there are no release notes for that event. if you are wondering what is going on you look at the changelogs and/or read up on the package itself via whatever means you can. it's sometimes been the case that the only way i've found out about some changes is by doing full downloads of all the source code and doing line-by-line comparisons between versions - not everything that changes is always documented. >> with testing, stuff can happen, like sid, stuff can >> break. that is just how it goes and i'm quite ok with >> that because i also do keep a stable partition (which >> is currently not upgraded yet and won't be until a >> point release or two down the line). my stable is even >> more stable than the released stable. there's nobody >> to force me to upgrade or mysterious software controlled >> by someone else running to mess with my machine (as i do >> not run auto updates). > > That's very conservative, and most people don't have twin > installations as you and I do. You also have years of Debian > experience, and a degree in computing, I believe. Probably > a good candidate for running testing. i've always been willing to take the chance, with only a few significant headaches over the years because of a maintainer making a mistake with a package or me doing something boneheaded. it also helps that what i'm doing with my computer is not very extensive in terms of running some sort of production system. yes, my background is computer science and i spent a fair number of years running mainframes, minis, pcs, etc. i retired at a young age to avoid further years of sitting at deskjobs being essentially an electronic janitor and babysitter. right about when the internet was becoming popular was when i got away from some things so my viewpoint is skewed and some web technologies i pretty much skipped. like currently the cloud is not something i know too much about. ... >> i consider the release process as a whole which >> includes at some point making copies of symlinks to >> the package pool and renaming various pathways or >> copying things as the whole point of making a >> release and then building images and such which do >> include the codename and not using things such as >> "testing", "sid", "experimental" or "rc-buggy" or >> ... > > More nonsense. They don't add/include a codename. > What they do add upon release is the release number. > The codename is the primary collection that is being > built be Debian. The way in which it is built and > maintained depends on its current status, and that > status is reflected, not defined, by the symlinks > pointing to it. So, a few days ago, bookworm became > a Release, obtained the number 12, had the stable > symlink moved to point at it, and now has a policy > for its modification that differs from what it was > before. yes, it could be another way. i realize this. so i could be wrong in other statements. :) >> i don't really think my viewpoint is far from >> the reality of what does happen, but if anyone >> from the release team cares to pipe up i'd listen. > > They shouldn't need to. It's all been documented in > the Debian reference/policy manuals, should you care > to read them. i have at various times, since the terminology is not always consistent you can chase definitions down all sorts of rabbit holes. to me and in the end the release team's interpretation of those documents and their specific tools as written and used are more defining and useful than many policy documents (policy documents are at times out of date and not updated until there is consensus established through practice). my own experiences in doing support systems work was to read the code and see what it was doing and then going back and seeing if the comments or the rest of the framework built around that code were accurate. i'd find a lot of mistakes (which isn't something i ever wanted to run into during something critical). > Cheers, > David. songbird
Re: Debian home page -> Download link broken:
> Using "stable" in your sources.list is idiotic, and you should not do > it. Ever. I guess I'm an idiot, then. I find it quite convenient because it says exactly what I want: I want those machines to run Debian stable, whichever version that "stable" happens to be at any particular time. AFAIK it used to mean that they got upgraded automatically when a new release was made, which worked fine for me. Nowadays it's a bit different because I get a message like: N: Repository 'http://deb.debian.org/debian stable InRelease' changed its 'Version' value from '11.7' to '12.0' E: Repository 'http://deb.debian.org/debian stable InRelease' changed its 'Codename' value from 'bullseye' to 'bookworm' 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] so I don't need to guess that there's a new release from the size of the `apt full-upgrade`, it says it upfront, but other than that, it works just as well. This year, I actually knew that a new release was coming because I saw announcements on the Fediverse and here, but many times in the past I didn't, because it's not super important for me. Using `stable` lets me know there's a new release without having to read this section of the news. Stefan
Re: Debian home page -> Download link broken:
On 2023-06-12 at 18:55, David Wright wrote: > On Sun 11 Jun 2023 at 19:18:15 (-0400), The Wanderer wrote: > >> On 2023-06-11 at 17:36, David Wright wrote: >>> There are several sources: > > [ snipped the back and forth ] > > I'm sorry, but I just can't take seriously your not being acquainted > with the term "release". Please don't put words in my mouth. Of course I'm familiar with that term. I just don't think of it when updating, perhaps in part because I update routinely when a release has not happened. Regardless of what you can or cannot take seriously, the fact is that in *none* of the cases thus far when I have encountered this message did the term "release" occur to me as something that I might search for, except in hindsight after having already encountered the '--allow-releaseinfo-change" argument name. >>> AIUI, it contains the string InRelease, according to >>> https://lists.debian.org/debian-user/2023/06/msg00392.html in >>> this thread. >> >> I consider that to be part not of the error message, but of the >> repository identifier being referenced *by* the error message. (The >> same would be true for the labels 'bookworm' and 'trixie'.) It did >> not occur to me to use that as an indicator of what to search for, >> and if it had, it would have led me to search not for 'release' but >> for 'InRelease' - since I consider that latter to be a discrete >> term of its own. >> >>> Debian's use of camelCase makes it easy to decompose the word. >>> As pointed out above, the man page that the Note directs you >>> (apt-secure) to uses Release rather than InRelease in all but >>> two places. >> >> I don't think of "InRelease" as being a word, but as being a >> filename that's presumably used on the repository servers and >> checked for by the update tooling - i.e., as an implementation >> detail, which is irrelevant to anyone not attempting to investigate >> the innards of that tooling or those servers. > > AFAICT the file InRelease is always accompanied by Release and > Release.gpg files. That seems plausible, though again it's an implementation detail which the end user doesn't need to know about, and was not referenced in the presented messages. In case it helps make my perspective more comprehensible: I've been seeing the term "InRelease" for all these years, in the output of 'apt-get update' as an apparent file file which is being downloaded and presumably parsed. There's never been any information provided as to what it is, and there's been no apparent benefit to trying to find out. (There are other terms used in that output, such as 'rred', which it seems entirely fruitless to even attempt to find any documentation for; I've actually found an explanation for that such-as example once, but don't remember the explanation, and have never been able to find it again.) Based on that experience, I no longer think of 'InRelease' as being anything but an unexplained internal detail of the 'apt-get update' process - one which it shows during its progress messages because that makes a helpful landmark for keeping track of where in the update process you are, in case there's a need to troubleshoot an issue. It has connotations in my mind of an opaque, discrete object, which there is no point in investigating or thinking about except in terms of that "here's where the failure occurred" type of troubleshooting. I certainly don't think of it as being a reference to a codenamed "release", except perhaps by some historical origin of the filename; I don't particularly think of it as *not* being that either, however, because I simply *do not think about it at all*. I'd have been as likely to think that its name referred to the releases of individual packages which are indexed within the file (i.e., "packages which are in a released state"), or something like that, as to think that it referred to a codenamed Debian release - if, again, I bothered to think about it at all. ...I've forgotten why I was writing the above paragraphs, or if there was a concluding point I was trying to reach, although if there was I think I'd have covered all the necessary ground before the point itself. >>> I don't know whether or which of your extra repositories use >>> stable/ testing as suites/codenames, so I can't opine on that. >> >> I wasn't thinking of it as applying only in cases where the >> symbolic names 'stable' and 'testing' are used; I'm pretty sure it >> would apply to any repository that uses a symbolic name rather than >> a release-specific codename, and there's nothing restricting >> symbolic names to those two. >> >> That said, as far as I recall I don't currently have any >> non-Debian-official repositories configured, which is one reason >> why I'm still considering taking this approach. I have had in the >> past, however, and I wouldn't want to have to remember to adjust >> this if I once again add one. >> >> The reason for both of the two reasons I gave is, I think, that I >> have the
Re: Debian home page -> Download link broken:
On Sun 11 Jun 2023 at 19:23:02 (-0400), songbird wrote: > David Wright wrote: > > songbird wrote: > ... > >> except that is a misconception for those who are running > >> testing. we're not upgrading to a new release. > > > > I don't understand. Suite testing was codenamed bookworm until today, > > and now testing is codenamed trixie. Why is that not a new release? > > testing is still testing is it not? No, it was bookworm, it's now trixie. Different repository operating under different rules. > they didn't delete it and then create it again. Trixie? no. Testing? Yes. AIUI, they delete the symlink that pointed to bookworm, and recreate it, pointing to trixie. When we used to connect to the Debian site by ftp, you could see the symlinks themselves in directory listings. I presume that it's the use of http access that disguises that fact by displaying testing and trixie as if they were directories of equal standing. > they just created a new directory structure with > the codename and put links to the packages that were > the same as testing. it is like taking a snapshot > but you don't destroy the original directory. There's no evidence that anything like that happens, but only symlink shuffling. It would be a great way of wasting time and resource, and make the repository pass through inconsistent states, rather than making the atomic changes of moving syslinks. > after that point testing and stable diverge as > changes are made (under the rules and procedures of > the release team and the various software gatekeepers, > security team, etc.). The rules change at the instant the symlinks move, on Release Day. So stable doesn't diverge, it's Testing that evolves. > you could say that as soon as the first change > happens that trixie is underway and i wouldn't > argue too much about that at all, but i don't > consider it anything other than testing and a > release candidate for trixie. it's not officially > a stable release for another 24-?? months and as > such it isn't really named by me, but others can > consider it what they want. it's only the view > of the release team that really counts (and their > established procedures and tools). Think of it however you want, but the facts are that the codename is the one point of stability in the whole Debian edifice. If you track a codename, you know you are using the same repository for the whole of its life cycle. > it's like the chicken and egg problem applied to > making a cake. at some point you start with an > empty bowl and then put in ingredients and then at > some future point (when the baking is done) you > have a cake (when it is released from the pan or > even taken from the oven - as some people do eat > the cake directly from the pan). flour alone > isn't the cake. so let's just say that testing is > the bowl which holds the ingredients of the next > potential stable release, you can call it what you > want but it isn't an official release until the > release team kicks it out the door with the > codename (or not as perhaps some year we run out > of codenames or Debian stops producing official > images of any kind or ...). That's just plain wrong. What was added to bookworm, the current stable release, on Release Day was a an official number (12 in this instance). Please stop trying to sow confusion about codenames. Cheers, David.
Re: Debian home page -> Download link broken:
On Sun 11 Jun 2023 at 09:46:49 (-0400), The Wanderer wrote:
> On 2023-06-11 at 09:34, Greg Wooledge wrote:
> > On Sun, Jun 11, 2023 at 09:20:41AM -0400, The Wanderer wrote:
> >> On 2023-06-11 at 09:02, Greg Wooledge wrote:
>
> >>> Using "stable" in your sources.list is idiotic, and you should
> >>> not do it. Ever.
> >>>
> >>> This is not a "use at your own risk" scenario, like using
> >>> "testing". That's OK for people who choose to accept the
> >>> responsibility.
> >>>
> >>> Using "stable" is just a mistake.
Maybe, but I don't think Debian would proscribe its use, as some
sysadmins might be happy to deal with the consequences as and when
the error and warning messages arise, for whatever reason. That
freedom is part of the open philosophy.
> >> I do not understand why or how. If you want to transition from one
> >> stable release to the next when that "next" release is made, I
> >> don't see any better option for doing so, and I don't see how
> >> there's any downside to using the symbolic name 'stable' for that
> >> purpose.
> >
> > The issue is that an upgrade to a new stable release CANNOT BE
> > AUTOMATED by the tools. There are manual steps required, and these
> > are specific to each release, and to each user's unique system.
>
> While I recognize that automation is in some cases a hard problem, I
> also take the position that if you have a task that has to be carried
> out on a computer over and over the exact same way every time, and you
> are not automating it, you are doing it wrong.
>
> Thus, I push back - not absolutely, but fairly hard - against "cannot be
> automated".
>
> > One example of this -- among many! -- is the changing of sources.list
> > line syntax across releases. This time around, we got a new section
> > ("non-free-firmware") that had to be added to each line. Before that,
> > there was a change to the syntax of the security.debian.org line,
> > from "buster/updates" to "bullseye-security".
>
> And rather than putting in the design, etc., work to make these things
> happen automatically when they should (and not when they shouldn't), the
> developers gave up and punted it to the release notes. That could be
> acceptable if done rarely, but from what I remember seeing, it seems to
> happen *multiple times per release*.
So in this case they have to mindread the attitude of each sysadmin to
the different categories of non-free software. The same goes for
backports, which I suspect some people (like me) frequently remove as
unnecessary, after an upgrade to a new release.
> As I already mentioned, it's an insufficient solution - both because
> people will not read the release notes before upgrading, as I mentioned,
> and also because people who are tracking testing will encounter these
> changes before the release notes are written. For the most part, release
> notes should be for "important changes you might want to be aware of"
> and/or for getting more information on the details of changes, not for
> some kind of mandatory upgrade checklist.
>
> I might even argue that for changes like the two you cite, there should
> at minimum have been a tool provided (whether on a Website, or in a
> Debian package, if not something run automatically) which would make the
> necessary adjustments.
Complexity comes at a cost. Making transitional packages for easing
the upgrade of complicated substantive packages themselves seems
reasonable to expend effort on, and leverages the maintainer's
expertise. But I don't think that applies to two-yearly upgrades
that are trivial to implement in themselves, and where the precise
adjustments made depend mainly on the individual sysadmin's policy,
attitude to risk, and so on.
For example, when the message under consideration is received, some
admins tracking "testing" might continue to stick with that, others
might decide that all their hardware is now working well, and switch
to "bookworm" (the most stability), or they might follow the trailing
edge of future Debian development with "stable". And the same applies
across the range of distributions, except sid (and experimental,
not a distribution anyway). How would your automated system decide
which changes to make and when? How would it cope with the sort of
major upgrade changes made during the lenny/squeeze transition
(the paired kernel/udev conundrum).
Cheers,
David.
Re: Debian home page -> Download link broken:
On Sun 11 Jun 2023 at 19:18:15 (-0400), The Wanderer wrote: > On 2023-06-11 at 17:36, David Wright wrote: > > On Sun 11 Jun 2023 at 09:32:04 (-0400), The Wanderer wrote: > >> On 2023-06-11 at 09:05, David Wright wrote: > > >>> It would seem very simple, the first time this happens, to > >>> configure this in APT. I typed man apt-get (my preferred > >>> method), /release > >> > >> Where did you come up with the 'release' search term? > > > > There are several sources: [ snipped the back and forth ] I'm sorry, but I just can't take seriously your not being acquainted with the term "release". Your reasons strike me as rather like a car driver saying that they didn't know that "No vehicles" or "No automobiles" applied to them. The list has been buzzing with the term in anticipation of release day. > >> The error message also does not include the string 'release', in > >> any capitalization variant, so that doesn't provide a hint for what > >> to search for either. > > > > AIUI, it contains the string InRelease, according to > > https://lists.debian.org/debian-user/2023/06/msg00392.html in this > > thread. > > I consider that to be part not of the error message, but of the > repository identifier being referenced *by* the error message. (The same > would be true for the labels 'bookworm' and 'trixie'.) It did not occur > to me to use that as an indicator of what to search for, and if it had, > it would have led me to search not for 'release' but for 'InRelease' - > since I consider that latter to be a discrete term of its own. > > > Debian's use of camelCase makes it easy to decompose the word. As > > pointed out above, the man page that the Note directs you > > (apt-secure) to uses Release rather than InRelease in all but two > > places. > > I don't think of "InRelease" as being a word, but as being a filename > that's presumably used on the repository servers and checked for by the > update tooling - i.e., as an implementation detail, which is irrelevant > to anyone not attempting to investigate the innards of that tooling or > those servers. AFAICT the file InRelease is always accompanied by Release and Release.gpg files. > > I don't know whether or which of your extra repositories use stable/ > > testing as suites/codenames, so I can't opine on that. > > I wasn't thinking of it as applying only in cases where the symbolic > names 'stable' and 'testing' are used; I'm pretty sure it would apply to > any repository that uses a symbolic name rather than a release-specific > codename, and there's nothing restricting symbolic names to those two. > > That said, as far as I recall I don't currently have any > non-Debian-official repositories configured, which is one reason why I'm > still considering taking this approach. I have had in the past, however, > and I wouldn't want to have to remember to adjust this if I once again > add one. > > The reason for both of the two reasons I gave is, I think, that I have > the impression that this "prohibit updating against a changed codename > unless explicitly approved" behavior is intended in part to protect > against cases where the name was *not* intended to be a symbolic name, > but the upstream repository has been taken over and changed (possibly > legitimately, possibly maliciously). That scenario is one of the things > I'd prefer to continue to protect against, for any repositories other > than ones where I know the name in use is a symbolic name. Seem like tilting at windmills to me. > All I can say on that front is that when I first ran across mention of > these configuration settings (many years ago, certainly well before the > behavior the specific setting we're discussing was introduced), that > file did not occur to me, and I had no idea where to start looking. I > think I eventually found a man page somewhere which mentioned the > filename, rather than just presenting the configuration strings with no > indication of where to put them, but I don't recall for certain. Well back then, as best I recall, most packages were configured with files called, basically, /etc/package.conf(ig) or under /etc/package/ when the package was more complex. The main exceptions were the traditional well-known unix configuration files. > Years after that, when I did decide that I wanted to set one of these > configuration settings, I did manage to dig up the correct file - but I > don't remember where I found the information, or how I came across it there. As time goes by, there are examples where information is less focussed on packages per se, particularly where DEs are involved and configuration applies more to the whole environment than to individual packages. But admin utilities, and Debian's own configuration, tends not to be so monolithic, but more discretely focussed. > Can you articulate what it is that makes that configuration file name > seem obvious to you as something to look for, when encountering a string > such as 'Foo::BarBaz' in an APT
Re: Debian home page -> Download link broken:
On Sun 11 Jun 2023 at 19:06:02 (-0400), songbird wrote: > Greg Wooledge wrote: > ... > > The overwhelming majority of people who track testing think that it's > > a rolling release. It's not. It's actually a series of evolving > > release candidates, with periods of great disruption interspersed with > > periods of relative calm. > > > > You're clearing replying to someone who thinks it's a single rolling > > release, so set your expectations accordingly. > > yes, we experience it as it happens, which can sometimes > be months or even years before the official stable release > happens and new images are built. the comment about > release candidates is appropriate because that is why > such things as RC bugs are filed and attempted to be > fixed before a release actually happens, but that > release is a stable and official one and not as far as > i've ever seen it is not a "release" so calling it a > rolling release is a contradiction in terminology. it > is not a release, but it is a collection of packages > in a certain state of being which can change as new > packages migrate from unstable (or via testing-pu or > via other means that perhaps i'm not aware of). i just > know that for sure it is not "magic". :) someone has > to do it and make the upload and other things may come > along and make changes (janitor programs are now doing > some things, etc.) I can't understand that paragraph. Too many "this", "that" and "it"s to know what refers to what. > release notes may not be written and some cases may > even be forgotten about. Which release doesn't have any Notes? Forgotten about by whom? > with testing, stuff can happen, like sid, stuff can > break. that is just how it goes and i'm quite ok with > that because i also do keep a stable partition (which > is currently not upgraded yet and won't be until a > point release or two down the line). my stable is even > more stable than the released stable. there's nobody > to force me to upgrade or mysterious software controlled > by someone else running to mess with my machine (as i do > not run auto updates). That's very conservative, and most people don't have twin installations as you and I do. You also have years of Debian experience, and a degree in computing, I believe. Probably a good candidate for running testing. > can you point me to any official statement from the > project as a whole which says that testing is released > and there are official images for people to download? > i know of daily and weekly builds of the installer and > some images but i have never seen any statement from > the project as a whole that "testing" is a release > candidate and treated as such. yes, it is the basis > of the next stable release, but it is not anything > more than a pool of packages in a directory structure > which can be copied and updated like any other > directory. Well, it depends when you look at it. The day before a Release Day, the codename that testing points at looks very like a release. The next day, that codename becomes a Release, but of course testing has moved on to point at the next codename, currently trixie. Trixie could become a mess, but then again, it probably won't. If it were, then it wouldn't look like a release, would it. > it is, in other words, the collection of packages > which are used which are the stable release and not > anything else which is the main product of making such > a stable release and it is the release team which > builds that and puts it all together. as far as i'm > concerned it is the release team which has that > delegated authority but i guess if they wanted to > build "official testing" images or any other > collection they surely could, but i'd be a happy > little potato doing as i have been and running from > the testing viewpoint (which can change from moment > to moment). Clearly it would be a waste of time and resource to put testing/trixie onto a DVD and start selling it. > i consider the release process as a whole which > includes at some point making copies of symlinks to > the package pool and renaming various pathways or > copying things as the whole point of making a > release and then building images and such which do > include the codename and not using things such as > "testing", "sid", "experimental" or "rc-buggy" or > ... More nonsense. They don't add/include a codename. What they do add upon release is the release number. The codename is the primary collection that is being built be Debian. The way in which it is built and maintained depends on its current status, and that status is reflected, not defined, by the symlinks pointing to it. So, a few days ago, bookworm became a Release, obtained the number 12, had the stable symlink moved to point at it, and now has a policy for its modification that differs from what it was before. > i don't really think my viewpoint is far from > the reality of what does happen, but if anyone >
Re: Debian home page -> Download link broken:
On Sun, 2023-06-11 at 15:24 -0400, Jeffrey Walton wrote: > On Sun, Jun 11, 2023 at 2:12 AM Tixy wrote: > > > > On Sat, 2023-06-10 at 23:55 -0400, Jeffrey Walton wrote: > > > Debian's wiki says to use apt-get: > > > https://wiki.debian.org/DebianUpgrade. Also see > > > https://www.debian.org/doc/manuals/debian-faq/uptodate.html . > > > > > > Maybe it's time for a complete refresh of those documents. > > > > Or maybe the wiki page should be deleted, or just say go RTFM, i.e. > > read the release notes for the release you want to upgrade to. > > Tixy, I checked the manual at > https://www.debian.org/doc/manuals/debian-handbook/sect.apt-get.en.html > . I cannot find the requirement to run 'apt upgrade'. > > Can you provide a reference, please? Sorry, I was referring to the release notes [1] not the Debian Handbook. I must admit that I didn't read the Wiki before now and to be fair it does say at the beginning to go read the release notes before going on to summarise the commands that you may need just using 'apt-get'. Note that release notes for the past two releases say to use the 'apt' command for everything, e.g.: apt update apt upgrade --without-new-pkgs apt full-upgrade And for making space and cleaning up: apt autoremove apt clean I also see that the Debian Handbook says that before starting APT related work to use 'apt update' and the release notes points out the issue [2] that users of apt-get may need --allow-releaseinfo-change. [1] https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#minimal-upgrade [2] https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#updating-lists -- Tixy
Re: Debian home page -> Download link broken:
David Wright wrote: > songbird wrote: ... >> except that is a misconception for those who are running >> testing. we're not upgrading to a new release. > > I don't understand. Suite testing was codenamed bookworm until today, > and now testing is codenamed trixie. Why is that not a new release? testing is still testing is it not? they didn't delete it and then create it again. i don't think they'd do something like that, but even if they did how would someone outside the release team know? they just created a new directory structure with the codename and put links to the packages that were the same as testing. it is like taking a snapshot but you don't destroy the original directory. after that point testing and stable diverge as changes are made (under the rules and procedures of the release team and the various software gatekeepers, security team, etc.). you could say that as soon as the first change happens that trixie is underway and i wouldn't argue too much about that at all, but i don't consider it anything other than testing and a release candidate for trixie. it's not officially a stable release for another 24-?? months and as such it isn't really named by me, but others can consider it what they want. it's only the view of the release team that really counts (and their established procedures and tools). it's like the chicken and egg problem applied to making a cake. at some point you start with an empty bowl and then put in ingredients and then at some future point (when the baking is done) you have a cake (when it is released from the pan or even taken from the oven - as some people do eat the cake directly from the pan). flour alone isn't the cake. so let's just say that testing is the bowl which holds the ingredients of the next potential stable release, you can call it what you want but it isn't an official release until the release team kicks it out the door with the codename (or not as perhaps some year we run out of codenames or Debian stops producing official images of any kind or ...). songbird
Re: Debian home page -> Download link broken:
Greg Wooledge wrote: ... > The overwhelming majority of people who track testing think that it's > a rolling release. It's not. It's actually a series of evolving > release candidates, with periods of great disruption interspersed with > periods of relative calm. > > You're clearing replying to someone who thinks it's a single rolling > release, so set your expectations accordingly. yes, we experience it as it happens, which can sometimes be months or even years before the official stable release happens and new images are built. the comment about release candidates is appropriate because that is why such things as RC bugs are filed and attempted to be fixed before a release actually happens, but that release is a stable and official one and not as far as i've ever seen it is not a "release" so calling it a rolling release is a contradiction in terminology. it is not a release, but it is a collection of packages in a certain state of being which can change as new packages migrate from unstable (or via testing-pu or via other means that perhaps i'm not aware of). i just know that for sure it is not "magic". :) someone has to do it and make the upload and other things may come along and make changes (janitor programs are now doing some things, etc.) release notes may not be written and some cases may even be forgotten about. with testing, stuff can happen, like sid, stuff can break. that is just how it goes and i'm quite ok with that because i also do keep a stable partition (which is currently not upgraded yet and won't be until a point release or two down the line). my stable is even more stable than the released stable. there's nobody to force me to upgrade or mysterious software controlled by someone else running to mess with my machine (as i do not run auto updates). can you point me to any official statement from the project as a whole which says that testing is released and there are official images for people to download? i know of daily and weekly builds of the installer and some images but i have never seen any statement from the project as a whole that "testing" is a release candidate and treated as such. yes, it is the basis of the next stable release, but it is not anything more than a pool of packages in a directory structure which can be copied and updated like any other directory. it is, in other words, the collection of packages which are used which are the stable release and not anything else which is the main product of making such a stable release and it is the release team which builds that and puts it all together. as far as i'm concerned it is the release team which has that delegated authority but i guess if they wanted to build "official testing" images or any other collection they surely could, but i'd be a happy little potato doing as i have been and running from the testing viewpoint (which can change from moment to moment). i consider the release process as a whole which includes at some point making copies of symlinks to the package pool and renaming various pathways or copying things as the whole point of making a release and then building images and such which do include the codename and not using things such as "testing", "sid", "experimental" or "rc-buggy" or ... i don't really think my viewpoint is far from the reality of what does happen, but if anyone from the release team cares to pipe up i'd listen. songbird
Re: Debian home page -> Download link broken:
On 2023-06-11 at 17:36, David Wright wrote: > On Sun 11 Jun 2023 at 09:32:04 (-0400), The Wanderer wrote: > >> On 2023-06-11 at 09:05, David Wright wrote: >>> It would seem very simple, the first time this happens, to >>> configure this in APT. I typed man apt-get (my preferred >>> method), /release >> >> Where did you come up with the 'release' search term? > > There are several sources: > > Project News News and Announcements about Debian 10June2023 Debian 12 > "bookworm" released; > > (remove the inflection from "released".) That assumes you've seen an announcement; this cycle, I don't think I had, and certainly not everyone will have been in a place to do so. > apt/apt-get man pages use release in their SYNOPSIS sections; As part of the "replace this with a real example of the class" keyword 'target_release', and not anywhere else. I certainly would not have thought of this as suggesting something to search for in the man page, or as being related to this error message. > From the term "Release Notes"; Release notes are not in my mind when I'm updating. That they are in yours indicates, as was probably already clear, that we think about these things differently. > From conversations on debian-user; > > (search for "release", and the most recent 100 matching posts in > 80,000 have a date range of just two months.) I've been reading debian-user for years on end, and it did not lead me to think of this as a search term to try. > From the error message printed when the release change fails, or the > confirmation when it succeeds (IIRC); > > (Since the time when signatures were included in Release files, > "Release" has been heavily camouflaged with the prefix "In".) See below. > From the apt-secure man page, which is mostly about Release files. This could be interpreted as a hint, I'll admit, but it did not occur to me as one when I was looking at that page. >> I don't remember what I searched for in the apt-get man page when >> I first encountered this message, but whatever it was, I didn't >> find anything relevant. >> >> Regardless, the apt-get man page isn't the one to start with, >> because it's not the one the error message directs you to. The >> error message directs you to the apt-secure man page, which does >> not provide any useful information about how to resolve the error >> message. > > Granted, that note might be improved, but as it was apt-get that > provoked the Error message, it would be natural to check out its man > page too. Indeed so, but I didn't find anything useful from searching for "update', which was the action I'd attempted to take. It did not occur to me to search for "release"; nothing I could see in the context brought that string into relevance. >> The error message also does not include the string 'release', in >> any capitalization variant, so that doesn't provide a hint for what >> to search for either. > > AIUI, it contains the string InRelease, according to > https://lists.debian.org/debian-user/2023/06/msg00392.html in this > thread. I consider that to be part not of the error message, but of the repository identifier being referenced *by* the error message. (The same would be true for the labels 'bookworm' and 'trixie'.) It did not occur to me to use that as an indicator of what to search for, and if it had, it would have led me to search not for 'release' but for 'InRelease' - since I consider that latter to be a discrete term of its own. > Debian's use of camelCase makes it easy to decompose the word. As > pointed out above, the man page that the Note directs you > (apt-secure) to uses Release rather than InRelease in all but two > places. I don't think of "InRelease" as being a word, but as being a filename that's presumably used on the repository servers and checked for by the update tooling - i.e., as an implementation detail, which is irrelevant to anyone not attempting to investigate the innards of that tooling or those servers. >>> and Space N three times, which showed: >>> >>> --allow-releaseinfo-change >>> Allow the update command to continue downloading data from a >>> repository which changed its information of the release contained >>> in the repository indicating e.g a new major release. APT will fail >>> at the update command for such repositories until the change is >>> confirmed to ensure the user is prepared for the change. See also >>> apt-secure(8) for details on the concept and configuration. >>> >>> Specialist options (--allow-releaseinfo-change-field) exist to >>> allow changes only for certain fields like origin, label, codename, >>> suite, version and defaultpin. See also apt_preferences(5). >>> Configuration Item: Acquire::AllowReleaseInfoChange. >> >> I've seen that (by searching that page for 'releaseinfo', after I >> saw the option mentioned in this thread today), and am considering >> whether to apply that configuration setting, or even to just alias >>
Re: Debian home page -> Download link broken:
On Sun, Jun 11, 2023 at 10:37:45PM +0100, David Wright wrote: > On Sun 11 Jun 2023 at 05:58:50 (-0400), songbird wrote: > > Tixy wrote: > > > On Sat, 2023-06-10 at 23:55 -0400, Jeffrey Walton wrote: > > >> Debian's wiki says to use apt-get: > > >> https://wiki.debian.org/DebianUpgrade. Also see > > >> https://www.debian.org/doc/manuals/debian-faq/uptodate.html . > > >> > > >> Maybe it's time for a complete refresh of those documents. > > > > > > Or maybe the wiki page should be deleted, or just say go RTFM, i.e. > > > read the release notes for the release you want to upgrade to. > > > > except that is a misconception for those who are running > > testing. we're not upgrading to a new release. > > I don't understand. Suite testing was codenamed bookworm until today, > and now testing is codenamed trixie. Why is that not a new release? The overwhelming majority of people who track testing think that it's a rolling release. It's not. It's actually a series of evolving release candidates, with periods of great disruption interspersed with periods of relative calm. You're clearing replying to someone who thinks it's a single rolling release, so set your expectations accordingly.
Re: Debian home page -> Download link broken:
On Sun 11 Jun 2023 at 05:58:50 (-0400), songbird wrote: > Tixy wrote: > > On Sat, 2023-06-10 at 23:55 -0400, Jeffrey Walton wrote: > >> Debian's wiki says to use apt-get: > >> https://wiki.debian.org/DebianUpgrade. Also see > >> https://www.debian.org/doc/manuals/debian-faq/uptodate.html . > >> > >> Maybe it's time for a complete refresh of those documents. > > > > Or maybe the wiki page should be deleted, or just say go RTFM, i.e. > > read the release notes for the release you want to upgrade to. > > except that is a misconception for those who are running > testing. we're not upgrading to a new release. I don't understand. Suite testing was codenamed bookworm until today, and now testing is codenamed trixie. Why is that not a new release? Cheers, David.
Re: Debian home page -> Download link broken:
Hi, On Sun, Jun 11, 2023 at 02:01:34PM -0400, Default User wrote: > https://wiki.debian.org/DebianUpgrade could use a tune-up, particularly > the part about editing /etc/apt/sources.list, which IMHO could be > worded a little more clearly. It is a wiki, so you can do that. If you can articulate where the release notes fell short for you, I think that belongs in a bug report on the release notes, too, as they are supposed to stand alone. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Debian home page -> Download link broken:
On Sun 11 Jun 2023 at 09:32:04 (-0400), The Wanderer wrote: > On 2023-06-11 at 09:05, David Wright wrote: > > On Sun 11 Jun 2023 at 08:12:49 (-0400), The Wanderer wrote: > >> On 2023-06-11 at 07:50, Andrew M.A. Cater wrote: > > >>> If you track "testing" (something which has been deprecated for > >>> a while) > >> > >> What? Since when? This is the first I remember having heard of > >> this. > >> > >> Certainly the "continuously usable testing" thing seems to have not > >> gone anywhere, or otherwise stalled - but that doesn't mean that > >> testing isn't usable, or useful, or that tracking it is > >> impractical, or anything of that nature; just that you have to > >> expect that by doing so you will occasionally see things break, e.g > >> during library transitions, and have to wait for those things to be > >> resolved. > >> > >>> then you must expect that it will change very unexpectedly on a > >>> release and then large changes immediately after as everything > >>> else catches up with being unfrozen. > >> > >> Of course it will. I actually look forward to seeing that happen, > >> and watching the flood of new package versions come in after a new > >> release. > >> > >> But that doesn't mean that we should be presented with this opaque > >> "this thing has changed, so we're going to refuse to update at all > >> till you do something to approve that change; here's a reference to > >> a man page which briefly mentions something about the technical > >> details of why this happens, but doesn't explain anything about how > >> to approve the change, or point to any other documentation which > >> does explain that". > >> > >> We *are already tracking testing*, *by that name*. We *know* that > >> when a new stable is released, the release codename that is in > >> testing is going to change. That is *expected*. It is aggravating > >> to see this prompt at all - let alone to see it again and again, > >> once every few years, and have to dredge into my memory (since it's > >> been a few years since the last time I needed the information) for > >> where to look to find the correct incantation to actually bypass > >> it. > >> > >> The same thing applies to those who track 'stable' by that name. > >> Using the symbolic names for the releases, rather than the actual > >> codenames, *is semantically different* and the tools *should treat > >> it differently*. > >> > >> I could achieve the same practical result by using the release > >> codenames, and manually editing sources.list after each release - > >> but that loses out on the *convenience* factor, as well as being > >> conceptually inappropriate; if you have something that has to be > >> done over and over in exactly the same way every time, on a > >> computer, and you are not automating it, you are Doing It Wrong. > >> Using the symbolic names should make it possible to avoid those > >> manual steps, and in fact it used to do just that, but it no longer > >> does. > >> > >> As songbird said: it should all "just work". > >> > >> I'm actually startled that, judging from the fact that your > >> responses have been centered on explaining the use of Debian > >> codenames, you seem to have so completely misinterpreted the > >> objection being raised here. > > > > It would seem very simple, the first time this happens, to configure > > this in APT. I typed man apt-get (my preferred method), /release > > Where did you come up with the 'release' search term? There are several sources: Project News News and Announcements about Debian 10June2023 Debian 12 "bookworm" released; (remove the inflection from "released".) apt/apt-get man pages use release in their SYNOPSIS sections; From the term "Release Notes"; From conversations on debian-user; (search for "release", and the most recent 100 matching posts in 80,000 have a date range of just two months.) From the error message printed when the release change fails, or the confirmation when it succeeds (IIRC); (Since the time when signatures were included in Release files, "Release" has been heavily camouflaged with the prefix "In".) From the apt-secure man page, which is mostly about Release files. > I don't remember what I searched for in the apt-get man page when I > first encountered this message, but whatever it was, I didn't find > anything relevant. > > Regardless, the apt-get man page isn't the one to start with, because > it's not the one the error message directs you to. The error message > directs you to the apt-secure man page, which does not provide any > useful information about how to resolve the error message. Granted, that note might be improved, but as it was apt-get that provoked the Error message, it would be natural to check out its man page too. > The error message also does not include the string 'release', in any > capitalization variant, so that doesn't provide a hint for what to > search for either. AIUI, it contains the string InRelease, according
Re: Debian home page -> Download link broken:
On Sun, Jun 11, 2023 at 3:35 PM Brian wrote: > > On Sun 11 Jun 2023 at 15:24:16 -0400, Jeffrey Walton wrote: > > > On Sun, Jun 11, 2023 at 2:12 AM Tixy wrote: > > > > > > On Sat, 2023-06-10 at 23:55 -0400, Jeffrey Walton wrote: > > > > Debian's wiki says to use apt-get: > > > > https://wiki.debian.org/DebianUpgrade. Also see > > > > https://www.debian.org/doc/manuals/debian-faq/uptodate.html . > > > > > > > > Maybe it's time for a complete refresh of those documents. > > > > > > Or maybe the wiki page should be deleted, or just say go RTFM, i.e. > > > read the release notes for the release you want to upgrade to. > > > > Tixy, I checked the manual at > > https://www.debian.org/doc/manuals/debian-handbook/sect.apt-get.en.html > > . I cannot find the requirement to run 'apt upgrade'. > > You failed to look very well :). I think if you read the entire article, I don't think you will find an 'apt upgrade' is a MUST. At best, it is a SHOULD for folks using apt, and it is not clear why someone should do it when using one of the other package managers. Or that was my parsing of the article. >From 6.2.1 (notice the word 'can', not 'must'): For any work with APT, the list of available packages needs to be updated; this can be done simply through apt update... The word 'can' implies the upgrade can be done other ways, too. And given the article discusses apt, apt-get and aptitude, then one should expect it can be done with all three tools. But the confusion is a perfect example of why the DebianUpgrade article should provide something prescriptive that always works. Jeff
Re: Debian home page -> Download link broken:
On Sun, Jun 11, 2023 at 03:24:16PM -0400, Jeffrey Walton wrote: > On Sun, Jun 11, 2023 at 2:12 AM Tixy wrote: > > > > On Sat, 2023-06-10 at 23:55 -0400, Jeffrey Walton wrote: > > > Debian's wiki says to use apt-get: > > > https://wiki.debian.org/DebianUpgrade. Also see > > > https://www.debian.org/doc/manuals/debian-faq/uptodate.html . > > > > > > Maybe it's time for a complete refresh of those documents. > > > > Or maybe the wiki page should be deleted, or just say go RTFM, i.e. > > read the release notes for the release you want to upgrade to. > > Tixy, I checked the manual at > https://www.debian.org/doc/manuals/debian-handbook/sect.apt-get.en.html > . I cannot find the requirement to run 'apt upgrade'. > > Can you provide a reference, please? > > I want to update the wiki page, but I need a citation to make the > change. Also, someone else will have to update the Debian FAQ. I'll > reach out to the webmaster once we have a reference. There is no need to do this if you're upgrading from one stable release to the next. The only time this is needed is when you're tracking TESTING.
Re: Debian home page -> Download link broken:
On Sun, Jun 11, 2023 at 2:12 AM Tixy wrote: > > On Sat, 2023-06-10 at 23:55 -0400, Jeffrey Walton wrote: > > Debian's wiki says to use apt-get: > > https://wiki.debian.org/DebianUpgrade. Also see > > https://www.debian.org/doc/manuals/debian-faq/uptodate.html . > > > > Maybe it's time for a complete refresh of those documents. > > Or maybe the wiki page should be deleted, or just say go RTFM, i.e. > read the release notes for the release you want to upgrade to. Tixy, I checked the manual at https://www.debian.org/doc/manuals/debian-handbook/sect.apt-get.en.html . I cannot find the requirement to run 'apt upgrade'. Can you provide a reference, please? I want to update the wiki page, but I need a citation to make the change. Also, someone else will have to update the Debian FAQ. I'll reach out to the webmaster once we have a reference. Jeff
Re: Debian home page -> Download link broken:
On Sun, 2023-06-11 at 07:11 +0100, Tixy wrote: > On Sat, 2023-06-10 at 23:55 -0400, Jeffrey Walton wrote: > > Debian's wiki says to use apt-get: > > https://wiki.debian.org/DebianUpgrade. Also see > > https://www.debian.org/doc/manuals/debian-faq/uptodate.html . > > > > Maybe it's time for a complete refresh of those documents. > > Or maybe the wiki page should be deleted, or just say go RTFM, i.e. > read the release notes for the release you want to upgrade to. > I just did a successful upgrade this morning from Debian 11 to Debian 12. I used https://wiki.debian.org/DebianUpgrade to do so. Without that, trying to go by the release notes only, I probably would not have been successful, and probably would have had to resort to doing a fresh install. Yes, I did look through the release notes, and did get good information from them. But I used https://wiki.debian.org/DebianUpgrade to actually get the job done. https://wiki.debian.org/DebianUpgrade could use a tune-up, particularly the part about editing /etc/apt/sources.list, which IMHO could be worded a little more clearly. Bottom line, please do NOT remove https://wiki.debian.org/DebianUpgrade - it was a life saver for me! Just my 2 cents worth . . .
Re: Debian home page -> Download link broken:
Greg Wooledge wrote: > On Sun, Jun 11, 2023 at 08:12:49AM -0400, The Wanderer wrote: >> The same thing applies to those who track 'stable' by that name. Using >> the symbolic names for the releases, rather than the actual codenames, >> *is semantically different* and the tools *should treat it differently*. > > Using "stable" in your sources.list is idiotic, and you should not do > it. Ever. i understand where you are coming from, but obviously i don't agree as i've been doing it for many years. > This is not a "use at your own risk" scenario, like using "testing". > That's OK for people who choose to accept the responsibility. > > Using "stable" is just a mistake. > > If you're suggesting that the behavior of the tools should change in > some way -- something I am *not* advocating -- then the bext change > would be to make them *reject* any sources.list line that uses "stable". > Inform the user that the use of that label is too dangerous, and that > they must select a specific release to track. no. that's breaking things that work fine for some people. if you keep your installation very simple there is a good chance you can do upgrades without too much fuss or bother. i just recently upgraded my stable partition and it was done without reading the release notes at all. i did have to change some lines in the apt sources list, but otherwise it all went as i would expect for it to go. on thing i do out of habit is only upgrade certain things first (apt, dpkg, core stuff) before i let the rest of the packages go in. sometimes i have to run through a few times but apt-get figures it out eventually or i have to use some flags to get broken packages fixed. my normal system runs about 2500 packages total and i don't do too many complcated things. my stable partition has many fewer packages and i don't do some things on it at all (if i add some package for testing i often remember to remove it and the dependencies so i'm not bloating it). songbird
Re: Debian home page -> Download link broken:
On 2023-06-11 at 09:34, Greg Wooledge wrote:
> On Sun, Jun 11, 2023 at 09:20:41AM -0400, The Wanderer wrote:
>
>> On 2023-06-11 at 09:02, Greg Wooledge wrote:
>>> Using "stable" in your sources.list is idiotic, and you should
>>> not do it. Ever.
>>>
>>> This is not a "use at your own risk" scenario, like using
>>> "testing". That's OK for people who choose to accept the
>>> responsibility.
>>>
>>> Using "stable" is just a mistake.
>>
>> I do not understand why or how. If you want to transition from one
>> stable release to the next when that "next" release is made, I
>> don't see any better option for doing so, and I don't see how
>> there's any downside to using the symbolic name 'stable' for that
>> purpose.
>
> The issue is that an upgrade to a new stable release CANNOT BE
> AUTOMATED by the tools. There are manual steps required, and these
> are specific to each release, and to each user's unique system.
While I recognize that automation is in some cases a hard problem, I
also take the position that if you have a task that has to be carried
out on a computer over and over the exact same way every time, and you
are not automating it, you are doing it wrong.
Thus, I push back - not absolutely, but fairly hard - against "cannot be
automated".
> One example of this -- among many! -- is the changing of sources.list
> line syntax across releases. This time around, we got a new section
> ("non-free-firmware") that had to be added to each line. Before that,
> there was a change to the syntax of the security.debian.org line,
> from "buster/updates" to "bullseye-security".
And rather than putting in the design, etc., work to make these things
happen automatically when they should (and not when they shouldn't), the
developers gave up and punted it to the release notes. That could be
acceptable if done rarely, but from what I remember seeing, it seems to
happen *multiple times per release*.
As I already mentioned, it's an insufficient solution - both because
people will not read the release notes before upgrading, as I mentioned,
and also because people who are tracking testing will encounter these
changes before the release notes are written. For the most part, release
notes should be for "important changes you might want to be aware of"
and/or for getting more information on the details of changes, not for
some kind of mandatory upgrade checklist.
I might even argue that for changes like the two you cite, there should
at minimum have been a tool provided (whether on a Website, or in a
Debian package, if not something run automatically) which would make the
necessary adjustments.
> And that's just an obvious and superficial change. There are
> deeper, more subtle changes as well. None of this is automatic, and
> a user who is expecting that "hey, I can just use stable and it'll
> upgrade for me every time it needs to!!!" needs to be educated.
That's not the same as the position you took above, and while I could
agree with this one, I do not agree with the other.
--
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
Re: Debian home page -> Download link broken:
On Sun, Jun 11, 2023 at 09:20:41AM -0400, The Wanderer wrote:
> On 2023-06-11 at 09:02, Greg Wooledge wrote:
>
> > On Sun, Jun 11, 2023 at 08:12:49AM -0400, The Wanderer wrote:
> >
> >> The same thing applies to those who track 'stable' by that name.
> >> Using the symbolic names for the releases, rather than the actual
> >> codenames, *is semantically different* and the tools *should treat
> >> it differently*.
> >
> > Using "stable" in your sources.list is idiotic, and you should not do
> > it. Ever.
> >
> > This is not a "use at your own risk" scenario, like using "testing".
> > That's OK for people who choose to accept the responsibility.
> >
> > Using "stable" is just a mistake.
>
> I do not understand why or how. If you want to transition from one
> stable release to the next when that "next" release is made, I don't see
> any better option for doing so, and I don't see how there's any downside
> to using the symbolic name 'stable' for that purpose.
The issue is that an upgrade to a new stable release CANNOT BE AUTOMATED
by the tools. There are manual steps required, and these are specific
to each release, and to each user's unique system.
One example of this -- among many! -- is the changing of sources.list
line syntax across releases. This time around, we got a new section
("non-free-firmware") that had to be added to each line. Before that,
there was a change to the syntax of the security.debian.org line, from
"buster/updates" to "bullseye-security".
And that's just an obvious and superficial change. There are deeper,
more subtle changes as well. None of this is automatic, and a user
who is expecting that "hey, I can just use stable and it'll upgrade
for me every time it needs to!!!" needs to be educated.
Re: Debian home page -> Download link broken:
On 2023-06-11 at 09:05, David Wright wrote: > On Sun 11 Jun 2023 at 08:12:49 (-0400), The Wanderer wrote: > >> On 2023-06-11 at 07:50, Andrew M.A. Cater wrote: >>> If you track "testing" (something which has been deprecated for >>> a while) >> >> What? Since when? This is the first I remember having heard of >> this. >> >> Certainly the "continuously usable testing" thing seems to have not >> gone anywhere, or otherwise stalled - but that doesn't mean that >> testing isn't usable, or useful, or that tracking it is >> impractical, or anything of that nature; just that you have to >> expect that by doing so you will occasionally see things break, e.g >> during library transitions, and have to wait for those things to be >> resolved. >> >>> then you must expect that it will change very unexpectedly on a >>> release and then large changes immediately after as everything >>> else catches up with being unfrozen. >> >> Of course it will. I actually look forward to seeing that happen, >> and watching the flood of new package versions come in after a new >> release. >> >> But that doesn't mean that we should be presented with this opaque >> "this thing has changed, so we're going to refuse to update at all >> till you do something to approve that change; here's a reference to >> a man page which briefly mentions something about the technical >> details of why this happens, but doesn't explain anything about how >> to approve the change, or point to any other documentation which >> does explain that". >> >> We *are already tracking testing*, *by that name*. We *know* that >> when a new stable is released, the release codename that is in >> testing is going to change. That is *expected*. It is aggravating >> to see this prompt at all - let alone to see it again and again, >> once every few years, and have to dredge into my memory (since it's >> been a few years since the last time I needed the information) for >> where to look to find the correct incantation to actually bypass >> it. >> >> The same thing applies to those who track 'stable' by that name. >> Using the symbolic names for the releases, rather than the actual >> codenames, *is semantically different* and the tools *should treat >> it differently*. >> >> I could achieve the same practical result by using the release >> codenames, and manually editing sources.list after each release - >> but that loses out on the *convenience* factor, as well as being >> conceptually inappropriate; if you have something that has to be >> done over and over in exactly the same way every time, on a >> computer, and you are not automating it, you are Doing It Wrong. >> Using the symbolic names should make it possible to avoid those >> manual steps, and in fact it used to do just that, but it no longer >> does. >> >> As songbird said: it should all "just work". >> >> I'm actually startled that, judging from the fact that your >> responses have been centered on explaining the use of Debian >> codenames, you seem to have so completely misinterpreted the >> objection being raised here. > > It would seem very simple, the first time this happens, to configure > this in APT. I typed man apt-get (my preferred method), /release Where did you come up with the 'release' search term? I don't remember what I searched for in the apt-get man page when I first encountered this message, but whatever it was, I didn't find anything relevant. Regardless, the apt-get man page isn't the one to start with, because it's not the one the error message directs you to. The error message directs you to the apt-secure man page, which does not provide any useful information about how to resolve the error message. The error message also does not include the string 'release', in any capitalization variant, so that doesn't provide a hint for what to search for either. > and Space N three times, which showed: > > --allow-releaseinfo-change > Allow the update command to continue downloading data from a > repository which changed its information of the release contained > in the repository indicating e.g a new major release. APT will fail > at the update command for such repositories until the change is > confirmed to ensure the user is prepared for the change. See also > apt-secure(8) for details on the concept and configuration. > > Specialist options (--allow-releaseinfo-change-field) exist to > allow changes only for certain fields like origin, label, codename, > suite, version and defaultpin. See also apt_preferences(5). > Configuration Item: Acquire::AllowReleaseInfoChange. I've seen that (by searching that page for 'releaseinfo', after I saw the option mentioned in this thread today), and am considering whether to apply that configuration setting, or even to just alias 'apt-get' to 'apt-get --alow-releaseinfo-change' or one of the field-specific sub-options. However, this seems like a potentially poor idea, for a minimum of two
Re: Debian home page -> Download link broken:
On 2023-06-11 at 09:02, Greg Wooledge wrote: > On Sun, Jun 11, 2023 at 08:12:49AM -0400, The Wanderer wrote: > >> The same thing applies to those who track 'stable' by that name. >> Using the symbolic names for the releases, rather than the actual >> codenames, *is semantically different* and the tools *should treat >> it differently*. > > Using "stable" in your sources.list is idiotic, and you should not do > it. Ever. > > This is not a "use at your own risk" scenario, like using "testing". > That's OK for people who choose to accept the responsibility. > > Using "stable" is just a mistake. I do not understand why or how. If you want to transition from one stable release to the next when that "next" release is made, I don't see any better option for doing so, and I don't see how there's any downside to using the symbolic name 'stable' for that purpose. I also don't see how there's any difference between using the name 'stable' and using the codenames of each stable release, except in regard to the convenience factor - that is, whether the transition is picked up automatically, or whether you have to notice that the release has happened and manually modify sources.list to use the new name. I myself have sources.list entries for both 'stable' and 'testing' (as well as ancillary repositories for each, such as the -debug variants), have been running that way for a long time without related issues, and would not want to run with any other configuration. The only possible justification I can see for taking that position is the "it's dangerous to upgrade from one stable release to the next without reading the release notes first" thing, which I consider an ill-advised policy in the first place (you are *never* going to have everyone read the release notes before upgrading, any more than you are going to have people read other documentation before trying to use the thing which it documents, and it's a bad idea to design around the expectation that people will), and which in any case doesn't apply to people who are tracking testing+stable as I do. > If you're suggesting that the behavior of the tools should change in > some way -- something I am *not* advocating -- then the bext change > would be to make them *reject* any sources.list line that uses > "stable". Inform the user that the use of that label is too > dangerous, and that they must select a specific release to track. I could, maybe, perhaps, see an argument for prohibiting tracking stable, by that name, alone. However, a reject such as you are describing would also prevent the scenario I use for myself, which is effectively tracking testing with fallback to stable. If that scenario would also be worth rejecting... then that might be the final straw that confirms that Debian has in fact abandoned my use cases, and it really *is* time I found something else to move to, which would be a decidedly unhappy development. I would not necessarily object to the inclusion of a run-time *warning* about the use of such a line, especially not if there were a configuration option to disable the presentation of such a warning. I do, however, think it would be better for the tools to not require '--allow-releaseinfo-change' for repositories specified by such symbolic names - or at least to have a configuration option to not require such for that case. (My understanding is that there *is* a configuration setting to effectively enable that flag unconditionally in all cases, but I'm not sure I want to do that, and I haven't dug deep enough yet to find out whether there are more fine-grained versions of the configuration setting that might do something closer to the specific thing I want.) That said, I'm not particularly advocating for that change. What I *do* advocate, in this context, is that either the message printed by apt-get when it sees the mismatch should be changed to point to a document which explains how to approve the change, or the document to which it points - apt-secure(8) - should be changed to explain that. It is *boggling* that we have reached, if I'm not mistaken, now at least the *third* consecutive Debian release with this uninformative and unhelpful "see here for more" message. -- 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
Re: Debian home page -> Download link broken:
On Sun 11 Jun 2023 at 08:12:49 (-0400), The Wanderer wrote: > On 2023-06-11 at 07:50, Andrew M.A. Cater wrote: > > On Sun, Jun 11, 2023 at 05:58:50AM -0400, songbird wrote: > >> Tixy wrote: > > >>> Or maybe the wiki page should be deleted, or just say go RTFM, > >>> i.e. read the release notes for the release you want to upgrade > >>> to. > >> > >> except that is a misconception for those who are running testing. > >> we're not upgrading to a new release. > > > I may go and have a crack at editing the wiki pages in a few > > minutes. Hint: Anybody with a wiki account can edit the wiki - it > > really is a wiki. > > > > Release names and codenames: > > > > This is a subject that has been fairly well explained over the > > years. Debian 1.0 never actually got released - someone took > > pre-release links and rebranded them as "Debian 1.0" for a CD > > release. At that time, Debian took on the idea of release names to > > stop this happening again. > > > > If you follow the release name in your /etc/apt/sources.list it will > > follow a release from testing -> stable -> oldstable -> > > oldoldstable. > > > > If you track "testing" (something which has been deprecated for a > > while) > > What? Since when? This is the first I remember having heard of this. > > Certainly the "continuously usable testing" thing seems to have not gone > anywhere, or otherwise stalled - but that doesn't mean that testing > isn't usable, or useful, or that tracking it is impractical, or anything > of that nature; just that you have to expect that by doing so you will > occasionally see things break, e.g during library transitions, and have > to wait for those things to be resolved. > > > then you must expect that it will change very unexpectedly on a > > release and then large changes immediately after as everything else > > catches up with being unfrozen. > > Of course it will. I actually look forward to seeing that happen, and > watching the flood of new package versions come in after a new release. > > But that doesn't mean that we should be presented with this opaque "this > thing has changed, so we're going to refuse to update at all till you do > something to approve that change; here's a reference to a man page which > briefly mentions something about the technical details of why this > happens, but doesn't explain anything about how to approve the change, > or point to any other documentation which does explain that". > > We *are already tracking testing*, *by that name*. We *know* that when a > new stable is released, the release codename that is in testing is going > to change. That is *expected*. It is aggravating to see this prompt at > all - let alone to see it again and again, once every few years, and > have to dredge into my memory (since it's been a few years since the > last time I needed the information) for where to look to find the > correct incantation to actually bypass it. > > The same thing applies to those who track 'stable' by that name. Using > the symbolic names for the releases, rather than the actual codenames, > *is semantically different* and the tools *should treat it differently*. > > I could achieve the same practical result by using the release > codenames, and manually editing sources.list after each release - but > that loses out on the *convenience* factor, as well as being > conceptually inappropriate; if you have something that has to be done > over and over in exactly the same way every time, on a computer, and you > are not automating it, you are Doing It Wrong. Using the symbolic names > should make it possible to avoid those manual steps, and in fact it used > to do just that, but it no longer does. > > As songbird said: it should all "just work". > > I'm actually startled that, judging from the fact that your responses > have been centered on explaining the use of Debian codenames, you seem > to have so completely misinterpreted the objection being raised here. It would seem very simple, the first time this happens, to configure this in APT. I typed man apt-get (my preferred method), /release and Space N three times, which showed: --allow-releaseinfo-change Allow the update command to continue downloading data from a repository which changed its information of the release contained in the repository indicating e.g a new major release. APT will fail at the update command for such repositories until the change is confirmed to ensure the user is prepared for the change. See also apt-secure(8) for details on the concept and configuration. Specialist options (--allow-releaseinfo-change-field) exist to allow changes only for certain fields like origin, label, codename, suite, version and defaultpin. See also apt_preferences(5). Configuration Item: Acquire::AllowReleaseInfoChange. Cheers, David.
Re: Debian home page -> Download link broken:
The Wanderer wrote: > On 2023-06-11 at 07:50, Andrew M.A. Cater wrote: ... >> If you track "testing" (something which has been deprecated for a >> while) > > What? Since when? This is the first I remember having heard of this. ditto... > Certainly the "continuously usable testing" thing seems to have not gone > anywhere, or otherwise stalled - but that doesn't mean that testing > isn't usable, or useful, or that tracking it is impractical, or anything > of that nature; just that you have to expect that by doing so you will > occasionally see things break, e.g during library transitions, and have > to wait for those things to be resolved. exactly, as i have always experienced and anticipated. i've been running testing + a few packages from sid for quite a long time. i also keep a stable partition (which is not following a code name either). i understand how those work along with sid. >> then you must expect that it will change very unexpectedly on a >> release and then large changes immediately after as everything else >> catches up with being unfrozen. > > Of course it will. I actually look forward to seeing that happen, and > watching the flood of new package versions come in after a new release. same here. i'm glad the new stable release is out! kudoes to all Debian developers, maintainers and the rest of the Debian community! :) > But that doesn't mean that we should be presented with this opaque "this > thing has changed, so we're going to refuse to update at all till you do > something to approve that change; here's a reference to a man page which > briefly mentions something about the technical details of why this > happens, but doesn't explain anything about how to approve the change, > or point to any other documentation which does explain that". > > We *are already tracking testing*, *by that name*. We *know* that when a > new stable is released, the release codename that is in testing is going > to change. That is *expected*. It is aggravating to see this prompt at > all - let alone to see it again and again, once every few years, and > have to dredge into my memory (since it's been a few years since the > last time I needed the information) for where to look to find the > correct incantation to actually bypass it. gladly someone did refresh my decrepit memory. > The same thing applies to those who track 'stable' by that name. Using > the symbolic names for the releases, rather than the actual codenames, > *is semantically different* and the tools *should treat it differently*. i don't really care how it is treated but if someone is tracking testing then breaking that is expected at times, but also fixes which seem reasonable should be applied and one fix i'd be in favor of is just accepting that change auto- matically for people who are tracking testing and then others who want to fiddle with the codenames can do what they'd like. > I could achieve the same practical result by using the release > codenames, and manually editing sources.list after each release - but > that loses out on the *convenience* factor, as well as being > conceptually inappropriate; if you have something that has to be done > over and over in exactly the same way every time, on a computer, and you > are not automating it, you are Doing It Wrong. Using the symbolic names > should make it possible to avoid those manual steps, and in fact it used > to do just that, but it no longer does. pretty much what i just wrote above in much finer words. :) > As songbird said: it should all "just work". > > I'm actually startled that, judging from the fact that your responses > have been centered on explaining the use of Debian codenames, you seem > to have so completely misinterpreted the objection being raised here. yes, but he is writing for the much wider audience perhaps? it's ok. as someone who's been aware of Debian since "Slink" and running it for a good long time i'm pretty well steeped in things and have tried various scenarios and also tried some other distributions but none really stacked up as well as Debian has. for that it is a big thanks for the many volunteers who've done the work over the years and i hope will continue for many more. :) songbird
Re: Debian home page -> Download link broken:
On Sun, Jun 11, 2023 at 08:12:49AM -0400, The Wanderer wrote: > The same thing applies to those who track 'stable' by that name. Using > the symbolic names for the releases, rather than the actual codenames, > *is semantically different* and the tools *should treat it differently*. Using "stable" in your sources.list is idiotic, and you should not do it. Ever. This is not a "use at your own risk" scenario, like using "testing". That's OK for people who choose to accept the responsibility. Using "stable" is just a mistake. If you're suggesting that the behavior of the tools should change in some way -- something I am *not* advocating -- then the bext change would be to make them *reject* any sources.list line that uses "stable". Inform the user that the use of that label is too dangerous, and that they must select a specific release to track.
Re: Debian home page -> Download link broken:
> > On Sat, Jun 10, 2023 at 06:52:59PM -0400, songbird wrote: > > > = > > > # apt-get update > > [...] > > > Reading package lists... Done > > > E: Repository 'http://deb.debian.org/debian-debug testing-debug > > > InRelease' changed its 'Codename' value from 'bookworm-debug' to > > > 'trixie-debug' > > > N: This must be accepted explicitly before updates for this repository > > > can be applied. See apt-secure(8) manpage for details. On Sat, Jun 10, 2023 at 11:55:40PM -0400, Jeffrey Walton wrote: > Debian's wiki says to use apt-get: > https://wiki.debian.org/DebianUpgrade. Also see > https://www.debian.org/doc/manuals/debian-faq/uptodate.html . > > Maybe it's time for a complete refresh of those documents. The documents in question are correct for upgrades from one stable release version to the next. What songbird is doing is following testing. TOTALLY different thing.
Re: Debian home page -> Download link broken:
On 2023-06-11 at 07:50, Andrew M.A. Cater wrote: > On Sun, Jun 11, 2023 at 05:58:50AM -0400, songbird wrote: > >> Tixy wrote: >>> Or maybe the wiki page should be deleted, or just say go RTFM, >>> i.e. read the release notes for the release you want to upgrade >>> to. >> >> except that is a misconception for those who are running testing. >> we're not upgrading to a new release. > Hi Songbird and all, > > I may go and have a crack at editing the wiki pages in a few > minutes. Hint: Anybody with a wiki account can edit the wiki - it > really is a wiki. > > Release names and codenames: > > This is a subject that has been fairly well explained over the > years. Debian 1.0 never actually got released - someone took > pre-release links and rebranded them as "Debian 1.0" for a CD > release. At that time, Debian took on the idea of release names to > stop this happening again. > > If you follow the release name in your /etc/apt/sources.list it will > follow a release from testing -> stable -> oldstable -> > oldoldstable. > > If you track "testing" (something which has been deprecated for a > while) What? Since when? This is the first I remember having heard of this. Certainly the "continuously usable testing" thing seems to have not gone anywhere, or otherwise stalled - but that doesn't mean that testing isn't usable, or useful, or that tracking it is impractical, or anything of that nature; just that you have to expect that by doing so you will occasionally see things break, e.g during library transitions, and have to wait for those things to be resolved. > then you must expect that it will change very unexpectedly on a > release and then large changes immediately after as everything else > catches up with being unfrozen. Of course it will. I actually look forward to seeing that happen, and watching the flood of new package versions come in after a new release. But that doesn't mean that we should be presented with this opaque "this thing has changed, so we're going to refuse to update at all till you do something to approve that change; here's a reference to a man page which briefly mentions something about the technical details of why this happens, but doesn't explain anything about how to approve the change, or point to any other documentation which does explain that". We *are already tracking testing*, *by that name*. We *know* that when a new stable is released, the release codename that is in testing is going to change. That is *expected*. It is aggravating to see this prompt at all - let alone to see it again and again, once every few years, and have to dredge into my memory (since it's been a few years since the last time I needed the information) for where to look to find the correct incantation to actually bypass it. The same thing applies to those who track 'stable' by that name. Using the symbolic names for the releases, rather than the actual codenames, *is semantically different* and the tools *should treat it differently*. I could achieve the same practical result by using the release codenames, and manually editing sources.list after each release - but that loses out on the *convenience* factor, as well as being conceptually inappropriate; if you have something that has to be done over and over in exactly the same way every time, on a computer, and you are not automating it, you are Doing It Wrong. Using the symbolic names should make it possible to avoid those manual steps, and in fact it used to do just that, but it no longer does. As songbird said: it should all "just work". I'm actually startled that, judging from the fact that your responses have been centered on explaining the use of Debian codenames, you seem to have so completely misinterpreted the objection being raised here. -- 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
Re: Debian home page -> Download link broken:
On Sun, Jun 11, 2023 at 05:58:50AM -0400, songbird wrote: > Tixy wrote: > > On Sat, 2023-06-10 at 23:55 -0400, Jeffrey Walton wrote: > >> Debian's wiki says to use apt-get: > >> https://wiki.debian.org/DebianUpgrade. Also see > >> https://www.debian.org/doc/manuals/debian-faq/uptodate.html . > >> > >> Maybe it's time for a complete refresh of those documents. > > > > Or maybe the wiki page should be deleted, or just say go RTFM, i.e. > > read the release notes for the release you want to upgrade to. > > except that is a misconception for those who are running > testing. we're not upgrading to a new release. > > > songbird > Hi Songbird and all, I may go and have a crack at editing the wiki pages in a few minutes. Hint: Anybody with a wiki account can edit the wiki - it really is a wiki. Release names and codenames: This is a subject that has been fairly well explained over the years. Debian 1.0 never actually got released - someone took pre-release links and rebranded them as "Debian 1.0" for a CD release. At that time, Debian took on the idea of release names to stop this happening again. If you follow the release name in your /etc/apt/sources.list it will follow a release from testing -> stable -> oldstable -> oldoldstable. If you track "testing" (something which has been deprecated for a while) then you must expect that it will change very unexpectedly on a release and then large changes immediately after as everything else catches up with being unfrozen. Unstable is _always_ sid - the character in Toy Story who breaks things - and you must expect major churn and random changes at short notice. All best as ever, Andy Cater
Re: Debian home page -> Download link broken:
Tixy wrote: > On Sat, 2023-06-10 at 23:55 -0400, Jeffrey Walton wrote: >> Debian's wiki says to use apt-get: >> https://wiki.debian.org/DebianUpgrade. Also see >> https://www.debian.org/doc/manuals/debian-faq/uptodate.html . >> >> Maybe it's time for a complete refresh of those documents. > > Or maybe the wiki page should be deleted, or just say go RTFM, i.e. > read the release notes for the release you want to upgrade to. except that is a misconception for those who are running testing. we're not upgrading to a new release. songbird
Re: Debian home page -> Download link broken:
Jeffrey Walton writes: > On Sun, Jun 11, 2023 at 2:12 AM Tixy wrote: >> >> On Sat, 2023-06-10 at 23:55 -0400, Jeffrey Walton wrote: >> > Debian's wiki says to use apt-get: >> > https://wiki.debian.org/DebianUpgrade. Also see >> > https://www.debian.org/doc/manuals/debian-faq/uptodate.html . >> > >> > Maybe it's time for a complete refresh of those documents. >> >> Or maybe the wiki page should be deleted, or just say go RTFM, i.e. >> read the release notes for the release you want to upgrade to. > > Probably too late to delete the page. Wiki's are used for long term > dissemination of information, and the link has been shared countless > times. At this point it is likely best to update the wiki pages. > I agree with Jeff's comments. Because i also read that wiki page when i did upgrade to 12 from 11. This is Bookworm's Emacs. Sincerely, Byung-Hee (Bookworm user) -- ^고맙습니다 _布德天下_ 감사합니다_^))//
Re: Debian home page -> Download link broken:
On Sun, Jun 11, 2023 at 2:12 AM Tixy wrote: > > On Sat, 2023-06-10 at 23:55 -0400, Jeffrey Walton wrote: > > Debian's wiki says to use apt-get: > > https://wiki.debian.org/DebianUpgrade. Also see > > https://www.debian.org/doc/manuals/debian-faq/uptodate.html . > > > > Maybe it's time for a complete refresh of those documents. > > Or maybe the wiki page should be deleted, or just say go RTFM, i.e. > read the release notes for the release you want to upgrade to. Probably too late to delete the page. Wiki's are used for long term dissemination of information, and the link has been shared countless times. At this point it is likely best to update the wiki pages. Jeff
Re: Debian home page -> Download link broken:
On Sat, 2023-06-10 at 23:55 -0400, Jeffrey Walton wrote: > Debian's wiki says to use apt-get: > https://wiki.debian.org/DebianUpgrade. Also see > https://www.debian.org/doc/manuals/debian-faq/uptodate.html . > > Maybe it's time for a complete refresh of those documents. Or maybe the wiki page should be deleted, or just say go RTFM, i.e. read the release notes for the release you want to upgrade to. -- Tixy
Re: Debian home page -> Download link broken:
On Sat, Jun 10, 2023 at 8:13 PM Greg Wooledge wrote: > > On Sat, Jun 10, 2023 at 06:52:59PM -0400, songbird wrote: > > = > > # apt-get update > [...] > > Reading package lists... Done > > E: Repository 'http://deb.debian.org/debian-debug testing-debug InRelease' > > changed its 'Codename' value from 'bookworm-debug' to 'trixie-debug' > > N: This must be accepted explicitly before updates for this repository can > > be applied. See apt-secure(8) manpage for details. > > This is not the first time this has happened. You need to run > "apt update" once. This will "accept" the change, whereas "apt-get update" > does not. > > After this one instance of apt, you can go back to apt-get. Debian's wiki says to use apt-get: https://wiki.debian.org/DebianUpgrade. Also see https://www.debian.org/doc/manuals/debian-faq/uptodate.html . Maybe it's time for a complete refresh of those documents. Jeff
Re: Debian home page -> Download link broken:
On Sat, 10 Jun 2023, Greg Wooledge wrote: On Sat, Jun 10, 2023 at 06:52:59PM -0400, songbird wrote: = # apt-get update [...] Reading package lists... Done E: Repository 'http://deb.debian.org/debian-debug testing-debug InRelease' changed its 'Codename' value from 'bookworm-debug' to 'trixie-debug' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. This is not the first time this has happened. You need to run "apt update" once. This will "accept" the change, whereas "apt-get update" does not. After this one instance of apt, you can go back to apt-get. or apt-get update --allow-releaseinfo-change
Re: Debian home page -> Download link broken:
Greg Wooledge wrote: > On Sat, Jun 10, 2023 at 06:52:59PM -0400, songbird wrote: >> = >> # apt-get update > [...] >> Reading package lists... Done >> E: Repository 'http://deb.debian.org/debian-debug testing-debug InRelease' >> changed its 'Codename' value from 'bookworm-debug' to 'trixie-debug' >> N: This must be accepted explicitly before updates for this repository can >> be applied. See apt-secure(8) manpage for details. > > This is not the first time this has happened. You need to run > "apt update" once. This will "accept" the change, whereas "apt-get update" > does not. > > After this one instance of apt, you can go back to apt-get. thanks for the reminder. :) i had to answer the two prompts to accept the changes. i hope in two to three more years i remember this is needed. songbird
Re: Debian home page -> Download link broken:
On Sat, Jun 10, 2023 at 06:52:59PM -0400, songbird wrote: > = > # apt-get update [...] > Reading package lists... Done > E: Repository 'http://deb.debian.org/debian-debug testing-debug InRelease' > changed its 'Codename' value from 'bookworm-debug' to 'trixie-debug' > N: This must be accepted explicitly before updates for this repository can be > applied. See apt-secure(8) manpage for details. This is not the first time this has happened. You need to run "apt update" once. This will "accept" the change, whereas "apt-get update" does not. After this one instance of apt, you can go back to apt-get.
Re: Debian home page -> Download link broken:
On Sat, Jun 10, 2023 at 06:52:59PM -0400, songbird wrote: > David Christensen wrote: > > debian-user: > > > > $ date > > Sat Jun 10 14:50:40 PDT 2023 > > > > > > The "Download" link on the Debian home page is currently broken: > > > > https://www.debian.org/ > > > > -> Download > ... > > there are also other artifacts happening which i hope > will eventually be corrected as the release process gets > completed. > > > = > # apt-get update > Hit:1 http://http.us.debian.org/debian sid InRelease > Get:2 http://http.us.debian.org/debian testing InRelease [108 kB] > Get:3 http://deb.debian.org/debian-debug testing-debug InRelease [32.1 kB] > Hit:4 http://security.debian.org testing-security InRelease > > Hit:5 http://deb.debian.org/debian-debug unstable-debug InRelease > > Reading package lists... Done > E: Repository 'http://deb.debian.org/debian-debug testing-debug InRelease' > changed its 'Codename' value from 'bookworm-debug' to 'trixie-debug' > N: This must be accepted explicitly before updates for this repository can be > applied. See apt-secure(8) manpage for details. > E: Repository 'http://http.us.debian.org/debian testing InRelease' changed > its 'Codename' value from 'bookworm' to 'trixie' > N: This must be accepted explicitly before updates for this repository can be > applied. See apt-secure(8) manpage for details. > = > > i don't use the codenames in my apt sources list because i > do not want to deal with changes like this happening. it > should all just work[tm]... > A litle bit of history: the reasone we HAVE codenames is to sort this out. There wasn't a Debian 1.0 because someone put out a "1.0" when there was just about 0.97. Using testing and stable leads to a flag day when there's a major release. If you tie to a codename, this can follow on for up to five years. All the very best, as ever, andy Cater > > songbird >
Re: Debian home page -> Download link broken:
David Christensen wrote: > debian-user: > > $ date > Sat Jun 10 14:50:40 PDT 2023 > > > The "Download" link on the Debian home page is currently broken: > > https://www.debian.org/ > > -> Download ... there are also other artifacts happening which i hope will eventually be corrected as the release process gets completed. = # apt-get update Hit:1 http://http.us.debian.org/debian sid InRelease Get:2 http://http.us.debian.org/debian testing InRelease [108 kB] Get:3 http://deb.debian.org/debian-debug testing-debug InRelease [32.1 kB] Hit:4 http://security.debian.org testing-security InRelease Hit:5 http://deb.debian.org/debian-debug unstable-debug InRelease Reading package lists... Done E: Repository 'http://deb.debian.org/debian-debug testing-debug InRelease' changed its 'Codename' value from 'bookworm-debug' to 'trixie-debug' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. E: Repository 'http://http.us.debian.org/debian testing InRelease' changed its 'Codename' value from 'bookworm' to 'trixie' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. = i don't use the codenames in my apt sources list because i do not want to deal with changes like this happening. it should all just work[tm]... songbird
Re: Debian home page -> Download link broken:
Peter Ehlert wrote: ... > have a little patience > https://forums.debian.net/viewtopic.php?p=773925#p773925 :) i have that. :) thanks for the link... songbird
Re: Debian home page -> Download link broken:
On 6/10/23 14:51, David Christensen wrote: debian-user: $ date Sat Jun 10 14:50:40 PDT 2023 The "Download" link on the Debian home page is currently broken: https://www.debian.org/ -> Download https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.7.0-amd64-netinst.iso 404 Not Found Not Found The requested URL was not found on this server. Apache/2.4.55 (Unix) Server at cdimage.debian.org Port 443 David have a little patience https://forums.debian.net/viewtopic.php?p=773925#p773925
Re: Debian home page -> Download link broken:
On Sat, Jun 10, 2023 at 02:51:00PM -0700, David Christensen wrote: > debian-user: > > $ date > Sat Jun 10 14:50:40 PDT 2023 > > > The "Download" link on the Debian home page is currently broken: > > https://www.debian.org/ > > -> Download > You may just find that it has changed to Debian 12.0.0 in the last couple of hours with the release. With every good wish, as ever, Andy Cater [part of the CD release and testing team] > > https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.7.0-amd64-netinst.iso > > > > 404 Not Found > > Not Found > The requested URL was not found on this server. > > Apache/2.4.55 (Unix) Server at cdimage.debian.org Port > 443 > > > > David >
Debian home page -> Download link broken:
debian-user: $ date Sat Jun 10 14:50:40 PDT 2023 The "Download" link on the Debian home page is currently broken: https://www.debian.org/ -> Download https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-11.7.0-amd64-netinst.iso 404 Not Found Not Found The requested URL was not found on this server. Apache/2.4.55 (Unix) Server at cdimage.debian.org Port 443 David
