Bug#1073998: linux: Purging linux-image- doesn't clean up modules.weakdep file

[Diederik de Haas]

Control: found -1 6.6.15-1

On Friday, 21 June 2024 13:41:38 CEST Christoph Berg wrote:
> I just had the same problem on linux-image-6.6.15-amd64.

Updating found version accordingly.

> > It seems to me that at least with purging that file should be removed
> > and subsequently the ``/lib/modules/`` dir.
> 
> TBH, I'd even argue plain "remove" should remove the debris from the
> modules directory, it's not like there's anything of value in the
> modules.* files left behind.

I didn't have that many kernels installed, so I only verified it with 1 and for 
that I used 'purge'. But I'm inclined to agree that remove should remove that 
file too.

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

Bug#1073998: linux: Purging linux-image- doesn't clean up modules.weakdep file

[Diederik de Haas]

Source: linux
Version: 6.9.2-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

When removing or 'even' purging a linux-image- package, it
reports the following issue:

rmdir: failed to remove '/lib/modules/': Directory not empty

The reason for that is that there's still a ``modules.weakdep`` file.
It seems to me that at least with purging that file should be removed
and subsequently the ``/lib/modules/`` dir.

FWIW: I do not have any DKMS package which could also result in the
inability to remove the modules dir.

- -- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZnVlCwAKCRDXblvOeH7b
bvdqAPwOCZQoQ5xXUbW+FkytY5Ovj5xoPizPFOWdFTvtaXro0QD/RhTTHvmL4cZ4
GfAOEDPN4Rv+vnze+lNZt+xCrTSa4AY=
=QCxl
-END PGP SIGNATURE-

Bug#973364: firmware-linux-free: Maybe missing soft dependency on wireless-regdb

[Diederik de Haas]

On Thu, 29 Oct 2020 14:22:16 +0100 Axel Beckert  wrote:
> Package: firmware-linux-free
> Version: 20200122-1
> 
> now that "iw" dropped the dependency on "crda" (see
> https://bugs.debian.org/972994), "wireless-regdb" gets uninstalled, too,
> as it was only pulled in via dependency by crda, at least on some of my
> machines.

FWIW: iw 5.9-3 added wireless-regdb as Recommends

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

Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC

[Diederik de Haas]

On Sunday, 16 June 2024 15:20:05 CEST Leith Bade wrote:
> I need to work out how to submit these fixes to the Linux device tree
> maintainers.

My experience is primarily/only with Rockchip based devices/SoCs and their 
upstream development process, but it may help wrt MediaTek's.

- If you think something is wrong, determine with ``git blame`` which commit 
added that (presumably) incorrect statement(s)
- In the commit message, you'll often find a ``Link: `` line which points to 
the discussion of that change and should point to https://lore.kernel.org/
- If there isn't a ``Link: `` line, you can put the title of the commit in the  
'lore' search box and search through all the archives; reasonable chance 
that'll point you to the discussion thread(s)
- Read through the whole discussion as it may already provide answers to 
questions you may have
- At the bottom of each 'lore' page, you'll find instructions on how to reply 
in case you have further questions/disagree/etc

https://lists.infradead.org/mailman/listinfo/linux-mediatek is where patch 
discussion takes place (which gets 'archived' on lore.k.o). You may want to 
subscribe to that list to get an idea how the upstreaming process takes place.
Keep in mind that the volume of that/those list(s) can be huge and that your 
email address will be publicly/wildly known (just like on Debian bug reports).

https://git-send-email.io/ is probably worth a look and also the ``b4`` tool.

HTH,
  Diederik

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

Bug#1073298: python3-stdlib-extensions: Version mismatch with python3 in Testing/Sid

[Diederik de Haas]

Source: python3-stdlib-extensions
Version: 3.12.3-3.1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I was running a Salsa CI job and noticed a failure with the arm64
cross-compile job due to the following error:

```sh
Setting up python3.11-minimal:arm64 (3.11.9-1) ...
/var/lib/dpkg/info/python3.11-minimal.postinst: 51: /usr/bin/python3.11: Exec 
format error
dpkg: error processing package python3.11-minimal:arm64 (--configure):
 installed python3.11-minimal:arm64 package post-installation script subprocess 
returned error exit status 126
Errors were encountered while processing:
 python3.11-minimal:arm64
E: Sub-process /usr/bin/dpkg returned an error code (1)
E: Failed to process build dependencies
```

As that job succeeded before, I looked a bit further and noticed this:

```sh
Get:22 http://deb.debian.org/debian sid/main arm64 python3 arm64 3.11.8-1 [27.4 
kB]
```

but also this:

```sh
Get:451 http://deb.debian.org/debian sid/main amd64 python3-lib2to3 all 
3.12.3-3.1 [77.7 kB]
Get:452 http://deb.debian.org/debian sid/main amd64 python3-distutils all 
3.12.3-3.1 [131 kB]
```

Based on that version number I *assume* it targets python3 version 3.12,
while src:python3-defaults is at version 3.11.8-1 in Testing and Sid.
Experimental has version 3.12.1 though.

Shouldn't those versions be in sync with each other?
Due to my assumption I didn't make it RC, but if my assumption is
correct, then a RC severity seems appropriate.

Cheers,
  Diederik

- -- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZm7VQQAKCRDXblvOeH7b
btDWAQDWPedCrXkK24zC0REJW7cDnxiGH4EmfbZwMXMkTabbvAD/ZLHjvFp4sJKP
hXgp5xOobhP0hQD9h86Z7pY7gM9c1Qo=
=/z5R
-END PGP SIGNATURE-

Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC

[Diederik de Haas]

On Thursday, 13 June 2024 23:00:51 CEST Leith Bade wrote:
> Excellent, hopefully we can get the DTS stuff from OpenWrt upstreamed into
> Linux for the OpenWrt and BPI-R3.

I have (thus far) found one possible oddity, but otherwise it looks ok AFAICT 
for BPI-R3. When that's done, the OpenWrt One should be rather simple.
But only *IF* they upstream it in time.

> I am not sure what the process is for that.

The first step would be to get involved with the community. I'm quite sure 
there's one or more threads about the BPI-R3 on the OpenWrt forums.

> As for the MT7988 I can save up and get a BPI-R4 for testing in the future,
> though I have a feeling that the Debian testing kernel might be too old,
> the drivers were only added to Linux 5 months ago. So maybe I will wait
> until there is a Debian version with a newer kernel.

I did look (briefly) into MT7988 and the problem isn't on the Debian side, but 
on the upstream side. Looking at the mt7988a.dtsi and it seems there's *quite* 
a lot missing. And the BPI-R4 dts file includes that incomplete dtsi file and 
then specifies the model name and chassis-type. That's it.
If you compare that with BPI-R3 then you'll see a huge difference.

So it looks like there's quite some work to do before the BPI-R4 is supported 
upstream, which is a prerequisite for support in Debian.
I haven't looked (at Mailing Lists), but I would be very surprised if we could 
get (proper) support in the Trixie kernel.
If you're interested in this kind of thing, you have enough time to learn and 
contribute to get proper support for it in the Forky kernel.

HTH,
  Diederik

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

Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC

[Diederik de Haas]

On Thursday, 13 June 2024 13:55:40 CEST Diederik de Haas wrote:
> > Banana Pi released a public version of the MT7986 manual which has all the
> > various register memory locations documented, though some stuff is
> > missing.
> 
> Only after writing the previous line, I realized you were talking about the
> MT798*1*, not the MT7986. And that means the OpenWrt One thread will be
> 'gold' as they intend to be as Open as possible, so check the Popular Links
> in the opening post.
> That should also lead you to https://mirror2.openwrt.org/docs/

What I forgot to mention:
MediaTek (employees) seem to contribute actively to the upstream Linux kernel. 
And they agreed to publish those detailed docs related to the OpenWrt One.

Which indicates to me they have a very friendly attitude towards Linux and 
FLOSS. So if you want a doc but can't find it (online), maybe just write them 
an email and ask for it? I don't know if they respond (positively), but 
certainly seems worth a try?

Cheers,
  Diederik

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

Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC

[Diederik de Haas]

On Wednesday, 12 June 2024 23:45:30 CEST Leith Bade wrote:
> Also, has a public version of the MT7981 Reference Manual been published?

I have no idea. I have not searched and actually don't know much/anything 
about MediaTek devices in general.
All I'm using is what is described in the DTS file in the upstream Linux repo.

> Google only finds me a pirated partial copy on Scribd. This will be needed
> to get all the memory locations for the DTS file, otherwise we will need to
> steal them from the DTS files in the Mediatek SDK or OpenWRT.

It's probably a good idea to find out if there are differences in what OpenWrt 
has/uses and what's available in the upstream Linux repo.
If there are, it would be great if those changes/improvements can be 
upstreamed (to the Linux kernel).
Probably best to ask (and search) in the OpenWrt forums. There's a LOT of info 
there and quite a number of (very) knowledgeable people.
They may also know about or have MT7981 TRM(s).

> Banana Pi released a public version of the MT7986 manual which has all the
> various register memory locations documented, though some stuff is missing.

Only after writing the previous line, I realized you were talking about the 
MT798*1*, not the MT7986. And that means the OpenWrt One thread will be 'gold' 
as they intend to be as Open as possible, so check the Popular Links in the 
opening post.
That should also lead you to https://mirror2.openwrt.org/docs/

Have fun ;-)

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

Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC

[Diederik de Haas]

On Wednesday, 12 June 2024 23:40:41 CEST Leith Bade wrote:
> Ideally if in your new kernel build you enable support for MT7981, MT7986,
> MT7988 at the same time that would be nice.

I'll only add support for the MT7986 in my kernel build as that one can be 
tested (by you) to actually work as intended.

Adding support for the other SoCs should then become much simpler as all the 
'ground work' has already been done. But to add that to the Debian kernel, 
we'd need one with a device with that SoC so that it too can be tested to 
actually work.

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

Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC

[Diederik de Haas]

On Tuesday, 11 June 2024 09:01:20 CEST Diederik de Haas wrote:
> I already have a local branch to add preliminary support for the OpenWrt One
> router [1] [2] which uses the same SoC :-)

I was wrong.
$ grep ".dtsi" arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
#include "mt7986a.dtsi"

$ grep ".dtsi" arch/arm64/boot/dts/mediatek/mt7981b-openwrt-one.dts
#include "mt7981b.dtsi"

I'm not sure but it could be Filogic 830 vs Filogic 820 platform? I wouldn't 
be surprised if there are some shared things, but those are different SoCs.

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

Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC

[Diederik de Haas]

On Tuesday, 11 June 2024 12:26:17 CEST Leith Bade wrote:
> For the record the issues I noticed are (comparing with U-boot and OpenWRTs
> versions of the device tree files):
> - mt7986a.dtsi is missing entry for the SNFI / SNAND interface to load
> https://github.com/torvalds/linux/blob/83a7eefedc9b56fe7bfeff13b6c7356688ffa
> 670/drivers/spi/spi-mtk-snfi.c this is not populated on the BPI-R3 but other
> boards might use this 

Generally, `*.dtsi` files get included into other files, usually `.dts` files.
The `mt7986a.dtsi` (likely) describes the SoC, not the full device. The device 
likely has the flash chip, not the SoC, so the dts file should have an entry 
for 
the flash chip (the dts file for OpenWrt One does f.e.).

> - in OpenWRT device tree there are a lot more entries in the efuse map
> related to the USB and PCIe ports - it seems the USB and PCIe device entries
> then use these efuse values

DeviceTree files describe the hardware, so *ideally* there should be no 
difference between what the Linux kernel has (which is generally considered the 
upstream project for DT files) and what OpenWrt has/uses.
Unfortunately, we don't live in an ideal world ;-)
If OpenWrt's DT are better (I don't know), then it would be great if they 
would upstream their improvements to the Linux kernel.
But AFAIK, OpenWrt has/manages their own kernel and DT files.

I know u-boot now has an OF_UPSTREAM (OF=OpenFirmware=DT) 'setting', which I 
*think* means they're (in the process of) switching to using the Linux 
kernel's DeviceTree files.

> - no hnat device - though maybe this is only usable with the proprietary
> Mediatek driver code

I have no idea what that is (for).

> - in OpenWRT device tree there is a different "compatible" string for spi0
> (quad) and spi1 (single) - I am not sure if that matters with the upstream
> driver, hopefully there is a way to check that the MTD device is using the
> quad SPI / SPIM mode

The "compatible" string is used to find the appropriate driver (IIUC), so if 
spi0 and spi1 have different "compatible"s, then they (apparently) need 
different drivers from them.
But as said before, (technically) OpenWrt is their own project, so it doesn't 
have to match what current upstream does/has. (OpenWrt doesn't track Linus'  
'master' branch but the most recent LTS version, which they then patch)

> - the BPI-R3 .dtso overlay files for the NAND and NOR flash options have
> partition definitions that don't match the device tree in U-boot and
> OpenWRT - ideally these should match the partitions on a factory fresh
> board which comes OpenWRT preloaded

It (generally) doesn't sound good if different projects use/assume different 
partition layouts. It could be one (or more) projects have incorrect and/or 
incomplete implementation. I don't know. It could be worth investigating what 
the correct values are and submitting patches to those projects to get that 
fixed.

> I noticed a few problems but I am not sure what normal protocol is - should
> I report it as a bug to Linux directly?

The best way to deal with it depends on the project (and could also depend on 
the subsystem of that project). AFAIK they all use Mailing Lists, but AFAIK 
OpenWrt also use Pull Requests on GH, which the (majority of the) Linux kernel 
does not. So you'll need to investigate how the project(s) you want to 
contribute too (generally) operates.

And learn/verify whether what you found is actually a bug and in which 
project(s) the problem is, and not f.e. that you were looking in the wrong 
place (dtsi vs dts).

HTH and have fun!
  Diederik

PS: this bug report is probably not the right place for these kind of 
discussions

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

Bug#1072968: linux-image-6.7.12-arm64: Add support for Mediatek MT7986 SoC

[Diederik de Haas]

Hi,

On Tuesday, 11 June 2024 08:02:41 CEST Leith Bade wrote:
> I have a Bananapi BPI-R3 board which uses the Mediatek MT7986 ARM64 SoC for
> its CPU. This is a router focussed board and currently has good support in
> the OpenWRT distribution and in the upstream Linux for a few years. The
> device tree for this board is
> https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/mediatek/m
> t7986a-bananapi- bpi-r3.dts (as well as some .dtso files to enable specific
> flash chip options).

I already have a local branch to add preliminary support for the OpenWrt One
router [1] [2] which uses the same SoC :-)

[1] 
https://forum.openwrt.org/t/openwrt-one-celebrating-20-years-of-openwrt/183684
[2] 
https://forum.openwrt.org/t/openwrt-one-celebrating-20-years-of-openwrt/183684/331

> There is a relevant discussion in https://salsa.debian.org/kernel-
> team/linux/-/merge_requests/906#note_483427 which was the code change that
> added the MT8xxx support about the various MT6xxx and MT7xxx modules being
> disabled. This is a shame as it seems that without explicitly disabling them
> then this code change would have added the modules I need.
> 
> I am happy to do any testing required to get this board supported.

And that was precisely about adding support for the OpenWrt One ;-)

Happy to update my local branch and add support for the BPi R-3.
I'm waiting for some (unrelated) other changes, but when that's posted
I intend to build a 6.10-rcX based kernel with it and I can 'merge' my
router branch into that. With that you could verify if it indeed works.

HTH,
  Diederik

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

Bug#1072239: bookworm-pu: package intel-microcode/3.20240514.1~deb12u1

[Henrique de Moraes Holschuh]

I have uploaded it source-only a few days ago, but missed emailing this bug 
report about it :-(

Thank you, and sorry for the delay!

On Wed, Jun 5, 2024, at 18:19, Jonathan Wiltshire wrote:
> Please go ahead.
-- 
  Henrique de Moraes Holschuh 

Bug#1072238: bullseye-pu: package intel-microcode/3.20240514.1~deb11u1

[Henrique de Moraes Holschuh]

I have uploaded it source-only a few days ago, but missed emailing this bug 
report about it :-(

Thank you, and sorry for the delay!

On Wed, Jun 5, 2024, at 18:18, Jonathan Wiltshire wrote:
> Please go ahead.

-- 
  Henrique de Moraes Holschuh 

Bug#1072722: nvidia-driver: Please configure SYSTEMD_SLEEP_FREEZE_USER_SESSION=false

[Peter De Wachter]

Hi Andreas,

Those locations work. But the correct environment variable turns out to be
SYSTEMD_SLEEP_FREEZE_USER_SESSIONS (plural), the NEWS file has it wrong.
(I've no idea why suspend seemed to work for me yesterday with the wrong
variable. Today it definitely didn't.) The overrides probably also need to
be installed for the other service files that run systemd-sleep:
systemd-hybrid-sleep.service, systemd-hibernate.service and
systemd-suspend-then-hibernate.service.

On Fri, Jun 7, 2024 at 10:05 PM Luca Boccassi  wrote:

> On Fri, 7 Jun 2024 at 21:03, Andreas Beckmann  wrote:
> >
> > On 07/06/2024 08.17, Peter De Wachter wrote:
> > > systemd 256-rc3 was recently uploaded to Debian. Its NEWS file
> mentions:
> > >
> > >  * The behavior of systemd-sleep and systemd-homed has been
> updated to
> > >freeze user sessions when entering the various sleep modes
> or when
> > >locking a homed-managed home area. This is known to cause
> issues with
> > >the proprietary NVIDIA drivers. Packagers of the NVIDIA
> proprietary
> > >drivers may want to add drop-in configuration files that set
> > >SYSTEMD_SLEEP_FREEZE_USER_SESSION=false for
> systemd-suspend.service
> > >and related services, and
> SYSTEMD_HOME_LOCK_FREEZE_SESSION=false for
> > >systemd-homed.service.
> >
> > Thanks for catching that. I'll try to include a fix with the upcoming
> > uploads of the recent CVE series.
> >
> > As I'm not that familiar with configuring systemd bits, do you know what
> > would be the correct locations and contents to ship the fix?
> >
> > If I read the documentation correctly, that should be
> >
> > /usr/lib/systemd/system/systemd-suspend.service.d/nvidia.conf
> > = 8< =
> > [Service]
> > Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSION=false"
> > = >8 =
> >
> > and
> >
> > /usr/lib/systemd/system/systemd-homed.service.d/nvidia.conf
> > = 8< =
> > [Service]
> > Environment="SYSTEMD_HOME_LOCK_FREEZE_SESSION=false"
> > = >8 =
> >
> > Could you verify that this works (after unapplying your temporary
> solution)?
>
> Hi Andreas, I can confirm those are the correct locations. You can
> also omit the quotes.
>

Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices

[Diederik de Haas]

On Friday, 1 September 2023 12:02:30 CEST Diederik de Haas wrote:
> > > AFAICT, TF-A for *rk356x* is really close to being mergeable?
> > I'm not entirely sure about that. In any case, for the rk3588 in U-Boot
> 
> I was talking solely about TF-A for rk3566/rk3568 here; the situation
> for rk3588 is unknown to me and could be totally different.
> 
> AFAICT, there are 2 'MRs' for TF-A for rk356x:
> 1) Addition to the (CI) build config
> 2) The actual patch set for TF-A for rk356x
> 
> ad 1) https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/20480
> ...
> 
> ad 2) https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16952
> Depends on 1 AFAICT. It's missing a SCMI part, but the plan is to add
> that in a subsequent patch.

The latter one has just been merged \o/
Thanks Kever and shengfei!

