Bug#1013356: fzf: Bash completions not active by default

[Bastian Venthur]

Package: fzf
Version: 0.42.0-1+b3
Followup-For: Bug #1013356
X-Debbugs-Cc: vent...@debian.org

Dear Maintainer,

there's also this weird behaviour, that wile bash completion is not enabled by
default, it will be enabled once you do:

fzf **

after that a

cd **

works as expected. If bash completion is not enabled on purpose, I would
consider this behaviou a bug. But I believe just enabling the bash completion
by default would be the better solution.


Cheers,

Bastian



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

Kernel: Linux 6.5.0-4-amd64 (SMP w/16 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 fzf depends on:
ii  libc6  2.37-12

fzf recommends no packages.

fzf suggests no packages.

-- no debconf information

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Ilias Tsitsimpis]

On Thu, Nov 16, 2023 at 10:16PM, Jonas Smedegaard wrote:
> Quoting John MacFarlane (2023-11-16 19:25:17)
> > Removing lua support would be most unfortunate!  If you need help from 
> > upstream in getting things to work, let me know.
> 
> I agree: Pandoc with its core scripting language disabled is a severely
> crippled Pandoc.

Understood, but I am not really sure how to move forward, since Pandoc
doesn't fully support the latest Stackage LTS. I can help with
packaging/upgrade libraries if you can provide the right set of
libraries we need.

-- 
Ilias

Bug#1054663: telegram-send: Fails to run

[Dale Richards]

> Versions of packages telegram-send depends on:
> ii  python3-python-telegram-bot  13.15-1

Here's the problem. The packaged version of telegram-send depends on changes to 
telegram/constants.py that were introduced in python-telegram-bot 14.0:
https://github.com/python-telegram-bot/python-telegram-bot/pull/2708

Currently python-telegram-bot 13.15 is packaged in sid, so we need to update 
this (and the depends of telegram-send) to fix this bug.

Best regards,
Dale Richards

Bug#1042428: lintian.debian.org off ?

[Otto Kekäläinen]

Hi!

On Wed, 27 Sept 2023 at 13:27, Lucas Nussbaum  wrote:
>
> Hi,
>
> #1042428 is the bug for "no explanation for lintian tags on UDD"
>
> On 26/09/23 at 21:35 -0700, Otto Kekäläinen wrote:
> > I know Lintian tag info is available via command line, but I
> > frequently need to educate upstreams about Lintian rules, and thus
> > really also need a URL to share to them. Perhaps I could implement
> > that later in the year.
>
> That's indeed a good rationale for adding a web interface to lintian
> tags explanations. Thanks.
>
> I still plan to work on adding that eventually.

This issue still exists. I would now have the need to send the url
https://lintian.debian.org/tags/service-file-is-not-a-file to upstream
developers to learn about this Lintian issue, but the URL does not
serve any contents nor does it redirect to a new location.

I am still willing to contribute the Apache/Nginx rewrite rules if
somebody can point me to a code repository where I can read/contribute
at like I announced on September 27th in this thread.

- Otto

Bug#1056113: xscreensaver: Please update xscreensaver to version 6.08

[Benjamin]

Package: xscreensaver

Version: 6.06+dfsg1-3

Severity: wishlist

X-Debbugs-CC: k...@benj.dropbear.id.au


Please update the Debian xscreensaver package to the latest 6.08 
version. This version adds some new hacks and fixes bugs in existing ones.


Thanks

Bug#1056065: transition: spdlog

[Andrius Merkys]

On 2023-11-17 08:42, Sebastian Ramacher wrote:
I suspect that's due to the use of libspdlogX-fmtY. I've added a manual 
tracker and added the fmt postfix.


Right, this might be the reason. Thanks!

Andrius

Bug#1055891: transition: gdal

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2023-11-13 18:53:40 +0100, Bas Couwenberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: g...@packages.debian.org
> Control: affects -1 + src:gdal
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-gdal.html
> Control: block -1 by 1051433
> 
> For the Debian GIS team I'd like to transition to GDAL 3.8.0.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1056065: transition: spdlog

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2023-11-16 18:01:01 +0200, Andrius Merkys wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: cru...@debian.org
> 
> Hello,
> 
> I would like to request a transition slot for spdlog (experimental ->
> unstable) due to soname bump.

Please go ahead.

> Ben tracker was not set up automatically, thus
> its file should look like this:
> 
> is_affected = .depends ~
> /\b(libspdlog\-dev|libspdlog1\.10|libspdlog1\.12)\b/;
> is_good = .depends ~ /\b(libspdlog\-dev|libspdlog1\.12)\b/;
> is_bad = .depends ~ /\b(libspdlog1\.10)\b/;

I suspect that's due to the use of libspdlogX-fmtY. I've added a manual
tracker and added the fmt postfix.

Cheers
-- 
Sebastian Ramacher

Bug#1055600: transition: suitesparse-7.3

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2023-11-08 18:00:20 +0100, Sébastien Villemot wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-suitesparse.html
> 
> Dear Release Team,
> 
> Please schedule a transition for suitesparse 7.3, which currently sits in
> experimental.
> 
> One the shared libraries got a SOVERSION bump (libcholmod4 → libcholmod5). The
> ABI change is minor and I’m therefore fairly confident that there won’t be any
> issue.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#946434: problems on phones

[Russell Coker]

Pressing backspace to undo works fine on a desktop PC or laptop but fails on a 
phone with soft keyboard.

The solution that is needed for this is a button in the app for undo.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#1056065: transition: spdlog

[Andrius Merkys]

On Thu, 16 Nov 2023 18:01:01 +0200 Andrius Merkys  wrote:

* kodi (seems to be affected by spdlog API change)


Sorry, kodi builds fine, it should not be here, my mistake.

Best,
Andrius

Bug#1056111: bpfcc ftbfs with LLVM 17

[Matthias Klose]

Package: src:bpfcc
Version:  0.26.0+ds-1
Severity: important
Tags: sid trixie

bpfcc ftbfs with LLVM 17:

[...]
[ 69%] Building CXX object src/cc/CMakeFiles/bcc-shared.dir/bcc_btf.cc.o
cd /<>/obj-x86_64-linux-gnu/src/cc && /usr/bin/c++ 
-DEXPORT_USDT -DHAVE_EXTERNAL_LIBBPF -Dbcc_shared_EXPORTS 
-I/usr/lib/llvm-17/include/../tools/clang/include -I/<>/src 
-I/<>/obj-x86_64-linux-gnu/src 
-I/<>/obj-x86_64-linux-gnu/src/cc -I/<>/src/cc 
-I/<>/obj-x86_64-linux-gnu/src/cc/frontends/b 
-I/<>/src/cc/frontends/b 
-I/<>/src/cc/frontends/clang -I/usr/lib/llvm-17/include 
-I/<>/src/cc/compat -g -O2 
-ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection 
-fdebug-prefix-map=/<>=/usr/src/bpfcc-0.26.0+ds-1ubuntu3 
-Wdate-time -D_FORTIFY_SOURCE=2 -DCUSTOM_MACRO=true -Wall  -fno-rtti 
-fPIC -DBCC_PROG_TAG_DIR='"/var/tmp/bcc"' -Wno-unused-result 
-DLLVM_MAJOR_VERSION=17 -std=gnu++17 -fPIC -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-MD -MT src/cc/CMakeFiles/bcc-shared.dir/bcc_btf.cc.o -MF 
CMakeFiles/bcc-shared.dir/bcc_btf.cc.o.d -o 
CMakeFiles/bcc-shared.dir/bcc_btf.cc.o -c /<>/src/cc/bcc_btf.cc
/<>/src/cc/bpf_module.cc:20:10: fatal error: 
llvm-c/Transforms/IPO.h: No such file or directory

   20 | #include 
  |  ^
compilation terminated.
make[3]: *** [src/cc/CMakeFiles/bcc-shared.dir/build.make:107: 
src/cc/CMakeFiles/bcc-shared.dir/bpf_module.cc.o] Error 1

Bug#1056110: ldc ftbfs with LLVM 17

[Matthias Klose]

Package: src:ldc
Version:  1:1.35.0-1
Severity: important
Tags: sid trixie

ldc ftbfs with LLVM 17:

[...]
[  0%] Building CXX object CMakeFiles/LDCShared.dir/gen/aa.cpp.o
/usr/bin/c++ -DLDC_ENABLE_PLUGINS -DLDC_LLVM_SUPPORTED_TARGET_AArch64=1 
-DLDC_LLVM_SUPPORTED_TARGET_AMDGPU=1 -DLDC_LLVM_SUPPORTED_TARGET_ARM=1 
-DLDC_LLVM_SUPPORTED_TARGET_AVR=1 -DLDC_LLVM_SUPPORTED_TARGET_BPF=1 
-DLDC_LLVM_SUPPORTED_TARGET_Hexagon=1 
-DLDC_LLVM_SUPPORTED_TARGET_Lanai=1 
-DLDC_LLVM_SUPPORTED_TARGET_LoongArch=1 
-DLDC_LLVM_SUPPORTED_TARGET_M68k=1 -DLDC_LLVM_SUPPORTED_TARGET_MSP430=1 
-DLDC_LLVM_SUPPORTED_TARGET_Mips=1 -DLDC_LLVM_SUPPORTED_TARGET_NVPTX=1 
-DLDC_LLVM_SUPPORTED_TARGET_PowerPC=1 
-DLDC_LLVM_SUPPORTED_TARGET_RISCV=1 -DLDC_LLVM_SUPPORTED_TARGET_Sparc=1 
-DLDC_LLVM_SUPPORTED_TARGET_SystemZ=1 -DLDC_LLVM_SUPPORTED_TARGET_VE=1 
-DLDC_LLVM_SUPPORTED_TARGET_WebAssembly=1 
-DLDC_LLVM_SUPPORTED_TARGET_X86=1 -DLDC_LLVM_SUPPORTED_TARGET_XCore=1 
-DLDC_LLVM_SUPPORTED_TARGET_Xtensa=1 -I/<>/. 
-I/<>/dmd -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection 
-fdebug-prefix-map=/<>=/usr/src/ldc-1:1.35.0-1ubuntu2 
-Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -DDMDV2 
-I/usr/lib/llvm-17/include -std=c++17   -fno-exceptions -funwind-tables 
-D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -fno-rtti  -Wall -Wextra -Wno-unused-parameter 
-Wno-comment -Wno-missing-field-initializers -Wno-non-virtual-dtor 
-Wno-pedantic -DLDC_POSIX  -DIN_LLVM -DOPAQUE_VTBLS 
"-DLDC_INSTALL_PREFIX=R\"(/usr)\"" -DLDC_LLVM_VER=1700 
"-DLDC_LIBDIR_SUFFIX=R\"()\"" -DLDC_HOST_GDMD=1 -DLDC_HOST_FE_VER=2103 
"-DLDC_LLVM_LIBDIR=R\"(/usr/lib/llvm-17/lib)\""  -DNDEBUG -MD -MT 
CMakeFiles/LDCShared.dir/gen/aa.cpp.o -MF 
CMakeFiles/LDCShared.dir/gen/aa.cpp.o.d -o 
CMakeFiles/LDCShared.dir/gen/aa.cpp.o -c /<>/gen/aa.cpp

In file included from /<>/./dmd/tokens.h:15,
 from /<>/./gen/aa.h:16,
 from /<>/gen/aa.cpp:10:
/<>/./dmd/globals.h:20:10: fatal error: llvm/ADT/Triple.h: 
No such file or directory

   20 | #include "llvm/ADT/Triple.h"
  |  ^~~
compilation terminated.
make[4]: *** [CMakeFiles/LDCShared.dir/build.make:79: 
CMakeFiles/LDCShared.dir/gen/aa.cpp.o] Error 1

Bug#1056109: util-linux: Broken packages when building with

[Gioele Barabucci]

Package: src:util-linux
Version: 2.39.2-6
Tags: patch

Dear util-linux maintainers,

Building util-linux with  generates invalid packages (for example 
they contain broken symlinks to missing manpages).


Also, even when the  build profile is used, `asciidoctor` remains 
a required build dependency.


A MR that fixes these issues is available at:

https://salsa.debian.org/debian/util-linux/-/merge_requests/27

Regards,

--
Gioele Barabucci

Bug#1036165: ITP: atuin -- Rich shell history using a SQLite database with optional encrypted sync

[Blair Noctis]

On 2023-11-16 16:02, Arturo Borrero Gonzalez wrote:
> Hi there,
> 
> thanks for working on this.
> 
> Do you have a repository where you are developing this?
> 
> regards.

Hi,

I'm afraid the work has stalled. I don't want to upload the half (or rather,
1/10) baked draft. I do still intend to package it but now with a low priority.
Feel free to take it if you have the time, or mark it as RFP.

-- 
Sdrager,
Blair Noctis



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056059: dracut: systemd 255: dracut fails to boot due to lack of systemd-executor

[Michael Biebl]

I've filed a corresponding bug report against systemd, so users are 
notified of this issue and the package doesn't migrate to testing 
prematurely:


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


We will add a versioned Breaks against dracut to systemd to ensure that 
dracut users do not accidentally upgrade.



Sorry for the breakage.
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056066: systemd: rsyslog fails to start if /dev/xconsole exists

[Michael Biebl]

Control: reassign -1 rsyslog
Control: found -1 8.2310.0-2

Am 16.11.23 um 19:53 schrieb Sven Joachim:

On 2023-11-16 18:12 +0100, Michael Biebl wrote:


Am 16.11.23 um 17:17 schrieb Sven Joachim:
It appears, that PrivateTmp=yes was locked down further and is now
remounted read-only (thanks bluca for the reference):
https://github.com/systemd/systemd/commit/4a9e03aa6bb2cbd23dac00f2b2a7642cc79eaade


Thanks, I had suspected something along these lines.



It's unlikely that systemd upstream is going to revert this behaviour 
change, so I'm going to reassign this issue to rsyslog to handle it there.



We basically have two options as I see it:

a/ Drop PrivateDevices=yes from rsyslog.service

b/ Move /dev/xconsole to run and turn /dev/xconsole into a symlink


The latter b/ will require updates to the local copies in
/etc/tmpfiles.d/ and /etc/rsyslog.d/

They would look like this now:

$ cat /etc/rsyslog.d/xconsole.conf
daemon.*;mail.*;\
news.err;\
*.=debug;*.=info;\
*.=notice;*.=warn   |/run/xconsole

$ cat /etc/tmpfiles.d/xconsole.conf
# Type Path Mode UID  GID  Age Argument
p /run/xconsole 0640 root adm
L /dev/xconsole ----   /run/xconsole

Conceptually, moving the named pipe out of /dev and into /run is the
cleaner solution I think. The /dev/xconsole symlink should make it
reasonably backwards compatible.

Thoughts?


I think b/ and an appropriate debian/NEWS entry in rsyslog are
preferable to softening security, even if it means some disruption for
the minority of users who still monitor logs via xconsole.  But there
may be more complaints once the changes arrive in testing.



Since b/ is my favorite as well, let's go with this.


Personally I have made your proposed changes, and after restarting
rsyslog and xconsole everything works fine again.


Thanks for testing.

Will poke you, once I have a MR ready. Maybe you want to proof read the 
NEWS entry.


Regards,
Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056108: v255 breaks boot with dracut

[Michael Biebl]

Package: systemd
Version: 255~rc2-1
Severity: serious

The addition of systemd-executor breaks dracut in a bad way.
It generates an unbootable initrd.

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

Filing with RC severity to notify users and to prevent testing
migration.

We should add a (versioned) Breaks against dracut to ensure that dracut
users do not end up with an unbootable system.


Michael

Bug#1056107: Nettle: please run valgrind tests during build

[Daniel Kahn Gillmor]

Package: src:nettle
Version: 3.9.1-2
Tags: patch

in Message-ID: cpffs17kwvd@shipon.lysator.liu.se on the nettle-bugs
mailing list, Niels Möller observed some new tests to identify
side-channel silence that depend on valgrind, but their CI is only
running on x86-64.

It looks to me like none of the valgrind tests are being run during
build on the debian buildd network.  It could help the upstream project
to get verified valgrind results.

The attached patch runs the valgrind tests during build, but i also note
that it causes a build failure on amd64 platforms, because of what
appears to be data-dependent branching during RSA decryption.  I've
raised that concern on the upstream nettle-bugs mailing list (and Cc'ed
Magnus) to try to figure out what we should do to avoid this negative
result.  So it's probably not safe yet to just apply this patch
unilaterally (at least not in unstable -- maybe in experimental for now
to get records from the various build daemons that build experimental?)

But the fact that there is a negative result which the current build
process doesn't catch suggests that we should probably be running the
tests in more detail.

  --dkg

commit 036e3794b169f8b0bfe306bc6db1ac47d9527da7
Author: Daniel Kahn Gillmor 
Date:   Wed Nov 15 12:45:19 2023 -0500

Run tests under valgrind during build

diff --git a/debian/control b/debian/control
index ce51f75b..c16150b5 100644
--- a/debian/control
+++ b/debian/control
@@ -8,6 +8,7 @@ Build-Depends:
  libgmp-dev,
  m4,
  texinfo,
+ valgrind ,
 Standards-Version: 4.6.2
 Vcs-Git: https://salsa.debian.org/holmgren/nettle.git
 Vcs-Browser: https://salsa.debian.org/holmgren/nettle
diff --git a/debian/rules b/debian/rules
index 3a59ce2b..ff708b22 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,3 +11,6 @@ override_dh_installdocs:
 
 override_dh_auto_configure:
 	dh_auto_configure -- --enable-fat
+
+execute_after_dh_auto_test:
+	dh_auto_test -- EMULATOR='$$(VALGRIND)'


signature.asc
Description: PGP signature

Bug#1039142: busybox: ships sysv-init script without systemd unit

[Michael Biebl]

Am 17.11.23 um 02:54 schrieb Michael Biebl:


That should do:



[snip patch]

oops, dropped one line too much from debian/rules.

Fixed patch attached.

diff --git a/debian/rules b/debian/rules
index 04018718b..b24b8f46f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -176,5 +176,4 @@ override_dh_installsystemd-indep:
 # explicitly list all packages with .service files here
dh_installsystemd -pbusybox-syslogd --name=busybox-klogd
dh_installsystemd -pbusybox-syslogd
-# the following does not work (see #1039142 for details):
-#  dh_installsystemd -pudhcpd --no-enable --no-start
+   dh_installsystemd -pudhcpd --no-enable
diff --git a/debian/udhcpd.service b/debian/udhcpd.service
index 0cdc24bc7..0d01d9722 100644
--- a/debian/udhcpd.service
+++ b/debian/udhcpd.service
@@ -1,7 +1,7 @@
 [Unit]
 Description=Busybox udhcpd DHCP daemon
 Documentation=man:udhcpd(8)
-After=syslog.service network.target
+After=network.target
 
 [Service]
 Environment=DHCPD_OPTS="-S"


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1039142: busybox: ships sysv-init script without systemd unit

[Michael Biebl]

On Tue, 14 Nov 2023 17:41:23 +0300 Michael Tokarev  wrote:

14.11.2023 14:56, Luca Boccassi wrote:
> On Mon, 13 Nov 2023 18:42:09 +0300 Michael Tokarev 
> wrote:
..

>> With just dh_installsystemd --no-enable, it is still started.
>> With dh_installsystemd --no-enable --no-start, it is started
>> as well, - apparently because initscript is started.  Also,
>> with --no-enable --no-start, it is not restarted on upgrades
>> if enabled locally.
>>
>> After doing several iterations, I decided to abandon this attempt, -
>> it just does not work, and I've no time to fight with the tools.
>>
>> If someone has a working recipe for all this madness, please
>> share a patch for d/rules.
>>
>> Tagging with "help" for now.
> 
> Could you please share a branch or a patch with your attempt? What you

> tried should work, but it's hard to say without looking at the
> implementation in details.

Sure thing, it is in current busybox master on salsa, here:

https://salsa.debian.org/installer-team/busybox/-/blob/master/debian/rules#L172

with udhcpd.service & udhcpd.init in the same dir.



That should do:


diff --git a/debian/rules b/debian/rules
index 04018718b..54e5cc225 100755
--- a/debian/rules
+++ b/debian/rules
@@ -175,6 +175,4 @@ execute_before_dh_installinit-indep:
 override_dh_installsystemd-indep:
 # explicitly list all packages with .service files here
dh_installsystemd -pbusybox-syslogd --name=busybox-klogd
-   dh_installsystemd -pbusybox-syslogd
-# the following does not work (see #1039142 for details):
-#  dh_installsystemd -pudhcpd --no-enable --no-start
+   dh_installsystemd -pudhcpd --no-enable
diff --git a/debian/udhcpd.service b/debian/udhcpd.service
index 0cdc24bc7..0d01d9722 100644
--- a/debian/udhcpd.service
+++ b/debian/udhcpd.service
@@ -1,7 +1,7 @@
 [Unit]
 Description=Busybox udhcpd DHCP daemon
 Documentation=man:udhcpd(8)
-After=syslog.service network.target
+After=network.target

 [Service]
 Environment=DHCPD_OPTS="-S"



Only "--no-enable" is necessary. disabled services won't be (re)started.
Once enabled by the user, future package upgrades will restart the service.

I've also dropped After=syslog.service as syslog is socket activated by 
default, so this is not necessary.



root@pluto:~# apt install /tmp/udhcpd_1.36.1-5_all.deb
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'udhcpd' instead of '/tmp/udhcpd_1.36.1-5_all.deb'
The following NEW packages will be installed:
  udhcpd
0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
Need to get 0 B/12.4 kB of archives.
After this operation, 51.2 kB of additional disk space will be used.
Get:1 /tmp/udhcpd_1.36.1-5_all.deb udhcpd all 1:1.36.1-5 [12.4 kB]
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Selecting previously unselected package udhcpd.
(Reading database ... 403057 files and directories currently installed.)
Preparing to unpack /tmp/udhcpd_1.36.1-5_all.deb ...
Unpacking udhcpd (1:1.36.1-5) ...
Setting up udhcpd (1:1.36.1-5) ...
udhcpd.service is a disabled or a static unit, not starting it.
Processing triggers for man-db (2.12.0-1) ...

root@pluto:~# systemctl status udhcpd.service
○ udhcpd.service - Busybox udhcpd DHCP daemon
 Loaded: loaded (/usr/lib/systemd/system/udhcpd.service; disabled; 
preset: enabled)

 Active: inactive (dead)
   Docs: man:udhcpd(8)





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053955: rust-toml: please update to v0.7.8

[Peter Green]

On 16/11/2023 18:41, Jonas Smedegaard wrote:

Quoting Peter Green (2023-11-16 10:55:33)

Please update to (at least) newer upstream release v0.7.8.

toml itself is not semver-breaking, but it's closely coupled dependency
toml_edit is.

[...]

My overall conclusion is that btm is the main blocker. Jonas, btm is one
of your packages, can you work with upstream to prepare and test an update?

Updated versions of toml_edit and toml are availble in experimental for
you to test with.

Please go ahead without waiting for btm: Upstream has swiftly responded
with an uncomplicated change.

Sorry I screwed up with my earlier analysis. I mixed up toml 0.7.8
with toml 0.8.8. Only the latter requires the new toml_edit. So it
seems I won't be semver bumping toml_edit at this time after all.

Bug#1056106: nss: Please enable Salsa CI

[Santiago Ruano Rincón]

Source: nss
Version: 2:3.94-1
Severity: wishlist
Tags: patch

Dear nss maintainers,

Could you please enable the Salsa CI's Pipeline for nss? This would
allow to automate testing how nss builds and run some tests, as
autopkgtest, lintian, reprotest, among others.

Please consider the following merge request:
https://salsa.debian.org/mozilla-team/nss/-/merge_requests/7

Cheers,

Santiago


signature.asc
Description: PGP signature

Bug#1056105: bullseye-pu: package libsolv/0.7.17-1+deb11u1

[Luca Boccassi]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
Both Fedora Rawhide and SUSE Tumbleweed started to compress their
respective RepoData with zstd. The libsolv version in bullseye is not
build with zstd support, so using zypper/dnf in bullseye to build a new
Fedora/SUSE chroot started to fail this week.

[ Impact ]
$ mkdir -p repos.d img
$ cat 
Building repository 'test.repo' cache 
.[error]
Error building the cache:
[test.repo|https://download.opensuse.org/tumbleweed/repo/oss/] Failed to cache 
repo (1).
History:
 - 'repo2solv' '-o' '/tmp/img/var/cache/zypp/solv/test.repo/solv' '-X' 
'/tmp/img/var/cache/zypp/raw/test.repo'
   
/tmp/img/var/cache/zypp/raw/test.repo/repodata/d6fbf1152bab99fc7ceacf974422a9799694274b64c36015b10288e6cabadd81e4649b19f52570efc5f3ab5b28817c9561fa8eeca117a05f3caea6c33e48cb69-primary.xml.zst:
 No such file or directory
   Command exited with status 1.

[ Tests ]
libsolv in bullseye already supports zstd, but it is not enabled. The
fix is simply to build-depend on libzstd and enable the relevant cmake
flag, and then it works:

$ zypper --reposd-dir=/tmp/repos.d --root=/tmp/img --gpg-auto-import-keys 
install distribution-release filesystem
Building repository 'mkosi.repo' cache 
.[done]
Loading repository data...
Reading installed packages...
'distribution-release' not found in package names. Trying capabilities.
Resolving package dependencies...

The following 20 NEW packages are going to be installed:
  bash bash-sh compat-usrmerge-tools filesystem glibc glibc-extra libgcc_s1 
libncurses6 libpcre2-8-0 libreadline8
  libselinux1 libstdc++6 ncurses-utils openSUSE-release 
openSUSE-release-appliance-custom
  patterns-glibc-hwcaps-x86_64_v3 system-user-root terminfo-base 
terminfo-screen timezone

The following 4 recommended packages were automatically selected:
  glibc-extra ncurses-utils terminfo-screen timezone

The following 9 packages are suggested, but will not be installed:
  branding-openSUSE distribution-logos-openSUSE-Tumbleweed java-11-openjdk 
mariadb mariadb-client openssl-1_1
  openSUSE-build-key openSUSE-repos-Tumbleweed procps

20 new packages to install.
Overall download size: 7.3 MiB. Already cached: 0 B. After the operation, 
additional 16.3 MiB will be used.
Continue? [y/n/v/...? shows all options] (y): y
<...>
$ cat img/usr/lib/os-release 
NAME="openSUSE Tumbleweed"
# VERSION="20231114"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20231114"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20231114"
BUG_REPORT_URL="https://bugzilla.opensuse.org;
SUPPORT_URL="https://bugs.opensuse.org;
HOME_URL="https://www.opensuse.org;
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed;
LOGO="distributor-logo-Tumbleweed"

[ Risks ]
Minimal, support for zstd is old and the change is simply a new build
dependency and build flag. Worst case scenario is that zstd doesn't
work, and the situation is not any different from status quo.

[ 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

[ Other info ]
I have already updated this change. It is fixed in the latest unstable
upload as well. I am also proposing the same fix for bookworm and
Ubuntu stable releases:

https://bugs.launchpad.net/ubuntu/+source/libsolv/+bug/2043625

-- 
Kind regards,
Luca Boccassi
diff -Nru libsolv-0.7.17/debian/changelog libsolv-0.7.17/debian/changelog
--- libsolv-0.7.17/debian/changelog	2021-02-01 20:04:46.0 +
+++ libsolv-0.7.17/debian/changelog	2023-11-16 23:25:47.0 +
@@ -1,3 +1,10 @@
+libsolv (0.7.17-1+deb11u1) bullseye; urgency=medium
+
+  [ Sjoerd Simons ]
+  * Enable libzstd compression support
+
+ -- Luca Boccassi   Thu, 16 Nov 2023 23:25:47 +
+
 libsolv (0.7.17-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libsolv-0.7.17/debian/control libsolv-0.7.17/debian/control
--- libsolv-0.7.17/debian/control	2020-12-19 12:58:21.0 +
+++ libsolv-0.7.17/debian/control	2023-11-16 23:25:33.0 +
@@ -13,6 +13,7 @@
  librpm-dev (>= 4),
  liblzma-dev,
  libbz2-dev,
+ libzstd-dev,
  python3-dev,
  libpython3-dev,
  swig,
diff -Nru libsolv-0.7.17/debian/rules libsolv-0.7.17/debian/rules
--- libsolv-0.7.17/debian/rules	2020-12-19 12:58:21.0 +
+++ libsolv-0.7.17/debian/rules	2023-11-16 23:25:33.0 +
@@ -47,6 

Bug#1056103: dgit fills up my disk with .git/dgit/unpack directories

[gregor herrmann]

On Thu, 16 Nov 2023 22:31:44 +, Ian Jackson wrote:

> Hi.  Thanks for the report.  I'm sorry that you're finding dgit has
> done xsomething inconvenient.

Thanks for the quick reply!
 
> gregor herrmann writes ("Bug#1056103: dgit fills up my disk with 
> .git/dgit/unpack directories"):
> > Recently I noticed that my usage of `dgit --gbp push-source' leaves
> > .git/dgit/unpack directories in each touched package directory. Which
> > in my case amounts to 1.5 GB below my pkg-perl directory (for more
> > than 1100 dgit-pushed packages since 2019).
> Ah.  I hadn't really considered this kind of use case.  (I obviously
> touch smaller packages, or fewer different packges, or sometbing.)

Yeah, I touch a lot of packages, and it took me some years to find
this issue :)
 
> I think the wasted space ought to be be O(the size of the source
> package), although constant factor may be 2 or 3.  Is this not the
> case for you ?  If there are cases where dgit has wasted much more
> space then that would be straightforwardly buggy I think.

Ack, from what I see, the contents of .git/dgit/unpack is one (the
current) tarball plus the unpacked upstream source.
It's just that this accumulates over > 1000 (potentially 4000 in the
pkg-perl case) packages to some GB.
 
> You're right that these directories are not really needed after dgit
> has completed.  

Great, thanks for the confirmation.

> However, they can be useful for debugging failures.

Hm, yeah, so maybe this "keep temporary artifacts" should be opt-in?

> Another future run of dgit would remove it of course, but would just
> leave another one.  And there's no central tracking and they're hidden
> in .git so you wouldn't normally see them and know to delete them.

Indeed, it took me some years to detect them :)
 
> So, yes, I can see the problem and I agree that something better
> should be done.

Cool, thanks.
 
> I think there are some tradeoffs involved, so may not entirely
> straightforward.  Some thought will be needed.  (Some of the things in
> .git/dgit are hardlinked from elsewhere, so it's not as simple as
> using TMPDIR instead.)

Oh, sure -- from my wild guessing I saw files in .git/dgit which
looked relevant and are also small; but one level below,
.git/dgit/unpack is the thing which needs space …
 
> Perhaps dgit should, by default, clean up this stuff just before it
> exits successfully, but leave it behind for debugging failures.

That sounds very reasonable to me.


Thanks again,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1056104: libreoffice: please enable ENABLE_WASM_STRIP_PINGUSER

[Cyril Brulebois]

Source: libreoffice
Version: 1:7.0.4-4+deb11u7
Severity: normal

Hi,

LibreOffice features a prompt that pops up every now and then, asking
users to get involved or to donate. I'm not sure asking repeatedly is
reasonable, and it seems like ENABLE_WASM_STRIP_PINGUSER would be
appropriate to turn that off. Implementation details can be found in
SfxViewFrame::Notify().

Thanks for considering.


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

Bug#1055907: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b3

[Scott Talbert]

On Thu, 16 Nov 2023, Cyril Brulebois wrote:


Hi,

Scott Talbert  (2023-11-13):

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org
Control: affects -1 + src:libalien-wxwidgets-perl

nmu libalien-wxwidgets-perl_0.69+dfsg-6+b3 . ANY . unstable . -m "Rebuild for 
wxwidgets3.2 (3.2.4+dfsg-1)"


This looks like a redux of #1054146, with libwx-perl also needing a
binNMU (after the libalien-wxwidgets-perl one)?


Yeah, I did at least file both at the same time this round though :)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055908

Scott

Bug#1056103: dgit fills up my disk with .git/dgit/unpack directories

[Ian Jackson]

Control: tags -1 confirmed

Hi.  Thanks for the report.  I'm sorry that you're finding dgit has
done xsomething inconvenient.

gregor herrmann writes ("Bug#1056103: dgit fills up my disk with 
.git/dgit/unpack directories"):
> Recently I noticed that my usage of `dgit --gbp push-source' leaves
> .git/dgit/unpack directories in each touched package directory. Which
> in my case amounts to 1.5 GB below my pkg-perl directory (for more
> than 1100 dgit-pushed packages since 2019).

Ah.  I hadn't really considered this kind of use case.  (I obviously
touch smaller packages, or fewer different packges, or sometbing.)

I think the wasted space ought to be be O(the size of the source
package), although constant factor may be 2 or 3.  Is this not the
case for you ?  If there are cases where dgit has wasted much more
space then that would be straightforwardly buggy I think.

You're right that these directories are not really needed after dgit
has completed.  However, they can be useful for debugging failures.
Another future run of dgit would remove it of course, but would just
leave another one.  And there's no central tracking and they're hidden
in .git so you wouldn't normally see them and know to delete them.

So, yes, I can see the problem and I agree that something better
should be done.

I think there are some tradeoffs involved, so may not entirely
straightforward.  Some thought will be needed.  (Some of the things in
.git/dgit are hardlinked from elsewhere, so it's not as simple as
using TMPDIR instead.)

Perhaps dgit should, by default, clean up this stuff just before it
exits successfully, but leave it behind for debugging failures.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

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

Bug#1028489: boost1.83 as default

[Anton Gladky]

Hi Sebastian,

bugs are filed:

https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-boost183-transition=gl...@debian.org=1=1=1=1#results

Regards

Anton

Bug#903393: console-setup: disagrees with xorg on what X keys exist ("WARNING: Unknown X keysym")

[roz]

Control: found -1 1.223
Control: retitle -1 console-setup: disagrees with xorg on what X keys exist 
("WARNING: Unknown X keysym")

On Wed, Jul 25, 2018 at 03:00:03PM +0800, Ben Hutchings wrote:
> This is not a bug in initramfs-tools.  The warning comes from console-
> setup and is triggered by a change to the German keyboard layout
Indeed, on my system (I use a customised German layout, attached)
console-setup.service fails, even though the layout works under X.org:
  $ systemctl status console-setup.service
  × console-setup.service - Set console font and keymap
   Loaded: loaded (/lib/systemd/system/console-setup.service; enabled; 
preset: enabled)
   Active: failed (Result: exit-code) since Thu 2023-11-16 06:35:40 CET; 
16h ago
 Main PID: 2308 (code=exited, status=1/FAILURE)
  CPU: 158ms
  
  Nov 16 06:35:40 rozbian systemd[1]: Starting console-setup.service - Set 
console font and keymap...
  Nov 16 06:35:40 rozbian console-setup.sh[2351]: WARNING: Unknown X keysym 
"Ssharp"
  Nov 16 06:35:40 rozbian console-setup.sh[2351]: WARNING: Unknown X keysym 
"Ssharp"
  Nov 16 06:35:40 rozbian console-setup.sh[2316]: /usr/bin/setupcon: 999: 
cannot open /tmp/tmpkbd.OzTB9k: No such file
  Nov 16 06:35:40 rozbian systemd[1]: console-setup.service: Main process 
exited, code=exited, status=1/FAILURE
  Nov 16 06:35:40 rozbian systemd[1]: console-setup.service: Failed with result 
'exit-code'.
  Nov 16 06:35:40 rozbian systemd[1]: Failed to start console-setup.service - 
Set console font and keymap.

The interesting bit is
  $ grep sharp /usr/share/X11/xkb/symbols/de2
  key   { [ s,  S,   ssharp,   Ssharp ] };
i.e. M-s -> ß and M-S -> ẞ, which correspond as expected to
  $ ą
  ß (U+00DF, UTF-8 c3 9f): LATIN SMALL LETTER SHARP S
  ẞ (U+1E9E, UTF-8 e1 ba 9e ): LATIN CAPITAL LETTER SHARP S

So Ssharp definitely exists but isn't in :
  $ grep -i sharp /usr/include/X11/keysymdef.h
  #define XK_ssharp0x00df  /* U+00DF LATIN SMALL LETTER 
SHARP S */
  #define XK_musicalsharp  0x0af5  /* U+266F MUSIC SHARP SIGN */
or, indeed, anywhere?
  $ grep -ri ssharp /usr/include/
  /usr/include/gtk-3.0/gdk/gdkkeysyms-compat.h:#define GDK_ssharp 0x0df
  /usr/include/gtk-3.0/gdk/gdkkeysyms.h:#define GDK_KEY_ssharp 0x0df
  /usr/include/xkbcommon/xkbcommon-keysyms.h:#define XKB_KEY_ssharp 
   0x00df  /* U+00DF LATIN SMALL LETTER SHARP S */
  /usr/include/gtk-4.0/gdk/gdkkeysyms.h:#define GDK_KEY_ssharp 0x0df
  /usr/include/X11/keysymdef.h:#define XK_ssharp0x00df  
/* U+00DF LATIN SMALL LETTER SHARP S */

xev says
  KeyPress event, serial 35, synthetic NO, window 0x781,
  root 0x6c6, subw 0x0, time 59127073, (215,-26), root:(966,406),
  state 0x2080, keycode 39 (keysym 0xdf, ssharp), same_screen YES,
  XKeysymToKeycode returns keycode: 28
  XLookupString gives 2 bytes: (c3 9f) "ß"
  XmbLookupString gives 2 bytes: (c3 9f) "ß"
  XFilterEvent returns: False
  KeyPress event, serial 35, synthetic NO, window 0x781,
  root 0x6c6, subw 0x0, time 59129097, (215,-26), root:(966,406),
  state 0x2081, keycode 39 (keysym 0x1001e9e, U1E9E), same_screen YES,
  XLookupString gives 3 bytes: (e1 ba 9e) "ẞ"
  XmbLookupString gives 3 bytes: (e1 ba 9e) "ẞ"
  XFilterEvent returns: False

So whatever the source of truth w.r.t. keys xinput-or-whatever uses,
console-setup probably needs to use as well, or not error after warnings.

~ roz
default partial alphanumeric_keys
xkb_symbols "basic" {

// Visualisation and description: http://podziemie.net/xkb/pl
// Contact: Michał Górny 

include "latin"

name[Group1]="Niemiecki";

key   { [ grave, asciitilde,  notsign,logicalor ] };
key   { [ 1, exclam, notequal,   exclamdown ] };
key   { [ 2, at,  twosuperior, questiondown ] };
key   { [ 4, dollar, cent,   onequarter ] };
key   { [ 5,percent, EuroSign,U2030 ] };
key   { [ 6, asciicircum, onehalf,   logicaland ] };
key   { [ 7,  ampersand,  section,U2248 ] };
key   { [ 8,   asterisk, periodcentered, threequarters ] };
key   { [ 9,  parenleft, guillemotleft,   plusminus ] };
key   { [ 0, parenright, guillemotright, degree ] };
key   { [ minus, underscore,   endash,   emdash ] };

key   { [ q,  Q, Greek_pi,  Greek_OMEGA ] };
key   { [ w,  W,   oe,   OE ] };
key   { [ e,  E,  eogonek,  Eogonek ] };
key   { [ r,  R,copyright,   registered ] };
key   { [ t,  T,   ssharp,trademark ] };
key   { [ u,  U,   udiaeresis,   Udiaeresis ] };
key   { [ i,  I,   rightarrow,U2194 ] };
key  

Bug#1056022: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/promod3_3.3.1+ds-1_unstable_boost181.log

Thanks

Anton

Bug#1055907: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b3

[Cyril Brulebois]

Hi,

Scott Talbert  (2023-11-13):
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org
> Control: affects -1 + src:libalien-wxwidgets-perl
> 
> nmu libalien-wxwidgets-perl_0.69+dfsg-6+b3 . ANY . unstable . -m "Rebuild for 
> wxwidgets3.2 (3.2.4+dfsg-1)"

This looks like a redux of #1054146, with libwx-perl also needing a
binNMU (after the libalien-wxwidgets-perl one)?


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


signature.asc
Description: PGP signature

Bug#1056008: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/votca_2022.1-1_unstable_boost181.log

Thanks

Anton

Bug#1056015: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/ros-interactive-markers_1.12.0-9_unstable_boost181.log

Thanks

Anton

Bug#1056019: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/python-mapnik_0.0~20200224-7da019cf9-4_unstable_boost181.log

Thanks

Anton

Bug#1056016: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/ros-geometry_1.13.2-10_unstable_boost181.log

Thanks

Anton

Bug#1056011: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/rsem_1.3.3+dfsg-2_unstable_boost181.log

Thanks

Anton

Bug#1056010: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/rsem_1.3.3+dfsg-2_unstable_boost181.log

Thanks

Anton

Bug#1056103: dgit fills up my disk with .git/dgit/unpack directories

[gregor herrmann]

Package: dgit
Version: 11.5
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Recently I noticed that my usage of `dgit --gbp push-source' leaves
.git/dgit/unpack directories in each touched package directory. Which
in my case amounts to 1.5 GB below my pkg-perl directory (for more
than 1100 dgit-pushed packages since 2019).

My assumption is that `.git/dgit/unpack' is a temporary workspace
with no further relevance. To test this hypothesis, I now went to a
package's source dir, rm'd .git/dgit/unpack, imported the new
upstream release, and ran `dgit --gbp push-source' at the end. And I
didn't notice any unusual output. So I guess the assumption that
`.git/dgit/unpack' can and should be cleaned is not completely crazy.

A quick look at /usr/bin/dgit (quick as I didn't want to read 8000+
lines of code) shows e.g.:

  1877  $playground = fresh_playground 'dgit/unpack';
  2600  changedir $playground;
  2885  rmtree $playground;
  4768  changedir $playground;
  4834  changedir $playground;
  6199  changedir $playground;
  6250  changedir "$playground/work";
  6258  @git, qw(pull --ff-only -q), "$playground/work", qw(master);
  7450  changedir $playground;
  7634  changedir $playground;

i.e. lots of `changedir $playground' but only one `rmtree
$playground'. My _guess_ is that at least one more strategically
placed removal of this probably temporary directory would be called
for.

For the sake of disk space (and backup time -- where I first noticed
the issue), please take a look into this issue.


Cheers,
gregor


-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAmVWj65fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZ39A/+PCxSeDpMjt9xRtZiY26VGXv10Ss4SMtYzXn4imGdGzEvyUXFQeYrYC7f
nk4dBrB0+5PzE29RvJG6IV99VB+UeTtmiFQyBCTZX9TBvHo16l/5WssVkM3Gt7qa
OW1NoIxcuKAJ+HX/UCVaLSj7P4SUmewSIqY78EAdpOrfoPOvfxsjbG6/cIPdi7Vq
CjzpH890jsq5biKCtinaaDqzpZV/BnbQiaiYEq1vL6aLc5I6y/2kv/ZHfVx9ZDtk
7Kqv7/I34WLveJjnMd3lv/WSnChO8lT1Tx2y8fOoZ461YQ8q1h9g4N083QVx9LSF
itLgiVE6l7AiJ1qQJA4ji6+/DU7q+YlKQIWg78liIzOHcpUtIoYNTQN2vusIuu9E
VS3/clDWycZnnGYO1iN1lloRzI2OjJWMXrXRMtSsHgBJBmoBrizqgek1xXtiM4OI
rzr9rm/aHV5N4Y0uWgR+YLTjBrG+Ly9OXYiATsA49twaM+EtjR19MwVsoE8r4e6g
Jus8yXjlFdXwwe3Bp+W8uhT3QulX2tPu1C+ZMDm+9ZpYHKPbzEvSXMHff/BRWjTc
2rwysLkMmUUL8tE0BOUrUuytm9whsrTu+AVWLpbw4LO2ZLmjDMrN7XvM0GlA3BoJ
TOrUIhxEG0WMc7PpBOFskq4KWC42Dq8iEVPKqLCPaAoeVmd+CTo=
=Dzmz
-END PGP SIGNATURE-

Bug#1056009: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/simgear_2020.3.18+dfsg-2_unstable_boost181.log

Thanks

Anton

Bug#1056021: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/pysolid_0.3.1-1_unstable_boost181.log

Thanks

Anton

Bug#1056020: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/python-igraph_0.11.2+ds-4_unstable_boost181.log

Thanks

Anton

Bug#1056076: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/laserboy_2016.03.15-1.2_unstable_boost181.log

Thanks

Anton

Bug#1056078: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/gtsam_4.2~9+dfsg-6_unstable_boost181.log

Thanks

Anton

Bug#1056079: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/graph-tool_2.58+ds-1_unstable_boost181.log

Thanks

Anton

Bug#1056077: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/heaptrack_1.4.0-3_unstable_boost181.log

Thanks

Anton

Bug#1056075: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/libkolabxml_1.2.1-4_unstable_boost181.log

Thanks

Anton

Bug#1056023: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/pirs_2.0.2+dfsg-11_unstable_boost181.log

Thanks

Anton

Bug#1056080: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/flightcrew_0.9.3+dfsg-1_unstable_boost181.log

Thanks

Anton

Bug#1056087: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/bali-phy_3.6.1+dfsg-1_unstable_boost181.log

Thanks

Anton

Bug#1056086: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/cctbx_2022.9+ds2+~3.11.2+ds1-6_unstable_boost181.log

Thanks

Anton

Bug#1056085: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/ceph_16.2.11+ds-5_unstable_boost181.log

Thanks

Anton

Bug#1056084: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/cpp-hocon_0.3.0-1_unstable_boost181.log

Thanks

Anton

Bug#1056083: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/dds_2.9.0-9_unstable_boost181.log

Thanks

Anton

Bug#1056081: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/fife_0.4.2-5_unstable_boost181.log

Thanks

Anton

Bug#1056082: Link update

[gladk]

Please use this link for logs

https://qa-logs.debian.net/2023/10/26/field3d_1.7.3-3_unstable_boost181.log

Thanks

Anton

Bug#1056017: Link update

[gladk]

Please use this link for logs

qa-logs.debian.net/2023/10/26/rlvm_0.14-5.1_unstable_boost181.log

Thanks

Anton

Bug#1056088: Link update

[gladk]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/bagel_1.2.2-6_unstable_boost181.log

Thanks

Anton

Bug#1056087: Link update

[gladk]

Please use this link for logs

qa-logs.debian.net/2023/10/26/bali-phy_3.6.1+dfsg-1_unstable_boost181.log

Thanks

Anton

Bug#1056089: Link update

[Anton Gladky]

Please use this link for logs

qa-logs.debian.net/2023/10/26/autodock-vina_1.2.5-1_unstable_boost181.log

thanks

Anton

Bug#1056090: Link update

[Anton Gladky]

Please use this link for logs

http://qa-logs.debian.net/2023/10/26/aegisub_3.2.2+dfsg-7_unstable_boost181.log

Thanks

Anton

Bug#1056102: gst-plugins-bad1.0: CVE-2023-44429: AV1 codec parser buffer overflow

[Salvatore Bonaccorso]

Source: gst-plugins-bad1.0
Version: 1.22.4-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gst-plugins-bad1.0.

CVE-2023-44429[0]:
| AV1 codec parser buffer overflow


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-44429
https://www.cve.org/CVERecord?id=CVE-2023-44429
[1] https://gstreamer.freedesktop.org/security/sa-2023-0009.html
[2] 
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/b76a801f57353b893c344025cac56413140fca6d

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1056074: libreoffice: FTBFS: boost1.83 transition

[Anton Gladky]

Hi Rene,

thanks for the deep analysis. We did a full rebuild of related
packages and it looks like libreoffice was false negative.

Let's keep the bug open for now, till we switch to a newer
version and if all is OK, the bug will be closed.

Best regards

Anton

Bug#1056101: gst-plugins-bad1.0: CVE-2023-44446: MXF demuxer use-after-free

[Salvatore Bonaccorso]

Source: gst-plugins-bad1.0
Version: 1.22.4-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for gst-plugins-bad1.0.

CVE-2023-6[0]:
| MXF demuxer use-after-free


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-6
https://www.cve.org/CVERecord?id=CVE-2023-6
[1] https://gstreamer.freedesktop.org/security/sa-2023-0010.html
[2] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5635
[3] 
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/7dfaa57b6f9b55f17ffe824bd8988bb71ae11353

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Jonas Smedegaard]

Quoting John MacFarlane (2023-11-16 19:25:17)
> Removing lua support would be most unfortunate!  If you need help from 
> upstream in getting things to work, let me know.

I agree: Pandoc with its core scripting language disabled is a severely
crippled Pandoc.


 - 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#1056099: node-axios: CVE-2023-45857

[Salvatore Bonaccorso]

Source: node-axios
Version: 1.5.1+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/axios/axios/issues/6006
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for node-axios.

CVE-2023-45857[0]:
| An issue discovered in Axios 1.5.1 inadvertently reveals the
| confidential XSRF-TOKEN stored in cookies by including it in the
| HTTP header X-XSRF-TOKEN for every request made to any host allowing
| attackers to view sensitive information.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-45857
https://www.cve.org/CVERecord?id=CVE-2023-45857
[1] https://github.com/axios/axios/issues/6006
[2] 
https://github.com/axios/axios/commit/96ee232bd3ee4de2e657333d4d2191cd389e14d0

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1056091: ITP: golang-github-prometheus-community-pgbouncer-exporter -- Prometheus exporter for PgBouncer

[Lena Voytek]

Package: wnpp
Severity: wishlist
Owner: Lena Voytek 
X-Debbugs-Cc: debian-de...@lists.debian.org, l...@voytek.dev

* Package name: golang-github-prometheus-community-pgbouncer-exporter
  Version : 0.7.0
  Upstream Author : Prometheus Monitoring Community
* URL : https://github.com/prometheus-community/pgbouncer_exporter
* License : MIT
  Programming Lang: Go
  Description : Prometheus exporter for PgBouncer

PgBouncer Exporter extracts data and metrics from pgbouncer for
monitoring using Prometheus tools. It provides a useful
connection between PostgreSQL databases and the Prometheus
ecosystem. For more information on Prometheus exporters see
https://prometheus.io/docs/instrumenting/exporters/

I intend to actively maintain this package within the Debian Go
Packaging team.

Bug#1056073: audacious: No media buttons in QT mode

[Jelle Haandrikman]

Package: audacious
Version: 4.3.1-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: jha...@freedom.nl

Dear Maintainer,


   * What led up to the situation?
Installed Audacious and opened it in QT mode in KDE plasma desktop

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
The application does show the media buttons with the GTK interface.
Changing the KDE theme does not work.

   * What was the outcome of this action?
The media buttons (previous/ Pause / Stop/ Next / Repeat / Shuffle )  are
replaced with text versions.

   * What outcome did you expect instead?
Icons of the media buttons.



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

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

Versions of packages audacious depends on:
ii  audacious-plugins 4.3.1-2
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-3
ii  dbus-x11 [dbus-session-bus]   1.14.10-3
ii  libaudcore5   4.3.1-2
ii  libc6 2.37-12
ii  libgcc-s1 13.2.0-5
ii  libglib2.0-0  2.78.1-2
ii  libstdc++613.2.0-5

Versions of packages audacious recommends:
ii  unzip  6.0-28

audacious suggests no packages.

-- no debconf information

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 16., Cs, 17:46):
>
> Hi Balint,
> >
> > Since libtypec installs include files and libs to the standard
> > locations actually there is no need to set those paths.
> > I think I would use the following patch:
> >
> > --- a/libtypec.pc.in
> > +++ b/libtypec.pc.in
> > @@ -1,12 +1,9 @@
> >   prefix=/usr
> >   exec_prefix=/usr
> > -libdir=${exec_prefix}/lib/x86_64-linux-gnu
> > -includedir=${prefix}/
> >
> >   Name: libtypec
> >   Description: USB-Type C and USB Power Delivery class devices
> >   Version: 0.4.0
> >
> >   Requires:
> > -Libs: -L${libdir} -llibtypec
> > -Cflags: -I${includedir}
> > +Libs: -llibtypec
> >

I think this patch application did not work out as intended, please
check the patched file.

The symbols file's first line is also still off and now the symbos
have debian package revisions.

Those are issues automatically detected by Lintian. I suggest running
lintian on the built binary packages' .changes file or populating the
packaging repository on Salsa where CI runs include lintian and many
other checks.

Cheers,
Balint

> Ah, good idea. I've refreshed package with this change. Also updated the
> .symbols file and uploaded a -4 to mentors.
>
> Colin

Bug#1056066: systemd: rsyslog fails to start if /dev/xconsole exists

[Sven Joachim]

On 2023-11-16 18:12 +0100, Michael Biebl wrote:

> Am 16.11.23 um 17:17 schrieb Sven Joachim:
>> Package: systemd
>> Version: 255~rc2-1
>> Severity: important
>> After upgrading systemd from 254.5-1 and rebooting, rsyslog failed
>> to
>> start on my system.  These messages appear in the journal:
>> ,
>> | Nov 16 16:58:10 localhost systemd[1]: Starting rsyslog.service - System 
>> Logging Service...
>> | Nov 16 16:58:10 localhost (rsyslogd)[674]: Failed to create
>> | destination mount point node
>> | '/run/systemd/mount-rootfs/dev/xconsole', ignoring: Read-only file
>> | system
>> | Nov 16 16:58:10 localhost (rsyslogd)[674]: Failed to mount
>> | /dev/xconsole to /run/systemd/mount-rootfs/dev/xconsole: No such
>> | file or directory
>> | Nov 16 16:58:10 localhost (rsyslogd)[674]: rsyslog.service: Failed
>> | to set up mount namespacing: /dev/xconsole: No such file or
>> | directory
>> | Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Main process 
>> exited, code=exited, status=226/NAMESPACE
>> | Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Failed with result 
>> 'exit-code'.
>> | Nov 16 16:58:10 localhost systemd[1]: Failed to start rsyslog.service - 
>> System Logging Service.
>> | Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Scheduled restart 
>> job, restart counter is at 1.
>> `
>> This gets repeated a few times, and after five restart attempts
>> systemd
>> gives up.
>> It should be noted that I have enabled forwarding messages to
>> xconsole
>> according to the the "Logging to xconsole" section in
>> /usr/share/doc/rsyslog/README.Debian, and the problem is obviously in
>> the bind mount for /dev/xconsole.  Removing /dev/xconsole so that the
>> "BindPaths=-/dev/xconsole" statement in rsyslog.service has no effect
>> lets rsyslog start, but recreates the problem of #1053913.
>
> It appears, that PrivateTmp=yes was locked down further and is now
> remounted read-only (thanks bluca for the reference):
> https://github.com/systemd/systemd/commit/4a9e03aa6bb2cbd23dac00f2b2a7642cc79eaade

Thanks, I had suspected something along these lines.

> We basically have two options as I see it:
>
> a/ Drop PrivateDevices=yes from rsyslog.service
>
> b/ Move /dev/xconsole to run and turn /dev/xconsole into a symlink
>
>
> The latter b/ will require updates to the local copies in
> /etc/tmpfiles.d/ and /etc/rsyslog.d/
>
> They would look like this now:
>
> $ cat /etc/rsyslog.d/xconsole.conf
> daemon.*;mail.*;\
>   news.err;\
>   *.=debug;*.=info;\
>   *.=notice;*.=warn   |/run/xconsole
>
> $ cat /etc/tmpfiles.d/xconsole.conf
> # Type Path Mode UID  GID  Age Argument
> p /run/xconsole 0640 root adm
> L /dev/xconsole ----   /run/xconsole
>
> Conceptually, moving the named pipe out of /dev and into /run is the
> cleaner solution I think. The /dev/xconsole symlink should make it
> reasonably backwards compatible.
>
> Thoughts?

I think b/ and an appropriate debian/NEWS entry in rsyslog are
preferable to softening security, even if it means some disruption for
the minority of users who still monitor logs via xconsole.  But there
may be more complaints once the changes arrive in testing.

Personally I have made your proposed changes, and after restarting
rsyslog and xconsole everything works fine again.

Cheers,
   Sven

Bug#1055716: python-mapnik ftbfs with Python 3.12

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 11/10/23 11:03, Sebastiaan Couwenberg wrote:

On 11/10/23 10:49, Matthias Klose wrote:
src/python_grid_utils.cpp:108:26: error: there are no arguments to 
‘PyUnicode_FromUnicode’ that depend on a template parameter, so a 
declaration of ‘PyUnicode_FromUnicode’ must be available [-fpermissive]
   108 |  PyUnicode_FromUnicode(line.get(), 
array_size;

   |  ^
src/python_grid_utils.cpp:108:26: note: (if you use ‘-fpermissive’, 
G++ will accept your code, but allowing the use of an undeclared name 
is deprecated)


Upstream is aware that PyUnicode_FromUnicode was deprecated but has not 
acted on that yet. Upstream development is pretty much dead, someone 
will have to provide a patch to port python-mapnik away from 
PyUnicode_FromUnicode.


Fedora has a patch for this which we now use too.

Kind Regards,

Bas

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

Bug#1053955: rust-toml: please update to v0.7.8

[Jonas Smedegaard]

Quoting Peter Green (2023-11-16 10:55:33)
> > Please update to (at least) newer upstream release v0.7.8.
> 
> toml itself is not semver-breaking, but it's closely coupled dependency
> toml_edit is.
[...] 
> My overall conclusion is that btm is the main blocker. Jonas, btm is one
> of your packages, can you work with upstream to prepare and test an update?
> 
> Updated versions of toml_edit and toml are availble in experimental for
> you to test with.

Please go ahead without waiting for btm: Upstream has swiftly responded
with an uncomplicated change.

Thanks for looking into this,

 - 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#1056072: RFP: eww A widget system written in Rust

[Lucas Cruz dos Reis]

Package: eww
Severity: wishlist
X-Debbugs-Cc: lcr.e...@gmail.com

Dear Maintainer,
I would like to suggest eww (Elkowars Wacky Widgets)
to be packaged for Debian. which provides ways for Window Manager
users to define their own widgets.

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

Kernel: Linux 6.5.10-mittermeyer (SMP w/24 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

Bug#1056067: ITP: node-sass-loader -- css loader module for webpack

[Alexandre Rossi]

Hi,

Package is awaiting sponsorship at 
https://mentors.debian.net/package/node-sass-loader/

Packaging is available at https://salsa.debian.org/niol/node-sass-loader

Thanks,

Alex

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Ilias Tsitsimpis]

Hi John,

On Thu, Nov 16, 2023 at 10:25AM, John MacFarlane wrote:
> Removing lua support would be most unfortunate!  If you need help from 
> upstream in getting things to work, let me know.

We are currently tracking the latest Stackage LTS, and Lua support is
not enabled for Pandoc there (see also [1]).

It would help if you can give us a list of packages/versions we need to
use in order to compile pandoc-cli with Lua support using the latest
Stackage LTS.

[1] 
https://github.com/commercialhaskell/stack/issues/6260#issuecomment-1751302985

Thanks,

-- 
Ilias

Bug#1053686: pandoc: cannot fulfill the build dependencies

[John MacFarlane]

Removing lua support would be most unfortunate!  If you need help from upstream 
in getting things to work, let me know.

Bug#1056033: ghc: Please include patch to fix cabal arch detection for sparc64

[Ilias Tsitsimpis]

Hi Adrian,

On Thu, Nov 16, 2023 at 09:13AM, John Paul Adrian Glaubitz wrote:
> The attached patch is a backported version of the patch which applies to GHC 
> 9.4.7.

Thanks for working on this. I fear that applying this patch will change
the ABI for Cabal, and hence we will have to rebuild every Haskell
package in Debian. Because of that, I plan on waiting for the current
transition to finish, and then include this patch in the next GHC
upload.

Best,

-- 
Ilias

Bug#1056071: acpi-support: When lid closed, a loop of lid closed/lid opened events cause 100%cpu usage

[Florence Birée]

Package: acpi-support
Version: 0.143-5.1
Severity: normal
X-Debbugs-Cc: flore...@biree.name

Dear Maintainer,

Since a week or two, in my Debian Unstable, my CPU has an high usage
when the laptod lid is closed (working with my external screen via my
dock station, by example).

This seems to be caused by a loop of Lid closed/Lid opened events, as
show in this journalctl -f output:

nov. 16 19:06:20 lyra systemd-logind[791]: Lid closed.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid opened.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid closed.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid opened.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid closed.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid opened.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid closed.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid opened.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid closed.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid opened.
nov. 16 19:06:20 lyra systemd-logind[791]: Lid closed.
nov. 16 19:06:21 lyra systemd-logind[791]: Lid opened.
nov. 16 19:06:21 lyra systemd-logind[791]: Lid closed.
nov. 16 19:06:21 lyra systemd-logind[791]: Lid opened.
nov. 16 19:06:21 lyra systemd-logind[791]: Lid closed.

... and so on.

But the state in /proc/acpi/button/lid/LID/state seems to be OK

This only occur when the lid is closed, when it is opened, I got only
one LID open event, which is the correct behavior.

I disabled all lid events in /etc/apci/events/lidbtn to prevent this
loop of events to run actions, and so to avoid the 100% cpu problem
(caused by the lid actions), but I would prefer to have this action
working correctly as before.

My laptop is a lenovo thinkpad x250.

I hop you will have an idea of the source of this problem...

Thanks for your work,
Florence

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

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

Versions of packages acpi-support depends on:
ii  acpi-support-base  0.143-5.1
ii  acpid  1:2.0.34-1
ii  sysvinit-utils [lsb-base]  3.08-3
ii  x11-xserver-utils  7.7+10

Versions of packages acpi-support recommends:
pn  acpi-fakekey  
ii  rfkill2.39.2-6

Versions of packages acpi-support suggests:
pn  radeontool   
pn  vbetool  
pn  xinput   
pn  xscreensaver | gnome-screensaver | kscreensaver | xautolock | xlock  
 | xtrlock | i3lock | cinnamon-screensaver

-- Configuration Files:
/etc/acpi/events/lidbtn changed:
event=button[ /]lid XXX
action=/etc/acpi/lid.sh


-- no debconf information

Bug#1053686: pandoc: cannot fulfill the build dependencies

[Ilias Tsitsimpis]

Hi Jonas,

On Thu, Nov 16, 2023 at 01:28PM, Jonas Smedegaard wrote:
> Upstream project has restructured to now be organized as multiple
> projects to be built as dependencies of each other.
> 
> I had hoped to be able to orchestrate such chain-of-builds internally in
> the single source package, but the Haskell build helper tools seem to be
> in too bad shape for that: Apparently all Haskell packages use CDBS
> which is quite cumbersome to use for "looping" subtasks, and both of the
> two available non-CDBS debhelper tools existing in Debian are broken.

I would suggest packaging these libraries as distinct packages in
Debian, not only because our tooling doesn't support the other way, but
also because these are distinct packages in Hackage, with different
versions/releases. Essentially treat Hackage as the source of truth, and
not the git (mono-) repo.

> I therefore give up on that approach, and see no other way forward than
> to introduce the libraries of Pandoc as a new source package, and then
> have the existing src:pandoc package depend on that to build the binary.
> 
> I will now file an RFP for that new dependent package, in the hope that
> the Haskell team can adopt maintenance of that.

Please let me know of any missing libraries, and I will package them
ASAP. I thought we had everything in Debian until now. See also my
message here [1], where I point to the new pandoc-cli package, and the
fact that Lua support is currently broken, and maybe it's best to
disable it for now.

Let me know how I can help.

[1] https://lists.debian.org/debian-haskell/2023/11/msg4.html

Best,

-- 
Ilias

Bug#1056070: hibiscus: Please package new version

[Martin Dosch]

Package: hibiscus
Version: 2.10.12+dfsg-1
Severity: wishlist

Dear Jochen,

could you please consider updating hibiscus to the current upstream 
version?

I checked out the git repo from salsa and locally built 2.10.15 without 
any issue so it should be easy to update the version in the debian 
repos.

Best regards,
Martin

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

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

Versions of packages hibiscus depends on:
ii  jameica   2.10.4+dfsg-1
ii  libeclipse-swtchart-java  0.13.0-4
ii  libguava-java 32.0.1-1
ii  libhbci4j-core-java   3.1.67+dfsg-1
ii  libitext5-java5.5.13.3-2
ii  libobantoo-java   2.1.12+ds1-4
ii  libpostgresql-jdbc-java   42.6.0-2
ii  libqrcodegen-java 1.8.0-1.2
ii  libsuper-csv-java 2.4.0-4

hibiscus recommends no packages.

hibiscus suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1055758: opensmtpd: OpenSMTPD release in stable (bookworm) is useless due to #1037359

[Ryan Kavanagh]

On Fri, Nov 10, 2023 at 10:06:11AM -0800, Mike Swanson wrote:
> Due to the bug mentioned in the subject (#1037359), OpenSMTPD fails to
> utilize TLS certificates with OpenSSL >= 3.0.0.  As such, the program
> is a total non-starter for any internet-facing mail solution (perhaps
> an internal mail server without encryption would be fine).  While the
> issue has been resolved upstream and in the sid and trixie
> repositories, it remains unusable in bookworm.

Indeed, OpenSMTPD in Debian stable is currently (only?) useful as a
local smarthost (my own use case for OpenSMTPD on Debian).
Unfortunately, a fix for #1037359 was not available in time for
bookworm.

I plan on uploading OpenSMTPD 7.4.0p2 to Debian backports in the near
future. This should at least provide a working version of OpenSMTPD for
those using bookworm.

Ryan

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Andrej Shadura]

Hello,

On 16/11/2023 18:14, Jonas Smedegaard wrote:

Upstream project consist of multiple crates released in sync - which is
a pattern that is only inefficiently handled by the Rust team (by
needlessly packaging each individual crate as a separate Debian source
package).

Unless you particularly are asking the Rust team for help here, then I
can offer to help: I have experience with handling this type of Rust
source code structure, and would be happy for this opportunity to
collaborate more closely with you, Andrej.


Yes, I’m aware of that, that’s why I packaged it separately from the 
debcargo-conf-managed packages. Nevertheless, the dependencies can be 
managed using debcargo-conf workflow (and that’s what I did when I still 
had energy to spend on this package).


In any case, I’ll be happy with any help that can be had with this 
package, whether it’s updating/packaging build dependencies as separate 
packages or by following the debcargo-conf workflow, and from anyone — 
you, Jonas, included :)


Thanks!

--
Cheers,
  Andrej

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Jonas Smedegaard]

Quoting Andrej Shadura (2023-11-16 18:02:10)
> Package: wnpp
> Severity: normal
> X-Debbugs-Cc: re...@packages.debian.org, debian-de...@lists.debian.org, Rust 
> Maintainers 
> Control: affects -1 + src:resvg
> 
> Hi all,
> 
> resvg is a command-line SVG renderer which I introduced to Debian back
> in 2019. Unfortunately, very soon after the initial upload the upstream
> has rewritten substantial parts of resvg, which resulted in it requiring
> build dependencies that were missing from Debian at that point. I tried
> to update resvg and upload the missing dependencies, but ultimately
> never completed that work, and resvg was removed from bookworm.
> 
> Unfortunately, I cannot invest any more time into resvg at the moment,
> so I have to officially request assistance with maintaining the resvg package.
> 
> To the Debian Rust team: if you can, please adopt this package.

Upstream project consist of multiple crates released in sync - which is
a pattern that is only inefficiently handled by the Rust team (by
needlessly packaging each individual crate as a separate Debian source
package).

Unless you particularly are asking the Rust team for help here, then I
can offer to help: I have experience with handling this type of Rust
source code structure, and would be happy for this opportunity to
collaborate more closely with you, Andrej.


Kind regards,

- 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#1056066: systemd: rsyslog fails to start if /dev/xconsole exists

[Michael Biebl]

Am 16.11.23 um 18:12 schrieb Michael Biebl:

b/ Move /dev/xconsole to run and turn /dev/xconsole into a symlink


The latter b/ will require updates to the local copies in 
/etc/tmpfiles.d/ and /etc/rsyslog.d/


They would look like this now:

$ cat /etc/rsyslog.d/xconsole.conf
daemon.*;mail.*;\
 news.err;\
 *.=debug;*.=info;\
 *.=notice;*.=warn    |/run/xconsole

$ cat /etc/tmpfiles.d/xconsole.conf
# Type Path Mode UID  GID  Age Argument
p /run/xconsole 0640 root adm
L /dev/xconsole -    -    -    -   /run/xconsole


And you need to drop BindPaths=-/dev/xconsole from rsyslog.service again.







OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056066: systemd: rsyslog fails to start if /dev/xconsole exists

[Michael Biebl]

Am 16.11.23 um 17:17 schrieb Sven Joachim:

Package: systemd
Version: 255~rc2-1
Severity: important

After upgrading systemd from 254.5-1 and rebooting, rsyslog failed to
start on my system.  These messages appear in the journal:

,
| Nov 16 16:58:10 localhost systemd[1]: Starting rsyslog.service - System 
Logging Service...
| Nov 16 16:58:10 localhost (rsyslogd)[674]: Failed to create destination mount 
point node '/run/systemd/mount-rootfs/dev/xconsole', ignoring: Read-only file 
system
| Nov 16 16:58:10 localhost (rsyslogd)[674]: Failed to mount /dev/xconsole to 
/run/systemd/mount-rootfs/dev/xconsole: No such file or directory
| Nov 16 16:58:10 localhost (rsyslogd)[674]: rsyslog.service: Failed to set up 
mount namespacing: /dev/xconsole: No such file or directory
| Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Main process exited, 
code=exited, status=226/NAMESPACE
| Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Failed with result 
'exit-code'.
| Nov 16 16:58:10 localhost systemd[1]: Failed to start rsyslog.service - 
System Logging Service.
| Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Scheduled restart job, 
restart counter is at 1.
`

This gets repeated a few times, and after five restart attempts systemd
gives up.

It should be noted that I have enabled forwarding messages to xconsole
according to the the "Logging to xconsole" section in
/usr/share/doc/rsyslog/README.Debian, and the problem is obviously in
the bind mount for /dev/xconsole.  Removing /dev/xconsole so that the
"BindPaths=-/dev/xconsole" statement in rsyslog.service has no effect
lets rsyslog start, but recreates the problem of #1053913.


It appears, that PrivateTmp=yes was locked down further and is now 
remounted read-only (thanks bluca for the reference):

https://github.com/systemd/systemd/commit/4a9e03aa6bb2cbd23dac00f2b2a7642cc79eaade

We basically have two options as I see it:

a/ Drop PrivateDevices=yes from rsyslog.service

b/ Move /dev/xconsole to run and turn /dev/xconsole into a symlink


The latter b/ will require updates to the local copies in 
/etc/tmpfiles.d/ and /etc/rsyslog.d/


They would look like this now:

$ cat /etc/rsyslog.d/xconsole.conf
daemon.*;mail.*;\
news.err;\
*.=debug;*.=info;\
*.=notice;*.=warn   |/run/xconsole

$ cat /etc/tmpfiles.d/xconsole.conf
# Type Path Mode UID  GID  Age Argument
p /run/xconsole 0640 root adm
L /dev/xconsole ----   /run/xconsole

Conceptually, moving the named pipe out of /dev and into /run is the 
cleaner solution I think. The /dev/xconsole symlink should make it 
reasonably backwards compatible.


Thoughts?


Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056051: reportbug: obsolete NEWQUEUE_URL, giving a 301 Moved Permanently, which is ignored

[Vincent Lefevre]

On 2023-11-16 17:34:57 +0100, Nis Martensen wrote:
> On 16.11.2023 12.48, Vincent Lefevre wrote:
> > Control: retitle -1 reportbug: obsolete NEWQUEUE_URL, giving a 301 Moved 
> > Permanently
> > 
> > On 2023-11-16 12:34:17 +0100, Vincent Lefevre wrote:
> >> So this URL gives a 301 Moved Permanently with
> >> https://ftp-master.debian.org/new.822 as the new URL,
> >> and reportbug does not attempt to use this new URL.
> 
> It will in the next version. This was fixed in git already:
> https://salsa.debian.org/reportbug-team/reportbug/-/commit/7fef65e8bf41a9946eb416597c39408a77aa3f56

I think that the URL given in the reportbug output should
be corrected too. It says

  Checking for newer versions at madison and 
https://ftp-master.debian.org/new.html

but the URL will actually be https://ftp-master.debian.org/new.822
and the contents are different from new.html! See

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055931#34

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

Bug#1051296: freecad: appimage file with version 0.21 works fine

[Leonardo Canducci]

Package: freecad
Version: 0.20.2+dfsg1-10
Followup-For: Bug #1051296

Dear Maintainer,

I've made some tests to get FreeCAD running correctly on my gome+wayland
sid system. First of all version 20.2 runs fine on XFCE and X. It
chashes on gnome+wayland when opening a file or creating a new project.
With the suggested fix (export COIN_GL_NO_CURRENT_CONTEXT_CHECK=1)
FreeCAD runs but its still very slow compared to XFCE (just open some
STL file and try panning or rotating the view). Tu sum up the suggested
fix improves things but doesn't completely solve the problem here.

I've tried the latest version (0.21.1) downloading the appimage file and 
it works fine with wayland. All is fine also with the 0.20.2 appimage
file so I guess the problem is related to the debian packaged version
only or its dependencies.

Regards,
Leonardo

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

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

Versions of packages freecad depends on:
ii  freecad-python3  0.20.2+dfsg1-10

Versions of packages freecad recommends:
ii  calculix-ccx2.20-1
ii  graphviz2.42.2-7+b3
ii  python3-opencamlib  2023.01.11-4

Versions of packages freecad suggests:
pn  povray  

-- no debconf information

Bug#1055931: apt ignores bullseye-backports

[Vincent Lefevre]

Hi Nis,

On 2023-11-16 17:31:13 +0100, Nis Martensen wrote:
> On 14.11.2023 15.17, Vincent Lefevre wrote:
> >> Checking for newer versions at madison and 
> >> https://ftp-master.debian.org/new.html
> >>
> >> Your version (6.1.55-1) of linux-image-6.1.0-13-amd64 appears to be out of 
> >> date.
> >> The following newer release(s) are available in the Debian archive:
> >>   bullseye-backports (backports-policy): 6.1.55+1~bpo11+1
> 
> > So I'm wondering where this information comes from.
> 
> I can find "6.1.55+1~bpo11+1" in https://ftp-master.debian.org/new.822
> so it must come from there.

Thanks. I had first looked at

  https://ftp-master.debian.org/new.html

(as output by reportbug), and it doesn't appear on this page
(I searched for both "linux" and "6.1.55"). Note that clicking
on "Click to toggle all/binary-NEW packages" does not make this
kernel appear either.

FYI, I later looked at https://ftp-master.debian.org/new.822 too
(as I could see it in the strace output), but only searched for
linux-image there, explaining that I didn't find it either (it
actually appears as linux-signed-amd64).

At the bottom of the new.html page:
"You can also look at the RFC822 version."

But why are the contents different? (linux-signed-amd64 appears
only in the RFC822 version.)

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

Bug#1056069: php-memcache: Upstream does not support php8.2 (version 4.x supports php 7.0-7.4)

[Gerardo Esteban Malazdrewicz]

Package: php-memcache
Version: 8.0+4.0.5.2+3.0.9~20170802.e702b5f9+-8
Severity: minor
X-Debbugs-Cc: gera...@malazdrewicz.com.ar

Dear Maintainer,

Upstream Release notes ( at https://pecl.php.net/package/memcache/8.2) say:
Version 8.2 (stable)
- Version 8.x support PHP 8.x
- Version 4.x supports PHP 7.0-7.4.

No lack of functionality observed though, but deprecation notices are 
generated, like:
PHP Deprecated:  Creation of dynamic property Memcache::$connection is 
deprecated in ...
generated since 8.2.


Would be possible to upgrade php-memcache to 8.2 in a future update?

Thanks for all your work, including php.

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

Kernel: Linux 6.5.0-4-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages php-memcache depends on:
ii  php-common   2:93
ii  php8.2-memcache  8.0+4.0.5.2+3.0.9~20170802.e702b5f9+-8

php-memcache recommends no packages.

Versions of packages php-memcache suggests:
pn  memcached  

-- no debconf information

Bug#1056068: RFH: resvg -- SVG rendering library (command-line utility)

[Andrej Shadura]

Package: wnpp
Severity: normal
X-Debbugs-Cc: re...@packages.debian.org, debian-de...@lists.debian.org, Rust 
Maintainers 
Control: affects -1 + src:resvg

Hi all,

resvg is a command-line SVG renderer which I introduced to Debian back
in 2019. Unfortunately, very soon after the initial upload the upstream
has rewritten substantial parts of resvg, which resulted in it requiring
build dependencies that were missing from Debian at that point. I tried
to update resvg and upload the missing dependencies, but ultimately
never completed that work, and resvg was removed from bookworm.

Unfortunately, I cannot invest any more time into resvg at the moment,
so I have to officially request assistance with maintaining the resvg package.

To the Debian Rust team: if you can, please adopt this package.

Thank you.

The package description is:
 resvg is a command-line utility to render SVG files based on a static
 SVG Full 1.1 subset. It is a fast, small, portable, multiple
 backend SVG library designed for edge-cases.
 .
 resvg supports Cairo and Qt backends.

Bug#1055881: virtualbox-dkms: Linux 6.7-rc1 throws "invalid opcode" during module loading

[Ingo Saitz]

retitle 1055881 Linux 6.7-rc1 / Linux 6.6.1 UBSan errors
forwarded 1055881 https://www.virtualbox.org/ticket/21877
thanks

I found the "invalid opcode" was caused by CONFIG_UBSAN_TRAP=y, that was
set by the hardening.config from linux 6.7-rc1. Using the same options I
can reproduce the bug on 6.6.1, too.

This is also reported upstream as https://www.virtualbox.org/ticket/21877

Changing CONFIG_UBSAN_TRAP to no shows these errors in the log (see
attachment.

Sorry for the wrong noise, but I suggest to keep this bug open, since
there is no similar bug reported.

Ingo
-- 
const_cast(Λ)
[   17.127943] vboxdrv: loading out-of-tree module taints kernel.
[   17.132074] vboxdrv: Found 2 processor cores/threads
[   17.133888] 

[   17.134091] UBSAN: array-index-out-of-bounds in 
/var/lib/dkms/virtualbox/7.0.12/build/vboxdrv/common/log/log.c:1791:41
[   17.134304] index 1 is out of range for type 'uint32_t [1]'
[   17.134521] CPU: 1 PID: 1988 Comm: modprobe Tainted: G   O   
6.6.1-pinguin20231116 #1
[   17.134755] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H97 
Anniversary, BIOS P1.20 12/15/2014
[   17.135004] Call Trace:
[   17.135259]  
[   17.135516]  dump_stack_lvl+0x32/0x40
[   17.135782]  __ubsan_handle_out_of_bounds+0xc3/0x100
[   17.136055]  VBoxHost_RTLogGroupSettings+0x472/0x490 [vboxdrv]
[   17.136347]  ? rtR0MemAllocEx+0x52/0xc0 [vboxdrv]
[   17.136573]  VBoxHost_RTLogCreateExV+0x27a/0x480 [vboxdrv]
[   17.136800]  VBoxHost_RTLogCreate+0x6a/0x90 [vboxdrv]
[   17.137030]  ? rtR0MemAllocEx+0x52/0xc0 [vboxdrv]
[   17.137263]  supdrvInitDevExt+0x54/0x320 [vboxdrv]
[   17.137498]  VBoxDrvLinuxInit+0x82/0x1000 [vboxdrv]
[   17.137738]  ? 0xc05f5000
[   17.137962]  do_one_initcall+0x8e/0x2c0
[   17.138190]  do_init_module+0x7d/0x230
[   17.138423]  init_module_from_file+0x81/0xc0
[   17.138658]  idempotent_init_module+0x119/0x230
[   17.138897]  __x64_sys_finit_module+0x4d/0x80
[   17.139140]  do_syscall_64+0x56/0xb0
[   17.139385]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
[   17.139636] RIP: 0033:0x7fb8a591eee9
[   17.139888] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d ff 1e 0d 00 f7 d8 64 89 01 48
[   17.140183] RSP: 002b:7fff225703a8 EFLAGS: 0246 ORIG_RAX: 
0139
[   17.140496] RAX: ffda RBX: 555e4ea0e600 RCX: 7fb8a591eee9
[   17.140814] RDX:  RSI: 555e4d89598b RDI: 0003
[   17.141137] RBP:  R08: 0060 R09: 555e4ea0f340
[   17.141464] R10: 0038 R11: 0246 R12: 555e4d89598b
[   17.141794] R13: 0004 R14: 555e4ea0e680 R15: 
[   17.142130]  
[   17.142471] 

[   17.142843] 

[   17.143196] UBSAN: array-index-out-of-bounds in 
/var/lib/dkms/virtualbox/7.0.12/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:399:33
[   17.143561] index 1 is out of range for type 'page *[1]'
[   17.143933] CPU: 1 PID: 1988 Comm: modprobe Tainted: G   O   
6.6.1-pinguin20231116 #1
[   17.144313] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H97 
Anniversary, BIOS P1.20 12/15/2014
[   17.144703] Call Trace:
[   17.145097]  
[   17.145495]  dump_stack_lvl+0x32/0x40
[   17.145902]  __ubsan_handle_out_of_bounds+0xc3/0x100
[   17.146311]  rtR0MemObjLinuxAllocPages+0x325/0x340 [vboxdrv]
[   17.146746]  rtR0MemObjNativeAllocCont+0x5a/0x110 [vboxdrv]
[   17.147183]  supdrvGipCreate+0x59/0xc30 [vboxdrv]
[   17.147623]  ? rtR0MemAllocEx+0x52/0xc0 [vboxdrv]
[   17.148068]  supdrvInitDevExt+0x148/0x320 [vboxdrv]
[   17.148516]  VBoxDrvLinuxInit+0x82/0x1000 [vboxdrv]
[   17.148966]  ? 0xc05f5000
[   17.149401]  do_one_initcall+0x8e/0x2c0
[   17.149839]  do_init_module+0x7d/0x230
[   17.150280]  init_module_from_file+0x81/0xc0
[   17.150725]  idempotent_init_module+0x119/0x230
[   17.151177]  __x64_sys_finit_module+0x4d/0x80
[   17.151621]  do_syscall_64+0x56/0xb0
[   17.152065]  entry_SYSCALL_64_after_hwframe+0x46/0xb0
[   17.152510] RIP: 0033:0x7fb8a591eee9
[   17.152951] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d ff 1e 0d 00 f7 d8 64 89 01 48
[   17.153431] RSP: 002b:7fff225703a8 EFLAGS: 0246 ORIG_RAX: 
0139
[   17.153925] RAX: ffda RBX: 555e4ea0e600 RCX: 7fb8a591eee9
[   17.154416] RDX:  RSI: 555e4d89598b RDI: 0003
[   17.154904] RBP:  R08: 0060 R09: 555e4ea0f340
[   17.155388] R10: 0038 R11: 0246 

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Colin King (gmail)]

Hi Balint,


Since libtypec installs include files and libs to the standard
locations actually there is no need to set those paths.
I think I would use the following patch:

--- a/libtypec.pc.in
+++ b/libtypec.pc.in
@@ -1,12 +1,9 @@
  prefix=/usr
  exec_prefix=/usr
-libdir=${exec_prefix}/lib/x86_64-linux-gnu
-includedir=${prefix}/

  Name: libtypec
  Description: USB-Type C and USB Power Delivery class devices
  Version: 0.4.0

  Requires:
-Libs: -L${libdir} -llibtypec
-Cflags: -I${includedir}
+Libs: -llibtypec



Ah, good idea. I've refreshed package with this change. Also updated the 
.symbols file and uploaded a -4 to mentors.


Colin

Bug#1056051: reportbug: obsolete NEWQUEUE_URL, giving a 301 Moved Permanently, which is ignored

[Nis Martensen]

control: tags -1 pending

On 16.11.2023 12.48, Vincent Lefevre wrote:
> Control: retitle -1 reportbug: obsolete NEWQUEUE_URL, giving a 301 Moved 
> Permanently
> 
> On 2023-11-16 12:34:17 +0100, Vincent Lefevre wrote:
>> So this URL gives a 301 Moved Permanently with
>> https://ftp-master.debian.org/new.822 as the new URL,
>> and reportbug does not attempt to use this new URL.

It will in the next version. This was fixed in git already:
https://salsa.debian.org/reportbug-team/reportbug/-/commit/7fef65e8bf41a9946eb416597c39408a77aa3f56

Bug#1055931: apt ignores bullseye-backports

[Nis Martensen]

Hi Vincent,

On 14.11.2023 15.17, Vincent Lefevre wrote:
>> Checking for newer versions at madison and 
>> https://ftp-master.debian.org/new.html
>>
>> Your version (6.1.55-1) of linux-image-6.1.0-13-amd64 appears to be out of 
>> date.
>> The following newer release(s) are available in the Debian archive:
>>   bullseye-backports (backports-policy): 6.1.55+1~bpo11+1

> So I'm wondering where this information comes from.

I can find "6.1.55+1~bpo11+1" in https://ftp-master.debian.org/new.822
so it must come from there.

You looked for the binary package in the new queue, that's why you did
not see it. However, reportbug looks for the source package
corresponding to your binary package:
https://sources.debian.org/src/reportbug/12.0.0/reportbug/checkversions.py/?hl=37#L268

Bug#1056067: ITP: node-sass-loader -- css loader module for webpack

[Alexandre Rossi]

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

* Package name: node-sass-loader
  Version : 13.3.2
  Upstream Contact: J. Tangelder
* URL : https://github.com/webpack-contrib/sass-loader
* License : MIT
  Programming Lang: Javascript
  Description : css loader module for webpack

Webpack takes code targeted at node.js and makes it run in the browser.
Node.js comes with API of its own that is not available in the browsers.
Webpack exposes this code to programs that are unaware they are running
in a browser.

Sass is a CSS preprocessor to include features that don’t exist in CSS yet
like nesting, mixins, inheritance, and other nifty goodies that help
write robust, maintainable CSS.

This package is enables webpack to include and compile Sass files
into a web application bundle.

Node.js is an event-based server-side JavaScript engine.

This is required to build some webapps.

I'll be seeking a sponsor for this.

Thanks,

Alex

Bug#1056066: systemd: rsyslog fails to start if /dev/xconsole exists

[Sven Joachim]

Package: systemd
Version: 255~rc2-1
Severity: important

After upgrading systemd from 254.5-1 and rebooting, rsyslog failed to
start on my system.  These messages appear in the journal:

,
| Nov 16 16:58:10 localhost systemd[1]: Starting rsyslog.service - System 
Logging Service...
| Nov 16 16:58:10 localhost (rsyslogd)[674]: Failed to create destination mount 
point node '/run/systemd/mount-rootfs/dev/xconsole', ignoring: Read-only file 
system
| Nov 16 16:58:10 localhost (rsyslogd)[674]: Failed to mount /dev/xconsole to 
/run/systemd/mount-rootfs/dev/xconsole: No such file or directory
| Nov 16 16:58:10 localhost (rsyslogd)[674]: rsyslog.service: Failed to set up 
mount namespacing: /dev/xconsole: No such file or directory
| Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Main process exited, 
code=exited, status=226/NAMESPACE
| Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Failed with result 
'exit-code'.
| Nov 16 16:58:10 localhost systemd[1]: Failed to start rsyslog.service - 
System Logging Service.
| Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Scheduled restart job, 
restart counter is at 1.
`

This gets repeated a few times, and after five restart attempts systemd
gives up.

It should be noted that I have enabled forwarding messages to xconsole
according to the the "Logging to xconsole" section in
/usr/share/doc/rsyslog/README.Debian, and the problem is obviously in
the bind mount for /dev/xconsole.  Removing /dev/xconsole so that the
"BindPaths=-/dev/xconsole" statement in rsyslog.service has no effect
lets rsyslog start, but recreates the problem of #1053913.


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

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

Versions of packages systemd depends on:
ii  libacl12.3.1-3
ii  libapparmor1   3.0.12-1
ii  libaudit1  1:3.1.1-1
ii  libblkid1  2.39.2-6
ii  libc6  2.37-12
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-5
ii  libfdisk1  2.39.2-6
ii  libgcrypt201.10.2-3
ii  libkmod2   30+20230601-2
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.4-0.1
ii  libmount1  2.39.2-6
ii  libpam0g   1.5.2-9.1
ii  libseccomp22.5.4-2
ii  libselinux13.5-1
ii  libssl33.0.12-2
ii  libsystemd-shared  255~rc2-1
ii  libsystemd0255~rc2-1
ii  libzstd1   1.5.5+dfsg2-2
ii  mount  2.39.2-6
ii  systemd-dev255~rc2-1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.10-3
ii  systemd-timesyncd [time-daemon]  255~rc2-1

Versions of packages systemd suggests:
ii  libfido2-11.13.0-1+b1
ii  libip4tc2 1.8.9-2
ii  libp11-kit0   0.25.0-5
ii  libqrencode4  4.1.1-1
pn  libtss2-esys-3.0.2-0  
pn  libtss2-mu0   
pn  libtss2-rc0   
ii  polkitd   123-3
ii  python3   3.11.4-5+b1
pn  python3-pefile
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.10-3
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 255~rc2-1
ii  libpam-systemd 255~rc2-1
ii  udev   255~rc2-1

-- no debconf information

Bug#1056065: transition: spdlog

[Andrius Merkys]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: cru...@debian.org

Hello,

I would like to request a transition slot for spdlog (experimental -> 
unstable) due to soname bump. Ben tracker was not set up automatically, 
thus its file should look like this:


is_affected = .depends ~ 
/\b(libspdlog\-dev|libspdlog1\.10|libspdlog1\.12)\b/;

is_good = .depends ~ /\b(libspdlog\-dev|libspdlog1\.12)\b/;
is_bad = .depends ~ /\b(libspdlog1\.10)\b/;

I have ratt-rebuilt all reverse dependencies with all of them building 
successfully except nmodl (FTBFS with catch2, #1054683) and the 
following packages which are not in sid due to other reasons:


* kodi (seems to be affected by spdlog API change)
* gr-dab (unrelated CMake problems)
* vast (problem with "Flatbuffers")
* purify - FTBFS eigen3 (#1001528, not in sid)

Best,
Andrius

Bug#1056064: RFP: haskell-typst -- parsing and evaluating typst syntax

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Debian Haskell Group 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: haskell-typst
  Version : 0.3.2.1
  Upstream Contact: John MacFarlane 
* URL : https://hackage.haskell.org/package/typst
* License : BSD-3-Clause
  Programming Lang: Haskell
  Description : parsing and evaluating typst syntax

 A library for parsing and evaluating typst syntax.
 Typst is a document layout and formatting language.
 This library targets typst 0.7
 and currently offers only partial support.

This library is needed for upgrading pandoc.

I would appreciate if the Haskell team could care for packaging this.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVWOqQACgkQLHwxRsGg
ASHpbQ//fLTEkhCjf8gkr1XtHTaKU6JDjYEkZPm8PG0bpP/xnkZJlUHiuxr76dC/
13Kkdg+ij+jecqRVWju5kTPI0S69R7ZThuGn4Zv/P5R+gtHN49BuvK8kzDYU5tne
EryTheMXFeN5yPd1grawzyPoSSddcgD2dY1FlvvprQ4n0gVgJD15KID+xoyQ+iJf
oVPqMUVWmKn/fzee/x4+wkH1aPyQJJ3xO+EH4yaQEiUHxHXWDyJIbGQrn6sjDCk3
ZaRSA/21LDwMj58JwMfnM759oiKFIMCkWL/ViAP1YVQI1FUOb7baV9xr6uKiBmVP
+3k8yuhE1RtXh1/C5Gpaivp2gqVaPNlm2gApVgYcXUljZ/0wdBklmmfoTDuYg2by
S7LP16hmL3W7pTFnzFwdArxSHo6qNAHoOWB5dahZdAun3cIlY0Po7kXiwDTSRC09
cf6YwG3c/qeLTGnBDVK39jBhkYqdsEn2jLXLvT3ES8NTLtqgIGAyOdKvRIGGDwuE
6YSUW7/kaID/SMFdbo46kDZITV2VKmLP7rhEPITV7OyHEdBU+DxAGBsmIytlWlzK
lASTIznj8oEdxQwrJjIWHAQLu3b+u8qzsmS1XFM21T6FZWemW+29DH8lYXxWNZPv
Jq56l0KcYIZH73Y0O7Zjs7MBS6i3hq/bw08Wn/DQwxOnrPJFUW4=
=xirR
-END PGP SIGNATURE-

Bug#1056063: RFP: haskell-crypton-connection -- simple and easy network connections API

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: Debian Haskell Group 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: haskell-crypton-connection
  Version : 0.3.1
  Upstream Contact: Vincent Hanquez 
* URL : https://hackage.haskell.org/package/crypton-connection
* License : BSD-3-Clause
  Programming Lang: Haskell
  Description : simple and easy network connections API

 Simple network library for all your connection need.
 .
 Features: Really simple to use, SSL/TLS, SOCKS.
 .
 This library provides a very simple api
 to create sockets to a destination
 with the choice of SSL/TLS, and SOCKS.

This library is needed to upgrade pandoc.

I would appreciate if the Haskell team could care for this library
package.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmVWOcUACgkQLHwxRsGg
ASFwPw/+I0FuWksz49lR4Et/OiXxk+HaFRUJNKvFcs5ZraIGlOWI+slwdcYiONdn
uJEJ+you/YJ5Zh0OfXzjkMvykQEU13QdNQjWHO6oQMW2zqVnW+jeBCIe6VS+ND7Z
kdAz9eOaD87V/0XVAyEhqdgPOot+9otlVtsLDp8NBHSQDlnPUCnLEIOSoO15iuv8
uHiPDJReMc2KD83Zo7Er1BpBzartxlwjRxcHHdKdxW1j55ajHRxmmC2S6brFGJmL
1BuA/ABPwcpPcs/SGtNFb5dUnrNDZ7xgpsMCu54ZtgkFk3ZM3IEkBMl6BhrL6yOx
Q7/e4m0bDvaTX5D1/cJMvJ67PV7W5SNpJceC76Wb7nNlqegyL8r7OnDDUvxB8U45
4Xd0VWkQw20zZwNVE1SHHaNPXGvBEEj1Ce14Jj3uUuEpJnZUfjC2PmvtZaObwZ1r
L6G6onuiPNqO5rXwZHbZZxn4aYWpmXjIFKjrWKT/pihfTlr6XdB1Yz59hww86khs
N34Imey8LcJArIlNPe7V0tHa2fPbSCuH/ChloSzupPB6IkNLIMnbQsTjJ0UoYkrj
016qA5KKN628VjRxP+WF0LMeC0uJf4Rvwc2+G+2Mw83POO1B3RXBAGRQbstDJtv9
0tCVSsjsXAQjgwQXuNpaCP2VDzzuQ1RPNk8cdwoHwZu3sYao3/4=
=M/n1
-END PGP SIGNATURE-

Bug#1041327: RFS: libtypec/0.3-1 [RFP] -- Development files for an interface for USB-C port management

[Bálint Réczey]

Hi Colin,

Colin King (gmail)  ezt írta (időpont: 2023.
nov. 16., Cs, 14:00):
>
> Hi again Balint,
>
> On 16/11/2023 11:35, Bálint Réczey wrote:
> > Hi Colin,
> >
> > Thanks for the quick response.
> > Please check my other observations, too, in
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041327#58
>
> You mentioned:
>
> "The .pc file is now at the right location, but contains multiarch
> strings which will differ across architectures.
> I suggest hardcoding the paths in the patch."
>
> I'm not quite sure what is incorrect here, this file is patched already
> via debian/patches/0001-fix-libtypec-libdir.patch
>
> For an i386 build, the .pc file in usr/share/pkgconfig contains:
>
> prefix=/usr
> exec_prefix=/usr
> libdir=${exec_prefix}/lib/i386-linux-gnu
> includedir=${prefix}/include/i386-linux-gnu
> ..
>
> For a x86-64 build, the .pc file in usr/share/pkgconfig contains:
> prefix=/usr
> exec_prefix=/usr
> libdir=${exec_prefix}/lib/x86_64-linux-gnu
> includedir=${prefix}/include/x86_64-linux-gnu
> ..
>
> For an arm64 build, the .pc file in usr/share/pkgconfig contains:
> prefix=/usr
> exec_prefix=/usr
> libdir=${exec_prefix}/lib/aarch64-linux-gnu
> includedir=${prefix}/include/aarch64-linux-gnu
> ..
>
> ..so I'm a bit confused. Do you mind clarifying for me.

I'm sorry, my comment was a bit vague, indeed.
So the problem is having the multiarch string in the .pc file, while
the file is not in a multiarch location.
Lintian throws an error about it, that would cause an auto-reject when
uploading the package:

E: libtypec-dev: pkg-config-multi-arch-wrong-dir full text contains
architecture specific dir x86_64-linux-gnu
[usr/share/pkgconfig/libtypec.pc]
N:
N:   The arch all pkg-config file contains a reference to a multi-arch path.
N:
N:   This can be usually be fixed by moving this file to a multi-arch path.
N:
N:   Another likely cause is using debhelper 9 or newer (thus enabling
multi-arch paths
N:   by default) on a package without multi-arch support. The usual
cure in this case is
N:   to update it for multi-arch.
N:
N:   Last but not least, this file could contain a reference to a
cross architecture
N:   (like for instance an x86_64-linux-gnu pkg-config file referencing an
N:   i386-linux-gnu file). In this case the usual cure is to fix this path.
N:
N:   Visibility: error
N:   Show-Always: no
N:   Check: files/pkgconfig

Since libtypec installs include files and libs to the standard
locations actually there is no need to set those paths.
I think I would use the following patch:

--- a/libtypec.pc.in
+++ b/libtypec.pc.in
@@ -1,12 +1,9 @@
 prefix=/usr
 exec_prefix=/usr
-libdir=${exec_prefix}/lib/x86_64-linux-gnu
-includedir=${prefix}/

 Name: libtypec
 Description: USB-Type C and USB Power Delivery class devices
 Version: 0.4.0

 Requires:
-Libs: -L${libdir} -llibtypec
-Cflags: -I${includedir}
+Libs: -llibtypec

Cheers,
Balint



> Colin
>