Bug#1037065: modsecurity-apache records the version of libapr during compilation

[Paul Gevers]

Package: modsecurity-apache

Hi,

In bug #1037024 an NMU was requested because modsecurity-apache records 
the version of libapr that it compiles again. That generates noise if we 
upgrade libapr even if there is no ABI breakage, and thus no transition 
(and rebuilds don't get scheduled).


On 02-06-2023 22:44, Ervin Hegedüs wrote:

[Wed May 31 13:11:05.165477 2023] [security2:notice] [pid 8:tid 1996017088] ModSecurity: APR 
compiled version="1.7.0"; loaded version="1.7.2"
[Wed May 31 13:11:05.165508 2023] [security2:warn] [pid 8:tid 1996017088] 
ModSecurity: Loaded APR do not match with compiled!


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037002: unblock: forensics-all/3.45

[Paul Gevers]

Control: tags -1 moreinfo

Hi,

On 31-05-2023 23:20, Joao Eriberto Mota Filho wrote:

[ Reason ]
forensics-all (like forensics-extra) is a metapackage to install several
tools to aid in forensics activities. Due an issue in reaver (see #1036809),
forensics-all is marked for autoremoval.


Given that reaver got fixed and migrated, is this still wanted and needed?

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037057: adduser.8: fix some formatting and text issues

[Marc Haber]

On Sat, Jun 03, 2023 at 05:57:51AM +0200, Helge Kreutzmann wrote:
> if you fix any (or all) of the bugs, unfuzzy the translations or
> inform me such that I can unfuzzy them.

I'll do a new translation rounds in the trixie cycle, the manpages will
be worked on again anyway since adduser will move on.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#932957: Please migrate Release Notes to reStructuredText

[Stuart Prescott]

Hi Holger

Thanks for working on this :)


- The list of archs is hardcoded in the Makefile for now.


The following might provide you with some useful way of not hard-coding 
such information:


curl -s 'https://api.ftp-master.debian.org/suite/bookworm'

(pipe that into « jq -r '.architectures[]' » to get just the archs as 
plain text)


You might want to make that a 'maintainer-run' step rather than is run 
occasionally as part of preparing a release, rather than as a build time 
step. That is, the maintainer runs that from a machine with internet 
access to find the list of archs that should be used; this is then 
cached in the repo until it is next refreshed. There is precedent for 
this 'maintainer-run' step in various "make dist' mechanisms (from the 
autotools world) and how the dh-python packages prepares a cache of 
known python modules in the archive for later module→package translation.


There has been talk for a while about how we might avoid baking in 
internal metadata in packages and there might be more inspiration on how 
to do this in other parts of the project:


https://wiki.debian.org/SuitesAndReposExtension

(there are already a couple of entries there for the release notes)

cheers
Stuart



--
Stuart Prescott   http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer  http://www.debian.org/   stu...@debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#1037064: maven-verifier depends on downloading sources at build time

[Steve Langasek]

Source: maven-verifier
Version: 1.8.0-1
Severity: serious
Justification: package in main has dependency on external software
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic

Dear maintainers,

maven-verifier 1.8.0-1 has been failing to build in Ubuntu, because its
build-time tests depend on downloading software from the Internet:

[...]
[ERROR] testWithMavenHome(org.apache.maven.it.Embedded3xLauncherTest)  Time 
elapsed: 0.581 s  <<< FAILURE!
java.lang.AssertionError: 
exit code unexpected, build log: 
[INFO] Scanning for projects...
Downloading from central: 
https://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-shared-components/18/maven-shared-components-18.pom
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for 
org.apache.maven.shared:maven-verifier:1.4-SNAPSHOT: Could not transfer 
artifact org.apache.maven.shared:maven-shared-components:pom:18 from/to central 
(https://repo.maven.apache.org/maven2): transfer failed for 
https://repo.maven.apache.org/maven2/org/apache/maven/shared/maven-shared-components/18/maven-shared-components-18.pom
 and 'parent.relativePath' points at wrong local POM @ line 23, column 11
 @ 
[...]

  (https://launchpad.net/ubuntu/+source/maven-verifier/1.8.0-1/+build/26010073)

This fails because Launchpad does not allow network access during package
builds, unlike Debian buildds which usually have network access.

While this is not a build failure, it does mean building the package has a
dependency on software outside of main, which I believe is a serious policy
violation.

libmaven-parent-java ships maven-shared-components-35.pom and maven-verifier
build-depends on libmaven-parent-java.  So perhaps src/test/resources/pom.xml
simply needs updated to point at the current version instead of version 18?

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


signature.asc
Description: PGP signature

Bug#1037063: libxml-libxml-perl: Seemingly incorrect handling of escaped characters in patterns

[Xan Charbonnet]

Package: libxml-libxml-perl
Version: 2.0134+dfsg-2+b1
Severity: normal

Dear Maintainer,

I use XML::LibXML::Reader to work with files that validate against the Library
of Congress's MARCXML Schema, available here:
https://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd

That schema includes a pattern:
[\dA-Za-z!#$%'()*+,-./:;=?{}_^`~\[\]\\]{1}
or, with the XML escaping processed:
[\dA-Za-z!"#$%&'()*+,-./:;<=>?{}_^`~\[\]\\]{1}

That regex requires a single character, any one of a long list of allowable
characters.  Note how three of the characters require escaping because they
would have meaning in the regex itself: the two square brackets [ and ], and
the backslash \.

An online XML Schema validator that I found with a quick search:
https://www.liquid-technologies.com/online-xsd-validator
shows that those three characters are valid.  The problem is that
XML::LibXML::Reader seems to believe that they are not.

I wrote a simple test script, validate.pl:

---
#!/usr/bin/perl

use strict;
use warnings;
use File::Slurp;
use XML::LibXML::Reader;

my ($xml_path, $xsd_path) = @ARGV;

my %parameters = (
'location'=>$xml_path,
'Schema'=>XML::LibXML::Schema->new(string=>scalar(read_file($xsd_path))),
);

my $reader = XML::LibXML::Reader->new(%parameters);
while($reader->read())
{}
print "Finished reading; document must be valid.\n";
---

Along with a basic XML Schema file, test.xsd:

---

http://www.w3.org/2001/XMLSchema;>


  
   
 
   
 
   
 

  



---

and a VERY basic XML file, test.xml:

---

---

Running:
$ perl validate.pl test.xml test.xsd
results in:
test.xml:1: Schemas validity error : Element 'root', attribute 'code': [facet
'pattern'] The value '[' is not accepted by the pattern
'[\dA-Za-z!"#$%&'()*+,-./:;<=>?{}_^`~\[\]\\]{1}'.

I believe that value in fact should match that pattern.  The online schema
validator from earlier validates this pair of files.  If you replace the data
in the "code" attribute with any of the other characters, validation passes.
It only fails for the three characters that are escaped.



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

Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads)
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 libxml-libxml-perl depends on:
ii  libc6 2.31-13+deb11u6
ii  libxml-namespacesupport-perl  1.12-1.1
ii  libxml-sax-perl   1.02+dfsg-1
ii  libxml2   2.9.10+dfsg-6.7+deb11u4
ii  perl  5.32.1-4+deb11u2
ii  perl-base [perlapi-5.32.0]5.32.1-4+deb11u2

libxml-libxml-perl recommends no packages.

libxml-libxml-perl suggests no packages.

-- no debconf information

Bug#1037057: adduser.8: fix some formatting and text issues

[Helge Kreutzmann]

Hello,
if you fix any (or all) of the bugs, unfuzzy the translations or
inform me such that I can unfuzzy them.

Greetings

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


signature.asc
Description: PGP signature

Bug#1037062: libva: Libva 2.17.0 breaks video acceleration in Chromium-based browsers

[Luis]

Source: libva
Version: 2.17.0-1
Severity: important
Tags: upstream
X-Debbugs-Cc: neopowermas...@protonmail.ch

Dear Maintainer,

After a few weeks using Debian testing I see that the video acceleration does
not work in chromium based browsers, after trying many configurations, I see
the upstream release notes and specify that in version 2.17 "x11: add basic
DRI3 support" and in the following version 2.18 "x11: allow disabling DRI3 via
LIBVA_DRI3_DISABLe env var".

That environment variable only works if you have the latest version 2.18.
(Tested on another distro).

Then reviewing the issues in github, there is this one where the problem is
reported, then they added that workaround in 2.18.

https://github.com/intel/libva/issues/677

I know that Bookworm is soon to be released as stable and that it is not
possible to upload the new version due to the full freeze. But I think it is
important that later you can backport a new version where can be used the
workaround that upstream suggests.


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

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

Bug#1037061: battery-stats: does not find power supply on Librem 5

[Evangelos Ribeiro Tzaras]

Package: battery-stats
Version: 0.5.6-3
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

I have installed battery-stats on Debian bookworm on my Librem 5
and noticed that the "Battery Charge Graph" was showing an empty plot.

Further /var/log/battery-stats did not contain anything useful.
So I updated the existing patch that fixed #998418.

Please find my patch attached below, or on salsa:
https://salsa.debian.org/debian/battery-stats/-/merge_requests/2

Note, that I did not explicitly test on any laptop.


*** ./0001-Update-patch-adding-more-power-supplies.patch
- From 3a66fa24bd80a4a1902457ef624dec1ee07f64ee Mon Sep 17 00:00:00 2001
From: Evangelos Ribeiro Tzaras 
Date: Sat, 3 Jun 2023 03:30:43 +0200
Subject: [PATCH] Update patch adding more power supplies

Chargers and Batteries on the L5 are not recognized
(because they do not use BAT0, AC, ..)

$ ls /sys/class/power_supply
bq25890-charger  max170xx_battery  tps6598x-source-psy-0-003f

This update considers $foo a battery
if it's /sys/class/power_supply/$foo/type reads "Battery".
And $foo is considered a charger
if it exposes the file /sys/class/power_supply/$foo/online
- ---
 ...1000-add-more-power-supplies-support.patch | 40 +--
 1 file changed, 28 insertions(+), 12 deletions(-)

diff --git a/debian/patches/1000-add-more-power-supplies-support.patch 
b/debian/patches/1000-add-more-power-supplies-support.patch
index d9aac0a..5b5bda9 100644
- --- a/debian/patches/1000-add-more-power-supplies-support.patch
+++ b/debian/patches/1000-add-more-power-supplies-support.patch
@@ -1,15 +1,19 @@
- -Description: Add support for more power supplies
- - Depending on the computer, a different power_supply name can be used.
- - Add support for more power supplies and use a loop to factorize code.
- -Author: Nicolas Schodet 
+From: Nicolas Schodet 
+Date: Sat, 3 Jun 2023 03:06:04 +0200
+Subject: Add support for more power supplies
+
 Bug-Debian: 998412
 
+Depending on the computer, a different power_supply name can be used.
+Add support for more power supplies and use a loop to factorize code.
+
+Last-Updated: 2023-06-03
 ---
- - src/battery-stats-collector | 15 ---
- - 1 file changed, 8 insertions(+), 7 deletions(-)
+ src/battery-stats-collector | 19 +++
+ 1 file changed, 11 insertions(+), 8 deletions(-)
 
 diff --git a/src/battery-stats-collector b/src/battery-stats-collector
- -index 8e3cff7..c5d054a 100755
+index 8e3cff7..d20b828 100755
 --- a/src/battery-stats-collector
 +++ b/src/battery-stats-collector
 @@ -22,13 +22,14 @@ get_logline() {
@@ -24,13 +28,25 @@ index 8e3cff7..c5d054a 100755
 -aconline=$(cat /sys/class/power_supply/ADP1/online)
 -else
 +aconline=notfound
- -+for ac in AC AC0 ACAD ADP0 ADP1; do
- -+if [ -f /sys/class/power_supply/$ac/online ]; then
- -+aconline=$(cat /sys/class/power_supply/$ac/online)
- -+break
- -+fi
++for ac in /sys/class/power_supply/*; do
++  if [ -f "$ac/online" ]; then
++  aconline=$(cat "$ac/online")
++  break
++  fi
 +done
 +if [ notfound = "$aconline" ]; then
  echo "No power supply found"
  fi
  
+@@ -40,8 +41,10 @@ get_logline() {
+ 
+ now="energy_now"
+ full="energy_full"
+-for f in /sys/class/power_supply/BAT*; do
++for f in /sys/class/power_supply/*; do
+ [ -e "$f" ] || continue
++  [ -f "$f/type" ] || continue
++  [ "Battery" = $(cat "$f/type") ] || continue
+ if [ ! -e $f/$now ] ; then now="charge_now"; fi
+ if [ ! -e $f/$full ] ; then full="charge_full"; fi
+ energy_now=$(cat $f/$now) # uWh
- -- 
2.40.1



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

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

Versions of packages battery-stats depends on:
ii  bc 1.07.1-3+b1
ii  gzip   1.12-1
ii  init-system-helpers1.65.2
ii  logrotate  3.21.0-1
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages battery-stats recommends:
ii  gnuplot-nox [gnuplot]  5.4.4+dfsg1-2+b2
ii  libtext-csv-perl   2.02-2
ii  python33.11.2-1+b1
ii  python3-matplotlib 3.6.3-1+b1

battery-stats suggests no packages.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuThlVLfdJmvLjimpkPDJsYprShkFAmR6sYUACgkQkPDJsYpr
Shn2cA//XC8nxDaAlb8G0NvjNQW6E/TnzCmv3u4ytsqz9uNp6GKtW9uwib90iAg+
99ReQso6Qn8mGHbOoXMqzA+jwDh9uhPuuwuFaij5bk0HqqxLI60XHwsvTnQbM0mZ

Bug#1037060: run-with-aspell.1: Fix some formatting issues in the man page

[Bjarni Ingi Gislason]

Package: aspell
Version: 0.60.8-4+b1
Severity: minor
Tags: patch

Dear Maintainer,

here are some fixes.

Input file is run-with-aspell.1

mandoc: run-with-aspell.1:8:2: WARNING: skipping paragraph macro: br at the end 
of SH
mandoc: run-with-aspell.1:29:2: WARNING: skipping paragraph macro: PP after SH

###

Remove space characters at the end of lines.

10:The recommended way to use 
14:is to change the 

#

--- run-with-aspell.1   2023-06-03 01:42:33.0 +
+++ run-with-aspell.1.new   2023-06-03 01:55:20.0 +
@@ -5,13 +5,12 @@ replacement
 .SH SYNOPSIS
 .B run\-with\-aspell
 .I ""
-.br
 .SH "DESCRIPTION"
-The recommended way to use 
+The recommended way to use
 .B Aspell
 as a replacement for
 .B Ispell
-is to change the 
+is to change the
 .B Ispell
 command from within the program being used.  If that is not possible,
 the
@@ -26,7 +25,6 @@ The old method of mapping ispell to Aspe
 create compatibility problems with programs that actually require ispell
 such as ispell's own scripts.
 .SH SEE ALSO
-.PP
 .BR aspell (1),
 .BR aspell\-import (1),
 .BR word\-list\-compress (1)


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

Kernel: Linux 6.1.27-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages aspell depends on:
ii  dictionaries-common  1.29.5
ii  libaspell15  0.60.8-4+b1
ii  libc62.36-9
ii  libncursesw6 6.4-4
ii  libstdc++6   12.2.0-14
ii  libtinfo66.4-4

Versions of packages aspell recommends:
ii  aspell-de [aspell-dictionary]  20161207-11
ii  aspell-en [aspell-dictionary]  2020.12.07-0-1
ii  aspell-is [aspell-dictionary]  0.51.1-0-2

Versions of packages aspell suggests:
pn  aspell-doc  
pn  spellutils  

-- no debconf information

Bug#1037059: aspell.1: fix some formatting issues in the man page

[Bjarni Ingi Gislason]

Package: aspell
Version: 0.60.8-4+b1
Severity: minor
Tags: patch

Dear Maintainer,

here are some fixes.

Input file is aspell.1


mandoc: aspell.1:7:2: WARNING: skipping paragraph macro: br at the end of SH
mandoc: aspell.1:330:2: WARNING: skipping paragraph macro: PP after SH



Remove space characters at the end of lines.

25:Aspell Utility.  
27:This manual page is maintained separately from the 
313:where 

#

Change '-' (\-) to '\(en' (en-dash) for a numeric range.

aspell.1:74:\fBexpand\fR [\fB1\-4\fR]

#

Change -- in x--y to \(em (em-dash), or, if an
option, to \-\-

255:\fB--backup\fR, \fB\-\-dont\-backup\fR, \fB\-b\fR, \fB\-x\fR

#

Increase size of ~ (tilde) to make it more visible
with "troff" by using character \(ti.

299:.I "~/.aspell.conf"

#

Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.

12:.B "ispell -a"
54:.I "ispell -a"
176:or nroff.  The alternative shortcut options are '-e' for email, '-H'
177:for Html/Sgml, '-t' for Tex or '-n' for Nroff.

#

Inhibit the hyphenation of 'aspell' in

.I "\(ti/.aspell.conf"

#

--- aspell.12023-06-03 00:31:09.0 +
+++ aspell.1.new2023-06-03 01:19:40.0 +
@@ -4,12 +4,11 @@ aspell \- interactive spell checker
 .SH SYNOPSIS
 .B aspell
 .I "[options] "
-.br
 .SH "DESCRIPTION"
 .B aspell
 is a utility program that connects to the Aspell library so that it can
 function as an
-.B "ispell -a"
+.B "ispell \-a"
 replacement, as an independent spell checker, as a test utility to test
 out Aspell library features, and as a utility for managing dictionaries
 used by the library.
@@ -22,9 +21,9 @@ check your distro first for modified dic
 for base language dictionaries .
 .PP
 The following information describes the commands and options used by the
-Aspell Utility.  
+Aspell Utility.
 .PP
-This manual page is maintained separately from the 
+This manual page is maintained separately from the
 official documentation so it may be out of date or incomplete.  The
 official documentation is maintained as a Texinfo manual.  See the
 .RB "`\|" aspell "\|'"
@@ -51,7 +50,7 @@ Spell\-check a single file.
 .TP
 \fBpipe\fR, \fB\-a\fR
 Run Aspell in
-.I "ispell -a"
+.I "ispell \-a"
 compatibility mode.
 .TP
 .B list
@@ -71,7 +70,7 @@ Output the soundslike equivalent of each
 .B munch
 Generate possible root words and affixes from an input list of words.
 .TP
-\fBexpand\fR [\fB1\-4\fR]
+\fBexpand\fR [\fB1\(en4\fR]
 Expands the affix flags of each affix compressed word entered.
 .TP
 \fBclean\fR [\fBstrict\fR]
@@ -173,8 +172,8 @@ Add or remove paths searched for filters
 .TP
 \fB\-\-mode=\fR\fI\fR, \fB\-e\fR, \fB\-H\fR, \fB\-t\fR, \fB\-n\fR
 Sets the filter mode.  \fIMode\fR is one of none, url, email, html, tex
-or nroff.  The alternative shortcut options are '-e' for email, '-H'
-for Html/Sgml, '-t' for Tex or '-n' for Nroff.
+or nroff.  The alternative shortcut options are '\-e' for email, '\-H'
+for Html/Sgml, '\-t' for Tex or '\-n' for Nroff.
 .TP
 \fB\-\-encoding=\fR\fI\fR
 encoding the document is expected to be in.  The default depends on the
@@ -252,7 +251,7 @@ These options are part of the
 .I aspell
 Utility and work independently of the library.
 .TP
-\fB--backup\fR, \fB\-\-dont\-backup\fR, \fB\-b\fR, \fB\-x\fR
+\fB\-\-backup\fR, \fB\-\-dont\-backup\fR, \fB\-b\fR, \fB\-x\fR
 The aspell utility creates a backup file by making a copy and appending
 .I .bak
 to file name.  This only applies when the command is
@@ -296,7 +295,7 @@ default global configuration file is
 .I "/etc/aspell.conf"
 or another file specified by option \fI\-\-conf\fR and is checked first.
 The default per user configuration file
-.I "~/.aspell.conf"
+.I "\%\(ti/.aspell.conf"
 located in the
 .B "$HOME"
 directory (or another file specified by option \fI\-\-per\-conf\fR) is
@@ -310,7 +309,7 @@ Each line of the configuration file has
 \fBoption\fR \fI[value]\fR
 .RE
 .PP
-where 
+where
 .B option
 is any one of the standard library options above without the leading
 dashes.  For example the following line will set the default language to
@@ -327,7 +326,6 @@ with a '#' as anything from a '#' to a n
 are also allowed.  The \fI/etc/aspell.conf\fR file is a good example of
 how to set these options and the Aspell Manual has more detailed info.
 .SH SEE ALSO
-.PP
 .BR aspell\-import (1),
 .BR prezip\-bin (1),
 .BR run\-with\-aspell (1),


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

Kernel: Linux 6.1.27-1 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages aspell depends on:
ii  dictionaries-common  1.29.5
ii  libaspell15  0.60.8-4+b1
ii  libc62.36-9
ii  libncursesw6 

Bug#1037058: mergerfs: Mounting as non-root user fails with EPERM due to missing setuid bit

[Grond]

Package: mergerfs
Version: 2.31.0-1
Severity: important
X-Debbugs-Cc: spa...@riseup.net

Mergerfs does not work properly when used as a non-root user:

 $ mkdir a b c
 $ mergerfs $(realpath a):$(realpath b) c
 fusermount: mount failed: Operation not permitted

After some debugging with strace, it appears that:
1) mergerfs ships it's own private version of fusermount as
   /usr/bin/mergerfs-fusermount
2) The version of fusermount shipped with the fuse3 package is setuid-root.
3) ...And /usr/bin/mergerfs-fusermount is not.

Making /usr/bin/mergerfs-fusermount setuid-root manually makes the problem
vanish.

So I'm going to bet that the intention is for /usr/bin/mergerfs-fusermount to
be installed as setuid-root but that doesn't happen for whatever reason.

Since one of the primary benefits of FUSE filesystems is to be able to mount
them as a standard user, I think it may be worth fixing this by either:
1) Patching mergerfs to use the system-provided fusermount binary. (Although,
   there may issues surrounding this approach as mergerfs seems to be using an
   embedded copy of libfuse as well.)
2) Making /usr/bin/mergerfs-fusermount setuid-root by default. (Though I don't
   know if there's any extra security red tape surrounding shipping setuid-root
   binaries in Debian.)

Just thought I report the above in the hope that this won't affect future
releases. And I'd be interested to know more about the feasibility of both
solutions.

Thanks,
--Grond

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

Kernel: Linux 5.10.0-21-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mergerfs depends on:
ii  fuse3 [fuse]  3.10.3-2
ii  libc6 2.31-13+deb11u5
ii  libfuse2  2.9.9-5
ii  libgcc-s1 10.2.1-6
ii  libstdc++610.2.1-6

mergerfs recommends no packages.

mergerfs suggests no packages.

-- no debconf information

Bug#1037014: AttributeError: module 'gettext' has no attribute 'bind_textdomain_codeset'

[Daniel Baumann]

close 1037014 2.1.1-1
thanks

Hi Matt,

thank you for your report. Yes, you're right that deluge-console is
broken in current unstable/testing, this has been fixed in the newer
upstream version that can be found in experimental, I'm
versioned-closing the bug as such.

The situation for deluge in bookworm is rather unfortunate, I took over
while bookworm was in freeze already so a lot of fixes, like this one,
can't make it into bookworm anymore due to freeze policy. Let's make
sure that the upper-next Debian release will have a decent deluge
package from the start and use a backport of the (currently 2.1.1-3 in
experimental) newer version in the meanwhile.

Regards,
Daniel

Bug#1035359: Processed: cloning 1022061, retitle -1 to linux: test-patches script produces uninstallable packages ...

[Diederik de Haas]

On Tuesday, 2 May 2023 00:36:05 CEST Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> > clone 1022061 -1
> > retitle -1 linux: test-patches script produces uninstallable packages
> > # First version with signed/unsigned Conflicts
> > reassign -1 src:linux 4.7~rc3-1~exp1

Isn't this bug fixed in 342dd6ce49afc4f4088616d0276c119033b67239 and uploaded 
to Debian with version 6.1.27-1 ?

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

Bug#1037057: adduser.8: fix some formatting and text issues

[Bjarni Ingi Gislason]

Package: adduser
Version: 3.134
Severity: minor
Tags: patch

Dear Maintainer,

here are some fixes.

Input file is adduser.8

#

Reduce space between words.

136:without the \fB\-\-system\fP or \fB\-\-group\fP  options,
175:with the \fB\-\-gid\fP  or \fB\-\-ingroup\fP options

#

