Bug#1041272: transmission-daemon: Still SEGV

[Pavel Kreuzt]

Package: transmission-daemon
Followup-For: Bug #1041272
X-Debbugs-Cc: pkre...@gmail.com

Please forget about my previous message. Went back to my self-packaged version 
and problem persists. It crashes in about 4 hours after starting. Maybe some 
dependency or unrelated package upgrade made this happen. I'm also affected by 
WebUI lockup already reported in another bug. Been running Transmission for 
years now without major problems, but it seems clear that 3.x is being way too 
problematic. Maybe maintainers should evaluate if their time is being properly 
used fixing what essentially looks like a broken version. Anyway, turning down 
to another seedbox-appropiate torrent client for the moment.

Sorry for the rant.

Bug#1051986: scalapack: cmake files miss multiarch, referencing missing file

[Michael Banck]

Source: scalapack
Version: 2.2.1-2
Severity: serious

Hi,

I'm building a package that can use scalapack; it uses cmake as build
system and fails configuring as such:

|dh_auto_configure --   \
|   -DCMAKE_BUILD_TYPE= \
|   -DBUILD_SHARED_LIBS=NO  \
|   -DBUILD_TESTING=YES \
|   -DENABLE_SCALAPACK_MPI=YES
|   cd obj-x86_64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb cmake
|-DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None
|-DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var
|-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON
|-DCMAKE_FIND_USE_PACKAGE_REGISTRY=OFF
|-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON
|-DFETCHCONTENT_FULLY_DISCONNECTED=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run
|"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON
|-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DCMAKE_BUILD_TYPE=
|-DBUILD_SHARED_LIBS=NO -DBUILD_TESTING=YES -DENABLE_SCALAPACK_MPI=YES ..
|-- Setting build type to Release as none was set
|-- Will use the mpi_f08 Fortran module
|CMake Error at
|/usr/lib/cmake/scalapack-2.2.1.openmpi/scalapack-targets.cmake:93
|(message):
|  The imported target "scalapack" references the file
|
| "/usr/lib/libscalapack-openmpi.so.2.2.1"
|
|  but this file does not exist.  Possible reasons include:
|
|  * The file was deleted, renamed, or moved to another location.
|
|  * An install or uninstall procedure did not complete successfully.
|
|  * The installation package was faulty and contained
|
| "/usr/lib/cmake/scalapack-2.2.1.openmpi/scalapack-targets.cmake"
|
|  but not all the files it references.
|
|Call Stack (most recent call first):
|  /usr/lib/cmake/scalapack-2.2.1.openmpi/scalapack-config.cmake:2
|(include)
|  CMakeLists.txt:61 (find_package)

Looking at
/usr/lib/cmake/scalapack-2.2.1.openmpi/scalapack-targets-none.cmake it
does not take multiarch into account:

|# grep PREFIX.*openmpi 
/usr/lib/cmake/scalapack-2.2.1.openmpi/scalapack-targets-none.cmake
|  IMPORTED_LOCATION_NONE "${_IMPORT_PREFIX}/lib/libscalapack-openmpi.so.2.2.1"
|list(APPEND _cmake_import_check_files_for_scalapack 
"${_IMPORT_PREFIX}/lib/libscalapack-openmpi.so.2.2.1" )

If I add (see attached patch), the build goes fine. I have not looked so
far at what it would take to change in the scalapack build system to fix
this.


Michael


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

Kernel: Linux 4.19.0-22-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- /usr/lib/cmake/scalapack-2.2.1.openmpi/scalapack-targets-none.cmake	2023-09-15 11:27:13.423032655 +
+++ /usr/lib/cmake/scalapack-2.2.1.openmpi/scalapack-targets-none.cmake.new	2023-09-15 11:26:56.347447809 +
@@ -8,12 +8,12 @@
 # Import target "scalapack" for configuration "None"
 set_property(TARGET scalapack APPEND PROPERTY IMPORTED_CONFIGURATIONS NONE)
 set_target_properties(scalapack PROPERTIES
-  IMPORTED_LOCATION_NONE "${_IMPORT_PREFIX}/lib/libscalapack-openmpi.so.2.2.1"
+  IMPORTED_LOCATION_NONE "${_IMPORT_PREFIX}/lib/${CMAKE_LIBRARY_ARCHITECTURE}/libscalapack-openmpi.so.2.2.1"
   IMPORTED_SONAME_NONE "libscalapack-openmpi.so.2.2"
   )
 
 list(APPEND _cmake_import_check_targets scalapack )
-list(APPEND _cmake_import_check_files_for_scalapack "${_IMPORT_PREFIX}/lib/libscalapack-openmpi.so.2.2.1" )
+list(APPEND _cmake_import_check_files_for_scalapack "${_IMPORT_PREFIX}/lib/${CMAKE_LIBRARY_ARCHITECTURE}/libscalapack-openmpi.so.2.2.1" )
 
 # Commands beyond this point should not need to know the version.
 set(CMAKE_IMPORT_FILE_VERSION)

Bug#1051515: raft: New version available

[Mathias Gibbens]

  Reported upstream as https://github.com/canonical/raft/issues/479.

Mathias


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

Bug#1051900: ohcount: aborts with segfaul or bus error 90% of the time on arm64

[Michael Cree]

On Wed, Sep 13, 2023 at 06:52:08PM -0300, Antonio Terceiro wrote:
> ohcount segfaults (and sometimes aborts with a Bus error) on arm64,
> almost 90% of the time. I tried this on an up to date arm64 Debian

Running ohcount under gdb traps on the segfault but can't get a
backtrace due to a corrupted stack.  So I recompiled ohcount with
the address sanitiser which traps on the segfault with the following:

=
==14540==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address 
0xeab309b4 at pc 0xacf8bd38 bp 0xeab30960 sp 0xeab30978
WRITE of size 1 at 0xeab309b4 thread T0
#0 0xacf8bd34 in disambiguate_aspx src/detector.c:241
#1 0xacf8ba80 in ohcount_detect_language src/detector.c:221
#2 0xacf87304 in ohcount_sourcefile_get_language src/sourcefile.c:128
#3 0xad1fb5d0 in ohcount_parse src/parser.c:16
#4 0xacf879cc in ohcount_sourcefile_parse src/sourcefile.c:195
#5 0xacf87be0 in ohcount_sourcefile_get_loc_list src/sourcefile.c:239
#6 0xacf88f48 in ohcount_sourcefile_list_analyze_languages 
src/sourcefile.c:404
#7 0xacf8582c in summary src/ohcount.c:210
#8 0xacf86394 in main src/ohcount.c:302
#9 0xa95f777c in __libc_start_call_main 
../sysdeps/nptl/libc_start_call_main.h:58
#10 0xa95f7854 in __libc_start_main_impl ../csu/libc-start.c:360
#11 0xacf840ac in _start 
(/home/mjc/debian/ohcount/ohcount-4.0.0/bin/ohcount+0x240ac)

Address 0xeab309b4 is located in stack of thread T0
SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow src/detector.c:241 in 
disambiguate_aspx
Shadow bytes around the buggy address:
  0x200ffd5660e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ffd5660f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ffd566100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ffd566110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ffd566120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x200ffd566130: ca ca ca ca 00 00[04]cb cb cb cb cb 00 00 00 00
  0x200ffd566140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ffd566150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ffd566160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x200ffd566170: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00
  0x200ffd566180: 00 00 01 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==14540==ABORTING

The code for disambiguate_aspx() where the segfaults occurs is:


const char *disambiguate_aspx(SourceFile *sourcefile) {
  char *p = ohcount_sourcefile_get_contents(sourcefile);
  char *eof = p + ohcount_sourcefile_get_contents_size(sourcefile);
  for (; p < eof; p++) {
// /<%@\s*Page[^>]+Language="VB"[^>]+%>/
p = strstr(p, "<%@");
if (!p)
break;
char *pe = strstr(p, "%>");
if (p && pe) {
  p += 3;
  const int length = pe - p;
  char buf[length];
  strncpy(buf, p, length);
  buf[length] = '\0';
  char *eol = buf + strlen(buf);
  for (p = buf; p < eol; p++) *p = tolower(*p);
  p = buf;
  while (*p == ' ' || *p == '\t') p++;
  if (strncmp(p, "page", 4) == 0) {
p += 4;
if (strstr(p, "language=\"vb\""))
  return LANG_VB_ASPX;
  }
}
  }
  return LANG_CS_ASPX;
}


Line 241 is the line with: buf[length] = '\0';

We see that buf is declared two lines above as a variable length
array. Being a local variable I assume that it is allocated on the
stack, which is dangerous if its length turns out to be too large
for the stack. Presumably that is the problem.

Cheers,
Michael.

Bug#1051981: systemd-boot kernel postinst script calls ukify which requires python3

[Michael Biebl]

Am 15.09.23 um 11:06 schrieb Christopher Obbard:

To workaround this, I have deleted /usr/lib/kernel/install.d/60-ukify.install


If installing python3-minimal is not an option, a better alternative is 
to run

touch /etc/kernel/install.d/60-ukify.install

This will disable the script shipped in the systemd package and will 
survive a package update.


Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051981: R:e systemd-boot kernel postinst script calls ukify which requires python3

[Michael Biebl]

Am 15.09.23 um 12:54 schrieb Alexandre Detiste:

A possible middle way could be to implement
/usr/lib/kernel/install.d/60-ukify.install in shell, the script seems
the script seems simple enough.


The little script load & call a much bigger one:
   https://github.com/systemd/systemd/blob/main/src/ukify/ukify.py


Sure, but 60-ukify.install could print a proper diagnostic warning 
message if python3 is missing without failing all of update-initramfs.





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1018873: Works for me

[Arnaud Rebillout]

On Fri, 25 Aug 2023 22:38:03 +0200 Roland Clobus  wrote:
> Control: tags 1018873 +pending
>
> I've tried the following with the latest version from git:
>
> lb config --firmware-chroot true --archive-areas "main contrib non-free"
> --distribution sid
>
> lb config --firmware-chroot true --archive-areas main contrib non-free
> non-free-firmware --distribution sid --debian-installer live
>
> Both variants work for me, they will build an image without errors.


I tried the command:

  # apt install nvidia-tesla-470-alternative nvidia-tesla-alternative

in a bookworm and in a sid container. Works in both cases.

It seems to me that the issue was fixed in the 
nvidia-graphics-drivers-tesla-470  package a while ago, maybe commit 
7aca87283c58d77dd88c52f645101f8428707464


We had some workaround in place for this issue in Kali. I will remove 
those workarounds, so if there's still a problem I will know it immediately.


--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#1051981: R:e systemd-boot kernel postinst script calls ukify which requires python3

[Alexandre Detiste]

>A possible middle way could be to implement
>/usr/lib/kernel/install.d/60-ukify.install in shell, the script seems
> the script seems simple enough.

The little script load & call a much bigger one:
  https://github.com/systemd/systemd/blob/main/src/ukify/ukify.py

>def call_ukify(opts):
>   # Punish me harder.
>   # We want this:
>   # ukify = importlib.machinery.SourceFileLoader('ukify', UKIFY).load_module()
>   # but it throws a DeprecationWarning.
>   ...
>   ukify = runpy.run_path(UKIFY, run_name='ukify')

Greetings

Bug#1039731: php-laravel-lumen-framework: FTBFS with symfony 6: unsatisfiable build-dependencies

[David Prévot]

Control: clone -1 -2
Control: reassign -2 php-laravel-framework 8.83.26+dfsg-2
Control: retitle -2 Uninstallable with symfony 6: unsatisfiable dependencies

Hi Robin,

Le Wed, Jun 28, 2023 at 03:41:28PM -0300, Athos Ribeiro a écrit :
> Source: php-laravel-lumen-framework
[…]
> We are about to start the symfony 6 transition in unstable.

