On Sun, 2022-05-15 at 20:53 +0200, Bastian Blank wrote:
> I see what you mean. But nothing of that actually enables the use of a
> particular hardware.
Enabling the use of particular hardware is a subset of the actual goal;
enabling more people to use Debian at all, which the non-firmware items
Moin
On Tue, May 10, 2022 at 02:30:04PM -0600, Sam Hartman wrote:
> Build Dependencies
> ==
>
> As a consequence of options 2-4, non-free-firmware would typically need
> to be enabled whenever non-free is enabled.
I don't understand why this is the case? Option 2 just needs
On Wed, May 11, 2022 at 07:38:18PM +0200, Adam Borowski wrote:
> I'd say that closed encrypted signed firmware that you need to load on
> every boot is strictly more free than the same firmware burned into ROM.
Not necessarily. Firmware-as-software and firmware-as-hardware are
covered by
On Fri, 2022-05-13 at 17:48 +0200, Thomas Goirand wrote:
> Yeah, of course, but this is because you know what you're doing. If
> you do, then you also probably read the release notes, don't you? :)
I haven't actually read the full release notes in recent years.
I expect a lot of experienced
On 5/12/22 23:26, Paul Wise wrote:
On Thu, 2022-05-12 at 16:56 +0200, Thomas Goirand wrote:
If protected by a debconf prompt (by default, doing nothing...), all
of your remarks are going away.
That means that people who only ever upgrade via unattended-upgrades or
other mechanisms that
On Thu, 2022-05-12 at 16:56 +0200, Thomas Goirand wrote:
> If protected by a debconf prompt (by default, doing nothing...), all
> of your remarks are going away.
That means that people who only ever upgrade via unattended-upgrades or
other mechanisms that disable debconf/dpkg prompts etc aren't
On 5/12/22 04:52, Paul Wise wrote:
On Wed, 2022-05-11 at 17:14 +0200, Thomas Goirand wrote:
A work around would be to have some automation to check if non-free is
activated, and (propose to) update the sources.list automatically to add
non-free-firmware.
That isn't feasible, since apt
On 5/11/22 17:24, Johannes Schauer Marin Rodrigues wrote:
Quoting Thomas Goirand (2022-05-11 17:14:57)
For backwards compatibility, I think that the firmware component is
going to need to be a subset of non-free; i.e. packages are going to
need to be *copied* not moved from non-free to the
On Wed, 2022-05-11 at 19:38 +0200, Adam Borowski wrote:
> You may want to talk to people responsible for that firmware, reproducible
> builds sounds like an attainable goal to me.
I don't have any of the hardware that supports SOF, so I'll leave that
up to the firmware-sof-signed maintainer etc.
On Wed, 2022-05-11 at 17:14 +0200, Thomas Goirand wrote:
> A work around would be to have some automation to check if non-free is
> activated, and (propose to) update the sources.list automatically to add
> non-free-firmware.
That isn't feasible, since apt sources are managed external to
On Wed, May 11, 2022 at 09:48:56AM +0800, Paul Wise wrote:
> The only exception is things like firmware-sof-signed, which is libre
> firmware except the binaries are built and signed by Intel, so Debian
> can't build the firmware binaries ourselves, unless the approach taken
> with the Secure Boot
Quoting Thomas Goirand (2022-05-11 17:14:57)
> > For backwards compatibility, I think that the firmware component is
> > going to need to be a subset of non-free; i.e. packages are going to
> > need to be *copied* not moved from non-free to the firmware component,
> > which means they would be
On 5/11/22 03:48, Paul Wise wrote:
On Tue, 2022-05-10 at 14:30 -0600, Sam Hartman wrote:
So let's assume that at least all those packages can move to
non-free-firmware.
For backwards compatibility, I think that the firmware component is
going to need to be a subset of non-free; i.e. packages
On Wed, May 11, 2022 at 12:04:15AM +0200, Vincent Bernat wrote:
> ❦ 10 May 2022 14:30 -06, Sam Hartman:
> > 2) We value being able to build from source when we can. We value
> > being able to have reproducible builds when we can. We don't want to
> > take steps backward in those areas in order to
On Tue, 2022-05-10 at 14:30 -0600, Sam Hartman wrote:
> So let's assume that at least all those packages can move to
> non-free-firmware.
For backwards compatibility, I think that the firmware component is
going to need to be a subset of non-free; i.e. packages are going to
need to be *copied*
> "Vincent" == Vincent Bernat writes:
Vincent> ❦ 10 May 2022 14:30 -06, Sam Hartman:
>> 2) We value being able to build from source when we can. We value
>> being able to have reproducible builds when we can. We don't want
>> to take steps backward in those areas in order to
❦ 10 May 2022 14:30 -06, Sam Hartman:
> 2) We value being able to build from source when we can. We value
> being able to have reproducible builds when we can. We don't want to
> take steps backward in those areas in order to get hardware working
> better.
Is there any firmware that would match
TL;DR: I tried to think about what all would go in non-free-firmware if
we create it.
I think there are some complicated questions especially around source
dvds and dependencies.
Hi. So it sounds like a number of the options involve creating a
non-free-firmware component, and we might even have
18 matches
Mail list logo
