Bug#993944: make: noguile profile is incomplete

[Helmut Grohne]

Control: tags -1 + patch

On Wed, Sep 08, 2021 at 01:32:13PM +0200, Stephen Kitt wrote:
> The patch in #892566 wasn't applied completely; the
> 
>   Build-Profiles: 
> 
> was left out in the make-guile package stanza. The result is that a
> noguile profile build doesn't build-depend on guile, which is fine,
> but it still builds a make-guile package which doesn't actually
> support guile.
> 
> Please add the missing line.

I'm attaching a patch to speed up the addition of the line and confirm
all that has been said.

Helmut
diff -u make-dfsg-4.3/debian/changelog make-dfsg-4.3/debian/changelog
--- make-dfsg-4.3/debian/changelog
+++ make-dfsg-4.3/debian/changelog
@@ -1,3 +1,10 @@
+make-dfsg (4.3-4.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Skip building make-guile given the noguile profile. (Closes: #993944)
+
+ -- Helmut Grohne   Wed, 31 May 2023 07:29:53 +0200
+
 make-dfsg (4.3-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u make-dfsg-4.3/debian/control make-dfsg-4.3/debian/control
--- make-dfsg-4.3/debian/control
+++ make-dfsg-4.3/debian/control
@@ -36,6 +36,7 @@
 Provides: make (= ${source:Version})
 Replaces: make
 Architecture: any
+Build-Profiles: 
 Multi-Arch: allowed
 Description: utility for directing compilation with guile support
  GNU Make is a utility which controls the generation of executables

Bug#1036891: texlive-binaries: Error "attempt to call method 'read' (a nil value)" makes lualatex unusable

[Salvatore Bonaccorso]

Hi Hilmar, hi Markus,

On Tue, May 30, 2023 at 11:32:24PM +0200, Preuße, Hilmar wrote:
> On 30.05.2023 20:37, Salvatore Bonaccorso wrote:
> 
> Hi Salvatore, hi Markus,
> 
> > No, buster is under LTS support which does not have point releases.
> > But as I understand this is a regression from DLA DLA-3427-1, so a
> > regression update might be worth to be issues for it, once there is a
> > fix known.
> > 
> Short question: the web page for the security issue [1] lists a few patches.
> I downloaded a few of them, but no one is matches to the
> CVE-2023-32700.patch in the texlive-bin_2018.20181218.49446-1+deb10u1 diff.
> Which patch did you use?

Source code patch is at https://tug.org/~mseven/luatex.html#patching
but it needs to be expanded as Markus explained, and update the
bytecode.

Just a suspect (and nothing more right now, have not digged deeper)
that there is in the older version of texlive-base something
incompatible with the popen change in buster. In fact diff'ing between
the versions in buster and bulleye,
texmf-dist/tex/luatex/luaotfload/luaotfload-database.lua drops the use
of the local iopopen, which is io.popen.

So (at least one) of the CTAN packages for luatex is causing an issue
(at least luaotfload).

So the security fix for texlive-bin, which I believe is correctly
implemented, causes a functional regression in src:texlive-base for
texlive-luatex, specificially for the luaotfload package? 

Can those changes be backported and a functional regression fix be
done in src:texlive-base or is that becoming too intrusive?

Regards,
Salvatore

Bug#987119: godot3: Name of .desktop file causes odd behavior in some DEs

[Petter Reinholdtsen]

> It is somewhat difficult to explain, but in any case, godot3 does not seem
> to behave as expected with these taskbars. Instead, once a project is opened
> in godot3, the icon in the taskbar appears to duplicate, such that the running
> instance of godot3 shows up separately from the pinned icon.

What make you believe this should be fixed in godot3 and not in the
implementation of these taskbars?

> It seems that the fix is to change the name of the .desktop file from
> "godot3.desktop" to just "godot.desktop"

Doing this would make it harder to introduce godot4 in parallel with
godot3.  As the former now is available from upstream, I guess it is
something to consider.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1031132: godot FTBFS on arm64, armel, ppc64el and s390x

[Petter Reinholdtsen]

Control: forwarded -1 https://github.com/godotengine/godot/issues/47344

A solution was provided in the upstream issue.  I am currently testing
this patch on arm64.

diff --git a/debian/rules b/debian/rules
index 51ceee03..bd0fe095 100755
--- a/debian/rules
+++ b/debian/rules
@@ -12,6 +13,15 @@ ifeq ($(DEB_HOST_ARCH),$(filter $(GCC_MINOR),armel riscv64))
export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic 
-Wl,--as-needed
 endif
 
+# The denoise module depends on OIDN which is x86_64 only (in the
+# vendored version).
+# Godot's own logic to disable it on other arches is a bit brittle
+# when it comes to cross-compiling currently.
+# See https://github.com/godotengine/godot/issues/47344
+ifneq ($(DEB_HOST_ARCH),$(filter $(GCC_MINOR),amd64 i386 armhf))
+   DISABLE_MODULES = module_denoise_enabled=no
+endif
+
 override_dh_clean:
dh_clean
scons -c
@@ -68,9 +78,9 @@ SCONS_OPTIONS = bits=$(DEB_HOST_ARCH_BITS) \
 
 override_dh_auto_build:
dh_auto_build
-   scons platform=server tools=yes target=release_debug $(SCONS_OPTIONS) 
-j $(NUMJOBS) CCFLAGS="$(CXXFLAGS)" LINKFLAGS="$(LDFLAGS)" CFLAGS="$(CFLAGS)"
-   scons platform=x11tools=no  target=release   $(SCONS_OPTIONS) 
-j $(NUMJOBS) CCFLAGS="$(CXXFLAGS)" LINKFLAGS="$(LDFLAGS)" CFLAGS="$(CFLAGS)"
-   scons platform=x11tools=yes target=release_debug $(SCONS_OPTIONS) 
-j $(NUMJOBS) CCFLAGS="$(CXXFLAGS)" LINKFLAGS="$(LDFLAGS)" CFLAGS="$(CFLAGS)"
+   scons platform=server tools=yes target=release_debug $(SCONS_OPTIONS) 
-j $(NUMJOBS) CCFLAGS="$(CXXFLAGS)" LINKFLAGS="$(LDFLAGS)" CFLAGS="$(CFLAGS)" 
$(DISABLE_MODULES)
+   scons platform=x11tools=no  target=release   $(SCONS_OPTIONS) 
-j $(NUMJOBS) CCFLAGS="$(CXXFLAGS)" LINKFLAGS="$(LDFLAGS)" CFLAGS="$(CFLAGS)" 
$(DISABLE_MODULES)
+   scons platform=x11tools=yes target=release_debug $(SCONS_OPTIONS) 
-j $(NUMJOBS) CCFLAGS="$(CXXFLAGS)" LINKFLAGS="$(LDFLAGS)" CFLAGS="$(CFLAGS)" 
$(DISABLE_MODULES)
 
 override_dh_auto_install:
echo "Installing binaries for $(BITS) bits architecture"
-- 
Happy hacking
Petter Reinholdtsen

Bug#1036963: Bug#1034065: sasl-xoauth2: FTBFS: ModuleNotFoundError: No module named 'distutils.core'

[Sebastiaan Couwenberg]

Control: reassign -1 src:argparse-manpage
Control: found -1 argparse-manpage/1.2.2-1
Control: tags -1 patch sid bookworm
Control: severity -1 important
Control: affects -1 src:sasl-xoauth2 src:osm2pgsql

On Tue, 30 May 2023 18:34:24 -0400 Daniel Kahn Gillmor wrote:

On Fri 2023-04-07 22:14:44 +0200, Andreas Beckmann wrote:
> sasl-xoauth2/experimental FTBFS on all architectures:
> https://buildd.debian.org/status/package.php?p=sasl-xoauth2=experimental
>
> ...
>debian/rules execute_after_dh_auto_build
> make[1]: Entering directory '/<>'
> mkdir -p completions manpages
> register-python-argcomplete --shell bash sasl-xoauth2-tool > 
completions/sasl-xoauth2-tool
> argparse-manpage --pyfile obj-x86_64-linux-gnu/scripts/sasl-xoauth2-tool 
--object parser \
>--author 'Tarick Bedeir' --author-email 'tar...@bedeir.com' --project-name 
sasl-xoauth2 \
>--url https://github.com/tarickb/sasl-xoauth2 --output 
manpages/sasl-xoauth2-tool.1
> Traceback (most recent call last):
>   File "/usr/bin/argparse-manpage", line 5, in 
> from build_manpages.cli import main
>   File "/usr/lib/python3/dist-packages/build_manpages/cli/__init__.py", line 5, in 

> from build_manpages.build_manpage import ManPageWriter, get_parser
>   File "/usr/lib/python3/dist-packages/build_manpages/build_manpage.py", line 10, 
in 
> from distutils.core import Command
> ModuleNotFoundError: No module named 'distutils.core'
> make[1]: *** [debian/rules:11: execute_after_dh_auto_build] Error 1
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:6: binary-arch] Error 2
> ...


I think this represents a missing dependency in
python3-argparse-manpage, which makes packages that build-depend on
python3-argparse-manpage to generate their manpages FTBFS.


distutils was removed from setuptools 60:


https://setuptools.pypa.io/en/latest/deprecated/distutils-legacy.html#prefer-setuptools

Upstream dealt with this in v4:


https://github.com/praiskup/argparse-manpage/commit/3e10dac5702915b9b92fdc686bad690c1b15bf61

The package is still at 1.2.2, quite a way behind to simply cherry-pick 
those changes.


I'm lowering the severity, because the package is not entirely unusable, 
the osm2psql package uses it during the build to generate a manpage for 
osm2pgsql-replication which still works because it uses selective imports:


 from build_manpages.manpage import Manpage
 from build_manpages.build_manpage import get_parser_from_file

Only the the build_manpage class is broken because it subclasses 
distutils.Command and raises DistutilsOptionError.


The attached patch replaces the distutils imports with those for 
setuptools, except the DistutilsOptionError exception which is replaced 
with plain Exception.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1diff -Nru argparse-manpage-1.2.2/debian/changelog 
argparse-manpage-1.2.2/debian/changelog
--- argparse-manpage-1.2.2/debian/changelog 2019-09-12 08:33:21.0 
+0200
+++ argparse-manpage-1.2.2/debian/changelog 2023-05-31 05:53:15.0 
+0200
@@ -1,3 +1,11 @@
+argparse-manpage (1.2.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to not use deprecated distutils module, removed in setuptools 60.
+(closes: #1034065)
+
+ -- Bas Couwenberg   Wed, 31 May 2023 05:53:15 +0200
+
 argparse-manpage (1.2.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru argparse-manpage-1.2.2/debian/control 
argparse-manpage-1.2.2/debian/control
--- argparse-manpage-1.2.2/debian/control   2019-09-12 08:24:48.0 
+0200
+++ argparse-manpage-1.2.2/debian/control   2023-05-31 05:51:44.0 
+0200
@@ -16,7 +16,7 @@
 
 Package: python3-argparse-manpage
 Architecture: all
-Depends: ${misc:Depends}, ${python3:Depends},
+Depends: ${misc:Depends}, ${python3:Depends}, python3-setuptools
 Description: Automatically build a manpage from argparse
  Generate a manual page in an automatic way from an ArgumentParser object,
  so that the manpage matches to the automatically generated --help output.
diff -Nru argparse-manpage-1.2.2/debian/patches/no-distutils.patch 
argparse-manpage-1.2.2/debian/patches/no-distutils.patch
--- argparse-manpage-1.2.2/debian/patches/no-distutils.patch1970-01-01 
01:00:00.0 +0100
+++ argparse-manpage-1.2.2/debian/patches/no-distutils.patch2023-05-31 
05:53:11.0 +0200
@@ -0,0 +1,74 @@
+Description: Don't use deprecated distutils module, removed in setuptools 60.
+Author: Bas Couwenberg 
+Bug-Debian: https://bugs.debian.org/1036963
+
+--- a/build_manpages/build_manpage.py
 b/build_manpages/build_manpage.py
+@@ -7,8 +7,7 @@ import datetime
+ import optparse
+ import argparse
+ 
+-from distutils.core import Command
+-from distutils.errors import DistutilsOptionError
++from setuptools import Command
+ 
+ from .manpage import Manpage
+ 
+@@ -216,9 +215,9 @@ class build_manpage(Command):
+ 
+ def 

Bug#1036955: RFS: trurl/0.7-1 -- command line tool for URL parsing and manipulation

[Paul Wise]

On Tue, 2023-05-30 at 21:41 +0200, Michael Ablassmeier wrote:

>  trurl (0.7-1) unstable; urgency=medium
>  .
>    * New upstream release.

Uploaded.

Upstream has added -Werror to the default CFLAGS. It isn't recommended
to do this in released software, because it means a lot more build
failures when compilers get updated in distros. Please consider sending
upstream a patch to move that to their CI scripts instead.

Most of the suggestions I listed in my first review still apply:

https://lists.debian.org/msgid-search/551f9af844ea1ebe0b814678c5560e42303d8299.ca...@debian.org

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1036965: ITP: libplack-middleware-prometheus-requesttimes-perl -- Perl module that records response times with a prometheus histogram

[mtj]

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

* Package name: libplack-middleware-prometheus-requesttimes-perl
  Version : 0.0001
  Upstream Author : Colin Newell 
* URL : 
https://metacpan.org/release/Plack-Middleware-Prometheus-RequestTimes
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module that records response times with a prometheus 
histogram

To setup a prometheus metrics app in your PSGI application, hook this
Plack::Middleware::Prometheus::RequestTimes middleware up with a histogram and
the metrics can report on your response times.

use strict;

use warnings;

use My::Website;

use Net::Prometheus;

use Net::Prometheus::ProcessCollector;

my $client = Net::Prometheus->new;

$client->register( Net::Prometheus::ProcessCollector->new(

prefix => "parent_process",

pid => getppid(),

) );

my $response_times = $client->new_histogram(

name => "response_times",

help => "Application response times",

);


--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1036648: zlib1g-dev: Missing manual pages for the functions

[Alejandro Colomar]

On 5/23/23 22:01, Mark Brown wrote:
> On Tue, May 23, 2023 at 09:57:42PM +0200, Alejandro Colomar wrote:
> 
>> I'm going to use zlib in the near future in my job, so I can write some
>> manual pages for the functions I use.  I'll keep upstream in the loop,
>> in case they want to pick the pages.  I will probably only write pages
>> for the functions I use, though, of course.
> 
> That'd be excellent!

Hi Mark!

I've already got one page written.  Since we're so close to the release of
Bookworm, I guess it's not allowed, not even if it's fixing a policy
violation, and is only documentation.

But maybe it would be interesting to backport (as a bugfix) the manual pages
once the release is made?

Here's the pull request to the upstream project, which I hope will go it
smoothly: .

Cheers,
Alex

-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035499: crowdsec-custom-bouncer: fails to install with --install-recommends: open /etc/crowdsec/config.yaml: no such file or directory

[Andreas Beckmann]

On 30/05/2023 23.59, Cyril Brulebois wrote:

My question is why that wouldn't show up for crowdsec-firewall-bouncer
as well since the logic is essentially the same! (It does a little
firewall detection, and there's basically a s/custom/firewall/ for a few
filenames, but the cscli part is exactly the same. And they both only
have crowdsec listed in Recommends.)


You just got lucky in the configuration order:
first crowdsec, thereafter crowdsec-firewall-bouncer

This heavily depends on apt's serialization of the dependency
dag ... installation of some unrelated packaged might
influence the outcome.

...
  Selecting previously unselected package crowdsec.
  Preparing to unpack .../13-crowdsec_1.4.6-3+b2_i386.deb ...
  Unpacking crowdsec (1.4.6-3+b2) ...
  Selecting previously unselected package crowdsec-firewall-bouncer.
  Preparing to unpack .../14-crowdsec-firewall-bouncer_0.0.25-2+b1_i386.deb ...
  Unpacking crowdsec-firewall-bouncer (0.0.25-2+b1) ...
  Setting up libsqlite3-0:i386 (3.40.1-2) ...
  Setting up libssl3:i386 (3.0.8-1) ...
  Setting up libjansson4:i386 (2.14-2) ...
  Setting up libmnl0:i386 (1.0.4-3) ...
  Setting up libxtables12:i386 (1.8.9-2) ...
  Setting up netbase (6.4) ...
  Setting up openssl (3.0.8-1) ...
  Setting up libbsd0:i386 (0.11.7-2) ...
  Setting up libedit2:i386 (3.1-20221030-2) ...
  Setting up libnftnl11:i386 (1.2.4-2) ...
  Setting up ca-certificates (20230311) ...
  Updating certificates in /etc/ssl/certs...
  140 added, 0 removed; done.
  Setting up crowdsec (1.4.6-3+b2) ...
  I: Registering to LAPI (/etc/crowdsec/local_api_credentials.yaml)
  W: Missing /etc/machine-id, initializing
  I: Registering to CAPI (/etc/crowdsec/online_api_credentials.yaml)
  I: Setting up offline hub (see README.Debian)
  I: Enabling upstream-recommended items, first installation (via symlinks from 
/etc/crowdsec)
  I: Enabling WAL for SQLite [fstype=] (see README.Debian)
  Setting up libnftables1:i386 (1.0.6-2) ...
  Setting up nftables (1.0.6-2) ...
  Setting up crowdsec-firewall-bouncer (0.0.25-2+b1) ...
  I: Configuring nftables [see README.Debian]
  To adjust the config: editor 
/etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml.local && systemctl 
restart crowdsec-firewall-bouncer
  Processing triggers for libc-bin (2.36-9) ...
  Processing triggers for ca-certificates (20230311) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.

Bug#1036964: igc: speed auto-negociation fails to set it to max with NIC I225-V on gigabit network

[Julien-Benjamin]

Package: linux-image-amd64-6.3.4
Severity: important
X-Debbugs-Cc: julienbenja...@free.fr

Dear Maintainer,

   * What led up to the situation?
I installed Debian on a Minisforum UM450 using a 2.5G NIC (Intel I225-V).

Speed autonegociation sometimes set the speed to 1Gbps (on a gigabit network), 
but more often than not it is set to 100Mbps.
It sometimes oscillates between 100 and 1000, but, most of the time, the speed 
is 100Mbps.

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

I tried the kernel version in experimental (6.3.4). It was the same as the one 
for current bookworm/sid (6.1.27).

I tried to change the cable and switch.

   * What was the outcome of this action?

The same behavior.

   * What outcome did you expect instead?

Since the I225-V is supposed to work on gigabit networks, whatever the kernel 
version, I expected it to work OOTB.


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

Kernel: Linux 6.3.0-0-amd64 (SMP w/6 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)
LSM: AppArmor: enabled

Bug#1034065: sasl-xoauth2: FTBFS: ModuleNotFoundError: No module named 'distutils.core'

[Daniel Kahn Gillmor]

Control: clone 1034065 -1
Control: reassign -1 python3-argparse-manpage
Control: affects -1 src:sasl-xoauth2
Control: retitle -1 argparse-manpage doesn't run unless python3-setuptools is 
installed

On Fri 2023-04-07 22:14:44 +0200, Andreas Beckmann wrote:
> sasl-xoauth2/experimental FTBFS on all architectures:
> https://buildd.debian.org/status/package.php?p=sasl-xoauth2=experimental
>
> ...
>debian/rules execute_after_dh_auto_build
> make[1]: Entering directory '/<>'
> mkdir -p completions manpages
> register-python-argcomplete --shell bash sasl-xoauth2-tool > 
> completions/sasl-xoauth2-tool
> argparse-manpage --pyfile obj-x86_64-linux-gnu/scripts/sasl-xoauth2-tool 
> --object parser \
>   --author 'Tarick Bedeir' --author-email 'tar...@bedeir.com' 
> --project-name sasl-xoauth2 \
>   --url https://github.com/tarickb/sasl-xoauth2 --output 
> manpages/sasl-xoauth2-tool.1
> Traceback (most recent call last):
>   File "/usr/bin/argparse-manpage", line 5, in 
> from build_manpages.cli import main
>   File "/usr/lib/python3/dist-packages/build_manpages/cli/__init__.py", line 
> 5, in 
> from build_manpages.build_manpage import ManPageWriter, get_parser
>   File "/usr/lib/python3/dist-packages/build_manpages/build_manpage.py", line 
> 10, in 
> from distutils.core import Command
> ModuleNotFoundError: No module named 'distutils.core'
> make[1]: *** [debian/rules:11: execute_after_dh_auto_build] Error 1
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:6: binary-arch] Error 2
> ...


I think this represents a missing dependency in
python3-argparse-manpage, which makes packages that build-depend on
python3-argparse-manpage to generate their manpages FTBFS.

  --dkg


signature.asc
Description: PGP signature

Bug#1032995: spyder: Spyder on startup says there is a missing dependency (pylsp_black) but it is correctly installed

[Brian Vaughan]

That rgrep didn't find anything.

Executing 'spyder' from the command line while in an empty directory 
still got the same 'pylsp_black' warning.

Bug#1036891: texlive-binaries: Error "attempt to call method 'read' (a nil value)" makes lualatex unusable

[Markus Koschany]

Hi Hilmar,

Am Dienstag, dem 30.05.2023 um 23:32 +0200 schrieb Preuße, Hilmar:
> On 30.05.2023 20:37, Salvatore Bonaccorso wrote:
> 
> Hi Salvatore, hi Markus,
> 
> > No, buster is under LTS support which does not have point releases.
> > But as I understand this is a regression from DLA DLA-3427-1, so a
> > regression update might be worth to be issues for it, once there is a
> > fix known.

I can reproduce the problem on Buster and that it is not present on Bullseye. I
don't see any patch differences though. The latex command appears to work too.
This problem occurs when I install texlive-latex-base texlive-luatex from
src:texlive-base. We only updated texlive-bin but the issue appears to be in
texlive-base now ?

Are there any major differences between those sources packages in Buster and
Bullseye? I had to run mtxrun --script luatex-core.lua in src:texlive-bin to
create luatex-core.c from scratch. I used the tool from Buster. Could this be
the root cause of the problem?

Regards,

Markus


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

Bug#1035499: crowdsec-custom-bouncer: fails to install with --install-recommends: open /etc/crowdsec/config.yaml: no such file or directory

[Cyril Brulebois]

Andreas Beckmann  (2023-05-30):
> crowdsec-firewall-bouncer passed the test

That I don't really understand.

> crowdsec-custom-bouncer always failed in sid (and testing) with
> --install-recommends, crowdsec-firewall-bouncer always succeeded
> 
> The difference caused by --install-recommends is
> 
> * crowdsec (which crowdsec-custom-bouncer Recommends) gets installed
> * but crowdsec-custom-bouncer gets configured first, i.e. after crowdsec got
> unpacked but before crowdsec could create the configuration file
> /etc/crowdsec/config.yaml
> * crowdsec-custom-bouncer.postinst only checks for cscli which is available
> after unpacacking

Sure, I got that part, and we're also seeing it now with a simple
`apt-get install $bouncer` in a fresh VM, so this is a real issue I'd
like to fix ASAP.

My question is why that wouldn't show up for crowdsec-firewall-bouncer
as well since the logic is essentially the same! (It does a little
firewall detection, and there's basically a s/custom/firewall/ for a few
filenames, but the cscli part is exactly the same. And they both only
have crowdsec listed in Recommends.)


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1036960: plocate: coredump on any search

[Steinar H. Gunderson]

On Tue, May 30, 2023 at 05:09:07PM -0400, Nick Black (Public gmail account) 
wrote:
> I've been using plocate for many months on all my machines without problems.
> Recently, I get a coredump on any search, on all the machines on which I've
> tested. I've got a stack trace that points at do_search_file():
> 
> Thread 1 (Thread 0x7f426c687740 (LWP 914015) "locate"):
> #0  __pthread_kill_implementation (threadid=,
> signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
> #1  0x7f426c2a9d2f in __pthread_kill_internal (signo=6, 
> threadid= out>) at ./nptl/pthread_kill.c:78
> #2  0x7f426c25aef2 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/posix/raise.c:26
> #3  0x7f426c245472 in __GI_abort () at ./stdlib/abort.c:79
> #4  0x7f426c29e2d0 in __libc_message (action=action@entry=do_abort,
> fmt=fmt@entry=0x7f426c3b8459 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
> #5  0x7f426c2b364a in malloc_printerr (str=str@entry=0x7f426c3b60b1
> "free(): invalid pointer") at ./malloc/malloc.c:5660
> #6  0x7f426c2b53d4 in _int_free (av=, p=,
> have_lock=have_lock@entry=0) at ./malloc/malloc.c:4435
> #7  0x7f426c2b7d2f in __GI___libc_free (mem=) at
> ./malloc/malloc.c:3385
> #8  0x5617abf86e1a in do_search_file (needles=std::vector of length 1,
> capacity 1 = {...}, filename="plocate.db") at ../plocate.cpp:491
> #9  0x5617abf804b8 in main (argc=, argv=) at
> ../plocate.cpp:995

The stack trace seems somewhat misleading, but I wonder perhaps if this is

  
https://git.sesse.net/?p=plocate;a=commitdiff;h=7f39444852308224240ebfb75e0bf8f39403afa0

Could you check if downgrading liburing helps? (If so, this shouldn't affect
bookworm as far as I understand)

/* Steinar */
-- 
Homepage: https://www.sesse.net/

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

[Alexandru Mihail]

Hello again, Nicholas

ProtonMail wins this time, I shall send directly to the bug as of now.

> Since you're comfortable with git, please consider creating a Salsa
> account and continuing to maintain the package in the Debian (previously
> collab-maint) group. Here's more info on what that means:

Sure, I'm absolutely fine with that

> That's ok, and totally understandable. What I meant is that 1.30 isn't
> that old compared to Bug #437932 (14 Aug 2007), #516307 from 2009.
> Those look like they may have already been fixed upstream. Then there
> are ones like #491078 that may have been fixed in Debian and/or
> upstream, or could be fixed in the next upload to Debian.

I'll check if those are resolved, of course; I'll add a suitable systemd 
service to resolve "missing-systemd-service-for-init.d-script".

> 
> Thank you, I hope yours was as good as mine!
> 
Sure was, thank you too and have a great day/night !

Best,
Alexandru

--- Original Message ---
On Wednesday, May 31st, 2023 at 00:06, Nicholas D Steeves  
wrote:


> Hello Alexandrus,
> 
> It appears that your mail user agent (possibly webmail) is encrypting
> emails to me when you "reply all" to the bug; the effect is non-public.
> It may be that the only way to fix that effect is to either 1. not CC me
> (just send to the bug) 2. Make that interface forget my key, because it
> always encrypts when a key is available. 3. Maybe there's a config
> toggle that disables unconditional encryption, for use with mailing
> lists?
> 
> Alexandru Mihail alexandru_mih...@protonmail.ch writes:
> 
> > Hello Nicholas,
> > Of course, please quote the first email at the bug. My apologies for 
> > omitting to reply all :)
> 
> 
> -- Re PM follows:
> 
> > Thank you a lot for taking the time to sponsor my work, it is a great 
> > pleasure and honor for me to finally contribute to Debian packages, after 
> > 11 years of daily usage :) . Sorry for the later reply, it's morning here.
> 
> 
> You're welcome! :) No worries with taking time to reply, and feel free
> to ping me if I take to long to reply.
> 
> > > "Do you intend to continue to maintain mini-httpd at this location (Vcs 
> > > location), or do you have a new one in mind?"
> > 
> > Do you have any preferences/suggestions regarding this question?
> > I am comfortable with git so forking on git wouldn't be a problem. I have 
> > no remote to share so far.
> 
> 
> Since you're comfortable with git, please consider creating a Salsa
> account and continuing to maintain the package in the Debian (previously
> collab-maint) group. Here's more info on what that means:
> 
> https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
> 
> It's ok if you don't want to; however, in this case we'll need to update
> the Vcs links in the package.
> 
> > > "On the topic of work, has upstream resolved any of these old bugs"
> > 
> > The latest upstream release is still mini_httpd-1.30.tar.gz. ACME
> > produces quality releases in general, but their release cycle is
> > pretty lethargic as they are a small team working on many tools.
> 
> 
> That's ok, and totally understandable. What I meant is that 1.30 isn't
> that old compared to Bug #437932 (14 Aug 2007), #516307 from 2009.
> Those look like they may have already been fixed upstream. Then there
> are ones like #491078 that may have been fixed in Debian and/or
> upstream, or could be fixed in the next upload to Debian.
> 
> > As context, I've worked professionally on patches for mini-httpd for about 
> > 9 months, adding PAM support and AAA authentication. Sadly, the license of 
> > my work is evidently proprietary. If I have the time I can try to tackle 
> > all the bugs alone, as I know everything that's happening in mini_httpd.c. 
> > I'll try mailing Jef (from ACME) to see if any fixes are in the pipeline.
> 
> 
> Nice, it sounds like you're the ideal maintainer for Debian's
> mini-httpd! It also sounds like you already know work to get things
> merged upstream whenever possible.
> 
> > I might need a wee bit of assistance with lintian errors/Debian
> > conventions as I mainly come from RPM land. I've packaged debs before
> > for my employer, but Debian's standards and procedures are very
> > different (and that's a good thing !).
> 
> 
> Oh good, you're already using lintian :) Please take care to use a
> recent version like 2.116.3 or 2.115.1~bpo11+1 (bullseye backport). Run
> it with the "--info" argument to get explanations. There is currently
> one warning (W) that needs to be fixed before this package is ready to
> upload.
> 
> > I'm looking forward to your input and have a great weekend !
> 
> 
> Thank you, I hope yours was as good as mine!
> 
> Regards,
> Nicholas

Bug#1035499: crowdsec-custom-bouncer: fails to install with --install-recommends: open /etc/crowdsec/config.yaml: no such file or directory

[Andreas Beckmann]

On 30/05/2023 21.18, Andreas Beckmann wrote:

On 30/05/2023 20.24, Cyril Brulebois wrote:

Alright, with RC 4 out of the way, I'm looking at this issue again, and
it seems the “sibling package” crowdsec-firewall-bouncer is affected by
the exact same issue (not surprisingly). I'm curious as to whether it
showed up in those piuparts tests, if you have bug reports yet to be
filed, or something else.


I have successful test logs from Apr 09 for crowdsec-firewall-bouncer, 
rescheduled them right now, will report later what happened.


crowdsec-firewall-bouncer passed the test

crowdsec-custom-bouncer always failed in sid (and testing) with 
--install-recommends, crowdsec-firewall-bouncer always succeeded


The difference caused by --install-recommends is

* crowdsec (which crowdsec-custom-bouncer Recommends) gets installed
* but crowdsec-custom-bouncer gets configured first, i.e. after crowdsec 
got unpacked but before crowdsec could create the configuration file 
/etc/crowdsec/config.yaml
* crowdsec-custom-bouncer.postinst only checks for cscli which is 
available after unpacacking



Andreas

Bug#1036962: ITP: libovxlib-dev -- Lightweight wrapper for OpenVX Neural-Network Extension provided by VeriSilicon to facilitate the deployment of Neural-Networks on OpenVX enabled hardware accelerato

[Leonardo Held]

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

* Package name : libovxlib-dev
Version : x.y.z
Upstream Author : Name 
* URL : https://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
Programming Lang: (C, C++, C#, Perl, Python, etc.)
Description : Lightweight wrapper for OpenVX Neural-Network Extension
provided by VeriSilicon
to facilitate the deployment of Neural-Networks on OpenVX enabled
hardware accelerators

Please also include as much relevant information as possible.
For example, consider answering the following questions:
- why is this package useful/relevant? is it a dependency for
another package? do you use it? if there are other packages
providing similar functionality, how does it compare?

libovxlib-dev is a dependency for certain tensorflow-lite deployments
that use custom delegates (ie, hardware accelerators).
It's extremely useful in embedded AI applications using iMX processors.
I also plan to send an ITP for libnnrt and and libneuralnetworks, which
are dependent of libovxlib.

- how do you plan to maintain it? inside a packaging team
(check list at https://wiki.debian.org/Teams)? are you
looking for co-maintainers? do you need a sponsor?

Company (see text after @ in my e-mail) actively uses this software, and
we already have it packaged
downstream.

[Toradex Logo]    Embedded Computing
Made Easy
Choose Us | 
Products | Developer Center | 
Community | Careers
Join our webinar:
- Simplify the development of critical medical and industrial applications with QNX 
and NXP i.MX 8 | June 23, 2023: 
Register

Meet our engineers at:
- Medtec China | Suzhou, China | June 01-03, 2023
- Sensors Converge | California, USA | June 20-22, 2023

Bug#1036891: texlive-binaries: Error "attempt to call method 'read' (a nil value)" makes lualatex unusable

[Preuße]

On 30.05.2023 20:37, Salvatore Bonaccorso wrote:

Hi Salvatore, hi Markus,


No, buster is under LTS support which does not have point releases.
But as I understand this is a regression from DLA DLA-3427-1, so a
regression update might be worth to be issues for it, once there is a
fix known.

Short question: the web page for the security issue [1] lists a few 
patches. I downloaded a few of them, but no one is matches to the 
CVE-2023-32700.patch in the texlive-bin_2018.20181218.49446-1+deb10u1 
diff. Which patch did you use?



Thus might need to loop in debian-lts list and/or Markus as well.

Does this helps you already for the admnistrativa part?


Yes, for now this answers my question.

Hilmar

[1] https://tug.org/~mseven/luatex.html
--
sigfault



OpenPGP_0x0C871C4C653C1F59.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036961: linux-image-5.10.0-21-amd64: ATA errors on healty SATA drive after many hours with ASMedia ASM1061 Controller

[Edward Ando]

Package: src:linux
Version: 5.10.162-1
Severity: important

Dear Maintainer,
I am running a server with a rather high-end motherboard for an AMD
Threadripper: Asus Pro WS WRX80E Sage SE WiFi
It has two SATA controllers offering four ports each:
  - AMD WRX80 Chipset
  - ASMedia ASM1061 Controller
I have an mdraid array with dissk connected to both ports. Drives connected to
the ASMedia controller
systematically (after a few weeks) started to complain of:

First:

May  3 08:56:27 thumper kernel: [2323271.879640] {6}[Hardware Error]: Hardware
error from APEI Generic Hardware Error Source: 512
May  3 08:56:27 thumper kernel: [2323271.879643] {6}[Hardware Error]: It has
been corrected by h/w and requires no further action
May  3 08:56:27 thumper kernel: [2323271.879644] {6}[Hardware Error]: event
severity: corrected
May  3 08:56:27 thumper kernel: [2323271.879646] {6}[Hardware Error]:  Error 0,
type: corrected
May  3 08:56:27 thumper kernel: [2323271.879647] {6}[Hardware Error]:
section_type: PCIe error
May  3 08:56:27 thumper kernel: [2323271.879648] {6}[Hardware Error]:
port_type: 4, root port
May  3 08:56:27 thumper kernel: [2323271.879649] {6}[Hardware Error]:
version: 0.2
May  3 08:56:27 thumper kernel: [2323271.879650] {6}[Hardware Error]:
command: 0x0407, status: 0x0010
May  3 08:56:27 thumper kernel: [2323271.879651] {6}[Hardware Error]:
device_id: :20:01.1
May  3 08:56:27 thumper kernel: [2323271.879652] {6}[Hardware Error]:   slot: 0
May  3 08:56:27 thumper kernel: [2323271.879653] {6}[Hardware Error]:
secondary_bus: 0x21
May  3 08:56:27 thumper kernel: [2323271.879654] {6}[Hardware Error]:
vendor_id: 0x1022, device_id: 0x1483
May  3 08:56:27 thumper kernel: [2323271.879655] {6}[Hardware Error]:
class_code: 060400
May  3 08:56:27 thumper kernel: [2323271.879656] {6}[Hardware Error]:   bridge:
secondary_status: 0x, control: 0x001a
May  3 08:56:27 thumper kernel: [2323271.880405] pcieport :20:01.1:[ 6]
BadTLP


Then:

May  4 04:25:05 thumper kernel: [2393388.290834] ata1: hard resetting link
May  4 04:25:06 thumper kernel: [2393388.827216] ata1: SATA link up 6.0 Gbps
(SStatus 133 SControl 300)
May  4 04:25:06 thumper kernel: [2393388.956776] ata1.00: configured for
UDMA/133
May  4 04:25:06 thumper kernel: [2393388.956798] ata1: EH complete
May  4 04:25:38 thumper kernel: [2393420.982144] ata1: hard resetting link
May  4 04:25:48 thumper kernel: [2393430.982246] ata1: hard resetting link
May  4 04:25:58 thumper kernel: [2393440.982626] ata1: hard resetting link
May  4 04:26:33 thumper kernel: [2393475.981161] ata1: limiting SATA link speed
to 3.0 Gbps
May  4 04:26:33 thumper kernel: [2393475.981162] ata1: hard resetting link
May  4 04:26:38 thumper kernel: [2393480.981248] ata1.00: disabled
May  4 04:26:38 thumper kernel: [2393480.981272] ata1: EH complete
May  4 04:26:38 thumper kernel: [2393480.981838] sd 0:0:0:0: [sdb] tag#31
FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=124s
May  4 04:26:38 thumper kernel: [2393480.981848] sd 0:0:0:0: [sdb] tag#31 CDB:
Write(16) 8a 00 00 00 00 00 ad 6c 78 00 00 00 05 40 00 00
May  4 04:26:38 thumper udisksd[1873]: Error performing housekeeping for drive
/org/freedesktop/UDisks2/drives/WDC_WD101EFBX_68B0AN0_VCHZLKRP: Error updating
SMART data: sk_disk_smart_read_data: Operation not supported (udisks-error-
quark, 0)
May  4 04:26:38 thumper kernel: [2393480.981997] sd 0:0:0:0: [sdb] Read
Capacity(16) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
May  4 04:26:38 thumper kernel: [2393480.982000] sd 0:0:0:0: [sdb] Sense not
available.
May  4 04:26:38 thumper kernel: [2393480.982018] sd 0:0:0:0: [sdb] Read
Capacity(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
May  4 04:26:38 thumper kernel: [2393480.982020] sd 0:0:0:0: [sdb] Sense not
available.
May  4 04:26:38 thumper kernel: [2393480.982035] sd 0:0:0:0: [sdb] 0 512-byte
logical blocks: (0 B/0 B)
May  4 04:26:38 thumper kernel: [2393480.982036] sd 0:0:0:0: [sdb] 4096-byte
physical blocks
May  4 04:26:38 thumper kernel: [2393480.982066] sdb: detected capacity change
from 1831348736 to 0


Followed by a lot of:

May  4 07:14:38 thumper kernel: [2403561.158594] sd 0:0:0:0: [sdb] tag#24
FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
May  4 07:14:38 thumper kernel: [2403561.158598] sd 0:0:0:0: [sdb] tag#24 CDB:
ATA command pass through(16) 85 06 20 00 00 00 00 00 00 00 00 00 00 00 e5 00
May  4 07:24:38 thumper udisksd[1873]: Error performing housekeeping for drive
/org/freedesktop/UDisks2/drives/WDC_WD101EFBX_68B0AN0_VCHZLKRP: Error updating
SMART data: Error sending ATA command CHECK POWER MODE: Unexpected sense data
returned:#012: 00 00 00 00  00 00 00 00  00 00 00

Then the drives disappeared completely.
They would return after a reboot quite happily.
A different SATA controller bought and added confirmed the drives were fine,
and no problems since.


-- Package-specific info:
** Version:
Linux version 5.10.0-21-amd64 

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

[Nicholas D Steeves]

Hello Alexandrus,

It appears that your mail user agent (possibly webmail) is encrypting
emails to me when you "reply all" to the bug; the effect is non-public.
It may be that the only way to fix that effect is to either 1. not CC me
(just send to the bug) 2. Make that interface forget my key, because it
always encrypts when a key is available.  3. Maybe there's a config
toggle that disables unconditional encryption, for use with mailing
lists?

Alexandru Mihail  writes:

> Hello Nicholas,
> Of course, please quote the first email at the bug. My apologies for omitting 
> to reply all :) 

-- Re PM follows:

> Thank you a lot for taking the time to sponsor my work, it is a great 
> pleasure and honor for me to finally contribute to Debian packages, after 11 
> years of daily usage :) . Sorry for the later reply, it's morning here.

You're welcome! :) No worries with taking time to reply, and feel free
to ping me if I take to long to reply.

>> "Do you intend to continue to maintain mini-httpd at this location (Vcs 
>> location), or do you have a new one in mind?"
>>
> Do you have any preferences/suggestions regarding this question?
> I am comfortable with git so forking on git wouldn't be a problem. I have no 
> remote to share so far.

Since you're comfortable with git, please consider creating a Salsa
account and continuing to maintain the package in the Debian (previously
collab-maint) group.  Here's more info on what that means:

  
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group

It's ok if you don't want to; however, in this case we'll need to update
the Vcs links in the package.

>> "On the topic of work, has upstream resolved any of these old bugs"
>>
> The latest upstream release is still mini_httpd-1.30.tar.gz. ACME
> produces quality releases in general, but their release cycle is
> pretty lethargic as they are a small team working on many tools.

That's ok, and totally understandable.  What I meant is that 1.30 isn't
that old compared to Bug #437932 (14 Aug 2007), #516307 from 2009.
Those look like they may have already been fixed upstream.  Then there
are ones like #491078 that may have been fixed in Debian and/or
upstream, or could be fixed in the next upload to Debian.

> As context, I've worked professionally on patches for mini-httpd for about 9 
> months, adding PAM support and AAA authentication. Sadly, the license of my 
> work is evidently proprietary. If I have the time I can try to tackle all the 
> bugs alone, as I know everything that's happening in mini_httpd.c. I'll try 
> mailing Jef (from ACME) to see if any fixes are in the pipeline. 

Nice, it sounds like you're the ideal maintainer for Debian's
mini-httpd!  It also sounds like you already know work to get things
merged upstream whenever possible.

> I might need a wee bit of assistance with lintian errors/Debian
> conventions as I mainly come from RPM land. I've packaged debs before
> for my employer, but Debian's standards and procedures are very
> different (and that's a good thing !).

Oh good, you're already using lintian :)  Please take care to use a
recent version like 2.116.3 or 2.115.1~bpo11+1 (bullseye backport).  Run
it with the "--info" argument to get explanations.  There is currently
one warning (W) that needs to be fixed before this package is ready to
upload.

> I'm looking forward to your input and have a great weekend !

Thank you, I hope yours was as good as mine!

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1036947: whipper: Whipper does not work when syncthing-gtk is also installed

[Louis-Philippe Véronneau]

reassign 1036947 syncthing-gtk
retitle 1036947 syncthing-gtk: Invalid version number breaks other packages
affects 1036947 whipper
severity 1036947 critical
tags 1036947 + patch
thanks

Thanks for reporting this bug. I can indeed reproduce the failure with whipper 
when syncthing-gtk is installed, with pretty much any whipper command.

As kindly mentioned by Nicolas Dandrimont on IRC, this seems to be a bug with 
syncthing-gtk itself, and not directly with whipper. As such, I'm reassigning this bug to 
syncthing-gtk and I've changed the severity to critical ("makes unrelated software 
on the system break").

The current syncthing-gtk version is not valid, as it doesn't respect PEP-440. 
Only ASCII letters ([a-zA-Z]), ASCII digits ([0-9]) and periods (.) are allowed 
after the initial + and this is what ends up crashing whipper (and maybe other 
packages?).

I tried rebuilding the package with version 
0.9.4.4+ds.git20221205.12a9702d29ab-1 (replacing the last 2 + by dots) and it 
does fix the issue, but it sounds like the wrong way to fix the issue.

I am not very familiar with syncthing-gtk's code, but it seems the issue spawns 
from the get_version() function in setup.py, which uses git tags to find the 
proper version.

Hardcoding a suitable version (say 0.9.4.4) in that file instead of using 
version=get_version() works too, but also sounds like the wrong solution, at 
least in the long term. For the sake of the upcoming release (and making sure 
whipper isn't broken randomly by syncthing-gtk), I'd say it is the simplest 
solution. I've thus attached a patch, and I encourage the maintainers to apply 
it and ask for an unblocking request post-haste.

Cheers,

[1]:  https://peps.python.org/pep-0440/

--
   ⢀⣴⠾⠻⢶⣦⠀
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
   ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
   ⠈⠳⣄Description: This hotfix patch fixes a problem with syncthing-gtk's current
 Debian version not respecting PEP-440 and thus crashing other packages. By
 bypassing the get_version() function altogether, the version used by the
 package doesn't include the git hash.
 This patch should probably be revisited after the release of Debian Bookworm
 to find long-term solution.
Forwarded: not-needed
Bug-Debian: http://bugs.debian.org/1036947
Author: Louis-Philippe Véronneau 
Index: syncthing-gtk/setup.py
===
--- syncthing-gtk.orig/setup.py
+++ syncthing-gtk/setup.py
@@ -119,7 +119,7 @@ if __name__ == "__main__":
 ]
 setup(
 name='syncthing-gtk',
-version=get_version(),
+version='0.9.4.4',
 description='GTK3 GUI for Syncthing',
 url='https://github.com/syncthing/syncthing-gtk',
 packages=['syncthing_gtk'],

Bug#1036957: unblock: openssl/3.0.8-1

[Sebastian Andrzej Siewior]

control: retitle -1 unblock: openssl/3.0.9-1

On 2023-05-30 22:16:53 [+0200], To sub...@bugs.debian.org wrote:
> 
> Please unblock package openssl.
> 
> The 3.0.9 release contains security and non-security related fixes for
> the package. There are five new CVEs in total that has been addressed.
> One with "moderate" severity. From the package's changelog:
> 
> - CVE-2023-0464 (Excessive Resource Usage Verifying X.509 Policy
>   Constraints) (Closes: #1034720).
> - CVE-2023-0465 (Invalid certificate policies in leaf certificates are
>   silently ignored).
> - CVE-2023-0466 (Certificate policy check not enabled).
> - Alternative fix for CVE-2022-4304 (Timing Oracle in RSA Decryption).
> - CVE-2023-2650 (Possible DoS translating ASN.1 object identifiers).
> - CVE-2023-1255 (Input buffer over-read in AES-XTS implementation on 64 
> bit ARM).
> 
> The package built on all release architectures (it is still building on
> mipsel at the of writing but I expect it to pass).
> The openssl testsuite run on all architectures during the build process.
> Please find attached the debdiff vs the version in testing.
> 
> unblock openssl/3.0.9-1

Sebastian

Bug#1033060: qa.debian.org: wrong username and email for my DDPO page

[Mattia Rizzolo]

On Thu, Mar 16, 2023 at 11:22:03PM +1100, Russell Coker wrote:
> https://qa.debian.org/developer.php?login=etbe%40debian.org
> https://qa.debian.org/developer.php?login=russell%40coker.com.au
> 
> The above pages attribute my packages to Taihsiang Ho ,
> apparently due to my last upload of the rasdaemon package.

Indeed.

The easiest way would be to fix that package and once it disappears from
the archive DDPO should catch up.  (i.e., try to get it into bookworm?)


I'm quite surprised nothing more broke out of the upload, since AFAIK
that's invalid (and I'm going to file a bug for that).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1036960: plocate: coredump on any search

[Nick Black (Public gmail account)]

Package: plocate
Version: 1.1.18-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

   * What led up to the situation?

I've been using plocate for many months on all my machines without problems.
Recently, I get a coredump on any search, on all the machines on which I've
tested. I've got a stack trace that points at do_search_file():

Thread 1 (Thread 0x7f426c687740 (LWP 914015) "locate"):
#0  __pthread_kill_implementation (threadid=,
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x7f426c2a9d2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x7f426c25aef2 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#3  0x7f426c245472 in __GI_abort () at ./stdlib/abort.c:79
#4  0x7f426c29e2d0 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f426c3b8459 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#5  0x7f426c2b364a in malloc_printerr (str=str@entry=0x7f426c3b60b1
"free(): invalid pointer") at ./malloc/malloc.c:5660
#6  0x7f426c2b53d4 in _int_free (av=, p=,
have_lock=have_lock@entry=0) at ./malloc/malloc.c:4435
#7  0x7f426c2b7d2f in __GI___libc_free (mem=) at
./malloc/malloc.c:3385
#8  0x5617abf86e1a in do_search_file (needles=std::vector of length 1,
capacity 1 = {...}, filename="plocate.db") at ../plocate.cpp:491
#9  0x5617abf804b8 in main (argc=, argv=) at
../plocate.cpp:995

this also happens with an empty database.


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

Kernel: Linux 6.3.4nlb2 (SMP w/64 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)

Versions of packages plocate depends on:
ii  adduser 3.134
ii  libc6   2.36-9
ii  libgcc-s1   12.2.0-14
ii  libstdc++6  12.2.0-14
ii  liburing2   2.3-3
ii  libzstd11.5.4+dfsg2-5

plocate recommends no packages.

Versions of packages plocate suggests:
ii  nocache 1.1-1+b1
ii  powermgmt-base  1.37
ii  systemd-sysv252.6-1

-- Configuration Files:
/etc/updatedb.conf changed:
PRUNE_BIND_MOUNTS="yes"
PRUNEPATHS="/tmp /var/spool /media/usb /media/dank /media/mtp /media/killermike 
/var/lib/os-prober /var/lib/ceph /home/.ecryptfs /var/lib/schroot"
PRUNEFS="NFS afs autofs binfmt_misc ceph cgroup cgroup2 cifs coda configfs 
curlftpfs debugfs devfs devpts devtmpfs ecryptfs ftpfs fuse.ceph fuse.cryfs 
fuse.encfs fuse.glusterfs fuse.gocryptfs fuse.gvfsd-fuse fuse.mfs fuse.rclone 
fuse.rozofs fuse.sshfs fusectl fusesmb hugetlbfs iso9660 lustre lustre_lite mfs 
mqueue ncpfs nfs nfs4 ocfs ocfs2 proc pstore rpc_pipefs securityfs shfs smbfs 
sysfs tmpfs tracefs udev udf usbfs"


-- no debconf information

Bug#1036959: rasdaemon: invalid Maintainer field

[Mattia Rizzolo]

Source: rasdaemon
Version: 0.6.8-1
Severity: serious

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

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#1031132: godot FTBFS on arm64, armel, ppc64el and s390x

[Petter Reinholdtsen]

[Salvatore Bonaccorso]
> the recent upload of godot/3.5.1-stable-1 FTBFS on arm64, armel,
> ppc64el and s390x:

I suspect most of these are upstream issue
https://github.com/godotengine/godot/issues/47344 >.
The armel issue is #1019868.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1036958: jigdo-file: Jigdo-file and jigdo-lite 0.8.1 still report as 0.8.0 version

[bud]

Package: jigdo-file
Version: 0.8.1-1+b1
Severity: minor
X-Debbugs-Cc: budheal...@gmail.com

Dear Maintainer,

   * What led up to the situation?
In bookworm, jigdo-lite messages are obviously changed. In bullseye, the most 
obvious change was (see Bug#988120) the failure to reuse the scan cache, making 
it worth to keep a machine running buster, which finishes much faster than 
bullseye running on a SSD.

The changes for bookworm may help others but not my paltry bandwidth. I am not 
about to offer a patch here, but it was worth a look at the sources. 
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
So I checked the versions (jigdo-file --version, jigdo-lite -v) and found the 
versions on bookworm and bullseye are reported as 0.8.0. cmp quickly reports 
that the respective binaries (and the jigdo-mirror scripts too) differ. 
   * What was the outcome of this action?
So I looked in the online sources and found only one apparent place 
self-reporting the version:

jigdo.spec:%define version  0.8.0
   * What outcome did you expect instead?
jigdo-file and jigdo-lite should report the right version. 

I am noticing that such minor inaccuracies can compound to where in the next 
major release, chaos can become difficult to rein in. Hence this report.

-- System Information:
Debian Release: 12.0
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/8 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)
LSM: AppArmor: enabled

Versions of packages jigdo-file depends on:
ii  libbz2-1.0  1.0.8-5+b1
ii  libc6   2.36-9
ii  libdb5.35.3.28+dfsg2-1
ii  libgcc-s1   12.2.0-14
ii  libstdc++6  12.2.0-14
ii  wget1.21.3-1+b2
ii  zlib1g  1:1.2.13.dfsg-1

jigdo-file recommends no packages.

jigdo-file suggests no packages.

-- no debconf information

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

[Alexandru Mihail]

Hello Nicholas,
Of course, please quote the first email at the bug. My apologies for omitting 
to reply all :)

Best,
Alexandru

