Bug#1063897: firefox: poor performance compared to vendor package
On Wed, 14 Feb 2024 16:49:59 +0100 Sylvestre Ledru wrote: > > Le 14/02/2024 à 13:00, Lorenzo Bertini a écrit : > > Dear Maintainer, > > > > Firefox on debian (both ESR and sid versions) is performing poorly. Here are the > > results on one of my machines, but it's consistent with all the others: > > > > Test: Browserbench Speedometer 2.1 (https://browserbench.org/Speedometer2.1) > > > > Gentoo: 290 (+65%) > > Debian sid with vendor package: 260 (+50%) > > Debian sid firefox: 175 (-) > > Debian sid firefox-esr: 160 (-10%) > > > > Upon inspection, I think the cause is the optimization flags, including LTO, PGO, O3. > > Please take this report in consideration, as the performance increase is massive. > > it is expected and why Mozilla is providing a Debian package now AFACS, the packages provided by mozilla are only nightly/devedition/beta, but there is no stable release with the optimizations, or am I overlooking something?
Bug#1064060: wsdd: Split to client and server packages?
On Fri, 16 Feb 2024 10:04:53 -0500 =?UTF-8?Q?Jeremy_B=C3=ADcha?= wrote: > gvfs 1.53.90-1 uses wsdd to find newer Windows network shares. > > My initial understanding is that wsdd can be used both to advertise > network shares or to find network shares. gvfs only needs the "find" > behavior and gvfs calls wsdd from $PATH directly when needed. > > I believe it is unwanted behavior for wsdd.service to be running for > gvfs's use case. > > Therefore, please create a separate package for wsdd.service , perhaps > named wsdd-server Currently all machines installing wsdd start to advertise on the network and are automatically discoverable, this is less than optimal indeed. And other alternative is to pass "--no-enable --no-start" to dh_installsystemd and add an After/Wants in the packages that really requires the "server" part to be running? Not sure what other packages we are talking about here? There is currently on one rdep and it's gvfs But I agree the "server" part shouldn't be running by default, at least without the "--no-host" option
Bug#1063391: systemd: Please enable password quality check feature
Source: systemd Version: 255.3-1 Severity: wishlist Hello, Would it possible to enable the password quality check feature? If I understand the code, it's dynamically loaded at runtim, so no hard dependency on it(?) There are two backends for this, it looks like libpwquality1 has more rdepends than libpasswdqc1 $ apt-cache rdepends libpwquality1 libpwquality1 Reverse Depends: libpwquality-dev libpwquality1-dbgsym freeipa-server-trust-ad freeipa-server zulucrypt-gui seahorse mate-user-admin python3-pwquality libpwquality-tools gnome-control-center libpam-pwquality gnome-initial-setup gnome-disk-utility budgie-control-center calamares $ apt-cache rdepends libpasswdqc1 libpasswdqc1 Reverse Depends: libpasswdqc-dev libpasswdqc1-dbgsym passwdqc libpam-passwdqc
Bug#1061731: fwupd: Failed to load daemon: failed to load engine: Failed to load config: Key file does not have group “redfish”
On Mon, 29 Jan 2024 10:47:50 +0100 Laurent Bigonville wrote: > > Hello, > > It seems that fwupd is not starting anymore on my machine. > > In the logs I can see: > > jan 29 10:40:28 eriador systemd[1]: Starting fwupd.service - Firmware > update daemon... > jan 29 10:40:28 eriador fwupd[13042]: Failed to load daemon: failed to > load engine: Failed to load config: Key file does not have group “redfish” > jan 29 10:40:28 eriador systemd[1]: fwupd.service: Main process exited, > code=exited, status=1/FAILURE > jan 29 10:40:28 eriador systemd[1]: fwupd.service: Failed with result > 'exit-code'. > jan 29 10:40:28 eriador systemd[1]: Failed to start fwupd.service - > Firmware update daemon. > I've no idea what happened, but the configuration file was changed (I didn't do these changes): $ sudo diff -u fwupd/fwupd.conf /etc/fwupd/fwupd.conf --- fwupd/fwupd.conf 2024-01-24 10:15:36.0 +0100 +++ /etc/fwupd/fwupd.conf 2023-07-13 11:36:11.244229063 +0200 @@ -1,5 +1,20 @@ -# use `man 5 fwupd.conf` for documentation [fwupd] DisabledPlugins=test;test_ble OnlyTrusted=true AllowEmulation=false +DisabledPlugins=test;test_ble +IgnorePower=false +OnlyTrusted=true +AllowEmulation=false + +[msr] +MinimumSmeKernelVersion=5.18.0 + +[redfish] + +[thunderbolt] +MinimumKernelVersion=4.13.0 +DelayedActivation=false +RetimerOfflineMode=false + +[uefi_capsule]
Bug#1061776: fail2ban: Wrong journalmatch for sshd jail
Package: fail2ban Version: 1.0.2-2 Severity: serious Tags: sid trixie bookworm Hello, The default journalmatch for ssh the following: filter.d/sshd.conf: journalmatch = _SYSTEMD_UNIT=sshd.service + _COMM=sshd But the .service file for ssh in debian is called ssh.service, not sshd.service If I run journalctl _SYSTEMD_UNIT=sshd.service _COMM=sshd, I get no entries. If I run journalctl _SYSTEMD_UNIT=ssh.service _COMM=sshd , I get the logs I think there are still something broken with the switch to journald The configuration should be changed to: "_SYSTEMD_UNIT=ssh.service _COMM=sshd" IMVHO Kind regards, Laurent Bigonville
Bug#1061731: fwupd: Failed to load daemon: failed to load engine: Failed to load config: Key file does not have group “redfish”
Package: fwupd Version: 1.9.12-1 Severity: serious Hello, It seems that fwupd is not starting anymore on my machine. In the logs I can see: jan 29 10:40:28 eriador systemd[1]: Starting fwupd.service - Firmware update daemon... jan 29 10:40:28 eriador fwupd[13042]: Failed to load daemon: failed to load engine: Failed to load config: Key file does not have group “redfish” jan 29 10:40:28 eriador systemd[1]: fwupd.service: Main process exited, code=exited, status=1/FAILURE jan 29 10:40:28 eriador systemd[1]: fwupd.service: Failed with result 'exit-code'. jan 29 10:40:28 eriador systemd[1]: Failed to start fwupd.service - Firmware update daemon. Kind regards, Laurent Bigonville
Bug#926900: sslv3 alert illegal parameter
tag 926900 patch
thanks
The attached patch fixes the issue for me
Le 26/01/24 à 10:38, Laurent Bigonville a écrit :
When looking at the documentation of smtplib (the python library used
here), it says:
An SMTP_SSL instance behaves exactly the same as instances of SMTP.
SMTP_SSL*should be used for situations where SSL is required from the
beginning of the connection and using starttls() is not appropriate*.
If host is not specified, the local host is used. If port is zero, the standard
SMTP-over-SSL port (465) is used.
So that means that SMTP_SSL is used for connections where SSL is
present from the start and not when STARTTLS is used to upgrade the
connection to a secure one.
The documentation of reportbug says: smtptls: Enables TLS encryption
for the SMTP connection, using STARTTLS. This setting is ignored if
you connect to port 465, in which case SSL/TLS will always be used.
So either the documentation is wrong, of the code is.
The following python code works:
>>> smtp = smtplib.SMTP('mail-submit.debian.org',587)
>>> smtp.ehlo()
(250, b'stravinsky.debian.org Hello eriador.bigon.be
[2a02:a03f:65c5:3301:a912:aba9:d92d:4965]\nSIZE
104857600\n8BITMIME\nCHUNKING\nSTARTTLS\nSMTPUTF8\nHELP')
>>> smtp.starttls()
(220, b'TLS go ahead')
>>> smtp.quit()
(221, b'stravinsky.debian.org closing connection')
>>>
While this is not:
>>> smtplib.SMTP_SSL('mail-submit.debian.org',587)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.11/smtplib.py", line 1050, in __init__
SMTP.__init__(self, host, port, local_hostname, timeout,
File "/usr/lib/python3.11/smtplib.py", line 255, in __init__
(code, msg) = self.connect(host, port)
File "/usr/lib/python3.11/smtplib.py", line 341, in connect
self.sock = self._get_socket(host, port, self.timeout)
^^
File "/usr/lib/python3.11/smtplib.py", line 1057, in _get_socket
new_socket = self.context.wrap_socket(new_socket,
File "/usr/lib/python3.11/ssl.py", line 517, in wrap_socket
return self.sslsocket_class._create(
^
File "/usr/lib/python3.11/ssl.py", line 1108, in _create
self.do_handshake()
File "/usr/lib/python3.11/ssl.py", line 1383, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1006)
>>>From 19b99e6c66c5febbcf590846cf29f824bc1c1440 Mon Sep 17 00:00:00 2001
From: Laurent Bigonville
Date: Fri, 26 Jan 2024 13:56:09 +0100
Subject: [PATCH] Fix issue when sending mails using SSL/STARTTLS
The hostname passed to smtplib should not contain the port, this
hostname is used to verify the SSL certificate.
Closes: #926900
---
reportbug/submit.py | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/reportbug/submit.py b/reportbug/submit.py
index 0daaad4..94a30bf 100644
--- a/reportbug/submit.py
+++ b/reportbug/submit.py
@@ -446,6 +446,11 @@ def send_report(body, attachments, mua, fromaddr, sendto, ccaddr, bccaddr,
tryagain = True
refused = None
retry = 0
+_smtphost = smtphost.split(':')[0]
+try:
+smtpport = smtphost.split(':')[1]
+except IndexError:
+smtpport = 25
while tryagain:
tryagain = False
ewrite("Connecting to %s via SMTP...\n", smtphost)
@@ -453,14 +458,14 @@ def send_report(body, attachments, mua, fromaddr, sendto, ccaddr, bccaddr,
conn = None
# if we're using reportbug.debian.org, send mail to
# submit
-if smtphost.lower() == 'reportbug.debian.org':
-conn = smtplib.SMTP(smtphost, 587)
-elif smtphost.endswith(':465'):
+if _smtphost.lower() == 'reportbug.debian.org':
+conn = smtplib.SMTP(_smtphost, 587)
+elif smtpport == 465:
# ignore smtptls setting since port 465 implies SSL
smtptls = None
-conn = smtplib.SMTP_SSL(smtphost)
+conn = smtplib.SMTP_SSL(_smtphost, 465)
else:
-conn = smtplib.SMTP(smtphost)
+conn = smtplib.SMTP(_smtphost, smtpport)
response = conn.ehlo()
if not (200 <= response[0] <= 299):
conn.helo()
--
2.43.0
Bug#1061569: spam: reportbug test
Package: spam Severity: normal Test, please disregard
Bug#926900: sslv3 alert illegal parameter
When looking at the documentation of smtplib (the python library used
here), it says:
An SMTP_SSL instance behaves exactly the same as instances of SMTP.
SMTP_SSL*should be used for situations where SSL is required from the beginning
of the connection and using starttls() is not appropriate*.
If host is not specified, the local host is used. If port is zero, the standard
SMTP-over-SSL port (465) is used.
So that means that SMTP_SSL is used for connections where SSL is present
from the start and not when STARTTLS is used to upgrade the connection
to a secure one.
The documentation of reportbug says: smtptls: Enables TLS encryption
for the SMTP connection, using STARTTLS. This setting is ignored if you
connect to port 465, in which case SSL/TLS will always be used.
So either the documentation is wrong, of the code is.
The following python code works:
smtp = smtplib.SMTP('mail-submit.debian.org',587)
smtp.ehlo()
(250, b'stravinsky.debian.org Hello eriador.bigon.be
[2a02:a03f:65c5:3301:a912:aba9:d92d:4965]\nSIZE
104857600\n8BITMIME\nCHUNKING\nSTARTTLS\nSMTPUTF8\nHELP')
smtp.starttls()
(220, b'TLS go ahead')
smtp.quit()
(221, b'stravinsky.debian.org closing connection')
While this is not:
smtplib.SMTP_SSL('mail-submit.debian.org',587)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.11/smtplib.py", line 1050, in __init__
SMTP.__init__(self, host, port, local_hostname, timeout,
File "/usr/lib/python3.11/smtplib.py", line 255, in __init__
(code, msg) = self.connect(host, port)
File "/usr/lib/python3.11/smtplib.py", line 341, in connect
self.sock = self._get_socket(host, port, self.timeout)
^^
File "/usr/lib/python3.11/smtplib.py", line 1057, in _get_socket
new_socket = self.context.wrap_socket(new_socket,
File "/usr/lib/python3.11/ssl.py", line 517, in wrap_socket
return self.sslsocket_class._create(
^
File "/usr/lib/python3.11/ssl.py", line 1108, in _create
self.do_handshake()
File "/usr/lib/python3.11/ssl.py", line 1383, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1006)
Bug#926900: Processed: severity of 926900 is serious
Le 25/01/24 à 16:04, Sandro Tosi a écrit : Well I raised this bug to serious as 1) I think these days, having non functional SSL is a real problem 2) mail-submit.debian.org (the SMTP server that can be used by DD to send mail with DKIM signature) is triggering this error. We can argue over the severity, I think that this should be fixed ASAP https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/doc/README.Users?ref_type=heads#L200-202 I'm not sure why you are pointing me to this? The problem is that reportbugs is not happy when trying to connect to some SMTP servers when using "smtptls" depending of their configuration, NOTHING to do with the BTS. The SMTP server I mentioned here is just an example AND it works perfectly with the openssl command: $ openssl s_client -connect mail-submit.debian.org:587 -starttls smtp CONNECTED(0003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = stravinsky.debian.org verify return:1 --- Certificate chain 0 s:CN = stravinsky.debian.org i:C = US, O = Let's Encrypt, CN = R3 a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Dec 2 00:46:54 2023 GMT; NotAfter: Mar 1 00:46:53 2024 GMT 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 i:O = Digital Signature Trust Co., CN = DST Root CA X3 a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT --- Server certificate -BEGIN CERTIFICATE- MIIGDzCCBPegAwIBAgISBLG1+0K75F9l9yqzoMGdBCvFMA0GCSqGSIb3DQEBCwUA MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD EwJSMzAeFw0yMzEyMDIwMDQ2NTRaFw0yNDAzMDEwMDQ2NTNaMCAxHjAcBgNVBAMT FXN0cmF2aW5za3kuZGViaWFuLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCC AgoCggIBALtI7AqU8JfQYct7WM69VCUQo1trInbUPVZ61i4Nmqa7nzCCw8C+4GkF +R8PQhjX3rGjK8NpLNruP+e7YbzrxR69OL9kZwXDFLhAwMn6OJ8UzoHwSeYstBLY mHxBcuy+dDVsE9oZQXFqT+mpEPGhAR8ynmzekGpfItiFLX8LmS36QKUnL4es2v3V jfhsZXNoS5dPM53nzuRaB3s2Vp7HAIxbT4PijEMTsfE0qdG3a5Qok5U/S+uE7fix A3nQbCd+qvAIb0mhoedpUmiCfBUVpWFl6NLdiJxiKTJdH2f0F8xB9l/OnE8NlpXu cqNP+wiw9AknBjH4xKYJP4BUVLlL4C5qiEvuIpAkqi4/EqHwWK+Z5njZfq7mWuSY 8fepsMiLxuMdvJCCg7T/bHrM7hFRyUewYvk/xFqYPEGW+Tv7kdwMU/CsiiGzAt6b k6hfftixOJbguLFAnKRgvNy3cB5ZQ/ehOEjGTaF952lJgDPYOnUL8iO+hd9lkPJJ JfRHpEZHUZ1U0T0vR9mEFPGF5rO5+NvlCImTyeLvVxFXdtoxVGApl9R9lxVXQHZI mGivYdPlDGpBSxwxEN9AObpl/QelL8MR5eLQfjXN86sUTR66MgtCQ4/GJs+l69Wv hFTBfGn1eDEo10I9qJVToV+5an0qWFPfH4q8/FZP/+wdEGwJgYHNAgMBAAGjggIv MIICKzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF BwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFHn9eJOpQZ+x7hjjPihPC4UuBaxl MB8GA1UdIwQYMBaAFBQusxe3WFbLrlAJQOYfr52LFMLGMFUGCCsGAQUFBwEBBEkw RzAhBggrBgEFBQcwAYYVaHR0cDovL3IzLm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAC hhZodHRwOi8vcjMuaS5sZW5jci5vcmcvMDgGA1UdEQQxMC+CFm1haWwtc3VibWl0 LmRlYmlhbi5vcmeCFXN0cmF2aW5za3kuZGViaWFuLm9yZzATBgNVHSAEDDAKMAgG BmeBDAECATCCAQQGCisGAQQB1nkCBAIEgfUEgfIA8AB1ADtTd3U+LbmAToswWwb+ QDtn2E/D9Me9AA0tcm/h+tQXAAABjCg1DJsAAAQDAEYwRAIgd8qYrzL27ecIMX5T VUz9bqJGIwyPsl3ke4fEy2PFPlkCIFmY9E6jXE8gFLrOVV9lFSJN6MoRWY9mYg9Z a1xNMaSqAHcA7s3QZNXbGs7FXLedtM0TojKHRny87N7DUUhZRnEftZsAAAGMKDUM rgAABAMASDBGAiEAykZgWprc6hA/rahTqXrU0jYyJKiceZly6WZGjhcfrwYCIQC4 tG+C8PJCr5QVhOU+MkNqHM2vXvZ/pOkMg8iN4oFzKzANBgkqhkiG9w0BAQsFAAOC AQEAVKPeYIZ6ed64BjO8v2rwOw3H+bDO5gO13MV79FvJrS+7T4Lkw7poUprN9Iv1 VpAgq3g8P6mAKwBgo+zi00eQjYwtP/cdMQ1KiUDdtadCAsjgopsJ/Aucdd41wMV8 wPlVh60+VdrF3xBlxLnVLydUmrnI2PYTfzH1w/b47Jh48ITFRfbnHo0oXI4rUnEA Bi4IhoGJCrSD8TyCHfeQzd1xMnIwB/Q6YAin716C3HlW486AyrlPkpSrag4YSNoW eZUF8fucmRdYFQdOXE2kAVR11YK/uPvGd+b+MyX1RAx7Bd1TFUkdOziIgTMfC9Wb bdUPIa+wZcviKUDRO45Y2Dl8NA== -END CERTIFICATE- subject=CN = stravinsky.debian.org issuer=C = US, O = Let's Encrypt, CN = R3 --- Acceptable client certificate CA names C = NA, ST = NA, L = Ankh Morpork, O = Debian SMTP, OU = Debian SMTP CA, CN = Debian SMTP CA, emailAddress =hostmas...@puppet.debian.org Requested Signature Algorithms: RSA+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:Ed448:RSA+SHA512:RSA-PSS+SHA512:RSA-PSS+SHA512:ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1 Shared Requested Signature Algorithms: RSA+SHA256:RSA-PSS+SHA256:RSA-PSS+SHA256:ECDSA+SHA256:Ed25519:RSA+SHA384:RSA-PSS+SHA384:RSA-PSS+SHA384:ECDSA+SHA384:Ed448:RSA+SHA512:RSA-PSS+SHA512:RSA-PSS+SHA512:ECDSA+SHA512 Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 5584 bytes and written 467 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 4096 bit This TLS version forbids renegotiation. Compression:
Bug#1061444: pcscd: GDM user is NOT authorized for action: access_pcsc
Package: pcscd Version: 2.0.1-1 Severity: normal X-Debbugs-Cc: debian-gtk-gn...@lists.debian.org Hello, When looking at the logs of pcscd, I see the following messages: jan 22 09:47:37 edoras pcscd[1663]: auth.c:125:IsClientAuthorized() Error in authorization: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Process not found jan 22 09:47:37 edoras pcscd[1663]: 0031 auth.c:143:IsClientAuthorized() Process 1565 (user: 115) is NOT authorized for action: access_pcsc It seems that GDM is not allowed to talk to pcscd. GDM has the functionality to detect whether there is a smartcard in the reader and then use the gdm-smartcard PAM service instead of the gdm-password one to perform login. I guess that GDM should be whitelisted to allow it to use pcscd? Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.11-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages pcscd depends on: ii init-system-helpers 1.66 ii libc6 2.37-13 ii libccid [pcsc-ifd-handler] 1.5.5-1 ii libglib2.0-02.78.3-1 ii libpcsclite12.0.1-1 ii libpolkit-gobject-1-0 124-1 ii libsystemd0 255.2-4 ii libudev1255.2-4 pcscd recommends no packages. Versions of packages pcscd suggests: ii systemd 255.2-4 -- no debconf information
Bug#1059922: nut-server: upsd fails to start since version 2.8.1
Le 12/01/24 à 12:46, Jörg-Volker Peetz a écrit : Hello Laurent, Hello Jörg, Thanks for your reply [...] Concerning the loopback (127.0.0.1/::1) interface, here is the output of the command 'ip ad': 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 I disabled IPv6 on my system (the linux kernel is locally configured and compiled). Ssh has no problems on the loopback device, i.e., For debugging purpose, could you try to re-enable IPv6 in the kernel and check that the lo interface has the ::1 address assign to it and then try again? Kind regards, Laurent Bigonville
Bug#1059922: nut-server: upsd fails to start since version 2.8.1
severity 1059922 important thanks > Dear Laurent Bigonville, Hello Jörg, > with version 2.8.0-7 an EATON UPS connected to a debian computer via > USB was working in standalone mode as expected. The only change in the > config files was in /etc/nut/ups.conf where I added the following lines: > > [Eaton] > driver = usbhid-ups > port = auto > vendorid = 0463 > pollfreq = 30 > > After the upgrade to version 2.8.1-1 the upsd daemon would fail to > start. The output in /var/log/syslog is > > upsd[12132]: not listening on ::1 port 3493 > upsd[12132]: listening on 127.0.0.1 port 3493 > upsd[12132]: no listening interface available > > instead of > > upsd[12553]: listening on 127.0.0.1 port 3493 > upsd[12553]: not listening on ::1 port 3493 > upsd[12553]: Connected to UPS [Eaton]: usbhid-ups-Eaton > upsd[12555]: Startup successful > > for the working version 2.8.0. > Any ideas? Could you please attach the other configuration files here (please check for clear-text passwords)? Do you have the loopback (127.0.0.1/::1) interface properly working? I cannot reproduce this at home where I have also an EATON UPS Kind regards, Laurent Bigonville
Bug#1060378: cups-daemon: apparmor denies net_admin capability
Package: cups-daemon Version: 2.4.7-1 Severity: normal Hello, I see a lot of denials from apparmor regarding net_admin capability: type=AVC msg=audit(1704872737.703:1422): apparmor="DENIED" operation="capable" class="cap" profile="/usr/sbin/cupsd" pid=149384 comm="cupsd" capability=12 capname="net_admin" Not too sure what part requires it, but I guess it should be either allowed or the audit trail should be suppressed Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.9-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups-daemon depends on: ii adduser3.137 ii bc 1.07.1-3+b1 ii init-system-helpers1.66 ii libavahi-client3 0.8-13+b1 ii libavahi-common3 0.8-13+b1 ii libc6 2.37-13 ii libcups2 2.4.7-1+b1 ii libdbus-1-31.14.10-4 ii libgssapi-krb5-2 1.20.1-5 ii libpam0g 1.5.2-9.1+b1 ii libpaper1 1.1.29 ii libsystemd0255.2-4 ii procps 2:4.0.4-2+b1 ii ssl-cert 1.1.2 ii sysvinit-utils [lsb-base] 3.08-5 Versions of packages cups-daemon recommends: ii avahi-daemon 0.8-13+b1 ii colord1.4.6-5 ii cups-browsed 1.28.17-3+b1 ii ipp-usb 0.9.23-1+b7 Versions of packages cups-daemon suggests: ii cups 2.4.7-1+b1 pn cups-bsd ii cups-client2.4.7-1+b1 ii cups-common2.4.7-1 ii cups-filters 1.28.17-3+b1 pn cups-pdf ii cups-ppdc 2.4.7-1+b1 ii cups-server-common 2.4.7-1 pn foomatic-db-compressed-ppds | foomatic-db ii ghostscript10.02.1~dfsg-2 ii poppler-utils 22.12.0-2+b1 pn smbclient ii udev 255.2-4 -- no debconf information
Bug#1056988: libvirt0: Wrong usage of ${binary:Version}
Source: libvirt
Version: 9.9.0-1
Severity: normal
Hello,
libvirt0 Recommends libvirt-l10n with the version equal to ${binary:Version}
But libvirt-l10n is an arch:all package, the version should be equal to
${source:Version}
Kind regards,
Laurent Bigonville
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1056642: wireshark: Mix of QT5 and QT6 dependencies
Package: wireshark Version: 4.2.0-1 Severity: normal Hello, It seems that the wireshark package has a mix of QT5 and QT6 dependencies: Depends: libc6 (>= 2.34), libgcc-s1 (>= 3.0), libgcrypt20 (>= 1.10.0), libglib2.0-0 (>= 2.75.3), libminizip1, libnl-3-200 (>= 3.2.21), libnl-genl-3-200 (>= 3.2.7), libnl-route-3-200 (>= 3.2.7), libpcap0.8 (>= 1.5.1), libqt6core5compat6 (>= 6.2.1), libqt6core6 (>= 6.4.0), libqt6gui6 (>= 6.4.0), libqt6multimedia6 (>= 6.2.1), libqt6printsupport6 (>= 6.1.2), libqt6widgets6 (>= 6.3.0), libspeexdsp1 (>= 1.2.1), libstdc++6 (>= 13.1), libwireshark17 (>= 4.1.1), libwiretap14 (>= 4.1.0), libwsutil15 (>= 4.1.1rc0), wireshark-common (= 4.2.0-1), libqt5svg5 Recommends: libqt5multimedia5-plugins I guess that both libqt5svg5 and libqt5multimedia5-plugins should be updated to their QT6 counter parts? Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wireshark depends on: ii libc62.37-12 ii libgcc-s113.2.0-6 ii libgcrypt20 1.10.2-3 ii libglib2.0-0 2.78.1-4 ii libminizip1 1:1.3.dfsg-3 ii libnl-3-200 3.7.0-0.2+b1 ii libnl-genl-3-200 3.7.0-0.2+b1 ii libnl-route-3-2003.7.0-0.2+b1 ii libpcap0.8 1.10.4-4 ii libqt5svg5 5.15.10-2 ii libqt6core5compat6 6.4.2-4 ii libqt6core6 6.4.2+dfsg-19 ii libqt6gui6 6.4.2+dfsg-19 ii libqt6multimedia66.4.2-11 ii libqt6printsupport6 6.4.2+dfsg-19 ii libqt6widgets6 6.4.2+dfsg-19 ii libspeexdsp1 1.2.1-1 ii libstdc++6 13.2.0-6 ii libwireshark17 4.2.0-1 ii libwiretap14 4.2.0-1 ii libwsutil15 4.2.0-1 ii wireshark-common 4.2.0-1 Versions of packages wireshark recommends: ii libqt5multimedia5-plugins 5.15.10-2 wireshark suggests no packages. -- no debconf information
Bug#808940: ITP: terraform -- tool for managing cloud infrastructure
retitle 808940 ITP: opentofu -- tool for managing cloud infrastructure thanks On Thu, 24 Dec 2015 14:08:40 +0100 Daniel Stender wrote: Hello, > * Package name : terraform > Version : 0.6.8 > Upstream Author : Mitchell Hashimoto > * URL : https://terraform.io/ > * License : MPL-2.0 > Programming Lang: Go > Description : tool for managing cloud infrastructure > > Terraform is a tool for launching complex infrastructure like from cloud providers > like AWS or DigitlOcean. Like the other tools from HashiCorp (Vagrant, Packer etc.) > a simple CLI based program which is very easy to use, employing configuration files > for the needed setups. For more info, please see the documentation and quick intro > on the site. > Now that hashicorp has changed the licence of their software BSL, I guess that this RFP should be changed to package opentofu instead? https://opentofu.org/
Bug#1040838: libblockdev: Please build the "tools" and create a -tools package
Source: libblockdev Version: 3.0.1-1 Severity: wishlist Hello, The libblockdev source package contains two "tools" that are currently not built. One for them is "vfat-resize", that looks like an intresting feature to have? Kind regards, Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-2-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1029095: libselinux: claim /run/setrans directory
On Tue, 17 Jan 2023 17:44:13 +0100 =?UTF-8?Q?Christian_G=C3=B6ttsche?= wrote: Hello Christian, > Libselinux by default, since Debian does not specify DISABLE_SETRANS > at compile time, tries to translate security contexts within non-raw > interfaces, e.g. getfilecon(3). The purpose is to translate MCS/MLS > labels into human readable via mcstransd(8). The translation happens > via communication over the public accessible UNIX socket > /var/run/setrans/.setrans-unix, created by mcstransd(8). mcstransd(8) > however is not installed by default, not a dependency of another > package, nor recommended or suggested by one. Thus mcstransd(8) is > probably not running on many (most?) SELinux enabled systems and > thereby the directory /var/run/setrans is not created. This leaves > the opportunity for (compromised) programs to create it and the UNIX > socket to take control of the security context translation. It might > not be prevented by the SELinux policy since most daemons are allowed > to create entries in /var/run and UNIX socket communication between > daemons is common. As a solution the directory /var/run/setrans > should be created at boot by a trusted party with the default context > according to the loaded policy (e.g. setrans_runtime_t), which no > other daemon than mcstransd(8) should have the permission to create > sockets inside. For example Fedora uses the tmpfiles.d(5) snippet: > > d /run/setrans 0755 root root I'm wondering if that couldn't be done directly by the systemd package instead of the libselinux1, that might avoid us the need to introduce a new libselinux-common package or headache in the (unlikely?) case there a soname change to the libselinux library. Note that we might need to remove the RuntimeDirectory=setrans option in the mcstrans.service to avoid conflict (but that might be for the next debian release) If that's OK for you I'll coordinate with the debian systemd maintainer Kind regards, Laurent
Bug#1037478: ca-certificates-java: Loop in the execution of the trigger
Package: ca-certificates-java Version: 20230103 Severity: serious Hello, While updating today, I got the following error: dpkg: boucle détectée durant le traitement des actions différées : listes des paquets qui en sont responsables (normalement) : ca-certificates-java -> ca-certificates-java paquets bloqués par le traitement impossible d'actions différées requises : ca-certificates-java: update-ca-certificates-java: /usr/lib/jvm libc-bin: ldconfig dictionaries-common: aspell-autobuildhash There seems to be a loop in the trigger execution Kind regards Laurent Bigonville -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages ca-certificates-java depends on: ii ca-certificates 20230311 ii openjdk-11-jre-headless [java8-runtime-headless] 11.0.19+7-1 ca-certificates-java recommends no packages. ca-certificates-java suggests no packages. -- Configuration Files: /etc/default/cacerts [Errno 13] Permission non accordée: '/etc/default/cacerts' -- no debconf information
Bug#1035076: plymouth: Plymouth package has defective hard-dependency on systemd
Le 29/04/23 à 15:37, Faulk Johnny a écrit :
I am not saying to remove the systemd dependency. I am saying that
changing "systemd," to "systemd | elogind" under the control section
for the plymouth package in particular, NOT the build dependencies,
thus allowing installation on (and forcing a dependency on) either one
of them. Those who use a no-systemd system know full well there is a
risk, seeing as it's a pretty deliberate act to begin with in Debian.
Changing it as described above would have no affect at all on systemd
systems, as it would still pull in systemd and enforce that need.
Please reconsider this course of action.
The fact that plymouth package is depending on systemd has nothing to do
with the fact that it requires (e)logind (it actually doesn't, plymouth
runs at early boot and has nothing to do with a user session).
As said the dependency is needed because plymouth requires some udev
rules (namely /usr/lib/udev/rules.d/71-seat.rules) and tags to properly
detect the framebuffer/drm devices.
So as long at the rules file is shipped, in systemd package, plymouth
will have that dependency.
On Sat, Apr 29, 2023 at 6:25 AM, Laurent Bigonville
Like explained in bug #1035076, the fact that systemd is pulled by
the
plymouth package doesn't mean you cannot use it with an other
initsystem
on debian, the package that actually changes the default
initsystem is
"systemd-sysv", not "systemd"
Removing the dependency might break plymouth at it requires some udev
rules files that are shipped by the systemd package (the rules are
used
to tag the framebuffer devices/heads installed on the machines).
So removing that could break some setup
Kind regards,
Laurent Bigonville
Bug#1035076: plymouth: Plymouth package has defective hard-dependency on systemd
tag 1035076 + wontfix thanks Le 29/04/23 à 00:10, john faulk a écrit : Dear Maintainer, Hello, The Plymouth Package has a hard-dependency on systemd for installation. This should not be the case, seeing as there are initscripts present for it. I have tested a simple fix where elogind is added in the source control file as an alternative to systemd's dependency, and it has worked every time I have tried it. This will allow non-systemd users to use plymouth, and is a very simple fix. Like explained in bug #1035076, the fact that systemd is pulled by the plymouth package doesn't mean you cannot use it with an other initsystem on debian, the package that actually changes the default initsystem is "systemd-sysv", not "systemd" Removing the dependency might break plymouth at it requires some udev rules files that are shipped by the systemd package (the rules are used to tag the framebuffer devices/heads installed on the machines). So removing that could break some setup Kind regards, Laurent Bigonville
Bug#1031152: system-config-printer: unlock button in system-config-printer provides no elevated permissions dialog
On Sun, 12 Feb 2023 09:06:02 -0500 Alexis wrote: [...] > > > * What was the outcome of this action? > > The following error was thrown: > > Gtk-WARNING **: 08:47:30.475: Error acquiring permission: Failed to acquire permission for action-id org.opensuse.cupspkhelper.mechanism.all-edit Do you have the cups-pk-helper package installed? system-config-printer-common already recommends that package. The definition of Recommends is: "This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations.", so you should probably also install recommended packages. Kind regards, Laurent Bigonville
Bug#1034223: powerman: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
severity 1034223 important thanks On Tue, 11 Apr 2023 16:42:32 +0200 Andreas Henriksson wrote: > Hello Laurent Bigonville, > > On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote: > > Package: powerman > > Version: 2.3.27-2 > > Severity: serious > > Tags: sid bookworm > > User: debhel...@packages.debian.org > > Usertags: systemd-files-in-usr-bookworm > > > > Dear Maintainer, > > > > It seems that your package powerman is shipping files (.service, .socket or > > .timer) in /usr/lib/systemd/system. > > > > This is not supported by the version of dh_installsystemd/debhelper currently > > in unstable and bookworm (See: #1031695). That means that currently your > > service might not be enabled at boot and/or started as expected. > [...] > > Note that debian/rules has: > > ``` > override_dh_installinit: > dh_installinit --no-start --no-enable > > override_dh_installsystemd: > dh_installsystemd --no-start --no-enable > ``` > > So do you agree that the severity of this bug report should be downgraded > (maybe even closed)? I think severity can be downgraded (to "important"?), this is still a problem as systemctl daemon-reload is not called, but at least there will be surprise after a reboot.
Bug#1034340: ltunify: 0.3-1
Package: ltunify Version: 0.3-1 Severity: normal Hello, The udev rules file starts with the following: # skip actual unified devices, only consider the receiver DRIVERS=="logitech-djdevice", GOTO="not_unify_recv" For what I understand only the permissions of reciver should be modified But for what I can see, the permissions of the hidraw device of my mouse are also modified: $ ls -la /dev/hidraw* [...] crw-rw+ 1 root root 248, 3 13 avr 10:15 /dev/hidraw3 crw-rw+ 1 root root 248, 4 13 avr 10:15 /dev/hidraw4 [259919.846547] logitech-djreceiver 0003:046D:C52B.0034: hiddev0,hidraw3: USB HID v1.11 Device [Logitech USB Receiver] on usb-:00:14.0-1.1.4/input2 [259919.976009] logitech-hidpp-device 0003:046D:101A.0035: input,hidraw4: USB HID v1.11 Mouse [Logitech Performance MX] on usb-:00:14.0-1.1.4/input2:2 So that doesn't seem to be right. When running udevadm info on the two devices, I don't see the driver being displayed, so I think that the matching based on the driver is not working. Kind regards, Laurent Bigonville -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1034337: ltunify: udev not triggered after installation
Package: ltunify Version: 0.3-1 Severity: normal Hello, It seems that the package is installing a udev rules file, but udev is not (re)triggered after installation. You should probably add something like that (to be tested) in the postinst script: udevadm control --reload || true udevadm trigger --subsystem-match=hidraw --action=change || true Kind regards, Laurent Bigonville -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1034055: fwknop-apparmor-profile: AppArmor profile installed in systemd system service path
Le 7/04/23 à 20:19, Francois Marier a écrit : On 2023-04-07 at 07:23:07, Laurent Bigonville (bi...@debian.org) wrote: It seems that you install the apparmor profile in the path for systemd system service The following change should be reverted: https://salsa.debian.org/debian/fwknop/-/commit/d3a5aaef39fedc1bb94e26921afbf63f79b31af7 Hm, that does look like a mistake. I don't remember what might have caused me to make that change. I guess the apparmor profile hasn't been in use for a while then. It seems like it's too late in the release process to re-add it in bookworm. Here's what I'm thinking of doing: - move it to /usr/share/apparmor/extra-profiles/ (so it's not turned on by default) for bookworm - move it back to /etc/apparmor.d/ after bookworm Alternatively, I could also not change anything for bookworm since it's not enabled as an AppArmor profile and it will be ignored as a systemd unit file. What do you think? Sorry for the late answer. I see that you moved the file to /usr/share/apparmor/extra-profiles/, for now it's OK I guess, might be indeed be too late to enable the profile so late in the development cycle An other option for bookworm+1 is to move the file back to /etc/apparmor.d/ AND merge the profile back in the main package so it's installed along side the daemon and kill fwknop-apparmor-profile (that package only ships one file AFAICS) Apparmor profile can be put in complain/non-enforcing mode if the user really wants to.
Bug#1034249: pvpgn: Do not exit the postinst script early if not in "configure" state
Package: pvpgn Version: 1.8.5-3 Severity: important Hello, Currently the postinst maintainer script exits early if it is not run in "configure" mode: # # Skip, if we are not in "configure" state # if [ "$1" != "configure" ]; then echo "I: Skipping configuration" exit 0 fi DIRS="bak/charinfo bak/charsave bnmail chanlogs charinfo charsave ladders reports status teams users" for DIR in $DIRS; do mkdir -p /var/lib/pvpgn/$DIR done INMHO, this is not good as debhelper snippets might not be properly executed (ie. the ones from dh_installsystemd or dh_installinit) The script should be changed to something like: DIRS="bak/charinfo bak/charsave bnmail chanlogs charinfo charsave ladders reports status teams users" if [ "$1" = "configure" ]; then for DIR in $DIRS; do mkdir -p /var/lib/pvpgn/$DIR done fi Kind regards, Laurent Bigonville -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pvpgn depends on: ii libc6 2.36-9 pn libcdb1 pn libmariadb3 pn libpq5 ii libsqlite3-0 3.40.1-2 ii sysvinit-utils [lsb-base] 3.06-4 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages pvpgn recommends: pn tinycdb ii wget 1.21.3-1+b2 Versions of packages pvpgn suggests: pn default-mysql-server | virtual-mysql-server pn fortune
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
FTR, I opened RC bugs against all the impacted packages so they will hopefully be fixed for bookworm See: https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debhelper%40packages.debian.org=systemd-files-in-usr-bookworm
Bug#1034055: fwknop-apparmor-profile: AppArmor profile installed in systemd system service path
Package: fwknop-apparmor-profile Version: 2.6.10-13 Severity: serious Hello It seems that you install the apparmor profile in the path for systemd system service The following change should be reverted: https://salsa.debian.org/debian/fwknop/-/commit/d3a5aaef39fedc1bb94e26921afbf63f79b31af7 Kind regards, Laurent Bigonville -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fwknop-apparmor-profile depends on: pn fwknop-server fwknop-apparmor-profile recommends no packages. fwknop-apparmor-profile suggests no packages.
Bug#1033999: webkit2gtk: FTBFS on hurd-i386 (disable GBM support)
Source: webkit2gtk Version: 2.39.1-1 Severity: important Tags: ftbfs Hello, It seems that webkit FTBFS again on hurd-i386 The issue seems to be the fact that libgbm is missing: -- Could NOT find GBM (missing: GBM_LIBRARIES GBM_INCLUDE_DIR) CMake Error at Source/cmake/OptionsGTK.cmake:403 (message): GBM is required for USE_GBM I guess that should be disabled on that arch? Kind regards, Laurent Bigonville -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1033045: librest-dev: Missing dependencies
Package: librest-dev Version: 0.9.1-4 Severity: serious Hello, It seems that librest-dev and librest-extras-dev are missing dependencies that are declared in the .pc files, like libjson-gib-dev and others. That should probably be fixed Kind regards, Laurent Bigonville -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages librest-dev depends on: ii gir1.2-rest-1.0 0.9.1-4 ii librest-1.0-00.9.1-4 pn libsoup-3.0-dev ii libxml2-dev 2.9.14+dfsg-1.1+b3 librest-dev recommends no packages. librest-dev suggests no packages.
Bug#1032183: libgusb-dev: missing dependency on libjson-glib-1.0-dev
On Wed, 1 Mar 2023 11:06:21 + Simon McVittie wrote: > Control: tags -1 + patch > > On Wed, 01 Mar 2023 at 10:52:44 +, Simon McVittie wrote: > > I'll send the obvious patch when I have a bug number. > > Attached, or available from > https://salsa.debian.org/efi-team/libgusb/-/merge_requests/6 Hello, Independently of whether the package should migrate to testing/bookworm now, could this bug be fixed? I think the necessary patches are in git, is it possible to upload? Kind regards, Laurent Bigonville
Bug#1032510: packagekit: pkcon what-provides application/x-keepass2 makes PK crash
Package: packagekit Version: 1.2.6-3 Severity: serious Hello, pkcon what-provides application/x-keepass2 makes PK crash: $ pkcon what-provides application/x-keepass2 Getting provides[=] Loading cache [=] Querying[=] e daemon crashed mid-transaction! Finished[ ] (0%) Stack trace of thread 10447: #0 0x7faf3ef75ccc __pthread_kill_implementation (libc.so.6 + 0x8accc) #1 0x7faf3ef26ef2 __GI_raise (libc.so.6 + 0x3bef2) #2 0x7faf3ef11472 __GI_abort (libc.so.6 + 0x26472) #3 0x7faf3c89d919 _ZN9__gnu_cxx27__verbose_terminate_handlerEv (libstdc++.so.6 + 0x9d919) #4 0x7faf3c8a8e1a _ZN10__cxxabiv111__terminateEPFvvE (libstdc++.so.6 + 0xa8e1a) #5 0x7faf3c8a8e85 _ZSt9terminatev (libstdc++.so.6 + 0xa8e85) #6 0x7faf3c8a90d8 __cxa_throw (libstdc++.so.6 + 0xa90d8) #7 0x7faf3c8a00e4 _ZSt19__throw_logic_errorPKc (libstdc++.so.6 + 0xa00e4) #8 0x7faf3e96cb3a _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC4IS3_EEPKcRKS3_ (libpk_backend_apt.so + 0x2cb3a) #9 0x7faf3e95d122 backend_what_provides_thread (libpk_backend_apt.so + 0x1d122) #10 0x5644cb0c7aca pk_backend_job_thread_setup (packagekitd + 0x23aca) #11 0x7faf3f5dbcfd g_thread_proxy (libglib-2.0.so.0 + 0x7ecfd) #12 0x7faf3ef73fd4 start_thread (libc.so.6 + 0x88fd4) #13 0x7faf3eff466c __clone3 (libc.so.6 + 0x10966c) This breaks GNOME ability to suggest which application to install when opening files. Feel free to downgrade the severity if you want. Kind regards, Laurent Bigonville -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages packagekit depends on: ii init-system-helpers 1.65.2 ii libappstream4 0.16.1-1 ii libapt-pkg6.0 2.6.0 ii libc6 2.36-8 ii libgcc-s1 12.2.0-14 ii libglib2.0-02.74.6-1 ii libglib2.0-bin 2.74.6-1 ii libgstreamer1.0-0 1.22.0-2 ii libpackagekit-glib2-18 1.2.6-3 ii libpolkit-gobject-1-0 122-3 ii libsqlite3-03.40.1-1 ii libstdc++6 12.2.0-14 ii libsystemd0 252.6-1 ii polkitd 122-3 Versions of packages packagekit recommends: ii packagekit-tools 1.2.6-3 ii systemd 252.6-1 Versions of packages packagekit suggests: ii appstream 0.16.1-1 -- no debconf information
Bug#1032406: /usr/bin/xgpsspeed: TypeError: 'km/h' is not a valid speed unit
Package: gpsd-clients Version: 3.22-4.1+b1 Severity: normal File: /usr/bin/xgpsspeed Hello, When running xgpsspeed on my machine, I get the following trace: Traceback (most recent call last): File "/usr/bin/xgpsspeed", line 1015, in Main( File "/usr/bin/xgpsspeed", line 652, in __init__ self.widget = NauticalSpeedometer( File "/usr/bin/xgpsspeed", line 305, in __init__ Speedometer.__init__(self, speed_unit) File "/usr/bin/xgpsspeed", line 87, in __init__ raise TypeError( TypeError: 'km/h' is not a valid speed unit Explicitly setting the speed unit with --speedunits kmh fixes the issue There seems to be an incompatibility between what's used in xgpsspeed and gps/clienthelpers.py Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages gpsd-clients depends on: ii gir1.2-gtk-3.0 3.24.36-4 ii gpsd-tools 3.22-4.1+b1 ii libbluetooth3 5.66-1 ii libc6 2.36-8 ii libdbus-1-3 1.14.6-1 ii libgps283.22-4.1+b1 ii libusb-1.0-02:1.0.26-1 ii python3 3.11.2-1 ii python3-cairo 1.20.1-5+b1 ii python3-gi 3.42.2-3+b1 ii python3-gi-cairo3.42.2-3+b1 ii python3-gps 3.22-4.1+b1 ii python3-matplotlib 3.6.3-1+b1 ii python3-serial 3.5-1.1 gpsd-clients recommends no packages. Versions of packages gpsd-clients suggests: ii gpsd 3.22-4.1+b1 -- no debconf information
Bug#1031506: darktable: Please adjust the architectures on which darktable is built
Source: darktable Version: 4.2.0-2 Severity: normal Hello, On x32 architecture, darktable FTBFS with the following error: 71 | #error "Unfortunately we only work on the 64-bit architectures amd64, ARMv8-A, PPC64 and riscv64." ATM, I see that ppc64 and riscv64 are not listed in the package architectures list. These should maybe be added. On the other side, x32 should maybe be removed Kr, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1017736: auditd: noise service shutdown of dispatcher plugins
On Fri, 19 Aug 2022 19:42:50 +0200 =?UTF-8?Q?Christian_G=C3=B6ttsche?= wrote: > From upstream report: https://github.com/linux-audit/audit-userspace/issues/272 > As mentioned in the upstream bug, I think that this should also be set upstream as on shutdown/reboot, systemd WILL stop auditd too I'm not sure that should be applied to debian only
Bug#1029760: evince: AppArmor prevents opening PDF files stored on Google drive
Package: evince
Version: 43.1-2+b1
Severity: important
Hello,
It seems that the AppArmor profile is not allowing evince to read file
accessed via the GVFS on Google drive (and probably other integrations)
I get the following denials:
type=AVC msg=audit(1674751821.962:528): apparmor="DENIED" operation="open"
profile="/usr/bin/evince"
name="/run/user/1000/gvfs/google-drive:host=example.com,user=foo/"
pid=11026 comm="EvJobScheduler" requested_mask="r" denied_mask="r" fsuid=1000
ouid=1000FSUID="bigon" OUID="bigon"
Adding the following rule is allowing me to read my files, but I'm not
sure that enough or consistant with the other rules (shouldn't write
access be allowed too?):
/{,var/}run/user/*/gvfs/** r,
Kind regards,
Laurent Bigonville
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages evince depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4
ii evince-common43.1-2
ii gsettings-desktop-schemas43.0-1
ii libatk1.0-0 2.46.0-4
ii libc62.36-8
ii libcairo-gobject21.16.0-7
ii libcairo21.16.0-7
ii libevdocument3-4 43.1-2+b1
ii libevview3-3 43.1-2+b1
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii libglib2.0-0 2.74.5-1
ii libgnome-desktop-3-2043.1-1
ii libgtk-3-0 3.24.36-2
ii libhandy-1-0 1.8.0-1
ii libpango-1.0-0 1.50.12+ds-1
ii libpangocairo-1.0-0 1.50.12+ds-1
ii libsecret-1-00.20.5-3
ii shared-mime-info 2.2-1
Versions of packages evince recommends:
ii dbus-user-session [default-dbus-session-bus] 1.14.4-1
Versions of packages evince suggests:
ii gvfs 1.50.3-1
pn nautilus-sendto
ii poppler-data 0.4.11-1
pn unrar
-- no debconf information
Bug#1028301: grub: grub-probe doesn't detect that file is on cryptfs on new installation
Package: grub-common Version: 2.06-7 Severity: serious File: /usr/sbin/grub-probe Hello, On a newly installed laptop, it seems that grub-probe is not able to detect that files are on an encrypted FS. New laptop: $ sudo grub-probe -t abstraction /usr/share/images/desktop-base/desktop-grub.png lvm $ sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme0n1 259:00 476,9G 0 disk ├─nvme0n1p1 259:10 512M 0 part /boot/efi ├─nvme0n1p2 259:20 488M 0 part /boot └─nvme0n1p3 259:30 476G 0 part └─nvme0n1p3_crypt 254:00 475,9G 0 crypt ├─new_laptop--vg-root254:10 27,9G 0 lvm / ├─new_laptop--vg-swap_1 254:20 976M 0 lvm [SWAP] ├─new_laptop--vg-home254:3040G 0 lvm /home └─new_laptop--vg-libvirt 254:4060G 0 lvm /var/lib/libvirt Old laptop: $ sudo grub-probe -t abstraction /usr/share/images/desktop-base/desktop-grub.png cryptodisk luks gcry_rijndael gcry_rijndael gcry_sha256 lvm $ sudo lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda8:01 0B 0 disk nvme0n1 259:00 476,9G 0 disk ├─nvme0n1p1 259:10 512M 0 part /boot/efi ├─nvme0n1p2 259:20 244M 0 part /boot └─nvme0n1p3 259:30 476,2G 0 part └─nvme0n1p3_crypt 254:00 476,2G 0 crypt ├─old_laptop--vg-root254:10 27,9G 0 lvm / ├─old_laptop--vg-swap_1 254:20 31,7G 0 lvm [SWAP] ├─old_laptop--vg-home254:30 120G 0 lvm /home ├─old_laptop--vg-sid_amd64_sbuild254:40 5G 0 lvm ├─old_laptop--vg-flatpak 254:5050G 0 lvm /var/lib/flatpak ├─old_laptop--vg-libvirt 254:6075G 0 lvm /var/lib/libvirt ├─old_laptop--vg-docker 254:7010G 0 lvm /var/lib/docker ├─old_laptop--vg-acng254:8010G 0 lvm /var/cache/apt-cacher-ng └─old_laptop--vg-buster_amd64_sbuild 254:90 5G 0 lvm Setting this as serious as this seems to be a regression, this at least breaks grub ability to display the theme wallpaper. Kind regards, Laurent Bigonville
Bug#968997: fwupdmgr: "Successfully" updates BIOS firmware, no effect on reboot
On Mon, 3 Oct 2022 21:48:42 +0100 Steve McIntyre wrote: > On Mon, Oct 03, 2022 at 09:22:02PM +0200, Vincent Bernat wrote: > > > >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. > > We've had problems in submitting shim 15.6 to Microsoft for > signing. We're working on a solution, but it's going to take a little > longer yet. Hello Steven, Sorry to insist (again), but do you have any news about this? We are slowly approaching the freeze for bookworm and having a fix for this looks quite important to me. Kind regards, Laurent Bigonville
Bug#1023530: nut: flaky autopkgtest: varying failures
On Sun, 6 Nov 2022 07:30:38 +0100 Paul Gevers wrote: > Dear maintainer(s), Hello Paul > I looked at the results of the autopkgtest of your package. I noticed > that it regularly fails (after the fix for bug #1019221). > > Because the unstable-to-testing migration software now blocks on > regressions in testing, flaky tests, i.e. tests that flip between > passing and failing without changes to the list of installed packages, > are causing people unrelated to your package to spend time on these > tests. > > Don't hesitate to reach out if you need help and some more information > from our infrastructure. It's impossible for me to reproduce this locally, can you still see that in the CI runs? For me this looks like a race condition, the test code already waits for 2 sec after the start of the nut daemon an drivers to be certain that everything is properly started. I can increase that sleep, but that's probably not the best solution. An other solution is to have a loop checking that the (dummy) driver is really connected, but I need to investigate how and I've no time ATM. Last solution could be to ask the release team to tag this bug as "bookworm-ignore" so it can be part of the upcoming release and try to fix this for the next one. WDYT? Kind regards, Laurent Bigonville
Bug#828903: auditd embeds a copy of libev
Hello, Le 15/12/22 à 17:08, Bastian Germann a écrit : On Tue, 28 Jun 2016 22:28:07 +0200 Nicolas Braud-Santoni wrote: The audit source package ships a (custom, patched) copy of libev. Moreover, it is not listed in the security team's list of code copies: https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=markup I discovered the issue while preparing a DEP5 copyright file for the audit source package, and more generally fixing all Lintian warnings while preparing a patch for #759604. I think this is an important issue and have included a patch. Would you please consider to apply this before the bookworm freeze? Do you think you could bring that upstream? Not sure we want to carry this patch forever
Bug#1024693: firefox: back/forward 2 fingers gesture not working
Package: firefox Version: 107.0-1 Severity: normal Hello, Since a few versions, firefox is supposed to support the back/forward 2 fingers gesture on wayland. This is working on my fedora work laptop and it's supposed to work on ubuntu as well, but not on my debian laptop https://www.omglinux.com/firefox-two-finger-swipe-back-coming-soon/ Not sure what's happening here Kind regards, Laurent Bigonville -- Package-specific info: -- Addons package information -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages firefox depends on: ii debianutils 5.7-0.4 ii fontconfig 2.13.1-4.5 ii libasound2 1.2.7.2-1 ii libatk1.0-0 2.46.0-4 ii libc62.36-5 ii libcairo-gobject21.16.0-6 ii libcairo21.16.0-6 ii libdbus-1-3 1.14.4-1 ii libdbus-glib-1-2 0.112-3 ii libevent-2.1-7 2.1.12-stable-5+b1 ii libffi8 3.4.4-1 ii libfontconfig1 2.13.1-4.5 ii libfreetype6 2.12.1+dfsg-3 ii libgcc-s112.2.0-9 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1 ii libglib2.0-0 2.74.1-2 ii libgtk-3-0 3.24.34-5 ii libnspr4 2:4.35-1 ii libnss3 2:3.85-1 ii libpango-1.0-0 1.50.10+ds-1 ii libstdc++6 12.2.0-9 ii libvpx7 1.12.0-1 ii libx11-6 2:1.8.1-2 ii libx11-xcb1 2:1.8.1-2 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxrandr2 2:1.5.2-2+b1 ii libxtst6 2:1.2.3-1.1 ii procps 2:3.3.17-7.1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages firefox recommends: ii libavcodec58 7:4.4.2-1+b3 ii libavcodec59 7:5.1.2-1 Versions of packages firefox suggests: pn fonts-lmodern pn fonts-stix | otf-stix ii libcanberra0 0.30-10 ii libgssapi-krb5-2 1.20.1-1 pn pulseaudio -- no debconf information
Bug#1019624: UPSONIC IRT-3K 2U broken by length checking in blazer_usb/nutdrv_qx
On Tue, 13 Sep 2022 10:19:24 +1000 "Trent W. Buck" wrote: Hello, > > Short version: > > 1. UPSONIC IRT-3K 2U speaks a variant of Q1 which omits final \r. > 2. nut 2.4 doesn't check for final \r, so it Just Works. > 3. nut 2.7 checks for final \r, cannot talk to my UPS. > 4. I fixed #3 but it's not very good. Do you think you could check whether nut 2.8.0 (currently in unstable) works with your UPS? Otherwise if the bug is still happening, could you please open a bug upstream if it's not already done? Kind regards, Laurent Bigonville
Bug#958036: nut-snmp: SNMPv3 with privacy method "AES" fails to communicate with UPS
On Fri, 17 Apr 2020 12:32:15 -0400 Wilfried Teiken wrote: > > Dear Maintainer, Hello Wilfried, > > when configuring SNMP as v3 with privacy enabled and "privProtocol = AES" in > /etc/nut/ups.conf for the UPS then the communication with the UPS will fail. > > The sympton is that on startup the driver will report: > - "Unknown mibs value: apcc" (with "mibs = apcc") > - "No supported device detected" (with "mibs = auto" > > Communication with "privProtocol = DES" works if the SNMP endpoint is configured > accordingly, so this only affects the "AES" setting. > > The underlying root cause is a length issue for the 'usmAESPrivProtocol' > oid value, causing the wrong privacy string being passed into the net-snmp > library caused by a #define that is leading to a sizeof() with a pointer > instead of the oid array. > > See attached patch for a fix. Could you please tell me if you are still experiencing this issue with the version 2.8.0 that is currently in debian unstable? I can see that the code to detect usmAESPrivProtocol/usmAES128PrivProtocol availability has changed. Also, in the build logs of version 2.7.14, I can see the compiler complain about the size of these types, while this warning is not present in version 2.8.0 I think that this is now fixed. Could you please confirm? Kind regards, Laurent Bigonville
Bug#1021384: ITP: low-memory-monitor -- Monitors low-memory conditions
Package: wnpp Severity: wishlist Owner: Laurent Bigonville X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: low-memory-monitor Version : 2.1 Upstream Author : Bastien Nocera * URL : https://gitlab.freedesktop.org/hadess/low-memory-monitor * License : GPL-3+ Programming Lang: C Description : Monitors low-memory conditions The Low Memory Monitor is an early boot daemon that will monitor memory pressure information coming from the kernel, and, first, send a signal to user-space applications when memory is running low, and then optionally activate the kernel's OOM killer when memory is running really low.
Bug#1021160: simple-scan: Please bump libhandy-1-dev build-dependency
Source: simple-scan Version: 42.0-1 Severity: important Hello, Currently, simple-scan package defines a build-dependency against libhandy-1-dev (>= 1.1.90), but the meson files requires libhandy-1-dev >= 1.6.0 libhandy-1-dev >= 1.6.0 is not available on on all architectures and it's probably a good idea to update the debian/control file and bump the version of the libhandy-1-dev build-dependency. Kind regards, Laurent Bigonville -- Package-specific info: -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1021040: tlog: FTBFS on non-linux architectures
Source: tlog Version: 12.1-1 Severity: important Tags: ftbfs patch Justification: fails to build from source (but built successfully in the past) Hello, tlog FTBFS on non-linux architectures because it tries to build systemd/journald support Disable journald support on non-linux architecture should fix this Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy diff -Nru tlog-12.1/debian/control tlog-12.1/debian/control --- tlog-12.1/debian/control2022-05-19 16:23:08.0 +0200 +++ tlog-12.1/debian/control2022-09-30 22:57:22.0 +0200 @@ -6,7 +6,7 @@ debhelper-compat (= 12), libcurl4-gnutls-dev, libjson-c-dev, - libsystemd-dev, + libsystemd-dev [linux-any], libutempter-dev, pkg-config, Rules-Requires-Root: no diff -Nru tlog-12.1/debian/rules tlog-12.1/debian/rules --- tlog-12.1/debian/rules 2022-05-19 16:23:08.0 +0200 +++ tlog-12.1/debian/rules 2022-09-30 22:57:22.0 +0200 @@ -8,12 +8,16 @@ DPKG_EXPORT_BUILDFLAGS = 1 -include /usr/share/dpkg/buildflags.mk +ifneq ($(DEB_HOST_ARCH_OS),linux) +DISABLE_JOURNAL:=--disable-journal +endif + %: dh $@ override_dh_auto_configure: dh_auto_configure -- \ - --enable-utempter + --enable-utempter $(DISABLE_JOURNAL) override_dh_auto_install: # dh_install -p libtlog0 lib/tlog/.libs/libtlog.so.0.0.0 usr/lib/$(DEB_HOST_MULTIARCH)/
Bug#978650: podman: please provide a default container registry for looking up short image names
Hello, Sorry for coming back to the topic here, but I (still) personally think that defining "unqualified-search-registries" with sensible default (dockerhub and quay.io?) is a better solution. For what I understand, the two arguments here against are 1) it's not up-to debian to choose the registries for the users 2) there are security concerns about using random images. IMVHO, it's still the role of a distribution to provide sensible defaults to their users (lot/all packages are already doing so today in the distribution). The fact that the package is adding that shortnames.conf file (with a selected subset of images) is actually forcing our users to use images (and not just repositories). With unqualified-search-registries set, podman WILL ask the user from where they want to pull the image from (currently nothing is asked), this would actually allow the user to have MORE control and clarity over the repository they uses. I also not sure what would happen if the package maintainer would change the content of that file to point to an other repository (let's say because of a dispute), the user would start pulling an image they are not expecting? With setting "unqualified-search-registries", the choice of the user is preserved. To that, I would also add that, AFAICS, debian is breaking expectation for users coming from other distributions here. So would it be possible to reconsider the solution here? Kind regards, Laurent Bigonville
Bug#1017372: #1017372 plymouth: reproducible builds: year and week embedded in .pc files
Le 22/09/22 à 21:02, Holger Levsen a écrit : hi Laurent, Hello Holger, what do you think of the proposed patch? for your convinience: (see https://bugs.debian.org/1017372 for more explainations but this is the diff) Subject: [PATCH] configure.ac: Avoid embedding the date in the version. Use the version from the last debian/changelog entry, otherwise the build will differ if built on a different year and week and from git builds vs. builds from source tarball. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 6e00c0c..0de1856 100644 --- a/configure.ac +++ b/configure.ac @@ -1,5 +1,5 @@ AC_INIT([plymouth], -m4_esyscmd_s([date +%y.%V.$(git rev-list $(git describe --abbrev=0)..HEAD --count) || echo 0]), +m4_esyscmd_s([dpkg-parsechangelog --show-field Version]), Thanks for the patch. I've modified the command line to 'dpkg-parsechangelog --show-field Version | sed -e 's/-[^-]*$//' | sed -e 's/^[0-9]*://'' to drop the epoch and debian revision from the version, and only keep the upstream one. (inspired from /usr/share/dpkg/pkg-info.mk) I also opened a bug upstream: https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/188 Kind regards, Laurent Bigonville
Bug#1020386: mesa: FTBFS on x32
Source: mesa Version: 21.0.0-1 Severity: important Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hello, mesa currently FTBFS on x32, with the following errors: dh_install -a dh_install: warning: Cannot find (any matches for) "usr/share/drirc.d/00-radv-defaults.conf" (tried in ., debian/tmp) dh_install: warning: mesa-vulkan-drivers missing files: usr/share/drirc.d/00-radv-defaults.conf dh_install: error: missing files, aborting make[1]: *** [debian/rules:228: override_dh_install] Error 25 That's probably happening because the amd vulkan driver is not built Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1017498: Plymouth Alternative Package Without Systemd Dependency
closes 1017498 severity 1017498 wishlist tags 1017498 + wontfix thanks On Wed, 17 Aug 2022 04:31:05 +0200 (CEST) truetec...@tutanota.com wrote: > When manually setting up an alternative init system such as OpenRC in Debian, the Plymouth boot splash cannot be used as the plymouth package has a hard dependency on SystemD. However, Plymouth can be configured to work without it either way as seen in Devuan. > > It might be that this requires a change in how the package is compiled, though I am not knowledgeable on the subject. However, seeing as other packages such as DBus are provided with separate non-Systemd variants, so there is precedent for that. > > I know that Systemd is the only officially supported init on Debian, but would it be possible to make this package usable on all systems? Aside from the eye-candy, it can make entering encryption passwords more legible. The fact that systemd is pulled by the plymouth package doesn't mean you cannot use it with an other initsystem on debian, the package that actually changes the default initsystem is "systemd-sysv", not "systemd" Removing the dependency might break plymouth at it requires some udev rules files that are shipped by the systemd package (the rules are used to tag the framebuffer devices/heads installed on the machines). I'm not planning to put extra work for this here.
Bug#1013630: cmake does not properly detect x32 architecture with nasm/yasm
Package: cmake Version: 3.23.2-1 Severity: important Tags: upstream Hello, Currently svt-av1 FTBFS on x32 with the following errror: [ 11%] Building ASM_NASM object Source/Lib/Common/ASM_SSE2/CMakeFiles/COMMON_ASM_SSE2.dir/intrapred_sse2.asm.o cd /<>/obj-x86_64-linux-gnux32/Source/Lib/Common/ASM_SSE2 && /usr/bin/yasm -DARCH_X86_64=1 -DEN_AVX512_SUPPORT=0 -DEXCLUDE_HASH=0 -DREPRODUCIBLE_BUILDS=1 -DSAFECLIB_STR_NULL_SLACK=1 -D_FORTIFY_SOURCE=2 -I/<>/. -I/<>/Source/API -I/<>/Source/Lib/Common/Codec -I/<>/Source/Lib/Common/C_DEFAULT -I/<>/Source/Lib/Common/ASM_SSE2 -DUNIX64 -f elf -o CMakeFiles/COMMON_ASM_SSE2.dir/intrapred_sse2.asm.o /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:57: warning: `rcx' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:57: error: undefined symbol `rcx' (first use) /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:57: error: (Each undefined symbol is reported only once.) /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:58: warning: `rdx' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:58: error: undefined symbol `rdx' (first use) /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:66: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:66: error: undefined symbol `rdi' (first use) /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:67: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:67: warning: `rsi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:67: error: undefined symbol `rsi' (first use) /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:68: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:68: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:68: warning: `rsi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:69: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:70: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:70: warning: `rsi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:81: warning: `rcx' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:87: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:88: warning: `rdi' is a register in 64-bit mode /<>/Source/Lib/Common/ASM_SSE2/intrapred_sse2.asm:88: warning: `rsi' is a register in 64-bit mode [...] As you can see, yasm is called with "-f elf" and not "-f elfx32" That should be fixed upstream Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages cmake depends on: ii cmake-data3.23.2-1 ii libarchive13 3.6.0-1 ii libc6 2.33-7 ii libcurl4 7.83.1-2 ii libexpat1 2.4.8-1 ii libgcc-s1 12.1.0-4 ii libjsoncpp25 1.9.5-4 ii librhash0 1.4.3-1 ii libstdc++612.1.0-4 ii libuv11.44.1-2 ii procps2:3.3.17-7+b1 ii zlib1g1:1.2.11.dfsg-4 Versions of packages cmake recommends: ii gcc 4:11.2.0-2 ii make 4.3-4.1 Versions of packages cmake suggests: pn cmake-doc pn cmake-format ii ninja-build 1.11.0-1 -- no debconf information
Bug#1011726: switcheroo-control: FTBFS: AssertionError: 0 != 1
severity 1011726 important thanks On Thu, 26 May 2022 08:13:24 +0200 Lucas Nussbaum wrote: > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. Hello, I cannot reproduce this on my laptop, not sure what happened I'll reduce the severity to important so the package is not removed from unstable for now Kind regards, Laurent Bigonville
Bug#1011159: qbs: FTBFS on hppa: '/usr/lib/qt5/bin/qdoc': No such file or directory
On Tue, 17 May 2022 17:54:50 + John David Anglin wrote: > Source: qbs > Version: 1.22.1-2 > Severity: normal > [...] > qdoc-qt5 is no longer built on hppa because it requires clang. > > If there is no way to work around this issue, maybe add qdoc-qt5 to > package dependencies. I guess an other option would be to disable the documentation generation when building arch:any packages as I think all the doc is installed in arch:all ones?
Bug#1013097: openh264: FTBFS on x32
On Fri, 17 Jun 2022 11:14:29 +0200 Bastian Germann wrote: > Control: reopen -1 > > The patch in https://github.com/cisco/openh264/issues/3545 does not affect the FTBFS. With ARCH=x32 set, the package builds fine locally
Bug#1013097: openh264: FTBFS on x32
input file `codec/common/x86/mc_chroma.o' is incompatible with i386:x64-32 output /usr/bin/ld: i386:x86-64 architecture of input file `codec/common/x86/mc_luma.o' is incompatible with i386:x64-32 output /usr/bin/ld: i386:x86-64 architecture of input file `codec/common/x86/satd_sad.o' is incompatible with i386:x64-32 output /usr/bin/ld: i386:x86-64 architecture of input file `codec/common/x86/vaa.o' is incompatible with i386:x64-32 output Here again there is a proble when calling nasm with the "-f elf64" flag: nasm -DUNIX64 -DHAVE_AVX2 -f elf64 -I./codec/common/x86/ -o codec/encoder/core/x86/coeff.o codec/encoder/core/x86/coeff.asm It should be "-f elfx32" here With these two changes, the build is suceeding on x32 architecture This has been forwarded upstream: https://github.com/cisco/openh264/issues/3545 Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1012743: opencv: FTBFS on hppa (missing viz module)
Source: opencv Version: 4.5.4+dfsg-9 Severity: important Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hello, opencv FTBFS on hppa because it seems that the viz module is not enabled during the build dh_install -a dh_install: warning: Cannot find (any matches for) "usr/include/opencv4/opencv2/viz.hpp" (tried in ., debian/tmp) dh_install: warning: libopencv-viz-dev missing files: usr/include/opencv4/opencv2/viz.hpp dh_install: warning: Cannot find (any matches for) "usr/include/opencv4/opencv2/viz/*" (tried in ., debian/tmp) dh_install: warning: libopencv-viz-dev missing files: usr/include/opencv4/opencv2/viz/* dh_install: warning: Cannot find (any matches for) "usr/lib/*/libopencv_viz.a" (tried in ., debian/tmp) dh_install: warning: libopencv-viz-dev missing files: usr/lib/*/libopencv_viz.a dh_install: warning: Cannot find (any matches for) "usr/lib/*/libopencv_viz.so" (tried in ., debian/tmp) dh_install: warning: libopencv-viz-dev missing files: usr/lib/*/libopencv_viz.so dh_install: warning: Cannot find (any matches for) "usr/lib/*/libopencv_viz.so.*" (tried in ., debian/tmp) dh_install: warning: libopencv-viz4.5d missing files: usr/lib/*/libopencv_viz.so.* dh_install: error: missing files, aborting https://buildd.debian.org/status/fetch.php?pkg=opencv=hppa=4.5.4%2Bdfsg-9%2Bb7=1655076922=0 I see that some build-dependencies are not installed on hppa (and others) architectures. Maybe the libopencv-viz* packages should not be built on these? Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1012523: gnuplot: Please review the build-dependencies
Source: gnuplot Version: 5.4.2+dfsg2-2 Severity: normal Hello, gnuplot is not building on some ports due to the build-dependencies against some Qt libraries (mainly QtWebkit), but looking in the code it seems that some of these are not needed anymore (removing these BD results in the same binary packages) In the configure I see: PKG_CHECK_MODULES_NOFAIL(QT, [Qt5Core Qt5Gui Qt5Network Qt5Svg Qt5PrintSupport]) So AFAICS, at least libqt5webkit5-dev and libqt5opengl5-dev are not needed anymore Could you please check? Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1012518: python3-distutils: CFLAGS and CPPFLAGS leaking in LD flags
Package: python3-distutils Version: 3.9.12-1 Severity: important Hello, When trying to build matplotlib (that uses hardening +pie) on x32, -specs=/usr/share/dpkg/pie-compile.specs ends up being added to the flags passed to the linker. This breaks the build with: x86_64-linux-gnux32-g++ -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -Wl,-z,now -g -O2 -ffile-prefix-map=/tmp/matplotlib-3.5.1=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_bezier_arc.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_curves.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_image_filters.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_trans_affine.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_vcgen_contour.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_vcgen_dash.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_vcgen_stroke.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/extern/agg24-svn/src/agg_vpgen_segmentator.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/src/_backend_agg.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/src/_backend_agg_wrapper.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/src/checkdep_freetype2.o build/temp.linux-x86_64-3.9/matplotlib.backends._backend_agg/src/py_converters.o -o build/lib.linux-x86_64-3.9/matplotlib/backends/_backend_agg.cpython-39-x86_64-linux-gnux32.so -lfreetype /usr/bin/ld: /tmp/cc7JfqHN.ltrans3.ltrans.o: warning: relocation against `PyExc_ValueError' in read-only section `.text' /usr/bin/ld: /tmp/cc7JfqHN.ltrans0.ltrans.o: relocation R_X86_64_PC32 against undefined symbol `_Py_NoneStruct' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status Looking in distutils code (/usr/lib/python3.9/distutils/sysconfig.py) it seems that the CFLAGS and CPPFLAGS are leaking in the flags passed to the linkers (LDFLAGS/LDSHARED) Is that expected? Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages python3-distutils depends on: ii python3 3.10.4-1+b1 ii python3-lib2to3 3.9.12-1 python3-distutils recommends no packages. python3-distutils suggests no packages. -- no debconf information
Bug#1012489: ceph: FTBFS on some architectures becuase of missing boost_context (and probably boost_coroutine)
Source: ceph Version: 16.2.7+ds-4 Severity: important Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hello, Ceph currently FTBFS on some architecture (x32, sparc64, ppc64, ia64, alpha). This is related to the fact that libboost-context-dev not being installed during the build: libboost-context-dev (>= 1.74.0) [!ia64 !m68k !ppc64 !sh4 !sparc64 !x32 !alpha], libboost-coroutine-dev (>= 1.74.0) [!ia64 !m68k !ppc64 !sh4 !sparc64 !x32 !alpha], Either the part of the code using this/these library/libraries should be disabled on these architectures or the arch qualifier should be removed so ceph is not attempted to be build on these architectures as we know it will fail (and we are not wasting cpu time). And it will start building again if boost_context is added to these architectures eventually (I've a patch that makes the build x32 succeed). I would go for the later. Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1012379: subversion: Please disable java support on kfreebsd
Source: subversion Version: 1.14.2-1 Severity: important Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) Hello, Java support should be disabled on kfreebsd too openjdk8 (the current default) is no available on that architecture for years (and openjdk11 is not even supported by the package) The attached patch should(?) disable the java support Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy diff -Nru subversion-1.14.2/debian/control subversion-1.14.2/debian/control --- subversion-1.14.2/debian/control2022-04-12 14:38:19.0 +0200 +++ subversion-1.14.2/debian/control2022-06-05 23:36:42.0 +0200 @@ -6,11 +6,11 @@ bash-completion, chrpath, debhelper-compat (= 12), - default-jdk-headless (>= 2:1.8) [!hurd-i386 !hppa !sparc] , + default-jdk-headless (>= 2:1.8) [!hurd-i386 !hppa !sparc !kfreebsd-amd64 !kfreebsd-i386] , dh-apache2, dh-python, doxygen, - junit4 [!hurd-i386 !hppa !sparc] , + junit4 [!hurd-i386 !hppa !sparc !kfreebsd-amd64 !kfreebsd-i386] , libapr1-dev, libaprutil1-dev, libdb5.3-dev, diff -Nru subversion-1.14.2/debian/rules subversion-1.14.2/debian/rules --- subversion-1.14.2/debian/rules 2022-04-12 14:38:19.0 +0200 +++ subversion-1.14.2/debian/rules 2022-06-05 23:36:42.0 +0200 @@ -27,7 +27,7 @@ # with DISABLE_JAVAHL_ARCHS. ENABLE_JAVAHL= yes -DISABLE_JAVAHL_ARCHS = hurd-i386 hppa sparc +DISABLE_JAVAHL_ARCHS = hurd-i386 hppa sparc kfreebsd-amd64 kfreebsd-i386 ifneq (,$(filter $(DEB_HOST_ARCH), $(DISABLE_JAVAHL_ARCHS))) ENABLE_JAVAHL = endif
Bug#1012378: elfutils: FTBFS on kfreebsd
Source: elfutils Version: 0.186-1 Severity: important Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hello, elfutils currently FTBFS on kfreebsd with the current error: gcc -D_GNU_SOURCE -DHAVE_CONFIG_H -DLOCALEDIR='"/usr/share/locale"' -I. -I.. -I. -I. -I../lib -I.. -I. -I./../libelf -I./../libebl -I./../libdw -I./../libdwelf -I/usr/include/p11-kit-1 -I/usr/include/x86_64-kfreebsd-gnu -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu99 -Wall -Wshadow -Wformat=2 -Wold-style-definition -Wstrict-prototypes -Wtrampolines -Wlogical-op -Wduplicated-cond -Wnull-dereference -Wimplicit-fallthrough=5 -Wunused -Wextra -Wstack-usage=262144 -D_FORTIFY_SOURCE=2 -g -O3 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -MT debuginfod-client.o -MD -MP -MF .deps/debuginfod-client.Tpo -c -o debuginfod-client.o debuginfod-client.c debuginfod-client.c: In function ‘debuginfod_query_server’: debuginfod-client.c:1042:37: error: ‘CLOCK_MONOTONIC_RAW’ undeclared (first use in this function); did you mean ‘CLOCK_MONOTONIC_FAST’? 1042 | if ( maxtime > 0 && clock_gettime(CLOCK_MONOTONIC_RAW, _time) == -1) | ^~~ | CLOCK_MONOTONIC_FAST debuginfod-client.c:1042:37: note: each undeclared identifier is reported only once for each function it appears in -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1011952: mesa: FTBFS on kfreebsd
Le 2/06/22 à 18:25, Timo Aaltonen a écrit : Laurent Bigonville kirjoitti 27.5.2022 klo 18.43: Source: mesa Version: 22.1.0~rc5-1 Severity: important Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) Forwarded: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4081 Hello, mesa currently FTBFS on kfreebsd The attached patch seems to fix this The patch has been propsed upstream Could you please apply that patch? Is disabling gallium-extra-hud a part of the fix? Yes indeed, should have mentioned it Apparently it requires linux specific wireless headers, disabling it on non-linux/kfreebsd is allowing the package to build
Bug#1011952: mesa: FTBFS on kfreebsd
Source: mesa
Version: 22.1.0~rc5-1
Severity: important
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
Forwarded: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4081
Hello,
mesa currently FTBFS on kfreebsd
The attached patch seems to fix this
The patch has been propsed upstream
Could you please apply that patch?
Kind regards,
Laurent Bigonville
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.17.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
diff -u mesa-22.1.0/debian/patches/series mesa-22.1.0/debian/patches/series
--- mesa-22.1.0/debian/patches/series
+++ mesa-22.1.0/debian/patches/series
@@ -2,3 +2,4 @@
path_max.diff
src_glx_dri_common.h.diff
revert-enabling-tlsdesc-support.diff
+fix_ftbfs_kfreebsd.patch
diff -u mesa-22.1.0/debian/rules mesa-22.1.0/debian/rules
--- mesa-22.1.0/debian/rules
+++ mesa-22.1.0/debian/rules
@@ -56,7 +56,6 @@
confflags_DIRECT_RENDERING = -Dglx-direct=true
confflags_GBM = -Dgbm=enabled
- confflags_GALLIUM += -Dgallium-extra-hud=true
confflags_GALLIUM += -Dgallium-vdpau=enabled
confflags_GALLIUM += -Dlmsensors=enabled
@@ -68,6 +67,7 @@
ifeq ($(DEB_HOST_ARCH_OS), linux)
confflags_DRI3 = -Ddri3=enabled
+ confflags_GALLIUM += -Dgallium-extra-hud=true
# Gallium drivers which require kernel support, not yet ported to
non-Linux
GALLIUM_DRIVERS += nouveau virgl
only in patch2:
unchanged:
--- mesa-22.1.0.orig/debian/patches/fix_ftbfs_kfreebsd.patch
+++ mesa-22.1.0/debian/patches/fix_ftbfs_kfreebsd.patch
@@ -0,0 +1,53 @@
+From 809fc7ef474a6010f2eafc853d8d1322f97a539c Mon Sep 17 00:00:00 2001
+From: Laurent Bigonville
+Date: Thu, 17 Feb 2022 14:49:27 +0100
+Subject: [PATCH] Try to fix FTBFS on kfreebsd architecture
+
+Fixes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4081
+---
+ include/drm-uapi/sync_file.h | 1 +
+ src/util/u_qsort.h | 2 +-
+ src/util/u_thread.h | 2 +-
+ 3 files changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/include/drm-uapi/sync_file.h b/include/drm-uapi/sync_file.h
+index 11d86db53e4..7ede34e12de 100644
+--- a/include/drm-uapi/sync_file.h
b/include/drm-uapi/sync_file.h
+@@ -19,6 +19,7 @@
+
+ #else /* One of the BSDs */
+
++#include
+ #include
+ #include
+
+diff --git a/src/util/u_qsort.h b/src/util/u_qsort.h
+index 34fff94dba4..ac3dfebaa6b 100644
+--- a/src/util/u_qsort.h
b/src/util/u_qsort.h
+@@ -57,7 +57,7 @@ util_qsort_r(void *base, size_t nmemb, size_t size,
+ void *arg)
+ {
+ #if HAVE_QSORT_R
+-# if DETECT_OS_APPLE || DETECT_OS_BSD
++# if (DETECT_OS_APPLE || DETECT_OS_BSD) && ! defined(__GLIBC__)
+/* BSD/macOS qsort_r takes "arg" before the comparison function and it
+ * pass the "arg" before the elements.
+ */
+diff --git a/src/util/u_thread.h b/src/util/u_thread.h
+index d06ff6beddb..70c02bf938c 100644
+--- a/src/util/u_thread.h
b/src/util/u_thread.h
+@@ -125,7 +125,7 @@ static inline thrd_t u_thread_create(int (*routine)(void
*), void *param)
+ static inline void u_thread_setname( const char *name )
+ {
+ #if defined(HAVE_PTHREAD)
+-#if DETECT_OS_LINUX || DETECT_OS_CYGWIN || DETECT_OS_SOLARIS
++#if DETECT_OS_LINUX || DETECT_OS_CYGWIN || DETECT_OS_SOLARIS ||
defined(__GLIBC__)
+int ret = pthread_setname_np(pthread_self(), name);
+if (ret == ERANGE) {
+ char buf[16];
+--
+GitLab
+
Bug#1011163: samba: FTBFS on kfreebsd
Source: samba
Version: 2:4.16.1+dfsg-4
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hello,
samba still FTBFS on kfreebsd
PYTHONHASHSEED=1 python3 ./buildtools/bin/waf -j2 -j1 configure -C
--prefix=/usr --enable-fhs --sysconfdir=/etc --localstatedir=/var
--libexecdir=/usr/libexec --libdir=/usr/lib/x86_64-kfreebsd-gnu
--datadir=/usr/share --with-modulesdir=/usr/lib/x86_64-kfreebsd-gnu/samba
--with-pammodulesdir=/lib/x86_64-kfreebsd-gnu/security
--with-privatedir=/var/lib/samba/private
--with-smbpasswd-file=/etc/samba/smbpasswd --with-piddir=/run/samba
--with-lockdir=/run/samba --with-statedir=/var/lib/samba
--with-cachedir=/var/cache/samba --with-pam --with-syslog --with-utmp
--with-winbind --with-quota --with-automount --with-ldap --with-ads
--with-gpgme --enable-avahi --enable-spotlight --disable-rpath
--disable-rpath-install
--with-shared-modules=idmap_rid,idmap_ad,idmap_adex,idmap_hash,idmap_ldap,idmap_tdb2,vfs_dfs_samba4,auth_samba4,vfs_nfs4acl_xattr
--bundled-libraries=NONE,pytevent,ldb --with-cluster-support
--enable-etcd-reclock --with-socketpath=/run/ctdb/ctdbd.socket
--with-logdir=/var/log/ctdb --disable-cephfs --without-systemd || \
{ echo " contents of config.log:"; cat bin/config.log; false; }
Setting top to : /<>
Setting out to : /<>/bin
Checking for 'clang' (C compiler): Traceback (most recent call last):
File "/<>/third_party/waf/waflib/Utils.py", line 831, in wrap
return cache[k]
KeyError: (,)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/<>/third_party/waf/waflib/Utils.py", line 831, in wrap
return cache[k]
KeyError: (,)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/<>/third_party/waf/waflib/Scripting.py", line 159, in
waf_entry_point
run_commands()
File "/<>/third_party/waf/waflib/Scripting.py", line 255, in
run_commands
ctx = run_command(cmd_name)
File "/<>/third_party/waf/waflib/Scripting.py", line 239, in
run_command
ctx.execute()
File "/<>/third_party/waf/waflib/Configure.py", line 159, in
execute
super(ConfigurationContext, self).execute()
File "/<>/third_party/waf/waflib/Context.py", line 214, in
execute
self.recurse([os.path.dirname(g_module.root_path)])
File "/<>/third_party/waf/waflib/Context.py", line 296, in
recurse
user_function(self)
File "/<>/wscript", line 163, in configure
conf.RECURSE('lib/replace')
File "/<>/./buildtools/wafsamba/samba_utils.py", line 66, in fun
return f(*k, **kw)
File "/<>/./buildtools/wafsamba/samba_utils.py", line 469, in
RECURSE
return ctx.recurse(relpath)
File "/<>/third_party/waf/waflib/Context.py", line 296, in
recurse
user_function(self)
File "/<>/third_party/waf/waflib/Utils.py", line 833, in wrap
ret = fun(*k)
File "/<>/lib/replace/wscript", line 30, in configure
conf.RECURSE('buildtools/wafsamba')
File "/<>/./buildtools/wafsamba/samba_utils.py", line 66, in fun
return f(*k, **kw)
File "/<>/./buildtools/wafsamba/samba_utils.py", line 469, in
RECURSE
return ctx.recurse(relpath)
File "/<>/third_party/waf/waflib/Context.py", line 296, in
recurse
user_function(self)
File "/<>/third_party/waf/waflib/Utils.py", line 833, in wrap
ret = fun(*k)
File "/<>/buildtools/wafsamba/wscript", line 296, in configure
conf.load('compiler_c')
File "/<>/third_party/waf/waflib/Configure.py", line 271, in load
func(self)
File "/<>/third_party/waf/waflib/Tools/compiler_c.py", line 79,
in configure
conf.load(compiler)
File "/<>/third_party/waf/waflib/Configure.py", line 271, in load
func(self)
File "/<>/third_party/waf/waflib/Tools/clang.py", line 22, in
configure
conf.find_clang()
File "/<>/./buildtools/wafsamba/samba_utils.py", line 66, in fun
return f(*k, **kw)
File "/<>/third_party/waf/waflib/Tools/clang.py", line 18, in
find_clang
conf.get_cc_version(cc, clang=True)
File "/<>/third_party/waf/waflib/Configure.py", line 317, in fun
return f(*k, **kw)
File "/<>/third_party/waf/waflib/Tools/c_config.py", line 1027,
in get_cc_version
cmd = cc + ['-dM', '-E', '-']
TypeError: unsupported operand type(s) for +: 'NoneType' and 'list'
Kind regards,
Laurent Bigonville
-- Package-specific info:
* /etc/samba/smb.conf present, but not attached
* /var/lib/samba/dhcp.conf pres
Bug#982085: gettext: Support autobuilding on emacsless and javaless architectures
Hello, Any news about this? By not allowing this package on some architectures, you are shifting the complexity of adding architecture qualifier to other packages higher in the dependency chain, so I'm also not sure this is a good thing either. As said by other, disabling optional language bindings on architectures where the language is not supported is quite common... my 2¢ Laurent Bigonville
Bug#1006530: mariadb-10.6: FTBFS on x32: undefined reference to misc functions and files (regression from MariaDB 10.5)
On Tue, 15 Mar 2022 15:22:15 +1100 Daniel Black wrote: > The error is earlier in the logs: > > -- Looking for sched_getcpu - found > -- Could NOT find PMEM (missing: PMEM_LIBRARIES PMEM_INCLUDE_DIR) > CMake Error at storage/innobase/CMakeLists.txt:345 (MESSAGE): > WITH_PMEM=ON cannot be satisfied > > When the configure stage fails, the builds outputs the > CMakeOutput/Error logs to complement this error earlier in the logs. > In this case its not useful but other times it is. > > so the architecture test in debian/rules isn't right as it adds WITH_PMEM=ON. > WITH_PMEM=ON doesn't seem explicitly added to the options on x32, so I'm wondering if WITH_PMEM=OFF shouldn't be added explicitly on architectures where libpmem is not available/supported
Bug#980744: Please add support for upcoming bullseye release
On Thu, 21 Jan 2021 10:25:08 +0100 Laurent Bigonville wrote: > Hello, > > The new debian release is coming and osinfo-db is currently not > supporting it. > > Could you please add support for bullseye? > I've created a branch with two patches that should be uploaded in stable as the currently the version in debian bullseye of osinfo-db is not supporting bullseye https://salsa.debian.org/bigon/osinfo-db/-/commits/debian/bullseye/ Could you please to as table upload with these? I still think that such bugs should be RC, as the data for the current stable must be supported in stable...
Bug#1009972: libvirt: TPM emulation requires swtpm, swtpm_setup and swtpm_ioctl executables
Source: libvirt Version: 8.2.0-1 Severity: normal Hello, TPM emulation requires the swtpm, swtpm_setup and swtpm_ioctl executables (that are shipped in swtpm and swtpm-tools packages) But libvirt is not depending on them. A (soft?) dependency should probably be added Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1009175: python3-samba package trying to replace file owned by samba one (dckeytab)
Package: python3-samba Version: 2:4.16.0+dfsg-2 Severity: serious Hello, When updating my system this morning, I got the following error: Préparation du dépaquetage de .../03-python3-samba_2%3a4.16.0+dfsg-2_amd64.deb ... Dépaquetage de python3-samba (2:4.16.0+dfsg-2) sur (2:4.13.14+dfsg-1+b3) ... dpkg: erreur de traitement de l'archive /tmp/apt-dpkg-install-pB0IcL/03-python3-samba_2%3a4.16.0+dfsg-2_amd64.deb (--unpack) : tentative de remplacement de « /usr/lib/python3/dist-packages/samba/dckeytab.cpython-310-x86_64-linux-gnu.so », qui appartient aussi au paquet samba 2:4.13.14+dfsg-1+b3 dpkg-deb: erreur: coller subprocess was killed by signal (Relais brisé (pipe)) Apparently the dckeytab.cpython-310-x86_64-linux-gnu.so file moved from the samba package to the python3-samba without the proper Breaks/Replaces -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages python3-samba depends on: ii libbsd0 0.11.6-1 ii libc6 2.33-7 ii libgnutls30 3.7.3-4+b1 ii libldb2 2:2.5.0+smb-2+samba4.16.0+dfsg ii libpython3.10 3.10.4-3 ii libtalloc2 2.3.3-3+b1 ii libtevent0 0.11.0-1 ii libwbclient02:4.16.0+dfsg-2 ii python3 3.10.4-1 ii python3-ldb 2:2.5.0+smb-2+samba4.16.0+dfsg ii python3-talloc 2.3.3-3+b1 ii python3-tdb 1.4.6-2+b1 ii samba-libs 2:4.16.0+dfsg-2 Versions of packages python3-samba recommends: ii python3-gpg 1.16.0-1.2 python3-samba suggests no packages. -- no debconf information
Bug#1006127: wireless-regdb stable policy
FTR, this seems to be fixed in the last release (2022-02-18) of wireless-regdb: https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/commit/?id=e427ff2a592e26fc1e8336769b9a1ad223f6f697
Bug#1007769: scipy: FTBFS on sh4
Source: scipy Version: 1.7.3-2 Severity: important Tags: ftbfs Forwarded: https://github.com/scipy/scipy/issues/15584 Hello, scipy currently FTBFS on sh4 with the following error: sh4-linux-gnu-gcc: scipy/special/_test_round.c scipy/special/_test_round.c: In function ‘__pyx_pf_5scipy_7special_11_test_round_have_fenv’: scipy/special/_test_round.c:2213:30: error: ‘FE_UPWARD’ undeclared (first use in this function) 2213 | __pyx_t_1 = ((fesetround(FE_UPWARD) != 0) != 0); | ^ scipy/special/_test_round.c:2213:30: note: each undeclared identifier is reported only once for each function it appears in scipy/special/_test_round.c:2241:30: error: ‘FE_DOWNWARD’ undeclared (first use in this function); did you mean ‘FP_INT_DOWNWARD’? 2241 | __pyx_t_1 = ((fesetround(FE_DOWNWARD) != 0) != 0); | ^~~ | FP_INT_DOWNWARD scipy/special/_test_round.c: In function ‘__pyx_pf_5scipy_7special_11_test_round_4test_add_round’: scipy/special/_test_round.c:2767:37: error: ‘FE_UPWARD’ undeclared (first use in this function) 2767 | __pyx_v_status = fesetround(FE_UPWARD); | ^ scipy/special/_test_round.c:2825:37: error: ‘FE_DOWNWARD’ undeclared (first use in this function); did you mean ‘FP_INT_DOWNWARD’? 2825 | __pyx_v_status = fesetround(FE_DOWNWARD); | ^~~ | FP_INT_DOWNWARD Upstream seems to think that it's a bug in the architecture and propose that debian carries a patch for it: https://github.com/scipy/scipy/issues/15584#issuecomment-1069125146 Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#819349: libnss3: broken AES on x32 on certain Intel CPUs
Hello, I can confirm that the last patch proposed in #819349 workaround the FTBFS of NSS and also fixes the FTBFS of libsrtp2 (bug #958427) Would it be possible to apply the patch in NSS to workaround the issue then? Kind regards, Laurent Bigonville
Bug#1007233: nss: FTBFS on x32 architecture
Source: nss Version: 2:3.52-1 Severity: important Tags: ftbfs Hello, nss currently FTBFS on x32 architecture with the following error: A PKCS #11 module returned CKR_DEVICE_ERROR, indicating that a problem has occurred with the token or slot. ERROR: Unable to switch FIPS modes. This is already reported upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1062903 Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#958427: libsrtp2: FTBFS on x32: bogus printf with time_t, then segfaults [regression]
found 958427 2.4.2-3 thanks So apparently the patch proposed here was not enough and the test is crashing :/ Thorsten do you think you could have a look?
Bug#958427: libsrtp2: FTBFS on x32: bogus printf with time_t, then segfaults [regression]
Hello, This should have been fixed upstream with the following patch: https://github.com/cisco/libsrtp/commit/4f1d945fe3eb302fa2bab2aea63fdf6ea7485e95 Do you think you could do an upload with that includes it? Thanks Laurent Bigonville
Bug#1005594: rygel: FTBFS: ../meson.build:99:0: ERROR: Could not generate cargs for gst-editing-services-1.0:
reassign 1005594 libges-1.0-dev 1.20.0-1 affects 1005594 src:rygel thanks On Sun, 13 Feb 2022 08:31:17 +0100 Lucas Nussbaum wrote: > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > [...] > > Package 'python-3.9-embed', required by 'gst-editing-services-1.0', not found This is an issue with gstreamer-editing-services1.0 libges-1.0-dev package should depends against libpython3-dev (or libpython3.X-dev) as the .pc file requires it I'm not sure how to automatically calculate that we need libpython3.9-dev vs libpython3.10-dev for example
Bug#1006365: wireplumber: Please split audio files out of the main package
Package: wireplumber Version: 0.4.8-3 Severity: important Hello, This is similar to #1006364 opened against pipewire-media-session and an addition to #997862 Currently having wireplumber and pulseaudio installed at the same time make both pipewire and pulseadio register A2DP endpoints in bluez (and open the alsa devices) As pulseaudio is still the default (at least when installing GNOME) this is causing issues. Would it be possible to split the configuration and plugins files that enable the "audio" part of pipewire to an other package? That way pipewire-pulse could depend on that package instead? Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages wireplumber depends on: ii init-system-helpers 1.62 ii libc6 2.33-7 ii libglib2.0-0 2.70.4-1 ii libpipewire-0.3-0 0.3.47-1 pn libwireplumber-0.4-0 ii pipewire 0.3.47-1 Versions of packages wireplumber recommends: pn pipewire-pulse wireplumber suggests no packages.
Bug#1006364: pipewire-media-session: Please split audio (configuration) files out of the main package
Package: pipewire-media-session Version: 0.4.1-2 Severity: important Hello, Currently having pipewire-media-session and pulseaudio installed at the same time make both pipewire and pulseadio register A2DP endpoints in bluez (and open the alsa devices) As pulseaudio is still the default (at least when installing GNOME) this is causing issues. Would it be possible to split the configuration files that enable the "audio" part of pipewire to an other package? That way pipewire-pulse could depend on that package instead? Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages pipewire-media-session depends on: ii init-system-helpers 1.62 ii libasound2 1.2.6.1-1 ii libc62.33-7 ii libdbus-1-3 1.12.20-4 ii libpipewire-0.3-00.3.47-1 ii libsystemd0 250.3-2 ii pipewire 0.3.47-1 pipewire-media-session recommends no packages. pipewire-media-session suggests no packages. -- no debconf information
Bug#1006211: x265: Does not build on kfreebsd
Source: x265 Version: 3.5-2 Severity: important Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) Hello, x265 currently does not build on kfreebsd because git is FTBFS The attached patch removes the git BD allowing the package to build on kfreebsd as well. There is a slight difference in the resulting binaries (in the .gnu_debuglink section), but it looks like it's more a reproductibility issue (https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/x265.html) Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy diff -Nru x265-3.5/debian/control x265-3.5/debian/control --- x265-3.5/debian/control 2021-08-22 23:51:00.0 +0200 +++ x265-3.5/debian/control 2021-09-24 00:47:21.0 +0200 @@ -6,7 +6,6 @@ Build-Depends: debhelper-compat (= 13), cmake, - git, libnuma-dev [amd64 arm64 i386 mips mips64 mips64el mipsel powerpc ppc64el], nasm (>= 2.13) [amd64 kfreebsd-amd64] Build-Depends-Indep: diff -Nru x265-3.5/debian/rules x265-3.5/debian/rules --- x265-3.5/debian/rules 2021-08-23 19:42:49.0 +0200 +++ x265-3.5/debian/rules 2021-09-24 00:47:21.0 +0200 @@ -12,7 +12,7 @@ # LFS support export DEB_CPPFLAGS_MAINT_APPEND=$(shell getconf LFS_CFLAGS) -FLAGS = -DENABLE_PIC=ON +FLAGS = -DENABLE_PIC=ON -DGIT_EXECUTABLE=/bin/true # no shared libs are built if HDR10+ is enabled # FLAGS += -DENABLE_HDR10_PLUS=ON FLAGS_OTHERBIT = -DENABLE_CLI=OFF
Bug#1005801: pipewire: Please enable aptx support
Source: pipewire Version: 0.3.45-1 Severity: wishlist Hello, Since a few day, libfreeaptx is in the debian archive Could you please enable support for aptx? Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#991597: pulseaudio: Please enable GStreamer support
Le 14/02/22 à 13:01, Tomas Janousek a écrit : - Hi all, Hello, On Wed, Aug 04, 2021 at 09:55:44AM +0200, Laurent Bigonville wrote: Le 3/08/21 à 18:46, Felipe Sateler a écrit : >Does that mean that enabling it, would only add some dependencies >but not actually do anything? Yes, a (soft) dependency should probably be added against gstreamer1.0-plugins-bad, but as I said, the needed version (>= 1.19) is not yet in debian There's gstreamer 1.20 in unstable and testing now, so there's a chance it would finally do something useful if enabled. :-) Yes it's planned, I've a build on my laptop and I did some testing with my Sony (WF1000xm4, WH1000xm4,...) devices and when using LDAC, it's not working (no sound or device crashing). So I personally don't want to upload the change before this is fixed.
Bug#1005703: weechat: Please switch from build-dependency libargon2-0-dev to libargon2-dev
Source: weechat Version: 3.4-2 Severity: important Tags: sid bookworm Hello, weechat currently build-depends against libargon2-0-dev that is now a virtual package. Could you please switch to libargon2-dev instead? Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1005702: ring: Please switch from build-dependency libargon2-0-dev to libargon2-dev
Source: ring Version: 20210112.2.b757bac~ds1-1 Severity: important Tags: sid bookworm Hello, ring currently build-depends against libargon2-0-dev that is now a virtual package. Could you please switch to libargon2-dev instead? Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1005699: opendht: Please switch from build-dependency libargon2-0-dev to libargon2-dev
Source: opendht Version: 2.3.1-1 Severity: important Tags: sid bookworm Hello, opendht currently build-depends against libargon2-0-dev that is now a virtual package. Could you please switch to libargon2-dev to libargon2-dev instead? Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1005700: python-argon2: Please switch from build-dependency libargon2-0-dev to libargon2-dev
Source: python-argon2 Version: 21.1.0-1 Severity: important Tags: sid bookworm Hello, python-argon2 currently build-depends against libargon2-0-dev that is now a virtual package. Could you please switch to libargon2-dev instead? Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1005285: procps: FTBFS on kfreebsd
Source: procps Version: 2:3.3.17-4 Severity: important Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) Hello, procps currently FTBFS on kfreebsd, it seems that it's caused by the locale files not being installed in the package: dh_missing -a dh_missing: warning: usr/share/locale/de/LC_MESSAGES/procps-ng.mo exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/share/locale/fr/LC_MESSAGES/procps-ng.mo exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/share/locale/pl/LC_MESSAGES/procps-ng.mo exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/share/locale/pt_BR/LC_MESSAGES/procps-ng.mo exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/share/locale/sv/LC_MESSAGES/procps-ng.mo exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/share/locale/uk/LC_MESSAGES/procps-ng.mo exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/share/locale/vi/LC_MESSAGES/procps-ng.mo exists in debian/tmp but is not installed to anywhere dh_missing: warning: usr/share/locale/zh_CN/LC_MESSAGES/procps-ng.mo exists in debian/tmp but is not installed to anywhere dh_missing: error: missing files, aborting The following debhelper tools have reported what they installed (with files per package) * dh_install: libprocps-dev (15), libprocps8 (2), procps (15) * dh_installdocs: libprocps-dev (0), libprocps8 (0), procps (2) * dh_installexamples: libprocps-dev (0), libprocps8 (0), procps (1) * dh_installman: libprocps-dev (0), libprocps8 (0), procps (76) If the missing files are installed by another tool, please file a bug against it. When filing the report, if the tool is not part of debhelper itself, please reference the "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for debhelper (10.6.3+). (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz) Be sure to test with dpkg-buildpackage -A/-B as the results may vary when only a subset is built If the omission is intentional or no other helper can take care of this consider adding the paths to debian/not-installed. The attached patch should fix this Kind regards, Laurent bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy diff -Nru procps-3.3.17/debian/procps.install.kfreebsd procps-3.3.17/debian/procps.install.kfreebsd --- procps-3.3.17/debian/procps.install.kfreebsd2022-01-13 09:46:59.0 +0100 +++ procps-3.3.17/debian/procps.install.kfreebsd2022-02-10 14:56:50.0 +0100 @@ -2,3 +2,4 @@ bbin/kill.procps bin bbin/ps bin bin/* /usr/bin +usr/share/locale
Bug#1005113: fwupd: Please tighten the version of libfwupd2
Package: fwupd Version: 1.5.7-5 Severity: serious Hello, fwupd package should tighten the version of the libfwupd2 dependency (and probably libfwupdplugin as well) Mixing fwupd version 1.5.7-5 and libfwupd2 version 1.7.4-1 makes fwupd crash Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages fwupd depends on: ii libc6 2.33-5 ii libcurl3-gnutls7.81.0-1 ii libefiboot137-6 ii libelf10.186-1 ii libflashrom1 1.2-5 ii libfwupd2 1.5.7-5 ii libfwupdplugin11.5.7-5 ii libglib2.0-0 2.70.3-1 ii libgnutls303.7.3-4+b1 ii libgudev-1.0-0 237-2 ii libgusb2 0.3.8-1 ii libjcat1 0.1.9-1 ii libjson-glib-1.0-0 1.6.6-1 ii libpolkit-gobject-1-0 0.105-31.1+b1 ii libsmbios-c2 2.4.3-1 ii libsqlite3-0 3.37.2-2 ii libsystemd0250.3-2 ii libtss2-esys-3.0.2-0 3.1.0-3 ii libxmlb2 0.3.6-2 ii shared-mime-info 2.1-2 Versions of packages fwupd recommends: ii bolt 0.9.1-2 ii dbus 1.12.20-3 ii fwupd-amd64-signed [fwupd-signed] 1.5.7+5 ii python33.9.8-1 pn secureboot-db ii udisks22.9.4-1 Versions of packages fwupd suggests: pn gir1.2-fwupd-2.0 -- Configuration Files: /etc/dbus-1/system.d/org.freedesktop.fwupd.conf [Errno 2] Aucun fichier ou dossier de ce type: '/etc/dbus-1/system.d/org.freedesktop.fwupd.conf' /etc/fwupd/remotes.d/fwupd.conf [Errno 2] Aucun fichier ou dossier de ce type: '/etc/fwupd/remotes.d/fwupd.conf' -- no debconf information
Bug#1004909: Bug#1004905: sudo: FTBFS on non-linux architectures
Le 3/02/22 à 17:39, Marc Haber a écrit : On Thu, Feb 03, 2022 at 11:39:37AM +0100, Laurent Bigonville wrote: On kfreebsd, the attached patch fixes the compilation (that should probably be reported upstream), but it still fails in the tests Can you please try the following upstream patch instead and report back? https://www.sudo.ws/repos/sudo/rev/10775e14164a I can confirm that the patch fix the compilation indeed (no the tests)
Bug#1004905: sudo: FTBFS on non-linux architectures
Source: sudo Version: 1.9.9-1 Severity: important Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) Hello, sudo currently FTBFS on non-linux architectures On hurd, it fails in the tests On kfreebsd, the attached patch fixes the compilation (that should probably be reported upstream), but it still fails in the tests Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Index: sudo-1.9.9/include/sudo_compat.h === --- sudo-1.9.9.orig/include/sudo_compat.h +++ sudo-1.9.9/include/sudo_compat.h @@ -471,7 +471,7 @@ sudo_dso_public time_t sudo_timegm(struc #ifndef HAVE_UTIMENSAT sudo_dso_public int sudo_utimensat(int fd, const char *file, const struct timespec *times, int flag); # undef utimensat -# define utimensat(_a, _b, _c, _d) sudo_utimensat((_a), (_b), (_c), (_d)) +# define utimensat(_a, _b, _c, _d) sudo_utimensat(_a, _b, _c, _d) #endif /* HAVE_UTIMENSAT */ #ifndef HAVE_FCHMODAT sudo_dso_public int sudo_fchmodat(int dfd, const char *path, mode_t mode, int flag); @@ -486,7 +486,7 @@ sudo_dso_public int sudo_fstatat(int dfd #ifndef HAVE_FUTIMENS sudo_dso_public int sudo_futimens(int fd, const struct timespec *times); # undef futimens -# define futimens(_a, _b) sudo_futimens((_a), (_b)) +# define futimens(_a, _b) sudo_futimens(_a, _b) #endif /* HAVE_FUTIMENS */ #if !defined(HAVE_SNPRINTF) || defined(PREFER_PORTABLE_SNPRINTF) sudo_dso_public int sudo_snprintf(char *str, size_t n, char const *fmt, ...) __printflike(3, 4);
Bug#1004858: golang-github-containernetworking-plugins: Please move executables from /usr/lib/cni to /usr/libexec/cni
Le 2/02/22 à 14:58, Shengjing Zhu a écrit : On Wed, Feb 2, 2022 at 9:33 PM Laurent Bigonville wrote: Source: golang-github-containernetworking-plugins Version: 0.9.0-1 Severity: normal Hello, I think that the executables should be moved from /usr/lib/cni to /usr/libexec/cni /usr/libexec is a more sutable location for executables (and it will also help with systemd labeling) Searching the archive with codesearch it seems that ansible is the only other package with a reference to that path, but it seems that it will try both /usr/libexec/cni and /usr/lib/cni. In worst case, a symlink could be added I guess? Same should happen with /usr/lib/cni/dnsname that is installed by golang-github-containernetworking-plugin-dnsname I guess? Could you please move the files in /usr/libexec/cni? If we reset the time to the beginning of this package, then I think it should install files in libexec. But what's the benefit to do it now, after this package has been in stable release. Usage of /usr/libexec was probably not allowed by the debian policy when the package was first created :) Well I was proposing this because it makes the selinux a tiny bit easier (and also a question of consistencies as a lot of packages have moved their executables in /usr/libexec) The path /usr/lib/cni/ is also included in containerd's conffile. Please do a better search with codesearch.d.n https://codesearch.debian.net/search?q=%2Fusr%2Flib%2Fcni=1=1 Mhh interesting, that didn't show up when I did the search an hour ago That could still be managed with making a symlink I prefer not to change it. OK, I'll manage this in an other way then
Bug#1004858: golang-github-containernetworking-plugins: Please move executables from /usr/lib/cni to /usr/libexec/cni
Source: golang-github-containernetworking-plugins Version: 0.9.0-1 Severity: normal Hello, I think that the executables should be moved from /usr/lib/cni to /usr/libexec/cni /usr/libexec is a more sutable location for executables (and it will also help with systemd labeling) Searching the archive with codesearch it seems that ansible is the only other package with a reference to that path, but it seems that it will try both /usr/libexec/cni and /usr/lib/cni. In worst case, a symlink could be added I guess? Same should happen with /usr/lib/cni/dnsname that is installed by golang-github-containernetworking-plugin-dnsname I guess? Could you please move the files in /usr/libexec/cni? Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Bug#1004856: psmisc: killall is not finding some processes
Package: psmisc Version: 23.4-2 Severity: important Hello, On my machine, it looks like killall is not finding some processes, like firefox, or podman $ ps ux|grep firefox|head -1 bigon 772207 57.0 7.5 14173340 2487880 tty2 Rl+ jan31 1772:09 /usr/lib/firefox/firefox $ LC_ALL=C killall firefox firefox: no process found $ ps ux|grep podman|head -1 bigon1072328 0.0 0.0 41484 1636 ?S12:47 0:00 podman $ LC_ALL=C killall podman podman: no process found This is quite a problem Kind regards, Laurent Bigonville -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages psmisc depends on: ii libc6 2.33-5 ii libtinfo6 6.3-2 psmisc recommends no packages. psmisc suggests no packages. -- no debconf information
Bug#942412: Does not build on platform other than i386/amd64
Hello, The mariadb-connector-odbc package has now migrated to testing. Do you think you could create a backport for the current debian stable release? Kind regards, Laurent Bigonville
Bug#977469: matplotlib: Please make package bootstrappable
On Mon, 10 Jan 2022 11:06:56 +0100 Laurent Bigonville wrote: > Hello, > > As suggested in an other bug report, moving the build-dependencies that > are only needed to build -doc/arch:all packages to Build-Depends-Indep > would also help here I guess > I've made this merge request: https://salsa.debian.org/python-team/packages/matplotlib/-/merge_requests/1 I duplicated some of the build-dependencies to make it more clear that they are needed by both, if that's no OK I can rework my change and only keep one
Bug#981285: Please move fdk-aac to main
Le 26/01/22 à 11:42, Bastian Blank a écrit : On Wed, Jan 26, 2022 at 10:51:34AM +0100, Laurent Bigonville wrote: I would be really interested to see AAC support in pulseaudio/pipewire for bluetooth devices [1]https://www.gnu.org/licenses/license-list.html#fdk This clearly states that the FDK license is incompatible with the GPL. For pipewire that should be okay, because it is Expat, if nothing makes the whole thing LGPL. For gstreamer and pulseaudio it's pretty much not okay, because they are some form of GPL. Right, pulseaudio daemon is itself LGPL, but it is depending against GPL libraries making the resulting binary GPL gstreamer itself seems to be LGPL though? Being plugins based makes it a bit difficult to see what's actually loaded at runtime
Bug#981285: Please move fdk-aac to main
Le 26/01/22 à 11:12, Fabian Greffrath a écrit : Am 26.01.2022 10:51, schrieb Laurent Bigonville: Could anybody of the multimedia team have a look at this? What do you expect from "having a look at this"? I agree that the package should be in main, but in the end it's up to the ftp-masters to decide. Well it was more about someone have a second look at what I'm saying here (and maybe pre-check with d-legal and/or the ftp-masters) before doing the change to move it to main I'll check with the ftp-masters what they prefer and then do the upload if that's OK for you
Bug#981285: Please move fdk-aac to main
The 28 Jan 2021, Laurent Bigonville wrote: Hello, Currently the fdk-aac[0] package is in non-free. That package would be needed by both pulseaudio (via gstreamer) and pipewire to provide AAC support for bluetooth headsets and speakers. After some discussion with people on #debian-gnome, it looks like that the licence of the package might actually be free after all. Both the GNU project[1] and Fedora[2] are considering it Free. Could you please have a look at this an maybe move the package to main? Could anybody of the multimedia team have a look at this? I would be really interested to see AAC support in pulseaudio/pipewire for bluetooth devices Note that this would remove the need of src:gst-plugins-bad1.0-contrib that is currently waiting in the NEW queue. Kind Regards, Laurent Bigonville [0]https://tracker.debian.org/pkg/fdk-aac [1]https://www.gnu.org/licenses/license-list.html#fdk [2]https://fedoraproject.org/wiki/Licensing/FDK-AAC
Bug#942412: Does not build on platform other than i386/amd64
On Tue, 15 Oct 2019 23:30:53 +0200 Bernhard Schmidt wrote: Hello, > > src:mariadb-connector-odbc fails to build on platforms other than i386/amd64 with > > -- Looking for floor > -- Looking for floor - not found > -- Looking for floor in m > -- Looking for floor in m - found > -- odbc_config is not found > -- Found ODBC Driver Manager includes: /usr/include > CMake Error at CMakeLists.txt:237 (MESSAGE): > Driver Manager was not found > > There is a lot of hardcoding library paths based on pointer size in cmake/FindDM.cmake, > which is probably the culprit here. > > It has been reported upstream at https://jira.mariadb.org/browse/ODBC-268 . > > I'll limit architectures to i386 / amd64 with the next upload for now. > > What's the status of this bug? There is a proposed patch attached to it, could you please apply it and upload?
