Bug#1066059: libreswan: CVE-2024-2357

[Daniel Kahn Gillmor]

On https://bugs.debian.org/1066059, Salvatore Bonaccorso wrote:
> The following vulnerability was published for libreswan.
>
> CVE-2024-2357[0]:
> | The Libreswan Project was notified of an issue causing libreswan to
> | restart under some IKEv2 retransmit scenarios when a connection is
> | configured to use PreSharedKeys (authby=secret) and the connection
> | cannot find a matching configured secret. When such a connection is
> | automatically added on startup using the auto= keyword, it can cause
> | repeated crashes leading to a Denial of Service.

I'm attaching a proposed debdiff for libreswan for bookworm, from the
current 4.10-2+deb12u1 to 4.10-2+deb12u3 (4.10-2+deb12u2 appears to have
never made it to publication, which is likely my fault).  This is also
pushed to the debian/bookworm branch at
https://salsa.debian.org/debian/libreswan.

In addition to resolving CVE-2024-2357, this debdiff rolls up three
other low-priority CVEs as well, using changesets from upstream.

If anyone from the security team could confirm this, i would be happy to
go ahead with the upload to bookworm-security.

Regards,

   --dkg

diff --git a/debian/changelog b/debian/changelog
index f2851b483e..c51e93d091 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+libreswan (4.10-2+deb12u3) bookworm-security; urgency=medium
+
+  * Fix CVE 2024-2357 (Closes: #1066059)
+
+ -- Daniel Kahn Gillmor   Tue, 12 Mar 2024 00:14:33 -0400
+
+libreswan (4.10-2+deb12u2) bookworm-security; urgency=medium
+
+  * Fix CVE-2023-38710
+  * Fix CVE-2023-38711
+  * Fix CVE-2023-38712
+
+ -- Daniel Kahn Gillmor   Mon, 07 Aug 2023 17:46:29 -0400
+
 libreswan (4.10-2+deb12u1) bookworm; urgency=medium
 
   * Fix CVE-2023-30570 (Closes: #1035542)
diff --git a/debian/patches/0006-CVE-2023-38710-Invalid-IKEv2-REKEY-proposal-causes-re.patch b/debian/patches/0006-CVE-2023-38710-Invalid-IKEv2-REKEY-proposal-causes-re.patch
new file mode 100644
index 00..f930a5761c
--- /dev/null
+++ b/debian/patches/0006-CVE-2023-38710-Invalid-IKEv2-REKEY-proposal-causes-re.patch
@@ -0,0 +1,261 @@
+From: Daniel Kahn Gillmor 
+Date: Mon, 7 Aug 2023 17:40:21 -0400
+Subject: CVE-2023-38710: Invalid IKEv2 REKEY proposal causes restart
+
+This alert (and any updates) are available at the following URLs:
+https://libreswan.org/security/CVE-2023-38710/
+
+The Libreswan Project was notified by "X1AOxiang" of an issue with receiving
+a malformed IKEv2 REKEY packet would cause a crash and restart of the libreswan
+pluto daemon. When sent continuously, this could lead to a denial of service attack.
+
+Severity: Medium
+Vulnerable versions : libreswan 3.20 - 4.11
+Not vulnerable  : libreswan 3.0 - 3.19, 4.12+
+
+Vulnerability information
+=
+When an IKEv2 Child SA REKEY packet contains an invalid IPsec protocol ID number
+of 0 or 1, an error notify INVALID_SPI is sent back. The notify payload's
+protocol ID is copied from the incoming packet, but the code that verifies
+outgoing packets fails an assertion that the protocol ID must be ESP (2) or AH(3)
+and causes the pluto daemon to crash and restart.
+
+Exploitation
+
+IKEv2 REKEY requests are only processed when received from authenticated peers,
+limiting the scope of possible attackers to peers who have successfully
+authenticated.
+
+Workaround
+==
+There is no workarounds, please apply the supplied patches or upgrade.
+
+History
+===
+* 2017 Vulnerable code introduced in libreswan 3.20
+* 2023-06-07 Report received via Red Hat
+* 2023-07-19 Prerelease of CVE notification and patches to support customers
+* 2023-08-04 Release of patch and libreswan 4.12
+
+Credits
+===
+This vulnerability was found and reported by X1AOxiang to Red Hat. Thanks to
+Daiki Ueno for contacting the Libreswan Project.
+---
+ programs/pluto/ikev2_create_child_sa.c | 149 -
+ 1 file changed, 89 insertions(+), 60 deletions(-)
+
+diff --git a/programs/pluto/ikev2_create_child_sa.c b/programs/pluto/ikev2_create_child_sa.c
+index 9e29032..e4bf588 100644
+--- a/programs/pluto/ikev2_create_child_sa.c
 b/programs/pluto/ikev2_create_child_sa.c
+@@ -175,80 +175,102 @@ static void emancipate_larval_ike_sa(struct ike_sa *old_ike, struct child_sa *ne
+ 	release_whack(new_ike->sa.st_logger, HERE);
+ }
+ 
+-static struct child_sa *find_v2N_REKEY_SA_child(struct ike_sa *ike,
+-		struct msg_digest *md)
++/*
++ * Find the Child SA identified by the v2N_REKEY_SA payload.
++ *
++ * FALSE: payload corrupt; caller should respond with the fatal
++ * v2N_INVALID_SYNTAX.
++ *
++ * TRUE, CHILD==NULL: payload ok but no matching Child SA was
++ * found. The v2N_CHILD_SA_NOT_FOUND response already recorded using
++ * information extracted from the rekey notify payload.
++ *
++ * TRUE, CHILD!=NULL: payload ok, matching Child SA found.
++ */
++
++static bool find_v2N_REKEY_SA_child(struct ike_sa *ike,
++struct msg_digest *md,
++struct child_sa **child)
+ 

Bug#1066077: usr-is-merged fails to install on a /usr-merged system

[David W]

Package: usr-is-merged
Version: 39

When attempting to install, I received the following message:

**
*
* The usr-is-merged package cannot be installed because this system does
* not have a merged /usr.
*
* Please install the usrmerge package to convert this system to merged-/usr.
*
* For more information please read https://wiki.debian.org/UsrMerge.
*
**

This despite the fact that I have version 39 of usrmerge installed, and the
symlinks were indeed set up correctly.

In the end, it turned out to be because /usr itself was a symlink, and
although this causes no issues for either the merging process or any
running software, since the check is using "readlink -f" it erroneously
fails.

-- 
=D ave

Bug#1061371: gcc-14 ftbfs on loong64

[Bo YU]

Hi!

On Tue, Mar 12, 2024 at 11:03 AM zhangdandan  wrote:
>
> Hi,
>   Thanks for your feedback on loong64's compilation errors.
>
> > > Package: src:gcc-14
> > > Version: 14-20240121-1
> > > Severity: important
> > > Tags: sid trixie ftbfs
> > > X-Debbugs-CC: debian-loonga...@lists.debian.org
> > >
> > > gcc-14 ftbfs on loong64:
> > >...
> >
> > The remaining build failure is now:
> >
> > https://buildd.debian.org/status/fetch.php?pkg=gcc-14=loong64=14-20240303-1=1709485913=0
> >
> > ...
> > dh_installdirs -plibgcc-s1 usr/share/doc/libgcc-s1 
> > usr/lib/loongarch64-linux-gnu
> > mv debian/tmp/usr/lib/loongarch64-linux-gnu/libgcc_s.so.1 
> > debian/libgcc-s1/usr/lib/loongarch64-linux-gnu/.
> > mv: cannot stat 'debian/tmp/usr/lib/loongarch64-linux-gnu/libgcc_s.so.1': 
> > No such file or directory
> > make[1]: *** [debian/rules.d/binary-libgcc.mk:291: 
> > stamps/08-binary-stamp-libgcc] Error 1
>
> - For the compilation error raised by Matthias Klose.
> It is because the linux header file linux-libc-dev lacks loong64 support.
> The Debian kernel-team has merged the loong64's patch, please see 
> https://salsa.debian.org/kernel-team/linux/-/merge_requests/879.
>
> - I have reproduced the gcc-14 compilation error locally from Adrian Bunk.
> The compilation error is consistent with the feedback from Adrian Bunk.
> For gcc-14, the loong64's multilib modification is not included in 
> gcc-multilib-multiarch.
> Please consider the following patch. If you have any questions, you can 
> contact me at any time.
> ```
> --- a/src/gcc/config/loongarch/t-linux
> +++ b/src/gcc/config/loongarch/t-linux
> @@ -16,9 +16,9 @@
>  # along with GCC; see the file COPYING3.  If not see
>  # .
>
> -MULTIOSDIR_lp64d := ../lib64$(call if_multiarch,:loongarch64-linux-gnu)
> -MULTIOSDIR_lp64f := ../lib64/f32$(call 
> if_multiarch,:loongarch64-linux-gnuf32)
> -MULTIOSDIR_lp64s := ../lib64/sf$(call if_multiarch,:loongarch64-linux-gnusf)
> +MULTIOSDIR_lp64d := ../lib$(call if_multiarch,:loongarch64-linux-gnu)
> +MULTIOSDIR_lp64f := ../lib/f32$(call if_multiarch,:loongarch64-linux-gnuf32)
> +MULTIOSDIR_lp64s := ../lib/sf$(call if_multiarch,:loongarch64-linux-gnusf)
>
>  # Don't define MULTILIB_OSDIRNAMES if multilib is disabled.
>  ifeq ($(filter LA_DISABLE_MULTILIB,$(tm_defines)),)
> ```

Maybe debdiff should be attached here for GCC maintainer with conveniently.

BR,
Bo
>
> BTW, the gcc-14 source package was compiled successfully on my local loong64 
> rootfs environment, for examples,
> ```
> ..
> dh_installdirs -plibgcc-s1 usr/share/doc/libgcc-s1 
> usr/lib/loongarch64-linux-gnu
> mv debian/tmp/usr/lib/loongarch64-linux-gnu/libgcc_s.so.1 
> debian/libgcc-s1/usr/lib/loongarch64-linux-gnu/.
> debian/dh_doclink -plibgcc-s1 gcc-14-base
> ..
> dpkg-deb: building package 'libgfortran-14-dev' in 
> '../libgfortran-14-dev_14-20240201-3_loong64.deb'.
> dpkg-deb: building package 'g++-14-loongarch64-linux-gnu' in 
> '../g++-14-loongarch64-linux-gnu_14-20240201-3_loong64.deb'.
> dpkg-deb: building package 'gccrs-14-loongarch64-linux-gnu-dbgsym' in 
> '../gccrs-14-loongarch64-linux-gnu-dbgsym_14-20240201-3_loong64.deb'.
> dpkg-deb: building package 'gcc-14-loongarch64-linux-gnu-dbgsym' in 
> '../gcc-14-loongarch64-linux-gnu-dbgsym_14-20240201-3_loong64.deb'.
> ..
> make[1]: Leaving directory '/home/zdd/gcc-14/gcc-14-14-20240201'
>  dpkg-genbuildinfo --build=binary -O../gcc-14_14-20240201-3_loong64.buildinfo
>  dpkg-genchanges --build=binary -O../gcc-14_14-20240201-3_loong64.changes
> ```
>
> thanks,
> Dandan Zhang
>

Bug#1063441: NO EFI entry created when installing with weekly Mate Live CD

[Brandon Werner]

I just discovered that a MR is already open that will fix this bug and wanted 
to add the link here.
https://salsa.debian.org/live-team/calamares-settings-debian/-/merge_requests/3
It would be great to get this merged to fix live installs of testing. Thanks.
Brandon

Bug#1066076: Current loglevel in system.conf is too verbose by default

[Neal]

Package: systemd
Version: 255.4-1
Severity: minor
File: /etc/systemd/system.conf
X-Debbugs-Cc: tombrown9...@gmail.com

Dear Maintainer,

Current kernel message verbosity during Debian boot significantly hampers the
ability to identify critical system alerts, with important messages quickly
lost in the noise. This situation presents challenges for both new and
experienced users; newcomers may find the volume of information daunting and
misinterpret its importance, while seasoned users may struggle to quickly
pinpoint vital warnings or errors. To address these concerns, it is proposed
that the default kernel log level be set to "Warning." This adjustment will
streamline the boot process, making critical messages more visible and less
likely to be overlooked. Such a change not only aids in diagnosing and
troubleshooting by highlighting essential alerts but also enhances the boot
experience for all users by focusing on the most pertinent information.

Thanks


-- Package-specific info:

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

Kernel: Linux 6.6.15-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
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  libacl12.3.2-1
ii  libapparmor1   3.0.12-1+b2
ii  libaudit1  1:3.1.2-2
ii  libblkid1  2.39.3-6
ii  libc6  2.37-15
ii  libcap21:2.66-5
ii  libcryptsetup122:2.6.1-6+b1
ii  libfdisk1  2.39.3-6
ii  libgcrypt201.10.3-2
ii  libkmod2   31+20240202-2
ii  liblz4-1   1.9.4-1+b2
ii  liblzma5   5.6.0-0.2
ii  libmount1  2.39.3-6
ii  libpam0g   1.5.2-9.1+b1
ii  libseccomp22.5.5-1
ii  libselinux13.5-2
ii  libssl33.1.5-1
ii  libsystemd-shared  255.4-1
ii  libsystemd0255.4-1
ii  libzstd1   1.5.5+dfsg2-2
ii  mount  2.39.3-6
ii  systemd-dev255.4-1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.10-4
ii  systemd-timesyncd [time-daemon]  255.4-1

Versions of packages systemd suggests:
ii  libfido2-11.14.0-1
ii  libip4tc2 1.8.10-3
ii  libp11-kit0   0.25.3-4
ii  libqrencode4  4.1.1-1+b1
ii  libtss2-esys-3.0.2-0  4.0.1-7
ii  libtss2-mu-4.0.1-04.0.1-7
pn  libtss2-rc0   
ii  libtss2-tcti-device0  4.0.1-7
ii  polkitd   124-1
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-4
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 255.4-1
ii  libpam-systemd 255.4-1
ii  udev   255.4-1

-- Configuration Files:
/etc/systemd/system.conf changed [not included]

-- no debconf information

Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test

[Antonio Russo]

Dear maintainer,

This bug is (apparently?) currently preventing the amd64 build of 1.20.1-6.  I
apologize if this is already understood (by the way, is there somewhere on [1]
or elsewhere to see if the build is being retried?).  I'm also assuming I am not
authorized to "give back" and trigger another build attempt.

So, I'm asking for someone to please "give back" the build to the buildds, so 
that
we can spin the roulette wheel and hopefully get a buildd with an ipv4 address.

Best,
Antonio Russo

[1] https://tracker.debian.org/pkg/krb5

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066075: RM: lua-nvim -- ROM; unused

[James McCoy]

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

The neovim package was the only user of this package (to run tests at
build time), but as of the latest neovim upload it is no longer using
it.

Bug#1061371: gcc-14 ftbfs on loong64

[zhangdandan]

Hi,
  Thanks for your feedback on loong64's compilation errors.

> > Package: src:gcc-14
> > Version: 14-20240121-1
> > Severity: important
> > Tags: sid trixie ftbfs
> > X-Debbugs-CC: debian-loonga...@lists.debian.org
> >
> > gcc-14 ftbfs on loong64:
> >...
>
> The remaining build failure is now:
>
> 
https://buildd.debian.org/status/fetch.php?pkg=gcc-14=loong64=14-20240303-1=1709485913=0

>
> ...
> dh_installdirs -plibgcc-s1 usr/share/doc/libgcc-s1 
usr/lib/loongarch64-linux-gnu
> mv debian/tmp/usr/lib/loongarch64-linux-gnu/libgcc_s.so.1 
debian/libgcc-s1/usr/lib/loongarch64-linux-gnu/.
> mv: cannot stat 
'debian/tmp/usr/lib/loongarch64-linux-gnu/libgcc_s.so.1': No such file 
or directory
> make[1]: *** [debian/rules.d/binary-libgcc.mk:291: 
stamps/08-binary-stamp-libgcc] Error 1


- For the compilation error raised by Matthias Klose.
It is because the linux header file linux-libc-dev lacks loong64 support.
The Debian kernel-team has merged the loong64's patch, please see 
https://salsa.debian.org/kernel-team/linux/-/merge_requests/879.


- I have reproduced the gcc-14 compilation error locally from Adrian Bunk.
The compilation error is consistent with the feedback from Adrian Bunk.
For gcc-14, the loong64's multilib modification is not included in 
gcc-multilib-multiarch.
Please consider the following patch. If you have any questions, you can 
contact me at any time.

```
--- a/src/gcc/config/loongarch/t-linux
+++ b/src/gcc/config/loongarch/t-linux
@@ -16,9 +16,9 @@
 # along with GCC; see the file COPYING3.  If not see
 # .

-MULTIOSDIR_lp64d := ../lib64$(call if_multiarch,:loongarch64-linux-gnu)
-MULTIOSDIR_lp64f := ../lib64/f32$(call 
if_multiarch,:loongarch64-linux-gnuf32)
-MULTIOSDIR_lp64s := ../lib64/sf$(call 
if_multiarch,:loongarch64-linux-gnusf)

+MULTIOSDIR_lp64d := ../lib$(call if_multiarch,:loongarch64-linux-gnu)
+MULTIOSDIR_lp64f := ../lib/f32$(call 
if_multiarch,:loongarch64-linux-gnuf32)

+MULTIOSDIR_lp64s := ../lib/sf$(call if_multiarch,:loongarch64-linux-gnusf)

 # Don't define MULTILIB_OSDIRNAMES if multilib is disabled.
 ifeq ($(filter LA_DISABLE_MULTILIB,$(tm_defines)),)
```

BTW, the gcc-14 source package was compiled successfully on my local 
loong64 rootfs environment, for examples,

```
..
dh_installdirs -plibgcc-s1 usr/share/doc/libgcc-s1 
usr/lib/loongarch64-linux-gnu
mv debian/tmp/usr/lib/loongarch64-linux-gnu/libgcc_s.so.1 
debian/libgcc-s1/usr/lib/loongarch64-linux-gnu/.

debian/dh_doclink -plibgcc-s1 gcc-14-base
..
dpkg-deb: building package 'libgfortran-14-dev' in 
'../libgfortran-14-dev_14-20240201-3_loong64.deb'.
dpkg-deb: building package 'g++-14-loongarch64-linux-gnu' in 
'../g++-14-loongarch64-linux-gnu_14-20240201-3_loong64.deb'.
dpkg-deb: building package 'gccrs-14-loongarch64-linux-gnu-dbgsym' in 
'../gccrs-14-loongarch64-linux-gnu-dbgsym_14-20240201-3_loong64.deb'.
dpkg-deb: building package 'gcc-14-loongarch64-linux-gnu-dbgsym' in 
'../gcc-14-loongarch64-linux-gnu-dbgsym_14-20240201-3_loong64.deb'.

..
make[1]: Leaving directory '/home/zdd/gcc-14/gcc-14-14-20240201'
 dpkg-genbuildinfo --build=binary 
-O../gcc-14_14-20240201-3_loong64.buildinfo

 dpkg-genchanges --build=binary -O../gcc-14_14-20240201-3_loong64.changes
```

thanks,
Dandan Zhang

Bug#1065787: 64-bit time_t transition: cargo needs manual intervention

[Steven Robbins]

Peter convincingly argues (details in bug) that manual intervention is needed 
for package "cargo":

On Sun, 10 Mar 2024 00:48:32 + Peter Michael Green  
wrote:

> This will require manual intervention to resolve, either through
> cross-building or through building manually in a hacked-up build
> environment.
> 
> I've certainly seen mention of rustc on #debian-devel recently,
> so I think the people handling the time_t transition are already
> aware of this.

I'm wondering if the time_t people or the rust people could comment on this?  
This build failure has a surprisingly (to me) long chain of casualties.  Is 
this an easy thing to fix or is going to take weeks?

Thanks,
-Steve


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

Bug#986936: ITA: libcdk5 -- C-based curses widget library

[Steven Robbins]

On Wednesday, March 6, 2024 7:42:55 P.M. CDT Steven Robbins wrote:
> On Tue, 19 Jul 2022 13:02:08 +0200 "Jose G. López" 
 
> > I intend to adopt it as I worked on it before but never uploaded it as
> > maintainer in Debian. I have special affection for it because it was
> > one of the first packages I worked with and learned.
> 
> Just wondering if you still plan to work on curses.  If so: it's failing to
> build on some platforms, so could really use help now!  :-)

This package has become somewhat important to me, since its failure to build 
is affecting packages that I maintain.  

I have worked on packaging the latest upstream version and it builds for me 
locally.  I'm not really wanting another package to maintain so if you can 
update this in the next short while, just let me know.  Otherwise, I can work 
on putting the new version into the archive.  Happy to co-maintain, or 
whatever you think best.

Regards,
-Steve



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

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Wesley Schwengle]

On Mon, Mar 11, 2024 at 11:32:24PM +0100, Miguel Angel Rojas wrote:
> > I see. It looks like `apt upgrade ' behaves as `apt install
> > '. Which (to me) is unexpected behaviour, as the man page is
> quite
> >clear on its behaviour (man 8 apt-get):
> 
> Well, clearly it shouldn’t. To begin with, “apt install” should mark a
> package as manual installed while “apt upgrade” shouldn’t (my assumption).
> And you’re right that “apt install” can remove a package if needed to
> satisfy dependencies.
> 
> On top of that, documentation clearly states that “apt upgrade” should not
> remove any package, but it does when you specify an individual package to
> upgrade.
> 
> If this is not the expected behavior, maybe this is a bug (unless I am
> missing something here).

I do not know what the bug here is, it could be one of these options:

1) apt-get/apt upgrade accepts packages to upgrade where the docs state it
   doesn't. The behaviour needs to change to not accept packages.

2) apt-get/apt upgrade accepts packages and removes packages to satisfy deps
   where the docs state it doesn't. The behaviour need to change to not remove
   any packages. There is a small edge case where you can say: `apt upgrade foo
   bar-'. Technically, it shouldn't remove packages, yet you want and instruct
   it to remove bar.

FWIW, aptitude does not remove packages where you call `aptitude safe-upgrade
foo'. It does remove packages when you call `aptitude full-upgrade foo'. It
also removes bar when you run `aptitude safe-upgrade foo bar-'. 

I'll leave this for the maintainers to answer.

Cheers,
Wesley

Bug#1066074: ntfs-3g: broken shlibs (deb and udeb)

[Cyril Brulebois]

Source: ntfs-3g
Version: 1:2022.10.3-1.1
Severity: serious
Tags: d-i
Justification: broken shlibs
X-Debbugs-Cc: debian-b...@lists.debian.org, Benjamin Drung 

Hi,

Here's what debian/libntfs-3g89t64/DEBIAN/shlibs looks like after
a build:

libntfs-3g 89 libntfs-3g89
udeb: libntfs-3g 89 libntfs-3g89

That doesn't match binaries shipped by the source package.


See debian/rules:

SONAME = $(shell objdump -p debian/tmp/lib/*/libntfs-3g.so.*.* | awk -Fso. 
'/SONAME/ { print $$2 }')

[…]

override_dh_makeshlibs:
dh_makeshlibs --add-udeb=ntfs-3g-udeb -Vlibntfs-3g$(SONAME)


In the previous version we had:

libntfs-3g 89 libntfs-3g89
udeb: libntfs-3g 89 ntfs-3g-udeb

Adding 't64' at the end of the dh_makeshlibs line quoted above gives:

libntfs-3g 89 libntfs-3g89t64
udeb: libntfs-3g 89 ntfs-3g-udeb

which certainly looks much better. I haven't performed any rebuild test
for the reverse dependencies of the library, nor runtime tests on the
d-i side (other packages are broken right now). The Depends field of
the udeb looks correct now though:

-Depends: libc6-udeb (>= 2.37), libntfs-3g89, fuse3-udeb
+Depends: libc6-udeb (>= 2.37), fuse3-udeb


I'll leave it up to the 64-bit time_t transition drivers to choose how
to address this issue (add t64 on the SONAME line, or just in the
dh_makeshlibs override, or something else), and to track down packages
that might have been rebuilt against the broken library.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#1066073: wireless-tools: nmudiff for the 30~pre9-16.2 upload

[Cyril Brulebois]

Source: wireless-tools
Version: 30~pre9-16.2
Severity: normal
Tags: d-i patch
X-Debbugs-Cc: Steve Langasek , debian-b...@lists.debian.org

Hi,

The previous upload broke udeb support, pointing to a non-existing udeb
in the shlibs file. This made wireless-tools-udeb uninstallable.

Seeing how this package is QA-maintained, I decided to just upload a fix
without filing a bug report separately. I've verified the Depends field
of the wireless-tools-udeb package looks fine; I didn't try and perform
any runtime tests (other packages are broken right now).

The source debdiff is attached.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru wireless-tools-30~pre9/debian/changelog 
wireless-tools-30~pre9/debian/changelog
--- wireless-tools-30~pre9/debian/changelog 2024-02-29 03:02:19.0 
+0100
+++ wireless-tools-30~pre9/debian/changelog 2024-03-12 01:42:45.0 
+0100
@@ -1,3 +1,11 @@
+wireless-tools (30~pre9-16.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix shlibs entry for the udeb: it isn't getting renamed for the 64-bit
+time_t transition. This makes wireless-tools-udeb installable again.
+
+ -- Cyril Brulebois   Tue, 12 Mar 2024 01:42:45 +0100
+
 wireless-tools (30~pre9-16.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru wireless-tools-30~pre9/debian/libiw30t64.shlibs 
wireless-tools-30~pre9/debian/libiw30t64.shlibs
--- wireless-tools-30~pre9/debian/libiw30t64.shlibs 2024-02-29 
03:01:29.0 +0100
+++ wireless-tools-30~pre9/debian/libiw30t64.shlibs 2024-03-12 
01:42:42.0 +0100
@@ -1,2 +1,2 @@
 libiw 30 libiw30t64 (>= 30~pre1)
-udeb: libiw 30 libiw30t64-udeb (>= 30~pre1)
+udeb: libiw 30 libiw30-udeb (>= 30~pre1)

Bug#1066072: ITP: swappy -- Wayland native snapshot and editor tool

[Nick Hastings]

Package: wnpp
Severity: wishlist
Owner: Nick Hastings 
X-Debbugs-Cc: debian-de...@lists.debian.org, nicholaschasti...@gmail.com

* Package name: swappy
  Version : 1.5.1
  Upstream Contact: Jeremy Attali 
* URL : https://github.com/jtheoof/swappy
* License : MIT
  Programming Lang: C
  Description : Wayland native snapshot and editor tool

A Wayland native snapshot and editor tool, inspired by Snappy on
macOS. Works great with grim, slurp and sway. But can easily work
with other screen copy tools that can output a final image to stdout.

This tool provides a nice balance between feature set and ease of used
for quickly annotating screenshots or other images.

A sponsor will be needed.

Bug#1053550: IKEv2 regression when IP address changes behind NAT-T

[Daniel Kahn Gillmor]

Control: forwarded 1053550 https://github.com/libreswan/libreswan/issues/1645

On Fri 2023-10-06 15:31:40 +0800, Herbert Xu wrote:
> When the IP address of a host behind NAT changes, libreswan fails
> to respond correctly when IKEv2 is used.  This is a regression from
> IKEv1 as libreswan will correctly shut down the existing connection
> and initiate a new one when DPD kicks in.

Thanks for this report, Herbert.  I don't know how to resolve this at
the debian packaging layer, but i've forwarded it upstream.

--dkg


signature.asc
Description: PGP signature

Bug#1065467: marisa: FTBFS on loongarch64 as the test case fails

[Boyuan Yang]

Hi,

在 2024-03-11星期一的 11:29 +0800，zhangdandan写道：
>  
> Hi,
>  
>    Thanks for your reply.
>  
>  
> On Thu, 07 Mar 2024 09:31:20 -0500 Boyuan Yang  wrote:
>  
>  > Hi,
>  > 
>  > 在 2024-03-05星期二的 12:10 +0800，zhangdandan写道：
>  > > Source: marisa
>  > > Version: 0.2.6-15
>  > > Severity: wishlist
>  > > Tags: ftbfs
>  > > User: debian-loonga...@lists.debian.org
>  > > Usertags: loong64
>  > > 
>  > > Dear maintainers,
>  > > 
>  > > Compiling the marisa failed for loong64 in the Debian Package 
>  > > Auto-Building environment.
>  > > Please consider the patch (my local patch) I have attached.
>  > > If you have any questions, you can contact me at any time.
>  > 
>  > I can take this patch, but the patch should be forwarded upstream first.
>  > Please forward it to GitHub upstream project so that I can use the 
> forwarded
>  > link as a reference. After that, I can make the patched upload in Debian.
>   
> I have submitted a pull request to upstream, please see 
> https://github.com/s-yata/marisa-trie/pull/56.
>  But this marisa-trie project hasn't been updated for a long time (about 4 
> years).
>  Refer to other architectures for handling, could you add a patch for 
> marisa-0.2.6 source package?

I just made a 0.2.6-16 upload in Debian based on your patch. Your upstream pull 
request is
used as a reference.

Thanks,
Boyuan Yang


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

Bug#1066071: mtdev: broken shlibs, leading to uninstallable udebs

[Cyril Brulebois]

Source: mtdev
Version: 1.1.6-1.1
Severity: serious
Tags: d-i
Justification: broken shlibs
X-Debbugs-Cc: debian-b...@lists.debian.org, Benjamin Drung 

Hi,

Your NMU broke this package's shlibs.

Before:

libmtdev 1 libmtdev1
udeb: libmtdev 1 libmtdev1-udeb

After:

libmtdev 1 libmtdev1t64

At the moment, at least the following package is broken:

The following packages have unmet dependencies:
 libinput10-udeb : Depends: libmtdev1t64 but it is not installable


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#1066070: libpng1.6: hardcodes wrong udeb in shlibs, making udebs uninstallable

[Cyril Brulebois]

Source: libpng1.6
Version: 1.6.43-3
Severity: serious
Tags: d-i
Justification: broken shlibs
X-Debbugs-Cc: debian-b...@lists.debian.org

Hi,

Your debian/rules includes this:

override_dh_makeshlibs:
dh_makeshlibs --add-udeb=libpng16-16-udeb -a

and that's indeed the package that's listed in debian/control.

However, debian/libpng16-16t64.shlibs has it wrong:

libpng16 16 libpng16-16t64 (>= 1.6.2)
udeb: libpng16 16 libpng16-udeb (>= 1.6.2)

At this point, that breaks at least:

The following packages have unmet dependencies:
 libcairo2-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not 
installable
 libfreetype6-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not 
installable
 libgdk-pixbuf-2.0-0-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it 
is not installable


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#1066069: libpng1.6: hardcodes wrong udeb in shlibs, making udebs uninstallable

[Cyril Brulebois]

Source: libpng1.6
Version: 1.6.43-3
Severity: serious
Tags: d-i
Justification: broken shlibs
X-Debbugs-Cc: debian-b...@lists.debian.org

Hi,

Your debian/rules includes this:

override_dh_makeshlibs:
dh_makeshlibs --add-udeb=libpng16-16-udeb -a

and that's indeed the package that's listed in debian/control.

However, debian/libpng16-16t64.shlibs has it wrong:

libpng16 16 libpng16-16t64 (>= 1.6.2)
udeb: libpng16 16 libpng16-udeb (>= 1.6.2)

At this point, that breaks at least:

The following packages have unmet dependencies:
 libcairo2-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not 
installable
 libfreetype6-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not 
installable
 libgdk-pixbuf-2.0-0-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it 
is not installable


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#1055970: ark: Ark is not working with upstream 7-zip

[Jesse Rhodes]

This has been fixed in salsa, and we are waiting for the 64-bit time_t
transition to progress to a point where new qt/kde uploads can build
in sid again. Just leaving this note since we don't currently know how
long that will take.

https://salsa.debian.org/qt-kde-team/kde/ark/-/merge_requests/4

sney

Bug#895570: devscripts: wrap-and-sort should default to -ast (--wrap-always, --short-indent, --trailing-comma)

[Johannes Schauer Marin Rodrigues]

Hi,

On Wed, 6 Mar 2024 11:04:01 +0100 Paride Legovini  wrote:
> On Sun, 03 Mar 2024 16:26:41 +0100 Benjamin Drung  wrote:
> > Time to join this discussion. The current default was the preference of
> > the author 14 years ago. My taste has change a bit since then. I am open
> > to change the default. --trailing-comma for wrapped lines is a good
> > idea, --short-indent is okay. I don't like --wrap-always in case there
> > are only two or three entries.
> > 
> > The new default should not only based on the preference, but also on
> > what is used the most. Can someone collect the information: which teams
> > use which options, how many packages use what?
> 
> I did some unscientific research on codesearch looking for d/changelog entries
> mentioning `wrap-and-sort -` (i.e. wrap-and-sort with some options). This is
> the query:
> 
> https://codesearch.debian.net/search?q=path%3Adebian%2Fchangelog+wrap-and-sort+-=1
> 
> Apparently -a is the single most used option, very often used together with
> -s and -t. I found similar results by searching GitHub:
> 
> https://github.com/search?q=path%3Adebian%2Fchangelog+%22wrap-and-sort+-%22=code
> 
> Looks like salsa (GitLab Free) doesn't allow to do instance-wide code 
> searches.

I disagree that the new default should be what is used the most. For example
debhelper versions do not become the default only after they are used the most.
The thing that makes switching defaults easier for debhelper is the explicit
opt-in for a new debhelper compat version which we don't have for wrap-and-sort
and I think it would very much be over-engineering to add such a feature for
something that is, in my opinion, of very little consequence. Furthermore, I
would not be surprised if many people using wrap-and-sort use the default
expecting that this is what is most well-liked by the project (because why else
would it be the default?). The question was asked in this email sub-thread:

https://lists.debian.org/161289428547.4135738.4002254931040787...@auryn.jones.dk

In that thread, same as in this bug, -ast was proposed as the default and
unless I missed something, there were no objections on debian-devel. Some even
argued, to make -b the default as well. So instead of asking "what is used
most" I'd like to ask, are there users of wrap-and-sort without -ast who would
be strongly against having to pass -AST to overwrite a potential new default?

That being said, I downloaded all debian/control files for all 36832 source
packages in Debian and ran the following shell script on them to figure out how
many source packages comply with which wrap-and-sort set of options:

for p in control/*; do
rm -f debian/control;
ln -s "../$p" debian/control;
for opt in "" -a -as -ast -astb -at -atb -ab -s -st -stb -sb -t -tb -b; 
do
wrap-and-sort --dry-run --file=debian/control $opt \
| grep --quiet debian/control \
|| echo $p >> w-a-s$opt;
done
done

It's of course still not possible to say whether a control file adheres to a
certain wrap-and-sort formatting style by accident or intentionally. Also,
packages can easily fall in multiple categories at the same time, for example
packages with only a single binary package which comply with -ast will
automatically also comply with -astb. There are also packages which comply with
-ast as well as with no options at all simply because they have no
Build-Depends nor Depends fields in debian/control. Here is the result sorted
by popularity in ascending order:

96 wrap-and-sort -st
96 wrap-and-sort -stb
   434 wrap-and-sort -as
   465 wrap-and-sort -tb
   489 wrap-and-sort -t
   579 wrap-and-sort -atb
   641 wrap-and-sort -at
  1341 wrap-and-sort -sb
  1405 wrap-and-sort -s
  2381 wrap-and-sort -astb
  2705 wrap-and-sort -ast
  2732 wrap-and-sort -b
  3020 wrap-and-sort
  3950 wrap-and-sort -ab
  4089 wrap-and-sort -a

So, wrap-and-sort -ast is very popular but it is not as popular as the current
default.

Do with that data what you wish. :)

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1066068: RFS: minidb/2.0.7-2 -- simple SQLite3-based store for Python objects

[Maxime Werlen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : minidb
   Version  : 2.0.7-2
   Upstream contact : Thomas Perl 
 * URL  : https://thp.io/2010/minidb/
 * License  : ISC
 * Vcs  : https://salsa.debian.org/mwerlen/minidb
   Section  : python

The source builds the following binary packages:

  python3-minidb - simple SQLite3-based store for Python objects

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/m/minidb/minidb_2.0.7-2.dsc

Changes since the last upload:

 minidb (2.0.7-2) unstable; urgency=medium
 .
   * Add a patch to switch from distutils to setuptools (closes: #1065902)
   * Update copyright years
   * Bump standard version

Regards,

Bug#1066062: libmath-int128-perl: FTBFS on i386 "your compiler doesn't support a 128-bit integer type"

[gregor herrmann]

Control: severity -1 normal
Control: found -1 0.22-1

On Mon, 11 Mar 2024 21:35:30 +, Mike Gerow via pkg-perl-maintainers wrote:

> libmath-int128-perl appears unable to build on i386 on my machine using
> sbuild and the latest buildd result[1] seems the same.

Correct, and that's the same since the beginning, libmath-int128-perl
never built on 32bit architectures.

% rmadison libmath-int128-perl
libmath-int128-perl | 0.22-2| oldoldstable   | source, amd64, arm64, 
mips64el, ppc64el, s390x
libmath-int128-perl | 0.22-2| oldstable  | source
libmath-int128-perl | 0.22-2+b2 | oldstable  | arm64, mips64el, 
ppc64el, s390x
libmath-int128-perl | 0.22-2+b3 | oldstable  | amd64
libmath-int128-perl | 0.22-4| stable | source, amd64, arm64, 
mips64el, ppc64el, s390x
libmath-int128-perl | 0.22-5| testing| source, amd64, arm64, 
mips64el, ppc64el, s390x
libmath-int128-perl | 0.22-5| unstable   | source
libmath-int128-perl | 0.22-5| unstable-debug | source
libmath-int128-perl | 0.22-5+b1 | unstable   | amd64, arm64, mips64el, 
ppc64el, riscv64, s390x

https://buildd.debian.org/status/logs.php?pkg=libmath-int128-perl

> This indirectly
> affects the i386 build of libmaxmind-db-writer-perl and probably a few
> other packages.

libmaxmind-db-writer-perl also was never available on 32bit
architectures:

% rmadison libmaxmind-db-writer-perl
libmaxmind-db-writer-perl | 0.33-4| oldstable  | source, amd64, 
arm64, mips64el, ppc64el
libmaxmind-db-writer-perl | 0.33-5| stable | source
libmaxmind-db-writer-perl | 0.33-5+b1 | stable | amd64, arm64, 
mips64el, ppc64el
libmaxmind-db-writer-perl | 0.34-1| testing| source
libmaxmind-db-writer-perl | 0.34-1| unstable   | source
libmaxmind-db-writer-perl | 0.34-1| unstable-debug | source
libmaxmind-db-writer-perl | 0.34-1+b1 | testing| amd64, arm64, 
mips64el, ppc64el
libmaxmind-db-writer-perl | 0.34-1+b2 | unstable   | amd64, arm64, 
mips64el, ppc64el, riscv64

https://buildd.debian.org/status/logs.php?pkg=libmaxmind-db-writer-perl


This is unfortunate but at least it's not a regression, and I don't
think we can do anything about it.
 

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#1066052: gcc-13: several acats tests raise ADA.CALENDAR.TIME_ERROR : a-calend.adb:601

[Matthias Klose]

CCing Nicolas ...

this is most likely time_t64 fallout. It should go away when we switch 
to gnat 13 and rebuild the packages in the archive.


Nicolas, please could you upload gnat 13? It's just one more transition 
for time_t64.


Matthias

On 11.03.24 21:05, John David Anglin wrote:

Source: gcc-12
Version: 12.3.0-15
Severity: normal

Dear Maintainer,

In test log, I see a number of tests with following error:

splitting /build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/testsuite/ada/acats1/test
s/a/a26007a.adt into:
a26007a.adb
BUILD a26007a.adb
/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/gnatmake 
--GNATBIND=/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/gnatbind 
--GNATLINK=/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/gnatlink 
--GCC=/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/xgcc 
-B/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/ -gnatws -O2 -gnat95 
-I/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/testsuite/ada/acats1/../acats/support
 a26007a.adb -largs --GCC=/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/xgcc 
-B/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/
/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/xgcc -c 
-B/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/ -gnatws -O2 -gnat95 
-I/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/testsuite/ada/acats1/../acats/support
 a26007a.adb
/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/gnatbind 
-I/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/testsuite/ada/acats1/../acats/support
 -x a26007a.ali
/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/gnatlink a26007a.ali -O2 
--GCC=/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/xgcc 
-B/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/
RUN a26007a


raised ADA.CALENDAR.TIME_ERROR : a-calend.adb:601
FAIL:   a26007a

Regards,
Dave Anglin


-- System Information:
Debian Release: trixie/sid
   APT prefers buildd-unstable
   APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.1.80+ (SMP w/4 CPU threads)
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)

-- no debconf information

Bug#1063376: How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)

[Mattia Rizzolo]

On Mon, Mar 11, 2024 at 09:12:30PM +0100, Andreas Tille wrote:
> I hope there is some better solution than sending single bug reports
> for those packages.  If ftpmaster tooling really needs single bug
> reports I wonder how I can automatically create such bug reports with
> always the same text, just targeting at different binary packages.
> 
> This also should include some means to work around the less than 5
> bug reports per hour SPAM protection means of BTS.


clone the bug however many time you need and retitle the clones?  What
matters for the ftp tooling is just the bug title, pretty much.
That's one single email...

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Miguel Angel Rojas]

> I see. It looks like `apt upgrade ' behaves as `apt install
> '. Which (to me) is unexpected behaviour, as the man page is
quite
>clear on its behaviour (man 8 apt-get):

Well, clearly it shouldn’t. To begin with, “apt install” should mark a
package as manual installed while “apt upgrade” shouldn’t (my assumption).
And you’re right that “apt install” can remove a package if needed to
satisfy dependencies.

On top of that, documentation clearly states that “apt upgrade” should not
remove any package, but it does when you specify an individual package to
upgrade.

If this is not the expected behavior, maybe this is a bug (unless I am
missing something here).

Bug#1066067: cl-plus-ssl: hardcoded libssl3 dependency

[Sebastian Ramacher]

Source: cl-plus-ssl
Version: 20220328.git8b91648-4
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

cl-plus-ssl hardcodeds a dependency on libssl3. Due to the time_t
transition, the package name changed and the dependency needs to be
updated.

Cheers
-- 
Sebastian Ramacher

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Wesley Schwengle]

On Mon, Mar 11, 2024 at 10:48:53PM +0100, Miguel Angel Rojas wrote:
> Hi Wesley, David,
> 
> > You keep saying `apt upgrade' yet your command was `apt full-upgrade'.
> 
> Yes, maybe it didn't express itself properly. After your suggestion about
> not using "apt full-upgrade" during this t64 migration, I followed your
> advice and used only "apt upgrade" for individual upgrades. I was referring
> to this comment you made below:

Ah, and I meant upgrading as individually installing packages ala: `apt install
foo'. I get the confusion now :)

> Now, If I type"apt upgrade" doesn't give me any option to update anything:

Ok, that is expected behaviour.

> But, in some situations, as you mentioned, individual package upgrades can
> work and remove some problems. So what I did was to try some "apt upgrade"
> on individual packages from that list. This time I try the ppp package:
> 
> # apt upgrade ppp
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Calculating upgrade... Done
> The following packages were automatically installed and are no longer
> required:
>  linux-headers-6.6.15-amd64 linux-headers-6.6.15-common
> linux-image-6.6.15-amd64 linux-kbuild-6.6.15
> Use 'apt autoremove' to remove them.
> The following packages will be REMOVED: <--- PACKAGE TO BE REMOVED
>  libpcap0.8
> The following NEW packages will be installed:
>  libpcap0.8t64
>
> [snip]
>
> The following packages will be upgraded:
>  ppp
> 1 upgraded, 1 newly installed, 1 to remove and 22 not upgraded.
> Need to get 511 kB of archives.
> After this operation, 15.4 kB disk space will be freed.
> ,
> 
> As you can see here, I'm typing "apt upgrade ppp" and it removes a package
> in this case: libpcap0.8 (sometimes more packages are removed).
> 
> Which is good, because libpcap0.8 is replaced by libpcap0.8t64 (as expected
> in this t64 migration) but "apt upgrade ppp" is REMOVING a package (which
> contradicts the specification).

I see. It looks like `apt upgrade ' behaves as `apt install
'. Which (to me) is unexpected behaviour, as the man page is quite
clear on its behaviour (man 8 apt-get):

upgrade
   upgrade is used to install the newest versions of **all** (emphasis mine)
   packages currently installed on the system from the sources enumerated in
   /etc/apt/sources.list.

It shouldn't accept the arguments you feed it, apt-get has the same
"feature". And with an install you do remove packages to satisfy the deps.

Cheers,
Wesley

Bug#1066066: Broken videoflip in gstreamer-1.22.0 (Bookworm)

[fduncanh]

Package:   gstreamer1.0-plugins-good

Version: 1.22.0-5+deb12u1


A regression inadvertently introduced in GStreamer-1.22.0 breaks user 
setting of  the "videoflip" feature.


It was initially fixed in 1.22.3, with three more fix attempts until the 
fix stabilized in 1.22.6.


I have prepared a patch to backport the fix to Debian Bookworm, the 
patch and more details are


available at 
https://github.com/FDH2/UxPlay/wiki/patch-for-broken--videoflip-method-in-GStreamer-1.22.0



Since Bookworm will last a long time, it would be good to include this 
backport of the fix in some future updates.


The patch (also attached) includes GStreamer commits

b17fbb23

2dc0e1ac

4c77bc21

bbca6cc8

diff -uNr a/docs/gst_plugins_cache.json b/docs/gst_plugins_cache.json
--- a/docs/gst_plugins_cache.json   2024-03-10 12:28:07.349086078 -0400
+++ b/docs/gst_plugins_cache.json   2024-03-10 12:40:14.858128390 -0400
@@ -26293,7 +26293,7 @@
 "method": {
 "blurb": "method (deprecated, use video-direction 
instead)",
 "conditionally-available": false,
-"construct": true,
+"construct": false,
 "construct-only": false,
 "controllable": true,
 "default": "none (0)",
diff -uNr a/gst/videofilter/gstvideoflip.c b/gst/videofilter/gstvideoflip.c
--- a/gst/videofilter/gstvideoflip.c2024-03-10 12:28:07.397087203 -0400
+++ b/gst/videofilter/gstvideoflip.c2024-03-10 14:12:15.331126852 -0400
@@ -1788,6 +1788,18 @@
 
   if (gst_video_orientation_from_tag (taglist, )) {
 gst_video_flip_set_method (vf, method, TRUE);
+
+if (vf->method == GST_VIDEO_ORIENTATION_AUTO) {
+  /* Update the orientation tag as we rotate the video accordingly.
+   * The event (and so the tag list) can be shared so always copy 
both. */
+  taglist = gst_tag_list_copy (taglist);
+
+  gst_tag_list_add (taglist, GST_TAG_MERGE_REPLACE,
+  "image-orientation", "rotate-0", NULL);
+
+  gst_event_unref (event);
+  event = gst_event_new_tag (taglist);
+}
   }
   break;
 default:
@@ -1834,6 +1846,17 @@
 }
 
 static void
+gst_video_flip_constructed (GObject * object)
+{
+  GstVideoFlip *self = GST_VIDEO_FLIP (object);
+
+  if (self->method == (GstVideoOrientationMethod) PROP_METHOD_DEFAULT) {
+gst_video_flip_set_method (self,
+(GstVideoOrientationMethod) PROP_METHOD_DEFAULT, FALSE);
+  }
+}
+
+static void
 gst_video_flip_class_init (GstVideoFlipClass * klass)
 {
   GObjectClass *gobject_class = (GObjectClass *) klass;
@@ -1846,13 +1869,14 @@
 
   gobject_class->set_property = gst_video_flip_set_property;
   gobject_class->get_property = gst_video_flip_get_property;
+  gobject_class->constructed = gst_video_flip_constructed;
 
   g_object_class_install_property (gobject_class, PROP_METHOD,
   g_param_spec_enum ("method", "method",
   "method (deprecated, use video-direction instead)",
   GST_TYPE_VIDEO_FLIP_METHOD, PROP_METHOD_DEFAULT,
   GST_PARAM_CONTROLLABLE | GST_PARAM_MUTABLE_PLAYING |
-  G_PARAM_READWRITE | G_PARAM_CONSTRUCT | G_PARAM_STATIC_STRINGS));
+  G_PARAM_READWRITE | G_PARAM_STATIC_STRINGS));
   g_object_class_override_property (gobject_class, PROP_VIDEO_DIRECTION,
   "video-direction");
   /* override the overriden property's flags to include the mutable in playing
@@ -1886,6 +1910,12 @@
 static void
 gst_video_flip_init (GstVideoFlip * videoflip)
 {
+  /* We initialize to the default and call set_method() from constructed
+   * if the value hasn't changed, this ensures set_method() does get called
+   * even if the non-construct method / direction properties aren't set
+   */
+  videoflip->method = (GstVideoOrientationMethod) PROP_METHOD_DEFAULT;
+
   /* AUTO is not valid for active method, this is just to ensure we setup the
* method in gst_video_flip_set_method() */
   videoflip->active_method = GST_VIDEO_ORIENTATION_AUTO;

Bug#1066065: libvformat: FTBFS: vf_reader.c:178:33: error: implicit declaration of function ‘read’; did you mean ‘fread’? [-Werror=implicit-function-declaration]

[Sebastian Ramacher]

Source: libvformat
Version: 1.13-12.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=libvformat=armhf=1.13-12.1=1709167815=0

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -c vf_delete.c  -fPIC -DPIC -o .libs/vf_delete.o
vf_reader.c: In function ‘vf_read_file’:
vf_reader.c:178:33: error: implicit declaration of function ‘read’; did you 
mean ‘fread’? [-Werror=implicit-function-declaration]
  178 | charsread = read(fileno(fp), buffer, 
sizeof(buffer));
  | ^~~~
  | fread
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -c vf_writer.c -o vf_writer.o >/dev/null 2>&1
/bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..   
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time 
-D_FORTIFY_SOURCE=2  -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -c -o 
vf_malloc_stdlib.lo vf_malloc_stdlib.c
cc1: some warnings being treated as errors
make[3]: *** [Makefile:458: vf_reader.lo] Error 1

Cheers
-- 
Sebastian Ramacher

Bug#1054171: Would you agree with swapping Maintainer and Uploaders in eric?

[Alexandre Detiste]

Hi Jan,

I see on the tracker that you have both set the LowNMU flag (like I did too)
and also made use of the special rule of the DPT policy discussed from [1];
that seems a bit of a contradiction to me but I have read that
it was the default behaviour of some source package templating tool
which might explain where it came from.

Would you agree to swap Maintainer & Uploader fields like proposed ?

My offer to refresh the package still stands on.
I would need this anyway for my work anyway in the coming months,
that seems like a waste of time not to share this work.
(we are currently using the bookworm .deb on buster and it justs works...)

Greetings

[0] https://tracker.debian.org/pkg/python-pika

Le lun. 11 mars 2024 à 22:30, Andreas Tille  a écrit :
>
> Hi Gudjon,
>
> in case you agree with the suggested change of policy discussed on the
> debian-python mailing list[1] would you agree to set DPT as maintainer?
> If yes, I'd volunteer to do this, fix bug #1065855 and #1060736.
>
> Kind regards and thanks for working on this package
> Andreas.
>
> [1] https://lists.debian.org/debian-python/2024/02/msg00052.html

Bug#1065237: O: astroidmail -- graphical notmuch email client

[Jonas Smedegaard]

Quoting Daniel Echeverri (2024-03-11 16:58:58)
> Hi Jonas, Nilesh!
> 
> El dom, 10 mar 2024 a la(s) 1:13 a.m., Jonas Smedegaard (jo...@jones.dk)
> escribió:
> 
> > Control: reopen -1
> >
> > Quoting Jonas Smedegaard (2024-03-10 07:03:27)
> > > I will now close this bugreport, interpreting it as bogus (unfortunately
> > > without the consent of the bugreporter).
> >
> > Ah, turns out that the bugreporter did respond, just only silently to
> > the bugreport, without informing me.
> >
> > Sorry for the added confusion - I will reopen the bugreport, which is
> > now tied to the correct package, src:astroid.
> >
> > My recommendations abut renaming the source package and generally using
> > prefix "python-" for python-specific packages stand.
> >
> > Kind regards,
> >
> >  - Jonas
> >
> > --
> >  * Jonas Smedegaard - idealist & Internet-arkitekt
> >  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> >  * Sponsorship: https://ko-fi.com/drjones
> >
> >  [x] quote me freely  [ ] ask before reusing  [ ] keep private
> 
> 
> Sorry for the confusion, I am trying to adopt astroid package not
> astroidmail, Can I go ahead?

Technically you are trying to adopt the *source* package astroid, which
is unambiguously expressed with prefix as src:astroid - you are not
trying to adopt the *binary* package astroid.  That's the root of the
confusion.

That said, yes, please go ahead - thanks for your interest in adopting
packages, and sorry for my part in the confusion¹

Please - in addition to (not as a precondition) and only as a
suggestion, consider renaming the package src:astroid to
src:python-astroid, so as to eliminate future confusions between
src:astroid (providing binary package python3-astroid) and
src:astroidmail (providing binary package astroid).


Kind regards,

 - Jonas

¹ I introduced the binary package astroid, unaware at the time of the
confusion, and (as I recall) when made aware of the potential for
confusion I insisting on keeping the name: I considered it more helpful
for our users that we rename the source package of a library than to
rename the binary package of a user-facing binary package to something
unaligned with the actual binary executable.  The former maintainer
disagreed with me, leading to the current situation.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1066064: openstack-trove: please remove python3-mock from build-dependency

[Alexandre Detiste]

Source: openstack-trove
Version: 1:20.0.0-2
Severity: normal

python3-mock usage has been replaced here by unittest.mock
from the standard library.

Greetings

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Miguel Angel Rojas]

Hi Wesley, David,

> You keep saying `apt upgrade' yet your command was `apt full-upgrade'.

Yes, maybe it didn't express itself properly. After your suggestion about
not using "apt full-upgrade" during this t64 migration, I followed your
advice and used only "apt upgrade" for individual upgrades. I was referring
to this comment you made below:

> My advice to you is: don't expect full-upgrade to work until the
transitioning
> is done. You can do `apt upgrade' without too much hassle. If you feel
like it
> you can inspect individual upgrades possibilities  via `apt list
--upgradable'
> and upgrade each package individually.

Therefore, that's the advice I'm following right now.

Now, If I type"apt upgrade" doesn't give me any option to update anything:

# apt upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer
required:
 linux-headers-6.6.15-amd64 linux-headers-6.6.15-common
linux-image-6.6.15-amd64 linux-kbuild-6.6.15
Use 'apt autoremove' to remove them.
The following packages have been kept back:
 gstreamer1.0-plugins-bad gstreamer1.0-plugins-good
gstreamer1.0-plugins-ugly kaddressbook kmail knotes
 libgstreamer-plugins-bad1.0-0 libkf5akonadisearch-bin
libkf5akonadisearch-plugins
 libkf5messagecomposer5abi1 libkf5messagecore5abi1 libkf5messagelist5abi1
libkf5messageviewer5abi1
 libkf5mimetreeparser5abi1 libkf5pimcommonakonadi5abi1
libkf5templateparser5 libkf5webengineviewer5abi1
 libkpimaddressbookimportexport5 libldb2 libopenconnect5 libqt5webengine5
ppp samba-libs
0 upgraded, 0 newly installed, 0 to remove and 23 not upgraded.


But, in some situations, as you mentioned, individual package upgrades can
work and remove some problems. So what I did was to try some "apt upgrade"
on individual packages from that list. This time I try the ppp package:

# apt upgrade ppp
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer
required:
 linux-headers-6.6.15-amd64 linux-headers-6.6.15-common
linux-image-6.6.15-amd64 linux-kbuild-6.6.15
Use 'apt autoremove' to remove them.
The following packages will be REMOVED: <--- PACKAGE TO BE REMOVED
 libpcap0.8
The following NEW packages will be installed:
 libpcap0.8t64
The following packages have been kept back:
 gstreamer1.0-plugins-bad gstreamer1.0-plugins-good
gstreamer1.0-plugins-ugly kaddressbook kmail knotes
 libgstreamer-plugins-bad1.0-0 libkf5akonadisearch-bin
libkf5akonadisearch-plugins
 libkf5messagecomposer5abi1 libkf5messagecore5abi1 libkf5messagelist5abi1
libkf5messageviewer5abi1
 libkf5mimetreeparser5abi1 libkf5pimcommonakonadi5abi1
libkf5templateparser5 libkf5webengineviewer5abi1
 libkpimaddressbookimportexport5 libldb2 libopenconnect5 libqt5webengine5
samba-libs
The following packages will be upgraded:
 ppp
1 upgraded, 1 newly installed, 1 to remove and 22 not upgraded.
Need to get 511 kB of archives.
After this operation, 15.4 kB disk space will be freed.
,

As you can see here, I'm typing "apt upgrade ppp" and it removes a package
in this case: libpcap0.8 (sometimes more packages are removed).

Which is good, because libpcap0.8 is replaced by libpcap0.8t64 (as expected
in this t64 migration) but "apt upgrade ppp" is REMOVING a package (which
contradicts the specification).

@David: I will send you the file as you requested.

Regards

On Mon, Mar 11, 2024 at 5:44 PM Wesley Schwengle 
wrote:

>
> Hi Miguel,
>
> On Mon, Mar 11, 2024 at 05:09:47PM +0100, Miguel Angel Rojas wrote:
> > > I do not know, at times I'm also wondering why it doesn't do it, but I
> > didn't
> > > take time to look at the code to understand what the resolver is doing.
> > Also,
> > > it was sort of expected. I think we can probably solve this is a more
> > > controlled manner. With the current t64 transitioning in unstable it is
> > > difficult to track down. Many updates so the situation now may differ
> > from the
> > > situation in an hour from now.
> >
> > Yes, it is confusing for me too. Without considering this t64 migration,
> > “apt upgrade” should *NOT* remove any package (just upgrading a package
> to
> > a newer version or install new dependencies). But it is removing packages
> > right now! i.e. again, with this t64 migration, it makes the old
> libraries
> > to be uninstalled and install the new *t64 version.
> >
> > Any thoughts why “apt upgrade” is removing packages even when
> documentation
> > says it shouldn’t? or is it a bug?
>
> You keep saying `apt upgrade' yet your command was `apt full-upgrade'. As
> said
> earlier, full-upgrade does indeed remove packages to be able to perform an
> upgrade. I haven't seen `apt upgrade' do that. So I cannot comment on apt
> doing
> something wrong when it isn't :)
>
> Cheers,
> Wesley
>

Bug#1059133: dogecoin: FTBFS: error: invalid ‘static_cast’ from type ‘boost::detail::function::function_buffer_members::obj_ptr_t’ {aka ‘void*’} to type ‘void (*)(bool, const CBlockIndex*)’

[Bastian Germann]

Let's wait for boost 1.84 to become available in Debian then.

Bug#1066063: python-django-compressor: please remove 2 more obsolete dependencies: python3-mock & python3-unittest2

[Alexandre Detiste]

Source: python-django-compressor
Version: 4.4-2
Severity: minor

A quick grep show that thoses are not used anymore.

Greetings

diff --git a/debian/control b/debian/control
index 467989c..7c70e53 100644
--- a/debian/control
+++ b/debian/control
@@ -23,11 +23,9 @@ Build-Depends-Indep:
  python3-html5lib,
  python3-jinja2,
  python3-lxml,
- python3-mock,
  python3-rcssmin,
  python3-rjsmin,
  python3-slimit,
- python3-unittest2,
 Standards-Version: 4.1.1
 Vcs-Browser: 
https://salsa.debian.org/openstack-team/python/python-django-compressor

Bug#1066062: libmath-int128-perl: FTBFS on i386 "your compiler doesn't support a 128-bit integer type"

[Mike Gerow]

Source: libmath-int128-perl
Version: 0.22-5
Severity: important
Tags: ftbfs

libmath-int128-perl appears unable to build on i386 on my machine using
sbuild and the latest buildd result[1] seems the same. This indirectly
affects the i386 build of libmaxmind-db-writer-perl and probably a few
other packages.

Checking for int __attribute__ ((__mode__ (TI)))...
  It looks like your compiler doesn't support a 128-bit integer type (one of
  "int __attribute__ ((__mode__ (TI)))" or "__int128"). One of these types  
is

  necessary to compile the Math::Int128 module.

[1]:  
https://buildd.debian.org/status/fetch.php?pkg=libmath-int128-perl=i386=0.22-5=1705861163=0

Bug#1053147: fixed

[Gianfranco Costamagna]

control: close -1
thanks


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1066061: networking-bagpipe: please remove extraneous python3-mock build dependency

[Alexandre Detiste]

Source: networking-bagpipe
Version: 19.0.0-2
Severity: normal

This package uses the newer unittest.mock
from the standard library.

python3-mock is being slowly removed from the distribution.

Greetings

Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2

[Amin Bandali]

Hi,

On Mon, Mar 11, 2024 at 05:55:31PM +0100, Sebastian Andrzej Siewior wrote:
> On 2024-03-11 00:05:54 [+], Amin Bandali wrote:
> > Hi Sebastian, all,
> Hi,
> 
> > Will this fix be enough for addressing all cases, though?
> 
> I think so. Do you have a test case for me to check?

Not about pristine-xz specifically; I meant more in the context of
other devel tools like gbp et al.

> > I'm thinking specifically of cases where tarball repacking
> > is involved, for example when using git-buildpackage's
> > "gbp import-orig --uscan" where uscan is used to download and
> > repack the upstream tarball, because the package at hand has
> > a Files-Excluded field in its debian/copyright header stanza.
> > As far as I can tell, Devscripts::Compression would need to be
> > updated to specify -T1 for xz compressions.
> > 
> > I believe there are also some cases where git-buildpackage
> > itself does repacking, so we'd probably want to update its
> > gbp.pkg.compressor's Opts to pass in -T1 for xz.
> 
> Who is handling the compression in the first place here?

In the case of "gbp import-orig --uscan", gbp invokes uscan, part of
the devscripts package which has several perl modules including
Devscripts::Compression which is a sort of a wrapper around dpkg's
Dpkg::Compression, which will ultimately run the 'xz' executable.

In some other cases like "gbp import-orig --filter" mentioned by
Andrey, gbp does the compression itself.  Which is why I suggested
that 'Opts' in gbp.pkg.compressor may need to be updated to add '-T1'
for calls to 'xz'.

> The idea is to pass -T1 to xz if nothing was recorded in pristine-tar's
> delta information. If the -T argument then everything keeps working
> as-is. If you use gbp to repack the tar archive then I would recommend
> to no pass -T1 and to use multi-threaded compression. pristine-tar
> will recongnise this and record this information.

Sorry I don't think I fully understood this bit.  Could you please
explain again, perhaps a bit more verbosely?

To clarify, the use-cases described earlier involving gbp and
devscripts aren't necessarily related to pristine-xz, used for
regenerating pristine xz files; rather, about the generation or
repacking of xz files *before* they are handed to pristine-xz for
processing and storage in the repo.  I was trying to imply that
similarly to how you sent patches for pristine-tar to adapt it for
changes in xz-utils, that similar patches are probably also needed
for gbp and devscripts.  Does that make sense?

> Sebastian
> 

Thanks,
-amin

Bug#1066060: libpam-modules: pam_lastlog.so missing

[Mourad De Clerck]

Package: libpam-modules
Version: 1.5.3-6
Severity: normal

I noticed the following line in my logs:

login[2449]: PAM unable to dlopen(pam_lastlog.so): 
/usr/lib/security/pam_lastlog.so: cannot open shared object file: No such file 
or directory

I looked in the deb files from snapshot.debian.org, and noticed the last version
that had it was 1.5.2-9.1 - starting from 1.5.3-1 it disappeared.

Maybe it's fallout from the time_t transition and you're already aware of it, in
which case feel free to close.

Thanks,

-- M

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

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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 libpam-modules depends on:
ii  debconf [debconf-2.0]  1.5.86
ii  libaudit1  1:3.1.2-2.1
ii  libc6  2.37-15.1
ii  libcrypt1  1:4.4.36-4
ii  libpam-modules-bin 1.5.3-6
ii  libpam0g   1.5.3-6
ii  libselinux13.5-2
ii  libsystemd0255.4-1+b1

libpam-modules recommends no packages.

libpam-modules suggests no packages.

-- debconf information excluded

Bug#1063376: How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)

[James McCoy]

On Mon, Mar 11, 2024 at 09:12:30PM +0100, Andreas Tille wrote:
> Hi,
> 
> Am Mon, Mar 04, 2024 at 06:25:50PM + schrieb Thorsten Alteholz:
> > Control: tags -1 + moreinfo
> > 
> > please file one RM bug for each package that needs to be partially removed.
> > This needs to be done even for dependencies of dependencies.
> > Please remove the moreinfo tag once that is done.
> 
> As Thorsten wrote above[1] every single package needs its own bug to
> enable ftpmaster removing the binary packages of 32bit architectures for
> about 40 packages (currently affected by testing removals).
> 
> I hope there is some better solution than sending single bug reports
> for those packages.

Sounds like a use case for devscript's mass-bug(1).

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1066059: libreswan: CVE-2024-2357

[Salvatore Bonaccorso]

Source: libreswan
Version: 4.12-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 https://github.com/libreswan/libreswan/issues/1609
Control: found -1 4.10-2+deb12u1
Control: found -1 4.10-2
Control: found -1 4.3-1+deb11u4
Control: found -1 4.3-1

Hi,

The following vulnerability was published for libreswan.

CVE-2024-2357[0]:
| The Libreswan Project was notified of an issue causing libreswan to
| restart under some IKEv2 retransmit scenarios when a connection is
| configured to use PreSharedKeys (authby=secret) and the connection
| cannot find a matching configured secret. When such a connection is
| automatically added on startup using the auto= keyword, it can cause
| repeated crashes leading to a Denial of Service.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-2357
https://www.cve.org/CVERecord?id=CVE-2024-2357
[1] https://libreswan.org/security/CVE-2024-2357/CVE-2024-2357.txt
[2] https://github.com/libreswan/libreswan/issues/1609

Regards,
Salvatore

Bug#1066058: libvirt: CVE-2024-1441

[Salvatore Bonaccorso]

Source: libvirt
Version: 10.0.0-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 9.0.0-4
Control: found -1 7.0.0-3+deb11u2
Control: found -1 7.0.0-3

Hi,

The following vulnerability was published for libvirt.

CVE-2024-1441[0]:
| An off-by-one error flaw was found in the
| udevListInterfacesByStatus() function in libvirt when the number of
| interfaces exceeds the size of the `names` array. This issue can be
| reproduced by sending specially crafted data to the libvirt daemon,
| allowing an unprivileged client to perform a denial of service
| attack by causing the libvirt daemon to crash.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-1441
https://www.cve.org/CVERecord?id=CVE-2024-1441
[1] 
https://gitlab.com/libvirt/libvirt/-/commit/c664015fe3a7bf59db26686e9ed69af011c6ebb8

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1060736: Would you agree with swapping Maintainer and Uploaders in eric?

[Andreas Tille]

Hi Gudjon,

in case you agree with the suggested change of policy discussed on the
debian-python mailing list[1] would you agree to set DPT as maintainer?
If yes, I'd volunteer to do this, fix bug #1065855 and #1060736.

Kind regards and thanks for working on this package
Andreas.


[1] https://lists.debian.org/debian-python/2024/02/msg00052.html

-- 
http://fam-tille.de

Bug#1066057: libhalide17-1-dev has an undeclared file conflict

[Helmut Grohne]

Package: libhalide17-1-dev
Version: 17.0.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + libhalide17-0-dev

libhalide17-1-dev has an undeclared file conflict. This may result in an
unpack error from dpkg.

The files
 * /usr/lib/x86_64-linux-gnu/cmake/Halide17/Halide-shared-deps.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/Halide17/Halide-shared-targets-release.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/Halide17/Halide-shared-targets.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/Halide17/HalideConfig.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/Halide17/HalideConfigVersion.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/FindHalide_WebGPU.cmake
 * 
/usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/Halide-Interfaces-release.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/Halide-Interfaces.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/HalideGeneratorHelpers.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/HalideHelpersConfig.cmake
 * 
/usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/HalideHelpersConfigVersion.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/HalideTargetHelpers.cmake
 * /usr/lib/x86_64-linux-gnu/cmake/HalideHelpers17/TargetExportScript.cmake
 * /usr/lib/x86_64-linux-gnu/halide17/adams2019_retrain_cost_model
 * /usr/lib/x86_64-linux-gnu/halide17/adams2019_weightsdir_to_weightsfile
 * /usr/lib/x86_64-linux-gnu/halide17/anderson2021_retrain_cost_model
 * /usr/lib/x86_64-linux-gnu/halide17/anderson2021_weightsdir_to_weightsfile
 * /usr/lib/x86_64-linux-gnu/halide17/featurization_to_sample
 * /usr/lib/x86_64-linux-gnu/halide17/get_host_target
 * /usr/lib/x86_64-linux-gnu/halide17/libautoschedule_adams2019.so
 * /usr/lib/x86_64-linux-gnu/halide17/libautoschedule_anderson2021.so
 * /usr/lib/x86_64-linux-gnu/halide17/libautoschedule_li2018.so
 * /usr/lib/x86_64-linux-gnu/halide17/libautoschedule_mullapudi2016.so
 * /usr/lib/x86_64-linux-gnu/libHalide17.so
 * /usr/lib/x86_64-linux-gnu/libHalidePyStubs17.a
are contained in the packages
 * libhalide17-0-dev/17.0.0-2 as present in trixie
 * libhalide17-1-dev/17.0.1-1 as present in unstable

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

Kind regards

The Debian Usr Merge Analysis Tool

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

Bug#1066051: openjdk-8: make package usable on systems without t64 packages

[Thorsten Glaser]

close 1066051
thanks

Fab Stz dixit:

>I usually install openjdk-8 from unstable on bookworm.

This has never been officially supported. I’ve had an entire
discussion around that last month, which I will quote parts
from below, for context.

>However this is not possible anymore because now it depends on t64 packages.

Yes, this is to be expected.

>Would it be possible to still install it on systems without t64 by
>updating the dependencies/build-depends?

No.

But (see the background information below) I’ll be making available
openjdk-8 packages built for bookworm in the “wtf-lts” extrepo soon
(with the next upload, which will be done once the t64 transition
has settled, i.e. in some days) if you don’t mind an inofficial repo
(though operated by the same person who uploads the package to Debian
proper so…), although for amd64 and i386 only at the moment, as I lack
hardware to build for other platforms (tell me if you need that).

The RSS feed for the wtf extrepo will tell you when. You can obtain that
at http://www.mirbsd.org/~tg/Debs/NEWS.rss (s/\.rss// for plaintext).

Quotes, some paraphrased, follow. Cc’ing the relevant bug for archival
and public readability.



OpenJDK 8 is included with Debian 9 (stretch) only, although it has
been retrofitted to Debian 8 (jessie) for ELTS as it still is actively
maintained, in contrast to jessie’s OpenJDK 7.

Debian 10 and 11 shipped OpenJDK 11, due to misalignment between
Debian’s and OpenJDK-LTS’ release cycles.

> (why does #989736 to keep OpenJDK out of testing and stable exist?)

The reason behind it is that every Debian release contains exactly
one, and only one, supported OpenJDK version; the security team does
not have resources for more (unlike commercial distributions, nobody
is paid for their work).

OpenJDK 8 had already been dropped from Debian, but I’ve resurrected
it and took over maintenance. We still use it in Debian proper for:

• staging new releases for ELTS (ELTS is not part of Debian proper
  but an external offering, although basically done by the same people)

• bootstrapping new environments (like Kotlin) that depend on JDK 8
  for their bootstrapping process

This is all done in “unstable”; Kotlin was only able to enter “testing”
once it met the release goals for the “next-stable”, that is to build
with that then-future release’s default JDK.

> There are a number of applications still depending on Java 8.

Most of these should still run with 11 at least, even if they can
only be built on 8 or with special options (I wrote a Maven parent POM
that manages this).

I know of exceptions that use undocumented/inofficial interfaces that
are not actually part of the JDK’s API. For these, it’s really SOL…

I personally don’t have a problem with making OpenJDK 8 releases
available for other Debian releases; this is in fact how my involvement
in this started (I did it for a customer but also made the results
publicly available). If you don’t mind external repositories, you can
use the builds from there.

I recently stopped making builds for Debian 7 (wheezy) even if that
is technically still feasible, because it is no longer supported by
even ELTS.

Debian 8 and 9 are provided OpenJDK 8 by Freexian ELTS.

I produce builds for Debian 10 and 11, amd64 and i386 only (I lack
the machines to do more currently).

I don’t provide these packages for Debian 12 because I do not use
the latter and have no way to test them and can so save time.

Given incentive (a nice offer) I might add more to this mix.

I also provide OpenJDK 8 for all *buntu LTS releases that Canonical
allows Launchpad to build for, for all architectures the respective
releases have, via a PPA.

> (would be convenient to add openjdk-8 to stable)

Once a Debian stable is released, packages aren’t added to it any
more, barring special cases in LTS/ELTS releases like the aforementioned
switching jessie from OpenJDK 7 to 8, or they all getting newer kernels.

> (does the bugreport mean it will forever be blocked from making it to stable?)

Yes, it blocks OpenJDK 8 from ever reaching testing, and a new stable
is made by copying a frozen testing at the point in time where the
release gets made.

This is, indeed, the purpose of that debbugs item. The “Outlook” and
the first message should have made that clear. (The latter also said
to contact me so all is fine.)

This is the compromise that allowed OpenJDK 8 to be kept in Debian
at all, i.e. in Debian unstable; otherwise the security team would
have veto’d this. There is no way for OpenJDK 8 to be supported in
a stable Debian release any more.

That doesn’t mean I desupport this in the package itself. While I
don’t build for or test on wheezy or precise any more, these two
and anything newer, up to the latest respective releases, should
work, and I occasionally do things to make it so. You just have to
obtain them from elsewhere than Debian itself… or, of course, do
the 

Bug#1066056: vokoscreen-ng: Change depends to allow pipewire/pipewire-pulse

[Wesley Schwengle]

Package: vokoscreen-ng
Version: 3.7.0-1
Severity: wishlist
X-Debbugs-Cc: wes...@schwengle.net

Dear Maintainer,

apt-cache depends vokoscreen-ng

[snip]
Recommends: pulseaudio
[snip]

Could you add an OR here with pipewire and/or pipewire-pulse?

Many thanks!


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'experimental'), (500, 'testing'), (10, 
'stable-updates'), (10, 'stable-security'), (10, 'oldstable-security'), (10, 
'oldoldstable'), (10, 'stable'), (10, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.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

Versions of packages vokoscreen-ng depends on:
ii  gstreamer1.0-plugins-good   1.24.0-1
ii  libc6   2.38-6
ii  libgcc-s1   14-20240303-1
ii  libglib2.0-0t64 [libglib2.0-0]  2.78.4-4
ii  libgstreamer1.0-0   1.24.0-1
ii  libpulse0   16.1+dfsg1-3+b1
ii  libqt5core5t64 [libqt5core5a]   5.15.10+dfsg-7.2
ii  libqt5dbus5t64 [libqt5dbus5]5.15.10+dfsg-7.2
ii  libqt5gui5t64 [libqt5gui5]  5.15.10+dfsg-7.2
ii  libqt5multimedia5   5.15.10-2+b2
ii  libqt5network5t64 [libqt5network5]  5.15.10+dfsg-7.2
ii  libqt5widgets5t64 [libqt5widgets5]  5.15.10+dfsg-7.2
ii  libqt5x11extras55.15.10-2+b1
ii  libstdc++6  14-20240303-1
ii  libwayland-client0  1.22.0-2.1+b1
ii  libx11-62:1.8.7-1

Versions of packages vokoscreen-ng recommends:
ii  gstreamer1.0-libav 1.24.0-1
ii  gstreamer1.0-pulseaudio1.24.0-1
ii  libqt5multimedia5-plugins  5.15.10-2+b2
pn  pulseaudio 

Versions of packages vokoscreen-ng suggests:
ii  gstreamer1.0-plugins-bad   1.24.0-1
ii  gstreamer1.0-plugins-ugly  1.24.0-1
ii  gstreamer1.0-vaapi 1.24.0-1
ii  intel-media-va-driver  24.1.0+dfsg1-1

-- no debconf information

Bug#1066055: rust-symphonia-core: FTBFS on i386 units::tests::verify_timebase panic

[Mike Gerow]

Source: rust-symphonia-core
Version: 0.5.2-1
Severity: important
Tags: ftbfs

rust-symphonia-core appears to FTBFS from an i386 sbuild chroot with a
test 'units::tests::verify_timebase' panicking

 units::tests::verify_timebase stdout 
thread 'units::tests::verify_timebase' panicked at 'assertion failed:  
`(left == right)`

  left: `4503599627370496`,
 right: `4503599627370497`', src/units.rs:257:9
stack backtrace:
   0: rust_begin_unwind
 at /usr/src/rustc-1.70.0/library/std/src/panicking.rs:578:5
   1: core::panicking::panic_fmt
 at /usr/src/rustc-1.70.0/library/core/src/panicking.rs:67:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
 at /usr/src/rustc-1.70.0/library/core/src/panicking.rs:228:5
   4: symphonia_core::units::tests::verify_timebase
 at  
/usr/share/cargo/registry/symphonia-core-0.5.2/src/units.rs:257:9

   5: symphonia_core::units::tests::verify_timebase::{{closure}}
 at  
/usr/share/cargo/registry/symphonia-core-0.5.2/src/units.rs:236:26

   6: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
   7: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.70.0/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a  
verbose backtrace.


This failure also seems present on the latest attempt from buildd[1].

[1]:  
https://buildd.debian.org/status/fetch.php?pkg=rust-symphonia-core=i386=0.5.2-1%2Bb1=170585=0

Bug#1066054: spacearyarya FTBFS due to -Werror=implicit-function-declaration

[Helmut Grohne]

Source: spacearyarya
Version: 1.0.2-8
Severity: serious
Tags: ftbfs

Due to the time64 transition, -Werror=-implicit-function-declaration was
enabled in default build flags and this makes spacearyarya FTBFS: Please
include the time.h header.

| gcc -DPACKAGE_NAME=\"SpaceAryarya-KXL\" 
-DPACKAGE_TARNAME=\"spacearyarya-kxl\" -DPACKAGE_VERSION=\"1.0.2\" 
-DPACKAGE_STRING=\"SpaceAryarya-KXL\ 1.0.2\" 
-DPACKAGE_BUGREPORT=\"m...@kxl.hn.or\" -DPACKAGE_URL=\"\" 
-DPACKAGE=\"spacearyarya-kxl\" -DVERSION=\"1.0.2\" -DHAVE_LIBKXL=1 
-DHAVE_LIBKXL=1 -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 
-DDATA_PATH=\"/usr/share/games/spacearyarya/data\" 
-DBMP_PATH=\"/usr/share/games/spacearyarya/bmp\" 
-DWAV_PATH=\"/usr/share/games/spacearyarya/wav\" -DTITLE=\"spacearyarya-kxl\ 
1.0.2\" -I.   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -c -o main.o main.c
| main.c: In function ‘options’:
| main.c:144:10: error: implicit declaration of function ‘strcmp’ 
[-Werror=implicit-function-declaration]
|   144 | if (!strcmp(argv[i], "-h") || !strcmp(argv[i], "--help")) {
|   |  ^~
| main.c:7:1: note: include ‘’ or provide a declaration of ‘strcmp’
| 6 | #include "extern.h"
|   +++ |+#include 
| 7 | 
| main.c: In function ‘main’:
| main.c:179:9: error: implicit declaration of function ‘time’ 
[-Werror=implicit-function-declaration]
|   179 |   srand(time(NULL));
|   | ^~~~
| main.c:7:1: note: ‘time’ is defined in header ‘’; did you forget to 
‘#include ’?
| 6 | #include "extern.h"
|   +++ |+#include 
| 7 | 
| misc.c: In function ‘ClearAndGameOver’:
| misc.c:107:5: error: implicit declaration of function ‘ScoreRanking’ 
[-Werror=implicit-function-declaration]
|   107 | ScoreRanking();
|   | ^~~~
| ranking.c: In function ‘ReadScore’:
| ranking.c:41:5: warning: ignoring return value of ‘fscanf’ declared with 
attribute ‘warn_unused_result’ [-Wunused-result]
|41 | fscanf(fp, "%"SCNu32, &(Root->HiScore));
|   | ^~~
| ranking.c:43:7: warning: ignoring return value of ‘fscanf’ declared with 
attribute ‘warn_unused_result’ [-Wunused-result]
|43 |   fscanf(fp, "%"SCNu32" %"SCNu8" %s",
|   |   ^~~
|44 |  &(Ranking[i]->Score),
|   |  ~
|45 |  &(Ranking[i]->Stage),
|   |  ~
|46 |  Ranking[i]->Name);
|   |  ~

Helmut

Bug#1066053: sgrep FTBFS due to -Werror=implicit-function-declaration

[Helmut Grohne]

Source: sgrep
Version: 1.94a-5
Severity: serious
Tags: ftbfs

Due to the time64 transition, default build flags now include
-Werror=implicit-function-declaration. This happens to cause a build
failure for sgrep:

| gcc -DHAVE_CONFIG_H -I. -DDATADIR="\"/usr/share/sgrep\"" 
-DSYSCONFDIR="\"/etc\""  -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-Werror=implicit-function-declaration -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -c -o index_main.o index_main.c
| sysdeps.c: In function ‘check_memory_leaks’:
| sysdeps.c:489:49: warning: format ‘%d’ expects argument of type ‘int’, but 
argument 4 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
|   489 | "Memory leak: %d blocks having %d bytes total size\n",
|   |~^
|   | |
|   | int
|   |%ld
| sysdeps.c:496:32: warning: format ‘%d’ expects argument of type ‘int’, but 
argument 5 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
|   496 | "\t%s:%d: %d 
bytes\n",block->file,block->line,block->size);
|   |   ~^  
~~~
|   ||  
 |
|   |int
 size_t {aka long unsigned int}
|   |   %ld
| index_main.c: In function ‘parse_index_options’:
| index_main.c:84:21: error: implicit declaration of function ‘strcmp’ 
[-Werror=implicit-function-declaration]
|84 | if (strcmp(*argv,"--")==0) return i+1;
|   | ^~
| index_main.c:2:1: note: include ‘’ or provide a declaration of 
‘strcmp’
| 1 | #include "sgrep.h"
|   +++ |+#include 
| 2 |
| index_main.c:138:41: warning: macro "__DATE__" might prevent reproducible 
builds [-Wdate-time]
|   138 | VERSION,__DATE__);
|   | ^~~~
| index_main.c: In function ‘index_main’:
| index_main.c:241:13: error: implicit declaration of function ‘index_query’ 
[-Werror=implicit-function-declaration]
|   241 | if (index_query(,argc-end_options,argv+end_options)
|   | ^~~
| cc1: some warnings being treated as errors
| make[2]: *** [Makefile:488: index_main.o] Error 1

Helmut

Bug#983357: Workaround for #983357

[Leigh Brown]

Hello,

On the XenProject Matrix channel, a user suggested adding "vkb_device=0" 
to the domU config to work around this bug. I have tested the workaround 
and can report that it works for me. I have been able to install using 
the Debian 11.1 and 12.5 netinst ISO images.


Config that I tested:


# Domain name
name= 'vm2'

# CPU and memory configuration
memory  = '2048'
maxmem  = '2048'
vcpus   = 4
maxvcpus= 4
type= 'hvm'

# HVM config
pae=1   # recommended
#acpi=1 # recommended to omit, default is on
#apic=1 # recommended to omit, default is on
#nx=1   # recommended to omit, default is on
serial=[ 'pty' ]
tsc_mode='default'
nomigrate=1
usb=1
usbdevice='tablet'
keymap='en-gb'
# Work around Debian bug #983357
vkb_device=0

# Disk device(s).
boot= 'dc'
hdtype  = 'ahci'
disk= [
'/dev/rootvg/vm2,raw,xvda,w',
#'/var/lib/media/debian-11.1.0-amd64-netinst.iso,raw,hdc,devtype=cdrom',
'/var/lib/media/debian-12.5.0-amd64-netinst.iso,raw,hdc,devtype=cdrom',
  ]

# Framebuffer
vfb=[ 'vnc=1' ]

# Networking
vif = [ 'mac=fe:fd:02:02:23:1f, bridge=br0vl40' ]

# Behaviour
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash= 'restart'


Regards,

Leigh.

Bug#1065841: Taking over datalad to either Debian Med or Debian Science team

[Andreas Tille]

Hi Yaroslav,

once we agreed that we should probably move all Neurodebian packages to
Debian Med to make it accessible for a bigger team.  I was not really
active for some time in this attempt.  However, bug #1065841 brought
datalad on my screen.  I would love to see it maintained on Salsa either
in Debian Science team (since it has wider usage) or Debiam Med (since
we moved Neurodebian packages there).

I'd volunteer to do the move if you agree to and by doing so also fix
the two open bugs and run some `routine-update` on the packaging.

What do you think?

Kind regards
   AndreasI'd volunteer to do the move if you agree to and by doing so also fix
the two open bugs and run some `routine-update` on the packaging.

What do you think?

Kind regards
   Andreas.

-- 
http://fam-tille.de

Bug#1063376: How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)

[Holger Levsen]

On Mon, Mar 11, 2024 at 08:26:40PM +, Holger Levsen wrote:
>   do mutt -s "RM: remove $package" -i tmpfile $package

the 2nd $package in that line must be sub...@bugs.debian.org


-- 
cheers,
Holger

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

“We live in capitalism. Its power seems inescapable. So did the divine right
 of kings. Any human power can be resisted and changed by human beings.
 Resistance and change often begin in art, and very often in our art, the art
 of words.” ― Ursula K. Le Guin


signature.asc
Description: PGP signature

Bug#1063376: How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)

[Holger Levsen]

On Mon, Mar 11, 2024 at 09:12:30PM +0100, Andreas Tille wrote:
> I hope there is some better solution than sending single bug reports
> for those packages.  If ftpmaster tooling really needs single bug
> reports I wonder how I can automatically create such bug reports with
> always the same text, just targeting at different binary packages.
> 
> This also should include some means to work around the less than 5
> bug reports per hour SPAM protection means of BTS.

foo="bin1
bin2
bin3"

$file=/some/path/to/bugreport_without_package_line.txt
tmpfile=$(mktemp)

for package in $foo ; do
( echo "package: $package" ;
  cat $file ) > $tmpfile
do mutt -s "RM: remove $package" -i tmpfile $package
sleep 15m
done
rm $tmpfile

with 40 packages this is just a 10h running script ;)


-- 
cheers,
Holger

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

If you’re going through hell, keep going!


signature.asc
Description: PGP signature

Bug#1065914: opm-simulators: Please drop dependencies on python3-distutils

[Markus Blatt]

Hi,

there is already a version (2023.10+ds-2) uploaded to unstable with the  
python3-distutils
dependency. We just need to for it's migration.

Best,

Markus

Bug#1063376: How to ask efficiently for removal of 32 bit architectures of about 40 packages (Was: reverse dependenc)

[Andreas Tille]

Hi,

Am Mon, Mar 04, 2024 at 06:25:50PM + schrieb Thorsten Alteholz:
> Control: tags -1 + moreinfo
> 
> please file one RM bug for each package that needs to be partially removed.
> This needs to be done even for dependencies of dependencies.
> Please remove the moreinfo tag once that is done.

As Thorsten wrote above[1] every single package needs its own bug to
enable ftpmaster removing the binary packages of 32bit architectures for
about 40 packages (currently affected by testing removals).

I hope there is some better solution than sending single bug reports
for those packages.  If ftpmaster tooling really needs single bug
reports I wonder how I can automatically create such bug reports with
always the same text, just targeting at different binary packages.

This also should include some means to work around the less than 5
bug reports per hour SPAM protection means of BTS.

Any help would be welcome
 Andreas.

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

-- 
http://fam-tille.de

Bug#1066049: stunnel4: please consider temporarily disabling tests on arm to unblock the t64 transition

[Simon McVittie]

On Mon, 11 Mar 2024 at 19:54:00 +0100, Mattia Rizzolo wrote:
> +ifeq ($(DEB_HOST_ARCH_BITS)$(filter i386,$(DEB_HOST_ARCH_CPU)),32)
>  execute_before_dh_auto_test:
>   env PYTHONPATH='$(CURDIR)/debian/tests/python' \
>   python3 -B -u -m struntime \
>   --certdir='$(CURDIR)/debian/tests/certs' \
>   --program='$(CURDIR)/src/stunnel'
> +endif
>  
> +ifeq ($(DEB_HOST_ARCH_BITS)$(filter i386,$(DEB_HOST_ARCH_CPU)),32)
>  override_dh_auto_test:
>   dh_auto_test || { \
>   printf '\n\n=== Some tests failed; here are all the 
> logs...\n\n' 1>&2; \
>   find tests/logs/ -type f -name '*.log' -exec grep -EHe '^' -- 
> '{}' + 1>&2; \
>   false; \
>   }
> +endif

Thanks for proposing this, but I think these should be ifneq instead
of ifeq: the current implementation looks like it's running tests on
exactly those architectures where you don't want to run tests :-)

The expression before the comma will expand to:

- 64: on amd64, arm64, s390x, etc. (we still want to run tests)
- 32: on armel, armhf, hppa, etc. (we don't want to run tests)
- 32i386: on i386 (we still want to run tests, because as a special
  exception, i386 does not get 64-bit time_t)

so we want to run the tests if it expands to anything other than 32.

The two if(n)eq..endif blocks could also be combined into one, to make
it more obvious that their condition is the same.

smcv

Bug#1066052: gcc-13: several acats tests raise ADA.CALENDAR.TIME_ERROR : a-calend.adb:601

[John David Anglin]

Source: gcc-12
Version: 12.3.0-15
Severity: normal

Dear Maintainer,

In test log, I see a number of tests with following error:

splitting /build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/testsuite/ada/acats1/test
s/a/a26007a.adt into:
   a26007a.adb
BUILD a26007a.adb
/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/gnatmake 
--GNATBIND=/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/gnatbind 
--GNATLINK=/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/gnatlink 
--GCC=/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/xgcc 
-B/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/ -gnatws -O2 -gnat95 
-I/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/testsuite/ada/acats1/../acats/support
 a26007a.adb -largs --GCC=/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/xgcc 
-B/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/
/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/xgcc -c 
-B/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/ -gnatws -O2 -gnat95 
-I/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/testsuite/ada/acats1/../acats/support
 a26007a.adb
/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/gnatbind 
-I/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/testsuite/ada/acats1/../acats/support
 -x a26007a.ali
/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/gnatlink a26007a.ali -O2 
--GCC=/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/xgcc 
-B/build/gcc-12-TxDF5I/gcc-12-12.3.0/build/gcc/
RUN a26007a


raised ADA.CALENDAR.TIME_ERROR : a-calend.adb:601
FAIL:   a26007a

Regards,
Dave Anglin


-- System Information:
Debian Release: trixie/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.1.80+ (SMP w/4 CPU threads)
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)

-- no debconf information

Bug#1066051: openjdk-8: make package usable on systems without t64 packages

[Fab Stz]

Source: openjdk-8
Version: 8u402-ga-2
Severity: normal

Dear Maintainer,

I usually install openjdk-8 from unstable on bookworm.
However this is not possible anymore because now it depends on t64 packages.

Would it be possible to still install it on systems without t64 by updating 
the dependencies/build-depends?

Thanks

-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (991, 'stable-updates'), (991, 'stable-security'), (991, 
'stable'), (990, 'proposed-updates'), (390, 'oldstable-security'), (390, 
'oldstable'), (389, 'oldstable-updates'), (380, 'oldoldstable'), (379, 
'oldoldstable-updates'), (370, 'oldoldstable'), (95, 'testing'), (94, 
'unstable'), (93, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#1064921: src:r-cran-estimatr: fails to migrate to testing for too long: autopkgtest regression on i386

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/DeclareDesign/estimatr/issues/407
Control: reopen -1
thanks

I have forwarded this problem upstream.
I've also reopened this bug to make sure it will show up on our sentinel

Kind regards
  Andreas.

-- 
http://fam-tille.de

Bug#1066023: libdebian-installer: Add subarch detection for loongarch64

[John Paul Adrian Glaubitz]

Hi,

On Mon, 2024-03-11 at 16:36 +0800, zhangdandan wrote:
> I have added subarch detection for loongarch64 in libdebian-installer 
> source package.
> Please consider the patch I have attached.
> 
> The libdebian-installer source package was compiled successfully on my 
> local loong64 rootfs environment.
> If you have any questions, you can contact me at any time.

I have just added subarch detection for 64-bit LoongArch [1].

However, the proper filename is "subarch-loong64-linux.c" as the filename
has to match the Debian architecture name, not the GNU triplet name (see
the configure.ac).

Adrian

> [1] 
> https://salsa.debian.org/installer-team/libdebian-installer/-/commit/4ca769d4ba26ca4fa2e35f6932ee2a123cdf5312

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1064922: src:r-cran-gbm: fails to migrate to testing for too long: autopkgtest regression

[Andreas Tille]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/gbm-developers/gbm/issues/78
Control: reopen -1
thanks

I have forwarded this bug upstream.  I've also re-opened the bug to make
sure it appears on our list of bugs.


-- 
http://fam-tille.de

Bug#1066050: RFP: java-digital -- A digital logic designer and circuit simulator

[Matthias Geiger]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: pkg-electronics-de...@alioth-lists.debian.net, 
werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: java-digital
  Version : 0.30
  Upstream Contact: Helmut Neemann 
* URL : https://github.com/hneemann/Digital
* License : GPL-3
  Programming Lang: Java
  Description : A digital logic designer and circuit simulator

digital is a nice program to simulate logic circuits. It supports a wide
range of features, like verilog/ VDHL export, 74xx symbols and state
machine support.
.
The source package could probably use a better name.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmXvXioVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1QW0P/iaNUiTDA84NJIZEbWYNitfZskWY
dm/diQbTgN4GUbLbXsoYvGRp7ZFmEfxNYvEnew7fk5YOp7r0Uzpg84lhy75iynEn
d8xlsWp8dohFIJmlFX63n+nUVTk6N8tmwd17w/jQJELK1ZdbwgiyuFauscG0X2zt
K79rGKmzoYhxdAdBCrrE7QpgSBVKSWCtD/wgN44sDKy5HKJOqJvtUKuc+cQt8JFI
A3sARvsHMHb48xSgAbButUBnA3r87PmhTilZ0GQpZfb8nA895dK/2wjZc6tN8oUM
tzkxWQEVM9oGQNBV9ELg9RxBT7N0hvmirKSc9I6z8UCl+w++LNn9Bo9O611PvumB
Us4ObwzlLbI9XXO+CpblkYWIU7cZ/lAU/uVqd34rmJ64wwWWRH3Ut02AFFehcahk
JfzI/HjkpjtncxC9Z4X4lsXS6jTZWhjAROg0xYJpgCxjkWMZpk4zB/WyB9BUMXjH
HBmVx831wQv3M/+KeOGmz5dwsVwWbNYe0CwrGka3fCZZ1yiHrMoZ1Ev/iHdy4xjb
/hNi3JENo/JontZE1KBKf8Rb07YpXfHeeAt0YLhDVnn4e1jrSk7QYJiM/4nt78RD
CpR+18llNbIMVI+4sEOEGE9HpkSIygglk8aY999P1UvIQpmnXJqJQDBqGONNBt62
aTLPTnJ7x8xvE/nY
=g3jO
-END PGP SIGNATURE-

Bug#1066049: stunnel4: please consider temporarily disabling tests on arm to unblock the t64 transition

[Mattia Rizzolo]

Source: stunnel4
Version: 3:5.72-1
Severity: wishlist
Tags: patch

Hello Peter,

In #-devel a couple of us (not related to the people working on the t64
transition) thought it would be a good idea if stunnel4 could
temporarily disable tests on the involved architectures (all 32 bits
archs except i386).

rebuilds of stunnel4 are blocked being rebootstrapping rustc and cargo,
and stunnel is itself blocking libssl3 and everything under it from
progressing.
It feels like detaching stunnel from the rust world is an easy enough
pick to let everything else progress while somebody works on rust/cargo.


I'm attaching a patch that should do what I explained above, please
consider uploading it?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
diff --git a/debian/control b/debian/control
index f32dc6f..f34acbd 100644
--- a/debian/control
+++ b/debian/control
@@ -10,13 +10,13 @@ Build-Depends:
  libssl-dev,
  libsystemd-dev [linux-any],
  libwrap0-dev,
- net-tools ,
- netcat-openbsd ,
+ net-tools [!armel !armhf !hppa !m68k !powerpc !sh4] ,
+ netcat-openbsd [!armel !armhf !hppa !m68k !powerpc !sh4] ,
  openssl,
  pkgconf,
- procps ,
- python3 ,
- python3-cryptography ,
+ procps [!armel !armhf !hppa !m68k !powerpc !sh4] ,
+ python3 [!armel !armhf !hppa !m68k !powerpc !sh4] ,
+ python3-cryptography [!armel !armhf !hppa !m68k !powerpc !sh4] ,
 Maintainer: Peter Pentchev 
 Uploaders: Laszlo Boszormenyi (GCS) 
 Standards-Version: 4.6.2
diff --git a/debian/rules b/debian/rules
index 8801c88..0507219 100755
--- a/debian/rules
+++ b/debian/rules
@@ -30,18 +30,22 @@ override_dh_auto_configure:
 	sleep 1
 	touch src/dhparam.c
 
+ifeq ($(DEB_HOST_ARCH_BITS)$(filter i386,$(DEB_HOST_ARCH_CPU)),32)
 execute_before_dh_auto_test:
 	env PYTHONPATH='$(CURDIR)/debian/tests/python' \
 		python3 -B -u -m struntime \
 		--certdir='$(CURDIR)/debian/tests/certs' \
 		--program='$(CURDIR)/src/stunnel'
+endif
 
+ifeq ($(DEB_HOST_ARCH_BITS)$(filter i386,$(DEB_HOST_ARCH_CPU)),32)
 override_dh_auto_test:
 	dh_auto_test || { \
 		printf '\n\n=== Some tests failed; here are all the logs...\n\n' 1>&2; \
 		find tests/logs/ -type f -name '*.log' -exec grep -EHe '^' -- '{}' + 1>&2; \
 		false; \
 	}
+endif
 
 override_dh_auto_install:
 	dh_auto_install -- -C src


signature.asc
Description: PGP signature

Bug#1052362: wpasupplicant: Fails to authenticate to iPhone 14 Personal Hotspot

[Andrej Shadura]

Control: notfound -1 2:2.10-12

Hi,

On Mon, 11 Mar 2024, at 18:24, Charles Curley wrote:
> On Wed, 20 Sep 2023 16:24:46 -0600 Charles Curley
>  wrote:
>> Package: wpasupplicant
>> Version: 2:2.10-12
>> Severity: normal
>> X-Debbugs-Cc: charlescur...@charlescurley.com
>
> I inadvertently solved this by upgrading the kernel from
> linux-image-6.1.0-18-amd64 to linux-image-6.5.0-0.deb12.4-amd64.

Great, makes this an easy bug 

> Does anybody read signatures any more?

I do!

-- 
Cheers,
  Andrej

Bug#986597: Screen Capture of gammastep-indicator

[Charles Curley]

On Thu, 8 Apr 2021 14:43:31 -0600 Charles Curley
 wrote:
> On Wed, 7 Apr 2021 15:19:36 -0700
> Felix Lechner  wrote:
> 

> Would you mind raising this issue upstream?
> > [1]
> 
> Done. https://gitlab.com/chinstrap/gammastep/-/issues/31

I have closed the upstream bug. I'll close this one shortly.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bug#1065435: aptitude: FTBFS on armhf and armel (probably -Werror=implicit-function-declaration related)

[Christoph Biedl]

Axel Beckert wrote...

> Citing from https://buildd.debian.org/status/package.php?p=aptitude:
(...)
> /usr/include/cppunit/TestAssert.h:161:6: note:   template argument 
> deduction/substitution failed:
> ../../tests/test_misc.cc:187:5: note:   deduced conflicting types for 
> parameter ‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long int’})
>   187 | CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);
>   | ^
> make[3]: *** [Makefile:869: test_misc.o] Error 1
(...)

This happens on armel, armhf, powerpc, and hppa. Guess which
architectures I'm using ... also, aptitude is configured as b-d resolver
here for a reason but the last, pre-t64 version is no longer
installable. So I'm somewhat stuck.

Therefore, any progress on this? Do you need help? I didn't get very far
at a first glance, aptitude's build dependencies are currently
uninstallable, at least in arm{el,hf}.

Christoph


signature.asc
Description: PGP signature

Bug#1065742: dh_install: cannot use empty lines or comments in substitution

[Andreas Metzler]

On 2024-03-10 Niels Thykier  wrote:
> Andreas Metzler:
[...]
>> supporting build-profiles like nodoc with dh_install seems to cumbersome.

> Any reason for not using dh_installdocs, which does `nodoc` out of the box?

Hello Niels

Because for this specific case I need to handle files outside of
/usr/share/doc/$package.

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

Bug#1052362: wpasupplicant: Fails to authenticate to iPhone 14 Personal Hotspot

[Charles Curley]

On Wed, 20 Sep 2023 16:24:46 -0600 Charles Curley
 wrote:
> Package: wpasupplicant
> Version: 2:2.10-12
> Severity: normal
> X-Debbugs-Cc: charlescur...@charlescurley.com

I inadvertently solved this by upgrading the kernel from
linux-image-6.1.0-18-amd64 to linux-image-6.5.0-0.deb12.4-amd64.

Thank you.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Bug#1053147:

[Gianfranco Costamagna]

Control: close -1Thanks
This should be fixed already.
G.

Bug#1065424: [Pkg-openssl-devel] Bug#1065424: Bug#1065424: Can't connect to Active Directory with openssl

[Sebastian Andrzej Siewior]

On 2024-03-11 13:29:10 [+0100], Maciej Bogucki wrote:
> Hi,
Hi,

> When I use stiati compiled openssl form different system I can have the
> connection
> 
> root@nsd-sdproxy1:~# /tmp/openssl version
> OpenSSL 1.0.1t  3 May 2016

that is stone age.

> root@nsd-sdproxy1:~# /tmp/openssl  s_client -connect 192.168.92.95:636
> -CAfile /etc/ssl/certs/ca-certificates.crt

What happens if you add
-cipher DEFAULT:@SECLEVEL=0

> On teh remote side is Windows 2008 with Active Directory over SSL/TLS.

My condolences. If you can, get rid of it. It will haunt you!

> Pozdrawiam serdecznie
> Maciej Bogucki

Sebastian

Bug#1066047: icingaweb2-module-incubator: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-incubator
Version: 0.20.0-2
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for
icingaweb2-module-incubator
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers


icingaweb2-module-incubator_0.20.0-2_templates.pot.bz2
Description: application/bzip

Bug#1065751: pristine-tar: diff for NMU version 1.50+nmu2

[Sebastian Andrzej Siewior]

On 2024-03-11 00:05:54 [+], Amin Bandali wrote:
> Hi Sebastian, all,
Hi,

> Will this fix be enough for addressing all cases, though?

I think so. Do you have a test case for me to check?

> I'm thinking specifically of cases where tarball repacking
> is involved, for example when using git-buildpackage's
> "gbp import-orig --uscan" where uscan is used to download and
> repack the upstream tarball, because the package at hand has
> a Files-Excluded field in its debian/copyright header stanza.
> As far as I can tell, Devscripts::Compression would need to be
> updated to specify -T1 for xz compressions.
> 
> I believe there are also some cases where git-buildpackage
> itself does repacking, so we'd probably want to update its
> gbp.pkg.compressor's Opts to pass in -T1 for xz.

Who is handling the compression in the first place here?
The idea is to pass -T1 to xz if nothing was recorded in pristine-tar's
delta information. If the -T argument then everything keeps working
as-is. If you use gbp to repack the tar archive then I would recommend
to no pass -T1 and to use multi-threaded compression. pristine-tar
will recongnise this and record this information.

> Thanks,
> -a

Sebastian

Bug#1066046: mystic: fails autopkgtests on i386, armel, armhf, ppc64el

[Julian Gilbey]

Source: mystic
Version: 0.4.2-1
Severity: serious
Tags: upstream

The autopkgtests are failing on mystic/tests/test_collapse.py, line
177.

Making this bug report to track progress.

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[David Kalnischkies]

On Mon, Mar 11, 2024 at 05:09:47PM +0100, Miguel Angel Rojas wrote:
> Yes, it is confusing for me too. Without considering this t64 migration,
> “apt upgrade” should *NOT* remove any package (just upgrading a package to
> a newer version or install new dependencies). But it is removing packages
> right now! i.e. again, with this t64 migration, it makes the old libraries
> to be uninstalled and install the new *t64 version.
> 
> Any thoughts why “apt upgrade” is removing packages even when documentation
> says it shouldn’t? or is it a bug?

If "apt upgrade" is saying that it removes packages, that is a bug, yes.

Please run: apt upgrade -s -o Dir::Log::Solver=/tmp/apt-upgrade-bug.edsp.xz
(as normal user; the -s enables simulation so nothing bad can happen)

That will create a /tmp/apt-upgrade-bug.edsp.xz file (a few MBs big) you
can sent to me (it might be too big for a bug and/or the mailinglist).
That file contains information about all packages currently available to
you and which of them you have installed – as that changes quiet often
and its near impossible to reproduce a problem, especially while a big
transition is underway, otherwise.

If that package-removing upgrade happened in the past, you can look it
up in /var/log/apt/history.log – far less details and harder to
reproduce, but at least some chance…


I do have to note that I am somewhat dubious through. I have heard that
claim quiet often recently and so far it turned out not to be an "apt
upgrade" invocation in the end, confusing it with autoremove remarks or
didn't expect that some non-t64 and t64 packages became co-installable…
but never say never.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1066045: maven-bundle-plugin: produces nondeterministic ordering in MANIFEST.MF headers

[James Addison]

Package: libmaven-bundle-plugin-java
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain

Dear Maintainer,

The maven-bundle-plugin utility creates Java .jar archives that contain
non-deterministic contents in the Export-Package, Private-Package and
Include-Resource header fields of the MANIFEST.MF file when listing those files
from the underlying filesystem returns them in differing order.

There is an exisiting report[1] of this problem upstream in the Apache Felix
project, and it has been resolved by a subsequent change[2] to sort the
contents of the relevant field values before they're written to the manifest.

Please find attached a backport of the upstream changeset, which applies
cleanly to the maven-bundle-plugin-3.5.1 sources.

Thank you,
James

[1] - https://issues.apache.org/jira/browse/FELIX-6602

[2] - https://github.com/apache/felix-dev/pull/208
>From d885d99a6a16660f655a4fd18e8a1a39beef0a15 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Herv=C3=A9=20Boutemy?= 
Date: Sat, 25 Mar 2023 00:18:11 +0100
Subject: [PATCH] FELIX-6602 sort resources and exported packages

---
 .../java/org/apache/felix/bundleplugin/BundlePlugin.java | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/src/main/java/org/apache/felix/bundleplugin/BundlePlugin.java
+++ b/src/main/java/org/apache/felix/bundleplugin/BundlePlugin.java
@@ -1938,6 +1938,7 @@ public class BundlePlugin extends AbstractMojo
 scanner.scan();
 
 String[] paths = scanner.getIncludedFiles();
+Arrays.sort( paths );
 for ( int i = 0; i < paths.length; i++ )
 {
 packages.put( analyzer.getPackageRef( getPackageName( paths[i] 
) ) );
@@ -2076,7 +2077,9 @@ public class BundlePlugin extends AbstractMojo
 scanner.addDefaultExcludes();
 scanner.scan();
 
-List includedFiles = Arrays.asList( 
scanner.getIncludedFiles() );
+String[] f = scanner.getIncludedFiles();
+Arrays.sort( f );
+List includedFiles = Arrays.asList( f );
 
 for ( Iterator j = includedFiles.iterator(); 
j.hasNext(); )
 {
-- 
2.43.0

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Wesley Schwengle]

Hi Miguel,

On Mon, Mar 11, 2024 at 05:09:47PM +0100, Miguel Angel Rojas wrote:
> > I do not know, at times I'm also wondering why it doesn't do it, but I
> didn't
> > take time to look at the code to understand what the resolver is doing.
> Also,
> > it was sort of expected. I think we can probably solve this is a more
> > controlled manner. With the current t64 transitioning in unstable it is
> > difficult to track down. Many updates so the situation now may differ
> from the
> > situation in an hour from now.
> 
> Yes, it is confusing for me too. Without considering this t64 migration,
> “apt upgrade” should *NOT* remove any package (just upgrading a package to
> a newer version or install new dependencies). But it is removing packages
> right now! i.e. again, with this t64 migration, it makes the old libraries
> to be uninstalled and install the new *t64 version.
> 
> Any thoughts why “apt upgrade” is removing packages even when documentation
> says it shouldn’t? or is it a bug?

You keep saying `apt upgrade' yet your command was `apt full-upgrade'. As said
earlier, full-upgrade does indeed remove packages to be able to perform an
upgrade. I haven't seen `apt upgrade' do that. So I cannot comment on apt doing
something wrong when it isn't :)

Cheers,
Wesley

Bug#1066029: secnet: please correct long description that says that hippotat is not packaged

[Ian Jackson]

Tomas Pospisek writes ("Bug#1066029: secnet: please correct long description 
that says that hippotat is not packaged"):
> The secnet long description reads:
> 
> > secnet works well with userv-ipif (allowing it to run without needing root 
> > privilege) and hippotat (not currently in Debian)
> 
> However hippotat seems to be packaged: 
> https://packages.debian.org/search?keywords=hippotat
> 
> Please correct the description.

Hah, thanks for the report :-).  I'll do this next time I work on
secnet, but it may not be soon...

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1066034: tech-ctte: proposed constitution fix and social contract chg to make documentation accessible to all people

[gregor herrmann]

On Mon, 11 Mar 2024 14:37:45 +0100, debbug.tech-c...@sideload.33mail.com wrote:

> The DSC shows “Version 1.2 ratified on October 1st, 2022.” But where
> and how?  The public should have transparent access to the
> discussions, decisions, and changes.

The last change of the DSC happened via a General Resolution, as laid
out by the Constitution, where the voting period ended on 2022-10-01.

Discussion and vote procedure/outcome are publically available:

https://www.debian.org/vote/2022/vote_003

https://lists.debian.org/debian-vote/2022/08/ ff.
 

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#1065807: installation-reports: Verify Installtion Media Fails

[Tom]

That does match my image. I cannot reproduce the error any longer, I'm
wondering if it had to do with an existing windows installation on my
device which has now been replaced with a debian install. I remember it was
a file in the grub folder but i can't remember which one.

On Sun, Mar 10, 2024 at 9:28 AM Steve McIntyre  wrote:

> Hi Neal,
>
> On Sat, Mar 09, 2024 at 08:45:28PM -0500, Neal wrote:
> >
> >(Please provide enough information to help the Debian
> >maintainers evaluate the report efficiently - e.g., by filling
> >in the sections below.)
> >
> >Boot method: USB
> >Image version:
> https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-
> >cd/debian-testing-amd64-netinst.iso 2024-03-07
> >Date: 3/9/24
> >
> >Machine: Lenovo Thinkcenter
> >Partitions: Failed be being set
> >
> >Base System Installation Checklist:
> >[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> >
> >Initial boot:   [O ]
> >Detect network card:[ ]
> >Configure network:  [ ]
> >Detect media:   [ O]
> >Load installer modules: [ ]
> >Clock/timezone setup:   [ ]
> >User/password setup:[ ]
> >Detect hard drives: [ ]
> >Partition hard drives:  [ ]
> >Install base system:[ ]
> >Install tasks:  [ ]
> >Install boot loader:[ ]
> >Overall install:[ ]
> >
> >Comments/Problems:
> >
> >It always detects a file corruption. I verified hash on download and
> verified
> >good usb stick. Same usb was used to install Debian 12 after, which
> correctly
> >verified.
>
> Hmmm. I've just grabed the latest weekly amd64 netinst and tried to
> reproduce your issue. Things work here just fine in a VM, using this
> image:
>
> e618afbebbbdf9495c74140bc87f2a4b  debian-testing-amd64-netinst.iso
>
> Does that match your image?
>
> If the integrity check fails, it should say which file is wrong. What
> did it report for please?
>
> --
> Steve McIntyre, Cambridge, UK.
> st...@einval.com
> "... the premise [is] that privacy is about hiding a wrong. It's not.
>  Privacy is an inherent human right, and a requirement for maintaining
>  the human condition with dignity and respect."
>   -- Bruce Schneier
>
>

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Miguel Angel Rojas]

Hi Wesley,

Good conversation here. Let me give you some comments from my side:

> No, there is (or was) something going on with the dependencies of
gdm-minimal
> for sure. I think it is related to libdebuginfod1, which has a t64
variant.
> This one has a dependency to libelf1 and libdw1. Now the libdebuginfod1t64
> depends on libelf1t64 and libdw1t64. These two replace libelf1 and
libdw1, the
> former having a relative high count of reverse dependencies.

I didn’t catch this one (and I spent a fair amount of time trying to find
out what was going on) ;) Thank you for spotting it!

> I do not know, at times I'm also wondering why it doesn't do it, but I
didn't
> take time to look at the code to understand what the resolver is doing.
Also,
> it was sort of expected. I think we can probably solve this is a more
> controlled manner. With the current t64 transitioning in unstable it is
> difficult to track down. Many updates so the situation now may differ
from the
> situation in an hour from now.

Yes, it is confusing for me too. Without considering this t64 migration,
“apt upgrade” should *NOT* remove any package (just upgrading a package to
a newer version or install new dependencies). But it is removing packages
right now! i.e. again, with this t64 migration, it makes the old libraries
to be uninstalled and install the new *t64 version.

Any thoughts why “apt upgrade” is removing packages even when documentation
says it shouldn’t? or is it a bug?

> I disagree (or agree) to some extent. The gdb-minimal has been held back
on my
> system for a long time. I removed it after I saw it was a remnant of a KDE
> experiment I did. The fact that I can install it now is a change from a
couple
> of days ago. The bug may be the same, but with how unstable it is now with
> this big transition, it's wise to leave it where we are now and break it
down
> into a more controlled reproduction path, where we don't have so many
moving
> pieces.

Yes, I fully agreed with that! Let’s wait until packages are fully settled
down. I have a feeling that it is the same bug but there is no way to probe
it with this transition going on.

Regards



On Mon, Mar 11, 2024 at 3:04 PM Wesley Schwengle 
wrote:

>
> Hello Miguel,
>
> On Mon, Mar 11, 2024 at 09:50:12AM +0100, Miguel Angel Rojas wrote:
>
> > >This problem isn't because of apt, the problem is that gdb-minimal/gdb
> > >  dependencies cannot be satified. A full-upgrade is the equivalent of a
> > >  dist-upgrade which will remove packages to resolve the dependencies.
> The
> > > problem you are facing is the t64 transition[1][2] where not all
> packages
> > are
> > >  transitioned.
> >
> > I haven't detected any "gdb | gdb-minimal dependencies that can't be
> > satisfied at this point. Everything seems to be OK with those packages.
>
> No, there is (or was) something going on with the dependencies of
> gdm-minimal
> for sure. I think it is related to libdebuginfod1, which has a t64 variant.
> This one has a dependency to libelf1 and libdw1. Now the libdebuginfod1t64
> depends on libelf1t64 and libdw1t64. These two replace libelf1 and libdw1,
> the
> former having a relative high count of reverse dependencies.
>
> > >  My advice to you is: don't expect full-upgrade to work until the
> > transitioning
> > >   is done.
> >
> > You nail it here! I have managed to upgrade package by package but it is
> a
> > tedious process until the whole transition is completed.
>
> Some of them yes, but often after doing one, you can use `apt upgrade' to
> see if it resolved other problems (which in my case it does from time to
> time).
>
> > But "apt upgrade"
> > should not remove any packages according to its documentation (man apt)
>
> That is correct, but you were executing full-upgrade:
>
> > > On Sun, Mar 10, 2024 at 02:13:34PM +0100, Miguel Angel wrote:
> > >
> > > > # apt full-upgrade
> > > > Reading package lists... Done
> > > > Building dependency tree... Done
> > > > Reading state information... Done
> > > > Calculating upgrade... Error!
> > > > Some packages could not be installed. This may mean that you have
> > > > requested an impossible situation or if you are using the unstable
> > > > distribution that some required packages have not yet been created
> > > > or been moved out of Incoming.
> > > > The following information may help to resolve the situation:
>
> > Why is this t64 upgrade working then as it is removing deprecated
> packages
> > for *t64 packages?
>
> I do not know, at times I'm also wondering why it doesn't do it, but I
> didn't
> take time to look at the code to understand what the resolver is doing.
> Also,
> it was sort of expected. I think we can probably solve this is a more
> controlled manner. With the current t64 transitioning in unstable it is
> difficult to track down. Many updates so the situation now may differ from
> the
> situation in an hour from now.
>
> > >  This seems to be an more of an actual issue where dependencies are
> > declared but
> > >apt 

Bug#1065237: O: astroidmail -- graphical notmuch email client

[Daniel Echeverri]

Hi Jonas, Nilesh!

El dom, 10 mar 2024 a la(s) 1:13 a.m., Jonas Smedegaard (jo...@jones.dk)
escribió:

> Control: reopen -1
>
> Quoting Jonas Smedegaard (2024-03-10 07:03:27)
> > I will now close this bugreport, interpreting it as bogus (unfortunately
> > without the consent of the bugreporter).
>
> Ah, turns out that the bugreporter did respond, just only silently to
> the bugreport, without informing me.
>
> Sorry for the added confusion - I will reopen the bugreport, which is
> now tied to the correct package, src:astroid.
>
> My recommendations abut renaming the source package and generally using
> prefix "python-" for python-specific packages stand.
>
> Kind regards,
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>  * Sponsorship: https://ko-fi.com/drjones
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private


Sorry for the confusion, I am trying to adopt astroid package not
astroidmail, Can I go ahead?

Regards
-- 
Daniel Echeverri
Debian Developer
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Bug#1066038: node-glob: Please update to glob 10

[Jérémy Lal]

Le lun. 11 mars 2024 à 15:03, Jérémy Lal  a écrit :

> Package: node-glob
> Version: 8.1.0+~cs8.5.15-1
> Severity: wishlist
>
> glob 8 doesn't export ECMAScript module.
>
> glob 10 supports both, it would be very nice to have it in debian.
>

I've started working on it...

Bug#1064762: dune-grid: FTBFS: make[1]: *** [/usr/share/dune/dune-debian.mk:39: override_dh_auto_test] Error 1

[Markus Blatt]

Hi,

these tests write out vtk files and read them in using python3-vtk9.
If parsing of the file succeeds then the test was successful.

How the files are written did not change between Debian stable and Debian sid.
I have verified that the files are the same.

Attached is a small test case in python3-vtk9-test.tar.gz that mimics the
problems. The script test/vtkcheckcomb.py will read the file 
vtktest-1D-leafview-nonconforming-appendedbase64.vtp using different

relative paths with vtkXMLPolyDataReader.

On Debian stable all those cases succeed (see log file 
tests/stable/vtkcheckcomb.log.

On Debian sid all of the fail with this error of vtk xml parser:

2024-03-11 14:31:34.098 (   0.123s) [A51E0740]   
vtkXMLParser.cxx:375ERR| vtkXMLDataParser (0x1659c80): Error parsing XML in 
stream at line 27, column 9, byte index 1562: not well-formed (invalid token)
2024-03-11 14:31:34.099 (   0.123s) [A51E0740]   
vtkXMLReader.cxx:521ERR| vtkXMLPolyDataReader (0x15f4e90): Error parsing 
input file.  ReadXMLInformation aborting.
2024-03-11 14:31:34.099 (   0.123s) [A51E0740]   
vtkExecutive.cxx:752ERR| vtkCompositeDataPipeline (0x1631800): Algorithm 
vtkXMLPolyDataReader(0x15f4e90) returned failure for request: vtkInformation 
(0x166e920)
  Debug: Off
  Modified Time: 775
  Reference Count: 1
  Registered Events: (none)
  Request: REQUEST_INFORMATION
  ALGORITHM_AFTER_FORWARD: 1
  FORWARD_DIRECTION: 0

I have no clue why this is the case. To me it is more likely that the problem
is due a change in vtk9. Hence I am reassinging to vtk9 in the hope
that the maintainers there have more clues than me.

Best,

Markus




python3-vtk9-test.tar.gz
Description: application/gzip

Bug#1066044: cups: dangling /usr/share/doc/cups*/README.Debian.gz symlinks

[Sven Joachim]

Source: cups
Version: 2.4.7-1.2
Tags: patch
X-Debbugs-Cc: Sven Joachim , Michael Hudson-Doyle 


Renaming libcups2 to libcups2t64 has caused several README.Debian.gz
symlinks to become broken:

,
| $ symlinks /usr/share/doc/cups*
| dangling: /usr/share/doc/cups/README.Debian.gz -> ../libcups2/README.Debian.gz
| dangling: /usr/share/doc/cups-core-drivers/README.Debian.gz -> 
../libcups2/README.Debian.gz
| dangling: /usr/share/doc/cups-client/README.Debian.gz -> 
../libcups2/README.Debian.gz
| dangling: /usr/share/doc/cups-daemon/README.Debian.gz -> 
../libcups2/README.Debian.gz
`

They need to be updated and point at ../libcups2t64/README.Debian.gz
instead.  The following command does the trick:

,
| $ sed -i 's|^/usr/share/doc/libcups2|/usr/share/doc/libcups2t64|' 
debian/*.links
`


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

Bug#1066034: tech-ctte: proposed constitution fix and social contract chg to make documentation accessible to all people

[Gunnar Wolf]

[ I am not part of the Technical Committee anymore, am answering just
  as a DD ]

debbug.tech-c...@sideload.33mail.com dijo [Mon, Mar 11, 2024 at 02:37:45PM 
+0100]:
> # The DSC needs to become meaningful
> 
> Chuck Zmudzinski filed a bug report saying that the Debian Social
> Contract (DSC) is “meaningless”:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028557
> 
> He is correct in the sense that there is no enforcement mechanism. At
> the same time, the Debian Constitution (DC) also neglects to
> acknowledge jurisdiction over DSC enforcement. This is a bug. I think
> it’s assumed that the technical committee is tasked with DSC
> enforcement. But this should be explicit and without guesswork.
> 
> Is the DSC a guaranteed protection whereby non-compliances have a
> complaint mechanism and corrective procedure?  Or is the DSC actually
> intended to be comparable to a meaningless pushover license?

No, the TC does not go around with a stick chasing violators of the
Social Contract. The SC is upheld by each individual Debian
contributor. Particularly, the Debian Developers have signed a
statement to follow this document when volunteering work for the
project. It is up to us all, as a group, to uphold it.

> (...)
> Problems in the DSC and calls for improvement thereof should itself be
> a transparent process. It was unclear to me where to submit this bug
> herein: tech-ctte, qa.debian.org, or general?

If you need to discuss this kind of documents, the right venue would
be the debian-proj...@lists.debian.org list. However, please modulate
a bit your tone, as this message feels to fall a bit towards
aggressive writing; you will find better echo if you approach trying
to understand instead of demanding action.

> The DSC shows “Version 1.2 ratified on October 1st, 2022.” But where
> and how?  The public should have transparent access to the
> discussions, decisions, and changes.

Debian is not a government, but a volunteer project. "The public" has
no rights: We have a committment to which we all (Developers) adhere
to. "We will not hide problems", of course, but if you want something
to change, please try pointing at specific issues that were not
handled correctly --- and for which the incorrect handling was done
purposefully so (i.e. hiding problems); we have more than once found
that we are stuck in a loophole we are unable to properly fix, and
cannot enforce our golden standard (i.e. the declassification of the
debian-private mailing list, that was supposed to happen for ~10
years, until we decided via an open discussion and vote that it just
was not be possible to do correctly.

> # DSC change proposal: make documentation accessible to ALL people
> 
> There is a growing problem of documentation being locked into walled
> gardens which discriminate against several demographics of people,
> such as blind people being forced to solve a CAPTCHA that requires
> vision. The access-restricted documentation problem is particularly
> rampant on the Linux Mint and (ironically) Ubuntu projects. Debian
> does not proactively impose any walled gardens on people at the moment
> but whenever a package makes reference to external documentation
> served from an access-restricted location, Debian passively allows
> this. Debian can (and should) do better than this. The problem and
> proposal is described in detail here:
> 
>   * https://linux.community/post/649372
>   * 
> https://kbin.social/m/debian/t/889598/Debian-Social-Contract-Should-all-Debian-users-inclusively-have-open
> 
> Those two links ↑ give two different views of the same article. I
> reference both because of a minor formatting bug in kbin.

The point you raise is interesting and worth discussing, although I
believe it would place too much of a burden on maintainers. But I feel
it is orthogonal to the main issue discussed.

Besides that, I completely agree with Christoph, in order for a
discussion to be taken seriously, I strongly recommend you to disclose
your name and a real address, and not do it from an unknown,
mission-specific sender.

Bug#1066043: RFS: lem/2022-12-10+dfsg-1 [ITP] -- Tool merging math and logic for executable definitions (tool)

[Bo YU]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Dear mentors,

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

 * Package name : lem
   Version  : 2022-12-10+dfsg-1
   Upstream contact : Lem Devs 
 * URL  : https://github.com/rems-project/lem
 * License  : GPL-2, BSD-3-clause
 * Vcs  : https://salsa.debian.org/ocaml-team/lem
   Section  : ocaml

The source builds the following binary packages:

  lem - Tool merging math and logic for executable definitions (tool)
  liblem-ocaml-dev - Tool merging math and logic for executable definitions 
(development)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/lem/lem_2022-12-10+dfsg-1.dsc

Changes for the initial release:

 lem (2022-12-10+dfsg-1) UNRELEASED; urgency=low
 .
   * Initial release. (Closes: #1065658)



-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1065476: RFS: omd/1.3.2-1 [ITP] -- Markdown frontend in pure OCaml

[Bo YU]

Hi,
On Tue, Mar 05, 2024 at 04:31:35PM +0800, Bo YU wrote:

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Dear mentors,

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

* Package name : omd
  Version  : 1.3.2-1
  Upstream contact : [fill in name and email of upstream]
* URL  : https://github.com/ocaml/omd
* License  : ISC
* Vcs  : https://salsa.debian.org/vimerbf-guest/omd


Moved to:

https://salsa.debian.org/ocaml-team/omd

--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1066042: python-quantities: please make the build reproducible

[Chris Lamb]

Source: python-quantities
Version: 0.15.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed that
python-quantities could not be built reproducibly.

This is because the build process writes a timestamp to a generated
file. A patch is attached that sources this timestamp from SOURCE_DATE_EPOCH
instead of the system clock.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2024-03-11 15:07:58.203181306 
+
@@ -0,0 +1,31 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2024-03-11
+
+--- python-quantities-0.15.0.orig/setup.py
 python-quantities-0.15.0/setup.py
+@@ -1,8 +1,14 @@
++import os
++import time
+ from setuptools import Command, setup
+ from setuptools.command.build_py import build_py as _build
+ from setuptools.command.sdist import sdist as _sdist
+-from datetime import datetime
++from datetime import datetime, timezone
+ 
++build_date = datetime.fromtimestamp(
++int(os.environ.get('SOURCE_DATE_EPOCH', time.time())),
++tz=timezone.utc,
++)
+ 
+ class data(Command):
+ 
+@@ -24,7 +30,7 @@ class data(Command):
+ with open('quantities/constants/_codata.py', 'w') as f:
+ f.write('# THIS FILE IS AUTOMATICALLY GENERATED\n')
+ f.write('# ANY CHANGES MADE HERE WILL BE LOST\n')
+-f.write(f'# LAST GENERATED: {datetime.now()}\n\n')
++f.write(f'# LAST GENERATED: {build_date}\n\n')
+ f.write('physical_constants = {}\n\n')
+ for line in data:
+ name = line[:55].rstrip().replace('mag.','magnetic')
--- a/debian/patches/series 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/series 2024-03-11 15:05:38.702459132 +
@@ -0,0 +1 @@
+reproducible-build.patch

Bug#1065420: RFS: ocaml-linenoise/1.5-1 [ITP] -- Lightweight readline alternative with OCaml

[Bo YU]

Hi,

On Mon, Mar 04, 2024 at 04:40:29PM +0800, Bo YU wrote:

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "ocaml-linenoise":

* Package name : ocaml-linenoise
  Version  : 1.5-1
  Upstream contact : Edgar Aroutiounian 
* URL  : https://github.com/ocaml-community/ocaml-linenoise
* License  : BSD-2-Clause
* Vcs  : https://salsa.debian.org/vimerbf-guest/ocaml-linenoise


I have moved the package from personal salsa namespace to Debian OCaml team:

* Vcs  : https://salsa.debian.org/ocaml-team/ocaml-linenoise
   Section  : ocaml

Please let me know any issues,


The source builds the following binary packages:

 liblinenoise-ocaml - Lightweight readline alternative with OCaml (runtime)
 liblinenoise-ocaml-dev - Lightweight readline alternative with OCaml 
(development)

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

 https://mentors.debian.net/package/ocaml-linenoise/

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

 dget -x 
https://mentors.debian.net/debian/pool/main/o/ocaml-linenoise/ocaml-linenoise_1.5-1.dsc

Changes for the initial release:

ocaml-linenoise (1.5-1) UNRELEASED; urgency=low
.
  * Initial release. (Closes: #1064586)

--
Regards,
--
 Bo YU





--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1066041: icingaweb2-module-statusmap: [INTL:de] updated German po file translation

[hermann-Josef Beckers]

Package: icingaweb2-module-statusmap
Version: 20160720-5
Severity: wishlist
Tags: patch l10n

Please find the updated German po file translation for
icingaweb2-module-statusmap
attached.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Yours
Hermann-Josef Beckers




icingaweb2-module-statusmap_20160720-5_de.po.bz2
Description: application/bzip

Bug#1052535: Bug fix available for #1052535

[Michael Pietsch]

Hello,

there seems to be a patch available to fix this bug:

https://github.com/canonical/cloud-init/commit/f75be2ebe15b0dc78092fe47b1ef8d506607e9da

The earliest official release of cloud-init that includes this fix is 
cloud-init version 23.1


To test this you can use this comand to simulate the config generation:
cloud-init devel net-convert -D debian -p /path/to/network-config.yaml 
-k yaml -d /some/outputdir/ -O networkd


With the config from #10 (after adding a missing "'" to the ipv6 gateway 
address) this would result in this working systemd .network file:

[Address]
Address=192.0.2.60/24

[Address]
Address=2001:db8:aaa:bbb::ccc/64

[Match]
MACAddress=ff:ff:ff:ff:ff:ff
Name=eth0

[Network]
DHCP=no
DNS=127.0.0.1

[Route]
Gateway=192.0.2.62

[Route]
Gateway=2001:db8:aaa:bbb::ddd

Would it be possible to backport this to stable?


smime.p7s
Description: Kryptografische S/MIME-Signatur

Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable

[Chris Hofstaedtler]

On Sat, Mar 02, 2024 at 03:16:22PM +0100, Chris Hofstaedtler wrote:
> Given the C codebase and lack of any patches so far I do not see that
> deborphan will ever get these features, and we have other tools
> available that work, do not mess with dpkg internals and are actually
> maintained.

As people have asked so nicely, and not at all demanding, entitled
or otherwise bossy in this bug report, I've checked around a bit how
APT provides deborphan's functionality today.

As you all know, apt keeps track of when a package was installed
manually or automatically. This is mostly equivalent to manually
maintaining a deborphan keep file, but automated. apt-mark can be
used to manipulate the manually-installed state.

On top of that, apt-patterns(7) documents how to select packages,
including on sections, installed status, manually-installed status.
It can also used to select based on package names and regexes.

Thus, a good approximation of the default deborphan functionality
(no additional options passed) is:

$ apt-mark auto '~i !~M (~slibs|~soldlibs|~slibdevel|~sintrospection|~sdebug)'
possibly followed by
$ apt autoremove

If you're using --guess- or --guess-section with
deborphan, you can copy the regex lists from deborphans source. A
lot of them are however outdated and wrong, so you were already in
"living dangerously" territory there.

And that's it. deborphan does not do any magic and you can do all of
it with apt.

Chris

Bug#1066040: gFTP doesn't set columns width automatically, wasting space

[José Luis González]

Package: gftp-gtk
Version: 2.9.1~beta-1+b1

gFTP sets its connection columns to widths that don't adjust to the column 
contents and
have arbitrary unnecessary space, forcing the user to set them manually.

Usability bug, most likely in upstream.

Best regards

Bug#1066039: virt-firmware: autopkgtest are failing on debci

[Luca Boccassi]

Source: virt-firmware
Version: 24.1.1-1
Severity: grave

Dear Maintainer,

The autodep8 autopkgtest suite is failing and has never worked, which
is stopping virt-firmware from migrating to testing (hence severity).

The fix is trivial and attached, the test simply needs a hint on which
modules to load.

I will NMU to DELAYED/5 next Monday unless you get to it first.

I would highly recommend to add a debian/salsa-ci.yml so that these
issues can be caught automatically and easily before uploading.

Thanks!

-- 
Kind regards,
Luca Boccassi

diff -Nru virt-firmware-24.1.1/debian/changelog virt-firmware-
24.1.1/debian/changelog
--- virt-firmware-24.1.1/debian/changelog   2024-02-15
15:16:12.0 +
+++ virt-firmware-24.1.1/debian/changelog   2024-03-11
14:05:43.0 +
@@ -1,3 +1,10 @@
+virt-firmware (24.1.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix autodep8 autopkgtest (Closes: #)
+
+ -- Luca Boccassi   Mon, 11 Mar 2024 14:05:43 +
+
 virt-firmware (24.1.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru virt-firmware-24.1.1/debian/tests/pkg-python/import-name
virt-firmware-24.1.1/debian/tests/pkg-python/import-name
--- virt-firmware-24.1.1/debian/tests/pkg-python/import-name1970-
01-01 00:00:00.0 +
+++ virt-firmware-24.1.1/debian/tests/pkg-python/import-name2024-
03-11 14:04:03.0 +
@@ -0,0 +1,2 @@
+virt.firmware
+virt.peutils


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

Bug#1065831: apt tries to uninstall kde & plasma (full-upgrade)

[Wesley Schwengle]

Hello Miguel,

On Mon, Mar 11, 2024 at 09:50:12AM +0100, Miguel Angel Rojas wrote:

> >This problem isn't because of apt, the problem is that gdb-minimal/gdb
> >  dependencies cannot be satified. A full-upgrade is the equivalent of a
> >  dist-upgrade which will remove packages to resolve the dependencies. The
> > problem you are facing is the t64 transition[1][2] where not all packages
> are
> >  transitioned.
> 
> I haven't detected any "gdb | gdb-minimal dependencies that can't be
> satisfied at this point. Everything seems to be OK with those packages.

No, there is (or was) something going on with the dependencies of gdm-minimal
for sure. I think it is related to libdebuginfod1, which has a t64 variant.
This one has a dependency to libelf1 and libdw1. Now the libdebuginfod1t64
depends on libelf1t64 and libdw1t64. These two replace libelf1 and libdw1, the
former having a relative high count of reverse dependencies.

> >  My advice to you is: don't expect full-upgrade to work until the
> transitioning
> >   is done.
> 
> You nail it here! I have managed to upgrade package by package but it is a
> tedious process until the whole transition is completed. 

Some of them yes, but often after doing one, you can use `apt upgrade' to
see if it resolved other problems (which in my case it does from time to time).

> But "apt upgrade"
> should not remove any packages according to its documentation (man apt)

That is correct, but you were executing full-upgrade:

> > On Sun, Mar 10, 2024 at 02:13:34PM +0100, Miguel Angel wrote:
> >
> > > # apt full-upgrade
> > > Reading package lists... Done
> > > Building dependency tree... Done
> > > Reading state information... Done
> > > Calculating upgrade... Error!
> > > Some packages could not be installed. This may mean that you have
> > > requested an impossible situation or if you are using the unstable
> > > distribution that some required packages have not yet been created
> > > or been moved out of Incoming.
> > > The following information may help to resolve the situation:

> Why is this t64 upgrade working then as it is removing deprecated packages
> for *t64 packages?

I do not know, at times I'm also wondering why it doesn't do it, but I didn't
take time to look at the code to understand what the resolver is doing. Also,
it was sort of expected. I think we can probably solve this is a more
controlled manner. With the current t64 transitioning in unstable it is
difficult to track down. Many updates so the situation now may differ from the
situation in an hour from now.

> >  This seems to be an more of an actual issue where dependencies are
> declared but
> >apt doing something weird. But that is an issue on bookworm where we
> aren't
> >getting poluted results because of a transitioning.
> 
> I'm glad you were able to replicate in bookworm (stable) it but I don't
> think (at least in this case) it is related to the t64 transition. Same
> errors on both distributions and I checked that gdb dependencies were
> satisfied in unstable (I don't have a system running stable).

I disagree (or agree) to some extent. The gdb-minimal has been held back on my
system for a long time. I removed it after I saw it was a remnant of a KDE
experiment I did. The fact that I can install it now is a change from a couple
of days ago. The bug may be the same, but with how unstable it is now with
this big transition, it's wise to leave it where we are now and break it down
into a more controlled reproduction path, where we don't have so many moving
pieces.

> Appreciate your support.

Yw and good luck!

Cheers,
Wesley

Bug#1029125: marked as done (Please update to a 2.x version)

[Alexandre Detiste]

Hi,

Please remove the old dependency on python3-six too.

Greetings


[11/03/2024 15:00.48]  ~/Desktop/python-google-auth-debian-caracal
[detistea.38099-L-O-BUR] ➤ grep six -r .
./.kokoro/requirements.txt:six==1.16.0 \
./CHANGELOG.md:- Use ``six.raise_from`` wherever possible.
([#212](https://github.com/googleapis/google-auth-library-python/pull/#212))
./debian/control: python3-six,
./debian/control: python3-six,
./google/auth/aws.py:import posixpath
./google/auth/aws.py:urljoin(url, posixpath.normpath(uri.path))
./system_tests/noxfile.py:session.install("six")
./tests/compute_engine/test__metadata.py:@mock.patch("os.name", new="posix")


---> system_tests/noxfile.py looks like it wants to download a lot of
random things
which is forbidden on buildd/Salsa anyway


[detistea.38099-L-O-BUR] ➤ uname -a
CYGWIN_NT-10.0-WOW 38099-L-O-BUR 2.10.0(0.325/5/3)

Can't test further

Le lun. 11 mars 2024 à 14:42, Debian Bug Tracking System
 a écrit :
>
>
> -- Forwarded message --
> From: Sjoerd Simons 
> To: Debian Bug Tracking System 
> Date: Wed, 18 Jan 2023 08:42:42 +0100
> Subject: Please update to a 2.x version
> Source: python-google-auth
> Version: 1.5.1-3
>
> Hey,
>
> Version 2.0 was released well over a year ago now :). It would be great to
> update to a reent 2.x version

> Format: 1.8
> Date: Mon, 11 Mar 2024 14:01:16 +0100
> Source: python-google-auth
> Architecture: source
> Version: 2.28.2-1
> Maintainer: Debian OpenStack 
> Changed-By: Thomas Goirand 
>  .
>* New upstream release (Closes: #1029125).
>* Fixed (build-)depends for this release.
>* Removed all old patches now useless.

Bug#1066034: tech-ctte: proposed constitution fix and social contract chg to make documentation accessible to all people

[Christoph Berg]

Re: debbug.tech-c...@sideload.33mail.com
> # The DSC needs to become meaningful
> 
> Chuck Zmudzinski filed a bug report saying that the Debian Social
> Contract (DSC) is “meaningless”:

Hi,

I don't think the tech-ctte is the right body to address this.

Also, please file request using a name, we'd want to know who we
are talking to.

Christoph

Bug#1066038: node-glob: Please update to glob 10

[Jérémy Lal]

Package: node-glob
Version: 8.1.0+~cs8.5.15-1
Severity: wishlist

glob 8 doesn't export ECMAScript module.

glob 10 supports both, it would be very nice to have it in debian.


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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 node-glob depends on:
ii  node-fs.realpath  1.0.0-3
ii  node-inflight 1.0.6-2
ii  node-inherits 2.0.4-6
ii  node-minimatch9.0.3-4
ii  node-once 1.4.1-1

node-glob recommends no packages.

node-glob suggests no packages.

-- no debconf information