On Tue, May 30, 2023 at 23:17, Nicholas D Steeves <[s...@debian.org](mailto:On 
Tue, May 30, 2023 at 23:17, Nicholas D Steeves < wrote:

> Hi Alexandru,
>
> Please take care to reply in cleartext to this RFS bug (#1036751), using
> "reply to all" or "reply to list", because it's expected that most
> Debian development and discussion happens in the open.
>
> It's also important to have evidence of progress so that someone's bug
> cleanup script doesn't mark the project as stalled and close the bug.
>
> May I quote your decrypted email (the first and longer one) at this bug
> in my reply?
>
> Best,
> Nicholas

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

[Nicholas D Steeves]

Hi Alexandru,

Please take care to reply in cleartext to this RFS bug (#1036751), using
"reply to all" or "reply to list", because it's expected that most
Debian development and discussion happens in the open.

It's also important to have evidence of progress so that someone's bug
cleanup script doesn't mark the project as stalled and close the bug.

May I quote your decrypted email (the first and longer one) at this bug
in my reply?

Best,
Nicholas


signature.asc
Description: PGP signature

Bug#1036956: xscreensaver: U2F instructions should be clearer

[Celejar]

Package: xscreensaver
Version: 6.06+dfsg1-3
Severity: minor

Hello,

I have configured xscreensaver to unlock via U2F (a hardware Yubico
device, in my case), as per the attached /etc/pam.d/xscreensaver file.
When unlocking, xscreensaver displays the message "Please touch the
device." along with two buttons, "New Login" and "OK." For unlocking
to work, the "OK" button must be pressed *first*, and only *afterward* does
touching the device work. I think the message should more clearly
indicate this sequence - the current message implies that touching the
device immediately will work.

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

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

Versions of packages xscreensaver depends on:
ii  init-system-helpers  1.65.2
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9
ii  libcrypt11:4.4.33-2
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libpam0g 1.5.2-6
ii  libsystemd0  252.6-1
ii  libx11-6 2:1.8.4-2
ii  libxext6 2:1.3.4-1+b1
ii  libxft2  2.3.6-1
ii  libxi6   2:1.8-1+b1
ii  libxinerama1 2:1.1.4-3
ii  libxml2  2.9.14+dfsg-1.2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxt6   1:1.2.1-1.1
ii  libxxf86vm1  1:1.1.4-1+b2
ii  xscreensaver-data6.06+dfsg1-3

Versions of packages xscreensaver recommends:
ii  fonts-urw-base35  20200910-7
ii  libjpeg-turbo-progs   1:2.1.5-2
ii  perl  5.36.0-7
ii  wamerican [wordlist]  2020.12.07-2

Versions of packages xscreensaver suggests:
ii  chromium [www-browser]   113.0.5672.126-1
ii  firefox [www-browser]113.0.2-1
pn  fortune  
pn  gdm3 | kdm-gdmcompat 
ii  lynx [www-browser]   2.9.0dev.12-1
pn  qcam | streamer  
pn  xdaliclock   
pn  xfishtank
pn  xscreensaver-data-extra  
pn  xscreensaver-gl  
pn  xscreensaver-gl-extra

-- Configuration Files:
/etc/pam.d/xscreensaver changed:
auth sufficient pam_u2f.so cue debug
@include common-auth
@include common-account


-- no debconf information

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

[Leonardo Held]

Package: qt6-base-dev
Followup-For: Bug #1035985

Dear Maintainer,

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.


Regards


-- System Information:
Debian Release: bookworm/sid
APT prefers jammy-updates
APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 
'jammy'), (100, 'jammy-backports')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.2.6-76060206-generic (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE:en

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages qt6-base-dev depends on:
ii libglx-dev 1.4.0-1
ii libopengl-dev 1.4.0-1
pn libqt6concurrent6 
pn libqt6core6 
pn libqt6dbus6 
pn libqt6gui6 
pn libqt6network6 
pn libqt6openglwidgets6 
pn libqt6printsupport6 
pn libqt6sql6 
pn libqt6test6 
pn libqt6widgets6 
pn libqt6xml6 
pn qmake6 
pn qt6-base-dev-tools 
pn qt6-qpa-plugins 

Versions of packages qt6-base-dev recommends:
pn libqt6opengl6-dev 

qt6-base-dev suggests no packages.

Bug#1036929: mmdebstrap: Feature request: "mmdebstrap --anything-failed-commands '%s'" should exist, like in sbuild

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Dima Kogan (2023-05-30 20:48:59)
> Johannes Schauer Marin Rodrigues  writes:
> > ah I see our main difference might be that I run mmdebstrap mostly
> > from other scripts whereas you are running it interactively and thus
> > you want a shell if something goes wrong.
> I usually run it from scripts too. But if something goes wrong, I re-run
> it manually, and having an easy way to get a shell at the failing point
> would be nice.

let me tell you about another trick. Instead of running

--customize-hook='chroot "$1" i-might-fail || chroot "$1" bash'

you can also run:

--chrooted-customize-hook='i-might-fail || bash'

In contrast to the --X-hook options, the --chrooted-X-hook options run their
arguments inside the chroot and thus save you quite a bit of typing. The
--chrooted-X-hook options do a bit more than that but those things are not
relevant here. The options are currently undocumented but I think I'll make
them official with the next release.

> > Oh, so you want the interactive shell on other things than failing hooks? 
> > You
> > also want that shell when any command run by mmdebstrap failed?
> 
> Yessir. A shell where the failure is quickly reproduced makes fixing
> problems MUCH faster. That's what sbuild does, and I've used this
> countless times.

There is a big difference between the commands run by sbuild and the commands
run by mmdebstrap. In sbuild, when your package fails, you start a shell inside
your build chroot, cd into the right directory and run dpkg-buildpackage. The
commands run by mmdebstrap are far from that trivial to reproduce. I've yet
to see a good use-case for dropping to an interactive shell for *and* failed
command (not just hooks).

To give you an idea of why it's really far from simple to just re-run a command
run by mmdebstrap have a look at this:

https://sources.debian.org/src/mmdebstrap/1.3.5-7/mmdebstrap/#L486

If any of that fails, what good is an interactive shell going to do?

> > The commands should be printed if you increase verbosity with --verbose or 
> > even
> > with --debug. If the command is not printed, then that is a bug that I will
> > fix.
> 
> Good to know. I admittedly haven't spent a ton of time working on it.

I think what you ultimately want with the interactive bash shell is to figure
out why the stuff that broke for you did break. But I can get you the same
information by increasing either the --verbose or --debug output as necessary.

> > For your specific problem I would first try to take mmdebstrap out of the 
> > loop
> > and see if the problem can be replicated with plain apt as well.
> 
> I did that. The problem only shows up with mmdebstrap. I doubt it's a
> bug in mmdebstrap, but that's the only place I see this.

When I said "plain apt" I meant the script below. After all, mmdebstrap is just
a wrapper around apt.

> > The man page contains a small shell snippet that does the essential things 
> > that
> > mmdebstrap does but without mmdebstrap in the section OPERATION:
> >
> > https://manpages.debian.org/unstable/mmdebstrap/mmdebstrap.1.en.html#OPERATION
> >
> > You could try if that script with your apt-cacher-ng setup produces the same
> > error and then you've already reduced the number of moving parts.
> 
> I can do that. But fixing this hasn't been very high priority for me
> today, so I haven't put in the work. I'm just using this as an example
> of a case where the --failure-hook option would be useful.

I think it is a bad example for the --failure-hook option because what you want
can also be achieved by better --verbose or --debug output.

Could you run your mmdebstrap invocation with --debug and paste(bin) the error
you get?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1036955: RFS: trurl/0.7-1 -- command line tool for URL parsing and manipulation

[Michael Ablassmeier]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : trurl
   Version  : 0.7-1
 * URL  : https://github.com/curl/trurl
 * License  : curl
   Section  : utils

The source builds the following binary packages:

  trurl - command line tool for URL parsing and manipulation

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/t/trurl/trurl_0.7-1.dsc

Changes since the last upload:

 trurl (0.7-1) unstable; urgency=medium
 .
   * New upstream release.

Typos in manpage have been reported upstream:

 https://github.com/curl/trurl/pull/212

Regards,
-- 
  Michael Ablassmeier

Bug#1036954: RM: matrix-synapse/1.78.0-1

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: matrix-syna...@packages.debian.org, 
matrix-syna...@packages.debian.org, t...@security.debian.org, Andrej Shadura 
, car...@debian.org
Control: affects -1 + src:matrix-synapse

Dear release team,

As discussed with Andrej in #1036806 matrix-synapse will be hard to
support during the bookworm release cycle. To avoid we ship it
initially with bookworm, but relatively quickly might need to ask for
removal, let's not ship it from the start.

See https://bugs.debian.org/1036806#30

Regards,
Salvatore

Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages

[Samuel Thibault]

Samuel Thibault, le mar. 30 mai 2023 21:21:51 +0200, a ecrit:
> Samuel Thibault, le mar. 30 mai 2023 21:16:46 +0200, a ecrit:
> > I'm wondering what kind of console aarch64 is using: is that the Linux
> > virtual Terminal on an fbdev, or a ttyS console? Something else? The
> > kernel boot logs could be useful to determine that.
> 
> Ah, https://openqa.debian.net/tests/151286/logfile?filename=serial0.txt
> provides it.
> 
> May 30 06:37:27 init: starting pid 246, tty '/dev/ttyAMA0': 
> '/sbin/debian-installer'
> May 30 06:37:27 init: starting pid 247, tty '/dev/tty1': 
> '/sbin/debian-installer'
> 
> So it might be "something else" :) Is the shown output from ttyAMA0, or
> tty1?

Also, to be noted:

May 30 06:37:27 kernel: [0.531174] Run /init as init process
May 30 06:37:27 kernel: [0.531176]   with arguments:
May 30 06:37:27 kernel: [0.531177] /init
May 30 06:37:27 kernel: [0.531178] ---
May 30 06:37:27 kernel: [0.531179]   with environment:
May 30 06:37:27 kernel: [0.531180] HOME=/
May 30 06:37:27 kernel: [0.531181] TERM=linux
May 30 06:37:27 kernel: [0.531181] BOOT_IMAGE=/install.a64/vmlinuz

So init does get started with TERM=linux, not vt102. So it's something
in-between that seems to be setting that.

Samuel

Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages

[Samuel Thibault]

Samuel Thibault, le mar. 30 mai 2023 21:16:46 +0200, a ecrit:
> I'm wondering what kind of console aarch64 is using: is that the Linux
> virtual Terminal on an fbdev, or a ttyS console? Something else? The
> kernel boot logs could be useful to determine that.

Ah, https://openqa.debian.net/tests/151286/logfile?filename=serial0.txt
provides it.

May 30 06:37:27 init: starting pid 246, tty '/dev/ttyAMA0': 
'/sbin/debian-installer'
May 30 06:37:27 init: starting pid 247, tty '/dev/tty1': 
'/sbin/debian-installer'

So it might be "something else" :) Is the shown output from ttyAMA0, or
tty1?

Samuel

Bug#1035499: crowdsec-custom-bouncer: fails to install with --install-recommends: open /etc/crowdsec/config.yaml: no such file or directory

[Andreas Beckmann]

On 30/05/2023 20.24, Cyril Brulebois wrote:

Alright, with RC 4 out of the way, I'm looking at this issue again, and
it seems the “sibling package” crowdsec-firewall-bouncer is affected by
the exact same issue (not surprisingly). I'm curious as to whether it
showed up in those piuparts tests, if you have bug reports yet to be
filed, or something else.


I have successful test logs from Apr 09 for crowdsec-firewall-bouncer, 
rescheduled them right now, will report later what happened.


Andreas

Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages

[Samuel Thibault]

Hello,

Cyril Brulebois, le mar. 30 mai 2023 21:08:45 +0200, a ecrit:
> Philip Hands  (2023-05-30):
> > Apparently, this MR fixes the problem:
> > 
> >   https://salsa.debian.org/installer-team/rootskel/-/merge_requests/8
> > 
> > Although this does prompt the question of why aarch64 has TERM set to
> > 'vt102' at this point, rather than 'linux'.
> 
> Glancing at the merge request earlier, my first (intertwined) questions
> were:
> 
>   1. Why is aarch64 special here?
>   2. Where does that difference come from?

I'm wondering what kind of console aarch64 is using: is that the Linux
virtual Terminal on an fbdev, or a ttyS console? Something else? The
kernel boot logs could be useful to determine that.

Samuel

>   3. Which other architectures might be impacted if we were to change
>  that?
> 
> > Also, I wonder whether there could be other circumstances when $TERM
> > is set to 'vt102' where this change could be problematic (I'm guessing
> > that the $TERM_TYPE checks deal with that, but I'm not sure).
> 
> Yeah, that's the same kind of questions one would get by combined my
> second and third questions…

Bug#773385: Ping

[Dima Kogan]

This really should work. It's maybe sorta ok for "apt-file list", but it
also affects "apt-file find". Look:

  dima@fatty:~$ apt-file find /usr/lib/aarch64-linux-gnu/libOpenCL.so


  dima@fatty:~$ apt-file -aarm64 find /usr/lib/aarch64-linux-gnu/libOpenCL.so

  nvidia-libopencl1: /usr/lib/aarch64-linux-gnu/libOpenCL.so.1
  nvidia-libopencl1: /usr/lib/aarch64-linux-gnu/libOpenCL.so.1.0.0
  ocl-icd-libopencl1: /usr/lib/aarch64-linux-gnu/libOpenCL.so.1
  ocl-icd-libopencl1: /usr/lib/aarch64-linux-gnu/libOpenCL.so.1.0.0
  ocl-icd-opencl-dev: /usr/lib/aarch64-linux-gnu/libOpenCL.so

I.e. I asked it to tell me what package provides a file, and I had to
tell it which architecture to look at.

The whole point of apt-file is to look up the package name from a path,
and if I have to tell IT things like the architecture, it loses a lot of
its utility.

Thanks.

Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages

[Cyril Brulebois]

Hi,

Philip Hands  (2023-05-30):
> Apparently, this MR fixes the problem:
> 
>   https://salsa.debian.org/installer-team/rootskel/-/merge_requests/8
> 
> Although this does prompt the question of why aarch64 has TERM set to
> 'vt102' at this point, rather than 'linux'.

Glancing at the merge request earlier, my first (intertwined) questions
were:

  1. Why is aarch64 special here?
  2. Where does that difference come from?
  3. Which other architectures might be impacted if we were to change
 that?

> Also, I wonder whether there could be other circumstances when $TERM
> is set to 'vt102' where this change could be problematic (I'm guessing
> that the $TERM_TYPE checks deal with that, but I'm not sure).

Yeah, that's the same kind of questions one would get by combined my
second and third questions…



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


signature.asc
Description: PGP signature

Bug#1036953: network-manager-fortisslvpn-gnome: No split tunneling

[Tobias Koeck]

Package: network-manager-fortisslvpn-gnome
Version: 1.4.0-0.1
Severity: normal

Dear Maintainer,

unfortunately it doesn't seem to support split tunneling. Openfortivpn
does seem to support that.

Greetings and thanks,
Tobias

-- System Information:
Debian Release: 12.0
  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/16 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)

Versions of packages network-manager-fortisslvpn-gnome depends on:
ii  libc62.36-9
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libgtk-4-1   4.8.3+ds-2
ii  libnm0   1.42.4-1
ii  libnma-gtk4-01.10.6-1
ii  libnma0  1.10.6-1
ii  libsecret-1-00.20.5-3
ii  network-manager-fortisslvpn  1.4.0-0.1

network-manager-fortisslvpn-gnome recommends no packages.

network-manager-fortisslvpn-gnome suggests no packages.

-- no debconf information

Bug#1036929: mmdebstrap: Feature request: "mmdebstrap --anything-failed-commands '%s'" should exist, like in sbuild

[Dima Kogan]

Johannes Schauer Marin Rodrigues  writes:

> ah I see our main difference might be that I run mmdebstrap mostly
> from other scripts whereas you are running it interactively and thus
> you want a shell if something goes wrong.

I usually run it from scripts too. But if something goes wrong, I re-run
it manually, and having an easy way to get a shell at the failing point
would be nice.


>> > I'd also like to add that you can already emulate this behaviour by
>> > running a hook like this:
>> >
>> > --customize-hook='chroot "$1" i-might-fail || chroot "$1" bash'
>> 
>> I would want to add the '|| chroot "$1" bash' to everything mmdebstrap
>> does: downloading packages, installing them, doing customization hooks,
>> etc, etc. The above just applies to customization hooks, right?
>
> Oh, so you want the interactive shell on other things than failing hooks? You
> also want that shell when any command run by mmdebstrap failed?

Yessir. A shell where the failure is quickly reproduced makes fixing
problems MUCH faster. That's what sbuild does, and I've used this
countless times.


>> The actual failure I'd like to fix today is a failing "apt update"
>> trying to talk to my apt-cacher-ng server (for some reason the server
>> returns 502 only when mmdebstrap tries to talk to it). I don't believe
>> there's a nice way to debug this with mmdebstrap today, right? I tried
>> to use --SOMETHING-hook (don't remember what SOMETHING was), but it
>> wasn't clear what the exact failing command was, so I moved on to
>> something else. Printing the exact failing command for easy
>> reproducibility would be important. Maybe there's already a verbosity
>> level that does this?
>
> The commands should be printed if you increase verbosity with --verbose or 
> even
> with --debug. If the command is not printed, then that is a bug that I will
> fix.

Good to know. I admittedly haven't spent a ton of time working on it.


> For your specific problem I would first try to take mmdebstrap out of the loop
> and see if the problem can be replicated with plain apt as well.

I did that. The problem only shows up with mmdebstrap. I doubt it's a
bug in mmdebstrap, but that's the only place I see this.


> The man page contains a small shell snippet that does the essential things 
> that
> mmdebstrap does but without mmdebstrap in the section OPERATION:
>
> https://manpages.debian.org/unstable/mmdebstrap/mmdebstrap.1.en.html#OPERATION
>
> You could try if that script with your apt-cacher-ng setup produces the same
> error and then you've already reduced the number of moving parts.

I can do that. But fixing this hasn't been very high priority for me
today, so I haven't put in the work. I'm just using this as an example
of a case where the --failure-hook option would be useful.

Thanks much.

Bug#1036952: rootskel: text installs on aarch64 lack glyphs for many languages

[Philip Hands]

Package: rootskel
Version: 1.135
Severity: normal
Tags: patch

Hi,

One can see the symptoms by looking here:

  https://openqa.debian.net/tests/151286

the orange "Soft Failed" boxes highlight some of the failing screens, where the
failure can be seen in the screenshot immediately preceeding the "Soft Failed"

I'll attach an example to save people from having to follow that link.

Apparently, this MR fixes the problem:

  https://salsa.debian.org/installer-team/rootskel/-/merge_requests/8

Although this does prompt the question of why aarch64 has TERM set to 'vt102' at
this point, rather than 'linux'.

Also, I wonder whether there could be other circumstances when $TERM is set to
'vt102' where this change could be problematic (I'm guessing that the $TERM_TYPE
checks deal with that, but I'm not sure).

BTW This seems to have some overlap with #263137.

Cheers, Phil.

Bug#1036891: texlive-binaries: Error "attempt to call method 'read' (a nil value)" makes lualatex unusable

[Salvatore Bonaccorso]

Hi Hilmar,

On Tue, May 30, 2023 at 05:25:33PM +0200, Preuße, Hilmar wrote:
> On 28.05.2023 20:52, Philippe SWARTVAGHER wrote:
> 
> Hello,
> 
> > (not sure if this bug report should be against texlive-luatex or
> > texlive-binaries...)
> > 
> > I upgraded texlive-binaries (and other related packages) from
> > 2018.20181218.49446-1 to 2018.20181218.49446-1+deb10u1 on a Debian
> > Buster. Since then, I cannot use lualatex because of an error.
> > 
> When texlive-luatex is not installed luaotfload complains, but compiling
> does not fail.
> 
> hille@ssoitbmtest:~$ lualatex test.tex
> This is LuaTeX, Version 1.07.0 (TeX Live 2019/dev/Debian)
>  restricted system commands enabled.
> (./test.tex
> LaTeX2e <2018-12-01>
> [\directlua]:1: module 'luaotfload-main' not found:
> no field package.preload['luaotfload-main']
> [kpse lua searcher] file not found: 'luaotfload-main'
> [kpse C searcher] file not found: 'luaotfload-main'
> Error in luaotfload: reverting to OT1
> 
> 
> > Some remarks:
> > - it works as expected with version 2018.20181218.49446-1 (tested by 
> > removing
> >buster/updates from sources.list)
> >
> Did not confirm, but I guess we would have seen that report earlier, if -1
> would be affected.
> 
> > - it works as expected as long as I don't install texlive-luatex
> > 
> Confirmed.
> 
> > - I didn't test with Debian stable / testing / unstable
> > 
> Works fine for stable and testing, so only oldstable (the upcoming
> oldoldstable) is affected.

First I'm relieved to hear it does not affect stable and newer.

> @Salvatore: I'll try to forward that issue to upstream. Will there be
> further point released for buster?

No, buster is under LTS support which does not have point releases.
But as I understand this is a regression from DLA DLA-3427-1, so a
regression update might be worth to be issues for it, once there is a
fix known.

Thus might need to loop in debian-lts list and/or Markus as well.

Does this helps you already for the admnistrativa part?

Regards,
Salvatore

Bug#1035499: crowdsec-custom-bouncer: fails to install with --install-recommends: open /etc/crowdsec/config.yaml: no such file or directory

[Cyril Brulebois]

Hallo Andreas,

Cyril Brulebois  (2023-05-27):
> Andreas Beckmann  (2023-05-04):
> > during a test with piuparts I noticed your package failed to install.
> > As per definition of the release team this makes the package too buggy
> > for a release, thus the severity.
> 
> For some reason, I didn't receive this bug report or the autoremoval
> notification.
> 
> I've just confirmed that requesting the bouncer's installation, in a
> freshly-installed bookworm VM, leads to the same issue. That's something
> that definitely worked when the bouncer was first introduced, I'm not
> exactly sure why that's no longer the case; I'd be happy to have some
> time to gather my thoughts, and upstream's, regarding this issue.

Alright, with RC 4 out of the way, I'm looking at this issue again, and
it seems the “sibling package” crowdsec-firewall-bouncer is affected by
the exact same issue (not surprisingly). I'm curious as to whether it
showed up in those piuparts tests, if you have bug reports yet to be
filed, or something else.

I might just file a report myself later on, I have to find a solution
anyway, and it should be applicable to both packages… but it'd be better
to have a report filed anyway, for documentation purposes. When that
happens, I'm expecting it to be OK to use the same tags as this bug
report… but I've kept Paul in copy to make sure.


Also, thanks for your QA work in general.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1036653: libworkflow0: broken symlink: /usr/lib//libworkflow.so.0.10.6 -> libworkflow.so.0

[Lin Qigang]

Andreas,

Disregard, I see the problem. Bastian Germann has a fix for it and it's 
already added to the next upload.


Lance


GPG Fingerprint: 4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7

On Wed, 31 May 2023 00:49:53 +0700 Lin Qigang  wrote:

> Andreas,
>
> Could you please tell me how you are testing this?
>
> For the salsa CI pipeline, workflow has passed piuparts. It also shows
> "sunny" on the [1] debian piuparts for workflow.
>
> I am unable to reproduce this but how do I fix this so that workflow
> ends up in the stable release?
>
> Best,
>
> Lance
>
> GPG Fingerprint: 4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7
>
> [1] https://piuparts.debian.org/sid/source/w/workflow.html
>
>
> On Tue, 23 May 2023 22:36:53 +0200 Andreas Beckmann  
wrote:

>
> > Package: libworkflow0
> > Version: 0.10.6-1.1
> > Severity: normal
> > User: debian...@lists.debian.org
> > Usertags: piuparts
> > Control: found -1 0.10.5-1
> >
> > Hi,
> >
> > during a test with piuparts I noticed your package ships (or creates)
> > a broken symlink:
> >
> > 0m13.7s ERROR: FAIL: Broken symlinks:
> > /usr/lib/x86_64-linux-gnu/libworkflow.so.0.10.6 -> libworkflow.so.0
> (libworkflow0:amd64)
> >
> > The package does not ship the shared library at all, only the broken
> > link. I haven't checked the source, but my guess is that the symlink
> > gets created in the wrong direction (link source and target swapped),
> > owerwriting the actual library.
> >
> >
> > cheers,
> >
> > Andreas
> >
> >
>



OpenPGP_0x903649294C33F9B7.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005359:

[Jari Kuittinen]

I think I've hit this same bug on another Intel graphics chip:
Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx
Integrated Graphics Controller (rev 36)"

The system worked with bullseye, but does not work with the current state
of bookworm (blank screen after X startup, system reboot required to
restore any graphics functionality outside X as well).

I also tested the bookworm version of xorgserver-xorg-core on a 5.10 kernel
from bullseye, the issue persisted.

Xorg logs of some other reports here mention a rotated fbcon console, just
like my setup, so I also tested without rotated fbcon. No effect.

Downgrading xserver-xorg-core to the bullseye version makes graphics
visible on bookworm again.
[   851.365] 
X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
[   851.365] Build Operating System: linux Debian
[   851.366] Current Operating System: Linux primo 6.1.0-9-686-pae #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) i686
[   851.366] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-686-pae root=UUID=9f58a82d-e87c-4d73-b489-a78aa78da577 ro quiet fbcon=rotate:1
[   851.366] Build Date: 23 March 2023  10:25:56AM
[   851.366] xorg-server 2:1.20.11-1+deb11u6 (https://www.debian.org/support) 
[   851.366] Current version of pixman: 0.42.2
[   851.366] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[   851.366] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   851.367] (==) Log file: "/var/log/Xorg.0.log", Time: Tue May 30 16:59:27 2023
[   851.369] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   851.369] (==) No Layout section.  Using the first Screen section.
[   851.369] (==) No screen section available. Using defaults.
[   851.370] (**) |-->Screen "Default Screen Section" (0)
[   851.370] (**) |   |-->Monitor ""
[   851.371] (==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
[   851.371] (==) Automatically adding devices
[   851.371] (==) Automatically enabling devices
[   851.371] (==) Automatically adding GPU devices
[   851.371] (==) Max clients allowed: 256, resource mask: 0x1f
[   851.376] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   851.376] 	Entry deleted from font path.
[   851.386] (==) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	built-ins
[   851.386] (==) ModulePath set to "/usr/lib/xorg/modules"
[   851.386] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[   851.386] (II) Loader magic: 0x74d740
[   851.386] (II) Module ABI versions:
[   851.386] 	X.Org ANSI C Emulation: 0.4
[   851.386] 	X.Org Video Driver: 24.1
[   851.386] 	X.Org XInput driver : 24.1
[   851.386] 	X.Org Server Extension : 10.0
[   851.393] (++) using VT number 7

[   851.394] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration
[   851.399] (II) xfree86: Adding drm device (/dev/dri/card0)
[   851.429] (--) PCI:*(0@0:2:0) 8086:22b0:8086:7270 rev 54, Mem @ 0x9000/16777216, 0x8000/268435456, I/O @ 0x1000/64, BIOS @ 0x/131072
[   851.429] (II) LoadModule: "glx"
[   851.431] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[   851.459] (II) Module glx: vendor="X.Org Foundation"
[   851.459] 	compiled for 1.20.11, module version = 1.0.0
[   851.460] 	ABI class: X.Org Server Extension, version 10.0
[   851.460] (==) Matched modesetting as autoconfigured driver 0
[   851.460] (==) Matched fbdev as autoconfigured driver 1
[   851.460] (==) Matched vesa as autoconfigured driver 2
[   851.460] (==) Assigned the driver to the xf86ConfigLayout
[   851.460] (II) LoadModule: "modesetting"
[   851.461] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[   851.463] (II) Module modesetting: vendor="X.Org Foundation"
[   851.463] 	compiled for 1.20.11, module version = 1.20.11
[   851.463] 	Module class: X.Org Video Driver
[   851.463] 	ABI class: X.Org Video Driver, version 24.1
[   851.464] (II) LoadModule: "fbdev"
[   851.466] (WW) Warning, couldn't open module fbdev
[   851.466] (EE) Failed to load module "fbdev" (module does not exist, 0)
[   851.466] (II) LoadModule: "vesa"
[   851.468] (WW) Warning, couldn't open module vesa
[   851.468] (EE) Failed to load module "vesa" (module does not exist, 0)
[   851.468] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[   851.492] (II) modeset(0): using drv /dev/dri/card0
[   851.493] (II) modeset(0): Creating default Display subsection in Screen section
	"Default Screen Section" for 

Bug#1036653: libworkflow0: broken symlink: /usr/lib//libworkflow.so.0.10.6 -> libworkflow.so.0

[Lin Qigang]

Andreas,

Could you please tell me how you are testing this?

For the salsa CI pipeline, workflow has passed piuparts. It also shows 
"sunny" on the [1] debian piuparts for workflow.


I am unable to reproduce this but how do I fix this so that workflow 
ends up in the stable release?


Best,

Lance

GPG Fingerprint: 4A31 DB5A 1EE4 096C 8739 9880 9036 4929 4C33 F9B7

[1] https://piuparts.debian.org/sid/source/w/workflow.html


On Tue, 23 May 2023 22:36:53 +0200 Andreas Beckmann  wrote:

> Package: libworkflow0
> Version: 0.10.6-1.1
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: found -1 0.10.5-1
>
> Hi,
>
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink:
>
> 0m13.7s ERROR: FAIL: Broken symlinks:
> /usr/lib/x86_64-linux-gnu/libworkflow.so.0.10.6 -> libworkflow.so.0 
(libworkflow0:amd64)

>
> The package does not ship the shared library at all, only the broken
> link. I haven't checked the source, but my guess is that the symlink
> gets created in the wrong direction (link source and target swapped),
> owerwriting the actual library.
>
>
> cheers,
>
> Andreas
>
>



OpenPGP_0x903649294C33F9B7.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036951: ITP: bitsnpicas -- Bitmap & Emoji font creation & conversion tools

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: bitsnpicas
  Version : 2.0+ds
  Upstream Authors: Rebecca G. Bettencourt
  URL : https://github.com/kreativekorp/bitsnpicas
* License : MPL-1.1
  Description : Bitmap & Emoji font creation & conversion tools
 This is a set of tools for creating and converting bitmap and emoji 
fonts.
 Bitmap font functions can be accessed both with a GUI and from a 
command

 line. Emoji font functions can only be accessed from a command line.

Will be Font team maintained...

Bug#1036950: schleuder: fails to upgrade from 'buster': fails during apt-get upgrade

[Andreas Beckmann]

Package: schleuder
Version: 3.6.0-3+deb11u1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'buster'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails.

Note that this failure only occurs during a 2-stage upgrade
(apt-get upgrade && apt-get distupgrade) in the apt-get upgrade step,
while a single-stage upgrade (only apt-get dist-upgrade) works fine.

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

  Setting up schleuder (3.6.0-3+deb11u1) ...
  Installing new version of config file /etc/schleuder/list-defaults.yml ...
  dpkg: error processing package schleuder (--configure):
   installed schleuder package post-installation script subprocess returned 
error exit status 1

I tried injecting 'set -x' into the postinst, but the output is not very
helpful:

Setting up schleuder (3.6.0-3+deb11u1) ...
+ set -e
+ id schleuder
+ chown schleuder /etc/schleuder
+ chown root:schleuder /etc/schleuder/schleuder.yml 
/etc/schleuder/list-defaults.yml
+ chmod 0640 /etc/schleuder/schleuder.yml /etc/schleuder/list-defaults.yml
+ chmod 0750 /var/lib/schleuder /var/log/schleuder
+ chown schleuder:schleuder /var/lib/schleuder /var/log/schleuder
+ [ -z 3.4.0-2+deb10u3 ]
+ dpkg --compare-versions 3.4.0-2+deb10u3 lt 3.0
+ SCHEMA=SCHEMA=/dev/null
+ runuser -u schleuder -- sh -c SCHEMA=/dev/null schleuder install >/dev/null
dpkg: error processing package schleuder (--configure):
 installed schleuder package post-installation script subprocess returned error 
exit status 1
Errors were encountered while processing:
 schleuder

Entering the chroot after the failure and runnign 
  runuser -u schleuder -- sh -c 'SCHEMA=/dev/null schleuder install'
does not give any output either.

My guess is that there is some insufficiently versioned dependency that
has not yet been upgraded during 'apt-get upgrade' is required for this
comand to succeed.


cheers,

Andreas


schleuder_3.6.0-3+deb11u1.log.gz
Description: application/gzip

Bug#1036949: systemd-networkd.service fails with Assertion 'a' failed at src/network/networkd-address.c:1868, function address_is_ready(). Aborting.

[Volker Theile]

Package: systemd
Version: 247.3-7+deb11u2
Severity: important

Hello,

systemd-networkd is crashing with the error message

systemd-networkd.service fails with Assertion 'a' failed at 
src/network/networkd-address.c:1868, function address_is_ready(). Aborting.

It can be forced into a running state by running "systemctl restart 
systemd-networkd.service" several times.

The following information can be provided to reproduce the issue.

OS: Debian 11
systemd version: 247 (247.3-7+deb11u2)
Linux kernel version used: 6.1.0-0.deb11.7-amd64
CPU architecture: x86_64

The following error is reported in syslog/journal:

May 30 17:28:13 omv6box systemd[1]: Starting Network Service...
May 30 17:28:13 omv6box systemd-networkd[10005]: bond0: netdev ready
May 30 17:28:13 omv6box systemd-networkd[10005]: vethcdaf262a: Gained IPv6LL
May 30 17:28:13 omv6box systemd-networkd[10005]: veth2a72a113: Gained IPv6LL
May 30 17:28:13 omv6box systemd-networkd[10005]: Enumeration completed
May 30 17:28:13 omv6box systemd[1]: Started Network Service.
May 30 17:28:13 omv6box systemd-networkd[10005]: bond0: netdev exists, using 
existing without changing its parameters
May 30 17:28:13 omv6box systemd-networkd[10005]: bond0: DHCPv4 address 
192.172.16.165/24 via 192.172.16.1
May 30 17:28:13 omv6box systemd-networkd[10005]: ens6: DHCPv4 address 
192.168.121.219/24 via 192.168.121.1
May 30 17:28:13 omv6box systemd-networkd[10005]: Assertion 'a' failed at 
src/network/networkd-address.c:1868, function address_is_ready(). Aborting.
May 30 17:28:13 omv6box systemd[1]: systemd-networkd.service: Main process 
exited, code=killed, status=6/ABRT
May 30 17:28:13 omv6box systemd[1]: systemd-networkd.service: Failed with 
result 'signal'.
May 30 17:28:13 omv6box systemd[1]: systemd-networkd.service: Scheduled restart 
job, restart counter is at 1.
May 30 17:28:13 omv6box systemd[1]: Stopped Network Service.
May 30 17:28:13 omv6box systemd[1]: Starting Network Service...
May 30 17:28:13 omv6box systemd-networkd[10007]: bond0: netdev ready
May 30 17:28:13 omv6box systemd-networkd[10007]: vethcdaf262a: Gained IPv6LL
May 30 17:28:13 omv6box systemd-networkd[10007]: veth2a72a113: Gained IPv6LL
May 30 17:28:13 omv6box systemd-networkd[10007]: Enumeration completed
May 30 17:28:13 omv6box systemd[1]: Started Network Service.
May 30 17:28:13 omv6box systemd-networkd[10007]: bond0: netdev exists, using 
existing without changing its parameters
May 30 17:28:13 omv6box systemd-networkd[10007]: bond0: DHCPv4 address 
192.172.16.165/24 via 192.172.16.1
May 30 17:28:13 omv6box systemd-networkd[10007]: Assertion 'a' failed at 
src/network/networkd-address.c:1868, function address_is_ready(). Aborting.
May 30 17:28:13 omv6box systemd[1]: systemd-networkd.service: Main process 
exited, code=killed, status=6/ABRT
May 30 17:28:13 omv6box systemd[1]: systemd-networkd.service: Failed with 
result 'signal'.
May 30 17:28:13 omv6box systemd[1]: systemd-networkd.service: Scheduled restart 
job, restart counter is at 2.
May 30 17:28:13 omv6box systemd[1]: Stopped Network Service.
May 30 17:28:13 omv6box systemd[1]: Starting Network Service...
May 30 17:28:13 omv6box systemd-networkd[10008]: bond0: netdev ready
May 30 17:28:13 omv6box systemd-networkd[10008]: vethcdaf262a: Gained IPv6LL
May 30 17:28:13 omv6box systemd-networkd[10008]: veth2a72a113: Gained IPv6LL
May 30 17:28:13 omv6box systemd-networkd[10008]: Enumeration completed
May 30 17:28:13 omv6box systemd[1]: Started Network Service.
May 30 17:28:13 omv6box systemd-networkd[10008]: bond0: netdev exists, using 
existing without changing its parameters
May 30 17:28:13 omv6box systemd-networkd[10008]: bond0: DHCPv4 address 
192.172.16.165/24 via 192.172.16.1
May 30 17:28:13 omv6box systemd-networkd[10008]: ens6: DHCPv4 address 
192.168.121.219/24 via 192.168.121.1
May 30 17:28:13 omv6box systemd-networkd[10008]: Assertion 'a' failed at 
src/network/networkd-address.c:1868, function address_is_ready(). Aborting.
May 30 17:28:13 omv6box systemd[1]: systemd-networkd.service: Main process 
exited, code=killed, status=6/ABRT
May 30 17:28:13 omv6box systemd[1]: systemd-networkd.service: Failed with 
result 'signal'.
May 30 17:28:13 omv6box systemd[1]: systemd-networkd.service: Scheduled restart 
job, restart counter is at 3.
May 30 17:28:13 omv6box systemd[1]: Stopped Network Service.
May 30 17:28:13 omv6box systemd[1]: Starting Network Service...
May 30 17:28:13 omv6box systemd-networkd[10014]: bond0: netdev ready
May 30 17:28:13 omv6box systemd-networkd[10014]: vethcdaf262a: Gained IPv6LL
May 30 17:28:13 omv6box systemd-networkd[10014]: veth2a72a113: Gained IPv6LL
May 30 17:28:13 omv6box systemd-networkd[10014]: Enumeration completed
May 30 17:28:13 omv6box systemd[1]: Started Network Service.
May 30 17:28:13 omv6box systemd-networkd[10014]: bond0: netdev exists, using 
existing without changing its parameters
May 30 17:28:13 omv6box systemd-networkd[10014]: bond0: DHCPv4 address 
192.172.16.165/24 via 192.172.16.1
May 30 

Bug#967994: CVE-2019-14560 fixed at last

[Lionel Élie Mamane]

This looks like it has at last been fixed upstream on 23 March 2023,
which looks more recent than even Debian experimental has.

Bug#1036948: edk2: please configure a grub menu entry for efi-shell-ARCH

[Lionel Mamane]

Source: edk2
Version: 2023.02-2
Severity: wishlist
Tags: patch

Dear Maintainer,

On installation of an architecture-appropriate efi-shell-XXX package,
please copy the shell into the EFI partition and configure grub2 to
have a boot menu entry to enter that shell.

I attach an example grup config file for aarch64, which works if
dropped into /etc/grub.d/35_efi-shell-aarch64 and the shell has been
installed as /boot/efi/EFI/tianocore/shellaa64.efi

The architecture test in the grub config file is probably not exactly
the best one; feel free to improve so that it works when running e.g.
an armfh or 32-bit arm Debian port on an aarch64-able machine.

For other architectures, adapt the architecture test. Maybe you can
generate the file for each architecture from a template where the only
change is the architecture test.

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (600, 'testing-security'), (600, 'testing'), (500, 'unstable'), 
(1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 6.2.0 (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_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
#! /bin/sh
set -e

# grub-mkconfig helper script.
# Copyright (C) 2020  Free Software Foundation, Inc.
#
# GRUB is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# GRUB is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GRUB.  If not, see .

prefix="/usr"
exec_prefix="/usr"
datarootdir="/usr/share"

export TEXTDOMAIN=grub
export TEXTDOMAINDIR="${datarootdir}/locale"

. "$pkgdatadir/grub-mkconfig_lib"

EFI_MNTPNT=/boot/efi
EFI_DEV="`"${grub_probe}" -t device \"${EFI_MNTPNT}\"`"
EFI_PATH=EFI/tianocore
SHELL_FNAME=shellaa64.efi
EFI_VARS_DIR=/sys/firmware/efi/efivars
EFI_GLOBAL_VARIABLE=8be4df61-93ca-11d2-aa0d-00e098032b8c
OS_INDICATIONS="$EFI_VARS_DIR/OsIndicationsSupported-$EFI_GLOBAL_VARIABLE"

if [ "`arch`" = aarch64 ] && \
   [ -f "${EFI_MNTPNT}/${EFI_PATH}/${SHELL_FNAME}" ]; then

  LABEL="TianoCore EFI shell"

  gettext_printf "Adding boot menu entry for TianoCore EFI shell ...\n" >&2

  cat << EOF
menuentry '$LABEL' \$menuentry_id_option 'tianocore-efishell' {
`prepare_grub_to_access_device "${EFI_DEV}" | grub_add_tab`
chainloader /${EFI_PATH}/${SHELL_FNAME}
boot
}
EOF
fi

Bug#1036947: whipper: Whipper does not work when syncthing-gtk is also installed

[Ben Morris]

Package: whipper
Version: 0.10.0-2+b3
Severity: important

Dear Maintainer,

Whipper exits with the following messages:

Traceback (most recent call last):
  File "/usr/bin/whipper", line 33, in 
sys.exit(load_entry_point('whipper==0.10.0', 'console_scripts', 
'whipper')())
 ^^^
  File "/usr/lib/python3/dist-packages/whipper/command/main.py", line 50, in 
main
distributions, _ = pkg_resources.working_set.find_plugins(
   ^^^
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 907, in 
find_plugins
env = Environment(self.entries)
  ^
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1044, 
in __init__
self.scan(search_path)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1077, 
in scan
self.add(dist)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1096, 
in add
dists.sort(key=operator.attrgetter('hashcmp'), reverse=True)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2631, 
in hashcmp
self.parsed_version,
^^^
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2679, 
in parsed_version
self._parsed_version = parse_version(self.version)
   ^^^
  File 
"/usr/lib/python3/dist-packages/pkg_resources/_vendor/packaging/version.py", 
line 266, in __init__
raise InvalidVersion(f"Invalid version: '{version}'")
pkg_resources.extern.packaging.version.InvalidVersion: Invalid version: 
'v0.9.4.4-ds-git20221205-12a9702d29ab'
(package: syncthing-gtk)

Uninstalling syncthing-gtk allows whipper to work correctly.



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

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

Versions of packages whipper depends on:
ii  cd-paranoia 10.2+2.0.1-1
ii  cdrdao  1:1.2.4-3
ii  flac1.4.2+ds-2
ii  libc6   2.36-9
ii  libsndfile1 1.2.0-1
ii  python3 3.11.2-1+b1
ii  python3-cdio2.1.1-1+b4
ii  python3-distutils   3.11.2-3
ii  python3-gi  3.42.2-3+b1
ii  python3-libdiscid   2.0.2-1+b2
ii  python3-musicbrainzngs  0.7.1-4
ii  python3-mutagen 1.46.0-1
ii  python3-pil 9.4.0-1.1+b1
ii  python3-requests2.28.1+dfsg-1
ii  python3-ruamel.yaml 0.17.21-1
ii  sox 14.4.2+git20190427-3.5

whipper recommends no packages.

whipper suggests no packages.

-- debconf-show failed

Bug#1036891: texlive-binaries: Error "attempt to call method 'read' (a nil value)" makes lualatex unusable

[Preuße]

On 28.05.2023 20:52, Philippe SWARTVAGHER wrote:

Hello,


(not sure if this bug report should be against texlive-luatex or
texlive-binaries...)

I upgraded texlive-binaries (and other related packages) from
2018.20181218.49446-1 to 2018.20181218.49446-1+deb10u1 on a Debian
Buster. Since then, I cannot use lualatex because of an error.

When texlive-luatex is not installed luaotfload complains, but compiling 
does not fail.


hille@ssoitbmtest:~$ lualatex test.tex
This is LuaTeX, Version 1.07.0 (TeX Live 2019/dev/Debian)
 restricted system commands enabled.
(./test.tex
LaTeX2e <2018-12-01>
[\directlua]:1: module 'luaotfload-main' not found:
no field package.preload['luaotfload-main']
[kpse lua searcher] file not found: 'luaotfload-main'
[kpse C searcher] file not found: 'luaotfload-main'
Error in luaotfload: reverting to OT1



Some remarks:
- it works as expected with version 2018.20181218.49446-1 (tested by removing
   buster/updates from sources.list)

>
Did not confirm, but I guess we would have seen that report earlier, if 
-1 would be affected.



- it works as expected as long as I don't install texlive-luatex


Confirmed.


- I didn't test with Debian stable / testing / unstable

Works fine for stable and testing, so only oldstable (the upcoming 
oldoldstable) is affected.


@Salvatore: I'll try to forward that issue to upstream. Will there be 
further point released for buster?


Hilmar
--
sigfault



OpenPGP_0x0C871C4C653C1F59.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024523: yad packaging

[Bastian Germann]

Hi Alexis,

To get the ball rolling I went ahead with importing the 7.2 release into 
experimental.
Please hand in an unstable upload when the bookworm release is done.

Thanks,
Bastian

Bug#1036213: apache2: More infos for this bug

[Fabien LE BERRE]

Hi,

this setup does not run mod_proxy_http2. Only mod_http2 was enabled.
Semantic is quite important as CPU Usage isn't really "load average", but I
will just give you a link for the "load average" question which will
explain it better than I will ever do ;) :
https://en.wikipedia.org/wiki/Load_(computing)

We do have a varnish behind apache with KeepAlive being disabled. So it
might be related to this application behind apache as well, not surprised
as the previous "segfault" bug I was refering to, was noticed on maybe 3 or
4 servers, while we manage hundreds of them, so it might be dependant to
how they handle connections/pipe...
I'm asking, just in case is keepalive necessary with http2 ?

Regards,
Fabien

Le mar. 30 mai 2023 à 16:25, 'Stefan Eissing' via Sysadmin <
sysad...@dutiko.com> a écrit :

> Thanks for the information.
>
> Does this setup also run mod_proxy_http2? (I am investigating issue in
> that module that I can somewhat reproduce)
> What measurement is the "load average" you mentioned? CPU usage?
>
> As to the observed log entries, these appear when a client connection is
> terminated and the HTTP/2 processing waits on running H2 workers to react
> to an abort and stop processing. All stream (e.g. running workers) that do
> not return after 60 seconds are logged and the waiting continues. After
> another 60 seconds all remaining are logged again and so on.
>
> So if these entries for a particular connection (you see in the
> "h2_stream(3805413-327-1" that it is in process 3805413 connection 327 and
> stream id 1)
> continue to be logged every minute, this points to a server mistake. If
> the logging of such stream stops eventually, this points to badly reacting
> request processing and it is the question what is running in your server
> that takes this long to finish/react to an aborted connection).
>
> For example, if you proxy a backend with very long timeout and that
> backend does not respond, these entries may happen.
>
> tl;dr
>
> The log entries could be a server bug, but as well a matter of
> configuration.
>
> Kind Regards,
> Stefan
>
> > Am 30.05.2023 um 11:42 schrieb root :
> >
> > Package: apache2
> > Version: 2.4.56-1~deb11u2
> > Followup-For: Bug #1036213
> >
> >
> > I have additional information that might be related to this bug.
> > It seems to be following the previous bug I opened in Bug#1033408 ,
> > which is now solved since 2.4.56-1~deb11u2, but now we don't have
> > segfaults anymore, but the server of our customer is having a load
> average
> > increasing since we've updated the package, we've tested for a week and
> > load average went from around 5, to 35, slowly increasing over the week
> > to this value, and it would probably have increased more if we hadn't
> > intervene.
> >
> > After witnessing this behavior I noticed these logs in error logs which
> > I had never seen before:
> > [...]
> > [Tue May 30 08:59:29.873462 2023] [http2:warn] [pid 3805413:tid
> 140434122716928] [client 81.204.51.61:56550]
> h2_stream(3805413-327-1,CLEANUP): started=1, scheduled=1, ready=0,
> out_buffer=0
> > [Tue May 30 08:59:29.873486 2023] [http2:warn] [pid 3805413:tid
> 140434122716928] [client 81.204.51.61:56550]
> h2_stream(3805413-327-5,CLEANUP): started=1, scheduled=1, ready=0,
> out_buffer=0
> > [Tue May 30 08:59:29.873490 2023] [http2:warn] [pid 3805413:tid
> 140434122716928] [client 81.204.51.61:56550]
> h2_stream(3805413-327-9,CLEANUP): started=1, scheduled=1, ready=0,
> out_buffer=0
> > [Tue May 30 09:07:11.128774 2023] [http2:warn] [pid 3808854:tid
> 140434047182592] [client 106.245.192.226:56994]
> h2_stream(3808854-230-1,CLEANUP): started=1, scheduled=1, ready=0,
> out_buffer=0
> > [Tue May 30 09:07:11.128793 2023] [http2:warn] [pid 3808854:tid
> 140434047182592] [client 106.245.192.226:56994]
> h2_stream(3808854-230-5,CLEANUP): started=1, scheduled=1, ready=0,
> out_buffer=0
> > [Tue May 30 09:13:36.366838 2023] [http2:warn] [pid 3811558:tid
> 140434114324224] [client 51.179.98.234:49225]
> h2_stream(3811558-357-17,CLEANUP): started=1, scheduled=1, ready=0,
> out_buffer=0
> > [Tue May 30 09:13:36.366874 2023] [http2:warn] [pid 3811558:tid
> 140434114324224] [client 51.179.98.234:49225]
> h2_stream(3811558-357-19,CLEANUP): started=1, scheduled=1, ready=0,
> out_buffer=0
> > [Tue May 30 09:55:14.468946 2023] [http2:warn] [pid 3832829:tid
> 140434089146112] [client 109.234.73.147:53640]
> h2_stream(3832829-35-5,CLEANUP): started=1, scheduled=1, ready=0,
> out_buffer=0
> > [Tue May 30 09:56:14.469032 2023] [http2:warn] [pid 3832829:tid
> 140434089146112] [client 109.234.73.147:53640]
> h2_stream(3832829-35-5,CLEANUP): started=1, scheduled=1, ready=0,
> out_buffer=0
> > [...]
> >
> > After noticing these, I immediately thought about the previous bug and
> > completely disabled the http2 module in apache. It immediately solved
> > the load issue.
> > I know it's very few information and I'm not sure it's related exactly
> > to his particular bug, might need a bug report 

Bug#1036806: matrix-synapse: not suitable for inclusion in bookworm

[Andrej Shadura]

Hi Salvatore,

On Tue, 30 May 2023, at 16:24, Salvatore Bonaccorso wrote:
> Did you got already a reply from upstream?
>
> As discussed face to face, if we start shipping with it in bookworm
> but relatively early would need to remove it, the impact is higher,
> because people already starting to rely on it.
>
> Thus beeing unsure, I would err on the safe sid. Clarify it early in
> the trixie release cycle with upstream and potentially target trixie
> for inclusion.
>
> The removal from testing would need to happen before the quiet phase
> starts in some days.

I talked to them, they said they’d not backport patches themselves. I asked if 
they could help with code reviews etc and there was no answer so far (but 
yesterday was a bank holiday in the UK).

Rethinking how much I can realistically spend on it given my commitments 
outside Debian, I’m not sure I want to take up another one.

Let’s keep Synapse out for now.

-- 
Cheers,
  Andrej

Bug#1036806: matrix-synapse: not suitable for inclusion in bookworm

[Salvatore Bonaccorso]

Hi Andrej,

On Sun, May 28, 2023 at 02:17:36PM +0200, Salvatore Bonaccorso wrote:
> Hi
> 
> For those following the bugreport:
> 
> On Fri, May 26, 2023 at 09:19:59PM +0200, Salvatore Bonaccorso wrote:
> > Hi Andrej,
> > 
> > On Fri, May 26, 2023 at 08:51:13PM +0200, Andrej Shadura wrote:
> > > Hi,
> > > 
> > > On Fri, 26 May 2023, at 19:28, Salvatore Bonaccorso wrote:
> > > > I believe matrix-synapse is still in the same status as for #982991
> > > > back for the bullseye release, and not suitable to be included in
> > > > bookworm as stable release.
> > > 
> > > In fact, I believe the situation has changed. Synapse it much more
> > > stable, as is the Matrix protocol itself, and there weren’t that
> > > many security issues.
> > 
> > For reference for the discussion: So there were at least the following
> > CVEs I think since the removal (maybe more, this is just rought
> > checking based on the CVE years):
> > 
> > https://security-tracker.debian.org/tracker/CVE-2023-32323
> > https://security-tracker.debian.org/tracker/CVE-2022-41952
> > https://security-tracker.debian.org/tracker/CVE-2022-39374
> > https://security-tracker.debian.org/tracker/CVE-2022-39335
> > https://security-tracker.debian.org/tracker/CVE-2022-31152
> > https://security-tracker.debian.org/tracker/CVE-2022-31052
> > 
> > > > As such let it have removed from bookworm if you agree. If this is not
> > > > correct, we need to have assurance security fixes arising during the
> > > > bookworm cycle can be addressed.
> > > 
> > > I believe I will be able to backport fixes — or ask for removal
> > > later if and when the need arises.
> > 
> > For the above CVEs, would have the fixes be isolated and backportable
> > enough to guarantee that? If so and you are confident you will be able
> > to backport the fixes, then please go ahead with closing this bug.
> > 
> > Personally I just would like to avoid we release bookworm with it, and
> > after while we have already to go trought the removal request from
> > stable.
> 
> Andrej checking on the above. If it's deemed feasible we will give it
> a go.
> 
> Ideally though we should remove id now before the release if it's
> unfeasable to maintain, because otheweise there are higher
> expectations if it's in the initial release.
> 
> A removal needs to be requested directly as respective bug to the
> release team, as autoremovals will likely not trigger right now for
> this case.
> 
> Andrej, do yu have already some information?

Did you got already a reply from upstream?

As discussed face to face, if we start shipping with it in bookworm
but relatively early would need to remove it, the impact is higher,
because people already starting to rely on it.

Thus beeing unsure, I would err on the safe sid. Clarify it early in
the trixie release cycle with upstream and potentially target trixie
for inclusion.

The removal from testing would need to happen before the quiet phase
starts in some days.

What do you think?

Regards,
Salvatore

Bug#1036213: apache2: More infos for this bug

[Stefan Eissing]

Thanks for the information. 

Does this setup also run mod_proxy_http2? (I am investigating issue in that 
module that I can somewhat reproduce)
What measurement is the "load average" you mentioned? CPU usage?

As to the observed log entries, these appear when a client connection is 
terminated and the HTTP/2 processing waits on running H2 workers to react to an 
abort and stop processing. All stream (e.g. running workers) that do not return 
after 60 seconds are logged and the waiting continues. After another 60 seconds 
all remaining are logged again and so on.

So if these entries for a particular connection (you see in the 
"h2_stream(3805413-327-1" that it is in process 3805413 connection 327 and 
stream id 1)
continue to be logged every minute, this points to a server mistake. If the 
logging of such stream stops eventually, this points to badly reacting request 
processing and it is the question what is running in your server that takes 
this long to finish/react to an aborted connection).

For example, if you proxy a backend with very long timeout and that backend 
does not respond, these entries may happen.

tl;dr

The log entries could be a server bug, but as well a matter of configuration. 

Kind Regards,
Stefan

> Am 30.05.2023 um 11:42 schrieb root :
> 
> Package: apache2
> Version: 2.4.56-1~deb11u2
> Followup-For: Bug #1036213
> 
> 
> I have additional information that might be related to this bug.
> It seems to be following the previous bug I opened in Bug#1033408 ,
> which is now solved since 2.4.56-1~deb11u2, but now we don't have
> segfaults anymore, but the server of our customer is having a load average
> increasing since we've updated the package, we've tested for a week and
> load average went from around 5, to 35, slowly increasing over the week
> to this value, and it would probably have increased more if we hadn't
> intervene.
> 
> After witnessing this behavior I noticed these logs in error logs which
> I had never seen before:
> [...]
> [Tue May 30 08:59:29.873462 2023] [http2:warn] [pid 3805413:tid 
> 140434122716928] [client 81.204.51.61:56550] 
> h2_stream(3805413-327-1,CLEANUP): started=1, scheduled=1, ready=0, 
> out_buffer=0
> [Tue May 30 08:59:29.873486 2023] [http2:warn] [pid 3805413:tid 
> 140434122716928] [client 81.204.51.61:56550] 
> h2_stream(3805413-327-5,CLEANUP): started=1, scheduled=1, ready=0, 
> out_buffer=0
> [Tue May 30 08:59:29.873490 2023] [http2:warn] [pid 3805413:tid 
> 140434122716928] [client 81.204.51.61:56550] 
> h2_stream(3805413-327-9,CLEANUP): started=1, scheduled=1, ready=0, 
> out_buffer=0
> [Tue May 30 09:07:11.128774 2023] [http2:warn] [pid 3808854:tid 
> 140434047182592] [client 106.245.192.226:56994] 
> h2_stream(3808854-230-1,CLEANUP): started=1, scheduled=1, ready=0, 
> out_buffer=0
> [Tue May 30 09:07:11.128793 2023] [http2:warn] [pid 3808854:tid 
> 140434047182592] [client 106.245.192.226:56994] 
> h2_stream(3808854-230-5,CLEANUP): started=1, scheduled=1, ready=0, 
> out_buffer=0
> [Tue May 30 09:13:36.366838 2023] [http2:warn] [pid 3811558:tid 
> 140434114324224] [client 51.179.98.234:49225] 
> h2_stream(3811558-357-17,CLEANUP): started=1, scheduled=1, ready=0, 
> out_buffer=0
> [Tue May 30 09:13:36.366874 2023] [http2:warn] [pid 3811558:tid 
> 140434114324224] [client 51.179.98.234:49225] 
> h2_stream(3811558-357-19,CLEANUP): started=1, scheduled=1, ready=0, 
> out_buffer=0
> [Tue May 30 09:55:14.468946 2023] [http2:warn] [pid 3832829:tid 
> 140434089146112] [client 109.234.73.147:53640] 
> h2_stream(3832829-35-5,CLEANUP): started=1, scheduled=1, ready=0, out_buffer=0
> [Tue May 30 09:56:14.469032 2023] [http2:warn] [pid 3832829:tid 
> 140434089146112] [client 109.234.73.147:53640] 
> h2_stream(3832829-35-5,CLEANUP): started=1, scheduled=1, ready=0, out_buffer=0
> [...]
> 
> After noticing these, I immediately thought about the previous bug and
> completely disabled the http2 module in apache. It immediately solved
> the load issue.
> I know it's very few information and I'm not sure it's related exactly
> to his particular bug, might need a bug report of its own, but in case,
> I don't want to duplicate and will let you choose.
> 
> 
> 
> -- Package-specific info:
> 
> -- System Information:
> Debian Release: 11.7
>  APT prefers stable-updates
>  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
> 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-18-amd64 (SMP w/32 CPU threads)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages apache2 depends on:
> ii  apache2-bin  2.4.56-1~deb11u2
> ii  apache2-data 2.4.56-1~deb11u2
> ii  apache2-utils2.4.56-1~deb11u2
> ii  dpkg 1.20.12
> ii  init-system-helpers  1.60
> ii  lsb-base 11.1.0
> ii  mime-support 3.66
> ii  perl

Bug#1036920: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]

[Luca Boccassi]

On Tue, 30 May 2023 at 14:09, Helmut Grohne  wrote:
>
> Hi Luca,
>
> On Tue, May 30, 2023 at 11:23:07AM +0100, Luca Boccassi wrote:
> > > > - unmerged-usr paths are no longer supported
> > >
> > > Then you argue that this bug would affect only unmerged systems, while
> > > it actually is in reverse. Unmerged systems are unaffected by this bug
> > > class. The deletion that Andreas describes can only happen due to the
> > > aliasing introduced by merging. This bug class only affects merged
> > > systems.
> >
> > No, this bug report only affects unmerged systems and has no effect on
> > merged ones, as the actual bug after the analysis and discussion is
> > that some packages since Bullseye install modules-load.d/ files in the
> > wrong directory, that nothing actually reads (since Bullseye!),
> > effectively making them useless, but nobody ever noticed, and I can
> > only speculate that this could be due to the fact that the vast
> > majority of systems have been merged and thus there's no difference
> > (alternatively it could be that such packages have extremely low
> > popcon, I have not checked). If these packages were used on unmerged
> > system, these bugs would be very real - the functionality they provide
> > would be broken.
>
> Given that we are saying exactly the opposite of each other, it seems
> likely that we are talking about different things (thanks to that kind
> soul pointing it out to me).
>
> As I read your reply, it seems to me that you see the bug in
> multipath-tools and other packages that ship files in
> /lib/modules-load.d as opposed to /usr/lib/modules-load.d. Assuming
> that's your view, what you write very much makes sense - including the
> assertion that it only affects unmerged systems. Do you confirm? If you
> confirm, I'd see what you see as the bug we are talking about as not an
> issue in systemd at all, but as multiple issues in other packages (such
> as multipath-tools) that fail at integrating properly with systemd (when
> unmerged, which is unsupported, so not worth fixing in bookworm). Given
> that the bug at hand is filed against systemd (rather than
> multipath-tools), it did not occur to me earlier that you were having
> this problem in mind.

Yes, that's exactly right - this behaviour was changed a long time ago
(for Bullseye) as mentioned earlier in the thread:

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

so it could of course be changed back so that files in /lib are picked
up instead - but as mentioned, I don't think it's worth it, especially
not this late. Packages installed in unmerged Bullseye shipping files
in /lib/modules-load.d have been buggy ever since, and on a merged
system it's just a cosmetic issue. This is (was) a severity serious
bug against src:systemd and that's how I approached it.

> As I understand what Andreas wrote (maybe he can confirm), the problem
> he sees is that /usr/lib/modules-load.d (the directory) disappears when
> removing other packages such as multipath-tools. So it's very much not
> about whether systemd deals with the dropins placed by multipath-tools.
> It's about removal of a package having unintended side-effects (removing
> a directory still owned by systemd). And this very problem, can only be
> experienced on merged /usr. The absence of a directory may not seem like
> a big deal to you and none of us seems convinced that it has a
> practically relevant impact on using systemd, but it very much has an
> impact on piuparts and testing migration and that - to me - is what this
> bug report has been about.
>
> Does that make more sense to you now?

Yes, that makes sense. However I don't think it needs to be a release
blocker? AFAIK there are no load-modules.d/ migrations left to do for
bookworm, and we can make sure piuparts is happy in trixie. Do you see
any reason why this should be a release blocker?

Kind regards,
Luca Boccassi

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

[Alexandru Mihail]

Hello again, I have reuploaded mini-httpd to mentors as per your 
recommandations Nicholas. Please see my last mail for some questions regarding 
upstream/VCS.

Regards,
Alexandru Mihail

Bug#1036920: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]

[Helmut Grohne]

Hi Luca,

On Tue, May 30, 2023 at 11:23:07AM +0100, Luca Boccassi wrote:
> > > - unmerged-usr paths are no longer supported
> >
> > Then you argue that this bug would affect only unmerged systems, while
> > it actually is in reverse. Unmerged systems are unaffected by this bug
> > class. The deletion that Andreas describes can only happen due to the
> > aliasing introduced by merging. This bug class only affects merged
> > systems.
> 
> No, this bug report only affects unmerged systems and has no effect on
> merged ones, as the actual bug after the analysis and discussion is
> that some packages since Bullseye install modules-load.d/ files in the
> wrong directory, that nothing actually reads (since Bullseye!),
> effectively making them useless, but nobody ever noticed, and I can
> only speculate that this could be due to the fact that the vast
> majority of systems have been merged and thus there's no difference
> (alternatively it could be that such packages have extremely low
> popcon, I have not checked). If these packages were used on unmerged
> system, these bugs would be very real - the functionality they provide
> would be broken.

Given that we are saying exactly the opposite of each other, it seems
likely that we are talking about different things (thanks to that kind
soul pointing it out to me).

As I read your reply, it seems to me that you see the bug in
multipath-tools and other packages that ship files in
/lib/modules-load.d as opposed to /usr/lib/modules-load.d. Assuming
that's your view, what you write very much makes sense - including the
assertion that it only affects unmerged systems. Do you confirm? If you
confirm, I'd see what you see as the bug we are talking about as not an
issue in systemd at all, but as multiple issues in other packages (such
as multipath-tools) that fail at integrating properly with systemd (when
unmerged, which is unsupported, so not worth fixing in bookworm). Given
that the bug at hand is filed against systemd (rather than
multipath-tools), it did not occur to me earlier that you were having
this problem in mind.

As I understand what Andreas wrote (maybe he can confirm), the problem
he sees is that /usr/lib/modules-load.d (the directory) disappears when
removing other packages such as multipath-tools. So it's very much not
about whether systemd deals with the dropins placed by multipath-tools.
It's about removal of a package having unintended side-effects (removing
a directory still owned by systemd). And this very problem, can only be
experienced on merged /usr. The absence of a directory may not seem like
a big deal to you and none of us seems convinced that it has a
practically relevant impact on using systemd, but it very much has an
impact on piuparts and testing migration and that - to me - is what this
bug report has been about.

Does that make more sense to you now?

Helmut

Bug#1036946: webkit2gtk: Tries to build Bubblewrap support even if its disabled

[John Paul Adrian Glaubitz]

Source: webkit2gtk
Version: 2.40.2-1
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sp...@lists.debian.org

Hello!

webkit2gtk currently FTBFS on multiple architectures since it tries to build 
Bubblewrap
support code despite being configured with -DENABLE_BUBBLEWRAP_SANDBOX=OFF.

On sparc64, for example, at the configure stage, the feature is clearly off:

-- Enabled features:
--  ENABLE_BUBBLEWRAP_SANDBOX . OFF


However, the build system still tries to build the corresponding code in 
Sandbox.cpp:

[151/6185] /usr/bin/ccache /usr/bin/c++ -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 
-DBUILDING_WITH_CMAKE=1 \
-DBUILDING_WTF -DGETTEXT_PACKAGE=\"WebKitGTK-4.0\" -DHAVE_CONFIG_H=1 
-DJSC_GLIB_API_ENABLED -DPAS_BMALLOC=1 \
-I/<>/build-soup2 
-I/<>/build-soup2/WTF/DerivedSources -I/<>/Source/WTF 
\
-I/<>/Source/WTF/wtf -I/<>/Source/WTF/wtf/dtoa 
-I/<>/Source/WTF/wtf/fast_float \
-I/<>/Source/WTF/wtf/persistence 
-I/<>/Source/WTF/wtf/text \
-I/<>/Source/WTF/wtf/text/icu 
-I/<>/Source/WTF/wtf/threads \
-I/<>/Source/WTF/wtf/unicode -isystem /usr/include/gio-unix-2.0 
-isystem /usr/include/glib-2.0 -isystem \
/usr/lib/sparc64-linux-gnu/glib-2.0/include -isystem /usr/include/libmount 
-isystem /usr/include/blkid \
-fdiagnostics-color=always -Wextra -Wall -pipe -fmax-errors=20 -Wno-odr 
-Wno-stringop-overread \
-Wno-stringop-overflow -Wno-nonnull -Wno-array-bounds -Wno-expansion-to-defined 
-Wno-noexcept-type \
-Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef 
-Wpointer-arith \
-Wmissing-format-attribute -Wformat-security -Wcast-align 
-Wno-tautological-compare -g1 -O2 \
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security \
-Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -DG_DISABLE_CAST_CHECKS 
-fno-strict-aliasing -fno-exceptions \
-fno-rtti -fPIC -fvisibility=hidden -std=c++20 -MD -MT 
Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o \
-MF Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o.d -o 
Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o \
-c /<>/Source/WTF/wtf/glib/Sandbox.cpp
FAILED: Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o 
/usr/bin/ccache /usr/bin/c++ -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 
-DBUILDING_WITH_CMAKE=1 -DBUILDING_WTF \
-DGETTEXT_PACKAGE=\"WebKitGTK-4.0\" -DHAVE_CONFIG_H=1 -DJSC_GLIB_API_ENABLED 
-DPAS_BMALLOC=1 \
-I/<>/build-soup2 
-I/<>/build-soup2/WTF/DerivedSources -I/<>/Source/WTF 
\
-I/<>/Source/WTF/wtf -I/<>/Source/WTF/wtf/dtoa 
-I/<>/Source/WTF/wtf/fast_float \
-I/<>/Source/WTF/wtf/persistence 
-I/<>/Source/WTF/wtf/text \
-I/<>/Source/WTF/wtf/text/icu 
-I/<>/Source/WTF/wtf/threads 
-I/<>/Source/WTF/wtf/unicode \
-isystem /usr/include/gio-unix-2.0 -isystem /usr/include/glib-2.0 -isystem 
/usr/lib/sparc64-linux-gnu/glib-2.0/include -isystem \
/usr/include/libmount -isystem /usr/include/blkid -fdiagnostics-color=always 
-Wextra -Wall -pipe -fmax-errors=20 -Wno-odr \
-Wno-stringop-overread -Wno-stringop-overflow -Wno-nonnull -Wno-array-bounds 
-Wno-expansion-to-defined -Wno-noexcept-type \
-Wno-psabi -Wno-misleading-indentation -Wno-maybe-uninitialized -Wundef 
-Wpointer-arith -Wmissing-format-attribute \
-Wformat-security -Wcast-align -Wno-tautological-compare -g1 -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong \
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG 
-DG_DISABLE_CAST_CHECKS -fno-strict-aliasing \
-fno-exceptions -fno-rtti -fPIC -fvisibility=hidden -std=c++20 -MD -MT 
Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o \
-MF Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o.d -o 
Source/WTF/wtf/CMakeFiles/WTF.dir/glib/Sandbox.cpp.o -c \
/<>/Source/WTF/wtf/glib/Sandbox.cpp
/<>/Source/WTF/wtf/glib/Sandbox.cpp: In function ‘bool 
WTF::isInsideUnsupportedContainer()’:
/<>/Source/WTF/wtf/glib/Sandbox.cpp:49:13: error: 
‘BWRAP_EXECUTABLE’ was not declared in this scope
   49 | BWRAP_EXECUTABLE,
  | ^~~~

See: 
https://buildd.debian.org/status/fetch.php?pkg=webkit2gtk=sparc64=2.40.2-1=1685439602=0

Adrian

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

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

[Michael Biebl]

[trimmed the list of CCs]

Am 30.05.23 um 13:36 schrieb Jochen Sprickerhof:

# find / -name e2scrub_reap.service
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/e2scrub_reap.service
/var/lib/systemd/deb-systemd-helper-enabled/default.target.wants/e2scrub_reap.service
/usr/lib/systemd/system/e2scrub_reap.service
/etc/systemd/system/default.target.wants/e2scrub_reap.service


[...]


Interesting. Will check.




OpenPGP_signature
Description: OpenPGP digital signature

Bug#941675: Bug#942296: gnome-keyring: gkr-pam: unable to locate daemon control file

[Vincent Lefevre]

Hi,

On 2019-10-14 08:28:22 +0200, GT wrote:
> Package: gnome-keyring

This is probably more a bug in libpam-gnome-keyring since the error
message contains "gkr-pam".

> Version: 3.34.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> Regular log in with standard user
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
> Slow session opening
> Error in the log file  oct. 14 07:50:24 debian sddm-helper[2570]: gkr-pam:
> unable to locate daemon control file

And this should be a dup of bug 941675 (gkr-pam: unable to locate
daemon control file), Cc'ed for the following information:

> According to Arch https://bbs.archlinux.org/viewtopic.php?pid=1837490#p1837490
> seems linked to this
> https://gitlab.gnome.org/GNOME/gnome-keyring/commit/b22d058a055ec3e0f31ae16417f16b42baadb42f

Moreover, there's an upstream bug:

  https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/28

now closed, but some users reported that the fix did not make the
error disappear.

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

Bug#941675: Same thing here

[Vincent Lefevre]

Control: found -1 42.1-1

I've also got this error since 3.34.0-1 (exactly), and it still
occurs.

On 2019-10-23 17:37:50 +0200, Felix Zielcke wrote:
> It seems like the updated mate-session-manager 1.22.2-2 in sid fixes
> the long delay with MATE.
> The original Launchpad bug for this is here:
> 
> https://bugs.launchpad.net/ubuntu/+source/mate-session-manager/+bug/1846987
> 
> But the gkr-pam failure is still in the logs.

I don't use MATE (just FVWM, with logging via lightdm), so, AFAIK,
I've never seen any delay related to that. I'm not aware of any issue,
except that this error is distracting when I look at the logs (it
appears in red in the journalctl output).

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

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

[Jochen Sprickerhof]

Hi Michael,

* Michael Biebl  [2023-05-30 13:23]:

bullseye chroot upgraded to bookworm:
# find /etc/systemd/system/ -name e2scrub_reap.service
/etc/systemd/system/multi-user.target.wants/e2scrub_reap.service
/etc/systemd/system/default.target.wants/e2scrub_reap.service


But when you use a VM:

$ debvm-create -r bullseye
$ debvm-run
# apt install e2fsprogs

# find / -name e2scrub_reap.service
/var/lib/systemd/deb-systemd-helper-enabled/default.target.wants/e2scrub_reap.service
/lib/systemd/system/e2scrub_reap.service
/etc/systemd/system/default.target.wants/e2scrub_reap.service

# cat /var/lib/systemd/deb-systemd-helper-enabled/e2scrub_reap.service.dsh-also
/etc/systemd/system/default.target.wants/e2scrub_reap.service

# sed -i 's/bullseye/bookworm/' /etc/apt/sources.list
# apt update
# apt dist-upgrade

# find / -name e2scrub_reap.service
/var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/e2scrub_reap.service
/var/lib/systemd/deb-systemd-helper-enabled/default.target.wants/e2scrub_reap.service
/usr/lib/systemd/system/e2scrub_reap.service
/etc/systemd/system/default.target.wants/e2scrub_reap.service

# cat /var/lib/systemd/deb-systemd-helper-enabled/e2scrub_reap.service.dsh-also
/etc/systemd/system/default.target.wants/e2scrub_reap.service
/etc/systemd/system/multi-user.target.wants/e2scrub_reap.service


So what I would suggest is a
if dpkg --compare-versions "$2" lt "$ver of your next upload"; then
 rm -f /etc/systemd/system/default.target.wants/e2scrub_reap.service
fi
in your postinst to clean up the stray enablement symlink.


I think this would disable the service for users that upgraded from 
bullseye as shown above.


Cheers Jochen


signature.asc
Description: PGP signature

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

[Salvatore Bonaccorso]

Hi Nick,

Thanks to you both for triaging the issue!

On Tue, May 30, 2023 at 04:01:04PM +0900, Nick Hastings wrote:
> Hi,
> 
> * Mario Limonciello  [230530 13:00]:
> > On 5/29/23 18:01, Nick Hastings wrote:
> > > Hi,
> > > 
> > > * Nick Hastings  [230529 12:51]:
> > > > * Mario Limonciello  [230529 10:14]:
> > > > > On 5/28/23 19:56, Nick Hastings wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > * Mario Limonciello  [230528 21:44]:
> > > > > > > On 5/28/23 01:49, Salvatore Bonaccorso wrote:
> > > > > > > > Hi Mario
> > > > > > > > 
> > > > > > > > Nick Hastings reported in Debian in 
> > > > > > > > https://bugs.debian.org/1036530
> > > > > > > > lockups from his system after updating from a 6.0 based version 
> > > > > > > > to
> > > > > > > > 6.1.y. >
> > > > > > > > #regzbot ^introduced 24867516f06d
> > > > > > > > 
> > > > > > > > he bisected the issue and tracked it down to:
> > > > > > > > 
> > > > > > > > On Sun, May 28, 2023 at 10:14:51AM +0900, Nick Hastings wrote:
> > > > > > > > > Control: tags -1 - moreinfo
> > > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > I repeated the git bisect, and the bad commit seems to be:
> > > > > > > > > 
> > > > > > > > > (git)-[v6.1-rc1~206^2~4^5~3|bisect] % git bisect bad
> > > > > > > > > 24867516f06dabedef3be7eea0ef0846b91538bc is the first bad 
> > > > > > > > > commit
> > > > > > > > > commit 24867516f06dabedef3be7eea0ef0846b91538bc
> > > > > > > > > Author: Mario Limonciello 
> > > > > > > > > Date:   Tue Aug 23 13:51:31 2022 -0500
> > > > > > > > > 
> > > > > > > > >ACPI: OSI: Remove Linux-Dell-Video _OSI string
> > > > > > > > >This string was introduced because drivers for NVIDIA 
> > > > > > > > > hardware
> > > > > > > > >had bugs supporting RTD3 in the past.
> > > > > > > > >Before proprietary NVIDIA driver started to support 
> > > > > > > > > RTD3, Ubuntu had
> > > > > > > > >had a mechanism for switching PRIME on and off, though 
> > > > > > > > > it had required
> > > > > > > > >to logout/login to make the library switch happen.
> > > > > > > > >When the PRIME had been off, the mechanism had 
> > > > > > > > > unloaded the NVIDIA
> > > > > > > > >driver and put the device into D3cold, but the GPU had 
> > > > > > > > > never come back
> > > > > > > > >to D0 again which is why ODMs used the _OSI to expose 
> > > > > > > > > an old _DSM
> > > > > > > > >method to switch the power on/off.
> > > > > > > > >That has been fixed by commit 5775b843a619 ("PCI: 
> > > > > > > > > Restore config space
> > > > > > > > >on runtime resume despite being unbound"). so vendors 
> > > > > > > > > shouldn't be
> > > > > > > > >using this string to modify ASL any more.
> > > > > > > > >Reviewed-by: Lyude Paul 
> > > > > > > > >Signed-off-by: Mario Limonciello 
> > > > > > > > > 
> > > > > > > > >Signed-off-by: Rafael J. Wysocki 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > drivers/acpi/osi.c | 9 -
> > > > > > > > > 1 file changed, 9 deletions(-)
> > > > > > > > > 
> > > > > > > > > This machine is a Dell with an nvidia chip so it looks like 
> > > > > > > > > this really
> > > > > > > > > could be the commit that that is causing the problems. The 
> > > > > > > > > description
> > > > > > > > > of the commit also seems (to my untrained eye) to be 
> > > > > > > > > consistent with the
> > > > > > > > > error reported on the console when the lockup occurs:
> > > > > > > > > 
> > > > > > > > > [   58.729863] ACPI Error: Aborting method \_SB.PCI0.PGON due 
> > > > > > > > > to previous error (AE_AML_LOOP_TIMEOUT) (20220331/psparse-529)
> > > > > > > > > [   58.729904] ACPI Error: Aborting method 
> > > > > > > > > \_SB.PCI0.PEG0.PG00._ON due to previous error 
> > > > > > > > > (AE_AML_LOOP_TIMEOUT) (20220331/psparse-529)
> > > > > > > > > [   60.083261] vfio-pci :01:00.0 Unable to change power 
> > > > > > > > > state from D3cold to D0, device inaccessible
> > > > > > > > > 
> > > > > > > > > Hopefully this is enough information for experts to resolve 
> > > > > > > > > this.
> > > > > > > > 
> > > > > > > > Does this ring some bell for you? Do you need any further 
> > > > > > > > information
> > > > > > > > from Nick?
> > > > > > > > 
> > > > > > > > Regards,
> > > > > > > > Salvatore
> > > > > > > 
> > > > > > 
> > > > > > > Have Nick try using "pcie_port_pm=off" and see if it helps the 
> > > > > > > issue.
> > > > > > 
> > > > > > I booted into a 6.1 kernel with this option. It has been running 
> > > > > > without
> > > > > > problems for 1.5 hours. Usually I would expect the lockup to have
> > > > > > occurred by now.
> > > > 
> > > > I let this run for 3 hours without issue.
> > > > 
> > > > > > > Does this happen in the latest 6.4 RC as well?
> > > > > > 
> > > > > > I have compiled that kernel and will boot into it after running 
> > > > > > this one
> > > > > > with the 

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

[Michael Biebl]

The title of this bug report is highly misleading.

Let's see what's actually happening here:


bullseye chroot:
# find /etc/systemd/system/ -name e2scrub_reap.service
/etc/systemd/system/default.target.wants/e2scrub_reap.service

bookworm chroot:
# find /etc/systemd/system/ -name e2scrub_reap.service
/etc/systemd/system/multi-user.target.wants/e2scrub_reap.service

bullseye chroot upgraded to bookworm:
# find /etc/systemd/system/ -name e2scrub_reap.service
/etc/systemd/system/multi-user.target.wants/e2scrub_reap.service
/etc/systemd/system/default.target.wants/e2scrub_reap.service


So, you have the service enabled both in default.target and 
multi-user.target. Does this pose any actual problem? Not really.
It is properly started during boot and if you purge the package, both 
symlinks are removed. It is thus imho not a serious issue, but something 
you might want to fix at it is a bit confusing.


That said, I find the piuparts output not very readable, so there might 
be another issue I don't see. In this case, Andreas needs to clarify the 
RC status of this bug.



So what I would suggest is a
if dpkg --compare-versions "$2" lt "$ver of your next upload"; then
  rm -f /etc/systemd/system/default.target.wants/e2scrub_reap.service
fi
in your postinst to clean up the stray enablement symlink.

Michael



OpenPGP_signature
Description: OpenPGP digital signature

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

[James Addison]

Package: e2fsprogs
Followup-For: Bug #1035543
X-Debbugs-Cc: ty...@mit.edu, bi...@debian.org, hel...@subdivi.de, 
jspri...@debian.org, ans...@debian.org, a...@debian.org, 
debian.bugrep...@wodny.org

Would a 'move /etc/systemd/system/default.target.wants/e2scrub_reap.service
to /etc/systemd/system/multi-user.target.wants/e2scrub_reap.service if the
source file exists' during the postinst be enough to restore consistency here,
and satisfy piuparts?

If waiting to the point-release is better, then I'm OK with that.  I have some
slight frustration about the path divergence - because I think consistent
results are important for robust packaging - but if there's higher risk of
breakage or a sense that it's too late to fix for bookworm, I can accept that.

Bug#1036920: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]

[Luca Boccassi]

On Tue, 30 May 2023 at 10:53, Helmut Grohne  wrote:
>
> Context for d-devel:
>
> Andreas Beckmann noticed that systemd ships an empty directory
> /usr/lib/modules-load.d. When removing a package that ships a file in
> /lib/modules-load.d (such as multipath-tools), dpkg may in some
> circumstanced delete the empty directory owned by systemd.
>
> On Mon, May 29, 2023 at 07:24:09PM +0100, Luca Boccassi wrote:
> > Given what was discussed:
>
> I think the conclusion is drawn too quickly here.
>
> > - bookworm is in hard freeze
> > - there is no functional impact
>
> In effect, this bug report is an instance of a bug class. I am in the
> process of quantifying its effects, but I do not have useful numbers at
> this time. As an initial gauge, I think it is about 2000 binary packages
> that ship empty directories (which does not imply them to be affected,
> rather this is to be seen as a grossly imprecise upper bound).

Not quite - this bug report is filed against src:systemd, and it's
about precisely one thing - the modules-load.d/ directory, and the
reply you are quoting is talking explicitly about that.

> > - unmerged-usr paths are no longer supported
>
> Then you argue that this bug would affect only unmerged systems, while
> it actually is in reverse. Unmerged systems are unaffected by this bug
> class. The deletion that Andreas describes can only happen due to the
> aliasing introduced by merging. This bug class only affects merged
> systems.

No, this bug report only affects unmerged systems and has no effect on
merged ones, as the actual bug after the analysis and discussion is
that some packages since Bullseye install modules-load.d/ files in the
wrong directory, that nothing actually reads (since Bullseye!),
effectively making them useless, but nobody ever noticed, and I can
only speculate that this could be due to the fact that the vast
majority of systems have been merged and thus there's no difference
(alternatively it could be that such packages have extremely low
popcon, I have not checked). If these packages were used on unmerged
system, these bugs would be very real - the functionality they provide
would be broken.

Now you want to talk about a different issue - that is fine of course,
but it's not what I was talking about.

> In my earlier reply, I also asked Andreas for a practical impact on
> systemd users and suggested lowering the severity of this instance.
> However, there is more to consider. This poses a problem to piuparts and
> thus testing migration. Making piuparts happy is a use case of its own.
> When a mitigation for non-essential adduser broke piuparts (again, I'm
> sorry about that), the release team decided that piuparts is an
> important piece of the release process and therefore the change was to
> be reverted. As a result, apt now depends on adduser in bookworm again.
> To be clear, I fully support the decision that has been made here and
> thank the release team for dealing with resulting issues (e.g. delayed
> migration of other packages). Since the problem we are discussing here
> is quite similar, I argue that this problem class also should be
> considered release critical in general, because it may impact testing
> migration. That being said, IANARM and I therefore leave that judgement
> to others.

/lib/modules-load.d/ being ignored (and thus packages shipping files
there being buggy) has been the case since Bullseye, as already
mentioned. If it was not release critical for Bullseye, why should it
be for Bookworm?

> > - as soon as trixie opens for business we might just canonicalize
> > everything (assuming all the ducks will be in a row)
>
> You make this look like a simple way forward.

The qualifications in that sentence were included to do precisely the opposite.

Kind regards,
Luca Boccassi

Bug#1036945: pass: do not recommend xclip and wl-clipboard

[Martin Kuettler]

Package: pass
Version: 1.7.4-6
Severity: normal
X-Debbugs-Cc: martin.kuett...@gmail.com

Dear Maintainer,

starting in bookworm, the package `pass` recommands both xclip and 
wl-clipboard. 
Thus, on a system without Xorg, installing pass leads to all (?) of the X 
server being
installed, which is obviously unnecessary and undesirable. I had to install 
with with 
`apt install -no-install-recommends`.

-- 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/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 pass depends on:
ii  gnupg  2.2.40-1.1
ii  tree   2.1.0-1

Versions of packages pass recommends:
ii  git   1:2.39.2-1.1
pn  qrencode  
ii  wl-clipboard  2.1.0-0.1+b1
pn  xclip 

Versions of packages pass suggests:
ii  libxml-simple-perl  2.25-2
ii  perl5.36.0-7
pn  python  
ii  python3 3.11.2-1+b1
pn  ruby

-- no debconf information

Bug#1036920: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]

[Helmut Grohne]

On Tue, May 30, 2023 at 11:53:01AM +0200, Helmut Grohne wrote:
> Are there other kinds of resources in dpkg that can be shared like
> directories? Thinking... Yes, regular files. How can files be shared?
> Via Multi-Arch: same.  Can that happen for real? Yes. I've attached an
> artificial reproducer.  Does it happen in the archive? I really cannot
> tell yet. In effect, this is yet another bug class derived from Andreas'
> directory-loss bug class. This new file-loss bug class is distinct from
> the file-loss bug class that resulted in the moratorium.

Sorry, for the double mail. That attachment thing is so easy to forget.

Also dropped Luca as his email bounces.

Helmut


multiarchbug.sh
Description: Bourne shell script

Bug#1036920: another problem class from /usr-merge [Re: Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/]

[Helmut Grohne]

Context for d-devel:

Andreas Beckmann noticed that systemd ships an empty directory
/usr/lib/modules-load.d. When removing a package that ships a file in
/lib/modules-load.d (such as multipath-tools), dpkg may in some
circumstanced delete the empty directory owned by systemd.

On Mon, May 29, 2023 at 07:24:09PM +0100, Luca Boccassi wrote:
> Given what was discussed:

I think the conclusion is drawn too quickly here.

> - bookworm is in hard freeze
> - there is no functional impact

In effect, this bug report is an instance of a bug class. I am in the
process of quantifying its effects, but I do not have useful numbers at
this time. As an initial gauge, I think it is about 2000 binary packages
that ship empty directories (which does not imply them to be affected,
rather this is to be seen as a grossly imprecise upper bound).

> - unmerged-usr paths are no longer supported

Then you argue that this bug would affect only unmerged systems, while
it actually is in reverse. Unmerged systems are unaffected by this bug
class. The deletion that Andreas describes can only happen due to the
aliasing introduced by merging. This bug class only affects merged
systems.

In my earlier reply, I also asked Andreas for a practical impact on
systemd users and suggested lowering the severity of this instance.
However, there is more to consider. This poses a problem to piuparts and
thus testing migration. Making piuparts happy is a use case of its own.
When a mitigation for non-essential adduser broke piuparts (again, I'm
sorry about that), the release team decided that piuparts is an
important piece of the release process and therefore the change was to
be reverted. As a result, apt now depends on adduser in bookworm again.
To be clear, I fully support the decision that has been made here and
thank the release team for dealing with resulting issues (e.g. delayed
migration of other packages). Since the problem we are discussing here
is quite similar, I argue that this problem class also should be
considered release critical in general, because it may impact testing
migration. That being said, IANARM and I therefore leave that judgement
to others.

> - as soon as trixie opens for business we might just canonicalize
> everything (assuming all the ducks will be in a row)

You make this look like a simple way forward. For now, I am unconvinced
that canonicalizing paths is the cure to this problem. To dpkg, a
canonicalization looks like removing a file and adding a different file.
Thus the deletion effect that Andreas reported may kick in while
performing that canonicalization. It probably is not that simple though.
As far as I understand it, dpkg first adds new files and then removes
the old ones thus seeing that the directory it tries to delete is not
empty (and we've seen it issue warnings about that case). To me, this
means that we (or rather I) don't understand the problem well enough to
judge it. It might be harmless, but it might be real. We shouldn't be
scared, but "it probably works" may not be the best approach either.

And then Andreas got me thinking. Before delving into that, I'd like to
again express thanks to Andreas. When we see a bug from Andreas, can we
please start with thanking him? Even if the bug ultimately is due to a
limitation in piuparts (as has happened in the adduser case), his work
(and that of other piuparts people such as Nicolas) still adds a lot of
value to Debian. The occasional report that looks harmless initially
tends to point at real problems more often than not.  When he writes a
mail, it is full of detail for looking at the issue. I ask us all to
better appreciate that work. Let me do that now: Thank you Andreas,
Holger and Nicolas!

So let's stack-pop to where he got me thinking. A directory is a
resource that can be shared between packages. Andreas demonstrated that
removing one package may remove such a shared resource still being
needed when another package references it via an aliased path. In
effect, we break dpkg's reference counting of shared resources.

Are there other kinds of resources in dpkg that can be shared like
directories? Thinking... Yes, regular files. How can files be shared?
Via Multi-Arch: same.  Can that happen for real? Yes. I've attached an
artificial reproducer.  Does it happen in the archive? I really cannot
tell yet. In effect, this is yet another bug class derived from Andreas'
directory-loss bug class. This new file-loss bug class is distinct from
the file-loss bug class that resulted in the moratorium.

Etienne Mollier pointed out that "dpkg --verify" helps with diagnosing
whether unexpected file deletion has happened on a particular system. It
also reports other diagnostics and it does not consider any
--path-excludes that have been configured via /etc/dpkg/dpkg.cfg, so use
the output with a grain of salt. Also reinstalling the affected packages
generally resolves the problem on a particular system.

I wish I could give you numbers. I don't have them. I 

Bug#1036213: apache2: More infos for this bug

[root]

Package: apache2
Version: 2.4.56-1~deb11u2
Followup-For: Bug #1036213


I have additional information that might be related to this bug.
It seems to be following the previous bug I opened in Bug#1033408 ,
which is now solved since 2.4.56-1~deb11u2, but now we don't have
segfaults anymore, but the server of our customer is having a load average
increasing since we've updated the package, we've tested for a week and
load average went from around 5, to 35, slowly increasing over the week
to this value, and it would probably have increased more if we hadn't
intervene.

After witnessing this behavior I noticed these logs in error logs which
I had never seen before:
[...]
[Tue May 30 08:59:29.873462 2023] [http2:warn] [pid 3805413:tid 
140434122716928] [client 81.204.51.61:56550] h2_stream(3805413-327-1,CLEANUP): 
started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 08:59:29.873486 2023] [http2:warn] [pid 3805413:tid 
140434122716928] [client 81.204.51.61:56550] h2_stream(3805413-327-5,CLEANUP): 
started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 08:59:29.873490 2023] [http2:warn] [pid 3805413:tid 
140434122716928] [client 81.204.51.61:56550] h2_stream(3805413-327-9,CLEANUP): 
started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 09:07:11.128774 2023] [http2:warn] [pid 3808854:tid 
140434047182592] [client 106.245.192.226:56994] 
h2_stream(3808854-230-1,CLEANUP): started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 09:07:11.128793 2023] [http2:warn] [pid 3808854:tid 
140434047182592] [client 106.245.192.226:56994] 
h2_stream(3808854-230-5,CLEANUP): started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 09:13:36.366838 2023] [http2:warn] [pid 3811558:tid 
140434114324224] [client 51.179.98.234:49225] 
h2_stream(3811558-357-17,CLEANUP): started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 09:13:36.366874 2023] [http2:warn] [pid 3811558:tid 
140434114324224] [client 51.179.98.234:49225] 
h2_stream(3811558-357-19,CLEANUP): started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 09:55:14.468946 2023] [http2:warn] [pid 3832829:tid 
140434089146112] [client 109.234.73.147:53640] h2_stream(3832829-35-5,CLEANUP): 
started=1, scheduled=1, ready=0, out_buffer=0
[Tue May 30 09:56:14.469032 2023] [http2:warn] [pid 3832829:tid 
140434089146112] [client 109.234.73.147:53640] h2_stream(3832829-35-5,CLEANUP): 
started=1, scheduled=1, ready=0, out_buffer=0
[...]

After noticing these, I immediately thought about the previous bug and
completely disabled the http2 module in apache. It immediately solved
the load issue.
I know it's very few information and I'm not sure it's related exactly
to his particular bug, might need a bug report of its own, but in case,
I don't want to duplicate and will let you choose.



-- Package-specific info:

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

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

Versions of packages apache2 depends on:
ii  apache2-bin  2.4.56-1~deb11u2
ii  apache2-data 2.4.56-1~deb11u2
ii  apache2-utils2.4.56-1~deb11u2
ii  dpkg 1.20.12
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  mime-support 3.66
ii  perl 5.32.1-4+deb11u2
ii  procps   2:3.3.17-5

Versions of packages apache2 recommends:
ii  ssl-cert  1.1.0+nmu1

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx [www-browser]   2.9.0dev.6-3~deb11u1

Versions of packages apache2-bin depends on:
ii  libapr1  1.7.0-6+deb11u2
ii  libaprutil1  1.6.1-5+deb11u1
ii  libaprutil1-dbd-sqlite3  1.6.1-5+deb11u1
ii  libaprutil1-ldap 1.6.1-5+deb11u1
ii  libbrotli1   1.0.9-2+b2
ii  libc62.31-13+deb11u6
ii  libcrypt11:4.4.18-4
ii  libcurl4 7.74.0-1.3+deb11u7
ii  libjansson4  2.13.1-1.1
ii  libldap-2.4-22.4.57+dfsg-3+deb11u1
ii  liblua5.3-0  5.3.3-1.1+b1
ii  libnghttp2-141.43.0-1
ii  libpcre3 2:8.44-2+0~20210301.9+debian11~1.gbpa278ad
ii  libssl1.11.1.1n-0+deb11u4
ii  libxml2  2.9.14+dfsg-0.1+0~20230421.14+debian11~1.gbpf14485
ii  perl 5.32.1-4+deb11u2
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
ii  lynx [www-browser]   2.9.0dev.6-3~deb11u1

Versions of packages apache2 

Bug#1036891: texlive-binaries: Error "attempt to call method 'read' (a nil value)" makes lualatex unusable

[Maximilian Stein]

> LaTeX2e <2018-12-01>
> ...-dist/tex/luatex/luaotfload/luaotfload-configuration.lua:292: 
attempt to cal

> l method 'read' (a nil value)


I am seeing the exact same issue. Downgrading "texlive-binaries" to 
"2018.20181218.49446-1" has fixed it for me (while leaving all other 
packages up to date), so I assume that "texlive-binaries" has the issue 
here.


Best,
Maximilian

Bug#1035361: sauce: Potentially dangerous mode on /etc/logrotate.d/sauce: 0755

[Ian Jackson]

Control: severity -1 normal
Control: tags -1 + patch

Andreas Beckmann writes ("Bug#1035361: sauce: Potentially dangerous mode on 
/etc/logrotate.d/sauce: 0755"):
> While the package works fine after a fresh install in sid or bookworm,
> the issue is still present after an upgrade from bullseye to bookworm.
> File permissions of conffiles do net seem to get updated on upgrades,
> this needs to be fixed manually in the postinst, e.g. (untested)
> 
> if dpkg --compare-versions "$2" lt-nl "0.9.3~"
> then
>   chmod -v -x /etc/logrotate.d/sauce 
> fi

Indeed.

However, I decided not to make that change so late in the freeze.  I
didn't want to add a risk that the maintscript fregemnt would be
wrong (despite the testing I would naturally do).

Cribbing from my commit message:

This is a conffile, so old installs don't get the updated mode.
Ideally we would add something to the postinst to fix them but
that seems too complex at this stage of the Debian release cycle.
Users who are annoyed with the warning can change the mode by
hand.

I will probably do something like you suggest when sid has reopened,
for the benefit of downstreams with a different release cycle, users
skip-upgrading, etc.

I don't intend to prepare a stable update for bookworm myself.  But
if, after I've done this fixup in sid, someone would like to drive
that, I would be happy to review the proposed update and lend my
support.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

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

Bug#1036944: unblock: node-babel7/7.20.15+ds1+~cs214.269.168-3

[Yadd]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: node-bab...@packages.debian.org
Control: affects -1 + src:node-babel7

Please unblock package node-babel7

[ Reason ]
Upgrades from Buster to Bookworm via Bullseye are broken due to a
missing Breaks/Replaces

[ Impact ]
Upgrades may fail

[ Tests ]
No changes

[ Risks ]
No risk, node-babel-code-frame < 7 has been removed before Bullseye

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

Cheers,
Yadd

unblock node-babel7/7.20.15+ds1+~cs214.269.168-3
diff --git a/debian/changelog b/debian/changelog
index d445ccc55..f0ff6d95f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+node-babel7 (7.20.15+ds1+~cs214.269.168-3) unstable; urgency=medium
+
+  * Team upload
+  * Add Breaks+Replaces against node-babel-code-frame << 7
+(Closes: #1036942)
+
+ -- Yadd   Tue, 30 May 2023 12:24:08 +0400
+
 node-babel7 (7.20.15+ds1+~cs214.269.168-2) unstable; urgency=medium
 
   * Update minimum version of node-regexpu-core to 5.2.1~.
diff --git a/debian/control b/debian/control
index ff31d4894..e5dba9547 100644
--- a/debian/control
+++ b/debian/control
@@ -120,6 +120,8 @@ Depends: ${misc:Depends}
 Suggests: node-babel-plugin-polyfill-es-shims
  , node-babel7-debug
 Breaks: node-babel-core (<< 6.26.0+repack-3~)
+ , node-babel-code-frame (<< 7)
+Replaces: node-babel-code-frame (<< 7)
 Provides: ${nodeBabel7:Provides}
  , babeljs (= ${binary:Version})
 X-Javascript-Built-Using: ${nodejs:BuiltUsing}

Bug#1036759: unblock: heat-cfntools/1.4.2-3

[Thomas Goirand]

Sorry. Indeed, forgot to upload, and just did it a few minutes ago.

Cheers,

Thomas Goirand (zigo)

Bug#1036942: node-babel7: missing Breaks+Replaces: node-babel-code-frame (<< 7)

[Andreas Beckmann]

Package: node-babel7
Version: 7.20.15+ds1+~cs214.269.168-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + node-babel-eslint

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'buster' to 'bullseye' to 'bookworm'.
It installed fine in 'buster', and upgraded to 'bullseye' successfully,
but then the upgrade to 'bullseye' failed
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

In case the package was not part of an intermediate stable release,
the version from the preceding stable release was kept installed.

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

  Preparing to unpack .../027-node-babel7_7.20.15+ds1+~cs214.269.168-2_all.deb 
...
  Unpacking node-babel7 (7.20.15+ds1+~cs214.269.168-2) over 
(7.12.12+~cs150.141.84-6) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-mHzAfl/027-node-babel7_7.20.15+ds1+~cs214.269.168-2_all.deb
 (--unpack):
   trying to overwrite '/usr/share/doc/node-babel-code-frame/README.md', which 
is also in package node-babel-code-frame 6.26.0+dfsg-3

node-babel-code-frame (last released as a separate package in buster)
survived the upgrade to bullseye without problems, but causes problems
during the subsequent upgrade to bookworm.

cheers,

Andreas


node-babel-eslint_None.log.gz
Description: application/gzip

Bug#1002470:

[Andrius Merkys]

On 2023-05-27 14:54, Fioddor Superconcentrado wrote:

Any update here?


Some additional details. The package builds and installs successfully, 
and I have collected the required build dependencies to debian/control. 
I did not do anything about the server, though. The upstream provides 
their own debs and possibly the easiest way would be to mimic their setup.


Andrius

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

[Nick Hastings]

Hi,

* Mario Limonciello  [230530 13:00]:
> On 5/29/23 18:01, Nick Hastings wrote:
> > Hi,
> > 
> > * Nick Hastings  [230529 12:51]:
> > > * Mario Limonciello  [230529 10:14]:
> > > > On 5/28/23 19:56, Nick Hastings wrote:
> > > > > Hi,
> > > > > 
> > > > > * Mario Limonciello  [230528 21:44]:
> > > > > > On 5/28/23 01:49, Salvatore Bonaccorso wrote:
> > > > > > > Hi Mario
> > > > > > > 
> > > > > > > Nick Hastings reported in Debian in 
> > > > > > > https://bugs.debian.org/1036530
> > > > > > > lockups from his system after updating from a 6.0 based version to
> > > > > > > 6.1.y. >
> > > > > > > #regzbot ^introduced 24867516f06d
> > > > > > > 
> > > > > > > he bisected the issue and tracked it down to:
> > > > > > > 
> > > > > > > On Sun, May 28, 2023 at 10:14:51AM +0900, Nick Hastings wrote:
> > > > > > > > Control: tags -1 - moreinfo
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > I repeated the git bisect, and the bad commit seems to be:
> > > > > > > > 
> > > > > > > > (git)-[v6.1-rc1~206^2~4^5~3|bisect] % git bisect bad
> > > > > > > > 24867516f06dabedef3be7eea0ef0846b91538bc is the first bad commit
> > > > > > > > commit 24867516f06dabedef3be7eea0ef0846b91538bc
> > > > > > > > Author: Mario Limonciello 
> > > > > > > > Date:   Tue Aug 23 13:51:31 2022 -0500
> > > > > > > > 
> > > > > > > >ACPI: OSI: Remove Linux-Dell-Video _OSI string
> > > > > > > >This string was introduced because drivers for NVIDIA 
> > > > > > > > hardware
> > > > > > > >had bugs supporting RTD3 in the past.
> > > > > > > >Before proprietary NVIDIA driver started to support 
> > > > > > > > RTD3, Ubuntu had
> > > > > > > >had a mechanism for switching PRIME on and off, though 
> > > > > > > > it had required
> > > > > > > >to logout/login to make the library switch happen.
> > > > > > > >When the PRIME had been off, the mechanism had unloaded 
> > > > > > > > the NVIDIA
> > > > > > > >driver and put the device into D3cold, but the GPU had 
> > > > > > > > never come back
> > > > > > > >to D0 again which is why ODMs used the _OSI to expose an 
> > > > > > > > old _DSM
> > > > > > > >method to switch the power on/off.
> > > > > > > >That has been fixed by commit 5775b843a619 ("PCI: 
> > > > > > > > Restore config space
> > > > > > > >on runtime resume despite being unbound"). so vendors 
> > > > > > > > shouldn't be
> > > > > > > >using this string to modify ASL any more.
> > > > > > > >Reviewed-by: Lyude Paul 
> > > > > > > >Signed-off-by: Mario Limonciello 
> > > > > > > > 
> > > > > > > >Signed-off-by: Rafael J. Wysocki 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > drivers/acpi/osi.c | 9 -
> > > > > > > > 1 file changed, 9 deletions(-)
> > > > > > > > 
> > > > > > > > This machine is a Dell with an nvidia chip so it looks like 
> > > > > > > > this really
> > > > > > > > could be the commit that that is causing the problems. The 
> > > > > > > > description
> > > > > > > > of the commit also seems (to my untrained eye) to be consistent 
> > > > > > > > with the
> > > > > > > > error reported on the console when the lockup occurs:
> > > > > > > > 
> > > > > > > > [   58.729863] ACPI Error: Aborting method \_SB.PCI0.PGON due 
> > > > > > > > to previous error (AE_AML_LOOP_TIMEOUT) (20220331/psparse-529)
> > > > > > > > [   58.729904] ACPI Error: Aborting method 
> > > > > > > > \_SB.PCI0.PEG0.PG00._ON due to previous error 
> > > > > > > > (AE_AML_LOOP_TIMEOUT) (20220331/psparse-529)
> > > > > > > > [   60.083261] vfio-pci :01:00.0 Unable to change power 
> > > > > > > > state from D3cold to D0, device inaccessible
> > > > > > > > 
> > > > > > > > Hopefully this is enough information for experts to resolve 
> > > > > > > > this.
> > > > > > > 
> > > > > > > Does this ring some bell for you? Do you need any further 
> > > > > > > information
> > > > > > > from Nick?
> > > > > > > 
> > > > > > > Regards,
> > > > > > > Salvatore
> > > > > > 
> > > > > 
> > > > > > Have Nick try using "pcie_port_pm=off" and see if it helps the 
> > > > > > issue.
> > > > > 
> > > > > I booted into a 6.1 kernel with this option. It has been running 
> > > > > without
> > > > > problems for 1.5 hours. Usually I would expect the lockup to have
> > > > > occurred by now.
> > > 
> > > I let this run for 3 hours without issue.
> > > 
> > > > > > Does this happen in the latest 6.4 RC as well?
> > > > > 
> > > > > I have compiled that kernel and will boot into it after running this 
> > > > > one
> > > > > with the pcie_port_pm=off for another hour or so.
> > > 
> > > I'm now running 6.4.0-rc4 without seeing the problem after 1 hour.
> > 
> > I did eventually see a lockup of this kernel. On the console I saw:
> > 
> > [  151.035036] vfio-pci :01:00.0 Unable to change power state from 
> > D3cold to D0, device inaccessible
> > 
> > I did not see the other two lines that were 

Bug#1002470:

[Andrius Merkys]

Hi,

On 2023-05-27 14:54, Fioddor Superconcentrado wrote:

Any update here?


Not much since. I dropped the ball at the stage of collecting the 
dependencies. Also it needs lucene9 (still in NEW).


Do you have your (unfinished) work publicly available? I don't see this 
in salsa (https://salsa.debian.org/users/merkys-guest/projects 
 or 
https://salsa.debian.org/users/merkys/projects 
)


You are right, it has not been pushed. Now I have pushed it to:

https://salsa.debian.org/merkys/opensearch

Let me know if you reach any progress with it.

Best,
Andrius

Bug#1032995: spyder: Spyder on startup says there is a missing dependency (pylsp_black) but it is correctly installed

[Julian Gilbey]

On Mon, May 29, 2023 at 04:51:25PM -0700, Brian Vaughan wrote:
> It didn't return anything. Neither did "locate
> 'v0.9.4.4-ds-git20221205-12a9702d29ab'".

Hi Brian,

Thanks for bearing with me!  Hmmm, this is strange indeed.  Let's try
the other search directories as well, then:

rgrep 0.9.4.4-ds-git20221205-12a9702d29ab \
  . /usr/lib/python3/dist-packages/spyder/plugins/help/utils \
  /usr/lib/python3.11 /usr/local/lib/python3.11/dist-packages \
  /usr/lib/python3/dist-packages /usr/lib/python3.11/dist-packages

(all one command; the "\" are line continuation characters and should
be omitted if the whole command is written on one line).  The initial
"." means look in the current directory, so you might want to run
this command from an empty directory!  (It would also be worth
checking that spyder still gives the pylsp_black warning when running
from this empty directory.)

Best wishes,

   Julian

Bug#1019868: godot: ftbfs on riscv64 ("undefined reference to `__atomic_compare_exchange_1'")

[Petter Reinholdtsen]

[Petter Reinholdtsen]
> The armel architecture need -latomic too.  Might be others as well.  I
> am testing a variant of this patch now to verify it work on armel too.

Here is a patch tested on armel to fix the armel build.  I tried
modifying the scons buidl to automaticalliy add this on armel, or when
the build of a simple code fragment require it (like autoconf can do),
but was unable to figure out how and where to modify the scons build
files to get it to work.

diff --git a/debian/rules b/debian/rules
index f46330e3..51ceee03 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,6 +7,11 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 
+# Link with libatomic on archs where it is needed.
+ifeq ($(DEB_HOST_ARCH),$(filter $(GCC_MINOR),armel riscv64))
+   export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic 
-Wl,--as-needed
+endif
+
 override_dh_clean:
dh_clean
scons -c
-- 
Happy hacking
Petter Reinholdtsen

Bug#1036929: mmdebstrap: Feature request: "mmdebstrap --anything-failed-commands '%s'" should exist, like in sbuild

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Dima Kogan (2023-05-30 05:34:20)
> > Since all hooks have the MMDEBSTRAP_HOOK variable set, whatever is run in 
> > the
> > hook would have access to the type of hook that failed.
> >
> > The information that would be missing would be *which* hook of a certain 
> > type
> > was the one failing. I do not see a good way to communicate this 
> > information.
> 
> Ideally, mmdebstrap will tell you which command failed, so the user can
> cut/paste the failing command to reproduce the failure. This maybe is
> the most important thing to communicate? I might be missing the
> subtleties of what you're thinking.

ah I see our main difference might be that I run mmdebstrap mostly from other
scripts whereas you are running it interactively and thus you want a shell if
something goes wrong.

> > Do you know of another software besides sbuild that has a similar interface?
> > I'd like to get some more ideas first before I add another interface that
> > mmdebstrap would have to support forever.
> 
> I can only thing of sbuild off the top of my head. But mmdebstrap
> already has a hook system, so extending that in the way you suggested
> above sounds like a self-consistent way to do it.

Yes, but every new feature comes at a cost, so I'd like to be very careful
about adding more stuff and first check if it can be avoided.

> > I'd also like to add that you can already emulate this behaviour by
> > running a hook like this:
> >
> > --customize-hook='chroot "$1" i-might-fail || chroot "$1" bash'
> 
> I would want to add the '|| chroot "$1" bash' to everything mmdebstrap
> does: downloading packages, installing them, doing customization hooks,
> etc, etc. The above just applies to customization hooks, right?

Oh, so you want the interactive shell on other things than failing hooks? You
also want that shell when any command run by mmdebstrap failed?

> The actual failure I'd like to fix today is a failing "apt update"
> trying to talk to my apt-cacher-ng server (for some reason the server
> returns 502 only when mmdebstrap tries to talk to it). I don't believe
> there's a nice way to debug this with mmdebstrap today, right? I tried
> to use --SOMETHING-hook (don't remember what SOMETHING was), but it
> wasn't clear what the exact failing command was, so I moved on to
> something else. Printing the exact failing command for easy
> reproducibility would be important. Maybe there's already a verbosity
> level that does this?

The commands should be printed if you increase verbosity with --verbose or even
with --debug. If the command is not printed, then that is a bug that I will
fix.

For your specific problem I would first try to take mmdebstrap out of the loop
and see if the problem can be replicated with plain apt as well.

The man page contains a small shell snippet that does the essential things that
mmdebstrap does but without mmdebstrap in the section OPERATION:

https://manpages.debian.org/unstable/mmdebstrap/mmdebstrap.1.en.html#OPERATION

You could try if that script with your apt-cacher-ng setup produces the same
error and then you've already reduced the number of moving parts.

Thanks!

cheers, josch

signature.asc
Description: signature