Bug#991625: debootstrap: extra-suites= broken; attempts Package.* fetches from primary suite

[TJ]

Package: debootstrap
Version: 1.0.123
Severity: important
X-Debbugs-Cc: deb...@iam.tj

Dear Maintainer,

   * What led up to the situation?

Attempting to reproduce another bug reported on IRC about Ubuntu and
debootstrap

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

/usr/sbin/debootstrap --verbose --arch=amd64
--extra-suites=focal-updates focal ./focal-chroot
http://archive.ubuntu.com/ubuntu

   * What was the outcome of this action?

I: Checking Release signature
I: Valid Release signature (key id
F6ECB3762474EDA9D21B7022871920D1991BC93C)
I: Validating Packages I: Retrieving Packages I: Validating Packages W:
Retrying failed download of
http://archive.ubuntu.com/ubuntu/dists/focal/main/binary-amd64/Packages.xz
I: Retrieving Packages

   * What outcome did you expect instead?

File to be fetched correctly

I inserted debug code and used set -x to narrow down the bug and found
that when EXTRA_SUITES is set, in function download_release_indices(),
in the loop "for s in $SUITE $EXTRA_SUITES; do" that the value of 's' is
being changed in the call to validate_suite() where it does "for s in
$SUITE $EXTRA_SUITES; do" and the first test is successful "if [ "$s" =
"$suite" ] || [ "$s" = "$CODENAME" ]; then return 0".

In the example case this resets the suite being processed from
'focal-updates' to 'focal' and so files are downloaded from the focal
suite but the hashes tested against are from the focal-updates
Releases file, causing the validation to fail.

Patch to fix the issue at the end of this email.


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

Kernel: Linux 5.13.0-soggy-02736-g7f1d227e86a3 (SMP w/4 CPU threads;
PREEMPT)
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debootstrap depends on:
ii  wget  1.21-1+b1

Versions of packages debootstrap recommends:
ii  arch-test   0.17-1
ii  debian-archive-keyring  2021.1.1
ii  gnupg   2.2.27-2

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

-- no debconf information

--
commit 23bb0a9f3c39b1f23f6c27bd7e8e85f43d7a0316 (HEAD -> master)
Author: Tj 
Date:   Wed Jul 28 21:27:01 2021 +0100

fix: download correct extra-suites Packages files

diff --git a/functions b/functions
index 09d93f4..ec34d84 100644
--- a/functions
+++ b/functions
@@ -551,7 +551,7 @@ extract_release_components () {
  CODENAME=""
 validate_suite () {
-   local reldest suite
+   local reldest suite s
reldest="$1"
 CODENAME=$(sed -n "s/^Codename: *//p" "$reldest")

Bug#991621: unblock: util-linux/2.36.1-8

[Chris Hofstaedtler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package util-linux

[ Reason ]
Fix for security bug CVE-2021-37600, reported as Debian bug #991619

[ Impact ]
Security issue remains open. From an util-linux perspective, I think
this is a local (=non-remote) issue.

[ Tests ]
util-linux build-time tests cover ipcs and lsipc, which are the two
affected commands.

[ Risks ]
The security bug is in a shared static .c file, used by the ipcs and
lsipc commands. I hope that ipc shmem/queue/semaphore users do not shell
out to ipcs/lsipc, and instead use some library. If this is true, only
"inspection" use cases of local admins would possibly break.


[ 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 ]
util-linux builds udebs. debian-boot@ is x-cc'ed.

unblock util-linux/2.36.1-8


diff -Nru util-linux-2.36.1/debian/changelog util-linux-2.36.1/debian/changelog
--- util-linux-2.36.1/debian/changelog  2021-02-07 14:38:19.0 +
+++ util-linux-2.36.1/debian/changelog  2021-07-28 19:09:07.0 +
@@ -1,3 +1,9 @@
+util-linux (2.36.1-8) unstable; urgency=medium
+
+  * Apply upstream patch for CVE-2021-37600 (Closes: #991619)
+
+ -- Chris Hofstaedtler   Wed, 28 Jul 2021 19:09:07 +
+
 util-linux (2.36.1-7) unstable; urgency=medium
 
   * libmount: allow --read-only for not-root users.
diff -Nru util-linux-2.36.1/debian/patches/series 
util-linux-2.36.1/debian/patches/series
--- util-linux-2.36.1/debian/patches/series 2021-02-07 14:38:19.0 
+
+++ util-linux-2.36.1/debian/patches/series 2021-07-28 19:09:07.0 
+
@@ -6,3 +6,4 @@
 debian/verbose-tests.patch
 upstream/libmount-do-not-canonicalize-ZFS-source-dataset.patch
 upstream/libmount-allow-read-only-for-not-root-users.patch
+upstream/CVE-2021-37600-sys-utils-ipcutils-be-careful-when-call-calloc.patch
diff -Nru 
util-linux-2.36.1/debian/patches/upstream/CVE-2021-37600-sys-utils-ipcutils-be-careful-when-call-calloc.patch
 
util-linux-2.36.1/debian/patches/upstream/CVE-2021-37600-sys-utils-ipcutils-be-careful-when-call-calloc.patch
--- 
util-linux-2.36.1/debian/patches/upstream/CVE-2021-37600-sys-utils-ipcutils-be-careful-when-call-calloc.patch
   1970-01-01 00:00:00.0 +
+++ 
util-linux-2.36.1/debian/patches/upstream/CVE-2021-37600-sys-utils-ipcutils-be-careful-when-call-calloc.patch
   2021-07-28 19:09:07.0 +
@@ -0,0 +1,23 @@
+From: Karel Zak 
+Date: Tue, 27 Jul 2021 11:58:31 +0200
+Subject: sys-utils/ipcutils: be careful when call calloc() for uint64 nmembs
+
+Fix: https://github.com/karelzak/util-linux/issues/1395
+Signed-off-by: Karel Zak 
+---
+ sys-utils/ipcutils.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/sys-utils/ipcutils.c b/sys-utils/ipcutils.c
+index 674b612..f2b04dd 100644
+--- a/sys-utils/ipcutils.c
 b/sys-utils/ipcutils.c
+@@ -218,7 +218,7 @@ static void get_sem_elements(struct sem_data *p)
+ {
+   size_t i;
+ 
+-  if (!p || !p->sem_nsems || p->sem_perm.id < 0)
++  if (!p || !p->sem_nsems || p->sem_nsems > SIZE_MAX || p->sem_perm.id < 
0)
+   return;
+ 
+   p->elements = xcalloc(p->sem_nsems, sizeof(struct sem_elem));

Bug#968195: keyboard-configuration: cannot set specific layout Français (Bépo, ergonomique, façon Dvorak, AFNOR) for tty console

[Cyril Brulebois]

Hi Sébastien,

Sébastien Villemot  (2021-07-28):
> I have prepared a merge request, improving on the patch submitted by
> Anisse Astier in #984427:
> 
>  https://salsa.debian.org/installer-team/console-setup/-/merge_requests/8
> 
> I’d really like to have this fixed in bullseye. It’s still possible to
> have it fixed before the unblock request deadline (on 2021-08-03).
> Otherwise it will have to go in a stable point update. In any case, I’m
> willing to do the necessary work (even NMUing if that’s ok with the
> maintainers).

Thanks for the offer, but that sounds like 11.1 material to me; I can
deal with spu after it's been uploaded and tested in unstable+testing
post-release.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Processed: reassign 968195 to console-setup, forcibly merging 968195 984427

[Debian Bug Tracking System]

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

> reassign 968195 console-setup 1.196
Bug #968195 [keyboard-configuration] keyboard-configuration: cannot set 
specific layout Français (Bépo, ergonomique, façon Dvorak, AFNOR) for tty 
console
Bug reassigned from package 'keyboard-configuration' to 'console-setup'.
No longer marked as found in versions console-setup/1.196.
Ignoring request to alter fixed versions of bug #968195 to the same values 
previously set
Bug #968195 [console-setup] keyboard-configuration: cannot set specific layout 
Français (Bépo, ergonomique, façon Dvorak, AFNOR) for tty console
Marked as found in versions console-setup/1.196.
> forcemerge 968195 984427
Bug #968195 [console-setup] keyboard-configuration: cannot set specific layout 
Français (Bépo, ergonomique, façon Dvorak, AFNOR) for tty console
Bug #968195 [console-setup] keyboard-configuration: cannot set specific layout 
Français (Bépo, ergonomique, façon Dvorak, AFNOR) for tty console
Marked as found in versions console-setup/1.201.
Bug #984427 [console-setup] console-setup: ckbcomp generates invalid linux 
keymaps
Severity set to 'important' from 'normal'
Marked as found in versions console-setup/1.196.
Merged 968195 984427
> thanks
Stopping processing here.

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

Processed (with 1 error): Re: Bug#968195: keyboard-configuration: cannot set specific layout Français (Bépo, ergonomique, façon Dvorak, AFNOR) for tty console

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + patch
Bug #968195 [keyboard-configuration] keyboard-configuration: cannot set 
specific layout Français (Bépo, ergonomique, façon Dvorak, AFNOR) for tty 
console
Added tag(s) patch.
> forcemerge -1 984427
Bug #968195 [keyboard-configuration] keyboard-configuration: cannot set 
specific layout Français (Bépo, ergonomique, façon Dvorak, AFNOR) for tty 
console
Unable to merge bugs because:
package of #984427 is 'console-setup' not 'keyboard-configuration'
Failed to forcibly merge 968195: Did not alter merged bugs.


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

Bug#968195: keyboard-configuration: cannot set specific layout Français (Bépo, ergonomique, façon Dvorak, AFNOR) for tty console

[Sébastien Villemot]

Control: tags -1 + patch
Control: forcemerge -1 984427

Le vendredi 23 juillet 2021 à 15:02 +0200, Sébastien Villemot a écrit :
Le lundi 10 août 2020 à 11:49 +0300, Jean-Louis Biasini a écrit :
> Package: keyboard-configuration
> Version: 1.196
> Severity: important

> * What exactly did you do (or not do) that was effective (or
> ineffective)?
> console tty:
> $ sudo dpkg-reconfigure keyboard-configuration
> choosing Français (Bépo, ergonomique, façon Dvorak, AFNOR)
> $ sudo systemctl restart keyboard-setup
> * What was the outcome of this action?
> still in en us

I was also hit by this bug. I confirm that setupcon is unable to load
the “fr(bepo_afnor)” keymap.

> The problem is that loadkeys fails to load the keymap generated by
> ckbcomp. It errors out with this message:
>
>  too many (160) entries on one line

The problem comes from the fact that the “fr(bepo_afnor)” keymap has a
Unicode code point above 0x (more precisely U+1F12F, the copyleft
symbol, which appears on key BKSL; see line 647 of
/usr/share/X11/xkb/symbols/fr).

Those code points are not handled by the Linux console (and actually,
loadkeys interpret them as two code points, hence the “too many
entries” message).

I have prepared a merge request, improving on the patch submitted by
Anisse Astier in #984427:

 https://salsa.debian.org/installer-team/console-setup/-/merge_requests/8

I’d really like to have this fixed in bullseye. It’s still possible to
have it fixed before the unblock request deadline (on 2021-08-03).
Otherwise it will have to go in a stable point update. In any case, I’m
willing to do the necessary work (even NMUing if that’s ok with the
maintainers).

Best,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org




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

hw-detect_1.147_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 28 Jul 2021 09:05:05 +0200
Source: hw-detect
Architecture: source
Version: 1.147
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Cyril Brulebois 
Changes:
 hw-detect (1.147) unstable; urgency=medium
 .
   * Add support for CHECK_MISSING_FIRMWARE=0 to hw-detect. This makes it
 possible for some callers (e.g. cdrom-detect, maybe iso-scan too) to
 avoid triggering firmware-related prompts when it's too early in the
 installation process to do anything about it (See: #991587, #991590).
Checksums-Sha1:
 27dc587eae90c0f3a1ee238701f6c39261baacda 2025 hw-detect_1.147.dsc
 fb68477a584f2aaf783aa25247a3f4718e9b2f47 18 hw-detect_1.147.tar.xz
 37c54af865dc7dcdb1f245626e86b6517003d777 6078 hw-detect_1.147_source.buildinfo
Checksums-Sha256:
 c9923cc7b1a80982e364aaf3bb22cc20c1465d1eba12c9b756b833dd77673650 2025 
hw-detect_1.147.dsc
 7bdca57be80776a385cfdd0cea5eb0d6350f2d22e645ee92446dbe3b71c4ecd8 18 
hw-detect_1.147.tar.xz
 f2a0314fb62e6fae6696f52a8c38835b8ed6ef522639a3995c77989ef483ab31 6078 
hw-detect_1.147_source.buildinfo
Files:
 ef31968417d69622b8321ea552da0563 2025 debian-installer standard 
hw-detect_1.147.dsc
 13fc3fa66c874dc5492ec1af3072f35a 18 debian-installer standard 
hw-detect_1.147.tar.xz
 8314f6889b54bc414ecb17ab61d00c3a 6078 debian-installer standard 
hw-detect_1.147_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmEBDakQHGtpYmlAZGVi
aWFuLm9yZwAKCRD/kUrwwrNVIKIHD/4uEyEdALg1sGqdWBSOeqCR3WcFmdAocqLH
hZVE4njUlu/twxOEIn0EUEZqDxAN5x7o8KQAx85WAUG5/MdgH2CAI20tSFC8YxR1
g2meln1FYFNde2WG41H7+PCYC7b15liDKzv9JYCGsNOpthp5Bp2MtB1lrUaI8oJH
LqbDx71wJe+M7hrnrXN9IgJvT8DBwSUnxE8FtCyn0fSeapbWGTAJsRg2APcoaSuj
iyLwXwPRfMIVA2A9uMrS0RibgOES1z+blo561oPkIC3R7vv3FFsV/JafTSofGq8H
zFRP2uCzAW4UFIZVVDtJ9TPWAhZbT84ltTmxJIXZff82Rq8Le8K9C6h8J7QcLk7V
6qjOHPlmTgnU0esc2B8IepBVjWEKapESMmMhxTnvZIGgVpa7+zyyFq6Y6p22faH3
j5ULvetX36z8fVcpk3wv0LMwjsJasqP3tZbFtQOcQpyQRarAP/nn9gbukH7kiPjq
B1FpoAOW51ImROJW/stEaRaJJuov0Kx/iLP85zetwIf91Wux3cR1V0HgZsxRV7gZ
p+0qnfOBpntJPR+S0JNv75MD89xIiUvNzglqa7sNSLpduLHdXMGykRMhWHfLWywg
G+hVjSCW+NqwQV5dv+/Em83d5MORcElYwYlmv09pfxztUl/nugWvdiqjbMyjqO5P
6ck7WYY1Lg==
=Dxfn
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of hw-detect_1.147_source.changes

[Debian FTP Masters]

hw-detect_1.147_source.changes uploaded successfully to localhost
along with the files:
  hw-detect_1.147.dsc
  hw-detect_1.147.tar.xz
  hw-detect_1.147_source.buildinfo

Greetings,

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

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

[Cyril Brulebois]

Cyril Brulebois  (2021-07-26):
> > ## proposed solution
> > 
> > If others agree, I suggest we add the following somewhere in the
> > installation guide (I don't think we should have a specific warning
> > in the installer; or more specifically it would be way too late to
> > have it be shown localized at this stage; more on that in the second
> > part of my mail). Heavily summarized (to give readers of this bug
> > report an idea, not for direct user consumption!!!): […]
> 
> Given Paul's ACK, I'll turn this into a bug report against the
> installation guide, with a slightly better draft.

This is my next action.

> This was uploaded to unstable, I'm currently waiting for the updated
> metadata to show up in the archive.

That propagated to unstable, resulted in successful testing with a
hacked debian-cd setup (pulling metadata from unstable instead of
testing), so I augmented Paul's unblock hint for firmware-nonfree with a
urgent, and we tested a non-hacked debian-cd setup as well.

> Basically, we extract the relevant bits from the DEP-11 YAML file, and
> generate patterns files that we ship on the firmware-enabled images:
>  - /firmware has firmware-*.deb
>  - /firmware/dep-11 has firmare-*.patterns
> 
> Meanwhile, I've hacked d-i to include those files, built manually
> while the rest was being worked on, so that I could test the runtime
> on my test laptops.

A difference between both (hacked d-i vs. proper debian-cd build) is
where the firmware directory appears, and that was addressed in this
upload (pushed to testing already):
  
https://salsa.debian.org/installer-team/hw-detect/-/commit/bc214296310c86f2144d50953b39d2f7628be136?w=1
  
https://tracker.debian.org/news/1245070/accepted-hw-detect-1146-source-into-unstable/

With that fix in place, I discovered another annoyance (this wouldn't
have been a blocker in my book, but that could surprise people):
  https://bugs.debian.org/991587 [cdrom-detect]
  https://bugs.debian.org/991590 [iso-scan, cloned]

which I've just fixed (even if that was only manually tested) in
hw-detect + cdrom-detect; the iso-scan bug report can stay around, I
don't think we need to rush acting on it: the cdrom-detect codepath is
much more likely to be hit as far as I understand it (that's what
happens with ISO images like netinst at least…).

I'll retest “for real” once packages are in the archive, once I've
triggered a new d-i daily build, and once debian-cd has spinned another
firmware-enabled netinst daily build, but besides a possible typo here
or there, I think I'm out of obvious issues that need fixing!

(At least on those two machines I've been re-installing over and over.)

> >  - make sure the relevant information bubbles up to the dep11/Components
> >files (YAML format, even if the excerpts above were XML);
> 
> TODO.

Done, with unstable, then with testing; everything looks good.

> >  - have debian-cd extract the relevant firmware package←→modalias
> >mapping from YAML into one or N flat files to be consumed by d-i, for
> >firmware-enabled images primarily (or exclusively);
> 
> DONE, to be checked once the previous item is complete, and some
> fixups might be required until a full image build behaves like my
> heavily hacked netboot-gtk images (meaning purely from
> debian-installer.git, no debian-cd involved).

Done checking… and fixing (see details above).

> Therefore, I'm tempted to blacklist this firmware file in hw-detect
> (i.e. pretend it was never requested).

Given Salvatore's mention of #969264 & #966218 (thanks!), I've added
this commit:
  
https://salsa.debian.org/installer-team/hw-detect/-/commit/82519629d9db3ccbcf7cc45ce87c0a7238008efd

Besides some builds (hw-detect, cdrom-detect, linux) and some final
tests (then migration to testing), I think we have all the pieces for
D-I Bullseye RC 3.

Whether we need a D-I Bullseye RC 4 (or 5…) for the final 11.0 builds
will depend on bug reports we might received on RC 3 is out, and our
ability (and confidence) with respect to triaging/fixing issues in a
timely manner. If RC 3 doesn't end in seasonal fireworks, I'd be happy
to defer any more code changes to 11.1… Time (and tests) will tell!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

cdrom-detect_1.98_source.changes ACCEPTED into unstable

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 28 Jul 2021 09:14:55 +0200
Source: cdrom-detect
Architecture: source
Version: 1.98
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Cyril Brulebois 
Closes: 991587
Changes:
 cdrom-detect (1.98) unstable; urgency=medium
 .
   * Set CHECK_MISSING_FIRMWARE=0 when calling hw-detect. Detecting the
 installation image happens very early in the installation process, and
 it's unlikely to require some firmware to access whatever device holds
 it (and in the case of an unofficial firmware-enabled image, firmware
 packages would be inside the ISO, that hasn't been mounted yet). This
 can avoid prompts about missing firmware files for e.g. sound modules
 (like Intel SOF) early in the installation process (Closes: #991587).
Checksums-Sha1:
 666dc6e1cab55459302b0f187af98bfb5c185793 1648 cdrom-detect_1.98.dsc
 82ed7ccbfb7b21e58270d872755c842050c0456c 136760 cdrom-detect_1.98.tar.xz
 41b250a21e442cd9f5c25bbdf88ef686a86de7c5 5977 
cdrom-detect_1.98_source.buildinfo
Checksums-Sha256:
 e0b83d7541bd37220ccbde4531bebe753e58684a114fc0f393e8b706441c173f 1648 
cdrom-detect_1.98.dsc
 a3ee0b65cd9bc7581fdbbf24445b99e455f4be0ab3412ab15a869e4ca8e18f0f 136760 
cdrom-detect_1.98.tar.xz
 d1fac8525eb4704f01d8563cc44d2ae6c4c1e011dbafd3747cc719b9aef363f8 5977 
cdrom-detect_1.98_source.buildinfo
Files:
 8a684af450e8c7a8815df621e9a002a6 1648 debian-installer optional 
cdrom-detect_1.98.dsc
 70a8ca5c4943237f2c21bc4df6895b4d 136760 debian-installer optional 
cdrom-detect_1.98.tar.xz
 7b7bff0cbfad0dc18952729c00a5b525 5977 debian-installer optional 
cdrom-detect_1.98_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmEBBCEQHGtpYmlAZGVi
aWFuLm9yZwAKCRD/kUrwwrNVICooD/9fsFNRjZWa2suLT+fYJ9yr9LOWeJRCiWjb
kfyAz7YyFFfoCjy/KzZ5Jn7PMH4fefH5tNZPCr3BHzCrk3rtjQnKgXJuE4gg1uSV
NjOFpQHLc8fphsuXrAXlnmgatJxeYPbsmLCbUQwW/ySZrDH7Ylcde4HwoBwYBHsC
8C5XmGaaWm68698X3RgVPO0vd+L7vQ9ukUPoGqbQLMaNssMgkPP5MdpBUTZFM0Vq
k0figLu/5xWsiXxK+hE+2Ka+rEjIvvSPDJJXSDWiBibcGh4g5Yj7KUAmvXPMPt6/
fhI4Z1L5ZLiij93CpBXPAHI9ZxAxRbhNL8MdIpDRv+7UbZasOHPNXyZoBoPMkAw7
8e5FxuF+qQL/6uCqVwuJLutrPZ9Y/KcyTdWvpV6rtsqIpSbjCDKRoYQxScM062lQ
wOlAwFuQGkKT5mkVl6AVqTy6bmN7BZuIrzh6y+3zBjZZhd5eaTzgNpKtnnUc7sNM
ti/uwutceFIXS1rRXHY4h0CW2iXji9p7vSTYx9VJZI2tJkajw8SDQr0iM3muhM6L
lpzxAZP6dQ6chJo/JA6rS1ChRGmgM5LboQcuMy2uUC1e04NqyEBij37DUAqecCJn
2Mlj899sAZOEM8yQLqCfXxSQTmxorsgMAJpZlhNtI/Qzb7/7Pklj/6Jwg5KNMkml
/iYVbHYMMg==
=Us2Y
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Processing of cdrom-detect_1.98_source.changes

[Debian FTP Masters]

cdrom-detect_1.98_source.changes uploaded successfully to localhost
along with the files:
  cdrom-detect_1.98.dsc
  cdrom-detect_1.98.tar.xz
  cdrom-detect_1.98_source.buildinfo

Greetings,

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

Bug#991587: marked as done (cdrom-detect: ask hw-detect to skip missing firmware detection)

[Debian Bug Tracking System]

Your message dated Wed, 28 Jul 2021 07:33:29 +
with message-id 
and subject line Bug#991587: fixed in cdrom-detect 1.98
has caused the Debian Bug report #991587,
regarding cdrom-detect: ask hw-detect to skip missing firmware detection
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.)


-- 
991587: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991587
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: hw-detect
Version: 1.146
Severity: important
X-Debbugs-Cc: debian...@lists.debian.org

I hadn't seen the following when test-installing in loops, since I was
using a netboot-gtk image, but this can be seen with a regular netinst
image produced by debian-cd, since the d-i image used there is slightly
different. I fear this is going to be a rather common annoyance, so I'd
like to get that fixed before the Bullseye release (either in D-I
Bullseye RC3 or in the final D-I release).


On this Dell G3, right after selecting locale settings, cdrom-detect
kicks in and tries to find the installation image to load. Doing so, it
calls hw-detect with this (two occurrences):

hw-detect cdrom-detect/detect_progress_title || true

which iso-scan can also do (one occurrence):

hw-detect iso-scan/detect_progress_title || true

At the bottom of hw-detect, there's a check-missing-firmware call, which
can trigger errors and prompts about irrelevant firmware files, e.g.:

intel/sof/sof-cml.ri

(which is about sound support, see firmware-sof-signed.)


While I'm not entirely certain about use-cases around iso-scan, I would
think cdrom-detect should be one of the very few first things to happen
on a system, and that raising errors because of missing firmware files
at this stage wouldn't help: even a firmware-enabled image wouldn't be
mounted and firmware packages wouldn't be available (later, they show up
at /cdrom/firmware).

Therefore, I'm proposing:

 1. Implement support for an environment variable in hw-detect, that
would disable the check-missing-firmware call.
 2. Set this variable for both hw-detect calls in cdrom-detect's
postinst. [This should fix the problem I'm seeing.]
 3. Set this variable for the hw-detect call in iso-scan's postinst.
[Optional, I'm not sure what people are doing before iso-scan kicks
in; maybe some firmware-holding block devices could be available at
this stage, so letting the missing firmware detection in place might
make sense in this case.]


For the avoidance of doubt, hw-detect is called in many places, later
for networking devices and for disks; those are much more likely to
require some firmware files to be available…


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
--- End Message ---
--- Begin Message ---
Source: cdrom-detect
Source-Version: 1.98
Done: Cyril Brulebois 

We believe that the bug you reported is fixed in the latest version of
cdrom-detect, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 991...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Cyril Brulebois  (supplier of updated cdrom-detect package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 28 Jul 2021 09:14:55 +0200
Source: cdrom-detect
Architecture: source
Version: 1.98
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Cyril Brulebois 
Closes: 991587
Changes:
 cdrom-detect (1.98) unstable; urgency=medium
 .
   * Set CHECK_MISSING_FIRMWARE=0 when calling hw-detect. Detecting the
 installation image happens very early in the installation process, and
 it's unlikely to require some firmware to access whatever device holds
 it (and in the case of an unofficial firmware-enabled image, firmware
 packages would be inside the ISO, that hasn't been mounted yet). This
 can avoid prompts about missing firmware files for e.g. sound modules
 (like Intel SOF) early in the installation process (Closes: #991587).
Checksums-Sha1:
 666dc6e1cab55459302b0f187af98bfb5c185793 1648 cdrom-detect_1.98.dsc
 

Re: No or wrong modules on netinst prevents install

[Philip Hands]

"Carlos R. Pasqualini"  writes:

> Again, I don't know if this is some kind of bug or issue to be
> resolved, just that I feel that it is not working right, as it is right
> now, and wanted to put it to the team's consideration.

The issue is that the image is tied to the version of the kernel that it
was built with, but the kernel & modules in the archive have
subsequently been updated, so when you try to install the version the
netboot is looking for has been removed.

This is not easy to fix because:

  a) only one version of a package can be present in the archive at a
 time, so the old versions of the modules cannot be left where they
 are for a grace period,

  b) debian-installer (actually the anna & net-retriever udebs) only
 supports downloading from a single repository, so one cannot
 currently configure an additional snapshot repository that could
 provide the matching modules to the netboot.

As it happens I've been using a patched version of d-i that enables
downloading from additional repos while creating test images that can
install unreleased udebs from salsa.debian.org -- those patches probably
need a bit of polishing before they could be part of a release but if
that feature were added then we could create a repo that contains the
matching modules when we create the daily images and configure that as
an additional source in the netboot images to make this problem go away.

I will endeavour to do something about this after the release.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Processed: Bug#991587 marked as pending in cdrom-detect

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #991587 [cdrom-detect] cdrom-detect: ask hw-detect to skip missing firmware 
detection
Added tag(s) pending.

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

Processed: Re: Bug#991587: hw-detect: check-missing-firmware can be a tad aggressive

[Debian Bug Tracking System]

Processing control commands:

> clone -1 -2
Bug #991587 [hw-detect] hw-detect: check-missing-firmware can be a tad 
aggressive
Bug 991587 cloned as bug 991590
> reassign -1 cdrom-detect
Bug #991587 [hw-detect] hw-detect: check-missing-firmware can be a tad 
aggressive
Bug reassigned from package 'hw-detect' to 'cdrom-detect'.
No longer marked as found in versions hw-detect/1.146.
Ignoring request to alter fixed versions of bug #991587 to the same values 
previously set
> retitle -1 cdrom-detect: ask hw-detect to skip missing firmware detection
Bug #991587 [cdrom-detect] hw-detect: check-missing-firmware can be a tad 
aggressive
Changed Bug title to 'cdrom-detect: ask hw-detect to skip missing firmware 
detection' from 'hw-detect: check-missing-firmware can be a tad aggressive'.
> reassign -2 iso-scan
Bug #991590 [hw-detect] hw-detect: check-missing-firmware can be a tad 
aggressive
Bug reassigned from package 'hw-detect' to 'iso-scan'.
No longer marked as found in versions hw-detect/1.146.
Ignoring request to alter fixed versions of bug #991590 to the same values 
previously set
> retitle -2 iso-scan: maybe ask hw-detect to skip missing firmware detection
Bug #991590 [iso-scan] hw-detect: check-missing-firmware can be a tad aggressive
Changed Bug title to 'iso-scan: maybe ask hw-detect to skip missing firmware 
detection' from 'hw-detect: check-missing-firmware can be a tad aggressive'.

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

Bug#991587: hw-detect: check-missing-firmware can be a tad aggressive

[Cyril Brulebois]

Control: clone -1 -2
Control: reassign -1 cdrom-detect
Control: retitle -1 cdrom-detect: ask hw-detect to skip missing firmware 
detection
Control: reassign -2 iso-scan
Control: retitle -2 iso-scan: maybe ask hw-detect to skip missing firmware 
detection

Cyril Brulebois  (2021-07-28):
> While I'm not entirely certain about use-cases around iso-scan, I would
> think cdrom-detect should be one of the very few first things to happen
> on a system, and that raising errors because of missing firmware files
> at this stage wouldn't help: even a firmware-enabled image wouldn't be
> mounted and firmware packages wouldn't be available (later, they show up
> at /cdrom/firmware).
> 
> Therefore, I'm proposing:
> 
>  1. Implement support for an environment variable in hw-detect, that
> would disable the check-missing-firmware call.

Done, but only tested manually (be re-typing the patch live).

>  2. Set this variable for both hw-detect calls in cdrom-detect's
> postinst. [This should fix the problem I'm seeing.]

Done, will be tracked by -1 (same proviso as above).

>  3. Set this variable for the hw-detect call in iso-scan's postinst.
> [Optional, I'm not sure what people are doing before iso-scan kicks
> in; maybe some firmware-holding block devices could be available at
> this stage, so letting the missing firmware detection in place might
> make sense in this case.]

Not done, we'll keep track of it via -2 and see if people hit the issue,
mention their use case, and if we can draw any conclusions as to whether
we should go the same route as with cdrom-detect.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#961056: marked as done (debian-installer: qemu-system-s390x installation fails due to incorrect serial device)

[Debian Bug Tracking System]

Your message dated Wed, 28 Jul 2021 06:03:43 +
with message-id 
and subject line Bug#961056: fixed in linux 5.10.46-3
has caused the Debian Bug report #961056,
regarding debian-installer: qemu-system-s390x installation fails due to 
incorrect serial device
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.)


-- 
961056: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961056
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: debian-installer
Version: 20190702+deb10u4
Severity: important

Dear Maintainer,

Running the installation inside a QEMU instance does not work in buster:

$ virt-install --arch=s390x --name test --memory 1024 --disk none \
  --extra-args=console=ttyS0 \
  -l http://ftp.de.debian.org/debian/dists/buster/main/installer-s390x/
Starting install...
Retrieving file kernel.debian...
  | 3.3 MB  00:00:00
Retrieving file initrd.debian...
  | 9.7 MB  00:00:01
Allocating 'virtinst-kernel.debian.mnba14e7'
  | 3.3 MB  00:00:00
Transferring virtinst-kernel.debian.mnba14e7
  | 3.3 MB  00:00:00
Allocating 'virtinst-initrd.debian.2q88l_1j'
  | 9.7 MB  00:00:00
Transferring virtinst-initrd.debian.2q88l_1j
  | 9.7 MB  00:00:00
Connected to domain test
Escape character is ^]
[1.785649] Linux version 4.19.0-9-s390x (debian-ker...@lists.debian.org) 
(gcc version 8.3.0 (Debian 8.3.0-6)) #1
+SMP Debian 4.19.118-2 (2020-04-29)
[1.786919] setup: Linux is running under KVM in 64-bit mode
[1.788555] setup: The maximum memory size is 1024MB
[1.790050] cpu: 1 configured CPUs, 0 standby CPUs
[1.822704] Write protected kernel read-only data: 8976k
...
[6.148235] mip6: Mobile IPv6
[6.148389] NET: Registered protocol family 17
[6.149302] mpls_gso: MPLS GSO support
[6.151503] registered taskstats version 1
[6.152310] zswap: loaded using pool lzo/zbud
[6.154776] AppArmor: AppArmor sha1 policy hashing enabled
[6.780329] Freeing unused kernel memory: 684K
[6.780784] Write protected read-only-after-init data: 20k
[6.780870] Run /init as init process
steal-ctty: No such file or directory

Than just hangs there because of the problem with the serial port name.
Installer tries to use nonexistent serial device /dev/ttyS1, while the real
name is /dev/ttysclp0. Proposed fix is here:

https://salsa.debian.org/installer-team/rootskel/-/merge_requests/2/diffs

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- End Message ---
--- Begin Message ---
Source: linux
Source-Version: 5.10.46-3
Done: Salvatore Bonaccorso 

We believe that the bug you reported is fixed in the latest version of
linux, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 961...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Salvatore Bonaccorso  (supplier of updated linux package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 28 Jul 2021 07:55:40 +0200
Source: linux
Architecture: source
Version: 5.10.46-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Kernel Team 
Changed-By: Salvatore Bonaccorso 
Closes: 961056 990312 991262
Changes:
 linux (5.10.46-3) unstable; urgency=medium
 .
   * [armhf] Add mdio-aspeed to nic-modules.
 Thanks to Joel Stanley  (Closes: #991262)
   * Revert "drm/amdgpu/gfx9: fix the doorbell missing when in CGPG issue."
 (Closes: #990312)
   * Revert "drm/amdgpu/gfx10: enlarge CP_MEC_DOORBELL_RANGE_UPPER to cover full
 doorbell." (Closes: #990312)
   * Input: joydev - prevent use of not