Bug#1068401: Pending uplad (Was: Bug#1068401: ltrsift dependencies unsatisfiable on 32-bit non-i386 architectures.)

[Andreas Tille]

Hi Sascha,

Am Thu, Apr 04, 2024 at 10:33:16PM +0200 schrieb Sascha Steinbiss:
> Interesting to see that there is no ltrsift-examples package indeed. But
> I must have had my reasons back then...
> 
> Anyway, to be honest I don't see much long-term future for LTRsift. I am
> actually surprised to see it still in Debian and not dropped out of
> testing as it depends on GTK2, which I assumed was gone from Debian
> already [0, 1].

I guess GTK2 will not be supported after the next release any more (at
best).  As long as no RC bugs are filed against packages depending from
it, it seems fine to keep these in a clean shape.
 
> I'd be happy with introducing an examples package but I don't think
> there is going to be a usable autopkgtest to gain, sorry.

Thanks for the clarification.  I'll leave this absolutely to you.
Given your explanation I do not think it is worth a detour via new
queue.  Thus I reverted my change to introduce the examples package.
I'll leave you the final decision and upload (where you can drop
the "Team upload" in changelog to silence lintian).
 
> I have pushed some changes and can upload soon.

Thanks a lot
   Andreas.
 
> [0] Apparently not, but it's dead upstream:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947713
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967603

-- 
https://fam-tille.de

Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

[Markus Wichmann]

Am Fri, Apr 05, 2024 at 05:04:37AM + schrieb Thorsten Glaser:
> Should be correct:
>
>  /usr/libexec/gcc/s390x-linux-gnu/13/collect2 -fno-lto -dynamic-linker 
> /lib/ld-musl-s390x.so.1 -nostdlib -static -static -pie --no-dynamic-linker -o 
> mksh /usr/lib/s390x-linux-musl/rcrt1.o /usr/lib/s390x-linux-musl/crti.o 
> /usr/lib/gcc/s390x-linux-gnu/13/crtbeginS.o -L/usr/lib/s390x-linux-musl -L 
> /usr/lib/gcc/s390x-linux-gnu/13/. -z relro -z now --as-needed -z text 
> --eh-frame-hdr lalloc.o edit.o eval.o exec.o expr.o funcs.o histrap.o jobs.o 
> lex.o main.o misc.o shf.o syn.o tree.o var.o ulimit.o --start-group 
> /usr/lib/gcc/s390x-linux-gnu/13/libgcc.a 
> /usr/lib/gcc/s390x-linux-gnu/13/libgcc_eh.a -lc --end-group 
> /usr/lib/gcc/s390x-linux-gnu/13/crtendS.o /usr/lib/s390x-linux-musl/crtn.o
>
> HTH & HAND,
> //mirabilos

I may not really know what I am talking about, so take this with a grain
of salt, but isn't this missing a -Bsymbolic somewhere? Ironically, that
switch causes ld to not emit symbolic relocations. I seem to remember
reading long ago in Rich's initial -static-pie proposal that that was
one of the switches added to the linker command line.

In any case, the emission of non-relative relocations is the issue here,
and it is coming from the linker.

Ciao,
Markus

Bug#1068434: ITP: python-asv-runner -- Core Python benchmark code for ASV

[Yogeswaran Umasankar]

Package: wnpp
Severity: wishlist
Owner: Yogeswaran Umasankar 
X-Debbugs-Cc: debian-de...@lists.debian.org, kd8...@gmail.com

* Package name: python-asv-runner
  Version : 0.2.1
  Upstream Contact: Rohit Goswami , Michael Droettboom 

* URL : https://github.com/airspeed-velocity/asv_runner
* License : BSD-3-clause
  Programming Lang: Python
  Description : Core Python benchmark code for ASV

ASV Runner provides essential functionality for benchmarking
 Python packages with ease and efficiency. Planning to maintain
 it under DPT, need a sponsor.

Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

[Thorsten Glaser]

Markus Wichmann dixit:

>can check with readelf -r what the relocation types are. If they are not
>relative, they will not be processed.

Gotcha! They are all R_390_RELATIVE except for:

00045ff0  00110016 R_390_64  00042c58 u_ops + 70
00045ff8  00110016 R_390_64  00042c58 u_ops + 0
00047020  00110016 R_390_64  00042c58 u_ops + 80
00047088  00110016 R_390_64  00042c58 u_ops + 80
000470a8  00110016 R_390_64  00042c58 u_ops + b8
00047220  00110016 R_390_64  00042c58 u_ops + 80
00046900  00260016 R_390_64  00015af8 c_command + 0
00046940  00070016 R_390_64  00017238 c_exec + 0
00046ab0  00200016 R_390_64  00016a80 c_trap + 0
00047090  00250016 R_390_64  000430ac initvsn + 0
00047278  00550016 R_390_64  00047438 null_string + 2

That’s our missing strings.

>Is it possible you are linking in the wrong start file? gcc -v should
>output the command line it feeds to the linker.

Should be correct:

 /usr/libexec/gcc/s390x-linux-gnu/13/collect2 -fno-lto -dynamic-linker 
/lib/ld-musl-s390x.so.1 -nostdlib -static -static -pie --no-dynamic-linker -o 
mksh /usr/lib/s390x-linux-musl/rcrt1.o /usr/lib/s390x-linux-musl/crti.o 
/usr/lib/gcc/s390x-linux-gnu/13/crtbeginS.o -L/usr/lib/s390x-linux-musl -L 
/usr/lib/gcc/s390x-linux-gnu/13/. -z relro -z now --as-needed -z text 
--eh-frame-hdr lalloc.o edit.o eval.o exec.o expr.o funcs.o histrap.o jobs.o 
lex.o main.o misc.o shf.o syn.o tree.o var.o ulimit.o --start-group 
/usr/lib/gcc/s390x-linux-gnu/13/libgcc.a 
/usr/lib/gcc/s390x-linux-gnu/13/libgcc_eh.a -lc --end-group 
/usr/lib/gcc/s390x-linux-gnu/13/crtendS.o /usr/lib/s390x-linux-musl/crtn.o

HTH & HAND,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Bug#1037521: (no subject)

[Yogeswaran Umasankar]

eribe...@debian.org, Matthias Geiger 
Bcc: 
Subject: Re: false positive NONVERBOSE BUILD for rust code in Python modules
Reply-To: 
Hi,


I am having similar issue in another package 'python-cotengrust' [0].
The link for buildlog [1].

[0] https://salsa.debian.org/python-team/packages/python-cotengrust/
[1] 
https://salsa.debian.org/python-team/packages/python-cotengrust/-/jobs/5519541

Best,
Yogeswaran.

Bug#1054514: [PATCH v2 1/1] Revert "drm/qxl: simplify qxl_fence_wait"

[Greg KH]

On Thu, Apr 04, 2024 at 07:14:48PM +0100, Alex Constantino wrote:
> This reverts commit 5a838e5d5825c85556011478abde708251cc0776.
> 
> Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
> result in a '[TTM] Buffer eviction failed' exception whenever it reached a
> timeout.
> Due to a dependency to DMA_FENCE_WARN this also restores some code deleted
> by commit d72277b6c37d ("dma-buf: nuke DMA_FENCE_TRACE macros v2").
> 
> Fixes: 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait")
> Link: https://lore.kernel.org/regressions/ztgydqrlk6wx_...@eldamar.lan/
> Reported-by: Timo Lindfors 
> Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054514
> Signed-off-by: Alex Constantino 
> ---
>  drivers/gpu/drm/qxl/qxl_release.c | 50 +++
>  include/linux/dma-fence.h |  7 +
>  2 files changed, 52 insertions(+), 5 deletions(-)

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You have marked a patch with a "Fixes:" tag for a commit that is in an
  older released kernel, yet you do not have a cc: stable line in the
  signed-off-by area at all, which means that the patch will not be
  applied to any older kernel releases.  To properly fix this, please
  follow the documented rules in the
  Documentation/process/stable-kernel-rules.rst file for how to resolve
  this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Bug#1068433: riseup-vpn dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: riseup-vpn
Version: 0.21.11+ds1-5
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, riseup-vpn
depends on both libqt5widgets5 and libqt5widgets5t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu has already fixed this issue by removing the hardcoded
dependency on shared libraries.

http://launchpadlibrarian.net/720831431/riseup-vpn_0.21.11+ds1-5build3_0.21.11+ds1-5ubuntu1.diff.gz

Bug#1068432: reapr dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: reapr
Version: 1.0.18+dfsg-5
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, reapr
depends on both libtabixpp0 and libtabixpp0t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu has already fixed this issue by removing the hardcoded
dependency on libtabixpp0.

http://launchpadlibrarian.net/721505761/reapr_1.0.18+dfsg-5build2_1.0.18+dfsg-5ubuntu1.diff.gz

Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

[Markus Wichmann]

Hi,

in static-pie, relocations get processed in _start, before main() is
called. In musl, this is done by linking with rcrt1.o as start file
instead of crt1.o. And that file processes all relative relocations. You
can check with readelf -r what the relocation types are. If they are not
relative, they will not be processed.

What you are seeing seems indicative of missing relocation processing.
Is it possible you are linking in the wrong start file? gcc -v should
output the command line it feeds to the linker.

Ciao,
Markus

Bug#998514: related bug #1065133

[Matija Nalis]

Suggested init.d script to orphan-sysvinit-scripts package:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065133

-- 
Opinions above are GNU-copylefted.

Bug#1065133: orphan-sysvinit-scripts: Please support pdns-recursor

[Matija Nalis]

On Tue, Mar 26, 2024 at 12:39:23PM +0100, Lorenzo wrote:
> Hi Matija,
> 
> could you please test the attached refreshed script and report if it
> works as expected for your use case?

Thanks!

I can confirm that attached /etc/init.d/pdns-recursor seems to work
just fine on my SysV based Debian Bookworm with pdns-recursor 4.8.7-1

-- 
Opinions above are GNU-copylefted.

Bug#1068431: rakarrack dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: rakarrack
Version: 0.6.1-8
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, rakarrack
depends on both libasound2 and libasound2t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Bug#1067752: anacrontab(5) incorrectly says the only @period is @monthly (@yearly also supported)

[Thorsten Glaser]

Hi,

I don’t think a /etc/cron.yearly/ should be created as directory,
given that the default /etc/crontab never executes anything in it
even if anacron may do.

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Bug#1068430: libqt5-ukui-style1 dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: libqt5-ukui-style1
Version: 1.0.8-1
Tags: trixie, sid
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, libqt5-ukui-style1
depends on both libqt5widgets5 and libqt5widgets5. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu appear to have already fixed this.

http://launchpadlibrarian.net/721518881/qt5-ukui-platformtheme_1.0.8-1build9_1.0.8-1ubuntu1.diff.gz

Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment

[Daniel Kahn Gillmor]

On Wed 2024-04-03 13:03:19 +0800, Sean Whitton wrote:
> Thanks, but can you sign this off?  Ty!

Sure, attached.  Let me know if you need anything different.

  --dkg

From b522c1cc6201f75ab6103954016bbb719d4dd2fa Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Tue, 30 Jan 2024 15:40:58 -0500
Subject: [PATCH] email-print-mime-structure: clean up typechecking
 (argcomplete types are known)

(and, update copyright years)

Signed-off-by: Daniel Kahn Gillmor 
---
 email-print-mime-structure | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/email-print-mime-structure b/email-print-mime-structure
index b7646e0..7635f53 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -2,7 +2,7 @@
 # PYTHON_ARGCOMPLETE_OK
 # -*- coding: utf-8 -*-
 
-# Copyright (C) 2019 Daniel Kahn Gillmor
+# Copyright (C) 2019-2024 Daniel Kahn Gillmor
 #
 # This program is free software: you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -39,6 +39,7 @@ import subprocess
 
 from argparse import ArgumentParser, Namespace
 from typing import Optional, Union, List, Tuple, Any
+from types import ModuleType
 from email.charset import Charset
 from email.message import Message
 
@@ -47,8 +48,9 @@ try:
 except ImportError:
 pgpy = None
 
+argcomplete:Optional[ModuleType]
 try:
-import argcomplete #type: ignore
+import argcomplete
 except ImportError:
 argcomplete = None
 
-- 
2.43.0



signature.asc
Description: PGP signature

Bug#881720: SSH public key authentication failed: Unable to extract public key from private key file: Method unimplemented in libgcrypt backend on curl 7.74.0

[Ben]

This problem continues to occur with curl 7.74.0 on Debian GNU/Linux
11 (bullseye) on WSL:

curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1w
zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0)
libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3
Release-Date: 2020-12-09, security patched: 7.74.0-1.3+deb11u11

 Debian GNU/Linux 11 (bullseye)
 Kernel: Linux 5.15.146.1-microsoft-standard-WSL2

Since I have the public key file, a workaround is to explicitly pass
the public key file. That is, this command fails:

curl -v sftp://user@host/home/user/

with this error:

 Using SSH private key file '.../.ssh/id_rsa'
* SSH public key authentication failed: Unable to extract public key
from private key file: Method unimplemented in libgcrypt backend

And this works:

curl --pubkey ~/.ssh/id_rsa.pub  sftp://user@host/home/user/

"curl 8.7.1 (x86_64-pc-cygwin)" extracts the private key from the public key.

Bug#1068429: nmu: pypy3_7.3.15+dfsg-1

[plugwash]

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

pypy3 needs rebuilding for the time64 transition (it currently depends on
libssl3).

nmu pypy3_7.3.15+dfsg-1 . ANY . unstable . -m "rebuild for time64"

-- System Information:
Debian Release: 10.13
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1053334: galera-4: FTBFS because of expired certificates

[Otto Kekäläinen]

Galera patch releases have been accepted as stable updates before. That is
also what users expect.

Thanks for reminding about this though, I yad forgotten about it. Will do
it next weekend.

Bug#1068428: pyode: python3-pyode is empty

[Benjamin Drung]

Package: pyode
Version: 1.2.0.dev15-4
Severity: grave
Tags: patch
Justification: renders package unusable
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
X-Debbugs-Cc: bdr...@debian.org

Dear Maintainer,

the python3-pyode package is empty, because it silently fails to build
with Cython 3.

In Ubuntu, the attached patch was applied to achieve the following:

  * Add support for Cython 3 to fix building the Python module.


Thanks for considering the patch.

-- 
Benjamin Drung
Debian & Ubuntu Developer
diff -Nru pyode-1.2.0.dev15/debian/patches/Add-support-for-Cython-3.patch 
pyode-1.2.0.dev15/debian/patches/Add-support-for-Cython-3.patch
--- pyode-1.2.0.dev15/debian/patches/Add-support-for-Cython-3.patch 
1970-01-01 01:00:00.0 +0100
+++ pyode-1.2.0.dev15/debian/patches/Add-support-for-Cython-3.patch 
2024-04-05 02:21:29.0 +0200
@@ -0,0 +1,35 @@
+From: Benjamin Drung 
+Date: Fri, 5 Apr 2024 02:21:21 +0200
+Subject: Add support for Cython 3
+
+See 
https://cython.readthedocs.io/en/latest/src/userguide/migrating_to_cy30.html
+
+Signed-off-by: Benjamin Drung 
+---
+ src/declarations.pyx | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/declarations.pyx b/src/declarations.pyx
+index b69a0e1..f274ad6 100755
+--- a/src/declarations.pyx
 b/src/declarations.pyx
+@@ -80,8 +80,8 @@ cdef extern from "ode/ode.h":
+ dVector3 f2
+ dVector3 t2
+ 
+-ctypedef void dNearCallback(void* data, dGeomID o1, dGeomID o2)
+-ctypedef dReal dHeightfieldGetHeight( void* p_user_data, int x, int z )
++ctypedef void dNearCallback(void* data, dGeomID o1, dGeomID o2) except *
++ctypedef dReal dHeightfieldGetHeight( void* p_user_data, int x, int z ) 
except *
+ 
+ ctypedef void dGetAABBFn (dGeomID, dReal aabb[6])
+ ctypedef int dColliderFn (dGeomID o1, dGeomID o2, int flags, dContactGeom 
*contact, int skip)
+@@ -322,7 +322,7 @@ cdef extern from "ode/ode.h":
+ void dBodySetGravityMode (dBodyID b, int mode)
+ int dBodyGetGravityMode (dBodyID b)
+ 
+-void dBodySetMovedCallback(dBodyID b, void (*callback)(dBodyID))
++void dBodySetMovedCallback(dBodyID b, void (*callback)(dBodyID) except *)
+ 
+ dGeomID dBodyGetFirstGeom (dBodyID b)
+ dGeomID dBodyGetNextGeom (dGeomID g)
diff -Nru pyode-1.2.0.dev15/debian/patches/series 
pyode-1.2.0.dev15/debian/patches/series
--- pyode-1.2.0.dev15/debian/patches/series 2021-11-10 19:39:19.0 
+0100
+++ pyode-1.2.0.dev15/debian/patches/series 2024-04-05 02:21:29.0 
+0200
@@ -1,3 +1,4 @@
 01_fix_setup.patch
 02_add_shebang.patch
 03_spellings.patch
+Add-support-for-Cython-3.patch

Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

[Thorsten Glaser]

Dixi quod…

>Now I (or someone) is going to have to reduce that to a testcase, so

No success with that, unfortunately.

>But this does seem to be a toolchain bug: adding -static-pie to the
>glibc dynamic-pie link command and…
>
>(gdb) print initcoms
>$1 = {0xda494 "typeset", 0x0, 0x0, 0x0, 0xda494 "typeset", 0x0, 0xd942c 
>"HOME", 0xda7d8 "PATH",

Wait, what?

(gdb) b main
Breakpoint 1 at 0xd820: file ../../main.c, line 785.
(gdb) print initcoms
$1 = {0xda494 "typeset", 0x0, 0x0, 0x0, 0xda494 "typeset", 0x0, 0xd942c "HOME", 
0xda7d8 "PATH",
[…]
(gdb) r
Starting program: /home/tg/mksh-59c/builddir/full/mksh

Breakpoint 1, main (argc=1, argv=0x3ffa4d8) at ../../main.c:785
785 {
(gdb) print initcoms
$2 = {0x3fff7eda494 "typeset", 0x3fff7ee4548  "-r",
  0x3fff7ee4ae0  "KSH_VERSION=@(#)MIRBSD KSH R59 2024/02/01 +Debian", 
0x0, 0x3fff7eda494 "typeset",
[…]

While in musl:

(gdb) print initcoms
$1 = {0x414a4 "typeset", 0x0, 0x0, 0x0, 0x414a4 "typeset", 0x0, 0x40478 "HOME", 
0x41d42 "PATH",
[…]
(gdb) r
Starting program: /home/tg/mksh-59c/builddir/static-musl/mksh

Breakpoint 1, main (argc=1, argv=0x3ffa498) at ../../main.c:785
785 {
(gdb) print initcoms
$2 = {0x3fff7fc14a4 "typeset", 0x0, 0x0, 0x0, 0x3fff7fc14a4 "typeset", 0x0, 
0x3fff7fc0478 "HOME",
[…]

So the existing ones did get relocated, but the nullptrs stayed thusly.

Apparently, it *is* supported on glibc on s390x, mjt (qemu maintainer)
also said so in 2023.

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#1068427: RFS: dpkg-dev-el/37.12 -- Emacs helpers specific to Debian development

[Xiyue Deng]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dpkg-dev-el":

 * Package name : dpkg-dev-el
   Version  : 37.12
   Upstream contact : Debian Emacsen Team 
 * URL  : [fill in URL of upstream's web site]
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/emacsen-team/dpkg-dev-el
   Section  : lisp

The source builds the following binary packages:

  elpa-dpkg-dev-el - Emacs helpers specific to Debian development
  dpkg-dev-el - Transition package, dpkg-dev-el to elpa-dpkg-dev-el

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

  https://mentors.debian.net/package/dpkg-dev-el/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dpkg-dev-el/dpkg-dev-el_37.12.dsc

Changes since the last upload:

 dpkg-dev-el (37.12) unstable; urgency=medium
 .
   [ Niels Thykier ]
   * Update list of known d/control fields for debian-control-mode
 .
   [ Xiyue Deng ]
   * Untabify and reindent source code in Emacs 29 for consistency
   * Fix fill-paragraph in debian-changelog-mode (Closes: #620185)
   * Improve highlighting in debian-copyright (Closes: #557594, #1067589)
 - Add highlighting for more field names
 - Properly highlight common URLs
 - Add highlighting for emails
 - Add highlighting for common licenses as defined in base-files
   * Fix comp warnings (Closes: #1026450, #1028470)
 - Drop calls to obsolete easy-menu-add
 - Guard XEmacs functions
 - Require debian-bug for function usage
 - There are still some warnings due to compatibility with XEmacs
   which are being tracked in Bug#1068370.
 - Replace obsolete `max-specpdl-size' with `max-lisp-eval-depth'
 - Drop calls to no-op function `easy-menu-add'
 - Use defvar for variables without a require
 - Replace `position' with `seq-position'
 - Replace `subseq' with `seq-subseq'
 - Fix long docstring
 - Use `goto-char' instead of `goto-line'
   * Initial support for autopkgtest control files (Closes: #1067590)
 - Add initial highlighting for field names, dependency extensions,
   and restrictions
   * Bump version to prepare for release
   * Add myself to uploaders

Regards,
-- 
Xiyue Deng

Bug#1068426: pkgconf fails to deduplicate -L in Debian bookworm

[Earl Chew]

Package: pkgconf
Version: 1.8.1-1
Severity: normal
X-Debbugs-Cc: earl_c...@yahoo.com

Dear Maintainer,

In Debian bullseye, pkgconf would deduplicate -L options:

# foo.pc
libdir=/opt/lib

Name: foo
Description: The foo library
Version: 1.0.0
Requires.private: bar
Libs: -L${libdir} -lfoo


# bar.pc
libdir=/opt/lib

Name: bar
Description: The bar library
Version: 1.0.0
Libs: -L${libdir} -lbar

$ /bullseye/usr/bin/pkg-config --libs --static foo
-L/opt/lib -lfoo -lbar


Since Debian bookworm, this is no longer the case:

$ pkg-config --libs --static foo
-L/opt/lib -lfoo -L/opt/lib -lbar


The version of pkg-config in Debian bookworm appears to be missing:

commit 78d53ea012dfbaf397bf8e6907efac5b51abac56
Author: Kai Pastor 
Date:   Fri Feb 23 15:18:08 2024 +0100

Revise serials, traversal, flattening

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

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

Versions of packages pkgconf depends on:
ii  pkgconf-bin  1.8.1-1

pkgconf recommends no packages.

pkgconf suggests no packages.

-- no debconf information

Bug#1068415: nghttp2: CVE-2024-28182: Reading unbounded number of HTTP/2 CONTINUATION frames to cause excessive CPU usage

[Tomasz Buchert]

On 04/04/24 21:36, Salvatore Bonaccorso wrote:
> Source: nghttp2
> Version: 1.60.0-1
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for nghttp2.
> 
> CVE-2024-28182[0]:
> | nghttp2 is an implementation of the Hypertext Transfer Protocol
> | version 2 in C. The nghttp2 library prior to version 1.61.0 keeps
> | reading the unbounded number of HTTP/2 CONTINUATION frames even
> | after a stream is reset to keep HPACK context in sync.  This causes
> | excessive CPU usage to decode HPACK stream. nghttp2 v1.61.0
> | mitigates this vulnerability by limiting the number of CONTINUATION
> | frames it accepts per stream. There is no workaround for this
> | vulnerability.
> 
> 
> 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-28182
> https://www.cve.org/CVERecord?id=CVE-2024-28182
> [1] https://github.com/nghttp2/nghttp2/security/advisories/GHSA-x6x3-gv8h-m57q
> 
> Please adjust the affected versions in the BTS as needed.
> 
> Regards,
> Salvatore

As the first measure I uploaded 1.61.0-1 to unstable with urgency=high.

Looking into older versions and appropriately patching them will take more time.

Tomasz

Bug#1068425: pflogsumm: Postfix logs days in month < 10 with leading zeroes, pflogsumm expects space padding

[Magnus Stenman]

Package: pflogsumm
Version: 1.1.5-8
Severity: important
Tags: patch
X-Debbugs-Cc: st...@hkust.se

Dear Maintainer,

Pflogsumm reports zero mails on day 1-9 of every month

Stock debian postfix version

Patch:
--- /usr/sbin/pflogsumm.orig2024-04-05 00:45:38.214914066 +0200
+++ /usr/sbin/pflogsumm 2024-04-05 00:45:44.710952673 +0200
@@ -1518,7 +1518,7 @@
 }
 my ($t_mday, $t_mon, $t_year) = (localtime($time))[3,4,5];

-return sprintf("%s %2d", $monthNames[$t_mon], $t_mday), 
sprintf("%04d-%02d-%02d", $t_year+1900, $t_mon+1, $t_mday);
+return sprintf("%s %02d", $monthNames[$t_mon], $t_mday), 
sprintf("%04d-%02d-%02d", $t_year+1900, $t_mon+1, $t_mday);
 }

 # if there's a real domain: uses that.  Otherwise uses the IP addr.



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

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

Versions of packages pflogsumm depends on:
ii  libdate-calc-perl  6.4-2
ii  perl   5.36.0-7+deb12u1

pflogsumm recommends no packages.

pflogsumm suggests no packages.

-- no debconf information

Bug#1068348: xz-utils: Should activate trigger to force regenerating initramfs

[Guillem Jover]

Hi!

On Thu, 2024-04-04 at 23:13:03 +0200, Sebastian Andrzej Siewior wrote:
> On 2024-04-04 00:14:27 [+0200], Guillem Jover wrote:
> > I initially was thinking that a conditionally triggered activation
> > when upgrading from the affected versions would be sufficient, but if
> > people have already upgraded, then that will still leave them with the
> > malicious stuff in their initramfs.
> 
> Do you think about a one-time trigger to ensure the 5.6 release is gone
> or to keep it?

Given that we do not have a release barrier to assume people have
upgraded to a known state, and are dealing with the rolling testing
and sid releases, I'd say probably at least until the release of
trixie to be extra safe, or if you don't want to have it included in
the stable release, then to be removed immediately before or during
the freeze?

(As in, if you include it for say 5.6.1+really5.4.5-2 and remove it
in 5.6.1+really5.4.5-3, if someone does not upgrade until -3 or later
then they will still miss it.)

> I can't tell what happend exactly but the 5.6 release is
> gone from my _current_ initramfs so something triggered it already. Only
> the older "previous" kernel has it.

If you have since installed any other package that might also trigger its
regeneration such as grub, a linux kernel, udev, etc, then that would be
expected. But if users have not, they might still have the backdoor.

I think the price for an excess initramfs regeneration is worth the
hassle of the time it takes to perform that action (better safe than
sorry etc).

Thanks,
Guillem

Bug#1068084: intel-microcode 3.20240312.1~deb12u1 flagged for acceptance

[Jonathan Wiltshire]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: intel-microcode
Version: 3.20240312.1~deb12u1

Explanation: security mitigations [CVE-2023-22655 CVE-2023-28746 CVE-2023-38575 
CVE-2023-39368 CVE-2023-43490]

Bug#1068424: populations - still depends on old libqt5gui5 after binnmu

[Peter Green]

Package: populations
Version: 1.2.33+svn0120106+dfsg-6
Severity: grave
Tags: trixie, sid
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition,
populations still depends on libqt5xml5,
rather than libqt5xml5t64. As a result it is uninstallable on
architectures that are undergoing the time64 transition
(armel, armhf and some debian-ports architectures).

Ubuntu has applied a fix for this.

https://launchpadlibrarian.net/721519148/populations_1.2.33+svn0120106+dfsg-6_1.2.33+svn0120106+dfsg-6ubuntu2.diff.gz

Bug#1068423: steam-installer: steam.desktop not removed when steam-installer is purged

[Jared Epp]

Package: steam-installer
Version: 1:1.0.0.75+ds-6
Severity: minor
X-Debbugs-Cc: jared...@pm.me

Dear Maintainer,

I just removed steam with "apt purge steam-installer". In the process it warned 
me that ~/.steam would not be removed and I should remove it manually (I did). 
But I also noticed Steam still appeared in the applications menu (I'm using KDE 
Plasma). I fixed that by deleting ~/.local/share/applications/steam.desktop 

It's extremely minor but I think it would be good to let the user know it needs
to be deleted manually along with ~/.steam , or to delete it automatically.

Thanks!

Jared

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

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

Versions of packages steam-installer depends on:
ii  debconf [debconf-2.0]  1.5.82
pn  steam-libs 
pn  steam-libs-i386
pn  zenity | yad   

steam-installer recommends no packages.

steam-installer suggests no packages.

Bug#1057850: libnss-db: Uses db5.3, no replacement in sight

[Paulo Henrique de Lima Santana]

Hi Cris,

Would be possible reintroduce libnss-db to testing?

I'm asking because I'm maintainer of the pglistener package and I know 
there aren't plans to update the sofwtare with another database solution.


And now I can't have pglistener on testing.

Best regards,

On Sat, 09 Dec 2023 16:54:26 +0100 Chris Hofstaedtler  
wrote:

Source: libnss-db
Version: 2.2.3pre1-8
Severity: serious
Tags: upstream

libnss-db is the so-called "Berkeley DB NSS". It last saw upstream
changes in 2001, and obviously depends on Berkeley DB 5.3. We want to
get rid of Berkeley DB, and now is as good a time as any other to stop
shipping libnss-db.

Users can probably use any other NSS module that can use some form of
database backend.

After a while I intend to file an RM bug, too.

Chris




--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068382: sbuild: Support tarballs not including ./ when using the unshare chroot mode

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Santiago Vila (2024-04-04 20:03:08)
> El 4/4/24 a las 19:29, Johannes Schauer Marin Rodrigues escribió:
> > Also I'm curious: what is your motivation for using unshare mode if you are
> > creating your chroots using superuser privileges?
> >
> > And are you really storing your chroots in /srv instead of letting them get
> > picked up automatically in ~/.cache/sbuild/unstable-arm64.tar?
> 
> I am testing the unshare backend at the request of Jochen.

I now also talked with Jochen on IRC. :)

> As we speak, I am building all packages in bookworm using unshare.

Thank you for doing that! I'd assume that quite a few testsuites break in that
environment.

> I already had a working setup for building packages using the other backends.
> In my setup, I run debootstrap in a master server, create the tarballs there,
> and the build nodes retrieve those tarballs using wget before they start to
> build packages.
> 
> So in my setup the logical thing to do to test the unshare backend
> was to make symlinks to the already existing tarballs at /srv, since the
> nodes are not creating any tarballs.

That makes sense, yes. I think it makes sense for sbuild to accept tarballs
without the leading ./. I think the best way to achieve this, is to filter out
the device nodes from the input tarball. The utility that I know that can do
this is mmtarfilter like this:

mmtarfilter --type-exclude CHRTYPE --type-exclude BLKTYPE

Unfortunately, that utility is written in Python and sbuild currently does not
depend on Python. I wonder if the same can be done in Perl? Maybe I should
write a very crude tarball parser that is able to do just enough parsing...

signature.asc
Description: signature

Bug#1068419: perdition: dependencies unsatisfiable after binnmu for time64 transition.

[Preuße]

Control: tags -1 + patch

On 04.04.2024 21:57, Peter Green wrote:

Hi,


After being rebuilt for the time64 transition, perdition
depends on both libvanessa-socket2 and libvanessa-socket2.
As a result it is uninstallable.

Interesting in this case, the uninstallability seems to apply to all 
architectures and not just those undergoing the time64 transition.




For any unknown reason the dep on libvanessa-socket2 is hard coded in 
the control file:


Package: perdition
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, libvanessa-socket2 (>= 
0.0.12), lsb-base (>= 3.2-14)

Conflicts: perdition-bdb

So I guess removing that libvanessa-socket2 (>= 0.0.12) and rebuilding 
the package should solve the issue.


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068199: librocfft0: callback test failures on gfx900 and gfx1030

[Cordell Bloor]

Ah. That makes sense. Thanks, Christian!

On 2024-04-04 04:30, Christian Kastner wrote:

I just rebuilt rocfft to 6.0.2 but the issue is still present. But that
was naive, there are other < 6.0 components in the stack that could
affect this.


The problem appeared in rocfft 5.5.1 when rocm-hipamd was updated from 
5.2.3 to 5.7.1. It was working fine even when every package in the stack 
below it aside from rocm-compilersupport and rocm-hipamd were on 5.7.1.


I suspect that rocm-hipamd alone determines whether rocfft requires PCIe 
atomics.

Bug#1060896: No longer just experimental

[Jeremy Stanley]

Unfortunately, this applies to unstable now too, and did apply to
trixie until it resulted in autoremoval of the package. Would it
help if I were to backport the fix from upstream? Or is the plan to
just wait? (I can always build my own local package from upstream
source, but this doesn't really help anyone else.)
-- 
Jeremy Stanley

Bug#1068348: xz-utils: Should activate trigger to force regenerating initramfs

[Thorsten Glaser]

Sebastian Andrzej Siewior dixit:

>the older "previous" kernel has it.

And that won’t be fixed even with a trigger.

Used to be -uk all would, but (#1065698) that doesn’t work any more.

Given how widespread the info already is and that it affects sid and
a subset of trixie users, maybe go with just a NEWS.Debian entry for
that?

(I’d be more interested of what other backdoors there might be like
joeyh indicated.)

bye,
//mirabilos
-- 
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc

[Thorsten Glaser]

Dixi quod…

>Hmm, actually… I could… test whether that one fixes static-pie
>on zelenka. Or at least the same approach. I’ll get back with
>report from that.

Having looked at the spec file, the only extra things the stock
specs do that the overriding specs don’t is:

*link:
[…] %{!static|static-pie:--eh-frame-hdr} […] %{static-pie:-static -pie 
--no-dynamic-linker -z text} […]

instead of:

[…] %{static-pie:-static -pie --no-dynamic-linker} […]

The -Wl,-z,text makes TEXTRELs an error. Granted.
The -Wl,--eh-frame-hdr is added for anything that’s not a normal
static executable, however adding that to a musl build doesn’t
fix the problem either.

A bit of gdb-ing shows the problem, though: the source code has…

#define Ttypeset "typeset"
#define Tdr "-r"
//… (a variant of this is used for string sharing on ancient Unix)

static const char *initcoms[] = {
Ttypeset, Tdr, initvsn, NULL,
Ttypeset, Tdx, "HOME", TPATH, TSHELL, NULL,
  […]
};

It then iterates over these commands with:

for (wp = initcoms; *wp != NULL; wp++) {
c_builtin(wp);
while (*wp != NULL)
wp++;
}

This is where the extra output happens:

(gdb) print initcoms
$3 = {0x3fff7fc14a4 "typeset", 0x0, 0x0, 0x0, 0x3fff7fc14a4 "typeset", 0x0, 
0x3fff7fc0478 "HOME", 
[…]

Notice the nullptrs there where string pointers are expected.
It shows the same output when just loading the executable, i.e. this
isn’t a runtime issue.

Linking the exact same .o files with the exact same command minus
-static-pie gives:

(gdb) print initcoms
$1 = {0x103cb34 "typeset", 0x103e368  "-r", 
  0x103e73c  "KSH_VERSION=@(#)MIRBSD KSH R59 2024/02/01 +Debian", 0x0, 
0x103cb34 "typeset", 

But this does seem to be a toolchain bug: adding -static-pie to the
glibc dynamic-pie link command and…

(gdb) print initcoms
$1 = {0xda494 "typeset", 0x0, 0x0, 0x0, 0xda494 "typeset", 0x0, 0xd942c "HOME", 
0xda7d8 "PATH",

Now I (or someone) is going to have to reduce that to a testcase, so
we can detect static-pie viability before it’s committed to being used…

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#1068399: lomiri-system-settings - uninstallable on armel, armhf and mips64el due to depends/build-depends cycles.

[Mike Gabriel]

Control: reassign -1 lomiri-system-settings-security-privacy
Control: found -1 1.0.2-2

On  Do 04 Apr 2024 17:53:07 CEST, Peter Green wrote:


Package: lomiri-system-settings
Version: 1.1.0-2
Severity: grave

lomiri-system-settings depends on  
lomiri-system-settings-security-privacy, which

is not availble on armel, armhf or mips64el.

The reason, or at least one reason, it is not available is because
lomiri-system-settings-security-privacy build-depends on  
lomiri-system-settings.


Reassinging to l-s-s-security-privacy.

Mike

--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpWL2MHPEe1q.pgp
Description: Digitale PGP-Signatur

Bug#1068422: can't import dask.dataframe - TypeError: descriptor '__call__' for 'type' objects doesn't apply to a 'property' object

[Rebecca N. Palmer]

Package: python3-dask
Version: 2023.12.1+dfsg-2
Severity: serious
Control: affects -1 src:pandas
Control: block 1068104 by -1

Importing dask.dataframe currently fails with the error

TypeError: descriptor '__call__' for 'type' objects doesn't apply to a 
'property' object


amd64 https://salsa.debian.org/science-team/pandas/-/jobs/5543041
https://ci.debian.net/packages/d/dask/unstable/arm64/44706021/
i386 https://salsa.debian.org/science-team/pandas/-/jobs/5543042

This appears to have started recently, as this log from 2024-03-31 
doesn't have it, and to occur in unstable but not testing:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/pandas.html

As the version of dask has not changed in this time, the cause is 
probably a change in some other package; I don't know which one.

Bug#1068399: lomiri-system-settings - uninstallable on armel, armhf and mips64el due to depends/build-depends cycles.

[Mike Gabriel]

On  Do 04 Apr 2024 17:53:07 CEST, Peter Green wrote:


Package: lomiri-system-settings
Version: 1.1.0-2
Severity: grave

lomiri-system-settings depends on  
lomiri-system-settings-security-privacy, which

is not availble on armel, armhf or mips64el.

The reason, or at least one reason, it is not available is because
lomiri-system-settings-security-privacy build-depends on  
lomiri-system-settings.


Yeah, the lomiri-system-settings inter-dependencies are a mess as I  
have learned recently, as well.


Will decouple this via a work-around for now, but this needs deeper  
thinking upstream.


Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpcc9m6zKTwT.pgp
Description: Digitale PGP-Signatur

Bug#1068348: xz-utils: Should activate trigger to force regenerating initramfs

[Sebastian Andrzej Siewior]

On 2024-04-04 00:14:27 [+0200], Guillem Jover wrote:
> Hi!
Hi,

> I initially was thinking that a conditionally triggered activation
> when upgrading from the affected versions would be sufficient, but if
> people have already upgraded, then that will still leave them with the
> malicious stuff in their initramfs.

Do you think about a one-time trigger to ensure the 5.6 release is gone
or to keep it? I can't tell what happend exactly but the 5.6 release is
gone from my _current_ initramfs so something triggered it already. Only
the older "previous" kernel has it.

> Thanks,
> Guillem

Sebastian

Bug#1067639: sasl2-bin: terminates with smashed stack and kills qemu-user?!

[Thorsten Glaser]

Sometimes, it does not crash with a smashed stack but instead:

Setting up sasl2-bin (2.1.28+dfsg1-6+b1) ...
BDB0002 __fop_file_setup:  Retry limit (100) exceeded
saslpasswd2: generic failure
dpkg: error processing package sasl2-bin (--configure):
 installed sasl2-bin package post-installation script subprocess returned error 
exit status 1

(I tried rebuilding it, but that didn’t fix it either.)

Bug#1068421: kanshi: kanshi output configurations do not persist across swaymsg reload

[Daniel Kahn Gillmor]

Package: kanshi
Version: 1.5.1-2
Severity: normal
X-Debbugs-Cc: Daniel Kahn Gillmor 

I'm using sway 1.9-1 with kanshi.  When i plug in an external monitor,
kanshi matches it appropriately against my configuration, and it
configures the monitor appropriately.

However, when i do `swaymsg reload`, the outputs are reconfigured to
some sort of default configuration which doesn't match kanshi's
configuration.

if i send a SIGHUP to kanshi, or terminate it and restart, it all goes
back to what i'd expected.

I can modify my keybindings for `reload` so that they also send the
SIGHUP to kanshi, but it seems like it ought to be able to subscribe to
some notifications so that it can re-apply its settings during sway's
configuration reload.

  --dkg

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 kanshi depends on:
ii  libc6   2.37-15
ii  libwayland-client0  1.22.0-2.1+b1

kanshi recommends no packages.

kanshi suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#922161: Grub null src bitmap error while trying to drop background image

[Jmkr]

I forgot to mention the exact GRUB versions:

- My Debian 10.13 Netinst based installer had GRUB: 2.06-3~deb10u1
- My Debian 10 based installed system had GRUB: 2.06-3~deb10u4
- My Debian 11.9 Netinst based installer had GRUB: 2.06-3~deb11u6
- My Debian 11 based installed system had GRUB: 2.06-3~deb11u6

Now, I also tested with a Debian 12.5 Netinst based installer that had GRUB
2.06-13+deb12u1. My script printed some errors and warnings while generating
that installer, but the installer worked good enough to confirm that this 
bug also affects the Debian 12 installer. I did not test the Debian 12
installed system (but I guess it could be unaffected like my Debian 10 and
11 installed systems).

Bug#1068401: Pending uplad (Was: Bug#1068401: ltrsift dependencies unsatisfiable on 32-bit non-i386 architectures.)

[Sascha Steinbiss]

Hi Andreas,

after routine-update dh_missing failed due to compat level 13 which 
defaults to fail if some files are not installed.


Yep, encountered that in other places as well when updating a few (old!)
things.

This made me aware that upstream in principle installs a test suite 
we could use for an autopkgtest.  I also realised that you once

added debian/ltrsift-examples.examples - so you probably had such a
package in mind.


Well, upstream is me ;) At least the original upstream, I don't think
anyone at my former organization has adopted it in the meantime and I do
not have the time to still care for it.
But... since LTRsift is a purely graphical tool, there is no automated
test suite I know of. The files in samqqple_data are basically just
quickstart examples for the accompanying paper to provide a realistic
data set to preprocess, manually load and do first clicky analysis steps
with, I think.

Since I have no idea what reasons you had not to use this file I'll 
leave the final decision to you.


Interesting to see that there is no ltrsift-examples package indeed. But
I must have had my reasons back then...

Anyway, to be honest I don't see much long-term future for LTRsift. I am
actually surprised to see it still in Debian and not dropped out of
testing as it depends on GTK2, which I assumed was gone from Debian
already [0, 1].

I'd be happy with introducing an examples package but I don't think
there is going to be a usable autopkgtest to gain, sorry.


(Please note:  Somehow a copy of ltrsift_code ends up in the
examples dir - I did not yet investigated why this is happening.
Before I have no clear picture about your intentions I'll left this
for later investigation.)


That is a result of lines 62-65 in the Makefile, which make sure that
there is a copy of the executable in that directory, for the paper
reviewer's convenience I think (same as why we have the the static build).
I think this can be safely patched out as the prepare_encseqs script in
the sample_data directory also tries to run ltrsift_encode from the
$PATH. ltrsift_encode, BTW, is just a script that prepares the input
data and is actually just a wrapper around another tool from
GenomeTools, which we wanted to have in here for convenience.

I have pushed some changes and can upload soon.

Cheers
Sascha

[0] Apparently not, but it's dead upstream: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947713

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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie

[Rich Felker]

On Thu, Apr 04, 2024 at 07:50:40PM +, Thorsten Glaser wrote:
> Szabolcs Nagy dixit:
> 
> >the next culprit is gcc (each target can have their own
> 
> gcc-13_13.2.0-23
> 
> >static pie specs) or the way you invoked gcc (not visible
> 
> As I wrote earlier, though with more flags. Dropping all the -D…
> and -W… and -I… and other irrelevant ones:
> 
> musl-gcc -Os -g -fPIE -fno-lto -fno-asynchronous-unwind-tables
> -fno-strict-aliasing -fstack-protector-strong -fwrapv -c …
> musl-gcc -Os -g -fPIE -fno-lto -fno-asynchronous-unwind-tables
> -fno-strict-aliasing -fstack-protector-strong -fwrapv
> -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -static -static-pie
> -fno-lto -o mksh  *.o
> 
> Same for both. You can see the full log by activating the
> [64]Installed and [71]Installed links respectively on
> https://buildd.debian.org/status/package.php?p=mksh and
> skipping to 'compilation of mksh in static-musl' to get to
> the beginning of the configure phase for that.
> 
> >are you sure static pie works on these targets?
> 
> No ;-) That’s why I reported this issue. I had just
> enabled it for the musl builds, as the security people
> like that more than normal static.

I seem to recall the musl-gcc wrapper does not handle static-pie
right. A real cross toolchain should. If there's an easy fix for the
wrapper I'd be happy to merge it.

Rich

Bug#1068370: elpa-dpkg-dev-el: Comp warnings due to XEmacs compatible code

[Xiyue Deng]

David Bremner  writes:

> Xiyue Deng  writes:
>
>>
>> Will re-evaluate if XEmacs compatibility would be dropped.
>>
>> [1] 
>> https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/132669ed6d6ee19a440234b943625da9cd6e2d9b
>>
>
> Does the package currently work (somehow?) with XEmacs? At least dh-elpa
> byte compilation does not support XEmacs, but I have not tested the
> binary package with XEmacs.

I don't know, but I guess we will find out once "someone" packages
XEmacs again ;) My hope was those legacy compatibility code will help a
little for the transition, which may turn out to be useless, but will
see.

>
> d

-- 
Xiyue Deng

Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie

[Thorsten Glaser]

Rich Felker dixit:

>I seem to recall the musl-gcc wrapper does not handle static-pie
>right.

Hmm. Inhowfar? And it does seem to work fine on the other
architectures.

>A real cross toolchain should.

I fear that that’s out of question for Debian.

I’ve got a github action test setup for mksh though, which also
uses jirutka/setup-alpine to set up chroots of Alpine Linux for
various architectures and uses them to build natively under
qemu-user. I could use that to check static-pie? IIUC, these use
“a real cross toolchain”, if natively; qemu-user adds an extra
potential failure dimension though…

>If there's an easy fix for the wrapper I'd be happy to merge it.

Together with the MIPS fix?

Hmm, actually… I could… test whether that one fixes static-pie
on zelenka. Or at least the same approach. I’ll get back with
report from that.

bye,
//mirabilos
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Bill Allombert]

On Thu, Apr 04, 2024 at 01:22:19PM -0700, Russ Allbery wrote:
> I'm not sure what I think about that.  We have a general escape hatch
> already for non-free packages in Policy 2.2.3 that says they may not fully
> comply with Policy, which may be sufficient. 

But precisely, we _do_ want non-free packages that are built on the autobuilders
to comply with this requirement. So we do not want 2.2.3 to apply in that
specific case. It seems cleaner to say that the requirement only apply if
Autobuild: yes is declared.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#834736: [buildd-tools-devel] Bug#834736: sbuild: Use basic format for ISO 8601 timestamps (for build logs filenames)

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Santiago Vila (2024-04-04 20:35:47)
> El 4/4/24 a las 19:44, Johannes Schauer Marin Rodrigues escribió:
> > instead of doing that, you could've worked around this by just placing the
> > build log into a dedicated temporary directory and then copying it to where 
> > you
> > want it after the build is finished.
> 
> That would be an option, yes, but maybe it's too convoluted for my taste.

it's a trade-of between doing that and patching sbuild over and over and over
again. Or working on a patch for this bug I guess. :D

> > I think I'd find an option useful which allows to pass a completely custom
> > build log filename. There is already the LOG_DIR configuration variable.
> > Maybe add the LOG_FILENAME configuration variable containing the filename
> > that the log will have when placed in LOG_DIR. The command line option can
> > be named --log-filename accordingly.
> 
> But I only need the date part. I still want sbuild to take care of the 
> filename,
> just not of the timestamp part of the filename.
> 
> I'll take a look at your hints above and see what I can do.

You could also add a LOG_TIMEFORMAT variable which by default would be set to
"%FT%TZ" but which you could customize to your liking.

> > If you run sbuild with a fake time, you also run apt with a fake time which
> > means you potentially get into trouble with https mirrors and their
> > certificate expiration times, for example.
> 
> I know, but that would violate the principle of desert island for QA,
> which I formulate as follows:
> 
> "It must be possible to build all packages in stable several years after
> the release without having to update any of them".
> 
> or in other words:
> 
> "Packages in stable must not contain time bombs preventing their succesful 
> build
> in the few years which follow the release of stable"
> 
> In practice I already found the expiration problem for the release files
> that you mention, so I already know how far in the future I can go.
> 
> My plan is to ask RMs to consider RC any FTBFS bug which happens not just
> the day before we release trixie as stable (which is what we did for bookworm)
> but also some years ahead (for example, maybe two for stable, two for
> oldstable, and one more for general LTS).

Ah okay, I understand. Yes, in that case it makes sense to run sbuild itself in
the future as well. But then you should not run sbuild with LOG_TIMEFORMAT
because a person in the future will not do that. To faithfully re-create what
will happen in the future, you might want to use sbuild in the same way as
well.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1065339: src:r-cran-rstanarm: FTBFS on mips64el and risc64

[Andreas Tille]

Control: retitle -1  src:r-cran-rstanarm: FTBFS on mips64el and risc64
Control: reopen -1
Control: tags -1 upstream
Control: forwarded -1 https://github.com/stan-dev/rstanarm/issues/619
thanks

As per autobuilders log[1] the package fails to build on mips64el and risc64 
with

...
g++ -std=gnu++17 -I"/usr/share/R/include" -DNDEBUG -I"../inst/include" 
-I"/usr/lib/R/site-library/StanHeaders/include/src" -DBOOST_DISABLE_ASSERTS 
-DEIGEN_NO_DEBUG -DBOOST_MATH_OVERFLOW_ERROR_POLICY=errno_on_error -DUSE_STANC3 
-D_HAS_AUTO_PTR_ETC=0 -I'/usr/lib/R/site-library/StanHeaders/include' 
-I'/usr/lib/R/site-library/rstan/include' 
-I'/usr/lib/R/site-library/BH/include' -I'/usr/lib/R/site-library/Rcpp/include' 
-I'/usr/lib/R/site-library/RcppEigen/include' 
-I'/usr/lib/R/site-library/RcppParallel/include'-I/usr/include 
-DTBB_INTERFACE_NEW -I'/usr/lib/R/site-library/RcppParallel/include' 
-D_REENTRANT -DSTAN_THREADS -DTBB_INTERFACE_NEW-fpic  -g -O2 
-ffile-prefix-map=/<>/r-base-4.3.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -c 
stan_files/count.cc -o stan_files/count.o
In file included from 
/usr/include/boost/math/special_functions/detail/bessel_jy.hpp:14,
 from /usr/include/boost/math/special_functions/bessel.hpp:20,
 from 
/usr/lib/R/site-library/StanHeaders/include/stan/math/prim/fun/bessel_first_kind.hpp:6,
 from 
/usr/lib/R/site-library/StanHeaders/include/stan/math/prim/fun.hpp:31,
 from 
/usr/lib/R/site-library/StanHeaders/include/stan/math/prim.hpp:14,
 from 
/usr/lib/R/site-library/StanHeaders/include/src/stan/io/dump.hpp:7,
 from 
/usr/lib/R/site-library/rstan/include/rstan/stan_fit.hpp:43,
 from 
/usr/lib/R/site-library/rstan/include/rstan/rstaninc.hpp:4,
 from stan_files/count.hpp:18,
 from stan_files/count.cc:3:
/usr/include/boost/math/special_functions/gamma.hpp: In instantiation of 
‘boost::math::detail::upper_incomplete_gamma_fract::result_type 
boost::math::detail::upper_incomplete_gamma_fract::operator()() [with T = 
double; result_type = std::pair]’:
/usr/include/boost/math/tools/fraction.hpp:217:20:   required from ‘typename 
boost::math::tools::detail::fraction_traits::result_type 
boost::math::tools::continued_fraction_a(Gen&, const U&, uintmax_t&) [with Gen 
= boost::math::detail::upper_incomplete_gamma_fract; U = double; 
typename detail::fraction_traits::result_type = double; uintmax_t = long 
unsigned int]’
/usr/include/boost/math/tools/fraction.hpp:252:31:   required from ‘typename 
boost::math::tools::detail::fraction_traits::result_type 
boost::math::tools::continued_fraction_a(Gen&, const U&) [with Gen = 
boost::math::detail::upper_incomplete_gamma_fract; U = double; typename 
detail::fraction_traits::result_type = double]’
/usr/include/boost/math/special_functions/gamma.hpp:314:68:   required from ‘T 
boost::math::detail::upper_gamma_fraction(T, T, T) [with T = double]’
/usr/include/boost/math/special_functions/gamma.hpp:1176:44:   required from ‘T 
boost::math::detail::gamma_incomplete_imp(T, T, bool, bool, const Policy&, T*) 
[with T = double; Policy = 
boost::math::policies::policy,
 boost::math::policies::promote_float, 
boost::math::policies::promote_double, 
boost::math::policies::default_policy, boost::math::policies::default_policy, 
boost::math::policies::default_policy, boost::math::policies::default_policy, 
boost::math::policies::default_policy, boost::math::policies::default_policy, 
boost::math::policies::default_policy, boost::math::policies::default_policy, 
boost::math::policies::default_policy, boost::math::policies::default_policy>]’
/usr/include/boost/math/special_functions/gamma.hpp:2130:35:   required from 
‘boost::math::tools::promote_args_t boost::math::gamma_p(RT1, RT2, 
const Policy&) [with RT1 = double; RT2 = double; Policy = 
policies::policy,
 policies::pole_error, 
policies::promote_double, policies::digits2<0>, 
policies::default_policy, policies::default_policy, policies::default_policy, 
policies::default_policy, policies::default_policy, policies::default_policy, 
policies::default_policy, policies::default_policy, policies::default_policy>; 
tools::promote_args_t = double]’
/usr/lib/R/site-library/StanHeaders/include/stan/math/prim/fun/gamma_p.hpp:76:30:
   required from here
/usr/include/boost/math/special_functions/gamma.hpp:299:16: note: the ABI for 
returning a value with C++17 empty bases but otherwise an aggregate with only 
one or two floating-point fields was changed in GCC 12.1
  299 |result_type operator()()
  |^~~~
"/usr/lib/R/bin/Rscript" -e "source(file.path('..', 'tools', 'make_cc.R')); 
make_cc(commandArgs(TRUE))" stan_files/jm.stan
code for methods in class "Rcpp_model_base" was not checked for suspicious 
field assignments (recommended package 'codetools' not available?)
code for methods in class 

Bug#1053334: galera-4: FTBFS because of expired certificates

[Santiago Vila]

El 23/12/23 a las 3:07, Otto Kekäläinen escribió:

Sure, this will be fixed (automatically) with uploading latest upstream minor 
release as stable update, and I intend to do it in coming 1-2 weeks.


Hi. Can you elaborate on that? Release managers do not usually allow
new upstream releases in stable. Is this something for which you have
already an ok from them?

I'm trying to ensure that all packages in stable build from source
in stable, so this kind of "will be fixed eventually" is not good enough
in my opinion.

Thanks.

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Russ Allbery]

Philipp Kern  writes:
> On 04.04.24 20:51, Bill Allombert wrote:

>> I still think we should allow Autobuild: no as an escape hatch.  If we
>> want to require non-free package to be autobuildable, we should be more
>> explicit about it (and probably require more feedback from
>> debian-devel).

> There is no requirement for non-free to be autobuildable today. This
> change also does not introduce this, except for everything that is to be
> built on official builders to not require network access.

I think Bill's point is that the section of Policy being changed here
isn't only for autobuilt packages.  It sets general requirements for all
Debian packages, including non-free packages that are never autobuilt, and
therefore arguably prohibits network use during the build of a non-free
package that was never intended to build on the autobuilders, which is a
bit outside the scope of the original motivation for this change.

(I didn't understand that point at first.)

I'm not sure what I think about that.  We have a general escape hatch
already for non-free packages in Policy 2.2.3 that says they may not fully
comply with Policy, which may be sufficient.  Builds that use the network
seem like a bad idea even in non-free packages because it means we may not
be able to rebuild them since all of the relevant data is not in the
Debian source package.

-- 
Russ Allbery (r...@debian.org)  

Bug#1068420: pidgin-gnome-keyring - still depends on old libpurple after binnmu

[Peter Green]

Package: pidgin-gnome-keyring
Version: 2.0-2
Severity: grave
Tags: trixie, sid
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition,
obs-advanced-scene-switcher still depends on libpurple0,
rather than libpurple0t64. As a result it is uninstallable on
architectures that are undergoing the time64 transition
(armel, armhf and some debian-ports architectures).

Ubuntu has applied a fix for this.

https://launchpadlibrarian.net/721511958/pidgin-gnome-keyring_2.0-2_2.0-2ubuntu1.diff.gz

Bug#1068363: src:autopkgtest: flaky autopkgtest (host dependent?) on ppc64el

[Paul Gevers]

Control: retitle -1 autopkgtest: test_copy_timeout fails on tmpfs

Hi,

On 04-04-2024 10:08 a.m., Paul Gevers wrote:
Overall, I 
expect the host to be *faster* than the old hosts, but ironically the 
tests that seems to fail is: __main__.SchrootRunner.test_copy_timeout. 


Yes, it's too fast. The test is testing a huge file and expects the copy 
to fail because it should take longer. Well, with tmpfs the autopktest 
inside the test passes and hence the outer test fails.


https://ci.debian.net/packages/a/autopkgtest/testing/ppc64el/44781763/
640s 16:22:15 O: handling copying timeout ... FAIL
640s 16:22:15 E: # command stdout:
640s 16:22:15 E: # to   PASS
...
640s 16:22:15 E: # exit status: 0

As also amd64 has /tmp on tmpfs, I don't immediately suspect that to be 
the problem;


I forgot that on amd64, autopkgtest's autopkgtest now runs in qemu which 
doesn't benefit yet as much from tmpfs as lxc does, so it's not a good 
comparison.


Is there a way to detect if we're on tmpfs? We should skip this test then.

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Philipp Kern]

Hi,

On 04.04.24 20:51, Bill Allombert wrote:

I still think we should allow Autobuild: no as an escape hatch.
If we want to require non-free package to be autobuildable, we should
be more explicit about it (and probably require more feedback from
debian-devel).


There is no requirement for non-free to be autobuildable today. This 
change also does not introduce this, except for everything that is to be 
built on official builders to not require network access.


There are even two stages of allowlisting today (file-based and the dsc 
field).


Kind regards
Philipp Kern

Bug#1068419: perdition: dependencies unsatisfiable after binnmu for time64 transition.

[Peter Green]

Package: perdition
Version: 2.2-3.3
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, perdition
depends on both libvanessa-socket2 and libvanessa-socket2.
As a result it is uninstallable.

Interesting in this case, the uninstallability seems to apply
to all architectures and not just those undergoing the
time64 transition.

Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie

[Thorsten Glaser]

Szabolcs Nagy dixit:

>the next culprit is gcc (each target can have their own

gcc-13_13.2.0-23

>static pie specs) or the way you invoked gcc (not visible

As I wrote earlier, though with more flags. Dropping all the -D…
and -W… and -I… and other irrelevant ones:

musl-gcc -Os -g -fPIE -fno-lto -fno-asynchronous-unwind-tables
-fno-strict-aliasing -fstack-protector-strong -fwrapv -c …
musl-gcc -Os -g -fPIE -fno-lto -fno-asynchronous-unwind-tables
-fno-strict-aliasing -fstack-protector-strong -fwrapv
-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -static -static-pie
-fno-lto -o mksh  *.o

Same for both. You can see the full log by activating the
[64]Installed and [71]Installed links respectively on
https://buildd.debian.org/status/package.php?p=mksh and
skipping to 'compilation of mksh in static-musl' to get to
the beginning of the configure phase for that.

>are you sure static pie works on these targets?

No ;-) That’s why I reported this issue. I had just
enabled it for the musl builds, as the security people
like that more than normal static.

Thanks for looking,
//mirabilos
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Bug#1068418: rust-openssl: CVE-2024-3296

[Salvatore Bonaccorso]

Source: rust-openssl
Version: 0.10.64-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/sfackler/rust-openssl/issues/2171
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for rust-openssl.

CVE-2024-3296[0]:
| A timing-based side-channel exists in the rust-openssl package,
| which could be sufficient to recover a plaintext across a network in
| a Bleichenbacher-style attack. To achieve successful decryption, an
| attacker would have to be able to send a large number of trial
| messages for decryption. The vulnerability affects the legacy
| PKCS#1v1.5 RSA encryption padding mode.


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-3296
https://www.cve.org/CVERecord?id=CVE-2024-3296
[1] https://github.com/sfackler/rust-openssl/issues/2171

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1068416: ssh-agent: improve systemd user session integration

[Daniel Kahn Gillmor]

Package: openssh-client
Version: 1:9.7p1-4
Severity: wishlist
X-Debbugs-Cc: Daniel Kahn Gillmor 
Tags: patch

Hi Debian OpenSSH maintainers!

ssh-agent is a critical piece of infrastructure for my workflow, and i
want it better integrated with my user session, which is managed by
systemd's per-user login manager (`systemd --user`).

It seems to me that the ideal scenario is to use a socket-activated
ssh-agent at a fixed location (in $XDG_RUNTIME_DIR).

The attached series of patches do this, by:

- patching ssh-agent.c to enable socket-activation when run in the
  foreground and the environment matches that described in
  sd_listen_fds(3)

- Adding an ssh-agent.socket file to debian/systemd/, so that the user
  session manager creates the socket and updates the dbus and systemd
  activation environments to point to the socket.  This systemd unit
  should be automatically activated at user login.

- Updating debian's ssh-agent.service unit to simply run ssh-agent in
  the foreground, accepting the distributed socket as its listening
  port.  I think this makes /usr/lib/openssh/agent-launch superfluous;
  maybe it can be removed.

- making `ssh-agent -k` Do What I Mean™ when $SSH_AGENT_PID is unset --
  it just tries to run `systemctl --user stop ssh-agent`, which has the
  same semantics.

Happy to get any feedback on this proposed change.

  --dkg

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

Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 openssh-client depends on:
ii  adduser   3.137
ii  libc6 2.37-15
ii  libedit2  3.1-20230828-1
ii  libfido2-11.14.0-1
ii  libgssapi-krb5-2  1.20.1-5+b1
ii  libselinux1   3.5-2
ii  libssl3t643.1.5-1.1
ii  passwd1:4.13+dfsg1-4
ii  zlib1g1:1.3.dfsg-3+b1

Versions of packages openssh-client recommends:
ii  xauth  1:1.1.2-1

Versions of packages openssh-client suggests:
pn  keychain 
pn  libpam-ssh   
ii  monkeysphere 0.44-1
ii  ssh-askpass-gnome [ssh-askpass]  1:9.7p1-4

-- no debconf information
From c5fc76aab1b956c74b2a46b45532f5802f7a1c1a Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Thu, 4 Apr 2024 13:09:10 -0400
Subject: [PATCH 1/3] ssh-agent: automatically detect when socket-activated via
 systemd

Socket activation for the ssh-agent is useful for several reasons:

- the systemd user session can choose and reserve the socket before
  the session has fully started.

- systemd can inject SSH_AUTH_SOCK directly into the dbus and systemd
  environment, even before the agent is started.

- the agent will be started lazily, on-demand.  This consumes no
  system resources (not even a pid) if the user never tries to talk to
  the agent, and the agent will inherit the systemd service activation
  environment when it is first accessed (for example, if it is first
  accessed from a Wayland session, $WAYLAND_DISPLAY will be set; if it
  is first accessed from an X11 session, $DISPLAY will be set).

We only enter this mode if the following conditions are true:

 - One of the -D or -d flags are given, and no command arguments are
   present (ssh-agent when supervised by systemd must be run in the
   foreground and not as a subprocess), and

 - The environment variable conditions described in
   sd_listen_fds(3) are met, and only a single socket is provided.
---
 ssh-agent.1 |  8 
 ssh-agent.c | 55 +++--
 2 files changed, 44 insertions(+), 19 deletions(-)

diff --git a/ssh-agent.1 b/ssh-agent.1
index 1ab7d729d..0ce0cd781 100644
--- a/ssh-agent.1
+++ b/ssh-agent.1
@@ -247,6 +247,14 @@ starts, it creates a
 socket and stores its pathname in this variable.
 It is accessible only to the current user,
 but is easily abused by root or another instance of the same user.
+.It Ev SD_LISTEN_FDS
+When
+.Nm
+starts, if no socket path has been specified, but this variable and the
+accompanying SD_LISTEN_PID are set as described in
+.Xr sd_listen_fds 3 ,
+.Nm
+uses the socket passed in by the systemd supervisor.
 .El
 .Pp
 In Debian,
diff --git a/ssh-agent.c b/ssh-agent.c
index d35741a86..47472e069 100644
--- a/ssh-agent.c
+++ b/ssh-agent.c
@@ -2194,7 +2194,7 @@ main(int ac, char **av)
 {
 	int c_flag = 0, d_flag = 0, D_flag = 0, k_flag = 0, s_flag = 0;
 	int sock, ch, result, saved_errno;
-	char *shell, *format, *pidstr, *agentsocket = NULL;
+	char *shell, *format, *pidstr, *listen, *agentsocket = NULL;
 #ifdef 

Bug#1068417: trafficserver: CVE-2024-31309: HTTP/2 CONTINUATION frames can be utilized for DoS attacks

[Salvatore Bonaccorso]

Source: trafficserver
Version: 9.2.3+ds-1+deb12u1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 8.1.9+ds-1~deb11u1

Hi,

The following vulnerability was published for trafficserver.

CVE-2024-31309[0].

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-31309
https://www.cve.org/CVERecord?id=CVE-2024-31309
[1] https://www.kb.cert.org/vuls/id/421644
[2] https://github.com/apache/trafficserver/pull/11207
[3] https://github.com/apache/trafficserver/pull/11206

Regards,
Salvatore

Bug#996202: EFI Secure Boot for systemd-boot

[Luca Boccassi]

On Fri, 22 Mar 2024 18:13:35 + Luca Boccassi 
wrote:
> On Mon, 4 Mar 2024 at 23:58, Luca Boccassi  wrote:
> >
> > On Mon, 4 Mar 2024 at 23:28, Steve McIntyre 
wrote:
> >
> > > Modulo those questions, let's talk infrastructure. Off the top of
my
> > > head, in no particular order...
> > >
> > >   * We'll need to create a new intermediate signing cert for
> > > systemd-boot (and another for UKI, I guess). Given recent
> > > discussions about changing the way we build and sign kernels,
we
> > > should also generate a new signer cert for those too. And if
we're
> > > going that far, we may as well generate a complete new set of
2024
> > > certs. [Sorry, rabbithole. :-)] We'll need to talk to DSA
about
> > > doing this piece.
> >
> > That makes sense to me, I guess DSA owns the machinery to do this?
> >
> > >   * We'll probably need to add things to the signing setup for
> > > ftp-master. Nothing earth-shattering, just some config to
> > > recognise the new set of packages IIRC. I'm sure Bastian can
> > > manage this. :-)
> > >
> > >   * Are people from the team ready to deal with long-term
security
> > > support for the systemd-boot chain?
> >
> > Speaking for myself, yes, I am already part of the team who is
> > responsible for that upstream, and I plan to be very strict about
not
> > carrying downstream patches for the signed components outside of
> > security fixes (and even then, prefer upstream stable point
releases
> > that I am also responsible for anyway).
> >
> > > That's all I can think of for now, but I wouldn't be surprised if
more
> > > comes to mind tomorrow... :-)
> >
> > Thanks for the feedback!
> 
> Gentle ping on this - what are the next steps in order to make this
happen?

On IRC Steve mentioned that he's ok with proceeding with this. jcristau
from DSA said that it's the FTP team that should confirm the request
for the new intermediate signer cert for systemd-boot to DSA.

FTP team, are you ok with proceeding with this? If so, would it be
possible to have an ACK, please? Is there any more information required
beforehand?

Thanks!

-- 
Kind regards,
Luca Boccassi


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

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Bill Allombert]

On Thu, Apr 04, 2024 at 09:25:36PM +0200, Philipp Kern wrote:
> Hi,
> 
> On 04.04.24 20:51, Bill Allombert wrote:
> > I still think we should allow Autobuild: no as an escape hatch.
> > If we want to require non-free package to be autobuildable, we should
> > be more explicit about it (and probably require more feedback from
> > debian-devel).
> 
> There is no requirement for non-free to be autobuildable today. This change
> also does not introduce this, except for everything that is to be built on
> official builders to not require network access.

Sorry, could you point me where the diff is limiting its scope to "everything
that is to be built on official builders"  ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1068415: nghttp2: CVE-2024-28182: Reading unbounded number of HTTP/2 CONTINUATION frames to cause excessive CPU usage

[Salvatore Bonaccorso]

Source: nghttp2
Version: 1.60.0-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for nghttp2.

CVE-2024-28182[0]:
| nghttp2 is an implementation of the Hypertext Transfer Protocol
| version 2 in C. The nghttp2 library prior to version 1.61.0 keeps
| reading the unbounded number of HTTP/2 CONTINUATION frames even
| after a stream is reset to keep HPACK context in sync.  This causes
| excessive CPU usage to decode HPACK stream. nghttp2 v1.61.0
| mitigates this vulnerability by limiting the number of CONTINUATION
| frames it accepts per stream. There is no workaround for this
| vulnerability.


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-28182
https://www.cve.org/CVERecord?id=CVE-2024-28182
[1] https://github.com/nghttp2/nghttp2/security/advisories/GHSA-x6x3-gv8h-m57q

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1068414: obs-advanced-scene-switcher - still depends on old libcurl after binnmu

[Peter Green]

Package: obs-advances-scene-switcher
Version: 1.23.1-2
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition,
obs-advanced-scene-switcher still depends on libcurl4,
rather than libcurl4t64. As a result it is uninstallable on
architectures that are undergoing the time64 transition
(armel, armhf and some debian-ports architectures).

Ubuntu has applied a fix for this.

https://launchpadlibrarian.net/720928573/obs-advanced-scene-switcher_1.23.1-2build2_1.23.1-2ubuntu1.diff.gz

Bug#1068413: python3-wilderness: Warning while installing with apt

[Enrique Garcia]

Package: python3-wilderness
Version: 0.1.10-1
Severity: minor
X-Debbugs-Cc: cqu...@arcor.de

While installing the apt python3-wilderness with apt (actually as part of some
other package dependency) I saw the following warning:

Configuring python3-wilderness (0.1.10-1) ...
/usr/lib/python3/dist-packages/wilderness/manpages.py:146: SyntaxWarning:
invalid escape sequence '\ '
  """Format a text line for use in manpages
/usr/lib/python3/dist-packages/wilderness/manpages.py:173: SyntaxWarning:
invalid escape sequence '\ '
  match = re.match("^\ ?\d+\.\ ", line)

Probably it is not very important, but since I have never seen such code
warnings while installing with apt I thought it was useful to report it.


-- 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)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_ES:es
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-wilderness depends on:
ii  python3  3.11.6-1

python3-wilderness recommends no packages.

python3-wilderness suggests no packages.

-- no debconf information

Bug#1068412: apache2: CVE-2024-27316 CVE-2024-24795 CVE-2023-38709

[Moritz Mühlenhoff]

Source: apache2
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for apache2.

CVE-2024-27316[0]:
https://www.kb.cert.org/vuls/id/421644
https://www.openwall.com/lists/oss-security/2024/04/04/4

CVE-2024-24795[1]:
https://www.openwall.com/lists/oss-security/2024/04/04/5

CVE-2023-38709[2]:
https://www.openwall.com/lists/oss-security/2024/04/04/3

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-27316
https://www.cve.org/CVERecord?id=CVE-2024-27316
[1] https://security-tracker.debian.org/tracker/CVE-2024-24795
https://www.cve.org/CVERecord?id=CVE-2024-24795
[2] https://security-tracker.debian.org/tracker/CVE-2023-38709
https://www.cve.org/CVERecord?id=CVE-2023-38709

Please adjust the affected versions in the BTS as needed.

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-freeo

[Bill Allombert]

On Thu, Apr 04, 2024 at 11:42:34AM -0700, Russ Allbery wrote:
> Tobias Frost  writes:
> > On Wed, Apr 03, 2024 at 10:58:37PM +0200, Aurelien Jarno wrote:
> 
> >> Thanks Philipp. Following that result, please find a patch proposal: 
> >> 
> >> --- a/policy/ch-source.rst
> >> +++ b/policy/ch-source.rst
> >> @@ -338,9 +338,9 @@
> >>  For example, the build target should pass ``--disable-silent-rules``
> >>  to any configure scripts.  See also :ref:`s-binaries`.
> >>  
> >> -For packages in the main archive, required targets must not attempt
> >> -network access, except, via the loopback interface, to services on the
> >> -build host that have been started by the build.
> >> +Required targets must not attempt network access, except, via the
> >> +loopback interface, to services on the build host that have been started
> >> +by the build.
> >>  
> >>  Required targets must not attempt to write outside of the unpacked
> >>  source package tree.  There are two exceptions.  Firstly, the binary
> 
> > LGTM, Seconded.
> 
> Also looks good to me.  Seconded.

I still think we should allow Autobuild: no as an escape hatch.
If we want to require non-free package to be autobuildable, we should
be more explicit about it (and probably require more feedback from
debian-devel).

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1068411: bookworm-pu: package schleuder/4.0.3-7+deb12u1

[Georg Faerber]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
Control: affects -1 + src:schleuder

Dear release team,

Schleuder, as currently present in bookworm, 4.0.3-7, is affected by
multiple bugs, which I would like to address via this proposed-update,
4.0.3-7+deb12u1.

All fixes as detailed below were made upstream, and fixed in unstable
via 4.0.3-11.

[ Reasons ]
- The 'x-subscribe' keyword doesn't enforce proper validation of
  optional flags. Due to this, an email address might get erroneously
  subscribed with 'admin' permissions.

- The 'x-add-key' keyword fails to import keys from attachments as
  Thunderbird sends them. This regression was introduced in 4.0.0.

- The 'x-add-key' keyword doesn't return a proper error message, if an
  email contains no further content or attachments.

- The 'message handler' strips keywords in the middle of emails. People
  might send "usage instructions", including keywords and details how to
  use them, within an email to a Schleuder list. Due to the keywords
  being removed, the value of such emails is greatly limited.

- The list option 'receive_from_subscribed_emailaddresses_only' checks
  an email address case-sensitive. Valid emails might get erroneously
  rejected, if an uppercase email address was used in the From: header
  of the incoming email.

- The 'message handler' doesn't consider the email address as used in
  the From: header of the incoming mail, when finding the email address
  to send the reply to. A reply might be send to a wrong email address,
  in case of multiple subscriptions which rely on the same key.

[ Impacts ]
- Severe; due to insufficient input validation, subscriptions might get
  'admin' privileges assigned, while they must not. This poses a
  security threat.

- Bad UX; a workaround might be to send an email which inlines keys in
  the email body.

- Bad UX; users might be left clueless if the import of keys was
  successful or wasn't, as no reply is send.

- Bad UX; a workaround might be to send such an email offlist, which
  might be challenging if: such an email should be encrypted, as all
  relevant keys would be required; or: the list of subscriptions of a
  Schleuder list is (partially) unknown.

- Bad UX; a workaround might be to disable this list option.
  Alternatively, the casing of the email address in the From: header
  could be adjusted, which might be impossible depending on the
  environment people operate in.

- Bad UX, possible implications of privacy and security if a user
  subscribes two email addresses, which rely on the same key, but are
  intended to be used for different list actions, like "admin" vs.
  "regular"; a workaround might be to rely on distinct keys.

[ Tests ]
Tests were done via upstream and Debian CI, manually and on production
systems for several weeks.

[ Risks ]
Risks should be low, as extensive testing happened. All fixes are
targeted and only change related code. The vast majority of the attached
debdiff makes changes to the testsuite, the actual code changes are
quite limited.

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

[ Changes ]
- x-subscribe: fix parsing of arguments. Optional flags provided at the
  end are only taken into account if there is a valid fingerprint, and
  they are checked to be "true", or "false". Before, due to insufficient
  validation, an email address might have been erroneously subscribed
  with 'admin' permissions. (Closes: #1068330)

- x-add-key: fix importing keys from attachments as Thunderbird sends
  them. Before, such attachments were ignored. This regression was
  introduced in 4.0.0. (Closes: #1068331)

- x-add-key: fix handling of emails without further content or
  attachments. A proper error message is returned. Before, a traceback
  was thrown. (Closes: #1068332)

- Stop looking for keywords if email starts with other content. This
  allows to send usage instructions including keywords within an email
  to a Schleuder list. Before, these keywords would have been stripped,
  which limited the value of such an email. This change matches
  documentation, which tells that keywords require that they are written
  in the beginning of an email body. (Closes: #1068333)

- receive_from_subscribed_emailaddresses_only(): check downcased email
  address. This follows and mirrors changes made in both schleuder-cli
  and schleuder-web, which nowadays enforce lowercase if adding
  subscriptions. Before, incoming emails might have been erroneously
  rejected, if an uppercase email address was used in the From: header.
  (Closes: #1068334)

- Consider From: when finding reply address. Look for a subscription
  that matches the sending email address, in case of multiple
  subscriptions which rely on the same key. As a fallback, the first

Bug#1068410: libwireshark-dev: Package is missing mandatory "dfilter-loc.h"

[Thorsten]

Package: libwireshark-dev
Version: 4.2.2-1.1+b1
Severity: important
X-Debbugs-Cc: contact.thors...@gmail.com

Dear Maintainer,

   * What led up to the situation?

Trying to build an external package dissector.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Including /usr/include/wireshark/epan/plugin_if.h in the source to build a 
dissector.

   * What was the outcome of this action?

In file included from /usr/include/wireshark/cfile.h:17,
 from /usr/include/wireshark/epan/plugin_if.h:26,
 from packet-trdp_spy.c:52:
/usr/include/wireshark/epan/dfilter/dfilter.h:15:10: fatal error: 
dfilter-loc.h: file missing

   * What outcome did you expect instead?

successful build


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

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

Versions of packages libwireshark-dev depends on:
ii  libwireshark17t64  4.2.2-1.1+b1
ii  libwiretap-dev 4.2.2-1.1+b1
ii  libwsutil-dev  4.2.2-1.1+b1

libwireshark-dev recommends no packages.

libwireshark-dev suggests no packages.

-- no debconf information

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free

[Russ Allbery]

Tobias Frost  writes:
> On Wed, Apr 03, 2024 at 10:58:37PM +0200, Aurelien Jarno wrote:

>> Thanks Philipp. Following that result, please find a patch proposal: 
>> 
>> --- a/policy/ch-source.rst
>> +++ b/policy/ch-source.rst
>> @@ -338,9 +338,9 @@
>>  For example, the build target should pass ``--disable-silent-rules``
>>  to any configure scripts.  See also :ref:`s-binaries`.
>>  
>> -For packages in the main archive, required targets must not attempt
>> -network access, except, via the loopback interface, to services on the
>> -build host that have been started by the build.
>> +Required targets must not attempt network access, except, via the
>> +loopback interface, to services on the build host that have been started
>> +by the build.
>>  
>>  Required targets must not attempt to write outside of the unpacked
>>  source package tree.  There are two exceptions.  Firstly, the binary

> LGTM, Seconded.

Also looks good to me.  Seconded.

-- 
Russ Allbery (r...@debian.org)  

Bug#1068401: Pending uplad (Was: Bug#1068401: ltrsift dependencies unsatisfiable on 32-bit non-i386 architectures.)

[Andreas Tille]

Control: tags -1 pending
thanks

Hi Sascha,

after routine-update dh_missing failed due to compat level 13
which defaults to fail if some files are not installed.

This made me aware that upstream in principle installs a
test suite we could use for an autopkgtest.  I also realised
that you once added debian/ltrsift-examples.examples - so
you probably had such a package in mind.

Since I have no idea what reasons you had not to use this
file I'll leave the final decision to you.

(Please note:  Somehow a copy of ltrsift_code ends up in
the examples dir - I did not yet investigated why this is
happening.  Before I have no clear picture about your
intentions I'll left this for later investigation.)

Kind regards
Andreas.

-- 
https://fam-tille.de

Bug#834736: [buildd-tools-devel] Bug#834736: sbuild: Use basic format for ISO 8601 timestamps (for build logs filenames)

[Santiago Vila]

El 4/4/24 a las 19:44, Johannes Schauer Marin Rodrigues escribió:

instead of doing that, you could've worked around this by just placing the
build log into a dedicated temporary directory and then copying it to where you
want it after the build is finished.


That would be an option, yes, but maybe it's too convoluted for my taste.


Can you give me a small hint about how I should proceed?  (For example, which
files in the source would require to be modified?) (Preferred name for the
command line?)


An example commit that adds a new option would be
a44b29e76450ce8c80467e0957ebc6909167e425 by Jochen. You need to touch these
files:

  - lib/Sbuild/Build.pm to implement the thing
  - lib/Sbuild/Conf.pm to add the configuration option
  - lib/Sbuild/Options.pm to add the command line argument changing the config
option
  - man/sbuild.1.in to document the command line argument


Thanks a lot! I'll try that.


I think I'd find an option useful which allows to pass a completely custom
build log filename. There is already the LOG_DIR configuration variable. Maybe
add the LOG_FILENAME configuration variable containing the filename that the
log will have when placed in LOG_DIR. The command line option can be named
--log-filename accordingly.


But I only need the date part. I still want sbuild to take care of the filename,
just not of the timestamp part of the filename.

I'll take a look at your hints above and see what I can do.


Don't run sbuild in the future. Only run dpkg inside sbuild in the future. This
is what the BUILD_ENV_CMND option lets you do. From the man page:


This command is run with the dpkg-buildpackage command line passed to it (in
the chroot, if doing a chrooted build).  It is used by the sparc buildd
(which is sparc64) to call the wrapper script that sets the environment to
sparc (32-bit).  It could be used for other build environment setup scripts.


I'm not sure that running only dpkg in the future is what I want to do.

I want to recreate the experience of building in the future as faithfully
as possible, so I believe setting the system clock still makes sense.


If you run sbuild with a fake time, you also run apt with a fake time which
means you potentially get into trouble with https mirrors and their certificate
expiration times, for example.


I know, but that would violate the principle of desert island for QA,
which I formulate as follows:

"It must be possible to build all packages in stable several years after
the release without having to update any of them".

or in other words:

"Packages in stable must not contain time bombs preventing their succesful build
in the few years which follow the release of stable"

In practice I already found the expiration problem for the release files
that you mention, so I already know how far in the future I can go.

My plan is to ask RMs to consider RC any FTBFS bug which happens not just
the day before we release trixie as stable (which is what we did for bookworm)
but also some years ahead (for example, maybe two for stable, two for oldstable,
and one more for general LTS).

Thanks.

Bug#1068409: dovecot-core: avoid linking against libsystemd0

[Jörg-Volker Peetz]

Package: dovecot-core
Version: 1:2.3.21+dfsg1-3+b1
Severity: wishlist

Dear Maintainer(s),

in light of the recent xz security breach, I'd like to ask if it
would be possible to rework systemd readiness notification and socket
activation patches to not link against libsystemd as just achieved for
the openssh-server package in version 1:9.7p1-4 ?
This would avoid /usr/bin/dovecot being linked also to three compression
libraries (liblz4, liblzma, libzstd) and to libgpg-error.

Regards,
Jörg.

Bug#1068408: Kicad bundle broken

[Terrance Hendrik]

Package: kicad
Version: 7.0.11+dfsg-1

I am using Debian testing/trixie, the Kicad bundle has multiple issues.

1. kicad-footprints kicad-packages3d kicad-symbols kicad-templates (7.x)
are all missing. I also checked stable sources.
```
# apt install kicad-footprints=
Completing package version
6.0.11-1  -- http://deb.debian.org/debian stable/main amd64 Packages
8.0.1-1   -- http://deb.debian.org/debian testing/main amd64 Packages
```
2. I also have "unstable" source for apt, when upgrading, kicad-footprints
kicad-packages3d kicad-symbols kicad-templates got upgraded to 8.0, which
Kicad 7.0 does not compatible with.

Kicad and its footprints packages3d symbols templates

3. kicad-libraries should not Depends kicad-footprints (>= 7.0.0~),
kicad-symbols (>= 7.0.0~), kicad-templates (>= 7.0.0~)，rather >= 7.0.0
<8.0.0


Kicad can only access libraries with same or lower major version.

Bug#1054514: [PATCH v2 1/1] Revert "drm/qxl: simplify qxl_fence_wait"

[Alex Constantino]

This reverts commit 5a838e5d5825c85556011478abde708251cc0776.

Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
result in a '[TTM] Buffer eviction failed' exception whenever it reached a
timeout.
Due to a dependency to DMA_FENCE_WARN this also restores some code deleted
by commit d72277b6c37d ("dma-buf: nuke DMA_FENCE_TRACE macros v2").

Fixes: 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait")
Link: https://lore.kernel.org/regressions/ztgydqrlk6wx_...@eldamar.lan/
Reported-by: Timo Lindfors 
Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054514
Signed-off-by: Alex Constantino 
---
 drivers/gpu/drm/qxl/qxl_release.c | 50 +++
 include/linux/dma-fence.h |  7 +
 2 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
b/drivers/gpu/drm/qxl/qxl_release.c
index 368d26da0d6a..9febc8b73f09 100644
--- a/drivers/gpu/drm/qxl/qxl_release.c
+++ b/drivers/gpu/drm/qxl/qxl_release.c
@@ -58,16 +58,56 @@ static long qxl_fence_wait(struct dma_fence *fence, bool 
intr,
   signed long timeout)
 {
struct qxl_device *qdev;
+   struct qxl_release *release;
+   int count = 0, sc = 0;
+   bool have_drawable_releases;
unsigned long cur, end = jiffies + timeout;
 
qdev = container_of(fence->lock, struct qxl_device, release_lock);
+   release = container_of(fence, struct qxl_release, base);
+   have_drawable_releases = release->type == QXL_RELEASE_DRAWABLE;
 
-   if (!wait_event_timeout(qdev->release_event,
-   (dma_fence_is_signaled(fence) ||
-(qxl_io_notify_oom(qdev), 0)),
-   timeout))
-   return 0;
+retry:
+   sc++;
+
+   if (dma_fence_is_signaled(fence))
+   goto signaled;
+
+   qxl_io_notify_oom(qdev);
+
+   for (count = 0; count < 11; count++) {
+   if (!qxl_queue_garbage_collect(qdev, true))
+   break;
+
+   if (dma_fence_is_signaled(fence))
+   goto signaled;
+   }
+
+   if (dma_fence_is_signaled(fence))
+   goto signaled;
+
+   if (have_drawable_releases || sc < 4) {
+   if (sc > 2)
+   /* back off */
+   usleep_range(500, 1000);
+
+   if (time_after(jiffies, end))
+   return 0;
+
+   if (have_drawable_releases && sc > 300) {
+   DMA_FENCE_WARN(fence,
+  "failed to wait on release %llu after 
spincount %d\n",
+  fence->context & ~0xf000, sc);
+   goto signaled;
+   }
+   goto retry;
+   }
+   /*
+* yeah, original sync_obj_wait gave up after 3 spins when
+* have_drawable_releases is not set.
+*/
 
+signaled:
cur = jiffies;
if (time_after(cur, end))
return 0;
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index e06bad467f55..c3f9bb6602ba 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -682,4 +682,11 @@ static inline bool dma_fence_is_container(struct dma_fence 
*fence)
return dma_fence_is_array(fence) || dma_fence_is_chain(fence);
 }
 
+#define DMA_FENCE_WARN(f, fmt, args...) \
+   do {\
+   struct dma_fence *__ff = (f);   \
+   pr_warn("f %llu#%llu: " fmt, __ff->context, __ff->seqno,\
+##args);   \
+   } while (0)
+
 #endif /* __LINUX_DMA_FENCE_H */
-- 
2.39.2

Bug#1054514: [PATCH v2 0/1] Revert "drm/qxl: simplify qxl_fence_wait"

[Alex Constantino]

Changes since v1:
- replace new code logic in v1 with past code version by reverting
  commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait")
- add missing code dependency from
  commit d72277b6c37d ("dma-buf: nuke DMA_FENCE_TRACE macros v2")

---

Hi,

To clarify, the reason for my original patch, as explained in more detail
in my previous email, was that it fixed the issue while keeping the code
simpler (which was the original reason for the commit being reverted here).
But I perfectly understand opting for previously battle tested code. Makes
sense.

As requested I've reverted commit 5a838e5d5825 ("drm/qxl: simplify 
qxl_fence_wait")
and then executed both Timo's and my test cases, and 1h video playback.
I was unable to reproduce the bug with any of those cases. So the revert
seems to fix the bug.
Please note, and as stated in the commit message, due to a dependency to
DMA_FENCE_WARN this patch also restores the relevant code deleted
by commit d72277b6c37d ("dma-buf: nuke DMA_FENCE_TRACE macros v2").

A couple of things I've observed from dmesg:
- (1) it always triggers a single warning at boot, this is issued by
  `WARN_ON(list_empty(>bos));` @ qxl_release_free @ qxl_release.c
  Maybe better for this to be addressed separately from this patch?
- (2) there are quite a few `failed to wait on release xx after spincount
  301` messages as printed by the patch v2 code when the test case shell
  scripts are being executed.
- (3) there can be a single error message `[drm:qxl_release_from_id_locked
  [qxl]] *ERROR* failed to find id in release_idr`
- (4) occasional error messages about `[drm:drm_atomic_helper_commit_planes
  [drm_kms_helper]] *ERROR* head 9 wrong:`.

Issue (1) relates to this patch v2 and also happened with kernel from
base-commit 1870cdc0e8de (March 1st).
Issue (2) also relates to this patch v2 but only happens with kernel from
base-commit a6bd6c99 (March 30th).
Both (3) and (4) are unrelated to this patch as they can occur
independently of it and I'm guessing these may be related to the recent
changes discussed in
https://lore.kernel.org/dri-devel/38d38331-3848-4995-b78e-a87ecae72...@linux.intel.com/T/#u


For reference here is the output of (1):
```
[   20.779514] [ cut here ]
[   20.779525] workqueue: WQ_MEM_RECLAIM ttm:ttm_bo_delayed_delete [ttm] is 
flushing !WQ_MEM_RECLAIM events:qxl_gc_work [qxl]
[   20.779666] WARNING: CPU: 1 PID: 601 at kernel/workqueue.c:3692 
check_flush_dependency+0xfa/0x110
[   20.779683] Modules linked in: nfsv3 nfs_acl nfs lockd grace intel_rapl_msr 
intel_rapl_common intel_pmc_core intel_vsec pmt_telemetry pmt_class kvm_intel 
rfkill kvm snd_hda_codec_generic crct10dif_pclmul crct10dif_common crc32_pclmul 
ghash_clmulni_intel snd_hda_intel snd_intel_dspcfg sha512_ssse3 sha512_generic 
snd_hda_codec sha256_ssse3 snd_hwdep sha1_ssse3 snd_hda_core sunrpc binfmt_misc 
snd_pcm aesni_intel qxl drm_ttm_helper ttm crypto_simd snd_timer cryptd rapl 
snd virtio_balloon virtio_console drm_kms_helper pcspkr soundcore button evdev 
joydev serio_raw drm loop fuse efi_pstore dm_mod configfs qemu_fw_cfg 
virtio_rng autofs4 ext4 crc32c_generic crc16 mbcache jbd2 virtio_net 
ata_generic net_failover virtio_blk failover uhci_hcd ata_piix ehci_hcd libata 
scsi_mod usbcore crc32c_intel i2c_piix4 virtio_pci virtio psmouse 
virtio_pci_legacy_dev virtio_pci_modern_dev virtio_ring floppy scsi_common 
usb_common
[   20.779825] CPU: 1 PID: 601 Comm: kworker/u13:1 Not tainted 
6.9.0-rc1-next-20240328-amd64-1-g756220c4615c #81
[   20.779833] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.14.0-2 04/01/2014
[   20.779837] Workqueue: ttm ttm_bo_delayed_delete [ttm]
[   20.779862] RIP: 0010:check_flush_dependency+0xfa/0x110
[   20.779869] Code: ff ff 49 8b 55 18 48 8d 8b c0 00 00 00 49 89 e8 48 81 c6 
c0 00 00 00 48 c7 c7 c0 16 44 8d c6 05 e7 75 b3 01 01 e8 86 97 fd ff <0f> 0b e9 
21 ff ff ff 80 3d d5 75 b3 01 00 75 96 e9 4d ff ff ff 90
[   20.779875] RSP: :b59600dd7cc8 EFLAGS: 00010082
[   20.779880] RAX:  RBX: 9af88104ee00 RCX: 0027
[   20.779902] RDX: 9af8fdd21708 RSI: 0001 RDI: 9af8fdd21700
[   20.779906] RBP: c0882570 R08:  R09: 0003
[   20.779910] R10: b59600dd7b58 R11: 8dcc83e8 R12: 9af894498000
[   20.779914] R13: 9af89558d780 R14: b59600dd7cf8 R15: 0001
[   20.779918] FS:  () GS:9af8fdd0() 
knlGS:
[   20.779924] CS:  0010 DS:  ES:  CR0: 80050033
[   20.779928] CR2: 5574b0bd4148 CR3: 1fb40002 CR4: 00370ef0
[   20.779994] DR0:  DR1:  DR2: 
[   20.77] DR3:  DR6: fffe0ff0 DR7: 0400
[   20.780003] Call Trace:
[   20.780135]  
[   20.780144]  ? __warn+0x7c/0x120
[   20.780153]  ? check_flush_dependency+0xfa/0x110
[   20.780161]  ? 

Bug#1068192: debian-policy: extended forbidden network access to contrib and non-free

[Tobias Frost]

On Wed, Apr 03, 2024 at 10:58:37PM +0200, Aurelien Jarno wrote:
> Hi,
> 
> On 2024-04-03 12:37, Philipp Kern wrote:
> > Hi,
> > 
> > On Tue, Apr 02, 2024 at 06:58:35AM +0200, Aurelien Jarno wrote:
> > > On 2024-04-02 09:21, Sean Whitton wrote:
> > > > Hello,
> > > > 
> > > > On Mon 01 Apr 2024 at 05:29pm +02, Aurelien Jarno wrote:
> > > > 
> > > > > The debian policy, section 4.9, forbids network access for packages in
> > > > > the main archive, which implicitly means they are authorized for
> > > > > packages in contrib and non-free (and non-free-firmware once #1029211 
> > > > > is
> > > > > fixed).
> > > > >
> > > > > This gives constraints on the build daemons infrastructure and also
> > > > > brings some security concerns. Would it be possible to extend this
> > > > > restriction to all archives?
> > > > 
> > > > We need to know if this is going to break existing packages and allow
> > > > some input from their maintainers.  Are you able to prepare a list of
> > > > the affected packages?
> > > 
> > > Fair enough. I can work on that, but help would be welcome as my
> > > resources are limited.
> > 
> > I did a test rebuild of contrib, non-free and non-free-firmware packages
> > in sid with both stable sbuild schroot and unshare backends and could
> > not find a difference in build success (i.e. what failed failed in both,
> > what succeeded succeeded in both).
> 
> Thanks Philipp. Following that result, please find a patch proposal: 
> 
> --- a/policy/ch-source.rst
> +++ b/policy/ch-source.rst
> @@ -338,9 +338,9 @@
>  For example, the build target should pass ``--disable-silent-rules``
>  to any configure scripts.  See also :ref:`s-binaries`.
>  
> -For packages in the main archive, required targets must not attempt
> -network access, except, via the loopback interface, to services on the
> -build host that have been started by the build.
> +Required targets must not attempt network access, except, via the
> +loopback interface, to services on the build host that have been started
> +by the build.
>  
>  Required targets must not attempt to write outside of the unpacked
>  source package tree.  There are two exceptions.  Firstly, the binary
> 
> Regards
> Aurelien

LGTM, Seconded.

> -- 
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://aurel32.net




signature.asc
Description: PGP signature

Bug#1068382: sbuild: Support tarballs not including ./ when using the unshare chroot mode

[Santiago Vila]

El 4/4/24 a las 19:29, Johannes Schauer Marin Rodrigues escribió:

Also I'm curious: what is your motivation for using unshare mode if you are
creating your chroots using superuser privileges?

And are you really storing your chroots in /srv instead of letting them get
picked up automatically in ~/.cache/sbuild/unstable-arm64.tar?


I am testing the unshare backend at the request of Jochen.

As we speak, I am building all packages in bookworm using unshare.

I already had a working setup for building packages using
the other backends. In my setup, I run debootstrap in a master server,
create the tarballs there, and the build nodes retrieve those
tarballs using wget before they start to build packages.

So in my setup the logical thing to do to test the unshare backend
was to make symlinks to the already existing tarballs at /srv, since
the nodes are not creating any tarballs.

Thanks.

Bug#834736: [buildd-tools-devel] Bug#834736: sbuild: Use basic format for ISO 8601 timestamps (for build logs filenames)

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Santiago Vila (2024-04-04 15:02:05)
> El 4/4/24 a las 14:07, Johannes Schauer Marin Rodrigues escribió:
> > well this is an old bug. How have you worked around it being open for the 
> > past
> > six years?
> 
> This is important for me, so I'm still patching my own sbuild version.  Yes,
> every single time.

instead of doing that, you could've worked around this by just placing the
build log into a dedicated temporary directory and then copying it to where you
want it after the build is finished.

> Can you give me a small hint about how I should proceed?  (For example, which
> files in the source would require to be modified?) (Preferred name for the
> command line?)

An example commit that adds a new option would be
a44b29e76450ce8c80467e0957ebc6909167e425 by Jochen. You need to touch these
files:

 - lib/Sbuild/Build.pm to implement the thing
 - lib/Sbuild/Conf.pm to add the configuration option
 - lib/Sbuild/Options.pm to add the command line argument changing the config
   option
 - man/sbuild.1.in to document the command line argument

> > I also think that there is a more elegant solution to this. If this is just
> > about the timestamp, why not add a new configuration option which allows
> > customizing the default strftime format %FT%TZ to be anything else? You
> > could use such a mechanism to store your own timestamp. This is what you
> > suggested doing earlier in this bug report.
> 
> Unfortunately, it's not just about the date format (that's only how it 
> started),
> it's mainly about sbuild allowing me to specify the build log filename 
> beforehand,
> without it second-guessing the string I really want to use.

I think I'd find an option useful which allows to pass a completely custom
build log filename. There is already the LOG_DIR configuration variable. Maybe
add the LOG_FILENAME configuration variable containing the filename that the
log will have when placed in LOG_DIR. The command line option can be named
--log-filename accordingly.

> I have a recent case where the usefulness of this may be seen easily:
> 
> Last time I tried to rebuild bookworm from source, I found several packages
> which FTBFS because of expired SSL certificates being used in the tests.
> 
> So I decided to build bookworm "in the future" to know which packages will 
> fail
> for similar reasons in the next years.
> 
> I first tried using libfaketime but did not managed for it to work easily.
> 
> At the end, the most reliable way I found was to actually change the
> system clock, like this:
> 
> timedatectl set-time '2031-01-14 12:00:00'
> 
> Now, here is the thing: When I do that, sbuild would think (rightfully)
> that I'm on such date, and would use it for both the contents of
> the build log and also the build log filename.
> 
> However, in this case I still want the build log filename to be
> the present day, because it's the real date where I tried such build in the
> future.

Don't run sbuild in the future. Only run dpkg inside sbuild in the future. This
is what the BUILD_ENV_CMND option lets you do. From the man page:

> This command is run with the dpkg-buildpackage command line passed to it (in
> the chroot, if doing a chrooted build).  It is used by the sparc buildd
> (which is sparc64) to call the wrapper script that sets the environment to
> sparc (32-bit).  It could be used for other build environment setup scripts.

If you run sbuild with a fake time, you also run apt with a fake time which
means you potentially get into trouble with https mirrors and their certificate
expiration times, for example.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1068382: sbuild: Support tarballs not including ./ when using the unshare chroot mode

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Santiago Vila (2024-04-04 15:24:13)
> > how did you create that tarball?
> 
> debootstrap to a directory
> cd /chroot/directory
> tar czvf /srv/whatever.tar.gz *
> 
> Yes, I know what using "." instead of "*" would solve the problem, but as I 
> said,
> sbuild already supports perfectly tarballs without ./ in the "file" backend,
> so the consistent thing would be to support them for unshare as well.

you can do this in less commands by using

tar -C /chroot/directory -czvf /srv/whatever.tar.gz .

In that case, the "*" wildcard would of course not work which is why usually,
people use '.' instead of "*". Another reason against using the glob operator
with tar is, that it will exclude hidden files and then you will end up with a
tarball that does not contain everything in the current directory. Using '.' is
really the safer option independent on whether you use -C or not.

Also I'm curious: what is your motivation for using unshare mode if you are
creating your chroots using superuser privileges?

And are you really storing your chroots in /srv instead of letting them get
picked up automatically in ~/.cache/sbuild/unstable-arm64.tar?

> > Your addition of --anchored drops support for tarballs with members that
> > start with ././ or with ./././ and so on.
> 
> Yes, but those tarballs are a lot more uncommon, so if we had to choose 
> between
> supporting "" and "./" or supporting "./" and "././" and "./././" etc, I guess
> supporting "" and "./" would be preferred.
> 
> So, well spotted, but I don't think that dropping support for ././
> would be a big deal.

I think those tarballs are even more uncommon than yours, yes. But then you are
also the first in six years that the unshare backend existed to have come
across that problem.  :)

> > Your second patch is described as "Do not extract anything in /dev" but
> > what it actually excludes is the directory itself and not just everything
> > in it.
> That's why I said "untested" :-) The point was to convey the idea, not the
> implementation.

Unfortunately the idea cannot work. Because the point of the exclude patterns
is to exclude everything that is a character special file. The point is not to
exclude everything in /dev.

> > Maybe a better solution would be to pipe the tarballs through mmtarfilter
> > and just remove all the device nodes from them. This avoids requiring any
> > --exclude options for tar.
> 
> Hmm, but if we get to such point, maybe we should really advocate for
> debootstrap and friends to stop including any /dev/* files at all.

I'd be very much in favour of doing that. With mmdebstrap you can create a
chroot without device nodes by running this:

mmdebstrap --variant=buildd --skip=output/mknod unstable 
~/.cache/sbuild/unstable-arm64.tar

The reason they are created in debootstrap (I think) is so that you can easily
just chroot into them without having to think of bind-mounting /dev beforehand.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1063140: mpg123: NMU diff for 64-bit time_t transition

[Thomas Orgis]

Am Thu, 4 Apr 2024 09:36:37 +0200
schrieb Sebastian Ramacher : 

> Now I get the following on arm{hf,el}:
> 
> --- debian/libmpg123-0.symbols (libmpg123-0_1.32.6~dev+20240403022201-1_armhf)
> +++ dpkg-gensymbolspYII3c 2024-04-03 09:52:12.863133592 +
> @@ -8,8 +8,8 @@
>   mpg123_current_decoder@Base 1.7.2
>   mpg123_decode@Base 1.6.2
>   mpg123_decode_frame64@Base 1.32.3
> - mpg123_decode_frame@Base 1.6.2
> - (arch-bits=32|arch=!x32)mpg123_decode_frame_32@Base 1.13.7
> +#MISSING: 1.32.6~dev+20240403022201-1# mpg123_decode_frame@Base 1.6.2
> +#MISSING: 1.32.6~dev+20240403022201-1# 
> (arch-bits=32|arch=!x32)mpg123_decode_frame_32@Base 1.13.7
 
> From your explanation above, this is what I expected. The builds on 64
> bit architectures and i386 are unaffected.

Thanks for confirming.

> If you feel strongly about this, I think the best option would be to
> bump SONAME of the libraries upstream … 

I only feel that the subtle breakage with changed behaviour of the
still-existing symbol is to be avoided. My change for 1.32.6 does this.
The remaining symbols are still compatible with the pre-existing ABI
and upstream nothing changed, so an SONAME change from my side is not
really warranted.

This is a specific build configuration that Debian chooses. There are a
number of other options where you can disable library features and make
symbols disappear. So not that much changed from before, from the
upstream POV.

Unless you plan to add some SONAME change to all libraries affected by
the time_t/off_t change, I don't see why mpg123 libs should be singled
out. If this is just done by package name/version suffixes, then so be
it.

I'll release 1.32.6 now to enable a smoother transition.


Alrighty then,

Thomas

Bug#1067630: Fix arbitrary Lisp execution vulnerability (CVE-2024-30202)

[Benjamin Moody]

Dear maintainers:

This bug report refers to a couple of distinct issues:

1. Evaluating arbitrary Lisp code when a file is opened.

2. Evaluating arbitrary LaTeX code in various circumstances.

While the second issue is important to consider, I'd like to
focus on the first part.  This is a grave security issue
affecting Debian stable, and the fix is simple.


To check whether or not you have a vulnerable version of
org-mode, create a file called "foo.org" containing the following
text:

#+MACRO: x (eval (syntax-propertize-rules ((insert (upcase "vulnerable\n")

Then open foo.org in Emacs.  If the word "VULNERABLE" appears,
you are using a vulnerable version.


Below is the patch from Emacs 29.3 that fixes this bug.  It
applies cleanly against the version in bookworm (1:28.2+1-15):

diff --git a/lisp/org/org-macro.el b/lisp/org/org-macro.el
index 776d162..0be51ee 100644
--- a/lisp/org/org-macro.el
+++ b/lisp/org/org-macro.el
@@ -109,6 +109,13 @@ previous one, unless VALUE is nil.  Return the updated 
list."
   (let ((new-templates nil))
 (pcase-dolist (`(,name . ,value) templates)
   (let ((old-definition (assoc name new-templates)))
+;; This code can be evaluated unconditionally, as a part of
+;; loading Org mode.  We *must not* evaluate any code present
+;; inside the Org buffer while loading.  Org buffers may come
+;; from various sources, like received email messages from
+;; potentially malicious senders.  Org mode might be used to
+;; preview such messages and no code evaluation from inside the
+;; received Org text should ever happen without user consent.
 (when (and (stringp value) (string-match-p "\\`(eval\\>" value))
   ;; Pre-process the evaluation form for faster macro expansion.
   (let* ((args (org-macro--makeargs value))
@@ -121,7 +128,7 @@ previous one, unless VALUE is nil.  Return the updated 
list."
  (cadr (read value))
(error
  (user-error "Invalid definition for macro %S" name)
-   (setq value (eval (macroexpand-all `(lambda ,args ,body)) t
+   (setq value `(lambda ,args ,body
 (cond ((and value old-definition) (setcdr old-definition value))
  (old-definition)
  (t (push (cons name (or value "")) new-templates)

Source: 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=befa9fcaae29a6c9a283ba371c3c5234c7f644eb

Please add this patch to the Emacs source package, and make a
security update, as soon as possible.

Bug#1068407: xfce4-terminal: processes sleep after a while when switching to a different workspace

[Julian Gilbey]

Package: xfce4-terminal
Version: 1.1.1-1
Severity: normal

This is a weird bug, and I have no idea how to locate the source.  I'm
running in an Xfce4 environment (xfce4-session, xfce4-panel,
xfce4-screensaver, xfce4-terminal and various other applications such
as firefox) on a Debian testing machine.  I have four workspaces on my
desktop.  If I start a long-running process in a terminal, for example
an sbuild, it runs absolutely fine.  But if I switch to a different
workspace, it seems that the process just freezes - when I return to
the workspace some time later, it continues from where it was.  This
makes it impossible to reliably have long-running jobs in a terminal.

This behaviour started relatively recently (probably within the last
month or so).  I've tried upgrading xfce4-terminal to 1.1.3-1 (rebuilt
for debian/testing), but while it seemed to work better for a little
while, it soon started doing the same thing.

Do you have any idea what might be causing this?  It might not be due
to xfce4-terminal itself, of course.

Thanks!

   Julian

Bug#1068341: bioawk: FTBFS randomly due to Makefile bug: cp: cannot create regular file 'ytab.c': File exists

[Santiago Vila]

Nilesh: Would it help if I do a "team upload" to fix this?
(Using the proposed patch)

Or would you prefer to fix it yourself?


Just go ahead with a fix. I don't have much time these days. Please also drop 
me from uploaders field for this package won't have time to maintain this.


Yes, I noticed, as there was already a commit in git about that.

I've made the commits in salsa and the upload.

Thanks a lot.

Bug#1064971: Can the fix be done for oldstable debian?

[Dick Hollenbeck]

I am using debian oldstable, how can I use this fix there?

Bug#1068387: ncl: FTBFS with HDF 4.3.0.

[Sebastiaan Couwenberg]

Control: tags -1 patch

On 4/4/24 6:22 PM, Sebastiaan Couwenberg wrote:

The FTBFS with HDF 4.3.0 is not fixed in 6.6.2.dfsg.1-5.


You need the attached patch to fix the error with HDF 4.3.0 by including 
df.h instead of dfi.h.


The package then still FTBFS but due to dh_install:

   dh_install
dh_install: warning: Cannot find (any matches for) "usr/bin/ctrans" 
(tried in ., debian/tmp)


dh_install: warning: ncl-ncarg missing files: usr/bin/ctrans
dh_install: warning: Cannot find (any matches for) "usr/bin/ras2ccir601" 
(tried in ., debian/tmp)


dh_install: warning: ncl-ncarg missing files: usr/bin/ras2ccir601
dh_install: warning: Cannot find (any matches for) "usr/bin/rascat" 
(tried in ., debian/tmp)


dh_install: warning: ncl-ncarg missing files: usr/bin/rascat
dh_install: warning: Cannot find (any matches for) "usr/bin/rasgetpal" 
(tried in ., debian/tmp)


dh_install: warning: ncl-ncarg missing files: usr/bin/rasgetpal
dh_install: warning: Cannot find (any matches for) "usr/bin/rasls" 
(tried in ., debian/tmp)


dh_install: warning: ncl-ncarg missing files: usr/bin/rasls
dh_install: warning: Cannot find (any matches for) "usr/bin/rasstat" 
(tried in ., debian/tmp)


dh_install: warning: ncl-ncarg missing files: usr/bin/rasstat
dh_install: warning: Cannot find (any matches for) "usr/bin/rasview" 
(tried in ., debian/tmp)


dh_install: warning: ncl-ncarg missing files: usr/bin/rasview
dh_install: warning: Cannot find (any matches for) "usr/bin/rassplit" 
(tried in ., debian/tmp)


dh_install: warning: ncl-ncarg missing files: usr/bin/rassplit
install -m0755 -d debian/ncl-ncarg//usr/bin
cp --reflink=auto -a debian/tmp/usr/bin/ConvertMapData 
debian/tmp/usr/bin/cgm2ncgm debian/tmp/usr/bin/ctlib 
debian/ncl-ncarg//usr/bin/
dh_install: warning: Cannot find (any matches for) "lib/libncarg_ras.a" 
(tried in ., debian/tmp)


dh_install: warning: libncarg-dev missing files: lib/libncarg_ras.a
dh_install: error: missing files, aborting

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
Description: Fix FTBFS with HDF 4.3.0.
Author: Bas Couwenberg 
Bug-Debian: https://bugs.debian.org/1068387

--- a/ni/src/ncl/FileSupport.c
+++ b/ni/src/ncl/FileSupport.c
@@ -39,7 +39,7 @@ shortNCLuseAFS;
 #include 
 
 #ifdef BuildHDF4
-#include 
+#include 
 #include 
 #ifdef BuildHDFEOS
 #include 

Bug#1068406: todo.txt-gtd: please drop extraneous dependency on python3-mock

[Alexandre Detiste]

Source: todo.txt-gtd
Version: 0.9
Severity: normal

Dear Maintainer,

This obsolete library is slowly being removed from Debian.
Upstream projects are moving to unittest.mock
from the standard library.

This one project doesn't need "mock" at all.

Greetings


$ grep mock -r
debian/control:   python3-mock,
$

Bug#1068345: trixie-pu: package chromium/123.0.6312.105-1~deb13u1

[Andres Salomon]

On 4/4/24 07:31, Paul Gevers wrote:

Hi Andres,

On 04-04-2024 9:56 a.m., Paul Gevers wrote:
I have $(reschedule --days=0)-ed your upload to DELAYED. I'll do a 
final check when that lands before unblocking.


The upload seems to be not a pure changelog only change. The tpu upload 
has a debian/patches/system/ffmpeg.patch that's not in unstable. Was 
that a mistake or care to elaborate?


Paul



I think that's backwards - the tpu upload (as well as my 
bookworm-security uploads) lacks the ffmpeg.patch that's in the unstable 
uploads, because they're built from clean git clones.


The sid upload has the ffmpeg.patch by mistake. It's not in git (anymore 
- 
https://salsa.debian.org/chromium-team/chromium/-/commit/510d9a6ed4586737bc20284fafab402ec682ed5e 
), and I need to delete it from the sid uploads. Recently I started 
testing to see if, now that we're not building chromium for bullseye 
anymore, I could reasonably start building against the system ffmpeg 
again. I never finished testing, and that patch got left in.


OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058552: [Pkg-javascript-devel] Bug#1058552: science.js: FTBFS: SyntaxError: Error parsing /<>/package.json: Unexpected end of JSON input

[Jonas Smedegaard]

Quoting James Valleroy (2024-04-04 16:13:07)
> On 3/28/24 4:08 AM, Petter Reinholdtsen wrote:
> > [James Valleroy 2024-02-12]
> >> Here is a patch that fixes the build:
> > 
> > Thank you.  Can you explain why changing the output from package.json to
> > mktemp and then moving the result to package.json will solve the build
> > problem?  I fail to understand how this could change anything.
> 
> The makefile receipe uses node to produce the content that will be 
> written to package.json. It seems that node is also trying to read in 
> and parse the contents of package.json. Apparently, writing the file is 
> not an atomic operation, so node is reading it before the write 
> operation has completed. So it reads some partially-written package.json 
> file, which is not yet valid JSON, and produces an error when trying to 
> parse it.
> 
> I don't know enough about node to say why it does this (reading in 
> package.json after it has started running the src/package.js script).
> 
> > Btw, did you mean TEMPFILE=$(shell mktemp) to get a random temp file
> > name?
> > 
> 
> I'm not sure. It may also work, but there is a difference in when a 
> shell command runs. Some people recommend not to use shell in a 
> makefile: https://stackoverflow.com/a/76121578

Each make target (i.e. each line indended by a tab) is executed within a
shell.  The point in the SO answer you reference is that calling the
make function $(shell ...) *inside* a make target effectively spawns a
shell within another shell, and *that* you rarely really want.

What Petter is talking about above is that "TEMPFILE=mktemp", because it
is a make target (i.e. on a TAB-indented line) is passed to a shell,
which will *not* set TEMPFILE to the output of the shell command mktemp,
but simply set TEMPFILE to the _string_ "mktemp" which is unlikely that
you want.


 - 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#1068405: ofxstatement-plugins: please drop dependency on python3-six

[Alexandre Detiste]

Source: ofxstatement-plugins
Version: 20210310+nmu1
Severity: normal

Dear,

This obsolete library is slowly being removed from Debian.
Upstream projects are moving to unittest.mock
from the standard library.

This one project doesn't need "mock" at all.

Greetings 


$ grep mock -r
debian/control:   python3-mock,
$

Bug#1065980: gfarm: FTBFS on arm{el,hf}:

[Peter Green]

tags 1065980 +patch
thanks

This build failure was caused by missing "feature test macros" meaning that
the relevant functions were not enabled in the system headers.

A debdiff adding them is attached.diff -Nru gfarm-2.7.20+dfsg/debian/changelog gfarm-2.7.20+dfsg/debian/changelog
--- gfarm-2.7.20+dfsg/debian/changelog  2024-02-28 17:35:22.0 +
+++ gfarm-2.7.20+dfsg/debian/changelog  2024-04-04 04:41:24.0 +
@@ -1,3 +1,11 @@
+gfarm (2.7.20+dfsg-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add include of unistd.h to lib/libgfarm/gfarm/gfp_xdr.c to fix
+implicit declaration error.
+
+ -- Peter Michael Green   Thu, 04 Apr 2024 04:41:24 +
+
 gfarm (2.7.20+dfsg-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gfarm-2.7.20+dfsg/debian/patches/missing-feature-test-macros.patch 
gfarm-2.7.20+dfsg/debian/patches/missing-feature-test-macros.patch
--- gfarm-2.7.20+dfsg/debian/patches/missing-feature-test-macros.patch  
1970-01-01 00:00:00.0 +
+++ gfarm-2.7.20+dfsg/debian/patches/missing-feature-test-macros.patch  
2024-04-04 04:41:24.0 +
@@ -0,0 +1,173 @@
+Index: gfarm-2.7.20+dfsg/lib/libgfarm/gfarm/gfp_xdr.c
+===
+--- gfarm-2.7.20+dfsg.orig/lib/libgfarm/gfarm/gfp_xdr.c
 gfarm-2.7.20+dfsg/lib/libgfarm/gfarm/gfp_xdr.c
+@@ -1,3 +1,4 @@
++#define _XOPEN_SOURCE 500
+ #include 
+ #include 
+ #include 
+Index: 
gfarm-2.7.20+dfsg/bench/gfperf/gfperf-autoreplica/gfperf-autoreplica-main.c
+===
+--- 
gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-autoreplica/gfperf-autoreplica-main.c
 gfarm-2.7.20+dfsg/bench/gfperf/gfperf-autoreplica/gfperf-autoreplica-main.c
+@@ -2,6 +2,7 @@
+  * $Id$
+  */
+ 
++#define _GNU_SOURCE
+ #include "gfperf-lib.h"
+ #include 
+ #include 
+Index: gfarm-2.7.20+dfsg/bench/gfperf/gfperf-copy/gfperf-copy-gfarm2fs.c
+===
+--- gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-copy/gfperf-copy-gfarm2fs.c
 gfarm-2.7.20+dfsg/bench/gfperf/gfperf-copy/gfperf-copy-gfarm2fs.c
+@@ -2,7 +2,7 @@
+  * $Id$
+  */
+ 
+-
++#define _GNU_SOURCE
+ #include 
+ #include 
+ #include 
+Index: gfarm-2.7.20+dfsg/bench/gfperf/gfperf-copy/gfperf-copy-main.c
+===
+--- gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-copy/gfperf-copy-main.c
 gfarm-2.7.20+dfsg/bench/gfperf/gfperf-copy/gfperf-copy-main.c
+@@ -2,7 +2,7 @@
+  * $Id$
+  */
+ 
+-
++#define _GNU_SOURCE
+ #include "gfperf-lib.h"
+ #include 
+ #include 
+Index: gfarm-2.7.20+dfsg/bench/gfperf/gfperf-lib/gfperf-util.c
+===
+--- gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-lib/gfperf-util.c
 gfarm-2.7.20+dfsg/bench/gfperf/gfperf-lib/gfperf-util.c
+@@ -2,7 +2,8 @@
+  * $Id$
+  */
+ 
+-
++#define _DEFAULT_SOURCE
++#define _XOPEN_SOURCE 500
+ #include 
+ #include 
+ #include 
+Index: gfarm-2.7.20+dfsg/bench/gfperf/gfperf-metadata/gfperf-metadata-main.c
+===
+--- gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-metadata/gfperf-metadata-main.c
 gfarm-2.7.20+dfsg/bench/gfperf/gfperf-metadata/gfperf-metadata-main.c
+@@ -2,7 +2,7 @@
+  * $Id$
+  */
+ 
+-
++#define _GNU_SOURCE
+ #include "gfperf-lib.h"
+ #include 
+ #include 
+Index: 
gfarm-2.7.20+dfsg/bench/gfperf/gfperf-parallel-read/gfperf-parallel-read-main.c
+===
+--- 
gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-parallel-read/gfperf-parallel-read-main.c
 
gfarm-2.7.20+dfsg/bench/gfperf/gfperf-parallel-read/gfperf-parallel-read-main.c
+@@ -3,6 +3,7 @@
+  */
+ 
+ 
++#define _GNU_SOURCE
+ #include "gfperf-lib.h"
+ #include 
+ #include 
+Index: 
gfarm-2.7.20+dfsg/bench/gfperf/gfperf-parallel-write/gfperf-parallel-write-main.c
+===
+--- 
gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-parallel-write/gfperf-parallel-write-main.c
 
gfarm-2.7.20+dfsg/bench/gfperf/gfperf-parallel-write/gfperf-parallel-write-main.c
+@@ -3,6 +3,7 @@
+  */
+ 
+ 
++#define _GNU_SOURCE
+ #include "gfperf-lib.h"
+ #include 
+ #include 
+Index: gfarm-2.7.20+dfsg/bench/gfperf/gfperf-read/gfperf-read-main.c
+===
+--- gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-read/gfperf-read-main.c
 gfarm-2.7.20+dfsg/bench/gfperf/gfperf-read/gfperf-read-main.c
+@@ -2,7 +2,7 @@
+  * $Id$
+  */
+ 
+-
++#define _GNU_SOURCE
+ #include "gfperf-lib.h"
+ #include 
+ #include 
+Index: gfarm-2.7.20+dfsg/bench/gfperf/gfperf-replica/gfperf-replica-main.c
+===
+--- gfarm-2.7.20+dfsg.orig/bench/gfperf/gfperf-replica/gfperf-replica-main.c
 

Bug#1068404: mariadb-plugin-s3 dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: mariadb-plugin-s3
Version: 1:10.11.7-3
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, mariadb-plugin-s3
depends on both libcurl4 and libcurl4t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Bug#1068403: mariadb-plugin-hashicorp-key-management dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: mariadb-plugin-hashicorp-key-management
Version: 1:10.11.7-3
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, 
mariadb-plugin-hashicorp-key-management
depends on both libcurl4 and libcurl4t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Bug#1068341: bioawk: FTBFS randomly due to Makefile bug: cp: cannot create regular file 'ytab.c': File exists

[Nilesh Patra]

On 4 April 2024 2:28:07 am IST, Santiago Vila  wrote:
>Hi. I've just realized that (as a member of Debian Med)
>I could fix this myself.
>
>Nilesh: Would it help if I do a "team upload" to fix this?
>(Using the proposed patch)
>
>Or would you prefer to fix it yourself?

Just go ahead with a fix. I don't have much time these days. Please also drop 
me from uploaders field for this package won't have time to maintain this.

>Thanks.

Thank you very much for helping out!

Bug#1068387: ncl: FTBFS with HDF 4.3.0.

[Sebastiaan Couwenberg]

reopen 1068387
thanks

The FTBFS with HDF 4.3.0 is not fixed in 6.6.2.dfsg.1-5.

On 4/4/24 1:53 PM, Bas Couwenberg wrote:

Your package FTBFS while performing test rebuilds with HDF 4.3.20.

The attached debdiff contains changes to fix FTBFS issues unrelated to HDF 
4.3.20.


This patch was included in 6.6.2.dfsg.1-5.


Once those are applied, the package fails to build because it includes dfi.h.

  FileSupport.c:42:10: fatal error: dfi.h: No such file or directory
 42 | #include 
|  ^~~

The private headers are no longer included, see:

  https://github.com/HDFGroup/hdf4/blob/hdf4.3.0/doc/HDF-4.2-to-4.3-migration.md


This issue is still present in 6.6.2.dfsg.1-5.

"
   [ Bas Couwenberg ]
   * Rebuild with HDF 4.3.0. Closes: #1068387
"

This changelog entry from the debdiff should not have been included in 
the upload, it is wrong because HDF 4.3.0 is only in experimental at the 
moment.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1068402: lua-lxc dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: lua-lxc
Version: 1:3.0.2-2
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, lua-lxc
depends on both liblxc1 and libliblxc1t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Bug#1068401: ltrsift dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: ltrsift
Version: 1.0.2-9
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, ltrsift
depends on both libgenometools0 and libgenometools0t64. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu seem to have already fixed this.

https://launchpadlibrarian.net/720967127/ltrsift_1.0.2-9build5_1.0.2-9ubuntu1.diff.gz

Bug#1066763: liferea: FTBFS: dh_auto_test: error: make -j8 test "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Paul Gevers]

control: notfound -1 1.15.4-1

On 04-04-2024 5:42 p.m., Paul Gevers wrote:

I've scheduled retries on the reproducible build infrastructure.


amd64 and i386 both build fine (while on amd64 there was the same 
failure in the past as in this bug report).


So, marking the bug as not affecting the version in testing to avoid 
autoremoval.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068400: lomiri-filemanager-app dependencies unsatisfiable on 32-bit non-i386 architectures.

[Peter Green]

Package: lomiri-filemanager-app
Version: 1.0.4+dfsg-1
Severity: grave
User: debian-...@lists.debian.org
Usertag: time-t

After being rebuilt for the time64 transition, lomiri-filemanager-app
depends on both libsmbclient and libsmbclient0. As a
result it is uninstallable on architectures that are undergoing
the time64 transition (armel, armhf and some debian-ports
architectures).

Ubuntu seem to have already fixed this.

https://launchpadlibrarian.net/721510452/lomiri-filemanager-app_1.0.4+dfsg-1_1.0.4+dfsg-1ubuntu2.diff.gz

Bug#1068399: lomiri-system-settings - uninstallable on armel, armhf and mips64el due to depends/build-depends cycles.

[Peter Green]

Package: lomiri-system-settings
Version: 1.1.0-2
Severity: grave

lomiri-system-settings depends on lomiri-system-settings-security-privacy, which
is not availble on armel, armhf or mips64el.

The reason, or at least one reason, it is not available is because
lomiri-system-settings-security-privacy build-depends on lomiri-system-settings.

Bug#1066763: liferea: FTBFS: dh_auto_test: error: make -j8 test "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Paul Gevers]

Hi,

On Fri, 15 Mar 2024 22:42:34 +0100 Paul Gevers  wrote:

The problem is somewhere in liblzma.


In hind-sight, this is all to likely that it's caused by CVE-2024-3094, 
the xz backdoor.


I've scheduled retries on the reproducible build infrastructure. As the 
version in unstable is stuck in the time_t transition, I ping the bug 
(before closing unversioned if rebuilds in trixie proof the problem is 
gone) to reset the autoremoval timer.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature