Bug#1035985: Built without GLESv2 support causing errors on machines only supporting GLES

[Erik Inkinen]

Hi Lisandro,

I think I misunderstood the Qt documentation myself. It seems the
dynamic GLES support is only available on Windows, but the changes in
qt6 rendering would still minimize the requirements for rebuilt
packages.

It seems that it is only necessary to rebuild libqt6gui6 with
"-DINPUT_opengl=es2". Maybe you could make a new source package for
Qt6 Base on GLES and make it build libqt6gui6 and only it.

For reference, you can take a look at
https://github.com/cutie-shell/qt6-base/tree/feature/bookworm/gles_minimal/debian
. Note that you would need to use a different package name like
libqt6gui6-gles and it should provide and conflict with libqt6gui6.

Kind regards,
Erik Inkinen

Bug#990298: conserver-server - ipmi support

[Paul B. Henson]

Please add ipmi support to this package.

Bug#1037136: dpkg-buildflags: 64-bit time_t by default

[Steve Langasek]

Package: dpkg-dev
Version: 1.21.22
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic patch

Hi Guillem,

The discussion on debian-devel around 64-bit time_t has died down, so I
figure it's time to propose some patches to implement what's been discussed
there.

I'm not sure whether you were persuaded that i386 should stay with the
current ABI, but anyway thought I would propose the patches and we could
discuss further if necessary.

-- 
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
From 5a861d19b1610ae82bf95e6c5142a3365436fbd2 Mon Sep 17 00:00:00 2001
From: Steve Langasek 
Date: Fri, 2 Jun 2023 14:30:20 +
Subject: [PATCH 1/3] lfs and time64 are no longer "future", call them
 "feature" instead

Recognize future= for backwards compatibility.
---
 scripts/Dpkg/Vendor/Debian.pm | 32 ++--
 scripts/t/Dpkg_BuildFlags.t   |  2 +-
 2 files changed, 23 insertions(+), 11 deletions(-)

diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
index 9285a61cf..f3d81bcc2 100644
--- a/scripts/Dpkg/Vendor/Debian.pm
+++ b/scripts/Dpkg/Vendor/Debian.pm
@@ -105,10 +105,14 @@ sub set_build_features {
 
 # Default feature states.
 my %use_feature = (
-future => {
+feature => {
 lfs => 0,
 time64 => 0,
 },
+future => {
+lfs => -1,
+time64 => -1,
+},
 qa => {
 bug => 0,
 canary => 0,
@@ -172,9 +176,17 @@ sub set_build_features {
 ($abi, $os, $cpu) = ('', '', '');
 }
 
-## Area: future
+# compatibility: map future=[+-]lfs,time64 onto 'feature'
+if ((my $flag = $use_feature{future}{lfs}) != -1) {
+$use_feature{feature}{lfs} = $flag;
+}
+if ((my $flag = $use_feature{future}{time64}) != -1) {
+$use_feature{feature}{time64} = $flag;
+}
+
+## Area: feature
 
-if ($use_feature{future}{time64}) {
+if ($use_feature{feature}{time64}) {
 # On glibc, new ports default to time64, old ports currently default
 # to time32, so we track the latter as that is a list that is not
 # going to grow further, and might shrink.
@@ -211,16 +223,16 @@ sub set_build_features {
 if ($abi_bits != 32 or
 not exists $time32_arch{$arch} or
 $libc eq 'musl') {
-$use_feature{future}{time64} = 0;
+$use_feature{feature}{time64} = 0;
 } elsif ($libc eq 'gnu') {
 # On glibc 64-bit time_t support requires LFS.
-$use_feature{future}{lfs} = 1;
+$use_feature{feature}{lfs} = 1;
 }
 }
 
-if ($use_feature{future}{lfs}) {
+if ($use_feature{feature}{lfs}) {
 if ($abi_bits != 32) {
-$use_feature{future}{lfs} = 0;
+$use_feature{feature}{lfs} = 0;
 }
 }
 
@@ -375,14 +387,14 @@ sub _add_build_flags {
 $flags->append($_, $default_flags) foreach @compile_flags;
 $flags->append('DFLAGS', $default_d_flags);
 
-## Area: future
+## Area: feature
 
-if ($flags->use_feature('future', 'lfs')) {
+if ($flags->use_feature('feature', 'lfs')) {
 $flags->append('CPPFLAGS',
'-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64');
 }
 
-if ($flags->use_feature('future', 'time64')) {
+if ($flags->use_feature('feature', 'time64')) {
 $flags->append('CPPFLAGS', '-D_TIME_BITS=64');
 }
 
diff --git a/scripts/t/Dpkg_BuildFlags.t b/scripts/t/Dpkg_BuildFlags.t
index 850fe28b8..d64c54bfd 100644
--- a/scripts/t/Dpkg_BuildFlags.t
+++ b/scripts/t/Dpkg_BuildFlags.t
@@ -85,7 +85,7 @@ is($bf->get_origin('DPKGFLAGS'), 'env', 'flag has an env origin');
 ok($bf->is_maintainer_modified('DPKGFLAGS'), 'prepend marked flag as maint modified');
 
 my %known_features = (
-future => [ qw(
+feature => [ qw(
 lfs
 time64
 ) ],
-- 
2.40.1

From 02ea4e4b7b472754458a64f37f61712d55d25c91 Mon Sep 17 00:00:00 2001
From: Steve Langasek 
Date: Fri, 2 Jun 2023 14:54:33 +
Subject: [PATCH 2/3] Enable time64 by default for all 32-bit archs, except for
 i386

---
 scripts/Dpkg/Vendor/Debian.pm | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
index f3d81bcc2..20d77fea1 100644
--- a/scripts/Dpkg/Vendor/Debian.pm
+++ b/scripts/Dpkg/Vendor/Debian.pm
@@ -107,7 +107,7 @@ sub set_build_features {
 my %use_feature = (
 feature => {
 lfs => 0,
-time64 => 0,
+time64 => 1,
 },
 future => {
 lfs => -1,
@@ -160,11 +160,6 @@ sub set_build_features {
 my $opts_build = 

Bug#1037135: please update to latest upstream version and confirm intent to maintain package

[Nicholas D Steeves]

Source: modus-themes
Version: 1.0.2-1
Severity: normal
X-Debbugs-Cc: Dhavan Vaidya 

Hi Dhavan,

I hope this email finds you in good health.  Are you still interested
in maintaining modus-themes?  The repository hasn't seen any activity
since 2021, the current stable upstream version is now 4.2.0, and this
makes it look like the package is effectively unmaintained.

Regards,
Nicholas

Bug#990016: marked as done (Debian installer images missing ASpeed video driver)

[Timothy Pearson]

Earlier merge request was redundant, after futher tracing I believe this merge 
request directly addresses the root of the remaining issues:

https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/34

- Original Message -
> From: "Timothy Pearson" 
> To: "990016" <990...@bugs.debian.org>
> Cc: "Salvatore Bonaccorso" 
> Sent: Monday, June 5, 2023 2:02:55 PM
> Subject: Re: Bug#990016: marked as done (Debian installer images missing 
> ASpeed video driver)

> Unfortunately it appears the bug persists.  On the latest ppc64el netinst 
> weekly
> build there is no trace of the ast module:
> 
> ~ # modprobe ast
> modprobe: FATAL: Module ast not found in directory
> /lib/modules/6.1.0-9-powerpc64le

Bug#1036818: [pkg-lxc-devel] Bug#1036818: Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat

[Mathias Gibbens]

On Thu, 2023-06-01 at 18:58 +0200, Pierre-Elliott Bécue wrote:
> >   I should have time this weekend when I can spin up a qemu vm to
> > test in, if we're not able to get a root cause identified before
> > then.

  I did try to reproduce the issue over the weekend with qemu. Using
qemu-user-static and systemd-nspawn was insufficient due to lxcfs
needing proper access to the fuse kernel api. After trying and failing
to bootstrap an armhf instance by hand, I grabbed a raspberry pi 2
bookworm image from raspi.d.n, and got it running under qemu-system-
arm. Within that environment, lxcfs appeared to work correctly
(/var/lib/lxcfs/proc/cpuinfo was correct, no obvious errors or warnings
noticed). I didn't spin up a full lxc container instance within that
environment.

> I can probably grant you privileges on abel as soon as I get an ack
> from my fellow DSA mates.

  If it's possible to get temporary permissions on abel, that would be
useful.

  One other thing to double check on ci-worker-armhf-01 would be the
contents of /var/lib/lxcfs/proc/cpuinfo, so we can see what lxcfs is
doing from the host side.

Mathias


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

Bug#1035985: Built without GLESv2 support causing errors on machines only supporting GLES

[Lisandro Damian Nicanor Perez Meyer]

Hi Erik, Leonardo

On Sun, 4 Jun 2023 22:41:46 -0300 Lisandro Damián Nicanor Pérez Meyer 
 wrote:
[snip]
> > please consider bumping the severity level of #1035985, as it makes
> > Debian unable to use qt on the many embedded platforms, and the next
> > stable will be affected by this for a long time. Is it possible to
> > include the `QT_FEATURE_opengles2` flag before the release? I'm
> > willingly to send a patch if needed.
> 
> I am afraid it was discovered too late in the release process. My plan
> is to test it as soon as Bookworm is released and hopefully get a
> stable pu update. But I can't promise anything.
> 
> Bumping the severity for a feature not discovered in time is a non-go.
> 
> 

I reviewed this bug report. libgles-dev is present in the build, as you can see 
in [0].

[0] 


Moreover, if you grep for "gles" in the build log [1] you will see that both 
libgles1 and libgles2 are present.

[1] 


Or even:

```
-- Performing Test HAVE_GLESv2
-- Performing Test HAVE_GLESv2 - Success
-- Found GLESv2: /usr/include 
```

If I force FEATURE_opengles2=ON I get:

```
CMake Error at cmake/QtBuildInformation.cmake:490 (message):
  Feature "opengles2": Forcing to "ON" breaks its condition:

  NOT WIN32 AND NOT WATCHOS AND NOT QT_FEATURE_opengl_desktop AND 
GLESv2_FOUND

  Condition values dump:

  WIN32 = ""
  WATCHOS = "0"
  QT_FEATURE_opengl_desktop = "ON"
  GLESv2_FOUND = "TRUE"

Call Stack (most recent call first):
  cmake/QtFeature.cmake:281 (qt_configure_add_report_error)
  cmake/QtFeature.cmake:403 (qt_feature_check_and_save_internal_value)
  cmake/QtFeature.cmake:606 (qt_evaluate_feature)
  cmake/QtFeature.cmake:575 (qt_feature_module_end)
  src/CMakeLists.txt:12 (qt_feature_evaluate_features)
```

So, unless I am missing something, it is Qt itself the one not producing OpenGL 
ES 2 support.

Am I missing something here?

Kinds regards, Lisandro.

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

Bug#1036983: bookworm-pu: package workflow/0.10.5-2

[Bastian Germann]

Control: retitle -1 RM: srpc/0.9.8-1.1
Control: user -1 release.debian@packages.debian.org
Control: usertags rm

On Sat, 3 Jun 2023 19:31:25 +0200 Bastian Germann  wrote:

One more note: srpc is still in testing but build-depends on libworkflow-dev.
If you do not want workflow to enter testing again, please remove srpc from 
testing as well.


Please remove srpc from bookworm which FTBFS without workflow.

Bug#918075: Some patches for dar

[John Goerzen]

On Mon, Jun 05 2023, László Böszörményi (GCS) wrote:

> Hi John,
>
> On Mon, Jun 5, 2023 at 10:12 PM John Goerzen  wrote:
>> If you are open to me taking over dar at this time, I would go ahead and
>> upload 2.7.9 (with my updates above) with the maintainer changed to me.
>  I just ask for one thing. Please wait until Bookworm is released -
> probably this or next week. Then go ahead and take over dar.

OK, will do.  Thanks László!

- John


>
> Regards,
> Laszlo/GCS

Bug#918075: Some patches for dar

[GCS]

Hi John,

On Mon, Jun 5, 2023 at 10:12 PM John Goerzen  wrote:
> If you are open to me taking over dar at this time, I would go ahead and
> upload 2.7.9 (with my updates above) with the maintainer changed to me.
 I just ask for one thing. Please wait until Bookworm is released -
probably this or next week. Then go ahead and take over dar.

Regards,
Laszlo/GCS

Bug#1037114: python3-opensnitch-ui: Desktop notifications should expire

[Gustavo Iñiguez Goya]

This issue was reported here:
https://github.com/evilsocket/opensnitch/issues/673

I didn't find a proper way of solving it.

On Mon, 5 Jun 2023 at 06:39, Petter Reinholdtsen  wrote:
>
>
> Package: python3-opensnitch-ui
> Version: 1.5.8.1-1
>
> In KDE, when a opensnitch dialog timed out and a connection is blocked,
> a notification show up in my lower right corner that the connection was
> indeed blocked.  These notifications never expire, causing a machine
> running over the weekend with Firefox running, to fill the right part of
> screen with a lot of notifications.  I have to manually click away these
> notifications to get rid of them.
>
> Can the behaviour be changed to expire these popup notifications after a
> while, for example 15 minutes?
>
> --
> Happy hacking
> Petter Reinholdtsen
>


-- 

Clave Pública:
gpg --keyserver pgp.rediris.es --recv-keys BCF6BE9C

Bug#1034128:

[Andreas Hasenack]

The problem is that 1.6.19-1 is listening on ipv6 as well, and that
makes the test suite fail to start another copy due to "address
already in use":

@@__xproc_block_delimiter__@@
slab class 1: chunk size 96 perslab 10922
(...)
failed to listen on TCP port 11211: Address already in use

1.6.18-1 only listened on 127.0.0.1:11211.

Best way to fix? Not sure yet. Maybe kill the system-provided
memcached before running the test? That might need to have the test
run as root, at least to execute that action, which is annoying...

Bug#1037133: Subfolders unavailable in Settings

[Lukáš Svoboda]

Typo correction: ..., folder hierarchy does _NOT_ expand...

L.


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1037133: owncloud-client: Subfolders unavailable in Settings

[Lukas Svoboda]

Package: owncloud-client
Version: 2.11.0.8354+dfsg-1+b1
Severity: normal
X-Debbugs-Cc: svobod...@gmail.com

Dear Maintainer,

subfolders cannot be accessed in Settings - Account setting to choose
individually what folders should sync. Only top level folders can be displayed,
folder hierarchy does expand after clicking the expander arrow left to the
folder name.

L.


-- 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/4 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 owncloud-client depends on:
ii  libc6  2.36-9
ii  libowncloudsync0   2.11.0.8354+dfsg-1+b1
ii  libqt5core5a   5.15.8+dfsg-10
ii  libqt5dbus55.15.8+dfsg-10
ii  libqt5gui5 5.15.8+dfsg-10
ii  libqt5keychain10.13.2-5
ii  libqt5network5 5.15.8+dfsg-10
ii  libqt5sql5-sqlite  5.15.8+dfsg-10
ii  libqt5widgets5 5.15.8+dfsg-10
ii  libqt5xml5 5.15.8+dfsg-10
ii  libstdc++6 12.2.0-14

Versions of packages owncloud-client recommends:
pn  owncloud-client-doc  

owncloud-client suggests no packages.

-- no debconf information

Bug#1037132: pahole missing final "cacheline boundary" message

[Aitken, Paul]

Package: pahole
Version: v1.21

It would be useful to emit a final a final "cacheline boundary" message 
when a structure ends on a cacheline, and emit a final "cacheline 
boundary was NN bytes ago" message when the last member overruns into a 
new cache line.

Bug#918075: Some patches for dar

[John Goerzen]

Hi László,

With bookworm almost released, I figured I'd check back in.  In addition
to the uses I've been using dar for already, I'm beginning work on a
long-term data archiving project with it, which is expanding my use case
set.  I blogged about that at
https://changelog.complete.org/archives/10500-recommendations-for-tools-for-backing-up-and-archiving-to-removable-media
if you are interested.

Anyhow, additional comments inline below:

On Wed, Mar 08 2023, László Böszörményi wrote:

> Hi John,
>
> On Wed, Mar 8, 2023 at 2:47 PM John Goerzen  wrote:
>> I had thought that I'd be able to get by without the delta-diff
>> features, but due to some changes over here, they would save me multiple
>> GBs per day.  So I am happy to dive in to work on dar.
>  Sounds good.
>
>> I have submitted an ITP for libthreadar, which will allow multithreaded
>> compression/encryption as well as enable remote repository support.  I
>> have also uploaded a backport of librsync to bullseye-backports to
>> enable a future dar backport to bullseye with binary delta support.
>  Where can I check the libthreadar packaging?

This is now in NEW and available at
https://salsa.debian.org/debian/libthreadar

>> Would you like me to take over maintaining dar?  Or would you like to
>> apply the patch (with appropriate changelog updates) and upload it?  Or
>> I could upload it and leave the maintainers line alone?
>  It's a release freeze for Bookworm. I'm asking for approval and will
> do it once it is allowed.
> I am open to giving the package to you during the Trixie release cycle.

I saw that the request to include a patched version in bookworm was
denied; that's unfortunate, but I will prepare a backport for it anyway.

My local patchset (not uploaded) carries this changelog:

  * Support delta changes via librsync.
  * Update dep on e2fslibs-dev to new name libext2fs-dev
  * Add dep on libcap-dev to eneable proper capability handling.
  * Add build-dependency on dot to ensure figures for docs are always
built.

Some of the dar frontends use the Python bindings, so I may also look
into getting those built in the future.

If you are open to me taking over dar at this time, I would go ahead and
upload 2.7.9 (with my updates above) with the maintainer changed to me.

Thanks,

John

Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements

[Martin-Éric Racine]

On Mon, Jun 5, 2023 at 10:20 PM Paul Gevers  wrote:
> On 05-06-2023 04:38, Martin-Éric Racine wrote:
> >>> On a related issue, something in dpkg or apt should check the CPU
> >>> features and refuse to perform an upgrade/dist-upgrade on an host
> >>> whose CPU doesn't meet the new baseline requirements.
> >>
> >> Please file a bug with the respective packages. Mentioning it in a bug
> >> against the release notes isn't going to achieve that feature.
> >
> > Oh, totally. I'm just not sure of which one typically handles this.
> > Last time the baseline was raised from 586 to 686 (before that from
> > 486 to 586), something in the upgrade process performed the CPU check
> > and loudly aborted the proceedings. Something similar was done when
> > the baseline was raised on SPARC ages ago; upgrade aborted early if
> > the host hardware didn't meet the new baseline.
>
> I wasn't aware of that. I *think* dpkg just installs what apt feeds it,
> so from those two, I'd guess apt. However, it's too late for bookworm to
> add that now. I thought you meant this mostly as a future enhancement.

Then the baseline will have to remain at 686 WITHOUT NOPL for Bookworm.

Sorry, but a baseline bump really has to be better planned and better
documented than this. Merely deciding to update the release notes at
the last minute because everyone is too lazy to fix the 20% of
packages or so that --configure NOPL or some more recent flag really
won't do.

Martin-Éric

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

[Xan Charbonnet]

Thanks very much, and apologies for my flawed analysis.  It's good to 
know this will be fixed in bookworm.  We're not going to be able to 
upgrade immediately so it would be nice if it could be fixed in 
bullseye, but I understand if that isn't the decision.

Bug#990016: marked as done (Debian installer images missing ASpeed video driver)

[Timothy Pearson]

Issue traced and merge request opened here:

https://salsa.debian.org/kernel-team/linux/-/merge_requests/743

- Original Message -
> From: "Timothy Pearson" 
> To: "990016" <990...@bugs.debian.org>
> Cc: "Salvatore Bonaccorso" 
> Sent: Monday, June 5, 2023 2:02:55 PM
> Subject: Re: Bug#990016: marked as done (Debian installer images missing 
> ASpeed video driver)

> Unfortunately it appears the bug persists.  On the latest ppc64el netinst 
> weekly
> build there is no trace of the ast module:
> 
> ~ # modprobe ast
> modprobe: FATAL: Module ast not found in directory
> /lib/modules/6.1.0-9-powerpc64le

Bug#1037131: ITP: stdgpu -- Efficient STL-like Data Structures on the GPU

[Timo Röhling]

Package: wnpp
Severity: wishlist
Owner: Timo Röhling 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: stdgpu
  Version : 1.3.0+git20220507.32e0517
  Upstream Author : Patrick Stotko
* URL : https://github.com/stotko/stdgpu
* License : Apache-2, BSD-3-clause, CC-BY-SA-3
  Programming Lang: C++
  Description : Efficient STL-like Data Structures on the GPU

stdgpu is an open-source library providing several generic GPU data structures
for fast and reliable data management. Multiple platforms such as CUDA,
OpenMP, and HIP are supported allowing you to rapidly write highly complex
agnostic and native algorithms that look like sequential CPU code but are
executed in parallel on the GPU.

The package will be maintained by Timo Röhling 
at https://salsa.debian.org/debian/stdgpu


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmR+OGMACgkQ+C8H+466
LVn5jgv9H09msVcdx84aRR+l4Ny6OFp498xVdttQvJZah2CN8vEC/BCJP7EQcv1o
D9OB02xOSvGwk5/qgPEzoJdgkuEyrjvw4hebkbw0y6owQN2uuCRCx77ncse2td81
9pAhb7cH4P+bBhf9ITtmhHjDZ7/g+8mcatRUFwITixzbuK2DqNplsDKyyK8G4PAz
nXXIpPaPA9CsW6LzHbISaVb1MK8ESLWIwsjiPabxEc+kmC4635QjCNI9pcY2LyIM
zTou7WIdd0mpxtXKU7Jlk1nkqJzfGdyL2c+AhBMg7JGnq/CLNkpRwzoMBTDyz0Dc
l7EBelMetVnTz35wQZTraC5icKsYOlTfMlhnZWa4kDHqtQwah8RrMeVjHp2Lrj8J
DfKyB821zQx/B5R/mUHBEkdJjcG9yqAFPWjhjeX0TWO5SI3zHZVaa+42LxBk5f8W
Vp6Y3rtdP0d+5FJh4CP5cwEFCSTUCCDj6a9R9WT3MzBt1As31qfJZ9Ymf6xU6fPO
0nBMOZNl
=K7Cv
-END PGP SIGNATURE-

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

[Niko Tyni]

reassign 1037063 libxml2 2.9.10+dfsg-6.7
found 1037063 2.9.10+dfsg-6.7+deb11u4
close 1037063 2.9.12+dfsg-1
forwarded 1037063 https://gitlab.gnome.org/GNOME/libxml2/-/issues/188
thanks

Hi, thanks for the report. See below for some analysis.

(TL;DR: It's a bug in libxml2 that was fixed upstream after the version
in bullseye, and the fix will be in the upcoming bookworm release.)

On Fri, Jun 02, 2023 at 10:38:02PM -0500, Xan Charbonnet wrote:
> 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.

[...]

> 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.

This last part is not quite correct: validation also fails for the
backtick (`) and the tilde (~) characters. It's not about quoting,
it's about mistreating the caret (^) in the middle of the pattern.

The fault actually lies is in libxml2 which libxml-libxml-perl uses,
as seen with `xmllint --schema test.xsd test.xml` (xmllint is in
the libxml2-utils package).

It looks like it was fixed upstream in libxml2 2.9.11 with

  
https://gitlab.gnome.org/GNOME/libxml2/-/commit/7d6837ba0e282e94eb8630ad791f427e44a57491

and the fix entered Debian with 2.9.12.

I'm reassigning and closing the bug as it's fixed in current versions
in unstable and testing.  Not sure if it's something that should be
backported to current Debian stable (bullseye). Feel free to discuss
that with the libxml2 maintainers (cc'd) if you like.

-- 
Niko Tyni   nt...@debian.org

Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements

[Paul Gevers]

Hi,

On 05-06-2023 04:38, Martin-Éric Racine wrote:

On a related issue, something in dpkg or apt should check the CPU
features and refuse to perform an upgrade/dist-upgrade on an host
whose CPU doesn't meet the new baseline requirements.


Please file a bug with the respective packages. Mentioning it in a bug
against the release notes isn't going to achieve that feature.


Oh, totally. I'm just not sure of which one typically handles this.
Last time the baseline was raised from 586 to 686 (before that from
486 to 586), something in the upgrade process performed the CPU check
and loudly aborted the proceedings. Something similar was done when
the baseline was raised on SPARC ages ago; upgrade aborted early if
the host hardware didn't meet the new baseline.


I wasn't aware of that. I *think* dpkg just installs what apt feeds it, 
so from those two, I'd guess apt. However, it's too late for bookworm to 
add that now. I thought you meant this mostly as a future enhancement.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#990016: marked as done (Debian installer images missing ASpeed video driver)

[Timothy Pearson]

Unfortunately it appears the bug persists.  On the latest ppc64el netinst 
weekly build there is no trace of the ast module:

~ # modprobe ast
modprobe: FATAL: Module ast not found in directory 
/lib/modules/6.1.0-9-powerpc64le

Bug#947685: still occuring on Linux 6.1.0-9-amd64 x86_64

[Christian]

> On Sun, 2023-05-28 at 21:22 +0200, Christian wrote:
> > I am plagued with this on current Linux 6.1.0-9-amd64 x86_64.
> > 
> > As soon as load on the system increases, the error comes up and
> > apparently it takes some other things (SATA) with it. Leaving the
> > system workable, but slowly failing.
> > 
> > Happy to provide more information or test things.
> 
> Please open a new bug report.  Seeing the same message doesn't mean
> you're seeing the same bug.
> 
> Ben.
> 
Did so under https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036900
added some infos and happy to do more testing if anyone can give a hint
on what to try next.

Bug#1033398: linux-image-amd64: reproducible kernel freeze on 5.19+

[Florian Lehner]

Hi all,

the fix was merged upstream with 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/maccess.c?id=d319f344561de23e810515d109c7278919bff7b0


- florian

On 3/25/23 16:58, Diederik de Haas wrote:

Control: found -1 5.19~rc4-1~exp1
Control: forwarded -1 
https://lore.kernel.org/bpf/20230118051443.78988-1-alexei.starovoi...@gmail.com/

On Saturday, 25 March 2023 16:00:47 CET Florian Lehner wrote:

Via https://snapshot.debian.org/binary/linux-image-amd64/ you can easily
test various kernel versions. Could you try whether 5.19~rc4-1~exp1
indeed produces the problem?


Yes - I can reproduce the total system freeze with 5.19~rc4-1~exp1


Thanks. Then the most likely case was that it was introduced in
the 5.19 merge window and thus also present in 5.19-rc1, but there isn't a
prebuild kernel to verify.


Since the running program is rather complex, it is not easily possible
to carve out a small reproducer. We can provide gdb backtraces from
freezes inside qemu.


Someone else would have to chime in for the backtraces; that's beyond my
skill set.


I just learned about
https://lore.kernel.org/bpf/20230118051443.78988-1-alexei.starovoitov@gmail.
com/. With the provided patch applied I no longer mange to freeze the
system.


I see you already responded to that thread, excellent :-)
Hopefully they'll read this whole bug report, but mentioning that your actual
problem was NOT triggered till 5.18, but did trigger from 5.19-rc4 and later,
could be useful. I may not fully understand what upstream talked about, but I
only saw a reference to a 6.0.0 kernel.

Thanks for testing and reporting back :-)

Bug#448105: mplayer: Illegal Instruction in init_audio_codec

[Reimar Döffinger]

> On 5 Jun 2023, at 00:08, Lorenzo  wrote:
> 
> Hi Reimar,
> 
[...]
> 
> The above was 16 years ago; on Debian powerpc list a couple a
> ways to do runtime detection were suggested
> 
> https://lists.debian.org/debian-powerpc/2023/06/msg00030.html
> 
> could you please check again if it's still unfeasible to detect altivec
> at runtime in mplayer/mencoder?

While it's still plenty messy, FFmpeg has runtime detection of altivec, and 
MPlayer itself has no altivec code itself.
But I don't think it works, the problem is the compiler options:
- to be able to compile code using altivec and have the optimizations 
available, -maltivec must be used
- if -maltivec is used, even normal C code will use altivec instructions, thus 
crashing

The first thing to check would be whether FFmpeg (ffplay in particular) works 
(supporting both altivec optimized playback and not crashing without altivec).
But in the end I don't know if it is realistic to change the situation:
- implementing and testing is hard since not much hardware is around (and at 
least some build system adjustments will be needed)
- without altivec, the machines are so slow, certainly nothing but ancient 
video files will be playable, putting the benefit a bit in question of running 
on non-altivec machines
- building the base code without -maltivec will make MPlayer slower on machines 
with altivec like G4, which might be enough to push them over the edge to not 
be able to play certain videos that they can otherwise

So maybe it is possible to get to work now, but probably separate builds would 
remain the better approach.
On the plus side, if FFmpeg works, and since Debian links MPlayer to FFmpeg 
dynamically, --disable-altivec should be all that is needed - assuming the 
performance degradation on altivec enabled systems mentioned above is 
considered acceptable.

Best regards,
Reimar

Bug#1037075: diffoscope: Get's killed trying to diff 2 large images (> 5GB)

[Chris Lamb]

forwarded 1037075 
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/342
thanks

I've forwarded this "upstream" here:

  https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/342


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1037130: elinks: lost lua support

[Sven Joachim]

Package: elinks
Version: 0.16.1.1-2

This version of elinks no longer depends on liblua5.1, although
liblua5.1-dev is still in Build-Depends.  Since nothing has been
mentioned in the Debian changelog, I guess this is not intended?


-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.182-nouveau (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages elinks depends on:
ii  elinks-data   0.16.1.1-2
ii  libbrotli11.0.9-2+b6
ii  libc6 2.36-9
ii  libev41:4.33-1
ii  libexpat1 2.5.0-1
ii  libfsplib00.14-5
ii  libgcrypt20   1.10.1-3
ii  libgnutls30   3.7.9-2
ii  libgpm2   1.20.7-10+b1
ii  libgssapi-krb5-2  1.20.1-2
ii  libidn12  1.41-1
ii  liblzma5  5.4.1-0.2
ii  libperl5.36   5.36.0-7
ii  libtinfo6 6.4-4
ii  libtre5   0.8.0-7
ii  zlib1g1:1.2.13.dfsg-1

elinks recommends no packages.

Versions of packages elinks suggests:
pn  elinks-doc  

-- no debconf information

Bug#1037129: debian-edu-router: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: debian-edu-router
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

This is for version: 2.12.7

Kind regards.

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


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

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

[Beauregard,Christophe (ECCC)]

I've managed to find a workaround. Not a great workaround, but it seems to let 
me take advantage of all cores for OMP without penalty. I'll be running some 
more tests on that.

The thread needs to call:

#include 
omp_pause_resource_all(omp_pause_soft);

at thread termination (a hard pause seens fine, too). The program needs to 
compiled with -fopenmp.

The call releases the TLS variables, and I believe that's what triggers the 
release of the memory mapped thread arena.

The downsides of that fix are (a) OMP doesn't get to share the thread pool 
across the program but instead blows it away for each thread the finishes, and 
(b) calling programs need to know stuff about the use of OMP at a level they 
really shouldn't need to know about.

It doesn't feel like something that can be shimmed into the GM API in a nice 
place, as IMHO there really isn't much other than Initialize/DestroyMagick() 
that should even care about crossing thread boundaries.

It's not entirely a new class of problem. For example, the issue that led me to 
trying the omp_pause_resource_all() call: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035

I still need to dig deeper as it's not clear to me why my particular machine is 
seeing the problem, but I certainly intend to follow up with gomp. I really 
hope it's a bug; a threading API that itself isn't thread-safe would just be... 
weird.

Bug#1036359: crashes with (wrong-type-argument consp nil)

[Antoine Beaupré]

On 2023-06-05 12:16:28, Antoine Beaupré wrote:
> Is there something out there that takes a markdown doc as input and
> outputs a TOC?

Answering my own question, this does what I want:

md_toc github -o .  < tpa-rfc-36-gitolite-gitweb-retirement.md

... and what I want in many cases is actually:

md_toc github -o .  < tpa-rfc-36-gitolite-gitweb-retirement.md | sed 
's/](#.*//;s/ \[/ /'

which is just an ordered list of items, without markdown links.

md_toc is part of `python3-md-toc`.

Bug#1032927: telegram-desktop: QT images management

[Stefano Callegari]

Il Tue, Mar 14, 2023 at 09:42:12AM +0100, To Debian Bug Tracking System scrisse:

Hi, 

today I've installed the telegram-desktop_4.5.3+ds-1+b1_amd64.deb, the last
4.5.*, and don't have any line in syslog.

When I've updated with telegram-desktop_4.6.0+ds-1_amd64.deb, the first
4.6.*, the syslog has filled of lines.

So the bug for me is in 4.6 releases.

Thanks

Stefano

> Package: telegram-desktop
> Version: 4.6.5+ds-1
> Severity: normal
> 
> Dear Maintainer,
> 
> in my syslog I found a very lot of lines like these:
> 
> - when start
>   2023-03-14T08:51:13.782218+01:00 G5045 telegram-desktop[43979]: qt.svg: 
> Error
> while inflating gzip file: SVG format check failed
> 
> - every time I focus it
>   2023-03-14T08:51:31.392459+01:00 G5045 telegram-desktop[43979]:
> QBuffer::seek: Invalid pos: 669743
> 
> Both messages are repeated for tens times in few seconds (the QBuffer with a
> random number positive or negative).
> 
> Maybe the errors are related only with QT
> (https://bugreports.qt.io/browse/QTBUG-45865), but in my system only Telegram
> reports them.
> 
> Thanks
> 
> Stefano
> 
> 
> -- Package-specific info:
> 
> -- System Information:
> Debian Release: 12.0
>   APT prefers unstable
>   APT policy: (903, 'unstable'), (500, 'testing'), (400, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.1.0-6-amd64 (SMP w/4 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:it
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages telegram-desktop depends on:
> ii  libabsl20220623   20220623.1-1
> ii  libavcodec59  7:5.1.2-3
> ii  libavformat59 7:5.1.2-3
> ii  libavutil57   7:5.1.2-3
> ii  libc6 2.36-8
> ii  libgcc-s1 12.2.0-14
> ii  libglib2.0-0  2.74.6-1
> ii  libglibmm-2.68-1  2.74.0-2
> ii  libhunspell-1.7-0 1.7.2+really1.7.1-2
> ii  libjpeg62-turbo   1:2.1.5-2
> ii  libkf5coreaddons5 5.103.0-1
> ii  liblz4-1  1.9.4-1
> ii  libminizip1   1.1-8+b1
> ii  libopenal11:1.19.1-2
> ii  libopus0  1.3.1-3
> ii  libqrcodegencpp1  1.8.0-1.1
> ii  libqt5core5a [qtbase-abi-5-15-8]  5.15.8+dfsg-3
> ii  libqt5gui55.15.8+dfsg-3
> ii  libqt5network55.15.8+dfsg-3
> ii  libqt5qml55.15.8+dfsg-3
> ii  libqt5quickwidgets5   5.15.8+dfsg-3
> ii  libqt5svg55.15.8-2
> ii  libqt5waylandcompositor5  5.15.8-2
> ii  libqt5widgets55.15.8+dfsg-3
> ii  librlottie0-1 0.1+dfsg-4
> ii  libsigc++-3.0-0   3.4.0-1
> ii  libssl3   3.0.8-1
> ii  libstdc++612.2.0-14
> ii  libswresample47:5.1.2-3
> ii  libswscale6   7:5.1.2-3
> ii  libvpx7   1.12.0-1
> ii  libwayland-client01.21.0-1
> ii  libx11-6  2:1.8.4-2
> ii  libxcb-keysyms1   0.4.0-1+b2
> ii  libxcb-record01.15-1
> ii  libxcb-screensaver0   1.15-1
> ii  libxcb1   1.15-1
> ii  libxcomposite11:0.4.5-1
> ii  libxdamage1   1:1.1.6-1
> ii  libxext6  2:1.3.4-1+b1
> ii  libxfixes31:6.0.0-2
> ii  libxrandr22:1.5.2-2+b1
> ii  libxtst6  2:1.2.3-1.1
> ii  libxxhash00.8.1-1
> ii  qt5-image-formats-plugins 5.15.8-2
> ii  zlib1g1:1.2.13.dfsg-1
> 
> Versions of packages telegram-desktop recommends:
> ii  fonts-open-sans   1.11-2
> ii  libwebkit2gtk-4.0-37  2.38.5-1
> ii  libwebkit2gtk-4.1-0   2.38.5-1
> 
> telegram-desktop suggests no packages.
> 
> Versions of packages telegram-desktop is related to:
> ii  xdg-desktop-portal   1.16.0-2
> ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.1-1
> ii  xdg-desktop-portal-kde [xdg-desktop-portal-backend]  5.27.2-1
> 
> -- no debconf information

-- 
Stefano Callegari

Bug#1036359: crashes with (wrong-type-argument consp nil)

[Antoine Beaupré]

On 2023-06-03 20:41:40, Nicholas D. Steeves wrote:
> Nicholas D Steeves  writes:
>
>> I also confirmed that both the patched version (in the staging branch)
>> and unpatched version (in bookworm) work correctly with
>>
>>  
>> https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-36-gitolite-gitweb-retirement.md
>>
>> when one loads markdown-toc and generates the toc before native comp
>> kicks in.
>
> Sorry for not being clear.  What I mean is that I believe that this bug
> is triggered by native compilation, and that it's unlikely that I'll
> find enough time figure out what the upstream issue is before the
> autoremoval.  Also, upstream hasn't seen any activity since 2021...
>
> Feel free to forward this bug and/or adopt this package (I don't use
> it).

You seem to have pasted a link to the TPA GitLab wiki here... Did you
mean to paste some other bug report or link there?

I think I'm okay with the package being removed from bookworm if we
can't find a quick fix here. The release date is just too close. We can
always fix this in a point release or get a backport going.

Interestingly, it's not marked as autoremoval here though:

https://tracker.debian.org/pkg/markdown-toc-el

Alternatively, I wonder if there's a way to make a simpler module that
would defer the TOC generation to an external command...

Is there something out there that takes a markdown doc as input and
outputs a TOC?

Cheers,

a.

-- 
Power is always dangerous.
Power attracts the worst and corrupts the best.
- Edward Abbey

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

[Bob Friesenhahn]

On Mon, 5 Jun 2023, Beauregard,Christophe (ECCC) wrote:

FWIW, I think I may have figured out what's happening. It's probably 
something to note in the http://www.graphicsmagick.org/OpenMP.html 
documentation.


In a nutshell, my understanding is that libgomp keeps track of its 
thread pool in thread local storage. When that thread local storage 
happens to be in the main process, all is well, everything works 
fine, etc. When that thread local storage is in a transient pthread 
(and, apparently, you're running on a certain class memory/CPU 
configuration) and your transient thread terminates, that thread 
local storage doesn't (always) get cleaned up.


This is very unfortunate and seems like a serious bug.

I suspect this isn't a particularly desirable situation, as 
GraphicsMagick appears to have put at least some effort into making 
the API thread-safe.


Considerable effort has been put into making the API as thread-safe as 
possible, but invoking OpenMP code from a POSIX thread (or other sort 
of thread) has not been significantly tested.


It would be good to write a bug report against gomp (it seems to still 
be a GCC product) so that there is hope to get this fixed, or be 
informed of a work-around.


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#1037042: graphicsmagick: GetImageDepth has a thread arena and memory leak

[Beauregard,Christophe (ECCC)]

FWIW, I think I may have figured out what's happening. It's probably something 
to note in the http://www.graphicsmagick.org/OpenMP.html documentation.

In a nutshell, my understanding is that libgomp keeps track of its thread pool 
in thread local storage. When that thread local storage happens to be in the 
main process, all is well, everything works fine, etc. When that thread local 
storage is in a transient pthread (and, apparently, you're running on a certain 
class memory/CPU configuration) and your transient thread terminates, that 
thread local storage doesn't (always) get cleaned up.

What this means in practice is making GM API calls from within a pthread can 
result in undefined behaviour when an API triggers OpenMP calls.

I suspect this isn't a particularly desirable situation, as GraphicsMagick 
appears to have put at least some effort into making the API thread-safe.

It likely means that even my mallopt(M_ARENA_MAX,n) fix is still not right, and 
the only "safe" solution is to disable OpenMP completely in that particular 
application.

I'm going to keep looking for a better workaround/mitigation. It would be ideal 
if there was a mechanism to keep the thread pool in the main process and still 
have it used from the subthread.


From: Beauregard,Christophe (ECCC) 
Sent: Monday, June 5, 2023 09:20
To: László Böszörményi (GCS) ; Bob Friesenhahn 
; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak



Never mind, you can close this. I've managed to reproduce the leak without GM:

/*
 * gcc -o gomparena gomparena.c -fopenmp
 */
#include 
#include 
#include 
#include 
#include 

static void* go_omp(void* arg) {
  const int m = 1024;
  double* a = alloca(m*sizeof(double));

  #pragma omp parallel for
  for( int n = 0; n < m; n ++ ) {
a[n] = n*n;
  }
  return NULL;
}

int main ( int argc, char **argv )
{
  int cycles = 10;

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

/* pthread_detach(thread_id); also shows the problem */
pthread_join(thread_id, NULL);
#else
/* this code path doesn't have a thread arena leak */
go_omp(NULL);
#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);
  }

  return 0;
}


From: Beauregard,Christophe (ECCC) 
Sent: Monday, June 5, 2023 08:58
To: László Böszörményi (GCS) ; Bob Friesenhahn 
; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak

>Do you think it might be a problem with another system component, a
GCC optimization or this is fixed meanwhile?

I'm not sure. It took me most of a week to even properly isolate the problem 
and find a repeatable test case on that one machine, and even then I feel like 
it's still a moving target.

I've done more poking and it's not 100% exclusive to GetImageDepth(). In fact, 
I'm seeing the problem now if I comment out the call to GetImageDepth() (but in 
my original application, ReadImage() without GetImageDepth() in another code 
path isn't enough to trigger the bug).

My working theory is something about how GM uses the OpenMP/libgomp API is 
tickling a bug in a code path that's only seen with certain CPU/memory configs.

The questions I can't answer are (a) is there possibly something 
incomplete/incorrect in how GM uses OpenMP which could lead to this sort of 
bug? and (b) just how deep does this rabbit hole go (glibc? kernel?)?

I'm starting to think that I might need to peel off a machine from the 
development cluster and investigate whether I can reproduce the error in a 
container, at which point I can play around with different configurations of 
libraries, compilers, etc.

c.

From: László Böszörményi (GCS) 
Sent: Sunday, June 4, 2023 06:25
To: Bob Friesenhahn ; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Cc: Beauregard,Christophe (ECCC) 
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak

[You don't often get email from g...@debian.org. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

Hi,

On Sat, Jun 3, 2023 at 8:30 PM Bob Friesenhahn
 wrote:
> I am definitely able to confirm that memory consumption builds due to
> invoking GetImageDepth() via a POSIX thread.  The rate that it builds
> 

Bug#1037127: exim4-config: Example Dovecot authenticator for Exim allows plaintext non TLS AUTH by default

[Dominic Preston]

Package: exim4-config
Version: 4.94.2-7
Severity: normal
X-Debbugs-Cc: lzq...@gmail.com

In Debian unstable exim4.conf.template, the example authenticator for
Dovecot, dovecot_plain_server, does not enforce TLS security for plaintext
authentication by default.

The Exim config should be changed to only advertise AUTH if the connection
is encrypted, in line with the other plain text authenticators, by adding
the final three lines below:

# dovecot_plain_server:
#   driver = dovecot
#   public_name = PLAIN
#   server_socket = /var/spool/exim4/dovecot.auth-client
#   server_set_id = $auth1
#   .ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS
#   server_advertise_condition = ${if eq{$tls_in_cipher}{}{}{*}}
#   .endif

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

[Beauregard,Christophe (ECCC)]

Never mind, you can close this. I've managed to reproduce the leak without GM:

/*
 * gcc -o gomparena gomparena.c -fopenmp
 */
#include 
#include 
#include 
#include 
#include 

static void* go_omp(void* arg) {
  const int m = 1024;
  double* a = alloca(m*sizeof(double));

  #pragma omp parallel for
  for( int n = 0; n < m; n ++ ) {
a[n] = n*n;
  }
  return NULL;
}

int main ( int argc, char **argv )
{
  int cycles = 10;

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

/* pthread_detach(thread_id); also shows the problem */
pthread_join(thread_id, NULL);
#else
/* this code path doesn't have a thread arena leak */
go_omp(NULL);
#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);
  }

  return 0;
}


From: Beauregard,Christophe (ECCC) 
Sent: Monday, June 5, 2023 08:58
To: László Böszörményi (GCS) ; Bob Friesenhahn 
; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak

>Do you think it might be a problem with another system component, a
GCC optimization or this is fixed meanwhile?

I'm not sure. It took me most of a week to even properly isolate the problem 
and find a repeatable test case on that one machine, and even then I feel like 
it's still a moving target.

I've done more poking and it's not 100% exclusive to GetImageDepth(). In fact, 
I'm seeing the problem now if I comment out the call to GetImageDepth() (but in 
my original application, ReadImage() without GetImageDepth() in another code 
path isn't enough to trigger the bug).

My working theory is something about how GM uses the OpenMP/libgomp API is 
tickling a bug in a code path that's only seen with certain CPU/memory configs.

The questions I can't answer are (a) is there possibly something 
incomplete/incorrect in how GM uses OpenMP which could lead to this sort of 
bug? and (b) just how deep does this rabbit hole go (glibc? kernel?)?

I'm starting to think that I might need to peel off a machine from the 
development cluster and investigate whether I can reproduce the error in a 
container, at which point I can play around with different configurations of 
libraries, compilers, etc.

c.

From: László Böszörményi (GCS) 
Sent: Sunday, June 4, 2023 06:25
To: Bob Friesenhahn ; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Cc: Beauregard,Christophe (ECCC) 
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak

[You don't often get email from g...@debian.org. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

Hi,

On Sat, Jun 3, 2023 at 8:30 PM Bob Friesenhahn
 wrote:
> I am definitely able to confirm that memory consumption builds due to
> invoking GetImageDepth() via a POSIX thread.  The rate that it builds
> is image sensitive since some images cause GetImageDepth() to perform
> more OpenMP loops.
 Unfortunately I can not reproduce. My processor is an Intel K variant
CPU, six cores and twelve threads, 64 Gb of RAM.
GM is 1.3.40 with two security fixes backported, compiled with GCC
v12.2.0. Tried with three PNG images, all memory consumption is static
from the beginning. Do I need some special case of PNG files to
experience this issue?

> My own testing is under Ubuntu 20.04 using GCC 10.
 Do you think it might be a problem with another system component, a
GCC optimization or this is fixed meanwhile? At least I do wonder why
this issue is CPU / machine dependent.

Regards,
Laszlo/GCS

Bug#1037126: ansible-core: Patch to fix URI Module find json sub type

[Bernhard Turmann]

Source: ansible-core
Source-Version: 2.14.3-1
Severity: important
Tags: fixed-upstream, patch, upstream


Dear Maintainer,
the attached patch applied in upstream commit [0] will fix ansible-core 
2.14.3-1 in Debian 12 Bookworm having an issue with the URI module 
recognizing JSON with some API endpoints correctly.


I am using this module in many tasks with the CEPH Dashboard API and 
confirm the patch is fixing it successfully. Without the patch, all 
these tasks are failing after installing a fresh Debian Bookworm.


Note:
The ansible version in Bullseye was working fine in this regard.

Upstream has an open PR [1] against stable-2.14, but not merged yet.

I would have opened a Merge Request on Salsa, but I just registered and 
waiting for approval.


[0] 
https://github.com/ansible/ansible/commit/0c7361d9acf7c8966a09f67de2a8679ef86fd856


[1] https://github.com/ansible/ansible/pull/80870

With Best Regards
Berni--- /usr/lib/python3/dist-packages/ansible/modules/uri.py	2023-03-01 21:06:21.0 +0100
+++ /tmp/uri.py	2023-06-03 16:51:49.224330090 +0200
@@ -699,7 +699,14 @@
 sub_type = 'octet-stream'
 content_encoding = 'utf-8'

-maybe_json = content_type and sub_type.lower() in JSON_CANDIDATES
+if sub_type and '+' in sub_type:
+# https://www.rfc-editor.org/rfc/rfc6839#section-3.1
+sub_type_suffix = sub_type.partition('+')[2]
+maybe_json = content_type and sub_type_suffix.lower() in JSON_CANDIDATES
+elif sub_type:
+maybe_json = content_type and sub_type.lower() in JSON_CANDIDATES
+else:
+maybe_json = False
 maybe_output = maybe_json or return_content or info['status'] not in status_code

 if maybe_output:

Bug#1037125: ganglia-monitor: Ganglia 3.7.2 (Debian Bullseye) doesn't find modules

[Steffen Grunewald]

Package: ganglia-monitor
Version: 3.7.2-4
Severity: normal

Dear Maintainer,

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

I upgraded from Buster (ganglia version 3.6.0) to Bullseye (3.7.2), resulting
in

apt-get install ganglia-monitor
service ganglia-monitor restart

I could no longer get any useful reports to the gmetad server. While the gmond
was running, I eventually found several lines of the type 

gmond[3101722]: Cannot load /usr/lib/ganglia/modcpu.so metric module: 
/usr/lib/ganglia/modcpu.so: cannot open shared object file: No such file or 
directory

in the syslog.

Ganglia's gmond used to find its modules before, but no longer does.
This is not related to gmond.conf (which has been changed to reflect the right
interface, and mute mode).


Closer inspection of the package itself and the related ones showed that
the modules are now in a multiarch subdirectory, /usr/lib/*/ganglia - while
gmond apparently doesn't know about that.
Adding a symlink ganglia -> */ganglia in /usr/lib fixes the issue.

I suspect that versions 3.6.0 had no multiarch support / a lower compat level.

I cannot test at the moment whether bookworm is also affected.

Thanks for your consideration.


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

Kernel: Linux 5.10.0-21-amd64 (SMP w/32 CPU threads)
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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ganglia-monitor depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libapr1  1.7.0-6+deb11u2
ii  libc62.31-13+deb11u5
ii  libconfuse2  3.3-2+deb11u1
ii  libganglia1  3.7.2-4
ii  libpcre3 2:8.39-13
ii  libtirpc31.3.1-1+deb11u1
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

ganglia-monitor recommends no packages.

ganglia-monitor suggests no packages.

-- Configuration Files:
/etc/ganglia/gmond.conf changed [not included]

-- no debconf information

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

[Beauregard,Christophe (ECCC)]

>Do you think it might be a problem with another system component, a
GCC optimization or this is fixed meanwhile?

I'm not sure. It took me most of a week to even properly isolate the problem 
and find a repeatable test case on that one machine, and even then I feel like 
it's still a moving target.

I've done more poking and it's not 100% exclusive to GetImageDepth(). In fact, 
I'm seeing the problem now if I comment out the call to GetImageDepth() (but in 
my original application, ReadImage() without GetImageDepth() in another code 
path isn't enough to trigger the bug).

My working theory is something about how GM uses the OpenMP/libgomp API is 
tickling a bug in a code path that's only seen with certain CPU/memory configs.

The questions I can't answer are (a) is there possibly something 
incomplete/incorrect in how GM uses OpenMP which could lead to this sort of 
bug? and (b) just how deep does this rabbit hole go (glibc? kernel?)?

I'm starting to think that I might need to peel off a machine from the 
development cluster and investigate whether I can reproduce the error in a 
container, at which point I can play around with different configurations of 
libraries, compilers, etc.

c.

From: László Böszörményi (GCS) 
Sent: Sunday, June 4, 2023 06:25
To: Bob Friesenhahn ; 1037...@bugs.debian.org 
<1037...@bugs.debian.org>
Cc: Beauregard,Christophe (ECCC) 
Subject: Re: Bug#1037042: graphicsmagick: GetImageDepth has a thread arena and 
memory leak

[You don't often get email from g...@debian.org. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

Hi,

On Sat, Jun 3, 2023 at 8:30 PM Bob Friesenhahn
 wrote:
> I am definitely able to confirm that memory consumption builds due to
> invoking GetImageDepth() via a POSIX thread.  The rate that it builds
> is image sensitive since some images cause GetImageDepth() to perform
> more OpenMP loops.
 Unfortunately I can not reproduce. My processor is an Intel K variant
CPU, six cores and twelve threads, 64 Gb of RAM.
GM is 1.3.40 with two security fixes backported, compiled with GCC
v12.2.0. Tried with three PNG images, all memory consumption is static
from the beginning. Do I need some special case of PNG files to
experience this issue?

> My own testing is under Ubuntu 20.04 using GCC 10.
 Do you think it might be a problem with another system component, a
GCC optimization or this is fixed meanwhile? At least I do wonder why
this issue is CPU / machine dependent.

Regards,
Laszlo/GCS

Bug#1037119: Acknowledgement (Fix rootlesskit with nss when subuids are defined for both the user name and the user id)

[Philipp Huebner]

tags 1037119 + patch
thanks

The upstream pull request that fixes this issue is
https://github.com/rootless-containers/rootlesskit/pull/369,

the actual commit is 
https://github.com/rootless-containers/rootlesskit/commit/15e24157f875dcf56e9532da755fef0ae279


Best wishes
Philipp

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Helmut Grohne]

On Sun, Jun 04, 2023 at 02:56:59PM +0100, Simon McVittie wrote:
> I think one way or another, if anyone is going to set a package-level
> dependency on systemd-tmpfiles, the first (preferred) dependency needs to
> be on either a concrete provider (systemd or systemd-tmpfiles-standalone
> in this case), or a default-systemd-tmpfiles virtual package
> that only has one provider per architecture (which is the way
> {default-,}dbus-{system,session}-bus are handled). Otherwise, you
> can get a non-deterministic choice of default implementation, which
> seems strictly worse than either depending on systemd or depending on
> systemd-tmpfiles-standalone - if you're unlucky, it can have all the
> disadvantages of either one of those.

Thank you for the elaborate writeup. There is little to add to what you
write except for one minor aspect.

>   - actual result: apt's heuristic might have difficulty realising that
> it needs to do that

I think we should be able to guide apt here. I recently had to look into
Replaces and in that process I also had to re-read policy section 7.6.2.
It details the "other" use of Replaces to guide a package manager (e.g.
apt) for changing implementations of an interface - which is exactly
what we are talking about here. In essence, it says that we should do:

Provides: systemd-tmpfiles
Conflicts: systemd-tmpfiles
Replaces: systemd-tmpfiles

And systemd-standalone-tmpfiles does that. :) But systemd does not. :(
systemd misses out on Conflicts and Replaces. I guess (but have not
verified) that once these are added, apt would be happier to "upgrade"
systemd-standalone-tmpfiles to systemd when needed.

I've also experimented with a minimal chroot, installed the standalone
tools and the asked apt to install libbiometric0 (which happens to have
a dependency on systemd) and apt was quite happy with removing the
standalone variants. This is still missing the consumers of the provided
facilities though, so it might not be representative.

Is there any concrete evidence of apt having difficulties in a real
situation? Or maybe a constructed example demonstrating this? Thanks for
being cautious, but I'd also like to understand whether this is
hypothetical or real.

Helmut

Bug#1029555: lintian: license-problem-font-adobe-copyrighted-fragment-no-credit false positive

[James Addison]

Package: lintian
Followup-For: Bug #1029555
X-Debbugs-Cc: rol...@debian.org

Dear Maintainer and Roland,

Worth noting: there are two programs in the relevant Adobe reference manual[1],
appendix three[2], and both programs are, I think, _intended_ to be available
under open source licensing.  The two programs collectively define four
subroutines.

So far Debian's lintian checks have looked for the smaller program that relates
to type hinting (as this is frequently useful for Type1 fonts).  The other
program relates to a technology called 'Flex' (that I don't know much about).

The published open source code[3] for what appears to be the Flex-related
program differs from the originally-published version in one statement that
looks significant (note: it _also_ differs in a few non-computationally
significant ways*, but those seem like they could be a result of automated
transformation, such as during re-reading of the code from storage prior to
reproduction for open source distribution).

The difference is that the code from the original publication closes with a
PostScript 'noaccess'[4] directive, but this is missing from the open sourced
version.

>From a codesearch, Debian does not include the 'noaccess' version anywhere;
only the open source version of the code is in use.  I'll report the
discrepancy to the upstream repository.

I'm working on a patch / merge request to update the lintian check to detect
other, non-open source code from the publication instead, as suggested.  There
is an example (non-appendix) program listing that could be relevant, although
also seems relatively unlikely to be copied widely.

Thanks,
James

[ * differences appear to be: style differences in the copyright header
comment, two missing comment lines, whitespace/newline differences, and
difference in representation of fractional numbers using scientific
notation (e.g. 1e-05 vs .1), and differences in whether the leading
zero in a decimal representation is included or not ]

[1] - https://adobe-type-tools.github.io/font-tech-notes/pdfs/T1_SPEC.pdf

[2] - 
https://adobe-type-tools.github.io/font-tech-notes/pdfs/T1_SPEC.pdf#page=97

[3] - 
https://github.com/adobe-type-tools/afdko/blob/2bf85cf44a64148353b24db17e0cc41ede5493b1/FDK/Tools/Programs/public/lib/source/t1write/t1write_flexothers.h

[4] - https://en.wikipedia.org/wiki/PostScript_fonts#Printer_Font_ASCII

Bug#1037123: calamares-settings-debian: 'Minimal HD space required' too small for some live images

[Jonathan Carter]

I agree that 10GB is way too small, will bump it for the point release 
and also take some space in to consideration for upgrades.

Bug#1037121: release-notes: Salt has been dropped

[Justin B Rye]

Elimar Riesebieter wrote:
> Please mention that in Bookworm the salt-stack has been removed.

Does this mean we need something in issues.dbk like this?

  

  salt stack dropped


  Due to several release-critical bugs and a short upstream support
  lifecycle, the salt remote execution manager stack
  has been dropped from Debian stable starting with bookworm. Users
  who cannot track unstable should switch to an alternative.
  

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Luca Boccassi]

On Mon, 5 Jun 2023 09:53:39 +0100 Simon McVittie 
wrote:
> On Mon, 05 Jun 2023 at 01:36:25 +0100, Luca Boccassi wrote:
> > If it is useful, adding a "default-tmpfiles" or so virtual package
> > would be fine by me - but with the kfreebsd port being retired
soon,
> > and i386 (for hurd) going the way of the dodo, I'm not sure it
would
> > be very useful? I don't think it would be a problem to add it, if
it
> > turns out to be of use though.
> 
> What this would look like, in src:systemd:
> 
> Package: systemd
> Provides: default-systemd-tmpfiles, systemd-tmpfiles
> 
> Package: systemd-standalone-tmpfiles
> Provides: systemd-tmpfiles
> 
> (or maybe the other way round, depending what conclusion we come to
on
> the choice between (1.) and (2.)), and then in dependent packages:
> 
> Package: foo-service
> Depends: default-systemd-tmpfiles | systemd-tmpfiles
> 
> The benefits of that over having foo-service depend directly on
> "systemd | systemd-tmpfiles" or
> "systemd-standalone-tmpfiles | systemd-tmpfiles" are fairly minor,
but the
> cost is also fairly minor; and if we want this, we should set it up
> *before* lots of packages start adding a dependency on the -tmpfiles
or
> -sysusers interfaces. The benefits I see are:
> 
> - if we find out that the dependency we first added is a practical
problem
>   for whatever reason, we can swap the default with a src:systemd
upload,
>   without needing multiple maintainers to touch all the dependent
packages;
> 
> - if we get a useful non-Linux port (admittedly this looks
increasingly
>   unlikely) which cannot compile src:systemd, then their
reimplementation
>   of these interfaces can have Provides: default-systemd-tmpfiles on
that
>   architecture, without affecting Linux architectures
>   (the same way dbus-x11 Provides default-dbus-session-bus on non-
Linux
>   ports, even though it's dbus-user-session that Provides the virtual
>   package on Linux)

Sure, that sounds reasonable and simple enough to do, no objection from
me.

-- 
Kind regards,
Luca Boccassi


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

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Luca Boccassi]

On Mon, 5 Jun 2023 10:11:46 +0100 Simon McVittie 
wrote:
> On Mon, 05 Jun 2023 at 01:36:25 +0100, Luca Boccassi wrote:
> > Our time is worth more than 80K or whatever it is of disk space in
a
> > throw-away container.
> 
> I agree that the systemd maintainers' time is a limited resource that
we
> should not waste, but that size estimate is off by a couple of orders
of
> magnitude. On amd64, aptitude tells me systemd-standalone-tmpfiles
and
> -sysusers are about 700K of Uncompressed Size between them, while the
> full systemd and libsystemd-shared packages add up to about 15M. For
> genuinely throwaway containers, yes, it's not worth optimizing this,
> but for containers that will be archived in a registry and/or kept
> running longer-term, that seems like enough that maintainers of
Docker
> containers, etc. will want to use the standalone binaries if they are
> sufficient for the container's needs.
> 
> (This is ignoring any extra library dependencies that might be
required by
> systemd and libsystemd-shared but unnecessary for the standalone
binaries;
> if there are any, then obviously the effective size delta increases.)

Sure, but again, those special cases that really care about that
particular angle can simply adjust their dependencies accordingly,
there's nothing stopping them from doing so. It does not need to be the
default.

-- 
Kind regards,
Luca Boccassi


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

Bug#1037123: calamares-settings-debian: 'Minimal HD space required' too small for some live images

[Roland Clobus]

Package: calamares-settings-debian
Version: 12.0.9-1
Severity: minor

Hello maintainers of calamares-settings-debian,

I'm currently preparing a test on openQA for the Calamares installer for each
of the live images.

In my first attempts to write such a test, I've found that for the larger live
images (GNOME and KDE) the minimal required HD space of 10 GiB (which is tested
when Calamares is started) is not enough.

I've tested a bit more extensively for KDE (with 4GB memory):
When booting with BIOS: a HD of 11 GB is required
When booting with Secure UEFI: a HD of 12 GB is required

The current code requires 10GB (irrespective of the size of the live image).
I would assume, that for the smaller live images 10GB will be enough.

Should the limit be raised? (This is more a question regarding the purpose of
the check)
- If the limit is low (e.g. 10GB), for some images the installer will issue an
error at the end of the installation (after which the whole HD has been
erased), leading to an unbootable system.
- If the limit is too high, sometime the Calamares installer would refuse to
run, even though the installation could have been successful.

With kind regards,
Roland Clobus


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

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

Versions of packages calamares-settings-debian depends on:
pn  calamares
ii  cryptsetup   2:2.6.1-4~deb12u1
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  keyutils 1.6.3-2
ii  pkexec   122-3
ii  qml-module-qtquick-window2   5.15.8+dfsg-3
ii  qml-module-qtquick2  5.15.8+dfsg-3

calamares-settings-debian recommends no packages.

calamares-settings-debian suggests no packages.

Bug#1037122: libpam-ssh-agent-auth: Sudo with ECDSA key segfaults

[Marc Fite]

Package: libpam-ssh-agent-auth
Version: 0.10.3-3+b1
Severity: normal
X-Debbugs-Cc: mf...@sabarca.cat

Dear Maintainer,

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

   * What led up to the situation?

Login with ssh -A and trying to sudo with a yubikey:


Jun  5 12:09:39 vls15775 sudo[3083994]: pam_ssh_agent_auth: 
secure_filename: terminating check at '/home/mfite'
Jun  5 12:09:39 vls15775 sudo[3083994]: pam_ssh_agent_auth: matching 
key found: file/command /home/mfite/.ssh/authorized_keys, line 1
Jun  5 12:09:39 vls15775 sudo[3083994]: pam_ssh_agent_auth: Found 
matching ECDSA key: f5:4f:d7:06:73:d4:e9:be:72:60:54:e4:fe:59:70:0e


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

sudo su -   

# cat /etc/pam.d/sudo
#%PAM-1.0
authsufficient  pam_ssh_agent_auth.so 
file=~/.ssh/authorized_keys debug

@include common-auth
@include common-account
@include common-session-noninteractive

   * What was the outcome of this action?


Segfault of sudo:

[16590023.461986] sudo[3083994]: segfault at 8 ip 7f6a8ae4f770 sp 
7ffc3696af78 error 4 in libcrypto.so.1.1[7f6a8ae04000+1a7000]

   * What outcome did you expect instead?


Sudo su - without segfault

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


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

Kernel: Linux 5.10.0-19-amd64 (SMP w/2 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 libpam-ssh-agent-auth depends on:
ii  libc6  2.31-13+deb11u6
ii  libpam0g   1.4.0-9+deb11u1
ii  libssl1.1  1.1.1n-0+deb11u5

libpam-ssh-agent-auth recommends no packages.

libpam-ssh-agent-auth suggests no packages.

-- no debconf information

Bug#1037121: release-notes: Salt has been dropped

[Elimar Riesebieter]

Package: release-notes
Severity: normal


Please mention that in Bookworm the salt-stack has been removed.

Bug#1037120: Mute output from `git gc`

[Christoph Berg]

Package: etckeeper
Version: 1.18.20-1
Severity: normal

Hi,

I keep getting cron mails from etckeeper:

Subject: Anacron job 'cron.daily' on maxwell

/etc/cron.daily/etckeeper:
Die Datenbank des Repositories wird für eine optimale Performance im
Hintergrund komprimiert.
Siehe "git help gc" für manuelles Aufräumen.


I frankly do not care about that, please mute that output.

At least `git gc` has a `--quiet` parameter, I'd guess there's ways to
make that happen for other operations as well.

Thanks.


-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages etckeeper depends on:
ii  debconf [debconf-2.0]  1.5.82
ii  git1:2.39.2-1.1
ii  mercurial  6.3.2-1

Versions of packages etckeeper recommends:
ii  cron [cron-daemon]  3.0pl1-162

Versions of packages etckeeper suggests:
ii  sudo  1.9.13p3-1

-- debconf information:
  etckeeper/purge: true

Christoph

Bug#907495: please ship the x11idle binary

[Michal Politowski]

Dnia Sat,  3 Jun 2023 23:06:00 -0400, Nicholas D Steeves napisał(a):
> Control: tag -1 pending
> 
> Sébastien Delafond  writes:
> 
> > On 27/03 09:26, Michal Politowski wrote:
> >> Actually I think there is no need to compile x11idle.  As the footnote
> >> https://orgmode.org/manual/Resolving-idle-time.html#DOCF82 says,
> >> Debian already provides xprintidle, which seems to work for me.
> >> 
> >> Maybe elpa-org could just suggest that package and change the default
> >> for org-clock-x11idle-program-name?
> >
> > Hi Michal,
> >
> > that's a good point, and sounds like an elegant way to solve this in
> > Debian. I'm pretty busy these days, so I won't have time to work on that
> > right now, but I'd happily accept a patch in the meantime :)
> >
> 
> Pending upload to experimental:
> 
> https://salsa.debian.org/emacsen-team/org-mode/-/commit/67d33aa4f2a26b8449f0f2ecb4404cdb2ad969a1

Nice. The relevant commit is actually
https://salsa.debian.org/emacsen-team/org-mode/-/commit/f484de742a55280a2e92e17f93fd21057e6b0705

-- 
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Simon McVittie]

On Mon, 05 Jun 2023 at 01:36:25 +0100, Luca Boccassi wrote:
> On Sun, 4 Jun 2023 at 14:56, Simon McVittie  wrote:
> > So I think the only realistic options for packages that hard-require
> > this functionality (not all do) are:
> >
> > 1. Depends: systemd | systemd-tmpfiles
> > 2. Depends: systemd-tmpfiles-standalone | systemd-tmpfiles
> > 3. Depends: default-systemd-tmpfiles | systemd-tmpfiles

In case it's not obvious, (2.) should say
systemd-standalone-tmpfiles | systemd-tmpfiles (and the same everywhere
else that I mentioned systemd-tmpfiles-standalone).

> Our time is worth more than 80K or whatever it is of disk space in a
> throw-away container.

I agree that the systemd maintainers' time is a limited resource that we
should not waste, but that size estimate is off by a couple of orders of
magnitude. On amd64, aptitude tells me systemd-standalone-tmpfiles and
-sysusers are about 700K of Uncompressed Size between them, while the
full systemd and libsystemd-shared packages add up to about 15M. For
genuinely throwaway containers, yes, it's not worth optimizing this,
but for containers that will be archived in a registry and/or kept
running longer-term, that seems like enough that maintainers of Docker
containers, etc. will want to use the standalone binaries if they are
sufficient for the container's needs.

(This is ignoring any extra library dependencies that might be required by
systemd and libsystemd-shared but unnecessary for the standalone binaries;
if there are any, then obviously the effective size delta increases.)

smcv

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Simon McVittie]

On Mon, 05 Jun 2023 at 01:36:25 +0100, Luca Boccassi wrote:
> If it is useful, adding a "default-tmpfiles" or so virtual package
> would be fine by me - but with the kfreebsd port being retired soon,
> and i386 (for hurd) going the way of the dodo, I'm not sure it would
> be very useful? I don't think it would be a problem to add it, if it
> turns out to be of use though.

What this would look like, in src:systemd:

Package: systemd
Provides: default-systemd-tmpfiles, systemd-tmpfiles

Package: systemd-standalone-tmpfiles
Provides: systemd-tmpfiles

(or maybe the other way round, depending what conclusion we come to on
the choice between (1.) and (2.)), and then in dependent packages:

Package: foo-service
Depends: default-systemd-tmpfiles | systemd-tmpfiles

The benefits of that over having foo-service depend directly on
"systemd | systemd-tmpfiles" or
"systemd-standalone-tmpfiles | systemd-tmpfiles" are fairly minor, but the
cost is also fairly minor; and if we want this, we should set it up
*before* lots of packages start adding a dependency on the -tmpfiles or
-sysusers interfaces. The benefits I see are:

- if we find out that the dependency we first added is a practical problem
  for whatever reason, we can swap the default with a src:systemd upload,
  without needing multiple maintainers to touch all the dependent packages;

- if we get a useful non-Linux port (admittedly this looks increasingly
  unlikely) which cannot compile src:systemd, then their reimplementation
  of these interfaces can have Provides: default-systemd-tmpfiles on that
  architecture, without affecting Linux architectures
  (the same way dbus-x11 Provides default-dbus-session-bus on non-Linux
  ports, even though it's dbus-user-session that Provides the virtual
  package on Linux)

smcv

Bug#1037119: Fix rootlesskit with nss when subuids are defined for both the user name and the user id

[Philipp Huebner]

Package: rootlesskit
Version: 1.1.0-1
Severity: important
Tags: upstream

In LDAP-based environments both "getsubids myusername" and "getsubids 1234" 
(where "id myusername" equals to "1234")
can return exactly the same subuid ranges. This happens when one of /etc/subuid 
or nss returns mappings for both the
user id and the user name. Both "newgidmap" and "newuidmap" fail when the 
parameters contain duplicate ranges.
This in turn makes rootlesskit fail.

Release 1.1.1 of rootlesskit fixes this issue by eliminating duplicate subuid 
ranges before calling "newgidmap" and
"newuidmap".

Please fix this bug for Bookworm.

Best wishes
--
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-

Bug#1037118: installation-reports: booting to d-i does not complete on Samsung Galaxy Book (arm64 laptop)

[Jonathan Carter]

Package: installation-reports
Severity: normal

Boot method: USB
Image version: 
https://cdimage.debian.org/cdimage/bookworm_di_rc4/arm64/iso-cd/debian-bookworm-DI-rc4-arm64-netinst.iso
Date: 2023-06-05

Machine: Samsung Galaxy Book Go 5G
Partitions: n/a

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]

GRUB starts fine, when selecting either Install or Graphical Install,
booting halts with just a static "_" on the display.

I'll try to troubleshoot this a bit further and attach more info to the bug, 
this is
a student's laptop so I'm not sure how long I'll have access to it.

Bug#1037117: ITP: libbadger-perl -- Badger application programming toolkit

[Andrew Ruthven]

Package: wnpp
Owner: Andrew Ruthven 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libbadger-perl
  Version : 0.16
  Upstream Author : Andy Wardley 
* URL : https://metacpan.org/release/Badger
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Badger application programming toolkit

The Badger toolkit is a collection of Perl modules designed to simplify
the process of building object-oriented Perl applications. It provides a
set of foundation classes upon which you can quickly build robust and
reliable systems that are simple, skimpy and scalable.

The package will be maintained under the umbrella of the Debian Perl Group.

This package is being added to Debian as it is an indirect build dependency
for CSS::Inliner which will be used by v5.0.4 of Request Tracker.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
-- 
Andrew Ruthven, Wellington, New Zealand
and...@etc.gen.nz |
Catalyst Cloud:   | This space intentionally left blank
 https://catalystcloud.nz |

Bug#1037116: Debian Edu bookworm not ready

[Holger Levsen]

package: release-notes
x-debbugs-cc: debian-...@lists.debian.org

hi,

maybe we should have a release notes entry stating that debian-edu bookworm
is not yet ready?!? :((

https://wiki.debian.org/DebianEdu/Status/Bookworm has the details what
needs doing.


-- 
cheers,
Holger

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

Stop saying that we are all in the same boat.
We’re all in the same storm. But we’re not all in the same boat.


signature.asc
Description: PGP signature

Bug#1037115: python3-rrdtool shifted by one step in the past

[BOURCHANIN BERTRAND]

Package: python3-rrdtool
Version: 1.7.2-3+b7

The python rrdtool output is shifted by one step (here 300 seconds) in the past 
comparing
to the original RRD maintainer version of rrdtool (Package: rrdtool, Version: 
1.7.2-3+b7)
from https://oss.oetiker.ch/rrdtool/

Sample of `rrdtool dump /var/local/mrtg/rrd/ROCKF/RockB/xxx.rrd'

 
6.814544e+001.1404103111e+03
 
6.319411e+001.3107397333e+03
 
6.939967e+001.377933e+03

Sample of 
rrdtool.fetch('/var/local/mrtg/rrd/ROCKF/RockB/xxx.rrd','MAX','1685943000')

(1685856600, 1685943300, 300),
('ds0', 'ds1'),
[ (6.3194111, 1310.73976),
  (6.9399666, 1377.93312),
  (6.385982274247492, 1407.4662690078037),
  ...
]

The python3-rrdtool is not very clear how to manage the first value with the 
timestamps
it returns 
(https://pythonhosted.org/rrdtool/usage.html#functions)
 but the number of steps
it gives (ie 290 values - not listed here -) matches the start and end values 
(here
1685856600 and 1685943300) by 290 increments indicating a first value of 
6.3194111
at 1685856600 timestamp (which is not what rrdtool returns).

Moreover, python3-rrdtool returns one or two records ahead (in the future) 
sometimes which
all are to a correct none value confirming the bug.

Best regards,

--

[1654843288242]
Bertrand Bourchanin
CISR - pôle ingénierie réseau
Mobile : 06 76 51 76 95
permanence du CISR : 04 72 44 79 99

Bug#733061: Bug#734435: notmuch-emacs: Emacs cannot load package notmuch

[Ben Finney]

Control: fixed -1 elpa-notmuch/0.37-1
Control: fixed -1 emacsen-common/3.0.5

On 03-Jun-2023, Nicholas D Steeves wrote:
> Ben Finney  writes:
> 
> > This still occurs for me with ‘notmuch-emacs’ 0.17-3, and
> > ‘emacsen-common’ 2.0.7.
> 
> It seems to me that this was fixed somewhere along the way. Would you
> please confirm this bug is fixed and/or go ahead and close it?

Yes, the behaviour no longer occurs when I install ‘elpa-notmuch’ version
0.37-1 with Emacs ‘emacsen-common’ version 3.0.5. I'm marking those
versions as fixing this bug.

Let's hear from the other reporters before deciding whether to close this
reports.

-- 
 \ “A politician is an animal which can sit on a fence and yet |
  `\  keep both ears to the ground.” —Henry L. Mencken |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#1037114: python3-opensnitch-ui: Desktop notifications should expire

[Petter Reinholdtsen]

Package: python3-opensnitch-ui
Version: 1.5.8.1-1

In KDE, when a opensnitch dialog timed out and a connection is blocked,
a notification show up in my lower right corner that the connection was
indeed blocked.  These notifications never expire, causing a machine
running over the weekend with Firefox running, to fill the right part of
screen with a lot of notifications.  I have to manually click away these
notifications to get rid of them.

Can the behaviour be changed to expire these popup notifications after a
while, for example 15 minutes?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1037113: Should not be in /usr/games

[Josh Triplett]

Package: sm
Version: 0.26-3
Severity: minor
X-Debbugs-Cc: j...@joshtriplett.org

sm is a useful utility for a wide variety of purposes. I don't think it
belongs in /usr/games. Please consider relocating it to /usr/bin.

Thank you for maintaining sm!

Bug#1037112: release-notes: Release notes paragraph from Debian Astro team

[Ole Streicher]

Package: release-notes
Severity: normal
X-Debbugs-Cc: debian-as...@lists.debian.org

Please add an Debian Astro section to the Bookworm release notes. The 
merge request is available in


https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/188

Thank you!

Best regards

Ole