[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Requesting Extension (was: Re: Changing how we handle non-free firmware)

Dear Debian Secretary and Debian Developers

As per the Debian Constitution[1] (4.2¶3), I'm requesting an extension for the discussion period of 7 days.

Apologies for jumping this on the last minute, I've been off-sick and have been fiercely triaging and catching up with issues the last day or so.

My rationale is that we have some unresolved issues that I think would be prudent to consider before the vote.

For one, some of the options may put some pressure on individuals or teams to implement some features at the wish of the project. We've already had (and even recently) situations like this that caused a lot of friction. So, I believe it would be worth while to discuss how we want to treat this specifically for the next releases. What happens if we decide on an option for Bookworm, and the implementation is nowhere ready by, say, August next year, do we delay the release? Or aim for Bookworm but make it RC for Trixie? Even if we have some consensus about how to address that and the details don't make it in the actual vote, it would still be an improvement.

Other than that, we may have to accept the fact that this GR won't be (and possibly can't be) perfect and that we'll have to apply some touch-ups based on our experiences and further conclusions based on that, and improve upon it again by another GR some time in the future. In the meantime, I think another week of polish will be worth it over the bookworm release cycle, and I'm glad that this topic is at least moving forward and that we get to make some choices together as a project regarding firmware.

Thanks for understanding,


[1] https://www.debian.org/devel/constitution

On 2022/08/18 21:58, Steve McIntyre wrote:
Hi a11!

I'm proposing to change how we handle non-free firmware in
Debian. I've written about this a few times already this year [1, 2]
and I ran a session on the subject at DebConf [3].
TL;DR: The way we deal with (non-free) firmware in Debian isn't
great. For a long time we've got away without supporting and including
(non-free) firmware on Debian systems. We don't *want* to have to
provide (non-free) firmware to our users, and in an ideal world we
wouldn't need to. However, it's no longer a sensible path when trying
to support lots of common current hardware. Increasingly, modern
computers don't function fully without these firmware blobs.

Since I started talking abbout this, Ansgar has already added dak
support for a new, separate non-free-firmware component - see
[4]. This makes part of my original proposal moot! More work is needed
yet to make use of this support, but it's started! :-)

I believe that there is reasonably wide support for changing what we
do with non-free firmware. I see several possible paths forward, but
as I've stated previously I don't want to be making the decision
alone. I believe that the Debian project as a whole needs to make the
decision on which path is the correct one.

I'm *not* going to propose full text for all the possible choices
here; as eloquently suggested by Russ [5], it's probably better to
leave it for other people to come up with the text of options that
they feel should also be on the ballot.

So, I propose the following:


We will include non-free firmware packages from the
"non-free-firmware" section of the Debian archive on our official
media (installer images and live images). The included firmware
binaries will *normally* be enabled by default where the system
determines that they are required, but where possible we will include
ways for users to disable this at boot (boot menu option, kernel
command line etc.).

When the installer/live system is running we will provide information
to the user about what firmware has been loaded (both free and
non-free), and we will also store that information on the target
system such that users will be able to find it later. The target
system will *also* be configured to use the non-free-firmware
component by default in the apt sources.list file. Our users should
receive security updates and important fixes to firmware binaries just
like any other installed software.

We will publish these images as official Debian media, replacing the
current media sets that do not include non-free firmware packages.


A reason for defaulting to installing non-free firmware *by default*
is accessibility. A blind user running the installer in text-to-speech
mode may need audio firmware loaded to be able to drive the installer
at all. It's going to be very difficult for them to change this. Other
people should be able to drive the system (boot menus, etc.) to *not*
install the non-free firmware packages if desired.

We will *only* include the non-free-firmware component on our media
and on installed systems by default. As a general policy, we still do
not want to see other non-free software in use. Users may still enable
the existing non-free component if they need it.

We also need to do the work to make this happen:

  * in d-i, live-boot and elsewhere to make information about firmware

  * add support for the non-free-firmware section in more places:
    ftpsync, debian-cd and more.

and I plan to start on some of those soon.

[1] https://blog.einval.com/2022/04/19#firmware-what-do-we-do
[2] https://lists.debian.org/debian-devel/2022/04/msg00130.html
[3] https://debconf22.debconf.org/talks/43-fixing-the-firmware-mess/
[4] https://incoming.debian.org/debian-buildd/dists/buildd-unstable
[5] https://lists.debian.org/debian-devel/2022/04/msg00214.html

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply to: