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
Hi Pascal,
On Fri, Oct 14, 2022 at 09:57:37PM +0200, Pascal Hambourg wrote:
>On 14/10/2022 at 21:49, Holger Wansing wrote:
>>
>> Pascal Hambourg wrote (Fri, 14 Oct 2022 21:31:31
>> +0200):
>> > > > > As far as I understand it, they can be packaged once their
>> > > > > redistributability is
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
Hi,
Pascal Hambourg wrote (Fri, 14 Oct 2022 21:57:37
+0200):
> I did not mention the need for any special installer medium, only the
> need for the installer to support extra firmware medium.
>
> > The usual installer also has the capability to make use of firmware
> > provided via USB.
>
>
On 14/10/2022 at 21:49, Holger Wansing wrote:
Pascal Hambourg wrote (Fri, 14 Oct 2022 21:31:31
+0200):
As far as I understand it, they can be packaged once their
redistributability is clarified?
The only way for the installer to make use of such firmware is, if the
user provides the
Holger Wansing (2022-10-14):
> Pascal Hambourg wrote (Fri, 14 Oct 2022
> > This is my point. If Debian does not provide all firmware for
> > drivers which are included into the installer, then support for
> > extra firmware medium is still useful and should not be removed.
>
> For this specific
Hi,
Pascal Hambourg wrote (Fri, 14 Oct 2022 21:31:31
+0200):
> >>> As far as I understand it, they can be packaged once their
> >>> redistributability is clarified?
> >
> > The only way for the installer to make use of such firmware is, if the
> > user provides the firmware files on a
On 14/10/2022 at 20:54, Holger Wansing wrote:
Pascal Hambourg wrote (Fri, 14 Oct 2022 19:50:11
+0200):
On 13/10/2022 at 10:13, Cyril Brulebois wrote:
Pascal Hambourg (2022-10-13):
What about firmware not available in Debian packages ? For example
Prims54 wireless adapters using p54pci and
Hi,
Pascal Hambourg wrote (Fri, 14 Oct 2022 19:50:11
+0200):
> On 13/10/2022 at 10:13, Cyril Brulebois wrote:
> > Pascal Hambourg (2022-10-13):
> >> What about firmware not available in Debian packages ? For example
> >> Prims54 wireless adapters using p54pci and p54usb drivers included
> >>
On 13/10/2022 at 10:13, Cyril Brulebois wrote:
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
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
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
* 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
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
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
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
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
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
>
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
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
>>
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
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
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
Hello,
On 08/10/2022 at 18:37, Steve McIntyre wrote:
* Let's drop the question/support for an extra firmware medium -
it's not useful any more. We're going to have firmware available
directly.
What about firmware not available in Debian packages ? For example
Prims54 wireless
Hey Jonathan!
On Sun, Oct 09, 2022 at 09:30:55AM +0200, Jonathan Carter (highvoltage) wrote:
>
>On 2022/10/08 18:37, Steve McIntyre wrote:
>>* Is PXE over wifi a thing? Never seen it...
>
>I've been poking around firmware setups of new laptops, and I'm intrigued by
>a new option that at least
Hi Steve
On 2022/10/08 18:37, Steve McIntyre wrote:
* Is PXE over wifi a thing? Never seen it...
I've been poking around firmware setups of new laptops, and I'm
intrigued by a new option that at least all the new Dell laptops have,
called httpboot. It seems that you can just provide a
Hey again folks!
On Sun, Oct 02, 2022 at 03:27:36PM +0100, Steve McIntyre wrote:
...
>We have quite a few things to do now, ideally before the freeze for
>Debian 12 (bookworm), due January 2023 [2]. This list of work items is
>almost definitely not complete, and Cyril and I are aiming to get
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
> >
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
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
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
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
> I think it's ironic
Apologies, on second thought this was poor wording. It's not ironic,
merely an oversight. We all believe in the success of free software, and
I don't mean to question anyone's values or allegiance for wanting to
serve users by tackling the most evident problems.
I concede I'm biased as its maintainer, but I think it's ironic that
non-free firmware is about to have better support than the flagship
libre wireless firmware. I'm referring to open-ath9k-htc-firmware, which
if you're not familiar, is the firmware for the most prominent USB
wireless adapters
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
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)?
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
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)?
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
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
Hi all!
[ I've also blogged about this - see
https://blog.einval.com/2022/10/02#firmware-vote-result ]
I'm assuming that there will be no surprises and Kurt will shortly
confirm the result that devotee reported already [1]. :-)
We have quite a few things to do now, ideally before the freeze
56 matches
Mail list logo
