Bug#1060715: gmsh: requires source-only upload for migration to testing

[Sebastian Ramacher]

Source: gmsh
Version: 4.11.1+ds1-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

https://qa.debian.org/excuses.php?package=gmsh

Migration status for gmsh (4.8.4+ds2-3 to 4.11.1+ds1-1): BLOCKED: 
Rejected/violates migration policy/introduces a regression
Issues preventing migration:
∙ ∙ autopkgtest for gmsh/4.11.1+ds1-1: amd64: Pass, arm64: Pass, armel: 
Pass, armhf: Pass, i386: Pass, ppc64el: Pass, s390x: Pass
∙ ∙ autopkgtest for pygmsh/7.1.17-2: amd64: Pass, arm64: Pass, armel: Pass, 
armhf: Pass, i386: Regression or new test ♻ (reference ♻), ppc64el: Pass, 
s390x: Pass
∙ ∙ Not built on buildd: arch amd64 binaries uploaded by 
gladky.an...@gmail.com
∙ ∙ Not built on buildd: arch all binaries uploaded by 
gladky.an...@gmail.com, a new source-only upload is needed to allow migration

Please perform a source-upload so that gmsh can become a candidate for
migration.

Cheers
-- 
Sebastian Ramacher

Bug#1060716: rust-clap: please update to v4.4.13

[Jonas Smedegaard]

Source: rust-clap
Version: 4.4.6-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v4.4.13.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWidrAACgkQLHwxRsGg
ASGpdg/6AuxEM+Q3RHqMcP5meQqCmGOdS/SOg73pclQu3xw+twzSeLGnAPHjJ/tv
F7VGJnRW37Q3ImaBGudRpdqQmjfudLy7qwgMsKeMIbOeLu3CRNQTDyRSA3jCuar6
PBO1l+C3MUgQJW2hWledYCxZ//BS7EfyAOJwowTaWYx1LZy8SHLy4ZWYvafPyURH
SnRU7sq37n2YNDmHI38s+z2ouSUDRak9LFqYT6C0viQ5CJ8EFoZjoW5XDlb7f9w0
Z6I4t2sNHIL5QbQlFaUFeUOpLsN5SlKPaJOlq1IZUbpSeJiEPfXlovjgV3KF9je6
tgg8uRp96Pylsn+GS1m5NY1Tgibwg4UaZ9LlJR10VQZfaulfqy0RC6s2LFZWgULC
N3PGD4wtJEQCUvSMJizE9glVlIwBxUfhQNPyexX1p69Itvv33Xo0Qn5XxuQjylbr
9SJZEWkin4RH9vme4B9pHboDsPhbVNASRrYtyjsdbKDN0OKIHaedraThvcsykDpL
WqdlFHcilkBJDlFnjVnHHeXxJLPgHN7hgzWYtyP3wq1MrnZdseJ2HslUufMPSCFM
rzzMf5hgi8Z1ZxtNwURmGWe1KJos3EKRpH+hU2guMt6rWOqBGB4gWr9I8NuLUZon
ewv2dN1zHy3OLwiRz/DyA/fXHXjbYVqQO0/dRrm57yFGIv14qXc=
=Fw0m
-END PGP SIGNATURE-

Bug#1060721: rust-terminal-size: please upgrade to v0.3

[Jonas Smedegaard]

Source: rust-terminal-size
Version: 0.2.6-3
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to (or separately provide) branch v0.3.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWid9sACgkQLHwxRsGg
ASHajhAApHqCKVy9EImp8k4u24wVNyNctes/yR7vZpsArUspHaHMAK+WwfPJh/VY
+QIw6Tq0XCtVw/XGT0Fn/UoE+VZhOEhaE72Y5PPWIqQLDOp/2l8lJ2TTMi01bM17
FWVWoX9SxnUWnvlJLMOqDtP+WDw9oW1GmdqOz1DzfMkql8GnvskfTV8ZV7BCNe/f
9wgor7KZk+6TiLQGthrD66mqjG2EvXYORtKR4WEqN77h4XygCx1bMGzC5W4a1rT9
deDxyMsJKTlZCQUeaq1v8X4k6ygh3id1R8US3+9ohFrUqIqVFPb3pi6/dG1RmV4l
ptsfmKEoWfVMXejaY7n3Xly3DnyrM8z+qWO0259tX0f/NmkssZJ56v6VjQHKguM0
n1M8ccH03UitxsgJ+3TOTNFHH4h+35UE8K8n29rUS9ynWM+ZWuUeRKlwcC8xF27Q
ufGs2ChktbBlSIctQjd7r0y1SxvHWlvdNlWvAdMj/KdhtL/6aRewYKcUUZwo9kcM
pomxUU9TuLL7Hwu5r5Gn868nrhuiRLqTHvDoApAey0c9qXnaqRinO1pB8+V2g6wG
+7nAgmrtIfd1wbHHw135rT7lqCbxFsvf7X9tluFGXqpuuRAGFoPZZXPuu9yprdZ/
0RtmXrFlkwCM3GuAHj2n2k6k1entNmGrPj07iyawf5eIs9bwwP8=
=yY0E
-END PGP SIGNATURE-

Bug#1060722: rust-tokio: please update to v1.35.1

[Jonas Smedegaard]

Source: rust-tokio
Version: 1.33.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v1.35.1.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWieCoACgkQLHwxRsGg
ASHsxxAArkrn4sx/2QKqPK3GMElgD7VT+15PKgXHGd7Jt4TKmMMX6Xbf1v70FW1W
BVsXJjGfqe2PD9+HbmzUERPvuANyMe1KZm/4vB9kMia458DB8uBPaLf6t4Ut0TCO
nmkyRo31Xw56txGWmhXYgVUA7cbFGtnOTrih+h1PEt65i7j0cGeFITN0j3Q/Gcl4
NOMbBM9sMFfZZPciHuOwsLgyzW2KLdhAn5Qa5bn4J5z0Vo+O0wMNZxW1eqcCcTp5
L40OBWNYJ8zxllV1xjU8mTAYEvIFhb7UfvyiMvE4AuQVyLlJkkz0REfbPajbKpva
Nkr96jP8o4SfXdCdfgc5i1gstbkbRrP82bWgxkOk+oBkasdw0h1wKQ1tx7O43WM/
p04ct6af6rTQjRpmmZHkraIvBbM1FyquC0YwHF/H5zRLhl47S2u1Gldnu+3Cr9HK
vOzjgaVQmKPEgHhDpb7BAhAjPYOAm5O7UWBvUJCT6M9q4qeqNauoJXbEupNkugJW
ah3if3aaNuOGDFgU4WOgHeFc1QLNVD2dZxG8XKhPJN3eTRT/M2l6xpW8n6t52Jd/
Q4sCKenL6+wFrXE65RBVdDgktTxnayycN84l75pV1eyjW0UdIhZm/gnQavF4zoKp
kGF7d9FDuRYqvidg7ZteQoj3CvhU7wQIc7lsLmrkBIpqEPm5gs4=
=HfPt
-END PGP SIGNATURE-

Bug#1030350: fweb: FTBFS with TeXInfo 7.0.x

[Bastian Germann]

On Fri, 3 Feb 2023 12:59:44 +0100 Hilmar Preusse  wrote:

The easiest solution is probably to add option "--output=fweb" to the
makeinfo --html in d/rules, but this needs to be verified.


I have just sponsored a NMU by Hilmar with the suggested change.

Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable

[Diederik de Haas]

On Saturday, 13 January 2024 11:45:29 CET Arno Lehmann wrote:
> Hardware name: ASUS System Product Name/ROG STRIX X670E-A GAMING WIFI, 
> BIOS 1410 04/28/2023

Possibly not related, but there's BIOS 1807 available.

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

Bug#964126: krita: Please switch from sip4 to sip5

[Dmitry Shachnev]

Control: retitle -1 krita: Please switch from sip4 to sip6

Hi again!

On Mon, Sep 21, 2020 at 02:24:04PM +0300, Dmitry Shachnev wrote:
> I have an update on PyQt5 vs. SIP 5 status.
>
> Unfortunately, things got a bit more complicated recently. Upstream is
> going to release SIP 6 in the beginning of next year, which will be not
> co-installable together with SIP 5, and which will not have /usr/bin/sip5
> “legacy” script:
>
> https://www.riverbankcomputing.com/pipermail/pyqt/2020-September/043201.html
> https://www.riverbankcomputing.com/pipermail/pyqt/2020-September/043162.html
>
> sip5 was a script to ease upgrades from SIP 4, and it has a set of options
> similar to SIP 4's /usr/bin/sip. Upstream now recommends using their new
> tools, sip-build and similar ones. See the documentation:
>
> https://www.riverbankcomputing.com/static/Docs/sip/
>
> This means that next year we will have SIP 4 and SIP 6 in Debian, but not
> SIP 5. My upstream work on Krita made use of /usr/bin/sip5, so it will need to
> be ported to the new tools in order to support SIP 6 (and PyQt6).
>
> At the same time, upstream says that it will remain possible to compile
> applications with SIP 4 even when PyQt5 uses newer SIP. So now I think the
> best plan is:
>
> - Please keep using SIP 4 for Krita for now.
> - Please test that it still works fine with PyQt5 in experimental.
> - Ask upstream to migrate to the new tools to be prepared for SIP 6 / PyQt6.

Another update on this.

It looks like upstream integrated proper support [1] for SIP 5+ a couple of
years ago, and a recent commit [2] indicates that it builds with the latest
version, 6.8, too.

So please switch from SIP 4 to SIP 6, maybe picking the needed commit(s) from
upstream.

From packaging standpoint that will mean:

- Build-depending on sip-tools and python3-sipbuild instead of
  python3-sip-dev.

- Dropping Recommends: python3-sip. Recommends already has python3-pyqt5,
  which ensures the presence of proper SIP runtime.

SIP 4 has an RC bug related to Python 3.12 [3] and it's unlikely to be fixed.

[1]: 
https://invent.kde.org/graphics/krita/-/commit/5bb4874ad04b771a0fec12827de748780b5b395b
[2]: 
https://invent.kde.org/graphics/krita/-/commit/2d71c47661d43a4e3c1ab0c27803de980bdf2bb2
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059648

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1060724: meteo-qt: Please remove python3-sip Depends

