Bug#1070163: socat: support duplicating data to multiple clients of listening socket?

[Paul Wise]

Package: socat
Severity: wishlist
X-Debbugs-Cc: so...@dest-unreach.org
Forwarded: so...@dest-unreach.org

socat does not appear to have a way to send data to multiple clients of
a listening socket, which would be useful to proxy data from overloaded
servers to multiple local clients.

For example:

   socat TCP-CONNECT:1.2.3.4:1234 UNIX-LISTEN:sock,unlink-early=1 &
   socat UNIX-CONNECT:out STDOUT &
   socat UNIX-CONNECT:out STDOUT &

The second client is not allowed to connect to the socket:

   2024/05/01 13:12:32 socat[957352] E connect(, AF=1 "out", 5): Connection 
refused

This can be achieved, by using this nmap ncat command:

   ncat --listen --unixsock out --keep-open --send-only

This appears to work by reading some data, then writing it
to all the client sockets, then repeating the process.

Unfortunately ncat breaks when one of the clients terminates,
so ncat currently does not appear to be useful for this yet.

   Ncat: Program bug: fd (4) not on list. QUITTING.

PS: some places on the web where people are looking for this feature,
for both local Unix domain stream sockets and local TCP ports:

https://serverfault.com/questions/747980/simpliest-unix-non-blocking-broadcast-socket
https://unix.stackexchange.com/questions/195880/socat-duplicate-stdin-to-each-connected-client
https://stackoverflow.com/questions/17480967/using-socat-to-multiplex-incoming-tcp-connection
https://gist.github.com/mathieue/3505472

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1070150: texlive-latex-extra: performance regression under emulation with 2023.20240207-1

[Norbert Preining]

> When running the hook with the 2023.20240207, this step takes around 3 hours.

Ouch, that hurts.

> I'm guessing that this is related to enabling lua on aarch64 finally, but I'm
> not familiar at all with latex and how to get the smallest possible test case 
> to
> show the issue.

If you suspect lua, then could you please run (as root or via sudo)
time fmtutil-sys --byengine luatex
time fmtutil-sys --byengine luajittex
and let us see the times there?

> A way to reproduce the issue would be to install debootstrap, qemu-user-static
> and systemd-nspawn and then run apt-get install texlive-latex-extra

Sorry, no Debian system around anymore.

> On an arm64 host (VM on an original M1 Macbook Air), this is fine

Nor that.

> sudo debootstrap --arch arm64 sid sid
> sudo systemd-nspawn -D sid
> time apt-get install texlive-latex-extra -y
> 
> real 181m11.687s
> user 181m43.534s
> sys  1m5.422s
> 
> texlive-latex-recommended: 2023.20240207-1

Can you show the *actual* output?

And, maybe install moreutils and run it through ts

apt-get install texlive-latex-extra -y | ts 

That would give a hint which part is taking so much time.

Best regards

Norbert

--
PREINING Norbert  https://www.preining.info
arXiv / Cornell University   +   IFMGA Guide   +   TU Wien  +  TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#1070146: aria2: The -o option could offer a substitution pattern for the original basename

[Kartik Mistry]

forwarded 1070146 https://github.com/aria2/aria2/issues/2207
thanks

-- 
Kartik Mistry | કાર્તિક મિસ્ત્રી
kartikm.wordpress.com

Bug#1069997: nginx: NGX_MODULE_SIGNATURE has changed on 32-bit t64 architectures, but the ${nginx:abi} substvar has not

[Jan Mojzis]

Thanks for the report,
I am preparing nginx release 1.26.0, and the updated ABI version will be part 
of it.

Jan

Bug#1069549: racket: FTBFS on armel: dh_install: error: missing files, aborting

[Lucas Nussbaum]

Hi David,

On 29/04/24 at 07:25 -0600, David Bremner wrote:
> 
> Control: severity -1 important
> 
> > Source: racket
> > Version: 8.12+dfsg1-7
> > Severity: serious
> > Justification: FTBFS
> > Tags: trixie sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel
> 
> OK, I figured out why this doesn't show up on the buildd's: they don't
> build the arch all packages on armel. For many years, armel hasn't been
> able to build the documentation for racket, and it has been disabled
> there. After some informal consultation with the release team I'm
> downgrading this bug to non-RC. I'll work on having more clear
> diagnostics for the build failure.
> 
> I don't know how common this scenario is, but it might make sense to
> restrict such rebuilds to arch:any on armel (and armhf), depending on
> your goals of course.

Yeah, rebuilding arch:all in addition to arch:any was a mistake. I only
filed bugs for packages that also have arch:any on armel, but obviously
this wasn't enough to avoid all non-RC issues.

Downgrading is of course fine.

Lucas

Bug#1070162: Nickle man page has residual template variable

[Eric Bavier]

Package: nickle
Version: 2.97+b1
Severity: minor
Tags: patch, upstream

The man page "nickle(1)" contains a residual template variable that seems to
have missed its substitution:

$ man nickle | tail -n1
@RELEASE_DATE@NICKLE(1)
$ nickle -e version
"2.97"

It appears this might be the case at least as far back as version 2.91 in
debian "bookworm".

The problem appears to be in upstream.  Specifically, commit
74e92c3ff8b3b8478d44ee5e9b1f0fc75283fd88, which switched from `BUILD_DATE` in
configure.ac and nickle.1.in.  This commit failed to update the substitution
that is performed in Makefile.am.  The attached patch fixes this and also
inserts the package version into the page footer.  The patch is also included
inline here:


>From 95ff7e9de4ed815e060b1df59b5b2b105307e0d7 Mon Sep 17 00:00:00 2001
From: Eric Bavier 
Date: Mon, 29 Apr 2024 23:34:15 -0500
Subject: [PATCH] Fixes substitution of REALEASE_DATE in nickle.1

* Makefile.am (nickle.1): 'BUILD_DATE' -> 'RELEASE_DATE'.
* nickle.1.in: Include version in footer.
---
 Makefile.am | 2 +-
 nickle.1.in | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index ba28ec9..5ed56a3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -96,7 +96,7 @@ RELEASE_FILES = $(TARFILE) $(SIGFILE) $(SRPMFILE)
$(RPMFILE)
 
 nickle.1: nickle.1.in nickle-config.h
sed -e 's,@''VERSION@,$(VERSION),' \
-   -e 's,@''BUILD_DATE@,$(BUILD_DATE),' \
+   -e 's,@''RELEASE_DATE@,$(RELEASE_DATE),' \
-e 's,@''pkgdatadir@,$(pkgdatadir),' $(top_srcdir)/nickle.1.in >
$@

 nickle.spec: nickle.spec.in nickle-config.h
diff --git a/nickle.1.in b/nickle.1.in
index 4871ac2..1ab9e08 100644
--- a/nickle.1.in
+++ b/nickle.1.in
@@ -1,4 +1,4 @@
-.TH NICKLE 1 "@RELEASE_DATE@"
+.TH NICKLE 1 "@RELEASE_DATE@" "nickle @VERSION@"
 .SH NAME
 nickle \- a desk calculator language
 .SH SYNOPSIS
-- 
2.41.0


From 95ff7e9de4ed815e060b1df59b5b2b105307e0d7 Mon Sep 17 00:00:00 2001
From: Eric Bavier 
Date: Mon, 29 Apr 2024 23:34:15 -0500
Subject: [PATCH] Fixes substitution of REALEASE_DATE in nickle.1

* Makefile.am (nickle.1): 'BUILD_DATE' -> 'RELEASE_DATE'.
* nickle.1.in: Include version in footer.
---
 Makefile.am | 2 +-
 nickle.1.in | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index ba28ec9..5ed56a3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -96,7 +96,7 @@ RELEASE_FILES = $(TARFILE) $(SIGFILE) $(SRPMFILE) $(RPMFILE)
 
 nickle.1: nickle.1.in nickle-config.h
 	sed -e 's,@''VERSION@,$(VERSION),' \
-	-e 's,@''BUILD_DATE@,$(BUILD_DATE),' \
+	-e 's,@''RELEASE_DATE@,$(RELEASE_DATE),' \
 	-e 's,@''pkgdatadir@,$(pkgdatadir),' $(top_srcdir)/nickle.1.in > $@
 	
 nickle.spec: nickle.spec.in nickle-config.h
diff --git a/nickle.1.in b/nickle.1.in
index 4871ac2..1ab9e08 100644
--- a/nickle.1.in
+++ b/nickle.1.in
@@ -1,4 +1,4 @@
-.TH NICKLE 1 "@RELEASE_DATE@"
+.TH NICKLE 1 "@RELEASE_DATE@" "nickle @VERSION@"
 .SH NAME
 nickle \- a desk calculator language
 .SH SYNOPSIS
-- 
2.41.0

Bug#1070161: ITS: ramond

[Boyuan Yang]

Source: ramond
Version: 0.5-4.2
Severity: important
Tags: sid trixie
X-Debbugs-CC: nicolas.dandrim...@crans.org

Dear package ramond maintainer in Debian,

After looking into the package you maintain (ramond, 
https://tracker.debian.org/pkg/ramond), I found that this package
received no maintainer updates in the past 12 years and is not in good
shape. As a result, I am filing an ITS (Intent to Salvage) request
against your package to take over package maintenance according to
section 5.12 in Debian's Developers' Reference [1].

My current plan is to refresh packaging and fix all release-critical
bugs.

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
(May 21, 2024) to continue with the package salvaging. If you find it
necessary to pause the ITS process, please let me know immediately by
replying this bug report.


[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Best Regards,
Boyuan Yang


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

Bug#1070160: libfmt: Please allow merge requests on Salsa

[Otto Kekäläinen]

Package: libfmt
Severity: wishlist

Hi!

Please allow CI and Merge Requests at
https://salsa.debian.org/zhsj/fmtlib so that it is easier for others
to contribute to the package.

I would for example like to submit a Merge Request to include

https://salsa.debian.org/otto/fmtlib/-/commit/07463212495f74196b6380423476827802a7be36
https://salsa.debian.org/otto/fmtlib/-/pipelines/672003

..and some follow-up fixes.

Bug#1070158: bullseye-pu: package distro-info-data/0.51+deb11u6

[Stefano Rivera]

Package: release.debian.org
Severity: normal
Tags: bullseye
X-Debbugs-Cc: distro-info-d...@packages.debian.org
Control: affects -1 + src:distro-info-data
User: release.debian@packages.debian.org
Usertags: pu

This is a regular distro-info-data update.

[ Reason ]
This update adds:
1. bullseye and bookworm LTS & ELTS.
2. Ubuntu 24.10 Oracular Oriole

[ Impact ]
$ ubuntu-distro-info -d
ubuntu-distro-info: Distribution data outdated.
$ debian-distro-info --lts -f --date=2024-09-01
$

[ Tests ]
We have automated tests that check the basic CSV data structure.
Manually verified the affected Debian & Ubuntu releases.

[ Risks ]
Minimal, this is a data-only package, and there are no schema changes.

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

[ Changes ]
   * Update data to 0.61:
 - Declare LTS and ELTS intentions for bullseye and bookworm
 - debian: Fix LTS EOL date for bullseye
 - debian.csv: Fix EOL date for 2.2
 - Add Ubuntu 24.10 "Oracular Oriole" (LP: #2064136)
diff -Nru distro-info-data-0.51+deb11u5/debian/changelog 
distro-info-data-0.51+deb11u6/debian/changelog
--- distro-info-data-0.51+deb11u5/debian/changelog  2023-10-29 
08:57:15.0 -0400
+++ distro-info-data-0.51+deb11u6/debian/changelog  2024-04-30 
20:54:51.0 -0400
@@ -1,3 +1,13 @@
+distro-info-data (0.51+deb11u6) bullseye; urgency=medium
+
+  * Update data to 0.61:
+- Declare LTS and ELTS intentions for bullseye and bookworm
+- debian: Fix LTS EOL date for bullseye
+- debian.csv: Fix EOL date for 2.2
+- Add Ubuntu 24.10 "Oracular Oriole" (LP: #2064136)
+
+ -- Stefano Rivera   Tue, 30 Apr 2024 20:54:51 -0400
+
 distro-info-data (0.51+deb11u5) bullseye; urgency=medium
 
   * Update data to 0.59:
diff -Nru distro-info-data-0.51+deb11u5/debian.csv 
distro-info-data-0.51+deb11u6/debian.csv
--- distro-info-data-0.51+deb11u5/debian.csv2023-10-29 08:57:15.0 
-0400
+++ distro-info-data-0.51+deb11u6/debian.csv2024-04-30 20:54:51.0 
-0400
@@ -4,7 +4,7 @@
 1.3,Bo,bo,1996-12-12,1997-06-05,1999-03-09
 2.0,Hamm,hamm,1997-06-05,1998-07-24,2000-03-09
 2.1,Slink,slink,1998-07-24,1999-03-09,2000-10-30
-2.2,Potato,potato,1999-03-09,2000-08-15,2003-07-30
+2.2,Potato,potato,1999-03-09,2000-08-15,2003-06-30
 3.0,Woody,woody,2000-08-15,2002-07-19,2006-06-30
 3.1,Sarge,sarge,2002-07-19,2005-06-06,2008-03-31
 4.0,Etch,etch,2005-06-06,2007-04-08,2010-02-15
@@ -14,8 +14,8 @@
 8,Jessie,jessie,2013-05-04,2015-04-26,2018-06-17,2020-06-30,2025-06-30
 9,Stretch,stretch,2015-04-26,2017-06-17,2020-07-18,2022-06-30,2027-06-30
 10,Buster,buster,2017-06-17,2019-07-06,2022-09-10,2024-06-30,2029-06-30
-11,Bullseye,bullseye,2019-07-06,2021-08-14,2024-08-14
-12,Bookworm,bookworm,2021-08-14,2023-06-10,2026-06-10
+11,Bullseye,bullseye,2019-07-06,2021-08-14,2024-08-14,2026-08-31,2031-06-30
+12,Bookworm,bookworm,2021-08-14,2023-06-10,2026-06-10,2028-06-30,2033-06-30
 13,Trixie,trixie,2023-06-10
 14,Forky,forky,2025-08-01
 ,Sid,sid,1993-08-16
diff -Nru distro-info-data-0.51+deb11u5/ubuntu.csv 
distro-info-data-0.51+deb11u6/ubuntu.csv
--- distro-info-data-0.51+deb11u5/ubuntu.csv2023-10-29 08:57:15.0 
-0400
+++ distro-info-data-0.51+deb11u6/ubuntu.csv2024-04-30 20:54:51.0 
-0400
@@ -39,3 +39,4 @@
 23.04,Lunar Lobster,lunar,2022-10-20,2023-04-20,2024-01-25
 23.10,Mantic Minotaur,mantic,2023-04-20,2023-10-12,2024-07-11
 24.04 LTS,Noble 
Numbat,noble,2023-10-12,2024-04-25,2029-05-31,2029-05-31,2034-04-25
+24.10,Oracular Oriole,oracular,2024-04-25,2024-10-10,2025-07-10

Bug#1070157: bookworm-pu: package distro-info-data/0.58+deb12u2

[Stefano Rivera]

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

This is a regular distro-info-data update.

[ Reason ]
This update adds:
1. bullseye and bookworm LTS & ELTS.
2. Ubuntu 24.10 Oracular Oriole

[ Impact ]
$ ubuntu-distro-info -d
ubuntu-distro-info: Distribution data outdated.
$ debian-distro-info --lts -f --date=2024-09-01
$

[ Tests ]
We have automated tests that check the basic CSV data structure.
Manually verified the affected Debian & Ubuntu releases.

[ Risks ]
Minimal, this is a data-only package, and there are no schema changes.

[ 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 ]

  * Update data to 0.61:
- Declare LTS and ELTS intentions for bullseye and bookworm
- debian: Fix LTS EOL date for bullseye
- debian.csv: Fix EOL date for 2.2
- Add Ubuntu 24.10 "Oracular Oriole" (LP: #2064136)
diff -Nru distro-info-data-0.58+deb12u1/debian/changelog 
distro-info-data-0.58+deb12u2/debian/changelog
--- distro-info-data-0.58+deb12u1/debian/changelog  2023-10-29 
06:12:45.0 -0400
+++ distro-info-data-0.58+deb12u2/debian/changelog  2024-04-30 
20:41:56.0 -0400
@@ -1,3 +1,13 @@
+distro-info-data (0.58+deb12u2) bookworm; urgency=medium
+
+  * Update data to 0.61:
+- Declare LTS and ELTS intentions for bullseye and bookworm
+- debian: Fix LTS EOL date for bullseye
+- debian.csv: Fix EOL date for 2.2
+- Add Ubuntu 24.10 "Oracular Oriole" (LP: #2064136)
+
+ -- Stefano Rivera   Tue, 30 Apr 2024 20:41:56 -0400
+
 distro-info-data (0.58+deb12u1) bookworm; urgency=medium
 
   * Update data to 0.59:
diff -Nru distro-info-data-0.58+deb12u1/debian.csv 
distro-info-data-0.58+deb12u2/debian.csv
--- distro-info-data-0.58+deb12u1/debian.csv2023-10-29 06:12:45.0 
-0400
+++ distro-info-data-0.58+deb12u2/debian.csv2024-04-30 20:41:56.0 
-0400
@@ -4,7 +4,7 @@
 1.3,Bo,bo,1996-12-12,1997-06-05,1999-03-09
 2.0,Hamm,hamm,1997-06-05,1998-07-24,2000-03-09
 2.1,Slink,slink,1998-07-24,1999-03-09,2000-10-30
-2.2,Potato,potato,1999-03-09,2000-08-15,2003-07-30
+2.2,Potato,potato,1999-03-09,2000-08-15,2003-06-30
 3.0,Woody,woody,2000-08-15,2002-07-19,2006-06-30
 3.1,Sarge,sarge,2002-07-19,2005-06-06,2008-03-31
 4.0,Etch,etch,2005-06-06,2007-04-08,2010-02-15
@@ -14,8 +14,8 @@
 8,Jessie,jessie,2013-05-04,2015-04-26,2018-06-17,2020-06-30,2025-06-30
 9,Stretch,stretch,2015-04-26,2017-06-17,2020-07-18,2022-06-30,2027-06-30
 10,Buster,buster,2017-06-17,2019-07-06,2022-09-10,2024-06-30,2029-06-30
-11,Bullseye,bullseye,2019-07-06,2021-08-14,2024-08-14
-12,Bookworm,bookworm,2021-08-14,2023-06-10,2026-06-10
+11,Bullseye,bullseye,2019-07-06,2021-08-14,2024-08-14,2026-08-31,2031-06-30
+12,Bookworm,bookworm,2021-08-14,2023-06-10,2026-06-10,2028-06-30,2033-06-30
 13,Trixie,trixie,2023-06-10
 14,Forky,forky,2025-08-01
 ,Sid,sid,1993-08-16
diff -Nru distro-info-data-0.58+deb12u1/ubuntu.csv 
distro-info-data-0.58+deb12u2/ubuntu.csv
--- distro-info-data-0.58+deb12u1/ubuntu.csv2023-10-29 06:12:45.0 
-0400
+++ distro-info-data-0.58+deb12u2/ubuntu.csv2024-04-30 20:41:56.0 
-0400
@@ -39,3 +39,4 @@
 23.04,Lunar Lobster,lunar,2022-10-20,2023-04-20,2024-01-25
 23.10,Mantic Minotaur,mantic,2023-04-20,2023-10-12,2024-07-11
 24.04 LTS,Noble 
Numbat,noble,2023-10-12,2024-04-25,2029-05-31,2029-05-31,2034-04-25
+24.10,Oracular Oriole,oracular,2024-04-25,2024-10-10,2025-07-10

Bug#1070156: RM: gnome-video-arcade -- ROM; Abandoned upstream, uses oldlibs

[Jordi Mallach]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: gnome-video-arc...@packages.debian.org, jbi...@ubuntu.com
Control: affects -1 + src:gnome-video-arcade
User: ftp.debian@packages.debian.org
Usertags: remove

As suggested by Jeremy Bicha, g-v-a should be removed as it is now
abandoned upstream and uses libs like libsoup2 that the GNOME team is
trying to get rid of.

This removal will also close 1061696 and 1061694.

Thanks,
Jordi

Bug#999957: sniproxy: diff for NMU version 0.6.1+git20240321-0.1

[Boyuan Yang]

Control: tags -1 +patch +pending

Dear maintainer,

I've prepared an NMU for sniproxy (versioned as 0.6.1+git20240321-0.1)
and uploaded it to DELAYED/14. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru sniproxy-0.6.0/ChangeLog sniproxy-0.6.1+git20240321/ChangeLog
--- sniproxy-0.6.0/ChangeLog	2018-12-05 23:14:58.0 -0500
+++ sniproxy-0.6.1+git20240321/ChangeLog	2024-03-21 01:16:44.0 -0400
@@ -1,3 +1,9 @@
+2023-03-16  Dustin Lundquist 
+	0.6.1 Release
+
+	* Fix buffer overflow in address module
+	* Fix tests
+
 2018-12-05  Dustin Lundquist 
 	0.6.0 Release
 
diff -Nru sniproxy-0.6.0/configure.ac sniproxy-0.6.1+git20240321/configure.ac
--- sniproxy-0.6.0/configure.ac	2018-12-05 23:14:58.0 -0500
+++ sniproxy-0.6.1+git20240321/configure.ac	2024-03-21 01:16:44.0 -0400
@@ -1,83 +1,33 @@
 #   -*- Autoconf -*-
 # Process this file with autoconf to produce a configure script.
 
-AC_PREREQ([2.60])
-AC_INIT([sniproxy], [0.6.0])
-AC_CONFIG_SRCDIR([src/sniproxy.c])
-AC_CONFIG_MACRO_DIR([m4])
+AC_PREREQ([2.71])
+AC_INIT([sniproxy],[0.6.1])
 AM_INIT_AUTOMAKE([subdir-objects])
 AM_SILENT_RULES([yes])
-AC_GNU_SOURCE
+AC_USE_SYSTEM_EXTENSIONS
 
 # Checks for programs.
-AC_PROG_CC_C99
-# Required by automake < 1.14
+AC_PROG_CC
 AM_PROG_CC_C_O
 
 
 # Checks for libraries.
-PKG_CHECK_MODULES([LIBEV], [libev], HAVE_LIBEV=yes; AC_DEFINE(HAVE_LIBEV, 1),
-[AC_LIB_HAVE_LINKFLAGS(ev,, [#include ], [ev_run(0,0);])
- if test x$ac_cv_libev = xyes; then
-  AC_SUBST([LIBEV_LIBS], [$LIBEV])
- else
-  AC_MSG_ERROR([[***
-*** libev4 was not found.
-***]])
- fi
-])
-
-PKG_CHECK_MODULES([LIBPCRE], [libpcre], HAVE_LIBPCRE=yes; AC_DEFINE(HAVE_LIBPCRE, 1),
-[AC_LIB_HAVE_LINKFLAGS(pcre,, [#include ], [pcre_exec(0,0,0,0,0,0,0,0);])
- if test x$ac_cv_libpcre = xyes; then
-  AC_SUBST([LIBPCRE_LIBS], [$LIBPCRE])
- else
-  AC_MSG_ERROR([[***
-*** libpcre was not found.
-***]])
- fi
-])
+AC_CHECK_LIB([ev], [ev_run])
+AC_CHECK_LIB([pcre2-8], [pcre2_compile_8], [],
+	 [AC_CHECK_LIB([pcre], [pcre_exec])])
 
 AC_ARG_ENABLE([dns],
-  [AS_HELP_STRING([--disable-dns], [Disable DNS resolution])],
-  [dns="$withval"], [dns=yes])
+  [AS_HELP_STRING([--enable-dns], [Enable DNS resolution])])
 
-AM_CONDITIONAL([DNS_ENABLED], [test "x$dns" = "xyes"])
+AM_CONDITIONAL([DNS_ENABLED], [test "$enable_dns"])
 
-AS_IF([test "x$dns" = "xyes"],
- [PKG_CHECK_MODULES([LIBUDNS], [libudns], HAVE_LIBUDNS=yes; AC_DEFINE(HAVE_LIBUDNS, 1),
-  [AC_LIB_HAVE_LINKFLAGS(udns,, [#include ], [dns_init(0, 0);])
-   AS_IF([test x$ac_cv_libudns = xyes], [AC_SUBST([LIBUDNS_LIBS], [$LIBUDNS])])
-  ])
-])
+AS_IF([test "$enable_dns"],
+  [AC_CHECK_LIB([udns], [dns_init])])
 
 AC_ARG_ENABLE([rfc3339-timestamps],
   [AS_HELP_STRING([--enable-rfc3339-timestamps], [Enable RFC3339 timestamps])],
-  [rfc3339_timestamps=${enableval}], [rfc3339_timestamps=no])
-
-AS_IF([test "x$rfc3339_timestamps" = "xyes"],
-[AC_DEFINE([RFC3339_TIMESTAMP], 1, [RFC3339 timestamps enabled])])
-
-# Checks for header files.
-AC_CHECK_HEADERS([arpa/inet.h fcntl.h inttypes.h netdb.h netinet/in.h stddef.h stdint.h stdlib.h string.h strings.h sys/socket.h sys/time.h syslog.h unistd.h],,
-AC_MSG_ERROR([required header(s) not found]))
-
-# Checks for typedefs, structures, and compiler characteristics.
-AC_C_INLINE
-AC_TYPE_PID_T
-AC_TYPE_UID_T
-AC_TYPE_SIZE_T
-AC_TYPE_SSIZE_T
-AC_TYPE_UINT16_T
-AC_TYPE_UINT8_T
-
-# Checks for library functions.
-AC_FUNC_FORK
-AC_FUNC_MALLOC
-AC_FUNC_REALLOC
-AC_FUNC_STRTOD
-AC_CHECK_FUNCS([atexit daemon memset socket strcasecmp strchr strdup strerror strncasecmp strrchr strspn strtoul],,
-AC_MSG_ERROR([required functions(s) not found]))
+  [AC_DEFINE([RFC3339_TIMESTAMP], 1, [RFC3339 timestamps enabled])])
 
 AC_CHECK_FUNCS([accept4])
 
diff -Nru sniproxy-0.6.0/debian/changelog sniproxy-0.6.1+git20240321/debian/changelog
--- sniproxy-0.6.0/debian/changelog	2023-04-29 13:03:02.0 -0400
+++ sniproxy-0.6.1+git20240321/debian/changelog	2024-04-30 19:59:09.0 -0400
@@ -1,3 +1,20 @@
+sniproxy (0.6.1+git20240321-0.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * New upstream snapshot.
++ Add libpcre2 support.
+  * debian/: Bump to debhelper compat v13.
+  * debian/control: Use libpcre2. (Closes: #57)
+  * debian/control: Add placeholder ${misc:Pre-Depends}.
+  * debian/control: Drop obsolete dependency lsb-base.
+  * debian/control: Use pkgconf and Standards-Version 4.7.0.
+  * debian/gbp.conf: Relax requirement and allow different branch names.
+  * debian/patches: Dropped, merged upstream.
+  * debian/sniproxy.service: Force the program to run in foreground if
+launched by systemd service. (Closes: #1032295)
+
+ -- Boyuan Yang   Tue, 30 Apr 2024 19:59:09 -0400
+
 sniproxy (0.6.0-2.1) unstable; urgency=medium
 
   * Non-maintainer upload by the LTS Team.
diff -Nru sniproxy-0.6.0/debian/compat sniproxy-0.6.1+git20240321/debian/compat
--- 

Bug#1070152: chkrootkit: duplicate line from ifpromisc

[Vincent Lefevre]

On 2024-05-01 01:29:10 +0200, Vincent Lefevre wrote:
> For instance, /var/log/chkrootkit/log.expected contains
> 
> WARNING: Output from ifpromisc:
> lo: not promisc and no packet sniffer sockets
> : PACKET 
> SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
> 
> But /var/log/chkrootkit/log.today currently has a duplicate line:
> 
> WARNING: Output from ifpromisc:
> lo: not promisc and no packet sniffer sockets
> : PACKET 
> SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
> : PACKET 
> SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
> 
> which has the effect to generate an alert.

This is actually due to the filter in /etc/chkrootkit/chkrootkit.conf,
which obfuscates the output.

The unfiltered output:

lo: not promisc and no packet sniffer sockets
eth0: PACKET SNIFFER(/usr/sbin/NetworkManager[1261])
wlp0s20f3: PACKET SNIFFER(/usr/sbin/NetworkManager[1261], 
/usr/sbin/wpa_supplicant[1263])

But for a laptop, there is not always an Ethernet cable plugged in.

IMHO, known packet sniffers should be filtered out.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1070154: bullseye-pu: qtbase-opensource-src/5.15.2+dfsg-9+deb11u1

[Thorsten Alteholz]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu


The attached debdiff for qtbase-opensource-src fixes several CVEs in 
Bullseye. All CVEs are marked as no-dsa by the security team.


  Thorstendiff -Nru qtbase-opensource-src-5.15.2+dfsg/debian/changelog 
qtbase-opensource-src-5.15.2+dfsg/debian/changelog
--- qtbase-opensource-src-5.15.2+dfsg/debian/changelog  2021-07-02 
17:58:04.0 +0200
+++ qtbase-opensource-src-5.15.2+dfsg/debian/changelog  2024-04-28 
22:48:02.0 +0200
@@ -1,3 +1,33 @@
+qtbase-opensource-src (5.15.2+dfsg-9+deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload by the LTS Team.
+  * CVE-2024-25580 (Closes: #1064053)
+fix buffer overflow due to crafted KTX image file
+  * CVE-2023-32763 (Closes: #1036702)
+fix QTextLayout buffer overflow due to crafted SVG file
+  * CVE-2022-25255
+prevent QProcess from execution of a binary from the current working
+directory when not found in the PATH
+  * CVE-2023-24607 (Closes: #1031872)
+fix denial of service via a crafted string when the SQL ODBC driver
+plugin is used
+  * fix regression caused by patch for CVE-2023-24607
+  * CVE-2023-32762
+prevent incorrect parsing of the strict-transport-security (HSTS) header
+  * CVE-2023-51714 (Closes: #1060694)
+fix incorrect HPack integer overflow check.
+  * CVE-2023-38197 (Closes: #1041105)
+fix infinite loop in recursive entity expansion
+  * CVE-2023-37369 (Closes: #1059302)
+fix crash of application in QXmlStreamReader due to crafted XML string
+  * CVE-2023-34410 (Closes: #1037210)
+fix checking during TLS whether root of the chain really is a
+configured CA certificate
+  * CVE-2023-33285 (Closes: #1036848)
+fix buffer overflow in QDnsLookup
+
+ -- Thorsten Alteholz   Sun, 28 Apr 2024 22:48:02 +0200
+
 qtbase-opensource-src (5.15.2+dfsg-9) unstable; urgency=medium
 
   * Revert adding fix-misplacement-of-placeholder-text-in-QLineEdit.diff.
diff -Nru qtbase-opensource-src-5.15.2+dfsg/debian/patches/CVE-2022-25255.diff 
qtbase-opensource-src-5.15.2+dfsg/debian/patches/CVE-2022-25255.diff
--- qtbase-opensource-src-5.15.2+dfsg/debian/patches/CVE-2022-25255.diff
1970-01-01 01:00:00.0 +0100
+++ qtbase-opensource-src-5.15.2+dfsg/debian/patches/CVE-2022-25255.diff
2024-03-05 13:22:01.0 +0100
@@ -0,0 +1,96 @@
+Description: QProcess: ensure we don't accidentally execute something from CWD
+ Unless "." (or the empty string) is in $PATH, we're not supposed to find
+ executables in the current directory. This is how the Unix shells behave
+ and we match their behavior. It's also the behavior Qt had prior to 5.9
+ (commit 28666d167aa8e602c0bea25ebc4d51b55005db13). On Windows, searching
+ the current directory is the norm, so we keep that behavior.
+ .
+ This commit does not add an explicit check for an empty return from
+ QStandardPaths::findExecutable(). Instead, we allow that empty string to
+ go all the way to execve(2), which will fail with ENOENT. We could catch
+ it early, before fork(2), but why add code for the error case?
+ .
+ See https://kde.org/info/security/advisory-20220131-1.txt
+Origin: upstream, 
https://download.qt.io/official_releases/qt/5.15/CVE-2022-25255-qprocess5-15.diff
+Last-Update: 2022-02-21
+
+Index: qtbase-opensource-src-5.15.2+dfsg/src/corelib/io/qprocess_unix.cpp
+===
+--- qtbase-opensource-src-5.15.2+dfsg.orig/src/corelib/io/qprocess_unix.cpp
2024-03-05 13:21:06.432881985 +0100
 qtbase-opensource-src-5.15.2+dfsg/src/corelib/io/qprocess_unix.cpp 
2024-03-05 13:21:06.428881981 +0100
+@@ -1,7 +1,7 @@
+ /
+ **
+ ** Copyright (C) 2016 The Qt Company Ltd.
+-** Copyright (C) 2016 Intel Corporation.
++** Copyright (C) 2022 Intel Corporation.
+ ** Contact: https://www.qt.io/licensing/
+ **
+ ** This file is part of the QtCore module of the Qt Toolkit.
+@@ -422,14 +422,15 @@
+ // Add the program name to the argument list.
+ argv[0] = nullptr;
+ if (!program.contains(QLatin1Char('/'))) {
++// findExecutable() returns its argument if it's an absolute path,
++// otherwise it searches $PATH; returns empty if not found (we handle
++// that case much later)
+ const QString  = QStandardPaths::findExecutable(program);
+-if (!exeFilePath.isEmpty()) {
+-const QByteArray  = QFile::encodeName(exeFilePath);
+-argv[0] = ::strdup(tmp.constData());
+-}
+-}
+-if (!argv[0])
++const QByteArray  = QFile::encodeName(exeFilePath);
++argv[0] = ::strdup(tmp.constData());
++} else {
+ argv[0] = ::strdup(encodedProgramName.constData());
++}
+ 
+ // Add every argument to the list
+ for (int i = 0; i < arguments.count(); ++i)
+@@ -983,15 +984,16 @@
+ 

Bug#1070155: bullseye-pu: package wpa/2.9.0-21+deb11u1

[Bastien Roucariès]

Package: release.debian.org
Severity: important
Tags: bullseye
X-Debbugs-Cc: w...@packages.debian.org
Control: affects -1 + src:wpa
User: release.debian@packages.debian.org
Usertags: pu
tags: security


[ Reason ]
CVE-2023-52160 security bug

[ Impact ]
security bug is present

[ Tests ]
Test suite run fine

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

[ Changes ]
The previous PEAP client behavior allowed the server to skip Phase 2
authentication with the expectation that the server was authenticated
during Phase 1 through TLS server certificate validation. Various PEAP
specifications are not exactly clear on what the behavior on this front
is supposed to be and as such, this ended up being more flexible than
the TTLS/FAST/TEAP cases. However, this is not really ideal when
unfortunately common misconfiguration of PEAP is used in deployed
devices where the server trust root (ca_cert) is not configured or the
user has an easy option for allowing this validation step to be skipped.

Change the default PEAP client behavior to be to require Phase 2
authentication to be successfully completed for cases where TLS session
resumption is not used and the client certificate has not been
configured. Those two exceptions are the main cases where a deployed
authentication server might skip Phase 2 and as such, where a more
strict default behavior could result in undesired interoperability
issues. Requiring Phase 2 authentication will end up disabling TLS
session resumption automatically to avoid interoperability issues.

[ Other info ]
Buster is fixed so upgrade reintroduce the CVE

Bastiendiff -Nru wpa-2.9.0/debian/changelog wpa-2.9.0/debian/changelog
--- wpa-2.9.0/debian/changelog	2021-02-25 21:19:14.0 +
+++ wpa-2.9.0/debian/changelog	2024-04-30 22:45:18.0 +
@@ -1,3 +1,19 @@
+wpa (2:2.9.0-21+deb11u1) bullseye; urgency=high
+
+  * Non-maintainer upload on behalf of the Security Team.
+  * Fix CVE-2023-52160 (Closes: #1064061):
+The implementation of PEAP in wpa_supplicant allows
+authentication bypass. For a successful attack,
+wpa_supplicant must be configured to not verify
+the network's TLS certificate during Phase 1
+authentication, and an eap_peap_decrypt vulnerability
+can then be abused to skip Phase 2 authentication.
+The attack vector is sending an EAP-TLV Success packet
+instead of starting Phase 2. This allows an adversary
+to impersonate Enterprise Wi-Fi networks.
+
+ -- Bastien Roucari??s   Tue, 30 Apr 2024 22:45:18 +
+
 wpa (2:2.9.0-21) unstable; urgency=high
 
   * Fix typos in the package descriptions.
diff -Nru wpa-2.9.0/debian/patches/0033-CVE-2023-52160-PEAP-client-Update-Phase-2-authentica.patch wpa-2.9.0/debian/patches/0033-CVE-2023-52160-PEAP-client-Update-Phase-2-authentica.patch
--- wpa-2.9.0/debian/patches/0033-CVE-2023-52160-PEAP-client-Update-Phase-2-authentica.patch	1970-01-01 00:00:00.0 +
+++ wpa-2.9.0/debian/patches/0033-CVE-2023-52160-PEAP-client-Update-Phase-2-authentica.patch	2024-04-30 22:45:18.0 +
@@ -0,0 +1,211 @@
+From: Jouni Malinen 
+Date: Sat, 8 Jul 2023 19:55:32 +0300
+Subject: CVE-2023-52160 PEAP client: Update Phase 2 authentication
+ requirements
+
+The previous PEAP client behavior allowed the server to skip Phase 2
+authentication with the expectation that the server was authenticated
+during Phase 1 through TLS server certificate validation. Various PEAP
+specifications are not exactly clear on what the behavior on this front
+is supposed to be and as such, this ended up being more flexible than
+the TTLS/FAST/TEAP cases. However, this is not really ideal when
+unfortunately common misconfiguration of PEAP is used in deployed
+devices where the server trust root (ca_cert) is not configured or the
+user has an easy option for allowing this validation step to be skipped.
+
+Change the default PEAP client behavior to be to require Phase 2
+authentication to be successfully completed for cases where TLS session
+resumption is not used and the client certificate has not been
+configured. Those two exceptions are the main cases where a deployed
+authentication server might skip Phase 2 and as such, where a more
+strict default behavior could result in undesired interoperability
+issues. Requiring Phase 2 authentication will end up disabling TLS
+session resumption automatically to avoid interoperability issues.
+
+Allow Phase 2 authentication behavior to be configured with a new phase1
+configuration parameter option:
+'phase2_auth' option can be used to control Phase 2 (i.e., within TLS
+tunnel) behavior for PEAP:
+ * 0 = do not require Phase 2 authentication
+ * 1 = require Phase 2 authentication when client certificate
+   (private_key/client_cert) is no used and TLS session resumption was
+   not used 

Bug#1070153: bookworm-pu: qtbase-opensource-src/5.15.8+dfsg-11+deb12u2

[Thorsten Alteholz]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu


The attached debdiff for qtbase-opensource-src fixes several CVEs in 
Bookworm. All CVEs are marked as no-dsa by the security team.


The debdiff is based on version 5.15.8+dfsg-11+deb12u1, which is already 
in s-p-u.


  Thorstendiff -Nru qtbase-opensource-src-5.15.8+dfsg/debian/changelog 
qtbase-opensource-src-5.15.8+dfsg/debian/changelog
--- qtbase-opensource-src-5.15.8+dfsg/debian/changelog  2024-04-07 
11:45:51.0 +0200
+++ qtbase-opensource-src-5.15.8+dfsg/debian/changelog  2024-04-28 
20:48:02.0 +0200
@@ -1,3 +1,13 @@
+qtbase-opensource-src (5.15.8+dfsg-11+deb12u2) bookworm; urgency=medium
+
+  * Non-maintainer upload by the LTS Team.
+  * CVE-2024-25580 (Closes: #1064053)
+fix buffer overflow due to crafted KTX image file
+  * CVE-2023-51714 (Closes: #1060694)
+fix incorrect HPack integer overflow check.
+
+ -- Thorsten Alteholz   Sun, 28 Apr 2024 20:48:02 +0200
+
 qtbase-opensource-src (5.15.8+dfsg-11+deb12u1) bookworm; urgency=medium
 
   [ Alexander Volkov ]
diff -Nru qtbase-opensource-src-5.15.8+dfsg/debian/patches/CVE-2023-51714.diff 
qtbase-opensource-src-5.15.8+dfsg/debian/patches/CVE-2023-51714.diff
--- qtbase-opensource-src-5.15.8+dfsg/debian/patches/CVE-2023-51714.diff
1970-01-01 01:00:00.0 +0100
+++ qtbase-opensource-src-5.15.8+dfsg/debian/patches/CVE-2023-51714.diff
2024-04-28 20:48:02.0 +0200
@@ -0,0 +1,61 @@
+From 23c3fc483e8b6e21012a61f0bea884446f727776 Mon Sep 17 00:00:00 2001
+From: Marc Mutz 
+Date: Tue, 12 Dec 2023 22:08:07 +0100
+Subject: [PATCH] HPack: fix incorrect integer overflow check
+
+This code never worked:
+
+For the comparison with max() - 32 to trigger, on 32-bit platforms (or
+Qt 5) signed interger overflow would have had to happen in the
+addition of the two sizes. The compiler can therefore remove the
+overflow check as dead code.
+
+On Qt 6 and 64-bit platforms, the signed integer addition would be
+very unlikely to overflow, but the following truncation to uint32
+would yield the correct result only in a narrow 32-value window just
+below UINT_MAX, if even that.
+
+Fix by using the proper tool, qAddOverflow.
+
+Manual conflict resolutions:
+ - qAddOverflow doesn't exist in Qt 5, use private add_overflow
+   predecessor API instead
+
+Change-Id: I7599f2e75ff7f488077b0c60b81022591005661c
+Reviewed-by: Allan Sandfeld Jensen 
+(cherry picked from commit ee5da1f2eaf8932aeca02ffea6e4c618585e29e3)
+Reviewed-by: Qt Cherry-pick Bot 
+(cherry picked from commit debeb8878da2dc706ead04b6072ecbe7e5313860)
+Reviewed-by: Thiago Macieira 
+Reviewed-by: Marc Mutz 
+(cherry picked from commit 811b9eef6d08d929af8708adbf2a5effb0eb62d7)
+(cherry picked from commit f931facd077ce945f1e42eaa3bead208822d3e00)
+(cherry picked from commit 9ef4ca5ecfed771dab890856130e93ef5ceabef5)
+Reviewed-by: Mårten Nordheim 
+---
+
+Index: 
qtbase-opensource-src-5.15.8+dfsg/src/network/access/http2/hpacktable.cpp
+===
+--- 
qtbase-opensource-src-5.15.8+dfsg.orig/src/network/access/http2/hpacktable.cpp  
   2024-04-24 16:08:28.259865332 +0200
 qtbase-opensource-src-5.15.8+dfsg/src/network/access/http2/hpacktable.cpp  
2024-04-24 16:09:16.163853040 +0200
+@@ -40,6 +40,7 @@
+ #include "hpacktable_p.h"
+ 
+ #include 
++#include 
+ 
+ #include 
+ #include 
+@@ -62,8 +63,10 @@
+ // for counting the number of references to the name and value would have
+ // 32 octets of overhead."
+ 
+-const unsigned sum = unsigned(name.size() + value.size());
+-if (std::numeric_limits::max() - 32 < sum)
++size_t sum;
++if (add_overflow(size_t(name.size()), size_t(value.size()), ))
++return HeaderSize();
++if (sum > (std::numeric_limits::max() - 32))
+ return HeaderSize();
+ return HeaderSize(true, quint32(sum + 32));
+ }
diff -Nru qtbase-opensource-src-5.15.8+dfsg/debian/patches/CVE-2024-25580.diff 
qtbase-opensource-src-5.15.8+dfsg/debian/patches/CVE-2024-25580.diff
--- qtbase-opensource-src-5.15.8+dfsg/debian/patches/CVE-2024-25580.diff
1970-01-01 01:00:00.0 +0100
+++ qtbase-opensource-src-5.15.8+dfsg/debian/patches/CVE-2024-25580.diff
2024-04-28 20:48:02.0 +0200
@@ -0,0 +1,197 @@
+diff --git a/src/gui/util/qktxhandler.cpp b/src/gui/util/qktxhandler.cpp
+index 0d98e97453..6a79e55109 100644
+--- a/src/gui/util/qktxhandler.cpp
 b/src/gui/util/qktxhandler.cpp
+@@ -73,7 +73,7 @@ struct KTXHeader {
+ quint32 bytesOfKeyValueData;
+ };
+ 
+-static const quint32 headerSize = sizeof(KTXHeader);
++static constexpr quint32 qktxh_headerSize = sizeof(KTXHeader);
+ 
+ // Currently unused, declared for future reference
+ struct KTXKeyValuePairItem {
+@@ -103,11 +103,36 @@ struct KTXMipmapLevel {
+ */
+ };
+ 
+-bool QKtxHandler::canRead(const QByteArray , const QByteArray )
++static bool qAddOverflow(quint32 

Bug#1070152: chkrootkit: duplicate line from ifpromisc

[Vincent Lefevre]

Package: chkrootkit
Version: 0.58b-1+b2
Severity: normal

In the generated log, I sometimes get a duplicate line from ifpromisc.

For instance, /var/log/chkrootkit/log.expected contains

WARNING: Output from ifpromisc:
lo: not promisc and no packet sniffer sockets
: PACKET 
SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})

But /var/log/chkrootkit/log.today currently has a duplicate line:

WARNING: Output from ifpromisc:
lo: not promisc and no packet sniffer sockets
: PACKET 
SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})
: PACKET 
SNIFFER([systemd-networkd|dhclient|dhcpd|dhcpcd|wpa_supplicant|NetworkManager]{PID})

which has the effect to generate an alert.

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

Kernel: Linux 6.6.15-amd64 (SMP w/16 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 chkrootkit depends on:
ii  libc6  2.37-19

Versions of packages chkrootkit recommends:
ii  anacron 2.3-40
ii  binutils2.42-4
ii  cron [cron-daemon]  3.0pl1-189
ii  iproute26.8.0-1
ii  mailutils [mailx]   1:3.17-1.1+b2
ii  net-tools   2.10-1.1
ii  postfix [mail-transport-agent]  3.9.0-2
ii  procps  2:4.0.4-4
ii  systemd-sysv255.4-1+b1

chkrootkit suggests no packages.

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1070151: bookworm-pu: package wpa/2:2.10-12

[Bastien Roucariès]

Package: release.debian.org
Severity: important
Tags: bookworm
X-Debbugs-Cc: w...@packages.debian.org
Control: affects -1 + src:wpa
User: release.debian@packages.debian.org
Usertags: pu
tags: security


[ Reason ]
CVE-2023-52160 security bug

[ Impact ]
security bug is present

[ Tests ]
Test suite run fine

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

[ Changes ]
The previous PEAP client behavior allowed the server to skip Phase 2
authentication with the expectation that the server was authenticated
during Phase 1 through TLS server certificate validation. Various PEAP
specifications are not exactly clear on what the behavior on this front
is supposed to be and as such, this ended up being more flexible than
the TTLS/FAST/TEAP cases. However, this is not really ideal when
unfortunately common misconfiguration of PEAP is used in deployed
devices where the server trust root (ca_cert) is not configured or the
user has an easy option for allowing this validation step to be skipped.

Change the default PEAP client behavior to be to require Phase 2
authentication to be successfully completed for cases where TLS session
resumption is not used and the client certificate has not been
configured. Those two exceptions are the main cases where a deployed
authentication server might skip Phase 2 and as such, where a more
strict default behavior could result in undesired interoperability
issues. Requiring Phase 2 authentication will end up disabling TLS
session resumption automatically to avoid interoperability issues.

[ Other info ]
Buster is fixed so upgrade reintroduce the CVE

Bastiendiff -Nru wpa-2.10/debian/changelog wpa-2.10/debian/changelog
--- wpa-2.10/debian/changelog	2023-02-24 13:01:35.0 +
+++ wpa-2.10/debian/changelog	2024-04-30 22:45:18.0 +
@@ -1,3 +1,19 @@
+wpa (2:2.10-12+deb12u1) bookworm; urgency=high
+
+  * Non-maintainer upload on behalf of the Security Team.
+  * Fix CVE-2023-52160 (Closes: #1064061):
+The implementation of PEAP in wpa_supplicant allows
+authentication bypass. For a successful attack,
+wpa_supplicant must be configured to not verify
+the network's TLS certificate during Phase 1
+authentication, and an eap_peap_decrypt vulnerability
+can then be abused to skip Phase 2 authentication.
+The attack vector is sending an EAP-TLV Success packet
+instead of starting Phase 2. This allows an adversary
+to impersonate Enterprise Wi-Fi networks.
+
+ -- Bastien Roucari??s   Tue, 30 Apr 2024 22:45:18 +
+
 wpa (2:2.10-12) unstable; urgency=medium
 
   * Prevent hostapd units from being started if there???s
diff -Nru wpa-2.10/debian/patches/0013-CVE-2023-52160-PEAP-client-Update-Phase-2-authentica.patch wpa-2.10/debian/patches/0013-CVE-2023-52160-PEAP-client-Update-Phase-2-authentica.patch
--- wpa-2.10/debian/patches/0013-CVE-2023-52160-PEAP-client-Update-Phase-2-authentica.patch	1970-01-01 00:00:00.0 +
+++ wpa-2.10/debian/patches/0013-CVE-2023-52160-PEAP-client-Update-Phase-2-authentica.patch	2024-04-30 22:42:02.0 +
@@ -0,0 +1,211 @@
+From: Jouni Malinen 
+Date: Sat, 8 Jul 2023 19:55:32 +0300
+Subject: CVE-2023-52160 PEAP client: Update Phase 2 authentication
+ requirements
+
+The previous PEAP client behavior allowed the server to skip Phase 2
+authentication with the expectation that the server was authenticated
+during Phase 1 through TLS server certificate validation. Various PEAP
+specifications are not exactly clear on what the behavior on this front
+is supposed to be and as such, this ended up being more flexible than
+the TTLS/FAST/TEAP cases. However, this is not really ideal when
+unfortunately common misconfiguration of PEAP is used in deployed
+devices where the server trust root (ca_cert) is not configured or the
+user has an easy option for allowing this validation step to be skipped.
+
+Change the default PEAP client behavior to be to require Phase 2
+authentication to be successfully completed for cases where TLS session
+resumption is not used and the client certificate has not been
+configured. Those two exceptions are the main cases where a deployed
+authentication server might skip Phase 2 and as such, where a more
+strict default behavior could result in undesired interoperability
+issues. Requiring Phase 2 authentication will end up disabling TLS
+session resumption automatically to avoid interoperability issues.
+
+Allow Phase 2 authentication behavior to be configured with a new phase1
+configuration parameter option:
+'phase2_auth' option can be used to control Phase 2 (i.e., within TLS
+tunnel) behavior for PEAP:
+ * 0 = do not require Phase 2 authentication
+ * 1 = require Phase 2 authentication when client certificate
+   (private_key/client_cert) is no used and TLS session resumption was
+   not 

Bug#1070150: texlive-latex-extra: performance regression under emulation with 2023.20240207-1

[Steev Klimaszewski]

Package: texlive-latex-extra
Version: 2023.20240207-1
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

Since the 2023.20240207-1 release, there is a major performance regression when
running the tex-common postinst hook in an arm64 chroot on amd64 host.  

This was not the case with 2022.20230122-3.

When running the hook with the 2023.20240207, this step takes around 3 hours.

I'm guessing that this is related to enabling lua on aarch64 finally, but I'm
not familiar at all with latex and how to get the smallest possible test case to
show the issue.

A way to reproduce the issue would be to install debootstrap, qemu-user-static
and systemd-nspawn and then run apt-get install texlive-latex-extra

On an arm64 host (VM on an original M1 Macbook Air), this is fine

sudo debootstrap --arch arm64 stable stable
sudo systemd-nspawn -D stable
time apt-get install texlive-latex-extra -y

real   1m4.121s
user   0m52.893s
system 0m6.116s

(due to the t64 transition, testing is currentl unable to debootstrap)

sudo debootstrap --arch arm64 sid sid
sudo systemd-nspawn -D sid
time apt-get install texlive-latex-extra -y

real 1m24.647s
user 1m14.897s
sys  0m6.558s

In the qemu emulated build however, 

sudo debootstrap --arch arm64 stable stable
sudo systemd-nspawn -D stable
time apt-get install texlive-latex-extra -y

real 13m14.171s
user 13m26.363s
sys  0m53.424s

texlive-latex-recommended: 2022.20230122-3

sudo debootstrap --arch arm64 sid sid
sudo systemd-nspawn -D sid
time apt-get install texlive-latex-extra -y

real 181m11.687s
user 181m43.534s
sys  1m5.422s

texlive-latex-recommended: 2023.20240207-1


So the version of latex in stable took less than 15 minutes to install, but the
version in testing and unstable both take 2 1/2 hours!  I did also test
2024.20240313.70630+ds-1 from experimental and it also takes the 2 1/2 hours.

Currently, we are working around this by forcing our package list to not install
any of the latex packages, but it would be nice to be able to have the packages
installed instead of telling end users to install them manually.

If you need me to do more testing or any sort of additional information, please
let me know!

-- steev


-- System Information:
Debian Release: kali-rolling
  APT prefers experimental
  APT policy: (1, 'experimental'), (1, 'unstable')
Architecture: arm64 (aarch64)

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

Versions of packages texlive-latex-extra depends on:
pn  libcommons-logging-java
pn  libpdfbox-java 
pn  preview-latex-style
ii  python33.11.6-1
pn  tex-common 
pn  texlive-base   
pn  texlive-binaries   
pn  texlive-latex-recommended  
pn  texlive-pictures   

Versions of packages texlive-latex-extra recommends:
pn  default-jre 
pn  libspreadsheet-parseexcel-perl  
pn  texlive-fonts-recommended   
pn  texlive-plain-generic   

Versions of packages texlive-latex-extra suggests:
pn  icc-profiles 
ii  libfile-which-perl   1.27-2
ii  python3-pygments 2.17.2+dfsg-1
pn  texlive-latex-extra-doc  
pn  texlive-science  

Bug#1068750: moment-timezone.js: FTBFS everywhere

[Martina Ferrari]

Hi Santiago,

On 30/04/2024 14:01, Santiago Vila wrote:

It fails to build if tzdata is updated, but it never stops working. It 
just needs to be updated as often as tzdata is. But if you have a 
suggestion to make this more automatic, I would love to hear it..


Sorry, I still don't get it.

Why does the package build needs to fail if tzdata is updated?



What happens if we allow the package to be built anyway?
(as in the attached patch).
Would the resulting package be broken in any way?


It works, but then there is no way to embed the (effective) tzdata 
version into the moment-timezone.js version, so you could have identical 
source packages producing binaries with the same version and different 
contents, and no way to depend on it. Plus, it almost always fails to 
build anyway, because many of the tests need to be adjusted when tzdata 
changes.


The (better) alternative would be to make it always use a fixed tzdata 
version, but then tzdata migrations will be blocked each time until I 
upload a new version.



I have been doing this very repetitive maintenance for years!


Well, I get that you have to make a new upload so that the package is 
current.
What I don't get is that the package fails to build. At most, it would 
result

in an improved package, not worse. Or maybe I'm missing anything.


What I described above, but I am really open to suggestions on how to 
better handle this.


--
Martina Ferrari

Bug#1070149: ITP: jack -- Rip and encode CDs with one command

[Cord Beermann]

Package: wnpp
Severity: wishlist
Owner: Cord Beermann 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: jack
  Version : 4~git20230906.795fba0
  Upstream Contact: Arne Zellentin 
* URL : https://github.com/jack-cli-cd-ripper/jack
* License : GPL-2+
  Programming Lang: Python
  Description : Rip and encode CDs with one command

 Jack has been developed with one main goal: making OGGs (or MP3s)
 without having to worry. There is nearly no way that an incomplete rip
 goes unnoticed, e.g. jack compares WAV and OGG file sizes when
 continuing from a previous run. Jack also checks your HD space before
 doing anything (even keeps some MB free).
 .
 Jack is different from other such tools in a number of ways:
  - it supports different rippers and encoders
  - it is very configurable
  - it doesn't need X
  - it can "rip" virtual CD images like the ones created by cdrdao
  - when using cdparanoia, cdparanoia's status information is displayed
and archived for all tracks, so you can see if something went wrong
  - it uses sophisticated disk space management, i.e. it schedules its
ripping/encoding processes depending on available space.
  - freedb/gnudb/musicbrainz query, file renaming and id3/ogg-tagging
  - it can resume work after it has been interrupted. If all tracks have
been ripped, it doesn't even need the CD anymore, even if you want
to do a freedb query.
  - it can do a freedb query based on OGGs alone, like if you don't
remember from which CD those OGGs came from.
  - freedb submissions


I used jack a long time, until pathon3 migration. IN the meantime the author
revived the project, so i want to re-introduce it into Debian.

Bug#1070148: sqlparse: CVE-2024-4340: sqlparse parsing heavily nested list leads to Denial of Service

[Salvatore Bonaccorso]

Source: sqlparse
Version: 0.4.4-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for sqlparse.

CVE-2024-4340[0]:
| Passing a heavily nested list to sqlparse.parse() leads to a Denial
| of Service due to RecursionError.


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-4340
https://www.cve.org/CVERecord?id=CVE-2024-4340
[1] https://github.com/advisories/GHSA-2m57-hf25-phgg
[2] 
https://github.com/andialbrecht/sqlparse/commit/b4a39d9850969b4e1d6940d32094ee0b42a2cf03

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1065688: python-jwcrypto: CVE-2024-28102

[Salvatore Bonaccorso]

Hi Steve,

On Tue, Apr 30, 2024 at 05:19:22PM +0100, Steve McIntyre wrote:
> Hi!
> 
> On Fri, Mar 08, 2024 at 10:42:40PM +0100, Salvatore Bonaccorso wrote:
> >Source: python-jwcrypto
> >Version: 1.5.4-1
> >Severity: important
> >Tags: security upstream
> >X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> >
> >
> >Hi,
> >
> >The following vulnerability was published for python-jwcrypto.
> >
> >CVE-2024-28102[0]:
> >| JWCrypto implements JWK, JWS, and JWE specifications using python-
> >| cryptography. Prior to version 1.5.6, an attacker can cause a denial
> >| of service attack by passing in a malicious JWE Token with a high
> >| compression ratio. When the server processes this token, it will
> >| consume a lot of memory and processing time. Version 1.5.6 fixes
> >| this vulnerability by limiting the maximum token length.
> 
> We wanted this fixed in Pexip, so I've taken a look at this bug.
> 
> The upstream bugfix just needs a small rework so it applies cleanly to
> the version in bookworm. Here's a debdiff for that that in case it's
> useful.

The issue does not warrant a DSA, but would be great if fixed in
bookworm if you have done already the work, via a upcoming point
release.

Can you propose the update in stable (unless the maintainers want to
do it on their own)?

Regards,
Salvatore

Bug#1070147: dpkg doesn't allow aborting a package downgrade

[Avram Dorfman]

Package: dpkg
Version: 1.21.22

Exact text of error:

$ sudo dpkg -i etx8-web-2.0.0-29a5f09-b1443.deb
dpkg: warning: downgrading etx8-web from 2.1.0 to 2.0.0
(Reading database ... 35531 files and directories currently installed.)
Preparing to unpack etx8-web-2.0.0-29a5f09-b1443.deb ...
Checking upgrade/ downgrade compatibility...
Migrating network config in prerm
New version 2.0.0 < 2.1.0
Migrating network config 'down'.
found v46 network config: static 10.0.42.33/23 
Aborting migration - Static network configuration is incomplete. System will 
default to DHCP.
Archiving pre-downgrade network configs as '15-etx8-v4v6.network.backup'.
Current configuration: address='10.0.42.33/23', gateway=''; dns=''
dpkg: warning: old etx8-web package pre-removal script subprocess returned 
error exit status 1
dpkg: trying script from the new package instead ...
dpkg: ... it looks like that went OK
Unpacking etx8-web (2.0.0) over (2.1.0) ...

Incorrect behavior:

The package maintainer script workflow does not provide a mechanism for a newer 
installed package to prevent downgrading to an older version of the same 
package, for scenarios where the downgrade is impossible. In every case where 
one of the scripts from the currently installed package can signal an abort 
with a non-zero exit status, the workflow then runs the corresponding script 
from the target package. If that script succeeds, then installation continues. 
This is confirmed by reviewing the flowchart at 
https://www.debian.org/doc/debian-policy/ap-flowcharts.html.

When the target package is older than the currently installed package, its 
maintainer scripts have no knowledge of incompatible downgrade scenarios; they 
are likely to decide to proceed when there is no path to a working outcome.

Expected behavior:

During a downgrade, the older package should not have the final say in whether 
to abort or continue. That responsibility should always belong to the newer 
package, regardless of which is installed or being overwritten. This workflow 
seems to assume that nobody will ever need to revert to an older version of a 
package after they discover issues with a newer version. 

Suggested fixes:

Option 1: Allow different classes of exit status, that signal dpkg on whether 
to try the older version of a given script or not. For example, positive exit 
status could signal that dpkg should always try the alternate version of the 
script, while negative status could signal that dpkg should only try the 
alternate version of the script if the target version is greater than the 
installed version. The rational is that only a newer version should be expected 
to have knowledge of requirements that did not exist at the time the current 
version was released.  

Option 2: Offer an abort command that any maintainer script can call that 
definitively puts the in-progress installation into an abort state. All other 
maintainer scripts that run after abort has been signaled will get a parameter 
indicating that an abort is in progress, and they should only what they can to 
support as graceful of a bail-out as possible.

Versions of package dependencies: not applicable, dpkg is the chicken, packages 
are the eggs

Kernel & C library version: 

Linux voltserv-fe02 5.19.9-voltserver.1 #5 SMP Wed Jan 31 23:29:58 UTC 2024 
armv7l GNU/Linux
-rwxr-xr-x 1 root root 1102644 Apr 19 16:34 /lib/arm-linux-gnueabihf/libc.so.6

Details of the configuration of the program with the problem: None, the problem 
is with dpkg itself

Relevant hardware details: None, although FWIW we are running on ARM32

Additional detail:

Here is a summary of our specific case (some details have been factored out 
that are not relevant to the issue).

The latest version, 2.1, of our application that runs our hardware product on 
an embedded Linux system offers new network configuration. Specifically, 2.1 
allows users to omit the IP default gateway or DNS server, b/c our devices may 
be on an isolated management network does not have them. We have a new config 
file format to support all of the new options. During package install, 
maintainer scripts convert between old and new config file formats. 

There is no way to write a valid 2.0 configuration file without a default 
gateway or DNS server - the 2.0 UI would crash without them. In this case, our 
package maintainer scripts (2.1's prerm to be specific) looks for this 
scenario, and attempts to abort and tell the user what she needs to do before 
this downgrade is possible. However, dpkg then runs the 2.0 prerm script, which 
doesn't know about any of this. It succeeds, and then dpkg completes the 
downgrade, leaving behind a network config file that the newly installed 
version can't read. 

Show me:
* Start with any package at some version, e.g. 1.0. It can be an empty dummy 
package if you have one, as long as it has a maintainer script - e.g. preinst
* Create a 2.0 version of the package
* Let's say that 2.0 can not be downgraded at all to 

Bug#1052009: Provide compiler-rt builtins for windows/mingw-64

[Norbert Lange]

Am So., 28. Apr. 2024 um 18:17 Uhr schrieb Sylvestre Ledru
:
>
> Hello
>
>
> Le 16/09/2023 à 00:29, Norbert Lange a écrit :
> > Package: libclang-rt-16-dev
> > Version: 1:16.0.6-3
> > Severity: wishlist
> > X-Debbugs-Cc: nolang...@gmail.com
> >
> > Adding the compiler-rt library for windows / mingw-64 would allow ease 
> > building
> > mingw-64 tools,
> > the builtins seem to be pretty universal for any windows target.
> >
> > There is a project providing a full mingw toolchain for reference:
> > https://github.com/mstorsjo/llvm-mingw
> >
> > I am able to create the builtins just with the mingw-w64-common package and
> > debians llvm/clang like this:
>
> Sorry but I am not a windows user (or interested by this space), could
> you please provide a MR to implement this?

I am not windows user (or interested by this space) but I am forced to build
for it and I prefer still staying away from that OS as much as possible.

The package is a a bit of a monster though, both in complexity as well
as build-time.
Any tips for hacking around?

Ill try to look at 'build-wasm/compiler-rt-%'.

I am meant to use STAGE2 binaries? Are those the final ones?

Given that clang is a native crosscompiler, I guess it makes sense providing
the mingw builtins as "all" package like libclang-rt-18-dev-wasm32?

Ill see if I  find time for that next week.

Regards, Norbert

Bug#1069538: zeroc-ice: FTBFS on armel: Gradle / Java heap space out-of-memory error

[Chris Knadle]

retitle 1069538 zeroc-ice: FTBFS on armel: Gradle / Java heap space 
out-of-memory-error


tags 1069538 - moreinfo

thanks

I've done additional test builds of zeroc-ice-3.7.10-2.2 on armel on 
porter boxes amdahl and abel and the build fails with the same error 
which seems to be during a Java memory check. It is still unclear as to 
why this error is happening now but not previously.


   -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Bug#1070049: closed by Debian FTP Masters (reply to Carlos Henrique Lima Melara ) (Bug#1070049: fixed in kristall 0.4+dfsg-3)

[Helmut Grohne]

Control: reopen -1

On Mon, Apr 29, 2024 at 07:51:03PM +, Debian Bug Tracking System wrote:
> It has been closed by Debian FTP Masters  
> (reply to Carlos Henrique Lima Melara ).

Unfortunately, my patch got mangled during application to the point
where it no longer achieves the desired effect. The QMAKE_COMMAND
assignment was moved to dh, which causes it to become
-O--=QMAKE_COMMAND=... on the relevant dh_auto_* invocations and is
being ignored. I'd appreciate if you could correctly apply the patch.
Also consider performing a test build (sbuild --host=... or pbuilder
--host-arch=...) to see whether your update retains the intended
effects. Thank you.

Helmut

Bug#1070146: aria2: The -o option could offer a substitution pattern for the original basename

[Manny]

Package: aria2
Version: 1.36.0-1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: debbug.ar...@sideload.33mail.com

The -o option is documented as follows:

===8<
-o, --out=
The file name of the downloaded file.  It is  always  relative  to  the 
 directory  given  in  --dir  option.   When  the
--force-sequential option is used, this option is ignored.

NOTE:
   You  cannot  specify a file name for Metalink or BitTorrent 
downloads.  The file name specified here is only used when
   the URIs fed to aria2 are given on the command line directly, but 
not when using --input-file, --force-sequential  op‐
   tion.

   Example:

   $ aria2c -o myfile.zip "http://mirror1/file.zip; 
"http://mirror2/file.zip;
===8<

There is an ambiguity in the first sentence: “The file name of the
downloaded file.”  It’s unclear from that phrasing if the parameter
will be taken as the name of the source file or the a potentially new
name. The example disambiguates it but it would be better if the
wording were more clear to begin with so readers are not confused
until they study the example.

Simply changing it to: “The name to give the downloaded file” would
make a difference.

I also suggest introducing a pattern substitution mechanism. It’s very
common to want to preserve the original filename but add something to
the name to clarify what it is. For example, consider this file:

  http://download.virtualbox.org/virtualbox/UserManual.pdf

It’s contextually clear from the source path that it’s a user manual
for vbox. But we typically do not want to preserve the original
path. A good filename to produce would be:

  virtualbox_UserManual.pdf

But if there are a lot of files it’s tedious to copy-paste and error
prone to retype them. If a token like “%o” were designated to hold the
original basename, a user could simply write: -o virtualbox_%o.

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

Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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)
LSM: AppArmor: enabled

Versions of packages aria2 depends on:
ii  libaria2-0  1.36.0-1
ii  libc6   2.36-9+deb12u6
ii  libgcc-s1   12.2.0-14
ii  libstdc++6  12.2.0-14

Versions of packages aria2 recommends:
ii  ca-certificates  20230311

aria2 suggests no packages.

-- no debconf information

Bug#1070126: fossil: Do not use embded sqlite

[Barak A. Pearlmutter]

The fossil upstream is also the sqlite3 upstream. They could not
possibly be more familiar with sqlite3!

When you ask fossil to build using an external (system) sqlite3
library, configuration-time checks are performed to see if the
external sqlite3 is up to snuff. If not, either because it is too
early a version or because it was compiled without some necessary
functionality, it ignores your request and builds with the internal
version anyway.

Some time ago, not defining SQLITE_ENABLE_JSON1 was the deficiency
with the Debian system sqlite3 that it noticed. Maybe it's something
else now.

Here's what the sources *say* it needs:

$ ./configure --print-minimum-sqlite-version
Host System...x86_64-pc-linux-gnu
Build System...x86_64-pc-linux-gnu
C compiler... cc -g -O2
C++ compiler... c++ -g -O2
Build C compiler...cc
Checking for stdlib.h...ok
3.43.0

Here's what the autobuilder logs for fossil 2.24 say:

dh_auto_configure -- --disable-option-checking \
--disable-internal-sqlite \
...
Checking for sqlite3_open in sqlite3...-lsqlite3
JSON support enabled
TH1 embedded documentation support enabled
TH1 hooks support enabled
Checking libs for iconv...none needed
...
Using sqlite3.c from this source tree.

Why the fall back to the internal version? It doesn't say. Perhaps
there is some bit rot because they may not exercise this option much.
I will look into it. But in the meantime, getting it to build with the
external sqlite3 might require surgery to disable fossil's
configure-time sqlite3-check logic. I would be loath to do that, for
obvious reasons. In the past, fossil upstream has sometimes put
bleeding-edge sqlite3 versions into its internal version. Right now
it's version 3.46.0, while Debian/sid is at 3.45.3. Sometimes they've
accidentally used recent features without updating the version it asks
for. I wouldn't feel comfortable overriding fossil's config-time
checks without coordination with them on the issue.

Bug#1070142: apt: [INTL:nl] Dutch translation for the apt package

[Frans Spiesschaert]

 
 
Package: apt 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the apt package. 
A draft has been posted to the debian-l10n-dutch mailing list allowing for
review. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1070141: dgit: [INTL:nl] Dutch translation for the dgit package

[Frans Spiesschaert]

 
 
Package: dgit 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the dgit package. 
A draft has been posted to the debian-l10n-dutch mailing list allowing for
review. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1070140: tpm2-tss: CVE-2024-29040

[Salvatore Bonaccorso]

Source: tpm2-tss
Version: 4.0.1-7
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for tpm2-tss.

CVE-2024-29040[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-29040
https://www.cve.org/CVERecord?id=CVE-2024-29040
[1] 
https://github.com/tpm2-software/tpm2-tss/commit/710cd0b6adf3a063f34a8e92da46df7a107d9a99

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1070139: tpm2-tools: CVE-2024-29038 CVE-2024-29039

[Salvatore Bonaccorso]

Source: tpm2-tools
Version: 5.6-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for tpm2-tools.

CVE-2024-29038[0] and CVE-2024-29039[1].

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-29038
https://www.cve.org/CVERecord?id=CVE-2024-29038

https://github.com/tpm2-software/tpm2-tools/commit/66d922d6547b7b4fe4f274fb2ec10b376e0e259c
[1] https://security-tracker.debian.org/tracker/CVE-2024-29039
https://www.cve.org/CVERecord?id=CVE-2024-29039

https://github.com/tpm2-software/tpm2-tools/commit/98599df9392a346216c5a059b8d35271286100bb

Regards,
Salvatore

Bug#1070138: RFS: django-anymail/10.3-1 [ITA] -- Django email backend for multiple ESPs (Python 3)

[Akash Doppalapudi]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "django-anymail":

 * Package name : django-anymail
   Version  : 10.3-1
   Upstream contact : Mike Edmunds 
 * URL  : https://github.com/anymail/django-anymail
 * License  : BSD-3-Clause
 * Vcs  : https://salsa.debian.org/debian/django-anymail
   Section  : python

The source builds the following binary packages:

  python3-django-anymail - Django email backend for multiple ESPs 
(Python 3)


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


  https://mentors.debian.net/package/django-anymail/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/django-anymail/django-anymail_10.3-1.dsc


Changes since the last upload:

 django-anymail (10.3-1) unstable; urgency=medium
 .
   * New upstream version 10.3
   * New Maintainer (Closes: #1063317)
   * d/control:
 - Set Rules-Requires-Root to 'no'
 - Bump Standards-Version to 4.7.0
 - Change Vcs-Browser to correct URL
 - Change Maintainer name to new maintainer
   * d/copyright: Add New maintainer's name in debian/* copyright stanza
   * d/p/0001-No-hatchling-README-install.patch: modify according to 
upstream


Regards,
--
  Akash Doppalapudi


OpenPGP_0xBCBCAE31ECE05007.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070137: bullseye-pu: package cloud-init/22.4.2-1

[Noah Meyerhans]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: cloud-i...@packages.debian.org, t...@security.debian.org
Control: affects -1 + src:cloud-init

Hi folks.  This isn't a straightforward stable proposed-updates
request, but I think starting with such a request is probably the
right approach...

The cloud team builds official Debian images for multiple cloud
environments, including OpenStack, Microsoft Azure, and Amazon EC2.
We support all supported stable releases, including those supported by
the LTS team.  We build images including the backports kernels in
addition to the standard kernels.

To make a long story short, we build our Azure images with the
cloud-init package from bullseye-backports.  Images targeting other
cloud environments use cloud-init from the main repo.

As bullseye-backports nears its EOL date, we're faced with the
possibility that our Azure images contain unsupportable packages, and
that eventually (when bullseye-backports is archived) we'll be unable
to build new images at all.  These are scenarios we'd very much like
to avoid.

We've got at least a few options:

1. With an upcoming bullseye point release (how many more are there?)
   we update cloud-init to the version that's in bookworm.  This is
   the 22.4.2 package, which is close to the 22.4.1 package we're
   currently shipping on Azure.  22.4.2 is well tested in bookworm
   across all major cloud services, though we have not performed any
   major testing in a bullseye environment yet.  For non Azure users,
   this would be an update from version 20.4.2, which is a pretty
   large change.

2. We introduce a new versioned cloud-init source and binary package
   in the bullseye security archive, e.g. something like
   cloud-init-22.4.1.  This would look similar to what the kernel team
   did with the linux-5.10 source package added to buster-security,
   and which I assume they plan on doing with linux-6.1 in
   bullseye-security.  The cloud team would transition to this new
   versioned package for the Azure images, but would continue using
   the existing bullseye package everywhere else.

3. We do nothing, and leave the bullseye Azure users without a
   supportable cloud-init package.

4. Something else?

There are pros and cons to each option.  Given bullseye's age and
cloud-init's blast radius (a regression could potentially disrupt the
provisioning process of cloud VMs, which is particularly disruptive in
such environments) I lean toward option (2) above, as it minimizes the
changes.  The obvious drawback is that we now have two versions of
cloud-init in the bullseye repositories, which was not the case
previously.  The cloud team is committed to supporting this situation
for the duration of the bullseye LTS lifetime.

I realize that the security and release teams won't specifically care
what choice we make once bullseye's final point release is issued, but
I suspect you'll both have useful insights into how best to approach
this situation, and we may need your signoff ahead of that event
depending on which path we choose.

Thanks.
noah

Bug#868095: base-files: clean up legacy conffiles

[Santiago Vila]

El 20/4/24 a las 20:40, Guillem Jover escribió:

Hi!

On Mon, 2024-04-15 at 13:15:13 +0200, Santiago Vila wrote:

Hi. I'm scared about removing /etc/profile by accident.

Guillem: I see that dpkg contains some helper programs to remove
"obsolete conffiles".

Are they meant to be used for conffiles which should no longer exist,
or also for conffiles which are no longer conffiles but should
continue to exist?


I'm afraid they are for the former.


Ok, in such case I believe everything I can reasonably do about this
is to add a new question in the base-files FAQ.

(Not that a lot of people ask about it anyway...)

Thanks.

Bug#1070136: openjdk-17-jre-headless: error creating symbolic link '/usr/share/man/man1/java.1.gz.dpkg-tmp': No such file or directory

[Peter van Dijk]

Package: openjdk-17-jre-headless
Version: 17.0.11+9-1~deb12u1
Severity: normal
X-Debbugs-Cc: pe...@7bits.nl

Dear Maintainer,

   * What led up to the situation?

Installing openjdk-17-jre-headless on a very minimal base system. The 12-slim 
Docker image is not minimal enough
 to reproduce this (it has an empty /usr/share/man/man1) but an mkosi-build 
Debian Bookworm image reproduces it
(by not having /usr/share/man/man1)

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

As suggested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863199 (which 
appears to be a previous instanc
e of the same problem), mkdir -p /usr/share/man/man1 followed by apt install -f 
sorted the situation. The fix ap
plied to close that bug would likely help here too.

Please note that the System Information below is from after:

* attempting to install openjdk-17-jre-headless
* the mkdir -p
* installing reportbug and its dependencies

although I have the impression installing reportbug did not change any of the 
information mentioned below.

-- System Information:
Debian Release: 12.1
  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)
Kernel taint flags: TAINT_DIE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openjdk-17-jre-headless depends on:
ii  ca-certificates-java  20230710~deb12u1
ii  java-common   0.74
ii  libasound21.2.8-1+b1
ii  libc6 2.36-9+deb12u1
ii  libcups2  2.4.2-3+deb12u5
ii  libfontconfig12.14.1-4
ii  libfreetype6  2.12.1+dfsg-5
ii  libgcc-s1 12.2.0-14
ii  libharfbuzz0b 6.0.0+dfsg-3
ii  libjpeg62-turbo   1:2.1.5-2
ii  liblcms2-22.14-2
ii  libnss3   2:3.87.1-1
ii  libpcsclite1  1.9.9-2
ii  libstdc++612.2.0-14
ii  util-linux2.38.1-5+b1
ii  zlib1g1:1.2.13.dfsg-1

openjdk-17-jre-headless recommends no packages.

Versions of packages openjdk-17-jre-headless suggests:
pn  fonts-dejavu-extra 
pn  fonts-indic
pn  fonts-ipafont-gothic   
pn  fonts-ipafont-mincho   
pn  fonts-wqy-microhei | fonts-wqy-zenhei  
pn  libnss-mdns

-- no debconf information

Bug#1070135: Acknowledgement (tempfile.TemporaryDirectory: symlink bug in cleanup (CVE-2023-6597))

[Steve McIntyre]

Control: fixed 1070135 3.11.8-1

On Tue, Apr 30, 2024 at 05:45:04PM +, Debian Bug Tracking System wrote:
>Thank you for filing a new Bug report with Debian.
>
>You can follow progress on this Bug here: 1070135: 
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070135.
>
>This is an automatically generated reply to let you know your message
>has been received.
>
>Your message is being forwarded to the package maintainers and other
>interested parties for their attention; they will reply in due course.
>
>As you requested using X-Debbugs-CC, your message was also forwarded to
>  steve.mcint...@pexip.com, debian security team 
>(after having been given a Bug report number, if it did not have one).
>
>Your message has been sent to the package maintainer(s):
> Matthias Klose 
>
>If you wish to submit further information on this problem, please
>send it to 1070...@bugs.debian.org.
>
>Please do not send mail to ow...@bugs.debian.org unless you wish
>to report a problem with the Bug-tracking system.
>
>-- 
>1070135: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070135
>Debian Bug Tracking System
>Contact ow...@bugs.debian.org with problems
>
-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone

Bug#1070040: bookworm-pu: package dm-writeboost/???

[Paul Gevers]

Hi,

On 30-04-2024 8:54 a.m., Andreas Beckmann wrote:
Can you point me to the code that evaluates dpkg's Testsuite-Triggers to 
schedule these tests? Maybe it's possible to convert dpkg's Testsuite 
field to a (hardcoded) list of additional triggers ...


I think you mean this: 
https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/utils.py?ref_type=heads#L609


Or probably more something like this one: 
https://salsa.debian.org/release-team/britney2/-/blob/master/britney2/policies/autopkgtest.py?ref_type=heads#L615 
and where it's used.


Having said that, I'm not a great fan of teaching britney2 about 
autodep8 internal details.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070135: tempfile.TemporaryDirectory: symlink bug in cleanup (CVE-2023-6597)

[Steve McIntyre]

Source: python3.11
Version: 3.11.2-6
Severity: minor
Tags: security upstream
X-Debbugs-Cc: steve.mcint...@pexip.com, Debian Security Team 


Quoting https://security-tracker.debian.org/tracker/CVE-2023-6597:

An issue was found in the CPython `tempfile.TemporaryDirectory` class
affecting versions 3.12.1, 3.11.7, 3.10.13, 3.9.18, and 3.8.18 and
prior. The tempfile.TemporaryDirectory class would dereference
symlinks during cleanup of permissions-related errors. This means
users which can run privileged programs are potentially able to modify
permissions of files referenced by symlinks in some circumstances.

Upstream have a patch for this, against 3.11.8. It's not too hard to
backport - I'll attach the tweaked patch shortly.

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

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

-- debconf-show failed

Bug#1052298: metafun broken?

[Preuße]

Control: reassign -1 context-modules
Control: tags -1 + pending

On 30.04.2024 18:28, Preuße...@buxtehude.debian.org, Hilmar wrote:

Hi *,

I'll upload a context-modules package to Debian experimental, which will 
contain the legacy mkii packages. This will bring back metafun.mpii, but 
won't make you happy anyway, as even the minimal example does not 
compile. I'll close that bug anyway, please open a new one, once you 
tested the package.




Reassign, tag

H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070133: Acknowledgement (python 3.11 zipbomb attack (CVE-2024-0450))

[Steve McIntyre]

Control: fixed 1070133 3.11.8-1

On Tue, Apr 30, 2024 at 05:24:04PM +, Debian Bug Tracking System wrote:
>Thank you for filing a new Bug report with Debian.
>
>You can follow progress on this Bug here: 1070133: 
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070133.
>
>This is an automatically generated reply to let you know your message
>has been received.
>
>Your message is being forwarded to the package maintainers and other
>interested parties for their attention; they will reply in due course.
>
>As you requested using X-Debbugs-CC, your message was also forwarded to
>  debian security team 
>(after having been given a Bug report number, if it did not have one).
>
>Your message has been sent to the package maintainer(s):
> Matthias Klose 
>
>If you wish to submit further information on this problem, please
>send it to 1070...@bugs.debian.org.
>
>Please do not send mail to ow...@bugs.debian.org unless you wish
>to report a problem with the Bug-tracking system.
>
>-- 
>1070133: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070133
>Debian Bug Tracking System
>Contact ow...@bugs.debian.org with problems
>
-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Bug#1070130: python3-pycurl: SSL path issues - upstream bug

[Scott Talbert]

On Tue, 30 Apr 2024, i...@fernandolucas.info wrote:


Package: python3-pycurl
Version: 7.45.3-2
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

Please consider

https://github.com/pycurl/pycurl/issues/834
pycurl 7.45.3 wheel not working for https in debian/ubuntu systems

I confirm that the debian package for 7.45.3 fails sometimes to handle SSL 
connections,
meanwhile 7.45.2 works properly always.

Mabye it can be manually patched, or skip version 7.45.3 for debian.


Are you having problems with the Debian packaged version of pycurl, or 
with the pycurl wheel from upstream?  If the you're having problems with 
the packaged version of pycurl, can you please explain how to reproduce 
the problem?


Thanks,
Scott

Bug#1070134: photoqt: Depends missed

[Egor Nechkin]

Package: photoqt
Version: 4.2+ds-3
Severity: important
Tags: patch
X-Debbugs-Cc: e.nech...@gmail.com

Dear Maintainer,

PhotoQt installed from testing and have had some troubles: crash on start,
invisible file dialog etc.
Installing the following packages makes it operable:

qml6-module-qtquick-window
qml6-module-qtquick-templates
qml6-module-qtcore
libqt6quickdialogs2-6


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 photoqt depends on:
ii  libarchive13  3.7.2-1
ii  libc6 2.37-18
ii  libdevil1c2   1.7.8-10+b3
ii  libexiv2-27   0.27.6-1+b1
ii  libfreeimage3 3.18.0+ds2-10+b1
ii  libgcc-s1 13.2.0-9
ii  libglib2.0-0t64 [libglib2.0-0]2.78.4-7
ii  libmagick++-6.q16-9   8:6.9.12.98+dfsg1-5+b1
ii  libmpv2   0.37.0-1
ii  libpoppler-qt6-3  22.12.0-2+b1
ii  libpugixml1v5 1.14-0.1+b1
ii  libqt6core6   6.4.2+dfsg-21
ii  libqt6dbus6   6.4.2+dfsg-21
ii  libqt6gui66.4.2+dfsg-21
ii  libqt6network66.4.2+dfsg-21
ii  libqt6opengl6 6.4.2+dfsg-21
ii  libqt6printsupport6   6.4.2+dfsg-21
ii  libqt6qml66.4.2+dfsg-4+b1
ii  libqt6quick6  6.4.2+dfsg-4+b1
ii  libqt6sql66.4.2+dfsg-21
ii  libqt6svg66.4.2-4+b1
ii  libqt6widgets66.4.2+dfsg-21
ii  libraw23  0.21.2-1
ii  libstdc++613.2.0-9
ii  libvips42 8.15.1-1
ii  python3-pychromecast  9.4.0-2
ii  qml6-module-qt-labs-platform  6.4.2+dfsg-4+b1
ii  qml6-module-qtmultimedia  6.4.2-11+b1
ii  qml6-module-qtquick-localstorage  6.4.2+dfsg-4+b1

Versions of packages photoqt recommends:
ii  kimageformat-plugins  5.107.0-3.1

photoqt suggests no packages.

-- no debconf information

Bug#1070133: python 3.11 zipbomb attack (CVE-2024-0450)

[Steve McIntyre]

Source: python3.11
Version: 3.11.2-6
Severity: important
Tags: upstream security
X-Debbugs-Cc: Debian Security Team 

Quoting https://security-tracker.debian.org/tracker/CVE-2024-0450:

An issue was found in the CPython `zipfile` module affecting versions
3.12.1, 3.11.7, 3.10.13, 3.9.18, and 3.8.18 and prior. The zipfile
module is vulnerable to “quoted-overlap” zip-bombs which exploit the
zip format to create a zip-bomb with a high compression ratio. The
fixed versions of CPython makes the zipfile module reject zip archives
which overlap entries in the archive.

Upstream have a patch for this, against 3.11.8. It's not too hard to
backport - I'll attach the tweaked patch shortly.

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

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

-- debconf-show failed

Bug#1069280: Offer to co-maintain or adopt less

[P. J. McDermott]

Milan,

I see you're at least catching up on src:less bug reports, so I won't
pursue the salvaging process.  But my offer to help co-maintain still
stands.

Either way, as a reminder in case it helps you, in my Salsa fork[1] I:

  * Updated to the latest upstream release version 643, closing bugs
#1069037, #901071, #1059967, #931216, and #977494
  * Worked around tests broken since version 632
  * Dropped End-OSC8-hyperlink-on-invalid-embedded-escape-sequen.patch,
applied upstream
  * Refreshed debian/patches/02-655926-more_can_go_backwards.patch
  * Added GNU/Hurd PATH_MAX FTBFS patch from #1060420, applied upstream
  * Fixed lintian old-fsf-address-in-copyright-file,
trailing-whitespace, uses-debhelper-compat-file, and
package-uses-old-debhelper-compat-version (all lintian tags
including info and pedantic are fixed)
  * Added patches (one from upstream, one from me applied upstream) to
fix troff warnings introduced in upstream versions 595 and 608
  * Added DEP-3 headers to debian/patches/less-is-more-434417.patch and
debian/patches/02-655926-more_can_go_backwards.patch both of which I
forwarded upstream (and the latter was accepted)
  * Added .gitignore to fix gbp-buildpackage complaining about .pc/
  * Added debian/salsa-ci.yml

I've rebased upon Salvatore's NMU.  Let me know if I should request
commit access on Salsa to debian/less.git (as a non-DD I don't
automatically have access).  It looks like you have merge requests
disabled.

Feel free to take any or all of my changes and exclude any you don't
like, such as the Uploaders change.

[1]: https://salsa.debian.org/pehjota/less
-- 
Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/


pgpyTs9yKP1Ww.pgp
Description: OpenPGP digital signature

Bug#1059007: python-asyncssh: CVE-2023-48795

[Steve McIntyre]

Hi!

On Tue, Dec 19, 2023 at 09:31:00AM +0100, Salvatore Bonaccorso wrote:
>Source: python-asyncssh
>Version: 2.10.1-2
>Severity: important
>Tags: security upstream
>X-Debbugs-Cc: car...@debian.org, Debian Security Team 
>
>
>Hi,
>
>The following vulnerability was published for python-asyncssh.
>
>CVE-2023-48795[0]:
>| The SSH transport protocol with certain OpenSSH extensions, found in
>| OpenSSH before 9.6 and other products, allows remote attackers to
>| bypass integrity checks such that some packets are omitted (from the
>| extension negotiation message), and a client and server may
>| consequently end up with a connection for which some security
>| features have been downgraded or disabled, aka a Terrapin attack.
>| This occurs because the SSH Binary Packet Protocol (BPP),
>| implemented by these extensions, mishandles the handshake phase and
>| mishandles use of sequence numbers. For example, there is an
>| effective attack against SSH's use of ChaCha20-Poly1305 (and CBC
>| with Encrypt-then-MAC). The bypass occurs in
>| chacha20-poly1...@openssh.com and (if CBC is used) the
>| -e...@openssh.com MAC algorithms. This also affects Maverick Synergy
>| Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh
>| before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before
>| 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, and
>| libssh2 through 1.11.0; and there could be effects on Bitvise SSH
>| through 9.31.

We wanted this fixed in Pexip, so I've taken a look at this bug.

The upstream bugfix just needs a small rework so it applies cleanly to
the version in bookworm. Here's a debdiff for that that in case it's
useful.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back
diff -Nru python-asyncssh-2.10.1/debian/changelog 
python-asyncssh-2.10.1/debian/changelog
--- python-asyncssh-2.10.1/debian/changelog 2022-12-22 03:54:16.0 
+
+++ python-asyncssh-2.10.1/debian/changelog 2024-04-29 11:45:47.0 
+0100
@@ -1,3 +1,11 @@
+python-asyncssh (2.10.1-2+deb12u1) bookworm; urgency=medium
+
+  * Apply and tweak upstream security fix for CVE-2023-48795
+Implement "strict kex" support to harden AsyncSSH against Terrapin
+Attack. Closes: #1059007
+
+ -- Steve McIntyre   Mon, 29 Apr 2024 11:45:47 +0100
+
 python-asyncssh (2.10.1-2) unstable; urgency=medium
 
   * Team Upload.
diff -Nru python-asyncssh-2.10.1/debian/patches/CVE-2023-48795.patch 
python-asyncssh-2.10.1/debian/patches/CVE-2023-48795.patch
--- python-asyncssh-2.10.1/debian/patches/CVE-2023-48795.patch  1970-01-01 
01:00:00.0 +0100
+++ python-asyncssh-2.10.1/debian/patches/CVE-2023-48795.patch  2024-04-29 
11:45:47.0 +0100
@@ -0,0 +1,382 @@
+commit 0bc73254f41acb140187e0c89606311f88de5b7b
+Author: Ron Frederick 
+Date:   Mon Dec 18 07:41:57 2023 -0800
+
+Implement "strict kex" support to harden AsyncSSH against Terrapin Attack
+
+This commit implements "strict kex" support and other countermeasures to
+protect against the Terrapin Attack described in CVE-2023-48795. Thanks
+once again go to Fabian Bäumer, Marcus Brinkmann, and Jörg Schwenk for
+identifying and reporting this vulnerability and providing detailed
+analysis and suggestions about proposed fixes.
+
+Index: b/asyncssh/connection.py
+===
+--- a/asyncssh/connection.py
 b/asyncssh/connection.py
+@@ -810,6 +810,7 @@ class SSHConnection(SSHPacketHandler, as
+ self._kexinit_sent = False
+ self._kex_complete = False
+ self._ignore_first_kex = False
++self._strict_kex = False
+ 
+ self._gss: Optional[GSSBase] = None
+ self._gss_kex = False
+@@ -1343,10 +1344,13 @@ class SSHConnection(SSHPacketHandler, as
+ (alg_type, b','.join(local_algs).decode('ascii'),
+  b','.join(remote_algs).decode('ascii')))
+ 
+-def _get_ext_info_kex_alg(self) -> List[bytes]:
+-"""Return the kex alg to add if any to request extension info"""
++def _get_extra_kex_algs(self) -> List[bytes]:
++"""Return the extra kex algs to add"""
+ 
+-return [b'ext-info-c' if self.is_client() else b'ext-info-s']
++if self.is_client():
++return [b'ext-info-c', b'kex-strict-c-...@openssh.com']
++else:
++return [b'ext-info-s', b'kex-strict-s-...@openssh.com']
+ 
+ def _send(self, data: bytes) -> None:
+ """Send data to the SSH connection"""
+@@ -1487,6 +1491,11 @@ class SSHConnection(SSHPacketHandler, as
+ self._ignore_first_kex = False
+ else:
+ handler = self._kex
++elif self._strict_kex and not self._recv_encryption and \
++MSG_IGNORE <= pkttype <= MSG_DEBUG:
++skip_reason = 'strict kex violation'
++exc_reason = 'Strict key 

Bug#1070132: sponsorship-requests: libkal/0.9.0-3.1 [NMU] [RC] -- library for converting dates between various calendar systems

[Bo YU]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : libkal
   Version  : 0.9.0-3.1
   Upstream contact : Petr Tomasek 
 * URL  : http://www.etf.cuni.cz/~tomasek/pub/my/
 * License  : LGPL-2+
 * Vcs  : https://salsa.debian.org/debian/libkal
   Section  : libs

The source builds the following binary packages:

  libkal-dev - library for converting dates between various calendar systems

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libk/libkal/libkal_0.9.0-3.1.dsc

Changes since the last upload:

 libkal (0.9.0-3.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add fix-impfuncdef-issue.diff to fix ftbfs. (Closes: #1066513)


-- 
Regards,
--
  Bo YU

diff -Nru libkal-0.9.0/debian/changelog libkal-0.9.0/debian/changelog
--- libkal-0.9.0/debian/changelog   2023-04-25 10:11:53.0 +0800
+++ libkal-0.9.0/debian/changelog   2024-04-30 16:19:46.0 +0800
@@ -1,3 +1,10 @@
+libkal (0.9.0-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add fix-impfuncdef-issue.diff to fix ftbfs. (Closes: #1066513)
+
+ -- Bo YU   Tue, 30 Apr 2024 16:19:46 +0800
+
 libkal (0.9.0-3) unstable; urgency=medium
 
   [ Jelmer Vernooij ]
diff -Nru libkal-0.9.0/debian/patches/fix-impfuncdef-issue.diff 
libkal-0.9.0/debian/patches/fix-impfuncdef-issue.diff
--- libkal-0.9.0/debian/patches/fix-impfuncdef-issue.diff   1970-01-01 
08:00:00.0 +0800
+++ libkal-0.9.0/debian/patches/fix-impfuncdef-issue.diff   2024-04-30 
16:18:31.0 +0800
@@ -0,0 +1,19 @@
+Description: fix impfuncdef issue
+Author: Bo YU 
+Bug: https://bugs.debian.org/1066513
+Forwarded: send to Petr Tomasek 
+Last-Update: 2024-04-30
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/kal_getdate.c
 b/kal_getdate.c
+@@ -18,6 +18,9 @@
+  */
+ 
+ #include 
++#include 
++
++#include "kal_main.h"
+ 
+ /* 
+  * Get current date (jd)
diff -Nru libkal-0.9.0/debian/patches/series libkal-0.9.0/debian/patches/series
--- libkal-0.9.0/debian/patches/series  2023-04-25 10:11:53.0 +0800
+++ libkal-0.9.0/debian/patches/series  2024-04-30 10:30:01.0 +0800
@@ -1 +1,2 @@
 Makefile.diff
+fix-impfuncdef-issue.diff


signature.asc
Description: PGP signature

Bug#930168: Confirming the bug on Debian

[Hefee]

I can confim the same behaviour on current Debian sid and I found a working 
solution for me.

In the end it was an issue outside discover. appstream data update was 
disabled, I proplery did that because the files are that big. I sill could 
search apps via appstream, so I thought that is not the root issue.

$ appstreamcli search kate
Identifier: org.kde.kate.desktop [desktop-application]
[...]

So appstream was already installed and working.

Steps I needed to do to list apps within discover:
rename /etc/apt/apt.conf.d/#50appstream to /etc/apt/apt.conf.d/50appstream
apt update

That was all.

So for others it is a good idea to check:
* can I search apps vis appstream (  appstreamcli search kate )
* does the update command is successfull ( appstreamcli refresh --source=os); 
or the command that is triggered by /etc/apt/apt.conf.d/50appstream)
* is /var/cache/swcatalog populated and writeable

that at least should clearify the issue even more.

regards,

hefee

On Mittwoch, 12. Juni 2019 01:07:03 CEST Alexander Kernozhitsky wrote:
> I also encounter this bug on Debian Buster.
> 
> But I manually disabled all the AppStream and DEP-11 metadata from apt
> configs, so this may be the reason.
> 
> Can anyone reproduce this on a clean system?



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

Bug#1070042: libarchive: archive_entry_stat returns zero size on mips64el with _FILE_OFFSET_BITS=64

[Theodore Ts'o]

reassign 1070042 e2fsprogs 1.47.1~rc1-1
retitle mke2fs -d foo.tar is broken on mips64el
thanks

On Tue, Apr 30, 2024 at 11:12:36AM +0300, Peter Pentchev wrote:
> > AC_SYS_LARGEFILE was added to e2fsprogs configure.ac 2 years ago, 
> > therefore manual
> >   #define _FILE_OFFSET_BITS 64
> >   #define _LARGEFILE64_SOURCE 1
> > should no longer be necessary for architectures where it is needed.
> 
> Yeah, I think that's what Helmut Grohne said in #1068251, I knew I had
> seen it before. So IMHO the problem here is indeed not in libarchive, but,
> yes, in e2fsprogs setting FILE_OFFSET_BITS=64 unconditionally.
> 
> As such, if no one objects, I think this bug should be closed and
> e2fsprogs should indeed rely on AC_SYS_LARGEFILE (as libarchive already does)
> instead.

Thanks for the analysis!  I've reassigned this bug to e2fsprogs and I
will fix it on my end.

Cheers,

- Ted

Bug#1069672: bookworm-pu: package flatpak/1.14.8-1~deb12u1

[Simon McVittie]

Control: retitle -1 bookworm-pu: package flatpak/1.14.8-1~deb12u1

flatpak 1.14.7 has now been released, closely followed by 1.14.8 to
revert unintended changes to the libglnx and bubblewrap submodules.
I would like to get this into a Debian 12 point release if possible.

I'm sorry about the size of this update, but we've built up quite a large
backlog of bug-fix changes upstream, and until very recently I have been
the only person making releases, so their frequency is limited by my
available time. If time permits, I will try to do more, smaller stable
updates in future.

[ Impact ]
If not accepted, several known bugs remain present in stable.
The highest-visibility is that the developer name of an app appears
in the CLI where the app name should be, for example "The Chromium Authors"
instead of the correct "Chromium Web Browser".

Also, if we keep up with upstream stable releases, then next time there
is a CVE, we have the option of taking upstream's stable release directly
instead of having to backport individual patches.

[ Tests ]
This is a relatively straightforward backport of the version I uploaded
to unstable today.

There is a fairly comprehensive test suite. It cannot be run under schroot
or lxc due to limitations of nested containers, but I run it in
autopkgtest-virt-qemu before each upload, and ci.debian.net has now been
configured to run flatpak's tests under autopkgtest-virt-qemu has well.

Also successfully manually tested on some bookworm systems:
- Can still set up a fresh installation as per
  https://flathub.org/en-GB/setup/Debian and install/run an app
  (tested with org.gnome.Recipes)
- Can still upgrade apps on an existing installation
- `flatpak update`, with an updated version of Chromium available, fixes
  the developer-name bug mentioned above
- It is now possible to run e.g.
  `flatpak run --command=bash org.gnome.Recipes` inside a
  `podman run --privileged` container with no D-Bus system bus, which
  wasn't possible before
  (tested without Recommends, other than ca-certificates which is required
  for installing from Flathub)
- CVE-2024-32462 is still fixed

[ Risks ]
Somewhat low risk, all changes are targeted bug fixes. I would say that
the highest-risk are the alterations to how AppStream metadata is parsed
and displayed, but several distributions are already using those changes
via the 1.15.x branch and we have not had regression reports.

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

[ Changes ]

* Makefile.am,
  configure.ac,
  data/Makefile.am.inc,
  data/tmpfiles.d/flatpak.conf,
  debian/flatpak.install,
  sideload-repos-systemd/Makefile.am.inc:
  - Add systemd-tmpfiles snippet run during boot to delete any obsolete
/var/tmp/flatpak-cache-* from the previous boot

* app/flatpak-builtins-build.c,
  common/flatpak-dir.c,
  common/flatpak-run.c,
  debian/patches/*,
  tests/test-run.sh:
  - Fix CVE-2024-32462 in upstream source instead of via a patch

* app/flatpak-builtins-ps.c:
  - Use xdg-desktop-portal-gnome in addition to -gtk and -kde to determine
whether an app is running in the background

* app/flatpak-builtins-remote-info.c:
  - Fix display of app info in `flatpak remote-info`
  - Fix some uses of deprecated libappstream API
  - Forward-compatibility with libappstream 0.17.x and 1.0

* app/flatpak-builtins-remote-ls.c,
  app/flatpak-builtins-search.c,
  app/flatpak-builtins-utils.c,
  app/flatpak-builtins-utils.h,
  config.h.in,
  configure.ac:
  - Fix some uses of deprecated libappstream API
  - Forward-compatibility with libappstream 0.17.x and 1.0

* app/flatpak-builtins-run.c,
  tests/testlibrary.c:
  - Silence compiler warning false-positives

* common/flatpak-appdata.c,
  tests/make-test-app.sh,
  tests/test-info.sh:
  - Don't parse the app developer name as though it was the app name
(for newly-installed apps the fix takes effect immediately, for
affected apps that were installed with an older Flatpak the fix will
take effect the next time that app is upgraded)

* common/flatpak-dir.c:
  - Automatically reload D-Bus session bus configuration on new
installations and upgrades, so that new .service files are reliably
picked up
  - Forward compatibility with newer GLib
  - Silence a compiler warning false-positive
  - Fix a minor memory leak

* common/flatpak-prune.c:
  - Fix some signed integer arithmetic that is strictly speaking
undefined behaviour

* common/flatpak-run.c,
  doc/flatpak-run.xml:
  - Don't let the sandboxed app inherit a wrong value for various
environment variables from the host system related to ld.so, EGL
and Vulkan

* common/flatpak-run.c,
  tests/test-repo.sh:
  - Don't try to repeat data migration for apps whose data was already
migrated to a new name and then deleted

* common/flatpak-run.c:
  - Ensure that 

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

[Guilhem Moulin]

Hi Tomasz,

On Fri, 5 Apr 2024 at 01:11:41 +0200, Tomasz Buchert wrote:
> Looking into older versions and appropriately patching them will take
> more time.

I'm preparing an update for this issue for Buster LTS and can hand
tested debdiffs over to the Security Team for newer suites if you'd
like.  (AFAICT the fix is the same but pending feedback I haven't tested
it thoroughly yet.)

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1070129: ITP: web-cache -- Simple Python key-value storage backed up by sqlite3 database

[Antoine Beaupré]

Control: retitle -1 ITP: web-cache -- Simple Python key-value storage backed up 
by sqlite3 database

On 2024-04-30 12:26:05, Antoine Beaupre wrote:
> * Package name: python3-web-cache

Actually, py2dsp makes a package named `web-cache` for this, which seems
a tad too generic. Thoughts?

-- 
Only after disaster can we be resurrected.
It's only after you've lost everything that you're free to doanything.
Nothing is static, everything is evolving, everything is falling apart.
- Chuck Palahniuk, Fight Club

Bug#1068953: new upstream (10.0)

[Daniel Baumann]

On 4/30/24 12:56, David Lamparter wrote:

Ok, for the time being I've instead decided to use this as a kick in my
ass to finally do the NM procedure to become a Debian Maintainer...
https://nm.debian.org/process/1284/


hehe, nice ;)


I have no idea what kind of timescale that works on, but I probably
can't get to hppa debugging right off anyway


can take from anywhere between a few days and a couple of months, 
depending on the availability of $people and you providing/fulfilling 
the requirements.



worst case I'd ping you later?


anytime, sure.

Regards,
Daniel

Bug#1070131: RFS: emacs-cfrs/1.6.0-1 [ITP] -- Child-frame based read-string for Emacs

[Xiyue Deng]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "emacs-cfrs":

 * Package name : emacs-cfrs
   Version  : 1.6.0-1
   Upstream contact : Alexander Miller 
 * URL  : https://github.com/Alexander-Miller/cfrs
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/emacsen-team/emacs-cfrs
   Section  : editors

The source builds the following binary packages:

  elpa-cfrs - Child-frame based read-string for Emacs

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

  https://mentors.debian.net/package/emacs-cfrs/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/emacs-cfrs/emacs-cfrs_1.6.0-1.dsc

Changes for the initial release:

 emacs-cfrs (1.6.0-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1070096)

Note that this is a required dependency of newer treemacs versions which
I plan to request for RFS soon after this is sponsored.

Regards,
-- 
Xiyue Deng

Bug#1067077: frr: FTBFS on armel: /usr/bin/ld: ./build/../bgpd/bgp_io.c:476:(.text+0x51c): undefined reference to `__atomic_store_8'

[Daniel Baumann]

Hi David,

On 4/30/24 18:21, David Lamparter wrote:

flipped libatomic to be linked unconditionally.


it's not harmful to do so on architectures that don't need it, but imho 
its cleaner to only be linked on affected architectures (armel m68k 
powerpc sh4).



https://github.com/FRRouting/frr/commits/debian/master/


nice, thanks!


Do you want to do anything else with it or should I go mark it as -1?


my last attempt from yesterday didn't work (after a long time it took to 
build on the armel porterbox), so -1 looks good like that.


Regards,
Daniel

Bug#1068951: new upstream (6.x)

[Daniel Baumann]

Hi,

On 4/30/24 18:12, Jakub Ružička wrote:
Secondary reason for that was that there is no upgrade path from 5.x to 
6.x so it's unwanted for knot-resolver 5 packages to auto-update to 6.


For that, the package probably needs a different name (like 
knot-resolver6)


imho this should be handled in the package (e.g. by showing a debconf 
note or so) and be included in the trixie release notes. renaming the 
binary package doesn't really solve much and is more suited for 
(library) transitions, i.e. if there were several knot-resolver-module-* 
packages or so.


also (I haven't looked at it), is it worthwile to (with users consent) 
to "try" to guess with (some parts of) the old config to generate the 
new config from?



So what do you suggest?


generally, the amount of binary packages should be limited to a minimum 
- oiow there needs to be a reason why an additional binary package is 
added. some of them are:


  * saving relative excessive amount of diskspace (e.g. large
documentation can be split into a -doc package)

  * different parts have different dependencies and/or particulary
long dependency chains (e.g. gtk parts of a cli tool)

therefore, imho the following binary packages make sense here:

  * knot-resolver
  * knot-resolver-doc
  * knot-resolver-module-dnstap
  * knot-resolver-module-http

Note that -dbg packages are generated automatically and don't need to be 
specified in control (I'll provide a commit for that).


Regards,
Daniel

Bug#1052298: metafun broken?

[Preuße]

On 23.02.2024 23:31, Hilmar Preuße wrote:

On 27.10.23 22:31, Siep Kroonenberg wrote:


Hi Stéphane,


The standalone context is mostly free from mkii, but cont-tmf.zip
still has most of the legacy stuff, which will mostly be added back
in, in the form of a context-legacy package for TL. I find sorting
things out and creating / modifying the .tlpsrc definitions for the
context packages a tricky business; it is going a lot slower than I
hoped and expected.



I noticed that there is now a package context-legacy.r69173.tar.xz in 
the TL/archive subdir . I contains a lot of stuff 
"tex/context/patterns/mkii". I guess I have to package that and upload 
it into Debian.




I'll upload a context-modules package to Debian experimental, which will 
contain the legacy mkii packages. This will bring back metafun.mpii, but 
won't make you happy anyway, as even the minimal example does not 
compile. I'll close that bug anyway, please open a new one, once you 
tested the package.


root@rasppi2:~# cat a.mp
input metafun.mp ;
root@rasppi2:~# mpost -interaction=nonstopmode a.mp
This is MetaPost, version 2.02 (TeX Live 2023/Debian) (kpathsea version 
6.3.5)

(/usr/share/texlive/texmf-dist/metapost/base/mpost.mp
(/usr/share/texlive/texmf-dist/metapost/base/plain.mp
Preloading the plain mem file, version 1.005) ) (./a.mp
(/usr/share/texmf/metapost/context/base/common/metafun.mp
(/usr/share/texlive/texmf-dist/metapost/context/base/mpii/metafun.mpii
(/usr/share/texlive/texmf-dist/metapost/context/base/mpii/mp-base.mpii
Preloading the plain mem file, version 1.004 for metafun ii
! Redundant equation.

   ;
l.338 mm=2.83464;
   pt=0.99626;dd=1.06601;  bp:=1;
! Redundant equation.

   ;
l.338 mm=2.83464;  pt=0.99626;
  dd=1.06601;  bp:=1;
! Redundant equation.

   ;
l.338 ...3464;  pt=0.99626;dd=1.06601;
bp:=1;
! Redundant equation.

   ;
l.339 cm=28.34645;
   pc=11.95517;   cc=12.79213; in:=72;
! Redundant equation.

   ;
l.339 cm=28.34645; pc=11.95517;
  cc=12.79213; in:=72;
! Redundant equation.

   ;
l.339 ...4645; pc=11.95517;   cc=12.79213;
   in:=72;
! Redundant equation.

   ;
l.530 laboff=(0,0);labxf=.5;
  labyf=.5;
! Redundant equation.

   ;
l.530 ...  =(0,0);labxf=.5;  labyf=.5;

! Redundant equation.

   ;
l.531 laboff.lft=(-1,0);   labxf.lft=1;
  labyf.lft=.5;
! Redundant equation.

   ;
l.531 ...ft=(-1,0);   labxf.lft=1;   labyf.lft=.5;

! Redundant equation.

   ;
l.532 laboff.rt =(1,0);labxf.rt =0;
  labyf.rt =.5;
! Redundant equation.

   ;
l.532 ...t =(1,0);labxf.rt =0;   labyf.rt =.5;

! Redundant equation.

   ;
l.533 laboff.bot=(0,-1);   labxf.bot=.5;
  labyf.bot=1;
! Redundant equation.

   ;
l.533 ...bot=(0,-1);   labxf.bot=.5;  labyf.bot=1;

! Redundant equation.

   ;
l.534 laboff.top=(0,1);labxf.top=.5;
  labyf.top=0;
! Redundant equation.

   ;
l.534 ...top=(0,1);labxf.top=.5;  labyf.top=0;

! Redundant equation.

   ;
l.535 laboff.ulft=(-.7,.7);labxf.ulft=1;
  labyf.ulft=0;
! Redundant equation.

   ;
l.535 ...lft=(-.7,.7);labxf.ulft=1;  labyf.ulft=0;

! Redundant equation.

   ;
l.536 laboff.urt=(.7,.7);  labxf.urt=0;
  labyf.urt=0;
! Redundant equation.

   ;
l.536 ...urt=(.7,.7);  labxf.urt=0;   labyf.urt=0;

! Redundant equation.

   ;
l.537 laboff.llft=-(.7,.7);labxf.llft=1;
  labyf.llft=1;
! Redundant equation.

   ;
l.537 ...lft=-(.7,.7);labxf.llft=1;  labyf.llft=1;

! Redundant equation.

   ;
l.538 laboff.lrt=(.7,-.7); labxf.lrt=0;
  labyf.lrt=1;
! Redundant equation.

   ;
l.538 ...lrt=(.7,-.7); labxf.lrt=0;   labyf.lrt=1;

) (/usr/share/texlive/texmf-dist/metapost/context/base/mpii/mp-tool.mpii)
(/usr/share/texlive/texmf-dist/metapost/context/base/mpii/mp-spec.mpii)
(/usr/share/texlive/texmf-dist/metapost/context/base/mpii/mp-core.mpii)
(/usr/share/texlive/texmf-dist/metapost/context/base/mpii/mp-page.mpii)
(/usr/share/texlive/texmf-dist/metapost/context/base/mpii/mp-text.mpii)

Bug#1070130: python3-pycurl: SSL path issues - upstream bug

[info]

Package: python3-pycurl
Version: 7.45.3-2
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

Please consider

https://github.com/pycurl/pycurl/issues/834
pycurl 7.45.3 wheel not working for https in debian/ubuntu systems

I confirm that the debian package for 7.45.3 fails sometimes to handle SSL 
connections,
meanwhile 7.45.2 works properly always.

Mabye it can be manually patched, or skip version 7.45.3 for debian.

Thanks,



-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (650, 'stable-security'), (600, 'stable'), 
(500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'unstable'), (250, 
'oldstable-security'), (200, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages python3-pycurl depends on:
ii  libc62.37-18
ii  libcurl4t64  8.7.1-3
ii  libssl3t64   3.2.1-3
ii  python3  3.11.8-1

python3-pycurl recommends no packages.

Versions of packages python3-pycurl suggests:
pn  libcurl4-openssl-dev  
pn  python-pycurl-doc 

-- no debconf information

Bug#1070129: ITP: python3-web-cache -- Simple Python key-value storage backed up by sqlite3 database

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python3-web-cache
  Version : 1.1.0
  Upstream Contact: https://github.com/desbma
* URL : https://github.com/desbma/web_cache/
* License : LGPL-2.1
  Programming Lang: Python
  Description : Simple Python key-value storage backed up by sqlite3 
database

Python module for simple key-value storage backed up by sqlite3 database. The 
typical use case is a URL to HTTP data cache, but it can also be used for non 
web ressources.
Features

Simple dict interface allows natural usage (if key in cache, value = 
cache[key], etc.)
Optional Zlib (deflate), BZIP2, LZMA or ZSTD (Zstandard) compression, with 
configurable compression level
FIFO or LRU cache eviction strategies
Optional thread safe interface to work around Python Sqlite3 'same thread' 
limitation
Provides cache hit rate statistics



dependency of sacad (#1057152)

Bug#1067077: frr: FTBFS on armel: /usr/bin/ld: ./build/../bgpd/bgp_io.c:476:(.text+0x51c): undefined reference to `__atomic_store_8'

[David Lamparter]

On Mon, Apr 29, 2024 at 06:05:08PM +0200, Daniel Baumann wrote:
> my initial attempt in 10.0-0.2 to link with libatomic didn't work, I've 
> fixed that locally but a build to confirming on an armel porterbox is 
> runnning before uploading 10.0-0.3 in some minutes..

I've synced in (all of) your changes, merged debian/ changes from
upstream (used to build CI packages), and then flipped libatomic to be
linked unconditionally.  I was able to reproduce the linking problem
with "sbuild --host=armel --build=amd64", it wasn't working before and
is working now.  (And linking libatomic didn't break amd64, i686 or arm64.)
=> https://github.com/FRRouting/frr/commits/debian/master/

Do you want to do anything else with it or should I go mark it as -1?

Cheers,
-equi

Bug#1065688: python-jwcrypto: CVE-2024-28102

[Steve McIntyre]

Hi!

On Fri, Mar 08, 2024 at 10:42:40PM +0100, Salvatore Bonaccorso wrote:
>Source: python-jwcrypto
>Version: 1.5.4-1
>Severity: important
>Tags: security upstream
>X-Debbugs-Cc: car...@debian.org, Debian Security Team 
>
>
>Hi,
>
>The following vulnerability was published for python-jwcrypto.
>
>CVE-2024-28102[0]:
>| JWCrypto implements JWK, JWS, and JWE specifications using python-
>| cryptography. Prior to version 1.5.6, an attacker can cause a denial
>| of service attack by passing in a malicious JWE Token with a high
>| compression ratio. When the server processes this token, it will
>| consume a lot of memory and processing time. Version 1.5.6 fixes
>| this vulnerability by limiting the maximum token length.

We wanted this fixed in Pexip, so I've taken a look at this bug.

The upstream bugfix just needs a small rework so it applies cleanly to
the version in bookworm. Here's a debdiff for that that in case it's
useful.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...
diff -Nru python-jwcrypto-1.1.0/debian/changelog 
python-jwcrypto-1.1.0/debian/changelog
--- python-jwcrypto-1.1.0/debian/changelog  2022-03-29 08:33:50.0 
+0100
+++ python-jwcrypto-1.1.0/debian/changelog  2024-04-26 17:18:31.0 
+0100
@@ -1,3 +1,10 @@
+python-jwcrypto (1.1.0-1+deb12u1) unstable; urgency=medium
+
+  * Apply and tweak upstream security fix for CVE-2024-28102
+Address potential DoS with high compression ratio
+
+ -- Steve McIntyre   Fri, 26 Apr 2024 17:18:31 +0100
+
 python-jwcrypto (1.1.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch 
python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch
--- python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch   1970-01-01 
01:00:00.0 +0100
+++ python-jwcrypto-1.1.0/debian/patches/CVE-2024-28102.patch   2024-04-26 
17:18:31.0 +0100
@@ -0,0 +1,72 @@
+commit 90477a3b6e73da69740e00b8161f53fea19b831f
+Author: Simo Sorce 
+Date:   Tue Mar 5 16:57:17 2024 -0500
+
+Address potential DoS with high compression ratio
+
+Fixes CVE-2024-28102
+
+Signed-off-by: Simo Sorce 
+
+Index: os-python-jwcrypto/jwcrypto/jwe.py
+===
+--- os-python-jwcrypto.orig/jwcrypto/jwe.py
 os-python-jwcrypto/jwcrypto/jwe.py
+@@ -9,6 +9,9 @@ from jwcrypto.common import base64url_de
+ from jwcrypto.common import json_decode, json_encode
+ from jwcrypto.jwa import JWA
+ 
++# Limit the amount of data we are willing to decompress by default.
++default_max_compressed_size = 256 * 1024
++
+ 
+ # RFC 7516 - 4.1
+ # name: (description, supported?)
+@@ -387,6 +390,10 @@ class JWE:
+ 
+ compress = jh.get('zip', None)
+ if compress == 'DEF':
++if len(data) > default_max_compressed_size:
++raise InvalidJWEData(
++'Compressed data exceeds maximum allowed'
++'size' + f' ({default_max_compressed_size})')
+ self.plaintext = zlib.decompress(data, -zlib.MAX_WBITS)
+ elif compress is None:
+ self.plaintext = data
+Index: os-python-jwcrypto/jwcrypto/tests.py
+===
+--- os-python-jwcrypto.orig/jwcrypto/tests.py
 os-python-jwcrypto/jwcrypto/tests.py
+@@ -1716,6 +1716,32 @@ class ConformanceTests(unittest.TestCase
+ check.decrypt(key)
+ self.assertEqual(check.payload, b'plain')
+ 
++def test_jwe_decompression_max(self):
++key = jwk.JWK(kty='oct', k=base64url_encode(b'A' * (128 // 8)))
++payload = '{"u": "' + "u" * 4 + '", "uu":"' \
+++ "u" * 4 + '"}'
++protected_header = {
++"alg": "A128KW",
++"enc": "A128GCM",
++"typ": "JWE",
++"zip": "DEF",
++}
++enc = jwe.JWE(payload.encode('utf-8'),
++  recipient=key,
++  protected=protected_header).serialize(compact=True)
++with self.assertRaises(jwe.InvalidJWEData):
++check = jwe.JWE()
++check.deserialize(enc)
++check.decrypt(key)
++
++defmax = jwe.default_max_compressed_size
++jwe.default_max_compressed_size = 10
++# ensure we can eraise the limit and decrypt
++check = jwe.JWE()
++check.deserialize(enc)
++check.decrypt(key)
++jwe.default_max_compressed_size = defmax
++
+ 
+ class JWATests(unittest.TestCase):
+ def test_jwa_create(self):
diff -Nru python-jwcrypto-1.1.0/debian/patches/series 
python-jwcrypto-1.1.0/debian/patches/series
--- python-jwcrypto-1.1.0/debian/patches/series 1970-01-01 01:00:00.0 
+0100
+++ python-jwcrypto-1.1.0/debian/patches/series 2024-04-26 17:18:31.0 

Bug#1070127: rss2email: update of upstream version

[info]

Package: rss2email
Version: 1:3.13.1-3
Severity: wishlist
Tags: upstream

Dear Maintainer,

The debian webpage
https://packages.debian.org/buster/amd64/rss2email
references into https://github.com/wking/rss2email as the "homepage" of the 
project,
this github project references, https://pypi.org/project/rss2email/ as the 
project website,

But this last one references https://github.com/rss2email/rss2email as the 
current project website,

Please update to https://github.com/rss2email/rss2email/releases/tag/v3.14


The new option "Add a new `subject-format` setting, customise the subject line" 
looks quite interesting.

Thanks,



-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (650, 'stable-security'), (600, 'stable'), 
(500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'unstable'), (250, 
'oldstable-security'), (200, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages rss2email depends on:
ii  python3 3.11.8-1
ii  python3-feedparser  6.0.10-1
ii  python3-html2text   2024.2.26-1

Versions of packages rss2email recommends:
ii  python3-bs4  4.12.3-1

Versions of packages rss2email suggests:
pn  esmtp  

-- no debconf information

Bug#1068951: new upstream (6.x)

[Jakub Ružička]

On 4/29/24 21:13, Daniel Baumann wrote:

On 4/29/24 19:50, Daniel Baumann wrote:
pushing to the repo requires me to be added to the salsa project.. 
would you mind adding me?


in the meantime, I've pushed to here:
https://git.progress-linux.org/users/daniel.baumann/debian/todo/knot-resolver/log/ 


Nice!

before I'll continue: what's the idea of adding knot-resolver-manager 
binary package?


I can't think of a reason why one would use kresd (knot-resolver-core) 
without the manager, and thus, would fold knot-resolver-manager and 
knot-resolver-core (back) into knot-resolver. But probably I'm missing 
something..
That is a great question and in fact the primary topic I wanted some 
other DD to review. You basically answered that already, but let me 
elaborate why it's like this.


Manager was initially developed in a separate repo imported into kresd 
as a git submodule and it wasn't clear back then how integrated / 
optional / required it will be.


Manager is now quite integrated in kresd and while it's theoretically 
possible to use knot-resolver-core without knot-resolver-manager, this 
isn't officially supported and generally a use case probably not worth 
supporting.


Secondary reason for that was that there is no upgrade path from 5.x to 
6.x so it's unwanted for knot-resolver 5 packages to auto-update to 6.


For that, the package probably needs a different name (like 
knot-resolver6) so I made this little trick of moving knot-resolver to 
knot-resolver-core and added manager to knot-resolver-manager with 
Provides: knot-resolver6. That way no upgrade is triggered as there is 
no knot-resolver package in 6.0.


However, this is probably just unneeded complexity - I guess the 
packages could or even should be merged.


So what do you suggest? Merging -manager and -core into knot-resolver6? 
Or is there a way to prevent upgrade without changing package name?



Cheers,
Jakub


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1070069: fossil: CVE-2024-24795 unreleated breakage

[Bastien Roucariès]

Le mardi 30 avril 2024, 14:56:07 UTC Barak A. Pearlmutter a écrit :
> I've uploaded a package with this fixed to unstable, 1:2.24-5, and
> it's been autobuilt and pushed out. Seems to work okay, and can be
> co-installed with apache2/sid.
> 
> Just uploaded 1:2.24-6 that adds Breaks: apach2-bin per your recent message.
> 
> Honestly, I'm not confident in my ability to properly back-port
> security-related patches to old versions of fossil. It's a big
> network-facing program with a large number of moving parts and a
> substantial attack surface, all written in C. It uses its own sqlite3
> copy when the shared library in Debian isn't a high enough version or
> doesn't have the right options enabled (currently Debian sqlite3 is
> compiled without SQLITE_ENABLE_JSON1 so the internal version is used.)
> All this means it would be super easy for me to miss some issue and
> introduce a vulnerability if I try to back-port a security patch,
> > particularly without myself deeply understanding the security issue.
> 
> Stable has 1:2.21-1.
> 
> I just made a debian-bookworm-proposed-updates branch rooted there and
> tried to cherry-pick the fix,
> https://fossil-scm.org/home/info/f4ffefe708793b03 but it does not
> apply cleanly. Obviously I can do it manually though, however there
> have been changes in the neighborhood.
> 
> Also, are you *sure* I shouldn't also be applying
> https://fossil-scm.org/home/info/71919ad1b542832c to the fixed
> versions? Because I'm not! I'd be most comfortable if upstream simply
> made a proper release with this fixed (which I bet they'd do upon
> request), and I uploaded that with the appropriate "Breaks:
> apache2-bin (<<...)", and did the (trivial) backport of that package
> to bookworm and bullseye, with the "breaks:" modified to the
> appropriate version.

I agree with you, may be a fullbackport is better for bookworm see changes here 
(line with * are interesting commit to backport)

Yadd do you have a piece of advice ?

Bastien

2024-04-22

*16:29  
cgi.md: be less specific about the Apache version in which the 
Content-Length change happened because a new forum post reports that it happens 
at least as far back as 2.4.41. ...
2024-04-21

18:51   
Merge the update to zLib-1.3.1. ...
18:46   
Improvements to comments in graph.c. No changes to actual code. ...
*16:20  
Fix parsing of the argument to the "Connection:" header of HTTP reply 
messages to deal with unusual arguments added by Apache mod_cgi. See forum 
thread ca6fc85c80f4704f. ...
*15:37  
Simplify parsing of the Connection: header in HTTP replies. ...
*06:15  
Only accept commas as separators for multiple values in "Connection:" 
HTTP headers, and ignore any white space surrounding (but not embedded into) 
values. The previous method would fall for (fictional) HTTP header values 
containing spaces, like "Connection: don't close", and recognize a value of 
"close". ...
2024-04-20

21:58   
In /chat preview mode, apply the click handlers to pikchrs in the 
preview. ...
*14:42  
Fix parsing of "Connection:" HTTP headers with multiple values. ...
2024-04-19

16:08   
Fix a minor problem in graph layout for timelines that made use of the 
offset-merge-riser enhancement. Problem originally seen on the bottom node of 
/timeline?p=6da255034b30b4b4=47362306a7dd7c6f. ...
*13:11  
More change-log enhancements: More details about the work-around for 
the Apache mod_cgi breakage, and put that work-around first on the change log 
since it seems to be important to people. ...
12:59   
Formatting enhancements to the change log for the upcoming 2.24 
release. ...
2024-04-18

17:14   
Update the built-in SQLite to the latest pre-release of version 3.46.0, 
including the bug fix for the use of VALUES-as-coroutine with an OUTER JOIN. ...
17:00   
Typo fix and add specific Apache version number to the notes about the 
Content-Length change. ...
2024-04-17

17:59   
Change log updates. ...
*15:30  • Edit [18d76fff]: Edit check-in comment. ...
*14:02  
Output a warning if a client sync or clone gets back a keep-alive HTTP 
reply that lacks a content-length header. ...
*13:27  
Only process HTTP replies that lack a Content-Length header if the 
connection is set to be closed. Suggested by 
https://bz.apache.org/bugzilla/show_bug.cgi?id=68905. ...
*13:21  
Update the change log in order to mention the Apache 
mod_cgi/Content-Length fix. ...
*13:14  
Update Apache mod_cgi/Content-Length documentation. ...
*12:58  
Fix the HTTP-reply parser so that it is able to deal with replies that 
lack a Content-Length header field. This resolves the issue reported by forum 
post 12ac403fd29cfc89. Also in this merge: (1) Add the --xverbose option to 
"fossil clone". (2) Improved error messages when web 

Bug#1070111: mini-buildd wishlist: configurable periodic jobs (or: don't keep complete build results for a full year)

[Stephan Sürken]

Hi Magnus,

On Tue, 2024-04-30 at 11:40 +0200, Magnus Holmgren wrote:
> Package: mini-buildd
> Severity: wishlist

> coded. Perhaps you've already planned to add some configurability in the 
> future, but more specifically I'd like to talk about the "Expire

no imminent plans to make cron jobs configurable, however expire times for
event and build directories are configurable in upcoming 2.2.x.

Hth!

S


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

Bug#1070069: fossil: CVE-2024-24795 unreleated breakage

[Bastien Roucariès]

Le mardi 30 avril 2024, 14:56:07 UTC Barak A. Pearlmutter a écrit :
> currently Debian sqlite3 is
> compiled without SQLITE_ENABLE_JSON1 so the internal version is used.)

On this proble could you cross check ?
>SQLITE_ENABLE_JSON1
>
>This compile-time option is a no-op. Prior to SQLite version 3.38.0 
> (2022-02-22), it was necessary to compile with this option in order to 
> include the JSON SQL functions in the build. However, beginning with SQLite 
> version 3.38.0, those functions are included by default. Use the 
> -DSQLITE_OMIT_JSON option to omit them. 

If so you could drop for bookworm (if release team is ok) and sid this embeded 
code copy

BTW I have just opened a bug and add some comment on embded code copy

Bastien


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

Bug#1070126: fossil: Do not use embded sqlite

[Bastien Roucariès]

Source: fossil
Severity: important

Dear Maintainer,

> currently Debian sqlite3 is
> compiled without SQLITE_ENABLE_JSON1 so the internal version is used.)

On this proble could you cross check ?
>SQLITE_ENABLE_JSON1
>
>This compile-time option is a no-op. Prior to SQLite version 3.38.0
(2022-02-22), it was necessary to compile with this option in order to include
the JSON SQL functions in the build. However, beginning with SQLite version
3.38.0, those functions are included by default. Use the -DSQLITE_OMIT_JSON
option to omit them.

If so you could drop for bookworm (if release team is ok) and sid this embeded
code copy

Bastien


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

Bug#1070119: gnome-remote-desktop: missing gnome-remote-desktop user setup in salsa upcoming 46 version

[Jeremy Bícha]

On Tue, Apr 30, 2024 at 11:29 AM Alban Browaeys  wrote:
> So I did not mean mixinf gnome-shell/gnome-remote-desktop version. My
> interest was into connection via RDP to a not unlocked or already
> opened remote Gnome Shell.
>
> As of now I us the "Allow Locked Remote Desktop" extension and gdm3
> autologin on the remote gnome shell user session.
> I would like to get rid of these hacks (especially since I have to set
> an empty password on my gnome keyring for such a setup).

Well you'll also need gnome-control-center built without the "revert
the remote desktop changes" patch.

Our priority is to get the t64 transitions migrated to Testing, then
upload GNOME Shell 46 to Unstable (with Release Team permission). The
Debian GNOME team may not have time or interest in maintaining two
versions of gnome-control-center for people trying to use Remote Login
right now.

Thank you,
Jeremy Bícha

Bug#1069063: distro-info: Please support distro-info --alias=trixie -r

[Benjamin Drung]

On Tue, 2024-04-30 at 15:38 +, Bastien Roucariès wrote:
> Le mardi 30 avril 2024, 15:24:11 UTC Benjamin Drung a écrit :
> > Hi,
> > 
> > On Mon, 2024-04-15 at 18:58 +, Bastien Roucariès wrote:
> > > Package: distro-info
> > > Version: 1.7
> > > Severity: minor
> > > 
> > > Dear Maintainer,
> > > 
> > > distro-info --alias=trixie -r is misleading it return trixie instead of 
> > > 13...
> > > 
> > > Maybe a feature but should be documented
> > > 
> > > I workarround by doing in my script in two steps:
> > > distro-info --$(distro-info --alias=trixie) -r
> > 
> > --alias was not developed to be combined with -c/-r/-f. So either
> > distro-info should reject this parameter combination or change the
> > behaviour to what you wanted to do.
> > 
> > 
> Yes that is the bug, with additionnally a documentation bug.

What I forgot to mention: Merge requests on
https://salsa.debian.org/debian/distro-info are welcome.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1069890: Resignation & call for votes to elect the Chair

[Helmut Grohne]

On Tue, Apr 30, 2024 at 11:09:26AM +0100, Matthew Vernon wrote:
> > ===BEGIN
> > 
> > A: Christoph Berg 
> > B: Matthew Garrett 
> > C: Helmut Grohne 
> > D: Stefano Rivera 
> > E: Timo Röhling 
> > F: Craig Small 
> > G: Matthew Vernon 
> > H: Sean Whitton 
> > 
> > ===END
> 
> I vote H > A = B = C = D = E = G > F
> 
> If no-one else wants to be chair when Sean leaves, I'd be willing to do so.

Thanks for volunteering. I prefer having a longer hand-over period over
a shorter one. Therefore, I change my earlier vote on this matter to the
following assuming that you are also volunteering now already.

G > H > AB > CDE > F

Helmut


signature.asc
Description: PGP signature

Bug#1069065: gcc-14: should -for-host builds move from cross-toolchain build to DEB_STAGE=rtlibs?

[Helmut Grohne]

On Mon, Apr 15, 2024 at 06:10:16PM +0200, Helmut Grohne wrote:
> In any case, I looked into prototyping this suggested move as a patch to
> the gcc packaging. I am attaching a proof-of-concept of this, but I'm
> not particularly fond of it as it noticeably increases the packaging
> complexity. I am adding a lot of "addons" and pull a bit of code from
> various debian/rules.d/binary-*.mk to a new
> debian/rules.d/binary-forhost.mk such that prefixes that were only used
> in a particular file are now spread to multiple. For instance, all
> ?_gdc_* variables were contained in debian/rules.d/binary-d.mk earlier
> and are now spread out to debian/rules.d/binary-forhost.mk. This move is
> rooted in the fact that inclusion of debian/rules.d/binary-*.mk is
> conditionalized.
> 
> So initially, I am more interested in figuring out whether this is the
> right direction and as a secondary question conditional to the answer of
> the first, how to improve the patch to make that work.

I have added this patch to rebootstrap now and it has generally improved
bootstrapping. In particular, gcc-N-for-host is practically
coinstallable. I am more and more convinced that this is the right
direction. Do you have fundamental objections? Do you see ways to
improve the patch?

Helmut

Bug#1069063: distro-info: Please support distro-info --alias=trixie -r

[Bastien Roucariès]

Le mardi 30 avril 2024, 15:24:11 UTC Benjamin Drung a écrit :
> Hi,
> 
> On Mon, 2024-04-15 at 18:58 +, Bastien Roucariès wrote:
> > Package: distro-info
> > Version: 1.7
> > Severity: minor
> > 
> > Dear Maintainer,
> > 
> > distro-info --alias=trixie -r is misleading it return trixie instead of 
> > 13...
> > 
> > Maybe a feature but should be documented
> > 
> > I workarround by doing in my script in two steps:
> > distro-info --$(distro-info --alias=trixie) -r
> 
> --alias was not developed to be combined with -c/-r/-f. So either
> distro-info should reject this parameter combination or change the
> behaviour to what you wanted to do.
> 
> 
Yes that is the bug, with additionnally a documentation bug.

Bastien


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

Bug#1070125: dmucs FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: dmucs
Version: 0.6.1+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

dmucs fails to cross build from source, because it uses the build
architecture compiler. override_dh_auto_configure now invokes
./configure without passing --host and hence configure uses the wrong
compiler. Moreover, the upstream build system fails to forward the
detected compiler to the COSMIC subdirectory. I'm attaching a patch to
fix both for your convenience.

Helmut
diff -Nru dmucs-0.6.1+dfsg/debian/changelog dmucs-0.6.1+dfsg/debian/changelog
--- dmucs-0.6.1+dfsg/debian/changelog   2024-04-22 02:19:52.0 +0200
+++ dmucs-0.6.1+dfsg/debian/changelog   2024-04-30 13:31:33.0 +0200
@@ -1,3 +1,11 @@
+dmucs (0.6.1+dfsg-2) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: (Closes: #-1)
++ Pass --host to configure.
++ cross.patch: Forward CC to COSMIC subdir.
+
+ -- Helmut Grohne   Tue, 30 Apr 2024 13:31:33 +0200
+
 dmucs (0.6.1+dfsg-1) unstable; urgency=medium
 
   * QA upload.
diff -Nru dmucs-0.6.1+dfsg/debian/patches/cross.patch 
dmucs-0.6.1+dfsg/debian/patches/cross.patch
--- dmucs-0.6.1+dfsg/debian/patches/cross.patch 1970-01-01 01:00:00.0 
+0100
+++ dmucs-0.6.1+dfsg/debian/patches/cross.patch 2024-04-30 13:31:33.0 
+0200
@@ -0,0 +1,19 @@
+--- dmucs-0.6.1+dfsg.orig/COSMIC/Makefile
 dmucs-0.6.1+dfsg/COSMIC/Makefile
+@@ -29,7 +29,7 @@
+ # One may also start up the PortMaster (Spm -f firewallfilename).
+ # Please read the documentation on this.
+ 
+-CC = cc
++CC ?= cc
+ 
+ OBJ = Saccept.o  Sprintf.o  Stest.ooutofmem.o \
+   Sclose.o   Sprtskt.o  Stimeoutwait.o rdcolor.o  \
+--- dmucs-0.6.1+dfsg.orig/Makefile.am
 dmucs-0.6.1+dfsg/Makefile.am
+@@ -1,3 +1,5 @@
++export CC
++
+ SUBDIRS = COSMIC
+ 
+ bin_PROGRAMS = gethost loadavg monitor remhost
diff -Nru dmucs-0.6.1+dfsg/debian/patches/series 
dmucs-0.6.1+dfsg/debian/patches/series
--- dmucs-0.6.1+dfsg/debian/patches/series  2024-04-20 05:31:05.0 
+0200
+++ dmucs-0.6.1+dfsg/debian/patches/series  2024-04-30 13:31:33.0 
+0200
@@ -3,3 +3,4 @@
 03_gcc-7.patch
 40_reproducible.patch
 50_fix-FTBS-GCC-13.patch
+cross.patch
diff -Nru dmucs-0.6.1+dfsg/debian/rules dmucs-0.6.1+dfsg/debian/rules
--- dmucs-0.6.1+dfsg/debian/rules   2024-04-22 02:09:44.0 +0200
+++ dmucs-0.6.1+dfsg/debian/rules   2024-04-30 13:31:30.0 +0200
@@ -3,11 +3,13 @@
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 export DEB_CFLAGS_MAINT_APPEND = -Wall
 
+include /usr/share/dpkg/architecture.mk
+
 override_dh_auto_install:
cp -a remhost addhost
 
 override_dh_auto_configure:
-   ./configure
+   ./configure --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE)
 
 override_dh_clean:
dh_clean

Bug#1070124: gpm FTBFS: -Werror=implicit-function-declaration makes missing #includes fatal

[Helmut Grohne]

Source: gpm
Version: 1.20.7-11
Severity: important
Tags: ftbfs patch
User: helm...@debian.org
Usertags: rebootstrap

We recently made -Werror=implicit-function-declaration the default.
Unfortunately src/daemon/old_main.c is missing some crucial #includes
and that makes the build fail in some configurations. It notably misses:

 *  for strcmp, strcpy and strerror
 *  for bzero

I'm attaching a patch for your convenience.

Helmut
--- gpm-1.20.7.orig/src/daemon/old_main.c
+++ gpm-1.20.7/src/daemon/old_main.c
@@ -19,6 +19,8 @@
  *
  /
 
+#include  /* str*  */
+#include /* bzero */
 #include  /* UNIX  */
 #include  /* SOCKET*/
 #include   /* open  */

Bug#1070123: attr FTBFS: -Werror=implicit-function-declaration triggers on basefile for missing libgen.h

[Helmut Grohne]

Source: attr
Version: 1:2.5.2-1
Severity: important
Tags: ftbfs patch
User: helm...@debian.org
Usertags: rebootstrap

attr may fail to build from source with
-Werror=implicit-function-declaration due to using basename without
including libgen.h. I'm attaching a patch for your convenience.

Helmut
--- attr-2.5.2.orig/tools/attr.c
+++ attr-2.5.2/tools/attr.c
@@ -18,6 +18,7 @@
 
 #include "config.h"
 
+#include 
 #include 
 #include 
 #include 

Bug#1070119: gnome-remote-desktop: missing gnome-remote-desktop user setup in salsa upcoming 46 version

[Alban Browaeys]

Le mardi 30 avril 2024 à 10:37 -0400, Jeremy Bícha a écrit :
> > I believe the bug is import as it prevents opening a new desktop
> > session
> > (but it still works when connection to an existing session).
> 
> Yes, I've bumped the severity but what do you mean about connecting
> to
> an existing session? It's not intended to run, for instance,
> gnome-remote-desktop 45 with gnome-shell 46 or with gnome-shell 44
> but
> I guess the package dependencies aren't set quite that strict.
> 

I meant that as of GS 46 we should be able to login via RDP even if no
gnome shell session is opened (or so I understood). I believe the
system daemon is required for that.
I am also interested in being able to login to a locked gnome shell
session, which as far as I understand is possible with gnome shell 46.

So I did not mean mixinf gnome-shell/gnome-remote-desktop version. My
interest was into connection via RDP to a not unlocked or already
opened remote Gnome Shell.

As of now I us the "Allow Locked Remote Desktop" extension and gdm3
autologin on the remote gnome shell user session.
I would like to get rid of these hacks (especially since I have to set
an empty password on my gnome keyring for such a setup).

Cheers,
Alban

Bug#1067660: wireplumber: Wireplumber 0.5.0 breaks asahi-audio 1.x

[Andreas Henriksson]

Hello Dylan,

On Mon, Apr 29, 2024 at 11:53:50AM +0200, Dylan Aïssi wrote:
> Hello,
> 
> Le dim. 31 mars 2024 à 15:41, Andreas Henriksson  a écrit :
> >
> > PLEASE NOTIFY US WHEN YOU UPLOAD wireplumber 0.5.x to UNSTABLE, so we
> > can do a coordinated transition (uploading asahi-audio 2.x to unstable).
> > (You might also want to contact release-team to set up a transition
> > tracker, even if this might not be a normal transition where binNMUs are
> > useful etc.)
> >
> 
> The autogenerated tracker for transition was removed (don't know why).
> I asked for a new one (#1070043). The only other package (waybar)
> affected by this transition has now a compatible version in unstable.

We now have asahi-audio 2.x in experimental. Please poke us again when
we should upload to unstable (or feel free to NMU asahi-audio to
unstable when you upload wireplumber 0.5.x to unstable).

> So, I think except the t64 transition nothing else is blocking, I am
> waiting the green light from the release team for next step, and I
> will ping here before uploading wireplumber 0.5 in unstable.
> 
> Best regards,
> Dylan

Regards,
Andreas Henriksson

Bug#1069063: distro-info: Please support distro-info --alias=trixie -r

[Benjamin Drung]

Hi,

On Mon, 2024-04-15 at 18:58 +, Bastien Roucariès wrote:
> Package: distro-info
> Version: 1.7
> Severity: minor
> 
> Dear Maintainer,
> 
> distro-info --alias=trixie -r is misleading it return trixie instead of 13...
> 
> Maybe a feature but should be documented
> 
> I workarround by doing in my script in two steps:
> distro-info --$(distro-info --alias=trixie) -r

--alias was not developed to be combined with -c/-r/-f. So either
distro-info should reject this parameter combination or change the
behaviour to what you wanted to do.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1070121: nmu: coreutils_9.4-3 (trixie), pam_1.5.2-9.1 (trixie)

[Sebastian Ramacher]

On 2024-04-30 15:44:51 +0100, Simon McVittie wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> X-Debbugs-Cc: coreut...@packages.debian.org, p...@packages.debian.org, 
> debian-b...@lists.debian.org
> Control: affects -1 + src:coreutils src:pam
> 
> coreutils_9.4-3.1 and pam_1.5.3-7 aren't currently migrating to trixie
> for whatever reason. Because debootstrap doesn't currently know about
> versioned Provides, I think it would be useful to get versions of these
> packages in trixie that have been rebuilt against the 64-bit time_t ABIs
> and package names.
> 
> If the versions in trixie don't migrate imminently, please consider:
> 
> nmu coreutils_9.4-3 . ANY . trixie . -m "rebuild against libssl3t64"
> nmu pam_1.5.2-9.1 . ANY . trixie . -m "rebuild against libdb5.3t64"
> 
> In a trixie derivative (a non-public future branch of the Steam Runtime)
> I found that local rebuilds of those two source packages were enough to
> bring a minbase debootstrap back from repeatably failing to reasonably
> reliable. I hope they would have a similar effect in real trixie.
> 
> Based on kibi's thread "Making trixie debootstrap-able again?" on -release
> and -boot, binNMUing util-linux and iproute2 might also help for d-i's
> use-case, which is larger than minbase and wants fdisk and iproute2:
> 
> nmu util-linux_2.39.3-6 . ANY . trixie . -m "rebuild against libreadline8t64"
> nmu iproute2_6.7.0-2 . ANY . trixie . -m "rebuild against libtirpc3t64"
> 
> but I have not independently verified that those two are necessary
> or sufficient.

The packages would be ready to migrate to trixie, but migrating them
makes britney crash. I don't expect that to change when we rebuild the
packages in trixie.

Cheers
-- 
Sebastian Ramacher

Bug#1070120: postfix: can't send mail due to obsolete /var/spool/postfix/etc/resolv.conf on new network

[Bastien Roucariès]

Le mardi 30 avril 2024, 14:52:46 UTC Vincent Lefevre a écrit :
Hi,

> Control: tags -1 security
> 
> On 2024-04-30 16:33:14 +0200, Vincent Lefevre wrote:
> > If I try to restart postfix, I get:
> > 
> > postfix/postfix-script: warning: /var/spool/postfix/etc/resolv.conf and 
> > /etc/resolv.conf differ

A solution may be to bind mount ro /etc/resolv.conf to 
/var/spool/postfix/etc/resolv.conf

Bastien
> 
> BTW, note that this is a security issue, because with wifi,
> the DNS server often corresponds to the local router (e.g.
> 10.3.0.1), and it may happen that the obsolete IP address
> may correspond to some random machine on the network, which
> could act as a malicious DNS server.
> 
> > Indeed, /var/spool/postfix/etc/resolv.conf contains obsolete data.
> > 
> > I had to do "cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf".
> 
> I don't know how the update should be done. I suppose that
> /etc/network/if-up.d/postfix is pointless in case of wifi as
> it says "Called when a new interface comes up", but for wifi,
> this is the same interface, only a new network.
> 
> And I don't understand why restarting postfix did not update
> the file.
> 
> BTW, even ethernet connections may be affected in case of
> network reconfiguration.
> 
> 



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

Bug#1070122: apt-cache rdepends with an exact match name

[Patrice Duroux]

Package: apt
Version: 2.9.2
Severity: wishlist

Dear Maintainer,

Could there be a possibility (by default or with an option) to not get result
like:

$ apt rdepends libaio1
libaio1
Reverse Depends:
  Depends: libaio-dev (= 0.3.112-9)
  Depends: qemu-utils (>= 0.3.93)
  Depends: qemu-system-x86 (>= 0.3.93)
  Depends: qemu-system-sparc (>= 0.3.93)
  Depends: qemu-system-ppc (>= 0.3.93)
  Depends: qemu-system-misc (>= 0.3.93)
  Depends: qemu-system-mips (>= 0.3.93)
  Depends: qemu-system-common (>= 0.3.93)
  Depends: qemu-system-arm (>= 0.3.93)
  Depends: zfs-test (>= 0.3.93)
  Depends: qemu-utils (>= 0.3.93)
  Depends: qemu-system-x86 (>= 0.3.93)
  Depends: qemu-system-sparc (>= 0.3.93)
  Depends: qemu-system-ppc (>= 0.3.93)
  Depends: qemu-system-misc (>= 0.3.93)
  Depends: qemu-system-mips (>= 0.3.93)
  Depends: qemu-system-common (>= 0.3.93)
  Depends: qemu-system-arm (>= 0.3.93)
  Depends: glusterfs-common (>= 0.3.93)
  Depends: zfs-test (>= 0.3.93)
  Depends: libdbd-oracle-perl
  Depends: zfs-fuse (>= 0.3.93)
  Depends: thin-provisioning-tools (>= 0.3.93)
  Depends: tgt (>= 0.3.93)
  Depends: sysbench (>= 0.3.93)
  Depends: stressapptest (>= 0.3.93)
  Depends: stenographer (>= 0.3.93)
  Depends: sbd (>= 0.3.93)
  Depends: sanlock (>= 0.3.93)
  Depends: libsanlock1 (>= 0.3.93)
  Depends: qemu-utils (>= 0.3.93)
  Depends: qemu-system-x86 (>= 0.3.93)
  Depends: qemu-system-sparc (>= 0.3.93)
  Depends: qemu-system-ppc (>= 0.3.93)
  Depends: qemu-system-misc (>= 0.3.93)
  Depends: qemu-system-mips (>= 0.3.93)
  Depends: qemu-system-common (>= 0.3.93)
  Depends: qemu-system-arm (>= 0.3.93)
  Depends: ocfs2-tools (>= 0.3.93)
  Depends: multipath-tools (>= 0.3.93)
  Depends: mariadb-test (>= 0.3.93)
  Depends: mariadb-server-core-10.5 (>= 0.3.93)
  Depends: mariadb-backup (>= 0.3.93)
  Depends: libmariadbd19 (>= 0.3.93)
  Depends: lvm2 (>= 0.3.93)
  Depends: liblvm2cmd2.03 (>= 0.3.93)
  Depends: iiod (>= 0.3.93)
  Depends: thin-provisioning-tools (>= 0.3.93)
  Depends: glusterfs-common (>= 0.3.93)
  Depends: gfio (>= 0.3.93)
  Depends: fio (>= 0.3.93)
  Depends: ceph-osd (>= 0.3.93)
  Depends: ceph-common (>= 0.3.93)
  Depends: ceph-base (>= 0.3.93)
  Depends: blktrace (>= 0.3.93)
  Depends: bcachefs-tools (>= 0.3.93)
  Recommends: libodpic4
  Depends: libdbd-oracle-perl

where most of the cases are libaio1t64 depends.

More generally, it should be more clear in the apt(-cache) manpage at least for
'pkg' versus 'regex' arguments if this is supposed to be identity or substring
matching versus a full regex matching.

Thanks,
Patrice


-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- (no /etc/apt/preferences.d/* present) --


-- (/etc/apt/sources.list present, but not submitted) --


-- (/etc/apt/sources.list.d/bouml.list present, but not submitted) --


-- (/etc/apt/sources.list.d/dbeaver.list present, but not submitted) --


-- (/etc/apt/sources.list.d/deb-multimedia.list present, but not submitted) --


-- (/etc/apt/sources.list.d/debian.list present, but not submitted) --


-- (/etc/apt/sources.list.d/google-chrome.list present, but not submitted) --


-- (/etc/apt/sources.list.d/home:tumic:GPXSee.list present, but not submitted) 
--


-- (/etc/apt/sources.list.d/liveusb.list present, but not submitted) --


-- (/etc/apt/sources.list.d/microsoft-prod.list present, but not submitted) --


-- (/etc/apt/sources.list.d/nilarimogard-ubuntu-webupd8-focal.list present, but 
not submitted) --


-- (/etc/apt/sources.list.d/signal-xenial.list present, but not submitted) --


-- (/etc/apt/sources.list.d/skype-unstable.list present, but not submitted) --


-- (/etc/apt/sources.list.d/sublime-text.list present, but not submitted) --


-- (/etc/apt/sources.list.d/teams.list present, but not submitted) --


-- (/etc/apt/sources.list.d/vivaldi.list present, but not submitted) --


-- (/etc/apt/sources.list.d/vscode.list present, but not submitted) --


-- (/etc/apt/sources.list.d/waydroid.list present, but not submitted) --


-- (/etc/apt/sources.list.d/wire-desktop.list present, but not submitted) --


-- (/etc/apt/sources.list.d/zerotier.list present, but not submitted) --


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

Kernel: Linux 6.7.12-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 apt depends on:
ii  adduser 3.137
ii  base-passwd 3.6.3
ii  debian-archive-keyring  2023.4
ii  gpgv2.2.40-3
ii  libapt-pkg6.0t642.9.2
ii  libc6   2.37-19
ii  libgcc-s1   

Bug#1070069: fossil: CVE-2024-24795 unreleated breakage

[Barak A. Pearlmutter]

I've uploaded a package with this fixed to unstable, 1:2.24-5, and
it's been autobuilt and pushed out. Seems to work okay, and can be
co-installed with apache2/sid.

Just uploaded 1:2.24-6 that adds Breaks: apach2-bin per your recent message.

Honestly, I'm not confident in my ability to properly back-port
security-related patches to old versions of fossil. It's a big
network-facing program with a large number of moving parts and a
substantial attack surface, all written in C. It uses its own sqlite3
copy when the shared library in Debian isn't a high enough version or
doesn't have the right options enabled (currently Debian sqlite3 is
compiled without SQLITE_ENABLE_JSON1 so the internal version is used.)
All this means it would be super easy for me to miss some issue and
introduce a vulnerability if I try to back-port a security patch,
particularly without myself deeply understanding the security issue.

Stable has 1:2.21-1.

I just made a debian-bookworm-proposed-updates branch rooted there and
tried to cherry-pick the fix,
https://fossil-scm.org/home/info/f4ffefe708793b03 but it does not
apply cleanly. Obviously I can do it manually though, however there
have been changes in the neighborhood.

Also, are you *sure* I shouldn't also be applying
https://fossil-scm.org/home/info/71919ad1b542832c to the fixed
versions? Because I'm not! I'd be most comfortable if upstream simply
made a proper release with this fixed (which I bet they'd do upon
request), and I uploaded that with the appropriate "Breaks:
apache2-bin (<<...)", and did the (trivial) backport of that package
to bookworm and bullseye, with the "breaks:" modified to the
appropriate version.

Bug#1065309: transition: gnat (12 -> 13 + time_t64)

[Graham Inggs]

Hi Nicholas

On Tue, 30 Apr 2024 at 12:33, Nicolas Boulenguez  wrote:
> The time_t64 transition has triggered #1067453 in the Ada compiler,
> which is now fixed by gcc-13/13.2.0-24.
>
> The patch modifies the sources of the Ada standard library, so most
> Ada packages need a rebuild in order to update their dependencies
> (gnat-13  Provides: gnat-13-HASH
>  each Ada library Provides: libFOO-dev-HASH
>  and each consumer Depends: gnat-13-HASH, libFOO-HASH).
>
> Please schedule the following rebuilds.
>
> nmu adacgi_1.6-34 . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.  Closes: #1067070.'
> dw  adacgi_1.6-34 . ANY . -m 'gnat-13 (>= 13.2.0-24)'
> nmu adasockets_1.14-1 . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.'
> dw  adasockets_1.14-1 . ANY . -m 'gnat-13 (>= 13.2.0-24)'
> nmu ahven_2.8.9   . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.  Closes: #1067224, #1069469.'
> dw  ahven_2.8.9   . ANY . -m 'gnat-13 (>= 13.2.0-24)'
> nmu libaunit_24.0.0-2 . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.  Closes: #1067071.'
> dw  libaunit_24.0.0-2 . ANY . -m 'gnat-13 (>= 13.2.0-24)'
> nmu libgmpada_1.6-2   . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.'
> dw  libgmpada_1.6-2   . ANY . -m 'gnat-13 (>= 13.2.0-24)'
> nmu libncursesada_6.3.20211021-11 . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.  Closes: #1067073.'
> dw  libncursesada_6.3.20211021-11 . ANY . -m 'gnat-13 (>= 13.2.0-24)'
> nmu libtexttools_2.1.0-28 . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.  Closes: #1069476.'
> dw  libtexttools_2.1.0-28 . ANY . -m 'gnat-13 (>= 13.2.0-24)'
> nmu libxmlada_24.0.0-2. ANY . -m 'Rebuild with #1067453 fixed in 
> gnat'
> dw  libxmlada_24.0.0-2. ANY . -m 'gnat-13 (>= 13.2.0-24)'
> nmu libxmlezout_1.06.2-14 . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.  Closes: #1067220.'
> dw  libxmlezout_1.06.2-14 . ANY . -m 'gnat-13 (>= 13.2.0-24)'
>
> nmu liblog4ada_1.3.1.b6dafb49-13  . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.  Closes: #1067074.'
> dw  liblog4ada_1.3.1.b6dafb49-13  . ANY . -m 'libxmezout-dev (>= 
> 1.06.2-14+b1)'
>
> nmu anet_0.5.0-3  . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.  Closes: #1067353.'
> dw  anet_0.5.0-3  . ANY . -m 'libahven-dev (>= 2.8.9+b1)'
> nmu dbusada_0.6.2-6   . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.  Closes: #1069421.'
> dw  dbusada_0.6-2-6   . ANY . -m 'libahven-dev (>= 2.8.9+b1)'
> nmu libalog_0.6.2-5   . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.  Closes: #1069454.'
> dw  libalog_0.6.2-5   . ANY . -m 'libahven-dev (>= 2.8.9+b1)'
> nmu pcscada_0.7.7-6   . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.  Closes: #1069468.'
> dw  pcscada_0.7.7-6   . ANY . -m 'libahven-dev (>= 2.8.9+b1)'
>
> nmu libtemplates-parser_24.0.0-2  . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.'
> dw  libtemplates-parser_24.0.0-2  . ANY . -m 'libxmlada-unicode-dev (>= 
> 24.0.0-2+b1)'
> nmu gprbuild_2024.1.20231009-4. ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.  Closes: #1069467.'
> dw  gprbuild_2024.1.20231009-4. ANY . -m 'libxmlada-unicode-dev (>= 
> 24.0.0-2+b1)'
>
> nmu libgnatcoll_24.1.20230921-4   . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.'
> dw  libgnatcoll_24.1.20230921-4   . ANY . -m 'libgnatprj-dev (>= 
> 2024.1.20231009-4+b1)'
>
> nmu libgnatcoll-bindings_24.0.0-2 . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.'
> dw  libgnatcoll-bindings_24.0.0-2 . ANY . -m 'libgnatcoll-dev (>= 
> 24.1.20230921-4+b1)'
>
> nmu libgnatcoll-db_23.0.0-6   . ANY . -m 'Rebuild with #1067453 fixed in 
> gnat.'
> dw  libgnatcoll-db_23.0.0-6   . ANY . -m 'libgnatcoll-iconv-dev (>= 
> 24.0.0-2+b1)'

Scheduled, thanks, with a couple of fixed typos in versions;
ahven_2.8.9 -> 2.8-9 and  dbusada_0.6-2-6 -< 0.6.2-6.

I'll check on the buildst later to see if any additional binNMUs are
required to get the +b versions aligned.

Regards
Graham

Bug#1070120: postfix: can't send mail due to obsolete /var/spool/postfix/etc/resolv.conf on new network

[Vincent Lefevre]

Control: tags -1 security

On 2024-04-30 16:33:14 +0200, Vincent Lefevre wrote:
> If I try to restart postfix, I get:
> 
> postfix/postfix-script: warning: /var/spool/postfix/etc/resolv.conf and 
> /etc/resolv.conf differ

BTW, note that this is a security issue, because with wifi,
the DNS server often corresponds to the local router (e.g.
10.3.0.1), and it may happen that the obsolete IP address
may correspond to some random machine on the network, which
could act as a malicious DNS server.

> Indeed, /var/spool/postfix/etc/resolv.conf contains obsolete data.
> 
> I had to do "cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf".

I don't know how the update should be done. I suppose that
/etc/network/if-up.d/postfix is pointless in case of wifi as
it says "Called when a new interface comes up", but for wifi,
this is the same interface, only a new network.

And I don't understand why restarting postfix did not update
the file.

BTW, even ethernet connections may be affected in case of
network reconfiguration.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1055656: A one-liner fix needed before telegram-desktop backporting

[Boyuan Yang]

Hi all,

On Fri, 2024-04-19 at 11:39 -0400, Boyuan Yang wrote:
> Hi Nicolas,
> 
> 在 2024-04-09星期二的 10:51 +0300，Egor Duda写道：
> > Hello!
> > 
> > Any news on this one?
> > 
> > It seems that Debian maintainers gave their go-ahead on
> > https://bugs.debian.org/1055656
> > 
> > And, in any case, big thanks for all your work on maintaining
> > telegram-desktop in Debian!
> 
> While this change may now not be enough to get telegram-desktop
> backport done,
> I think we can upload this specific fix already to close this bug
> report.
> 
> If you are not having time on it, I can upload this version with the
> approved
> changes to bookworm. Just let me know whether you think it's OK.

Since this bookworm-pu has been approved by the Release Team, I am
uploading it as-is into DELAYED/7.

If anyone has any concerns, please let me know ASAP if you want to stop
the upload.

Thanks,
Boyuan Yang


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

Bug#1070121: nmu: coreutils_9.4-3 (trixie), pam_1.5.2-9.1 (trixie)

[Simon McVittie]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: coreut...@packages.debian.org, p...@packages.debian.org, 
debian-b...@lists.debian.org
Control: affects -1 + src:coreutils src:pam

coreutils_9.4-3.1 and pam_1.5.3-7 aren't currently migrating to trixie
for whatever reason. Because debootstrap doesn't currently know about
versioned Provides, I think it would be useful to get versions of these
packages in trixie that have been rebuilt against the 64-bit time_t ABIs
and package names.

If the versions in trixie don't migrate imminently, please consider:

nmu coreutils_9.4-3 . ANY . trixie . -m "rebuild against libssl3t64"
nmu pam_1.5.2-9.1 . ANY . trixie . -m "rebuild against libdb5.3t64"

In a trixie derivative (a non-public future branch of the Steam Runtime)
I found that local rebuilds of those two source packages were enough to
bring a minbase debootstrap back from repeatably failing to reasonably
reliable. I hope they would have a similar effect in real trixie.

Based on kibi's thread "Making trixie debootstrap-able again?" on -release
and -boot, binNMUing util-linux and iproute2 might also help for d-i's
use-case, which is larger than minbase and wants fdisk and iproute2:

nmu util-linux_2.39.3-6 . ANY . trixie . -m "rebuild against libreadline8t64"
nmu iproute2_6.7.0-2 . ANY . trixie . -m "rebuild against libtirpc3t64"

but I have not independently verified that those two are necessary
or sufficient.

smcv

Bug#1070115: libaio1t64: libaio1 and libaio1t64 are co-installed: is this expected?

[Patrice Duroux]

On Tue, 30 Apr 2024 15:29:15 +0200 Gianfranco Costamagna
 wrote:
> Hello,
> quoting changelog:
> [...]


So how can I install:
https://packages.debian.org/source/sid/thin-provisioning-tools
if libaio1:amd64 is no more there:
https://packages.debian.org/sid/libaio1
and libaio1t64 not providing libaoi1?

Based an daily rolling upgrade, my system still have then thin-provisioning-
tools and so the removed liabaio1.
Lets wait then for a rebuild of thin-provisioning-tools.

Sorry for the noise.
Thanks!

Bug#1070119: gnome-remote-desktop: missing gnome-remote-desktop user setup in salsa upcoming 46 version

[Jeremy Bícha]

Control: severity -1 important

On Tue, Apr 30, 2024 at 9:57 AM Alban Browaeys  wrote:
> The issue seems to be that the user gnome-remote-desktop is not existing
> thus the system wide systemd gnome-remote-desktop.service fails to
> start:

The gnome-remote-desktop user is new for gnome-remote-desktop 46. The
user ought to be created by the package and it seems to work for
Ubuntu 24.04 LTS (which uses the same packaging).

> I found no issue tracker on the salsa project for gnome-remote-desktop
> so opened the issue here.

I wouldn't open an upstream bug for this issue yet since we should
assume this is a Debian packaging issue until confirmed otherwise.

> I believe the bug is import as it prevents opening a new desktop session
> (but it still works when connection to an existing session).

Yes, I've bumped the severity but what do you mean about connecting to
an existing session? It's not intended to run, for instance,
gnome-remote-desktop 45 with gnome-shell 46 or with gnome-shell 44 but
I guess the package dependencies aren't set quite that strict.

Thank you,
Jeremy Bícha

Bug#1070077: [Pkg-privacy-maintainers] Bug#1070077: ships files directly in /usr/onionprobe

[Antoine Beaupré]

On 2024-04-30 08:25:55, Georg Faerber wrote:
> On 24-04-29 16:19:21, Antoine Beaupre wrote:
>> Package: onionprobe
>> Version: 1.0.0+ds-2.1+deb12u1
>> Severity: serious
>> 
>> The Debian package shipped in bookworm right now changed the path to
>> the examples/ directory. It used to be:
>> 
>> /usr/lib/python3/dist-packages/onionprobe/examples/tpo.py
>> 
>>  and now seems to be:
>> 
>> /usr/onionprobe/examples/tpo.py
>> 
>> Apart from the gratuitous change, this seems to be a violation of the
>> FHS policy, packages shouldn't ship their own stuff directly under
>> /usr like this...
>
> Indeed -- I wasn't aware, or probably forgot, that bookworm is affected.
> Given the severity, this might warrant a bookworm-pu, I guess?

Honestly, I'm not sure. It's relatively minor because it's just the
examples files, and the rest of the package is functional. I've patched
our puppet manifests to workaround the issue over here...

>> I haven't checked in unstable to see if this is fixed.
>
> This was reported via #1025508 and fixed in unstable via 1.1.2+ds-1.

Oh, I didn't realize that, good job! :)

-- 
It is capitalism and government which stand for disorder and
violence. Anarchism is the very reverse of it; it means order without
government and peace without violence.
- Alexander Berkman

Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common

[Vincent Lefevre]

On 2024-04-30 11:49:57 +0200, Julian Andres Klode wrote:
> This bug has since been reassigned to aptitude. Solver limitations
> in aptitude wrt t64 handling should not be considered release critical,
> it makes no sense to remove aptitude from testing for it; there are
> still plenty of other valid use cases that are unaffected by these
> particular bugs, so I am downgrading it to important.

OK, but note that this is a rather serious bug somewhere (perhaps
in aptitude, but really, I'm not sure since according to aptitude's
debug log, everything is fine on its side), not just a solver
limitation: if this were a solver limitation, aptitude would have
at least said that the upgrade was not possible because some
dependency could not be satisfied (this is what it usually does);
but this is not what happened.

In short, something attempts to remove a package that has *not*
been marked as to be removed. Fortunately, when trying to remove
the package, dpkg detects a dependency issue. But I fear, that in
some cases (e.g. when the unannounced package to be removed would
not have a dependency on it), this could potentially completely
break the system.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1070120: postfix: can't send mail due to obsolete /var/spool/postfix/etc/resolv.conf on new network

[Vincent Lefevre]

Package: postfix
Version: 3.9.0-2
Severity: important

While being connected in the train, mailq gives:

-Queue ID-  --Size-- Arrival Time -Sender/Recipient---
24FC2CA011A2232 Tue Apr 30 16:21:46  vinc...@vinc17.net
(Host or domain name not found. Name service error for name=joooj.vinc17.net 
type=: Host not found, try again)
[...]

while "host joooj.vinc17.net" gives no issues.

If I try to restart postfix, I get:

postfix/postfix-script: warning: /var/spool/postfix/etc/resolv.conf and 
/etc/resolv.conf differ

Indeed, /var/spool/postfix/etc/resolv.conf contains obsolete data.

I had to do "cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf".

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

Kernel: Linux 6.6.15-amd64 (SMP w/16 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 postfix depends on:
ii  adduser3.137
ii  cpio   2.15+dfsg-1
ii  debconf [debconf-2.0]  1.5.86
ii  dpkg   1.22.6
ii  e2fsprogs  1.47.0-2.4
ii  init-system-helpers1.66
ii  libc6  2.37-19
ii  libdb5.3t645.3.28+dfsg2-7
ii  libicu72   72.1-4+b1
ii  libnsl21.3.0-3+b2
ii  libsasl2-2 2.1.28+dfsg1-6
ii  libssl3t64 3.2.1-3
ii  netbase6.4
ii  ssl-cert   1.1.2

Versions of packages postfix recommends:
ii  ca-certificates  20240203
ii  python3  3.11.8-1

Versions of packages postfix suggests:
ii  emacs-gtk [mail-reader]   1:29.3+1-2
ii  libsasl2-modules  2.1.28+dfsg1-6
ii  mailutils [mail-reader]   1:3.17-1.1+b2
ii  mutt [mail-reader]2.2.12-0.1+b1
pn  postfix-cdb   
ii  postfix-doc   3.9.0-2
pn  postfix-ldap  
pn  postfix-lmdb  
pn  postfix-mongodb   
pn  postfix-mta-sts-resolver  
pn  postfix-mysql 
ii  postfix-pcre  3.9.0-2
pn  postfix-pgsql 
pn  postfix-sqlite
ii  procmail  3.22-27
pn  resolvconf
pn  ufw   

-- debconf information:
* postfix/mailname: qaa.vinc17.org
* postfix/root_address:
  postfix/not_configured:
* postfix/destinations: qaa.vinc17.org, 135.197.67.86.rev.sfr.net, , localhost
  postfix/relayhost:
* postfix/protocols: all
* postfix/chattr: false
  postfix/newaliases: false
* postfix/procmail: true
* postfix/recipient_delim: -
* postfix/mynetworks: 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
* postfix/main_mailer_type: Internet Site
* postfix/mailbox_limit: 0
  postfix/bad_recipient_delimiter:
  postfix/rfc1035_violation: false

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1043408: ITP: golang-github-dsnet-compress -- Collection of compression related Go packages.

[Maytham Alsudany]

Control: owner -1 !

I will be taking over this ITP and package maintenance as no response has been
received from Nisha.

Kind regards,
Maytham


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

Bug#1060075: gcc-13 FTCBFS: target system type set to nvptx-unknown-none

[Emanuele Rocca]

Control: retitle -1 gcc-13 FTCBFS: nvptx does not cross compile

On 2024-01-06 01:10, Matthias Klose wrote:
> no, the target is always nvptx-unknown-none.

Ack, but in order to cross build nvptx we probably have to set build and
host? I tried cross building gcc 13.2.0-23 on a x86 system with:

 DEB_BUILD_OPTIONS='nolang=m2' sbuild --host=arm64

And I got the following error in build-nvptx/config.log:

 configure:4591: checking whether we are cross compiling
 configure:4599: aarch64-linux-gnu-gcc-13 -o conftestconftest.c  >&5
 configure:4603: $? = 0
 configure:4610: ./conftest
 ../src-nvptx/configure: line 4612: ./conftest: cannot execute binary file: 
Exec format error

Things looked slightly better adding --build and --host to
CONFARGS_NVPTX, at least the build process went past the "checking
whether we are cross compiling" step.

diff -Nru gcc-13-13.2.0/debian/rules2 gcc-13-13.2.0/debian/rules2
--- gcc-13-13.2.0/debian/rules2 2024-03-23 13:29:34.0 +0100
+++ gcc-13-13.2.0/debian/rules2 2024-04-30 10:28:00.0 +0200
@@ -1524,7 +1524,9 @@
--enable-languages=c,c++,fortran,lto \
--enable-checking=release \
--with-system-zlib \
-   --without-isl
+   --without-isl \
+   --build=$(DEB_BUILD_GNU_TYPE) \
+   --host=$(DEB_HOST_GNU_TYPE)
 
 #  --with-build-time-tools=/$(PF)/nvptx-none/bin

However, there is still a failure later on when the nvptx Makefile tries
to run nvptx-none-gcc -dumpspecs.

GCC_FOR_TARGET is set to nvptx-none-gcc in ./build-nvptx/Makefile and
used in ./build-nvptx/gcc/Makefile, but there is no such command.

  cp xgcc gcc-cross
  nvptx-none-gcc  -dumpspecs > tmp-specs
  rm -f gfortran-cross
  /bin/bash: line 1: nvptx-none-gcc: command not found
  make[4]: *** [Makefile:2226: specs] Error 127
  make[4]: *** Waiting for unfinished jobs
  cp gfortran gfortran-cross
  rm gcc.pod gfortran.pod lto-dump.pod
  make[4]: Leaving directory '/<>/build-nvptx/gcc'
  make[3]: *** [Makefile:4622: all-gcc] Error 2
  make[3]: Leaving directory '/<>/build-nvptx'
  make[2]: *** [Makefile:1022: all] Error 2
  make[2]: Leaving directory '/<>/build-nvptx'

Any ideas welcome. Full build log at:
https://people.debian.org/~ema/gcc-13_13.2.0-23.1_arm64.build

Bug#1070119: gnome-remote-desktop: missing gnome-remote-desktop user setup in salsa upcoming 46 version

[Alban Browaeys]

Package: gnome-remote-desktop
Version: 46.1-1
Severity: normal

I believe the bug is import as it prevents opening a new desktop session
(but it still works when connection to an existing session).

The issue seems to be that the user gnome-remote-desktop is not existing
thus the system wide systemd gnome-remote-desktop.service fails to
start:
journalctl -b -u gnome-remote-desktop.service
avril 30 15:47:42 hermes systemd[1]: Starting gnome-remote-desktop.service - 
GNOME Remote Desktop...
avril 30 15:47:42 hermes (p-daemon)[855818]: gnome-remote-desktop.service: 
Failed to determine user credentials: No such process
avril 30 15:47:42 hermes systemd[1]: gnome-remote-desktop.service: Main process 
exited, code=exited, status=217/USER
avril 30 15:47:42 hermes systemd[1]: gnome-remote-desktop.service: Failed with 
result 'exit-code'.
avril 30 15:47:42 hermes systemd[1]: Failed to start 
gnome-remote-desktop.service - GNOME Remote Desktop.


Also there is an error message about being unable to create the
gnoem-remote-desktop home /var/lib/gnome-remote-desktop and
/etc/gnome-remote-desktop as user and group gnome-remote-desktop:

sudo LC_ALL=C dpkg -i gnome-remote-desktop_46.1-1_amd64.deb
(Reading database ... 728947 files and directories currently installed.)
Preparing to unpack gnome-remote-desktop_46.1-1_amd64.deb ...
Unpacking gnome-remote-desktop (46.1-1) over (46.1-1) ...
Setting up gnome-remote-desktop (46.1-1) ...
/usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf:2: Failed to resolve 
user 'gnome-remote-desktop': No such process
/usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf:3: Failed to resolve 
user 'gnome-remote-desktop': No such process
Could not execute systemctl:  at /usr/bin/deb-systemd-invoke line 148.
Processing triggers for gnome-menus (3.36.0-1.1+b2) ...
Processing triggers for desktop-file-utils (0.27-2) ...
Processing triggers for mailcap (3.70+nmu1) ...
Processing triggers for dbus (1.14.10-4+b1) ...
Processing triggers for libglib2.0-0t64:i386 (2.80.0-6) ...
Processing triggers for libglib2.0-0t64:amd64 (2.80.0-6) ...
Processing triggers for man-db (2.12.1-1) ...


/usr/lib/tmpfiles.d/gnome-remote-desktop-tmpfiles.conf
# tmpfiles.d file to ensure the existence of the home directory for 
gnome-remote-desktop user
d /var/lib/gnome-remote-desktop 0700 gnome-remote-desktop gnome-remote-desktop
d /etc/gnome-remote-desktop 0755 gnome-remote-desktop gnome-remote-desktop

indeed I have no gnome-remote-desktop user:
$ getent passwd|grep gnome


I found no issue tracker on the salsa project for gnome-remote-desktop
so opened the issue here.

Cheers
Alban

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

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

Versions of packages gnome-remote-desktop depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b2
ii  fuse33.14.0-5
ii  init-system-helpers  1.66
ii  libc62.37-19
ii  libcairo21.18.0-3+b1
ii  libei1   1.2.1-1
ii  libepoxy01.5.10-1+b2
ii  libfreerdp-server3-3 3.5.1+dfsg1-1
ii  libfreerdp3-33.5.1+dfsg1-1
ii  libfuse3-3   3.14.0-5
ii  libglib2.0-0t64  2.80.0-6
ii  libmutter-14-0   46.1-1
ii  libnotify4   0.8.3-1+b1
ii  libopus0 1.4-1+b1
ii  libpipewire-0.3-0t64 1.0.5-1+b3
ii  libpolkit-gobject-1-0124-2
ii  libsecret-1-00.21.4-1+b1
ii  libsystemd0  255.5-1
ii  libtss2-esys-3.0.2-0t64  4.0.1-7.2
ii  libtss2-mu-4.0.1-0t644.0.1-7.2
ii  libtss2-rc0t64   4.0.1-7.2
ii  libtss2-tctildr0t64  4.0.1-7.2
ii  libwinpr3-3  3.5.1+dfsg1-1
ii  libxkbcommon01.6.0-1+b1
ii  pipewire 1.0.5-1+b3
ii  wireplumber  0.4.17-1+b2

gnome-remote-desktop recommends no packages.

gnome-remote-desktop suggests no 

Bug#1070074: several errors on tab completion

[Alban Browaeys]

Package: bash-completion
Followup-For: Bug #1070074

I doubt this issue is related to util-linux-extra being too old.

I had a similar error while pressing "sudo" I got the error:
"sudo bash: _comp_initialize : commande introuvable"
ie "commande introuvable" is "command not found".

It turned out that this error only happens in bash shell I had opened
before the upgrade (the fact you had the issue opening new bash shell is
awakward to me). The bash shell I opened after were fine.

Note the _comp_deprecate_var, _comp_xxx functions are defined in 
/usr/share/bash-completion/bash_completion
which is part of the bash-completion package, so upgrading
util-linux-extra can have no effect on them being present or not.

From the error I got above I guess bash completion 
/usr/share/bash-completion/completions/*
might get source anew after upgrade while the
/usr/share/bash-completion/bash-completion common function definition
file is not.
A way to workaround this issue would be to source this file in existing
bash shells: "source /usr/share/bash-completion/bash_completion" indeed
fixed my shell with broken "sudo" and missing _comp_initialize
command.

I see no easy fix as as far as I know, the 
/usr/share/bash-completion/bash_completion
is imported when the bash shell is started (profile file or bashrc) but it 
seems the
completion files can be source during the shell runtime.
Maybe the a check at each completion files function call could be added
to check if /usr/share/bash-completion/bash_completion has changed and
source it when so. But this looks more like an upstream issue
than a Debian specific topic.

NB: I still do not understand why you got the "command not found" when
opening a new bash shell. The new
/usr/share/bash-completion/bash_completion is source from the latest
version at this point.
Maybe your $HOME/.bashrc is not up to date:

/etc/skel/.bashrc: (should be in your $HOME/.bashrc)
# If not running interactively, don't do anything
case $- in
*i*) ;;
  *) return;;
esac
(...)
# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
. /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
. /etc/bash_completion
  fi
fi


/etc/bash.bashrc:
# enable bash completion in interactive shells
#if ! shopt -oq posix; then
#  if [ -f /usr/share/bash-completion/bash_completion ]; then
#. /usr/share/bash-completion/bash_completion
#  elif [ -f /etc/bash_completion ]; then
#. /etc/bash_completion
#  fi
#fi

or it is not imported from your $HOME/.profile which should have:
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi


but even then /etc/profile should have source the common bash completion 
functions:
/etc/profile:
/etc/profile.d/bash_completion.sh
# shellcheck shell=sh disable=SC1091,SC2166,SC2268,SC3028,SC3044,SC3054
# Check for interactive bash and that we haven't already been sourced.
if [ "x${BASH_VERSION-}" != x -a "x${PS1-}" != x -a 
"x${BASH_COMPLETION_VERSINFO-}" = x ]; then

# Check for recent enough version of bash.
if [ "${BASH_VERSINFO[0]}" -gt 4 ] ||
[ "${BASH_VERSINFO[0]}" -eq 4 -a "${BASH_VERSINFO[1]}" -ge 2 ]; then
[ -r "${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion" ] &&
. "${XDG_CONFIG_HOME:-$HOME/.config}/bash_completion"
if shopt -q progcomp && [ -r /usr/share/bash-completion/bash_completion 
]; then
# Source completion code.
. /usr/share/bash-completion/bash_completion
fi
fi

fi



Cheers
Alban

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

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

-- no debconf information

Bug#1070115: libaio1t64: libaio1 and libaio1t64 are co-installed: is this expected?

[Gianfranco Costamagna]

Hello,
quoting changelog:

+libaio (0.3.113-6) unstable; urgency=medium
+
+  * Switch from future=+lfs to abi=+lfs build flags feature, and Build-Depends
+on dpkg-dev >= 1.22.0.
+  * Add time64 support:
+- Remove dead code for syscall handling.
+- Refactor code to use an internal implementation for public functions
+  that handle timespec, by switching them to always use __kernel_timespec,
+  and add conversion functions to map from 'struct timespec' to
+  'struct __kernel_timespec', and from 'struct __kernel_timespec' to
+  'struct __kernel_old_timespec'.
+- Add support for io_pgetevents_time64() Linux syscall, but disable it
+  for now as it only works on 32-bit kernels, but not on the compat
+  mode in 64-bit kernels running 32-bit userland, will be fixed in Linux
+  in parallel, as the timeouts used are supposed to be relative anyway,
+  and this does not and will not break ABI.
+- Add dual time32/time64 ABI support by adding io_getevents_time64() and
+  io_pgetevents_time64() library functions on 32-bit architectures, that
+  get redirected from the io_getevents() and io_pgetevents() functions
+  when the user sets _TIME_BITS=64.
+- Perform a SONAME bump to avoid stomping on upstream SONAME. Once and if
+  the new symbols are accepted by upstream then we can merge that back
+  into libaio.so.1 and drop the t64 packages and temporarily provide
+  a compat symlink for the t64 SONAME for a smooth transition back. This
+  should also be an easier way to revert this transition when there are
+  no file conflicts involved, and does not block on upstream support.
+- Do not rename the udeb from libaio1-udeb, as d-i does not care, and
+  that would require a pointless trip through NEW. But update the shlibs
+  references for the libaio1t64 rename.
+- We do not need a dependency on a newer dpkg-dev nor gcc as we are
+  explicitly handling the time64 dual-ABI independently of the toolchain.
+Closes: #1062218
+
+ -- Guillem Jover   Tue, 05 Mar 2024 11:33:54 +0100

On Tue, 30 Apr 2024 14:37:54 +0200 Patrice Duroux  
wrote:

Package: libaio1t64
Version: 0.3.113-8
Severity: minor

Dear Maintainer,

On my Sid system, I have currently the following:

$ dpkg -l | grep libaio
ii  libaio1:amd640.3.113-5
amd64Linux kernel AIO access library - shared library
ii  libaio1t64:amd64 0.3.113-8
amd64Linux kernel AIO access library - shared library


Does installing libaio1t64 should have removed libaio1 like in some other t64
library transition cases?

Thanks



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

Kernel: Linux 6.7.12-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 libaio1t64 depends on:
ii  libc6  2.37-19

libaio1t64 recommends no packages.

libaio1t64 suggests no packages.

-- no debconf information

Bug#1070098: openssh-sftp-server: False dependency on openssh-client

[Wolf]

On Tue, Apr 30, 2024 at 5:41 AM Colin Watson  wrote:

> This saves a bit of space if all the packages are installed together,
> which is the common case.  However, it's true that it's not very much
> space (200K or so), so maybe it's not worth the resulting confusion ...
>

Ah, I'd missed that symlink, likely because I'd path-excluded the various
/usr/share/doc and such
directories already, my apologies for the oversight.

With other SSH services relying on this package for SFTP support it adds
about a few megabytes
on amd64 from pulling in the tertiary dependencies for openssh-client by
comparison.


> You'll have to report that as a separate bug - I don't maintain the
> dropbear packages.
>

Gotcha, and thank you both for your time and for letting me know that, I'll
get the other bug filed.

Bug#1070118: focuswriter: Freezes randomly during use on 32-bit Debian

[Diogo Oliveira]

Package: focuswriter
Version: 1.8.6-1
Severity: important
X-Debbugs-Cc: dhe...@vivaldi.net

Dear Maintainer,

Focuswriter randomly hangs and freezes, forcing me to "ps -ax | grep focus" ,
then "kill [focuswriter process number]".

To reproduce the bug:

(a) Open Focuswriter and use it until it hangs, this usually happens under 5 to
10 minutes of continuous use.

This bug happens just under my 32-bit Debian, no matter if I'm using Debian
Bookworm/Stable (in which Focuswriter is version 1.8.4.1) or Trixie/Testing (in
which Focuswriter is version 1.8.6.1+b1). Also, it doesn't matter what Window
Manager/Desktop Rnvironment I'm using. All my 64-bit Debian installations are
free of this bug. I didn't try to reproduce the bug under other Linux distros
or under Windows.


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

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

Versions of packages focuswriter depends on:
ii  libc62.37-15
ii  libgcc-s114-20240201-3
ii  libhunspell-1.7-01.7.2+really1.7.2-10+b1
ii  libqt6core6  6.4.2+dfsg-21
ii  libqt6gui6   6.4.2+dfsg-21
ii  libqt6multimedia66.4.2-4
ii  libqt6network6   6.4.2+dfsg-21
ii  libqt6printsupport6  6.4.2+dfsg-21
ii  libqt6widgets6   6.4.2+dfsg-21
ii  libstdc++6   14-20240201-3
ii  zlib1g   1:1.3.dfsg-3+b1

focuswriter recommends no packages.

Versions of packages focuswriter suggests:
ii  hunspell-en-us [hunspell-dictionary]  1:2020.12.07-2
ii  hunspell-pt-br [hunspell-dictionary]  1:7.5.0-1
pn  myspell-dictionary

-- no debconf information

Bug#1068750: moment-timezone.js: FTBFS everywhere

[Santiago Vila]

# Fail the build if the tzdata package does not match TZVER.
grep -q '^# version 2023d$' /usr/share/zoneinfo/tzdata.zi


Yes, this is expected after each update to tzdata.


I'm curious: Does this package embed the information from tzdata into 
javascript code,
in such a way that a change in tzdata requires a rebuild?


Yes. It is the only way I found to keep the package aligned with tzdata while 
ensuring it is fully built from source: upstream ships the pre-compiled tzdata 
information, so I regenerate those files using the tzdata package.


I think it would be highly desirable to find a way for this package to do what
it's supposed to do without having to fix it in oldstable and stable every year.


Without a new upload, I cannot imagine how.. :-/


(In fact, I asked Paul Gevers about this, he says that a package which we know
for sure that it will fail to build during the support time of the release is 
RC).


It fails to build if tzdata is updated, but it never stops working. It just 
needs to be updated as often as tzdata is. But if you have a suggestion to make 
this more automatic, I would love to hear it..


Sorry, I still don't get it.

Why does the package build needs to fail if tzdata is updated?

What happens if we allow the package to be built anyway?
(as in the attached patch).

Would the resulting package be broken in any way?


I have been doing this very repetitive maintenance for years!


Well, I get that you have to make a new upload so that the package is current.
What I don't get is that the package fails to build. At most, it would result
in an improved package, not worse. Or maybe I'm missing anything.

Thanks.--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Build-Depends: debhelper-compat (= 13)
  , dh-sequence-nodejs
  , uglifyjs
  , ts-node 
+ , tzdata (>= 2024a)
  , tzdata-legacy (>= 2024a)
 Standards-Version: 4.6.2
 Vcs-Browser: https://salsa.debian.org/js-team/moment-timezone.js
--- a/debian/rules
+++ b/debian/rules
@@ -23,10 +23,6 @@ all: binary
 %:
dh $@
 
-execute_before_dh_auto_configure:
-   # Fail the build if the tzdata package does not match TZVER.
-   grep -q '^# version $(TZVER)$$' /usr/share/zoneinfo/tzdata.zi
-
 override_dh_auto_build: $(TARGETS)
 
 execute_before_dh_auto_test: tests/zones/zulu.js