As for php-laravel-lumen-framework, php-laravel-framework is not yet
ready for the symfony 6 transition, documenting the issue in this bug
report. As for the symfony 5 transition during the last cycle, I assume
we should not block it by Laravel, and be ready to see
php-laravel-lumen-framework and php-laravel-lumen-framework removed from
testing if they are not yet ready (there is more than a year in the
release cycle to get them ready).

Cheers

taffit


signature.asc
Description: PGP signature

Bug#1051984: s3ql: Upstream is at "5.1.1"

[Christian Buhtz]

Package: s3ql
Severity: important

Dear Maintainer,

upstream (https://github.com/s3ql/s3ql) is at version "5.1.1". The version
"3.7.3" in Debian repo is out of date.
The upstream version is not tracked via the "watch" file. "uscan" reports a
problem with it.

Upstream evolved a lot and seems to fix a lot of problems. It also droped the
dependency on "python-dugong" which is currently blocking the Debian package.

Thanks in advance.


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

Kernel: Linux 6.1.0-12-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_CRAP
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

Bug#1051478: elpa-debian-el: warnings (comp)

[Jörg-Volker Peetz]

Package: elpa-debian-el
Version: 37.10
Severity: normal

Dear Debian Emacsen team,

also for the file 'apt-sources.el' there are warnings when native-compiled:

Warning (comp): apt-sources.el:172:2: Warning: defvar
`apt-sources-font-lock-deb-regexp' docstring has wrong usage of unescaped single
quotes (use \= or different quoting)
Warning (comp): apt-sources.el:339:4: Warning: ‘end-of-buffer’ is for
interactive use only; use ‘(goto-char (point-max))’ instead.
Warning (comp): apt-sources.el:376:2: Warning: docstring has wrong usage of
unescaped single quotes (use \= or different quoting)
Warning (comp): apt-sources.el:412:2: Warning: docstring has wrong usage of
unescaped single quotes (use \= or different quoting)
Warning (comp): apt-sources.el:470:2: Warning: docstring has wrong usage of
unescaped single quotes (use \= or different quoting)

Regards,
Jörg.

Bug#1051983: ITP: golang-github-katalix-go-l2tp -- L2TP and PPPoE tools built using the go-l2tp package

[Tom Parkin]

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

* Package name: golang-github-katalix-go-l2tp
  Version : 0.1.1
  Upstream Contact: Tom Parkin 
* URL : https://github.com/katalix/go-l2tp
* License : BSD
  Programming Lang: golang
  Description : L2TP and PPPoE tools built using the go-l2tp package

go-l2tp is a suite of Go libraries for building L2TP applications on
Linux systems.
.
It includes a set of daemons for managing various related connections:
 * kl2tpd is a client (LAC-mode) L2TPv2 daemon,
 * ql2tpd manages static L2TPv3 Ethernet connections,
 * kpppoed is a PPPoE server daemon which can be used alongside kl2tpd
   to implement L2TP Access Concentrator connections.
.
The go-l2tp daemons use the Linux kernel L2TP and PPP subsystems for
data transport.  PPP termination is delegated to pppd.

Since go-l2tp's initial release on GitHub, the NetworkManager-l2tp
project (a VPN plugin for NetworkManager), has adopted kl2tpd as
its default L2TP daemon, falling back to xl2tpd if kl2tpd is not
available.

kl2tpd offers several benefits over xl2tpd, including the use of
ephemeral ports by default, and supporting the use of IPSec with
kernel-mode L2TP data transport.

Offering kl2tpd as a part of a Debian package will make
NetworkManager-l2tp easier to maintain and make it easier for users to
use kl2tpd for their VPN connections.

As a golang package, golang-github-katalix-go-l2tp would fall under the
aegis of the Debian Go Packaging team.  However the upstream authors
would be happy to provide collaborative ongoing support with the
maintenance of the package.

Bug#1051981: systemd-boot kernel postinst script calls ukify which requires python3

[Michael Biebl]

Am 15.09.23 um 11:06 schrieb Christopher Obbard:

Package: src:systemd
Version: 254.1-3
Severity: important
X-Debbugs-Cc: chris.obb...@collabora.com

Dear Maintainer,

Installing a new kernel on a system which uses systemd-boot as the
bootloader fails if python3 is not installed. Here's the snippet from apt
upgrade:

 /etc/kernel/postinst.d/zz-systemd-boot:
 Installing kernel version 6.4.0-4-amd64 in systemd-boot...
 /usr/bin/env: ‘python3’: No such file or directory
 /usr/lib/kernel/install.d/60-ukify.install failed with exit status 127.

This renders the new kernel unusable as it never actually gets installed
in the right place for systemd-boot.

/etc/kernel/postinst.d/zz-systemd-boot calls kernel-install, which in turn
calls /usr/lib/kernel/install.d/60-ukify.install which calls /lib/systemd/ukify
to attempt to create a unified kernel image. These are both python3 scripts.

To workaround this, I have deleted /usr/lib/kernel/install.d/60-ukify.install
as we don't (yet!) create uki images with the ukify utility anyway. When
the ukify postinst script _does_ run, it currently just detects the
environment variable KERNEL_INSTALL_LAYOUT != "uki" (set from some config
files) and exits early, not even creating the uki. So this is opt-in.

/lib/systemd/ukify is shipped in the systemd package along with
/usr/lib/kernel/install.d/60-ukify.install, which I think is wrong as
systemd package does not have the right dependencies for this script.


Perhaps we should split the ukify bits into its own package (systemd-ukify)
which depends on python3 and should be manually installed? Also this package
can then depend on e.g. sbsigntool and other packages to actually manage
the signing (but that can be a separate bug!).



Having a separate package feels a bit like overkill for 68K

52K /lib/systemd/ukify
8,0K/usr/lib/kernel/install.d/60-ukify.install
8,0K/usr/share/man/man1/ukify.1.gz


While systemd has a suggests python3, we certainly don't want a hard 
python3 dependency though.


A possible middle way could be to implement 
/usr/lib/kernel/install.d/60-ukify.install in shell, the script seems 
simple enough.


Michael




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051982: RM: rust-nom-3 -- ROM; depends on unavailable packages, obsolete

[Matthias Geiger]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: pkg-rust-maintain...@alioth-lists.debian.net, werdah...@riseup.net
Control: block 984771 by -1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear ftpmasters,

please remove rust-nom-3. It has no other dependencies, is obsolete
and depends on unavailable packages.

best,

Matthias Geiger

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmUEIsYVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1jOEP/1dEe0nI0AeBloDaUfdWSKUVK4GM
5oyJ4VOC7do2jytiC9JUnVQPS09FDbYHFbDZIsTg8CmZJxdsHyQPK5n8WOz/9M4m
Br6RtS0OLqEn5AU9epsbBlxiuPI7ODQsHuPcmmnZU5oN8AEjFmVOCiJ7OMsmugAZ
LNblmCA9gBlupVB9l8j5fYz7YNEJMnYKu7/2KTZjfq0s4qbZkA8VxgSFgCV9+xUA
ZIyNFrWrfi8a3gmwhN6R/4EKcaotDEMwPRMNyf1PxwrpjllMnmcaqmDLWrYxRW+J
uN3RfLKjFmFaho4i7Pn15A3+ycPzxotHsoEMmdhB3QHRAauAyyN6fleQZ+bimTyE
8RWjZHfB+Rljf9G9ZsOIth7H1g71kxGegyqSch0OpSbE3TuRI2odMXIem5gNIwdZ
voeLJdLZ7kEAE8z1JBiojV2huY/FZEUZa5159HzppBuxuityuOubKWLHrQCfcW34
XQz3rOspum/xG7YW8dPVCPb/RGHaICWtlJ8pLDIohN3KtyGx6W8rNc/mkDX2U+Sa
dyjKqFEb8o4mrc150O2JzN5e27lNJj4PW0NP1GF9VufBtdh/cFvvCQ6Q4DMXMikl
lLtHcVdEzvuktZlQKruIiBSyCyqfiFN93QJb90CTAOnL5ABraDr8csuqUcsTxtwe
Om8dakBWcs2DfZaG
=4+eL
-END PGP SIGNATURE-

Bug#1041692: python3-mesonpy: could the build be verbose by default

[Simon McVittie]

Control: reassign -1 python3-mesonpy,src:dh-python

On Sat, 22 Jul 2023 at 10:33:11 +0200, Picca Frédéric-Emmanuel wrote:
> I am packaging python-fabio and pyfai whcih use this new build system for 
> python extensions.
> 
> Now blhc complain that the compilation is not verbose.
> So I need to add something like this to abtain a verbose output.
> 
> override_dh_auto_build:
>   PYBUILD_BUILD_ARGS="-Ccompile-args=--verbose" dh_auto_build
> 
> It seems to me that it will be a lot eaysier to have a default verbose output
> instead of modifying each package which use this build system.

I think this might be more appropriate to be done in pybuild than in
meson-python. meson-python has its upstream behaviour (detailed output
only when requested) similar to Meson, but if I patched the meson-python
source package to make verbose output the default, that would affect
*all* builds done on Debian - not just Debian packages, but also users'
local builds.

That would be conceptually similar to patching the upstream parts of
Meson or CMake or any other build system to be verbose by default,
which we also don't do.

dh-python maintainers: would it make sense for pybuild to detect
"[build-system] build-backend = 'mesonpy'" in pyproject.toml, and if found,
make it behave more like what happens in non-Python Meson packages?
(configure with --wrap-mode=nodownload --buildtype=plain etc.,
build with --verbose, and so on)

Another way to achieve this in packages like python-fabio and pyfai
would be to bypass pyproject and meson-python to run Meson directly,
either manually per-package via "export PYBUILD_SYSTEM=meson", or maybe
automatically in pybuild when build-backend = 'mesonpy' is found (but
perhaps that would be too much magic).

smcv

Bug#1051981: systemd-boot kernel postinst script calls ukify which requires python3

[Christopher Obbard]

Package: src:systemd
Version: 254.1-3
Severity: important
X-Debbugs-Cc: chris.obb...@collabora.com

Dear Maintainer,

Installing a new kernel on a system which uses systemd-boot as the
bootloader fails if python3 is not installed. Here's the snippet from apt
upgrade:

/etc/kernel/postinst.d/zz-systemd-boot:
Installing kernel version 6.4.0-4-amd64 in systemd-boot...
/usr/bin/env: ‘python3’: No such file or directory
/usr/lib/kernel/install.d/60-ukify.install failed with exit status 127.

This renders the new kernel unusable as it never actually gets installed
in the right place for systemd-boot.

/etc/kernel/postinst.d/zz-systemd-boot calls kernel-install, which in turn
calls /usr/lib/kernel/install.d/60-ukify.install which calls /lib/systemd/ukify
to attempt to create a unified kernel image. These are both python3 scripts.

To workaround this, I have deleted /usr/lib/kernel/install.d/60-ukify.install
as we don't (yet!) create uki images with the ukify utility anyway. When
the ukify postinst script _does_ run, it currently just detects the
environment variable KERNEL_INSTALL_LAYOUT != "uki" (set from some config
files) and exits early, not even creating the uki. So this is opt-in.

/lib/systemd/ukify is shipped in the systemd package along with
/usr/lib/kernel/install.d/60-ukify.install, which I think is wrong as
systemd package does not have the right dependencies for this script.


Perhaps we should split the ukify bits into its own package (systemd-ukify)
which depends on python3 and should be manually installed? Also this package
can then depend on e.g. sbsigntool and other packages to actually manage
the signing (but that can be a separate bug!).

Thanks!

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

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

Versions of packages systemd-boot depends on:
ii  libc6  2.37-7
ii  libsystemd-shared  254.1-3
ii  systemd-boot-efi   254.1-3

Versions of packages systemd-boot recommends:
ii  efibootmgr  17-2

systemd-boot suggests no packages.

-- no debconf information

Bug#1051906: Changes in JDK-8315020 have been backported to jdk17u-dev

[panxuefeng]

Dear Maintainers,

Previously, the JDK-8315020 changes have not been backported to jdk17u. 
The Loongson JDK team leader Qi Ao has backported this change to 
jdk17u-dev: 
https://github.com/openjdk/jdk17u-dev/commit/4636018f02f68ff4e0347969077bc80ed26ce847.


These changes may be integrated into jdk17u in 17.0.10.

I hope this information will help you in reviewing the code.

Thanks,

Xuefeng Pan

Bug#1051822: installed chrony package post-installation script subprocess returned error exit status 1

[Anibal Monsalve Salazar]

On Thu, 2023-09-14 13:14:47 +0200, Vincent Blut wrote:

> diff -Nru chrony-4.4/debian/changelog chrony-4.4/debian/changelog
> --- chrony-4.4/debian/changelog   2023-08-09 17:50:42.0 +0200
> +++ chrony-4.4/debian/changelog   2023-09-14 12:02:21.0 +0200
> @@ -1,3 +1,10 @@
> +chrony (4.4-2) unstable; urgency=medium
> +
> +  * debian/control:
> +- Add version constraint on adduser. (Closes: #1051822)
> +
> + -- Vincent Blut   Thu, 14 Sep 2023 12:02:21 +0200
> +
>  chrony (4.4-1) unstable; urgency=medium
>  
>* Import upstream version 4.4:
> diff -Nru chrony-4.4/debian/control chrony-4.4/debian/control
> --- chrony-4.4/debian/control 2023-08-09 17:50:42.0 +0200
> +++ chrony-4.4/debian/control 2023-09-14 12:02:21.0 +0200
> @@ -25,7 +25,7 @@
>  Package: chrony
>  Architecture: linux-any
>  Pre-Depends: ${misc:Pre-Depends}
> -Depends: adduser,
> +Depends: adduser (>= 3.130),
>   iproute2 [linux-any],
>   tzdata-legacy,
>   ucf,
> diff -Nru chrony-4.4/debian/.gitlab-ci.yml chrony-4.4/debian/.gitlab-ci.yml
> --- chrony-4.4/debian/.gitlab-ci.yml  2023-08-09 17:50:42.0 +0200
> +++ chrony-4.4/debian/.gitlab-ci.yml  2023-09-14 12:02:21.0 +0200
> @@ -4,8 +4,6 @@
>  - 
> https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
>  
>  variables:
> -# chrony now depends on tzdata-legacy which is only available in 
> experimental
> -RELEASE: 'experimental'
>  # Skip the reprotest job as long as it is run as root due to problems 
> with
>  # chrony system tests.
>  SALSA_CI_DISABLE_REPROTEST: 1

That fixed this bug for me.

Thank you,

Aníbal

Bug#1051979: Do not suggest APT::Default-Release setting

[Max Nikulin]

Package: debian-reference
Version: 2.100

The "2.7.7. Tweaking candidate version with apt-pinning" section
in "Chapter 2. Debian package management" recommends


The target release archive can be set by several methods.

- "/etc/apt/apt.conf" configuration file with "APT::Default-Release "stable";" 
line
- command line option, e.g., "apt-get install -t testing some-package"


https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_tweaking_candidate_version

Unfortunately "APT::Default-Release "stable";" prevents installing of 
updates from stable-security and stable-updates repositories. So this 
option should be either just dropped or a warning should be added to 
alert users who remembers it from previous release.


Accordingly to the Debian 11 bullseye release notes acceptable value for 
default release may be



APT::Default-Release "/^bullseye(|-security|-updates)$/";


https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive
"5.1.3. Changed security archive layout"
in "Chapter 5. Issues to be aware of for bullseye"

However there are opinions that this option should be considered as 
deprecated:


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041708#38
apt man pages

https://lists.debian.org/debian-security/2022/01/msg00022.html
Re: Bullseye security.debian.org codename misconfigured?
Sat, 22 Jan 2022 21:07:09 +0100

There is a similar bug against debian-handbook
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041706
filed during the following discussion
https://lists.debian.org/debian-security/2023/07/msg00011.html
"Setting APT::Default-Release prevents installation of security updates 
in bookworm!?"


In my case it was bookworm with the backports repository added to test a 
wifi issue and trixie to get firefox-esr 115 earlier than it will appear 
in stable. By setting APT::Default-Release I was going to prevent 
upgrade kernel from backports to testing when I noticed missed security 
updates. I decided to use apt pinning instead.


I have seen doubts concerning support of APT::Default-Release in
synaptic and regexps in "apt source PKG", but I have not noticed any
problem. So I am unsure if it can be an *additional* argument against
APT::Default-Release.

I admit that some users may need purely stable release without security 
updates (e.g. to test upgrades from particular versions), but I believe 
this case is too specific to be covered in the manual.


Either removing mention of the setting or adding a warning against 
APT::Default-Release should prevent users from making their 
configuration insecure.

Bug#1051978: ITP: python-yamlfix -- Simple opionated yaml formatter that keeps your comments

[Carsten Schoenert]

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

* Package name: python-yamlfix
  Version : 1.13.0
  Upstream Contact: Lyz 
* URL : https://github.com/lyz-code/yamlfix
* License : GPL-3
  Programming Lang: Python
  Description : Simple opionated yaml formatter that keeps your comments

 yamlfix is a Python based YAML file formatter which will fix any known
 formatting issue within your YAML files automatically.
 .
 It can read configuration settings from pyproject.toml, from configuration
 files or environment variables while it is called from the CLI or by
 including as Python library.
 .
 Main feature are:
  * Add the header --- to your file.
  * Correct truthy strings: 'True' -> true, 'no' -> 'false'
  * Remove unnecessary apostrophes:
title: 'Why we sleep' -> title: Why we sleep.
  * Correct comments
  * Ensure that there is exactly one newline at the end of each file, to
comply with the POSIX standard.
  * Split long lines.
  * Respect Jinja2 syntax.
  * Convert short lists to flow-style list: [item, item]
  * Convert lists longer than line-width to block-style

This package will get maintained within the Debian Python Team.

Bug#982894: isc-dhcp-client: Empty /etc/resolv.conf if root partition is full

[Santiago Ruano Rincón]

Control: tags -1 + pending

On Mon, 15 Feb 2021 23:49:40 +0100 =?utf-8?q?Johannes_Wei=C3=9Fl?= 
 wrote:
> Package: isc-dhcp-client
> Version: 4.4.1-2
> Severity: important
> Tags: patch
> 
> The Debian version of /sbin/dhclient-script creates a temporary file next to
> /etc/resolv.conf, and fills it with information. Then it replaces
> /etc/resolv.conf with the temporary file. So far so good.
> 
> The problem appears when the root partition is full. The temporary file is
> creates, but filling it with informations is not possible anymore (echo "..." 
> >
> temporary_resolv_conf fails). BUT: Instead of aborting, dhclient-script still
> replaced the perfectly good /etc/resolv.conf with an empty one.
> 
> This problem appears a lot on AWS EC2 instances (are configured using DHCP,
> despite being servers).

[snip]

Sorry for the radio noise here. I've just applied the patch, and it will
be part of the next release.

cheers,

 -- Santiago


signature.asc
Description: PGP signature

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

[Santiago Ruano Rincón]

On Sun, 23 Jul 2023 12:45:34 +1000 Steven Haigh  wrote:
> Ok, so after a day of messing around with Debian 12, it looks like 
> without these patches applied, there is no way to get a IPv6 PD working 
> with a PPPoE connection. Given the majority of ISPs in Australia use 
> PPPoE as their connection method, this is a much bigger issue in this 
> country than where the maintainers of this package live.
> 
> wide-dhcpv6-client doesn't seem to interpret the reply from the ISP as 
> a valid one.
> 
> dibbler-client binds to the wrong LL address and fails to open a socket.
> 
> Copying the dhclient binary from a Fedora 38 install and using that 
> works perfectly - which is using the Fedora patches for dhclient v4.4.3.
> 
> The current, functioning patch from Fedora is here:
> 
> 
> How are we able to fix this properly instead of a 'copy the binary from 
> Fedora' type fix?

Sorry, I really missed this bug report. That said, since the EOL of
isc-dhcp-server, I reduced the priority given to isc-dhcp.

If isc-dhcp is that broken for .au, I could consider a stable update,
after this has been solved in unstable and confirmed doesn't break
anything.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1051126: armhf: Miscompilation at O2 level (O1 is working)

[Mathieu Malaterre]

Total Test time (real) =  26.65 sec

The following tests FAILED:
446 - HwyWidenMulTestGroup/HwyWidenMulTest.TestAllSatWidenMulPairwiseAdd/EMU128
 # GetParam() = 2305843009213693952 (Subprocess aborted)
452 - HwyWidenMulTestGroup/HwyWidenMulTest.TestAllSumOfMulQuadAccumulate/EMU128
 # GetParam() = 2305843009213693952 (Subprocess aborted)
Errors while running CTest
FAILED: CMakeFiles/test.util

https://buildd.debian.org/status/fetch.php?pkg=highway=armhf=1.0.7-6=1694727847=0

Bug#1035043: alex4-data: please request assets be explictly licensed

[Alexandre Detiste]

Hi,

> [Phil Morrell ]
> I have no personal incentive to follow up.

I understand

It's disappointing, but we'll need to move on.

This game is now in the same situation as opentyrian...

The assets can be made packageable with data-game-data-packager
and alex4 engine will have to be moved to contrib.

Greets

> alex4 is marked for autoremoval from testing

> Hi there,
>
> glad to hear you like the game!
> The license only applies to the source code.
>
> Johan

Bug#1051968: libreoffice: Libreoffice on MATE doesn't install libreoffice-gnome

[Rene Engelhard]

severity 1051968 wishlist

reassign 1051968 tasksel

retitle 1051968 please make task-mate-desktop install libreoffice-gnome

thanks


Hi,

Am 15.09.23 um 04:33 schrieb Charles Boling:

Package: libreoffice
Severity: normal
Tags: patch

Dear Maintainer,

(Sorry if wrong pkg; had trouble finding dependency
Also, yes, I used the term "patch" very loosely.)

Yes, there is no patch here anyway. :)

Problem:
Fresh debian installation includes LibreOffice, but when installed in the MATE
environment, it installs the libreoffice-gtk package but does NOT install
the libreoffice-gnome package.


You mean you have chosen "MATE Desktop Environment" in the installer in 
the "task selection" (a.k.a tasksel)?




How I noticed:
LO was unable to open e.g. "sftp://; files.
If opened from LO, it was as if you hit ESC instead of ENTER on open dialog
-- nothing happened.
If opened from file browser (Caja), it launched LO which then immediately 
exited.

How I fixed:
Manually installed libreoffice-gnome


See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933271. One 
can always install libreoffice-gnome, too.



The "libreoffice" package suggests libreoffice-gnome | 
libreoffice-plasma but indeed  the MATE task just does



Package: task-mate-desktop
Source: tasksel
Version: 3.73
Installed-Size: 9
Maintainer: Debian Install System Team 
Architecture: all
Depends: tasksel (= 3.73), task-desktop, mate-desktop-environment, lightdm
Recommends: gimp, synaptic, libreoffice-writer, libreoffice-calc, 
libreoffice-impress, libreoffice-help-en-us, mythes-en-us, 
hunspell-en-us, hyphen-en-us, network-manager-gnome, orca, libreoffice-gtk3

Description-en: MATE
 This task package is used to install the Debian desktop, featuring
 the MATE desktop environment, and with other packages that Debian users
 expect to have available on the desktop.
Description-md5: 11325f7ae02031b05c57d0b5e0d607c0
Section: tasks
Priority: optional
Filename: pool/main/t/tasksel/task-mate-desktop_3.73_all.deb
Size: 1200
MD5sum: 97a791eba1c4446482466b6a218490f0
SHA256: 90db4b36c0ef18f8fad2cc878173efb78f1e3fee36bb33b7bda3abd69ce65380


But that (understandably, leaving out Base etc) bypasses the 
"libreoffice" metapackage (except that that suggests is not shown when 
being installed by the installer anyway...)



Maybe we definitely should add it in task-mate-desktop... I prepared a 
merge request for tasksel...



I don't know where to go to tweak this in the distro, but I suspect you do!


That would be tasksel.


Regards,


Rene

Bug#1051819: fluidsynth: Consider building with pipewire support

[Gianfranco Costamagna]

Control: tags 1051819 + patch
Control: tags 1051819 + pending

Dear maintainer,

I've prepared an NMU for fluidsynth (versioned as 2.3.3-2.1) and
uploaded it.

Regards.

diff -Nru fluidsynth-2.3.3/debian/changelog fluidsynth-2.3.3/debian/changelog
--- fluidsynth-2.3.3/debian/changelog   2023-09-13 02:52:50.0 +0200
+++ fluidsynth-2.3.3/debian/changelog   2023-09-14 07:22:04.0 +0200
@@ -1,3 +1,11 @@
+fluidsynth (2.3.3-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fixup previous upload, also runtime depend on libpipewire-0.3-dev,
+on libfluidsynth-dev (Closes: #1051819)
+
+ -- Gianfranco Costamagna   Thu, 14 Sep 2023 
07:22:04 +0200
+
 fluidsynth (2.3.3-2) unstable; urgency=medium

   * Team upload.
diff -Nru fluidsynth-2.3.3/debian/control fluidsynth-2.3.3/debian/control
--- fluidsynth-2.3.3/debian/control 2023-09-13 02:52:50.0 +0200
+++ fluidsynth-2.3.3/debian/control 2023-09-14 07:22:04.0 +0200
@@ -82,6 +82,7 @@
  libdbus-1-dev [linux-any],
  libinstpatch-dev (>= 1.1.0),
  libjack-dev | libjack-jackd2-dev,
+ libpipewire-0.3-dev,
  libpulse-dev,
  libreadline-dev,
  libsdl2-dev,


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1051976: commons-daemon: FTBFS: error: Unsupported CPU architecture "loongarch64"

[zhangdandan]

source: commons-daemon
Version: 1.0.15-10
Severity: wishlist
Tags: patch ftbfs
User: debian-de...@lists.debian.org
Usertags: loongarch64

Dear maintainers,

When compiling the package commons-daemon for loong64 in the Debian 
Package Auto-Building environment [1], the error message is as follows:

..omit
checking C flags dependant on host system type... failed
configure: error: Unsupported CPU architecture "loongarch64"
    cd src/native/unix && tail -v -n \+0 config.log
..omit

The full compilation log can be found at [2].

I have added support for loongarch64. Please consider the patch I have 
attached.
Would it be possible to include the support for LoongArch in the next 
upload?

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

[1]:https://buildd.debian.org/status/package.php?p=commons-daemon=sid
[2]:https://buildd.debian.org/status/fetch.php?pkg=commons-daemon=loong64=1.0.15-10=1693581308=0

thanks,
Dandan Zhang

Description: Add support for loongarch64 
Last-Update: 2023-09-14

--- commons-daemon-1.0.15.orig/src/native/unix/support/apsupport.m4
+++ commons-daemon-1.0.15/src/native/unix/support/apsupport.m4
@@ -191,6 +191,10 @@ AC_DEFUN(AP_SUPPORTED_HOST,[
 supported_os="riscv64"
 HOST_CPU=riscv64
 ;;
+  loongarch64)
+CFLAGS="$CFLAGS -DCPU=\\\"loong64\\\""
+HOST_CPU=loong64
+;;
   *)
 AC_MSG_RESULT([failed])
 AC_MSG_ERROR([Unsupported CPU architecture "$host_cpu"]);;

Bug#1050053: xml2rfc: recommends empty package fonts-noto-unhinted

[Jonas Smedegaard]

Quoting Scott Kitterman (2023-09-15 07:49:52)
> 
> 
> On September 15, 2023 5:37:23 AM UTC, Jonas Smedegaard  wrote:
> >Scott Kitterman wrote:
> >>> Please change the dependency to the appropriate package instead.
> >>> Thank you.
> >> Which one is that?  I can't find any indication in the package what
> >> replaced it.
> >
> >The binary package fonts-noto-unhinted is currently empty because it
> >contained only fonts lacking hinting, and currently all fonts provided
> >from same source package are available with hinting.
> >
> >So I would turn the question around: Do xml2rfc require fonts without
> >hinting, or does it require certain specific fonts which formerly
> >existed only without hinting?
> 
> Unhinted is what the upstream documentation specifies:
> 
> https://salsa.debian.org/debian/pkg-xml2rfc/-/blob/debian/sid/README.md

Hmm, it might be that upstream only really specifies the need for "the
full Noto Font and Roboto Mono", and is simply being helpful in how to
achieve that.  Especially since historically the unhinted Noto fonts had
a wider coverage than the hinted ones, but this has since caught up.

Regardless, the Debian *never* offered the full subset of unhinted Noto
fonts, only those unavailable as hinted fonts.

If there really is a need for Debian to distribute yet another gigabyte
of Noto fonts crippled to not contain hinting (which is something only
commonly needed in contrained places like on some smartphones, and
commonly Debian aims for "most bloated" rather than optimizing for
embedded environments) then please file a bugreport against
src:fonts-noto to move further discussion to a wider audience.


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#1051752: closed by Debian FTP Masters (reply to Jonas Smedegaard ) (Bug#1051752: fixed in uwsgi 2.0.22-2)

[Sebastian Ramacher]

Control: reopen -1

On 2023-09-13 21:48:07 +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the src:uwsgi package:
> 
> #1051752: uwsgi: remove uwsgi-plugin-glusterfs on 32 bit architectures

Reopening as a fix for this bug also requires the removal of
libglusterfs-dev from Build-Depends:

https://buildd.debian.org/status/package.php?p=uwsgi

Dependency installability problem for uwsgi on armel:

uwsgi build-depends on missing:
- libglusterfs-dev:armel

Dependency installability problem for uwsgi on armhf:

uwsgi build-depends on missing:
- libglusterfs-dev:armhf

Dependency installability problem for uwsgi on i386:

uwsgi build-depends on missing:
- libglusterfs-dev:i386

Cheers
-- 
Sebastian Ramacher

Bug#1051972: jami-daemon: Fails to start with libopendht2 2.6.0.4-1

[Sebastian Ramacher]

Control: reassign -1 libopendht2 2.6.0.4-1
Control: retitle -1 libopendht2: broke ABI without SONAME bump
Control: affects -1 jami-daemon

On 2023-09-15 03:07:58 +, Asher Gordon wrote:
> Package: jami-daemon
> Version: 20230206.0~ds2-1.3
> Severity: grave
> X-Debbugs-Cc: none, Asher Gordon 
> 
> Dear Maintainer,
> 
> After upgrading libopendht2, jami-daemon fails to start, making Jami
> unusable. Downgrading libopendht2 fixes the problem.
> 
> $ apt-cache policy libopendht2 | grep Installed:
>   Installed: 2.6.0.4-1
> $ jami
> Using Qt runtime version: 6.4.2
> "notify server name: dunst, vendor: knopwob, version: 1.9.2 (2023-04-20), 
> spec: 1.2"
> "Using locale: en_US"
> "Error : jamid is not available, make sure it is running"
> terminate called after throwing an instance of 'char const*'
> Aborted
> $ /usr/libexec/jamid 
> /usr/libexec/jamid: symbol lookup error: /usr/libexec/jamid: undefined 
> symbol: 
> _ZN3dht4http8ResolverC1ERN4asio10io_contextERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt10shared_ptrINS_6LoggerEE

So libopendht2 broke its ABI without a transition. This needs to be
fixed in opendht.

Cheers

> 
> Downgrading:
> 
> $ sudo sed -i~ s/trixie/bookworm/g /etc/apt/sources.list
> $ sudo apt-get update
> Get:1 tor+https://deb.debian.org/debian bookworm InRelease [151 kB]
> [...]
> Fetched 88.2 MB in 42s (2,120 kB/s)
> Reading package lists... Done
> $ sudo apt-get install libopendht2=2.4.12-7
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> The following packages will be DOWNGRADED:
>   libopendht2
> 0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not 
> upgraded.
> Need to get 806 kB of archives.
> After this operation, 377 kB disk space will be freed.
> Do you want to continue? [Y/n] y
> Get:1 tor+https://deb.debian.org/debian bookworm/main amd64 libopendht2 
> amd64 2.4.12-7 [806 kB]
> Fetched 806 kB in 2s (335 kB/s)
> debconf: unable to initialize frontend: Dialog
> debconf: (Dialog frontend will not work on a dumb terminal, an emacs 
> shell buffer, or without a controlling terminal.)
> debconf: falling back to frontend: Readline
> dpkg: warning: downgrading libopendht2:amd64 from 2.6.0.4-1 to 2.4.12-7
> (Reading database ... 586843 files and directories currently installed.)
> Preparing to unpack .../libopendht2_2.4.12-7_amd64.deb ...
> Unpacking libopendht2:amd64 (2.4.12-7) over (2.6.0.4-1) ...
> Setting up libopendht2:amd64 (2.4.12-7) ...
> Processing triggers for libc-bin (2.37-8) ...
> $ apt-cache policy libopendht2 | grep Installed:
>   Installed: 2.4.12-7
> $ jami
> Using Qt runtime version: 6.4.2
> "notify server name: dunst, vendor: knopwob, version: 1.9.2 (2023-04-20), 
> spec: 1.2"
> "Using locale: en_US"
> No migration required
> [...]
> $ /usr/libexec/jamid 
> Jami Daemon 13.7.0, by Savoir-faire Linux Inc. 2004-2023
> https://jami.net/
> [Video support enabled]
> [Plugins support enabled]
> 
> 22:56:59.121 os_core_unix.c !pjlib 2.12.1 for POSIX initialized
>   C-c C-cCaught signal Interrupt, terminating...
> 
> Jami runs as expected.
> 
> It looks like jamid references an undefined symbol,
> _ZN3dht4http8ResolverC1ERN4asio10io_contextERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt10shared_ptrINS_6LoggerEE,
> which is likely present in the old version of libopendht2. I don't know
> a whole lot about C++ and name mangling, but I would guess that Jami had
> been using a deprecated or undocumented symbol, which has been removed
> or renamed in libopendht2. It's also possible that the new libopendht2
> was compiled with a newer compiler, which mangled the name differently,
> but as far as I know, name mangling is supposed to be fairly stable
> (again, I don't know a whole lot about this).
> 
> Also, the name unmangled:
> 
> $ echo 
> _ZN3dht4http8ResolverC1ERN4asio10io_contextERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt10shared_ptrINS_6LoggerEE
>  | c++filt
> dht::http::Resolver::Resolver(asio::io_context&, 
> std::__cxx11::basic_string, std::allocator 
> > const&, std::shared_ptr)
> 
> Thanks,
> Asher
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers testing-debug
>   APT policy: (500, 'testing-debug'), (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.4.0-4-amd64 (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages jami-daemon depends on:
> ii  libarchive13 3.6.2-1
> ii  libasound2   1.2.9-2
> ii  libavcodec60