Bug#1063161:

[Vincent Blut]

Hi Nathan,

Le 2024-05-23 17:12, Nathan MALO a écrit :
> Hello !
> 
> Thank you very much for enabling those two features in the kernel.
> Your work is much appreciated !
> 
> Maybe I am missing something but I've download the 6.8.9-1 package from
> here
> http://ftp.us.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.8.9-amd64_6.8.9-1_amd64.deb
> and while fiddling with it, I was not able to find the keys CONFIG_AMDTEE
> and CONFIG_AMD_PMF in the /boot/config file.
> 
> I was able to see those two keys activated in salsa :
> https://salsa.debian.org/kernel-team/linux/-/blob/sid/debian/config/amd64/config?ref_type=heads
> 
> Am I missing something ?
> Maybe the package was not rebuilt with this new configuration ?

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?

> Thanks for your help !

Thanks for the report,
Vincent


signature.asc
Description: PGP signature

Bug#1063812: btrfsd: Do not scrub all mount points that belong to the same file system

[Vincent Blut]

Package: btrfsd
Version: 0.2.1-1+b1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

btrfsd runs 'btrfs scrub' on all mount points even if those are part of
a unique filesystem. This is suboptimal since that will not just scrub
those mount points but the entire filesystem where they reside.

So, let's say I have three subvolumes mounted on a single filesystem, scrub will
thus pass over the filesystem three times in a row. While not dramatic, it's
certainly a waste of ressources.

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCZcqe8QAKCRAQn1qAt/bg
AXY+AP4n0+y1Rxrtva1yEOc7EK1ER56zKzkK0O+y3KSf7t4QMQD+JWIKf3pESV6s
rwpqHOqK+07PqojDMkaMgX7ZSPRJrAQ=
=hB6t
-END PGP SIGNATURE-

Bug#1061498: newt: Please do not remove colour palettes

[Vincent Blut]

Package: newt
Version: 0.52.24-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Alastair,

Newt's colour palettes added into /etc/newt/ are going to end up removed
when upgrading or installing whiptail from Config-Files state due to the
following one-liner in the libnewt0.52.preinst file:

rm -f /etc/newt/palette*

This is quite harsh. Could you please drop it so that one can easily use a
system-wide palette?

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCZbJ3ZgAKCRAQn1qAt/bg
AcYJAQDc83xNWal7cv/9IIkDCGWfjopIU4np43y0zUSLmD9NMAEAk0GiEVQ3G9DJ
9006w0xauvywUpfjNEhWP68TJUJ2Zw4=
=Ns0h
-END PGP SIGNATURE-

Bug#1057272: Enable SENSORS_IIO_HWMON support

[Vincent Blut]

Control: tags -1 moreinfo

Hi Andrey,

Le 2023-12-02 16:40, Andrey Melnikov a écrit :
> Package: src:linux
> Version: 6.5.13-1
> Severity: wishlist
> 
> Please, enable SENSORS_IIO_HWMON support. Without it I'm unable to
> fetch the AXP209 internal temperature sensor.
 
The definition of the AXP209 PMU seems to confirm that the internal temperature
sensor is hooked to the iio-hwmon driver:

pmic-temp {
compatible = "iio-hwmon";
io-channels = <_adc 4>; /* Internal temperature */
};

One thing, though. Does it make sense to enable SENSORS_IIO_HWMON outside of
armhf?

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1056616: firefox: Firefox tab freeze when using BigBlueButton

[Vincent Blut]

Le 2023-11-26 19:20, Vincent Blut a écrit :
> Package: firefox
> Version: 120.0-2
> Followup-For: Bug #1056616
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi,
> 
> I'm having the same issue. Each time this happens, one of the following 
> message is logged:
> 
> $ journalctl --no-hostname -b -t firefox.desktop --grep="signal 15"
> nov. 25 00:06:16 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] 
> WARNING: process 5019 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 25 00:06:21 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] 
> WARNING: process 5121 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 25 00:09:39 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] 
> WARNING: process 5450 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 25 00:11:20 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] 
> WARNING: process 5612 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 25 00:13:54 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] 
> WARNING: process 5773 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 25 11:39:03 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] 
> WARNING: process 7242 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 25 11:40:22 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] 
> WARNING: process 10185 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 25 11:40:59 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] 
> WARNING: process 10684 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 25 11:41:30 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] 
> WARNING: process 10963 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 25 12:03:33 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] 
> WARNING: process 12228 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 25 12:06:15 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] 
> WARNING: process 12399 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 25 12:08:04 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
> WARNING: process 13505 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 26 14:14:58 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
> WARNING: process 20426 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 26 15:06:39 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
> WARNING: process 42403 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 26 15:35:09 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
> WARNING: process 44221 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 26 15:54:05 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
> WARNING: process 45807 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 26 16:14:30 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
> WARNING: process 48716 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 26 16:16:40 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
> WARNING: process 13854 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 26 17:15:39 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
> WARNING: process 53954 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 26 17:16:29 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
> WARNING: process 54021 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> nov. 26 18:50:27 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
> WARNING: process 58308 exited on signal 15: file 
> ./ipc/chromium/src/base/process_util_posix.cc:265
> 
> -BEGIN PGP SIGNATURE-
> 
> iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCZWOMYAAKCRAQn1qAt/bg
> AVa/AQD1zDrGPrQJLIJtNiJZNIOM2HC0Iymdw58xvS0Ix86XegD/YOsGj62Druym
> exqd/CDAENB7cKK1GSpVG2oACRHJkgo=
> =YP0B
> -END PGP SIGNATURE-

Seems like the Dark Reader extension is the culprit on my side. I can't seem to
be able to reproduce the issue when I disable it.


signature.asc
Description: PGP signature

Bug#1056616: firefox: Firefox tab freeze when using BigBlueButton

[Vincent Blut]

Package: firefox
Version: 120.0-2
Followup-For: Bug #1056616

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

I'm having the same issue. Each time this happens, one of the following message 
is logged:

$ journalctl --no-hostname -b -t firefox.desktop --grep="signal 15"
nov. 25 00:06:16 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] WARNING: 
process 5019 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 25 00:06:21 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] WARNING: 
process 5121 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 25 00:09:39 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] WARNING: 
process 5450 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 25 00:11:20 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] WARNING: 
process 5612 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 25 00:13:54 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] WARNING: 
process 5773 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 25 11:39:03 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] WARNING: 
process 7242 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 25 11:40:22 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] WARNING: 
process 10185 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 25 11:40:59 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] WARNING: 
process 10684 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 25 11:41:30 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] WARNING: 
process 10963 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 25 12:03:33 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] WARNING: 
process 12228 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 25 12:06:15 firefox.desktop[4109]: [Parent 4109, IPC I/O Parent] WARNING: 
process 12399 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 25 12:08:04 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
WARNING: process 13505 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 26 14:14:58 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
WARNING: process 20426 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 26 15:06:39 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
WARNING: process 42403 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 26 15:35:09 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
WARNING: process 44221 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 26 15:54:05 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
WARNING: process 45807 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 26 16:14:30 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
WARNING: process 48716 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 26 16:16:40 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
WARNING: process 13854 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 26 17:15:39 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
WARNING: process 53954 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 26 17:16:29 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
WARNING: process 54021 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265
nov. 26 18:50:27 firefox.desktop[13293]: [Parent 13293, IPC I/O Parent] 
WARNING: process 58308 exited on signal 15: file 
./ipc/chromium/src/base/process_util_posix.cc:265

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCZWOMYAAKCRAQn1qAt/bg
AVa/AQD1zDrGPrQJLIJtNiJZNIOM2HC0Iymdw58xvS0Ix86XegD/YOsGj62Druym
exqd/CDAENB7cKK1GSpVG2oACRHJkgo=
=YP0B
-END PGP SIGNATURE-

Bug#1055244: linux-image-amd64: Please enable CONFIG_MTK_T7XX for the Intel/Mediatek FM350-GL 5G modem

[Vincent Blut]

Hi Martin,

Le 2023-11-02 20:10, Martin Sofaru a écrit :
> Source: linux
> Version: linux/6.5.0-3
> Severity: wishlist
> X-Debbugs-Cc: debian-b...@fhloston.org
> 
> Dear Maintainer,
> 
> please set CONFIG_MTK_T7XX=m to build the mtk_t7xx kernel module.
> 
> This module is necessary to use some 5G modems built into newer Lenovo 
> Laptops like X1 Yoga Gen7/Gen8 and X1 Carbon Gen10/Gen11.
> 
> As long as this [1] patch is not merged upstream, it might be sensible to 
> also include this. 
> 
> The modem itself also needs some kind of FCC unlock which can be found here 
> [2].

I'll send a merge request soon. The patch to have the modem part work has been
merged in Linux 6.6-rc1.
 
> Thank you
> 
> Martin

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1055205: chrony: SysV problems after upgrade

[Vincent Blut]

Hi Richard,

Le 2023-11-02 09:01, Richard Lucassen a écrit :
> Package: chrony
> Version: 4.4-3
> Severity: normal
> 
> I run chronyd supervised. Therefore I removed symlinks in /etc/rc2.d/ 
> (update-rc.d chrony remove).
> But after an upgrade the deb package installs new symlinks in /etc/rc2.d/ and 
> starts chronyd, even though chronyd is SysV disabled.
> 
> Please check if /etc/rc2.d/*chrony symlinks exist, if not, don't add these 
> and do not start chronyd. Maybe it's a good idea to just display a warning in 
> that case.
> 

I'm closing this bug report as this is, to me, not something that should
handled on the packaging side. From update-rc.d(8):

A common system administration error is to delete the links with the  
thought  that  this  will
"disable"  the  service, i.e., that this will prevent the service from 
being started.  However,
if all links have been deleted then the next  time  the  package  is  
upgraded,  the  package's
postinst  script  will run update-rc.d again and this will reinstall links 
at their factory de-
fault locations.  The correct way to disable services is to configure the 
service as stopped in
all runlevels in which it is started by default.  In the System V init 
system this means renam-
ing the service's symbolic links from S to K.  .P The script .BI 
/etc/init.d/ name  must  exist
before update-rc.d is run to create the links.

Running 'update-rc.d chrony disable' as root should work too.

> Richard.

Have a good day,
Vincent


signature.asc
Description: PGP signature

Bug#1055069: please enable SC8280XP sound modules

[Vincent Blut]

Hi,

Le 2023-10-30 20:30, Dmitry Baryshkov a écrit :
> Package: src:linux
> Version: 6.5.8-1
> Severity: normal
> 
> Please enable the following options as modules to enable audio support
> on Lenovo X13s platform:
> 
> CONFIG_SND_SOC_SC8280XP
> CONFIG_SC_LPASSCC_8280XP

Emanuele, as you’re working on support for the Lenovo X13s platform, could you
please comment on that?

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1054222: chrony: installs some units twice once dh_installsystemd installs to /usr

[Vincent Blut]

Package: chrony
Version: 4.4-2
Severity: normal
User: helm...@debian.org
Usertags: dep17m2

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

chrony is among the packages that will become RC buggy as soon as
dh_installsystemd installs systemd units in /usr/lib/systemd/system due to some
of those units being also installed into /lib/systemd/system via dh_install.

My plan is to drop the systemd units listed in the d/install file and symlink
the units provided in the examples/ directory into debian/ to let
dh_installsystemd handle them.

A new chrony revision implementing this plan is expected this weekend.

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCZTEw8wAKCRAQn1qAt/bg
Abv4AQDnZArfFNIKH9sDTMAjkjzt94OMk+87bG+vAypTb87SxgEAwW0eWISic+UB
RIQBzs27W81gFRF9KeRygfUhY95dDgU=
=9Qne
-END PGP SIGNATURE-

Bug#1053852: btrfsd: Segfault in libgobject-2.0.so.0.7800.0[7fcec2dff000+34000]

[Vincent Blut]

Package: btrfsd
Version: 0.2.0-1
Followup-For: Bug #1053852

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tags -1 fixed-upstream

Hi Matthias,

I built btrfsd with 59145f1 (utils: Don't free result twice when checking if 
device is on
battery) applied, that fixes the issue. Thanks!

Have a good day,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCZSkWGgAKCRAQn1qAt/bg
AeIwAQDwHqQfIi2iEr3HUORgLk1CNXknX3VdaP90pxPg3p3jzwD8DBPwjqqHqUsr
b6LXQ0VKKNxqb9dJ04cB6Fzljh8NWg8=
=C4ko
-END PGP SIGNATURE-

Bug#1053852: btrfsd: Segfault in libgobject-2.0.so.0.7800.0[7fcec2dff000+34000]

[Vincent Blut]

Le 2023-10-12 19:24, Matthias Klumpp a écrit :
> Hi!
> 
> Thank you for the issue report!

You're welcome!

> How did you run btrfsd exactly? Did you set anything specific in its
> configuration file?

This is a default install, i.e. running btrfsd through systemd without any 
changes
to the configuration file.

>Can you generate a backtrace with debug symbols for btrfsd installed?

Oh, my bad. I was in a hurry and I totally forgot to install btrfsd-dbgsym.
Here is another run after installing it:

Thread 1 "btrfsd" received signal SIGSEGV, Segmentation fault.
0x77e40c01 in g_type_check_instance_is_fundamentally_a ()
   from /lib/x86_64-linux-gnu/libgobject-2.0.so.0

(gdb) thread apply all bt

Thread 4 (Thread 0x767fe6c0 (LWP 53845) "gdbus"):
#0  0x779b1a1f in __GI___poll (fds=0x7fffeb90, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x77ec1237 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x77ec1bdf in g_main_loop_run () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77d3bdfa in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x77eee9e1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7793e3ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x779bea4c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 3 (Thread 0x7fffee7fe6c0 (LWP 53844) "gmain"):
#0  0x779b1a1f in __GI___poll (fds=0x55575a40, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x77ec1237 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x77ec18f0 in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77ec1941 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x77eee9e1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7793e3ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x779bea4c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 2 (Thread 0x76fff6c0 (LWP 53843) "pool-spawner"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x77f1c9a4 in g_cond_wait () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x77e8b15b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77eef06a in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x77eee9e1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7793e3ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x779bea4c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 1 (Thread 0x773e5900 (LWP 53839) "btrfsd"):
#0  0x77e40c01 in g_type_check_instance_is_fundamentally_a () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1  0x77e2187d in g_object_unref () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#2  0xa119 in glib_autoptr_clear_GDBusConnection 
(_ptr=0x5557c2d0) at /usr/include/glib-2.0/gio/gio-autocleanups.h:49
#3  glib_autoptr_cleanup_GDBusConnection (_ptr=) at 
/usr/include/glib-2.0/gio/gio-autocleanups.h:49
#4  btd_machine_is_on_battery () at ../src/btd-utils.c:365
#5  0x8b35 in btd_scheduler_run_for_mount (bfs=0x55573fa0, 
self=0x5556e420) at ../src/btd-scheduler.c:436
#6  btd_scheduler_run (self=self@entry=0x5556e420, 
error=error@entry=0x7fffc778) at ../src/btd-scheduler.c:497
#7  0x7a5b in main (argc=, argv=) at 
../src/btrfsd.c:81

> Cheers,
> Matthias

Thanks for your time,
Vincent


signature.asc
Description: PGP signature

Bug#1053852: btrfsd: Segfault in libgobject-2.0.so.0.7800.0[7fcec2dff000+34000]

[Vincent Blut]

Package: btrfsd
Version: 0.2.0-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Matthias,

btrfsd fails to start on my system:

[…]
oct. 12 00:44:41 lamella kernel: btrfsd[29326]: segfault at 5625ebe5fe33 ip 
7f0bf91bec01 sp 7ffc992c1fb8 error 4 in 
libgobject-2.0.so.0.7800.0[7f0bf9193000+34000] likely on CPU 3 (core 1, socket 
0)
oct. 12 13:05:16 lamella kernel: btrfsd[33302]: segfault at 55c2402dc51d ip 
7f8fbe68ec01 sp 7ffc586d53f8 error 4 in 
libgobject-2.0.so.0.7800.0[7f8fbe663000+34000] likely on CPU 2 (core 0, socket 
0)
oct. 12 14:06:03 lamella kernel: btrfsd[36063]: segfault at 5583eef6893b ip 
7f358c23ec01 sp 7ffc0253e1d8 error 4 in 
libgobject-2.0.so.0.7800.0[7f358c213000+34000] likely on CPU 0 (core 0, socket 
0)
oct. 12 15:06:44 lamella kernel: btrfsd[39068]: segfault at 55f98253392b ip 
7f6bc3b89c01 sp 7fff7597e4f8 error 4 in 
libgobject-2.0.so.0.7800.0[7f6bc3b5e000+34000] likely on CPU 2 (core 0, socket 
0)
oct. 12 16:06:46 lamella kernel: btrfsd[40261]: segfault at 55a61769a534 ip 
7fcec2e2ac01 sp 7ffcaad664a8 error 4 in 
libgobject-2.0.so.0.7800.0[7fcec2dff000+34000] likely on CPU 2 (core 0, socket 
0)


Here is the backtrace:

(gdb) thread apply all bt

Thread 4 (Thread 0x75ffd6c0 (LWP 45447) "gdbus"):
#0  0x779b1a1f in __GI___poll (fds=0x7fffec000b90, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x77ec1237 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x77ec1bdf in g_main_loop_run () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77d3bdfa in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x77eee9e1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7793e3ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x779bea4c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 3 (Thread 0x767fe6c0 (LWP 45446) "gmain"):
#0  0x779b1a1f in __GI___poll (fds=0x55575a40, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x77ec1237 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x77ec18f0 in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77ec1941 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x77eee9e1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7793e3ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x779bea4c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 2 (Thread 0x76fff6c0 (LWP 45445) "pool-spawner"):
#0  syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1  0x77f1c9a4 in g_cond_wait () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
- --Type  for more, q to quit, c to continue without paging--c
#2  0x77e8b15b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x77eef06a in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x77eee9e1 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7793e3ec in start_thread (arg=) at 
./nptl/pthread_create.c:444
#6  0x779bea4c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 1 (Thread 0x773e5900 (LWP 45441) "btrfsd"):
#0  0x77e40c01 in g_type_check_instance_is_fundamentally_a () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1  0x77e2187d in g_object_unref () from 
/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#2  0xa119 in ?? ()
#3  0x8b35 in ?? ()
#4  0x7a5b in ?? ()
#5  0x778dd6ca in __libc_start_call_main 
(main=main@entry=0x78a0, argc=argc@entry=1, 
argv=argv@entry=0x7fffc988) at ../sysdeps/nptl/libc_start_call_main.h:58
#6  0x778dd785 in __libc_start_main_impl (main=0x78a0, argc=1, 
argv=0x7fffc988, init=, fini=, 
rtld_fini=, stack_end=0x7fffc978) at ../csu/libc-start.c:360
#7  0x7ba1 in ?? ()

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCZSgLGQAKCRAQn1qAt/bg
AZeRAQDeJWUcwAOPFd//0QXVJx+hwTyUpFsJFoJqBnWsiApA5gD9Gws81Xw6zrDY
V8fjtAM1ebiJBPksIkOnK+9AVF61zg4=
=wiTQ
-END PGP SIGNATURE-

Bug#1051822: installed chrony package post-installation script subprocess returned error exit status 1

[Vincent Blut]

Control: tags -1 + moreinfo

Hi Anibal,

Le 2023-09-13 13:52, Anibal Monsalve Salazar a écrit :
> Package: chrony
> Version: 4.2-2
> Severity: critical
> 
> # dpkg -i /mnt/apt/archives/chrony_4.4-1_i386.deb
> (Reading database ... 34682 files and directories currently installed.)
> Preparing to unpack .../archives/chrony_4.4-1_i386.deb ...
> Failed to stop chronyd-restricted.service: Unit chronyd-restricted.service 
> not loaded.
> Unpacking chrony (4.4-1) over (4.3-4) ...
> Setting up chrony (4.4-1) ...
> Unknown option: comment
> adduser [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID]
> [--firstuid ID] [--lastuid ID] [--gecos GECOS] [--ingroup GROUP | --gid ID]
> [--disabled-password] [--disabled-login] [--add_extra_groups] USER
>Add a normal user
> 
> adduser --system [--home DIR] [--shell SHELL] [--no-create-home] [--uid ID]
> [--gecos GECOS] [--group | --ingroup GROUP | --gid ID] [--disabled-password]
> [--disabled-login] [--add_extra_groups] USER
>Add a system user
> 
> adduser --group [--gid ID] GROUP
> addgroup [--gid ID] GROUP
>Add a user group
> 
> addgroup --system [--gid ID] GROUP
>Add a system group
> 
> adduser USER GROUP
>Add an existing user to an existing group
> 
> general options:
>   --quiet | -q  don't give process information to stdout
>   --force-badname   allow usernames which do not match the
> NAME_REGEX configuration variable
>   --help | -h   usage message
>   --version | -vversion number and copyright
>   --conf | -c FILE  use FILE as configuration file
> 
> dpkg: error processing package chrony (--install):
>  installed chrony package post-installation script subprocess returned error 
> exit status 1
> Processing triggers for man-db (2.11.2-3) ...
> Errors were encountered while processing:
>  chrony

I don't seem to be able to reproduce this issue. Could you please give me more
information on the system on which you were upgrading chrony? It seems you were
upgrading from chrony 4.3-4, so I guess this system is running testing/unstable‽

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1041007: linux-image-6.1.0-0.deb11.7-amd64: Please enable TPM hardware RNG support (CONFIG_HW_RANDOM_TPM)

[Vincent Blut]

Hi Björn,

Le 2023-08-15 07:49, Björn Persson a écrit :
> Hello, has there been any progress with this?

I started working on this a few days ago. I’ll try to send a merge request
over the weekend.

> […]
>
> Björn Persson

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1041007: linux-image-6.1.0-0.deb11.7-amd64: Please enable TPM hardware RNG support (CONFIG_HW_RANDOM_TPM)

[Vincent Blut]

Hello,

Le 2023-07-13 23:10, jflf_ker...@gmx.com a écrit :
> Package: src:linux
> Version: 6.1.20-2~bpo11+1
> Severity: normal
> X-Debbugs-Cc: jflf_ker...@gmx.com
> 
> Dear Maintainer,
> 
> Currently no Debian kernel enables support for TPM hardware RNG. On one of my
> systems:
> 
> $ uname -a
> Linux XXX 6.1.0-0.deb11.7-amd64 #1 SMP PREEMPT_DYNAMIC Debian
> 6.1.20-2~bpo11+1 (2023-04-23) x86_64 GNU/Linux
> 
> $ cat /sys/class/tpm/tpm0/device/description
> TPM 2.0 Device
> 
> $ ls /dev/tpm*
> /dev/tpm0  /dev/tpmrm0
> 
> $ sudo tpm2_getrandom 16 | xxd -p
> 7ba65632453b191385a3989485ac80a3
> 
> $ grep HW_RANDOM_TPM /boot/config-$(uname -r)
> 
> 
> $ find /lib/modules/$(uname -r) -iname \*tpm\*rng\*
> 
> 
> $ ls /dev/hwrng
> ls: cannot access '/dev/hwrng': No such file or directory
> 
> 
> I have checked the current bookworm and trixie kernel debs, and they don't
> include it either. It should be enabled there too.
> 
> I manage multiple older amd64 machines that have discrete TPM chips, but no
> RDRAND instruction or any other hardware RNG. Enabling support for the TPM RNG
> would provide the kernel with additional entropy earlier in the boot process.

Indeed, this regression compared to the kernel provided in bullseye is due to
a configuration issue.
For HW_RANDOM_TPM to be enabled, the TCG_TPM and HW_RANDOM config symbols are
required but there is a subtlety in the way they have to be built. If TCG_TPM
is built-in then HW_RANDOM must not be loadable (built as a module).

If we take a look at the kernel configuration files prior being constructed, we
can see that both TCG_TPM and HW_RANDOM config symbols should be built as
modules:

$ grep -Er "TCG_TPM|HW_RANDOM="
arm64/config:CONFIG_TCG_TPM=m
kernelarch-x86/config:CONFIG_TCG_TPM=m
config:CONFIG_HW_RANDOM=m
config.cloud:CONFIG_TCG_TPM=m
 
However after these files have been constructed, the TCG_TPM config symbol is
no longer provided as module but built-in:

$ grep TCG_TPM /boot/config-6.3.0-1-amd64
CONFIG_TCG_TPM=y

This change is what causes HW_RANDOM_TPM to be disabled and is probably due to
[1].

Ben, Salvatore, to fix this regression we should either force TCG_TPM to be
built as a module or make HW_RANDOM built-in. The second solution have my
preference, WDYT?

Cheers,
Vincent

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=644f17412f5acf01a19af9d04a921937a2bc86c6


signature.asc
Description: PGP signature

Bug#1038385: linux-image-amd64: Please enable CONFIG_INTEL_SKL_INT3472 for the Intel Skylake power controller

[Vincent Blut]

Le 2023-07-26 14:57, Martin Sofaru a écrit :
> Hi Vincent,
> 
> On Tue, 25 Jul 2023 22:50:35 +0200 Vincent Blut 
> wrote:
> > Hi Martin,
> > 
> > Le 2023-07-25 16:15, Martin Sofaru a écrit :
> > > Dear maintainer,
> > > > since kernel 6.4.
> > > > CONFIG_VIDEO_V4L2_SUBDEV_API=y needs to be set aswell.
> > > > It was previously enabled until kernel 6.3.
> > > > > CONFIG_INTEL_SKL_INT3472=m and
> > 
> > […]
> > 
> > > CONFIG_VIDEO_V4L2_SUBDEV_API=y
> > > > are needed to compile ipu6-drivers-dkms for the new Intel
> > Computervision
> > > webcams present in major manufacturer's new designs, for example Lenovo's 
> > > X1
> > > Carbon gen10+ or X1 Yoga Gen7+.
> > 
> > This driver should select VIDEO_V4L2_SUBDEV_API, right?
> 
> currently the dkms from ipu6-drivers just fails to compile when
> CONFIG_VIDEO_V4L2_SUBDEV_API is not set. So if I enable some other not
> related media driver that selects CONFIG_VIDEO_V4L2_SUBDEV_API=y I can build
> ipu6-drivers.
 
If this driver requires this API then it should select VIDEO_V4L2_SUBDEV_API.
Could you eventually send a bug report upstream?

> I simply noticed that
> config-6.3.0-1-amd64 and
> config-6.3.0-2-amd64
> have CONFIG_VIDEO_V4L2_SUBDEV_API=y while config-6.4.0-1-amd64 has not.
> 
> I do not know the reasoning for the removal of that config.
 
CONFIG_VIDEO_V4L2_SUBDEV_API was available in Linux 6.3 thanks to the 
CONFIG_VIDEO_NOON010PC30 option. However that camera sensor driver has been
dropped in Linux 6.4 and none of the camera sensor drivers enabled in Debian
select CONFIG_VIDEO_V4L2_SUBDEV_API.

> At this point I am just grateful I can use the camera in my device at all :)

Understandable ;)


signature.asc
Description: PGP signature

Bug#1038385: linux-image-amd64: Please enable CONFIG_INTEL_SKL_INT3472 for the Intel Skylake power controller

[Vincent Blut]

Hi Martin,

Le 2023-07-25 16:15, Martin Sofaru a écrit :
> Dear maintainer,
> 
> since kernel 6.4.
> 
> CONFIG_VIDEO_V4L2_SUBDEV_API=y needs to be set aswell.
> 
> It was previously enabled until kernel 6.3.
> 
> 
> CONFIG_INTEL_SKL_INT3472=m and

[…]

> CONFIG_VIDEO_V4L2_SUBDEV_API=y
> 
> are needed to compile ipu6-drivers-dkms for the new Intel Computervision
> webcams present in major manufacturer's new designs, for example Lenovo's X1
> Carbon gen10+ or X1 Yoga Gen7+.

This driver should select VIDEO_V4L2_SUBDEV_API, right?

> Thank you
> 
> Martin
 
 Cheers,
 Vincent


signature.asc
Description: PGP signature

Bug#1012222: linux: please enable the CONFIG_X86_KERNEL_IBT configuration option

[Vincent Blut]

Version: 6.3.1-1~exp1

Hi Laurent,

Le 2022-06-01 18:53, Laurent Bonnaud a écrit :
> Package: src:linux
> Version: 5.18.0-trunk
> Severity: wishlist
> 
> 
> Dear kernel Maintainers,
> 
> the CONFIG_X86_KERNEL_IBT configuration option is currently not enabled in 
> Debian kernels:
> 
> $ grep CONFIG_X86_KERNEL_IBT /boot/config*
> /boot/config-5.18.0-trunk-amd64:# CONFIG_X86_KERNEL_IBT is not set
> /boot/config-5.18.0-trunk-rt-amd64:# CONFIG_X86_KERNEL_IBT is not set
> 
> It is an important protection against ROP/JOP attacks.  Could you please 
> enable it in Debian kernels?

Let's close this report since kernel IBT is enabled by default starting with
Linux 6.2+ [1].
 
> Thanks,
> 
> -- 
> Laurent.
 
Cheers,
Vincent

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4fd5f70ce14da230c6a29648c3d51a48ee0b4bfd


signature.asc
Description: PGP signature

Bug#1035898: unblock: chrony/4.3-2+deb12u1

[Vincent Blut]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: chr...@packages.debian.org
Control: affects -1 + src:chrony

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Please unblock package chrony

[ Reason ]
This softens a rule in the AppArmor profile. Currently, the profile is way too
strict about allowed gpsd socket names.

[ Impact ]
Users may need to override the AppArmor profile (or put the profile in complain 
mode) so that chronyd can consume time information from gpsd using sockets.
Overriding an AppArmor profile is acceptable when dealing with some exotic
configurations, but here even trying to feed chronyd with something as common
as PPS samples would be denied by the profile.

[ Tests ]
I checked that chronyd was able to receive PPS samples from gpsd through a
Unix socket driver using the '/run/chrony.pps0.sock' path. This is no longer
denied with chrony 4.3-2+deb12u1.

[ Risks ]
None that I know of.

[ Checklist ]
  [✓] all changes are documented in the d/changelog
  [✓] I reviewed all changes and I approve them
  [✓] attach debdiff against the package in testing

[ Other info ]
I must admit that the version number is atypical for an upload to unstable but
chrony 4.3-3 is already in experimental.

unblock chrony/4.3-2+deb12u1


-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCZFv+fQAKCRAQn1qAt/bg
ATptAQDKB1vG2CXDXkwW1dGb9l3GFwua+oeoc1qOm3LNhqNfSgD/ZBld8s8e1XSD
QXFm/ZXjxKXIkU+1m8TaS5JL5oRWDwk=
=uMJh
-END PGP SIGNATURE-
diff -Nru chrony-4.3/debian/changelog chrony-4.3/debian/changelog
--- chrony-4.3/debian/changelog 2023-01-27 22:51:17.0 +0100
+++ chrony-4.3/debian/changelog 2023-05-08 22:05:00.0 +0200
@@ -1,3 +1,13 @@
+chrony (4.3-2+deb12u1) unstable; urgency=medium
+
+  * debian/usr.sbin.chronyd:
+- Modify the AppArmor profile to allow more gpsd socket names. This will
+avoid the need for users to override the profile to let chronyd consume PPS
+samples or serial time supplied by gpsd over a Unix-domain socket.
+Thanks to Ryan Govostes for the report. (Closes: #1034519)
+
+ -- Vincent Blut   Mon, 08 May 2023 22:05:00 +0200
+
 chrony (4.3-2) unstable; urgency=medium
 
   * debian/control:
diff -Nru chrony-4.3/debian/usr.sbin.chronyd chrony-4.3/debian/usr.sbin.chronyd
--- chrony-4.3/debian/usr.sbin.chronyd  2023-01-27 22:51:17.0 +0100
+++ chrony-4.3/debian/usr.sbin.chronyd  2023-05-08 22:05:00.0 +0200
@@ -59,7 +59,7 @@
   # Configs using a 'chrony.' prefix like the tempcomp config file example
   /etc/chrony.* r,
   # Example gpsd socket is outside @{run}/chrony/
-  @{run}/chrony.tty{,*}.sock rw,
+  @{run}/chrony.*.sock rw,
   # To sign replies to MS-SNTP clients by the smbd daemon
   /var/lib/samba/ntp_signd/socket rw,
 

Bug#1035569: installation-reports: failed to detect Realtek RTL8852BE WiFi 6 802.11ax PCIe adapter

[Vincent Blut]

Le 2023-05-09 19:05, Diederik de Haas a écrit :
> On Tuesday, 9 May 2023 18:49:35 CEST Vincent Blut wrote:
> > > today I tried again with a TP-Link TL-WN725N Nano USB dongle which
> > > contains the Realtek RTL8188EU chip set. Same result, the adapter is not
> > > recognized and I am presented with a list of kernel modules of which none
> > > works. But in this case, I am pretty sure that the RTL8188EU chip *should*
> > > be supported by a recent kernel.
> > > 
> > > Any hints, or should I file a separate installation report?
> > 
> > RTL8188EU support requires Linux 6.3+:
> > https://lore.kernel.org/all/3aad60f6-23f9-81e8-c741-4bd51e99f...@gmail.com/
> 
> While that appears to be a 'proper' driver for RTL8188EU, it looks like there
> was a previous driver for it in staging:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-6.1.y=grep=RTL8188EU
> 
> The new installation report (https://bugs.debian.org/1035824) has this line:
> [42871.936975] r8188eu: module is from the staging directory, the quality is 
> unknown, you have been warned.
> 
> Am I missing something (still)?

Color me stupid. I was working from upstream's master branch which have the
staging driver removed. Sorry for the confusion!


signature.asc
Description: PGP signature

Bug#1035569: installation-reports: failed to detect Realtek RTL8852BE WiFi 6 802.11ax PCIe adapter

[Vincent Blut]

Hi Fabian,

Le 2023-05-09 18:04, fab...@greffrath.com a écrit :
> Hi guys,
> 
> Am 05.05.2023 18:09, schrieb Diederik de Haas:
> > Too recent for Bookworm as it appears that it was added in 6.2,
> > while Bookworm has 6.1.
> 
> today I tried again with a TP-Link TL-WN725N Nano USB dongle which contains
> the Realtek RTL8188EU chip set. Same result, the adapter is not recognized
> and I am presented with a list of kernel modules of which none works. But in
> this case, I am pretty sure that the RTL8188EU chip *should* be supported by
> a recent kernel.
> 
> Any hints, or should I file a separate installation report?

RTL8188EU support requires Linux 6.3+:
https://lore.kernel.org/all/3aad60f6-23f9-81e8-c741-4bd51e99f...@gmail.com/
 
> Cheers,
> 
>  - Fabian
 
Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1034519: chrony: AppArmor profile denies creation of chrony.ppsX.sock

[Vincent Blut]

Le 2023-04-17 20:45, Vincent Blut a écrit :
> Control: severity -1 important
> Control: tags -1 moreinfo
> 
> Hi Ryan,
> 
> Le 2023-04-17 14:54, Ryan Govostes a écrit :
> > Package: chrony
> > Version: 4.3
> > Severity: normal
> > X-Debbugs-Cc: rgovos...@gmail.com
> > 
> > Dear Maintainer,
> > 
> > gpsd and chronyd can communicate via domain sockets such as 
> > /var/run/chrony.ttyS0.sock. chronyd creates the sockets and gpsd connects 
> > to them.
> > 
> > However, the AppArmor profile for chronyd is too strict; it only allows the 
> > creation of sockets for tty devices, and not pps devices.
> > 
> > @{run}/chrony.tty{,*}.sock rw,
> 
> Indeed, this rule is too restrictive…
>  
> > The corresponding rules on the gpsd profile are:
> > 
> > /{,var/}run/chrony.tty{,S,USB,AMA}[0-9]*.sock rw,
> > /tmp/chrony.tty{,S,USB,AMA}[0-9]*.sock rw,
> > 
> > Could these be relaxed to allow /var/run/chrony.*.sock?
> 
> …This might be too permissive though. Could you please tell me if changing the
> rule to "@{run}/chrony{,.clk}.{tty,pps}*.sock rw," meets your need?

Any update on this Ryan?

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1034541: tzdata: Please upload tzdata 2023c-3exp1

[Vincent Blut]

Package: tzdata
Version: 2023c-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: affects -1 chrony

Hi,

chrony in experimental depends on tzdata-legacy but it is no longer available
since you uploaded tzdata 2023c-3 into unstable. That makes chrony in
experimental uninstallable.

Could you please ensure that changes made to tzdata in unstable are merged
back into experimental for the time being?

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCZD2mxAAKCRAQn1qAt/bg
AWfqAP47t2mlazoAVJ5ETQrQjPoej5ENIJfJofI+Tkp5l9MfowD7BYcRiiJ0Hv68
0JVhCXnNrUky8bu7b/zcwCNB0PFYUwE=
=5DEQ
-END PGP SIGNATURE-

Bug#1034519: chrony: AppArmor profile denies creation of chrony.ppsX.sock

[Vincent Blut]

Control: severity -1 important
Control: tags -1 moreinfo

Hi Ryan,

Le 2023-04-17 14:54, Ryan Govostes a écrit :
> Package: chrony
> Version: 4.3
> Severity: normal
> X-Debbugs-Cc: rgovos...@gmail.com
> 
> Dear Maintainer,
> 
> gpsd and chronyd can communicate via domain sockets such as 
> /var/run/chrony.ttyS0.sock. chronyd creates the sockets and gpsd connects to 
> them.
> 
> However, the AppArmor profile for chronyd is too strict; it only allows the 
> creation of sockets for tty devices, and not pps devices.
> 
> @{run}/chrony.tty{,*}.sock rw,

Indeed, this rule is too restrictive…
 
> The corresponding rules on the gpsd profile are:
> 
> /{,var/}run/chrony.tty{,S,USB,AMA}[0-9]*.sock rw,
> /tmp/chrony.tty{,S,USB,AMA}[0-9]*.sock rw,
> 
> Could these be relaxed to allow /var/run/chrony.*.sock?

…This might be too permissive though. Could you please tell me if changing the
rule to "@{run}/chrony{,.clk}.{tty,pps}*.sock rw," meets your need?
 
> Ryan

Cheers,
Vincent

P.S: run "apparmor_parser -r /etc/apparmor.d/usr.sbin.chronyd" after modifying
the profile.


signature.asc
Description: PGP signature

Bug#1028096: age: Testing migration

[Vincent Blut]

Package: age
Version: 1.0.0-2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Could you please do a source-only upload to allow age migrate into testing?

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCY7hq6QAKCRAQn1qAt/bg
AVptAP9TMNAyQpnB+7u0mdvQbzjlGelr9k3sSEkZA9tFXpLpkgEAwDmxgam8ANTs
m+p88VrIb3ztacANryS/ge7pQ9Z0xww=
=Tdc/
-END PGP SIGNATURE-

Bug#1011079: kitty: New upstream release

[Vincent Blut]

Hi James,

Le 2022-08-03 20:19, James McCoy a écrit :
> On Wed, Aug 03, 2022 at 11:59:55PM +0200, Vincent Blut wrote:
> > Hi James,
> > 
> > Le 2022-05-16 18:11, James McCoy a écrit :
> > > That's because it has new dependencies which aren't packaged yet.  I've
> > > blocked this bug with those, for proper tracking.
> > 
> > We could override upstream choice to make "furo" the default theme for HTML
> > help pages by replacing "html_theme = 'furo'" with "html_theme = 'classic'" 
> > in
> > docs/conf.py.
> 
> Possibly.

furo has been package so the aforementioned override is no longer needed.

> > That would prevent us from depending on "furo" and would leave us
> > with just packaging "sphinx-inline-tabs" to update kitty in Debian.
> 
> Sure, if someone does that, I'll see how overriding the theme works.

And thanks to you we also have sphinx-inline-tabs.
 
> Cheers,
> -- 
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1025076: sphinx-inline-tabs: Source-only upload

[Vincent Blut]

Package: sphinx-inline-tabs
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi James,

Could you please do a source-only upload to let sphinx-inline-tabs migrate in
testing?

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCY4Y4awAKCRAQn1qAt/bg
Afa/AQDaN04ZZep+0i6Y2Vb6coTWge340s/+GJL0x4QIt288HAD9E/jNwBMn0Ki+
SKHdmE220JLCm5bVC0OkG/taxYCM9A0=
=xD0f
-END PGP SIGNATURE-

Bug#1021337: linux-image-5.19.0-2-amd64: Please enable building of the idxd module for the IntelData Accelerator support

[Vincent Blut]

Le 2022-10-06 12:34, Diederik de Haas a écrit :
> Control: severity -1 wishlist
> 
> On donderdag 6 oktober 2022 07:58:35 CEST Gunnar Wolf wrote:
> > Package: linux-image-5.19.0-2-amd64
> > 
> > Specifically, the required configuration options to enable all of its
> > features are:
> >CONFIG_INTEL_IDXD=m
> >CONFIG_INTEL_IDXD_SVM=y
> 
> Is this only applicable for the amd64 architecture or is it useful for others 
> as well?

Since these depend on X86_64, only amd64 is concerned.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1011079: kitty: New upstream release

[Vincent Blut]

Hi James,

Le 2022-05-16 18:11, James McCoy a écrit :
> Control: block -1 by 992743 992745
> 
> On Mon, May 16, 2022 at 05:42:39PM +0200, Vincent Blut wrote:
> > kitty version in testing/unstable is quite old now. Would it be possible to
> > have newer one, please?
> 
> That's because it has new dependencies which aren't packaged yet.  I've
> blocked this bug with those, for proper tracking.

We could override upstream choice to make "furo" the default theme for HTML
help pages by replacing "html_theme = 'furo'" with "html_theme = 'classic'" in
docs/conf.py. That would prevent us from depending on "furo" and would leave us
with just packaging "sphinx-inline-tabs" to update kitty in Debian.
 
> Cheers,
> -- 
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1013895: RTL8188EUS 802.11n Wireless Network Adapter not working on 5.18

[Vincent Blut]

Control: tags -1 moreinfo

Hi,

Le 2022-06-26 23:53, Santiago Ruano Rincón a écrit :
> Package: src:linux
> Version: 5.18.5-1
> Severity: important
> 
> Dear linux maintainers,
> 
> Not sure if this should be filed against firmware-realtek, and sorry if
> that is the case. I have a WiFi USB dongle that doesn't work on linux
> 5.18, but it does work on 5.15.
> 
> You can see this error in the logs below during boot, or when I replug
> the dongle:
> 
>  r8188eu 1-1.2:1.0: _rtw_init_xmit_priv failed
> 
> Maybe this is relevant:
> https://lkml.org/lkml/2022/5/21/527

This patch has been applied upstream to Linux 5.19-rc3 and backported to Linux
5.18.6. While the latter is not yet available in Debian, we have Linux 5.19-rc4
in experimental. Could you please check if it fixes this issue?
 
> Thanks for your work,
> 
>  -- Santiago

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1013882: fails to read certificates not "directly" readable by _chrony user

[Vincent Blut]

Hi Daniel,

Le 2022-06-26 17:45, Daniel Baumann a écrit :
> Package: chrony
> Version: 4.2-2
> 
> Hi,
> 
> thank you for maintaining chrony in Debian.

You're welcome! :-)
 
> When configuring NTS and using letsencrypt, I'd like to have the
> certificates owned by root:ssl-cert with directory permissions set to
> 0750 and file permissions set to 0640.
> 
> For every other daemon used so far, that works perfectly fine when
> putting the daemon user to the ssl-cert group.
> 
> However, with chrony, this does not work. I confirmed that _chrony can
> read the files. Anything but having the files/directories-along-the-path
> either world-readable or readable by _chrony directly does not work.
> 
> It would be nice if this could be fixed, looking at the sources I don't
> see anything obvious that would make it fail though.
> 
> Let me know if you need more information to reproduce it.

The behavior you are describing here is expected. chronyd reads the
certificates and private keys after dropping root privileges. Consequently,
those files need to be readable by the user under which chronyd is running.
 
> Regards,
> Daniel

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1012880: linux: ti omap hw crypto drivers not enabled

[Vincent Blut]

Control: reassign -1 src:linux

Hi,

Le 2022-06-16 17:49, Yu-Tung Chang a écrit :
> Package: linux-image-armmp
> Version: 5.18.0-1
> 
> lookup in debian\config\armhf\config:
> CONFIG_CRYPTO_DEV_OMAP_SHAM=m
> CONFIG_CRYPTO_DEV_OMAP_AES=m
> 
> lookup in /boot/config-5.18.0-1-armmp:
> # CONFIG_CRYPTO_DEV_OMAP is not set
> 
> Drivers not enabled as expected!
 
We are missing CRYPTO_DEV_OMAP, indeed. I'll fix that!

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#944028: ITP: git-delta -- A syntax-highlighting pager for git

[Vincent Blut]

Package: wnpp
Followup-For: Bug #944028
X-Debbugs-Cc: nat...@lovsund.eu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Nathan,

Since there has been no progress on this ITP for over 2 years, I think you can
work on this if you still want to.

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYpkEEgAKCRAQn1qAt/bg
AU7HAPwMbkHxTEyWU3cq4+M/9+3NxLS3XpBdiW5gQhGrjmfQeQD/UTCQLlCaXQbQ
PMnnJrUUnrhICQJJtk03XINP/xmdngg=
=l0NV
-END PGP SIGNATURE-

Bug#1012276: sudo: Usefulness of the --enable-admin-flag configuration option in Debian

[Vincent Blut]

Package: sudo
Version: 1.9.10-3
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

sudo 1.9.10-1 has adopted some changes from Ubuntu, including the activation of
the --enable-admin-flag configuration option.

At the moment, it does not seem valuable to have it enabled in Debian since all
it does is creating the empty sudo_as_admin_successful hidden file in the home
directory of the user calling sudo.

What makes this option interesting in Ubuntu is this code snippet in
/etc/bash.bashrc:

if [ ! -e "$HOME/.sudo_as_admin_successful" ] && [ ! -e "$HOME/.hushlogin" ] ; 
then
case " $(groups) " in *\ admin\ *|*\ sudo\ *)
if [ -x /usr/bin/sudo ]; then
cat <<-EOF
To run a command as administrator (user "root"), use "sudo 
".
See "man sudo_root" for details.

EOF
fi
esac
fi

Until bash in Debian provides this, I propose that we drop this configuration
option (setting 'Defaults !admin_flag' in /etc/sudoers would work too). If this
is acceptable to you, I can send a merge request.


Thanks for your work on sudo,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYpj12wAKCRAQn1qAt/bg
AShHAQCWXBDkaGr9XZPgNOz9ii1mgNwIbOj9clrHrWGWx+ExAgEAwWI1KKjxLSFE
94B2e6FleH9+DdDut1ojgglgyWLrVwA=
=vOFd
-END PGP SIGNATURE-

Bug#1011079: kitty: New upstream release

[Vincent Blut]

Package: kitty
Version: 0.21.2-1+b1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi James,

kitty version in testing/unstable is quite old now. Would it be possible to
have newer one, please?

Thanks for your work,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYoJw7gAKCRAQn1qAt/bg
Afx5AP0aIeVLL+IXXaRUorhOT7z/QSIQVKPd9X/J8WlBGFc9fAEA3rbGNkoMV3as
HSJav6Mqa+5k3ZrCGwxfM9uEHSo6+AY=
=/0jl
-END PGP SIGNATURE-

Bug#1010580: acp drivers

[Vincent Blut]

Hi Mario,

Le 2022-05-04 16:04, Limonciello, Mario a écrit :
> Package: linux
> Version: 5.17.3
> 
> Currently the kernel config by default does not configure these two options:
> # CONFIG_SND_SOC_AMD_ACP5x is not set
> # CONFIG_SND_SOC_AMD_ACP6x is not set
> 
> Ideally these should both be set to "m".
> 
> ACP5x is for supporting the ACP in the Steam Deck.
> ACP6x is for supporting the DMIC in notebooks with Ryzen 6000.

This is on my TODO list.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1010146: modprobe: ERROR: could not insert 'amd_pstate': No such device

[Vincent Blut]

Package: src:linux
Followup-For: Bug #1010146

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Tobias,

The AMD P-State driver has been enabled in linux 5.17.3-1 available in
testing/unstable. The kernel you are using does not include it.

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYmf4nQAKCRAQn1qAt/bg
AatkAP46KeDriC3sYK2cnwBEHUmYdD1CWNhAMYF9Tu4YrMJJTAD+J5NBDxUSddqR
EP80CuI/o9PhPDmNCNZLwYunHwzEPAw=
=Mv1P
-END PGP SIGNATURE-

Bug#1009856: chrony: Support refclock in /etc/chrony/sources.d

[Vincent Blut]

Hi Stephan,

Le 2022-04-19 12:10, Stephan Austermühle a écrit :
> Package: chrony
> Version: 4.0-8+deb11u2
> Severity: important
> 
> Dear Maintainer,
> 
> please consider adding support for 'refclock' in /etc/chrony/sources.d.
> 
> Some compute providers (Azure, Hetzner, KVM) support PTP as a
> high-precision alternative to NTP but that feature requires to
> configure a refclock in chrony.
> 
> Example (works for Azure, Hetzner, and KVM):
> 
>   refclock PHC /dev/ptp0 poll 2 dpoll -2 offset 0
> 
> Note that using PTP usually requires loading a corresponding Linux
> kernel module, too (e.g., ptp_kvm).

Please specify your hardware reference clock in /etc/chrony/chrony.conf.
Only NTP sources (i.e. sources declared by the peer, pool and server
directives) can be specified in /etc/chrony/sources.d.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1009018: linux-image-5.16.0-5-amd64: Shutdown, reboot, and suspend broken on chromebook when module cros_ec_typec is loaded.

[Vincent Blut]

Version: 5.17.3-1

Hi,

Le 2022-04-05 18:23, Dan Bassett a écrit :
> Package: src:linux
> Version: 5.16.14-1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: b...@fizix.org
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
>I upgraded my system from Stable (5.10 kernel) to Testing in order
>to get sound working, however, upon upgrade, my system was no longer
>able to shutdown, reboot, or suspend properly.  All of these actions
>would result in the system hanging, requiring a hard reset.
> 
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>I manually built a series of kernels to try to narrow down where
>the issue was occuring and found that when I disabled the building of
>chromebook related platform drivers, my system would happily reboot
>and suspend.  I also noticed that the kernel was throwing an error 
>at boot when attempting to load the cros_ec_typec module.  Given this
>information, I attempted to boot the stock debian kernel
>(5.16.0-5-amd64) with the option module_blacklist=cros_ec_typec,
>which resulted in a system that rebooted and suspended as expected.
>I am unaware of any functionality that I may be losing by not loading
>the cros_ec_typec module.
> 
> 
>* What was the outcome of this action?
> 
>I have a working system, though ideally this module would properly
>load on boot (as my hardware configuration seems to want it), and not
>break shutdown/reboot/suspend.
> 
> 
>* What outcome did you expect instead?
> 
>The system should work without disabling relevant kernel modules.

Dan confirmed to me privately that this issue has been fixed in Linux 5.17.3.
Closing!

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1008973: linux-image-amd64: Very slow wireless with MEDIATEK 7961

[Vincent Blut]

Control: tags -1 moreinfo

Hi,

Le 2022-04-05 14:39, Xavier Chantry a écrit :
> Package: linux-image-amd64
> Version: 5.10.84-1
> Severity: important
> X-Debbugs-Cc: chantry.xav...@gmail.com
> 
> Dear Maintainer,
> 
> We have a problem with MEDIATEK 7961 wireless on Levono P14s with AMD
> Ryzen.
> 
> With 5.10 kernel on debian stable the wireless just does not work, so we
> installed kernel 5.16 from testing.
> 
> With kernel 5.16 the wireless is so slow that it's unusable, each
> internet query takes several seconds. A simple ping to google.com varies
> from 100ms to 3000ms.
> 
> With kernel 5.17 it's slighly better but the ping still goes up to
> 600ms.
> 
> With kernel 5.15 however, it works quite good, Internet is very usable,
> ping varies from 3ms to 30ms.
> (on the same network, the P14s with Intel wireless does better and is
> always under 10ms).
> 
> It looks like big changes were made to the mt7921e driver in 5.16
> according to Phoronix :
> The Mediatek MT7921 WiFi driver has added support for 6GHz WiFi, active
> state power management (ASPM), and other improvements.
> 
> And it looks like this caused a big regression with MEDIATEK 7961.
> 
> Besides the network performance problem on 5.16, suspend/resume is also
> broken, while it works perfectly on 5.15.

Le 2022-04-06 10:19, Christoph Martin a écrit :
> I have the same Problem with an P14s and Mediathek 7921e.
> There is even about 30% package loss.
> 
> Christoph
> 
> Am 05.04.22 um 14:39 schrieb Xavier Chantry:
> > 
> > With kernel 5.16 the wireless is so slow that it's unusable, each
> > internet query takes several seconds. A simple ping to google.com varies
> > from 100ms to 3000ms.
> > 
> > With kernel 5.17 it's slighly better but the ping still goes up to
> > 600ms.

Le 2022-04-15 14:19, Julien Negros a écrit :
> Hi,
> 
> Same issue here, switching to linux-image-5.15.0-0.bpo.3-amd64 did the
> trick. Hope the next kernel version fixes this problem !
> 
> Cheers
> -- 
> Julien Négros
 
Linux 5.17.3 (uploaded to unstable earlier today) includes a lot of fixes for
Mediatek WLAN devices. Could you please check if that kernel fixes the slowness
you are seeing?

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1009299: linux-image-5.16.0-6-amd64: 5.16 breaks buttons below touchpad on Dell Precision 7550

[Vincent Blut]

Hi Marc,

Le 2022-04-11 09:59, Marc Glisse a écrit :
> Package: src:linux
> Version: 5.16.18-1
> Severity: normal
> 
> Dear Maintainer,
> 
> the Dell Precision 7550 is a laptop which has a touchpad, and below it 3
> physical buttons. If I boot with linux-image-5.15.0-3-amd64, these
> buttons work perfectly well. However, with linux-image-5.16.0-6-amd64,
> the right button does not work. Running xev, it prints nothing when I
> click that button. evemu-record does see something when I click on the
> right button, here are some random parts of its log
> 
> # DMI: 
> dmi:bvnDellInc.:bvr1.12.0:bd12/12/2021:br1.12:svnDellInc.:pnPrecision7550:pvr:rvnDellInc.:rn01PXFR:rvrA00:cvnDellInc.:ct10:cvr:sku09C3:
> # Input device name: "DELL09C3:00 0488:120A Touchpad"
> # Input device ID: bus 0x18 vendor 0x488 product 0x120a version 0x100
> 
> #   Event type 1 (EV_KEY)
> # Event code 272 (BTN_LEFT)
> # Event code 325 (BTN_TOOL_FINGER)
> # Event code 328 (BTN_TOOL_QUINTTAP)
> # Event code 330 (BTN_TOUCH)
> # Event code 333 (BTN_TOOL_DOUBLETAP)
> # Event code 334 (BTN_TOOL_TRIPLETAP)
> # Event code 335 (BTN_TOOL_QUADTAP)
> 
> # Properties:
> #   Property  type 0 (INPUT_PROP_POINTER)
> #   Property  type 2 (INPUT_PROP_BUTTONPAD)
> 
> E: 0.01 0004 0005   # EV_MSC / MSC_TIMESTAMP0
> E: 0.01     #  SYN_REPORT (0) -- +0ms
> E: 0.001257 0004 0005 4400  # EV_MSC / MSC_TIMESTAMP4400
> E: 0.001257     #  SYN_REPORT (0) -- +1ms
> E: 0.002600 0004 0005 8900  # EV_MSC / MSC_TIMESTAMP8900
> E: 0.002600     #  SYN_REPORT (0) -- +1ms
> E: 0.004029 0004 0005 13300 # EV_MSC / MSC_TIMESTAMP13300
> [...]
> 
> The buttons were always a bit strange (see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980376).
> 
> syslog (or Xorg.0.log) has, among other things
> 
> Apr 11 08:44:23 hippo /usr/libexec/gdm-x-session[1418]: (II) event23 - 
> DELL09C3:00 0488:120A Touchpad: is tagged by udev as: Touchpad
> Apr 11 08:44:23 hippo /usr/libexec/gdm-x-session[1418]: (EE) event23 - 
> DELL09C3:00 0488:120A Touchpad: kernel bug: missing right button, assuming it 
> is a clickpad.
> Apr 11 08:44:23 hippo /usr/libexec/gdm-x-session[1418]: (II) event23 - 
> DELL09C3:00 0488:120A Touchpad: device is a touchpad
> 
> Please let me know any logs I should attach to help.

The fix [1] for this issue has been applied to the last upstream stable
kernels so it should find its way in Debian relatively soon.

Cheers,
Vincent

[1] 
https://lore.kernel.org/all/20220321184404.20025-1-jose.exposit...@gmail.com/


signature.asc
Description: PGP signature

Bug#1009302: linux-image-5.17.0-trunk-amd64: Missing CONFIG_X86_AMD_PSTATE=m module

[Vincent Blut]

Control: tags -1 pending

Hi,

Le 2022-04-11 10:52, Tobias Koeck a écrit :
> Package: src:linux
> Version: 5.17.1-1~exp1
> Severity: important
> 
> Dear Maintainer,
> 
> the
> 
> CONFIG_X86_AMD_PSTATE
> 
> module is not set.
> 
> https://www.phoronix.com/scan.php?page=news_item=AMD-P-State-How-To
> 
> Can you add it to the kernel so that it is possible to use AMD's power
> management?

This is pending.

https://salsa.debian.org/kernel-team/linux/-/commit/2ee8b17f8d9cf15a02bf373b7eca5bade354abaf

> Greetings and thanks,
> Tobias

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1009018: linux-image-5.16.0-5-amd64: Shutdown, reboot, and suspend broken on chromebook when module cros_ec_typec is loaded.

[Vincent Blut]

Le 2022-04-06 14:02, Vincent Blut a écrit :
> Hi Dan,
> 
> Le 2022-04-05 18:23, Dan Bassett a écrit :
> > Package: src:linux
> > Version: 5.16.14-1
> > Severity: normal
> > Tags: upstream
> > X-Debbugs-Cc: b...@fizix.org
> > 
> > Dear Maintainer,
> > 
> >* What led up to the situation?
> > 
> >I upgraded my system from Stable (5.10 kernel) to Testing in order
> >to get sound working, however, upon upgrade, my system was no longer
> >able to shutdown, reboot, or suspend properly.  All of these actions
> >would result in the system hanging, requiring a hard reset.
> > 
> > 
> >* What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > 
> >I manually built a series of kernels to try to narrow down where
> >the issue was occuring and found that when I disabled the building of
> >chromebook related platform drivers, my system would happily reboot
> >and suspend.  I also noticed that the kernel was throwing an error 
> >at boot when attempting to load the cros_ec_typec module.  Given this
> >information, I attempted to boot the stock debian kernel
> >(5.16.0-5-amd64) with the option module_blacklist=cros_ec_typec,
> >which resulted in a system that rebooted and suspended as expected.
> >I am unaware of any functionality that I may be losing by not loading
> >the cros_ec_typec module.
> > 
> > 
> >* What was the outcome of this action?
> > 
> >I have a working system, though ideally this module would properly
> >load on boot (as my hardware configuration seems to want it), and not
> >break shutdown/reboot/suspend.
> > 
> > 
> >* What outcome did you expect instead?
> > 
> >The system should work without disabling relevant kernel modules.
> 
> I think [1], currently applied to Linux 5.18-rc1, will fix this issue.
> 
> Prashant, Benson, should this patch be applied to Linux 5.7+?

I just noticed that it has been commited to the relevant stable trees. Sorry
for the noise!


signature.asc
Description: PGP signature

Bug#1009018: linux-image-5.16.0-5-amd64: Shutdown, reboot, and suspend broken on chromebook when module cros_ec_typec is loaded.

[Vincent Blut]

Hi Dan,

Le 2022-04-05 18:23, Dan Bassett a écrit :
> Package: src:linux
> Version: 5.16.14-1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: b...@fizix.org
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
>I upgraded my system from Stable (5.10 kernel) to Testing in order
>to get sound working, however, upon upgrade, my system was no longer
>able to shutdown, reboot, or suspend properly.  All of these actions
>would result in the system hanging, requiring a hard reset.
> 
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>I manually built a series of kernels to try to narrow down where
>the issue was occuring and found that when I disabled the building of
>chromebook related platform drivers, my system would happily reboot
>and suspend.  I also noticed that the kernel was throwing an error 
>at boot when attempting to load the cros_ec_typec module.  Given this
>information, I attempted to boot the stock debian kernel
>(5.16.0-5-amd64) with the option module_blacklist=cros_ec_typec,
>which resulted in a system that rebooted and suspended as expected.
>I am unaware of any functionality that I may be losing by not loading
>the cros_ec_typec module.
> 
> 
>* What was the outcome of this action?
> 
>I have a working system, though ideally this module would properly
>load on boot (as my hardware configuration seems to want it), and not
>break shutdown/reboot/suspend.
> 
> 
>* What outcome did you expect instead?
> 
>The system should work without disabling relevant kernel modules.

I think [1], currently applied to Linux 5.18-rc1, will fix this issue.

Prashant, Benson, should this patch be applied to Linux 5.7+?

Cheers,
Vincent

[1] https://lore.kernel.org/all/20220126190219.3095419-1-pmal...@chromium.org/


signature.asc
Description: PGP signature

Bug#1007747: bullseye-pu: package chrony/4.0-8+deb11u2

[Vincent Blut]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

[ Reason ]
The AppArmor profile for chronyd does not include a rule to read the chronyd
configuration file generated by the timemaster program.

[ Impact ]
Without the proposed fix, users must override the Apparmor profile (or at worse
set the profile to complain mode) to flowlessly use chronyd with timemaster.

[ Tests ]
I checked that AppArmor no longer sends 'denied' log entries as seen in
#1004745 when using chronyd with timemaster.

[ Risks ]
Low. An equivalent fix sits in testing/unstable for over a month now without
any regression so far.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Adding a rule in the AppArmor profile to allow chronyd to read the
configuration file /run/timemaster/chrony.conf

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYjEp0AAKCRAQn1qAt/bg
AT7sAQDwqm/E7R4J1CelQmf5dq9+BUU5BRzBxgboHwcfU6N1WwD/Scx21KLyOQdJ
89J1VMvMWWCQDPENpd8SLsVGwEDrPwY=
=L1xq
-END PGP SIGNATURE-
diff -Nru chrony-4.0/debian/changelog chrony-4.0/debian/changelog
--- chrony-4.0/debian/changelog 2021-10-19 22:02:40.0 +0200
+++ chrony-4.0/debian/changelog 2022-03-14 22:17:25.0 +0100
@@ -1,3 +1,11 @@
+chrony (4.0-8+deb11u2) bullseye; urgency=medium
+
+  * debian/usr.sbin.chronyd:
+- Allow reading the chronyd configuration file that timemaster(8)
+generates. Thanks to Michael Lestinsky for the report! (Closes: #1004745)
+
+ -- Vincent Blut   Mon, 14 Mar 2022 22:17:25 +0100
+
 chrony (4.0-8+deb11u1) bullseye; urgency=medium
 
   * debian/patches/:
diff -Nru chrony-4.0/debian/usr.sbin.chronyd chrony-4.0/debian/usr.sbin.chronyd
--- chrony-4.0/debian/usr.sbin.chronyd  2021-10-19 22:02:40.0 +0200
+++ chrony-4.0/debian/usr.sbin.chronyd  2022-03-14 22:17:25.0 +0100
@@ -67,6 +67,9 @@
   /dev/pps[0-9]* rw,
   /dev/ptp[0-9]* rw,
 
+  # Allow reading the chronyd configuration file that timemaster(8) generates
+  @{run}/timemaster/chrony.conf r,
+
   # For use with clocks that report via shared memory (e.g. gpsd),
   # you may need to give ntpd access to all of shared memory, though
   # this can be considered dangerous. See https://launchpad.net/bugs/722815

Bug#1007745: buster-pu: package chrony/3.4-4+deb10u2

[Vincent Blut]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

[ Reason ]
The AppArmor profile for chronyd does not include a rule to read the chronyd
configuration file generated by the timemaster program.

[ Impact ]
Without the proposed fix, users must override the Apparmor profile (or at worse
set the profile to complain mode) to flowlessly use chronyd with timemaster.

[ Tests ]
I checked that AppArmor no longer sends 'denied' log entries as seen in 
#1004745 when using chronyd with timemaster.

[ Risks ]
Low. An equivalent fix sits in testing/unstable for over a month now without
any regression so far.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Adding a rule in the AppArmor profile to allow chronyd to read the
configuration file /run/timemaster/chrony.conf

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYjEhAwAKCRAQn1qAt/bg
ARIMAQDhOqCNkBnilT1AOQfJKVilWa909Qm/lfAPopWsSnBmHgEAoUTteuwrv0HM
Q/mTQmEg0kLhzYZ3BoujiNnP5iGHqgk=
=bn+y
-END PGP SIGNATURE-
diff -Nru chrony-3.4/debian/changelog chrony-3.4/debian/changelog
--- chrony-3.4/debian/changelog 2020-09-16 13:44:04.0 +0200
+++ chrony-3.4/debian/changelog 2022-03-15 13:45:14.0 +0100
@@ -1,3 +1,11 @@
+chrony (3.4-4+deb10u2) buster; urgency=medium
+
+  * debian/usr.sbin.chronyd:
+- Allow reading the chronyd configuration file that timemaster(8)
+generates. Thanks to Michael Lestinsky for the report! (Closes: #1004745)
+
+ -- Vincent Blut   Tue, 15 Mar 2022 13:45:14 +0100
+
 chrony (3.4-4+deb10u1) buster; urgency=medium
 
   * debian/patches/:
diff -Nru chrony-3.4/debian/usr.sbin.chronyd chrony-3.4/debian/usr.sbin.chronyd
--- chrony-3.4/debian/usr.sbin.chronyd  2020-09-16 13:44:04.0 +0200
+++ chrony-3.4/debian/usr.sbin.chronyd  2022-03-15 13:45:14.0 +0100
@@ -50,6 +50,9 @@
   /dev/pps[0-9]* rw,
   /dev/ptp[0-9]* rw,
 
+  # Allow reading the chronyd configuration file that timemaster(8) generates
+  /{,var/}run/timemaster/chrony.conf r,
+
   # For use with clocks that report via shared memory (e.g. gpsd),
   # you may need to give ntpd access to all of shared memory, though
   # this can be considered dangerous. See https://launchpad.net/bugs/722815

Bug#1007725: linux-image-5.16.0-4-amd64: Intel Alder Lake-P audio device not detected correctly

[Vincent Blut]

Control: tags -1 moreinfo

Hi,

Le 2022-03-15 17:55, Sean Clarke a écrit :
> Package: src:linux
> Version: 5.16.12-1
> Severity: important
> X-Debbugs-Cc: sean.cla...@sec-consulting.co.uk
> 
> Dear Maintainer,
> 
> New Alienware X15 R2 with Alder Lake-P sound. Sound not detceted, no options 
> or
> device shown in alsa.

It seems the firmware-sof-signed package is missing. Please install it and
report back!

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1007722: linux-image-5.16.0-4-amd64: Intel Killer WIFI AX1675 not working (not detected / identified / firmware doesn't load)

[Vincent Blut]

Control: tags -1 moreinfo

Hi,

Le 2022-03-15 17:40, Sean Clarke a écrit :
> Package: src:linux
> Version: 5.16.12-1
> Severity: important
> X-Debbugs-Cc: sean.cla...@sec-consulting.co.uk
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
> New Alienware installed with Debian Bookworm/Testing. WiFi not detected
> correctly and not showing as available

Looking at the device ID (8086:51f0), it should be supported starting with
Linux 5.17 [1]. Could you please install linux-image-5.17.0-rc8 from
experimental and report back?

Cheers,
Vincent


[1] 
https://lore.kernel.org/all/iwlwifi.20211219132536.2d5bec2d7b68.Icffb4e27390e6a5c76a0cbe7abf7472558f323d6@changeid/


signature.asc
Description: PGP signature

Bug#1006490: linux-image-5.16.0-1-amd64: hid-playstation.ko is missing

[Vincent Blut]

Hi Anton,

Le 2022-02-26 13:21, Anton Shestakov a écrit :
> Package: src:linux
> Version: 5.16.7-2
> Severity: normal
> X-Debbugs-Cc: a...@dwimlabs.net
> 
> Dear Maintainer,
> 
> On linux-image-5.15.0-3-amd64 there's a hid-playstation.ko module that 
> supports
> DualSense (PS5) controller, but it's missing from linux-image-5.16.0-1-amd64:
> 
> # dpkg -L linux-image-5.15.0-3-amd64 | fgrep hid-playstation
> /lib/modules/5.15.0-3-amd64/kernel/drivers/hid/hid-playstation.ko
> # dpkg -L linux-image-5.16.0-1-amd64 | fgrep hid-playstation
> 
> (Also missing from linux-image-5.16.0-2-amd64.)
> 
> Because of this, a different driver is used for the controller (I assume it's
> hid-generic), and so accelerometer/gyro and touchpad are not supported, and 
> the
> buttons/axes are in a strange order.
> 
> After looking at #1006275 and the patch that fixed it, I found that the older
> kernel config file also used to contain CONFIG_HID_PLAYSTATION=m and
> CONFIG_PLAYSTATION_FF=y. Please consider re-enabling these options too.

Indeed, this driver now depends on LEDS_CLASS_MULTICOLOR which is disabled in
our kernel config. I'll fix this!

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1006397: liquidctl: New upstream release

[Vincent Blut]

Package: liquidctl
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Laszlo,

To benefit from bug fixes and new hardware support, it would be awesome if you
could release a new upstream version in Debian.

Thanks for your work,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYhgC6wAKCRAQn1qAt/bg
AWqHAQDPhFZCMWJfwXAuqQN95SNWZoSr63uhCOtHtkVsf/v3XwEAyjDpqrtcMkMD
zYRwKYDRmKMSxzafVkNzAFVcdZYH7wE=
=f040
-END PGP SIGNATURE-

Bug#1004745: chrony (Debian Bullseye)

[Vincent Blut]

Control: tags -1 - moreinfo + pending

Le 2022-02-01 19:43, Michael Lestinsky a écrit :
> On 01.02.22 19:30, Vincent Blut wrote:
> > Control: tags -1 moreinfo
> > 
> > Hi Michael,
> > 
> > Le 2022-02-01 15:43, Michael Lestinsky a écrit :
> > > Package: chrony
> > > Version: 4.0.8+deb11u1
> > > 
> > > Dear everyone,
> > > 
> > > thank you for maintaining the chrony package. While tinkering with a PTP
> > > setup, I discovered a slight inconsistency in the default configuration.
> > > Maybe the maintainers would like to consider the following suggestion:
> > > 
> > > --- etc/apparmor.d/usr.sbin.chronyd   2021-10-19 22:02:40.0 
> > > +0200
> > > +++ /etc/apparmor.d/usr.sbin.chronyd  2022-01-27 17:13:59.249409806 
> > > +0100
> > > @@ -41,6 +41,7 @@
> > >  /etc/chrony/{,**} r,
> > >  /var/lib/chrony/{,*} rw,
> > >  /var/log/chrony/{,*} rw,
> > > +  @{run}/timemaster/chrony.conf r,
> > >  @{run}/chrony/{,*} rw,
> > >  @{run}/chrony-dhcp/{,*} r,
> > 
> > Looks good! For the avoidance of doubt, could you please show the denied log
> > entry AppArmor generates when the above rule is missing?
> > 
> > > Best,
> > > Michael
> > 
> > Cheers,
> > Vincent
> 
> Dear Vinzenz,
> 
> of course. I found lines like this repeating...
> 
> /var/log/syslog.1:Jan 27 16:32:53 atppc025 kernel: [76912.418852] audit:
> type=1400 audit(1643297573.801:17): apparmor="DENIED" operation="open"
> profile="/usr/sbin/chronyd" name="/run/timemaster/chrony.conf" pid=219959
> comm="chronyd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

Great! Thanks Michael. This issue will first be fixed in testing/unstable and
then in bullseye and buster. Since the next point releases for those two is not
yet planned, you'll have to override the shipped Apparmor profile in the
meantime.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1004745: chrony (Debian Bullseye)

[Vincent Blut]

Control: tags -1 moreinfo

Hi Michael,

Le 2022-02-01 15:43, Michael Lestinsky a écrit :
> Package: chrony
> Version: 4.0.8+deb11u1
> 
> Dear everyone,
> 
> thank you for maintaining the chrony package. While tinkering with a PTP
> setup, I discovered a slight inconsistency in the default configuration.
> Maybe the maintainers would like to consider the following suggestion:
> 
> --- etc/apparmor.d/usr.sbin.chronyd   2021-10-19 22:02:40.0 +0200
> +++ /etc/apparmor.d/usr.sbin.chronyd  2022-01-27 17:13:59.249409806 +0100
> @@ -41,6 +41,7 @@
> /etc/chrony/{,**} r,
> /var/lib/chrony/{,*} rw,
> /var/log/chrony/{,*} rw,
> +  @{run}/timemaster/chrony.conf r,
> @{run}/chrony/{,*} rw,
> @{run}/chrony-dhcp/{,*} r,

Looks good! For the avoidance of doubt, could you please show the denied log
entry AppArmor generates when the above rule is missing?

> Best,
> Michael

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1002460: linux-image-amd64: Missing kernel configuration for Microsoft Laptops and Surface devices

[Vincent Blut]

Le 2021-12-22 14:07, Matthias Brennwald a écrit :
> Full details (including a suggested fix) are available here:
> https://github.com/linux-surface/linux-surface/issues/683

I need a clarification about CONFIG_SURFACE_AGGREGATOR_CDEV. This options' 
help text mentions that it is intended for debugging and development only, 
and should not be used otherwise. Is it really needed?

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#1002460: linux-image-amd64: Missing kernel configuration for Microsoft Laptops and Surface devices

[Vincent Blut]

Control: reassign -1 src:linux

Hi Matthias,

Le 2021-12-22 14:07, Matthias Brennwald a écrit :
> Package: linux-image-amd64
> Version: 5.15.5-1
> Severity: normal
> X-Debbugs-Cc: mbren...@gmail.com
> 
> Dear Maintainer,
> 
> Some features for Linux on Microsoft Laptops and Surface devices that were
> implemented in the 5.13+ Linux kernel are not configured with the kernels
> provided by Debian.
> 
> Full details (including a suggested fix) are available here:
> https://github.com/linux-surface/linux-surface/issues/683

I'll work on this later today.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#998627: linux: please enable the new NTFS3 driver in 5.15

[Vincent Blut]

Le 2021-11-23 22:34, Salvatore Bonaccorso a écrit :
> Hi,
> 
> On Tue, Nov 23, 2021 at 12:37:02PM +0100, Vincent Blut wrote:
> > Hi,
> > 
> > Le 2021-11-22 18:54, Boyuan Yang a écrit :
> > > Hi,
> > > 
> > > On Fri, 5 Nov 2021 16:55:33 +0800 Wenbin Lv  wrote:
> > > > Package: src:linux
> > > > Version: 5.15-1~exp1
> > > > Severity: wishlist
> > > > 
> > > > Hi,
> > > > Paragon's NTFS3 driver has been merged to 5.15, and it offers much
> > > > better performance compared to ntfs-3g. Currently it is not enabled in
> > > > Debian's kernel config, nor can I mount NTFS partitions using '-t
> > > > ntfs3'.
> > > > Please enable it if you consider it stable enough. Thank you!
> > > 
> > > Now that 5.15 has been uploaded to Unstable, this issue will attract wider
> > > attention. Please consider enabling it in future uploads.
> > 
> > I'll send a merge request to the kernel team later today.
> 
> Are tools available to handle creation and checking of such NTFS3
> filesystems?

Not yet AFAIK.

> The last time I went to the paragon software site it mentioned it was
> planning. This is not a must, but kept me for slightly on the on hold
> position for enabling it.

Understandable! Let's hold off for the moment then.
 
> Regards,
> Salvatore

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#998627: linux: please enable the new NTFS3 driver in 5.15

[Vincent Blut]

Hi,

Le 2021-11-22 18:54, Boyuan Yang a écrit :
> Hi,
> 
> On Fri, 5 Nov 2021 16:55:33 +0800 Wenbin Lv  wrote:
> > Package: src:linux
> > Version: 5.15-1~exp1
> > Severity: wishlist
> > 
> > Hi,
> > Paragon's NTFS3 driver has been merged to 5.15, and it offers much
> > better performance compared to ntfs-3g. Currently it is not enabled in
> > Debian's kernel config, nor can I mount NTFS partitions using '-t
> > ntfs3'.
> > Please enable it if you consider it stable enough. Thank you!
> 
> Now that 5.15 has been uploaded to Unstable, this issue will attract wider
> attention. Please consider enabling it in future uploads.

I'll send a merge request to the kernel team later today.

> Thanks!
> Boyuan Yang

Have a good day,
Vincent


signature.asc
Description: PGP signature

Bug#997907: linux-image-arm64: CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER unset in 5.14 kernel

[Vincent Blut]

Hi,

Le 2021-10-26 17:33, Zameer Manji a écrit :
> On Tue, Oct 26, 2021 at 5:05 PM Vincent Blut  wrote:
> 
> > Control: reassign -1 src:linux
> >
> > Hi,
> >
> > Le 2021-10-26 20:44, Zameer Manji a écrit :
> > > Package: linux-image-arm64
> > > Version: 5.14.9-2
> > > Severity: important
> > >
> > > Dear Maintainer,
> > >
> > > In bullseye, version 5.10.70-1 has the
> > CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
> > > kernel configuration set to 'y'. In bookworm it is unset which disable
> > this feature.
> > >
> > > This kernel configuration parameter allows for the EFI stub of the
> > kernel to
> > > parse and use a 'initrd=' parameter to set up an initrd when booting
> > from EFI.
> > > Boot loaders like 'systemd-boot' or 'refind' set this parameter if
> > configured
> > > to pass an initrd. If the kernel configuration parameter is unset, the
> > > `initrd=` paramater is ignored, and can result in an unbootable system
> > because
> > > the initrd has not setup the root filesystem.
> > >
> > > Without the kernel configuaration set, it is not possible to use
> > 'systemd-boot'
> > > or 'refind' on arm64 as both of these bootloaders assume the kernel will
> > > handle the 'initrd=' flag and setup the initrd.
> > >
> > > Please consider enabling CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER on
> > > arm64 so using 'systemd-boot' or 'refind' can continue to work. Until
> > these
> > > bootloaders have been updated to use an alternative method of passing the
> > > initrd to the EFI stub, it is not possible to have a booting system.
> >
> > Except on X86, EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is no longer enabled
> > by
> > default. Please see [1] for some details.
> >
> > Cheers,
> > Vincent
> >
> > [1]
> > https://gitlab.com/linux-kernel/stable/-/commit/6edcf9dc2e1aff3aa1f5a69ee420fb30dd0e968a
> >
>
> Hello Vincent,
> 
> I see and understand the rationale of upstream to deprecate this
> functionality.
> >From the commit you linked I see another commit [0] which says:
> 
> > Loading an initrd passed via the kernel command line is deprecated: it
> > is limited to files that reside in the same volume as the one the kernel
> > itself was loaded from, and we have more flexible ways to achieve the
> > same. So make it configurable so new architectures can decide not to
> > enable it.
> 
> I assume the 'more flexible ways' to do the same is referencing this
> feature [1]
> which is indeed more flexible. The problem is that the firmware/bootloader
> must
> support this new functionality, by populating the right EFI file with the
> right GUID.
> 
> As far as I can see on arm64 there are three EFI bootloaders:
> * GRUB2
> * systemd-boot
> * refind
> 
> Both systemd-boot and refind do not yet support this new mechanism,
> although I see
> that systemd has some unreleased code [2] to support the new way. I have
> not been
> able to test GRUB2 but my understanding is that this new method is still
> under active
> development [3].
> 
> The problem is that upstream has deprecated this functionality by assuming
> the only
> active use was x86, but was completely possible to use it on arm64 (it
> works fine for me
> on bullseye). Since EFI bootloaders have not yet implemented the new way,
> and still
> rely on this deprecated method on all architectures, it results in
> unbootable systems
> on arm64.
> 
> I would 100% think this should remain disabled on arm64 if most EFI
> bootloaders
> supported the new way, but unfortunately they do not.
> 
> I hope you would consider enabling this kernel configuration for arm64
> until EFI
> bootloaders catch up to the recommended way.
> 
> 
> [0]
> https://gitlab.com/linux-kernel/stable/-/commit/cf6b83664895a5c7e97710df282e220bd047f0f5
> [1]
> https://gitlab.com/linux-kernel/stable/-/commit/ec93fc371f014a6fb483e3556061ecad4b40735c
> [2]
> https://github.com/systemd/systemd/commit/a6089431d52adda93eec251a3df0dffa1fe0661a#diff-76eb4030e88f340c9133388f17c65774b0f17a0a8105500978f6ce18ca1deb5a
> [3] https://www.mail-archive.com/grub-devel@gnu.org/msg32272.html
 
Salvatore, I tend to agree with Zameer. I think we should explicitly enable 
EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER until the support for loading initrd
from a device path is widespread among bootloaders.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#999589: ITP: catatonit -- Lightweight init implementation for containers

[Vincent Blut]

Hi Reinhard,

Le 2021-11-12 16:07, Reinhard Tartler a écrit :
> Package: wnpp
> Owner: Reinhard Tartler 
> Severity: wishlist
> 
> * Package name: catatonit
>   Version : 0.1.7
>   Upstream Author : 2018 SUSE LLC
> * URL or Web page : https://github.com/openSUSE/catatonit
> * License : GPLv3
>   Description : Lightweight init implementation for containers
> 
> A container init that is so simple it's effectively brain-dead. This is a
> rewrite of [initrs][initrs] in C, because we found that it is not possible to
> statically compile Rust binaries without using musl. That was, in turn, a
> reimplementation of other container inits like `tini` and `dumb-init`.
> 
> The reason for re-implementing `docker-init` is because it appears as though
> all of the other implementations do not handle signals as correctly as they
> should. In particular, they all appear to make use of `sigwait(2)` (`tini` 
> does
> a `sigtimedwait(2)` for an interval and then will do a `waitpid(2)` even if it
> didn't detect a `SIGCHLD`). `catatonit` uses `signalfd(2)`, which [has its own
> warts][signalfd-broken], but the improvements over `sigwait(2)` are 
> significant
> in terms of stability. Ideally we would just write a patch for the other
> projects to use `signalfd(2)` rather than creating a new project, but after
> some time spent looking at `tini` and `dumb-init` we felt that such patches
> would be closer to full rewrites.
> 
> In addition, the purpose of `catatonit` is to only support the key usage by
> `docker-init` which is `/dev/init -- `. With few exceptions, no
> other features will be added.
> 
> Co-maintainers welcome!

catatonit is already available in Debian.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#997907: linux-image-arm64: CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER unset in 5.14 kernel

[Vincent Blut]

Control: reassign -1 src:linux

Hi,

Le 2021-10-26 20:44, Zameer Manji a écrit :
> Package: linux-image-arm64
> Version: 5.14.9-2
> Severity: important
> 
> Dear Maintainer,
> 
> In bullseye, version 5.10.70-1 has the 
> CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
> kernel configuration set to 'y'. In bookworm it is unset which disable this 
> feature.
> 
> This kernel configuration parameter allows for the EFI stub of the kernel to
> parse and use a 'initrd=' parameter to set up an initrd when booting from EFI.
> Boot loaders like 'systemd-boot' or 'refind' set this parameter if configured
> to pass an initrd. If the kernel configuration parameter is unset, the
> `initrd=` paramater is ignored, and can result in an unbootable system because
> the initrd has not setup the root filesystem.
> 
> Without the kernel configuaration set, it is not possible to use 
> 'systemd-boot'
> or 'refind' on arm64 as both of these bootloaders assume the kernel will
> handle the 'initrd=' flag and setup the initrd.
> 
> Please consider enabling CONFIG_EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER on
> arm64 so using 'systemd-boot' or 'refind' can continue to work. Until these
> bootloaders have been updated to use an alternative method of passing the
> initrd to the EFI stub, it is not possible to have a booting system.
 
Except on X86, EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is no longer enabled by
default. Please see [1] for some details. 

Cheers,
Vincent

[1] 
https://gitlab.com/linux-kernel/stable/-/commit/6edcf9dc2e1aff3aa1f5a69ee420fb30dd0e968a
 


signature.asc
Description: PGP signature

Bug#997597: bullseye-pu: package chrony/4.0-8+deb11u1

[Vincent Blut]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

[ Reason ]
chrony 4.0 allows binding the NTP, NTS-KE, client and UDP command sockets 
to a specific network device using the 'binddevice', 'bindacqdevice' and
'bindcmddevice' directives.
In Bullseye, using these directives with a network interface name longer
than 3 characters (e.g. binddevice eth0) will cause chronyd to crash because
of the way the system call filter handles the SO_BINDTODEVICE socket option.

[ Impact ]
To bind sockets to a network interface with a "long" name, users have to
disable chronyd's system call filter which is certainly not ideal.

[ Tests ]
I manually tested each of the aforementioned directives with a network
interface name longer than 3 characters. I also made sure that autopkgtests
still run fine.

[ Risks ]
The fix is trivial and well tested.

[ Checklist ]
  [ ] *all* changes are documented in the d/changelog
  [✓] I reviewed all changes and I approve them
  [✓] attach debdiff against the package in (old)stable
  [✓] the issue is verified as fixed in unstable

[ Changes ]
In addition to the patch fixing the issue with the system call filter, I also
made a few anecdotal but practical changes that I considered unnecessary to
mention for a revision targetting stable:
- pointing Vcs-Git to the 'debian/bullseye' branch
- running the Salsa CI pipeline on Bullseye

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYXR7MQAKCRAQn1qAt/bg
AVlbAP9ZaHpjsgLA3HNcLPsWJXhMm/SUcU3DgEpdM9nMiJjDJgEAxYspGEhLBnGK
4n5lB38HAKdWm6aY1/VHGAcLZ0X9tQM=
=K28n
-END PGP SIGNATURE-
diff -Nru chrony-4.0/debian/changelog chrony-4.0/debian/changelog
--- chrony-4.0/debian/changelog 2021-05-13 16:51:41.0 +0200
+++ chrony-4.0/debian/changelog 2021-10-19 22:02:40.0 +0200
@@ -1,3 +1,12 @@
+chrony (4.0-8+deb11u1) bullseye; urgency=medium
+
+  * debian/patches/:
+- Add fix-seccomp-filter-for-BINDTODEVICE-socket-option.patch to be able
+to bind a socket to a network device with a name longer than 3 characters
+when the system call filter is enabled. (Closes: #995207)
+
+ -- Vincent Blut   Tue, 19 Oct 2021 22:02:40 +0200
+
 chrony (4.0-8) unstable; urgency=medium
 
   * debian/patches/:
diff -Nru chrony-4.0/debian/control chrony-4.0/debian/control
--- chrony-4.0/debian/control   2021-05-13 16:51:41.0 +0200
+++ chrony-4.0/debian/control   2021-10-19 22:02:40.0 +0200
@@ -18,7 +18,7 @@
pps-tools (>= 0.20120406+g0deb9c7e-2) [linux-any],
procps 
 Homepage: https://chrony.tuxfamily.org
-Vcs-Git: https://salsa.debian.org/debian/chrony.git -b debian/latest
+Vcs-Git: https://salsa.debian.org/debian/chrony.git -b debian/bullseye
 Vcs-Browser: https://salsa.debian.org/debian/chrony
 Rules-Requires-Root: no
 
diff -Nru chrony-4.0/debian/.gitlab-ci.yml chrony-4.0/debian/.gitlab-ci.yml
--- chrony-4.0/debian/.gitlab-ci.yml2021-05-13 16:51:41.0 +0200
+++ chrony-4.0/debian/.gitlab-ci.yml2021-10-19 22:02:40.0 +0200
@@ -9,3 +9,6 @@
 only:
 variables:
 - $SEE_YOU_SOON_REPROTEST
+
+variables:
+RELEASE: 'bullseye'
diff -Nru 
chrony-4.0/debian/patches/fix-seccomp-filter-for-BINDTODEVICE-socket-option.patch
 
chrony-4.0/debian/patches/fix-seccomp-filter-for-BINDTODEVICE-socket-option.patch
--- 
chrony-4.0/debian/patches/fix-seccomp-filter-for-BINDTODEVICE-socket-option.patch
   1970-01-01 01:00:00.0 +0100
+++ 
chrony-4.0/debian/patches/fix-seccomp-filter-for-BINDTODEVICE-socket-option.patch
   2021-10-19 22:02:40.0 +0200
@@ -0,0 +1,33 @@
+From 29d7d3176d9d1b208039a9d2ca3f26bc3cc5a387 Mon Sep 17 00:00:00 2001
+From: Miroslav Lichvar 
+Date: Wed, 6 Oct 2021 10:02:34 +0200
+Subject: sys_linux: fix seccomp filter for BINDTODEVICE option
+
+The BINDTODEVICE socket option is the first option in the seccomp filter
+setting a string instead of int. Remove the length check from the
+setsockopt rules to allow a device name longer than 3 characters.
+
+This was reported in Debian bug #995207.
+
+Fixes: b9f5ce83b02e ("sys_linux: allow BINDTODEVICE option in seccomp filter")
+
+Origin: upstream, 
https://git.tuxfamily.org/chrony/chrony.git/commit/?id=29d7d3176d9d1b208039a9d2ca3f26bc3cc5a387
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995207
+
+Index: chrony/sys_linux.c
+===
+--- chrony.orig/sys_linux.c
 chrony/sys_linux.c
+@@ -694,10 +694,9 @@ SYS_Linux_EnableSystemCallFilter(int lev
+ 
+ /* Allow selected socket options */
+ for (i = 0; i < sizeof (socket_options) / sizeof (*socket_options); i++) {
+-  if (seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(setsockopt), 3,
++  if (seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(setsockopt), 2,
+ 

Bug#989777: Re: Severity: High / Debian 10 amp;amp;amp; 11 with Kernel 5.10.x-amd64 =amp;amp;gt; Intel AX210 Wifi amp;amp;amp; Bluetooth not work

[Vincent Blut]

Hi Philippe,

Le 2021-10-14 14:11, pham...@bluewin.ch a écrit :
> Hello Vincent,
> 
> 
> Finally I had to force the installation of the firmware-iwlwifi 20210818-1 
> for it to work.
> 
> Configuring preferences.d (with files => stable-prioritaire + 
> testing-on-bullseye) and sources.list  (see attached files) was not enough. 
> By the way in Debian 12.1 sources.list is unusually short, it does not 
> contain the "Bullseye base repository" or other directory, which can be very 
> annoying for a beginner user...
> 
> After this manipulation the Bluetooth works +/-. When starting the OS for the 
> first time, Bluetooth is present and working, I can connect my Logitech MX 
> Anywhere 2S mouse but it is impossible to connect a Logitech CRAFT keyboard. 
> Indeed, the Logitech CRAFT keyboard requires the entry of a series of numeric 
> digits to confirm its connection with the OS, but no series of digits is 
> provided by the OS to make this connection, so it fails...

Installing the 'solaar' package should help you pair the keyboard with the
receiver.
 
> After a simple start, the Bluetooth connection no longer works. If I try to 
> start blueman-manager manually I get the following error message :
> 
> 
> philippe@laptop:~$ blueman-manager
> blueman-manager version 2.1.4 starting
> blueman-manager 13.43.01 ERRORManager:118 on_dbus_name_appeared: Default 
> adapter not found, trying first available.
> blueman-manager 13.43.01 ERRORManager:122 on_dbus_name_appeared: No 
> adapter(s) found, exiting
> 
> 
> root@laptop:~# blueman-manager
> Unable to init server: Could not connect: Connection refused
> Unable to init server: Impossible de se connecter : Connection refused
> Traceback (most recent call last):
>   File "/usr/bin/blueman-manager", line 44, in 
> manager = Blueman()
>   File "/usr/lib/python3/dist-packages/blueman/main/Manager.py", line 29, in 
> __init__
> super().__init__(title=_("Bluetooth Devices"))
>   File "/usr/lib/python3/dist-packages/gi/overrides/Gtk.py", line 515, in 
> __init__
> raise RuntimeError(
> RuntimeError: Gtk couldn't be initialized. Use Gtk.init_check() if you want 
> to handle this case.
> 
> 
> In this case if I run the command journalctl -k | grep -Ei 
> 'bluetooth|iwlwifi' I get :
> 
> 
> root@laptop:~# journalctl -k | grep -Ei 'bluetooth|iwlwifi' 
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: enabling device ( -> 
> 0002)
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: firmware: failed to load 
> iwlwifi-ty-a0-gf-a0-64.ucode (-2)
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: Direct firmware load for 
> iwlwifi-ty-a0-gf-a0-64.ucode failed with error -2
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: firmware: direct-loading 
> firmware iwlwifi-ty-a0-gf-a0-63.ucode
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: api flags index 2 larger 
> than supported by driver
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: TLV_FW_FSEQ_VERSION: 
> FSEQ Version: 0.0.2.25
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: loaded firmware version 
> 63.c04f3485.0 ty-a0-gf-a0-63.ucode op_mode iwlmvm
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: firmware: failed to load 
> iwl-debug-yoyo.bin (-2)
> oct 14 13:34:21 laptop kernel: Bluetooth: Core ver 2.22
> oct 14 13:34:21 laptop kernel: NET: Registered PF_BLUETOOTH protocol family
> oct 14 13:34:21 laptop kernel: Bluetooth: HCI device and connection manager 
> initialized
> oct 14 13:34:21 laptop kernel: Bluetooth: HCI socket layer initialized
> oct 14 13:34:21 laptop kernel: Bluetooth: L2CAP socket layer initialized
> oct 14 13:34:21 laptop kernel: Bluetooth: SCO socket layer initialized
> oct 14 13:34:21 laptop kernel: Bluetooth: hci0: Firmware timestamp 2021.28 
> buildtype 1 build 28502
> oct 14 13:34:21 laptop kernel: Bluetooth: hci0: No device address configured
> oct 14 13:34:21 laptop kernel: bluetooth hci0: firmware: direct-loading 
> firmware intel/ibt-0041-0041.sfi
> oct 14 13:34:21 laptop kernel: Bluetooth: hci0: Found device firmware: 
> intel/ibt-0041-0041.sfi
> oct 14 13:34:21 laptop kernel: Bluetooth: hci0: Boot Address: 0x100800
> oct 14 13:34:21 laptop kernel: Bluetooth: hci0: Firmware Version: 86-28.21
> oct 14 13:34:21 laptop kernel: Bluetooth: hci0: Firmware already loaded
> oct 14 13:34:21 laptop kernel: iwlwifi :3b:00.0: Detected Intel(R) Wi-Fi 
> 6 AX210 160MHz, REV=0x420
> oct 14 13:34:22 laptop kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> oct 14 13:34:22 laptop kernel: Bluetooth: BNEP filters: protocol multicast
> oct 14 13:34:22 laptop kernel: Bluetooth: BNEP socket layer initialized
> oct 14 13:34:22 laptop kernel: iwlwifi :3b:00.0: firmware: direct-loading 
> firmware iwlwifi-ty-a0-gf-a0.pnvm
> oct 14 13:34:22 laptop kernel: iwlwifi :3b:00.0: loaded PNVM version 
> 0xd35929d8
> oct 14 13:34:22 laptop kernel: iwlwifi :3b:00.0: Detected RF GF, 
> rfid=0x10d000
> oct 14 13:34:22 laptop kernel: iwlwifi 

Bug#989777: Severity: High / Debian 10 11 with Kernel 5.10.x-amd64 = Intel AX210 Wifi Bluetooth not work

[Vincent Blut]

Salut Philippe,

Le 2021-10-11 23:10, pham...@bluewin.ch a écrit :
> Hello Vincent,
> I installed the 5.14.9-2 kernel: amd64 from testing.
> After reboot I still have to install your old package for my wifi card to be 
> detected :
> https://snapshot.debian.org/archive/debian/20210313T203823Z/pool/non-free/f/firmware-nonfree/firmware-iwlwifi_20210208-4_all.deb

Curious, what does journalctl -k | grep -Ei 'bluetooth|iwlwifi' report when
booting on Linux 5.14.9-2 paired with firmware-iwlwifi 20210818-1?

> As with the 5.10 kernel there is only the Wifi which does not work and the 
> Bluetooth ?!
> I understood that Wifi worked from kernel 5.10 and Bluetooth worked from 
> kernel 5.10 ?!

AFAIR, Wi-Fi should work on Linux 5.10 but bluetooth requires Linux >= 5.11.

> Can you give me some good advice on how to get this damn Intel AX210 card 
> working under Debian 11 Bullseye ??
> Thanks in advance.
> Meilleures salutations.
> Philippe

Bonne journée,
Vincent


signature.asc
Description: PGP signature

Bug#995608: linux-image-5.14.0-1-amd64: Boot immediately hangs.

[Vincent Blut]

Le 2021-10-03 20:58, Salvatore Bonaccorso a écrit :
> Hi Vincent,
> 
> On Sun, Oct 03, 2021 at 03:55:21PM +0200, Vincent Blut wrote:
> > Hi,
> > 
> > Le 2021-10-03 11:40, Nathanael Schweers a écrit :
> > > 
> > > Salvatore Bonaccorso  writes:
> > > 
> > > > Control: tags -1 + moreinfo
> > > >
> > > > Hi Nathanael,
> > > >
> > > > On Sun, Oct 03, 2021 at 10:02:35AM +0200, Nathanael Schweers wrote:
> > > >> Package: src:linux
> > > >> Version: 5.14.6-3
> > > >> Severity: grave
> > > >> Justification: renders package unusable
> > > >>
> > > >> Dear Maintainer,
> > > >>
> > > >> using this kernel, my machine no longer boots.  Instead of showing a 
> > > >> prompt to
> > > >> enter the LUKS passphrase (as is done in version 
> > > >> linux-image-5.10.0-7-amd64) a
> > > >> non-blinking cursor is shown.  Nothing happens afterwards.
> > > >>
> > > >> Version linux-image-5.10.0-7-amd64 still works, but newer versions
> > > >> (linux-image-5.10.0-8-amd64 and the version this report is for) 
> > > >> produce the
> > > >> behaviour mentioned above.
> > > >>
> > > >> I’m afraid that I don’t have a decent idea on what extra information 
> > > >> to provide.
> > > >
> > > > Could you please confirm that booting with the 'mem_encrypt=off'
> > > > kernel command line heps?
> > > 
> > > With this option the kernel does indeed boot.  Thanks for the tip!
> > 
> > Salvatore, given the increase in bug reports that this feature generates,
> > I think it would be sensible to unset AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT 
> > until
> > those incompatibilities are fixed, like I proposed in [1]. One would have to
> > use the "mem_encrypt=on" command line option to enable the AMD Secure Memory
> > Encryption. If it sounds reasonable to you and the rest of the kernel team,
> > I can send a merge request.
> 
> Yes I think at this point is reasonable, as people wanting the feature
> still can enable it, but we do not break usual setups as it has hit
> severral people arleady. Can you post the reference [1], it was not
> included.  No need for a merge request, as I have the change already
> in debian/config/kernelarch-x86/config .

Oops, sorry about that. [1] was supposed to point to 
https://salsa.debian.org/kernel-team/linux/-/merge_requests/322/diffs

> Vincent, thanks for your huge amount of contributions, that is awesome
> :)

You're welcome!

> Regards,
> Salvatore

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#995608: linux-image-5.14.0-1-amd64: Boot immediately hangs.

[Vincent Blut]

Hi,

Le 2021-10-03 11:40, Nathanael Schweers a écrit :
> 
> Salvatore Bonaccorso  writes:
> 
> > Control: tags -1 + moreinfo
> >
> > Hi Nathanael,
> >
> > On Sun, Oct 03, 2021 at 10:02:35AM +0200, Nathanael Schweers wrote:
> >> Package: src:linux
> >> Version: 5.14.6-3
> >> Severity: grave
> >> Justification: renders package unusable
> >>
> >> Dear Maintainer,
> >>
> >> using this kernel, my machine no longer boots.  Instead of showing a 
> >> prompt to
> >> enter the LUKS passphrase (as is done in version 
> >> linux-image-5.10.0-7-amd64) a
> >> non-blinking cursor is shown.  Nothing happens afterwards.
> >>
> >> Version linux-image-5.10.0-7-amd64 still works, but newer versions
> >> (linux-image-5.10.0-8-amd64 and the version this report is for) produce the
> >> behaviour mentioned above.
> >>
> >> I’m afraid that I don’t have a decent idea on what extra information to 
> >> provide.
> >
> > Could you please confirm that booting with the 'mem_encrypt=off'
> > kernel command line heps?
> 
> With this option the kernel does indeed boot.  Thanks for the tip!

Salvatore, given the increase in bug reports that this feature generates,
I think it would be sensible to unset AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT until
those incompatibilities are fixed, like I proposed in [1]. One would have to
use the "mem_encrypt=on" command line option to enable the AMD Secure Memory
Encryption. If it sounds reasonable to you and the rest of the kernel team,
I can send a merge request.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#995207: chrony: Using 'bindacqdevice' directive causes a SIGSYS error

[Vincent Blut]

Le 2021-09-28 12:54, S Egbert a écrit :
> Trying attachment again.

Thanks. To see what happens when blocking only a small number of specific
syscalls, could you please run the following command and attach the
chronyd-debug.txt file?

# timeout 10 strace -o chronyd-debug.txt -e trace=setsockopt chronyd -d -F 2

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#995260: chrony: Mismatched filename for UNIX socket between client and daemon

[Vincent Blut]

Hi,

Le 2021-09-28 11:55, Steve Egbert a écrit :
> Package: chrony
> Version: 4.0-8
> Severity: grave
> Tags: upstream
> Justification: renders package unusable
> X-Debbugs-Cc: s.egb...@sbcglobal.net
> 
> Dear Maintainer,
> 
> 
> The filename construct for a UNIX socket to be shared
> between the Chrony (chronyd) daemon and its Chrony CLI (chronyc) client
> admin tool are not in sync, as client's UNIX filename uses a PID value
> whereas server's UNIX filename does not use PID value.
> 
> This appears to be a Debian-only issue.

What makes you think that this issue, if at all, is specific to Debian?

> Fired up its daemon and doubled checked that a UNIX socket was made:
> 
> $ ls -1 /run/chrony
> chrony.sock
> chrony.pid

chrony in Debian will create by default the chronyd.{pid,sock} files. The
above shows that you are tweaked chronyd's configuration. What changes did you
make?
 
> Execute the client and no successful UNIX socket opened.
> 
> Using List Open File (lsof) tool, I show the daemon's opened files:
> 
> COMMAND   PID USER   FD   TYPE NODE NAME
> 
> chronyd  3597  _chrony3u  unix 0x \
> type=DGRAM
> chronyd  3597  _chrony5u  IPv4 UDP 127.0.0.1:323 
> chronyd  3597  _chrony6u  IPv6 UDP [::1]:323 
> chronyd  3597  _chrony7u  unix 0x \
> /run/chrony/chronyd.sock type=DGRAM
> chronyd  3597  _chrony8u  unix 0x type=SEQPACKET
> chronyc  3809johnd3u  IPv4 UDP \
> 127.0.0.1:33911->127.0.0.1:323 
> 
> No socket in the dispatcher part of the daemon, now to check the other
> forked part of the daemon used to carry on the connection with
> its chronyc client, same 'lsof' output.
> 
> COMMAND   PID USER   FD   TYPE NODE NAME
> 
> chronyd  3597  _chrony5u  IPv4 UDP 127.0.0.1:323 
> chronyd  3597  _chrony6u  IPv6 UDP [::1]:323 
> chronyd  3598  _chrony9u  unix 0x type=SEQPACKET
> chronyc  3809johnd3u  IPv4 UDP \
> 127.0.0.1:33911->127.0.0.1:323 
> 
> Appears that client failed socket open and fell back to a
> different approach which is using an IP loopback address.
> 
> Investigated why socket open failed... by using 'strace -f chrony[c|d]'.
> 
> For the chronyd v4.0 having opened a Debian-tweaked '/run/chrony/chrony.sock',
> I show the corresponding chronyc v4.0 version:
> 
> $ chronyc -v
> chronyc (chrony) version 4.0 (+READLINE +SECHASH +IPV6 -DEBUG)
> 
> And ran strace against this v4.0 client and grep'd for 'sock' word pattern:
> 
> $ strace -f /usr/bin/chronyc 
> socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
> unlink("/run/chrony/chronyc.3875.sock") = -1 EACCES (Permission denied)
> 
> bind(3, {sa_family=AF_UNIX, sun_path="/run/chrony/chronyc.3875.sock"}, 
> 110) = -1 EACCES (Permission denied)
> getsockname(3, {sa_family=AF_UNIX}, [112->2]) = 0
> close(3)= 0
> 
> socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
> connect(3, {sa_family=AF_INET, sin_port=htons(323), 
> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
> 
> Noticed the 'PID' number being inserted into the 
> '/run/chrony/chronyc.3875.sock'?  
> This is the chronyc client doing "PID-sock" filenaming convention, whereas 
> its daemon is doing a different "just-sock" filenaming convention.

The PID is included to have the ability to run multiple chronyc instances at
the same time. Nothing wrong with that.
 
> The v4.1 client does exactly the same.
> 
> chronyc (chrony) version DEVELOPMENT (-READLINE -SECHASH +IPV6 +DEBUG)
> 
> socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
> unlink("/var/run/chrony/chronyc.3885.sock") = -1 EACCES (Permission 
> denied)
> 
> bind(3, {sa_family=AF_UNIX, 
> sun_path="/var/run/chrony/chronyc.3885.sock"}, 110) = -1 EACCES (Permission 
> denied)
> getsockname(3, {sa_family=AF_UNIX}, [112->2]) = 0
> close(3)= 0
> 
> socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
> connect(3, {sa_family=AF_INET, sin_port=htons(323), 
> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
> fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
> read(0, ^Cstrace: Process 3885 detached
>  
> 
> It  would be nice to use consistent filenaming convention for the UNIX socket
> for both client and daemon.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#995234: linux-image-amd64: can't start X anymore with linux-image-5.14.0-1

[Vincent Blut]

Control: tags -1 moreinfo

Hi,

Le 2021-09-28 12:06, Klaumi Klingsporn a écrit :
> Package: linux-image-amd64
> Version: 5.14.6-2
> Severity: important
> 
> Dear Maintainer,
> 
> after today's kernel-upgrade in testing to linux-image-5.14.0-1-amd64 
> (version 5.14.6-2)
> X cannot be started on my machine neither by lightdm nor by hand with startx.
> Booting with linux-image-5.10.0-8-amd64 (version 5.10.46-5) all works fine.
> 
> Hardware: AMD Ryzen3 3200G with Radeon Vega Graphics managed by amdgpu
> 
> I'll attach the relevant log-files for both kernels. But looking at 
> Xorg.0.log it seems
> as if the amdgpu-driver doesn't recognize the GPU any more and lists all 
> supported
> chipsets instead.

Does adding 'mem_encrypt=off' to the kernel command line helps?

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#995207: chrony: Using 'bindacqdevice' directive causes a SIGSYS error

[Vincent Blut]

Control: tags -1 - upstream + moreinfo
Control: severity -1 important

Hi,

Le 2021-09-27 17:31, Steve Egbert a écrit :
> Package: chrony
> Version: 4.0-8
> Severity: critical
> Tags: upstream
> X-Debbugs-Cc: s.egb...@sbcglobal.net
> 
> Dear Maintainer,
> 
> 
> Wanted to use the 'bindacqdevice' due to my host having a dynamic IP 
> interface.
> 
> Using that 'bindacqdevice' directive keyword anywhere in my
> /etc/chrony/chrony.conf file results in a signal 31 (according to Linux 
> auditd).
> 
> My guess is that attempts to do a Chrony as a NTP server (disbursing out
> NTP beacons), we need to have an socket open on this dynamic IP interface.
> 
> This is the setting of the systemd resource.
> 
> Removing the 'bindacqdevice' directive, and all works perfectly.
> 
> Was half-expecting to be able to use 'bindacqdevice' configuration directive
> here.

After having stopped chronyd, please run the command below when using the
'bindacqdevice' directive and attach the chronyd_debug.txt file.

# strace -o chronyd_debug.txt chronyd -d -F -1

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#994453: Bug confirmation

[Vincent Blut]

Le 2021-09-24 16:44, Alexander Kernozhitsky a écrit :
> Hello,
> 
> > Is it still reproducible when adding 'mem_encrypt=off' to the kernel command
> > line?
> 
> with `mem_encrypt=off` parameter, the kernel boots fine.

Thanks for testing, Alexander!

Jens-Michael, Gert, how does your system behave when
disabling AMD Secure Memory Encryption?
 
> -- 
> Alexander Kernozhitsky
 
Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#994949: linux-image-5.14.0-1-amd64: amdgpu and other problems during boot resulting in unusable machine

[Vincent Blut]

Control: tags -1 moreinfo

Hi,

Le 2021-09-23 19:46, Jan Christoph Uhde a écrit :
> Package: src:linux
> Version: 5.14.6-2
> Severity: important
> Tags: upstream
> 
> Dear Maintainer,
> 
> after installing the latest kernel my system does no longer
> boot into a usable state. The display freezes and the machine
> can only be accessed via ssh. Booting a 5.10 kernel mitigates
> the problem.
> 
> please note that I tried to use the navi-driver from linux-firmware
> (0268c1b8a06798f5167cbef8fb16241298b3eba9) which does not resolve the
> issue.
> 
> the dirvers have been installed with the following command:
> 
> --- linux-firmware-update-navi - start ---
> #!/bin/bash
> 
> ferr(){
> echo "$*"
> exit 1
> }
> 
> lib="/usr/lib/firmware"
> logfile=linux-firmware-amdgpu-update.log
> 
> cd linux-firmware || ferr "can not change into git reop"
> git fetch origin
> git reset --hard origin/HEAD || ferr "can not update"
> 
> changes="$(git diff HEAD@{1} HEAD -- amdgpu 2>&1)"
> 
> if [[ -z $changes ]]; then
> exit 1
> fi
> 
> cp amdgpu/nav* "$lib/amdgpu" || ferr "can not copy navi files"
> 
> date +%F | tee -a ../$logfile
> git log -n1 | tee -a ../$logfile
> echo "$changes" | tee -a ../$logfile
> echo "---" | tee -a ../$logfile
> echo "" | tee -a ../$logfile
> update-initramfs -u
> #yes this sucks I should use $HOME instead of `..`
> --- linux-firmware-update-navi - end ---
> 
> I am really willing to help to resolve this issue, but I would need
> some guidance as I have no system/kernel programming experience.
> 
> I feel comfortable with git / gdb / c++ and understand basic C.
> But I have no clue about gnu-extensions or the standard libraries
> other than the stuff in `string.h`.
> 
> If you can not deal with the problem yourself it would be really
> helpful if you could bring me into contact with people, who can
> solve this issue or are at least interested. I can not identify
> the problem enough to find the correct mailing list. This why I
> file the bug here in the debian bug tracker. 

Could you please try if booting with the 'mem_encrypt=off' kernel command line
helps?

Thanks,
Vincent


signature.asc
Description: PGP signature

Bug#994453: Bug confirmation

[Vincent Blut]

Hi,

Le 2021-09-24 03:02, Alexander Kernozhitsky a écrit :
> Control: found -1 5.14.6-2
> 
> I have just tried installing the kernel from unstable. After reboot, the 
> booting process just hung at the very early stage. Nothing was printed onto 
> the screen, and I cannot find the logs, as it happened during booting from 
> initramfs.
> 
> The problem may be specific to Debian, as I tried booting openSUSE Tumbleweed 
> from LiveUSB with kernel 5.14.5, and it worked fine.
> 
> I am using Lenovo Thinkpad E495 with AMD Ryzen 5 3500U CPU.

Is it still reproducible when adding 'mem_encrypt=off' to the kernel command
line?
 
> -- 
> Alexander Kernozhitsky
 
Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#977320: linux-image-4.19.0-9-amd64: Enable CONFIG_BACKLIGHT_PWM

[Vincent Blut]

Package: src:linux
Followup-For: Bug #977320

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Pablo,

Were you able to diagnosed this issue?

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYUT7HgAKCRAQn1qAt/bg
AdpBAQDGv+E83P4C0+T9+G8jlohi3RhhiGjWfPnB5PAtV+hGaQD+NtuUuqXx/Iip
H8FXkRu4VlZ82BLw5H9WhpfSlGFpDQ4=
=5Vml
-END PGP SIGNATURE-

Bug#944886: Please enable CONFIG_SND_SOC_SOF_NOCODEC_SUPPORT

[Vincent Blut]

Package: src:linux
Followup-For: Bug #944886

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tags -1 moreinfo

Hi,

Debian Bullseye should provide a much better experience on machines equipped
with this kind of audio controllers without having to enable
CONFIG_SND_SOC_SOF_NOCODEC_SUPPORT, which is not recommended.

If you still have this laptop, it would be nice to hear how it behaves on a
"modern" kernel.

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYUSweAAKCRAQn1qAt/bg
AZEkAPsE1p7I0KEmLEnxHZ1yh5hWeKDPKmrkd0o2e9h0FIBG4AD/c3d/2+bgXKrN
Me740IT+3NBm002WTYrsQn+BWs+I2g8=
=4ypf
-END PGP SIGNATURE-


signature.asc
Description: PGP signature

Bug#994215: Enable CONFIG_FSL_MC_UAPI_SUPPORT

[Vincent Blut]

Control: forcemerge -1 992988

Hi Christian,

Le 2021-09-13 21:28, Christian Svensson a écrit :
> Package: src:linux
> Version: linux/5.14.2-1~exp1
> 
> Please enable CONFIG_FSL_MC_UAPI_SUPPORT ("Management Complex (MC)
> userspace support") for arm64.
> This is needed to manage the onboard network interfaces on LX2160A-based
> boards such as the SolidRun HoneyComb LX2. Without this configuration
> option the onboard network interfaces can only be used in the state it is
> handed over to Linux by the bootloader. In practice this means that while
> e.g. lower speed interfaces may be set up, the faster SFP+ or QSFP28 ports
> could be left deactivated and thus not usable.
> 
> If you have any questions I am happy to try to answer them.

I'll work on this. Hopefully it'll be enabled in the next kernel upload.

> Regards,
> Chris

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#993865: please enable CONFIG_MT7915E

[Vincent Blut]

Hi Piotr,

Le 2021-09-07 15:08, Piotr Ożarowski a écrit :
> Package: src:linux
> Version: 5.10.28-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Please enable CONFIG_MT7915E (MediaTek MT7915E (PCIe) support) - looks
> like my new mini PCIe card needs this one.
> 5.14-1~exp2 from experimental doesn't have this one enabled as well
> 
> CONFIG_MT7915E was added in Linux 5.8

I sent a merge request¹ to fulfil your request. It also enables support for
other wireless MediaTek chips, notably the MT7921E which seems quite popular on
some laptops (e.g. ASUS G15, Acer Nitro 5).

> TIA

Cheers,
Vincent

¹ https://salsa.debian.org/kernel-team/linux/-/merge_requests/391


signature.asc
Description: PGP signature

Bug#908196: linux-image-4.9.0-8-armmp: Please set CONFIG_LEDS_PCA963X=m

[Vincent Blut]

Hi Reco,

Le 2021-08-20 11:16, Reco a écrit :
>   Hi, Vincent.
> 
> On Tue, Aug 17, 2021 at 04:41:20PM +0200, Vincent Blut wrote:
> > Package: src:linux
> > Followup-For: Bug #908196
> 
> > Is it still worthwhile to enable this option?
> 
> IMO yes. I have the thing sitting on my desk now, it runs Debian, and it
> serves its function.

Good to know.

> > So if this router does not run on Linux 5.13+, it's probably not worth
> > to enable this option.
> 
> I've just upgraded the device to bullseye, and installed
> linux-image-5.13.0-trunk from the experimental on it.
> I confirm that:
> 
> - the device boots successfully with that kernel.
> - both LAN and WAN ports work.
> - USB ports work too.
> 
> The kernel from the experimental just misses the usual:
> 
> - pca963x for WAN/WIFI leds
> - wifi.
> 
> Wifi requires out of tree module anyway, and its outside of the scope of
> this bug report.

OK! I'll send a merge request to the kernel team later today then.
> 
> Sincerely yours, Reco

Have a good day,
Vincent


signature.asc
Description: PGP signature

Bug#908196: linux-image-4.9.0-8-armmp: Please set CONFIG_LEDS_PCA963X=m

[Vincent Blut]

Package: src:linux
Followup-For: Bug #908196

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tags -1 moreinfo

Hi Reco,

Sorry it took so long to get back to you.

Is it still worthwhile to enable this option? Looking at device tree
information, the pca963x LED drivers seem to be used only by the
Linksys WRT1200AC (pca9635), other devices generally prefer to use GPIO
connected LEDs or a different expander (PCA9555, etc.)

So if this router does not run on Linux 5.13+, it's probably not worth to enable
this option.

Cheers,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYRvKjwAKCRAQn1qAt/bg
AdBHAP9fDZdx3++JQg02zknaSgh+Wa/s5q8Ko5NRMKXlZtCgyQD+LZzzeUOTownu
JQFLgTD3dG/gPvf0oJE0WLcxhahSOQ0=
=X1j+
-END PGP SIGNATURE-

Bug#986822: BUG#986822 Broadwell SST CATPT Sound module

[Vincent Blut]

Version: 5.10.38-1

Hi,

One week has passed, as per your request I'm closing this bug report. Feel free
to reopen it if the issue recurs.

Cheers,
Vincent

Le 2021-06-21 09:34, Dekks Herton a écrit :
> problem resolved, i think.
> 
> new sof firmware update came out, not sure its arrival was more than a
> coincidence
> 
> 1 - disabling all intel vitrualisation options in the helix bios was enough
> to allow the fw to load thus  pavucontrol was now seeing input bars moving
> but no sound output.
> 
> 2 - ran alsactl -U init after i noticed ucm errors when running alsactl
> init.
> 
> 3 - aplay -l now sees all 3 cards when docked and 2 when tablet only.
> 
> 4 - alsamixer still showed the correct hw but a lot of outputs were muted,
> by enabling and disabling them all in sequence enabling the front dac
> enabled sount from the rt256 card and headphone socket.
> 
> I'm doing basic checks like detaching and reattaching to see if that
> affects the sound, so far ok Only noticeable thing is the fw gets reloaded
> 3 or 4 times a session, but doesn't seem to affect anything . If i have not
> commented more  in a week feel free to close the bug.
> 
> On Tue, 15 Jun 2021 at 11:43, Dekks Herton  wrote:
> 
> > Hi Vincent
> >
> > I'll kill the pipewire server, i would uninstall the packages but they are
> > hard deps for gnome now.
> >
> > Is the fw file catpt is trying to load the correct one? Is there new fw
> > files that come with catpt that have been forgotten?
> > Is there a listiing for the error codes -110 and -2, are they missing
> > files or read permission issues?
> >
> > Regards.
> >
> >
> >
> >
> > On Sun, 13 Jun 2021 at 18:08, Vincent Blut  wrote:
> >
> >> Hi,
> >>
> >> Le 2021-06-05 08:31, Dekks Herton a écrit :
> >> > Hi
> >> >
> >> > Additional alsa-info script output
> >>
> >> From a quick look, alsa-info reports that you're running both PipeWire and
> >> PulseAudio sound servers. While it may not be the root cause of your
> >> issue,
> >> if you want to stick with the former, please disable the latter:
> >> $ sudo systemctl --user disable --now pulseaudio.service pulseaudio.socket
> >>
> >> Note though that using PipeWire as a substitute to PulseAudio/JACK/ALSA in
> >> Debian 11 is considered experimental.
> >>
> >> Cheers,
> >> Vincent
> >>
> >


signature.asc
Description: PGP signature

Bug#989777: Re: Severity: High / Debian 10 amp; 11 with Kernel 5.10.x-amd64 =gt; Intel AX210 Wifi amp; Bluetooth not work

[Vincent Blut]

Salut Philippe,

Le 2021-06-14 23:09, pham...@bluewin.ch a écrit :
> The boot is difficult, I have a recurring error message that turns in a loop.
> 
> journalctl -k | grep -Ei "iwl|bluetooth :
> 
> 
> root@portable-1:~# journalctl -k | grep -Ei "iwl|bluetooth"
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: enabling device 
> ( -> 0002)
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: firmware: 
> direct-loading firmware iwlwifi-ty-a0-gf-a0-59.ucode
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: api flags index 2 
> larger than supported by driver
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: TLV_FW_FSEQ_VERSION: 
> FSEQ Version: 93.8.63.28
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: loaded firmware 
> version 59.601f3a66.0 ty-a0-gf-a0-59.ucode op_mode iwlmvm
> jun 14 22:48:11 portable-1 kernel: iwlwifi :3b:00.0: firmware: failed to 
> load iwl-debug-yoyo.bin (-2)
> jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0: Detected Intel(R) 
> Wi-Fi 6 AX210 160MHz, REV=0x420
> jun 14 22:48:12 portable-1 kernel: Bluetooth: Core ver 2.22
> jun 14 22:48:12 portable-1 kernel: Bluetooth: HCI device and connection 
> manager initialized
> jun 14 22:48:12 portable-1 kernel: Bluetooth: HCI socket layer initialized
> jun 14 22:48:12 portable-1 kernel: Bluetooth: L2CAP socket layer initialized
> jun 14 22:48:12 portable-1 kernel: Bluetooth: SCO socket layer initialized
> jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0: firmware: failed to 
> load iwlwifi-ty-a0-gf-a0.pnvm (-2)
> jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0: base HW address: 
> 54:14:f3:52:7b:e1
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Reading Intel version 
> information failed (-22)
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel Read version failed 
> (-22)
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel reset sent to retry 
> FW download
> jun 14 22:48:12 portable-1 kernel: iwlwifi :3b:00.0 wlp59s0: renamed from 
> wlan0
> jun 14 22:48:12 portable-1 kernel: Bluetooth: BNEP (Ethernet Emulation) ver 
> 1.3
> jun 14 22:48:12 portable-1 kernel: Bluetooth: BNEP filters: protocol multicast
> jun 14 22:48:12 portable-1 kernel: Bluetooth: BNEP socket layer initialized
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Reading Intel version 
> information failed (-22)
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel Read version failed 
> (-22)
> jun 14 22:48:12 portable-1 kernel: Bluetooth: hci0: Intel reset sent to retry 
> FW download
> jun 14 22:48:13 portable-1 kernel: Bluetooth: hci0: Reading Intel version 
> information failed (-22)
> jun 14 22:48:13 portable-1 kernel: Bluetooth: hci0: Intel Read version failed 
> (-22)
> jun 14 22:48:13 portable-1 kernel: Bluetooth: hci0: Intel reset sent to retry 
> FW download
> 
> 
> systemctl status bluetooth.service :
> 
> 
> root@portable-1:~# systemctl status bluetooth.service
> ● bluetooth.service - Bluetooth service
>  Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor 
> preset: enabled)
>  Active: active (running) since Mon 2021-06-14 22:48:12 CEST; 10min ago
>Docs: man:bluetoothd(8)
>Main PID: 649 (bluetoothd)
>  Status: "Running"
>   Tasks: 1 (limit: 38030)
>  Memory: 2.6M
> CPU: 266ms
>  CGroup: /system.slice/bluetooth.service
>  └─649 /usr/libexec/bluetooth/bluetoothd
> 
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEScanIntervalConnect” in >
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEScanWindowConnect” in gr>
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEMinConnectionInterval” i>
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEMaxConnectionInterval” i>
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEConnectionLatency” in gr>
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEConnectionSupervisionTim>
> jun 14 22:48:12 portable-1 bluetoothd[649]: 
> src/main.c:parse_controller_config() Key file does not have key 
> “LEAutoconnecttimeout” in g>
> jun 14 22:48:12 portable-1 systemd[1]: Started Bluetooth service.
> jun 14 22:48:12 portable-1 bluetoothd[649]: Starting SDP server
> jun 14 22:48:12 portable-1 bluetoothd[649]: Bluetooth management interface 
> 1.18 initialized
> lines 1-22/22 (END)
> 
> 
> If I can be useful for make a test on my system, do not hesitate to ask me it.

Thanks for the logs, Phillipe. From the information I gathered, it seems
Linux 5.11 is required to get bluetooth work on this adapter.

Before rebasing on Linux 5.11 for the 21.04 

Bug#989777: Severity: High / Debian 10 11 with Kernel 5.10.x-amd64 = Intel AX210 Wifi Bluetooth not work

[Vincent Blut]

Le 2021-06-14 22:19, pham...@bluewin.ch a écrit :
> Salut Vincent,
> 
> I have rebooted my Laptop after downgrading the firmware, this must have 
> restarted the iwlmvm and iwlwifi services, which allowed me to launch an 
> internet connection by Wifi.

OK, that's good to hear.

> But nothing to do for Bluetooth, it refuses to work.

Could you please attach the output of the following commands:
$ sudo journalctl -k | grep -Ei "iwl|bluetooth"
$ sudo systemctl status bluetooth.service


signature.asc
Description: PGP signature

Bug#989777: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[Vincent Blut]

Salut Philippe,

Le 2021-06-14 21:48, pham...@bluewin.ch a écrit :
> Hello Andrei,
> I must have "my head in the moon" as we say in French :) I did not see the 
> download link...
> After uninstall of the new "firmware-iwlwifi_20210315-2_all.deb" and 
> installation of the old "firmware-iwlwifi_20210208-4_all.deb" the Wifi work 
> fine, but the Bluetooth not work, I dont have access to my Bluetooth devices 
> ;-(

Did you reload the iwlmvm and iwlwifi modules after downgrading the firmware?

> Best regards.
> Philippe

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#989777: Severity: High / Debian 10 & 11 with Kernel 5.10.x-amd64 => Intel AX210 Wifi & Bluetooth not work

[Vincent Blut]

Hi,

Le 2021-06-14 11:58, pham...@bluewin.ch a écrit :
> Hello and thank you for your message.
> I'm already using the "non-free" Debian images which contain firmware for 
> network cards etc.
> https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-builds/amd64/iso-dvd/
> The package "firmware-iwlwifi_20210315-2_all.deb" is correctly installed, but 
> my Intel AX210 Wifi / Bluetooth card is not recognized and is not functional.
> This problem is extremely debilitating for me (severity: high). I bought this 
> hardware to run on Debian 10 with Backport and on Debian 11 but I cannot use 
> it.

There are reports in the wild stating that firmware version 22.40.0.2 (included
upstream in linux-firmware 20210315) for Intel AX210 caused some regressions.
Downgrading to firmware version 22.30.0.4 (included upstream in linux-firmware
20210208) seems to have fixed those regressions for the people affected by them.

Could you check if installing firmware_iwlwifi 20210208-4 [1] fixes your issue?

> Best regards.
> Philippe

Cheers,
Vincent

[1] 
https://snapshot.debian.org/archive/debian/20210313T203823Z/pool/non-free/f/firmware-nonfree/firmware-iwlwifi_20210208-4_all.deb


signature.asc
Description: PGP signature

Bug#986822: BUG#986822 Broadwell SST CATPT Sound module

[Vincent Blut]

Le 2021-06-13 20:08, Vincent Blut a écrit :
> Hi,
> 
> Le 2021-06-05 08:31, Dekks Herton a écrit :
> > Hi
> > 
> > Additional alsa-info script output
> 
> From a quick look, alsa-info reports that you're running both PipeWire and
> PulseAudio sound servers. While it may not be the root cause of your issue,
> if you want to stick with the former, please disable the latter:
> $ sudo systemctl --user disable --now pulseaudio.service pulseaudio.socket

Err: the above command should not be run with sudo.

> Note though that using PipeWire as a substitute to PulseAudio/JACK/ALSA in
> Debian 11 is considered experimental.
> 
> Cheers,
> Vincent


signature.asc
Description: PGP signature

Bug#986822: BUG#986822 Broadwell SST CATPT Sound module

[Vincent Blut]

Hi,

Le 2021-06-05 08:31, Dekks Herton a écrit :
> Hi
> 
> Additional alsa-info script output

From a quick look, alsa-info reports that you're running both PipeWire and
PulseAudio sound servers. While it may not be the root cause of your issue,
if you want to stick with the former, please disable the latter:
$ sudo systemctl --user disable --now pulseaudio.service pulseaudio.socket

Note though that using PipeWire as a substitute to PulseAudio/JACK/ALSA in
Debian 11 is considered experimental.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#986822: BUG#986822 Broadwell SST CATPT Sound module

[Vincent Blut]

Hi Salvatore,

Le 2021-06-04 21:39, Salvatore Bonaccorso a écrit :
> Hi,
> 
> On Fri, Jun 04, 2021 at 05:56:03PM +0200, Vincent Blut wrote:
> > Hi Dekks,
> > 
> > Le 2021-06-04 15:34, Dekks Herton a écrit :
> > > Hi Everyone,
> > > 
> > > As 5.10.7 was still in unstable 1 added it to my bullseye system via 
> > > adding
> > > SId to sources.list and pulling the image and relevant headers packages. 
> > > If
> > > there is a better or more correct way please advise.
> > > 
> > > Running 5.10.7 AFAIK installs the catpt modules correctly and all the hw
> > > associated correctly
> > > 
> > > 1) See aplayL txt file enc 2) GNOME shows a different slider layout
> > > 
> > > However there is still no sound on play back, parsing journalctl it seems
> > > the firmware IntcSST2.bin errors out and thus no firmware is loaded.
> > > 
> > > Jun 04 00:49:06 HELIX2NDGEN kernel: intel_catpt INT3438:00: firmware:
> > > direct-loading firmware intel/IntcSST2.bin
> > > Jun 04 00:49:10 HELIX2NDGEN kernel: intel_catpt INT3438:00: firmware:
> > > direct-loading firmware intel/IntcSST2.bin
> > > Jun 04 00:49:10 HELIX2NDGEN kernel: intel_catpt INT3438:00: firmware ready
> > > timeout
> > > Jun 04 00:49:10 HELIX2NDGEN kernel: intel_catpt INT3438:00: boot firmware
> > > failed: -110
> > > 
> > > I enclose a listing of the intel firmware folder showing IntcSST2.bin is
> > > there, Is it the correct firmware?
> > > 
> > > I've googled and cant find any info on this. Does intel have a github for
> > > this re-written driver?
> > > 
> > > Can the bug reopened or can you advise any possible solutions?
> > 
> > Do you have firmware-sof-signed installed? It may be needed on your system.
> 
> Reopened the bug for now (at least until the above question is
> clarified).

Dekks replied to me privately. Those SOF audio firmware aren't going to help in
this case since we don't provide support for SOF on Broadwell based platforms.
I already mentioned this in [1] but I had totally forgotten that.

Dekks, out of curiosity, could you please post the output of 'pacmd list-sinks'?

> Regards,
> Salvatore

Cheers,
Vincent

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986822#10


signature.asc
Description: PGP signature

Bug#986822: BUG#986822 Broadwell SST CATPT Sound module

[Vincent Blut]

Hi Dekks,

Le 2021-06-04 15:34, Dekks Herton a écrit :
> Hi Everyone,
> 
> As 5.10.7 was still in unstable 1 added it to my bullseye system via adding
> SId to sources.list and pulling the image and relevant headers packages. If
> there is a better or more correct way please advise.
> 
> Running 5.10.7 AFAIK installs the catpt modules correctly and all the hw
> associated correctly
> 
> 1) See aplayL txt file enc 2) GNOME shows a different slider layout
> 
> However there is still no sound on play back, parsing journalctl it seems
> the firmware IntcSST2.bin errors out and thus no firmware is loaded.
> 
> Jun 04 00:49:06 HELIX2NDGEN kernel: intel_catpt INT3438:00: firmware:
> direct-loading firmware intel/IntcSST2.bin
> Jun 04 00:49:10 HELIX2NDGEN kernel: intel_catpt INT3438:00: firmware:
> direct-loading firmware intel/IntcSST2.bin
> Jun 04 00:49:10 HELIX2NDGEN kernel: intel_catpt INT3438:00: firmware ready
> timeout
> Jun 04 00:49:10 HELIX2NDGEN kernel: intel_catpt INT3438:00: boot firmware
> failed: -110
> 
> I enclose a listing of the intel firmware folder showing IntcSST2.bin is
> there, Is it the correct firmware?
> 
> I've googled and cant find any info on this. Does intel have a github for
> this re-written driver?
> 
> Can the bug reopened or can you advise any possible solutions?

Do you have firmware-sof-signed installed? It may be needed on your system.

> Regards

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#977320: Updated information

[Vincent Blut]

Control: notfixed 977320 linux/5.10.9-1
Control: tags -1 moreinfo

Hi Pablo,

Le 2021-05-27 09:45, Pablo Bianucci a écrit :
> Hello,
> 
> I saw that the bug was fixed and tried the kernel, but it seems I did a bad
> diagnostic. As found in https://bugs.archlinux.org/task/55024, it seems that
> the required options for backlight control to work out-of-the-box in Cherry
> Trail tablets are:
> 
> CONFIG_PWM=y
> CONFIG_PWM_SYSFS=y
> CONFIG_PWM_CRC=y
> CONFIG_PWM_LPSS=m
> CONFIG_PWM_LPSS_PCI=m
> CONFIG_PWM_LPSS_PLATFORM=m

Among these options, only CONFIG_PWM_LPSS_PCI is missing in our kernel
configuration. That would be nice if you could build a kernel with this option
enabled to check that it allows you to correctly turn down the screen backlight
on the ASUS Transformer TA102.

> I apologize for the earlier misleading report...
> 
> Pablo B.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#987281: linux-image-amd64: Enable i915 HDCP 2.2 support

[Vincent Blut]

Le 2021-04-30 13:41, Salvatore Bonaccorso a écrit :
> Hi Vincent,
> 
> On Fri, Apr 30, 2021 at 12:43:22PM +0200, Vincent Blut wrote:
> > Le 2021-04-30 09:12, Bastian Germann a écrit :
> > > Am 29.04.21 um 20:13 schrieb Vincent Blut:
> > > > Running 'xrandr --verbose' from Xorg should give you the supported
> > > > HDCP Content Type. If that reports "HDCP Type1" then support for HDCP 
> > > > 2.2 is
> > > > enabled.
> > > 
> > > Works as expected. Enabling the two configs is sufficient.
> > 
> > Thanks for confirming.
> > 
> > Salvatore, how do you feel about enabling those kernel options for Bullseye?
> > Should I open a MR?
> 
> As it was verified to work and it adds important additional hardware
> support, then yes please.

Done.
https://salsa.debian.org/kernel-team/linux/-/merge_requests/354

> I just find at this stage the part very important, we should try to
> enable additional HW support only if we have some verification that it
> adds value for the users, this is why I mentioned it last time.

Definitely agree!

> Regards,
> Salvatore

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#987281: linux-image-amd64: Enable i915 HDCP 2.2 support

[Vincent Blut]

Le 2021-04-30 09:12, Bastian Germann a écrit :
> Am 29.04.21 um 20:13 schrieb Vincent Blut:
> > Running 'xrandr --verbose' from Xorg should give you the supported
> > HDCP Content Type. If that reports "HDCP Type1" then support for HDCP 2.2 is
> > enabled.
> 
> Works as expected. Enabling the two configs is sufficient.

Thanks for confirming.

Salvatore, how do you feel about enabling those kernel options for Bullseye?
Should I open a MR?


signature.asc
Description: PGP signature

Bug#987281: linux-image-amd64: Enable i915 HDCP 2.2 support

[Vincent Blut]

Hi,

Le 2021-04-29 19:01, Bastian Germann a écrit :
> Am 21.04.21 um 07:24 schrieb Salvatore Bonaccorso:
> > Were you able to verify that enabling those two as modules make it
> > work?
> 
> I honestly do not know how to check from userspace. xrandr has a Content
> Protection flag that is responsible for enabling/indicating HDCP usage. It
> works but I cannot verify it to be HDCP v2.2 (v1.4 works without those
> configs). libhdcpsdk has a HDCPSetProtectionLevel but I do not have the time
> right now to write a test program.

Running 'xrandr --verbose' from Xorg should give you the supported
HDCP Content Type. If that reports "HDCP Type1" then support for HDCP 2.2 is
enabled.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#987773: enable netfilter modules

[Vincent Blut]

Control: reassign -1 src:linux
Control: tags -1 moreinfo

Hi Arturo,

Le 2021-04-29 12:09, Arturo Borrero Gonzalez a écrit :
> Source: linux
> Severity: normal
> 
> Dear maintainers,
> 
> thanks for your hard work with this package, it is really appreciated.
> 
> I noticed today the following missing netfilter modules in the kernel
> from testing/sid (by the time of this writing same version in both):
> 
> === 8< ===
> arturo@endurance:~ $ grep NETFILTER_EGRESS /boot/config-5.10.0-6-amd64 

That one is not available, see below.

> arturo@endurance:~ $ grep NETFILTER_XT_TARGET_NOTRACK 
> /boot/config-5.10.0-6-amd64 
> # CONFIG_NETFILTER_XT_TARGET_NOTRACK is not set

That one is deprecated upstream, do we really need it?

> I think CONFIG_NETFILTER_EGRESS is newer, but should be available since 5.7, 
> in
> upstream commit:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8537f78647c072bdb1a5dbe32e1c7e5b13ff1258

It has been reverted:
https://github.com/torvalds/linux/commit/357b6cc5834eabc1be7c28a9faae7da061df097d

 
> regards.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#987638: linux-image-5.10.0-6-arm64: Missing kernel modules for Pine64's Pinebook Pro (usb-c, battery gauge, audio)

[Vincent Blut]

Salut Lionel,

Le 2021-04-27 11:27, Lionel Fourquaux a écrit :
> On Mon, Apr 26, 2021 at 11:19:29PM +0200, Vincent Blut wrote:
> > A merge request [1] has been proposed today to improve support for the 
> > Pinebook
> > Pro.
> 
> Thanks! (The merge request and this report are related.)
> 
> Some additional information: I (finally) managed to (cross-)build a Debian
> kernel package and test this:
>  * the battery gauge is working!

Great.

>  * the usb-c port gets its FUSB302 driver, but hits an error later:
> [8.656555] OF: graph: no port node found in /i2c@ff3d/fusb30x@22
>(This may be related to this patch to the DTD:
>   
> https://patchwork.kernel.org/project/linux-rockchip/patch/20200924063042.41545-1-...@endlessos.org/
>which made the monitor work, or possibly another missing driver.)

As it's not clear from your message, did you also enable CONFIG_TYPEC and
CONFIG_TYPEC_TCPM as modules?

>  * pulseaudio starts correctly (unlike before), but no sound (note: the
> internal switch controlling the audio jack is set in "serial port"mode;
> I'm not sure whether this affects the speakers, I will tryflipping the
> switch later).
> 
> So this is clearly an improvement (especially the battery gauge), but not a
> complete solution.
>
> Best regards,
> 
>   -- Lionel

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#987638: linux-image-5.10.0-6-arm64: Missing kernel modules for Pine64's Pinebook Pro (usb-c, battery gauge, audio)

[Vincent Blut]

Hi,

Le 2021-04-26 22:46, Lionel Fourquaux a écrit :
> Package: src:linux
> Version: 5.10.28-1
> Severity: wishlist
> X-Debbugs-Cc: lionel.fourquaux+deb...@normalesup.org
> 
> Dear Maintainer,
> 
> I'm using Debian bullseye (currently unstable, soon to be stable) on 
> a Pine64 Pinebook Pro, installed using the official Debian installer.
> 
> Some devices are "not working" (meaning: nonfunctional, not detected by 
> the kernel):
>  * the usb-c port
>  * the battery gauge (cw2025) (note: dmesg shows error messages about a 
>missing power supply (the usb-c port?):
> [8.546079] power_supply cw2015-battery: Not all required supplies found, 
> defer probe
> [8.546089] cw2015 4-0062: Failed to register power supply
>)
>  * the audio output (built-in speakers).
> 
> After comparing the available kernel modules to the device tree, I believe 
> that this is caused by some missing modules in the kernel configuration. 
> I suggest enabling:
>   CONFIG_TYPEC_FUSB302
>   CONFIG_SND_SOC_ES8316

A merge request [1] has been proposed today to improve support for the Pinebook
Pro.

> Best regards,
> 
>   -- Lionel

Cheers,
Vincent

[1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/352


signature.asc
Description: PGP signature

Bug#987019: (no subject)

[Vincent Blut]

Hey Josua,

Le 2021-04-26 17:32, Josua Mayer a écrit :
> Hi Vincent,
> 
> Thanks for your quick reply (which I failed to notice )
> So I did a test today with GPIO_MXC=m, and initramfs-tools in default
> configuration.
> 
> gpio_mxc module is included in initramfs automatically, and the system can
> boot from microSD just fine.
> Therefore, setting it as a module would do.

Awesome, thanks for testing. I'll update the merge request then.

> Yours sincerely
> Josua mayer

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#987576: linux: Please enable CONFIG_SND_AUDIO_GRAPH_CARD

[Vincent Blut]

Le 2021-04-26 02:19, Diederik de Haas a écrit :
> Source: linux
> Version: 5.10.28-1
> Severity: wishlist
> 
> https://github.com/torvalds/linux/commit/ddf3fa8b8a16e076f247c115a73356b4b0d83a33
> is titled: "arm64: defconfig: Enable CONFIG_SND_AUDIO_GRAPH_CARD"
> and the secondary commit msg is 
> "CONFIG_SND_AUDIO_GRAPH_CARD is needed to use HDMI sound with video"
> 
> According to the above mentioned URL, it's been part of arm64's
> defconfig since 2018-05-02 and included since kernel version 4.18-rc1.
> When researching how to get HDMI audio working on a Rock64, this was one
> of the settings they (on IRC freenode#linux-rockchip) said needed to be
> enabled for it to work.
> Checking on the config on this RPi3B+ indicated that it wasn't enabled
> on arm64, so hereby the request to enable it.

I sent a MR [1] to enable this option.

> I can imaging that it would also make sense to enable it on armhf, but I
> don't know if that's needed or maybe already enabled there, but I assume
> the Debian kernel maintainers can make an informed judgement on that.

It is already provided as a module on armhf.

> Cheers,
>   Diederik

Have a good day,
Vincent

[1] https://salsa.debian.org/kernel-team/linux/-/merge_requests/351


signature.asc
Description: PGP signature

Bug#987019: (no subject)

[Vincent Blut]

Hi Josua,

Le 2021-04-15 20:22, Josua Mayer a écrit :
> Dear Maintainers,
> 
> I have found a configuration change that makes the microSD port function
> again, verified by rebuilding 5.10.0-6:
> diff --git a/debian/config/armhf/config b/debian/config/armhf/config
> index bdf0fa118db1..7c39d00d7aae 100644
> --- a/debian/config/armhf/config
> +++ b/debian/config/armhf/config
> @@ -343,6 +343,7 @@ CONFIG_GPIO_DA9052=m
>  CONFIG_GPIO_PALMAS=y
>  CONFIG_GPIO_TWL4030=y
>  CONFIG_GPIO_TWL6040=y
> +CONFIG_GPIO_MXC=y
> 
>  ##
>  ## file: drivers/gpu/drm/Kconfig

Would compiling it as a module lead to the same result?

> Yours sincerely
> Josua Mayer

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#986848: linux: Please enable CONFIG_RMI4_F3A kernel config option

[Vincent Blut]

Hi Justin,

Le 2021-04-12 15:53, Justin King-Lacroix a écrit :
> Source: linux
> Severity: normal
> X-Debbugs-Cc: justi...@google.com
> 
> Kernel config option CONFIG_RMI4_F3A is not enabled by default on Debian 
> kernels.
> 
> It is required for touchpad "click" functionality to work on the Lenovo P1 
> Gen 2
> (among possibly other laptop models).

It is also required by the Lenovo Thinkpad X1 Extreme Gen 2.

> Can it please be enabled for future kernels?
> (Related: is there a reason why it isn't?)

I'll propose a merge request to the kernel team.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#986822: installation-reports: Debian 11 Breaks Analague sound on Thinkpad Helix 2nd Gen

[Vincent Blut]

Control: reassign -1 src:linux
Control: retitle -1 Missing support for Haswell/Broadwell platforms with I2S 
codec present

Hi,

Le 2021-04-12 13:40, dekks herton a écrit :
> Comments/Problems:
> 
> No analogue sound on Tablet from Broadwell-U from intel smart sound chipset -
> hw works on Buster but breaks on Bullseye
> Card0 on Buster no longer detected on Bullseye

Due to various bugs, Intel has rewritten the audio driver for Haswell/Broadwell
in Linux 5.10.
The bad news is that our kernel configuration does not seem to provide the
necessary bits to enable support for the Intel Audio DSP on Haswell U/Y and
Broadwell U.
I'm willing to provide a patch to fix this but the release of Bullseye is
approaching really fast so we might have to wait for the first point release.

> Tried installing Intel SOF drivers/firmware to no effect, forcing 
> snd_hda_intel
> via modprobe conf doesn't work either
> Broadwell-U works eith with HDA or SOF drivers theoretically.
> There is record of a kernel compilation flag to enable SOF functionality
> SND_SOC_SOF_BROADWELL_SUPPORT=Y breaking legacy and snd_hda_intel too.

We do not support SOF on Broadwell. This is even not recommended by upstream due
to some limitations related to DMA and suspend-resume so installing
firmware-sof-signed is of no use in your case.

Cheers,
Vincent


signature.asc
Description: PGP signature

Bug#986705: unblock: chrony/4.0-7

[Vincent Blut]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Please unblock package chrony

[ Reason ]
The IP_TOS socket option is currently missing in chronyd's seccomp filter
which prevents users from using the 'dscp' directive in the chronyd
configuration file while the seccomp filter is enabled. This directive allows
one to set the Differentiated Services Code Point to a specific value.

[ Impact ]
Since chronyd's seccomp filter is enabled by default in Debian, chronyd would be
killed right after being started when using the 'dscp' directive. Consequently,
to use this feature, users have to disable the seccomp filter.

[ Tests ]
Since the issue is easy to trigger, I manually tested the proposed fix while
ensuring that autopkgtest reports no regressions. Here are some steps to
reproduce the issue encountered by chrony 4.0-6:

# echo 'dscp 22' > /etc/chrony/conf.d/dscp.conf
# systemctl restart chrony.service
# systemctl is-active chrony.service
failed

With chrony 4.0-7, the last command reports chrony.service as active.

[ Risks ]
Harmless. We just allow the IP_TOS setsockopt() option in the seccomp filter.

[ Checklist ]
  [✓] all changes are documented in the d/changelog
  [✓] I reviewed all changes and I approve them
  [✓] attach debdiff against the package in testing

unblock chrony/4.0-7

Cheers,
Vincent


-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCYHC9bQAKCRAQn1qAt/bg
AbvgAQCCCKwtSJ/J5u9UJFT0KFVLrBo2b7wYV/uHY20Mq+WHZAEA0xNSEF/09KJi
JIMz/mzm/PGJ3Q9K3BT5zSewfjmLBwI=
=skob
-END PGP SIGNATURE-
diff -Nru chrony-4.0/debian/changelog chrony-4.0/debian/changelog
--- chrony-4.0/debian/changelog 2021-02-21 21:59:22.0 +0100
+++ chrony-4.0/debian/changelog 2021-04-08 16:21:16.0 +0200
@@ -1,3 +1,11 @@
+chrony (4.0-7) unstable; urgency=medium
+
+  * debian/patches/:
+- Add allow-IP_TOS-socket-option-in-seccomp-filter.patch to enable the use
+of the 'dscp' directive.
+
+ -- Vincent Blut   Thu, 08 Apr 2021 16:21:16 +0200
+
 chrony (4.0-6) unstable; urgency=medium
 
   * debian/tests/helper-functions:
diff -Nru 
chrony-4.0/debian/patches/allow-IP_TOS-socket-option-in-seccomp-filter.patch 
chrony-4.0/debian/patches/allow-IP_TOS-socket-option-in-seccomp-filter.patch
--- 
chrony-4.0/debian/patches/allow-IP_TOS-socket-option-in-seccomp-filter.patch
1970-01-01 01:00:00.0 +0100
+++ 
chrony-4.0/debian/patches/allow-IP_TOS-socket-option-in-seccomp-filter.patch
2021-04-08 16:21:16.0 +0200
@@ -0,0 +1,33 @@
+From 966e6fd939df724235a93e7a89dd7cf67178f99d Mon Sep 17 00:00:00 2001
+From: Foster Snowhill 
+Date: Sun, 4 Apr 2021 15:12:17 +0200
+Subject: sys_linux: allow setsockopt(SOL_IP, IP_TOS) in seccomp
+
+This system call is required by the DSCP marking feature introduced in commit
+6a5665ca5877 ("conf: add dscp directive").
+
+Before this change, enabling seccomp filtering (chronyd -F 1) and specifying a
+custom DSCP value in the configuration (for example "dscp 46") caused the
+process to be killed by seccomp due to IP_TOS not being allowed by the filter.
+
+Tested before and after the change on Ubuntu 21.04, kernel 5.11.0-13-generic.
+IP_TOS is available since Linux 1.0, so I didn't add any ifdefs for it.
+
+Signed-off-by: Foster Snowhill 
+
+Bug: 
https://listengine.tuxfamily.org/chrony.tuxfamily.org/chrony-dev/2021/04/msg0.html
+Applied-Upstream: 
https://git.tuxfamily.org/chrony/chrony.git/commit/?id=966e6fd939df724235a93e7a89dd7cf67178f99d
+Last-Update: 2021-04-08
+Index: chrony/sys_linux.c
+===
+--- chrony.orig/sys_linux.c
 chrony/sys_linux.c
+@@ -615,7 +615,7 @@ SYS_Linux_EnableSystemCallFilter(int lev
+   };
+ 
+   const static int socket_options[][2] = {
+-{ SOL_IP, IP_PKTINFO }, { SOL_IP, IP_FREEBIND },
++{ SOL_IP, IP_PKTINFO }, { SOL_IP, IP_FREEBIND }, { SOL_IP, IP_TOS },
+ #ifdef FEAT_IPV6
+ { SOL_IPV6, IPV6_V6ONLY }, { SOL_IPV6, IPV6_RECVPKTINFO },
+ #endif
diff -Nru chrony-4.0/debian/patches/series chrony-4.0/debian/patches/series
--- chrony-4.0/debian/patches/series2021-02-21 21:59:22.0 +0100
+++ chrony-4.0/debian/patches/series2021-04-08 16:21:16.0 +0200
@@ -1 +1,2 @@
+allow-IP_TOS-socket-option-in-seccomp-filter.patch
 nm-dispatcher-dhcp_Move-server_dir-to-run.patch