The former one is still 'Active' although I thought they were supposed to be 
merged together.
And apparently 'Gerrit' is a bit confused (by TF-A's workflow?)

https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/21840 for rk3588 
now has a Merge Conflict (due to merging the rk3568 stuff?), but that has seen 
activity in the last month too, so hopefully that'll progress (soon) too.

Cheers,
  Diederik

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

Bug#1072735: linux-image-6.7.12-amd64: graphics / KMS errors on AMD internal GPU

[Diederik de Haas]

Control: tag -1 moreinfo

On Friday, 7 June 2024 11:27:43 CEST Michael Kesper wrote:
> With kernel 6.7.12-amd64, no GUI is getting started, also no console
> gets opened automatically (boot seems to "hang"). External monitors
> (connected via USB HUB) stay blank.
> With kernel 6.6 everything works as expected.

Via https://snapshot.debian.org/package/linux-signed-amd64/ you can find older 
kernels from the 6.7 series, starting with 6.7+1~exp1.
Can you try whether the problem is also present in older 6.7 kernel versions?

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

Bug#1072722: nvidia-driver: Please configure SYSTEMD_SLEEP_FREEZE_USER_SESSION=false

[Peter De Wachter]

Package: nvidia-driver
Version: 545.23.06-1
Severity: normal

systemd 256-rc3 was recently uploaded to Debian. Its NEWS file mentions:

* The behavior of systemd-sleep and systemd-homed has been updated to
  freeze user sessions when entering the various sleep modes or when
  locking a homed-managed home area. This is known to cause issues with
  the proprietary NVIDIA drivers. Packagers of the NVIDIA proprietary
  drivers may want to add drop-in configuration files that set
  SYSTEMD_SLEEP_FREEZE_USER_SESSION=false for systemd-suspend.service
  and related services, and SYSTEMD_HOME_LOCK_FREEZE_SESSION=false for
  systemd-homed.service.

And indeed suspend would hang for me with either nvidia driver
545.23.06-1 or 535.161.08-2.


For anybody stumbling on this bug report: The easiest way to do this
by hand, is to run `systemctl edit systemd-suspend.service` and add
the two lines:

[Service]
Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSION=false"




-- Package-specific info:
uname -a:
Linux fractal 6.8.12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.8.12-1 (2024-05-31) 
x86_64 GNU/Linux

/proc/version:
Linux version 6.8.12-amd64 (debian-ker...@lists.debian.org) 
(x86_64-linux-gnu-gcc-13 (Debian 13.2.0-25) 13.2.0, GNU ld (GNU Binutils for 
Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.8.12-1 (2024-05-31)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  545.23.06  Sun Oct 15 17:43:11 
UTC 2023
GCC version:  gcc version 13.2.0 (Debian 13.2.0-25) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 
1050 Ti] [10de:1c82] (rev a1) (prog-if 00 [VGA controller])
Subsystem: ZOTAC International (MCO) Ltd. Device [19da:a454]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video  226,   0 Jun  7 07:45 /dev/dri/card0
crw-rw+ 1 root render 226, 128 Jun  7 07:45 /dev/dri/renderD128
crw-rw-rw-  1 root root   195, 254 Jun  7 07:45 /dev/nvidia-modeset
crw-rw-rw-  1 root root   195,   0 Jun  7 07:45 /dev/nvidia0
crw-rw-rw-  1 root root   195, 255 Jun  7 07:45 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Jun  7 07:45 pci-:01:00.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Jun  7 07:45 pci-:01:00.0-render -> ../renderD128
video:x:44:pdewacht

Alternative 'nvidia':
nvidia - auto mode
  link best version is /usr/lib/nvidia/current
  link currently points to /usr/lib/nvidia/current
  link nvidia is /usr/lib/nvidia/nvidia
  slave nvidia--libEGL_nvidia.so.0-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libEGL_nvidia.so.0
  slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libEGL_nvidia.so.0
  slave nvidia--libGLX_nvidia.so.0-i386-linux-gnu is 
/usr/lib/i386-linux-gnu/libGLX_nvidia.so.0
  slave nvidia--libGLX_nvidia.so.0-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0
  slave nvidia--libglxserver_nvidia.so is /usr/lib/nvidia/libglxserver_nvidia.so
  slave nvidia--libnvidia-ml.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/libnvidia-ml.so.1
  slave nvidia--libvdpau_nvidia.so.1-x86_64-linux-gnu is 
/usr/lib/x86_64-linux-gnu/vdpau/libvdpau_nvidia.so.1
  slave nvidia--nv-control-dpy is /usr/bin/nv-control-dpy
  slave nvidia--nvidia-application-profiles-key-documentation is 
/usr/share/nvidia/nvidia-application-profiles-key-documentation
  slave nvidia--nvidia-blacklists-nouveau.conf is 
/etc/nvidia/nvidia-blacklists-nouveau.conf
  slave nvidia--nvidia-bug-report.sh is /usr/lib/nvidia/nvidia-bug-report.sh
  slave nvidia--nvidia-debugdump is /usr/bin/nvidia-debugdump
  slave nvidia--nvidia-drm-outputclass.conf is 
/etc/nvidia/nvidia-drm-outputclass.conf
  slave nvidia--nvidia-load.conf is /etc/nvidia/nvidia-load.conf
  slave nvidia--nvidia-modprobe.conf is /etc/nvidia/nvidia-modprobe.conf
  slave nvidia--nvidia-options.conf is /etc/modprobe.d/nvidia-options.conf
  slave nvidia--nvidia-settings is /usr/bin/nvidia-settings
  slave nvidia--nvidia-settings.1.gz is /usr/share/man/man1/nvidia-settings.1.gz
  slave nvidia--nvidia-settings.desktop is 
/usr/share/applications/nvidia-settings.desktop
  slave nvidia--nvidia-smi is /usr/bin/nvidia-smi
  slave nvidia--nvidia-smi.1.gz is /usr/share/man/man1/nvidia-smi.1.gz
  slave nvidia--nvidia_drv.so is /usr/lib/nvidia/nvidia_drv.so
/usr/lib/nvidia/current - priority 545
  slave nvidia--libEGL_nvidia.so.0-i386-linux-gnu: 
/usr/lib/i386-linux-gnu/nvidia/current/libEGL_nvidia.so.0
  slave nvidia--libEGL_nvidia.so.0-x86_64-linux-gnu: 
/usr/lib/x86_64-linux-gnu/nvidia/current/libEGL_nvidia.so.0
  slave nvidia--libGLX_nvidia.so.0-i386-linux-gnu: 

Bug#1072435: minidlna: FTBFS with ffmpeg 7.0 : libav.h:177:36: error: ‘AVCodecParameters ’ has no member named ‘channels’

[Diederik de Haas]

Control: tag -1 upstream
Control: forwarded -1 https://sourceforge.net/p/minidlna/bugs/363/

On 2 Jun 2024 15:22:21 +0200 Sebastian Ramacher  wrote:
> Source: minidlna
> Version: 1.3.3+dfsg-1
> Severity: important
> Tags: trixie sid ftbfs
> Usertags: ffmpeg-7.0
> 
> during a rebuild of the reverse dependencies for the transition to
> ffmpeg 7.0, your package failed to build

There's an upstream bug for it, but not yet a solution.
Updating metadata accordingly.

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

Bug#1055157: duf version not shown

[Danie de Jager]

Will it be possible to improve the duf package to show the version?


Danie de Jager

Bug#1060200: intel-microcode: diff for NMU version 3.20240531.1+nmu1

[Henrique de Moraes Holschuh]

Hello Chris,

Did you test the result?   Does the system boots with an updated microcode 
after the change ?

It has to be tested with mkinitramfs and Dracut, the resulting early-initramfs 
must be "almost" byte-equal (timestamps can change, but not the paths/filenames 
inside, nor the *offset* where the data starts relative to start-of-file. THIS 
IS IMPORTANT.

I believe it should really just work with mkinitramfs, since we ask iucode_tool 
to generate the early-initramfs in that case, and iucode_tool doesn't care 
where the source data is, as long as it can read it.  One should still test it 
to be sure.

Dracut, I haven't looked into what it is doing. Hopefully it also uses 
iucode_tool nowadays...

-- 
  Henrique de Moraes Holschuh 

Bug#1072538: dracut-core: systemd-cryptsetup missing from generated image

[Mourad De Clerck]

Package: dracut-core
Version: 102-1
Severity: important

Hi,

As of version 102-1 the generated initrd leaves my system unbootable, as my root
filesystem in luks-encrypted.

After investigating it looks like the systemd-cryptsetup binary is simply 
missing.

I looked through /usr/lib/dracut/modules.d/90crypt/module-setup.sh and couldn't
find an instance where this binary is installed.

I added the line:

inst_multiple systemd-cryptsetup cryptsetup

… to the install() function of that file, regenerated my initrd, and it works 
again.

It'd be nice to get a proper fix.

Thank you,

-- Mourad DC

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

Kernel: Linux 6.8.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dracut-core depends on:
ii  cpio2.15+dfsg-1
ii  dracut-install  102-1
ii  e2fsprogs   1.47.1-1
ii  kmod32+20240327-1
ii  libc6   2.38-12
ii  libkmod232+20240327-1
ii  udev256~rc3-7

Versions of packages dracut-core recommends:
ii  binutils   2.42-4
pn  console-setup  
ii  cryptsetup 2:2.7.2-2
pn  dmraid 
ii  dmsetup2:1.02.196-1+b1
ii  kpartx 0.9.7-7
pn  lvm2   
pn  mdadm  
ii  pigz   2.8-1
ii  pkgconf1.8.1-1+b2
ii  systemd256~rc3-7

dracut-core suggests no packages.

-- no debconf information

Bug#1027773: setting sysctl net.ipv4.ping_group_range

[Diederik de Haas]

On Monday, 3 June 2024 13:29:48 CEST Luca Boccassi wrote:
> as we get near the Trixie freeze (say, September)

Wait, wut? Isn't that usually in/around January?


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

Bug#1072458: wf-recorder: FTBFS with ffmpeg 7.0: ../src/frame-writer.cpp:458:19: error: ‘const AVCodec’ {aka ‘const struct AVCodec’} has no member named ‘channel_layouts’; did you mean ‘ch_layouts’?

[Diederik de Haas]

Control: tag -1 upstream
Control: forwarded -1 https://github.com/ammen99/wf-recorder/pull/262

On zondag 2 juni 2024 15:27:52 CEST you wrote:
> Source: wf-recorder
> Version: 0.4.1-1
> Severity: important
> Tags: trixie sid ftbfs
> Usertags: ffmpeg-7.0
> 
> during a rebuild of the reverse dependencies for the transition to
> ffmpeg 7.0, your package failed to build

With the attached patch (taken from upstream PR, but adapted for Debian 
packaging) it builds successfully against ffmpeg 7.0 (as well as 6.1).

Although ... for some reason the reprotest failed as it was unable to fulfill 
the `ffmpeg (>= 7:7.0)` B-D in that job. Setting Salsa's CI release to 
"experimental" didn't make it use ffmpeg from experimental, so 'forced' it via 
an updated B-D, which worked ... for the most part.
Therefor I'm not adding the 'patch' tag.

https://salsa.debian.org/diederik/wf-recorder/-/pipelines/685183

HTH,
  Diederik>From 0cd5917c9e1ee46685119922e3ec2d5392dccbf1 Mon Sep 17 00:00:00 2001
From: Diederik de Haas 
Date: Sun, 2 Jun 2024 15:47:16 +0200
Subject: [PATCH] d/patches: Add ffmpeg 7.0 compatibility

There's an upstream PR for ffmpeg 7.0 compatibility, so add the patch
from that PR to ``debian/patches``.
Closes: #1072458

Link: https://github.com/ammen99/wf-recorder/pull/262
---
 debian/patches/ffmpeg-7-compat-pr262.patch | 109 +
 debian/patches/series  |   1 +
 2 files changed, 110 insertions(+)
 create mode 100644 debian/patches/ffmpeg-7-compat-pr262.patch
 create mode 100644 debian/patches/series

diff --git a/debian/patches/ffmpeg-7-compat-pr262.patch b/debian/patches/ffmpeg-7-compat-pr262.patch
new file mode 100644
index 000..432ecf3
--- /dev/null
+++ b/debian/patches/ffmpeg-7-compat-pr262.patch
@@ -0,0 +1,109 @@
+From 239829231e6bf5da30c43413491a0a195b84101d Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Robert-Andr=C3=A9=20Mauchin?= 
+Date: Mon, 6 May 2024 17:03:08 +0200
+Subject: [PATCH] Add compatibility with FFMPEG 7.0
+Origin: upstream, https://github.com/ammen99/wf-recorder/pull/262
+
+channel_layout has been replaced with ch_layout
+---
+ src/frame-writer.cpp | 38 +-
+ 1 file changed, 37 insertions(+), 1 deletion(-)
+
+diff --git a/src/frame-writer.cpp b/src/frame-writer.cpp
+index ad21e49..2bd9d51 100644
+--- a/src/frame-writer.cpp
 b/src/frame-writer.cpp
+@@ -12,6 +12,7 @@
+ #include "averr.h"
+ #include 
+ 
++#define HAVE_CH_LAYOUT (LIBAVUTIL_VERSION_INT >= AV_VERSION_INT(57, 28, 100))
+ 
+ static const AVRational US_RATIONAL{1,100} ;
+ 
+@@ -446,6 +447,22 @@ void FrameWriter::init_video_stream()
+ }
+ 
+ #ifdef HAVE_PULSE
++#if HAVE_CH_LAYOUT
++static uint64_t get_codec_channel_layout(const AVCodec *codec)
++{
++int i = 0;
++if (!codec->ch_layouts)
++return AV_CH_LAYOUT_STEREO;
++while (1) {
++if (!av_channel_layout_check(>ch_layouts[i]))
++break;
++if (codec->ch_layouts[i].u.mask == AV_CH_LAYOUT_STEREO)
++return codec->ch_layouts[i].u.mask;
++i++;
++}
++return codec->ch_layouts[0].u.mask;
++}
++#else
+ static uint64_t get_codec_channel_layout(const AVCodec *codec)
+ {
+   int i = 0;
+@@ -460,6 +477,7 @@ static uint64_t get_codec_channel_layout(const AVCodec *codec)
+   }
+   return codec->channel_layouts[0];
+ }
++#endif
+ 
+ static enum AVSampleFormat get_codec_auto_sample_fmt(const AVCodec *codec)
+ {
+@@ -533,10 +551,14 @@ void FrameWriter::init_audio_stream()
+ {
+ audioCodecCtx->sample_fmt = convert_codec_sample_fmt(codec, params.sample_fmt);
+ }
++#if HAVE_CH_LAYOUT
++av_channel_layout_from_mask(>ch_layout, get_codec_channel_layout(codec));
++#else
+ audioCodecCtx->channel_layout = get_codec_channel_layout(codec);
++audioCodecCtx->channels = av_get_channel_layout_nb_channels(audioCodecCtx->channel_layout);
++#endif
+ audioCodecCtx->sample_rate = params.sample_rate;
+ audioCodecCtx->time_base = (AVRational) { 1, 1000 };
+-audioCodecCtx->channels = av_get_channel_layout_nb_channels(audioCodecCtx->channel_layout);
+ 
+ if (fmtCtx->oformat->flags & AVFMT_GLOBALHEADER)
+ audioCodecCtx->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
+@@ -559,8 +581,14 @@ void FrameWriter::init_audio_stream()
+ av_opt_set_int(swrCtx, "out_sample_rate", audioCodecCtx->sample_rate, 0);
+ av_opt_set_sample_fmt(swrCtx, "in_sample_fmt", AV_SAMPLE_FMT_FLT, 0);
+ av_opt_set_sample_fmt(swrCtx, "out_sample_fmt", audioCodecCtx->sample_fmt, 0);
++#if HAVE_CH_LAYOUT
++AVChannelLayout in_chlayout = AV_CHANNEL_LAYOUT_STEREO;
++av_opt_set_chlayout(swrCtx, "in_chlayout", _chlayout, 0);
++av_opt_set_chlayout(swrCtx, "out_chlayout", >ch_layout, 0);
++#else
+ av_opt_set_channel_layout(swrCtx, "in_channel_layout", 

Bug#1072355: nss-pam-ldapd: upload with maintainer-built binaries cannot migrate

[Arthur de Jong]

On Sat, 2024-06-01 at 14:59 +0200, Chris Hofstaedtler wrote:
> thanks for uploading to unstable. However the upload included
> maintainer-built binaries (for Arch: all and amd64). Migration to
> testing of these is forbidden by release team policy.
> Please upload a new version (no further changes needed) without any
> binaries to let the package migrate.

Thanks. I always seem to be confused about which changes file to upload
:/

Anyway, I've just uploaded 0.9.12-7 which should be source-only again.

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



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

Bug#1061701: nss-pam-ldapd: install PAM and NSS modules into /usr

[Arthur de Jong]

On Wed, 2024-05-29 at 00:59 +0200, Chris Hofstaedtler wrote:
> Please make sure this patch reaches unstable well before the trixie
> transition freeze. Now would be a good time.

Thanks for the reminder. I've uploaded 0.9.12-6 which includes this
change.

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



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

Bug#1072239: bookworm-pu: package intel-microcode/3.20240514.1~deb12u1

[Henrique de Moraes Holschuh]

, pf_mask 0x07, 2023-12-05, rev 0x0035
+sig 0x000b06f2, pf_mask 0x07, 2023-12-05, rev 0x0035
+sig 0x000b06f5, pf_mask 0x07, 2023-12-05, rev 0x0035
+sig 0x000906a3, pf_mask 0x80, 2023-12-05, rev 0x0433, size 08
+sig 0x000906a4, pf_mask 0x80, 2023-12-05, rev 0x0433
+sig 0x000906a4, pf_mask 0x40, 2023-12-07, rev 0x0007, size 119808
+sig 0x000b0671, pf_mask 0x32, 2024-01-25, rev 0x0123, size 215040
+sig 0x000b06e0, pf_mask 0x11, 2023-12-07, rev 0x0017, size 138240
+sig 0x000c06f2, pf_mask 0x87, 2024-02-05, rev 0x21000230, size 552960
+sig 0x000c06f1, pf_mask 0x87, 2024-02-05, rev 0x21000230
+
 2024-03-12:
   * New upstream microcode datafile 20240312
 - Mitigations for INTEL-SA-INTEL-SA-00972 (CVE-2023-39368):
diff --git a/debian/changelog b/debian/changelog
index f156f68..92b7e2b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,52 @@
+intel-microcode (3.20240514.1~deb12u1) bookworm; urgency=medium
+
+  * Build for bookworm (no changes)
+
+ -- Henrique de Moraes Holschuh   Wed, 29 May 2024 23:27:07 -0300
+
+intel-microcode (3.20240514.1) unstable; urgency=medium
+
+  * New upstream microcode datafile 20240514 
+* Mitigations for INTEL-SA-01051 (CVE-2023-45733)
+  Hardware logic contains race conditions in some Intel Processors may
+  allow an authenticated user to potentially enable partial information
+  disclosure via local access.
+* Mitigations for INTEL-SA-01052 (CVE-2023-46103)
+  Sequence of processor instructions leads to unexpected behavior in
+  Intel Core Ultra Processors may allow an authenticated user to
+  potentially enable denial of service via local access.
+* Mitigations for INTEL-SA-01036 (CVE-2023-45745,  CVE-2023-47855)
+  Improper input validation in some Intel TDX module software before
+  version 1.5.05.46.698 may allow a privileged user to potentially enable
+  escalation of privilege via local access.
+* Fix for unspecified functional issues on 4th gen and 5th gen Xeon
+  Scalable, 12th, 13th and 14th gen Intel Core processors, as well as for
+  Core i3 N-series processors.
+* Updated microcodes:
+  sig 0x000806f8, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0, size 581632
+  sig 0x000806f7, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0
+  sig 0x000806f6, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0
+  sig 0x000806f5, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0
+  sig 0x000806f4, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0
+  sig 0x000806f8, pf_mask 0x10, 2024-02-05, rev 0x2c000390, size 614400
+  sig 0x000806f6, pf_mask 0x10, 2024-02-05, rev 0x2c000390
+  sig 0x000806f5, pf_mask 0x10, 2024-02-05, rev 0x2c000390
+  sig 0x000806f4, pf_mask 0x10, 2024-02-05, rev 0x2c000390
+  sig 0x00090672, pf_mask 0x07, 2023-12-05, rev 0x0035, size 224256
+  sig 0x00090675, pf_mask 0x07, 2023-12-05, rev 0x0035
+  sig 0x000b06f2, pf_mask 0x07, 2023-12-05, rev 0x0035
+  sig 0x000b06f5, pf_mask 0x07, 2023-12-05, rev 0x0035
+  sig 0x000906a3, pf_mask 0x80, 2023-12-05, rev 0x0433, size 08
+  sig 0x000906a4, pf_mask 0x80, 2023-12-05, rev 0x0433
+  sig 0x000906a4, pf_mask 0x40, 2023-12-07, rev 0x0007, size 119808
+  sig 0x000b0671, pf_mask 0x32, 2024-01-25, rev 0x0123, size 215040
+  sig 0x000b06e0, pf_mask 0x11, 2023-12-07, rev 0x0017, size 138240
+  sig 0x000c06f2, pf_mask 0x87, 2024-02-05, rev 0x21000230, size 552960
+  sig 0x000c06f1, pf_mask 0x87, 2024-02-05, rev 0x21000230
+  * source: update symlinks to reflect id of the latest release, 20240514
+
+ -- Henrique de Moraes Holschuh   Thu, 16 May 2024 21:40:52 -0300
+
 intel-microcode (3.20240312.1~deb12u1) bookworm; urgency=medium
 
   * Build for bookworm (no changes)
diff --git a/intel-ucode/06-8f-05 b/intel-ucode/06-8f-05
index bef4d36..ef5b752 100644
Binary files a/intel-ucode/06-8f-05 and b/intel-ucode/06-8f-05 differ
diff --git a/intel-ucode/06-8f-06 b/intel-ucode/06-8f-06
index bef4d36..ef5b752 100644
Binary files a/intel-ucode/06-8f-06 and b/intel-ucode/06-8f-06 differ
diff --git a/intel-ucode/06-8f-07 b/intel-ucode/06-8f-07
index 07ab364..d629737 100644
Binary files a/intel-ucode/06-8f-07 and b/intel-ucode/06-8f-07 differ
diff --git a/intel-ucode/06-8f-08 b/intel-ucode/06-8f-08
index bef4d36..ef5b752 100644
Binary files a/intel-ucode/06-8f-08 and b/intel-ucode/06-8f-08 differ
diff --git a/intel-ucode/06-97-02 b/intel-ucode/06-97-02
index 71c9c34..05450f8 100644
Binary files a/intel-ucode/06-97-02 and b/intel-ucode/06-97-02 differ
diff --git a/intel-ucode/06-97-05 b/intel-ucode/06-97-05
index 71c9c34..05450f8 100644
Binary files a/intel-ucode/06-97-05 and b/intel-ucode/06-97-05 differ
diff --git a/intel-ucode/06-9a-03 b/intel-ucode/06-9a-03
index a8339f9..b4f9b45 100644
Binary files a/intel-ucode/06-9a-03 and b/intel-ucode/06-9a-03 differ
diff --git a/intel-ucode/06-9a-04 b/intel-ucode/06-9a-04
index 5917702..27bfc92 100644
Binary files a/intel-ucode/06-9a-04 and

Bug#1072238: bullseye-pu: package intel-microcode/3.20240514.1~deb11u1

[Henrique de Moraes Holschuh]

, pf_mask 0x07, 2023-12-05, rev 0x0035
+sig 0x000b06f2, pf_mask 0x07, 2023-12-05, rev 0x0035
+sig 0x000b06f5, pf_mask 0x07, 2023-12-05, rev 0x0035
+sig 0x000906a3, pf_mask 0x80, 2023-12-05, rev 0x0433, size 08
+sig 0x000906a4, pf_mask 0x80, 2023-12-05, rev 0x0433
+sig 0x000906a4, pf_mask 0x40, 2023-12-07, rev 0x0007, size 119808
+sig 0x000b0671, pf_mask 0x32, 2024-01-25, rev 0x0123, size 215040
+sig 0x000b06e0, pf_mask 0x11, 2023-12-07, rev 0x0017, size 138240
+sig 0x000c06f2, pf_mask 0x87, 2024-02-05, rev 0x21000230, size 552960
+sig 0x000c06f1, pf_mask 0x87, 2024-02-05, rev 0x21000230
+
 2024-03-12:
   * New upstream microcode datafile 20240312
 - Mitigations for INTEL-SA-INTEL-SA-00972 (CVE-2023-39368):
diff --git a/debian/changelog b/debian/changelog
index 317fad2..10f37f4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,53 @@
+intel-microcode (3.20240514.1~deb11u1) bullseye; urgency=medium
+
+  * Backport to Debian Bullseye
+  * debian/control: revert non-free-firmware change
+
+ -- Henrique de Moraes Holschuh   Wed, 29 May 2024 23:31:29 -0300
+
+intel-microcode (3.20240514.1) unstable; urgency=medium
+
+  * New upstream microcode datafile 20240514 
+* Mitigations for INTEL-SA-01051 (CVE-2023-45733)
+  Hardware logic contains race conditions in some Intel Processors may
+  allow an authenticated user to potentially enable partial information
+  disclosure via local access.
+* Mitigations for INTEL-SA-01052 (CVE-2023-46103)
+  Sequence of processor instructions leads to unexpected behavior in
+  Intel Core Ultra Processors may allow an authenticated user to
+  potentially enable denial of service via local access.
+* Mitigations for INTEL-SA-01036 (CVE-2023-45745,  CVE-2023-47855)
+  Improper input validation in some Intel TDX module software before
+  version 1.5.05.46.698 may allow a privileged user to potentially enable
+  escalation of privilege via local access.
+* Fix for unspecified functional issues on 4th gen and 5th gen Xeon
+  Scalable, 12th, 13th and 14th gen Intel Core processors, as well as for
+  Core i3 N-series processors.
+* Updated microcodes:
+  sig 0x000806f8, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0, size 581632
+  sig 0x000806f7, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0
+  sig 0x000806f6, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0
+  sig 0x000806f5, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0
+  sig 0x000806f4, pf_mask 0x87, 2024-02-05, rev 0x2b0005c0
+  sig 0x000806f8, pf_mask 0x10, 2024-02-05, rev 0x2c000390, size 614400
+  sig 0x000806f6, pf_mask 0x10, 2024-02-05, rev 0x2c000390
+  sig 0x000806f5, pf_mask 0x10, 2024-02-05, rev 0x2c000390
+  sig 0x000806f4, pf_mask 0x10, 2024-02-05, rev 0x2c000390
+  sig 0x00090672, pf_mask 0x07, 2023-12-05, rev 0x0035, size 224256
+  sig 0x00090675, pf_mask 0x07, 2023-12-05, rev 0x0035
+  sig 0x000b06f2, pf_mask 0x07, 2023-12-05, rev 0x0035
+  sig 0x000b06f5, pf_mask 0x07, 2023-12-05, rev 0x0035
+  sig 0x000906a3, pf_mask 0x80, 2023-12-05, rev 0x0433, size 08
+  sig 0x000906a4, pf_mask 0x80, 2023-12-05, rev 0x0433
+  sig 0x000906a4, pf_mask 0x40, 2023-12-07, rev 0x0007, size 119808
+  sig 0x000b0671, pf_mask 0x32, 2024-01-25, rev 0x0123, size 215040
+  sig 0x000b06e0, pf_mask 0x11, 2023-12-07, rev 0x0017, size 138240
+  sig 0x000c06f2, pf_mask 0x87, 2024-02-05, rev 0x21000230, size 552960
+  sig 0x000c06f1, pf_mask 0x87, 2024-02-05, rev 0x21000230
+  * source: update symlinks to reflect id of the latest release, 20240514
+
+ -- Henrique de Moraes Holschuh   Thu, 16 May 2024 21:40:52 -0300
+
 intel-microcode (3.20240312.1~deb11u1) bullseye; urgency=medium
 
   * Backport to Debian Bullseye
diff --git a/intel-ucode/06-8f-05 b/intel-ucode/06-8f-05
index bef4d36..ef5b752 100644
Binary files a/intel-ucode/06-8f-05 and b/intel-ucode/06-8f-05 differ
diff --git a/intel-ucode/06-8f-06 b/intel-ucode/06-8f-06
index bef4d36..ef5b752 100644
Binary files a/intel-ucode/06-8f-06 and b/intel-ucode/06-8f-06 differ
diff --git a/intel-ucode/06-8f-07 b/intel-ucode/06-8f-07
index 07ab364..d629737 100644
Binary files a/intel-ucode/06-8f-07 and b/intel-ucode/06-8f-07 differ
diff --git a/intel-ucode/06-8f-08 b/intel-ucode/06-8f-08
index bef4d36..ef5b752 100644
Binary files a/intel-ucode/06-8f-08 and b/intel-ucode/06-8f-08 differ
diff --git a/intel-ucode/06-97-02 b/intel-ucode/06-97-02
index 71c9c34..05450f8 100644
Binary files a/intel-ucode/06-97-02 and b/intel-ucode/06-97-02 differ
diff --git a/intel-ucode/06-97-05 b/intel-ucode/06-97-05
index 71c9c34..05450f8 100644
Binary files a/intel-ucode/06-97-05 and b/intel-ucode/06-97-05 differ
diff --git a/intel-ucode/06-9a-03 b/intel-ucode/06-9a-03
index a8339f9..b4f9b45 100644
Binary files a/intel-ucode/06-9a-03 and b/intel-ucode/06-9a-03 differ
diff --git a/intel-ucode/06-9a-04 b/intel-ucode/06-9a-04
index 5917702..27bfc92

Bug#1054093: monit: diff for NMU version 1:5.33.0-2.1

[Fabio A. De Muzio Tobich]

Em 29/05/2024 21:59, Chris Hofstaedtler escreveu:

Control: tags 1054093 + pending


Dear maintainer,

I've prepared an NMU for monit (versioned as 1:5.33.0-2.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.



Hi Chris,

Your NMU is welcome, and feel free to reduce the delay if you see fit.

Thanks.

--
⢀⣴⠾⠻⢶⣦
⣾⠁⢠⠒⠀⣿⡁   Fabio Augusto De Muzio Tobich
⢿⡄⠘⠷⠚⠋⠀   9730 4066 E5AE FAC2 2683  D03D 4FB3 B4D3 7EF6 3B2E
⠈⠳⣄


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072108: linux-image-amd64: Enable CONFIG_PINCTRL_METEORLAKE

[Diederik de Haas]

On Wednesday, 29 May 2024 03:22:50 CEST Mark Pearson wrote:
> >> X-Debbugs-Cc: mpearson-len...@squebb.ca
> > ...
> > The MR for it (1062) has just been merged into master.
> 
> Awesome - thanks! I did scan the bugs before submitting but missed that one.
> Apologies. Should I close this issue then as it's a duplicate?

I *assumed* the "X-Debbugs-Cc" meant that bug would've landed directly in your 
inbox, but I can be wrong. Sorry about that.

No need to do anything. They're merged which means that when the kernel with 
that commit gets uploaded to the Debian archives, both will automatically be 
closed together.

Cheers,
  Diederik

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

Bug#1072108: linux-image-amd64: Enable CONFIG_PINCTRL_METEORLAKE

[Diederik de Haas]

Control: forcemerge -1 1071551

On Tuesday, 28 May 2024 20:20:11 CEST Mark Pearson wrote:
> Package: src:linux
> Version: 6.8.11-1
> Severity: important
> X-Debbugs-Cc: mpearson-len...@squebb.ca
> 
> Dear Maintainer,
> 
> Please enable the CONFIG_PINCTRL_METEORLAKE kernel option. This is needed to
> support Meteorlake based platforms.

That was already requested in bug #1071551 with the following header:

On Mon, 20 May 2024 22:19:16 -0300 Facundo Gaich  wrote:
> Package: src:linux
> Version: 6.8.9-1
> Severity: important
> X-Debbugs-Cc: mpearson-len...@squebb.ca

...

The MR for it (1062) has just been merged into master.

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

Bug#1072090: cannot use compile command

[Thadeu Lima de Souza Cascardo]

Package: gdb
Version: 13.2-1+b1
Severity: normal

As of recently, I cannot use the compile command anymore.

(gdb) compile close(6);
cc1: fatal error: libcc1plugin: unknown version in handshake
compilation terminated.
Compilation failed.



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages gdb depends on:
ii  libbabeltrace1   1.5.11-3+b6
ii  libc62.38-11
ii  libdebuginfod1t640.191-1+b1
ii  libexpat12.6.2-1
ii  libgcc-s114.1.0-1
ii  libgmp10 2:6.3.0+dfsg-2+b1
ii  libipt2  2.0.6-1
ii  liblzma5 5.6.1+really5.4.5-1
ii  libmpfr6 4.2.1-1+b1
ii  libncursesw6 6.5-2
ii  libpython3.11t64 3.11.9-1
ii  libreadline8t64  8.2-4
ii  libsource-highlight4t64  3.1.9-4.3
ii  libstdc++6   14.1.0-1
ii  libtinfo66.5-2
ii  libxxhash0   0.8.2-2+b1
ii  libzstd1 1.5.5+dfsg2-2
ii  zlib1g   1:1.3.dfsg+really1.3.1-1

Versions of packages gdb recommends:
ii  libc6-dbg [libc-dbg]  2.38-11

Versions of packages gdb suggests:
pn  gdb-doc
ii  gdbserver  13.2-1+b1

-- no debconf information

Bug#1071575: dahdi-dkms: module fails to build for Linux 6.8.9: error: implicit declaration of function 'strlcpy'

[Diederik de Haas]

On Monday, 27 May 2024 17:25:02 CEST Tzafrir Cohen wrote:
> Thanks for that. Just one note regarding the word "upstream". The
> current upstream of the package is the osmo fork. At the time when
> uploading previous version, that fork was looking more reliable than the
> main branch.

Yeah, it was/is a bit confusing, hence my next reply contained:

On 27 May 2024 10:40:24 +0200 Diederik de Haas  wrote:
> Forgot to mention that that commit is part of upstream's 3.4.0~rc1, 
> but it's unclear to me what is considered upstream now.

The ``debian/watch`` file points to one repo, but the ``upstream`` branch 
(indeed) indicated that came from another repo.

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

Bug#1071575: dahdi-dkms: module fails to build for Linux 6.8.9: error: implicit declaration of function 'strlcpy'

[Diederik de Haas]

On 27 May 2024 10:26:45 +0200 Diederik de Haas  wrote:
> Control: tag -1 upstream fixed-upstream patch
> 
> On Tue, 21 May 2024 14:57:47 +0200 Andreas Beckmann  wrote:
> > Package: dahdi-dkms
> > Version: 1:3.1.0+git20230717~dfsg-5
> > Severity: serious
> 
> Attached is the upstream patch for compatibility with 6.8/6.9 kernels added
> to ``debian/patches``.

Forgot to mention that that commit is part of upstream's 3.4.0~rc1, 
but it's unclear to me what is considered upstream now.

https://github.com/asterisk/dahdi-linux/commit/497f11466688d9e76a7b68ffdd2c3859279f5fce

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

Bug#1071575: dahdi-dkms: module fails to build for Linux 6.8.9: error: implicit declaration of function 'strlcpy'

[Diederik de Haas]

Control: tag -1 upstream fixed-upstream patch

On Tue, 21 May 2024 14:57:47 +0200 Andreas Beckmann  wrote:
> Package: dahdi-dkms
> Version: 1:3.1.0+git20230717~dfsg-5
> Severity: serious
> 
> DKMS make.log for dahdi-3.1.0+git20230717 for kernel 6.8.9-amd64 (x86_64)
> Sun May 19 19:55:53 UTC 2024
> make -C /lib/modules/6.8.9-amd64/build KBUILD_EXTMOD=/var/lib/dkms/dahdi/
> 3.1.0+git20230717/build/drivers/dahdi DAHDI_INCLUDE=/var/lib/dkms/dahdi/
> 3.1.0+git20230717/build/include DAHDI_MODULES_EXTRA="dahdi_dummy.o 
> dahdi_echocan_oslec.o " HOTPLUG_FIRMWARE=yes m
> ...
> /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/wct4xxp/base.c:
> In function 'free_wc':
> /usr/src/linux-headers-6.8.9-common/include/linux/workqueue.h:625:9: 
> warning: call to '__warn_flushing_systemwide_wq' declared with attribute 
> warning: Please avoid flushing system-wide workqueues. [-Wattribute-warning]
>   625 | __warn_flushing_systemwide_wq();  
>   
>   \
>   | ^~~

This is something upstream should take a look at, but is not the cause of the 
build failure.

>   CC [M]  /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/
>   card_global.o 
> /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/card_global.c:
> In function 'parse_chip_command':
> /var/lib/dkms/dahdi/3.1.0+git20230717/build/drivers/dahdi/xpp/card_global.c
> :344:9: error: implicit declaration of function 'strlcpy'; did you mean
> 'strscpy'? [-Werror=implicit-function-declaration]> 
>   344 | strlcpy(buf, cmdline, MAX_PROC_WRITE);  /* Save a copy */
>   
>   | ^~~
>   | strscpy
> 
> cc1: some warnings being treated as errors

But this is.
Attached is the upstream patch for compatibility with 6.8/6.9 kernels added to 
``debian/patches``.
>From e032b7936b75400f039ae8dfd40b1fdfdd56f2ce Mon Sep 17 00:00:00 2001
From: Diederik de Haas 
Date: Mon, 27 May 2024 10:18:08 +0200
Subject: [PATCH] d/patches: Add "Fix compilation issue for 6.8.y/6.9.y kernel"

Link: https://github.com/asterisk/dahdi-linux/commit/497f11466688d9e76a7b68ffdd2c3859279f5fce
---
 ...ilation-issue-for-6.8.y-6.9.y-kernel.patch | 231 ++
 debian/patches/series |   2 +
 2 files changed, 233 insertions(+)
 create mode 100644 debian/patches/Fix-compilation-issue-for-6.8.y-6.9.y-kernel.patch

diff --git a/debian/patches/Fix-compilation-issue-for-6.8.y-6.9.y-kernel.patch b/debian/patches/Fix-compilation-issue-for-6.8.y-6.9.y-kernel.patch
new file mode 100644
index 000..123428b
--- /dev/null
+++ b/debian/patches/Fix-compilation-issue-for-6.8.y-6.9.y-kernel.patch
@@ -0,0 +1,231 @@
+From: Pushkar Singh 
+Date: Thu, 4 Apr 2024 01:15:01 +0530
+Subject: Fix compilation issue for 6.8.y/6.9.y kernel
+Origin: upstream, https://github.com/asterisk/dahdi-linux.git/commit/497f11466688d9e76a7b68ffdd2c3859279f5fce
+
+---
+ drivers/dahdi/dahdi-base.c  | 40 ++---
+ drivers/dahdi/dahdi_dynamic.c   |  4 +--
+ drivers/dahdi/dahdi_dynamic_eth.c   |  4 +--
+ drivers/dahdi/dahdi_dynamic_ethmf.c |  2 +-
+ drivers/dahdi/dahdi_transcode.c |  2 +-
+ drivers/dahdi/xpp/card_global.c |  2 +-
+ 6 files changed, 27 insertions(+), 27 deletions(-)
+
+diff --git a/drivers/dahdi/dahdi-base.c b/drivers/dahdi/dahdi-base.c
+index b96f72b..87177a6 100644
+--- a/drivers/dahdi/dahdi-base.c
 b/drivers/dahdi/dahdi-base.c
+@@ -4359,7 +4359,7 @@ static int dahdi_ioctl_getparams(struct file *file, unsigned long data)
+ 	param.pulsebreaktime = chan->pulsebreaktime;
+ 	param.pulseaftertime = chan->pulseaftertime;
+ 	param.spanno = (chan->span) ? chan->span->spanno : 0;
+-	strlcpy(param.name, chan->name, sizeof(param.name));
++	strscpy(param.name, chan->name, sizeof(param.name));
+ 	param.chanpos = chan->chanpos;
+ 	param.sigcap = chan->sigcap;
+ 	/* Return current law */
+@@ -4447,8 +4447,8 @@ static int dahdi_ioctl_spanstat(struct file *file, unsigned long data)
+ 
+ 	spaninfo.spanno = s->spanno; /* put the span # in here */
+ 	spaninfo.totalspans = span_count();
+-	strlcpy(spaninfo.desc, s->desc, sizeof(spaninfo.desc));
+-	strlcpy(spaninfo.name, s->name, sizeof(spaninfo.name));
++	strscpy(spaninfo.desc, s->desc, sizeof(spaninfo.desc));
++	strscpy(spaninfo.name, s->name, sizeof(spaninfo.name));
+ 	spaninfo.alarms = s->alarms;		/* get alarm status */
+ 	spaninfo.rxlevel = s->rxlevel;	/* get rx level */
+ 	spaninfo.txlevel = s->txlevel;	/* get tx level */
+@@ -4475,18 +4475,18 @@ static int dahdi_ioctl_spanstat(struct file *file, unsigned long data)
+ 	spaninfo.lineconfig = s->lineconfig;
+ 	spaninfo.irq = 0;
+ 	spaninfo.linecompat = s->linecompat;
+-	strlcpy(spaninfo.lboname, dahdi_lboname(s->lbo),
++	strscpy(spaninfo.lboname, dahdi_lbon

Bug#1071959: arm-trusted-firmware: New upstream versions (lts-v2.10.4 and v2.11)

[Diederik de Haas]

Source: arm-trusted-firmware
Version: 2.10.0+dfsg-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Upstream recently released two new versions:
- - lts-v2.10.4
- - v2.11

If you want to stay on a LTS release, then updating to 2.10.4 gives
quite a number of workarounds for errata.

If you want to switch to the latest upstream release, then you can drop
my patch for rk3328 as that's included upstream.

Cheers,
  Diederik

- -- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZlNFxAAKCRDXblvOeH7b
bt0NAQCWZNqPRYkhlbRqsZm/q9eqj7ktyDa9b9gKG04+7bYpngEAlTjYOwCxzdWu
fuEoYL6KFbWRhJfCzPr/FDiF3UBxlQo=
=Ix6n
-END PGP SIGNATURE-

Bug#1009802: Warning: The home dir /var/lib/usbmux you specified can't be accessed: No such file or directory

[Diederik de Haas]

Control: found -1 1.1.1-2
Control: found -1 1.1.1-3+b1

On 18 Apr 2022 12:23:29 -0700 Scott Corcoran  wrote:
> Good catch:
> 
> ~ # apt list | grep usbmuxd
> 
> libusbmuxd-dev/testing 2.0.2-3 amd64
> libusbmuxd-tools/testing 2.0.2-3 amd64
> libusbmuxd6/testing,now 2.0.2-3 amd64 [installed,automatic]
> usbmuxd/testing,now 1.1.1-2 amd64 [installed,automatic]

Setting the found version to that version.
And as I just ran into this problem too, add my version too.

I installed upower and as one of its dependencies, usbmuxd got installed too:

```
Selecting previously unselected package usbmuxd.
Preparing to unpack .../5-usbmuxd_1.1.1-3+b1_arm64.deb ...
Unpacking usbmuxd (1.1.1-3+b1) ...
Setting up libplist3:arm64 (2.2.0-7+b1) ...
Setting up libusbmuxd6:arm64 (2.0.2-4+b1) ...
Setting up libupower-glib3:arm64 (1.90.3-1) ...
Setting up libimobiledevice6:arm64 (1.3.0-7.1+b1) ...
Setting up upower (1.90.3-1) ...
upower.service is a disabled or a static unit, not starting it.
Setting up usbmuxd (1.1.1-3+b1) ...
info: The home dir /var/lib/usbmux you specified can't be accessed: No such 
file or directory

info: Selecting UID from range 100 to 999 ...

info: Adding system user `usbmux' (UID 106) ...
info: Adding new user `usbmux' (UID 106) with group `plugdev' ...
info: Not creating home directory `/var/lib/usbmux'.
```

And indeed /var/lib/usbmux doesn't exist on the system where I installed it on.
It's also installed on my main PC and that doesn't have that dir either.

Shouldn't this bug have a higher severity?
It creates a (system) user and it wants to create a home dir for it, but fails
to do so.
I haven't noticed any adverse affects, so I won't bump the severity, but as I
don't have any iDevice I may not be considered a 'normal' user of the package.

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

Bug#1071825: linux-image-6.8.9-amd64: Fails to build some module(s) during install

[Diederik de Haas]

Control: found -1 0.4.4-1
Control: tag -1 upstream patch
Control: forwarded -1 
https://gitlab.com/ddcci-driver-linux/ddcci-driver-linux/-/commit/7f851f5fb8fbcd7b3a93aaedff90b27124e17a7e

On Saturday, 25 May 2024 10:18:20 CEST Bastian Blank wrote:
> Control: reassign -1 ddcci-dkms/0.4.4-1

Upstream has a commit for compatibility with 6.8 and I've set that at
the 'forwarded' URL. There's no release/tag with that commit though.

HTH

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

Bug#1071662: chromium: Wrapper script does not correctly pass arguments to Chromium

[Remco de Man]

I extracted a patch file from the commit you mentioned at 
https://salsa.debian.org/chromium-team/chromium/-/commit/e8b6bbd59aadf18e41ee98841da7fc4783036957 
and applied it in our environment.


The patch seems to be working correctly. At least for our use case, the 
--user-agent flag, it does not cause any further problems.


Let me know if you need any additional information.

Andres Salomon schreef op 2024-05-23 20:05:

Can you please test out the following patch?

https://salsa.debian.org/chromium-team/chromium/-/commit/e8b6bbd59aadf18e41ee98841da7fc4783036957

The easiest way to test would probably be to manually edit 
/usr/bin/chromium, and cut/paste the changes that are reflected in that 
commit for the debian/scripts/chromium file.



On 5/23/24 12:42, Andres Salomon wrote:
Thanks for the heads up. While I work on fixing this, a temporary 
workaround you can use is ' -- ' before --user-agent. Eg,


chromium --headless --no-sandbox -- --user-agent="Mozilla/5.0 
(Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like 
Gecko) Chrome/41.0.2227.1 Safari/537.36"


On 5/23/24 07:11, Remco de Man wrote:

Package: chromium
Version: 125.0.6422.76-1~deb12u1
Severity: normal

Dear Maintainer,

When running 125.0.6422.76-1~deb12u1, when passing arguments to the 
chromium
wrapper script included in the Debian package, not all arguments are 
passed

correctly to the Chromium binary.

This happens especially when the arguments need any type of quoting, 
like

in the case of passing a custom User-Agent with --user-agent.

A minimal reproduction sample for me is running the following 
command:


chromium --headless --no-sandbox --user-agent="Mozilla/5.0 
(Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like 
Gecko) Chrome/41.0.2227.1 Safari/537.36"


It seems that because the user agent contains spaces, this is not 
correctly
passed to the chromium binary. The regression was not present in the 
previous
security release, 125.0.6422.60-1~deb12u1, and seems to be caused by 
change

https://salsa.debian.org/chromium-team/chromium/-/commit/dc792dc4f3bfdd3e00f5fe7b7bf314077ed301bb

Because of this, many of our headless usage scenarios do not work 
correctly
anymore, since Chromium exits with the 'Multiple targets are not 
supported'
message, because it parses some of the user agent as seperate 
arguments to

its binary.

Seems like the wrapper script should be patched to handle this 
scenario,

or the change should be reverted.

-- System Information:
Debian Release: 12.5
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'stable-security'), 
(500, 'stable')

Architecture: amd64 (x86_64)

Kernel: Linux 6.1.82 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) 
(ignored: LC_ALL set to en_US.UTF-8), LANGUAGE not set

Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages chromium depends on:
ii  chromium-common    125.0.6422.76-1~deb12u1
ii  libasound2 1.2.8-1+b1
ii  libatk-bridge2.0-0 2.46.0-5
ii  libatk1.0-0    2.46.0-5
ii  libatomic1 12.2.0-14
ii  libatspi2.0-0  2.46.0-5
ii  libc6  2.36-9+deb12u7
ii  libcairo2  1.16.0-7
ii  libcups2   2.4.2-3+deb12u5
ii  libdav1d6  1.0.0-2+deb12u1
ii  libdbus-1-3    1.14.10-1~deb12u1
ii  libdouble-conversion3  3.2.1-1
ii  libdrm2    2.4.114-1+b1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libexpat1  2.5.0-1
ii  libflac12  1.4.2+ds-2
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-5
ii  libgbm1    22.3.6-1+deb12u1
ii  libgcc-s1  12.2.0-14
ii  libglib2.0-0   2.74.6-2+deb12u2
ii  libgtk-3-0 3.24.38-2~deb12u1
ii  libharfbuzz-subset0    6.0.0+dfsg-3
ii  libharfbuzz0b  6.0.0+dfsg-3
ii  libjpeg62-turbo    1:2.1.5-2
ii  libjsoncpp25   1.9.5-4
ii  liblcms2-2 2.14-2
ii  libminizip1    1.1-8+deb12u1
ii  libnspr4   2:4.35-1
ii  libnss3    2:3.87.1-1
ii  libopenh264-7  2.3.1+dfsg-3
ii  libopenjp2-7   2.5.0-2
ii  libopus0   1.3.1-3
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpng16-16    1.6.39-2
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsnappy1v5   1.1.9-3
ii  libstdc++6 12.2.0-14
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.4-2+deb12u2
ii  libxcb1    1.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage1    1:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml2    2.9.14+dfsg-1.3~deb12u1
ii  libxnvctrl0    525.85.05-3~deb12u1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages chr

Bug#1063161:

[Diederik de Haas]

On Thursday, 23 May 2024 17:33:47 CEST Vincent Blut wrote:
> We are just lacking a configuration symbol. Diederik, starting with
> linux 6.8 AMD PMF requires TEE. Do you want me to send a MR?

Sure.
Bit surprised it wouldn't be automatically selected though.

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

Bug#966570: RFP: libamf -- Advanced Media Framework (AMF) SDK

[Diederik de Haas]

On 30 Jul 2020 16:00:44 -0400 Louis-Philippe Véronneau  
wrote:
> I'm happy to help or sponsor work for this, but I'm not confident I
> understand the codebase enough to be packaging this myself.

There has been a reply to this, but it didn't directly To/CC you, so I'm 
replying to make sure you're at least aware of it.

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

Bug#1071666: ffmpeg: autopkgtest failure with ffmpeg 7.0

[Diederik de Haas]

Package: ffmpeg
Version: 7:7.0-1+b1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The autopkgtest job [1] fails with ffmpeg 7.0 with the following error:
"no single success: something is definitely wrong"

AFAICT this is caused by an extra column in the ``ffmpeg -format``
command which results in an empty "muxers" list, which in turn causes
it to skip all the tests.
If I apply the attached patch then the muxers list is no longer empty
and then it does run all the tests.
There's still a failure though [2], but now it's only one test
that fails:

```
Test 674:
trying muxer 'nut' with 'a' encoder 'adpcm_ima_wav' for codec 'adpcm_ima_wav'
ffmpeg -threads 2 -f lavfi -i sine=d=0.1 -strict -2 -c:a adpcm_ima_wav -f nut 
/tmp/autopkgtest-lxc.uwh7i80y/downtmp/autopkgtest_tmp/test/adpcm_ima_wav.nut -y 
-hide_banner -nostdin
Input #0, lavfi, from 'sine=d=0.1':
  Duration: N/A, start: 0.00, bitrate: 705 kb/s
  Stream #0:0: Audio: pcm_s16le, 44100 Hz, mono, s16, 705 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (pcm_s16le (native) -> adpcm_ima_wav (native))
Output #0, nut, to 
'/tmp/autopkgtest-lxc.uwh7i80y/downtmp/autopkgtest_tmp/test/adpcm_ima_wav.nut':
  Metadata:
encoder : Lavf61.1.100
  Stream #0:0: Audio: adpcm_ima_wav ([17][0][0][0] / 0x0011), 44100 Hz, mono, 
s16p, 176 kb/s
  Metadata:
encoder : Lavc61.3.100 adpcm_ima_wav
[out#0/nut @ 0x556381aa17c0] video:0KiB audio:3KiB subtitle:0KiB other 
streams:0KiB global headers:0KiB muxing overhead: 9.700521%
size=   3KiB time=00:00:00.10 bitrate= 269.6kbits/s speed=46.9x
FAILED: nut;a=adpcm_ima_wav; probing failed: 1
```

There are also several "SUCCESS" test which mention "streamcopying fails".
I don't know if that's expected though.

I don't know if the patch is correct (so didn't tag it as such) and it's
certainly incomplete as there's still a failure. I didn't look into why
that was though.
Hopefully it does help find a proper/complete fix for autopkgtest.

Cheers,
  Diederik

[1] https://salsa.debian.org/diederik/ffmpeg/-/jobs/5762517
[2] https://salsa.debian.org/diederik/ffmpeg/-/jobs/5762735


- -- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages ffmpeg depends on:
ii  libavcodec-extra61 [libavcodec61]7:7.0-1+b1
ii  libavdevice617:7.0-1+b1
ii  libavfilter107:7.0-1+b1
ii  libavformat-extra61 [libavformat61]  7:7.0-1+b1
ii  libavutil59  7:7.0-1+b1
ii  libc62.38-11
ii  libplacebo3386.338.2-2
ii  libpostproc587:7.0-1+b1
ii  libsdl2-2.0-02.30.2+dfsg-1
ii  libswresample5   7:7.0-1+b1
ii  libswscale8  7:7.0-1+b1

ffmpeg recommends no packages.

Versions of packages ffmpeg suggests:
pn  ffmpeg-doc  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZk84QQAKCRDXblvOeH7b
bvVIAQDA4LvXWWAPSZQwaqZlylM725y7ufLDUipcQjCdeAPB2wEAkt24mkzhrX4a
k4j1ha90YnCJ4osRP4cQB7zVM9NgPAE=
=T+qu
-END PGP SIGNATURE-
>From 7a9c17ed2508f9f4a3ac8e8fc104e1da07335935 Mon Sep 17 00:00:00 2001
From: Diederik de Haas 
Date: Thu, 23 May 2024 12:08:28 +0200
Subject: [PATCH] d/tests: Update list_formats for extra output column in
 ffmpeg 7.0

The ``ffmpeg -formats`` command got an extra output column.

``ffmpeg -formats`` output header for ffmpeg 6.1:
```
File formats:
 D. = Demuxing supported
 .E = Muxing supported
```

``ffmpeg -formats`` output header for ffmpeg 7.0:
```
Formats:
 D.. = Demuxing supported
 .E. = Muxing supported
 ..d = Is a device
```

This caused problems with the ``sed`` statement and caused the list of
muxers to be empty, which caused the autopkgtests to fail.

Fix the ``sed`` statement in the ``list_formats`` function so that the
list of muxers is no longer empty.
---
 debian/tests/encdec | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/tests/encdec b/debian/tests/encdec
index 377bd70d..97588833 100755
--- a/debian/tests/encdec
+++ b/debian/tests/encdec
@@ -160,7 +160,7 @@ list_formats() {
 # Get the raw list
 lines=$(ffmpeg -hide_banner -formats | grep "^ $match")
 for line in $lines; do
-item=$(echo "$line" | sed "s/^ [D ][E ] \([^ ]*\) .*/\1/")
+item=$(echo "$line" | sed "s/^ [D ][E ][d ] \([^ ]*\) .*/\1/")
 item=${item%%,*}
 echo "$item"
 done
-- 
2.45.1

Bug#1071662: chromium: Wrapper script does not correctly pass arguments to Chromium

[Remco de Man]

Package: chromium
Version: 125.0.6422.76-1~deb12u1
Severity: normal

Dear Maintainer,

When running 125.0.6422.76-1~deb12u1, when passing arguments to the chromium 
wrapper script included in the Debian package, not all arguments are passed
correctly to the Chromium binary.

This happens especially when the arguments need any type of quoting, like
in the case of passing a custom User-Agent with --user-agent.

A minimal reproduction sample for me is running the following command:

chromium --headless --no-sandbox --user-agent="Mozilla/5.0 (Macintosh; Intel 
Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2227.1 
Safari/537.36"

It seems that because the user agent contains spaces, this is not correctly
passed to the chromium binary. The regression was not present in the previous
security release, 125.0.6422.60-1~deb12u1, and seems to be caused by change
https://salsa.debian.org/chromium-team/chromium/-/commit/dc792dc4f3bfdd3e00f5fe7b7bf314077ed301bb

Because of this, many of our headless usage scenarios do not work correctly
anymore, since Chromium exits with the 'Multiple targets are not supported'
message, because it parses some of the user agent as seperate arguments to
its binary.

Seems like the wrapper script should be patched to handle this scenario,
or the change should be reverted.

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

Kernel: Linux 6.1.82 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages chromium depends on:
ii  chromium-common125.0.6422.76-1~deb12u1
ii  libasound2 1.2.8-1+b1
ii  libatk-bridge2.0-0 2.46.0-5
ii  libatk1.0-02.46.0-5
ii  libatomic1 12.2.0-14
ii  libatspi2.0-0  2.46.0-5
ii  libc6  2.36-9+deb12u7
ii  libcairo2  1.16.0-7
ii  libcups2   2.4.2-3+deb12u5
ii  libdav1d6  1.0.0-2+deb12u1
ii  libdbus-1-31.14.10-1~deb12u1
ii  libdouble-conversion3  3.2.1-1
ii  libdrm22.4.114-1+b1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libexpat1  2.5.0-1
ii  libflac12  1.4.2+ds-2
ii  libfontconfig1 2.14.1-4
ii  libfreetype6   2.12.1+dfsg-5
ii  libgbm122.3.6-1+deb12u1
ii  libgcc-s1  12.2.0-14
ii  libglib2.0-0   2.74.6-2+deb12u2
ii  libgtk-3-0 3.24.38-2~deb12u1
ii  libharfbuzz-subset06.0.0+dfsg-3
ii  libharfbuzz0b  6.0.0+dfsg-3
ii  libjpeg62-turbo1:2.1.5-2
ii  libjsoncpp25   1.9.5-4
ii  liblcms2-2 2.14-2
ii  libminizip11.1-8+deb12u1
ii  libnspr4   2:4.35-1
ii  libnss32:3.87.1-1
ii  libopenh264-7  2.3.1+dfsg-3
ii  libopenjp2-7   2.5.0-2
ii  libopus0   1.3.1-3
ii  libpango-1.0-0 1.50.12+ds-1
ii  libpng16-161.6.39-2
ii  libpulse0  16.1+dfsg1-2+b1
ii  libsnappy1v5   1.1.9-3
ii  libstdc++6 12.2.0-14
ii  libwoff1   1.0.2-2
ii  libx11-6   2:1.8.4-2+deb12u2
ii  libxcb11.15-1
ii  libxcomposite1 1:0.4.5-1
ii  libxdamage11:1.1.6-1
ii  libxext6   2:1.3.4-1+b1
ii  libxfixes3 1:6.0.0-2
ii  libxkbcommon0  1.5.0-1
ii  libxml22.9.14+dfsg-1.3~deb12u1
ii  libxnvctrl0525.85.05-3~deb12u1
ii  libxrandr2 2:1.5.2-2+b1
ii  libxslt1.1 1.1.35-1
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  125.0.6422.76-1~deb12u1

Versions of packages chromium suggests:
ii  chromium-driver  125.0.6422.76-1~deb12u1
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6 2.36-9+deb12u7
ii  libdrm2   2.4.114-1+b1
ii  libjsoncpp25  1.9.5-4
ii  libstdc++612.2.0-14
ii  libx11-6  2:1.8.4-2+deb12u2
ii  libxnvctrl0   525.85.05-3~deb12u1
ii  x11-utils 7.7+5
ii  xdg-utils 1.1.3-4.1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages chromium-common recommends:
ii  chromium-sandbox   125.0.6422.76-1~deb12u1
pn  fonts-liberation   
ii  libgl1-mesa-dri22.3.6-1+deb12u1
pn  notification-daemon
pn  system-config-printer  
pn  udev   
pn  upower 

Versions of packages chromium-driver depends on:
ii  libatomic1 12.2.0-14
ii  libc6  2.36-9+deb12u7
ii  libdouble-conversion3  3.2.1-1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libglib2.0-0   2.74.6-2+deb12u2
ii  libjsoncpp25   1.9.5-4
ii  libminizip11.1-8+deb12u1
ii  libnspr4   2:4.35-1
ii  

Bug#1071258: linux-image-6.1.0-21-amd64: Mouse, trackpad, keyboard behave inconsistently

[Diederik de Haas]

On Thursday, 23 May 2024 09:59:52 CEST Eduardo Casais wrote:
> 4) Determining whether the bug was introduced by the passage from kernel
> 5.10.0 to 6.1.0, or whether it was an error introduced between releases
> of image 6.1.0-*.
> 
> Attempted resolution:
> 
> I looked at the image versions available in Synaptic, installed the
> oldest one available: linux-image-6.1.0-11-amd64, and restarted the system.
> 
> Result:
> 
> The problem occurs again. I did not try installing other images between
> 6.1.10-11 and 6.1.10-21.
> 
> At this stage, I must leave it to you to investigate and suggest further
> operations that may help diagnose the problem and ferret out the bug.

Via https://snapshot.debian.org/package/linux-signed-amd64/ you can find deb 
packages for all the versions released to Debian which includes kernels older 
then 6.1.10-11. With that you can find the latest version that still works and 
the next version where this bug occurs.

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

Bug#1071559: linux-headers-6.8.9-amd64: error creating r8125 module with dkms

[Diederik de Haas]

Control: reassign -1 r8125-dkms

On Tuesday, 21 May 2024 10:41:54 CEST Pierpaolo Toniolo wrote:
> Was installing the linux-image-6.8.9-amd64 and it's fellow linux-
> headers-6.8.9-headers.
> At modules creation with dkms I got an error building module r8125 (package
> r8125-dkms)

Which is a problem of r8125-dkms, thus reassigning

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

Bug#1071501: linux-image-6.1.0-21-arm64: Linux NFS client hangs in nfs4_lookup_revalidate

[Diederik de Haas]

On Monday, 20 May 2024 21:07:49 CEST Salvatore Bonaccorso wrote:
> - I did read you cannot trigger with 5.15. If you build 6.1.90 from
>   upstream without Debian patches I assume you can trigger the issue
>   likewise? If so could you bisect the changes introducing the issue?

If the test with the upstream 6.1.90 version also has this problem, there's 
another (series of) test(s) worth doing, which could shorten the bisect 
operation significantly.

I got the impression that you have only tried it with version 6.1.90.
Have you tried it with earlier versions in the 6.1 series to see if the issue 
is present there? 

Via https://snapshot.debian.org/package/linux-signed-arm64/ you can find 
earlier versions from the 6.1 series already compiled and packaged.
To take version 6.1.52 as (random) example:
- click on the ``6.1.52+1`` link
- In the ``Binary packages`` list, click on the linux-image-6.1.0-X-arm64 
link, where 'X' is 12 in this case
- Click the ``linux-image-6.1.0-12-arm64_6.1.52-1_arm64.deb`` link to download 
the deb file which you can then install as root or with sudo by executing
``apt install ./linux-image-_arm64.deb``

If the problem does NOT occur with 6.1.52-1, then you try a higher version. 
Continue that process until you've found the latest version that works and the 
earliest version where it stopped working.

If the problem also occurs with 6.1.52-1, then you try an (even) older 
version.

This is to test whether it was a regression *within* the 6.1 series and if so, 
to get the narrowest range without having to compile yourself.

HTH

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

Bug#1071522: ITP: paping -- Test network connection between two hosts

[Rony Joao de Sousa]

Package: wnpp
Severity: wishlist
Owner: Rony Joao de Sousa 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: paping
  Version : 1.6.0
  Upstream Contact: Mike Lovell 
* URL : https://github.com/ronyjdesousa/paping
* License : MIT
  Programming Lang: C++
  Description : Test network connection between two hosts

 Paping is an tool designed to monitor the availability of a TCP/IP network
 connection between two points using TCP protocol.
 .
 It offers a straightforward approach to checking if a server is
 reachable and responsive on a specific port. Paping enables real-time
 monitoring of server status, aiding in the prompt detection of
 connectivity issues.
 .
 Paping alike to Ping, but in TCP level, targeting specific ports TCP.
 Both network diagnostic tools used to test the reachability of a host.
 Here are their key similarities:
 .
 Purpose: Both tools are used to check the availability and responsiveness
 of network connections.
 Functionality: They send packets to a specified address and wait for
 a response, measuring the round-trip time.
 Output: Both provide feedback on the success or failure of the packets sent,
 including response times.
 Usage: Both can be used to diagnose network issues and ensure that a host
 is reachable over the network.
 .
 Paping is also an excellent tool for learning TCP/IP. However, this
 program does not support UDP connections and IPv6.

Bug#1071516: ITP: libhash-wrap-perl -- Perl module that provides a simple way to create object-oriented interfaces to hash references

[Lincoln Yuji de Oliveira]

Package: wnpp
Owner: Lincoln Yuji ,
   Luiza Soezima ,
   Sabrina Araujo 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libhash-wrap-perl
  Version : 1.03
  Upstream Author : Diab Jerius 
* URL : https://metacpan.org/release/Hash-Wrap
* License : GPL-3
  Programming Lang: Perl
  Description : Hash::Wrap is a perl module that provides a simple way
to create object-oriented interfaces to hash references, wrapping them in
an object and allowing the use of method calls to interact with the hash's
keys and values.

This makes codes that deal with complex data structures more readable and
easier to manage.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1071184: Kernel 6.6 and 6.7 route-leak between VRF and default leads to Time to live exceeded

[Diederik de Haas]

On Friday, 17 May 2024 15:08:17 CEST Development EasyNet wrote:
> I will try. Meanwhile I was troubleshooting this issue for some time and
> I notice a change in FRRouting between 9.1 and 10.0.
> Before 10.0 FRRouting was installing the routes in kernel using the
> destination interface of the route. Starting from 10.0 FRRouting is
> installing all routes towards the VRF interface.
> 
> Here is my bug reported on FRRouting:
> https://github.com/FRRouting/frr/issues/15909

I have no (particular) knowledge about kernel routing or FRRouting, so I can't 
help with that aspect. But if the problem is resolved with 6.8.9, then that 
seems the easiest solution and means the underlying issue is fixed.
If not, it's useful to know if there is a(n older) kernel version where it 
does work.

But given there's also a FRR 9.x -> 10.x upgrade at play, I'm not so sure the 
problem is actually in the kernel.

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

Bug#1071184: Kernel 6.6 and 6.7 route-leak between VRF and default leads to Time to live exceeded

[Diederik de Haas]

Control: tag -1 moreinfo

On 15 May 2024 16:08:27 +0200 Development EasyNet  wrote:
> Package: linux-image
> Version: 6.6.15-2 and 6.7.12-1
> 
> I'm facing for some time a strange behavior of the route-leak. It happen 
> on both IPv4 and IPv6.
> Configuration used: Debian Trixie, Kernel 6.7.12 with FRRouting 10.1 - git
> VRF: internet
> Default: just local management

Sid recently got a 6.8.9 kernel, can you test whether that fixes the issue?

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

Bug#1071263: linux-image-6.8.9-amd64: Vulkan applications crash on computers using amdgpu

[Diederik de Haas]

Control: forwarded -1 https://gitlab.freedesktop.org/drm/amd/-/issues/3343



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

Bug#1069077: rockpro64: multiple kernel oops and frequent boot failures

[Diederik de Haas]

On Friday, 17 May 2024 03:36:35 CEST Forest wrote:
> A git bisect reveals it to be fixed by this commit:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=
> f7a59018953910032231c0a019208c4b0a4a8bc3
> > maple_tree: make mas_erase() more robust
> > 
> > mas_erase() may not deal correctly with all maple states.  Make the
> > function more robust by ensuring the state is in one of the two acceptable
> > states.

Kernel 6.8.9 has recently been uploaded to Unstable which has that commit.
Can you verify that it indeed fixes this bug?

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

Bug#1071015: RFS: color-picker/1.0.3-3 -- Powerful screen color picker based on Qt

[Hugo Torres de Lima]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "color-picker":

 * Package name : color-picker
   Version  : 1.0.3-3
   Upstream contact : https://github.com/keshavbhatt/ColorPicker/issues
 * URL  : https://github.com/keshavbhatt/ColorPicker
 * License  : MIT
 * Vcs  : https://salsa.debian.org/debian/colorpicker
   Section  : graphics

The source builds the following binary packages:

  color-picker - Powerful screen color picker based on Qt

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/color-picker/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/c/color-picker/color-picker_1.0.3-3.dsc

Changes since the last upload:

 color-picker (1.0.3-3) unstable; urgency=medium
 .
   * debian/control: bumped Standards-Version to 4.7.0.
   * debian/copyright: Updated dates.
   * debian/patches/01-segfaults.patch:
   - Created. Thanks to Sudip Mukherjee (Closes: #1060003)

Regards,
--
  Hugo Torres de Lima

Bug#1070907: python-stdnum: please drop the suggests on SimpleSoap

[Arthur de Jong]

On Sat, 2024-05-11 at 14:26 +0200, Alexandre Detiste wrote:
> Please drop the suggests on python3-pysimplesoap;
> this package would soon be dropped from Debian
> altogheter.

The next upload will drop the suggest (which already was a fallback for
zeep).

Thanks,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



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

Bug#1070713: how-can-i-help: undefined local variable or method autorm_header_done

[Diederik de Haas]

Control: severity -1 grave

On 07 May 2024 19:35:30 +0200 Nicolas Noirbent  wrote:
> Package: how-can-i-help
> Version: 18
> Severity: important
> Tags: patch
> 
> Running how-can-i-help outputs nothing past the initial banner, due to an
> undefined variable:

Which makes the package unusable, so upgrading severity accordingly

> ```
> /usr/bin/how-can-i-help:338:in `': undefined local variable or method 
`autorm_header_done' for main:Object (NameError)
> 
> autorm_header_done == 0
> ^^
> Did you mean?  autorm_date
> ```

Can confirm that error message

> Looking at the code following it, this should probably be:
> 
> ```
> autorm_header_done = 0
> ```

Can confirm that that made it work (properly) again.

Thanks!

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

Bug#1070367: linux-image-6.7.12-amd64: No WiFi

[Diederik de Haas]

Control: merge -1 1070353

On Saturday, 4 May 2024 16:56:10 CEST Kurt Meyer wrote:
> Package: src:linux
> Version: 6.7.12-1
> Severity: important
> 
> * What led up to the situation?
> 
> Booting with the linux-image-6.7.12-amd64 kernel results in Wi-Fi not
> working and Wi-Fi isn't even an option under network-manager. This issue
> also manifested when I attempted to boot using the linux-image-6.6.15-amd64
> kernel, so the issue may have started with that kernel.

This seems the exact same bug as 1070353, thus merging

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

Bug#1053995: Info received (ITP: fastfetch -- like neofetch, but much faster because written in C)

[Hiago De Franco]

Hello,

On Wed, Nov 15, 2023 at 02:12:00AM +, Li Carter wrote:
> Friendly ping
>

As discussed on 
https://github.com/fastfetch-cli/fastfetch/issues/533#issuecomment-2094282467
I will be taking this bug to work on it. 

> > 2023年10月16日 14:39，Debian Bug Tracking System  写道：
> > 
> > Thank you for the additional information you have supplied regarding
> > this Bug report.
> > 
> > This is an automatically generated reply to let you know your message
> > has been received.
> > 
> > Your message is being forwarded to the package maintainers and other
> > interested parties for their attention; they will reply in due course.
> > 
> > Your message has been sent to the package maintainer(s):
> > w...@debian.org
> > 
> > If you wish to submit further information on this problem, please
> > send it to 1053...@bugs.debian.org.
> > 
> > Please do not send mail to ow...@bugs.debian.org unless you wish
> > to report a problem with the Bug-tracking system.
> > 
> > -- 
> > 1053995: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053995
> > Debian Bug Tracking System
> > Contact ow...@bugs.debian.org with problems
>

Regards,
Hiago.

Bug#1068082: bullseye-pu: package intel-microcode/3.20240312.1~deb11u1

[Henrique de Moraes Holschuh]

On Mon, Apr 22, 2024, at 13:58, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
>
> On Sat, Mar 30, 2024 at 07:50:45AM -0300, Henrique de Moraes Holschuh wrote:
>> As requested by the security team, I would like to bring the microcode
>> update level for Intel processors in Bullseye and Bookworm to match what
>> we have in Sid and Trixie.  This is the bug report for Bullseye, a
>> separate one will be filled for Bookmorm.
>
> Please go ahead.

Uploaded!

Thank you!

-- 
  Henrique de Moraes Holschuh 

Bug#1069870: linux-image-6.7.7-686-pae: please enable i915 mtl_* firmware

[Diederik de Haas]

Control: reassign -1 src:firmware-nonfree 20230625-2

On Friday, 26 April 2024 07:36:16 CEST Martin-Éric Racine wrote:
> Package: src:linux
> Version: 6.7.7-1
> Severity: normal
> 
> W: Possible missing firmware /lib/firmware/i915/mtl_gsc_1.bin for module
> i915 W: Possible missing firmware /lib/firmware/i915/mtl_huc_gsc.bin for
> module i915 W: Possible missing firmware /lib/firmware/i915/mtl_guc_70.bin
> for module i915

Should be fixed when firmware-nonfree version 20230919 is released

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

Bug#1068365: FTBFS on mips64el in lsfd/mkfds-multiplexing-pselect6 test et al

[Diederik de Haas]

Control: forwarded -1 https://github.com/util-linux/util-linux/issues/2867 
https://lore.kernel.org/all/20240328-mips_save_syscall-v1-1-9e1d62d69...@flygoat.com/

On Thursday, 25 April 2024 22:10:12 CEST Chris Hofstaedtler wrote:
> reassign 1068365 src:linux
> affects 1068365 src:util-linux
> thanks

It's already marked as 'upstream' and 'fixed-upstream', so the tags are fine.

Upstream commit 4370b673ccf240bf7587b0cb8e6726a5ccaf1f17 titled
"MIPS: scall: Save thread_info.syscall unconditionally on entry"

That commit is part of 6.9-rc4 and autoselected for 6.8, 6.1 and 5.10
on 2024-04-22 by Sasha Levin, but I haven't seen them in their
respective Stable queues yet?


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

Bug#1069301: linux-image-6.1.0-20-amd64: bluetooth causes kernel BUG - list_del corruption, (address)->prev is LIST_POISON2

[Diederik de Haas]

Control: tag -1 -moreinfo +upstream
Control: forwarded -1 
https://lore.kernel.org/linux-bluetooth/CADRbXaDqx6S+7tzdDPPEpRu9eDLrHQkqoWTTGfKJSRxY=ht...@mail.gmail.com/

On Monday, 22 April 2024 10:32:00 CEST Jeremy Lainé wrote:
> Over the weekend I reported the issue to the linux-bluetooth mailing
> list, which led to bisecting the issue down to a single commit:
> 
> https://lore.kernel.org/linux-bluetooth/CADRbXaDqx6S+7tzdDPPEpRu9eDLrHQkqoWT
> TGfKJSRxY=ht...@mail.gmail.com/

Nice work :)

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

Bug#1069082: linux-image-6.1.0-20-amd64: USB ethernet AX88179 device name eth0

[Diederik de Haas]

On Tuesday, 16 April 2024 16:41:46 CEST Roland Rosenfeld wrote:
> A.B says on stackexchange, that both patches have to be reverted to
> make this working again.
> 
> I did not yet try this out myself, because I use precompiled kernels
> for ages and have to re-learn again how to patch and build a kernel.

https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
describes a procedure with which you can apply (the attached) patches

HTH>From 21f7e476d0afe832f6656b917b976c6efe6b24f3 Mon Sep 17 00:00:00 2001
From: Diederik de Haas 
Date: Tue, 16 Apr 2024 16:53:16 +0200
Subject: [PATCH 1/2] Revert "net: usb: ax88179_178a: avoid the interface
 always configured as random address"

This reverts commit fc77240f6316d17fc58a8881927c3732b1d75d51.
---
 drivers/net/usb/ax88179_178a.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index e0e9b4c53cb0..d837c1887416 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1273,8 +1273,6 @@ static void ax88179_get_mac_addr(struct usbnet *dev)
 
 	if (is_valid_ether_addr(mac)) {
 		eth_hw_addr_set(dev->net, mac);
-		if (!is_local_ether_addr(mac))
-			dev->net->addr_assign_type = NET_ADDR_PERM;
 	} else {
 		netdev_info(dev->net, "invalid MAC address, using random\n");
 		eth_hw_addr_random(dev->net);
-- 
2.43.0

>From 75b1a1f4d80ca93591e7833c0683a651d54edc38 Mon Sep 17 00:00:00 2001
From: Diederik de Haas 
Date: Tue, 16 Apr 2024 16:53:36 +0200
Subject: [PATCH 2/2] Revert "net: usb: ax88179_178a: avoid two consecutive
 device resets"

This reverts commit 5c4cbec5106d2f3c055ad138165e60a73f5b355c.
---
 drivers/net/usb/ax88179_178a.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index d837c1887416..5a1bf42ce156 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1315,6 +1315,8 @@ static int ax88179_bind(struct usbnet *dev, struct usb_interface *intf)
 
 	netif_set_tso_max_size(dev->net, 16384);
 
+	ax88179_reset(dev);
+
 	return 0;
 }
 
-- 
2.43.0



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

Bug#1069077: es8316 driver causes kernel oops / panic on rockpro64

[Diederik de Haas]

Control: retitle -1 es8316 driver causes kernel oops / panic on rockpro64

On Tuesday, 16 April 2024 01:37:57 CEST Forest wrote:
> The current debian unstable kernel causes a variety of failures that are not
> present in the bookworm kernel, on the RockPro64 single board computer.
> (This is an arm64 machine built upon the Rockchip rk3399 SoC.)

On Tuesday, 16 April 2024 05:21:13 CEST Forest wrote:
> Blacklisting the snd_soc_es8316 module in /etc/modprobe.d seems to restore
> kernel stability, as far as I have seen from half a dozen reboots.

Can you try the Debian Testing kernel, which is at version 6.6.15?

If the 6.6.15 kernel does work properly, then the 3 commits for
the es8316 driver in kernel 6.7 are the most likely suspects:
869f30782cda ASoC: es8316: Enable support for MCLK div by 2
a43c0dc1004c ASoC: es8316: Replace NR_SUPPORTED_MCLK_LRCK_RATIOS with 
ARRAY_SIZE()
2f06f231f0bf ASoC: es8316: Enable support for S32 LE format

Attached you'll find 3 patches which revert those commits.
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4
describes a procedure with which you can apply patches to the
(6.7) kernel. If that makes the 6.7 kernel work properly again, we
likely have found the culprit for the kernel oops/panic.

Can you first try the Testing (6.6.15) kernel and if that works try
applying the attached patches to the 6.7 kernel?>From 407672343a738ede6f5e955e3afa57d16b37f4e6 Mon Sep 17 00:00:00 2001
From: Diederik de Haas 
Date: Tue, 16 Apr 2024 10:24:39 +0200
Subject: [PATCH 1/3] Revert "ASoC: es8316: Enable support for MCLK div by 2"

This reverts commit 869f30782cdad0a86598a700a864e4a2bf44f8cc.
---
 sound/soc/codecs/es8316.c | 45 ++-
 sound/soc/codecs/es8316.h |  3 ---
 2 files changed, 11 insertions(+), 37 deletions(-)

diff --git a/sound/soc/codecs/es8316.c b/sound/soc/codecs/es8316.c
index e53b2856d625..a1c3e10c3cf1 100644
--- a/sound/soc/codecs/es8316.c
+++ b/sound/soc/codecs/es8316.c
@@ -469,42 +469,19 @@ static int es8316_pcm_hw_params(struct snd_pcm_substream *substream,
 	u8 bclk_divider;
 	u16 lrck_divider;
 	int i;
-	unsigned int clk = es8316->sysclk / 2;
-	bool clk_valid = false;
-
-	/* We will start with halved sysclk and see if we can use it
-	 * for proper clocking. This is to minimise the risk of running
-	 * the CODEC with a too high frequency. We have an SKU where
-	 * the sysclk frequency is 48Mhz and this causes the sound to be
-	 * sped up. If we can run with a halved sysclk, we will use it,
-	 * if we can't use it, then full sysclk will be used.
-	 */
-	do {
-		/* Validate supported sample rates that are autodetected from MCLK */
-		for (i = 0; i < ARRAY_SIZE(supported_mclk_lrck_ratios); i++) {
-			const unsigned int ratio = supported_mclk_lrck_ratios[i];
-
-			if (clk % ratio != 0)
-continue;
-			if (clk / ratio == params_rate(params))
-break;
-		}
-		if (i == ARRAY_SIZE(supported_mclk_lrck_ratios)) {
-			if (clk == es8316->sysclk)
-return -EINVAL;
-			clk = es8316->sysclk;
-		} else {
-			clk_valid = true;
-		}
-	} while (!clk_valid);
 
-	if (clk != es8316->sysclk) {
-		snd_soc_component_update_bits(component, ES8316_CLKMGR_CLKSW,
-	  ES8316_CLKMGR_CLKSW_MCLK_DIV,
-	  ES8316_CLKMGR_CLKSW_MCLK_DIV);
-	}
+	/* Validate supported sample rates that are autodetected from MCLK */
+	for (i = 0; i < ARRAY_SIZE(supported_mclk_lrck_ratios); i++) {
+		const unsigned int ratio = supported_mclk_lrck_ratios[i];
 
-	lrck_divider = clk / params_rate(params);
+		if (es8316->sysclk % ratio != 0)
+			continue;
+		if (es8316->sysclk / ratio == params_rate(params))
+			break;
+	}
+	if (i == ARRAY_SIZE(supported_mclk_lrck_ratios))
+		return -EINVAL;
+	lrck_divider = es8316->sysclk / params_rate(params);
 	bclk_divider = lrck_divider / 4;
 	switch (params_format(params)) {
 	case SNDRV_PCM_FORMAT_S16_LE:
diff --git a/sound/soc/codecs/es8316.h b/sound/soc/codecs/es8316.h
index 0ff16f948690..c335138e2837 100644
--- a/sound/soc/codecs/es8316.h
+++ b/sound/soc/codecs/es8316.h
@@ -129,7 +129,4 @@
 #define ES8316_GPIO_FLAG_GM_NOT_SHORTED		0x02
 #define ES8316_GPIO_FLAG_HP_NOT_INSERTED	0x04
 
-/* ES8316_CLKMGR_CLKSW */
-#define ES8316_CLKMGR_CLKSW_MCLK_DIV	0x80
-
 #endif
-- 
2.43.0

>From c309d8cf7e3c192683beacb3781458a2f8bfef81 Mon Sep 17 00:00:00 2001
From: Diederik de Haas 
Date: Tue, 16 Apr 2024 10:24:55 +0200
Subject: [PATCH 2/3] Revert "ASoC: es8316: Replace
 NR_SUPPORTED_MCLK_LRCK_RATIOS with ARRAY_SIZE()"

This reverts commit a43c0dc1004cbe2edbae9b6e6793db71f6896449.
---
 sound/soc/codecs/es8316.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/es8316.c b/sound/soc/codecs/es8316.c
index a1c3e10c3cf1..09fc0b25f600 100644
--- a/sound/soc/codecs/es8316.c
+++ b/sound/soc/codecs/es8316.c
@@ -27,6 +27,7 @@
  * MCLK/LRCK ratios, but we also add ratio 400, which is commonly used on
  * In

Bug#1066398: xwayland: FTBFS: ./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/testfile.c:17:(.text+0x9): undefined reference to `SHA1Init'

[Diederik de Haas]

Control: forcemerge -1 1065184

On Saturday, 13 April 2024 16:32:04 CEST Andreas Metzler wrote:
> > If you agree, please merge these two bugs.
> > FTR: Bug #1065184 is already fixed in git.
> 
> FWIW I can cobnfirm that xwayland builds successfully if libtirpc-dev is
> installed.

Thanks, then I'm merging the bugs. Today a "release to sid" commit was made, 
so this bug will be closed/fixed real soon now.

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

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Diederik de Haas]

On Wednesday, 10 April 2024 15:32:02 CEST Cyril Brulebois wrote:
> Cyril Brulebois  (2024-04-10):
> > Salvatore Bonaccorso  (2024-04-10):
> > > On Tue, Apr 09, 2024 at 03:33:09PM +0200, Diederik de Haas wrote:
> > > > Does the problem go away if you revert the following commits on top of
> > > > -19?
> > > > 
> > > > db6338f45971b4285ea368432a84033690eaf53c
> > > > scsi: core: Move scsi_host_busy() out of host lock for waking up EH
> > > > handler
> > > > 
> > > > 1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
> > > > scsi: core: Move scsi_host_busy() out of host lock if it is for
> > > > per-command
> > > > 
> > > > cf33e6ca12d814e1be2263cb76960d0019d7fb94
> > > > scsi: core: Add struct for args to execution functions
> > 
> > Preparing that test right now, thanks Diederik.
> 
> This doesn't build, but I didn't try very hard:
> 
> /home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c: In function
> ‘sd_read_block_zero’:
> /home/kibi/debian-kernel/linux.git/drivers/scsi/sd.c:3300:9: error:
> implicit declaration of function ‘scsi_execute_cmd’; did you mean
> ‘scsi_execute_req’? [-Werror=implicit-function-declaration]

Then it got troublesome even earlier then I expected ;-)
If you do `gitk -- drivers/scsi/` on 'master', then you'll see a huge list of 
recent commits ... which probably didn't get backported all ...
A lot of them landed in 6.8.

That Salvatore could confirm the issue should help.

Good luck,
  Diederik

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

Bug#1068675: linux-image-6.1.0-19-amd64: loss of SMART information: Device is in SLEEP mode, exit(2)

[Diederik de Haas]

Hi Cyril,

On Tuesday, 9 April 2024 01:06:43 CEST Cyril Brulebois wrote:
> Upgrading from linux-image-6.1.0-18-amd64 to linux-image-6.1.0-19-amd64
> leads to losing some SMART information, at least as queried by munin (in
> Debian 12) when it comes to sensors.

Does the problem go away if you revert the following commits on top of -19?

db6338f45971b4285ea368432a84033690eaf53c
scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler

1ebd75cefaac6fd74729a7d3157f6eaa59960ae2
scsi: core: Move scsi_host_busy() out of host lock if it is for per-command

cf33e6ca12d814e1be2263cb76960d0019d7fb94
scsi: core: Add struct for args to execution functions

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

Bug#1068701: TypeError: cannot use a string pattern on a bytes-like object

[Timon de Groot]

Package: duplicity
Version: 0.8.22-1+b3
Severity: normal
X-Debbugs-Cc: timon.degr...@hypernode.com

Dear Maintainer,

   * What led up to the situation?
   We create write offsite backups to s3 with duply/duplicity. We run
   duplicity with the following params (from duply):
   --s3-european-buckets --s3-use-new-style --s3-multipart-chunk-size=25
   --s3-use-multiprocessing --s3-use-ia
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 When we run the duply backup, we get to see the error:
During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/duplicity/backends/_boto_multi.py", line 223, 
in _upload
mp.upload_part_from_file(fd, offset + 1, cb=_upload_callback,
  File "/usr/lib/python3/dist-packages/boto/s3/multipart.py", line 257, 
in upload_part_from_file
key.set_contents_from_file(fp, headers=headers, replace=replace,
  File "/usr/lib/python3/dist-packages/boto/s3/key.py", line 1307, in 
set_contents_from_file
self.send_file(fp, headers=headers, cb=cb, num_cb=num_cb,
  File "/usr/lib/python3/dist-packages/boto/s3/key.py", line 760, in 
send_file
self._send_file_internal(fp, headers=headers, cb=cb, num_cb=num_cb,
  File "/usr/lib/python3/dist-packages/boto/s3/key.py", line 932, in 
_send_file_internal
self.content_type = mimetypes.guess_type(self.path)[0]
^^^
  File "/usr/lib/python3.11/mimetypes.py", line 307, in guess_type
return _db.guess_type(url, strict)
   ^^^
  File "/usr/lib/python3.11/mimetypes.py", line 123, in guess_type
scheme, url = urllib.parse._splittype(url)
  
  File "/usr/lib/python3.11/urllib/parse.py", line 1038, in _splittype
match = _typeprog.match(url)

TypeError: cannot use a string pattern on a bytes-like object
Giving up after 5 attempts. BackendException: Multipart upload failed. 
Aborted.
   * What outcome did you expect instead?
   Duplicity to finish the backup and upload to S3, not crash

For your info/convenience, we repackaged bookworm duplicity in our own repo 
with this patch applied:
https://gitlab.com/duplicity/duplicity/-/merge_requests/99

Our repackaged duplicity: 
https://apt.hypernode.com/pool/hypernode/d/duplicity/duplicity_0.8.22-1%2Bhypernode1_amd64.deb

Upstream issue: https://gitlab.com/duplicity/duplicity/-/issues/126
Ubuntu also has related issue: 
https://bugs.launchpad.net/ubuntu/+source/duplicity/+bug/1908971


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

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

Versions of packages duplicity depends on:
ii  gnupg  2.2.40-1.1
ii  libc6  2.36-9+deb12u4
ii  librsync2  2.3.2-1+b1
ii  python33.11.2-1+b1
ii  python3-fasteners  0.17.3-2
ii  python3-future 0.18.2-6
ii  python3-lockfile   1:0.12.2-2.2
ii  python3.11 3.11.2-6

Versions of packages duplicity recommends:
ii  python3-oauthlib  3.2.2-1
ii  python3-paramiko  2.12.0-2
ii  python3-pexpect   4.8.0-4
ii  python3-urllib3   1.26.12-1
ii  rsync 3.2.7-1

Versions of packages duplicity suggests:
pn  lftp 
pn  ncftp
pn  par2 
pn  python3-boto 
ii  python3-pip  23.0.1+dfsg-1
pn  python3-swiftclient  
pn  tahoe-lafs   

-- no debconf information

Bug#1068631: linux-image-6.6.15-amd64: Using monitor refreshrate above 120Hz i get random black screen for a few seconds at certain actions

[Diederik de Haas]

Control: forcemerge -1 1054889

On Monday, 8 April 2024 10:44:12 CEST dada007 wrote:
>  I had an earlier report with this bug

No need to have 2 bugs for the same problem, thus merging

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

Bug#1057850: libnss-db: Uses db5.3, no replacement in sight

[Paulo Henrique de Lima Santana]

Hi Cris,

Would be possible reintroduce libnss-db to testing?

I'm asking because I'm maintainer of the pglistener package and I know 
there aren't plans to update the sofwtare with another database solution.


And now I can't have pglistener on testing.

Best regards,

On Sat, 09 Dec 2023 16:54:26 +0100 Chris Hofstaedtler  
wrote:

Source: libnss-db
Version: 2.2.3pre1-8
Severity: serious
Tags: upstream

libnss-db is the so-called "Berkeley DB NSS". It last saw upstream
changes in 2001, and obviously depends on Berkeley DB 5.3. We want to
get rid of Berkeley DB, and now is as good a time as any other to stop
shipping libnss-db.

Users can probably use any other NSS module that can use some form of
database backend.

After a while I intend to file an RM bug, too.

Chris




--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068249: linux-image-6.1.0-18-amd64: ax201 iwlwifi driver creates millions of 'Unhandled alg: 0x33f0707' messages

[Diederik de Haas]

Please always reply to the bug report (I'll see it then too)!

On woensdag 3 april 2024 22:01:20 CEST you wrote:
> Thanks, I am working on that, but it's not trivial
> 
> (1) About firmware
> 
> These are provided by debian and cause the problem
> -rw-r--r-- 1 root root 1299660 2023-05-01 21:30
> iwlwifi-QuZ-a0-hr-b0-59.ucode -rw-r--r-- 1 root root 1370356 2023-05-01
> 21:30 iwlwifi-QuZ-a0-hr-b0-72.ucode
> 
> I grabbed new fw from a TI git repo, but the debian kernel does not load any
> of them. Is fw signed? Do I need to sign it with my MOK?

Use the upstream repo to get the files. The files aren't signed.
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/

The `dmesg` command will tell you which firmware files it's trying to load.

Then DL that(/those) file(s) from the repo and put them in /lib/firmware/
Then on next boot the kernel will find them.

> -rw-r--r-- 1 root root 1369976 2024-04-03 21:24
> iwlwifi-QuZ-a0-hr-b0-73.ucode -rw-r--r-- 1 root root 1371668 2024-04-03
> 21:24 iwlwifi-QuZ-a0-hr-b0-74.ucode -rw-r--r-- 1 root root 1404184
> 2024-04-03 21:24 iwlwifi-QuZ-a0-hr-b0-77.ucode
> 
> (2) About kernel experiments, unfortunately it is a production server with
> samba-ad and ad replication. It uses btrfs and snapshots work great, but it
> needs some work (disable email services, make snapshots, stop all clients,
> testing, restore snapshots, reenable email, restart clients).
> 
> (3) Instead I will try first to use debian testing on a different NUC, but
> this will take some time.
> 
> 2. April 2024 20:28, "Diederik de Haas"  schrieb:
> > On Tuesday, 2 April 2024 19:54:41 CEST J. Pfennig wrote:
> >> Package: src:linux
> >> Version: 6.1.76-1
> >> Severity: important
> >> Tags: upstream
> > 
> > I am/was inclined to remove that tag, but the problem is likely caused by
> > firmware which is too old for the 'backported' patches that upstream
> > applied.> 
> >> The driver fills the eventlog with millions !!! of messages, see below.
> >> It otherwise works. The problem can be reproduced on different NUC
> >> systems.
> > 
> > If you downgrade the kernel version, does the issue then go away?
> > 
> >> ** Kernel log:
> >> [30911.569896] BTRFS info (device sda4): disk space caching is enabled
> >> [30974.905443] net_ratelimit: 67420 callbacks suppressed
> >> [30974.905457] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
> >> [30974.905728] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
> >> [30974.906036] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
> > 
> > https://unix.stackexchange.com/a/721474 looks related and the solution is
> > to upgrade the firmware to a newer version.
> > That isn't available on Stable, but grabbing ``firmware-iwlwifi`` from
> > Testing should be safe. Not sure if that version is new enough though.
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.gi
> > t
> > is the upstream repo and you could 'grab' the firmware files which `dmesg`
> > reports it can't find.
> > 
> >> -- System Information:
> >> Debian Release: 12.5
> >> APT prefers stable-security
> >> APT policy: (500, 'stable-security'), (500, 'stable')
> >> Architecture: amd64 (x86_64)
> >> 
> >> Versions of packages linux-image-6.1.0-18-amd64 is related to:
> >> ii firmware-amd-graphics 20230210-5
> >> pn firmware-atheros 
> >> pn firmware-bnx2 
> >> pn firmware-bnx2x 
> >> pn firmware-brcm80211 
> >> pn firmware-cavium 
> >> ii firmware-intel-sound 20230210-5
> >> pn firmware-intelwimax 
> >> pn firmware-ipw2x00 
> >> pn firmware-ivtv 
> >> ii firmware-iwlwifi 20230210-5
> > 
> > My guess is that those 'backported' patches expect newer firmware then
> > that.



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

Bug#1068084: bookworm-pu: package intel-microcode/3.20240312.1~deb12u1

[Henrique de Moraes Holschuh]

Uploaded.

On Mon, Apr 1, 2024, at 08:48, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
>
> On Sat, Mar 30, 2024 at 07:47:05AM -0300, Henrique de Moraes Holschuh wrote:
>> As requested by the security team, I would like to bring the microcode
>> update level for Intel processors in Bullseye and Bookworm to match what
>> we have in Sid and Trixie.  This is the bug report for Bookworm, a
>> separate one will be filled for Bullseye.
>
> Please go ahead.
>
> Thanks,
>
> -- 
> Jonathan Wiltshire  j...@debian.org
> Debian Developer http://people.debian.org/~jmw
>
> 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
> ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

-- 
  Henrique de Moraes Holschuh 

Bug#1068249: linux-image-6.1.0-18-amd64: ax201 iwlwifi driver creates millions of 'Unhandled alg: 0x33f0707' messages

[Diederik de Haas]

On Tuesday, 2 April 2024 19:54:41 CEST J. Pfennig wrote:
> Package: src:linux
> Version: 6.1.76-1
> Severity: important
> Tags: upstream

I am/was inclined to remove that tag, but the problem is likely caused by 
firmware which is too old for the 'backported' patches that upstream applied.

> The driver fills the eventlog with millions !!! of messages, see below.
> It otherwise works. The problem can be reproduced on different NUC systems.

If you downgrade the kernel version, does the issue then go away?

> ** Kernel log:
> [30911.569896] BTRFS info (device sda4): disk space caching is enabled
> [30974.905443] net_ratelimit: 67420 callbacks suppressed
> [30974.905457] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
> [30974.905728] iwlwifi :00:14.3: Unhandled alg: 0x33f0707
> [30974.906036] iwlwifi :00:14.3: Unhandled alg: 0x33f0707

https://unix.stackexchange.com/a/721474 looks related and the solution is to 
upgrade the firmware to a newer version.
That isn't available on Stable, but grabbing ``firmware-iwlwifi`` from Testing 
should be safe. Not sure if that version is new enough though.

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
is the upstream repo and you could 'grab' the firmware files which `dmesg` 
reports it can't find.

> -- System Information:
> Debian Release: 12.5
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Versions of packages linux-image-6.1.0-18-amd64 is related to:
> ii  firmware-amd-graphics 20230210-5
> pn  firmware-atheros  
> pn  firmware-bnx2 
> pn  firmware-bnx2x
> pn  firmware-brcm80211
> pn  firmware-cavium   
> ii  firmware-intel-sound  20230210-5
> pn  firmware-intelwimax   
> pn  firmware-ipw2x00  
> pn  firmware-ivtv 
> ii  firmware-iwlwifi  20230210-5

My guess is that those 'backported' patches expect newer firmware then that.

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

Bug#1068084: bookworm-pu: package intel-microcode/3.20240312.1~deb12u1

[Henrique de Moraes Holschuh]

ale register buffers.  Affects SGX as well.
+  Requires kernel update to be effective.
+- Mitigations for INTEL-SA-INTEL-SA-00960 (CVE-2023-22655), aka TECRA:
+  Protection mechanism failure in some 3rd and 4th Generation Intel Xeon
+  Processors when using Intel SGX or Intel TDX may allow a privileged
+  user to potentially enable escalation of privilege via local access.
+  NOTE: effective only when loaded by firmware.  Allows SMM firmware to
+  attack SGX/TDX.
+- Mitigations for INTEL-SA-INTEL-SA-01045 (CVE-2023-43490):
+  Incorrect calculation in microcode keying mechanism for some Intel
+  Xeon D Processors with Intel SGX may allow a privileged user to
+  potentially enable information disclosure via local access.
+  * Fixes for other unspecified functional issues on many processors
+  * Updated microcodes:
+sig 0x00050653, pf_mask 0x97, 2023-07-28, rev 0x1000191, size 36864
+sig 0x00050656, pf_mask 0xbf, 2023-07-28, rev 0x4003605, size 38912
+sig 0x00050657, pf_mask 0xbf, 2023-07-28, rev 0x5003605, size 37888
+sig 0x0005065b, pf_mask 0xbf, 2023-08-03, rev 0x7002802, size 30720
+sig 0x00050665, pf_mask 0x10, 2023-08-03, rev 0xe15, size 23552
+sig 0x000506f1, pf_mask 0x01, 2023-10-05, rev 0x003e, size 11264
+sig 0x000606a6, pf_mask 0x87, 2023-09-14, rev 0xd0003d1, size 307200
+sig 0x000606c1, pf_mask 0x10, 2023-12-05, rev 0x1000290, size 299008
+sig 0x000706a1, pf_mask 0x01, 2023-08-25, rev 0x0040, size 76800
+sig 0x000706a8, pf_mask 0x01, 2023-08-25, rev 0x0024, size 76800
+sig 0x000706e5, pf_mask 0x80, 2023-09-14, rev 0x00c4, size 114688
+sig 0x000806c1, pf_mask 0x80, 2023-09-13, rev 0x00b6, size 111616
+sig 0x000806c2, pf_mask 0xc2, 2023-09-13, rev 0x0036, size 98304
+sig 0x000806d1, pf_mask 0xc2, 2023-09-13, rev 0x0050, size 104448
+sig 0x000806ec, pf_mask 0x94, 2023-07-16, rev 0x00fa, size 106496
+sig 0x000806f8, pf_mask 0x87, 2024-01-03, rev 0x2b000590, size 579584
+sig 0x000806f7, pf_mask 0x87, 2024-01-03, rev 0x2b000590
+sig 0x000806f6, pf_mask 0x87, 2024-01-03, rev 0x2b000590
+sig 0x000806f5, pf_mask 0x87, 2024-01-03, rev 0x2b000590
+sig 0x000806f4, pf_mask 0x87, 2024-01-03, rev 0x2b000590
+sig 0x00090661, pf_mask 0x01, 2023-09-26, rev 0x0019, size 20480
+sig 0x00090672, pf_mask 0x07, 2023-09-19, rev 0x0034, size 224256
+sig 0x00090675, pf_mask 0x07, 2023-09-19, rev 0x0034
+sig 0x000b06f2, pf_mask 0x07, 2023-09-19, rev 0x0034
+sig 0x000b06f5, pf_mask 0x07, 2023-09-19, rev 0x0034
+sig 0x000906a3, pf_mask 0x80, 2023-09-19, rev 0x0432, size 08
+sig 0x000906a4, pf_mask 0x80, 2023-09-19, rev 0x0432
+sig 0x000906c0, pf_mask 0x01, 2023-09-26, rev 0x2426, size 20480
+sig 0x000906e9, pf_mask 0x2a, 2023-09-28, rev 0x00f8, size 108544
+sig 0x000906ea, pf_mask 0x22, 2023-07-26, rev 0x00f6, size 105472
+sig 0x000906ec, pf_mask 0x22, 2023-07-26, rev 0x00f6, size 106496
+sig 0x000906ed, pf_mask 0x22, 2023-07-27, rev 0x00fc, size 106496
+sig 0x000a0652, pf_mask 0x20, 2023-07-16, rev 0x00fa, size 97280
+sig 0x000a0653, pf_mask 0x22, 2023-07-16, rev 0x00fa, size 97280
+sig 0x000a0655, pf_mask 0x22, 2023-07-16, rev 0x00fa, size 97280
+sig 0x000a0660, pf_mask 0x80, 2023-07-16, rev 0x00fa, size 97280
+sig 0x000a0661, pf_mask 0x80, 2023-07-16, rev 0x00fa, size 96256
+sig 0x000a0671, pf_mask 0x02, 2023-09-14, rev 0x005e, size 108544
+sig 0x000b0671, pf_mask 0x32, 2023-12-14, rev 0x0122, size 215040
+sig 0x000b06a2, pf_mask 0xe0, 2023-12-07, rev 0x4121, size 220160
+sig 0x000b06a3, pf_mask 0xe0, 2023-12-07, rev 0x4121
+sig 0x000b06e0, pf_mask 0x11, 2023-09-25, rev 0x0015, size 138240
+  * New microcodes:
+sig 0x000a06a4, pf_mask 0xe6, 2024-01-03, rev 0x001c, size 136192
+sig 0x000b06a8, pf_mask 0xe0, 2023-12-07, rev 0x4121, size 220160
+sig 0x000c06f2, pf_mask 0x87, 2023-11-20, rev 0x21000200, size 549888
+sig 0x000c06f1, pf_mask 0x87, 2023-11-20, rev 0x21000200
+
 2023-11-14:
   * New upstream microcode datafile 20231114
 Mitigations for "reptar", INTEL-SA-00950 (CVE-2023-23583)
diff --git a/debian/changelog b/debian/changelog
index c2aeefe..f156f68 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,91 @@
+intel-microcode (3.20240312.1~deb12u1) bookworm; urgency=medium
+
+  * Build for bookworm (no changes)
+
+ -- Henrique de Moraes Holschuh   Sat, 30 Mar 2024 07:01:52 -0300
+
+intel-microcode (3.20240312.1) unstable; urgency=medium
+
+  * New upstream microcode datafile 20240312 (closes: #1066108)
+- Mitigations for INTEL-SA-INTEL-SA-00972 (CVE-2023-39368):
+  Protection mechanism failure of bus lock regulator for some Intel
+  Processors may allow an unauthenticated user to potentially enable
+  denial of service via network access.
+- Mitigations for INTEL-SA-INTEL-SA-00982 (CVE-2023-38575):
+  Non-transparent sharing of re

Bug#1068083: bullseye-pu: package intel-microcode/3.20240312.1~deb11u1

[Henrique de Moraes Holschuh]

ale register buffers.  Affects SGX as well.
+  Requires kernel update to be effective.
+- Mitigations for INTEL-SA-INTEL-SA-00960 (CVE-2023-22655), aka TECRA:
+  Protection mechanism failure in some 3rd and 4th Generation Intel Xeon
+  Processors when using Intel SGX or Intel TDX may allow a privileged
+  user to potentially enable escalation of privilege via local access.
+  NOTE: effective only when loaded by firmware.  Allows SMM firmware to
+  attack SGX/TDX.
+- Mitigations for INTEL-SA-INTEL-SA-01045 (CVE-2023-43490):
+  Incorrect calculation in microcode keying mechanism for some Intel
+  Xeon D Processors with Intel SGX may allow a privileged user to
+  potentially enable information disclosure via local access.
+  * Fixes for other unspecified functional issues on many processors
+  * Updated microcodes:
+sig 0x00050653, pf_mask 0x97, 2023-07-28, rev 0x1000191, size 36864
+sig 0x00050656, pf_mask 0xbf, 2023-07-28, rev 0x4003605, size 38912
+sig 0x00050657, pf_mask 0xbf, 2023-07-28, rev 0x5003605, size 37888
+sig 0x0005065b, pf_mask 0xbf, 2023-08-03, rev 0x7002802, size 30720
+sig 0x00050665, pf_mask 0x10, 2023-08-03, rev 0xe15, size 23552
+sig 0x000506f1, pf_mask 0x01, 2023-10-05, rev 0x003e, size 11264
+sig 0x000606a6, pf_mask 0x87, 2023-09-14, rev 0xd0003d1, size 307200
+sig 0x000606c1, pf_mask 0x10, 2023-12-05, rev 0x1000290, size 299008
+sig 0x000706a1, pf_mask 0x01, 2023-08-25, rev 0x0040, size 76800
+sig 0x000706a8, pf_mask 0x01, 2023-08-25, rev 0x0024, size 76800
+sig 0x000706e5, pf_mask 0x80, 2023-09-14, rev 0x00c4, size 114688
+sig 0x000806c1, pf_mask 0x80, 2023-09-13, rev 0x00b6, size 111616
+sig 0x000806c2, pf_mask 0xc2, 2023-09-13, rev 0x0036, size 98304
+sig 0x000806d1, pf_mask 0xc2, 2023-09-13, rev 0x0050, size 104448
+sig 0x000806ec, pf_mask 0x94, 2023-07-16, rev 0x00fa, size 106496
+sig 0x000806f8, pf_mask 0x87, 2024-01-03, rev 0x2b000590, size 579584
+sig 0x000806f7, pf_mask 0x87, 2024-01-03, rev 0x2b000590
+sig 0x000806f6, pf_mask 0x87, 2024-01-03, rev 0x2b000590
+sig 0x000806f5, pf_mask 0x87, 2024-01-03, rev 0x2b000590
+sig 0x000806f4, pf_mask 0x87, 2024-01-03, rev 0x2b000590
+sig 0x00090661, pf_mask 0x01, 2023-09-26, rev 0x0019, size 20480
+sig 0x00090672, pf_mask 0x07, 2023-09-19, rev 0x0034, size 224256
+sig 0x00090675, pf_mask 0x07, 2023-09-19, rev 0x0034
+sig 0x000b06f2, pf_mask 0x07, 2023-09-19, rev 0x0034
+sig 0x000b06f5, pf_mask 0x07, 2023-09-19, rev 0x0034
+sig 0x000906a3, pf_mask 0x80, 2023-09-19, rev 0x0432, size 08
+sig 0x000906a4, pf_mask 0x80, 2023-09-19, rev 0x0432
+sig 0x000906c0, pf_mask 0x01, 2023-09-26, rev 0x2426, size 20480
+sig 0x000906e9, pf_mask 0x2a, 2023-09-28, rev 0x00f8, size 108544
+sig 0x000906ea, pf_mask 0x22, 2023-07-26, rev 0x00f6, size 105472
+sig 0x000906ec, pf_mask 0x22, 2023-07-26, rev 0x00f6, size 106496
+sig 0x000906ed, pf_mask 0x22, 2023-07-27, rev 0x00fc, size 106496
+sig 0x000a0652, pf_mask 0x20, 2023-07-16, rev 0x00fa, size 97280
+sig 0x000a0653, pf_mask 0x22, 2023-07-16, rev 0x00fa, size 97280
+sig 0x000a0655, pf_mask 0x22, 2023-07-16, rev 0x00fa, size 97280
+sig 0x000a0660, pf_mask 0x80, 2023-07-16, rev 0x00fa, size 97280
+sig 0x000a0661, pf_mask 0x80, 2023-07-16, rev 0x00fa, size 96256
+sig 0x000a0671, pf_mask 0x02, 2023-09-14, rev 0x005e, size 108544
+sig 0x000b0671, pf_mask 0x32, 2023-12-14, rev 0x0122, size 215040
+sig 0x000b06a2, pf_mask 0xe0, 2023-12-07, rev 0x4121, size 220160
+sig 0x000b06a3, pf_mask 0xe0, 2023-12-07, rev 0x4121
+sig 0x000b06e0, pf_mask 0x11, 2023-09-25, rev 0x0015, size 138240
+  * New microcodes:
+sig 0x000a06a4, pf_mask 0xe6, 2024-01-03, rev 0x001c, size 136192
+sig 0x000b06a8, pf_mask 0xe0, 2023-12-07, rev 0x4121, size 220160
+sig 0x000c06f2, pf_mask 0x87, 2023-11-20, rev 0x21000200, size 549888
+sig 0x000c06f1, pf_mask 0x87, 2023-11-20, rev 0x21000200
+
 2023-11-14:
   * New upstream microcode datafile 20231114
 Mitigations for "reptar", INTEL-SA-00950 (CVE-2023-23583)
diff --git a/debian/changelog b/debian/changelog
index fa702cb..317fad2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,92 @@
+intel-microcode (3.20240312.1~deb11u1) bullseye; urgency=medium
+
+  * Backport to Debian Bullseye
+  * debian/control: revert non-free-firmware change
+
+ -- Henrique de Moraes Holschuh   Sat, 30 Mar 2024 07:06:46 -0300
+
+intel-microcode (3.20240312.1) unstable; urgency=medium
+
+  * New upstream microcode datafile 20240312 (closes: #1066108)
+- Mitigations for INTEL-SA-INTEL-SA-00972 (CVE-2023-39368):
+  Protection mechanism failure of bus lock regulator for some Intel
+  Processors may allow an unauthenticated user to potentially enable
+  denial of service via network access.
+- Mitigations for INTEL-SA-INTEL-SA-00982 (CVE-2023-

Bug#1068082: bullseye-pu: package intel-microcode/3.20240312.1~deb11u1

[Henrique de Moraes Holschuh]

ure via local access.  Enhances
+  VERW instruction to clear stale register buffers.  Affects SGX as well.
+  Requires kernel update to be effective.
+- Mitigations for INTEL-SA-INTEL-SA-00960 (CVE-2023-22655), aka TECRA:
+  Protection mechanism failure in some 3rd and 4th Generation Intel Xeon
+  Processors when using Intel SGX or Intel TDX may allow a privileged
+  user to potentially enable escalation of privilege via local access.
+  NOTE: effective only when loaded by firmware.  Allows SMM firmware to
+  attack SGX/TDX.
+- Mitigations for INTEL-SA-INTEL-SA-01045 (CVE-2023-43490):
+  Incorrect calculation in microcode keying mechanism for some Intel
+  Xeon D Processors with Intel SGX may allow a privileged user to
+  potentially enable information disclosure via local access.
+  * Fixes for other unspecified functional issues on many processors
+  * Updated microcodes:
+sig 0x00050653, pf_mask 0x97, 2023-07-28, rev 0x1000191, size 36864
+sig 0x00050656, pf_mask 0xbf, 2023-07-28, rev 0x4003605, size 38912
+sig 0x00050657, pf_mask 0xbf, 2023-07-28, rev 0x5003605, size 37888
+sig 0x0005065b, pf_mask 0xbf, 2023-08-03, rev 0x7002802, size 30720
+sig 0x00050665, pf_mask 0x10, 2023-08-03, rev 0xe15, size 23552
+sig 0x000506f1, pf_mask 0x01, 2023-10-05, rev 0x003e, size 11264
+sig 0x000606a6, pf_mask 0x87, 2023-09-14, rev 0xd0003d1, size 307200
+sig 0x000606c1, pf_mask 0x10, 2023-12-05, rev 0x1000290, size 299008
+sig 0x000706a1, pf_mask 0x01, 2023-08-25, rev 0x0040, size 76800
+sig 0x000706a8, pf_mask 0x01, 2023-08-25, rev 0x0024, size 76800
+sig 0x000706e5, pf_mask 0x80, 2023-09-14, rev 0x00c4, size 114688
+sig 0x000806c1, pf_mask 0x80, 2023-09-13, rev 0x00b6, size 111616
+sig 0x000806c2, pf_mask 0xc2, 2023-09-13, rev 0x0036, size 98304
+sig 0x000806d1, pf_mask 0xc2, 2023-09-13, rev 0x0050, size 104448
+sig 0x000806ec, pf_mask 0x94, 2023-07-16, rev 0x00fa, size 106496
+sig 0x000806f8, pf_mask 0x87, 2024-01-03, rev 0x2b000590, size 579584
+sig 0x000806f7, pf_mask 0x87, 2024-01-03, rev 0x2b000590
+sig 0x000806f6, pf_mask 0x87, 2024-01-03, rev 0x2b000590
+sig 0x000806f5, pf_mask 0x87, 2024-01-03, rev 0x2b000590
+sig 0x000806f4, pf_mask 0x87, 2024-01-03, rev 0x2b000590
+sig 0x00090661, pf_mask 0x01, 2023-09-26, rev 0x0019, size 20480
+sig 0x00090672, pf_mask 0x07, 2023-09-19, rev 0x0034, size 224256
+sig 0x00090675, pf_mask 0x07, 2023-09-19, rev 0x0034
+sig 0x000b06f2, pf_mask 0x07, 2023-09-19, rev 0x0034
+sig 0x000b06f5, pf_mask 0x07, 2023-09-19, rev 0x0034
+sig 0x000906a3, pf_mask 0x80, 2023-09-19, rev 0x0432, size 08
+sig 0x000906a4, pf_mask 0x80, 2023-09-19, rev 0x0432
+sig 0x000906c0, pf_mask 0x01, 2023-09-26, rev 0x2426, size 20480
+sig 0x000906e9, pf_mask 0x2a, 2023-09-28, rev 0x00f8, size 108544
+sig 0x000906ea, pf_mask 0x22, 2023-07-26, rev 0x00f6, size 105472
+sig 0x000906ec, pf_mask 0x22, 2023-07-26, rev 0x00f6, size 106496
+sig 0x000906ed, pf_mask 0x22, 2023-07-27, rev 0x00fc, size 106496
+sig 0x000a0652, pf_mask 0x20, 2023-07-16, rev 0x00fa, size 97280
+sig 0x000a0653, pf_mask 0x22, 2023-07-16, rev 0x00fa, size 97280
+sig 0x000a0655, pf_mask 0x22, 2023-07-16, rev 0x00fa, size 97280
+sig 0x000a0660, pf_mask 0x80, 2023-07-16, rev 0x00fa, size 97280
+sig 0x000a0661, pf_mask 0x80, 2023-07-16, rev 0x00fa, size 96256
+sig 0x000a0671, pf_mask 0x02, 2023-09-14, rev 0x005e, size 108544
+sig 0x000b0671, pf_mask 0x32, 2023-12-14, rev 0x0122, size 215040
+sig 0x000b06a2, pf_mask 0xe0, 2023-12-07, rev 0x4121, size 220160
+sig 0x000b06a3, pf_mask 0xe0, 2023-12-07, rev 0x4121
+sig 0x000b06e0, pf_mask 0x11, 2023-09-25, rev 0x0015, size 138240
+  * New microcodes:
+sig 0x000a06a4, pf_mask 0xe6, 2024-01-03, rev 0x001c, size 136192
+sig 0x000b06a8, pf_mask 0xe0, 2023-12-07, rev 0x4121, size 220160
+sig 0x000c06f2, pf_mask 0x87, 2023-11-20, rev 0x21000200, size 549888
+sig 0x000c06f1, pf_mask 0x87, 2023-11-20, rev 0x21000200
+
 2023-11-14:
   * New upstream microcode datafile 20231114
 Mitigations for "reptar", INTEL-SA-00950 (CVE-2023-23583)
diff --git a/debian/changelog b/debian/changelog
index fa702cb..317fad2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,92 @@
+intel-microcode (3.20240312.1~deb11u1) bullseye; urgency=medium
+
+  * Backport to Debian Bullseye
+  * debian/control: revert non-free-firmware change
+
+ -- Henrique de Moraes Holschuh   Sat, 30 Mar 2024 07:06:46 -0300
+
+intel-microcode (3.20240312.1) unstable; urgency=medium
+
+  * New upstream microcode datafile 20240312 (closes: #1066108)
+- Mitigations for INTEL-SA-INTEL-SA-00972 (CVE-2023-39368):
+  Protection mechanism failure of bus lock regulator for some Intel
+  Processors may allow an unauthenticated user to potentially enable
+  denial of service via netw

Bug#1054249: (no subject)

[Johan Van de Wauw]

Can this solution be brought too bookworm, either through stable-updates 
(preferably) or otherwise backports?


The current package is not useable.

Bug#1063591: (no subject)

[Marcos Rodrigues de Carvalho (aka oday)]

retitle 1063591 RFP: anew -- Tool for adding new lines to files, skipping 
duplicates (program)
noowner 1063591

The anew project isn't very active at the moment.
There are open bug issues on GitHub that haven't been addressed.
For this reason, I won't proceed with the effort to package anew for Debian.

I've opened an issue on the project's GitHub repository, but haven't received
any responses.
This is yet another reason not to pursue this packaging task further.

I am immensely grateful for the work done by the upstream team, but adhering
to Debian's best practices, it doesn't make sense to continue with this
packaging endeavor.

Bug#1063591: (no subject)

[Marcos Rodrigues de Carvalho (aka oday)]

retitle 1063591 RFP: anew -- Tool for adding new lines to files, skipping 
duplicates (program)
noowner 1063591

Bug#1003091: xwayland: Xwayland uses glamor and shows black screens

[Gert van de Kraats]

I think this issued can be closed.

In fact it is a really sad story.
Problems occurred at i915 classic. Xwayland upstream didnot want to
remove the activation of ES 2.0, which totally was not working.
But they also did not want to approve merge-requests,
which solve the problems.
Then Debian was delivered without the i915 driver, because upstream
decided to stop support for it @#$.  Also gnome-shell was not working,
without an i915-driver (solved).
Finally Debian was delivered with the gallium-i915-driver. But this
driver surprisingly supports GL 2.1. And Xwayland disables glamor
at GL 2.1, because the graphics-performance is to poor.

So currently Xwayland uses the llvmpipe software driver again at
trixie (testing) and I think also at bookworm.

At the moment I use 
https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1171 at

Xwayland, which also still is not approved. This patch activates glamor
for GL 2.1, and also uses some (fast) fallbacks.
This also needs Mesa MR
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25533 for i915 
gallium, which


gives errorcodes if shader is failing, instead of using a standard 
simple shader,


which  mangles the screen.

Bug#1065184: xwayland: missing build-dep on libtirpc-dev

[Diederik de Haas]

Hi,

I saw that this issue was fixed in git, but there hasn't been an upload with 
that yet. It seems it's blocking the armhf build of wlroots and therefor its 
migration, so could you upload a version with that fix?

Cheers,
  Diederik

PS: On Salsa 'upstream-unstable' is set as default branch, while 'debian-
unstable' seems more used as default branch? I think that's also why 
'vcswatch' seems to have trouble analyzing the repo (according to tracker.d.o)

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

Bug#1003091: xwayland: Xwayland uses glamor and shows black screens

[Diederik de Haas]

Hi,

On 21 Jan 2022 19:49:55 +0100 Gert van de Kraats  wrote:
> I reported the bug upstream for Xwayland:
> 
> https://gitlab.freedesktop.org/xorg/xserver/-/issues/1288
> 
> It will be fixed.

Could you update this bug with its status?
I got the impression that it is fixed upstream, but IIUC the commit that fixed 
it is as of yet only in the 'master' branch and (thus) not part of an upstream 
released version. But it also seems that this issue resulted in fixes in 
several projects? It appears that you were on top of (all the) things, so I 
figured it's better to ask you then trying to figure it out myself.

Cheers,
  Diederik

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

Bug#1066398: xwayland: FTBFS: ./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/testfile.c:17:(.text+0x9): undefined reference to `SHA1Init'

[Diederik de Haas]

Hi,

On Wed, 13 Mar 2024 13:06:09 +0100 Lucas Nussbaum  wrote:
> Source: xwayland
> Version: 2:23.2.4-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > /usr/bin/ld: /tmp/ccL8lXZd.o: in function `main':
> > ./obj-x86_64-linux-gnu/meson-private/tmpz22kr2qg/./obj-x86_64-linux-gnu/
meson-private/tmpz22kr2qg/testfile.c:17:(.text+0x9): undefined reference to 
`SHA1Init'
> > collect2: error: ld returned 1 exit status
> 
> 
> The full build log is available from:
> http://qa-logs.debian.net/2024/03/13/xwayland_23.2.4-1_unstable.log

It think this is actually https://bugs.debian.org/1065184 because:

1) https://sources.debian.org/src/xwayland/2%3A23.2.4-1/meson.build/#L263
is about using (g)libc's SHA1 implementation and #1065184 is about a change in 
glibc causing a FTBFS issue.
IIUC xwayland uses libgcrypt for the SHA1 implementation

2) near the end of your build log is the following message:
"../os/meson.build:63:8: ERROR: Problem encountered: secure-rpc requested, but 
neither libtirpc or libc RPC support were found"
And that matches the build issue mentioned in #1065184.

If you agree, please merge these two bugs.
FTR: Bug #1065184 is already fixed in git.

Cheers,
  Diederik

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

Bug#1067194: ITP: ansible-creator -- fastest way to generate all your ansible content

[Guilherme de Paula Xavier Segundo]

Package: wnpp
Severity: wishlist
Owner: Guilherme de Paula Xavier Segundo 
X-Debbugs-Cc: debian-de...@lists.debian.org, guilherme@gmail.com

* Package name: ansible-creator
  Version : 24.2.0
  Upstream Contact: Ansible by Red Hat 
* URL : https://github.com/ansible/ansible-creator
* License : Apache 2.0
  Programming Lang: Python
  Description : fastest way to generate all your ansible content

 CLI tool for scaffolding all your Ansible Content. This package
 is a Command-Line Interface (CLI) tool designed for effortless scaffolding
 all your Ansible content. Used to initializing an Ansible collection or
 creating a framework for specific plugins, this tool streamlines the process
 with efficiency, standard and precision based on your requirements.

Bug#1064617: update password selection advice

[Diederik de Haas]

On Tuesday, 19 March 2024 12:08:53 CET Holger Wansing wrote:
> Apparently we have reached something like a consensus on this topic,
> should we merge this then?
> 
> 
> 
> Any objections?

LGTM :-)

possibly `s/rms/debra/` with username examples?

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

Bug#1065611: Additional support for SolidRun HoneyComb

[Diederik de Haas]

On Tuesday, 19 March 2024 11:52:29 CET Josua Mayer wrote:
> May I ask if you are analyzing dts manually, or whether you are aware
> of an automatic tool?

Analyses is done by a MUCH improved scripts based upon what I came up with a 
while ago:
https://salsa.debian.org/kernel-team/linux/-/merge_requests/906#note_442903

My script came forth as I was analysing dts[i] files manually by looking up the 
``compatible = "xyz"`` ... and at some point I made a script to help with 
that. Even the much improved version doesn't find them all so I regularly end 
up filling in the things it didn't find, but usually it does find 80-90+%.

HTH,
  Diederik

dts2config
Description: application/shellscript
diederik@bagend:~/dev/debian/salsa/kernel-team/linux$ ../dts2config 
arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts

dts: arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts

 includes: arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
 
 dts: arch/arm64/boot/dts/freescale/fsl-lx2160a-honeycomb.dts
 - ARCH_LAYERSCAPE
   - arch/arm64/Kconfig.platforms
 - ARCH_LAYERSCAPE (bool)
   - debian/config/arm64/config
 - CONFIG_ARCH_LAYERSCAPE=y
   - debian/config/arm64/config.cloud-arm64
 - # CONFIG_ARCH_LAYERSCAPE is not set
 
 compatible: "solidrun,honeycomb"
 
 compatible: "solidrun,lx2160a-cex7"
 
 compatible: "fsl,lx2160a"
 

dts: arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi

 includes: arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
 
 compatible: "gpio-keys"
 - source: drivers/input/keyboard/gpio_keys.c
   - KEYBOARD_GPIO
 - drivers/input/keyboard/Kconfig
   - KEYBOARD_GPIO (tristate)
 - debian/config/config
   - # CONFIG_KEYBOARD_GPIO is not set
 - debian/config/config.cloud
   - # CONFIG_KEYBOARD_GPIO is not set
 - debian/config/arm64/config
   - CONFIG_KEYBOARD_GPIO=m
   - INPUT_KEYBOARD
 - drivers/input/keyboard/Kconfig
   - INPUT_KEYBOARD (bool, default y)
 - debian/config/config
   - CONFIG_INPUT_KEYBOARD=y
   - INPUT
 - drivers/input/Kconfig
   - INPUT (tristate, default y)
 - debian/config/config
   - CONFIG_INPUT=y
 
 compatible: "sff,sfp"
 - source: drivers/net/phy/sfp.c
   - SFP
 - drivers/net/phy/Kconfig
   - SFP (tristate)
 - debian/config/config
   - CONFIG_SFP=m
 

dts: arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi

 includes: arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
 
 compatible: "solidrun,lx2160a-cex7"
 
 compatible: "fsl,lx2160a"
 
 compatible: "regulator-fixed"
 - source: drivers/regulator/fixed.c
   - REGULATOR_FIXED_VOLTAGE
 - drivers/regulator/Kconfig
   - REGULATOR_FIXED_VOLTAGE (tristate)
 - debian/config/config
   - # CONFIG_REGULATOR_FIXED_VOLTAGE is not set
 - debian/config/arm64/config
   - CONFIG_REGULATOR_FIXED_VOLTAGE=m
   - REGULATOR
 - drivers/regulator/Kconfig
   - REGULATOR (bool)
 - debian/config/config
   - # CONFIG_REGULATOR is not set
 - debian/config/config.cloud
   - # CONFIG_REGULATOR is not set
 - debian/config/arm64/config
   - CONFIG_REGULATOR=y
 
 compatible: "nxp,pca9547"
 - source: drivers/i2c/muxes/i2c-mux-pca954x.c
   - I2C_MUX_PCA954x
 - drivers/i2c/muxes/Kconfig
   - I2C_MUX_PCA954x (tristate)
 - debian/config/config
   - # CONFIG_I2C_MUX_PCA954x is not set
 - debian/config/arm64/config
   - CONFIG_I2C_MUX_PCA954x=m
 
 compatible: "atmel,24c512"
 - source: drivers/misc/eeprom/at24.c
   - EEPROM_AT24
 - drivers/misc/eeprom/Kconfig
   - EEPROM_AT24 (tristate)
 - debian/config/config
   - CONFIG_EEPROM_AT24=m
 
 compatible: "atmel,spd"
 - source: drivers/misc/eeprom/at24.c
   - EEPROM_AT24
 - drivers/misc/eeprom/Kconfig
   - EEPROM_AT24 (tristate)
 - debian/config/config
   - CONFIG_EEPROM_AT24=m
 
 compatible: "atmel,24c02"
 - source: drivers/misc/eeprom/at24.c
   - EEPROM_AT24
 - drivers/misc/eeprom/Kconfig
   - EEPROM_AT24 (tristate)
 - debian/config/config
   - CONFIG_EEPROM_AT24=m
 
 compatible: "ti,amc6821"
 - source: drivers/hwmon/amc6821.c
   - SENSORS_AMC6821
 - drivers/hwmon/Kconfig
   - SENSORS_AMC6821 (tristate)
 - debian/config/config
   - CONFIG_SENSORS_AMC6821=m
   - I2C
 - drivers/i2c/Kconfig
   - I2C (tristate)
 - debian/config/arm64/config
   - CONFIG_I2C=y
 
 compatible: "lltc,ltc3882"
 - source: drivers/hwmon/pmbus/ltc2978.c
   - SENSORS_LTC2978
 - drivers/hwmon/pmbus/Kconfig
   - SENSORS_LTC2978 (tristate)
   - PMBUS
 - drivers/hwmon/pmbus/Kconfig
   - PMBUS (tristate)
 - debian/config/config
   - # CONFIG_PMBUS is not set
   - HWMON
 - drivers/hwmon/Kconfig
   - HWMON (tristate, default y)
 - debian/config/config
   - CONFIG_HWMON=y
 

Bug#1066829: ITP: assetfinder -- Find domains and subdomains related to a given domain

[Henrique de Moraes Holschuh]

Hello,

On Wed, Mar 13, 2024, at 21:47, aquilamac...@riseup.net wrote:
> * Package name: assetfinder
>   Version : 0.1.1
>   Upstream Contact: Tom Hudson 
> * URL : https://github.com/tomnomnom/assetfinder
> * License : MIT 
>   Programming Lang: Golang
>   Description : Find domains and subdomains related to a given
> domain

Please consider a less generic name, there are many assets in the world one 
might want to search for using software, dns domains and subdomains are not 
even remotely on the top of that list for most people.

May I humbly suggest "dns-assetfinder" ?

It might be a very good idea to talk to upstream first.

-- 
  Henrique de Moraes Holschuh 

Bug#1065611: Additional support for SolidRun HoneyComb

[Diederik de Haas]

Hi Josua,

On Tuesday, 12 March 2024 16:28:06 CET Josua Mayer wrote:
> I believe I found the answer:
> EDAC_MPC85XX is for power-pc only,
> EDAC_LAYERSCAPE is for arm (see drivers/edac/layerscape_edac.c).

You're right. In the commit I referenced earlier (ea2eb9a8b6207ee4),
I misinterpreted the commit message.
That commit also created ``drivers/edac/fsl_ddr_edac.c`` which got the arch 
independent (or at least dual arch) parts. Its header has this:
```
 * Support Power-based SoCs including MPC85xx, MPC86xx, MPC83xx and
 * ARM-based Layerscape SoCs including LS2xxx. Originally split
 * out from mpc85xx_edac EDAC driver.
```

> Am 12.03.24 um 16:13 schrieb Josua Mayer:
> >
> > Thank you for taking care of this!
> > First the additional changes you found seem reasonable.

Excellent, then I'll make a MR for them (except EDAC_MPC85XX):
- drivers/hwmon/pmbus: Enable PMBUS, SENSORS_PMBUS and
   SENSORS_LTC2978 as modules
- drivers/nvmem: Enable NVMEM_LAYERSCAPE_SFP as module
- drivers/rtc: Enable RTC_DRV_FSL_FTM_ALARM as module
- drivers/soc/fsl: Enable FSL_RCPM

> > Regarding edac - I checked NXPs reference BSP for LX2160,
> > and their linux fork has the same status, driver can not be enabled on
> > arm64.
> > However I also agree it should be enabled if it were possible.
> > The driver appears to setup ecc bit error interrupts so that hey can be
> > reported by Linux.
> > ...
> > I may have access to an lx2160a system with ecc memory within the coming
> > week, so I could test (on vendor kernel based on 5.10 only) whether any
> > problems show up. If not, perhaps a patch to the kernel is advisable.

As EDAC_LAYERSCAPE got enabled in 5.5.17-1 via bug 948576 (with a patch from 
you), ECC support should already work with the Stable 6.1 kernel (or newer).

> > Am 07.03.24 um 13:34 schrieb Diederik de Haas:
> >> On Thursday, 18 January 2024 17:40:38 CET Josua Mayer wrote:
> >> 
> >>> LX2160 SoC early silicon revisions have a pci-e generation 4
> >>> controller.
> >>> It requires a different driver from newer gen-3 silicon.
> >>>
> >>> This affects the SolidRun Honeycomb Workstation which
> >>> is otherwise fully supported in Debian.
> >> 
> >> I cloned bug report #1061116 into #1065611 to discuss some additional
> >> support for the SolidRun HoneyComb.
> >>
> >> I analyzed the HoneyComb dts file and the following included .dtsi
> >> files:
> >> - arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
> >> - arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
> >> - arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi

If my MR gets merged, then there's truly full support in Debian :)

Cheers,
  Diederik

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

Bug#1055016: override: tasksel-data:admin/optional

[Diederik de Haas]

On Sunday, 29 October 2023 12:54:13 CET Cyril Brulebois wrote:
> Daniel Lewart  (2023-10-29):
> > Package: ftp.debian.org
> > Severity: normal
> > User: ftp.debian@packages.debian.org
> > Usertags: override
> > X-Debbugs-Cc: task...@packages.debian.org, debian-b...@lists.debian.org,
> > 855...@bugs.debian.org, 954...@bugs.debian.org Control: affects -1 +
> > src:tasksel
> > 
> > FTP Team,
> > 
> > #855151 - tasksel: should not be Priority: important
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855151
> > 
> > #954090 - override: tasksel:admin/optional
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954090
> > 
> > However, tasksel is still installed by default because of the following:
> > $ apt-cache show tasksel-data | grep -E '^(Package|Depends|Priority)'
> > Package: tasksel-data
> > Depends: tasksel (= 3.73)
> > Priority: important
> > 
> > Please change tasksel-data from:
> > admin/important
> > 
> > to:
> > admin/optional
> 
> It's probably safe since pkgsel's postinst features:
> 
> if db_get pkgsel/run_tasksel && [ "$RET" = true ]; then
> log "starting tasksel"
> db_progress INFO pkgsel/progress/tasksel
> apt-install tasksel  # ensure tasksel is installed
> 

I just ran into this issue too wondering why tasksel-data (and its Depends/
Recommends) got installed.
So hereby a +1 on changing it to ``admin/optional``.

Cheers,
  Diederik

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

Bug#1066060: libpam-modules: pam_lastlog.so missing

[Mourad De Clerck]

Package: libpam-modules
Version: 1.5.3-6
Severity: normal

I noticed the following line in my logs:

login[2449]: PAM unable to dlopen(pam_lastlog.so): 
/usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file 
or directory

I looked in the deb files from snapshot.debian.org, and noticed the last version
that had it was 1.5.2-9.1 - starting from 1.5.3-1 it disappeared.

Maybe it's fallout from the time_t transition and you're already aware of it, in
which case feel free to close.

Thanks,

-- M

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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libpam-modules depends on:
ii  debconf [debconf-2.0]  1.5.86
ii  libaudit1  1:3.1.2-2.1
ii  libc6  2.37-15.1
ii  libcrypt1  1:4.4.36-4
ii  libpam-modules-bin 1.5.3-6
ii  libpam0g   1.5.3-6
ii  libselinux13.5-2
ii  libsystemd0255.4-1+b1

libpam-modules recommends no packages.

libpam-modules suggests no packages.

-- debconf information excluded

Bug#1064617: Passwords should not be changed frequently

[Diederik de Haas]

On Friday, 8 March 2024 19:58:56 CET Philip Hands wrote:
> IMO Having the 'password/passphrase' throughout makes it awkward to
> read, and actually we've got one place where it still just says
> password, and fixing that would make it slightly worse IMO.
> 
> How about dropping the passphrase stuff?

I agree with dropping it. It does look odd and it'll likely raise (more) 
questions then it answers. And most/all people are familiar with password.

Explaining passwords/passphrases is better suited to some educational 
resource.


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

Bug#1065611: Additional support for SolidRun HoneyComb

[Diederik de Haas]

Hi Josua,

On Thursday, 18 January 2024 17:40:38 CET Josua Mayer wrote:
> LX2160 SoC early silicon revisions have a pci-e generation 4 controller.
> It requires a different driver from newer gen-3 silicon.
> 
> This affects the SolidRun Honeycomb Workstation which
> is otherwise fully supported in Debian.

I cloned bug report #1061116 into #1065611 to discuss some additional support 
for the SolidRun HoneyComb.

I analyzed the HoneyComb dts file and the following included .dtsi files:
- arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
- arch/arm64/boot/dts/freescale/fsl-lx2160a-cex7.dtsi
- arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi

If I exclude the kernel modules from 1061116 and 1061117, then I still have 
the following list of additional modules to enable:
- drivers/edac: Enable EDAC_MPC85XX
- drivers/hwmon/pmbus: Enable PMBUS, SENSORS_PMBUS and
  SENSORS_LTC2978 as modules
- drivers/nvmem: Enable NVMEM_LAYERSCAPE_SFP as module
- drivers/rtc: Enable RTC_DRV_FSL_FTM_ALARM as module
- drivers/soc/fsl: Enable FSL_RCPM

If you agree that this is a good list I can make a MR to get them enabled.
A MR for 1061116 and 1061117 has just been merged in our 'master' branch.

But I ran into an issue when looking at the ``EDAC_MPC85XX`` stanza 
in``drivers/edac/Kconfig``:
``depends on FSL_SOC && EDAC=y``

But ``FSL_SOC`` is (only) defined in ``arch/powerpc/Kconfig``, which means 
``EDAC_MPC85XX`` can not be enabled on ``arm64``. 
That module was found based on ``compatible = "fsl,qoriq-memory-controller"``, 
which sounds like something you would want to have.

Upstream commit ea2eb9a8b6207ee4 has the following commit message:
```
EDAC, fsl-ddr: Separate FSL DDR driver from MPC85xx

The mpc85xx-compatible DDR controllers are used on ARM-based SoCs too.
Carve out the DDR part from the mpc85xx EDAC driver in preparation to
support both architectures.
```
Which I interpret as all (?) the preparations for supporting both powerpc and 
ARM were made, but they forgot to update the strict dependency of 
``EDAC_MPC85XX`` to powerpc to actually support both architectures?

Can you shed some light on this?

Cheers,
  Diederik

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

Bug#1061116: linux-image-6.1.0-17-arm64: please enable support for lx2160a pcie gen4 controller on early silicon

[Diederik de Haas]

Control: clone -1 -2
Control: retitle -2 Additional support for SolidRun HoneyComb

On Thursday, 18 January 2024 17:40:38 CET Josua Mayer wrote:
> LX2160 SoC early silicon revisions have a pci-e generation 4 controller.
> It requires a different driver from newer gen-3 silicon.
> 
> This affects the SolidRun Honeycomb Workstation which
> is otherwise fully supported in Debian.

Cloning this bug into a new one to discuss some additional support for the 
SolidRun HoneyComb.

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

Bug#1032623: fixed in qa.debian.org

[Diederik de Haas]

On Wednesday, 6 March 2024 16:26:40 CET Christoph Berg wrote:
> Re: Diederik de Haas
> 
> > The pre-filter which was 1GB and was recently further reduced to 500MB is
> > still in place AFAICT. So it seems to me that this bug would be fixed
> > when the size limitation is removed, which is not (yet) the case?
> 
> The checkouts are now a 1/1000th in size.

Oh, and that means that $repo_size would also be 1/1000th? Which in turn means 
it would now only block repos which would be 500GB in "normal" size?
I can live with that ;-)

Cheers,
  Diederik

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

Bug#1032623: fixed in qa.debian.org

[Diederik de Haas]

On Wednesday, 6 March 2024 15:13:20 CET Christoph Berg wrote:
> Hello,
> 
> Bug #1032623 in qa.debian.org reported by you has been fixed in the Git
> repository. You can see the commit message below and you can check the diff
> of the fix at:
> 
> https://salsa.debian.org/qa/qa/-/commit/d404abd20e11b8bbad551b5991eaf0a0a822
> 0fc2
> 
> 
> vcswatch: Use --filter blob:none
> 
> Required blobs (changelog, control, upstream metadata) are fetched by
> git on demand. Thanks to Gábor Németh for the suggestion!
> 
> Closes: #1032623
> 

The pre-filter which was 1GB and was recently further reduced to 500MB is still 
in place AFAICT. So it seems to me that this bug would be fixed when the size 
limitation is removed, which is not (yet) the case?

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

Bug#1064617: Passwords should not be changed frequently

[Diederik de Haas]

On Wednesday, 6 March 2024 13:19:04 CET Justin B Rye wrote:
> Maybe instead of saying "use the system's initial user account to
> become root" it should say "allow the system's initial user account
> to gain administrative privileges"?  I'm not sure.  Oh, and we might
> even want to mention the word "superuser", or then again we might not.

How about using 'root' for the user/account and super-user for the privileges?
The 'root' user has super-user privileges all the time and the normal user can 
get those privileges via (the) sudo (mechanism).

FTR: that *is* a slight diversion from what's said here:
https://www.debian.org/releases/bookworm/amd64/ch06s03.en.html#di-user-setup

Whatever terminology we use, I think it's important that we use the same 
terminology in both the d-i screens and the Trixie Installation Guide.
Updating the Installation Guide should probably be done separately?

Cheers,
  Diederik

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

Bug#1064617: Passwords should not be changed frequently

[Diederik de Haas]

On Tuesday, 5 March 2024 19:28:25 CET Cyril Brulebois wrote:
> Philip Hands  (2024-03-05):
> > Cool, in that case I'll fix those two things and then use the result
> > for the MR[1], and if the openQA test runs look OK, will merge that.
> 
> Only skimmed over it, but that looks sensible, thanks all.
> 
> Is it worth getting d-l-english involved in a final review before
> getting that translated? Contrary to a lot of not-so-critical l10n
> material, that particular screen is crucial, and I'd hate it if we
> wasted translator efforts due to a missed typo or obvious improvement.

I had started a reply before I had to get out the door, so I'll just keep it 
to one suggestion, which may seem a bit 'radical':

How about getting rid of the password advise entirely from the d-i screen?

We could still make educational resources with f.e. tips on passwords/
passphrases in f.e. the wiki, but it's not the job or the (best) place to put 
such things in the d-i screens?

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

Bug#1064617: Passwords should not be changed frequently

[Diederik de Haas]

On Monday, 4 March 2024 22:30:57 CET Holger Wansing wrote:
> > https://wiki.debian.org/Passwords doesn't exist (yet), but it's an easy to
> > remember URL and we'd have all the space we need to give proper advise?
> 
> Would need to check if that fits in the relevant screens (I want to avoid
> having a scroll bar on that screens).

I didn't mean importing its contents, but just including a link/URL, which a 
user can type in a browser on a secondary device.
Therefor it needs to be short/memorable.

I later realized that putting it in the wiki may be useful, but also dangerous 
as anyone can edit a wiki (page). So another place where only authorized 
changes can be made is probably better.

Cheers,
  Diederik

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

Bug#1060254: mumble: please make the build reproducible

[Diederik de Haas]

On zondag 11 februari 2024 14:43:49 CET you wrote:
> I went ahead and send your patch upstream and that got accepted.
> So I'm attaching a/your patch with all the DEP-3 headers set.

There's now a new release/tag v1.5.613 which includes this fix :)

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

Bug#1064617: Passwords should not be changed frequently

[Diederik de Haas]

On Monday, 4 March 2024 10:43:59 CET Holger Wansing wrote:
> >Regarding the password advice, I ended up concluding that it's pretty
> >unlikely that anything we say at this point will have any effect on
> >people's behaviour, but then I'm probably just an old cynic. Also, I
> >failed when trying to come up with a wording which I was happy with,
> >which is why I ended up discarding the advice entirely.
> >
> >If we want to keep the password advice in then I think what you wrote is
> >(mostly) OK, although I think it implies that one should be choosing a
> >single "password" (although, not a word in any normal sense), which
> >could be argued to steer people away from the perfectly decent xkcd
> >approach of using several dictionary words. Saying "Password or
> >Passphrase" at least once would probably address that.
> 
> Ok, makes it a bit longer, but it could be worth it.

https://wiki.debian.org/Passwords doesn't exist (yet), but it's an easy to 
remember URL and we'd have all the space we need to give proper advise?

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

Bug#1065404: virt-manager: Cannot load AooArmor profile

[Erik de Castro Lopo]

Package: virt-manager
Version: 1:4.1.0-3
Severity: normal

Dear Maintainer,

I moved the `/var/lib/libvirt/images` directory to a new disk at 
`/libvirt/images`
and created a symlink from the former to the later.

The 3 VM disk images were working at the old location but at the new location
I get an error:

libvirt.libvirtError: internal error: cannot load AppArmor profile 
'libvirt-'

Running virt-manager as recommended:

  > virt-manager  --debug  --no-fork
  [Mon, 04 Mar 2024 10:21:10 virt-manager 32] DEBUG (cli:204) Version 4.1.0 
launched with command line: /usr/bin/virt-manager --debug --no-fork
  [Mon, 04 Mar 2024 10:21:10 virt-manager 32] DEBUG (virtmanager:167) 
virt-manager version: 4.1.0
  [Mon, 04 Mar 2024 10:21:10 virt-manager 32] DEBUG (virtmanager:168) 
virtManager import: /usr/share/virt-manager/virtManager
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (virtmanager:205) 
PyGObject version: 3.47.0
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (virtmanager:209) GTK 
version: 3.24.41
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (systray:84) Imported 
AppIndicator3=
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (systray:86) 
AppIndicator3 is available, but didn't find any dbus watcher.
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (systray:476) Showing 
systray: False
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (inspection:206) python 
guestfs is not installed
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (engine:113) Loading 
stored URIs:
  qemu:///system
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (engine:461) processing 
cli command uri= show_window=manager domain=
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (engine:464) No cli 
action requested, launching default window
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (manager:185) Showing 
manager
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (engine:316) window 
counter incremented to 1
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (engine:211) Initial 
gtkapplication activated
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (connection:482) 
conn=qemu:///system changed to state=Connecting
  [Mon, 04 Mar 2024 10:21:11 virt-manager 32] DEBUG (connection:903) 
Scheduling background open thread for qemu:///system
  [Mon, 04 Mar 2024 10:21:15 virt-manager 32] DEBUG (connection:128) 
libvirt URI versions library=10.0.0 driver=10.0.0 hypervisor=8.2.1
  [Mon, 04 Mar 2024 10:21:15 virt-manager 32] DEBUG (connection:109) 
Fetched capabilities for qemu:///system: 
  

  03d502e0-045e-0541-c606-a40700080009
  
x86_64
Skylake-Client
Intel
































  
  



  
  
  


  tcp
  rdma

  
  

  
49290208
12322552
0
0

  


  
  
  
  
  
  
  
  
  
  
  
  

  

  
  

  
  
apparmor
0
  
  
dac
0
+64055:+64055
+64055:+64055
  

  

  hvm
  
32
/usr/bin/qemu-system-i386
pc-i440fx-8.2
pc
pc-q35-5.2
pc-i440fx-2.12
pc-i440fx-2.0
pc-i440fx-6.2
pc-q35-4.2
pc-i440fx-2.5
pc-i440fx-4.2
pc-i440fx-5.2
pc-q35-2.7
pc-q35-7.1
pc-i440fx-2.2
pc-q35-8.1
pc-i440fx-8.1
pc-i440fx-2.7
pc-q35-6.1
pc-q35-2.4
pc-i440fx-7.1
pc-q35-2.10
x-remote
pc-q35-5.1
pc-q35-2.9
pc-i440fx-2.11
pc-q35-3.1
pc-i440fx-6.1
pc-q35-4.1
pc-i440fx-2.4
pc-i440fx-4.1
pc-i440fx-5.1
pc-i440fx-2.9
isapc
pc-q35-2.6
pc-i440fx-3.1
pc-q35-2.12
pc-q35-7.0
pc-i440fx-2.1
pc-q35-8.0
pc-i440fx-8.0
pc-q35-6.0
pc-i440fx-2.6
pc-q35-4.0.1
pc-i440fx-7.0
pc-q35-5.0
pc-q35-2.8
pc-i440fx-2.10
pc-q35-3.0
pc-q35-7.2
pc-q35-4.0
pc-i440fx-6.0
microvm
pc-i440fx-2.3
pc-i440fx-4.0
pc-q35-8.2
q35
pc-i440fx-5.0
pc-i440fx-2.8
pc-q35-6.2
pc-q35-2.5
pc-i440fx-3.0
pc-i440fx-7.2
pc-q35-2.11