Bug#1052018: package contains license CC-BY-NC-ND-4.0

[Thorsten Alteholz]

Package: fortran-language-server
Version: 2.13.0-1
Severity: serious
User: alteh...@debian.org
Usertags: license
thanks


Hi Denis,

unfortunately your package contains files with license: CC-BY-NC-ND-4.0

   assets/*

This license is not compatible with DFSG, so please remove the files or
move the package to non-free.

Thanks!
 Thorsten

Processed: control

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> fixed 1051826 8.9.2.26~cuda12+2
Bug #1051826 [src:nvidia-cudnn] nvidia-cudnn autopkg tests fail
Marked as fixed in versions nvidia-cudnn/8.9.2.26~cuda12+2.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1051826: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051826
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1051355: No more crash, this is fixed

[William Desportes]

Thank you for the upload, I can confirm this is fixed.
The CIs PASS now:
- 
- 
--
William Desportes

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

[Michael Cree]

Tags: patch

Further to my prior report it is not the use of variable length array
but the overwriting the end of the array that is the problem. This bug
is repeated multiple times throughout the source file src/detector.c.
It appears that there have been attempts to fix a couple of
occurrences of the bug but even that has been cocked up. There does
not seem to be any understanding by the authors of the code that
strlen() returns the length of a string less the terminating zero.

It is astonishing that this code successfully runs on any architecture
whatsoever given the multiple array overruns!

I attach a patch that fixes many occurrences of the bug.  This is
sufficient to get ohcount running on itself on arm64 without crashing.

There are also occurrences of array underruns in the code. For example,
about line 615 of src/detector.c there is the following:

p = line;
while (p < eol) {
  if (islower(*p) && p != bof && !isalnum(*(p - 1)) && *(p - 1) != '_') {

On the first iteration of the while loop in the if statement one byte
before the start of array line can be read.  That is undefined
behaviour.  I have not fixed this in the attached patch, but it should
be reported upstream.  Frankly, the code needs a full audit for issues
such as these.

Regards,
Michael.
--- a/src/detector.c
+++ b/src/detector.c
@@ -46,7 +46,7 @@
   while (isalnum(*pe)) pe++;
   length = pe - p;
   strncpy(buf, p, length);
-  buf[length] = '\0';
+  buf[79] = '\0';
   struct LanguageMap *rl = ohcount_hash_language_from_name(buf, length);
   if (rl) return(rl->name);
 }
@@ -63,7 +63,7 @@
 } while (*p == '-'); // Skip over any switches.
 length = pe - p;
 strncpy(buf, p, length);
-buf[length] = '\0';
+buf[79] = '\0';
 struct LanguageMap *rl = ohcount_hash_language_from_name(buf, length);
 if (rl) return(rl->name);
   } else if (strstr(line, "xml")) return(LANG_XML);
@@ -146,7 +146,7 @@
 while (pe < eof) {
   // Get the contents of the first line.
   while (pe < eof && *pe != '\r' && *pe != '\n') pe++;
-  length = (pe - p <= sizeof(line)) ? pe - p : sizeof(line);
+  length = (pe - p <= sizeof(line)-1) ? pe - p : sizeof(line)-1;
   strncpy(line, p, length);
   line[length] = '\0';
   if (*line == '#' && *(line + 1) == '!') {
@@ -166,7 +166,7 @@
   }
   pe = p;
   while (!isspace(*pe) && *pe != ';' && pe != strstr(pe, "-*-")) pe++;
-  length = (pe - p <= sizeof(buf)) ? pe - p : sizeof(buf);
+  length = (pe - p <= sizeof(buf)-1) ? pe - p : sizeof(buf)-1;
   strncpy(buf, p, length);
   buf[length] = '\0';
 
@@ -236,7 +236,7 @@
 if (p && pe) {
   p += 3;
   const int length = pe - p;
-  char buf[length];
+  char buf[length+1];
   strncpy(buf, p, length);
   buf[length] = '\0';
   char *eol = buf + strlen(buf);
@@ -550,7 +550,7 @@
   // If the directory contains a matching *.m file, likely Objective C.
   length = strlen(sourcefile->filename);
   if (strcmp(sourcefile->ext, "h") == 0) {
-char path[length];
+char path[length+1];
 strncpy(path, sourcefile->filename, length);
 path[length] = '\0';
 *(path + length - 1) = 'm';
@@ -572,7 +572,7 @@
   while (pe < eof) {
 // Get a line at a time.
 while (pe < eof && *pe != '\r' && *pe != '\n') pe++;
-length = (pe - p <= sizeof(line)) ? pe - p : sizeof(line);
+length = (pe - p <= sizeof(line)-1) ? pe - p : sizeof(line)-1;
 strncpy(line, p, length);
 line[length] = '\0';
 char *eol = line + strlen(line);
@@ -594,7 +594,7 @@
   while (pe < eol && *pe != '>' && *pe != '"') pe++;
   length = pe - p;
   strncpy(buf, p, length);
-  buf[length] = '\0';
+  buf[80] = '\0';
   if (ohcount_hash_is_cppheader(buf, length))
 return LANG_CPP;
   // Is the extension for the header file a C++ file?
@@ -602,7 +602,7 @@
   while (p > line && *(p - 1) != '.') p--;
   length = pe - p;
   strncpy(buf, p, length);
-  buf[length] = '\0';
+  buf[80] = '\0';
   struct ExtensionMap *re = ohcount_hash_language_from_ext(buf, length);
   if (re && strcmp(re->value, LANG_CPP) == 0)
 return LANG_CPP;
@@ -619,7 +619,7 @@
 if (!isalnum(*pe) && *pe != '_') {
   length = pe - p;
   strncpy(buf, p, length);
-  buf[length] = '\0';
+  buf[80] = '\0';
   if (strcmp(buf, "class") == 0 ||
   strcmp(buf, "namespace") == 0 ||
   strcmp(buf, "template") == 0 ||
@@ -650,7 +650,7 @@
   if (strstr(p, ".") <= pe) {
 // Only if the filename has an extension prior to the .in
 length = pe - p;
-char buf[length];
+char buf[length+1];
 strncpy(buf, p, length);
 buf[length] = '\0';
 p = ohcount_sourcefile_get_contents(sourcefile);
@@ -741,7 +741,7 @@
   while (pe < eof) {
 // Get a line at a time.
 while 

Processed: affects 1052002

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> affects 1052002 wasmedge
Bug #1052002 [clang-16] firefox: FTBFS: ERROR: Cannot find wasi headers or 
problem with the wasm compiler. Please fix the problem. Or build with 
--without-wasm-sandboxed-libraries
Added indication that 1052002 affects wasmedge
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1052002: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052002
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1052011: iscsitarget-dkms: Module fails to compile

[TimW]

Package: iscsitarget-dkms
Version: 1.4.20.3+svn502-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: t...@tee-jay.org.uk

Dear Maintainer,

Trying to install this package dkms fails to compile the module


make.log is as follows:
DKMS make.log for iscsitarget-1.4.20.3+svn502 for kernel 6.1.21+ (armv7l)
Fri 15 Sep 23:04:56 BST 2023
make: Entering directory '/usr/src/linux-headers-6.1.21+'
  CC [M]  /var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/tio.o
  CC [M]  /var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/iscsi.o
  CC [M]  /var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/nthread.o
  CC [M]  /var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/wthread.o
In file included from 
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/nthread.c:16:
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/iscsi.h:274:19: error: 
field ‘rx_hash’ has incomplete type
  274 |  struct hash_desc rx_hash;
  |   ^~~
In file included from 
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/tio.c:7:
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/iscsi.h:274:19: error: 
field ‘rx_hash’ has incomplete type
  274 |  struct hash_desc rx_hash;
  |   ^~~
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/iscsi.h:275:19: error: 
field ‘tx_hash’ has incomplete type
  275 |  struct hash_desc tx_hash;
  |   ^~~
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/iscsi.h:275:19: error: 
field ‘tx_hash’ has incomplete type
  275 |  struct hash_desc tx_hash;
  |   ^~~
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/nthread.c: In function 
‘iscsi_conn_init_read’:
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/nthread.c:45:17: error: 
‘struct msghdr’ has no member named ‘msg_iov’; did you mean ‘msg_inq’?
   45 |  conn->read_msg.msg_iov = conn->read_iov;
  | ^~~
  | msg_inq
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/nthread.c:46:16: error: 
‘struct msghdr’ has no member named ‘msg_iovlen’
   46 |  conn->read_msg.msg_iovlen = 1;
  |^
In file included from ./include/linux/kernel.h:26,
 from ./include/linux/cpumask.h:10,
 from ./include/linux/smp.h:13,
 from ./include/linux/lockdep.h:14,
 from ./include/linux/spinlock.h:63,
 from ./include/linux/wait.h:9,
 from ./include/linux/wait_bit.h:8,
 from ./include/linux/fs.h:6,
 from ./include/linux/highmem.h:5,
 from ./include/linux/bvec.h:10,
 from ./include/linux/blk_types.h:10,
 from ./include/linux/blkdev.h:9,
 from 
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/iscsi.h:11,
 from 
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/tio.c:7:
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/tio.c: In function 
‘tio_add_data’:
./include/linux/minmax.h:20:28: warning: comparison of distinct pointer types 
lacks a cast
   20 |  (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
  |^~
./include/linux/minmax.h:26:4: note: in expansion of macro ‘__typecheck’
   26 |   (__typecheck(x, y) && __no_side_effects(x, y))
  |^~~
./include/linux/minmax.h:36:24: note: in expansion of macro ‘__safe_cmp’
   36 |  __builtin_choose_expr(__safe_cmp(x, y), \
  |^~
./include/linux/minmax.h:45:19: note: in expansion of macro ‘__careful_cmp’
   45 | #define min(x, y) __careful_cmp(x, y, <)
  |   ^
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/tio.c:75:25: note: in 
expansion of macro ‘min’
   75 |  const size_t to_copy = min(tio->pg_cnt * PAGE_SIZE - iter->size, len);
  | ^~~
./include/linux/minmax.h:20:28: warning: comparison of distinct pointer types 
lacks a cast
   20 |  (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
  |^~
./include/linux/minmax.h:26:4: note: in expansion of macro ‘__typecheck’
   26 |   (__typecheck(x, y) && __no_side_effects(x, y))
  |^~~
./include/linux/minmax.h:36:24: note: in expansion of macro ‘__safe_cmp’
   36 |  __builtin_choose_expr(__safe_cmp(x, y), \
  |^~
./include/linux/minmax.h:45:19: note: in expansion of macro ‘__careful_cmp’
   45 | #define min(x, y) __careful_cmp(x, y, <)
  |   ^
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/tio.c:82:18: note: in 
expansion of macro ‘min’
   82 |   size_t chunk = min(PAGE_SIZE - iter->pg_off, residual);
  |  ^~~
In file included from 
/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build/kernel/wthread.c:9:

Bug#1052010: package contains license CC-BY-NC-ND-3.0

[Thorsten Alteholz]

Package: lemonldap-ng
Version: 2.0.2+ds-7+deb10u7
Severity: serious
User: alteh...@debian.org
Usertags: license
thanks


Hi,

unfortunately your package contains files with license: CC-BY-NC-ND-3.0

This license is not compatible with DFSG, so please remove the files or
move the package to non-free.

Thanks!
 Thorsten

Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.

[Sebastian Andrzej Siewior]

On 2023-09-15 15:51:51 [+0200], Felix Zielcke wrote:
> Hi Sebastian,

Hi Felix,

> there's now a patch from Jon DeVree upstream, which might fix this for
> you. Is it possible for you to test his patch?
> 
> https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00059.html

Yes it sovles the issue, the box boots.

Sebastian

Processed: Re: Bug#1052002: firefox: FTBFS: ERROR: Cannot find wasi headers or problem with the wasm compiler. Please fix the problem. Or build with --without-wasm-sandboxed-libraries

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 1052002 clang-16
Bug #1052002 [src:firefox] firefox: FTBFS: ERROR: Cannot find wasi headers or 
problem with the wasm compiler. Please fix the problem. Or build with 
--without-wasm-sandboxed-libraries
Bug reassigned from package 'src:firefox' to 'clang-16'.
No longer marked as found in versions firefox/117.0.1-1.
Ignoring request to alter fixed versions of bug #1052002 to the same values 
previously set
> affects 1052002 firefox
Bug #1052002 [clang-16] firefox: FTBFS: ERROR: Cannot find wasi headers or 
problem with the wasm compiler. Please fix the problem. Or build with 
--without-wasm-sandboxed-libraries
Added indication that 1052002 affects firefox
> affects 1052002 firefox-esr
Bug #1052002 [clang-16] firefox: FTBFS: ERROR: Cannot find wasi headers or 
problem with the wasm compiler. Please fix the problem. Or build with 
--without-wasm-sandboxed-libraries
Added indication that 1052002 affects firefox-esr
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1052002: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052002
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: trophy: FTBFS: undefined reference to `pthread_mutexattr_setkind_np'

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 src:clanlib
Bug #1042140 [src:trophy] trophy: FTBFS: ld: 
/usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/libclanCore.so: 
undefined reference to `pthread_mutexattr_setkind_np'
Bug reassigned from package 'src:trophy' to 'src:clanlib'.
No longer marked as found in versions trophy/2.0.3-2.
Ignoring request to alter fixed versions of bug #1042140 to the same values 
previously set
> tags -1 pending
Bug #1042140 [src:clanlib] trophy: FTBFS: ld: 
/usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/libclanCore.so: 
undefined reference to `pthread_mutexattr_setkind_np'
Added tag(s) pending.

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

Bug#1052002: firefox: FTBFS: ERROR: Cannot find wasi headers or problem with the wasm compiler. Please fix the problem. Or build with --without-wasm-sandboxed-libraries

[Mike Hommey]

reassign 1052002 clang-16
affects 1052002 firefox
affects 1052002 firefox-esr
thanks

On Fri, Sep 15, 2023 at 08:19:17PM +0200, Aurelien Jarno wrote:
> Source: firefox
> Version: 117.0.1-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 
> Dear maintainer,
> 
> firefox fails to build from source. From my build log on amd64:
> 
> | checking for vpx >= 1.10.0... yes
> | checking MOZ_LIBVPX_CFLAGS... 
> | checking MOZ_LIBVPX_LIBS... -lvpx -lm
> | checking for vpx/vpx_decoder.h... yes
> | checking for vpx_codec_dec_init_ver... yes
> | checking for nasm... /usr/bin/nasm
> | checking nasm version... 2.16.01
> | checking for the wasm C compiler... /usr/bin/clang
> | checking whether the wasm C compiler can be used... yes
> | checking the wasm C compiler version... 16.0.6
> | checking the wasm C compiler works... yes
> | checking the wasm C compiler can find wasi headers... yes
> | checking the wasm C linker can find wasi libraries... yes
> | checking for the wasm C++ compiler... /usr/bin/clang++
> | checking whether the wasm C++ compiler can be used... yes
> | checking the wasm C++ compiler version... 16.0.6
> | checking the wasm C++ compiler works... yes
> | checking the wasm C++ compiler can find wasi headers... 
> | DEBUG: Creating `/tmp/conftest.t4tbmgsv.cpp` with content:
> | DEBUG: | #include 
> | DEBUG: | int
> | DEBUG: | main(void)
> | DEBUG: | {
> | DEBUG: | 
> | DEBUG: |   ;
> | DEBUG: |   return 0;
> | DEBUG: | }
> | DEBUG: Executing: `/usr/bin/clang++ --target=wasm32-wasi 
> /tmp/conftest.t4tbmgsv.cpp -c`
> | DEBUG: The command returned non-zero exit status 1.
> | DEBUG: Its error output was:
> | DEBUG: | /tmp/conftest.t4tbmgsv.cpp:1:10: fatal error: 'cstring' file not 
> found
> | DEBUG: | #include 
> | DEBUG: |  ^
> | DEBUG: | 1 error generated.
> | ERROR: Cannot find wasi headers or problem with the wasm compiler. Please 
> fix the problem. Or build with --without-wasm-sandboxed-libraries.
> | make[1]: *** [debian/rules:228: stamps/configure-browser] Error 1
> | make[1]: Leaving directory '/<>'
> | make: *** [debian/rules:329: build-arch] Error 2
> | dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> status 2

This is a regression from the upgrade to clang 16.

with clang 14:
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/wasm32-wasi/c++/v1
 /usr/lib/llvm-14/lib/clang/14.0.6/include
 /usr/local/include
 /usr/include/wasm32-wasi
 /usr/include
End of search list.

with clang 16:
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/llvm-16/lib/clang/16/include
 /usr/local/include
 /usr/include/wasm32-wasi
 /usr/include
End of search list.

Note how /usr/include/wasm32-wasi/c++/v1 is missing.

Mike

Bug#1042140: trophy: FTBFS: undefined reference to `pthread_mutexattr_setkind_np'

[Markus Koschany]

Control: reassign -1 src:clanlib
Control: tags -1 pending

This is actually a bug in clanlib which surfaced because of the recent uploads
/ rebuilds against glibc > 2.34. The pthread_mutexattr_setkind_np symbol is
obsolete and has been replaced by pthread_mutexattr_settype.




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

Bug#1051592: Regression: Commit "netfilter: nf_tables: disallow rule addition to bound chain via NFTA_RULE_CHAIN_ID" breaks ruleset loading in linux-stable

[Timo Sigurdsson]

Hi,

Salvatore Bonaccorso schrieb am 12.09.2023 21:13 (GMT +02:00):

> Hi Timo,
> 
> On Tue, Sep 12, 2023 at 01:39:59PM +0200, Timo Sigurdsson wrote:
>> Hi Pablo,
>> 
>> Pablo Neira Ayuso schrieb am 12.09.2023 00:57 (GMT +02:00):
>> 
>> > Hi Timo,
>> > 
>> > On Mon, Sep 11, 2023 at 11:37:50PM +0200, Timo Sigurdsson wrote:
>> >> Hi,
>> >> 
>> >> recently, Debian updated their stable kernel from 6.1.38 to 6.1.52
>> >> which broke nftables ruleset loading on one of my machines with lots
>> >> of "Operation not supported" errors. I've reported this to the
>> >> Debian project (see link below) and Salvatore Bonaccorso and I
>> >> identified "netfilter: nf_tables: disallow rule addition to bound
>> >> chain via NFTA_RULE_CHAIN_ID" (0ebc1064e487) as the offending commit
>> >> that introduced the regression. Salvatore also found that this issue
>> >> affects the 5.10 stable tree as well (observed in 5.10.191), but he
>> >> cannot reproduce it on 6.4.13 and 6.5.2.
>> >> 
>> >> The issue only occurs with some rulesets. While I can't trigger it
>> >> with simple/minimal rulesets that I use on some machines, it does
>> >> occur with a more complex ruleset that has been in use for months
>> >> (if not years, for large parts of it). I'm attaching a somewhat
>> >> stripped down version of the ruleset from the machine I originally
>> >> observed this issue on. It's still not a small or simple ruleset,
>> >> but I'll try to reduce it further when I have more time.
>> >> 
>> >> The error messages shown when trying to load the ruleset don't seem
>> >> to be helpful. Just two simple examples: Just to give two simple
>> >> examples from the log when nftables fails to start:
>> >> /etc/nftables.conf:99:4-44: Error: Could not process rule: Operation not
>> >> supported
>> >> tcp option maxseg size 1-500 counter drop
>> >> ^
>> >> /etc/nftables.conf:308:4-27: Error: Could not process rule: Operation not
>> >> supported
>> >> tcp dport sip-tls accept
>> >> 
>> > 
>> > I can reproduce this issue with 5.10.191 and 6.1.52 and nftables v1.0.6,
>> > this is not reproducible with v1.0.7 and v1.0.8.
>> > 
>> >> Since the issue only affects some stable trees, Salvatore thought it
>> >> might be an incomplete backport that causes this.
>> >> 
>> >> If you need further information, please let me know.
>> > 
>> > Userspace nftables v1.0.6 generates incorrect bytecode that hits a new
>> > kernel check that rejects adding rules to bound chains. The incorrect
>> > bytecode adds the chain binding, attach it to the rule and it adds the
>> > rules to the chain binding. I have cherry-picked these three patches
>> > for nftables v1.0.6 userspace and your ruleset restores fine.
>> 
>> hmm, that doesn't explain why Salvatore didn't observe this with
>> more recent kernels.
>> 
>> Salvatore, did you use newer userspace components when you tested
>> your 6.4.13 and 6.5.2 builds?
> 
> It does explain now because understanding the issue better. While one
> while experinting should only change each one constraint for the
> 6.4.13 and 6.5.2 testing I indeed switched to a Debian unstable
> system, which has newer userpace nftables and so not triggering the
> issue. This was missleading for the report.
> 
>> As for the regression and how it be dealt with: Personally, I don't
>> really care whether the regression is solved in the kernel or
>> userspace. If everybody agrees that this is the best or only viable
>> option and Debian decides to push a nftables update to fix this,
>> that works for me. But I do feel the burden to justify this should
>> be high. A kernel change that leaves users without a working packet
>> filter after upgrading their machines is serious, if you ask me. And
>> since it affects several stable/longterm trees, I would assume this
>> will hit other stable (non-rolling) distributions as well, since
>> they will also use older userspace components (unless this is
>> behavior specific to nftables 1.0.6 but not older versions). They
>> probably should get a heads up then.
> 
> So if it is generally believed on kernel side there should not happen
> any further changes to work with older userland, I guess in Debian we
> will need to patch nftables. I'm CC'ing Arturo Borrero Gonzalez
> , maintainer for the package. The update should go
> ideally in the next point releases from October (and maybe released
> earlier as well trough the stable-updates mechanism).

So, I built nftables 1.0.6-2+deb12u1 with the three cherry-picked patches from 
Pablo and can confirm that they resolve the issue for me on bookworm. I can now 
run linux 6.1.52-1 and load my original nftables ruleset again.
 
> FWIW: In Debian bullseye we have 0.9.8 based nftables, in bookworm
> 1.0.6, so both will need those fixes.
> 
> As 0ebc1064e487 is to address CVE-2023-4147 other distros picking the
> fix will likely 

Bug#1042310: marked as done (python-cobra: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13)

[Debian Bug Tracking System]

Your message dated Fri, 15 Sep 2023 19:26:22 +
with message-id 
and subject line Bug#1042310: fixed in python-cobra 0.26.3-1
has caused the Debian Bug report #1042310,
regarding python-cobra: FTBFS: dh_auto_test: error: pybuild --test 
--test-pytest -i python{version} -p 3.11 returned exit code 13
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1042310: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042310
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: python-cobra
Version: 0.26.2-1
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20230726 ftbfs-trixie

Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.


Relevant part (hopefully):
>  debian/rules binary
> dh binary --with python3 --buildsystem=pybuild
>dh_update_autotools_config -O--buildsystem=pybuild
>dh_autoreconf -O--buildsystem=pybuild
>dh_auto_configure -O--buildsystem=pybuild
> I: pybuild base:240: python3.11 setup.py config 
> running config
>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:240: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.11_cobra/build/cobra
> copying src/cobra/__init__.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra
> copying src/cobra/exceptions.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra
> creating /<>/.pybuild/cpython3_3.11_cobra/build/cobra/io
> copying src/cobra/io/sbml.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/io
> copying src/cobra/io/yaml.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/io
> copying src/cobra/io/__init__.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/io
> copying src/cobra/io/json.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/io
> copying src/cobra/io/mat.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/io
> copying src/cobra/io/dict.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/io
> creating /<>/.pybuild/cpython3_3.11_cobra/build/cobra/summary
> copying src/cobra/summary/reaction_summary.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/summary
> copying src/cobra/summary/__init__.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/summary
> copying src/cobra/summary/metabolite_summary.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/summary
> copying src/cobra/summary/summary.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/summary
> copying src/cobra/summary/model_summary.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/summary
> creating /<>/.pybuild/cpython3_3.11_cobra/build/cobra/medium
> copying src/cobra/medium/__init__.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/medium
> copying src/cobra/medium/minimal_medium.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/medium
> copying src/cobra/medium/annotations.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/medium
> copying src/cobra/medium/boundary_types.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/medium
> creating /<>/.pybuild/cpython3_3.11_cobra/build/cobra/core
> copying src/cobra/core/species.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/core
> copying src/cobra/core/singleton.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/core
> copying src/cobra/core/solution.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/core
> copying src/cobra/core/group.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/core
> copying src/cobra/core/object.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/core
> copying src/cobra/core/gene.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/core
> copying src/cobra/core/__init__.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/core
> copying src/cobra/core/model.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/core
> copying src/cobra/core/configuration.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/core
> copying src/cobra/core/dictlist.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/core
> copying src/cobra/core/formula.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/core
> copying src/cobra/core/reaction.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/core
> copying src/cobra/core/metabolite.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/core
> creating 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/flux_analysis
> copying src/cobra/flux_analysis/gapfilling.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/flux_analysis
> copying src/cobra/flux_analysis/__init__.py -> 
> /<>/.pybuild/cpython3_3.11_cobra/build/cobra/flux_analysis
> 

Bug#1052004: libcbor: requires source-only upload to transition

[Sebastian Ramacher]

Source: libcbor
Version: 0.10.2-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

https://qa.debian.org/excuses.php?package=libcbor

Issues preventing migration:

Not built on buildd: arch amd64 binaries uploaded by bernat
Not built on buildd: arch all binaries uploaded by bernat, a new 
source-only upload is needed to allow migration

Cheers
-- 
Sebastian Ramacher

Bug#1051165: marked as done (FTBFS with doxygen 1.9.8)

[Debian Bug Tracking System]

Your message dated Fri, 15 Sep 2023 18:37:08 +
with message-id 
and subject line Bug#1051165: fixed in libstxxl 1.4.1-4
has caused the Debian Bug report #1051165,
regarding FTBFS with doxygen 1.9.8
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


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

Package: libstxxl-doc
Version: 1.4.1-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the 
past)

X-Debbugs-Cc: paolo.gre...@libpf.com

While preparing to upload doxygen 1.9.8, I did a partial rebuild of 
packages that build-depend on it.
More info here: 
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial


Of 510 packages I tried, 6 failed and one is libstxxl-doc.

The build error was:

  ! LaTeX Error: File `topics.tex' not found.

  Type X to quit or  to proceed,
  or enter new name. (Default extension: tex)

  Enter file name:
  ! Emergency stop.
  

  l.211 \input{topics}
  ^^M
  !  ==> Fatal error occurred, no output PDF file produced!
  Transcript written on refman.log.

I attach the full build log.

Paolo

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

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

Versions of packages libstxxl-doc depends on:
ii  libjs-jquery  3.6.1+dfsg+~3.5.14-1

libstxxl-doc recommends no packages.

libstxxl-doc suggests no packages.

-- no debconf information

libstxxl_1.4.1-3.xz
Description: application/xz
--- End Message ---
--- Begin Message ---
Source: libstxxl
Source-Version: 1.4.1-4
Done: Anton Gladky 

We believe that the bug you reported is fixed in the latest version of
libstxxl, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1051...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Anton Gladky  (supplier of updated libstxxl package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 15 Sep 2023 19:36:33 +0200
Source: libstxxl
Architecture: source
Version: 1.4.1-4
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 

Changed-By: Anton Gladky 
Closes: 1051165
Changes:
 libstxxl (1.4.1-4) unstable; urgency=medium
 .
   * [fe2eba4] Add .gitlab-ci.yml.
   * [3c8b84c] Disable pdf build. (Closes: #1051165)
   * [6a530dc] Trim trailing whitespace.
   * [2bf9fcd] Update watch file format version to 4.
   * [aeff07a] Bump debhelper from old 11 to 13.
   * [48b1e14] Set debhelper-compat version in Build-Depends.
   * [0151f9e] Fix day-of-week for changelog entry 1.3.1-4.
   * [2aa4f8a] Remove field Priority on binary packages
   libstxxl-dev, libstxxl-doc, libstxxl1-bin that duplicates source.
   * [7ec46e6] Set Recommends-Versions to 4.6.2.
   * [5ccf28b] Apply cme fix dpkg.
   * [45b9d3f] Add myself as uploader.
Checksums-Sha1:
 76d58f4008d0915374c92a06d76b3b726e09f522 2339 libstxxl_1.4.1-4.dsc
 8efb084dd71a20e66b5d1f274e0e36fab7af2223 11428 libstxxl_1.4.1-4.debian.tar.xz
 5d656db224d7200b40df4ff30f99ec9ea55f2a61 11001 
libstxxl_1.4.1-4_source.buildinfo
Checksums-Sha256:
 9a9e910eb640e845d1ec73350217c7c322f6e17af16270ce0f6779531250b5c0 2339 
libstxxl_1.4.1-4.dsc
 e50325a01aec7259fc6d0268f34be85ef4c6687e993f3fc995c8e74104d30a84 11428 
libstxxl_1.4.1-4.debian.tar.xz
 2d395f965ffb589d8352039ccfe9d5b8d3d9323334e308670df9261b6049cad0 11001 
libstxxl_1.4.1-4_source.buildinfo
Files:
 6b52c6dc55385219437c2bd00263611c 2339 science optional libstxxl_1.4.1-4.dsc
 cfda4279abc3bacdd91a0b97809d5df3 11428 science optional 
libstxxl_1.4.1-4.debian.tar.xz
 42fe9a91648ff8044323353dc219d1b6 11001 science optional 
libstxxl_1.4.1-4_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAmUEls0ACgkQ0+Fzg8+n

Bug#1052002: firefox: FTBFS: ERROR: Cannot find wasi headers or problem with the wasm compiler. Please fix the problem. Or build with --without-wasm-sandboxed-libraries

[Aurelien Jarno]

Source: firefox
Version: 117.0.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

firefox fails to build from source. From my build log on amd64:

| checking for vpx >= 1.10.0... yes
| checking MOZ_LIBVPX_CFLAGS... 
| checking MOZ_LIBVPX_LIBS... -lvpx -lm
| checking for vpx/vpx_decoder.h... yes
| checking for vpx_codec_dec_init_ver... yes
| checking for nasm... /usr/bin/nasm
| checking nasm version... 2.16.01
| checking for the wasm C compiler... /usr/bin/clang
| checking whether the wasm C compiler can be used... yes
| checking the wasm C compiler version... 16.0.6
| checking the wasm C compiler works... yes
| checking the wasm C compiler can find wasi headers... yes
| checking the wasm C linker can find wasi libraries... yes
| checking for the wasm C++ compiler... /usr/bin/clang++
| checking whether the wasm C++ compiler can be used... yes
| checking the wasm C++ compiler version... 16.0.6
| checking the wasm C++ compiler works... yes
| checking the wasm C++ compiler can find wasi headers... 
| DEBUG: Creating `/tmp/conftest.t4tbmgsv.cpp` with content:
| DEBUG: | #include 
| DEBUG: | int
| DEBUG: | main(void)
| DEBUG: | {
| DEBUG: | 
| DEBUG: |   ;
| DEBUG: |   return 0;
| DEBUG: | }
| DEBUG: Executing: `/usr/bin/clang++ --target=wasm32-wasi 
/tmp/conftest.t4tbmgsv.cpp -c`
| DEBUG: The command returned non-zero exit status 1.
| DEBUG: Its error output was:
| DEBUG: | /tmp/conftest.t4tbmgsv.cpp:1:10: fatal error: 'cstring' file not 
found
| DEBUG: | #include 
| DEBUG: |  ^
| DEBUG: | 1 error generated.
| ERROR: Cannot find wasi headers or problem with the wasm compiler. Please fix 
the problem. Or build with --without-wasm-sandboxed-libraries.
| make[1]: *** [debian/rules:228: stamps/configure-browser] Error 1
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:329: build-arch] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

A full build log on riscv64 is also available:
https://buildd.debian.org/status/fetch.php?pkg=firefox=riscv64=117.0.1-1=1694756702=0

Regards
Aurelien

Processed: libasound2: 1.2.10 breaks ability to play audio using i386 binaries on amd64 host

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forwarded 1051901 https://github.com/alsa-project/alsa-lib/issues/352
Bug #1051901 [libasound2] libasound2: 1.2.10 breaks ability to play audio using 
i386 binaries on amd64 host
Set Bug forwarded-to-address to 
'https://github.com/alsa-project/alsa-lib/issues/352'.
> tags 1051901 fixed-upstream
Bug #1051901 [libasound2] libasound2: 1.2.10 breaks ability to play audio using 
i386 binaries on amd64 host
Added tag(s) fixed-upstream.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1051901: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051901
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 1051901 upstream
Bug #1051901 [libasound2] libasound2: 1.2.10 breaks ability to play audio using 
i386 binaries on amd64 host
Added tag(s) upstream.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1051901: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051901
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1051901: libasound2: 1.2.10 breaks ability to play audio using i386 binaries on amd64 host

[Antoine Le Gonidec]

tags -1 upstream
thanks

Similar symptoms have been reported by Arch Linux users: 
https://bugs.archlinux.org/task/79628
So this bug is most probably not specific to the Debian packaging.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1043124: FYI Same error with zfs-2.1.12-2 and kernel 6.5.0-1-amd64

[Michal Wojcik]

checking whether bops->release() is void... configure: error:
*** None of the expected "bops->release()" interfaces were detected.
*** This may be because your kernel version is newer than what is
*** supported, or you are using a patched custom kernel with
*** incompatible modifications.
***
*** ZFS Version: zfs-2.1.12-2
*** Compatible Kernels: 3.10 - 6.3


Building module:
Cleaning build area...(bad exit status: 2)
make -j12 KERNELRELEASE=6.5.0-1-amd64...(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.5.0-1-amd64 (x86_64)
Consult /var/lib/dkms/zfs/2.1.12/build/make.log for more information.
dkms autoinstall on 6.5.0-1-amd64/x86_64 failed for zfs(10)

Bug#1051563: Backporting mutt patches to Debian Buster

[Chris Frey]

Attached is a patch that applies to the unpackaged sources of Debian Buster's
version of mutt 1.10.

It includes 3 patches:

upstream/Fix-rfc2047-base64-decoding-to-abort-on-illegal-char.patch
debian-specific/Check-for-NULL-userhdrs.patch
debian-specific/Fix-write_one_header-illegal-header-check.patch

First one applied from Bullseye.  The other two I modified slightly
to match the older sources.

The CVE's make mention of "specially crafted input" but I don't have
any samples to test with.  I only tested that this built on Buster and
opens mail as before.

I have not adjusted any other files but the 3 above and debian/patches/series.
Hopefully this gives a head start on making these fixes available on buster.

- Chris

diff --git a/debian/patches/debian-specific/Check-for-NULL-userhdrs.patch b/debian/patches/debian-specific/Check-for-NULL-userhdrs.patch
new file mode 100644
index 000..33f5cb5
--- /dev/null
+++ b/debian/patches/debian-specific/Check-for-NULL-userhdrs.patch
@@ -0,0 +1,56 @@
+From: Chris Frey 
+Date: Fri, 15 Sep 2023 08:41:00 -0400
+Subject: Check for NULL userhdrs.
+Bug-Debian: https://bugs.debian.org/1051563
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-4875
+
+The original patch from Kevin McCarthy backported to Debian buster's
+mutt version 1.10.1-2.1+deb10u6.
+
+Original summary below:
+
+ From: Kevin McCarthy 
+ Date: Mon, 4 Sep 2023 12:50:07 +0800
+ Subject: Check for NULL userhdrs.
+ Origin: https://gitlab.com/muttmua/mutt/-/commit/4cc3128abdf52c615911589394a03271fddeefc6
+
+ When composing an email, miscellaneous extra headers are stored in a
+ userhdrs list.  Mutt first checks to ensure each header contains at
+ least a colon character, passes the entire userhdr field (name, colon,
+ and body) to the rfc2047 decoder, and safe_strdup()'s the result on
+ the userhdrs list.  An empty result would from the decode would result
+ in a NULL headers being added to list.
+
+ The previous commit removed the possibility of the decoded header
+ field being empty, but it's prudent to add a check to the strchr
+ calls, in case there is another unexpected bug resulting in one.
+
+ Thanks to Chenyuan Mi (@morningbread) for discovering the two strchr
+ crashes, giving a working example draft message, and providing the
+ stack traces for the two NULL derefences.
+ ---
+  sendlib.c | 4 ++--
+  1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/sendlib.c b/sendlib.c
+index f9bf3f9..d75e66a 100644
+--- a/sendlib.c
 b/sendlib.c
+@@ -2070,7 +2070,7 @@ int mutt_write_rfc822_header (FILE *fp, ENVELOPE *env, BODY *attach,
+   /* Add any user defined headers */
+   for (; tmp; tmp = tmp->next)
+   {
+-if ((p = strchr (tmp->data, ':')))
++if ((p = strchr (NONULL (tmp->data), ':')))
+ {
+   q = p;
+ 
+@@ -2116,7 +2116,7 @@ static void encode_headers (LIST *h)
+ 
+   for (; h; h = h->next)
+   {
+-if (!(p = strchr (h->data, ':')))
++if (!(p = strchr (NONULL (h->data), ':')))
+   continue;
+ 
+ i = p - h->data;
diff --git a/debian/patches/debian-specific/Fix-write_one_header-illegal-header-check.patch b/debian/patches/debian-specific/Fix-write_one_header-illegal-header-check.patch
new file mode 100644
index 000..8806525
--- /dev/null
+++ b/debian/patches/debian-specific/Fix-write_one_header-illegal-header-check.patch
@@ -0,0 +1,46 @@
+From: Chris Frey 
+Date: Fri, 15 Sep 2023 10:09:00 -0400
+Subject: Fix write_one_header() illegal header check.
+Bug-Debian: https://bugs.debian.org/1051563
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-4874
+
+Backporting original patch from Kevin McCarthy to Debian Buster's
+mutt version 1.10.1-2.1+deb10u6.
+
+Original commentary included below:
+
+ From: Kevin McCarthy 
+ Date: Sun, 3 Sep 2023 14:11:48 +0800
+ Subject: Fix write_one_header() illegal header check.
+ Origin: https://gitlab.com/muttmua/mutt/-/commit/a4752eb0ae0a521eec02e59e51ae5daedf74fda0
+
+ This is another crash caused by the rfc2047 decoding bug fixed in the
+ second prior commit.
+
+ In this case, an empty header line followed by a header line starting
+ with ":", would result in t==end.
+
+ The mutt_substrdup() further below would go very badly at that point,
+ with t >= end+1.  This could result in either a memcpy onto NULL or a
+ huge malloc call.
+
+ Thanks to Chenyuan Mi (@morningbread) for giving a working example
+ draft message of the rfc2047 decoding flaw.  This allowed me, with
+ further testing, to discover this additional crash bug.
+ ---
+  sendlib.c | 2 +-
+  1 file changed, 1 insertion(+), 1 deletion(-)
+ 
+diff --git a/sendlib.c b/sendlib.c
+index f9bf3f9..d821061 100644
+--- a/sendlib.c
 b/sendlib.c
+@@ -1832,7 +1832,7 @@ static int write_one_header (FILE *fp, int pfxw, int max, int wraplen,
+   else
+   {
+ t = strchr (start, ':');
+-if (!t || t > end)
++if (!t || t >= end)
+ {
+   dprint (1, (debugfile, "mwoh: warning: header not 

Processed: Re: Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid

[Debian Bug Tracking System]

Processing control commands:

> severity -1 important
Bug #1051965 [compat-el] compat-el: new upstream release 29.1.4.2 needed by 
elpa-hl-todo/sid
Severity set to 'important' from 'serious'

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

Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid

[David Bremner]

Control: severity -1 important

David Bremner  writes:

> Andreas Beckmann  writes:
>
>> Package: compat-el
>> Version: 29.1.4.1-2
>> Severity: serious
>>
>> elpa-hl-todo/sid is currently uninstallable since it depends on
>> elpa-compat (>= 29.1.4.2).
>>
>>
>> Andreas
>
> Maybe it doesn't matter, but I don't think this is a serious bug in
> compat.el. It's not like a it's a regression. It's a serious bug in the
> package which is uninstallable.

Addendum: it does matter, there are a bunch of rdepends and unless they
all don't work with current elpa-compat, then it is needlessly
disruptive to auto-remove elpa-compat (or even to mark it for
auto-removal).

elpa-hl-todo has a versioned depends which is wrong.

Bug#1051543: grub2: Fails to load normal.mod from a XFS v5 parition.

[Felix Zielcke]

Am Samstag, dem 09.09.2023 um 15:41 +0200 schrieb Sebastian Andrzej
Siewior:
> Package: grub2
> Version: 2.12~rc1-9
> Severity: Serious
> control: forwarded -1 https://savannah.gnu.org/bugs/?64376
> 
> I have a single XFS partition which contains the root filesystem and
> the
> boot partition. Since the recent upgrade to the 2.12 series I can't
> boot
> anymore because grub complains that it can't find normal.mod and
> remains in
> the rescue shell.
> The ls command kind of works. A ls in /boot/grub/i386-pc/ (where the
> normal.mod should be) shows a few files and then abort with the error
> message: 'error: invalid XFS directory entry'.
> 

Hi Sebastian,

there's now a patch from Jon DeVree upstream, which might fix this for
you. Is it possible for you to test his patch?

https://lists.gnu.org/archive/html/grub-devel/2023-09/msg00059.html

Bug#1051965: compat-el: new upstream release 29.1.4.2 needed by elpa-hl-todo/sid

[David Bremner]

Andreas Beckmann  writes:

> Package: compat-el
> Version: 29.1.4.1-2
> Severity: serious
>
> elpa-hl-todo/sid is currently uninstallable since it depends on
> elpa-compat (>= 29.1.4.2).
>
>
> Andreas

Maybe it doesn't matter, but I don't think this is a serious bug in
compat.el. It's not like a it's a regression. It's a serious bug in the
package which is uninstallable.

d

Processed: reopen 1051577

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reopen 1051577
Bug #1051577 {Done: Luca Boccassi } [iproute2] iproute2: 
obsolete conffiles
Bug reopened
Ignoring request to alter fixed versions of bug #1051577 to the same values 
previously set
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
1051577: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051577
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1051577: iproute2: obsolete conffiles

[Luca Boccassi]

On Wed, 13 Sept 2023 at 10:44, Ian Campbell  wrote:
>
> On Tue, 2023-09-12 at 23:13 +0200, Luca Boccassi wrote:
> > On Mon, 11 Sept 2023 at 15:57, Daniel Gröber 
> > wrote:
> > >
> > > Hi Luca,
> > >
> > > On Mon, Sep 11, 2023 at 01:06:06PM +0100, Luca Boccassi wrote:
> > > > > I want to question whether removing these conffiles is a good idea at
> > > > > all. I'm probably one of the few people that actually muck around in 
> > > > > there
> > > > > but it seems like this is going to break things for any users that do.
> > > >
> > > > As far as I understand dpkg's conffile machinery should recognize if
> > > > you changed anything, and leave it in place. Upstream moved the
> > > > default ones to /usr, so we just follow what they do.
> > >
> > > Right. Think of an admin having to adjust these config files though:
> > > previously they could just `editor /etc/iproute2/rt_tables` and get on 
> > > with
> > > things. Now anyone needing to do that will have to do a doubletake, figure
> > > out why /etc/iproute2 is missing, realize that it's at /usr/lib/iproute2
> > > now, copy that over and finally edit.
> > >
> > > Is that friction really warrented to cater to a specialized niche 
> > > use-case?
> > >
> > > Please consider overriding upstream's decision here.
> >
> > Yes, it is warranted, both because it's exactly the correct behaviour
> > for a package, and also because we are certainly not spending time and
> > resources to go against upstream choices, especially when they are the
> > right choices.
>
> What is the plan for handling updates? AIUI we've lost the dpkg
> conffile handling but it doesn't look like it's been replaced by
> anything (e.g. like using ucf to prompt when an update happened
> perhaps?).

Same as everything else that uses drop-ins and hermetic-usr since
forever. No more pointless noise and wasting time solving conflicts by
hand in whitespace changes, comment typos and so on.

Processed: notfixed 1051577

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> notfixed 1051577 iproute2/6.5.0-3
Bug #1051577 {Done: Luca Boccassi } [iproute2] iproute2: 
obsolete conffiles
No longer marked as fixed in versions iproute2/6.5.0-3.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
1051577: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051577
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#1042911: (Still?) breaks Emacs 29.1 unattended-upgrade

[Farblos]

Not sure whether this is still relevant or just bad luck or whatever ... my
unattended-upgrade failed today because of this issue.  Logs available
on request.  Work-around was to remove version 3.20+dfsg-7, retrigger
the unattended upgrade, install version 3.20+dfsg-8.

Thanks for taking care of this package, BTW!

Bug#1050582: kmod update corrupts systemd uefi boot

[Martin Nybo Andersen]

Hi,

The problem is, that kmod has switched to using the kernel decompressor 
when available, which is XZ Embedded. This version doesn't handle CRC64 
and dictionaries larger than 1 MiB.


You can fix it by compressing the modules with `xz --check=crc32 
--lzma2=dict=1MiB module.ko`

This can easily be done by applying the following patch to your kernel git 
repository:


https://lore.kernel.org/all/3d34a965-ab9c-d549-0c63-c717ab5d2...@tweek.dk/

Afterwards `make modules_install` will compress and install the modules 
correctly.



Best regards,
Martin Nybo Andersen

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#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.

Processed: RM: rust-nom-3 -- ROM; depends on unavailable packages, obsolete

[Debian Bug Tracking System]

Processing control commands:

> block 984771 by -1
Bug #984771 [src:rust-nom-3] rust-nom-3: depends on multiple unavailable 
packages
984771 was not blocked by any bugs.
984771 was not blocking any bugs.
Added blocking bug(s) of 984771: 1051982

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

Bug#1051934: marked as done (python3-pyasn1-modules-lextudio has an undeclared file conflict)

[Debian Bug Tracking System]

Your message dated Fri, 15 Sep 2023 09:04:40 +
with message-id 
and subject line Bug#1051934: fixed in python-pyasn1-modules-lextudio 0.2.9-3
has caused the Debian Bug report #1051934,
regarding python3-pyasn1-modules-lextudio has an undeclared file conflict
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1051934: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051934
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: python3-pyasn1-modules-lextudio
Version: 0.2.9-1
Severity: serious
User: debian...@lists.debian.org
Usertags: fileconflict
Control: affects -1 + python3-pyasn1-modules

python3-pyasn1-modules-lextudio has an undeclared file conflict. This
may result in an unpack error from dpkg.

The files
 * /usr/lib/python3/dist-packages/pyasn1_modules/__init__.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/pem.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc1155.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc1157.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc1901.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc1902.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc1905.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc2251.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc2314.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc2315.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc2437.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc2459.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc2511.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc2560.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc2631.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc2634.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc2985.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc2986.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc3114.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc3161.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc3274.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc3279.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc3280.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc3281.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc3412.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc3414.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc3447.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc3560.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc3565.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc3709.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc3770.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc3779.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc3852.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc4043.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc4055.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc4073.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc4108.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc4210.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc4211.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc4334.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc4985.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5035.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5083.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5084.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5208.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5280.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5480.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5649.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5652.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5751.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5755.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5913.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5914.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5915.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5916.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5917.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5924.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5934.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5940.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5958.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc5990.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc6010.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc6019.py
 * /usr/lib/python3/dist-packages/pyasn1_modules/rfc6031.py
 * 

Bug#1051752: marked as done (uwsgi: remove uwsgi-plugin-glusterfs on 32 bit architectures)

[Debian Bug Tracking System]

Your message dated Fri, 15 Sep 2023 08:40:22 +
with message-id 
and subject line Bug#1051752: fixed in uwsgi 2.0.22-3
has caused the Debian Bug report #1051752,
regarding uwsgi: remove uwsgi-plugin-glusterfs on 32 bit architectures
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1051752: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051752
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: uwsgi
Version: 2.0.22-1
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

glusterfs dropped support for 32 bit architectures (see #1050629 for
details) and the binaries are being removed from trixie.
uwsgi-plugin-glusterfs is the last remaining binary package depending on
them on 32 bit architectures which prevents their removal. Please remove
uwsgi-plugin-glusterfs on all 32 bit architectures.

Cheers
-- 
Sebastian Ramacher
--- End Message ---
--- Begin Message ---
Source: uwsgi
Source-Version: 2.0.22-3
Done: Jonas Smedegaard 

We believe that the bug you reported is fixed in the latest version of
uwsgi, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1051...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jonas Smedegaard  (supplier of updated uwsgi package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Fri, 15 Sep 2023 09:46:25 +0200
Source: uwsgi
Architecture: source
Version: 2.0.22-3
Distribution: unstable
Urgency: medium
Maintainer: uWSGI packaging team 
Changed-By: Jonas Smedegaard 
Closes: 1051752
Changes:
 uwsgi (2.0.22-3) unstable; urgency=medium
 .
   * fix refreshing build-dependencies
 with custom command `DEB_MAINTAINER_MODE=1 debian/rules clean`
   * update arch-specific build-dependencies;
 really closes: bug#1051752, thanks (again) to Sebastian Ramacher
Checksums-Sha1:
 43bf29adf189b12213aae287f5d6578ab38b9f12 6963 uwsgi_2.0.22-3.dsc
 3aa67cf29cb80c90bc0b5388dc9c36b2871bc7a7 69556 uwsgi_2.0.22-3.debian.tar.xz
 dfa5bb2d317ae1864975b4e76fe5b9cb5569e8a9 37696 uwsgi_2.0.22-3_amd64.buildinfo
Checksums-Sha256:
 74a9ad0de16845c620abf32d5d9d24eb9eb45b78174c5cd139d3825abdfbaaa1 6963 
uwsgi_2.0.22-3.dsc
 61ca105bc145bb54772ac7f208803b90f2450afcc36ae18182b3eebe3e310f30 69556 
uwsgi_2.0.22-3.debian.tar.xz
 ecbd5a53d528d923143eaee389fd8e7205be2917c926b893724c1485ad1eb7d6 37696 
uwsgi_2.0.22-3_amd64.buildinfo
Files:
 9e2aaf84f719ffba855723d7a1b066ab 6963 httpd optional uwsgi_2.0.22-3.dsc
 267f8db094f47d0bd6fc4807ad0e3250 69556 httpd optional 
uwsgi_2.0.22-3.debian.tar.xz
 14ccacad0120f29da955168136517ec6 37696 httpd optional 
uwsgi_2.0.22-3_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmUEDrgACgkQLHwxRsGg
ASFmOg//XZ4S6yG0gw8LzIdOdJw2nWV48i0Kd3+ppXZ9SgUNKIqW4hXUxuEUp1hp
hNd2VtEeJsME6jyw/zQ2rFZQv6TMxBaUycBo3jtlS4YW5ZIptFx1y53Opg9FQkC4
Jgkhogx3iFlDSX99DVgnvxNKkfrhFL/i8TIFUXf2gzydz+dZsDAIqIkAMS9sB7Jp
abCKgMCZu0iqVeRemSeFoaVxtRFW5OqJb2gYU5bqFFbs50O1nR6RDRDPj+HT9eNO
EgpszYXmq+aoT3Nl4L447PEepVZqFhTg9o/WQBWn7VasOBDu1IQVuc8n9db8obJu
y7ZmrZUH+qVlGq9TlrdWfYN6P3H37TtjHyiSvdHHBWHn1MSwXXAwF23l0PS9MJ2I
1tCtJOSo5mbJ04G/VEV+UUtFrfRpkLTdv7wuMh797XlZm9NMdcq8cqj8ZaPVOT55
85QKkSvfr0Y6mx/63SpUgilSd4b2WWRms4aELAfsWU6UQX9PG6tI0mID0QMV99/c
teVCCE0tEKGWtL+YvtocLDmtaxnd1b4E0tpbguope1+6LQnJwgZXbgiIb5bWrLe0
AoBS40PFeUblpfYTcEOEHILwMwuvsSOr53F0GDQxIyI4lmGxjGi2KDan/7riXXPv
25unTdWXs7URgiw0HnGML+/Ej0kx0bgfhWCcYn47WMATIzAnaQ4=
=Wk/0
-END PGP SIGNATURE End Message ---

Processed: Bug#1051934 marked as pending in python-pyasn1-modules-lextudio

[Debian Bug Tracking System]

Processing control commands:

> tag -1 pending
Bug #1051934 [python3-pyasn1-modules-lextudio] python3-pyasn1-modules-lextudio 
has an undeclared file conflict
Added tag(s) pending.

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

Bug#1051934: marked as pending in python-pyasn1-modules-lextudio

[Thomas Goirand]

Control: tag -1 pending

Hello,

Bug #1051934 in python-pyasn1-modules-lextudio reported by you has been fixed 
in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/openstack-team/third-party/python-pyasn1-modules-lextudio/-/commit/336c08d3f25b4447361a65ba88e4b499db6c7f66


Added Conflicts: python3-pyasn1-modules (Closes: #1051934).


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1051934

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#1051819: marked as done (fluidsynth: Consider building with pipewire support)

[Debian Bug Tracking System]

Your message dated Fri, 15 Sep 2023 06:49:00 +
with message-id 
and subject line Bug#1051819: fixed in fluidsynth 2.3.3-2.1
has caused the Debian Bug report #1051819,
regarding fluidsynth: Consider building with pipewire support
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1051819: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051819
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: fluidsynth
Version: 2.3.1-2
Severity: wishlist

Dear Maintainer,

Please consider building fluidsynth with pipewire support.
While it is working adequately via the pulseaudio compatibility layer,
it would be nice to utilize the native support added in 2.3.0 as it is
the default sound server in Debian 12.

It looks like all that is needed is a Build-Depends on libpipewire-0.3-dev
to have cmake pick up on it.

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

Kernel: Linux 6.1.0-11-amd64 (SMP w/4 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 fluidsynth depends on:
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u1
ii  libfluidsynth3   2.3.1-2
ii  libglib2.0-0 2.74.6-2
ii  libsdl2-2.0-02.26.5+dfsg-1
ii  libsystemd0  252.12-1~deb12u1

Versions of packages fluidsynth recommends:
ii  qsynth  0.9.9-1

fluidsynth suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---
Source: fluidsynth
Source-Version: 2.3.3-2.1
Done: Gianfranco Costamagna 

We believe that the bug you reported is fixed in the latest version of
fluidsynth, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1051...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Gianfranco Costamagna  (supplier of updated 
fluidsynth package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 14 Sep 2023 07:22:04 +0200
Source: fluidsynth
Built-For-Profiles: noudeb
Architecture: source
Version: 2.3.3-2.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Multimedia Maintainers 
Changed-By: Gianfranco Costamagna 
Closes: 1051819
Changes:
 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)
Checksums-Sha1:
 eb96ebda40226ee0598403b69126a46a749729ea 2545 fluidsynth_2.3.3-2.1.dsc
 bf0198870f06f540b60b9e4039267bc0e183c425 19724 
fluidsynth_2.3.3-2.1.debian.tar.xz
 49cd3c51107b55c056668cc83cfd02a456132d0e 14375 
fluidsynth_2.3.3-2.1_source.buildinfo
Checksums-Sha256:
 43b1afb3a418f7223fa91b110074545429f59ea8c5f0c872d0768722206a7da7 2545 
fluidsynth_2.3.3-2.1.dsc
 1fe1bb371ef8f4d32a30a2d4ea95fe6f0f7750ee83d917066e91fe546f59b747 19724 
fluidsynth_2.3.3-2.1.debian.tar.xz
 86ee96f279d66c1b56fd8b3e654d82f95424e4ac119f334d5ac24ef509d65a6d 14375 
fluidsynth_2.3.3-2.1_source.buildinfo
Files:
 afbc9303a33a40ba3f685659891af5d8 2545 sound optional fluidsynth_2.3.3-2.1.dsc
 ba6637e07ba0e0fe2a3501d9e81ca501 19724 sound optional 
fluidsynth_2.3.3-2.1.debian.tar.xz
 dcd45afd87a73e7b0cd899cbe9bfd77e 14375 sound optional 
fluidsynth_2.3.3-2.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkpeKbhleSSGCX3/w808JdE6fXdkFAmUD+KAACgkQ808JdE6f
XdmInw/9FQKuOc7GZI8stfqgcNsI9dYT9Fx9BUkGqVIyI58WXKCg3xo3FBtrTNSq
AlkfrQy+TR0/CpKzvMb2HVYty41k5dfXZckr+oWn5wbq+Y35MS4dCq5bxW9VbSjS
sJkhzshC5amx/kpfsRjhqca8BJn2S3p0BnHDgW/A4IVn9gwK7en+RI75GcRubsjO
mcStR9f4PbOhRJ+k8yGHpF5FCOmBQcP5KGnr5d+LDvNfSrSFpsP3LfNvF+v/aT43
lxrk1sRRUeoy2IiLCVFdxuTgWaz4L/NHcThCNrM/Vqu/EjHfFdHg/BwK0/+gIrMP
Ul2Yf6EIW9hEhq32zdgimZJ56aCRpwh78ydgoO1zZpV1HEOuEAcGjDWLYSnt3WqY
YD3JGjsz5XjhLiL6n4+LW1INcwiJsrDf97aa03LCuxCVlABvbREa8x4EGzMVuAKc
UawUzInYRtDLvl8PqANK1spQxG3pVVDcw+a5krd7sCSg6m1FWE+smkPK6emEuCKw
mDBW9VDJJW4zB4ZjLBkU6futlqsTGs4ZKtOvCssDGRUHh+5TDFUFjJW7KBoYJluG

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

Processed: Re: fluidsynth: Consider building with pipewire support

[Debian Bug Tracking System]

Processing control commands:

> tags 1051819 + patch
Bug #1051819 [fluidsynth] fluidsynth: Consider building with pipewire support
Ignoring request to alter tags of bug #1051819 to the same tags previously set
> tags 1051819 + pending
Bug #1051819 [fluidsynth] fluidsynth: Consider building with pipewire support
Added tag(s) pending.

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

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

Processed (with 1 error): Re: ldap-account-manager: Multiple embeded and minified javascript library

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 1042528 - FTBFS
Unknown tag/s: FTBFS.
Recognized are: patch wontfix moreinfo unreproducible help security upstream 
pending confirmed ipv6 lfs d-i l10n newcomer a11y ftbfs fixed-upstream fixed 
fixed-in-experimental sid experimental potato woody sarge sarge-ignore etch 
etch-ignore lenny lenny-ignore squeeze squeeze-ignore wheezy wheezy-ignore 
jessie jessie-ignore stretch stretch-ignore buster buster-ignore bullseye 
bullseye-ignore bookworm bookworm-ignore trixie trixie-ignore forky 
forky-ignore.

Bug #1042528 [src:ldap-account-manager] ldap-account-manager: Multiple embeded 
and minified javascript library
Requested to remove no tags; doing nothing.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
1042528: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042528
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#1051752 closed by Debian FTP Masters (reply to Jonas Smedegaard ) (Bug#1051752: fixed in uwsgi 2.0.22-2)

[Debian Bug Tracking System]

Processing control commands:

> reopen -1
Bug #1051752 {Done: Jonas Smedegaard } [src:uwsgi] uwsgi: remove 
uwsgi-plugin-glusterfs on 32 bit architectures
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions uwsgi/2.0.22-2.

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

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

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

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 libopendht2 2.6.0.4-1
Bug #1051972 [jami-daemon] jami-daemon: Fails to start with libopendht2 
2.6.0.4-1
Bug reassigned from package 'jami-daemon' to 'libopendht2'.
No longer marked as found in versions ring/20230206.0~ds2-1.3.
Ignoring request to alter fixed versions of bug #1051972 to the same values 
previously set
Bug #1051972 [libopendht2] jami-daemon: Fails to start with libopendht2 
2.6.0.4-1
Marked as found in versions opendht/2.6.0.4-1.
> retitle -1 libopendht2: broke ABI without SONAME bump
Bug #1051972 [libopendht2] jami-daemon: Fails to start with libopendht2 
2.6.0.4-1
Changed Bug title to 'libopendht2: broke ABI without SONAME bump' from 
'jami-daemon: Fails to start with libopendht2 2.6.0.4-1'.
> affects -1 jami-daemon
Bug #1051972 [libopendht2] libopendht2: broke ABI without SONAME bump
Added indication that 1051972 affects jami-daemon

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

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