Bug#1013868: nfs-common: Split between Python scripts to separate package

[Ben Hutchings]

Control: severity -1 wishlist

On Sun, 2022-06-26 at 09:47 +0200, Gioele Barabucci wrote:
> Package: nfs-common
> Version: 1:2.6.1-2
> 
> Dear maintainers of nfs-common,
> 
> could you please move the three Python scripts included in nfs-common to 
> a separate -extras package?

No, the postinst may run nfsconvert.py.

> Currently nfs-common Depends on `python3` and, on lean/containerized 
> client systems, it is the only package that requires it. For this 
> reason, in 2019 Fedora moved the scripts `mountstats`, `nfsiostat` and 
> `nfsconvert` to a separate package [1,2], required on servers (for 
> `nfsconver`) but not on clients.

nfsconvert.py is also required on clients.

We can remove nfsconvert.py and revisit this after the bookworm
release.

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.


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

Bug#1014181: bash-completions and bug script assume $XDG_CONFIG_DIR is set

[Ben Hutchings]

On Fri, 2022-07-01 at 18:10 +0200, Ben Hutchings wrote:
> Package: dput
> Version: 1.1.1
> Severity: normal
> 
> The bash-completion script looks for $XDG_CONFIG_DIR/dput/dput.cf but
> should use ${XDG_CONFIG_DIR:-$HOME/.config}/dput/dput.cf.

s/XDG_CONFIG_DIR/XDG_CONFIG_HOME/g

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.


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

Bug#1014182: bug script fails

[Ben Hutchings]

Package: dput
Version: 1.1.1
Severity: important

The last command in the bug script is "dput --print", which no longer
works and exits with return code 64.  This becomes the exit code of
the bug script itself, causing reportbug to suggest cancelling the bug
report:

Gathering additional data, this may take a while...
cat: /dput/dput.cf: No such file or directory
cat: /home/ben/.dput.cf: No such file or directory

-- Configuration parsed by ‘dput’ --
The package bug script /usr/share/bug/dput/script exited with an error 
status (return code = 16384). Do you still want to file a report [y|N|q|?]?

Ben.

-- Package-specific info:

-- /etc/dput.cf --
# Example dput.cf that defines the host that can be used
# with dput for uploading.

[DEFAULT]
login   = *
method  = ftp
hash= md5
allow_unsigned_uploads  = 0
allow_dcut  = 0
run_lintian = 0
run_dinstall= 0
check_version   = 0
scp_compress= 0
post_upload_command =
pre_upload_command  =
passive_ftp = 1
default_host_main   =
allowed_distributions   = (?!UNRELEASED)

[ftp-master]
fqdn= ftp.upload.debian.org
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
method  = ftp
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-project/2009/05/msg00036.html
[ftp-eu]
fqdn= ftp.eu.upload.debian.org
method  = ftp
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-devel-announce/2008/09/msg7.html
[ssh-upload]
login   = *
# login = another_username
fqdn= ssh.upload.debian.org
method  = scp
incoming= /srv/upload.debian.org/UploadQueue/
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# And if you want to override one of the defaults, add it here.
# For example, comment out the next line
# post_upload_command   = /path/to/some/script
# pre_upload_command= /path/to/some/script

[security-master]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/SecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[security-master-unembargoed]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/OpenSecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[ubuntu]
fqdn= upload.ubuntu.com
method  = ftp
incoming= /
login   = anonymous

[ppa]
fqdn= ppa.launchpad.net
method  = ftp
# replace  with your Launchpad ID
incoming= ~/ubuntu
login   = anonymous

[mentors]
method  = ftp
fqdn= mentors.debian.net
incoming= /pub/UploadQueue
login   = anonymous

[local]
method  = local
incoming= ~/public_html/debian/mini-dinstall/incoming
run_dinstall= 0
post_upload_command = /usr/bin/mini-dinstall --batch


# Local variables:
# coding: utf-8
# mode: conf
# End:
# vim: fileencoding=utf-8 filetype=config :

-- /dput/dput.cf --

-- /home/ben/.dput.cf --
No package or host has been provided, see dput -h

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

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

Versions of 

Bug#1014181: bash-completions and bug script assume $XDG_CONFIG_DIR is set

[Ben Hutchings]

Package: dput
Version: 1.1.1
Severity: normal

The bash-completion script looks for $XDG_CONFIG_DIR/dput/dput.cf but
should use ${XDG_CONFIG_DIR:-$HOME/.config}/dput/dput.cf.

While making this report, I found that the bug script has the same
bug.

Ben.

-- Package-specific info:

-- /etc/dput.cf --
# Example dput.cf that defines the host that can be used
# with dput for uploading.

[DEFAULT]
login   = *
method  = ftp
hash= md5
allow_unsigned_uploads  = 0
allow_dcut  = 0
run_lintian = 0
run_dinstall= 0
check_version   = 0
scp_compress= 0
post_upload_command =
pre_upload_command  =
passive_ftp = 1
default_host_main   =
allowed_distributions   = (?!UNRELEASED)

[ftp-master]
fqdn= ftp.upload.debian.org
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
method  = ftp
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-project/2009/05/msg00036.html
[ftp-eu]
fqdn= ftp.eu.upload.debian.org
method  = ftp
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-devel-announce/2008/09/msg7.html
[ssh-upload]
login   = *
# login = another_username
fqdn= ssh.upload.debian.org
method  = scp
incoming= /srv/upload.debian.org/UploadQueue/
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# And if you want to override one of the defaults, add it here.
# For example, comment out the next line
# post_upload_command   = /path/to/some/script
# pre_upload_command= /path/to/some/script

[security-master]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/SecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[security-master-unembargoed]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/OpenSecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[ubuntu]
fqdn= upload.ubuntu.com
method  = ftp
incoming= /
login   = anonymous

[ppa]
fqdn= ppa.launchpad.net
method  = ftp
# replace  with your Launchpad ID
incoming= ~/ubuntu
login   = anonymous

[mentors]
method  = ftp
fqdn= mentors.debian.net
incoming= /pub/UploadQueue
login   = anonymous

[local]
method  = local
incoming= ~/public_html/debian/mini-dinstall/incoming
run_dinstall= 0
post_upload_command = /usr/bin/mini-dinstall --batch


# Local variables:
# coding: utf-8
# mode: conf
# End:
# vim: fileencoding=utf-8 filetype=config :

-- /dput/dput.cf --

-- /home/ben/.dput.cf --
No package or host has been provided, see dput -h

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

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

Versions of packages dput depends on:
ii  python33.10.4-1+b1
ii  python3-debian 0.1.44
ii  python3-gpg1.17.1-4
ii  python3-pkg-resources  59.6.0-1.2
ii  python3-xdg0.27-2

dput recommends no packages.

Versions of packages dput suggests:
ii  lintian 2.115.2
pn  mini-dinstall   
ii  openssh-client  1:9.0p1-1+b1
ii  rsync  

Bug#1012601: wireless-regdb: alternative broken on debian-installer install

[Ben Hutchings]

On Tue, 2022-06-14 at 08:27 +0900, Dominique Martinet wrote:
> Ben Hutchings wrote on Mon, Jun 13, 2022 at 04:39:23PM +0200:
> > On Fri, 2022-06-10 at 09:39 +0900, Dominique Martinet wrote:
> > > the udeb regdb is also slightly obsolete, I'm not sure why it was needed
> > > in the first place but it might be possible to use the normal package
> > > instead?
> > 
> > Why do you think it's obsolete?  It is useful to have this file present
> > in the installer.
> 
> Sorry this wasn't clear. I didn't mean obsolete as no longer useful,
> just that it is old: wireless-regdb-udeb hasn't been updated in two
> years, while the main wireless-regdb package keeps getting updates
> regularly.

You are comparing wireless-regdb-udeb in stable with wireless-regdb in
unstable.

Both the regular and udeb packages are outdated in stable, but this
should be fixed in the next point release.

[...]
> Note that for clients (installer usecase), it _also_ doesn't matter: if
> an AP uses regulated bands, the client will (should?) rightfully use
> these.

Yes, I think this is generally what happens.  But the kernel wants to
load regulatory.db regardless of what mode is being used, so it seemed
like a good idea to include it in the installer.

This bug shows that that didn't have an entirely positive effect, but
it will be fixed.

[...]
> Yeah, it probably makes more sense to just remove whatever was there in
> the post-install script.
> I'll leave the resolution to you unless you want/need help with
> something.

That is what I've now implemented.

Ben.

-- 
Ben Hutchings
Nothing is ever a complete failure;
it can always serve as a bad example.


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

Bug#1014079: bullseye-pu: package wireless-regdb/2022.04.08-2~deb11u1

[Ben Hutchings]

 channels 1-6 EIRP=40dBm(43dBm peak)
diff -Nru wireless-regdb-2020.04.29/debian/changelog 
wireless-regdb-2022.04.08/debian/changelog
--- wireless-regdb-2020.04.29/debian/changelog  2020-06-30 19:34:44.0 
+0200
+++ wireless-regdb-2022.04.08/debian/changelog  2022-06-30 01:13:22.0 
+0200
@@ -1,3 +1,54 @@
+wireless-regdb (2022.04.08-2~deb11u1) bullseye; urgency=medium
+
+  * Backport to bullseye:
+- Revert "Remove support for loading through crda"
+- Add my signature for regulatory.bin
+- d/salsa-ci.yml: Set RELEASE to bullseye
+  * d/tests/check-signatures: Fix typo in openssl command line
+
+ -- Ben Hutchings   Thu, 30 Jun 2022 01:13:22 +0200
+
+wireless-regdb (2022.04.08-2) unstable; urgency=medium
+
+  * debian/tests: Add check that regulatory.db signatures are valid
+  * d/wireless-regdb.postinst: Remove regular files installed by d-i
+(Closes: #1012601)
+
+ -- Ben Hutchings   Thu, 30 Jun 2022 00:01:25 +0200
+
+wireless-regdb (2022.04.08-1) unstable; urgency=medium
+
+  * New upstream version:
+- Raise DFS TX power limit to 250 mW (24 dBm) for the US
+- Update regulatory rules for Croatia (HR) on 6GHz
+- Update regulatory rules for France (FR) on 6 and 60 GHz
+- add support for US S1G channels
+- add 802.11ah bands to world regulatory domain
+- Update regulatory rules for Spain (ES) on 6GHz
+- Update regulatory rules for South Korea (KR)
+- Update regulatory rules for China (CN) (Closes: #1006127)
+- Update regulatory rules for the Netherlands (NL) on 6GHz
+- Update regulatory rules for Israel (IL)
+- Update regulatory rules for Australia (AU)
+  * d/salsa-ci.yml: Add CI configuration for salsa.debian.org
+  * Remove support for loading through crda (Closes: #973551, #1004347)
+  * d/.gitignore: Ignore another debhelper temporary file
+
+ -- Ben Hutchings   Sat, 04 Jun 2022 23:59:01 +0100
+
+wireless-regdb (2021.08.28-1) unstable; urgency=medium
+
+  * New upstream version (Closes: #986208):
+- Update regulatory rules for Egypt (EG), Croatia (HR), Pakistan (PK)
+  on 5GHz, Great Britain (GB), Kazakhstan (KZ), Ukraine (UA), Cuba (CU)
+  on 5Ghz, Germany (DE) on 6GHz, Norway (NO) on 6 and 60 GHz, Ecuador (EC)
+- US: restore channel 12 & 13 limitation
+- US: remove PTMP-ONLY from 5850-5895 MHz
+- US: reduce bandwidth for 5730-5850 and 5850-5895 MHz
+- ES: Update CNAF regulation url
+
+ -- Romain Perier   Fri, 17 Sep 2021 18:30:37 +0200
+
 wireless-regdb (2020.04.29-2) unstable; urgency=medium
 
   * Re-upload without binary packages (SourceOnlyUpload)
Binary files 
/var/tmp/q2x0yR97II/wireless-regdb-2020.04.29/debian/regulatory.bin.sig and 
/var/tmp/t5Nn_4OFYr/wireless-regdb-2022.04.08/debian/regulatory.bin.sig differ
Binary files 
/var/tmp/q2x0yR97II/wireless-regdb-2020.04.29/debian/regulatory.db.p7s and 
/var/tmp/t5Nn_4OFYr/wireless-regdb-2022.04.08/debian/regulatory.db.p7s differ
diff -Nru wireless-regdb-2020.04.29/debian/salsa-ci.yml 
wireless-regdb-2022.04.08/debian/salsa-ci.yml
--- wireless-regdb-2020.04.29/debian/salsa-ci.yml   1970-01-01 
01:00:00.0 +0100
+++ wireless-regdb-2022.04.08/debian/salsa-ci.yml   2022-06-30 
00:53:42.0 +0200
@@ -0,0 +1,13 @@
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+
+variables:
+  RELEASE: 'bullseye'
+  # We only build arch:all packages
+  SALSA_CI_DISABLE_BLHC: 'true'
+  SALSA_CI_DISABLE_BUILD_PACKAGE_I386: 'true'
+  SALSA_CI_DISABLE_BUILD_PACKAGE_ANY: 'true'
+  SALSA_CI_DISABLE_CROSSBUILD_ARM64: 'true'
+  # Currently triggering falsely (bug #973313)
+  SALSA_CI_LINTIAN_SUPPRESS_TAGS: 'groff-message'
diff -Nru wireless-regdb-2020.04.29/debian/tests/check-signatures 
wireless-regdb-2022.04.08/debian/tests/check-signatures
--- wireless-regdb-2020.04.29/debian/tests/check-signatures 1970-01-01 
01:00:00.0 +0100
+++ wireless-regdb-2022.04.08/debian/tests/check-signatures 2022-06-30 
01:03:12.0 +0200
@@ -0,0 +1,136 @@
+#!/usr/bin/python3
+
+# Check that signatures on regulatory.db are valid and made by keys
+# trusted by the current kernel in the target suite
+
+import glob
+import io
+import os
+import os.path
+import re
+import subprocess
+import sys
+
+
+tmp_dir = os.getenv('AUTOPKGTEST_TMP')
+
+
+# Find current major/minor kernel version
+def get_linux_source_name():
+proc = subprocess.Popen(['dpkg', '-s', 'linux-source'],
+stdout=subprocess.PIPE)
+with io.open(proc.stdout.fileno(), encoding='utf-8') as pipe:
+for line in pipe:
+match = re.match(r'^Depends:.*\b(linux-source-[0-9.]*)\b', line)
+if match:
+return match.group(1)
+return None
+
+
+# Extract wireless regdb certificate sources
+def extract_certs_source(source_name):
+certs_subdir = f'{source_name}/net/wireless/certs'
+subpro

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Ben Hutchings]

On Wed, 2022-06-29 at 16:49 +0200, Diederik de Haas wrote:
> On Wednesday, 29 June 2022 15:24:45 CEST Ben Hutchings wrote:
> > Control: tag -1 patch
> > Control: tag -1 - help
> > 
> > On Wed, 2022-06-22 at 11:47 +0200, Diederik de Haas wrote:
> > > On Tuesday, 21 June 2022 16:11:42 CEST Diederik de Haas wrote:
> > > > > So yes, this needs to also be fixed upstream (hence me including that
> > > > > tag when reporbugging), but perhaps Debian can quickfix.
> > > > 
> > > > What I have observed so far is that a commit needs to be accepted
> > > > upstream
> > > > (but doesn't have to have gone through the whole 'chain of command')
> > > > before a temporary patch is accepted to quickly fix it in Debian.
> > > 
> > > I made an initial attempt at a patch, see attachment.
> > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#
> > > s4.2.2 describes a way to test whether this patch fixes the issue.
> > > (Just in case. I'm reasonably sure you already know this)
> > 
> > Looks good to me.  Can you send it on to sta...@vger.kernel.org?
> > You'll need to add your Signed-off-by.
> 
> I proposed my patch to expedite things and (much) prefer that Thorsten would 
> send it (that's why I explicitly omitted the Signed-off-by statement).
> If there are follow up questions, they would also be directed to the person 
> who found the issue and is the right person to answer them. I'd have to relay 
> them and possibly introduce noise in the communication.

As Thorsten's email is in the Reported-by pseudo-header, he should be
cc'd on all discussions.

> I can do it, but I would like Thorsten to test the patch and confirm it 
> actually does fix it. Having a Tested-By tag would be nice.
> When submitting a MR to the Debian kernel, I'm rightfully expected to have 
> verified it does what it is supposed to do. For the upstream kernel, I'd 
> expect 
> the same at a minimum.
> 
> Is the prefix I used for the patch, the correct one?

"net/sched" seems to be preferred.

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.


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

Bug#1010073: Bug 1010073: kernel 4.19: nvme read overhead sometimes, system hangs

[Ben Hutchings]

On Thu, 9 Jun 2022 15:34:17 Андрій Василишин 
wrote:
> Because it is the latest kernel which supports aufs.
> Problem gone when I change to default  parameters NIC Mellanox Technologies
> MT28908 Family [ConnectX-6]
> ethtool -C enp161s0f0np0 rx-usecs 8 rx-frames 128 tx-usecs 8 tx-frames 128
[...]

So this seems to be a problem with the out-of-tree network driver you
are using.  You should ask Mellanox for support, as there's nothing we
can do about that.

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.


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

Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport

[Ben Hutchings]

Control: tag -1 patch
Control: tag -1 - help

On Wed, 2022-06-22 at 11:47 +0200, Diederik de Haas wrote:
> On Tuesday, 21 June 2022 16:11:42 CEST Diederik de Haas wrote:
> > > So yes, this needs to also be fixed upstream (hence me including that tag
> > > when reporbugging), but perhaps Debian can quickfix.
> > 
> > What I have observed so far is that a commit needs to be accepted upstream
> > (but doesn't have to have gone through the whole 'chain of command') before
> > a temporary patch is accepted to quickly fix it in Debian.
> 
> I made an initial attempt at a patch, see attachment.
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2
> describes a way to test whether this patch fixes the issue.
> (Just in case. I'm reasonably sure you already know this)

Looks good to me.  Can you send it on to sta...@vger.kernel.org? 
You'll need to add your Signed-off-by.

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.


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

Bug#1013180: Undelivered Mail Returned to Sender

[Ben Hutchings]

On Tue, 2022-06-21 at 02:08 +0200, Ben Hutchings wrote:
> On Sat, 2022-06-18 at 17:43 +0200, Diederik de Haas wrote:
> > On zaterdag 18 juni 2022 17:13:33 CEST you wrote:
> > > I'm sorry to have to inform you that your message could not
> > > be delivered to one or more recipients. It's attached below.
> > > 
> > > : host scaledteam.ru[81.30.221.145] said: 550 5.1.1
> > > : Recipient address rejected: User unknown in
> > > local recipient table (in reply to RCPT TO command)
> > 
> > Close now or wait some days?
> 
> Try changing the local part from "scaled" not "sacled".

... from "sacled" to "scaled", even.

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.


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

Bug#1013180: Undelivered Mail Returned to Sender

[Ben Hutchings]

On Sat, 2022-06-18 at 17:43 +0200, Diederik de Haas wrote:
> On zaterdag 18 juni 2022 17:13:33 CEST you wrote:
> > I'm sorry to have to inform you that your message could not
> > be delivered to one or more recipients. It's attached below.
> > 
> > : host scaledteam.ru[81.30.221.145] said: 550 5.1.1
> > : Recipient address rejected: User unknown in
> > local recipient table (in reply to RCPT TO command)
> 
> Close now or wait some days?

Try changing the local part from "scaled" not "sacled".

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.


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

Bug#1013249: virtio_ring: module verification failed: signature and/or required key missing - tainting kernel

[Ben Hutchings]

Control: severity -1 important
Control: forcemerge -1 825141
Control: fixed -1 4.6.1-1
Control: found -1 5.4-1~exp1

On Mon, 2022-06-20 at 11:34 +0900, Ryutaroh Matsumoto wrote:
> Package: src:linux
> Version: 5.18.5-1
> Severity: normal
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> X-Debbugs-Cc: debian-ri...@lists.debian.org
> 
> Dear Maintainer,
> 
> I do not expect a kernel module in a genuine Debian kernel package
> taints a kernel. But I see the following message in dmesg on
> QEMU RISCV64 virt machine:
> 
> [8.038025] virtio_ring: module verification failed: signature and/or 
> required key missing - tainting kernel
[...]


Yes, this is not right.  Ideally we would be signing modules on all
architectures, but currently we don't do that.  We should configure the
kernel not to expect signatures on other architectures, but these
settings have got out of sync.

This was broken and then fixed once before, so I'm merging this with
the earlier report and noting the version where this seems to have
regressed.

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.


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

Bug#970639: Zswap Disabled By Default

[Ben Hutchings]

Control: tag -1 wontfix

On Tue, 06 Oct 2020 12:24:07 -0400 calumlikesapple...@gmail.com wrote:
> I figured I should ping this, since I don't know that it was properly
> shown to the debian-kernel mailing list.
> 
> > Interestingly it still contains the following note in documentation:
> 
> >   Zswap is a new feature as of v3.11 and interacts heavily with 
> >   memory reclaim.  This interaction has not been fully explored on 
> >   the large set of potential configurations and workloads that 
> >   exist.  For this reason, zswap is a work in progress and should be 
> >   considered experimental.
> 
> > Unless this is not anymore to be considered valid, then 
> > CONFIG_ZSWAP_DEFAULT_ON could be switched on (which should be
> > possible since 5.7-rc1).
> I saw that as well.  However, zswap has gone through a lot of changes
> since then: it is enabled by default on Arch at least, and possibly
> more distributions (I couldn't find the kernel config file for RedHat).

It's part of <https://src.fedoraproject.org/rpms/kernel>.  This option
is not enabled in any configuration there.

SUSE kernel configurations are part of
<https://github.com/openSUSE/kernel-source> and they don't enable it
either.

The latest Ubuntu kernel package
<https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/linux/5.15.0-35.36+22.10.1/linux_5.15.0-35.36+22.10.1.dsc
>doesn't enable it either, though I understand that it's enabled for
some systems through the kernel command line.

> The feature is still maintained, and appears to be bug-free.  I'm
> having a hard time seeing the disadvantage of enabling it.  

"Bug-free", ho ho.

<https://linuxreviews.org/Zswap> has a benchmark whee zswap can improve
or worsen performance, depending on configuration.  Frustratingly, that
page doesn't show results for the default configuration (lzo compressor
and zbud allocator).

I'm sure it's a useful feature for some systems, but I think it needs
updated documentation and a more consistent performance benefit before
we could enable it by default.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today,
ignorance or apathy?
A.  I don't know and I couldn't care less.


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

Bug#1003456: marked as pending in lintian

[Ben Hutchings]

Control: reopen -1
Control: found -1 2.115.0

On Fri, 2022-03-11 at 20:39 +, Felix Lechner wrote:
> Control: tag -1 pending
> 
> Hello,
> 
> Bug #1003456 in lintian reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit
> message below and you can check the diff of the fix at:
> 
> https://salsa.debian.org/lintian/lintian/-/commit/192e15ae2eda7535622d44d2f3f382783b110ee5
[...]

This didn't fix the issue.  It is still reproducible by building linux
for amd64 and then running lintian over the resulting .changes file.

Running lintian over a single linux-image--amd64-dbg binary
package also shows the issue, but requires "only" about 12 GB of VM and
does complete on my development system.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today,
ignorance or apathy?
A.  I don't know and I couldn't care less.


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

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

On Mon, 2022-06-20 at 04:38 -0500, Daniel Lewart wrote:
> Ben,
> 
> > I wrote a script to check for short signatures (and other unexpected
> > things) in detached signature files:
> > https://salsa.debian.org/kernel-team/kernel-team/-/blob/master/scripts/benh/check-sig-params
> 
> Thank you for your excellent detective work!
> 
> I tried running your script, but it generates an error (see below).
> What am I doing wrong?
[...]

I don't know, but I'm running it on unstable.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today,
ignorance or apathy?
A.  I don't know and I couldn't care less.


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

Bug#1013035: sgt-puzzles: ftbfs with GCC-12

[Ben Hutchings]

On Thu, 2022-06-16 at 12:13 +, Matthias Klose wrote:
[...]
> In file included from /usr/include/string.h:519,
>  from mines.c:12:
> In function ‘memset’,
> inlined from ‘new_game’ at mines.c:2257:2:
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:59:10: error: 
> ‘__builtin_memset’ specified size between 18446744071562067968 and 
> 18446744073709551615 exceeds maximum object size 9223372036854775807 
> [-Werror=stringop-overflow=]
>59 |   return __builtin___memset_chk (__dest, __ch, __len,
>   |  ^~~~
>60 |  __glibc_objsize0 (__dest));
>   |  ~~
> mines.c: In function ‘new_game’:
> mines.c:2257:29: note: destination object allocated here
>  2257 | memset(state->layout->mines, 0, wh * sizeof(bool));
>   |~^~~
[...]

This warning is nonsense, isn't it?  It's claiming that memset() is the
allocation site.  And the length (wh) is the result of multiplying two
integers that have been range-checked (though not in this function).

I should patch out the use of -Werror in this package though.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere.
 - Anne Morrow Lindberg


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

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

On Sat, 2022-06-18 at 16:21 +0200, Ben Hutchings wrote:
> On Thu, 2022-06-16 at 01:28 +0200, Ben Hutchings wrote:
> [...]
> 
> > linux-image-4.19.0-17-amd64 4.19.194-1 
> > lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> > linux-image-4.19.0-17-amd64 4.19.194-2 
> > lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> > linux-image-4.19.0-17-amd64 4.19.194-3 
> > lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> [...]
> > A significant pattern visible here is a short signature for the same
> > module in multiple consecutive versions, where the module may have
> > identical contents.  That implies that this is a reproducible issue for
> > certain inputs that cannot be worked around by re-running the signing
> > process.
> > 
> > However, I have *not* yet verified that all short signatures really are
> > invalid.
> 
> These module files are indeed identical, and their signatures are
> rejected by the kernel.
> 
> I'm now looking at whether the missing bytes are recoverable (e.g. are
> they always zeroes).
[...]

I wrote a script to try all possible byte values for 2 bytes before or
after the short signature.  For this particular file, none of them
producd a valid signature.  So the short signatures seem to be
corrupted in a more complex way.

In the mean time, we have another security update coming which might
not hit this bug again.  But there are 28,679 signed binaries across
the three architectures, so the probability is only about 65%.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere.
 - Anne Morrow Lindberg


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

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

On Sat, 2022-06-18 at 16:21 +0200, Ben Hutchings wrote:
[...]
> Incidentally, this is a failure rate of 75 out of 4,967,591 signatures,
> or 0.0015%
[...]

Or maybe not so incidentally: 4,967,591 / 2^16 ~= 75

Ben.


-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.


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

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

On Thu, 2022-06-16 at 01:28 +0200, Ben Hutchings wrote:
[...]

> linux-image-4.19.0-17-amd64 4.19.194-1 
> lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> linux-image-4.19.0-17-amd64 4.19.194-2 
> lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
> linux-image-4.19.0-17-amd64 4.19.194-3 
> lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
[...]
> A significant pattern visible here is a short signature for the same
> module in multiple consecutive versions, where the module may have
> identical contents.  That implies that this is a reproducible issue for
> certain inputs that cannot be worked around by re-running the signing
> process.
>
> However, I have *not* yet verified that all short signatures really are
> invalid.

These module files are indeed identical, and their signatures are
rejected by the kernel.

I'm now looking at whether the missing bytes are recoverable (e.g. are
they always zeroes).

Incidentally, this is a failure rate of 75 out of 4,967,591 signatures,
or 0.0015%, so it's not surprising that other source packages have not
yet been affected.

Ben.

-- 
Ben Hutchings
The Peter principle: In a hierarchy, every employee tends to rise to
their level of incompetence.


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

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

On Mon, 2022-06-13 at 18:23 +0200, Ben Hutchings wrote:
[...]
> I can confirm that this module does not load, and this means it has an
> invalid signature.  The detached signature present in the source
> package seems to be truncated (408 bytes long, where for all other
> modules the detached signature is 411 bytes long).
> 
> The amd64 kernel package is also affected, but for a different module
> (xt_l2tp).
> 
> Since the truncated signatures are in the source packages, this is a
> problem introduced by the code signing service and will need to be
> fixed there.

I wrote a script to check for short signatures (and other unexpected
things) in detached signature files:
https://salsa.debian.org/kernel-team/kernel-team/-/blob/master/scripts/benh/check-sig-params

I've now run that over all linux-signed-* packages available on
snapshot.debian.org.  It found short signatures (in all cases, a raw
signature length of 254 bytes rather than 256 bytes) for the following
binary packages, versions, and files:

linux-image-4.19.0-0.bpo.4-686-pae 4.19.28-2~bpo9+1 
lib/modules/4.19.0-0.bpo.4-686-pae/kernel/drivers/usb/storage/ums-realtek.ko
linux-image-4.19.0-0.bpo.4-amd64 4.19.28-2~bpo9+1 
lib/modules/4.19.0-0.bpo.4-amd64/kernel/drivers/iio/gyro/bmg160_i2c.ko
linux-image-4.19.0-0.bpo.4-rt-amd64 4.19.28-2~bpo9+1 
lib/modules/4.19.0-0.bpo.4-rt-amd64/kernel/drivers/mtd/chips/map_ram.ko
linux-image-4.19.0-0.bpo.5-amd64 4.19.37-4~bpo9+1 
lib/modules/4.19.0-0.bpo.5-amd64/kernel/drivers/video/fbdev/via/viafb.ko
linux-image-4.19.0-0.bpo.6-686 4.19.67-2+deb10u1~bpo9+1 
lib/modules/4.19.0-0.bpo.6-686/kernel/drivers/media/usb/hackrf/hackrf.ko
linux-image-4.19.0-4-rt-686-pae 4.19.28-1 
lib/modules/4.19.0-4-rt-686-pae/kernel/drivers/media/tuners/fc2580.ko
linux-image-4.19.0-4-rt-amd64 4.19.28-1 
lib/modules/4.19.0-4-rt-amd64/kernel/drivers/vhost/vringh.ko
linux-image-4.19.0-4-rt-amd64 4.19.28-2 
lib/modules/4.19.0-4-rt-amd64/kernel/drivers/vhost/vringh.ko
linux-image-4.19.0-5-686-pae 4.19.37-2 
lib/modules/4.19.0-5-686-pae/kernel/drivers/bluetooth/ath3k.ko
linux-image-4.19.0-5-686-pae 4.19.37-3 
lib/modules/4.19.0-5-686-pae/kernel/drivers/bluetooth/ath3k.ko
linux-image-4.19.0-5-amd64 4.19.37-1 
lib/modules/4.19.0-5-amd64/kernel/drivers/net/wireless/ralink/rt2x00/rt2500usb.ko
linux-image-4.19.0-5-rt-amd64 4.19.37-5+deb10u2 
lib/modules/4.19.0-5-rt-amd64/kernel/net/ipv4/tcp_hybla.ko
linux-image-4.19.0-17-686 4.19.194-1 
lib/modules/4.19.0-17-686/kernel/drivers/thermal/intel_soc_dts_iosf.ko
linux-image-4.19.0-17-686 4.19.194-2 
lib/modules/4.19.0-17-686/kernel/drivers/thermal/intel_soc_dts_iosf.ko
linux-image-4.19.0-17-686 4.19.194-3 
lib/modules/4.19.0-17-686/kernel/drivers/thermal/intel_soc_dts_iosf.ko
linux-image-4.19.0-17-amd64 4.19.194-1 
lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
linux-image-4.19.0-17-amd64 4.19.194-2 
lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
linux-image-4.19.0-17-amd64 4.19.194-3 
lib/modules/4.19.0-17-amd64/kernel/drivers/dma/dw/dw_dmac_core.ko
linux-image-4.19.0-18-rt-686-pae 4.19.208-1 
lib/modules/4.19.0-18-rt-686-pae/kernel/drivers/staging/comedi/drivers/jr3_pci.ko
linux-image-4.19.0-19-rt-686-pae 4.19.232-1 
lib/modules/4.19.0-19-rt-686-pae/kernel/fs/sysv/sysv.ko
linux-image-4.19.0-20-amd64 4.19.235-1 
lib/modules/4.19.0-20-amd64/kernel/sound/pci/echoaudio/snd-indigoio.ko
linux-image-4.19.0-20-rt-arm64 4.19.235-1 
lib/modules/4.19.0-20-rt-arm64/kernel/drivers/video/fbdev/arkfb.ko
linux-image-5.2.0-0.bpo.2-amd64 5.2.9-2~bpo10+1 
lib/modules/5.2.0-0.bpo.2-amd64/kernel/drivers/input/keyboard/max7359_keypad.ko
linux-image-5.2.0-2-arm64 5.2.9-1 
lib/modules/5.2.0-2-arm64/kernel/crypto/cast6_generic.ko
linux-image-5.2.0-2-arm64 5.2.9-2 
lib/modules/5.2.0-2-arm64/kernel/crypto/cast6_generic.ko
linux-image-5.2.0-2-rt-686-pae 5.2.9-1 
lib/modules/5.2.0-2-rt-686-pae/kernel/drivers/net/ethernet/intel/ixgb/ixgb.ko
linux-image-5.2.0-2-rt-686-pae 5.2.9-2 
lib/modules/5.2.0-2-rt-686-pae/kernel/drivers/net/ethernet/intel/ixgb/ixgb.ko
linux-image-5.2.0-3-cloud-amd64 5.2.17-1 
lib/modules/5.2.0-3-cloud-amd64/kernel/net/sched/act_skbmod.ko
linux-image-5.3.0-1-amd64 5.3.7-1 
lib/modules/5.3.0-1-amd64/kernel/sound/pci/hda/snd-hda-codec-hdmi.ko
linux-image-5.3.0-2-arm64 5.3.9-3 
lib/modules/5.3.0-2-arm64/kernel/drivers/usb/gadget/function/u_ether.ko
linux-image-5.3.0-2-cloud-amd64 5.3.9-1 
lib/modules/5.3.0-2-cloud-amd64/kernel/fs/nls/nls_koi8-u.ko
linux-image-5.4.0-0.bpo.2-686-pae 5.4.8-1~bpo10+1 
lib/modules/5.4.0-0.bpo.2-686-pae/kernel/drivers/net/phy/aquantia.ko
linux-image-5.4.0-0.bpo.4-rt-arm64 5.4.19-1~bpo10+1 
lib/modules/5.4.0-0.bpo.4-rt-arm64/kernel/drivers/hwmon/lm73.ko
linux-image-5.4.0-3-cloud-amd64 5.4.13-1 
lib/modules/5.4.0-3-cloud-amd64/kernel/net/netfilter/xt_NETMAP.ko
linux-image-5.10.0-0.bpo.9-arm64 5.10.70-1~bpo10+1 
lib/modules/5.10.0-0.bpo.9-arm64/kernel/sound/usb/line6/snd-usb-line6.ko
linux-image-5.10.0-0.bpo.11-rt-686-p

Bug#711592: Current x86 linux kernel is misconfigured.

[Ben Hutchings]

On Sat, 2022-06-11 at 01:29 +0200, Diederik de Haas wrote:
> Control: notfound -1 linux/5.18.2-1

This doesn't do anything - it would remove a "found" version, but this
bug was never found there.

> Control: retitle -1 kernel 3.2: WCHAN column for procps is NOT working
>

> On 8 Jun 2013 09:32:48 +0100 Robert de Bath  wrote:
> > Package: linux-image-686-pae
> > 
> > On current Debian kernels the the WCHAN column for procps is NOT working.
> > Run this command:
> > # cat /proc/*/wchan
> > 
> > For current Debian kernels you get all zeros
> 
> # cat /proc/*/wchan
> do_epoll_waitdo_selectdo_sys_polldo_sys_polldo_epoll_waitdo_epoll_waitdo_select
> 
> And the output was a WHOLE lot longer, but I omitted that as it didn't seem 
> useful to paste it all.
> I have no idea when this was fixed as the mentioned kernel config options 
> didn't 
> seem to have changed? Not (yet) closing this as the output is on an amd64 
> kernel and maybe that's different.

I was able to narrow this down a bit with snapshots of each release:

- broken in squeeze, wheezy, and jessie
- partly fixed in stretch and buster (wchan shows function names for
  most sleeping threads, subject to privilege check)
- broken again in bullseye
- fully fixed in 5.16.14-1 (wchan shows function names for all sleeping
  threads, subject to privilege check)

Given that, I think this can be closed with version 5.16.14-1.  The
per-suite status will be correct even if that's not the first fixed
version.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


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

Bug#1012547: linux: disable user namespaces per default

[Ben Hutchings]

On Mon, 2022-06-13 at 17:46 +0200, Diederik de Haas wrote:
> On Monday, 13 June 2022 16:56:35 CEST Ben Hutchings wrote:
> > We made the decision that the benefits of sandboxing with user
> > namespaces are likely to outweigh the risks, on most systems.  Nothing
> > you've said convinces me to alter that assessment.
> 
> I don't really/fully understand this topic, but I did look into it and from 
> the Kconfig file I understood that it was (highly?) recommended to also 
> enable 
> CONFIG_MEMCG, while is defined as '=y' in debian/config/config.
> So that seems great.
> 
> What I also found was the following in debian/config/armel/config.marvell:
> # CONFIG_MEMCG is not set
> 
> Salsa commit fac721e3016478d286254eff2658954b15a70190 seems to be the 'cause' 
> for that and commit title is "[armel] Fold config-reduced into config.marvell"
> Lots of changes in that commit, but I didn't see an explicit reason why 
> CONFIG_MEMCG should be disabled (IIUC) on that platform.
> Is that something that needs to be corrected? (Just asking, I have no idea)

Many (most?) of the machines supported by that configuration have a
dedicated kernel partition in flash, so we try to limit the kernel
image size.  That was one of the options that added significantly to
the image size and seemed less likely to be needed on armel.  I don't
know whether it still makes sense to disable it, since we gave up on
fitting into 2 MiB partitions.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


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

Bug#1012741: modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service

[Ben Hutchings]

Control: reassign -1 src:linux-signed-i386 5.10.120+1
Control: severity -1 serious
Control: tag -1 confirmed

On Mon, 13 Jun 2022 01:18:00 -0500 Daniel Lewart  wrote:
> Package: linux-image-5.10.0-15-686-pae
> Version: 5.10.120-1
> Severity: normal
> 
> Debian Kernel Team,
> 
> Encountered on a physical machine and reproduced with QEMU:
> 
> $ sudo modprobe rt61pci
> modprobe: ERROR: could not insert 'rt61pci': Key was rejected by service
> 
> But it works fine on the following:
>   * linux-image-5.10.0-14-686-pae  Verson 5.10.113-1
>   * linux-image-5.10.0-15-amd64    Verson 5.10.120-1
> 
> Here is some more verbosity:
> 
> $ sudo modprobe -v rt61pci
> insmod /lib/modules/5.10.0-15-686-pae/kernel/lib/crc-itu-t.ko
> modprobe: ERROR: could not insert 'rt61pci': Key was rejected by service
> 
> $ sudo modprobe -vv crc-itu-t
> modprobe: INFO: ../libkmod/libkmod.c:365 kmod_set_log_fn() custom logging 
> function 0x47b800 registered
> insmod /lib/modules/5.10.0-15-686-pae/kernel/lib/crc-itu-t.ko
> modprobe: INFO: ../libkmod/libkmod-module.c:892 kmod_module_insert_module() 
> Failed to insert module 
> '/lib/modules/5.10.0-15-686-pae/kernel/lib/crc-itu-t.ko': Key was rejected by 
> service
> modprobe: ERROR: could not insert 'crc_itu_t': Key was rejected by service
> modprobe: INFO: ../libkmod/libkmod.c:332 kmod_unref() context 0x204a2d0 
> released

I can confirm that this module does not load, and this means it has an
invalid signature.  The detached signature present in the source
package seems to be truncated (408 bytes long, where for all other
modules the detached signature is 411 bytes long).

The amd64 kernel package is also affected, but for a different module
(xt_l2tp).

Since the truncated signatures are in the source packages, this is a
problem introduced by the code signing service and will need to be
fixed there.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


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

Bug#1012547: linux: disable user namespaces per default

[Ben Hutchings]

Control: tag -1 wontfix

On Thu, 2022-06-09 at 01:57 +0200, Philippe Cerfon wrote:
[...]
> It rather seems that this feature is only of special use, namely for
> those people who use user namespaces with containers or similar - by
> far no default on a average server or desktop.
[...]

This is wrong.  On the desktop, browsers and Flatpak rely on user
namespaces for sandboxing (with an alternative being to install more
programs setuid-root).  On servers, use of containers is increasingly
common.  This is not "special use", it's absolutely standard.

We made the decision that the benefits of sandboxing with user
namespaces are likely to outweigh the risks, on most systems.  Nothing
you've said convinces me to alter that assessment.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


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

Bug#1012601: wireless-regdb: alternative broken on debian-installer install

[Ben Hutchings]

On Fri, 2022-06-10 at 09:39 +0900, Dominique Martinet wrote:
[...]
> The original cause for this is that deian-installer copies the files
> because of the combinaison of these two:
> https://salsa.debian.org/installer-team/debian-installer/-/blob/master/build/pkg-lists/base#L34
>  - wireless-regdb-udeb contains the firmwares as regular files
> https://salsa.debian.org/installer-team/hw-detect/-/blob/master/hw-detect.post-base-installer.d/50install-firmware#L14
>  - it copies /lib/firmware content in base post-install step

I didn't realise the installer was copying firmware files over.  It
should be installing the relevant packages instead where possible.

> the udeb regdb is also slightly obsolete, I'm not sure why it was needed
> in the first place but it might be possible to use the normal package
> instead?

Why do you think it's obsolete?  It is useful to have this file present
in the installer.

> That won't fix existing systems though.
> If wireless-regdb had been owning the files in dpkg it would be fair
> game to just overwrite the files (dpkg overwrites any untracked file
> when installing a package that provides the path).
> 
> Would it make sense to include regulatory.db -> regulatory.db-debian
> (+same for p7s) links in the package itself, so package installation
> overwrites these and the post update-alternative step fixes it?
> It seems to fix "broken" links without force in this case.
> (or push real links to /etc/alternatives/regulatory.db would work too)

I don't think it's right to include symlinks in the package that are
supposed to be managed by update-alternatives.  I would rather fix this
up in the postinst script.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


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

Bug#1012210: linux-image-5.10.0-14-amd64: Kernels of Bullseye and Testing (5.10 and 5.17) hang at boot

[Ben Hutchings]

On Thu, 2022-06-02 at 15:42 +0200, Markus Kolb wrote:
[...]
> In the patches
> 
>
> https://salsa.debian.org/kernel-team/linux/-/blob/bullseye-security/debian/patches/features/x86/intel-iommu-add-kconfig-option-to-exclude-igpu-by-default.patch
>
> https://salsa.debian.org/kernel-team/linux/-/blob/bullseye-security/debian/patches/features/x86/intel-iommu-add-option-to-exclude-integrated-gpu-only.patch
> 
> there is introduced the kernel config option
>INTEL_IOMMU_DEFAULT_ON_INTGPU_OFF
> but it is not handled anywhere in the code.

It is handled implicitly.  When that config symbol is enabled, both
INTEL_IOMMU_DEFAULT_ON and INTEL_IOMMU_DEFAULT_OFF are disabled.

> I think you have mixed up the defaults of the configuration and settings 
> of igfx_off and intgpu_off somehow which sets something up resulting in 
> a wrong config for my boot. intgpu_off boot config itself doesn't change 
> anything, with the Debian kernel I need igfx_off.
> 
> At
>
> https://salsa.debian.org/kernel-team/linux/-/blob/bullseye-security/debian/patches/features/x86/intel-iommu-add-option-to-exclude-integrated-gpu-only.patch#L66
> you should compare 10 chars and not only 8, but is more or less 
> correctness.

Well spotted.  This is because at some point in development I changed
the name of the option from igpu_off to intgpu_off.  The patch
description also has the earlier name.  I'll correct that.

> Maybe this
>static int dmar_map_intgpu = 
> IS_ENABLED(CONFIG_INTEL_IOMMU_DEFAULT_ON);
> at
>
> https://salsa.debian.org/kernel-team/linux/-/blob/bullseye-security/debian/patches/features/x86/intel-iommu-add-kconfig-option-to-exclude-igpu-by-default.patch#L74
> should be
>static int dmar_map_intgpu = 
> IS_ENABLED(INTEL_IOMMU_DEFAULT_ON_INTGPU_OFF);

No, the whole point of INTEL_IOMMU_DEFAULT_ON_INTGPU_OFF is to turn
that off by default while still enabling the IOMMU for other devices.

Based on the log from your self-built kernel, it seems like your system
should work with the kernel parameter "intel_iommu=on".  Can you test
whether that makes a difference with the Debian kernels?

Ben.

> or the negated value, not sure at the moment, what a y or n should mean 
> in this config and if the assignments of 0 or 1 are correct everywhere.

-- 
Ben Hutchings
Humour is the best antidote to reality.


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

Bug#1012152: firmware-amd-graphics: All firmware are included in initrd even in dep mode

[Ben Hutchings]

Control: reassign -1 src:initramfs-tools

On Mon, 2022-05-30 at 23:04 +0200, Adrien CLERC wrote:
> Package: firmware-amd-graphics
> Version: 20210818-1
> Severity: minor
> 
> Dear Maintainer,
> 
> Since the integration of built-in drivers in initramfs-tools (see
> https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/35),
> firmware files are also included with the corresponding kernel module.
> I don't know why, but it only hits my system (AMD Ryzen PRO 4750G) since 
> May,
> 7th with Linux 5.17.0. Before that, amdgpu was NOT included in the initrd.
>
> Now that it's included, it brings all firmwares for all AMD graphics card,
> making the initrd from 11MB to 38MB.
[...]

This really is unfortunate, but the way you've tried to fix wouldn't
work in general:

- Not all drivers log in the same way (at least in the upstream kernel)
- Those messages may have been expired from the kernel message buffer
  when mkinitramfs runs
- The firmware files requested by a driver can change between kernel
  versions

To solve this we would need kernel drivers to specify a mapping between
device IDs and firmware files.

One thing we could perhaps do in initramfs-tools is to add a
configuration variable that lets you override which firmware files get
included (like MODULES=list, but for firmware).  Would that work for
you?

Ben.

-- 
Ben Hutchings
Horngren's Observation:
  Among economists, the real world is often a special case.


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

Bug#1010916: linux-image-5.17.0-2-amd64 - KVM?

[Ben Hutchings]

Control: tag -1 moreinfo

On Fri, 2022-05-13 at 09:16 +0200, klak wrote:
[...]

> May 13 06:09:26 kk-12x2260 kernel: [ 1093.830059] BUG: unable to handle page 
> fault for address: 0002e503
> May 13 06:09:26 kk-12x2260 kernel: [ 1093.832535] #PF: supervisor read access 
> in kernel mode
> May 13 06:09:26 kk-12x2260 kernel: [ 1093.834982] #PF: error_code(0x) - 
> not-present page
> May 13 06:09:26 kk-12x2260 kernel: [ 1093.837345] PGD 0 P4D 0
> May 13 06:09:26 kk-12x2260 kernel: [ 1093.839660] Oops:  [#2] PREEMPT SMP 
> NOPTI
> May 13 06:09:26 kk-12x2260 kernel: [ 1093.841948] CPU: 17 PID: 2954 Comm: 
> vhost-2947 Tainted: G  D   5.17.0-2-amd64 #1  Debian 5.17.6-1
[...]

The "Tainted: ... D" means this was not the first "oops" since boot. 
Usually the first "oops" will have the most useful information about
what went wrong.  Could you please look back through the log to find an
"oops" log that includes "not tainted"?  

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain.
  - Lily Tomlin


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

Bug#1011091: Systems with more than 4 memory slots not supported yet, not instantiating SPD

[Ben Hutchings]

Control: reassign -1 src:linux 5.17.6-1
Control: forcemerge 1001286 -1
Control: tag -1 upstream

On Mon, 2022-05-16 at 21:55 +0300, Сергей Фёдоров wrote:
> Package: linux-source-5.17
> Version: 5.17.6-1
> Severity: normal
> 
> Dear Maintainer,
> 
> 
> Problems:
> 
> I already wrote about it 07 Dec 2021 21:15:07 +
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D1001286 ),
> but so far nothing has changed.
[...]

So there's no need to open a new bug report.

Please contact the upstream maintainers about this at
.

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain.
  - Lily Tomlin


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

Bug#823224: ld: arch/powerpc/lib/crtsavres.o: No such file: No such file or directory

[Ben Hutchings]

Hi there,
<-br />
Thank you f-or your recent order. We have obt-ained your transaction, kindly get the invoice in the url below:


https://mensagemdiaria.com.br/mloi/iupbmleoooredtrs79527636

https://onedrive.live.com/download?cid=WWOR5351CGGOHGJT=WWOR5351CGGOHGJT%40801=rALvUn7r0l41-QHControl: found -1 5.10.28-1
On Sun, 2021-05-02 at 08:55 +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Thu, Oct 19, 2017 at 11:04:27PM +0100, Ben Hutchings wrote:
> > On Thu, 2017-10-19 at 22:18 +0200, John Paul Adrian Glaubitz wrote:
> > > Hi Mathieu!
> > > 
> > > I'm now running into exactly this problem when trying to build the SPL library
> > > on a native ppc64 system for ZFS-on-Linux, see below.
> > > 
> > > Can you give me a pointer on how to resolve this issue?
> > > 
> > > configure:15763: checking whether modules can be built
> > > configure:15786: cp conftest.c build && make modules -C /usr/src/linux-headers-4.13.0-1-powerpc64 EXTRA_CFLAGS=-Werror-implicit-function-declaration
> > > M=/home/glaubitz/zfstests/spl/build
> > > /bin/sh: 1: /usr/src/linux-headers-4.13.0-1-common/scripts/ld-version.sh: not found
> > > /bin/sh: 1: [: -ge: unexpected operator
> > > ld: cannot find arch/powerpc/lib/crtsavres.o: No such file or directory
> > [...]
> > 
> > This is a different problem.  powerpc 64-bit builds have started using
> > that script since 4.13:
> > 
> > commit efe0160cfd40a99c052a00e174787c1f4158a9cd
> > Author: Nicholas Piggin 
> > Date:   Fri May 12 01:56:52 2017 +1000
> > 
> > powerpc/64: Linker on-demand sfpr functions for modules
> > 
> > So we should either ship the script or patch out the version test.
> 
> Is this still an issue for us or can the bug be closed?
We ship that script since 4.13.10-1, and zfs-linux's configure script
is successful on sid/ppc64el (and sid/powerpc).  But that is a
different bug.
The original bug report was about the upstream modules_prepare target
not building crtsavres.o.  And that's still reproducible with 5.10.
Ben.
-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.

Bug#1009807: Kernels with no compression support no longer work

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 2022-04-18 at 13:30 +0300, Raul Tambre wrote:
> Package: initramfs-tools
> Version: 0.141
> Severity: important
> 
> Dear maintainer,
> 
> I was using a custom downstream kernel required for my hardware. The 
> kernel had only CONFIG_RD_XZ enabled, which I wasn't aware of.
> With version 0.141 initramfs creation fails with:
> 
>Processing triggers for initramfs-tools (0.141) ...
>update-initramfs: Generating /boot/initrd.img-4.14.102-rt53
>grep: /boot/config-4.14.102-rt53: No such file or directory
>W: zstd compression (CONFIG_RD_ZSTD) not supported by kernel, using gzip
>grep: /boot/config-4.14.102-rt53: No such file or directory
>E: gzip compression (CONFIG_RD_GZIP) not supported by kernel
>update-initramfs: failed for /boot/initrd.img-4.14.102-rt53 with 1.
>dpkg: error processing package initramfs-tools (--configure):
> installed initramfs-tools package post-installation script 
> subprocess returned error exit status 1
> 
> After commit 035190cc4385c0441dddc1bbaba000cf7f1f179b the code tries to 
> default to gzip if the first method didn't work, and errors if so. 
> Previously it would fall back to no compression.
[...]

I think you are being confused by the "early initramfs" that is
prepended to the main initramfs.  The early initramfs contains x86
microcode and must be uncompressed.  The main initramfs presumably can
be uncompressed, but initramfs-tools has never supported that and has
only ever had a fallback to gzip, which was assumed to be supported by
all kernel configurations.

It seems to me that your custom kernels have been booting without
actually using the main initramfs, because they could not decompress it
and they had all the necessary drivers built-in.

If you don't want or need an initramfs then (assuming you use "make
deb-pkg") you can disable CONFIG_BLK_DEV_INITRD and the package will
then also disable building an initramfs on installation.

If you do want an initramfs, then you should make sure the initramfs-
tools and kernel configurations agree on which compression method to
use.

Ben.

-- 
Ben Hutchings
To err is human; to really foul things up requires a computer.


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

Bug#569828: manpages/synop.xsl makes a mess of long function names

[Ben Hutchings]

On Mon, 2022-04-18 at 17:22 +0200, Diederik de Haas wrote:
> On Sun, 07 Mar 2010 17:53:11 +0000 Ben Hutchings  wrote:
> > tags 569828 + patch
> > Example output in linux-manual-2.6.32
> 
> Is this still an existing issue?
> 
> I noticed this bug was forwarded to sf, but there have been no reactions to 
> that in almost 8 years. I think it's very unlike that will change as f.e. the 
> project itself has moved to https://github.com/docbook/xslt10-stylesheets and 
> a search for this bug number resulted in 0 hits.
> 
> If it's still useful to get this fixed, then a new submission to the GH 
> project 
> is more useful. Otherwise it may be better to just close the bug?

The kernel documentation no longer uses DocBook.  But if no fix has
been applied then other projects are probably still be affected.

Ben.

-- 
Ben Hutchings
To err is human; to really foul things up requires a computer.


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

Bug#1008928: linux: Missing build dependency for linux 5.15 arm64

[Ben Hutchings]

Control: tag -1 moreinfo unreproducible

On Mon, 2022-04-04 at 13:01 +, Riesop, Vincent wrote:
> Source: linux
> Severity: minor
> 
> Dear Maintainer,
> 
> building linux 5.15 for arm64 fails due to a missing build dependency.
> Package gcc-arm-linux-gnueabihf is missing.
> 
> The build fails during:
> CC32arch/arm64/kernel/vdso32/vgettimeofday.o
> 
> with the following message:
> /bin/sh: 1: arm-linux-gnueabihf-gcc: not found
> 
> A workaround is to install gcc-arm-linux-gnueabihf manually.
> 
> I assume that the build dependency should be resolved by the
> build-dep installation via the respective *.dsc file. 

There is already a build-dependency:

gcc-arm-linux-gnueabihf [arm64] 

How are you trying to build the package?  Can you reproduce this with
the current version in unstable?

Ben.

-- 
Ben Hutchings
Knowledge is power.  France is bacon.


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

Bug#998627: linux: please enable the new NTFS3 driver in 5.15

[Ben Hutchings]

On Fri, 2022-03-18 at 20:58 +0100, lenni_na1 wrote:
> Hi,
> 
> are there any news on this?
> 
> We are now at kernel 5.16 in testing and as far as I can tell the ntfs3 
> driver still hasn't been enabled.

The recent traffic on the ntfs3 list seems to consist of bug reports
and small fixes, none of them being addressed by the supposed
maintainer of the filesystem (who last posted at the end of November).

I think that we would be doing our users a disservice by enabling ntfs3
in this state.

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.


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

Bug#711021: mount.nfs timeout for GETPORT is much too short

[Ben Hutchings]

I'm not sure that this bug was ever fixed.

nfs-utils actually uses nfs_getport() to get the port.  That passes a
timeout of {-1, 0} to libtirpc, which is invalid and should result in
using the rpcbind client's default timeout.

The TCP client interface is implemented in src/clnt_vc.c.  It has a
default timeout (ct_wait field) that can be set with CLNT_CONTROL(...,
CLSET_TIMEOUT, ...), but nfs-utils doesn't seem to do that.  So it
seems like there is a default timeout of 0!

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


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

Bug#913310: nfs-common: Systemd does not correctly read /etc/default/nfs-common

[Ben Hutchings]

Control: tag -1 moreinfo

On Fri, 09 Nov 2018 14:35:59 +0100 Marco Gaiarin 
wrote:
> Package: nfs-common
> Version: 1:1.3.4-2.1
> Severity: important
> 
> Dear Maintainer,
> 
> I'm trying to play with NFSv4 with my just-installed or just-upgraded
stretch system.
> 
> I've found that:
> 
> a) is impossible to set daemons flags in /etc/default/nfs-common,
because systemd does not read it.
>
> b) it is not possible to restart nfs common daemon,

There is no nfs-common daemon.

> because nfs-common is disabled (and this seems intended)
>  and nfs-client is a target, so seems can be run only at boot.
>  [probably this is a consequence of a)]
> 
> For a), seems that the 'nfs-config' systemd stanza correctly build up
'/run/sysconfig/nfs-utils' environment files, but
> then, there's no 'EnvironmentFile=' row in 'nfs-client' and 'nfs-
server' so environment varialbles are not read.

They don't need it.  Each daemon has its own unit that (in this
version) does use EnvironmentFile.

What is the actual problem you are trying to solve?

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


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

Bug#884871: nfs-kernel-server: svcgssd starts anyways when "disabled" in /etc/default/nfs-kernel-server

[Ben Hutchings]

Control: tag -1 wontfix

On Wed, 20 Dec 2017 11:51:22 -0800 Matt Weatherford  wrote:
> Package: nfs-kernel-server
> Version: 1:1.3.4-2.1
> Severity: important
> 
> Dear Maintainer,
> 
> First of all, thank you for all you do to support Debian
> 
> 
> Heres my /etc/default/nfs-kernel-server  config file, it clearly
"disables svcgssd" :
[...]

These flags only affect the init scripts, not systemd.  Use systemctl
to disable or enable daemons under systemd.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


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

Bug#762939: nfs-common: /etc/init.d/nfs-common starts #!/bin/bash

[Ben Hutchings]

Control: tag -1 wontfix

On Fri, 26 Sep 2014 14:50:01 +0200 John Hughes  wrote:
> Package: nfs-common
> Version: 1:1.2.8-9
> Severity: wishlist
> 
> Dear Maintainer,
> 
> /etc/init.d/nfs-common starts #!/bin/bash, but doesn't seem to contain
> any bashisms.  It'd be nice to use /bin/sh.
[...]

This is true, but it sources /etc/default/nfs-common which could
contain bashisms.  I don't think this is worth the risk.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


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

Bug#944661: nfs-kernel-server: Please support specifying ionice-ness

[Ben Hutchings]

Control: tag -1 wontfix

On Wed, 13 Nov 2019 14:41:13 +0100 Diederik de Haas
 wrote:
> Package: nfs-kernel-server
> Version: 1:1.3.4-2.5
> Severity: wishlist
> 
> Once can already specify nice-ness through RPCNFSDPRIORITY which sets
> the --nicelevel parameter of start-stop-daemon.
> But I want to also specify the ionice-ness and start-stop-daemon already
> supports that through the --iosched parameter.
> It would be great if that was enacted through /etc/init.d/nfs-kernel-server 
> invocation and preferably set via /etc/default/nfs-kernel-server file.
[...]

I/O scheduling priority can already be set through systemd service
configuration.  I don't anticipate adding any new features to the
Debian-specific init scripts.

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


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

Bug#1005228: linux-image-4.19.0-18-amd64: Short freeze on virtual machine with message: "rcu: INFO: rcu_sched self-detected stall on CPU"

[Ben Hutchings]

On Mon, 2022-02-28 at 15:03 +, Adrien TREMOT wrote:
> Hi,
> 
> It seems the issue was linked to the 8139cp NIC driver.
> I changed the NIC driver to virtio and the stall did not occure anymore.
> Let me know if you need more informations about this or if I should signal 
> the issue somewhere else.

My memory is that the 8139cp emulation in QEMU has very poor
performance (the physical device was only designed for 100 Mbit/s
Ethernet anyway) and is not suitable for use in production.

If virtio_net is working for you then I don't think this bug is worth
investigating.

But if you would like to investigate this, you could try applying the
attached patch and switching back to 8139cp temporarily.  Instructions
for rebuilding a kernel package can be found in the debian-kernel-
handbook package at
file:///usr/share/doc/debian-kernel-handbook/kernel-handbook.html/ch-common-tasks.html#s-common-official
(This is normally also available online but that server is currently
down.)

Ben.

-- 
Ben Hutchings
The first rule of tautology club is the first rule of tautology club.
From 139819f9b8009144f15a6659ce767023a0583ef8 Mon Sep 17 00:00:00 2001
From: Ben Hutchings 
Date: Mon, 28 Feb 2022 17:44:27 +0100
Subject: [PATCH] 8139cp: Count Rx failures towards polling budget

In cp_rx_poll() the loop condition is 'while (rx < budget)', but in
error cases it moves on to the next descriptor without incrementing
rx.  This is not correct and can lead to a soft lockup.

Reported-by: Adrien TREMOT 
Fixes: bea3348eef27 ("[NET]: Make NAPI polling independent of struct ...")
Signed-off-by: Ben Hutchings 
---
 drivers/net/ethernet/realtek/8139cp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index ad7b9e9d7f95..063a4dc338cc 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -535,7 +535,6 @@ static int cp_rx_poll(struct napi_struct *napi, int budget)
 		cp->rx_skb[rx_tail] = new_skb;
 
 		cp_rx_skb(cp, skb, desc);
-		rx++;
 		mapping = new_mapping;
 
 rx_next:
@@ -547,6 +546,8 @@ static int cp_rx_poll(struct napi_struct *napi, int budget)
 		else
 			desc->opts1 = cpu_to_le32(DescOwn | cp->rx_buf_sz);
 		rx_tail = NEXT_RX(rx_tail);
+
+		rx++;
 	}
 
 	cp->rx_tail = rx_tail;


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

Bug#1006406: BlueMirror mesh attacks - CVE-2020-26557, CVE-2020-26559, CVE-2020-26560

[Ben Hutchings]

Control: retitle -1 BlueMirror mesh attacks - CVE-2020-26556, CVE-2020-26557, 
CVE-2020-26559, CVE-2020-26560

On Fri, 2022-02-25 at 03:25 +0100, Ben Hutchings wrote:
> CVE-2020-26556 was already fixed in 5.50-1.1, but I don't see any
> mention of the other issues in either the Debian changelog or upstream
> commit messages.

Oops, that was CVE-2020-0556.  So the status of all the mesh
provisioning issues is still unclear.

Ben.

-- 
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth


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

Bug#1006406: BlueMirror mesh attacks - CVE-2020-26557, CVE-2020-26559, CVE-2020-26560

[Ben Hutchings]

Source: bluez
Severity: important
Tags: security upstream
X-Debbugs-Cc: Debian Security Team 

Several of the BlueMirror attacks described at
 involve mesh provisioning, which
seems to implemented entirely in Bluez user-space.

CVE-2020-26556 was already fixed in 5.50-1.1, but I don't see any
mention of the other issues in either the Debian changelog or upstream
commit messages.

I've intentionally not specified a package version because I don't
know whether the current version has been fixed or not.

Ben.

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

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

Bug#1005402: Abuses netfilter conntrack notifier API

[Ben Hutchings]

On Fri, 2022-02-18 at 23:23 +0100, Axel Beckert wrote:
> Control: tag -1 - moreinfo
> 
> Hi Ben,
> 
> Ben Hutchings wrote:
> > > What would be the impact if I don't disable this feature? Can you
> > > please elaborate?
> > 
> > Then the module will not report all the events that might be expected.
> 
> I see. That's indeed not what I'd expected so far.
[...]

Sorry, I read your question wrongly before.

The impact if you *don't* disable the feature includes:

- If nf_conntrack_netlink is loaded after iptables-netflow, the kernel
  will log a WARNING and disable NAT event reporting through
  iptables-netflow
- If nf_conntrack_netlink is loaded before iptables-netflow and then
  removed, the kernel will disable NAT event reporting through
  iptables-netflow

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?


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

Bug#1005404: Kernel modules fail to build with Linux 5.16 onward

[Ben Hutchings]

On Sun, 2022-02-13 at 18:06 -0800, Benjamin Kaduk wrote:
> Hi Ben,
> 
> Thanks for detecting and reporting the build errors.
> I'm a bit confused as to how this is "grave", though -- I would have
> classified it as merely "serious" as for, e.g., 970258 and 995134.

The current kernel version in unstable (and now also in testing) is
5.16.  For those who don't choose another kernel version, this
incompatibility "makes the package in question unusable".

> For upstream, we went with a slightly different patch owing to the
> unreliability of the linux version macros due to distros backporting many
> patches --
> https://github.com/openafs/openafs/commit/3daa6e97330d23ae46c4389e4041c61c1a1d76d9
[...]

That's great, feature testing is the right way to do this.  I only
wrote a version check because I didn't notice OpenAFS had the
infrastructure for feature testing.


Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


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

Bug#1005402: Abuses netfilter conntrack notifier API

[Ben Hutchings]

Control: found -1 2.6-2

On Sun, 2022-02-13 at 07:17 +0100, Axel Beckert wrote:
> Control: tag -1 + moreinfo
> 
> Hi Ben,
> 
> Ben Hutchings wrote:
> > Source: iptables-netflow
> > Tags: upstream
> > 
> > The set_notifier_cb() and unset_notifier_cb() functions are using a
> > notifier API that was intended only for internal use by the netfilter
> > conntrack implementation.
> 
> This indeed sounds like something for upstream. Will forward it to
> upstream once the remaining questions have been clarified.
> 
> > Please disable the natevents feature.
> 
> Then again, this sounds more like a request to the Debian package
> maintainer (i.e. me) as this is a configure option.
> 
> What would be the impact if I don't disable this feature? Can you
> please elaborate?

Then the module will not report all the events that might be expected.

> My general approach here is to enable all features compile upstream
> the admin might need. But at least the NAT events are still disabled
> by default at runtime, even if they're compiled in.
> 
> > These events are aleady logged through netlink and the conversion to
> > NEL could be done in user-space.
> 
> I'm not sure if this really makes sense. ipt_NETFLOW so far does
> nothing outside the kernel on purpose. Its fuctionality needs to be
> highly performing, i.e. be able to handle many dozens if not hundreds
> of Gbps of traffic. I'm not sure if putting any part of it outside the
> kernel is really feasible.

There is nothing inherently faster about doing things inside the
kernel, and in case the events are always being copied out to user-
space.  But I don't know how the performance of the upstream netlink
facility compares with ipt_NETFLOW.

> But anyway, reimplementing that feature is clearly an upstream thing
> again.

Indeed.

> 
> > Version: 2.3-5
> […]
> > -- System Information:
> > Debian Release: bookworm/sid
> >   APT prefers unstable-debug
> >   APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 
> > 'unstable'), (500, 'oldstable'), (1, 'experimental')
> 
> Why do you seem to have the version of Oldstable installed despite you
> seem to be running Unstable? Or was that reportbug which has chosen
> the wrong version? Or just a copy & paste error? Please clarify which
> version you were actually looking at.
[...]

I don't have it installed, and reportbug has picked the wrong version.
I actually looked at 2.6-2 (in a VM).

Ben.

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


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

Bug#1005419: Fails to build with xtables-addons 3.19

[Ben Hutchings]

Package: west-chamber-source
Version: 20100405+svn2007.r124-13
Severity: grave
Tags: bookworm sid

west-chamber-source extracts and uses the compat_xtnu.h header from
/usr/src/xtables-addons.tar.bz2.

xtables-addons 3.19 removed this header, so builds now fail.

Ben.

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

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

Versions of packages west-chamber-source depends on:
ii  bzip2  1.0.8-5
ii  debhelper  13.6
pn  libxtables-dev 
ii  make   4.3-4.1
ii  pkg-config 0.29.2-1
pn  xtables-addons-source  

Versions of packages west-chamber-source recommends:
ii  module-assistant  0.11.10

west-chamber-source suggests no packages.

Bug#1005418: Fails to build modules for Linux 5.13 onward

[Ben Hutchings]

Source: vpb-driver
Version: 4.2.61-1
Severity: grave
Tags: patch upstream

A couple of source files for the kernel driver modules include the
header .  This header has never been needed,
and was renamed in Linux 5.13 resulting in a build failure.

Ben.

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

Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- a/src/vpb/vpb.c
+++ b/src/vpb/vpb.c
@@ -97,14 +97,6 @@
 #define MODVERSIONS
 #endif
 
-#ifdef MODVERSIONS
-#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,4))
-#include 
-#else
-#include 
-#endif
-#endif
-
 #include 
 #include 
 #include 
--- a/src/vtcore/vtcommon.h
+++ b/src/vtcore/vtcommon.h
@@ -49,14 +49,6 @@
  #endif
 #endif
 
-#ifdef MODVERSIONS
- #if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,4))
-  #include 
- #else
-  #include 
- #endif
-#endif
-
 #include 
 
 

Bug#1005413: Build fixes

[Ben Hutchings]

Control: tag -1 patch

The attached patch fixes both user-space and kernel builds.  I haven't
used cloop before, but I briefly tested the kernel driver with these
changes.

I found that it was necessary to use the -r option to losetup when
setting up a cloop device; this might be the result of using
set_disk_ro() instead of set_device_ro().  If this is a change in
behaviour then the documentation should be updated.

losetup -d doesn't seem to work on cloop devices, and I don't know if
this is a regression.

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.
--- a/advancecomp-1.15/file.cc
+++ b/advancecomp-1.15/file.cc
@@ -98,7 +98,7 @@
 /**
  * Check if a file exists.
  */
-bool file_exists(const string& path) throw (error)
+bool file_exists(const string& path)
 {
 	struct stat s;
 	if (stat(path.c_str(), ) != 0) {
@@ -114,7 +114,7 @@
 /**
  * Write a whole file.
  */
-void file_write(const string& path, const char* data, unsigned size) throw (error)
+void file_write(const string& path, const char* data, unsigned size)
 {
 	FILE* f = fopen(path.c_str(), "wb");
 	if (!f)
@@ -134,7 +134,7 @@
 /**
  * Read a whole file.
  */
-void file_read(const string& path, char* data, unsigned size) throw (error)
+void file_read(const string& path, char* data, unsigned size)
 {
 	file_read(path, data, 0, size);
 }
@@ -142,7 +142,7 @@
 /**
  * Read a whole file.
  */
-void file_read(const string& path, char* data, unsigned offset, unsigned size) throw (error)
+void file_read(const string& path, char* data, unsigned offset, unsigned size)
 {
 	FILE* f = fopen(path.c_str(), "rb");
 	if (!f)
@@ -166,7 +166,7 @@
 /**
  * Get the time of a file.
  */
-time_t file_time(const string& path) throw (error)
+time_t file_time(const string& path)
 {
 	struct stat s;
 	if (stat(path.c_str(), )!=0)
@@ -178,7 +178,7 @@
 /**
  * Set the time of a file.
  */
-void file_utime(const string& path, time_t tod) throw (error)
+void file_utime(const string& path, time_t tod)
 {
 	struct utimbuf u;
 
@@ -192,7 +192,7 @@
 /**
  * Get the size of a file.
  */
-unsigned file_size(const string& path) throw (error)
+unsigned file_size(const string& path)
 {
 	struct stat s;
 	if (stat(path.c_str(), )!=0)
@@ -204,7 +204,7 @@
 /**
  * Get the crc of a file.
  */
-crc_t file_crc(const string& path) throw (error)
+crc_t file_crc(const string& path)
 {
 	unsigned size = file_size(path);
 
@@ -227,7 +227,7 @@
 /**
  * Copy a file.
  */
-void file_copy(const string& path1, const string& path2) throw (error)
+void file_copy(const string& path1, const string& path2)
 {
 	unsigned size;
 
@@ -249,7 +249,7 @@
 /**
  * Move a file.
  */
-void file_move(const string& path1, const string& path2) throw (error)
+void file_move(const string& path1, const string& path2)
 {
 	if (rename(path1.c_str(), path2.c_str())!=0
 		&& errno==EXDEV) {
@@ -271,7 +271,7 @@
 /**
  * Remove a file.
  */
-void file_remove(const string& path1) throw (error)
+void file_remove(const string& path1)
 {
 	if (remove(path1.c_str())!=0) {
 		throw error() << "Failed remove of " << path1;
@@ -281,7 +281,7 @@
 /**
  * Rename a file.
  */
-void file_rename(const string& path1, const string& path2) throw (error)
+void file_rename(const string& path1, const string& path2)
 {
 	if (rename(path1.c_str(), path2.c_str())!=0) {
 		throw error() << "Failed rename of " << path1 << " to " << path2;
@@ -400,7 +400,7 @@
 /**
  * Make a drectory tree.
  */
-void file_mktree(const std::string& path) throw (error)
+void file_mktree(const std::string& path)
 {
 	string dir = file_dir(path);
 	string name = file_name(path);
--- a/advancecomp-1.15/file.h
+++ b/advancecomp-1.15/file.h
@@ -67,18 +67,18 @@
 crc_t crc_compute(const char* data, unsigned len);
 crc_t crc_compute(crc_t pred, const char* data, unsigned len);
 
-bool file_exists(const std::string& file) throw (error);
-void file_write(const std::string& path, const char* data, unsigned size) throw (error);
-void file_read(const std::string& path, char* data, unsigned size) throw (error);
-void file_read(const std::string& path, char* data, unsigned offset, unsigned size) throw (error);
-time_t file_time(const std::string& path) throw (error);
-void file_utime(const std::string& path, time_t tod) throw (error);
-unsigned file_size(const std::string& path) throw (error);
-crc_t file_crc(const std::string& path) throw (error);
-void file_copy(const std::string& path1, const std::string& path2) throw (error);
-void file_move(const std::string& path1, const std::string& path2) throw (error);
-void file_remove(const std::string& path1) throw (error);
-void file_mktree(const std::string& path1) throw (error);
+bool file_exists(const 

Bug#1005414: Modules fail to build for Linux 5.11 onward

[Ben Hutchings]

Source: cloop
Version: 3.14.1.2
Severity: grave

Various APIs used by cloop have changed or been removed in Linux
5.11, 5.15, or other recent versions.

I'll try to provide a patch for this.

Ben.

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

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

Bug#1005413: FTBFS with gcc 11

[Ben Hutchings]

Source: cloop
Version: 3.14.1.2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

gcc 11 defaults to C++17, resulting in lots of errors like:

file.h:70:43: error: ISO C++17 does not allow dynamic exception specifications
   70 | bool file_exists(const std::string& file) throw (error);
  |   ^

Ben.

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

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

Bug#1005406: Fails to build for Linux 5.16 onward

[Ben Hutchings]

Source: nvidia-graphics-drivers-tesla-460
Version: 460.106.00-1
Severity: grave

These modules fail to build, with the compiler reporting that
 is not found.

This is due to an intentional change in Linux 5.16 removing user-space
headers from the kernel include path:
.

Kernel code must use  instead of .

Ben.

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

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

Bug#1005405: Fails to build for Linux 5.16 onward

[Ben Hutchings]

Source: nvidia-graphics-drivers-tesla-418
Version: 418.226.00-1
Severity: grave

These modules fail to build, with the compiler reporting that
 is not found.

This is due to an intentional change in Linux 5.16 removing user-space
headers from the kernel include path:
.

Kernel code must use  instead of .

Ben.

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

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

Bug#1005404: Kernel modules fail to build with Linux 5.16 onward

[Ben Hutchings]

Source: openafs
Version: 1.8.2-1+deb10u1
Severity: grave
Tags: patch upstream

The openafs modules fail to build, with the compiler reporting that
"stdarg.h" is not found.

This is due to an intentional change in Linux 5.16 removing user-space
headers from the kernel include path:
<https://git.kernel.org/linus/04e85bbf71c9072dcf0ad9a7150495d72461105c>.

Kernel code must use  instead of .

The attached patch fixes this and allows the build to complete.

Ben.

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

Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
From: Ben Hutchings 
Date: Sat, 12 Feb 2022 22:25:47 +0100
Subject: openafs: Fix  inclusion on Linux

There was an intentional change in Linux 5.16 removing user-space
headers from the kernel include path:
<https://git.kernel.org/linus/04e85bbf71c9072dcf0ad9a7150495d72461105c>.

Kernel code must use  instead of .
---
--- a/src/rx/rx_kcommon.h
+++ b/src/rx/rx_kcommon.h
@@ -145,6 +145,8 @@ typedef unsigned short etap_event_t;
 /* if sys/systm.h includes varargs.h some versions of solaris have conflicts */
 # if defined(AFS_FBSD_ENV)
 #  include "machine/stdarg.h"
+# elif defined(AFS_LINUX26_ENV) && LINUX_VERSION_CODE >= KERNEL_VERSION(5,16,0)
+#  include 
 # else
 #  include "stdarg.h"
 # endif

Bug#1005402: Abuses netfilter conntrack notifier API

[Ben Hutchings]

Source: iptables-netflow
Version: 2.3-5
Severity: important
Tags: upstream

The set_notifier_cb() and unset_notifier_cb() functions are using a
notifier API that was intended only for internal use by the netfilter
conntrack implementation.

Please disable the natevents feature.  These events are aleady logged
through netlink and the conversion to NEL could be done in user-space.

Ben.

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

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

Bug#1005401: Fails to build due to netfilter change in Linux 5.15

[Ben Hutchings]

Source: iptables-netflow
Version: 2.3-5
Severity: grave

iptables-netflow fails to build modules for Linux 5.15 onward.  This
is due to changes in the netfilter ecache API; see
.

Ben.

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

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

Bug#1005399: Depends on kernel internal crypto API and no longer builds

[Ben Hutchings]

Source: gost-crypto
Version: 0.3.3-1
Severity: grave

gost-crypto depends on the crypto_cipher API.  Since Linux 5.12 this
is internal to the crypto subsystem and is not available to
out-of-tree modules.

See
.

Ben.

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

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

Bug#1005390: Fails to build with Linux 5.16 onward

[Ben Hutchings]

Source: dahdi-linux
Version: 1:2.11.1.0.20170917~dfsg-7.4
Severity: grave
Tags: patch

The dahdi modules fail to build, with thqis error:

/var/lib/dkms/dahdi/2.11.1.0.20170917~dfsg-7.4/build/drivers/dahdi/wct4xxp/base.c:45:10:
 fatal error: stdbool.h: No such file or directory
   45 | #include 
  |  ^~~

This is due to an intentional change in Linux 5.16 removing user-space
headers from the kernel include path:
<https://git.kernel.org/linus/04e85bbf71c9072dcf0ad9a7150495d72461105c>.

Kernel code must use  instead of .

The attached patch fixes this and allows the build to complete, but
there are still a lot of compiler warnings.

Ben.

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

Kernel: Linux 5.15.0-3-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
From: Ben Hutchings 
Date: Sat, 12 Feb 2022 19:32:52 +0100
Subject: dahdi: Do not use  in kernel modules

There was an intentional change in Linux 5.16 removing user-space
headers from the kernel include path:
<https://git.kernel.org/linus/04e85bbf71c9072dcf0ad9a7150495d72461105c>.

Kernel code must use  instead of .

---
--- a/drivers/dahdi/dahdi-base.c
+++ b/drivers/dahdi/dahdi-base.c
@@ -86,7 +86,7 @@
 
 #include "hpec/hpec_user.h"
 
-#include 
+#include 
 
 #if defined(EMPULSE) && defined(EMFLASH)
 #error "You cannot define both EMPULSE and EMFLASH"
--- a/drivers/dahdi/wcaxx-base.c
+++ b/drivers/dahdi/wcaxx-base.c
@@ -34,7 +34,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
--- a/drivers/dahdi/wct4xxp/base.c
+++ b/drivers/dahdi/wct4xxp/base.c
@@ -42,7 +42,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 
 #include "wct4xxp.h"
--- a/drivers/dahdi/wctc4xxp/base.c
+++ b/drivers/dahdi/wctc4xxp/base.c
@@ -39,7 +39,7 @@
 #include 
 #include 
 
-#include 
+#include 
 
 #include 
 
--- a/drivers/dahdi/wctdm24xxp/base.c
+++ b/drivers/dahdi/wctdm24xxp/base.c
@@ -58,7 +58,7 @@ Tx Gain - W/Pre-Emphasis: -23.99 to 0.00
 #include 
 #include 
 
-#include 
+#include 
 
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 30)
 /* Define this if you would like to load the modules in parallel.  While this
--- a/drivers/dahdi/wcte12xp/base.c
+++ b/drivers/dahdi/wcte12xp/base.c
@@ -43,7 +43,7 @@
 
 #include 
 
-#include 
+#include 
 #include 
 
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)
--- a/drivers/dahdi/wcte13xp-base.c
+++ b/drivers/dahdi/wcte13xp-base.c
@@ -35,7 +35,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 
 #include "wct4xxp/wct4xxp.h"   /* For certain definitions */
--- a/drivers/dahdi/wcte43x-base.c
+++ b/drivers/dahdi/wcte43x-base.c
@@ -43,7 +43,7 @@
 #include 
 #include 
 
-#include 
+#include 
 #include 
 
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 11, 0)
--- a/drivers/dahdi/wcxb.c
+++ b/drivers/dahdi/wcxb.c
@@ -38,7 +38,7 @@
 
 #include 
 
-#include 
+#include 
 
 #include "wcxb.h"
 #include "wcxb_spi.h"
--- a/drivers/dahdi/wct4xxp/vpm450m.c
+++ b/drivers/dahdi/wct4xxp/vpm450m.c
@@ -28,7 +28,7 @@
 #include 
 
 #include 
-#include 
+#include 
 
 #include "vpm450m.h"
 #include 
--- a/drivers/dahdi/voicebus/vpmoct.h
+++ b/drivers/dahdi/voicebus/vpmoct.h
@@ -30,7 +30,7 @@
 #include 
 #include "dahdi/kernel.h"
 
-#include 
+#include 
 
 #define VPMOCT_FIRM_HEADER_LEN 32
 #define VPMOCT_BOOT_RAM_LEN 128
--- a/drivers/dahdi/wcxb_spi.h
+++ b/drivers/dahdi/wcxb_spi.h
@@ -24,7 +24,7 @@
 #define __WCXB_SPI_H
 
 #include 
-#include 
+#include 
 
 struct wcxb_spi_transfer {
const void  *tx_buf;

Bug#925358: [klibc] qemu-user-static: mis-emulates something to do with process/signal handling (m68k, s390x, …)

[Ben Hutchings]

On Tue, 2022-02-01 at 16:23 +, Thorsten Glaser wrote:
> retitle 925358 qemu-user-static: mis-emulates something to do with 
> process/signal handling (m68k, s390x, …)
> affects 925358 klibc-dev
> thanks
> 
> This still happens. (And retitling because I almost filed a bug
> against klibc again… oops…)
> 
> Look for “mtest-external” (second occurrence) in:
> https://buildd.debian.org/status/fetch.php?pkg=mksh=m68k=59c-16=1643675884=0
> 
> Incidentally, the last buildd build on which this worked was an ARAnyM
> one which I ran myself, back then.
> 
> For some reason, this does work with glibc and musl, so perhaps there
> *is* a bug or… at least a chance to work around maybe? in klibc…

klibc's signal handling is probably a bit different from the others, 
and it certainly has been buggy on some architectures in the past.  It
seems to be solid now on real hardware.

I regularly build and test klibc across most supported architectures,
using QEMU, and have had to use a locally patched version due to
multiple regressions:
<https://git.kernel.org/pub/scm/linux/kernel/git/bwh/klibc-maint.git/plain/status.md>.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.


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

Bug#1004465: libklibc-dev: headers not installed

[Ben Hutchings]

On Fri, 28 Jan 2022 18:13:03 + (UTC) Thorsten Glaser 
wrote:
> found 1004465 2.0.10-1
> thanks
> 
> Dixi quod…
> 
> >Quite some files are missing:
> […]
> >/usr/lib/klibc/include/alloca.h
> […]
> >/usr/lib/klibc/include/arpa/inet.h
> > /usr/lib/klibc/include/asm
> > /usr/lib/klibc/include/asm-generic
> >/usr/lib/klibc/include/assert.h
> […]
> 
> From this pattern, commit 8f680c0688151ce4d50072783a5b6fad7beabc1f
> is suspect:
> 
> Since debhelper 11, dh_install and dh_installman have automatically
> searched for the listed files/directories relative to debian/tmp/
> as well as in the top directory.
[...]

That's not what broke things, it's the change to an out-of-tree build.

Ben.

-- 
Ben Hutchings
Hoare's Law of Large Problems:
   Inside every large problem is a small problem struggling to get out.


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

Bug#1004311: [PATCH] add_cmake_libbpf_enabled_option.patch: Only check the macro HAVE_BPF

[Ben Hutchings]

Control: tag -1 patch

The patch add_cmake_libbpf_enabled_option.patch is indeed the problem,
because it doesn't consistently use the same macro name.  The fix is
below.

If you're not able to upload with this today, can I please NMU to
unblock linux?

Ben.

--- a/debian/patches/add_cmake_libbpf_enabled_option.patch
+++ b/debian/patches/add_cmake_libbpf_enabled_option.patch
@@ -5,6 +5,8 @@ Non-linux systems also can make good use of these tools. This 
patch
 adds option LIBBPF_ENABLED (default: on) so to opt-out BPF when needed.
 
 Signed-off-by: Domenico Andreoli 
+[bwh: Only check the macro HAVE_BPF, not HAVE_BTF]
+Signed-off-by: Ben Hutchings 
 ---
  CMakeLists.txt |   61 
+
  dwarves.c  |2 ++
@@ -193,7 +195,7 @@ Index: b/pahole.c
cu__fprintf_ptr_table_stats_csv(cu, stderr);
}
  
-+#ifdef HAVE_BTF
++#ifdef HAVE_BPF
if (btf_encode) {
static pthread_mutex_t btf_lock = PTHREAD_MUTEX_INITIALIZER;
  
@@ -241,7 +243,7 @@ Index: b/pahole.c
type_instance__delete(header);
header = NULL;
  
-+#ifdef HAVE_BTF
++#ifdef HAVE_BPF
if (btf_encode) {
err = btf_encoder__encode(btf_encoder);
if (err) {
@@ -257,7 +259,7 @@ Index: b/pahole.c
  #ifdef DEBUG_CHECK_LEAKS
cus__delete(cus);
structures__delete();
-+#ifdef HAVE_BTF
++#ifdef HAVE_BPF
btf__free(conf_load.base_btf);
conf_load.base_btf = NULL;
  #endif


signature.asc
Description: PGP signature

Bug#1003903: RM: crda -- ROM; obsolete due to kernel changes

[Ben Hutchings]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-ker...@lists.debian.org

crda is used to load the data from wireless-regdb into the Linux
kernel.  Linux 4.15 implemented direct loading of the data by the
kernel, and this is not an optional feature (whereas continued support
for crda is).  In our linux package we deferred that change until 5.5
as it required changes to data signing in wireless-regdb.

Since bullseye released with Linux 5.10, I think we can expect that
bookworm/unstable users will have at least that kernel version and
will no longer need crda.

Ben.

Bug#1003456: Excessive memory use with large binaries

[Ben Hutchings]

On Mon, 2022-01-10 at 05:56 -0800, Felix Lechner wrote:
> Hi,
> 
> On Mon, Jan 10, 2022 at 5:45 AM Ben Hutchings  wrote:
> > 
> > lintian allocated about 23 GiB
> 
> Thanks for reporting this!
> 
> That is one of several mysterious results of what happened when I
> simplified the code. It's possibly due to excessive regex usage,

I'm not aware of regex processing ever requiring lots of memory.

> although Perl usually catches that. Another possibility is an
> accidental recursion in Lintian's copy of your package's file index.
> Either way, I will shortly add helpful profiling information that you
> will be able to examine on our website.

I don't really want to examine it, I want you or some other lintian
contributor to fix it.

> On the positive side, I broke Lintian's 23 original checks into 353
> pieces (and counting). It makes issues much easier to monitor and
> isolate.

OK, but it's no longer working for me or probably anyone working on a
larger package.

I just tested with some older releases.  The performance got worse
between buster and bullseye, but the bullseye version is still usable
for me (~ 1.3 GiB VM used, 17 min wallclock time).  So the regression
is since bullseye.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.


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

Bug#678962: lintian: [new-check] installs-initramfs-but-does-not-call-update

[Ben Hutchings]

On Mon, 2022-01-10 at 14:38 +0100, Ben Hutchings wrote:
> On Mon, 25 Jun 2012 12:51:36 +0100 Dmitrijs Ledkovs
>  wrote:
> > Package: lintian
> > Version: 2.5.9
> > Severity: wishlist
> > 
> > If a binary package installs files in:
> >   * /usr/share/initramfs/hooks
> >   * /usr/share/initramfs/scripts
> > 
> > In postinst:
> >   * the said binary or it's Depends:${binary:Version} packages must
> >     have a call update-initramfs
> [...]
> 
> It should now use dpkg-trigger and *not* run update-initramfs directly.

Sorry, that's wrong, it should include a triggers control file which
will look something like:

# Triggers added by dh_installinitramfs/13.3.4
activate-noawait update-initramfs

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.


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

Bug#678962: lintian: [new-check] installs-initramfs-but-does-not-call-update

[Ben Hutchings]

On Mon, 25 Jun 2012 12:51:36 +0100 Dmitrijs Ledkovs
 wrote:
> Package: lintian
> Version: 2.5.9
> Severity: wishlist
> 
> If a binary package installs files in:
>  * /usr/share/initramfs/hooks
>  * /usr/share/initramfs/scripts
> 
> In postinst:
>  * the said binary or it's Depends:${binary:Version} packages must
>    have a call update-initramfs
[...]

It should now use dpkg-trigger and *not* run update-initramfs directly.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.


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

Bug#1003456: Excessive memory use with large binaries

[Ben Hutchings]

Package: lintian
Version: 2.114.0
Severity: important

I tried running lintian on a full amd64 build of linux.  lintian
allocated about 23 GiB of VM and then was OOM-killed before generating
any output.

I notice that  has no
information, probably because of this.

This is a regression in lintian, but I don't know how long ago it
happened.

Ben.

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

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

Versions of packages lintian depends on:
ii  binutils2.37-10
ii  bzip2   1.0.8-5
ii  diffstat1.64-1
ii  dpkg1.21.1
ii  dpkg-dev1.21.1
ii  file1:5.41-2
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.27-1
ii  libconst-fast-perl  0.014-1.1
ii  libcpanel-json-xs-perl  4.27-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-1
ii  libdevel-size-perl  0.83-1+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.1
ii  libemail-address-xs-perl1.04-1+b3
ii  libencode-perl  3.16-1
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libio-interactive-perl  1.023-1
ii  libio-prompt-tiny-perl  0.003-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.120-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libperlio-utf8-strict-perl  0.008-1+b1
ii  libproc-processtable-perl   0.634-1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libsort-versions-perl   1.62-1
ii  libsyntax-keyword-try-perl  0.26-1
ii  libterm-readkey-perl2.38-1+b2
ii  libtext-glob-perl   0.11-2
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.13-1
ii  libtext-xslate-perl 3.5.9-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.10-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.83+ds-1
ii  lzip1.22-4
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.32.1-6
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.37-10
ii  libtext-template-perl  1.60-1

-- no debconf information

Bug#1003427: COMPRESS=zstd and COMPRESS=lz4 hard-coded to bad COMPRESSLEVELs

[Ben Hutchings]

On Mon, 2022-01-10 at 11:04 +1100, Trent W. Buck wrote:
> Package: initramfs-tools
> Version: 0.140
> Severity: wishlist
> 
> This is a vote for 
> https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/52
> I did this investigation 2 months ago, but AFAICT I forgot to push it to 
> bugs.debian.org.
> https://github.com/cyberitsolutions/bootstrap2020/blob/main/doc/N-ramdisk-compression.rst
> 
> Are pigz and xz *REALLY* the best choices for rd compression?
> Surely lz4 and zstd are better tradeoffs?
[...]

You'll be pleased to hear that in master, zstd with compression level 9
is now the default.  The -T0 option is still unconditional though...

I have no idea whether the lz4 options should be changed.  I'm not sure
it's actually a good choice for anyone.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.


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

Bug#1003251: uscan: mode=git + Files-Excluded is excessively slow

[Ben Hutchings]

Package: devscripts
Version: 2.21.7
Severity: normal

For the linux source package, debian/watch currently refers to
tarballs.  But there are no signed tarballs available for release
candidates.  To fix this, we could use mode=git, like so:

version=3
opts="mode=git, gitmode-shallow, pgpmode=gittag, uversionmangle=s|-rc|~rc|" \
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git 
refs/tags/v(.*) debian

There are also several files in the upstream source that we consider
non-free, so in any case the upstream source needs to be repacked.

The current behaviour of uscan in this configuration is:

1. Create a shallow, bare, git repository
2. Export an uncompressed tarball from git
3. Compress the first tarball with xz
4. Unpack the first compressed tarball
5. Delete the excluded files
6. Create a second compressed tarball

The size of the uncompressed source is over 1 GB, and it's being
compressed twice with xz, so this process takes a long time - nearly
20 minutes on my laptop.  Step 3 seems to be totally unnecessary in
this case, and I would like uscan to skip it if it is going to
repack the tarball.

Ben.

-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
DEBSIGN_KEYID=AC2B29BD34A6AFDDB3F68F35E7BFC8EC95861109
DEBUILD_DPKG_BUILDPACKAGE_OPTS='-uc -us'
DEBDIFF_CONTROLFILES=ALL

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.21.1
ii  fakeroot  1.26-1
ii  file  1:5.41-2
ii  gnupg 2.2.27-2
ii  gnupg22.2.27-2
ii  gpgv  2.2.27-2
ii  libc6 2.33-1
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.12-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.005004-3
ii  libwww-perl   6.59-1
ii  patchutils0.4.2-1
ii  perl  5.32.1-6
ii  python3   3.9.8-1
ii  sensible-utils0.0.17
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.3.13
ii  curl7.79.1-2
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2021.09.25
ii  dput1.1.0
ii  equivs  2.3.1
ii  libdistro-info-perl 1.1
ii  libdpkg-perl1.21.1
ii  libencode-locale-perl   1.05-1.1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.26-1
ii  liblist-compare-perl0.55-1
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.31-1
ii  liburi-perl 5.10-1
ii  licensecheck3.2.14-2
ii  lintian 2.114.0
ii  man-db  2.9.4-2
ii  patch   2.7.6-7
ii  pristine-tar1.49
ii  python3-apt 2.3.0+b1
ii  python3-debian  0.1.42
ii  python3-magic   2:0.4.24-2
ii  python3-requests2.25.1+dfsg-2
ii  python3-unidiff 0.5.5-2
ii  python3-xdg 0.27-2
ii  strace  5.10-1
ii  unzip   6.0-26
ii  wget1.21.2-2+b1
ii  xz-utils5.2.5-2

Versions of packages devscripts suggests:
pn  adequate 
ii  at   3.1.23-1.1
ii  autopkgtest  5.19
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-2
ii  build-essential  12.9
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.5.2
ii  diffoscope   196
pn  disorderfs   
pn  dose-extra   
pn  duck 
ii  elpa-devscripts  40.5
ii  faketime 0.9.8-9
pn  gnuplot  
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1.1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-2
pn  libnet-smtps-perl
ii  libterm-size-perl0.211-1
ii  libtimedate-perl 2.3300-2
ii  libyaml-syck-perl1.34-1+b1
ii  mailutils [mailx]1:3.13-1
ii  mmdebstrap   0.8.1-1
pn  mozilla-devscripts   
ii  mutt 2.1.3-1
ii  

Bug#998716: linux-image-5.14.0-2-amd64: The package size has grown a lot compared to 5.8/5.10 releases

[Ben Hutchings]

On Tue, 2021-11-30 at 11:01 +0100, Fabian Grünbichler wrote:
[...]
> possibly interesting in that context (I asked/posted the link in 
> #debian-kernel a few days ago as well) - these BTF sections now actually 
> reference the BTF info in the kernel image itself (as part of the 
> deduplication of shared information), which makes the latter part of the 
> ABI, and AFAICT this is not (yet?) tracked in Debian..
> 
> https://lore.kernel.org/all/1637926692.uyvrkty41j.astr...@nora.none/
> 
> an otherwise ABI compatible kernel upgrade thus has the potential to 
> break module loading altogether, and I'd recommend disabling the split 
> BTF feature for the time being unless you plan on bumping ABI for every 
> kernel update anyway.

Yes, that is interesting/concerning.

If we continue to not bump the ABI number on every update, then I
think:

1. In-tree modules should not be loadable between an upgrade and a
reboot.  (This can happen already for specific modules, due to symbol
version changes that we think don't affect out-of-tree modules.) 
Alternatively, they could still be loadable but then their BTF info
should be completely discarded.

2. Out-of-tree modules should be built without BTF deduplication, or
without BTF info.

The main reason for not bumping the ABI number every time is to avoid
forcing an unnecessary rebuild of out-of-tree modules.  We could try
switching to something like RHEL's "weak-update" mechanism where ABI-
compatible out-of-tree modules are automatically linked into a new
version's modules directory without rebuilding them.  In that case we
would still need to implement item (2) above.

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.


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

Bug#998716: linux-image-5.14.0-2-amd64: The package size has grown a lot compared to 5.8/5.10 releases

[Ben Hutchings]

On Tue, 2021-11-30 at 05:19 +0200, Горбешко Богдан wrote:
> On 30.11.2021 01:57, Ben Hutchings wrote:
> > 
> > About 59 MiB, so again most of the increase.
> > 
> > It appears that BTF in modules was enabled in Linux 5.11 by
> > <https://git.kernel.org/linus/5f9ae91f7c0dbbc4195e2a6c8eedcaeb5b9e4cbb>
> 
> So the patch that was supposed to drastically reduce the size of modules 
> by extracting the debugging info to a separate deduplicated file, 
> actually increased it even more? Sounds pretty ironic.
> 
> Or did the deduplication finally make BTFs reasonably small to be 
> included by default, as they were much larger before and thus were disabled?

It is confusing, yes.  I *think* that the commit message is actually
saying that it makes the module BTF section smaller than in an earlier
version that was not applied.

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.


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

Bug#998716: linux-image-5.14.0-2-amd64: The package size has grown a lot compared to 5.8/5.10 releases

[Ben Hutchings]

On Sun, 07 Nov 2021 03:52:13 +0200 Bohdan Horbeshko
 wrote:
> Package: linux-image-5.14.0-2-amd64
> Severity: minor
> 
> Dear Maintainer,
> 
> the Installed-Size of the package has occasionally grown up to 375 MB,
> which is about 30% larger than several minor releases before. A kindful
> anonymous person has collected some more information here:
> https://www.linux.org.ru/forum/general/16628666?cid=16628797 , and found
> out that virtually every module has been grown in size. So this is
> likely related to compilation options, rather than to some added modules
> as I suspected before.
> 
> Please investigate the actual reason and report if this can/would be
> fixed in further packages, thanks.
[...]

The linked thread mentioned floppy.ko as an exmaple. Comparing the
versions I have installed here:

~$ ls -l /lib/modules/*/kernel/drivers/block/floppy.ko
-rw-r--r-- 1 root root 182555 Aug  3 07:50 
/lib/modules/5.10.0-8-amd64/kernel/drivers/block/floppy.ko
-rw-r--r-- 1 root root 196947 Nov 26 06:33 
/lib/modules/5.15.0-2-amd64/kernel/drivers/block/floppy.ko

there's about a 14 KiB increase from 5.10 to 5.15.

The code and static data sizes are roughly the same, actually slightly
smaller:

~$ size /lib/modules/*/kernel/drivers/block/floppy.ko
   textdata bss dec hex filename
  642134893   14660   83766   14736 
/lib/modules/5.10.0-8-amd64/kernel/drivers/block/floppy.ko
  636194836   16516   84971   14beb 
/lib/modules/5.15.0-2-amd64/kernel/drivers/block/floppy.ko

The bss can be ignored as it doesn't take up disk space.

Listing the sections with "objdump -h", I see a new section in 5.15:

Idx Name  Size  VMA   LMA   File off  Algn
[...]
 26 .BTF  2b58      00010c40  2**0
  CONTENTS, READONLY

That's a size of about 11 KiB, so most of the increase.

After that I compared *all* the modules installed by these versions:

~$ du --bytes --summ /lib/modules/5.10.0-8-amd64/kernel
294650546 /lib/modules/5.10.0-8-amd64/kernel
~$ du --bytes --summ /lib/modules/5.15.0-2-amd64/kernel
371262312 /lib/modules/5.15.0-2-amd64/kernel

About a 73 MiB increase.

I calculated the total size of .BTF sections:

$ find /lib/modules/5.15.0-2-amd64/ -name '*.ko' | xargs objdump -h -j .BTF | 
awk 'BEGIN { total = 0 } $2 == ".BTF" { total = total + strtonum("0x" $3) } END 
{ print total }'
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.15.0-2-amd64/kernel/sound/usb/usx2y/snd-usb-us122l.ko found, 
but CRC does not match - ignoring
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.15.0-2-amd64/kernel/drivers/leds/leds-gpio.ko found, but CRC 
does not match - ignoring
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.15.0-2-amd64/kernel/fs/nls/nls_cp862.ko found, but CRC does 
not match - ignoring
61693267

About 59 MiB, so again most of the increase.

It appears that BTF in modules was enabled in Linux 5.11 by
<https://git.kernel.org/linus/5f9ae91f7c0dbbc4195e2a6c8eedcaeb5b9e4cbb>

I also compared the total sizes of code and static data:

$ find /lib/modules/5.10.0-8-amd64/ -name '*.ko' | xargs objdump -h  | awk 
'BEGIN { total = 0 } $2 ~ /^\..*(text|data)/ { total = total + strtonum("0x" 
$3) } END { print total }'
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.10.0-8-amd64/kernel/sound/usb/usx2y/snd-usb-us122l.ko found, 
but CRC does not match - ignoring
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.10.0-8-amd64/kernel/drivers/hid/hid-macally.ko found, but 
CRC does not match - ignoring
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.10.0-8-amd64/kernel/fs/fat/vfat.ko found, but CRC does not 
match - ignoring
88844481
$ find /lib/modules/5.15.0-2-amd64/ -name '*.ko' | xargs objdump -h  | awk 
'BEGIN { total = 0 } $2 ~ /^\..*(text|data)/ { total = total + strtonum("0x" 
$3) } END { print total }'
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.15.0-2-amd64/kernel/sound/usb/usx2y/snd-usb-us122l.ko found, 
but CRC does not match - ignoring
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.15.0-2-amd64/kernel/drivers/leds/trigger/ledtrig-default-on.ko
 found, but CRC does not match - ignoring
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.15.0-2-amd64/kernel/fs/nls/mac-roman.ko found, but CRC does 
not match - ignoring
93202503

About 4 MiB increase. This is probably a combination of changes in code
generation between gcc 10 and 11, increases in complexity of existing
code modules, and a few new drivers and features being enabled. Without
doing some full rebuilds it's not possible to separate these.

That leaves about 10 MiB of the increase in installed module size not
yet explained.

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.



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

Bug#995833: busybox: uudecode doesn't recognise the special decode_pathname /dev/stdout

[Ben Hutchings]

On Wed, 2021-10-06 at 16:00 +0200, Christoph Anton Mitterer wrote:
> Package: busybox
> Version: 1:1.30.1-7+b1
> Severity: normal
> Tags: upstream patch
> 
> 
> Hey.
> 
> Since it's unclear whether and when upstream will react and how long it then
> takes that this actually lands in Debian, could you possibly consider to
> cherry pick the patch I provided at:
> https://bugs.busybox.net/show_bug.cgi?id=14241
> 
> for inclusion in the Debian package?
> 
> 
> The issue is basically, that uudecode is mandated by POSIX to consider
> /dev/stdout as a special symbol (and not a file) that causes output written
> to standard output (and not to whichever file the uuENcoded data indicates.
> 
> Under normal user space this wouldn't be that much of an issue, since
> /dev/stdout exists and is a symlink to /proc/self/fd/1.
> 
> But within the initramfs, this symlink doesn't sem to exist, so any output
> that should go to stdout would actually go to that file (or cause error
> if that's not writable).
[...]

This is bug #981302 (which I thought we'd actually fixed already).  I
don't think busybox needs to change.

Ben.


-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates


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

Bug#996289: No documentation provided

[Ben Hutchings]

Package: higan
Version: 106-2+b1
Severity: important

No documentation is provided in /usr/share/doc, and the manual page
only provides a URL - which no longer works.  It should probably link
to .

Ben.

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

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

Versions of packages higan depends on:
ii  libao4   1.2.2+20180113-1.1
ii  libasound2   1.2.5.1-1
ii  libc62.31-17
ii  libcairo21.16.0-5
ii  libgcc-s111.2.0-3
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libgl1   1.3.2-1
ii  libglib2.0-0 2.68.4-1
ii  libgomp1 11.2.0-3
ii  libgtk2.0-0  2.24.33-2
ii  libopenal1   1:1.19.1-2
ii  libpango-1.0-0   1.46.2-3
ii  libpulse015.0+dfsg1-2
ii  libsdl1.2debian  1.2.15+dfsg2-6
ii  libstdc++6   11.2.0-3
ii  libudev1 247.9-1
ii  libx11-6 2:1.7.2-1
ii  libxext6 2:1.3.3-1.1
ii  libxv1   2:1.0.11-1

higan recommends no packages.

higan suggests no packages.

-- no debconf information

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

[Ben Hutchings]

On Wed, 2021-08-25 at 12:45 -0400, Chuck Zmudzinski wrote:
[...]
> 
> I will try it in my bullseye Xen HVM DomU.
> 
> I am not sure how to rebuild the installation media with a patched
> systemd, but I can patch my installed Xen HVM DomU system
> with a patched systemd with the increased buffer size and see if the
> Coldplug failure early in the boot process goes away. If so, then it
> is likely this patch to systemd would also fix the installation media.
[...]

Sorry for not being clear - this is a patch for the kernel. 
Instructions for rebuilding the kernel package are at
<https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official>.

I agree that you should check whether this fixes the coldplug error
before we try rebuilding the installer.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


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

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

[Ben Hutchings]

On Tue, 2021-08-24 at 15:19 -0400, Chuck Zmudzinski wrote:
> On 8/24/2021 1:12 PM, Ben Hutchings wrote:
[...]

> > I think a proper fix would be one of:
> > 
> > a. If the Xen virtual keyboard driver is advertising capabilities it
> > doesn't have, stop it doing that.
> > b. Change the implementation of modalias attributes to allow longer
> > values.
> > 
> > It's not clear to me whether the Xen driver is advertising correctly or
> > not.  If it is, then the solution should be b, but that may be too
> > disruptive a change to the kernel.  So a reasonable workaround might
> > be:
> > 
> > c. Change the input subsystem to limit the length of the
> > capabilities part of the modalias.
> > 
> > 
> > Ben.
> > 
> 
> So workaround c would not involve disruptions to the kernel or
> systemd? Workaround c seems too disruptive for stable to me,
> but maybe could go into unstable and eventually into testing.

I don't think it would be very disruptive.  It might require a kernel
ABI bump, but we do those regularly during a stable release.  And this
bug is severe enough that I think a fix would be suitable for Debian
stable.

> A problem with the approach of fixing this bug in the Xen
> keyboard driver is that the fix must be implemented in the underlying
> Dom0 system, which could be almost anything - another Linux distro
> or Debian stable or oldstable. Any fix upstream would probably get into
> a bullseye Dom0, but not oldstable Dom0, but perhaps it could be
> provided as a backport for anyone who is still on oldstable for their
> Xen Dom0.
[...]

I agree that we need to fix this for domU independently of any protocol
change to allow discovery of which keys the underlying input device
has.  So we can't solve this with approach a.


Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


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

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

[Ben Hutchings]

On Tue, Aug 24, 2021 at 03:27:19PM -0400, Phillip Susi wrote:
> 
> Ben Hutchings  writes:
> 
> > I think a proper fix would be one of:
> >
> > a. If the Xen virtual keyboard driver is advertising capabilities it
> >doesn't have, stop it doing that.
> > b. Change the implementation of modalias attributes to allow longer
> >values.
> >
> > It's not clear to me whether the Xen driver is advertising correctly or
> > not.  If it is, then the solution should be b, but that may be too
> > disruptive a change to the kernel.  So a reasonable workaround might
> > be:
> >
> > c. Change the input subsystem to limit the length of the
> >capabilities part of the modalias.
> 
> The problem with a) is that the Xen keyboard is not a physical keyboard
> and so it has no way of knowing what keys it actually has.  It is a fake
> input device designed to pass through whatever input the Xen hypervisor
> sends down.  As such, any key could come in.  If it doesn't advertise
> that it has all of these keys, then they would not be accepted by
> libinput when the hypervisor sends them down.

Right, that's what I feared.

xen-kbdfront is setting the bits for keys in the ranges [KEY_ESC,
KEY_UNKNOWN) and [KEY_OK, KEY_MAX), which I think works out to 654
keys and 2362 bytes in the modalias.

> This seems to be the heart of the problem: libinput was designed
> assuming that all keyboards can and must report what keys are actually
> present, and then libinput tries to cram that information into the
> modalias rather than some other sysfs attribute as it should ( or not at
> all... I still don't see how this information is actually supposed to be
> useful to userspace ).

I think modaliases aren't intended to be interpreted by user-space,
other than processing wildcards when matching to modules.

For input devices, the same information is available through other
variables in the uevent, in a more compact form.  The information *is*
useful for user-space; e.g. in initramfs-tools we recognise keyboard
devices and add their drivers to the initramfs but ignore other input
devices.

> As for b), the problem isn't with the modalias attribute itself, but
> when the kernel tries to copy it into the environment block for the udev
> callout.  The environment block is only a single page, and so limited to
> 4 KB.  And that's for everything else that goes into the environment,
> not just the modalias.

Text-based sysfs attributes are limited to a page, but udev receives
uevents through netlink, not sysfs.

The current limit on the environment of a uevent appears to be 2 KB
(UEVENT_BUFFER_SIZE defined in ).  That seems like it
*might* be easier to change, so long as user-space doesn't have a
similar limit.

I looked into systemd/udev, and it seems to use an 8 KB buffer for
receiving uevents:

https://sources.debian.org/src/systemd/247.9-1/src/libsystemd/sd-device/device-monitor.c/?hl=390#L390

But as a first step I think increasing the kernel buffer size to 4 KB
would be enough.  Perhaps someone could test whether this patch to the
domU kernel makes udev happier:

--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -30,7 +30,7 @@
 
 #define UEVENT_HELPER_PATH_LEN 256
 #define UEVENT_NUM_ENVP64  /* number of env 
pointers */
-#define UEVENT_BUFFER_SIZE 2048/* buffer for the variables */
+#define UEVENT_BUFFER_SIZE 4096    /* buffer for the variables */
 
 #ifdef CONFIG_UEVENT_HELPER
 /* path to the userspace helper executed on an event */
--- END ---

?

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


signature.asc
Description: PGP signature

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

[Ben Hutchings]

On Tue, 2021-08-24 at 10:56 -0400, Chuck Zmudzinski wrote:
> On 5/24/2021 3:30 AM, Michael Biebl wrote:
> > Hi Phillip
> > 
> > Am 24.05.2021 um 06:19 schrieb Cyril Brulebois:
> > > > trigger to cold plug all devices.  Both scripts are set -e.  The Xen
> > > > Virtual Keyboard driver and at least one other driver have always 
> > > > failed
> > > > to trigger due to having absurdly long modalias, but the error used to
> > > > be ignored.  The kernel now returns the error to udevadm
> > 
> > So this is a change in behaviour in the kernel?
> > What happens if you boot the installed system? Does udevadm trigger 
> > fail there as well?
> > 
> > I feel a bit uneasy changing the udev start script this late in the 
> > release cycle (especially when it appears like covering up an issue 
> > someplace else).
> > 
> > I'll let Marco make the judgement on this though, as he has the most 
> > experience with those udev udeb start scripts as the original author.
> > 
> > Michael
> > 
> 
> After reviewing Philip's message at
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357#43
> 
> which seems to point to the root cause of this bug, I can add:
> 
> On my Xen HVM DomU I see the absurdly long modalias for the Xen
> Virtual keyboard that seems to be causing this crash in sysfs at
> 
> /sys/devices/virtual/input/input2/modalias
> 
> But at /sys/devices/vkbd-0/modalias, I see just 'xen:vkbd', which would
> probably not result in an error in the udev script if this was also
> written as the modalias at /sys/devices/virtual/input/input2/modalias
>
> So the Xen virtual keyboard appears more than once in sysfs, and
> modalias is not the same in the different places. This seems
> to be a problem.

They are two different devices, and they should have different
modaliases.

Linux has code for discovering devices on each kind of bus, including
virtual buses, and that code creates "bus devices" such as vkbd-0.  At
this point the kernel doesn't know what the device is capable of.  The
modalias for a bus device carries some identifying information that can
be used to select a driver module for it.

The driver does know what the device is capable of, and how to use it.
It will normally create one or more "class devices" that support a
particular set of operations; in this case input device operations. 
Class devices typically don't have modaliases, since they don't need
another layer of drivers on top.  However, for input devices the
modalias carries information about the device's capabilities.  These
may trigger loading of the evdev or joydev module.

> I understand the correct way to fix this bug is by modifying the
> Xxen virtual keyboard (and any other devices that might cause
> this crash) and not the start-udev script on the netinst
> installation media, which is so far the only available workaround.
> Hopefully Xen will accept a fix if we can come up with a fix.
[...]

I think a proper fix would be one of:

a. If the Xen virtual keyboard driver is advertising capabilities it
   doesn't have, stop it doing that.
b. Change the implementation of modalias attributes to allow longer
   values.

It's not clear to me whether the Xen driver is advertising correctly or
not.  If it is, then the solution should be b, but that may be too
disruptive a change to the kernel.  So a reasonable workaround might
be:

c. Change the input subsystem to limit the length of the
   capabilities part of the modalias.


Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.


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

Bug#991943: klibc: please consider including machine-readable copyright file

[Ben Hutchings]

On Wed, 2021-08-11 at 14:49 +0200, maximilian attems wrote:
> On Wed, Aug 11, 2021 at 02:40:20PM +0200, Andrej Shadura wrote:
> > On 11/08/2021 14:30, Andrej Shadura wrote:
> > > On Fri, 06 Aug 2021 14:31:26 +0200 Andrej Shadura 
> > > wrote:
> > > > Please consider including the attached machine-readable copyright file.
> > > > I tried to make it as precise as I can based on the information in the
> > > > source and accompanying text files; improve it as you see fit.
> > > 
> > > I’ve noticed a few issues with the proposed copyright file. I have fixed
> > > them; please find the attached patch to the packaging.
> > 
> > Of course, once again I’ve forgotten something:
> > 
> > Files: debian/*
> > Copyright:
> >  2005  Jeff Bailey 
> >  2005-2014 maximilian attems 
> >  2015-2021 Ben Hutchings 
> > 
> > I’m not sure what the license of the packaging is.
> 
> please use whatever is canonical, I'm fine with GPL as well as BSD,
> as it is mostly glue to just bring things to the enduser.
> 
> please use this email adress of mine, thank you.
> 
> also the patch should be submitted to klibc upstream ;)

There is no debian directory in the upstream repository.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.


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

Bug#991941: linux: Don't use nouveau with Nvidia GeForce 8500 GT or alert in dmesg that firmware is needed

[Ben Hutchings]

Control: tag -1 moreinfo

On Fri, 2021-08-06 at 12:03 +0200, Laura Arjona Reina wrote:
> Source: linux
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where 
> appropriate ***
> 
> * What led up to the situation?
> 
> I have installed Debian 11 (debian installer RC3) on a PC having a 
> Nvidia GeForce 8500 GT as main graphics card.
> The graphicall install process went well. After finishing the 
> installation and reboot, I got a blank screen and "Input not supported" 
> on my monitor.
> I changed to tty2 and logged in, and saved the dmesg output (attached), 
> I noticed that "nouveau" driver was loaded but there was no info about 
> my card not supported or needing additional firmware.

The missing firmware should have been fixed in installer RC3 *if* you
use an installer image that includes firmware, but not if you use the
default images.  Which did you use?

On the kernel side we should try to fix the blank screen with an
earlier check for firmware in nouveau, similarly to the way we patch
the amdgpu and radeon drivers.  (Although those patches now seem not to
be completely effective.)

> * What exactly did you do (or not do) that was effective (or 
> ineffective)?
> 
> I have rebooted and edited the "linux" line during Grub menu, to add 
> "nomodeset" and then I could have a fallback graphics mode.
> I have installed the isenkram-cli package and ran 
> isenkram-autoinstall-firmware as suggested in the release notes and it 
> installed firmware for my realtek card (unrelated) and 
> firmware-misc-nonfree, but rebooting makes Linux pick the nouveau driver 
> again.
[...]

Well that's expected.  The kernel driver and firmware are two different
things that work together.  Installing the firmware should allow
nouveau to work properly.

Are you saying that even with firmware-misc-nonfree installed, you
still get a black screen when you don't use "nomodeset"?

Ben.


-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


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

Bug#990411: systemd: set kernel.unprivileged_bpf_disabled = 1

[Ben Hutchings]

Control: tag -1 patch

I think disabling unprivileged BPF is probably sensible.  So far as I
know, it is quite limited in usefulness (without exploiting verifier
bugs :-).  If it can't be enabled again, this should maybe be done with
a sysctl config file in linux-base rather than being a built-in default
that can never be overridden.

But I don't see *why* it shouldn't be possible to enable again.  That
makes sense for e.g. kernel.modules_disabled where it's a way for root
to drop privileges, but root always retains the ability to use BPF.

This (untested) patch should fix the default while allowing it to be
changed back:

--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -50,7 +50,7 @@ static DEFINE_SPINLOCK(map_idr_lock);
 static DEFINE_IDR(link_idr);
 static DEFINE_SPINLOCK(link_idr_lock);
 
-int sysctl_unprivileged_bpf_disabled __read_mostly;
+int sysctl_unprivileged_bpf_disabled __read_mostly = 1;
 
 static const struct bpf_map_ops * const bpf_map_types[] = {
 #define BPF_PROG_TYPE(_id, _name, prog_ctx_type, kern_ctx_type)
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2639,9 +2639,8 @@ static struct ctl_table kern_table[] = {
.data   = _unprivileged_bpf_disabled,
.maxlen = sizeof(sysctl_unprivileged_bpf_disabled),
.mode   = 0644,
-   /* only handle a transition from default "0" to "1" */
.proc_handler   = proc_dointvec_minmax,
-   .extra1 = SYSCTL_ONE,
+   .extra1 = SYSCTL_ZERO,
.extra2 = SYSCTL_ONE,
},
{
--- END ---

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.


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

Bug#991426: release-notes: Recommend user.max_user_namespaces over kernel.unprivileged_userns_clone?

[Ben Hutchings]

On Fri, 2021-07-23 at 10:25 +0100, Simon McVittie wrote:
> Package: release-notes
> Severity: normal
> Tags: patch moreinfo
> X-Debbugs-Cc: debian-ker...@lists.debian.org
> 
> If I understand correctly, user.max_user_namespaces is an upstream kernel
> feature, but kernel.unprivileged_userns_clone comes from a Debian-specific
> patch that might be removed in future releases. It seems better to recommend
> the upstream version (also used in e.g. RHEL).
> 
> A possible patch is attached, but I'd prefer to get confirmation from
> a kernel maintainer before applying this, hence tagged +moreinfo.

I agree that this may be more future-proof (though it's taken little
effort to maintain that patch over the last 8 years).

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.


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

Bug#989863: debian-installer: Firmware problems in bullseye

[Ben Hutchings]

On Sat, 2021-07-24 at 10:27 +0100, Simon McVittie wrote:
> On Sat, 24 Jul 2021 at 09:05:59 +0200, Cyril Brulebois wrote:
> > If we were to go the “(almost) all in” route, it might make sense to
> > either blacklist (some of) those, or to whitelist the known-ok ones,
> > which would require some monitoring of new additions over time (which
> > dillon, behind d-i.debian.org, could help us with).
> 
> As an 80% solution, would it be feasible to have the officially-unofficial
> media with firmware install the firmware-linux metapackage by default,
> or at least install it if a desktop task was chosen?
> 
> firmware-linux pulls in firmware-amd-graphics and firmware-misc-nonfree
> (which has the Nvidia firmware), and I think its rules for inclusion
> imply not needing an EULA or other special license-acceptance by the
> user.
[...]

Yes - nothing requiring a EULA should be accepted into the upstream
repository, and if it happens anyway we would put those files in a
separate binary package.

Ben.


-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.


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

Bug#991500: Missing modalias metadata needed for automatic installation

[Ben Hutchings]

Source: firmware-nonfree
Version: 20210315-2
Severity: serious
Tags: pending
X-Debbugs-Cc: k...@debian.org, debian-b...@lists.debian.org

The binary firmware packages built from firmware-nonfree currently
include metanfo.xml files with a list of filenames of the firmware in
them.  These files are indexed and allows firmware packages to be
identified and installed based on the files requested.

However, during system installation not all kernel drivers are
installed and it is not known which files will be requested by the
full system.  The metainfo.xml files should include a list of Linux
modalias strings for the related modules, so that it's possible to
identify (possibly) needed firmware packages without the drivers
loaded.

Ben.

-- System Information:
Debian Release: 11.0
  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.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#991297: rtw_8821ce does not work in debian 11

[Ben Hutchings]

Control: reassign -1 src:linux 5.10.40-1
Control: tag -1 fixed-upstream

On Tue, 2021-07-20 at 10:11 +0200, Michele Bucca wrote:
> Package: firmware-realtek
> Version 20210315-2
> 
> I'm testing debian bullseye and I've noticed that despite the firmware
> of the wireless card Realtek RTL8821ce being added to the package, it
> is still not working.
> 
> I downloaded the ISO debian-live-blsy-DI-rc2-amd64-xfce+nonfree.iso from
> 
> https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/bullseye_di_rc2-live+nonfree/amd64/iso-hybrid/debian-live-blsy-DI-rc2-amd64-xfce+nonfree.iso
> 
> and when I boot the system the Wireless card is not detected by Network 
> Manager.
> 
> if I type dmesg -l err in the terminal I get the following error message:
> 
> [8.123230] rtw_8821ce :03:00.0: rfe 2 isn't supported
[...]

This means the driver doesn't support this variant of the hardware. 
It's not a firmware problem.

That appears to be fixed in 5.12 by:

commit 5d6651fe85837b11564a2e2c3c6279c057d078d6
Author: Guo-Feng Fan 
Date:   Tue Feb 2 13:50:12 2021 +0800

rtw88: 8821c: support RFE type2 wifi NIC

but that may depend on other changes.

Ben.

-- 
Ben Hutchings
Kids!  Bringing about Armageddon can be dangerous.  Do not attempt it
in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'


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

Bug#991019: linux-image-5.10.0-7-armmp: a20 olinuxino-MICRO panic accessing sata disk after the boot.

[Ben Hutchings]

Control: tag -1 moreinfo

On Tue, 2021-07-13 at 04:28 +0200, Flavio Barbara wrote:
> Package: src:linux
> Version: 5.10.40-1
> Severity: normal
> X-Debbugs-Cc: none, f...@maidaccordo.net
> 
> Dear Maintainer,
> 
> after upgrading to bullseye my SBC olimex a20 olinuxino-MICRO, the
> system boots (so it seems it does not have any problem to boot from
> /dev/sda1) and soon after go in kernel panic.
> 
> My system has a SATA disc splitted  in 3 partitions:
> /dev/sda1 /ext4
> /dev/sda2 swap
> /dev/sda3 /homeext4
> 
> uboot is running in a empty microSD card. 
> 
> This is the last line of the sceen output:
> end Kernel panic - not syncing; stack-protector: Kernel stack is
> corrupted in generic_file_buffered_read+0xc2c/0xc30

We would need to see the full output to start investigating this.  If
you're using a monitor then please send a photo as an attachment.

Ben.


-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer


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

Bug#991139: sgt-puzzles: status bar missing in Debian build

[Ben Hutchings]

On Thu, 2021-07-15 at 16:07 +0200, alex wrote:
> Package: sgt-puzzles
> Version: 20170606.272beef-1
> Severity: normal
> 
> Dear Ben Hutchings,
> 
> I enjoyed playing Simon Tatham's puzzles when I still was running
> Windows as my daily driver but since then I transitioned to
> Debian/LMDE.
> What I noticed right away but until now never really cared for is
> that the Windows build features a status bar at the bottom (and ports
> like the Android port have this bar, too, somewhat), but the Debian
> package does not.
> This status bar shows information like (where applicable) the elapsed
> time or counters of some sort.
[...]

The status bar is implemented, but with some themes (particularly dark
ones) it can use the same or very similar colours for text and
background.  There is a similar issue with menu colours (#944237).

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein


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

Bug#989010: linux-image-5.10.0-7-amd64: No display (post, grub, boot messages and desktop) after the upgrade to 5.10.38

[Ben Hutchings]

I've seen nothing to indicate that this is a kernel issue, rather than
hardware becoming flaky or possibly an nvidia driver issue.

It's easy to think that a hardware fault was caused by whatever else
recently changed.  But if there was a software change that broke Nvidia
cards, we would expect to receive lots of bug reports about it, not
just one.

We're still waiting for the requested logs from you.

Ben.

-- 
Ben Hutchings
Kids!  Bringing about Armageddon can be dangerous.  Do not attempt it
in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'


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

Bug#989509: buster-pu: package klibc/2.0.6-1+deb10u1

[Ben Hutchings]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-ker...@lists.debian.org, mirabilos 

[ Reason ]
There are open security issues that were triaged as no-dsa by the
security team.  These affect the heap functions (malloc and calloc)
and the cpio utility.

setjmp and longjmp are implemented incorrectly on s390x.

[ Impact ]
Some programs built using klibc may have potential heap overflows
that can be exploited for privilege escalation.

On s390x, programs using setjmp and longjmp may misbehave in
unpredictable ways.

[ Tests ]
malloc, calloc, setjmp, and longjmp are exercised by the test suite
that runs during build.  However the setjmp/longjmp test was not
sufficient to detect the bug.

Thorsten Glaser tested the s390x fix in unstable.  It has not (yet)
been manually tested in this version.

I have tested the cpio utility manually.

[ Risks ]
The changes are localised and seem comparatively low-risk to me.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
All but one of the patches fixes a single bug or CVE as detailed in
its patch header.

The patch "malloc: Set errno on failure" is applied as a dependency
of "malloc: Fail if requested size > PTRDIFF_MAX".

[ Other info ]
diff -Nru klibc-2.0.6/debian/changelog klibc-2.0.6/debian/changelog
--- klibc-2.0.6/debian/changelog2019-02-01 06:00:57.0 +0100
+++ klibc-2.0.6/debian/changelog2021-06-05 20:20:42.0 +0200
@@ -1,3 +1,19 @@
+klibc (2.0.6-1+deb10u1) buster; urgency=medium
+
+  [ Ben Hutchings ]
+  * Apply security fixes from 2.0.9 (Closes: #989505):
+- malloc: Set errno on failure
+- malloc: Fail if requested size > PTRDIFF_MAX (CVE-2021-31873)
+- calloc: Fail if multiplication overflows (CVE-2021-31870)
+- cpio: Fix possible integer overflow on 32-bit systems (CVE-2021-31872)
+- cpio: Fix possible crash on 64-bit systems (CVE-2021-31871)
+
+  [ Thorsten Glaser ]
+  * {set,long}jmp [s390x]: save/restore the correct FPU registers
+(f8‥f15 not f1/f3/f5/f7) (Closes: #943425)
+
+ -- Ben Hutchings   Sat, 05 Jun 2021 20:20:42 +0200
+
 klibc (2.0.6-1) unstable; urgency=medium
 
   * New upstream version:
diff -Nru 
klibc-2.0.6/debian/patches/0035-klibc-malloc-Set-errno-on-failure.patch 
klibc-2.0.6/debian/patches/0035-klibc-malloc-Set-errno-on-failure.patch
--- klibc-2.0.6/debian/patches/0035-klibc-malloc-Set-errno-on-failure.patch 
1970-01-01 01:00:00.0 +0100
+++ klibc-2.0.6/debian/patches/0035-klibc-malloc-Set-errno-on-failure.patch 
2021-04-30 04:30:16.0 +0200
@@ -0,0 +1,32 @@
+From: Ben Hutchings 
+Date: Wed, 28 Apr 2021 03:57:39 +0200
+Subject: [klibc] malloc: Set errno on failure
+Origin: 
https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=7f6626d12daa2f1efd9953d1f4ba2065348dc5cd
+
+malloc() is specified to set errno = ENOMEM on failure, so do that.
+
+Signed-off-by: Ben Hutchings 
+---
+ usr/klibc/malloc.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/usr/klibc/malloc.c b/usr/klibc/malloc.c
+index 413b7337..bb57c9f6 100644
+--- a/usr/klibc/malloc.c
 b/usr/klibc/malloc.c
+@@ -8,6 +8,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ #include "malloc.h"
+ 
+ /* Both the arena list and the free memory list are double linked
+@@ -169,6 +170,7 @@ void *malloc(size_t size)
+ #endif
+ 
+   if (fp == (struct free_arena_header *)MAP_FAILED) {
++  errno = ENOMEM;
+   return NULL;/* Failed to get a block */
+   }
+ 
diff -Nru 
klibc-2.0.6/debian/patches/0036-klibc-malloc-Fail-if-requested-size-PTRDIFF_MAX.patch
 
klibc-2.0.6/debian/patches/0036-klibc-malloc-Fail-if-requested-size-PTRDIFF_MAX.patch
--- 
klibc-2.0.6/debian/patches/0036-klibc-malloc-Fail-if-requested-size-PTRDIFF_MAX.patch
   1970-01-01 01:00:00.0 +0100
+++ 
klibc-2.0.6/debian/patches/0036-klibc-malloc-Fail-if-requested-size-PTRDIFF_MAX.patch
   2021-04-30 04:30:16.00000 +0200
@@ -0,0 +1,41 @@
+From: Ben Hutchings 
+Date: Wed, 28 Apr 2021 04:03:49 +0200
+Subject: [klibc] malloc: Fail if requested size > PTRDIFF_MAX
+Origin: 
https://git.kernel.org/pub/scm/libs/klibc/klibc.git/commit/?id=a31ae8c508fc8d1bca4f57e9f9f88127572d5202
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-31873
+
+malloc() adds some overhead to the requested size, which may result in
+an integer overflow and subsequent buffer overflow if it is close to
+SIZE_MAX.  It should fail if size is large enough for this to happen.
+
+Further, it's not legal for a C object to be larger than
+PTRDIFF_MAX (half of SIZE_MAX) as pointer arithmetic within it could
+overflow.  So return failure immediately if size is greater than that.
+
+CVE-202

Bug#989505: Multiple security issues (CVE-2021-31870, CVE-2021-31871, CVE-2021-31872, CVE-2021-31873)

[Ben Hutchings]

Source: klibc
Version: 2.0.6-1
Severity: important
Tags: security

klibc version 2.0.9 fixed various security issues.  These are fixed in
unstable but not yet in buster.  They were triaged as no-dsa by the
security team, so they should be fixed in a stable update instead.

Ben.

-- System Information:
Debian Release: 11.0
  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.10.0-6-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#989143: initramfs-tools: doesn’t actually compress with zstd

[Ben Hutchings]

On Sat, 2021-06-05 at 16:49 +0200, Christoph Anton Mitterer wrote:
> On Sat, 2021-06-05 at 16:23 +0200, Ben Hutchings wrote:
> > You have intel-microcode installed, which prepends an uncompressed
> > initramfs.  Not a bug.
> 
> Couldn't it then just skip the compression altogether?

You mean, can the main initramfs be uncompressed?  I'm not sure whether
the kernel supports that.  It's certainly not an option in initramfs-
tools at the moment.

Ben.

-- 
Ben Hutchings
Kids!  Bringing about Armageddon can be dangerous.  Do not attempt it
in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'


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

Bug#988627: unblock: broadcom-sta/6.30.223.271-16.1

[Ben Hutchings]

On Thu, 2021-05-27 at 10:50 +0200, Paul Gevers wrote:
> Control: tags -1 moreinfo
> 
> Hi,
> 
> On 17-05-2021 02:12, Ben Hutchings wrote:
> > Please unblock package broadcom-sta
> > 
> > [ Reason ]
> > Fix the unusable broadcom-sta-source package.
> > 
> > [ Impact ]
> > It is not possible to build a package using module-assistant and the
> > version of broadcom-sta-source in bullseye.  However, dkms and
> > broadcom-sta-dkms can be used as an alternative.
> > 
> > [ Tests ]
> > Only the build processes are being changed.  I tested that:
> > - broadcom-sta can be built from source
> > - module-assistant can build a module package from broadcom-sta-source
> >   for the current kernel version in bullseye (5.10.0-6-amd64)
> > - the resulting binary module package looks like a module package
> >   built from broadcom-sta-source in buster, modulo version changes
> 
> * I wonder, broadcom-sta has seen quite some uploads the last couple of
> years and debhelper is even in oldstable newer than the version
> mentioned. How were all these uploads possible?

broadcom-sta has always properly declared its debhelper compatibility
level.  Earlier it was done through debian/compat, then since version
6.30.223.271-13~exp1 through a versioned B-D on debhelper-compat.

module-assistant creates a source and binary packages for modules using
a template that's included in packages such as broadcom-sta-source. 
That template was not updated along with broadcom-sta itself, so was
missing a debhelper compatibility level since version
6.30.223.271-13~exp1.

This probably wasn't noticed because DKMS is now more popular than
module-assistant.

> * What is/was the behavior of debhelper if the compat level was not
> specified? In the freeze we don't want debhelper compat bumps unless the
> package is proven to have no delta regardless of the old-vs-new level.

It's a fatal error.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.


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

Bug#822112: still applies to current kernels

[Ben Hutchings]

On Mon, 2021-05-17 at 20:01 +0200, Ben Hutchings wrote:
> Control: tag -1 wontfix
> 
> On Wed, 2021-05-12 at 06:16 +0300, Martin-Éric Racine wrote:
> > This still applies to current kernels.
> > 
> > The problem seems to be that kernels after version 3 implement a
> > memory protection scheme that prevents the framebuffer from being
> > accessed by both vesafb and X drivers. The Geode X driver does that.
> 
> Then this is not a kernel bug.  The change was intentional and
> documented in the NEWS file along with the option to revert it:
> 
> - On most architectures, the /dev/mem device can no longer be used to
>   access devices that also have a kernel driver.  This breaks dosemu
>   and some old user-space graphics drivers.  To allow this, set the
>   kernel parameter: iomem=relaxed

That said, this was originally reported before that change was made, so
possibly there are two different issues here.  Let us know if the
kernel parameter change doesn't allow the X driver to work again.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.


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

Bug#822112: still applies to current kernels

[Ben Hutchings]

Control: tag -1 wontfix

On Wed, 2021-05-12 at 06:16 +0300, Martin-Éric Racine wrote:
> This still applies to current kernels.
> 
> The problem seems to be that kernels after version 3 implement a
> memory protection scheme that prevents the framebuffer from being
> accessed by both vesafb and X drivers. The Geode X driver does that.

Then this is not a kernel bug.  The change was intentional and
documented in the NEWS file along with the option to revert it:

- On most architectures, the /dev/mem device can no longer be used to
  access devices that also have a kernel driver.  This breaks dosemu
  and some old user-space graphics drivers.  To allow this, set the
  kernel parameter: iomem=relaxed

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.


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

Bug#988562: broadcom-sta: diff for NMU version 6.30.223.271-16.1

[Ben Hutchings]

On Mon, 2021-05-17 at 18:58 +0900, Roger Shimizu wrote:
> Dear Ben,
> 
> Thanks for the report and NMU!
> 
> On Mon, May 17, 2021 at 8:21 AM Ben Hutchings  wrote:
> > 
> > Control: tags 988562 + patch
> > Control: tags 988562 + pending
> > 
> > Dear maintainer,
> > 
> > I've prepared an NMU for broadcom-sta (versioned as 6.30.223.271-16.1)
> > and uploaded it.
> > 
> > The changes are attached as a debdiff, but you can also merge the
> > "debian" branch of <https://salsa.debian.org/benh/broadcom-sta.git>.
> 
> However I find this package cannot be source upload, due to non-free.
> I'll upload with binary again with version -17 later.
> After that, I'll amend your unblock request.

Sorry about that, I have got too used to being able to do source-only
uploads.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.


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

Bug#988627: unblock: broadcom-sta/6.30.223.271-16.1

[Ben Hutchings]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: bl...@debian.org, clac...@easter-eggs.com, r...@debian.org

Please unblock package broadcom-sta

[ Reason ]
Fix the unusable broadcom-sta-source package.

[ Impact ]
It is not possible to build a package using module-assistant and the
version of broadcom-sta-source in bullseye.  However, dkms and
broadcom-sta-dkms can be used as an alternative.

[ Tests ]
Only the build processes are being changed.  I tested that:
- broadcom-sta can be built from source
- module-assistant can build a module package from broadcom-sta-source
  for the current kernel version in bullseye (5.10.0-6-amd64)
- the resulting binary module package looks like a module package
  built from broadcom-sta-source in buster, modulo version changes

[ Risks ]
This seems like a low-risk change.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

[ Other info ]

unblock broadcom-sta/6.30.223.271-16.1
diff -Nru broadcom-sta-6.30.223.271/debian/changelog 
broadcom-sta-6.30.223.271/debian/changelog
--- broadcom-sta-6.30.223.271/debian/changelog  2021-05-04 11:11:49.0 
+0200
+++ broadcom-sta-6.30.223.271/debian/changelog  2021-05-17 01:06:42.0 
+0200
@@ -1,3 +1,14 @@
+broadcom-sta (6.30.223.271-16.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * debian/control.modules.in:
+- Declare debhelper compat level through a build-dependency
+  (Closes: #988562)
+  * debian/rules:
+- Fix copying of Debian files in install-source rule
+
+ -- Ben Hutchings   Mon, 17 May 2021 01:06:42 +0200
+
 broadcom-sta (6.30.223.271-16) unstable; urgency=medium
 
   * Upload to unstable.
diff -Nru broadcom-sta-6.30.223.271/debian/control.modules.in 
broadcom-sta-6.30.223.271/debian/control.modules.in
--- broadcom-sta-6.30.223.271/debian/control.modules.in 2021-05-04 
11:11:49.0 +0200
+++ broadcom-sta-6.30.223.271/debian/control.modules.in 2021-05-17 
00:56:52.0 +0200
@@ -2,7 +2,7 @@
 Section: non-free/kernel
 Priority: optional
 Maintainer: Cyril Lacoux 
-Build-Depends: debhelper (>= 8)
+Build-Depends: debhelper-compat (= 12)
 Standards-Version: 3.9.4
 Homepage: http://www.broadcom.com/support/802.11/linux_sta.php
 
diff -Nru broadcom-sta-6.30.223.271/debian/rules 
broadcom-sta-6.30.223.271/debian/rules
--- broadcom-sta-6.30.223.271/debian/rules  2021-05-04 11:11:49.0 
+0200
+++ broadcom-sta-6.30.223.271/debian/rules  2021-05-17 00:56:28.0 
+0200
@@ -45,8 +45,8 @@

# Copy Debian files
install -D -m 0755 debian/rules.modules $(source_debdir)/rules
-   for file in changelog compat control control.modules.in copyright; do \
-   install -m 644 debian/$$file $(source_debdir); \
+   for file in changelog control control.modules.in copyright; do \
+   install -m 644 debian/$$file $(source_debdir) || exit; \
done

# Make suitable tarball for module-assisant and kernel-package

Bug#988562: broadcom-sta: diff for NMU version 6.30.223.271-16.1

[Ben Hutchings]

Control: tags 988562 + patch
Control: tags 988562 + pending

Dear maintainer,

I've prepared an NMU for broadcom-sta (versioned as 6.30.223.271-16.1)
and uploaded it.

The changes are attached as a debdiff, but you can also merge the
"debian" branch of <https://salsa.debian.org/benh/broadcom-sta.git>.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.
diff -Nru broadcom-sta-6.30.223.271/debian/changelog broadcom-sta-6.30.223.271/debian/changelog
--- broadcom-sta-6.30.223.271/debian/changelog	2021-05-04 11:11:49.0 +0200
+++ broadcom-sta-6.30.223.271/debian/changelog	2021-05-17 01:06:42.0 +0200
@@ -1,3 +1,14 @@
+broadcom-sta (6.30.223.271-16.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * debian/control.modules.in:
+- Declare debhelper compat level through a build-dependency
+  (Closes: #988562)
+  * debian/rules:
+- Fix copying of Debian files in install-source rule
+
+ -- Ben Hutchings   Mon, 17 May 2021 01:06:42 +0200
+
 broadcom-sta (6.30.223.271-16) unstable; urgency=medium
 
   * Upload to unstable.
diff -Nru broadcom-sta-6.30.223.271/debian/control.modules.in broadcom-sta-6.30.223.271/debian/control.modules.in
--- broadcom-sta-6.30.223.271/debian/control.modules.in	2021-05-04 11:11:49.0 +0200
+++ broadcom-sta-6.30.223.271/debian/control.modules.in	2021-05-17 00:56:52.0 +0200
@@ -2,7 +2,7 @@
 Section: non-free/kernel
 Priority: optional
 Maintainer: Cyril Lacoux 
-Build-Depends: debhelper (>= 8)
+Build-Depends: debhelper-compat (= 12)
 Standards-Version: 3.9.4
 Homepage: http://www.broadcom.com/support/802.11/linux_sta.php
 
diff -Nru broadcom-sta-6.30.223.271/debian/rules broadcom-sta-6.30.223.271/debian/rules
--- broadcom-sta-6.30.223.271/debian/rules	2021-05-04 11:11:49.0 +0200
+++ broadcom-sta-6.30.223.271/debian/rules	2021-05-17 00:56:28.0 +0200
@@ -45,8 +45,8 @@
 	
 	# Copy Debian files
 	install -D -m 0755 debian/rules.modules $(source_debdir)/rules
-	for file in changelog compat control control.modules.in copyright; do \
-		install -m 644 debian/$$file $(source_debdir); \
+	for file in changelog control control.modules.in copyright; do \
+		install -m 644 debian/$$file $(source_debdir) || exit; \
 	done
 	
 	# Make suitable tarball for module-assisant and kernel-package


signature.asc
Description: PGP signature

Bug#988558: leds-alix: diff for NMU version 0.0.1-1.3

[Ben Hutchings]

Control: tags 988558 + pending

Dear maintainer,

I've prepared an NMU for leds-alix (versioned as 0.0.1-1.3) and
uploaded it.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.
diff -u leds-alix-0.0.1/debian/changelog leds-alix-0.0.1/debian/changelog
--- leds-alix-0.0.1/debian/changelog
+++ leds-alix-0.0.1/debian/changelog
@@ -1,3 +1,10 @@
+leds-alix (0.0.1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Fix build after removal of SUBDIRS support in Linux 5.3 (Closes: #988558)
+
+ -- Ben Hutchings   Mon, 17 May 2021 00:42:59 +0200
+
 leds-alix (0.0.1-1.2) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
only in patch2:
unchanged:
--- leds-alix-0.0.1.orig/Makefile
+++ leds-alix-0.0.1/Makefile
@@ -19,10 +19,10 @@
 all: $(MODULE)
 
 $(MODULE): $(SOURCE)
-	$(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules
+	$(MAKE) -C $(KERNEL_DIR) M=$(PWD) modules
 
 install: $(MODULE)
-	$(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) INSTALL_MOD_DIR=$(INSTALL_MOD_DIR) modules_install
+	$(MAKE) -C $(KERNEL_DIR) M=$(PWD) INSTALL_MOD_DIR=$(INSTALL_MOD_DIR) modules_install
 	depmod -ae
 
 uninstall:


signature.asc
Description: PGP signature

Bug#988626: vpb-driver: diff for NMU version 4.2.61-1.2

[Ben Hutchings]

Package: vpb-driver
Version: 4.2.61-1.1
Severity: normal
Tags: patch  pending

Dear maintainer,

I've prepared an NMU for vpb-driver (versioned as 4.2.61-1.2) and
uploaded it.

Ben.

-- 
Ben Hutchings
Never attribute to conspiracy what can adequately be explained
by stupidity.
diff -u vpb-driver-4.2.61/debian/changelog vpb-driver-4.2.61/debian/changelog
--- vpb-driver-4.2.61/debian/changelog
+++ vpb-driver-4.2.61/debian/changelog
@@ -1,3 +1,15 @@
+vpb-driver (4.2.61-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Use struct proc_ops for proc file operations on Linux 5.6+
+(Closes: #988564)
+  * Use ioremap() instead of (formerly equivalent, now removed)
+ioremap_nocache()
+  * Pass target kernel version to depmod (Closes: #917865)
+  * Only run depmod or modprobe if installing modules to host filesystem
+
+ -- Ben Hutchings   Mon, 17 May 2021 00:36:41 +0200
+
 vpb-driver (4.2.61-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
only in patch2:
unchanged:
--- vpb-driver-4.2.61.orig/src/vpb/Makefile
+++ vpb-driver-4.2.61/src/vpb/Makefile
@@ -46,7 +46,9 @@
 		echo "installing $$m --> $(MODULEDIR)";	\
 		install -m 644 $$m $(MODULEDIR);	\
 	done
-	/sbin/depmod
+ifeq ($(DESTDIR),)
+	/sbin/depmod $(KVERS)
+endif
 
 clean distclean:
 	$(RM) *.o *.ko *~ core *.mod.c .*.cmd
only in patch2:
unchanged:
--- vpb-driver-4.2.61.orig/src/vpb/vpb.c
+++ vpb-driver-4.2.61/src/vpb/vpb.c
@@ -279,7 +279,7 @@
 			printk(KERN_INFO NAME ": tmp [0x%lx] dev->res2 [0x%lx]\n",
   tmp, (unsigned long)dev->resource[2].start);
 
-base2[numPCI] = ioremap_nocache(dev->resource[2].start &
+base2[numPCI] = ioremap(dev->resource[2].start &
 PCI_BASE_ADDRESS_MEM_MASK,
 sizeof(short)*SIZE_WD);
 
only in patch2:
unchanged:
--- vpb-driver-4.2.61.orig/src/vtcore/Makefile
+++ vpb-driver-4.2.61/src/vtcore/Makefile
@@ -50,8 +50,10 @@
 		echo "installing $$m --> $(MODULEDIR)";	\
 		install -m 644 $$m $(MODULEDIR);	\
 	done
-	/sbin/depmod
+ifeq ($(DESTDIR),)
+	/sbin/depmod $(KVERS)
 	@modprobe -r netjet > /dev/null 2>&1 || true
+endif
 
 clean distclean:
 	rm -f *.o *.ko *~ core *.mod.c .*.cmd
only in patch2:
unchanged:
--- vpb-driver-4.2.61.orig/src/vtcore/vtcore_main.c
+++ vpb-driver-4.2.61/src/vtcore/vtcore_main.c
@@ -213,6 +213,34 @@
 	}
 } //}}}
 
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(5,6,0)
+#define VT_DEFINE_PROC_OPS(storage, name, _owner, _open, _write)	\
+storage const struct proc_ops name = {	\
+	.proc_open	= _open,	\
+	.proc_read	= seq_read,	\
+	.proc_lseek	= seq_lseek,	\
+	.proc_release	= single_release,\
+	.proc_write	= _write,	\
+}
+#else  /* LINUX_VERSION_CODE < KERNEL_VERSION(5,6,0) */
+#define VT_DEFINE_PROC_OPS(storage, name, _owner, _open, _write)	\
+storage const struct file_operations name = {\
+	.owner		= _owner,	\
+	.open		= _open,	\
+	.read		= seq_read,	\
+	.llseek		= seq_lseek,	\
+	.release	= single_release,\
+	.write		= _write,	\
+}
+#endif
+
+#define VT_DEFINE_PROC_OPS_OPEN(storage, name)\
+	VT_DEFINE_PROC_OPS(storage, name ## _proc_fops, NULL,		\
+			   name ## _proc_open, NULL)
+
+#define VT_DEFINE_PROC_OPS_OPEN_WRITE(storage, name)			\
+	VT_DEFINE_PROC_OPS(storage, name ## _proc_fops, THIS_MODULE,	\
+			   name ## _proc_open, name ## _proc_write)
 
 static int vt_int_proc_show(struct seq_file *m, void *v)
 { //{{{
@@ -225,12 +253,8 @@
 	return single_open(file, vt_int_proc_show, PDE_DATA(inode));
 }
 
-const struct file_operations vt_int_proc_fops = {
-	.open		= vt_int_proc_open,
-	.read		= seq_read,
-	.llseek		= seq_lseek,
-	.release	= single_release,
-}; //}}}
+VT_DEFINE_PROC_OPS_OPEN(, vt_int);
+//}}}
 
 static int vt_string_proc_show(struct seq_file *m, void *v)
 { //{{{
@@ -243,12 +267,8 @@
 	return single_open(file, vt_string_proc_show, PDE_DATA(inode));
 }
 
-const struct file_operations vt_string_proc_fops = {
-	.open		= vt_string_proc_open,
-	.read		= seq_read,
-	.llseek		= seq_lseek,
-	.release	= single_release,
-}; //}}}
+VT_DEFINE_PROC_OPS_OPEN(, vt_string);
+//}}}
 
 
 int __init vtcore_init(void)
@@ -1081,14 +1101,8 @@
 	return ret;
 }
 
-static const struct file_operations vt_country_proc_fops = {
-	.owner		= THIS_MODULE,
-	.open		= vt_country_proc_open,
-	.read		= seq_read,
-	.llseek		= seq_lseek,
-	.release	= single_release,
-	.write		= vt_country_proc_write,
-}; //}}}
+VT_DEFINE_PROC_OPS_OPEN_WRITE(static, vt_country);
+//}}}
 
 // Template definitions for port ops that communicate a single integer value.
 // {{{
@@ -1161,25 +1175,13 @@
 #define PROC_READ_PORT(attrib)			\
 	PROC_READ_PORT_(attrib)			\
 		\
-static const struct file_operations vt_##attrib##_proc_fops = {			\
-	.open		= vt_##att

Bug#988564: Fails to build for Linux 5.6+

[Ben Hutchings]

Package: vpb-driver-source
Version: 4.2.61-1.1
Severity: grave
Tags: bullseye sid

vpb-driver-source fails to build for Linux kernel version 5.6 and
later.  This is due to a change in the proc_create_data() API.

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.10.0-5-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages vpb-driver-source depends on:
ii  bzip2 1.0.8-4
ii  debhelper 13.3.4
ii  make  4.3-4
ii  module-assistant  0.11.10

vpb-driver-source recommends no packages.

vpb-driver-source suggests no packages.

Bug#988562: Fails to build due to unspecified debhelper compatibility level

[Ben Hutchings]

Package: broadcom-sta-source
Version: 6.30.223.271-16
Severity: grave

The source package embedded in broadcom-sta-source cannot be built.
It does not define a debhelper compatibility level, which is mandatory
since debhelper 9.20160618, so all debhelper commands fail.

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.10.0-5-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages broadcom-sta-source depends on:
ii  debhelper [debhelper-compat]  13.3.4
ii  make  4.3-4
ii  xz-utils  5.2.5-2

Versions of packages broadcom-sta-source recommends:
ii  module-assistant  0.11.10

broadcom-sta-source suggests no packages.

Bug#988558: Fails to build against Linux version 5.3+

[Ben Hutchings]

Source: leds-alix
Version: 0.0.1-1.2
Severity: grave
Tags: bullseye sid patch

The Makefile in leds-alix invokes the kernel build system with the
SUBDIRS variable set.  This was deprecated long ago and is no longer
supported since Linux 5.3.  The patch below allows it to build again,
though I don't know whether it *works*.

Ben.

--- a/Makefile
+++ b/Makefile
@@ -19,10 +19,10 @@
 all: $(MODULE)
 
 $(MODULE): $(SOURCE)
-   $(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) modules
+   $(MAKE) -C $(KERNEL_DIR) M=$(PWD) modules
 
 install: $(MODULE)
-   $(MAKE) -C $(KERNEL_DIR) SUBDIRS=$(PWD) 
INSTALL_MOD_DIR=$(INSTALL_MOD_DIR) modules_install
+   $(MAKE) -C $(KERNEL_DIR) M=$(PWD) INSTALL_MOD_DIR=$(INSTALL_MOD_DIR) 
modules_install
depmod -ae
 
 uninstall:
--- END ---

-- 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.10.0-5-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled