Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)

[Tobias Frost]

On Fri, Apr 05, 2024 at 12:37:19PM +0200, Andreas Tille wrote:
> Hi Tobias,
> 
> Am Thu, Apr 04, 2024 at 07:59:56PM +0200 schrieb Tobias Frost:
> > 
> > There is the possilbity to salavage the packagei [1], but that of course 
> > will
> > only work if the person agrees to take over maintainance and add their name 
> > to
> > Uploaders: or Maintainer: [2]. 
> 
> I want to be able to immediately respond to future problems in this
> package.  I'm fine with putting Debian Med team as maintainer, but not
> my personal ID (maximum as Uploader since I do not have any personal
> packages).
> 
> Do you think this would be the appropriate action (which I personally
> would even prefer over debian/ space)?  The conservative criteria
> are fulfilled.

Yes, (if your name is in Uploaders:) this is is fine.

> Kind regards
>Andreas.
> 
> > The package can be put into a team's umbrella at the ITS time.  This
> > does not need an explicit OK, though the maintainer can veto.
> > 
> > [1] 
> > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> > https://wiki.debian.org/PackageSalvaging
> > 
> > [2] This is a feature, the ITS procedure has been designed exactly that
> > way, to avoid that people just do an upload and drop the package
> > immediatly afterwards, as this will likely only upset the current
> > maintainer without long-term benefits to the package - kind of to
> > avoid the reaction Marc predicted.
> > If taking over the maintaince is not the goal, remember NMU allow
> > one to fix almost every bug, also wishlist bugs are regularily in
> > scope. And bugs can be filed, if needed. 
> > Some Background story: 
> > https://lists.debian.org/debian-devel/2018/07/msg00453.html
> > 
> > --  
> > tobi
> 
> 
> 
> -- 
> https://fam-tille.de
> 


signature.asc
Description: PGP signature

Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)

[Tobias Frost]

Hi Andreas,

On Thu, Apr 04, 2024 at 02:32:45PM +0200, Andreas Tille wrote:
> Hi,
> 
> in the light of the previous discussion I have a question to all voters.
> Due to bug #1066377 more than 30 testing removal warnings hit my mailbox
> today (I stopped counting after 30).  While the Debian Med package
> clustalo is the only package that's responsible for this due to its
> Build-Dependency from libargtable2-dev there is quite some dependency
> tree inside Debian Med team also affecting packages relevant for
> COVID-19 etc.  This small lib is not a key package which is important
> for all things I'm writing below.  Its used as Build-Depends by 6 other
> packages.
> 
> Our always busy team member Étienne Mollier provided a patch 10 days ago
> (thanks again Étienne).  The package had its last maintainer Upload
> 
>  -- Shachar Shemesh   Sat, 16 Jul 2016 20:45:15 +0300
> 
> (Shachar in CC) and a NMU
> 
>  -- Holger Levsen   Fri, 01 Jan 2021 17:15:04 +0100
> 
> (reproducible build, no changes - in other words no problems since
> 2016).  However, the BTS view of Sanchar might hinting for some
> inactivity when looking at two RC bugs in other packages:
> 
>   #965787 privbind: Removal of obsolete debhelper compat 5 and 6 in bookworm
>   #998987 [src:privbind] privbind: missing required debian/rules targets 
> build-arch and/or build-indep
> 
> As I wrote to Marc here on this list also the explicit hint to Shachar:
> Its not about blaming you - I just want to analyse the current situation
> to act properly.  Given that you had no capacity to respond to two bugs
> that are RC since 2 years makes me wonder how long I need to wait for
> your OK to a team upload I'm proposing below.  I'm perfectly aware that
> we as volunteers can't be blamed about those things.  I simply want to
> find new ways how to deal with those situations appropriately.

There is the possilbity to salavage the packagei [1], but that of course will
only work if the person agrees to take over maintainance and add their name to
Uploaders: or Maintainer: [2]. 
The package can be put into a team's umbrella at the ITS time.  This
does not need an explicit OK, though the maintainer can veto.

[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
https://wiki.debian.org/PackageSalvaging

[2] This is a feature, the ITS procedure has been designed exactly that
way, to avoid that people just do an upload and drop the package
immediatly afterwards, as this will likely only upset the current
maintainer without long-term benefits to the package - kind of to
avoid the reaction Marc predicted.
If taking over the maintaince is not the goal, remember NMU allow
one to fix almost every bug, also wishlist bugs are regularily in
scope. And bugs can be filed, if needed. 
Some Background story: 
https://lists.debian.org/debian-devel/2018/07/msg00453.html

--  
tobi


signature.asc
Description: PGP signature

Re: new proposal: free and and non-free installers with SC change

[Tobias Frost]

On Wed, Sep 14, 2022 at 03:00:26PM +, Holger Levsen wrote:
> hi,
> 
> I'm looking seconds for this new proposal below, which is like
> proposal E plus *also* offering free installer image.
> 
> Rationale: we should keep producing fully freely distributable 
> Debian installer images, for those cases were some included non-free
> stuff else might limit distribution, eg to Iran or Cuba etc or
> by imposing other restrictions...!
> 
> 
> -
> Proposal F
> 
> This ballot option supersedes the Debian Social Contract (a foundation 
> document) under point 4.1.5 of the constitution and thus requires a 3:1 
> majority.
> 
> The Debian Social Contract is replaced with a new version that is identical 
> to the current version in all respects except that it adds the following 
> sentence to the end of point 5:
> 
> The Debian official media may include firmware that is otherwise not
> part of the Debian system to enable use of Debian with hardware that
> requires such firmware.
> 
> The Debian Project also makes the following statement on an issue of the day:
> 
> 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. Where non-free firmware is found to be necessary, 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, alongside the current 
> media sets that do not include non-free firmware packages.
> 
> ---
> 
> (This is exactly "Proposal E" as found on 
> https://www.debian.org/vote/2022/vote_003
> now, except that in the very last sentence the word "replacing" has
> been replaced with "alongside".)
> 

Thanks, Holger!
Seconded.


signature.asc
Description: PGP signature

Re: Possible draft non-free firmware option with SC change

[Tobias Frost]

On Tue, Sep 13, 2022 at 07:10:24PM +, Bill Allombert wrote:
> Le Tue, Sep 13, 2022 at 02:37:49PM +, Bill Allombert a écrit :
> > Le Tue, Sep 13, 2022 at 11:56:07AM +0500, Andrey Rahmatullin a écrit :
> > > Do you too agree with the position that having non-free firmware stored in
> > > your hardware is better than having it loaded from your OS?
> > 
> > My position is that the laws governing embedded firmware are much
> > more favorable to the users than the laws governing freestanding
> > firmware. 
> 
> To gives a random example: firmware-iwlwifi 
> (by the way the link in packages.d.o to the copyright file does not work
> https://metadata.ftp-master.debian.org/changelogs//non-free/f/firmware-nonfree/firmware-nonfree_20210315-3_copyright
> return 404
> )
> 
> * No reverse engineering, decompilation, or disassembly of this software
>   is permitted.
> 
> This would not be legal for embedded firmware

Reverse engineering is legal in some legislation and certain circumstances.
This conditions could be void in those legislations.
For example, I've read articles about the German GeschGehG, implementing
EU Regulation 2016/943, which indicates that it might not be possible to 
restrict
the right for reverse engineering contractually, especially if the product is
available to the public.

Often, embedded firmware is protected to be read from its flash memory.
Circumventing technical protecions is often illegal.
 
>  THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
>  FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED
> 
> You cannot disclaim warranty on hardware. You have to provide statutory
> warranty.

You can't disclaim statutory warranty, regardless if its hardware or software.

However, you can write a lot of sentences in your licenses, even some sentences
which are legally ineffective…

Disclaimer: IANAL. This is not legal advice, but my oppinion.

-- 
tobi

Re: Possible draft non-free firmware option with SC change

[Tobias Frost]

On Tue, Sep 13, 2022 at 07:29:05AM +0200, Simon Josefsson wrote:
 
> My reason for using Debian is that I can rely on getting a 100% free
> system, and then add non-free works on top of it when I chose to do so.
> 
> For example, I install the firmware-iwlwifi package on my laptop because
> I haven't been bothered to replace the wifi module with an Atheros wifi
> module yet, even though I bought it five years ago.  This flexibility
> suits me well, and it does not seem to be in conflict with the
> flexibility you appear to desire: using a non-free installer to install
> these things automatically for you.  My flexibility will no longer be
> permitted by Proposal A and E.

As you keep repeating that:
Proposal A and E explictly states:

  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.).**

You still have the flexibilty. You still can make the non-free firmware inert 
bits.
The installer will still not *require* these bits to function.

 
> /Simon




signature.asc
Description: PGP signature

Re: Possible draft non-free firmware option with SC change

[Tobias Frost]

On Sun, Sep 11, 2022 at 08:19:26AM +0200, Simon Josefsson wrote:
> Paul Wise  writes:
> 
> > On Sat, 2022-09-10 at 09:16 +0200, Simon Josefsson wrote:
> >
> >> So the practical problems facing people requiring non-free software
> >> appears solved or possible to solve.
> >
> > As I understand it there are two problems solved by proposal A/E:
> >
> > Users who aren't aware of the firmware problem are directed by the
> > Debian website to download the free installer, they try it out, find it
> > doesn't work on their hardware and then abandon Debian in favour of
> > other distros, or ask questions about it to the Debian support channels
> > or the Debian teams involved in the image creation/distribution. They
> > always get the non-free installer eventually, but we have wasted their
> > time and ours by directing them to the free installer by default.
> >
> > Since the hardware most users use causes the first problem, the people
> > fielding these support requests see that the free installer is in most
> > cases not useful and therefore want to stop building or working on it.
> 
> The problem is caused by hardware manufacturer chosing to require
> non-free works for their use.  The blame for that choice lies on the
> hardware manufacturer, not on Debian.  Accepting the blame for someone
> else's choices and taking on the responsibility solve the consequences
> of that choice seems misguided to me.  It makes it harder for users to
> experience the frustration of such hardware themselves.

How does frustation or blaming manufactores help our users?

Also, our users will not blame the manufactores. They blame us.

BTW, about choices…
Especially for (modern) Wifi hardware, there is legistlation in place that
forbids manufactores to enable users to operate outside of RF complicance.
(e.g. Tx Power, DFS). This is usually done in the firmware.

You can't expect manufactores to break regolatory rules, they do not
have the option to choose.

Sure, *some* parameters might be limitable by hardware design, but that
is generally costier. And as it is *some* parameters, not *all*, this won't
make the device compliant.
Additionally, ithey dont really have incentives to let their competitors
look into their code. Another incentive NOT to open up firmware is that
this would actually cost them money to do so and maybe make the liable
if a competitor detects that some code violates some IP…

> I disagree they
> always get the non-free installer eventually: some end up learning about
> the problem and chose better hardware.  Some end up reverse engineering
> their hardware, and contributing to a free solution.  Some dislike other
> distributions taking a less rigid stance on non-free works, and will
> come up with work-arounds to get Debian to work on the hardware.  If
> Debian takes on itself to solve the problems with non-free hardware, I
> think we are in more difficult position to ask for a change.

The thing I experience on some of our channels where many (potential) users
are:
 - Can't install, $network not detected.
 - Installed it, network stopped working.
 - They usually pointed to use the non-free installer as first response.
   This is when they are in Debian channels.
 - In non-Debian forums, the response is too often:
- Debian sucks. Just use another distro.
- Especially for gaming


Is this helping our users or does it help the free software cause if those
users just go somewhere else and asscociate Debian with "broken"?
Those are lost users, and they will never learn and then care about their
missing freedoms.

