klibc_2.0.7-1_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 08 Oct 2019 02:14:11 +0100
Source: klibc
Architecture: source
Version: 2.0.7-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Kernel Team 
Changed-By: Ben Hutchings 
Closes: 922814 931416 932926
Changes:
 klibc (2.0.7-1) unstable; urgency=medium
 .
   [ Ben Hutchings ]
   * New upstream version:
 - klcc: Enable stripping even if CONFIG_DEBUG_INFO is enabled
 - run-init: Allow the initramfs to be persisted across root changes
   (thanks to Matthew Garrett)
 - ipconfig: Implement support -d ...:dns0:dns1 options (Closes: #931416)
 - Kbuild: Work around broken "ar s" in binutils 2.32 (see #941921)
   * debian/rules: Reorganise make flags variables
   * debian/rules: Define ARCH for klibc, for all architectures
   * debian/rules: Delete redundant architecture mappings
   * debian/rules: Delete redundant export
   * klibc-utils: Trigger update-initramfs on install/upgrade
   * initramfs-tools: Don't install commands that already exist in /sbin
   * initramfs-tools: Exclude kinit and zcat commands earlier
   * initramfs-tools: Exclude gzip command
   * Drop "resume: Backward compatibility for resume_offset", which will
 not be needed in the next release
   * [klibc] fstype: Drop obsolete support for "ext4dev" (Closes: #932926)
   * debian/control: Set Maintainer to Debian Kernel Team; move maks to
 Uploaders
 .
   [ James Clarke ]
   * debian/control: Restrict m4 build dependency to just sparc
 .
   [ Helmut Grohne ]
   * Honour DEB_BUILD_OPTIONS=nocheck. (Closes: #922814)
Checksums-Sha1:
 19bea2db554b94efa7a657c5742fa0a417c30d08 2105 klibc_2.0.7-1.dsc
 826e384df8534e2f126a1b1316e5813eeefebd16 630557 klibc_2.0.7.orig.tar.gz
 bfb62c06132780a05bf8e919597f09388962a42f 19016 klibc_2.0.7-1.debian.tar.xz
 98afcadae1f9bd83728110a5b5367157f8aa5d5d 6277 klibc_2.0.7-1_source.buildinfo
Checksums-Sha256:
 858ddbf2a9413c290295ede37a928ecd9463aeed52896dcdf7f572974b1097a1 2105 
klibc_2.0.7-1.dsc
 d953f91ef54b2875bba05f9b615dea049987ac935c165c9d08279a61f2eee1e5 630557 
klibc_2.0.7.orig.tar.gz
 7d30df85144fc4f7b0680e2a5166d2091097176a57f0779591675acdcf9ac628 19016 
klibc_2.0.7-1.debian.tar.xz
 0204ba5d2c58166974b3590f860c1c5c2fd337dc35e950afaaa21fa59c16f866 6277 
klibc_2.0.7-1_source.buildinfo
Files:
 2ce8270322dd5c07df2c390cf724e20e 2105 libs optional klibc_2.0.7-1.dsc
 87fea024c7f3c2987348978a740cc0f6 630557 libs optional klibc_2.0.7.orig.tar.gz
 fe9b85b7d0831ed5481c90d21cd5a8fe 19016 libs optional 
klibc_2.0.7-1.debian.tar.xz
 474ed7fd6b0d49ec5a43eef4844c4f09 6277 libs optional 
klibc_2.0.7-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAl2b5GUACgkQ57/I7JWG
EQnq7w/+NO3MqxJwtucHwTgBZsDWSmGbVxwzpsuaWmkQTMs992xfeemwgzf1wZyr
DuKJuMgmb/oFg0bXp/sTc2+kuEKd4G1SZlR1KAeKtGdefOaMC6Fg1dBS6GyLxvR6
6yup6B9loZaoG3V8MRB0osd7hHWDBQgwbAdjk1DKQqbxAsvzBB723gIIV6DiDvWj
ABD8G+ycNt/sWU3TtJ//hgptMcdAJ4PJa/yxERCKmBxxNfZVQ/DVAgWtO8Cly3ke
dWUa8BGg2XbVIqkjnGkP0QZ3VReuow9HNUpgf3p47GA5ROP34ZWJXb+2VdnIESp7
A3u6crcB5+z7ch1D0227G9b4nJL3pdpFbJaoQy/qugX7Eykwzc3EHovBC0T4vJKa
gu146To4mWCK3XVjpqNGtvme8ybDabCoyXjG7so/ViC+2fhwrISkWKtwUsqNuoao
QkzpqvwaS8E5S5iYh/2+C5uAUpFmFgu6pv78YxR2MCsGj+G2Bpnh6iPR+fArtjoZ
j79KwvABMExutN2PhkuOkagXx2JwIPTT1vmtaLC/62J7Mt6oUMOedmduwtIYCWQs
QWA4xgf5exDwsc/FdJ0jDf6FYZF7b7YPlcu3UO01zbrc+gQVPu+BajJy+0kJLmY/
htgo891Lsm/qpfgSxbyFSwT/6boXKf9q1YpgAQKUlYjqCa/ZdS0=
=/A14
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of klibc_2.0.7-1_source.changes

[Debian FTP Masters]

klibc_2.0.7-1_source.changes uploaded successfully to localhost
along with the files:
  klibc_2.0.7-1.dsc
  klibc_2.0.7.orig.tar.gz
  klibc_2.0.7-1.debian.tar.xz
  klibc_2.0.7-1_source.buildinfo

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

Dependency is not satisfiable

[john smith]

The package requires
linux-headers-4.19.0-0.bpo.6-common_4.19.67-2+deb10u1~bpo9+1_amd64
but the corresponding package in stretch-backports is called
linux-headers-4.19.0-0.bpo.6-common_4.19.67-2~bpo9+1_amd64
which leads to a broken dependency.

Bug#941952: marked as done (linux-headers-3.16.0-6-amd64 package removed from stable repository)

[Debian Bug Tracking System]

Your message dated Mon, 07 Oct 2019 23:52:03 +0100
with message-id 
and subject line Re: Bug#941952: linux-headers-3.16.0-6-amd64 package removed 
from stable repository
has caused the Debian Bug report #941952,
regarding linux-headers-3.16.0-6-amd64 package removed from stable repository
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.)


-- 
941952: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941952
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-headers-3.16.0-6-amd64
Version: 3.16.56-1+deb8u1
Severity: normal

Dear Maintainer,

I work for a security focused company and part of my work is to check our DKMS
modules are well supported in Debian, recently I've started to have issues with
the linux-headers-$(uname -r) packages in Debian 8/9, it seems as the kernel
gets updates new linux-headers (linux-image) packages are generated and the
previous ones are removed from the stable repositories, I can workaround this
problem by adding the snapshot repositories, however I'm unsure if this is the
normal behavour in Debian, is there any formal document that states clearly how
these kernel updates are handled to stable users?

At the moment of writing this I'm on a Debian 8.10 system where the running 
kernel
is: uname -r 3.16.0-4-amd64 which has no matching headers
apt-get install linux-headers-$(uname -r)

Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package linux-headers-3.16.0-4-amd64
E: Couldn't find any package by regex 'linux-headers-3.16.0-4-amd64'

The system have more update kernel packages:

$ apt-cache search linux-headers- | grep 3.16
linux-headers-3.16.0-6-all - All header files for Linux 3.16 (meta-package)
linux-headers-3.16.0-6-all-amd64 - All header files for Linux 3.16 
(meta-package)
linux-headers-3.16.0-6-amd64 - Header files for Linux 3.16.0-6-amd64
linux-headers-3.16.0-6-common - Common header files for Linux 3.16.0-6
linux-headers-3.16.0-10-all - All header files for Linux 3.16 (meta-package)
linux-headers-3.16.0-10-all-amd64 - All header files for Linux 3.16 
(meta-package)
linux-headers-3.16.0-10-amd64 - Header files for Linux 3.16.0-10-amd64
linux-headers-3.16.0-10-common - Common header files for Linux 3.16.0-10

-- System Information:
Debian Release: 8.10
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-headers-3.16.0-6-amd64 depends on:
ii  linux-compiler-gcc-4.9-x86 3.16.74-1
ii  linux-headers-3.16.0-6-common  3.16.56-1+deb8u1
ii  linux-kbuild-3.16  3.16.56-1

linux-headers-3.16.0-6-amd64 recommends no packages.

linux-headers-3.16.0-6-amd64 suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Javier López  wrote:
[...]
> it seems as the kernel
> gets updates new linux-headers (linux-image) packages are generated and the
> previous ones are removed from the stable repositories, I can workaround this
> problem by adding the snapshot repositories, however I'm unsure if this is the
> normal behavour in Debian

This is now normal for the Linux kernel packages, but not for packages
in general.  Maintaining a stable kernel module ABI is often
impractical for us, particularly for some of the invasive security
fixes needed over the past 2 years.  Every time we need to break that
ABI, we change the kernel release string and binary package names.

The older packages are then obsolete and not supported in any way by
Debian, and you should not feel obliged to support them either.

> is there any formal document that states clearly how
> these kernel updates are handled to stable users?
[...]

Not precisely.

Users should generally install meta-packages like linux-image-amd64 and
linux-headers-amd64.  (The Debian installer does that.)  When there is
an ABI bump in the kernel during a stable release, the advisory is
supposed to document using "apt upgrade" or "apt-get upgrade
--with-new-pkgs" to upgrade, which will install the new dependency.

There's some documentation of ABI versions:
.

Discussion with the release team about kernel ABI bumps in stable:
.

Ben.

-- 
Ben Hutchings
Nothing is ever a complete failure;
it can alw

Bug#941952: linux-headers-3.16.0-6-amd64 package removed from stable repository

[Javier López]

Package: linux-headers-3.16.0-6-amd64
Version: 3.16.56-1+deb8u1
Severity: normal

Dear Maintainer,

I work for a security focused company and part of my work is to check our DKMS
modules are well supported in Debian, recently I've started to have issues with
the linux-headers-$(uname -r) packages in Debian 8/9, it seems as the kernel
gets updates new linux-headers (linux-image) packages are generated and the
previous ones are removed from the stable repositories, I can workaround this
problem by adding the snapshot repositories, however I'm unsure if this is the
normal behavour in Debian, is there any formal document that states clearly how
these kernel updates are handled to stable users?

At the moment of writing this I'm on a Debian 8.10 system where the running 
kernel
is: uname -r 3.16.0-4-amd64 which has no matching headers
apt-get install linux-headers-$(uname -r)

Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package linux-headers-3.16.0-4-amd64
E: Couldn't find any package by regex 'linux-headers-3.16.0-4-amd64'

The system have more update kernel packages:

$ apt-cache search linux-headers- | grep 3.16
linux-headers-3.16.0-6-all - All header files for Linux 3.16 (meta-package)
linux-headers-3.16.0-6-all-amd64 - All header files for Linux 3.16 
(meta-package)
linux-headers-3.16.0-6-amd64 - Header files for Linux 3.16.0-6-amd64
linux-headers-3.16.0-6-common - Common header files for Linux 3.16.0-6
linux-headers-3.16.0-10-all - All header files for Linux 3.16 (meta-package)
linux-headers-3.16.0-10-all-amd64 - All header files for Linux 3.16 
(meta-package)
linux-headers-3.16.0-10-amd64 - Header files for Linux 3.16.0-10-amd64
linux-headers-3.16.0-10-common - Common header files for Linux 3.16.0-10

-- System Information:
Debian Release: 8.10
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-headers-3.16.0-6-amd64 depends on:
ii  linux-compiler-gcc-4.9-x86 3.16.74-1
ii  linux-headers-3.16.0-6-common  3.16.56-1+deb8u1
ii  linux-kbuild-3.16  3.16.56-1

linux-headers-3.16.0-6-amd64 recommends no packages.

linux-headers-3.16.0-6-amd64 suggests no packages.

-- no debconf information

Bug#941946: linux-image-5.2.0-0.bpo.2-amd64: kernel oops and system freeze after installing firmware-iwlwifi

[Peter Upton]

Package: src:linux
Version: 5.2.9-2~bpo10+1
Severity: important
Tags: upstream

Dear Maintainer,

While running kernel 5.2.0-0.bpo.2-amd64 with firmware-iwlwifi
installed, system freezes and becomes non-responsive to any user input.
Freezing occurs shortly after boot with no warning.

Below are possibly relevent lines from /var/log/messages logged when the system
froze:

Oct  7 13:27:58 petros-laptop kernel: [  419.619222] PGD 45dd29067 P4D 
45dd29067 PUD 0
Oct  7 13:27:58 petros-laptop kernel: [  419.619223] Oops: 0002 [#1] SMP PTI
Oct  7 13:27:58 petros-laptop kernel: [  419.619225] CPU: 4 PID: 4467 Comm: 
kworker/4:0 Tainted: GW 5.2.0-0.bpo.2-amd64 #1 Debian 
5.2.9-2~bpo10+1
Oct  7 13:27:58 petros-laptop kernel: [  419.619226] Hardware name: LENOVO 
20QVCTO1WW/20QVCTO1WW, BIOS N2OET36W (1.23 ) 07/26/2019
Oct  7 13:27:58 petros-laptop kernel: [  419.619229] Workqueue: pm 
pm_runtime_work
Oct  7 13:27:58 petros-laptop kernel: [  419.619289] RIP: 
0010:evo_wait+0x5a/0x130 [nouveau]
Oct  7 13:27:58 petros-laptop kernel: [  419.619290] Code: 00 00 00 89 c3 4c 89 
f7 e8 b3 66 78 ef 89 da 44 01 eb 48 8d 04 95 00 00 00 00 81 fb f7 03 00 00 0f 
86 86 00 00 00 48 8b 45 70  04 90 00 00 00 20 f6 45 58 01 74 09 48 8b 7d 28 
e8 40 e1 ff ff
Oct  7 13:27:58 petros-laptop kernel: [  419.619290] RSP: 0018:ade906ba7c60 
EFLAGS: 00010216
Oct  7 13:27:58 petros-laptop kernel: [  419.619291] RAX: ade901b09000 RBX: 
4033 RCX: 7f084f5a3700
Oct  7 13:27:58 petros-laptop kernel: [  419.619292] RDX: 3fff RSI: 
 RDI: 9f5dde32a0c0
Oct  7 13:27:58 petros-laptop kernel: [  419.619292] RBP: 9f5dbe7c1d08 R08: 
9f5dde32ab10 R09: 
Oct  7 13:27:58 petros-laptop kernel: [  419.619293] R10:  R11: 
0001 R12: 9f5dc0b4e350
Oct  7 13:27:58 petros-laptop kernel: [  419.619293] R13: 0034 R14: 
9f5dbe7c1dd0 R15: 9f5dbe7c1d08
Oct  7 13:27:58 petros-laptop kernel: [  419.619294] FS:  
() GS:9f5dde30() knlGS:
Oct  7 13:27:58 petros-laptop kernel: [  419.619295] CS:  0010 DS:  ES: 
 CR0: 80050033
Oct  7 13:27:58 petros-laptop kernel: [  419.619295] CR2: adea01b08ffc CR3: 
00042154e005 CR4: 003606e0
Oct  7 13:27:58 petros-laptop kernel: [  419.619296] Call Trace:
Oct  7 13:27:58 petros-laptop kernel: [  419.619322]  corec57d_init+0x23/0x110 
[nouveau]
Oct  7 13:27:58 petros-laptop kernel: [  419.619345]  
nv50_display_init+0x34/0xf0 [nouveau]
Oct  7 13:27:58 petros-laptop kernel: [  419.619368]  
nouveau_display_init+0x3b/0xd0 [nouveau]
Oct  7 13:27:58 petros-laptop kernel: [  419.619391]  
nouveau_display_resume+0x23/0x70 [nouveau]
Oct  7 13:27:58 petros-laptop kernel: [  419.619414]  
nouveau_do_suspend+0x152/0x180 [nouveau]
Oct  7 13:27:58 petros-laptop kernel: [  419.619437]  
nouveau_pmops_runtime_suspend+0x3f/0xa0 [nouveau]
Oct  7 13:27:58 petros-laptop kernel: [  419.619439]  
pci_pm_runtime_suspend+0x58/0x140
Oct  7 13:27:58 petros-laptop kernel: [  419.619440]  ? 
pci_has_legacy_pm_support+0x60/0x60
Oct  7 13:27:58 petros-laptop kernel: [  419.619441]  __rpm_callback+0x81/0x140
Oct  7 13:27:58 petros-laptop kernel: [  419.619442]  ? 
pci_has_legacy_pm_support+0x60/0x60
Oct  7 13:27:58 petros-laptop kernel: [  419.619443]  rpm_callback+0x1f/0x70
Oct  7 13:27:58 petros-laptop kernel: [  419.619444]  rpm_suspend+0x10f/0x5f0
Oct  7 13:27:58 petros-laptop kernel: [  419.619446]  ? 
finish_task_switch+0x190/0x270
Oct  7 13:27:58 petros-laptop kernel: [  419.619447]  pm_runtime_work+0x82/0x90
Oct  7 13:27:58 petros-laptop kernel: [  419.619449]  
process_one_work+0x1a7/0x3b0
Oct  7 13:27:58 petros-laptop kernel: [  419.619450]  worker_thread+0x30/0x390
Oct  7 13:27:58 petros-laptop kernel: [  419.619451]  ? 
create_worker+0x1a0/0x1a0
Oct  7 13:27:58 petros-laptop kernel: [  419.619452]  kthread+0x112/0x130
Oct  7 13:27:58 petros-laptop kernel: [  419.619453]  ? 
__kthread_parkme+0x70/0x70
Oct  7 13:27:58 petros-laptop kernel: [  419.619454]  ret_from_fork+0x35/0x40
Oct  7 13:27:58 petros-laptop kernel: [  419.619455] Modules linked in: ccm 
thunderbolt fuse twofish_generic twofish_avx_x86_64 twofish_x86_64_3way 
twofish_x86_64 twofish_common serpent_avx2 serpent_avx_x86_64 
serpent_sse2_x86_64 serpent_generic blowfish_generic blowfish_x86_64 
blowfish_common cast5_avx_x86_64 cast5_generic cast_common ctr des_generic 
algif_skcipher camellia_generic camellia_aesni_avx2 camellia_aesni_avx_x86_64 
camellia_x86_64 xcbc sha512_ssse3 sha512_generic md4 algif_hash af_alg 
xfrm_user xfrm4_tunnel tunnel4 ipcomp xfrm_ipcomp esp4 ah4 l2tp_ppp af_key 
l2tp_netlink xfrm_algo l2tp_core ip6_udp_tunnel udp_tunnel pppox ppp_generic 
slhc rfcomm xt_CHECKSUM nft_chain_nat xt_MASQUERADE nf_nat xt_conntrack 
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c ipt_REJECT nf_reject_ipv4 
nft_counter xt_tcpudp nft_compat tun bridge stp llc cmac nf_t

Bug#941910: marked as done (Patched kernel available in stretch-security, but meta package still points to older image)

[Debian Bug Tracking System]

Your message dated Mon, 07 Oct 2019 19:04:41 +0100
with message-id <1cb07c6c2b0bb9f70dc403cd7ea358bf06adc1a1.ca...@decadent.org.uk>
and subject line Re: Bug#941910: Patched kernel available in stretch-security, 
but meta package still points to older image
has caused the Debian Bug report #941910,
regarding Patched kernel available in stretch-security, but meta package still 
points to older image
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.)


-- 
941910: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941910
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: src:linux-latest
Version: 4.9+80+deb9u9

Dear maintainers,

the binary linux-image-4.9.0-11-amd64 (4.9.189-3+deb9u1) provides some 
CVE fixes and was released to
stretch-security on 20 Sep 2019. However, the associated meta package on 
stretch-security is still
linux-image-amd64 (4.9+80+deb9u6) from 19 Aug 2018, which depends on a 
somewhat older linux package 4.9.0-8.

Is this intentional?

In our setup we pull upgrades from stretch-security only, and refer to 
linux kernel via the meta package. So we end up
with a slightly outdated linux-image-4.9.0-8-amd64, even if a patched 
version was available in stretch-security.
--- End Message ---
--- Begin Message ---
On Mon, 2019-10-07 at 16:28 +0200, Tobias Deiminger wrote:
[...]
> In our setup we pull upgrades from stretch-security only,
[...]

This is not a supported configuration.  You must enable updates from
the stretch (oldstable) suite (point releases) as well as updates from 
the stretch-security suite.

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
--- End Message ---

Correlation between Log Files and Display Report?

[Susmita/Rajib]

To,
The Teams Debian Boot and Kernel,

Dear Sirs, our Illustrious List Maintainers,

I have a need for which I require your help.

I am posting a link to my Question in the Debian forum:
http://forums.debian.net/viewtopic.php?f=5&t=143901&p=708902#p708902

Although I have posted my query on the Debian Forum, I am apprehensive
that the cacophonic forum is not the right place for academic need,
and that I won't receive a suitable reply (and instead be trolled)
unless you specifically and anonymously intervene.

Kindly help.

Regards,
Rajib
(Rajib Bandopadhyay)
A Debian user

Bug#941910: Patched kernel available in stretch-security, but meta package still points to older image

[Tobias Deiminger]

Package: src:linux-latest
Version: 4.9+80+deb9u9

Dear maintainers,

the binary linux-image-4.9.0-11-amd64 (4.9.189-3+deb9u1) provides some 
CVE fixes and was released to
stretch-security on 20 Sep 2019. However, the associated meta package on 
stretch-security is still
linux-image-amd64 (4.9+80+deb9u6) from 19 Aug 2018, which depends on a 
somewhat older linux package 4.9.0-8.

Is this intentional?

In our setup we pull upgrades from stretch-security only, and refer to 
linux kernel via the meta package. So we end up
with a slightly outdated linux-image-4.9.0-8-amd64, even if a patched 
version was available in stretch-security.

Processed: limit source to linux, tagging 940530, tagging 935945

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> limit source linux
Limiting to bugs with field 'source' containing at least one of 'linux'
Limit currently set to 'source':'linux'

> tags 940530 + pending
Bug #940530 [src:linux] Add CONFIG_BRCMFMAC_SDIO=y to linux-image-rpi
Added tag(s) pending.
> tags 935945 + pending
Bug #935945 [src:linux] linux-image-5.2.0-2-amd64: does not load signed kernel 
modules when UEFI Secure Boot is enabled
Bug #939773 [src:linux] linux-image-5.2.0-2-amd64: MOK key not used for 
verification of modules signatures.
Bug #940181 [src:linux] linux-image-5.2.0-2-amd64: Kernel does not accept 
self-signed modules using UEFI db key
Bug #941827 [src:linux] module loading fails with error: "Lockdown: modprobe: 
Loading of unsigned module is restricted; see 
https://wiki.debian.org/SecureBoot";
Added tag(s) pending.
Added tag(s) pending.
Added tag(s) pending.
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
935945: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935945
939773: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939773
940181: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940181
940530: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940530
941827: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941827
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems