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?

[Cyril Brulebois]

Pascal Hambourg  (2022-10-13):
> What about firmware not available in Debian packages ? For example
> Prims54 wireless adapters using p54pci and p54usb drivers included
> in nic-wireless-modules-*-di need firmware unavailable in Debian
> packages.

As far as I understand it, they can be packaged once their
redistributability is clarified?


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


signature.asc
Description: PGP signature