Bug#1062688: libtrace3: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: libtrace3
Version: 3.0.22-0.1
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
libtrace3 as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for libtrace3
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libtrace3-3.0.22/debian/changelog libtrace3-3.0.22/debian/changelog
--- libtrace3-3.0.22/debian/changelog   2022-01-06 16:13:17.0 +
+++ libtrace3-3.0.22/debian/changelog   2024-02-02 18:11:21.0 +
@@ -1,3 +1,10 @@
+libtrace3 (3.0.22-0.2) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Fri, 02 Feb 2024 18:11:21 +
+
 libtrace3 (3.0.22-0.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru libtrace3-3.0.22/debian/control libtrace3-3.0.22/debian/control
--- libtrace3-3.0.22/debian/control 2014-10-23 23:45:43.0 +
+++ libtrace3-3.0.22/debian/control 2024-02-02 18:11:21.0 +
@@ -11,7 +11,7 @@
 Package: libtrace3-dev
 Section: libdevel
 Architecture: any
-Depends: libtrace3 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
+Depends: libtrace3t64 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
 Provides: libtrace-dev
 Conflicts: libtrace-dev
 Description: development headers for the libtrace network processing library
@@ -25,7 +25,10 @@
  libtrace is developed by the WAND Network Research Group at Waikato
  University in New Zealand.
 
-Package: libtrace3
+Package: libtrace3t64
+Provides: ${t64:Provides}
+Replaces: libtrace3
+Breaks: libtrace3 (<< ${source:Version})
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -40,7 +43,7 @@
 Package: libpacketdump3-dev
 Section: libdevel
 Architecture: any
-Depends: libpacketdump3 (= ${binary:Version}), ${misc:Depends},
+Depends: libpacketdump3t64 (= ${binary:Version}), ${misc:Depends},
  ${shlibs:Depends}
 Provides: libpacketdump-dev
 Conflicts: libpacketdump-dev
@@ -55,7 +58,10 @@
  libpacketdump is developed by the WAND Network Research Group at Waikato
  University in New Zealand.
 
-Package: libpacketdump3
+Package: libpacketdump3t64
+Provides: ${t64:Provides}
+Replaces: libpacketdump3
+Breaks: libpacketdump3 (<< ${source:Version})
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -81,7 +87,10 @@
  libtrace is developed by the WAND Network Research Group at Waikato 
  University in New Zealand.
 
-Package: libwandio1
+Package: libwandio1t64
+Provides: ${t64:Provides}
+Replaces: libwandio1
+Breaks: libwandio1 (<< ${source:Version})
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -97,7 +106,7 @@
 Package: libwandio1-dev
 Section: libdevel
 Architecture: any
-Depends: libwandio1 (= ${binary:Version}), ${misc:Depends},
+Depends: libwandio1t64 (= ${binary:Version}), ${misc:Depends},
  ${shlibs:Depends}
 Provides: libwandio-dev
 Conflicts: libwandio-dev
diff -Nru libtrace3-3.0.22/debian/libpacketdump3.dirs 
libtrace3-3.0.22/debian/libpacketdump3.dirs
--- 

Bug#1062687: libtorrent: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: libtorrent
Version: 0.13.8-2
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
libtorrent as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for libtorrent
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libtorrent-0.13.8/debian/changelog libtorrent-0.13.8/debian/changelog
--- libtorrent-0.13.8/debian/changelog  2019-12-29 08:52:29.0 +
+++ libtorrent-0.13.8/debian/changelog  2024-02-02 18:09:42.0 +
@@ -1,3 +1,10 @@
+libtorrent (0.13.8-2.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Fri, 02 Feb 2024 18:09:42 +
+
 libtorrent (0.13.8-2) unstable; urgency=medium
 
   * Update Standards-Version to 4.4.1:
diff -Nru libtorrent-0.13.8/debian/control libtorrent-0.13.8/debian/control
--- libtorrent-0.13.8/debian/control2019-12-29 08:52:29.0 +
+++ libtorrent-0.13.8/debian/control2024-02-02 18:09:42.0 +
@@ -25,7 +25,7 @@
 Multi-Arch: same
 Depends:
  libsigc++-2.0-dev,
- libtorrent21 (= ${binary:Version}),
+ libtorrent21t64 (= ${binary:Version}),
  ${misc:Depends}
 Description: C++ BitTorrent library by Rakshasa (development files)
  LibTorrent is a BitTorrent library written in C++ for *nix. It is
@@ -35,7 +35,10 @@
  This package contains the files needed to compile and link programs
  which use LibTorrent.
 
-Package: libtorrent21
+Package: libtorrent21t64
+Provides: ${t64:Provides}
+Replaces: libtorrent21
+Breaks: libtorrent21 (<< ${source:Version})
 Architecture: any
 Pre-Depends: ${misc:Pre-Depends}
 Multi-Arch: same
diff -Nru libtorrent-0.13.8/debian/libtorrent21.install 
libtorrent-0.13.8/debian/libtorrent21.install
--- libtorrent-0.13.8/debian/libtorrent21.install   2018-06-24 
10:13:00.0 +
+++ libtorrent-0.13.8/debian/libtorrent21.install   1970-01-01 
00:00:00.0 +
@@ -1 +0,0 @@
-usr/lib/*/lib*.so.*
diff -Nru libtorrent-0.13.8/debian/libtorrent21t64.install 
libtorrent-0.13.8/debian/libtorrent21t64.install
--- libtorrent-0.13.8/debian/libtorrent21t64.install1970-01-01 
00:00:00.0 +
+++ libtorrent-0.13.8/debian/libtorrent21t64.install2018-06-24 
10:13:00.0 +
@@ -0,0 +1 @@
+usr/lib/*/lib*.so.*
diff -Nru libtorrent-0.13.8/debian/libtorrent21t64.lintian-overrides 
libtorrent-0.13.8/debian/libtorrent21t64.lintian-overrides
--- libtorrent-0.13.8/debian/libtorrent21t64.lintian-overrides  1970-01-01 
00:00:00.0 +
+++ libtorrent-0.13.8/debian/libtorrent21t64.lintian-overrides  2024-02-02 
18:09:42.0 +
@@ -0,0 +1 @@
+libtorrent21t64: package-name-doesnt-match-sonames libtorrent21

Bug#1062686: bookworm-pu: package libdatetime-timezone-perl/1:2.60-1+2024a

[gregor herrmann]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libdatetime-timezone-p...@packages.debian.org
Control: affects -1 + src:libdatetime-timezone-perl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdatetime-timezone-perl/1:2.60-1+2024a to bookworm.

It contains the data from the Olson DB release 2024a as a new quilt
patch.

Changes in the timezone data, taken from the tzdata upstream release:

Kazakhstan unifies on UTC+5 beginning 2024-03-01.
Palestine springs forward a week later after Ramadan.

Kazakhstan unifies on UTC+5.  This affects Asia/Almaty and
Asia/Qostanay which together represent the eastern portion of the
country that will transition from UTC+6 on 2024-03-01 at 00:00 to
join the western portion.  (Thanks to Zhanbolat Raimbekov.)

Palestine springs forward a week later than previously predicted
in 2024 and 2025.  (Thanks to Heba Hamad.)  Change spring-forward
predictions to the second Saturday after Ramadan, not the first;
this also affects other predictions starting in 2039.

Manually stripped down debdiff attached.

If possible, it would be nice to get this into the upcoming point
release.


Thanks in advance,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmW9MChfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZ2XRAAlXUujeRvDiZm+GNu3uHJMArQLIBRjnLMP6EtWYZJEH+vu2j0TF/G2LUY
phrqe0zpJrZs62ZuX/3OuwWGeZ7lwyllssQl4jdB4l1sYlEoLX9ATJqmvA+otI97
zI21oNafatZTD1O0Fnt5O+WPxGQCfSb4q2hzgxbLG6PrVcp2/gMQAcDNi+s2lWca
6dUnvft6SQVhPIS55sCF+g99B8Lm9FEzPQHyRU9MaegqRbtpDgEQsviO4ZF0/z5U
GFHwMRLYkzXPYnOIlulgL75Jk6W6Qaqapt9T1+dq43XYowF5VzTc0F0OPXHaEmLw
b2AN/lQOrojVf/XcM5ohzO0+AE9lm9bvObVxofJ0tqHQpQJyV3tok5yBUVbe3Ba9
bFZWUyxmfzri7p0AaX2dDYPQJe1cYVS5ts0Nmpr8D13Mr7fpDppDV6+Di4h9wWv0
p44eiSKaiRn95yCmhu9x1JQj4+ENbRWwpZMlpyRql5cTjhQJ+P3L5ha6cWkxdOKI
bTmchUiNO6hZSB6VlA/uWb3TzrmY1CUWkW2HsEt/lka7+5gpRqqwdQaUD0R9PgAc
UKjnea+B6Z2UHHTF0SU0KqDVqgoD7gQk73LUHCnjGCupGVTJEPe4jspflEe2+AH+
brZUTS4ljYmiahNKkU24Q5c1PG3XSN6OBWAkMHtdUtkxe3tnERU=
=DwiJ
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.60/debian/changelog 
libdatetime-timezone-perl-2.60/debian/changelog
--- libdatetime-timezone-perl-2.60/debian/changelog 2023-12-23 
01:27:56.0 +0100
+++ libdatetime-timezone-perl-2.60/debian/changelog 2024-02-02 
18:59:53.0 +0100
@@ -1,3 +1,10 @@
+libdatetime-timezone-perl (1:2.60-1+2024a) bookworm; urgency=medium
+
+  * Update data to Olson database version 2024a.
+This update contains contemporary changes for Kazakhstan and Palestine.
+
+ -- gregor herrmann   Fri, 02 Feb 2024 18:59:53 +0100
+
 libdatetime-timezone-perl (1:2.60-1+2023d) bookworm; urgency=medium
 
   * Update data to Olson database version 2023d.
diff -Nru libdatetime-timezone-perl-2.60/debian/patches/olson-2024a 
libdatetime-timezone-perl-2.60/debian/patches/olson-2024a
--- libdatetime-timezone-perl-2.60/debian/patches/olson-2024a   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.60/debian/patches/olson-2024a   2024-02-02 
18:59:53.0 +0100
@@ -0,0 +1,12415 @@
+Description: Update to Olson DB 2024a
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2024-02-02
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2023d
++# Generated from debian/tzdata/africa.  Olson data version 2024a
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,11 +43,11 @@
+ ],
+ ];
+ 
+-sub olson_version {'2023d'}
++sub olson_version {'2024a'}
+ 
+ sub has_dst_changes {0}
+ 
+-sub _max_year {2033}
++sub _max_year {2034}
+ 
+ sub _new_instance {
+ return shift->_init( @_, spans => $spans );
+--- a/lib/DateTime/TimeZone/Asia/Almaty.pm
 b/lib/DateTime/TimeZone/Asia/Almaty.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/asia.  Olson data version 2023d
++# Generated from debian/tzdata/asia.  Olson data version 2024a
+ #
+ # Do not edit this file directly.
+ #
+@@ -484,20 +484,29 @@
+ ],
+ [
+ 63234849600, #utc_start 2004-10-30 20:00:00 (Sat)
+-DateTime::TimeZone::INFINITY, #  utc_end
++63844912800, #  utc_end 2024-02-29 18:00:00 (Thu)
+ 63234871200, #  local_start 2004-10-31 02:00:00 (Sun)
+-DateTime::TimeZone::INFINITY, #local_end
++63844934400, #local_end 2024-03-01 00:00:00 (Fri)
+ 21600,
+ 0,
+ '+06',
+ ],
++[
++63844912800, #utc_start 2024-02-29 18:00:00 (Thu)
++DateTime::TimeZone::INFINITY, #  utc_end
++63844930800, #  local_start 2024-02-29 23:00:00 (Thu)
++DateTime::TimeZone::INFINITY, #local_end
++18000,
++0,
++'+05',
++

Bug#1062685: bullseye-pu: package libdatetime-timezone-perl/1:2.47-1+2024a

[gregor herrmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libdatetime-timezone-p...@packages.debian.org
Control: affects -1 + src:libdatetime-timezone-perl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded libdatetime-timezone-perl/1:2.47-1+2024a to bullseye.

It contains the data from the Olson DB release 2024a as a new quilt
patch.

Changes in the timezone data, taken from the tzdata upstream release:

Kazakhstan unifies on UTC+5 beginning 2024-03-01.
Palestine springs forward a week later after Ramadan.

Kazakhstan unifies on UTC+5.  This affects Asia/Almaty and
Asia/Qostanay which together represent the eastern portion of the
country that will transition from UTC+6 on 2024-03-01 at 00:00 to
join the western portion.  (Thanks to Zhanbolat Raimbekov.)

Palestine springs forward a week later than previously predicted
in 2024 and 2025.  (Thanks to Heba Hamad.)  Change spring-forward
predictions to the second Saturday after Ramadan, not the first;
this also affects other predictions starting in 2039.

Manually stripped down debdiff attached.

If possible, it would be nice to get this into the upcoming point
release.


Thanks in advance,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmW9MCZfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYHRBAAp/bDs3BJ8P6M1+hAwJnM2SXMsNquJBWVar3SJEaA67wZHFcLgAp6Vx9N
4Fb/iJ4XeLTjZTm9ioU4SW+R4tsc7geg5pnocIJDm8JAB6odk7EZ33QXkXD7lE19
zMl06twBkfGXoOgXWPo89x6SlxIa90w0IOe5+OIZZy11zn1ojJxM13JpVwSj0EiK
g0dzHEdOHToxOjzORpl97p4oBp0qPp9N73Nl2WZhOVTrTEZ5aqahkqXQzHtdzlAE
sMmEoEPLsPwy2hqbdS2b1gv3JOpONmOKMURovX8Tax2sdgAZlB/P6MjjM9p+9ymn
iypiqeT2M6mXACI4SPQqa9ILAKasjA1QSUwoNl5XbJjllkOQybwbL/xp3nfNRGin
OBYvzvdQhgl7n90FsGLCrmVUpiP5wz2yA0RrVdksZ/lsNCannseVf+Gl6YJf+J6F
uWztkiK208ARR8H3LMHUHxR7UKoSzhyeIPIi9OGPGf6vgoQ41HhAZ0aGZ8BBRE9Y
0+cVCJmgqAp2UzRXT3E5g+s7m25H+O/kYK/wNVnlSJnGrY3IUiNs0nuAZYU67L/1
0Hzog6uOdEqRAgR+j+M44OULmjKfg+HwC1Ef3YH5aff4h8O8ZyuP5O/JBTzE8URu
UBvfJjevble5S5vR38DUn9aegi7aC4zbUtadnwK+nt1aBecJTaA=
=G4Mm
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-2.47/debian/changelog 
libdatetime-timezone-perl-2.47/debian/changelog
--- libdatetime-timezone-perl-2.47/debian/changelog 2023-12-23 
01:50:44.0 +0100
+++ libdatetime-timezone-perl-2.47/debian/changelog 2024-02-02 
18:51:35.0 +0100
@@ -1,3 +1,10 @@
+libdatetime-timezone-perl (1:2.47-1+2024a) bullseye; urgency=medium
+
+  * Update data to Olson database version 2024a.
+This update contains contemporary changes for Kazakhstan and Palestine.
+
+ -- gregor herrmann   Fri, 02 Feb 2024 18:51:35 +0100
+
 libdatetime-timezone-perl (1:2.47-1+2023d) bullseye; urgency=medium
 
   * Update data to Olson database version 2023d.
diff -Nru libdatetime-timezone-perl-2.47/debian/patches/olson-2024a 
libdatetime-timezone-perl-2.47/debian/patches/olson-2024a
--- libdatetime-timezone-perl-2.47/debian/patches/olson-2024a   1970-01-01 
01:00:00.0 +0100
+++ libdatetime-timezone-perl-2.47/debian/patches/olson-2024a   2024-02-02 
18:51:35.0 +0100
@@ -0,0 +1,12302 @@
+Description: Update to Olson DB 2024a
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2024-02-02
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2023d
++# Generated from debian/tzdata/africa.  Olson data version 2024a
+ #
+ # Do not edit this file directly.
+ #
+@@ -43,11 +43,11 @@
+ ],
+ ];
+ 
+-sub olson_version {'2023d'}
++sub olson_version {'2024a'}
+ 
+ sub has_dst_changes {0}
+ 
+-sub _max_year {2033}
++sub _max_year {2034}
+ 
+ sub _new_instance {
+ return shift->_init( @_, spans => $spans );
+--- a/lib/DateTime/TimeZone/Asia/Almaty.pm
 b/lib/DateTime/TimeZone/Asia/Almaty.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/asia.  Olson data version 2023d
++# Generated from debian/tzdata/asia.  Olson data version 2024a
+ #
+ # Do not edit this file directly.
+ #
+@@ -484,20 +484,29 @@
+ ],
+ [
+ 63234849600, #utc_start 2004-10-30 20:00:00 (Sat)
+-DateTime::TimeZone::INFINITY, #  utc_end
++63844912800, #  utc_end 2024-02-29 18:00:00 (Thu)
+ 63234871200, #  local_start 2004-10-31 02:00:00 (Sun)
+-DateTime::TimeZone::INFINITY, #local_end
++63844934400, #local_end 2024-03-01 00:00:00 (Fri)
+ 21600,
+ 0,
+ '+06',
+ ],
++[
++63844912800, #utc_start 2024-02-29 18:00:00 (Thu)
++DateTime::TimeZone::INFINITY, #  utc_end
++63844930800, #  local_start 2024-02-29 23:00:00 (Thu)
++DateTime::TimeZone::INFINITY, #local_end
++18000,
++0,
++'+05',
++

Bug#1062684: libtorrent-rasterbar: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: libtorrent-rasterbar
Version: 2.0.9-2
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
libtorrent-rasterbar as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for 
libtorrent-rasterbar
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libtorrent-rasterbar-2.0.9/debian/changelog 
libtorrent-rasterbar-2.0.9/debian/changelog
--- libtorrent-rasterbar-2.0.9/debian/changelog 2023-08-14 05:25:12.0 
+
+++ libtorrent-rasterbar-2.0.9/debian/changelog 2024-02-02 18:00:32.0 
+
@@ -1,3 +1,10 @@
+libtorrent-rasterbar (2.0.9-2.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Fri, 02 Feb 2024 18:00:32 +
+
 libtorrent-rasterbar (2.0.9-2) unstable; urgency=medium
 
   * Fix 'Fails to build source after successful build' (Closes: #1048692)
diff -Nru libtorrent-rasterbar-2.0.9/debian/control 
libtorrent-rasterbar-2.0.9/debian/control
--- libtorrent-rasterbar-2.0.9/debian/control   2022-10-23 15:10:21.0 
+
+++ libtorrent-rasterbar-2.0.9/debian/control   2024-02-02 18:00:32.0 
+
@@ -10,7 +10,10 @@
  libboost-python-dev, libssl-dev, pkg-config, python3-dev, cmake, ninja-build,
  python3-setuptools
 
-Package: libtorrent-rasterbar2.0
+Package: libtorrent-rasterbar2.0t64
+Provides: ${t64:Provides}
+Replaces: libtorrent-rasterbar2.0
+Breaks: libtorrent-rasterbar2.0 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -30,7 +33,7 @@
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Depends: ${misc:Depends}, libtorrent-rasterbar2.0 (= ${binary:Version}), 
libboost-system-dev,
+Depends: ${misc:Depends}, libtorrent-rasterbar2.0t64 (= ${binary:Version}), 
libboost-system-dev,
  libssl-dev, pkg-config
 Suggests: libtorrent-rasterbar-doc
 Description: Development files for libtorrent-rasterbar
diff -Nru libtorrent-rasterbar-2.0.9/debian/libtorrent-rasterbar2.0.install 
libtorrent-rasterbar-2.0.9/debian/libtorrent-rasterbar2.0.install
--- libtorrent-rasterbar-2.0.9/debian/libtorrent-rasterbar2.0.install   
2022-10-23 15:10:14.0 +
+++ libtorrent-rasterbar-2.0.9/debian/libtorrent-rasterbar2.0.install   
1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
-usr/lib/*/lib*.so.*
diff -Nru libtorrent-rasterbar-2.0.9/debian/libtorrent-rasterbar2.0t64.install 
libtorrent-rasterbar-2.0.9/debian/libtorrent-rasterbar2.0t64.install
--- libtorrent-rasterbar-2.0.9/debian/libtorrent-rasterbar2.0t64.install
1970-01-01 00:00:00.0 +
+++ libtorrent-rasterbar-2.0.9/debian/libtorrent-rasterbar2.0t64.install
2022-10-23 15:10:14.0 +
@@ -0,0 +1 @@
+usr/lib/*/lib*.so.*
diff -Nru 
libtorrent-rasterbar-2.0.9/debian/libtorrent-rasterbar2.0t64.lintian-overrides 
libtorrent-rasterbar-2.0.9/debian/libtorrent-rasterbar2.0t64.lintian-overrides
--- 
libtorrent-rasterbar-2.0.9/debian/libtorrent-rasterbar2.0t64.lintian-overrides  
1970-01-01 00:00:00.0 +
+++ 

Bug#1062683: RFS: runit-services/0.7.1 -- UNIX init scheme with service supervision (services)

[Lorenzo]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "runit-services":

 * Package name : runit-services
   Version  : 0.7.1
   Upstream contact : [fill in name and email of upstream]
 * URL  : [fill in URL of upstream's web site]
 * License  : GPL-2.0+, BSD-3-Clause, CC0-1.0, GPL-3+
 * Vcs  :
   https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section
  : admin

The source builds the following binary packages:

  runit-services - UNIX init scheme with service supervision (services)

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

  https://mentors.debian.net/package/runit-services/

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

  dget -x
  
https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.7.1.dsc

Git repo:
  
https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next?ref_type=heads

Changes since the last upload:

 runit-services (0.7.1) experimental; urgency=medium
 .
   * Fix piuparts failure in package removal
  (Closes: #1062682)
   * update years in copyright.in and
  regenerate d/copyright

Regards,
Lorenzo

Bug#1061966: closed by Debian FTP Masters (reply to Steve Langasek ) (Bug#1061966: fixed in audit 1:3.1.2-2.1~exp2)

[Steve Langasek]

Really-really-really

On Fri, Feb 02, 2024 at 09:36:27AM -0800, Steve Langasek wrote:
> Helmut pointed out the preinst.in files didn't actually include the token to
> be substituted, but instead still had the hard-coded architecture path :/
> 
> Attached is the really-really-fixed-this-time NMU patch.
> 
> 
> On Fri, Feb 02, 2024 at 08:56:32AM -0800, Steve Langasek wrote:
> > By happenstance I noticed that I had mindlessly hard-coded the
> > amd64-specific multiarch path into the preinsts.
> > 
> > Please find a really-fixed-this-time NMU patch for experimental.
> > 
> > 
> > On Wed, Jan 31, 2024 at 12:41:48PM -0800, Steve Langasek wrote:
> > > Sorry, and thanks for bearing with me.  Uploaded to experimental again;
> > > updated full NMU debdiff attached.
> > > 
> > > On Wed, Jan 31, 2024 at 09:31:25PM +0100, Helmut Grohne wrote:
> > > > Control: reopen -1
> > > > 
> > > > On Wed, Jan 31, 2024 at 10:12:03AM +, Debian Bug Tracking System 
> > > > wrote:
> > > > > #1061966: file loss due to combining time64 + /usr-move
> > > > > 
> > > > > It has been closed by Debian FTP Masters 
> > > > >  (reply to Steve Langasek 
> > > > > ).
> > > > 
> > > > I fear this is not fixed.
> > > > 
> > > > > /usr/lib/x86_64-linux-gnu/libaudit.so.1 and
> > > > 
> > > > This is fixed.
> > > > 
> > > > > /usr/lib/x86_64-linux-gnu/libaudit.so.1.0.0 have been moved from
> > > > 
> > > > This not.
> > > > 
> > > > > libaudit1 to libaudit1t64 in this upload and these files have formerly
> > > > > been installed below /lib in bookworm. Hence, we are creating exactly
> > > > > the problem that the file move moratorium was meant to prevent.
> > > > > 
> > > > > /usr/lib/x86_64-linux-gnu/libauparse.so.0 and
> > > > 
> > > > This is fixed.
> > > > 
> > > > > /usr/lib/x86_64-linux-gnu/libauparse.so.0.0.0 likewise move from
> > > > 
> > > > This not.
> > > > 
> > > > > libauparse0 to libauparse0t64 and create the same problem.
> > > > > 
> > > > > DEP17 classifies this a P1 and proposed mitigations M7 and M8. In this
> > > > > case, I recommend not exercising Conflicts (M7), because they are 
> > > > > known
> > > > > to be unreliable and libaudit1 is part of the the essential set (login
> > > > > depends on it). Instead, their respective preinst script should create
> > > > > protective diversions
> > > > > 
> > > > > dpkg-divert --package libaudit1t64 --no-rename --divert 
> > > > > /lib/x86_64-linux-gnu/libaudit.so.1.usr-is-merged 
> > > > > /lib/x86_64-linux-gnu/libaudit.so.1
> > > > > 
> > > > > for each of the affected files with their aliased location. In this 
> > > > > case
> > > > > - since we cannot use Conflicts - we cannot get rid of these 
> > > > > diversions
> > > > > in postinst. We already have Breaks: libaudit1 (<< ...), but that 
> > > > > allows
> > > > > concurrent unpack and hence still allows for the file loss scenario. 
> > > > > The
> > > > > diversions should be cleaned up in forky's postinst.
> > > > > 
> > > > > I appreciate another upload of audit to experimental to verify the
> > > > > mitigation.
> > > > 
> > > > Helmut
> > > > 
> > > 
> > > -- 
> > > 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
> > 
> > > diff -Nru audit-3.1.2/debian/changelog audit-3.1.2/debian/changelog
> > > --- audit-3.1.2/debian/changelog  2024-01-24 15:05:18.0 +
> > > +++ audit-3.1.2/debian/changelog  2024-01-31 20:39:17.0 +
> > > @@ -1,3 +1,19 @@
> > > +audit (1:3.1.2-2.1~exp3) experimental; urgency=medium
> > > +
> > > +  * Proper complete fix for usrmerge.  Closes: #1061966.
> > > +
> > > + -- Steve Langasek   Wed, 31 Jan 2024 20:39:17 +
> > > +
> > > +audit (1:3.1.2-2.1~exp2) experimental; urgency=medium
> > > +
> > > +  * Non-maintainer upload.
> > > +  * Rename libraries for 64-bit time_t transition.
> > > +  * Fix uninstallable packages from the previous upload.
> > > +  * Add usrmerge diversions in preinst to protect against file deletion
> > > +due to libraries moving between packages.  Closes: #1061966.
> > > +
> > > + -- Steve Langasek   Wed, 31 Jan 2024 08:49:07 +
> > > +
> > >  audit (1:3.1.2-2) unstable; urgency=medium
> > >  
> > >[ Chris Hofstaedtler ]
> > > diff -Nru audit-3.1.2/debian/control audit-3.1.2/debian/control
> > > --- audit-3.1.2/debian/control2024-01-24 15:05:18.0 +
> > > +++ audit-3.1.2/debian/control2024-01-31 08:49:07.0 +
> > > @@ -26,8 +26,8 @@
> > >  Package: auditd
> > >  Section: admin
> > >  Architecture: linux-any
> > > -Depends: libaudit1 (= ${binary:Version}),
> > > - libauparse0 (= ${binary:Version}),
> > > +Depends: libaudit1t64 (= ${binary:Version}),
> > > + libauparse0t64 (= ${binary:Version}),
> > >   mawk | gawk,

Bug#1061926: Bug#1061966 closed by Debian FTP Masters (reply to Steve Langasek ) (Bug#1061966: fixed in audit 1:3.1.2-2.1~exp2)

[Steve Langasek]

Helmut pointed out the preinst.in files didn't actually include the token to
be substituted, but instead still had the hard-coded architecture path :/

Attached is the really-really-fixed-this-time NMU patch.


On Fri, Feb 02, 2024 at 08:56:32AM -0800, Steve Langasek wrote:
> By happenstance I noticed that I had mindlessly hard-coded the
> amd64-specific multiarch path into the preinsts.
> 
> Please find a really-fixed-this-time NMU patch for experimental.
> 
> 
> On Wed, Jan 31, 2024 at 12:41:48PM -0800, Steve Langasek wrote:
> > Sorry, and thanks for bearing with me.  Uploaded to experimental again;
> > updated full NMU debdiff attached.
> > 
> > On Wed, Jan 31, 2024 at 09:31:25PM +0100, Helmut Grohne wrote:
> > > Control: reopen -1
> > > 
> > > On Wed, Jan 31, 2024 at 10:12:03AM +, Debian Bug Tracking System 
> > > wrote:
> > > > #1061966: file loss due to combining time64 + /usr-move
> > > > 
> > > > It has been closed by Debian FTP Masters 
> > > >  (reply to Steve Langasek 
> > > > ).
> > > 
> > > I fear this is not fixed.
> > > 
> > > > /usr/lib/x86_64-linux-gnu/libaudit.so.1 and
> > > 
> > > This is fixed.
> > > 
> > > > /usr/lib/x86_64-linux-gnu/libaudit.so.1.0.0 have been moved from
> > > 
> > > This not.
> > > 
> > > > libaudit1 to libaudit1t64 in this upload and these files have formerly
> > > > been installed below /lib in bookworm. Hence, we are creating exactly
> > > > the problem that the file move moratorium was meant to prevent.
> > > > 
> > > > /usr/lib/x86_64-linux-gnu/libauparse.so.0 and
> > > 
> > > This is fixed.
> > > 
> > > > /usr/lib/x86_64-linux-gnu/libauparse.so.0.0.0 likewise move from
> > > 
> > > This not.
> > > 
> > > > libauparse0 to libauparse0t64 and create the same problem.
> > > > 
> > > > DEP17 classifies this a P1 and proposed mitigations M7 and M8. In this
> > > > case, I recommend not exercising Conflicts (M7), because they are known
> > > > to be unreliable and libaudit1 is part of the the essential set (login
> > > > depends on it). Instead, their respective preinst script should create
> > > > protective diversions
> > > > 
> > > > dpkg-divert --package libaudit1t64 --no-rename --divert 
> > > > /lib/x86_64-linux-gnu/libaudit.so.1.usr-is-merged 
> > > > /lib/x86_64-linux-gnu/libaudit.so.1
> > > > 
> > > > for each of the affected files with their aliased location. In this case
> > > > - since we cannot use Conflicts - we cannot get rid of these diversions
> > > > in postinst. We already have Breaks: libaudit1 (<< ...), but that allows
> > > > concurrent unpack and hence still allows for the file loss scenario. The
> > > > diversions should be cleaned up in forky's postinst.
> > > > 
> > > > I appreciate another upload of audit to experimental to verify the
> > > > mitigation.
> > > 
> > > Helmut
> > > 
> > 
> > -- 
> > 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
> 
> > diff -Nru audit-3.1.2/debian/changelog audit-3.1.2/debian/changelog
> > --- audit-3.1.2/debian/changelog2024-01-24 15:05:18.0 +
> > +++ audit-3.1.2/debian/changelog2024-01-31 20:39:17.0 +
> > @@ -1,3 +1,19 @@
> > +audit (1:3.1.2-2.1~exp3) experimental; urgency=medium
> > +
> > +  * Proper complete fix for usrmerge.  Closes: #1061966.
> > +
> > + -- Steve Langasek   Wed, 31 Jan 2024 20:39:17 +
> > +
> > +audit (1:3.1.2-2.1~exp2) experimental; urgency=medium
> > +
> > +  * Non-maintainer upload.
> > +  * Rename libraries for 64-bit time_t transition.
> > +  * Fix uninstallable packages from the previous upload.
> > +  * Add usrmerge diversions in preinst to protect against file deletion
> > +due to libraries moving between packages.  Closes: #1061966.
> > +
> > + -- Steve Langasek   Wed, 31 Jan 2024 08:49:07 +
> > +
> >  audit (1:3.1.2-2) unstable; urgency=medium
> >  
> >[ Chris Hofstaedtler ]
> > diff -Nru audit-3.1.2/debian/control audit-3.1.2/debian/control
> > --- audit-3.1.2/debian/control  2024-01-24 15:05:18.0 +
> > +++ audit-3.1.2/debian/control  2024-01-31 08:49:07.0 +
> > @@ -26,8 +26,8 @@
> >  Package: auditd
> >  Section: admin
> >  Architecture: linux-any
> > -Depends: libaudit1 (= ${binary:Version}),
> > - libauparse0 (= ${binary:Version}),
> > +Depends: libaudit1t64 (= ${binary:Version}),
> > + libauparse0t64 (= ${binary:Version}),
> >   mawk | gawk,
> >   ${misc:Depends},
> >   ${shlibs:Depends}
> > @@ -41,29 +41,35 @@
> >   .
> >   Also contains the audit dispatcher "audisp".
> >  
> > -Package: libauparse0
> > +Package: libauparse0t64
> > +Provides: ${t64:Provides}
> > +Replaces: libauparse0
> > +Breaks: libauparse0 (<< ${source:Version})
> >  Architecture: linux-any
> >  Pre-Depends: 

Bug#1062682: runit-services: fails to remove (prerm) (piuparts)

[Lorenzo Puliti]

Package: runit-services
Version: 0.7.0
Severity: important
Tags: patch
X-Debbugs-Cc: plore...@disroot.org

when one wants to remove this package dpkg fails with [1]

  (Reading database ... 5625 files and directories currently installed.)
  Removing runit-services (0.7.0) ...
  cat: /usr/share/runit/sv/acpi-fakekey/.meta/onupgrade: No such file or 
directory
  dpkg: error processing package runit-services (--remove):
   installed runit-services package pre-removal script subprocess returned 
error exit status 1
  dpkg: too many errors, stopping
  Errors were encountered while processing:
   runit-services
  Processing was halted because there were too many errors.
  E: Sub-process /usr/bin/dpkg returned an error code (1)

this affects version of the package that are build with dh_runit>=2.16 
(currently in unstable);
0.5.5 is not affected right now but it could be if a no-change rebuild is 
triggered in unstable
for some reason.

patch:
https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/commit/407919bcf17fd2560f86194badaeced2f528b1af


[1] https://piuparts.debian.org/experimental/fail/runit-services_0.7.0.log


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

Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE
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: runit (via /run/runit.stopit)

Versions of packages runit-services depends on:
ii  runit 2.1.2-57
ii  runit-helper  2.16.2

Versions of packages runit-services recommends:
ii  runit-init  2.1.2-57

Versions of packages runit-services suggests:
ii  socklog  2.1.0+repack-5

-- no debconf information

Bug#1061660: liblwp-protocol-https-perl: Fail to verify certificates

[gregor herrmann]

On Tue, 30 Jan 2024 18:18:59 +0100, Christian Marillat wrote:

> > @@ -96,9 +96,12 @@
> >  if ( $Net::HTTPS::SSL_SOCKET_CLASS->can('start_SSL')) {
> >  *_upgrade_sock = sub {
> > my ($self,$sock,$url) = @_;
> > +# SNI should be passed there only if it is not an IP address.
> > +# Details: 
> > https://github.com/libwww-perl/libwww-perl/issues/449#issuecomment-1896175509
> 
> I had  the idea to read this github issue.

Thanks for your further investigations!
 
> In my case I've a proxy and IPv6 isn't configured so this explain this
> Debian bug and reverting upstream changes in 6.12 is maybe a bad idea.

Ok; so where does this leave us? Do I understand you correctly that
we should not revert the above change, and that the issue is with
your local setup? So should we just close the bug or is there
anything left?


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#1061792: mini-httpd: Update of mini-httpd still breaks default web page if it is not index.html

[Alexandru Mihail]

> Hi,
Hi again,
> Result of my basic tests:
> 
> Update with existing /var/www/html/index.cgi works as expected 
> (index.cgi as default page).
> 
> Install with existing /var/www/html/index.cgi works as expected 
> (index.cgi as default page).
> 
> Install without /var/www/ works as expected (index.html copied, and
> as 
> default page).
> 
> Install with empty /var/www/html/ works as expected (index.html
> copied, 
> and as default page).
> 
> 
> Testing error behaviour:
> 
>  rm -rf /var/www
> 
>  touch /var/www
> 
>  chmod 000 /var/www
> 
>  apt install /tmp/mini-httpd_1.30-8_amd64.deb
> 
> Fails as expected:
> 
>  Setting up mini-httpd (1.30-8) ...
>  mkdir: cannot create directory ‘/var/www’: Not a directory
>  dpkg: error processing package mini-httpd (--configure):
>       installed mini-httpd package post-installation script
> subprocess 
> returned error exit status 1
>  Processing triggers for man-db (2.12.0-3) ...
>  Errors were encountered while processing:
>       mini-httpd
>  E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> postinst checks look sane.
> 
Thanks a lot for your help ! You've sped up this release tremendously
by helping me with testing !
> 
> But while testing, I found an odd little detail:
> 
> mini_httpd is invoked with a repeated -C /etc/mini-httpd.conf, or at 
> least that is what systemd reports.

You're right, I missed that one ! Although you're right, httpd does not
care about duplicated -C call now, it might in the future if getopts in
mini_httpd.c change. It's clearly a bug I missed when I created the
systemd service from scratch. This:
git diff debian/mini-httpd.service
diff --git a/debian/mini-httpd.service b/debian/mini-httpd.service
index 577b72a..916ae65 100644
--- a/debian/mini-httpd.service
+++ b/debian/mini-httpd.service
@@ -6,7 +6,7 @@ After=network.target
 Type=forking
 PIDFile=/run/mini_httpd.pid
 EnvironmentFile=-/etc/default/mini-httpd
-ExecStart=/usr/sbin/mini_httpd -C /etc/mini-httpd.conf $DAEMON_OPTS -i
/run/mini_httpd.pid
+ExecStart=/usr/sbin/mini_httpd $DAEMON_OPTS -i /run/mini_httpd.pid
 
 [Install]
 WantedBy=multi-user.target

fixes it entirely.

On this note, I'm getting close to releasing 1.30-8, this systemd
little fix pushes these changes into "quite important enough to push
into a new release" land.

Thanks for all your help !
You'll automatically get a mail when I push, as your Bug report will
automatically close.

Have a great one,
Alexandru Mihail


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

Bug#1044076: influxdb-python: FTBFS with pandas 2.0

[Andreas Tille]

Hi Rebecca,

I followed your hint "replacing all 3 instances of pandas.util.testing
with pandas.testing" [1] but as you can see in Salsa CI there are
remaining issues[2].  The Python3.12 issues should be fixed meanwhile
in version 5.3.1-5.

Any further hints / patches (preferably pushed to Salsa) would be nice.

Kind regards
Andreas.


[1] 
https://salsa.debian.org/python-team/packages/influxdb-python/-/blob/master/debian/patches/pandas2.0.patch?ref_type=heads
[2] https://salsa.debian.org/python-team/packages/influxdb-python/-/jobs/5239463

-- 
http://fam-tille.de

Bug#1060103: transition: imagemagick7

[Bastien Roucariès]

Le vendredi 2 février 2024, 16:53:10 UTC Sebastian Ramacher a écrit :
> Control: tags -1 moreinfo
> 
> Hi Bastien
> 
> On 2024-01-05 22:35:44 +, Bastien Roucariès wrote:
> > Package: release.debian.org
> > Severity: important
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > X-Debbugs-CC: ftpmas...@debian.org
> > 
> > Imagemagick will need a new major bump
> > 
> > I achieved to get imagemagick 7 build for experimental (it is only on salsa 
> > not
> > uploaded yet).
> > 
> > Every package include a version in the package name (except legacy package 
> > name
> > and perl*) so I plan to do some step by step migration, because it is mainly
> > coinstallable with imagemagick 6.
> 
> Why does this migration require co-instabillity with the old version?
> This makes the transition overly complicated. Do you expect major
> changes required in reverse dependencies of imagemagick's shared
> library?

The problem is not the library but the command line interface that may need 
change.

Librarry will break (I think here about php module that will need a update), 
but it is treatable.

convert6 is not fully compatible with convert7

convert6 will be co installable with convert7 in order to test, and convert 
will be provided by alternative system.

We avoid a flag day, but we need co installable library.

Bastien

> 
> PS: Before the time_t transition is done, we will not process other
> transitions.

Not a problem, but I will like to upload work on experimental in order to test 
other arch than i386/amd64/arm that I could test

Bastien

> 
> Cheers
> 



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

Bug#1062613: librsb: NMU diff for 64-bit time_t transition

[Rafael Laboissière]

Control: tags -1 - upstream

* Steve Langasek  [2024-02-02 08:48]:


On Fri, Feb 02, 2024 at 02:06:38PM +0100, Rafael Laboissière wrote:

Control: tags -1 + upstream


Thanks for this bug report and for the upload to experimental, Steve.   I am 
hereby forwarding your message to the upstream author.


Note that this is an ABI change introduced by a distro-wide change in 
default build flags; there is no action for upstream to take in this 
regards.


Oops, it is true, thanks for this correction.

@Michele: as said, nothing to do on your side !

Best,

Rafael Laboissière

Bug#1061966: closed by Debian FTP Masters (reply to Steve Langasek ) (Bug#1061966: fixed in audit 1:3.1.2-2.1~exp2)

[Steve Langasek]

By happenstance I noticed that I had mindlessly hard-coded the
amd64-specific multiarch path into the preinsts.

Please find a really-fixed-this-time NMU patch for experimental.


On Wed, Jan 31, 2024 at 12:41:48PM -0800, Steve Langasek wrote:
> Sorry, and thanks for bearing with me.  Uploaded to experimental again;
> updated full NMU debdiff attached.
> 
> On Wed, Jan 31, 2024 at 09:31:25PM +0100, Helmut Grohne wrote:
> > Control: reopen -1
> > 
> > On Wed, Jan 31, 2024 at 10:12:03AM +, Debian Bug Tracking System wrote:
> > > #1061966: file loss due to combining time64 + /usr-move
> > > 
> > > It has been closed by Debian FTP Masters 
> > >  (reply to Steve Langasek 
> > > ).
> > 
> > I fear this is not fixed.
> > 
> > > /usr/lib/x86_64-linux-gnu/libaudit.so.1 and
> > 
> > This is fixed.
> > 
> > > /usr/lib/x86_64-linux-gnu/libaudit.so.1.0.0 have been moved from
> > 
> > This not.
> > 
> > > libaudit1 to libaudit1t64 in this upload and these files have formerly
> > > been installed below /lib in bookworm. Hence, we are creating exactly
> > > the problem that the file move moratorium was meant to prevent.
> > > 
> > > /usr/lib/x86_64-linux-gnu/libauparse.so.0 and
> > 
> > This is fixed.
> > 
> > > /usr/lib/x86_64-linux-gnu/libauparse.so.0.0.0 likewise move from
> > 
> > This not.
> > 
> > > libauparse0 to libauparse0t64 and create the same problem.
> > > 
> > > DEP17 classifies this a P1 and proposed mitigations M7 and M8. In this
> > > case, I recommend not exercising Conflicts (M7), because they are known
> > > to be unreliable and libaudit1 is part of the the essential set (login
> > > depends on it). Instead, their respective preinst script should create
> > > protective diversions
> > > 
> > > dpkg-divert --package libaudit1t64 --no-rename --divert 
> > > /lib/x86_64-linux-gnu/libaudit.so.1.usr-is-merged 
> > > /lib/x86_64-linux-gnu/libaudit.so.1
> > > 
> > > for each of the affected files with their aliased location. In this case
> > > - since we cannot use Conflicts - we cannot get rid of these diversions
> > > in postinst. We already have Breaks: libaudit1 (<< ...), but that allows
> > > concurrent unpack and hence still allows for the file loss scenario. The
> > > diversions should be cleaned up in forky's postinst.
> > > 
> > > I appreciate another upload of audit to experimental to verify the
> > > mitigation.
> > 
> > Helmut
> > 
> 
> -- 
> 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

> diff -Nru audit-3.1.2/debian/changelog audit-3.1.2/debian/changelog
> --- audit-3.1.2/debian/changelog  2024-01-24 15:05:18.0 +
> +++ audit-3.1.2/debian/changelog  2024-01-31 20:39:17.0 +
> @@ -1,3 +1,19 @@
> +audit (1:3.1.2-2.1~exp3) experimental; urgency=medium
> +
> +  * Proper complete fix for usrmerge.  Closes: #1061966.
> +
> + -- Steve Langasek   Wed, 31 Jan 2024 20:39:17 +
> +
> +audit (1:3.1.2-2.1~exp2) experimental; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Rename libraries for 64-bit time_t transition.
> +  * Fix uninstallable packages from the previous upload.
> +  * Add usrmerge diversions in preinst to protect against file deletion
> +due to libraries moving between packages.  Closes: #1061966.
> +
> + -- Steve Langasek   Wed, 31 Jan 2024 08:49:07 +
> +
>  audit (1:3.1.2-2) unstable; urgency=medium
>  
>[ Chris Hofstaedtler ]
> diff -Nru audit-3.1.2/debian/control audit-3.1.2/debian/control
> --- audit-3.1.2/debian/control2024-01-24 15:05:18.0 +
> +++ audit-3.1.2/debian/control2024-01-31 08:49:07.0 +
> @@ -26,8 +26,8 @@
>  Package: auditd
>  Section: admin
>  Architecture: linux-any
> -Depends: libaudit1 (= ${binary:Version}),
> - libauparse0 (= ${binary:Version}),
> +Depends: libaudit1t64 (= ${binary:Version}),
> + libauparse0t64 (= ${binary:Version}),
>   mawk | gawk,
>   ${misc:Depends},
>   ${shlibs:Depends}
> @@ -41,29 +41,35 @@
>   .
>   Also contains the audit dispatcher "audisp".
>  
> -Package: libauparse0
> +Package: libauparse0t64
> +Provides: ${t64:Provides}
> +Replaces: libauparse0
> +Breaks: libauparse0 (<< ${source:Version})
>  Architecture: linux-any
>  Pre-Depends: ${misc:Pre-Depends}
> -Depends: libaudit1 (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
> +Depends: libaudit1t64 (= ${binary:Version}), ${misc:Depends}, 
> ${shlibs:Depends}
>  Multi-Arch: same
>  Description: Dynamic library for parsing security auditing
>   The libauparse package contains the dynamic libraries needed for
>   applications to use the audit framework. It is used to monitor systems for
>   security related events.
>   .
> - This package contains the libauparse0 library.
> + This package 

Bug#1062681: macromoleculebuilder: NMU diff for 64-bit time_t transition

[Graham Inggs]

Source: macromoleculebuilder
Version: 4.0.0+dfsg-3
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
macromoleculebuilder as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for 
macromoleculebuilder
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru macromoleculebuilder-4.0.0+dfsg/debian/changelog 
macromoleculebuilder-4.0.0+dfsg/debian/changelog
--- macromoleculebuilder-4.0.0+dfsg/debian/changelog2023-06-23 
05:37:57.0 +
+++ macromoleculebuilder-4.0.0+dfsg/debian/changelog2024-02-02 
16:53:45.0 +
@@ -1,3 +1,10 @@
+macromoleculebuilder (4.0.0+dfsg-3.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Graham Inggs   Fri, 02 Feb 2024 16:53:45 +
+
 macromoleculebuilder (4.0.0+dfsg-3) unstable; urgency=medium
 
   * Fix gemmi 0.6.2 support (Closes: #1037463)
diff -Nru macromoleculebuilder-4.0.0+dfsg/debian/control 
macromoleculebuilder-4.0.0+dfsg/debian/control
--- macromoleculebuilder-4.0.0+dfsg/debian/control  2023-06-23 
05:37:57.0 +
+++ macromoleculebuilder-4.0.0+dfsg/debian/control  2024-02-02 
16:53:45.0 +
@@ -29,7 +29,7 @@
 Architecture: any
 Multi-Arch: same
 Depends:
- libmmb4.0 (= ${binary:Version}),
+ libmmb4.0t64 (= ${binary:Version}),
  ${misc:Depends},
 Breaks:
  libmmblib-dev (<< 4.0.0),
@@ -43,7 +43,10 @@
  .
  This package contains the development files.
 
-Package: libmmb4.0
+Package: libmmb4.0t64
+Provides: ${t64:Provides}
+Replaces: libmmb4.0
+Breaks: libmmb4.0 (<< ${source:Version})
 Section: libs
 Architecture: any
 Multi-Arch: same
diff -Nru macromoleculebuilder-4.0.0+dfsg/debian/libmmb4.0.install 
macromoleculebuilder-4.0.0+dfsg/debian/libmmb4.0.install
--- macromoleculebuilder-4.0.0+dfsg/debian/libmmb4.0.install2023-06-23 
05:37:57.0 +
+++ macromoleculebuilder-4.0.0+dfsg/debian/libmmb4.0.install1970-01-01 
00:00:00.0 +
@@ -1 +0,0 @@
-usr/lib/*/libMMB.so.*
diff -Nru macromoleculebuilder-4.0.0+dfsg/debian/libmmb4.0t64.install 
macromoleculebuilder-4.0.0+dfsg/debian/libmmb4.0t64.install
--- macromoleculebuilder-4.0.0+dfsg/debian/libmmb4.0t64.install 1970-01-01 
00:00:00.0 +
+++ macromoleculebuilder-4.0.0+dfsg/debian/libmmb4.0t64.install 2023-06-23 
05:37:57.0 +
@@ -0,0 +1 @@
+usr/lib/*/libMMB.so.*
diff -Nru macromoleculebuilder-4.0.0+dfsg/debian/libmmb4.0t64.lintian-overrides 
macromoleculebuilder-4.0.0+dfsg/debian/libmmb4.0t64.lintian-overrides
--- macromoleculebuilder-4.0.0+dfsg/debian/libmmb4.0t64.lintian-overrides   
1970-01-01 00:00:00.0 +
+++ macromoleculebuilder-4.0.0+dfsg/debian/libmmb4.0t64.lintian-overrides   
2024-02-02 16:53:45.0 +
@@ -0,0 +1 @@
+libmmb4.0t64: package-name-doesnt-match-sonames libmmb4.0

Bug#1062680: m4api: NMU diff for 64-bit time_t transition

[Graham Inggs]

Source: m4api
Version: 0.3~0.9646fd-2
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
m4api as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for m4api
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru m4api-0.3~0.9646fd/debian/changelog 
m4api-0.3~0.9646fd/debian/changelog
--- m4api-0.3~0.9646fd/debian/changelog 2020-09-28 02:58:56.0 +
+++ m4api-0.3~0.9646fd/debian/changelog 2024-02-02 16:52:41.0 +
@@ -1,3 +1,10 @@
+m4api (0.3~0.9646fd-2.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Graham Inggs   Fri, 02 Feb 2024 16:52:41 +
+
 m4api (0.3~0.9646fd-2) unstable; urgency=medium
 
   * Switch to debhelper compat level 14, which passes options to cmake to
diff -Nru m4api-0.3~0.9646fd/debian/control m4api-0.3~0.9646fd/debian/control
--- m4api-0.3~0.9646fd/debian/control   2020-09-28 02:56:50.0 +
+++ m4api-0.3~0.9646fd/debian/control   2024-02-02 16:52:41.0 +
@@ -15,14 +15,17 @@
 Package: m4api
 Architecture: any
 Multi-Arch: foreign
-Depends: ${misc:Depends}, ${shlibs:Depends}, libm4api0.3
+Depends: ${misc:Depends}, ${shlibs:Depends}, libm4api0.3t64
 Description: access Mini-Box M4-ATX power supplies (utility)
  The m4api is a tool for monitoring and configuring Mini-Box M4-ATX
  power supplies.
  .
  This package provides the m4ctl utility.
 
-Package: libm4api0.3
+Package: libm4api0.3t64
+Provides: ${t64:Provides}
+Replaces: libm4api0.3
+Breaks: libm4api0.3 (<< ${source:Version})
 Architecture: any
 Multi-Arch: allowed
 Section: libs
diff -Nru m4api-0.3~0.9646fd/debian/libm4api0.3.install 
m4api-0.3~0.9646fd/debian/libm4api0.3.install
--- m4api-0.3~0.9646fd/debian/libm4api0.3.install   2020-04-14 
02:43:43.0 +
+++ m4api-0.3~0.9646fd/debian/libm4api0.3.install   1970-01-01 
00:00:00.0 +
@@ -1,6 +0,0 @@
-#!/bin/sh
-
-cat << EOF
-/usr/include/* /usr/include/${DEB_HOST_MULTIARCH}/
-/usr/lib/* /usr/lib/${DEB_HOST_MULTIARCH}/
-EOF
diff -Nru m4api-0.3~0.9646fd/debian/libm4api0.3.lintian-overrides 
m4api-0.3~0.9646fd/debian/libm4api0.3.lintian-overrides
--- m4api-0.3~0.9646fd/debian/libm4api0.3.lintian-overrides 2020-08-30 
03:28:09.0 +
+++ m4api-0.3~0.9646fd/debian/libm4api0.3.lintian-overrides 1970-01-01 
00:00:00.0 +
@@ -1,2 +0,0 @@
-# This is a small library
-libm4api0.3: link-to-shared-library-in-wrong-package usr/lib/*/libm4api.so.* 
usr/lib/*/libm4api.so
diff -Nru m4api-0.3~0.9646fd/debian/libm4api0.3t64.install 
m4api-0.3~0.9646fd/debian/libm4api0.3t64.install
--- m4api-0.3~0.9646fd/debian/libm4api0.3t64.install1970-01-01 
00:00:00.0 +
+++ m4api-0.3~0.9646fd/debian/libm4api0.3t64.install2020-04-14 
02:43:43.0 +
@@ -0,0 +1,6 @@
+#!/bin/sh
+
+cat << EOF
+/usr/include/* /usr/include/${DEB_HOST_MULTIARCH}/
+/usr/lib/* /usr/lib/${DEB_HOST_MULTIARCH}/
+EOF
diff -Nru m4api-0.3~0.9646fd/debian/libm4api0.3t64.lintian-overrides 
m4api-0.3~0.9646fd/debian/libm4api0.3t64.lintian-overrides
--- 

Bug#1060103: transition: imagemagick7

[Sebastian Ramacher]

Control: tags -1 moreinfo

Hi Bastien

On 2024-01-05 22:35:44 +, Bastien Roucariès wrote:
> Package: release.debian.org
> Severity: important
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-CC: ftpmas...@debian.org
> 
> Imagemagick will need a new major bump
> 
> I achieved to get imagemagick 7 build for experimental (it is only on salsa 
> not
> uploaded yet).
> 
> Every package include a version in the package name (except legacy package 
> name
> and perl*) so I plan to do some step by step migration, because it is mainly
> coinstallable with imagemagick 6.

Why does this migration require co-instabillity with the old version?
This makes the transition overly complicated. Do you expect major
changes required in reverse dependencies of imagemagick's shared
library?

PS: Before the time_t transition is done, we will not process other
transitions.

Cheers
-- 
Sebastian Ramacher

Bug#1062679: lxc: NMU diff for 64-bit time_t transition

[Graham Inggs]

Source: lxc
Version: 1:5.0.3-2
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
lxc as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for lxc
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru lxc-5.0.3/debian/changelog lxc-5.0.3/debian/changelog
--- lxc-5.0.3/debian/changelog  2023-11-30 01:04:13.0 +
+++ lxc-5.0.3/debian/changelog  2024-02-02 16:36:18.0 +
@@ -1,3 +1,10 @@
+lxc (1:5.0.3-2.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Graham Inggs   Fri, 02 Feb 2024 16:36:18 +
+
 lxc (1:5.0.3-2) unstable; urgency=medium
 
   * Switch default branch to debian/sid
diff -Nru lxc-5.0.3/debian/control lxc-5.0.3/debian/control
--- lxc-5.0.3/debian/control2023-11-23 20:52:39.0 +
+++ lxc-5.0.3/debian/control2024-02-02 16:36:17.0 +
@@ -64,7 +64,7 @@
 Section: libdevel
 Architecture: linux-any
 Depends: libcap-dev,
- liblxc1 (= ${binary:Version}),
+ liblxc1t64 (= ${binary:Version}),
  libseccomp-dev [!alpha !ia64 !m68k !sh4 !sparc64],
  libselinux-dev,
  lxc (= ${binary:Version}),
@@ -80,7 +80,7 @@
 
 Package: lxc-tests
 Architecture: linux-any
-Depends: liblxc1 (= ${binary:Version}),
+Depends: liblxc1t64 (= ${binary:Version}),
  lxc (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
@@ -94,7 +94,10 @@
  used for autopkgtest and by some developers. They are not meant to be
  installed on regular user systems.
 
-Package: liblxc1
+Package: liblxc1t64
+Provides: ${t64:Provides}
+Replaces: liblxc1
+Breaks: liblxc1 (<< ${source:Version})
 Section: libs
 Architecture: linux-any
 Multi-Arch: same
@@ -111,7 +114,7 @@
 Package: liblxc-common
 Section: libs
 Architecture: linux-any
-Depends: liblxc1 (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
+Depends: liblxc1t64 (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
 Breaks: lxc (<< 1:4.0.11-1~)
 Replaces: lxc (<< 1:4.0.11-1~)
 Description: Linux Containers userspace tools (library)
diff -Nru lxc-5.0.3/debian/liblxc1.install lxc-5.0.3/debian/liblxc1.install
--- lxc-5.0.3/debian/liblxc1.install2023-08-03 22:55:49.0 +
+++ lxc-5.0.3/debian/liblxc1.install1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
-usr/lib/*/liblxc*.so.*
diff -Nru lxc-5.0.3/debian/liblxc1.symbols lxc-5.0.3/debian/liblxc1.symbols
--- lxc-5.0.3/debian/liblxc1.symbols2023-08-03 22:55:49.0 +
+++ lxc-5.0.3/debian/liblxc1.symbols1970-01-01 00:00:00.0 +
@@ -1,716 +0,0 @@
-liblxc.so.1 liblxc1 #MINVER#
-* Build-Depends-Package: lxc-dev
-#MISSING: 1:4.0.4# __cgfsng_delegate_controllers@Base 1:4.0.2
-#MISSING: 1:4.0.4# __criu_check_feature@Base 1:3.0.2
-#MISSING: 1:4.0.4# __criu_dump@Base 1:3.0.2
-#MISSING: 1:4.0.4# __criu_pre_dump@Base 1:3.0.2
-#MISSING: 1:4.0.4# __criu_restore@Base 1:3.0.2
-#MISSING: 1:4.0.4# __lxc_start@Base 1:3.0.2
-#MISSING: 1:4.0.4# __netlink_recv@Base 1:3.0.2
-#MISSING: 1:4.0.4# __netlink_send@Base 1:3.0.2
-#MISSING: 1:4.0.4# __netlink_transaction@Base 

Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

[Diederik de Haas]

Package: amd64-microcode
Version: 3.20231019.1
Severity: normal
X-Debbugs-Cc: debian-ker...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

While working on a firmware-nonfree update I came across a commit where
a new file was added in a new directory: ``amdtee``:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/amdtee

This is about "AMD Platform Management Framework TA", which seems to be
about AMD CPU features. The first (and only) commit message has this:

```
amd_pmf: Add initial PMF TA for Smart PC Solution Builder

AMD PMF driver loads the PMF TA (Trusted Application) into the AMD
ASP's (AMD Security Processor) TEE (Trusted Execution Environment).
```

Firmware for AMD graphics belongs in firmware-nonfree, but the
``amdtee`` directory seems to fit better in amd64-microcode?

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

Kernel: Linux 6.6.13-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

amd64-microcode depends on no packages.

Versions of packages amd64-microcode recommends:
ii  initramfs-tools  0.142

amd64-microcode suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZb0dXwAKCRDXblvOeH7b
bhbwAQDt0VW65WhlRttuxWFueuSVHvzo/3zN4deCEESRxvVFrAEA+WrBIu/CWSX+
tMw/Lg8VsnRIstVaqZbTMeAyjgv8fQA=
=3uCZ
-END PGP SIGNATURE-

Bug#1062613: librsb: NMU diff for 64-bit time_t transition

[Steve Langasek]

On Fri, Feb 02, 2024 at 02:06:38PM +0100, Rafael Laboissière wrote:
> Control: tags -1 + upstream

> Thanks for this bug report and for the upload to experimental, Steve.   I am
> hereby forwarding your message to the upstream author.

Note that this is an ABI change introduced by a distro-wide change in
default build flags; there is no action for upstream to take in this
regards.

> * Steve Langasek  [2024-02-02 06:09]:
> 
> > Source: librsb
> > Version: 1.3.0.2+dfsg-6
> > Severity: serious
> > Tags: patch pending
> > Justification: library ABI skew on upgrade
> > User: debian-...@lists.debian.org
> > Usertags: time-t
> > 
> > NOTICE: these changes must not be uploaded to unstable yet!
> > 
> > Dear maintainer,
> > 
> > As part of the 64-bit time_t transition required to support 32-bit
> > architectures in 2038 and beyond
> > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> > librsb as a source package shipping runtime libraries whose ABI either
> > is affected by the change in size of time_t, or could not be analyzed
> > via abi-compliance-checker (and therefore to be on the safe side we
> > assume is affected).
> > 
> > To ensure that inconsistent combinations of libraries with their
> > reverse-dependencies are never installed together, it is necessary to
> > have a library transition, which is most easily done by renaming the
> > runtime library package.
> > 
> > Since turning on 64-bit time_t is being handled centrally through a
> > change to the default dpkg-buildflags (https://bugs.debian.org/1037136),
> > it is important that libraries affected by this ABI change all be
> > uploaded close together in time.  Therefore I have prepared a 0-day NMU
> > for librsb which will initially be uploaded to experimental if possible,
> > then to unstable after packages have cleared binary NEW.
> > 
> > Please find the patch for this NMU attached.
> > 
> > If you have any concerns about this patch, please reach out ASAP.
> > Although this package will be uploaded to experimental immediately,
> > there will be a period of several days before we begin uploads to
> > unstable; so if information becomes available that your package should
> > not be included in the transition, there is time for us to amend the
> > planned uploads.
> > 
> > 
> > 
> > -- System Information: Debian Release: trixie/sid  APT prefers unstable
> > APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale:
> > LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell:
> > /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
> 
> > diff -Nru librsb-1.3.0.2+dfsg/debian/.gitignore
> > librsb-1.3.0.2+dfsg/debian/.gitignore ---
> > librsb-1.3.0.2+dfsg/debian/.gitignore   2023-06-13 09:19:25.0
> > + +++ librsb-1.3.0.2+dfsg/debian/.gitignore 1970-01-01
> > 00:00:00.0 + @@ -1,15 +0,0 @@ -/.debhelper/
> > -/*.debhelper.log -/debhelper-build-stamp -/autoreconf.after
> > -/autoreconf.before -/files -/librsb-dev.substvars -/librsb-dev/
> > -/librsb-doc.substvars -/librsb-doc/ -/librsb-tools.substvars
> > -/librsb-tools/ -/librsb0.substvars -/librsb0/ -/tmp/ diff -Nru
> > librsb-1.3.0.2+dfsg/debian/changelog
> > librsb-1.3.0.2+dfsg/debian/changelog ---
> > librsb-1.3.0.2+dfsg/debian/changelog2023-06-13 09:19:25.0 
> > +
> > +++ librsb-1.3.0.2+dfsg/debian/changelog2024-02-02 05:59:18.0
> > + @@ -1,3 +1,10 @@ +librsb (1.3.0.2+dfsg-6.1) experimental;
> > urgency=medium + +  * Non-maintainer upload. +  * Rename libraries for
> > 64-bit time_t transition. + + -- Steve Langasek 
> > Fri, 02 Feb 2024 05:59:18 + + librsb (1.3.0.2+dfsg-6) unstable;
> > urgency=medium
> > 
> >   * Upload to unstable
> > diff -Nru librsb-1.3.0.2+dfsg/debian/control
> > librsb-1.3.0.2+dfsg/debian/control ---
> > librsb-1.3.0.2+dfsg/debian/control  2023-06-13 09:19:25.0 +
> > +++ librsb-1.3.0.2+dfsg/debian/control  2024-02-02 05:59:18.0
> > + @@ -16,7 +16,10 @@ Vcs-Browser:
> > https://salsa.debian.org/science-team/librsb Rules-Requires-Root: no
> > 
> > -Package: librsb0 +Package: librsb0t64 +Provides: ${t64:Provides}
> > +Replaces: librsb0 +Breaks: librsb0 (<< ${source:Version}) Architecture:
> > any Depends: ${shlibs:Depends}, ${misc:Depends} Multi-Arch: same @@
> > -35,7 +38,7 @@ Package: librsb-dev Section: libdevel Architecture: any
> > -Depends: librsb0 (= ${binary:Version}), ${misc:Depends} +Depends:
> > librsb0t64 (= ${binary:Version}), ${misc:Depends} Description:
> > shared-memory Sparse BLAS library using the RSB matrix format
> > (development)  This is a library for sparse matrix computations
> > featuring the Recursive  Sparse Blocks (RSB) matrix format. This format
> > allows cache efficient and @@ -51,7 +54,7 @@
> > 
> > Package: 

Bug#1060103: Remainder of imagemagick7 transition plan

[Bastien Roucariès]

Hi,

A gentle remainder about imagemagick7 transition plan.

Many thanks for santiago to review partially it, but I need green light from 
release team.

Bastien

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

Bug#1062677: lwipv6: NMU diff for 64-bit time_t transition

[Graham Inggs]

Source: lwipv6
Version: 1.5a-9
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
lwipv6 as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for lwipv6
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru lwipv6-1.5a/debian/changelog lwipv6-1.5a/debian/changelog
--- lwipv6-1.5a/debian/changelog2020-11-07 17:12:00.0 +
+++ lwipv6-1.5a/debian/changelog2024-02-02 16:35:02.0 +
@@ -1,3 +1,10 @@
+lwipv6 (1.5a-9.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Graham Inggs   Fri, 02 Feb 2024 16:35:02 +
+
 lwipv6 (1.5a-9) unstable; urgency=medium
 
   * Add missing file libvdeplug_dyn.h (Closes: #973182)
diff -Nru lwipv6-1.5a/debian/control lwipv6-1.5a/debian/control
--- lwipv6-1.5a/debian/control  2020-09-18 16:14:11.0 +
+++ lwipv6-1.5a/debian/control  2024-02-02 16:35:02.0 +
@@ -11,7 +11,7 @@
 Package: liblwipv6-dev
 Section: libdevel
 Architecture: any
-Depends: liblwipv6-2 (= ${binary:Version}), ${misc:Depends}
+Depends: liblwipv6-2t64 (= ${binary:Version}), ${misc:Depends}
 Conflicts: liblwipv6-1-dev
 Replaces: liblwipv6-1-dev
 Description: Development files for the LWIPv6 library
@@ -37,7 +37,10 @@
  This package contains the files needed to compile applications that link
  LWIPv6.
 
-Package: liblwipv6-2
+Package: liblwipv6-2t64
+Provides: ${t64:Provides}
+Replaces: liblwipv6-2
+Breaks: liblwipv6-2 (<< ${source:Version})
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
diff -Nru lwipv6-1.5a/debian/liblwipv6-2.install 
lwipv6-1.5a/debian/liblwipv6-2.install
--- lwipv6-1.5a/debian/liblwipv6-2.install  2020-09-18 10:52:46.0 
+
+++ lwipv6-1.5a/debian/liblwipv6-2.install  1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-debian/tmp/usr/lib/lib*.so.*
diff -Nru lwipv6-1.5a/debian/liblwipv6-2t64.install 
lwipv6-1.5a/debian/liblwipv6-2t64.install
--- lwipv6-1.5a/debian/liblwipv6-2t64.install   1970-01-01 00:00:00.0 
+
+++ lwipv6-1.5a/debian/liblwipv6-2t64.install   2020-09-18 10:52:46.0 
+
@@ -0,0 +1 @@
+debian/tmp/usr/lib/lib*.so.*
diff -Nru lwipv6-1.5a/debian/liblwipv6-2t64.lintian-overrides 
lwipv6-1.5a/debian/liblwipv6-2t64.lintian-overrides
--- lwipv6-1.5a/debian/liblwipv6-2t64.lintian-overrides 1970-01-01 
00:00:00.0 +
+++ lwipv6-1.5a/debian/liblwipv6-2t64.lintian-overrides 2024-02-02 
16:35:02.0 +
@@ -0,0 +1 @@
+liblwipv6-2t64: package-name-doesnt-match-sonames liblwipv6-2

Bug#1062122: Usage information

[Peter Hyman]

Some usage and integration information.

* On KDE, LD_PRELOAD can be set in a file in the 
.config/plasma-workspace/env directory. This will enable libtrash 
throughout the KDE session.


* libtrash is not active in the Dolphin file manager which has its own 
trash can.


* Some user defaults can be set. There are some system defaults and any 
settings in the user directory will override the system defaults. Here 
is what I have in my $HOME/.libtrash file


$cat $HOME/.libtrash

IGNORE_EXTENSIONS = o;log;aux;swp;bak;tmp;vmdk;out;lrz;file;h;lck

- don't preserve files with these extensions.

TEMPORARY_DIRS = /tmp;/var;/share/software/cache;

- ignore these directories and don't preserve files in them

IGNORE_RE = conftest.*;*cache;config.*

- use regular expressions and don't preserve matching files

REMOVABLE_MEDIA_MOUNT_POINTS = /run;/media;/mnt;/dev

- ignore these removable directories

USER_TEMPORARY_DIRS = mnt;tmp;temp

- ignore user-owned temporary directories

PRESERVE_FILES_LARGER_THAN = 1G

- do not preserve files larger than...

Here are the system defaults.

TRASH_CAN = "Trash"

- name of user trash can in $HOME

IN_CASE_OF_FAILURE = PROTECT | ALLOW_DESTRUCTION

- if there is some failure in calling the unlink() or other function, 
preserve the file


SHOULD_WARN = NO

- if libtrash is disabled (i,e, TRASH_OFF=YES) issue a warning on stderr

PROTECT_TRASH = YES

- do not delete files in the user trash can

IGNORE_EXTENSIONS = "o;log;aux"

- (see above)

IGNORE_HIDDEN = YES

- do not preserve hidden files

IGNORE_EDITOR_BACKUP = YES

- do not preserve editor backup files

IGNORE_EDITOR_TEMPORARY = YES

- ignore editor temporary files

LIBTRASH_CONFIG_FILE_UNREMOVABLE = YES

- protect user .libtrash file

GLOBAL_PROTECTION = YES

- IF the user has permission in a foreign directory, not excluded above, 
move files to ~/Trash/SYSTEM_ROOT/dir/file. (See SYSTEM_ROOT below)


If GLOBAL_PROTECTION=NO, then the foreign file will be removed directly 
if the user has permission.


TRASH_SYSTEM_ROOT = "SYSTEM_ROOT"

- subdir that will contain foreign mount point files

UNREMOVABLE_DIRS = "/bin;/boot;/dev;/etc;/lib;/lib64;/opt;/sbin;/usr"

- do not remove these directories or files inside them. Ever.

TEMPORARY_DIRS "/run;/tmp;/var"

- (see above)

REMOVABLE_MEDIA_MOUNT_POINTS "/cdrom;/media;/mnt/run"

- (see above)

EXCEPTIONS 
"/etc/mtab;/etc/resolv.conf;/etc/adjtime;/etc/upsstatus;/etc/dhcpc"


- These files can be removed even if in an UNREMOVABLE_DIR

USER_TEMPORARY_DIRS ""

- (see above)

IGNORE_RE  = "files*"

- ignore files matching anything listed using regular expressions

--
Peter Hyman

Bug#1062676: lwip: NMU diff for 64-bit time_t transition

[Graham Inggs]

Source: lwip
Version: 2.2.0+dfsg1-6
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
lwip as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for lwip
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru lwip-2.2.0+dfsg1/debian/changelog lwip-2.2.0+dfsg1/debian/changelog
--- lwip-2.2.0+dfsg1/debian/changelog   2024-01-20 09:52:55.0 +
+++ lwip-2.2.0+dfsg1/debian/changelog   2024-02-02 16:33:50.0 +
@@ -1,3 +1,10 @@
+lwip (2.2.0+dfsg1-6.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Graham Inggs   Fri, 02 Feb 2024 16:33:50 +
+
 lwip (2.2.0+dfsg1-6) unstable; urgency=medium
 
   * Minor fixes for the posixlib patch
diff -Nru lwip-2.2.0+dfsg1/debian/control lwip-2.2.0+dfsg1/debian/control
--- lwip-2.2.0+dfsg1/debian/control 2023-12-09 14:21:42.0 +
+++ lwip-2.2.0+dfsg1/debian/control 2024-02-02 16:33:50.0 +
@@ -14,7 +14,7 @@
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Depends: liblwip0 (= ${binary:Version}), ${misc:Depends}
+Depends: liblwip0t64 (= ${binary:Version}), ${misc:Depends}
 Description: small implementation of the TCP/IP protocol suite - development 
files
  lwIP is a small independent implementation of the TCP/IPv4/IPv6 protocol
  suite that has been developed by Adam Dunkels at the Computer and
@@ -28,7 +28,10 @@
  .
  This package contains the development files.
 
-Package: liblwip0
+Package: liblwip0t64
+Provides: ${t64:Provides}
+Replaces: liblwip0
+Breaks: liblwip0 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
diff -Nru lwip-2.2.0+dfsg1/debian/liblwip0.install 
lwip-2.2.0+dfsg1/debian/liblwip0.install
--- lwip-2.2.0+dfsg1/debian/liblwip0.install2023-10-13 11:17:06.0 
+
+++ lwip-2.2.0+dfsg1/debian/liblwip0.install1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-usr/lib/*/lib*.so.*
diff -Nru lwip-2.2.0+dfsg1/debian/liblwip0t64.install 
lwip-2.2.0+dfsg1/debian/liblwip0t64.install
--- lwip-2.2.0+dfsg1/debian/liblwip0t64.install 1970-01-01 00:00:00.0 
+
+++ lwip-2.2.0+dfsg1/debian/liblwip0t64.install 2023-10-13 11:17:06.0 
+
@@ -0,0 +1 @@
+usr/lib/*/lib*.so.*
diff -Nru lwip-2.2.0+dfsg1/debian/liblwip0t64.lintian-overrides 
lwip-2.2.0+dfsg1/debian/liblwip0t64.lintian-overrides
--- lwip-2.2.0+dfsg1/debian/liblwip0t64.lintian-overrides   1970-01-01 
00:00:00.0 +
+++ lwip-2.2.0+dfsg1/debian/liblwip0t64.lintian-overrides   2024-02-02 
16:33:50.0 +
@@ -0,0 +1 @@
+liblwip0t64: package-name-doesnt-match-sonames liblwip0

Bug#1062675: lucene++: NMU diff for 64-bit time_t transition

[Graham Inggs]

Source: lucene++
Version: 3.0.8-8
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
lucene++ as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for lucene++
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru lucene++-3.0.8/debian/changelog lucene++-3.0.8/debian/changelog
--- lucene++-3.0.8/debian/changelog 2023-06-19 19:44:17.0 +
+++ lucene++-3.0.8/debian/changelog 2024-02-02 16:18:43.0 +
@@ -1,3 +1,10 @@
+lucene++ (3.0.8-8.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Graham Inggs   Fri, 02 Feb 2024 16:18:43 +
+
 lucene++ (3.0.8-8) unstable; urgency=medium
 
   * Fix another cmake regression
diff -Nru lucene++-3.0.8/debian/control lucene++-3.0.8/debian/control
--- lucene++-3.0.8/debian/control   2023-06-19 13:13:36.0 +
+++ lucene++-3.0.8/debian/control   2024-02-02 16:18:43.0 +
@@ -24,8 +24,8 @@
 Package: liblucene++-dev
 Section: libdevel
 Architecture: any
-Depends: liblucene++-contrib0v5 (= ${binary:Version}),
- liblucene++0v5 (= ${binary:Version}),
+Depends: liblucene++-contrib0t64 (= ${binary:Version}),
+ liblucene++0t64 (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
 Multi-Arch: same
@@ -46,26 +46,32 @@
  .
  This package contains the reference manual and examples.
 
-Package: liblucene++0v5
+Package: liblucene++0t64
+Provides: ${t64:Provides}
+X-Time64-Compat: liblucene++0v5
+Breaks: liblucene++0v5 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Conflicts: liblucene++0
-Replaces: liblucene++0
+Replaces: liblucene++0v5, liblucene++0
 Description: Shared library for Lucene++
  Lucene++ is an up to date C++ port of the popular Java Lucene
  library, a high-performance, full-featured text search engine.
  .
  This package contains the shared library.
 
-Package: liblucene++-contrib0v5
+Package: liblucene++-contrib0t64
+Provides: ${t64:Provides}
+X-Time64-Compat: liblucene++-contrib0v5
+Breaks: liblucene++-contrib0v5 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Conflicts: liblucene++-contrib0
-Replaces: liblucene++-contrib0
+Replaces: liblucene++-contrib0v5, liblucene++-contrib0
 Description: Shared library with Lucene++ contributions
  Lucene++ is an up to date C++ port of the popular Java Lucene
  library, a high-performance, full-featured text search engine.
diff -Nru lucene++-3.0.8/debian/liblucene++-contrib0t64.install 
lucene++-3.0.8/debian/liblucene++-contrib0t64.install
--- lucene++-3.0.8/debian/liblucene++-contrib0t64.install   1970-01-01 
00:00:00.0 +
+++ lucene++-3.0.8/debian/liblucene++-contrib0t64.install   2021-01-04 
10:17:32.0 +
@@ -0,0 +1 @@
+usr/lib/*/liblucene++-contrib.so.*
diff -Nru lucene++-3.0.8/debian/liblucene++-contrib0t64.lintian-overrides 
lucene++-3.0.8/debian/liblucene++-contrib0t64.lintian-overrides
--- 

Bug#1062674: lua-compat53: NMU diff for 64-bit time_t transition

[Graham Inggs]

Source: lua-compat53
Version: 0.7-2
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
lua-compat53 as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for lua-compat53
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru lua-compat53-0.7/debian/changelog lua-compat53-0.7/debian/changelog
--- lua-compat53-0.7/debian/changelog   2019-10-29 03:42:31.0 +
+++ lua-compat53-0.7/debian/changelog   2024-02-02 16:17:27.0 +
@@ -1,3 +1,10 @@
+lua-compat53 (0.7-2.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Graham Inggs   Fri, 02 Feb 2024 16:17:27 +
+
 lua-compat53 (0.7-2) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru lua-compat53-0.7/debian/control lua-compat53-0.7/debian/control
--- lua-compat53-0.7/debian/control 2019-10-29 03:42:31.0 +
+++ lua-compat53-0.7/debian/control 2024-02-02 16:17:26.0 +
@@ -14,13 +14,15 @@
 Vcs-Git: https://salsa.debian.org/lua-team/lua-compat53/
 Vcs-Browser: https://salsa.debian.org/lua-team/lua-compat53/
 
-Package: lua-compat53
+Package: lua-compat53t64
+Replaces: lua-compat53
+Breaks: lua-compat53 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
-Provides:
+Provides: ${t64:Provides},
  ${lua:Provides},
 XB-Lua-Versions: ${lua:Versions}
 Description: Lua-5.3-style APIs for Lua 5.2 and 5.1
@@ -36,7 +38,7 @@
  ${misc:Pre-Depends},
 Section: libdevel
 Depends:
- lua-compat53 (= ${binary:Version}),
+ lua-compat53t64 (= ${binary:Version}),
  ${misc:Depends},
 Provides:
  ${lua:Provides},
@@ -47,4 +49,4 @@
  5.3. This does not make Lua 5.2 (or even Lua 5.1) entirely compatible
  with Lua 5.3, but it brings the API closer to that of Lua 5.3.
  .
- This package provides the static library and header files for lua-compat53
+ This package provides the static library and header files for lua-compat53t64
diff -Nru lua-compat53-0.7/debian/lua-compat53.docs 
lua-compat53-0.7/debian/lua-compat53.docs
--- lua-compat53-0.7/debian/lua-compat53.docs   2019-10-29 03:42:31.0 
+
+++ lua-compat53-0.7/debian/lua-compat53.docs   1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-README.md
diff -Nru lua-compat53-0.7/debian/lua-compat53.lintian-overrides 
lua-compat53-0.7/debian/lua-compat53.lintian-overrides
--- lua-compat53-0.7/debian/lua-compat53.lintian-overrides  2019-10-29 
03:42:31.0 +
+++ lua-compat53-0.7/debian/lua-compat53.lintian-overrides  1970-01-01 
00:00:00.0 +
@@ -1 +0,0 @@
-lua-compat53: package-name-doesnt-match-sonames *
diff -Nru lua-compat53-0.7/debian/lua-compat53t64.docs 
lua-compat53-0.7/debian/lua-compat53t64.docs
--- lua-compat53-0.7/debian/lua-compat53t64.docs1970-01-01 
00:00:00.0 +
+++ lua-compat53-0.7/debian/lua-compat53t64.docs2019-10-29 
03:42:31.0 +
@@ -0,0 +1 @@
+README.md
diff -Nru lua-compat53-0.7/debian/lua-compat53t64.lintian-overrides 
lua-compat53-0.7/debian/lua-compat53t64.lintian-overrides
--- 

Bug#1062673: lrcalc: NMU diff for 64-bit time_t transition

[Graham Inggs]

Source: lrcalc
Version: 1.2-2
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
lrcalc as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for lrcalc
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru lrcalc-1.2/debian/changelog lrcalc-1.2/debian/changelog
--- lrcalc-1.2/debian/changelog 2016-08-01 16:26:25.0 +
+++ lrcalc-1.2/debian/changelog 2024-02-02 16:13:45.0 +
@@ -1,3 +1,10 @@
+lrcalc (1.2-2.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Graham Inggs   Fri, 02 Feb 2024 16:13:45 +
+
 lrcalc (1.2-2) unstable; urgency=medium
 
   * New patch debian/includes.patch:
diff -Nru lrcalc-1.2/debian/control lrcalc-1.2/debian/control
--- lrcalc-1.2/debian/control   2016-08-01 16:26:04.0 +
+++ lrcalc-1.2/debian/control   2024-02-02 16:13:45.0 +
@@ -21,7 +21,10 @@
  .
  This package contains the command-line programs.
 
-Package: liblrcalc1
+Package: liblrcalc1t64
+Provides: ${t64:Provides}
+Replaces: liblrcalc1
+Breaks: liblrcalc1 (<< ${source:Version})
 Architecture: any
 Section: libs
 Multi-Arch: same
@@ -39,7 +42,7 @@
 Package: liblrcalc-dev
 Architecture: any
 Section: libdevel
-Depends: ${misc:Depends}, liblrcalc1 (= ${binary:Version})
+Depends: ${misc:Depends}, liblrcalc1t64 (= ${binary:Version})
 Description: library for calculating Littlewood-Richardson coefficients - 
development files
  The "Littlewood-Richardson Calculator" is a package of C programs for
  computing Littlewood-Richardson coefficients, providing fast calculation of
diff -Nru lrcalc-1.2/debian/liblrcalc1.install 
lrcalc-1.2/debian/liblrcalc1.install
--- lrcalc-1.2/debian/liblrcalc1.install2016-08-01 16:13:24.0 
+
+++ lrcalc-1.2/debian/liblrcalc1.install1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-/usr/lib/*/*.so.*
diff -Nru lrcalc-1.2/debian/liblrcalc1t64.install 
lrcalc-1.2/debian/liblrcalc1t64.install
--- lrcalc-1.2/debian/liblrcalc1t64.install 1970-01-01 00:00:00.0 
+
+++ lrcalc-1.2/debian/liblrcalc1t64.install 2016-08-01 16:13:24.0 
+
@@ -0,0 +1 @@
+/usr/lib/*/*.so.*
diff -Nru lrcalc-1.2/debian/liblrcalc1t64.lintian-overrides 
lrcalc-1.2/debian/liblrcalc1t64.lintian-overrides
--- lrcalc-1.2/debian/liblrcalc1t64.lintian-overrides   1970-01-01 
00:00:00.0 +
+++ lrcalc-1.2/debian/liblrcalc1t64.lintian-overrides   2024-02-02 
16:13:45.0 +
@@ -0,0 +1 @@
+liblrcalc1t64: package-name-doesnt-match-sonames liblrcalc1

Bug#1062672: lorene: NMU diff for 64-bit time_t transition

[Graham Inggs]

Source: lorene
Version: 0.0.0~cvs20161116+dfsg-1.1
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
lorene as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for lorene
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru lorene-0.0.0~cvs20161116+dfsg/debian/changelog 
lorene-0.0.0~cvs20161116+dfsg/debian/changelog
--- lorene-0.0.0~cvs20161116+dfsg/debian/changelog  2023-12-31 
13:40:01.0 +
+++ lorene-0.0.0~cvs20161116+dfsg/debian/changelog  2024-02-02 
15:44:31.0 +
@@ -1,3 +1,10 @@
+lorene (0.0.0~cvs20161116+dfsg-1.2) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Graham Inggs   Fri, 02 Feb 2024 15:44:31 +
+
 lorene (0.0.0~cvs20161116+dfsg-1.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -Nru lorene-0.0.0~cvs20161116+dfsg/debian/control 
lorene-0.0.0~cvs20161116+dfsg/debian/control
--- lorene-0.0.0~cvs20161116+dfsg/debian/control2016-11-18 
09:23:15.0 +
+++ lorene-0.0.0~cvs20161116+dfsg/debian/control2024-02-02 
15:44:31.0 +
@@ -16,8 +16,8 @@
 Multi-Arch: same
 Section: libdevel
 Depends: libfftw3-dev, libgsl0-dev, giza-dev, liblapack-dev, libx11-dev,
-liblorene-debian1 (= ${binary:Version}), liblorenef77-debian1 (= 
${binary:Version}),
-liblorene-export-debian0 (= ${binary:Version}),
+liblorene-debian1t64 (= ${binary:Version}), liblorenef77-debian1t64 (= 
${binary:Version}),
+liblorene-export-debian0t64 (= ${binary:Version}),
 ${misc:Depends}
 Recommends: gfortran
 Suggests: lorene-codes-src, lorene-doc
@@ -77,7 +77,10 @@
  components. The reference guide is available in the lorene-doc
  package.
 
-Package: liblorene-debian1
+Package: liblorene-debian1t64
+Provides: ${t64:Provides}
+Replaces: liblorene-debian1
+Breaks: liblorene-debian1 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -89,7 +92,10 @@
  .
  This package contains a shared library version of the liblorene library.
 
-Package: liblorenef77-debian1
+Package: liblorenef77-debian1t64
+Provides: ${t64:Provides}
+Replaces: liblorenef77-debian1
+Breaks: liblorenef77-debian1 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
@@ -101,7 +107,10 @@
  .
  This package contains a shared library version of the liblorenef77 library.
 
-Package: liblorene-export-debian0
+Package: liblorene-export-debian0t64
+Provides: ${t64:Provides}
+Replaces: liblorene-export-debian0
+Breaks: liblorene-export-debian0 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
diff -Nru lorene-0.0.0~cvs20161116+dfsg/debian/liblorene-debian1.install 
lorene-0.0.0~cvs20161116+dfsg/debian/liblorene-debian1.install
--- lorene-0.0.0~cvs20161116+dfsg/debian/liblorene-debian1.install  
2016-11-18 09:24:48.0 +
+++ lorene-0.0.0~cvs20161116+dfsg/debian/liblorene-debian1.install  
1970-01-01 00:00:00.0 +
@@ 

Bug#1060761: fixed in lomiri-ui-toolkit 1.3.5012+dfsg-1

[Dmitry Shachnev]

Control: reopen -1
Control: forwarded -1 
https://gitlab.com/ubports/development/core/lomiri-ui-toolkit/-/issues/34

Hi Mike!

On Fri, Feb 02, 2024 at 12:34:40AM +, Debian FTP Masters wrote:
> Source: lomiri-ui-toolkit
> Source-Version: 1.3.5012+dfsg-1
> Done: Mike Gabriel 
> 
> We believe that the bug you reported is fixed in the latest version of
> lomiri-ui-toolkit, which is due to be installed in the Debian FTP archive.
> 
> A summary of the changes between this version and the previous one is
> attached.

In the original bug report, I mentioned that there are two issues.
The new upstream release fixes the first one, but not the second one.

As a temporary measure until upstream fixes this properly, I can suggest
the attached patch that I applied in Ubuntu.

--
Dmitry Shachnev
Description: disable the test that fails with Qt 5.15.11
Author: Dmitry Shachnev 
Forwarded: not-needed
Bug: https://gitlab.com/ubports/development/core/lomiri-ui-toolkit/-/issues/34
Last-Update: 2024-01-13

--- a/tests/unit/units/dpr1/tst_units.cpp
+++ b/tests/unit/units/dpr1/tst_units.cpp
@@ -41,6 +41,7 @@ private Q_SLOTS:
 QCOMPARE(units.gridUnit(), 42.0f);
 }
 
+#if QT_VERSION < QT_VERSION_CHECK(5, 15, 11)
 void gridUnitEnvironmentVariable() {
 QByteArray gridUnit = QString::number(11).toLocal8Bit();
 qputenv("GRID_UNIT_PX", gridUnit);
@@ -48,6 +49,7 @@ private Q_SLOTS:
 QCOMPARE(units.gridUnit(), 11.0);
 qunsetenv("GRID_UNIT_PX");
 }
+#endif
 
 void dpGridUnitDefault() {
 UCUnits units;


signature.asc
Description: PGP signature

Bug#1061079: RFS pidgin-skype

[Gianfranco Costamagna]

Hello,


>It is really random, for upstream modification.
>
>But it looks I could have to do something for auto-glib2.0 
> transition.
>Which I don't really understand yet.

Just don't do any action should be fine.
There is a time_t -> time64_t transition ongoing (not yet, but will start soon 
TM)
this should happen for armel/armhf only, 

https://lists.debian.org/debian-release/2024/01/msg00033.html

>I plan to make a backport for Bookworm. Do you think I should:
>- Backport this version even if VCS fields are not up to date?
>- Make a new version with update VCS fields and backport it as soon as 
>it is in testing?


up to you!

>- Wait again for the auto-glib2.0 
> 
>transition. to make all needed modifications, create a version with also 
>updated VCS fields and see what will happen for the backport?

This won't affect the package, it should be a no change rebuild done semi 
automatically
by Release Team, and only for 32 bit architectures excluded i386.

So, it is really up to you.

G.

Bug#1061762: suricata: please enable dpdk

[Sascha Steinbiss]

Hi,


apt-cache policy dpdk-dev
dpdk-dev:
   Installed: 23.11-1
   Candidate: 23.11-1
   Version table:
  *** 23.11-1 500
     500 http://deb.debian.org/debian unstable/main riscv64 Packages
     100 /var/lib/dpkg/status

riscv64 is not a release architecture, so it is not in bullseye.


Totally right, my bad, sorry! No idea why I had bullseye selected there. 
I will try to maximize the supported archs on sid first and then narrow 
things down for backports.


Cheers
Sascha


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061762: suricata: please enable dpdk

[Alexandra N. Kossovsky]

On 02/02/2024 18:37, Sascha Steinbiss wrote:

On 2/2/24 16:14, Alexandra N. Kossovsky wrote:

and riscv64, please.


Unfortunately, riscv64 does not have a dpdk-dev package available, which would be a dependency [1]. I looked at all 
dependencies (libnuma-dev, dpdk-dev etc) and used the intersection of their available architectures.


[1] https://packages.debian.org/bullseye/dpdk-dev


apt-cache policy dpdk-dev
dpdk-dev:
  Installed: 23.11-1
  Candidate: 23.11-1
  Version table:
 *** 23.11-1 500
500 http://deb.debian.org/debian unstable/main riscv64 Packages
100 /var/lib/dpkg/status

riscv64 is not a release architecture, so it is not in bullseye.

--
Alexandra N. Kossovsky
OKTET Labs (http://www.oktetlabs.ru/)

Bug#1062669: lomiri-download-manager: NMU diff for 64-bit time_t transition

[Graham Inggs]

Source: lomiri-download-manager
Version: 0.1.2-2
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
lomiri-download-manager as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for 
lomiri-download-manager
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru lomiri-download-manager-0.1.2/debian/changelog 
lomiri-download-manager-0.1.2/debian/changelog
--- lomiri-download-manager-0.1.2/debian/changelog  2023-07-27 
00:13:05.0 +
+++ lomiri-download-manager-0.1.2/debian/changelog  2024-02-02 
15:29:13.0 +
@@ -1,3 +1,10 @@
+lomiri-download-manager (0.1.2-2.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Graham Inggs   Fri, 02 Feb 2024 15:29:13 +
+
 lomiri-download-manager (0.1.2-2) unstable; urgency=medium
 
   * [debian/*.symbols] Mark unused symbols that would otherwise be optimized 
out
diff -Nru lomiri-download-manager-0.1.2/debian/control 
lomiri-download-manager-0.1.2/debian/control
--- lomiri-download-manager-0.1.2/debian/control2023-07-27 
00:12:39.0 +
+++ lomiri-download-manager-0.1.2/debian/control2024-02-02 
15:29:13.0 +
@@ -39,7 +39,10 @@
 Vcs-Git: https://salsa.debian.org/ubports-team/lomiri-download-manager.git
 Vcs-Browser: https://salsa.debian.org/ubports-team/lomiri-download-manager/
 
-Package: libldm-common0
+Package: libldm-common0t64
+Provides: ${t64:Provides}
+Replaces: libldm-common0
+Breaks: libldm-common0 (<< ${source:Version})
 Section: libs
 Architecture: any
 Depends: ${misc:Depends},
@@ -54,7 +57,7 @@
 Package: libldm-common-dev
 Section: libdevel
 Architecture: any
-Depends: libldm-common0 (= ${binary:Version}),
+Depends: libldm-common0t64 (= ${binary:Version}),
  qtbase5-dev,
  ${shlibs:Depends},
  ${misc:Depends}
@@ -65,22 +68,28 @@
  This package contains the common headers, shared between the client
  library and the daemon library.
 
-Package: libldm-priv-common0
+Package: libldm-priv-common0t64
+Provides: ${t64:Provides}
+Replaces: libldm-priv-common0
+Breaks: libldm-priv-common0 (<< ${source:Version})
 Section: libs
 Architecture: any
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- libldm-common0 (= ${binary:Version}),
+ libldm-common0t64 (= ${binary:Version}),
 Description: Lomiri Upload/Download Manager - shared private library
  Lomiri Upload/Download Manager performs uploads and downloads from a
  centralized location.
  .
  This package includes an auxiliary shared (but private) library.
 
-Package: liblomiri-download-manager-common0
+Package: liblomiri-download-manager-common0t64
+Provides: ${t64:Provides}
+Replaces: liblomiri-download-manager-common0
+Breaks: liblomiri-download-manager-common0 (<< ${source:Version})
 Section: libs
 Architecture: any
-Depends: libldm-common0 (= ${binary:Version}),
+Depends: libldm-common0t64 (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends},
 Description: QT library for Lomiri Download Manager - common shared library
@@ -94,7 +103,7 @@
 Section: libdevel
 

Bug#1061762: suricata: please enable dpdk

[Sascha Steinbiss]

On 2/2/24 16:14, Alexandra N. Kossovsky wrote:

On 02/02/2024 17:19, Sascha Steinbiss wrote:
Will look into adding DPDK support in the binaries on platforms that 
support it on Debian (i.e. amd64, arm64, i386, ppc64el).


and riscv64, please.


Unfortunately, riscv64 does not have a dpdk-dev package available, which 
would be a dependency [1]. I looked at all dependencies (libnuma-dev, 
dpdk-dev etc) and used the intersection of their available architectures.


Cheers
S

[1] https://packages.debian.org/bullseye/dpdk-dev


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1062670: lomiri-indicator-transfer: NMU diff for 64-bit time_t transition

[Graham Inggs]

Source: lomiri-indicator-transfer
Version: 1.0.0-3
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
lomiri-indicator-transfer as a source package shipping runtime libraries whose 
ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for 
lomiri-indicator-transfer
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru lomiri-indicator-transfer-1.0.0/debian/changelog 
lomiri-indicator-transfer-1.0.0/debian/changelog
--- lomiri-indicator-transfer-1.0.0/debian/changelog2023-07-26 
19:19:46.0 +
+++ lomiri-indicator-transfer-1.0.0/debian/changelog2024-02-02 
15:35:08.0 +
@@ -1,3 +1,10 @@
+lomiri-indicator-transfer (1.0.0-3.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Graham Inggs   Fri, 02 Feb 2024 15:35:08 +
+
 lomiri-indicator-transfer (1.0.0-3) unstable; urgency=medium
 
   * debian/patches: Add patch to fix FTBFS with googletest 1.13.0
diff -Nru lomiri-indicator-transfer-1.0.0/debian/control 
lomiri-indicator-transfer-1.0.0/debian/control
--- lomiri-indicator-transfer-1.0.0/debian/control  2023-07-26 
19:19:16.0 +
+++ lomiri-indicator-transfer-1.0.0/debian/control  2024-02-02 
15:35:08.0 +
@@ -36,7 +36,7 @@
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  lomiri-indicator-transfer-common (>= ${source:Version}),
- libindicator-transfer1 (= ${binary:Version}),
+ libindicator-transfer1t64 (= ${binary:Version}),
  ayatana-indicator-common,
 Recommends: indicator-applet | indicator-renderer,
 content-hub,
@@ -69,7 +69,10 @@
  .
  This package contains the associated download manager.
 
-Package: libindicator-transfer1
+Package: libindicator-transfer1t64
+Provides: ${t64:Provides}
+Replaces: libindicator-transfer1
+Breaks: libindicator-transfer1 (<< ${source:Version})
 Section: libs
 Architecture: any
 Multi-Arch: same
@@ -87,7 +90,7 @@
 Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends},
- libindicator-transfer1 (= ${binary:Version}),
+ libindicator-transfer1t64 (= ${binary:Version}),
 Description: Development files for indicator-transfer
  Indicator that shows file/data transfers in the indicator bar of the
  Lomiri operating shell.
diff -Nru lomiri-indicator-transfer-1.0.0/debian/libindicator-transfer1.install 
lomiri-indicator-transfer-1.0.0/debian/libindicator-transfer1.install
--- lomiri-indicator-transfer-1.0.0/debian/libindicator-transfer1.install   
2023-07-26 19:06:43.0 +
+++ lomiri-indicator-transfer-1.0.0/debian/libindicator-transfer1.install   
1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
-usr/lib/*/libindicator-transfer.so.*
diff -Nru 
lomiri-indicator-transfer-1.0.0/debian/libindicator-transfer1t64.install 
lomiri-indicator-transfer-1.0.0/debian/libindicator-transfer1t64.install
--- lomiri-indicator-transfer-1.0.0/debian/libindicator-transfer1t64.install
1970-01-01 00:00:00.0 +
+++ lomiri-indicator-transfer-1.0.0/debian/libindicator-transfer1t64.install
2023-07-26 19:06:43.0 +
@@ -0,0 +1 @@

Bug#1062005: usb.ids 2024.01.20-0+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1062005 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: usb.ids
Version: 2024.01.20-0+deb11u1

Explanation: update included data list

Bug#1061472: tinyxml 2.6.2-4+deb11u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1061472 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: tinyxml
Version: 2.6.2-4+deb11u2

Explanation: fix assertion issue [CVE-2023-34194]

Bug#1062578: tzdata 2023d-0+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1062578 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: tzdata
Version: 2023d-0+deb11u1

Explanation: new upstream stable release

Bug#1061471: xerces-c 3.2.3+debian-3+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1061471 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: xerces-c
Version: 3.2.3+debian-3+deb11u1

Explanation: fix use-after-free issue [CVE-2018-1311]; fix integer overflow 
issue [CVE-2023-37536]

Bug#1062475: debian-edu-fai 2024.02.01.2~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1062475 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: debian-edu-fai
Version: 2024.02.01.2~deb12u1

Explanation: new upstream release

Bug#1062469: debian-edu-config 2.12.44~deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1062469 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: debian-edu-config
Version: 2.12.44~deb12u1

Explanation: new upstream release

Bug#1062435: indent 2.2.12-4+deb12u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1062435 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: indent
Version: 2.2.12-4+deb12u3

Explanation: fix buffer under read issue [CVE-2024-0911]

Bug#1061556: dropbear 2020.81-3+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1061556 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: dropbear
Version: 2020.81-3+deb11u1

Explanation: fix security measure bypass issue [CVE-2021-36369]; fix "terrapin" 
attack [CVE-2023-48795]

Bug#1060186: libde265 1.0.11-1+deb12u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1060186 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: libde265
Version: 1.0.11-1+deb12u2

Explanation: fix buffer overflow issues [CVE-2023-49465 CVE-2023-49467 
CVE-2023-49468]

Bug#1054386: fssync 1.6-1.1+deb12u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1054386 = bookworm pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bookworm.

Thanks for your contribution!

Upload details
==

Package: fssync
Version: 1.6-1.1+deb12u1

Explanation: disable flaky tests

Bug#1060185: libde265 1.0.11-0+deb11u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1060185 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: libde265
Version: 1.0.11-0+deb11u3

Explanation: fix buffer overflow issues [CVE-2023-49465 CVE-2023-49467 
CVE-2023-49468]

Bug#1059804: exuberant-ctags 5.9~svn20110310-14+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1059804 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: exuberant-ctags
Version: 5.9~svn20110310-14+deb11u1

Explanation: fix arbitrary command execution issue [CVE-2022-4515]

Bug#1062668: log4cplus: NMU diff for 64-bit time_t transition

[Graham Inggs]

Source: log4cplus
Version: 2.0.8-1
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
log4cplus as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for log4cplus
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
diff -Nru log4cplus-2.0.8/debian/changelog log4cplus-2.0.8/debian/changelog
--- log4cplus-2.0.8/debian/changelog2022-10-09 09:29:34.0 +
+++ log4cplus-2.0.8/debian/changelog2024-02-02 15:26:45.0 +
@@ -1,3 +1,10 @@
+log4cplus (2.0.8-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Graham Inggs   Fri, 02 Feb 2024 15:26:45 +
+
 log4cplus (2.0.8-1) unstable; urgency=medium
 
   * New upstream version 2.0.8
diff -Nru log4cplus-2.0.8/debian/control log4cplus-2.0.8/debian/control
--- log4cplus-2.0.8/debian/control  2022-10-09 09:16:35.0 +
+++ log4cplus-2.0.8/debian/control  2024-02-02 15:26:45.0 +
@@ -18,7 +18,10 @@
 Vcs-Git: https://salsa.debian.org/debian/log4cplus.git
 Rules-Requires-Root: no
 
-Package: liblog4cplus-2.0.5
+Package: liblog4cplus-2.0.5t64
+Provides: ${t64:Provides}
+Replaces: liblog4cplus-2.0.5
+Breaks: liblog4cplus-2.0.5 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends:
@@ -34,7 +37,7 @@
 Multi-Arch: same
 Section: libdevel
 Depends:
- liblog4cplus-2.0.5 (= ${binary:Version}),
+ liblog4cplus-2.0.5t64 (= ${binary:Version}),
  ${misc:Depends}
 Description: C++ logging API modeled after the Java log4j API - development 
library
  log4cplus is a simple to use C++ logging API providing thread-safe,
diff -Nru log4cplus-2.0.8/debian/liblog4cplus-2.0.5.install 
log4cplus-2.0.8/debian/liblog4cplus-2.0.5.install
--- log4cplus-2.0.8/debian/liblog4cplus-2.0.5.install   2022-03-29 
13:18:42.0 +
+++ log4cplus-2.0.8/debian/liblog4cplus-2.0.5.install   1970-01-01 
00:00:00.0 +
@@ -1 +0,0 @@
-usr/lib/${DEB_HOST_MULTIARCH}/liblog4cplus-2.0.so.*
diff -Nru log4cplus-2.0.8/debian/liblog4cplus-2.0.5.lintian-overrides 
log4cplus-2.0.8/debian/liblog4cplus-2.0.5.lintian-overrides
--- log4cplus-2.0.8/debian/liblog4cplus-2.0.5.lintian-overrides 2022-10-09 
09:16:35.0 +
+++ log4cplus-2.0.8/debian/liblog4cplus-2.0.5.lintian-overrides 1970-01-01 
00:00:00.0 +
@@ -1,4 +0,0 @@
-# Upstream does not maintain an intended SO Name, so using package version as 
substitute.
-liblog4cplus-2.0.5: package-name-doesnt-match-sonames liblog4cplus-2.0-3
-# Not doing symbols files for C++ libraries.
-liblog4cplus-2.0.5: no-symbols-control-file 
usr/lib/x86_64-linux-gnu/liblog4cplus-2.0.so.3.4.*
diff -Nru log4cplus-2.0.8/debian/liblog4cplus-2.0.5t64.install 
log4cplus-2.0.8/debian/liblog4cplus-2.0.5t64.install
--- log4cplus-2.0.8/debian/liblog4cplus-2.0.5t64.install1970-01-01 
00:00:00.0 +
+++ log4cplus-2.0.8/debian/liblog4cplus-2.0.5t64.install2022-03-29 
13:18:42.0 +
@@ -0,0 +1 @@
+usr/lib/${DEB_HOST_MULTIARCH}/liblog4cplus-2.0.so.*
diff -Nru log4cplus-2.0.8/debian/liblog4cplus-2.0.5t64.lintian-overrides 

Bug#1062667: rust-h2: Resource exhaustion vulnerability in h2 may lead to Denial of Service

[Alexander Kjäll]

Source: rust-h2
Severity: important
X-Debbugs-Cc: alexander.kj...@gmail.com

Dear Maintainer,

An attacker with an HTTP/2 connection to an affected endpoint can send 
a steady stream of invalid frames to force the generation of reset frames 
on the victim endpoint. By closing their recv window, the attacker could 
then force these resets to be queued in an unbounded fashion, resulting 
in Out Of Memory (OOM) and high CPU usage.

This fix is corrected in hyperium/h2#737, which limits the total number 
of internal error resets emitted by default before the connection is 
closed.


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

Kernel: Linux 6.6.11-amd64 (SMP w/8 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

Bug#1061762: suricata: please enable dpdk

[Alexandra N. Kossovsky]

On 02/02/2024 17:19, Sascha Steinbiss wrote:
Will look into adding DPDK support in the binaries on platforms that support it on Debian (i.e. amd64, arm64, i386, 
ppc64el).


and riscv64, please.

--
Alexandra N. Kossovsky
OKTET Labs (http://www.oktetlabs.ru/)

Bug#1062665: [INTL:sv] Swedish strings for clamav debconf

[Martin Bagge / brother]

package: clamav
severity: wishlist
tags: patch l10n

Please consider to add this file to translation of debconf.
--
brother# Translation of clamav to Swedish
# Copyright (C) 2024 Martin Bagge 
# This file is distributed under the same license as the clamav package.
#
# Martin Bagge , 2008-2011, 2024
msgid ""
msgstr ""
"Project-Id-Version: clamav_0.93~dfsg-1_sv\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2023-12-20 15:17+\n"
"PO-Revision-Date: 2024-02-02 16:08+0100\n"
"Last-Translator: Martin Bagge / brother \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Poedit-Language: Swedish\n"
"X-Poedit-Country: Sweden\n"

#. Type: select
#. Choices
#: ../clamav-freshclam.templates:2001
msgid "daemon"
msgstr "demon"

#. Type: select
#. Choices
#: ../clamav-freshclam.templates:2001
msgid "manual"
msgstr "manuell"

#. Type: select
#. Description
#: ../clamav-freshclam.templates:2002
msgid "Virus database update method:"
msgstr "Metod för uppdatering av virusdatabasen:"

#. Type: select
#. Description
#: ../clamav-freshclam.templates:2002
msgid "Please choose the method for virus database updates."
msgstr "Välj en metod för uppdatering av virusdatabasen."

#. Type: select
#. Description
#: ../clamav-freshclam.templates:2002
msgid ""
" daemon:  freshclam is running as a daemon all the time. You should choose\n"
"  this option if you have a permanent network connection;\n"
" ifup.d:  freshclam will be running as a daemon as long as your Internet\n"
"  connection is up. Choose this one if you use a dialup Internet\n"
"  connection and don't want freshclam to initiate new connections;\n"
" cron:freshclam is started from cron. Choose this if you want full "
"control\n"
"  of when the database is updated;\n"
" manual:  no automatic invocation of freshclam. This is not recommended,\n"
"  as ClamAV's database is constantly updated."
msgstr ""
" daemon :   freshclam körs som en daemon hela tiden. Du bör välja\n"
"denna om du har en permanent nätverksuppkoppling.\n"
" ifup.d :   freshclam kommer att köras som en daemon så längre som din\n"
"Internet förbindelse är igång. Välj denna om du har en uppringd\n"
"förbindelse och inte vill att freshclam ska skapa nya "
"uppkopplingar.\n"
" cron : freshclam startas från cron. Välj denna om du vill ha full "
"kontroll\n"
"när databasen ska uppdateras.\n"
" manuellt : Ingen automatiskt uppdatering av freshclam. Detta är inte\n"
"rekommanderat eftersom clamav's databas uppdateras ofta."

#. Type: select
#. Description
#: ../clamav-freshclam.templates:3001
msgid "Local database mirror site:"
msgstr "Lokal spegelsajt för databas:"

#. Type: select
#. Description
#: ../clamav-freshclam.templates:3001
msgid "Please select the closest local mirror site."
msgstr "Välj den närmaste lokala spegelsajten."

#. Type: select
#. Description
#: ../clamav-freshclam.templates:3001
msgid ""
"Freshclam updates its database from a world wide network of mirror sites. "
"Please select the closest mirror. If you leave the default setting, an "
"attempt will be made to guess a nearby mirror."
msgstr ""
"Freshclam uppdaterar sin database från ett världsspännande nätverk av "
"spegelsajter.  Välj den spegel som är närmast dig.  Om du lämnar detta kvar "
"som standardvärdet kommer ett försök att göras att hitta en spegel närmast "
"dig men detta försök kanske inte alltid ger dig den närmaste spegelsajten."

#. Type: string
#. Description
#: ../clamav-freshclam.templates:4001
msgid "HTTP proxy information (leave blank for none):"
msgstr "HTTP-proxy information (lämna blank om du inte har en):"

#. Type: string
#. Description
#: ../clamav-freshclam.templates:4001
msgid ""
"If you need to use an HTTP proxy to access the outside world, enter the "
"proxy information here. Otherwise, leave this blank."
msgstr ""
"Om du behöver använda en HTTP-proxy för att få tillgång till världen "
"utanför, ange proxyinformationen här. Om inte, lämna denna blank."

#. Type: string
#. Description
#: ../clamav-freshclam.templates:4001
msgid "Please use URL syntax (\"http://host[:port]\;) here."
msgstr "Använd URL-syntax (\"http://värd[:port]\;) här."

#. Type: string
#. Description
#: ../clamav-freshclam.templates:5001
msgid "Proxy user information (leave blank for none):"
msgstr "Användarinformation för proxy (lämna blank om du inte har någon):"

#. Type: string
#. Description
#: ../clamav-freshclam.templates:5001
msgid ""
"If you need to supply a username and password to the proxy, enter it here. "
"Otherwise, leave this blank."
msgstr ""
"Om du behöver skicka med ett användarnamn och lösenord till proxyn, ange då "
"det här. Om inte, lämna fältet blankt."

#. Type: string
#. Description
#: ../clamav-freshclam.templates:5001
msgid "When entering user information, use the standard form of \"user:pass\"."
msgstr ""

Bug#1051010: Bug #1051010: lwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Nicholas Bamber]

Simon,

Thanks for the hints. I will explore them.

(and sorry about the email title.)


Nicholas

On 02/02/2024 14:42, Simon McVittie wrote:

I've changed the subject line back to the one from the bug - I get a
*lot* of bugmail, which I usually see out-of-context, so "Investigating"
doesn't really work as a reminder of what bug and what package you're
talking about. I hope that's compatible with your workflow.

On Fri, 02 Feb 2024 at 12:11:13 +, Nicholas Bamber wrote:

So far in order to investigate I have:

1. installed discord on a lwm desktop via flatpak. This works but is pretty
ugly and the whole filesystem is exposed.

Large proprietary apps containing an entire web browser engine tend not to
be feasible to sandbox meaningfully, unfortunately, especially if their
packagers want them to have full functionality for users who are unaware of
the existence of sandboxing and want everything to "just work".

My usual go-to test apps are GNOME Recipes
https://flathub.org/apps/org.gnome.Recipes, ASHPD demo
https://flathub.org/apps/com.belmoussaoui.ashpd.demo, or the portal tests
built by src:libportal (install libportal-tests-gtk3 and
libportal-tests-gtk4 and run with "GTK_USE_PORTAL=1 GDK_DEBUG=portals" in
the environment, or you can build them into Flatpak apps from the source
package). Those are a lot more meaningfully sandboxed.


2. Looking into ways to get the XDG_CURRENT_DESKTOP into the systemd user
environment.

In the original bug report, part of the solution I suggested was this:

 Add a sequence of semicolon-separated desktop environment names to
 /usr/share/xsessions/lwm.desktop, most likely just "Lwm":

 DesktopNames=Lwm;

 (For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
 their equivalent xsessions file.)

Most display managers take this into account and will convert it into
setting the XDG_CURRENT_DESKTOP setting (for example, I know that gdm3,
lightdm and sddm do this).

This won't work for xdm, but at some point I think we have to start
treating that sort of thing as an xdm limitation, rather than something
that individual desktop environments are expected to address?


Putting a script into the 55 priority in /etc/X11/Xsession.d. This works
(and does not pollute other desktop environments since we can check at that
point). However it depends on the the package dbus-x11 and I have concerns
about the long term support for this package.

Doesn't the combination of these two files

dbus-user-session: /etc/X11/Xsession.d/20dbus_xdg-runtime
dbus-x11: /etc/X11/Xsession.d/95dbus_update-activation-env

already do what's needed here? Those two packages represent the only two
implementations of the dbus-session-bus virtual package that currently
exist in Debian.

xdg-desktop-portal already depends on
default-dbus-session-bus | dbus-session-bus, so whenever xdg-desktop-portal
is installed, so is at least one of those two packages; and they both pull
in dbus-bin, which provides /usr/bin/dbus-update-activation-environment.

If someone adds a third implementation of dbus-session-bus, I think it
would be entirely reasonable for us to expect it to have similar handling
of at least the most basic variables like DBUS_SESSION_BUS_ADDRESS,
DISPLAY, XAUTHORITY and XDG_CURRENT_DESKTOP.

The other possible way to do this, which *would* work even for xdm, is to
do like gnome-session does, and upload at least those few basic environment
variables to the D-Bus activation environment during GUI session startup,
either from the main executable (using libdbus or a similar library) or
from a shell script wrapper (using dbus-update-activation-environment or
equivalent). This wouldn't necessarily have to imply a hard dependency
on d-u-a-e, it could be done conditionally. I realise that this is
unappealing for a specifically lightweight desktop environment, so I'd
be fine with the answer to this particular part being "wontfix, use a
better display manager if you want this functionality".

 smcv

Bug#1062666: transition: openmm

[Andrius Merkys]

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

Hello,

I would like to request a transition slot for openmm
(experimental -> unstable) due to soname bump. Current ben tracker [1]
is OK.

All reverse dependencies rebuild fine, except for cpptraj which is not 
in testing.


Thanks,
Andrius

[1] https://release.debian.org/transitions/html/auto-openmm.html

Bug#1051010: Bug #1051010: lwm: please set XDG_CURRENT_DESKTOP and use it to configure xdg-desktop-portal

[Simon McVittie]

I've changed the subject line back to the one from the bug - I get a
*lot* of bugmail, which I usually see out-of-context, so "Investigating"
doesn't really work as a reminder of what bug and what package you're
talking about. I hope that's compatible with your workflow.

On Fri, 02 Feb 2024 at 12:11:13 +, Nicholas Bamber wrote:
> So far in order to investigate I have:
> 
> 1. installed discord on a lwm desktop via flatpak. This works but is pretty
> ugly and the whole filesystem is exposed.

Large proprietary apps containing an entire web browser engine tend not to
be feasible to sandbox meaningfully, unfortunately, especially if their
packagers want them to have full functionality for users who are unaware of
the existence of sandboxing and want everything to "just work".

My usual go-to test apps are GNOME Recipes
https://flathub.org/apps/org.gnome.Recipes, ASHPD demo
https://flathub.org/apps/com.belmoussaoui.ashpd.demo, or the portal tests
built by src:libportal (install libportal-tests-gtk3 and
libportal-tests-gtk4 and run with "GTK_USE_PORTAL=1 GDK_DEBUG=portals" in
the environment, or you can build them into Flatpak apps from the source
package). Those are a lot more meaningfully sandboxed.

> 2. Looking into ways to get the XDG_CURRENT_DESKTOP into the systemd user
> environment.

In the original bug report, part of the solution I suggested was this:

Add a sequence of semicolon-separated desktop environment names to
/usr/share/xsessions/lwm.desktop, most likely just "Lwm":

DesktopNames=Lwm;

(For example, icewm and windowmaker use "ICEWM" and "WindowMaker" in
their equivalent xsessions file.)

Most display managers take this into account and will convert it into
setting the XDG_CURRENT_DESKTOP setting (for example, I know that gdm3,
lightdm and sddm do this).

This won't work for xdm, but at some point I think we have to start
treating that sort of thing as an xdm limitation, rather than something
that individual desktop environments are expected to address?

> Putting a script into the 55 priority in /etc/X11/Xsession.d. This works
> (and does not pollute other desktop environments since we can check at that
> point). However it depends on the the package dbus-x11 and I have concerns
> about the long term support for this package.

Doesn't the combination of these two files

dbus-user-session: /etc/X11/Xsession.d/20dbus_xdg-runtime
dbus-x11: /etc/X11/Xsession.d/95dbus_update-activation-env

already do what's needed here? Those two packages represent the only two
implementations of the dbus-session-bus virtual package that currently
exist in Debian.

xdg-desktop-portal already depends on
default-dbus-session-bus | dbus-session-bus, so whenever xdg-desktop-portal
is installed, so is at least one of those two packages; and they both pull
in dbus-bin, which provides /usr/bin/dbus-update-activation-environment.

If someone adds a third implementation of dbus-session-bus, I think it
would be entirely reasonable for us to expect it to have similar handling
of at least the most basic variables like DBUS_SESSION_BUS_ADDRESS,
DISPLAY, XAUTHORITY and XDG_CURRENT_DESKTOP.

The other possible way to do this, which *would* work even for xdm, is to
do like gnome-session does, and upload at least those few basic environment
variables to the D-Bus activation environment during GUI session startup,
either from the main executable (using libdbus or a similar library) or
from a shell script wrapper (using dbus-update-activation-environment or
equivalent). This wouldn't necessarily have to imply a hard dependency
on d-u-a-e, it could be done conditionally. I realise that this is
unappealing for a specifically lightweight desktop environment, so I'd
be fine with the answer to this particular part being "wontfix, use a
better display manager if you want this functionality".

smcv

Bug#1062664: u-boot-starfive: crash with USB stick plugged in

[Heinrich Schuchardt]

Package: u-boot-starfive
Version: 2024.01+dfsg-1
Severity: normal

As reported in Launchpad bug 2052141 booting the StarFive VisionFive 2 
board with a USB stick plugged in results in a crash.


The crash occurs when calling free() implemented in common/dlmalloc.c

The following two patches applied on top of upstream v2024.01 resolve 
the issue:


0351b659dd02 ("efi_loader: create common function to free struct 
efi_disk_obj")
f674a2f9a9f9 ("efi_loader: avoid pointer access after calling 
efi_delete_handle")


Best regards

Heinrich

Bug#1061762: suricata: please enable dpdk

[Sascha Steinbiss]

Hi,

thanks for the notification.


Suricata can work with DPDK, but this feature is not enabled in the
Debian package.  Could you enable it, please?


True. I assumed DPDK and the other methods (like AF_PACKET/AF_XDP) were 
mutually exclusive, but looks like they are not! Will look into adding 
DPDK support in the binaries on platforms that support it on Debian 
(i.e. amd64, arm64, i386, ppc64el).


Cheers
S


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061079: RFS pidgin-skype

[Patrick ZAJDA]

Hello,

Le 30/01/2024 à 19:20, Gianfranco Costamagna a écrit :

Hello,
please switch VCS fields to the new location
https://salsa.debian.org/debian/pidgin-skype/-/blob/master/debian/control?ref_type=heads


Done, in both repositories.


And then just delete the old repository once the new version is uploaded in sid.

There is no rush, if you plan some upload in the near future.


It is really random, for upstream modification.

But it looks I could have to do something for auto-glib2.0 
 transition.

Which I don't really understand yet.

I plan to make a backport for Bookworm. Do you think I should:
- Backport this version even if VCS fields are not up to date?
- Make a new version with update VCS fields and backport it as soon as 
it is in testing?
- Wait again for the auto-glib2.0 
 
transition. to make all needed modifications, create a version with also 
updated VCS fields and see what will happen for the backport?


Thanks,

Patrick


G.


Il martedì 30 gennaio 2024 alle ore 16:28:14 CET, Patrick ZAJDA 
 ha scritto:





Hello,

On Fri, 26 Jan 2024 18:36:02 +0100 Gianfranco Costamagna
 wrote:

Happily done, btw how do you feel about pushing your work somewhere

in Debian git repositories?

https://salsa.debian.org/debian/pidgin-skype might be a good place.

This way other people can help maintaining your package

I've just pushed all branches and tags to this repository and set CI.

What do you suggest me to do after knowing it is referenced in the
package meta-data?
Maintaining both repositories synced until there is a new version to
publish?

Thanks and best regards,



--
Patrick ZAJDA
Logo certification NVDA expert 2022


OpenPGP_0x9D4AD35BEA273DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061954: frog: NMU diff for 64-bit time_t transition

[Joost van Baal-Ilić]

Hi,

[sorry for yet another one, i clicked sent too early...]

On Fri, Feb 02, 2024 at 03:01:04PM +0100, Joost van Baal-Ilić wrote:
> On Fri, Feb 02, 2024 at 02:22:20PM +0100, Maarten van Gompel wrote:
> > 
> > On second thought, I read https://wiki.debian.org/ReleaseGoals/64bit-time 
> > and
> > checked the updated Frog sources, there is no time_t exposed at all anymore
> > in the new version I'm packaging.
> 
> That's nice.
> 
> > So if I understand things correctly, the new
> > libfrog3 library does not need the t64 transition and I can revert
> > https://salsa.debian.org/science-team/frog/-/commit/2bbda8d92d40b96a216e8d8db972a9589f8df02f
> >  ?
> 
> 
> > > Afaik the plan is to keep the binary packages named libt64 (reading
> > > https://wiki.debian.org/ReleaseGoals/64bit-time ); this helps executing 
> > > the
> > > transition.
> > 
> > I'll rebase so the libfrog2t64 patch is included, but it'll be
> > immediately superseded by libfrog3.
> 
> Upcoming stable release could likely ship both frog2 and frog3.  E.g. if
> testing around release-time ships binaries build-depending upon frog2, this
> will happen.

Wow, having just read Message-Id:  to
debian-science, we might indeed succeed in shipping upcoming Debian stable
without frog2.

Bye,

Joost

Bug#1061954: frog: NMU diff for 64-bit time_t transition

[Joost van Baal-Ilić]

Hi,

On Fri, Feb 02, 2024 at 02:22:20PM +0100, Maarten van Gompel wrote:
> 
> On second thought, I read https://wiki.debian.org/ReleaseGoals/64bit-time and
> checked the updated Frog sources, there is no time_t exposed at all anymore
> in the new version I'm packaging.

That's nice.

> So if I understand things correctly, the new
> libfrog3 library does not need the t64 transition and I can revert
> https://salsa.debian.org/science-team/frog/-/commit/2bbda8d92d40b96a216e8d8db972a9589f8df02f
>  ?


> > Afaik the plan is to keep the binary packages named libt64 (reading
> > https://wiki.debian.org/ReleaseGoals/64bit-time ); this helps executing the
> > transition.
> 
> I'll rebase so the libfrog2t64 patch is included, but it'll be
> immediately superseded by libfrog3.

Upcoming stable release could likely ship both frog2 and frog3.  E.g. if
testing around release-time ships binaries build-depending upon frog2, this
will happen.

Bye,

Joost

Bug#709051: Might "just" be a local firewall rule

[Henrik Christian Grove]

I encountered that error earlier today, but it went away when I fixed 
the local firewall to allow the traffic.


It's not a good way to report that though.

But I'm writing this in the hope that it can help others that encounter 
this (since the bug report is more than 10 years old, I don't expect 
that it will help Harish).


.Henrik

Bug#1061954: frog: NMU diff for 64-bit time_t transition

[Maarten van Gompel]

Hi Joost, Lukas, 

On second thought, I read https://wiki.debian.org/ReleaseGoals/64bit-time and 
checked the updated Frog sources, there is no time_t
exposed at all anymore in the new version I'm packaging. So if I understand 
things correctly, the new
libfrog3 library does not need the t64 transition and I can revert
https://salsa.debian.org/science-team/frog/-/commit/2bbda8d92d40b96a216e8d8db972a9589f8df02f
 ?

> Afaik the plan is to keep the binary packages named libt64 (reading
> https://wiki.debian.org/ReleaseGoals/64bit-time ); this helps executing the
> transition.

I'll rebase so the libfrog2t64 patch is included, but it'll be
immediately superseded by libfrog3.

Regards,

-- 

Maarten van Gompel (proycon)

web: https://proycon.anaproy.nl
gpg: 0x39FE11201A31555C


signature.asc
Description: PGP signature

Bug#1054152: rasdaemon: frequent crashes of rasdaemon

[piorunz]

Hello Tai,

No problem at all, I have installed deb package from unstable into my
Stable system. No new deps, so everything went smoothly. Older dbgsym
package has been removed in the process.

I will monitor for any regressions and let you know if I have any.

On 02/02/2024 12:00, Taihsiang Ho (tai271828) wrote:

Hi piorunz,

The issue and the corresponding backport should have been included in
the latest version in unstable/testing with version 0.8.0-2. If you
have a moment, would you mind a try?

Cheers,
Tai

On Sat, Jan 6, 2024 at 11:30 AM piorunz  wrote:


Hello Tai,

Thanks for your reply.

Patch attached, for Debian Stable, following this commit for upstream
version:

https://github.com/mchehab/rasdaemon/commit/f1ea76375281001cdf4a048c1a4a24d86c6fbe48

It's 1 line change in 1 file (ras-events.c).


--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Bug#1062663: rust-snow: Unauthenticated Nonce Increment in snow

[Alexander Kjäll]

Source: rust-snow
Severity: important
X-Debbugs-Cc: alexander.kj...@gmail.com

Dear Maintainer,

There was a logic bug where unauthenticated payloads could still cause 
a nonce increment in snow's internal state. For an attacker with the 
ability to inject packets into the channel Noise is talking over, this 
allows a denial-of-service type attack which could prevent 
communication as it causes the sending and receiving side to be 
expecting different nonce values than would arrive.

Note that this only affects those who are using the stateful 
TransportState, not those using StatelessTransportState.

Patches

This has been patched in version 0.9.5, and all users are recommended to update.

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

Kernel: Linux 6.6.11-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1062662: gnome-software: Option "--show-metainfo" is missing in manpage

[Christian Buhtz]

Package: gnome-software
Version: 43.5-1~deb12u1
Severity: minor

Dear Maintainer,

the option "--show-metainfo" is not present in the manpage.

Kind


-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.1.0-17-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

Versions of packages gnome-software depends on:
ii  appstream0.16.1-2
ii  apt-config-icons 0.16.1-2
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gnome-software-common43.5-1~deb12u1
ii  gsettings-desktop-schemas43.0-1
ii  libadwaita-1-0   1.2.2-1
ii  libappstream40.16.1-2
ii  libc62.36-9+deb12u3
ii  libcairo21.16.0-7
ii  libfwupd21.8.12-2
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-4-1   4.8.3+ds-2+deb12u1
ii  libgtk3-perl 0.038-3
ii  libgudev-1.0-0   237-2
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmalcontent-0-00.11.0-4
ii  libpackagekit-glib2-18   1.2.6-5
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpolkit-gobject-1-0122-3
ii  libsoup-3.0-03.2.2-2
ii  libxmlb2 0.3.10-2
ii  packagekit   1.2.6-5
ii  software-properties-gtk  0.99.30-4

Versions of packages gnome-software recommends:
ii  fwupd  1.8.12-2

Versions of packages gnome-software suggests:
pn  apt-config-icons-hidpi 
pn  gnome-software-plugin-flatpak  
pn  gnome-software-plugin-snap 

-- no debconf information

Bug#1062613: librsb: NMU diff for 64-bit time_t transition

[Rafael Laboissière]

Control: tags -1 + upstream

Thanks for this bug report and for the upload to experimental, Steve. 
 
I am hereby forwarding your message to the upstream author.


Best,

Rafael Laboissière

* Steve Langasek  [2024-02-02 06:09]:


Source: librsb
Version: 1.3.0.2+dfsg-6
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit 
architectures in 2038 and beyond 
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified 
librsb as a source package shipping runtime libraries whose ABI 
either is affected by the change in size of time_t, or could not be 
analyzed via abi-compliance-checker (and therefore to be on the safe 
side we assume is affected).


To ensure that inconsistent combinations of libraries with their 
reverse-dependencies are never installed together, it is necessary to 
have a library transition, which is most easily done by renaming the 
runtime library package.


Since turning on 64-bit time_t is being handled centrally through a change 
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is 
important that libraries affected by this ABI change all be uploaded close 
together in time.  Therefore I have prepared a 0-day NMU for librsb 
which will initially be uploaded to experimental if possible, then to 
unstable after packages have cleared binary NEW.


Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although 
this package will be uploaded to experimental immediately, there will be a 
period of several days before we begin uploads to unstable; so if information 
becomes available that your package should not be included in the transition, 
there is time for us to amend the planned uploads.




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


Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE 
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set 
Shell: /bin/sh linked to /usr/bin/dash 
Init: systemd (via /run/systemd/system)


diff -Nru librsb-1.3.0.2+dfsg/debian/.gitignore librsb-1.3.0.2+dfsg/debian/.gitignore 
--- librsb-1.3.0.2+dfsg/debian/.gitignore	2023-06-13 09:19:25.0 + 
+++ librsb-1.3.0.2+dfsg/debian/.gitignore	1970-01-01 00:00:00.0 + 
@@ -1,15 +0,0 @@ 
-/.debhelper/ 
-/*.debhelper.log 
-/debhelper-build-stamp 
-/autoreconf.after 
-/autoreconf.before 
-/files 
-/librsb-dev.substvars 
-/librsb-dev/ 
-/librsb-doc.substvars 
-/librsb-doc/ 
-/librsb-tools.substvars 
-/librsb-tools/ 
-/librsb0.substvars 
-/librsb0/ 
-/tmp/ 
diff -Nru librsb-1.3.0.2+dfsg/debian/changelog librsb-1.3.0.2+dfsg/debian/changelog 
--- librsb-1.3.0.2+dfsg/debian/changelog	2023-06-13 09:19:25.0 + 
+++ librsb-1.3.0.2+dfsg/debian/changelog	2024-02-02 05:59:18.0 + 
@@ -1,3 +1,10 @@ 
+librsb (1.3.0.2+dfsg-6.1) experimental; urgency=medium 
+ 
+  * Non-maintainer upload. 
+  * Rename libraries for 64-bit time_t transition. 
+ 
+ -- Steve Langasek   Fri, 02 Feb 2024 05:59:18 + 
+ 
librsb (1.3.0.2+dfsg-6) unstable; urgency=medium


  * Upload to unstable
diff -Nru librsb-1.3.0.2+dfsg/debian/control librsb-1.3.0.2+dfsg/debian/control 
--- librsb-1.3.0.2+dfsg/debian/control	2023-06-13 09:19:25.0 + 
+++ librsb-1.3.0.2+dfsg/debian/control	2024-02-02 05:59:18.0 + 
@@ -16,7 +16,10 @@ 
Vcs-Browser: https://salsa.debian.org/science-team/librsb 
Rules-Requires-Root: no


-Package: librsb0 
+Package: librsb0t64 
+Provides: ${t64:Provides} 
+Replaces: librsb0 
+Breaks: librsb0 (<< ${source:Version}) 
Architecture: any 
Depends: ${shlibs:Depends}, ${misc:Depends} 
Multi-Arch: same 
@@ -35,7 +38,7 @@ 
Package: librsb-dev 
Section: libdevel 
Architecture: any 
-Depends: librsb0 (= ${binary:Version}), ${misc:Depends} 
+Depends: librsb0t64 (= ${binary:Version}), ${misc:Depends} 
Description: shared-memory Sparse BLAS library using the RSB matrix format (development) 
 This is a library for sparse matrix computations featuring the Recursive 
 Sparse Blocks (RSB) matrix format. This format allows cache efficient and 
@@ -51,7 +54,7 @@


Package: librsb-tools
Architecture: any
-Depends: librsb0 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends} 
+Depends: librsb0t64 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends} 
Description: shared-memory Sparse BLAS library using the RSB matrix format (tools) 
 This is a library for sparse matrix computations featuring the Recursive 
 Sparse Blocks (RSB) matrix format. This format allows cache efficient and 
diff -Nru librsb-1.3.0.2+dfsg/debian/librsb0.install 

Bug#1040168: The default orientation of a video in mplayer is wrong

[Lorenzo]

Control: severity -1 wishlist

On Sun, 2 Jul 2023 19:49:28 +0200 AlMa  wrote:
> Package: mplayer
> Version: 2:1.5+svn38408-1
> 
> The video in the attachment is supposed to be oriented in a way such 
> that the ground and water is below, and the sky is above. VLC does
> this without any options (and `mplayer -vf rotate=0` and `mplayer -vf 
> rotate`).  However, the default orientation in mplayer is wrong; what
> I see is the video on the side.
> 
> Please improve mplayer in this respect.

Hi,

This issue needs work upstream and giving the low activity there I
don't think there will be a patch soon.
Also, according to upstream, rotation was never applied by default due
to performance impact, so this is a new feature request rather than a
regression. And the one time fix (that is, add vf-pre=rotate to
mplayer.conf[1]) on user side is cheap enough to consider this a
wishlist bug.

possible future development can be followed upstream at
https://trac.mplayerhq.hu/ticket/2415

Lorenzo

[1] I tested this with the video provided and it works, it may not
   work with some other -vo, not sure.

> 
> Gratefully,
> AlMa

Bug#1062073: Re: Bug#1062073: grub-efi-amd64: GRUB 2.12 fails to boot with X64 exception

[Mate Kukri]

Thanks for bisecting, appreciate that.

Having boot crashes like that by default still looks really bad,
I would rather revert that commit given that it's new and no one
had the opportunity to rely on it yet.

On Fri, Feb 2, 2024 at 12:44 PM Morten Hein Tiljeset  wrote:
>
> So I spent an evening bisecting the issue from upstream sources.
>
> The problem was introduced with
> > 7b192ec4c term/ns8250: Use ACPI SPCR table when available to configure 
> > serial
>
> The old behaviour can be regained by setting the unit explicitly grub.cfg
> > serial --unit=0 --speed=115200
>
> This solves my issue, so you can go ahead and close the bug report.
> I assume the ACPI lookup logic triggered a bug in my particular firmware.
>
> /Morten

Bug#1062661: RM: python-rdflib-jsonld -- ROM; Obsoleted by python3-rdflib 6.x; last use in sid removed

[Michael R. Crusoe]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: python-rdflib-jso...@packages.debian.org, cru...@debian.org
Control: affects -1 + src:python-rdflib-jsonld

Thanks!

--
Michael R. Crusoe



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1062073: Re: Bug#1062073: grub-efi-amd64: GRUB 2.12 fails to boot with X64 exception

[Morten Hein Tiljeset]

So I spent an evening bisecting the issue from upstream sources.

The problem was introduced with
> 7b192ec4c term/ns8250: Use ACPI SPCR table when available to configure serial

The old behaviour can be regained by setting the unit explicitly grub.cfg
> serial --unit=0 --speed=115200

This solves my issue, so you can go ahead and close the bug report.
I assume the ACPI lookup logic triggered a bug in my particular firmware.

/Morten

Bug#1062660: bookworm-pu: package pypy3/7.3.11+dfsg-2+deb12u1

[Stefano Rivera]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: py...@packages.debian.org
Control: affects -1 + src:pypy3

[ Reason ]
A user ran into a JIT bug in pypy3 in bookworm that has been resolved
upstream. It's a simple bug and trivial to backport the fix for.

[ Impact ]
More users may run into this particular JIT bug.

[ Tests ]
The bug comes with a regression test, that passes.

[ Risks ]
The change is very simple. The patch applied cleanly and that code
hasn't been modified upstream, since this patch.

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

[ Changes ]
An assert that crashes the interpreter is replaced by an exception that
will drop back out of the JIT.
diff -Nru pypy3-7.3.11+dfsg/debian/changelog pypy3-7.3.11+dfsg/debian/changelog
--- pypy3-7.3.11+dfsg/debian/changelog  2023-02-06 10:12:43.0 -0400
+++ pypy3-7.3.11+dfsg/debian/changelog  2024-02-01 20:41:13.0 -0400
@@ -1,3 +1,10 @@
+pypy3 (7.3.11+dfsg-2+deb12u1) bookworm; urgency=medium
+
+  * Avoid an rpython assertion error in the JIT if integer ranges don't
+overlap in a loop. (Closes: #1062460)
+
+ -- Stefano Rivera   Thu, 01 Feb 2024 20:41:13 -0400
+
 pypy3 (7.3.11+dfsg-2) unstable; urgency=medium
 
   * Mark pypy3 as being EXTERNALLY-MANAGED.
diff -Nru pypy3-7.3.11+dfsg/debian/patches/int-jit-assert.patch 
pypy3-7.3.11+dfsg/debian/patches/int-jit-assert.patch
--- pypy3-7.3.11+dfsg/debian/patches/int-jit-assert.patch   1969-12-31 
20:00:00.0 -0400
+++ pypy3-7.3.11+dfsg/debian/patches/int-jit-assert.patch   2024-02-01 
20:41:13.0 -0400
@@ -0,0 +1,100 @@
+From: Carl Friedrich Bolz-Tereick 
+Date: Fri, 3 Mar 2023 14:15:42 +0100
+Subject: Upstream: #3892: fix wrong assert in intutils,
+ it should be an InvalidLoop instead
+
+I introduced the assert in 5909f5e0a75c. before that, inconsistent intersects
+would just do nothing, which I am not sure is a better solution than raising
+InvalidLoop
+
+Bug-Debian: https://bugs.debian.org/1062460
+Origin: upstream, 
https://github.com/pypy/pypy/commit/ba8a3c45b9afe068c06780b4c34709c852ae20ea
+---
+ rpython/jit/metainterp/optimizeopt/intutils.py |  8 +-
+ .../metainterp/optimizeopt/test/test_intbound.py   |  5 ++--
+ rpython/jit/metainterp/test/test_ajit.py   | 33 ++
+ 3 files changed, 42 insertions(+), 4 deletions(-)
+
+diff --git a/rpython/jit/metainterp/optimizeopt/intutils.py 
b/rpython/jit/metainterp/optimizeopt/intutils.py
+index 381d0a2..e9ba7f7 100644
+--- a/rpython/jit/metainterp/optimizeopt/intutils.py
 b/rpython/jit/metainterp/optimizeopt/intutils.py
+@@ -129,7 +129,13 @@ class IntBound(AbstractInfo):
+ return 0 <= self.lower
+ 
+ def intersect(self, other):
+-assert not self.known_gt(other) and not self.known_lt(other)
++from rpython.jit.metainterp.optimize import InvalidLoop
++if self.known_gt(other) or self.known_lt(other):
++# they don't overlap, which makes the loop invalid
++# this never happens in regular linear traces, but it can happen 
in
++# combination with unrolling/loop peeling
++raise InvalidLoop("two integer ranges don't overlap")
++
+ r = False
+ if self.make_ge_const(other.lower):
+ r = True
+diff --git a/rpython/jit/metainterp/optimizeopt/test/test_intbound.py 
b/rpython/jit/metainterp/optimizeopt/test/test_intbound.py
+index d4a0db4..ea9b74c 100644
+--- a/rpython/jit/metainterp/optimizeopt/test/test_intbound.py
 b/rpython/jit/metainterp/optimizeopt/test/test_intbound.py
+@@ -225,13 +225,12 @@ def test_intersect():
+ assert not b.contains(n)
+ 
+ def test_intersect_bug():
++from rpython.jit.metainterp.optimize import InvalidLoop
+ b1 = bound(17, 17)
+ b2 = bound(1, 1)
+-with pytest.raises(AssertionError):
++with pytest.raises(InvalidLoop):
+ b1.intersect(b2)
+ 
+-
+-
+ def test_add_bound():
+ for _, _, b1 in some_bounds():
+ for _, _, b2 in some_bounds():
+diff --git a/rpython/jit/metainterp/test/test_ajit.py 
b/rpython/jit/metainterp/test/test_ajit.py
+index 29a8bf8..68e7d60 100644
+--- a/rpython/jit/metainterp/test/test_ajit.py
 b/rpython/jit/metainterp/test/test_ajit.py
+@@ -3256,6 +3256,39 @@ class BasicTests:
+ res = self.interp_operations(f, [127 - 256 * 29])
+ assert res == 127
+ 
++def 
test_bug_inline_short_preamble_can_be_inconsistent_in_optimizeopt(self):
++myjitdriver = JitDriver(greens = [], reds = "auto")
++class Str(object):
++_immutable_fields_ = ['s']
++def __init__(self, s):
++self.s = s
++
++empty = Str("")
++space = Str(" ")
++
++def f(a, b):
++   

Bug#943917: some thoughts

[Nicholas Bamber]

I have come to believe this is not a bug.

It may be that environment.d is very nice for systemd integration, but 
it is not very granular. Any environment entered via that route will end 
up in systemd user environments possibly even when it was not intended.


Scripts in Xsession.d on the other hand may well write over environment 
variables but they are written in generic shell scripts and so can be 
tailored to only set environment variables in specific circumstances. I 
would guess (and I am guessing here) that environment.d gets processed 
before Xsession.d, and so scripts in Xsession.d could choose not 
override environment variables that have already been set if appropriate.

Bug#1051010: Investigating

[Nicholas Bamber]

So far in order to investigate I have:

1. installed discord on a lwm desktop via flatpak. This works but is 
pretty ugly and the whole filesystem is exposed.


2. Looking into ways to get the XDG_CURRENT_DESKTOP into the systemd 
user environment.


Putting a script into the 55 priority in /etc/X11/Xsession.d. This works 
(and does not pollute other desktop environments since we can check at 
that point). However it depends on the the package dbus-x11 and I have 
concerns about the long term support for this package.


Looking at bug #943917, I see these concerns over the dbus-x11 package 
and  a suggestion that environment.d be used. However this is 
unacceptable because that will load the environment variables 
irrespective of what desktop environment is chosen. Specifically I have 
tested it shows up in "systemctl --user show-environment" but does not 
show up in "env" when you login to an openbox desktop.



So the Xsession.d approach seems to be the way to go, but I also have 
concerns about how many dependencies (even at the suggests level) should 
be added to a package intended to be lightweight. Obviously this could 
all be documented.

Bug#1062176: podman: Package containers-storage should be recommended

[Holger Leskien]

Thanks for the clarification and information. I support that the 
defaults for the stable distribution should not be changed. In this 
case, it would actually cause chaos because the entire storage would 
have to be reset before changing the storage driver. A change “in the 
middle” would render all active images unusable.


I can only hope that others who have the same problem as me somehow come 
across the correct information.


Kind regards

Holger

Bug#1061954: frog: NMU diff for 64-bit time_t transition

[Joost van Baal-Ilić]

Hi Maarten e.a.,

On Thu, Feb 01, 2024 at 06:29:20PM +0100, Maarten van Gompel wrote:
> On Tue Jan 30, 2024 at 2:31 PM CET, Lukas Märdian wrote:
> > As part of the 64-bit time_t transition required to support 32-bit
> > architectures in 2038 and beyond
> > (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified

> 
> Thanks for your patch. I am currently in the progress of upgrading these
> packages to the new upstream sources after a long hiatus. This would
> involve a library transition anyway (libfrog2 -> libfrog3). Is it
> sufficient if I include  'Provides: ${t64:Provides}' for the new
> libfrog3 package to accomodate this transition? I just did this in
> commit 2bbda8d92d40b96a216e8d8db972a9589f8df02f:
>   
>   
> https://salsa.debian.org/science-team/frog/-/commit/2bbda8d92d40b96a216e8d8db972a9589f8df02f
> 
> Perhaps that also removes the need for the oddly named frog2t64 package?
> If not, I'll apply your patch and rebase my changes on top of it.

Afaik the plan is to keep the binary packages named libt64 (reading
https://wiki.debian.org/ReleaseGoals/64bit-time ); this helps executing the
transition.

HTH, Bye,

Joost

Bug#1062659: appstream-generator: Missing color legend in AppStream data for bookworm

[Christian Buhtz]

Package: appstream-generator
Version: v0.9.2, AS: 1.0.2
Severity: normal

Dear Maintainer,

I was looking at 

I do see 4 colored circle graphs. But the colors are not explained, not even in
tooltips.
I assume there should be a legend.

Kind
Christian Buhtz


-- System Information:
Debian Release: 12.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.1.0-17-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

Versions of packages appstream-generator depends on:
pn  libappstream-compose0 
pn  libappstream4 
ii  libarchive13  3.6.2-1
ii  libc6 2.36-9+deb12u3
ii  libgcc-s1 12.2.0-14
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.74.6-2
pn  libglibd-2.0-0
ii  libjs-highlight.js9.18.5+dfsg1-2
pn  libjs-jquery-flot 
pn  liblmdb0  
pn  libphobos2-ldc-shared100  

Versions of packages appstream-generator recommends:
ii  ffmpeg   7:5.1.4-0+deb12u1
pn  optipng  

appstream-generator suggests no packages.

Bug#1054152: rasdaemon: frequent crashes of rasdaemon

[Taihsiang Ho (tai271828)]

Hi piorunz,

The issue and the corresponding backport should have been included in
the latest version in unstable/testing with version 0.8.0-2. If you
have a moment, would you mind a try?

Cheers,
Tai

On Sat, Jan 6, 2024 at 11:30 AM piorunz  wrote:
>
> Hello Tai,
>
> Thanks for your reply.
>
> Patch attached, for Debian Stable, following this commit for upstream
> version:
>
> https://github.com/mchehab/rasdaemon/commit/f1ea76375281001cdf4a048c1a4a24d86c6fbe48
>
> It's 1 line change in 1 file (ras-events.c).

Bug#1062658: mdevctl: This is only a test bug to check reporting through nullmailer

[Christian]

Package: mdevctl
Version: 1.2.0-7
Severity: wishlist

Dear Maintainer,

really just a test, please close

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

Kernel: Linux 6.5.0-14-generic (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mdevctl depends on:
ii  libc6  2.37-15
ii  libgcc-s1  14-20240201-2
ii  udev   255.3-2

mdevctl recommends no packages.

mdevctl suggests no packages.

Bug#1062657: Faiss needs to be migrated away from using distutils

[Pushkar Kulkarni]

Package: faiss
Version:  1.7.4-3
Severity: medium

Python 3.12 purged distutils from the std library. The Debian faiss
packages still depend on distutils in faiss/python/loader.py, causing
autopkgtests to fail.

It might help to backport upstream commit [1], but the FTFBS bug [2]
is a blocker here, and needs to be addressed first.

[1] 
https://github.com/facebookresearch/faiss/commit/c540e762ca0ecf8f43da0bfc215da148c5cf420e
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062656

Bug#1062656: Faiss fails to build from source

[Pushkar Kulkarni]

Package: faiss
Version:  1.7.4-3
Severity: high

The faiss build seems to fail in debian/sid due to a recent upgrade of
dependency swig to version 4.2.0-1.  It's my guess that this issue did
not exist with swig 4.1.0-0.3.

This was also reported upstream [1].



/<>/build/faiss/python/CMakeFiles/swigfaiss.dir/swigfaissPYTHON_wrap.cxx:
In function ‘PyObject* swig_ptr(PyObject*)’:
/<>/build/faiss/python/CMakeFiles/swigfaiss.dir/swigfaissPYTHON_wrap.cxx:4939:41:
error: ‘SWIGTYPE_p_unsigned_long_long’ was not declared in this scope;
did you mean ‘SWIGTYPE_p_unsigned_long’?
4939 | return SWIG_NewPointerObj(data, SWIGTYPE_p_unsigned_long_long, 0);
| ^
/<>/build/faiss/python/CMakeFiles/swigfaiss.dir/swigfaissPYTHON_wrap.cxx:1136:94:
note: in definition of macro ‘SWIG_NewPointerObj’
1136 | #define SWIG_NewPointerObj(ptr, type, flags)
SWIG_Python_NewPointerObj(NULL, ptr, type, flags)
| ^~~~
/<>/build/faiss/python/CMakeFiles/swigfaiss.dir/swigfaissPYTHON_wrap.cxx:4946:41:
error: ‘SWIGTYPE_p_long_long’ was not declared in this scope; did you
mean ‘SWIGTYPE_p_long’?
4946 | return SWIG_NewPointerObj(data, SWIGTYPE_p_long_long, 0);
| ^~~~
/<>/build/faiss/python/CMakeFiles/swigfaiss.dir/swigfaissPYTHON_wrap.cxx:1136:94:
note: in definition of macro ‘SWIG_NewPointerObj’
1136 | #define SWIG_NewPointerObj(ptr, type, flags)
SWIG_Python_NewPointerObj(NULL, ptr, type, flags)
| ^~~~
[ 92%] Building CXX object c_api/CMakeFiles/faiss_c.dir/utils/distances_c.cpp.o
[ 92%] Building CXX object
tests/CMakeFiles/faiss_test.dir/test_pq_encoding.cpp.o

-

[1] https://github.com/facebookresearch/faiss/issues/3235

Bug#1062407: liblopsub: NMU diff for 64-bit time_t transition

[Andre Noll]

On Thu, Feb 01, 21:13, Steve Langasek wrote:

> > * The tfortune package depends on liblopsub and currently has
> 
> > Depends: ${shlibs:Depends}, liblopsub1, ${misc:Depends}
> 
> > in its own debian/control file. When would be the best time to replace
> > liblopsub1 by liblopsub1t64?
> 
> You should just drop this hard-coded dependency on liblopsub1. This is
> what shlibs are for.

Done. Thanks for the suggestion.

> > * Do I need to do anything else to get this going besides merging
> > the branch and pushing it to the public repo?
> 
> No.  Please do not upload this change to unstable; these changes will be
> batch-uploaded to unstable at the appropriate time, *after* dpkg has been
> uploaded to unstable changing the default build flags.
> 
> Once the NMU has been uploaded to unstable, you are free to make further
> uploads to unstable incorporating this change.

The master branch of the public repo now contains your patch.

Best
Andre
-- 
Max Planck Institute for Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/


signature.asc
Description: PGP signature

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

[Yadd]

On 1/28/24 20:21, Steve Langasek wrote:

On Tue, Jan 23, 2024 at 08:32:18AM +0400, Yadd wrote:

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:



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 ?


We do not *know* that it's a false positive; we only know that we were
unable to analyze the header files under a-c-c to prove that the ABI is not
affected.

Patches to the check-armhf-time_t script at
https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/check-armhf-time_t?ref_type=heads
to quirk this package and allow its headers to be analyzed, or changes to
the source package to not ship uncompilable headers ("apt-file search
lib/strarray.h" returns no results), would both be welcome.

Thanks,


Hi,

is it possible to build a salsa-ci job to test this on i386 ?

Best regards,
Yadd

Bug#1051998: chromium: please to add support for riscv64

[Bo YU]

Version: 121.0.6167.85-1
Tags: patch

Sorry for the wrong version in the previous email.

Bo
On Wed, Jan 17, 2024 at 10:40 AM Bo YU  wrote:
>
> Version: 120.0.6099.216-1
> Tags: patch
>
> On Tue, Dec 19, 2023 at 10:03:18PM +0800, Bo YU wrote:
> >Version: 120.0.6099.109-1
> >Tags: patch
> >
> >Hi,
> >On Fri, Nov 24, 2023 at 11:52:01PM -0500, Daniel Richard G. wrote:
> >>On Thu, 2023 Nov 23 22:44-05:00, Bo YU wrote:
> >>>
> >>>But likely the Chromium developer has picked this now:
> >>>1. angle:
> >>>https://chromium-review.googlesource.com/c/angle/angle/+/5057086
> >>>2. base:
> >>>https://chromium-review.googlesource.com/c/chromium/src/+/5054184
> >>>3. sandbox:
> >>>https://chromium-review.googlesource.com/c/chromium/src/+/5056263
> >>>4. ffmpeg:
> >>>https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/5054185
> >>>
> >>>we have one dav1d to be left, but the developer told me he has did it.
> >
> >The good news is that angle and base support riscv64 both was merged by
> >chromium upstream.
> >
> >sandbox and ffmpeg support riscv64 was become more complicated: first
> >get approval from Chromium ATLs, see:
> >https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/5054185/comments/72ecb31a_56bf277d
> >
> >https://chromium-review.googlesource.com/c/chromium/src/+/4935120
> >
> >>
> >>Thanks Bo. It is good that the upstream is willing to accept patches for
> >>riscv64. I was worried that Google would not support the platform, in
> >>the same way that they do not support ppc64el.
> >
> >Thanks. CCing Yahan here also.:)
> >>
> >>I had considered adjusting the patches here so that they can be applied
> >>after the ppc64el patches. (There is no way that a conditional patch set
> >>would be accepted by Debian---all the patches have to apply together.)
> >>But if the patches are accepted by the upstream, then there is no need
> >>to adjust the patches for Debian.
>
> The good news is that I have adjusted these patches which can be applied
> after ppc64el.
>
> These patches did not change since previous update and I have descripted
> their status with upstream support. It seems very pretty that looks like
> got upstream support whole.
>
> BR,
> Bo
> >
> >hmm, this time I have dropped 2 patches which upstream has updated based
> >on 120. Later version we will remove more riscv64 patch here. But we all
> >know, the most two biggest blockers are sandbox and ffmpeg.
> >
> >Thanks your suggestions here.
> >
> >I can cost some time to try apply these patches together and feedback to
> >here also.
> >
> >>
> >
> >--
> >Regards,
> >--
> >  Bo YU
> >
>

Bug#1028408: Seems fixed

[Eugen Dedu]

Hi,

This email to say that it seems the bug seems to be fixed for me, I am 
using gnumeric 1.12.56-2+b1 now.


Cheers,
Eugen

Bug#1062655: O: libcoap3 -- C-Implementation of CoAP - libraries API version 3

[Carsten Schoenert]

Package: wnpp
Severity: normal
X-Debbugs-Cc: libco...@packages.debian.org
Control: affects -1 + src:libcoap3

I intend to orphan the libcoap3 package.

The package description is:
 Lightweight application-protocol for devices that are constrained their
 resources such as computing power, RF range, memory, bandwidth, or network
 packet sizes. This protocol, CoAP, is developed in the IETF working group
 "CoRE",  and was
 standardized in RFC 7252.
 .
 The libcoap library v3 has DTLS functionality included based on TLS
 functions provided by GnuTLS or OpenSSL with enhanced behavior to the
 previous API version.
 .
 This package contains the various libcoap libraries based on API v3 with
 and without DTLS functionality.

Bug#1061792: mini-httpd: Update of mini-httpd still breaks default web page if it is not index.html

[Alexander Foken]

Hi,

Result of my basic tests:

Update with existing /var/www/html/index.cgi works as expected 
(index.cgi as default page).


Install with existing /var/www/html/index.cgi works as expected 
(index.cgi as default page).


Install without /var/www/ works as expected (index.html copied, and as 
default page).


Install with empty /var/www/html/ works as expected (index.html copied, 
and as default page).



Testing error behaviour:

    rm -rf /var/www

    touch /var/www

    chmod 000 /var/www

    apt install /tmp/mini-httpd_1.30-8_amd64.deb

Fails as expected:

    Setting up mini-httpd (1.30-8) ...
    mkdir: cannot create directory ‘/var/www’: Not a directory
    dpkg: error processing package mini-httpd (--configure):
     installed mini-httpd package post-installation script subprocess 
returned error exit status 1

    Processing triggers for man-db (2.12.0-3) ...
    Errors were encountered while processing:
     mini-httpd
    E: Sub-process /usr/bin/dpkg returned an error code (1)

postinst checks look sane.


But while testing, I found an odd little detail:

    root@debian-sid:~# service mini-httpd status
     ...
    Process: 2536 ExecStart=/usr/sbin/mini_httpd -C 
/etc/mini-httpd.conf $DAEMON_OPTS -i /run/mini_httpd.pid (code=exited, 
status=0/SUCCESS)

     ...
     └─2538 /usr/sbin/mini_httpd -C /etc/mini-httpd.conf -C 
/etc/mini-httpd.conf -i /run/mini_httpd.pid

 ...

mini_httpd is invoked with a repeated -C /etc/mini-httpd.conf, or at 
least that is what systemd reports.


ps confirms:

    root@debian-sid:~# ps auxw | grep m[i]ni_httpd
    nobody  2538  0.0  0.1  10124  2980 ?    Ss   10:20 0:00 
/usr/sbin/mini_httpd -C /etc/mini-httpd.conf -C /etc/mini-httpd.conf -i 
/run/mini_httpd.pid

    root@debian-sid:~#

mini_httpd does not seem to care, so it's just cosmetic.

This happens because /usr/lib/systemd/system/mini-httpd.service invokes 
mini_httpd like this:


    EnvironmentFile=-/etc/default/mini-httpd
    ExecStart=/usr/sbin/mini_httpd -C /etc/mini-httpd.conf $DAEMON_OPTS 
-i /run/mini_httpd.pid


And /etc/default/mini-httpd contains:

    DAEMON_OPTS="-C /etc/mini-httpd.conf"


Compare with /etc/init.d/mini-httpd:

    ...
    if [ -f /etc/default/mini-httpd ]
    then
    . /etc/default/mini-httpd
    fi
    ...
    start() {
    echo -n "Starting $DESC: "
    start-stop-daemon --start --quiet --pidfile 
/var/run/$NAME.pid \

    --exec $DAEMON -- $DAEMON_OPTS
    echo "$NAME."
    }
    ...

The ExecStart line in the service file should not contain "-C 
/etc/mini-httpd.conf", as that option is already read from 
/etc/default/mini-httpd and replaces $DAEMON_OPTS in the ExecStart line.



Best regards

A.Foken


On 02.02.2024 00:03, Alexandru Mihail wrote:

Hi,


Hi,
Can you test this updated package? It's a lot closer to release form. I
cleaned up postinst as yesterday's build was a bit rushed. Thanks for
all the helpful observations !
I don't need any more full logs, just your usual tests that you did
before (fresh install, update, existing index.html, etc) as I've
removed the debug prints anyway.
Thanks for your contribution !

Cheers,
Alexandru Mihail


--
Alexander Foken
mailto:alexan...@foken.de

Bug#1057532: addtional information

[Vladimir Petko]

Dear Maintainers,

  Would it be possible to consider a merge request[1] that addresses this issue?

Best Regards,
 Vladimir.

 [1] https://salsa.debian.org/java-team/procyon/-/merge_requests/2

Bug#1062654: openjdk-17-jre-headless: Segfault in jspawnhelper

[Will Thompson]

Package: openjdk-17-jre-headless
Version: 17.0.10+7-1~deb12u1
Severity: important

In 17.0.10+7-1~deb12u1 from bookworm-security, jspawnhelper segfaults 
on startup.


$ /usr/lib/jvm/java-17-openjdk-amd64/lib/jspawnhelper
Segmentation fault

In real applications, this manifests as a failure to spawn subprocesses.

With 17.0.9+9-1~deb12u1 from bookworm, jspawnhelper shows an 
informational message when run directly.


$ /usr/lib/jvm/java-17-openjdk-amd64/lib/jspawnhelper
This command is not for general use and should only be run as the 
result of a call to

ProcessBuilder.start() or Runtime.exec() in a java application


-- 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/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openjdk-17-jdk-headless depends on:
ii  libc62.36-9+deb12u4
ii  openjdk-17-jre-headless  17.0.10+7-1~deb12u1
ii  zlib1g   1:1.2.13.dfsg-1

openjdk-17-jdk-headless recommends no packages.

Versions of packages openjdk-17-jdk-headless suggests:
pn  openjdk-17-demo
pn  openjdk-17-source  

Bug#1062555: liboprf: NMU diff for 64-bit time_t transition

[Joost van Baal-Ilić]

Hi,

I've had a look at the diff, lgtm.  I'd appreciate the upload to unstable in
due time.  Thanks a lot for your work, much appreciated!

Bye,

Joost


On Thu, Feb 01, 2024 at 10:57:49PM +, Steve Langasek wrote:
> Source: liboprf
> Version: 0.1+git20231001.0da3e2b-1
> Severity: serious
> Tags: patch pending
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
> 
> NOTICE: these changes must not be uploaded to unstable yet!
> 
> Dear maintainer,
> 
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> liboprf as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
> 
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
> 
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time.  Therefore I have prepared a 0-day NMU for liboprf
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
> 
> Please find the patch for this NMU attached.
> 
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.
> 
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)

> diff -Nru liboprf-0.1+git20231001.0da3e2b/debian/changelog 
> liboprf-0.1+git20231001.0da3e2b/debian/changelog
> --- liboprf-0.1+git20231001.0da3e2b/debian/changelog  2023-10-04 
> 14:07:26.0 +
> +++ liboprf-0.1+git20231001.0da3e2b/debian/changelog  2024-02-01 
> 17:51:25.0 +
> @@ -1,3 +1,10 @@
> +liboprf (0.1+git20231001.0da3e2b-1.1) experimental; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Rename libraries for 64-bit time_t transition.
> +
> + -- Steve Langasek   Thu, 01 Feb 2024 17:51:25 +
> +
>  liboprf (0.1+git20231001.0da3e2b-1) unstable; urgency=low
>  
>* New upstream git snapshot (thanks again Thorsten Alteholz for
> diff -Nru liboprf-0.1+git20231001.0da3e2b/debian/control 
> liboprf-0.1+git20231001.0da3e2b/debian/control
> --- liboprf-0.1+git20231001.0da3e2b/debian/control2023-10-04 
> 14:07:26.0 +
> +++ liboprf-0.1+git20231001.0da3e2b/debian/control2024-02-01 
> 17:51:25.0 +
> @@ -10,7 +10,10 @@
>  Vcs-Browser: https://salsa.debian.org/debian/liboprf
>  Vcs-Git: https://salsa.debian.org/debian/liboprf.git
>  
> -Package: liboprf0
> +Package: liboprf0t64
> +Provides: ${t64:Provides}
> +Replaces: liboprf0
> +Breaks: liboprf0 (<< ${source:Version})
>  Section: libs
>  Architecture: any
>  Multi-Arch: same
> diff -Nru liboprf-0.1+git20231001.0da3e2b/debian/liboprf0.install 
> liboprf-0.1+git20231001.0da3e2b/debian/liboprf0.install
> --- liboprf-0.1+git20231001.0da3e2b/debian/liboprf0.install   2023-10-04 
> 14:07:26.0 +
> +++ liboprf-0.1+git20231001.0da3e2b/debian/liboprf0.install   1970-01-01 
> 00:00:00.0 +
> @@ -1,2 +0,0 @@
> -#!/usr/bin/dh-exec
> -usr/lib/liboprf.so.0 => usr/lib/${DEB_HOST_MULTIARCH}/liboprf.so.0
> diff -Nru liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.install 
> liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.install
> --- liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.install
> 1970-01-01 00:00:00.0 +
> +++ liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.install
> 2023-10-04 14:07:26.0 +
> @@ -0,0 +1,2 @@
> +#!/usr/bin/dh-exec
> +usr/lib/liboprf.so.0 => usr/lib/${DEB_HOST_MULTIARCH}/liboprf.so.0
> diff -Nru 
> liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.lintian-overrides 
> liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.lintian-overrides
> --- liboprf-0.1+git20231001.0da3e2b/debian/liboprf0t64.lintian-overrides  
> 1970-01-01 00:00:00.0 +
> +++ 

Bug#1062533: chromium: Chromium doesn't launch in ARM64!

[Andres Salomon]

Running 'grep chromium /var/log/dpkg.log' (or /var/log/dpkg.log.1 if it 
was already rotated) should tell you what version it was upgraded from.


On 2/1/24 15:43, Sally A.haj wrote:

I don't remember exactly, but I believe it was the very recent before
the latest, because I usually do update the system every week or so.

Thank you.
On Thu, 2024-02-01 at 15:36 -0500, Andres Salomon wrote:



On 2/1/24 15:23, Sally A.haj wrote:
[...]


     * What outcome did you expect instead?
 Before the latest update, it was working just fine.
I am using Gnome/Wayland on Raspberry Pi 4 for a quite some times,
and this the first time I face an issue with chromium.



Thanks for the report. What exactly was the previous version that
worked
for you?




OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1062467: jcal: NMU diff for 64-bit time_t transition

[Lior Kaplan]

Hi Graham,

Thanks for the patch.

You're welcome to upload the NMU.

Kaplan

On Thu, Feb 1, 2024 at 6:15 PM Graham Inggs  wrote:

> Source: jcal
> Version: 0.4.1-2.1
> Severity: serious
> Tags: patch pending
> Justification: library ABI skew on upgrade
> User: debian-...@lists.debian.org
> Usertags: time-t
>
> Dear maintainer,
>
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> jcal as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
>
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
>
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time.  Therefore I have prepared a 0-day NMU for jcal
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
>
> Please find the patch for this NMU attached.
>
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if
> information
> becomes available that your package should not be included in the
> transition,
> there is time for us to amend the planned uploads.
>
>
>
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.5.0-15-generic (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect
>

Bug#1062653: gnome-network-displays crashes ("Trace/breakpoint trap") if local display selection cancelled

[Josh Triplett]

Package: gnome-network-displays
Version: 0.92.1-2
Severity: important
X-Debbugs-Cc: j...@joshtriplett.org

Steps to reproduce:

- Open gnome-network-displays
- Hit cancel on the prompt for whether to cast the whole screen, a
  window, or a virtual monitor
- Select a display to cast to
- gnome-network-displays crashes with "Trace/breakpoint trap"

Log messages:

(gnome-network-displays:9669): libportal-CRITICAL **: 01:04:19.778: 
xdp_session_get_streams: assertion 'XDP_IS_SESSION (session)' failed
(gnome-network-displays:9669): Gnd-ERROR **: 01:04:19.778: XDP session streams 
not found!


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

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

Versions of packages gnome-network-displays depends on:
ii  libadwaita-1-0  1.4.2-1+b1
ii  libavahi-common30.8-13+b1
ii  libavahi-gobject0   0.8-13+b1
ii  libc6   2.37-15
ii  libglib2.0-02.78.3-2
ii  libgstreamer-plugins-base1.0-0  1.22.8-1
ii  libgstreamer1.0-0   1.22.9-1+b1
ii  libgstrtspserver-1.0-0  1.22.8-1
ii  libgtk-4-1  4.12.5+ds-2
ii  libjson-glib-1.0-0  1.8.0-2
ii  libnm0  1.44.2-7
ii  libportal-gtk4-10.7.1-5
ii  libportal1  0.7.1-5
ii  libprotobuf-c1  1.4.1-1+b1
ii  libpulse-mainloop-glib0 16.1+dfsg1-3
ii  libpulse0   16.1+dfsg1-3
ii  libsoup-3.0-0   3.4.4-5
ii  network-manager 1.44.2-7
ii  wpasupplicant   2:2.10-21

gnome-network-displays recommends no packages.

gnome-network-displays suggests no packages.

-- no debconf information

Bug#1062205: Crashes desktop when attempting to make a network display

[Josh Triplett]

On Wed, Jan 31, 2024 at 08:23:22PM -0500, Jeremy Bícha wrote:
> On Wed, Jan 31, 2024 at 12:39 PM Josh Triplett  wrote:
> > I've attempted to use gnome-network-displays a few times, creating a
> > virtual display and sharing that display on a Chromecast on the local
> > network. When doing so, the entire GNOME desktop crashes, dropping me
> > into GDM to log back in.
> 
> I am uploading gnome-network-displays 0.92.1-1 now so try the new
> version. Both this version and the version you tried worked for me
> using the Chromecast protocol. Could you try to provide a bit more
> information?
> 
> What version of GNOME Shell are you using?

44.8-1

> Are you using X or Wayland?

Wayland.

> Is there anything unusual about your system you should mention?

Nothing that I can think of. Tested with latest sid as of today.

> If you are using Shell extensions, have you tried without them?

No, I'm not running any extensions.

> Does it still crash if you try while logged in as a new user?

Yes.

> Try looking through your systemd log with journatlctl to see if there
> are related errors.

I tried with the newly uploaded version, and managed to get some further
information.

Attempting to cast a window, or the whole screen, appears to work now,
but with 8-10 seconds of lag, making it unusable. (I'll report that as a
separate bug.)

Attempting to cast a virtual monitor still causes a crash. Here are logs
from that attempt:

Feb 02 00:28:36 o gnome-shell[1083]: Added virtual monitor Meta-0
...
Feb 02 00:28:37 o kernel: gnome-shell[1083]: segfault at 20 ip 7fececdf8f04 
sp 7ffc5ad85ed8 error 4 in 
libmutter-clutter-12.so.0.0.0[7fececda5000+9] likely on CPU 3 (core 4, 
socket 0)
Feb 02 00:28:37 o kernel: Code: c3 0f 1f 44 00 00 48 8d 15 e1 1a 04 00 48 8d 35 
d2 7e 05 00 48 8d 3d 4e f4 03 00 e9 d6 f2 fa ff 66 0f 1f 44 00 00 f3 0f 1e fa 
<48> 8b 47 20 c3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8b 47 28 c3 0f

Bug#1062652: Lags by 8-10 seconds

[Josh Triplett]

Package: gnome-network-displays
Version: 0.92.1-2
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

When casting either a window or the entire screen to a Chromecast, the
display on the Chromecast lags by 8-10 seconds behind the local display,
making it unusable for any interactive purposes. Concretely, moving the
mouse or typing in a terminal became visible 8-10 seconds later.


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

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

Versions of packages gnome-network-displays depends on:
ii  libadwaita-1-0  1.4.2-1+b1
ii  libavahi-common30.8-13+b1
ii  libavahi-gobject0   0.8-13+b1
ii  libc6   2.37-15
ii  libglib2.0-02.78.3-2
ii  libgstreamer-plugins-base1.0-0  1.22.8-1
ii  libgstreamer1.0-0   1.22.9-1+b1
ii  libgstrtspserver-1.0-0  1.22.8-1
ii  libgtk-4-1  4.12.5+ds-2
ii  libjson-glib-1.0-0  1.8.0-2
ii  libnm0  1.44.2-7
ii  libportal-gtk4-10.7.1-5
ii  libportal1  0.7.1-5
ii  libprotobuf-c1  1.4.1-1+b1
ii  libpulse-mainloop-glib0 16.1+dfsg1-3
ii  libpulse0   16.1+dfsg1-3
ii  libsoup-3.0-0   3.4.4-5
ii  network-manager 1.44.2-7
ii  wpasupplicant   2:2.10-21

gnome-network-displays recommends no packages.

gnome-network-displays suggests no packages.

-- no debconf information

Bug#1061835: Usage of six (Was: ragout fails its autopkg tests with Python 3.12)

[Alexandre Detiste]

Hi,

Removing the vendored 1.12 six.py
could do the trick.

Or maybe you'll also need to add a symlink to current 1.16 six.py in /usr/
. depending on how six.py is imported.

And the of course adding Depends: python3-six

Greetings

Le ven. 2 févr. 2024, 08:26, Andreas Tille  a écrit :

> Control: tags -1 upstream
> Control: forwarded -1 https://github.com/fenderglass/Ragout/issues/88
>
> Hi,
>
> the usage of six is quite hard-coded into ragout code as I just reported
> upstream[1].  I dout upstream will react quickly so we are possibly on
> our own to get rid of this.  Alexandre, it would be great if you could
> help out here.
>
> Kind regards
>Andreas.
>
> [1] https://github.com/fenderglass/Ragout/issues/88
>
> --
> http://fam-tille.de
>

Bug#1062651: libtickit: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: libtickit
Version: 0.4.3-1
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
libtickit as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for libtickit
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libtickit-0.4.3/debian/changelog libtickit-0.4.3/debian/changelog
--- libtickit-0.4.3/debian/changelog2023-02-04 17:27:05.0 +
+++ libtickit-0.4.3/debian/changelog2024-02-02 08:25:15.0 +
@@ -1,3 +1,10 @@
+libtickit (0.4.3-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Fri, 02 Feb 2024 08:25:15 +
+
 libtickit (0.4.3-1) unstable; urgency=medium
 
   * Update to new upstream version 0.4.3.
diff -Nru libtickit-0.4.3/debian/control libtickit-0.4.3/debian/control
--- libtickit-0.4.3/debian/control  2023-02-04 17:27:05.0 +
+++ libtickit-0.4.3/debian/control  2024-02-02 08:25:15.0 +
@@ -19,7 +19,7 @@
 Architecture: any
 Multi-Arch: same
 Depends:
- libtickit3 (= ${binary:Version}),
+ libtickit3t64 (= ${binary:Version}),
  libtermkey-dev,
  libunibilium-dev,
  ${misc:Depends}
@@ -56,7 +56,10 @@
  This package contains the header files and libraries needed for developing
  with libtickit.
 
-Package: libtickit3
+Package: libtickit3t64
+Provides: ${t64:Provides}
+Replaces: libtickit3
+Breaks: libtickit3 (<< ${source:Version})
 Pre-Depends: ${misc:Pre-Depends}
 Multi-Arch: same
 Architecture: any
diff -Nru libtickit-0.4.3/debian/libtickit3.install 
libtickit-0.4.3/debian/libtickit3.install
--- libtickit-0.4.3/debian/libtickit3.install   2023-02-04 17:27:05.0 
+
+++ libtickit-0.4.3/debian/libtickit3.install   1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-usr/lib/*/lib*.so.*
diff -Nru libtickit-0.4.3/debian/libtickit3.symbols 
libtickit-0.4.3/debian/libtickit3.symbols
--- libtickit-0.4.3/debian/libtickit3.symbols   2023-02-04 17:27:05.0 
+
+++ libtickit-0.4.3/debian/libtickit3.symbols   1970-01-01 00:00:00.0 
+
@@ -1,267 +0,0 @@
-libtickit.so.3 libtickit3 #MINVER#
-* Build-Depends-Package: libtickit-dev
- (optional|regex)"bindings" 0.3
- (optional|regex)"evloop" 0.4.2
- (optional|regex)"mockterm" 0.1
- (optional|regex)"termdrv" 0.4.3
- tickit_build@Base 0.4
- tickit_ctl_lookup@Base 0.4.3
- tickit_ctl_name@Base 0.4.3
- tickit_ctl_type@Base 0.4.3
- tickit_ctlname@Base 0.3
- tickit_ctltype@Base 0.3
- tickit_debug_enabled@Base 0.1
- tickit_debug_init@Base 0.1
- tickit_debug_logf@Base 0.1
- tickit_debug_open@Base 0.1
- tickit_debug_set_fh@Base 0.1
- tickit_debug_set_func@Base 0.1
- tickit_debug_vlogf@Base 0.1
- tickit_get_rootwin@Base 0.2
- tickit_get_term@Base 0.2
- tickit_getctl_int@Base 0.3
- tickit_lookup_ctl@Base 0.3
- tickit_new_for_term@Base 0.2
- tickit_new_stdio@Base 0.2
- tickit_new_stdtty@Base 0.4
- tickit_pen_attrname@Base 0.1
- tickit_pen_attrtype@Base 0.1
- tickit_pen_bind_event@Base 0.1
- tickit_pen_clear@Base 0.1
- tickit_pen_clear_attr@Base 0.1
- tickit_pen_clone@Base 0.1
- tickit_pen_copy@Base 

Bug#1062650: libterralib: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: libterralib
Version: 4.3.0+dfsg.2-12.1
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
libterralib as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for libterralib
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libterralib-4.3.0+dfsg.2/debian/changelog 
libterralib-4.3.0+dfsg.2/debian/changelog
--- libterralib-4.3.0+dfsg.2/debian/changelog   2019-08-26 17:28:30.0 
+
+++ libterralib-4.3.0+dfsg.2/debian/changelog   2024-02-02 08:13:47.0 
+
@@ -1,3 +1,10 @@
+libterralib (4.3.0+dfsg.2-12.2) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Fri, 02 Feb 2024 08:13:47 +
+
 libterralib (4.3.0+dfsg.2-12.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libterralib-4.3.0+dfsg.2/debian/control 
libterralib-4.3.0+dfsg.2/debian/control
--- libterralib-4.3.0+dfsg.2/debian/control 2019-08-26 17:27:36.0 
+
+++ libterralib-4.3.0+dfsg.2/debian/control 2024-02-02 08:13:46.0 
+
@@ -21,7 +21,7 @@
 Architecture: any
 Multi-Arch: same
 Section: libdevel
-Depends: libterralib3 (= ${binary:Version}),
+Depends: libterralib3t64 (= ${binary:Version}),
  ${misc:Depends}
 Suggests: libterralib-doc
 Description: C++ library for Geographical Information Systems -- development 
package
@@ -37,7 +37,8 @@
  .
  This package contains development files for terralib.
 
-Package: libterralib3
+Package: libterralib3t64
+Provides: ${t64:Provides}
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends},
@@ -45,9 +46,9 @@
 Pre-Depends: ${misc:Pre-Depends}
 Suggests: libterralib-doc
 Conflicts: libterralib1c2a,
-Replaces: libterralib1c2a,
+Replaces: libterralib3, libterralib1c2a,
   libterralib (<< 4.3.0+dfsg.1-3~)
-Breaks: libterralib (<< 4.3.0+dfsg.1-3~)
+Breaks: libterralib3 (<< ${source:Version}), libterralib (<< 4.3.0+dfsg.1-3~)
 Description: C++ library for Geographical Information Systems
  TerraLib enables quick development of custom-built geographical applications
  using spatial databases. As a research tool, TerraLib  is aimed at providing a
@@ -63,7 +64,7 @@
 Architecture: all
 Section: doc
 Depends: ${misc:Depends}
-Recommends: libterralib3
+Recommends: libterralib3t64
 Replaces: libterralib3-doc
 Description: C++ library for Geographical Information Systems -- documentation 
package
  TerraLib enables quick development of custom-built geographical applications
diff -Nru libterralib-4.3.0+dfsg.2/debian/libterralib3.install.in 
libterralib-4.3.0+dfsg.2/debian/libterralib3.install.in
--- libterralib-4.3.0+dfsg.2/debian/libterralib3.install.in 2019-08-26 
12:07:00.0 +
+++ libterralib-4.3.0+dfsg.2/debian/libterralib3.install.in 1970-01-01 
00:00:00.0 +
@@ -1,11 +0,0 @@
-Release/linux-g++/libterralib.so.*  usr/lib/@DEB_HOST_MULTIARCH@
-Release/linux-g++/libterralibpdi.so.*  usr/lib/@DEB_HOST_MULTIARCH@
-Release/linux-g++/libte_utils.so.*  usr/lib/@DEB_HOST_MULTIARCH@

Bug#1062649: libtecla: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: libtecla
Version: 1.6.3-3
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
libtecla as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for libtecla
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libtecla-1.6.3/debian/changelog libtecla-1.6.3/debian/changelog
--- libtecla-1.6.3/debian/changelog 2021-10-18 07:23:41.0 +
+++ libtecla-1.6.3/debian/changelog 2024-02-02 08:13:00.0 +
@@ -1,3 +1,10 @@
+libtecla (1.6.3-3.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Fri, 02 Feb 2024 08:13:00 +
+
 libtecla (1.6.3-3) unstable; urgency=medium
 
   * Fix watch file
diff -Nru libtecla-1.6.3/debian/control libtecla-1.6.3/debian/control
--- libtecla-1.6.3/debian/control   2021-10-18 07:23:41.0 +
+++ libtecla-1.6.3/debian/control   2024-02-02 08:12:59.0 +
@@ -15,7 +15,7 @@
 Package: libtecla-dev
 Architecture: any
 Section: libdevel
-Depends: libtecla1 (= ${binary:Version}),
+Depends: libtecla1t64 (= ${binary:Version}),
  ${misc:Depends}
 Multi-Arch: same
 Description: interactive command line editing facilities (development)
@@ -44,7 +44,10 @@
  This package contains the development files and documentation for
  developing applications using the tecla library.
 
-Package: libtecla1
+Package: libtecla1t64
+Provides: ${t64:Provides}
+Replaces: libtecla1
+Breaks: libtecla1 (<< ${source:Version})
 Architecture: any
 Section: libs
 Depends: ${shlibs:Depends},
diff -Nru libtecla-1.6.3/debian/libtecla1t64.lintian-overrides 
libtecla-1.6.3/debian/libtecla1t64.lintian-overrides
--- libtecla-1.6.3/debian/libtecla1t64.lintian-overrides1970-01-01 
00:00:00.0 +
+++ libtecla-1.6.3/debian/libtecla1t64.lintian-overrides2024-02-02 
08:12:59.0 +
@@ -0,0 +1 @@
+libtecla1t64: package-name-doesnt-match-sonames libtecla1

Bug#1062648: libtcod: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: libtcod
Version: 1.18.1+dfsg-1
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
libtcod as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for libtcod
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libtcod-1.18.1+dfsg/debian/changelog 
libtcod-1.18.1+dfsg/debian/changelog
--- libtcod-1.18.1+dfsg/debian/changelog2021-09-11 16:03:34.0 
+
+++ libtcod-1.18.1+dfsg/debian/changelog2024-02-02 08:11:24.0 
+
@@ -1,3 +1,10 @@
+libtcod (1.18.1+dfsg-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Fri, 02 Feb 2024 08:11:24 +
+
 libtcod (1.18.1+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libtcod-1.18.1+dfsg/debian/control libtcod-1.18.1+dfsg/debian/control
--- libtcod-1.18.1+dfsg/debian/control  2021-09-11 16:03:34.0 +
+++ libtcod-1.18.1+dfsg/debian/control  2024-02-02 08:11:23.0 +
@@ -12,7 +12,10 @@
 Vcs-Git: https://salsa.debian.org/wolff/libtcod.git
 Vcs-Browser: https://salsa.debian.org/wolff/libtcod
 
-Package: libtcod1
+Package: libtcod1t64
+Provides: ${t64:Provides}
+Replaces: libtcod1
+Breaks: libtcod1 (<< ${source:Version})
 Architecture: linux-any
 Multi-Arch: same
 Depends: ${misc:Depends},
@@ -30,7 +33,7 @@
 Architecture: linux-any
 Multi-Arch: same
 Section: libdevel
-Depends: libtcod1 (= ${binary:Version}),
+Depends: libtcod1t64 (= ${binary:Version}),
  libsdl2-dev,
  ${misc:Depends}
 Description: development files for the libtcod roguelike library
diff -Nru libtcod-1.18.1+dfsg/debian/libtcod1.install 
libtcod-1.18.1+dfsg/debian/libtcod1.install
--- libtcod-1.18.1+dfsg/debian/libtcod1.install 2021-09-11 16:03:34.0 
+
+++ libtcod-1.18.1+dfsg/debian/libtcod1.install 1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-usr/lib/*/*.so.*
diff -Nru libtcod-1.18.1+dfsg/debian/libtcod1t64.install 
libtcod-1.18.1+dfsg/debian/libtcod1t64.install
--- libtcod-1.18.1+dfsg/debian/libtcod1t64.install  1970-01-01 
00:00:00.0 +
+++ libtcod-1.18.1+dfsg/debian/libtcod1t64.install  2021-09-11 
16:03:34.0 +
@@ -0,0 +1 @@
+usr/lib/*/*.so.*
diff -Nru libtcod-1.18.1+dfsg/debian/libtcod1t64.lintian-overrides 
libtcod-1.18.1+dfsg/debian/libtcod1t64.lintian-overrides
--- libtcod-1.18.1+dfsg/debian/libtcod1t64.lintian-overrides1970-01-01 
00:00:00.0 +
+++ libtcod-1.18.1+dfsg/debian/libtcod1t64.lintian-overrides2024-02-02 
08:11:23.0 +
@@ -0,0 +1 @@
+libtcod1t64: package-name-doesnt-match-sonames libtcod1

Bug#1062647: libtar: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: libtar
Version: 1.2.20-8
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
libtar as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for libtar
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



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

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libtar-1.2.20/debian/changelog libtar-1.2.20/debian/changelog
--- libtar-1.2.20/debian/changelog  2019-08-25 16:49:41.0 +
+++ libtar-1.2.20/debian/changelog  2024-02-02 08:10:49.0 +
@@ -1,3 +1,10 @@
+libtar (1.2.20-8.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Fri, 02 Feb 2024 08:10:49 +
+
 libtar (1.2.20-8) unstable; urgency=low
 
   * Convert debian/rules to modern dh style and upgrade to compat level
diff -Nru libtar-1.2.20/debian/control libtar-1.2.20/debian/control
--- libtar-1.2.20/debian/control2019-08-25 16:49:41.0 +
+++ libtar-1.2.20/debian/control2024-02-02 08:10:48.0 +
@@ -13,18 +13,18 @@
 Architecture: any
 Multi-Arch: same
 Section: libdevel
-Depends: libtar0 (= ${binary:Version}), ${misc:Depends}
+Depends: libtar0t64 (= ${binary:Version}), ${misc:Depends}
 Description: C library for manipulating tar archives (development files)
  Contains static library, headers, example code and development manpages
  for libtar
 
-Package: libtar0
+Package: libtar0t64
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Replaces: libtar
-Breaks: libtar
-Provides: libtar
+Replaces: libtar0, libtar
+Breaks: libtar0 (<< ${source:Version}), libtar
+Provides: ${t64:Provides}, libtar
 Description: C library for manipulating tar archives
  libtar allows programs to create, extract and test tar archives.
  It supports both the strict POSIX tar format and many of the commonly-used
diff -Nru libtar-1.2.20/debian/libtar0.install 
libtar-1.2.20/debian/libtar0.install
--- libtar-1.2.20/debian/libtar0.install2019-08-25 16:25:54.0 
+
+++ libtar-1.2.20/debian/libtar0.install1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-usr/lib/*/lib*.so.*
diff -Nru libtar-1.2.20/debian/libtar0t64.install 
libtar-1.2.20/debian/libtar0t64.install
--- libtar-1.2.20/debian/libtar0t64.install 1970-01-01 00:00:00.0 
+
+++ libtar-1.2.20/debian/libtar0t64.install 2019-08-25 16:25:54.0 
+
@@ -0,0 +1 @@
+usr/lib/*/lib*.so.*
diff -Nru libtar-1.2.20/debian/libtar0t64.lintian-overrides 
libtar-1.2.20/debian/libtar0t64.lintian-overrides
--- libtar-1.2.20/debian/libtar0t64.lintian-overrides   1970-01-01 
00:00:00.0 +
+++ libtar-1.2.20/debian/libtar0t64.lintian-overrides   2024-02-02 
08:10:48.0 +
@@ -0,0 +1 @@
+libtar0t64: package-name-doesnt-match-sonames libtar0