Bug#1061368: ITP: gnome-prompt -- terminal for GNOME

2024-01-22 Thread Gürkan Myczko

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: gnome-prompt
  Version : 46~alpha
  Upstream Authors: Christian Hergert 
  URL : https://gitlab.gnome.org/chergert/prompt
* License : GPL-3.0-or-later
  Description : terminal for GNOME
 This is a terminal for GNOME with first-class support for containers.
 Contrary to gnome-terminal this supports transparent backgrounds.

This is to be maintained inside the GNOME-team in Debian.



Bug#1061263: spglib: buildsystem could be switched to scikit-build-core

2024-01-22 Thread Andrius Merkys

Hi,

I think both #1061263 and #1061357 could be solved by switching spglib's 
buildsystem to one based on scikit-build-core, as its pyproject.toml 
supports that.


Andrius



Bug#1061367: ITP: loki-ecmwf -- Source-to-source code translator for Fortran

2024-01-22 Thread Alastair McKinstry
Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: loki-ecmwf
  Version : 0.1.6
  Upstream Contact: Michael Lange (michael.la...@ecmwf.int)
* URL : https://github.com/ecmwf-ifs/loki
* License : Apache-2
  Programming Lang: Python
  Description : Source-to-source code translator for Fortran

Loki is an experimental tool to explore the possible use of
source-to-source translation for ECMWF's Integrated Forecasting System (IFS) and
associated Fortran software packages.

Loki is based on compiler technology (visitor patterns and ASTs) and aims to
provide an abstract, language-agnostic representation of a kernel, as well as a
programmable (pythonic) interface that allows developers to experiment with
different kernel implementations and optimizations.  The aim is to allow changes
to programming models and coding styles to be encoded and automated instead of
hand-applying them, enabling advanced experimentation with large kernels as well
as bulk processing of large numbers of source files to evaluate different kernel
implementations and programming models.

This software is now in use beyond ECMWF, and I intend to work
and develop it with other Fortran environments in Debian.
I intend to maintain it within Debian Science team as part of the
Meteorology stack.

As Loki is a pre-existing name in Debian, I intend to follow
convention and rename the package loki-ecmwf.



Bug#1061361: Adapt lektor to werkzeug 3.0.1 - fix proposed

2024-01-22 Thread Pushkar Kulkarni
Hello,

I submitted a patch [1] for review.

Many thanks,
Pushkar

[1] https://salsa.debian.org/debian/lektor/-/merge_requests/2



Bug#1061360: Adapt onionshare to the new werkzeug urls API

2024-01-22 Thread Pushkar Kulkarni
Hello,

I submitted a patch [1] for review.

Many thanks,
Pushkar

[1] https://salsa.debian.org/pkg-privacy-team/onionshare/-/merge_requests/3



Bug#1061366: python3.12: Python3.12 segfaults on python-xarray testsuite

2024-01-22 Thread Alastair McKinstry
Package: python3.12
Version: 3.12.1-2
Severity: serious
Justification: 4
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Python3.12 segfaults on the unittest suite for python-xarray
(2024.01.0, head of tree in debian/latest)
Unfortunately I cannot get a core dump yet to be more specific; this is on 
arm64 at least.



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

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



Bug#1061365: RM: ros-python-qt-binding -- ROM; No longer used in Debian and depends on broken sip4

2024-01-22 Thread Jochen Sprickerhof
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ros-python-qt-bind...@packages.debian.org
Control: affects -1 + src:ros-python-qt-binding



Bug#1061364: RM: ros-wstool -- ROM; deprecated upstream in favour of vcstool

2024-01-22 Thread Jochen Sprickerhof
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ros-wst...@packages.debian.org
Control: affects -1 + src:ros-wstool



Bug#1061363: RM: ros-rosinstall -- ROM; deprecated upstream in favour of vcstool

2024-01-22 Thread Jochen Sprickerhof
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: ros-rosinst...@packages.debian.org
Control: affects -1 + src:ros-rosinstall



Bug#1024276: ITP: golang-github-googleapis-enterprise-certificate-proxy -- Google Proxies for Enterprise Certificates

2024-01-22 Thread Maytham Alsudany
Hi Drew,

Now that golang-github-google-go-pkcs11 has been uploaded and accepted, is it
possible for you to now upload golang-github-googleapis-enterprise-certificate-
proxy?

Kind regards,
Maytham


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


Bug#1061298: u-boot: refresh patches

2024-01-22 Thread Лухнов Андрей Олегович
Thanks for the prompt reply, Vagrant!

May be, I chose wrong wordings and mislead you a bit.

It happened so, that I applied patches one by one and observed following info:

```
# quilt push
Applying patch debian/patches/arndale/board-spl-rule.diff
patching file Makefile
Hunk #1 succeeded at 2056 (offset -52 lines).
```

or

```
Applying patch debian/patches/rockchip/rockchip-inno-usb.patch
patching file drivers/phy/rockchip/phy-rockchip-inno-usb2.c
Hunk #1 succeeded at 64 (offset 2 lines).
Hunk #2 succeeded at 108 (offset 14 lines).
Hunk #3 succeeded at 126 (offset 14 lines).
Hunk #4 succeeded at 142 (offset 14 lines).
Hunk #5 succeeded at 168 (offset 14 lines).
Hunk #6 succeeded at 312 (offset 82 lines).
```

So, I decided to issue `quilt refresh` for each patch, that has such reports.

I'm not a seasoned Debian maintainer, so sorry for the noise if those actions 
are unneeded. :)

I understand that patches still apply well, but they are already "not perfectly 
in place". So, it appears, the policy is to wait till they are not applicable 
with `--fuzz=0`.
Understood. Thank you for the clarification!

Andrey

- Original Message -
From: "Vagrant Cascadian" 
To: "Андрей Лухнов" , 1061...@bugs.debian.org
Sent: Monday, January 22, 2024 10:32:40 PM
Subject: Re: Bug#1061298: u-boot: refresh patches

On 2024-01-22, Лухнов Андрей Олегович wrote:
> I've quilt-refreshed patches in u-boot 2024.01+dfsg-1 to apply them
> without fuzzyness.
>
> Please find, ahem, a patch for that attached. :) (I'm not sure, if it
> is a correct method to propose a fix, though, or you could just run
> quilt refresh yourself)

Since the patches apply with "quilt push --fuzz=0 -a" I do not think
this is currently needed.

Is there something I am missing?

live well,
  vagrant



Bug#1061361: Adapt lektor to the new python-werkzeug urls API

2024-01-22 Thread Pushkar Kulkarni
Package: lektor
Version: 3.3.7-1
Severity: normal


python3-werkzeug have substantially reworked (purged, if I may) their
urls API in upstream release 3.0.1 which is accepted by Debian
experimental. As per the Ubuntu bug report [1], and as also verified
by me, lektor's autopkgtests fail when it depends on
python-werkzeug 3.X.Y. The former needs to be adapted to the new API
of the latter.

[1] https://bugs.launchpad.net/ubuntu/+source/onionshare/+bug/2048769



Bug#1061360: Adapt onionshare to python3-werkzeug API 3.X.Y

2024-01-22 Thread Pushkar Kulkarni
Package: onionshare
Version: 2.6-5
Severity: normal


python3-werkzeug have substantially reworked (purged, if I may) their
urls API in upstream release 3.0.1 which is accepted by Debian
experimental. As per the Ubuntu bug report [1], and as also verified
by me, onionshare's autopkgtests fail when it depends on
python-werkzeug 3.X.Y. The former needs to be adapted to the new API
of the latter.

[1] https://bugs.launchpad.net/ubuntu/+source/onionshare/+bug/2048769



Bug#1059315: tinyxml: CVE-2023-34194 CVE-2023-40462 CVE-2023-40458

2024-01-22 Thread Salvatore Bonaccorso
Hi,

On Sun, Jan 14, 2024 at 05:48:54PM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Sun, Jan 14, 2024 at 04:41:00PM +, Bastien Roucari?s wrote:
> > On Sun, 31 Dec 2023 07:14:26 +0100 Salvatore Bonaccorso  
> > wrote:
> > Hi Guilhem, hi Moritz,
> > > Hi Guilhem, hi Moritz,
> > > 
> > > On Sat, Dec 30, 2023 at 11:26:02PM +0100, Guilhem Moulin wrote:
> > > > On Sat, 30 Dec 2023 at 21:02:16 +0100, Felix Geyer wrote:
> > > > > There are some minor changes staged in the salsa git repo. It would 
> > > > > be good
> > > > > to include them as well. Feel free to push the patch to git and 
> > > > > upload.
> > > > > Alternatively a merge request works as well of course.
> > > > 
> > > > Thanks for the fast response!  Tagged and uploaded.
> > > > 
> > > > Security team, if you agree with my assessment that CVE-2023-40462 is a
> > > > duplicate of CVE-2023-34194 (but for a separate project that embeds
> > > > libxml) and that CVE-2023-40458 is a duplicate of CVE-2021-42260 (but
> > > > for a separate project that embeds libxml), I can propose debdiffs for
> > > > bullseye and bookworm.
> > > 
> > > I think the former is correct but still bit biased. We initially had
> > > exactly CVE-2023-40462 as NFU and CVE-2023-34194 for tinyxml. I have
> > > now commmited
> > > https://salsa.debian.org/security-tracker-team/security-tracker/-/commit/7e507c932b999df48f808969c00f07a638e3357b
> > > hich does match my understanding for this doubled CVE assignment. The
> > > document is actually not very very clear. It still metnions
> > > CVE-2023-40462 but does not consistently say "TinyXML as used in".
> > > Still hope we can agree the above matches our all udnerstanding.
> > > Moritz given you updated back then the entry from NFU and tinyxml, if
> > > you still strongly disagree I will revert the above, but I tried to
> > > explain my reasoning in the commit message.
> > > 
> > > Now for CVE-2023-40458 I'm  not sure. Looking back at the references
> > > for CVE-2021-42260 and the issue report at
> > > https://sourceforge.net/p/tinyxml/bugs/141/ this sensibly match the
> > > description for CVE-2023-40458, but will want to see if Moritz has an
> > > additional input here.
> > > 
> > > If this is the case we either have the otpion to mark it really as
> > > duplicate (and request a reject from MITRE) or it is again just a
> > > ALEOS issue "... tinyxml as used in". Again the table here is not very
> > > clear in the report, for the CVE-2023-34194 and CVE-2023-40462 there
> > > were explicitly listed the two CVEs with brackeds including the
> > > product in the the table, but this is not the case for CVE-2023-40458.
> > > 
> > > Moritz?
> > 
> > Any news of this triagging ?
> 
> I contacted the involved CNA and they are investigting if that needs
> to be considered a dupliate (for CVE-2023-40458 and CVE-2021-42260).
> 
> CVE-2023-40462 was already updated.

So CVE-2023-40458 is to be consideres specific to ALEOS. The reason
is, while the underlying vulnerability is the same as CVE-2021-42260
Sierra Wireless CNA choosed to register a unique CVE as the ALEOS
source code contained code taken from TinyXML but did not contain the
complete TinyXML source.  The fixing of the vulnerability reflects the
fix in TinyXML (as per its CVE), but it was not possible in the
Sirerra Wireless product to address the vulnerability by directly
taking the TinyXML code.

Regards,
Salvatore



Bug#1061341: cyrus-common: identified for time_t transition but no ABI in shlibs

2024-01-22 Thread Yadd

Control: tags -1 + moreinfo

On 1/23/24 00:43, Steve Langasek wrote:

Package: cyrus-common
Version: 3.8.1-1
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t

Dear maintainers,

Analysis of the archive for the 64-bit time_t transition[0][1] identifies
cyrus-common as an affected package, on the basis that the headers could not
be compiled and analyzed out of the box using abi-compliance-checker[2], so
we have to assume it's affected.

However, cyrus-commons's shlibs file declares a dependency on a library
package name that contains no ABI information:


Hi,

according to 
https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/cyrus-dev/base/log.txt 
, this issue looks like a false-positive: test failed because of C 
error, not bad report


Am I right here ?

Best regards,
Xavier



Bug#1061348: [debian-mysql] Bug#1061348: mariadb: install PAM modules and systemd unit files into /usr

2024-01-22 Thread Michael Biebl

Am 23.01.24 um 03:24 schrieb Otto Kekäläinen:
Thanks, I wil check all occurrences of /lib after 
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/29 
 has been approved and merged.


Your review on that one would be appreciated.




I would prefer not to entangle the two, tbh and have this one fixed first.


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1061348: [debian-mysql] Bug#1061348: mariadb: install PAM modules and systemd unit files into /usr

2024-01-22 Thread Otto Kekäläinen
Thanks, I wil check all occurrences of /lib after
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/29
has been approved and merged.

Your review on that one would be appreciated.


Bug#1060089: isc-dhcp: install dhclient into /usr/sbin, with DEP17 M18 diversions

2024-01-22 Thread Chris Hofstaedtler
Hi,

On Fri, Jan 05, 2024 at 08:53:30PM +0100, Chris Hofstaedtler wrote:
> I'm attaching a patch that moves /sbin/dhclient and applies the
> required workarounds for diversions ("DEP17 M18").

Attached is an improved patch, that avoids the temporary file loss
that could occur in the old version. This is mostly based on work by
Helmut Grohne.

Please consider this version of the patch.

Chris

diff -Nru isc-dhcp-4.4.3-P1/debian/changelog isc-dhcp-4.4.3-P1/debian/changelog
--- isc-dhcp-4.4.3-P1/debian/changelog  2023-10-20 14:16:37.0 +0200
+++ isc-dhcp-4.4.3-P1/debian/changelog  2024-01-21 17:17:47.0 +0100
@@ -1,3 +1,11 @@
+isc-dhcp (4.4.3-P1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move dhclient to /usr/sbin and add duplicated diversions (DEP17 P3 M18).
+Also add Conflicts: older isc-dhcp-client-ddns. (Closes: #1060089)
+
+ -- Chris Hofstaedtler   Sun, 21 Jan 2024 17:17:47 +0100
+
 isc-dhcp (4.4.3-P1-4) unstable; urgency=low
 
   [ Athos Ribeiro ]
diff -Nru isc-dhcp-4.4.3-P1/debian/control isc-dhcp-4.4.3-P1/debian/control
--- isc-dhcp-4.4.3-P1/debian/control2023-09-15 18:19:55.0 +0200
+++ isc-dhcp-4.4.3-P1/debian/control2024-01-21 17:17:47.0 +0100
@@ -107,6 +107,8 @@
  isc-dhcp-client-ddns,
 Provides:
  dhcp-client,
+Conflicts:
+ isc-dhcp-client-ddns (<< 4.4.3-P1-4.1),
 Description: DHCP client for automatically obtaining an IP address
  This is the Internet Software Consortium's DHCP client.
  .
diff -Nru isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.install 
isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.install
--- isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.install   2022-02-23 
10:28:51.0 +0100
+++ isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.install   2024-01-05 
18:51:22.0 +0100
@@ -1 +1 @@
-client/dhclient sbin
+client/dhclient usr/sbin
diff -Nru isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postinst 
isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postinst
--- isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postinst  1970-01-01 
01:00:00.0 +0100
+++ isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postinst  2024-01-21 
17:17:47.0 +0100
@@ -0,0 +1,13 @@
+#!/bin/sh
+
+set -e
+
+# DEP17 M18: Duplicate diversion in aliased location /sbin.
+
+if [ "$1" = "configure" ]; then
+   # Remove diversion in aliased path, which is only needed for upgrades.
+   dpkg-divert --package isc-dhcp-client-ddns --remove --no-rename \
+   --divert /sbin/dhclient-noddns.usr-is-merged /sbin/dhclient
+fi
+
+#DEBHELPER#
diff -Nru isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postrm 
isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postrm
--- isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postrm2022-02-23 
10:28:51.0 +0100
+++ isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.postrm2024-01-05 
18:51:22.0 +0100
@@ -3,8 +3,8 @@
 set -e 
 
 if [ "$1" = "remove" -o "$1" = "abort-install" -o "$1" = "disappear" ]; then
-dpkg-divert --package isc-dhcp-client-ddns --remove \
-   --rename --divert /sbin/dhclient-noddns /sbin/dhclient
+   dpkg-divert --package isc-dhcp-client-ddns --remove \
+   --rename --divert /usr/sbin/dhclient-noddns /usr/sbin/dhclient
 fi
 
 #DEBHELPER#
diff -Nru isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.preinst 
isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.preinst
--- isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.preinst   2022-02-23 
10:28:51.0 +0100
+++ isc-dhcp-4.4.3-P1/debian/isc-dhcp-client-ddns.preinst   2024-01-21 
17:17:47.0 +0100
@@ -2,9 +2,47 @@
 
 set -e 
 
-if [ "$1" != "upgrade" ]; then
-   dpkg-divert --package isc-dhcp-client-ddns --add --rename \
-   --divert /sbin/dhclient-noddns /sbin/dhclient
-fi
+# DEP17 M18: Duplicate diversion in aliased location /sbin.
+
+case "$1" in
+   install)
+   # canonical path; the one we are using going forward.
+   dpkg-divert --package isc-dhcp-client-ddns --add --rename \
+   --divert /usr/sbin/dhclient-noddns /usr/sbin/dhclient
+   # aliased path, for upgrades. postinst will --remove it.
+   dpkg-divert --package isc-dhcp-client-ddns --add --rename \
+   --divert /sbin/dhclient-noddns.usr-is-merged 
/sbin/dhclient
+
+   ;;
+
+   upgrade)
+   TRUENAME=$(dpkg-divert --truename /usr/sbin/dhclient)
+   if test "$TRUENAME" = /usr/sbin/dhclient.usr-is-merged; then
+   # isc-dhcp-client.preinst duplicated the diversion for 
us.
+   # Remove duplicated diversion.
+   dpkg-divert --package isc-dhcp-client-ddns --remove 
--no-rename \
+   --divert /usr/sbin/dhclient.usr-is-merged 
/usr/sbin/dhclient
+   dpkg-divert --package isc-dhcp-client-ddns --add 
--no-rename \
+   

Bug#1061359: zfs-linux: please install files into /usr

2024-01-22 Thread Chris Hofstaedtler
Source: zfs-linux
User: helm...@debian.org
Usertags: dep17m2

Hi,

I'd like to ask you to investigate installing files into /usr, where
they curently are installed into /bin, /lib, or /sbin. This would
help us finishing the /usr-move transition (aka DEP17) for trixie.

I'm filing this bug now, as the zfs-linux packaging seems to be a
lot, and installs quite a number of files that need moving, and
probably also wants a lot of testing - so I expect you want more
time than the typical package.

Please see the wiki here for details: https://wiki.debian.org/UsrMerge

If you have questions, please don't hesitate to ask and/or join
#debian-usrmerge.

Thanks,
Chris



Bug#1061358: gnumeric: identified for time_t transition but no ABI in shlibs

2024-01-22 Thread Steve Langasek
Package: gnumeric
Version: 1.12.56-2
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t

Hi Dmitry,

Analysis of the archive for the 64-bit time_t transition[0][1] identifies
gnumeric as an affected package, on the basis that the headers could not be
compiled and analyzed out of the box using abi-compliance-checker[2], so we
have to assume it's affected.

However, gnumeric's shlibs file declares a dependency on a library package
name that contains no ABI information:

$ cat DEBIAN/shlibs
libspreadsheet 1.12.56 gnumeric (>= 1.12.56)
$

It is therefore not obvious that we should rename the package to
'gnumeric-t64' as part of this transition.

Looking at the archive, there are packages built from separate source
packages which depend on this library: both libgcu0v5 from
gnome-chemistry-utils, and also gir1.2-gnumeric from gnumeric source whose
only dependency on gnumeric is via the shlibs, rather than being a strict
versioned dependency.

Since there is no self-evident thing to do with the library package name
here, we will not be handling this package as part of the mass NMUs.
Instead I am filing a serious bug because partial upgrades from bookworm to
trixie on 32-bit architectures will result in ABI skew and may result in
broken behavior.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[0] https://wiki.debian.org/ReleaseGoals/64bit-time
[1] https://lists.debian.org/debian-devel/2024/01/msg00041.html
[2] 
https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/gnumeric/base/log.txt


signature.asc
Description: PGP signature


Bug#1061357: python3-spglib: spglib python package not identified by dh_python3

2024-01-22 Thread Drew Parsons
Package: python3-spglib
Version: 2.2.0-2
Severity: normal

We have dh_python3 to help automatically identify python package
dependencies when building a package.

It's unable to identify spglib, however. For instance a pymatgen build
log shows
   dh_python3 -a -O--buildsystem=pybuild
I: dh_python3 pydist:302: Cannot find package that provides spglib. Please add 
package that provides it to Build-Depends or add "spglib python3-spglib" line 
to debian/py3dist-overrides or add proper dependency to Depends by hand and 
ignore this info.

I'm not sure exactly why dh_python3 can't identify it. I would have
thought it could find out which package provides
/usr/lib/python3/dist-packages/spglib.  But it's not doing that. Maybe
it's a bug in dh-python.

But I notice that python3-spglib doesn't provide the .dist-info
directory that most other python packages provide.  I guess dh-python
is using the dist-info mechanism to identify packages. Perhaps we
should file a bug against dh-python for it to run something like
"dpkg -S /usr/lib/python3/dist-packages/" if it doesn't find
a dist-info entry.

In the meantime, I figure spglib's lack of dist-info occurs because
it's a cmake build rather than a python setuptools build, in which
case the problem sits alongside Bug#1061263.


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

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

Versions of packages python3-spglib depends on:
ii  libc6  2.37-13
ii  libsymspg2 2.2.0-2
ii  python33.11.6-1
ii  python3-numpy  1:1.24.2-2

python3-spglib recommends no packages.

python3-spglib suggests no packages.

-- no debconf information



Bug#1061356: google-authenticator: install PAM modules into /usr

2024-01-22 Thread Michael Biebl
Source: google-authenticator
Version: 20191231-2
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. google-authenticator installs files into /lib; these should be
moved into the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru google-authenticator-20191231/debian/changelog 
google-authenticator-20191231/debian/changelog
--- google-authenticator-20191231/debian/changelog  2020-04-07 
14:55:07.0 +0200
+++ google-authenticator-20191231/debian/changelog  2024-01-23 
00:16:16.0 +0100
@@ -1,3 +1,10 @@
+google-authenticator (20191231-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM modules into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Tue, 23 Jan 2024 00:16:16 +0100
+
 google-authenticator (20191231-2) unstable; urgency=medium
 
   * Source only upload.
diff -Nru google-authenticator-20191231/debian/rules 
google-authenticator-20191231/debian/rules
--- google-authenticator-20191231/debian/rules  2020-03-07 11:11:25.0 
+0100
+++ google-authenticator-20191231/debian/rules  2024-01-23 00:15:43.0 
+0100
@@ -19,7 +19,7 @@
dh_clean build/*
 
 override_dh_auto_configure:
-   dh_auto_configure -- --libdir=/lib/$(DEB_HOST_MULTIARCH)
+   dh_auto_configure -- --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
 
 override_dh_install: build
sed -i "/dependency_libs/ s/'.*'/''/" `find debian/ -name '*.la'`


Bug#1061355: pam-p11: install PAM modules into /usr

2024-01-22 Thread Michael Biebl
Source: pam-p11
Version: 0.3.1-1.2
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. pam-p11 installs files into /lib; these should be moved into
the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru pam-p11-0.3.1/debian/changelog pam-p11-0.3.1/debian/changelog
--- pam-p11-0.3.1/debian/changelog  2022-11-18 17:02:03.0 +0100
+++ pam-p11-0.3.1/debian/changelog  2024-01-23 00:04:38.0 +0100
@@ -1,3 +1,10 @@
+pam-p11 (0.3.1-1.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM modules into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Tue, 23 Jan 2024 00:04:38 +0100
+
 pam-p11 (0.3.1-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pam-p11-0.3.1/debian/rules pam-p11-0.3.1/debian/rules
--- pam-p11-0.3.1/debian/rules  2022-11-18 17:02:03.0 +0100
+++ pam-p11-0.3.1/debian/rules  2024-01-23 00:04:38.0 +0100
@@ -8,4 +8,4 @@
dh $@
 
 override_dh_auto_configure:
-   dh_auto_configure -- --libdir=/lib/$(DEB_HOST_MULTIARCH) 
--disable-strict
+   dh_auto_configure -- 
--with-pamdir=/usr/lib/$(DEB_HOST_MULTIARCH)/security --disable-strict


Bug#1061354: packages.debian.org: MIT mirror returns 503 error

2024-01-22 Thread David R. Hedges
Package: www.debian.org
Severity: important

Dear Maintainer,

packages.debian.org appears to likely have two physical hosts, one at MIT, and 
one
hosted via conova(?):

=
packages.debian.org has address 128.31.0.51
packages.debian.org has address 195.192.210.132
packages.debian.org has IPv6 address 2603:400a::bb8::801f:33
packages.debian.org has IPv6 address 2a02:16a8:dc41:100::132

NetRange:   128.31.0.0 - 128.31.255.255
CIDR:   128.31.0.0/16
NetName:MIT-RES

NetRange:   2603:4000:: - 2603:40FF::::::
CIDR:   2603:4000::/24
NetName:MIT-V6


inetnum:195.192.208.0 - 195.192.215.255
netname:AT-CONOVA-19960403

inet6num:   2a02:16a8:dc41:100::/56
netname:CUS-DEBIAN
...
route6: 2a02:16a8::/32
descr:  conova communications GmbH IPv6 Route Object
=

While the two conova-associated IPs seem to work fine, the MIT-associated hosts 
hang for 60 seconds before eventually returning a 503:

=
$ time curl -I --resolve packages.debian.org:443:128.31.0.51 
"https://packages.debian.org/sid/p7zip;
HTTP/2 503
...
real1m4.353s

$ time curl -I --resolve packages.debian.org:443:[2a02:16a8:dc41:100::132] 
"https://packages.debian.org/sid/p7zip;
HTTP/2 200
...
real0m0.519s

$ time curl -I --resolve packages.debian.org:443:[2603:400a::bb8::801f:33] 
"https://packages.debian.org/sid/p7zip;
HTTP/2 503
...
real1m4.350s

$ time curl -I --resolve packages.debian.org:443:195.192.210.132 
"https://packages.debian.org/sid/p7zip;
HTTP/2 200
...
real0m0.523s


This also results in a web browser failing to load the page ~50% of the time 
(across launches).

I have confirmed this behavior from multiple ISPs, web browsers, and curl.



Bug#1061353: pam-krb5-migrate: install PAM modules into /usr

2024-01-22 Thread Michael Biebl
Source: pam-krb5-migrate
Version: 0.0.11-5
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. pam-krb5-migrate installs files into /lib; these should be moved
into the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru pam-krb5-migrate-0.0.11/debian/changelog 
pam-krb5-migrate-0.0.11/debian/changelog
--- pam-krb5-migrate-0.0.11/debian/changelog2017-08-29 00:47:53.0 
+0200
+++ pam-krb5-migrate-0.0.11/debian/changelog2024-01-22 23:59:08.0 
+0100
@@ -1,3 +1,10 @@
+pam-krb5-migrate (0.0.11-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM modules into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Mon, 22 Jan 2024 23:59:08 +0100
+
 pam-krb5-migrate (0.0.11-5) unstable; urgency=medium
 
   * Adopt package. (Closes: #724346)
diff -Nru pam-krb5-migrate-0.0.11/debian/libpam-krb5-migrate-heimdal.install 
pam-krb5-migrate-0.0.11/debian/libpam-krb5-migrate-heimdal.install
--- pam-krb5-migrate-0.0.11/debian/libpam-krb5-migrate-heimdal.install  
2017-08-29 00:47:53.0 +0200
+++ pam-krb5-migrate-0.0.11/debian/libpam-krb5-migrate-heimdal.install  
2024-01-22 23:57:50.0 +0100
@@ -1,3 +1,3 @@
 #! /usr/bin/dh-exec
-heimdal/pam_krb5_migrate_heimdal.so => 
/lib/${DEB_HOST_MULTIARCH}/security/pam_krb5_migrate_heimdal.so
+heimdal/pam_krb5_migrate_heimdal.so => 
/usr/lib/${DEB_HOST_MULTIARCH}/security/pam_krb5_migrate_heimdal.so
 debian/libpam-krb5-migrate-heimdal.pam-config => 
/usr/share/pam-configs/krb5-migrate-heimdal
diff -Nru pam-krb5-migrate-0.0.11/debian/libpam-krb5-migrate-mit.install 
pam-krb5-migrate-0.0.11/debian/libpam-krb5-migrate-mit.install
--- pam-krb5-migrate-0.0.11/debian/libpam-krb5-migrate-mit.install  
2017-08-29 00:47:53.0 +0200
+++ pam-krb5-migrate-0.0.11/debian/libpam-krb5-migrate-mit.install  
2024-01-22 23:57:59.0 +0100
@@ -1,3 +1,3 @@
 #! /usr/bin/dh-exec
-mit/pam_krb5_migrate_mit.so => 
/lib/${DEB_HOST_MULTIARCH}/security/pam_krb5_migrate_mit.so
+mit/pam_krb5_migrate_mit.so => 
/usr/lib/${DEB_HOST_MULTIARCH}/security/pam_krb5_migrate_mit.so
 debian/libpam-krb5-migrate-mit.pam-config => 
/usr/share/pam-configs/krb5-migrate-mit


Bug#1061352: libpam-krb5: install PAM modules into /usr

2024-01-22 Thread Michael Biebl
Source: libpam-krb5
Version: 4.11-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. libpam-krb5 installs files into /lib; these should be moved into
the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru libpam-krb5-4.11/debian/changelog libpam-krb5-4.11/debian/changelog
--- libpam-krb5-4.11/debian/changelog   2021-10-18 00:49:06.0 +0200
+++ libpam-krb5-4.11/debian/changelog   2024-01-22 23:45:18.0 +0100
@@ -1,3 +1,10 @@
+libpam-krb5 (4.11-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM modules into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Mon, 22 Jan 2024 23:45:18 +0100
+
 libpam-krb5 (4.11-1) unstable; urgency=medium
 
   * Upload to unstable.
diff -Nru libpam-krb5-4.11/debian/rules libpam-krb5-4.11/debian/rules
--- libpam-krb5-4.11/debian/rules   2021-10-18 00:49:06.0 +0200
+++ libpam-krb5-4.11/debian/rules   2024-01-22 23:43:54.0 +0100
@@ -17,13 +17,13 @@
 override_dh_auto_configure:
mkdir build-mit build-heimdal
dh_auto_configure -Bbuild-mit --   \
-   --enable-reduced-depends --libdir=/lib/$(DEB_HOST_MULTIARCH)   \
+   --enable-reduced-depends --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)   \
--with-krb5-include=/usr/include/mit-krb5  \
--with-krb5-lib=/usr/lib/$(DEB_HOST_MULTIARCH)/mit-krb5\
--with-kadm-client-include=/usr/include/mit-krb5   \
--with-kadm-client-lib=/usr/lib/$(DEB_HOST_MULTIARCH)/mit-krb5
dh_auto_configure -Bbuild-heimdal --  \
-   --enable-reduced-depends --libdir=/lib/$(DEB_HOST_MULTIARCH)  \
+   --enable-reduced-depends --libdir=/usr/lib/$(DEB_HOST_MULTIARCH)  \
--with-krb5-include=/usr/include/heimdal  \
--with-krb5-lib=/usr/lib/$(DEB_HOST_MULTIARCH)/heimdal\
--with-kadm-client-include=/usr/include/heimdal   \
@@ -40,8 +40,8 @@
 override_dh_auto_install:
dh_auto_install -Bbuild-mit --destdir=debian/libpam-krb5
dh_auto_install -Bbuild-heimdal --destdir=debian/libpam-heimdal
-   rm debian/libpam-*/lib/*/security/*.la
-   chmod 644 debian/libpam-*/lib/*/security/*.so
+   rm debian/libpam-*/usr/lib/*/security/*.la
+   chmod 644 debian/libpam-*/usr/lib/*/security/*.so
install -d debian/libpam-krb5/usr/share/pam-configs
install -d debian/libpam-heimdal/usr/share/pam-configs
install -m 644 debian/pam-auth-update \


Bug#1052376: lxpanel: no longer obeys its geometry settings

2024-01-22 Thread Francesco Poli
On Thu, 21 Sep 2023 09:26:30 +0200 Francesco Poli wrote:

> On Thu, 21 Sep 2023 08:49:04 +0200 Francesco Poli (wintermute) wrote:
> 
> > Downgrading/reinstalling the following packages:
> > 
> >   libwnck-common (2.30.7-6)
> >   libwnck22 (2.30.7-6+b1)
> >   libkeybinder0 (0.3.1-2.1)
> >   libfm4 (1.3.2-1)
> >   libfm-gtk4 (1.3.2-1)
> >   lxpanel-data (0.10.1-2) ...
> >   lxpanel (0.10.1-2)
> > 
> > is enough to restore the normal (sane) behavior.
> 
> I also had to downgrade the following package:
> 
>   libfm-modules (1.3.2-1)
> 
> and to purge the following packages:
> 
>   libfm-gtk3-4
>   libkeybinder-3.0-0
>   libwnck-3-0
>   libwnck-3-common

Hello,
just a gentle ping about this bug report: any progress?

I see that several other users are experiencing the same issues I
reported. Is there any plan to fix them soon?

Thanks for your time and dedication!



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpw0xPq2IK1G.pgp
Description: PGP signature


Bug#1061351: Acknowledgement (libpam-net: install PAM modules into /usr)

2024-01-22 Thread Michael Biebl

The previous patch was reversed, sorry for that.
Correct one is attached now.

Michael
diff -Nru libpam-net-0.3/debian/changelog libpam-net-0.3/debian/changelog
--- libpam-net-0.3/debian/changelog 2022-08-14 16:17:04.0 +0200
+++ libpam-net-0.3/debian/changelog 2024-01-22 23:38:12.0 +0100
@@ -1,3 +1,10 @@
+libpam-net (0.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM modules into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Mon, 22 Jan 2024 23:38:12 +0100
+
 libpam-net (0.3-2) unstable; urgency=medium
 
   * Fix Daniel Gröber e-mail address
diff -Nru libpam-net-0.3/debian/rules libpam-net-0.3/debian/rules
--- libpam-net-0.3/debian/rules 2022-08-14 16:15:40.0 +0200
+++ libpam-net-0.3/debian/rules 2024-01-22 23:38:12.0 +0100
@@ -19,4 +19,4 @@
 
 override_dh_auto_configure:
dh_auto_configure -- \
-   -DLIBSECURITYDIR=/lib/$(DEB_HOST_MULTIARCH)/security
+   -DLIBSECURITYDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/security


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1061350: Acknowledgement (sssd: install PAM and NSS modules into /usr)

2024-01-22 Thread Michael Biebl

The previous patch was reversed, sorry for that.
Correct one is attached now.

Michael
diff -Nru sssd-2.9.4/debian/changelog sssd-2.9.4/debian/changelog
--- sssd-2.9.4/debian/changelog 2024-01-18 11:04:33.0 +0100
+++ sssd-2.9.4/debian/changelog 2024-01-22 23:33:21.0 +0100
@@ -1,3 +1,10 @@
+sssd (2.9.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM and NSS modules into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Mon, 22 Jan 2024 23:33:21 +0100
+
 sssd (2.9.4-1) unstable; urgency=medium
 
   [ Sergio Durigan Junior ]
diff -Nru sssd-2.9.4/debian/libnss-sss.install 
sssd-2.9.4/debian/libnss-sss.install
--- sssd-2.9.4/debian/libnss-sss.install2024-01-18 11:01:26.0 
+0100
+++ sssd-2.9.4/debian/libnss-sss.install2024-01-22 23:33:21.0 
+0100
@@ -1 +1 @@
-lib/*/libnss_sss.so.2
+usr/lib/*/libnss_sss.so.2
diff -Nru sssd-2.9.4/debian/libpam-sss.install 
sssd-2.9.4/debian/libpam-sss.install
--- sssd-2.9.4/debian/libpam-sss.install2024-01-18 11:01:26.0 
+0100
+++ sssd-2.9.4/debian/libpam-sss.install2024-01-22 23:33:21.0 
+0100
@@ -1,4 +1,4 @@
-lib/*/security/pam_sss.so
-lib/*/security/pam_sss_gss.so
+usr/lib/*/security/pam_sss.so
+usr/lib/*/security/pam_sss_gss.so
 usr/share/man/man8/pam_sss.8*
 usr/share/man/man8/pam_sss_gss.8*
diff -Nru sssd-2.9.4/debian/rules sssd-2.9.4/debian/rules
--- sssd-2.9.4/debian/rules 2024-01-18 11:01:26.0 +0100
+++ sssd-2.9.4/debian/rules 2024-01-22 23:33:21.0 +0100
@@ -31,8 +31,8 @@
--datadir=/usr/share/ \
--with-environment-file=/etc/default/sssd \

--with-krb5-plugin-path=/usr/lib/$(DEB_HOST_MULTIARCH)/krb5/plugins/libkrb5 \
-   --enable-nsslibdir=/lib/$(DEB_HOST_MULTIARCH) \
-   --enable-pammoddir=/lib/$(DEB_HOST_MULTIARCH)/security \
+   --enable-nsslibdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
+   --enable-pammoddir=/usr/lib/$(DEB_HOST_MULTIARCH)/security \
--enable-systemtap \
--disable-static \
--disable-rpath \


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1061351: libpam-net: install PAM modules into /usr

2024-01-22 Thread Michael Biebl
Source: libpam-net
Version: 0.3-2
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. libpam-net installs files into /lib; these should be moved into
the respective canonical locations in /usr/.

Please find a patch attached. It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru libpam-net-0.3/debian/changelog libpam-net-0.3/debian/changelog
--- libpam-net-0.3/debian/changelog 2024-01-22 23:38:12.0 +0100
+++ libpam-net-0.3/debian/changelog 2022-08-14 16:17:04.0 +0200
@@ -1,10 +1,3 @@
-libpam-net (0.3-2.1) UNRELEASED; urgency=medium
-
-  * Non-maintainer upload.
-  * Install PAM modules into /usr. (Closes: #-1)
-
- -- Michael Biebl   Mon, 22 Jan 2024 23:38:12 +0100
-
 libpam-net (0.3-2) unstable; urgency=medium
 
   * Fix Daniel Gröber e-mail address
diff -Nru libpam-net-0.3/debian/rules libpam-net-0.3/debian/rules
--- libpam-net-0.3/debian/rules 2024-01-22 23:37:59.0 +0100
+++ libpam-net-0.3/debian/rules 2022-08-14 16:15:40.0 +0200
@@ -19,4 +19,4 @@
 
 override_dh_auto_configure:
dh_auto_configure -- \
-   -DLIBSECURITYDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/security
+   -DLIBSECURITYDIR=/lib/$(DEB_HOST_MULTIARCH)/security


Bug#1061350: sssd: install PAM and NSS modules into /usr

2024-01-22 Thread Michael Biebl
Source: sssd
Version: 2.9.4-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. sssd installs files into /lib; these
should be moved into the respective directories in /usr/

Please find a patch attached.  It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru sssd-2.9.4/debian/changelog sssd-2.9.4/debian/changelog
--- sssd-2.9.4/debian/changelog 2024-01-22 23:33:21.0 +0100
+++ sssd-2.9.4/debian/changelog 2024-01-18 11:04:33.0 +0100
@@ -1,10 +1,3 @@
-sssd (2.9.4-1.1) UNRELEASED; urgency=medium
-
-  * Non-maintainer upload.
-  * Install PAM and NSS modules into /usr. (Closes: #-1)
-
- -- Michael Biebl   Mon, 22 Jan 2024 23:33:21 +0100
-
 sssd (2.9.4-1) unstable; urgency=medium
 
   [ Sergio Durigan Junior ]
diff -Nru sssd-2.9.4/debian/libnss-sss.install 
sssd-2.9.4/debian/libnss-sss.install
--- sssd-2.9.4/debian/libnss-sss.install2024-01-22 23:27:25.0 
+0100
+++ sssd-2.9.4/debian/libnss-sss.install2024-01-18 11:01:26.0 
+0100
@@ -1 +1 @@
-usr/lib/*/libnss_sss.so.2
+lib/*/libnss_sss.so.2
diff -Nru sssd-2.9.4/debian/libpam-sss.install 
sssd-2.9.4/debian/libpam-sss.install
--- sssd-2.9.4/debian/libpam-sss.install2024-01-22 23:27:55.0 
+0100
+++ sssd-2.9.4/debian/libpam-sss.install2024-01-18 11:01:26.0 
+0100
@@ -1,4 +1,4 @@
-usr/lib/*/security/pam_sss.so
-usr/lib/*/security/pam_sss_gss.so
+lib/*/security/pam_sss.so
+lib/*/security/pam_sss_gss.so
 usr/share/man/man8/pam_sss.8*
 usr/share/man/man8/pam_sss_gss.8*
diff -Nru sssd-2.9.4/debian/rules sssd-2.9.4/debian/rules
--- sssd-2.9.4/debian/rules 2024-01-22 23:26:56.0 +0100
+++ sssd-2.9.4/debian/rules 2024-01-18 11:01:26.0 +0100
@@ -31,8 +31,8 @@
--datadir=/usr/share/ \
--with-environment-file=/etc/default/sssd \

--with-krb5-plugin-path=/usr/lib/$(DEB_HOST_MULTIARCH)/krb5/plugins/libkrb5 \
-   --enable-nsslibdir=/usr/lib/$(DEB_HOST_MULTIARCH) \
-   --enable-pammoddir=/usr/lib/$(DEB_HOST_MULTIARCH)/security \
+   --enable-nsslibdir=/lib/$(DEB_HOST_MULTIARCH) \
+   --enable-pammoddir=/lib/$(DEB_HOST_MULTIARCH)/security \
--enable-systemtap \
--disable-static \
--disable-rpath \


Bug#1042447: Fwd: [Bug 2028819] [NEW] File-Roller should depend on 7zip package instead of p7zip-full since version 43

2024-01-22 Thread Bastian Germann

On Fri, 28 Jul 2023 13:09:22 +0300 bal...@gmail.com wrote:

It seems Debian developers planing to replace p7zip-full with official
7zip package, see https://bugs.debian.org/991428


This has been done. But please still move from p7zip-full to 7zip because 
currently,
file-roller makes p7zip-full a key package.



Bug#1061349: libpam-abl: install PAM module into /usr

2024-01-22 Thread Michael Biebl
Source: libpam-abl
Version: 0.6.0-6
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. libpam-abl installs files into /lib; these
should be moved into the respective directories in /usr/

Please find a patch attached.  It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru libpam-abl-0.6.0/debian/changelog libpam-abl-0.6.0/debian/changelog
--- libpam-abl-0.6.0/debian/changelog   2022-10-26 15:36:18.0 +0200
+++ libpam-abl-0.6.0/debian/changelog   2024-01-22 23:19:15.0 +0100
@@ -1,3 +1,11 @@
+libpam-abl (0.6.0-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix multiarch.patch to respect prefix, install PAM module into /usr.
+(Closes: #-1)
+
+ -- Michael Biebl   Mon, 22 Jan 2024 23:19:15 +0100
+
 libpam-abl (0.6.0-6) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru libpam-abl-0.6.0/debian/patches/multiarch.patch 
libpam-abl-0.6.0/debian/patches/multiarch.patch
--- libpam-abl-0.6.0/debian/patches/multiarch.patch 2022-10-26 
15:36:18.0 +0200
+++ libpam-abl-0.6.0/debian/patches/multiarch.patch 2024-01-22 
23:19:09.0 +0100
@@ -7,4 +7,4 @@
RUNTIME DESTINATION bin
  )
 -INSTALL(TARGETS pam-abl_lib DESTINATION lib/security)
-+INSTALL(TARGETS pam-abl_lib DESTINATION 
/lib/$ENV{DEB_HOST_MULTIARCH}/security)
++INSTALL(TARGETS pam-abl_lib DESTINATION lib/$ENV{DEB_HOST_MULTIARCH}/security)


Bug#1061348: mariadb: install PAM modules and systemd unit files into /usr

2024-01-22 Thread Michael Biebl
Source: mariadb
Version: 1:10.11.6-2
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. mariadb installs the following files into /lib:

$ apt-file search -x ^/lib | grep mariadb
mariadb-server: 
/lib/systemd/system/mariadb@bootstrap.service.d/use_galera_new_cluster.conf
mariadb-server: /lib/systemd/system/mysql.service
mariadb-server: /lib/systemd/system/mysqld.service
mariadb-server: /lib/x86_64-linux-gnu/security/pam_user_map.so


These should be moved into the respective directories in /usr/
I notice, that some of the systemd unit files are already correctly
installed:

$ apt-file list mariadb-server | grep /usr/lib/systemd
mariadb-server: /usr/lib/systemd/system/mariadb.service
mariadb-server: /usr/lib/systemd/system/mariadb.socket
mariadb-server: /usr/lib/systemd/system/mariadb@.service
mariadb-server: /usr/lib/systemd/system/mariadb@.socket

This discrepancy is probably a result of some files being installed by
debhelper and some by the upstream build system.

Eventually this would make sense to unify and maybe switch to
dh_installsystemd and a newer compat version.

I tried to keep the changes minimal for this patch though.
Please find it attached.  It has been build-tested.

$ dpkg -c mariadb-server_10.11.6-2.1_amd64.deb | grep -E '(systemd|security)'
drwxr-xr-x root/root 0 2024-01-22 22:30 ./etc/security/
-rw-r--r-- root/root   247 2023-11-08 16:46 ./etc/security/user_map.conf
drwxr-xr-x root/root 0 2024-01-22 22:30 ./usr/lib/systemd/
drwxr-xr-x root/root 0 2024-01-22 22:30 ./usr/lib/systemd/system/
-rw-r--r-- root/root  5865 2024-01-22 22:30 
./usr/lib/systemd/system/mariadb.service
-rw-r--r-- root/root   571 2024-01-22 22:30 
./usr/lib/systemd/system/mariadb.socket
-rw-r--r-- root/root 10007 2024-01-22 22:30 
./usr/lib/systemd/system/mariadb@.service
-rw-r--r-- root/root   578 2024-01-22 22:30 
./usr/lib/systemd/system/mariadb@.socket
drwxr-xr-x root/root 0 2024-01-22 22:30 
./usr/lib/systemd/system/mariadb@bootstrap.service.d/
-rw-r--r-- root/root   676 2023-11-08 16:46 
./usr/lib/systemd/system/mariadb@bootstrap.service.d/use_galera_new_cluster.conf
drwxr-xr-x root/root 0 2024-01-22 22:30 
./usr/lib/x86_64-linux-gnu/security/
-rw-r--r-- root/root 14176 2024-01-22 22:30 
./usr/lib/x86_64-linux-gnu/security/pam_user_map.so
lrwxrwxrwx root/root 0 2024-01-22 22:30 
./usr/lib/systemd/system/mysql.service -> mariadb.service
lrwxrwxrwx root/root 0 2024-01-22 22:30 
./usr/lib/systemd/system/mysqld.service -> mariadb.service



Note: this should not be backported to bookworm. If you intend to
backport, please revert this change or use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru mariadb-10.11.6/debian/changelog mariadb-10.11.6/debian/changelog
--- mariadb-10.11.6/debian/changelog2024-01-05 09:32:12.0 +0100
+++ mariadb-10.11.6/debian/changelog2024-01-22 22:30:08.0 +0100
@@ -1,3 +1,10 @@
+mariadb (1:10.11.6-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM module and systemd files into /usr. (Closes: #-1)
+
+ -- Michael Biebl   Mon, 22 Jan 2024 22:30:08 +0100
+
 mariadb (1:10.11.6-2) unstable; urgency=medium
 
   [ Otto Kekäläinen ]
diff -Nru mariadb-10.11.6/debian/mariadb-server.install 
mariadb-10.11.6/debian/mariadb-server.install
--- mariadb-10.11.6/debian/mariadb-server.install   2024-01-04 
11:36:14.0 +0100
+++ mariadb-10.11.6/debian/mariadb-server.install   2024-01-22 
22:27:28.0 +0100
@@ -8,10 +8,10 @@
 etc/apparmor.d/usr.sbin.mariadbd
 etc/logrotate.d/mariadb
 etc/security/user_map.conf
-lib/*/security/pam_user_map.so
-[linux-any] 
lib/systemd/system/mariadb@bootstrap.service.d/use_galera_new_cluster.conf
-[linux-any] lib/systemd/system/mysql.service
-[linux-any] lib/systemd/system/mysqld.service
+usr/lib/*/security/pam_user_map.so
+[linux-any] 
usr/lib/systemd/system/mariadb@bootstrap.service.d/use_galera_new_cluster.conf
+[linux-any] usr/lib/systemd/system/mysql.service
+[linux-any] usr/lib/systemd/system/mysqld.service
 usr/bin/aria_chk
 usr/bin/aria_dump_log
 usr/bin/aria_ftdump
diff -Nru mariadb-10.11.6/debian/mariadb-server.lintian-overrides 
mariadb-10.11.6/debian/mariadb-server.lintian-overrides
--- mariadb-10.11.6/debian/mariadb-server.lintian-overrides 2024-01-04 
11:36:14.0 +0100
+++ mariadb-10.11.6/debian/mariadb-server.lintian-overrides 2024-01-22 
22:30:08.0 +0100
@@ -9,8 +9,8 @@
 # Intentional in-context documentation
 package-contains-documentation-outside-usr-share-doc 
[usr/share/mysql/errmsg-utf8.txt]
 # mysql(d).service are symlinks to 

Bug#1061347: cryptsetup-nuke-password: improving package description

2024-01-22 Thread Christoph Anton Mitterer
Source: cryptsetup-nuke-password
Version: 4+nmu1
Severity: wishlist


Hey.

I think the description should add some important details:

*If* a sufficently advanced 3-letter-government organisation would seize 
someone’s computer,
it's rather unlikely that the idea of wiping the master keys with a special 
passphrase would
work out, since copies of the medium containing the plain dm-crypt / LUKS would 
likely have
been made (quite likely, even unknown to the user... maybe while he wasn’t at 
home).

Instead, unlocking would then not only give proof, that the user actually has 
access to the
encrypted volume (which may already be enouhg to disappear at some black site 
;-) )...
but also give "them" a key (keylogger), which "they" could then use to open the 
device,
simply from some other system, not booting into the one that contains the 
"nuke" code, and just
have access to the data.


I think right now, people may quite easily get a sense of wrong security, while 
they'd
acutally make things worse (by giving out a key).


Cheers,
Chris.


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

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


Bug#1061346: geany: identified for time_t transition but no ABI in shlibs

2024-01-22 Thread Steve Langasek
Package: geany
Version: 2.0-1
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t

Dear maintainers,

Analysis of the archive for the 64-bit time_t transition[0][1] identifies
geany as an affected package, on the basis that the headers could not
be compiled and analyzed out of the box using abi-compliance-checker[2], so
we have to assume it's affected.

However, geany's shlibs file declares a dependency on a library package name
that contains no ABI information:

$ cat DEBIAN/shlibs
libgeany 0 geany (>= 2.0)
$

It is therefore not obvious that we should rename the package to 'geany-t64'
as part of this transition.

Looking at the archive, there are packages built from the separate
geany-plugins source package which depend on this library.

Since there is no self-evident thing to do with the library package name
here, we will not be handling this package as part of the mass NMUs.
Instead I am filing a serious bug because partial upgrades from bookworm to
trixie on 32-bit architectures will result in ABI skew and may result in
broken behavior.

Thanks,
--
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[0] https://wiki.debian.org/ReleaseGoals/64bit-time
[1] https://lists.debian.org/debian-devel/2024/01/msg00041.html
[2] 
https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/geany-common/base/log.txt


signature.asc
Description: PGP signature


Bug#1061345: lib32stdc++6-14-dbg, libstdc++6-14-dbg and libx32stdc++6-14-dbg have an undeclared file conflict

2024-01-22 Thread Helmut Grohne
Package: libstdc++6-14-dbg,libx32stdc++6-14-dbg,lib32stdc++6-14-dbg
Version: 14-20240121-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + lib32stdc++6-13-dbg libstdc++6-13-dbg libx32stdc++6-13-dbg

lib32stdc++6-14-dbg, libstdc++6-14-dbg and libx32stdc++6-14-dbg have an
undeclared file conflict. This may result in an unpack error from dpkg.

The files
 * /usr/lib32/debug/libstdc++.a
 * /usr/lib32/debug/libstdc++.so
 * /usr/lib32/debug/libstdc++.so.6
 * /usr/lib32/debug/libstdc++exp.a
 * /usr/lib32/debug/libstdc++fs.a
are contained in the packages
 * lib32stdc++6-13-dbg/13.2.0-10 as present in trixie|unstable
 * lib32stdc++6-14-dbg/14-20240121-1 as present in experimental

The files
 * /usr/lib/x86_64-linux-gnu/debug/libstdc++.a
 * /usr/lib/x86_64-linux-gnu/debug/libstdc++.so
 * /usr/lib/x86_64-linux-gnu/debug/libstdc++.so.6
 * /usr/lib/x86_64-linux-gnu/debug/libstdc++exp.a
 * /usr/lib/x86_64-linux-gnu/debug/libstdc++fs.a
are contained in the packages
 * libstdc++6-13-dbg/13.2.0-10 as present in trixie|unstable
 * libstdc++6-14-dbg/14-20240121-1 as present in experimental

The files
 * /usr/libx32/debug/libstdc++.a
 * /usr/libx32/debug/libstdc++.so
 * /usr/libx32/debug/libstdc++.so.6
 * /usr/libx32/debug/libstdc++exp.a
 * /usr/libx32/debug/libstdc++fs.a
are contained in the packages
 * libx32stdc++6-13-dbg/13.2.0-10 as present in trixie|unstable
 * libx32stdc++6-14-dbg/14-20240121-1 as present in experimental

These packages can be unpacked concurrently, because there is no
relevant Replaces or Conflicts relation. Attempting to unpack these
packages concurrently results in an unpack error from dpkg, because none
of the packages installs a diversion for the affected files.

Kind regards

The Debian Usr Merge Analysis Tool

This bug report has been automatically filed with no human intervention.
The source code is available at https://salsa.debian.org/helmutg/dumat.
If the filing is unclear or in error, don't hesitate to contact
hel...@subdivi.de for assistance.



Bug#799392: closed by Debian FTP Masters (reply to Martin Buck ) (Bug#799392: fixed in calc 2.15.0.4-1)

2024-01-22 Thread Martin Buck
On Fri, Jan 19, 2024 at 07:29:05PM +0100, Francesco Poli wrote:
> Thank you so much for checking and closing the bug report!

You're welcome. And it took only 8.5 years to fix it ;-)
Sorry, I managed to completely miss this bug when working on calc.

And even though it was only a documentation issue, while analyzing it I
found a real bug that got fixed by upstream in the meantime as well.

Martin



Bug#1061274: coreutils: DEP17: move files to /usr

2024-01-22 Thread Helmut Grohne
On Sun, Jan 21, 2024 at 11:06:41PM +0100, Helmut Grohne wrote:
> I've prepared a patch for performing the conversion in a way that
> simplifies the packaging. This patch must not be backported to
> bookworm-backports as the moratorium still applies there, but I think
> backports of coreutils are fairly unlikely. The patch also allows us to
> get rid of the remaining maintainer scripts.

IRC user cacin observed that my patch left an empty /bin directory.
Thanks. I'm attaching an updated patch that takes care of it.

Helmut
diff --minimal -Nru coreutils-9.4/debian/changelog 
coreutils-9.4/debian/changelog
--- coreutils-9.4/debian/changelog  2024-01-02 14:54:03.0 +0100
+++ coreutils-9.4/debian/changelog  2024-01-21 22:33:08.0 +0100
@@ -1,3 +1,10 @@
+coreutils (9.4-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * DEP17: Move files to /usr. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 21 Jan 2024 22:33:08 +0100
+
 coreutils (9.4-3) unstable; urgency=low
 
   * remove arch restriction from libssl-dev build-depend
diff --minimal -Nru coreutils-9.4/debian/control coreutils-9.4/debian/control
--- coreutils-9.4/debian/control2024-01-02 14:22:27.0 +0100
+++ coreutils-9.4/debian/control2024-01-21 22:33:08.0 +0100
@@ -11,6 +11,7 @@
 Pre-Depends: ${shlibs:Depends}, ${misc:Pre-Depends}
 Essential: yes
 Depends: ${misc:Depends}
+Breaks: usrmerge (<< 39)
 Description: GNU core utilities
  This package contains the basic file, shell and text manipulation
  utilities which are expected to exist on every operating system.
diff --minimal -Nru coreutils-9.4/debian/coreutils.dirs 
coreutils-9.4/debian/coreutils.dirs
--- coreutils-9.4/debian/coreutils.dirs 2014-09-01 15:51:06.0 +0200
+++ coreutils-9.4/debian/coreutils.dirs 2024-01-21 22:33:08.0 +0100
@@ -1,2 +1 @@
-bin
 usr/share/doc/coreutils
diff --minimal -Nru coreutils-9.4/debian/coreutils.postinst 
coreutils-9.4/debian/coreutils.postinst
--- coreutils-9.4/debian/coreutils.postinst 2022-09-20 17:04:38.0 
+0200
+++ coreutils-9.4/debian/coreutils.postinst 1970-01-01 01:00:00.0 
+0100
@@ -1,8 +0,0 @@
-#!/bin/sh
-set -e
-
-if [ "$1" = 'configure' -a ! -e "$DPKG_ROOT/usr/bin/touch" ]; then
-  ln -s /bin/touch "$DPKG_ROOT/usr/bin/touch"
-fi
-
-#DEBHELPER#
diff --minimal -Nru coreutils-9.4/debian/coreutils.postrm 
coreutils-9.4/debian/coreutils.postrm
--- coreutils-9.4/debian/coreutils.postrm   2022-09-20 17:04:49.0 
+0200
+++ coreutils-9.4/debian/coreutils.postrm   1970-01-01 01:00:00.0 
+0100
@@ -1,8 +0,0 @@
-#!/bin/sh
-set -e
-
-if [ "$1" = 'remove' -a -L "$DPKG_ROOT/usr/bin/touch" ]; then
-  rm "$DPKG_ROOT/usr/bin/touch"
-fi
-
-#DEBHELPER#
diff --minimal -Nru coreutils-9.4/debian/rules coreutils-9.4/debian/rules
--- coreutils-9.4/debian/rules  2023-11-10 14:31:21.0 +0100
+++ coreutils-9.4/debian/rules  2024-01-21 22:33:08.0 +0100
@@ -36,11 +36,6 @@
 override_dh_install-arch: 
dh_install -a
 
-   # some things go in root rather than usr
-   for f in $(BIN_PROGS); do \
-   mv $(d)/usr/bin/$$f $(d)/bin/$$f; \
-   done
-   
# backward compatability
ln -s /usr/bin/md5sum $(d)/usr/bin/md5sum.textutils
ln -s /usr/share/man/man1/md5sum.1 
$(d)/usr/share/man/man1/md5sum.textutils.1
@@ -49,8 +44,6 @@
 ifeq ($(DEB_HOST_ARCH_OS),linux)
# kill from procps is linux-specific
rm -f $(d)/usr/bin/kill $(d)/usr/share/man/man1/kill.1
-else
-   mv $(d)/usr/bin/kill $(d)/bin
 endif
rm -f $(d)/usr/bin/hostname $(d)/usr/share/man/man1/hostname.1
rm -f $(d)/usr/bin/uptime $(d)/usr/share/man/man1/uptime.1


Bug#1060270: /lib/cryptsetup/askpass: coordinated move to /usr for DEP17

2024-01-22 Thread Helmut Grohne
Hi,

On Fri, Jan 19, 2024 at 12:42:59PM +0100, Helmut Grohne wrote:
> Chris Hofstaedler found an inconsistency in the remove-after annotations
> where I mixed trixie and forky in bad ways. Attaching an updated patch,
> thanks.

I'm sorry for going another iteration. Chris Hofstaedler also discovered
that a sequence of

echo cryptsetup-nuke-password deinstall | dpkg --set-selections
dpkg --auto-deconfigure -i cryptsetup.deb cryptsetup-bin.deb

would result in

dpkg-divert: error: rename involves overwriting 
'/usr/lib/cryptsetup/askpass' with
  different file '/usr/lib/cryptsetup/askpass.usr-is-merged', not allowed

and fail the installation.

My revised patch downgraded the Conflicts declaration to Breaks based on
a misunderstanding of how Breaks work. I had foolishly assumed that
Breaks would require cryptsetup-nuke-password to be removed by the time
cryptsetup is configured. Breaks only ensure that
cryptsetup-nuke-password is deconfigured though. Hence,
/usr/lib/cryptsetup/askpass is still installed by
cryptsetup-nuke-password when cryptsetup.postinst is run, which explains
the failure. We really need Conflicts here.

I've attached an updated patch and hope it's right this time.

Helmut
diff --minimal -Nru cryptsetup-2.6.1/debian/changelog 
cryptsetup-2.6.1/debian/changelog
--- cryptsetup-2.6.1/debian/changelog   2023-12-05 17:48:58.0 +0100
+++ cryptsetup-2.6.1/debian/changelog   2024-01-05 18:56:40.0 +0100
@@ -1,3 +1,10 @@
+cryptsetup (2:2.6.1-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * DEP17: Move fles to /usr. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 05 Jan 2024 18:56:40 +0100
+
 cryptsetup (2:2.6.1-6) unstable; urgency=medium
 
   [ Kevin Locke ]
diff --minimal -Nru cryptsetup-2.6.1/debian/control 
cryptsetup-2.6.1/debian/control
--- cryptsetup-2.6.1/debian/control 2023-12-05 17:48:58.0 +0100
+++ cryptsetup-2.6.1/debian/control 2024-01-05 18:56:40.0 +0100
@@ -43,6 +43,7 @@
  dmsetup,
  ${misc:Depends},
  ${shlibs:Depends}
+Conflicts: cryptsetup-nuke-password (<< 4+nmu2~)
 Suggests: cryptsetup-initramfs, dosfstools, keyutils, liblocale-gettext-perl
 Description: disk encryption support - startup scripts
  Cryptsetup provides an interface for configuring encryption on block
diff --minimal -Nru cryptsetup-2.6.1/debian/cryptsetup-bin.install 
cryptsetup-2.6.1/debian/cryptsetup-bin.install
--- cryptsetup-2.6.1/debian/cryptsetup-bin.install  2023-12-05 
17:48:58.0 +0100
+++ cryptsetup-2.6.1/debian/cryptsetup-bin.install  2024-01-05 
18:56:40.0 +0100
@@ -1,5 +1,5 @@
-sbin/cryptsetup
-sbin/integritysetup
-sbin/veritysetup
+usr/sbin/cryptsetup
+usr/sbin/integritysetup
+usr/sbin/veritysetup
 usr/lib/tmpfiles.d/cryptsetup.conf
 usr/share/locale/*/*/*
diff --minimal -Nru cryptsetup-2.6.1/debian/cryptsetup-ssh.install 
cryptsetup-2.6.1/debian/cryptsetup-ssh.install
--- cryptsetup-2.6.1/debian/cryptsetup-ssh.install  2023-12-05 
17:48:58.0 +0100
+++ cryptsetup-2.6.1/debian/cryptsetup-ssh.install  2024-01-05 
18:56:40.0 +0100
@@ -1,2 +1,2 @@
-lib/${DEB_HOST_MULTIARCH}/cryptsetup/libcryptsetup-token-ssh.so
-sbin/cryptsetup-ssh
+usr/lib/${DEB_HOST_MULTIARCH}/cryptsetup/libcryptsetup-token-ssh.so
+usr/sbin/cryptsetup-ssh
diff --minimal -Nru cryptsetup-2.6.1/debian/cryptsetup-suspend.install 
cryptsetup-2.6.1/debian/cryptsetup-suspend.install
--- cryptsetup-2.6.1/debian/cryptsetup-suspend.install  2023-12-05 
17:48:58.0 +0100
+++ cryptsetup-2.6.1/debian/cryptsetup-suspend.install  2024-01-05 
18:56:40.0 +0100
@@ -1,5 +1,5 @@
-debian/scripts/suspend/cryptsetup-suspend /lib/cryptsetup/scripts/suspend/
-debian/scripts/suspend/cryptsetup-suspend-wrapper 
/lib/cryptsetup/scripts/suspend/
-debian/scripts/suspend/cryptsetup-suspend.shutdown 
/lib/systemd/system-shutdown/
+debian/scripts/suspend/cryptsetup-suspend /usr/lib/cryptsetup/scripts/suspend/
+debian/scripts/suspend/cryptsetup-suspend-wrapper 
/usr/lib/cryptsetup/scripts/suspend/
+debian/scripts/suspend/cryptsetup-suspend.shutdown 
/usr/lib/systemd/system-shutdown/
 debian/scripts/suspend/suspend.conf /etc/cryptsetup/
-debian/scripts/suspend/systemd/cryptsetup-suspend.conf 
/lib/systemd/system/systemd-suspend.service.d/
+debian/scripts/suspend/systemd/cryptsetup-suspend.conf 
/usr/lib/systemd/system/systemd-suspend.service.d/
diff --minimal -Nru cryptsetup-2.6.1/debian/cryptsetup-udeb.install 
cryptsetup-2.6.1/debian/cryptsetup-udeb.install
--- cryptsetup-2.6.1/debian/cryptsetup-udeb.install 2023-12-05 
17:48:58.0 +0100
+++ cryptsetup-2.6.1/debian/cryptsetup-udeb.install 2024-01-05 
18:56:40.0 +0100
@@ -1,7 +1,7 @@
-debian/askpass  /lib/cryptsetup/
-debian/checks/* /lib/cryptsetup/checks/
-debian/cryptdisks-functions /lib/cryptsetup/
-debian/functions/lib/cryptsetup/
-debian/scripts/decrypt_*/lib/cryptsetup/scripts/
-debian/scripts/passdev  

Bug#1059533: DEP17: handle /usr-move for gzip and its diversions by zutils

2024-01-22 Thread Helmut Grohne
On Thu, Jan 04, 2024 at 10:08:36PM +0100, Helmut Grohne wrote:
> Attached:
>  * Fixed testcase.sh
>  * Fixed zutils patch (changes 1 line in zutils.preinst)

I eventually figured that there is a way out of the policy violation of
temporarily loosing e.g. /bin/zcat. The scenario was:

echo zutils deinstall | dpkg --set-selections
dpkg --install gzip.deb

In this scenario, Conflicts does not prevent unpack of gzip while zutils
is still unpacked and no amount of changes to zutils can prevent the
loss. What can prevent loss here is changes to gzip.preinst though!

I've implemented this approach for cryptsetup+cryptsetup-nuke-password
and am attaching a very similar implementation for gzip and zutils:

gzip.preinst will now check whether /bin/$tool has been diverted but
/usr/bin/$tool has not. This covers exactly the case above. When this
happens, it'll temporarily duplicate the diversion on behalf of zutils.
If zutils.preinst runs, it'll fix up the diversions, otherwise
gzip.postinst will undo what gzip.preinst did. With these changes, the
code for restoring lost files can go away and we no longer cause any
loss at all, thus that policy violation is removed. The only downside is
that gzip has to help zutils fix up its diversions and thus we
temporarily add zutils-specific code to the gzip package. I think that's
a good trade-off.

Helmut
diff -Nru gzip-1.12/debian/changelog gzip-1.12/debian/changelog
--- gzip-1.12/debian/changelog  2022-04-10 04:22:26.0 +0200
+++ gzip-1.12/debian/changelog  2023-12-23 07:46:32.0 +0100
@@ -1,3 +1,10 @@
+gzip (1.12-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move files to /usr (closes: #-1)
+
+ -- Helmut Grohne   Sat, 23 Dec 2023 07:46:32 +0100
+
 gzip (1.12-1) sid; urgency=high
 
   * new upstream release
diff -Nru gzip-1.12/debian/control gzip-1.12/debian/control
--- gzip-1.12/debian/control2022-04-10 04:05:08.0 +0200
+++ gzip-1.12/debian/control2023-12-23 07:27:28.0 +0100
@@ -16,6 +16,7 @@
 Pre-Depends: ${shlibs:Depends}
 Depends: dpkg (>= 1.15.4) | install-info
 Suggests: less
+Conflicts: zutils (<< 1.12-3.1~)
 Description: GNU compression utilities
  This package provides the standard GNU file compression utilities, which
  are also the default compression tools for Debian.  They typically operate
diff -Nru gzip-1.12/debian/dirs gzip-1.12/debian/dirs
--- gzip-1.12/debian/dirs   2022-04-09 04:15:18.0 +0200
+++ gzip-1.12/debian/dirs   2023-12-23 07:46:32.0 +0100
@@ -1,3 +1,2 @@
-bin
 usr/share/info
 usr/share/man/man1
diff -Nru gzip-1.12/debian/gzip.postinst gzip-1.12/debian/gzip.postinst
--- gzip-1.12/debian/gzip.postinst  1970-01-01 01:00:00.0 +0100
+++ gzip-1.12/debian/gzip.postinst  2023-12-23 07:46:32.0 +0100
@@ -0,0 +1,22 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:forky
+if [ "$1" = configure ]; then
+   for tool in zcat zcmp zdiff zegrep zfgrep zgrep; do
+   if [ "$(dpkg-divert --truename "/usr/bin/$tool")" = 
"/usr/bin/$tool.usr-is-merged" ] &&
+   [ "$(dpkg-divert --listpackage "/usr/bin/$tool")" = 
zutils ]; then
+   # This diversion was added by preinst and. This
+   # indicates that zutils was unpacked at preinst time
+   # and is now removed. Thus we clean up the diversion.
+   echo "Removing duplicated diversion of /bin/$tool after 
zutils is removed."
+   dpkg-divert --rename --package zutils \
+   --divert "/usr/bin/$tool.usr-is-merged" \
+   --remove "/usr/bin/$tool"
+   fi
+   done
+fi
+# end-remove-after
+
+#DEBHELPER#
diff -Nru gzip-1.12/debian/gzip.preinst gzip-1.12/debian/gzip.preinst
--- gzip-1.12/debian/gzip.preinst   1970-01-01 01:00:00.0 +0100
+++ gzip-1.12/debian/gzip.preinst   2023-12-23 07:46:32.0 +0100
@@ -0,0 +1,22 @@
+#!/bin/sh
+
+set -e
+
+# begin-remove-after: released:forky
+if [ "$1" = upgrade ] || [ "$1" = install ]; then
+   for tool in zcat zcmp zdiff zegrep zfgrep zgrep; do
+   if [ "$(dpkg-divert --truename "/bin/$tool")" = 
"/bin/$tool.gzip" ] &&
+   [ "$(dpkg-divert --listpackage "/bin/$tool")" = zutils 
] &&
+   [ "$(dpkg-divert --truename "/usr/bin/$tool")" = 
"/usr/bin/$tool" ]; then
+   # A pre-/usr-move diversion is installed by zutils.
+   echo "Mitigating diversion of /bin/$tool on behalf of 
zutils"
+   dpkg-divert --no-rename --package zutils \
+   --divert "/usr/bin/$tool.usr-is-merged" \
+   --add "/usr/bin/$tool"
+   fi
+   done
+fi
+# end-remove-after
+
+
+#DEBHELPER#
diff -Nru gzip-1.12/debian/rules gzip-1.12/debian/rules
--- gzip-1.12/debian/rules  2022-04-09 

Bug#1061315: inn2 ftbfs with Python 3.12 as the default

2024-01-22 Thread Matthias Klose

On 22.01.24 21:31, Julien ÉLIE wrote:

Hi Matthias,


Package: src:inn2
Version: 2.7.2~20231223-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

with python3-defaults from experimental:

[...]
checking for Python.h... yes
checking for Py_Initialize... no
configure: error: in `/<>/build':
configure: error: unable to link with Python library
See `config.log' for more details


Could you put the end of the config.log file? (the part showing the 
failure to find Py_Initialize)


sorry, just reporting the issue as found on the Ubuntu buildds:

https://launchpad.net/ubuntu/+source/inn2/2.7.2~20231223-1build2



Bug#1060795: bluez: Troubles with bluetooth after upgrade from bookworm to testing (trixie): br-connection-unknown

2024-01-22 Thread Brian Tarricone
I'm running into this too, poked around a little bit, and found an issue filed 
on BlueZ's github repo that seems like it might be related: 
https://github.com/bluez/bluez/issues/686

Unclear what the proper fix is; there's some complaint on there that what they 
merged requires a new, unreleased kernel.  But there's also a patch posted in a 
comment that some people claim fixes it (I have not yet tested): 
https://github.com/bluez/bluez/issues/686#issuecomment-1858902231



Bug#1061344: emboss-lib: identified for time_t transition but no ABI in shlibs

2024-01-22 Thread Steve Langasek
Package: emboss-lib
Version: 6.6.0+dfsg-12
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t

Dear maintainers,

Analysis of the archive for the 64-bit time_t transition[0][1] identifies
emboss-lib as an affected package, on the basis that the headers could not
be compiled and analyzed out of the box using abi-compliance-checker[2], so
we have to assume it's affected.

However, emboss-lib's shlibs file declares a dependency on a library package
name that contains no ABI information:

$ cat DEBIAN/shlibs
libacd 6 emboss-lib (>= 6.6.0+dfsg)
libajax 6 emboss-lib (>= 6.6.0+dfsg)
libajaxdb 6 emboss-lib (>= 6.6.0+dfsg)
libajaxg 6 emboss-lib (>= 6.6.0+dfsg)
libensembl 6 emboss-lib (>= 6.6.0+dfsg)
libepcre 7 emboss-lib (>= 6.6.0+dfsg)
libeplplot 3 emboss-lib (>= 6.6.0+dfsg)
libnucleus 6 emboss-lib (>= 6.6.0+dfsg)
$

It is therefore not obvious that we should rename the package to
'emboss-lib-64' as part of this transition.

Looking at the archive, there are packages built from separate source
packages which depend on these libraries: embassy-domainatrix,
embassy-domalign, embassy-domsearch.

Since there is no self-evident thing to do with the library package name
here, we will not be handling this package as part of the mass NMUs. 
Instead I am filing a serious bug because partial upgrades from bookworm to
trixie on 32-bit architectures will result in ABI skew and may result in
broken behavior.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[0] https://wiki.debian.org/ReleaseGoals/64bit-time
[1] https://lists.debian.org/debian-devel/2024/01/msg00041.html
[2] 
https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/emboss-lib/base/log.txt


signature.asc
Description: PGP signature


Bug#1058172: unattended-upgrades: diff for NMU version 2.9.1+nmu4

2024-01-22 Thread Stefano Rivera
Control: tags 1058172 + patch
Control: tags 1058172 + pending

Dear maintainer,

I've prepared an NMU for unattended-upgrades (versioned as 2.9.1+nmu4) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

Stefano
diff -Nru unattended-upgrades-2.9.1+nmu3/debian/changelog unattended-upgrades-2.9.1+nmu4/debian/changelog
--- unattended-upgrades-2.9.1+nmu3/debian/changelog	2022-12-31 16:59:00.0 -0400
+++ unattended-upgrades-2.9.1+nmu4/debian/changelog	2024-01-22 16:11:59.0 -0400
@@ -1,3 +1,11 @@
+unattended-upgrades (2.9.1+nmu4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't run pyflakes, it dropped support for type comments.
+(Closes: #1058172)
+
+ -- Stefano Rivera   Mon, 22 Jan 2024 16:11:59 -0400
+
 unattended-upgrades (2.9.1+nmu3) unstable; urgency=medium
 
   * test: don't confuse -dbg and -unsigned with current running kernel
diff -Nru unattended-upgrades-2.9.1+nmu3/test/test_pyflakes.py unattended-upgrades-2.9.1+nmu4/test/test_pyflakes.py
--- unattended-upgrades-2.9.1+nmu3/test/test_pyflakes.py	2022-12-31 16:59:00.0 -0400
+++ unattended-upgrades-2.9.1+nmu4/test/test_pyflakes.py	2024-01-22 16:11:59.0 -0400
@@ -7,6 +7,8 @@
 """ ensure that the tree is pyflakes clean """
 
 def test_pyflakes_clean(self):
+# https://github.com/PyCQA/pyflakes/issues/683
+self.skipTest("not clean, pyflakes no longer supports type comments")
 top_src_dir = os.path.join(os.path.dirname(__file__), "..")
 targets = [
 top_src_dir,


Bug#1043240: transition: pandas 1.5 -> 2.1

2024-01-22 Thread Rebecca N. Palmer

On 22/01/2024 11:51, Julian Gilbey wrote:

Please could we wait until the "Python 3.12 is a supported version"
transition is completed?


How are you defining that?  python3-defaults 3.11.6+ in testing?  (I was 
previously told 3.12-supporting pandas and numpy in testing, which has 
happened.  I don't think any of these 25 packages are on 
https://qa.debian.org/excuses.php?package=python3-defaults , but I 
haven't checked carefully, and at least influxdb-python and tqdm do have 
what I suspect are Python 3.12 related issues.)



Adding another 25 or so RC bugs at this
point will just slow down that transition.


What exactly do you want not done until then?   Just not uploading 
pandas 2.x to unstable, or is it also a problem to have these bugs 
marked as RC in the BTS?  (In all 22 cases that are in testing at all, 
the bug is also present in the version in testing, so it being RC 
shouldn't block migration.)



(Unless pandas 1.5 is
preventing the transition, that is.)


It isn't.



Bug#1061343: tpm2-tss: FTBFS in chroot created by recent debootstrap versions

2024-01-22 Thread Aurelien Jarno
Source: tpm2-tss
Version: 4.0.1-5
Severity: important
Tags: ftbfs
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear Maintainer,

tpm2-tss fail to build from source when built in a chroot created by
debootstrap 1.0.133 or later. Starting with this version, packages with
priority "Required" are not installed in the chroot anymore, and
source packages need to explicitly add a build dependency. In the case
of tpm2-tss, the package passwd providing useradd and groupadd is
missing. This causes an FTBFS on riscv64:

| checking whether C compiler accepts -Wno-missing-braces... yes
| checking whether C compiler accepts -Wstrict-overflow=5... yes
| checking whether the linker accepts -Wl,--no-undefined... yes
| checking whether the linker accepts -Wl,-z,noexecstack... yes
| checking whether the linker accepts -Wl,-z,now... yes
| checking whether the linker accepts -Wl,-z,relro... yes
| checking for systemd-sysusers... no
| checking for systemd-tmpfiles... no
| checking for useradd... no
| checking for groupadd... no
| checking for adduser... no
| checking for addgroup... no
| configure: error: addgroup or groupadd are needed.
|   tail -v -n \+0 config.log

The full build log is available here:
https://buildd.debian.org/status/fetch.php?pkg=tpm2-tss=riscv64=4.0.1-5=1705952887=0

The solution is to add passwd as a build-depends.

Note that this bug is currently not a RC bug as riscv64 is currently not
a release architecture. It will become RC as soon as one of the two
following event happens:
- riscv64 becomes a release architecture
- trixie is released

Regards
Aurelien



Bug#1061342: gridengine: install PAM module into /usr

2024-01-22 Thread Michael Biebl
Source: gridengine
Version: 8.1.9+dfsg-11
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. gridengine installs files into /lib; these
should be moved into the respective directories in /usr/

Please find a patch attached.  It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru gridengine-8.1.9+dfsg/debian/changelog 
gridengine-8.1.9+dfsg/debian/changelog
--- gridengine-8.1.9+dfsg/debian/changelog  2023-08-13 17:56:03.0 
+0200
+++ gridengine-8.1.9+dfsg/debian/changelog  2024-01-22 21:37:36.0 
+0100
@@ -1,3 +1,10 @@
+gridengine (8.1.9+dfsg-11.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM modules into /usr (DEP 17 M2). (Closes: #-1)
+
+ -- Michael Biebl   Mon, 22 Jan 2024 21:37:36 +0100
+
 gridengine (8.1.9+dfsg-11) unstable; urgency=medium
 
   * Team upload.
diff -Nru gridengine-8.1.9+dfsg/debian/gridengine-exec.install 
gridengine-8.1.9+dfsg/debian/gridengine-exec.install
--- gridengine-8.1.9+dfsg/debian/gridengine-exec.install2023-08-13 
17:40:33.0 +0200
+++ gridengine-8.1.9+dfsg/debian/gridengine-exec.install2024-01-22 
21:37:35.0 +0100
@@ -1,3 +1,3 @@
 debian/tmp/usr/bin/*/sge_execd usr/lib/gridengine
 debian/tmp/usr/bin/*/sge_*shepherd usr/lib/gridengine
-/lib/*/security/*.so
+usr/lib/*/security/*.so
diff -Nru gridengine-8.1.9+dfsg/debian/rules gridengine-8.1.9+dfsg/debian/rules
--- gridengine-8.1.9+dfsg/debian/rules  2023-08-13 17:40:33.0 +0200
+++ gridengine-8.1.9+dfsg/debian/rules  2024-01-22 21:37:36.0 +0100
@@ -66,7 +66,7 @@
 override_dh_auto_install:
install -d debian/tmp/usr
install -d debian/tmp/usr/share
-   install -d debian/tmp/lib/$(DEB_HOST_GNU_TYPE)/security
+   install -d debian/tmp/usr/lib/$(DEB_HOST_GNU_TYPE)/security
cd source && /usr/bin/yes | ${PRECMD} scripts/distinst \
-basedir ${CURDIR}/debian \
-vdir tmp/usr \
@@ -102,7 +102,7 @@
mandb -u -c debian/tmp/usr/share/man
chmod 755 debian/scripts/init_cluster debian/gridengine-wrapper
cp source/clients/qmon/qmon.desktop debian
-   mv debian/tmp/usr/lib/*/pam_sge* 
debian/tmp/lib/$(DEB_HOST_GNU_TYPE)/security
+   mv debian/tmp/usr/lib/*/pam_sge* 
debian/tmp/usr/lib/$(DEB_HOST_GNU_TYPE)/security
 
 override_dh_installinit:
dh_installinit -p gridengine-master


Bug#1061341: cyrus-common: identified for time_t transition but no ABI in shlibs

2024-01-22 Thread Steve Langasek
Package: cyrus-common
Version: 3.8.1-1
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t

Dear maintainers,

Analysis of the archive for the 64-bit time_t transition[0][1] identifies
cyrus-common as an affected package, on the basis that the headers could not
be compiled and analyzed out of the box using abi-compliance-checker[2], so
we have to assume it's affected.

However, cyrus-commons's shlibs file declares a dependency on a library
package name that contains no ABI information:

$ cat DEBIAN/shlibs
libcyrus 0 cyrus-common (>= 3.8.1)
libcyrus_imap 0 cyrus-common (>= 3.8.1)
libcyrus_min 0 cyrus-common (>= 3.8.1)
libcyrus_sieve 0 cyrus-common (>= 3.8.1)
$

It is therefore not obvious that we should rename the package to
'cyrus-common-t64' as part of this transition.

Looking at the archive, there are packages that depend on these libraries,
cyrus-admin and cyrus-clients.  Despite being built from the same source
package, they do not have a strict versioned dependency on cyrus-common but
instead use the shlibs.

Since there is no self-evident thing to do with the library package name
here, we will not be handling this package as part of the mass NMUs. 
Instead I am filing a serious bug because partial upgrades from bookworm to
trixie on 32-bit architectures (upgrading cyrus-common without also
upgrading cyrus-{admin,clients}) will result in ABI skew and may result in
broken behavior.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[0] https://wiki.debian.org/ReleaseGoals/64bit-time
[1] https://lists.debian.org/debian-devel/2024/01/msg00041.html
[2] 
https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/cyrus-dev/base/log.txt


signature.asc
Description: PGP signature


Bug#1061315: inn2 ftbfs with Python 3.12 as the default

2024-01-22 Thread Julien ÉLIE

Hi Matthias,


Package: src:inn2
Version: 2.7.2~20231223-1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

with python3-defaults from experimental:

[...]
checking for Python.h... yes
checking for Py_Initialize... no
configure: error: in `/<>/build':
configure: error: unable to link with Python library
See `config.log' for more details


Could you put the end of the config.log file? (the part showing the 
failure to find Py_Initialize)


Maybe a problem of Python not in the path?


FWIW, I do not run trixie, but building INN with a downloaded version of 
Python 3.12 on bookworm works for me:


checking for flags to link with Python... -L/home/news/work/py3.12.1/lib 
-lpython3.12 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic

checking Python.h usability... yes
checking Python.h presence... yes
checking for Python.h... yes
checking for Py_Initialize... yes


configure:15028: checking for Py_Initialize
configure:15028: gcc -o conftest -g -O2 
-I/home/news/work/py3.12.1/include/python3.12   conftest.c 
-L/home/news/work/py3.12.1/lib -lpython3.12 -lpthread -ldl -lutil -lm 
-Xlinker -export-dynamic   >&5



--
Julien ÉLIE

« L'éternité, c'est long, surtout vers la fin. » (Woody Allen)



Bug#1061339: numpy_1.26.3-1_s390x-buildd.changes REJECTED

2024-01-22 Thread Aurelien Jarno
Source: numpy
Version: 1.26.3-1
Severity: serious

On 2024-01-22 08:24, Debian FTP Masters wrote:
> 
> 
> python3-numpy_1.26.3-1_s390x.deb: has 876 file(s) with a timestamp too far in 
> the past:
>   usr/lib/python3/dist-packages/numpy/LICENSE.txt (Thu Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/__init__.cython-30.pxd (Thu Jan  1 
> 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/__init__.pxd (Thu Jan  1 
> 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/__init__.py (Thu Jan  1 
> 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/__init__.pyi (Thu Jan  1 
> 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/_core/__init__.py (Thu 
> Jan  1 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/_core/_dtype.py 
> (Thu Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/_core/_dtype_ctypes.py (Thu Jan  1 
> 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/_core/_internal.py (Thu 
> Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/_core/_multiarray_umath.py (Thu Jan  1 
> 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/_core/multiarray.py (Thu 
> Jan  1 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/_core/umath.py 
> (Thu Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/_distributor_init.py (Thu Jan  1 00:00:00 
> 1970)  usr/lib/python3/dist-packages/numpy/_globals.py (Thu Jan  1 00:00:00 
> 1970)  usr/lib/python3/dist-packages/numpy/_pyinstaller/__init__.py (Thu Jan  
> 1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/_pyinstaller/hook-numpy.py (Thu Jan  1 
> 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/_pyinstaller/pyinstaller-smoke.py (Thu 
> Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/_pyinstaller/test_pyinstaller.py (Thu Jan 
>  1 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/_pytesttester.py (Thu 
> Jan  1 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/_pytesttester.pyi 
> (Thu Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/_typing/__init__.py (Thu Jan  1 00:00:00 
> 1970)  usr/lib/python3/dist-packages/numpy/_typing/_add_docstring.py (Thu Jan 
>  1 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/_typing/_array_like.py 
> (Thu Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/_typing/_callable.pyi (Thu Jan  1 
> 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/_typing/_char_codes.py 
> (Thu Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/_typing/_dtype_like.py (Thu Jan  1 
> 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/_typing/_extended_precision.py (Thu Jan  
> 1 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/_typing/_nbit.py (Thu 
> Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/_typing/_nested_sequence.py (Thu Jan  1 
> 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/_typing/_scalars.py (Thu 
> Jan  1 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/_typing/_shape.py 
> (Thu Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/_typing/_ufunc.pyi (Thu Jan  1 00:00:00 
> 1970)  usr/lib/python3/dist-packages/numpy/_typing/setup.py (Thu Jan  1 
> 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/_utils/__init__.py (Thu 
> Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/_utils/_convertions.py (Thu Jan  1 
> 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/_utils/_inspect.py (Thu 
> Jan  1 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/_utils/_pep440.py 
> (Thu Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/array_api/__init__.py (Thu Jan  1 
> 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/array_api/_array_object.py (Thu Jan  1 
> 00:00:00 1970)  usr/lib/python3/dist-packages/numpy/array_api/_constants.py 
> (Thu Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/array_api/_creation_functions.py (Thu Jan 
>  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/array_api/_data_type_functions.py (Thu 
> Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/array_api/_dtypes.py (Thu Jan  1 00:00:00 
> 1970)  
> usr/lib/python3/dist-packages/numpy/array_api/_elementwise_functions.py (Thu 
> Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/array_api/_indexing_functions.py (Thu Jan 
>  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/array_api/_manipulation_functions.py (Thu 
> Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/array_api/_searching_functions.py (Thu 
> Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/array_api/_set_functions.py (Thu Jan  1 
> 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/array_api/_sorting_functions.py (Thu Jan  
> 1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/array_api/_statistical_functions.py (Thu 
> Jan  1 00:00:00 1970)  
> usr/lib/python3/dist-packages/numpy/array_api/_typing.py (Thu Jan  1 00:00:00 
> 1970)  usr/lib/python3/dist-packages/numpy/array_api/_utility_functions.py 
> (Thu Jan  1 00:00:00 1970)  
> 

Bug#1061340: pelican: Please run tests (during build and in an autopkgtest)

2024-01-22 Thread Louis-Philippe Véronneau

Package: src:pelican
Severity: important
Control: tags -1 patch

Dear maintainers,

This package currently does not run any tests, neither during build nor as 
autopkgtests. This is pretty bad, as it means the package could be broken 
without no one realising it! BTS #1057484 is a pretty good example of why it's 
important to run tests.

I've attached a pretty trivial patch that seems to do 95% of the job. Of 
course, the last 5% is always the hardest, but from the following error log, it 
doesn't seem so bad. IMHO, even skipping those failing tests and completely 
ignoring them would already be an improvement over the current situation.

As for autopkgtests, the magic line to add to d/control is `Testsuite: 
autopkgtest-pkg-pybuild`.

==
ERROR: test_theme_overrides 
(pelican.tests.test_generators.TestGenerator.test_theme_overrides)
Test that the THEME_TEMPLATES_OVERRIDES configuration setting is
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12/build/pelican/tests/test_generators.py",
 line 148, in test_theme_overrides
filename = generator.get_template("taglist").filename
   ^
  File "/<>/.pybuild/cpython3_3.12/build/pelican/generators.py", 
line 127, in get_template
raise PelicanTemplateNotFound(
pelican.generators.PelicanTemplateNotFound: [templates] unable to load taglist[.html] from 
['/<>/.pybuild/cpython3_3.12/build/pelican/tests/theme_overrides/level1', 
'/<>/.pybuild/cpython3_3.12/build/pelican/tests/theme_overrides/level2', 
'/<>/.pybuild/cpython3_3.12/build/pelican/themes/simple/templates']

==
ERROR: test_md_extensions_deprecation 
(pelican.tests.test_pelican.TestPelican.test_md_extensions_deprecation)
Test that a warning is issued if MD_EXTENSIONS is used
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12/build/pelican/tests/test_pelican.py", 
line 234, in test_md_extensions_deprecation
settings = read_settings(
   ^^
  File "/<>/.pybuild/cpython3_3.12/build/pelican/settings.py", 
line 213, in read_settings
settings = configure_settings(settings)
   
  File "/<>/.pybuild/cpython3_3.12/build/pelican/settings.py", 
line 575, in configure_settings
raise Exception(
Exception: You need to specify a path containing the content (see pelican 
--help for more information)

==
ERROR: test_theme_static_paths_copy 
(pelican.tests.test_pelican.TestPelican.test_theme_static_paths_copy)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12/build/pelican/tests/test_pelican.py", 
line 162, in test_theme_static_paths_copy
settings = read_settings(
   ^^
  File "/<>/.pybuild/cpython3_3.12/build/pelican/settings.py", 
line 184, in read_settings
settings = dict(get_settings_from_file(path), **settings)

  File "/<>/.pybuild/cpython3_3.12/build/pelican/settings.py", 
line 237, in get_settings_from_file
module = load_source(name, path)
 ^^^
  File "/<>/.pybuild/cpython3_3.12/build/pelican/settings.py", 
line 19, in load_source
spec.loader.exec_module(mod)
  File "", line 990, in exec_module
  File "", line 1127, in get_code
  File "", line 1185, in get_data
FileNotFoundError: [Errno 2] No such file or directory: 
'/<>/.pybuild/cpython3_3.12/build/samples/pelican.conf.py'

==
ERROR: test_theme_static_paths_copy_single_file 
(pelican.tests.test_pelican.TestPelican.test_theme_static_paths_copy_single_file)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.12/build/pelican/tests/test_pelican.py", 
line 188, in test_theme_static_paths_copy_single_file
settings = read_settings(
   ^^
  File "/<>/.pybuild/cpython3_3.12/build/pelican/settings.py", 
line 184, in read_settings
settings = dict(get_settings_from_file(path), **settings)

  File "/<>/.pybuild/cpython3_3.12/build/pelican/settings.py", 
line 237, in get_settings_from_file
module = load_source(name, path)
 ^^^
  File "/<>/.pybuild/cpython3_3.12/build/pelican/settings.py", 
line 19, in load_source
spec.loader.exec_module(mod)
  File "", line 990, in exec_module
  File "", line 1127, in get_code
  File "", line 1185, in get_data
FileNotFoundError: [Errno 2] No such file or directory: 

Bug#1061338: RFS: kvazaar/2.3.0-1 [ITP] -- HEVC encoder

2024-01-22 Thread Joachim Bauch

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: 
pkg-multimedia-maintain...@lists.alioth.debian.org,sramac...@debian.org


(CC'ing pkg-multimedia-maintainers as the group where I'm planning to
maintain it and Sebastian who sponsored other packages from me)

Dear mentors,

I am looking for a sponsor for my package "kvazaar":

 * Package name : kvazaar
   Version  : 2.3.0-1
   Upstream contact : https://ultravideo.fi/#encoder
 * URL  : https://github.com/ultravideo/kvazaar
 * License  : BSD-2-clause, ISC, BSD-3-clause
 * Vcs  : https://salsa.debian.org/multimedia-team/kvazaar
   Section  : libs

The source builds the following binary packages:

  kvazaar - HEVC encoder - application
  libkvazaar7 - HEVC encoder - shared library
  libkvazaar-dev - HEVC encoder - development files
  kvazaar-doc - HEVC encoder - documentation

Note: the packaging files (for now) are available at

https://salsa.debian.org/fancycode/kvazaar

I'm planning to move this to the "multimedia-team" group once packaging
is final.

Package "hm" is required for building to run the tests from kvazaar.
See bug 1060809 for the RFS status of "hm".

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


  https://mentors.debian.net/package/kvazaar/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/k/kvazaar/kvazaar_2.3.0-1.dsc


Changes for the initial release:

 kvazaar (2.3.0-1) unstable; urgency=medium
 .
   * Initial release. (Closes: #1060341)

Regards,
--
  Joachim Bauch


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1061337: google-compute-engine-oslogin: install files into /usr

2024-01-22 Thread Michael Biebl
Source: google-compute-engine-oslogin
Version: 20210907.00-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. google-compute-engine-oslogin installs files into /lib; these
should be moved into the respective directories in /usr/

Please find a patch attached.  It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru google-compute-engine-oslogin-20210907.00/debian/changelog 
google-compute-engine-oslogin-20210907.00/debian/changelog
--- google-compute-engine-oslogin-20210907.00/debian/changelog  2021-09-21 
12:19:19.0 +0200
+++ google-compute-engine-oslogin-20210907.00/debian/changelog  2024-01-22 
21:04:05.0 +0100
@@ -1,3 +1,14 @@
+google-compute-engine-oslogin (20210907.00-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install PAM module and systemd files into /usr (DEP17 M2).
+Use systemd.pc to get the paths for the unit and preset dir.
+Add a corresponding versioned Build-Depends on debhelper (>= 13.11.6) to
+ensure we have a recent enough dh_installsystemd.
+(Closes: #-1)
+
+ -- Michael Biebl   Mon, 22 Jan 2024 21:04:05 +0100
+
 google-compute-engine-oslogin (20210907.00-1) unstable; urgency=medium
 
   * Initial release.
diff -Nru google-compute-engine-oslogin-20210907.00/debian/control 
google-compute-engine-oslogin-20210907.00/debian/control
--- google-compute-engine-oslogin-20210907.00/debian/control2021-09-21 
12:19:19.0 +0200
+++ google-compute-engine-oslogin-20210907.00/debian/control2024-01-22 
21:04:05.0 +0100
@@ -6,6 +6,9 @@
  Bastian Blank 
 Build-Depends:
  debhelper-compat (= 13),
+ debhelper (>= 13.11.6),
+ systemd-dev,
+ pkgconf,
  libcurl4-openssl-dev,
  libgtest-dev ,
  libjson-c-dev,
diff -Nru google-compute-engine-oslogin-20210907.00/debian/rules 
google-compute-engine-oslogin-20210907.00/debian/rules
--- google-compute-engine-oslogin-20210907.00/debian/rules  2021-09-21 
12:19:19.0 +0200
+++ google-compute-engine-oslogin-20210907.00/debian/rules  2024-01-22 
21:04:05.0 +0100
@@ -8,7 +8,12 @@
dh $@
 
 override_dh_auto_install:
-   dh_auto_install -- LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) 
PAMDIR=/lib/$(DEB_HOST_MULTIARCH)/security VERSION=$(DEB_VERSION_UPSTREAM)
+   dh_auto_install -- \
+   LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) \
+   PAMDIR=/usr/lib/$(DEB_HOST_MULTIARCH)/security \
+   SYSTEMDDIR=$(shell pkgconf --variable=systemd_system_unit_dir 
systemd) \
+   PRESETDIR=$(shell pkgconf --variable=systemd_system_preset_dir 
systemd) \
+   VERSION=$(DEB_VERSION_UPSTREAM)
 
 override_dh_auto_test:
$(MAKE) alltests


Bug#1061336: ITP: chatterino -- Chatterino is a chat client for Twitch chat. It aims to be an

2024-01-22 Thread matt
Package: wnpp
Severity: wishlist
Owner: matt 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: chatterino
  Version : 2.4.6
  Upstream Author : https://github.com/chatterino/chatterino2
* URL : https://chatterino.com/

* URL :
* License : (MIT)
  Programming Lang: (C++)
  Description : Chatterino is a chat client for Twitch chat.

Chatterino is a chat client for Twitch chat. It aims to be an
improved/extended version of the Twitch web chat.

 - this package is useful to me because I don't need to open the browser
   to look at chat, it does not have dependencies
   for any other packages, I use it, gnome-twitch has similar
   functionality but is unmaintained and lacks features that chatterino has 
example banning seeing certain emotes,
 - I plan on maintaining it by compiling the latest package or use the
   deb they provide, inside a packaging team
 I would need a need a sponsor



Bug#1061335: python3-breezy: ships files in `/build`

2024-01-22 Thread Ansgar
Package: python3-breezy
Version: 3.3.5-1
Severity: serious

Hi,

python3-breezy ships files in `/build`:

+---
| % dpkg-deb -c python3-breezy_3.3.5-1_amd64.deb | head
| drwxr-xr-x root/root 0 2024-01-19 23:12 ./
| drwxr-xr-x root/root 0 2024-01-19 23:12 ./build/
| drwxr-xr-x root/root 0 2024-01-19 23:12 ./build/reproducible-path/
| drwxr-xr-x root/root 0 2024-01-19 23:12 
./build/reproducible-path/breezy-3.3.5/
| drwxr-xr-x root/root 0 2024-01-19 23:12 
./build/reproducible-path/breezy-3.3.5/debian/
+---

This is probably not intended.

Ansgar



Bug#1061334: RM: oce -- ROM (team); dead upstream; alternative exists; leaf package

2024-01-22 Thread Bastian Germann

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

As noted in #1036879, oce is dead upstream. The last reverse dependency has switched to the alternative opencascade some 
months ago, which has not caused any issue. Please remove oce from unstable.




Bug#1060053: RFP: wayprompt -- multi-purpose (password-)prompt tool for Wayland

2024-01-22 Thread Antoine Beaupré
On 2024-01-05 12:02:20, Piotr Ożarowski wrote:

[...]

> Note that this project is written in Zig which is not packaged for Debian yet,
> I didn't find any other PinEntry replacement for Wayland.

Interesting project! Too bad we don't have Zig yet (or, maybe, that this
one is written in Zig...)

that said, i'm not sure what you mean by "for Wayland". I'm currently
using pinentry-qt and it works in Wayland. pinentry-gnome3 is also
packaged and works.

Neither of those properly grabs the keyboard in Sway, that said, but I
suspect this is probably an interoperability issue more than anything
else.

a.

-- 
Every one of us is, in the cosmic perspective, precious. If a human
disagrees with you, let him live. In a hundred billion galaxies, you
will not find another.   - Carl Sagan



Bug#1061333: RFS: streamlink/6.5.1-1 -- CLI for extracting video streams from various websites to a video player

2024-01-22 Thread Alexis Murzeau

Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor for my package "streamlink" for a new
upstream version 6.5.1.

  * Package name: streamlink
Version : 6.5.1-1
Upstream Author : Streamlink Team
  * URL : https://streamlink.github.io/
  * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
  * Vcs : https://salsa.debian.org/amurzeau/streamlink/
Section : python

It builds those binary packages:
  python3-streamlink - Python module for extracting video streams from
various websites
  python3-streamlink-doc - CLI for extracting video streams from
various websites (documentation)
  streamlink - CLI for extracting video streams from various websites
to a video player


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

  https://mentors.debian.net/package/streamlink/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.5.1-1.dsc



Changes since the last upload to unstable:
streamlink (6.5.1-1) unstable; urgency=medium

  * New upstream version 6.5.1
  * d/copyright: update copyright years to 2024

 -- Alexis Murzeau   Mon, 22 Jan 2024 20:11:11 +0100

Regards,

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|


OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature


Bug#1061332: cifs-utils: install files into /usr

2024-01-22 Thread Michael Biebl
Source: cifs-utils
Version: 2:7.0-2
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

We want to finalize the /usr-merge via DEP17 by moving all files to
/usr. cifs-utils installs files into /lib and /sbin; these should
be moved into the respective directories in /usr/

Please find a patch attached.  It has been build-tested.

Note: this should not be backported to bookworm. If you intend to
backport, please use dh_movetousr instead.

If your package will change for the t64 transition or otherwise
rename/split/move its binaries (packages) during trixie, please
then upload to experimental and get in touch with the UsrMerge
driver, please see the wiki [1].

Michael

[1] https://wiki.debian.org/UsrMerge
diff -Nru cifs-utils-7.0/debian/changelog cifs-utils-7.0/debian/changelog
--- cifs-utils-7.0/debian/changelog 2022-08-26 16:06:45.0 +0200
+++ cifs-utils-7.0/debian/changelog 2024-01-22 20:20:42.0 +0100
@@ -1,3 +1,10 @@
+cifs-utils (2:7.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install files into /usr (DEP17 M2). (Closes: #-1)
+
+ -- Michael Biebl   Mon, 22 Jan 2024 20:20:42 +0100
+
 cifs-utils (2:7.0-2) unstable; urgency=medium
 
   * root_sbindir-hook.patch - fix upstream fix for non-parallel
diff -Nru cifs-utils-7.0/debian/cifs-utils.lintian-overrides 
cifs-utils-7.0/debian/cifs-utils.lintian-overrides
--- cifs-utils-7.0/debian/cifs-utils.lintian-overrides  2022-08-25 
22:11:10.0 +0200
+++ cifs-utils-7.0/debian/cifs-utils.lintian-overrides  2024-01-22 
20:20:04.0 +0100
@@ -1 +1 @@
-cifs-utils: elevated-privileges 4755 root/root [sbin/mount.cifs]
+cifs-utils: elevated-privileges 4755 root/root [usr/sbin/mount.cifs]
diff -Nru cifs-utils-7.0/debian/rules cifs-utils-7.0/debian/rules
--- cifs-utils-7.0/debian/rules 2022-05-10 21:59:48.0 +0200
+++ cifs-utils-7.0/debian/rules 2024-01-22 20:20:42.0 +0100
@@ -6,7 +6,7 @@
dh $@ --with bash-completion
 
 override_dh_auto_configure:
-   dh_auto_configure -- --enable-cifsidmap --enable-cifscreds 
--with-libcap-ng=auto --enable-pam 
--with-pamdir=/lib/$(DEB_HOST_MULTIARCH)/security
+   ROOTSBINDIR=/usr/sbin dh_auto_configure -- --enable-cifsidmap 
--enable-cifscreds --with-libcap-ng=auto --enable-pam 
--with-pamdir=/usr/lib/$(DEB_HOST_MULTIARCH)/security
 
 override_dh_auto_install-indep:
 override_dh_auto_install-arch:
@@ -16,7 +16,7 @@
 
 override_dh_fixperms:
dh_fixperms
-   chmod u+s debian/cifs-utils/sbin/mount.cifs
+   chmod u+s debian/cifs-utils/usr/sbin/mount.cifs
 
 override_dh_auto_clean-indep:
 override_dh_auto_clean-arch:


Bug#1061331: RM: aptfs -- RoM; abandoned upstream

2024-01-22 Thread Chris Lamb
Package: ftp.debian.org
Severity: normal

Hi,

I am both the package maintainer and the upstream maintainer, and I
think aptfs should be removed from the archive. Many thanks.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-



Bug#1008625: RFH: qiskit-terra

2024-01-22 Thread Diego M. Rodriguez
Hello Andreas,

I concur: the most reasonable course of action would be to remove the 
package(s) [1] [2] [3] from Debian. My availability and skills for working on 
the packages is at the same level or lower than at the time of the RFH, and the 
amount of effort has increased since then.

Best,

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008625
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008627
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008626
---
Diego M. Rodriguez



Bug#1061330: calamares: identified for time_t transition but no ABI in shlibs

2024-01-22 Thread Steve Langasek
Package: calamares
Version: 3.3.0-1
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t

Hi Jonathan,

Analysis of the archive for the 64-bit time_t transition[0][1] identifies
calamares as a package shipping a library whose ABI changes on 32-bit
architectures with 64-bit time_t.

However, calamares's shlibs file declares a dependency on a library package
name that contains no ABI information:

$ cat DEBIAN/shlibs
libcalamares 3.3 calamares (>= 3.3.0)
libcalamaresui 3.3 calamares (>= 3.3.0)
$

It is therefore not obvious that we should rename the package to
'calamares-t64' as part of this transition.

Looking at the archive, there are packages built from separate source
packages, 'calamares-extensions' and 'calamares-settings-mobian', which
depend on this library.

Since there is no self-evident thing to do with the library package name
here, we will not be handling this package as part of the mass NMUs. 
Instead I am filing a serious bug because partial upgrades from bookworm to
trixie on 32-bit architectures (upgrading calamares without also upgrading
worker) will result in ABI skew and may result in broken behavior.

However, since calamares is an installer, maybe upgrades are a non-issue and
all you need is to ensure rebuilds of the three packages in unstable.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[0] https://wiki.debian.org/ReleaseGoals/64bit-time
[1] https://lists.debian.org/debian-devel/2024/01/msg00041.html


signature.asc
Description: PGP signature


Bug#1061298: u-boot: refresh patches

2024-01-22 Thread Vagrant Cascadian
On 2024-01-22, Лухнов Андрей Олегович wrote:
> I've quilt-refreshed patches in u-boot 2024.01+dfsg-1 to apply them
> without fuzzyness.
>
> Please find, ahem, a patch for that attached. :) (I'm not sure, if it
> is a correct method to propose a fix, though, or you could just run
> quilt refresh yourself)

Since the patches apply with "quilt push --fuzz=0 -a" I do not think
this is currently needed.

Is there something I am missing?

live well,
  vagrant


signature.asc
Description: PGP signature


Bug#1061300: lcm: Update to version 1.5.0

2024-01-22 Thread Vagrant Cascadian
On 2024-01-22, Jose Luis Rivero wrote:
> lcm upstream released the version 1.5.0 on April 2023. It would be great to
> have it packaged and available on Debian Sid.
>
> I canhelp with code changes if the maintainer or the team are willing to
> sponsor and review them.

Well the "team" is the Debian QA Group, which effectively means it needs
an actual maintainer:

  https://bugs.debian.org/965945

On the positive side, any Debian Developer can make changes to the
package, so your pool of potential sponsors is quite large!

If you want to prepare an upload for someone to sponsor, this has some
helpful information and infrastructure:

  https://mentors.debian.net/

live well,
  vagrant


signature.asc
Description: PGP signature


Bug#1061329: /usr/bin/futility: "FATAL: do_vbutil_kernel: Error reading bootloader file." when --bootloader points to empty file

2024-01-22 Thread наб
Package: vboot-kernel-utils
Version: 0~R106-15054.B-1
Severity: normal
File: /usr/bin/futility

Dear Maintainer,

# vbutil_kernel --pack /dev/mmcblk1p9 --keyblock 
/usr/share/vboot/devkeys/kernel.keyblock --signprivate 
/usr/share/vboot/devkeys/kernel_data_key.vbprivk --version 1 --vmlinuz 
/media/new+pstored+sysrq.dtb --bootloader /dev/null --config cmdline3 --arch 
arm64
FATAL: do_vbutil_kernel: Error reading bootloader file.

The same happens when you
  # > b
  # ... --bootloader b ...
and you need to printf '\0' > b for vbutil_kernel to accept it.

This appears to be a fake restrixion ‒
AFAICT the boot bundles on my chromebook are all-zero anyway,
and booting with the single-NUL-byte bootloader works.

So the --bootloader option should be optional,
or it should correctly accept empty files.

Best,
наб

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.6.9-amd64 (SMP w/2 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: sysvinit (via /sbin/init)

Versions of packages vboot-kernel-utils depends on:
ii  coreboot-utils  4.15~dfsg-4
ii  flashrom1.3.0-2.1+b1
ii  libc6   2.37-13
ii  libflashrom11.3.0-2.1+b1
ii  libssl3 3.1.4-2

vboot-kernel-utils recommends no packages.

vboot-kernel-utils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature


Bug#1061258: rpm: enable read-only BerkeleyDB backend for bookworm?

2024-01-22 Thread Holger Levsen
Hi Peter,

On Mon, Jan 22, 2024 at 07:49:53PM +0200, Peter Pentchev wrote:
> Yes, I did fully intend to submit it for stable-updates after it had
> spent a couple of days in unstable and possibly migrated to
> testing. Thanks, though - for all you knew, I had not even
> considered it, so thanks for the reminder, 

awesome, thanks already! And please do reach out if you need any help
with that!

> and thanks for all
> your work on Debian.

uhm, thanks, *blushes*. :)


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

No mas pobres en un pais rico!


signature.asc
Description: PGP signature


Bug#1061328: RFP: wireviz -- Easily document cables and wiring harnesses.

2024-01-22 Thread Matthias Geiger
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: pkg-electronics-de...@alioth-lists.debian.net, 
werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: wireviz
  Version : 0.3.2
  Upstream Contact: Andreas Motl 
* URL : https://github.com/wireviz/WireViz
* License : GPL-3
  Programming Lang: Python
  Description : Easily document cables and wiring harnesses.

WireViz is a tool for easily documenting cables, wiring harnesses and connector 
pinouts. 
It takes plain text, YAML-formatted files as input and produces beautiful
graphical output (SVG, PNG, ...) thanks to GraphViz. It handles automatic 
BOM (Bill of Materials) creation and has a lot of extra features.

This seems like a nice addition to debian, all dependencies are already
present.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmWuvR0VHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1M+kP/i7XDqLuiwZ0w1Mvn26ITZ2/bfGw
BCSDuqqSGZDiz/cqKuodnG79vSBQqVZlQNtWJw/v4ug8aMPX0K7P75KfWo6jB8Hg
gXBOl/qxRZthJmip00Jce8BqUqilbmr6/yH7Uh5hMpDsxJoWoLBCgecI56eCB+0b
zaqySraJv5+qvbdDoTzh2egy1ztmoQK53RGN+b9EGdLRwYJ9lyIQySXI/H7k/qqc
25O1JAtSAO54hnPH5dd1224TB+eEasjJnKI+jfU0SUyujj7xSrYgE+95frwP7BTa
fZjjMz3DGtB4iI6HbrtwwjoC6U3IZkUqCFXOSPbmlnVA3Imsysa7iHi10JHIfUAB
9N660vh2zUgR4Zm3MC5HoMPr3+PtTCajJJ9O/arIREW0WLfdDaiqrsS5dbScM/I3
NWjBHYqNrnjokZW3XFGuprdtphs8LOquIoZAI7sP6juM0rdz72+6ue0zm6PARU81
gYkR8gkJrS+UTnY0wNUILc0qG+T2mIvtQdItgdvESlp7vvKKNKtTKcycqHeJ2dMF
mtrmLc95wjGilMx71jCbYCufIoefZSFqf60fOTIEq59nWCO2FIaA+/J4BGttpiKV
52woFxm8IFEYc0xRFwwyemhexiUa1QrRlow7t6dzPp43J+P5PnNDRPsswO0xfy2B
pWZTO3UnTFHd4D8c
=cuHv
-END PGP SIGNATURE-



Bug#1001105: RFP: pyvista -- 3D plotting and mesh analysis

2024-01-22 Thread Diego M. Rodriguez
Control: retitle 1001105 RFP: pyvista -- 3D plotting and mesh analysis
Control: noowner 1001105

Hello,

regrettably, I'm no longer able / interested in packaging this software. I'm 
attempting to officially signal it by removing my ownership, in the hopes it 
can be picked up by other contributor (specially in light of the recent 
blocking dependency from python-scooby).

Best, and thanks Drew for the collaboration that led to the initial ITP,
---
Diego M. Rodriguez



Bug#995581: ITP: python-oauthenticator -- OAuth authenticator for JupyterHub

2024-01-22 Thread Diego M. Rodriguez
Control: noowner 995581
Control: close 995581

Hello,

I am no longer interested in packaging this module. 

Best,
---
Diego M. Rodriguez



Bug#1059891: linux-image-6.1.0-17-amd64: netfilter (nftables) breaks since bookworm

2024-01-22 Thread Daniel Haryo Sugondo

Hi,

do you have some new status to this behaviour?

regards,

Daniel.

On 1/8/24 23:08, Daniel Haryo Sugondo wrote:

Hi,

thank you for your answer.

On 1/5/24 20:18, Salvatore Bonaccorso wrote:

Control: tags -1 + moreinfo

On Wed, Jan 03, 2024 at 07:35:23AM +0100, Daniel Haryo Sugondo wrote:

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

Dear Maintainer,

since Debian 12 (Bookworm) the nft with named set ends with kernel 
trace and the

nft stalled (D)
# ps aux
root   82373  0.0  0.0  0 0 ?    D    Jan02   0:00 [nft]

The message looks like:
[ 3566.525419] [ cut here ]
[ 3566.525424] kernel BUG at mm/slub.c:419!
[ 3566.529834] invalid opcode:  [#1] PREEMPT SMP PTI
[ 3566.535474] CPU: 19 PID: 8146 Comm: kworker/19:0 Not tainted 
6.1.0-17-amd64 #1  Debian 6.1.69-1

[ 3566.545182] Hardware name:  /0X3D66, BIOS 2.2.2 01/16/2014
[ 3566.551304] Workqueue: events nf_tables_trans_destroy_work 
[nf_tables]

[ 3566.558609] RIP: 0010:__slab_free+0x118/0x2d0
[ 3566.563474] Code: 74 35 49 8b 06 48 89 4c 24 20 48 c1 e8 36 4c 8b 
a4 c3 d8 00 00 00 4c 89 e7 e8 74 6a 71 00 48 8b 4c 24 20 48 89 44 24 
18 eb 8f <0f> 0b f7 43 08 00 0d 21 00 75 cd eb c6 80 4c 24 53 80 e9 
75 ff ff

[ 3566.584431] RSP: 0018:a76066effdb0 EFLAGS: 00010246
[ 3566.590262] RAX: 95430ba21930 RBX: 952b80043300 RCX: 
802a001a
[ 3566.598223] RDX: a76066effdd8 RSI: eed9a22e8840 RDI: 
a76066effe18
[ 3566.606189] RBP: 95430ba21900 R08: 0001 R09: 
c0d89ecc
[ 3566.614152] R10: 0013 R11: 0001 R12: 
a76066effe50
[ 3566.622114] R13: 95430ba21900 R14: eed9a22e8840 R15: 
95430ba21900
[ 3566.630079] FS:  () GS:955a9fa4() 
knlGS:

[ 3566.639107] CS:  0010 DS:  ES:  CR0: 80050033
[ 3566.645518] CR2: 7f255e9eb3d8 CR3: 002a6d410006 CR4: 
001706e0

[ 3566.653479] Call Trace:
[ 3566.656210]  
[ 3566.658552]  ? __die_body.cold+0x1a/0x1f
[ 3566.662928]  ? die+0x2a/0x50
[ 3566.666144]  ? do_trap+0xc5/0x110
[ 3566.669848]  ? __slab_free+0x118/0x2d0
[ 3566.674029]  ? do_error_trap+0x6a/0x90
[ 3566.678211]  ? __slab_free+0x118/0x2d0
[ 3566.682393]  ? exc_invalid_op+0x4c/0x60
[ 3566.686676]  ? __slab_free+0x118/0x2d0
[ 3566.690857]  ? asm_exc_invalid_op+0x16/0x20
[ 3566.695529]  ? nf_tables_trans_destroy_work+0x1cc/0x250 [nf_tables]
[ 3566.702532]  ? __slab_free+0x118/0x2d0
[ 3566.706714]  ? obj_cgroup_uncharge_pages+0xd0/0xd0
[ 3566.712066]  nf_tables_trans_destroy_work+0x1cc/0x250 [nf_tables]
[ 3566.718874]  process_one_work+0x1c7/0x380
[ 3566.723351]  worker_thread+0x4d/0x380
[ 3566.727436]  ? rescuer_thread+0x3a0/0x3a0
[ 3566.731908]  kthread+0xda/0x100
[ 3566.735417]  ? kthread_complete_and_exit+0x20/0x20
[ 3566.740763]  ret_from_fork+0x22/0x30
[ 3566.744759]  
[ 3566.747195] Modules linked in: xt_conntrack xt_MASQUERADE 
nf_conntrack_netlink xfrm_user xfrm_algo xt_addrtype nft_compat 
br_netfilter bridge 8021q garp stp mrp llc overlay bonding tls 
nft_nat nft_chain_nat nf_nat nft_log qrtr nft_limit nft_ct 
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c 
nfnetlink_log nfnetlink binfmt_misc intel_rapl_msr intel_rapl_common 
sb_edac x86_pkg_temp_thermal intel_powerclamp nls_ascii nls_cp437 
coretemp kvm_intel vfat fat kvm ipmi_ssif irqbypass 
ghash_clmulni_intel sha512_ssse3 sha512_generic sha256_ssse3 
sha1_ssse3 aesni_intel crypto_simd cryptd ipmi_si iTCO_wdt rapl 
intel_pmc_bxt ipmi_devintf joydev intel_cstate iTCO_vendor_support 
ipmi_msghandler sg acpi_power_meter watchdog intel_uncore mei_me mei 
pcspkr evdev parport_pc ppdev lp parport efi_pstore dm_mod fuse loop 
configfs efivarfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 
crc32c_generic hid_generic usbhid hid sr_mod cdrom sd_mod t10_pi 
crc64_rocksoft crc64 crc_t10dif
[ 3566.747268]  crct10dif_generic mgag200 i2c_algo_bit 
drm_shmem_helper ahci drm_kms_helper libahci ehci_pci ehci_hcd libata 
crct10dif_pclmul megaraid_sas drm crct10dif_common crc32_pclmul 
crc32c_intel usbcore tg3 scsi_mod lpc_ich libphy usb_common 
scsi_common wmi button

[ 3566.870202] ---[ end trace  ]---
[ 3566.878075] RIP: 0010:__slab_free+0x118/0x2d0
[ 3566.882954] Code: 74 35 49 8b 06 48 89 4c 24 20 48 c1 e8 36 4c 8b 
a4 c3 d8 00 00 00 4c 89 e7 e8 74 6a 71 00 48 8b 4c 24 20 48 89 44 24 
18 eb 8f <0f> 0b f7 43 08 00 0d 21 00 75 cd eb c6 80 4c 24 53 80 e9 
75 ff ff

[ 3566.903925] RSP: 0018:a76066effdb0 EFLAGS: 00010246
[ 3566.909772] RAX: 95430ba21930 RBX: 952b80043300 RCX: 
802a001a
[ 3566.917752] RDX: a76066effdd8 RSI: eed9a22e8840 RDI: 
a76066effe18
[ 3566.925747] RBP: 95430ba21900 R08: 0001 R09: 
c0d89ecc
[ 3566.933714] R10: 0013 R11: 0001 R12: 
a76066effe50
[ 3566.941694] R13: 95430ba21900 R14: eed9a22e8840 R15: 
95430ba21900
[ 3566.949670] FS:  () 

Bug#1061282: Possible fix

2024-01-22 Thread Daniel Suchy

It seem upstream already fixed this issue in 3.24.40-2:

https://gitlab.gnome.org/GNOME/gtk/-/issues/6349

- Daniel



Bug#1060711: python3-wxgtk4.0: Library dependency too lenient

2024-01-22 Thread Matthias Urlichs

On 22.01.24 18:54, Scott Talbert wrote:
I'll try to find a way to tighten wxPython's dependency on be >= the 
wxWidgets it was compiled with.


Thanks, that's all I'm asking for.

--
-- Matthias Urlichs



Bug#1060711: python3-wxgtk4.0: Library dependency too lenient

2024-01-22 Thread Matthias Urlichs

On 17.01.24 15:01, Scott Talbert wrote:

On Wed, 17 Jan 2024, Matthias Urlichs wrote:


On 16.01.24 23:58, Scott Talbert wrote:
Do I understand correctly that you installed the python3-wxgtk4.0 
4.2.1+dfsg-3
binary package from Debian Testing into a Debian 12 system and 
that's how you encountered this error? 


Yes. So? Mix+match from stable+testing is rather common when you're 
developing stuff, and Policy 3.5 doesn't say "umm well that only 
applies for dependencies from the same release".


Sorry, but that's not generally supported, at least for wxWidgets 
related packages.  Sometimes we change compile options and other 
things that change the ABI.



I noticed …

However, perhaps you misunderstood. I'm not asking for "support mix and 
match of wx*-related packages". I'm asking for "support mix+match 
between releases; if and when that doesn't work, please set the 
dependencies so that the user can't install a mix-and-match system in 
the first place".


See also: https://lists.debian.org/debian-devel/2024/01/msg00266.html — 
NB, please disregard my snarky "go away" pseudo-quote there. That was 
not intended to reflect your reply here.


--
-- Matthias Urlichs



Bug#1061282: libgtk-3-0: gtk crashes (during suspend)

2024-01-22 Thread Daniel Suchy

Hello,
I noticed similar issue (during laptop suspends) with 3.24.40-1.
Downgrade to 3.24.39-2 is working workaround in my env.

- Daniel[67857.127107] xfwm4[47880]: segfault at 56255d5ab189 ip 7fadf0e074fc sp 
7ffd547b39e0 error 4 in libglib-2.0.so.0.7800.3[7fadf0daa000+99000] likely 
on CPU 9 (core 17, socket 0)
[67857.127131] Code: 89 fd 53 48 89 f3 48 83 ec 08 4c 8b 2d 7d 8a 0c 00 eb 10 
0f 1f 00 48 89 ee e8 20 5e fe ff 48 85 db 74 29 41 8b 45 00 48 89 df <4a> 8b 1c 
23 85 c0 74 e4 31 f6 48 89 ea e8 c2 2b fa ff 48 89 ee 48
[67857.127475] panel-6-systray[48004]: segfault at 5621b123af81 ip 
7f883c4d44fc sp 7ffede13c8d0 error 4 in 
libglib-2.0.so.0.7800.3[7f883c477000+99000] likely on CPU 9 (core 17, socket 0)
[67857.127492] Code: 89 fd 53 48 89 f3 48 83 ec 08 4c 8b 2d 7d 8a 0c 00 eb 10 
0f 1f 00 48 89 ee e8 20 5e fe ff 48 85 db 74 29 41 8b 45 00 48 89 df <4a> 8b 1c 
23 85 c0 74 e4 31 f6 48 89 ea e8 c2 2b fa ff 48 89 ee 48
[67857.127583] xfce4-notifyd[48034]: segfault at 7f2ad1e12b07 ip 
7f2fc8e034fc sp 7ffc5a4d7760 error 4 in 
libglib-2.0.so.0.7800.3[7f2fc8da6000+99000] likely on CPU 10 (core 18, socket 0)
[67857.127614] Code: 89 fd 53 48 89 f3 48 83 ec 08 4c 8b 2d 7d 8a 0c 00 eb 10 
0f 1f 00 48 89 ee e8 20 5e fe ff 48 85 db 74 29 41 8b 45 00 48 89 df <4a> 8b 1c 
23 85 c0 74 e4 31 f6 48 89 ea e8 c2 2b fa ff 48 89 ee 48
[67857.128062] xfdesktop[47999]: segfault at 555290ae2640 ip 7f368a7744fc 
sp 7ffc5d3909c0 error 4 in libglib-2.0.so.0.7800.3[7f368a717000+99000] 
likely on CPU 9 (core 17, socket 0)
[67857.128079] Code: 89 fd 53 48 89 f3 48 83 ec 08 4c 8b 2d 7d 8a 0c 00 eb 10 
0f 1f 00 48 89 ee e8 20 5e fe ff 48 85 db 74 29 41 8b 45 00 48 89 df <4a> 8b 1c 
23 85 c0 74 e4 31 f6 48 89 ea e8 c2 2b fa ff 48 89 ee 48
[67857.128179] xfce4-appfinder[51439]: segfault at 7fed5306fba4 ip 
7fe84ada24fc sp 7ffcce46df50 error 4 in 
libglib-2.0.so.0.7800.3[7fe84ad45000+99000] likely on CPU 9 (core 17, socket 0)
[67857.128192] Code: 89 fd 53 48 89 f3 48 83 ec 08 4c 8b 2d 7d 8a 0c 00 eb 10 
0f 1f 00 48 89 ee e8 20 5e fe ff 48 85 db 74 29 41 8b 45 00 48 89 df <4a> 8b 1c 
23 85 c0 74 e4 31 f6 48 89 ea e8 c2 2b fa ff 48 89 ee 48
[67857.128258] xfce4-session[47790]: segfault at 55ea0f269864 ip 
7fa58d42b4fc sp 7ffc8cfc4af0 error 4 in 
libglib-2.0.so.0.7800.3[7fa58d3ce000+99000] likely on CPU 12 (core 20, socket 0)
[67857.128282] Code: 89 fd 53 48 89 f3 48 83 ec 08 4c 8b 2d 7d 8a 0c 00 eb 10 
0f 1f 00 48 89 ee e8 20 5e fe ff 48 85 db 74 29 41 8b 45 00 48 89 df <4a> 8b 1c 
23 85 c0 74 e4 31 f6 48 89 ea e8 c2 2b fa ff 48 89 ee 48
[67857.128669] panel-12-system[48006]: segfault at 55abb8bb45e7 ip 
7f21f97484fc sp 7ffdc03ba730 error 4 in 
libglib-2.0.so.0.7800.3[7f21f96eb000+99000] likely on CPU 14 (core 22, socket 0)
[67857.128710] Code: 89 fd 53 48 89 f3 48 83 ec 08 4c 8b 2d 7d 8a 0c 00 eb 10 
0f 1f 00 48 89 ee e8 20 5e fe ff 48 85 db 74 29 41 8b 45 00 48 89 df <4a> 8b 1c 
23 85 c0 74 e4 31 f6 48 89 ea e8 c2 2b fa ff 48 89 ee 48
[67857.128741] panel-5-screens[48005]: segfault at 55ffb357894b ip 
7f7623bcd4fc sp 7fff574ea320 error 4 in 
libglib-2.0.so.0.7800.3[7f7623b7+99000] likely on CPU 12 (core 20, socket 0)
[67857.128757] Code: 89 fd 53 48 89 f3 48 83 ec 08 4c 8b 2d 7d 8a 0c 00 eb 10 
0f 1f 00 48 89 ee e8 20 5e fe ff 48 85 db 74 29 41 8b 45 00 48 89 df <4a> 8b 1c 
23 85 c0 74 e4 31 f6 48 89 ea e8 c2 2b fa ff 48 89 ee 48
[67857.128930] panel-10-cpugra[48013]: segfault at 5571bb655bb8 ip 
7fd314d484fc sp 7ffc5c6a86d0 error 4 in 
libglib-2.0.so.0.7800.3[7fd314ceb000+99000] likely on CPU 7 (core 12, socket 0)
[67857.128956] Code: 89 fd 53 48 89 f3 48 83 ec 08 4c 8b 2d 7d 8a 0c 00 eb 10 
0f 1f 00 48 89 ee e8 20 5e fe ff 48 85 db 74 29 41 8b 45 00 48 89 df <4a> 8b 1c 
23 85 c0 74 e4 31 f6 48 89 ea e8 c2 2b fa ff 48 89 ee 48
[67857.130224] panel-2-pulseau[48003]: segfault at 563e57569718 ip 
7fd3a7fe74fc sp 7ffd72ebbd40 error 4 in 
libglib-2.0.so.0.7800.3[7fd3a7f8a000+99000] likely on CPU 0 (core 0, socket 0)
[67857.130252] Code: 89 fd 53 48 89 f3 48 83 ec 08 4c 8b 2d 7d 8a 0c 00 eb 10 
0f 1f 00 48 89 ee e8 20 5e fe ff 48 85 db 74 29 41 8b 45 00 48 89 df <4a> 8b 1c 
23 85 c0 74 e4 31 f6 48 89 ea e8 c2 2b fa ff 48 89 ee 48


Bug#1061258: rpm: enable read-only BerkeleyDB backend for bookworm?

2024-01-22 Thread Peter Pentchev
On Mon, Jan 22, 2024 at 02:36:24PM +, Holger Levsen wrote:
> hi,
> 
> from reading the d/changelog entry "Enable the read-only BerkeleyDB backend.
> Closes: #1061258" it sounds like it should be possible to have this fix
> in bookworm too, via the upcoming point release?!
> 
> I think it would qualify, as it's breaking updating Qubes dom0 via
> a debian based update-vm (see 
> https://github.com/QubesOS/qubes-issues/issues/8482)
> which is a.) an important use-case and b.) a regression compared to bullseye.
> 
> What do you think?

Yes, I did fully intend to submit it for stable-updates after it had
spent a couple of days in unstable and possibly migrated to
testing. Thanks, though - for all you knew, I had not even
considered it, so thanks for the reminder, and thanks for all
your work on Debian.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature


Bug#1056793: Quote variable in cmake file to allow empy values

2024-01-22 Thread Athos Ribeiro

The attached patch should fix the cmake errors Sebastiaan referred to.

--
Athos Ribeiro
Description: Quote variable in cmake file to allow empy values
 Use quotes to allow empty submodules variable during the cmake build
 configuration, fixing a FTBFS issue started in noble.
Author: Athos Ribeiro 
Forwarded: no
Last-Update: 2024-01-20
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/cmake/modules/CTags.cmake
+++ b/cmake/modules/CTags.cmake
@@ -16,10 +16,10 @@
   OUTPUT_VARIABLE submodules
   OUTPUT_STRIP_TRAILING_WHITESPACE)
 if(${result_code} EQUAL 0)
-  string(REPLACE "${TAGS_SRC_DIR}/" "" submodules ${submodules})
+  string(REPLACE "${TAGS_SRC_DIR}/" "" submodules "${submodules}")
   # cmake list uses ";" as the delimiter, so split the string manually
   # before iterating in it.
-  string(REPLACE "\n" ";" submodules ${submodules})
+  string(REPLACE "\n" ";" submodules "${submodules}")
   list(APPEND excludes ${submodules})
 endif()
   endif()


Bug#1060711: python3-wxgtk4.0: Library dependency too lenient

2024-01-22 Thread Scott Talbert

On Mon, 22 Jan 2024, Matthias Urlichs wrote:


On 17.01.24 15:01, Scott Talbert wrote:

On Wed, 17 Jan 2024, Matthias Urlichs wrote:


On 16.01.24 23:58, Scott Talbert wrote:
Do I understand correctly that you installed the python3-wxgtk4.0 
4.2.1+dfsg-3
binary package from Debian Testing into a Debian 12 system and that's how 
you encountered this error? 


Yes. So? Mix+match from stable+testing is rather common when you're 
developing stuff, and Policy 3.5 doesn't say "umm well that only applies 
for dependencies from the same release".


Sorry, but that's not generally supported, at least for wxWidgets related 
packages.  Sometimes we change compile options and other things that change 
the ABI.



I noticed …

However, perhaps you misunderstood. I'm not asking for "support mix and match 
of wx*-related packages". I'm asking for "support mix+match between releases; 
if and when that doesn't work, please set the dependencies so that the user 
can't install a mix-and-match system in the first place".


I didn't misunderstand - you're asking for mis+match of wx-related (to 
include wxWidgets and wxPython) packages between releases, which isn't 
supported.  wxPython is a Python wrapper for wxWidgets, so it is by 
necessity tightly coupled with wxWidgets.  I'll try to find a way to 
tighten wxPython's dependency on be >= the wxWidgets it was compiled with.


See also: https://lists.debian.org/debian-devel/2024/01/msg00266.html — NB, 
please disregard my snarky "go away" pseudo-quote there. That was not 
intended to reflect your reply here.


Yes, I saw that.

Scott

Bug#1006945: please consider supporting wildcards

2024-01-22 Thread Marc Haber
On Fri, Oct 07, 2022 at 09:32:31PM +0200, Niels Thykier wrote:
> I appreciate that it is unwieldly to maintain that links file.  However, I
> also feel like it is a special case that could just as easily be solved by
> having an executable debhelper config file.

I was not aware of that feature. I have done this in adduser now.
Thanks.

Greetings
Marc



Bug#1008625: RFH: qiskit-terra

2024-01-22 Thread Andreas Tille
Hi,

since qiskit-terra has two RC bugs (#1027203 and #1056878 in CC) and
nobody who has expressed any help with this package I wonder whether
we can keep this package in Debian.  I had a look in later upstream
versions but even in 0.13.0 there is a not yet packaged dependency
retworkx[1] which seems to become not used in lates upstream any more
but this becomes quite rust-dependant. So tags later than 0.19.2
need Rust crates.io-index[2] and I personally do not have any experience
with packaging rust.

Given that we have no real capacity to catch up with upstream sensibly
I wonder whether it makes sense to keep this package inside Debian.

I have not analysed the upstream status of qiskit-aer.  If it will
require similar new dependencies I wonder whether we should remove both
packages.  While it seems to be not very hard to fix the RC bugs in both
packages it does not make much sense to fix very outdated software.

What do you think?

Kind regards
Andreas.


[1] https://pypi.org/project/retworkx/
[2] https://github.com/rust-lang/crates.io-index

-- 
http://fam-tille.de



Bug#1061327: libimath-dev: please drop dependency on python3-imath

2024-01-22 Thread Johannes Schauer Marin Rodrigues
Package: libimath-dev
Version: 3.1.9-3
Severity: normal
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

Hi,

five months ago, bug #1050349 was reported due to a missing dependency of
libimath-dev on python3-imath. The bug was resolved by adding that dependency.
Choosing this solution resulted in the following 134 source packages gaining
one additional cross build satisfiability problem because they will attempt to
install the host architecture version of python:

actiona amberol auto-multiple-choice beads blender budgie-control-center
calligra chafa cheese cimg converseen darknet darktable digikam dmtx-utils
drawtiming dvdauthor dx embree enblend-enfuse eviacam exactimage ffcv field3d
freecad freeimage frei0r gegl gem gimp gmic gnome-authenticator
gnome-dvb-daemon gnome-metronome gnome-sound-recorder gnome-subtitles gnunet
gnustep-gui gst-plugins-bad1.0 gstreamer-editing-services1.0 gstreamer-vaapi
gst-rtsp-server1.0 gtk4 hugin imagemagick imview inkscape jmagick jpeg-xl
kimageformats kio-extras krita kxstitch kylin-scanner lebiniou libopenshot
libvigraimpex luminance-hdr megapixels mgba mia mldemos mlt monado mrgingham
mrpt mupen64plus-core nheko nip2 nitrokey-authenticator node-opencv nomacs
nvidia-texture-tools nvidia-vaapi-driver obs-advanced-scene-switcher odr-padenc
olive-editor opencfu opencolorio opencv openexr openexr-viewers openimageio
openvdb os-autoinst osm2pgsql otb otpclient performous pfstools photoqt
php-facedetect php-imagick pink-pony pitivi povray pqiv pragha pstoedit
pulseeffects pythonmagick pytorch pyzbar qimgv rails r-cran-magick
ros-image-pipeline ros-image-transport-plugins ros-opencv-apps
ros-vision-opencv rss-glx ruby-image-processing ruby-rmagick ruby-vips
rust-gstreamer-play rust-gstreamer-play-sys rust-zbar-rust sayonara sight
simple-whip-client siril slic3r-prusa swayimg synfig synfigstudio
ukui-biometric-auth ukui-biometric-manager ukui-control-center ukui-greeter
ukui-screensaver uprightdiff vdr-plugin-skinenigmang vips virtuoso-opensource

To resolve the situation I approached imath upstream in this issue:

https://github.com/AcademySoftwareFoundation/Imath/issues/360

The resulting pull request was since merged into main:

https://github.com/AcademySoftwareFoundation/Imath/pull/361

In this bug I'm asking you to cherry-pick that commit from the upstream main
branch and apply it to the package even before the next upstream release with
that commit in it happens. I attached a debdiff that is doing exactly that for
your convenience.

Doing so will greatly help with maintaining a downstream Debian Pure Blends
that I am maintaining for the MNT Reform open source laptop.  For gstreamer to
do the right thing, we are backporting some patches from gstreamer upstream but
we need to cross-compile it because the MNT Reform is an arm64 laptop and our
build machine is a normal Intel box. With this patch applied, build times get
reduced from 1.5 hours to just under 4 minutes. This is a tremendous help when
developing for that platform as you can probably imagine (and helps reducing
our carbon emissions by a tiny bit).

Note also, that this bug is distinct from #1060843. That bug is about imath
itself failing to cross-build. This bug is about packages that need imath
failing to cross-build.

Thank you for considering!

cheers, josch
diff -Nru imath-3.1.9/debian/changelog imath-3.1.9/debian/changelog
--- imath-3.1.9/debian/changelog2023-09-04 14:11:55.0 +0200
+++ imath-3.1.9/debian/changelog2024-01-22 17:54:01.0 +0100
@@ -1,3 +1,12 @@
+imath (3.1.9-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * cherry-pick upstream commit to prevent reverse B-D of libimath-dev
+from requiring python3-imath being installed
+  * libimath-dev: drop dependency on python3-imath (Closes: #-1)
+
+ -- Johannes Schauer Marin Rodrigues   Mon, 22 Jan 2024 
17:54:01 +0100
+
 imath (3.1.9-3) unstable; urgency=medium
 
   * debian/control: add python3-imath as dep to -dev
diff -Nru imath-3.1.9/debian/control imath-3.1.9/debian/control
--- imath-3.1.9/debian/control  2023-09-04 14:09:31.0 +0200
+++ imath-3.1.9/debian/control  2024-01-22 17:54:01.0 +0100
@@ -47,7 +47,6 @@
 Multi-Arch: same
 Depends:
  libimath-3-1-29 (= ${binary:Version}),
- python3-imath,
  ${misc:Depends},
  ${shlibs:Depends}
 Pre-Depends:
diff -Nru 
imath-3.1.9/debian/patches/0001-src-python-config-ModuleDefine.cmake-do-not-install-.patch
 
imath-3.1.9/debian/patches/0001-src-python-config-ModuleDefine.cmake-do-not-install-.patch
--- 
imath-3.1.9/debian/patches/0001-src-python-config-ModuleDefine.cmake-do-not-install-.patch
  1970-01-01 01:00:00.0 +0100
+++ 
imath-3.1.9/debian/patches/0001-src-python-config-ModuleDefine.cmake-do-not-install-.patch
  2024-01-22 17:48:31.0 +0100
@@ -0,0 +1,29 @@
+From 7d58bb722faccd21d336cd0de52f611bac00a9c5 Mon Sep 17 00:00:00 2001
+From: josch 
+Date: Mon, 22 Jan 2024 00:55:39 +
+Subject: 

Bug#1061326: railway-gtk: Could you add it to bookworm-backports?

2024-01-22 Thread Martin Dosch
Package: railway-gtk
Severity: wishlist

Dear Maintainer,

I would really like to use this program on my travel laptop running 
bookworm. I don't know how difficult it is to backport regarding 
dependencies, but if it would be a low hanging fruit I'd highly 
appreciate if you would provide a backport for bookworm.

Best regards,
Martin

-- 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-17-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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


signature.asc
Description: PGP signature


Bug#1061325: chiaki: Requires libqt5multimedia5-plugins package for sound.

2024-01-22 Thread lolicon0930
Package: chiaki
Version: 2.2.0-1
Severity: normal
X-Debbugs-Cc: lolicon0...@gmail.com

Dear Maintainer,

There is no sound, the solution to the problem is as simple as mentioned in
https://github.com/thestr4ng3r/chiaki/issues/332#issuecomment-712293808, just
install the missing libqt5multimedia5-plugins package.
Is it because the build dependencies were updated last time?

Thanks,

--
lolicon0930


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

Kernel: Linux 6.6.11-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8), 
LANGUAGE=zh_TW:zh
Shell: /bin/sh linked to /usr/bin/lksh
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chiaki depends on:
ii  libavcodec60   10:6.1.1-dmo1
ii  libavutil5810:6.1.1-dmo1
ii  libc6  2.37-13
ii  libgcc-s1  13.2.0-10
ii  libjerasure2   2.0.0+2017.04.10.git.de1739cc84-2
ii  libopus0   1.4-1
ii  libqt5core5a   5.15.10+dfsg-6
ii  libqt5gui5 5.15.10+dfsg-6
ii  libqt5multimedia5  5.15.10-2
ii  libqt5svg5 5.15.10-2
ii  libqt5widgets5 5.15.10+dfsg-6
ii  libsdl2-2.0-0  2.28.5+dfsg-3
ii  libssl33.1.4-2
ii  libstdc++6 13.2.0-10

chiaki recommends no packages.

chiaki suggests no packages.

-- no debconf information



Bug#1061234: po4a: Consider parsing the macros .PS and .PE

2024-01-22 Thread Helge Kreutzmann
Hello Martin,
Am Mon, Jan 22, 2024 at 01:17:11PM +0100 schrieb Martin Quinson:
> how should these macro be considered? Locale::Po4a::Man proposes options to

I'm not into knowledgable of groff, so excuse if I say something
stupid. 

> handle macros that are not known to po4a. For example, if the content of this
> macro should be ignored, try adding "-o untranslated PS,PE" to the command 
> line
> or alias definition in your config file.

No, quite the contrary, the macro should be included, i.e. strings
within should be translatable. Current setup simply ignores them, so
the graphics appears in english.

> Other such options exist, such as translate_joined or translate_each, etc.

I'll check them. I vaguely remember that we tried something many years
back and ran into problems (but did not investigage, because this is
*really low priority).

> > More details and the full discussion (unfortunately with some side
> > discussions) can be found at:
> > https://savannah.gnu.org/bugs/?59962

This explains it much better than I could (except lots of side
discussions).

Greetings

   Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature


Bug#988337: weston: Fails to start with `environment variable XDG_RUNTIME_DIR is not set.`

2024-01-22 Thread Dylan Aïssi
Control: tag -1 wontfix

As explained in the linked upstream bug, this is expected
and marked as "won't fix".

Best,
Dylan



Bug#1061280: sysvinit crashes podman container on install

2024-01-22 Thread Mark Hindley
Sam,

Thanks for this.

A quick look at sysvinit-core postinst reveals:

restart=yes

if ischroot --default-true ; then
restart=no
fi
if [ -n "${DPKG_ROOT:-}" ]; then
restart=no
fi

# If systemd is running, don't restart init or doing any initctl
# migration.
if [ -d "$DPKG_ROOT/run/systemd/system" ]; then
restart=no
fi
if [ "$(uname -s)" = "GNU" ]; then
restart=no
fi

if [ "$restart" = "yes" ]; then
do_restart
else
echo "Not restarting sysvinit"
fi

My initial thought is that restart should really be 'no' if it is a new
sysvinit-core installation. The attached patch fixes sysvinit-core installation
within a podman container for me. I need to do more testing to check that it
doesn't cause breakage elsewhere.

Can you confirm?

Thanks

Mark
>From a14a542cf08db3ef53a154d0366e873375662f4a Mon Sep 17 00:00:00 2001
From: Mark Hindley 
Date: Mon, 22 Jan 2024 16:45:11 +
Subject: [PATCH] d/sysvinit-core.postinst: don't do_restart() for new
 installations.

Closes: #1061280
---
 debian/sysvinit-core.postinst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/sysvinit-core.postinst b/debian/sysvinit-core.postinst
index ecb27a5b..d0ac5841 100755
--- a/debian/sysvinit-core.postinst
+++ b/debian/sysvinit-core.postinst
@@ -112,6 +112,9 @@ fi
 
 restart=yes
 
+if [ -z "${oldver}" ]; then
+restart=no
+fi
 if ischroot --default-true ; then
 	restart=no
 fi
-- 
2.39.2



Bug#1061297: libelogind0: does not implement all ABI required by important packages like procps

2024-01-22 Thread Simon McVittie
On Mon, 22 Jan 2024 at 15:10:14 +, Mark Hindley wrote:
> On Mon, Jan 22, 2024 at 10:47:08AM +, Simon McVittie wrote:
> > Expected result: libelogind0 is a drop-in replacement for libsystemd0 in
> > this scenario,
> 
> This used to be the case, but in sid/trixie to resolve[1] the lag in upstream
> elogind releases[2], we now have a patch for elogind which enables it to use
> libsystemd0 directly[3].  That means that the expected dependencies are now
> 
>  libpam-elogind -> elogind -> libsystemd0
> 
> with procps installable and libelogind0 not installed.
> 
> So, I am curious why libelogind0 was being installed in your VM. Did you 
> request
> it specifically?

I'm not sure what is going on here, to be honest. Perhaps I did install
libelogind0 specifically because that had been necessary in the past?
My sidegrade from systemd to sysvinit went poorly because systemd
(IMO quite reasonably) doesn't want to be removed while it's still
the implementation of the running pid 1, so probably I did a wrong
workaround somewhere.

Retrying this in a fresh VM, with the steps that I should have taken,
if I'd known:

* Start from a virtual machine image produced by autopkgtest-virt-qemu,
  with systemd-sysv (any relatively minimal image would probably be OK)

* apt install sysvinit-core
  (removes libpam-systemd)

* reboot
  (init is now sysvinit)

* apt purge systemd
  (installs systemd-standalone-sysusers instead)

* apt install elogind libpam-elogind

* reboot
  (possibly unnecessary but seems safer)

* apt install xdm xorg openbox
  (This tried to remove sysvinit-core/elogind and reinstate systemd-sysv,
  which would defeat the purpose of this test, so I cancelled.)

* apt install xdm xorg openbox systemd-sysv-
  (This still tried to remove elogind, so I cancelled.)

* apt install xdm xorg openbox systemd-sysv- elogind
  (Success.)

I don't have any particular interest in non-systemd init systems, so you
would know better than me how to proceed from there, and maybe how to make
installing a small graphical desktop less likely to swap back to systemd.

This is prompted by
https://lists.debian.org/debian-devel/2024/01/msg00268.html where a user
seems to be making life hard for themselves by choosing to use a
non-default init system, on a -ports architecture that reached EOL
in 2018 and only exists as a version of unstable, on 20 year old
hardware. unstable can work but should be done with caution because
large chunks of it are sometimes uninstallable; non-default init has
similar caveats; and -ports has similar caveats at the best of times;
so it isn't surprising if combining the three will sometimes propose
removal of important packages.

> Bin:libelogind0 is still built by src:elogind and available in
> the archive. I hesitated to remove it before being certain that the elogind
> cgroups patch to use libsystemd0 was reliable. But maybe libelogind0 should
> become a dependency package to smooth upgrades?

If you are intentionally replacing x by y on all end-user systems that
have it, and y provides all the "API" of x, then I think it's nearly
always correct and necessary for x to become a transitional package that
depends on y. When we try to shortcut around that, the result is frequently
a need to fix it up during the freeze after receiving upgrade reports.

I see that elogind Conflicts with libelogind0. On existing systems with
both elogind and libelogind0, this is going to leave apt taking a guess
at which one is more important to you - keeping elogind, or keeping
libelogind0 - and it will at least sometimes produce the wrong answer
(especially because few packages depend on elogind, but lots of packages
depend on libsystemd0, which on existing elogind-based systems is provided
by libelogind0, so libelogind0 will tend to have a very high "score").

I think this would go better with a transitional package to migrate
to libsystemd. elogind could have a Breaks: libelogind0
(<< first transitional version), or something?

smcv



Bug#1061246: newt FTCBFS: uses the wrong python-config

2024-01-22 Thread Alastair McKinstry

Hi,

Yes, I'm willing to apply this.

Alastair

On 20/01/2024 20:35, Helmut Grohne wrote:

Source: newt
Version: 0.52.24-2
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Tags: patch upstream

Hi,

thanks for quickly fixing the error trapping. newt also fails to cross
build from source, because it fails finding some Python stuff. This is
rooted in Makefile.in hard coding the build architecture python-config,
which works badly when combined with a host architecture compiler.

Fixing this is rather tricky. In principle, we'd want to use
AC_PATH_TOOL to disocver python-config, but it really is
python$ver-config and we cannot loop over all available Python versions
and call AC_PATH_TOOL for each as AC_PATH_TOOL needs to know the program
name at autoconf time rather than at configure time. So what I'm
proposing here is to emulate AC_PATH_TOOL in the Makefile.in by passing
ac_tool_prefix to the Makefile.in and there trying the prefixed
python-config before the plain one. In a cross build, the prefixed one
will be selected and things work. When the prefixed one does is not
exist, it'll fall back to the unprefixed one and work as before.

Is that something you're willing to apply? Do you have other ideas for
solving this?

Helmut


--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie



Bug#1061324: lmdb: Move doxygen to B-D-I

2024-01-22 Thread Scott Kitterman
Source: lmdb
Version: 0.9.31-1
Severity: normal

It looks like doxygen is only needed for building the arch all lmdb-doc
package, so it could be moved from Build-Depends to Build-Depends-Indep.
While this is a pretty minor issue, I think it would be better and it
would at least allow lmdb to be built on archs which don't have doxygen
(currently only hurd-amd64, but it's been others in the past).

Scott K



Bug#1061323: RFP: rust-toml2json -- A very small CLI for converting TOML to JSON

2024-01-22 Thread Matthias Geiger
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-r...@lists.debian.org, brem...@debian.org, 
werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-toml2json
  Version : 1.3.1
  Upstream Contact: woodruffw
* URL : https://github.com/woodruffw/toml2json
* License : MIT
  Programming Lang: Rust
  Description : A very small CLI for converting TOML to JSON

Filing on behalf on bremner. Since src: reserialize provides a toml2json
binary it would have to be renamed. All its dependencies are in debin
so this would be easy to package.

best, 

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmWukBcVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1zdsP/ii5thNVyEgA+guwp9CvVAKJ95a7
AE8qw0SXuCYcIndWpj/qDexXZp03Tg/uAoVp0+6G1NrFxkT7uMq+eTlx7drFc6E/
RVdzhPR+wD+ZQfb30YeWivVAOayITa1ckBRE8nYdjnptEwjSgG4MUlnawPVUhF/Z
8hddtBOdPZKiCyEigWnhmEzb5zb7iPj11LeI/XfAr8WQ/UkuONzH+Gy/6AYmvRPE
lbIP1hL4HdGRCIp41XqjyDvMOakAcLHrlSwrhcHMfMGoRPYLsHbAtAlALbulEjZ4
9u9dcdu7NbARWKmQAIMDOXzXNSizG189pOxj46pnBmiZWiDNTsBKH6ZpBtm+PL+Q
AnXKfMr9jOaHv/wfbjxBlGVKqu1hJxNkAhRuWOfQtmt15DaRpIBPB6yp47fDjXAZ
lehxBS4ptGaqAHTr0mXN3h1wcbAqsK130NhP6ukeZ0l+5tAZMnHwoMFqaJELlLG/
uNhRl/qQ1O5Q+F76bMxu82oWfWxzg5Ln3U34l2K0O2KRCT+NN5KEh+Umm0a6qq9h
9p5PqcldVU6gc9h/hhxqEip88ZUYk/b+wfWBuCAoJPZwN8cbHtP6C8yhSIcYYSWF
Epcj/dl2Hl+V4Kcvsl5pXNuqCnz3n98JA6zFV4v6fKD4SordRar1MLog1OVckObZ
TVGugL7q4xaZkXZV
=u4IJ
-END PGP SIGNATURE-



Bug#1060584: rauc: Please switch Build-Depends to systemd-dev

2024-01-22 Thread Uwe Kleine-König
On Mon, Jan 22, 2024 at 12:37:13PM +0100, Michael Biebl wrote:
> Am 22.01.24 um 12:09 schrieb Uwe Kleine-König:
> > On Thu, Jan 11, 2024 at 11:36:53PM +0100, bi...@debian.org wrote:
> > > Source: rauc
> > > Version: 1.11-1
> > > Severity: normal
> > > User: pkg-systemd-maintain...@lists.alioth.debian.org
> > > Usertags: systemd-dev
> > > 
> > > your package rauc declares a Build-Depends on systemd and/or udev.
> > 
> > Since version 1.10.1-2 rauc build-depends on:
> > 
> > systemd, systemd-dev | systemd (<< 254.1-3~)
> > 
> 
> Is it deliberate, that you kept the Build-Depends on the "full" systemd
> package, i.e. do you need resources from systemd during build other than
> udev.pc/systemd.pc?

I thought there was a reason to keep it. Just dropping systemd doesn't
result in a build problem. I'll have to investigate that.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature


Bug#1061297: libelogind0: does not implement all ABI required by important packages like procps

2024-01-22 Thread Mark Hindley
Simon,

Thanks for this.

On Mon, Jan 22, 2024 at 10:47:08AM +, Simon McVittie wrote:
> Package: libelogind0
> Version: 252.9-1debian3
> Severity: important
> Tags: trixie sid
> 
> Steps to reproduce: attempt to install a Debian unstable virtual machine
> (I used amd64) with sysvinit-core, libpam-elogind, dbus-x11, and a small
> X11 system (I used xdm and openbox).
> 
> Expected result: libelogind0 is a drop-in replacement for libsystemd0 in
> this scenario,

This used to be the case, but in sid/trixie to resolve[1] the lag in upstream
elogind releases[2], we now have a patch for elogind which enables it to use
libsystemd0 directly[3].  That means that the expected dependencies are now

 libpam-elogind -> elogind -> libsystemd0

with procps installable and libelogind0 not installed.

So, I am curious why libelogind0 was being installed in your VM. Did you request
it specifically? Bin:libelogind0 is still built by src:elogind and available in
the archive. I hesitated to remove it before being certain that the elogind
cgroups patch to use libsystemd0 was reliable. But maybe libelogind0 should
become a dependency package to smooth upgrades? Or is there another detail in
the dependency chain I have missed?

Mark



[1]  https://bugs.debian.org/1052064

[2]  Upstream has still not released 254

[3]  
https://git.devuan.org/devuan/elogind/src/branch/debian/debian/patches/Use-libsystemd0-compatible-cgroups-layout.patch



Bug#1061322: avfs: identified for time_t transition but no ABI in shlibs

2024-01-22 Thread Steve Langasek
Package: avfs
Version: 1.1.5-1
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t

Hi Michael,

Analysis of the archive for the 64-bit time_t transition[0][1] identifies
avfs as a package shipping a library whose ABI changes on 32-bit
architectures with 64-bit time_t.

However, avfs's shlibs file declares a dependency on a library package name
that contains no ABI information:

$ cat DEBIAN/shlibs
libavfs 0 avfs (>= 1.1.5)
$

It is therefore not obvious that we should rename the package to 'avfs-t64'
as part of this transition.

Looking at the archive, there is a package built from a separate source
package, 'worker', which depends on this library.

Since there is no self-evident thing to do with the library package name
here, we will not be handling this package as part of the mass NMUs. 
Instead I am filing a serious bug because partial upgrades from bookworm to
trixie on 32-bit architectures (upgrading avfs without also upgrading
worker) will result in ABI skew and may result in broken behavior.

Thanks,
--
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[0] https://wiki.debian.org/ReleaseGoals/64bit-time
[1] https://lists.debian.org/debian-devel/2024/01/msg00041.html


signature.asc
Description: PGP signature


Bug#1061313: macaulay2 ftbfs with Python 3.12 as the default

2024-01-22 Thread Torrance, Douglas

Control: tags -1 confirmed

On Mon 22 Jan 2024 09:22:49 AM -05, Matthias Klose  wrote:

Package: src:macaulay2
Version: 1.22+ds-5
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

with python3-defaults from experimental:

[...]
gcc -std=gnu11 -g -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security
 -fcf-protection 
-fdebug-prefix-map=/<>=/usr/src/macaulay2-1.22+ds-5build1
 -g3 -O2 -Wno-unused -pipe -Wall -Wno-shadow -Wcast-qual 
-Wno-sign-conversion -Wno-sign-compare -Wno-parentheses
 -Wno-sign-compare  -Wuninitialized -Wframe-address -Wstrict-aliasing 
-Wfatal-errors -Wimplicit-function-declaration -Wno-unused-label
 -Wreturn-type -Wunused-function -Wfatal-errors -I. -I. -I./../e 
-I./../system -I./../../include -I./../c -I/<>/M2/include
 -I/<>/M2/include -I/<>/M2/usr-host/include 
-I/<>/M2/include -I/<>/M2/include
 -I/<>/M2/usr-host/include -I/<>/M2/include 
-I/<>/M2/include -I/<>/M2/usr-host/include
 -Wdate-time -D_FORTIFY_SOURCE=3 -isystem /usr/include/libxml2 
-I/usr/include/x86_64-linux-gnu/singular -I/usr/include/singular
 -DSING_NDEBUG -DOM_NDEBUG-I/usr/src/gtest  -Wdate-time 
-D_FORTIFY_SOURCE=3 -DNDEBUG  -I/usr/include/cddlib -I/usr/include/cdd
 -I/usr/include/eigen3  -I/usr/include/python3.12 -I/usr/include 
-DBOOST_STACKTRACE_LINK -isystem /usr/include/libxml2
 -I/usr/include/x86_64-linux-gnu/singular -I/usr/include/singular 
-DSING_NDEBUG -DOM_NDEBUG-I/usr/src/gtest  -Wdate-time

 -D_FORTIFY_SOURCE=3 -DNDEBUG  -I/usr/include/cddlib
-I/usr/include/cdd -I/usr/include/eigen3  -I/usr/include/python3.12
-I/usr/include -DBOOST_STACKTRACE_LINK -isystem /usr/include/libxml2 
-I/usr/include/x86_64-linux-gnu/singular -I/usr/include/singular
 -DSING_NDEBUG -DOM_NDEBUG-I/usr/src/gtest  -Wdate-time 
-D_FORTIFY_SOURCE=3 -DNDEBUG  -I/usr/include/cddlib -I/usr/include/cdd
 -I/usr/include/eigen3  -I/usr/include/python3.12 -I/usr/include 
-DBOOST_STACKTRACE_LINK -DNDEBUG -Wno-unknown-pragmas  -c

 -Wno-unused-value -Wno-unused-but-set-variable
-Wno-maybe-uninitialized util-tmp.c -o util.o
util.d: In function ‘util_getSequenceOfPairsOfSmallIntegers_1’:
util.d:52:12: warning: array subscript ‘struct M2_arrayint_struct[0]’
is partly outside array bounds of ‘unsigned char[4]’ [-Warray-bounds=]
   52 |  is x:Sequence  do getSequenceOfPairsOfSmallIntegers(x)
  |^~
In file included from ./../../include/M2/gc-include.h:44,
 from util-exports.h:6,
 from util-tmp.c:1:
util.d:52:29: note: object of size 4 allocated by ‘GC_malloc_atomic’
   52 |  is x:Sequence  do getSequenceOfPairsOfSmallIntegers(x)
  | ^~~~
util.d: In function ‘util_getSequenceOfSmallIntegers_1’:
util.d:102:19: warning: array subscript ‘struct M2_arrayint_struct[0]’
is partly outside array bounds of ‘unsigned char[4]’ [-Warray-bounds=]
  102 |   anywhereAbort("internal error:
  getSequenceOfSmallIntegers.");
  |   ^~
util.d:102:36: note: object of size 4 allocated by ‘GC_malloc_atomic’
  102 |   anywhereAbort("internal error:
  getSequenceOfSmallIntegers.");
  |^~~~
util.d: In function ‘util_getNullOrSequenceOfSmallIntegers’:
util.d:110:19: warning: array subscript ‘struct M2_arrayint_struct[0]’
is partly outside array bounds of ‘unsigned char[4]’ [-Warray-bounds=]
  110 |   anywhereAbort("internal error:
  getSequenceOfSmallIntegers.");
  |   ^~
util.d:110:36: note: object of size 4 allocated by ‘GC_malloc_atomic’
  110 |   anywhereAbort("internal error:
  getSequenceOfSmallIntegers.");
  |^~~~
util.d: In function ‘util_getSequenceOfStrings’:
util.d:120:12: warning: array subscript ‘struct
M2_ArrayString_struct[0]’ is partly outside array bounds of ‘unsigned 
char[8]’ [-Warray-bounds=]

  120 |  new array(string) len length(s) do (
  |^~
util.d:120:32: note: object of size 8 allocated by ‘GC_malloc’
  120 |  new array(string) len length(s) do (
  |^
util.d: In function ‘util_getSequenceOfRingElements’:
util.d:151:12: warning: array subscript ‘struct
engine_RawRingElementArray_struct[0]’ is partly outside array bounds
of ‘unsigned char[8]’ [-Warray-bounds=]
  151 |  is a:RawRingElementCell do RawRingElementArray(a.p)
  |^~
util.d:151:44: note: object of size 8 allocated by ‘GC_malloc’
  151 |  is a:RawRingElementCell do RawRingElementArray(a.p)
  |^
util.d: In function ‘util_getSequenceOfMatrices’:
util.d:170:13: warning: array subscript ‘struct
engine_RawMatrixArray_struct[0]’ is partly outside array bounds of 
‘unsigned char[8]’ [-Warray-bounds=]

  170 |  is 

Bug#1058590: getent in polkitd.postinst is broken

2024-01-22 Thread Harald Dunkel

On 2024-01-22 12:41:04, Simon McVittie wrote:

On Thu, 14 Dec 2023 at 11:38:16 +0100, Harald Dunkel wrote:

getent queries all databases, as listed in /etc/nsswitch.conf, AFAIU.
I would suggest to use

getent -s files passwd polkitd

to query /etc/passwd only and to ignore remote databases based on LDAP
or NIS or similar. polkitd is supposed to be a local system user.


Wouldn't this break systems where polkitd is a local system user stored
in some backend other than the standard flat files, like libnss-db or
libnss-extrausers?



I can't help it. The getent was just a suggestion. Maybe it would be wise
to ignore all local and remote databases for creating system accounts,
except for the traditional files in /etc?



How is this particular system set up? Is it using a remote user database?



It would be using a remote database (FreeIPA, i.e LDAP), but this is a
chroot. I am updating a clone of the root partition from Debian 11 to
12 to reduce the downtime. /usr/sbin/policy-rc.d is set accordingly.

There is no polkitd account in the remote database, anyway. I checked.


This seems to be consistent with how
/usr/share/debhelper/autoscripts/postinst-sysusers handles sysusers, so
if there is a bug here, it would affect any package that relies on
sysusers.d, not just polkit.


I have updated quite a number of hosts already, but only polkitd postinst
in Debian 12 ran into this problem. The fix is to manually add polkitd
to the local database on the command line (copy and paste from the
postinst script:

adduser --group --system --gecos 'polkit' \
--no-create-home --home /nonexistent polkitd

) and to try again.

Looking at the code

if command -v systemd-sysusers >/dev/null; then
systemd-sysusers ${DPKG_ROOT:+--root="$DPKG_ROOT"} polkitd.conf
else
adduser --group --system --gecos 'polkit' \
--no-create-home --home /nonexistent polkitd
addgroup --system polkitd
fi

I wonder if the systemd case would be executed in a chroot?


Regards

Harri



Bug#1061320: dblatex: FTBFS with Python 3.12

2024-01-22 Thread Graham Inggs
Control: tags -1 + patch

These two patches from Fedora[1] fix the FTBFS:

dblatex-0.3.12-replace-imp-by-importlib.patch
dblatex-0.3.12-adjust-submodule-imports.patch

I attach an additional patch that fixes several instances of
'SyntaxWarning: invalid escape sequence' that may be alarming to
users.


[1] https://src.fedoraproject.org/rpms/dblatex/tree/rawhide
Description: Fix several SyntaxWarnings
 Use raw strings to avoid invalid escape sequence
Author: Graham Inggs 
Last-Update: 2024-01-22

--- a/lib/dbtexmf/dblatex/grubber/texparser.py
+++ b/lib/dbtexmf/dblatex/grubber/texparser.py
@@ -31,7 +31,7 @@
 # Make a "foo|bar\*stub" list
 hooklist = [x.replace("*", "\\*") for x in self.hooks]
 
-pattern = "(?P%s)\*?"\
+pattern = r"(?P%s)\*?"\
   " *(\\[(?P[^\\]]*)\\])?"\
   " *({(?P[^{}]*)}|(?=[^A-Za-z]))"
 
--- a/lib/dbtexmf/dblatex/texcodec.py
+++ b/lib/dbtexmf/dblatex/texcodec.py
@@ -26,7 +26,7 @@
 l.append(unient.unicode_map[ord(c)])
 except KeyError:
 print("Missing character 

Bug#1061321: firmware-nonfree: Important changes coming up with upstream version 20230919

2024-01-22 Thread Diederik de Haas
Source: firmware-nonfree
Version: 20230625-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm currently working on an update for upstream version 20230919, based
upon MR86 (Release 20230804) [1], which itself is based upon MR85
(Update to 20230625) [2] and I'm running into some major issues:

1) Salsa's CI now always fails as the (archive) size is now too big for
   it to handle it.
2) Upstream introduced a new keyword RawFile to 'list files that must
   not be compressed'. I'm guessing one or more script files need to be
   updated for it?
3) Upstream commit a0142c57045701b7557c3060af5c4246c420e4d8 titled
   "ath10k/WCN3990: move wlanmdsp to qcom/sdm845" would mean moving
   entries from ``debian/config/atheros`` to ``debian/config/qcom-soc``
   and adding a 'recommends' field to ``atheros``'s ``defines`` file.
   Which means that qcom-soc recommends atheros and atheros recommends
   qcom-soc. Technically doable, but it raises the question whether this
   separation still makes sense. 

[1] https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/86
[2] https://salsa.debian.org/kernel-team/firmware-nonfree/-/merge_requests/85

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

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

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZa5+3wAKCRDXblvOeH7b
br9tAQCbvKeLqadcQE0fBigvlCW66k55+X76p0gd+R45PUc6ngEAqjJuUSHra5Jd
Liswzmc7gOnYa8DEg4Y2ZXzl8xep0wc=
=33X+
-END PGP SIGNATURE-



Bug#1061320: dblatex: FTBFS with Python 3.12

2024-01-22 Thread Graham Inggs
Source: dblatex
Version: 0.3.12py3-2
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

Hi Maintainer

dblatex FTBFS with Python 3.12.  I've copied what I hope is the
relevant part of the log below.

Regards
Graham


Traceback (most recent call last):
  File "/<>/setup.py", line 498, in 
version=get_version(),
^
  File "/<>/setup.py", line 475, in get_version
from dbtexmf.dblatex import dblatex
  File "/<>/lib/dbtexmf/dblatex/dblatex.py", line 8, in 
from dbtexmf.core.dbtex import DbTex, DbTexCommand
  File "/<>/lib/dbtexmf/core/dbtex.py", line 18, in 
import imp
ModuleNotFoundError: No module named 'imp'



Bug#1061319: cadabra2 ftbfs with Python 3.12 as default

2024-01-22 Thread Matthias Klose

Package: src:cadabra2
Version: 2.4.3.2-1.1
Severity: serious
Tags: sid trixie ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

with python3-defaults from experimental:

there goes something wrong during the configuration, 3.11 is picked up 
instead of 3.12.


Also d/rules reads:
override_dh_auto_install:
dh_auto_install
sed -i s,python3.10,python3,g debian/cadabra2/usr/bin/cadabra2

please don't hardcode the python version.


[...]
---
  Configuring Python
---
-- Building for use with Python 3 (good!)
CMake Deprecation Warning at libs/pybind11/CMakeLists.txt:8 
(cmake_minimum_required):

  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument  value or use a ... suffix to tell
  CMake that the project does not need compatibility with older versions.


-- pybind11 v2.11.0 dev1
CMake Warning (dev) at cmake/modules/FindPythonLibsNew.cmake:60 
(find_package):
  Policy CMP0148 is not set: The FindPythonInterp and FindPythonLibs 
modules

  are removed.  Run "cmake --help-policy CMP0148" for policy details.  Use
  the cmake_policy command to set the policy and suppress this warning.

Call Stack (most recent call first):
  libs/pybind11/tools/pybind11Tools.cmake:50 (find_package)
  libs/pybind11/tools/pybind11Common.cmake:180 (include)
  libs/pybind11/CMakeLists.txt:208 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found PythonInterp: /usr/bin/python3.11 (found version "3.11.7")
-- Found PythonLibs: python3.11
-- Performing Test HAS_FLTO
-- Performing Test HAS_FLTO - Success
-- Found python python3.11
-- Python version is 3.11.
-- Installing Python module in /usr/lib/python3.11/site-packages
-- Python abi name cpython-311-x86_64-linux-gnu



Bug#1061258: rpm: enable read-only BerkeleyDB backend for bookworm?

2024-01-22 Thread Holger Levsen
hi,

from reading the d/changelog entry "Enable the read-only BerkeleyDB backend.
Closes: #1061258" it sounds like it should be possible to have this fix
in bookworm too, via the upcoming point release?!

I think it would qualify, as it's breaking updating Qubes dom0 via
a debian based update-vm (see 
https://github.com/QubesOS/qubes-issues/issues/8482)
which is a.) an important use-case and b.) a regression compared to bullseye.

What do you think?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

„Copyright is for losers ©™“ (Banksy)


signature.asc
Description: PGP signature


  1   2   >