Bug#1041685: foot-terminfo: Please let ncurses-term take over the foot terminfo entries

[Sven Joachim]

Package: foot-terminfo
Version: 1.15.0-1
Severity: wishlist

Two years ago the foot and foot-direct terminfo entries were added to
ncurses upstream, and I would like to include them in the ncurses-term
package, replacing the ones shipped currently in the foot-terminfo
package.

This requires coordinated uploads of foot and ncurses, adding a
versioned Breaks/Replaces on foot-terminfo to ncurses-term and a
versioned dependency on ncurses-term to foot.  The foot-terminfo package
would either become a transitional package or could be dropped entirely.

The benefit for foot users would be that ncurses-term is much more
likely to be installed on any remote system they might want to connect
to than foot-terminfo (popcon score is 96.39% vs 0.58%).

Bug#1041688: src:golang-github-grpc-ecosystem-grpc-gateway: fails to migrate to testing for too long: FTBFS & autopkgtest regression

[Paul Gevers]

Source: golang-github-grpc-ecosystem-grpc-gateway
Version: 1.6.4-2
Severity: serious
Control: close -1 1.16.0-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1038870

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:golang-github-grpc-ecosystem-grpc-gateway 
has been trying to migrate for 31 days [2]. Hence, I am filing this bug. 
The version in unstable fails to build on 32 bit (bug #1038870) and 
fails its own autopkgtest.


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=golang-github-grpc-ecosystem-grpc-gateway




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034668: Please update to new upstream release 3.22.3 in experimental

[Nilesh Patra]

On Sat, Jul 22, 2023 at 05:33:03AM +0530, Nilesh Patra wrote:
> **NB1:** The static libs are not present in the protobuf lib at the moment
> because this changed after the build system changed, and needs some work to 
> get both shared
> and static libs enabled and it's 5 in the morning and
> I'm too tired and sleepy to work on it. For gitlab's usecase, static libs are 
> *probably*
> not needed.

This was actually easy to implement, attached modified patch to get the
static libraries building as well.

The third party utf8's static libs are not installed still
because I don't really know if they are needed.
But if they are, it should be as simple as adding it to an install
file with relevant path, much like how protobuf's static libs are
installed.

That said, my work for the gitlab issue ends here 

> **NB2:** bazel buildsystem probably downloads some stuff off the
> internet for this package (I did not check in depth) so the debian way
> of doing it would be to either package the stuff it needs or download
> copies beforehand and use that in build.

This still seems to be an issue, though. During build I could see it
fetch some tarballs from github.

> PS: Sponsor me a party/dinner when?
> 
> [0]: https://people.debian.org/~praveen/new/pool/main/p/protobuf/
> [1]: https://github.com/abseil/abseil-cpp/issues/1407
> [2]: https://github.com/google/googletest/issues/2184
> [3]: 
> https://salsa.debian.org/debian/abseil/-/commit/136c2572f4d6e6ab8ae02f74d691634874458184
> [4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034908#48


Best,
Nilesh
commit 287465705eea4572b76a5d45308c2a5c3377cead
Author: Nilesh Patra 
Date:   Sat Jul 22 12:53:53 2023 +0530

Vendor static libs as well

diff --git a/debian/changelog b/debian/changelog
index 338446c..03edb4e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+protobuf (3.23.4-1) UNRELEASED; urgency=medium
+
+  * New upstream version 3.23.4
+
+ -- Nilesh Patra   Sat, 22 Jul 2023 00:14:20 +0530
+
 protobuf (3.22.3-1) experimental; urgency=medium
 
   * New upstream release 3.22.3.
diff --git a/debian/clean b/debian/clean
index 43ff921..905c503 100644
--- a/debian/clean
+++ b/debian/clean
@@ -1,3 +1,8 @@
 protoc.1
 ruby/ext/google/protobuf_c/third_party/wyhash/wyhash.h
 ruby/tests/multi_level_nesting_test_pb.rb
+ruby/ext/google/protobuf_c/naive.c
+ruby/ext/google/protobuf_c/range2-neon.c
+ruby/ext/google/protobuf_c/range2-sse.c
+ruby/ext/google/protobuf_c/utf8_range.h
+python/google/protobuf/internal/generator_test.py
diff --git a/debian/control b/debian/control
index 6bc74c8..cff61f0 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,8 @@ Build-Depends:
  , cmake
 # C/C++
  , zlib1g-dev
- , libabsl-dev
+ , bazel-bootstrap
+ , libabsl-dev (>= 20230125.3-1~)
  , libgmock-dev 
  , libgtest-dev 
 # Python
@@ -19,6 +20,7 @@ Build-Depends:
  , libpython3-all-dev 
  , python3-setuptools 
  , python3-six 
+ , python3-numpy 
 # Manpage generator
  , xmlto
 # Tests
diff --git a/debian/libprotobuf-dev.install b/debian/libprotobuf-dev.install
index ad15927..a2c8719 100644
--- a/debian/libprotobuf-dev.install
+++ b/debian/libprotobuf-dev.install
@@ -4,3 +4,4 @@ usr/lib/*/libprotobuf.so
 usr/lib/*/libprotobuf-lite.so
 usr/lib/*/pkgconfig/*
 usr/include
+usr/lib/*/cmake/protobuf/*.cmake
diff --git a/debian/patches/append-lib-dirs.patch b/debian/patches/append-lib-dirs.patch
new file mode 100644
index 000..ab27a3e
--- /dev/null
+++ b/debian/patches/append-lib-dirs.patch
@@ -0,0 +1,21 @@
+--- a/python/setup.py
 b/python/setup.py
+@@ -344,6 +344,9 @@
+   else:
+ library_dirs = ['..']
+ 
++if library_dirs is None:
++library_dirs= []
++library_dirs.append('../shared')
+ TestConformanceCmd.target = ('//python:conformance_test_cpp '
+  '--define=use_fast_cpp_protos=true')
+ 
+@@ -412,7 +415,7 @@
+ Extension(
+ 'google.protobuf.pyext._message',
+ glob.glob('google/protobuf/pyext/*.cc'),
+-include_dirs=['.', '../src', '../third_party/abseil-cpp'],
++include_dirs=['.', '../src'],
+ libraries=libraries,
+ extra_objects=extra_objects,
+ extra_link_args=message_extra_link_args,
diff --git a/debian/patches/fix_hppa_alignof_assert.patch b/debian/patches/fix_hppa_alignof_assert.patch
index fad5aa3..d4b703b 100644
--- a/debian/patches/fix_hppa_alignof_assert.patch
+++ b/debian/patches/fix_hppa_alignof_assert.patch
@@ -8,7 +8,7 @@ Last-Update: 2023-04-09
 
 --- a/src/google/protobuf/descriptor.cc
 +++ b/src/google/protobuf/descriptor.cc
-@@ -381,7 +381,9 @@
+@@ -384,7 +384,9 @@
  ABSL_CHECK(!has_allocated());
  if (std::is_trivially_destructible::value) {
// Trivial types are aligned to 8 bytes.
@@ -20,7 +20,7 @@ Last-Update: 2023-04-09
// Since we can't use `if constexpr`, just make the expression compile
 --- a/src/google/protobuf/map.h
 +++ b/src/google/protobuf/map.h
-@@ 

Bug#1041684: ITP: not-ocamlfind -- front-end to ocamlfind to add a few new commands

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-ocaml-ma...@lists.debian.org

* Package name: not-ocamlfind
  Version : 0.10
  Upstream Contact: Chet Murthy
* URL : https://github.com/chetmurthy/not-ocamlfind
* License : MIT
  Programming Lang: OCaml
  Description : front-end to ocamlfind to add a few new commands

 The command not-ocamlfind is a pass-thru to ocamlfind, but adds three
 new commands: preprocess, reinstall-if-diff and package-graph.

This package is a new dependency of camlp5. It will be maintained in
the OCaml team.

Bug#1041687: src:accountsservice: fails to migrate to testing for too long: FTBFS

[Paul Gevers]

Source: accountsservice
Version: 22.08.8-6
Severity: serious
Control: close -1 23.13.9-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1038865

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:accountsservice has been trying to migrate 
for 31 days [2]. Hence, I am filing this bug.


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=accountsservice



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1041691: src:libchemistry-opensmiles-perl: fails to migrate to testing for too long: causes autopkgtest regression

[Paul Gevers]

Source: libchemistry-opensmiles-perl
Version: 0.8.5-1
Severity: serious
Control: close -1 0.8.6-1
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:libchemistry-opensmiles-perl has been 
trying to migrate for 32 days [2]. Hence, I am filing this bug. The 
version in unstable breaks the (autopkg)test of smiles-scripts.


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=libchemistry-opensmiles-perl



OpenPGP_signature
Description: OpenPGP digital signature

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

[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



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

Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.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 udisks2 depends on:
ii  dbus   1.14.8-2
ii  libacl12.3.1-3
ii  libatasmart4   0.19-5
ii  libblkid1  2.38.1-6
ii  libblockdev-crypto33.0.1-2
ii  libblockdev-fs33.0.1-2
ii  libblockdev-loop3  3.0.1-2
ii  libblockdev-mdraid33.0.1-2
ii  libblockdev-nvme3  3.0.1-2
ii  libblockdev-part3  3.0.1-2
ii  libblockdev-swap3  3.0.1-2
ii  libblockdev-utils3 3.0.1-2
ii  libblockdev3   3.0.1-2
ii  libc6  2.37-5
ii  libglib2.0-0   2.74.6-2
ii  libgudev-1.0-0 237-2
ii  libmount1  2.38.1-6
ii  libpolkit-agent-1-0122-4
ii  libpolkit-gobject-1-0  122-4
ii  libsystemd0253.5-1
ii  libudisks2-0   2.10.0-3
ii  libuuid1   2.38.1-6
ii  parted 3.6-3
ii  udev   253.5-1

Versions of packages udisks2 recommends:
ii  dosfstools  4.2-1
ii  e2fsprogs   1.47.0-2
ii  eject   2.38.1-6
ii  exfatprogs  1.2.1-2
ii  libpam-systemd  253.5-1
ii  ntfs-3g 1:2022.10.3-1+b1
ii  polkitd 122-4

Versions of packages udisks2 suggests:
pn  btrfs-progs
pn  f2fs-tools 
pn  mdadm  
pn  nilfs-tools
pn  reiserfsprogs  
pn  udftools   
pn  udisks2-btrfs  
pn  udisks2-lvm2   
pn  xfsprogs   

-- no debconf information

Bug#1037593: binutils-avr: ftbfs with GCC-13

[Gregor Riepl]

Upstream has fixed this via
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5b429b870767e2107bcc7d5d849e04d6901b5912


Thanks for uploading the fix.

Unfortunately, it looks like the buildds are still choking on it:
https://buildd.debian.org/status/package.php?p=binutils-avr


# Convert hardlinks to softlinks
cd debian/binutils-avr/usr/lib/avr/bin && for f in *; do \
rm ../../../bin/avr-$f; \
ln -s ../lib/avr/bin/$f ../../../bin/avr-$f; \
done
/bin/sh: 1: cd: can't cd to debian/binutils-avr/usr/lib/avr/bin
make: *** [debian/rules:88: install] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess 
returned exit status 2



Could you take a look?
Thanks!

Bug#1041690: RM: picolisp [s390x] -- NBS; maintainer explicitly dropped s390x

[Paul Gevers]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: picol...@packages.debian.org, kos...@debian.org
Control: affects -1 + src:picolisp

Dear ftp-master,

The maintainer of picolisp (in XD-CC) dropped s390x from the supported
architectures in the last upload. Because the binary is still
available on s390x for the old version, the package fails to
migrate. Please remove the old binary.

Paul

Bug#1041642: dh_missing: Doesn't work if used in $(CURDIR)

[Niels Thykier]

Control: tags -1 wontfix

Daniel Leidert:

Package: debhelper
Version: 13.11.4
Severity: normal

I have a native package source from which I build multiple binary packages. The
files are organized as they would be on the target system with their full
destination path. As an example, the souirce directory contains:

./usr/share/applications/foo.desktop

[...]

This might be a cornercase, but I find it quite weird that it isn't working and
I could really use this. Is that a bug or a feature request?

Regards, Daniel

[...]



Hi Daniel

You have indeed hit a corner case and I do not think it makes sense to 
change dh_missing to support it.


You can trivially work around it by moving the "FS layout" into a 
subdirectory (e.g., "mkdir root && mv ... root/") and then use "root" as 
the --sourcedir for the dh_* tools that need --sourcedir.


As for having dh_missing support "$(CURDIR)", then most packages have a 
lost of "cruft" in "$(CURDIR)" that you would have to manually exclude - 
you see it already with your own cmd-line having to ignore debian + 
README.  There is one "exciting" thing here in that excludes are 
"global" - so the -X README.md ignores `README.md` *anywhere* it might 
occur, so you do not get warnings if you get install a `README.md` from 
somewhere (that is not the root). Probably benign in most cases but also 
surprising for most - and changing the -X semantics would be a pain.


For these (and other reasons), dh_missing is built around the concept of 
checking the output of "make install" rather than the source root. I do 
not see a good reason nor a compelling argument for changing that given 
the trivial work around for this one corner case, where might have been 
useful.


Accordingly, I have tagged the bug as wontfix.

Best regards,
Niels

Bug#1027959: transition: libkiwix

[Kunal Mehta]

Hi,

On 6/19/23 18:36, Sebastian Ramacher wrote:

Let's do this one properly during the trixie release cycle.


What's the status here?


I think we're ready to go. libzim is sorted (the ABI change was 
reverted, unstable is now at 8.1.1).


I just uploaded libkiwix 12.0.0-2 (to fix 2 RC bugs) and kiwix-tools 
3.5.0-1 (new upstream version) to experimental, those two plus kiwix 
2.3.1-1 should be set.


-- Kunal

Bug#897959: fbterm: Please stop shipping /usr/share/terminfo/f/fbterm

[Sven Joachim]

On 2018-05-05 10:22 +0200, Sven Joachim wrote:

> Package: fbterm
> Version: 1.7-4
> Severity: wishlist
>
> Last year the fbterm terminal description was added to ncurses
> upstream, and I would like to add it to the ncurses-term package,
> replacing the one shipped currently in the fbterm package.
>
> This requires coordinated uploads of ncurses and fbterm, adding a
> versioned Breaks/Replaces on fbterm to ncurses-term and a versioned
> dependency on ncurses-term to fbterm.
>
> The benefit for fbterm users would be that ncurses-term is much more
> likely to be installed on any remote system they might want to connect
> to than fbterm, so setting TERM=fbterm has a higher chance to work in
> such cases.

Gentle ping, as there has been no reply yet.  I still think this would
be a good idea, and you do not need to run tic at build time as well
(see #1034644).

Cheers,
   Sven

Bug#1041686: Add support for HTTP Status Code 308 as described in RFC 7238 (with patch)

[Joey Schulze]

Package: lynx
Version: 2.9.0dev.12-1
Severity: wishlist
Tags: patch upstream
X-Debbugs-Cc: j...@infodrom.org

Hi,

please add support for HTTP Status Code 308 (Permanent Redirect) to
lynx, at least for the request method GET.  This new code has been
specified in RFC 7238 in 2014.

Attached please find a patch for the quilt system which can be easily
integrated.

Please also forward it to the upstream project.

Regards

Joey
Support HTTP Status Code 308 Permanent Redirect

Code 308 does not allow switching from POST to GET protocol,
thus aborting when doing POST requests.

Index: lynx-2.9.0dev.12/WWW/Library/Implementation/HTTP.c
===
--- lynx-2.9.0dev.12.orig/WWW/Library/Implementation/HTTP.c
+++ lynx-2.9.0dev.12/WWW/Library/Implementation/HTTP.c
@@ -2213,7 +2213,8 @@ static int HTLoadHTTP(const char *arg,
 * 305 Use Proxy.
 * 306 Set Proxy.
 * 307 Temporary Redirect with method retained.
-* > 308 is unknown.
+* 308 Permanent Redirect
+* > 309 is unknown.
 */
if (no_url_redirection || do_head || keep_mime_headers) {
/*
@@ -2267,7 +2268,7 @@ static int HTLoadHTTP(const char *arg,
 
if (server_status == 305 ||
server_status == 306 ||
-   server_status > 307) {
+   server_status > 308) {
/*
 * Show user the content, if any, for 305, 306, or unknown
 * status.  - FM
@@ -2341,6 +2342,19 @@ static int HTLoadHTTP(const char *arg,
HTAlert(gettext("Have POST content.  Treating 
Permanent Redirection as Temporary.\n"));
} else {
permanent_redirection = TRUE;
+   }
+   }
+   if (server_status == 308) { /* Permanent Redirect */
+   if (do_post) {
+   /*
+* Don't make the redirection permanent if we have
+* POST content.  - FM
+*/
+   CTRACE((tfp,
+   "HTTP: Have POST content.  Treating 308 
(Permanent) as Temporary.\n"));
+   HTAlert(gettext("Have POST content.  Treating 
Permanent Redirection as Temporary.\n"));
+   } else {
+   permanent_redirection = TRUE;
}
}
doing_redirect = TRUE;

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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#1019013:

[Jordan Justen]

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

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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#1041692: python3-mesonpy: could the build be verbose by default

[Picca Frédéric-Emmanuel]

Package: python3-mesonpy
Version: 0.12.0-2
Severity: normal
X-Debbugs-Cc: pi...@debian.org

Dear Maintainer,

I am packaging python-fabio and pyfai whcih use this new build system for 
python extensions.

Now blhc complain that the compilation is not verbose.
So I need to add something like this to abtain a verbose output.

override_dh_auto_build:
PYBUILD_BUILD_ARGS="-Ccompile-args=--verbose" dh_auto_build

It seems to me that it will be a lot eaysier to have a default verbose output
instead of modifying each package which use this build system.

thanks for considering

Frederic

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

Kernel: Linux 6.3.0-1-amd64 (SMP w/4 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 python3-mesonpy depends on:
ii  libjs-sphinxdoc 5.3.0-4
ii  meson   1.2.0-1
ii  ninja-build 1.11.1-1
ii  python3 3.11.4-5
ii  python3-pyproject-metadata  0.6.1-3
ii  python3-tomli   2.0.1-2
ii  python3-typing-extensions   4.4.0-1

Versions of packages python3-mesonpy recommends:
ii  patchelf  0.14.3-1+b1

python3-mesonpy suggests no packages.

-- no debconf information

Bug#1037851: Your mail

[Bastian Germann]

On Sat, 22 Jul 2023 11:36:10 +1000 Matthew Fernandez wrote:
Btw, why does this bug not appear when searching for bugs against the 
package? https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=rumur


Because it is reported for the source package (replace ?pkg=rumur with 
?src=rumur).

Bug#1041693: borgbackup: recommend fuse3 instead of fuse

[srscrb+anoudqh2mr8ec]

Package: borgbackup
Version: 1.2.4-1
Severity: normal

Dear Maintainer,

borgbackup in bookworm currently has 'fuse' as recommends. It should instead 
recommend 'fuse3'.

'fuse3' has 'Provides: fuse' and fully replaces 'fuse'

Please fix.
thanks

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

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

Versions of packages borgbackup depends on:
ii  libacl12.3.1-3
ii  libc6  2.36-9
ii  liblz4-1   1.9.4-1
ii  libssl33.0.9-1
ii  libxxhash0 0.8.1-1
ii  libzstd1   1.5.4+dfsg2-5
ii  python33.11.2-1+b1
ii  python3-msgpack1.0.3-2+b1
ii  python3-packaging  23.0-1
ii  python3-pkg-resources  66.1.1-1

Versions of packages borgbackup recommends:
ii  fuse3 [fuse] 3.14.0-4
ii  python3-llfuse   1.4.1+dfsg-2+b3
ii  python3-pyfuse3  3.2.1-2+b2

Versions of packages borgbackup suggests:
pn  borgbackup-doc  

-- no debconf information

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

[Steven Haigh]

It looks like this report is over a year old - but there's been no 
movement on it.


It seems that a PD request won't work on Debian 12 either using 4.4.3.

Is there any reason as to why this patch hasn't been added?
--
Steven Haigh

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

Bug#967677: oss4: depends on deprecated GTK 2

[Bastian Germann]

On Tue, 04 Aug 2020 11:57:53 +0100 s...@debian.org wrote:

This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
binary packages with a Depends on GTK 2.


I suggest to remove the binary package oss4-gtk and buildwithout gtk.

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

[Vincent Lefevre]

Package: apt-show-versions
Version: 0.22.14
Severity: important

I get the following:

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.

Ditto for the other "Architecture: all" packages from the
libreoffice source:

zira:~> apt-show-versions -u | grep manually
fonts-opensymbol:all/experimental *manually* upgradeable from 
4:102.12+LibO7.5.4-4 to 4:102.12+LibO7.5.5~rc1-2
liblibreoffice-java:all/experimental *manually* upgradeable from 4:7.5.4-4 to 
4:7.5.5~rc1-2
libreoffice-common:all/experimental *manually* upgradeable from 4:7.5.4-4 to 
4:7.5.5~rc1-2
libreoffice-java-common:all/experimental *manually* upgradeable from 4:7.5.4-4 
to 4:7.5.5~rc1-2
libreoffice-nlpsolver:all/experimental *manually* upgradeable from 
4:0.9+LibO7.5.4-4 to 4:0.9+LibO7.5.5~rc1-2
libreoffice-report-builder:all/experimental *manually* upgradeable from 
4:7.5.4-4 to 4:7.5.5~rc1-2
libreoffice-script-provider-bsh:all/experimental *manually* upgradeable from 
4:7.5.4-4 to 4:7.5.5~rc1-2
libreoffice-script-provider-js:all/experimental *manually* upgradeable from 
4:7.5.4-4 to 4:7.5.5~rc1-2
libreoffice-script-provider-python:all/experimental *manually* upgradeable from 
4:7.5.4-4 to 4:7.5.5~rc1-2
libreoffice-style-colibre:all/experimental *manually* upgradeable from 
4:7.5.4-4 to 4:7.5.5~rc1-2
libreoffice-wiki-publisher:all/experimental *manually* upgradeable from 
4:1.2.0+LibO7.5.4-4 to 4:1.2.0+LibO7.5.5~rc1-2
libunoloader-java:all/experimental *manually* upgradeable from 4:7.5.4-4 to 
4:7.5.5~rc1-2

This is actually the *first* issue I had at
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858337#5

Now I can give more information:

zira:~> grep '^Package: libreoffice-common' /var/lib/apt/lists/*Packages
/var/lib/apt/lists/ftp.debian.org_debian_dists_experimental_main_binary-amd64_Packages:Package:
 libreoffice-common
/var/lib/apt/lists/ftp.debian.org_debian_dists_stable_main_binary-amd64_Packages:Package:
 libreoffice-common
/var/lib/apt/lists/ftp.debian.org_debian_dists_testing_main_binary-amd64_Packages:Package:
 libreoffice-common

but

zira:~> grep '^Package: libreoffice$' /var/lib/apt/lists/*Packages
/var/lib/apt/lists/ftp.debian.org_debian_dists_experimental_main_binary-amd64_Packages:Package:
 libreoffice
/var/lib/apt/lists/ftp.debian.org_debian_dists_stable_main_binary-amd64_Packages:Package:
 libreoffice
/var/lib/apt/lists/ftp.debian.org_debian_dists_testing_main_binary-amd64_Packages:Package:
 libreoffice
/var/lib/apt/lists/ftp.debian.org_debian_dists_unstable_main_binary-amd64_Packages:Package:
 libreoffice

I suspect that the amd64 packages could be uploaded but there was some
failure with the "Architecture: all" packages, with the additional
consequence that the old unstable version is no longer listed.

As you can see, this is not the first time this occurs, and
apt-show-versions should handle that to avoid outputting incorrect
information. Perhaps some special detection concerning unstable vs
experimental in case of "No unstable version".

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

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

Versions of packages apt-show-versions depends on:
ii  apt  2.7.2
ii  libapt-pkg-perl  0.1.40+b2
ii  perl [libstorable-perl]  5.36.0-7

apt-show-versions recommends no packages.

apt-show-versions suggests no packages.

-- no debconf information

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

Bug#1041697: linux-image-6.1.0-10-amd64: Hang at shutdown with mdraid

[Steve Onding]

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

Dear Maintainer,

after upgrading a server to bookworm, I experience hangs on shutdown
while the console is spammed with "md: mdXX stopped." messages.

As this is a remote server, it's tricky for me to copy the entire
shutdown log, but I was able to catch some of the repeated messages on a
screen recording:

[...]
md: md30 stopped.
md: md30 stopped.
md: md30 stopped.
md: md30 stopped.
md: md30 stopped.
[...]
md: md30 stopped.
systemd-shutdown[1]: Not all MD devices stopped, 1 left.
systemd-shutdown[1]: Stopping MD devices.
systemd-shutdown[1]: Stopping MD /dev/md30 (9:30).
md: md30 stopped.
systemd-shutdown[1]: Not all MD devices stopped, 1 left.
systemd-shutdown[1]: Stopping MD devices.
systemd-shutdown[1]: Stopping MD /dev/md30 (9:30).
md: md30 stopped.
systemd-shutdown[1]: Not all MD devices stopped, 1 left.
systemd-shutdown[1]: Stopping MD devices.
systemd-shutdown[1]: Stopping MD /dev/md30 (9:30).
md: md30 stopped.
[...]

I believe the issue to be very similar to #1023876 but AIUI the BTS
won't let me add messages to an archived bug. 

I have tested both 6.1.37 (bookworm) and 6.1.38
(bookworm-proposed-updates)
which both appear to be affected. I haven't tested older versions so I
am unsure if the issue reappeared or was never fully fixed.

This is my first time reporting a bug to the BTS so please excuse any
newbie mistakes (but feel free to point them out so I can do it properly
next time).

Thanks and best regards,

Steve

-- additional info: kernel log
reportbug was unable to read the kernel log so I've pasted dmesg output
of the running system here: https://paste.debian.net/hidden/359bf40e/

Sadly I don't know how to capture dmesg during shutdown on this server.

-- additional info: block device information, mdraid and mdadm
information
# set -x ; lsblk ; cat /proc/mdstat ; cat /etc/mdadm/mdadm.conf ; mdadm
--examine --scan
I've pasted the output here: https://paste.debian.net/hidden/1393afd2/

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

** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-10-amd64 root=UUID=[id redacted but confirmed
identical to the one that appears in `blkid /dev/md1`] ro net.ifnames=0
biosdevname=0 nomodeset consoleblank=0

** Not tainted

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

** Model information
sys_vendor: QEMU
product_name: Standard PC (i440FX + PIIX, 1996)
product_version: pc-i440fx-3.1
chassis_vendor: QEMU
chassis_version: pc-i440fx-3.1
bios_vendor: SeaBIOS
bios_version: 1.12.0-1

** Loaded modules:
nf_tables
nfnetlink
cpufreq_powersave
cpufreq_conservative
cpufreq_userspace
cpufreq_ondemand
bridge
stp
llc
intel_rapl_msr
intel_rapl_common
kvm_intel
binfmt_misc
kvm
ppdev
irqbypass
rapl
drm_vram_helper
joydev
evdev
sg
drm_ttm_helper
serio_raw
parport_pc
ttm
parport
drm_kms_helper
button
drm
dm_mod
fuse
loop
efi_pstore
configfs
qemu_fw_cfg
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
btrfs
blake2b_generic
zstd_compress
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
multipath
linear
raid1
raid0
md_mod
hid_generic
usbhid
hid
crc32_pclmul
crc32c_intel
sd_mod
t10_pi
crc64_rocksoft_generic
ghash_clmulni_intel
crc64_rocksoft
crc_t10dif
crct10dif_generic
crct10dif_pclmul
sha512_ssse3
crc64
crct10dif_common
ata_generic
sha512_generic
ahci
libahci
ata_piix
libata
aesni_intel
uhci_hcd
ehci_hcd
crypto_simd
e1000e
scsi_mod
cryptd
usbcore
psmouse
ptp
pps_core
usb_common
i2c_piix4
scsi_common
floppy

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC
[Natoma] [8086:1237] (rev 02)
Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- 
Kernel driver in use: ahci
Kernel modules: ahci

00:04.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit
Network Connection [8086:10d3]
Subsystem: Intel Corporation 82574L Gigabit Network Connection
[8086:]
Physical Slot: 4
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
SERR- 
Kernel driver in use: e1000e
Kernel modules: e1000e


** USB devices:
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU Tablet
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


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

Bug#1030394: Bug#1040690: reassign bug to correct package

[Nikolaus Rath]

Hi,

In case it helps, I also still have the "apt dist-upgrade" output for an 
affected system.

I don't remember installing any elpa packages from non-stable, but I can't rule 
it out either.

Best,
-Nikolaus

Bug#1024167: ITP: ruby-arr-pm -- RPM reader and writer library

[thegodtune]

Hi Myczko,

At some point I gave up packaging ruby-arr-pm because it was getting
too stressful, but I am back to it, I'll have it in the archive soon.
On Sat, 2023-05-06 at 13:13 +0200, Gürkan Myczko wrote:
> Hi Ajayi
> 
> I'm so glad you want to package this, as I'd need it to package this:
> http://sid.ethz.ch/debian/fpm/
> 
> I'm aware packages.debian.org/src:fpm is already used, but before I 
> write RFP or ITP,
> I'd like to see (first ruby package) how it works, if it works, how
> well 
> it works, if it works at all, etc...
> 
> Are you progressing with the packaging? Stuck somewhere? Will it land
> on 
> salsa.debian.org?
> (
> https://salsa.debian.org/search?search=ruby-arr-pm_source=navbar 
> zero results)
> 
> Best,

Bug#1007698: ITP: kasts -- kasts is a podcast client for desktop and mobile

[Salvo Tomaselli]

Hello,

I was planning to do it in the summer, but my hard drive is broken,
I'm waiting for lenovo to do something about it.

Il giorno sab 1 lug 2023 alle ore 15:57 Marco Mattiolo
 ha scritto:
>
> Hi Tzafrir,
>
> no news on my side for the packaging. There's an ITP bug submitted by Salvo, 
> I will leave that answer to him.
>
> Thank you for the MR on 23.04.2!
>
> My 2 cents on the icons issue: I faced the same when installing kasts in a 
> non-Plasma environment (Phosh on pmOS), I solved it by installing Breeze icon 
> theme and then creating a custom launcher.
>
> cp /usr/share/applications/org.kde.kasts.desktop ~/.local/share/applications/
>
> Then, modify the 'Exec' line in the launcher with the following:
>
> Exec=env QT_STYLE_OVERRIDE=Breeze kasts
>
> I'm recalling that by memory because I've re-flashed the phone in the 
> meanwhile, you could be required to tweak something. My source was [1] btw.
>
> Kind regards
>
> Marco
>
> [1] https://wiki.archlinux.org/title/Uniform_look_for_Qt_and_GTK_applications
>
>
> Il 28/06/23 23:16, Tzafrir Cohen ha scritto:
>
> Any news?
>
> I tried this package again. I updated the packaging for upstream 23.04.2
> (See a simple MR[1]). Right now it runs, but there are missing
> images on buttons, both on my desktop (sway) and on my mobian phone
> (where the flatpak runs OK).
>
> CMake also notes that the optional VNC playback backend is missing. How
> important is this?
>
> On my phone I had to install the following two packages (that I
> guessed from error messages)
>
> qml-module-org-kde-kirigami-addons-labs-components
> qml-module-qt-labs-qmlmodels
>
> And still I get the following output in my terminal:
> Database version 6
> kf.kirigami: Failed to find a Kirigami platform plugin
> qrc:/main.qml:416:5: QML ErrorListOverlay: Binding loop detected for property 
> "implicitHeight"
> qrc:/main.qml:416:5: QML ErrorListOverlay: Binding loop detected for property 
> "implicitHeight"
> qrc:/DesktopPlayerControls.qml:406:5: QML Dialog: Binding loop detected for 
> property "implicitHeight"
> qrc:/DesktopPlayerControls.qml:406:5: QML Dialog: Binding loop detected for 
> property "implicitHeight"
> file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ScrollablePage.qml:200:9:
>  QML MouseArea: Binding loop detected for property "width"
> file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ContextDrawer.qml:132:9:
>  QML ListView: Binding loop detected for property "topMargin"
> file:///usr/lib/aarch64-linux-gnu/qt5/qml/org/kde/kirigami.2/ContextDrawer.qml:132:9:
>  QML ListView: Binding loop detected for property "topMargin"
>
>
> [1] https://salsa.debian.org/ltworf-guest/kasts/-/merge_requests/2
>


-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Bug#1039714: fixed in gobject-introspection 1.76.1-3

[Thomas Uhle]

Hello Simon,

thanks for your support!

Cheers,

Thomas

Bug#1041614: Acknowledgement (unbootable system after installing dracut on a standard Debian installation)

[Patrick Schleizer]

This might be duplicate of:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029324

Bug#1029324: (no subject)

[Patrick Schleizer]

Thanks to Laszlo Gombos, this has been reported upstream.

Generic initrd does not work with encrypted root FS without further 
configuration


https://github.com/dracutdevs/dracut/issues/2437

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

[Martin-Éric Racine]

On Sat, Jul 22, 2023 at 4:57 PM Jonathan Wiltshire  wrote:
>
> Control: tag -1 confirmed
>
> On Sat, Jul 22, 2023 at 02:54:18PM +0300, Martin-Éric Racine wrote:
> > Since  posed
> > some reservations about the suitability of changes since 9.4.1-22,
> > here's the debdiff compared to that.
> >
> > It should also be noted that src:dhcpcd5 has been replaced by
> > src:dhcpcd in testing/unstable, which ships a newer upstream release,
> > thus the version of this bookworm update is not higher.
> >
> > Martin-Éric
>
> > diff -Nru dhcpcd5-9.4.1/debian/changelog dhcpcd5-9.4.1/debian/changelog
> > --- dhcpcd5-9.4.1/debian/changelog2023-05-24 15:03:22.0 +0300
> > +++ dhcpcd5-9.4.1/debian/changelog2023-07-13 07:56:52.0 +0300
> > @@ -1,3 +1,31 @@
> > +dhcpcd5 (9.4.1-24+deb12u1) bookworm; urgency=medium
>
> With the version as 9.4.1-24~deb12u1, please go ahead. The existing upload
> will be rejected.

Alright. Uploading again with corrected version. Thanks.

Matin-Éric

Bug#1041272: bookworm-pu: package transmission/3.00-2.1+deb12u1

[Jonathan Wiltshire]

Control: tag -1 confirmed

On Sun, Jul 16, 2023 at 07:29:31PM +0200, Sebastian Ramacher wrote:
> transmission in bookworm suffers from a memory leak in bookworm (see
> #1015003). This issue was fixed in unstable in the new upstream
> releaase.

Please go ahead.

Thanks,

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51
ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1

Bug#1041709: RFP: zig -- A general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.

[Nk]

Package: zig
Severity: wishlist

URL: https://ziglang.org/download/
License: MIT License (Expat)
Description:  A general-purpose programming language and toolchain for
maintaining robust, optimal, and reusable software.