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

Bug#950332: marked as done (buster-pu: package wireless-regdb/2019.06.03-1~deb10u1)

Your message dated Sat, 10 Sep 2022 19:09:56 +0100
with message-id <dea94b1025145f815b558e8ca26d800e39550b9c.camel@adam-barratt.org.uk>
and subject line Re: Bug#950332: buster-pu: package wireless-regdb/2019.06.03-1~deb10u1
has caused the Debian Bug report #950332,
regarding buster-pu: package wireless-regdb/2019.06.03-1~deb10u1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
950332: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950332
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian.org@packages.debian.org
Usertags: pu

I failed to update wireless-regdb for some time, as it needed some
significant work to prepare for the regulatory database being directly
loaded by the kernel (instead of by crda).  This was introduced in
Linux 4.15, but is currently disabled in all Debian suites.  It will
be enabled starting with 5.5.

The version now in unstable has:

1. regulatory.bin: loadable by crda, trusted by Debian crda
2. regulatory.db-debian, regulatory.db.p7s-debian:
   loadable by kernel, trusted by future Debian kernels
3. regulatory.db-upstream, regulatory.db.p7s-upstream:
   loadable by kernel, trusted by upstream and future Debian kernels
4. regulatory.db, regulatory.db.p7s: alternative links for either
   (2) or (3)

So this should be backward-compatible with all supported Debian
releases, with one exception:

On a system that has a recent kernel and (3) from elsewhere, *and*
also a currently unused wireless-regdb package, upgrading
wireless-regdb will effectively replace (3) with (2), which is not
trusted by their kernel.  They will need to run update-alternatives to
fix this (this is documented in README.Debian).

The update for (1) definitely should be delivered to all suites, but
I'm undecided whether the other files should be included.  Please
advise what I should do.

Ben.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

--- End Message ---
--- Begin Message --- 
On Sun, 2020-04-26 at 16:48 +0200, Julien Cristau wrote:
> On Fri, Jan 31, 2020 at 02:26:18PM +0100, Ben Hutchings wrote:
> > I failed to update wireless-regdb for some time, as it needed some
> > significant work to prepare for the regulatory database being
> > directly
> > loaded by the kernel (instead of by crda).  This was introduced in
> > Linux 4.15, but is currently disabled in all Debian suites.  It
> > will
> > be enabled starting with 5.5.
> > 
> > The version now in unstable has:
> > 
> > 1. regulatory.bin: loadable by crda, trusted by Debian crda
> > 2. regulatory.db-debian, regulatory.db.p7s-debian:
> >    loadable by kernel, trusted by future Debian kernels
> > 3. regulatory.db-upstream, regulatory.db.p7s-upstream:
> >    loadable by kernel, trusted by upstream and future Debian
> > kernels
> > 4. regulatory.db, regulatory.db.p7s: alternative links for either
> >    (2) or (3)
> > 
> > So this should be backward-compatible with all supported Debian
> > releases, with one exception:
> > 
> > On a system that has a recent kernel and (3) from elsewhere, *and*
> > also a currently unused wireless-regdb package, upgrading
> > wireless-regdb will effectively replace (3) with (2), which is not
> > trusted by their kernel.  They will need to run update-alternatives 
> > to
> > fix this (this is documented in README.Debian).
> > 
> Is this something that can be detected from e.g. maintainer scripts,
> to
> show some kind of hint to the affected user?
> 
> > The update for (1) definitely should be delivered to all suites,
> > but
> > I'm undecided whether the other files should be included.  Please
> > advise what I should do.
> > 
> I guess our options for stable are:
> a. ship 1/2/3/4 in a point release
> b. ship an update for 1 in a point release, ship 1/2/3/4 in backports
> 
> For option b, can we reasonably have the backports kernel Break old
> wireless-regdb, to nudge apt into updating that to the backport
> too?  Or
> is that more likely to get wireless-regdb removed than anything else?
> 

Apparently we never picked this back up. :-/

The final point release for buster has now happened, so any further
updates to packages in buster will need to be handled via LTS. I'm
therefore going to close this request now.

Regards,

Adam

--- End Message ---
Reply to: