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
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
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
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 Mon, Oct 3, 2022 at 11:32 PM Santiago Ruano Rincón
wrote:
> > Can we have different versions in each section?
> >
> > + non-free/pkgA version~1
> > + non-free-firmware/pkgA version~2
>
> that wouldn't comply with the current policy:
>
El 03/10/22 a las 19:40, Shengjing Zhu escribió:
> On Mon, Oct 3, 2022 at 7:31 PM Didier 'OdyX' Raboud wrote:
> >
> > 3 octobre 2022 11:11 "Santiago Ruano Rincón" a
> > écrit:
> > > El 02/10/22 a las 20:42, Michael Biebl escribió:
> > >> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
> > >> On
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
El 03/10/22 a las 11:31, Didier 'OdyX' Raboud escribió:
> 3 octobre 2022 11:11 "Santiago Ruano Rincón" a écrit:
> > El 02/10/22 a las 20:42, Michael Biebl escribió:
> >> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
> >> On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
> >> In Bullseye we
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
On Mon, Oct 3, 2022 at 7:31 PM Didier 'OdyX' Raboud wrote:
>
> 3 octobre 2022 11:11 "Santiago Ruano Rincón" a écrit:
> > El 02/10/22 a las 20:42, Michael Biebl escribió:
> >> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
> >> On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
> >> In Bullseye
3 octobre 2022 11:11 "Santiago Ruano Rincón" a écrit:
> El 02/10/22 a las 20:42, Michael Biebl escribió:
>> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
>> On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
>> In Bullseye we changed the name/syntax for the security repository, and
>> for that
On Sun, Oct 02, 2022 at 11:47:42PM +0200, Thomas Goirand wrote:
> On 10/2/22 22:02, Russ Allbery wrote:
> > Michael Biebl writes:
> >
> > > The main difference is, that the renaming caused an error message by
> > > apt, so you knew something needed to be fixed.
> >
> > One could argue that
El 02/10/22 a las 20:42, Michael Biebl escribió:
>
> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
> > On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
>
> > > will
> > > be very obvious. But if you currently have non-free configured but
> > > don't
> > > add the new firmware section,
Hi,
Le 03/10/2022 à 01:00, Lennart Sorensen a écrit :
[…]
I can't think of ever having had to add anything, only
change the release name.
You’ll change your mind when you’ll upgrade to stable.
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information#security-archive
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 10/2/22 22:02, Russ Allbery wrote:
Michael Biebl writes:
The main difference is, that the renaming caused an error message by
apt, so you knew something needed to be fixed.
One could argue that having non-free but not non-free-firmware is
sufficiently strange that it would be worth a
Michael Biebl writes:
> The main difference is, that the renaming caused an error message by
> apt, so you knew something needed to be fixed.
One could argue that having non-free but not non-free-firmware is
sufficiently strange that it would be worth a suppressable apt warning
(that you could
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
Am 02.10.22 um 20:14 schrieb Luca Boccassi:
On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
will
be very obvious. But if you currently have non-free configured but
don't
add the new firmware section, everything will appear to work but you
won't
get new firmware, so the problem may go
On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote:
> Shengjing Zhu writes:
> > On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre
> > wrote:
>
> > > 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
>
On 2022-10-02 at 13:52, Russ Allbery wrote:
> Shengjing Zhu writes:
>
>> On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre
>> wrote:
>
>>> 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),
Shengjing Zhu writes:
> On Sun, Oct 2, 2022 at 10:53 PM Steve McIntyre wrote:
>> 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
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
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 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)?
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 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
54 matches
Mail list logo
