Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

2023-03-22 Thread Cyril Brulebois
Hi Frédéric,

Frédéric Bonnard  (2023-03-22):
> Another important detail ... I only get that behavior in qemu in
> graphical mode. On LPARs there is no issue. I didn't try on baremetal
> so far.

Could you please guide me into reproducing this issue in QEMU? #987368
had hints, but at least the openpower.xyz part no longer works (it's no
longer resolving).


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


signature.asc
Description: PGP signature


Bug#1032431: marked as done (installation-reports: Bullseye installation on Fujitsu LIFEBOOK U9312)

2023-03-22 Thread Debian Bug Tracking System
Your message dated Wed, 22 Mar 2023 13:34:44 +0100
with message-id <20230322123444.sqjhe4o3falew...@mraw.org>
and subject line Re: Bug#1032431: installation-reports: Bullseye installation 
on Fujitsu LIFEBOOK U9312
has caused the Debian Bug report #1032431,
regarding installation-reports: Bullseye installation on Fujitsu LIFEBOOK U9312
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.)


-- 
1032431: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032431
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: installation-reports
Severity: normal

Boot method: USB
Image version: 
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.6.0+nonfree/amd64/iso-cd/firmware-11.6.0-amd64-netinst.iso
Date: 2023-03-02

Machine: Fujitsu LIFEBOOK U9312
Partitions: 
FilesystemType  1K-blocks  Used  Available Use% Mounted 
on
udev  devtmpfs   16196776 0   16196776   0% /dev
tmpfs tmpfs   3247404  23843245020   1% /run
/dev/mapper/bobo--vg-root ext4 1920358680 374068376 1448667676  21% /
tmpfs tmpfs  16237012183456   16053556   2% /dev/shm
tmpfs tmpfs  5120 8   5112   1% 
/run/lock
/dev/nvme0n1p2ext2 481642171481 285176  38% /boot
/dev/nvme0n1p1vfat 523248  5928 517320   2% 
/boot/efi
tmpfs tmpfs   3247400   1283247272   1% 
/run/user/1000


Model: SAMSUNG MZVL22T0HBLB-00B07 (nvme)
Disk /dev/nvme0n1: 2048GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End SizeFile system  Name  Flags
 1  1049kB  538MB   537MB   fat32  boot, esp
 2  538MB   1050MB  512MB   ext2
 3  1050MB  2048GB  2047GB


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O*]
Configure network:  [O]
Detect media:   [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Using a netboot install image with non-free firmware; the wireless card
was not detected during the installation so I used the wired network
adapter instead.

The touchpad was not working, but an external mouse could be used.
This later turned out to be a minor issue but a cost me the most time.
Loading the i2c_hid_acpi module got it going.

Since this was a fairly new laptop I expected some things not to work (yet).
The missing firmware files reported by the kernel could be downloaded from
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
which was sufficient to get the wireless card and bluetooth to work.

I always expected to run the system in a mixed stable/testing setup
because I wanted to install pipewire/wireplumber which seems to work
better with Debian 12. I ended up switching almost entirely to testing.

The sound card required the latest firmware from the SOF project. To get
the digital microphone working a different topology file was needed as
outlined on this page:

https://thesofproject.github.io/latest/getting_started/intel_debug/suggestions.html#digital-mic-issues

And this bug report:

https://github.com/thesofproject/linux/issues/4099


The system seems to do great otherwise, as it is my daily workhorse to
replace an earlier Fujitsu model (LIFEBOOK U937). The only non-functioning
element is the Fujitsu PalmSecure biometric sensor.

Also see the hardware report

https://linux-hardware.org/?probe=19a72f502b



-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210731+deb11u7+b1"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux bobo 5.10.0-20-amd64 #1 SMP Debian 5.10.158-2 (2022-12-13) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4601] 
(rev 04)
lspci -knn: Subsystem: Fujitsu Client Computing Limited Device [1e26:0087]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel 

Bug#1032431: installation-reports: Bullseye installation on Fujitsu LIFEBOOK U9312

2023-03-22 Thread Dennis van Dok

On 21-03-2023 17:39, Cyril Brulebois wrote:

Cyril Brulebois  (2023-03-08):

I should be able to share a small(-ish) ISO for you to test, so that
you can check whether touchpad support becomes available. Same story
as before: that'd be just about booting the installer, reaching the
language selection screen, and letting us know whether the touchpad's
working.


Test ISO (without any firmware, just a fresh minimal installer build)
available here for you to check whether that helps the touchpad become
alive:
   https://people.debian.org/~kibi/bug-1032136/


Tested and the touchpad is now functional. The pointer moves as 
expected. Tapping on the pad does not translate to mouse clicks, but the 
touchpad buttons work correctly.


Tap-to-click is a feature of the driver that I find annoying and 
normally leave off, but I'm not sure that should be the default for the 
installer. I have no real opinion on that, I just thought it was worth 
mentioning that it behaves that way.




Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

2023-03-22 Thread Frédéric Bonnard
Thanks Cyril.
Another important detail ... I only get that behavior in qemu in
graphical mode.
On LPARs there is no issue. I didn't try on baremetal so far.

F.

On Tue, 21 Mar 2023 17:44:49 +0100 Cyril Brulebois  wrote:
> Frédéric Bonnard  (2023-03-17):
> > > It would be helpful to confirm which exact kernel version is getting
> > > used in both cases (last 6.1.0-4 working, and first 6.1.0-5 not
> > > working), then look at the changes between both versions, in src:linux
> > > (and resulting udebs).
> > 
> > From linux changelog (
> > https://tracker.debian.org/media/packages/l/linux/changelog-6.1.15-1 )
> > and http://snapshot.debian.org/package/linux/,
> > I see :
> > 6.1.11-1 -> Bump ABI to 4 
> > http://snapshot.debian.org/archive/debian/20230211T151657Z/
> > 6.1.12-1 -> Bump ABI to 5 
> > http://snapshot.debian.org/archive/debian/20230217T033139Z/
> > 
> > and tested from those (rebuilding the same d-i source with the 2 kernels
> > from snapshot.d.o . 6.1.12-1 clearly doesn't work.
> > I had already have a look at the kernel changelog but missed that one :
> > ---
> > linux (6.1.12-1) unstable; urgency=medium
> > ...
> > - of: Make OF framebuffer device names unique
> > ...
> > ---
> > 
> > I recompiled the kernel deb source without that one (
> > https://github.com/torvalds/linux/commit/241d2fb56a18473af5f2ff0d512992a996eb64dd.patch
> > ) and the mini.iso actually made it to the menu... and given the
> > behaviour, a framebuffer actually makes sense.
> > 
> > Now, that patch does not harm when the kernel is installed on disk.
> > But it does in the installer...
> 
> Adding the kernel team to the loop: d-i regression on ppc64el.
> 
> 
> Cheers,
> -- 
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#1032431: installation-reports: Bullseye installation on Fujitsu LIFEBOOK U9312

2023-03-22 Thread Cyril Brulebois
Dennis van Dok  (2023-03-22):
> Tested and the touchpad is now functional. The pointer moves as
> expected. Tapping on the pad does not translate to mouse clicks, but
> the touchpad buttons work correctly.
> 
> Tap-to-click is a feature of the driver that I find annoying and
> normally leave off, but I'm not sure that should be the default for
> the installer. I have no real opinion on that, I just thought it was
> worth mentioning that it behaves that way.

Many thanks for confirming.

The installer will use whatever is implemented by the X driver, and I don't
anticipate us diverting from the default settings, unless absolutely needed.


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


signature.asc
Description: PGP signature


Bug#1033035: hw-detect: trivial patches

2023-03-22 Thread Cyril Brulebois
Pascal Hambourg  (2023-03-17):
> On 16/03/2023 at 21:09, Cyril Brulebois wrote:
> > OK, this might be fixing an actual issue.
> 
> Attached patches v2 with more descriptions and which apply without the
> other rejected patches. Thank you for all the useful comments.

Thanks, merged. Feel free to tweak the changelog entry as you see fit.

The /target/tmp thing was self-fixing so never noticed… but the Package
thing I would have noticed/fixed while working on the firmware summary
thing (which is what I'm about to do, and reminded me I had stuff to
merge…).


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


signature.asc
Description: PGP signature


Bug#1031643: preseeding hostname=foo via the kernel command line seems to be ignored

2023-03-22 Thread Salvatore Bonaccorso
Hi,

On Sun, Feb 19, 2023 at 07:39:02PM +0100, Cyril Brulebois wrote:
> Package: preseed
> Version: 1.113
> Severity: normal
> X-Debbugs-Cc: Salvatore Bonaccorso 
> 
> Filing this against preseed for visibility, after Salvatore Bonaccorso
> reported that D-I Bookworm Alpha 1 was dealing with preseeding
> hostname=foo just fine, and that it's no longer the case with D-I
> Bookworm Alpha 2: the hostname question is asked, with either the
> default value (“debian”) or a value determined from the DHCP hostname
> (if any).
> 
> The relevant code didn't change on the installer side, but Linux
> mainline got a relevant commit: 5a704629f2 (first released in v6.0-rc1):
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5a704629f2c1ba33bbb444cb18e6957e97c76e8f
> 
> At first glance, a side effect is that the kernel seems to “eat” the
> hostname=foo parameter instead of leaving it alone as it did in earlier
> versions, possibly hiding it from the installer:
> 
>   -Unknown kernel command line parameters "--- 
> BOOT_IMAGE=/install.amd/vmlinuz vga=788 hostname=miaou", will be passed to 
> userspace
>   +Unknown kernel command line parameters "--- 
> BOOT_IMAGE=/install.amd/vmlinuz vga=788", will be passed to userspace
> 
> 
> Now, parameters might be added before or after the '---' marker, and
> moving hostname=foo from after to before this marker makes this issue go
> away.
> 
> Checking the story behind that marker, i.e. debian-installer-utils
> version 1.109 first published in jessie to fix #762007, I'm not sure
> what to think about it… A cursory look at it suggests parameters found
> after that marker should be visible to both the installer and the
> kernel, but that's not the case here.
> 
> Looking at the user-space side, I'm still seeing “hostname=foo” at the
> end of /proc/cmdline, but calling user-params only returns “quiet”, and
> that's the case for both D-I Bookworm Alpha 1 and Alpha 2. Both images
> have the same /etc/preseed_aliases, which dictates what user-params
> does.
> 
> 
> Adding DEBCONF_DEBUG=developer on the kernel command line, searching for
> lines with “cdebconf” and “hostname”, the big difference is that line,
> only in Alpha 1:
> 
>   debconf: Adding [ID] -> [netcfg/get_hostname]
> 
> It happens early in the boot process (at start-up), and that comes from
> debconf's question_variable_add() function. Right after that, there's an
> extra “frontend” line (not “cdebconf” this time) marking that question
> as seen, which means the hostname prompt is skipped down the line.
> 
> Why the difference? The actual consequence of the Linux change is not in
> /proc/cmdline or user-params or preseed, it's just just about early
> start-up: /init is run without hostname=foo in its environment, which
> explains why the debconf preseeding is no longer happening.
> 
> 
> I'm not sure where to go from here though. Compensate for this change by
> adding a special case for this parameter in env2debconf? The existing
> code seems unfriendly enough as it is… maybe implement /proc/cmdline
> lookup from netcfg instead? Not doing anything? All three options seem
> suboptimal to me…

First, this was a real use case which triggered noticing the issue
with the D-I Bookworm Alpha 1 while doing some pre-testing. 

But if there is no reasy technical way to continue having the
hostname alias support for preseed, would a pracmatic solution be to
drop support for the hostname= alias, cleanup as well the
documentation on it, and have people use the longer
netcfg/get_hostname instead?

Regards,
Salvatore



Bug#1029849: hw-detect: storing firmware information specifically

2023-03-22 Thread Cyril Brulebois
Control: clone -1 -2
Control: reassign -2 installation-report
Control: retitle -2 installation-report: store and report firmware information

Cyril Brulebois  (2023-01-28):
> hw-detect already has some finish-install hooks, so it would only need
> to generate something like /var/log/installer/firmware-packages from
> it, with “$package $component” on each line?
> 
> And maybe “# no firmware packages” (with a leading # to signal a
> comment), so that people can easily iterate over it if they so wish?

Trying to balance informative header, appearance, and machine-readability
I'm about to implement something like this when some packages are found:

#Package Component Reason  
firmware-linux-nonfree   non-free-firmware modalias
firmware-realtek non-free-firmware dmesg   

(I was about to use column -t, but that's bsdextrautils, so I'm using a
format string with printf, allowing 30-character worth of package name.)

and otherwise:

# No firmware/microcode packages deployed by the installer

which means people can grep -v ^# to get to the actual data (if any) and
do stuff with it, while humans have a decent-ish table.

I'm also adding the firmware summary file to the installation report via
the bug script.

I'll test this shortly with patched hw-detect and installation-report on
a netinst ISO, on baremetal then report actual results, instead of the
mockup above.

> I don't think that's a blocker for the next d-i release, that might be
> considered a blocker for Bookworm though; debian-release@ in Cc can
> comment and raise severity if that's desired.

Cc dropped since we're implementing this right now.


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


signature.asc
Description: PGP signature


Processed: Re: Bug#1029849: hw-detect: storing firmware information specifically

2023-03-22 Thread Debian Bug Tracking System
Processing control commands:

> clone -1 -2
Bug #1029849 [hw-detect] hw-detect: storing firmware information specifically
Bug 1029849 cloned as bug 1033325
> reassign -2 installation-report
Bug #1033325 [hw-detect] hw-detect: storing firmware information specifically
Bug reassigned from package 'hw-detect' to 'installation-report'.
Ignoring request to alter found versions of bug #1033325 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1033325 to the same values 
previously set
> retitle -2 installation-report: store and report firmware information
Bug #1033325 [installation-report] hw-detect: storing firmware information 
specifically
Changed Bug title to 'installation-report: store and report firmware 
information' from 'hw-detect: storing firmware information specifically'.

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



Bug#1033325: Bug#1029849: hw-detect: storing firmware information specifically

2023-03-22 Thread Cyril Brulebois
Cyril Brulebois  (2023-03-22):
> Trying to balance informative header, appearance, and machine-readability
> I'm about to implement something like this when some packages are found:
> 
> #Package Component Reason  
> firmware-linux-nonfree   non-free-firmware modalias
> firmware-realtek non-free-firmware dmesg   
> 
> (I was about to use column -t, but that's bsdextrautils, so I'm using a
> format string with printf, allowing 30-character worth of package name.)
> 
> and otherwise:
> 
> # No firmware/microcode packages deployed by the installer
> 
> which means people can grep -v ^# to get to the actual data (if any) and
> do stuff with it, while humans have a decent-ish table.
> 
> I'm also adding the firmware summary file to the installation report via
> the bug script.
> 
> I'll test this shortly with patched hw-detect and installation-report on
> a netinst ISO, on baremetal then report actual results, instead of the
> mockup above.

Test VM with Realtek Wi-Fi USB adapter shared from the host:

#Package Component   Reason
firmware-realtek non-free-firmware   dmesg
firmware-realtek non-free-firmware   modalias
intel-microcode  non-free-firmware   cpu

Asus Vivobook:

#Package Component   Reason
firmware-realtek non-free-firmware   dmesg
firmware-amd-graphicsnon-free-firmware   modalias
amd64-microcode  non-free-firmware   cpu

Dell G3 15:

#Package Component   Reason
firmware-iwlwifi non-free-firmware   dmesg
firmware-realtek non-free-firmware   dmesg
firmware-iwlwifi non-free-firmware   modalias
firmware-misc-nonfreenon-free-firmware   modalias
firmware-realtek non-free-firmware   modalias
firmware-sof-signed  non-free-firmware   modalias
intel-microcode  non-free-firmware   cpu

I'm deliberately choosing not to duplicate package names.

The only thing I cannot really easily test is the “no firmware or
microcode packages case” since the CPU matching will pull microcode at
the very least:
  
https://salsa.debian.org/installer-team/installation-report/-/commit/2b46263446e838f3965239aa14ed65a64aea49c2#9cef33ed9dfd3270ca2973284679af40ac3e0fe0_22_32


In any case, that file is now included in installation reports, near the
end, and that looks like this:

==
Installer firmware-summary:
==
#Package Component   Reason
firmware-realtek non-free-firmware   dmesg
firmware-realtek non-free-firmware   modalias
intel-microcode  non-free-firmware   cpu


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


signature.asc
Description: PGP signature


Bug#1031631: marked as done (hw-detect: insufficient firmware files deduplication)

2023-03-22 Thread Debian Bug Tracking System
Your message dated Wed, 22 Mar 2023 19:49:21 +
with message-id 
and subject line Bug#1031631: fixed in hw-detect 1.155
has caused the Debian Bug report #1031631,
regarding hw-detect: insufficient firmware files deduplication
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.)


-- 
1031631: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031631
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: hw-detect
Severity: normal

Seen by Andrew M.A. Cater while testing the first batch of installation
images yesterday, which were missing the “symlink fix”[1]:

The missing firmware files are rtlwifi/rt8723bs_nic.bin 
rtlwifi/rt8723bs_nic.bin

This should have been deduplicated.

 1. 
https://salsa.debian.org/images-team/debian-cd/-/commit/aebf4f0556280fbb9358ad63b86a930932b014a4


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
--- End Message ---
--- Begin Message ---
Source: hw-detect
Source-Version: 1.155
Done: Cyril Brulebois 

We believe that the bug you reported is fixed in the latest version of
hw-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 1031...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Cyril Brulebois  (supplier of updated hw-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, 22 Mar 2023 20:31:11 +0100
Source: hw-detect
Architecture: source
Version: 1.155
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Cyril Brulebois 
Closes: 1029804 1029849 1031631 1033035
Changes:
 hw-detect (1.155) unstable; urgency=medium
 .
   [ Cyril Brulebois ]
   * Deduplicate the list of requested firmware files, not just the list of
 requesting modules (Closes: #1031631).
   * Implement microcode support when /proc/cpuinfo contains a vendor_id
 field, with one of the following values (Closes: #1029804):
  - Install amd64-microcode on AuthenticAMD.
  - Install intel-microcode on GenuineIntel.
  - Enable non-free-firmware accordingly.
  - Perform installation via finish-install, making sure apt-setup has
been configured, and using apt-install for dependency resolution.
   * Optimize firmware package installation: process dpkg triggers once,
 after all packages have been installed (i.e. install-firmware only
 triggers a single update-initramfs call).
   * Fix condition around moutmedia calls (See: #1032377).
   * Fix files removal for non-accepted firmware packages (See: #1032377).
   * Add a special case for the mhi module: when the module requesting
 firmware files is “mhi”, use the modules listed as holders (e.g.
 ath11k_pci and qrtr_mhi). This is less precise than the usb special
 case, since /sys/bus/mhi/devices/ gives no hints as to which
 network module would be involved (See: #1032140). Thanks to Nicolas
 Dandrimont and Benoît Chauvet for the tests.
   * Adjust dmesg timestamp management: only update the timestamp file if
 there are new lines.
   * Fix package name extraction when removing a firmware package (e.g.
 it failed to install because it was corrupted). Regression in 1.153,
 spotted in #1032970.
   * Build /var/log/firmware-summary as a 3-column summary of firmware (and
 microcode) packages getting installed (Closes: #1029849). Those three
 columns are: package, component, and reason. The reason might be dmesg
 (check-missing-firmware), modalias (install-firmware hook), or cpu
 (install-firmware hook).
 .
   [ Pascal Hambourg ]
   * Fix several glitches (Closes: #1033035):
  - Fix removal of temporary files in /target after installing firmware
packages (they're in /tmp so the next reboot has been doing the
trick until now).
  - Determine the package name by using the Package field instead of
trusting the filename when installing firmware packages.
  - Make sure not to include the possible -n option when setting the
IFACES variables in check-missing-firmware.
Checksums-Sha1:
 eaa42a8ae1ad674a6d18dd2992fa20b70ecfd296 1990 hw-detect_1.155.dsc
 

Bug#1033325: marked as done (installation-report: store and report firmware information)

2023-03-22 Thread Debian Bug Tracking System
Your message dated Wed, 22 Mar 2023 19:49:28 +
with message-id 
and subject line Bug#1033325: fixed in installation-report 2.87
has caused the Debian Bug report #1033325,
regarding installation-report: store and report firmware information
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.)


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

Hi,

Quoting the text that was agreed to via the 2022 General Resolution
about non-free firmware:

When the installer/live system is running we will provide
information to the user about what firmware has been loaded (both
free and non-free), and we will also store that information on the
target system such that users will be able to find it later. 

During the initial brainstorming, I think it was suggested to maybe
include some kind of informational message at the end of the
installation process, like “we installed this and that” or “yay,
you're entirely free”.

That would mean extra work on the translation side, wouldn't add much
value, so that looks like something we should *not* implement.


Regarding the letter of the text, and given hw-detect's code, it's
probably easy enough to keep a file around during the installation
process, with both package name and the component it was found in.

hw-detect already has some finish-install hooks, so it would only need
to generate something like /var/log/installer/firmware-packages from
it, with “$package $component” on each line?

And maybe “# no firmware packages” (with a leading # to signal a
comment), so that people can easily iterate over it if they so wish?


I don't think that's a blocker for the next d-i release, that might be
considered a blocker for Bookworm though; debian-release@ in Cc can
comment and raise severity if that's desired.

If one wanted not to work on this at all, one could make the case that
/var/log/installer/syslog can be used to determine whether/which
firmware packages were installed; the presence of non-free-firmware in
sources.list would be another indication. (That's why I don't think
that's a short-term blocker at all.) But building a 2-column table out
of existing information shouldn't be much work anyway…


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

We believe that the bug you reported is fixed in the latest version of
installation-report, 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 1033...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Cyril Brulebois  (supplier of updated installation-report 
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, 22 Mar 2023 20:28:35 +0100
Source: installation-report
Architecture: source
Version: 2.87
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Cyril Brulebois 
Closes: 1033325
Changes:
 installation-report (2.87) unstable; urgency=medium
 .
   * Store firmware information in /var/log/installer/firmware-summary
 (Closes: #1033325):
  - Either /var/log/firmware-summary was created by the various
hw-detect scripts, and it was copied over already; in which case,
prettify it a little (adding a descriptive header, and aligning
columns).
  - Or there was no need for firmware at all and there's no such file;
in which case, create it with a single line stating that no
firmware or microcode packages were deployed by the installer.
  - In both cases, developers wishing to process its contents can just
drop lines starting with the '#' character and iterate on the other
ones (if any).
   * Include firmware-summary in installation reports.
Checksums-Sha1:
 b8c6f39bbd2350760eab83b431fd34b8f4ab4e6f 1746 installation-report_2.87.dsc
 

Bug#1033035: marked as done (hw-detect: trivial patches)

2023-03-22 Thread Debian Bug Tracking System
Your message dated Wed, 22 Mar 2023 19:49:21 +
with message-id 
and subject line Bug#1033035: fixed in hw-detect 1.155
has caused the Debian Bug report #1033035,
regarding hw-detect: trivial patches
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.)


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

Package: src:hw-detect
Version: 1.155
Tags: patch

Dear maintainer,
Please consider merging the attached patches.

- hw-detect.pre-pkgsel.d/50install-firmware: fix path of deleted file

- check-missing-firmware.sh: shift positional parameters after reading
   -n

- check-missing-firmware.sh: define local variables in functions

- check-missing-firmware.sh: get package name from control instead of
   file name

- check-missing-firmware.sh: replace spaces with tabs in indentationFrom e9a8ceeaa83fbf43e33cdd3745bbbf5d64c3291c Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Mon, 13 Mar 2023 14:57:52 +0100
Subject: [PATCH 1/5] hw-detect.pre-pkgsel.d/50install-firmware: fix path of
 deleted file

---
 hw-detect.pre-pkgsel.d/50install-firmware | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw-detect.pre-pkgsel.d/50install-firmware b/hw-detect.pre-pkgsel.d/50install-firmware
index 61d23b41..15c145e8 100644
--- a/hw-detect.pre-pkgsel.d/50install-firmware
+++ b/hw-detect.pre-pkgsel.d/50install-firmware
@@ -18,7 +18,7 @@ if [ -d /var/cache/firmware ]; then
 			else
 n=$((n+1))
 			fi
-			rm -f "/target/tmp/$deb"
+			rm -f "/target/tmp/$(basename "$deb")"
 		fi
 	done
 	if [ $n -gt 0 ]; then
-- 
2.30.2

From 69a30ad764bb3760feae7cf5a7f19dcc34ac886a Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Wed, 8 Mar 2023 19:38:04 +0100
Subject: [PATCH 2/5] check-missing-firmware.sh: shift positional parameters
 after reading -n

---
 check-missing-firmware.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh
index cfb85fb1..44054818 100755
--- a/check-missing-firmware.sh
+++ b/check-missing-firmware.sh
@@ -6,6 +6,7 @@ DENIED=/tmp/missing-firmware-denied
 
 if [ "x$1" = "x-n" ]; then
 	NONINTERACTIVE=1
+	shift
 else
 	NONINTERACTIVE=""
 fi
-- 
2.30.2

From ce221a36cbdae932453fbcc6b037fe4d634e1dce Mon Sep 17 00:00:00 2001
From: Pascal Hambourg 
Date: Wed, 8 Mar 2023 19:35:49 +0100
Subject: [PATCH 3/5] check-missing-firmware.sh: define local variables in
 functions

---
 check-missing-firmware.sh | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh
index 44054818..0557f7d1 100755
--- a/check-missing-firmware.sh
+++ b/check-missing-firmware.sh
@@ -23,8 +23,9 @@ log_output() {
 
 # USB is special, and we don't want to take it all done:
 get_usb_module() {
-	address="$1"
-	device="/sys/bus/usb/devices/$address"
+	local address="$1"
+	local device="/sys/bus/usb/devices/$address"
+	local subdirs driver
 
 	# Make sure there's a single subdirectory (e.g. 4-1.5:1.0 below 4-1.5):
 	subdirs=$(find -L "$device" -maxdepth 1 -type d -name "$address:*")
@@ -52,7 +53,7 @@ get_usb_module() {
 # The mhi module's holders directory lists ath11k_pci and qrtr_mhi
 # though!
 get_mhi_holders() {
-	holders=$(find -L /sys/module/mhi/holders/ -mindepth 1 -maxdepth 1 -exec basename {} ';')
+	local holders=$(find -L /sys/module/mhi/holders/ -mindepth 1 -maxdepth 1 -exec basename {} ';')
 	if [ "$holders" = "" ]; then
 		log "failed to perform mhi lookup (no holders found)"
 		log "=> sticking with the mhi module"
@@ -66,6 +67,8 @@ get_mhi_holders() {
 # then down any interfaces specified by ethdetect. Don't touch interfaces
 # that users might have configured (manually or via preseeding) though!
 upnics() {
+	local iface sys_iface
+
 	for iface in $IFACES; do
 		# Don't rely on ip's output, it lacks at least state UP/DOWN:
 		sys_iface="/sys/class/net/$iface"
@@ -88,7 +91,8 @@ upnics() {
 # is up and has an IP address. Such modules should not be reloaded,
 # to avoid taking down the network after it's been configured.
 nic_is_configured() {
-	module="$1"
+	local module="$1"
+	local iface dir
 
 	for iface in $(ip -o link show up | cut -d : -f 2); do
 		dir="/sys/class/net/$iface/device/driver"
@@ -103,8 +107,9 @@ nic_is_configured() {
 }
 
 get_fresh_dmesg() {
-	dmesg_file=/tmp/dmesg.txt
-	dmesg_ts=/tmp/dmesg-ts.txt
+	local dmesg_file=/tmp/dmesg.txt
+	local dmesg_ts=/tmp/dmesg-ts.txt
+	local tspattern ln
 
 	# Get current dmesg:
 	dmesg > $dmesg_file
@@ -143,6 +148,8 @@ 

Processed: Bug#1033325 marked as pending in installation-report

2023-03-22 Thread Debian Bug Tracking System
Processing control commands:

> tag -1 pending
Bug #1033325 [installation-report] installation-report: store and report 
firmware information
Added tag(s) pending.

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



Bug#1029804: marked as done (hw-detect: decide whether to automatically install amd64-microcode/intel-microcode)

2023-03-22 Thread Debian Bug Tracking System
Your message dated Wed, 22 Mar 2023 19:49:21 +
with message-id 
and subject line Bug#1029804: fixed in hw-detect 1.155
has caused the Debian Bug report #1029804,
regarding hw-detect: decide whether to automatically install 
amd64-microcode/intel-microcode
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.)


-- 
1029804: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029804
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: hw-detect
Severity: important
X-Debbugs-Cc: amd64-microc...@packages.debian.org, 
intel-microc...@packages.debian.org

Hi,

Both of those *-microcode packages are featured in my initial list of
firmware packages that I found interesting to move from non-free to
non-free-firmware:
  https://lists.debian.org/debian-boot/2023/01/msg00150.html

Henrique (in X-D-Cc) is fine with the proposed move, even if that hasn't
happened yet (and I won't consider this a blocker for the upcoming D-I
release):
  https://salsa.debian.org/hmh/amd64-microcode/-/merge_requests/3
  https://salsa.debian.org/hmh/intel-microcode/-/merge_requests/2

That being said, contrary to other firmware packages:
 - we are not going to see log lines in dmesg to tell us that firmware
   loading failed, so we won't try and find firmware packages shipping
   those missing files (via check-missing-firmware);
 - they don't ship appstream metadata which would give us hints about
   hardware that could benefit from firmware packages, even without
   log lines in dmesg (via 50install-firmware, post-base-installer).

We could probably implement specific detection in hw-detect to install
those packages anyway (alternatively, maybe discover but nothing's been
happening there for a while anyway). Should we?

Various topics if we wanted to implement that:
 - Those are not needed during the installation, so installing them
   as soon as possible is not required, contrary to regular firmware
   packages; queueing their installation would be sufficient, along
   with enabling non-free-firmware (apt-setup/non-free-firmware).
 - Those have dependencies, so dpkg -i wouldn't fly and something like
   `in-target apt-get` should be used instead):
 https://salsa.debian.org/installer-team/hw-detect/-/commit/c876e43039
 - intel-microcode requires iucode-tool, currently in contrib, but
   Henrique is fine with moving it to main:
 https://salsa.debian.org/hmh/intel-microcode/-/merge_requests/2
 - What would be the best way to perform detection?

That, along with the move of those 3 packages between sections, is not
something I consider a blocker for the upcoming D-I release, or even for
the first Bookworm release. Just something that seems nice to have, if
we want to.


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

We believe that the bug you reported is fixed in the latest version of
hw-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 1029...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Cyril Brulebois  (supplier of updated hw-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, 22 Mar 2023 20:31:11 +0100
Source: hw-detect
Architecture: source
Version: 1.155
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Cyril Brulebois 
Closes: 1029804 1029849 1031631 1033035
Changes:
 hw-detect (1.155) unstable; urgency=medium
 .
   [ Cyril Brulebois ]
   * Deduplicate the list of requested firmware files, not just the list of
 requesting modules (Closes: #1031631).
   * Implement microcode support when /proc/cpuinfo contains a vendor_id
 field, with one of the following values (Closes: #1029804):
  - Install amd64-microcode on AuthenticAMD.
  - Install intel-microcode on GenuineIntel.
  - Enable non-free-firmware accordingly.
  - Perform installation via finish-install, making sure apt-setup has
been configured, and using apt-install for 

Bug#1029849: marked as done (hw-detect: storing firmware information specifically)

2023-03-22 Thread Debian Bug Tracking System
Your message dated Wed, 22 Mar 2023 19:49:21 +
with message-id 
and subject line Bug#1029849: fixed in hw-detect 1.155
has caused the Debian Bug report #1029849,
regarding hw-detect: storing firmware information specifically
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.)


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

Hi,

Quoting the text that was agreed to via the 2022 General Resolution
about non-free firmware:

When the installer/live system is running we will provide
information to the user about what firmware has been loaded (both
free and non-free), and we will also store that information on the
target system such that users will be able to find it later. 

During the initial brainstorming, I think it was suggested to maybe
include some kind of informational message at the end of the
installation process, like “we installed this and that” or “yay,
you're entirely free”.

That would mean extra work on the translation side, wouldn't add much
value, so that looks like something we should *not* implement.


Regarding the letter of the text, and given hw-detect's code, it's
probably easy enough to keep a file around during the installation
process, with both package name and the component it was found in.

hw-detect already has some finish-install hooks, so it would only need
to generate something like /var/log/installer/firmware-packages from
it, with “$package $component” on each line?

And maybe “# no firmware packages” (with a leading # to signal a
comment), so that people can easily iterate over it if they so wish?


I don't think that's a blocker for the next d-i release, that might be
considered a blocker for Bookworm though; debian-release@ in Cc can
comment and raise severity if that's desired.

If one wanted not to work on this at all, one could make the case that
/var/log/installer/syslog can be used to determine whether/which
firmware packages were installed; the presence of non-free-firmware in
sources.list would be another indication. (That's why I don't think
that's a short-term blocker at all.) But building a 2-column table out
of existing information shouldn't be much work anyway…


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

We believe that the bug you reported is fixed in the latest version of
hw-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 1029...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Cyril Brulebois  (supplier of updated hw-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, 22 Mar 2023 20:31:11 +0100
Source: hw-detect
Architecture: source
Version: 1.155
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Cyril Brulebois 
Closes: 1029804 1029849 1031631 1033035
Changes:
 hw-detect (1.155) unstable; urgency=medium
 .
   [ Cyril Brulebois ]
   * Deduplicate the list of requested firmware files, not just the list of
 requesting modules (Closes: #1031631).
   * Implement microcode support when /proc/cpuinfo contains a vendor_id
 field, with one of the following values (Closes: #1029804):
  - Install amd64-microcode on AuthenticAMD.
  - Install intel-microcode on GenuineIntel.
  - Enable non-free-firmware accordingly.
  - Perform installation via finish-install, making sure apt-setup has
been configured, and using apt-install for dependency resolution.
   * Optimize firmware package installation: process dpkg triggers once,
 after all packages have been installed (i.e. install-firmware only
 triggers a single update-initramfs call).
   * Fix condition around moutmedia calls (See: #1032377).
   * Fix files removal for non-accepted firmware packages (See: #1032377).
   * Add a special case for 

Processing of hw-detect_1.155_source.changes

2023-03-22 Thread Debian FTP Masters
hw-detect_1.155_source.changes uploaded successfully to localhost
along with the files:
  hw-detect_1.155.dsc
  hw-detect_1.155.tar.xz
  hw-detect_1.155_source.buildinfo

Greetings,

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



Processing of installation-report_2.87_source.changes

2023-03-22 Thread Debian FTP Masters
installation-report_2.87_source.changes uploaded successfully to localhost
along with the files:
  installation-report_2.87.dsc
  installation-report_2.87.tar.xz
  installation-report_2.87_source.buildinfo

Greetings,

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



installation-report_2.87_source.changes ACCEPTED into unstable

2023-03-22 Thread Debian FTP Masters
Thank you for your contribution to Debian.



Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 22 Mar 2023 20:28:35 +0100
Source: installation-report
Architecture: source
Version: 2.87
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Cyril Brulebois 
Closes: 1033325
Changes:
 installation-report (2.87) unstable; urgency=medium
 .
   * Store firmware information in /var/log/installer/firmware-summary
 (Closes: #1033325):
  - Either /var/log/firmware-summary was created by the various
hw-detect scripts, and it was copied over already; in which case,
prettify it a little (adding a descriptive header, and aligning
columns).
  - Or there was no need for firmware at all and there's no such file;
in which case, create it with a single line stating that no
firmware or microcode packages were deployed by the installer.
  - In both cases, developers wishing to process its contents can just
drop lines starting with the '#' character and iterate on the other
ones (if any).
   * Include firmware-summary in installation reports.
Checksums-Sha1:
 b8c6f39bbd2350760eab83b431fd34b8f4ab4e6f 1746 installation-report_2.87.dsc
 776cf839456eb9daec30a6d5973692d1c17f2cd7 92436 installation-report_2.87.tar.xz
 54ac918410f1aaf764f58c08ee6f7e1e6aaca738 6451 
installation-report_2.87_source.buildinfo
Checksums-Sha256:
 89e0fb264dcfb88d36aa0c4bdaed0b99a43fe3c31fb0c63dbc5dc44370bffb22 1746 
installation-report_2.87.dsc
 227ffdbc130585f0620e76c472961dc35dad85c94f07f6f079bf8015e1214164 92436 
installation-report_2.87.tar.xz
 0c4956f54f4019f34610e2becd5285fe453764cf2f68c931a78e3937ccee18ae 6451 
installation-report_2.87_source.buildinfo
Files:
 da082aadeabedc5e1e5c9faddf5064f5 1746 debian-installer optional 
installation-report_2.87.dsc
 26f6ba8a0d572a79e33b366dd7842a3b 92436 debian-installer optional 
installation-report_2.87.tar.xz
 2b7ac0a65badd8fea4507d9abfa99d63 6451 debian-installer optional 
installation-report_2.87_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmQbVwwQHGtpYmlAZGVi
aWFuLm9yZwAKCRD/kUrwwrNVIA6xEACGt1BKMhU5M0RDPLlQLMxDabBcWLgXqE9X
fvxn2GCgNgf8ZM8sZASzFyWFJc0BPWPa3O/jHRD/5MqbwHltAgQDBe8vme9LKCT1
n4O7nAUV3cD/Qs2qUkOgVumleTOgOy4XYa4aVCkbqZKKtnehJRGvIicoctTV7OUR
0rSttdb6heCivuMmswxzQWTFizZTvUqWrtr8bYb+Kl1TpU1XIWBqtmeBBzLblOXB
ZKgKNVJMSIjXQo82DCymIEX818mzF6glj3cG/6Tb8y0sPtQw37Fn1N6UbJgRvAIK
tLc0FJ21v9S0nmOoj3Ty26x6l86cirb0dm6F2rgbWwVn934vmIZ5dX0NccStaodO
SAD5CEy2IRKAALM9VaDqR6g/+Brxk8ZcgN9YCbkhiFlQoWB4Nrrr55s4tUNoZyR4
g1UbKQCqidi9FJoKfHeJTmcqSlvqpi9RbTfUqA0WmwqT0cbBDWaTuayX83KeHYll
I4EE4U2GOzxELIjkKH/vU6lGrEnGtadeSL0dmW1r46/OR8n5tGhB+oDAUmJ8HY4O
MaDM87PI6XZiheqQllw7kQmTWf9sYV0MhVb3VRdAeas4ySHGz1A9EEhlXiqYCOz7
oZSvmAtK4C0EPvrgouFdbFyKPd5bFUl4e9gdS5r7hP6dFfVIeIavy895ZPAq8Q/L
HESb7frNYg==
=4rIR
-END PGP SIGNATURE-



hw-detect_1.155_source.changes ACCEPTED into unstable

2023-03-22 Thread Debian FTP Masters
Thank you for your contribution to Debian.



Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 22 Mar 2023 20:31:11 +0100
Source: hw-detect
Architecture: source
Version: 1.155
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Cyril Brulebois 
Closes: 1029804 1029849 1031631 1033035
Changes:
 hw-detect (1.155) unstable; urgency=medium
 .
   [ Cyril Brulebois ]
   * Deduplicate the list of requested firmware files, not just the list of
 requesting modules (Closes: #1031631).
   * Implement microcode support when /proc/cpuinfo contains a vendor_id
 field, with one of the following values (Closes: #1029804):
  - Install amd64-microcode on AuthenticAMD.
  - Install intel-microcode on GenuineIntel.
  - Enable non-free-firmware accordingly.
  - Perform installation via finish-install, making sure apt-setup has
been configured, and using apt-install for dependency resolution.
   * Optimize firmware package installation: process dpkg triggers once,
 after all packages have been installed (i.e. install-firmware only
 triggers a single update-initramfs call).
   * Fix condition around moutmedia calls (See: #1032377).
   * Fix files removal for non-accepted firmware packages (See: #1032377).
   * Add a special case for the mhi module: when the module requesting
 firmware files is “mhi”, use the modules listed as holders (e.g.
 ath11k_pci and qrtr_mhi). This is less precise than the usb special
 case, since /sys/bus/mhi/devices/ gives no hints as to which
 network module would be involved (See: #1032140). Thanks to Nicolas
 Dandrimont and Benoît Chauvet for the tests.
   * Adjust dmesg timestamp management: only update the timestamp file if
 there are new lines.
   * Fix package name extraction when removing a firmware package (e.g.
 it failed to install because it was corrupted). Regression in 1.153,
 spotted in #1032970.
   * Build /var/log/firmware-summary as a 3-column summary of firmware (and
 microcode) packages getting installed (Closes: #1029849). Those three
 columns are: package, component, and reason. The reason might be dmesg
 (check-missing-firmware), modalias (install-firmware hook), or cpu
 (install-firmware hook).
 .
   [ Pascal Hambourg ]
   * Fix several glitches (Closes: #1033035):
  - Fix removal of temporary files in /target after installing firmware
packages (they're in /tmp so the next reboot has been doing the
trick until now).
  - Determine the package name by using the Package field instead of
trusting the filename when installing firmware packages.
  - Make sure not to include the possible -n option when setting the
IFACES variables in check-missing-firmware.
Checksums-Sha1:
 eaa42a8ae1ad674a6d18dd2992fa20b70ecfd296 1990 hw-detect_1.155.dsc
 9918ed7197c5f80945fe5d3cb2ef91e0b4a0298d 195232 hw-detect_1.155.tar.xz
 6e415c8183d2fb5574bf360a5815641cccfaf888 6524 hw-detect_1.155_source.buildinfo
Checksums-Sha256:
 9e55c9507048484b85870d7c89640d91cbd3c3930282ac8f51c5bd5f0eecbe50 1990 
hw-detect_1.155.dsc
 b13bb32c6a162a77549dc59584418b191e6cd406e5222357b41bd71651d59b71 195232 
hw-detect_1.155.tar.xz
 31a63bad2f86257964f5d545cc361fdb3dfdab1a834c1763b09a91f5f77c6b4e 6524 
hw-detect_1.155_source.buildinfo
Files:
 3e9910d3b03016b60ee45f046b8e838c 1990 debian-installer standard 
hw-detect_1.155.dsc
 4d4062ce48d90a4802b6f8f732bfcc1e 195232 debian-installer standard 
hw-detect_1.155.tar.xz
 6e5293b429f561996d21cd2f9e58dd61 6524 debian-installer standard 
hw-detect_1.155_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAuFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmQbV6wQHGtpYmlAZGVi
aWFuLm9yZwAKCRD/kUrwwrNVIEBYEACRtLD90dTz8KXqRQikYF4EHd6sgNRVdbSy
iB9PyVAaGvp+VAOK4Vni0Wvf1liihqoOeRw22hYITqBMulX7OgzJWUOcRpUn+HSA
BeuBPbM1nLmS7pcDH0AKkrIwEp3PMj+yYQzhoOa1nVYH3bRdfxWYoz4XDLkXObK+
U9CLCXgQI4dDNf4GnZdt+kmJGccFnNTHcAmgDbfsOhd01AkN64uY/zOy1kSHKJCx
1lK1Wg94m83iPOU8eNKqoXXsJEp1h4m7MV7GFfB7hTBA9GsPbiMsFnmCS1YOAeCI
R9AfH239TudJmCRXGYaW4oI33h9G7AEOz17AI/IQj2MnYrrjzdSNImsQcuJ8V331
3gBUvH4bn+5Q0npj8KKDuxalot6dswOTUa6SOfZ1fryTXIEIITx20SyrjSC/Q9j1
U24Jf/fUpvWIV2cmK6vrXdl2luGBlvzk0TugG6WH7cLTFLkiW/BrBMlt0Np+mJi0
8RwUTT+GrVcmpSdtbsMTXASTrJuTm3Hy1VYSUlnpo7C+5wGhjViXDgShbdl6dSjJ
ohiAS+h3u8wWOJef7yoI7bzaH36CgSu+Qp/HkHSHGPdRtY1zazXnspRAlYlxFWH6
zTdrY7iwx3Aiw3q4jBQ8tHug0dM6VwwB1/ffi566pNAdaqjU7m+qkFyVtRtiuOoN
iRKOpMdzKA==
=5f86
-END PGP SIGNATURE-