Bug#1049954: Info received (Bug#1049954: Acknowledgement (libvips42: Can not create image in AVIF format with libvips))

[DINH Huy]

 Apologies disregard previous message, issue is still occuring 
On Thursday, August 31, 2023 at 12:27:05 PM GMT+9, Debian Bug Tracking 
System  wrote:  
 
 Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Laszlo Boszormenyi (GCS) 

If you wish to submit further information on this problem, please
send it to 1049...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

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

Bug#1042896: transition: armadillo

[Kumar Appaiah]

Dear Graham,

On Wed, Aug 30, 2023 at 07:35:46AM +, Graham Inggs wrote:
> 
> Please go ahead.

I just did a source-only upload. Will keep an eye on the buildds.

Thanks.

Kumar
-- 
Kumar Appaiah

Bug#1049954: Acknowledgement (libvips42: Can not create image in AVIF format with libvips)

[DINH Huy]

Fixed with 8.14.4 






On Thursday, August 17, 2023 at 06:48:08 PM GMT+9, Debian Bug Tracking System 
 wrote: 





Thank you for filing a new Bug report with Debian.

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

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
  d...@yahoo.com
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
Laszlo Boszormenyi (GCS) 

If you wish to submit further information on this problem, please
send it to 1049...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

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

Bug#1050892: kylin-nm-plugin: Initial release.

[liudun]

Package: kylin-nm-plugin
Version: 4.0.0.0-1
Severity: normal
X-Debbugs-Cc: liudun@qq.com


-- 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/8 CPU threads; PREEMPT)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), 
LANGUAGE=zh_CN:zh
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Vincent Lefevre]

On 2023-08-30 23:12:48 +0200, Francesco Poli wrote:
> On Wed, 30 Aug 2023 00:19:51 +0200 Vincent Lefevre wrote:
> > I don't see how this would separate the debug messages from the
> > error messages. I recall that I do *not* want the debug data on
> > the screen.
> 
> Sorry, I must have misunderstood your request.
> 
> So you want the debug output (which is currently sent to stderr)
> to be redirected to a file, while the normal output (which is sent to
> stdout) and any error messages (which are sent to stderr)
> should still be sent to the controlling terminal.
> Is this correct?

Yes. Here, the debug messages would have to be enabled until
the bug occurs again (which could take months), i.e. in normal
use of apt-listbugs. Having debugging messages on the screen
in these conditions would be too invasive.

Other applications like Mutt and Xterm have logging/debugging
features, and the debug messages are sent to some file.

> In the meanwhile, could you please tell me whether you have experienced
> this bug (#1019732) again, since the time when you originally reported
> it?

No, I have never seen this bug again.

> Or should I close the bug report as unreproducible?

Yes, perhaps.

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

Bug#1021292: Enabling branch protection on amd64 and arm64

[Guillem Jover]

Hi!

On Sun, 2023-08-27 at 12:51:53 +0200, Guillem Jover wrote:
> On Tue, 2023-06-27 at 16:09:40 +0100, Wookey wrote:
> > OK. We're all agreed on that then. Guillem can stick it in the next
> > dpkg upload.

So this happened, and Johannes reported that this seems to be breaking
cross-building. :(

The problem, which is in fact not new, but is made way more evident
now, is that the flags used are accepted only per arch, so when
passing for example CFLAGS (the host ones) into CC_FOR_BUILD, then
that one will not know about them and fail. (We have had this problem
up to now as we set flags per arch as some are broken in some arches,
but it being a problem depends on the host and build arches involved.)

I'm thinking about uploading later today a workaround to disable these
flags for now when cross-building. And then for the next release after
that support for _FOR_BUILD which can then take into account
these arch differences. I think some upstream code can already make
use of these, but this might need going over packaging or upstream
build systems to adapt/fix stuff. :/

And until that's done I don't think the workaround can be lifted,
and cross-compiling will generate different binaries than
non-cross-compiling. Another option would be to revert this change
until we can add it safely, but that would also be unfortunate.
OTOH, upstream code that uses stuff like CFLAGS with things like
CC_FOR_BUILD are already broken in regards cross-building, so perhaps
this can be an opportunity to flush them out?

Thanks,
Guillem

Bug#1050886: [pkg-gnupg-maint] Bug#1050886: Issues that need to be fixed in "yat2m" for transforming manuals to a man-page format

[NIIBE Yutaka]

Bjarni Ingi Gislason  wrote:

> Package: gpgrt-tools
> Version: 1.47-2
> Severity: normal
>
> Dear Maintainer,
>
>   The following are issues that yat2m needs to correct when producing
> man-page formatted manuals.
>
>   The example is from "gpg(1)".

Thank you for your bug report and good descriptions.

Last week, in upstream, I created a ticket for the problem of U+2010
vs. U+002D.

https://dev.gnupg.org/T6674

Since it's for yat2m, other problems should be handled in this ticket
too.
-- 

Bug#1050891: sccache - update for new addr2line.

[Peter Michael Green]

Package: sccache
Version: 0.5.4-11
Severity: serious
Tags: patch

I just updated addr2line to version 0.20.0, sccache builds succesfully
with the new version after bumping the dependency.

Debdiff attatched.
diff -Nru sccache-0.5.4/debian/changelog sccache-0.5.4/debian/changelog
--- sccache-0.5.4/debian/changelog  2023-08-24 08:23:51.0 +
+++ sccache-0.5.4/debian/changelog  2023-08-28 13:25:35.0 +
@@ -1,3 +1,10 @@
+sccache (0.5.4-11.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump dependency on object crate to 0.31.
+
+ -- nobody   Mon, 28 Aug 2023 13:25:35 +
+
 sccache (0.5.4-11) unstable; urgency=medium
 
   * drop patch 2018, obsoleted by Debian package changes
diff -Nru sccache-0.5.4/debian/control sccache-0.5.4/debian/control
--- sccache-0.5.4/debian/control2023-08-13 09:04:02.0 +
+++ sccache-0.5.4/debian/control2023-08-28 13:15:03.0 +
@@ -44,7 +44,7 @@
  librust-mime-0.3+default-dev,
  librust-num-cpus-1+default-dev,
  librust-number-prefix-0.4+default-dev,
- librust-object-0.30+default-dev,
+ librust-object-0.31+default-dev,
  librust-once-cell-1+default-dev (>= 1.17),
  librust-predicates-2+default-dev ,
  librust-rand-0.8+default-dev,
diff -Nru sccache-0.5.4/debian/patches/1007_update_object.patch 
sccache-0.5.4/debian/patches/1007_update_object.patch
--- sccache-0.5.4/debian/patches/1007_update_object.patch   1970-01-01 
00:00:00.0 +
+++ sccache-0.5.4/debian/patches/1007_update_object.patch   2023-08-28 
13:17:51.0 +
@@ -0,0 +1,7 @@
+Index: sccache-0.5.4/Cargo.toml
+===
+--- sccache-0.5.4.orig/Cargo.toml
 sccache-0.5.4/Cargo.toml
+@@ -92,1 +92,1 @@ zip = { version = "0.6", default-feature
+-object = "0.30"
++object = "0.31"
diff -Nru sccache-0.5.4/debian/patches/2001_no_dist-server.patch 
sccache-0.5.4/debian/patches/2001_no_dist-server.patch
--- sccache-0.5.4/debian/patches/2001_no_dist-server.patch  2023-08-24 
08:23:51.0 +
+++ sccache-0.5.4/debian/patches/2001_no_dist-server.patch  2023-08-28 
13:18:19.0 +
@@ -30,7 +30,7 @@
 -# dist-server only
  memmap2 = "0.6.2"
 -nix = { version = "0.26.2", optional = true }
- object = "0.30"
+ object = "0.31"
 -rouille = { version = "3.5", optional = true, default-features = false, 
features = [
 -  "ssl",
 -] }
diff -Nru sccache-0.5.4/debian/patches/2008_assert_cmd.patch 
sccache-0.5.4/debian/patches/2008_assert_cmd.patch
--- sccache-0.5.4/debian/patches/2008_assert_cmd.patch  2023-08-24 
08:23:51.0 +
+++ sccache-0.5.4/debian/patches/2008_assert_cmd.patch  2023-08-28 
13:18:39.0 +
@@ -8,7 +8,7 @@
 --- a/Cargo.toml
 +++ b/Cargo.toml
 @@ -100,7 +100,7 @@
- object = "0.30"
+ object = "0.31"
  
  [dev-dependencies]
 -assert_cmd = "2.0.10"
diff -Nru sccache-0.5.4/debian/patches/2017_memmap2.patch 
sccache-0.5.4/debian/patches/2017_memmap2.patch
--- sccache-0.5.4/debian/patches/2017_memmap2.patch 2023-08-24 
08:23:51.0 +
+++ sccache-0.5.4/debian/patches/2017_memmap2.patch 2023-08-28 
13:19:01.0 +
@@ -13,6 +13,6 @@
  
 -memmap2 = "0.6.2"
 +memmap2 = ">= 0.5.10, < 0.7"
- object = "0.30"
+ object = "0.31"
  
  [dev-dependencies]
diff -Nru sccache-0.5.4/debian/patches/series 
sccache-0.5.4/debian/patches/series
--- sccache-0.5.4/debian/patches/series 2023-08-18 15:13:19.0 +
+++ sccache-0.5.4/debian/patches/series 2023-08-28 13:16:36.0 +
@@ -1,5 +1,6 @@
 1001_optional_tests.patch
 1006_tests_network.patch
+1007_update_object.patch
 2001_no_dist-server.patch
 2002_no_opendal_backends.patch
 2003_no_windows.patch

Bug#1050890: Firefox LTO build breakage (and fixage)

[Daniel Richard G.]

Package: firefox
Version: 117.0-1

Hello,

I am working to get the Firefox build working with LTO on
unstable, i.e. with

DEB_BUILD_MAINT_OPTIONS=optimize=+lto

set in the environment. There are three main issues I encountered, which
are described and addressed below.


1. Webrender / glslopt crash

begin build log excerpt
[webrender 0.62.0] cargo:rerun-if-changed=res/brush_yuv_image.glsl
[webrender 0.62.0] cargo:rerun-if-changed=res/cs_conic_gradient.glsl
[webrender 0.62.0] cargo:rerun-if-changed=res/cs_clip_image.glsl
[webrender 0.62.0] Optimizing shader ShaderOptimizationInput { shader_name: 
"cs_line_decoration", config: "", gl_version: Gl }
error: failed to run custom build command for `webrender v0.62.0 
(/tmp/firefox-117.0/gfx/wr/webrender)`

Caused by:
  process didn't exit successfully: 
`/tmp/firefox-117.0/build-browser/release/build/webrender-503c370365efbdbf/build-script-build`
 (signal: 11, SIGSEGV: invalid memory reference)
end build log excerpt

Webrender is invoking "glslopt" here, and the latter has a history of
crashing in multithreaded scenarios. This has supposedly been fixed long
ago, but LTO seems to draw out some unresolved aspect of the issue. I
have filed a bug report on this with the upstream:

https://github.com/jamienicol/glsl-optimizer/issues/9

Here are some historical references, for background:

https://bugzilla.mozilla.org/show_bug.cgi?id=1637148
https://bugzilla.redhat.com/show_bug.cgi?id=1883904
https://github.com/servo/servo/issues/27039

Since this crash does not occur in a non-LTO build, my workaround is
simply to remove LTO flags from the Rust part of the build, by adding

perl -pi -e 's/-flto(=\w+)?//g; s/-ffat-lto-objects//g' \
build-browser/toolkit/library/rust/backend.mk

to the end of the "stamps/configure-$(PRODUCT)::" rule in debian/rules.


2. --param flag syntax

This one had me confused at first:

begin build log excerpt
make[3]: Entering directory 
'/tmp/firefox-117.0/build-browser/security/sandbox/linux'
security/sandbox/linux/libmozsandbox.so
rm -f libmozsandbox.so
/usr/bin/g++ -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-strong 
-Wdate-time -D_FORTIFY_SOURCE=2 -fno-sized-deallocation -fno-aligned-new -O2 
-ffile-prefix-map=/tmp/firefox-117.0=. -flto=auto -ffat-lto-objects 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -fno-exceptions -fPIC -fno-rtti 
-ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread 
-pipe -gdwarf-4 -freorder-blocks -O2 -fomit-frame-pointer -funwind-tables 
-shared -Wl,-z,defs -Wl,-h,libmozsandbox.so -o libmozsandbox.so safe_sprintf.o 
icu_utf.o trap.o syscall_wrappers.o Unified_cpp_sandbox_linux0.o 
Unified_cpp_sandbox_linux1.o Unified_cpp_sandbox_linux2.o 
Unified_cpp_sandbox_linux3.o   -lpthread -flto=auto -ffat-lto-objects 
-Wl,-z,relro -Wl,--as-needed -Wl,--reduce-memory-overheads -Wl,--stats 
-Wl,-z,pack-relative-relocs -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro 
-Wl,-z,nocopyreloc -Wl,-Bsymbolic-functions -Wl,--build-id=sha1 
-fstack-protector-strong '--param lto-partitions=1' 
-Wl,-rpath-link,/tmp/firefox-117.0/build-browser/dist/bin 
-Wl,-rpath-link,/usr/lib  -lplds4 -lplc4 -lnspr4 -lrt
g++: error: unrecognized command-line option '--param lto-partitions=1'; did 
you mean '--param lto-partitions='?
make[3]: *** [/tmp/firefox-117.0/config/rules.mk:526: libmozsandbox.so] Error 1
make[3]: Leaving directory 
'/tmp/firefox-117.0/build-browser/security/sandbox/linux'
make[2]: *** [/tmp/firefox-117.0/config/recurse.mk:72: 
security/sandbox/linux/target] Error 2
make[2]: Leaving directory '/tmp/firefox-117.0/build-browser'
make[1]: *** [/tmp/firefox-117.0/config/recurse.mk:34: compile] Error 2
make[1]: Leaving directory '/tmp/firefox-117.0/build-browser'
make: *** [/tmp/firefox-117.0/config/rules.mk:361: default] Error 2
end build log excerpt

Note that the flag being passed in is '--param lto-partitions=1', as a
single string containing a space. This is incorrect syntax; it needs to
be passed in as '--param' + 'lto-partitions=1'.

Fixed by this source patch:

begin patch
--- a/security/sandbox/linux/moz.build
+++ b/security/sandbox/linux/moz.build
@@ -117,7 +117,7 @@ if CONFIG["CC_TYPE"] in ("clang", "gcc")
 # forcing there to be only one partition.
 for f in CONFIG["OS_CXXFLAGS"]:
 if f.startswith("-flto") and CONFIG["CC_TYPE"] != "clang":
-LDFLAGS += ["--param lto-partitions=1"]
+LDFLAGS += ["--param", "lto-partitions=1"]
 
 DEFINES["NS_NO_XPCOM"] = True
 DisableStlWrapping()
end patch

This should probably be pushed upstream.


3. dh_dwz unknown opcode error

begin build log excerpt
make[2]: Entering directory '/tmp/firefox-117.0'
dh_dwz -X libxul
dwz: debian/firefox/usr/lib/firefox/libmozavcodec.so: Unknown DWARF DW_OP_0 
referenced from DIE at [325272]
dwz: debian/firefox/usr/lib/firefox/libmozavutil.so: Unknown 

Bug#1050872: release.debian.org: mips64el apparently relies on buster (oldoldstable) LTS?

[Simon McVittie]

On Wed, 30 Aug 2023 at 21:26:24 +0200, Aurelien Jarno wrote:
> On 2023-08-30 16:54, Simon McVittie wrote:
> > Luca Boccassi and I have been preparing stable and oldstable updates for
> > debootstrap so that the transition described in DEP-17 can continue.
> > Because DEP-17 involves changes to trixie/sid chroots' bootstrap
> > procedures, the updated debootstrap needs to be deployable to every
> > official buildd
>
> We have issues running [bookworm?] and bullseye kernels on
> some arm32 and mips*el buildds. The problem on arm has been solved by
> decommissioning the hardware or by hosts dying. We still have problems
> with a big part of the mips*el hosts.

Would it be possible to make an exception to the usual rule that buildds
get their debootstrap from (old)stable point releases, and manually
install a newer debootstrap (the version proposed for bullseye should
be suitable) onto the affected mips*el machines? I see that they already
have a newer-than-buster version of sbuild, possibly from the
buster-backports suite (which was discontinued when buster was handed over
to the LTS team).

I would prefer not to spend time preparing and testing a special buster
version of debootstrap and negotiating with the Debian 10 LTS team to get
it into buster/updates in the security archive; and it's not clear to
me that there is actually any apt repository that we could put it into
that would be accepted by the affected buildds, because buster is read-only
in the main Debian archive, and debian-security no longer has
dists/buster/updates/main/binary-mips64el at all?

(debian-security does have binary-all, and debootstrap is Architecture:
all, but I'm not sure how much that would help us with buster's apt, since
separate Packages files for binary-all seem to be a relatively new thing.)

> > From the point of view of the project having control over its own future,
> > I would have hoped that official Debian infrastructure would only be using
> > suites that are supported by Debian as a whole, rather than handing over
> > control and responsibility to the Debian-LTS subproject.

Sam Hartman pointed out on #debian-devel that this is worse than I thought,
because Debian-LTS doesn't cover mips*el. So as far as I can see, there is
no channel that gets security updates onto these buildds at all?

smcv

Bug#1043168: please include missing stub_flasher_32.json file

[Faidon Liambotis]

Control: block -1 by 868895

On Sun, Aug 06, 2023 at 10:12:30PM +0200, Piotr Ożarowski wrote:
> I had to add stub_flasher_32.json file manually from upstream repo in
> order to make my esphome (not yet in Debian, working on it) work with
> ESP32 WROOM 32 board.
> 
> Please include this file in the package. TIA

Not sure if that's entirely clear to you (apologies if it is): that file
isn't "just" a JSON data file that has been accidentally omitted from
the package. It's in fact a (JSON-wrapped) binary, compiled from C
sources bundled with the esptool source (and built with gcc, and a libc
and everything). So it's not a matter of including the file, but rather
rebuilding it.

A lot of work has happened in Debian and with upstream over the years to
build these binaries from unmodified sources, which culminated with
Debian shipping the stubs for the ESP8266, as well as for the ESP32
RISC-V variants (ESP32-C2, ESP32-C3, ESP32-C6, ESP32-H2). See the
4.5.1+dfsg-0.1 and 4.6.2+dfsg-0.1 changelog entries, Debian bug #948096,
as well as upstream issues #458, #499 and PRs #500, #501, #856, #858.

The reason that the same has not happened yet for the ESP32, ESP32-S2
and ESP32-S3 stubs is that we lack the toolchain for them in Debian
(gcc, binutils & picolibc). picolibc seems to have gained ESP32 support
upstream in 1.7.9, and Keith Packard is both upstream and the Debian
maintainer for it, so I suppose it won't be too hard to persuade him.
gcc and binutils are more complicated. #868895 provides some context,
and Jonathan McDowell, who maintains gcc-xtensa-lx106 and
binutils-xtensa-lx106, is aware of the need. I think there is more of a
backstory there, but he has the details.

Note that the ESP-IDF is thankfully *not* needed anymore (see upstream
#458).

As an alternative, we could probably ship these three stubs as built by
upstream separately in non-free, but I wasn't motivated enough, and I
was hoping we'd get the toolchain in Debian at some point. (I'm not even
the maintainer for esptool. If you're interested, I'm sure Milan will
appreciate the help!).

Finally, note that the stub isn't always necessary. --no-stub should
work for some, but not all, operations, sometimes at slower speeds.

Hope this helps!

Faidon

Bug#1050889: ITP: turbine-java -- A header compiler for Java

[Olek Wojnar]

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

* Package name: turbine-java
  Upstream Author : Google Inc. 
* URL : https://github.com/google/turbine
* License : Apache-2.0
  Programming Lang: Java
  Description : A header compiler for Java

 Used internally in the Bazel Build System.

This is required to package Bazel Java Tools which in turn is required to
package Bazel version 5.

Bug#1025708: bullseye-pu: package debootstrap/1.0.123+deb11u2

[Simon McVittie]

Control: tags -1 = bullseye d-i

[ Reason ]
The same changes proposed for bookworm in #1050868, but for bullseye.
Because official buildds that build trixie/sid are not yet all running
bookworm, we'll need this change in bullseye too.

I also included the changes that Luca previously proposed on this bug,
which are backports from bookworm's debootstrap:

- no longer including usrmerge and its dependencies in the installed
  system if usr-is-merged would be sufficient, saving ~ 50MB on a minbase
  image and effectively fixing a regression caused by making
  usrmerge|usr-is-merged transitively Essential in bookworm (#1025657)
- enabling merged-/usr on Hurd

These are technically a behaviour change for bullseye, but we're making
a larger behaviour change here already, and it aligns the behaviour
with what we have in bookworm. We could revert those if required, but
they're really small changes and seem desirable to me: in particular,
they make the whole merged-/usr code path into the same tested code
that's in trixie and proposed for bookworm.

[ Impact ]
If not accepted, trixie will continue to be stuck in a
mostly-but-not-entirely merged-/usr limbo, with the moratorium from #1035831
remaining in place (until all buildds can be upgraded to bookworm).

[ Tests ]
I did the same testing as for bookworm's #1050868, summarized on
.
As with #1050868, all differences between the output of a reference
version (from Debian 12.1) and the output of this version were expected
or ignorable. In addition to the ignorable differences noted in #1050868,
/etc/apt/apt.conf.d/01autoremove-kernels reflected the use of a bullseye
rather than bookworm kernel.

The autopkgtest passes, as in #1050868.

[ Risks ]
Same as in #1050868.

Additionally, I suppose someone could conceivably be relying on debootstrap
of bookworm|trixie|sid from a bullseye host installing a non-minimal system
with Perl and various libraries? But that seems tenuous.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable (and trixie)

[ Changes ]

The addition of EXCLUDE_DEPENDENCY in ./debootstrap, and the logic that
uses it (last hunk in ./functions and second hunk in scripts/debian-common),
are for #1025657.

setup_merged_usr() in ./functions now allows merged-/usr to continue on
Hurd too.

In copying setup_merged_usr() from trixie (via bookworm), it seems we've
accidentally enabled correct merged-/usr handling for loongarch64, which
wasn't exactly intentional but seems harmless!

scripts/trixie now exists (it's a symlink, the same as for every other
Debian suite).

The rest is the same as in bookworm's #1050868.

[ Other info ]
To keep bookworm's debootstrap "better" than bullseye's, this update
should not be accepted until after #1050868 is.

smcv
diffstat for debootstrap-1.0.123+deb11u1 debootstrap-1.0.123+deb11u2

 debian/.gitignore  |6 +
 debian/changelog   |   44 +
 debian/gbp.conf|3 
 debian/salsa-ci.yml|1 
 debian/tests/debian-testing|   27 +++
 debian/tests/fake/schroot-1.6.10-3 |2 
 debootstrap|4 +
 debootstrap.8  |5 -
 functions  |  125 +
 scripts/amber  |2 
 scripts/artful |2 
 scripts/bionic |2 
 scripts/cosmic |2 
 scripts/debian-common  |9 +-
 scripts/disco  |2 
 scripts/eoan   |2 
 scripts/focal  |2 
 scripts/gutsy  |2 
 scripts/hardy  |2 
 scripts/intrepid   |2 
 scripts/jaunty |2 
 scripts/karmic |2 
 scripts/lucid  |2 
 scripts/maverick   |2 
 scripts/natty  |2 
 scripts/oneiric|2 
 scripts/precise|2 
 scripts/quantal|2 
 scripts/raring |2 
 scripts/saucy  |2 
 scripts/trixie |   16 
 scripts/trusty |2 
 scripts/utopic |2 
 scripts/vivid  |2 
 scripts/wily   |2 
 scripts/xenial |2 
 scripts/yakkety|2 
 scripts/zesty  |2 
 38 files changed, 246 insertions(+), 50 deletions(-)

diff -Nru debootstrap-1.0.123+deb11u1/debian/changelog debootstrap-1.0.123+deb11u2/debian/changelog
--- 

Bug#1049325: Increasing severity

[Daniel Markstedt]

Control: severity -1 important
X-Debbugs-Cc: pkg-netatalk-de...@alioth-lists.debian.net

Dear Debian Release Team,

Please allow me to raise the severity for this ticket.
The patches address 9 public CVE advisories, and I think it would be beneficial 
to Bullseye users to have a patched package.

As mentioned before, the exact same patchset has been applied to 
oldoldstable-security with help from the Security Team (special thanks to 
Markus Koschany!)

Would it be possible to get feedback on the proposed release?

For reference, here are the relevant netatalk bug tickets that I know of.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025011
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036740
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043504

Thank you!

Daniel

Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1

[Simon McVittie]

Control: tags -1 + d-i

On Wed, 30 Aug 2023 at 16:27:12 +0100, Simon McVittie wrote:
> Part of the transition to merged-/usr, and more specifically, allowing
> us to stop shipping files in trixie whose physical path on disk does
> not match their path in the dpkg database due to directory aliasing.
> 
> This change needs to be in bookworm (and bullseye, and maybe buster)
> before that process can continue, because official buildds run debootstrap
> from stable (or older).
> 
> I also took the opportunity to backport changes that make the autopkgtests
> pass.

Sorry, I should have mentioned that this is a (significant) d-i component
and so will presumably need a d-i ack. I haven't explicitly cc'd
debian-boot on the basis that it's already the package's maintainer of
record (and the bug already appeared on the mailing list).

smcv

Bug#1050874: rsyslog: logging with short hostname instead of FQDN until first HUP

[Michael Biebl]

Am 30.08.23 um 18:20 schrieb Michael Prokop:

| /etc/rsyslog.d/graylog.conf:$PreserveFQDN on


I could reproduce the issue on unstable and forwarded it upstream.

Fortunately, $PreserveFQDN is off by default.


Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050888: alsa-utils: alsa-retore service does not restore state of a sound card plugged in through USB hub on boot

[Alexander Betaev]

Package: alsa-utils
Version: 1.2.9-1
Severity: normal
Tags: a11y
X-Debbugs-Cc: bet...@gmail.com

To fix this I have to run `sudo alsactl  restore` after each boot.

Additional notes:
- It does store state, so if I run `alsactl restore` it will restore volume
level set before reboot
- It works as expected with built-in sound card
- I did not test if it works or not when USB sound card is plugged directly
- It affects 1.2.8 version as well, I tested on both, 1.2.8 and 1.2.9


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

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

Versions of packages alsa-utils depends on:
ii  kmod  30+20221128-1
ii  libasound21.2.8-1+b1
ii  libatopology2 1.2.8-1+b1
ii  libc6 2.36-9+deb12u1
ii  libfftw3-single3  3.3.10-1
ii  libncursesw6  6.4-4
ii  libsamplerate00.2.2-3
ii  libtinfo6 6.4-4

alsa-utils recommends no packages.

Versions of packages alsa-utils suggests:
pn  dialog  

-- no debconf information

Bug#1050887: endlessh.service includes unhelpful instructions for listening on low ports

[Philip Hands]

Package: endlessh
Version: 1.1-5
Severity: normal

Dear Maintainer,

In `/lib/systemd/system/endlessh.service` there is this comment:

  ## If you want Endlessh to bind on ports < 1024
  ## 1) run:
  ## setcap 'cap_net_bind_service=+ep' /usr/local/bin/endlessh
  ## 2) uncomment following line
  #AmbientCapabilities=CAP_NET_BIND_SERVICE
  ## 3) comment following line
  PrivateUsers=true

which isn't very helpful, since the README instructs one to do the much 
preferable:

  systemctl enable --now endlessh@222.socket

BTW I started out this bug pointing out that /usr/local/bin is the wrong path,
and suggesting that socket activation would be much preferable, before noticing
that actually, that's already what the README's suggesting.

The comment should probably just be removed, or replaced with something like:

  # to run Endlessh on alternative ports, see: 
/usr/share/doc/endlessh/README.Debian

oh, actually, not quite ... I notice that the endlessh@.socket file appears to
be missing at present, so that would need to be added to the package first.

Cheers, Phil.

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Francesco Poli]

On Wed, 30 Aug 2023 00:19:51 +0200 Vincent Lefevre wrote:

> On 2023-08-29 22:45:40 +0200, Francesco Poli wrote:
> > On Sun, 2 Apr 2023 23:18:57 +0200 Vincent Lefevre wrote:
[...]
> > > But then, how can one get the error messages (which are still
> > > important) in the terminal?
> > 
> > Maybe the following could achieve this goal:
> > 
> >   DPkg::Pre-Install-Pkgs {"/usr/bin/bash -c '/usr/bin/apt-listbugs -d apt 
> > 2> >(/usr/bin/tee /tmp/apt-listbugs.err)'";};
> >   DPkg::Tools::Options::/usr/bin/bash "";
> >   DPkg::Tools::Options::/usr/bin/bash::Version "3";
> >   DPkg::Tools::Options::/usr/bin/bash::InfoFD "20";
> 
> I don't see how this would separate the debug messages from the
> error messages. I recall that I do *not* want the debug data on
> the screen.

Sorry, I must have misunderstood your request.

So you want the debug output (which is currently sent to stderr)
to be redirected to a file, while the normal output (which is sent to
stdout) and any error messages (which are sent to stderr)
should still be sent to the controlling terminal.
Is this correct?

I don't know how to achieve this, without modifying apt-listbugs.
Oh well, maybe I should modify apt-listbugs and add an option to
specify a file for the debug output...

I'll think about it.


In the meanwhile, could you please tell me whether you have experienced
this bug (#1019732) again, since the time when you originally reported
it?
Is it still reproducible on an up-to-date Debian testing/unstable box
(although sporadically)?
Or should I close the bug report as unreproducible?

Thanks for your time and patience!



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpzwUKtoExcH.pgp
Description: PGP signature

Bug#1050886: Issues that need to be fixed in "yat2m" for transforming manuals to a man-page format

[Bjarni Ingi Gislason]

Package: gpgrt-tools
Version: 1.47-2
Severity: normal

Dear Maintainer,

  The following are issues that yat2m needs to correct when producing
man-page formatted manuals.

  The example is from "gpg(1)".

-.-

Output from "mandoc -T lint gpg.1":

mandoc: gpg.1:152:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:646:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:1174:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:2210:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:2350:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:2747:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:2866:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:2965:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:3689:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:3737:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:3781:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:4076:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:4092:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:4183:2: WARNING: skipping paragraph macro: PP empty
mandoc: gpg.1:4184:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:4201:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:4304:1: WARNING: skipping paragraph macro: sp after PP
mandoc: gpg.1:4355:1: WARNING: skipping paragraph macro: sp after PP

-.-.

Input file is gpg.1

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

gpg.1:338:the numbers 1-3 for certificate check level (see
gpg.1:345:numbers 1-9 or "T" for 10 and above to indicate trust signature levels
gpg.1:2859:that not all values in the 1024-65011712 range are legal and if an

-.-.

Change three HYPHEN-MINUSES (code 0x055, 2D) to an em-dash (\(em),
if one is intended.  An en-dash is usually surrounded by a space,
while an em-dash is used without spaces.

gpg.1:2287:--- you cannot make an group that points to another group. When used

-.-.

Mark a full stop (.) and the exclamation mark (!) with "\&",
if it does not mean an end of a sentence.
This is a preventive action,
the paragraph could be reshaped, e.g., after changes.

When typing, one does not always notice when the line wraps after the
period.
There are too many examples of input lines in manual pages,
that end with an abbreviation point.

This marking is robust, and independent of the position on the line.

It corresponds to "\ " in TeX, and to "@:" in Texinfo.


331:checking the signature (e.g. a non supported algorithm).  Signatures
589:ownertrust values (e.g. in the file \(oq\fIotrust.txt\fR\(cq), you may 
re-create
867:once it has been send to the public (i.e. to a keyserver).  In that case
901:(i.e. to a keyserver).  In that case you better use \fBrevuid\fR.
1000:a subkey, once it has been send to the public (i.e. to a keyserver).  In
1043:that is no longer usable (e.g. revoked, or expired). Then, remove any
1446:(e.g. "jpg"), "%T" for the MIME type of the image (e.g. "image/jpeg"),
1448:viewed (e.g. "f"), "%V" for the calculated validity as a string (e.g.
2184:(i.e. run, but give a warning).
2396:known (e.g. keyserver, web key directory) and set.  For a standard
2562:e.g. "2016-08-17". (drop-subkey)
2604:e.g. "2016-08-17". (drop-sig)
2704:(i.e. \fB--with-colons\fR).  Note that the legacy format does not
2822:(e.g. \fB--clear-sign\fR or \fB--sign\fR).
2833:to consider (e.g. \fB--symmetric\fR).
3027:in C syntax (e.g. 0x0042) or as a comma separated list of flag names.
3045:(e.g. "20070924T154812").
3367:(cf. \fB--s2k-mode\fR).
3878:(i.e. inside the angle brackets).

-.-.

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

71:options \fB--with-colons\fR and \fB--status-fd\fR.  For certain
72:operations the option \fB--command-fd\fR may come handy too.  See
86:forcing their use via the \fB--cipher-algo\fR,
87:\fB--digest-algo\fR, \fB--cert-digest-algo\fR, or
88:\fB--compress-algo\fR options in GnuPG, it is possible to create a
104:the \fB--pgp6\fR, \fB--pgp7\fR, or \fB--pgp8\fR options. These
120:If you run into any problems, please add the option \fB--verbose\fR
131:.B  --version
136:.B  --help
144:.B  --warranty
148:.B  --dump-options
161:.B  --sign
164:Sign a message. This command may be combined with \fB--encrypt\fR
165:(to sign and encrypt a message), \fB--symmetric\fR (to sign and
166:symmetrically encrypt a message), or both \fB--encrypt\fR and
167:\fB--symmetric\fR (to sign and encrypt a message that can be
170:\fB--local-user\fR and \fB--default-key\fR options.
173:.B  --clear-sign
175:.B  --clearsign
181:explicitly using the \fB--local-user\fR and \fB--default-key\fR
186:.B  --detach-sign
192:.B  --encrypt
196:with \fB--sign\fR (to sign and encrypt a message),
197:\fB--symmetric\fR (to encrypt a message that can be decrypted using a
198:secret key or a passphrase), or \fB--sign\fR and
199:\fB--symmetric\fR together (for a signed message that 

Bug#1050833: release-notes: Bookworm renames network interfaces

[Rainer Dorsch]

Hi Justin,

thanks for the elaborate followup.

Just a few quick answers:

> Did the installer give you a 70-persistent-net.rules file?  It seems a
> bit of a pointless mechanism for hardware like yours...

I did not check on the test system (on which I installed bullseye and upgraded 
to bookworm) if there was one, I assume though that there was none, otherwise 
I would not expect the network device renaming after the upgrade.

On my production machine (initial installation is much older than bullseye), I 
found one, which still seems to work (since the system still has an wlan0 
interface). Judging after etckeeper, I commented the eth line during the 
upgrade from stretch to buster (I do not recall why though):

rd@home:~$ cat /etc/udev/rules.d/70-persistent-net.rules 
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# Unknown net device (/devices/soc0/soc/210.aips-bus/2188000.ethernet/net/
eth0) (fec)
# SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}
=="d0:63:b4:00:2b:ac", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", 
NAME="eth0"

# Unknown net device (/devices/soc0/soc/210.aips-bus/219.usdhc/
mmc_host/mmc0/mmc0:0001/mmc0:0001:1/net/wlan0) (brcmfmac)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}
=="b8:5a:f7:82:aa:c2", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", 
NAME="wlan0"
rd@home:~$ 

What I don't understand:
Before the upgrade from bullseye to bookworm, this machine still had the eth 
network interface names, even though the line in /etc/udev/rules.d/70-
persistent-net.rules was already commented out.

> >> Sure, *if* the change was in bookworm.  But if people didn't read
> >> the stretch and buster release notes, why would we expect a warning in
> >> the bookworm release notes to do any good?
> > 
> > I am also somewhat concerned that users don't read the release notes
> > carefully, break their systems. This information should probably be in a
> > more prominent place and clearly visible during the upgrade. I liked the
> > previous solution better that systems by default continue to use the old
> > naming scheme.
> Well, systems still do continue to use the old naming scheme, unless
> you change your apt sources to point at a new release!  And it's
> really much easier to change your configuration once to use the new
> names than to change your grub configuration and carry that around
> forever - or until linux-8.0.0 stops supporting that commandline
> parameter, long after you've forgotten you were using it...

I fully agree. But it would be much better if I would learn before the upgrade 
about this change and not get as a surprise a headless system which does not 
connect to the network anymore after the upgrade.

> Personally I have a .link file in /etc/systemd/network to make sure
> my machines use consistent names for their interfaces regardless of
> their hardware differences, and if you're administrating machines with
> different architectures that might well be what you'd want, too.

Many thanks for sharing this. For reference, I found an example here:

https://wiki.archlinux.org/title/Systemd-networkd#Renaming_an_interface

Thanks again
Rainer
-- 
Rainer Dorsch
http://bokomoko.de/

Bug#1050581: ruby-html-proofer: broken by ruby-nokogiri 1.15.4

[Lucas Nussbaum]

On 26/08/23 at 16:55 +0200, Lucas Nussbaum wrote:
> Source: ruby-html-proofer
> Version: 3.19.2-7
> Severity: serious
> 
> Hi,
> 
> I just uploaded ruby-nokogiri 1.15.4, and while testing reverse
> dependencies, noticed that it breaks this package.

It fails with

  1) Html test reports failures
 Failure/Error: expect(proofer.failed_tests.first).to match(/ERROR: That 
tag isn't allowed here/)
 
   expected "spec/html-proofer/fixtures/html/parse_failure.html: 1:33: 
ERROR: End tag 'a' isn't allowed here. Cur... open tags: html.\n\n^ (line 1)" to 
match /ERROR: That tag isn't allowed here/
   Diff:
   @@ -1,3 +1,5 @@
   -/ERROR: That tag isn't allowed here/
   +spec/html-proofer/fixtures/html/parse_failure.html: 1:33: ERROR: End 
tag 'a' isn't allowed here. Currently open tags: html.
   +
   +^ (line 1)
   
 # ./spec/html-proofer/html_spec.rb:132:in `block (2 levels) in '

  2) Html test allows div inside head
 Failure/Error: expect(proofer.failed_tests).to eq []
 
   expected: []
got: ["spec/html-proofer/fixtures/html/div_inside_head.html: 5:1: 
ERROR: End tag 'head' isn't allowed here. Currently open tags: html, 
body.\n\n^ (line 5)"]
 
   (compared using ==)
 
   Diff:
   @@ -1 +1,2 @@
   +spec/html-proofer/fixtures/html/div_inside_head.html: 5:1: ERROR: End 
tag 'head' isn't allowed here. Currently open tags: html, body.\n\n^ 
(line 5)
   
 # ./spec/html-proofer/html_spec.rb:51:in `block (2 levels) in '

  3) Html test allows an unmatched end tag
 Failure/Error: expect(proofer.failed_tests).to eq []
 
   expected: []
got: ["spec/html-proofer/fixtures/html/unmatched_end_tag.html: 3:1: 
ERROR: End tag 'div' isn't allowed here. Currently open tags: html, 
body.\n\n^ (line 3)"]
 
   (compared using ==)
 
   Diff:
   @@ -1 +1,2 @@
   +spec/html-proofer/fixtures/html/unmatched_end_tag.html: 3:1: ERROR: End 
tag 'div' isn't allowed here. Currently open tags: html, body.\n\n^ (line 
3)
   
 # ./spec/html-proofer/html_spec.rb:33:in `block (2 levels) in '

  4) Html test allows mismatch between opening and ending tag
 Failure/Error: expect(proofer.failed_tests).to eq []
 
   expected: []
got: 
["spec/html-proofer/fixtures/html/opening_and_ending_tag_mismatch.html: 3:31: 
ERROR: End tag 'p' isn'...ed here. Currently open tags: html, body, strong, 
p.\nlazy dog.\n   ^ (line 5)"]
 
   (compared using ==)
 
   Diff:
   @@ -1,2 +1,4 @@
   +spec/html-proofer/fixtures/html/opening_and_ending_tag_mismatch.html: 
3:31: ERROR: End tag 'p' isn't allowed here. Currently open tags: html, body, 
p, strong.\nThe quick brown fox\n  ^ 
(line 3)
   +spec/html-proofer/fixtures/html/opening_and_ending_tag_mismatch.html: 
5:8: ERROR: End tag 'strong' isn't allowed here. Currently open tags: html, 
body, strong, p.\nlazy dog.\n   ^ (line 5)
   
 # ./spec/html-proofer/html_spec.rb:45:in `block (2 levels) in '


Lucas

Bug#1050580: ruby-roxml: broken by ruby-nokogiri 1.15.4

[Lucas Nussbaum]

On 26/08/23 at 16:55 +0200, Lucas Nussbaum wrote:
> Source: ruby-roxml
> Version: 4.2.0-1
> Severity: serious
> 
> Hi,
> 
> I just uploaded ruby-nokogiri 1.15.4, and while testing reverse
> dependencies, noticed that it breaks this package.

It fails with:

Failures:

  1) ROXML::XMLTextRef when the namespaces are different with :namespace => '*' 
should collect all instances
 Failure/Error: xml.search(xpath, roxml_namespaces)

 Nokogiri::XML::XPath::SyntaxError:
   xmlXPathCompOpEval: function local-name not found
 # 
/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0/gems/nokogiri-1.15.4/lib/nokogiri/xml/searchable.rb:238:in
 `evaluate'
 # 
/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0/gems/nokogiri-1.15.4/lib/nokogiri/xml/searchable.rb:238:in
 `xpath_impl'
 # 
/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0/gems/nokogiri-1.15.4/lib/nokogiri/xml/searchable.rb:219:in
 `xpath_internal'
 # 
/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0/gems/nokogiri-1.15.4/lib/nokogiri/xml/searchable.rb:182:in
 `xpath'
 # 
/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0/gems/nokogiri-1.15.4/lib/nokogiri/xml/searchable.rb:61:in
 `search'
 # ./lib/roxml/xml/parsers/nokogiri.rb:58:in `search'
 # ./lib/roxml/xml/references.rb:121:in `nodes_in'
 # ./lib/roxml/xml/references.rb:220:in `fetch_value'
 # ./lib/roxml/xml/references.rb:36:in `value_in'
 # ./spec/xml/text_spec.rb:60:in `block (4 levels) in '

Finished in 0.3076 seconds (files took 0.91462 seconds to load)
213 examples, 1 failure, 19 pending


This is not known upstream (the last commit is from September 2021), and
the last issues are from 2016.

Lucas

Bug#1050521: Fix FTBFS patch

[Athos Ribeiro]

Control: tags -1 patch

A fix was proposed through salsa at
https://salsa.debian.org/debian/mdevctl/-/merge_requests/7

--
Athos Ribeiro

Bug#1050885: RM: ruby-roxml/4.2.0-1 (from testing)

[Lucas Nussbaum]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: ruby-ro...@packages.debian.org
Control: affects -1 + src:ruby-roxml

Please remove ruby-roxml from testing.
- it is broken in testing due to #1050580, which blocks the migration of
  ruby-nokogiri to testing
- it looks dead upstream (last commits in 09/2021; last issues in 2016)
- it has no reverse dependencies
- it has a low popcon (4 insts)

I think it's fine to keep it in unstable for now, in case someone has a
good reason to fix it.

Lucas

Bug#1050884: evdev.4: some remarks and an editorial patch for the manual

[Bjarni Ingi Gislason]

Package: xserver-xorg-input-evdev
Version: 1:2.10.6-2+b1
Severity: minor
Tags: patch

Dear Maintainer,

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

-.-

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -man -Z - "

instead of "nroff -man"

  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 evdev.4":

mandoc: evdev.4:19:10: STYLE: whitespace at end of input line
mandoc: evdev.4:26:4: STYLE: whitespace at end of input line
mandoc: evdev.4:40:2: WARNING: skipping paragraph macro: PP empty
mandoc: evdev.4:43:12: STYLE: whitespace at end of input line
mandoc: evdev.4:46:2: WARNING: skipping paragraph macro: PP empty
mandoc: evdev.4:52:21: STYLE: whitespace at end of input line
mandoc: evdev.4:67:74: STYLE: whitespace at end of input line
mandoc: evdev.4:84:2: WARNING: line scope broken: TP breaks TP

-.-.

Input file is evdev.4

Remove space characters at the end of lines.

Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".

19:.B evdev 
26:The 
43:through the 
52:The following driver 
67:Specifies the device through which the device can be accessed.  This will 

-.-.

Change '-' (\-) to '\(en' (en-dash) for a numeric range.
GNU gnulib has recently (2023-06-18) updated its
"build_aux/update-copyright" to recognize "\(en" in man pages.

evdev.4:282:8 bit. Either 1 value or pairs of values. Value range 0-32, 0 
disables a
evdev.4:292:1 8 bit value, allowed range 0-32, 0 disables the button.
evdev.4:301:1 8 bit value, allowed range 0-32, 0 disables the button.

-.-.

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

125:.BR EmulateWheel
149:.BR EmulateWheelButton
151:.BR EmulateWheelButton
242:.BI "Option \*qTypeName\*q \*q"type"\*q
271:.BI "Evdev Axis Calibration"
275:.BI "Evdev Axis Inversion"
278:.BI "Evdev Axes Swap"
281:.BI "Evdev Drag Lock Buttons"
285:.BI "Evdev Middle Button Emulation"
288:.BI "Evdev Middle Button Timeout"
291:.BI "Evdev Middle Button Button"
294:.BI "Evdev Wheel Emulation"
297:.BI "Evdev Wheel Emulation Axes"
300:.BI "Evdev Wheel Emulation Button"
303:.BI "Evdev Wheel Emulation Inertia"
306:.BI "Evdev Wheel Emulation Timeout"
309:.BI "Evdev Scrolling Distance"

-.-.

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

Search for two adjacent words is easier, when they belong to the same line,
and the same phrase.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.

N.B

  The number of lines affected is too large to be in the patch.


28:driver can serve as both a pointer and a keyboard input device. Multiple
38:per-device configuration. Devices configured in the
57:Sets the button mapping for this device. The mapping is a space-separated 
list
59:device (i.e. the first number is the mapping for button 1, etc.). The default
60:mapping is "1 2 3 ... 32". A mapping of 0 deactivates the button. Multiple
63:mapping of "3 2 1 0 0". Invalid mappings are ignored and the default mapping
64:is used. Buttons not specified in the user's mapping use the default mapping.
69:The mapping from device node to hardware is system-dependent. Property:
75:same time they move a mouse cursor. Button numbers occur in pairs,
77:number that is the target of the lock button. Property: "Evdev
83:\*qdrag locked\*q. Property: "Evdev Drag Lock Buttons".
89:pressing both buttons simultaneously.  Default: off. Property: "Evdev Middle
95:enabled.  Default: 50. Property: "Evdev Middle Button Timeout".
115:options.  Default: off. Property "Evdev Wheel Emulation".
124:settings. If the button is 0 and
126:is on, any motion of the device is converted into wheel events. Default: 4.
131:press/release events in wheel emulation mode.  Default: 10. Property: "Evdev
139:the name \*qinertia\*q is a misnomer. This option defines the distance
144:options. It does not enable inertia in the
150:must be pressed before wheel emulation is started. If the
153:is sent.  Default: 200. Property: "Evdev Wheel Emulation Timeout".

Bug#1050287: Confirmed bug, present in testing.

[Dread Quixadhal]

Just a quick note to confirm that the but in r8168-dkms, version 8.051.02-3, is 
present in the TESTING release of Debian, not just in unstable, and the 
workaround suggested by lol does work properly.

Bug#1050883: src:bornagain: fails to migrate to testing for too long: FTBFS nearly everywhere

[Paul Gevers]

Source: bornagain
Version: 1.19.0-4
Severity: serious
Control: close -1 21.0+ds3-2
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1042810

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:bornagain has been trying to migrate for 
31 days [2]. Hence, I am filing this bug. As reported in bug 1042810, 
the version in unstable fails to build from source on most architectures.


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



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050882: kicad-libraries metapackage version mixup

[antto]

Package: kicad-libraries
Version: 7.0.6+dfsg-1~bpo12+1
Severity: normal
X-Debbugs-Cc: an...@mail.bg

Dear Maintainer,

After upgrading to Debian12, the normal version of kicad is 6.x, after enabling
backports you can get kicad 7.x.
When you "Force Version" of the kicad-libraries metapackage in Synaptic to 7.x,
you would think that you'll get all the version 7 packages, but you don't, it
requires "(>=6.0.0~)" according to Synaptic, for kicad-footprints/kicad-
symbols/kicad-templates. it only correctly suggests kicad-packages3d v7.x.

And if you already had the stable kicad version, you will upgrade kicad itself
to v7 (from backports), the "libraries" metapackage will also get upgraded to
v7, but your actual library files (symbols, footprints, templates) will stay at
version 6 because they cover the requirements of the metapackage.
This seems wrong to me, the whole point of the "kicad-libraries" metapackage as
far as i know is to "group" the real packages that make up the libraries
(symbols, footprints, templates, 3D models).

I expected that the kicad-libraries metapackage actually upgrades the real
packages to the same version (or at least to some version above 7).


-- 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-11-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kicad-libraries depends on:
ii  kicad-footprints  7.0.6-1~bpo12+1
ii  kicad-symbols 7.0.6-1~bpo12+1
ii  kicad-templates   7.0.1-2~bpo12+1

kicad-libraries recommends no packages.

Versions of packages kicad-libraries suggests:
ii  kicad-packages3d  7.0.6-1~bpo12+1

-- no debconf information

Bug#1050872: release.debian.org: mips64el apparently relies on buster (oldoldstable) LTS?

[Aurelien Jarno]

Hi,

On 2023-08-30 16:54, Simon McVittie wrote:
> Package: release.debian.org
> Severity: normal
> X-Debbugs-Cc: debian-m...@lists.debian.org, bl...@debian.org, 
> debian-wb-t...@lists.debian.org
> 
> Luca Boccassi and I have been preparing stable and oldstable updates for
> debootstrap so that the transition described in DEP-17 can continue.
> Because DEP-17 involves changes to trixie/sid chroots' bootstrap
> procedures, the updated debootstrap needs to be deployable to every
> official buildd, and we've been told that (old)stable point releases
> are the preferred way to achieve that.
> 
> When Luca asked how many suites we needed this change in, we were hoping
> the answer would be stable only, and maybe oldstable (which is still
> in its 1 year of overlapping support from the security team and DDs
> in general).
> 
> However, if I understand correctly, Luca has been told that some official
> mips64el buildds are running mipsel user-space on mips64el hardware which
> only works with the buster kernel, and therefore those official buildds
> are still stuck on buster, meaning we also need to prepare a buster
> version of debootstrap and get it into Debian 10 LTS via buster-security.
> 
> Is this true?

This is correct. We have issues running buster and bullseye kernels on
some arm32 and mips*el buildds. The problem on arm has been solved by
decommissioning the hardware or by hosts dying. We still have problems
with a big part of the mips*el hosts.

> >From the point of view of the project having control over its own future,
> I would have hoped that official Debian infrastructure would only be using
> suites that are supported by Debian as a whole, rather than handing over
> control and responsibility to the Debian-LTS subproject.

That's also our wishes. Unfortunately real life makes things more
difficult, even on x86. And not speaking about buildds, some services
also do not run on newer debian releases.

> Also, from the point of view of continued development of testing/unstable,
> I would have hoped that packages in testing/unstable could safely
> assume that they will run on at least the kernel from stable (or maybe
> oldstable for a short time after a new stable release), following our
> usual "skipping a release is unsupported" rule. Obviously if the buildds
> are running on an oldoldstable kernel, any mips64el package that might
> be used at compile-time or for build-time tests will be unable to make
> that assumption.

Yes, this is definitely problem, and it has already been reported.

> Please could someone with knowledge of the buildds clarify the situation?
> 
> If our official buildds for a release architecture are unable to run on
> either the stable or oldstable kernel, I think that raises some important
> questions about suitability for inclusion in future releases.

I don't think this assumption should change, instead we should have a
way to upgrade those hosts. Probably we'll just decommission them
instead.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1050880: borgbackup: Mention required documentation for upgrading repositories for fixes for CVE-2023-36811

[Salvatore Bonaccorso]

Source: borgbackup
Version: 1.2.5-1
Severity: normal
X-Debbugs-Cc: car...@debian.org, t...@security.debian.org
Control: clone -1 -2
Control: reassign -2 release-notes

Hi

borgbackup/1.2.5-1 contained a fix for CVE-2023-36811. But
additionally to the package upgrades, users need to follow the upgrade
procedure as documented.

After an update of the package one is not really aware of it, so I
suggest a NEWS.Debian entry at least referring to the needed
documentation.

Would it be a good idea to document this as well in the release notes
for trixie, for users updating from bookworm to trixie? (Cloning this
bugreport accordingly to the release-notes).

Regards,
Salvatore

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, 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

Bug#1050879: ghc: FTBFS on hppa - virtual memory exhausted

[John David Anglin]

Source: ghc
Version: 9.4.6-1
Severity: normal
Tags: ftbfs

Dear Maintainer,

Build fails here:
"inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O -lffi 
-optl-pthread -Wall -this-unit-id Cabal-3.8.1.0 -hide-all-packages 
-package-env - -i -ilibraries/Cabal/Cabal/src 
-ilibraries/Cabal/Cabal/dist-install/build 
-Ilibraries/Cabal/Cabal/dist-install/build 
-ilibraries/Cabal/Cabal/dist-install/build/./autogen 
-Ilibraries/Cabal/Cabal/dist-install/build/./autogen -Ilibraries/Cabal/Cabal/.  
-optP-include 
-optPlibraries/Cabal/Cabal/dist-install/build/./autogen/cabal_macros.h 
-package-id Cabal-syntax-3.8.1.0 -package-id array-0.5.4.0 -package-id 
base-4.17.2.0 -package-id bytestring-0.11.5.1 -package-id containers-0.6.7 
-package-id deepseq-1.4.8.0 -package-id directory-1.3.7.1 -package-id 
filepath-1.4.2.2 -package-id mtl-2.2.2 -package-id parsec-3.1.16.1 -package-id 
pretty-1.1.3.6 -package-id process-1.6.17.0 -package-id text-2.0.2 -package-id 
time-1.12.2 -package-id transformers-0.5.6.2 -package-id unix-2.7.3 -Wall 
-fno-ignore-asserts -fwarn-tabs -fwarn-incomplete-uni-patterns 
-fwarn-incomplete-record-updates -Wcompat -Wnoncanonical-monad-instances 
-XHaskell2010   -no-user-package-db -rtsopts  -Wno-deprecated-flags
-Wnoncanonical-monad-instances  -outputdir 
libraries/Cabal/Cabal/dist-install/build -split-sections -dynamic-too -c 
libraries/Cabal/Cabal/src/Distribution/Simple/Build/Macros.hs -o 
libraries/Cabal/Cabal/dist-install/build/Distribution/Simple/Build/Macros.o 
-dyno 
libraries/Cabal/Cabal/dist-install/build/Distribution/Simple/Build/Macros.dyn_o
virtual memory exhausted: Cannot allocate memory
`gcc' failed in phase `C Compiler'. (Exit code: 1)

See:
https://buildd.debian.org/status/fetch.php?pkg=ghc=hppa=9.4.6-1=1693300415=0

This can be avoided by adding hppa to arches that need -optcggc-min-expand=10:
ifneq (,$(filter i386 hppa mips mipsel s390x, $(DEB_HOST_ARCH)))

Probably, all 32-bit arches need this option.

Regards,
Dave Anglin

-- System Information:
Debian Release: trixie/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.1.48+ (SMP w/4 CPU threads)
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)

-- no debconf information

Bug#1049903: petsc: misbuild with gcc-13

[Drew Parsons]

Source: petsc
Followup-For: Bug #1049903

Hi Steve, thanks for the bug report.

With patching, wouldn't it be simpler to just add -lstdc++ to
CXX_LINKER_FLAGS at configuration time (in debian/rules) rather than
hacking the upstream detection code?  As you say, hardcoding in the
upstream scripts doesn't really resolve the underlying problem.

Is there a reason why hacking CXX_LINKER_FLAGS in debian/rules doesn't
fix the build?

Drew

Bug#1050842: upgrade-reports: 6930p kde 11>12 it's okay

[Paul Gevers]

Control: tags -1 moreinfo

Hi,

Thanks for reporting issues you encounter.

On 30-08-2023 01:45, bw wrote:

- Did any packages fail to upgrade?
yeah, lots of obsoletes


I'm wondering what you expected here. Did you follow the instructions in 
the release notes, particular chapter 4.2.5 [1] and the there referenced 
chapter 4.8?


[1] 
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-upgrading.en.html#remove-obsolete-packages



- Were there any problems with the system after upgrading?
yeah lots of typical


Can you please be more specific? Without more details there's nothing 
actionable in this bug report.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices

[Vagrant Cascadian]

On 2023-08-30, Diederik de Haas wrote:
> On Wednesday, 30 August 2023 16:35:46 CEST Vagrant Cascadian wrote:
>> > I also recall seeing references to a `rk3568_ddr_1056MHz_v1.18.bin` file
>> > from https://github.com/rockchip-linux/rkbin/tree/master/bin/rk35. AFAIK
>> > that's only available as a BLOB? Is that file needed? And is it a problem
>> > if that's only available as a BLOB?
>> 
>> If upstream u-boot requires that to work it is... more complicated.
>> 
>> Looks like it does probably require it, based on the trustedfirmware
>> thread you linked to above.
>
> As mentioned above, AFAIK it's no different from rk3328/rk3399, but I'll ask.

If the rk3568*.bin is not actually required to build an upstream
arm-trusted-firmware, then it is not different!

If the rk3568*.bin is required to build an upstream
arm-trusted-firmware, then it is different!

The current arm-trusted-firmware and u-boot packages for rk3328 and
rk3399 do not require those or other blobs.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1050777: The surf autopkgtests are failing with webkitgtk 2.41

[Sebastien Bacher]

Le 30/08/2023 à 18:22, Alberto Garcia a écrit :

You are using Wayland I suppose? What if you run surf with
WAYLAND_DISPLAY=none, does it work then?

I'm having problems passing the autopkgtests locally with Wayland, but
already with WebKitGTK 2.40.x ...

Berto


No, in fact since that's an autopkgtest issue I wanted to have a simple 
setup to rule out desktop interactions and reproduced in a xfce session 
but a GNOME xorg session shows the same issue (in a wayland GNOME 
session surf errors out on x11 backend errors)


Cheers,
Sébastien

Bug#1049852: iwd: Fails to build binary packages again after successful build

[Jonas Smedegaard]

Control: tags -1 +upstream

Quoting Lucas Nussbaum (2023-08-16 10:26:37)
> This package fails to do build a binary-only build (not source) after a
> successful build (dpkg-buildpackage ; dpkg-buildpackage -b).

> > /bin/mkdir -p src/ && rst2man --strict --no-raw --no-generator 
> > --no-datestamp src/iwd.rst src/iwd.8
> > make[2]: *** No rule to make target 'src/iwd.debug.7', needed by 'all-am'.  
> > Stop.

The underlying issue is that the source file src/iwd.debug.rst is not
included in upstream tarball releases (it exists in upstream git repo).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices

[Diederik de Haas]

On Wednesday, 30 August 2023 16:35:46 CEST Vagrant Cascadian wrote:
> > You can add me as tester for Quartz64 Model A + B, but I don't have a
> > SoQuartz (or a base/carrier board).
> 
> Ok, if we ever get there... but I would not want to enable new boards
> that nobody has ever offered to test.

I can probably get one or more people to test, but I doubt I can get them 
listed as 'official testers'.

> >> > https://source.denx.de/u-boot/u-boot/-/tree/master/board/pine64/quartz6
> >> > 4_rk3566
> >> > 
> >> > Hereby the request to package them for Debian.
> 
> This is going to require quite a bit of work:
> 
> * package "rkbin" in non-free-firmware, if the license permits
> 
> * get appropriate rk35xx builds for TF-A (a.k.a. arm-trusted-firmware)
>   merged upstream, and then uploaded to the debian package (can possibly
>   cheat and instead only use the bl31.elf from rkbin).
> 
> * figure out the complicated dance between packages in "contrib"
>   depending on packages in "non-free-firmware" and not polluting
>   packages built from the same source in "main"

AFAIK, which isn't much in this case, it should be the same/similar to rk3328/
rk3399? They also use a file similar to `rk3568_ddr_1056MHz_v1.18.bin`, but 
then ofc tailored for their platform.
I'll ask the upstream maintainer/reviewer; this bug is probably not the place 
to document my learning experiences ;)

> > In some build instructions for u-boot that I've seen there was a reference
> > to an `bl31.elf` file from https://github.com/rockchip-linux/rkbin but I
> > guess that's what TF-A would provide (too), but then built from source?
> 
> Yes.

Ok, thanks.

> > I also recall seeing references to a `rk3568_ddr_1056MHz_v1.18.bin` file
> > from https://github.com/rockchip-linux/rkbin/tree/master/bin/rk35. AFAIK
> > that's only available as a BLOB? Is that file needed? And is it a problem
> > if that's only available as a BLOB?
> 
> If upstream u-boot requires that to work it is... more complicated.
> 
> Looks like it does probably require it, based on the trustedfirmware
> thread you linked to above.

As mentioned above, AFAIK it's no different from rk3328/rk3399, but I'll ask.

> Someone had briefly explored doing something similar for imx8*
> platforms, and it was a maze of complications... though the imx8* blobs
> turned out to not even be suitible for non-free-firmware, in the end, so
> it stalled out.
> 
> Because of all these complications, I have so far tried to stick to
> platforms which are strictly suitable for debian "main", although
> technically the requirements are a bit looser than they used to
> be... but I have little experience with or enthusiasm for the
> complexities such a setup would bring for the u-boot and
> arm-trusted-firmware packaging in Debian.

Let's for now assume that what I said was inaccurate.
Trying to make it work, assuming it's similar to rk3328, is going to be a 
challenge enough. If it'll require some 'hustling' between main/contrib/non-
free/non-free-firmware, I'll probably bail out.

Cheers,
  Diederik

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

Bug#1050878: Emacsen fails to install in Debian Chroot

[Jeffrey Walton]

Package: emacsen-common
Version: 3.0.5
Severity: Important
X-Debbugs-CC: r...@defaultvalue.org

I'm trying to install emacs-nox in an armel chroot. The install is
failing due to emacsen-common. Please see below.

This seems to be unique to armel chroot. I believe I have emacs-nox
installed for other chroots, like aarch64 and powerpc.

--

Setting up emacs-nox (1:28.2+1-7) ...
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
>>Error occurred processing /usr/share/emacs/site-lisp/debian-startup.el: File 
>>error (("Doing chmod" "Operation not supported" 
>>"/usr/share/emacs/site-lisp/debian-startup.elcSfHxT7"))
ERROR: install script from emacsen-common package failed
dpkg: error processing package emacs-nox (--configure):
 installed emacs-nox package post-installation script subprocess
returned error exit status 1
Setting up emacsen-common (3.0.5) ...
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
>>Error occurred processing /usr/share/emacs/site-lisp/debian-startup.el: File 
>>error (("Doing chmod" "Operation not supported" 
>>"/usr/share/emacs/site-lisp/debian-startup.elcSCq0OS"))
ERROR: install script from emacsen-common package failed
dpkg: error processing package emacsen-common (--configure):
 installed emacsen-common package post-installation script subprocess
returned error exit status 1
Errors were encountered while processing:
 emacs-nox
 emacsen-common
E: Sub-process /usr/bin/dpkg returned an error code (1)

--

$ apt-cache show emacsen-common
Package: emacsen-common
Version: 3.0.5
Installed-Size: 55
Maintainer: Rob Browning 
Architecture: all
Conflicts: emacs19, emacs20, emacs21-common, emacs22-common,
emacs23-common, emacs24-common, emacs25-common, xemacs21-support (<<
21.4.24-6~)
Description-en: Common facilities for all emacsen
 This package contains code that is needed by all the (x)emacs
 packages.  It will be automatically installed when needed.
Description-md5: 181ad2d7eef0b855d8f6d9bbf2373d8a
Tag: admin::configuring, devel::editor, implemented-in::lisp, role::app-data,
 role::plugin, role::program, suite::emacs, use::configuring,
 use::editing, works-with::text
Section: editors
Priority: optional
Filename: pool/main/e/emacsen-common/emacsen-common_3.0.5_all.deb
Size: 12296
MD5sum: a6eb6b8921f977740f03b2bcee477c95
SHA256: 74d972556adf85fbbfb0b3b10dcf16687547a9ef521c7c86f5cda454e11a60df

Bug#1050833: release-notes: Bookworm renames network interfaces

[Justin B Rye]

Rainer Dorsch wrote:
>> Are you saying that armhf machines still used one of the old interface
>> naming schemes (https://wiki.debian.org/NetworkInterfaceNames) on
>> bullseye, and hadn't yet switched over to "predictable" names?  
> 
> That is at least what I observed. I don't have insights, why armhf behaves 
> differently here.

Maybe I should go and ask on the armhf mailinglist - oh, except that
you've done that for me, thanks!  Let's see if anyone follows up.

The name "end0" doesn't match anything that the systemd documentation
told us the Predictable Names scheme would generate, so I should also
try to find out what's going on there... ah, looks as if it's "d for
devicetree":

https://github.com/systemd/systemd/commit/65c2ad985a8debdf6d7d11fee5b466f280260f4b#diff-74ecd06b7b5ba73ee97dbca326e44e3dddf6e8841bda2e073b06bdc4d8bd158dR682

You'd think they'd have learned by now that when you change this
stuff, you need to mention to sysadmins that you're planning to lock
them out of their servers next time they do a remote reboot, but no,
it isn't mentioned anywhere in

https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html

Except, wait, if this was caused by a change in systemd v254, doesn't
that make it a bookworm-to-trixie tripwire?  Perhaps I'm looking at
the wrong arbitrary unsignposted fluctuation in naming policy...

>> For
>> the architectures I know anything about, interface names like eth0
>> disappeared quite a while ago, with particular warnings in the stretch
>> and buster release notes:
>> 
>> https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.
>> html#new-interface-names
>> 
>> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en
>> .html#migrate-interface-names
> 
> If I understand the sentence
> 
> "This change does not apply to upgrades of jessie systems; the naming will 
> continue to be enforced by /etc/udev/rules.d/70-persistent-net.rules."
> 
> correctly, this means old systems stay with the old naming scheme by default, 
> newly installed systems use the new naming scheme.

It was true for jessie-to-stretch upgrades, but then buster lost the
machinery keeping /etc/udev/rules.d/70-persistent-net.rules updated
for changed network hardware, and the support has crumbled further
since then - it's not exactly clear how much is left.  Upstream
insists it isn't supported at all, but then again udev still seems to
allow those rules files...
 
> That is an excellent solution, since it does not break existing systems 
> during 
> the upgrade. 
>
> But what I observed in the armhf install is exactly the opposite. A running 
> bullseye system did not work anymore after the upgrade to bookworm due to the 
> network interface naming change. Since these are often headless systems, you 
> then rely on a serial interface for debugging.
> 
> As a side note:
> I have two amd64 kvm cloud hosted machines at different providers. I upgraded 
> one of them to bookworm, both use still uses eth0 as interface name. I see 
> the 
> they have both
> 
> net.ifnames=0
> 
> configured as kernel parameter in /etc/default/grub in the variable 
> GRUB_CMDLINE_LINUX.
> 
> Since I did not actively configure that, I assume that there are quite a few 
> machines out there with disabled Predictable Network Interface renaming 
> behavior.

I'm told (so it went into the bookworm release notes) that Xen only
recently switched from "eth0" to "enX0"; no idea what the situation is
like on KVM.

>> If the sequence of events has been different on armhf, that might need
>> a new entry in the "Complications and corner cases" section of the
>> wiki page.  The question is, how exactly did you come to be still
>> using "eth0" in a bullseye /etc/network/interfaces file?
> 
> I just run the installer for bullseye on a cubox-i/armhf machine. I do not 
> recall that I did anything special. I could repeat it, but maybe it is better 
> if somebody else does a test (just in case I missed something, it is likely 
> that I miss it again, though I don't know what that could be).

Did the installer give you a 70-persistent-net.rules file?  It seems a
bit of a pointless mechanism for hardware like yours...
 
>> Sure, *if* the change was in bookworm.  But if people didn't read
>> the stretch and buster release notes, why would we expect a warning in
>> the bookworm release notes to do any good? 
> 
> I am also somewhat concerned that users don't read the release notes 
> carefully, break their systems. This information should probably be in a more 
> prominent place and clearly visible during the upgrade. I liked the previous 
> solution better that systems by default continue to use the old naming scheme.

Well, systems still do continue to use the old naming scheme, unless
you change your apt sources to point at a new release!  And it's
really much easier to change your configuration once to use the new
names than to change your grub configuration and carry that around

Bug#1050877: devscripts: debchange v2.17.10 ignores EMAIL and DEBEMAIL env variables

[Peter Hyman]

Package: devscripts
Version: 2.23.4
Severity: normal

Dear Maintainer,

* What led up to the situation?
running debchange to create a changelog
$ debchange --version
This is debchange, from the Debian devscripts package, version 2.17.10
(same version as in devscripts package version 2.23.6)
* What exactly did you do (or not do) that was effective (or
ineffective)?
$ set |grep -e EMAIL -e FULLNAME
DEBEMAIL=p...@peterhyman.com
DEBFULLNAME='Peter Hyman'
EMAIL=p...@peterhyman.com
$ debchange --create --package foo -v 1.0
* What was the outcome of this action?
debchange warning: neither DEBEMAIL nor EMAIL environment variable is
set
debchange warning: building email address from username and mailname
debchange: Did you see those 2 warnings? Press RETURN to continue...
* What outcome did you expect instead?
No warning since environment variables properly set.


-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
Not present

-- 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/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages devscripts depends on:
ii dpkg-dev 1.21.22
ii fakeroot 1.31-1.2
ii file 1:5.44-3
ii gnupg 2.2.40-1.1
ii gpgv 2.2.40-1.1
ii libc6 2.36-9+deb12u1
ii libfile-dirlist-perl 0.05-3
ii libfile-homedir-perl 1.006-2
ii libfile-touch-perl 0.12-2
ii libfile-which-perl 1.27-2
ii libipc-run-perl 20220807.0-1
ii libmoo-perl 2.005005-1
ii libwww-perl 6.68-1
ii patchutils 0.4.2-1
ii perl 5.36.0-7
ii python3 3.11.2-1+b1
ii sensible-utils 0.0.17+nmu1
ii wdiff 1.2.2-5

Versions of packages devscripts recommends:
ii apt 2.6.1
ii curl 7.88.1-10+deb12u1
ii dctrl-tools 2.24-3+b1
ii debian-keyring 2022.12.24
ii dput 1.1.3
ii equivs 2.3.1
ii libdistro-info-perl 1.5
ii libdpkg-perl 1.21.22
ii libencode-locale-perl 1.05-3
ii libgit-wrapper-perl 0.048-2
ii libgitlab-api-v4-perl 0.26-3
ii liblist-compare-perl 0.55-2
ii liblwp-protocol-https-perl 6.10-1
ii libsoap-lite-perl 1.27-3
ii libstring-shellquote-perl 1.04-3
ii libtry-tiny-perl 0.31-2
ii liburi-perl 5.17-1
ii licensecheck 3.3.5-1
ii lintian 2.116.3
ii man-db 2.11.2-2
ii patch 2.7.6-7
ii pristine-tar 1.50
ii python3-apt 2.6.0
ii python3-debian 0.1.49
ii python3-magic 2:0.4.26-3
ii python3-requests 2.28.1+dfsg-1
ii python3-unidiff 0.7.3-1
ii python3-xdg 0.28-2
ii strace 6.1-0.1
ii unzip 6.0-28
ii wget 1.21.3-1+b2
ii xz-utils 5.4.1-0.2

Versions of packages devscripts suggests:
pn adequate 
pn at 
pn autopkgtest 
pn bls-standalone 
ii bsd-mailx [mailx] 8.1.2-0.20220412cvs-1
ii build-essential 12.9
pn check-all-the-things 
pn cvs-buildpackage 
ii debhelper 13.11.4
pn diffoscope 
pn disorderfs 
pn dose-extra 
pn duck 
pn elpa-devscripts 
pn faketime 
pn gnuplot 
pn how-can-i-help 
ii libauthen-sasl-perl 2.1600-3
pn libdbd-pg-perl 
ii libfile-desktopentry-perl 0.22-3
pn libterm-size-perl 
ii libtimedate-perl 2.3300-2
pn libyaml-syck-perl 
pn mmdebstrap 
pn mozilla-devscripts 
pn mutt 
ii openssh-client [ssh-client] 1:9.2p1-2
pn piuparts 
pn postgresql-client 
pn pristine-lfs 
pn quilt 
pn ratt 
pn reprotest 
pn svn-buildpackage 
pn w3m 

-- no debconf information

--
Peter Hyman

Bug#1050875: feh: Escape hyphens in manpage

[Peter Samuelson]

Package: feh
Version: 3.10-1
Severity: minor
Tags: patch upstream

feh.1, like many manpages, fails to escape the `-` character in option
descriptions.  In modern groff, this causes each one to be rendered as
U+2010 "HYPHEN" instead of the ASCII character (U+002D "HYPHEN-MINUS").
The net effect:

- Certain old fonts (I still use the classic X11 'fixed' for my xterms)
  don't have the U+2010 glyph

- Searching in "less" (by typing, e.g., "/--auto " does not work.

Fortunately the manpage formats every instance of every option with the
"Cm" macro, so this is easy to fix without also hitting all the
legitimate English-language hyphens that are not options (as in the
phrase "English-language").  Here is a simple patch.

Thanks,
Peter
--- feh-3.10/man/Makefile~  2023-04-06 09:19:59.0 -0500
+++ feh-3.10/man/Makefile   2023-08-30 11:35:13.557736015 -0500
@@ -15,6 +15,7 @@
-e 's/\$$MAN_INOTIFY\$$/${MAN_INOTIFY}/' \
-e 's/\$$MAN_MAGIC\$$/${MAN_MAGIC}/' \
-e 's/\$$MAN_XINERAMA\$$/${MAN_XINERAMA}/' \
+   -e '/^\(\.Cm\|\.[A-Z][a-z].* Cm\)/{ s/ -\([^ ]\)/ \\-\1/g; s/\(\\-[^ 
\-]*\)-/\1\\-/g; s/\(\\-[^ \-]*\)-/\1\\-/g }' \
< ${@:.1=.pre} > $@
 
 clean:

Bug#1050777: The surf autopkgtests are failing with webkitgtk 2.41

[Alberto Garcia]

On Wed, Aug 30, 2023 at 10:14:15AM +0200, Sebastien Bacher wrote:
> The MiniBrowser works fine and render webpages as expected
> 
> Starting surf with WEBKIT_DISABLE_COMPOSITING_MODE=1 set also
> workaround the issue and gives working rendering

You are using Wayland I suppose? What if you run surf with
WAYLAND_DISPLAY=none, does it work then?

I'm having problems passing the autopkgtests locally with Wayland, but
already with WebKitGTK 2.40.x ...

Berto

Bug#1050874: rsyslog: logging with short hostname instead of FQDN until first HUP

[Michael Prokop]

Package: rsyslog
Version: 8.2302.0-1
Severity: important

Hi,

it looks like the rsyslog version in bookworm is affected by
something related to https://github.com/rsyslog/rsyslog/issues/4975,
quoting from there:

| After rsyslog start, local hostname is short name only. It changes to FQDN 
after the first HUP.

I observed this and can reproduce it on several bookworm systems:

| synpromika@example01 ~ % hostname
| example01
| synpromika@example01 ~ % hostname --fqdn
| example01.in.example.com
| synpromika@example01 ~ % logger mika-was-here
| synpromika@example01 ~ % sudo tail /var/log/syslog
| [...]
| 2023-08-30T16:54:12.429181+02:00 example01 synpromika: mika-was-here

Only when sending HUP to rsyslog it behaves as expected:

| synpromika@example01 ~ % sudo pkill -HUP rsyslogd
| synpromika@example01 ~ % logger mika-was-here2
| synpromika@example01 ~ % sudo tail /var/log/syslog
| []
| 2023-08-30T16:54:12.429181+02:00 example01 synpromika: mika-was-here
| 2023-08-30T16:54:20.194863+02:00 example01.in.example.com rsyslogd: [origin 
software="rsyslogd" swVersion="8.2302.0" x-pid="5181" 
x-info="https://www.rsyslog.com;] rsyslogd was HUPed
| 2023-08-30T16:54:23.708793+02:00 example01.in.example.com synpromika: 
mika-was-here2

FTR, the systems have the default /etc/rsyslog.conf:

| synpromika@example01 ~ % grep -v '^#' /etc/rsyslog.conf | sed '/^$/d'
| module(load="imuxsock") # provides support for local system logging
| module(load="imklog")   # provides kernel logging support
| $FileOwner root
| $FileGroup adm
| $FileCreateMode 0640
| $DirCreateMode 0755
| $Umask 0022
| $WorkDirectory /var/spool/rsyslog
| $IncludeConfig /etc/rsyslog.d/*.conf
| *.*;auth,authpriv.none  -/var/log/syslog
| auth,authpriv.* /var/log/auth.log
| cron.*  -/var/log/cron.log
| kern.*  -/var/log/kern.log
| mail.*  -/var/log/mail.log
| user.*  -/var/log/user.log
| *.emerg :omusrmsg:*

And /etc/rsyslog.d/postfix.conf as shipped by the postfix package,
plus a custom /etc/rsyslog.d/graylog.conf for central logging are
also in place:

| synpromika@example01 ~ % grep -v '^#' /etc/rsyslog.d/*.conf | sed '/^$/d'
| /etc/rsyslog.d/graylog.conf:$PreserveFQDN on
| /etc/rsyslog.d/graylog.conf:*.* 
@logging01.in.example.com:5140;RSYSLOG_SyslogProtocol23Format
| /etc/rsyslog.d/postfix.conf:$AddUnixListenSocket /var/spool/postfix/dev/log

This is especially tricky, as rsyslog's logrotate configuration also
sends the HUP:

| synpromika@example01 ~ % cat /etc/logrotate.d/rsyslog
| /var/log/syslog
| /var/log/mail.log
| /var/log/kern.log
| /var/log/auth.log
| /var/log/user.log
| /var/log/cron.log
| {
| rotate 4
| weekly
| missingok
| notifempty
| compress
| delaycompress
| sharedscripts
| postrotate
| /usr/lib/rsyslog/rsyslog-rotate
| endscript
| }
| synpromika@example01 ~ % cat /usr/lib/rsyslog/rsyslog-rotate
| #!/bin/sh
|
| if [ -d /run/systemd/system ]; then
| systemctl kill -s HUP rsyslog.service
| fi

So this causes systems to log with short hostname after fresh system
start (and also after every single rsyslog service restart), but
once logrotate kicks in it switches to logging with FQDN / full
hostname instead:

| 2023-08-18T00:00:08.311354+02:00 testsuitecrm01 systemd[1]: Reloaded 
apache2.service - The Apache HTTP Server.
| 2023-08-18T00:00:08.331611+02:00 testsuitecrm01.in.example.com systemd[1]: 
rsyslog.service: Sent signal SIGHUP to main process 550 (rsyslogd) on client 
request.
| 2023-08-18T00:00:08.332430+02:00 testsuitecrm01.in.example.com rsyslogd: 
[origin software="rsyslogd" swVersion="8.2302.0" x-pid="550" 
x-info="https://www.rsyslog.com;] rsyslogd was HUPed
| 2023-08-18T00:00:08.553169+02:00 testsuitecrm01.in.example.com systemd[1]: 
logrotate.service: Deactivated successfully.
| 2023-08-18T00:00:08.553771+02:00 testsuitecrm01.in.example.com systemd[1]: 
Finished logrotate.service - Rotate log files.

Especially for folks with log monitoring/alerting based on FQDNs
(e.g. with central loggging or logwatch) this might result in
*quite* some unexpected behavior.

The issue feels similar to what was reported and supposedly fixed
with https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022128 and
https://github.com/rsyslog/rsyslog/pull/5004, though it looks like
to be incomplete yet?

regards
-mika-

Bug#1034744: Bug#1024695: also debian-ispell

[Agustin Martin]

Control: tags 1034744 + wontfix

El jue, 3 ago 2023 a las 19:58, Dan Jacobson () escribió:
> Hi 1034744 team: please see #1024695 as a bug that could get fixed at
> the same time...

#1034744 is not a  bug but a design choice inside  emacsen-common
policy, please look at the thread mentioned at #1034744.
emacsen-commmon must be configured before packages shipping elisp
snippets are configured, but if packages contain more than those
snippets they may be installed without Emacs ittself (emacsen-common
does not pull Emacs or XEmacs and is a very small package whose
installation without {X}Emacs causes no problemas at all). This
(wishlist) report is left open just to be a reference, but I am
tagging it wontfix to make more clear things about it.

Regards,

-- 
Agustin

Bug#1037346: Issue confirmation, desaster recovery

[Bastian Dombret]

Hi,

Confirming this issue also arises when coming from 3.2.6-2+deb11u2. 
After conducting an update from a fully updated Bullseye to Bookworm, no 
more mails were in any user's account, and new mailboxes were created 
for users when logging in.


All accounts are many years old. As I had awareness of potential upgrade 
issues, I even tried to run reconstruct -G -V max before conducting the 
upgrade, which though did not help to prevent the desaster.


Suggestion:
Bullseye (oldstable) should be updated to a Cyrus version 3.2.10+, as 
this is the only confirmed way as per Cyrus' upgrade documentation to 
avoid these issues when moving to v3.6.1 as contained in Bookworm.

https://www.cyrusimap.org/3.6/imap/download/upgrade.html#versions-to-upgrade-from

I currently have no awareness of what else an admin could do to prevent 
this from happening when updating directly from 3.2.6-2+deb11u2 
(Standard Bullseye). The most promising hints I've read in other threads 
is to run the reconstruct with additional parameters (reconstruct -f -G 
-I -V max), whereas I would suggest anyone not to test this without a 
very solid backup.


For others for whom it's too late and who are here for solutions, here 
is what I did to recover after the desaster:


1) su'ed to user cyrus
2) Downloaded rescue script by @larsimmisch from here and saved to local 
folder:

https://gist.github.com/larsimmisch/f0c02977ffc9a9c72781716eaa3d7334
3) In the same folder:
git clone https://github.com/larsimmisch/python_cyrus python_cyrus
4) python3 ./cyrreconstruct.py -a  

Step 4 will only work if the mailbox has already been created again 
(what happens automatically - as an empty one - when a user logs in). If 
the mailbox isn't present yet, use cyradm and

cm user.
to create it before running the cyrreconstruct.py script.

Special thanks to @larsimmisch for saving my life, and to the package 
maintainers for acting swiftly for preventing others from this nightmare.


Best,
Bastian

Bug#1050873: dh-php: Provide dh-sequence-php

[Bas Couwenberg]

Source: dh-php
Version: 5.2
Severity: normal
Tags: patch

Dear Maintainer,

The dh-php package should provide dh-sequence-php to automatically enable the 
sequence instead of using dh --with php.

The attached patch adds dh-sequence-php to the Provides of dh-php.

Kind Regards,

Bas
diff -Nru dh-php-5.2/debian/changelog dh-php-5.2+nmu1/debian/changelog
--- dh-php-5.2/debian/changelog 2023-01-05 14:20:19.0 +0100
+++ dh-php-5.2+nmu1/debian/changelog2023-08-30 17:52:10.0 +0200
@@ -1,3 +1,10 @@
+dh-php (5.2+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Provide dh-sequence-php.
+
+ -- Bas Couwenberg   Wed, 30 Aug 2023 17:52:10 +0200
+
 dh-php (5.2) unstable; urgency=medium
 
   * Bump version for source-only build
diff -Nru dh-php-5.2/debian/control dh-php-5.2+nmu1/debian/control
--- dh-php-5.2/debian/control   2023-01-05 14:20:19.0 +0100
+++ dh-php-5.2+nmu1/debian/control  2023-08-30 17:51:48.0 +0200
@@ -16,6 +16,7 @@
  perl,
  xml2,
  ${misc:Depends}
+Provides: dh-sequence-php
 Description: debhelper add-on to handle PHP PECL extensions
  dh-php provides a debhelper sequence add-on named 'php' and the
  dh_php command.

Bug#1050872: release.debian.org: mips64el apparently relies on buster (oldoldstable) LTS?

[Simon McVittie]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: debian-m...@lists.debian.org, bl...@debian.org, 
debian-wb-t...@lists.debian.org

Luca Boccassi and I have been preparing stable and oldstable updates for
debootstrap so that the transition described in DEP-17 can continue.
Because DEP-17 involves changes to trixie/sid chroots' bootstrap
procedures, the updated debootstrap needs to be deployable to every
official buildd, and we've been told that (old)stable point releases
are the preferred way to achieve that.

When Luca asked how many suites we needed this change in, we were hoping
the answer would be stable only, and maybe oldstable (which is still
in its 1 year of overlapping support from the security team and DDs
in general).

However, if I understand correctly, Luca has been told that some official
mips64el buildds are running mipsel user-space on mips64el hardware which
only works with the buster kernel, and therefore those official buildds
are still stuck on buster, meaning we also need to prepare a buster
version of debootstrap and get it into Debian 10 LTS via buster-security.

Is this true?

>From the point of view of the project having control over its own future,
I would have hoped that official Debian infrastructure would only be using
suites that are supported by Debian as a whole, rather than handing over
control and responsibility to the Debian-LTS subproject.

Also, from the point of view of continued development of testing/unstable,
I would have hoped that packages in testing/unstable could safely
assume that they will run on at least the kernel from stable (or maybe
oldstable for a short time after a new stable release), following our
usual "skipping a release is unsupported" rule. Obviously if the buildds
are running on an oldoldstable kernel, any mips64el package that might
be used at compile-time or for build-time tests will be unable to make
that assumption.

Please could someone with knowledge of the buildds clarify the situation?

If our official buildds for a release architecture are unable to run on
either the stable or oldstable kernel, I think that raises some important
questions about suitability for inclusion in future releases.

Thanks,
smcv

Bug#1050837: [Pkg-utopia-maintainers] Bug#1050837: udisks2.service does not start, timeout after ~3 minutes

[Jens Arnold]

Dear maintainer

See https://github.com/storaged-project/udisks/issues/1152 



While the problem might be related to this upstream bug, the case is 
certainly not identical. I've installed nvme-cli and tested some commands.



root@jupiter:~# nvme sanitize-log -H /dev/nvme0
NVMe status: Invalid Log Page: The log page indicated is invalid(0x4109)


Apparently my SSD (Sandisk, see below) doesn't support the sanitize log. 
But that's the same with VMware NMVe...



root@jupiter:~# nvme id-ctrl -H /dev/nvme0
NVME Identify Controller:
vid   : 0x15b7
ssvid : 0x15b7
sn: 190567800208
mn: SanDisk Extreme Pro 500GB
fr: 101200RL
rab   : 4
ieee  : 001b44
cmic  : 0
  [3:3] : 0 ANA not supported
  [2:2] : 0 PCI
  [1:1] : 0 Single Controller
  [0:0] : 0 Single Port

mdts  : 7
cntlid: 0x2017
ver   : 0x10300
rtd3r : 0x7a120
rtd3e : 0xf4240
oaes  : 0x200
  [31:31] : 0   Discovery Log Change Notice Not Supported
  [27:27] : 0   Zone Descriptor Changed Notices Not Supported
  [15:15] : 0   Normal NSS Shutdown Event Not Supported
  [14:14] : 0	Endurance Group Event Aggregate Log Page Change Notice 
Not Supported

  [13:13] : 0   LBA Status Information Notices Not Supported
  [12:12] : 0	Predictable Latency Event Aggregate Log Change Notices 
Not Supported

  [11:11] : 0   Asymmetric Namespace Access Change Notices Not Supported
  [9:9] : 0x1   Firmware Activation Notices Supported
  [8:8] : 0 Namespace Attribute Changed Event Not Supported

ctratt: 0x2
  [19:19] : 0   Flexible Data Placement Not Supported
  [15:15] : 0   Extended LBA Formats Not Supported
  [14:14] : 0   Delete NVM Set Not Supported
  [13:13] : 0   Delete Endurance Group Not Supported
  [12:12] : 0   Variable Capacity Management Not Supported
  [11:11] : 0   Fixed Capacity Management Not Supported
  [10:10] : 0   Multi Domain Subsystem Not Supported
  [9:9] : 0 UUID List Not Supported
  [8:8] : 0 SQ Associations Not Supported
  [7:7] : 0 Namespace Granularity Not Supported
  [6:6] : 0 Traffic Based Keep Alive Not Supported
  [5:5] : 0 Predictable Latency Mode Not Supported
  [4:4] : 0 Endurance Groups Not Supported
  [3:3] : 0 Read Recovery Levels Not Supported
  [2:2] : 0 NVM Sets Not Supported
  [1:1] : 0x1   Non-Operational Power State Permissive Supported
  [0:0] : 0 128-bit Host Identifier Not Supported

rrls  : 0
cntrltype : 0
  [7:2] : 0 Reserved
  [1:0] : 0 Controller type not reported
fguid : ----
crdt1 : 0
crdt2 : 0
crdt3 : 0
nvmsr : 0
  [1:1] : 0 NVM subsystem Not part of an Enclosure
  [0:0] : 0 NVM subsystem Not part of a Storage Device

vwci  : 0
  [7:7] : 0 VPD Write Cycles Remaining field is Not valid.
  [6:0] : 0 VPD Write Cycles Remaining

mec   : 0
  [1:1] : 0 NVM subsystem Not contains a Management Endpoint on a PCIe port
  [0:0] : 0	NVM subsystem Not contains a Management Endpoint on an 
SMBus/I2C port


oacs  : 0x17
  [10:10] : 0   Lockdown Command and Feature Not Supported
  [9:9] : 0 Get LBA Status Capability Not Supported
  [8:8] : 0 Doorbell Buffer Config Not Supported
  [7:7] : 0 Virtualization Management Not Supported
  [6:6] : 0 NVMe-MI Send and Receive Not Supported
  [5:5] : 0 Directives Not Supported
  [4:4] : 0x1   Device Self-test Supported
  [3:3] : 0 NS Management and Attachment Not Supported
  [2:2] : 0x1   FW Commit and Download Supported
  [1:1] : 0x1   Format NVM Supported
  [0:0] : 0x1   Security Send and Receive Supported

acl   : 4
aerl  : 7
frmw  : 0x14
  [5:5] : 0 Multiple FW or Boot Update Detection Not Supported
  [4:4] : 0x1   Firmware Activate Without Reset Supported
  [3:1] : 0x2   Number of Firmware Slots
  [0:0] : 0 Firmware Slot 1 Read/Write

lpa   : 0x2
  [6:6] : 0 Telemetry Log Data Area 4 Not Supported
  [5:5] : 0	LID 0x0, Scope of each command in LID 0x5, 0x12, 0x13 Not 
Supported

  [4:4] : 0 Persistent Event log Not Supported
  [3:3] : 0 Telemetry host/controller initiated log page Not Supported
  [2:2] : 0 Extended data for Get Log Page Not Supported
  [1:1] : 0x1   Command Effects Log Page Supported
  [0:0] : 0 SMART/Health Log Page per NS Not Supported

elpe  : 255
  [7:0] : 255 (0's based)   Error Log Page Entries (ELPE)

npss  : 4
  [7:0] : 4 (0's based) Number of Power States Support (NPSS)

avscc : 0x1
  [0:0] : 0x1   Admin Vendor Specific Commands uses NVMe Format

apsta : 0x1
  [0:0] : 0x1   Autonomous Power State Transitions Supported

wctemp: 353
 [15:0] : 80 °C (353 K) Warning Composite Temperature Threshold (WCTEMP)

cctemp: 358
 [15:0] : 85 °C (358 K) Critical Composite Temperature Threshold (CCTEMP)

mtfa  : 50
hmpre : 0
hmmin : 0
tnvmcap   : 500.107.862.016
[127:0] : 500.107.862.016

Bug#1050871: udev: no systemd and LUKS+btrfs makes incomplete database

[Frederic]

Package: udev
Version: 1:252.6-1mx23+1
Severity: normal
X-Debbugs-Cc: frederic.lamo...@gmail.com

Dear Maintainer,

Using MX23 (Debian bookworm based), having a LUKS partition formatted with 
btrfs.

When booting without systemd, some applications that query disks via 
lsblk/libudev do not work
because the report is missing info about FS type and UUID.

It can be seen using command "udevadm info /dev/dm-0" 

Booting with systemd, command reports:

P: /devices/virtual/block/dm-0
M: dm-0
R: 0
U: block
T: disk
D: b 253:0
N: dm-0
L: 0
S: 
disk/by-id/dm-uuid-CRYPT-LUKS2-504a3ccbe6f64593b4f959d010c2d22b-luks-504a3ccb-e6f6-4593-b4f9-59d0
10c2d22b
S: disk/by-label/root
S: mapper/luks-504a3ccb-e6f6-4593-b4f9-59d010c2d22b
S: disk/by-id/dm-name-luks-504a3ccb-e6f6-4593-b4f9-59d010c2d22b
S: disk/by-uuid/d7340ebe-8fd2-457d-92b9-bc7b19c81c47
Q: 2
E: DEVPATH=/devices/virtual/block/dm-0
E: DEVNAME=/dev/dm-0
E: DEVTYPE=disk
E: DISKSEQ=2
E: MAJOR=253
E: MINOR=0
E: SUBSYSTEM=block
E: USEC_INITIALIZED=7446182
E: DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES=1
E: DM_UDEV_RULES_VSN=2
E: DM_ACTIVATION=1
E: DM_NAME=luks-504a3ccb-e6f6-4593-b4f9-59d010c2d22b
E: 
DM_UUID=CRYPT-LUKS2-504a3ccbe6f64593b4f959d010c2d22b-luks-504a3ccb-e6f6-4593-b4f9-59d010c2d22b
E: DM_SUSPENDED=0
E: ID_FS_LABEL=root
E: ID_FS_LABEL_ENC=root
E: ID_FS_UUID=d7340ebe-8fd2-457d-92b9-bc7b19c81c47
E: ID_FS_UUID_ENC=d7340ebe-8fd2-457d-92b9-bc7b19c81c47
E: ID_FS_UUID_SUB=41ae936c-0d24-4aab-9aec-e9ec214961c1
E: ID_FS_UUID_SUB_ENC=41ae936c-0d24-4aab-9aec-e9ec214961c1
E: ID_FS_TYPE=btrfs
E: ID_FS_USAGE=filesystem
E: ID_BTRFS_READY=1
E: SYSTEMD_READY=1
E: 
DEVLINKS=/dev/disk/by-id/dm-uuid-CRYPT-LUKS2-504a3ccbe6f64593b4f959d010c2d22b-luks-504a3ccb-e6f6-
4593-b4f9-59d010c2d22b /dev/disk/by-label/root 
/dev/mapper/luks-504a3ccb-e6f6-4593-b4f9-59d010c2d22b
 /dev/disk/by-id/dm-name-luks-504a3ccb-e6f6-4593-b4f9-59d010c2d22b 
/dev/disk/by-uuid/d7340ebe-8fd2-4
57d-92b9-bc7b19c81c47
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:


Booting without systemd, the command reports:

P: /devices/virtual/block/dm-0
M: dm-0
R: 0
U: block
T: disk
D: b 253:0
N: dm-0
L: 0
Q: 2
E: DEVPATH=/devices/virtual/block/dm-0
E: DEVNAME=/dev/dm-0
E: DEVTYPE=disk
E: DISKSEQ=2
E: MAJOR=253
E: MINOR=0
E: SUBSYSTEM=block
E: USEC_INITIALIZED=8727241
E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
E: DM_UDEV_DISABLE_DISK_RULES_FLAG=1
E: DM_UDEV_DISABLE_OTHER_RULES_FLAG=1
E: SYSTEMD_READY=0
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:


-- Package-specific info:

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

Kernel: Linux 6.4.0-2mx-ahs-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages udev depends on:
ii  adduser  3.134
ii  libacl1  2.3.1-3
ii  libblkid12.38.1-5+b1
ii  libc62.36-9+deb12u1
ii  libcap2  1:2.66-4
ii  libkmod2 30+20221128-1
ii  libselinux1  3.4-1+b6
ii  libudev1 1:252.6-1mx23+1

udev recommends no packages.

udev suggests no packages.

Versions of packages udev is related to:
ii  systemd  1:252.6-1mx23+1

-- Configuration Files:
/etc/init.d/udev changed:
PATH="/sbin:/bin"
NAME="systemd-udevd"
DAEMON="/lib/systemd/systemd-udevd"
DESC="hotplug events dispatcher"
PIDFILE="/run/udev.pid"
CTRLFILE="/run/udev/control"
OMITDIR="/run/sendsigs.omit.d"
TSPLASH="/live/bin/tell-tsplash"
DO_TSPLASH=
[ -x "$TSPLASH" -a -d /live/config/tsplash ] && DO_TSPLASH=true
unmount_devpts() {
  if mountpoint -q /dev/pts/; then
umount -n -l /dev/pts/
  fi
  if mountpoint -q /dev/shm/; then
umount -n -l /dev/shm/
  fi
}
mount_devtmpfs() {
  if grep -E -q "^[^[:space:]]+ /dev devtmpfs" /proc/mounts; then
mount -n -o remount,nosuid,size=$tmpfs_size,mode=0755 -t devtmpfs devtmpfs 
/dev
return
  fi
  if ! mount -n -o nosuid,size=$tmpfs_size,mode=0755 -t devtmpfs devtmpfs /dev; 
then
log_failure_msg "udev requires devtmpfs support, not started"
log_end_msg 1
  fi
  return 0
}
create_dev_makedev() {
  if [ -e /sbin/MAKEDEV ]; then
ln -sf /sbin/MAKEDEV /dev/MAKEDEV
  else
ln -sf /bin/true /dev/MAKEDEV
  fi
}
my_tty() {
  [ -x /bin/readlink ] || return 0
  [ -e /proc/self/fd/0 ] || return 0
  readlink --silent /proc/self/fd/0 || true
}
warn_if_interactive() {
  if [ "$RUNLEVEL" = "S" -a "$PREVLEVEL" = "N" ]; then
return
  fi
  TTY=$(my_tty)
  if [ -z "$TTY" -o "$TTY" = "/dev/console" -o "$TTY" = "/dev/null" ]; then
return
  fi
  printf "\n\n\nIt has been detected that the command\n\n\t$0 $*\n\n"
  printf "has been run from an interactive shell.\n"
  printf "It will probably not do what you expect, so this script will 

Bug#1036437: please provide a simple example to reproduce the bug

[Georges Khaznadar]

Dear Alexis,

the bug about "import Gumshoe from "./gumshoe-patched.js";" is not due
to furo: it is due to the package python-sympy-doc.

When I modify the file /usr/share/doc/python-sympy-doc/html/index.html,
and replace 
 
by

then, Firefox accepts to import Gumshoe seamlessly.

By the way, the file python-sympy-doc also misses a file version.json;
this file should be accessed properly only when one opens the file via a
http: service, like in:
firefox http://localhost/doc/python-sympy-doc/html/index.html

Please can you check whether the bug you reported still exists when
furo.js is invoked with the type "module"?

Please be kind enough to send me another way to reproduce the bug you
saw, taking in account that 
 
is the right way to use furo.js.

Best regards.   Georges

Alexis Murzeau a écrit :
> On 31/05/2023 16:43, georgesk wrote:
> > Dear Alexis,
> > 
> > I packaged furo for debian in order to be able to keep maintaining the
> > package sympy, which depends on it.
> > 
> > However sympy's documentation is rather big. Creating a minimal sphinx
> > tree with sphinx-quickstart is not enough to trigger the bug which you
> > are reporting.
> > 
> > Please can you share a minimal example which would trigger this bug, so
> > I can include it in furo package's test scripts, and prevent future
> > regressions after this bug's fix?
> > 
> > Thank you in advance.   Georges.
> > 
> 
> 
> Hi,
> 
> You can reproduce it by:
> - Installing python3-sympy-doc package
> - Open firefox and browse to 
> file:///usr/share/doc/python-sympy-doc/html/index.html
> - Check the Firefox' console, it will show "Uncaught SyntaxError: import 
> declarations may only appear at top level of a module"
>   for furo.js
> - furo.js contains "import Gumshoe from "./gumshoe-patched.js";" line which 
> means it was not minified (which is what upstream does).
> 
> The impact is just that dark/light theme and search bar won't work.
> 
> I've checked if this would be possible to do the minification, but that seems 
> to require many node packages and not all of them
> are available or up to date in Debian.
> 
> So maybe that's too much work to just get dark/light theme and search bar... 
> (most of the theme, mostly css, is still working fine anyway)
> 
> -- 
> Alexis Murzeau
> PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|
> 




-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1050869: skrooge: /tmp/skrooge-* files accumulate

[bw]

Package: skrooge
Version: 2.29.0-1
Severity: normal

Dear Maintainer,

Thanks for the new version, upgraded yesterday to bookworm.  I use the app a 
lot for 
several years now.  Very reliable, so minor annoyance is acceptable.

Every time skrooge is opened it creates and leaves behind 16 random tmp files, 
these will 
build up pretty quickly, but I can deal with it.

I checked quickly on the web, did not browse the source code very much, but 
found no 
issue reported https://github.com/flathub/org.kde.skrooge/issues.  It does not 
seem to be 
a problem with my data file, happens with or without an open file.

$ ls -d /tmp/skrooge* && ls -d /tmp/skrooge* | wc -l
...
/tmp/skrooge-FLmLeH  /tmp/skrooge-KRgBkN  /tmp/skrooge-rmUVys  
/tmp/skrooge-zssohZ
/tmp/skrooge-fntqIZ  /tmp/skrooge-KuFuam  /tmp/skrooge-RtTREt  
/tmp/skrooge-ZswTYO
/tmp/skrooge-fVRVtR  /tmp/skrooge-LHuBTM  /tmp/skrooge-rWGCXf  
/tmp/skrooge-zuWWwY
96

Thanks, keep up the great work!
bw

-- 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-11-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages skrooge depends on:
ii  kinit 5.103.0-1
ii  kio   5.103.0-1
ii  libc6 2.36-9+deb12u1
ii  libgcc-s1 12.2.0-14
ii  libgrantlee-templates55.2.0-4
ii  libkf5archive55.103.0-1
ii  libkf5completion5 5.103.0-1
ii  libkf5configcore5 5.103.0-2
ii  libkf5configgui5  5.103.0-2
ii  libkf5configwidgets5  5.103.0-1
ii  libkf5coreaddons5 5.103.0-1
ii  libkf5dbusaddons5 5.103.0-1
ii  libkf5i18n5   5.103.0-1
ii  libkf5iconthemes5 5.103.0-1
ii  libkf5kiocore55.103.0-1
ii  libkf5kiofilewidgets5 5.103.0-1
ii  libkf5newstuff5   5.103.0-1
ii  libkf5newstuffcore5   5.103.0-1
ii  libkf5notifications5  5.103.0-1
ii  libkf5notifyconfig5   5.103.0-1
ii  libkf5parts5  5.103.0-1
ii  libkf5service-bin 5.103.0-1
ii  libkf5service55.103.0-1
ii  libkf5textwidgets55.103.0-1
ii  libkf5wallet-bin  5.103.0-1
ii  libkf5wallet5 5.103.0-1
ii  libkf5widgetsaddons5  5.103.0-1
ii  libkf5xmlgui5 5.103.0-1
ii  libofx7   1:0.10.9-1
ii  libqca-qt5-2  2.3.5-2
ii  libqca-qt5-2-plugins  2.3.5-2
ii  libqt5concurrent5 5.15.8+dfsg-11
ii  libqt5core5a [qtbase-abi-5-15-8]  5.15.8+dfsg-11
ii  libqt5dbus5   5.15.8+dfsg-11
ii  libqt5gui55.15.8+dfsg-11
ii  libqt5network55.15.8+dfsg-11
ii  libqt5printsupport5   5.15.8+dfsg-11
ii  libqt5qml55.15.8+dfsg-3
ii  libqt5quick5  5.15.8+dfsg-3
ii  libqt5quickwidgets5   5.15.8+dfsg-3
ii  libqt5script5 5.15.8+dfsg-2
ii  libqt5sql55.15.8+dfsg-11
ii  libqt5sql5-sqlite 5.15.8+dfsg-11
ii  libqt5svg55.15.8-3
ii  libqt5webkit5 5.212.0~alpha4-30
ii  libqt5widgets55.15.8+dfsg-11
ii  libqt5xml55.15.8+dfsg-11
ii  libqt5xmlpatterns55.15.8-2
ii  libsqlcipher0 3.4.1-2+b1
ii  libstdc++612.2.0-14
ii  skrooge-common2.29.0-1

Versions of packages skrooge recommends:
ii  poppler-utils  22.12.0-2+b1

Versions of packages skrooge suggests:
pn  aqbanking-tools  

-- no debconf information

Bug#1050186: [Pkg-nginx-maintainers] Bug#1050186: Bug#1050186: Bug#1050186: libnginx-mod-http-lua: depends on obsolete pcre3 library

[Jérémy Lal]

Le mer. 30 août 2023 à 12:18, Jan Mojzis  a écrit :

> Hi,
> I've uploaded experimental version with the PCRE2 patch included
> 1:0.10.25-2~exp1 to the experimental.


Cool !
It seems three modules need to be patched:
https://github.com/swananan/lua-resty-core/tree/support_pcre2
https://github.com/swananan/lua-nginx-module/commits/support_pcre2
https://github.com/swananan/stream-lua-nginx-module/commits/support_pcre2

Jérémy

Bug#1050868: bookworm-pu: package debootstrap/1.0.128+nmu2+deb12u1

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: debootst...@packages.debian.org, hel...@subdivi.de
Control: affects -1 + src:debootstrap
Control: block 1025708 by -1

[ Reason ]
Part of the transition to merged-/usr, and more specifically, allowing
us to stop shipping files in trixie whose physical path on disk does
not match their path in the dpkg database due to directory aliasing.

This change needs to be in bookworm (and bullseye, and maybe buster)
before that process can continue, because official buildds run debootstrap
from stable (or older).

I also took the opportunity to backport changes that make the autopkgtests
pass.

[ Impact ]
If not accepted, trixie will continue to be stuck in a
mostly-but-not-entirely merged-/usr limbo, with the moratorium from #1035831
remaining in place.

[ Tests ]
More details of testing on
.
A prerelease (differing only in the changelog) is available from
.

I used this version of debootstrap to install sid, trixie, bookworm,
bullseye and buster on amd64, in the default, minbase and buildd
variants, and compared the results to corresponding pairs of reference
chroots. The reference chroots were installed with the Debian 12.1
version of debootstrap, explicitly forcing --[no-]merged-usr.

All default and minbase chroots continue to be merged-/usr by default.

The sid and trixie buildd chroots are now merged-/usr by default (this
is an intentional change).

The bookworm, bullseye and buster buildd chroots continue to be
non-merged-/usr by default.

When I used diffoscope to compare each chroot tarball to the reference
chroot tarball with the same suite, variant and (non-)merged-/usr status,
all differences were expected or ignorable:

- /lib32, /libx32 symlinks not created (an intentional change)
- empty /usr/lib32/, /usr/libx32/ not created (an intentional change)
- non-reproducible timestamps (ignorable)
- non-reproducible machine ID (ignorable)
- non-reproducible ldconfig cache (ignorable)
- non-reproducible systemd-journald message catalog in buster (ignorable)
- non-reproducible /var/log (ignorable)

Philip Hands built a d-i mini.iso with the proposed version, and it seems
to have installed GNOME successfully under openQA.

There is also an autopkgtest which bootstraps Debian testing and
inspects various subtleties of the resulting chroot. It now passes under
autopkgtest-virt-qemu (which previously failed), autopkgtest-virt-lxc
and Salsa-CI.

The changes were backported from testing/unstable, where there were
no regression reports that I've seen. The last of them migrated to
trixie today.

[ Risks ]
Packages that were relying on sid and trixie buildds to be non-merged-/usr
could break or misbehave. This is intentional: only merged-/usr is
supported, and this change is mainly to get the buildds into a supported
state for the future.

Packages that were relying on the existence of compat symlinks for
non-default multilib flavours (for example /lib32 and /libx32 on amd64)
will no longer find that they exist in all cases. I would say this is only
a minor risk. In principle it could be mitigated by creating the compat
symlinks unconditionally when bootstrapping older suites (<= bookworm)
but if that's wanted, we should do it in unstable first.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable (and trixie)

[ Changes ]

* debootstrap:
  - Add --merged-usr to the --help (#1031828). Minor documentation fix,
no functional change.

* functions:
  - can_usrmerge_symlink(), merge_usr_entry(), merge_usr():
Helmut Grohne's implementation of a new bootstrap protocol for
merged-/usr, which unpacks Essential packages and then does the
equivalent of the usrmerge package's convert-usrmerge before
proceeding, instead of creating the compat symlinks and then unpacking
Essential packages over the top of them.
This is a prerequisite for lifting the moratorium imposed by #1035831.
(#1049898)

Unlike the old setup_merged_usr(), this does not create compat symlinks
for non-default multilib libQUAL directories unless they are mentioned
in an Essential package: the practical effect is that on for example
amd64, the /lib32 and /libx32 symlinks are no longer created (but /lib64
still is, because libc6:amd64 needs it).

  - In merge_usr() (new) and setup_merged_usr() (no longer used by
debootstrap, but some versions of mmdebstrap rely on it),
apply the /usr merge to trixie, sid and future buildd chroots.
Technical Committee consensus is that we want this, and it is a
prerequisite for lifting the moratorium imposed by #1035831.

* scripts/*:
  

Bug#1034258: opensc: with the new opensc version in Debian testing/sid I am unable to use the new Italian CNS

[Davide Prina]

Bastian Germann ha scritto:

> I see you have opened an upstream bug. It seems to have worked for you but I 
> have not got if 
> compiled version 0.23.0 or a git version after that. Maybe we can identify 
> the issue.

sorry for my late response.

In short: the bug I have make is incorrect because the driver for my CNS
has been inserted in OpenSC after the stable release and so is not in the
actual OpenSC Debian package.

For the previous OpenSC version I have made a .deb package using the
patched github source.
Using the github OpenSC version in develop I'm unable to make a working
.deb package: all seem to function correctly, I can start authentication
phase, insert the PIN, but after I get some errors and the authentication
don't work.

I was able to compile le OpenSC version in develop using the instruction
on OpenSC site and using my CNS to authenticate correctly, but I will
prefer to have a .deb package.

I would like to find and solve the problem before to reply to that bug...
but I'm unable to understand where is the problem. 

Ciao
Davide

--
La mia privacy non è affar tuo
https://noyb.eu/it
- You do not have my permission to use this email to train an AI -
If you use this to train your AI than you accept to distribute under AGPL
license >= 3.0 all the model trained, all the source you have used to
training your model and all the source of the program that use that model

Bug#1050867: support for YAML aliases broken by switch from safe_yaml to Psych

[Sébastien Villemot]

Le mercredi 30 août 2023 à 16:05 +0200, Sébastien Villemot a écrit :
> In jekyll 4.3.1+dfsg-1, a Debian-specific patch was added to rely on Psych
> instead of safe_yaml for reading YAML files (see #1026427).
> 
> This change has however broken support for YAML aliases.
[…]
> An easy fix is to explicitly allow aliases. I attach a patch (which must be
> applied on top of 0016-Drop-usage-of-safe_yaml.patch).

Note that my patch has been incorporated into the upstream pull request
on which the Debian-specific patch is based:

  https://github.com/jekyll/jekyll/pull/8772#issuecomment-1699309363

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices

[Vagrant Cascadian]

On 2023-08-30, Diederik de Haas wrote:
> On Wednesday, 30 August 2023 00:41:18 CEST you wrote:
>> On 2023-08-29, Diederik de Haas wrote:
>> > Upstream recently added support for the following Pine64 Quartz64 devices:
>> > - Quartz64 Model A
>> > - Quartz64 Model B
>> > - SoQuartz on Model A board
>> > - SoQuartz on Blade board
>> > - SoQuartz on CM4 IO carrier board
>> 
>> Would you or someone else be willing to be listed as a tester for these
>> boards?
>
> You can add me as tester for Quartz64 Model A + B, but I don't have a 
> SoQuartz 
> (or a base/carrier board).

Ok, if we ever get there... but I would not want to enable new boards
that nobody has ever offered to test.


>> > https://source.denx.de/u-boot/u-boot/-/tree/master/board/pine64/quartz64_
>> > rk3566
>> > 
>> > Hereby the request to package them for Debian.

This is going to require quite a bit of work:

* package "rkbin" in non-free-firmware, if the license permits

* get appropriate rk35xx builds for TF-A (a.k.a. arm-trusted-firmware)
  merged upstream, and then uploaded to the debian package (can possibly
  cheat and instead only use the bl31.elf from rkbin).
  
* figure out the complicated dance between packages in "contrib"
  depending on packages in "non-free-firmware" and not polluting
  packages built from the same source in "main"


>> Although, you will likely first need to enable in arm-trusted-firmware,
>> as that is usually a build-dependency for u-boot on rockchip platforms.
>
> ... but it looks like I have some time to learn :-P ... given the speed of 
> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16952
> and https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/20480 (although 
> it does seem to have gotten some momentum recently)

Yeah, there does at least appear to be some recent activity, at least...


> In some build instructions for u-boot that I've seen there was a reference to 
> an `bl31.elf` file from https://github.com/rockchip-linux/rkbin but I guess 
> that's what TF-A would provide (too), but then built from source?

Yes.


> I also recall seeing references to a `rk3568_ddr_1056MHz_v1.18.bin` file from 
> https://github.com/rockchip-linux/rkbin/tree/master/bin/rk35. AFAIK that's 
> only available as a BLOB? Is that file needed? And is it a problem if that's 
> only available as a BLOB?

If upstream u-boot requires that to work it is... more complicated.

Looks like it does probably require it, based on the trustedfirmware
thread you linked to above.


> Rockchip did add a LICENSE recently (in case that helps/is relevant):
> https://github.com/rockchip-linux/rkbin/blob/master/LICENSE

That license looks like it *maybe* would work for the
"non-free-firmware" part of the repo...

In which case, it might be possible to use those blobs for both
arm-trusted-firmware/TF-A and the ddr training blob.


Someone had briefly explored doing something similar for imx8*
platforms, and it was a maze of complications... though the imx8* blobs
turned out to not even be suitible for non-free-firmware, in the end, so
it stalled out.

Because of all these complications, I have so far tried to stick to
platforms which are strictly suitable for debian "main", although
technically the requirements are a bit looser than they used to
be... but I have little experience with or enthusiasm for the
complexities such a setup would bring for the u-boot and
arm-trusted-firmware packaging in Debian.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1050587: linux: cpufreq-dt requires manually loading cpufreq-dt-platdev (6.5 regression)

[Lukas F. Hartmann]

I encountered the same issue on MNT Reform with Banana Pi CM4 module
(Amlogic A311D / meson g12b). The processor operates at lowest speed and
toolig can't display CPU freqs, until the cpufreq-dt-platdev module is
loaded manually.

Bug#1050867: support for YAML aliases broken by switch from safe_yaml to Psych

[Sébastien Villemot]

Package: jekyll
Version: 4.3.1+dfsg-2
Severity: normal
Tags: patch

Dear Maintainers,

In jekyll 4.3.1+dfsg-1, a Debian-specific patch was added to rely on Psych
instead of safe_yaml for reading YAML files (see #1026427).

This change has however broken support for YAML aliases. More precisely, I’m no
longer able to use the minimal-mistakes theme, because this theme triggers the
parsing of the following YAML file:
 https://github.com/mmistakes/minimal-mistakes/blob/master/_data/ui-text.yml

This YAML file has aliases (symbol names starting with an ampersand), which are
not supported by the Psych.safe_load() method with its default arguments. I
thus get this error message (truncated trace):

/usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:430:in `visit_Psych_Nodes_Alias': 
Unknown alias: DEFAULT_EN (Psych::BadAlias)
from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:30:in `visit'
from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:6:in `accept'
from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:35:in `accept'
from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:345:in `block in 
revive_hash'
from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each'
from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each_slice'
from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `revive_hash'
from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:167:in 
`visit_Psych_Nodes_Mapping'
from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:30:in `visit'
from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:6:in `accept'
from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:35:in `accept'
from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:345:in `block in 
revive_hash'
from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each'
from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each_slice'
from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `revive_hash'
from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:167:in 
`visit_Psych_Nodes_Mapping'
from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:30:in `visit'
from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:6:in `accept'
from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:35:in `accept'
from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:318:in 
`visit_Psych_Nodes_Document'
from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:30:in `visit'
from /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:6:in `accept'
from /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:35:in `accept'
from /usr/lib/ruby/3.1.0/psych.rb:335:in `safe_load'
from 
/usr/share/rubygems-integration/all/gems/jekyll-4.3.1/lib/jekyll/utils.rb:321:in
 `safe_load_yaml'
from 
/usr/share/rubygems-integration/all/gems/jekyll-4.3.1/lib/jekyll/utils.rb:330:in
 `safe_load_yaml_file'
[…]

An easy fix is to explicitly allow aliases. I attach a patch (which must be
applied on top of 0016-Drop-usage-of-safe_yaml.patch).

Thanks for your work,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org
--- /usr/share/rubygems-integration/all/gems/jekyll-4.3.1/lib/jekyll/utils.rb   
2023-04-16 23:35:56.0 +0200
+++ utils.rb2023-08-30 15:56:26.028936881 +0200
@@ -318,7 +318,7 @@
 
 # Safely load YAML strings
 def safe_load_yaml(yaml)
-  Psych.safe_load(yaml, :permitted_classes => [Date, Time])
+  Psych.safe_load(yaml, :permitted_classes => [Date, Time], aliases: true)
 rescue ArgumentError
   # Psych versions < 3.1 had a different safe_load API and used
   # problematic language.

Bug#1050866: poppler: missing ToUnicode support for similarequal

[Vincent Lefevre]

Source: poppler
Version: 22.12.0-2
Severity: normal
Tags: patch upstream
Forwarded: https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1444

For \simeq, TeX generates /similarequal instead of Adobe's
/asymptoticallyequal; so similarequal needs to be supported too.

In TeX Live 2023:
texmf-dist/fonts/map/glyphlist/glyphlist.txt (Adobe Glyph List) contains

  asymptoticallyequal;2243

but texmf-dist/fonts/map/glyphlist/texglyphlist.txt (Extensions to the
Adobe Glyph List for TeX fonts and encodings) contains

  similarequal;2243

As a consequence, texmf-dist/tex/generic/pdftex/glyphtounicode.tex
contains both

  \pdfglyphtounicode{asymptoticallyequal}{2243}
  \pdfglyphtounicode{similarequal}{2243}

NameToUnicodeTable.h already has

  { 0x2243, "asymptoticallyequal" }
so one just needs to add the missing

  { 0x2243, "similarequal" }

To reproduce the issue, consider the following simeq.tex file:

\documentclass{article}
\usepackage[T1]{fontenc}
\begin{document}
\thispagestyle{empty}
$\simeq\approx$
\end{document}

In the PDF file generated by pdflatex, after uncompressing it with
"qpdf --stream-data=uncompress":

/F32 9.9626 Tf 148.712 707.125 Td [('\031)]TJ

and

dup 25 /approxequal put
dup 39 /similarequal put

i.e. /similarequal is generated for \simeq, and pdftotext gives

'≈

(the apostrophe ', code 39, corresponds to /similarequal, but appears
as an apostrophe since /similarequal is not supported; and \031, i.e.
25 in decimal, corresponds to /approxequal, which appears correctly
because /approxequal is supported).

With the attached patch, pdftotext gives

≃≈

as wanted.

I've created a merge request upstream.

-- 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)
Foreign Architectures: i386

Kernel: Linux 6.4.0-3-amd64 (SMP w/12 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

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Description: add ToUnicode support for similarequal.
 For \simeq, TeX generates /similarequal instead of Adobe's
 /asymptoticallyequal; so similarequal needs to be supported too.
 In TeX Live 2023:
 texmf-dist/fonts/map/glyphlist/glyphlist.txt (Adobe Glyph List) contains
   asymptoticallyequal;2243
 but texmf-dist/fonts/map/glyphlist/texglyphlist.txt (Extensions to the
 Adobe Glyph List for TeX fonts and encodings) contains
   similarequal;2243
 As a consequence, texmf-dist/tex/generic/pdftex/glyphtounicode.tex
 contains both
   \pdfglyphtounicode{asymptoticallyequal}{2243}
   \pdfglyphtounicode{similarequal}{2243}
 NameToUnicodeTable.h already has
   { 0x2243, "asymptoticallyequal" }
 so one just needs to add the missing
   { 0x2243, "similarequal" }
Merge-Request: 
https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1444
Author: Vincent Lefevre 
Last-Update: 2023-08-30

diff --git a/poppler/NameToUnicodeTable.h b/poppler/NameToUnicodeTable.h
index c7749f00..36bb5bb7 100644
--- a/poppler/NameToUnicodeTable.h
+++ b/poppler/NameToUnicodeTable.h
@@ -3518,6 +3518,7 @@ static const struct NameToUnicodeTab 
nameToUnicodeTextTab[] = { { 0x0021, "!" },
 { 0x05bd, 
"siluqhebrew" },
 { 0x05bd, 
"siluqlefthebrew" },
 { 0x223c, 
"similar" },
+{ 0x2243, 
"similarequal" },
 { 0x05c2, 
"sindothebrew" },
 { 0x3274, 
"siosacirclekorean" },
 { 0x3214, 
"siosaparenkorean" },

Bug#1050865: kwin-bismuth: Please patch for Wayland compatibility

[John Goerzen]

Package: kwin-bismuth
Version: 3.1.4-4
Severity: important
Tags: patch

Hi,

Bismuth doesn't work well with Wayland (and, in some cases, X11) in current KDE.

A one-character patch here fixes it:

https://github.com/Bismuth-Forge/bismuth/pull/490


-- System Information:
Debian Release: 12.1
  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-11-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kwin-bismuth depends on:
ii  libc6 2.36-9+deb12u1
ii  libgcc-s1 12.2.0-14
ii  libkdecorations2-5v5  4:5.27.5-2
ii  libkf5configcore5 5.103.0-2
ii  libkf5configgui5  5.103.0-2
ii  libkf5coreaddons5 5.103.0-1
ii  libkf5globalaccel-bin 5.103.0-1
ii  libkf5globalaccel55.103.0-1
ii  libkf5i18n5   5.103.0-1
ii  libkf5quickaddons55.103.0-1
ii  libqt5core5a  5.15.8+dfsg-11
ii  libqt5dbus5   5.15.8+dfsg-11
ii  libqt5gui55.15.8+dfsg-11
ii  libqt5qml55.15.8+dfsg-3
ii  libqt5quick5  5.15.8+dfsg-3
ii  libqt5widgets55.15.8+dfsg-11
ii  libstdc++612.2.0-14
ii  plasma-workspace  4:5.27.5-2
ii  qml-module-org-kde-kcm5.103.0-1
ii  qml-module-org-kde-kirigami2  5.103.0-1
ii  qml-module-qtquick-controls   5.15.8-2
ii  qml-module-qtquick-layouts5.15.8+dfsg-3
ii  qml-module-qtquick2   5.15.8+dfsg-3

kwin-bismuth recommends no packages.

kwin-bismuth suggests no packages.

-- no debconf information

Bug#1050239: linux-image-6.1.0-11-amd64 breaks usermode networking for Windows VM in Gnome Boxes

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Tue, Aug 22, 2023 at 03:45:08PM +0200, Stijn Segers wrote:
> Package: linux-image-6.1.0-11-amd64
> Version: 6.1.38-4
> 
> Using kernel linux-image-6.1.0-11-amd64, my Windows 10 VM loses network
> connectivity. Linux VMs still work (tested with an Xubuntu 23.04 and 22.04
> LTS VM). Rolling back to linux-image-6.1.0-10-amd64 makes the Windows VM
> connect to the network again.
> 
> Tested in Gnome Boxes on Debian Bookworm; used virt-manager as well to start
> the Windows VM to make sure it was not a Gnome Boxes issue.
> 
> Network configuration snippet of the Windows 10 VM:
> 
> 
> 
> 
>   
>   
>function='0x0'/>
> 
> 

You are not giving information on the underlying host, but can you
specificy is this a regression from 6.1.38-2? 

While not exactly the same, there were regression from the AMD
Inception fixes, can you verify if #1043585 is the same and the
upstream changes fixes your issue?

Regards,
Salvatore

Bug#1050864: nginx-common: dangling soft link

[Jörg-Volker Peetz]

Package: nginx-common
Version: 1.24.0-1
Severity: normal

Dear Nginx Maintainer,

there is this dangling soft link in the package:

/usr/share/nginx/modules

Shouldn't it be removed?

Regards,
Jörg.

Bug#1050001: Unwinding directory aliasing [and 3 more messages] [and 1 more messages]

[Ian Jackson]

On the burden of proof and the correctness of software:

I'm afraid I see a pattern, where blanket statements are made which
are only "mostly" or "roughly" or "generally" true.  But the
discrepancies and details matter.  When we make computer systems, it's
not good enough to if they're only "mostly" right.

Every program is an unproven conjecture whose truth we end up relying
on.  We need simple axioms, and rigorously correct reasoning.

Aliased usrmerge, when deployed, was a conjecture that was disputed:
"usrmerge via directory aliasing functions correctly".

In the time since the TC dismissed the objections and ruled in favour
of believing in the truth of this conjecture, has been disproven.
It is false in such important wsys that even in Debian, where we have
every possible advantage, we have been significantly inconvenienced.
Now we have a long list of counterexamples demonstrating the
invalidity of the original thesis.

Nevertheless, in mathematical terms, we are trying to patch up
the conjecture with many qualifications - the mitigations.
Also, we are apparently trying to impose on 3rd parties qualifications
about when it is OK to refer to files by the "wrong" name, which
cannot even be stated clearly, let along succinctly.

Despite all this, apparently when we argue for continued reliance on
this disproven assertion we go back to imprecise statements.

Helmut Grohne writes ("Bug#1050001: Unwinding directory aliasing [and 3 more 
messages]"):
> In order to prefer Debian over something else, we want it to be similar
> enough to make switching feasible while making it differ from others
> enough to make switching worthwhile. Not having aliasing symlinks hardly
> seems like an aspect that makes Debian more suitable to people. I guess
> that you disagree with this and that is fine.

Debian has historically been simply much more reliable.  That
reliability doesn't come from one particular decision.  It comes from
an aggregate of, on the whole, making better decisions.  That
reliability is very valuable to our users and downstreams.  It's
one of our our most compelling advantages.

>  My impression has always been that the disagreement on the end
> state was involving a minority.

Well, if you disagree with aliased usrmerge and say you don't want it,
you get abuse.  Even here, many abusive messages have been posted with
impunity by persons with considerable status.

usrmerge is a facet of Debian's culture wars.  (Debian's culture wars
are mostly orthogonal to the wider world's, but it would be foolish to
ignore the huge social factors at play.)  If one is on the
currently-losing side one is not optimistic about the value of making
one's views widely known.  Most of my friends agree with me on
substance but think it's a lost cause.

Of course, I could try to "solve" this invisibility by making a blog
post drawing attention and asking random people across the internet to
"contribute" to this discussion (or even just ask them to "me too").
That might even be effective, since currently I'm rather alone here.

I'm not doing that because Debian is quite toxic enough.  (And also
because as an apparent minority, seen as a reactionary outgroup, we
would get blamed for the behaviour of extremists.)

> > This argument is basically drawing together the common factor in the
> > DEP-17 problem list.
> 
> And that's precisely why I don't understand your argument. All of the
> DEP-17 problems are supposed to go away. So it appears as if you cite a
> list of problems that I expect to not be problems for much longer as a
> reason for changing the end goal.

DEP-17's list of *problems* forms a category: directory-aliasing-
induced malfunctions.  But the DEP-17 *solutions* are ad-hoc, and many
are only applicable to to malfunctions that occur during migration.
There is nothing inherently migration-specific about aliasing-induced
malfunction; migration is in this context mostly just a lot of Things
happening, each of which has a chance to go wrong.

The result of the current plan is that all directory-aliasing-induced
malfunctions must be averted, individually, forever.  By us, but also
by everyone who has to modify any Debian-derived system.

> > Affected tooling includes not just our .debs, but also remote
> > configuration management systems like Ansible, image construction
> > (Dockerfiles), and 3rd-party software installation progrmas (including
> > both 3rd-party .debs and 3rd-party script-based installation systems).
> 
> I don't follow the reasoning. [...]

Sam has posted a helpful set of examples of things that one might do,
whose consequences with aliased directories are unclear.

These are of course only examples.

> > I would be much more convinced that all of this isn't a problem, if
> > there existed, and had been formally adopted (eg by existing in some
> > manual somewhere) a short and clear set of rules about what is and
> > isn't allowed - not just rules for us within Debian, but rules for
> > everyone, 

Bug#1050863: r8168-dkms: module fails to compile against kernel 6.4.x

[Don Alex]

Package: r8168-dkms
Version: 8.051.02-3
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: de...@roosoft.ltd.uk

Dear Maintainer,


   * What led up to the situation?
Normal apt upgrade on Debian Testing
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Nothing, dkms fails according to this log.

DKMS make.log for r8168-8.051.02 for kernel 6.4.0-3-amd64 (x86_64)
Wed 30 Aug 12:41:03 BST 2023
make: Entering directory '/usr/src/linux-headers-6.4.0-3-amd64'
  CC [M]  /var/lib/dkms/r8168/8.051.02/build/r8168_n.o
  CC [M]  /var/lib/dkms/r8168/8.051.02/build/r8168_asf.o
  CC [M]  /var/lib/dkms/r8168/8.051.02/build/rtl_eeprom.o
  CC [M]  /var/lib/dkms/r8168/8.051.02/build/rtltool.o
/var/lib/dkms/r8168/8.051.02/build/r8168_n.c: In function
‘r8168_csum_workaround’:
/var/lib/dkms/r8168/8.051.02/build/r8168_n.c:29212:24: error: implicit
declaration of function ‘skb_gso_segment’; did you mean ‘skb_gso_reset’?
[-Werror=implicit-function-declaration]
29212 | segs = skb_gso_segment(skb, features);
  |^~~
  |skb_gso_reset
/var/lib/dkms/r8168/8.051.02/build/r8168_n.c:29212:22: warning: assignment to
‘struct sk_buff *’ from ‘int’ makes pointer from integer without a cast [-Wint-
conversion]
29212 | segs = skb_gso_segment(skb, features);
  |  ^
cc1: some warnings being treated as errors
make[1]: *** [/usr/src/linux-headers-6.4.0-3-common/scripts/Makefile.build:257:
/var/lib/dkms/r8168/8.051.02/build/r8168_n.o] Error 1
make: *** [/usr/src/linux-headers-6.4.0-3-common/Makefile:2057:
/var/lib/dkms/r8168/8.051.02/build] Error 2
make: Leaving directory '/usr/src/linux-headers-6.4.0-3-amd64'


   * What was the outcome of this action?
initrd fails to build and so new kernel updates cannot be installed. Could
potentially leave the system without network access

   * What outcome did you expect instead?

Clean module build.


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

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

Versions of packages r8168-dkms depends on:
ii  dkms  3.0.11-3

r8168-dkms recommends no packages.

r8168-dkms suggests no packages.

-- debconf-show failed

Bug#1050862: ship systemd-tmpfiles /usr/lib/tmpfiles.d/tor.conf to fix permission issues

[Patrick Schleizer]

Package: tor
Severity: wishlist

Dear maintainer,

if file permissions in folder /var/lib/tor are messed up [1], i.e. if 
any files or sub folders there are owned by anything other than Linux 
user/group debian-tor, then Tor will fail to start.


Also if user /var/lib/tor was previously deleted, then the Tor systemd 
unit should be able to restore it without needing to re-install the tor 
package.


I would suggest the following /usr/lib/tmpfiles.d/tor.conf file contents:

d /var/lib/tor 02700 debian-tor debian-tor -
Z /var/lib/tor/* 0660 debian-tor debian-tor -

Kind regards,
Patrick Schleizer

[1] Which can happen in corner cases such as restoring backups, mounted 
file-systems, changing underlying Qubes TempalteVMs or other user error.

Bug#1050861: RM: golang-github-twstrike-gotk3adapter -- RoQA; FTBFS since 2021, coyim leaf library

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: golang-github-twstrike-gotk3adap...@packages.debian.org, 
z...@debian.org
Control: affects -1 + src:golang-github-twstrike-gotk3adapter


golang-github-twstrike-gotk3adapter was introduced to build coyim, which is
already removed in 2021, see #994195.

Bug#1050841: [IMPORTANT] Debian images no longer works for GPU driver installation with apt update

[Sean Whitton]

control: reassign -1 ftp.debian.org
control: retitle -1 linux-headers-5.10.0-24-cloud-amd64 no longer installable
control: severity -1 wishlist
control: tag -1 + moreinfo

Hello,

This is not a bug in apt.  I'm not sure there's reason to think that
it's a bug at all.  Debian doesn't guarantee that you can upgrade any
other package without also having to upgrade the kernel.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1050860: icingaweb2: No translation for icingaweb2 base system

[Marcel Ebbrecht]

Package: icingaweb2
Version: 2.11.4-2
Severity: normal

Dear Maintainer,

after upgrading from bullseye to bookworm the translations are not working 
anymore. Locales are set up correctly and for different modules like x509, 
translation is correct. 

After a few tests considered on the web when translation is not working I 
recognized, that /usr/share/icingaweb2/application/locale is missing in my 
installation. I copied the directory from current git master branch to 
/usr/share/icingaweb2/application/locale without success.

Greetings,
Marcel

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

Kernel: Linux 6.1.0-11-amd64 (SMP w/8 CPU threads; 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 icingaweb2 depends on:
ii  fonts-dejavu-core 2.37-6
ii  fonts-dejavu-extra2.37-6
ii  icingaweb2-common 2.11.4-2
ii  php-xml   2:8.2+93+0~20230409.46+debian12~1.gbpdb4dcc
ii  php7.4-xml [php-xml]  1:7.4.33-7+0~20230815.86+debian12~1.gbp091944
ii  php8.1-xml [php-xml]  8.1.22-1+0~20230815.49+debian12~1.gbp8da143
ii  php8.2-xml [php-xml]  8.2.8-1+0~20230815.27+debian12~1.gbp5cf2f6

Versions of packages icingaweb2 recommends:
ii  apache2 [httpd]   2.4.57-2
ii  icingacli 2.11.4-2
ii  icingaweb2-module-doc 2.11.4-2
ii  icingaweb2-module-monitoring  2.11.4-2
ii  libapache2-mod-php8.2 [php-j  8.2.8-1+0~20230815.27+debian12~1.gbp5cf2f6
son]
ii  nagios-images 0.9.5
ii  nginx [httpd] 1.22.1-9
ii  php   2:8.2+93+0~20230409.46+debian12~1.gbpdb4dcc
ii  php-cli   2:8.2+93+0~20230409.46+debian12~1.gbpdb4dcc
ii  php-curl  2:8.2+93+0~20230409.46+debian12~1.gbpdb4dcc
ii  php-gd2:8.2+93+0~20230409.46+debian12~1.gbpdb4dcc
ii  php-imagick   3.7.0-4+0~20230701.41+debian12~1.gbpbf7e27
ii  php-intl  2:8.2+93+0~20230409.46+debian12~1.gbpdb4dcc
ii  php-json  2:8.2+93+0~20230409.46+debian12~1.gbpdb4dcc
ii  php-ldap  2:8.2+93+0~20230409.46+debian12~1.gbpdb4dcc
ii  php-mbstring  2:8.2+93+0~20230409.46+debian12~1.gbpdb4dcc
ii  php7.4 [php]  1:7.4.33-7+0~20230815.86+debian12~1.gbp091944
ii  php7.4-cli [php-cli]  1:7.4.33-7+0~20230815.86+debian12~1.gbp091944
ii  php7.4-curl [php-curl]1:7.4.33-7+0~20230815.86+debian12~1.gbp091944
ii  php7.4-gd [php-gd]1:7.4.33-7+0~20230815.86+debian12~1.gbp091944
ii  php7.4-intl [php-intl]1:7.4.33-7+0~20230815.86+debian12~1.gbp091944
ii  php7.4-json [php-json]1:7.4.33-7+0~20230815.86+debian12~1.gbp091944
ii  php7.4-ldap [php-ldap]1:7.4.33-7+0~20230815.86+debian12~1.gbp091944
ii  php7.4-mbstring [php-mbstrin  1:7.4.33-7+0~20230815.86+debian12~1.gbp091944
g]
ii  php7.4-xml [php-dom]  1:7.4.33-7+0~20230815.86+debian12~1.gbp091944
ii  php8.1-cgi [php-json] 8.1.22-1+0~20230815.49+debian12~1.gbp8da143
ii  php8.1-cli [php-json] 8.1.22-1+0~20230815.49+debian12~1.gbp8da143
ii  php8.1-curl [php-curl]8.1.22-1+0~20230815.49+debian12~1.gbp8da143
ii  php8.1-fpm [php-json] 8.1.22-1+0~20230815.49+debian12~1.gbp8da143
ii  php8.1-gd [php-gd]8.1.22-1+0~20230815.49+debian12~1.gbp8da143
ii  php8.1-imagick [php-imagick]  3.7.0-4+0~20230701.41+debian12~1.gbpbf7e27
ii  php8.1-intl [php-intl]8.1.22-1+0~20230815.49+debian12~1.gbp8da143
ii  php8.1-ldap [php-ldap]8.1.22-1+0~20230815.49+debian12~1.gbp8da143
ii  php8.1-mbstring [php-mbstrin  8.1.22-1+0~20230815.49+debian12~1.gbp8da143
g]
ii  php8.1-xml [php-dom]  8.1.22-1+0~20230815.49+debian12~1.gbp8da143
ii  php8.2 [php]  8.2.8-1+0~20230815.27+debian12~1.gbp5cf2f6
ii  php8.2-cgi [php-json] 8.2.8-1+0~20230815.27+debian12~1.gbp5cf2f6
ii  php8.2-cli [php-json] 8.2.8-1+0~20230815.27+debian12~1.gbp5cf2f6
ii  php8.2-curl [php-curl]8.2.8-1+0~20230815.27+debian12~1.gbp5cf2f6
ii  php8.2-fpm [php-json] 8.2.8-1+0~20230815.27+debian12~1.gbp5cf2f6
ii  php8.2-gd [php-gd]8.2.8-1+0~20230815.27+debian12~1.gbp5cf2f6
ii  php8.2-imagick [php-imagick]  3.7.0-4+0~20230701.41+debian12~1.gbpbf7e27
ii  php8.2-intl [php-intl]8.2.8-1+0~20230815.27+debian12~1.gbp5cf2f6
ii  php8.2-ldap [php-ldap]8.2.8-1+0~20230815.27+debian12~1.gbp5cf2f6
ii  php8.2-mbstring [php-mbstrin  8.2.8-1+0~20230815.27+debian12~1.gbp5cf2f6
g]
ii  php8.2-phpdbg [php-json]  8.2.8-1+0~20230815.27+debian12~1.gbp5cf2f6
ii  php8.2-xml [php-dom]  8.2.8-1+0~20230815.27+debian12~1.gbp5cf2f6

icingaweb2 suggests no packages.

-- no debconf information

Bug#1000053: courier: depends on obsolete pcre3 library

[Bastian Germann]

Upstream verison 1.1.6 has moved to pcre2.

Bug#1050812: u-boot-rockchip: Please add support for Pine64 Quartz64 devices

[Diederik de Haas]

Hi Vagrant,

On Wednesday, 30 August 2023 00:41:18 CEST you wrote:
> On 2023-08-29, Diederik de Haas wrote:
> > Upstream recently added support for the following Pine64 Quartz64 devices:
> > - Quartz64 Model A
> > - Quartz64 Model B
> > - SoQuartz on Model A board
> > - SoQuartz on Blade board
> > - SoQuartz on CM4 IO carrier board
> 
> Would you or someone else be willing to be listed as a tester for these
> boards?

You can add me as tester for Quartz64 Model A + B, but I don't have a SoQuartz 
(or a base/carrier board).

> > https://source.denx.de/u-boot/u-boot/-/tree/master/board/pine64/quartz64_
> > rk3566
> > 
> > Hereby the request to package them for Debian.
> 
> Presuming they are similar to the other rockchip arm64 targets, could
> you provide a basic patch and test one or more of the above platforms to
> work? For example, the rock64-rk3328:
>  
> https://salsa.debian.org/debian/u-boot/-/blob/debian/latest/debian/targets.
> mk#L109

I can/will give it a try, but the u-boot stuff is mostly a mystery to me.
https://github.com/Kwiboo/u-boot-build/ is what I have been using so far ...

> Although, you will likely first need to enable in arm-trusted-firmware,
> as that is usually a build-dependency for u-boot on rockchip platforms.

... but it looks like I have some time to learn :-P ... given the speed of 
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16952
and https://review.trustedfirmware.org/c/ci/tf-a-ci-scripts/+/20480 (although 
it does seem to have gotten some momentum recently)

In some build instructions for u-boot that I've seen there was a reference to 
an `bl31.elf` file from https://github.com/rockchip-linux/rkbin but I guess 
that's what TF-A would provide (too), but then built from source?

I also recall seeing references to a `rk3568_ddr_1056MHz_v1.18.bin` file from 
https://github.com/rockchip-linux/rkbin/tree/master/bin/rk35. AFAIK that's 
only available as a BLOB? Is that file needed? And is it a problem if that's 
only available as a BLOB?
Rockchip did add a LICENSE recently (in case that helps/is relevant):
https://github.com/rockchip-linux/rkbin/blob/master/LICENSE

Cheers,
  Diederik

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

Bug#1050325: Unknown group "wheel" in message bus configuration file

[Jonas Smedegaard]

Control: reopen -1

Quoting Simon McVittie (2023-08-30 12:20:07)
> On Wed, 30 Aug 2023 at 11:44:56 +0200, Michael Biebl wrote:
> > [iwd] triggers a warning on every start or reload of dbus:
> > 
> > Aug 08 20:01:51 pluto dbus-daemon[706]: Unknown group "wheel" in message bus
> > configuration file
> > 
> > I do consider this a bug in the configuration that is shipped by the iwd
> > package.
> 
> I agree with Michael. Debian packages should only refer to groups
> that are reserved by base-passwd, the package itself, or the package's
> dependencies.
> 
> This is arguably even a security issue: the "wheel" group name is not
> reserved on Debian systems, so there would be nothing preventing a
> user (presumably one without knowledge of 1980s Unix tradition or
> conventional group names in non-Debian distros) from creating a new
> user/group of that name, not expecting that it would grant extra
> privileges.
> 
> The closest Debian equivalent of other distros' wheel group is the
> sudo group, as defined by base-passwd.

Thanks for the clarification.  Makes good sense (and sorry, Michael,
that I didn't recognized that from your original bugreport).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1050859: xxhash: update d/watch file

[Patrice Duroux]

Source: xxhash
Version: 0.8.1-1
Severity: minor

Dear Maintainer,

Here is a suggestion for.

Thanks,
Patrice


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

Kernel: Linux 6.5.0-0-amd64 (SMP w/12 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
diff --git a/debian/watch b/debian/watch
index 2d3805a..920a2e4 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,3 +1,3 @@
 version=4
-opts=filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/xxhash-$1\.tar\.gz/ \
-  https://github.com/Cyan4973/xxHash/releases/latest .*/v?(\d\S*)\.tar\.gz
+opts=filenamemangle=s/.+\/v?@ANY_VERSION@(@ARCHIVE_EXT@)/xxhash-$1$2/ \
+  https://github.com/Cyan4973/xxHash/tags .*/v?@ANY_VERSION@@ARCHIVE_EXT@

Bug#1050325: Unknown group "wheel" in message bus configuration file

[Simon McVittie]

On Wed, 30 Aug 2023 at 11:44:56 +0200, Michael Biebl wrote:
> [iwd] triggers a warning on every start or reload of dbus:
> 
> Aug 08 20:01:51 pluto dbus-daemon[706]: Unknown group "wheel" in message bus
> configuration file
> 
> I do consider this a bug in the configuration that is shipped by the iwd
> package.

I agree with Michael. Debian packages should only refer to groups
that are reserved by base-passwd, the package itself, or the package's
dependencies.

This is arguably even a security issue: the "wheel" group name is not
reserved on Debian systems, so there would be nothing preventing a user
(presumably one without knowledge of 1980s Unix tradition or conventional
group names in non-Debian distros) from creating a new user/group of
that name, not expecting that it would grant extra privileges.

The closest Debian equivalent of other distros' wheel group is the
sudo group, as defined by base-passwd.

(It would probably also be better if iwd could avoid group-based policy in
dbus-daemon configuration files and instead use polkit to query policy,
but I realise that's non-trivial upstream development work, and it's
out of scope for this particular bug.)

smcv

Bug#1041389: Will Upload NMU

[Barak A. Pearlmutter]

Dear Alexander,

Since minidlna upstream version 1.3.3 has been out since the end of
May 2023, and I've been testing my packaging of it pretty hard and it
seems significantly more robust than the current version in Debian,
I'm going to take the liberty of doing an NMU of it with a delay of
three days. Hope that's okay! (And if you're looking for a
co-maintainer, or an extra team member, or whatever: pick me! Pick me!
Also if you cancel the upload and tell me to go away and stop
bothering you: also okay, and sorry for the trouble!)

Cheers,

--Barak.

PS It's great that minidlna is in Debian; nothing else seems to just
work, and the Gnome rygel thing just mysteriously crashes, while
minidlna just does its job.

Bug#1037629: Upgrade libtins to latest version?

[Oliver Smith]

Hello,

the mentioned bug is fixed in the latest version of libtins:


/usr/include/tins/ip_address.h:220:31: error: ‘uint32_t’ is not a member of 
‘std’; did you mean ‘wint_t’?


I have also created this bug report to ask for the upgrade on 2023-08-21:

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

However on 2023-08-24 the package was removed from testing, I guess 
because of this open bug report?


https://tracker.debian.org/news/1456620/libtins-removed-from-testing/

So can the package be added back, and get upgraded to the latest version?

Thanks!

--
- Oliver Smith https://www.sysmocom.de/
===
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

Bug#1050186: [Pkg-nginx-maintainers] Bug#1050186: Bug#1050186: libnginx-mod-http-lua: depends on obsolete pcre3 library

[Jan Mojzis]

Hi,
I've uploaded experimental version with the PCRE2 patch included
1:0.10.25-2~exp1 to the experimental.

Jan


On Tue, 29 Aug 2023 15:50:52 +0200 =?UTF-8?B?SsOpcsOpbXkgTGFs?= 
 wrote:
> Le mar. 29 août 2023 à 15:43, Thomas Ward  a écrit :
> 
> > I apoligize I was thinking Lua deps not PCRE.
> >
> > However, I did more digging. OpenResty has been on NGINX cofe version
> > 1.21.4 for the longest time.  They do not have PCRE2 support in their
> > system.  As this is an OpenResty-originating module the 4th requirement as
> > stated in the linked GitHub issue is not met.
> >
> > I would not be so sure that "next update" will have a fix if OpenResty
> > core does not support PRCE2 (1.21.5 nginx introduced PCRE2 core
> > requirement/build fixes, OpenResty never inccuded that).  The reason PCRE3
> > is still used here in the Lua module is the custom workaround of mixing
> > PCRE2 nginx and PCRE3 Lua which use different build flags at compile time
> > with the linking options.
> >
> > Therefore, we need to not make assumptions and watch this closely.  If
> > there is not movement in a reasonable time period, then we may have to drop
> > this module from Debian due to PCRE3 being obsolete.
> >
> 
> Actually, openresty has started supporting nginx 1.25.1 recently:
> 
> [feature: upgrade nginx core to 1.25.1 which supports HTTP3](
> https://github.com/openresty/openresty/commit/6278b1aeae0593b17d3143aeb60a216f73b6bb1d)[feature:
> [upgrade nginx core to 1.25.1](
> https://github.com/openresty/stream-lua-nginx-module/commit/d48f057f18eb1f33123bf62be49c735c5cb98f16
> )
> [upgrade nginx core to 1.25.1](
> https://github.com/openresty/lua-nginx-module/commit/e69fd3de281f31804857aa6dc0b8e79055716138
> )
> >
> >
> Considering the work of the author of these patches, I'd be surprised if it
> wasn't finished soon (right now, only stream-lua-nginx has no support for
> pcre2).

Bug#1050857: fweb: Please modify rules file for texinfo upgrade

[yalingfang]

Package: fweb
Version: 1.62-14
Severity: wishlist
Tags: patch
User:debian-de...@lists.debian.org
Usertags: loongarch64

Dear maintainers,

   When I compiled 1.62-14 for loongarch architecture. Currently the texinfo 
upgrade to 7.*.
The folder name is changed from fweb to fweb_html by using makeinfo --html 
fweb.texi, so the rules should be modified after texinfo upgrade.

We have added sample patch and built success in my localenv.

The sample is following:
diff --git a/debian/rules b/debian/rules
index d83dad5..0b8018b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -64,7 +64,7 @@ clean:
 
-rm -f Web/idxmerge Web/idxmerge.c Web/custom.h Web/config.h \

Manual/fweb.info* Manual/fweb*.html
-   rm -rf Manual/fweb/
+   rm -rf Manual/fweb_html/
rm -f Web/fweave.mds Web/fweave.ndx
dh_clean
 
@@ -88,7 +88,7 @@ install: build

mandir=${mandir}/man1 \
install
 # documentation
-   ${installdoc} Manual/fweb/* ${htmldocdir}/
+   ${installdoc} Manual/fweb_html/* ${htmldocdir}/
${installdoc} Manual/fweb.texi ${docdir}/
${installdoc} debian/idxmerge.1 ${mandir}/man1/
ln -s fweb.1.gz ${mandir}/man1/fweave.1.gz



 If you have any questions, you can contact me at any time.

Bug#1024416: unbound does not restart reliably under sysvinit with apparmor in enforcing mode

[Michael Tokarev]

Control: tag -1 - patch

30.08.2023 13:00, Michael Tokarev wrote:
...

This is interesting, since I closed that bug report after merging the
change mentioned in there, which is exactly what you propose below,
with --remove-pidfile option:

   
https://salsa.debian.org/dns-team/unbound/-/commit/baca147f4cd27753ceca3a2855f463ed905b7eeb


Please, do not close this report unless, on a system managed by
sysvinit-core with apparmor in enforcing mode, exactly one instance of
unbound is left running after invoking "/etc/init.d/unbound restart"
at least four times in a row.


Ok, I'll left this bug open and tag it 'wontfix' for now, so it don't
catch my eyes from now on.


Also removing the tag "patch" since the proposed patch is already applied,
it's impossible to apply it second time.

/mjt

Bug#1050856: libgd2: update d/watch file

[Patrice Duroux]

Source: libgd2
Version: 2.3.3-9
Severity: minor

Dear Maintainer,

Here is a suggestion for.

Thanks,
Patrice


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

Kernel: Linux 6.5.0-0-amd64 (SMP w/12 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
diff --git a/debian/watch b/debian/watch
index 4480bdf..f8e903e 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,10 +1,9 @@
 # run the "uscan" command to check for upstream updates and more.
 version=4
 opts="\
-   compression=xz, \
searchmode=plain, \
uversionmangle=s/RC/~rc/, \
dversionmangle=s/\~dfsg$//, \
-   filenamemangle=s/.+\/libgd-@any_vers...@.tar.xz/@PACKAGE@-$1\.tar\.xz/, 
\
-   "
-https://api.github.com/repos/libgd/libgd/releases 
https://github.com/libgd/libgd/releases/download/gd-(\d\S+)/libgd-(\d\S+).tar.xz
+   
filenamemangle=s/.+\/libgd-@ANY_VERSION@(@ARCHIVE_EXT@)/@PACKAGE@-$1$2/, \
+   " \
+https://api.github.com/repos/libgd/libgd/releases 
https://github.com/libgd/libgd/releases/download/gd-[^/]+/libgd-@ANY_VERSION@@ARCHIVE_EXT@

Bug#1024416: unbound does not restart reliably under sysvinit with apparmor in enforcing mode

[Michael Tokarev]

Control: tag -1 + wontfix

On Sat, 19 Nov 2022 09:00:19 +0100 g1  wrote:

Package: unbound
Version: 1.13.1-1
Severity: normal
Tags: patch
X-Debbugs-Cc: g...@libero.it

Hi

With the apparmor profile shipped with unbound, /usr/sbin/unbound is
allowed to truncate and create its own pidfile /run/unbound.pid, but
cannot remove it at exit or rewrite it when it starts again.

As a consequence, "start-stop-daemon --stop" leaves behind an empty pidfile,
and a subsequent "start-stop-daemon --start" spawns a new daemon whose
pid is written nowhere.  The overall result is that N invocations of
"/etc/init.d/unbound restart" end up with N-1 daemons running, with
obvious implications for security.

In #947771 Stephane Lapie and Gedalya suggested a simple patch that
solves the problem.  That bug report was closed as "problem solved",
without actually applying the patch, probably because I failed to clearly
explain how to reproduce the issue.


This is interesting, since I closed that bug report after merging the
change mentioned in there, which is exactly what you propose below,
with --remove-pidfile option:

  
https://salsa.debian.org/dns-team/unbound/-/commit/baca147f4cd27753ceca3a2855f463ed905b7eeb


Please, do not close this report unless, on a system managed by
sysvinit-core with apparmor in enforcing mode, exactly one instance of
unbound is left running after invoking "/etc/init.d/unbound restart"
at least four times in a row.


Ok, I'll left this bug open and tag it 'wontfix' for now, so it don't
catch my eyes from now on.

Thanks,

/mjt

Bug#1000087: evqueue-core: depends on obsolete pcre3 library

[Bastian Germann]

Newer upstream versions do not depend on pcre.

Bug#1050855: RM: rust-rustls-0.20 -- ROM; obsoleted by rust-rustls

[Jonas Smedegaard]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-rustls-0...@packages.debian.org
Control: affects -1 + src:rust-rustls-0.20

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please drop package rust-rustls-0.20, no longer needed as all reverse
dependencies should have migrated to rust-rustls 0.21 by now.

 - Jonas
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmTvEsoACgkQLHwxRsGg
ASGUfA//TilP0oqW7Zxz9jxCobxn5K7L+hX7cQwAn+qfPbiflDL17Juw+svw58Qz
kQzULoex5ZP8sWY2gZPagDCqME5S6gGPdK0WOZlCWJtIX2y2rjgCSNpc3j2GlsjF
RvXhwSr0tpDOSTJ6NOwSQyZc+MOo9m8KWDthjG3aoxgwAIeGEEswScspxvronPMr
yY+xU06IIeSBCWhRNISmURKlXYItyHJ+aE+bgcComiMYPLGCHJJWOh0zN1/z5HTJ
PPjTVlI8OD9xWkvU0uYEHiHyrBHqRoSSb+pDATe8d18jh8t4nZzN/B+nqGPZt6oh
qGEqferluCnjkzffC6ZJ/hxhZx63YmHRNJzAkgyRv75/iwMh1jvKHwfp19jdaBG0
PPzWgQzt19ybfUg4stfLoLCsGowlOQg9i5I+Fy1s//xJJnmZPr+vS87Wh9p69xo/
cKYVz/F/awF0aoGggAKqzsVqqJoLDCMQS1IX75y6smNj8AnRQKYQenNC3mCZXewG
gPIAF7Aq/WmI+4eHskrldQnJe3rfcf9fNRK4gp3xYLmv/AoY30foU3suNgdXqjoK
YrMmiLWLOBOfugMcvHAaJnLoYaPJucUsBBvQUCZdbu0Cw6bA/azLdt4Y1ZzMb3C+
guFIOkqCK1WJp0PwLdOMt9OLoCOD8K9pzp8iwhVh2wRFe2fykQs=
=nBtB
-END PGP SIGNATURE-

Bug#1050325: closed by Jonas Smedegaard (reply to 1050...@bugs.debian.org) (Re: Bug#1050325: Unknown group "wheel" in message bus configuration file)

[Michael Biebl]

It triggers a warning on every start or reload of dbus:

Aug 08 20:01:51 pluto dbus-daemon[706]: Unknown group "wheel" in message 
bus configuration file


I do consider this a bug in the configuration that is shipped by the iwd 
package.


Simon, do you disagree?

Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1036299: unbound: can't bind to 127.0.0.1:53

[Michael Tokarev]

Control: tag -1 + moreinfo unreproducible

On Fri, 19 May 2023 10:05:08 +1200 andrej  wrote:

Package: unbound
Version: 1.17.1-2
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
 With our unbound configuration file unbound couldn't start

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Place the unbound apparmor profile into complain mode rather than enforcing


What's the apparmor error message(s) when it blocks unbound from using the given
address?  It works here just fine.

/mjt

Bug#1000131: e2guardian: depends on obsolete pcre3 library

[Bastian Germann]

I am uploading a NMU to fix this.diff -Nru e2guardian-5.3.5/debian/changelog e2guardian-5.3.5/debian/changelog
--- e2guardian-5.3.5/debian/changelog   2022-10-22 22:05:11.0 +0200
+++ e2guardian-5.3.5/debian/changelog   2023-08-30 10:40:56.0 +0200
@@ -1,3 +1,12 @@
+e2guardian (5.3.5-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix build with GCC 13. (Closes: #1037637)
+  * Disable pcre support. (Closes: #1000131)
+  * d/control: Drop unused quilt.
+
+ -- Bastian Germann   Wed, 30 Aug 2023 08:40:56 +
+
 e2guardian (5.3.5-4) unstable; urgency=medium
 
   * debian/watch:
diff -Nru e2guardian-5.3.5/debian/control e2guardian-5.3.5/debian/control
--- e2guardian-5.3.5/debian/control 2022-10-22 22:04:40.0 +0200
+++ e2guardian-5.3.5/debian/control 2023-08-30 10:40:56.0 +0200
@@ -7,8 +7,6 @@
  Benjamin Schlüter ,
 Build-Depends: debhelper-compat (= 13),
dpkg-dev (>= 1.16.1.1),
-   quilt,
-   libpcre3-dev,
libpthread-stubs0-dev,
libssl-dev (>= 1.1),
pkg-config,
diff -Nru e2guardian-5.3.5/debian/patches/0002_uint32-ListContainer.cpp.patch 
e2guardian-5.3.5/debian/patches/0002_uint32-ListContainer.cpp.patch
--- e2guardian-5.3.5/debian/patches/0002_uint32-ListContainer.cpp.patch 
1970-01-01 01:00:00.0 +0100
+++ e2guardian-5.3.5/debian/patches/0002_uint32-ListContainer.cpp.patch 
2023-08-30 10:40:56.0 +0200
@@ -0,0 +1,19 @@
+Origin: backport, eab1476ed478f409b11a89c97ad98bc0965d828e
+From: Arjow 
+Date: Tue, 9 May 2023 12:45:53 +0200
+Subject: Update ListContainer.cpp
+
+fix uint32_t error
+---
+diff --git a/src/ListContainer.cpp b/src/ListContainer.cpp
+index 087681bc..1107d1fb 100644
+--- a/src/ListContainer.cpp
 b/src/ListContainer.cpp
+@@ -9,6 +9,7 @@
+ #ifdef HAVE_CONFIG_H
+ #include "dgconfig.h"
+ #endif
++#include 
+ #include 
+ #include 
+ #include "ListContainer.hpp"
diff -Nru e2guardian-5.3.5/debian/patches/0003_uint32-ListContainer.hpp.patch 
e2guardian-5.3.5/debian/patches/0003_uint32-ListContainer.hpp.patch
--- e2guardian-5.3.5/debian/patches/0003_uint32-ListContainer.hpp.patch 
1970-01-01 01:00:00.0 +0100
+++ e2guardian-5.3.5/debian/patches/0003_uint32-ListContainer.hpp.patch 
2023-08-30 10:40:56.0 +0200
@@ -0,0 +1,19 @@
+Origin: backport, ab1299caf0cb5487e19e165e346d890fdc2e716d
+From: Arjow 
+Date: Tue, 9 May 2023 13:03:33 +0200
+Subject: Update ListContainer.hpp
+
+fixing uint32_t errror
+---
+diff --git a/src/ListContainer.hpp b/src/ListContainer.hpp
+index b83a057e..db0d4cb4 100644
+--- a/src/ListContainer.hpp
 b/src/ListContainer.hpp
+@@ -9,6 +9,7 @@
+ 
+ // INLCUDES
+ 
++#include 
+ #include 
+ #include 
+ #include 
diff -Nru e2guardian-5.3.5/debian/patches/series 
e2guardian-5.3.5/debian/patches/series
--- e2guardian-5.3.5/debian/patches/series  2022-03-12 13:57:01.0 
+0100
+++ e2guardian-5.3.5/debian/patches/series  2023-08-30 10:40:56.0 
+0200
@@ -3,3 +3,5 @@
 1002_fix-maxcontentramcachescansize.patch
 1003_AM_INIT_AUTOMAKE-expanded-multiple-times.patch
 0001_CVE-2021-44273_fix-hostname-validation-in-certificates.patch
+0002_uint32-ListContainer.cpp.patch
+0003_uint32-ListContainer.hpp.patch
diff -Nru e2guardian-5.3.5/debian/rules e2guardian-5.3.5/debian/rules
--- e2guardian-5.3.5/debian/rules   2020-02-15 10:53:35.0 +0100
+++ e2guardian-5.3.5/debian/rules   2023-08-30 10:40:56.0 +0200
@@ -23,7 +23,7 @@
--enable-email=yes \
--enable-ntlm=yes \
--enable-sslmitm=yes \
-   --enable-pcre=yes \
+   --enable-pcre=no \
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info
 

Bug#1050854: python-xarray: autopkgtest failures

[Bas Couwenberg]

Source: python-xarray
Version: 2023.08.0-1
Severity: serious
Tags: patch
Justification: autopkgtest failures

Dear Maintainer,

The autopkgtest for your package is failing:

 230s === FAILURES 
===
 230s  test_open_mfdataset_manyfiles[netcdf4-20-True-None-5] 
_
 230s 
 230s self = CachingFileManager(, 
'/tmp/tmp4hr6i68_/temp-1120.nc', mode='r', kwargs={'clobber': True, 'diskless': 
False, 'persist': False, 'format': 'NETCDF4'}, 
manager_id='abdbaa71-0b5f-4544-982d-afa923d39953')
 230s needs_lock = True
 230s 
 230s def _acquire_with_cache_info(self, needs_lock=True):
 230s """Acquire a file, returning the file and whether it was 
cached."""
 230s with self._optional_lock(needs_lock):
 230s try:
 230s >   file = self._cache[self._key]
 230s 
 230s /usr/lib/python3/dist-packages/xarray/backends/file_manager.py:211: 
 230s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ 
 230s 
 230s self = 
 230s key = [, 
('/tmp/tmp4hr6i68_/temp-1120.nc',), 'r', (('clobber', True), ('diskless', 
False), ('format', 'NETCDF4'), ('persist', False)), 
'abdbaa71-0b5f-4544-982d-afa923d39953']
 230s 
 230s def __getitem__(self, key: K) -> V:
 230s # record recent use of the key by moving it to the front of the 
list
 230s with self._lock:
 230s >   value = self._cache[key]
 230s E   KeyError: [, 
('/tmp/tmp4hr6i68_/temp-1120.nc',), 'r', (('clobber', True), ('diskless', 
False), ('format', 'NETCDF4'), ('persist', False)), 
'abdbaa71-0b5f-4544-982d-afa923d39953']
 230s 
 230s /usr/lib/python3/dist-packages/xarray/backends/lru_cache.py:56: KeyError
 230s 
 230s During handling of the above exception, another exception occurred:
 230s 
 230s readengine = 'netcdf4', nfiles = 20, parallel = True, chunks = None
 230s file_cache_maxsize = 5
 230s 
 230s @requires_dask
 230s @pytest.mark.filterwarnings("ignore:use make_scale(name) instead")
 230s def test_open_mfdataset_manyfiles(
 230s readengine, nfiles, parallel, chunks, file_cache_maxsize
 230s ):
 230s # skip certain combinations
 230s skip_if_not_engine(readengine)
 230s 
 230s if ON_WINDOWS:
 230s pytest.skip("Skipping on Windows")
 230s 
 230s randdata = np.random.randn(nfiles)
 230s original = Dataset({"foo": ("x", randdata)})
 230s # test standard open_mfdataset approach with too many files
 230s with create_tmp_files(nfiles) as tmpfiles:
 230s writeengine = readengine if readengine != "pynio" else 
"netcdf4"
 230s # split into multiple sets of temp files
 230s for ii in original.x.values:
 230s subds = original.isel(x=slice(ii, ii + 1))
 230s if writeengine != "zarr":
 230s subds.to_netcdf(tmpfiles[ii], engine=writeengine)
 230s else:  # if writeengine == "zarr":
 230s subds.to_zarr(store=tmpfiles[ii])
 230s 
 230s # check that calculation on opened datasets works properly
 230s >   with open_mfdataset(
 230s tmpfiles,
 230s combine="nested",
 230s concat_dim="x",
 230s engine=readengine,
 230s parallel=parallel,
 230s chunks=chunks if (not chunks and readengine != "zarr") 
else "auto",
 230s ) as actual:
 230s 
 230s /usr/lib/python3/dist-packages/xarray/tests/test_backends.py:3407: 
 230s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ 
 230s /usr/lib/python3/dist-packages/xarray/backends/api.py:1020: in 
open_mfdataset
 230s datasets, closers = dask.compute(datasets, closers)
 230s /usr/lib/python3/dist-packages/dask/base.py:600: in compute
 230s results = schedule(dsk, keys, **kwargs)
 230s /usr/lib/python3/dist-packages/dask/threaded.py:89: in get
 230s results = get_async(
 230s /usr/lib/python3/dist-packages/dask/local.py:511: in get_async
 230s raise_exception(exc, tb)
 230s /usr/lib/python3/dist-packages/dask/local.py:319: in reraise
 230s raise exc
 230s /usr/lib/python3/dist-packages/dask/local.py:224: in execute_task
 230s result = _execute_task(task, data)
 230s /usr/lib/python3/dist-packages/dask/core.py:119: in _execute_task
 230s return func(*(_execute_task(a, cache) for a in args))
 230s /usr/lib/python3/dist-packages/dask/utils.py:71: in apply
 230s return func(*args, **kwargs)
 230s /usr/lib/python3/dist-packages/xarray/backends/api.py:570: in open_dataset
 230s backend_ds = backend.open_dataset(
 230s /usr/lib/python3/dist-packages/xarray/backends/netCDF4_.py:602: in 
open_dataset
 230s store = NetCDF4DataStore.open(
 230s /usr/lib/python3/dist-packages/xarray/backends/netCDF4_.py:400: in open
 230s return cls(manager, group=group, 

Bug#1050853: ITP: glycin-loaders -- Image loaders for loupe

[Matthias Geiger]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, jbi...@debian.org, 
pkg-gnome-maintain...@lists.alioth.debian.org, werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: glycin-loaders
  Version : 0.1~beta4
  Upstream Contact: Sophie Herold
* URL : https://gitlab.gnome.org/sophie-h
* License : MPL-2.0 OR LGPL-2.1-or-later
  Programming Lang: Rust
  Description : Image loaders for loupe

glycin-loaders are four loaders for image formats. They consist of
a .so and a config file. They enable support for diffferent image
formats such as heic or svg.

They are needed for loupe. This package will be maintained within the
Debian GNOME team.

thanks,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmTvAqkVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1WrcP/iYEkn+U+IkKyzvqF/NFvGIaPGsv
fm8A8k+NTwoQ4Gun3+IcW6wmD7UpBlCh0fprkUqTyuMb79naeX7d3WUuv1qvRza2
hGkaflGqpAdcQQPHaHeGK2i5XCwgChedgUyFDllkZLDKgJ7dhsf9q+I1gfq52UYN
Qo9ek9PcLfmDYzXGlfCTprvzg0CpfOvg2TvRhElEXrqCeQMGWkq1c2pDqaja32x3
EV5t8WhusyBI9v7thRoDjpimPAJ2n5dVCbOKVA5LodFT+yXhqcu2CV8RzOdywzKX
+uP1NvtNWI7werXvP7enKZ3Q/KHOCaRI9dm00I85ZijrmxSQjw5eHQWt6X33Fo8X
MO+5Q20liVwy8qCvG9wTqbIorIgFO8Slw2BUY9hz2q8F4res8i72F2nQhgQLupp9
pwUmeUAqKb0eiWXjQLRnjdkAacyD3PpjPZB7ELL0R04O7e9ICNmMYy3tNzfhcI9O
sSWfropd8nhxVyW/zRxUaz7u0NiBSA8I+4HIduCvzrSkn/Pq0MRUbB0g725wMCLB
kA5Uh/Yn5FjEK6OZQLF3ql03AZ4vqfjYgrRJxRw7HuRuAKN+x5rrqWrRdhIWTPGG
R3Hk6jnw6VVGJcAJkGIawdUrb/j2w8j4F3YcI99SsGBVDGYM6JPg9F2cwWK0x5Wl
PFYQ/7sPeDHPzVD+
=I33y
-END PGP SIGNATURE-

Bug#1050833: release-notes: Bookworm renames network interfaces

[Rainer Dorsch]

Hi Justin,

many thanks for the quick follow-up.

Am Mittwoch, 30. August 2023, 07:46:04 CEST schrieben Sie:
> Are you saying that armhf machines still used one of the old interface
> naming schemes (https://wiki.debian.org/NetworkInterfaceNames) on
> bullseye, and hadn't yet switched over to "predictable" names?  

That is at least what I observed. I don't have insights, why armhf behaves 
differently here.

> For
> the architectures I know anything about, interface names like eth0
> disappeared quite a while ago, with particular warnings in the stretch
> and buster release notes:
> 
> https://www.debian.org/releases/stretch/amd64/release-notes/ch-whats-new.en.
> html#new-interface-names
> 
> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en
> .html#migrate-interface-names

If I understand the sentence

"This change does not apply to upgrades of jessie systems; the naming will 
continue to be enforced by /etc/udev/rules.d/70-persistent-net.rules."

correctly, this means old systems stay with the old naming scheme by default, 
newly installed systems use the new naming scheme.

That is an excellent solution, since it does not break existing systems during 
the upgrade. 

But what I observed in the armhf install is exactly the opposite. A running 
bullseye system did not work anymore after the upgrade to bookworm due to the 
network interface naming change. Since these are often headless systems, you 
then rely on a serial interface for debugging.

As a side note:
I have two amd64 kvm cloud hosted machines at different providers. I upgraded 
one of them to bookworm, both use still uses eth0 as interface name. I see the 
they have both

net.ifnames=0

configured as kernel parameter in /etc/default/grub in the variable 
GRUB_CMDLINE_LINUX.

Since I did not actively configure that, I assume that there are quite a few 
machines out there with disabled Predictable Network Interface renaming 
behavior.

> If the sequence of events has been different on armhf, that might need
> a new entry in the "Complications and corner cases" section of the
> wiki page.  The question is, how exactly did you come to be still
> using "eth0" in a bullseye /etc/network/interfaces file?

I just run the installer for bullseye on a cubox-i/armhf machine. I do not 
recall that I did anything special. I could repeat it, but maybe it is better 
if somebody else does a test (just in case I missed something, it is likely 
that I miss it again, though I don't know what that could be).

> Sure, *if* the change was in bookworm.  But if people didn't read
> the stretch and buster release notes, why would we expect a warning in
> the bookworm release notes to do any good? 

I am also somewhat concerned that users don't read the release notes 
carefully, break their systems. This information should probably be in a more 
prominent place and clearly visible during the upgrade. I liked the previous 
solution better that systems by default continue to use the old naming scheme.


Thanks again
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/

Bug#1050852: firmware-misc-nonfree: System crashes and reboots when i915/kbl_dmc_ver1_04.bin is present

[hanzoh]

Package: firmware-misc-nonfree
Version: 20230210-5
Severity: important

Dear Maintainer,

installing Debian 12 on an HP ProDesk 400 G5 Mini works fine, but gives the 
following warning in dmesg:
Failed to load DMC firmware i915/kbl_dmc_ver1_04.bin
So when installing firmware-misc-nonfree, this firmware file becomes available 
and is loaded correctly.
Unfortunately, this leads to the system crashing every few minutes.

I have narrowed it down to the following situation:
- When firmware-misc-nonfree is installed, but I delete or rename 
/lib/firmware/i915/kbl_dmc_ver1_04.bin, the system no longer crashes
- With i915/kbl_dmc_ver1_04.bin present and a monitor being connected and 
turned on, the system no longer crashes
- dmesg shows no relevant entry whatsoever, enabling kernel crash dumps crashes 
the system, but it does not reboot, also no entry in /var/crash

-- 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-11-amd64 (SMP w/6 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-misc-nonfree depends on no packages.

firmware-misc-nonfree recommends no packages.

Versions of packages firmware-misc-nonfree suggests:
ii  initramfs-tools  0.142

-- no debconf information

Bug#1050851: ITP: loupe -- An image viewer application written with GTK 4, Libadwaita and Rust.

[Matthias Geiger]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, jbi...@debian.org, 
pkg-gnome-maintain...@lists.alioth.debian.org, werdah...@riseup.net
Control: block -1 by 1017905

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: loupe
  Version : 45.beta.1
  Upstream Contact: Sophie Herold 
* URL : https.//gitlab.gnome.org/GNOME/loupe
* License : GPL-3+
  Programming Lang: Rust
  Description : An image viewer application written with GTK 4, Libadwaita 
and Rust.

Loupe is the new image viewer for GNOME starting with GNOME 45,
superseding Eye of GNOME. It's written in Rust. I have been
consistetenly packaging the remaining dependencies.

This package will be maintained with the Debian GNOME team.

thanks,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmTu/74VHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1m0kP+gKaotXsI7hQnqqOYgxMDlV39RVH
BUAjMsePreT157DGjKpDmUmhg7H3AIAz+DjZlOAsbGgmPXwhbkZ7306llbYRVwsE
7cCgMbJS8kyE50nWQiLz2J9RtEGWPRdXokSZDPSOLSHAhX7RR+uGmWcG2W4Z2N10
1XfDkZ7FxJ9tYtjVcyPPAXdME96Ukfi/DuFjopUfVfd8lfAHSGd4BL1vhubTrVNG
G1A7P0jVN3CkDrUHL7TZ2bZ4AyFR8Y10x+IsMeXywmwIWDP+NLMVL+jnxaDLWPKK
/lSo86s3yeKoqQAkT5QTn39rJu+jeg2iZMiFBrOSCDRc0JW4CXZ1NblT6PLfh866
bDiiZvIuugPeF+dvR4eGmw3Hs33glwfS7cbjgb6QhFCYbDezlvPNujLN6GSX9FqF
MBypGzCzv0lLnoakzibdng7cjcjD/u6rXbRvKh1KfZPIXuKZ96PoIJ5kT24Eo9rS
WTE83a1VtQgh4ypgmWDf3rMooZygmcXjzfXy3DjKxWN5qdirNgT4sj3Co1gVYf2G
hlqyeDnnA6bcluk3rc8uir7oJ0TMMkTJU40bINA55aMOnogfVmkdD8tIhVM4OrwM
b79/oYC2HVOxfABz8bp25jWTaA9gIx3fQCRXgGSwk+0rHunu0CfCxchM1MR+URaN
mIsptN8KSW8PBhlL
=EEpc
-END PGP SIGNATURE-

Bug#664141: fancontrol: service needs restarting after sleep

[Tobias Frost]

Package: fancontrol
Control: reopen -1
Control: found 1:3.6.0-8
Version: 1:3.6.0-8
Followup-For: Bug #664141

I've just experienced this behaviour on this (sid) machine,
only installed this week, where fancontrol controls the fan
of an ASRock RX 6x00 GPU card. The fan came on full speed after
leaving suspend and stayed there. The log indicates that fancontrol
had been restarted, exited with error:

Aug 30 09:48:47 isildor2 kernel: PM: suspend entry (deep)
(...)
Aug 30 09:48:56 isildor2 kernel: amdgpu :2d:00.0: amdgpu: Failed to set 
manual fan control mode
(...)
Aug 30 09:48:56 isildor2 kernel: amdgpu: manual fan speed control should be 
enabled first
Aug 30 09:48:56 isildor2 kernel: amdgpu: manual fan speed control should be 
enabled first
Aug 30 09:48:56 isildor2 systemd-sleep[223073]: System returned from sleep 
state.
Aug 30 09:48:56 isildor2 fancontrol[222841]: /usr/sbin/fancontrol: line 649: 
echo: write error: Invalid argument
Aug 30 09:48:56 isildor2 fancontrol[222841]: Error writing PWM value to 
/sys/class/hwmon/hwmon1/pwm1
Aug 30 09:48:56 isildor2 fancontrol[222841]: Aborting, restoring fans...
Aug 30 09:48:56 isildor2 fancontrol[222841]: Verify fans have returned to full 
speed
Aug 30 09:48:56 isildor2 systemd[1]: fancontrol.service: Main process exited, 
code=exited, status=1/FAILURE
Aug 30 09:48:56 isildor2 systemd[1]: fancontrol.service: Failed with result 
'exit-code'.
Aug 30 09:48:56 isildor2 systemd[1]: Starting atop.service - Atop advanced 
performance monitor...
Aug 30 09:48:56 isildor2 systemd[1]: Started atop.service - Atop advanced 
performance monitor.
Aug 30 09:48:56 isildor2 systemd[1]: systemd-suspend.service: Deactivated 
successfully.

It seems that the original fix of this bug is still prone to a race condition:
the restart attempts seems to happen before the IO gets ready to accept
manual fan mode.

My fix was to add a drop in to the fancontrol.service:

[Service]
Restart=on-failure


(This might even make /lib/systemd/system-sleep/fancontrol
obsolete; bonus is that if fancontrol crashes, it will also auto-restart,
possibly saving some hardware from overheating…)


-- 
Cheers,
tobi


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages fancontrol depends on:
ii  init-system-helpers  1.65.2

fancontrol recommends no packages.

fancontrol suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1050777: The surf autopkgtests are failing with webkitgtk 2.41

[Sebastien Bacher]

The MiniBrowser works fine and render webpages as expected

Starting surf with WEBKIT_DISABLE_COMPOSITING_MODE=1 set also workaround 
the issue and gives working rendering


Le 30/08/2023 à 01:53, Alberto Garcia a écrit :

On Tue, Aug 29, 2023 at 05:09:32PM +0200, Sebastien Bacher wrote:

And as a follow up it's not only an autopkgtest issue, surf fails to
render any webpage on my Ubuntu mantic system with the new webkitgtk
installed

I cannot reproduce the problem in Debian with libwebkit2gtk-4.1-0
2.41.91-1, it seems to work fine.

What happens if you use the MiniBrowser directly instead of surf?

$ /usr/lib/x86_64-linux-gnu/webkit2gtk-4.1/MiniBrowser https://www.debian.org/

Berto

Bug#1050832: sarsen: autopkgtest needs update for python-xarray 2023.08.0

[Graham Inggs]

Control: severity -1 serious
Control: tags -1 + ftbfs

As can be seen on reproducible builds [1], this same error causes
sarsen to FTBFS in unstable.


[1] https://tests.reproducible-builds.org/debian/rb-pkg/sarsen.html

Bug#1021607: debhelper: Also trim (or delete) NEWS.Debian.gz if changelog.Debian.gz is trimmed

[Gioele Barabucci]

Control: tags -1 patch

On Sun, 09 Oct 2022 19:37:12 +0200 "Francesco Poli (wintermute)" 
 wrote:

  W: apt-listbugs: debian-news-entry-has-unknown-version 0.1.14 
[usr/share/doc/apt-listbugs/NEWS.Debian.gz:1]
  N:
  N:   The version number of the most recent NEWS.Debian entry does not match 
any
  N:   of the version numbers in the changelog file for this package. This


A patch to fix this problem is available at

https://salsa.debian.org/debian/debhelper/-/merge_requests/110

--
Gioele Barabucci

Bug#1050850: writes files to /var/cache/apt-cacher-ng/var/cache/apt-cacher-ng

[Marc Haber]

Package: apt-cacher-ng
Version: 3.7.4-1+b2
Severity: normal

Hi,

on my apt-cacher-ng installation, I see directories like
/var/cache/apt-cacher-ng/var/cache/apt-cacher-ng/zg20150/dists/bookworm-zg-unstable
(zg20150 is a local repository created by reprepro that holds my backports).

I sometimes see files like InRelease.1692725238.head in those
directories, but apt-cacher-ng does seem to clean those up as probably
intended.

Is the doubled "/var/cache/apt-cacher-ng" an intended path or is that
double insertion of the CacheDir value that is not intended?

Greetings
Marc


-- Package-specific info:

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

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

Versions of packages apt-cacher-ng depends on:
ii  adduser3.134
ii  debconf [debconf-2.0]  1.5.82
ii  dpkg   1.21.22
ii  libbz2-1.0 1.0.8-5+b1
ii  libc-ares2 1.18.1-3
ii  libc6  2.36-9+deb12u1
ii  libevent-2.1-7 2.1.12-stable-8
ii  libevent-pthreads-2.1-72.1.12-stable-8
ii  libfuse2   2.9.9-6+b1
ii  libgcc-s1  12.2.0-14
ii  liblzma5   5.4.1-0.2
ii  libssl33.0.9-1
ii  libstdc++6 12.2.0-14
ii  libsystemd0252.12-1~deb12u1
ii  libwrap0   7.6.q-32
ii  sysvinit-utils [lsb-base]  3.06-4
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages apt-cacher-ng recommends:
ii  ca-certificates  20230311

Versions of packages apt-cacher-ng suggests:
pn  avahi-daemon  
pn  doc-base  

-- Configuration Files:
/etc/apt-cacher-ng/acng.conf changed:
CacheDir: /var/cache/apt-cacher-ng
LogDir: /var/log/apt-cacher-ng
SupportDir: /usr/lib/apt-cacher-ng
Port:13142
Remap-debrep: file:deb_mirror*.gz /debian ; file:backends_debian # Debian 
Archives
Remap-uburep: file:ubuntu_mirrors /ubuntu ; file:backends_ubuntu # Ubuntu 
Archives
Remap-klxrep: file:kali_mirrors /kali ; file:backends_kali # Kali Linux Archives
Remap-cygwin: file:cygwin_mirrors /cygwin # ; file:backends_cygwin # 
incomplete, please create this file or specify preferred mirrors here
Remap-sfnet:  file:sfnet_mirrors # ; file:backends_sfnet # incomplete, please 
create this file or specify preferred mirrors here
Remap-alxrep: file:archlx_mirrors /archlinux # ; file:backend_archlx # Arch 
Linux
Remap-fedora: file:fedora_mirrors # Fedora Linux
Remap-epel:   file:epel_mirrors # Fedora EPEL
Remap-slrep:  file:sl_mirrors # Scientific Linux
Remap-gentoo: file:gentoo_mirrors.gz /gentoo ; file:backends_gentoo # Gentoo 
Archives
Remap-secdeb: security.debian.org security.debian.org/debian-security 
deb.debian.org/debian-security /debian-security ; 
deb.debian.org/debian-security security.debian.org
Remap-debian: debian ; debian.apt-cache.zugschlus.de/debian
Remap-debiansecurity: debian-security ; 
debian-security.apt-cache.zugschlus.de/debian-security
Remap-zg20150: zg20150 ; zg20150.apt-cache.zugschlus.de/zg20150
ReportPage: acng-report.html
ExThreshold: 4
LocalDirs: acng-doc /usr/share/doc/apt-cacher-ng

/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
'/etc/apt-cacher-ng/security.conf'
/etc/logrotate.d/apt-cacher-ng changed:
/var/log/apt-cacher-ng/apt-cache*.log {
su apt-cacher-ng apt-cacher-ng
weekly
missingok
rotate 4
nomail
compress
delaycompress
notifempty
create
prerotate
find /var/log/apt-cacher-ng -maxdepth 1 -type f -name 
'apt-cache*.log*' -ls > /home/mh/varlogaptcacherngaptcachelog-findls-$(date 
+%Y%m%d%H%M) | sort -k11
endscript
postrotate
if [ -e /run/systemd/system ] ; then
if systemctl -q is-active apt-cacher-ng ; then 
systemctl kill --signal=USR1 apt-cacher-ng ; fi
elif [ -s /var/run/apt-cacher-ng/pid ] ; then
kill -s USR1 "$(cat /var/run/apt-cacher-ng/pid)" 
2>/dev/null ||:
fi
endscript
}
/var/log/apt-cacher-ng/apt-cache*.err {
su apt-cacher-ng apt-cacher-ng
weekly
notifempty
missingok
nomail
rotate 4
compress
delaycompress
create
prerotate
find /var/log/apt-cacher-ng -maxdepth 1 -type f -name 
'apt-cache*.err*' -ls > /home/mh/varlogaptcacherngaptcacheerr-findls-$(date 
+%Y%m%d%H%M) | sort -k11
endscript
postrotate
if [ -e /run/systemd/system ] ; then
if systemctl -q is-active apt-cacher-ng ; then 
systemctl kill --signal=USR1 apt-cacher-ng ; fi

Bug#1029203: Fix for serious bug needs package in new (r-cran-gfonts)

[Andreas Tille]

Hi Thorsten,

I'm pinging RC bugs to avoid testing removal, accepting this package
would help quite a chain of reverse depends.

Kind regards and thanks for your work as ftpmaster
 Andreas.

Am Fri, Aug 18, 2023 at 07:21:47AM +0200 schrieb Andreas Tille:
> Control: block -1 by 1029203
> 
> Hi,
> 
> the new version of flextable works together with recent r-cran-bookdown.
> Unfortunately r-cran-flextable (0.9.2-1) implizitly depends from
> r-cran-gfonts (ITP #1029203) which takes its second round in new [1].
> It would help if this package could get preference to fix this RC bug.
> 
> Kind regards
> Andreas.
> 
> [1] https://ftp-master.debian.org/new/r-cran-gfonts_0.2.0-1.html
> 
> -- 
> http://fam-tille.de

-- 
http://fam-tille.de

Bug#719897: pretty much moot now

[Barak A. Pearlmutter]

This issue is now pretty much moot, since by default

$ sysctl fs.inotify.max_user_watches
fs.inotify.max_user_watches = 65536

and 64K "should be enough for anyone."

Bug#1042896: transition: armadillo

[Sebastiaan Couwenberg]

Control: block -1 by 1028633

On 8/30/23 09:13, Kumar Appaiah wrote:

I could not build mlpack since the build failed, but I am sure it's
not due to pip. Here is the extract from the failed build log:

-- After much of the build
mkdir: cannot create directory '/usr/lib/python3.11/site-packages/':
Permission denied /usr/bin/python3: No module named pip
CMake Error at
/build/mlpack-4.1.0/src/mlpack/bindings/python/PythonInstall.cmake:23
(message):
   Error installing Python bindings!
Call Stack (most recent call first):
   src/mlpack/bindings/python/cmake_install.cmake:66 (include)
   src/mlpack/bindings/cmake_install.cmake:50 (include)
   src/mlpack/cmake_install.cmake:68 (include)
   cmake_install.cmake:55 (include)


That's a known issue: #1028633

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1050849: creduce upstream homepage

[Mathieu Malaterre]

Source: creduce
Version: 2.11.0~20230819-1

Could someone please document where creduce homepage is located nowadays.

http://embed.cs.utah.edu/creduce/ seems to be gone.

I am not clear what to do with reports such as:

===< pass_clang_binsrch :: replace-function-def-with-decl >===
Segmentation fault

***

pass_clang_binsrch::replace-function-def-with-decl has encountered a bug:
crashed: "/usr/libexec/clang_delta"
--transformation=replace-function-def-with-decl --counter=1
--to-counter=25 /tmp/creduce-2sfsbN/mul_test.cc

Please consider tarring up /home/malat/creduce_bug_000
and mailing it to creduce-b...@flux.utah.edu and we will try to fix
the bug.

This bug is not fatal, C-Reduce will continue to execute.

***

===< pass_clang_binsrch :: remove-unused-function >===

Thank you !