[Dmitry Shachnev]

Package: meteo-qt
Version: 3.3-2
Severity: important
Usertags: sip6

Dear Maintainer,

Your package depends on python3-sip, which belongs to the deprecated sip4
source package.

The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages
in Debian are built with that modern version.

python3-pyqt5 already depends on its SIP run-time module, python3-pyqt5.sip,
so there is no need to depend on it explicitly.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1060723: gnuradio: Please remove python3-sip Depends

[Dmitry Shachnev]

Package: gnuradio
Version: 3.10.9.1-1
Severity: important
Usertags: sip6

Dear Maintainer,

Your package depends on python3-sip, which belongs to the deprecated sip4
source package.

The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages
in Debian are built with that modern version.

python3-pyqt5 already depends on its SIP run-time module, python3-pyqt5.sip,
so there is no need to depend on it explicitly.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1060725: qutebrowser: Please remove python3-sip Depends

[Dmitry Shachnev]

Package: qutebrowser
Version: 2.5.4-1
Severity: important
Usertags: sip6

Dear Maintainer,

Your package depends on python3-sip, which belongs to the deprecated sip4
source package.

The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages
in Debian are built with that modern version.

python3-pyqt5 already depends on its SIP run-time module, python3-pyqt5.sip,
so there is no need to depend on it explicitly.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1060726: valgrind: Test after build instead of hardcoded arch list

[Petter Reinholdtsen]

Package: valgrind
Version: 1:3.20.0-2
Severity: wishlist

Instead of only listing a hardcoded list of supported architectures,
what about duing a simple test to verify that valgrind work after
building, and only upload binary packages on architectures where it
work?

A patch similar to this might work.  It call 'valgrind ls', a very
simple test, to ensure the program do not crash and burn imediately:

diff --git a/debian/control b/debian/control
index 6cefa73..23f8bb0 100644
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,7 @@ Vcs-Browser: https://salsa.debian.org/debian/valgrind
 Homepage: https://www.valgrind.org/
 
 Package: valgrind
-Architecture: amd64 armel arm64 armhf i386 mips mipsel mips64 mips64el powerpc 
ppc64 ppc64el s390x
+Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}, libc6-dbg
 Suggests: valgrind-mpi, kcachegrind
 Recommends: valgrind-dbg, gdb
diff --git a/debian/rules b/debian/rules
index c0513a2..c3f222e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,7 +17,7 @@ override_dh_auto_configure:
dh_auto_configure -- --enable-tls CFLAGS="$(CFLAGS)" 
LDFLAGS="$(LDFLAGS)"
 
 override_dh_auto_test:
-   : # do nothing for now
+   ./vg-in-place ls
 
 override_dh_auto_build:
dh_auto_build

The patch is tested on armel, where it currently fail as expected.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1060602: efl: Please switch Build-Depends to systemd-dev

[Andreas Metzler]

On 2024-01-11 bi...@debian.org wrote:
> Source: efl
> Version: 1.27.0-1
> Severity: normal
> User: pkg-systemd-maintain...@lists.alioth.debian.org
> Usertags: systemd-dev

> Hi,

> your package efl declares a Build-Depends on systemd and/or udev.

> In most cases, this build dependency is added to get the paths that
> are defined in udev.pc or systemd.pc (via pkgconfig).

> Since systemd_253-2 [1], these two pkgconfig files have been split
> into a separate package named systemd-dev. This package is arch:all,
> so even available on non-Linux architectures, which will simplify the
> installation of upstream provided service files / udev rules.
[...]

we cannot test this right now since efl build-depends on libscim-dev
which indirectly depends on systemd

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1060727: python3-python-qt-binding: Please port from sip4 to sip6

[Dmitry Shachnev]

Package: python3-python-qt-binding
Version: 0.4.4-2
Severity: important
Usertags: sip6

Dear Maintainer,

Your package ships sip_configure.py and sip_helper.cmake which are designed
to work with the old version of SIP, sip4.

The modern version of SIP is packaged as sip6, and PyQt5 and PyQt6 packages
in Debian are built with that modern version.

The documentation on how to use modern SIP is available in sip6-doc package,
or on the SIP website [1]. The recommended approach is using SIP's own
PEP 517-compliant build system (i.e. pyproject.toml and project.py files),
however some projects (e.g. krita upstream) have successfully integrated SIP 6
into their CMake-based build systems.

SIP 4 has an RC bug related to Python 3.12 [2] and it's unlikely to be fixed.

So, if the mentioned files are still needed, please port them to SIP 6, and
drop dependencies on sip-dev and python3-sip-dev packages.

[1]: https://www.riverbankcomputing.com/static/Docs/sip/
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059648

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#966055: vistrails: Uses old name of sip module

[Dmitry Shachnev]

Control: severity -1 important

Hi,

On Wed, Jul 22, 2020 at 02:44:00PM +0300, Dmitry Shachnev wrote:
> Dear Maintainer,
> 
> You are receiving this bug because your package seems to be using PyQt5
> and has Python files with "import sip" lines.
> 
> With the latest version of PyQt5 in experimental, the private sip module
> used by PyQt5 is called "PyQt5.sip", not just "sip". I am going to upload
> this version to unstable around end of August.
> 
> You may need to update your imports to do something like this:
> 
> try:
> from PyQt5 import sip
> except ModuleNotFoundError:
> import sip
> 
> Alternatively, you may import sip after importing PyQt5. So the following
> will work too:
> 
> from PyQt5 import QtCore
> import sip
> 
> Please see the following link for details:
> 
> https://www.riverbankcomputing.com/static/Docs/PyQt5/incompatibilities.html#importing-the-sip-module
> 
> If you use sip for reasons unrelated to PyQt5, you may leave the old import
> as is, but please bear in mind that sip4 is deprecated.
> 
> Also, calls like "sip.setapi('QDate', 2)" are not needed at all with PyQt5.
> They were needed only with PyQt4 and Python 2. It is safe to delete them.
> 
> For the actual documentation of sip module, see the following link:
> 
> https://www.riverbankcomputing.com/static/Docs/PyQt5/api/sip/sip-module.html

It looks like the only file where sip is imported before PyQt5 is
vistrails/packages/CLTools/wizard.py, and it uses sip for setapi() calls
which are, as described in this bug report, no longer needed.

In addition to fixing that file, please also remove python3-sip dependency.
You may want to depend on python3-pyqt5 instead, as it is used in this
package.

I am bumping the severity to important because sip4 is RC-buggy [1] and I am
going to remove it from Debian.

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

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1060698: [Pkg-auth-maintainers] Bug#1060698: yubioath-desktop: Doesn't see yubikeys anymore.

[Sébastien Noel]

On Sat, 13 Jan 2024 11:26:50 +0100 Florian Schlichting
 wrote:
>
> [...]
> While it might be possible to patch py/yubikey.py to work with the
> interface changes in current python3-ykman, I doubt this is a
> sensible thing to do if upstream has decided to abandon
> the QT version.

in case you are interested, you can find the patch in attachement

br,
Sébastien
From 5660af2838fef22b53e9c7c47381755e96dcdc52 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Noel?= 
Date: Sat, 25 Feb 2023 17:59:48 +0100
Subject: [PATCH] Compatibility for ykman 5

---
 py/yubikey.py | 93 ++-
 1 file changed, 84 insertions(+), 9 deletions(-)

diff --git a/py/yubikey.py b/py/yubikey.py
index 592f215..bfec19b 100644
--- a/py/yubikey.py
+++ b/py/yubikey.py
@@ -20,9 +20,7 @@
 
 from fido2.ctap import CtapError
 from fido2.ctap2 import Ctap2, ClientPin, FPBioEnrollment, CredentialManagement, CaptureError
-from ykman.device import scan_devices, list_all_devices, connect_to_device, get_name, read_info
 from ykman.pcsc import list_readers, list_devices as list_ccid
-from ykman.otp import PrepareUploadFailed, generate_static_pw, prepare_upload_key, time_challenge, format_oath_code
 from ykman.settings import AppData
 from ykman.oath import is_hidden, is_steam, calculate_steam
 from ykman.scancodes import KEYBOARD_LAYOUT, encode
@@ -44,6 +42,18 @@
 
 import pyotherside
 
+from ykman import __version__ as ykman_v
+
+if int(ykman_v.split(".")[0] ) > 4:
+from yubikit.support import get_name, read_info
+from ykman.device import list_all_devices, scan_devices
+from ykman.otp import (
+_PrepareUploadFailed as PrepareUploadFailed
+, _prepare_upload_key as prepare_upload_key, generate_static_pw, time_challenge, format_oath_code)
+else:
+from ykman.device import scan_devices, list_all_devices, get_name, read_info
+from ykman.otp import PrepareUploadFailed, generate_static_pw, prepare_upload_key, time_challenge, format_oath_code
+
 
 logger = logging.getLogger(__name__)
 
@@ -193,7 +203,22 @@ def _open_device(self, connection_types=[SmartCardConnection, FidoConnection, Ot
 return dev.open_connection(connection_types[0])
 else:
 raise ValueError('no_device_custom_reader')
-return connect_to_device(self._current_serial, connection_types=connection_types)[0]
+
+if int(ykman_v.split(".")[0] ) > 4:
+devs = list_all_devices(connection_types)
+if len(devs) == 0:
+raise Exception("No YubiKey connected")
+elif len(devs) != 1:
+raise Exception("More than one YubiKey connected")
+dev, info2 = devs[0]
+
+for conn_type in connection_types:
+try:
+return dev.open_connection(conn_type)
+except Exception:
+logger.debug(f"Failed connecting to the YubiKey over {conn_type}", exc_info=True)
+else:
+return connect_to_device(self._current_serial, connection_types=connection_types)[0]
 
 def _open_oath(self):
 if self._reader_filter:
@@ -203,7 +228,16 @@ def _open_oath(self):
 else:
 raise ValueError('no_device_custom_reader')
 
-return connect_to_device(self._current_serial, [SmartCardConnection])[0]
+if int(ykman_v.split(".")[0] ) > 4:
+devs = list_all_devices([SmartCardConnection])
+if len(devs) == 0:
+raise Exception("No YubiKey connected")
+elif len(devs) != 1:
+raise Exception("More than one YubiKey connected")
+dev, info2 = devs[0]
+return dev.open_connection(SmartCardConnection)
+else:
+return connect_to_device(self._current_serial, [SmartCardConnection])[0]
 
 def is_win_non_admin(self):
 return success({'winNonAdmin': self._win_non_admin})
@@ -284,7 +318,39 @@ def _get_version(dev):
 supported_interfaces = interfaces_from_capabilities(
 info.supported_capabilities.get(TRANSPORT.USB))
 
-return {
+if int(ykman_v.split(".")[0] ) > 4:
+  return {
+'name': get_name(info, dev.pid.yubikey_type),
+'version': _get_version(info),
+'serial': info.serial or '',
+'usbAppEnabled': [
+a.name for a in CAPABILITY
+if a in info.config.enabled_capabilities.get(TRANSPORT.USB)],
+'usbAppSupported': [
+a.name for a in CAPABILITY
+if a in info.supported_capabilities.get(TRANSPORT.USB)],
+'nfcAppEnabled': [
+a.name for a in CAPABILITY
+if a in info.config.enabled_capabilities.get(TRANSPORT.NFC, [])],
+'nfcAppSupported': [
+a.name for a in CAPABILITY
+if a in info.supported_capabilities.get(TRANSPORT.NFC, [])],
+

Bug#1060728: tulip: Please port from sip4 to sip6

[Dmitry Shachnev]

Package: tulip
Version: 5.4.0+dfsg-3
Severity: important
Usertags: sip6

Dear Maintainer,

Your package currently builds with sip4, which is a deprecated version of SIP.
The modern version of SIP is packaged as sip6.

The documentation on how to use modern SIP is available in sip6-doc package,
or on the SIP website [1]. The recommended approach is using SIP's own
PEP 517-compliant build system (i.e. pyproject.toml and project.py files),
however some projects (e.g. krita upstream) have successfully integrated SIP 6
into their CMake-based build systems.

SIP 4 has an RC bug related to Python 3.12 [2] and it's unlikely to be fixed.

Please port this package to SIP 6, and after that is done, remove build-dep
on python3-sip-dev and runtime dependency on python3-sip.

[1]: https://www.riverbankcomputing.com/static/Docs/sip/
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059648

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Sat, Jan 13, 2024 at 11:45:29AM +0100, Arno Lehmann wrote:
> Package: src:linux
> Version: 6.1.69-1
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> 
> just having the computer run for a while, the network loses connection because
> the NIC detached from PCIe. I suspect this is related to power management but
> am not really sure.
> 
> As this seemed to be a known problem, I added pcie_aspm=off to the kernel
> command line.
> 
> The problem happens more or less randomly, the computer is usually running 
> 24/7:
> 
> # journalctl --grep 'PCIe link lost' --quiet | cat
> Sep 20 14:21:17 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device 
> now detached
> Okt 06 05:44:20 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device 
> now detached
> Okt 07 16:39:10 Zwerg kernel: igc :0a:00.0 (unnamed net_device) 
> (uninitialized): PCIe link lost, device now detached
> Okt 23 18:31:25 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device 
> now detached
> Okt 30 11:16:06 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device 
> now detached
> Okt 31 13:50:06 Zwerg kernel: igc :0a:00.0 (unnamed net_device) 
> (uninitialized): PCIe link lost, device now detached
> Nov 22 18:59:11 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device 
> now detached
> Nov 23 15:45:49 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device 
> now detached
> Dez 19 07:33:02 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device 
> now detached
> Jan 01 09:57:40 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device 
> now detached
> Jan 10 16:15:20 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device 
> now detached
> Jan 13 11:16:31 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device 
> now detached
> 
> 
> This is what I find in the kernel or system log:
> 
> Jan 13 11:16:31 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device 
> now detached
> Jan 13 11:16:31 Zwerg kernel: [ cut here ]
> Jan 13 11:16:31 Zwerg kernel: igc: Failed to read reg 0xc030!
> Jan 13 11:16:31 Zwerg kernel: WARNING: CPU: 18 PID: 6389 at 
> drivers/net/ethernet/intel/igc/igc_main.c:6482 igc_rd32+0x91/0xa0 [igc]
> Jan 13 11:16:31 Zwerg kernel: Modules linked in: rfcomm cpufreq_userspace 
> cpufreq_powersave cpufreq_ondemand cpufreq_conservative nfsv3 nfs_acl rpcs>
> Jan 13 11:16:31 Zwerg kernel:  configfs efivarfs ip_tables x_tables autofs4 
> xfs libcrc32c crc32c_generic dm_crypt dm_mod hid_generic amdgpu crc32_pc>
> Jan 13 11:16:31 Zwerg kernel: CPU: 18 PID: 6389 Comm: kworker/18:1 Not 
> tainted 6.1.0-17-amd64 #1  Debian 6.1.69-1
> Jan 13 11:16:31 Zwerg kernel: Hardware name: ASUS System Product Name/ROG 
> STRIX X670E-A GAMING WIFI, BIOS 1410 04/28/2023
> Jan 13 11:16:31 Zwerg kernel: Workqueue: events igc_watchdog_task [igc]
> Jan 13 11:16:31 Zwerg kernel: RIP: 0010:igc_rd32+0x91/0xa0 [igc]
> Jan 13 11:16:31 Zwerg kernel: Code: 48 c7 c6 d0 55 56 c0 e8 0b 7d 6c f8 48 8b 
> bd 28 ff ff ff e8 31 c7 23 f8 84 c0 74 b4 89 de 48 c7 c7 f8 55 56 c0 e>
> Jan 13 11:16:31 Zwerg kernel: RSP: 0018:ac56d5f13df0 EFLAGS: 00010286
> Jan 13 11:16:31 Zwerg kernel: RAX:  RBX: c030 
> RCX: 0027
> Jan 13 11:16:31 Zwerg kernel: RDX: a046f85a03a8 RSI: 0001 
> RDI: a046f85a03a0
> Jan 13 11:16:31 Zwerg kernel: RBP: a03f45710c28 R08:  
> R09: ac56d5f13c68
> Jan 13 11:16:31 Zwerg kernel: R10: 0003 R11: a04717f7ffe8 
> R12: a03f4571
> Jan 13 11:16:31 Zwerg kernel: R13:  R14: a03f456efd40 
> R15: c030
> Jan 13 11:16:31 Zwerg kernel: FS:  () 
> GS:a046f858() knlGS:
> Jan 13 11:16:31 Zwerg kernel: CS:  0010 DS:  ES:  CR0: 
> 80050033
> Jan 13 11:16:31 Zwerg kernel: CR2: 7f1fc894f000 CR3: 0008a8538000 
> CR4: 00750ee0
> Jan 13 11:16:31 Zwerg kernel: PKRU: 5554
> Jan 13 11:16:31 Zwerg kernel: Call Trace:
> Jan 13 11:16:31 Zwerg kernel:  
> 
> 
> Obviously, the kernel parameter to disable PCIe power management was not 
> solving this problem.
> 
> The way to recover is to restart the computer.

Just to be clear, can you confirm this is or is not a regression from
a previous running 6.1.y kernel? I'm asking because I suspect that
this similar to
https://lore.kernel.org/intel-wired-lan/20221031170535.77be0...@kernel.org/
and did not ever worked reliably with your hardware?

Regards,
Salvatore

Bug#848268: RFP: opentoonz -- 2D animation software

[Zeke Williams]

It's a been a number of years since this bug report/feature request
has been opened. Can this been packaged for debian 13? Because the one
and only reason I would use deb-multimedia is for OpenToonz native
debs. A lot has changed since this was requested, it's at 1.7 right
now with 1.8 coming out later this may. Is there any blocker for this?
If you want to patch in a different libtiff, a fork of OpenToonz
called Tahoma2D uses an updated libtiff rather than the modified
version provided. You could see how and what it does to make a patch
for when building the deb.

https://github.com/tahoma2d/tahoma2d

Thank you for your hard work and I hope this makes it into debian 13,
making debian even better.

Bug#1060465: gnome-control-center: crashes loading System panel if gnome-remote-desktop is missing

[Jeremy Bícha]

On Sat, Jan 13, 2024 at 5:24 AM Josh Triplett  wrote:
> I do continue to feel that having gnome-remote-desktop installed and
> *enabled* by default feels risky in a similar way to having an installed
> sshd on a system that shouldn't be remotely accessed. But, of course, we
> cannot have settings pages crashing, either.

GNOME Remote Desktop is still available but not enabled by default as
of GNOME 45 in Debian Unstable or Testing.

This can also be verified by running

systemctl --user status gnome-remote-desktop.service

I need to get freerdp3 packaged before I can test the headless mode
for GNOME 46. I'm going to work on that this month because this is
such a major feature that early testing could be helpful.

Thank you,
Jeremy Bícha

Bug#993849: RE. authenticator

[Bastian Germann]

Hi Matthias,

On Fri, 14 Jul 2023 00:59:43 +0200 Matthias Geiger  wrote:
If my tracking spreadsheet is correct (rust) authenticator is 
still missing five crates:


scrypt, search-provider, libadwaita, gst-plugin-gtk4 and aes-gcm.


They are all available (gst-plugin-gtk4 in experimental) now.
Are you going to upload the new version soon?
The git repo should be moved over to the GNOME Team. Is there anybody with 
sufficient rights?

Thanks,
Bastian

Bug#1041089: thin-provisioning-tools FTBFS with googletest 1.13.0

[Bastian Blank]

On Sat, Jan 13, 2024 at 01:03:17AM +0100, Karsten Kruse wrote:
> Is there something else that needs to be done to get the package back into
> testing?

Yes,
https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/547

Bastian

-- 
If I can have honesty, it's easier to overlook mistakes.
-- Kirk, "Space Seed", stardate 3141.9

Bug#1060457: /usr/sbin/exim4: SIGSEGV when remote smtp reject the message

[Giuseppe Sacco]

Hello Andreas,

Il giorno ven, 12/01/2024 alle 18.15 +0100, Andreas Metzler ha scritto:
[...]
> Is this a regression in 4.96-15+deb12u4? i.e. can you still reprroduce
> the issue after downgrading exim4-daemon-heavy to 4.96-15+deb12u3 [1]
> (and re-reproduce after upgrading again)?

I am going to downgrade the package and let it run for a week. I'll report
here.

Thank you,
Giuseppe

Bug#1060005: cifs-utils: Copy file with cp, hangs with a kernel NULL pointer dereference.

[Salvatore Bonaccorso]

Hi

A fix for this issue has been queued for the 6.1.y series:

https://lore.kernel.org/stable/zajygki9o5j1u...@eldamar.lan/T/#m934ca5a14db8bcef8f24329c7edee8a3592465b2

If someone additionally might or want to test testbuilds please have a
look at:

https://people.debian.org/~carnil/tmp/linux/1060005/

The builds are signed with my key in the Debian keyring.

Regards,
Salvatore

Bug#1011558: Not going to do this

[Wouter Verhelst]

Control: severity -1 wishlist
Control: tags -1 wontfix
Thanks

The problem with this is that the config file ships statically, and detecting 
which distribution you're running is actually quite complicated due to the fact 
that people may have multiple distributions enabled but then use various 
intricate apt pinning configurations to decide which distribution to prefer, if 
any.

The current situation is that we default to the code name of whatever 
distribution the extrepo package is in (except in unstable, because the package 
does not change when migrating to testing), which seems like the best 
possibility here, given the existing constraints.

I did want to give this some thought, but I don't see a way to make this work, 
and if you're using unstable and would prefer that, then having to edit a 
config file is not too hard.
-- 
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.

Bug#1054446: bookworm-pu: package wolfssl/5.5.4-2+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2024-01-13 at 00:10 +0100, Bastian Germann wrote:
> On Tue, 26 Dec 2023 12:04:50 + "Adam D. Barratt"
>  wrote:
> > 
> 
> Did you want to tell me to proceed with the upload?

I have no idea what happened there. :-(

Yes, that was the intention. Please use Closes: as usual, as Salvatore
indicated.

Regards,

Adam

Bug#1060465: gnome-control-center: crashes loading System panel if gnome-remote-desktop is missing

[Josh Triplett]

On Thu, 11 Jan 2024 18:00:58 -0500 =?UTF-8?Q?Jeremy_B=C3=ADcha?= 
 wrote:
> On Thu, Jan 11, 2024 at 5:27 PM Arnaud Ferraris  wrote:
> > Package: gnome-control-center
> > Version: 1:46~alpha-1
> …
> >
> > On a system without gnome-remote-desktop, trying to access the "System" 
> > panel
> > (containing the "Users", "Date & Time" panels among other important things)
> > results in a crash with the following message:
> >
> >   GLib-GIO[25147]: ERROR: Settings schema 'org.gnome.desktop.remote-
> > desktop.rdp' is not installed
> >
> > I believe either g-c-c should handle the lack of gnome-remote-desktop more
> > gracefully, or the latter should be promoted to Depends instead of 
> > Recommends.
> 
> Ok, I'll promote gnome-remote-desktop to Depends again.
> 
> Josh, I remember you complained about this dependency in
> https://bugs.debian.org/1014879
> 
> GNOME Remote Desktop is going to be more tightly entwined in GNOME 46
> to support the new integrated "headless" mode allowing remote access
> even when the user is not already logged into the host computer. It
> doesn't feel feasible to me to make this dependency optional because
> of the integration in gnome-session, gdm3, gnome-settings-daemon, and
> as a separate page in gnome-control-center.

I appreciate that, and I understand.

I do continue to feel that having gnome-remote-desktop installed and
*enabled* by default feels risky in a similar way to having an installed
sshd on a system that shouldn't be remotely accessed. But, of course, we
cannot have settings pages crashing, either.

For the "headless" mode, would it be possible to confirm that it isn't
enabled by default, that nothing is running if it *isn't* enabled, and
that it requires administrator permissions to enable? (e.g. enabling the
requisite setting should require a policykit prompt.)

For the per-user version, would it be possible to similarly confirm that
it isn't enabled by default, and thus there's *no* remote socket
connection without it first being explicitly enabled, not even a
socket-activateable connection?

Bug#1057040: firmware-qcom-soc: please add qcom/sc8280xp/LENOVO/21BX/audioreach-tplg.bin and symlink

[Emanuele Rocca]

On Tue, Nov 28, 2023 at 02:29:28PM +0100, Emanuele Rocca wrote:
> The file qcom/sc8280xp/LENOVO/21BX/audioreach-tplg.bin and its symlink
> qcom/sc8280xp/SC8280XP-LENOVO-X13S-tplg.bin are needed by the Lenovo
> Thinkpad X13s. Please consider adding them to firmware-qcom-soc.
> 
> File: qcom/sc8280xp/LENOVO/21BX/audioreach-tplg.bin
> Link: qcom/sc8280xp/SC8280XP-LENOVO-X13S-tplg.bin -> 
> LENOVO/21BX/audioreach-tplg.bin

The following merge request implements the changes above:
https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/75

FTR this issue is the last missing piece to get working audio on the Thinkpad
X13s. :-)

Bug#1060698: [Pkg-auth-maintainers] Bug#1060698: yubioath-desktop: Doesn't see yubikeys anymore.

[Florian Schlichting]

Hi Freagarach,

On Sat, Jan 13, 2024 at 07:40:42AM +0100, Freagarach wrote:
> since yesterday the problem holding back python3-ykman (and related packages) 
> was resolved, I upgraded my system today.
> When trying to use the GUI for yubikeys (this package), my yubikeys were not 
> shown. I could use the terminal (yubikey-manager CLI) to do my tasks.
> 
> It seems that this package relies on a lower version of its dependencies. I 
> can't really test due to the dependency issues that introduces.

apparently, yes. Starting yubioath-desktop from the commandline, I get

$  yubioath-desktop
qrc:/qml/main.qml:305:5: QML Shortcut: Shortcut: Only binding to one of 
multiple key bindings associated with 7. Use 'sequences: [  ]' to bind to 
all of them.
qrc:/qml/main.qml:297:5: QML Shortcut: Shortcut: Only binding to one of 
multiple key bindings associated with 9. Use 'sequences: [  ]' to bind to 
all of them.
Qt Quick Layouts: Detected recursive rearrange. Aborting after two iterations.
Qt Quick Layouts: Detected recursive rearrange. Aborting after two iterations.
"PyOtherSide error: Traceback (most recent call last):\n\n  File 
\"qrc:///py/yubikey.py\", line 23, in \nfrom ykman.device import 
scan_devices, list_all_devices, connect_to_device, get_name, 
read_info\n\nImportError: cannot import name 'connect_to_device' from 
'ykman.device' (/usr/lib/python3/dist-packages/ykman/device.py)\n"
Unhandled PyOtherSide error: Cannot import module: yubikey (Traceback (most 
recent call last):

  File "qrc:///py/yubikey.py", line 23, in 
from ykman.device import scan_devices, list_all_devices, connect_to_device, 
get_name, read_info

ImportError: cannot import name 'connect_to_device' from 'ykman.device' 
(/usr/lib/python3/dist-packages/ykman/device.py)
)
"PyOtherSide error: Traceback (most recent call last):\n\n  File \"\", 
line 1, in \n\nNameError: name 'yubikey' is not defined\n"
Unhandled PyOtherSide error: Function not found: 'yubikey.init' (Traceback 
(most recent call last):

  File "", line 1, in 

NameError: name 'yubikey' is not defined
)
"PyOtherSide error: Traceback (most recent call last):\n\n  File \"\", 
line 1, in \n\nNameError: name 'yubikey' is not defined\n"
Unhandled PyOtherSide error: Function not found: 
'yubikey.controller.check_descriptors' (Traceback (most recent call last):

  File "", line 1, in 

NameError: name 'yubikey' is not defined
)
qml: TypeError: Cannot read property 'success' of undefined undefined
"PyOtherSide error: Traceback (most recent call last):\n\n  File \"\", 
line 1, in \n\nNameError: name 'yubikey' is not defined\n"
Unhandled PyOtherSide error: Function not found: 
'yubikey.controller.is_win_non_admin' (Traceback (most recent call last):

  File "", line 1, in 

NameError: name 'yubikey' is not defined
)
qml: TypeError: Cannot read property 'winNonAdmin' of undefined undefined


> I know there is #1034701, so this report might be considered an escalation of 
> that, but I'm not too comfortable (yet) with Debian policies.

I fear this means the end of yubioath-desktop in Debian, as long as
flutter isn't packaged (see #931793). The "legacy" branch on Github
doesn't seem to have received any commits since the release of version
6.0.0. While it might be possible to patch py/yubikey.py to work with the
interface changes in current python3-ykman, I doubt this is a sensible
thing to do if upstream has decided to abandon the QT version.

Florian

Bug#1056504: python-sparse's autopkg tests fail with Python 3.12

[Nilesh Patra]

On Sat, Jan 13, 2024 at 09:03:07AM +0100, Andreas Tille wrote:
> This is surely due to the removal of versioneer in upstream commit
> 6fca42bc1cd0acea2153b074658b834231a4d00f  - but I can't imaginge upstream
> simply left the according responsible line
> 
> sparse/__init__.py:from ._version import __version__, __version_tuple__  # 
> noqa: F401
> 
> and did not noticed that tests are failing.  Am I missing something?

Fixed in Git, please check.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1060704: transition: dcmtk

[Mathieu Malaterre]

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

I'd like to migrate to dcmtk 3.6.8. This is a standard SONAME transition.

Current status in exp:
https://buildd.debian.org/status/package.php?p=dcmtk=experimental

Thanks

Bug#1060705: grub-pc: Symbol grub_env_get not found

[Bastian Germann]

Package: grub-pc
Severity: grave
Version: 2.12~rc1-12+b1

Hi,

Booting my i386 sid installation after an update fails because grub cannot find 
one of its symbols.
I cannot even boot to an initramfs but I can run a grub shell.

I guess this is an issue introduced by the recent binNMU because I think before 
I have updated to 2.12~rc1-12.
Thanks for any hint.

Cheers,
Bastian

Bug#1053866: transition: jpeg-xl

[Mathieu Malaterre]

On Tue, Oct 17, 2023 at 6:04 PM Sebastian Ramacher  wrote:
>
> Hi Mathieu
>
> On 2023-10-13 16:42:34 +0200, Mathieu Malaterre wrote:
> > On Fri, Oct 13, 2023 at 11:57 AM Sebastian Ramacher
> >  wrote:
> > >
> > > Control: tags -1 moreinfo
> > > Control: forwarded -1 
> > > https://release.debian.org/transitions/html/auto-jpeg-xl.html
> > >
> > > On 2023-10-13 10:44:31 +0200, Mathieu Malaterre wrote:
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > User: release.debian@packages.debian.org
> > > > Usertags: transition
> > > >
> > > > This is a minor SONAME transiton. Two (unused anywhere) symbols were
> > > > removed.
> > >
> > > Are the reverse dependencies known to build with the new version?
> >
> > Nope. I've requested an account on debomatic-amd64 to run the following:
> >
> > % cat jxl.commands
> > rebuild ffmpeg_7:6.0-7 unstable experimental
> > rebuild geeqie_1:2.1-1 unstable experimental
> > rebuild gimp_2.10.34-1 unstable experimental
> > rebuild graphicsmagick_1.4+really1.3.42-1 unstable experimental
> > rebuild imlib2_1.12.1-1 unstable experimental
> > rebuild kimageformats_5.107.0-3 unstable experimental
> > rebuild krita_1:5.2.0+dfsg-1 unstable experimental
> > rebuild swayimg_1.12-1 unstable experimental
> > rebuild vips_8.14.5-1 unstable experimental
> > rebuild webkit2gtk_2.42.1-2 unstable experimental
> > rebuild wpewebkit_2.42.1-1 unstable experimental
> >
> >
> > will post back when I get access.
>
> Alright, thanks. Please let us know as soon as you have the results.

Turns out, I cannot connect to debomatic-amd64 online service. Is
there an alternate solution for me to rebuild a large set of packages
automatically ?

Thanks!

Bug#1060706: linux-image-6.1.0-17-amd64: intel i225 NIC loses PCIe link, network becomes unusable

[Arno Lehmann]

Package: src:linux
Version: 6.1.69-1
Severity: normal
Tags: upstream

Dear Maintainer,


just having the computer run for a while, the network loses connection because
the NIC detached from PCIe. I suspect this is related to power management but
am not really sure.

As this seemed to be a known problem, I added pcie_aspm=off to the kernel
command line.

The problem happens more or less randomly, the computer is usually running 24/7:

# journalctl --grep 'PCIe link lost' --quiet | cat
Sep 20 14:21:17 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Okt 06 05:44:20 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Okt 07 16:39:10 Zwerg kernel: igc :0a:00.0 (unnamed net_device) 
(uninitialized): PCIe link lost, device now detached
Okt 23 18:31:25 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Okt 30 11:16:06 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Okt 31 13:50:06 Zwerg kernel: igc :0a:00.0 (unnamed net_device) 
(uninitialized): PCIe link lost, device now detached
Nov 22 18:59:11 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Nov 23 15:45:49 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Dez 19 07:33:02 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Jan 01 09:57:40 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Jan 10 16:15:20 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Jan 13 11:16:31 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached


This is what I find in the kernel or system log:

Jan 13 11:16:31 Zwerg kernel: igc :0a:00.0 eno1: PCIe link lost, device now 
detached
Jan 13 11:16:31 Zwerg kernel: [ cut here ]
Jan 13 11:16:31 Zwerg kernel: igc: Failed to read reg 0xc030!
Jan 13 11:16:31 Zwerg kernel: WARNING: CPU: 18 PID: 6389 at 
drivers/net/ethernet/intel/igc/igc_main.c:6482 igc_rd32+0x91/0xa0 [igc]
Jan 13 11:16:31 Zwerg kernel: Modules linked in: rfcomm cpufreq_userspace 
cpufreq_powersave cpufreq_ondemand cpufreq_conservative nfsv3 nfs_acl rpcs>
Jan 13 11:16:31 Zwerg kernel:  configfs efivarfs ip_tables x_tables autofs4 xfs 
libcrc32c crc32c_generic dm_crypt dm_mod hid_generic amdgpu crc32_pc>
Jan 13 11:16:31 Zwerg kernel: CPU: 18 PID: 6389 Comm: kworker/18:1 Not tainted 
6.1.0-17-amd64 #1  Debian 6.1.69-1
Jan 13 11:16:31 Zwerg kernel: Hardware name: ASUS System Product Name/ROG STRIX 
X670E-A GAMING WIFI, BIOS 1410 04/28/2023
Jan 13 11:16:31 Zwerg kernel: Workqueue: events igc_watchdog_task [igc]
Jan 13 11:16:31 Zwerg kernel: RIP: 0010:igc_rd32+0x91/0xa0 [igc]
Jan 13 11:16:31 Zwerg kernel: Code: 48 c7 c6 d0 55 56 c0 e8 0b 7d 6c f8 48 8b 
bd 28 ff ff ff e8 31 c7 23 f8 84 c0 74 b4 89 de 48 c7 c7 f8 55 56 c0 e>
Jan 13 11:16:31 Zwerg kernel: RSP: 0018:ac56d5f13df0 EFLAGS: 00010286
Jan 13 11:16:31 Zwerg kernel: RAX:  RBX: c030 RCX: 
0027
Jan 13 11:16:31 Zwerg kernel: RDX: a046f85a03a8 RSI: 0001 RDI: 
a046f85a03a0
Jan 13 11:16:31 Zwerg kernel: RBP: a03f45710c28 R08:  R09: 
ac56d5f13c68
Jan 13 11:16:31 Zwerg kernel: R10: 0003 R11: a04717f7ffe8 R12: 
a03f4571
Jan 13 11:16:31 Zwerg kernel: R13:  R14: a03f456efd40 R15: 
c030
Jan 13 11:16:31 Zwerg kernel: FS:  () 
GS:a046f858() knlGS:
Jan 13 11:16:31 Zwerg kernel: CS:  0010 DS:  ES:  CR0: 80050033
Jan 13 11:16:31 Zwerg kernel: CR2: 7f1fc894f000 CR3: 0008a8538000 CR4: 
00750ee0
Jan 13 11:16:31 Zwerg kernel: PKRU: 5554
Jan 13 11:16:31 Zwerg kernel: Call Trace:
Jan 13 11:16:31 Zwerg kernel:  


Obviously, the kernel parameter to disable PCIe power management was not 
solving this problem.

The way to recover is to restart the computer.


-- Package-specific info:
** Version:
Linux version 6.1.0-17-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-17-amd64 root=/dev/mapper/Zwerg--vg-root ro 
pcie_aspm=off quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: ASUS
product_name: System Product Name
product_version: System Version
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: 1410
board_vendor: ASUSTeK COMPUTER INC.
board_name: ROG STRIX X670E-A GAMING WIFI
board_version: Rev 1.xx

** Loaded modules:
rfcomm
cpufreq_userspace
cpufreq_powersave
cpufreq_ondemand
cpufreq_conservative
nfsv3
nfs_acl
rpcsec_gss_krb5
auth_rpcgss
nfsv4
dns_resolver
nfs
lockd
grace
fscache
netfs
qrtr
overlay
cmac
algif_hash
algif_skcipher
af_alg
bnep
sunrpc

Bug#1060702: tcl-itcl4-dev: incr Tcl programs do not compile with tcl8.7-dev

[Rafael Laboissière]

Package: tcl-itcl4-dev
Version: 4.2.3-1
Severity: important
Tags: upstream patch

With the versions of tcl-itcl4-dev (4.2.3-1) and tcl8.7-dev 
(8.7.0~a5+dfsg-3) currently in experimental, this simple example does 
not work:

$ echo "#include " > test.c
$ gcc -c test.c -I/usr/include/tcl
In file included from test.c:1:
/usr/include/itcl/itcl.h:144:5: error: unknown type name 'Tcl_Size'
  144 | Tcl_Size len;  /* number of values on stack */
  | ^~~~
/usr/include/itcl/itcl.h:145:5: error: unknown type name 'Tcl_Size'
  145 | Tcl_Size max;  /* maximum size of stack */
  | ^~~~
/usr/include/itcl/itcl.h:164:5: error: unknown type name 'Tcl_Size'
  164 | Tcl_Size num;  /* number of elements */
  | ^~~~

It does work in unstable.

Currently, in experimental, tcl-dev depends on tcl8.7-dev. If this 
packages migrate into unstable, then tcl-itcl4-dev will be broken in a 
serious way. Hence, I am am hereby setting the severity level to 
important.

The patch attached to this bug report seems to fix the problem.

Best,

Rafael

-- System Information: 
Debian Release: 12.0 
  APT prefers testing 
  APT policy: (650, 'testing'), (600, 'unstable') 
Architecture: amd64 (x86_64)

Kernel: Linux 4.18.0-2-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tcl-itcl4-dev depends on: 
pn  tcl-dev 
pn  tcl-itcl4  

tcl-itcl4-dev recommends no packages.

Versions of packages tcl-itcl4-dev suggests: 
pn  tcl-itcl4-doc  
diff -Nru itcl4-4.2.3/debian/changelog itcl4-4.2.3/debian/changelog
--- itcl4-4.2.3/debian/changelog2022-11-27 08:34:33.0 -0300
+++ itcl4-4.2.3/debian/changelog2024-01-13 04:53:27.0 -0300
@@ -1,3 +1,10 @@
+itcl4 (4.2.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * d/p/tcl-size-define.patch: New patch
+
+ -- Rafael Laboissière   Sat, 13 Jan 2024 04:53:27 -0300
+
 itcl4 (4.2.3-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru itcl4-4.2.3/debian/patches/series itcl4-4.2.3/debian/patches/series
--- itcl4-4.2.3/debian/patches/series   2022-11-27 08:34:33.0 -0300
+++ itcl4-4.2.3/debian/patches/series   2024-01-13 04:53:27.0 -0300
@@ -1 +1 @@
-# nothing here
+tcl-size-define.patch
diff -Nru itcl4-4.2.3/debian/patches/tcl-size-define.patch 
itcl4-4.2.3/debian/patches/tcl-size-define.patch
--- itcl4-4.2.3/debian/patches/tcl-size-define.patch1969-12-31 
21:00:00.0 -0300
+++ itcl4-4.2.3/debian/patches/tcl-size-define.patch2024-01-13 
04:41:42.0 -0300
@@ -0,0 +1,16 @@
+Description: Allow compilation with Tcl 8.7
+Author: Rafael Laboissière 
+Forwarded: no
+Last-Update: 2024-01-13
+
+--- itcl4-4.2.3.orig/generic/itcl.h
 itcl4-4.2.3/generic/itcl.h
+@@ -132,7 +132,7 @@ ITCL_EXTERN int Itcl_SafeInit(Tcl_Interp
+ #define ITCL_PRIVATE  3
+ #define ITCL_DEFAULT_PROTECT  4
+ 
+-#if (TCL_MAJOR_VERSION == 8) && (TCL_MINOR_VERSION < 7) && !defined(Tcl_Size)
++#if (TCL_MAJOR_VERSION == 8) && (TCL_MINOR_VERSION < 8) && !defined(Tcl_Size)
+ #define Tcl_Size int
+ #endif
+ 

Bug#1043311: [Pkg-rust-maintainers] Bug#1043311: rustc: please enable profiler builtin

[Andres Salomon]

On 1/13/24 02:42, Andres Salomon wrote:
On Fri, 08 Sep 2023 13:35:44 -0400 Andres Salomon 
 wrote:

>
>
> On Fri, Sep 8 2023 at 10:36:48 AM +02:00:00, Fabian Grünbichler
>  wrote:
> >>  On Tue, Aug 8 2023 at 06:22:28 PM -04:00:00, Andres Salomon
> >>
> [...]
> >>
> >>  This patch adds
> >> "cargo:rustc-link-search=/usr/lib/clang/15/lib/linux/" and
> >> "cargo:rustc-link-lib=static=clang_rt.profile-x86_64" (or whatever
> >>  architecture it happens to be building on) to the profiler_builtins
> >> build
> >>  flags when the target matches the host. In the case where the
> >> target is
> >>  different from the host, it assumes a wasm build and sets
> >>  "rustc-link-lib=static=clang_rt.builtins-wasm32" or
> >> "cargo:rustc-link-lib=static=clang_rt.builtins-wasm64" depending
> >> upon
> >>  whether the target is 32 or 64 bits, respectively.
> >
> > Thanks for the patch! the Windows part in d/rules looks wrong to me -
> > that is built with mingw, not wasi. I assume you are not 
interested in

> > that part, so maybe it would also be an option to guard it based on
> > target and just build it for the regular one (or regular+wasm, but 
not

> > windows/mingw)?
>

After you pointed out the upstream patch on IRC 
(https://github.com/rust-lang/rust/pull/114069), I backported it to 
1.70 and tried building it. It gets pretty far, but fails late in the 
build on some tests. I'm going to do some more building (starting with 
rustc by itself without the profiler stuff, to ensure that the test 
failure I'm seeing is actually related to profiler). But in the 
meantime, here's the backported patch. If I can get it fully built, 
I'll follow up with the full debian patch or a merge request.





Ugh, unfortunately I'm hitting the same build failure even without 
profiler enabled. This is just rustc from sid without any changes 
failing. I can file a separate FTBFS bug if it's not some issue with my 
build environment...




 Debian rustc test report 
Specific test failures:
test [ui] tests/ui/io-checks/inaccessbile-temp-dir.rs ... FAILED
test [ui] tests/ui/io-checks/non-ice-error-on-worker-io-fail.rs ... FAILED
command did not execute successfully: BOOTSTRAP_CARGO="/usr/bin/cargo" 
DOC_RUST_LANG_ORG_CHANNEL="https://doc.rust-lang.org/1.70.0; 
LD_LIBRARY_PATH="/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/stage0-bootstrap-tools/x86_64-unknown-linux-gnu/release/deps:/usr/lib" 
RUSTC="/usr/bin/rustc" RUSTC_BOOTSTRAP="1" 
RUSTC_FORCE_RUSTC_VERSION="compiletest" RUST_TEST_THREADS="16" 
RUST_TEST_TMPDIR="/rustc-1.70.0+dfsg1/build/tmp" 
"/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" 
"--compile-lib-path" 
"/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/stage2/lib" 
"--run-lib-path" 
"/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" 
"--rustc-path" 
"/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" 
"--src-base" "/rustc-1.70.0+dfsg1/tests/ui" "--build-base" 
"/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/test/ui" 
"--sysroot-base" 
"/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/stage2" "--stage-id" 
"stage2-x86_64-unknown-linux-gnu" "--suite" "ui" "--mode" "ui" 
"--target" "x86_64-unknown-linux-gnu" "--host" 
"x86_64-unknown-linux-gnu" "--llvm-filecheck" 
"/usr/lib/llvm-16/bin/FileCheck" "--nodejs" "/usr/bin/node" 
"--optimize-tests" "--target-linker" "x86_64-linux-gnu-gcc" 
"--host-linker" "x86_64-linux-gnu-gcc" "--host-rustcflags" "-Crpath" 
"--host-rustcflags" "-Cdebuginfo=0" "--host-rustcflags" 
"-Lnative=/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" 
"--target-rustcflags" "-Crpath" "--target-rustcflags" "-Cdebuginfo=0" 
"--target-rustcflags" 
"-Lnative=/rustc-1.70.0+dfsg1/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" 
"--python" "/usr/bin/python3" "--gdb" "/usr/bin/gdb" "--skip" 
"src/tools/tidy" "--verbose" "--json" "--llvm-version" "16.0.6" 
"--llvm-components" "aarch64 aarch64asmparser aarch64codegen aarch64desc 
aarch64disassembler aarch64info aarch64utils aggressiveinstcombine all 
all-targets amdgpu amdgpuasmparser amdgpucodegen amdgpudesc 
amdgpudisassembler amdgpuinfo amdgputargetmca amdgpuutils analysis arm 
armasmparser armcodegen armdesc armdisassembler arminfo armutils 
asmparser asmprinter avr avrasmparser avrcodegen avrdesc avrdisassembler 
avrinfo binaryformat bitreader bitstreamreader bitwriter bpf 
bpfasmparser bpfcodegen bpfdesc bpfdisassembler bpfinfo cfguard codegen 
core coroutines coverage debuginfocodeview debuginfodwarf debuginfogsym 
debuginfologicalview debuginfomsf debuginfopdb demangle dlltooldriver 
dwarflinker dwarflinkerparallel dwp engine executionengine extensions 
filecheck frontendhlsl frontendopenacc frontendopenmp fuzzercli 
fuzzmutate globalisel hexagon hexagonasmparser hexagoncodegen 
hexagondesc hexagondisassembler hexagoninfo instcombine instrumentation 
interfacestub interpreter ipo irprinter irreader jitlink 

Bug#1060410: /etc/pacpl: Full sid upgrade removed packages dependent on perl-5.36.0-10

[Bartek]

On 1/10/24 20:16, Bartek wrote:

Package: pacpl
Version: 6.1.3-1
Severity: important
File: /etc/pacpl
X-Debbugs-Cc: poem...@gmail.com

Dear Maintainer,


* What was the outcome of this action?
Removing pacpl because it depends on other packages which depend on
perlapi-5.36.0, technically perl-5.36.0

* What outcome did you expect instead?
Bump dependency version to packages to perlapi-5.36.0


Dear Maintainer,

Please close this bug as it has been resolved after last update.

Regards,

Bartek

Bug#1056504: python-sparse's autopkg tests fail with Python 3.12

[Andreas Tille]

Hi,

thanks to Rebecca's hint I've updated python-sparse in Git to the latest
upstream version.  I decided to deactivate all patches.  When trying to build
I'm running into several errors:

  ModuleNotFoundError: No module named 'sparse._version'   [1]

This is surely due to the removal of versioneer in upstream commit
6fca42bc1cd0acea2153b074658b834231a4d00f  - but I can't imaginge upstream
simply left the according responsible line

sparse/__init__.py:from ._version import __version__, __version_tuple__  # 
noqa: F401

and did not noticed that tests are failing.  Am I missing something?

Kind regards
Andreass.

[1] ModuleNotFoundError: No module named 'sparse._version'

-- 
http://fam-tille.de

Bug#1060701: go-git: CVE-2023-49568 CVE-2023-49569

[Salvatore Bonaccorso]

Source: golang-github-go-git-go-git
Version: 5.4.2-4
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for go-git.

CVE-2023-49568[0]:
| A denial of service (DoS) vulnerability was discovered in go-git
| versions prior to v5.11. This vulnerability allows an attacker to
| perform denial of service attacks by providing specially crafted
| responses from a Git server which triggers resource exhaustion in
| go-git clients.  Applications using only the in-memory filesystem
| supported by go-git are not affected by this vulnerability. This is
| a go-git implementation issue and does not affect the upstream
| git cli.


CVE-2023-49569[1]:
| A path traversal vulnerability was discovered in go-git versions
| prior to v5.11. This vulnerability allows an attacker to create and
| amend files across the filesystem. In the worse case scenario,
| remote code execution could be achieved.  Applications are only
| affected if they are using the  ChrootOS
| https://pkg.go.dev/github.com/go-git/go-billy/v5/osfs#ChrootOS ,
| which is the default when using "Plain" versions of Open and Clone
| funcs (e.g. PlainClone). Applications using  BoundOS
| https://pkg.go.dev/github.com/go-git/go-billy/v5/osfs#BoundOS  or
| in-memory filesystems are not affected by this issue. This is a go-
| git implementation issue and does not affect the upstream git cli.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-49568
https://www.cve.org/CVERecord?id=CVE-2023-49568
https://github.com/go-git/go-git/security/advisories/GHSA-mw99-9chc-xw7r
[1] https://security-tracker.debian.org/tracker/CVE-2023-49569
https://www.cve.org/CVERecord?id=CVE-2023-49569
https://github.com/go-git/go-git/security/advisories/GHSA-449p-3h89-pw88

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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

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

Bug#1060703: RFS: golang-golang-x-oauth2/0.15.0-1~bpo12 1 -- Google APIs support for OAuth2

[M Hickford]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "golang-golang-x-oauth2":

 * Package name : golang-golang-x-oauth2
   Version  : 0.15.0-1~bpo12+1
 * URL  : https://golang.org/x/oauth2
 * License  : BSD-3-clause
 * Vcs  :
https://salsa.debian.org/go-team/packages/golang-golang-x-oauth2
   Section  : golang

The source builds the following binary packages:

  golang-golang-x-oauth2-dev - make OAuth2 authorized and
authenticated HTTP requests
  golang-golang-x-oauth2-google-dev - Google APIs support for OAuth2

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

  https://mentors.debian.net/package/golang-golang-x-oauth2/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-golang-x-oauth2/golang-golang-x-oauth2_0.15.0-1~bpo12+1.dsc

Changes since the last upload:

 golang-golang-x-oauth2 (0.15.0-1~bpo12+1) bookworm-backports; urgency=medium
 .
   * Rebuild for bookworm-backports.

Regards,

Bug#1054890: closed by Debian FTP Masters (reply to b...@debian.org (Barak A. Pearlmutter)) (Bug#1054890: fixed in ddccontrol 1.0.0-2)

[Paul Wise]

Control: reopen -1

On Fri, 2024-01-12 at 12:06 +, Barak A. Pearlmutter wrote:

>    * Remove obsolete conffile (closes: #1054890)

This change didn't work, the obsolete conffile is not removed.
You need to use the upload version instead, so 1.0.0-3 instead.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1060729: /usr/lib/x86_64-linux-gnu/pkgconfig/neatvnc.pc: Requires libdrm, libdrm-dev isn't pulled in the dependency list

[наб]

Package: libneatvnc-dev
Version: 0.5.4+dfsg-1
Version: 0.7.1+dfsg-1
Severity: normal
File: /usr/lib/x86_64-linux-gnu/pkgconfig/neatvnc.pc

Dear Maintainer,

After installation,
  $ pkg-config --libs --cflags neatvnc
  Package libdrm was not found in the pkg-config search path.
  Perhaps you should add the directory containing `libdrm.pc'
  to the PKG_CONFIG_PATH environment variable
  Package 'libdrm', required by 'neatvnc', not found

Found on bookworm, AFAICT also affects sid.

Best,
наб

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libneatvnc-dev:amd64 depends on:
ii  libaml-dev0.2.2-1
ii  libgnutls28-dev [gnutls-dev]  3.7.9-2+deb12u1
ii  libneatvnc0   0.5.4+dfsg-1
ii  libpixman-1-dev   0.42.2-1
ii  libturbojpeg0-dev 1:2.1.5-2
ii  zlib1g-dev1:1.2.13.dfsg-1

libneatvnc-dev:amd64 recommends no packages.

libneatvnc-dev:amd64 suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1060709: dh-runit: autopkgtest failure with Perl 5.38: given is deprecated

[gregor herrmann]

Control: tag -1 + confirmed patch

On Sat, 13 Jan 2024 13:14:48 +0200, Niko Tyni wrote:

> This package fails its autopkgtest checks with Perl 5.38
> (currently in unstable.)
> 
>  autopkgtest [21:33:45]: test command1:  - - - - - - - - - - results - - - - 
> - - - - - -
>  command1 FAIL stderr: given is deprecated at /usr/bin/dh_runit 
> line 50.
>  autopkgtest [21:33:45]: test command1:  - - - - - - - - - - stderr - - - - - 
> - - - - -

Find attached a patch to get rid of given/when.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
diff --git a/dh_runit b/dh_runit
index 52a1c62..6bd7dfb 100755
--- a/dh_runit
+++ b/dh_runit
@@ -11,7 +11,6 @@ use Text::Hogan::Compiler;
 use File::Slurp qw(read_file write_file);
 use File::Copy::Recursive qw(dircopy);
 use feature 'signatures';
-no warnings 'experimental';
 
 our $VERSION = "2.16.0";
 
@@ -47,21 +46,21 @@ sub template_from_data_directory {
 sub parse_options($opts) {
 my $conf = { enable => 1, onupgrade => 'restart' };
 for my $opt (split(/,/, $opts)) {
-given($opt) {
-when (/^disable$/) { $conf->{enable} = 0; };
-when (/^name=(.*)$/)   { $conf->{name} = $1; };
-when (/^onupgrade=(.*)$/)   { $conf->{onupgrade} = $1; };
-when (/^since=(.*)$/)  { $conf->{since} = $1; };
-when (/^logscript$/)   { $conf->{logscript} = 1};
-when (/^noreplace$/)   { $conf->{noreplace} = 1};
-when (/^noscripts$/)   { $conf->{noscripts} = 1};
-when (/^presubj$/) { $conf->{presubj} = 1; };
-when (/^usr$/)   { $conf->{usr} = 1};
-when (/^finish$/)   { $conf->{finish} = 1};
-when (/^nofinish$/)   { $conf->{nofinish} = 1};
-when (/^bin=(.*)$/)   { $conf->{bin} = $1; };
-when (/^defaults$/){ "do nothing"; };
-default{ error("unknown option `$opt'"); }
+for($opt) {
+if (/^disable$/)   { $conf->{enable} = 0; }
+elsif (/^name=(.*)$/)  { $conf->{name} = $1; }
+elsif (/^onupgrade=(.*)$/) { $conf->{onupgrade} = $1; }
+elsif (/^since=(.*)$/) { $conf->{since} = $1; }
+elsif (/^logscript$/)  { $conf->{logscript} = 1}
+elsif (/^noreplace$/)  { $conf->{noreplace} = 1}
+elsif (/^noscripts$/)  { $conf->{noscripts} = 1}
+elsif (/^presubj$/){ $conf->{presubj} = 1; }
+elsif (/^usr$/){ $conf->{usr} = 1}
+elsif (/^finish$/) { $conf->{finish} = 1}
+elsif (/^nofinish$/)   { $conf->{nofinish} = 1}
+elsif (/^bin=(.*)$/)   { $conf->{bin} = $1; }
+elsif (/^defaults$/)   { } # do nothing
+else   { error("unknown option `$opt'"); }
 }
 }
 return $conf;


signature.asc
Description: Digital Signature

Bug#1060730: /usr/share/doc/libneatvnc-dev/examples/png-server.c: depends on "../src/pngfb.c", which isn't distributed

[наб]

Package: libneatvnc-dev
Version: 0.5.4+dfsg-1
Version: 0.7.1+dfsg-1
Severity: normal
File: /usr/share/doc/libneatvnc-dev/examples/png-server.c

Dear Maintainer,

  $ cc $(pkg-config --libs --cflags neatvnc aml pixman-1 libpng) 
/usr/share/doc/libneatvnc-dev/examples/png-server.c -O3 -o png-server
  /bin/ld: /tmp/png-server-952d18.o: in function `main':
  png-server.c:(.text+0x1f): undefined reference to `read_png_file'
  cc: error: linker command failed with exit code 1 (use -v to see invocation)
cf. /usr/share/doc/libneatvnc-dev/examples/meson.build:
  if libpng.found()
  executable(
  'png-server',
  [
  'png-server.c',
  '../src/pngfb.c',
  ],
this isn't distributed, so to actually use this example you need to apt
source neatvnc and run
  $ cc $(pkg-config --libs --cflags neatvnc aml pixman-1 libpng) 
/usr/share/doc/libneatvnc-dev/examples/png-server.c 
neatvnc-0.7.1+dfsg/src/pngfb.c -O3 -o png-server
which diminishes the utility of the example greatly.

Please also put pngfb.c into examples.

Best,
наб

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libneatvnc-dev:amd64 depends on:
ii  libaml-dev0.2.2-1
ii  libgnutls28-dev [gnutls-dev]  3.7.9-2+deb12u1
ii  libneatvnc0   0.5.4+dfsg-1
ii  libpixman-1-dev   0.42.2-1
ii  libturbojpeg0-dev 1:2.1.5-2
ii  zlib1g-dev1:1.2.13.dfsg-1

libneatvnc-dev:amd64 recommends no packages.

libneatvnc-dev:amd64 suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1060731: davfs2: Installs empty /sbin directory

[Chris Hofstaedtler]

Package: davfs2
Version: 1.6.1-1
Severity: important
User: helm...@debian.org

Hi,

your package installs an empty /sbin directory. For the currently
ongoing UsrMerge effort[1] these directories need to go away.

Please stop installing the directory, as it appears to have no function
as is.

Chris

[1] https://wiki.debian.org/UsrMerge

Bug#1060710: dnsenum: autopkgtest failure with Perl 5.38: Smartmatch is deprecated

[gregor herrmann]

Control: tag -1 + patch upstream

On Sat, 13 Jan 2024 13:17:01 +0200, Niko Tyni wrote:

> This package fails its autopkgtest checks with Perl 5.38
> (currently in unstable.)
> 
>  28s autopkgtest [21:35:23]: test command1:  - - - - - - - - - - results - - 
> - - - - - - - -
>  28s command1 FAIL stderr: Smartmatch is deprecated at 
> /usr/bin/dnsenum line 749.
>  29s autopkgtest [21:35:24]: test command1:  - - - - - - - - - - stderr - - - 
> - - - - - - -
>  29s Smartmatch is deprecated at /usr/bin/dnsenum line 749.
>  29s Smartmatch is deprecated at /usr/bin/dnsenum line 751.

Here's a quilt patch getting rid of smartmatch.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1060732: abinit: FTBFS with stack-clash-protection on armhf

[Emanuele Rocca]

Source: abinit
Version: 9.10.4-2
Severity: serious
Tags: patch
User: debian-...@lists.debian.org
Usertags: 32bit-stackclash

Dear Maintainer,

abinit currently fails to build from source on armhf. To address the immediate
issue, please disable stack-clash-protection with the following snippet in
debian/rules:

  ifeq ($(DEB_TARGET_ARCH),armhf)
export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-stackclash
  else
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
  endif

You can find the full build logs of a failed build at:
http://qa-logs.debian.net/2024/01/11/armhf/abinit_9.10.4-2_unstable-armhf.log

The failure is:

Command   /<>/src/98_main/abinit 
/<>/tests/Test_suite/fast_t26/t26.abi> 
/<>/tests/Test_suite/fast_t26/t26.stdout   2> 
/<>/tests/Test_suite/fast_t26/t26.stderr 
 returned exit_code: 139

[fast][t26][np=1][run_etime: 0.63 s]: fldiff fatal error:
file 1 has more significant lines than file 2 (288 > 121).
 [file=t26.abo]
[fast][t26][np=1] Test was not expected to fail but subprocesses returned 
retcode: 139

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
Segmentation fault

Bug#1060733: pdns-recursor: new upstream versions 5.x

[Chris Hofstaedtler]

Source: pdns-recursor
Control: block -1 by 1025912

Upstream has released 5.0.0 and 5.0.1, now requiring rust/cargo to
build, and some rust crates, f.e. rust-serde-yaml >= 0.9.

Bug#1060702: [Pkg-tcltk-devel] Bug#1060702: tcl-itcl4-dev: incr Tcl programs do not compile with tcl8.7-dev

[Sergei Golovan]

Hi Rafael,

On Sat, Jan 13, 2024 at 11:09 AM Rafael Laboissière  wrote:
> With the versions of tcl-itcl4-dev (4.2.3-1) and tcl8.7-dev
> (8.7.0~a5+dfsg-3) currently in experimental, this simple example does
> not work:
>
> $ echo "#include " > test.c
> $ gcc -c test.c -I/usr/include/tcl
> In file included from test.c:1:
> /usr/include/itcl/itcl.h:144:5: error: unknown type name 'Tcl_Size'
>   144 | Tcl_Size len;  /* number of values on stack */
>   | ^~~~
> /usr/include/itcl/itcl.h:145:5: error: unknown type name 'Tcl_Size'
>   145 | Tcl_Size max;  /* maximum size of stack */
>   | ^~~~
> /usr/include/itcl/itcl.h:164:5: error: unknown type name 'Tcl_Size'
>   164 | Tcl_Size num;  /* number of elements */
>   | ^~~~
>
> It does work in unstable.

Thank you for the report and for the patch!

>
> Currently, in experimental, tcl-dev depends on tcl8.7-dev. If this
> packages migrate into unstable, then tcl-itcl4-dev will be broken in a
> serious way. Hence, I am am hereby setting the severity level to
> important.

Indeed, tcl-dev depends on tcl8.8-dev in experimental in order to spot
this type of bugs. Eventually, Tcl/Tk 8.7 will be released, and then
we'll do a big transition of all the Tcl/Tk related packages from 8.6
to 8.7. Your patch will definitely help with it.

Cheers!
-- 
Sergei Golovan

Bug#1059982: dpkg: move start-stop-daemon to /usr for DEP17

[Guillem Jover]

Hi!

On Thu, 2024-01-04 at 12:05:00 +0100, Helmut Grohne wrote:
> Package: dpkg
> Version: 1.22.2
> Tags: patch
> User: helm...@debian.org
> Usertags: dep17m2

> please move /sbin/start-stop-daemon to /usr for the /usr-move aka DEP17.
> It's the last file in dpkg that needs moving and since it is essential,
> it's a prerequisite for doing the bootstrap work. Thanks in advance.

Thanks for the patch! As mentioned on IRC at the time, I'll be going
with an alternative solution, which I think I'll be uploading to
experimental alongside another potentially disruptive refactoring change
during the weekend.

Thanks,
Guillem

Bug#1026463: Bug#960434: ITP: varlink -- point-to-point IPC protocol and interface description format

[Guillem Jover]

Hi!

[ I was asked to mentor someone to complete this ITP, which prompted
  me to look into its current state. ]

It seems Jason's mail bounces, so this ITP should at least be turned
into an RFP most probably, and even perhaps be closed, see below.

On Tue, 2020-05-12 at 09:43:04 -0400, Jason Francis wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jason Francis 
> 
> * Package name: varlink
>   Version : 19
>   Upstream Author : Kay Sievers 
> * URL : https://www.varlink.org/
> * License : Apache-2.0
>   Programming Lang: C
>   Description : point-to-point IPC protocol and interface description
> format
> 
> Varlink is an interface description format and protocol that aims to make
> services accessible to both humans and machines in the simplest feasible way.
> 
> A varlink interface combines the classic UNIX command line options,
> STDIN/OUT/ERROR text formats, man pages, service metadata and provides the
> equivalent over a single file descriptor, a.k.a. “FD3”.
> 
> Varlink is plain-text, type-safe, discoverable, self-documenting, remotable,
> testable, easy to debug. Varlink is accessible from any programming
> environment.

> ---
> 
> Submission Notes:
> Varlink is a small IPC protocol intended to be a very simple peer-to-peer
> alternative to D-Bus. A minimal implementation has already been adopted by the
> systemd project and integrated into their codebase; however I am submitting
> this ITP in order to package the official C reference implementation that
> includes a shared library and command line utility. Another package named
> "kanshi" that I contribute to upstream is looking at using this library, and 
> it
> would be nice to have it ready in Debian for when a new version is published.
> I'm not sure what package team this would fall under, but I've been testing
> some Debian packaging already which is up on my github:
> https://github.com/cyclopsian/libvarlink/tree/debian-19/debian

It looks like the upstream varlink project is dead or close to that.

The last commit on the libvarlink project is from 2 years ago, and
I think there's been no apparent interaction in MRs and issues for a
long time. The Linux kernel module for longer. And that looks similar
for the other bindings, except for the Rust ones which have seen a
few commits 6 months ago.

My memory was spotty about its popularity, so did some checking. It
looks like podman gained varlink support but they then dropped it when
varlink upstream told them they'd stop maintaining the project:

  https://podman.io/blogs/2020/12/11/remove-varlink-libpod-conf-notice
  https://podman.io/blogs/2020/08/01/deprecate-and-remove-varlink-notice

It looks like the main user, as noted above, is systemd, which imported
or implemented minimal varlink code into their tree and do not use the
external reference implementation at all.

Then also checked dependencies in Debian:

  - python3-varlink: 0 reverse depends
  - golang-github-varlink-go-dev: 0 build-depends

A search for varlink.h across all Debian sources:

  https://codesearch.debian.net/search?q=varlink.h=1

shows only a handful of potential users. Searching instead of varlink
gives way more hits, but I think the majority are unrelated, and instead
are related to Java SWIG.


The state of this upstream does not look very healthy, and from here
it does not look like adding this to Debian might be entirely wise.
For kanshi perhaps upstream should be looking into using something
else, maybe Cap'n Proto ?

Thanks,
Guillem

Bug#1055847: python-sparse's autopkg tests fail with Python 3.12

[Andreas Tille]

Hi Nilesh,

Am Sat, Jan 13, 2024 at 04:15:07PM +0530 schrieb Nilesh Patra:
> Fixed in Git, please check.

Thanks a lot.  I'll wait for debci whether bug #1055847 persists.

I wonder whether we could close simply #1058485 since the test is passing
with current numba.

Kind regards
 Andreas.

-- 
http://fam-tille.de

Bug#1057717: cmake ftbfs on ppc64el (and ppc64)

[John Paul Adrian Glaubitz]

Control: tags -1 +patch

On Fri, 2024-01-12 at 01:31 +0100, John Paul Adrian Glaubitz wrote:
> This has now been tracked down to the libuv upstream change that introduced 
> support
> for io_uring [1]. This regression is tracked now in a new issue for libuv [2].

The attached patch disables io_uring on ppc64 and ppc64el for the time being 
until
the upstream issue has been resolved.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
From 3b6a1a14caeeeaf5510f2939a8e28ed9ba0ad968 Mon Sep 17 00:00:00 2001
From: Brad King 
Date: Sat, 13 Jan 2024 06:04:01 -0500
Subject: [PATCH] linux: disable io_uring on ppc64 and ppc64le (#4285)

Since `io_uring` support was added, libuv's signal handler randomly
segfaults on ppc64 when interrupting `epoll_pwait`.  Disable it
pending further investigation.

Issue: https://github.com/libuv/libuv/issues/4283
---
 src/unix/linux.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/unix/linux.c b/src/unix/linux.c
index 3c1313e7..4164e90d 100644
--- a/src/unix/linux.c
+++ b/src/unix/linux.c
@@ -463,6 +463,9 @@ static int uv__use_io_uring(void) {
 #elif defined(__arm__) && __SIZEOF_POINTER__ == 4
   /* See https://github.com/libuv/libuv/issues/4158. */
   return 0;  /* All 32 bits kernels appear buggy. */
+#elif defined(__powerpc64__) || defined(__ppc64__)
+  /* See https://github.com/libuv/libuv/issues/4283. */
+  return 0; /* Random SIGSEGV in signal handler. */
 #else
   /* Ternary: unknown=0, yes=1, no=-1 */
   static _Atomic int use_io_uring;
-- 
2.43.0

Bug#1060734: Add more dev dependencies

[Dmitry Baryshev]

Package: libsail0
Version: 0.9.0+repack-2

Hi! There are missing dependencies for -dev packages that are not currently
installed and need manual installation:

libsail-dev should depend on libsail-common-dev
libsail-c++-dev should depend on libsail-dev and libsail-manip-dev

Bug#993849: RE. authenticator

[Matthias Geiger]

On 13.01.24 14:19, Bastian Germann wrote:

Hi Matthias,

On Fri, 14 Jul 2023 00:59:43 +0200 Matthias Geiger 
 wrote:
If my tracking spreadsheet is correct (rust) authenticator is still 
missing five crates:


scrypt, search-provider, libadwaita, gst-plugin-gtk4 and aes-gcm.


They are all available (gst-plugin-gtk4 in experimental) now.
Are you going to upload the new version soon?
The git repo should be moved over to the GNOME Team. Is there anybody 
with sufficient rights?




Hi Bastian,

gst-plugin-gtk4 still needed the rest of the gstreamer-gl* packages 
which were just accepted today from NEW. Another issue is Authenticator 
depending on aperture. While it is available on crates.io it does not 
include a copy of its license in the source which I believe won't fly 
with ftpmasters. It's upstream just links to it (see issue [0] ).


I would rather someone else would take over Authenticator as I already 
maintain a lot; the options I see are a) getting upstream to include the 
license (might be unlikely since they aren't distro-friendly ) or use an 
old version of Authenticator which does not use aperture yet.


I don't have a lot of time until February anyway but save the aperture 
situation this should be straightforward to package now.


[0] https://gitlab.gnome.org/GNOME/snapshot/-/issues/114

best,

--
Matthias Geiger 
Debian Maintainer
"Freiheit ist immer Freiheit des anders Denkenden" -- Rosa Luxemburg



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature