wireless-regdb_2022.04.08-2~deb11u1_source.changes ACCEPTED into proposed-updates->stable-new
Mapping bullseye to stable. Mapping stable to proposed-updates. Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 30 Jun 2022 01:13:22 +0200 Source: wireless-regdb Architecture: source Version: 2022.04.08-2~deb11u1 Distribution: bullseye Urgency: medium Maintainer: Debian kernel team Changed-By: Ben Hutchings Changes: 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 Checksums-Sha1: 9d3a7d13a9b9230729c9a86192a45368f671c775 2302 wireless-regdb_2022.04.08-2~deb11u1.dsc 505556b9f632150a336d98b9f227ab7b9807b32b 20460 wireless-regdb_2022.04.08-2~deb11u1.debian.tar.xz dcede5987dbb089bad61b4bedf23cf9fe6a53c46 6655 wireless-regdb_2022.04.08-2~deb11u1_amd64.buildinfo Checksums-Sha256: 19919bbadf47695027ba1e0377c82eb1b83c2863aa8127dddfb283f0938fd9d7 2302 wireless-regdb_2022.04.08-2~deb11u1.dsc 7d82a550eb6fa49d1e02afc426ac26b56deeb1d7837f8adb7a567ad406c95678 20460 wireless-regdb_2022.04.08-2~deb11u1.debian.tar.xz 8e329cf2b7d37d24435f1ac09869b0d5903e7f0df65e8daa381c870b4c23bd74 6655 wireless-regdb_2022.04.08-2~deb11u1_amd64.buildinfo Files: 238162a8946839316c749267588d2c97 2302 net optional wireless-regdb_2022.04.08-2~deb11u1.dsc eae40ad66719ccc6893c81fa57e27c18 20460 net optional wireless-regdb_2022.04.08-2~deb11u1.debian.tar.xz a7e2fe44853cd1573c1db2c494af8f7c 6655 net optional wireless-regdb_2022.04.08-2~deb11u1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmK83UYACgkQ57/I7JWG EQlHfg/+IwjBu2H/bpC2B+sEj9Yyh4aY6y0sfDGgPNfV/UxMFKCMz5ZZNHpJA0+K AkrdGK4HWrTOMsa8NfZGacrmscjElF0D0CpvfFhJ0eUZnwMnhdV4ahuasygWvASV luS3bPy8TwwcIMRJcZfnLnYYeg5D/UjJ2D88Rgwl+z9V8mdc25XUk+a1xaqp1QX2 cWElIAEhE3bxXs6tNjxkXQVuLaNDj/md/JMZXHFw9zWXjpSBiay/IBegD6I2XFnJ AntA9bRw9zbJmOQ9ri4byXyIe53tRwBqUYNDS/MC26xrmRrdR+6kCfwpZZD1gUaf cpJ/h/jy01r6Nm+GAYqFb0ub0yLmryahc7m4RYjZfW4eJuwuOg+dthfD2GRfa+Wd xMhAnBdSopov4+53etlm8NsyL/AztBOpqAOpr6+cRI+jYyC1ZsE9vnfvogxvD7Ul NFYSjyHURr44wUNAhq75+jkV7UII2FecPWJO9KIg9e2a53q+OCAk8OYx04vBewPV zqAjQdTcM+vZrFcQZgOsPX26UjqccGmVzWJwnhRSTStQKUukKvVBQ9r1KsygOh0b B/vZ5gif6imM8iFua5L62ynhPdoPVQzxnsJYAsW6kcAR9PGQkXjdaPqnrVEsRiHv dSmJ3PdTv5GUKjnxKwyxai7+HIWrM3gtz6CaRHPp5sn0jKnm/cs= =DF1C -END PGP SIGNATURE- Thank you for your contribution to Debian.
Bug#1012601: wireless-regdb: alternative broken on debian-installer install
Ben Hutchings wrote on Thu, Jun 30, 2022 at 02:08:24AM +0200: > > 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. Ah, sorry I didn't realize they had the same source package. > > 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. I've had a look at the postinst script[1] after the automated notification and it looks good to me, thank you. [1] https://salsa.debian.org/kernel-team/wireless-regdb/-/blob/master/debian/wireless-regdb.postinst -- Dominique
Bug#1012601: wireless-regdb: alternative broken on debian-installer install
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
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debian-kernel@lists.debian.org
[ Reason ]
Provide current information about national radio regulations to the
Linux Wi-Fi stack.
[ Impact ]
Users may accidentally configure Wi-Fi hardware to use channels or
power levels that are not permitted, or may be unable to use channels
that are permitted.
[ Tests ]
- The signatures on regulatory.db are now checked against the kernel
trust list by an autopkgtest test case.
- I installed the package on top of a fresh bullseye installation
and verified that:
- /lib/firmware/regulatory.db{,.p7s} are replaced with symlinks.
- The kernel can load the regulatory database without errors.
- The database itself is currently identical to the upstream version
which is already used by other distributions.
[ Risks ]
The package is fairly trivial. The only risk I see is that the new
database could conceivably differ from the actual regulations in a
more serious way.
[ 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 ]
Upstream changes:
- Updated the regulatory database (db.txt) following various national
radio regulatory changes.
- Regenerated the binaries and signatures (regulatory.bin,
regulatory.db, regulatory.db.p7s) and checksum (sha1sum.txt) from
db.txt.
- Changed gen-pubcert.sh script and associated rule to put a
configurable name in the generated certificate. These aren't used
in a package build.
Debian changes:
- Fixed bug #1012601, which would otherwise mean that the updated
database isn't actually used.
- Regenerated my signatures (debian/regulatory.bin.sig,
debian/regulatory.db.p7s).
- Added a Salsa CI configuration.
- Added an autopkgtest test case.
[ Other info ]
N/A
diff -Nru wireless-regdb-2020.04.29/Makefile wireless-regdb-2022.04.08/Makefile
--- wireless-regdb-2020.04.29/Makefile 2020-04-29 19:51:03.0 +0200
+++ wireless-regdb-2022.04.08/Makefile 2022-04-08 17:54:37.0 +0200
@@ -80,7 +80,7 @@
$(REGDB_PUBCERT): $(REGDB_PRIVKEY)
@echo "Generating certificate for $(REGDB_AUTHOR)..."
- ./gen-pubcert.sh $(REGDB_PRIVKEY) $(REGDB_PUBCERT)
+ ./gen-pubcert.sh $(REGDB_PRIVKEY) $(REGDB_PUBCERT) $(REGDB_AUTHOR)
@echo $(REGDB_PUBKEY) > .custom
diff -Nru wireless-regdb-2020.04.29/db.txt wireless-regdb-2022.04.08/db.txt
--- wireless-regdb-2020.04.29/db.txt2020-04-29 19:51:03.0 +0200
+++ wireless-regdb-2022.04.08/db.txt2022-04-08 17:54:37.0 +0200
@@ -10,6 +10,9 @@
# This is the world regulatory domain
country 00:
+ # There is no global intersection for 802.11ah, so just mark the entire
+ # possible band as NO-IR
+ (755 - 928 @ 2), (20), NO-IR
(2402 - 2472 @ 40), (20)
# Channel 12 - 13.
(2457 - 2482 @ 20), (20), NO-IR, AUTO-BW
@@ -118,7 +121,7 @@
(57000 - 66000 @ 2160), (40)
# Source:
-# https://www.legislation.gov.au/Details/F2016C00432
+# https://www.legislation.gov.au/Details/F2022C00281
# Both DFS-ETSI and DFS-FCC are acceptable per AS/NZS 4268 Appendix B.
# The EIRP for DFS bands can be increased by 3dB if TPC is implemented.
# In order to allow 80MHz operation between 5650-5730MHz the upper boundary
@@ -130,6 +133,7 @@
(5470 - 5600 @ 80), (27), DFS
(5650 - 5730 @ 80), (27), DFS
(5730 - 5850 @ 80), (36)
+ (5925 - 6425 @ 160), (24), NO-OUTDOOR
(57000 - 66000 @ 2160), (43), NO-OUTDOOR
country AW: DFS-ETSI
@@ -346,11 +350,13 @@
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5735 - 5835 @ 80), (20)
+# Source:
+#
https://wap.miit.gov.cn/cms_files/filemanager/1226211233/attach/20219/d125301b13454551b698ff5afa49ca28.pdf
+# Note: The transmit power for 5150-5350MHz bands can be raised by 3dBm when
TPC is implemented
country CN: DFS-FCC
- (2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (23), AUTO-BW
- (5250 - 5330 @ 80), (23), DFS, AUTO-BW
- (5735 - 5835 @ 80), (30)
+ (2400 - 2483.5 @ 40), (20)
+ (5150 - 5350 @ 80), (20), DFS, AUTO-BW
+ (5725 - 5850 @ 80), (33)
# 60 GHz band channels 1,4: 28dBm, channels 2,3: 44dBm
# ref:
http://www.miit.gov.cn/n11293472/n11505629/n11506593/n11960250/n11960606/n11960700/n12330791.files/n12330790.pdf
(57240 - 59400 @ 2160), (28)
@@ -374,9 +380,13 @@
# Source:
# https://www.mincom.gob.cu/es/marco-legal
# - Redes Informáticas
-# Resolución 127- 2011 Reglamento de Banda de frecuencias de 2,4 GHz.
+#Resolución 98- 2019 Reglamento de Redes Inalámbricas:
+#
https://www.mincom.gob.cu/sites/default/files/marcoregulatorio/r_98-19_reglamento_redes_inalambricas.pdf
country CU: DFS-FCC
(2400 - 2483.5 @ 40), (200 mW)
+ (5150 - 5350 @ 80), (200 mW),
wireless-regdb_2022.04.08-2_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Thu, 30 Jun 2022 00:01:25 +0200 Source: wireless-regdb Architecture: source Version: 2022.04.08-2 Distribution: unstable Urgency: medium Maintainer: Debian kernel team Changed-By: Ben Hutchings Closes: 1012601 Changes: 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) Checksums-Sha1: 2b06505f5dbd8ae3582a324dd9b539580c2d05ca 2270 wireless-regdb_2022.04.08-2.dsc d6ebdaa8826a4bfaea2f9bcfe6bb2ac4413f5e05 18504 wireless-regdb_2022.04.08-2.debian.tar.xz 2b0f8edd556e3e6448c086a9b68f4b580ebc0e73 7427 wireless-regdb_2022.04.08-2_source.buildinfo Checksums-Sha256: 7ccbf0f383389ee308f2ed07bdf6cdea1b210ce57ad0f86c3171abc03e5a92e7 2270 wireless-regdb_2022.04.08-2.dsc e502b481a3431fa8ac6970dd9cc258758d1660616938302a4c4336f20dbfe6bd 18504 wireless-regdb_2022.04.08-2.debian.tar.xz 6d93e1f912b9944f62f413008f15f3e8b2ad1b6091a2e5490ea95cfeabb12b48 7427 wireless-regdb_2022.04.08-2_source.buildinfo Files: a36033f129f73a1dad095343c001c31d 2270 net optional wireless-regdb_2022.04.08-2.dsc a90611177003018ff19e2e92f303a9e6 18504 net optional wireless-regdb_2022.04.08-2.debian.tar.xz 30b375065455cad58af4180da57a6f43 7427 net optional wireless-regdb_2022.04.08-2_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmK8y+cACgkQ57/I7JWG EQnphhAAwyuNMrFir05nTTxw7KeiWIYM05sL978L7afZvIshK0PuansqHivJHngA YIq2Py8CG8MaX5+KMCT7ouN44/cWgtl/2r7UMMKYMsib7s41PpijahIPkzxll5NG uvANpssqsKTnhzfq3zgFLyhJDN461Sj9Y8k0dIPY2wI1kbhGTtlqpwZOAbfkISbb t+LpWiviMiMjmupioyVBOvuE+RD+X0DDrYqqubQYtBtJOyF90Exlf3yU7fVL4I9m ximGg1PDNFPcQsKS654eBKvdmHK0kV/DCdu2bUnl7EeYDvDlyNdbj7UZsDNKOMjf cssIYjz4S2pRedE4lZ+PDTUnb9A0hYDUGbgizYdH5IfmFinmnQR4s+H9FlAAR4/f PSnqkqXgXypLeommeUEzVfxYyuYgDC0VvjGrORCpO6PEgSo7mXxd3jhP2QA9G+GE zqrHB2sbBx6ACBQyxNg+mxgH00BZxxqsW99/ovSfhLV1ZMz4lGU0OqSGRFHNAsUV 9LQHwISWkcqrzoE8PPkcGygliunRME9KmY31RafU35P2RNxmHVM3w3NGehv+90cx VB7rz4Z4UIzkwRsUc4kVqp6vlDmPQNQrv1U8nHoysif0UKkNxWc75Q9cI+HHRBaU oAPxTyXt+lOd9BlJoq5sUVZfsrJqhvASXmMY44s0QJu1orWwK6E= =BWCX -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of wireless-regdb_2022.04.08-2~deb11u1_source.changes
wireless-regdb_2022.04.08-2~deb11u1_source.changes uploaded successfully to localhost along with the files: wireless-regdb_2022.04.08-2~deb11u1.dsc wireless-regdb_2022.04.08-2~deb11u1.debian.tar.xz wireless-regdb_2022.04.08-2~deb11u1_amd64.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#1012601: marked as done (wireless-regdb: alternative broken on debian-installer install)
Your message dated Wed, 29 Jun 2022 23:32:25 + with message-id and subject line Bug#1012601: fixed in wireless-regdb 2022.04.08-2 has caused the Debian Bug report #1012601, regarding wireless-regdb: alternative broken on debian-installer install to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1012601: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012601 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: wireless-regdb Version: 2021.08.28-1 Severity: important Tags: d-i X-Debbugs-Cc: debian-b...@lists.debian.org Dear Maintainer, I've noticed after installing wireless-regdb on a fresh install the package-provided file is not actually used (older version from wireless-regdb-udeb is used), and update-alternative to select the upstream version of the regdb also fails (debian-boot@l.d.o: sorry for the explicit cc, I'm not really sure what the d-i tag implies) The problem is that the installer copies /lib/firmware/regulatory.db and /lib/firmware/regulatory.db.p7s from the installer, and wireless-regdb postinstall script does not overwrite these if they exist. This can be reproduced in a minimal container: root@00e7025e1eeb:/# mkdir /lib/firmware root@00e7025e1eeb:/# touch /lib/firmware/regulatory.db root@00e7025e1eeb:/# apt install -y wireless-regdb Reading package lists... Done Building dependency tree... Done Reading state information... Done Suggested packages: crda The following NEW packages will be installed: wireless-regdb 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 13.9 kB of archives. After this operation, 42.0 kB of additional disk space will be used. Get:1 http://deb.debian.org/debian bullseye/main amd64 wireless-regdb all 2020.04.29-2 [13.9 kB] Fetched 13.9 kB in 0s (222 kB/s) debconf: delaying package configuration, since apt-utils is not installed Selecting previously unselected package wireless-regdb. (Reading database ... 6662 files and directories currently installed.) Preparing to unpack .../wireless-regdb_2020.04.29-2_all.deb ... Unpacking wireless-regdb (2020.04.29-2) ... Setting up wireless-regdb (2020.04.29-2) ... update-alternatives: using /lib/firmware/regulatory.db-debian to provide /lib/firmware/regulatory.db (regulatory.db) in auto mode update-alternatives: warning: not replacing /lib/firmware/regulatory.db with a link update-alternatives: warning: forcing reinstallation of alternative /lib/firmware/regulatory.db-debian because link group regulatory.db is broken update-alternatives: warning: not replacing /lib/firmware/regulatory.db with a link root@00e7025e1eeb:/# ls -l /lib/firmware/regulatory.db* -rw-r--r-- 1 root root0 Jun 10 00:21 /lib/firmware/regulatory.db -rw-r--r-- 1 root root 3764 Jun 30 2020 /lib/firmware/regulatory.db-debian -rw-r--r-- 1 root root 3764 Jun 30 2020 /lib/firmware/regulatory.db-upstream lrwxrwxrwx 1 root root 35 Jun 10 00:21 /lib/firmware/regulatory.db.p7s -> /etc/alternatives/regulatory.db.p7s -rw-r--r-- 1 root root 1249 Jun 30 2020 /lib/firmware/regulatory.db.p7s-debian -rw-r--r-- 1 root root 1182 Jun 30 2020 /lib/firmware/regulatory.db.p7s-upstream root@00e7025e1eeb:/# update-alternatives --config regulatory.db There are 2 choices for the alternative regulatory.db (providing /lib/firmware/regulatory.db). SelectionPath Priority Status 0/lib/firmware/regulatory.db-debian 100 auto mode * 1/lib/firmware/regulatory.db-debian 100 manual mode 2/lib/firmware/regulatory.db-upstream 50manual mode Press to keep the current choice[*], or type selection number: update-alternatives: warning: forcing reinstallation of alternative /lib/firmware/regulatory.db-debian because link group regulatory.db is broken update-alternatives: warning: not replacing /lib/firmware/regulatory.db with a link root@00e7025e1eeb:/# ls -l /lib/firmware/regulatory.db -rw-r--r-- 1 root root0 Jun 10 00:21 /lib/firmware/regulatory.db Running with --force removes the original file with a warning and works: root@00e7025e1eeb:/# update-alternatives --force --config regulatory.db There are 2 choices for the alternative regulatory.db (providing /lib/firmware/regulatory.db). SelectionPath Priority Status 0/lib/firmware/regulatory.db-debian 100 auto mode * 1/lib/firmware/regulatory.db-debian
Processing of wireless-regdb_2022.04.08-2_source.changes
wireless-regdb_2022.04.08-2_source.changes uploaded successfully to localhost along with the files: wireless-regdb_2022.04.08-2.dsc wireless-regdb_2022.04.08-2.debian.tar.xz wireless-regdb_2022.04.08-2_source.buildinfo Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport
Control: forwarded -1 https://lore.kernel.org/all/20220629224938.7760-1-didi.deb...@cknow.org/ On Wednesday, 29 June 2022 15:24:45 CEST Ben Hutchings wrote: > Looks good to me. Can you send it on to sta...@vger.kernel.org? > You'll need to add your Signed-off-by. Done. signature.asc Description: This is a digitally signed message part.
Processed: Re: Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport
Processing control commands: > forwarded -1 > https://lore.kernel.org/all/20220629224938.7760-1-didi.deb...@cknow.org/ Bug #1013299 [src:linux] linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport Set Bug forwarded-to-address to 'https://lore.kernel.org/all/20220629224938.7760-1-didi.deb...@cknow.org/'. -- 1013299: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013299 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: tagging 1012835
Processing commands for cont...@bugs.debian.org: > tags 1012835 - security Bug #1012835 [src:linux] linux-image-5.10.0-15-amd64: entropy dropped to 256 from ~4k after 5.10.120-1 update Bug #1013192 [src:linux] linux-image-5.10.0-15-amd64: ridiculously small entropy pool Bug #1013241 [src:linux] upgrade-reports: kernel upgrade 5.10.0.9 to 5.10.0.15 Bug #1013982 [src:linux] linux-image-5.10.0-15-amd64: Available entropy is a constant Removed tag(s) security. Removed tag(s) security. Removed tag(s) security. Removed tag(s) security. > thanks Stopping processing here. Please contact me if you need assistance. -- 1012835: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012835 1013192: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013192 1013241: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013241 1013982: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013982 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1014038: marked as done (linux-image-5.10.0-15-amd64: write protected files deleted)
Your message dated Wed, 29 Jun 2022 20:56:44 +0200
with message-id
and subject line Re: Bug#1014038: linux-image-5.10.0-15-amd64: write protected
files deleted
has caused the Debian Bug report #1014038,
regarding linux-image-5.10.0-15-amd64: write protected files deleted
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1014038: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014038
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:linux
Version: 5.10.120-1
Severity: critical
Justification: causes serious data loss
X-Debbugs-Cc: piob...@mindspring.com
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Within Dolphin, a folder was highlighted. This folder was a development folder
congaing read-only backup files.
I clicked on a file that was obsolete, and instrcuted Dolphin to . I
did not notice that clicking on the obsolete file did not un-highlight the
development folder.
* What was the outcome of this action?
Both the obsolete file and the development file were deleted entirely.
* What outcome did you expect instead?
A notice of failure because of attempt to delete a read-only file
-- Package-specific info:
** Version:
Linux version 5.10.0-15-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP
Debian 5.10.120-1 (2022-06-09)
** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-15-amd64
root=UUID=baba1d66-1d46-4fc8-a6ea-50135e908f3f ro quiet
** Tainted: POE (12289)
* proprietary module was loaded
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
Unable to read kernel log; any relevant messages should be attached
** Model information
sys_vendor: Gigabyte Technology Co., Ltd.
product_name: To be filled by O.E.M.
product_version: To be filled by O.E.M.
chassis_vendor: Gigabyte Technology Co., Ltd.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: F5
board_vendor: Gigabyte Technology Co., Ltd.
board_name: 970A-D3P
board_version: To be filled by O.E.M.
** Loaded modules:
nls_ascii
nls_cp437
vfat
fat
vboxnetadp(OE)
vboxnetflt(OE)
rfkill
vboxdrv(OE)
binfmt_misc
usblp
s5h1411
cx88_dvb
cx88_vp3054_i2c
videobuf2_dvb
dvb_core
rc_fusionhdtv_mce
ir_kbd_i2c
xc5000
snd_hda_codec_via
tuner
snd_hda_codec_generic
snd_hda_codec_hdmi
ledtrig_audio
edac_mce_amd
snd_hda_intel
kvm_amd
ccp
snd_intel_dspcfg
soundwire_intel
rng_core
soundwire_generic_allocation
snd_soc_core
kvm
snd_compress
cx88_alsa
soundwire_cadence
snd_hda_codec
cx8800
cx8802
videobuf2_dma_sg
cx88xx
snd_hda_core
irqbypass
videobuf2_memops
tveeprom
videobuf2_v4l2
rc_core
snd_hwdep
ghash_clmulni_intel
joydev
soundwire_bus
videobuf2_common
videodev
aesni_intel
snd_pcm
mc
libaes
snd_timer
crypto_simd
i2c_algo_bit
cryptd
snd
glue_helper
soundcore
pcspkr
sp5100_tco
k10temp
fam15h_power
sg
watchdog
evdev
acpi_cpufreq
nvidia_drm(POE)
drm_kms_helper
cec
nvidia_modeset(POE)
nvidia(POE)
ipmi_devintf
ipmi_msghandler
msr
parport_pc
ppdev
lp
drm
parport
fuse
configfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
hid_logitech_hidpp
hid_logitech_dj
hid_generic
usbhid
hid
uas
usb_storage
sd_mod
sr_mod
cdrom
t10_pi
crc_t10dif
crct10dif_generic
ohci_pci
ata_generic
pata_atiixp
ahci
xhci_pci
libahci
crct10dif_pclmul
crct10dif_common
xhci_hcd
ohci_hcd
crc32_pclmul
ehci_pci
libata
ehci_hcd
crc32c_intel
r8169
usbcore
realtek
scsi_mod
mdio_devres
i2c_piix4
libphy
usb_common
button
** Network interface configuration:
*** /etc/network/interfaces:
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
** Network status:
*** IP interfaces and addresses:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: mtu 1500 qdisc pfifo_fast state UP
group default qlen 1000
link/ether 74:d4:35:07:71:cf brd ff:ff:ff:ff:ff:ff
inet 192.168.1.204/24 brd 192.168.1.255 scope global dynamic noprefixroute
enp3s0
valid_lft 78628sec preferred_lft 78628sec
inet6 2600:4040:1043:8c00:edfe:ceb3:eed9:7126/64 scope global temporary
dynamic
valid_lft 7038sec preferred_lft 7038sec
inet6 2600:4040:1043:8c00:76d4:35ff:fe07:71cf/64 scope global dynamic
mngtmpaddr noprefixroute
valid_lft 7038sec
Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport
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#1014065: i915: Blank screen on resume from suspend to RAM on Intel Iris Xe i915
Package: src:linux Version: 5.18.5-1 Severity: normal File: i915 -- Package-specific info: ** Version: Linux version 5.18.0-2-amd64 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.3.0-3) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.50.20220615) #1 SMP PREEMPT_DYNAMIC Debian 5.18.5-1 (2022-06-16) ** Command line: BOOT_IMAGE=/vmlinuz-5.18.0-2-amd64 root=/dev/mapper/debian_vg-debian_root ro rootflags=subvol=@rootfs net.ifnames=0 biosdevname=0 splash quiet ** Tainted: UW (576) * taint requested by userspace application * kernel issued warning ** Kernel log: [ 2301.468336] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2304.801568] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2307.468246] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2312.416912] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI [ 2319.139810] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] Failed to enable link training [ 2321.098775] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2324.431984] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2327.098973] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2332.044406] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI [ 2339.078966] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] Failed to enable link training [ 2341.392741] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2344.059327] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2346.726030] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2351.650385] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI [ 2358.516906] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] Failed to enable link training [ 2360.330289] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2363.663623] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2366.330695] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2371.420772] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI [ 2378.515903] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] Failed to enable link training [ 2380.621812] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2383.288376] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2385.955030] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2390.881154] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI [ 2397.872907] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] Failed to enable link training [ 2400.228249] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2402.894802] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2405.561459] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2410.292321] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI [ 2416.981272] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] Failed to enable link training [ 2418.981803] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2422.315095] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2424.981741] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2429.923831] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI [ 2437.040902] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] Failed to enable link training [ 2439.271490] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2441.938022] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2444.604655] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2449.529213] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI [ 2456.312453] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] Failed to enable link training [ 2458.208989] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2461.542393] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2464.209041] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2469.199262] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI [ 2476.273890] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] Failed to enable link training [ 2478.504395] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2481.170945] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2483.837685] i915 :00:02.0: [drm] *ERROR* Failed to read DPCD register 0x92 [ 2488.763900] i915 :00:02.0: [drm] *ERROR* Failed to write source OUI [ 2495.705784] i915 :00:02.0: [drm] *ERROR* [ENCODER:307:DDI A/PHY A][DPRX] Failed to enable link training [ 2497.456781] i915 :00:02.0: [drm] *ERROR* Failed to
Bug#1010073: Bug 1010073: kernel 4.19: nvme read overhead sometimes, system hangs
ср, 29 черв. 2022 р. о 16:32 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. > Yes and no. Problem reappeared. Helped disable sendfile in nginx
Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport
Diederik de Haas dixit: >I proposed my patch to expedite things and (much) prefer that Thorsten would I’m not the author… >I can do it, but I would like Thorsten to test the patch and confirm it It’s obviously correct, it moves the nil check to the correct place. I tested “the reverse” by doing… @@ -1275,11 +1275,12 @@ static void htb_destroy_class(struct Qdisc *sch, struct htb_class *cl) WARN_ON(!cl->leaf.q); #if (LINUX_VERSION_CODE < KERNEL_VERSION(4, 20, 0)) && \ (!defined(JENS_LINUX_4_19_SL) || (JENS_LINUX_4_19_SL < 221)) qdisc_destroy(cl->leaf.q); #else - qdisc_put(cl->leaf.q); + if (cl->leaf.q) + qdisc_put(cl->leaf.q); #endif } gen_kill_estimator(>rate_est); tcf_block_put(cl->block); kfree(cl); … so the net effect is tested. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: Mutual Investment Proposal
Good Day, My name is Luis Fernandez, I am contacting you because we have investors that have the capacity to invest in any massive project in your country or invest in your existing project that requires funding. Kindly get back to me for more details. Best Regards, Luis Fernandez
Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport
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. 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? signature.asc Description: This is a digitally signed message part.
Bug#1010073: Bug 1010073: kernel 4.19: nvme read overhead sometimes, system hangs
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
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
Processed: Re: Bug#1013299: linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport
Processing control commands: > tag -1 patch Bug #1013299 [src:linux] linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport Added tag(s) patch. > tag -1 - help Bug #1013299 [src:linux] linux-image-4.19.0-20-amd64: NULL pointer deref in qdisc_put() due to missing backport Removed tag(s) help. -- 1013299: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013299 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1014038: linux-image-5.10.0-15-amd64: write protected files deleted
On Wednesday, 29 June 2022 03:38:47 CEST William Melgaard wrote: >* What led up to the situation? > Within Dolphin, a folder was highlighted. This folder was a development > folder congaing read-only backup files. I clicked on a file that was > obsolete, and instrcuted Dolphin to . I did not notice that > clicking on the obsolete file did not un-highlight the development folder. > >* What was the outcome of this action? > Both the obsolete file and the development file were deleted entirely. >* What outcome did you expect instead? > A notice of failure because of attempt to delete a read-only file https://lists.debian.org/debian-kde/2021/08/msg1.html is a discussion about being able to write a read-only file and that was resolved upstream here: https://bugs.kde.org/show_bug.cgi?id=440986 While not exactly the same, it does seem similar. And while its behavior seems *technically* correct, I can understand it is undesirable and unexpected. signature.asc Description: This is a digitally signed message part.