Yes, the situation could be better, but re-inforcing the current situation 
won't improve that. We tried that for a very long time already.


-- 
tobi

Re: Possible draft non-free firmware option with SC change

[Tobias Frost]

On Wed, Sep 07, 2022 at 10:48:36AM -0700, Russ Allbery wrote:
> Between one thing and another I've not been tracking the timeline of this
> vote and I'm worried we may be out of time for new ballot options and
> possibly extensions.
> 
> (As promised in the previous vote for changing the timing of GRs, I've
> been watching the timing closely and the last couple have felt rushed.
> When there's a quiet period, I'm considering proposing a small
> constitutional amendment to relax the timelines a bit based on that
> experience.  But we can discuss that separately.)
> 
> If there is time left, though, I'm considering proposing the following
> option based on my earlier message, just so that there's something on the
> ballot that explicitly modifies the Social Contract to allow for non-free
> firmware, in case people want that for clarity.
> 
> I should stress that I'm not involved in this part of Debian directly and
> am not a great choice for a proponent, so I'd be happy if someone else
> took that over, but it does feel to me like it would be good to have this
> explicitly on the ballot.
> 
> Possible wording, which includes the existing option A verbatim:
> 
> --
> 
> This ballot option supersedes the Debian Social Contract (a foundation
> document) under point 4.1.5 of the constitution and thus requires a 3:1
> majority.
> 
> The Debian Social Contract is replaced with a new version that is
> identical to the current version in all respects except that it adds the
> following sentence to the end of point 5:
> 
> The Debian official media may include firmware that is otherwise not
> part of the Debian system to enable use of Debian with hardware that
> requires such firmware.
> 
> The Debian Project also makes the following statement on an issue of the
> day:
> 
> 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. Where non-free firmware is found to be
> necessary, 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.
> 
> -- 
> Russ Allbery (r...@debian.org)  

Seconded.



signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Tobias Frost]

Hi Steve,

On Fri, Sep 02, 2022 at 09:14:53PM +0200, Kurt Roeckx wrote:
> On Tue, Aug 30, 2022 at 03:11:25PM -0500, Richard Laager wrote:
> > 
> > > I like to discussion about anything related to this, so that I can at
> > > least get an idea what the consensus is.
> > 
> > DSC 1 and DSC 5 have some implications about "the Debian system" vis-a-vis
> > non-free, but the plan here is to keep the firmware in a separate
> > non-free-firmware analogous to non-free. That seems fine to me.
> > 
> > DSC 1 says we will never "require the use of a non-free component". To me,
> > this is the major relevant issue.
> > 
> > Proposals B and C offer users the explicit choice of media. That feels
> > clearly compatible with the DSC, as users are not required to use non-free
> > bits.
> > 
> > Proposal A will use non-free-firmware by default, but "where possible...will
> > include ways for users to disable this". Without the "where possible", I
> > think this opt-out is compatible with the DSC. However, if it is not
> > possible to disable the non-free-firmware, then it feels like the system is,
> > in fact, requiring it. Thus this option, as worded, feels potentially
> > incompatible with the DSC.
> 
> It that it says "at boot". That seems to imply that it will get
> installed, but it might not get used, which might at least surprise
> some people. But maybe that's only for the live images.
> 
> Note that the SC only says: "require the use of a non-free component".
> This can be interpreted as having it installed is not a problem as
> long as it's not used.
> 
> I think there are people that want to use the official image but don't
> want anything non-free installed, nor want it in the sources.list file.
> So they might want to have an installer that supports that.
> 
> So I think I have to agree that the "where possible" is probably not
> compatible with the SC. I think it should be more explicit that it will
> be possible to disable the use of non-free firmware.
> 
> SC #5 says that contrib and non-free is not part of the Debian system.
> But talks about CDs that can include such packages. It seems that we
> find it acceptable that installation and live media contains non-free
> software. But clearly there are people who don't agree with this.
> 
> Other questions I still have:
> - Can a GR overrule the SC without explicitly saysing so, and does it
>   then need a 3:1 super majority? Currently I think it should explicitly
>   change the SC.
> - Is opt-out good enough, or does it need to be opt-in?
> - Does SC #5 need to be changes since we're adding a non-free-firmware
>   section?
> 
> I will likely say that option A is not compatible with the SC and
> invalid. Please either change the text, or try to convince me otherwise.
> I did not see any arguments of why it would not conflict.
> 

I think that "where possible" is aimed towards that there might be systems that
won't boot (properly) anymore, or possibly the system would not be usable for
some people (e.g people requiring TTS), so it could be hard for them to
actually disable them.

Disabling _might_ be even impossible during boot, if those bits are required so
early in the boot process that there is no way to intervene. (e.g Raspberry Pi)

Steve, to fix the concerns by Kurt, would you accept some changes

- to remove the words "where possible"
- and change the next sentence to:
  "When the installer/live system is running we will provide
   informationa to the user about what firmware has been loaded (both
   free and non-free) and offer to abort the installation if non-free
   firmare has been loaded. And we will also …"

(please rephrase as you see appropiate; English is not my native
language and I might have missed subtlities in my wording…)

My rationale for the second sentence is:

(I first had this version in mind, to be added to the sentence that has
the "where possible: I quote that now because I believe that makes it
clearer what I have in mind, but I believe the proposoal above is more
practical:
 "Where disabling the firmware is not possible or feasible, (e.g it is
 required to boot the system/installer, required by active accessiblity
 features, etc), we will inform the user about this, and offer to abort
 the installation.")

- if there is a system that won't work without firemware, there won't be
  a usable free installer for them, so for people who care, the only
  option will be not using that system, so we should give them this
  option as well at all. At that point, everything happended in RAM, so
  aborting the installation will return to the previous state of the
  device, without any permanent modifications.
- people might not be able to make this decission before they have
  actually loaded firmware. IIUIC for TTS systems, some AMD APU won't
  display *anything* without firmware… So a chicken-egg problem; with the
  second sentence they'll explicitly get a "you do not have to…" option.

I changed my original sentence, because I'm not sure if 

Re: Changing how we handle non-free firmware

[Tobias Frost]

On Mon, Aug 22, 2022 at 12:32:54PM -0500, Gunnar Wolf wrote:
> I hereby propose the following alternative text to Steve's original
> proposal.
> 
> I'm only suggesting to modify the third paragraph, offering to produce
> two sets of images (fully-free and with-non-free-firmware), being the
> later more prominent.
> 
> =
> 
> 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.
> 
> While we will publish these images as official Debian media, they will
> *not* replace the current media sets that do not include non-free
> firmware packages, but offered alongside. Images that do include
> non-free firmware will be presented more prominently, so that
> newcomers will find them more easily; fully-free images will not be
> hidden away; they will be linked from the same project pages, but with
> less visual priority.
> 
> =

Thanks Gunnar; I think it is important to have on the ballot, so:
seconded.


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Tobias Frost]

On Mon, Aug 22, 2022 at 05:48:28PM +0200, Simon Josefsson wrote:
> Tobias Frost  writes:
> That seems incorrect.  Here is a quote from the proposal:
> 
>   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).
>   ...
>   We will publish these images as official Debian media, replacing the
>  ^
>   current media sets that do not include non-free firmware packages.

We are replacing stuff very often, for example when we update the installer it
is replaced too. For me, the replace in the proposal is meaning that kind of
replacing. We'd not taking anything away in respect to the spirit of SC-1.

--
tobi 



signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Tobias Frost]

On Mon, Aug 22, 2022 at 07:39:21AM +0200, Simon Josefsson wrote:
> Ansgar  writes:
> 
> > On Fri, 2022-08-19 at 16:23 +0200, Simon Richter wrote:
> >> Do we need to update the Debian Social Contract for that?
> >> Specifically paragraph 1, which currently reads
> >> 
> >>  Debian will remain 100% free
> >
> > No. Just like we don't need to update the Debian Social Contract for
> > having https://deb.debian.org/debian/pool/non-free/: we just ship
> > additional files that might be useful for people having specific
> > hardware.
> 
> I disagree -- what is being proposed here is to replace our current
> DSC-compatible free software installer images with non-free.  That goes
> significantly further than what the spirit of DSC§5 suggests.

It not being replaced; there are just additional bits in there which
help people to actually be able to install Debian on some modern machines.

The guarantee in SC1 that we will never *require* those non-free bits, as writen
out in "We will never make the system require the use of a non-free component."
This GR does not violate this promise.


--
tobi's 0.02 €


signature.asc
Description: PGP signature

Re: Changing how we handle non-free firmware

[Tobias Frost]

On Thu, Aug 18, 2022 at 08:58:21PM +0100, 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 about 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
>available.
> 
>  * 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
> 
> -- 
> Steve McIntyre, Cambridge, UK.st...@einval.com
> You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Thanks Steve for this going forward!
(seconded.)



signature.asc
Description: PGP signature

Re: Proposed GR: State exception for security bugs in Social Contract clause 3

[Tobias Frost]

Am 13. Januar 2017 06:17:48 GMT+08:00 schrieb Philip Hands :
>Scott Kitterman  writes:
>
>> On Thursday, January 12, 2017 02:26:59 PM Sean Whitton wrote:
>>> Hello,
>>> 
>>> On Thu, Jan 12, 2017 at 03:11:46AM +, Scott Kitterman wrote:
>>> > Here's an example of possible unintended consequences:
>>> > 
>>> > Currently we enumerate no specifics about exceptions to when
>things
>>> > should be public.  Once we have a foundational list of acceptable
>>> > reasons to not be public (security would be the only one), then
>it's
>>> > easy to infer that's the complete list.
>>> > 
>>> > Would this GR prohibit the tech ctte practice of private
>deliberations
>>> > about recommendations for new members?  I think it might.
>>> > 
>>> > I've worked in private with other DDs to resolve disputes within
>the
>>> > project.  Often a quiet conversation out of the public glare can
>make
>>> > solutions possible that wouldn't happen if all discussion was
>public.
>>> > Does this GR prohibit that?  Maybe.
>>> 
>>> Thank you for your e-mail -- I now understand your objection.
>>> 
>>> All the other wording in clause 3 is about bug reports against the
>>> Debian system.  The examples that you give are about unresolved
>issues
>>> in the Debian project -- disputes between people, rather than
>problems
>>> in source and binary packages.  I find the line between the Debian
>>> system and the Debian project to be fairly sharp.  I'd be interested
>to
>>> hear if you disagree.
>>> 
>>> The header of clause 3 ("We will not hide problems") admittedly
>could
>>> refer to your examples.  Would it help if my GR text were amended to
>>> append "in the Debian system" to the header of the clause?
>>
>> That then has the opposite problem.  It clearly narrows the notion of
>not 
>> hiding problems and I don't think that's good either.
>>
>> I'm still at don't monkey with foundational documents to solve
>> non-problems.
>
>Quite.
>
>I'm yet to be convinced that there exists anyone that would be upset by
>the fact that our security team might abide by embargoes in supposed
>defiance of 'not hide problems'.  I am also not convinced that if there
>does exist such a person, and they are capable of becoming upset enough
>about it to be driven away from Debian, that that would be a great
>loss.
>
>Cheers, Phil.

Seems that topic has been previously discussed already: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=129604

(just came across that bug by purechange yesterday)
-- 
Tobias Frost
GPG fingerprint: 13C9 04F0 CE08 5E7C 3630 7985 DECF 849A A635 7FB7

Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution

[Tobias Frost]

Am Freitag, den 08.07.2016, 15:27 +0200 schrieb Margarita Manterola:
> The Debian Constitution is very well written, in a way that is almost
> completely
> ungendered.  The only gendered word left is the Chairman of the
> Technical
> Committee.  There is no reason for this position to be gendered.
> Ungendered
> alternatives for Chairman are Chair and Chairperson. While both work,
> Chair is
> simpler and shorter.
> 
> I'm therefore proposing the following General Resolution:
> 
> === BEGIN GR TEXT ===
> 
> Title: Replace "Chairman" with "Chair" throughout the Debian
> Constitution
> 
> All appearances of the word Chairman shall be replaced with the word
> Chair.
> 
> === END GR TEXT ===
> 
> This change can be applied by a simple sed command
> (s/Chairman/Chair/g).  I'm
> attaching the diff between the current constitution document and the
> output of
> said sed command to make it explicit that no other changes are
> intended.
> 
Seconded.


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

Re: Re-Proposal - preserve freedom of choice of init systems

[Tobias Frost]

On Thu, 2014-10-16 at 16:05 +0100, Ian Jackson wrote:
> I wish to propose the following general resolution, and hereby call
> for seconds.  This GR resolution proposal is identical to that
> proposed by Matthew Vernon in March:
>   https://lists.debian.org/debian-vote/2014/03/msg0.html
> and the substantive text is that which was drafted for the purposes of
> the technical committee's vote (where they decided not to pass a
> resolution on the subject).
> 
> IMO developments since March show that the concerns put forward then
> were well-founded.  Following discussions elsewhere including -devel I
> have received enough offers of seconds by private email.
> 
> As Matthew said, I don't think further lengthy discussion of the
> issues is likely to be productive, and therefore hope we can bring
> this swiftly to a vote.  This is particularly true given the impact on
> the jessie release.
> 
> Thanks,
> Ian.
> 
> ** Begin Proposal **
> 
> 0. Rationale
> 
>   Debian has decided (via the technical committee) to change its
>   default init system for the next release. The technical committee
>   decided not to decide about the question of "coupling" i.e. whether
>   other packages in Debian may depend on a particular init system.
> 
>   This GR seeks to preserve the freedom of our users now to select an
>   init system of their choice, and the project's freedom to select a
>   different init system in the future. It will avoid Debian becoming
>   accidentally locked in to a particular init system (for example,
>   because so much unrelated software has ended up depending on a
>   particular init system that the burden of effort required to change
>   init system becomes too great). A number of init systems exist, and
>   it is clear that there is not yet broad consensus as to what the
>   best init system might look like.
> 
>   This GR does not make any comment on the relative merits of
>   different init systems; the technical committee has decided upon the
>   default init system for Linux for jessie.
> 
> 1. Exercise of the TC's power to set policy
> 
>   For jessie and later releases, the TC's power to set technical
>   policy (Constitution 6.1.1) is exercised as follows:
> 
> 2. Loose coupling of init systems
> 
>   In general, software may not require a specific init system to be
>   pid 1.  The exceptions to this are as follows:
> 
>* alternative init system implementations
>* special-use packages such as managers for init systems
>* cooperating groups of packages intended for use with specific init
>  systems
> 
>   provided that these are not themselves required by other software
>   whose main purpose is not the operation of a specific init system.
> 
>   Degraded operation with some init systems is tolerable, so long as
>   the degradation is no worse than what the Debian project would
>   consider a tolerable (non-RC) bug even if it were affecting all
>   users.  So the lack of support for a particular init system does not
>   excuse a bug nor reduce its severity; but conversely, nor is a bug
>   more serious simply because it is an incompatibility of some software
>   with some init system(s).
> 
>   Maintainers are encouraged to accept technically sound patches
>   to enable improved interoperation with various init systems.
> 
> 3. Notes and rubric
> 
>   This resolution is a Position Statement about Issues of the Day
>   (Constitution 4.1.5), triggering the General Resolution override
>   clause in the TC's resolution of the 11th of February.
> 
>   The TC's decision on the default init system for Linux in jessie
>   stands undisturbed.
> 
>   However, the TC resolution is altered to add the additional text
>   in sections (1) and (2) above.
> 
> ** End Proposal **
> -- 
> 
> 

Seconded.



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