Bug#1069959: nan bug

[Vincent Bernat]

On 2024-11-10 00:52, Pavel Kalvoda wrote:
Hi, dev here, should be patched in https://github.com/PJK/libcbor/ 
pull/335 . Do you need a tagged 
release version?


Hello Pavel,

No need, I can cherry-pick 
https://github.com/PJK/libcbor/pull/335/commits/1ed1517ba56432ed6d6e8bc1ea58231329bd410e 
until there is a new release.


Thanks.

Bug#1084271: Please have /etc/haproxy/haproxy.cfg not owned by package

[Vincent Bernat]

On 2024-10-07 10:31, Thomas Goirand wrote:


During upgrades from one Debian suite to another, dpkg is prompting for
changes to /etc/haproxy/haproxy.cfg. This is very annoying and useless,
as there's no way someone will keep haproxy.cfg pristine unchanged for a
normal workload. Everyone is going to change that file to handle some kind
of workload, and therefore, everyone will be prompted.

The solution could be to have the sample haproxy.cfg stored somewhere else,
like for example /usr/share/haproxy/haproxy.cfg, and have something like this
in the postinst:

if [ ${1} = "configure" ] ; then
if ! [ -e /etc/haproxy/haproxy.cfg ] ; then
cp /usr/share/haproxy/haproxy.cfg /etc/haproxy
fi
fi

This way, only new installations would get the example file, and it wouldn't
be annoying to upgrade.


I don't know if such a pattern is widely applied. If there is a 
packaging change (for syslog, for reload) that requires a configuration 
change, this is the easiest way to communicate the information to the user.

Bug#1082876: keepalived FTBFS on armhf with GCC 14: [-Wincompatible-pointer-types]

[Vincent Bernat]

On 2024-09-27 15:50, Athos Ribeiro wrote:


In Ubuntu, the attached patch was applied to achieve the following:

keepalived FTBFS due to an incompatible pointer type
[-Wincompatible-pointer-types] issue when compiling keepalived with GCC
14 [1] in 32-bit architectures where time_t size is 64 bits.

[1] https://gcc.gnu.org/gcc-14/porting_to.html

The issue was found when compiling keepalived in Ubuntu 24.10 for armhf
with gcc 14
(https://launchpadlibrarian.net/749244069/buildlog_ubuntu-oracular-armhf.keepalived_1%3A2.3.1-1_BUILDING.txt.gz)

   * d/p/fix-armhf-ftbfs.patch: fix -Wincompatible-pointer-types issue in armhf
 which leads to a FTBFS failure due to time_t size. (LP: #2082514)


Thanks for considering the patch.


Since it is merged upstream, I'll wait either to be hit by the bug in 
Debian or a new upstream version to fix that.


Thanks.

Bug#908500: cups-browsed: Please consider making cups-browsed a Suggests:

[Vincent Bernat]

On Mon, 10 Sep 2018 15:16:44 +0100 Brian Potkin  
wrote:



cups-browsed is installed by default because cups-daemon (quite rightly)
recommends it. With the changed situation in CUPS and applications it
would appear that cups-browsed has less relevance with regard to printer
and print queue discovery and management. The Recommends field lists
packages that would be found with the cups package because there is a
strong dependency between it and cups-browsed. cups-browsed would still
enhance cups if changed to a Suggests:.


With the recent vulnerability in cups-browsed, it may be a good idea to 
revisit this subject?

Bug#1079532: haproxy FTCBFS: multiple reasons

[Vincent Bernat]

Hello Helmut,

I am running into this issue when trying to crossbuild with cowbuilder:

The following packages have unmet dependencies:
 builddeps:/build/haproxy_3.0.5-2.dsc:arm64 : Depends: python3-sphinx:amd64
  Depends: python3:arm64 
but it is not going to be installed
  Depends: 
python3-mako:arm64 but it is not installable



I am only adding --git-pbuilder-options="--host-arch arm64" to "gbp 
buildpackage".


Isn't there something to do also for Build-Depends-Indep? I wonder why 
python3-sphinx is not build-depends-indep. I'll investigate that.


On 2024-08-24 11:28, Helmut Grohne wrote:

Source: haproxy
Version: 2.9.9-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability ftcbfs

haproxy cannot be cross built from source for multiple reasons. The
immediate issue is the python3-sphinx dependency. That package is
affected by the multiarch interpreter problem and hence must not be
annotated Multi-Arch: foreign. As a result, the dependency is
technically unsatisfiable. Whilst it can be used in
architecture-dependent ways, that's not the common case and we are
commonly annotating it :native. That's also applicable here as it is
used for manual page generation. If the manual page were not included in
an Arch:any package the preferred solution were to move it to
Build-Depends-Indep.

Then debian/rules does not pass any cross tools to make. While normally,
I'd recommend using dh_auto_build, the install target also uses CC and
dh_auto_install does not pass cross tools. So here, I recommend passing
them explicitly instead.

Last but not least, the upstream build system hard codes the build
architecture pkg-config in a few spots. It is recommended for Makefile
build systems to always refer to it via the PKG_CONFIG variable to allow
passing a different one for cross building.

All of these issues are fixed in the attached patch and it makes haproxy
cross buildable. Please consider applying it and forwarding the upstream
parts.

Helmut

Bug#1069959: libcbor FTBFS on hppa and mips to due different NaN encoding

[Vincent Bernat]

I have temporarily pushed Helge's patch until this is solved upstream.

On 2024-09-11 17:01, Bo YU wrote:

Hi,

Sorry for jumping into this topic.

Is there anything I can do to push for updates to this package?

Becasue the package blocked debci team to create riscv64/testing chroot
on our riscv64 workers due to this FTBFS on mips64el lead to fail to
migrate.

On Mon, Aug 12, 2024 at 10:33:28AM +0200, Aurelien Jarno wrote:

Hi,

...


But for upstream, it just hides the real bug. On those architectures,
the NaN encoding is indeed different, but the resulted encoded data
should be the identical, as defined in the RFC. Therefore I believe the
real fix is to convert NaNs (and probably also infinities) during the
encoding process.


My initial thoughts is to report this to upstream and then we can
disable/skip NaNs related test on Debian side. But I am not sure if this
is appropriate so let me make sure first here.

BR,
Bo

Bug#1072970: RM: graphite-api -- ROM; FTBFS, dead

[Vincent Bernat]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: graphite-...@packages.debian.org
Control: affects -1 + src:graphite-api
User: ftp.debian@packages.debian.org
Usertags: remove

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

No commit on upstream since 7 years.

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmZn804SHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5tBAQAJ4zysFWk9zrvYLird5s9+Bug7yo5tQU
Y5LS8Kbd0jNS4W+ggEDESLFDhz7JL+krrEga1hqQklopo7pw1ZWytSWH0Hk6RDhW
xCQ+Teo1DqoLXqA2XpMxrkws1C98pRbq9yWENz9+rWQwFU2MhEXgz0DUONWl5KQZ
jfcJ/pgK//KxAN4rAla6cnAlFPo7qNCjDLLhky+ynL4IbxKM3YuiQJ0pBO4sgJu7
DOaxTFAqiUBMjjX3ntP4qbuCiL2RiHe89GQ30OhEa8DclcyAmgX7LJoBELb+T1a3
fW4m/fDTPyR+A9Y6V0iT/OJlhrrCfC9RWwlRkt6fV4Id23xUsapeUYEMDhG0K3zf
pGwAHTdtG+rCEHDbUYEL16GSM0u1HiW5p4jFwqbrrJ3o5JQzAsRu+XjCM5zLkSzp
VxCZQy19RldEt0YfRELTo7JfVmtKqpnwRH+8m3dRNJri5fBEOKVsO3D00CwIunYt
g8pPE5Vfj6OIsAp1Z7hroydJOCxlXTzw3WU/DLqR8X2QleLGfDUH6eCiKQzCgX4l
qMLpQStgJpVh0mnvGzIrNJnqfuWwdt4CWNkxQ3zjB1op/klP2ddys/UHvf9D+Jlm
3tdbqSS9VLHik9aMp5cOOnctDC1xXz2nokgSCcKYzqVpf51arHLxUxD4QJam+KWx
zNe+aXvlaLBR
=WFyf
-END PGP SIGNATURE-

Bug#1069959: libcbor FTBFS on hppa and mips to due different NaN encoding

[Vincent Bernat]

Hello Helge,

Couldn't the patch be pushed upstream? And maybe there should be an else 
branch with the encoding of the other NaN?


On 2024-04-27 17:35, Helge Deller wrote:

Source: libcbor
Version: 0.10.2-1.2
Tags: ftbfs
X-Debbugs-Cc: del...@debian.org

libcbor fails to build from source on the hppa and mips architectures.
Reason is, that a testcases which checks the binary representation
of NaN fails on those architectures, because they use a different binary
encoding of the bytes.
See the "encoding" section at https://en.wikipedia.org/wiki/NaN for 
details.


Failure except:
20: [ RUN  ] test_float
20: [  ERROR   ] --- difference at offset 2 0xffbf 0xffc0
20: difference at offset 3 0x 0x00
20: difference at offset 4 0x 0x00
20: 3 bytes of 0x1739c and 0xfa001b57 differ
20: [   LINE   ] --- ./test/float_ctrl_encoders_test.c:150: error: Failure!
20: [  FAILED  ] test_float
20: [ RUN  ] test_double
20: [  ERROR   ] --- difference at offset 2 0xfff7 0xfff8
20: difference at offset 3 0x 0x00
20: difference at offset 4 0x 0x00
20: difference at offset 5 0x 0x00
20: difference at offset 6 0x 0x00
20: difference at offset 7 0x 0x00
20: difference at offset 8 0x 0x00
20: 7 bytes of 0x1739c and 0xfa001b63 differ
20: [   LINE   ] --- ./test/float_ctrl_encoders_test.c:177: error: Failure!

The attached patch avoids this test on hppa and thus building libcbor 
succeeds.

I did not test the patch on mips yet.

Helge

Bug#1065690: lldpd: Does not pick correct IP or hostname

[Vincent Bernat]

The IP address is a global information of the system (so, the same IP 
address is advertised for all interfaces).


The hostname is the result of "getent host $(uname -n)".

On 2024-03-09 00:12, Witold Baryluk wrote:

Package: lldpd
Version: 1.0.18-1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

It sends correct IPv6, but IPv4 and hostname are wrong.

user@debian:~$ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp7s0:  mtu 1500 qdisc mq state DOWN 
group default qlen 1000
 link/ether 10:00:00:0d:b0:00 brd ff:ff:ff:ff:ff:ff
3: enp8s0:  mtu 1500 qdisc mq state DOWN 
group default qlen 1000
 link/ether 10:00:00:00:b0:00 brd ff:ff:ff:ff:ff:ff
8: docker0:  mtu 1500 qdisc noqueue state 
DOWN group default
 link/ether 02:00:00:00:00:90 brd ff:ff:ff:ff:ff:ff
 inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
23: enp10s0f0np0:  mtu 1500 qdisc pfifo_fast 
state DOWN group default qlen 1000
 link/ether 64:00:00:00:00:01 brd ff:ff:ff:ff:ff:ff
24: enp10s0f1np1:  mtu 9000 qdisc fq_pie state 
UP group default qlen 1000
 link/ether 64:00:00:00:00:02 brd ff:ff:ff:ff:ff:ff
 inet 10.0.0.18/24 brd 10.0.0.255 scope global dynamic noprefixroute 
enp10s0f1np1
valid_lft 85650sec preferred_lft 85650sec
 inet6 fe80::0002/64 scope link noprefixroute
valid_lft forever preferred_lft forever



What I see on the switch (MikroTik RouterOS 7.15beta6, on hw model
CRS504-4XQ-IN) connected to directly to enp10s0f1np1:

Interface   qsfp28-4-1# correct
IP Address  172.17.0.1# incorrect
IPv6 Addressfe80::0002# correct
MAC Address 64:00:00:00:00:02 # correct
Identitylocalhost # incorrect
Platform
Version 
Board Name  
Interface Name  enp10s0f1np1  # incorrect



Regards,
Witold

Bug#1065370: RM: pyiosxr -- ROM; dead upstream

[Vincent Bernat]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pyio...@packages.debian.org
Control: affects -1 + src:pyiosxr
User: ftp.debian@packages.debian.org
Usertags: remove

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256




-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmXkhSwSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5ZQkP/AgLRJdg/Q+HCzTHWB0itqjTBXUUKOMl
lU/09LdZp5HUN2bVmhk5UuEXsGtmdN6F5a8V/yt0R17ItqmtwiVMNQwlaKyXrd9M
H4AWHo5d00BEi7F4Msc9+Qwphm/tZrbejPPL/fNA/MaW+/Z8BcqgRTYEYBRD7lig
ecEl9QyLVqURFK9xB2S6qg+Q8XUhL72vJLT7buI6HTa5bFYqqnHCqDLtGZn8N6jD
wmr4Bhh4W3eIJoGU372F8jTnQ8uSrKB/WvH2fTnv5ou8bZxira+P4TDHsAzGGpdU
T4DLw7mkhWtOlTunwIgpUb6OyQuSmbF6mTvwDt13e/lKeGymhxEFE7PuTXZt3FSx
wqeMmS4uZlFSPoqQEn3yz/RDzvt2SLP9n1yX7CUXmr9j0dY0Es9Ve6QLkTjyV4CJ
/8pJXFYWEWggzFh6EnPlQqvTQQ8VucdmBJKdqsb9DjMOTzZoFs6o0n/xJMq+90Ej
zvZTz8ruK2w1NWUPdcSNGA9sUnauV2J+NpWSO714bZNvyoek4G0sO3txuBeL2jao
MkxGh8RxVrE+w/RDEJvcQdn5Fm8z7N2n9s8lFWS4tG8BeK1fu5tzN/n0WfA06MAn
0EKYg2AbQSmIcgqXatQaqeaZfBRv0sfunPduKDnNzbfeWdx2uXVC4s0C1o+jdryG
PJoNZdc4KjNm
=10TI
-END PGP SIGNATURE-

Bug#929830: lldpd: Memory usage of lldpd implies memory leak

[Vincent Bernat]

This is only for FDP/EDP (rare protocols). But a similar problem was 
fixed in earlier releases. So, maybe.


On 2024-01-15 10:56, Gürkan Myczko wrote:

Maybe the memory leak(s) are fixed with 1.0.18?
https://github.com/lldpd/lldpd/releases

Bug#1058794: [Help] Re: python-future: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Vincent Bernat]

On 2024-01-04 00:30, Alexandre Detiste wrote:


@Vincent: this one package "gtextfsm" is yours
do you green light an upload ?


Yes.

Bug#1040988: fixed in picom 10.2-2

[Vincent Bernat]

On Tue, 26 Dec 2023 16:19:12 + Debian FTP Masters 
 wrote:



   * Fix infinite loop with GNOME (Closes: #1040988)


Upstream also added: 
https://github.com/yshui/picom/commit/7366553be2b825495c5b1e09be09d0fabde4b9b4


Otherwise, picom won't start at the beginning of a session (no windows yet).

Bug#1053736: amdgpu firmware are not looked up in all possible paths

[Vincent Bernat]

Source: linux
Version: 6.5.6-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

When amdgpu firmware are in /lib/firmware/updates, they are not detected by the
"amdgpu-firmware-required" patch, preventing the module to load while the
correct firmwares are present.

https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/patches/bugfix/all/radeon-amdgpu-firmware-is-required-for-drm-and-kms-on-r600-onward.patch

Also, maybe the situation in 2013 is not the same in 2023 and we should just
drop the patch?


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

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

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmUkcSYSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5b1EQAJvTSc0ZV3duNoF/rjNbkfWJOcbu63Fu
tmSYaWHzuCAgoXUZIFt+6BZTRbVMGFMFeNHhuR/qd8cq6Rh/qdH5AiICR5aV3Xts
c/TYVbrJNsj0fpsO7+sbaDMzvnJ7Ccu6qWbDfo/YLkNzU7AAHJS8M8pkepAwY830
najSkl3NeQPADp268V42HfpF+O8okTxuHXUpbzYlYODSw+kj7MCCJUvSPb5NtQOg
EyF32bOQZ86TtM99atbMdywGKwGN5q8qbiuJmQJuKsF0I7CaYDYewfOkpnAaps4n
3SFhiEBDu1Xhvif89umt6K/AU9Qp6Fz2wXycEmDgUArIuDc9Y2hddNneKXe93tE4
kN0OeyyEWebmwwWJlGBIios7EYugA6p7n9yNkS3fL5YaRkPm3GAWEruU9bLrLVVZ
xXfq7PqzBxSl1lzkZwi6fN85LZ2HOwcHDKP9yFiQG+bXse0/4VRhXePgTlXY+DXV
Pi/apu1kGMlOOOhs4uniH+3EHGwvHNOofPoCd2WG0aQ/c+VHlqD/0Bc5/bg7inX9
oicyKKhLZvvURp1wgQrEpqUuPopecDgNkyY16iyi2cpMrIFM6HchRUIyBnto1Nay
IyBL5XgxEnfj8ZcIKiQf8Yx9CfXUluJghWCqpKG5LQpkEWB/pCLZrnctM5ywDXF5
Tzoiu8OLqeXH
=6yHp
-END PGP SIGNATURE-

Bug#1052613: Keepalived occasionally fails SSL_CHECK

[Vincent Bernat]

Hello Pavel,

I'll be more comfortable if you submitted this patch upstream first.

On 2023-09-25 12:48, Pavel Matěja wrote:

Package: keepalived
Version: 1:2.2.7-1

I'm upgrading our servers from Bullseye to Bookworm. Some of them act as load 
balancers using keepalived.
Right now I have one Bullseye and one Bookworm with the same configuration 
checking the same services.
Several of our services are running on HTTPS therefore I'm using SSL_CHECK.
I can see that the Bookworm one occasionally fails SSL_CHECK for several 
seconds on one service while the
Bullseye does not report any problem at all.
It's quite rare - not even once per hour with 2s loop delay.

I was looking for possible reason and I've found
https://github.com/openssl/openssl/issues/20365
https://github.com/pjsip/pjproject/issues/3632
https://stackoverflow.com/questions/18179128/how-to-manage-the-error-queue-in-openssl-ssl-get-error-and-err-get-error

They are all basically saying that you can have multiple SSL errors left in 
error queue and you are supposed to
run|ERR_get_error() before calling |SSL_* functions.

I've tried to patch keepalived sources (see attachment) and the problem seems 
to disappear.

I have no idea why is Bullseye package unaffected. It might be related to 
different OpenSSL version.

What do you think about this?

--
Pavel Matěja

Bug#1039968: python3-tvdb-api: Incompatible with requests-cache version in repositories

[Bernat Arlandis]

Package: python3-tvdb-api
Version: 3.1-2
Severity: serious
Tags: upstream newcomer
Justification: Policy 2.2.1

Dear Maintainer,

This bug renders the package tvnamer completely useless. It always fails with
this error when trying to connect remotely to TVDB:

Traceback (most recent call last):
  File "/usr/bin/tvnamer", line 6, in 
tvnamer.main.main()
  File "/usr/share/tvnamer/main.py", line 474, in main
tvnamer(paths = sorted(args))
  File "/usr/share/tvnamer/main.py", line 370, in tvnamer
processFile(tvdb_instance, episode)
  File "/usr/share/tvnamer/main.py", line 175, in processFile
episode.populateFromTvdb(tvdb_instance, force_name=Config['force_name'],
series_id=Config['series_id'])
  File "/usr/share/tvnamer/utils.py", line 641, in populateFromTvdb
show = tvdb_instance[force_name or self.seriesname]
   ~^^^
  File "/usr/lib/python3/dist-packages/tvdb_api.py", line 1152, in __getitem__
sid = self._nameToSid(key)
  
  File "/usr/lib/python3/dist-packages/tvdb_api.py", line 1136, in _nameToSid
selected_series = self._getSeries(name)
  ^
  File "/usr/lib/python3/dist-packages/tvdb_api.py", line 935, in _getSeries
all_series = self.search(series)
 ^^^
  File "/usr/lib/python3/dist-packages/tvdb_api.py", line 914, in search
series_resp = self._getetsrc(self.config['url_getSeries'] % (series))
  ^^^
  File "/usr/lib/python3/dist-packages/tvdb_api.py", line 874, in _getetsrc
src = self._loadUrl(url, language=language)
  ^
  File "/usr/lib/python3/dist-packages/tvdb_api.py", line 811, in _loadUrl
self.authorize()
  File "/usr/lib/python3/dist-packages/tvdb_api.py", line 859, in authorize
r = self.session.post(
^^
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 635, in post
return self.request("POST", url, data=data, json=json, **kwargs)
   ^
  File "/usr/lib/python3/dist-packages/requests_cache/session.py", line 115, in
request
return super().request(method, url, *args, **kwargs)
   ^
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 587, in
request
resp = self.send(prep, **send_kwargs)
   ^^
  File "/usr/lib/python3/dist-packages/requests_cache/session.py", line 127, in
send
cache_key = self.cache.create_key(request, **kwargs)

TypeError: create_key() got an unexpected keyword argument 'timeout'

This is due to changes in the API to requests-cache. It seems upstream isn't
updating the code anymore but I've created a PR anyway:
https://github.com/dbr/tvdb_api/pull/105

I've tried these changes in Debian Boookworm and they fix this issue and others
related to changes in requests-cache.

I hope someone can patch these changes into the Debian sources.

Thanks.
Cheers.


-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python3-tvdb-api depends on:
ii  python3 3.11.2-1+b1
ii  python3-requests2.28.1+dfsg-1
ii  python3-requests-cache  0.9.8-1

python3-tvdb-api recommends no packages.

python3-tvdb-api suggests no packages.

-- no debconf information

Bug#1037185: bpftrace: Fix FTBFS on armhf

[Vincent Bernat]

On 2023-06-07 12:07, Danilo Egea Gondolfo wrote:


* What led up to the situation?

The build is failing on armhf because cmake is not detecting the 
architecture correctly as we cross compile on arm64.


Also, after fixing the cmake part, the build will fail in src/triggers.h 
due to the attribute used when it build on arm 32-bit. It might be a bug 
on gcc but I'm not sure (clang++ doesn't throw the same error).


Shouldn't all this be fixed upstream?

Bug#1031912: Package cirrus/ directory

[Vincent Bernat]

Source: firmware-nonfree
Version: 20230210-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

The Cirrus Logic CS35L41 is a DSP with firmwares shipped upstream in the cirrus/
directory. It would be nice to build a package for that (firmware-cirrus?).

Thanks!


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

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

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmP5ySASHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5hDYP/0+bw+0ar+FW4QdtfObxjhSr6IAS10DR
avdy4linMxK8rdmn3PV44F4sC5A1TnfCILthLtLgM8urraJj9CD0kNR+WHL2hxI7
qrmSXYoBIFlMtP6rR4ICupzM1HAU2Gb4XCTVJz5CFt/w0JBGXXkKfeQA8b0HRWDy
LiSbS9qWY+kJpmvSbzIJzChz5N64TJziRNPhDsy8vHAzMXBkcc5G4oyU2jdoAyuk
VfXgHFyJ2kZYiv1/dvvzGy3bXYK9pv+Q/oYq86Ty9LPwudI5xBVMiEAwOKq126HX
1ZtGvEDXV1JgRKap1+9Rhyvkf1j5F4ANGfnr/GmOL94uhdpDOh0Hrdasgw6/klBt
HiwBXzFQkZjXE5RhKeAjXMiCSkpbvPY5o8aJZTfqMjhV17qUN2yw7lGfVfl4rDOG
2xdK+c+/UHfgprAcPCXUCCZ1GROYXXh36KJlX2v5UNGKm37rXKvxmcbBsWj5SPIc
UCy1zOUdKvKig01WrGkS5tAVK8jKWMOPGidD+DMVN0LcbdemPkG3LTYbXZDg4qSy
leKJ+wOlrHhX03thPl3q3KzU0Ufpr8FGPQwcM2Ku3g0u+fKYwoPjNXPrl5znGEnf
IYHUBNS/muIfPS3e6vFqMma8VWpj9PaqZGR60iEOygMavDwDDMG92oScD3bPq6wu
sbPxjVIqIU4S
=iiuL
-END PGP SIGNATURE-

Bug#1029992: xtl: new upstream version 0.7.5 available

[Vincent Bernat]

On 2023-01-30 00:31, Drew Parsons wrote:

Source: xtl
Version: 0.7.2-2.1
Severity: normal

xtl 0.7.5 has just been released.  The latest version of xtensor needs
it (uses xtl/xcompare.hpp), and we need the latest version of xtensor
in order to support the latest version of xsimd.  The latest release
of xsimd fixes some issues which makes pythran more stable and more
effective.  scipy uses pythran to accelerate computations.

tl;dr:   Would it be possible to upload the new version of xtl to
experimental so we can test it alongside xsimd 10.0.0 ?


Hello Drew,

Done.

Bug#1030173: Document breaking changes in NEWS.Debian

[Vincent Bernat]

On 2023-01-31 23:09, Lee Garrett wrote:


I've written a NEWS file for you:


Thanks, it will be part of the next upload.

Bug#1030173: Document breaking changes in NEWS.Debian

[Vincent Bernat]

On 2023-01-31 21:44, Lee Garrett wrote:


with release 2.6 haproxy has dropped the "ssl-engine" keyword by default. Would
be nice to document that in NEWS.Debian so it gets shown by tools such as
apt-listchanges during upgrade from bullseye to bookworm.

In my case haproxy failed to start with my bullseye config since it still had
the "ssl-engine" keyword in it.


I understand this would be useful, but it opens me to get bugs like 
"NEWS.Debian says something about ssl-engine, but not about some other 
change". I would need to make a summary of upstream's CHANGELOG file. 
This seems a tedious task.

Bug#1027382: Please, minimize your build chroots

[Vincent Bernat]

On 2023-01-28 13:59, Adrian Bunk wrote:

I am not saying that trying to force maintainers to spend time on such
issues by making them release critical is better, but you are also
creating extra work and frustration for the people who are doing QA work
in Debian.


It also pushes some maintainers to give up on packages. I gave up on 
maintaining any Go package after the whole "everything should compile 
with only one CPU because policy says so" fiasco. The most rare resource 
we have is volunteer time. Creating artificial problems is not helping.

Bug#1027382: Please, minimize your build chroots

[Vincent Bernat]

On 2023-01-28 00:20, Santiago Vila wrote:

Release Policy exists as a canonical list of what should be RC and > what not, 
and it's intended to avoid stupid discussions like this one.


Extending build-essential is easier than asking many people to do 
pointless work to satisfy a set of non-existing users. It is not like we 
had several reports of people complaining they can't build a package 
because they are in an environment without tzdata. It is not OK to 
create problems to force many volunteers to do extra work.

Bug#958895: libevhtp-dev: libtool arguments failure

[Vincent Bernat]

On 2023-01-27 08:48, Alexandre Rossi wrote:


Now that the blocking bug is fixed, I thing the patch should be uploaded to 
unstable.
Do you want me to prepare a build for you to upload?


Yes, please do.


An updated package is available on mentors.
https://mentors.debian.net/package/libevhtp/


Thanks, it's uploaded!

Bug#1021502: lintian: incorrectly complains about debian-news-entry-has-unknown-version

[Vincent Bernat]

On Tue, 11 Oct 2022 20:11:07 +0200 Axel Beckert  wrote:

> > Please investigate and fix this bug in lintian.

I see no possibility how to do that in Lintian except for switching
the check from a binary to a source package check. Not sure if this is
that easily doable. Additionally it will become more complex as it
would have each per-binary-package debian/.NEWS files
separately. (It would also invalidate any lintian override about it.)

But I actually would prefer to not have to do that at all as IMHO that
tag is validly emitted and this is IMHO a newly introduced bug in
debhelper. Cloning an according (wishlist) bug report against
debhelper


As it won't be fixed in debhelper either, maybe downgrade this warning?

Bug#958895: libevhtp-dev: libtool arguments failure

[Vincent Bernat]

On 2023-01-12 08:46, Alexandre Rossi wrote:

Now that the blocking bug is fixed, I thing the patch should be uploaded to 
unstable.
Do you want me to prepare a build for you to upload?


Yes, please do.

Bug#1023697: Keep out of testing

[Vincent Bernat]

On Thu, 10 Nov 2022 22:45:57 +0100 Bastian Germann  wrote:

As a new maintainer has stepped up, this cannot be the reason anymore to dump 
the package.
Actually, with the next version of swupdate (one of those handful) I wanted to 
switch from OpenSSL
to SWUpdate.


As there are no real plan to provide QUIC support in OpenSSL 3 and the 
performance regressions of OpenSSL 3 are quite important, I may also 
switch HAProxy to WolfSSL.

Bug#689962: linux: Compile with CONFIG_VIRTIO_CONSOLE=y

[Vincent Bernat]

  ❦ 24 avril 2021 16:15 +02, Salvatore Bonaccorso:


Is this still something we should consider, or can the bug be closed?


I suppose that's since almost nobody chimes in in all these years, there
is no need.


Now that 989153 and 989181 have been merged into this one and the bug is
reopened, then the next question becomes: how to proceed.

The current setting in debian/config/config (ie: globally) is this:
CONFIG_VIRTIO_CONSOLE=m

I can make a MR to change that to =y, but I'm not familiar with VIRTIO_CONSOLE
and thus can't assess whether it's useful on all architectures.

https://salsa.debian.org/kernel-team/linux/-/commit/e83e9da65cce7c870acc6b601738dd5d71bdc842
is where the above setting was made ... on 2008-09-04.

The helptext in drivers/char/Kconfig says:
"Virtio console for use with hypervisors."


Unfortunately, I don't know either for other architectures. It is useful 
at least for AMD64 (to make it work on VM with no ISA bus). For ARM64, I 
don't know if the platform has a better mechanism for serial consoles.

Bug#1023537: bpftrace/libbpf: SIGSEGV at btf_find_by_name_kind()

[Vincent Bernat]

On Sun, 06 Nov 2022 10:01:09 + Breno Leitao  wrote:


bpftrace is segfault on everycommand when running on 6.0 kernel:


It works for me. Can you try again with bpftrace 0.16.0-1+b1?

Bug#1023974: Dependency missing

[Vincent Bernat]

On 2022-11-13 12:30, Philipp Marek wrote:


 # bpftrace
 bpftrace: error while loading shared libraries: libclang-15.so.13: cannot 
open shared object file: No such file or directory


I am not able to reproduce on my system. I don't have libclang1-15 at 
all and it works. bpftrace is not linked to libclang 15 but to libclang 
14. Are you sure bpftrace is the one from the Debian package, not 
side-compiled version?

Bug#1023485: Shipped blkid is incompatible with the one in util-linux, break cryptsetup

[Vincent Bernat]

Package: busybox-static
Version: 1:1.35.0-3
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

blkid was added as an applet in busybox. This makes it available in initramfs in
place of the one from util-linux. This prevents cryptsetup to works as the
syntax used is not recognized by busybox.

 10:58 ❱ blkid -l -t UUID=255e21df-9261-47b5-ac37-b4ae4c435a37 -o device
/dev/nvme0n1p3
 10:59 ❱ busybox blkid -l -t UUID=255e21df-9261-47b5-ac37-b4ae4c435a37 -o device
 10:59 ❱ sudo busybox blkid -l -t UUID=255e21df-9261-47b5-ac37-b4ae4c435a37 -o 
device

cryptsetup-initramfs could parse the output of busybox blkid, but this seems
more fragile. It seems easiest to not ship blkid in busybox (hence the bug
against busybox).

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

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmNmNPMSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5xT0QAKDHldn2kpQ+q5++vOpu05hYLsz9VkWp
ud2ZH+gNXc85qDHvTN+kKu+h1nMbK8Qk/x6o/orRzvRBAwmJ6XE06tBBulOahoKi
q8dxYorvXQJV3bI7ua1JYsYKTybguE/omN27IguopQdzE1Bac5fkfcKwni5QHEdi
oOda3FNVAdQiZ7mh77nBaD9NtqG4lzMb4rbxwQ5ZGG2BOypVQ7CHnoyPt813PjSI
eh76R5cW9/KgyqbWo4mGVGtZ8DqmVY+BLuVKH0+g+zreieRlbTLhJakwYCUJ4SNS
6ye9M58xtgviBbDUBl4ae7LV9ARSa9RpG6wkLgVw36CrD/QAwAoSsjJwcPRg2xGH
P7O8nyT+tyP3xFmNGAHfJpLO/CPh8B3rNJABSO6F8hGzoh2Ej8zFfmEZ3CfchnmR
SatUtS5yBlvU3wvkdK0VMDpXOdqqJjDkexjm28vriBvyAUi07OBsbqtEILGgJXb6
bOXv6hGWg5F/qA+OgjWdu6YJUbBrZVH7gvePbr5lmwwGItDc0UIrAZxZ5/1FIi5G
G9+NTS+kpFFT0uvD8F6HaqZrPGTSDJM5DSoHxZLkYSYJjZzbrC2Fk9w3AaE7/6u/
05EVetREI89NvCt7GJbvS0jCWIlk3JVMAfbDvoNm6vqqTGJPEMjW81ABkJk6QKpF
3UcOjdL4nGqS
=KLT1
-END PGP SIGNATURE-

Bug#1021157: missing firmwares for Qualcomm NFA725A

[Vincent Bernat]

On 2022-10-29 20:05, Diederik de Haas wrote:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/?qt=grep&q=WCN6855
does show various results which come very close ...SILICONZ_LITE-3.6510.7 vs
the referenced ...SILICONZ_LITE-3.6510.16.
And one commit is for symlinks to hw2.1

qca/rampatch_usb_00130201.bin is also present in the upstream repo, but
searching for nvm_usb_00130201_gf.bin did not yield any results.

So this looks like upstream does have most of the needed files, albeit a
slightly older version?
I don't know if anything should be done based on this, but figured I'd share
my findings.


I suppose the search engine only works for stuff mentioned directly in 
commit messages. The file present in the repository: 
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/qca/nvm_usb_00130201_gf.bin.

Bug#1022848: linux: 6.0.5 fixes critical btrfs bug

[Vincent Bernat]

On 2022-10-29 09:23, Salvatore Bonaccorso wrote:

So question is,.. would it make sense to request that linux-image-amd64
depends on the signed | unsigned version?


No unfortunately we cannot do that. The reason is similar to what lead
to
https://salsa.debian.org/kernel-team/linux/-/commit/248736d493fcfd0e05cd23f97befe40f5c125c71
or caused bugs like #916927.

In meanwhile furthermore linux-image-amd64 is anyway not anymore from
a separate metapackage but built from linux-signed-amd64.

The signed packages need always longer as this needs action of signing
them trough a seprate manual process of ftp-masters.


What about linux-image-amd64-unsigned?

Bug#1021157: missing firmwares for Qualcomm NFA725A

[Vincent Bernat]

On 2022-10-29 07:15, Vincent Bernat wrote:

  07:14 ❱ dpkg -L firmware-atheros | grep -E '(WCM6855|nvm_usb_00130201)'


I made a typo in WCN, but the files are not here either.

Bug#1021157: missing firmwares for Qualcomm NFA725A

[Vincent Bernat]

On 2022-10-29 00:50, Diederik de Haas wrote:


The card works just fine with a 5.19 kernel after installing these files
in /usr/lib/firmware/ath11k/WCN6855/hw2.0/:
https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/1.1/WLAN.H
SP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.16/amss.bin
https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/1.1/WLAN.
HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.16/m3.bin
https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/board-2.b
in
https://github.com/kvalo/ath11k-firmware/raw/master/WCN6855/hw2.0/regdb.bin

And then creating a symlink from /usr/lib/firmware/ath11k/WCN6855/hw2.1/
to hw2.0/ .

(I do not understand the structure of the directories in
WCN6855/hw2.0/1.1/, so I choose the newest files.)

Some other firmwares from
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
/tree/qca are needed for Bluetooth support and are missing as well:

qca/rampatch_usb_00130201.bin
qca/nvm_usb_00130201_gf.bin


I found all the mentioned file names in the buildd log for 20220913-1, so I
guess the issue is fixed.
Can you verify that and update/close the bug accordingly?


They are not present.

 07:14 ❱ dpkg -L firmware-atheros | grep -E '(WCM6855|nvm_usb_00130201)'

Bug#968997: fwupdmgr: "Successfully" updates BIOS firmware, no effect on reboot

[Vincent Bernat]

On Fri, 10 Sep 2021 10:35:31 +0200 Julian Andres Klode  
wrote:

Control: reassign -1 shim
Control: affects -1 fwupd

On Fri, Sep 10, 2021 at 09:27:11AM +0200, Norbert Schulz wrote:
> Package: fwupd
> Version: 1.2.14-1~deb10u1
> Followup-For: Bug #968997
> 
> Dear Maintainer,
> 
> this bug still exist for a long time. I removed all packages relating fwupd and install it from scratch but 
> no install of the firmware on reboot. 


Sure, that's expected, shim 15.4 is not able to load fwupd without
additional patches, which have not been applied yet, so it's
not going to get better by reinstalling fwupd.


shim-unsigned has been updated to 15.6 which has the right patches in. 
But for some reason, shim-signed is still at 15.4.

Bug#1010039: autorandr: python deprecation warnings

[Vincent Bernat]

On Fri, 22 Apr 2022 16:52:35 -0700 Don Armstrong  
wrote:


> % autorandr 
> /usr/bin/autorandr:42: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives

>   from distutils.version import LooseVersion as Version

Thanks for the report!

Looks like upstream has fixed this, so I just need to upgrade to the
newest version.


Hey Don!

Any plan for that?

Thanks!

Bug#1017676: bpftrace: Please upgrade to llvm-toolchain-14

[Vincent Bernat]

On 2022-08-18 23:43, Sylvestre Ledru wrote:

Source: bpftrace
Severity: important

Dear Maintainer,

As part of the effort to limit the number of llvm packages in the
archive, it would be great if you could upgrade to -14.

We are trying NOT to ship Bookworm with llvm-toolchain-13.

llvm-defaults is now pointing to -14.


I was about to upload. Can I still proceeed or should I not?

Bug#1017079: ITP: netbox -- WebUI based tool designed to manage and document computer networks

[Vincent Bernat]

On 2022-08-13 09:59, Carsten Schoenert wrote:

The NetBox UI is using some comprehensive JS files which are shipped as
minimized files. Currently I'm unable to drop the shipped minimized code
and rebuild all the needed files from scratch. If possible I'd like to
get some help on this, currently netbox will need to go into non-free due
the non rebuild-able minimized files.
OTOH netbox can't go into main as it requires at least one package from
non-free, it requires drf-yasg-nonfree for some Swagger functionality.


It also looks like drf-yasg-nonfree is non-free just because of the 
minimized JS files. This is often a problem and while not everybody 
agrees with this, you can workaround this issue by shipping the 
non-minified sources in debian/missing-sources. You may or may not use 
them in the build process. Maybe it does not hurt to try to run a 
minifier (like uglifyjs) on them if you feel like it. As long as 
upstream is using the files as is, the FTP masters are likely to accept 
a package with the sources in debian/missing.

Bug#1015210: OUI lookups incorrect

[Vincent Bernat]

On 2022-07-17 21:54, Jonathon Reinhart wrote:

Are you suggesting that python3-netaddr would need its own directory
somewhere under /var for the updated index files? (Because /usr
shouldn't change, and /var/lib/ieee-data isn't controlled by
python3-netaddr)


That's right.

Bug#1015210: OUI lookups incorrect

[Vincent Bernat]

On 2022-07-17 20:40, Jonathon Reinhart wrote:


OUI lookups are returning incorrect / corrupt results. Take for
example OUI F4-6D-04.

The data in ieee-data is correct:

 F4-6D-04   (hex)ASUSTek COMPUTER INC.
 F46D04 (base 16)ASUSTek COMPUTER INC.
 15,Li-Te Rd.,Peitou,
 Taipei112
 TW

But using the OUI object I get completely incorrect / corrupt results:

 >>> oui = OUI('F4-6D-04')
 >>> oui
 OUI('F4-6D-04')
 >>> oui.registration()
 {'address': [')\t\tCisco Systems, Inc',
 '80 West Tasman Drive',
 'San Jose  CA  94568',
 'US'],
 'idx': 16018692,
 'offset': 821392,
 'org': 'eero inc.',
 'oui': 'F4-6D-04',
 'size': 141}

I suspect that the reason is because this debian package replaces
netaddr/eui/oui.txt with a symlink to /var/lib/ieee-data/oui.txt but
**does not** update the corresponding oui.idx. Thus, the indices are
stale.

This Debian package likely needs to re-generate the indices before shipping.


It's already the case. However, the file can change unexpectedly (for 
example, when the user is running update-ieee-data). It seems that 
update-ieee-data will execute hooks in /var/lib/ieee-data/update.d. We 
could install such a hook. But, we would also need to add a symlink for 
the indexes to a directory controlled by the netaddr package.


If you want to try to do that, you are welcome to submit a patch.

In the meantime, you can run python3 
/usr/lib/python3/dist-packages/netaddr/eui/ieee.py as root to fix the 
issue. This is not really "clean" (as you erase package-owned data), but 
it would work.

Bug#1013581: Please rebuild to pick up the new libXi.6 dependency.

[Vincent Bernat]

Version: 3.19-9

On 6/24/22 13:39, Peter Pentchev wrote:

If this is the case, could you just request a binNMU?


Hm, that's actually an interesting idea... I'll look into it, and,
in that case, sorry for bothering you! :) So yeah, I will look into
it and probably close this bug accordingly.


I have uploaded a new version.

Bug#1013581: Please rebuild to pick up the new libXi.6 dependency.

[Vincent Bernat]

On 6/24/22 13:05, Peter Pentchev wrote:

Source: xnee
Version: 3.19-8
Severity: serious
X-Debbugs-Cc: r...@debian.org

Hi,

First of all, thanks for taking care of cnee/xnee in Debian!

At some point recently, the XIQueryVersion() function from the X11 API
moved to a separate library, libXi.so.6, found in the libxi6 Debian package.
Since cnee 3.19-8 (in both unstable and testing) has not been linked
against libXi.so.6 at build time, it does not try to load it, resulting in
errors such as:

 [roam@straylight ~]$ cnee --replay -f /dev/null; echo "exit code $?"
 cnee: symbol lookup error: /lib/libxnee.so.0: undefined symbol: 
XIQueryVersion
 exit code 127

...which breaks any program that tries to invoke cnee, leading to e.g.
the wmanager tests breaking in #1013579.

I think that a simple rebuild should be enough - I tested it on my local
system and the cnee binary is now linked against libXi.so.6, too.


If this is the case, could you just request a binNMU?

Thanks.

Bug#1011391: [Pkg-openssl-devel] Bug#1011391: openssl: please support quictls patchset

[Vincent Bernat]

 ❦  8 June 2022 07:44 +02, Sebastian Andrzej Siewior:

>> Willy Tarreau already asked the team for QuicTLS packaging without an
>> answer:
>> 
>> https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2021-October/007668.html
>
> there was an answer:
>
> https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2022-January/007702.html

Oh, sorry for saying otherwise. It seems pipermail does not provide
links when a thread span over two months.

As for the last paragraph, OpenSSL team said API compatibility with the
patchset is a non-goal and it was also said they would like to not use
the same approach by unifying the various way to handle TLS flavors. So
it seems likely QuicTLS will die at some point. However, QUIC support
will appear during a major version of OpenSSL, so previous version
supporting the QuicTLS patchset will continue to receive security
support and I suppose that it gives time for the few users to migrate
to the proper OpenSSL API.

I can relay your questions directly to QuicTLS on GitHub unless you want
to do it yourself.
-- 
Use library functions.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#1011391: openssl: please support quictls patchset

[Vincent Bernat]

 ❦ 22 May 2022 16:50 +02, Sakirnth Nagarasa:

> This patchset of OpenSSL is necessary to build the crypto helper
> libraries for ngtcp2 with OpenSSL as well.

HAProxy is also a user of such a fork. It should be noted the fork is
backed by Akamai and Microsoft and is able to release updated versions
the same day as OpenSSL and they managed to make the library
coinstallable with the regular OpenSSL one. So, we could also provide a
libssl3-quick library.

Willy Tarreau already asked the team for QuicTLS packaging without an
answer:

https://alioth-lists.debian.net/pipermail/pkg-openssl-devel/2021-October/007668.html

My opinion is that we cannot rely on OpenSSL to provide a solution in
the near term (no work is currently done). As the number of downstream
projects increase, users will try to find a solution. It would be better
to have a solution backed at least partially by their distribution.

It would be nice to have some kind of feedback to know how things are on
the Debian side for this OpenSSL fork.
-- 
Make sure comments and code agree.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#1010849: DWARF support disabled during build / no symbolic stack traces or argument types

[Vincent Bernat]

 ❦ 11 May 2022 16:00 +02, Harald Welte:

> It seems the Debian bpftrace is built without libdw support.  This means no 
> stack
> traces can be provided with uprobes, and one cannot dereference structs or 
> other
> type information from the DWARF information.
>
> # bpftrace -lv 
> 'uprobe:/usr/local/lib/libosmocore.so.18.0.0:osmo_timer_schedule'
> WARNING: Cannot parse DWARF: libdw not available

No particular reason. I have added it to as a build-dep and it works
just fine. Well, it took me two tries!
-- 
There is a great discovery still to be made in Literature: that of
paying literary men by the quantity they do NOT write.

Bug#1008323: bpftrace: fix FTBFS

[Vincent Bernat]

 ❦ 11 April 2022 21:14 +02, Hector Oron:

>   According to https://github.com/iovisor/bpftrace/issues/2068
>
>   I applied the following patch to make the package build:

Thanks! I will use the more minimal patch found here instead:
https://github.com/iovisor/bpftrace/pull/2174
-- 
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#960420: Needs versioned dependency on slop

[Vincent Bernat]

 ❦ 12 May 2020 14:25 +02, Yuri D'Elia:

> I didn't realize maim depended on slop through a dso (I assumed it
> simply called the binary).
>
> slop was updated to 7.5, which broke maim as a result:
>
> maim: error while loading shared libraries: libslopy.so.7.4: cannot
> open shared object file: No such file or directory

