Bug#1041757: libswe-dev: ships empty directory /usr/lib/pkgconfig

[Helmut Grohne]

Package: libswe-dev
Version: 2.10.03-3
Severity: important
Tags: patch

libswe-dev installs an empty directory /usr/lib/pkgconfig. This
directory is prone to loss due to us having implemented the /usr-merge
using aliasing.

libswe-dev was converted to multiarch and now ships its .pc file in
/usr/lib//pkgconfig. The empty directory is an artifact of an
incomplete conversion and can be deleted without loss of functionality.
What does not exist cannot be lost, so that solves the issue at hand.
I'm attaching a patch for your convenience.

Helmut
diff -Nru libswe-2.10.03/debian/changelog libswe-2.10.03/debian/changelog
--- libswe-2.10.03/debian/changelog 2023-04-30 19:01:56.0 +0200
+++ libswe-2.10.03/debian/changelog 2023-07-23 07:04:43.0 +0200
@@ -1,3 +1,10 @@
+libswe (2.10.03-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not ship empty directory /usr/lib/pkgconfig. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 23 Jul 2023 07:04:43 +0200
+
 libswe (2.10.03-3) unstable; urgency=medium
 
   * Apply multi-arch hints: swetest drop Multi-Arch: same
diff -Nru libswe-2.10.03/debian/libswe-dev.dirs 
libswe-2.10.03/debian/libswe-dev.dirs
--- libswe-2.10.03/debian/libswe-dev.dirs   2022-11-15 11:16:01.0 
+0100
+++ libswe-2.10.03/debian/libswe-dev.dirs   2023-07-23 07:04:38.0 
+0200
@@ -1,2 +1 @@
 usr/include
-usr/lib/pkgconfig

Bug#1041756: libmpeg3-dev: ships empty directory /usr/lib/pkgconfig

[Helmut Grohne]

Package: libmpeg3-dev
Version: 1.8.dfsg-3
Severity: important
Tags: patch

libmpeg3-dev installs an empty /usr/lib/pkgconfig. This directory is
prone to loss since we implemented the /usr-merge using directory
aliasing.

However, the directory is an artifact of an incomplete multiarch
conversion. The .pc file is now shipped in /usr/lib//pkgconfig.
The old location is no longer needed and what does not exist cannot be
lost. I'm attaching a patch for your convenience.

Helmut
diff -Nru libmpeg3-1.8.dfsg/debian/changelog libmpeg3-1.8.dfsg/debian/changelog
--- libmpeg3-1.8.dfsg/debian/changelog  2021-08-25 11:27:20.0 +0200
+++ libmpeg3-1.8.dfsg/debian/changelog  2023-07-23 06:59:17.0 +0200
@@ -1,3 +1,10 @@
+libmpeg3 (1.8.dfsg-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not ship empty directory /usr/lib/pkgconfig. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 23 Jul 2023 06:59:17 +0200
+
 libmpeg3 (1.8.dfsg-3) unstable; urgency=medium
 
   * Adopt package into multimedia-team
diff -Nru libmpeg3-1.8.dfsg/debian/libmpeg3-dev.dirs 
libmpeg3-1.8.dfsg/debian/libmpeg3-dev.dirs
--- libmpeg3-1.8.dfsg/debian/libmpeg3-dev.dirs  2021-08-25 11:27:20.0 
+0200
+++ libmpeg3-1.8.dfsg/debian/libmpeg3-dev.dirs  2023-07-23 06:59:15.0 
+0200
@@ -1,5 +1,4 @@
 usr/lib
-usr/lib/pkgconfig
 usr/include/mpeg3
 usr/include/mpeg3/audio
 usr/include/mpeg3/video

Bug#1041755: python3-expeyes: ships empty /lib/udev/rules.d

[Helmut Grohne]

Package: python3-expeyes
Version: 5.3.0+repack-3
Severity: important
Tags: patch

python3-expeyes ships empty directories /etc/udev/rules.d and
/lib/udev/rules.d. The latter of these is prone to loss since we
implemented the /usr-merge using directory aliasing. Another package may
remove a file from /usr/lib/udev/rules.d and thereby delete this empty
directory.

As far as I understand it, these directories are not crucial to the
python bindings. While the expeyes contains a 99-phoenix.rules, it is
not installed to any binary package and these directories normally
belong to udev otherwise. As such, they can be deleted at no loss of
functionality. What does not exist, cannot be lost. Problem solved. I'm
attaching a patch for your convenience.

Helmut
diff -Nru expeyes-5.3.0+repack/debian/changelog 
expeyes-5.3.0+repack/debian/changelog
--- expeyes-5.3.0+repack/debian/changelog   2023-02-27 19:34:03.0 
+0100
+++ expeyes-5.3.0+repack/debian/changelog   2023-07-23 07:17:49.0 
+0200
@@ -1,3 +1,10 @@
+expeyes (5.3.0+repack-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not ship empty directories /{etc,lib}/udev/rules.d. Closes: #-1
+
+ -- Helmut Grohne   Sun, 23 Jul 2023 07:17:49 +0200
+
 expeyes (5.3.0+repack-3) unstable; urgency=medium
 
   * added Ceppo's Italian translation. Closes: #1032079
diff -Nru expeyes-5.3.0+repack/debian/python3-expeyes.dirs 
expeyes-5.3.0+repack/debian/python3-expeyes.dirs
--- expeyes-5.3.0+repack/debian/python3-expeyes.dirs2022-03-26 
12:07:55.0 +0100
+++ expeyes-5.3.0+repack/debian/python3-expeyes.dirs1970-01-01 
01:00:00.0 +0100
@@ -1,2 +0,0 @@
-lib/udev/rules.d
-etc/udev/rules.d

Bug#1041753: jigit ships empty directory /usr/lib/pkgconfig

[Helmut Grohne]

Package: libjte-dev
Version: 1.22-3
Severity: important
Tags: patch

jigit ships an empty directory /usr/lib/pkgconfig. Since other packages
ship files in /lib/pkgconfig and we implemented /usr-merge via aliasing,
this directory is prone to loss and may unexpectedly disappear from the
filesystem.

As it happens, the directory also is not needed. The package got
multiarchified and now installs its .pc file into
/usr/lib//pkgconfig. The empty directory is an omission during
the conversion and can safely be deleted. Once deleted, it can no longer
be lost due to /usr-merge.

Helmut
diff -Nru jigit-1.22/debian/changelog jigit-1.22/debian/changelog
--- jigit-1.22/debian/changelog 2019-12-06 20:08:56.0 +0100
+++ jigit-1.22/debian/changelog 2023-07-23 06:47:24.0 +0200
@@ -1,3 +1,10 @@
+jigit (1.22-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Avoid installing empty directory /usr/lib/pkgconfig. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 23 Jul 2023 06:47:24 +0200
+
 jigit (1.22-3) unstable; urgency=medium
 
   * Multiarchify the library packages. Closes: #812946. Thanks to Matthias
diff -Nru jigit-1.22/debian/libjte-dev.dirs jigit-1.22/debian/libjte-dev.dirs
--- jigit-1.22/debian/libjte-dev.dirs   2019-02-04 19:38:43.0 +0100
+++ jigit-1.22/debian/libjte-dev.dirs   2023-07-23 06:47:22.0 +0200
@@ -1,2 +1 @@
 /usr/include/libjte
-/usr/lib/pkgconfig

Bug#1041754: pcp: ships empty directory /usr/lib/pkgconfig

[Helmut Grohne]

Package: pcp
Version: 6.0.5-1
Severity: important
Tags: patch

The binary package pcp ships an empty /usr/lib/pkgconfig. Since we
implemented the /usr-merge using aliasing, this directory is prone to
loss.

As I see it, pcp is split into a number of packages some of which
contain files below /usr/lib/pkgconfig. The existence of that empty
directory is an artifact of how the package is being split and not
required for operation (as it is normally "owned" by pkg-config). As
such, we can delete it from pcp without loss of functionality (and in
the packages shipping .pc files it is non-empty). Since we cannot loose
something that does not exist, the original problem is solved. Do you
agree? I'm attaching a patch for your convenience.

Helmut
diff -Nru pcp-6.0.5/debian/changelog pcp-6.0.5/debian/changelog
--- pcp-6.0.5/debian/changelog  2023-06-14 04:49:33.0 +0200
+++ pcp-6.0.5/debian/changelog  2023-07-23 07:15:09.0 +0200
@@ -1,3 +1,10 @@
+pcp (6.0.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not ship empty directory /usr/lib/pkgconfig (closes: #-1)
+
+ -- Helmut Grohne   Sun, 23 Jul 2023 07:15:09 +0200
+
 pcp (6.0.5-1) unstable; urgency=low
 
   * New release (full details in CHANGELOG).
diff -Nru pcp-6.0.5/debian/rules pcp-6.0.5/debian/rules
--- pcp-6.0.5/debian/rules  2023-02-13 05:03:53.0 +0100
+++ pcp-6.0.5/debian/rules  2023-07-23 07:15:03.0 +0200
@@ -148,7 +148,7 @@
 uninstallpy = cat python*-pcp.list | sed -e "s,^,$(dirpcp)/," | xargs rm -fr
 uninstallpydir = ls -d $(dirpcp)/usr/lib*/python* | xargs rm -fr
 uninstalltest = cat $(dirpcp_testsuite).dirs | sed -e "s,^,debian/$(pcp)/," | 
xargs rm -fr
-uninstalldirs = rmdir $(dirpcp)/usr/include/pcp $(dirpcp)/usr/include 
$(dirpcp)/usr/share/man/man3
+uninstalldirs = rmdir $(dirpcp)/usr/include/pcp $(dirpcp)/usr/include 
$(dirpcp)/usr/share/man/man3 $(dirpcp)/usr/lib/pkgconfig
 uninstallib = cat $(dirpcp_pmda_infiniband).dirs | sed -e "s,^,$(dirpcp)/," | 
xargs rm -fr
 uninstallspark = cat $(dirdoc).dirs | sed -e "s,^,$(dirpcp_export_spark)/," | 
xargs rm -fr
 uninstallgui = cat $(dirgui).dirs | sed -e "s,^,$(dirpcp)/," | xargs rm -fr

Bug#1041752: fwupd: ships empty directory /lib/systemd/system-preset

[Helmut Grohne]

Source: fwupd
Version: 1.9.3-1
Severity: important
Tags: patch

fwupd ships an empty directory /lib/systemd/system-preset. This
directory is prone to loss since we implemented the /usr-merge using
aliasing. Another package may install a file into
/usr/lib/systemd/system-preset and when that package is removed, this
empty directory is deleted as well.

fwupd used to install a preset file there, but no longer does. This
directory is not crucial to fwupd and can be deleted as well. Once
deleted, it can no longer be lost. I'm attaching a patch for your
convenience.

Helmut
diff -Nru fwupd-1.9.3/debian/changelog fwupd-1.9.3/debian/changelog
--- fwupd-1.9.3/debian/changelog2023-07-11 18:15:06.0 +0200
+++ fwupd-1.9.3/debian/changelog2023-07-23 06:45:46.0 +0200
@@ -1,3 +1,10 @@
+fwupd (1.9.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Avoid shipping empty directory /lib/systemd/system-preset. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 23 Jul 2023 06:45:46 +0200
+
 fwupd (1.9.3-1) unstable; urgency=medium
 
   * New upstream version (1.9.3)
diff -Nru fwupd-1.9.3/debian/rules fwupd-1.9.3/debian/rules
--- fwupd-1.9.3/debian/rules2023-07-11 18:15:06.0 +0200
+++ fwupd-1.9.3/debian/rules2023-07-23 06:45:44.0 +0200
@@ -78,6 +78,8 @@
 
#enable fwupd-refresh.service by default (we have a dedicated user)
rm -f debian/fwupd/lib/systemd/system-preset/fwupd-refresh.preset
+   # avoid shipping an empty directory
+   find debian/fwupd/lib/systemd -type d -empty -delete
 
 override_dh_strip_nondeterminism:
dh_strip_nondeterminism -Xfirmware-example.xml.gz

Bug#1041643: ITP: ktls-utils -- TLS handshake utilities for in-kernel TLS consumers

[Salvatore Bonaccorso]

Hi,

On Sat, Jul 22, 2023 at 11:51:55PM +0200, Ben Hutchings wrote:
> I've prepared a package in the Git repository
> .
> 
> As of Linux 6.4, the only in-kernel user of TLS is the NFS server. 
> Linux 6.5 adds support in the NFS client.  With just the NFS server
> supporting TLS, I can't do an end-to-end test.
> 
> Once we have Linux 6.5 packaged, I can test and hopefully upload this
> package.

Sounds like a good plan. 6.4.y should soon come to unstable, making
the master branch free for the 6.5~rcY packagings.

Regards,
Salvatore

Bug#1038422: ntpsec: ntpd segmentation fault in libcrypto.so[7f6d3ecc5000+278000]

[Richard Laager]

Some questions from upstream, with my commentary added...


How busy is this sustem? Is it just a simple client or also a server? If 
server, how busy?

From the stack trace, the server side is trying to decode a NTS cookie. Is this 
box setup as a NTS server? That needs a certificate and key so it takes more 
than just upgrading from bullseye to bookworm.


It's not, right? We previously established that this is using the stock 
ntp.conf?



What are the chances that a valid NTP request with NTS arrived at this system? 
ntpq -c ntsinfo will show counters.


It would be good if you could check this. But if an NTS request is 
crashing ntpd, you might never see non-zero counters.



The log file from starting up might be helpful.

--
Richard

Bug#1041731: groff-base: "-" mapped as HYPHEN

[G. Branden Robinson]

Hi Colin,

On Sun, 23 Jul 2023 00:37:43 +0100, Colin Watson wrote:
> On Sat, Jul 22, 2023 at 06:46:28PM +0200, Sven Joachim wrote:
> > This version of groff maps an unescaped "-" to HYPHEN rather than
> > HYPHEN-MINUS.  Due to that, copying text from manpages or following
> > references in the "SEE ALSO" section is rather unreliable, because
> > many manpages contain a plain "-" where they should have used "\-"
> > instead.

Yes.  That's an error in the man pages, an error Debian has been hiding
for 10+ years.

> > [...] the upstream NEWS file [...] make[s] [no] mention of this
> > change, or how to revert it locally.

Yeah, see, that's where the hyphen-minus brigade gives itself away.

I know it's not very generous to observe that Sven either made this
claim without verifying it first, or had no concern for the facts when
making it, but it's hard to account for otherwise.

https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS?h=1.23.0#n206

If it's any comfort (it actually isn't, to me), Sven's not alone; it's
obvious that the Arch Linux groff packager didn't read the NEWS file
either.[1]

I would add that groff's GNU maintainer, Bertrand Garrigues, included
the entire portion of the NEWS file applicable to groff 1.23.0 in the
release announcement.[2][3]

It is pretty discouraging as an upstream maintainer to go to the trouble
of carefully documenting these things only to find that people not only
don't read the documentation, but assert in the face of obvious contrary
evidence that such documentation doesn't exist.

As annoyed as someone might be by "-" not copying and pasting correctly,
be assured that I am at least ten times as annoyed by people adopting
this QAnon-esque approach to software defect reporting.  The entire
project of cooperative bug reporting and remediation breaks down if
people don't attend conscientiously to material reality.

> I admit I overlooked this; I was aware of the change, but it somehow
> fell off my list of things to make a positive decision about when
> packaging 1.23.0.  I'm rather inclined to revert this by adding the
> rest of the recipe above to debian/mandoc.local (while I agree with
> the idealized typographical point being made, I have approximately
> negative appetite for the Sisyphean task of fixing an entire
> distribution's manual pages in practice), but I'll let this suggestion
> sit for a few days in case anyone wants to make a reasoned argument
> against it in the meantime.

Okay.  Here is my attempt at such.

My reasoning is this:

1.  We're not going to get people to fix these problems by asking them
to fix them when they cannot observe the deleterious effects they
create.  Debian has tried this approach for as long as its relevant
`char` requests have been in place in its groff package; you know
that duration better than I do.  (I guessed at 10+ years above.)

2.  There are a few exceptions to this rule, like Alex Colomar and me,
but we are maintainers of man page collections[4] and moreover we
are both bent on precision and correctness in detail.

3.  Some people will notice the problem Sven reported, become annoyed by
it, research it (perhaps by reading groff's NEWS file, which like
the maintenance of an exercise regimen or healthy diet, appears to
enjoy more lip service than adherence in practice), and work around
it on their systems; either in a narrowly focused way, as with the
recipe in groff's PROBLEMS file, or with a crude, blunt approach
(like LC_ALL=C) as noted by Sven.

4.  Some people will notice the problem Sven reported, become annoyed by
it, and report bugs to Debian.  Possibly against man-db or groff.
As an unofficial groff co-maintainer, I'm willing to shoulder the
responsibility of copy-and-pasting from groff's NEWS and/or PROBLEMS
and reassign the bug reports.  I hadn't been monitoring man-db's
Debian bug list, but I have started.

5.  Some people will notice the problem Sven reported, will not be
annoyed by it, and resign themselves to correcting cut-and-pasted
text.  It's not all _that_ hard: with Bash's no-longer-brand-new
bracketed paste mode, it's a lot easier to distinguish what gets
pasted to the shell prompt, and ^X^E is available by default to
permit editing of command lines.  Not everyone is bent on driving
their shell at breakneck speed, and if they are comfortable
undertaking this effort, I will not tell them they're living their
lives wrong.

6.  Some people will not notice the problem.  For them there is no bug,
and bliss is enjoyed.

It is only through the efforts of people in groups 2 and 4 that any
headway will be made on the problem.  That is where the Sisyphean effort
lies.  The good news is that this effort distributes...but only if
distributors decide not to hide the problems.

Regards,
Branden

[1] 
https://gitlab.archlinux.org/archlinux/packaging/packages/groff/-/commits/main
[2] 

Bug#1041638: bugs.debian.org: the b.d.o mail sofware doesn't parse the "To:" header correctly, generating incorrect addresses

[Don Armstrong]

Control: retitle -1 RFC1522 parsing doesn't re-escape commas

Thanks for the report.

On Fri, 21 Jul 2023, Vincent Lefevre wrote:
> For bug 1041631, I replied to a mail, and the headers were:

[...]

> To: =?iso-8859-1?Q?Preu=DFe=2C?= Hilmar 

[...]

> To: =?UTF-8?Q?Preu=C3=9...@buxtehude.debian.org,
> ?= Hilmar 

It failed the comma and then went through address expansion.

For future me: the test for this should be that:

From: =?UTF-8?B?UHJldcOfZSwgSGlsbWFy?= 

gets round tripped to the same (or uses quotation marks to escape the
comma). [Use a different address in testing.]


-- 
Don Armstrong  https://www.donarmstrong.com

"I always tend to assume there's an infinite amount of money out
there." "There might as well be, [...] but most of it gets spent on
pornography, sugar water, and bombs. There is only so much that can be
scraped together for particle accelerators."
 -- Neal Stephenson _Anathem_ p262

Bug#1041751: libxml-light-ocaml-dev: undeclared file conflict with libxml-light-ocaml (<= 2.4-1+b4) on /usr/lib/ocaml/xml-light/META

[Helmut Grohne]

Package: libxml-light-ocaml-dev
Version: 2.5-1
Severity: serious
Control: affects -1 + libxml-light-ocaml

libxml-light-ocaml-dev introduces an undeclared file conflict with
libxml-light-ocaml up to version 2.4-1+b4 on the file
/lib/ocaml/xml-light/META. This may result in an unpack error at package
extraction time. Do you miss Breaks + Replaces here?

Helmut

Bug#1037468: Acknowledgement (nvidia-driver: RmInitAdapter failed! (0x25:0x65:1457))

[Allan Wind]

It appears to be resolved with the Debian 12.1 upgrade today:

linux-image-6.1.0-10-amd64:amd64 (6.1.37-1, 6.1.38-1)
nvidia-driver:amd64 (525.105.17-1, 525.125.06-1~deb12u1)

Notified upstream.

Bug#1039725: Follow up

[Gary Kramlich]

A few questions that are necessary to figure this out. Was the peer on
the same lan or was this over the internet. Also is ipv6 a possibility
here?

Thanks,

--
Gary Kramlich 

Bug#1041748: snapper: script that uses full apt command as snapshot description

[Anchal Nigam]

Package: snapper
Version: 0.10.4-1
Followup-For: Bug #1041748

Dear Maintainer,

I was able to create my own script that does what I am talking about. This
script will use the apt command as the snapshot description.

I will try to submit a pull request into
https://salsa.debian.org/debian/snapper with my enhancements.

`**/etc/apt/apt.conf.d/80snapper**`:

```
DPkg::Pre-Invoke { "/path/to/dpkg-pre-post-snapper.sh pre"; };
DPkg::Pre-Invoke { "/path/to/dpkg-pre-post-snapper.sh post"; };
```

`**/path/to/dpkg-pre-post-snapper.sh**`

```
#!/bin/bash

# we need to work up the process tree to find the apt command that triggered
the call to this script
# get the initial PPID
PARENT_PID=${PPID}
# trim leading spacess
PARENT_PID="${PARENT_PID## }"

# if the command for this PPID is not apt
while [ "$(ps -ho comm "${PARENT_PID}")" != "apt" ] ; do
# go up one level
PARENT_PID=$(ps -ho ppid "${PARENT_PID}")
PARENT_PID="${PARENT_PID## }" # trim leading
spacess
done

APT_CMD="$(ps -ho args "${PARENT_PID}")"

SNAPPER_DESCRIPTION="apt; ${APT_CMD}"

# source /etc/default/snapper if it exists
if [ -e /etc/default/snapper ] ; then
. /etc/default/snapper
fi

# what action are we taking
if [ "$1" = "pre" ] ; then
# pre, so take a pre snapshot

# if snapper is installed
# and if snapper snapshots are not being disabled using the
DISABLE_APT_SNAPSHOT variable
# and if /etc/snapper/configs/root exists
if [ -x /usr/bin/snapper ] && [ ! x$DISABLE_APT_SNAPSHOT = 'xyes' ] && [ -e
/etc/snapper/configs/root ] ; then
# delete any lingering temp files
rm -f /var/tmp/snapper-apt || true

# create a snapshot
# and save the snapshot number for reference later
snapper create -d "${SNAPPER_DESCRIPTION}" -c number -t pre -p >
/var/tmp/snapper-apt || true

# clean up snapper
snapper cleanup number || true
fi
elif [ "$1" = "post" ] ; then
# post, so take a post snapshot

# if snapper is installed
# and if snapper snapshots are not being disabled using the
DISABLE_APT_SNAPSHOT variable
# and if the temp file with the snapshot number from the pre snapshot
exists
if [ -x /usr/bin/snapper ] && [ ! x$DISABLE_APT_SNAPSHOT = 'xyes' ] && [ -e
/var/tmp/snapper-apt ]
then
# take a post snapshot and link it to the # of the pre snapshot
snapper create -d "${SNAPPER_DESCRIPTION}" -c number -t post --pre-
number=`cat /var/tmp/snapper-apt` || true

# clean up snapper
snapper cleanup number || true
fi
fi

```


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

Kernel: Linux 6.1.0-10-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

Versions of packages snapper depends on:
ii  libboost-thread1.74.0  1.74.0+ds1-21
ii  libc6  2.36-9
ii  libdbus-1-31.14.6-1
ii  libgcc-s1  12.2.0-14
ii  libjson-c5 0.16-2
ii  libmount1  2.38.1-5+b1
ii  libsnapper60.10.4-1
ii  libstdc++6 12.2.0-14
ii  libtinfo6  6.4-4

snapper recommends no packages.

snapper suggests no packages.

-- Configuration Files:
/etc/apt/apt.conf.d/80snapper changed [not included]
/etc/default/snapper changed [not included]

-- no debconf information

Bug#1041750: apt-get changelog nvidia-driver fails with "Changelog unavailable"

[Allan Wind]

Package: apt
Version: 2.6.1
Severity: normal

Dear Maintainer,

I was trying to find out which changes were in the nvidia-driver 
in the just released Debian 12.1 and did:

$ apt-get changelog nvidia-driver
Err:1 https://metadata.ftp-master.debian.org nvidia-graphics-drivers 
525.125.06-1~deb12u1 Changelog
  Changelog unavailable for nvidia-graphics-drivers=525.125.06-1~deb12u1 (404  
Not Found [IP: 146.75.34.132 443])
E: Failed to fetch 
https://metadata.ftp-master.debian.org/changelogs/non-free/n/nvidia-graphics-drivers/nvidia-graphics-drivers_525.125.06-1%7edeb12u1_changelog
  Changelog unavailable for nvidia-graphics-drivers=525.125.06-1~deb12u1 (404  
Not Found [IP: 146.75.34.132 443])

The information exist as I was able to find it via:

https://www.debian.org/News/2023/20230722 ->
https://packages.debian.org/search?searchon=sourcenames=nvidia-graphics-drivers
 ->
https://packages.debian.org/source/bullseye/nvidia-graphics-drivers ->
https://metadata.ftp-master.debian.org/changelogs//non-free-firmware/n/nvidia-graphics-drivers/nvidia-graphics-drivers_525.125.06-1~deb12u1_changelog


/Allan

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^postgresql.*-15";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || 
true; fi";
APT::Update::Post-Invoke "";
APT::Update::Post-Invoke:: "[ ! -x /usr/bin/debtags ] || debtags update || 
true";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "lz4";
APT::Compressor::lz4::Cost "50";
APT::Compressor::lz4::CompressArg "";
APT::Compressor::lz4::CompressArg:: "-1";
APT::Compressor::lz4::UncompressArg "";
APT::Compressor::lz4::UncompressArg:: "-d";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "

Bug#1024353: fixed

[sergio]

https://github.com/asterisk/asterisk/pull/198

Please, apply this for the broken packages.

--
sergio.

Bug#1015809: 1015809: isc-dhcp-client: DHCPv6 doesn't work on ppp interface, got `Unsupported device type` error

[Steven Haigh]

Ok, so after a day of messing around with Debian 12, it looks like 
without these patches applied, there is no way to get a IPv6 PD working 
with a PPPoE connection. Given the majority of ISPs in Australia use 
PPPoE as their connection method, this is a much bigger issue in this 
country than where the maintainers of this package live.


wide-dhcpv6-client doesn't seem to interpret the reply from the ISP as 
a valid one.


dibbler-client binds to the wrong LL address and fails to open a socket.

Copying the dhclient binary from a Fedora 38 install and using that 
works perfectly - which is using the Fedora patches for dhclient v4.4.3.


The current, functioning patch from Fedora is here:


How are we able to fix this properly instead of a 'copy the binary from 
Fedora' type fix?


--
Steven Haigh

 net...@crc.id.au 
 https://crc.id.au 

Bug#1041749: “/usr/libexec/gdm-x-session[…]: (WW) Warning, couldn't open module ast” followed by “/usr/libexec/gdm-x-session[968]: (EE) Failed to load module "ast" (module does not exist, 0)”

[Al Ma]

Package: gdm3
Version: 43.0-3
The machine in question has two graphic chips:
- ASPEED AST2500 64MB built into the motherboard and
- NVIDIA GeForce GTX 1660 Ti PCIe graphics card.
The ASPEED chip (/dev/dri/card0) has only a VGA port; nothing is connected to 
this D-SUB port. The NVIDIA card (/dev/dri/card1) has lots of ports; a properly 
functioning monitor Philips 275B1 is connected to the DisplayPort of the card, 
and the other ports are empty.
In the journal we see a warning and an error written there during boot:
/usr/libexec/gdm-x-session[…]: (WW) Warning, couldn't open module ast
/usr/libexec/gdm-x-session[…]: (EE) Failed to load module "ast" (module does 
not exist, 0)
>From a user's viewpoint, there's probably no error here and nothing to warn 
>about here, since the absence of anything connected to the VGA D-SUB port is 
>fine as long as a functioning monitor is connected elsewhere (in our case, to 
>the graphics card). I tried to specify the monitor as a command-line argument 
>“video=DP-1:2560x1440R”; does this help or can this even be improved?
If the (WW) and (EE) lines occur for a different reason than the absense of 
anything connected to the VGA D-SUB port, the reason should be visible in the 
journal (but it's not)!
The machine has other, related issues (cf. #1040497), which, hypothetically, 
may (or may not) interplay with this one.
The relevant parts of the journal and of the lshw and lspci outputs are 
attached.
By the way, after boot and after gdm3+gnome started, the module ast turns out 
to be even loaded (probably, for no good reason!):
# lsmod | grep ast
ast                    61440  1
drm_vram_helper        20480  1 ast
drm_ttm_helper         16384  3 drm_vram_helper,ast,nouveau
drm_kms_helper        204800  5 drm_vram_helper,ast,drm_display_helper,nouveau
drm                   614400  18 
drm_kms_helper,drm_vram_helper,ast,drm_display_helper,drm_ttm_helper,ttm,nouveau
i2c_algo_bit           16384  3 igb,ast,nouveau
Gratefully,
AlMa
Part of the journal:
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: (--) Log 
file renamed from "/var/lib/gdm3/.local/share/xorg/Xorg.pid-968.log" to 
"/var/lib/gdm3/.local/share/xorg/Xorg.0.log"
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: X.Org X 
Server 1.21.1.7
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: X 
Protocol Version 11, Revision 0
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: Current 
Operating System: Linux AnonymizedMachineName 6.1.0-10-amd64 #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.38-1 (2023-07-14) x86_64
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: Kernel 
command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-10-amd64 
root=UUID=794e56b5-1d18-4d73-849e-6d52f2eacce5 ro video=DP-1:2560x1440R
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: 
xorg-server 2:21.1.7-3 (https://www.debian.org/support)
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: Current 
version of pixman: 0.42.2
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: 
Before reporting problems, check http://wiki.x.org
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: 
to make sure that you have the latest version.
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: Markers: 
(--) probed, (**) from config file, (==) default setting,
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: 
(++) from command line, (!!) notice, (II) informational,
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: 
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: (==) Log 
file: "/var/lib/gdm3/.local/share/xorg/Xorg.0.log", Time: Sat Jul 22 22:35:25 
2023
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: (==) 
Using system config directory "/usr/share/X11/xorg.conf.d"
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: (==) No 
Layout section.  Using the first Screen section.
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: (==) No 
screen section available. Using defaults.
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: (**) 
|-->Screen "Default Screen Section" (0)
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: (**) |   
|-->Monitor ""
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: (==) No 
monitor specified for screen "Default Screen Section".
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: 
Using a default monitor configuration.
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: (==) 
Automatically adding devices
Jul 22 22:35:25 AnonymizedMachineName /usr/libexec/gdm-x-session[968]: (==) 
Automatically enabling devices
Jul 22 22:35:25 

Bug#1041748: snapper: feature idea: configure debian snapper package to append apt command as snapshot description

[Anchal Nigam]

Package: snapper
Version: 0.10.4-1
Severity: wishlist

Dear Maintainer,

Right now, on `debian`, snapper will take pre/post snapshots when you use `apt`
and set the snapshot description to `apt`. I think this is handled in the
80snapper file.

I had a few ideas for feature enhancement:

1. If an inline variable is set in the `apt` command call, add that to the
description. For example: `SD="doing something funky" sudo apt install funky`
would set the snapshot description to `apt; doing something funky`.

2. Add the `apt` command line arguments to the description. Using my above
example, the description might be something like `apt; install funky; doing
something funky`.

3. Maybe there could be a way to force an interactive mode that would ask the
user what the snapshot description should be.

Just a thought.


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

   * What led up to the situation? With the current configuration, the system
does automatically take snaptshots but thhe descriptions aren't very helpful.
With this idea, the snapshot descriptions would be more helpful.
   * What exactly did you do (or not do) that was effective (or ineffective)?
N/A
   * What was the outcome of this action? N/A
   * What outcome did you expect instead? The full apt command should be added
to the snapshot description.

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


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

Kernel: Linux 6.1.0-10-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

Versions of packages snapper depends on:
ii  libboost-thread1.74.0  1.74.0+ds1-21
ii  libc6  2.36-9
ii  libdbus-1-31.14.6-1
ii  libgcc-s1  12.2.0-14
ii  libjson-c5 0.16-2
ii  libmount1  2.38.1-5+b1
ii  libsnapper60.10.4-1
ii  libstdc++6 12.2.0-14
ii  libtinfo6  6.4-4

snapper recommends no packages.

snapper suggests no packages.

-- Configuration Files:
/etc/default/snapper changed [not included]

-- no debconf information

Bug#1037449: colord[…]: failed to get edid data: EDID length is too small

[Al Ma]

In the meantime, systemd and udev have been upgraded to version 
252.12-1~deb12u1 on a similar (but not identical) computer running Debian 12 
stable. There, this message seems to be unconnected to printers (because no 
printer is physically attached, and the only network printer is off). The 
relevant portion of the log is attached. I have not noticed any color issues so 
far. (Exception: my network printer – usually and now it's turned off – runs 
out of ink from time to time, but Linux knows nothing about this.)
Gratefully,
AlMa
Jul 22 22:35:24 AnonymizedMachineName systemd[1]: Starting colord.service - 
Manage, Install and Generate Color Profiles...
Jul 22 22:35:24 AnonymizedMachineName smartd[815]: Device: /dev/sda [SAT], 
state read from /var/lib/smartmontools/smartd.AnonymizedSerialOne.ata.state
Jul 22 22:35:24 AnonymizedMachineName smartd[815]: Device: /dev/nvme0, opened
Jul 22 22:35:24 AnonymizedMachineName smartd[815]: Device: /dev/nvme0, Samsung 
SSD 970 EVO 1TB, S/N:AnonymizedSerialTwo, FW:2B2QEXE7, 1.00 TB
Jul 22 22:35:24 AnonymizedMachineName smartd[815]: Device: /dev/nvme0, is SMART 
capable. Adding to "monitor" list.
Jul 22 22:35:24 AnonymizedMachineName smartd[815]: Device: /dev/nvme0, state 
read from 
/var/lib/smartmontools/smartd.Samsung_SSD_970_EVO_1TB-AnonymizedSerialTwo.nvme.state
Jul 22 22:35:24 AnonymizedMachineName smartd[815]: Monitoring 1 ATA/SATA, 0 
SCSI/SAS and 1 NVMe devices
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Info: Initial device: 
auto
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Info: Initial device: 
auto
Jul 22 22:35:24 AnonymizedMachineName lircd[884]: lircd-0.10.1[884]: Info: 
lircd:  Opening log, level: Info
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
driver: devinput
Jul 22 22:35:24 AnonymizedMachineName lircd[884]: lircd-0.10.1[884]: Notice: 
Using systemd fd
Jul 22 22:35:24 AnonymizedMachineName lircd[884]: lircd-0.10.1[884]: Warning: 
Running as root
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
output: /var/run/lirc/lircd
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
nodaemon: 1
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
plugindir: /usr/lib/x86_64-linux-gnu/lirc/plugins
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
logfile: syslog
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
immediate-init: 0
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
permission: 666
Jul 22 22:35:24 AnonymizedMachineName lircd[884]: lircd-0.10.1[884]: Info: 
Using remote: devinput-64.
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
driver-options:
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
pidfile: /var/run/lirc/lircd.pid
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
listen: 0
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
connect: (null)
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
userelease: 0
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
effective_user: (null)
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
release_suffix: _EVUP
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
allow_simulate: 0
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
repeat_max: 600
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
configfile: /etc/lirc/lircd.conf
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
dynamic_codes: (null)
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Current 
driver: devinput
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Driver API 
version: 4
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Driver  
version: 0.10.0
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Driver  info: 
See file:///usr/share/doc/lirc/plugindocs/devinput.html
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Info: lircd:  Opening 
log, level: Info
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Using systemd 
fd
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Warning: Running as 
root
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Info: Using remote: 
devinput-64.
Jul 22 22:35:24 AnonymizedMachineName lircd[884]: lircd-0.10.1[884]: Notice: 
/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-64: Multiple values for 
same code: BTN_MISC
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: 
/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-64: Multiple values for 
same code: BTN_MISC
Jul 22 22:35:24 AnonymizedMachineName lircd[884]: lircd-0.10.1[884]: Notice: 
/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-64: Multiple values for 
same code: 

Bug#1035885: iwlwifi: api flags index 2 larger than supported by driver

[Al Ma]

Dear iwlwifi developers,
I get a yellow warning in the journal: “iwlwifi :b3:00.0: api flags index 2 
larger than supported by driver”.
The card:
AX3000 Dual Band PCE-AX3000 Wi-Fi 6 PCI-E Adapter
The preceding journal entries:
Jul 22 22:35:22 AnonymizedMachineName kernel: iwlwifi :b3:00.0: enabling 
device (0100 -> 0102) Jul 22 22:35:22 AnonymizedMachineName kernel: [drm] 
Initialized ast 0.1.0 20120228 for :04:00.0 on minor 0 Jul 22 22:35:22 
AnonymizedMachineName kernel: AVX2 version of gcm_enc/dec engaged. Jul 22 
22:35:22 AnonymizedMachineName kernel: ipmi_si IPI0001:00: IPMI message 
handler: Found new BMC (man_id: 0x000a3f, prod_id: 0x0f83, dev_id: 0x20) Jul 22 
22:35:22 AnonymizedMachineName kernel: AES CTR mode by8 optimization enabled 
Jul 22 22:35:22 AnonymizedMachineName kernel: asus_wmi: ASUS WMI generic driver 
loaded Jul 22 22:35:22 AnonymizedMachineName kernel: Console: switching to 
colour frame buffer device 128x48 Jul 22 22:35:22 AnonymizedMachineName kernel: 
ast :04:00.0: [drm] fb0: astdrmfb frame buffer device Jul 22 22:35:22 
AnonymizedMachineName kernel: iwlwifi :b3:00.0: firmware: direct-loading 
firmware iwlwifi-cc-a0-72.ucode Jul 22 22:35:22 AnonymizedMachineName kernel: 
iwlwifi :b3:00.0: api flags index 2 larger than supported by driver
The relevant lshw portion:
*-pci:2 description: PCI bridge product: Sky Lake-E PCI Express Root Port A 
vendor: Intel Corporation physical id: 0 bus info: pci@:b2:00.0 version: 07 
width: 32 bits clock: 33MHz capabilities: pci msi pciexpress pm normal_decode 
bus_master cap_list configuration: driver=pcieport resources: irq:35 
memory:fbe0-fbef *-network description: Wireless interface product: 
Wi-Fi 6 AX200 vendor: Intel Corporation physical id: 0 bus info: 
pci@:b3:00.0 logical name: wlp179s0 version: 1a serial: AnonymizedSerial 
width: 64 bits clock: 33MHz capabilities: pm msi pciexpress msix bus_master 
cap_list ethernet physical wireless configuration: broadcast=yes driver=iwlwifi 
driverversion=6.1.0-10-amd64 firmware=72.daa05125.0 cc-a0-72.ucode 
ip=192.168.1.49 latency=0 link=yes multicast=yes wireless=IEEE 802.11 
resources: irq:94 memory:fbe0-fbe03fff
The relevant lspci portion:
b3:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a) Subsystem: 
Intel Corporation Wi-Fi 6 AX200NGW Control: I/O- Mem+ BusMaster+ SpecCycle- 
MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 
66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
http://bugs.debian.org/1035885 that the firmware probably 
advertises some features that the driver doesn't know how to use.  Perhaps, 
it's time to upgrade the driver?  Or is the aforementioned yellow message a 
real warning for me as an admin or a user, and I should take some action?
Gratefully,
AlMa

Bug#1041747: ITP: golang-github-containers-libtrust -- Primitives for identity and authorization

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-containers-libtrust
  Version : 0.0~git20230121.c1716e8-1
  Upstream Author : Containers
* URL : https://github.com/containers/libtrust
* License : Apache-2.0
  Programming Lang: Go
  Description : Primitives for identity and authorization

 Libtrust is library for managing authentication and authorization using
 public key cryptography.
 .
 Authentication is handled using the identity attached to the public key.
 Libtrust provides multiple methods to prove possession of the private
 key associated with an identity.
 .
  * TLS x509 certificates
  * Signature verification
  * Key Challenge
 .
 Authorization and access control is managed through a distributed trust
 graph. Trust servers are used as the authorities of the trust graph and
 allow caching portions of the graph for faster access.
 .
 This package contains a fork of Docker's libtrust that is being worked
 by the github containers commnuity.

Bug#1040956: Issue now in Bookworm

[Chris Talbot]

Hello,

Bookworm 12.1 now has systemd 252.12-1~deb12u1 , and this issue is
occuring on this systemd version.

-- 
Respectfully,
Chris Talbot

Bug#1041552: HFS/HFS+ are insecure

[Ben Hutchings]

On Fri, 2023-07-21 at 18:35 +0100, Matthew Garrett wrote:
> On Fri, Jul 21, 2023 at 10:55:39AM +0200, Marco d'Itri wrote:
> 
> > Unless somebody has a better idea then then my plan is to ship in the 
> > next upload of kmod a file in /etc/modprobe.d/ which uses the blacklist 
> > directive to prevent automatically loading some file system modules.
> 
> I think this would break any existing fstab entries that reference hfs 
> and hfsplus, and the convenient way to integrate Linux boot with x86 
> Macs is certainly to have an hfsplus EFI partition so this may be a 
> legitimate use-case. It also means that anyone who has a need to use one 
> of these filesystems in a static manner is vulnerable to automount 
> attacks using them.

Right, auto-loading of filesystems has to keep working.  And since
mount() of arbitrary filesystems is restricted to root (CAP_NET_ADMIN
in the initial namespace), we should let the callers apply a block- or
allow-list.

The reason we have to disable auto-loading of network protocols is that
socket creation is generally an unprivileged operation, so there's no
trusted user-space that can apply the policy (besides kmod).

> Completely untested, but I think something along the lines of:
> 
> SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end"
> ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0"
> ENV{ID_FS_TYPE}=="hfsplus", ENV{UDISKS_AUTO}="0"
> LABEL="udisks_insecure_fs_end"
> 
> in a udev fragment should work? Any static fstab or mount units should 
> still work, but it should disable udisks automounting regardless of the 
> desktop agent involved, even if the fs modules are already loaded.

I agree we should not have UDisks probing for any of the (many) kernel
filesystems that aren't being actively maintained including responding
to security issues.

Beyond that, I would also like to see libmount limiting the filesystems
that it will probe when the fstab type is "auto".  But since UDisks
normally handles mounting for unprivileged users, that's probably less
of a concern.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.



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

Bug#1041746: curl: libcurl4 links to a superset of libraries compared to libcurl3-gnutls

[Daniel Kahn Gillmor]

Source: curl
Version: 7.88.1-10
Severity: normal
X-Debbugs-Cc: d...@fifthhorseman.net

libcurl4 (and indeed, libcurl3-nss) both ship shared objects that
themselves link to a set of shared objects that are a strict superset
of the shared objects linked to by libcurl3-gnutls:

```
0 dkg@alice:~$ libs() { ldd "$1" | sort | sed s/0x.*// ; }
0 dkg@alice:~$ diff -u <(libs /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.8.0 
) <(libs /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4.8.0)
--- /dev/fd/63  2023-07-22 17:17:42.627000390 -0700
+++ /dev/fd/62  2023-07-22 17:17:42.627000390 -0700
@@ -18,12 +18,18 @@
libldap-2.5.so.0 => /lib/x86_64-linux-gnu/libldap-2.5.so.0 (
libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 (
libnghttp2.so.14 => /lib/x86_64-linux-gnu/libnghttp2.so.14 (
+   libnspr4.so => /lib/x86_64-linux-gnu/libnspr4.so (
+   libnss3.so => /lib/x86_64-linux-gnu/libnss3.so (
+   libnssutil3.so => /lib/x86_64-linux-gnu/libnssutil3.so (
libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (
+   libplc4.so => /lib/x86_64-linux-gnu/libplc4.so (
+   libplds4.so => /lib/x86_64-linux-gnu/libplds4.so (
libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 (
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (
librtmp.so.1 => /lib/x86_64-linux-gnu/librtmp.so.1 (
libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 (
libssh2.so.1 => /lib/x86_64-linux-gnu/libssh2.so.1 (
+   libssl3.so => /lib/x86_64-linux-gnu/libssl3.so (
libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (
libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (
1 dkg@alice:~$ diff -u <(libs /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.8.0 
) <(libs /usr/lib/x86_64-linux-gnu/libcurl.so.4.8.0)
--- /dev/fd/63  2023-07-22 17:17:48.623045082 -0700
+++ /dev/fd/62  2023-07-22 17:17:48.623045082 -0700
@@ -24,6 +24,7 @@
librtmp.so.1 => /lib/x86_64-linux-gnu/librtmp.so.1 (
libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 (
libssh2.so.1 => /lib/x86_64-linux-gnu/libssh2.so.1 (
+   libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (
libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (
libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (
1 dkg@alice:~$ 
```

What advantage is there for the library to link to these extra
libraries?  libcurl-gnutls seems like the minimal implementation here.

--dkg

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

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

-- no debconf information

Bug#1041743: Thx!

[Al Ma]

Ben, thank you for a quick reply! Issue created: 
https://gitlab.freedesktop.org/drm/nouveau/-/issues/246 
https://gitlab.freedesktop.org/drm/nouveau/-/issues/246. There I wonder: if the 
message is purely informational, it probably better really not be yellow (and 
thus warn the user because yellow means, AFAIK, a warning) but light-gray–white 
as usual.
Gratefully,
AlMa

Bug#1041745: smartd[…]: Device: /dev/nvme0, number of Error Log entries increased from … to …

[Al Ma]

Package: linux-image-6.1.0-10-amd64
Version: 6.1.38-1
Control: affects -1 src:linux smartmontools
In the journal I see a red error message of the form “smartd[…]: Device: 
/dev/nvme0, number of Error Log entries increased from 푛 to 푛+1”.  I think the 
number 푛 increases on each boot. The relevant portion of the log is attached. 
Is this a problem of software, firmware, or hardware?  In plain English, what 
is the real error?  What to do to avoid whichever havoc might occur?
Gratefully,
AlMa
Jul 22 22:35:24 AnonymizedMachineName smartd[815]: Device: /dev/nvme0, opened
Jul 22 22:35:24 AnonymizedMachineName smartd[815]: Device: /dev/nvme0, Samsung 
SSD 970 EVO 1TB, S/N:AnonymizedSerialOne, FW:2B2QEXE7, 1.00 TB
Jul 22 22:35:24 AnonymizedMachineName smartd[815]: Device: /dev/nvme0, is SMART 
capable. Adding to "monitor" list.
Jul 22 22:35:24 AnonymizedMachineName smartd[815]: Device: /dev/nvme0, state 
read from 
/var/lib/smartmontools/smartd.Samsung_SSD_970_EVO_1TB-AnonymizedSerialOne.nvme.state
Jul 22 22:35:24 AnonymizedMachineName smartd[815]: Monitoring 1 ATA/SATA, 0 
SCSI/SAS and 1 NVMe devices
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Info: Initial device: 
auto
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Info: Initial device: 
auto
Jul 22 22:35:24 AnonymizedMachineName lircd[884]: lircd-0.10.1[884]: Info: 
lircd:  Opening log, level: Info
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
driver: devinput
Jul 22 22:35:24 AnonymizedMachineName lircd[884]: lircd-0.10.1[884]: Notice: 
Using systemd fd
Jul 22 22:35:24 AnonymizedMachineName lircd[884]: lircd-0.10.1[884]: Warning: 
Running as root
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
output: /var/run/lirc/lircd
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
nodaemon: 1
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
plugindir: /usr/lib/x86_64-linux-gnu/lirc/plugins
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
logfile: syslog
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
immediate-init: 0
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
permission: 666
Jul 22 22:35:24 AnonymizedMachineName lircd[884]: lircd-0.10.1[884]: Info: 
Using remote: devinput-64.
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
driver-options:
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
pidfile: /var/run/lirc/lircd.pid
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
listen: 0
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
connect: (null)
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
userelease: 0
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
effective_user: (null)
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
release_suffix: _EVUP
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
allow_simulate: 0
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
repeat_max: 600
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
configfile: /etc/lirc/lircd.conf
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Options: 
dynamic_codes: (null)
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Current 
driver: devinput
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Driver API 
version: 4
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Driver  
version: 0.10.0
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Driver  info: 
See file:///usr/share/doc/lirc/plugindocs/devinput.html
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Info: lircd:  Opening 
log, level: Info
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: Using systemd 
fd
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Warning: Running as 
root
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Info: Using remote: 
devinput-64.
Jul 22 22:35:24 AnonymizedMachineName lircd[884]: lircd-0.10.1[884]: Notice: 
/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-64: Multiple values for 
same code: BTN_MISC
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: 
/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-64: Multiple values for 
same code: BTN_MISC
Jul 22 22:35:24 AnonymizedMachineName lircd[884]: lircd-0.10.1[884]: Notice: 
/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-64: Multiple values for 
same code: BTN_MOUSE
Jul 22 22:35:24 AnonymizedMachineName lircd[884]: lircd-0.10.1[884]: Notice: 
/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-64: Multiple values for 
same code: BTN_SOUTH
Jul 22 22:35:24 AnonymizedMachineName lircd-0.10.1[884]: Notice: 
/etc/lirc/lircd.conf.d/devinput.lircd.conf: devinput-64: Multiple 

Bug#1041744: kernel: thermal thermal_zone0: failed to read out thermal zone (-61)

[Al Ma]

Package: linux-image-6.1.0-10-amd64 Version: 6.1.38-1 Control: affects -1 
src:linux
In the journal of a computer with motherboard ASUS WS C422 PRO/SE and Intel® 
Xeon® W-2235 CPU @ 3.80GHz, 32 GB RAM, ASPEED AST2500 64MB built-in graphics 
chip, and NVIDIA GeForce GTX 1660 Ti PCIe graphics card, we see the yellow 
warning “thermal thermal_zone0: failed to read out thermal zone (-61)”. Is this 
a problem of software, firmware, or hardware?  In plain English, what are we 
really warned about?  What to do to avoid whichever havoc might occur?  The 
probably relevant portions of the journal, lshw, and lspci are attached.
Gratefully,
AlMa
In journal:
Jul 22 22:35:23 AnonymizedMachineName kernel: nouveau :65:00.0: vgaarb: 
deactivate vga console
Jul 22 22:35:23 AnonymizedMachineName kernel: nouveau :65:00.0: NVIDIA 
TU116 (168000a1)
Jul 22 22:35:23 AnonymizedMachineName kernel: ipmi_si IPI0001:00: IPMI kcs 
interface initialized
Jul 22 22:35:23 AnonymizedMachineName systemd[1]: Mounting boot-efi.mount - 
/boot/efi...
Jul 22 22:35:23 AnonymizedMachineName systemd[1]: Mounting home.mount - /home...
Jul 22 22:35:23 AnonymizedMachineName systemd[1]: Mounting 
media-AnonymizedLabelOne.mount - /media/AnonymizedLabelOne...
Jul 22 22:35:23 AnonymizedMachineName systemd[1]: Mounting 
media-AnonymizedLabelTwo.mount - /media/AnonymizedLabelTwo...
Jul 22 22:35:23 AnonymizedMachineName systemd[1]: tmp.mount: Directory /tmp to 
mount over is not empty, mounting anyway.
Jul 22 22:35:23 AnonymizedMachineName systemd[1]: Mounting tmp.mount - /tmp...
Jul 22 22:35:23 AnonymizedMachineName systemd[1]: Mounted tmp.mount - /tmp.
Jul 22 22:35:23 AnonymizedMachineName kernel: ipmi_ssif: IPMI SSIF Interface 
driver
Jul 22 22:35:23 AnonymizedMachineName ntfs-3g[698]: Version 2022.10.3 
integrated FUSE 28
Jul 22 22:35:23 AnonymizedMachineName ntfs-3g[698]: Mounted /dev/nvme0n1p5 
(Read-Write, label "", NTFS 3.1)
Jul 22 22:35:23 AnonymizedMachineName systemd[1]: Mounted 
media-AnonymizedLabelTwo.mount - /media/AnonymizedLabelTwo.
Jul 22 22:35:23 AnonymizedMachineName ntfs-3g[698]: Cmdline options: 
rw,noatime,discard,commit=120
Jul 22 22:35:23 AnonymizedMachineName ntfs-3g[698]: Mount options: 
discard,commit=120,allow_other,nonempty,noatime,rw,fsname=/dev/nvme0n1p5,blkdev,blksize=4096
Jul 22 22:35:23 AnonymizedMachineName ntfs-3g[698]: Ownership and permissions 
disabled, configuration type 7
Jul 22 22:35:23 AnonymizedMachineName kernel: iwlwifi :b3:00.0: Detected 
Intel(R) Wi-Fi 6 AX200 160MHz, REV=0x340
Jul 22 22:35:23 AnonymizedMachineName kernel: thermal thermal_zone0: failed to 
read out thermal zone (-61)
Jul 22 22:35:23 AnonymizedMachineName kernel: nouveau :65:00.0: bios: 
version 90.16.29.00.a9

# journalctl -b | grep -i -C 1 thermal
Jul 22 22:35:22 AnonymizedMachineName kernel: Mountpoint-cache hash table 
entries: 65536 (order: 7, 524288 bytes, linear)
Jul 22 22:35:22 AnonymizedMachineName kernel: CPU0: Thermal monitoring enabled 
(TM1)
Jul 22 22:35:22 AnonymizedMachineName kernel: process: using mwait in idle 
threads
--
Jul 22 22:35:22 AnonymizedMachineName kernel: audit: type=2000 
audit(1690058117.100:1): state=initialized audit_enabled=0 res=1
Jul 22 22:35:22 AnonymizedMachineName kernel: thermal_sys: Registered thermal 
governor 'fair_share'
Jul 22 22:35:22 AnonymizedMachineName kernel: thermal_sys: Registered thermal 
governor 'bang_bang'
Jul 22 22:35:22 AnonymizedMachineName kernel: thermal_sys: Registered thermal 
governor 'step_wise'
Jul 22 22:35:22 AnonymizedMachineName kernel: thermal_sys: Registered thermal 
governor 'user_space'
Jul 22 22:35:22 AnonymizedMachineName kernel: thermal_sys: Registered thermal 
governor 'power_allocator'
Jul 22 22:35:22 AnonymizedMachineName kernel: cpuidle: using governor ladder
--
Jul 22 22:35:23 AnonymizedMachineName kernel: iwlwifi :b3:00.0: Detected 
Intel(R) Wi-Fi 6 AX200 160MHz, REV=0x340
Jul 22 22:35:23 AnonymizedMachineName kernel: thermal thermal_zone0: failed to 
read out thermal zone (-61)
Jul 22 22:35:23 AnonymizedMachineName kernel: nouveau :65:00.0: bios: 
version 90.16.29.00.a9

Part of the output of lshw (searched for “thermal”):
*-generic:14 UNCLAIMED
 description: Signal processing controller
 product: 200 Series PCH Thermal Subsystem
 vendor: Intel Corporation
 physical id: 14.2
 bus info: pci@:00:14.2
 version: 00
 width: 64 bits
 clock: 33MHz
 capabilities: pm msi cap_list
 configuration: latency=0
 resources: memory:9094e000-9094efff

Part of the output of lspci (searched for “thermal”):
00:14.2 Signal processing controller: Intel Corporation 200 Series PCH Thermal 
Subsystem
DeviceName: Onboard - Other
Subsystem: ASUSTeK Computer Inc. 200 Series PCH Thermal Subsystem
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-

Bug#1035312: minetest: New upstream version available (5.7.0)

[tuxayo]

Hi :)

Hopefully the update is easy, the arch package changelog shows only tag 
bumps for MT and irrlichtmt.


https://gitlab.archlinux.org/archlinux/packaging/packages/minetest/-/commit/88eb2e21e5c813103bae315b77b464ff9c28eafe

Cheers,

--
tuxayo

Bug#1041731: groff-base: "-" mapped as HYPHEN

[Colin Watson]

On Sat, Jul 22, 2023 at 06:46:28PM +0200, Sven Joachim wrote:
> This version of groff maps an unescaped "-" to HYPHEN rather than
> HYPHEN-MINUS.  Due to that, copying text from manpages or following
> references in the "SEE ALSO" section is rather unreliable, because many
> manpages contain a plain "-" where they should have used "\-" instead.
> 
> Neither the upstream NEWS file nor the Debian changelog make any mention
> of this change, or how to revert it locally.  Running "man" under
> LC_ALL=C works around it, at the cost of worse typography.

It is in fact mentioned in the upstream NEWS file:

  o The an (man) and doc (mdoc) macro packages no longer remap the -, ',
and ` input characters to Basic Latin code points on UTF-8 devices,
but treat them as groff normally does (and AT troff before it did)
for typesetting devices, where they become the hyphen, apostrophe or
right single quotation mark, and left single quotation mark,
respectively.  This change is expected to expose glyph usage errors in
man pages.  See the "PROBLEMS" file for a recipe that will conceal
these errors.  A better long-term approach is for man pages to adopt
correct input practices; the man pages groff_man_style(7),
groff_char(7), and man-pages(7) (subsection "Generating optimal
glyphs"; from the Linux man-pages project) contain such instructions.
Doing so also improves man page typography when formatting for PDF.
  
If you maintain a generator of man(7) or mdoc(7) documents (such as a
tool that converts other formats to them), and need assistance, please
contact the gr...@gnu.org mailing list and describe your situation.

And the PROBLEMS file says:

  * When viewing man pages, some characters on my UTF-8 terminal emulator
look funny or copy-and-paste wrong.  Why?
  
  Some Unicode Basic Latin ("ASCII") input characters are mapped to
  non-Basic Latin code points in output for consistency with other output
  devices, like PDF.  See groff_man_style(7) and groff_char(7) for correct
  input conventions and background.  If you use the correct groff special
  character escape sequences to input them, you will get correct output no
  matter what device the input is formatted for.
  
  However, many man pages are written in ignorance of the correct special
  characters to obtain the desired glyphs.  You can conceal these errors
  by adding the following to your site-local man(7) configuration.  The
  file is called "man.local"; its installation directory depends on how
  groff was configured when it was built.
  
  --- start ---
  .if '\*[.T]'utf8' \{\
  .  char ' \[aq]
  .  char - \-
  .  char ^ \[ha]
  .  char ` \[ga]
  .  char ~ \[ti]
  .\}
  --- end ---
  
  You may also wish to do the same for "mdoc.local".
  
  In man pages (only), groff maps the minus sign special character '\-' to
  the Basic Latin hyphen-minus (U+002D) because man pages require this
  glyph and there is no historically established *roff input character,
  ordinary or special, for obtaining it when a hyphen and minus sign are
  both separately available.  To obtain a true minus sign, use the special
  character escape sequences '\(mi' or '\[mi]'.

I admit I overlooked this; I was aware of the change, but it somehow
fell off my list of things to make a positive decision about when
packaging 1.23.0.  I'm rather inclined to revert this by adding the rest
of the recipe above to debian/mandoc.local (while I agree with the
idealized typographical point being made, I have approximately negative
appetite for the Sisyphean task of fixing an entire distribution's
manual pages in practice), but I'll let this suggestion sit for a few
days in case anyone wants to make a reasoned argument against it in the
meantime.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1038603: libisl23 0.25-1: amd64/i386 baseline violation: uses BMI instructions)

[Roman Lebedev]

Package: libisl23
Followup-For: Bug #1038603
X-Debbugs-Cc: Debian GCC Maintainers , 
debian-rele...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

While the issue has been resolved in isl 0.26-3,
which was uploaded to unstable on 2023-06-19,
nothing has been done for the stable release,
and Debian 12.1 still comes with a "miscompiled" isl 0.25-1,
and thus gcc is still somewhat unusable(*) on older hardware(**)

This occasionally manifests as spurious failures
on e.g. https://build.opensuse.org/

* As long as no graphite optimizations are enabled it's perfectly usable.
** Older than the one on which it was built,
   roughly anything pre-Ryzen / pre-Haswell.

Roman.

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

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

Versions of packages libisl23 depends on:
ii  libc6 2.37-6
ii  libgmp10  2:6.2.1+dfsg1-1.1

libisl23 recommends no packages.

libisl23 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE+UikBxeiu50LOdFYgbqkFMWfZdAFAmS8Z4MACgkQgbqkFMWf
ZdA8tQ/8DU/KIBQIMCSGOOGioxM8Bo/bHpUjMiurfKJsTKu26qaR5puhsvNUCGoE
PzyJYZFJgHeGNi0/vbbGVIbu4+1NcfaWngwEVynJj2vK7Naf2fm2FYVzRoYA4obD
KpLz9viwdkjdp10Dgstvike8RYGw3g5MOD56Qk6ct6kaI3yiOciyTxzRTHU6csN2
WMCEzdSUI9T530NeXOyTZriYS17WathHqQHgugnQUbrEJsGoe7OYMHqOfC01F2Gr
+VmElssLIp669+VHADPyFgSdwbcgSjpXCHN2+qfC2s4MrIsPfdZzL2XrF2Qz5AJY
wAknMa0dV7YVSI5c8nAje77cAvGkGxuEXu9eN61B4KuzBjRih9trAQS9J3Zucq2g
VSCVYcquDsttGRDV5Nblb2X+iTFP37LNNnCl72QM35lnQneMHW3B8Ggw8vdl8ysq
1rsERMHjGVivdczQO2QeM4e+joSHw8ExjbBeHr7E1HV3rqcm/XpUoieZodBT0KuX
gszv6a3dLD1n4WfuleYNsEeWJl/rZnHsdOo6JXOTyR2jesDMV6uxxWzz8eR2Un4H
k6mrSi4S6Ysf6KyJ3rT7DwSb9VBRIO/z+yRykUrUyrSiLD2U/WyXVfnZQNQANtFm
V3GQTQM3I48IydJUHuzjtxGdTDIGDhZ6Z5SLqvNGyIV6QpYeIO4=
=2jT8
-END PGP SIGNATURE-

Bug#1041743: kernel: MXM: GUID detected in BIOS

[Al Ma]

Package: linux-image-6.1.0-10-amd64
Version: 6.1.38-1
Control: affects -1 src:linux
In the journal I discover the yellow warning “MXM: GUID detected in BIOS”.  Is 
this a software, a firmware, or a hardware problem?  In plain English, what are 
we really warned about?  What to do to avoid whichever havoc might occur?  The 
relevant portion of the journal:
Jul 22 22:35:22 AnonymizedMachineName kernel: asus_wmi: Initialization: 0x0
Jul 22 22:35:22 AnonymizedMachineName kernel: asus_wmi: BIOS WMI version: 0.9
Jul 22 22:35:22 AnonymizedMachineName kernel: asus_wmi: SFUN value: 0x0
Jul 22 22:35:22 AnonymizedMachineName kernel: eeepc-wmi eeepc-wmi: Detected 
ASUSWMI, use DCTS
Jul 22 22:35:22 AnonymizedMachineName kernel: input: Eee PC WMI hotkeys as 
/devices/platform/eeepc-wmi/input/input7
Jul 22 22:35:22 AnonymizedMachineName kernel: usb 1-11.4.2: Found UVC 1.50 
device USB2.0 FHD UVC WebCam (04f2:b612)
Jul 22 22:35:23 AnonymizedMachineName kernel: input: USB2.0 FHD UVC WebCam: 
USB2.0 F as 
/devices/pci:00/:00:14.0/usb1/1-11/1-11.4/1-11.4.2/1-11.4.2:1.0/input/input8
Jul 22 22:35:23 AnonymizedMachineName kernel: usb 1-11.4.2: Found UVC 1.50 
device USB2.0 FHD UVC WebCam (04f2:b612)
Jul 22 22:35:23 AnonymizedMachineName kernel: input: USB2.0 FHD UVC WebCam: IR 
Camer as 
/devices/pci:00/:00:14.0/usb1/1-11/1-11.4/1-11.4.2/1-11.4.2:1.2/input/input9
Jul 22 22:35:23 AnonymizedMachineName kernel: usbcore: registered new interface 
driver uvcvideo
Jul 22 22:35:23 AnonymizedMachineName kernel: MXM: GUID detected in BIOS
Gratefully,
AlMa

Bug#1041704: $MANWIDTH does not overwrite explicit line length in "~/.manpath"

[Colin Watson]

On Sat, Jul 22, 2023 at 01:10:23PM +, Bjarni Ingi Gislason wrote:
> In my ".manpath" for "nroff" was:
> 
> DEFINE nroff test-nroff -b -ww -mandoc -rF=0  -P-i -rHY=0 -dAD=l 
> -rCHECKSTYLE=0 -rLL=90m
> 
> Changing the line length with, say "export MANWIDTH=80", had no effect.

I believe this can be fixed as follows:

diff --git a/src/man.c b/src/man.c
index 70d0dc7a..68515eed 100644
--- a/src/man.c
+++ b/src/man.c
@@ -685,8 +685,7 @@ static int get_roff_line_length (void)
 {
int line_length = cat_width ? cat_width : get_line_length ();
 
-   /* groff >= 1.18 defaults to 78. */
-   if ((!troff || ditroff) && line_length != 80) {
+   if (!troff || ditroff) {
int length = line_length * 39 / 40;
if (length > line_length - 2)
return line_length - 2;

This may be the right thing to do.  However, it will mean that the -rLL
in your ~/.manpath is always overridden, so I don't understand why
you're going to the effort of specifying it explicitly in the first
place if you want it to be overridden.  Can you explain why you're doing
this?

> N.B.

Including multiple semi-related issues in a single bug report should be
deprecated (it makes bug tracking significantly more annoying), and my
practice is typically to disregard things that aren't the main subject
of the bug report unless they really are trivial to fix; I have too much
to do to pick up on every passing comment.  If you think something is
important enough to mention, then it's probably important enough to
justify its own bug report.  However, just a few quick notes:

>   Most(?) tests (searches) are a waste, as the option '-l' is used.

There's no actual searching going on here.  It's basically all just
generic setup.

>   The search for "andoc" should start with "andoc.tmac".

No, because what you're seeing here seems to be the effect of something
like SYSTEM=andoc (or equivalent - I'd suggest that perhaps you might
have an alias for "man" that adds the "-mandoc" option, except that
you've said that you're calling /usr/bin/man explicitly which would
presumably bypass any such alias).  That feature does _not_ mean the
same thing as the -m option in *roff, and it's unrelated to reading
.tmac files.

I don't know why you would be setting that variable if you aren't
intending to use the rather obscure feature of reading manual pages from
other installed operating systems.  If that's not what you want, then I
suggest not asking man(1) for it.

> "man -l ..." : "bash-completion" is not active.

Improving bash-completion for man(1) should definitely be a separate bug
report, not least because right now the completion for man(1) is not
handled by the man-db package at all (though perhaps it should be).  I
won't deal with it further in this bug report.

>  Do not use "atoi" (atoi(3)).

While I agree that functions with better error handling are generally
better, in context I don't consider these particular uses important
enough to be worth spending time on.  If you think they are, I'm happy
to review patches.

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1035885: kernel: iwlwifi 0000:b3:00.0: api flags index 2 larger than supported by driver

[Al Ma]

The warning is still there after upgrading the kernel to 
linux-image-6.1.0-10-amd64 version 6.1.38-1. The logs are attached.
Jul 22 22:35:22 AnonymizedMachineName kernel: iwlwifi :b3:00.0: enabling 
device (0100 -> 0102)
Jul 22 22:35:22 AnonymizedMachineName kernel: [drm] Initialized ast 0.1.0 
20120228 for :04:00.0 on minor 0
Jul 22 22:35:22 AnonymizedMachineName kernel: AVX2 version of gcm_enc/dec 
engaged.
Jul 22 22:35:22 AnonymizedMachineName kernel: ipmi_si IPI0001:00: IPMI message 
handler: Found new BMC (man_id: 0x000a3f, prod_id: 0x0f83, dev_id: 0x20)
Jul 22 22:35:22 AnonymizedMachineName kernel: AES CTR mode by8 optimization 
enabled
Jul 22 22:35:22 AnonymizedMachineName kernel: asus_wmi: ASUS WMI generic driver 
loaded
Jul 22 22:35:22 AnonymizedMachineName kernel: Console: switching to colour 
frame buffer device 128x48
Jul 22 22:35:22 AnonymizedMachineName kernel: ast :04:00.0: [drm] fb0: 
astdrmfb frame buffer device
Jul 22 22:35:22 AnonymizedMachineName kernel: iwlwifi :b3:00.0: firmware: 
direct-loading firmware iwlwifi-cc-a0-72.ucode
Jul 22 22:35:22 AnonymizedMachineName kernel: iwlwifi :b3:00.0: api flags 
index 2 larger than supported by driver


 *-pci:2
  description: PCI bridge
  product: Sky Lake-E PCI Express Root Port A
  vendor: Intel Corporation
  physical id: 0
  bus info: pci@:b2:00.0
  version: 07
  width: 32 bits
  clock: 33MHz
  capabilities: pci msi pciexpress pm normal_decode bus_master cap_list
  configuration: driver=pcieport
  resources: irq:35 memory:fbe0-fbef
*-network
 description: Wireless interface
 product: Wi-Fi 6 AX200
 vendor: Intel Corporation
 physical id: 0
 bus info: pci@:b3:00.0
 logical name: wlp179s0
 version: 1a
 serial: AnonymizedSerial
 width: 64 bits
 clock: 33MHz
 capabilities: pm msi pciexpress msix bus_master cap_list ethernet 
physical wireless
 configuration: broadcast=yes driver=iwlwifi 
driverversion=6.1.0-10-amd64 firmware=72.daa05125.0 cc-a0-72.ucode 
ip=192.168.1.49 latency=0 link=yes multicast=yes wireless=IEEE 802.11
 resources: irq:94 memory:fbe0-fbe03fff

Bug#966218: iwlwifi 0000:b3:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)

[Al Ma]

found 966218 src:linux/6.1.0-10
found 966218 linux/6.1.0-10
found 966218 linux-image-6.1.0-10-amd64/6.1.38-1
found 966218 firmware-iwlwifi/20230210-5
thanks
The errors in the journal still occur by default (i.e., without any options) 
with ASUS AX3000 Dual Band PCE-AX3000 Wi-Fi PCI-E Adapter. The relevant 
portions of the journal and lshw are attached. The line portions
iwlwifi :b3:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
firmware_class: See https://wiki.debian.org/Firmware for information about 
missing firmware
iwlwifi :b3:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
are red. As for creating /etc/modprobe.d/iwlwifi.conf with a single line
options iwlwifi enable_ini=N
: is the type still boolean? In 
https://patchwork.kernel.org/project/linux-wireless/patch/iwlwifi.20220304131517.4929e4b14956.I1bdffa4c37d4ee349aa0001978b716b96e38b090@changeid/
 
https://patchwork.kernel.org/project/linux-wireless/patch/iwlwifi.20220304131517.4929e4b14956.I1bdffa4c37d4ee349aa0001978b716b96e38b090@changeid/
 they tried to change it to integer, but I might be looking in a wrong place.  
Further, I'm feeling very uncomfortable about changing something I don't really 
understand (the option is not really documented) that should be done by the 
system itself (kernel or firmware). Whoever is responsible for the mess should 
also resolve it!
Gratefully,
AlMa
Jul 22 22:35:22 AnonymizedMachineName kernel: ast :04:00.0: [drm] fb0: 
astdrmfb frame buffer device
Jul 22 22:35:22 AnonymizedMachineName kernel: iwlwifi :b3:00.0: firmware: 
direct-loading firmware iwlwifi-cc-a0-72.ucode
Jul 22 22:35:22 AnonymizedMachineName kernel: iwlwifi :b3:00.0: api flags 
index 2 larger than supported by driver
Jul 22 22:35:22 AnonymizedMachineName kernel: iwlwifi :b3:00.0: 
TLV_FW_FSEQ_VERSION: FSEQ Version: 89.3.35.37
Jul 22 22:35:22 AnonymizedMachineName kernel: iwlwifi :b3:00.0: firmware: 
failed to load iwl-debug-yoyo.bin (-2)
Jul 22 22:35:22 AnonymizedMachineName kernel: firmware_class: See 
https://wiki.debian.org/Firmware for information about missing firmware
Jul 22 22:35:22 AnonymizedMachineName kernel: iwlwifi :b3:00.0: firmware: 
failed to load iwl-debug-yoyo.bin (-2)
Jul 22 22:35:22 AnonymizedMachineName kernel: iwlwifi :b3:00.0: loaded 
firmware version 72.daa05125.0 cc-a0-72.ucode op_mode iwlmvm


 *-pci:2
  description: PCI bridge
  product: Sky Lake-E PCI Express Root Port A
  vendor: Intel Corporation
  physical id: 0
  bus info: pci@:b2:00.0
  version: 07
  width: 32 bits
  clock: 33MHz
  capabilities: pci msi pciexpress pm normal_decode bus_master cap_list
  configuration: driver=pcieport
  resources: irq:35 memory:fbe0-fbef
*-network
 description: Wireless interface
 product: Wi-Fi 6 AX200
 vendor: Intel Corporation
 physical id: 0
 bus info: pci@:b3:00.0
 logical name: wlp179s0
 version: 1a
 serial: AnonymizedSerial
 width: 64 bits
 clock: 33MHz
 capabilities: pm msi pciexpress msix bus_master cap_list ethernet 
physical wireless
 configuration: broadcast=yes driver=iwlwifi 
driverversion=6.1.0-10-amd64 firmware=72.daa05125.0 cc-a0-72.ucode 
ip=192.168.1.49 latency=0 link=yes multicast=yes wireless=IEEE 802.11
 resources: irq:94 memory:fbe0-fbe03fff

Bug#1038912: libreswan: build-depends on deprecated libcurl4-nss-dev, will be dropped in August 2023

[Daniel Kahn Gillmor]

Control: forwarded 1038912 https://github.com/libreswan/libreswan/issues/1202

On Fri 2023-06-23 00:49:24 +0100, Samuel Henrique wrote:
> This package build-depends on the NSS variant of libcurl "libcurl4-nss-dev".
>
> Curl's upstream announced support for NSS is going to be dropped in August
> 2023:
> https://curl.se/dev/deprecate.html#nss

Thanks for the heads-up on this, Samuel.

As i wrote over at https://github.com/libreswan/libreswan/issues/1202:

AFAICT, libreswan currently uses curl only for fetching CRLs over
HTTPS in the pluto daemon, entirely in programs/pluto/fetch.c.

Since libreswan depends on libnss, of course it is reasonable to
depend on the NSS variant of curl. But as of next month that won't
be a supported configuration.

If we build pluto against the OpenSSL or GnuTLS variant of curl,
then pluto will depend on two different cryptography libraries (NSS
directly, and whatever libcurl transitively depends on). That's
unsightly and a bit bloaty, but probably still functional.

Alternately, maybe there's some other HTTP client library that
libreswan wants to move to that can support NSS as a crypto backend?

If i hear nothing from upstream, i'll probably try switching debian's
libreswan package to use libcurl-gnutls-dev.

Happy to hear other recommendations if other people want to offer them.

  --dkg


signature.asc
Description: PGP signature

Bug#1003372: ITP: oci-cli -- Command Line Interface for Oracle Cloud Infrastructure

[Paul Wise]

Control: retitle 1003714 RFP: oci-cli -- Command Line Interface for Oracle 
Cloud Infrastructure
Control: noowner 1003714
Control: retitle 1003372 RFP: oci-python-sdk -- Oracle Cloud Infrastructure 
Python SDK
Control: noowner 1003372

On Fri, 14 Jan 2022 14:03:07 +0800 Paul Wise wrote:

> * Package name: oci-cli
...
>   Description : Command Line Interface for Oracle Cloud Infrastructure
> 
> It depends on oci-python-sdk, which I also intend to package (#1003372).

I no longer intend to package oci-cli or oci-python-sdk, but there may
be other folks using Oracle Cloud Infrastructure, so making these RFPs.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1019013:

[Jordan Justen]

Control: retitle -1 ITA: nix -- Purely functional package manager (binaries)
Control: owner -1 !

Bug#1041742: RFS: keepassxc-proxy-client/0.1.6-1 [ITP] -- Library to access a running KeepassXC instance

[Antonio Russo]

Package: sponsorship-requests
Severity: wishlist
Control: block 1041718 by -1

Dear mentors,

I am looking for a sponsor for my package "keepassxc-proxy-client":

  * Package name : keepassxc-proxy-client
Version  : 0.1.6-1
Upstream contact : Henrik Böving 
  * URL  : https://github.com/hargoniX/keepassxc-proxy-client
  * License  : ISC
  * Vcs  : 
https://salsa.debian.org/aerusso-guest/keepassxc-proxy-client
Section  : python

The source builds the following binary packages:

   keepassxc-proxy-client - Library to access a running KeepassXC instance

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

   https://mentors.debian.net/package/keepassxc-proxy-client/

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

   dget -x 
https://mentors.debian.net/debian/pool/main/k/keepassxc-proxy-client/keepassxc-proxy-client_0.1.6-1.dsc

Changes for the initial release:

 keepassxc-proxy-client (0.1.6-1) unstable; urgency=medium
 .
   * Initial release (Closes: #1041718)

Best,
Antonio Russo

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041741: kernel: nvme nvme0: missing or invalid SUBNQN field.

[Al Ma]

Package: linux-image-6.1.0-10-amd64
Version: 6.1.38-1
Control: affects -1 scr:linux
On an ASUS WS C422 PRO/SE with a Samsung SSD 970 EVO 1TB, I get a yellow kernel 
warning in the journal: “nvme nvme0: missing or invalid SUBNQN field.”  The 
relevant parts of the logs are attached. A software issue in the kernel or a 
firmware/hardware issue of the NVMe SSD? Anything to upgrade? I could run the 
software from https://www.samsung.com/de/support/model/MZ-V7E1T0BW , but the 
drivers there seem old, from year 2000, so I'm not sure whether they are of any 
help or would make things worse (and whether they upgrade the firmware at all 
or concern just Windows).
Gratefully,
AlMa
excerpt from the journal:
Jul 22 22:35:22 AnonymizedMachineName kernel: nvme nvme0: pci function 
:09:00.0
Jul 22 22:35:22 AnonymizedMachineName kernel: xhci_hcd :05:00.0: hcc params 
0x0200ef80 hci version 0x110 quirks 0x00800010
Jul 22 22:35:22 AnonymizedMachineName kernel: xhci_hcd :05:00.0: xHCI Host 
Controller
Jul 22 22:35:22 AnonymizedMachineName kernel: xhci_hcd :05:00.0: new USB 
bus registered, assigned bus number 6
Jul 22 22:35:22 AnonymizedMachineName kernel: xhci_hcd :05:00.0: Host 
supports USB 3.1 Enhanced SuperSpeed
Jul 22 22:35:22 AnonymizedMachineName kernel: usb usb5: New USB device found, 
idVendor=1d6b, idProduct=0002, bcdDevice= 6.01
Jul 22 22:35:22 AnonymizedMachineName kernel: usb usb5: New USB device strings: 
Mfr=3, Product=2, SerialNumber=1
Jul 22 22:35:22 AnonymizedMachineName kernel: usb usb5: Product: xHCI Host 
Controller
Jul 22 22:35:22 AnonymizedMachineName kernel: usb usb5: Manufacturer: Linux 
6.1.0-10-amd64 xhci-hcd
Jul 22 22:35:22 AnonymizedMachineName kernel: usb usb5: SerialNumber: 
:05:00.0
Jul 22 22:35:22 AnonymizedMachineName kernel: hub 5-0:1.0: USB hub found
Jul 22 22:35:22 AnonymizedMachineName kernel: hub 5-0:1.0: 2 ports detected
Jul 22 22:35:22 AnonymizedMachineName kernel: usb usb6: We don't know the 
algorithms for LPM for this host, disabling LPM.
Jul 22 22:35:22 AnonymizedMachineName kernel: usb usb6: New USB device found, 
idVendor=1d6b, idProduct=0003, bcdDevice= 6.01
Jul 22 22:35:22 AnonymizedMachineName kernel: nvme nvme0: missing or invalid 
SUBNQN field.


excerpt from lshw:
*-pci:7
 description: PCI bridge
 product: 200 Series PCH PCI Express Root Port #9
 vendor: Intel Corporation
 physical id: 1d
 bus info: pci@:00:1d.0
 version: f0
 width: 32 bits
 clock: 33MHz
 capabilities: pci pciexpress msi pm normal_decode bus_master 
cap_list
 configuration: driver=pcieport
 resources: irq:32 memory:9040-904f
   *-nvme
description: NVMe device
product: Samsung SSD 970 EVO 1TB
vendor: Samsung Electronics Co Ltd
physical id: 0
bus info: pci@:09:00.0
logical name: /dev/nvme0
version: 2B2QEXE7
serial: AnonymizedSerial
width: 64 bits
clock: 33MHz
capabilities: nvme pm msi pciexpress msix nvm_express 
bus_master cap_list
configuration: driver=nvme latency=0 
nqn=nqn.2014.08.org.nvmexpress:144d144dAnonymizedSerial Samsung SSD 970 EVO 
1TB state=live
resources: irq:16 memory:9040-90403fff

Bug#1019013: (no subject)

[Jordan Justen]

Control: owner -1 Jordan Justen 
Control: retitle -1 ITA: nix -- Purely functional package manager (binaries)


signature.asc
Description: signature

Bug#1041643: ITP: ktls-utils -- TLS handshake utilities for in-kernel TLS consumers

[Ben Hutchings]

I've prepared a package in the Git repository
.

As of Linux 6.4, the only in-kernel user of TLS is the NFS server. 
Linux 6.5 adds support in the NFS client.  With just the NFS server
supporting TLS, I can't do an end-to-end test.

Once we have Linux 6.5 packaged, I can test and hopefully upload this
package.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.



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

Bug#1041503: (no subject)

[Al Ma]

found 1041503 linux-image-6.1.0-10-amd64/6.1.38-1
thanks
Same warning after kernel upgrade on a different machine (motherboard ASUS WS 
C422 PRO/SE):
Jul 22 22:35:22 AnonymizedMachineName kernel: hub 1-0:1.0: USB hub found
Jul 22 22:35:22 AnonymizedMachineName kernel: hub 1-0:1.0: 16 ports detected
Jul 22 22:35:22 AnonymizedMachineName kernel: usb usb2: New USB device found, 
idVendor=1d6b, idProduct=0003, bcdDevice= 6.01
Jul 22 22:35:22 AnonymizedMachineName kernel: usb usb2: New USB device strings: 
Mfr=3, Product=2, SerialNumber=1
Jul 22 22:35:22 AnonymizedMachineName kernel: usb usb2: Product: xHCI Host 
Controller
Jul 22 22:35:22 AnonymizedMachineName kernel: usb usb2: Manufacturer: Linux 
6.1.0-10-amd64 xhci-hcd
Jul 22 22:35:22 AnonymizedMachineName kernel: usb usb2: SerialNumber: 
:00:14.0
Jul 22 22:35:22 AnonymizedMachineName kernel: hub 2-0:1.0: USB hub found
Jul 22 22:35:22 AnonymizedMachineName kernel: hub 2-0:1.0: 10 ports detected
Jul 22 22:35:22 AnonymizedMachineName kernel: usb: port power management may be 
unreliable
To debug this further, I could try to plug in a USB-A mouse and USB-C charging 
cable into various ports and observe the journal, but I'd like to know, while 
doing so, what I should watch for, i.e., what I should and shouldn't see.
Gratefully,
AlMa

Bug#1001286: kernel: i2c i2c-0: Systems with more than 4 memory slots not supported yet, not instantiating SPD

[Al Ma]

severity 1001286 important
found 1001286 linux/6.1.0-10
found 1001286 linux-image-6.1.0-10-amd64/6.1.38-1
thanks
Same restriction here, namely for two stationary computers with Asus WS C422 
PRO/SE with Intel® Xeon® W-2235 CPU @ 3.80GHz (motherboard specification: 
https://www.asus.com/de/motherboards-components/motherboards/workstation/ws-c422-pro-se/techspec
 
https://www.asus.com/de/motherboards-components/motherboards/workstation/ws-c422-pro-se/techspec
 ).
Journal messages:
Jul 22 22:35:22 AnonymizedMachineName kernel: i801_smbus :00:1f.4: SPD 
Write Disable is set
Jul 22 22:35:22 AnonymizedMachineName kernel: i801_smbus :00:1f.4: SMBus 
using PCI interrupt
Jul 22 22:35:22 AnonymizedMachineName kernel: pci :00:1f.1: [8086:a2a0] 
type 00 class 0x058000
Jul 22 22:35:22 AnonymizedMachineName kernel: pci :00:1f.1: reg 0x10: [mem 
0xfd00-0xfdff 64bit]
Jul 22 22:35:22 AnonymizedMachineName kernel: pci :00:1f.1: Adding to iommu 
group 86
Jul 22 22:35:22 AnonymizedMachineName kernel: dca service started, version 
1.12.1
Jul 22 22:35:22 AnonymizedMachineName kernel: pci :00:1f.1: Removing from 
iommu group 86
Jul 22 22:35:22 AnonymizedMachineName kernel: i2c i2c-0: 2/8 memory slots 
populated (from DMI)
Jul 22 22:35:22 AnonymizedMachineName kernel: i2c i2c-0: Systems with more than 
4 memory slots not supported yet, not instantiating SPD
Raising severity because more than two machines are concerned. Though it's not 
urgent (or at least not urgent for me in any sense of the word) because 
currently I don't have that much RAM to populate all the slots, it's important 
to eventually remove the restriction because I'm quite sure that I am going to 
add RAM in the future. All my computers so far ended their lives with the 
maximal amount of RAM.
Gratefully,
AlMa

Bug#1001286: kernel: i2c i2c-0: Systems with more than 4 memory slots not supported yet, not instantiating SPD

[Al Ma]

severity 1001286 important
thanks
Same restriction here, namely for two stationary computers with Asus WS C422 
PRO/SE with Intel® Xeon® W-2235 CPU @ 3.80GHz (motherboard specification: 
https://www.asus.com/de/motherboards-components/motherboards/workstation/ws-c422-pro-se/techspec
 
https://www.asus.com/de/motherboards-components/motherboards/workstation/ws-c422-pro-se/techspec
 ).
Journal messages:
Jul 22 22:35:22 AnonymizedMachineName kernel: i801_smbus :00:1f.4: SPD 
Write Disable is set
Jul 22 22:35:22 AnonymizedMachineName kernel: i801_smbus :00:1f.4: SMBus 
using PCI interrupt
Jul 22 22:35:22 AnonymizedMachineName kernel: pci :00:1f.1: [8086:a2a0] 
type 00 class 0x058000
Jul 22 22:35:22 AnonymizedMachineName kernel: pci :00:1f.1: reg 0x10: [mem 
0xfd00-0xfdff 64bit]
Jul 22 22:35:22 AnonymizedMachineName kernel: pci :00:1f.1: Adding to iommu 
group 86
Jul 22 22:35:22 AnonymizedMachineName kernel: dca service started, version 
1.12.1
Jul 22 22:35:22 AnonymizedMachineName kernel: pci :00:1f.1: Removing from 
iommu group 86
Jul 22 22:35:22 AnonymizedMachineName kernel: i2c i2c-0: 2/8 memory slots 
populated (from DMI)
Jul 22 22:35:22 AnonymizedMachineName kernel: i2c i2c-0: Systems with more than 
4 memory slots not supported yet, not instantiating SPD
Raising severity because more than two machines are concerned. Though it's not 
urgent (or at least not urgent for me in any sense of the word) because 
currently I don't have that much RAM to populate all the slots, it's important 
to eventually remove the restriction because I'm quite sure that I am going to 
add RAM in the future. All my computers so far ended their lives with the 
maximal amount of RAM.
Gratefully,
AlMa

Bug#1041141: kernel: pmd_set_huge: Cannot satisfy [mem 0x…-0x…] with a huge-page mapping due to MTRR override.

[Al Ma]

I stand corrected – the very last message as of a few minutes ago concerned a 
different machine: WS C422 PRO/SE with Intel® Xeon® W-2235 CPU @ 3.80GHz, 32 GB 
RAM, ASPEED AST2500 64MB built-in graphics chip, and NVIDIA GeForce GTX 1660 Ti 
PCIe graphics card.

Bug#1033658: ftp.debian.org: Please add "riscv64" to the archive

[Mark Hymers]

On Wed, 05, Jul, 2023 at 11:19:48PM +0200, Manuel A. Fernandez Montecelo spoke 
thus..

> Gentle ping?
> 
> We'd like to start with this when possible, the rebuilding of the
> whole archive will take a while and this is a good moment for us.
> 
> If there's any blocker, please let us know.

Hi Manuel,

Sorry for the delay - life is rather busy.

I'm going to take the lead for the ftp-team on importing riscv64 to the
archive.

The key points are:

 1. We need to import enough packages from the unofficial port to
 bootstrap a build chroot.
 2. These packages need to be at the current unstable versions.
 3. These packages need to be signed with a special gpg upload key so
 that we can track them and ensure they have been rebuilt before
 release.

If we can have a discussion on #debian-riscv to identify who will be
responsible for which parts of this and who from DSA / buildd etc will
ensure that their sides are done (where needed), that would be helpful.
Once we've had that discussion, I'll add the architecture to the
relevant suites, import the GPG key as a restricted upload key and we
should be good to get started.

Thanks,

Mark



-- 
Mark Hymers 


signature.asc
Description: PGP signature

Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386

[Dirk Eddelbuettel]

On 22 July 2023 at 21:45, Paul Gevers wrote:
| Source: lme4
| Version: 1.1-31-1
| Severity: serious
| Control: close -1 1.1-34-1
| X-Debbugs-CC: debia...@lists.debian.org
| Tags: sid trixie
| User: release.debian@packages.debian.org
| Usertags: out-of-sync
| 
| Dear maintainer(s),
| 
| The Release Team considers packages that are out-of-sync between testing 
| and unstable for more than 30 days as having a Release Critical bug in 
| testing [1]. Your package src:lme4 has been trying to migrate for 32 
| days [2]. Hence, I am filing this bug.
| 
| The version in unstable causes 3 autopkgtest failures when tested in 
| testing, all on i386. The failures are due to autopkgtest timeout after 
| 2:47 h, while normally these tests run in minutes, so this suggests the 
| tests hang. In unstable, r-cran-afex and r-cran-mertools pass (so this 
| is probably a (set of) package(s) in unstable that also needs to migrate 
| together with lme4), but r-cran-mlmrev also times out in unstable.
| 
| If a package is out of sync between unstable and testing for a longer 
| period, this usually means that bugs in the package in testing cannot be 
| fixed via unstable. Additionally, blocked packages can have impact on 
| other packages, which makes preparing for the release more difficult. 
| Finally, it often exposes issues with the package and/or
| its (reverse-)dependencies. We expect maintainers to fix issues that 
| hamper the migration of their package in a timely manner.
| 
| This bug will trigger auto-removal when appropriate. As with all new 
| bugs, there will be at least 30 days before the package is auto-removed.
| 
| I have immediately closed this bug with the version in unstable, so if 
| that version or a later version migrates, this bug will no longer affect 
| testing. I have also tagged this bug to only affect sid and trixie, so 
| it doesn't affect (old-)stable.
| 
| If you believe your package is unable to migrate to testing due to 
| issues beyond your control, don't hesitate to contact the Release Team.

The lme4 package is in fine standing at CRAN
  https://cloud.r-project.org/web/checks/check_results_lme4.html
and build everywhere on Debian (see this and other links)
  https://cloud.r-project.org/web/checks/check_results_lme4.html

If three other packages (that I have nothing to do with) fail in _their
autopkgtests_ may I suggest you talk to the maintainers of _those packages_?

lme4 is _core_ package, written and maintained by current and former R Core
members. It is one of the most widely used and watched packages around.

This is most likely an issue of shooting the messenger as the root cause with
be with those other packages.  It could be an issue as simple as CRAN (and
upstream) no longer checking on i386 though it usually does not fail there.

Dirk


| Paul
| 
| [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
| [2] https://qa.debian.org/excuses.php?package=lme4
| x[DELETED ATTACHMENT OpenPGP_signature, application/pgp-signature]

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

Bug#1041363: nft BUG: kernel NULL pointer dereference, address: 0000000000000038

[Daniel Gröber]

Hi Salvatore,

On Sat, Jul 22, 2023 at 10:07:39PM +0200, Salvatore Bonaccorso wrote:
> On Tue, Jul 18, 2023 at 02:35:25AM +0200, Daniel Gröber wrote:
> > I got the following BUG on my router while working on my nftables
> > ruleset. After this happened network connectivity was broken quite severely
> > so some internal state might have gotten messed up too. An attempted reboot
> > never completed and a hard power cut was necessary.
>
> As this is not the newest kernel in bookworm, please test with
> 6.1.38-1. 
> 
> Are you able to reliably reproduce the issue and can share the poc?

Unfortunately this bug only reared it's ugly head once so far. I upgraded
to 6.1-38-1 just after sending this report.

Since that upgrade I have

[   27.057795] WARNING: CPU: 0 PID: 1180 at net/core/flow_dissector.c:1016 
__skb_flow_dissect+0xa91/0x1cd0

on every boot on the two of my routers. Is that a known issue? I can't seem
to find any reports but this also happens on my workstation. Let me know if
I should open another bug for that.

The original bug is likely very hard to trigger if it still exists. It's
hard to reconstruct the various changes I was making while testing my
ruleset :/

I'd be happy to have a quick look at the code to see if I can deduce what
triggered it, but I'm not familliar with how to parse these kernel BUG
traces. Could you point me to any docs on how to get some line numbers for
that backtrace?

Thanks,
--Daniel

Bug#1041141: kernel: pmd_set_huge: Cannot satisfy [mem 0x…-0x…] with a huge-page mapping due to MTRR override.

[Al Ma]

found 1041141 6.1.38-1
thanks
After the kernel upgrade, I got a slightly different message in the same vein:
Jul 22 22:35:22 AnonymizedMachineName kernel: Registering PCC driver as Mailbox 
controller
Jul 22 22:35:22 AnonymizedMachineName kernel: acpiphp: ACPI Hot Plug PCI 
Controller Driver version: 0.5
Jul 22 22:35:22 AnonymizedMachineName kernel: PCI: MMCONFIG for domain  
[bus 00-ff] at [mem 0x6000-0x6fff] (base 0x6000)
Jul 22 22:35:22 AnonymizedMachineName kernel: PCI: MMCONFIG at [mem 
0x6000-0x6fff] reserved in E820
Jul 22 22:35:22 AnonymizedMachineName kernel: pmd_set_huge: Cannot satisfy [mem 
0x6000-0x6020] with a huge-page mapping due to MTRR override.
Gratefully,
AlMa

Bug#1041014: systemd-timesyncd: data collected by reportbug, new journal

[Al Ma]

Michael, thanks for taking a look. Last time I started 
/lib/systemd/systemd-timesyncd directly as root from the command line was 
several days ago, way before the today upload of the new versions of systemd 
and systemd-timesyncd to stable. Back then, /lib/systemd/systemd-timesyncd did 
start, did not print anything and also did not terminate by itself. Hitting 
Ctrl+C killed/terminated it, leading me back to the usual bash prompt. Is this 
the expected behavior? If this behavior is still the same after the today 
upgrade, should I still run strace on the process and post the logs or do 
something else? (I'm going to check in a few days because I don't always have 
the laptop on which the bug occurs at my disposal.)
(Wild guess: Presumably, during the upgrade from Debian 11 to Debian 12 some 
important packages that should be installed in their amd64 versions could have 
hypothetically been installed, for whatever reason, in i386. This is something 
I observed today on a different machine during an otherwise uneventful, routine 
upgrade of dbus. I can try to check via `sudo dpkg -l | awk '/^ii/ && $4 == 
"i386" { print }'`.)
Gratefully,
AlMa

Bug#1041689: [Pkg-utopia-maintainers] Bug#1041689: udisks2: After upgrading to 2.10.0-3 on trixie, the service udisks2 does not start.

[Marc Bres Gil]

Hello,

thanks for your quick answer. Here are the logs you asked.

Systemctl:

× udisks2.service - Disk Manager
 Loaded: loaded (/lib/systemd/system/udisks2.service; enabled; preset:
enabled)
 Active: failed (Result: signal) since Sat 2023-07-22 22:53:20 CEST;
1min 10s ago
   Docs: man:udisks(8)
Process: 1286 ExecStart=/usr/libexec/udisks2/udisksd (code=killed,
signal=ABRT)
   Main PID: 1286 (code=killed, signal=ABRT)
CPU: 28ms

de jul. 22 22:53:20 helm systemd[1]: Starting udisks2.service - Disk
Manager...
de jul. 22 22:53:20 helm udisksd[1286]: udisks daemon version 2.10.0
starting
de jul. 22 22:53:20 helm udisksd[1286]: Error getting 'loop6' information:
Failed to get status of the device loop6: No such device or address
(g-bd-loop-error-quark, 1)
de jul. 22 22:53:20 helm udisksd[1286]: Error getting 'loop7' information:
Failed to get status of the device loop7: No such device or address
(g-bd-loop-error-quark, 1)
de jul. 22 22:53:20 helm udisksd[1286]: Error getting 'loop6' information:
Failed to get status of the device loop6: No such device or address
(g-bd-loop-error-quark, 1)
de jul. 22 22:53:20 helm udisksd[1286]: Error getting 'loop7' information:
Failed to get status of the device loop7: No such device or address
(g-bd-loop-error-quark, 1)
de jul. 22 22:53:20 helm udisksd[1286]: *** stack smashing detected ***:
terminated
de jul. 22 22:53:20 helm systemd[1]: udisks2.service: Main process exited,
code=killed, status=6/ABRT
de jul. 22 22:53:20 helm systemd[1]: udisks2.service: Failed with result
'signal'.
de jul. 22 22:53:20 helm systemd[1]: Failed to start udisks2.service - Disk
Manager.

-
Journalctl, before upgrading on udisks 2.9.4 starts ok, and after upgrading
on 2.10.0 fails:

-- Boot 567f68c732264f54917bdb7a37b26720 --
de jul. 22 22:49:27 helm systemd[1]: Starting udisks2.service - Disk
Manager...
de jul. 22 22:49:27 helm udisksd[945]: udisks daemon version 2.9.4 starting
de jul. 22 22:49:27 helm udisksd[945]: failed to load module crypto:
libbd_crypto.so.2: cannot open shared object file: No such file or
directory
de jul. 22 22:49:27 helm udisksd[945]: failed to load module mdraid:
libbd_mdraid.so.2: cannot open shared object file: No such file or
directory
de jul. 22 22:49:27 helm udisksd[945]: Failed to load the 'mdraid'
libblockdev plugin
de jul. 22 22:49:27 helm udisksd[945]: Failed to load the 'crypto'
libblockdev plugin
de jul. 22 22:49:27 helm systemd[1]: Started udisks2.service - Disk
Manager.
de jul. 22 22:49:27 helm udisksd[945]: Acquired the name
org.freedesktop.UDisks2 on the system message bus
de jul. 22 22:52:46 helm systemd[1]: Stopping udisks2.service - Disk
Manager...
de jul. 22 22:52:46 helm udisksd[945]: udisks daemon version 2.9.4 exiting
de jul. 22 22:52:46 helm systemd[1]: udisks2.service: Deactivated
successfully.
de jul. 22 22:52:46 helm systemd[1]: Stopped udisks2.service - Disk
Manager.
de jul. 22 22:52:46 helm systemd[1]: Starting udisks2.service - Disk
Manager...
de jul. 22 22:52:46 helm udisksd[4414]: udisks daemon version 2.10.0
starting
de jul. 22 22:52:46 helm udisksd[4414]: Error getting 'loop6' information:
Failed to get status of the device loop6: No such device or address
(g-bd-loop-error-quark, 1)
de jul. 22 22:52:46 helm udisksd[4414]: Error getting 'loop7' information:
Failed to get status of the device loop7: No such device or address
(g-bd-loop-error-quark, 1)
de jul. 22 22:52:46 helm udisksd[4414]: Error getting 'loop6' information:
Failed to get status of the device loop6: No such device or address
(g-bd-loop-error-quark, 1)
de jul. 22 22:52:46 helm udisksd[4414]: Error getting 'loop7' information:
Failed to get status of the device loop7: No such device or address
(g-bd-loop-error-quark, 1)
de jul. 22 22:52:46 helm udisksd[4414]: *** stack smashing detected ***:
terminated
de jul. 22 22:52:46 helm systemd[1]: udisks2.service: Main process exited,
code=killed, status=6/ABRT
de jul. 22 22:52:46 helm systemd[1]: udisks2.service: Failed with result
'signal'.
de jul. 22 22:52:46 helm systemd[1]: Failed to start udisks2.service - Disk
Manager.
-- Boot d1305a6d74754540b463848b4b0e353c --
de jul. 22 22:53:18 helm systemd[1]: Starting udisks2.service - Disk
Manager...
de jul. 22 22:53:18 helm udisksd[940]: udisks daemon version 2.10.0
starting
de jul. 22 22:53:18 helm udisksd[940]: Error getting 'loop6' information:
Failed to get status of the device loop6: No such device or address
(g-bd-loop-error-quark, 1)
de jul. 22 22:53:18 helm udisksd[940]: Error getting 'loop7' information:
Failed to get status of the device loop7: No such device or address
(g-bd-loop-error-quark, 1)
de jul. 22 22:53:18 helm udisksd[940]: Error getting 'loop6' information:
Failed to get status of the device loop6: No such device or address
(g-bd-loop-error-quark, 1)
de jul. 22 22:53:18 helm udisksd[940]: Error getting 'loop7' information:
Failed to get status of the device loop7: No such device or address

Bug#1041695: chromium: Crash when starting with --incognito option

[maxim . 7xiw8]

I am running Chromium in a Plasma (X11) environment.

Version===
KWin version: 5.27.5
Qt Version: 5.15.8
Qt compile version: 5.15.8
XCB compile version: 1.15

Operation Mode: X11 only

Bug#1041363: nft BUG: kernel NULL pointer dereference, address: 0000000000000038

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Daniel,

On Tue, Jul 18, 2023 at 02:35:25AM +0200, Daniel Gröber wrote:
> Package: src:linux
> Version: 6.1.27-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I got the following BUG on my router while working on my nftables
> ruleset. After this happened network connectivity was broken quite severely
> so some internal state might have gotten messed up too. An attempted reboot
> never completed and a hard power cut was necessary.
> 
> kernel: BUG: kernel NULL pointer dereference, address: 0038
> kernel: #PF: supervisor read access in kernel mode
> kernel: #PF: error_code(0x) - not-present page
> kernel: PGD 0 P4D 0 
> kernel: Oops:  [#1] PREEMPT SMP NOPTI
> kernel: CPU: 2 PID: 902522 Comm: kworker/2:3 Tainted: GW  
> 6.1.0-9-amd64 #1  Debian 6.1.27-1
> kernel: Hardware name: PC Engines apu3/apu3, BIOS v4.11.0.3 01/29/2020
> kernel: Workqueue: events nf_tables_trans_destroy_work [nf_tables]
> kernel: RIP: 0010:nft_set_elem_expr_destroy+0x56/0xa0 [nf_tables]
> kernel: Code: 6b 20 d9 48 8b 03 48 8b 40 78 48 8b 78 30 e8 f1 6e 54 d8 48 
> 8b 03 8b 40 10 01 c5 48 01 c3 41 0f b6 04 24 39 c5 73 2f 48 8b 13 <48> 8b 42 
> 38 48 85 c0 75 c5>
> kernel: RSP: 0018:b4e1484cfd28 EFLAGS: 00010246
> kernel: RAX:  RBX: 940746193d08 RCX: 940764e89200
> kernel: RDX:  RSI: 940746193d00 RDI: b4e1484cfd58
> kernel: RBP:  R08: 0003 R09: 8020001d
> kernel: R10:  R11:  R12: 940746193d00
> kernel: R13: b4e1484cfd58 R14: dead0122 R15: 940746c23e80
> kernel: FS:  () GS:9407b5f0() 
> knlGS:
> kernel: CS:  0010 DS:  ES:  CR0: 80050033
> kernel: CR2: 0038 CR3: 6eac2000 CR4: 000406e0
> kernel: Call Trace:
> kernel:  
> kernel:  nft_set_elem_destroy+0xe5/0x100 [nf_tables]
> kernel:  nft_set_pipapo_match_destroy+0x65/0x80 [nf_tables]
> kernel:  nft_pipapo_destroy+0x2e/0x1b0 [nf_tables]
> kernel:  nft_set_destroy+0x95/0x120 [nf_tables]
> kernel:  nf_tables_trans_destroy_work+0x303/0x330 [nf_tables]
> kernel:  process_one_work+0x1c7/0x380
> kernel:  worker_thread+0x4d/0x380
> kernel:  ? _raw_spin_lock_irqsave+0x23/0x50
> kernel:  ? rescuer_thread+0x3a0/0x3a0
> kernel:  kthread+0xe9/0x110
> kernel:  ? kthread_complete_and_exit+0x20/0x20
> kernel:  ret_from_fork+0x22/0x30
> kernel:  
> kernel: Modules linked in: mptcp_diag sctp_diag raw_diag unix_diag 
> af_packet_diag netlink_diag nf_conntrack_netlink sctp udp_diag tcp_diag 
> inet_diag ip_set_hash_ip ip_s>
> kernel:  zstd_compress raid10 raid456 async_raid6_recov async_memcpy 
> async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 
> multipath cdc_ether l>
> kernel: CR2: 0038
> kernel: ---[ end trace  ]---
> kernel: RIP: 0010:nft_set_elem_expr_destroy+0x56/0xa0 [nf_tables]
> kernel: Code: 6b 20 d9 48 8b 03 48 8b 40 78 48 8b 78 30 e8 f1 6e 54 d8 48 
> 8b 03 8b 40 10 01 c5 48 01 c3 41 0f b6 04 24 39 c5 73 2f 48 8b 13 <48> 8b 42 
> 38 48 85 c0 75 c5>
> kernel: RSP: 0018:b4e1484cfd28 EFLAGS: 00010246
> kernel: RAX:  RBX: 940746193d08 RCX: 940764e89200
> kernel: RDX:  RSI: 940746193d00 RDI: b4e1484cfd58
> kernel: RBP:  R08: 0003 R09: 8020001d
> kernel: R10:  R11:  R12: 940746193d00
> kernel: R13: b4e1484cfd58 R14: dead0122 R15: 940746c23e80
> kernel: FS:  () GS:9407b5f0() 
> knlGS:
> kernel: CS:  0010 DS:  ES:  CR0: 80050033
> kernel: CR2: 0038 CR3: 6eac2000 CR4: 000406e0
> kernel: note: kworker/2:3[902522] exited with irqs disabled

As this is not the newest kernel in bookworm, please test with
6.1.38-1. 

Are you able to reliably reproduce the issue and can share the poc?

Regards,
Salvatore

Bug#1041740: Error: Regex version mismatch, expected: 10.42 2022-12-11 actual: 10.36 2020-12-04

[Frank lin Piat]

Package: selinux-policy-default
Version: 2:2.20210203-7
Severity: minor

After upgading from bullseye to bookworm...
I had the following error many time (tens or hundreds times) when I use 
apt/dpkg programs:

> dpkg: warning: selinux: Regex version mismatch, expected: 10.42 2022-12-11 
> actual: 10.36 2020-12-04

I installed SELinux at some point on my system and partially removed it.
Some packages were in configured (uninstalled) state.

After purging those packages configuraiton, the error don't occur anymore :

Purging configuration files for selinux-basics (0.5.8) ...
Purging configuration files for selinux-policy-dev (2:2.20210203-7) ...
Purging configuration files for at (3.1.23-1) ...
Purging configuration files for selinux-policy-default (2:2.20210203-7) ...
Purging configuration files for setools-gui (4.3.0-2) ...
Purging configuration files for discover (2.1.2-8) ...


My assumption is that this error wouldn't occur anymore if the packages were
installed state during the upgrade.

Thanks

Franklin Piat

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

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

Versions of packages selinux-policy-default depends on:
ii  libselinux1  3.4-1+b6
ii  libsemanage2 3.4-1+b5
ii  libsepol23.4-2.1
pn  policycoreutils  
pn  selinux-utils

Versions of packages selinux-policy-default recommends:
pn  checkpolicy  
pn  setools  

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

Bug#1041014: systemd-timesyncd: data collected by reportbug, new journal

[Michael Biebl]

The logs so far do not reveal anything out of the ordinary.

Please start /lib/systemd/systemd-timesyncd directly (as root, from the 
command line).

If that fails as well, please run strace on the process and post the logs.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041689: [Pkg-utopia-maintainers] Bug#1041689: udisks2: After upgrading to 2.10.0-3 on trixie, the service udisks2 does not start.

[Michael Biebl]

Control: tags -1  + moreinfo unreproducible

Am 22.07.23 um 09:43 schrieb Marc Bres Gil:

Package: udisks2
Version: 2.10.0-3
Severity: important
X-Debbugs-Cc: marc.b...@gmail.com

Dear Maintainer,

* What led up to the situation?
 Upgrade udisks2 to 2.10.0-3

* What exactly did you do (or not do) that was effective (or
  ineffective)?
Upgrade with apt-update and apt-upgradem.

* What was the outcome of this action?
 It broke my desktop system: As plasma-desktop seems to depend on 
udisks2 for some functions, it let me out of my desktop. Luckily I've been able 
to still access with cinnamon desktop to check and fill the bug report. If I 
download the udisks2 from stable and its dependencies, and then install it 
manually, udisks2 starts but it is not a real solution

* What outcome did you expect instead?
udisks2 continue working as usual before the upgrade


I can't reproduce the problem.

Can you please send me the output of
systemctl status udisks2.service
and
journalctl -u udisks2.service



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041739: Error: Regex version mismatch, expected: 10.42 2022-12-11 actual: 10.36 2020-12-04

[Frank Lin PIAT]

Package: selinux-policy-default
Version: 2:2.20210203-7
Severity: minor

After upgading from bullseye to bookworm...
I had the following error many time (tens or hundreds times) when I use 
apt/dpkg programs:

> dpkg: warning: selinux: Regex version mismatch, expected: 10.42 2022-12-11 
> actual: 10.36 2020-12-04

I installed SELinux at some point on my system and partially removed it.
Some packages were in configured (uninstalled) state.

After purging those packages configuraiton, the error don't occur
anymore :

Purging configuration files for selinux-basics (0.5.8) ...
Purging configuration files for selinux-policy-dev (2:2.20210203-7) ...
Purging configuration files for at (3.1.23-1) ...
Purging configuration files for selinux-policy-default (2:2.20210203-7) ...
Purging configuration files for setools-gui (4.3.0-2) ...
Purging configuration files for discover (2.1.2-8) ...


My assumption is that this error wouldn't occur anymore if the packages were
installed state during the upgrade.

Thanks

Franklin Piat

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

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

Versions of packages selinux-policy-default depends on:
ii  libselinux1  3.4-1+b6
ii  libsemanage2 3.4-1+b5
ii  libsepol23.4-2.1
pn  policycoreutils  
pn  selinux-utils

Versions of packages selinux-policy-default recommends:
pn  checkpolicy  
pn  setools  

Versions of packages selinux-policy-default suggests:
pn  logcheck
pn  syslog-summary  

Bug#1041738: src:lme4: fails to migrate to testing for too long: causes timeout in autopkgtests on i386

[Paul Gevers]

Source: lme4
Version: 1.1-31-1
Severity: serious
Control: close -1 1.1-34-1
X-Debbugs-CC: debia...@lists.debian.org
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:lme4 has been trying to migrate for 32 
days [2]. Hence, I am filing this bug.


The version in unstable causes 3 autopkgtest failures when tested in 
testing, all on i386. The failures are due to autopkgtest timeout after 
2:47 h, while normally these tests run in minutes, so this suggests the 
tests hang. In unstable, r-cran-afex and r-cran-mertools pass (so this 
is probably a (set of) package(s) in unstable that also needs to migrate 
together with lme4), but r-cran-mlmrev also times out in unstable.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=lme4


OpenPGP_signature
Description: OpenPGP digital signature

Bug#932501: [pkg-apparmor] BTS housekeeping and severity adjustments

[Christian Boltz]

Hello,

Am Freitag, 21. Juli 2023, 15:05:52 CEST schrieb Stefano Rivera:
> > severity 932501 serious
> 
> I'm wondering if this bug should really be serious. Squid's apparmor
> config is shipped disabled, so one has to manually enable it to
> trigger this bug.
> 
> I would have gone for normal/important.
> 
> I don't know what the correct solution to this bug is. Presumably one
> has to get the squid profile to include the abstraction that
> squid-deb-proxy provides. I don't know how this is usually done in a
> Debian package. Maybe one of the apparmor team can comment.

The interesting part is that the abstraction is shipped in squid-deb-
proxy, while the squid profile comes from another package (I didn't check 
which one).

I guess the best you can have is to add
include if exists 
in the squid profile so that it will include the abstraction if it 
exists, and doesn't complain if it doesn't.

Note that the AppArmor profile cache is only timestamp-based [1], so if 
you install squid-deb-proxy (and had the squid AppArmor profile loaded 
before), it might happen that the cache file is never than the squid-deb-
proxy abstraction, with the result that the cache doesn't get updated.
(Workaround: delete the cache file, then reload the profile.)


The alternative is to add the rules needed for squid-deb-proxy directly 
to the squid profile. This adds some "superfluous" rules for people who 
don't use squid-deb-proxy, but on the positive side it avoids the cache 
issue.


BTW: https://packages.debian.org/sid/all/squid-deb-proxy/filelist says 
the abstraction is packaged as
/etc/apparmor.d/abstractions/squid-deb-proxy/squid-deb-proxy
which looks slightly wrong ;-)  It should just be
/etc/apparmor.d/abstractions/squid-deb-proxy
(assuming no other files get deployed to
/etc/apparmor.d/abstractions/squid-deb-proxy/ )

Bonus points if you add
include if exists 
to the abstraction ;-)


For the records:   include if exists   needs AppArmor >= 3.0 userspace.


Regards,

Christian Boltz

[1] Using a better cache validation method like checking the checksum of 
the text profile is on the TODO list upstream, but not implemented 
yet.
-- 
[SuSE vs. SUSE] As a friend of mine elsewhere remarked, the picky
spelling capitalization scheme reinforces the idea that Linux is
case-sensitive, so these are "sensitive" issues and certainly worth
discussing (for us, at least)! :)   [Shriramana Sharma in opensuse]


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

Bug#1041737: sensible-terminal.1: some remarks and editorial fixes for the manual

[Bjarni Ingi Gislason]

Package: sensible-utils
Version: 0.0.20
Severity: minor
Tags: patch

Dear Maintainer,

here are some notes and editorial fixes for the man page.

The patch is in the attachment.

-.-.

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"echo .kern 0 | groff -man -Z - " instead of "nroff -man"

  Add the option "-t", if the file contains a table.

  Read the output of "diff -u" with "less -R" or similar.

-.-.

  If "man" (man-db) is used to check the manual, the following
must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-.

Output from "mandoc -T lint sensible-terminal.1":

mandoc: sensible-terminal.1:6:32: STYLE: unterminated quoted argument
mandoc: sensible-terminal.1:7:2: WARNING: skipping paragraph macro: br at the 
end of SH
mandoc: sensible-terminal.1:19:84: STYLE: input text line longer than 80 bytes: 
Documentation of beh...

-.-.

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

9:.BR sensible-terminal-emulator

-.-.

"[" and "]", showing optional arguments to options, should be typeset in roman.

6:.BR sensible-terminal-emulator " [-T title] [--wait] [-e cmd...]

-.-.

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

6:.BR sensible-terminal-emulator " [-T title] [--wait] [-e cmd...]

-.-.

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

6:.BR sensible-terminal-emulator " [-T title] [--wait] [-e cmd...]
16:.B sh -c

-.-.



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

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

-- no debconf information
--- sensible-terminal.1 2023-07-21 20:53:04.0 +
+++ sensible-terminal.1.new 2023-07-21 21:24:24.0 +
@@ -3,19 +3,20 @@
 .SH NAME
 sensible-terminal-emulator \- sensible terminal emulator
 .SH SYNOPSIS
-.BR sensible-terminal-emulator " [-T title] [--wait] [-e cmd...]
-.br
+.B sensible-terminal-emulator
+.RB [ "\-T \fItitle\fP" "] [" \-\-wait "] [" "\-e \fIcmd...\fP" ]
 .SH DESCRIPTION
-.BR sensible-terminal-emulator
+.B sensible-terminal-emulator
 makes sensible decisions on which terminal emulator to call.
 Programs in Debian can use this script
 as their default terminal emulator or emulate their behavior.
 .br
 TERMINAL_EMULATOR environment variable could be set, and will be used if set.
 Any string acceptable as a command_string operand to the
-.B sh -c
+.B sh \-c
 command shall be valid.
 .SH "STANDARD"
-Documentation of behavior of sensible-utils under a debian system is available 
under
+Documentation of behavior of sensible-utils under a debian system is
+available under
 sections 11.4-11.8 of debian-policy usually installed under
 /usr/share/doc/debian-policy (you might need to install debian-policy)

Bug#1041695: chromium: Crash when starting with --incognito option

[Andres Salomon]

Are you running this in an X11 or Wayland session, and with which 
window manager or desktop environment? Do you have chromium configured 
to use X11 or Wayland?



On Sat, Jul 22 2023 at 12:13:57 PM +02:00:00, Maxime Silvier 
 wrote:

Package: chromium
Version: 115.0.5790.98-1~deb12u1
Severity: normal
X-Debbugs-Cc: maxim.7x...@simplelogin.fr 
, t...@security.debian.org 



Dear Maintainer,

Since last Bookworm stable update (deb12u1), Chromium crash after few 
seconds when starting with --incognito option (in order to navigate 
in private mode).
By comparrison, private mode still properly functions when using only 
the in-app option.


Previously, in version 113.0.5672.126-1, the option worked as 
intented: `chromium --incognito` command launches the program in 
private mode without any crash.


I tried to purge Chromium packages and user's config files, then 
reinstall, but it did not change anything to this issue. Same result 
when deactivating browser extensions (Ublock and Privacy Badger).


PS : Please forgive any spelling mistakes, as English is not my 
native language.


Best regards.


-- System Information:
Debian Release: 12.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), 
(500, 'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-10-amd64 (SMP w/6 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE not set

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

Versions of packages chromium depends on:
ii  chromium-common 
115.0.5790.98-1~deb12u1

ii  libasound2  1.2.8-1+b1
ii  libatk-bridge2.0-0  2.46.0-5
ii  libatk1.0-0 2.46.0-5
ii  libatomic1  12.2.0-14
ii  libatspi2.0-0   2.46.0-5
ii  libbrotli1  1.0.9-2+b6
ii  libc6   2.36-9
ii  libcairo2   1.16.0-7
ii  libcups22.4.2-3
ii  libdbus-1-3 1.14.6-1
ii  libdouble-conversion3   3.2.1-1
ii  libdrm2 2.4.114-1+b1
ii  libevent-2.1-7  
2.1.12-stable-8

ii  libexpat1   2.5.0-1
ii  libflac12   1.4.2+ds-2
ii  libfontconfig1  2.14.1-4
ii  libfreetype62.12.1+dfsg-5
ii  libgbm1 
22.3.6-1+deb12u1

ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libgtk-3-0  3.24.37-2
ii  libjpeg62-turbo 1:2.1.5-2
ii  libjsoncpp251.9.5-4
ii  liblcms2-2  2.14-2
ii  libminizip1 1.1-8+b1
ii  libnspr42:4.35-1
ii  libnss3 2:3.87.1-1
ii  libopenh264-7   2.3.1+dfsg-3
ii  libopenjp2-72.5.0-2
ii  libopus01.3.1-3
ii  libpango-1.0-0  1.50.12+ds-1
ii  libpng16-16 1.6.39-2
ii  libpulse0   
16.1+dfsg1-2+b1
ii  libre2-9
20220601+dfsg-1+b1

ii  libsnappy1v51.1.9-3
ii  libstdc++6  12.2.0-14
ii  libwebp71.2.4-0.2
ii  libwebpdemux2   1.2.4-0.2
ii  libwebpmux3 1.2.4-0.2
ii  libwoff11.0.2-2
ii  libx11-6
2:1.8.4-2+deb12u1

ii  libxcb1 1.15-1
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.6-1
ii  libxext62:1.3.4-1+b1
ii  libxfixes3  1:6.0.0-2
ii  libxkbcommon0   1.5.0-1
ii  libxml2 
2.9.14+dfsg-1.2

ii  libxnvctrl0

Bug#1030560: Ugly // in symlinks

[Sven Joachim]

On 2023-02-05 20:07 -0400, David Bremner wrote:

> Sven Joachim  writes:
>
>>
>> I have attached a patch which drops the extra second slash.
>>
>> Cheers,
>>Sven
>
> Thanks Sven, I'll most likely wait until after the freeze to apply that.

Just a reminder that the freeze is over and you can safely do that now.

Cheers,
   Sven

Bug#999977: qxw: depends on obsolete pcre3 library

[Stephen Kitt]

On Sat, 22 Jul 2023 16:14:06 +0200, Bastian Germann  wrote:
> I suggest to remove the package. I do not think upstream will deal with 
> this.

qxw’s usage of pcre seems simple enough, I’ll try to come up with a patch.

Regards,

Stephen


pgpj3AFhwSrrc.pgp
Description: OpenPGP digital signature

Bug#1041736: aptitude: if package to be upgraded is not found, please search for the correct package name approximately

[Al Ma]

Package: aptitude
Version: 0.8.13-5
Severity: wishlist
Today I wanted to upgrade the pacakge sudo but made a typo:
# aptitude upgrade suo
Couldn't find any package whose name is "suo", but there are 4 packages which 
contain "suo" in their name:
golang-github-bmatsuo-lmdb-go-dev festvox-suopuhe-lj festvox-suopuhe-mv 
festvox-suopuhe-common
Unable to apply some actions, aborting
Clearly, neither of the suggestions of aptitude is anywhere close to my 
intention.  I propose that aptitude searches approximately, akin to what 
tre-agrep does, and suggests first packages whose names deviate by 1 character 
from the asked one, then by two characters, then by three, …, and stops after 
it has listed all the packages with the current number of deviations (and 
increases the admissible number of deviations if less than 4 packages have been 
found so far) or until the list of the known packages is exhausted, whichever 
comes first.
Gratefully,
AlMa

Bug#1041735: freedombox: [INTL:sv] Swedish translation for freedombox debconf

[Peter Kvillegård]

Package: freedombox
Version: 23.13
Severity: wishlist
Tags: l10n patch
X-Debbugs-Cc: q...@sdfeu.org

Dear Maintainer,

Please copy the attachment into debian/po/sv.po
it's in utf-8 and has been tested with msgfmt.

Regards / Peter
# Translation of freedombox 23.13 debconf to Swedish.
# Copyright (C) 2011-2023 FreedomBox Authors
# This file is distributed under the same license as the freedombox package.
# Peter Kvillegård , 2023
#
msgid ""
msgstr ""
"Project-Id-Version: freedombox 23.13\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2023-07-21 16:31+\n"
"PO-Revision-Date: 2023-07-22 15:55+0200\n"
"Last-Translator: Peter Kvillegård \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: note
#. Description
#: ../freedombox.templates:1001
msgid "FreedomBox first wizard secret - ${secret}"
msgstr "Hemlighet för FreedomBox första guidade installerare - ${secret}"

#. Type: note
#. Description
#: ../freedombox.templates:1001
msgid ""
"Please note down the above secret. You will be asked to enter this in the "
"first screen after you launch the FreedomBox web interface. In case you lose "
"it, you can retrieve it by running the following command:"
msgstr ""
"Skriv ner ovanstående hemlighet. Du kommer att bli ombedd att ange den i "
"den första skärmen efter att du startat FreedomBox webbgränssnitt. Om du "
"tappar bort den kan den hämtas igen genom att köra följande kommando:"

Bug#1041722: steam is incompatible with libgudev 238-2

[Felix Zielcke]

forwarded -1 https://github.com/ValveSoftware/steam-for-linux/issues/9805
thanks

Am Samstag, dem 22.07.2023 um 18:46 +0100 schrieb Simon McVittie:
> On Sat, 22 Jul 2023 at 17:43:56 +0200, Felix Zielcke wrote:
> > Steam crashes on startup with libgudev 238-2 currently in unstable.
> 
> Debian has no control over what's in the proprietary Steam client, so
> please report this sort of thing to
> .
> 
> Thanks,
>     smcv

Hi,

this seems to have been already reported upstream 2 weeks ago.
I guess even if on Debian side, nothing can be changed, it's still
useful to have the problem at least known. Which was mainly my
motivation.
As soon as it enters testing more people are affected

Bug#1041511: ntfs-3g: Undocumented dependency on libbrotli-dev

[GCS]

Control: tags -1 +unreproducible +wontfix
Control: severity -1 normal

On Thu, Jul 20, 2023 at 3:57 AM Theodoric Stier  wrote:
> Source: ntfs-3g
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
[...]
> This package build fails during the configure step if libbrotli-dev is not 
> installed.
> It appears to be missing from BuildDep.
 It has nothing to do with ntfs-3g. I see three things:
1) You are changing the package to be non-official:
-- cut --
dpkg-buildpackage: info: source package ntfs-3g
dpkg-buildpackage: info: source version 1:2022.10.3-2
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Theodoric Stier 
-- cut --

2) The package does not need and doesn't check for brotli. Your build
log clearly show this:
-- cut --
configure:14736: checking for gnutls >= 1.4.
configure:14743: $PKG_CONFIG --exists --print-errors "gnutls >= 1.4.4"
Package libbrotlienc was not found in the pkg-config search path.
Perhaps you should add the directory containing `libbrotlienc.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libbrotlienc', required by 'gnutls', not found
Package 'libbrotlidec', required by 'gnutls', not found
Package 'libzstd', required by 'gnutls', not found
configure:14746: $? = 1
configure:14760: $PKG_CONFIG --exists --print-errors "gnutls >= 1.4.4"
Package libbrotlienc was not found in the pkg-config search path.
Perhaps you should add the directory containing `libbrotlienc.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libbrotlienc', required by 'gnutls', not found
Package 'libbrotlidec', required by 'gnutls', not found
-- cut --

It is gnutls which needs brotli, not ntfs-3g.

3) Official gnutls28 packages don't build with brotli so it seems you
have an unofficial one or you tampered with that as well.

Regards,
Laszlo/GCS

Bug#1040690: reassign bug to correct package

[Christoph Groth]

Nicholas D Steeves wrote:

> To all affected users: Do you remember if you ever manually installed
> an affected elpa-package from sid/unstable or from testing?  I'm
> curious if this might be part of the trigger condition.

Before the upgrade to bookworm I was running an almost pure bullseye.
The exception were a few elpa packages from bookworm (i.e. then
testing).  We can try to reconstruct the list of these package from the
output of the following command:

  zgrep -h ' elpa-' /var/log/dpkg.log* | grep ' upgrade '

2023-07-20 20:31:46 upgrade elpa-adaptive-wrap:all 0.8-1 0.8-3
2023-07-20 20:31:46 upgrade elpa-websocket:all 1.13-1 1.13-3
2023-07-20 20:31:47 upgrade elpa-atomic-chrome:all 2.0.0-2 2.0.0-4
2023-07-20 20:31:47 upgrade elpa-dash:all 2.19.1+dfsg-1 
2.19.1+git20220608.1.0ac1ecf+dfsg-1
2023-07-20 20:31:47 upgrade elpa-emacsql:all 3.0.0+ds-2 3.1.1+ds-1
2023-07-20 20:31:48 upgrade elpa-git-commit:all 3.3.0-1 3.3.0-2
2023-07-20 20:31:48 upgrade elpa-htmlize:all 1.55-1 1.56-1
2023-07-20 20:31:49 upgrade elpa-magit-section:all 3.3.0-1 3.3.0-2
2023-07-20 20:31:49 upgrade elpa-magit:all 3.3.0-1 3.3.0-2
2023-07-20 20:31:50 upgrade elpa-markdown-mode:all 2.4-1 2.5-1
2023-07-20 20:31:51 upgrade elpa-notmuch:all 0.31.4-2 0.37-1
2023-07-20 20:31:52 upgrade elpa-org:all 9.4.0+dfsg-1 9.5.2+dfsh-5
2023-07-20 20:31:52 upgrade elpa-transient:all 0.3.6-2 0.3.7-1
2023-07-20 20:31:53 upgrade elpa-yaml-mode:all 0.0.15-1 0.0.15-2
2023-07-20 21:19:26 upgrade elpa-emacsql-sqlite:amd64 3.0.0+ds-2 3.1.1+ds-1

(The main upgrade from bullseye to bookworm occurred around 20:30.)

Comparing the left versions in the log to the ones in bullseye one can
see that at least the following packages were from testing:

elpa-dash
elpa-git-commit
elpa-magit-section
elpa-magit
elpa-transient

To this list one should add elpa-org-roam which did not require an
upgrade during the bullseye -> bookworm transition and perhaps other
elpa packages that I lost track of.

> Likewise, do you remember if you installed dh-elpa from backports?
> While I think both of these cases are unlikely to have caused
> problems, one might as well be thorough!

I do not remember ever installing dh-elpa from any source, nor can
I find any trace of it in the logs.


signature.asc
Description: PGP signature

Bug#1028111: r-cran-clock: autopkgtest failure on 32bit

[Paul Gevers]

Control: severity -1 serious

Hi,

On Sun, 22 Jan 2023 17:15:54 +0100 Andreas Tille  wrote:

The two failing tests were excluded for the three affected architectures.
While the problem is not really fixed (and thus the bug remains open) the
severity is lowered to "important" to enable testing migration.


Apparently something regressed.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#967375: gcin: depends on deprecated GTK 2

[Shengjing Zhu]

Control: tags -1 + wontfix

On Sat, Jul 22, 2023 at 11:39 PM Bastian Germann  wrote:
>
> Please just drop gcin-gtk2-immodule.
>

All gtk2 input method modules are supposed to be the last ones to be
removed from Debian.
Please see smcv's last paragraph.

-- 
Shengjing Zhu

Bug#1041722: steam is incompatible with libgudev 238-2

[Simon McVittie]

On Sat, 22 Jul 2023 at 17:43:56 +0200, Felix Zielcke wrote:
> Steam crashes on startup with libgudev 238-2 currently in unstable.

Debian has no control over what's in the proprietary Steam client, so
please report this sort of thing to
.

Thanks,
smcv

Bug#1039923: Acknowledgement (RFP: scip -- linear and nonlinear mixed integer optimization suite)

[David Bremner]

"Debian Bug Tracking System"  writes:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1039923: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039923.

I started some packages for my own use at

  https://salsa.debian.org/bremner/scipoptsuite

The packaging is currently not suitable for upload (aka RC buggy), but
it does solve a few of the initial technical problems.

Bug#1038812: Bug#1041409: thunderbird: OpenPGP features in v115 requires librnp0 >= 0.17.0 not in archive

[Daniel Kahn Gillmor]

Control: block 1041409 by 1038812

Hi all--

Thanks for noticing this.  Putting rnp 0.17.0 in the archive will
require sexpp to land in the archive as well, but has been in in NEW for
a few weeks (see #1038812).

  --dkg

On Tue 2023-07-18 19:06:58 +0200, Carsten Schoenert wrote:
> Hi Alper,
>
> Am 18.07.23 um 17:20 schrieb Alper Nebi Yasak:
>> I decided to upgrade Thunderbird to the version in experimental, and
>> noticed that its OpenPGP functionality is completely broken: the Key
>> Manager is empty, and it doesn't even attempt to decrypt/verify
>> encrypted/signed messages (at least over external gnupg).
>
> ha, by accident I noticed the described behavior just a few hour ago too!
> Thanks for trying out Thunderbird from experimental, I expect we will 
> find a few more glitches like that.
>
>> The "Troubleshooting Information" page says the expected minimum version
>> for the RNP library is 0.17.0, where I had 0.16.3-1 installed as
>> currently in unstable.
>
> Unfortunately the Thunderbird build system does not do a really good job 
> on detecting required versions for libraries or equal. And it's mostly 
> difficult to detect such version bumps by reviewing manually changes 
> after importing a new version.
>
>> Seeing a 0.17.0~git20220428-1 version for librnp0 in experimental, I
>> tried installing that. But that doesn't work either, apparently its
>> source is older than 0.16.1? (Also see bug #1031363).
>> 
>> So I think Thunderbird needs to depend on librnp0 >= 0.17.0 (currently
>> unversioned), but no such version is in Debian yet. I got it to work by
>> sloppily packaging the newer source. (The proper package may take a bit,
>> has a new dependency apparently in NEW -- I'm CC-ing the maintainer.)
>
> Your analysis is correct, Thunderbird will need a version constrain on 
> librnp0. But this requires the package to be available at least in 
> experimental.
>
> I'll do some work around this and change the build system while 
> preparing the next upload so it is using the internal shipped librnp 
> version until Daniel has uploaded a newer version.
>
> -- 
> Regards
> Carsten


signature.asc
Description: PGP signature

Bug#1039983: Color Laser-Printer does only print in greyscale after upgrade to Debian 12

[Till Kamppeter]

Probably you are hitting this bug

https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1971242

The bug is fixed upstream in CUPS 2.4.3 and later and I have created 2 
Stable Release Updates (SRUs) for Ubuntu Jammy (CUPS 2.4.1) and Lunar 
(CUPS 2.4.2). So you could try these fixes and they could perhaps also 
get applied to Debian.

Bug#1041734: RM: gauche-gtk -- RoQA; depends on gtk2; low popcon

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:gauche-gtk

Please remove gauche-gtk. It depends on gtk2, has missed 
bullseye/bookworm, and has a very low popcon.

Bug#1041733: ITP: rust-linemux -- asynchronous, multiplexed file tailing

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-linemux
  Version : 0.3.0
  Upstream Contact: Jon Magnuson 
* URL : https://github.com/jmagnuson/linemux
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : asynchronous, multiplexed file tailing

 linemux is a library providing asynchronous, multiplexed tailing
 for (namely log) files.
 .
 Also available is the underlying file event-stream
 (driven by notify)
 that can register non-existent files.

This package is needed for tailspin (bug#1041717) and safe-vdash
(bug#1009781).
It will be maintained in the collaborative debian section of salsa, at
.

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmS8DncACgkQLHwxRsGg
ASEnVg/9Evn2uuNe5P7JwBOAcrbBoWLsAlViW7cr8ZpbenTAEeqVRuEGskMsIrR1
7Q5bqtXCxJk8yNZggXnJmQZvCTPjJ8YG/05TT5M+LeNQszQgnJqeXtDYXos6KGbX
YHGcCKHeN2HXAm9XftFPu+gtEZqxVFF/ghtH1wsOpCj7LXCzV6a9iVfEErevZPBU
T3eM1KXCwqM3U2mV2X/FvRcgkTtRIQEiC98JeLRRK6sGS6uiuaItT+WDq2NomuJE
siJO5pTELWuCZpMjAjVYfIE/emp7alp3NlepwPxENbgoxMza7GSbeecDqMrtsLR7
DzdmbzOfgVqzeYtfR50oiQ4hQG3O/l0uzAVEno7wilQCh+IphtMTBVcw3NFfu7Qk
RE28ObdHQPELCfswUXmqcAc8k1nzqIivyr0mRTbYqaek4tpaPPhK2SGKWR+sY04q
Far/c9wmo/AhgRq1u/NMN/1O/FOkJ8nx4fUaKSLFLO5Jcewmm0buNXA9Re1v1piS
3coRb2fi94WzwYTJ69Iwq4y0HvpZIRGUO5sLgkdjFyr4QXr02HIPUHmECr/jd61z
FaMmie9jXQADkQkcRFyl6/EHP6rAVZiuAdsQidRzlnokQIybpxYLcEzv3lb+emN7
lkLJLwx1+l/J/iG4nLAF4+375Z/E69X+IReJcIr6EKoXxFyy1jg=
=Tkfc
-END PGP SIGNATURE-

Bug#1041730: dpkg: Systemd dpkg-db-backup.timer unit should be "Persistent=true"

[Guillem Jover]

Hi!

On Sat, 2023-07-22 at 19:36:46 +0300, Teemu Likonen wrote:
> Package: dpkg
> Version: 1.21.22
> Severity: minor
> Tags: patch
> X-Debbugs-Cc: tliko...@iki.fi

> Dpkg installs systemd timer unit dpkg-db-backup.timer which is supposed
> to run daily:
> 
> # /lib/systemd/system/dpkg-db-backup.timer
> [Unit]
> Description=Daily dpkg database backup timer
> Documentation=man:dpkg(1)
> 
> [Timer]
> OnCalendar=daily
> 
> [Install]
> WantedBy=timers.target
> 
> The "OnCalendar=daily" rule means every night exactly at 00:00:00. The
> timer does not trigger if computer is not turned on exactly at that
> time.
> 
> I think the timer is meant to trigger daily even if the computer is not
> running at midnight. The attached patch makes the timer trigger
> immediately if the specified time has passed (Persistent=true).

Ah, indeed, nice catch! Queued the patch for the next push.

Thanks,
Guillem

Bug#1041732: "N: Missing Signed-By in the sources.list(5) entry for 'http://deb.debian.org/debian'"

[Jörn Heissler]

Package: apt
Version: 2.7.2
Severity: minor
X-Debbugs-Cc: debbugs2023...@wulf.eu.org


Hello,

since updating to apt-2.7.2 I'm getting a notice on "apt update":

# apt update
Hit:1 http://deb.debian.org/debian sid InRelease
Hit:2 http://deb.debian.org/debian experimental InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
N: Missing Signed-By in the sources.list(5) entry for 
'http://deb.debian.org/debian'
N: Missing Signed-By in the sources.list(5) entry for 
'http://deb.debian.org/debian'

My /etc/apt/sources.list.d/debian.sources contains:

Types: deb deb-src
URIs: http://deb.debian.org/debian/
Suites: sid experimental
Components: main contrib non-free non-free-firmware

The Changelog contains an entry:
* update: Add notice about missing Signed-By in deb822 sources"

I tried "Signed-By: /etc/apt/trusted.gpg.d/*" but that doesn't work.
What is the correct value?

Thanks!



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "0";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke "";
APT::Update::Post-Invoke:: "[ ! -x /usr/bin/debtags ] || debtags update || 
true";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "lz4";
APT::Compressor::lz4::Cost "50";
APT::Compressor::lz4::CompressArg "";
APT::Compressor::lz4::CompressArg:: "-1";
APT::Compressor::lz4::UncompressArg "";
APT::Compressor::lz4::UncompressArg:: "-d";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";

Bug#967760: suil: depends on deprecated GTK 2

[Bastian Germann]

None of the reverse dependencies are built with gtk2 anymore.
So it is time to drop the gtk2 dependencies from suil.

Bug#1039720: Acknowledgement (gnome-online-accounts: google account stop working files and calendar. Not able to re create online account.)

[Sergio Zamora]

Hi,


Disabling the switchable graphics on bios allowed me to configure the G 
online account. Enabling it again kept the change without any problem.



nvidia-driver issue ?


Best Regards.


On 11-07-23 12:36, Alberto Garcia wrote:

On Tue, Jul 11, 2023 at 12:17:22PM -0400, Sergio Zamora wrote:

try this from terminal ? :

$ WEBKIT_DISABLE_COMPOSITING_MODE=1 gnome-control-center

Yes. This only has a temporary effect and it will last until you close
the GNOME control center.

Thanks,

Berto

Bug#1041731: groff-base: "-" mapped as HYPHEN

[Sven Joachim]

Package: groff-base
Version: 1.23.0-2

This version of groff maps an unescaped "-" to HYPHEN rather than
HYPHEN-MINUS.  Due to that, copying text from manpages or following
references in the "SEE ALSO" section is rather unreliable, because many
manpages contain a plain "-" where they should have used "\-" instead.

Neither the upstream NEWS file nor the Debian changelog make any mention
of this change, or how to revert it locally.  Running "man" under
LC_ALL=C works around it, at the cost of worse typography.


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

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

Versions of packages groff-base depends on:
ii  libc6 2.37-6
ii  libgcc-s1 13.1.0-8
ii  libstdc++613.1.0-8
ii  libuchardet0  0.0.7-1

groff-base recommends no packages.

Versions of packages groff-base suggests:
ii  groff  1.23.0-2

-- no debconf information

Bug#1041703: Broken due to missed udev dependencies

[Martin Steigerwald]

Simon McVittie - 22.07.23, 18:01:22 CEST:
> On Sat, 22 Jul 2023 at 13:57:33 +0100, Klaus Ethgen wrote:
[…]
> > ii  libeudev1 [libudev1]  3.2.12-1
> 
> libeudev1 is not part of Debian. If it was, I'd be reassigning this
> bug to libeudev1; but it isn't, so I'm closing the bug instead.
> Please report this to wherever you obtained your libeudev1 package
> from.

I was not aware that eudev is not part of Debian.

Fair enough. Thanks.

-- 
Martin

Bug#1041730: dpkg: Systemd dpkg-db-backup.timer unit should be "Persistent=true"

[Teemu Likonen]

Package: dpkg
Version: 1.21.22
Severity: minor
Tags: patch
X-Debbugs-Cc: tliko...@iki.fi

Dpkg installs systemd timer unit dpkg-db-backup.timer which is supposed
to run daily:

# /lib/systemd/system/dpkg-db-backup.timer
[Unit]
Description=Daily dpkg database backup timer
Documentation=man:dpkg(1)

[Timer]
OnCalendar=daily

[Install]
WantedBy=timers.target

The "OnCalendar=daily" rule means every night exactly at 00:00:00. The
timer does not trigger if computer is not turned on exactly at that
time.

I think the timer is meant to trigger daily even if the computer is not
running at midnight. The attached patch makes the timer trigger
immediately if the specified time has passed (Persistent=true).


-- Package-specific info:
This system uses merged-usr-via-aliased-dirs, going behind dpkg's
back, breaking its core assumptions. This can cause silent file
overwrites and disappearances, and its general tools misbehavior.
See .

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.36-9
ii  liblzma5 5.4.1-0.2
ii  libmd0   1.0.4-2
ii  libselinux1  3.4-1+b6
ii  libzstd1 1.5.4+dfsg2-5
ii  tar  1.34+dfsg-1.2
ii  zlib1g   1:1.2.13.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.6.1
pn  debsig-verify  

-- no debconf information
--- debian/dpkg.dpkg-db-backup.timer~   2023-07-22 19:18:00.760386969 +0300
+++ debian/dpkg.dpkg-db-backup.timer2023-07-22 19:17:27.881116417 +0300
@@ -4,6 +4,7 @@
 
 [Timer]
 OnCalendar=daily
+Persistent=true
 
 [Install]
 WantedBy=timers.target

Bug#1040951: bookworm-pu: package dhcpcd5/9.4.1-24 deb12u1

[Adam D. Barratt]

On Sat, 2023-07-22 at 19:29 +0300, Martin-Éric Racine wrote:
> On Sat, Jul 22, 2023 at 7:26 PM Adam D. Barratt
>  wrote:
> > On Sat, 2023-07-22 at 18:03 +0300, Martin-Éric Racine wrote:
> > > Sure enough, I had forgotten to change the version used in
> > > dhcpcd.preinst to the tilde one. Fixed as per attachment.
> > 
> > Please could we have an interdiff from ~deb12u1, to make seeing the
> > specific change simpler?
> 
> Sure. Attached.
> 

Thanks, please feel free upload with that diff.

Regards,

Adam

Bug#1040951: bookworm-pu: package dhcpcd5/9.4.1-24 deb12u1

[Martin-Éric Racine]

On Sat, Jul 22, 2023 at 7:26 PM Adam D. Barratt
 wrote:
>
> On Sat, 2023-07-22 at 18:03 +0300, Martin-Éric Racine wrote:
> > Sure enough, I had forgotten to change the version used in
> > dhcpcd.preinst to the tilde one. Fixed as per attachment.
>
> Please could we have an interdiff from ~deb12u1, to make seeing the
> specific change simpler?

Sure. Attached.

Martin-Éric
diff -Nru dhcpcd5-9.4.1/debian/changelog dhcpcd5-9.4.1/debian/changelog
--- dhcpcd5-9.4.1/debian/changelog  2023-07-22 17:00:48.0 +0300
+++ dhcpcd5-9.4.1/debian/changelog  2023-07-22 17:56:49.0 +0300
@@ -1,3 +1,9 @@
+dhcpcd5 (9.4.1-24~deb12u2) bookworm; urgency=medium
+
+  * Fixed dhcpcd.preinst with the tilde version.
+
+ -- Martin-Éric Racine   Sat, 22 Jul 2023 17:56:49 
+0300
+
 dhcpcd5 (9.4.1-24~deb12u1) bookworm; urgency=medium
 
   * Backported Wheezy upgrade mitigation from unstable (Closes: #1037190).
diff -Nru dhcpcd5-9.4.1/debian/dhcpcd.preinst 
dhcpcd5-9.4.1/debian/dhcpcd.preinst
--- dhcpcd5-9.4.1/debian/dhcpcd.preinst 2023-07-22 17:00:48.0 +0300
+++ dhcpcd5-9.4.1/debian/dhcpcd.preinst 2023-07-22 17:56:40.0 +0300
@@ -2,7 +2,7 @@
 # As per Debian bug #1037190.
 # Copyright 2023 Andreas Beckmann 
 set -e
-if dpkg --compare-versions "$2" lt-nl "1:9.4.1-24+deb12u1~" ; then
+if dpkg --compare-versions "$2" lt-nl "1:9.4.1-24~deb12u2~" ; then
   # Cleanup leftovers from dhcpcd 1:3.* in Wheezy.
   # Can be removed after Trixie is released.
   update-alternatives --remove dhcpcd /sbin/dhcpcd3

Bug#1041729: RM: gxmms2 -- RoQA; RC-buggy; depends on gtk2; low popcon

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:gxmms2

Please remove gxmms2. It depends on gtk2, is RC-buggy (has missed 
bookworm), and has a low popcon.

Bug#1041699:

[Jacob ..]

Thanks Moritz,

Started the process of adding a patch to wolfssl_4.6.0+p1-0+deb11u1.1.dsc.

Sent from Mail for Windows

Bug#1040951: bookworm-pu: package dhcpcd5/9.4.1-24 deb12u1

[Adam D. Barratt]

On Sat, 2023-07-22 at 18:03 +0300, Martin-Éric Racine wrote:
> Sure enough, I had forgotten to change the version used in
> dhcpcd.preinst to the tilde one. Fixed as per attachment.

Please could we have an interdiff from ~deb12u1, to make seeing the
specific change simpler?

Regards,

Adam

Bug#1041725: RM: csmash -- RoQA; orphaned; depends on gtk2; low popcon

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:csmash

Please remove csmash. It depends on gtk2, is orphand, and has a low popcon.

Bug#1041724: RM: pidgin-librvp -- RoQA; orphaned; depends on gtk2; low popcon

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:pidgin-librvp

Please remove pidgin-librvp. It depends on gtk2, is orphand, and has a 
low popcon.

Bug#967242: abx: depends on deprecated GTK 2

[Bastian Germann]

I suggest removing abx to fix this.

Bug#1041696: apt-show-versions: wrong output when version of an installed package is missing from the unstable Packages file

[Vincent Lefevre]

On 2023-07-22 12:43:43 +0200, Vincent Lefevre wrote:
> zira:~> apt-show-versions -a libreoffice-common
> libreoffice-common:all 4:7.5.4-4 install ok installed
> libreoffice-common:all 4:7.4.5-3 stable   ftp.debian.org
> No stable-updates version
> libreoffice-common:all 4:7.4.7-1 testing  ftp.debian.org
> No unstable version
> libreoffice-common:all 4:7.5.5~rc1-2 experimental ftp.debian.org
> libreoffice-common:all/experimental *manually* upgradeable from 4:7.5.4-4 to 
> 4:7.5.5~rc1-2
> 
> The "libreoffice-common:all/experimental *manually* upgradeable"
> is wrong, because the installed version was the unstable version
> (not an experimental version), and for some reason, it has been
> removed from unstable.
[...]

Note that this is a completely different bug than the one fixed
in 0.22.14. For the one fixed in 0.22.14, the cache was incorrect
(and one of the first lines of the output was incorrect too as a
consequence).

Here, on the contrary, the cache is correct, and the output is
correct except the last line.

A first thing to do could be to stop writing "/experimental" if
it can't be sure (ditto for the other distributions). At least the
line would no longer be misleading. This may even be sufficient.

Or perhaps write something like

  libreoffice-common:all *manually* upgradeable from 4:7.5.4-4 to 4:7.5.5~rc1-2 
(experimental)

or it could give more information, such as

  libreoffice-common:all *manually* upgradeable from 4:7.5.4-4 (> unstable) to 
4:7.5.5~rc1-2 (experimental)

or

  libreoffice-common:all *manually* upgradeable from 4:7.5.4-4 (unknown) to 
4:7.5.5~rc1-2 (experimental)

depending on whether there is an unstable version (first case)
or not (second case).

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

Bug#1040890: nvidia-settings-tesla 525.125.06-1~deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nvidia-settings-tesla
Version: 525.125.06-1~deb12u1

Explanation: new upstream bugfix release

Bug#1041272: transmission 3.00-2.1+deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: transmission
Version: 3.00-2.1+deb12u1

Explanation: replace openssl3 compat patch to fix memory leak

Bug#1040939: rmlint 2.9.0-2.3+deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: rmlint
Version: 2.9.0-2.3+deb12u1

Explanation: fix error in other packages caused by invalid python package 
version

Bug#1040770: nvidia-settings 525.125.06-1~deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nvidia-settings
Version: 525.125.06-1~deb12u1

Explanation: new upstream bugfix release

Bug#1040768: libxnvctrl 525.85.05-3~deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libxnvctrl
Version: 525.85.05-3~deb12u1

Explanation: new source package split from nvidia-settings

Bug#1041723: darktable: Please update to latest upstream

[Shin Ice]

Package: darktable
Version: 4.2.1-4
Severity: wishlist

Dear Maintainer,

would you please be so kind to update to the latest upstream version?

If there is anything I can help you here, instead of bothering you each time,
please feel free to let me know.

Best wishes & thanks =)

Greetings
Shin


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

Kernel: Linux 6.3.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 darktable depends on:
ii  libavif150.11.1-3
ii  libc62.37-6
ii  libcairo21.16.0-7
ii  libcolord-gtk1   0.3.0-4
ii  libcolord2   1.4.6-2.2
ii  libcups2 2.4.2-5
ii  libcurl3-gnutls  7.88.1-10
ii  libexiv2-27  0.27.6-1
ii  libgcc-s113.1.0-8
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.76.4-3
ii  libgomp1 13.1.0-8
ii  libgphoto2-6 2.5.30-1
ii  libgphoto2-port122.5.30-1
ii  libgraphicsmagick-q16-3  1.4+really1.3.40-4
ii  libgtk-3-0   3.24.37-2
ii  libheif1 1.16.2-2
ii  libicu72 72.1-3
ii  libimath-3-1-29  3.1.6-1
ii  libjpeg62-turbo  1:2.1.5-2
ii  libjson-glib-1.0-0   1.6.6-1
ii  libjxl0.70.7.0-10
ii  liblcms2-2   2.14-2
ii  liblensfun1  0.3.3-1
ii  liblua5.4-0  5.4.4-3
ii  libopenexr-3-1-303.1.5-5
ii  libopenjp2-7 2.5.0-2
ii  libosmgpsmap-1.0-1   1.2.0-2
ii  libpango-1.0-0   1.50.14+ds-1
ii  libpangocairo-1.0-0  1.50.14+ds-1
ii  libpng16-16  1.6.40-1
ii  libportmidi0 1:217-6.1
ii  libpugixml1v51.13-0.2
ii  librsvg2-2   2.54.5+dfsg-3
ii  libsdl2-2.0-02.28.1+dfsg-1
ii  libsecret-1-00.20.5-3
ii  libsoup2.4-1 2.74.3-1
ii  libsqlite3-0 3.42.0-1
ii  libstdc++6   13.1.0-8
ii  libtiff6 4.5.1-1
ii  libwebp7 1.2.4-0.2
ii  libwebpmux3  1.2.4-0.2
ii  libx11-6 2:1.8.6-1
ii  libxml2  2.9.14+dfsg-1.3
ii  libxrandr2   2:1.5.2-2+b1
ii  zlib1g   1:1.2.13.dfsg-1

darktable recommends no packages.

darktable suggests no packages.

-- no debconf information

--

I'm just a placeholder for a really awesome signature...
...that is still missing *sob*


signature.asc
Description: PGP signature

Bug#1041711: libmovit8: nageru fails to compile a shader on startup

[Steinar H. Gunderson]

On Sat, Jul 22, 2023 at 03:40:32PM +, stefa...@debian.org wrote:
> Nope, same error with LC_ALL=C.
> Nicolas next to me (also on an AMD system running Debian unstable) hits
> exactly the same bug.

I don't have any AMD machines anymore, unfortunately, only Intel and NVidia.
(Back when I had one, the drivers used to be untenably buggy...) Is there
any way I can perhaps SSH into a system or similar to try to figure out
what's going on?

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