Change -- in x--y to \(em (em-dash), or, if an
option, to \-\-

360:Using this option in \fBadduser --system\fP

#

Use the correct macro for the font change of a single argument or
split the argument into two.

308:.BR \-\-debug
371:.BR \-\-help
407:.BR \-\-quiet
430:.BR \-\-verbose

#

Fix spelling

Nomally -> Normally

#

Remove trailing space

#

--- adduser.8   2023-06-02 21:14:13.0 +
+++ adduser.8.new   2023-06-02 23:43:42.0 +
@@ -133,7 +133,7 @@ see the OPTIONS section.
 \fBadduser\fP and \fBaddgroup\fP can be run in one of five modes:
 .SS "Add a normal user"
 If called with one non-option argument and
-without the \fB\-\-system\fP or \fB\-\-group\fP  options,
+without the \fB\-\-system\fP or \fB\-\-group\fP options,
 \fBadduser\fP will add a normal user,
 that means a
 \fIdynamically allocated user account\fP
@@ -172,7 +172,7 @@ is explained in detail in
 .PP
 Users' primary groups can also be overridden
 from the command line
-with the \fB\-\-gid\fP  or \fB\-\-ingroup\fP options
+with the \fB\-\-gid\fP or \fB\-\-ingroup\fP options
 to set the group by id or name,
 respectively.
 Also,
@@ -292,7 +292,7 @@ See VALID NAMES in
 Valid Modes: \fBadduser\fP, \fBadduser \-\-system\fP,
 \fBaddgroup\fP, \fBaddgroup \-\-system\fP.
 .TP
-.BI \-\-comment " comment "
+.BI \-\-comment " comment"
 Set the comment field for the new entry generated.
 \fBadduser\fP will not ask for the information if this option is given.
 This field is also known under the name GECOS field
@@ -301,11 +301,11 @@ This used to be the \fB\-\-gecos\fR opti
 which is deprecated and will be removed after Debian bookworm.
 Valid Modes: \fBadduser\fP, \fBadduser \-\-system\fP.
 .TP
-.BI \-\-conf " file "
+.BI \-\-conf " file"
 Use \fIfile\fP instead of \fI/etc/adduser.conf\fP.
 Multiple \fB\-\-conf\fR options can be given.
 .TP
-.BR \-\-debug
+.B \-\-debug
 Activate debugging code.
 .TP
 .B \-\-disabled\-login
@@ -319,13 +319,13 @@ for reasons that are beyond \fBadduser\f
 \fI/usr/sbin/nologin\fP.
 Valid Mode: \fBadduser\fP.
 .TP
-.BI \-\-firstuid " ID "
+.BI \-\-firstuid " ID"
 .TQ
-.BI \-\-lastuid " ID "
+.BI \-\-lastuid " ID"
 .TQ
-.BI \-\-firstgid " ID "
+.BI \-\-firstgid " ID"
 .TQ
-.BI \-\-lastgid " ID "
+.BI \-\-lastgid " ID"
 Override the first UID / last UID / first GID / last GID
 in the range that the uid is chosen from
 (\fBFIRST_UID\fP, \fBLAST_UID\fP, \fBFIRST_GID\fP and \fBLAST_GID\fP,
@@ -347,7 +347,7 @@ These are the deprecated forms of \fB\-\
 It will be removed
 during the release cycle of the Debian release after \fIbookworm\fP.
 .TP
-.BI \-\-gid " ID "
+.BI \-\-gid " ID"
 When creating a group,
 this option sets the group ID number of the new group to \fIGID\fP.
 When creating a user,
@@ -357,7 +357,7 @@ Valid Modes: \fBadduser\fP, \fBadduser \
 \fBaddgroup\fP, \fBaddgroup \-\-system\fP.
 .TP
 .B \-\-group
-Using this option in \fBadduser --system\fP
+Using this option in \fBadduser \-\-system\fP
 indicates that the new user should get
 an identically named group as its primary group.
 If that identically named group is not already present, it is created.
@@ -368,17 +368,17 @@ the program is invoked as \fBaddgroup\fP
 Valid Modes: \fBadduser \-\-system\fP,
 \fBaddgroup\fP, \fBaddgroup \-\-system\fP.
 .TP
-.BR \-\-help
+.B \-\-help
 Display brief instructions.
 .TP
-.BI \-\-home " dir "
+.BI \-\-home " dir"
 Use \fIdir\fP as the user's home directory,
 rather than the default specified by the configuration file
 (or \fI/nonexistent\fP if \fBadduser \-\-system\fP is used).
 If the directory does not exist, it is created.
 Valid Modes: \fBadduser\fP, \fBadduser \-\-system\fP.
 .TP
-.BI \-\-ingroup " GROUP "
+.BI \-\-ingroup " GROUP"
 When creating a user,
 this option sets the primary group ID number of the new user
 to the GID of the named group.
@@ -387,9 +387,9 @@ the group is specified here by name rath
 The group must already exist.
 Valid Modes: \fBadduser\fP, \fBadduser \-\-system\fP.
 .TP
-.BI \-\-lastuid " ID "
+.BI \-\-lastuid " ID"
 .TQ
-.BI \-\-lastgid " ID "
+.BI \-\-lastgid " ID"
 Override the last UID / last GID.
 See \fB\-\-firstuid\fP.
 .TP
@@ -404,17 +404,17 @@ that some other mechanism will be respon
 for initializing the new user's home directory.
 Valid Modes: \fBadduser\fP, \fBadduser \-\-system\fP.
 .TP
-.BR \-\-quiet
+.B \-\-quiet
 Suppress informational messages, only show warnings and errors.
 .TP
-.BI \-\-shell " shell "
+.BI \-\-shell " shell"
 Use \fIshell\fP as the user's login shell,
 rather than the default specified by the configuration file
 (or \fI/usr/sbin/nologin\fP if \fBadduser \-\-system\fP is used).
 Valid Modes: \fBadduser\fP, \fBadduser \-\-system\fP.
 

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Nicholas D Steeves]

Alexandru Mihail  writes:

> As for the old bugs, at least #491078 and #1018900 are stil present, I
> shall test a user submitted patch for the first one.

Thank you for taking the time to verify and document this.  While not
required, it would also be nice if #491078 was noted in the appropriate
patch[es].  Bug-Debian is an optional field:
https://dep-team.pages.debian.net/deps/dep3/

> I'll also create a salsa account soon.

Thanks!  Do you know if you'd prefer to fork and file pull
requests/merge requests, or wait for the permissions to push directly to
be granted?

> I hope this mail finds you well !
>

Thanks, you as well!
Nicholas


signature.asc
Description: PGP signature

Bug#1035542: libreswan: CVE-2023-30570: Incorrect aggressive mode interaction causes the pluto daemon to crash

[Daniel Kahn Gillmor]

Hi Salvatore--

On Fri 2023-06-02 21:20:50 +0200, Salvatore Bonaccorso wrote:
> Thanks for having a closer look and for your assessment. Then I
> believe we can have a fix scheduled via respective point releases, I
> do not see an urgency for it requiring a DSA. Initially I was not
> completely sure about it.

i'm fine with a fix in the point release approach.  I've gone ahead and
uploaded 4.11-1 to unstable, and 4.3-1+deb11u4 to bullseye for
proposed-updates (#1037054).  And I've uploaded 4.10-1+deb12u1 to bookworm's
proposed-updates too (#1037056).

I recognize that i missed the window for bookworm, and i'm bummed about
that, but i think this approach should reach users with reasonable speed
(and most users shouldn't have IKEv1 enabled at all on bookworm anyway).

Please don't hesitate to nudge here if there's more that needs doing.

  --dkg


signature.asc
Description: PGP signature

Bug#1037056: bookworm-pu: package libreswan/4.10-2+deb12u1

[Daniel Kahn Gillmor]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libres...@packages.debian.org, d...@fifthhorseman.net
Control: affects -1 + src:libreswan

[ Reason ]

Uploading libreswan 4.19-1+deb12u1 should address #1035542 (aka
CVE-2023-30570), which addresses a potential DoS against libreswan
instances that use a certain IKEv1 configuration.

Discussion with Salvatore Bonaccorso over in #1035542 concluded that
using point releases for this should be sufficient.

[ Impact ]

Users on bookworm with a specific libreswan configuration (IKEv1 in
aggressive mode) risk a DDoS on their libreswan IKE daemon if a
malicious attacker on the network emits a certain stream of packets.

[ Tests ]

Sadly, most libreswan test suites involve running virtual machines,
interacting with the linux kernel over open network policies, and this
isn't possible on debian testing architecture.

[ Risks ]

The risks of including these patches are minimal.

[ 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 changes deal solely with how the pluto IKE daemon handles error
cases on incoming IKEv1 packets in aggressive mode.

[ Other info ]

All of the above information has been agregated and adapted from
https://libreswan.org/security/CVE-2023-30570/ Upstream released
version 4.11, which is just 4.10 with comparable patches applied.
4.11 is in unstable now.

I've already uploaded an update to 4.3 for the next bullseye point
release as well.
diff -Nru libreswan-4.10/debian/changelog libreswan-4.10/debian/changelog
--- libreswan-4.10/debian/changelog 2023-03-10 16:34:25.0 -0500
+++ libreswan-4.10/debian/changelog 2023-06-02 18:15:28.0 -0400
@@ -1,3 +1,9 @@
+libreswan (4.10-2+deb12u1) bookworm; urgency=medium
+
+  * Fix CVE-2023-30570 (Closes: #1035542)
+
+ -- Daniel Kahn Gillmor   Fri, 02 Jun 2023 18:15:28 
-0400
+
 libreswan (4.10-2) unstable; urgency=medium
 
   * Reach NSPR mipsel workaround for #854472
diff -Nru libreswan-4.10/debian/control libreswan-4.10/debian/control
--- libreswan-4.10/debian/control   2023-03-03 09:54:30.0 -0500
+++ libreswan-4.10/debian/control   2023-06-02 18:15:28.0 -0400
@@ -6,7 +6,7 @@
  Paul Wouters ,
  Ondřej Surý ,
 Vcs-Browser: https://salsa.debian.org/debian/libreswan
-Vcs-Git: https://salsa.debian.org/debian/libreswan.git
+Vcs-Git: https://salsa.debian.org/debian/libreswan.git -b debian/bookworm
 Standards-Version: 4.6.2
 Rules-Requires-Root: no
 Build-Depends:
diff -Nru libreswan-4.10/debian/gbp.conf libreswan-4.10/debian/gbp.conf
--- libreswan-4.10/debian/gbp.conf  2023-03-03 09:54:30.0 -0500
+++ libreswan-4.10/debian/gbp.conf  2023-06-02 18:15:28.0 -0400
@@ -1,4 +1,4 @@
 [DEFAULT]
 pristine-tar = True
 upstream-tag = v%(version)s
-debian-branch = debian/unstable
+debian-branch = debian/bookworm
diff -Nru libreswan-4.10/debian/patches/0005-Fix-CVE-2023-30570.patch 
libreswan-4.10/debian/patches/0005-Fix-CVE-2023-30570.patch
--- libreswan-4.10/debian/patches/0005-Fix-CVE-2023-30570.patch 1969-12-31 
19:00:00.0 -0500
+++ libreswan-4.10/debian/patches/0005-Fix-CVE-2023-30570.patch 2023-06-02 
18:14:32.0 -0400
@@ -0,0 +1,138 @@
+From: Daniel Kahn Gillmor 
+Date: Fri, 2 Jun 2023 18:14:24 -0400
+Subject: Fix CVE-2023-30570
+
+---
+ programs/pluto/ikev1.c  | 61 ++---
+ programs/pluto/ikev1_aggr.c |  5 ++--
+ 2 files changed, 61 insertions(+), 5 deletions(-)
+
+diff --git a/programs/pluto/ikev1.c b/programs/pluto/ikev1.c
+index e061532..401618b 100644
+--- a/programs/pluto/ikev1.c
 b/programs/pluto/ikev1.c
+@@ -1101,10 +1101,20 @@ void process_v1_packet(struct msg_digest *md)
+   struct state *st = NULL;
+   enum state_kind from_state = STATE_UNDEFINED;   /* state we started in 
*/
+ 
++  /*
++   * For the initial responses, don't leak the responder's SPI.
++   * Hence the use of send_v1_notification_from_md().
++   *
++   * AGGR mode is a mess in that the R0->R1 transition happens
++   * well before the transition succeeds.
++   */
+ #define SEND_NOTIFICATION(t)  \
+   {   \
+   pstats(ikev1_sent_notifies_e, t);   \
+-  if (st != NULL) \
++  if (st != NULL &&   \
++  st->st_state->kind != STATE_AGGR_R0 &&  \
++  st->st_state->kind != STATE_AGGR_R1 &&  \
++  st->st_state->kind != STATE_MAIN_R0)\
+   send_v1_notification_from_state(st, from_state, 

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Sandy Shores]

 line #276 - # 298 of dmesg... attached to Message # 62

 [    0.066966] smpboot: CPU0: Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz 
(family: 0x6, model: 0x9e, stepping: 0xd) [    0.066966] cblist_init_generic: 
Setting adjustable number of callback queues. [    0.066966] 
cblist_init_generic: Setting shift to 4 and lim to 1. [    0.066966] 
cblist_init_generic: Setting shift to 4 and lim to 1. [    0.066966] 
cblist_init_generic: Setting shift to 4 and lim to 1. [    0.066966] 
Performance Events: PEBS fmt3+, Skylake events, 32-deep LBR, full-width 
counters, Intel PMU driver. [    0.066966] ... version:                4 [    
0.066966] ... bit width:              48 [    0.066966] ... generic registers:  
    4 [    0.066966] ... value mask:              [    
0.066966] ... max period:             7fff [    0.066966] ... 
fixed-purpose events:   3 [    0.066966] ... event mask:             
0007000f [    0.066966] Estimated ratio of average max frequency by 
base frequency (times 1024): 2005 [    0.066966] rcu: Hierarchical SRCU 
implementation. [    0.066966] rcu:     Max phase no-delay instances is 1000. [ 
   0.066966] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter. [  
  0.066966] smp: Bringing up secondary CPUs ... [    0.066966] x86: Booting SMP 
configuration: [    0.066966]  node  #0, CPUs:        #1  #2  #3  #4  #5  
#6  #7  #8 [    0.077241] MMIO Stale Data CPU bug present and SMT on, data leak 
possible. See 
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/processor_mmio_stale_data.html
 for more details. [    0.077241]   #9 #10 #11 #12 #13 #14 #15 [    0.088667] 
smp: Brought up 1 node, 16 CPUs
 compare to lspci -tvnn posted in Message # 133
   lspci -tvnn -[:00]-+-00.0  Intel Corporation Device [8086:3e20]          
 +-01.0-[01]00.0  NVIDIA Corporation TU117M [GeForce GTX 1650 Mobile / 
Max-Q] [10de:1f91]           +-02.0  Intel Corporation CoffeeLake-H GT2 [UHD 
Graphics 630] [8086:3e9b]           +-04.0  Intel Corporation Xeon E3-1200 
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem [8086:1903]           
+-08.0  Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen 
Core Processor Gaussian Mixture Model [8086:1911]           +-12.0  Intel 
Corporation Cannon Lake PCH Thermal Controller [8086:a379]           +-14.0  
Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host Controller [8086:a36d]      
     +-14.2  Intel Corporation Cannon Lake PCH Shared SRAM [8086:a36f]          
 +-15.0  Intel Corporation Cannon Lake PCH Serial IO I2C Controller #0 
[8086:a368]           +-15.1  Intel Corporation Cannon Lake PCH Serial IO I2C 
Controller #1 [8086:a369]           +-16.0  Intel Corporation Cannon Lake PCH 
HECI Controller [8086:a360]           +-17.0  Intel Corporation Cannon Lake 
Mobile PCH SATA AHCI Controller [8086:a353]           
+-1b.0-[02-3a]00.0-[03-3a]--+-00.0-[04]00.0  Intel Corporation JHL6340 
Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016] [8086:15d9]           |       
                        +-01.0-[05-39]--           |                            
   \-02.0-[3a]00.0  Intel Corporation JHL6340 Thunderbolt 3 USB 3.1 
Controller (C step) [Alpine Ridge 2C 2016] [8086:15db]           
+-1c.0-[3b]00.0  Intel Corporation Wi-Fi 6 AX200 [8086:2723]           
+-1c.4-[3c]00.0  Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card 
Reader [10ec:525a]           +-1d.0-[3d]00.0  Samsung Electronics Co Ltd 
NVMe SSD Controller SM981/PM981/PM983 [144d:a808]           +-1f.0  Intel 
Corporation Cannon Lake LPC Controller [8086:a30e]           +-1f.3  Intel 
Corporation Cannon Lake PCH cAVS [8086:a348]           +-1f.4  Intel 
Corporation Cannon Lake PCH SMBus Controller [8086:a323]           \-1f.5  
Intel Corporation Cannon Lake PCH SPI Controller           [8086:a324]    I 
hope this is not noise! much gratitude

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Nicholas D Steeves]

Hi Lorenzo, Thank you for the help with reviewing :)

Hi Alexandru, Reply follows inline with two hints.

Lorenzo  writes:

> On Thu, 01 Jun 2023 12:05:51 +
> Alexandru Mihail  wrote:
>
>> I've uploaded again to mentors, the (now gone) lintian warning
>> complained about missing the SystemD service for the package. I've
>> added one from scratch and upon initial testing it performs OK.

Wonderful :) By the way, do you know if the forking service type is
needed for mini-httpd?  This page notes when that type is required:
https://wiki.debian.org/systemd/Services

>> I modified debian/rules to take the service into consideration though
>> this raises some concerns for non-systemd Debian installations. I
>> assume further modifications are required to intelligently enable or
>> ignore the service (use old init.d mechanism).

Thank you for considering the implications of your changes, especially
at this phase of the freeze when we all need to be really careful about
any changes.

> (looking at your rules file)
> override_dh_installinit:
>   dh_installinit --no-stop-on-upgrade --no-start --name=mini-httpd
>
> override_dh_installsystemd:
>   dh_installsystemd --name=mini-httpd
>
> if the '--no-stop-on-upgrade --no-start' is to avoid a conflict between
> the systemd service and the init.d file, you don't need that: debhelper
> generated scripts should do the right thing.
> If you look at generated maintscripts

One way to do this is 'dpkg-deb -R [aka: --raw-extract] archive directory',
then inspect the DEBIAN dir.

> you see that systemctl calls are guarded by a test for
> /run/systemd/system (it imply that systemd is the running init); the
> equivalent code for sysvinit (invoke.rc.d) is not guarded but that's
> ok since other inits are supposed to mask initscripts and systemd
> already does that.

Thanks again for your analysis and explanation Lorenzo!

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1026973: rrdtool FTBFS on 32-bit arches (may fail in testcase)

[Diederik de Haas]

On Thursday, 5 January 2023 19:15:43 CEST Diederik de Haas wrote:
> I cloned the rrdtool repo, added/enabled Salsa's CI and added the patch you
> proposed, but the `build i386` job still failed (it also failed without the
> patch): https://salsa.debian.org/diederik/rrdtool/-/pipelines/479591

https://salsa.debian.org/rrdtool-team/rrdtool/-/merge_requests/4 contains the 
changes I made to make Salsa's CI and thus the 'build i386' job succeed.


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

Bug#1037055: coreutils: od with multiple output modes falls out of alignment when address width changes

[наб]

Package: coreutils
Version: 9.1-1
Version: 8.32-4+b1
Severity: normal

Dear Maintainer,

# od   -txzoz -j 0xffFfFf -Ax /dev/sda | head
ff0081a400a491b60010a83563  >c5..<
   00040322000 000 2333000 02052032543  >c5..<
10f10a8356410a835640064  >d5..d5..d...<
   02052032544 02052032544 144 000  >d5..d5..d...<
11f0800040000f30a000400  ><
   010 0002000 00074605000 0002000  ><
12f  ><
   000 000 000 000  ><
*
15f20331d00009b  >..3 <

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

Kernel: Linux 6.1.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.36-9
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b6

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1037054: bullseye-pu: package libreswan/4.3-1+deb11u4

[Daniel Kahn Gillmor]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libres...@packages.debian.org, d...@fifthhorseman.net
Control: affects -1 + src:libreswan

[ Reason ]

Uploading libreswan 4.3-1+deb11u4 should address #1035542 (aka
CVE-2023-30570), which addresses a potential DoS against libreswan
instances that use a certain IKEv1 configuration.

Discussion with Salvatore Bonaccorso over in #1035542 concluded that
using point releases for this should be sufficient.

[ Impact ]

Users on bullseye with a specific libreswan configuration (IKEv1 in
aggressive mode) risk a DDoS on their libreswan IKE daemon if a
malicious attacker on the network emits a certain stream of packets.

[ Tests ]

Sadly, most libreswan test suites involve running virtual machines,
interacting with the linux kernel over open network policies, and this
isn't possible on debian testing architecture.

[ Risks ]

The risks of including these patches are minimal.

[ 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 changes deal solely with how the pluto IKE daemon handles error
cases on incoming IKEv1 packets in aggressive mode.

[ Other info ]

All of the above information has been agregated and adapted from
https://libreswan.org/security/CVE-2023-30570/ Upstream released
version 4.11, which is just 4.10 with comparable patches applied.
4.11 is in unstable now.

I'll be uploading an update to 4.10 for a bookworm point release
shortly as well.
diff -Nru libreswan-4.3/debian/changelog libreswan-4.3/debian/changelog
--- libreswan-4.3/debian/changelog  2023-03-03 08:34:50.0 -0500
+++ libreswan-4.3/debian/changelog  2023-06-01 16:14:59.0 -0400
@@ -1,3 +1,9 @@
+libreswan (4.3-1+deb11u4) bullseye; urgency=medium
+
+  * Resolve CVE-2023-30570 (Closes: #1035542)
+
+ -- Daniel Kahn Gillmor   Thu, 01 Jun 2023 16:14:59 
-0400
+
 libreswan (4.3-1+deb11u3) bullseye-security; urgency=high
 
   * use upstream patch for 4.2 and 4.3
diff -Nru libreswan-4.3/debian/patches/0005-Resolve-CVE-2023-30570.patch 
libreswan-4.3/debian/patches/0005-Resolve-CVE-2023-30570.patch
--- libreswan-4.3/debian/patches/0005-Resolve-CVE-2023-30570.patch  
1969-12-31 19:00:00.0 -0500
+++ libreswan-4.3/debian/patches/0005-Resolve-CVE-2023-30570.patch  
2023-06-01 16:14:59.0 -0400
@@ -0,0 +1,140 @@
+From: Daniel Kahn Gillmor 
+Date: Thu, 1 Jun 2023 16:12:50 -0400
+Subject: Resolve CVE-2023-30570
+
+see https://libreswan.org/security/CVE-2023-30570/CVE-2023-30570.txt
+
+This patch was ported from
+https://libreswan.org/security/CVE-2023-30570/CVE-2023-30570-libreswan-4.x.patch
+---
+ programs/pluto/ikev1.c  | 60 ++---
+ programs/pluto/ikev1_aggr.c |  5 ++--
+ 2 files changed, 60 insertions(+), 5 deletions(-)
+
+diff --git a/programs/pluto/ikev1.c b/programs/pluto/ikev1.c
+index 2a06c2c..bb6c7be 100644
+--- a/programs/pluto/ikev1.c
 b/programs/pluto/ikev1.c
+@@ -1249,10 +1249,20 @@ void process_v1_packet(struct msg_digest *md)
+   struct state *st = NULL;
+   enum state_kind from_state = STATE_UNDEFINED;   /* state we started in 
*/
+ 
++  /*
++   * For the initial responses, don't leak the responder's SPI.
++   * Hence the use of send_v1_notification_from_md().
++   *
++   * AGGR mode is a mess in that the R0->R1 transition happens
++   * well before the transition succeeds.
++   */
+ #define SEND_NOTIFICATION(t)  \
+   {   \
+   pstats(ikev1_sent_notifies_e, t);   \
+-  if (st != NULL) \
++  if (st != NULL &&   \
++  st->st_state->kind != STATE_AGGR_R0 &&  \
++  st->st_state->kind != STATE_AGGR_R1 &&  \
++  st->st_state->kind != STATE_MAIN_R0)\
+   send_notification_from_state(st, from_state, t); \
+   else\
+   send_notification_from_md(md, t);   \
+@@ -1322,17 +1332,26 @@ void process_v1_packet(struct msg_digest *md)
+   from_state = (md->hdr.isa_xchg == ISAKMP_XCHG_IDPROT ?
+ STATE_MAIN_R0 : STATE_AGGR_R0);
+   } else {
+-  /* not an initial message */
++  /*
++   * Possibly not an initial message.  Possibly
++   * from initiator.  Possibly from responder.
++   *
++   * Possibly.  

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

[James Addison]

On Fri, Jun 2, 2023, 15:30 James Addison  wrote:

> On Fri, 2 Jun 2023 at 15:24, James Addison  wrote:
> >
> > > > Also, arguing against my own revert-patch: I think it could be said
> > > > that multi-user is the "better" target to use here, because the
> > > > default could be "graphical" or some later-reached system state
> > > > whereas this is a relatively low-level (if small) system cleanup
> > > > service.
> > >
> > > Right, that's I believe the point of bug #991349; it's possible that
> > > the system adminsitrator might manually set default.target to point to
> > > graphical.target, per [1].  And since multi-user.target is a subset of
> > > graphical.target, it makes sense to make the Wanted-by to be
> > > multi-user.target.
> > >
> > > [1] https://www.baeldung.com/linux/systemd-target-multi-user
> >
> > I guess so.  However, now that I read it, the manual for
> > systemd.special[1] does indicate that the target it will load at boot
> > is default.target -- whatever it's configured to (usually multi-user
> > or graphical).
> >
> > In other words: default.target should be a subset of all of
> > multi-user.target, graphical.target, and whatever else a system
> > administrator might configure as the boot target state.
>
> Eh, poor phrasing there: default.target isn't a _subset_ of all those
> targets, but for any given systemd-enabled boot environment,
> default.target should be guaranteed (as far as systemd lives up to the
> guarantees it aims to provide) to be on the service startup path
> between systemd loading as init and systemd reaching the desired boot
> state.
>
> > > In this particular case, since we *always* want it to be
> > > default.target, since the whole *point* is to clean up after a failed
> > > e2scrub, it seems really unlikely to me that the system administrator
> > > would change this.  So this is one where it's probably fair for the
> > > postinstall script to just fix the wanted-by link **always** if the
> > > the systemd unit file says Wanted-by: default.target, and the symlink
> > > is inconsistent with it.
> >
> > What do you mean by "fix the link" in this context?
> >
> > [1] -
> https://manpages.debian.org/bullseye/systemd/systemd.special.7.en.html


After further thought here: if the change from #991349 to use
multi-user.target means slightly earlier invocation of the service when
working towards graphical.target, but _also_ means that the service won't
be invoked _at all_ on some systemd-enabled systems (whenever
default.target is configured to a state that doesn't visit
multi-user.target)... then I think rolling back to default.target would be
better.

Bug#1036243: Not Gwenview bug. Should be closed.

[MLHPUB]

Hi !

I have proceeded more tests because an Internet search reported 
suspicion with exiv2 and more precisely lib64exiv2 because I had to 
install exiv2 package for the following tests.

With a concerned picture, I have read meta-data with these commands :

EXIF data :
exiv2 -pt 20230528_113116.jpg = no problem

IPTC data :
exiv2 -pi 20230528_113116.jpg = no problem

XMP data :
exiv2 -px 20230528_113116.jpg = finish with following error

Xmp.exif.DateTimeOriginal    XmpText    19  Uncaught 
exception: basic_string::at: __n (which is 19) >= this->size() (which is 19)


Regards,

Matthieu

Bug#1036755: linux-image-6.1.0-9-amd64: Android ROM build on Debian breaks with the 6.1.0-9-amd64 kernel

[Infant V Patrick]

Package: src:linux
Version: 6.1.27-1
Followup-For: Bug #1036755
X-Debbugs-Cc: infant...@yahoo.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Doing Android build of a custom ROM using Debian unstable
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Following normal build process - reposync, buildenv and then brunch 
commands in the command line
   * What was the outcome of this action?
Error pasted below (snippet)
=
variant=generic --instruction-set-features=default 
--generate-mini-debug-info 
|| ( echo 'ERROR: Dex2oat failed to compile a boot image.
It is likely that the boot classpath is inconsistent.
Rebuild with ART_BOOT_IMAGE_EXTRA_ARGS="--runtime-arg -verbose:verifier" to see 
verification errors.' 
; false ) # hash of input list: 
156f4df5f1951bb33c62df25cb6fec2b621d15047fc47574974c2b5b1d6f1d05
dex2oatd F 06-01 04:37:58 815255 815255 mem_map_arena_pool.cc:65] 
Check failed: map.IsValid() Failed anonymous mmap((nil), 131072, 0x3, 0x22, -1, 
0): 
Cannot allocate memory. See process maps in the log.
Runtime aborting...
All threads:
DALVIK THREADS (24):


I can understand if this is with 8-10GB of RAM. However this is 
happening with a hard 50G of RAM allocated to the VM in HyperV. If 50g causes 
this then something is wrong.
I found this kernel bug and thats why I am reporting this issue
https://bugzilla.kernel.org/show_bug.cgi?id=216911

   * What outcome did you expect instead?
General outcome is for the compile to end normal and write the ROM zip 
file which it did in the linux-image-5.10.0-23-amd64 kernel

Please note the build worked fine when I rebooted to the 5.10 kernel which was 
present from the stable repo I had installed Debian originally from. So this is 
definitely kernel version related. Nothing was changed.

*** End of the template - remove these template lines ***


-- Package-specific info:
** Version:
Linux version 6.1.0-9-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08)

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-9-amd64 root=/dev/mapper/rootvg-root ro biosdevname=0 
ipv6.disable=1 audit=off rd.plymouth=0 plymouth.enable=0 apparmor=0

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

Please ask me for any information that you need. I dont know what is needed. I 
have used sosreport in RHEL.
Never sent anything similar in Debian.

** Model information
sys_vendor: Microsoft Corporation
product_name: Virtual Machine
product_version: Hyper-V UEFI Release v4.1
chassis_vendor: Microsoft Corporation
chassis_version: Hyper-V UEFI Release v4.1
bios_vendor: Microsoft Corporation
bios_version: Hyper-V UEFI Release v4.1
board_vendor: Microsoft Corporation
board_name: Virtual Machine
board_version: Hyper-V UEFI Release v4.1

** Loaded modules:
tls
binfmt_misc
nls_ascii
nls_cp437
vfat
fat
intel_rapl_msr
intel_rapl_common
ghash_clmulni_intel
sha512_ssse3
hyperv_drm
sha512_generic
hv_utils
ptp
drm_shmem_helper
serio_raw
hyperv_keyboard
hv_balloon
aesni_intel
pps_core
drm_kms_helper
sg
pcspkr
crypto_simd
cryptd
evdev
joydev
drm
configfs
fuse
loop
efi_pstore
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
dm_mod
sd_mod
t10_pi
crc64_rocksoft
sr_mod
crc64
crc_t10dif
cdrom
crct10dif_generic
hv_storvsc
hid_generic
scsi_transport_fc
hid_hyperv
scsi_mod
hv_netvsc
hid
scsi_common
crct10dif_pclmul
crct10dif_common
crc32_pclmul
crc32c_intel
hv_vmbus


** PCI devices:

** USB devices:
not available


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

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

Versions of packages linux-image-6.1.0-9-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20221128-1
ii  linux-base  4.9

Versions of packages linux-image-6.1.0-9-amd64 recommends:
ii  apparmor 3.0.8-3
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.1.0-9-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi-amd64  2.06-13
pn  linux-doc-6.1   

Versions of packages linux-image-6.1.0-9-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   

Bug#1037052: minidlna: CVE-2023-33476

[Salvatore Bonaccorso]

Source: minidlna
Version: 1.3.2+dfsg-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for minidlna.

CVE-2023-33476[0]:
| ReadyMedia (MiniDLNA) versions from 1.1.15 up to 1.3.2 is vulnerable
| to Buffer Overflow. The vulnerability is caused by incorrect
| validation logic when handling HTTP requests using chunked transport
| encoding. This results in other code later using attacker-controlled
| chunk values that exceed the length of the allocated buffer, resulting
| in out-of-bounds read/write.


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-2023-33476
https://www.cve.org/CVERecord?id=CVE-2023-33476
[1] https://blog.coffinsec.com/0day/2023/05/31/minidlna-heap-overflow-rca.html
[2] 
https://sourceforge.net/p/minidlna/git/ci/9bd58553fae5aef3e6dd22f51642d2c851225aec/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1037051: libfinance-quote-perl: Quotes from Yahoo stopped working again.

[David Engel]

Package: libfinance-quote-perl
Version: 1.54-3
Severity: normal
Tags: patch upstream

Dear Maintainer,

The fix for #1035690 was unfortunately short lived as Yahoo dropped
support for the older, Yahoo API.  However, upstream Finance::Quote
1.56 now has a better fix using the current, Yahoo API.  I replaced my
copy of YahooJSON.pm with the one from 1.56 and it solved my issue.

David

-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-security'), (100, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-9-amd64 (SMP w/32 CPU threads; PREEMPT)
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 libfinance-quote-perl depends on:
ii  libcgi-pm-perl 4.55-1
ii  libdatetime-format-strptime-perl   1.7900-1
ii  libdatetime-perl   2:1.59-1
pn  libencode-perl 
ii  libhtml-parser-perl3.81-1
ii  libhtml-tableextract-perl  2.15-2
ii  libhtml-tokeparser-simple-perl 3.16-4
ii  libhtml-tree-perl  5.07-3
ii  libhtml-treebuilder-xpath-perl 0.14-1.1
ii  libhttp-cookies-perl   6.10-1
ii  libhttp-message-perl   6.44-1
ii  libjson-parse-perl 0.62-1+b1
ii  libjson-perl   4.1-1
ii  liblwp-protocol-https-perl 6.10-1
ii  libreadonly-perl   2.050-3
ii  libscalar-list-utils-perl  1:1.63-1+b1
ii  libspreadsheet-xlsx-perl   0.17-1
ii  libstring-util-perl1.34-2
ii  libtext-template-perl  1.61-1
ii  libtry-tiny-perl   0.31-2
ii  liburi-perl5.17-1
ii  libweb-scraper-perl0.38-2
ii  libwww-perl6.68-1
ii  libxml-libxml-perl 2.0207+dfsg+really+2.0134-1+b1
ii  perl [libio-compress-perl] 5.36.0-7
ii  perl-base [libscalar-list-utils-perl]  5.36.0-7

libfinance-quote-perl recommends no packages.

libfinance-quote-perl suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/perl5/Finance/Quote/YahooJSON.pm (from 
libfinance-quote-perl package)

Bug#1035748: unblock: modsecurity/3.0.9-1

[Ervin Hegedüs]

On Fri, Jun 02, 2023 at 09:46:19PM +0200, Paul Gevers wrote:
> Hi,
> 
> On 01-06-2023 22:39, Ervin Hegedüs wrote:
> 
> > On Thu, Jun 01, 2023 at 09:52:06PM +0200, Paul Gevers wrote:
> > I think there is absolutely no risk. Bot package (libmodsecurity3
> > and libnginx-mod-http-modsecurity) is totally new packages, we
> > won't introduce any "unknown" issues.
> 
> Huh? src:modsecurity as been part of stable for at least two times.

yes, but nothing uses it. There is not any package which depends
on it.
 
> > these files (which created the huge diff) are generated by Bison.
> 
> Now that is extremely relevant information. Why wasn't that shared before
> (and filtered from the debdiff for that reason)?

I don't know... :(

> Does the same hold for all
> that .m4 stuff? Are those files recreated during the build?

I don't think that .m4 files are re-generated during the build
process.

The vendor of ModSecurity provides the generated Bison related
files, but it does not matter, because the generated files are
also have a huge diff.
 
> > (A side note: not these files (above) have huge diff, but the
> > derived ones: seclang-parser.cc, seclang-parser.hh,
> > seclang-scanner.cc)
> 
> But I didn't know... So, please tell me. Which files are generated?

In the upstream directory, here is the line which generates these
lines:

https://github.com/SpiderLabs/ModSecurity/blob/v3/master/src/parser/Makefile.am#L33

And these are the generated lines:

https://github.com/SpiderLabs/ModSecurity/blob/v3/master/src/parser/Makefile.am#L36-L42



a.

Bug#1037024: nmu: modsecurity-apache_2.9.7-1

[Ervin Hegedüs]

Hi Paul,

On Fri, Jun 02, 2023 at 10:16:09PM +0200, Paul Gevers wrote:
> Hi Ervin,
> 
> On 01-06-2023 22:54, Ervin Hegedüs wrote:
> > Now the module complains during the startup process, and users
> > wondering why.
> 
> I wonder why too. 

because of this messages:

[Wed May 31 13:11:05.165477 2023] [security2:notice] [pid 8:tid 1996017088] 
ModSecurity: APR compiled version="1.7.0"; loaded version="1.7.2"
[Wed May 31 13:11:05.165508 2023] [security2:warn] [pid 8:tid 1996017088] 
ModSecurity: Loaded APR do not match with compiled!

> What issues would this rebuild be papering over? Do you
> have a bug report number?

not for Debian, but the user opened an issue on Github:

https://github.com/SpiderLabs/ModSecurity/issues/2910

Thanks,

a.

Bug#1036071: fixed in gsl 2.7.1+dfsg-4

[Dirk Eddelbuettel]

On 2 June 2023 at 20:57, Paul Gevers wrote:
| Hi Dirk,
| 
| On 02-06-2023 20:38, Dirk Eddelbuettel wrote:
| > | Are you sure? I just diffed the source to see if I should unblock and
| > | got this:
| > 
| > I would appear I did NOT add that one line to debian/control !!  Doh !!
| > 
| > Shall I prepare a -5 ?
| 
| If that can happen this evening, then yes. I expect you only add a 
| Breaks. If not this evening (European time) it's too late.

Totally understood -- I just uploaded -5 and it has a minimal diff:

   
https://salsa.debian.org/edd/gsl/-/commit/da5283152b6afad29444eb8272e4a90ef42390c6

Thanks for spotting this, and for all your help in getting the release out.

Tschoe,  Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1036959: rasdaemon: invalid Maintainer field

[Cyril Brulebois]

Control: tag -1 patch pending

Mattia Rizzolo  (2023-05-30):
> v0.6.8-1 of this package has this in d/control:
> 
> Maintainer: Russell Coker , Taihsiang Ho 
> 
> 
> This is against Policy as there should only be one entity in this field.
> 
> 
> Also, as you noticed, this confused DDPO (actually carnivore) a lot...

On the release team side, we're not exactly sure what could break, or
how badly, if we were to try and publish Bookworm with this package…

Therefore, I've just uploaded an NMU, splitting the Maintainer field
into Maintainer + Uploaders, picking developers in order.

Source debdiff attached.


By the way, the declared VCS isn't up-to-date, and lacks tags for recent
uploads (last tag is debian/0.6.6-2, testing and unstable have 0.6.8-1
instead).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru rasdaemon-0.6.8/debian/changelog rasdaemon-0.6.8/debian/changelog
--- rasdaemon-0.6.8/debian/changelog	2023-02-06 08:24:59.0 +0100
+++ rasdaemon-0.6.8/debian/changelog	2023-06-02 22:12:50.0 +0200
@@ -1,3 +1,13 @@
+rasdaemon (0.6.8-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload, on the behalf of the release team, making sure
+we don't discover breakages when preparing the Bookworm release. 
+  * Fix too-many-contacts lintian error: the Maintainer field is not
+multi-valued, so keep the first developer in Maintainer and move the
+second one to Uploaders (Closes: #1036959).
+
+ -- Cyril Brulebois   Fri, 02 Jun 2023 22:12:50 +0200
+
 rasdaemon (0.6.8-1) unstable; urgency=medium
 
   * Remove the patch in the upstream
diff -Nru rasdaemon-0.6.8/debian/control rasdaemon-0.6.8/debian/control
--- rasdaemon-0.6.8/debian/control	2022-06-09 20:01:05.0 +0200
+++ rasdaemon-0.6.8/debian/control	2023-06-02 22:09:32.0 +0200
@@ -1,7 +1,8 @@
 Source: rasdaemon
 Section: admin
 Priority: optional
-Maintainer: Russell Coker , Taihsiang Ho 
+Maintainer: Russell Coker 
+Uploaders: Taihsiang Ho 
 Build-Depends: debhelper (>= 12), quilt, libsqlite3-dev, libgettextpo-dev,
  autoconf, dh-exec
 Standards-Version: 4.5.0


signature.asc
Description: PGP signature

Bug#1037043: pink-pony crashes on start

[Simon McVittie]

Control: retitle -1 sdl12-compat: makes pink-pony crash on start
Control: reassign -1 src:sdl12-compat
Control: found -1 1.2.60-1
Control: affects -1 pink-pony

On Fri, 02 Jun 2023 at 21:22:30 +0200, Jakub Wilk wrote:
> * Simon McVittie , 2023-06-02 19:33:
> > I recently uploaded sdl12-compat version 1.2.64 to experimental, and
> > from some quick testing it seems to run OK with that version.
> 
> Yup, upgrading libsdl1.2-compat-shim to 1.2.62-1 fixes it for me.

Reassigning, will close when reassigned.

Regressions like this are the reason I wasn't prepared to switch all of
Debian over to sdl12-compat in bookworm.

smcv

Bug#1037024: nmu: modsecurity-apache_2.9.7-1

[Paul Gevers]

Hi Ervin,

On 01-06-2023 22:54, Ervin Hegedüs wrote:

Now the module complains during the startup process, and users
wondering why.


I wonder why too. What issues would this rebuild be papering over? Do 
you have a bug report number?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Beauregard,Christophe (ECCC)]

And to answer the question about mtrace.

root@host:~# MALLOC_TRACE=mtrace.log  ./threadarena Zoom140.png
1685735077
   VSZ   RSS USER COMMAND
2312024 8124 root ./threadarena Zoom140.png
33
1685735078
   VSZ   RSS USER COMMAND
4605784 9684 root ./threadarena Zoom140.png
67
1685735079
   VSZ   RSS USER COMMAND
6899544 11232 root./threadarena Zoom140.png
101
1685735080
   VSZ   RSS USER COMMAND
9193304 12796 root./threadarena Zoom140.png
135
1685735081
   VSZ   RSS USER COMMAND
11487064 14328 root   ./threadarena Zoom140.png
169
1685735082
   VSZ   RSS USER COMMAND
13780824 15924 root   ./threadarena Zoom140.png
203
1685735084
   VSZ   RSS USER COMMAND
16074584 17424 root   ./threadarena Zoom140.png
237
1685735085
   VSZ   RSS USER COMMAND
18368344 19004 root   ./threadarena Zoom140.png
271
1685735086
   VSZ   RSS USER COMMAND
20662104 20536 root   ./threadarena Zoom140.png
305
1685735087
   VSZ   RSS USER COMMAND
20989784 21948 root   ./threadarena Zoom140.png
309
root@host:~# mtrace ./threadarena mtrace.log
- 0x7f31380008d0 Free 365 was never alloc'd 0x7f315afcc4d4
- 0x7f3150008a70 Free 367 was never alloc'd 0x7f315afcc4bb
- 0x7f3150006ed0 Free 369 was never alloc'd 0x7f315afcc4bb
- 0x7f3150008300 Free 370 was never alloc'd 0x7f315afcc4bb
- 0x7f3150008a90 Free 371 was never alloc'd 0x7f315afcc4bb
- 0x7f315000b350 Free 372 was never alloc'd 0x7f315afcc4bb
- 0x7f315000b150 Free 373 was never alloc'd 0x7f315afcc4bb
- 0x7f315000b050 Free 374 was never alloc'd 0x7f315afcc4bb
- 0x7f315000af50 Free 375 was never alloc'd 0x7f315afcc4bb
...
- 0x7f2c5000a610 Free 3839 was never alloc'd 0x7f315afcc4bb
- 0x7f2c50002d90 Free 3840 was never alloc'd 0x7f315afcc4bb
- 0x7f2c50007df0 Free 3842 was never alloc'd 0x7f315afcc4bb
- 0x7f2c50011940 Free 3843 was never alloc'd 0x7f315afcc4bb
- 0x7f2c50011ad0 Free 3844 was never alloc'd 0x7f315afcc4bb
- 0x7f2c5000a740 Free 3846 was never alloc'd 0x7f315afcc4bb
- 0x7f2c58d0 Free 3847 was never alloc'd 0x7f315afcc4d4

Memory not freed:
-
   Address Size Caller
0x555b1d8652d0 0xd0  at 0x7f315a4a90f9

There's a total of 514 "Free xxx was never alloc'd" messages, which doesn't 
match the thread arena leaks. It might match the total number of threads OpenMP 
might use, but it seems a bit off.

As an extra data point, restricting the number of OpenMP threads doesn't fix 
the problem:

root@host:~# OMP_NUM_THREADS=8 ./threadarena  Zoom140.png
1685735486
   VSZ   RSS USER COMMAND
345944  8324 root ./threadarena Zoom140.png
4
1685735487
   VSZ   RSS USER COMMAND
608088  9724 root ./threadarena Zoom140.png
7
1685735488
   VSZ   RSS USER COMMAND
870232 11156 root ./threadarena Zoom140.png
10
1685735489
   VSZ   RSS USER COMMAND
1132376 12556 root./threadarena Zoom140.png
13
1685735490
   VSZ   RSS USER COMMAND
1394520 13988 root./threadarena Zoom140.png
16
1685735491
   VSZ   RSS USER COMMAND
1656664 15388 root./threadarena Zoom140.png
19
1685735492
   VSZ   RSS USER COMMAND
1918808 16820 root./threadarena Zoom140.png
22
1685735493
   VSZ   RSS USER COMMAND
2180952 18220 root./threadarena Zoom140.png
25
1685735494
   VSZ   RSS USER COMMAND
2443096 19652 root./threadarena Zoom140.png
28
1685735495
   VSZ   RSS USER COMMAND
2705240 21052 root./threadarena Zoom140.png
31


From: Beauregard,Christophe (ECCC) 
Sent: Friday, June 2, 2023 15:32
To: Bob Friesenhahn ; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak

I'm kind of stuck with this version of GM; my organization is currently 
tracking Debian LTS.

I suppose I should have added some more points... while digging into this I did 
run diagnostics under gdb on my "real" application.

The threads themselves are terminating correctly; there aren't any 
lingering/unjoined threads, and the internal pthreads cleanup routines are all 
being hit. No sign of any red flags.

Running with MAGICK_DEBUG=resource:

root@host:~# MAGICK_DEBUG=resource ./threadarena  Zoom140.png
18:46:16 0:0.000223  0.000u 2666849 
resource.c/InitializeMagickResources/447/Resource:
  Total physical memory 128776 MB (3298 pages and 4096 bytes per page)
18:46:16 0:0.000279  0.000u 2666849 
resource.c/InitializeMagickResources/615/Resource:
  40 CPU cores are available
18:46:16 0:0.000294  0.000u 2666849 
resource.c/InitializeMagickResources/644/Resource:
  System file open limits are 1024 soft, 1048576 hard
18:46:16 0:0.000306  0.000u 2666849 
resource.c/SetMagickResourceLimit/964/Resource:
  Set files resource limit to 256
18:46:16 0:0.000321  0.000u 2666849 
resource.c/SetMagickResourceLimit/964/Resource:
  Set map resource limit to 251.5GiB
18:46:16 0:0.000332  0.000u 2666849 

Bug#1035748: unblock: modsecurity/3.0.9-1

[Paul Gevers]

Hi,

On 01-06-2023 22:39, Ervin Hegedüs wrote:

sorry to join this conversation :),


No, not at all.


On Thu, Jun 01, 2023 at 09:52:06PM +0200, Paul Gevers wrote:
I think there is absolutely no risk. Bot package (libmodsecurity3
and libnginx-mod-http-modsecurity) is totally new packages, we
won't introduce any "unknown" issues.


Huh? src:modsecurity as been part of stable for at least two times.


these files (which created the huge diff) are generated by Bison.


Now that is extremely relevant information. Why wasn't that shared 
before (and filtered from the debdiff for that reason)? Does the same 
hold for all that .m4 stuff? Are those files recreated during the build?



(A side note: not these files (above) have huge diff, but the
derived ones: seclang-parser.cc, seclang-parser.hh,
seclang-scanner.cc)


But I didn't know... So, please tell me. Which files are generated?

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034378: Allow Percentage Formatting in apt

[Emir SARI]

Hello,

MR created: https://salsa.debian.org/apt-team/apt/-/merge_requests/294

Best regards,
Emir (ఽ఺఍)

** E-mail needs to stay simple
** Use plain text e-mail

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Beauregard,Christophe (ECCC)]

I'm kind of stuck with this version of GM; my organization is currently 
tracking Debian LTS.

I suppose I should have added some more points... while digging into this I did 
run diagnostics under gdb on my "real" application.

The threads themselves are terminating correctly; there aren't any 
lingering/unjoined threads, and the internal pthreads cleanup routines are all 
being hit. No sign of any red flags.

Running with MAGICK_DEBUG=resource:

root@host:~# MAGICK_DEBUG=resource ./threadarena  Zoom140.png
18:46:16 0:0.000223  0.000u 2666849 
resource.c/InitializeMagickResources/447/Resource:
  Total physical memory 128776 MB (3298 pages and 4096 bytes per page)
18:46:16 0:0.000279  0.000u 2666849 
resource.c/InitializeMagickResources/615/Resource:
  40 CPU cores are available
18:46:16 0:0.000294  0.000u 2666849 
resource.c/InitializeMagickResources/644/Resource:
  System file open limits are 1024 soft, 1048576 hard
18:46:16 0:0.000306  0.000u 2666849 
resource.c/SetMagickResourceLimit/964/Resource:
  Set files resource limit to 256
18:46:16 0:0.000321  0.000u 2666849 
resource.c/SetMagickResourceLimit/964/Resource:
  Set map resource limit to 251.5GiB
18:46:16 0:0.000332  0.000u 2666849 
resource.c/SetMagickResourceLimit/964/Resource:
  Set memory resource limit to 125.8GiB
18:46:16 0:0.000343  0.000u 2666849 
resource.c/SetMagickResourceLimit/964/Resource:
  Set threads resource limit to 40
18:46:16 0:0.001345  0.000u 2666849 
resource.c/AcquireMagickResource/235/Resource:
  width +414P//256.0MiP
18:46:16 0:0.001372  0.000u 2666849 
resource.c/AcquireMagickResource/235/Resource:
  height +377P//256.0MiP
18:46:16 0:0.001383  0.000u 2666849 
resource.c/AcquireMagickResource/235/Resource:
  pixels +152.4KiP//Unlimited
18:46:16 0:0.001394  0.000u 2666849 
resource.c/AcquireMagickResource/235/Resource:
  memory +1.5MiB/1.5MiB/125.8GiB
18:46:16 0:0.019786  0.010u 2666849 
resource.c/LiberateMagickResource/811/Resource:
  memory -1.5MiB/0B/125.8GiB
1685731577
   VSZ   RSS USER COMMAND
2443096 8280 root ./threadarena Zoom140.png
35
18:46:17 0:1.054500  0.100u 2666849 
resource.c/AcquireMagickResource/235/Resource:
  width +414P//256.0MiP
18:46:17 0:1.054537  0.100u 2666849 
resource.c/AcquireMagickResource/235/Resource:
  height +377P//256.0MiP
18:46:17 0:1.054554  0.100u 2666849 
resource.c/AcquireMagickResource/235/Resource:
  pixels +152.4KiP//Unlimited
18:46:17 0:1.054574  0.100u 2666849 
resource.c/AcquireMagickResource/235/Resource:
  memory +1.5MiB/1.5MiB/125.8GiB
18:46:17 0:1.073180  0.170u 2666849 
resource.c/LiberateMagickResource/811/Resource:
  memory -1.5MiB/0B/125.8GiB
1685731578
   VSZ   RSS USER COMMAND
4802392 9848 root ./threadarena Zoom140.png
70

...

20989784 31940 root   ./threadarena Zoom140.png
302
18:46:34 0:17.922374 2.080u 2666849 
resource.c/AcquireMagickResource/235/Resource:
  width +414P//256.0MiP
18:46:34 0:17.922409 2.080u 2666849 
resource.c/AcquireMagickResource/235/Resource:
  height +377P//256.0MiP
18:46:34 0:17.922426 2.080u 2666849 
resource.c/AcquireMagickResource/235/Resource:
  pixels +152.4KiP//Unlimited
18:46:34 0:17.922448 2.080u 2666849 
resource.c/AcquireMagickResource/235/Resource:
  memory +1.5MiB/1.5MiB/125.8GiB
18:46:34 0:17.943440 2.180u 2666849 
resource.c/LiberateMagickResource/811/Resource:
  memory -1.5MiB/0B/125.8GiB

0B, which backs up what I saw with valgrind/memcheck. It leaks, but it's not a 
resource leak that GM seems to be able to track.

Unfortunately/interestingly, this test application doesn't quite show the same 
behaviour under valgrind. That is, if I modify it to only run 10 cycles:

root@host:~# valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all  
./threadarena  Zoom140.png
==2674090== Memcheck, a memory error detector
==2674090== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2674090== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==2674090== Command: ./threadarena Zoom140.png
==2674090==
1685732666
   VSZ   RSS USER COMMAND
224116 115612 root/usr/bin/valgrind.bin --tool=memcheck --leak-check=full --
0
1685732677
   VSZ   RSS USER COMMAND
224196 116692 root/usr/bin/valgrind.bin --tool=memcheck --leak-check=full --
0
1685732689
   VSZ   RSS USER COMMAND
228388 118252 root/usr/bin/valgrind.bin --tool=memcheck --leak-check=full --
0
1685732701
   VSZ   RSS USER COMMAND
228452 119784 root/usr/bin/valgrind.bin --tool=memcheck --leak-check=full --
0
1685732711
   VSZ   RSS USER COMMAND
232644 121336 root/usr/bin/valgrind.bin --tool=memcheck --leak-check=full --
0
1685732721
   VSZ   RSS USER COMMAND
232724 122880 root/usr/bin/valgrind.bin --tool=memcheck --leak-check=full --
0
1685732732
   VSZ   RSS USER COMMAND
236916 124440 root/usr/bin/valgrind.bin --tool=memcheck --leak-check=full --
0
1685732743
   VSZ   RSS USER COMMAND
236980 125972 root/usr/bin/valgrind.bin 

Bug#1037043: pink-pony crashes on start

[Jakub Wilk]

* Simon McVittie , 2023-06-02 19:33:
I recently uploaded sdl12-compat version 1.2.64 to experimental, and 
from some quick testing it seems to run OK with that version.


Yup, upgrading libsdl1.2-compat-shim to 1.2.62-1 fixes it for me.

--
Jakub Wilk

Bug#1036190: kmail: Crash on startup when GHNS is disabled in kde5rc

[Pijgn]

On Fri, 02 Jun 2023 08:37:16 +0200 Felix Stupp wrote:
> I have the same issue that kmail on version 4:22.12.3-1 does
> eventually but always crash after a certain time or action.

> I haven't set the "ghns" key to false in /etc/kde5rc,

This is unlikely to be the same bug, but you can get more information by 
generating a kcrash report with drkonqi. For a meaningful report, you 
will also need to add the debug repository [0] to your apt sources and 
install the appropriate -dbgsym packages. For example, I needed kmail-
dbgsym, kdepim-addons-dbgsym, and libkf5newstuffwidgets5-dbgsym to 
completely contextualize the crash report attached to my initial email. 
'find-dbgsym-packages' in debian-goodies [1] may be more efficient than 
what I did (searching packages.debian.org for shared object filenames).

If your crash is not caused by KNSWidgets::Action::setConfigFile, you 
should submit a new bug about it.

[0] "deb http://deb.debian.org/debian-debug/ bookworm-debug main"
[1] https://packages.debian.org/bookworm/debian-goodies

Bug#1035542: libreswan: CVE-2023-30570: Incorrect aggressive mode interaction causes the pluto daemon to crash

[Salvatore Bonaccorso]

Hi Daniel,

On Thu, Jun 01, 2023 at 05:19:06PM -0400, Daniel Kahn Gillmor wrote:
> Control: found 1035542 4.3-1+deb11u3
> Control: tags 1035542 + patch
> 
> Thanks for the documentation of CVE-2023-30570 on
> https://bugs.debian.org/1035542, Salvatore.
> 
> fwiw, i don't think this is particularly serious -- the vulnerability
> only appears to be dangerous if the libreswan endpoint is configured to
> allow IKEv1 in aggressive mode.

Thanks for having a closer look and for your assessment. Then I
believe we can have a fix scheduled via respective point releases, I
do not see an urgency for it requiring a DSA. Initially I was not
completely sure about it.

> Since 4.5-2, libreswan's ikev1-policy has defaulted to "drop", and we've
> heard no complaints from users that this has been an impediment, so i
> have my doubts about how many people have such a configuration.
> 
> That said, in bullseye, it is still a plausible choice.
> 
> I'm attaching the patch here for bullseye (against v4.3), which i can
> upload to bullseye-security whenever you you think is appropriate.

Let's fix it via the next bullseye point release (and as well first
bookworm point release).
> 
> For v4.10 (which is in bookworm, about to be stable) i think the best
> move is to just ship v4.11 directly.  I'm also attaching here the diff
> between upstream's v4.10 and v4.11 -- it is a narrowly-targeted bugfix
> release.  i think it makes more sense to just ship v4.11 as a security
> update to bookworm (since i missed the freeze cutoff, apologies) rather
> than to try to ship v4.10 plus basically the same patch.

Note we are now almost late for bookworm. The last date for asking for
unlbocks was last weekend, and now this weekend entering the quiet
phase where no changes will happen (unless urgencies arise). 

So that's unfortunate, but we missed the window. Unless you can
convince the release team to still accept a fix in (from security team
point of view while welcome, I could understand that you will now get
a NACK).

As usual, thanks for your work on libreswan maintenance in Debian!

Regards,
Salvatore

Bug#910970: flameshot: does not work on debian buster under wayland

[JavierDebian]

Hi.

The solution is impement that descibed in this post:

https://github.com/flameshot-org/flameshot/issues/2848

The user pintassilgo found the issue and fixed it.

The user zorn-v made this script that work fine:



#!/bin/bash

set  -e

rm -rf build
mkdir -p build
cd  build

sudo apt install devscripts equivs libkf5guiaddons-dev -y
sudo mk-build-deps -t'apt-get -y'  -ir flameshot

aptsource  flameshot
SRC_DIR=`ls | cut -f1 | head -n1`

pushd  ${SRC_DIR}
sed -i's/-DFLAMESHOT_ABOUT_DEB_VERSION/-DUSE_WAYLAND_CLIPBOARD=1 
-DFLAMESHOT_ABOUT_DEB_VERSION/'  debian/rules

EMAIL=nob...@email.com  dch -n''
debuild -i -j -us -uc
popd

sudo apt purge flameshot-build-deps devscripts equivs libkf5guiaddons-dev 
--auto-remove -y

sudo dpkg -i flameshot_*.deb
rm -rf ../build
==



SUGGEST:  Make the binary with the-DUSE_WAYLAND_CLIPBOARD=1  option set, 
because it works fine in X11 and Wayland.

Regards.

Bug#1035871: flare-engine: broken symlink: /usr/share/games/flare/mods/default/fonts/unifont-10.0.06.ttf -> ../../../../../fonts/truetype/unifont/unifont.ttf

[James Addison]

Followup-For: Bug #1035871
X-Debbugs-Cc: elb...@debian.org

[ not a maintainer, but I have tested the behaviour of this bug ]

On Thu, 1 Jun 2023 11:57:46 +0200, Paul wrote:
> On Wed, 10 May 2023 13:54:11 +0200 Andreas Beckmann  wrote:
> > fonts-unifont does no longer ship unifont.ttf or other *.ttf.
> > There are only the *.otf variants left in most cases.
> 
> How bad is this in practice? Does flare-engine break completely or is 
> this mostly an annoyance? (I can imagine either or anything in between)

In short: the game remains playable in English-language, but becomes practically
unusable in other supported locales (ja, ko, zh, zh_TW).

For affected locales, a (non-fatal) error prompt appears and in-game text is
absent.  Empty labels appear wherever menu/game text is expected, and error
messages of the following form are output to stdout:

  ERROR: FontEngine: Invalid font 'font_'. No fallback available.


Workaround:

As Andreas mentions, an otf font variant exist.  The game does correctly load
and display fonts from this file when the symlink is updated to point to that
file.

Also note:

The package 'cataclysm-dda-data' was similarly affected; see bug #1022269 for
details.

Bug#1036187: vfu: several notes about clipboard

[Anonymous 648]

Hi Vladi.
Seems to be working fine now

On Thu, Jun 01, 2023 at 12:14:57AM +0300, Vladi Belperchinov-Shabanski wrote:


hi,

I fixed it with commit 2cfa35ceef551708481626732a4d98734e7a0f22.
also fixed size calculation so it will properly report progress
and estimate time when copy/move from the clipboard.

try it again?

P! Vladi.
--
Vladi Belperchinov-Shabanski
  
http://cade.noxrun.com
pgp/gpg key 6F35B214 @ http://pgp.mit.edu

Bug#1037050: Please package libstd-rust-dev-macos

[Matt Corallo]

Package: src:rustc
Version: 1.63.0+dfsg1-2

Similar to libstd-rust-dev-windows, it would be nice to have a macos version as well, which is 
generally well-supported by clang/LLVM/rustc.

Bug#1036071: fixed in gsl 2.7.1+dfsg-4

[Paul Gevers]

Hi Dirk,

On 02-06-2023 20:38, Dirk Eddelbuettel wrote:

| Are you sure? I just diffed the source to see if I should unblock and
| got this:

I would appear I did NOT add that one line to debian/control !!  Doh !!

Shall I prepare a -5 ?


If that can happen this evening, then yes. I expect you only add a 
Breaks. If not this evening (European time) it's too late.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Bob Friesenhahn]

Christophe,

It would be good to test a modern GM version which supports "resource 
limited memory".  Probably Debian's 1.4 version supports that.


For a version which supports the resource limited memory allocator, 
you can set 'MAGICK_DEBUG=resource' in the environment prior to 
running the program.  This will cause very verbose output with a tally 
similar to:


13:27:40 0:0.007952  0.050u 173194 resource.c/unknown/236/Resource:
  memory +65.2MiB/81.0MiB/39.0GiB
13:27:40 0:0.027664  0.190u 173194 resource.c/unknown/818/Resource:
  memory -3.3KiB/81.0MiB/39.0GiB
13:27:40 0:0.027692  0.190u 173194 resource.c/unknown/818/Resource:
.
.
.
13:27:40 0:0.033629  0.220u 173194 resource.c/unknown/818/Resource:
  memory -65.2MiB/0B/39.0GiB

The "0B" at the end means that at least as related to memory allocated 
by the resource limited memory allocator (used only for non-public 
allocations), there are no leaks.


The type of leak you seem to be finding is a thread-specific memory 
allocation leak where a destructor did not fire to free the memory 
when the thread quit.  I don't believe that GetImageDepth() uses 
thread-specific memory but the "thread arena"s that you are talking 
about likely do.


For allocations which specifically use a memory allocator, I have had 
some good luck using Glibc's mtrace.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Bug#1037036: ITP: autogram -- eIDAS-compliant document signing tool

[Andrej Shadura]

Hi,

On Fri, 2 Jun 2023, at 20:13, Gioele Barabucci wrote:
> On 02/06/23 13:28, Andrej Shadura wrote:
>>Description : eIDAS-compliant document signing tool
>> 
>> Autogram is a cross-platform (Windows, MacOS, Linux) desktop JavaFX
>> application to sign documents accordancing to the eIDAS standard.
>> The user can use it to sign files directly, or the application can be
>> easily integrated into your own (web) information system using the
>> HTTP API.
>
> The documentation hints at the fact that this application works only in 
> conjunction with Slovenian eIDs.

It's Slovak, not Slovenian.

> This (current?) limitation should be mentioned in the short and long 
> descriptions.

It does in fact work with anything, as long as has a PKCS #11 provider.

-- 
Cheers,
  Andrej

Bug#1036259: moment-timezone.js: FTBFS in testing: make[1]: *** [debian/rules:28: execute_before_dh_auto_configure] Error 1

[Martina Ferrari]

Update:

I have just uploaded the package, force-pushed my changes to master, and 
 submitted the unblock request: #1037049


On 02/06/2023 19:13, Martina Ferrari wrote:
On Sun, 28 May 2023 18:15:14 +0200 gregor herrmann  
wrote:

On Sun, 28 May 2023 20:05:09 +0400, Yadd wrote:

> > This looked reasonably easy to fix (cf. attached patch), but the
> > tests fail as follows:
> I fixed it in salsa (needs an update to import 2023 data). I'm 
waiting for

> Martina review who maintains it.

Ack, I've seen your commits in salsa but as the pipeline fails
(probably the version in d/changelog?) and as a new upstream release
2 weeks before the release might not be accepted by the release team,
I thougt I'd give it a try as well; but well, it was not that
quick :)


Agreed. The upstream release is not much more than a repackaging of the 
Olson database and adjusting the tests to match, but the debdiff is 
enormous.


Luckily, the debian/rules I wrote a few years ago takes care of updating 
the data files and tests based on the installed tzdata package (which 
should match the last part of the debian package version).


The only thing that needs to be handled separately are the countries.js 
test file, which is manually maintained. So I just made a quilt patch 
based on the git diff from upstream.


I have just prepared a new package like this, the debdiff is fairly 
minimal:


$ debdiff moment-timezone.js_0.5.40+dfsg-1+2022g.dsc 
moment-timezone.js_0.5.40+dfsg-1+2023c.dsc | diffstat

  changelog |   10 ++
  control   |    4 ++--
  patches/02-tzdata-2023c.patch |   42 
++

  patches/series    |    1 +
  4 files changed, 55 insertions(+), 2 deletions(-)

Sadly, Yadd changes were already pushed to master, so I will have to do 
some git history rewriting. Please update your local clones accordingly.





--
Martina Ferrari (Tina)

Bug#1037036: ITP: autogram -- eIDAS-compliant document signing tool

[Gioele Barabucci]

On 02/06/23 20:25, Andrej Shadura wrote:

The documentation hints at the fact that this application works only in
conjunction with Slovenian eIDs.


It's Slovak, not Slovenian.


Yes, right. Common lapsus lingue, isn't it? :)


This (current?) limitation should be mentioned in the short and long
descriptions.


It does in fact work with anything, as long as has a PKCS #11 provider.


The README on GitHub says:

> Momentálne podporujeme na Slovensku bežne používané karty
> a ich ovládače:
>
> * občiansky preukaz (eID klient)
> * I.CA SecureStore
> * MONET+ ProID+Q
> * Gemalto IDPrime 940
>
> Doplniť ďalšie je pomerne ľahké pokiaľ používajú PKCS#11.

I read this as "Support for other kinds of eIDs is _possible and easy_ 
as long as they support PKCS#11, but _not automatic_". Am I reading this 
wrong?


Regards,

--
Gioele Barabucci

Bug#1036071: fixed in gsl 2.7.1+dfsg-4

[Dirk Eddelbuettel]

On 2 June 2023 at 20:19, Paul Gevers wrote:
| Hi Dirk,
| 
| On Mon, 15 May 2023 03:04:06 + Debian FTP Masters 
|  wrote:
| >  gsl (2.7.1+dfsg-4) unstable; urgency=medium
| >  .
| >* debian/control: Add explicit 'Breaks: libgsl25' (with thanks to
| >  Andreas Beckmann for the suggestion)   (Closes: #1036071)
| 
| Are you sure? I just diffed the source to see if I should unblock and 
| got this:

I would appear I did NOT add that one line to debian/control !!  Doh !!

Shall I prepare a -5 ?

Dirk
 
| diff -Nru gsl-2.7.1+dfsg/debian/changelog gsl-2.7.1+dfsg/debian/changelog
| --- gsl-2.7.1+dfsg/debian/changelog 2021-12-06 21:20:43.0 +
| +++ gsl-2.7.1+dfsg/debian/changelog 2023-05-15 02:25:16.0 +
| @@ -1,3 +1,12 @@
| +gsl (2.7.1+dfsg-4) unstable; urgency=medium
| +
| +  * debian/control: Add explicit 'Breaks: libgsl25' (with thanks to
| +Andreas Beckmann for the suggestion)   (Closes: #1036071)
| +
| +  * debian/control: Set Standards-Version: to current version
| +
| + -- Dirk Eddelbuettel   Sun, 14 May 2023 21:25:16 -0500
| +
|   gsl (2.7.1+dfsg-3) unstable; urgency=medium
| 
| * debian/control: Support DEB_BUILD_PROFILES for libgsl0-prof package
| diff -Nru gsl-2.7.1+dfsg/debian/control gsl-2.7.1+dfsg/debian/control
| --- gsl-2.7.1+dfsg/debian/control   2021-12-06 21:18:28.0 +
| +++ gsl-2.7.1+dfsg/debian/control   2023-05-15 02:25:16.0 +
| @@ -2,7 +2,7 @@
|   Section: math
|   Priority: optional
|   Maintainer: Dirk Eddelbuettel 
| -Standards-Version: 4.5.1
| +Standards-Version: 4.6.2
|   Build-Depends: gawk | awk, debhelper-compat (= 12), gcc (>= 4:4.0), 
| binutils (>= 2.12.90.0.9)
|   Vcs-Browser: https://salsa.debian.org/edd/gsl
|   Vcs-Git: https://salsa.debian.org/edd/gsl.git
| @@ -142,4 +142,4 @@
|suitable for use with gprof.
|.
|URL: http://www.gnu.org/software/gsl/
| -
| \ No newline at end of file
| +
| x[DELETED ATTACHMENT OpenPGP_signature, application/pgp-signature]

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1037043: pink-pony crashes on start

[Simon McVittie]

(Please keep the subject line intact so message recipients have context)

On Fri, 02 Jun 2023 at 19:23:12 +0200, Judit Foglszinger wrote:
> seems, [pink-pony] only crashes with libsdl1.2-compat-shim installed

I recently uploaded sdl12-compat version 1.2.64 to experimental, and
from some quick testing it seems to run OK with that version.

I'm hoping to make sdl12-compat the default/only implementation of the
SDL 1.2 API/ABI in Debian 13.

smcv

Bug#1037036: ITP: autogram -- eIDAS-compliant document signing tool

[Gioele Barabucci]

On 02/06/23 13:28, Andrej Shadura wrote:

   Description : eIDAS-compliant document signing tool

Autogram is a cross-platform (Windows, MacOS, Linux) desktop JavaFX
application to sign documents accordancing to the eIDAS standard.
The user can use it to sign files directly, or the application can be
easily integrated into your own (web) information system using the
HTTP API.


The documentation hints at the fact that this application works only in 
conjunction with Slovenian eIDs.


This (current?) limitation should be mentioned in the short and long 
descriptions.


Regards,

--
Gioele Barabucci

Bug#1036259: moment-timezone.js: FTBFS in testing: make[1]: *** [debian/rules:28: execute_before_dh_auto_configure] Error 1

[Martina Ferrari]

On Sun, 28 May 2023 18:15:14 +0200 gregor herrmann  
wrote:

On Sun, 28 May 2023 20:05:09 +0400, Yadd wrote:

> > This looked reasonably easy to fix (cf. attached patch), but the
> > tests fail as follows:
> I fixed it in salsa (needs an update to import 2023 data). I'm waiting for
> Martina review who maintains it.

Ack, I've seen your commits in salsa but as the pipeline fails
(probably the version in d/changelog?) and as a new upstream release
2 weeks before the release might not be accepted by the release team,
I thougt I'd give it a try as well; but well, it was not that
quick :)


Agreed. The upstream release is not much more than a repackaging of the 
Olson database and adjusting the tests to match, but the debdiff is 
enormous.


Luckily, the debian/rules I wrote a few years ago takes care of updating 
the data files and tests based on the installed tzdata package (which 
should match the last part of the debian package version).


The only thing that needs to be handled separately are the countries.js 
test file, which is manually maintained. So I just made a quilt patch 
based on the git diff from upstream.


I have just prepared a new package like this, the debdiff is fairly minimal:

$ debdiff moment-timezone.js_0.5.40+dfsg-1+2022g.dsc 
moment-timezone.js_0.5.40+dfsg-1+2023c.dsc | diffstat

 changelog |   10 ++
 control   |4 ++--
 patches/02-tzdata-2023c.patch |   42 
++

 patches/series|1 +
 4 files changed, 55 insertions(+), 2 deletions(-)

Sadly, Yadd changes were already pushed to master, so I will have to do 
some git history rewriting. Please update your local clones accordingly.



--
Martina Ferrari (Tina)

Bug#1036071: fixed in gsl 2.7.1+dfsg-4

[Paul Gevers]

Hi Dirk,

On Mon, 15 May 2023 03:04:06 + Debian FTP Masters 
 wrote:

 gsl (2.7.1+dfsg-4) unstable; urgency=medium
 .
   * debian/control: Add explicit 'Breaks: libgsl25' (with thanks to
 Andreas Beckmann for the suggestion)   (Closes: #1036071)


Are you sure? I just diffed the source to see if I should unblock and 
got this:


diff -Nru gsl-2.7.1+dfsg/debian/changelog gsl-2.7.1+dfsg/debian/changelog
--- gsl-2.7.1+dfsg/debian/changelog 2021-12-06 21:20:43.0 +
+++ gsl-2.7.1+dfsg/debian/changelog 2023-05-15 02:25:16.0 +
@@ -1,3 +1,12 @@
+gsl (2.7.1+dfsg-4) unstable; urgency=medium
+
+  * debian/control: Add explicit 'Breaks: libgsl25' (with thanks to
+Andreas Beckmann for the suggestion)   (Closes: #1036071)
+
+  * debian/control: Set Standards-Version: to current version
+
+ -- Dirk Eddelbuettel   Sun, 14 May 2023 21:25:16 -0500
+
 gsl (2.7.1+dfsg-3) unstable; urgency=medium

   * debian/control: Support DEB_BUILD_PROFILES for libgsl0-prof package
diff -Nru gsl-2.7.1+dfsg/debian/control gsl-2.7.1+dfsg/debian/control
--- gsl-2.7.1+dfsg/debian/control   2021-12-06 21:18:28.0 +
+++ gsl-2.7.1+dfsg/debian/control   2023-05-15 02:25:16.0 +
@@ -2,7 +2,7 @@
 Section: math
 Priority: optional
 Maintainer: Dirk Eddelbuettel 
-Standards-Version: 4.5.1
+Standards-Version: 4.6.2
 Build-Depends: gawk | awk, debhelper-compat (= 12), gcc (>= 4:4.0), 
binutils (>= 2.12.90.0.9)

 Vcs-Browser: https://salsa.debian.org/edd/gsl
 Vcs-Git: https://salsa.debian.org/edd/gsl.git
@@ -142,4 +142,4 @@
  suitable for use with gprof.
  .
  URL: http://www.gnu.org/software/gsl/
-
\ No newline at end of file
+


OpenPGP_signature
Description: OpenPGP digital signature

Bug#975495: ITP gping

[Tom Forbes]

Is there anything I can do as the maintainer to help move this forward?

Bug#1005359:

[Jari Kuittinen]

The
Option "UseGammaLUT" "false"
workaround mentioned here fixes the blank screen issue on current bookworm.

Bug#1037048: coreutils: od: -tc doesn't work at all?

[наб]

Package: coreutils
Version: 9.1-1
Version: 8.32-4+b1
Severity: normal

Dear Maintainer,

Issue 8 Draft 3, XCU, od, OPTIONS says:
108132  −t type_string
108133Specify one or more output types. See the EXTENDED DESCRIPTION 
section. The
108134application shall ensure that the type_string option-argument is a 
string specifying
108135the types to be used when writing the input data. The string shall 
consist of the
108136type specification characters a, c, d, f, o, u, and x, specifying 
named character,
108137character, signed decimal, floating point, octal, unsigned decimal, 
and
108138hexadecimal, respectively. The type specification characters d, f, o, 
u, and x can be
108139followed by an optional unsigned decimal integer that specifies the 
number of
108140bytes to be transformed by each instance of the output type. The type 
specification
108141character f can be followed by an optional F, D, or L indicating that 
the conversion
108142should be applied to an item of type float, double, or long double, 
respectively.
108143The type specification characters d, o, u, and x can be followed by 
an optional C, S,
108144I, or L indicating that the conversion should be applied to an item 
of type char,
108145short, int, or long, respectively. Multiple types can be concatenated 
within the
108146same type_string and multiple −t options can be specified. Output 
lines shall be
108147written for each type specified in the order in which the type 
specification
108148characters are specified.

ENVIRONMENT VARIABLES:
108183  LC_CTYPE Determine the locale for the interpretation of sequences of 
bytes of text data as
108184   characters (for example, single-byte as opposed to multi-byte 
characters in
108185   arguments and input files).

EXTENDED DESCRIPTION:
108205  The number of bytes transformed by the output type specifier c may be 
variable depending on
108206  the LC_CTYPE category.

108244  The type specifier character c specifies that bytes shall be 
interpreted as characters specified by
108245  the current setting of the LC_CTYPE locale category. Characters listed 
in the table in XBD
108246  Chapter 5 (on page 113) ('\\', '\a', '\b', '\f', '\n', '\r', '\t', 
'\v') shall be written as
108247  the corresponding escape sequences, except that  shall be 
written as a single
108248   and a NUL shall be written as '\0'. Other non-printable 
characters shall be
108249  written as one three-digit octal number for each byte in the character. 
Printable multi-byte
108250  characters shall be written in the area corresponding to the first byte 
of the character; the two-
108251  character sequence "**" shall be written in the area corresponding to 
each remaining byte in the
108252  character, as an indication that the character is continued. When 
either the −j skip or −N count
108253  option is specified along with the c type specifier, and this results 
in an attempt to start or finish
108254  in the middle of a multi-byte character, the result is 
implementation-defined.


Why, then,
  $ od -tc
  ą
  000 304 205  \n
  003
?

It appears that od -tc is treated the same as -c,
even though they're naturally different:
108106  XSI  −c  Interpret bytes as characters specified by the current setting 
of the LC_CTYPE
108107   category. Certain non-graphic characters appear as C escapes: 
"NUL=\0",
108108   "BS=\b", "FF=\f", "NL=\n", "CR=\r", "HT=\t"; others appear as 
3-digit octal
108109   numbers.
(and CHANGE HISTORY, Issue 5 says
 "In the description of the −c option, the phrase ``This is equivalent to −t 
c.’’ is deleted.",
 which disambiguates this clumsy spelling as "-c is btowc(), -tc is normal".)

Best,
наб

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

Kernel: Linux 6.1.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.36-9
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b6

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1037047: cytadela: fails to start under Xwayland: SDL_SetVideoMode(640, 480, 3D): Couldn't find matching GLX visual

[Simon McVittie]

Package: cytadela
Version: 1.1.0-4
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: wayland

cytadela has behaviour very similar to https://bugs.debian.org/1037045
in blobandconquer.

To reproduce:

* GNOME 43 in its default Wayland mode, with Xwayland available
* either of:
* "classic" SDL 1.2 (libsdl1.2debian version 1.2.15+dfsg2-8 tested)
* sdl12-compat (libsdl1.2-compat-shim version 1.2.64 tested)
* run blobAndConquer

Expected result: gameplay

Actual result:

> Welcome to the Citadel!
> 
> 
> Reading the OpenGL vrsion and extensions...
> !SDL_SetVideoMode(640, 480, 3D): Couldn't find matching GLX visual
> 
> Error: Could not initialize OpenGL!
> Exiting...

Workaround (1): log out, and log in to "GNOME on Xorg" instead.

Workaround (2): install libsdl1.2-compat-shim *and* run with
SDL_VIDEODRIVER=wayland,x11 in the environment (which is not the default,
even with SDL 2, because it can cause regressions in other games)

-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-security'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages cytadela depends on:
ii  cytadela-data   1.1.0-4
ii  libc6   2.36-9
ii  libgcc-s1 [libgcc1] 12.2.0-14
ii  libgl1  1.6.0-1
ii  libglu1-mesa [libglu1]  9.0.2-1.1
ii  libsdl-mixer1.2 1.2.12-17+b3
ii  libsdl1.2debian 1.2.64-2~1+1+g544b03a
ii  libstdc++6  12.2.0-14
ii  libvlc5 3.0.18-2
ii  vlc-plugin-base 3.0.18-2

cytadela recommends no packages.

cytadela suggests no packages.

-- no debconf information

Bug#1037006: opensnitch: Upstream change enables ebpf compilation

[Pijgn]

Control: retitle -1 opensnitch: Explicitly use 'proc' fallback by default
Control: severity -1 minor
Control: summary -1 0
Control: tags -1 - upstream + patch

Debian 12 does not ship the eBPF module required for the upstream default
process monitor method. The 'proc' method is used as an implicit fallback,
but python3-opensnitch-ui refuses to set the InterceptUnknown option when
the module is missing and the 'ebpf' monitor method is nominally selected.

My original bug report was based on ignorance of the fallback behavior.
Since eBPF is currently not used at all, patching the build process to add
the missing module would constitute a feature update. That is obviously
out of the question, so here is a minor patch that fixes the actual bug.

Although this bug is not reproducible unless opensnitch-ui is installed
and running, the file that needs to be changed is part of opensnitch.Description: Explicitly use 'proc' fallback by default
 Debian 12 does not ship the eBPF module required for the upstream default
 process monitor method. The 'proc' method is used as an implicit fallback,
 but python3-opensnitch-ui refuses to set the InterceptUnknown option when
 the module is missing and the 'ebpf' monitor method is nominally selected.
Bug-Debian: https://bugs.debian.org/1037006
Forwarded: not-needed
Author: Pijgn 
Index: opensnitch-1.5.8.1/daemon/default-config.json
===
--- opensnitch-1.5.8.1.orig/daemon/default-config.json
+++ opensnitch-1.5.8.1/daemon/default-config.json
@@ -7,7 +7,7 @@
 "DefaultAction": "allow",
 "DefaultDuration": "once",
 "InterceptUnknown": false,
-"ProcMonitorMethod": "ebpf",
+"ProcMonitorMethod": "proc",
 "LogLevel": 2,
 "Firewall": "iptables",
 "Stats": {

Bug#1037046: lrzsz: yet another typo in a manpage

[Uwe Kleine-König]

Package: lrzsz
Version: 0.12.21-10+b1
Severity: minor
Tags: patch
X-Debbugs-Cc: uklei...@debian.org

Hello,

lrz(1) has:

Default ist 32768, [...]

which is probably originating by a German author. In proper English it
has to read:

Default is 32768, [...]

.

The following patch to the debian source fixes that:

diff --git a/debian/patches/mantypos.diff b/debian/patches/mantypos.diff
index 6a6a4b23eaf9..46d09b16f4a2 100644
--- a/debian/patches/mantypos.diff
+++ b/debian/patches/mantypos.diff
@@ -47,3 +47,14 @@
  The environment variable ZNULLS may be used to specify the number of nulls to
  send before a ZDATA frame.
  Values of 101 for a 4.77 mHz PC and 124 for an AT are typical.
+--- lrzsz-0.12.21.orig/man/lrz.1
 lrzsz-0.12.21/man/lrz.1
+@@ -172,7 +172,7 @@
+ .B "-B NUMBER, --bufsize NUMBER"
+ Buffer 
+ .B NUMBER
+-bytes before writing to disk. Default ist 32768, which should be enough
++bytes before writing to disk. Default is 32768, which should be enough
+ for most situations. If you have a slow machine or a bad disk interface
+ or suffer from other hardware problems you might want to increase
+ the buffersize.

Best regards
Uwe

Bug#1037043: (no subject)

[Judit Foglszinger]

severity 1037043 important
thanks

Hi,

seems, it only crashes with libsdl1.2-compat-shim installed,
so not for everyone and the submitter is ok with downgrading it to important
to keep pink ponies in bookworm one week before the release.

Bug#1037045: blobandconquer: fails to start with Xwayland: Couldn't set 800x600 video mode: Couldn't find matching GLX visual

[Simon McVittie]

Package: blobandconquer
Version: 1.11-dfsg+20-2
Severity: important

To reproduce:

* GNOME 43 in its default Wayland mode, with Xwayland available
* either of:
* "classic" SDL 1.2 (libsdl1.2debian version 1.2.15+dfsg2-8 tested)
* sdl12-compat (libsdl1.2-compat-shim version 1.2.64 tested)
* run blobAndConquer

Expected result: gameplay

Actual result:

[DEBUG (0)] Pak : Filename set to 
/usr/share/games/blobAndConquer/blobAndConquer.pak
[DEBUG (0)] initSystem()
[DEBUG (0)] unpack() : /home/smcv/.parallelrealities/blobAndConquer/savedata 
does not exist
[DEBUG (118)] Query stencil support: has stencils: 1
[DEBUG (118)] unpack() : /home/smcv/.parallelrealities/blobAndConquer/config 
does not exist
[DEBUG (118)] User Home = /home/smcv/.parallelrealities/blobAndConquer
[DEBUG (118)] Graphics::setResolution() - 0: 800 x 600
Couldn't set 800x600 video mode: Couldn't find matching GLX visual
[DEBUG (119)] Cleaning Up...
[DEBUG (119)] Deleting Tracer...
[DEBUG (119)] Freeing Audio...
[DEBUG (119)] Removing Temp File...
[DEBUG (119)] Saving Config...
[DEBUG (119)] Removing PAK File Data...
[DEBUG (119)] Closing Audio...
[DEBUG (119)] Freeing Game Data...
[DEBUG (119)] Freeing Remaining Entities...
[DEBUG (119)] Freeing Widgets...
[DEBUG (119)] Freeing Sprites and Fonts
[DEBUG (119)] Freeing Textures...
[DEBUG (119)] Freeing Models...
[DEBUG (119)] Closing TTF...
[DEBUG (119)] Quitting SDL...
[DEBUG (0)] All Done.

Workaround (1): log out, and log in to "GNOME on Xorg" instead.

Workaround (2): install libsdl1.2-compat-shim *and* run with
SDL_VIDEODRIVER=wayland,x11 in the environment (which is not the default,
even with SDL 2, because it can cause regressions in other games)

-- System Information:
Debian Release: 12.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-security'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages blobandconquer depends on:
ii  blobandconquer-data 1.11-dfsg+20-2
ii  libc6   2.36-9
ii  libgcc-s1   12.2.0-14
ii  libgl1  1.6.0-1
ii  libglu1-mesa [libglu1]  9.0.2-1.1
ii  libsdl-image1.2 1.2.12-13+b2
ii  libsdl-mixer1.2 1.2.12-17+b3
ii  libsdl-ttf2.0-0 2.0.11-6
ii  libsdl1.2debian [local build using sdl12-compat 1.2.64]
ii  libstdc++6  12.2.0-14
ii  libx11-62:1.8.4-2
ii  zlib1g  1:1.2.13.dfsg-1

blobandconquer recommends no packages.

Versions of packages blobandconquer suggests:
pn  blobwars  

-- no debconf information

Bug#1037044: Forced password reset leaves behind failed user@.service unit

[Jason Franklin]

Package: systemd
Version: 252.6-1
Severity: normal

Greetings:

It appears that user@.service is left in a failed state when a user logs
in over ssh and is forced to reset their password due to expiration.

I was able to regularly reproduce this behavior with the process
described below.

# Create a test user.
$ sudo adduser fish
...

# Ensure no failed units.
$ systemctl list-units --failed
...

# Expire the user's password.
$ sudo passwd -e fish

# Log in via ssh. Properly change the user's password when prompted.
$ ssh fish@localhost
...
# Here, you will be kicked back out to your prompt after the new
# password is set.

# Now, note that a failed unit for the user is left behind.
$ systemctl list-units --failed
  UNIT   LOAD   ACTIVE SUBDESCRIPTION
* user@1001.service  loaded failed failed User Manager for UID 1001
...

I think the above accurately describes the behavior I'm seeing.

It seems odd to me that the failed service lingers even though the
user's password has been changed correctly, without any real failures in
the process. The user is now able to log in and what not, but systemd
indicates a failure.

This is an issue for me because these failures can stack up on systems
at my work, and monitoring of failed units then indicates a problem
where there is not one.

Please let me know any thoughts on this. It could be another piece of
software that's causing the error. Or, it could be that I have something
improperly configured or that I am misinterpreting things.

Many thanks,

-- 
Jason Franklin

Bug#1037043: pink-pony crashes on start

[Jakub Wilk]

* Jakub Wilk , 2023-06-02 18:49:

ii  libsdl1.2-compat-shim [libsdl1.2debian]  1.2.60-1


Looks like it crashes only if libsdl1.2-compat-shim is installed.

--
Jakub Wilk

Bug#1035575: RM: ams.lv2 -- RoQA; unmaintained; reverse dependency of lvtk; RC-buggy

[Bastian Germann]

Control: severity -1 normal
Control: reassign -1 ftp.debian.org
Control: retitle -1 RM: ams.lv2 -- RoQA; unmaintained; reverse dependency of 
gtk2/lvtk; RC-buggy

Please remove ams.lv2. It has a trivial RC bug. Upstream last touched it in Feb 
2019.
The Debian maintainer (team) does not respond to bugs and the package depends on
several obsolete packages, including gtk2 and the to-be-removed lvtk.

Bug#1037043: pink-pony crashes on start

[Jakub Wilk]

Package: pink-pony
Version: 1.4.1-3.1
Severity: grave

pink-pony crashes on start:

   $ pink-pony
   malloc(): corrupted top size
   Aborted

Or sometimes:

   $ pink-pony
   Segmentation fault

Or:

   $ pink-pony
   Fatal glibc error: malloc assertion failure in _int_malloc: (unsigned long) 
(size) >= (unsigned long) (nb)
   Aborted


-- System Information:
Architecture: i386

Versions of packages pink-pony depends on:
ii  libc62.36-9
ii  libdevil1c2  1.7.8-10+b3
ii  libftgl2 2.4.0-2.1
ii  libgcc-s112.2.0-14
ii  libgl1   1.6.0-1
ii  libglfw3 3.3.8-1
ii  libglu1-mesa [libglu1]   9.0.2-1.1
ii  libimath-3-1-29  3.1.6-1
ii  libprotobuf323.21.12-3
ii  libsdl-mixer1.2  1.2.12-17+b3
ii  libsdl1.2-compat-shim [libsdl1.2debian]  1.2.60-1
ii  libsigc++-2.0-0v52.12.0-1
ii  libstdc++6   12.2.0-14
ii  libtinyxml2.6.2v52.6.2-6
ii  pink-pony-data   1.4.1-3.1

--
Jakub Wilk

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

[James Addison]

On Fri, 2 Jun 2023 at 15:24, James Addison  wrote:
>
> > > Also, arguing against my own revert-patch: I think it could be said
> > > that multi-user is the "better" target to use here, because the
> > > default could be "graphical" or some later-reached system state
> > > whereas this is a relatively low-level (if small) system cleanup
> > > service.
> >
> > Right, that's I believe the point of bug #991349; it's possible that
> > the system adminsitrator might manually set default.target to point to
> > graphical.target, per [1].  And since multi-user.target is a subset of
> > graphical.target, it makes sense to make the Wanted-by to be
> > multi-user.target.
> >
> > [1] https://www.baeldung.com/linux/systemd-target-multi-user
>
> I guess so.  However, now that I read it, the manual for
> systemd.special[1] does indicate that the target it will load at boot
> is default.target -- whatever it's configured to (usually multi-user
> or graphical).
>
> In other words: default.target should be a subset of all of
> multi-user.target, graphical.target, and whatever else a system
> administrator might configure as the boot target state.

Eh, poor phrasing there: default.target isn't a _subset_ of all those
targets, but for any given systemd-enabled boot environment,
default.target should be guaranteed (as far as systemd lives up to the
guarantees it aims to provide) to be on the service startup path
between systemd loading as init and systemd reaching the desired boot
state.

> > In this particular case, since we *always* want it to be
> > default.target, since the whole *point* is to clean up after a failed
> > e2scrub, it seems really unlikely to me that the system administrator
> > would change this.  So this is one where it's probably fair for the
> > postinstall script to just fix the wanted-by link **always** if the
> > the systemd unit file says Wanted-by: default.target, and the symlink
> > is inconsistent with it.
>
> What do you mean by "fix the link" in this context?
>
> [1] - https://manpages.debian.org/bullseye/systemd/systemd.special.7.en.html

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

[James Addison]

> > Also, arguing against my own revert-patch: I think it could be said
> > that multi-user is the "better" target to use here, because the
> > default could be "graphical" or some later-reached system state
> > whereas this is a relatively low-level (if small) system cleanup
> > service.
>
> Right, that's I believe the point of bug #991349; it's possible that
> the system adminsitrator might manually set default.target to point to
> graphical.target, per [1].  And since multi-user.target is a subset of
> graphical.target, it makes sense to make the Wanted-by to be
> multi-user.target.
>
> [1] https://www.baeldung.com/linux/systemd-target-multi-user

I guess so.  However, now that I read it, the manual for
systemd.special[1] does indicate that the target it will load at boot
is default.target -- whatever it's configured to (usually multi-user
or graphical).

In other words: default.target should be a subset of all of
multi-user.target, graphical.target, and whatever else a system
administrator might configure as the boot target state.

> In this particular case, since we *always* want it to be
> default.target, since the whole *point* is to clean up after a failed
> e2scrub, it seems really unlikely to me that the system administrator
> would change this.  So this is one where it's probably fair for the
> postinstall script to just fix the wanted-by link **always** if the
> the systemd unit file says Wanted-by: default.target, and the symlink
> is inconsistent with it.

What do you mean by "fix the link" in this context?

[1] - https://manpages.debian.org/bullseye/systemd/systemd.special.7.en.html

Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Beauregard,Christophe (ECCC)]

Package: graphicsmagick
Version: 1.4+really1.3.36+hg16481-2+deb11u1
Severity: normal
Tags: upstream

The GraphicsMagick API has a thread arena and more general memory leak
somewhere in the GetImageDepth() API call, presumably a side-effect of
the OpenMP usage.

First, you need a server class system... a lot of beefy cores (i.e. I
can't reproduce it on my quad-core laptop), and possibly a lot of RAM
(128G on this one):

root@host:~# grep 'model name' /proc/cpuinfo |tail -1
model name  : Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz
root@host:~# grep processor /proc/cpuinfo |tail -1
processor   : 39

Then you need this test program:

root@host:~# cat threadarena.c
/*
 * gcc -o threadarena threadarena.c \
 *    `GraphicsMagick-config --cppflags --ldflags --libs`
 */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

static void* readimage(void* arg) {
  ImageInfo *imageInfo;
  ExceptionInfo exception;
  const char* filename = (const char*) arg;
  ImageCharacteristics chars;

  imageInfo=CloneImageInfo(0);
  GetExceptionInfo();

  (void) strncpy(imageInfo->filename, arg, MaxTextExtent-1 );

  Image *image = ReadImage(imageInfo, );
  if (image == (Image *) NULL)
  {
CatchException();
perror("ReadImage");
  }

  GetImageDepth(image,>exception);

  DestroyImage(image);
  DestroyImageInfo(imageInfo);
  DestroyExceptionInfo(  );
  return NULL;
}

int main ( int argc, char **argv )
{
  const char* file = argv[1];
  if( file == NULL ) {
fprintf(stderr,"usage: %s \n", argv[0]);
return 1;
  }

  InitializeMagick(NULL);

  while(1) {
pid_t myp = getpid();
char s[PATH_MAX];
#if 1
/* this code path has a thread arena leak */
pthread_t thread_id;
pthread_create(_id, NULL, readimage, argv[1]);

/* pthread_detach(thread_id); also shows the problem */
pthread_join(thread_id, NULL);
#else
/* this code path doesn't have a thread arena leak */
readimage(argv[1]);
#endif

sleep(1);

fprintf(stderr,"%lld\n", (long long)time(0));
snprintf(s,sizeof(s),
  "ps -o vsz -o rss -o user -o command -p %lld", (long 
long)myp);
system(s);
snprintf(s,sizeof(s),
  "pmap -x %lld | grep 65404 | wc -l", (long long)myp);
system(s);
  }

  DestroyMagick();

  return 0;
}

Compile and run the test program:

root@host:~# gcc -o threadarena threadarena.c `GraphicsMagick-config --cppflags 
--ldflags --libs`

root@host:~# ./threadarena  Zoom140.png
1685713732
   VSZ   RSS USER COMMAND
2443096 8248 root ./threadarena Zoom140.png
35
1685713734
   VSZ   RSS USER COMMAND
4802392 9816 root ./threadarena Zoom140.png
70
1685713735
   VSZ   RSS USER COMMAND
7161688 11352 root./threadarena Zoom140.png
105
1685713736
   VSZ   RSS USER COMMAND
9520984 12920 root./threadarena Zoom140.png
140
1685713737
   VSZ   RSS USER COMMAND
11880280 14456 root   ./threadarena Zoom140.png
175
1685713738
   VSZ   RSS USER COMMAND
14239576 16040 root   ./threadarena Zoom140.png
210
1685713739
   VSZ   RSS USER COMMAND
16598872 17608 root   ./threadarena Zoom140.png
245
1685713740
   VSZ   RSS USER COMMAND
18958168 19128 root   ./threadarena Zoom140.png
280
1685713741
   VSZ   RSS USER COMMAND
20989784 20660 root   ./threadarena Zoom140.png
310
1685713742
   VSZ   RSS USER COMMAND
20989784 22100 root   ./threadarena Zoom140.png
309
1685713743
   VSZ   RSS USER COMMAND
20989784 23492 root   ./threadarena Zoom140.png
308
1685713744
   VSZ   RSS USER COMMAND
20989784 24900 root   ./threadarena Zoom140.png
307
1685713745
   VSZ   RSS USER COMMAND
20989784 26292 root   ./threadarena Zoom140.png
306

As you can see, the number of thread arenas (65404 k mapped sections)
according to pmap grows dramatically with each invocation of
GetImageDepth(), and the virtual memory usage blows up to ~20G before
stabilizing. RSS also increases, albeit less dramatically, but eventually
the system does start to hit an OOM condition.

My understanding of malloc thread arenas is that new threads are supposed
to reuse the arenas, and only attempt to create new ones when an existing
arena is locked, so I assume that's what's happening here. And I also assume
there's some missing housekeeping that's also leaking RSS memory.

Some fun facts about the bug:

1. so far, only GetImageDepth() triggers the error. Reading pixel data and
other transformations seems fine.

2. it only happens when the API is called from within a thread (hence the
pthread_start()). If you call it from the main process, no problem.

3. the problem can be mitigated by mallopt(M_ARENA_MAX, n); for some fixed
n (currently running with 8), although I haven't really quantified what that 

Bug#1036968: linux: Enable CONFIG_SND_SOC_CS35L41_I2C for Intel Alder Lake sound

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Wed, May 31, 2023 at 09:40:54AM +0200, Hans-Christoph Steiner wrote:
> 
> Package: src:linux
> Version: 6.3.2-1~exp1
> Severity: important
> 
> Dear Maintainer,
> 
> I installed Debian on a Dell XPS 17 9720:
> https://wiki.debian.org/InstallingDebianOn/Dell/XPS%2017%209720
> 
> The audio output works, but there are a number of problems:
> 
> * Headphone plug detection does not work at all.
> * No audio input is detected.
> * The audio crashes after a couple of days.
> 
> This bug goes through some of the development efforts to fix this:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194
> 
> One thing they said there is that all CS35L41 modules need to be
> enabled.  This is the recommended set:
> 
> CONFIG_SND_HDA_SCODEC_CS35L41=m
> CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m
> CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m
> CONFIG_SND_SOC_CS35L41_LIB=m
> CONFIG_SND_SOC_CS35L41=m
> CONFIG_SND_SOC_CS35L41_SPI=m
> CONFIG_SND_SOC_CS35L41_I2C=m
> 
> There is one module still not enabled in the Debian kernels (6.1.0-8,
> 6.3.2-1~exp1, and 6.3.4-1~exp1):
> 
> $ grep CS35L41 /boot/config-6.3.0-0-amd64
> CONFIG_SND_HDA_SCODEC_CS35L41=m
> CONFIG_SND_HDA_SCODEC_CS35L41_I2C=m
> CONFIG_SND_HDA_SCODEC_CS35L41_SPI=m
> CONFIG_SND_SOC_CS35L41_LIB=m
> CONFIG_SND_SOC_CS35L41=m
> CONFIG_SND_SOC_CS35L41_SPI=m
> # CONFIG_SND_SOC_CS35L41_I2C is not set
> 
> Could this module be enabled?

Can you confirm that the issue is resolved if you enable the
configuration and enable this as module?

Regards,
Salvatore

Bug#1037041: linux-image-6.1.0-9-amd64: Spurious failures from mmap(MAP_32BIT)

[Salvatore Bonaccorso]

Control: forcemerge 1036755 -1 

Hi Alfred,

On Fri, Jun 02, 2023 at 03:51:53PM +0200, Alfred Agrell wrote:
> Package: src:linux
> Version: 6.1.27-1
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: blub...@gmail.com
> 
> Dear Maintainer,
> 
> Please run this program 20 times:
> 
> 
> #include 
> #include 
> #include 
> 
> int main()
> {
> for (int i=0;i<1000;i++)
> {
> void* p = mmap(NULL, 65536, PROT_READ|PROT_WRITE, 
> MAP_PRIVATE|MAP_ANONYMOUS|MAP_32BIT, -1, 0);
> if (p != MAP_FAILED) printf(".");
> else if (errno == ENOMEM) printf("E");
> else printf("(%d)", errno);
> }
> puts("");
> }
> 
> 
> Expected behavior:
> 
> It should print 1000 dots. If 1000 is increased to 10, it should print 
> some dots, then some Es. It should never print a dot after an E; if it's out 
> of address space, it shouldn't suddenly find new address space if the 
> operation is retried.
> 
> 
> Actual behavior:
> 
> Kernel version 6.1.0-7-amd64:
> 
> On 13 of 20 runs, it prints 1000 dots. On some, it prints one to three 
> randomly scattered Es (never an E before at least 155 dots), and the rest is 
> dots.
> 
> Kernel version 6.1.0-9-amd64:
> 
> On 8 of 20 runs, it prints 1000 dots. On some, it prints one to four randomly 
> scattered Es, first one after only 16 dots.
> 
> On some runs, there are long sequences of Es with a few dots interspersed; 
> worst case, only 383 of 1000 mmap()s succeed.
> 
> 
> Additional information:
> 
> Running this on a few other computers, and asking some friends to run it, 
> returns
> 
> - Ubuntu 22.04 (kernel 5.19.0-43-generic): 1000 dots, every time.
> - Debian 11 (kernel 5.10.0-21-amd64): 1000 dots, every time.
> - Arch (kernel 6.3.3-arch1-1): Same pattern as 6.1.0-9-amd64.
> - Arch (kernel 6.3.4-arch1-1): 1000 dots, every time.
> - Fedora 38 (kernel 6.2.15-300.fc38.x86_64): Same pattern as 6.1.0-9-amd64.
> 
> so I suspect it depends, at least partially, on kernel configuration.
> 
> 
> The more practical impact (and the context where I first encountered this 
> bug) is that the game Creeper World 3 frequently (~85% of the time) segfaults 
> at launch (after 437th line of strace output) under kernel 6.1.0-9-amd64, 
> while it reliably launches under 6.1.0-7-amd64.
> 
> (Unfortunately, the game is closed source and commercial, so I'm not sure if 
> you want a link in your bug tracker. The binary is freely available on the 
> developer's website; it asks for a license key, but the crashing part is far 
> before that.)
> 
> I'm happy to provide strace logs, kernel config, and whatever else; just tell 
> me what you need.

I believe this is the same as #1036755 and will be fixed in the first
bookworm point release.

I will already merge as I'm relatively sure this is the same, but in
case you can confirm it is a different issue, please unmerge the bugs
again.

Regards,
Salvatore

Bug#1037041: linux-image-6.1.0-9-amd64: Spurious failures from mmap(MAP_32BIT)

[Alfred Agrell]

Package: src:linux
Version: 6.1.27-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: blub...@gmail.com

Dear Maintainer,

Please run this program 20 times:


#include 
#include 
#include 

int main()
{
for (int i=0;i<1000;i++)
{
void* p = mmap(NULL, 65536, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_ANONYMOUS|MAP_32BIT, -1, 0);
if (p != MAP_FAILED) printf(".");
else if (errno == ENOMEM) printf("E");
else printf("(%d)", errno);
}
puts("");
}


Expected behavior:

It should print 1000 dots. If 1000 is increased to 10, it should print some 
dots, then some Es. It should never print a dot after an E; if it's out of 
address space, it shouldn't suddenly find new address space if the operation is 
retried.


Actual behavior:

Kernel version 6.1.0-7-amd64:

On 13 of 20 runs, it prints 1000 dots. On some, it prints one to three randomly 
scattered Es (never an E before at least 155 dots), and the rest is dots.

Kernel version 6.1.0-9-amd64:

On 8 of 20 runs, it prints 1000 dots. On some, it prints one to four randomly 
scattered Es, first one after only 16 dots.

On some runs, there are long sequences of Es with a few dots interspersed; 
worst case, only 383 of 1000 mmap()s succeed.


Additional information:

Running this on a few other computers, and asking some friends to run it, 
returns

- Ubuntu 22.04 (kernel 5.19.0-43-generic): 1000 dots, every time.
- Debian 11 (kernel 5.10.0-21-amd64): 1000 dots, every time.
- Arch (kernel 6.3.3-arch1-1): Same pattern as 6.1.0-9-amd64.
- Arch (kernel 6.3.4-arch1-1): 1000 dots, every time.
- Fedora 38 (kernel 6.2.15-300.fc38.x86_64): Same pattern as 6.1.0-9-amd64.

so I suspect it depends, at least partially, on kernel configuration.


The more practical impact (and the context where I first encountered this bug) 
is that the game Creeper World 3 frequently (~85% of the time) segfaults at 
launch (after 437th line of strace output) under kernel 6.1.0-9-amd64, while it 
reliably launches under 6.1.0-7-amd64.

(Unfortunately, the game is closed source and commercial, so I'm not sure if 
you want a link in your bug tracker. The binary is freely available on the 
developer's website; it asks for a license key, but the crashing part is far 
before that.)

I'm happy to provide strace logs, kernel config, and whatever else; just tell 
me what you need.


-- Package-specific info:
** Version:
Linux version 6.1.0-9-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64 
root=UUID=3f03a19e-1f7e-43c8-a4e9-6297f87ce127 ro quiet

** Not tainted

** Kernel log:
[2.147324] input: HDA Intel PCH Front Headphone as 
/devices/pci:00/:00:1f.3/sound/card0/input14
[2.147886] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/sound/card0/input15
[2.148024] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1f.3/sound/card0/input16
[2.148081] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1f.3/sound/card0/input17
[2.148161] input: HDA Intel PCH HDMI/DP,pcm=9 as 
/devices/pci:00/:00:1f.3/sound/card0/input18
[2.160594] Bluetooth: Core ver 2.22
[2.160606] NET: Registered PF_BLUETOOTH protocol family
[2.160606] Bluetooth: HCI device and connection manager initialized
[2.160609] Bluetooth: HCI socket layer initialized
[2.160610] Bluetooth: L2CAP socket layer initialized
[2.160614] Bluetooth: SCO socket layer initialized
[2.168164] usbcore: registered new interface driver btusb
[2.168428] Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection 
command is advertised, but not supported.
[2.258383] pcieport :00:1c.5: AER: Multiple Corrected error received: 
:00:1c.5
[2.258411] pcieport :00:1c.5: PCIe Bus Error: severity=Corrected, 
type=Physical Layer, (Receiver ID)
[2.258413] pcieport :00:1c.5:   device [8086:43bd] error 
status/mask=0001/2000
[2.258416] pcieport :00:1c.5:[ 0] RxErr  (First)
[2.258423] pcieport :00:1c.5: AER: Multiple Corrected error received: 
:00:1c.5
[2.258436] pcieport :00:1c.5: AER: can't find device of ID00e5
[2.291946] pcieport :00:1c.5: AER: Multiple Corrected error received: 
:00:1c.5
[2.291977] pcieport :00:1c.5: PCIe Bus Error: severity=Corrected, 
type=Physical Layer, (Receiver ID)
[2.291980] pcieport :00:1c.5:   device [8086:43bd] error 
status/mask=0081/2000
[2.291985] pcieport :00:1c.5:[ 0] RxErr  (First)
[2.291989] pcieport :00:1c.5:[ 7] BadDLLP   
[2.394348] ath10k_pci :03:00.0: firmware: failed to load 
ath10k/pre-cal-pci-:03:00.0.bin (-2)
[2.394397] firmware_class: See https://wiki.debian.org/Firmware 

Bug#1037023: blueman: missing dependency (Failed to load module "xapp-gtk3-module")

[Christopher Schramm]

I can easily reproduce the message e.g. by setting 
GTK3_MODULE=xapp-gtk3-module while not having libxapp-gtk3-module 
installed. The package's configuration file 
/etc/X11/Xsession.d/80xapp-gtk3-module also sets that for the Xsession.


However... i) I can influence the message independent of 
gir1.2-xapp-1.0. If it's referenced in $GTK3_MODULE and 
libxapp-gtk3-module is installed, the message does not show up even if 
gir1.2-xapp-1.0 is not installed. ii) It's harmless. blueman-manager 
does not terminate in any way.


Actually, what return code do you get? In case of a crash, could you get 
a backtrace? Otherwise, try blueman-manager --loglevel debug to find why 
it exits.

Bug#1036971: pwsafe: empty window after internal timeout or screen blank

[Bill Blough]

Ah, I see.  Thanks for the clarification.

Yes, that sounds like a bug to me.

I'll test with the upstream version and see if the problem exists there
(I assume it will - I don't think any of our packaging would cause
this), and then forward upstream.

Thanks for your report!

Bug#1037040: util-linux: Please coordinate upload of 2.39 with manpages-l10n

[Helge Kreutzmann]

Package: util-linux
Version: 2.38.1-5+b1
Severity: wishlist
Tags: l10n

Hello util-linux maintainer,
once bookworm is released, I assume that you intend to package the latest
version, i.e. 2.39.

This version comes with translated man pages, which were (up to
now) shipped by manpages-l10n.

To allow a smooth transition, both packages need to declare
appropriate package relations:
https://wiki.debian.org/PackageTransition

So please let me know about the upload and the relevant version
(probably 2.39.0-1?).

Until I hear something from your side, manpages-l10n will continue
shipping the translated man pages.


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

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

Versions of packages util-linux depends on:
ii  libblkid1 2.38.1-5+b1
ii  libc6 2.36-9
ii  libcap-ng00.8.3-1+b3
ii  libcrypt1 1:4.4.33-2
ii  libmount1 2.38.1-5+b1
ii  libpam0g  1.5.2-6
ii  libselinux1   3.4-1+b5
ii  libsmartcols1 2.38.1-5+b1
ii  libsystemd0   252.6-1
ii  libtinfo6 6.4-4
ii  libudev1  252.6-1
ii  libuuid1  2.38.1-5+b1
ii  util-linux-extra  2.38.1-5+b1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages util-linux recommends:
ii  sensible-utils  0.0.17+nmu1

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
ii  kbd 2.5.1-1+b1
pn  util-linux-locales  

-- no debconf information

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


signature.asc
Description: PGP signature

Bug#1035542: libreswan: CVE-2023-30570: Incorrect aggressive mode interaction causes the pluto daemon to crash

[Daniel Kahn Gillmor]

Control: found 1035542 4.3-1+deb11u3
Control: tags 1035542 + patch

Thanks for the documentation of CVE-2023-30570 on
https://bugs.debian.org/1035542, Salvatore.

fwiw, i don't think this is particularly serious -- the vulnerability
only appears to be dangerous if the libreswan endpoint is configured to
allow IKEv1 in aggressive mode.

Since 4.5-2, libreswan's ikev1-policy has defaulted to "drop", and we've
heard no complaints from users that this has been an impediment, so i
have my doubts about how many people have such a configuration.

That said, in bullseye, it is still a plausible choice.

I'm attaching the patch here for bullseye (against v4.3), which i can
upload to bullseye-security whenever you you think is appropriate.

For v4.10 (which is in bookworm, about to be stable) i think the best
move is to just ship v4.11 directly.  I'm also attaching here the diff
between upstream's v4.10 and v4.11 -- it is a narrowly-targeted bugfix
release.  i think it makes more sense to just ship v4.11 as a security
update to bookworm (since i missed the freeze cutoff, apologies) rather
than to try to ship v4.10 plus basically the same patch.

Here's the patch against v4.3 that i intend to send to
bullseye-security:

From: Daniel Kahn Gillmor 
Date: Thu, 1 Jun 2023 16:12:50 -0400
Subject: Resolve CVE-2023-30570

see https://libreswan.org/security/CVE-2023-30570/CVE-2023-30570.txt

This patch was ported from
https://libreswan.org/security/CVE-2023-30570/CVE-2023-30570-libreswan-4.x.patch
---
 programs/pluto/ikev1.c  | 60 ++---
 programs/pluto/ikev1_aggr.c |  5 ++--
 2 files changed, 60 insertions(+), 5 deletions(-)

diff --git a/programs/pluto/ikev1.c b/programs/pluto/ikev1.c
index 2a06c2c..bb6c7be 100644
--- a/programs/pluto/ikev1.c
+++ b/programs/pluto/ikev1.c
@@ -1249,10 +1249,20 @@ void process_v1_packet(struct msg_digest *md)
 	struct state *st = NULL;
 	enum state_kind from_state = STATE_UNDEFINED;   /* state we started in */
 
+	/*
+	 * For the initial responses, don't leak the responder's SPI.
+	 * Hence the use of send_v1_notification_from_md().
+	 *
+	 * AGGR mode is a mess in that the R0->R1 transition happens
+	 * well before the transition succeeds.
+	 */
 #define SEND_NOTIFICATION(t)		\
 	{\
 		pstats(ikev1_sent_notifies_e, t);			\
-		if (st != NULL)		\
+		if (st != NULL &&	\
+		st->st_state->kind != STATE_AGGR_R0 &&		\
+		st->st_state->kind != STATE_AGGR_R1 &&		\
+		st->st_state->kind != STATE_MAIN_R0)		\
 			send_notification_from_state(st, from_state, t); \
 		else			\
 			send_notification_from_md(md, t);		\
@@ -1322,17 +1332,26 @@ void process_v1_packet(struct msg_digest *md)
 			from_state = (md->hdr.isa_xchg == ISAKMP_XCHG_IDPROT ?
   STATE_MAIN_R0 : STATE_AGGR_R0);
 		} else {
-			/* not an initial message */
+			/*
+			 * Possibly not an initial message.  Possibly
+			 * from initiator.  Possibly from responder.
+			 *
+			 * Possibly.  Which is probably hopeless.
+			 */
 
 			st = find_state_ikev1(>hdr.isa_ike_spis,
 	  md->hdr.isa_msgid);
 
 			if (st == NULL) {
 /*
- * perhaps this is a first message
+ * Perhaps this is a first message
  * from the responder and contains a
  * responder cookie that we've not yet
  * seen.
+ *
+ * Perhaps this is a random message
+ * with a bogus non-zero responder IKE
+ * SPI.
  */
 st = find_state_ikev1_init(>hdr.isa_ike_initiator_spi,
 			   md->hdr.isa_msgid);
@@ -1343,6 +1362,21 @@ void process_v1_packet(struct msg_digest *md)
 	/* XXX Could send notification back */
 	return;
 }
+if (st->st_state->kind == STATE_AGGR_R0) {
+	/*
+	 * The only way for this to
+	 * happen is for the attacker
+	 * to guess the responder's
+	 * IKE SPI that hasn't been
+	 * sent over the wire?
+	 *
+	 * Well that or played 1/2^32
+	 * odds.
+	 */
+	log_pexpect(HERE,
+		 "phase 1 message matching AGGR_R0 state");
+	return;
+}
 			}
 			from_state = st->st_state->kind;
 		}
@@ -3027,6 +3061,26 @@ void complete_v1_state_transition(struct state *st, struct msg_digest *md, stf_s
 			delete_state(st);
 			/* wipe out dangling pointer to st */
 			md->st = NULL;
+		} else if  (st->st_state->kind == STATE_AGGR_R0 ||
+			st->st_state->kind == STATE_AGGR_R1 ||
+			st->st_state->kind == STATE_MAIN_R0) {
+			/*
+			 *
+			 * Wipe out the incomplete larval state.
+			 *
+			 * ARGH! In <=v4.10, the aggr code flipped the
+			 * larval state to R1 right at the start of
+			 * the transition and not the end, so using
+			 * state to figure things out is close to
+			 * useless.
+			 *
+			 * Deleting the state means that pluto has no
+			 * way to detect and ignore amplification
+			 * attacks.
+			 */
+			delete_state(st);
+			/* wipe out dangling pointer to st */
+			md->st = NULL;
 		}
 		break;
 	}
diff --git a/programs/pluto/ikev1_aggr.c 

Bug#1037004: msmtp-mta doesn't respect DEBIAN_FRONTEND=noninteractive

[Emmanuel Bouthenot]

On Thu, Jun 01, 2023 at 09:06:52AM -0700, Tao Effect wrote:
> Wow, that worked! Sorry for not understanding that that had to be prepended 
> to both commands.
> 
> Lesson learned! Thank you and please feel free to close this bug report now 
> (I have no idea how to do that).

Perfect, hence I'm closing this bugs.

Regards,

-- 
Emmanuel Bouthenot
  kolter@{openics,debian}.org   kolter@{libera,oftc}
  0x929D42C3/4096R

Bug#1037023: blueman: missing dependency (Failed to load module "xapp-gtk3-module")

[Marc Lehmann]

On Fri, Jun 02, 2023 at 09:30:13AM +0200, Christopher Schramm 
 wrote:
> blueman-manager works fine for me without that package and blueman does not
> have anything to do with xapp.

Interesting - probably some action at a distance thing then. Weird that
only blueman did output this message, though.

> Could it be that you're referring to the module in
> ~/.config/gtk-3.0/settings.ini or similar? Do other GTK 3 apps work fine?

Can't see anything (see below), and other gtk-3 programs (such as
xfce4-panel) did not complain when started similarly (i.e. same terminal
instance).

Here are the contents of ~/.config/gtk-3.0/settings.ini

   [Settings]
   gtk-cursor-theme-name=breeze_cursors
   gtk-font-name=Noto Sans 10
   gtk-theme-name=Breeze
   gtk-icon-theme-name=breeze
   gtk-fallback-icon-theme=gnome
   gtk-toolbar-style=GTK_TOOLBAR_ICONS
   gtk-menu-images=1
   gtk-button-images=1
   gtk-primary-button-warps-slider=0
   gtk-application-prefer-dark-theme=0

Bug#932957: Please migrate Release Notes to reStructuredText

[Holger Wansing]

Some status update:

I managed to expand the Makefile, to build r-n for different archs for all 
languages and for formats text+pdf+nopdf+html:

https://salsa.debian.org/holgerw/release-notes/-/commits/master?ref_type=heads


Open points: 

- In this version, it builds for amd64+armel+i386+ppc64el only. No problem,
  to expand this for more archs though.
- For now, I have separate conf.py files for the different archs, which I copy 
  in place before starting the builds; needs to be replaced by some sed 
mechanism.
- The list of archs is hardcoded in the Makefile for now.
- The target 'make install' is not ready; you can only build with 
  'make text|make pdf|make nopdf|make html|make all' and get the results in 
  the build dir.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1037039: rsyslog - SysV init file missing

[Narayanan R S]

Package: rsyslog
Version: 8.2302.0-1~bpo11+1

Can you please reinstate the missing /etc/init.d/rsyslog file in the
package?

>From the changelog notes, it appears to have been removed (intentionally)
in version 8.2110.0-2.

I'm not clear on why this is removed - one can continue to use a SysV init
and so this file is useful/important in systems that do not use systemd to
launch rsyslog. While I understand that ryslog's priority has been demoted
from important to optional (per
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018788), I see no reason
to exclude the SysV init file from the package

Thank you.

Narayanan.

Bug#651280: don't allocate all available disk space in standard LVM partioning scheme

[Pascal Hambourg]

On 31/05/2023 at 19:50, James Addison wrote:

On Wed, 31 May 2023 at 16:38, Cyril Brulebois  wrote:

James Addison  (2023-05-31):


The disk space required for e2scrub[1] snapshots is 256MiB and the
default allocation for LVM (encrypted or unecrypted) in the bookworm
RC4 installer is 100% (same as originally reported here in Y2011).


That's the default setting. Users who want to use e2scrub can tweak it.


The volume group allocation size can be adjusted during an interactive
install session, yep - the operator is prompted to input a size, and
the default value is the full extent of the block device (my
terminology may be a bit wonky).


Bug#651280 submitter's intent was to reserve enough free space in the VG 
for future LV creation or growth. This has been addressed in Buster 
installer so I thought this very old bug should be closed.


IMO reserving free space for e2scrub is a separate topic. Periodic 
execution of e2scrub is disabled by default in /etc/e2scrub.conf, so it 
is not unreasonable to consider that users willing to enable it should 
be aware of its requirements. However if you consider that guided 
partitioning should reserve a small amount of free space for e2scrub you 
may file a new bug report against partman-auto-lvm.



(the 256MiB requirement appears to static, though - it's a fixed size
for exactly one snapshot, I suppose)


The snapshot size is defined in /etc/e2scrub.conf. The actual required 
size must be enough to hold changes to the original LV during the check.

Bug#1037038: ITP: ruby-google-apis-androidpublisher-v3 -- Simple REST client for Google Play Android Developer API V3

[Vinay]

package: wnpp
Severity: wishlist
Owner: Vinay Keshava

*Package Name  : ruby-google-apis-androidpublisher-v3
 Version   : 0.34.0
 Upstream Author   : 2021 Google LLC
*URL   :https://github.com/google/google-api-ruby-client
*License   : Apache-2.0
 Programming Lang  : Ruby
*Description: Simple REST client for Google Play Android Developer API V3
 This is the simple REST client for Google Play Android Developer API V3.
 Simple REST clients are Ruby client libraries that provide access to Google
 services via their HTTP REST API endpoints. These libraries are generated and
 updated automatically based on the discovery documents published by the
 service, and they handle most concerns such as authentication, pagination,
 retry, timeouts, and logging. You can use this client to access the Google
 Play Android Developer API, but note that some services may provide a separate
 modern client that is easier to use.


This gem is required for gitlab.

- Vinay Keshava




OpenPGP_0xD3FDE3D93A1FCF50.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037037: RFP: eu-dss -- EU Digital Signature Service implementation

[Andrej Shadura]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Debian Java Maintainers 
, team+ei...@tracker.debian.org

* Package name: eu-dss (?)
  Version : 5.12
  Upstream Contact: David Naramski, Pierrick Vandenbroucke, Aleksandr Beliakov 
et al
* URL : https://github.com/esig/dss

https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/Digital+Signature+Service+-++DSS
* License : LGPL-2.1
  Programming Lang: Java
  Description : EU Digital Signature Service implementation

DSS (Digital Signature Services) is an open-source software library for 
electronic signature creation
and validation in line with European legislation.

In particular, DSS aims to follow the eIDAS Regulation and related standards 
closely.

DSS can be re-used in an IT solution for electronic signatures to ensure
that signatures are created and verified in line with European legislation
and standards. DSS allows re-use in a variety of different ways: in an
applet, in a stand-alone application or in a server application. DSS
can also be used as a reference implementation for IT solutions which
do not directly re-use it. Demos are also available to assist the use of
DSS as a reference implementation. DSS was developed by Nowina Solutions
and is maintained up-to-date via new releases.

This package is a dependency of the Autogram eIDAS signing tool.

Bug#1037036: ITP: autogram -- eIDAS-compliant document signing tool

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 
X-Debbugs-Cc: debian-de...@lists.debian.org, team+ei...@tracker.debian.org

* Package name: autogram
  Version : 1.99.10
  Upstream Contact: Jakub Ďuraš, Slovensko.Digital et al.
* URL : https://github.com/slovensko-digital/autogram
* License : EUPL 1.2
  Programming Lang: Java
  Description : eIDAS-compliant document signing tool

Autogram is a cross-platform (Windows, MacOS, Linux) desktop JavaFX
application to sign documents accordancing to the eIDAS standard.
The user can use it to sign files directly, or the application can be
easily integrated into your own (web) information system using the
HTTP API.

Bug#1037035: FTBFS due to tests relying on running redis server

[Shengjing Zhu]

Source: beaker
Version: 1.12.1-1
Severity: serious
Tags: ftbfs patch
X-Debbugs-Cc: z...@debian.org


The tests need a running redis server. I suggests ignore it just
like the mongodb one.

Please see the patch.
diff -Nru beaker-1.12.1/debian/changelog beaker-1.12.1/debian/changelog
--- beaker-1.12.1/debian/changelog  2023-02-10 02:37:53.0 +0800
+++ beaker-1.12.1/debian/changelog  2023-06-02 19:23:50.0 +0800
@@ -1,3 +1,9 @@
+beaker (1.12.1-1.1) unstable; urgency=medium
+
+  * Exclude tests relying on running redis server.
+
+ -- Shengjing Zhu   Fri, 02 Jun 2023 19:23:50 
+0800
+
 beaker (1.12.1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru beaker-1.12.1/debian/rules beaker-1.12.1/debian/rules
--- beaker-1.12.1/debian/rules  2023-02-10 02:37:53.0 +0800
+++ beaker-1.12.1/debian/rules  2023-06-02 19:23:37.0 +0800
@@ -1,6 +1,6 @@
 #! /usr/bin/make -f
 
 export PYBUILD_NAME=beaker
-export PYBUILD_TEST_ARGS=--ignore=tests/test_memcached.py 
--ignore=tests/test_managers/test_ext_mongodb.py -k 'not 
test_cookie_expires_different_locale'
+export PYBUILD_TEST_ARGS=--ignore=tests/test_memcached.py 
--ignore-glob=tests/test_managers/test_ext_*.py -k 'not 
test_cookie_expires_different_locale'
 %:
dh $@ --with python3 --buildsystem=pybuild

Bug#1037034: coreutils: manifest still uses "/bin" although files are in "/usr/bin"

[Matthias Scheler]

Package: coreutils
Version: 9.1-1
Severity: minor

On Debian 12 "/bin" has been changed to a symbolic link that points
to "/usr/bin":

> ls -l /bin
lrwxrwxrwx 1 root root 7 May 14 08:39 /bin -> usr/bin

However the package manifest of "coreutils" still claims that files are
located in "/bin". This is confusing when the user tries to determine
which package owns a file:

> which ls
/usr/bin/ls
> dpkg -S /usr/bin/ls
dpkg-query: no path found matching pattern /usr/bin/ls
> dpkg -S /bin/ls
coreutils: /bin/ls

This oddity is not even consistent for the "coreutils" package:

> which seq   
/usr/bin/seq
> dpkg -S /usr/bin/seq
coreutils: /usr/bin/seq
> dpkg -S /bin/seq
dpkg-query: no path found matching pattern /bin/seq

I suspect that many more packages are affected.

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

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

Versions of packages coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.36-9
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b5

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#1037033: clang-7-dbgsym: missing /usr/share/doc/clang-7-dbgsym -> clang-7

[Andreas Beckmann]

Package: clang-7-dbgsym
Version: 1:7.0.1-8~deb9u3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: found -1 7.0.1-8~deb9u2
Control: fixed -1 7.0.1-8+deb10u1
Control: close -1 7.0.1-9

Hi,

during a test with piuparts I noticed your package misses the
/usr/share/doc/clang-7-dbgsym -> clang-7 symlink.

>From the attached log (scroll to the bottom...):

  MISSING COPYRIGHT FILE: /usr/share/doc/clang-7-dbgsym/copyright
  # ls -lad /usr/share/doc/clang-7-dbgsym
  ls: cannot access '/usr/share/doc/clang-7-dbgsym': No such file or directory
  # ls -la /usr/share/doc/clang-7-dbgsym/
  ls: cannot access '/usr/share/doc/clang-7-dbgsym/': No such file or directory


cheers,

Andreas


clang-7-dbgsym_1:7.0.1-8~deb9u3.log.gz
Description: application/gzip

Bug#1036302: free(): double free detected in tcache 2 during history search

[Bernhard Übelacker]

Hello,
below is the top of a valgrind run
with dbgsym package installed.

Kind regards,
Bernhard



benutzer@debian:~$ valgrind bash
==1114== Memcheck, a memory error detector
==1114== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1114== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1114== Command: bash
==1114==
benutzer@debian:~$ bind '"\C-p": history-search-backward'
benutzer@debian:~$ bind '"\C-n": history-search-forward'
benutzer@debian:~$

Control-P   # history-search-backward
Control-U   # unix-line-discard
Control-P   # history-search-backward
Control-U   # unix-line-discard
Control-N   # history-search-forward
Control-J   # accept-line

==1114== Invalid read of size 4
==1114==at 0x1E9D04: rl_do_undo (undo.c:186)
==1114==by 0x1EA0B4: rl_revert_line (undo.c:337)
==1114==by 0x1CD86C: readline_internal_teardown (readline.c:498)
==1114==by 0x1CEC7B: readline_internal (readline.c:734)
==1114==by 0x1CEC7B: readline (readline.c:387)
==1114==by 0x13AFE1: yy_readline_get (parse.y:1528)
==1114==by 0x13DAE0: yy_getc (parse.y:1462)
==1114==by 0x13DAE0: shell_getc (parse.y:2393)
==1114==by 0x13FF5A: read_token.constprop.0 (parse.y:3402)
==1114==by 0x1440BA: yylex (parse.y:2890)
==1114==by 0x1440BA: yyparse (y.tab.c:1854)
==1114==by 0x13A5B5: parse_command (eval.c:348)
==1114==by 0x13A743: read_command (eval.c:392)
==1114==by 0x13A8F5: reader_loop (eval.c:139)
==1114==by 0x1393D8: main (shell.c:833)
==1114==  Address 0x53ba808 is 24 bytes inside a block of size 32 free'd
==1114==at 0x484317B: free (vg_replace_malloc.c:872)
==1114==by 0x1E9ABA: _rl_free_undo_list (undo.c:111)
==1114==by 0x1F03DF: _rl_free_saved_history_line (misc.c:396)
==1114==by 0x1D4286: rl_history_search_forward (search.c:647)
==1114==by 0x1CDD96: _rl_dispatch_subseq (readline.c:916)
==1114==by 0x1CE371: _rl_dispatch (readline.c:860)
==1114==by 0x1CE371: readline_internal_char (readline.c:675)
==1114==by 0x1CEC64: readline_internal_charloop (readline.c:721)
==1114==by 0x1CEC64: readline_internal (readline.c:733)
==1114==by 0x1CEC64: readline (readline.c:387)
==1114==by 0x13AFE1: yy_readline_get (parse.y:1528)
==1114==by 0x13DAE0: yy_getc (parse.y:1462)
==1114==by 0x13DAE0: shell_getc (parse.y:2393)
==1114==by 0x13FF5A: read_token.constprop.0 (parse.y:3402)
==1114==by 0x1440BA: yylex (parse.y:2890)
==1114==by 0x1440BA: yyparse (y.tab.c:1854)
==1114==by 0x13A5B5: parse_command (eval.c:348)
==1114==  Block was alloc'd at
==1114==at 0x48407B4: malloc (vg_replace_malloc.c:381)
==1114==by 0x1A2C8D: xmalloc (xmalloc.c:114)
==1114==by 0x1E9A4E: alloc_undo_entry (undo.c:75)
==1114==by 0x1E9A4E: rl_add_undo (undo.c:92)
==1114==by 0x1EDB41: rl_delete_text (text.c:152)
==1114==by 0x1E8E4C: rl_kill_text (kill.c:177)
==1114==by 0x1E9466: rl_unix_line_discard (kill.c:412)
==1114==by 0x1CDD96: _rl_dispatch_subseq (readline.c:916)
==1114==by 0x1CE371: _rl_dispatch (readline.c:860)
==1114==by 0x1CE371: readline_internal_char (readline.c:675)
==1114==by 0x1CEC64: readline_internal_charloop (readline.c:721)
==1114==by 0x1CEC64: readline_internal (readline.c:733)
==1114==by 0x1CEC64: readline (readline.c:387)
==1114==by 0x13AFE1: yy_readline_get (parse.y:1528)
==1114==by 0x13DAE0: yy_getc (parse.y:1462)
==1114==by 0x13DAE0: shell_getc (parse.y:2393)
==1114==by 0x13FF5A: read_token.constprop.0 (parse.y:3402)
==1114==
==1114== Invalid read of size 4
...
==1114==
benutzer@debian:~$ exit
...
==1114== ERROR SUMMARY: 85 errors from 13 contexts (suppressed: 0 from 0)
benutzer@debian:~$

Bug#1031566: Same

[Bernard Bou]

Same bug

Bug#1031046: Asterisk packaging

[Olivier]

Hello,

I lately discovered  this thread.
I volunteer to help to package Asterisk either in current official
Debian repo or in an alternative repository.

The perspectives of Asterisk Deb packaging is talked about in [1] (I'm
the original author of this thread).

One thing that comes to mind reading [1] is that several people
recommend packaging from scratch while it seems to me, that
contributing in coordinated activities may lower the amount of work
(no need to build a repo, to configure host to use a custom repo, ...)
and increase the outcome quality as Debian standards are quite high.

If having Asterisk distributed with Bookwom is a lost cause, maybe we
can try to have latest Asterisk 20.3 be packaged "the Debian way" in
unstable repo and self assign the goal that this build would done by
new contributors, under the control of experienced mainteners ?

Then, what could be the best media to read or add doc about Asterisk packaging ?

[1] 
https://community.asterisk.org/t/status-and-perspectives-of-asterisk-package-on-debian-bookworm/97087/11

Regards

Bug#1035724: ITS: wmforkplop

[Bastian Germann]

Control: retitle -1 O: wmforkplop -- monitors forking activity and displays top 
CPU consuming processes
Control: reassign -1 wnpp

Nobody reacted to the ITS, so I am orphaning the package now.
Please only adopt it if you can afford the time and have skills to maintain it.

Bug#1035852: Updated patch series for version jhove version 1.28.0

[Elias Oltmanns]

Hi Tony,

thanks for your response, that's great news! I look forward to sorting
things out once you have got bookworm out the door.

Best,

Elias


Am 2. Juni 2023 um 06:23 schrieb tony mancill:
> Hi Elias,
> Thank you for your work to update jhove.
> 
> I will review the patches and help with the upload, although not until
> after the bookworm release (which is just over a week away).
> 
> Cheers,
> tony
> 
> On Thu, Jun 01, 2023 at 04:23:33PM +0200, Elias Oltmanns wrote:
>> Hi there,
>> 
>> meanwhile, version 1.28.0 has been released upstream. Please find the
>> updated patch series below.
>> 
>> Also, I have realised that I am probably not asking for a NMU because I
>> am not a Debian developer myself. Can anyone review the patches and help
>> to get a new version uploaded?
>> 
>> Thank you in advance,
>> 
>> Elias
> 
>> From ea1161185c01a2510ba6c7d07b0d98009b78d5b4 Mon Sep 17 00:00:00 2001
>> From: Elias Oltmanns 
>> Date: Wed, 19 Apr 2023 10:00:55 +0200
> 

Bug#1033479: closed by Thomas Goirand (Re: Bug#1033479: minissdpd: Service fails to start on boot with "Error parsing address/mask...")

[Thomas Goirand]

On 6/1/23 17:44, Facundo Gaich wrote:
On Thu, Jun 1, 2023 at 11:54 AM Debian Bug Tracking System 
mailto:ow...@bugs.debian.org>> wrote:


Hi,

This is IMO a missconfiguration, not a bug. Closing accordingly.

Cheers,

Thomas Goirand (zigo)


  Hi Thomas,

Thanks, although, isn't it still a bug if it arrived at a misconfigured 
state without user interaction?


Indeed. Please see the debconf thingy as only a helper to get a first 
configuration in. If for a reason, the system has change state, there's 
not much the package can do without user manual configuration.


Cheers,

Thomas Goirand (zigo)

Bug#1036266: Acknowledgement (mirror submission for mirror.web4africa.co.za)

[Web4Africa]

Hello,

I am yet to receive a response or action on this ticket.

---
Oluniyi D. Ajao
https://web4africa.com

On 2023-05-18 10:21, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1036266: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036266.


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.

Your message has been sent to the package maintainer(s):
 Debian Mirrors Team 

If you wish to submit further information on this problem, please
send it to 1036...@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.

--
1036266: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036266
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1037023: blueman: missing dependency (Failed to load module "xapp-gtk3-module")

[Christopher Schramm]

Hi Marc,

blueman-manager works fine for me without that package and blueman does 
not have anything to do with xapp.


Could it be that you're referring to the module in 
~/.config/gtk-3.0/settings.ini or similar? Do other GTK 3 apps work fine?


Cheers

Bug#999918: [Pkg-zsh-devel] Bug#999918: Bug#999918: zsh: depends on obsolete pcre3 library

[Axel Beckert]

Control: tag -1 + fixed-upstream

Hi Jeremy,

Jeremy Bícha wrote:
> It looks like this was fixed upstream with
> https://github.com/zsh-users/zsh/commit/b62e91134

Ah, nice. Thanks for the hint!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#1001047: todo.txt-gtd: home page 404s

[Nathan Lövsund]

Package: todo.txt-gtd
Version: 0.8
Followup-For: Bug #1001047
X-Debbugs-Cc: nat...@lovsund.eu

Dear Maintainer,

The homepage URL in the package metadata (`apt show todo.txt-gtd`)
still leads to a 404.

Have a nice day!

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

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

Versions of packages todo.txt-gtd depends on:
ii  python3 3.11.2-1+b1
pn  python3-configargparse  
pn  python3-relatorio   
pn  todo.txt-base   
pn  topydo  

Versions of packages todo.txt-gtd recommends:
ii  todotxt-cli  2.11.0-2

todo.txt-gtd suggests no packages.

Bug#1037032: blastem manpage improvement

[Stéphane Blondon]

Package: blastem
Version: 0.6.3-pre
Severity: minor
Tags: patch

A lot of manpages start with a SYNOPSIS section. This patch adds it to
the blastem manpage.

The patch adds also the most basic example and reorder the others. I
think it's more understandable for a beginner.

The patch is available in salsa:
https://salsa.debian.org/games-team/blastem/-/merge_requests/2


-- 
Stéphane

Bug#1036190: kmail: Crash on startup when GHNS is disabled in kde5rc

[Felix Stupp]

I have the same issue that kmail on version 4:22.12.3-1 does eventually but 
always crash after a certain time or action.
Makes the program unusable.

I haven't set the "ghns" key to false in /etc/kde5rc,
but I also might not have the full KDE suite installed, I selected the packages 
I need.

And because reverting to 4:22.12.2-1 does solve my issue (aka. 4:22.12.3-1 was 
the first I had this issue),
I assume that I might have the same bug.
So I assume it could be from the same reason, I'm sorry if that assumption of 
mine is wrong.

-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (550, 'testing'), (500, 'testing-security'), (500, 
'stable-security'), (400, 'stable-updates'), (400, 'stable'), (350, 
'oldstable-updates'), (350, 'oldstable'), (110, 'unstable'), (102, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages kmail depends on:
ii  akonadi-server   4:22.12.3-1
ii  kdepim-runtime   4:22.12.3-1
ii  kio  5.103.0-1
ii  libc62.36-9
ii  libgcc-s112.2.0-14
ii  libgpgmepp6  1.18.0-3+b1
ii  libkf5akonadiagentbase5 [libkf5akonadiagentbase5-22  4:22.12.3-1
.12]
ii  libkf5akonadicontact5 [libkf5akonadicontact5-22.12]  4:22.12.3-1
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-22.12]4:22.12.3-1
ii  libkf5akonadimime5 [libkf5akonadimime5-22.12]4:22.12.3-1
ii  libkf5akonadisearch-bin  4:22.12.3-1
ii  libkf5akonadisearch-plugins  4:22.12.3-1
ii  libkf5akonadisearchdebug5 [libkf5akonadisearchdebug  4:22.12.3-1
5-22.12]
ii  libkf5akonadisearchpim5 [libkf5akonadisearchpim5-22  4:22.12.3-1
.12]
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-22  4:22.12.3-1
.12]
ii  libkf5bookmarks5 5.103.0-1
ii  libkf5calendarcore5abi2  5:5.103.0-1
ii  libkf5calendarutils5 [libkf5calendarutils5-22.12]4:22.12.3-1
ii  libkf5codecs55.103.0-1
ii  libkf5completion55.103.0-1
ii  libkf5configcore55.103.0-2
ii  libkf5configgui5 5.103.0-2
ii  libkf5configwidgets5 5.103.0-1
ii  libkf5contacts5  5:5.103.0-1
ii  libkf5coreaddons55.103.0-1
ii  libkf5crash5 5.103.0-1
ii  libkf5dbusaddons55.103.0-1
ii  libkf5grantleetheme-plugins  22.12.3-1
ii  libkf5gravatar5abi2 [libkf5gravatar5-22.12]  4:22.12.3-1
ii  libkf5guiaddons5 5.103.0-1
ii  libkf5i18n5  5.103.0-1
ii  libkf5iconthemes55.103.0-1
ii  libkf5identitymanagement5 [libkf5identitymanagement  22.12.3-1
5-22.12]
ii  libkf5identitymanagementwidgets5 [libkf5identityman  22.12.3-1
agementwidgets5-22.12]
ii  libkf5itemmodels55.103.0-1
ii  libkf5itemviews5 5.103.0-1
ii  libkf5jobwidgets55.103.0-1
ii  libkf5kcmutils5  5.103.0-3
ii  libkf5kiocore5   5.103.0-1
ii  libkf5kiofilewidgets55.103.0-1
ii  libkf5kiogui55.103.0-1
ii  libkf5kiowidgets55.103.0-1
ii  libkf5kontactinterface5 [libkf5kontactinterface5-22  22.12.3-1
.12]
ii  libkf5ksieveui5 [libkf5ksieveui5-22.12]  4:22.12.3-1
ii  libkf5ldap5abi1 [libkf5ldap5-22.12]  22.12.3-1
ii  libkf5libkdepim5 [libkf5libkdepim5-22.12]4:22.12.3-1
ii  libkf5libkleo5 [libkf5libkleo5-22.12]4:22.12.3-1
ii  libkf5mailcommon5abi2 [libkf5mailcommon5-22.12]  4:22.12.3-1
ii  libkf5mailtransport5 [libkf5mailtransport5-22.12]22.12.3-1
ii  libkf5mailtransportakonadi5 [libkf5mailtransportako  22.12.3-1
nadi5-22.12]
ii  libkf5messagecomposer5abi1 [libkf5messagecomposer5-  4:22.12.3-1
22.12]
ii  libkf5messagecore5abi1 [libkf5messagecore5-22.12]4:22.12.3-1
ii  libkf5messagelist5abi1 [libkf5messagelist5-22.12]4:22.12.3-1
ii  libkf5messageviewer5abi1