Re: Firmware GR result - what happens next?

[Michael Stone]

On Fri, Oct 14, 2022 at 10:52:01AM +0200, Santiago Ruano Rincón wrote:

5. transitional packages along with a helper package (that fails or
success during install) to prompt the user so they add non-free-firmware
section when needed.

Is there any reason why you are not considering 5.?


The danger we're trying to avoid is that a system with a working 
"something" (say, networking) gets upgraded, user reboots (or machine 
crashes, or there's a power failure, etc, etc.), the working "something" 
is now a not-working "something", and fixing it is really hard for the 
user who has no idea what happened and maybe doesn't have a network or a 
console or whatever any more. A package that fails during install will 
prevent the upgrade from completing, but will leave things in an 
in-between state until some action is taken, the upgrade restarted, and 
the upgrade manages to finish successfully. What happens if the 
reboot/crash/powercycle/etc happens during that in-between state? How do 
you make a firmware helper package that reliably prevents a kernel 
installation when the kernel doesn't have any dependencies on the 
firmware package, and also doesn't yank out the old working firmware, 
etc. I'm sure you can make the install explode, but making it reliably 
explode at just the right time seems harder. I guess this could all 
work, but I'm seeing a lot of potential for partial installs/failures 
with this approach and I suspect this would require transition code in a 
number of packages' preinsts, not a discrete "helper package".

Re: Firmware GR result - what happens next?

[Bernd Zeimetz]

On Sun, 2022-10-02 at 12:26 -0700, Steve Langasek wrote:
> 
> I heartily endorse ubuntu-release-upgrader, it has been useful in addressing
> uncounted upgrade issues over the years and I think something like this
> would be a nice addition to Debian as well.  Two caveats:

That thing is actually one of the main reasons I'm not using Ubuntu.

I expect properly maintained and upgradable packages, and not a hacky thing.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Firmware GR result - what happens next?

[David Kalnischkies]

On Fri, Oct 14, 2022 at 01:32:41PM +0800, Paul Wise wrote:
> On Thu, 2022-10-13 at 17:35 +0200, Julien Cristau wrote:
> > I'd prefer if we could make things work vs making things fail,
> > however loudly.
> 
> There seem to be a few ways to deal with this transition:

(quotes reordered in Pauls preference order mentioned at the end)

> 4. Keep all non-free-firmware packages in non-free too. This would be
> backwards compatible, but may expose bugs in dak, debian-cd, apt and
> other tools, so IIRC this has been vetoed by the archive and CD teams.
> This also wouldn't result in users without non-free getting any of the
> non-free firmware, which maybe we want since it is the new default?

libapt or probably most user-facing client are no concern in this as
packages coming from multiple sources is normal. If you have e.g.
unstable and testing in your sources.list it is happening all the time,
or you have multiple mirrors, … only by the virtue of having packages
installed and somewhere online a client needs a way to figure out if the
version installed is the same as (one of) the versions online and which
online sources talk about the same version (naively, you would think
version number is enough, but libapt actually goes beyond that).

I assume through that in servers and other tools who are not usually
exposed to packages in multiple versions or multiple sources in general
have a harder time with this, so I can understand them being reluctant.

There are also a lot of tools… most user-facing clients will be based
on libapt or at least directly inspired by it, but if clients like
(c)debootstrap expect a package name to be no longer unique in their
world view (after all, they don't even do multi-sources like -updates
and -security …) I honestly don't know and fear the worst.


It is also that if we decide that, we basically decide that it will stay
that way forever. Its also an (arguably tiny) waste of diskspace and
such for everyone who has both components configured.

It is the only solution treating everyone equal though. All the others
talk only about sources.list with no idea if and how e.g. debootstrap
needs to understand that non-free-firmware is a thing now. Does it?


> 3. Add some code to apt to download non-free-firmware when non-free is
> available in the sources and the downloaded Release files. This would
> solve the issue for Debian and all other derivatives too, if they
> decide to add a new non-free-firmware component too. This might not
> be accepted by apt developers as it is kind of a hack to special-case
> Debian component semantics in apt, although maybe a component mapping
> config option would be accepted. This might result in extra Debian
> support requests when users notice the new component in `apt update`.
> This might not work for users of tools not based on apt, like cupt?
> This wouldn't result in users without non-free getting any non-free
> firmware though, which maybe we want since it is the new default?

The problem with this within libapt is that libapt wants to look at the
sources.list entry and produce a list of files which could possibly
belong to this entry. The Release file is just one of those files.
It is consulted later to remove entries from the file list (e.g. in an
'update'), but files aren't added at that stage.

Think of 'apt update --print-uris': What would that print if it would
need to look at the Release first? If you look closely, you will notice
e.g. a line talking about 'binary-all/Packages'. The Release file will
later tell apt to not download it for Debian. Similar, depending on your
locale environment apt talks about downloading Translation files here
which don't exist or perhaps even of Contents files which are in an
other location than in reality for some distros (hello Ubuntu).

So, if we wanted that, I could hardcode in apt that it should look for
non-free-firmware, too, if it sees non-free as a component configured
and decide later on not to download that component if it doesn't exist –
on the upside (depending on your view) that isn't Debian specific.
In practice it would probably turn out to be a medium sized patch as
so far apt doesn't have the concept of an implicit component, but it
shouldn't be rocket science and easily done ahead of the freeze.
It would probably be too big for a backport through and even if very
unlikely in practice a behaviour change as suddenly grabbing an existing
non-free-firmware component and upgrades from it after an unattended
upgrade in an unattended upgrade is… that rules out availability of
the bookworm-version of firmware packages in the upgrade to bookworm.
They would be installed only with the first 'update && upgrade' cycle
on the upgraded bookworm system, potentially unattended. Most other
"solutions" have the same "problem" – I would hope that for firmware
packages it isn't really one in practice as they should be very light on
(rev-)dependencies and demands upon them.

We are potentially burning one 

Re: Firmware GR result - what happens next?

[Holger Levsen]

On Fri, Oct 14, 2022 at 01:32:41PM +0800, Paul Wise wrote:
> 4. Keep all non-free-firmware packages in non-free too. This would be
> backwards compatible, but may expose bugs in dak, debian-cd, apt and
> other tools, so IIRC this has been vetoed by the archive and CD teams.
> This also wouldn't result in users without non-free getting any of the
> non-free firmware, which maybe we want since it is the new default?
> 
> Personally I would choose 4 first, I expect any potential issues could
> be easily fixed before the freeze. 

but what would you then propose after the release, where we would have
exactly the same situation as we would have now. carry this on forever?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

When this virus is over, I still want some of you all to stay away from me.


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Marvin Renich]

* Paul Wise  [221014 01:35]:
> On Thu, 2022-10-13 at 17:35 +0200, Julien Cristau wrote:
> 
> > I'd prefer if we could make things work vs making things fail,
> > however loudly.
> 
> There seem to be a few ways to deal with this transition:
> 
> 2. Add some code somewhere to automatically modify the apt sources,
> somehow ensure that code is run by all Debian users and hope that other
> automated processes (like ansible/puppet) don't overwrite those changes
> and hope that users aren't storing apt sources config in packages,
> which would mean conffile prompts after the modification happens.

Actually, I think this would work really well.  Do not modify any
existing sources.list; drop a new file in sources.list.d.  This file can
have a default name that includes "firmware-nonfree" so is highly
unlikely to exist, but if it does, add "-NNN" suffix with the smallest
numeric NNN that does not exist.

Of course, the file would only be added if the current sources do not
include that component, which would _really_ decrease the probability of
a file name conflict to be about the same as the probability of the
earth being destroyed by an asteroid.

...Marvin

Re: Firmware GR result - what happens next?

[Peter Pentchev]

On Fri, Oct 14, 2022 at 10:52:01AM +0200, Santiago Ruano Rincón wrote:
> El 14/10/22 a las 13:32, Paul Wise escribió:
> > On Thu, 2022-10-13 at 17:35 +0200, Julien Cristau wrote:
> > 
> > > I'd prefer if we could make things work vs making things fail,
> > > however loudly.
> > 
> > There seem to be a few ways to deal with this transition:
> > 
> > 1. Document it in the release notes and let users handle it. This means
> > lots of users won't get security updates for firmware (which are mostly
> > only issued for x86 CPU microcode), since lots of folks won't read the
> > release notes. This also means lots of support requests when users
> > can't find the firmware package they wanted.
> > 
> > 2. Add some code somewhere to automatically modify the apt sources,
> > somehow ensure that code is run by all Debian users and hope that other
> > automated processes (like ansible/puppet) don't overwrite those changes
> > and hope that users aren't storing apt sources config in packages,
> > which would mean conffile prompts after the modification happens.
> > 
> > 3. Add some code to apt to download non-free-firmware when non-free is
> > available in the sources and the downloaded Release files. This would
> > solve the issue for Debian and all other derivatives too, if they
> > decide to add a new non-free-firmware component too. This might not
> > be accepted by apt developers as it is kind of a hack to special-case
> > Debian component semantics in apt, although maybe a component mapping
> > config option would be accepted. This might result in extra Debian
> > support requests when users notice the new component in `apt update`. 
> > This might not work for users of tools not based on apt, like cupt?
> > This wouldn't result in users without non-free getting any non-free
> > firmware though, which maybe we want since it is the new default?
> > 
> > 4. Keep all non-free-firmware packages in non-free too. This would be
> > backwards compatible, but may expose bugs in dak, debian-cd, apt and
> > other tools, so IIRC this has been vetoed by the archive and CD teams.
> > This also wouldn't result in users without non-free getting any of the
> > non-free firmware, which maybe we want since it is the new default?
> > 
> > Personally I would choose 4 first, I expect any potential issues could
> > be easily fixed before the freeze. Next I would choose 3. Next I would
> > choose 1 because I think /etc belongs to the sysadmin not packages.
> 
> 5. transitional packages along with a helper package (that fails or
> success during install) to prompt the user so they add non-free-firmware
> section when needed.
> 
> Is there any reason why you are not considering 5.?

Do you mean having packages with the same names, but different versions
(even if only Debian revisions) and totally different contents, and also
built from different source packages, in different sections of the same
suite in the archive?... I'm... I'm not sure this would work... I think that
others already expressed some doubts as to how dak would handle that.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Santiago Ruano Rincón]

El 14/10/22 a las 13:32, Paul Wise escribió:
> On Thu, 2022-10-13 at 17:35 +0200, Julien Cristau wrote:
> 
> > I'd prefer if we could make things work vs making things fail,
> > however loudly.
> 
> There seem to be a few ways to deal with this transition:
> 
> 1. Document it in the release notes and let users handle it. This means
> lots of users won't get security updates for firmware (which are mostly
> only issued for x86 CPU microcode), since lots of folks won't read the
> release notes. This also means lots of support requests when users
> can't find the firmware package they wanted.
> 
> 2. Add some code somewhere to automatically modify the apt sources,
> somehow ensure that code is run by all Debian users and hope that other
> automated processes (like ansible/puppet) don't overwrite those changes
> and hope that users aren't storing apt sources config in packages,
> which would mean conffile prompts after the modification happens.
> 
> 3. Add some code to apt to download non-free-firmware when non-free is
> available in the sources and the downloaded Release files. This would
> solve the issue for Debian and all other derivatives too, if they
> decide to add a new non-free-firmware component too. This might not
> be accepted by apt developers as it is kind of a hack to special-case
> Debian component semantics in apt, although maybe a component mapping
> config option would be accepted. This might result in extra Debian
> support requests when users notice the new component in `apt update`. 
> This might not work for users of tools not based on apt, like cupt?
> This wouldn't result in users without non-free getting any non-free
> firmware though, which maybe we want since it is the new default?
> 
> 4. Keep all non-free-firmware packages in non-free too. This would be
> backwards compatible, but may expose bugs in dak, debian-cd, apt and
> other tools, so IIRC this has been vetoed by the archive and CD teams.
> This also wouldn't result in users without non-free getting any of the
> non-free firmware, which maybe we want since it is the new default?
> 
> Personally I would choose 4 first, I expect any potential issues could
> be easily fixed before the freeze. Next I would choose 3. Next I would
> choose 1 because I think /etc belongs to the sysadmin not packages.

5. transitional packages along with a helper package (that fails or
success during install) to prompt the user so they add non-free-firmware
section when needed.

Is there any reason why you are not considering 5.?

Cheers!

 -- Santiago


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Paul Wise]

On Thu, 2022-10-13 at 17:35 +0200, Julien Cristau wrote:

> I'd prefer if we could make things work vs making things fail,
> however loudly.

There seem to be a few ways to deal with this transition:

1. Document it in the release notes and let users handle it. This means
lots of users won't get security updates for firmware (which are mostly
only issued for x86 CPU microcode), since lots of folks won't read the
release notes. This also means lots of support requests when users
can't find the firmware package they wanted.

2. Add some code somewhere to automatically modify the apt sources,
somehow ensure that code is run by all Debian users and hope that other
automated processes (like ansible/puppet) don't overwrite those changes
and hope that users aren't storing apt sources config in packages,
which would mean conffile prompts after the modification happens.

3. Add some code to apt to download non-free-firmware when non-free is
available in the sources and the downloaded Release files. This would
solve the issue for Debian and all other derivatives too, if they
decide to add a new non-free-firmware component too. This might not
be accepted by apt developers as it is kind of a hack to special-case
Debian component semantics in apt, although maybe a component mapping
config option would be accepted. This might result in extra Debian
support requests when users notice the new component in `apt update`. 
This might not work for users of tools not based on apt, like cupt?
This wouldn't result in users without non-free getting any non-free
firmware though, which maybe we want since it is the new default?

4. Keep all non-free-firmware packages in non-free too. This would be
backwards compatible, but may expose bugs in dak, debian-cd, apt and
other tools, so IIRC this has been vetoed by the archive and CD teams.
This also wouldn't result in users without non-free getting any of the
non-free firmware, which maybe we want since it is the new default?

Personally I would choose 4 first, I expect any potential issues could
be easily fixed before the freeze. Next I would choose 3. Next I would
choose 1 because I think /etc belongs to the sysadmin not packages.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Firmware GR result - what happens next?

[Wouter Verhelst]

On Thu, Oct 13, 2022 at 04:13:57PM +0100, Steve McIntyre wrote:
> On Thu, Oct 13, 2022 at 05:08:57PM +0200, Julien Cristau wrote:
> >On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote:
> >> Maybe and idea would to do something like isa-support does for e.g 
> >> sseX-support
> >> on CPUs that does not have that feature: It fails on installation with an 
> >> debconf message, IIRC.
> >> So that would allow something like "new package" | 
> >> "you-need-to-enable-nonfree-firmware-reminder-package"
> >> 
> >Failing on installation is a terrible user experience, let's not, pretty
> >please.
> 
> It's not great, no. Do you have a better suggestion for making sure
> people update sources.list?

We can display a debconf error (which debconf tries really really hard
to show to the user) and then succeed?

Alternatively, the package could install an apt hook that nags the user
every time they run "apt update" or equivalent, and that turns silent if
the updated firmware packages are installed (because of the difference
between "purge" and "remove").

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Firmware GR result - what happens next?

[Tobias Frost]

On Thu, Oct 13, 2022 at 05:08:57PM +0200, Julien Cristau wrote:
> On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote:
> > Maybe and idea would to do something like isa-support does for e.g 
> > sseX-support
> > on CPUs that does not have that feature: It fails on installation with an 
> > debconf message, IIRC.
> > So that would allow something like "new package" | 
> > "you-need-to-enable-nonfree-firmware-reminder-package"
> > 
> Failing on installation is a terrible user experience, let's not, pretty
> please.

I'd prefer failing loudly to failing silently.
 
> Cheers,
> Julien

Re: Firmware GR result - what happens next?

[Julien Cristau]

On Thu, Oct 13, 2022 at 05:17:59PM +0200, Tobias Frost wrote:
> On Thu, Oct 13, 2022 at 05:08:57PM +0200, Julien Cristau wrote:
> > On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote:
> > > Maybe and idea would to do something like isa-support does for e.g 
> > > sseX-support
> > > on CPUs that does not have that feature: It fails on installation with an 
> > > debconf message, IIRC.
> > > So that would allow something like "new package" | 
> > > "you-need-to-enable-nonfree-firmware-reminder-package"
> > > 
> > Failing on installation is a terrible user experience, let's not, pretty
> > please.
> 
> I'd prefer failing loudly to failing silently.
>  
I'd prefer if we could make things work vs making things fail, however loudly.

Cheers,
Julien

Re: Firmware GR result - what happens next?

[Steve McIntyre]

On Thu, Oct 13, 2022 at 05:08:57PM +0200, Julien Cristau wrote:
>On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote:
>> Maybe and idea would to do something like isa-support does for e.g 
>> sseX-support
>> on CPUs that does not have that feature: It fails on installation with an 
>> debconf message, IIRC.
>> So that would allow something like "new package" | 
>> "you-need-to-enable-nonfree-firmware-reminder-package"
>> 
>Failing on installation is a terrible user experience, let's not, pretty
>please.

It's not great, no. Do you have a better suggestion for making sure
people update sources.list?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis

Re: Firmware GR result - what happens next?

[Julien Cristau]

On Thu, Oct 06, 2022 at 05:13:22PM +0200, Tobias Frost wrote:
> Maybe and idea would to do something like isa-support does for e.g 
> sseX-support
> on CPUs that does not have that feature: It fails on installation with an 
> debconf message, IIRC.
> So that would allow something like "new package" | 
> "you-need-to-enable-nonfree-firmware-reminder-package"
> 
Failing on installation is a terrible user experience, let's not, pretty
please.

Cheers,
Julien

More on nonfree firmware transitional packages (was: Firmware GR result - what happens next?)

[Santiago Ruano Rincón]

El 06/10/22 a las 17:13, Tobias Frost escribió:
> On Thu, Oct 06, 2022 at 05:03:20PM +0200, Julien Cristau wrote:
> > On Thu, Oct  6, 2022 at 15:45:25 +0100, Steve McIntyre wrote:
> > 
> > > On Wed, Oct 05, 2022 at 10:11:27PM +0200, Julien Cristau wrote:
> > > >On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:
> > > >> On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote:
> > > >> >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
> > > >> >> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
> > > >> >> > What's the plan for upgraded systems with an existing 
> > > >> >> > /etc/apt/sources.list.
> > > >> >> > Will the new n-f-f section added on upgrades automatically(if 
> > > >> >> > non-free was
> > > >> >> > enabled before)?
> > > >> >> 
> > > >> >> So this is the one bit that I don't think we currently have a good
> > > >> >> answer for. We've never had a specific script to run on upgrades 
> > > >> >> (like
> > > >> >> Ubuntu do), so this kind of potentially breaking change doesn't 
> > > >> >> really
> > > >> >> have an obvious place to be fixed.
> > > >> >
> > > >> >Is there a reason to not continue to make the packages available in 
> > > >> >non-free?
> > > >> >I don't see a reason to force any change on existing systems.
> > > >> 
> > > >> Two things:
> > > >> 
> > > >>  1. I'm worried what bugs we might expose by having packages be in two
> > > >> components at once.
> > > >>  2. I really don't like the idea of leaving two different
> > > >> configurations in the wild; it'll confuse people and is more
> > > >> likely to cause issues in the future IMHO.
> > > >> 
> > > >> Plus, as Shengjing Zhu points out: we already expect people to manage
> > > >> the sources.list anyway on upgrades.
> > > >> 
> > > >I think in the absence of a release upgrade script (which I very much
> > > >doubt will happen, and be tested, and we can rely will be used, for
> > > >bookworm), Michael's suggestion seems like a reasonable way forward.  I
> > > >imagine we'll need to patch dak to allow that, but it seems like it
> > > >should be tractable?
> > > 
> > > I'm also worried what effect this will have on other tools that have
> > > to grok the archive (mirror tools, debian-cd, etc.). I'm not going to
> > > try and veto having things in more than one component, but (ugh!) I
> > > really think it's ugly. Actually, I think I'd much prefer Santiago's
> > > idea:
> > > 
> > > > Couldn't we handle this via transitional firware* non-free packages,
> > > > that depend on bookworm non-free-firmware packages?
> > > 
> > > We'd need to add some transitional binary packages for the small
> > > number of n-f-f source packages. That way people would get errors from
> > > apt if they don't read our warnings and update. Maybe this is a way
> > > forward?
> > > 
> > I don't think that will work well, the packages will likely just be held
> > at the old version if the new ones are uninstallable because the new
> > component isn't enabled.

Good point!

> Maybe and idea would to do something like isa-support does for e.g 
> sseX-support
> on CPUs that does not have that feature: It fails on installation with an 
> debconf message, IIRC.
> So that would allow something like "new package" | 
> "you-need-to-enable-nonfree-firmware-reminder-package"

And this could solve the issue, indeed. Picking up my other mail in the
thread, the transitional packages could be summarised like this:

bullseye:
firmware-linux-nonfree (non-free)
bookworm:
firmware-linux-nonfree (non-free) - empty
Depends: firmware-linux-nonfree-bookworm* (non-free-firmware) |
 non-free-firmware-needed-warning-package
trixie:
firmware-linux-nonfree-bookworm (non-free-firmware) - empty
Depends: firmware-linux-nonfree (non-free-firmware)
trixie+1 (forky):
firmware-linux-nonfree (non-free-firmware)
and so on.

* find a better name/suffix

Would this make sense?

I could volunteer to test this and propose the needed new package,
unless someone else wants to do it.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Tobias Frost]

On Thu, Oct 06, 2022 at 05:03:20PM +0200, Julien Cristau wrote:
> On Thu, Oct  6, 2022 at 15:45:25 +0100, Steve McIntyre wrote:
> 
> > On Wed, Oct 05, 2022 at 10:11:27PM +0200, Julien Cristau wrote:
> > >On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:
> > >> On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote:
> > >> >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
> > >> >> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
> > >> >> > What's the plan for upgraded systems with an existing 
> > >> >> > /etc/apt/sources.list.
> > >> >> > Will the new n-f-f section added on upgrades automatically(if 
> > >> >> > non-free was
> > >> >> > enabled before)?
> > >> >> 
> > >> >> So this is the one bit that I don't think we currently have a good
> > >> >> answer for. We've never had a specific script to run on upgrades (like
> > >> >> Ubuntu do), so this kind of potentially breaking change doesn't really
> > >> >> have an obvious place to be fixed.
> > >> >
> > >> >Is there a reason to not continue to make the packages available in 
> > >> >non-free?
> > >> >I don't see a reason to force any change on existing systems.
> > >> 
> > >> Two things:
> > >> 
> > >>  1. I'm worried what bugs we might expose by having packages be in two
> > >> components at once.
> > >>  2. I really don't like the idea of leaving two different
> > >> configurations in the wild; it'll confuse people and is more
> > >> likely to cause issues in the future IMHO.
> > >> 
> > >> Plus, as Shengjing Zhu points out: we already expect people to manage
> > >> the sources.list anyway on upgrades.
> > >> 
> > >I think in the absence of a release upgrade script (which I very much
> > >doubt will happen, and be tested, and we can rely will be used, for
> > >bookworm), Michael's suggestion seems like a reasonable way forward.  I
> > >imagine we'll need to patch dak to allow that, but it seems like it
> > >should be tractable?
> > 
> > I'm also worried what effect this will have on other tools that have
> > to grok the archive (mirror tools, debian-cd, etc.). I'm not going to
> > try and veto having things in more than one component, but (ugh!) I
> > really think it's ugly. Actually, I think I'd much prefer Santiago's
> > idea:
> > 
> > > Couldn't we handle this via transitional firware* non-free packages,
> > > that depend on bookworm non-free-firmware packages?
> > 
> > We'd need to add some transitional binary packages for the small
> > number of n-f-f source packages. That way people would get errors from
> > apt if they don't read our warnings and update. Maybe this is a way
> > forward?
> > 
> I don't think that will work well, the packages will likely just be held
> at the old version if the new ones are uninstallable because the new
> component isn't enabled.

Maybe and idea would to do something like isa-support does for e.g sseX-support
on CPUs that does not have that feature: It fails on installation with an 
debconf message, IIRC.
So that would allow something like "new package" | 
"you-need-to-enable-nonfree-firmware-reminder-package"

> Cheers,
> Julien
> 

Re: Firmware GR result - what happens next?

[Julien Cristau]

On Thu, Oct  6, 2022 at 15:45:25 +0100, Steve McIntyre wrote:

> On Wed, Oct 05, 2022 at 10:11:27PM +0200, Julien Cristau wrote:
> >On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:
> >> On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote:
> >> >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
> >> >> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
> >> >> > What's the plan for upgraded systems with an existing 
> >> >> > /etc/apt/sources.list.
> >> >> > Will the new n-f-f section added on upgrades automatically(if 
> >> >> > non-free was
> >> >> > enabled before)?
> >> >> 
> >> >> So this is the one bit that I don't think we currently have a good
> >> >> answer for. We've never had a specific script to run on upgrades (like
> >> >> Ubuntu do), so this kind of potentially breaking change doesn't really
> >> >> have an obvious place to be fixed.
> >> >
> >> >Is there a reason to not continue to make the packages available in 
> >> >non-free?
> >> >I don't see a reason to force any change on existing systems.
> >> 
> >> Two things:
> >> 
> >>  1. I'm worried what bugs we might expose by having packages be in two
> >> components at once.
> >>  2. I really don't like the idea of leaving two different
> >> configurations in the wild; it'll confuse people and is more
> >> likely to cause issues in the future IMHO.
> >> 
> >> Plus, as Shengjing Zhu points out: we already expect people to manage
> >> the sources.list anyway on upgrades.
> >> 
> >I think in the absence of a release upgrade script (which I very much
> >doubt will happen, and be tested, and we can rely will be used, for
> >bookworm), Michael's suggestion seems like a reasonable way forward.  I
> >imagine we'll need to patch dak to allow that, but it seems like it
> >should be tractable?
> 
> I'm also worried what effect this will have on other tools that have
> to grok the archive (mirror tools, debian-cd, etc.). I'm not going to
> try and veto having things in more than one component, but (ugh!) I
> really think it's ugly. Actually, I think I'd much prefer Santiago's
> idea:
> 
> > Couldn't we handle this via transitional firware* non-free packages,
> > that depend on bookworm non-free-firmware packages?
> 
> We'd need to add some transitional binary packages for the small
> number of n-f-f source packages. That way people would get errors from
> apt if they don't read our warnings and update. Maybe this is a way
> forward?
> 
I don't think that will work well, the packages will likely just be held
at the old version if the new ones are uninstallable because the new
component isn't enabled.

Cheers,
Julien

Re: Firmware GR result - what happens next?

[Steve McIntyre]

On Wed, Oct 05, 2022 at 10:11:27PM +0200, Julien Cristau wrote:
>On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:
>> On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote:
>> >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
>> >> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
>> >> > What's the plan for upgraded systems with an existing 
>> >> > /etc/apt/sources.list.
>> >> > Will the new n-f-f section added on upgrades automatically(if non-free 
>> >> > was
>> >> > enabled before)?
>> >> 
>> >> So this is the one bit that I don't think we currently have a good
>> >> answer for. We've never had a specific script to run on upgrades (like
>> >> Ubuntu do), so this kind of potentially breaking change doesn't really
>> >> have an obvious place to be fixed.
>> >
>> >Is there a reason to not continue to make the packages available in 
>> >non-free?
>> >I don't see a reason to force any change on existing systems.
>> 
>> Two things:
>> 
>>  1. I'm worried what bugs we might expose by having packages be in two
>> components at once.
>>  2. I really don't like the idea of leaving two different
>> configurations in the wild; it'll confuse people and is more
>> likely to cause issues in the future IMHO.
>> 
>> Plus, as Shengjing Zhu points out: we already expect people to manage
>> the sources.list anyway on upgrades.
>> 
>I think in the absence of a release upgrade script (which I very much
>doubt will happen, and be tested, and we can rely will be used, for
>bookworm), Michael's suggestion seems like a reasonable way forward.  I
>imagine we'll need to patch dak to allow that, but it seems like it
>should be tractable?

I'm also worried what effect this will have on other tools that have
to grok the archive (mirror tools, debian-cd, etc.). I'm not going to
try and veto having things in more than one component, but (ugh!) I
really think it's ugly. Actually, I think I'd much prefer Santiago's
idea:

> Couldn't we handle this via transitional firware* non-free packages,
> that depend on bookworm non-free-firmware packages?

We'd need to add some transitional binary packages for the small
number of n-f-f source packages. That way people would get errors from
apt if they don't read our warnings and update. Maybe this is a way
forward?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Re: Firmware GR result - what happens next?

[Julien Cristau]

On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:
> On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote:
> >On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
> >> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
> >> > What's the plan for upgraded systems with an existing 
> >> > /etc/apt/sources.list.
> >> > Will the new n-f-f section added on upgrades automatically(if non-free 
> >> > was
> >> > enabled before)?
> >> 
> >> So this is the one bit that I don't think we currently have a good
> >> answer for. We've never had a specific script to run on upgrades (like
> >> Ubuntu do), so this kind of potentially breaking change doesn't really
> >> have an obvious place to be fixed.
> >
> >Is there a reason to not continue to make the packages available in non-free?
> >I don't see a reason to force any change on existing systems.
> 
> Two things:
> 
>  1. I'm worried what bugs we might expose by having packages be in two
> components at once.
>  2. I really don't like the idea of leaving two different
> configurations in the wild; it'll confuse people and is more
> likely to cause issues in the future IMHO.
> 
> Plus, as Shengjing Zhu points out: we already expect people to manage
> the sources.list anyway on upgrades.
> 
I think in the absence of a release upgrade script (which I very much
doubt will happen, and be tested, and we can rely will be used, for
bookworm), Michael's suggestion seems like a reasonable way forward.  I
imagine we'll need to patch dak to allow that, but it seems like it
should be tractable?

Cheers,
Julien

Re: transitional packages? (was: Firmware GR result - what happens next?)

[Shengjing Zhu]

On Mon, Oct 3, 2022 at 11:32 PM Santiago Ruano Rincón
 wrote:
> > Can we have different versions in each section?
> >
> > + non-free/pkgA version~1
> > + non-free-firmware/pkgA version~2
>
> that wouldn't comply with the current policy:
> https://www.debian.org/doc/debian-policy/ch-binary.html#the-package-name
>

I don't think it's related to name policy. It's whether dak will
remove old versions in different sections.

-- 
Shengjing Zhu

Re: transitional packages? (was: Firmware GR result - what happens next?)

[Santiago Ruano Rincón]

El 03/10/22 a las 19:40, Shengjing Zhu escribió:
> On Mon, Oct 3, 2022 at 7:31 PM Didier 'OdyX' Raboud  wrote:
> >
> > 3 octobre 2022 11:11 "Santiago Ruano Rincón"  a 
> > écrit:
> > > El 02/10/22 a las 20:42, Michael Biebl escribió:
> > >> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
> > >> On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
> > >> In Bullseye we changed the name/syntax for the security repository, and
> > >> for that a mention in the release notes was enough, no? Isn't this a
> > >> very similar situation?
> > >>
> > >> The main difference is, that the renaming caused an error message by 
> > >> apt, so
> > >> you knew something needed to be fixed.
> > >>
> > >> For this particular change, there will be no error. So yes, I have the 
> > >> same
> > >> fear as Russ that this particular change might go unnoticed.
> > >
> > > Couldn't we handle this via transitional firware* non-free packages,
> > > that depend on bookworm non-free-firmware packages?
> >
> > That would only work if we renamed all concerned binary packages, or if apt 
> > grew a "section/packagename" syntax (which would be bizarre).
> >
> 
> Can we have different versions in each section?
> 
> + non-free/pkgA version~1
> + non-free-firmware/pkgA version~2

that wouldn't comply with the current policy:
https://www.debian.org/doc/debian-policy/ch-binary.html#the-package-name

> 
> And let non-free/pkgA version~1 just fail during upgrade and produce a
> migration guide.
> 
> -- 
> Shengjing Zhu
> 


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Thomas Goirand]

On 10/3/22 02:23, Charles Plessy wrote:

Le Mon, Oct 03, 2022 at 12:33:20AM +0200, Mattia Rizzolo a écrit :


I can live with an APT hook warning me if I have non-free but not
non-free-firmware, but I would prefer to even do without that.


In addition, how about distributing the firmware in both 'non-free' and
'non-free-firmware' at the same time for a release or two ?


How about being smarter than this? :)

Cheers,

Thomas Goirand (zigo)

Re: Firmware GR result - what happens next?

[Michael Stone]

On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:

Plus, as Shengjing Zhu points out: we already expect people to manage
the sources.list anyway on upgrades.


We also try to avoid silent install problems that might or might not 
result in a system that doesn't boot properly.

Re: Firmware GR result - what happens next?

[Julian Andres Klode]

On Sun, Oct 02, 2022 at 12:26:29PM -0700, Steve Langasek wrote:
> On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
> > >What's the plan for upgraded systems with an existing 
> > >/etc/apt/sources.list.
> > >Will the new n-f-f section added on upgrades automatically(if non-free was
> > >enabled before)?
> 
> > So this is the one bit that I don't think we currently have a good
> > answer for. We've never had a specific script to run on upgrades (like
> > Ubuntu do), so this kind of potentially breaking change doesn't really
> > have an obvious place to be fixed.
> 
> > Obviously we'll need to mention this in the release notes for
> > bookworm. Should we maybe talk about adding an upgrade helper tool?

We have already talked about apt release-upgrade for a couple of times,
but no time to implement it yet and the design needs to be talked
through how the target release can hook into apt to provide quirks.

We want apt release-upgrade too

1. rewrite sources for you if you want to
2. upgrade the system in three steps equivalent to

apt safe-upgrade --without-new-pkgs
apt safe-upgrade --with-new-pkg
apt full-upgrade

3. Hooks to customize the dependency solving (adding/removing packages),
   and potentially arbitrary quirks.

Where things get awkard is that (1) we'd like declarative hooks where
possible, a deb822 file of hooks, but (2) we also need to perhaps add
new logic.

So there was an idea to build a binary package that ships a module that
can be loaded at runtime by apt. So apt would install that package first
before it can upgrade. Or you can make it be a shell script and have
hooks of Type: Shell. Or just add Depends to release file that requires
users to install a newer version of apt before they can use the
repository and then ship that in (old)stable-updates with the additional
types of hooks.


> 
> I heartily endorse ubuntu-release-upgrader, it has been useful in addressing
> uncounted upgrade issues over the years and I think something like this
> would be a nice addition to Debian as well.  Two caveats:
> 
>  - Despite this being the sanctioned upgrade path in Ubuntu for over a
>decade, every single cycle we get bug reports from users who have run
>into issues because they have bypassed it and done the manual sed
>/etc/apt/sources.list && apt dist-upgrade.  So in Debian where this has
>been the norm for /two/ decades, I would not expect this to substantially
>reduce the error rate in the first release where such a mechanism is
>introduced.  (After all, whether telling users to use a new upgrader tool
>or telling them to manually add a component to sources.list, they will
>have to read the release notes to know about it!)
> 
>  - There are always some users that end up with buggy systems after upgrade
>despite using the supported interface because they upgrade to the devel
>release, and the release-upgrader is still under development up until
>release so they miss out on quirks being applied - and there is no
>interface for users to replay the quirks that they missed out on.  Don't
>repeat the same design mistake.

That makes sense. So the idea for apt release-upgrade is to have a list
of quirks and each quirk can then have a test to see if it ran already.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Lennart Sorensen]

On Mon, Oct 03, 2022 at 02:47:33PM +0200, Pascal Hambourg wrote:
> Not even replace "stable/updates" with "stable-security" during the upgrade
> from buster to bullseye ?

Hmm I don't recall but I suppose it just wasn't very memorable to do it.
At least it would have given an error fetching the list if you didn't
do it.  Not adding a new entry on the other hand will not.

-- 
Len Sorensen

Re: Firmware GR result - what happens next?

[Pascal Hambourg]

On 03/10/2022 at 01:00, Lennart Sorensen wrote:

On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:


Plus, as Shengjing Zhu points out: we already expect people to manage
the sources.list anyway on upgrades.


People that just have 'stable' in their sources.list haven't had to
do anything.  I can't think of ever having had to add anything, only
change the release name.


Not even replace "stable/updates" with "stable-security" during the 
upgrade from buster to bullseye ?

Re: transitional packages? (was: Firmware GR result - what happens next?)

[Santiago Ruano Rincón]

El 03/10/22 a las 11:31, Didier 'OdyX' Raboud escribió:
> 3 octobre 2022 11:11 "Santiago Ruano Rincón"  a écrit:
> > El 02/10/22 a las 20:42, Michael Biebl escribió:
> >> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
> >> On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
> >> In Bullseye we changed the name/syntax for the security repository, and
> >> for that a mention in the release notes was enough, no? Isn't this a
> >> very similar situation?
> >> 
> >> The main difference is, that the renaming caused an error message by apt, 
> >> so
> >> you knew something needed to be fixed.
> >> 
> >> For this particular change, there will be no error. So yes, I have the same
> >> fear as Russ that this particular change might go unnoticed.
> > 
> > Couldn't we handle this via transitional firware* non-free packages,
> > that depend on bookworm non-free-firmware packages?
> 
> That would only work if we renamed all concerned binary packages, 

Indeed. Something like:

bullseye:
firmware-linux-nonfree (non-free)
bookworm:
firmware-linux-nonfree (non-free) - empty, that
Depends on: firmware-linux-nonfree-bookworm (non-free-firmware) -
find a better name/suffix
trixie:
firmware-linux-nonfree-bookworm (non-free-firmware) - empty
Depends on: firmware-linux-nonfree (non-free-firmware)
trixie+1:
firmware-linux-nonfree (non-free-firmware)
and so on.

It is (also) bizarre, but this would help users make sure they include
the non-free-firmware section when required. I suppose apt would
complain if it cannot satisfy the dependency due to a missing section.

> or if apt grew a "section/packagename" syntax (which would be bizarre).

Beyond being bizarre, users and other tools would have to learn that
syntax.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Cyril Brulebois]

Steve McIntyre  (2022-10-02):
>   + ftpsync (?)

I don't think that's needed. Using buster's and more recently bullseye's
version, I have this locally:

drwxr-xr-x 4 mirror mirror 4096 Jul 19 04:16 
/srv/mirrors/debian/dists/bookworm/non-free-firmware/by-hash/

which matches when dak's config got updated with that extra component.

The git tree has a bin/archive_release that lists components explicitly
but it doesn't end up in any binary packages (there's a single ftpsync,
and it's not shipped there). Furthermore the 'non-free' string doesn't
appear in any of the files below debian/ftpsync/ after a build, so the
package doesn't look like it needs an update for that (even though a lot
of work happened in master since the last tag/release).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Cyril Brulebois]

Colin Watson  (2022-10-03):
> Done in debmirror 1:2.37.  I guess we need to cherry-pick this to
> bullseye too?  I know bullseye doesn't have non-free-firmware (which
> is fine, the new debmirror doesn't object), but most people running
> mirrors probably run stable rather than testing.

Thanks for patching and verifying the extra component's presence on a
per-suite basis isn't an issue, that was on my to-do list.

And yes, it looks like bullseye-proposed-updates material to me; esp.
given that tiny diff…


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Colin Watson]

On Sun, Oct 02, 2022 at 03:27:36PM +0100, Steve McIntyre wrote:
> * Check/add support for the non-free-firmware section in various
>   places:
>   + debmirror (?)

Done in debmirror 1:2.37.  I guess we need to cherry-pick this to
bullseye too?  I know bullseye doesn't have non-free-firmware (which is
fine, the new debmirror doesn't object), but most people running mirrors
probably run stable rather than testing.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: transitional packages? (was: Firmware GR result - what happens next?)

[Shengjing Zhu]

On Mon, Oct 3, 2022 at 7:31 PM Didier 'OdyX' Raboud  wrote:
>
> 3 octobre 2022 11:11 "Santiago Ruano Rincón"  a écrit:
> > El 02/10/22 a las 20:42, Michael Biebl escribió:
> >> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
> >> On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
> >> In Bullseye we changed the name/syntax for the security repository, and
> >> for that a mention in the release notes was enough, no? Isn't this a
> >> very similar situation?
> >>
> >> The main difference is, that the renaming caused an error message by apt, 
> >> so
> >> you knew something needed to be fixed.
> >>
> >> For this particular change, there will be no error. So yes, I have the same
> >> fear as Russ that this particular change might go unnoticed.
> >
> > Couldn't we handle this via transitional firware* non-free packages,
> > that depend on bookworm non-free-firmware packages?
>
> That would only work if we renamed all concerned binary packages, or if apt 
> grew a "section/packagename" syntax (which would be bizarre).
>

Can we have different versions in each section?

+ non-free/pkgA version~1
+ non-free-firmware/pkgA version~2

And let non-free/pkgA version~1 just fail during upgrade and produce a
migration guide.

-- 
Shengjing Zhu

Re: transitional packages? (was: Firmware GR result - what happens next?)

[Didier 'OdyX' Raboud]

3 octobre 2022 11:11 "Santiago Ruano Rincón"  a écrit:
> El 02/10/22 a las 20:42, Michael Biebl escribió:
>> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
>> On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
>> In Bullseye we changed the name/syntax for the security repository, and
>> for that a mention in the release notes was enough, no? Isn't this a
>> very similar situation?
>> 
>> The main difference is, that the renaming caused an error message by apt, so
>> you knew something needed to be fixed.
>> 
>> For this particular change, there will be no error. So yes, I have the same
>> fear as Russ that this particular change might go unnoticed.
> 
> Couldn't we handle this via transitional firware* non-free packages,
> that depend on bookworm non-free-firmware packages?

That would only work if we renamed all concerned binary packages, or if apt 
grew a "section/packagename" syntax (which would be bizarre).

Re: Firmware GR result - what happens next?

[Julian Andres Klode]

On Sun, Oct 02, 2022 at 11:47:42PM +0200, Thomas Goirand wrote:
> On 10/2/22 22:02, Russ Allbery wrote:
> > Michael Biebl  writes:
> > 
> > > The main difference is, that the renaming caused an error message by
> > > apt, so you knew something needed to be fixed.
> > 
> > One could argue that having non-free but not non-free-firmware is
> > sufficiently strange that it would be worth a suppressable apt warning
> > (that you could turn off in apt.conf).  I have no idea how easy that would
> > be to implement, though.
> 
> Hi!
> 
> I would very much prefer having this implemented in the base_files package.
> This is *the* package that follows releases, so that's IMO the best
> location.
> 
> I would hate having to use an upgrade program like in Ubuntu. :/
> 
> An easy check could be:
> 1/ are we upgrading from base-files << 12.3 (we're currently at 12.2 in Sid)
> AND
> 2/ is there the non-free repo installed in the default sources.list
> AND
> 3/ non-free-firmware repo isn't installed
> 
> THEN
> 
> warn user with debconf.
> 
> Checking the configuration of a non-free and non-free-firmware is kind of
> hard, because just reading/parsing source.list and source.list.d that could
> be filled with non-debian repos can be quite hard. Though we could imagine
> tricks, like where both repo would include a special package present only
> for that test, and we just see if it is available with apt-cache policy for
> example (this is just an idea... not sure if there's better options).

Really all you need is

if [ -n "$(apt-get indextargets 'Component: non-free' 'Origin: Debian')" ] &&
   [ -z "$(apt-get indextargets 'Component: non-free-firmware' 'Origin: 
Debian')" ]; then
   debconf prompt
fi

I mean you could filter on codenames too but meh.

(CC me if you want me to get a reply in my INBOX, I may not see it
otherwise, I'm not subscribed, just receiving via NNTP gateway :D)
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

transitional packages? (was: Firmware GR result - what happens next?)

[Santiago Ruano Rincón]

El 02/10/22 a las 20:42, Michael Biebl escribió:
> 
> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
> > On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
> 
> > > will
> > > be very obvious.  But if you currently have non-free configured but
> > > don't
> > > add the new firmware section, everything will appear to work but you
> > > won't
> > > get new firmware, so the problem may go unnoticed.
> > 
> > In Bullseye we changed the name/syntax for the security repository, and
> > for that a mention in the release notes was enough, no? Isn't this a
> > very similar situation?
> 
> The main difference is, that the renaming caused an error message by apt, so
> you knew something needed to be fixed.
> 
> For this particular change, there will be no error. So yes, I have the same
> fear as Russ that this particular change might go unnoticed.
> 

Couldn't we handle this via transitional firware* non-free packages,
that depend on bookworm non-free-firmware packages?

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[David Prévot]

Hi,

Le 03/10/2022 à 01:00, Lennart Sorensen a écrit :
[…]

I can't think of ever having had to add anything, only
change the release name.


You’ll change your mind when you’ll upgrade to stable.

https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information#security-archive

Regards

David

Re: Firmware GR result - what happens next?

[Charles Plessy]

Le Mon, Oct 03, 2022 at 12:33:20AM +0200, Mattia Rizzolo a écrit :
> 
> I can live with an APT hook warning me if I have non-free but not
> non-free-firmware, but I would prefer to even do without that.

In addition, how about distributing the firmware in both 'non-free' and
'non-free-firmware' at the same time for a release or two ?

Cheers,

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: Firmware GR result - what happens next?

[Lennart Sorensen]

On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:
> Two things:
> 
>  1. I'm worried what bugs we might expose by having packages be in two
> components at once.
>  2. I really don't like the idea of leaving two different
> configurations in the wild; it'll confuse people and is more
> likely to cause issues in the future IMHO.
> 
> Plus, as Shengjing Zhu points out: we already expect people to manage
> the sources.list anyway on upgrades.

People that just have 'stable' in their sources.list haven't had to
do anything.  I can't think of ever having had to add anything, only
change the release name.

This will get missed and it will get missed a lot.

-- 
Len Sorensen

Re: Firmware GR result - what happens next?

[Mattia Rizzolo]

On Mon, Oct 03, 2022 at 01:18:55AM +0300, Dmitry Baryshkov wrote:
> вс, 2 окт. 2022 г. в 22:36, Steve Langasek :
> > > So this is the one bit that I don't think we currently have a good
> > > answer for. We've never had a specific script to run on upgrades (like
> > > Ubuntu do), so this kind of potentially breaking change doesn't really
> > > have an obvious place to be fixed.
> >
> > > Obviously we'll need to mention this in the release notes for
> > > bookworm. Should we maybe talk about adding an upgrade helper tool?
> >
> > I heartily endorse ubuntu-release-upgrader, it has been useful in addressing
> > uncounted upgrade issues over the years and I think something like this
> > would be a nice addition to Debian as well.  Two caveats:
> 
> I'd kindly ask against additional upgrade scripts. It is too easy to
> miss them, especially if one has been using Debian for ages with bare
> apt-get update && apt-get dist-upgrade.
> Moreover such a script will not help people that are already using testing.
> 
> For the past few decades, updating the setup was always a job of the
> package scripts.

This is getting OT in this thread, but I agree with the many that are
against such upgrading script.

I consider even the need for such thing a bug, as each package should
take care of its own quirks.

Besides, if something wants to mess with my system configuration, that's
an even greater bug for me (something that IME ubuntu has been doing
more and more over the last years).


I can live with an APT hook warning me if I have non-free but not
non-free-firmware, but I would prefer to even do without that.

For stable→stable updates there are the release notes for this tiny
change.
For testing/unstable users, they should really read d-d-a, and this
change be announced there (if it hasn't already).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Dmitry Baryshkov]

Hello,

вс, 2 окт. 2022 г. в 22:36, Steve Langasek :
>
> On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
> > >What's the plan for upgraded systems with an existing 
> > >/etc/apt/sources.list.
> > >Will the new n-f-f section added on upgrades automatically(if non-free was
> > >enabled before)?
>
> > So this is the one bit that I don't think we currently have a good
> > answer for. We've never had a specific script to run on upgrades (like
> > Ubuntu do), so this kind of potentially breaking change doesn't really
> > have an obvious place to be fixed.
>
> > Obviously we'll need to mention this in the release notes for
> > bookworm. Should we maybe talk about adding an upgrade helper tool?
>
> I heartily endorse ubuntu-release-upgrader, it has been useful in addressing
> uncounted upgrade issues over the years and I think something like this
> would be a nice addition to Debian as well.  Two caveats:

I'd kindly ask against additional upgrade scripts. It is too easy to
miss them, especially if one has been using Debian for ages with bare
apt-get update && apt-get dist-upgrade.
Moreover such a script will not help people that are already using testing.

For the past few decades, updating the setup was always a job of the
package scripts. Thus we potentially can have an addon in the apt's
postinstall script that will check if the user is running bookworm,
the non-free repo is enabled and non-free-firmware is not. In such
case postinst can present user with a choice of ignoring n-f-f,
attempting automatic '/bookworm/s/non-free/non-free
non-free-firmware/' or letting user to fix setup. This way the user
will be present with such choice whichever path he uses to update to
bookworm.


-- 
With best wishes
Dmitry

Re: Firmware GR result - what happens next?

[Thomas Goirand]

Hi Steve,

On 10/2/22 21:26, Steve Langasek wrote:

I heartily endorse ubuntu-release-upgrader, it has been useful in addressing
uncounted upgrade issues over the years and I think something like this
would be a nice addition to Debian as well.  Two caveats:

  - Despite this being the sanctioned upgrade path in Ubuntu for over a
decade, every single cycle we get bug reports from users who have run
into issues because they have bypassed it and done the manual sed
/etc/apt/sources.list && apt dist-upgrade.  So in Debian where this has
been the norm for /two/ decades, I would not expect this to substantially
reduce the error rate in the first release where such a mechanism is
introduced.  (After all, whether telling users to use a new upgrader tool
or telling them to manually add a component to sources.list, they will
have to read the release notes to know about it!)

  - There are always some users that end up with buggy systems after upgrade
despite using the supported interface because they upgrade to the devel
release, and the release-upgrader is still under development up until
release so they miss out on quirks being applied - and there is no
interface for users to replay the quirks that they missed out on.  Don't
repeat the same design mistake.


I very much dislike the Ubuntu approach, but not only because of the 
above. Also because this approach forgets the fact that we also maintain 
2 rolling-updates distro (testing and unstable).



In the absence of a release-upgrader, the only way I see to automate this on
upgrade would be to handle it in the maintainer scripts of either base-files
(which I don't think the base-files maintainer would like) or apt.


If the base-files maintainer (ie: Santiago Vila) doesn't like doing 
things like this in "his" package, maybe we could have base-file >> 12.2 
depend on another package (called non-free-upgrade?) that would do the 
work instead. We could even have only base-file to depend on that 
package for a single release (ie: only for the lifetime of bookworm, and 
we get rid of the package after the release).


I think that's an even better approach than having this done in 
base-files itself.


Your thoughts?

Cheers,

Thomas Goirand (zigo)

Re: Firmware GR result - what happens next?

[Thomas Goirand]

On 10/2/22 22:02, Russ Allbery wrote:

Michael Biebl  writes:


The main difference is, that the renaming caused an error message by
apt, so you knew something needed to be fixed.


One could argue that having non-free but not non-free-firmware is
sufficiently strange that it would be worth a suppressable apt warning
(that you could turn off in apt.conf).  I have no idea how easy that would
be to implement, though.


Hi!

I would very much prefer having this implemented in the base_files 
package. This is *the* package that follows releases, so that's IMO the 
best location.


I would hate having to use an upgrade program like in Ubuntu. :/

An easy check could be:
1/ are we upgrading from base-files << 12.3 (we're currently at 12.2 in Sid)
AND
2/ is there the non-free repo installed in the default sources.list
AND
3/ non-free-firmware repo isn't installed

THEN

warn user with debconf.

Checking the configuration of a non-free and non-free-firmware is kind 
of hard, because just reading/parsing source.list and source.list.d that 
could be filled with non-debian repos can be quite hard. Though we could 
imagine tricks, like where both repo would include a special package 
present only for that test, and we just see if it is available with 
apt-cache policy for example (this is just an idea... not sure if 
there's better options).


Eventually, and propose automatically adding the n-f-f repo, if some of 
you really want to, but I'd prefer if at least this could be the 
non-default debconf answer (because on non-interactive setup, without 
access to internet (only to a local mirror), this could really mess 
things up).


Your thoughts everyone?
Cheers,

Thomas Goirand (zigo)

P.S: I'm unfortunately *not* volunteering for implementing the above as 
I wont have enough time to do it properly, though I just hope my above 
suggestion helps...

Re: Firmware GR result - what happens next?

[Russ Allbery]

Michael Biebl  writes:

> The main difference is, that the renaming caused an error message by
> apt, so you knew something needed to be fixed.

One could argue that having non-free but not non-free-firmware is
sufficiently strange that it would be worth a suppressable apt warning
(that you could turn off in apt.conf).  I have no idea how easy that would
be to implement, though.

-- 
Russ Allbery (r...@debian.org)  

Re: Firmware GR result - what happens next?

[Steve Langasek]

On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
> >What's the plan for upgraded systems with an existing /etc/apt/sources.list.
> >Will the new n-f-f section added on upgrades automatically(if non-free was
> >enabled before)?

> So this is the one bit that I don't think we currently have a good
> answer for. We've never had a specific script to run on upgrades (like
> Ubuntu do), so this kind of potentially breaking change doesn't really
> have an obvious place to be fixed.

> Obviously we'll need to mention this in the release notes for
> bookworm. Should we maybe talk about adding an upgrade helper tool?

I heartily endorse ubuntu-release-upgrader, it has been useful in addressing
uncounted upgrade issues over the years and I think something like this
would be a nice addition to Debian as well.  Two caveats:

 - Despite this being the sanctioned upgrade path in Ubuntu for over a
   decade, every single cycle we get bug reports from users who have run
   into issues because they have bypassed it and done the manual sed
   /etc/apt/sources.list && apt dist-upgrade.  So in Debian where this has
   been the norm for /two/ decades, I would not expect this to substantially
   reduce the error rate in the first release where such a mechanism is
   introduced.  (After all, whether telling users to use a new upgrader tool
   or telling them to manually add a component to sources.list, they will
   have to read the release notes to know about it!)

 - There are always some users that end up with buggy systems after upgrade
   despite using the supported interface because they upgrade to the devel
   release, and the release-upgrader is still under development up until
   release so they miss out on quirks being applied - and there is no
   interface for users to replay the quirks that they missed out on.  Don't
   repeat the same design mistake.

In the absence of a release-upgrader, the only way I see to automate this on
upgrade would be to handle it in the maintainer scripts of either base-files
(which I don't think the base-files maintainer would like) or apt.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Steve McIntyre]

On Sun, Oct 02, 2022 at 11:08:47AM -0400, Michael Stone wrote:
>On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:
>> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
>> > What's the plan for upgraded systems with an existing 
>> > /etc/apt/sources.list.
>> > Will the new n-f-f section added on upgrades automatically(if non-free was
>> > enabled before)?
>> 
>> So this is the one bit that I don't think we currently have a good
>> answer for. We've never had a specific script to run on upgrades (like
>> Ubuntu do), so this kind of potentially breaking change doesn't really
>> have an obvious place to be fixed.
>
>Is there a reason to not continue to make the packages available in non-free?
>I don't see a reason to force any change on existing systems.

Two things:

 1. I'm worried what bugs we might expose by having packages be in two
components at once.
 2. I really don't like the idea of leaving two different
configurations in the wild; it'll confuse people and is more
likely to cause issues in the future IMHO.

Plus, as Shengjing Zhu points out: we already expect people to manage
the sources.list anyway on upgrades.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Re: Firmware GR result - what happens next?

[Steve McIntyre]

On Sun, Oct 02, 2022 at 05:31:16PM +0200, Cyril Brulebois wrote:
>Steve McIntyre  (2022-10-02):
>> * Extra d-i code to inform users about what firmware blobs have been
>>   loaded and the matching non-free-firmware packages. Plus information
>>   about the hardware involved. Maybe a new d-i module / udeb for this?
>>   Exact details here still TBD. Probably the biggest individual piece
>>   of work here.
>
>Not just blobs that were loaded, but also those which might get loaded
>in the installed system (since we don't have all modules around), see
>hw-detect.post-base-installer.d/50install-firmware in hw-detect (udevadm
>vs. modalias stuff).

ACK.

>> * Tweaks to add the non-free-firmware section in the apt-setup module
>>   if desired/needed.
>> 
>> * An extra boot option (a debconf variable) to disable loading extra
>>   firmware automatically, then exposed as an extra option through the
>>   isolinux and GRUB menus. d-i "expert mode" can also be used to tweak
>>   this behaviour later, except (obviously) for things like audio
>>   firmware that *must* be loaded early if they're going to be useful
>>   at all.
>
>The option/variable looks easy enough (once we decide what to call it)…
>Not sure what would be best to expose it to users: bootloader menus
>already have many options (text vs.  graphical, normal vs. rescue,
>accessibility settings, etc.), and don't get internationalization
>support anyway. On the flip side, having to go through a full expert
>installation is very nice.
>
>Maybe start by documenting the option (probably installation guide plus
>release notes), and of course implementing it; then see if/how we expose
>it?

Yup. Very much in that order... :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 

Re: Firmware GR result - what happens next?

[Michael Biebl]

Am 02.10.22 um 20:14 schrieb Luca Boccassi:

On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:



will
be very obvious.  But if you currently have non-free configured but
don't
add the new firmware section, everything will appear to work but you
won't
get new firmware, so the problem may go unnoticed.


In Bullseye we changed the name/syntax for the security repository, and
for that a mention in the release notes was enough, no? Isn't this a
very similar situation?


The main difference is, that the renaming caused an error message by 
apt, so you knew something needed to be fixed.


For this particular change, there will be no error. So yes, I have the 
same fear as Russ that this particular change might go unnoticed.



Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Re: Firmware GR result - what happens next?

[Luca Boccassi]

On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
> Shengjing Zhu  writes:
> > On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre 
> > wrote:
> 
> > > So this is the one bit that I don't think we currently have a
> > > good
> > > answer for. We've never had a specific script to run on upgrades
> > > (like
> > > Ubuntu do), so this kind of potentially breaking change doesn't
> > > really
> > > have an obvious place to be fixed.
> 
> > > Obviously we'll need to mention this in the release notes for
> > > bookworm. Should we maybe talk about adding an upgrade helper
> > > tool?
> 
> > For upgrading, people already need to edit their source list to
> > change
> > the suite name, why would it hurt to add one more manual step to
> > change
> > the section name?
> 
> I think the difference is that if you don't update your sources.list
> to
> point to the new suite, your system won't upgrade and so the problem
> will
> be very obvious.  But if you currently have non-free configured but
> don't
> add the new firmware section, everything will appear to work but you
> won't
> get new firmware, so the problem may go unnoticed.

In Bullseye we changed the name/syntax for the security repository, and
for that a mention in the release notes was enough, no? Isn't this a
very similar situation? Is it truly necessary to do more than mention
this in the release notes?

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Re: Firmware GR result - what happens next?

[The Wanderer]

On 2022-10-02 at 13:52, Russ Allbery wrote:

> Shengjing Zhu  writes:
> 
>> On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre 
>> wrote:
> 
>>> So this is the one bit that I don't think we currently have a
>>> good answer for. We've never had a specific script to run on
>>> upgrades (like Ubuntu do), so this kind of potentially breaking
>>> change doesn't really have an obvious place to be fixed.
> 
>>> Obviously we'll need to mention this in the release notes for 
>>> bookworm. Should we maybe talk about adding an upgrade helper
>>> tool?
> 
>> For upgrading, people already need to edit their source list to
>> change the suite name, why would it hurt to add one more manual
>> step to change the section name?
> 
> I think the difference is that if you don't update your sources.list
> to point to the new suite, your system won't upgrade and so the
> problem will be very obvious.  But if you currently have non-free
> configured but don't add the new firmware section, everything will
> appear to work but you won't get new firmware, so the problem may go
> unnoticed.

There's also the issue of people who track stable or testing by that
name, rather than by the release-specific codename, and so *don't* need
to edit sources.list to start getting the packages from the new release.

I don't know how many of us there are, but I know there's at least me
(for the testing case), and I'd greatly prefer to be able to run an
upgrade and have things Just Work rather than need to make sure I catch
whatever notification comes along and make that change at the right
time to coordinate with when the 'upstream' change is made.

-- 
   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: Firmware GR result - what happens next?

[Russ Allbery]

Shengjing Zhu  writes:
> On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre  wrote:

>> So this is the one bit that I don't think we currently have a good
>> answer for. We've never had a specific script to run on upgrades (like
>> Ubuntu do), so this kind of potentially breaking change doesn't really
>> have an obvious place to be fixed.

>> Obviously we'll need to mention this in the release notes for
>> bookworm. Should we maybe talk about adding an upgrade helper tool?

> For upgrading, people already need to edit their source list to change
> the suite name, why would it hurt to add one more manual step to change
> the section name?

I think the difference is that if you don't update your sources.list to
point to the new suite, your system won't upgrade and so the problem will
be very obvious.  But if you currently have non-free configured but don't
add the new firmware section, everything will appear to work but you won't
get new firmware, so the problem may go unnoticed.

-- 
Russ Allbery (r...@debian.org)  

Re: Firmware GR result - what happens next?

[Shengjing Zhu]

On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre  wrote:
>
> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
> >
> >Hi Steve,
> >
> >thanks for the update!
> >
> >Am 02.10.22 um 16:27 schrieb Steve McIntyre:
> >
> >> * Tweaks to add the non-free-firmware section in the apt-setup module
> >>if desired/needed.
> >
> >...
> >
> >> If you think I've missed anything here, please let me and Cyril know -
> >> the best place would be the mailing list
> >> (debian-b...@lists.debian.org).
> >
> >What's the plan for upgraded systems with an existing /etc/apt/sources.list.
> >Will the new n-f-f section added on upgrades automatically(if non-free was
> >enabled before)?
>
> So this is the one bit that I don't think we currently have a good
> answer for. We've never had a specific script to run on upgrades (like
> Ubuntu do), so this kind of potentially breaking change doesn't really
> have an obvious place to be fixed.
>
> Obviously we'll need to mention this in the release notes for
> bookworm. Should we maybe talk about adding an upgrade helper tool?

For upgrading, people already need to edit their source list to change
the suite name, why would it hurt to add one more manual step to
change the section name?

-- 
Shengjing Zhu

Re: Firmware GR result - what happens next?

[Cyril Brulebois]

Steve McIntyre  (2022-10-02):
> * Extra d-i code to inform users about what firmware blobs have been
>   loaded and the matching non-free-firmware packages. Plus information
>   about the hardware involved. Maybe a new d-i module / udeb for this?
>   Exact details here still TBD. Probably the biggest individual piece
>   of work here.

Not just blobs that were loaded, but also those which might get loaded
in the installed system (since we don't have all modules around), see
hw-detect.post-base-installer.d/50install-firmware in hw-detect (udevadm
vs. modalias stuff).

> * Tweaks to add the non-free-firmware section in the apt-setup module
>   if desired/needed.
> 
> * An extra boot option (a debconf variable) to disable loading extra
>   firmware automatically, then exposed as an extra option through the
>   isolinux and GRUB menus. d-i "expert mode" can also be used to tweak
>   this behaviour later, except (obviously) for things like audio
>   firmware that *must* be loaded early if they're going to be useful
>   at all.

The option/variable looks easy enough (once we decide what to call it)…
Not sure what would be best to expose it to users: bootloader menus
already have many options (text vs.  graphical, normal vs. rescue,
accessibility settings, etc.), and don't get internationalization
support anyway. On the flip side, having to go through a full expert
installation is very nice.

Maybe start by documenting the option (probably installation guide plus
release notes), and of course implementing it; then see if/how we expose
it?


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Firmware GR result - what happens next?

[Jeremy Bicha]

On Sun, Oct 2, 2022 at 10:53 AM Steve McIntyre  wrote:
> On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
> >What's the plan for upgraded systems with an existing /etc/apt/sources.list.
> >Will the new n-f-f section added on upgrades automatically(if non-free was
> >enabled before)?
>
> So this is the one bit that I don't think we currently have a good
> answer for. We've never had a specific script to run on upgrades (like
> Ubuntu do), so this kind of potentially breaking change doesn't really
> have an obvious place to be fixed.

There is /etc/apt/sources.list.d/ . One idea is that you could have a
package install a non-free-firmware apt source line there without
needing to touch anyone's primary /etc/apt/sources.list

I'm guessing things that change apt sources for mirrors would need to
be able to handle that file, but maybe they needed to handle
sources.list.d/ anyway.

Thank you,
Jeremy Bicha

Re: Firmware GR result - what happens next?

[Michael Stone]

On Sun, Oct 02, 2022 at 03:53:00PM +0100, Steve McIntyre wrote:

On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:

What's the plan for upgraded systems with an existing /etc/apt/sources.list.
Will the new n-f-f section added on upgrades automatically(if non-free was
enabled before)?


So this is the one bit that I don't think we currently have a good
answer for. We've never had a specific script to run on upgrades (like
Ubuntu do), so this kind of potentially breaking change doesn't really
have an obvious place to be fixed.


Is there a reason to not continue to make the packages available in 
non-free? I don't see a reason to force any change on existing systems.

Re: Firmware GR result - what happens next?

[Steve McIntyre]

On Sun, Oct 02, 2022 at 04:43:47PM +0200, Michael Biebl wrote:
>
>Hi Steve,
>
>thanks for the update!
>
>Am 02.10.22 um 16:27 schrieb Steve McIntyre:
>
>> * Tweaks to add the non-free-firmware section in the apt-setup module
>>if desired/needed.
>
>...
>
>> If you think I've missed anything here, please let me and Cyril know -
>> the best place would be the mailing list
>> (debian-b...@lists.debian.org).
>
>What's the plan for upgraded systems with an existing /etc/apt/sources.list.
>Will the new n-f-f section added on upgrades automatically(if non-free was
>enabled before)?

So this is the one bit that I don't think we currently have a good
answer for. We've never had a specific script to run on upgrades (like
Ubuntu do), so this kind of potentially breaking change doesn't really
have an obvious place to be fixed.

Obviously we'll need to mention this in the release notes for
bookworm. Should we maybe talk about adding an upgrade helper tool?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back

Starting the firmware GR - see mail on d-vote

[Steve McIntyre]

Hi all!

Sorry for the delay on this, I've been really really busy. :-(

I think it's time we started on the firmware GR, so I've mailed the
-vote list:

  https://lists.debian.org/debian-vote/2022/08/msg1.html

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone

Re: The firmware GR

[Don Armstrong]

On Mon, 15 Dec 2008, Ben Finney wrote:
 Romain Beauxis to...@rastageeks.org writes:
  Unfortunately you forgot to also mention this bug for instance:
  
http://bugs.debian.org/494120
 
 Which has been prematurely archived on 2008-08-15 while in
 mid-discussion, by one party in that discussion.

Uh... it was archived on 2008/09/6 by the BTS itself after the bug had
been closed on 2008/8/7 and the last message was on 2008/8/8.

So no, it wasn't prematurely archived, and more than 28 days with no
discussion certainly is not mid-discussion.


Don Armstrong

-- 
I was thinking seven figures, he said, but I would have taken a
hundred grand. I'm not a greedy person. [All for a moldy bottle of
tropicana.]
 -- Sammi Hadzovic [in Andy Newman's 2003/02/14 NYT article.]
 http://www.nytimes.com/2003/02/14/nyregion/14EYEB.html

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: The firmware GR

[Ben Finney]

Don Armstrong d...@debian.org writes:

 On Mon, 15 Dec 2008, Ben Finney wrote:
  Romain Beauxis to...@rastageeks.org writes:
 http://bugs.debian.org/494120
  
  Which has been prematurely archived on 2008-08-15 while in
  mid-discussion, by one party in that discussion.
 
 Uh... it was archived on 2008/09/6 by the BTS itself after the bug
 had been closed on 2008/8/7 and the last message was on 2008/8/8.

I checked carefully before sending the above message; the dates on the
bug discussion and control messages *were* as I described. Yet today,
they're as you describe. I have no ready explanation for that
discrepancy.

This thread certainly isn't the place to discuss strange observed
debbugs behaviour, though, so I'll leave it at that for now.

-- 
 \ “I object to doing things that computers can do.” —Olin Shivers |
  `\   |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

The firmware GR

[Robert Millan]

Hi,

I don't think d-d-a is meant to be used as a forum, but since others are
doing so, I guess it's fine if I join.

 With these hopefully solid plans in place for the release, we feel the
 need to acknowledge that there is an ongoing vote whose outcome could
 potentially disrupt them.

Luk is referring to 11 bugs in linux-2.6 which all have a 'patch' tag, and
which the maintainers have been ignoring so far.  Option 1 wouldn't cause any
disruption to the release process, other than moving support for these chips
to non-free when the patches are applied.  Any other delay is self-imposed.

  http://bugs.debian.org/494007
  http://bugs.debian.org/494009
  http://bugs.debian.org/494010
  http://bugs.debian.org/494308
  http://bugs.debian.org/501152
  http://bugs.debian.org/501153
  http://bugs.debian.org/502663
  http://bugs.debian.org/502665
  http://bugs.debian.org/502666
  http://bugs.debian.org/502667
  http://bugs.debian.org/502669

I hope this helps everyone pick the options they feel most comfortable with.

Sincerely,

-- 
Robert Millan

  The DRM opt-in fallacy: Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all.


signature.asc
Description: Digital signature

Re: The firmware GR

[Ben Hutchings]

On Mon, 2008-12-15 at 10:36 +0100, Robert Millan wrote:
 Hi,
 
 I don't think d-d-a is meant to be used as a forum, but since others are
 doing so, I guess it's fine if I join.
 
  With these hopefully solid plans in place for the release, we feel the
  need to acknowledge that there is an ongoing vote whose outcome could
  potentially disrupt them.
 
 Luk is referring to 11 bugs in linux-2.6 which all have a 'patch' tag, and
 which the maintainers have been ignoring so far.
[...]

This is partly because they've had very little testing.  Some of the
testing showed serious bugs, which I believe I have now fixed, but
others may well still be present.

Again, for anyone who wants to test the latest versions of these patches
(which I have not mailed individually to the bugs, sorry), see
http://people.debian.org/~benh/firmware-removal/

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of incompetence.


signature.asc
Description: This is a digitally signed message part

Re: The firmware GR

[Ben Hutchings]

On Mon, 2008-12-15 at 10:54 +0100, Romain Beauxis wrote:
 Le Monday 15 December 2008 10:36:50 Robert Millan, vous avez écrit :
   With these hopefully solid plans in place for the release, we feel the
   need to acknowledge that there is an ongoing vote whose outcome could
   potentially disrupt them.
 
  Luk is referring to 11 bugs in linux-2.6 which all have a 'patch' tag, and
  which the maintainers have been ignoring so far.  Option 1 wouldn't cause
  any disruption to the release process, other than moving support for
  these chips to non-free when the patches are applied.  Any other delay is
  self-imposed.
 
 Unfortunately you forgot to also mention this bug for instance:
 
   http://bugs.debian.org/494120

There's no reason to think that the array in question is not the
preferred form for modification.

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of incompetence.


signature.asc
Description: This is a digitally signed message part

Re: Purpose of devel-announce (Re: The firmware GR)

[Kalle Kivimaa]

Kalle Kivimaa kil...@debian.org writes:
 Please refrain from using the absolutely wrong list for your own
 political purposes in the future.

As Cyril already pointed out, Robert's post was to the devel, not to
the devel-announce, so please ignore my outburst. Sorry for the noise.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: The firmware GR

[Cyril Brulebois]

Robert Millan r...@aybabtu.com (15/12/2008):
 I don't think d-d-a is meant to be used as a forum, but since others
 are doing so, I guess it's fine if I join.

Thankfully, replies to mail sent to dda@ land in d...@. You fail.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Purpose of devel-announce (Re: The firmware GR)

[Cyril Brulebois]

Kalle Kivimaa kil...@debian.org (15/12/2008):
 As Cyril already pointed out, Robert's post was to the devel, not to
 the devel-announce, so please ignore my outburst. Sorry for the noise.

No no, you were right:
| From: Robert Millan r...@aybabtu.com
| To: debian-devel-annou...@lists.debian.org

But the lists are configured in a way that doesn't let that happen; I
was only pointing that Robert even failed abusing the system.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: The firmware GR

[Ben Finney]

Romain Beauxis to...@rastageeks.org writes:

 Unfortunately you forgot to also mention this bug for instance:
 
   http://bugs.debian.org/494120

Which has been prematurely archived on 2008-08-15 while in
mid-discussion, by one party in that discussion.

-- 
 \“There are no significant bugs in our released software that |
  `\ any significant number of users want fixed.” —Bill Gates, |
_o__)   1995-10-23 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Purpose of devel-announce (Re: The firmware GR)

[Kalle Kivimaa]

Robert Millan r...@aybabtu.com writes:
 I don't think d-d-a is meant to be used as a forum, but since others are
 doing so, I guess it's fine if I join.

Mmm, who is doing so? Do you mean the release team update? If so, I
don't think the update qualifies as using devel-announce as a forum.
And even if it does, that does NOT excuse your misuse of it.

Please refrain from using the absolutely wrong list for your own
political purposes in the future.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: The firmware GR

[Romain Beauxis]

Le Monday 15 December 2008 10:36:50 Robert Millan, vous avez écrit :
  With these hopefully solid plans in place for the release, we feel the
  need to acknowledge that there is an ongoing vote whose outcome could
  potentially disrupt them.

 Luk is referring to 11 bugs in linux-2.6 which all have a 'patch' tag, and
 which the maintainers have been ignoring so far.  Option 1 wouldn't cause
 any disruption to the release process, other than moving support for
 these chips to non-free when the patches are applied.  Any other delay is
 self-imposed.

Unfortunately you forgot to also mention this bug for instance:

  http://bugs.debian.org/494120


Romain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: The firmware GR

[Kurt Roeckx]

On Mon, Dec 15, 2008 at 10:36:50AM +0100, Robert Millan wrote:
 
 Hi,
 
 I don't think d-d-a is meant to be used as a forum, but since others are
 doing so, I guess it's fine if I join.
 
  With these hopefully solid plans in place for the release, we feel the
  need to acknowledge that there is an ongoing vote whose outcome could
  potentially disrupt them.
 
 Luk is referring to 11 bugs in linux-2.6 which all have a 'patch' tag, and
 which the maintainers have been ignoring so far.  Option 1 wouldn't cause any
 disruption to the release process, other than moving support for these chips
 to non-free when the patches are applied.  Any other delay is self-imposed.
 
   http://bugs.debian.org/494007
   http://bugs.debian.org/494009
   http://bugs.debian.org/494010
   http://bugs.debian.org/494308
   http://bugs.debian.org/501152
   http://bugs.debian.org/501153
   http://bugs.debian.org/502663
   http://bugs.debian.org/502665
   http://bugs.debian.org/502666
   http://bugs.debian.org/502667
   http://bugs.debian.org/502669
 
 I hope this helps everyone pick the options they feel most comfortable with.

There are currently 31 bugs marked lenny-ignore.  As I understand things,
if option 1 makes it all those 31 need to be fixed before we can release
lenny.

Here is the list of bugs and the packages:
 211765 | xorg-server
 368559 | x11proto-gl
 368564 | xorg-server
 382175 | glibc
 383465 | xserver-xorg-video-nv
 391935 | xen-3
 424957 | portmap
 445507 | mklibs
 459705 | pike7.6
 477060 | texlive-base
 477751 | sgml-base
 483217 | texlive-base
 488895 | lucene2
 491354 | texlive-extra
 492699 | fakeroot
 494007 | linux-2.6
 494009 | linux-2.6
 494010 | linux-2.6
 494308 | linux-2.6
 495256 | cacao-oj6
 498475 | net-snmp
 498476 | libsmi
 498631 | linux-2.6
 501152 | linux-2.6
 501153 | linux-2.6
 502663 | linux-2.6
 502665 | linux-2.6
 502666 | linux-2.6
 502667 | linux-2.6
 502668 | linux-2.6
 502669 | linux-2.6


Note that 2 of them (488895 - lucene2, 495256 - cacao-oj6) have been
fixed in unstable but not in lenny.


Kurt


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: The firmware GR

[Paul Wise]

On Tue, Dec 16, 2008 at 4:21 AM, Kurt Roeckx k...@roeckx.be wrote:

 There are currently 31 bugs marked lenny-ignore.  As I understand things,
 if option 1 makes it all those 31 need to be fixed before we can release
 lenny.

Some of these are technical issues rather than DFSG issues, so aren't
relevant to the GR.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

position statement from the kernel team over the current non-free firmware GR vote (Was: Call for votes for GR: : Handling source-less firmware in the Linux kernel)

[Sven Luther]

Hello,

The kernel team consider that neither of the two proposals currently under
vote [1] are a good solution to the non-free firmware problem. Furthermore, 
a consensual proposal has now reached enough seconds [2] to be put to vote,
and is much preferable, both in clearness of text as in actual content. 

The proposal made by Josselin (Choice 2) will have a hard time to pass,
as it needs 3:1 supermajority. It gives a longer term exception for
firmwares beyond the etch release, which we believe not being necessary,
and furthermore, it is an amendment to the original proposal from Steve,
now withdrawn, and is thus less clean.

The proposal originally from Frederik as amended by Manoj (Choice 1) has
serious issues. It doesn't correspond to the wish of the kernel team,
as expressed by the position statement at [3] following the kernel team
meeting about the firmware issue. This proposal is titled : Choice 1:
Release Etch even with kernel firmware issues but this is highly
misleading, since the actual proposal in many ways contradicts this.
The proposal states : 

  1. It forces us to not release as part of etch those firmwares removed
 in sarge, which include popular drivers used for installation as tg3
 and acenic (Point 3.).

  2. It means illegal to distribute firmwares will have to go (good),
 altough it is silent about the sourceless GPL ones (Point 4.).

  3. It means we will not distribute firmwares with non-DFSG free licenses
 (Point 4.). This is highly confusing, because the distinction is made
 on the licenses, and not on the actual freeness, and it thus favours
 firmwares under free licenses, but not respecting the terms of the
 licenses, over those firmwares whose copyright holder has clarified
 their licensing, like broadcom did for the tg3 license.

Furthermore, the current choice 1, which will allow to ship sourceless GPLed
firmwares, should have needed a 3:1 supermajority, as it directly contradicts
the DFSG.

For all these reasons, the kernel team believes that the solution proposed
at [3], and which already reached enough seconds, and will thus be needed
to be voted on, is a better solution, and since it is not possible anymore
to amend the current ballot, we urge all voters to vote Further Discussion,
and allow for the recast of a new ballot containing the better solution, and
possible other amendments (like a rewording of Josselin's proposal on top of
the consensual proposal for example).

On behalf of the Debian Kernel Team, 

Friendly,

Sven Luther

  [1] - http://www.debian.org/vote/2006/vote_007
  [2] - http://lists.debian.org/debian-vote/2006/10/msg00183.html
  [3] - 
http://wiki.debian.org/KernelFirmwareLicensing#head-98e7641feaea08b775f4d5c58d071b77ff172c90


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]