Re: debian.org - broken Download link.

[David Christensen]

On 10/9/23 05:07, Dmitry wrote:

Hi, Brad.

The issue with a broken download link was in browser cache. It preserved 
link

to previous 12.1 version in html. After force update by F5 the issue was
resolved.

P.S. It is so uncommon when robust technologies with low resource 
consumption

are used, with SinglePageApplications no need to press F5, full data set
downloaded per each request.



There are two hard problems in computer science:

1.  What to name things.

2.  When to clear caches.

3.  Off-by-one errors.


See also:

* "The Mess We're In" by Joe Armstrong 
https://www.youtube.com/watch?v=lKXe3HUG2l4



David

Re: Single-page application [was: debian.org - broken Download link.]

[tomas]

On Mon, Oct 09, 2023 at 09:56:43PM +0700, Dima Estudiante wrote:
> > Tastes can be so different :)
> 
> Looks like our tastes quite the same.
> - Plain HTML with Caching is a robust but now days rare used.
> - SPA widely used, but with high resource consumption.

Glad I'm not alone :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Single-page application [was: debian.org - broken Download link.]

[tomas]

On Mon, Oct 09, 2023 at 07:39:44AM -0700, Mike Castle wrote:
> On Mon, Oct 9, 2023 at 6:11 AM  wrote:
> 
> > Gah, no. As a user I hate those with all my guts. Page "state" is
> > distributed in some intransparent way across client and server and
> > there is no way to refer to "something" via an URL.
> 
> Many modern SPAs track state via URL, so they can be referenced.  And
> not just as a ?query or #fragment either.

Sometimes they get it right, yes. Most of the time not.

The problem with web "applications" is that every framework seems
intent in reinventing every wheel, in slightly different ways. Web
"programmers" using those frameworks use them in, again, slightly
different ways. The upshot:

 - slightly different UI "languages" for every application
   (e.g. copy-paste works sometimes, sometimes it doesn't,
   yadda, yadda)
 - at the time the fattest bugs are shaken out, the framework
   dies and is replaced by an even chee^H^H^H^H cooler one.

I've been using my $COMPANY's webmail (a single-pager) for a while.
You can change to calender. If you do a reload, you're thrown back
into your inbox.

People put up with this instead of screaming at their provider.

(I discovered there's an IMAP. Thankfully).

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Single-page application [was: debian.org - broken Download link.]

[Dima Estudiante]

> Tastes can be so different :)

Looks like our tastes quite the same.
- Plain HTML with Caching is a robust but now days rare used.
- SPA widely used, but with high resource consumption.

Re: Single-page application [was: debian.org - broken Download link.]

[Mike Castle]

On Mon, Oct 9, 2023 at 6:11 AM  wrote:

> Gah, no. As a user I hate those with all my guts. Page "state" is
> distributed in some intransparent way across client and server and
> there is no way to refer to "something" via an URL.

Many modern SPAs track state via URL, so they can be referenced.  And
not just as a ?query or #fragment either.

mrc

Single-page application [was: debian.org - broken Download link.]

[tomas]

On Mon, Oct 09, 2023 at 07:07:09PM +0700, Dmitry wrote:

[...]

> P.S. It is so uncommon when robust technologies with low resource consumption
> are used, with SinglePageApplications no need to press F5, full data set
> downloaded per each request.

Gah, no. As a user I hate those with all my guts. Page "state" is
distributed in some intransparent way across client and server and
there is no way to refer to "something" via an URL.

Tastes can be so different :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: debian.org - broken Download link.

[Dmitry]

Hi, Brad.

The issue with a broken download link was in browser cache. It preserved link
to previous 12.1 version in html. After force update by F5 the issue was
resolved.

P.S. It is so uncommon when robust technologies with low resource consumption
are used, with SinglePageApplications no need to press F5, full data set
downloaded per each request.

Re: debian.org - broken Download link.

[Brad Rogers]

On Sun, 8 Oct 2023 21:20:04 +0700
Dmitry  wrote:

Hello Dmitry,

>https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.1.0-amd64-netinst.iso

Appears to have been updated/corrected.  Now works, d/l'ing Debian 12.2
after recent point release.

Transitional error, I suspect - Debian is a big web site with lots of
links to update.  I bet it's not done manually.  In any event, it takes
time to get everything updated correctly.

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
Never much liked playing there anyway
Banned From The Roxy - Crass


pgpY7Z_xjrgpN.pgp
Description: OpenPGP digital signature

debian.org - broken Download link.

[Dmitry]

Hi!

At the main page https://www.debian.org/, the Download link with Debian 
logo at the right part of the page is broken.

https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.1.0-amd64-netinst.iso

Leads to "Not Found". The requested URL was not found on this server.

Apache/2.4.55 (Unix) Server at cdimage.debian.org Port 443

Re: Debian 11.7 download - official repository

[Andrew M.A. Cater]

On Wed, Jun 28, 2023 at 08:14:52PM +, Edwar Saliba Junior wrote:
> Hello!
> I'm looking for Debian version 11.7 on the official website, but I didn't 
> find any link to download this one. 
> Could you tell me the correct URL to download please? 
> 

You could try:

https://cdimage.debian.org/cdimage/archive/11.7.0/amd64/iso-cd/ which should
work. The netinst is possibly all you need.

If you need the DVD, try the iso-dvd directory above 

> In advance, thank you very much!
> 
> Edwar Saliba Júnior

With every good wish, as ever,

Andy Cater

Re: Debian 11.7 download - official repository

[riveravaldez]

On 6/28/23, Edwar Saliba Junior  wrote:
> Hello!
> I'm looking for Debian version 11.7 on the official website, but I didn't
> find any link to download this one.
> Could you tell me the correct URL to download please?

Hi!, I hope this two, in order, could be what you're looking for:

Installing Debian 11.7
https://www.debian.org/releases/bullseye/debian-installer/

Debian Mirrors (worldwide)
https://www.debian.org/mirror/list

Kind regards!

Debian 11.7 download - official repository

[Edwar Saliba Junior]

Hello!
I'm looking for Debian version 11.7 on the official website, but I didn't find 
any link to download this one. 
Could you tell me the correct URL to download please? 

In advance, thank you very much!

Edwar Saliba Júnior

Re: Debian home page -> Download link broken:

[David Wright]

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:

[songbird]

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:

[songbird]

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:

[Stefan Monnier]

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

[The Wanderer]

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:

[David Wright]

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:

[David Wright]

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:

[David Wright]

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:

[David Wright]

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, no

Re: Debian home page -> Download link broken:

[Tixy]

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:

[songbird]

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:

[songbird]

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:

[The Wanderer]

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:

[Greg Wooledge]

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:

[David Wright]

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:

[Andy Smith]

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:

[David Wright]

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:

[Jeffrey Walton]

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:

[Greg Wooledge]

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:

[Jeffrey Walton]

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:

[Default User]

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:

[songbird]

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:

[The Wanderer]

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:

[Greg Wooledge]

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:

[The Wanderer]

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:

[The Wanderer]

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:

[David Wright]

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:

[songbird]

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:

[Greg Wooledge]

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:

[Greg Wooledge]

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

[The Wanderer]

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:

[Andrew M.A. Cater]

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:

[songbird]

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:

[Jeffrey Walton]

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:

[Tixy]

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:

[Jeffrey Walton]

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:

[Tim Woodall]

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:

[songbird]

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:

[Greg Wooledge]

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:

[Andrew M.A. Cater]

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:

[songbird]

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:

[songbird]

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:

[Peter Ehlert]

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:

[Andrew M.A. Cater]

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:

[David Christensen]

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

Re: How to download source package using only console?

[Alexander V. Makartsev]

On 15.05.2023 15:19, Vincent Lefevre wrote:

On 2023-05-15 10:25:45 +0500, Alexander V. Makartsev wrote:


I see. That explains why I can request source package
"golang-github-xenolf-lego/testing" directly and get the right one.
So, in my case, I won't be able to reliably get a source package(-s) from
"testing" if I don't add "deb" part of "testing" to "sources.list", which
could be a different can of worms...
Is this something for me to just be aware of and leave it as is now, or is
there more elegant solution?

Well, if you don't want the "deb" part, you need to provide the
name of the source package directly to "apt source". If you do that
frequently, you can write a script. There are 2 solutions:
* A remote request, e.g. with rmadison.
* Something based of "apt cache show". From that, you can get the
   source package, then call "apt source" with the source package.
   But note that this is only a heuristic; if the name of the source
   package has changed from stable to testing, this won't work.

Note that adding the "deb" part shouldn't be much an issue (except
noise, e.g. with "apt cache show", which would give output for both
stable and testing). If you want to make sure that a package from
testing won't be installed by mistake (by apt), I suppose that you
can use apt preferences with a negative priority for testing to
prevent such an installation:

Package: *
Pin: release a=testing
Pin-Priority: -1

(not tried). See the apt_preferences(5) man page for details.

It looks like adding the "deb" part with apt pinning is the best option.
Even with pinning in effect, packages from "testing" still could be 
installed, but only if they were manually requested.

Now the command "$ apt source lego/testing" is working properly.
Thanks for suggestions, Vincent.

--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: How to download source package using only console?

[Vincent Lefevre]

On 2023-05-15 10:25:45 +0500, Alexander V. Makartsev wrote:
> On 15.05.2023 05:43, Vincent Lefevre wrote:
> > But my point is that your database is obsolete, because if you ask
> > the version from testing, apt thinks that it is 3.2.0-3.1, while it
> > should be 4.9.1-1. You need to fix that.
> What is the best approach to fix that? [...]

That:

[...]
> I see. That explains why I can request source package
> "golang-github-xenolf-lego/testing" directly and get the right one.
> So, in my case, I won't be able to reliably get a source package(-s) from
> "testing" if I don't add "deb" part of "testing" to "sources.list", which
> could be a different can of worms...
> Is this something for me to just be aware of and leave it as is now, or is
> there more elegant solution?

Well, if you don't want the "deb" part, you need to provide the
name of the source package directly to "apt source". If you do that
frequently, you can write a script. There are 2 solutions:
* A remote request, e.g. with rmadison.
* Something based of "apt cache show". From that, you can get the
  source package, then call "apt source" with the source package.
  But note that this is only a heuristic; if the name of the source
  package has changed from stable to testing, this won't work.

Note that adding the "deb" part shouldn't be much an issue (except
noise, e.g. with "apt cache show", which would give output for both
stable and testing). If you want to make sure that a package from
testing won't be installed by mistake (by apt), I suppose that you
can use apt preferences with a negative priority for testing to
prevent such an installation:

Package: *
Pin: release a=testing
Pin-Priority: -1

(not tried). See the apt_preferences(5) man page for details.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: How to download source package using only console?

[Alexander V. Makartsev]

On 15.05.2023 05:43, Vincent Lefevre wrote:

On 2023-05-14 14:17:05 +0500, Alexander V. Makartsev wrote:

[...]
I think you haven't noticed that I requested for "4.9.1-1" version from
"testing" specifically,

You can't. You can either request some given version, e.g. 4.9.1-1
(but this will work only if it can be found from your local database),
or the version from some given distribution, e.g. "testing".

But my point is that your database is obsolete, because if you ask
the version from testing, apt thinks that it is 3.2.0-3.1, while it
should be 4.9.1-1. You need to fix that.
What is the best approach to fix that? Keep in mind, I only need a 
source package(-s) from "testing".

So, just to be safe, "deb" source for "testing" was commented out:

   $ cat /etc/apt/sources.list | grep -iE "testing"
   #deb https://deb.debian.org/debian/ testing main contrib non-free
   deb-src https://deb.debian.org/debian/ testing main contrib non-free



hence why the command was "$ apt source lego/testing" not just "$ apt source
lego".
There is no reason for building a backport package for "stable" using a
source package from "stable"...

I've changed all my repo mirrors to "deb.debian.org" suspecting the previous
mirror I used was somehow out-of-date. Why is my output differ from yours?

$ apt-show-versions -a lego
lego:amd64 3.2.0-3.1+b5 bullseye deb.debian.org
No proposed-updates version
No stable-updates version
No testing version
No unstable version
lego:amd64 not installed
lego:i386 3.2.0-3.1+b5 bullseye deb.debian.org
No proposed-updates version
No stable-updates version
No testing version
No unstable version
lego:i386 not installed

After changing your sources.list, you need an "apt update" again.
Of course, I always do "$ sudo apt update" after changing apt config 
files and before any package manipulation.



Yet "rmadison" reports there is a version "4.9.1-1" available in "testing":

$ rmadison lego
lego   | 0.3.1-5+b13   | oldstable  | amd64, arm64, armel,
armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
lego   | 3.2.0-3.1+b5  | stable | amd64, arm64, armel,
armhf, i386, mips64el, mipsel, ppc64el, s390x
lego   | 4.9.1-1   | testing    | amd64, arm64, armel,
armhf, i386, mips64el, mipsel, ppc64el, s390x
lego   | 4.9.1-1   | unstable   | amd64, arm64, armel,
armhf, i386, mips64el, mipsel, ppc64el, s390x

I suspect "apt-show-versions" output is inconsistent because I only request
"deb-src" from "testing" in "sources.list", as I've shown before.

Probably. "apt-show-versions" considers only the binary packages
(but "lego" is only a binary package).
I see. "rmadison" utility is checking out repos directly, where as 
"apt-show-versions" rely on local database information.



[...]

I did some additional research and I think I got it.
"lego" package is special because its source package is named differently:

Yes, as said by apt above:

   Picking 'golang-github-xenolf-lego' as source package instead of 'lego'

[...]

But why "apt" doesn't play along, since it knows the source package for
"lego" has different name, but ignores the "testing" part of the request?

$ apt source lego/testing
Reading package lists... Done
Picking 'golang-github-xenolf-lego' as source package instead of 'lego'
E: Can not find version '3.2.0-3.1' of package 'lego'
E: Unable to find a source package for golang-github-xenolf-lego

Looks like an "apt" bug to me.

Probably not. You are doing a request on a binary package (since
"lego" is not a source package). The translation from the binary
package to the source package depends on the particular version of
the binary package. So lego/testing will correspond to the binary
package from testing, which is 3.2.0-3.1+b5 in your case (because
of your obsolete database due to the missing "deb" for testing in
sources.list). Then apt translates this to the source package (of
the same version) golang-github-xenolf-lego 3.2.0-3.1, which is
unknown on your machine because the deb-src database is up-to-date
(contrary to the deb database). Something like that.

I see. That explains why I can request source package 
"golang-github-xenolf-lego/testing" directly and get the right one.
So, in my case, I won't be able to reliably get a source package(-s) 
from "testing" if I don't add "deb" part of "testing" to "sources.list", 
which could be a different can of worms...
Is this something for me to just be aware of and leave it as is now, or 
is there more elegant solution?


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: How to download source package using only console?

[Vincent Lefevre]

On 2023-05-14 14:17:05 +0500, Alexander V. Makartsev wrote:
> On 14.05.2023 10:06, Vincent Lefevre wrote:
> > On 2023-05-14 00:15:39 +0500, Alexander V. Makartsev wrote:
> > > Hello, fellow Debian users.
> > > 
> > > When I need to build a backport of a package, I sometimes find it 
> > > difficult
> > > to obtain actual source package(-s) from Debian repos using console.
> > > Following advice from a wiki page [1], after "apt update", doesn't do it:
> > > 
> > > $ apt source lego/testing
> > > Reading package lists... Done
> > > Picking 'golang-github-xenolf-lego' as source package instead of 
> > > 'lego'
> > > E: Can not find version '3.2.0-3.1' of package 'lego'
> > > E: Unable to find a source package for golang-github-xenolf-lego
> > zira:~> apt-show-versions -a lego
> > lego:amd64 3.2.0-3.1+b5 stableftp.debian.org
> > No stable-updates version
> > lego:amd64 4.9.1-1  testingftp.debian.org
> > lego:amd64 4.9.1-1  unstableftp.debian.org
> > No experimental version
> > lego:amd64 not installed
> > 
> > Indeed, 3.2.0-3.1 is no longer the testing version. Your database
> > seems to be out-of-date.
> > 
> I think you haven't noticed that I requested for "4.9.1-1" version from
> "testing" specifically,

You can't. You can either request some given version, e.g. 4.9.1-1
(but this will work only if it can be found from your local database),
or the version from some given distribution, e.g. "testing".

But my point is that your database is obsolete, because if you ask
the version from testing, apt thinks that it is 3.2.0-3.1, while it
should be 4.9.1-1. You need to fix that.

> hence why the command was "$ apt source lego/testing" not just "$ apt source
> lego".
> There is no reason for building a backport package for "stable" using a
> source package from "stable"...
> 
> I've changed all my repo mirrors to "deb.debian.org" suspecting the previous
> mirror I used was somehow out-of-date. Why is my output differ from yours?
> 
>$ apt-show-versions -a lego
>lego:amd64 3.2.0-3.1+b5 bullseye deb.debian.org
>No proposed-updates version
>No stable-updates version
>No testing version
>No unstable version
>lego:amd64 not installed
>lego:i386 3.2.0-3.1+b5 bullseye deb.debian.org
>No proposed-updates version
>No stable-updates version
>No testing version
>No unstable version
>lego:i386 not installed

After changing your sources.list, you need an "apt update" again.

> Yet "rmadison" reports there is a version "4.9.1-1" available in "testing":
> 
>$ rmadison lego
>lego   | 0.3.1-5+b13   | oldstable  | amd64, arm64, armel,
>armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
>lego   | 3.2.0-3.1+b5  | stable | amd64, arm64, armel,
>armhf, i386, mips64el, mipsel, ppc64el, s390x
>lego   | 4.9.1-1   | testing    | amd64, arm64, armel,
>armhf, i386, mips64el, mipsel, ppc64el, s390x
>lego   | 4.9.1-1   | unstable   | amd64, arm64, armel,
>armhf, i386, mips64el, mipsel, ppc64el, s390x
> 
> I suspect "apt-show-versions" output is inconsistent because I only request
> "deb-src" from "testing" in "sources.list", as I've shown before.

Probably. "apt-show-versions" considers only the binary packages
(but "lego" is only a binary package).

[...]
> I did some additional research and I think I got it.
> "lego" package is special because its source package is named differently:

Yes, as said by apt above:

  Picking 'golang-github-xenolf-lego' as source package instead of 'lego'

[...]
> But why "apt" doesn't play along, since it knows the source package for
> "lego" has different name, but ignores the "testing" part of the request?
> 
>$ apt source lego/testing
>Reading package lists... Done
>Picking 'golang-github-xenolf-lego' as source package instead of 'lego'
>E: Can not find version '3.2.0-3.1' of package 'lego'
>E: Unable to find a source package for golang-github-xenolf-lego
> 
> Looks like an "apt" bug to me.

Probably not. You are doing a request on a binary package (since
"lego" is not a source package). The translation from the binary
package to the source package depends on the particular version of
the binary package. So lego/testing will correspond to the binary
package from testing, which is 3.2.0-3.1+b5 in your case (because
of your obsolete database due to the missing "deb" for testing in
sources.list). Then apt translates this to the source package (of
the same version) golang-github-xenolf-lego 3.2.0-3.1, which is
unknown on your machine because the deb-src database is up-to-date
(contrary to the deb database). Something like that.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: How to download source package using only console?

[Greg Wooledge]

On Sun, May 14, 2023 at 02:17:05PM +0500, Alexander V. Makartsev wrote:
> hence why the command was "$ apt source lego/testing" not just "$ apt source
> lego".
> There is no reason for building a backport package for "stable" using a
> source package from "stable"...

If you're trying to build a backport, you add "deb-src" lines for
testing, then "apt-get update", and then simply use
"apt-get source pkgname".  Or their "apt" equivalents, I guess.

Re: How to download source package using only console?

[Alexander V. Makartsev]

On 14.05.2023 10:06, Vincent Lefevre wrote:

On 2023-05-14 00:15:39 +0500, Alexander V. Makartsev wrote:

Hello, fellow Debian users.

When I need to build a backport of a package, I sometimes find it difficult
to obtain actual source package(-s) from Debian repos using console.
Following advice from a wiki page [1], after "apt update", doesn't do it:

$ apt source lego/testing
Reading package lists... Done
Picking 'golang-github-xenolf-lego' as source package instead of 'lego'
E: Can not find version '3.2.0-3.1' of package 'lego'
E: Unable to find a source package for golang-github-xenolf-lego

zira:~> apt-show-versions -a lego
lego:amd64 3.2.0-3.1+b5 stableftp.debian.org
No stable-updates version
lego:amd64 4.9.1-1  testingftp.debian.org
lego:amd64 4.9.1-1  unstableftp.debian.org
No experimental version
lego:amd64 not installed

Indeed, 3.2.0-3.1 is no longer the testing version. Your database
seems to be out-of-date.

I think you haven't noticed that I requested for "4.9.1-1" version from 
"testing" specifically,
hence why the command was "$ apt source lego/testing" not just "$ apt 
source lego".
There is no reason for building a backport package for "stable" using a 
source package from "stable"...


I've changed all my repo mirrors to "deb.debian.org" suspecting the 
previous mirror I used was somehow out-of-date. Why is my output differ 
from yours?


   $ apt-show-versions -a lego
   lego:amd64 3.2.0-3.1+b5 bullseye deb.debian.org
   No proposed-updates version
   No stable-updates version
   No testing version
   No unstable version
   lego:amd64 not installed
   lego:i386 3.2.0-3.1+b5 bullseye deb.debian.org
   No proposed-updates version
   No stable-updates version
   No testing version
   No unstable version
   lego:i386 not installed

Yet "rmadison" reports there is a version "4.9.1-1" available in "testing":

   $ rmadison lego
   lego   | 0.3.1-5+b13   | oldstable  | amd64, arm64, armel,
   armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
   lego   | 3.2.0-3.1+b5  | stable | amd64, arm64, armel,
   armhf, i386, mips64el, mipsel, ppc64el, s390x
   lego   | 4.9.1-1   | testing    | amd64, arm64, armel,
   armhf, i386, mips64el, mipsel, ppc64el, s390x
   lego   | 4.9.1-1   | unstable   | amd64, arm64, armel,
   armhf, i386, mips64el, mipsel, ppc64el, s390x

I suspect "apt-show-versions" output is inconsistent because I only 
request "deb-src" from "testing" in "sources.list", as I've shown before.


Here is another example package that works as expected:

   $ rmadison roundcube
   roundcube  | 1.3.17+dfsg.1-1~deb10u2 | oldstable    |
   source, all
   roundcube  | 1.4.13+dfsg.1-1~deb11u1~bpo10+1 | buster-backports |
   source, all
   roundcube  | 1.4.13+dfsg.1-1~deb11u1 | stable   |
   source, all
   roundcube  | 1.6.1+dfsg-1    | testing  |
   source, all
   roundcube  | 1.6.1+dfsg-1    | unstable |
   source, all

   $ apt-show-versions -a roundcube
   roundcube:all 1.4.13+dfsg.1-1~deb11u1 bullseye  deb.debian.org
   roundcube:all 1.4.13+dfsg.1-1~deb11u1 bullseye-security deb.debian.org
   No proposed-updates version
   No stable-updates version
   No testing version
   No unstable version
   roundcube:all not installed

   $ apt source roundcube/testing
   Reading package lists... Done
   Selected version '1.6.1+dfsg-1' (testing) for roundcube
   ...


I did some additional research and I think I got it.
"lego" package is special because its source package is named differently:

   $ rmadison golang-github-xenolf-lego
   golang-github-xenolf-lego | 0.3.1-5   | oldstable  | source
   golang-github-xenolf-lego | 3.2.0-3.1 | stable | source
   golang-github-xenolf-lego | 4.9.1-1   | testing    | source
   golang-github-xenolf-lego | 4.9.1-1   | unstable   | source
   golang-github-xenolf-lego | 4.9.1-1   | unstable-debug | source

   $ apt source golang-github-xenolf-lego/testing
   Reading package lists... Done
   Selected version '4.9.1-1' (testing) for golang-github-xenolf-lego
   ...

But why "apt" doesn't play along, since it knows the source package for 
"lego" has different name, but ignores the "testing" part of the request?


   $ apt source lego/testing
   Reading package lists... Done
   Picking 'golang-github-xenolf-lego' as source package instead of 'lego'
   E: Can not find version '3.2.0-3.1' of package 'lego'
   E: Unable to find a source package for golang-github-xenolf-lego


Looks like an "apt" bug to me.


--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: How to download source package using only console?

[Vincent Lefevre]

On 2023-05-14 00:15:39 +0500, Alexander V. Makartsev wrote:
> Hello, fellow Debian users.
> 
> When I need to build a backport of a package, I sometimes find it difficult
> to obtain actual source package(-s) from Debian repos using console.
> Following advice from a wiki page [1], after "apt update", doesn't do it:
> 
>$ apt source lego/testing
>Reading package lists... Done
>Picking 'golang-github-xenolf-lego' as source package instead of 'lego'
>E: Can not find version '3.2.0-3.1' of package 'lego'
>E: Unable to find a source package for golang-github-xenolf-lego

zira:~> apt-show-versions -a lego
lego:amd64 3.2.0-3.1+b5 stable   ftp.debian.org
No stable-updates version
lego:amd64 4.9.1-1  testing  ftp.debian.org
lego:amd64 4.9.1-1  unstable ftp.debian.org
No experimental version
lego:amd64 not installed

Indeed, 3.2.0-3.1 is no longer the testing version. Your database
seems to be out-of-date.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

How to download source package using only console?

[Alexander V. Makartsev]

Hello, fellow Debian users.

When I need to build a backport of a package, I sometimes find it 
difficult to obtain actual source package(-s) from Debian repos using 
console.

Following advice from a wiki page [1], after "apt update", doesn't do it:

   $ apt source lego/testing
   Reading package lists... Done
   Picking 'golang-github-xenolf-lego' as source package instead of 'lego'
   E: Can not find version '3.2.0-3.1' of package 'lego'
   E: Unable to find a source package for golang-github-xenolf-lego

Any other seemingly intended ways also fail in a similar fashion:

   $ dget lego=4.9.1-1
   dget: no hostnames in apt-cache policy lego for version 4.9.1-1 found

   $ apt-get source lego -t testing
   Reading package lists... Done
   E: The value 'testing' is invalid for APT::Default-Release as such a
   release is not available in the sources
   E: Unable to find a source package for

Trying to do the same for another package seems to work:

   $ apt source ipcalc/testing
   Reading package lists... Done
   Selected version '0.42-2' (testing) for ipcalc
   Need to get 33,7 kB of source archives.
   Get:1 https://mirror.yandex.ru/debian testing/main ipcalc 0.42-2
   (dsc) [1 692 B]
   Get:2 https://mirror.yandex.ru/debian testing/main ipcalc 0.42-2
   (tar) [25,9 kB]
   Get:3 https://mirror.yandex.ru/debian testing/main ipcalc 0.42-2
   (diff) [6 144 B]
   Fetched 33,7 kB in 1s (52,5 kB/s)
   dpkg-source: info: extracting ipcalc in ipcalc-0.42
   dpkg-source: info: unpacking ipcalc_0.42.orig.tar.gz
   dpkg-source: info: unpacking ipcalc_0.42-2.debian.tar.xz
   dpkg-source: info: using patch list from debian/patches/series
   dpkg-source: info: applying 01-paths.patch


So why those fail for a "lego" package and is there a way to solve this 
once and for all?
I know I can go to a packages website [2] and manually download ".dsc" 
file and feed it to "dget" utility, or download source files directly 
from said website, but there has to be a better way.


Some useful info:

   $ cat /etc/apt/sources.list | grep -iE "testing"
   #deb https://mirror.yandex.ru/debian/ testing main contrib non-free
   deb-src https://mirror.yandex.ru/debian/ testing main contrib non-free

   $ rmadison lego
   lego   | 0.3.1-5+b13   | oldstable  | amd64, arm64, armel,
   armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
   lego   | 3.2.0-3.1+b5  | stable | amd64, arm64, armel,
   armhf, i386, mips64el, mipsel, ppc64el, s390x
   lego   | 4.9.1-1   | testing    | amd64, arm64, armel,
   armhf, i386, mips64el, mipsel, ppc64el, s390x
   lego   | 4.9.1-1   | unstable   | amd64, arm64, armel,
   armhf, i386, mips64el, mipsel, ppc64el, s390x

   $ uname -a
   Linux host0 5.10.0-22-amd64 #1 SMP Debian 5.10.178-3 (2023-04-22)
   x86_64 GNU/Linux



[1] https://wiki.debian.org/SimpleBackportCreation
[2] https://packages.debian.org/bookworm/lego

--
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄

Re: Download links do not work

[Huihang Yan]

On Mon, 12 Sep 2022 01:59:25 +0200
Kevin Price  wrote:

> Do you happen to be in a country whose government restricts Internet access?

Probably not a government restriction. Debian.org is pretty fast to reach even 
in Chinese mainland here.


On Sun, 11 Sep 2022 19:09:22 -0400
Tom Zarcone  wrote:

> Debian.org/download does not work. Not a single link works. All it says is 
> “unable to connect”. I get this issue on every browser I use

Do you have http testing tools like curl by your hands? It would be useful to 
take a look at what they say.

Is Debian.org/download ok on your environment? It's weird if 
Debian.org/download works but the links within do not work.


-- 
Huihang Yan 

Re: Download links do not work

[Luna Jernberg]

Works for me too here in Sweden with Telia as an ISP

On Mon, Sep 12, 2022 at 10:42 AM Corentin Bardet 
wrote:

> Hi,
>
> > Debian.org/download does not work. Not a single link works. All it says
> is “unable to connect”. I get this issue on every browser I use
>
> Debian download page does work here from France.
>
> Kevin Price , le 12 sept 2022 :
> > Your IPv4 address 17.58.6.50 is allocated to Apple Inc.
>
> I think that's because he is using iCloud Mail, which masks the real
> user's IP address in headers.
>
> Cheers,
>
> --
> Corentin Bardet
> https://corentin.fastmail.com
>
>

Re: Download links do not work

[Corentin Bardet]

Hi,

> Debian.org/download does not work. Not a single link works. All it says is 
> “unable to connect”. I get this issue on every browser I use

Debian download page does work here from France.

Kevin Price , le 12 sept 2022 :
> Your IPv4 address 17.58.6.50 is allocated to Apple Inc.

I think that's because he is using iCloud Mail, which masks the real user's IP 
address in headers.

Cheers,

-- 
Corentin Bardet
https://corentin.fastmail.com

Re: Download links do not work

[Kevin Price]

Am 12.09.22 um 01:09 schrieb Tom Zarcone:
> Debian.org/download does not work. Not a single link works.

So double-check https://www.debian.org/download again.

All it says is “unable to connect”. I get this issue on every browser I use

Do you happen to be in a country whose government restricts Internet access?

Your IPv4 address 17.58.6.50 is allocated to Apple Inc.
-- 
Kevin

Re: Download links do not work

[The Wanderer]

On 2022-09-11 at 19:09, Tom Zarcone wrote:

> Debian.org/download does not work. Not a single link works. All it
> says is “unable to connect”. I get this issue on every browser I use

Works flawlessly for me, with all of Firefox, w3m, and wget.
(https://debian.org/download redirects to
https://www.debian.org/download , and the HTTP version redirects to that
same HTTP destination, but that shouldn't affect the result.)

What IP address are you getting for the site? I get:

$ host debian.org
debian.org has address 128.31.0.62
debian.org has address 130.89.148.77
debian.org has address 149.20.4.15
debian.org has IPv6 address 2603:400a::bb8::801f:3e
debian.org has IPv6 address 2001:67c:2564:a119::77
debian.org has IPv6 address 2001:4f8:1:c::15
debian.org mail is handled by 0 mailly.debian.org.
debian.org mail is handled by 0 muffat.debian.org.
debian.org mail is handled by 0 mitropoulos.debian.org.

$ host www.debian.org
www.debian.org has address 149.20.4.15
www.debian.org has address 128.31.0.62
www.debian.org has IPv6 address 2603:400a::bb8::801f:3e
www.debian.org has IPv6 address 2001:4f8:1:c::15

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

Download links do not work

[Tom Zarcone]

Debian.org/download does not work. Not a single link works. All it says is 
“unable to connect”. I get this issue on every browser I use

Re: Firefox PDF download - strange behaviour.

[Andrei POPESCU]

On Ma, 18 ian 22, 11:35:04, The Wanderer wrote:
> 
> Looking at that example, I note that it starts with the variable name
> "currentDirHandle". I think it's intended, although not explicitly
> stated, that the directory path specified in that function call is
> *relative*; that would let the API be used to create subdirectory trees
> underneath the user-chosen directory, but not outside of there.
> 
> So this could potentially be dangerous if the user chooses a directory
> location that's high enough in the directory tree to have important
> files already underneath it, but not if the user chooses e.g. a
> dedicated Downloads directory.
> 
> I can still envision scenarios in which this could be dangerous, but
> unless there are ways to get access to a file-handle variable that don't
> rely on something directly user-interactive (the ones described in that
> page are file-picker dialogs and "drag and drop a file into (a specific
> area of?) the browser window"), I don't think it can plausibly do so in
> a way that's invisible to the user.

This reminds me of 

https://arstechnica.com/gadgets/2021/07/separate-eop-flaws-let-hackers-gain-full-control-of-windows-and-linux-systems/

(the second part, with the Linux vulnerability)

Letting some random site have access to local storage seems like a Very 
Bad Idea.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Firefox PDF download - strange behaviour.

[Curt]

On 2022-01-18, Jeremy Nicoll  wrote:
>
> The problem is that a user would normally only expect a browser to
> save a file to the file-system in two cases:
>
> (a) when the user has explcicitly chosen to download something, and 
>then chooses where to put it
>
> (b) when the browser is cacheing content, or manipulating its own
>   config files
>

And (c) as in cookies, of course.

Re: Firefox PDF download - strange behaviour.

[Vincent Lefevre]

On 2022-01-18 11:23:14 -0500, songbird wrote:
> Jeremy Nicoll wrote:
> > songbird wrote:
> ...
> >> but what i do is set where files are saved in a
> >> specific directory and leave it at that
> >
> > That works fine while you can be sure that a browser is only 
> > saving downloaded files.  What about when if can do anything
> > it likes to any file/folder?
> 
>   i'm trusting the developers of the browser just like
> everyone else who uses it.

The main issue is security bugs.

>   javascript has always been an issue, i don't see that
> changing.  if you are paranoid about that kind of access
> then the OS does let you set things up to be doubly sure
> (different users and groups) and there are even security
> protocols that go even further.  i don't bother with 
> them.

I systematically run firefox in firejail.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Firefox PDF download - strange behaviour.

[Jeremy Nicoll]

On Tue, 18 Jan 2022, at 16:35, The Wanderer wrote:

> So this could potentially be dangerous if the user chooses a directory
> location that's high enough in the directory tree to have important
> files already underneath it, but not if the user chooses e.g. a
> dedicated Downloads directory.

I'd expect malware using this mechanism to put forward a "plausible"
reason why a naive user should select an unsafe directory, rather than
a downloads one.


>> I think I also read that once the code has a handle to a directory it
>> can scan sub-directories as well.
>
> Yes, that appears to be correct.

And that opens up the scourge of malware that correctly identifies what
software one has installed, and/or aspects of its configuration, just based
on what files/folders exist.

-- 
Jeremy Nicoll - my opinions are my own.

Re: Firefox PDF download - strange behaviour.

[David Wright]

On Tue 18 Jan 2022 at 14:46:48 (+), Jeremy Nicoll wrote:
> On Tue, 18 Jan 2022, at 04:51, songbird wrote:
> > Jeremy Nicoll wrote:
> >> On Mon, 17 Jan 2022, at 05:19, songbird wrote:
> >>
> >>>   you are right, but i just wanted to say that for some sites
> >>> the behavior is to generate a unique file name if they find
> >>> one that already exists with the same name and for other sites
> >>> it is not.  i think this is dependent upon the website designers
> >>> and not firefox.
> >>
> >> Are you saying that code on a webpage can interrogate my 
> >> file system to see whether certain files exist?  I don't like the
> >> sound of that.
> >
> >   you are running the webpage on your browser so it is your
> > own computer and your own program that is doing the accessing
> > just like any other program you run.
> 
> The problem is that a user would normally only expect a browser to
> save a file to the file-system in two cases:
> 
> (a) when the user has explcicitly chosen to download something, and 
>then chooses where to put it
> 
> (b) when the browser is cacheing content, or manipulating its own
>   config files
> 
> In both those cases it's code written by the browser's developers 
> that's doing the writing.
> 
> The new situation will allow any JS written by any page developer to
> access my files.  I am unconvinced that this will never lead to malware
> doing things to files/folders on my system without my knowledge.
> 
> It's a BIG change to users' expectations of what a browser can do.
> 
> Users with no technical knowledge could get bitten by this.
> 
> > what controls you wish
> > to put on the access to your file system and how you do that
> > is up to you and your own desires and capabilities.
> 
> I don't think it should be up to me.  I'd prefer to prohibit any JS 
> in a browser from doing that.
> 
> > but what i do is set where files are saved in a
> > specific directory and leave it at that
> 
> That works fine while you can be sure that a browser is only 
> saving downloaded files.  What about when if can do anything
> it likes to any file/folder?

Songbird went on to say:

> > if you are running a linux 
> > system then you have the capability of using different users
> > and groups to control file and directory access.  so you only
> > browse using one user and then set up a directory for that 
> > user to save files to and then put stuff there.  then you can
> > make that directory read only to a group and set up another
> > user to go look at the files saved there.  or something like
> > that...

… which is what I do: user "flash" browses all except a few
trusted sites. I can read flash's ~/PDF/, downloads and browser
cache, and after a minute, I own the first two categories,
thanks to cron.

Cheers,
David.

Re: Firefox PDF download - strange behaviour.

[songbird]

Jeremy Nicoll wrote:
> songbird wrote:
...
>> but what i do is set where files are saved in a
>> specific directory and leave it at that
>
> That works fine while you can be sure that a browser is only 
> saving downloaded files.  What about when if can do anything
> it likes to any file/folder?

  i'm trusting the developers of the browser just like
everyone else who uses it.

  javascript has always been an issue, i don't see that
changing.  if you are paranoid about that kind of access
then the OS does let you set things up to be doubly sure
(different users and groups) and there are even security
protocols that go even further.  i don't bother with 
them.

  Debian itself is also another web of trust that us 
users rely upon.  i consider it similar enough to what 
happens at firefox devs that i don't really worry about
it.


  songbird

Re: Firefox PDF download - strange behaviour.

[The Wanderer]

On 2022-01-17 at 15:55, Jeremy Nicoll wrote:

> On Mon, 17 Jan 2022, at 05:19, songbird wrote:
> 
>> you are right, but i just wanted to say that for some sites the
>> behavior is to generate a unique file name if they find one that
>> already exists with the same name and for other sites it is not.  i
>> think this is dependent upon the website designers and not
>> firefox.
> 
> Are you saying that code on a webpage can interrogate my file system
> to see whether certain files exist?  I don't like the sound of that.
> 
> A quick google found me: 
> https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API
>
>  which seems to describe ways that Javascript can read and write my
> files, and scan my directories (or will be able to when this API is
> implemented).
> 
> There's not enough information, in my view, explaining how a browser
> user can prevent that.  It says - if I'm reading it right - that it's
> secure because users are offered file pickers etc when a file is to
> be opened or file-save dialogs when something is to be created.

The key is probably that - if my reading is correct - then what the
handles acquired by presenting such a file picker dialog do is to grant
access to the specified directory *and everything underneath it*, but
not to anything *outside* of that.

> But one of the code examples describes getting a handle to a
> directory and says if the directory doesn't exist yet it will be
> created.  That suggests that rogue code could create folders on my
> system.

Looking at that example, I note that it starts with the variable name
"currentDirHandle". I think it's intended, although not explicitly
stated, that the directory path specified in that function call is
*relative*; that would let the API be used to create subdirectory trees
underneath the user-chosen directory, but not outside of there.

So this could potentially be dangerous if the user chooses a directory
location that's high enough in the directory tree to have important
files already underneath it, but not if the user chooses e.g. a
dedicated Downloads directory.

I can still envision scenarios in which this could be dangerous, but
unless there are ways to get access to a file-handle variable that don't
rely on something directly user-interactive (the ones described in that
page are file-picker dialogs and "drag and drop a file into (a specific
area of?) the browser window"), I don't think it can plausibly do so in
a way that's invisible to the user.

> I think I also read that once the code has a handle to a directory it
> can scan sub-directories as well.

Yes, that appears to be correct.

-- 
   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: Firefox PDF download - strange behaviour.

[Jeremy Nicoll]

On Tue, 18 Jan 2022, at 04:51, songbird wrote:
> Jeremy Nicoll wrote:
>> On Mon, 17 Jan 2022, at 05:19, songbird wrote:
>>
>>>   you are right, but i just wanted to say that for some sites
>>> the behavior is to generate a unique file name if they find
>>> one that already exists with the same name and for other sites
>>> it is not.  i think this is dependent upon the website designers
>>> and not firefox.
>>
>> Are you saying that code on a webpage can interrogate my 
>> file system to see whether certain files exist?  I don't like the
>> sound of that.
>
>   you are running the webpage on your browser so it is your
> own computer and your own program that is doing the accessing
> just like any other program you run.

The problem is that a user would normally only expect a browser to
save a file to the file-system in two cases:

(a) when the user has explcicitly chosen to download something, and 
   then chooses where to put it

(b) when the browser is cacheing content, or manipulating its own
  config files

In both those cases it's code written by the browser's developers 
that's doing the writing.

The new situation will allow any JS written by any page developer to
access my files.  I am unconvinced that this will never lead to malware
doing things to files/folders on my system without my knowledge.

It's a BIG change to users' expectations of what a browser can do.

Users with no technical knowledge could get bitten by this.


> what controls you wish
> to put on the access to your file system and how you do that
> is up to you and your own desires and capabilities.

I don't think it should be up to me.  I'd prefer to prohibit any JS 
in a browser from doing that.


> but what i do is set where files are saved in a
> specific directory and leave it at that

That works fine while you can be sure that a browser is only 
saving downloaded files.  What about when if can do anything
it likes to any file/folder?

-- 
Jeremy Nicoll - my opinions are my own.

Re: Firefox PDF download - strange behaviour.

[songbird]

Jeremy Nicoll wrote:
> On Mon, 17 Jan 2022, at 05:19, songbird wrote:
>
>>   you are right, but i just wanted to say that for some sites
>> the behavior is to generate a unique file name if they find
>> one that already exists with the same name and for other sites
>> it is not.  i think this is dependent upon the website designers
>> and not firefox.
>
> Are you saying that code on a webpage can interrogate my 
> file system to see whether certain files exist?  I don't like the
> sound of that.

  you are running the webpage on your browser so it is your
own computer and your own program that is doing the accessing
just like any other program you run.  what controls you wish
to put on the access to your file system and how you do that
is up to you and your own desires and capabilities.  for some
security systems they allow file access and directory access
controls, but what i do is set where files are saved in a
specific directory and leave it at that.  and, yes, more can
be done but i don't care to do it.  same as i could use a
very paranoid and text only based browser like lynx and
never run javascript or anything else that does things 
automatically, but then i'd probably not really enjoy doing
much on-line.  i pick my battles in other ways (like running
linux and debian) and i don't open or save files 
automatically.  those are good enough for me.  :)


> A quick google found me: 
> https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API
>
> which seems to describe ways that Javascript can read and write 
> my files, and scan my directories (or will be able to when this
> API is implemented). 
>
> There's not enough information, in my view, explaining how a
> browser user can prevent that.  It says - if I'm reading it right -
> that it's secure because users are offered file pickers etc when
> a file is to be opened or file-save dialogs when something is to 
> be created.
>
> But one of the code examples describes getting a handle to a 
> directory and says if the directory doesn't exist yet it will be 
> created.  That suggests that rogue code could create folders
> on my system.
>
> I think I also read that once the code has a handle to a directory
> it can scan sub-directories as well.

  you could break the issue down into two things quite easily
and not get super complicated.  if you are running a linux 
system then you have the capability of using different users
and groups to control file and directory access.  so you only
browse using one user and then set up a directory for that 
user to save files to and then put stuff there.  then you can
make that directory read only to a group and set up another
user to go look at the files saved there.  or something like
that...


  songbird

Re: Firefox PDF download - strange behaviour.

[Jeremy Nicoll]

On Mon, 17 Jan 2022, at 05:19, songbird wrote:

>   you are right, but i just wanted to say that for some sites
> the behavior is to generate a unique file name if they find
> one that already exists with the same name and for other sites
> it is not.  i think this is dependent upon the website designers
> and not firefox.

Are you saying that code on a webpage can interrogate my 
file system to see whether certain files exist?  I don't like the
sound of that.

A quick google found me: 
https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API

which seems to describe ways that Javascript can read and write 
my files, and scan my directories (or will be able to when this
API is implemented). 

There's not enough information, in my view, explaining how a
browser user can prevent that.  It says - if I'm reading it right -
that it's secure because users are offered file pickers etc when
a file is to be opened or file-save dialogs when something is to 
be created.

But one of the code examples describes getting a handle to a 
directory and says if the directory doesn't exist yet it will be 
created.  That suggests that rogue code could create folders
on my system.

I think I also read that once the code has a handle to a directory
it can scan sub-directories as well.

-- 
Jeremy Nicoll - my opinions are my own.

Re: Firefox PDF download - strange behaviour.

[songbird]

Kamil Jońca wrote:
> songbird  writes:
>
>> Kamil Jońca wrote:
>>>
>>> Recently I recognized strange behaviour during pdf download with
>>> firefox.
>>> 1. When I enter target name with colon - this colon is replaced with
>>> space.
>>
>>   no idea because i usually replace any strange characters 
>> in file names with underlines before saving them to disk.  i
>> do not automatically save or open pdfs from firefox or any
>> other utility.
>
>>
>>
>>> 2. When target file exists -  firefox does not ask to replace it but
>>> create file with number.
>>> (for example: I have already file.pdf, then firefox creates file(1).pdf)
>>> What am I missing?
>>
>>   this is normal behavior for as long as i can remember using
>> firefox.
>
> This is simply not true. Because if I try to save *.jpeg, or *.jpg - i
> got question if I want to overwrite file, which already exists.
> And I am sure that some time ago pdf-s was also treated this way.
> KJ

  you are right, but i just wanted to say that for some sites
the behavior is to generate a unique file name if they find
one that already exists with the same name and for other sites
it is not.  i think this is dependent upon the website designers
and not firefox.

  this has been the same for some sites as long as i've used
firefox.  i don't do a ton of file loading or pdf stuff but it
seems to be mostly financial ones that give me access to my 
statements that have this feature.  i still don't like that 
they do automatic filenames as i end up redoing them to fit my
own current naming scheme instead so they could call it file a.pdf
and i'd be fine with that.

  perhaps there is an addon or plugin that will do what you'd 
like.


  songbird

Re: Firefox PDF download - strange behaviour.

[Kamil Jońca]

Greg Wooledge  writes:

> On Sun, Jan 16, 2022 at 05:47:13PM +0100, Kamil Jońca wrote:
>> Recently I recognized strange behaviour during pdf download with
>> firefox.
>> 1. When I enter target name with colon - this colon is replaced with
>> space.
>
> Probably because colons are not allowed in filenames on Microsoft
> platforms.  I can easily see Firefox applying the same sanitization
> code on all platforms.

This is also my guess :). 
But another question is: how can I turn it off and make firefox save
filenames requested by me and not filtered, and not to create files with
numbers.
KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/

Re: Firefox PDF download - strange behaviour.

[Greg Wooledge]

On Sun, Jan 16, 2022 at 05:47:13PM +0100, Kamil Jońca wrote:
> Recently I recognized strange behaviour during pdf download with
> firefox.
> 1. When I enter target name with colon - this colon is replaced with
> space.

Probably because colons are not allowed in filenames on Microsoft
platforms.  I can easily see Firefox applying the same sanitization
code on all platforms.

Re: Firefox PDF download - strange behaviour.

[Kamil Jońca]

songbird  writes:

> Kamil Jońca wrote:
>>
>> Recently I recognized strange behaviour during pdf download with
>> firefox.
>> 1. When I enter target name with colon - this colon is replaced with
>> space.
>
>   no idea because i usually replace any strange characters 
> in file names with underlines before saving them to disk.  i
> do not automatically save or open pdfs from firefox or any
> other utility.

>
>
>> 2. When target file exists -  firefox does not ask to replace it but
>> create file with number.
>> (for example: I have already file.pdf, then firefox creates file(1).pdf)
>> What am I missing?
>
>   this is normal behavior for as long as i can remember using
> firefox.

This is simply not true. Because if I try to save *.jpeg, or *.jpg - i
got question if I want to overwrite file, which already exists.
And I am sure that some time ago pdf-s was also treated this way.
KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/

Re: Firefox PDF download - strange behaviour.

[songbird]

Kamil Jońca wrote:
>
> Recently I recognized strange behaviour during pdf download with
> firefox.
> 1. When I enter target name with colon - this colon is replaced with
> space.

  no idea because i usually replace any strange characters 
in file names with underlines before saving them to disk.  i
do not automatically save or open pdfs from firefox or any
other utility.


> 2. When target file exists -  firefox does not ask to replace it but
> create file with number.
> (for example: I have already file.pdf, then firefox creates file(1).pdf)
> What am I missing?

  this is normal behavior for as long as i can remember using
firefox.


> User AgentMozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 
> Firefox/96.0
> OSLinux 5.15.0-2-amd64 #1 SMP Debian 5.15.5-2 (2021-12-18)
> KJ


  songbird

Firefox PDF download - strange behaviour.

[Kamil Jońca]

Recently I recognized strange behaviour during pdf download with
firefox.
1. When I enter target name with colon - this colon is replaced with
space.
2. When target file exists -  firefox does not ask to replace it but
create file with number.
(for example: I have already file.pdf, then firefox creates file(1).pdf)
What am I missing?

User Agent  Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101 
Firefox/96.0
OS  Linux 5.15.0-2-amd64 #1 SMP Debian 5.15.5-2 (2021-12-18)
KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/

Re: why i can't download debian-live-10.11.0-i386-gnome.iso?

[lou]

Thank Keith and David!

Sorry,  i've not been able to receive replies from both of you on time 
because of mail service problem

Re: why i can't download debian-live-10.11.0-i386-gnome.iso?

[lou]

Thank Dan and Stefan!

file system is ext3, it has no 2G limit IMO

i've installed curl, it doesn't have such bug

Re: why i can't download debian-live-10.11.0-i386-gnome.iso?

[David Wright]

On Wed 01 Dec 2021 at 20:26:19 (-0500), lou wrote:
> http://ftp.sunet.se/cdimage/archive/10.11.0-live/i386/iso-hybrid/
> 
> i use wget to download, length is 2G though ftp.sunet.se shows 2.6G
> 
> ftp.funet.fi has same problem, live gnome image is more than 2G, i
> can't get it with wget
> 
> http://ftp.funet.fi/pub/Linux/mirrors/debian-cdimage/current-live/i386/iso-hybrid/

Are you downloading to a FAT16 filesystem, maximum file size 2GB.

Cheers,
David.

Re: why i can't download debian-live-10.11.0-i386-gnome.iso?

[Dan Ritter]

lou wrote: 
> http://ftp.sunet.se/cdimage/archive/10.11.0-live/i386/iso-hybrid/
> 
> i use wget to download, length is 2G though ftp.sunet.se shows 2.6G
> 
> ftp.funet.fi has same problem, live gnome image is more than 2G, i can't get
> it with wget
> 
> http://ftp.funet.fi/pub/Linux/mirrors/debian-cdimage/current-live/i386/iso-hybrid/

What filesystem are you downloading this image to? Is it a
filesystem with a maximum file size of 2GB?

-dsr-

Re: why i can't download debian-live-10.11.0-i386-gnome.iso?

[Keith Bainbridge]

On 2/12/21 12:26, lou wrote:

http://ftp.sunet.se/cdimage/archive/10.11.0-live/i386/iso-hybrid/

i use wget to download, length is 2G though ftp.sunet.se shows 2.6G

ftp.funet.fi has same problem, live gnome image is more than 2G, i can't 
get it with wget


http://ftp.funet.fi/pub/Linux/mirrors/debian-cdimage/current-live/i386/iso-hybrid/



Good afternoon lou

I often download files larger than 2G with wget

Have you tried the debian download site?


All the best

Keith Bainbridge

kkeithrbaugro...@gmail.com

why i can't download debian-live-10.11.0-i386-gnome.iso?

[lou]

http://ftp.sunet.se/cdimage/archive/10.11.0-live/i386/iso-hybrid/

i use wget to download, length is 2G though ftp.sunet.se shows 2.6G

ftp.funet.fi has same problem, live gnome image is more than 2G, i can't 
get it with wget


http://ftp.funet.fi/pub/Linux/mirrors/debian-cdimage/current-live/i386/iso-hybrid/

Re: Ot: 6 or 7 nights to download a CD

[Thomas Schmitt]

Hi,

Russell L. Harris wrote:
> hopefully someone mentioned jigo -- the jigsaw downloader.

Well, if you mean Jigdo, then i can report that it is still alive:
  https://www.debian.org/CD/jigdo-cd/
It recently got a protocol upgrade to version 2, with SHA256 instead
of old MD5.

For most Debian ISO images it is the only download opportunity.
Be it 18 DVD sized images
  https://cdimage.debian.org/debian-cd/current/amd64/jigdo-dvd/
or 4 BD sized images (25 GB)
  https://cdimage.debian.org/debian-cd/current/amd64/jigdo-bd/
or 2 BD DL sized images (50 GB)
  https://cdimage.debian.org/debian-cd/current/amd64/jigdo-dlbd/

Only the CD edition ended after Jessie with 85 CD sized images.


Have a nice day :)

Thomas

Re: Ot: 6 or 7 nights to download a CD

[Russell L. Harris]

On Fri, Oct 08, 2021 at 11:23:46AM -0400, Cindy Sue Causey wrote:

There was one download manager that sold itself because it focused on
being able to continue on without having to restart the download.
Whatever that one in-browser manager was, that was my HERO for a
number of years... until I discovered wget. Once in a while there will
be a "gatekeeper" (cookie reliant) instance where wget also doesn't
work still and though.


I have not followed this thread, but hopefully someone mentioned jigo
-- the jigsaw downloader.

RLH


--
How should one chase a thousand, and two put ten thousand to flight,
except their Rock had sold them, and the Lord had shut them up?
- Deuteronomy 32:30

Re: Ot: 6 or 7 nights to download a CD (was: Re: RJ-11 phone line)

[Cindy Sue Causey]

On 10/8/21, rhkra...@gmail.com  wrote:
> On Thursday, October 07, 2021 07:43:02 AM Dan Ritter wrote:
>> Note that a minimal Debian install is around 500 MB, which would
>> take around 24 hours of a perfect 56K modem connection.
>
> I can remember when I got a fast modem (I forget if it was 28 or 33 kbps)
> and
> felt it was now reasonable to download an entire CD, doing it in 6 or 7
> nights
> (stopping it every morning to use the Internet for other stuff, restarting
> it
> every night.)
>
> (Wait, hopefully, that wasn't me that did that, maybe it was my grandfather


You were lucky to be able to continue on. Those were the days when
that wasn't an almost demanded prerequisite as part of a download
manager, e.g. wget's "-c / --continue" flag. Connections were so
flaky, so unstable that even a 3 or 4 megabyte sized file was an all
day event.

The last year that I was on dialup, the local provider suddenly sped
up to maybe taking an hour to download those same 3 or 4 megabyte
files. As it turned out, I was about the only person left using their
dialup server. It was faster because there was no competing web
traffic from other ISP customers.

There was one download manager that sold itself because it focused on
being able to continue on without having to restart the download.
Whatever that one in-browser manager was, that was my HERO for a
number of years... until I discovered wget. Once in a while there will
be a "gatekeeper" (cookie reliant) instance where wget also doesn't
work still and though.

The World needs to obsolete anything that's slower than the cheap
service I'm using right now (whatever it is). Speedier Internet
connections are a LIFE-altering necessity in the Age of Technology.
Beyond that, COVID-19 has turned quality of at-home Internet service
into a checkpoint regarding one's employability.

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

Ot: 6 or 7 nights to download a CD (was: Re: RJ-11 phone line)

[rhkramer]

On Thursday, October 07, 2021 07:43:02 AM Dan Ritter wrote:
> Note that a minimal Debian install is around 500 MB, which would
> take around 24 hours of a perfect 56K modem connection.

I can remember when I got a fast modem (I forget if it was 28 or 33 kbps) and 
felt it was now reasonable to download an entire CD, doing it in 6 or 7 nights 
(stopping it every morning to use the Internet for other stuff, restarting it 
every night.)  

(Wait, hopefully, that wasn't me that did that, maybe it was my grandfather 
;-)

Re: - maybe someone may be familiar MX : Download

[ellanios82]

On 29/8/21 5:50 μ.μ., Thomas Schmitt wrote:

But because i dislike their stop-me-if-you-can download, i rather did

   wgethttps://ftp.gwdg.de/pub/linux/mx/iso/MX/Final/MX-19.4_x64.iso

and got as SHA256
   469f63c7170e20cfe4c1e8996f6e2acf56509c068c08322aaed3ec3a6c9e254f

It's a nice isohybrid made in march 2021 by xorriso-1.5.2 (probably from
the Debian package that was in "testing" back then).


Have a nice day :)

Thomas



 Thank you, kindly, Thomas


 regards

.

Re: - maybe someone may be familiar MX : Download

[Thomas Schmitt]

Hi,

ellanios82 wrote:
> >  - bewildered, have been trying to download :
> >   MX-19.4_July_x64.iso
> >          from
> > <https://sourceforge.net/projects/mx-linux/files/latest/download>
> >  however, the  > 469f63c7170e20cfe4c1e8996f6e2acf56509c068c08322aaed3ec3a6c9e254f>
> >
> >  from web-page <https://mxlinux.org/wiki/system/iso-download-mirrors/> which
> > i ought to be getting , is Not what i am getting

Dan Ritter wrote:
> 3. You are looking at the wrong file/hash combination.

I place my bet on this one.

The SHA256 is for MX-19.4_x64.iso, not for MX-19.4_July_x64.iso.
The matching ISO is probably at
  https://sourceforge.net/projects/mx-linux/files/Final/
But because i dislike their stop-me-if-you-can download, i rather did

  wget https://ftp.gwdg.de/pub/linux/mx/iso/MX/Final/MX-19.4_x64.iso

and got as SHA256
  469f63c7170e20cfe4c1e8996f6e2acf56509c068c08322aaed3ec3a6c9e254f

It's a nice isohybrid made in march 2021 by xorriso-1.5.2 (probably from
the Debian package that was in "testing" back then).


Have a nice day :)

Thomas