Again with the latest upload.

 10:16 ❱ maim
maim: error while loading shared libraries: libslopy.so.7.5: cannot open shared 
object file: No such file or directory

-- 
Your manuscript is both good and original, but the part that is good is not
original and the part that is original is not good.
-- Samuel Johnson

Bug#995028: ncal: incorrect week numbers listed when using -w option

[Vincent Bernat]

 ❦ 24 September 2021 16:33 -07, Andy Bussman:

> ncal lists incorrect week numbers when using the -w option.
>
> Week numbers do not conform in the ISO-8601 standard, even though the
> man page states that the "-w" option is ISO-8601 compliant.

FI, the bug is also present upstream.
-- 
Make sure all variables are initialised before use.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#1008222: bind unicast_src x.y.z.w failed 99 - Cannot assign requested address

[Vincent Bernat]

 ❦ 25 March 2022 11:48 +01, Arturo Borrero Gonzalez:

>> After looking twice, I notice the VIP is in the same subnet as the peer.
>> If you don't have any other address on the subnet, I don't see how this
>> could work. If you have, maybe it would be better to use a /32 for the
>> VIP.
>
> Would you mind to elaborate?
>
> The setup is as follows:
>
> * peer 1, local IP 208.80.153.188/29
> * peer 2, local IP 208.80.153.189/29
> * VIP 208.80.153.190/29
>
> I honestly don't know how this relates to the execution error itself.
> Do you think the address assignment fails because some misconfigured
> netmask?

Usually, on Linux, VIP are using /32 to avoid issues with source address
selection. Notably, when contacting a peer, the VIP could be selected
when using a /29, while this is not possible when using a /32.
-- 
Its name is Public Opinion.  It is held in reverence.  It settles everything.
Some think it is the voice of God.
-- Mark Twain

Bug#1008222: bind unicast_src x.y.z.w failed 99 - Cannot assign requested address

[Vincent Bernat]

severity -1 important
fixed -1 1:2.2.7-1~bpo11+1
thanks

 ❦ 24 March 2022 17:24 +01, Arturo Borrero Gonzalez:

> This exact same setup was previously working, and actually, the next version 
> works just fine.
> Not sure if this has anything to do with the kernel version warning at the 
> beginning.
>
> In summary:
>
> | keepalived version  | Debian   | Works? |
> | |--||
> | 1:2.0.10-1  | buster   | yes|
> | 1:2.1.5-0.2+deb11u1 | bullseye | no |
> | 1:2.2.7-1~bpo11+1   | bullseye-bpo | yes|
>
> I'm opeining this bug report mostly so others can find it.
> Raelly appreciated the bpo package is ready to use.

Glad that the backport solves this issue. Unfortunately, I don't think
it's worth reporting the issue upstream as they don't like us lagging so
many versions late. I have used it myself with unicast_src, so it is not
broken for everyone.

After looking twice, I notice the VIP is in the same subnet as the peer.
If you don't have any other address on the subnet, I don't see how this
could work. If you have, maybe it would be better to use a /32 for the
VIP.
-- 
If one cannot enjoy reading a book over and over again, there is no use
in reading it at all.
-- Oscar Wilde

Bug#1007800: golang-golang-x-tools: FTBFS with Go 1.18

[Vincent Bernat]

 ❦ 16 March 2022 18:39 -05, William 'jawn-smith' Wilson:

> golang-golang-x-tools currently FTBFS with Go 1.18
>
> In Ubuntu, the attached patch was applied to achieve the following:
>
>
>   * Fix FTBFS with Go 1.18

Hello,

gopls has issues with Go 1.18. Better upgrade to the latest upstream
version.

Thanks.
-- 
There are more things in heaven and earth,
Horatio, than are dreamt of in your philosophy.
-- Wm. Shakespeare, "Hamlet"

Bug#1006427: New upstream version: 2.2.7

[Vincent Bernat]

 ❦  9 March 2022 12:37 +01, Alexander Wirt:

>> >> A new upstream version has been published. Would you mind if I take
>> >> over the package? I work next to the upstream author and I am often
>> >> badgered by the package being not up-to-date. :)
>> 
>> > I would be glad if you would take over. Unfortunately I am more or
>> > less in management nowadays and less in maintaining clusters.
>> 
>> Thanks! Do you prefer I move the repository under the Debian namespace
>> on Salsa or that I keep it under ipvs-team?

> Whatever you like more. It is yours, just tell me so that I will be
> able to move the repo.

If you don't mind, can you move it to the Debian namespace?

Thanks!
-- 
Write clearly - don't sacrifice clarity for "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)

Bug#1006961: exabgp.env not loaded with systemd Service

[Vincent Bernat]

 ❦  9 March 2022 13:18 +01, Adrian:

> ExecStart=/usr/sbin/exabgp -e /etc/exabgp/exabgp.env /etc/exabgp/exabgp.conf 
> # < manually added env file

/etc/exabgp/exabgp.env is the default value when no -e option is provided.
-- 
A horse!  A horse!  My kingdom for a horse!
-- Wm. Shakespeare, "Richard III"

Bug#1006427: New upstream version: 2.2.7

[Vincent Bernat]

 ❦  4 March 2022 10:47 +01, Alexander Wirt:

>> A new upstream version has been published. Would you mind if I take
>> over the package? I work next to the upstream author and I am often
>> badgered by the package being not up-to-date. :)

> I would be glad if you would take over. Unfortunately I am more or
> less in management nowadays and less in maintaining clusters.

Thanks! Do you prefer I move the repository under the Debian namespace
on Salsa or that I keep it under ipvs-team?
-- 
Parenthesise to avoid ambiguity.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#1006427: New upstream version: 2.2.7

[Vincent Bernat]

Source: keepalived
Version: 1:2.2.4-0.2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

A new upstream version has been published. Would you mind if I take
over the package? I work next to the upstream author and I am often
badgered by the package being not up-to-date. :)

Thanks.


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

Kernel: Linux 5.16.0-rc2+ (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmIYr6oSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5+58P/RP4CWS+i+eUmfyN4FfUDJdptPPOCscO
AFs5bkvXmYaSRjMZPd+UUHQS3mFfMvzJav6MoASvzt4FQguTpQAaFPJotQk6KrGt
jJ5LW9CJaozt1NopB4kLWe6n+GYq4Hgogqa6pXno1omEj78VvQAow/2wfM0oo5n2
24kXMiW0USHSu0vOtytrAUo3A/Fvqj79DnYhUGCpBV3zvfvgcnCynD8Q3eZomqv5
copImS212Ds19WCNm4l8DM4Pqkjt/B9FUQrWat2vHotwGwi7s0rfejSML3nhl4eW
OYGYjwO5htBedfHFfqfhanHMHOZ7D5R5CVibtWqnRS7hiNHGDByhrJ7c8caBgv9g
GaU9QZMvoTpD34k/GNFBKvvnYi0KtnH6c7ZQRzIPaCgY1rsHoF6PMcE9sXTqxWP8
kev6S0XVqhZxM2OT0/msiP/iTVXbx7+gGWwERJHKf4kpcderZyN774zOx7rya1gK
h2XbjkWUfw3o4Q8i9eNAJyPvXnyZlV01oXS09fRsfy1LTd3a55oG6cPGSBlw+uzp
n2W4zDMESWyRHcsnQgggUXhTyMvvGazxM9m/7HWOc4V7J3kO24ZShE7AZp19z3Tb
7Fa5h8VWaOFB1gQTvGZj1mwf5DlL8zcvbXs+T7OoyvFcOAzZx5qGL6n0z95nrzLW
3MXHCKa5CRxW
=QL8q
-END PGP SIGNATURE-

Bug#1006007:

[Vincent Bernat]

 ❦ 19 February 2022 10:02 -03, Andreas Hasenack:

> Salsa PR at https://salsa.debian.org/haproxy-team/haproxy/-/merge_requests/7
> with the upstream patch that ubuntu has been carrying.

I have asked upstream about guidance on this. It seems that despite
compiling, there are regressions during integration tests.
-- 
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#1003108: Dependency on python3-cachecontrol has an odd alternative

[Vincent Bernat]

Package: python3-poetry
Version: 1.1.12+dfsg-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

python3-cachecontrol (>= 0.12.6) | python3 (>> 3.6)

So, python3-cachecontrol don't get installed. Dunno who is generating
this dependency. Checked cachecontrol repository, but nothing odd
here. And in dh-python, nothing odd here either.


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/12 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-poetry depends on:
ii  python3 3.9.8-1
ii  python3-cachy   0.3.0-4
ii  python3-cleo0.8.1-2
ii  python3-clikit  0.6.2-3
ii  python3-html5lib1.1-3
ii  python3-importlib-metadata  4.6.4-1
ii  python3-lockfile1:0.12.2-2.2
ii  python3-packaging   21.3-1
ii  python3-pexpect 4.8.0-2
ii  python3-pkginfo 1.8.2-1
ii  python3-poetry-core 1.0.7-2
ii  python3-requests2.25.1+dfsg-2
ii  python3-requests-toolbelt   0.9.1-1
ii  python3-shellingham 1.3.2-1.1
ii  python3-tomlkit 0.8.0-1
ii  python3-virtualenv  20.12.1+ds-1

python3-poetry recommends no packages.

python3-poetry suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmHUC/MSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5wxAP/ifdRGmBN7Uxwr5yB0GT9zBXNl2jOk7l
8IUyaG7jkbIHggLaxTo7hG65uOfLn7v0EF8iEHv+iV68lbPeN7anbjVdZgoRno/K
81XfA+KPlkNgMbT2AcLKizxCbYGHSqqBNTFe3sIaDwoEKdwxcB5EEejbc67s2KJf
32lOUXgmHvS+oA+jZ2YOSBuf0qK1G6ET/8tBDWUg02gnlsE4KQnQUNvA1pKrl5LX
+3P1cYKGrQXuxnayMGWZJ4xlbS4QdWLspQmiIbFENxyT594mDF2pnl96EMKNkde3
hnhFu4I2Hz3Q0IUteFPiAOv4ADREwzgSVUXJ0LsTUIkwJjN5t46h1tAKcdxhsYSl
O0CBxIAFvTK/BWPeLth11zOqzR2XYeUOVu3hidmg7pzBEVpvNk1VP9pxdXBve315
dEEsEz6EW10QrMBkC3GbR4vLVb+Z2z79O1NXL7/+Shxq6843LMy8wlgSLd4KW26m
vZP32DACnnORWAmACU6xOM4lmZPP7c0PUN4yZcIcB42HWHRUuRb8KFfguvvwLYzD
n72kbABEgQijWCGyL81XF2r7I35FZjebX3B5xJAL9Nu/x0CDZgzaJOoKrmebmXdy
qmVYm1/mZ8UlXdvUTl3nLCTw9RFr98sM07R4zh1r8qQFJEhhihk+saNLoasOxxOJ
WhvF48J+K10+
=+gUh
-END PGP SIGNATURE-

Bug#965696: libwhisker2-perl: diff for NMU version 2.5-1.2

[Vincent Bernat]

Thanks! If you want to take over this package, be my guest!

On January 1, 2022 6:35:04 PM GMT+01:00, gregor herrmann  
wrote:
>Control: tags 965696 + patch
>Control: tags 965696 + pending
>Control: tags 999044 + patch
>Control: tags 999044 + pending
>
>
>Dear maintainer,
>
>I've prepared an NMU for libwhisker2-perl (versioned as 2.5-1.2) and
>uploaded it to DELAYED/5. Please feel free to tell me if I
>should delay it longer.
>
>Regards.
>
>
>-- 
> .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
> : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
> `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
>   `-   

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#998242: cron-failure@.service delivery fails due to DynamicUser with exim

[Vincent Bernat]

Control: forwarded -1 https://github.com/systemd-cron/systemd-cron/issues/75

 ❦ 21 December 2021 21:14 +01, Vincent Bernat:

> I have the same issue with Postfix.

This is a problem known upstream. DynamicUser= implies NoNewPrivileges=.

https://github.com/systemd-cron/systemd-cron/issues/75
-- 
To be or not to be.
-- Shakespeare
To do is to be.
-- Nietzsche
To be is to do.
-- Sartre
Do be do be do.
-- Sinatra

Bug#995212: ungoogled-chromium? [

[Vincent Bernat]

 ❦ 14 December 2021 09:13 GMT, Jeff Blake:

> Unless there are licensing or technical objections, I would suggest building 
> with upstream 
> bundled clang to avoid all sorts of incompatibilities and obviate the need 
> for extra patching 
> (stable's clang is often too old and upstream currently uses clang-14 vs 
> unstable's 13). 
> As an added bonus, this is a prerequisite to, and allows building with PGO 
> enabled. Refer to 
> my rules file to see how download of upstream clang/llvm binaries can
> be automated [6].

Unfortunately, packages are not allowed to fetch external stuff during
build. You'll need to vendor clang, either directly in the source
tarball or as an additional tarball.

I just cite this part, but I agree with everything else you said.

> Finally, it's good to see some of the maintainability issues being
> discussed, as when debian chromium development was restarted a year or
> so ago, I became frustrated when my questions on the issue went
> unanswered. So many patches seemed to be superfluous, yet nobody
> seemed to have the motivation, authority or courage to delete them.

The situation didn't change that much. When a maintainer is inactive, it
is always a bit difficult to know how to move forward. The issue has now
gotten a bit more light, but it is still unclear on how to proceed. I
don't think we had a similar case in the past (pretty popular package,
totally unable to push security fixes). It is a pity the package got an
exception to go in Bullseye while it was pretty clear we would get into
this situation.
-- 
As flies to wanton boys are we to the gods; they kill us for their sport.
-- Shakespeare, "King Lear"

Bug#998242: cron-failure@.service delivery fails due to DynamicUser with exim

[Vincent Bernat]

 ❦  1 November 2021 14:27 +01, Yuri D'Elia:

> cron-failure@ is using DynamicUser=yes, however this causes a silent
> delivery failure when using exim4:
>
> systemd[1]: Starting cron-failure@cron-monthly.service...
> mail_on_failure[328561]: 2021-11-01 14:11:23 1mhX5v-001NTN-LU Failed
> to create spool file /var/spool/exim4//input//1mhX5v-001NTN-LU-D:
> Permission denied
> mail_on_failure[328561]: 2021-11-01 14:11:23 1mhX5v-001NTN-LU Failed
> to create spool file /var/spool/exim4//input//1mhX5v-001NTN-LU-D:
> Permission denied
> mail_on_failure[328561]: 2021-11-01 14:11:23 1mhX5v-001NTN-LU Failed
> to create spool file /var/spool/exim4//input//1mhX5v-001NTN-LU-D:
> Permission denied
> systemd[1]: cron-failure@cron-monthly.service: Deactivated successfully.
> systemd[1]: Finished cron-failure@cron-monthly.service.

I have the same issue with Postfix.

Dec 21 21:02:53 neo mail_on_failure[938987]: postdrop: warning: 
mail_queue_enter: create file maildrop/155101.938987: Permission denied
Dec 21 21:02:53 neo postfix/postdrop[938987]: warning: mail_queue_enter: create 
file maildrop/155101.938987: Permission denied
Dec 21 21:03:03 neo mail_on_failure[938987]: postdrop: warning: 
mail_queue_enter: create file maildrop/155516.938987: Permission denied
Dec 21 21:03:03 neo postfix/postdrop[938987]: warning: mail_queue_enter: create 
file maildrop/155516.938987: Permission denied

However, I don't know how it should work. Permissions for maildrop is:

 21:03 ❱ ls -ltrd /var/spool/postfix/maildrop
drwx-wx--T 2 postfix postdrop 4096 Dec 21 20:05 /var/spool/postfix/maildrop

With `T`, I am unable to create a file either:

 21:05 ❱ touch /var/spool/postfix/maildrop/titi
touch: cannot touch '/var/spool/postfix/maildrop/titi': Permission denied

I suppose only postdrop can write here:

 21:08 ❱ ls -ltrhA =postdrop
-r-xr-sr-x 1 root postdrop 19K Nov 13 22:05 /usr/sbin/postdrop

However, for some reason, the process is not part of the postdrop group:

 21:09 ❱ ls -ltrhAd /proc/938987
dr-xr-xr-x 9 cron-failure systemd-journal 0 Dec 13 07:19 /proc/938987

 21:11 ❱ systemctl cat cron-failure@cron-root-root-0.service
# /lib/systemd/system/cron-failure@.service
[Unit]
Description=systemd-cron OnFailure for %i
Documentation=man:systemd.cron(7)
RefuseManualStart=true
RefuseManualStop=true
ConditionFileIsExecutable=/usr/sbin/sendmail

[Service]
Type=oneshot
ExecStart=/lib/systemd-cron/mail_on_failure %i
DynamicUser=yes
Group=systemd-journal

 21:13 ❱ cat /proc/938987/status | grep Cap
CapInh: 
CapPrm: 
CapEff: 
CapBnd: 01ff
CapAmb: 

 21:13 ❱ capsh --decode=01ff | grep setgid
0x01ff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore

So, process should be able to change group.

-- 
This night methinks is but the daylight sick.
-- William Shakespeare, "The Merchant of Venice"

Bug#996165: firmware-sof-signed: sound/mic also does not work on Dell Precision 5760

[Vincent Bernat]

 ❦ 17 December 2021 17:55 +01, Dirk Kostrewa:

> I have also tried before the 5.14 kernel from the Bullseye backports
> repository (with firmware-sof-signed 1.7.1), which also didn't work. I 
> would be grateful for any other suggestion!

No idea. You should try to ask upstream: https://github.com/thesofproject/sof
-- 
Make input easy to prepare and output self-explanatory.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#996165: firmware-sof-signed: sound/mic also does not work on Dell Precision 5760

[Vincent Bernat]

 ❦ 17 December 2021 10:19 +01, Dirk Kostrewa:

> 00:1f.3 Multimedia audio controller [0401]: Intel Corporation Device
> [8086:43c8] (rev 11)
>     Subsystem: Dell Device [1028:0a5e]
>     Flags: bus master, fast devsel, latency 64, IRQ 16, IOMMU group 17
>     Memory at 618d1d8000 (64-bit, non-prefetchable) [size=16K]
>     Memory at 618d00 (64-bit, non-prefetchable) [size=1M]
>     Capabilities: [50] Power Management version 3
>     Capabilities: [80] Vendor Specific Information: Len=14 
>     Capabilities: [60] MSI: Enable- Count=1/1 Maskable- 64bit+
>     Kernel driver in use: sof-audio-pci
>     Kernel modules: snd_hda_intel, snd_sof_pci
>
> Could you please check this?
>
> I would be happy to provide any information that you need to address
> this issue!

You can try with a more recent version to see if it fixes your issue:
https://packages.debian.org/sid/all/firmware-sof-signed/download
-- 
After all, all he did was string together a lot of old, well-known quotations.
-- H. L. Mencken, on Shakespeare

Bug#1001507: RFS: dwm/6.2-1 [ITA] -- dynamic window manager

[Vincent Bernat]

 ❦ 11 December 2021 10:43 GMT, Matteo Bini:

>* New maintainer

Is there some agreement with the original maintainer?

>* New upstream release.

You can close #978687 and #945281.
-- 
Debian package sponsoring guidelines:
 https://vincent.bernat.ch/en/debian-package-sponsoring

Bug#1001474: bullseye-pu: package bpftrace/0.11.3-5

[Vincent Bernat]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

[ Reason ]
Array indexing is broken, making bpftrace unable to complete its task on some 
scripts.

[ Impact ]
Some scripts cannot work.

[ Tests ]
Tested with this script:

#!/usr/bin/env bpftrace
#include 
#include 
kprobe:tcp_connect
{
 $sk = ((struct sock *) arg0);
 if ($sk->__sk_common.skc_family == AF_INET6) {
 $d0 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[0];
 $d1 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[1];
 $d2 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[2];
 $d3 = $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr32[3];
 printf("%X %X %X %X\n", $d0, $d1, $d2, $d3);
 }
}
[ Risks ]
Code is trivial. Patch is from upstream.

[ 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 ]
Upstream patch to fix the issue.

[ Other info ]

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmGzmqISHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5N/QP/ibBMh/2uaCW0gsYOeb7brdwNEBuclMW
r7NQhJx10Q/f5tonj1NizPu94oeEOh4W6GpmZ4tMmQSi7k2Hr9Ny3r+mqwSjGTEZ
R5xK8gHV1WSoVCXCXa9xu3XdXaeZhG545g9cnAIxkCRp6ZOcI6MqDZ6A+xEExTz2
y5bF9ezhPDRjbhMFiuhhZ9lwIBSuINwm0osgEsrwxpRz96TnLQG2rPS52UUTYCiO
6Tpd4aJdCLTgw969H2//tb1PuODq0//KFndDWhtZcN88ahvH1QYk9Tlf7HrtQ5qy
LrkAQe5puu5q5+S54OdvGhcEINclgsdZ52tqF///nHm1Q+IghimlSjsNZAQh9CaI
wh3PhTKtFUj5zHWQKFwgLV/41p6Cg8SYTlQp9trT1tS8J9eELJQDzoHEBFl6iJer
HtOFSazwIkHlFqFsrmZ+mIZ0mpmlKRBQmLwP4dURV+4skFbIT4tx1g4TrZeK0Erg
dEOZQ8BP3pTjSXT1GqHpnif6NiiLGre0FTmqEVT3XrgFPoR5jrECxn7PzAKAxuCP
Ulx3pTpsock1jS/LSAbPoyUTOo2skm39tC9zOuixLQuLy81NVMIUr2SQQctLiLAk
/avo0leQDqZihJY2Di7idvm9El/VbHq80SYi2ddMsD8WeFvIU77xwrP1azlnjkhg
hdP5YokOmKBt
=pJ4O
-END PGP SIGNATURE-
>From b06bd9dfd60e58f6c5164fd283cb19801513fb09 Mon Sep 17 00:00:00 2001
From: Vincent Bernat 
Date: Fri, 10 Dec 2021 19:16:23 +0100
Subject: [PATCH] d/patches: add patch to fix array indexing

---
 debian/changelog  |  6 ++
 debian/patches/1457.patch | 27 +++
 debian/patches/series |  1 +
 3 files changed, 34 insertions(+)
 create mode 100644 debian/patches/1457.patch

diff --git a/debian/changelog b/debian/changelog
index e22c1cc4b4a8..e138bfe58331 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+bpftrace (0.11.3-5+deb11u1) bullseye; urgency=medium
+
+  * d/patches: add patch to fix array indexing (Closes: #1001449).
+
+ -- Vincent Bernat   Fri, 10 Dec 2021 19:16:15 +0100
+
 bpftrace (0.11.3-5) unstable; urgency=medium
 
   * d/control: do not build-depends on libbfd-dev (Closes: #980438)
diff --git a/debian/patches/1457.patch b/debian/patches/1457.patch
new file mode 100644
index ..d572df0e39fa
--- /dev/null
+++ b/debian/patches/1457.patch
@@ -0,0 +1,27 @@
+From 21e9a7292240e1aa7a2809dedb37347104085dc1 Mon Sep 17 00:00:00 2001
+From: Daniel Xu 
+Date: Thu, 6 Aug 2020 08:51:44 -0700
+Subject: [PATCH] Fix array indexing regression
+
+We regressed on array indexing because the CreateArray() helper forgot
+to set pointee_size. This caused all array indexes to silently index to
+index 0.
+---
+ CHANGELOG.md  | 2 ++
+ src/ast/semantic_analyser.cpp | 3 ++-
+ src/types.cpp | 1 +
+ tests/runtime/regression  | 5 +
+ 4 files changed, 10 insertions(+), 1 deletion(-)
+
+diff --git a/src/types.cpp b/src/types.cpp
+index bc0be7d912..14fff5f64a 100644
+--- a/src/types.cpp
 b/src/types.cpp
+@@ -280,6 +280,7 @@ SizedType CreateArray(size_t num_elements, const SizedType 
&element_type)
+   auto ty = SizedType(Type::array, num_elements);
+   ty.num_elements_ = num_elements;
+   ty.element_type_ = new SizedType(element_type);
++  ty.pointee_size = element_type.size;
+   return ty;
+ }
+ 
diff --git a/debian/patches/series b/debian/patches/series
index d01dae2643d1..d6e04b4626c3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 0001-Ensure-symbols-are-exported-for-bpftrace-executable.patch
+1457.patch
-- 
2.34.1

Bug#1001449: array indexing broken

[Vincent Bernat]

 ❦ 10 December 2021 10:40 +01, Julian Taylor:

> This has been fixed upstream with this patch:
> https://github.com/iovisor/bpftrace/pull/1457

I'll try to push the update for the next point release (Dec 18).
-- 
The last thing one knows in constructing a work is what to put first.
-- Blaise Pascal

Bug#999673: bullseye-pu: package lldpd/1.0.11-1

[Vincent Bernat]

 ❦ 29 November 2021 17:32 GMT, Adam D. Barratt:

>> > What you've uploaded to bullseye is *not* what you proposed in this
>> > request, however.
>> > 
>> > The debdiff attached to this bug report amounts to "4 files
>> > changed,
>> > 130 insertions(+)", the uploaded package is "39 files changed, 561
>> > insertions(+), 221 deletions(-)" and includes a new upstream
>> > release.
>> 
>> Ugh. Very sorry about that!
>> 
>> Here is the appropriate diff. How can I sort out my bad upload?
>> Bumping the version number? I hold uploading anything else until you
>> approve.
>
> Ah, I see the confusion - you used the wrong base upload when
> generating the first diff. As that resulted in an upload of 1.0.12-
> 1+deb11u1 and the fixed package will be 1.0.11-1+deb11u1, they can co-
> exist in the processing queue - free to upload the new diff and we will
> deal with rejecting the larger diff.

Thanks! Done.
-- 
"... all the modern inconveniences ..."
-- Mark Twain

Bug#977738: rofi: New upstream release 1.6.1

[Vincent Bernat]

 ❦  9 September 2021 09:04 +02, Vincent Bernat:

>> https://github.com/davatorium/rofi/releases/tag/1.6.1
>>
>> Version 1.6.0 is very interesting because it adds a new [1]script mode
>> that allows more powerful selectors.
>>
>> I tried to build the package using the current [2]debian directory for
>> the package in Sid and it seems to work with no changes.
>>
>> 1. https://github.com/davatorium/rofi/blob/next/doc/rofi-script.5.markdown
>> 2. https://deb.debian.org/debian/pool/main/r/rofi/rofi_1.5.4-1.debian.tar.xz
>
> I am also interested by updating Rofi in Debian. Jason, do you plan to
> continue working on Rofi? I can sponsor the uploads if needed.

I have uploaded 1.7.1 in DELAYED/10 queue. Attached is the diff.

diff -Nru rofi-1.5.4/debian/changelog rofi-1.7.1/debian/changelog
--- rofi-1.5.4/debian/changelog	2021-09-14 20:17:12.0 +0200
+++ rofi-1.7.1/debian/changelog	2021-11-28 14:15:52.0 +0100
@@ -1,3 +1,15 @@
+rofi (1.7.1-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream release. Closes: #977738.
+  * d/patches: remove patch to fix autoconf 2.70 compatibility.
+  * d/control: add libxcb-cursor-dev as a build-depedency.
+  * d/control: remove libxcb-xrm (not needed anymore).
+  * d/control: replace librsvg2-dev with gdk-pixbuf.
+  * d/docs: remove (no more README.md).
+
+ -- Vincent Bernat   Sun, 28 Nov 2021 14:15:52 +0100
+
 rofi (1.5.4-1.1) unstable; urgency=high
 
   * Non-maintainer upload.
diff -Nru rofi-1.5.4/debian/control rofi-1.7.1/debian/control
--- rofi-1.5.4/debian/control	2021-09-14 19:55:52.0 +0200
+++ rofi-1.7.1/debian/control	2021-11-28 14:15:52.0 +0100
@@ -7,18 +7,18 @@
bison,
flex,
libpango1.0-dev,
+   libgdk-pixbuf-2.0-dev,
libstartup-notification0-dev,
libxkbcommon-dev (>= 0.5.0),
libxkbcommon-x11-dev (>= 0.5.0),
libxcb1-dev,
-   libxcb-xkb-dev,
-   libxcb-xinerama0-dev,
+   libxcb-cursor-dev,
libxcb-ewmh-dev,
libxcb-icccm4-dev,
libxcb-randr0-dev,
libxcb-util0-dev,
-   librsvg2-dev,
-   libxcb-xrm-dev
+   libxcb-xinerama0-dev,
+   libxcb-xkb-dev
 Standards-Version: 4.4.0
 Homepage: https://github.com/DaveDavenport/rofi/
 Vcs-Git: https://salsa.debian.org/jpleau-guest/rofi
diff -Nru rofi-1.5.4/debian/patches/0001-fix-autoconf-2.70-compat.patch rofi-1.7.1/debian/patches/0001-fix-autoconf-2.70-compat.patch
--- rofi-1.5.4/debian/patches/0001-fix-autoconf-2.70-compat.patch	2021-09-14 20:17:02.0 +0200
+++ rofi-1.7.1/debian/patches/0001-fix-autoconf-2.70-compat.patch	1970-01-01 01:00:00.0 +0100
@@ -1,24 +0,0 @@
-From: Boyuan Yang 
-Date: Tue, 14 Sep 2021 14:12:35 -0400
-Subject: fix autoconf 2.70 compat
-
-* Use no argument AC_PROG_LEX
-
-Bug-Debian: https://bugs.debian.org/978898

- configure.ac | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/configure.ac b/configure.ac
-index 533b99d..d4b7c59 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -7,7 +7,7 @@ AH_BOTTOM([#include "gitconfig.h"])
- dnl -
- dnl Lex & Bison language parser.
- dnl -
--AC_PROG_LEX([flex])
-+AC_PROG_LEX
- AC_PROG_YACC
- 
- AS_IF([test "x${YACC}" != "xbison -y" ], [AC_MSG_ERROR( "Failed to find bison")])
diff -Nru rofi-1.5.4/debian/patches/series rofi-1.7.1/debian/patches/series
--- rofi-1.5.4/debian/patches/series	2021-09-14 20:13:04.0 +0200
+++ rofi-1.7.1/debian/patches/series	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-0001-fix-autoconf-2.70-compat.patch
diff -Nru rofi-1.5.4/debian/rofi.docs rofi-1.7.1/debian/rofi.docs
--- rofi-1.5.4/debian/rofi.docs	2021-09-14 19:55:52.0 +0200
+++ rofi-1.7.1/debian/rofi.docs	1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-README.md

-- 
In the first place, God made idiots; this was for practice; then he made
school boards.
-- Mark Twain

Bug#999673: bullseye-pu: package lldpd/1.0.11-1

[Vincent Bernat]

 ❦ 27 November 2021 17:43 GMT, Adam D. Barratt:

>> > Package: release.debian.org
>> > Severity: normal
>> > Tags: bullseye
>> > User: release.debian@packages.debian.org
>> > Usertags: pu
>> [...]
>> 
>> I did the upload to bullseye as I think the change is not
>> controversial.
>
> What you've uploaded to bullseye is *not* what you proposed in this
> request, however.
>
> The debdiff attached to this bug report amounts to "4 files changed,
> 130 insertions(+)", the uploaded package is "39 files changed, 561
> insertions(+), 221 deletions(-)" and includes a new upstream release.

Ugh. Very sorry about that!

Here is the appropriate diff. How can I sort out my bad upload? Bumping
the version number? I hold uploading anything else until you approve.

>From a5a413c1f44bb0a063fc9ca4cf56ae7137f53f3d Mon Sep 17 00:00:00 2001
From: Vincent Bernat 
Date: Sun, 14 Nov 2021 15:42:12 +0100
Subject: [PATCH] Tentative security update for Bullseye

---
 debian/changelog  |  8 ++
 ...et-VLAN-tag-if-client-did-not-set-it.patch | 27 ++
 ...-overflow-when-reading-SONMP-packets.patch | 93 +++
 debian/patches/series |  2 +
 4 files changed, 130 insertions(+)
 create mode 100644 debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
 create mode 100644 debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch

diff --git a/debian/changelog b/debian/changelog
index 4fc8b730cc52..6da569249198 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+lldpd (1.0.11-1+deb11u1) bullseye; urgency=high
+
+  * d/patches: sonmp: fix heap overflow when reading SONMP packets.
+CVE-2021-43612
+  * d/patches: client: do not set VLAN tag if client did not set it
+
+ -- Vincent Bernat   Sat, 27 Nov 2021 23:30:43 +0100
+
 lldpd (1.0.11-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch b/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
new file mode 100644
index ..1f65986ae27e
--- /dev/null
+++ b/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
@@ -0,0 +1,27 @@
+From 261afbe371ab316a4bf710338f6d9183a01e083f Mon Sep 17 00:00:00 2001
+From: Vincent Bernat 
+Date: Wed, 29 Sep 2021 12:02:15 +0200
+Subject: [PATCH] client: do not set VLAN tag if client did not set it
+
+This fixes a bug where frames could be tagged with VLAN 0 after client
+configuration.
+---
+ src/daemon/client.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/daemon/client.c b/src/daemon/client.c
+index b4a08aae80a8..0d0f3ea37a19 100644
+--- a/src/daemon/client.c
 b/src/daemon/client.c
+@@ -390,7 +390,7 @@ _client_handle_set_port(struct lldpd *cfg,
+ 		port->p_disable_rx = port->p_disable_tx = 1;
+ 		break;
+ 	}
+-	if (set->vlan_tx_enabled >= -1) {
++	if (set->vlan_tx_enabled > -1) {
+ 		port->p_vlan_tx_enabled = set->vlan_tx_enabled;
+ 		port->p_vlan_tx_tag = set->vlan_tx_tag;
+ 	}
+-- 
+2.33.1
+
diff --git a/debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch b/debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch
new file mode 100644
index ..c06689987c34
--- /dev/null
+++ b/debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch
@@ -0,0 +1,93 @@
+From 73d42680fce8598324364dbb31b9bc3b8320adf7 Mon Sep 17 00:00:00 2001
+From: Vincent Bernat 
+Date: Sun, 19 Sep 2021 21:18:47 +0200
+Subject: [PATCH] sonmp: fix heap overflow when reading SONMP packets
+
+By sending short SONMP packets, an attacker can make the decoder crash
+by reading too much data on the heap. SONMP packets are fixed in size,
+just ensure we get the enough bytes to contain a SONMP packet.
+
+CVE-2021-43612
+---
+ NEWS |  2 ++
+ src/daemon/protocols/sonmp.c |  2 +-
+ src/daemon/protocols/sonmp.h |  2 +-
+ tests/check_sonmp.c  | 10 +-
+ 4 files changed, 9 insertions(+), 7 deletions(-)
+
+diff --git a/src/daemon/protocols/sonmp.c b/src/daemon/protocols/sonmp.c
+index 41dcf6aa412d..f8f12469e28a 100644
+--- a/src/daemon/protocols/sonmp.c
 b/src/daemon/protocols/sonmp.c
+@@ -311,7 +311,7 @@ sonmp_decode(struct lldpd *cfg, char *frame, int s,
+ 
+ 	length = s;
+ 	pos = (u_int8_t*)frame;
+-	if (length < SONMP_SIZE) {
++	if (length < SONMP_SIZE + 2*ETHER_ADDR_LEN + sizeof(u_int16_t)) {
+ 		log_warnx("sonmp", "too short SONMP frame received on %s", hardware->h_ifname);
+ 		goto malformed;
+ 	}
+diff --git a/src/daemon/protocols/sonmp.h b/src/daemon/protocols/sonmp.h
+index 0e60106dae63..ff7a720f0b5d 100644
+--- a/src/daemon/protocols/sonmp.h
 b/src/daemon/protocols/sonmp.h
+@@ -24,7 +24,7 @@
+ 

Bug#1000707: bullseye-pu: package keepalived/1:2.1.5-0.2

[Vincent Bernat]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

[ Reason ]
Keepalived ships a DBus policy allowing anyone to access and write any
properties. We want to restrict this policy to only impact the
properties owned by Keepalived.

[ Impact ]
Any user can read any DBus property and write any writable property.

[ Tests ]
Tested manually with:

dbus-send --print-reply --system --dest=org.freedesktop.nm_dispatcher \
/ org.freedesktop.DBus.Properties.Set \
string:com.example.Nope string:Nope variant:string:foo

Thanks to Simon McVittie for its help on this.

[ Risks ]
Very low. I think most people don't enable DBus support, so we are
unlikely to break anything.

[ 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 ]
Restrict allowed properties to org.keepalived.Vrrp1 destination.

[ Other info ]
- - Real impact seems small as most properties are already readable and
  are not writable.
- - Security team is OK to use a point release to fix this.

9b4813899b1b

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmGiR6sSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5S/gP/ipz9T9W02SEl2QOVw3falS9pQx4JUaV
NYbwqbd+nocTjRTjk093QbtpfsGIxldwOBNy5cdZhEBQr+v4P+sj6zzBnP5s75mG
foWBRviSQhD3XvwS9kZ5+4yhULdhv9iiSJE22nDmIRCOQ/zYvxeoaMxbjSoEetvE
4CzSNtVXP3uPmC+/FmdmdyoYxtbZTgnSkBv5bNNHtpMt9bl3jjRlLTx9vp1gbkzg
nJUulyvv63wIm6pAiKbjrvW0gwutKlvlfNchlREgS4k8kAvuT/nUsZnsoMYw6m/B
B8aR8z2HRTUYI/PmIqOG+UXvnL5M69SR5EB3bTGJfhgPhjDVG/M5yIdbBBBYHRdH
4/F42o5krlMPHSc96LRhaX8E1H5xcIGh3rwRq7EvP9i5C5O6Ox9cSRj+9kindvkR
hBbjtdqXu4idmf9+unSk/NN+I2T+lOLKWeqhF00Wu8TtD9+JIEJbLnqcBoXc9QC7
d6qG3fuqKPyqrplliYgMEWb/GzQXvFnwx+JleBwFZ0nXXl5lGOLzOAVliYDowkZv
a0w3qmdC0o46QfLzilGBPbFRLuoGCJ1ptQO9p/cK3esYEkxwicxgkhsAoSFqaWLT
tvSt2KC9nC6FmuBpLrhUwK63zZOanHFwuTkVqsP+vQu+uHnDpnxaT4kvo78ckdhX
e3DXALjBZLhd
=uiHe
-END PGP SIGNATURE-
>From 9b4813899b1bd0ba9b719f458d794534e9989d22 Mon Sep 17 00:00:00 2001
From: Vincent Bernat 
Date: Sat, 27 Nov 2021 15:53:33 +0100
Subject: [PATCH] Fix shipped too broad DBus policy. CVE-2021-44225

---
 debian/changelog  |  6 ++
 debian/patches/2063.patch | 38 ++
 debian/patches/series |  1 +
 3 files changed, 45 insertions(+)
 create mode 100644 debian/patches/2063.patch

diff --git a/debian/changelog b/debian/changelog
index 51ee7b25efc1..2491770e8103 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+keepalived (1:2.1.5-0.2+deb11u1) bullseye; urgency=medium
+
+  * Fix shipped too broad DBus policy. CVE-2021-44225.
+
+ -- Vincent Bernat   Sat, 27 Nov 2021 15:51:39 +0100
+
 keepalived (1:2.1.5-0.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/patches/2063.patch b/debian/patches/2063.patch
new file mode 100644
index ..ea9d40ec2115
--- /dev/null
+++ b/debian/patches/2063.patch
@@ -0,0 +1,38 @@
+From 7977fec0be89ae6fe87405b3f8da2f0b5e415e3d Mon Sep 17 00:00:00 2001
+From: Vincent Bernat 
+Date: Tue, 23 Nov 2021 06:50:59 +0100
+Subject: [PATCH] dbus: fix policy to not be overly broad
+
+The DBus policy did not restrict the message destination, allowing any
+user to inspect and manipulate any property.
+
+Signed-off-by: Vincent Bernat 
+---
+ keepalived/dbus/org.keepalived.Vrrp1.conf | 13 -
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+diff --git a/keepalived/dbus/org.keepalived.Vrrp1.conf 
b/keepalived/dbus/org.keepalived.Vrrp1.conf
+index 2b78a575c..b5ced6085 100644
+--- a/keepalived/dbus/org.keepalived.Vrrp1.conf
 b/keepalived/dbus/org.keepalived.Vrrp1.conf
+@@ -3,12 +3,15 @@
+  "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";>
+ 
+   
+-  
+-  
++  
++  
+   
+   
+-  
+-  
+-  
++  
++  
++  
+   
+ 
diff --git a/debian/patches/series b/debian/patches/series
index e69de29bb2d1..c6683cd1715d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -0,0 +1 @@
+2063.patch
-- 
2.34.0

Bug#999673: bullseye-pu: package lldpd/1.0.11-1

[Vincent Bernat]

 ❦ 14 November 2021 19:21 +01, Vincent Bernat:

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

I did the upload to bullseye as I think the change is not controversial.
-- 
The lunatic, the lover, and the poet,
Are of imagination all compact...
-- Wm. Shakespeare, "A Midsummer Night's Dream"

Bug#995817: ERROR: Could not resolve symbol: /proc/self/exe:BEGIN_trigger

[Vincent Bernat]

 ❦ 15 November 2021 07:51 +01, Salvatore Bonaccorso:

>> I have tried to just not strip the binary, but this produces a quite
>> huge binary. I didn't get time to investigate much yet.
>
> Asked a bit around, and got the following hint from Niels Thykier:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595810#10
>
> so that might work, first exclude with -X in dh_strip and then call
> strip manually, keeping BEGIN_trigger and END_trigger.
>
> Niels, thanks for the pointer!

Thanks! It works. I have uploaded the new version to unstable.
-- 
Make the coupling between modules visible.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#999673: bullseye-pu: package lldpd/1.0.11-1

[Vincent Bernat]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

[ Reason ]

- - Low-severity security issue when receiving SONMP packets.
  CVE-2021-43612

- - Annoying bug where LLDP packets are encapsulated in VLAN 0 when some
  configuration directives are used. Many implementations reject such
  a packet (regression introduced in 1.0.6)

[ Impact ]

- - Someone could crash lldpd from another neighbor if the user enables
  SONMP (quite unlikely).

- - People cannot use some configuration directives.

[ Tests ]

- - Both codes are covered by tests in upstream. The SONMP tests are run
  during build as well. The VLAN 0 test is not run during build.

[ Risks ]

- - For SONMP, low risk as it is seldomly used and correctly formed
  packets are part of the tests run during build.

- - For VLAN 0, the change is trivial, tested upstream and reported OK by two 
users.

[ 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 ]

- - SONMP: there was a confusion about the size of a packet. The same
  variable was used for the payload size and for checking the size
  with Ethernet headers.

- - VLAN 0: when changing some settings, a struct containing the changed
  settings is transmitted. -1 was used to say "no change" but it was
  interpreted as a change.

[ Other info ]

- - Security team is OK to fix the security issue in a point release.

- - I don't think this is worth fixing the SONMP issue in Buster, but I
  can do that too. The VLAN issue is not present.


-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmGRU44SHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5++gP/jK+rA7DgjxgweFrlUezPB39QSg6wcmu
9YrUO8wyjSzZ0A51Gfh/afyJAKRKehy3tD/nWvrQumn5ZkYXMhVbock5zJbgnTmo
1ndd2CtIOlpdSceqmnxX83Qt5qj7yHLWCzyAYg+ujgO1Su/IrE6GwwWr3+OBJQdN
lwLrbDzIe+Xv+4sYLLhWjO1ApVHpJmLJYYywBWug6YkTa9hx1wixPGm76G1Z4tvc
312L+9uwJqdp85Nb8w29VgBx8nDOWZS54FaimnggmGk895beQdI4wUCGfrJ/Tqkt
K4emDeOUv5pUudDYNU98a0byf7Ahif+QVZLS0w9p32uHd7qtr1ZwkmhcO2I0W0jA
EWIC7PW3qyQqa8SrD068Sx9jEhCt69uJaQyDUV38DbCmNFjip4oK607XeLuh/WwC
R6TI3iMro3T03QSzyYyFvWLJpL0n/xHtoMb0UXWY+KE38uOQQ1Fdv3JkvxxI6q6Z
8FhpTYr1ONE9uj577aMj3bX9BkxdVKKjy48bLEkHhTd1KS/FOLpWMmnlRVNBAr8t
KDn09xcsxU+anIGunFwrATqH8sBFOqO0gvr+ylgyswQiW3L8WWM2uyG1+UoO/AeW
lwMHk+6WUuejhB/7PzA0Wcv5zfgkwahZRf2zN6ohON6IaVR6Pbn0+lSYU5rlramB
dsd1jEbkXZ36
=W7Cl
-END PGP SIGNATURE-
>From d70b8be04c6d8638e6f2cd612a07e73992fa0798 Mon Sep 17 00:00:00 2001
From: Vincent Bernat 
Date: Sun, 14 Nov 2021 15:42:12 +0100
Subject: [PATCH] Tentative security update for Bullseye

---
 debian/changelog  |  8 ++
 ...et-VLAN-tag-if-client-did-not-set-it.patch | 27 ++
 ...-overflow-when-reading-SONMP-packets.patch | 93 +++
 debian/patches/series |  2 +
 4 files changed, 130 insertions(+)
 create mode 100644 
debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
 create mode 100644 
debian/patches/0001-sonmp-fix-heap-overflow-when-reading-SONMP-packets.patch

diff --git a/debian/changelog b/debian/changelog
index bb87d8129f9e..68ae7b91d22d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+lldpd (1.0.12-1+deb11u1) bullseye; urgency=high
+
+  * d/patches: sonmp: fix heap overflow when reading SONMP packets.
+CVE-2021-43612
+  * d/patches: client: do not set VLAN tag if client did not set it
+
+ -- Vincent Bernat   Sun, 14 Nov 2021 15:41:59 +0100
+
 lldpd (1.0.12-1) unstable; urgency=medium
 
   * New upstream release.
diff --git 
a/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch 
b/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
new file mode 100644
index ..1f65986ae27e
--- /dev/null
+++ 
b/debian/patches/0001-client-do-not-set-VLAN-tag-if-client-did-not-set-it.patch
@@ -0,0 +1,27 @@
+From 261afbe371ab316a4bf710338f6d9183a01e083f Mon Sep 17 00:00:00 2001
+From: Vincent Bernat 
+Date: Wed, 29 Sep 2021 12:02:15 +0200
+Subject: [PATCH] client: do not set VLAN tag if client did not set it
+
+This fixes a bug where frames could be tagged with VLAN 0 after client
+configuration.
+---
+ src/daemon/client.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/daemon/client.c b/src/daemon/client.c
+index b4a08aae80a8..0d0f3ea37a19 100644
+--- a/src/daemon/client.c
 b/src/daemon/client.c
+@@ -390,7 +390,7 @@ _client_handle_set_port(struct lldpd *cfg,
+   port->p_disable_rx = port->p_disable_tx = 1;
+   break;
+   }
+-  if (set->vlan_tx_enabled >= -1) {
++  if (set->vlan_tx_enabled > -1) {
+   port->p_vlan_tx_enabled = set->vlan_tx_enabled;

Bug#995817: ERROR: Could not resolve symbol: /proc/self/exe:BEGIN_trigger

[Vincent Bernat]

 ❦ 13 November 2021 15:06 +01, Salvatore Bonaccorso:

>> > In fact, it does not happen if you have debug symbols. My patch does not
>> > work anymore either and the previous upload did not fix this bug. Some
>> > distributions work around that by asking "strip" to keep BEGIN_trigger.
>> > It seems we cannot do that easily with dh_strip.
>> 
>> Confirmed!
>> 
>> No idea on the solution though.
>
> Any idea on how to bring that back?

I have tried to just not strip the binary, but this produces a quite
huge binary. I didn't get time to investigate much yet.
-- 
Why is it that we rejoice at a birth and grieve at a funeral?  It is because we
are not the person involved.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"

Bug#964934: cookiecutter: Upgrade to version 1.7.x

[Vincent Bernat]

 ❦ 12 November 2021 12:52 -04, Wesley Schwengle:

>>> In December 2019 version 1.7.0 was released and in April 2020 1.7.1 and
>>> 1.7.2 were released. It adds a very useful feature:
>>>
>>>https://cookiecutter.readthedocs.io/en/1.7.2/advanced/directories.html
>>>
>>> I would like to make use of this. Could you bump the version the debian
>>> unstable branch?
>> I am missing a recent enough version of python3-recommonmark due to
>> bug
>> #955180.
>
> It seems that bug has been resolved. Could you perhaps see if the
> version bump is now possible?

I have uploaded 1.7.3.
-- 
Modularise.  Use subroutines.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#997218: keepalived: FTBFS: if.h:44:5: error: redeclaration of enumerator ‘IFF_UP’

[Vincent Bernat]

 ❦ 23 October 2021 21:13 +02, Lucas Nussbaum:

> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This bug has been fixed in later versions. I have uploaded 2.2.4-0.1 to
DELAYED/10. Here is the diff compared to what is actually in master on
Salsa.

diff --git a/debian/changelog b/debian/changelog
index a11fb75cca2d..f9c585865a56 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,17 @@
-keepalived (1:2.2.1-1) UNRELEASED; urgency=medium
+keepalived (1:2.2.4-0.1) unstable; urgency=medium
 
+  [ Alexander Wirt ]
   * [61cbc18] New upstream version 2.2.1
   * [ecf662d] Keepalived has now support for systemd notify
 
- -- Alexander Wirt   Mon, 25 Jan 2021 09:04:08 +0100
+  [ Vincent Bernat ]
+  * Non-maintainer upload.
+  * New upstream version 2.2.4. Closes: #980563.
+- Fix FTFBS. Closes: #997218.
+  * d/rules: enable systemd as an init to get systemd features.
+  * d/rules: remove use of custom-specified include directory for kernel.
+
+ -- Vincent Bernat   Sun, 07 Nov 2021 17:57:44 +0100
 
 keepalived (1:2.1.5-0.2) unstable; urgency=medium
 
diff --git a/debian/include/linux/linux/ip_vs.h b/debian/include/linux/linux/ip_vs.h
deleted file mode 100644
index 4102ddcb4e14..
--- a/debian/include/linux/linux/ip_vs.h
+++ /dev/null
@@ -1,474 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- *  IP Virtual Server
- *  data structure and functionality definitions
- */
-
-#ifndef _IP_VS_H
-#define _IP_VS_H
-
-#include 	/* For __beXX types in userland */
-
-#define IP_VS_VERSION_CODE	0x010201
-#define NVERSION(version)			\
-	(version >> 16) & 0xFF,			\
-	(version >> 8) & 0xFF,			\
-	version & 0xFF
-
-/*
- *  Virtual Service Flags
- */
-#define IP_VS_SVC_F_PERSISTENT	0x0001		/* persistent port */
-#define IP_VS_SVC_F_HASHED	0x0002		/* hashed entry */
-#define IP_VS_SVC_F_ONEPACKET	0x0004		/* one-packet scheduling */
-#define IP_VS_SVC_F_SCHED1	0x0008		/* scheduler flag 1 */
-#define IP_VS_SVC_F_SCHED2	0x0010		/* scheduler flag 2 */
-#define IP_VS_SVC_F_SCHED3	0x0020		/* scheduler flag 3 */
-
-#define IP_VS_SVC_F_SCHED_SH_FALLBACK	IP_VS_SVC_F_SCHED1 /* SH fallback */
-#define IP_VS_SVC_F_SCHED_SH_PORT	IP_VS_SVC_F_SCHED2 /* SH use port */
-
-/*
- *  Destination Server Flags
- */
-#define IP_VS_DEST_F_AVAILABLE	0x0001		/* server is available */
-#define IP_VS_DEST_F_OVERLOAD	0x0002		/* server is overloaded */
-
-/*
- *  IPVS sync daemon states
- */
-#define IP_VS_STATE_NONE	0x		/* daemon is stopped */
-#define IP_VS_STATE_MASTER	0x0001		/* started as master */
-#define IP_VS_STATE_BACKUP	0x0002		/* started as backup */
-
-/*
- *  IPVS socket options
- */
-#define IP_VS_BASE_CTL		(64+1024+64)		/* base */
-
-#define IP_VS_SO_SET_NONE	IP_VS_BASE_CTL		/* just peek */
-#define IP_VS_SO_SET_INSERT	(IP_VS_BASE_CTL+1)
-#define IP_VS_SO_SET_ADD	(IP_VS_BASE_CTL+2)
-#define IP_VS_SO_SET_EDIT	(IP_VS_BASE_CTL+3)
-#define IP_VS_SO_SET_DEL	(IP_VS_BASE_CTL+4)
-#define IP_VS_SO_SET_FLUSH	(IP_VS_BASE_CTL+5)
-#define IP_VS_SO_SET_LIST	(IP_VS_BASE_CTL+6)
-#define IP_VS_SO_SET_ADDDEST	(IP_VS_BASE_CTL+7)
-#define IP_VS_SO_SET_DELDEST	(IP_VS_BASE_CTL+8)
-#define IP_VS_SO_SET_EDITDEST	(IP_VS_BASE_CTL+9)
-#define IP_VS_SO_SET_TIMEOUT	(IP_VS_BASE_CTL+10)
-#define IP_VS_SO_SET_STARTDAEMON (IP_VS_BASE_CTL+11)
-#define IP_VS_SO_SET_STOPDAEMON (IP_VS_BASE_CTL+12)
-#define IP_VS_SO_SET_RESTORE(IP_VS_BASE_CTL+13)
-#define IP_VS_SO_SET_SAVE   (IP_VS_BASE_CTL+14)
-#define IP_VS_SO_SET_ZERO	(IP_VS_BASE_CTL+15)
-#define IP_VS_SO_SET_MAX	IP_VS_SO_SET_ZERO
-
-#define IP_VS_SO_GET_VERSION	IP_VS_BASE_CTL
-#define IP_VS_SO_GET_INFO	(IP_VS_BASE_CTL+1)
-#define IP_VS_SO_GET_SERVICES	(IP_VS_BASE_CTL+2)
-#define IP_VS_SO_GET_SERVICE	(IP_VS_BASE_CTL+3)
-#define IP_VS_SO_GET_DESTS	(IP_VS_BASE_CTL+4)
-#define IP_VS_SO_GET_DEST	(IP_VS_BASE_CTL+5)	/* not used now */
-#define IP_VS_SO_GET_TIMEOUT	(IP_VS_BASE_CTL+6)
-#define IP_VS_SO_GET_DAEMON	(IP_VS_BASE_CTL+7)
-#define IP_VS_SO_GET_MAX	IP_VS_SO_GET_DAEMON
-
-
-/*
- *  IPVS Connection Flags
- *  Only flags 0..15 are sent to backup server
- */
-#define IP_VS_CONN_F_FWD_MASK	0x0007		/* mask for the fwd methods */
-#define IP_VS_CONN_F_MASQ	0x		/* masquerading/NAT */
-#define IP_VS_CONN_F_LOCALNODE	0x0001		/* local node */
-#define IP_VS_CONN_F_TUNNEL	0x0002		/* tunneling */
-#define IP_VS_CONN_F_DROUTE	0x0003		/* direct routing */
-#define IP_VS_CONN_F_BYPASS	0x0004		/* cache bypass */
-#define IP_VS_CONN_F_SYNC	0x0020		/* entry created by sync */
-#define IP_VS_CONN_F_HASHED	0x0040		/* hashed entry */
-#define IP_VS_CONN_F_NOOUTPUT	0x0080		/* no output packets */
-#define IP_VS_CONN_F_INACTIVE	0x0100		/* not established */
-#define IP_VS_CONN_F_OUT_SEQ	0x0200		/* must do output seq adjust */
-#define IP_VS_CONN_F_IN_SEQ	0x0400		/* must do input seq adjust */
-#define IP_VS_CONN_F_SEQ_MASK	0x0600		/* in/out sequence mask */
-#define IP_VS_CONN_F_NO_CPORT	0x0

Bug#998108: Tracking this bug down

[Vincent Bernat]

 ❦  4 November 2021 23:39 +01, Eugen Dedu:

> Maybe I am wrong, but, for me, the simplest method to track this bug
> down is to check the changes between the two versions, 93.0 and 
> 93.0-1+b1.  Firefox code has not changed, only one or some libraries
> it depends on.  I thought that the only change is in libvpx version,
> but, surprisingly, a previous comment mentions that rebuilding firefox
> with old vpx (libvpx6) still exhibits the bug.  I think that libc6 is
> out of question, because the last package is 19 Sep, too old wrt this
> bug; the same for gcc-11, the last package being on 21 Oct.  Doesn't
> this (checking the changes) sound like a good approach to find the
> cause of the problem?

There are a lot of changes between the two builds:

- automake (= 1:1.16.5-1),
+ automake (= 1:1.16.4-2),
- bash (= 5.1-3+b2),
+ bash (= 5.1-3+b1),
- bsdextrautils (= 2.37.2-4),
- bsdutils (= 1:2.37.2-4),
+ bsdextrautils (= 2.37.2-3),
+ bsdutils (= 1:2.37.2-3),
- cargo (= 0.57.0-3),
+ cargo (= 0.47.0-3+b1),
- cpp (= 4:11.2.0-2),
- cpp-11 (= 11.2.0-10),
- dash (= 0.5.11+git20210120+802ebd4-2),
- dbus (= 1.12.20-3),
- dbus-bin (= 1.12.20-3),
- dbus-daemon (= 1.12.20-3),
- dbus-session-bus-common (= 1.12.20-3),
- dbus-system-bus-common (= 1.12.20-3),
- dbus-user-session (= 1.12.20-3),
+ cpp (= 4:10.2.1-1),
+ cpp-10 (= 10.3.0-11),
+ dash (= 0.5.11+git20210120+802ebd4-1),
+ dbus (= 1.12.20-2),
+ dbus-user-session (= 1.12.20-2),
- debconf (= 1.5.78),
+ debconf (= 1.5.77),
- dh-strip-nondeterminism (= 1.12.0-2),
+ dh-strip-nondeterminism (= 1.12.0-1),
- g++ (= 4:11.2.0-2),
- g++-11 (= 11.2.0-10),
- gcc (= 4:11.2.0-2),
+ g++ (= 4:10.2.1-1),
+ g++-10 (= 10.3.0-11),
+ gcc (= 4:10.2.1-1),
+ gcc-10 (= 10.3.0-11),
- gcc-11 (= 11.2.0-10),
- gcc-11-base (= 11.2.0-10),
+ gcc-11-base (= 11.2.0-8),
- lib32gcc-s1 (= 11.2.0-10),
- lib32stdc++6 (= 11.2.0-10),
+ lib32gcc-s1 (= 11.2.0-8),
+ lib32stdc++6 (= 11.2.0-8),
- libapparmor1 (= 3.0.3-5),
+ libapparmor1 (= 3.0.3-2),
- libasan6 (= 11.2.0-10),
+ libasan6 (= 11.2.0-8),
- libatomic1 (= 11.2.0-10),
+ libatomic1 (= 11.2.0-8),
- libaudit-common (= 1:3.0.6-1),
- libaudit1 (= 1:3.0.6-1),
+ libaudit-common (= 1:3.0.5-1),
+ libaudit1 (= 1:3.0.5-1),
- libblkid-dev (= 2.37.2-4),
- libblkid1 (= 2.37.2-4),
+ libblkid-dev (= 2.37.2-3),
+ libblkid1 (= 2.37.2-3),
- libc-ares2 (= 1.18.1-1),
+ libc-ares2 (= 1.17.2-1),
- libcc1-0 (= 11.2.0-10),
+ libcc1-0 (= 11.2.0-8),
- libcryptsetup12 (= 2:2.4.1-1),
+ libcryptsetup12 (= 2:2.4.0-1),
- libdatrie-dev (= 0.2.13-2),
- libdatrie1 (= 0.2.13-2),
+ libdatrie-dev (= 0.2.13-1),
+ libdatrie1 (= 0.2.13-1),
- libdbus-1-3 (= 1.12.20-3),
- libdbus-1-dev (= 1.12.20-3),
+ libdbus-1-3 (= 1.12.20-2),
+ libdbus-1-dev (= 1.12.20-2),
- libdeflate-dev (= 1.8-1),
- libdeflate0 (= 1.8-1),
+ libdeflate-dev (= 1.7-2),
+ libdeflate0 (= 1.7-2),
- libegl-mesa0 (= 21.2.4-1),
+ libegl-mesa0 (= 21.2.3-1),
- libegl1-mesa-dev (= 21.2.4-1),
+ libegl1-mesa-dev (= 21.2.3-1),
- libepoxy-dev (= 1.5.9-2),
- libepoxy0 (= 1.5.9-2),
+ libepoxy-dev (= 1.5.9-1),
+ libepoxy0 (= 1.5.9-1),
- libexpat1 (= 2.4.1-3),
- libexpat1-dev (= 2.4.1-3),
- libffi-dev (= 3.4.2-3),
- libffi8 (= 3.4.2-3),
- libfile-stripnondeterminism-perl (= 1.12.0-2),
+ libexpat1 (= 2.4.1-2+b1),
+ libexpat1-dev (= 2.4.1-2+b1),
+ libffi-dev (= 3.4.2-2),
+ libffi7 (= 3.3-6),
+ libffi8 (= 3.4.2-2),
+ libfile-stripnondeterminism-perl (= 1.12.0-1),
- libfreetype-dev (= 2.11.0+dfsg-1),
- libfreetype6 (= 2.11.0+dfsg-1),
- libfreetype6-dev (= 2.11.0+dfsg-1),
+ libfreetype-dev (= 2.10.4+dfsg-1),
+ libfreetype6 (= 2.10.4+dfsg-1),
+ libfreetype6-dev (= 2.10.4+dfsg-1),
- libgbm1 (= 21.2.4-1),
+ libgbm1 (= 21.2.3-1),
- libgcc-11-dev (= 11.2.0-10),
- libgcc-s1 (= 11.2.0-10),
+ libgcc-s1 (= 11.2.0-8),
- libgdbm-compat4 (= 1.22-1),
- libgdbm6 (= 1.22-1),
+ libgdbm-compat4 (= 1.21-1),
+ libgdbm6 (= 1.21-1),
- libgl1-mesa-dri (= 21.2.4-1),
- libglapi-mesa (= 21.2.4-1),
+ libgl1-mesa-dri (= 21.2.3-1),
+ libglapi-mesa (= 21.2.3-1),
- libglib2.0-0 (= 2.70.0-3),
- libglib2.0-bin (= 2.70.0-3),
- libglib2.0-data (= 2.70.0-3),
- libglib2.0-dev (= 2.70.0-3),
- libglib2.0-dev-bin (= 2.70.0-3),
+ libglib2.0-0 (= 2.70.0-1+b1),
+ libglib2.0-bin (= 2.70.0-1+b1),
+ libglib2.0-data (= 2.70.0-1),
+ libglib2.0-dev (= 2.70.0-1+b1),
+ libglib2.0-dev-bin (= 2.70.0-1+b1),
- libglx-mesa0 (= 21.2.4-1),
+ libglx-mesa0 (= 21.2.3-1),
- libgomp1 (= 11.2.0-10),
+ libgomp1 (= 11.2.0-8),
- libisl23 (= 0.24-2),
- libitm1 (= 11.2.0-10),
+ libisl23 (= 0.23-1),
+ libitm1 (= 11.2.0-8),
- libllvm12 (= 1:12.0.1-15),
- libllvm13 (= 1:13.0.0-8),
- liblsan0 (= 11.2.0-10),
+ libllvm12 (= 1:12.0.1-9),
+ libllvm13 (= 1:13.0.0-2),
+ liblsan0 (= 11.2.0-8),
- libmount-dev (= 2.37.2-4),
- libmount1 (= 2.37.2-4),
- libmpc3 (= 1.2.1-1),
+ libmount-dev (= 2.37.2-3),
+ libmount1 (= 2.37.2-3),
+ libmpc3 (= 1.2.0-1),
- libnode72 (= 12.22.7~dfsg-2),
+ libnode72 (= 12.22.5~dfsg-5),
- libobjc4 (= 11.2.0-10),
+ libobjc4 (= 11.2.0-8),
- libp11-kit0 (= 0.24.0-5),
+ libp11-kit0 (= 0.24.0-3),
- libpam-sys

Bug#990821: aptly fails to run if both gnupg2 and gnupg1 are installed

[Vincent Bernat]

 ❦  8 July 2021 16:51 +02, Christoph Berg:

> As soon as gpg1 (package gnupg1) and gpgv (from gnupg 2) are
> installed, aptly fails to run. I think aptly should "Conflicts:
> gnupg1", but maybe there is a better fix.

This also happens when gpgv1 is installed.
-- 
Don't sacrifice clarity for small gains in "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)

Bug#995823: bullseye-pu: package kodi/2:19.2+dfsg1-1~deb11u1 (pre-upload unblock bug)

[Vincent Bernat]

 ❦  7 October 2021 16:24 GMT, Vasyl Gello:

> FYI, kodi 2:19.1+dfsg2-2_19.2+dfsg1-1 is in unstable :)

I have been running a version rebuilt for Bullseye since a few days
(notably due to issues with HD audio which are fixed in this release)
and it works fine for me.
-- 
For a light heart lives long.
-- Shakespeare, "Love's Labour's Lost"

Bug#995817: ERROR: Could not resolve symbol: /proc/self/exe:BEGIN_trigger

[Vincent Bernat]

 ❦  6 October 2021 15:03 +02, Salvatore Bonaccorso:

> After updating bpftrace to 0.13.0-1 in unstable, I noticed invocation
> using a BEGIN block do not work anymore, the BEGIN_trigger symbol
> cannot be resolved, basically reproducible with the minimal:
>
> # bpftrace -e 'BEGIN { }'
> Attaching 1 probe...
> ERROR: Could not resolve symbol: /proc/self/exe:BEGIN_trigger
>
> Samewise for the END_trigger.
>
> Not further checked on the issue.
>
> p.s.: please downgrade if you think important is not appropriate.

In fact, it does not happen if you have debug symbols. My patch does not
work anymore either and the previous upload did not fix this bug. Some
distributions work around that by asking "strip" to keep BEGIN_trigger.
It seems we cannot do that easily with dh_strip.
-- 
Don't diddle code to make it faster - find a better algorithm.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#930557: i3-gaps RFS/ITP

[Vincent Bernat]

 ❦  3 October 2021 09:16 +02, Michael Stapelberg:

> I will stress one more time that what we need here is not a one-time
> sponsorship offer, but a multi-year commitment for maintaining the
> i3-gaps package in Debian.

Let's hear from antisocrates. I can offer a multi-year commitment for
sponsorship and take over maintainance if needed. I can also maintain it
myself.

I suppose you would favor i3-gaps to conflict with i3-wm instead of
trying to be co-installable (with or without alternatives as the
difference is limited to a few binaries and I think this does not
include i3-msg).
-- 
Must I hold a candle to my shames?
-- William Shakespeare, "The Merchant of Venice"

Bug#930557: i3-gaps RFS/ITP

[Vincent Bernat]

 ❦  3 October 2021 08:48 +02, Michael Stapelberg:

> I still think it’d be better to spend time on merging gaps rather than
> packaging gaps,
> but it seems like nobody has the skill set and/or motivation.

This is a very different skillset from packaging.

> Is there someone who would continuously maintain i3-gaps in Debian?
> I wouldn’t want that package to diverge from upstream i3 in terms of which
> version is available in Debian.

Alternatively, src:i3-wm could build both i3-wm and i3-gaps. It adds
extra work on existing maintainers but maybe you and Jakob would be OK
with that? I can propose a patch for that if it helps.
-- 
Use recursive procedures for recursively-defined data structures.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#930557: i3-gaps RFS/ITP

[Vincent Bernat]

 ❦ 17 June 2019 18:30 +02, Michael Stapelberg:

> Ingo will outline what needs to be done to get i3-gaps into a mergable
> state, so that we can eventually bring these features to all i3 users.
>
> For the time being, our recommendation is to NOT add i3-gaps to Debian or
> any other Linux distribution. Instead, if you have time and motivation,
> please consider helping improve i3-gaps with the goal of a merge.

It seems there is not much progress on this front. The issue on GitHub
does not show activity either. As other popular desktop distributions
(Fedora, openSuSE, Arch and Manjaro) are providing a i3-gaps package,
maybe an i3-gaps package in Debian could be reconsidered?

I would gladly sponsor it if there is no strong opposition from i3
maintainers.
-- 
Write and test a big program in small pieces.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#994865: Delayed start due to Pipewire not running

[Vincent Bernat]

 ❦ 23 September 2021 17:09 +02, Vincent Bernat:

> Let me reboot at the end of the day with just xdg-desktop-portal in
> verbose mode, it may be enough to find the cause. If not, I will apply
> your other tricks.

OK, a bit late, but on verbose, I get:

Sep 30 07:57:56 chocobo xdg-desktop-portal[1730]: XDP: providing portal 
org.freedesktop.portal.FileChooser
Sep 30 07:57:56 chocobo xdg-desktop-portal[1730]: XDP: Falling back to 
gtk.portal for org.freedesktop.impl.portal.AppChooser
Sep 30 07:58:21 chocobo xdg-desktop-portal[1730]: XDP: Failed to create 
FileManager proxy: Error calling StartServiceByName for 
org.freedesktop.FileManager1: Timeout was reached
Sep 30 07:58:21 chocobo xdg-desktop-portal[1730]: XDP: providing portal 
org.freedesktop.portal.OpenURI
Sep 30 07:58:21 chocobo xdg-desktop-portal[1730]: XDP: Falling back to 
gtk.portal for org.freedesktop.impl.portal.Print

I have Thunar installed and I think there may be just a dependency loop:

Sep 30 07:58:21 chocobo dbus-daemon[1433]: [session uid=1000 pid=1433] 
Successfully activated service 'org.freedesktop.portal.Desktop'
Sep 30 07:58:22 chocobo dbus-daemon[1433]: [session uid=1000 pid=1433] 
Successfully activated service 'org.freedesktop.FileManager1'

 08:07 ❱ journalctl -b0 --user-unit=thunar.service
-- Journal begins at Sun 2021-08-01 16:26:21 CEST, ends at Thu 2021-09-30 
08:05:07 CEST. --
Sep 30 07:57:56 chocobo systemd[1402]: Starting Thunar file manager...
Sep 30 07:58:22 chocobo systemd[1402]: Started Thunar file manager.

So, the bug may be more in Thunar. This looks like:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929490
https://www.reddit.com/r/swaywm/comments/ptwd6p/thunar_and_xdgdesktopportal_block_each_other/

Personally, I don't care much about org.freedesktop.FileManager1 and I
would prefer this dbus service to not be provided at all. I'll try to
mask thunar.service to avoid this.
-- 
I do desire we may be better strangers.
-- William Shakespeare, "As You Like It"

Bug#994865: Delayed start due to Pipewire not running

[Vincent Bernat]

 ❦ 23 September 2021 15:37 +01, Simon McVittie:

> I see from your initial bug report that you are using systemd as pid 1,
> systemd --user, and dbus-user-session (i.e. dbus-daemon --session is
> running as a systemd --user unit). Is that correct?

Yes.

> What desktop environment are you using? Or if you have made your own
> desktop environment from individual components, what are the major
> components like window manager and session manager (if any)?

lightdm with autologin to Xsession which chains to systemd --user which
spawns i3 and various other stuff.

> It might be helpful to run the affected GTK app with G_MESSAGES_DEBUG=all
> in the environment. This doesn't work for gnome-terminal because
> gnome-terminal is weird, but gnome-terminal -vv is close enough.

I am using my own terminal and since it is a "GTK application" (it has a
daemon mode), I think it may be like gnome-terminal, but the very first
terminal is "normal".

> Most components that talk to xdg-desktop-portal only do so when they find
> that they're running as a Flatpak app, or maybe some other sandboxed app
> framework like Snap. Just to rule some things out: are you launching
> Flatpak and/or Snap apps? Or if not, do you have environment variable
> GTK_USE_PORTAL set?

No Flatpak on boot. I am using some later.

Let me reboot at the end of the day with just xdg-desktop-portal in
verbose mode, it may be enough to find the cause. If not, I will apply
your other tricks.
-- 
If you tell the truth you don't have to remember anything.
-- Mark Twain

Bug#994865: Delayed start due to Pipewire not running

[Vincent Bernat]

 ❦ 23 September 2021 10:08 +01, Simon McVittie:

>> Since upgrading to 1.10.1-1, xdg-desktop-portal service takes a lot of
>> time to start on a desktop not using Pipewire.
>
> Looking at the diff, I don't understand why this particular upgrade
> would trigger this: the only Pipewire-related change was to add a 10
> second timeout on some operations, instead of waiting indefinitely.
>
> Are you sure this is triggered by upgrading xdg-desktop-portal, and not
> by upgrading some related package - perhaps x-d-p-gtk or pipewire?

I don't have Pipewire installed (but it was installed at some point). I
see that on a previous boot, the same error was here but did not
introduce a delay.

> The 25 second delay you reported is the default timeout for D-Bus method
> calls, so I suspect what you are seeing here is a D-Bus method call that
> never gets a reply and times out.
>
> I'm less confident than you are that the missing Pipewire service is the
> root cause here. I think the log you reported is equally consistent with
> some unrelated D-Bus method call starting, timing out 25 seconds later,
> and then x-d-p proceeding through its remaining startup tasks, one of
> which is to try to talk to Pipewire to decide whether it can provide
> video-related portals (screen-sharing and remote-desktop).
>
> It might be helpful to run
>
> /usr/libexec/xdg-desktop-portal --verbose --replace
>
> or even
>
> G_MESSAGES_DEBUG=all /usr/libexec/xdg-desktop-portal --verbose --replace
>
> and report what the output is, and where in the output the 25 second delay
> happened.

Unfortunately, it seems the problem only happens on boot. I have added
--verbose for the next boot and I'll keep you posted.

> Doing the same for xdg-desktop-portal-gtk (or whatever other backend you
> are using, if not -gtk) could also provide useful information; or watching
> the output of `dbus-monitor --session` might also be helpful, although
> there will be a lot of noise from unrelated D-Bus operations in that.

xdg-desktop-portal-gtk started without delay and its log does not have
any error.

>> In turn, this seems to delay many other things that rely on this
>> service. For example, VTE terminals are delayed.
>
> I would have expected xdg-desktop-portal to start up at most once per
> GUI login session, so I would have expected you to only see a delay
> once.

Yes, the delay happens only once.

> If you're seeing a delay in opening VTE terminals, one possible reason
> is that when /etc/profile.d/flatpak.sh runs
> `GIO_USE_VFS=local flatpak --installations`, it might be doing IPC to some
> service that takes a long time.
>
> If you run
>
> G_MESSAGES_DEBUG=all flatpak --installations -vv
>
> is that also delayed, and are there any clues in its output?

The terminal window does is not displayed. The delay is related to the
fact that VTE terminals (like Gnome Terminal) are "GTK apps" and they
synchronize with DBus to find an existing instance if any. For some
reason, this requires a desktop portal.

So, I'll reboot before the end of the week and I'll tell you what's in
the logs.
-- 
Test programs at their boundary values.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#994890: New upstream version (5.7.4)

[Vincent Bernat]

Package: maim
Version: 5.6.3-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

Could you please upload a new version? 5.6.3 is getting a bit old and
I am running into an annoying bug that may be fixed in a more recent
version.

Thanks!


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

Kernel: Linux 5.14.0-1-amd64 (SMP w/12 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages maim depends on:
ii  libc62.32-4
ii  libgcc-s111.2.0-7
ii  libjpeg62-turbo  1:2.0.6-4
ii  libpng16-16  1.6.37-3
ii  libstdc++6   11.2.0-7
ii  libx11-6 2:1.7.2-2+b1
ii  libxcomposite1   1:0.4.5-1
ii  libxext6 2:1.3.4-1
ii  libxfixes3   1:5.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  slop 7.5-1+b1

maim recommends no packages.

maim suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmFLYPgSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5gvgP/R2B3vthPg67Ch5dUEcF6i7CNEZhfHSu
Nmxb8LyaAPHM682dTvBbb0lK6Dh2PjUIBZLnKs1rc8kD1RgnVlf5BYpyvO0E/hin
PlmG/XK3vRzAkXNagO6KDHm9n+B1p9gTmfCzyXbzJP7lgthZgwP5pd+qdtg3nS4n
NWIY+kqUGFV6eAbWO2CIrUrA/VYCufP2spNR7aUgVFNRciklYxtxJD6/0zNVXu1n
fpC+1JBQnER7rg8gCZTChEuIMeNa1BYPTvS9WBVPEcXMKyOEoQzCDN1OcuqoaaLX
g4XxlCU+KwKd3AA2JRKivb0Qb+S55uqqeCoiVkxm8N4TU4KqvdUQe2fSKHwVQrtI
gb4GDZK+jEYXOEzf7FqHfhvfV5Gt3Kpw3KmJcQXqh6Kszq2j4zsox7jvV+dJ28Kv
Qc+jPMZE5ltkqEhSCM8HM/mH5v1bNAB8haKAPQJ2j9DKst2eZq2EfNKctRgjMxIX
pwjrnumOrArBnSGaccNX4mmhboxiNnSqD3JgvLLFlsYWCYzqh18YfXDc6sAZL8zN
dV3aQMNsXCcdmgsVi3m/vbYnATIR2OQ224rJan8n7QAPEdiaNOrssn5Ei5u9e+C/
yEgBIOGODObiJFPuAwzADoo64q9nEXZsI4kwpl3ce70Ytr4HyY8d+sQ+5xyk5GRU
33xCAxiNWhgA
=16HM
-END PGP SIGNATURE-

Bug#980300: libcbor: Please upgrade to new version 0.8.0

[Vincent Bernat]

 ❦ 21 September 2021 14:54 -04, Nicolas Mora:

> Friendly ping request for this bug.
> If you need help, I'll be happy to help you with this upgrade.

Done. It is waiting in NEW.
-- 
Identify bad input; recover if possible.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#994865: Delayed start due to Pipewire not running

[Vincent Bernat]

Package: xdg-desktop-portal
Version: 1.10.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

Since upgrading to 1.10.1-1, xdg-desktop-portal service takes a lot of
time to start on a desktop not using Pipewire.

 09:52 ❱ journalctl -b0 --user-unit=xdg-desktop-portal
- -- Journal begins at Sat 2021-07-31 17:43:34 CEST, ends at Wed 2021-09-22 
09:50:26 CEST. --
Sep 22 09:39:02 neo systemd[1655]: Starting Portal service...
Sep 22 09:39:27 neo xdg-desktop-portal[2274]: context 0x56081dd4ed40: can't 
load config client.conf: No such file or directory
Sep 22 09:39:27 neo xdg-desktop-portal[2274]: context 0x56081dd4ed40: can't 
load config client.conf: No such file or directory
Sep 22 09:39:27 neo xdg-desktop-por[2274]: Failed connect to PipeWire: Couldn't 
create PipeWire context
Sep 22 09:39:27 neo systemd[1655]: Started Portal service.

In turn, this seems to delay many other things that rely on this
service. For example, VTE terminals are delayed.

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

Kernel: Linux 5.14.0-1-amd64 (SMP w/12 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xdg-desktop-portal depends on:
ii  bubblewrap0.5.0-1
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-2
ii  dbus-x11 [dbus-session-bus]   1.12.20-2
ii  fuse3 [fuse]  3.10.5-1
ii  libc6 2.32-4
ii  libfuse2  2.9.9-5
ii  libgdk-pixbuf-2.0-0   2.42.6+dfsg-2
ii  libglib2.0-0  2.70.0-1
ii  libjson-glib-1.0-01.6.6-1
ii  libpipewire-0.3-0 0.3.36-1

xdg-desktop-portal recommends no packages.

xdg-desktop-portal suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmFK4UMSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5PdQP/2ucWQj0hy8lUcziq0ipJAXrA4gAgw/4
0ItN/TXnFvjFEphm8GNf+phCX1GMMpZ8hDsd0GSrh075heabLeslT5SgTTzf66Hj
uTXCrtGyCWRfy4Gejs24FqfUbRthWJKUfLfhoWzwdmltxrVCupaMUVnUmGHVnc/+
bb17WtIGBRgXuVn7i3o9HbmyeN/g52j9hwq8r01gdpr20jtlSgntj8JrHVZa0FIy
d9Le4GCDEtJixvoS3Rd34anLOvUituma9ykrGYR+H3HGSKCTZYBMGlG5USUMxvyz
p+GaBP+/RRUyW4ylCtack9VdJxlMFqbM5qJX/KZOTQGOEp82NqCHirUtoVvHV1NO
H7q9KZ6a5zZQ7ow+orfZ68pHnlZW0is1JLr2ZQM5S/lONsUFlmXlfnTvk/WzjtRf
wO7WE85eg1tHtgpgxzytZTl/9LAV7yeY0UL6hA6iNRwGjAm8nD6BwvUaBcOelhMU
zR+8pzDoFPRmfVxHQeJEfOTWI7q6RMdXOonUF3t+v1h0MqRN+MWkdjqcBIdPDN6g
mWwaOr4gr7Y+c5pBrvO0DzoegpiHEkC8LDF1cVSeXTJDbOoSGdR3fPCvdZEoPBTD
/BTOZ2foZgZfHiziGoACis/C9iPB7vWRaKmtumzi2UZvqQ6R1IffbZca2Ljgnd7H
RwoM33yporRa
=g1Mf
-END PGP SIGNATURE-

Bug#992149: firmware-sof: Internal microphone (DMIC) not working on Lenovo Thinkpad 13S

[Vincent Bernat]

 ❦ 21 September 2021 18:03 +03, Andrei POPESCU:

>> The work-around is presented here:
>> https://github.com/thesofproject/linux/issues/2460#issuecomment-779212719
>> 
>> In a nutshell, a binary blob is offered there to replace the file
>> sof-hda-generic-2ch.tplg in firmware-sof-signed.

>From my understand, this would break all laptops where the mic is on
PDM0. It seems the infrastructure to detect PDM0 or PDM1 is not here yet.
-- 
Make sure every module hides something.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#977738: rofi: New upstream release 1.6.1

[Vincent Bernat]

 ❦ 19 December 2020 20:18 GMT, Ayose:

> A new version was published:
>
> https://github.com/davatorium/rofi/releases/tag/1.6.1
>
> Version 1.6.0 is very interesting because it adds a new [1]script mode
> that allows more powerful selectors.
>
> I tried to build the package using the current [2]debian directory for
> the package in Sid and it seems to work with no changes.
>
> 1. https://github.com/davatorium/rofi/blob/next/doc/rofi-script.5.markdown
> 2. https://deb.debian.org/debian/pool/main/r/rofi/rofi_1.5.4-1.debian.tar.xz

I am also interested by updating Rofi in Debian. Jason, do you plan to
continue working on Rofi? I can sponsor the uploads if needed.
-- 
Use recursive procedures for recursively-defined data structures.
- The Elements of Programming Style (Kernighan & Plauger)

Bug#993821: After upgrading libc, some services are unable to restart (including systemd-resolved)

[Vincent Bernat]

Package: systemd
Version: 247.9-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

After upgrading to libc6 2.32-1, some services are unable to restart.
In my case, systemd-resolved, systemd-timesyncd and colord. Using
"systemctl daemon-reexec" fixes the issue. Unsure if there is really
something to be fixed but as I didn't find anything about that, a bug
report may help others. I suppose the problem is related to NSS.

Sep 06 23:06:43 chocobo systemd[1]: Starting Network Time Synchronization...
Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service: Failed to 
determine user credentials: No such process
Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service: Failed at 
step USER spawning /lib/systemd/systemd-timesyncd: No such process



- -- Package-specific info:

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

Kernel: Linux 5.13.0-trunk-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_USER
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.3.1-1
ii  libapparmor1 3.0.3-2
ii  libaudit11:3.0.5-1
ii  libblkid12.37.2-2
ii  libc62.32-1
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.25-2
ii  libcryptsetup12  2:2.4.0-1
ii  libgcrypt20  1.9.4-2
ii  libgnutls30  3.7.2-2
ii  libgpg-error01.42-3
ii  libip4tc21.8.7-1
ii  libkmod2 29-1
ii  liblz4-1 1.9.3-2
ii  liblzma5 5.2.5-2
ii  libmount12.37.2-2
ii  libpam0g 1.4.0-10
ii  libseccomp2  2.5.1-1
ii  libselinux1  3.1-3
ii  libsystemd0  247.9-1
ii  libzstd1 1.4.8+dfsg-2.1
ii  mount2.37.2-2
ii  systemd-timesyncd [time-daemon]  247.9-1
ii  util-linux   2.37.2-2

Versions of packages systemd recommends:
ii  dbus  1.12.20-2

Versions of packages systemd suggests:
ii  policykit-10.105-31
ii  systemd-container  247.9-1

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
ii  libnss-systemd   247.9-1
ii  libpam-systemd   247.9-1
ii  udev 247.9-1

- -- Configuration Files:
/etc/systemd/logind.conf changed:
[Login]
HandlePowerKey=ignore

/etc/systemd/resolved.conf changed:
[Resolve]
DNSSEC=allow-downgrade


- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmE2jA8SHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5HXcQAKG5+toLrAqmXBjrFCHUauoUJ1MKEXYp
gMk11uNJd61yY0gW7eQHNJ1bl1aeXQ5FBOw830xMVFn9qXcCAghrDcB8yT8Vlsw9
XQQakme/+qUNU6xg4RW9IRbrqH32AhV1hp4rkrchjVYpoLng26JOV7zKSs7PrhL/
THtVzuxRnqgyQ0j742yDmw5X6y/jqBIyOgdVWm176kYIaIvkob8i8YzF8eSjQCgq
0PEDVwtbkDUu8M79lA2QPTya+3y9xD/vp01/hbyMA7+lOfQKC5ylX5rklsMhsWez
mLwRBj3UYGGYm6jRWwYRbciSCpYLxsz0RVz6+T8FStyGqh3vNBAWFQHYn47QtypU
2t4JGgJV+Z6yDeY2eh/ltk2kk+yhsMJtDzEoY7unsG4fWa8MoxgdKeIwbQ3Hujir
uyQMD170q5/AkPWsmKeJm2OdBF9nRs8dGU+VGi80XZzld0Ociu0tcUQu9F9LbrNj
5HdvUlkY6rkW0OsTpDBjKqVyB/DMHT9ciS5o9a/C6ZwRMspyItxKrxtN+9M2VIN3
5BHv/2vuZfh5OqDCtlVVwEhj2YZUVlEmtIJ+UfA7VfupXHwNiCvI8QOWkKcOvkMJ
1FurFmmJ3WED/2qLfr25GhZgyUGDb/3NluuHHnwRIkpCBYyV4qOSnAd/z4SUa+wv
p2k968FNOmUz
=jj8P
-END PGP SIGNATURE-

Bug#993658: qemu-user-static does not work through binfmt since 6.0

[Vincent Bernat]

 ❦  4 September 2021 15:49 +03, Michael Tokarev:

>> Kernel: Linux 5.13.0-trunk-amd64 (SMP w/12 CPU threads)
>
> Can you please check if it works with not-so-fresh kernel
> (eg the one from bullseye)?
>
> I wont able to do this until late evening today.
>
> I'm guessing this is the upstream way to detect if we were
> called from binfmt subsystem (they done it within kernel)
> interferes with my way of doing the same without touching
> the kernel. Kernel side is a recent addition.

It works fine with 5.10.0-8-amd64 from bullseye. Thanks!
-- 
The Public is merely a multiplied "me."
-- Mark Twain

Bug#993658: qemu-user-static does not work through binfmt since 6.0

[Vincent Bernat]

Package: qemu-user-static
Version: 1:6.1+dfsg-4
Severity: critical

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

Since 6.0, qemu-user-static does not seem to work properly through
binfmt. I am a bit lost on how to diagnose that:

 13:23 ❱ cat /proc/sys/fs/binfmt_misc/qemu-aarch64
enabled
interpreter /usr/libexec/qemu-binfmt/aarch64-binfmt-P
flags: POCF
offset 0
magic 7f454c46020101000200b700
mask ff00feff
 13:23 ❱ ./bin/busybox ls
BusyBox v1.30.1 (Debian 1:1.30.1-7) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
Licensed under GPLv2. See source distribution for detailed
copyright notices.
[...]
 13:25 ❱ file bin/busybox
bin/busybox: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), 
statically linked, BuildID[sha1]=6a67fd6d086c703062f3be2d751adf619aa67bc6, for 
GNU/Linux 3.7.0, stripped

When invoked through binfmt, the binaries seem to go from "I display
something wrong" to "I will wipe your entire home". That's what
happened to me when using cowbuilder. The chroot was not able to be
setup correctly and during the clean phase, cowbuilder did not detect
the bind mount and/or was not able to undo them, rm -rfing everything
that was mounted.

Downgrading qemu-user-static to 1:5.2+dfsg-11 fixes the issue.

 13:30 ❱ cat /proc/sys/fs/binfmt_misc/qemu-aarch64
enabled
interpreter /usr/libexec/qemu-binfmt/aarch64-binfmt-P
flags: POCF
offset 0
magic 7f454c46020101000200b700
mask ff00feff
 13:31 ❱ ./bin/busybox ls
bin  usr


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

Kernel: Linux 5.13.0-trunk-amd64 (SMP w/12 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  binfmt-support  2.2.1-1

Versions of packages qemu-user-static suggests:
ii  sudo  1.9.5p2-3

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmEzWXASHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5QgoQAKCvyj4ZvK38O+U4JczjZgEyFr1F3L91
04eRxVhienFsserUx+8qE50kQvAjFXt7iqjugF65o+UpsgC0YCG7f8Ri5KAynHWx
X5ChFgyZtjU3W9ZOs/zGBa9g2Dw8v3FcXO4AvjZnlmXHzLM7Xh7OhcmUjnQe5U1s
JPXw8tojzJA6gaqjCZRmkBuVZMfLteUSeb/yxbopdUCqlv89bFF5VyHS/Agoxj8Q
iRyo8qcyAhur/oqMe0tTCoLP9IWtisF1mO0TZoFe82qzSL/WTayn9nvJ7mhCS/s/
2PyuVa9z1z4NprnZj4f6L3DFszbIB/rlkZng1/GNd9VwAbFqlgGltHZbww1mAOhP
2+ssNF7TDWuFeNQbUwk/YJyzySM/t9fL+O21onahLOR/Hc+Z+tD0f91AdOhBOxM0
D14cqYjKiyQ3Td+N46ZyEkJXW1ThNE2PLU+tnkyXFJGOCfgVLZdPyIeyV77We/MF
9yV9Jy3XrvwuSuqaZZSmlqTp5HzY86AgfEesYTB7diyBTeFwKPE8qnNKOIBXLakG
yqH19GtqReRK4zImsQ+/0UU9qxuvrpwGgaAsClZtAxyeBLLdffsXi2kb4EAJ9B2C
HFHwSOF+zC91xm8x1wbezCJf9newuQRxvciAIPcXKmKwut9oLqI/zSDRk5LoZLwy
VjloaV/64hIA
=15C8
-END PGP SIGNATURE-

Bug#993429: Please indent example in package description

[Vincent Bernat]

 ❦  1 September 2021 08:23 +02, Christoph Biedl:

> please check https://packages.debian.org/sid/jo - there is a small and
> nice usage example in the package description, but unfortunately the
> formatting is rather poor.
>
> According to policy, just adding another space at the beginning of the
> respective lines should be sufficient to resolve that.

OK, it will be there on next upload!
-- 
Truth is the most valuable thing we have -- so let us economize it.
-- Mark Twain

Bug#865793: hsetroot FTCBFS: uses the build architecture pkg-config

[Vincent Bernat]

 ❦ 24 June 2017 22:31 +02, Helmut Grohne:

> hsetroot fails to cross build from source, because the patch added in
> #735758 uses the build architecture pkg-config. It should be using the
> PKG_PROG_PKG_CONFIG macro and access pkg-config through $PKG_CONFIG
> instead. After doing so, hsetroot cross builds successfully. Please
> consider applying the attached patch.

I have just uploaded a new version. Unfortunately, the build system is
now a very simple makefile. It accepts PKG_CONFIG as an environment
variable to change the location of pkg-config. Would this work when
crosscompiling?

Thanks.
-- 
No violence, gentlemen -- no violence, I beg of you!  Consider the furniture!
-- Sherlock Holmes

Bug#982249: New upstream version 0.33.0 - Please package

[Vincent Bernat]

Package: mpv
Followup-For: Bug #982249

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

Here is a patch to update to 0.33.1. If you prefer to pull directly
from Salsa, the branches are available on my fork:

 https://salsa.debian.org/bernat/mpv


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

Kernel: Linux 5.13.0-trunk-amd64 (SMP w/12 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mpv depends on:
ii  libarchive13  3.4.3-2+b1
ii  libasound21.2.5.1-1
ii  libass9   1:0.15.1-2
ii  libavcodec58  7:4.4-5
ii  libavdevice58 7:4.4-5
ii  libavfilter7  7:4.4-5
ii  libavformat58 7:4.4-5
ii  libavutil56   7:4.4-5
ii  libbluray21:1.3.0-3
ii  libc6 2.31-17
ii  libcaca0  0.99.beta19-2.2
ii  libcdio-cdda2 10.2+2.0.0-1+b2
ii  libcdio-paranoia2 10.2+2.0.0-1+b2
ii  libcdio19 2.1.0-2
ii  libdrm2   2.4.107-2
ii  libdvdnav46.1.1-1
ii  libegl1   1.3.2-1
ii  libgbm1   21.2.1-1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.17~dfsg-1
ii  libjpeg62-turbo   1:2.0.6-4
ii  liblcms2-22.12~rc1-2
ii  liblua5.2-0   5.2.4-1.1+b3
ii  libpulse0 15.0+dfsg1-2
ii  librubberband21.9.0-1
ii  libsdl2-2.0-0 2.0.14+dfsg2-3
ii  libswresample37:4.4-5
ii  libswscale5   7:4.4-5
ii  libuchardet0  0.0.7-1
ii  libva-drm22.12.0-2
ii  libva-wayland22.12.0-2
ii  libva-x11-2   2.12.0-2
ii  libva22.12.0-2
ii  libvdpau1 1.4-3
ii  libwayland-client01.19.0-2
ii  libwayland-cursor01.19.0-2
ii  libwayland-egl1   1.19.0-2
ii  libx11-6  2:1.7.2-1
ii  libxext6  2:1.3.3-1.1
ii  libxinerama1  2:1.1.4-2
ii  libxkbcommon0 1.0.3-2
ii  libxrandr22:1.5.1-1
ii  libxss1   1:1.2.3-1
ii  libxv12:1.0.11-1
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages mpv recommends:
ii  xdg-utils   1.1.3-4.1
ii  youtube-dl  2021.06.06-1

mpv suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmEl9TUSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5KEMQAJtafIg14KBpg95jlrsgsIQxym5SHT9+
6n8hqgFFuzwZLRjfEli4I8Xhjjn64KQ0pby2kGsXYsZcO1BEwfjiwb+TQzxTKmA2
4lUWiyVwBUhaog61/GAVEkrnuOjk1y13+jFTF4zl4TeU0ZgtGZ6jlBNOqVPFCdSf
JI9PtwBAkkmBKU5uHihfKvLeAhtKKzOMY/6jPIXP5+LNWUV3s65Bzit98shynE2w
zIxEQNvNHG3DSwhzwwb/VKgvNXCWHO21CFaPPK7bEbLbGj5TevL9Cw1hCRPP5gIF
kWPGuUAXEZfbT1sJbGt47kx1aB5acPYPOOhPtJvVGgFEwk0YD+p7gjsdEqVgvRw+
YwBqOnIMFIIDJ/bQ/cKvHOLFOLa+QK/YAyaIw7FA3bG7KN8XcEJGUT+i1I2FnuK1
B1RHBTvP3QhZq4Zo087+v6Bb/Ft7i+72bS/ZwEvZZqs+vpkBwedAqhwG90VySJdL
NwVLieqqGwYOKiTFrtO3xi+8cd6D9EySftfsJVXd1RbdRP062Ks9M6XRJVlNMjpV
peLgN/bAT4E3IvpPPYIlxhkL2ucsotXyV7OgUAFiw+VaMkkToH5BUOuyEd8ZRH6i
pPj9YghGtOHYESTApcdtHWrvwuQMEzjpA8nsOR5HT99CHfJjROEgxfl4llqSf9d5
mRmCmSBCOEO8
=ay07
-END PGP SIGNATURE-
diff --git a/debian/changelog b/debian/changelog
index b896541ff7f3..0abbbc810204 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+mpv (0.33.1-1) unstable; urgency=medium
+
+  * New upstream release. Closes: #982249.
+  * d/patches: remove fix for CVE-2021-30145, applied upstream.
+  * d/patches: remove ffmpeg ABI fix, applied upstream.
+  * d/patches: remove Lua security fix, applied upstream.
+  * d/rules: don't build with SMB client support (removed upstream).
+  * d/rules: don't build with sndio support (removed upstream).
+  * d/symbols: update.
+
+ -- Vincent Bernat   Wed, 25 Aug 2021 09:20:59 +0200
+
 mpv (0.32.0-3) unstable; urgency=medium
 
   * debian/patches: Apply upstream fix for CVE-2021-30145 (Closes: #986839)
diff --git a/debian/control b/debian/control
index a36186f0fcb2..7724677d81c1 100644
--- a/debian/control
+++ b/debian/control
@@ -31,8 +31,6 @@ Build-Depends:
  libpulse-dev,
  librubberband-dev,
  libsdl2-dev,
- libsmbclient-dev,
- libsndio-dev (>= 1.0.1),
  libswscale-dev (>= 7:4.0

Bug#846383: grub2: add TPM support

[Vincent Bernat]

fixed 846383 2.04-18
thanks

 ❦ 21 August 2021 20:42 +02, Vincent Bernat:

>> grub2 (2.04-18) unstable; urgency=medium
>>
>>   [ Steve McIntyre ]
>>   * Enable the shim_lock and tpm modules for i386-efi too. Ensure that
>> tpm is included in our EFI images.
>>   [...]
>>
>>  -- Colin Watson   Sun, 25 Apr 2021 16:20:17 +0100
>>
>> Do we think that's enough to close this bug?
>
> Does this mean it's inside "core.efi"? I think this is not the case:
> there is a "tpm.mod" file and "strings core.efi | grep tpm" does not
> return any result. But maybe it's easy for a user to build a core.efi
> with the module added? Some users may like core.efi to be signed, but
> that's not my case.

OK, that's not the file which is used to boot with EFI. This is
/usr/lib/grub/x86_64-efi/monolithic/grubx64.efi which contains the TPM
module. So, yes, this can be closed.

-- 
Must I hold a candle to my shames?
-- William Shakespeare, "The Merchant of Venice"

Bug#846383: grub2: add TPM support

[Vincent Bernat]

 ❦ 21 August 2021 17:45 +01, Colin Watson:

>> > We think that TPM support is a good addition to Debian because it can 
>> > increase
>> > its adoption in environments where a more secure approach to the booting is
>> > needed, by being able to securely measure if any component has been
>> > tampered.
>> 
>> It seems that Grub in Debian has now TPM support as there is a tpm.mod
>> shipped with Grub. Manual here:
>> https://www.gnu.org/software/grub/manual/grub/html_node/Measured-Boot.html
>> 
>> The documentation suggests the module should be builtin. If not, it is a
>> bit unknown what can happen. Maybe the tpm.mod itself can be tampered?
>> 
>> Would it be possible to have the module builtin for GRUB UEFI (where
>> the size does not matter)?
>
> It already is, in bullseye:
>
> grub2 (2.04-18) unstable; urgency=medium
>
>   [ Steve McIntyre ]
>   * Enable the shim_lock and tpm modules for i386-efi too. Ensure that
> tpm is included in our EFI images.
>   [...]
>
>  -- Colin Watson   Sun, 25 Apr 2021 16:20:17 +0100
>
> Do we think that's enough to close this bug?

Does this mean it's inside "core.efi"? I think this is not the case:
there is a "tpm.mod" file and "strings core.efi | grep tpm" does not
return any result. But maybe it's easy for a user to build a core.efi
with the module added? Some users may like core.efi to be signed, but
that's not my case.
-- 
Consider well the proportions of things.  It is better to be a young June-bug
than an old bird of paradise.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"