Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

[Eli Zaretskii]

> Date: Sat, 5 Nov 2022 13:54:54 -0700
> Cc: vinc...@vinc17.net, spwhit...@spwhitton.name, 58...@debbugs.gnu.org,
>  1017...@bugs.debian.org
> From: Paul Eggert 
> 
> On 2022-11-04 00:00, Eli Zaretskii wrote:
> > We need to establish what is the
> > source of SIGHUP in these cases.  "These cases" mean, AFAIU, the
> > situations where Emacs launched an async subprocess to do native
> > compilation (which is another Emacs process in a --batch session), and
> > the parent Emacs session is terminated by the user before the async
> > compilation runs to completion.  Would the child Emacs process get
> > SIGHUP in this scenario?
> 
> Hard for me to say. It's a messy area, with kernels (and Emacs itself) 
> sending SIGHUP on various whims.

But is it possible for a program like Emacs to get SIGHUP in such a
situation, or is that highly improbable?  We have standard streams of
the inferior Emacs process connected via PTYs to the parent process, I
believe -- does that deliver SIGHUP or SIGPIPE when the parent exits?

> Does the attached patch fix things? It builds on your commit 
> 190a6853708ab22072437f6ebd93beb3ec1a9ce6 dated 2020-12-04; I don't know 
> why that earlier patch was installed, but it would seem to apply to 
> SIGHUP and SIGTERM as well as it applies to SIGINT.

I was trying to be conservative, that's all.  I'm okay with doing the
same for SIGHUP.  Vincent, can you try this patch, please?

Bug#1023504: pipewire: moc play no sound if pulseaudio purged from system

[Thom]

Package: pipewire
Version: 0.3.59-1+b1
Followup-For: Bug #1023504
X-Debbugs-Cc: thom1...@gmail.com


Hi, Patrice!

pipewire-pulse already installed in my system.
Sorry, i forgot to mention it.

Your solution in message #15 do the trick for me.

Thanks a lot for you help!

Bug#1023529: subversion: FTBFS: segfault in Python tests with SWIG 4.1.0

[Paul Wise]

Source: subversion
Version: 1.14.2-3
Severity: serious
Tags: ftbfs patch fixed-upstream
Forwarded: https://github.com/swig/swig/issues/2373 
https://github.com/apache/subversion/commit/8ff4cfd06ce554e9df31a088c9d09f45278c6de4
 https://svn.apache.org/repos/asf/subversion/trunk@1904167

subversion FTBFS in sid (on all arches, but detected below on amd64 and
by the buildds on riscv64) due to a segfault in the Python tests when
building with SWIG 4.1.0. The issue has been fixed upstream in the
subversion git/svn repos, see the URLs above.

   pabs@barriere:~$ dd-schroot-cmd -y -c $sessionid apt-get build-dep subversion
   ...
   Get:286 https://deb.debian.org/debian sid/main amd64 swig4.0 amd64 4.1.0-0.1 
[1387 kB]
   Get:287 https://deb.debian.org/debian sid/main amd64 swig all 4.1.0-0.1 [321 
kB]
   ...
   Selecting previously unselected package swig4.0.
   Preparing to unpack .../285-swig4.0_4.1.0-0.1_amd64.deb ...
   Unpacking swig4.0 (4.1.0-0.1) ...
   Selecting previously unselected package swig.
   Preparing to unpack .../286-swig_4.1.0-0.1_all.deb ...
   Unpacking swig (4.1.0-0.1) ...
   ...
   Setting up swig4.0 (4.1.0-0.1) ...
   ...
   Setting up swig (4.1.0-0.1) ...
   ...
   pabs@barriere:~$ schroot -r -c $sessionid
   (sid_amd64-dchroot)pabs@barriere:~$ apt source subversion
   ...
   (sid_amd64-dchroot)pabs@barriere:~$ cd subversion-*/
   (sid_amd64-dchroot)pabs@barriere:~/subversion-1.14.2$ debuild -J10
   ...
   finished...
   make[2]: Leaving directory '/home/pabs/subversion-1.14.2/BUILD'
   make[1]: Leaving directory '/home/pabs/subversion-1.14.2'
  debian/rules override_dh_auto_test-arch
   make[1]: Entering directory '/home/pabs/subversion-1.14.2'
   /usr/bin/make -f debian/rules check-swig-py check-swig-pl check-swig-rb 
check-javahl check
   make[2]: Entering directory '/home/pabs/subversion-1.14.2'
   make[2]: warning: -j10 forced in makefile: resetting jobserver mode.
   set -e; for v in 3.10; do rm -f 
/home/pabs/subversion-1.14.2/BUILD/subversion/bindings/swig/python; ln -sfT 
python$v /home/pabs/subversion-1.14.2/BUILD/subversion/bindings/swig/python; 
pyinc=$(python$v-config --includes); pylib=$(python$v -c 'from distutils import 
sysconfig; print(sysconfig.get_python_lib())');  /usr/bin/make -C 
/home/pabs/subversion-1.14.2/BUILD LTFLAGS="--tag=CC --verbose" 
LTCXXFLAGS="--tag=CXX --verbose" check-swig-py PYTHON=python$v PYVER=$v 
CLEANUP=1 LC_ALL=C; ln -sfT python3.10 
/home/pabs/subversion-1.14.2/BUILD/subversion/bindings/swig/python; done
   :1: DeprecationWarning: The distutils package is deprecated and 
slated for removal in Python 3.12. Use setuptools or check PEP 632 for 
potential alternatives
   :1: DeprecationWarning: The distutils.sysconfig module is 
deprecated, use sysconfig instead
   make[3]: Entering directory '/home/pabs/subversion-1.14.2'
   make[3]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
   mkdir 
/home/pabs/subversion-1.14.2/BUILD/subversion/bindings/swig/python/libsvn
   if [ "LD_LIBRARY_PATH" = "DYLD_LIBRARY_PATH" ]; then for d in 
/home/pabs/subversion-1.14.2/BUILD/subversion/bindings/swig/python/libsvn_swig_py
 
/home/pabs/subversion-1.14.2/BUILD/subversion/bindings/swig/python/../../../libsvn_*;
 do if [ -n "$DYLD_LIBRARY_PATH" ]; then 
LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$d/.libs"; else LD_LIBRARY_PATH="$d/.libs"; 
fi; done; export LD_LIBRARY_PATH; fi; \
   cd /home/pabs/subversion-1.14.2/BUILD/subversion/bindings/swig/python; \
 python3.10 
/home/pabs/subversion-1.14.2/BUILD/../subversion/bindings/swig/python/tests/run_all.py
   make[3]: *** [Makefile:944: check-swig-py] Segmentation fault
   make[3]: Leaving directory '/home/pabs/subversion-1.14.2/BUILD'
   make[2]: *** [debian/rules:252: check-swig-py] Error 2
   make[2]: Leaving directory '/home/pabs/subversion-1.14.2'
   make[1]: *** [debian/rules:232: override_dh_auto_test-arch] Error 2
   make[1]: Leaving directory '/home/pabs/subversion-1.14.2'
   make: *** [debian/rules:197: binary] Error 2
   dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2
   debuild: fatal error at line 1182:
   dpkg-buildpackage -us -uc -ui -J10 failed

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1008735: base-files: /etc/os-release should contain VERSION variables for testing and unstable

[Witold Baryluk]

Package: base-files
Version: 12.3
Followup-For: Bug #1008735
X-Debbugs-Cc: witold.bary...@gmail.com

I am somehow confused by the current solution in base-files 12.3.

bookworm:

$ lsb_release -s -i -d -r -c
No LSB modules are available.
Debian
Debian GNU/Linux bookworm/sid
n/a
bookworm
$

sid:

$ lsb_release -s -i -d -r -c 
No LSB modules are available.
Debian
Debian GNU/Linux bookworm/sid
n/a
bookworm
$



How one can distinguish between testing / bookworm and sid now? Do I need
to parse files in /etc/apt/sources.list.d/ now, maybe using `apt-cache
policy base-files` ?

There are practical situations where bookworm and sid are out of sync for
months, and this is important to distinguish in many places.

Regards,
Witold

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

Kernel: Linux 6.1.0-rc3 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, 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)

Versions of packages base-files depends on:
ii  gawk [awk]  1:5.1.0-1
ii  mawk [awk]  1.3.4.20200120-3.1

base-files recommends no packages.

base-files suggests no packages.

-- no debconf information

Bug#1023528: mipsel: crash: VEX: Unsupported baseline Found: Loongson-baseline

[Adam Borowski]

Package: valgrind
Version: 1:3.19.0-1
Severity: normal

Hi!
On any modern mips machine (ie, loongson -- at least as our infra is
concerned; CIP United is rumoured to disagree), valgrind crashes with:

.
VEX: Unsupported baseline
 Found: Loongson-baseline
Cannot continue. Good-bye

vex storage: T total 0 bytes allocated
vex storage: P total 0 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().

host stacktrace:
==1833049==at 0x5804FB44: ??? (in 
/usr/libexec/valgrind/memcheck-mips32-linux)
==1833049==by 0x5804FA2C: ??? (in 
/usr/libexec/valgrind/memcheck-mips32-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 1833049)
==1833049==at 0x401B920: __start (in /lib/mipsel-linux-gnu/ld.so.1)
==1833049==by 0x7EB7B088: ???
client stack range: [0x7EB78000 0x7EB7BFFF] client SP: 0x7EB7B090
valgrind stack range: [0x42878000 0x42977FFF] top usage: 5512 of 1048576


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using.  Thanks.
`

Bug#1023527: mips64el: false positive 100% calls of memcheck; rseq in all tools

[Adam Borowski]

Package: valgrind
Version: 1:3.19.0-1
Severity: normal

Hi!
Valgrind reports a false positive during glibc initialization on mips64el:

Conditional jump or move depends on uninitialised value(s)
   at 0x400746C: cached_fpabi_reject_phdr_p (dl-machine-reject-phdr.h:57)
   by 0x400746C: elf_machine_reject_phdr_p (dl-machine-reject-phdr.h:217)
   by 0x40079E0: open_verify.constprop.0 (dl-load.c:1793)
   by 0x400ABA8: _dl_map_object (dl-load.c:2211)
   by 0x401DA2C: map_doit (rtld.c:647)
   by 0x401B3C8: _dl_catch_exception (dl-error-skeleton.c:208)
   by 0x401B478: _dl_catch_error (dl-error-skeleton.c:227)
   by 0x401D96C: do_preload (rtld.c:822)
   by 0x401F058: handle_preload_list (rtld.c:898)
   by 0x4021BC4: dl_main (rtld.c:1859)
   by 0x401CD98: _dl_sysdep_start (dl-sysdep.c:140)
   by 0x401E3D0: _dl_start_final (rtld.c:497)
   by 0x401E684: _dl_start (rtld.c:586)

This makes all packages that run valgrind during their testsuite fail if
they consider this error to be fatal.

Also, all tools report the following warning:

WARNING: unhandled mips64-linux syscall: 5327
You may be able to write your own handler.
Read the file README_MISSING_SYSCALL_OR_IOCTL.
Nevertheless we consider this a bug.  Please report
it at http://valgrind.org/support/bug_reports.html.

The syscall in question is rseq, added in 2018.  For a package to fail
it'd need to do so on unexpected stderr -- but that's the default for
some test engines.

Bug#1023526: s390x: false positive in drd: memcpy > _IO_new_file_xsputn

[Adam Borowski]

Package: valgrind
Version: 1:3.19.0-1
Severity: normal
Tags: patch

Hi!
As detected by valgrind-if-available testsuite (on zelenka, as buildds
for this arch are slooow), drd reports the following false positive:

.
drd, a thread error detector
Copyright (C) 2006-2020, and GNU GPL'd, by Bart Van Assche.
Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
Command: /tmp/___

Thread 3:
Conflicting store by thread 3 at 0x052581c0 size 2
   at 0x486A32A: memcpy (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x490EBBD: _IO_new_file_xsputn (fileops.c:1235)
   by 0x490EBBD: _IO_file_xsputn@@GLIBC_2.2 (fileops.c:1196)
   by 0x48EA709: outstring_func (vfprintf-internal.c:239)
   by 0x48EA709: __vfprintf_internal (vfprintf-internal.c:767)
   by 0x48E0715: printf@@GLIBC_2.4 (printf.c:33)
   by 0x108B7B: worker (threaded.c:16)
   by 0x484C1B7: ??? (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x491779F: start_thread (pthread_create.c:442)
   by 0x49942FD: ??? (clone.S:66)
   by 0x: ???
Address 0x52581c0 is at offset 0 from 0x52581c0. Allocation context:
   at 0x48456DE: malloc (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x4901215: _IO_file_doallocate (filedoalloc.c:101)
   by 0x4910A83: _IO_doallocbuf (genops.c:347)
   by 0x4910A83: _IO_doallocbuf (genops.c:342)
   by 0x490FCC3: _IO_file_overflow@@GLIBC_2.2 (fileops.c:744)
   by 0x490EC61: _IO_new_file_xsputn (fileops.c:1243)
   by 0x490EC61: _IO_file_xsputn@@GLIBC_2.2 (fileops.c:1196)
   by 0x48EA709: outstring_func (vfprintf-internal.c:239)
   by 0x48EA709: __vfprintf_internal (vfprintf-internal.c:767)
   by 0x48E0715: printf@@GLIBC_2.4 (printf.c:33)
   by 0x108B7B: worker (threaded.c:16)
   by 0x484C1B7: ??? (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x491779F: start_thread (pthread_create.c:442)
   by 0x49942FD: ??? (clone.S:66)
   by 0x: ???
Other segment start (thread 2)
   at 0x49942A8: clone (clone.S:48)
   by 0x49954C3: __clone_internal (clone-internal.c:83)
   by 0x: ???
Other segment end (thread 2)
   at 0x48639F2: pthread_rwlock_wrlock@* (in 
/usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x108BE7: worker (threaded.c:23)
   by 0x484C1B7: ??? (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x491779F: start_thread (pthread_create.c:442)
   by 0x49942FD: ??? (clone.S:66)
   by 0x: ???

Conflicting store by thread 3 at 0x052581c6 size 1
   at 0x486A35E: memcpy (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x490EBBD: _IO_new_file_xsputn (fileops.c:1235)
   by 0x490EBBD: _IO_file_xsputn@@GLIBC_2.2 (fileops.c:1196)
   by 0x48EA709: outstring_func (vfprintf-internal.c:239)
   by 0x48EA709: __vfprintf_internal (vfprintf-internal.c:767)
   by 0x48E0715: printf@@GLIBC_2.4 (printf.c:33)
   by 0x108B7B: worker (threaded.c:16)
   by 0x484C1B7: ??? (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x491779F: start_thread (pthread_create.c:442)
   by 0x49942FD: ??? (clone.S:66)
   by 0x: ???
Address 0x52581c6 is at offset 6 from 0x52581c0. Allocation context:
   at 0x48456DE: malloc (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x4901215: _IO_file_doallocate (filedoalloc.c:101)
   by 0x4910A83: _IO_doallocbuf (genops.c:347)
   by 0x4910A83: _IO_doallocbuf (genops.c:342)
   by 0x490FCC3: _IO_file_overflow@@GLIBC_2.2 (fileops.c:744)
   by 0x490EC61: _IO_new_file_xsputn (fileops.c:1243)
   by 0x490EC61: _IO_file_xsputn@@GLIBC_2.2 (fileops.c:1196)
   by 0x48EA709: outstring_func (vfprintf-internal.c:239)
   by 0x48EA709: __vfprintf_internal (vfprintf-internal.c:767)
   by 0x48E0715: printf@@GLIBC_2.4 (printf.c:33)
   by 0x108B7B: worker (threaded.c:16)
   by 0x484C1B7: ??? (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x491779F: start_thread (pthread_create.c:442)
   by 0x49942FD: ??? (clone.S:66)
   by 0x: ???
Other segment start (thread 2)
   at 0x49942A8: clone (clone.S:48)
   by 0x49954C3: __clone_internal (clone-internal.c:83)
   by 0x: ???
Other segment end (thread 2)
   at 0x48639F2: pthread_rwlock_wrlock@* (in 
/usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x108BE7: worker (threaded.c:23)
   by 0x484C1B7: ??? (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x491779F: start_thread (pthread_create.c:442)
   by 0x49942FD: ??? (clone.S:66)
   by 0x: ???

Conflicting store by thread 3 at 0x052581c7 size 1
   at 0x486A090: memcpy (in /usr/libexec/valgrind/vgpreload_drd-s390x-linux.so)
   by 0x490EBBD: _IO_new_file_xsputn (fileops.c:1235)
   by 0x490EBBD: _IO_file_xsputn@@GLIBC_2.2 (fileops.c:1196)
   by 0x48EBB71: outstring_func (vfprintf-internal.c:239)
   by 0x48EBB71: __vfprintf_internal (vfprintf-process-arg.c:213)
   by 0x48E0715: printf@@GLIBC_2.4 (printf.c:33)
   by 0x108B7B: worker (threaded.c:16)
   by 0x484C1B7: ??? (in 

Bug#1023500: grpc-java: FTBFS with protobuf 3.21

[Olek Wojnar]

Control: tags -1 confirmed

Hi László,

On 11/5/22 08:50, László Böszörményi (GCS) wrote:


I would like to start the Protobuf transition. Your package fails to
build since it tries to include a header which is moved to a new name.
Simple patch is attached to update this.
Please be prepared to upload the updated package when the transition starts.


Thanks for letting me know. The patch looks pretty trivial, I'll add it 
to packaging in the next couple days and will be ready to upload when 
3.21 hits unstable.


-Olek


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023525: Empty candidate window in x11 sessions

[Gunnar Hjalmarsson]

Package: ibus-mozc
Version: 2.28.4715.102+dfsg-2
Severity: serious

When using ibus-mozc in x11 sessions, the candidate window is empty. I 
see the issue in Debian unstable (GNOME on Xorg), and have previously 
confirmed it in Ubuntu on Xorg and Xubuntu. The issue is not present in 
wayland sessions.


The issue seems to be related to the fix of 
. In Ubuntu 22.10 that fix was reverted 
for now to make ibus-mozc usable also on x11:


https://launchpad.net/ubuntu/+source/mozc/2.28.4715.102+dfsg-1ubuntu1

Related Ubuntu bug: https://launchpad.net/bugs/1987010

--
Regards,
Gunnar

Bug#1023524: sudo should provide a dh-nss definition for the `sudoers` NSS database

[Gioele Barabucci]

Source: sudo
Version: 1.9.11p3-2
Tags: patch
X-Debbugs-CC: pkg-sssd-de...@alioth-lists.debian.net

Dear sudo maintaners,

could you please introduce a `libnss-sudo` (or `libnss-sudoers`) whose 
job is to add the `sudoers` database line in `/etc/nsswitch.conf` via 
`dh_installnss(1)`?


A patch that adds a `libnss-sudo` to `src:sudo` is available at:

https://salsa.debian.org/sudo-team/sudo/-/merge_requests/12

`dh_installnss` (part of `dh-nss`) provides a declarative way to manage 
NSS databases and services. Almost all Debian packages that install NSS 
services have been converted to `dh-nss`.


Introducing `libnss-sudo` and moving to `dh-nss` will also solve the 
issues described in #783889 [1]. sssd has already been converted to 
dh-nss [2,3]. The last remaining piece of the puzzle is having the 
`sudoers` database declared in an ad-hoc package like `libnss-sudo`.


Regards,

[1] https://bugs.debian.org/783889
[2] https://salsa.debian.org/sudo-team/sudo/-/merge_requests/12
[3] https://salsa.debian.org/sssd-team/sssd/-/merge_requests/16

--
Gioele Barabucci

Bug#979186: [Aptitude-devel] Bug#979186: Bug#979186: aptitude: in the TUI, "+" changes the version of some packages in an inconsistent way

[Vincent Lefevre]

Control: found -1 0.8.13-5

On 2021-02-14 12:28:00 +0100, Vincent Lefevre wrote:
> On 2021-01-04 11:35:46 +0100, Axel Beckert wrote:
> > Will have a closer look later, earliest this evening.
> 
> Any news?

This occurred again:

i   libc-bin   2.35-1   2.36-4
i A libc6  2.35-1   2.35-1
i A libc6-i386 2.35-1   2.36-4
i A libc6-x32  2.35-1   2.36-4

but

zira:~> apt-show-versions -a libc6
libc6:amd64 2.35-1 install ok installed
libc6:amd64 2.31-13+deb11u4 stable ftp.debian.org
libc6:amd64 2.31-13+deb11u5 stable-updates ftp.debian.org
libc6:amd64 2.35-4  testingftp.debian.org
libc6:amd64 2.36-4  unstable   ftp.debian.org
No experimental version
libc6:amd64/unstable 2.35-1 upgradeable to 2.36-4

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

Bug#1023523: RFP: poxy -- Documentation generator for C++ based on Doxygen and mosra/m.css

[Bastian Germann]

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

* Package name: poxy
  Version : 0.11.1
  Upstream Author : Mark Gillard 
* URL : https://github.com/marzer/poxy
* License : Expat
  Programming Lang: Python
  Description : Documentation generator for C++ based on Doxygen and 
mosra/m.css

mosra/m.css is a Doxygen-based documentation generator that significantly improves on Doxygen's 
default output by controlling some of Doxygen's more unruly options, supplying it's own HTML+CSS 
generation and adding a live search feature. Poxy builds upon both by:


  * Moving the configuration out into a TOML file
  * Preprocessing the Doxygen XML to fix a bunch of Doxygen bugs quirks
  * Postprocessing the generated HTML to improve syntax highlighting
  * Allowing source, image and example directories to be recursive
  * Automatically defining C++ language feature macros based on your project's 
target C++ version
  * Automatically integrating the cppreference.com doxygen tagfile
  * Providing a number of additional built-in doxygen @alias commands
  * Giving more control over the HTML inline using square-bracket [tags][/tags]
  * Adding a switchable light theme
  * Adding support for C++20 concepts
  * Self-hosting fonts to reduce external HTTP requests
  * Inlining SVGs so they can take advantage of currentColor

Bug#1022953: qmltermwidget: Package as separate Debian source package

[Mike Gabriel]

Hi Gürkan,

On  Mo 31 Okt 2022 10:32:34 CET, Gürkan Myczko wrote:


Dear Gürkan (maintainer of cool-retro-termin in Debian), dear Filippo
(upstream if cool-retro-term),


Dear Mike,


we (Ubuntu Touch developer team) are maintaining an Ubuntu Touch app
called lomiri-terminal-app. This app bundles an embedded copy of
qmlterminwidget. The lomiri-terminal-app has also just been uploaded
to Debian unstable (as part of the complete Lomiri Operating
Environment, formerly known as Ubuntu's Unity8).

We would like to get rid of the embedded copy of qmltermwidget code in
lomiri-terminal-app and would like to bundle efforts on qmltermwidget
upstream development and Debian package maintenance.


That is a good plan, already suggested with #991987


I have now uploaded qmltermwidget as a standalone library/QML module package.

See ITP #1023522.


The current packaging situation of qmltermwidget in Debian is
suboptimal as it is wrapped into the cool-retro-term source package in
Debian [1] and also versioned with cool-retro-term (i.e. both
packages  have the same Debian package version). From my perspective,
qml-module-qmltermwidget should be a standalone source package (with
its own software/package version). On the upstream side qmltermwidget
is also a separate Git upstream project [2] and only bundled into
cool-retro-term via Git submoduling. However, for upstream's
qmltermwidget I don't see any recent release tags.

One of our Ubuntu Touch devs (Guido Berhörster) has already worked on
preparing some upstream pull requests for qmltermwidget so that
qmltermwidget on Github [2] will become usable for Ubuntu Touch /
lomiri-terminal-app. These PRs will be communicated directly on
Github.


I have no objections to split qmltermwidget out of cool-retro-term,
please go ahead.


Thanks!


For Debian, I'd like to propose splitting out the qmltermwidget
bin:pkg out of cool-retro-term src:pkg and uploading qmltermwidget as
a separate src:pkg. I could handle this packaging + uploading, if ok
with Gürkan.

From upstream, this would ideally require some qmltermwidget release
tagging in the future, so we in Debian get notified about changes
worth-to-be-updated-and-packaged. In cool-retro-term, you would have
to specify a minimal version of qmltermwidget that is required to
successfully run/build cool-retro-term.


Ack. I would like to suggest to add me to uploaders for the new qmltermwidget
package.


Done. I also already invited you as Maintainer to the qmltermwidget  
Git repo on Salsa.



I know some projects are lazy about tagging realeases which
I "solve" with the git2deb script, available here:
https://salsa.debian.org/debian/devscripts/-/merge_requests/276


I use another approach (as always in Debian). I simply have a special  
debian/watch file and retrieve the Git snapshot as orig.tar.xz using  
uscan.



Would you guys be open to such a shift? Could we get this done before
the Debian 12 freeze (Jan 12th 2023). This would mean that we should
get started with is the coming days.


Sounds like a good plan.


Once the package has landed in Debian unstable, I can upload and  
adjust cool-retro-term. Or you do it. Let me know what you prefer.


The new qmltermwidget can co-exist with qml-module-qmltermwidget from  
cool-retro-term as the new QML module package will have a slightly  
different name: qml-module-termwidget.


So, a smooth transition is possible. I also already tested the new  
qml-module-termwidget package with cool-retro-term (on Debian  
bullseye, though).


Furthermore, the new qml-module-termwidget also contains Guido's  
Lomiri Terminal App patches [1], so we are good to go and also use  
qmltermwidget with lomiri-terminal-app in Debian.


Greets,
Mike

[1] https://github.com/Swordfish90/qmltermwidget/pull/39
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpHZX_jFrklp.pgp
Description: Digitale PGP-Signatur

Bug#1023419: transition: freeglut

[Anton Gladky]

Uploaded, thanks!

Anton

Bug#1017711: bug#58956: mark_object, mark_objects(?) crash

[Paul Eggert]

On 2022-11-04 00:00, Eli Zaretskii wrote:

We need to establish what is the
source of SIGHUP in these cases.  "These cases" mean, AFAIU, the
situations where Emacs launched an async subprocess to do native
compilation (which is another Emacs process in a --batch session), and
the parent Emacs session is terminated by the user before the async
compilation runs to completion.  Would the child Emacs process get
SIGHUP in this scenario?


Hard for me to say. It's a messy area, with kernels (and Emacs itself) 
sending SIGHUP on various whims.


Does the attached patch fix things? It builds on your commit 
190a6853708ab22072437f6ebd93beb3ec1a9ce6 dated 2020-12-04; I don't know 
why that earlier patch was installed, but it would seem to apply to 
SIGHUP and SIGTERM as well as it applies to SIGINT.diff --git a/src/emacs.c b/src/emacs.c
index 1b2aa9442b..92e2299a04 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -432,9 +432,9 @@ terminate_due_to_signal (int sig, int backtrace_limit)
   if (sig == SIGTERM || sig == SIGHUP || sig == SIGINT)
 	{
 	  /* Avoid abort in shut_down_emacs if we were interrupted
-		 by SIGINT in noninteractive usage, as in that case we
+		 in noninteractive usage, as in that case we
 		 don't care about the message stack.  */
-	  if (sig == SIGINT && noninteractive)
+	  if (noninteractive)
 		clear_message_stack ();
 	  Fkill_emacs (make_fixnum (sig), Qnil);
 	}

Bug#1023522: ITP: qmltermwidget -- Terminal Widget QML module

[Mike Gabriel]

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

* Package name: qmltermwidget
  Version : 0.2+
  Upstream Author : Filippo Scognamiglio 
* URL : https://github.com/Swordfish90/qmltermwidget
* License : GPL-2+, LGPL-2+
  Programming Lang: C, C++, QML
  Description : Terminal Widget QML module

 This project is a QML port of qtermwidget. It is written to be as close
 as possible to the upstream project in order to make cooperation
 possible.
 .
 At the moment this plugin is powering cool-retro-term and the
 lomiri-terminal-app.
 .
 This package will be maintained by the cool-retro-term package maintainer
 and by Debian's UBports Packaging Team.

Bug#1022526: python-ssdeep: FTBFS: distutils.errors.DistutilsClassError: command class must subclass Command

[Peter Wienemann]

Dear Helmut,

On 04.11.22 10:36, Helmut Grohne wrote:

Would someone handle dnstwist, which is the only remaining dependency?


I opened a corresponding upstream request:

https://github.com/elceef/dnstwist/issues/170

Peter

Bug#1023501: busybox-static: version 1:1.35.0-3 breaks boot on hppa

[Robert Luberda]

severity 1023501 grave
retitle 1023501 busybox-static: version 1:1.35.0-3 breaks boot on hppa 
and amd64

found 1023501 1:1.35.0-3
notfound 1023501  1:1.35.0-2

On Sat, 05 Nov 2022 13:31:51 + John David Anglin 
 wrote:

Package: busybox-static
Version: 1:1.35.0-2
Severity: normal

Dear Maintainer,

With 1:1.35.0-3, boot ends in initramfs:

Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... 
   
mdadm: No arrays found in config file or automatically
done.
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically


I had the same issue on amd64.
Removing mdadm package did not help.
Downgrading busybox-static to 1.35.0-2 fixed the issue.


I'm including the system information generated by reportbug below:


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (990, 'unstable-debug'), (990, 'unstable'), (990, 
'testing'), (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable')

merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages busybox depends on:
ii  libc6  2.36-4

busybox recommends no packages.

busybox suggests no packages.

-- no debconf information

Regards,
Robert

Bug#1023495: transition: ruby3.1

[Sebastian Ramacher]

Control: forwarded -1 
https://release.debian.org/transitions/html/ruby3.1-default.html

On 2022-11-05 09:23:03 -0300, Antonio Terceiro wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi, I would like to plan the ruby 3.1 transition. As soon as we have the
> tracker I will perform all the test rebuilds necessary and report any
> bugs.
> 
> Ben file:
> 
> title = "ruby3.1 as default";
> is_affected = (.depends ~ /ruby3.0/ | .depends ~ /ruby3.1/) & !.source ~ 
> /^(ruby3.0|ruby3.1|ruby-defaults)$/;
> is_good = .depends ~ "ruby3.1" | .depends ~ "libruby3.1" | ! (.depends ~ 
> "ruby3.0" | .depends ~ "libruby3.0");
> is_bad = ! (.depends ~ "ruby3.1" | .depends ~ "libruby3.1") & (.depends ~ 
> "ruby3.0" | .depends ~ "libruby3.0");

The tracker is available at 
https://release.debian.org/transitions/html/ruby3.1-default.html

Cheers
-- 
Sebastian Ramacher

Bug#1017504: Please build doxygen with large file support

[Mathias Gibbens]

  I've just encountered this same issue while building lxc on sh4:
https://buildd.debian.org/status/fetch.php?pkg=lxc=sh4=1%3A5.0.1-2=1667666175=0
It would be nice if doxygen could be fixed so it works consistently and
correctly on 32-bit platforms.

Thanks,
Mathias


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

Bug#1023419: transition: freeglut

[Sebastian Ramacher]

Control: tags -1 = confirmed

On 2022-11-04 07:18:38 +0100, Anton Gladky wrote:
> Hi Sebastian, you are right.
> 
> I have uploaded a new package into experimental, which introduces
> fereglut3-dev as a transitional package. I will rebuild and report
> about results.

With that fixed, please go ahead.

Cheers

> 
> Regards
> 
> Anton
> 
> Am Do., 3. Nov. 2022 um 22:51 Uhr schrieb Sebastian Ramacher
> :
> >
> > Control: tags -1 moreinfo
> > Control: forwarded -1 
> > https://release.debian.org/transitions/html/auto-freeglut.html
> >
> > On 2022-11-03 20:12:03 +0100, Anton Gladky wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > >
> > >
> > > New version of freeglut library and binary renaming.
> > > Reverse depends were rebuilt against new lib.
> > >
> > >
> > > Ben file:
> > >
> > > title = "freeglut";
> > > is_affected = .depends ~ "freeglut3|freeglut3-dev" | .depends ~ 
> > > "libglut-dev|libglut3.12";
> > > is_good = .depends ~ "libglut-dev|libglut3.12";
> > > is_bad = .depends ~ "freeglut3|freeglut3-dev";
> >
> > What's the deal with the renamed -dev package? Do we need sourceful
> > uploads for all the reverse dependencies? What's the upgrade path for
> > users?  Or in other words: why is there no transitional freeglut3-dev
> > package?
> >
> > Cheers
> > --
> > Sebastian Ramacher
> 

-- 
Sebastian Ramacher

Bug#1018945: transition: libbpf

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-11-05 00:11:07 +, Sudip Mukherjee wrote:
> Control: tags -1 - moreinfo
> --
> 
> On Mon, Oct 24, 2022 at 10:22:32PM +0100, Sudip Mukherjee wrote:
> > As of today only v4l-utils and bpfcc still fails to build with libbpf
> > in experimental.
> > 
> > v4l-utils is a key package, I will look into its fix and request the
> > libbpf transition after that.
> 
> All the packages except bpfcc (#1018818) now builds fine with libbpf/1.0.1-1
> from experimental. I can help bpfcc maintainers with the porting to new libbpf
> but they have not replied to the bug report or to my mails.
> 
> Please consider libbpf for transition.

Please go ahead

Cheers
-- 
Sebastian Ramacher

Bug#1023521: ITP: spopt -- spatial optimization in PySAL

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: spopt
  Version : 0.4.1
  Upstream Author : PySAL Developers 
* URL : https://github.com/pysal/spopt
* License : BSD-3-clause and Public-Domain
  Programming Lang: Python
  Description : spatial optimization in PySAL

 Open source Python library under active development, this module is
 sourced from the module region in PySAL (Python Spatial Analysis Library).
 .
 It aims to solve optimization problems with spatial data, including new
 models and proposed methods for regionalization, facility location and
 transport-oriented solutions.

Bug#1023519: python3-wxgtk4.0: Windows do not follow "dark" mode in Gnome

[Matthias Brennwald]

Package: python3-wxgtk4.0
Version: 4.2.0+dfsg-1
Severity: normal
X-Debbugs-Cc: mbren...@gmail.com

Dear Maintainer,

If "dark" mode is active in GNOME, GUI windows (and other GUI elements) created
with python3-wxgtk4.0 are not painted in "dark" mode. Instead, they are painted
using the standard "non-dark" mode.


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

Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=en_CH.UTF-8, LC_CTYPE=en_CH.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 python3-wxgtk4.0 depends on:
ii  libc6   2.36-4
ii  libgcc-s1   12.2.0-9
ii  libstdc++6  12.2.0-9
ii  libwxbase3.2-0  3.2.1+dfsg-1
ii  libwxgtk3.2-0   3.2.1+dfsg-1
ii  python3 3.10.6-1
ii  python3-numpy   1:1.21.5-1+b1
ii  python3-pil 9.2.0-1.1
ii  python3-six 1.16.0-4

python3-wxgtk4.0 recommends no packages.

Versions of packages python3-wxgtk4.0 suggests:
pn  wx3.0-doc  

-- no debconf information

Bug#1023518: nodejs: CVE-2022-43548

[Salvatore Bonaccorso]

Source: nodejs
Version: 18.12.0+dfsg-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for nodejs.

CVE-2022-43548[0]:
| DNS rebinding in --inspect via invalid octal IP address

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-43548
https://www.cve.org/CVERecord?id=CVE-2022-43548
[1] 
https://nodejs.org/en/blog/vulnerability/november-2022-security-releases/#dns-rebinding-in-inspect-via-invalid-octal-ip-address-medium-cve-2022-43548

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1023373: Further bug discussion

[Bastian Germann]

Am 05.11.22 um 16:44 schrieb Teus Benschop:

Paragraph 4.16 of the DPM [1] does not mention “non-source files”.
It is about “missing sources”.


We can play a word game but "missing sources" is exactly about 
"non-source files". If a file is contained in a package that is not a 
source file then its sources are missing.


The common understanding in Debian of what is a source file is 
"preferred form of modification".


Please take a look at analytics.html and think about the question: "Is 
this a source file or not?"



There was a bug report on this issue [2].
The file "quill/source/docs/_includes/analytics.html” landed in the Bibledit 
source to fix that bug.

[1]https://www.debian.org/doc/debian-policy/ch-source.html#missing-sources-debian-missing-sources
[2]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017083


I know about that bug report (I have already referenced it here). It was 
closed without actually fixing it. The quill files are still non-source 
files because they are not in their preferred form of modification.


So this bug is primarily about the missing source (Policy violation).
When you have addressed that you can downgrade the severity to important 
to address the secondary issue of supposed privacy violations.

Bug#1023517: openconnect: SSO with anyconnect V2 fails

[Marc Dietrich]

Package: openconnect
Version: 9.01-1
Severity: normal

Dear Maintainer,

due to missing patch
https://gitlab.com/openconnect/openconnect/-/commit/0e82c9371420db42376f7952f0d756222aba1001,
SSO with anyconnect V2 fail.
I tested the patch from the commit above and it works for me.
The bug was also reported to ubuntu:
https://bugs.launchpad.net/ubuntu/+source/openconnect/+bug/1993901

Best wishes,

Marc


-- System Information:
Debian Release: bookworm/sid
  APT prefers kinetic-updates
  APT policy: (500, 'kinetic-updates'), (500, 'kinetic-security'), (500, 
'kinetic-proposed'), (500, 'kinetic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages openconnect depends on:
ii  libc62.36-0ubuntu4
ii  libgnutls30  3.7.7-2ubuntu2
ii  libopenconnect5  9.01-1
ii  libproxy1v5  0.4.18-1
ii  libxml2  2.9.14+dfsg-1
ii  vpnc-scripts 0.1~git20220510-1

Versions of packages openconnect recommends:
ii  python3 3.10.6-1
ii  python3-asn1crypto  1.5.1-1
ii  python3-mechanize   1:0.4.8+pypi-4
ii  python3-netifaces   0.11.0-1build2

Versions of packages openconnect suggests:
ii  bash-completion  1:2.11-6ubuntu1

-- no debconf information

Bug#1022166: Not a `gcc-snapshot` bug, but glibc

[Jan-Benedict Glaw]

Hi!

After poking around, I guess this is actually a glibc issue and it's
probably already fixed by this commit:

jbglaw@lili:/var/cache/git/glibc$ git show 
3e5760fcb48528d48deeb60cb885a97bb731160c | head -20
commit 3e5760fcb48528d48deeb60cb885a97bb731160c
Author: Joseph Myers 
Date:   Wed Sep 28 20:09:34 2022 +

Update _FloatN header support for C++ in GCC 13

GCC 13 adds support for _FloatN and _FloatNx types in C++, so breaking
the installed glibc headers that assume such support is not present.
GCC mostly works around this with fixincludes, but that doesn't help
for building glibc and its tests (glibc doesn't itself contain C++
code, but there's C++ code built for tests).  Update glibc's
bits/floatn-common.h and bits/floatn.h headers to handle the GCC 13
support directly.

In general the changes match those made by fixincludes, though I think
the ones in sysdeps/powerpc/bits/floatn.h, where the header tests
__LDBL_MANT_DIG__ == 113 or uses #elif, wouldn't match the existing
fixincludes patterns.
[...]

So this can either be closed or reassigned to glibc, which will have a fix in
2.37 I guess.

Thanks,
  Jan-Benedict

-- 


signature.asc
Description: PGP signature

Bug#1023516: evilwm: ignores input when Num Lock is enabled

[Kacper Gutowski]

Package: evilwm
Version: 1.4.0-1
Severity: normal

Dear Maintainer,
After the upgrade to 1.4.0-1, evilwm started to ignore all the input
when Num Lock is enabled (focus follows mouse, but nothing else works).
Turning the Num Lock off makes it work again.

Apparently now that bindings became configurable, it could be fixed by
doubling all the bindings to write them both with and without the mod2,
but the default configuration is borderline unusable and having to
reconfigure it this way is quite annoying to say the least.

-k


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (700, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages evilwm depends on:
ii  libc6   2.35-4
ii  libx11-62:1.8.1-2
ii  libxext62:1.3.4-1+b1
ii  libxrandr2  2:1.5.2-2+b1

evilwm recommends no packages.

Versions of packages evilwm suggests:
ii  xfonts-100dpi1:1.0.5
ii  xfonts-75dpi 1:1.0.5
ii  xfonts-terminus  4.48-3.1
ii  xterm375-1

-- no debconf information

Bug#1023375:

[Nilson Silva]

It only seems to be useful for windows environment.

Bug#1023515: systemd-pcrphase sysinit hangs blocking boot when tpm2-abrmd installed

[Marek Rusinowski]

Package: systemd
Version: 252-2
Severity: important
X-Debbugs-Cc: marekrusinow...@gmail.com

Dear Maintainer,

In systemd 252 a new tool systemd-pcrphase got included that
measures PCR values at different boot stages. When tpm2-abrmd is
installed in the system, the sysinit stage of that tool
systemd-pcrphase-sysinit.service will hang when initializing tpm2
context on trying to connect via dbus to running tpm2-abrmd daemon
because this daemon is not yet running in this point during the boot
process. This blocks the whole boot sequence as timelimit on
systemd-pcrphase-sysinit is infinite.

Resolution for me was to purge from the system tpm2-abrmd and
libtss2-tcti-tabrmd0 packages so that the tpm2 initialization
doesn't try to use this daemon but contacts tpm2 device using a
different method.

I've confirmed and figured out above by using systemd debug shell
and running `systemd-pcrphase sysinit` under gdb, the stacktrace
looked like:
#0 __GI__poll
(...)
#17 Tss2_Tcti_Tabrmd_Init
(...)
#24 Esys_Initialize (libtss2-esys)
#25 tpm2_context_init (libsystemd-shared)

Thank you,
Marek


-- Package-specific info:

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages systemd depends on:
ii  libacl12.3.1-1
ii  libaudit1  1:3.0.7-1.1+b1
ii  libblkid1  2.38.1-1.1+b1
ii  libc6  2.36-4
ii  libcap21:2.44-1
ii  libcryptsetup122:2.5.0-6
ii  libfdisk1  2.38.1-1.1+b1
ii  libgcrypt201.10.1-2
ii  libkmod2   30+20220905-1
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.2.7-0.1
ii  libmount1  2.38.1-1.1+b1
ii  libseccomp22.5.4-1+b1
ii  libselinux13.4-1+b2
ii  libssl33.0.7-1
ii  libsystemd-shared  252-2
ii  libsystemd0252-2
ii  libzstd1   1.5.2+dfsg-1
ii  mount  2.38.1-1.1+b1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.4-1
ii  systemd-timesyncd [time-daemon]  252-2

Versions of packages systemd suggests:
ii  libfido2-11.12.0-1
ii  libtss2-esys-3.0.2-0  3.2.0-1+b1
ii  libtss2-mu0   3.2.0-1+b1
ii  libtss2-rc0   3.2.0-1+b1
ii  policykit-1   122-1
ii  systemd-boot  252-2
ii  systemd-container 252-2
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.4-1
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 252-2
ii  libpam-systemd 252-2
ii  udev   252-2

-- no debconf information

Bug#1022339: virt-manager: diff for NMU version 1:4.1.0-1.1

[Stefano Rivera]

Control: tags 1022339 + patch
Control: tags 1022339 + pending

Dear maintainer,

I've prepared an NMU for virt-manager (versioned as 1:4.1.0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.

SR
diff -Nru virt-manager-4.1.0/debian/changelog virt-manager-4.1.0/debian/changelog
--- virt-manager-4.1.0/debian/changelog	2022-08-05 08:35:08.0 +0200
+++ virt-manager-4.1.0/debian/changelog	2022-11-05 20:08:35.0 +0200
@@ -1,3 +1,11 @@
+virt-manager (1:4.1.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Explicitly specify --install-layout=deb in the Python module installation,
+fixing compatibility with Python 3.10 in Debian. (Closes: #1022339)
+
+ -- Stefano Rivera   Sat, 05 Nov 2022 20:08:35 +0200
+
 virt-manager (1:4.1.0-1) unstable; urgency=medium
 
   * New upstream version 4.1.0
diff -Nru virt-manager-4.1.0/debian/rules virt-manager-4.1.0/debian/rules
--- virt-manager-4.1.0/debian/rules	2022-08-05 08:09:44.0 +0200
+++ virt-manager-4.1.0/debian/rules	2022-11-05 20:08:32.0 +0200
@@ -10,7 +10,7 @@
 	pytest-3 -v -rs
 
 override_dh_auto_install:
-	python3 setup.py --no-update-icon-cache --no-compile-schemas install --force --root=debian/tmp --no-compile -O0
+	python3 setup.py --no-update-icon-cache --no-compile-schemas install --force --install-layout=deb --root=debian/tmp --no-compile -O0
 
 override_dh_installdocs:
 	dh_installdocs --all NEWS.md

Bug#1023514: logwatch: get error about exim

[Tim McConnell]

Package: logwatch
Version: 7.5.6-1
Severity: normal

Dear Maintainer,
I get the following report in Logwatch:
- EXIM Begin 

 Use of uninitialized value $SelfSigned in concatenation (.) or string at
/usr/share/logwatch/scripts/services/exim line 334,  line 442.

 --- Self-Signed Certificate in use (  Time(s))

 -- EXIM End -
I go to those lines in the named script and I don't see an error. I'm attching
the script it's complaining about


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

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

Versions of packages logwatch depends on:
ii  exim4-daemon-light [mail-transport-agent]  4.96-7
ii  perl   5.36.0-4

Versions of packages logwatch recommends:
ii  libdate-manip-perl   6.89-1
ii  libsys-cpu-perl  0.61-3+b1
ii  libsys-meminfo-perl  0.99-2+b1

logwatch suggests no packages.

-- debconf-show failed
#!/usr/bin/perl


# Please file all bug reports, patches, and feature
# requests under:
#  https://sourceforge.net/p/logwatch/_list/tickets
# Help requests and discusion can be filed under:
#  https://sourceforge.net/p/logwatch/discussion/



# Originally written by:
#Dariusz Nierada 



# Default Detail Levels:
# 0: Prints MisFormatted log lines (should never happen)
#Virus/Malware blocks (if AntiVirus configured)
#Prints protocol violations (by category)
#Prints address verification rejections
#Prints administrative rejections (by category)
#Prints Refused Relay count
#
# 5: Prints Queue Run count
#Prints server Stop/Start
#
#10: Prints Refused Relay (individual lines)
#Prints Per Message Tracking



## Copyright (c) 2008 Gary Allen Vollink
## Covered under the included MIT/X-Consortium License:
##http://www.opensource.org/licenses/mit-license.php
## All modifications and contributions by other persons to
## this script are assumed to have been donated to the
## Logwatch project and thus assume the above copyright
## and licensing terms.  If you want to make contributions
## under your own copyright or a different license this
## must be explicitly stated in the contribution an the
## Logwatch project reserves the right to not accept such
## contributions.  If you have made significant
## contributions to this script and want to claim
## copyright please contact logwatch-de...@lists.sourceforge.net.
#

use Logwatch ':dates';
use warnings;

$Detail   = $ENV{'LOGWATCH_DETAIL_LEVEL'}  || 0;

$LvlBadFormat= $ENV{'exim_misformat'} || 0;
$LvlRestarts = $ENV{'exim_restart'}   || 5;
$LvlVirus= $ENV{'exim_virus'} || 0;
$LvlProtocol  = $ENV{'exim_protocol'}  || 0;
$LvlProtocolLines = $ENV{'exim_protocol_lines'}|| 5;
$LvlDontAccept   = $ENV{'exim_dontaccept'}|| 0;
$LvlDontAcceptLines = $ENV{'exim_dontaccept_lines'}|| 0;
$LvlVerify   = $ENV{'exim_verify'}|| 0;
$LvlVerifyLines  = $ENV{'exim_verify_lines'}  || 5;
$LvlRuns = $ENV{'exim_runs'}  || 5;
$LvlRelay= $ENV{'exim_relay'} || 0;
$LvlRelayLines   = $ENV{'exim_relay_lines'}   || 10;
$LvlMsgs = $ENV{'exim_mesgs'} || 10;

# procedura sortujaca tak jak ja chce (bo tamta sotrowala po ASCII)
# procedure to compare numbers at the beginning of submitted strings.
#  .. Which in this case is the message count for a given message ID.
sub wedlug_liczb {
($aa) = ($a =~ /^(\d+).+/);
($bb) = ($b =~ /^(\d+).+/);
$aa <=> $bb;
}

# START

my $SearchDate = TimeFilter("%Y-%m-%d %H:%M:%S");
$StartQueue = 0;
$EndQueue = 0;

# Regex to match IPv4 addresses and IPv6 addresses
# IPv6 part could be made more strict
my $IPAddress = qr/\d+\.\d+\.\d+\.\d+|[a-fA-F0-9]*:[a-fA-F0-9:]+/;

my $MatchedDate = 0;

while (defined($ThisLine = )) {
   chomp($ThisLine);
# pobierz dzisiejsza date z 2002-03-31 22:13:48 ...
# Collect this line's date, e.g. 2002-03-31 22:13:48 ...
   do {
  if ( $ThisLine =~ /^ Suggested action: use keep_environment./ ) {
 $KeepEnv++ if $MatchedDate;
 next;
  }
  if ( $ThisLine =~ /^ Suggested action: 

Bug#1023509: openssh-server: suggestion about (default) sshd_config and sshd_config.d

[Patrice]

Postscriptum

My motivation here is related to the point 1. of the following issue:
https://github.com/EXALAB/AnLinux-App/issues/397
The current is to overwrite the /etc/ssh/sshd_config by a file that contents
only:
PermitRootLogin yes

So putting that file in /etc/ssh/sshd_config.d should do the job
but I don't know what could be the result if the /etc/ssh/sshd_config content
the opposite in the following of the Include directive.

Bug#1023513: command-not-found: crash report when opening terminal session in MATE

[Tim McConnell]

Package: command-not-found
Version: 20.10.1-1
Severity: normal

Dear Maintainer,

When I open a terminal in MATE I get the following error report:
Sorry, command-not-found has crashed! Please file a bug report at:
http://www.debian.org/Bugs/Reporting
Please include the following information with the report:

command-not-found version: 0.3
Python version: 3.10.8 final 0
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux bookworm/sid
Release:n/a
Codename:   bookworm
Exception information:

unable to open database file
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in
crash_guard
callback()
  File "/usr/lib/command-not-found", line 90, in main
cnf = CommandNotFound.CommandNotFound(options.data_dir)
  File "/usr/share/command-not-found/CommandNotFound/CommandNotFound.py", line
79, in __init__
self.db = SqliteDatabase(dbpath)
  File "/usr/share/command-not-found/CommandNotFound/db/db.py", line 12, in
__init__
self.con = sqlite3.connect(filename)
sqlite3.OperationalError: unable to open database file


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

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

Versions of packages command-not-found depends on:
ii  apt-file 3.3
ii  lsb-release  12.0-1
ii  python3  3.10.6-1
ii  python3-apt  2.3.0+nmu1

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
ii  snapd  2.54.3-1.1+b2

-- debconf-show failed

Bug#1023204: (no subject)

[Andre Naujoks]

I am also affected by this. I worked around this by installing the 
samba-libs package from testing and pinning the version to 2:4.16*


This workaround will go away though, when 2:4.17 migrates to testing as 
well.

Bug#1023512: python3-pyhcl: Should be named python3-hcl

[Stefano Rivera]

Package: python3-pyhcl
Version: 0.4.4-2
Severity: normal

According to the Debian Python Policy Section 4.3, binary package names
should be named after the *import* name of the module, not the PyPI
distribution name.

https://www.debian.org/doc/packaging-manuals/python-policy/index.html#module-package-names

Thus, python3-pyhcl should be called python3-hcl.

This would fix the failed autopkgtest.

SR

Bug#1022318: python-pyhcl: diff for NMU version 0.4.4-2.1

[Stefano Rivera]

Control: tags 1022318 + patch
Control: tags 1022318 + pending

Dear maintainer,

I've prepared an NMU for python-pyhcl (versioned as 0.4.4-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,

SR
diff -Nru python-pyhcl-0.4.4/debian/changelog python-pyhcl-0.4.4/debian/changelog
--- python-pyhcl-0.4.4/debian/changelog	2021-08-20 20:46:40.0 +0200
+++ python-pyhcl-0.4.4/debian/changelog	2022-11-05 20:00:30.0 +0200
@@ -1,3 +1,10 @@
+python-pyhcl (0.4.4-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Support setuptools 60. (Closes: #1022318)
+
+ -- Stefano Rivera   Sat, 05 Nov 2022 20:00:30 +0200
+
 python-pyhcl (0.4.4-2) unstable; urgency=medium
 
   * Reupload source-only.
diff -Nru python-pyhcl-0.4.4/debian/patches/series python-pyhcl-0.4.4/debian/patches/series
--- python-pyhcl-0.4.4/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ python-pyhcl-0.4.4/debian/patches/series	2022-11-05 19:58:22.0 +0200
@@ -0,0 +1 @@
+setuptools-60
diff -Nru python-pyhcl-0.4.4/debian/patches/setuptools-60 python-pyhcl-0.4.4/debian/patches/setuptools-60
--- python-pyhcl-0.4.4/debian/patches/setuptools-60	1970-01-01 02:00:00.0 +0200
+++ python-pyhcl-0.4.4/debian/patches/setuptools-60	2022-11-05 20:00:30.0 +0200
@@ -0,0 +1,28 @@
+Description: Import setuptools before distutils
+ setuptools 60 uses its own bunlded version of distutils, by default. It
+ injects this into sys.modules, at import time. So we need to make sure that it
+ is imported, before anything else imports distutils, to ensure everything is
+ using the same distutils version.
+ .
+ This is to prepare for Python 3.12, which will drop distutils.
+Author: Stefano Rivera 
+Forwarded: https://github.com/virtuald/pyhcl/pull/84
+Bug-Debian: https://bugs.debian.org/1022318
+--- a/setup.py
 b/setup.py
+@@ -3,13 +3,14 @@
+ from __future__ import print_function
+ 
+ from os.path import abspath, dirname, join, exists
+-from distutils.core import setup
+ 
+ try:
+ from setuptools.command.build_py import build_py as _build_py
+ except ImportError:
+ from distutils.command.build_py import build_py as _build_py
+ 
++from distutils.core import setup
++
+ import os
+ import sys
+ import subprocess

Bug#1023511: Plymouth bootsplash not displayed, cannot be set - packages installed but commands not found

[epp]

Package:  plymouth
Version:  22.02.122-2

Debian stable and unstable were first installed to a VirtualBox using 
VMSVGA (VMware) for virtual graphics. Then installed to two desktops on 
the system hardware. One has an AMD Radeon 3000 on-board, the other has 
an AMD Radeon HD 5450 on a PCI-E x16 video card.


The plymouth bootsplash would not and does not display with any of these 
installations. The plymouth-set-default-theme command reports the 
command update-initrams is not found. In the VirtualBox, 
plymouth-set-default-theme wasn't found:



When installed to hardware:

root@downstairs:/home/epp# /usr/sbin/plymouth-set-default-theme -R spinner
/usr/libexec/plymouth/plymouth-update-initrd: 5: update-initramfs: not found

Note update-initramfs is installed.

root@downstairs:/home/epp# dpkg -S update-initramfs
initramfs-tools: /usr/share/man/man8/update-initramfs.8.gz
initramfs-tools: /etc/initramfs-tools/update-initramfs.conf
initramfs-tools: /usr/share/bash-completion/completions/update-initramfs
initramfs-tools: /usr/share/man/man5/update-initramfs.conf.5.gz
initramfs-tools: /usr/sbin/update-initramfs


When installed to a VirtualBox (since deleted, no longer using 
VirtualBox), plymouth-set-default-theme was also not found.


root@debian:/home/epp# apt install plymouth plymouth-themes
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
plymouth is already the newest version (22.02.122-2).
plymouth-themes is already the newest version (22.02.122-2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@debian:/home/epp# plymouth-set-default-theme -l
bash: plymouth-set-default-theme: command not found

Bug#1023510: Use update-alternatives for /usr/share/applications/sm.puri.OSK0

[Guido Günther]

Package: squeekboard
Version: 1.20.0
Severity: wishlist

It can be useful to have both squeekboard and phosh-osk-stub
installed on a system and to switch between them as both implement
the required interfaces.

The upstream phosh-osk-stub packages solves that by using a diversion
but that is not ideal as one can't switch easily.

As I'd like to upload phosh-osk-stub to experimental it would be great
to make squeekboard use `update-alternatives` for

   /usr/share/applications/sm.puri.OSK0

so both packages get co-installable and the OSK implementation could
be switched easily.

Filing this bug to see if there are objections, otherwise I'd send a
patch for squeekboard.

Cheers,
 -- Guido

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

Kernel: Linux 6.0.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 squeekboard depends on:
ii  gnome-themes-extra-data  3.28-2
ii  libc62.35-3
ii  libcairo-gobject21.16.0-6
ii  libcairo21.16.0-6
ii  libfeedback-0.0-00.0.0+git20220520-1
ii  libgcc-s112.2.0-3
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libglib2.0-0 2.74.0-2
pn  libgnome-desktop-3-19
ii  libgnome-desktop-3-2043-2
ii  libgtk-3-0   3.24.34-3
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libwayland-client0   1.21.0-1
ii  libxkbcommon01.4.1-1

squeekboard recommends no packages.

squeekboard suggests no packages.

Bug#1023509: openssh-server: suggestion about (default) sshd_config and sshd_config.d

[Patrice Duroux]

Package: openssh-server
Version: 1:9.0p1-1+b2
Severity: wishlist

Dear Maintainer,

I think the current state is a bit confusing because the Include directive is
at the very beguining of the file before some commented (default) setting that
could suggest administrator to edit there.

And so, doing this, does this override any sshd_config.d contents?

If it is just some sort of self-documented for the Debian default setting, it
could be elsewhere, no?

Why not then providing an almost empty sshd_config that just includes
sshd_config.d and have a sample file in this folder with all the current
commented content.

Regards,
Patrice


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

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

Versions of packages openssh-server depends on:
ii  adduser3.129
ii  debconf [debconf-2.0]  1.5.79
ii  dpkg   1.21.9+b1
ii  init-system-helpers1.65.2
ii  libaudit1  1:3.0.7-1.1+b1
ii  libc6  2.36-4
ii  libcom-err21.46.6~rc1-1+b1
ii  libcrypt1  1:4.4.30-1
ii  libgssapi-krb5-2   1.20-1+b1
ii  libkrb5-3  1.20-1+b1
ii  libpam-modules 1.5.2-5
ii  libpam-runtime 1.5.2-5
ii  libpam0g   1.5.2-5
ii  libselinux13.4-1+b2
ii  libssl33.0.7-1
ii  libsystemd0252-2
ii  libwrap0   7.6.q-31
ii  openssh-client 1:9.0p1-1+b2
ii  openssh-sftp-server1:9.0p1-1+b2
ii  procps 2:3.3.17-7.1
ii  runit-helper   2.15.0
ii  sysvinit-utils [lsb-base]  3.05-6
ii  ucf3.0043
ii  zlib1g 1:1.2.11.dfsg-4.1

Versions of packages openssh-server recommends:
ii  libpam-systemd [logind]  252-2
ii  ncurses-term 6.3+20220423-2
ii  xauth1:1.1.1-1

Versions of packages openssh-server suggests:
pn  molly-guard   
pn  monkeysphere  
pn  ssh-askpass   
pn  ufw   

-- debconf information excluded

Bug#1022310: ofxstatement-plugins: diff for NMU version 20210310+nmu1

[Stefano Rivera]

Control: tags 1022310 + patch
Control: tags 1022310 + pending

Dear maintainer,

I've prepared an NMU for ofxstatement-plugins (versioned as 20210310+nmu1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,

SR
diff -Nru ofxstatement-plugins-20210310/debian/changelog ofxstatement-plugins-20210310+nmu1/debian/changelog
--- ofxstatement-plugins-20210310/debian/changelog	2021-03-10 10:15:48.0 +0200
+++ ofxstatement-plugins-20210310+nmu1/debian/changelog	2022-11-05 18:36:19.0 +0200
@@ -1,3 +1,10 @@
+ofxstatement-plugins (20210310+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch: Support setuptools 60. (Closes: #1022310)
+
+ -- Stefano Rivera   Sat, 05 Nov 2022 18:36:19 +0200
+
 ofxstatement-plugins (20210310) unstable; urgency=medium
 
   * d/rules: Disable autotests because of tecnical FTBFS. (Closes: #982704)
diff -Nru ofxstatement-plugins-20210310/debian/patches/series ofxstatement-plugins-20210310+nmu1/debian/patches/series
--- ofxstatement-plugins-20210310/debian/patches/series	2021-01-08 15:32:57.0 +0200
+++ ofxstatement-plugins-20210310+nmu1/debian/patches/series	2022-11-05 18:34:18.0 +0200
@@ -3,3 +3,4 @@
 03-fix-pytest.patch
 04-fix-ofxstatement-6.5+-compatibility.patch
 05-fix-interpreter.patch
+setuptools-60.patch
diff -Nru ofxstatement-plugins-20210310/debian/patches/setuptools-60.patch ofxstatement-plugins-20210310+nmu1/debian/patches/setuptools-60.patch
--- ofxstatement-plugins-20210310/debian/patches/setuptools-60.patch	1970-01-01 02:00:00.0 +0200
+++ ofxstatement-plugins-20210310+nmu1/debian/patches/setuptools-60.patch	2022-11-05 18:36:19.0 +0200
@@ -0,0 +1,39 @@
+Description: Import setuptools before distutils
+ setuptools 60 uses its own bunlded version of distutils, by default. It
+ injects this into sys.modules, at import time. So we need to make sure that it
+ is imported, before anything else imports distutils, to ensure everything is
+ using the same distutils version.
+ .
+ This is to prepare for Python 3.12, which will drop distutils.
+Author: Stefano Rivera 
+Bug-Debian: https://bugs.debian.org/1022310
+Forwarded: https://github.com/lbschenkel/ofxstatement-al_bank/pull/1
+Forwarded: https://github.com/lbschenkel/ofxstatement-lansforsakringar/pull/3 
+--- a/ofxstatement-al_bank/setup.py
 b/ofxstatement-al_bank/setup.py
+@@ -1,9 +1,9 @@
+ #!/usr/bin/python3
+ 
+-from distutils.core import setup
+-
+ from setuptools import find_packages
+ 
++from distutils.core import setup
++
+ version = "0.2.1"
+ 
+ with open('README.rst') as f:
+--- a/ofxstatement-lansforsakringar/setup.py
 b/ofxstatement-lansforsakringar/setup.py
+@@ -1,9 +1,9 @@
+ #!/usr/bin/python3
+ 
+-from distutils.core import setup
+-
+ from setuptools import find_packages
+ 
++from distutils.core import setup
++
+ version = "0.2.0"
+ 
+ with open('README.rst', mode='r', encoding='utf-8') as f:
diff -Nru ofxstatement-plugins-20210310/ofxstatement-al_bank/setup.py ofxstatement-plugins-20210310+nmu1/ofxstatement-al_bank/setup.py
--- ofxstatement-plugins-20210310/ofxstatement-al_bank/setup.py	2021-01-08 15:17:55.0 +0200
+++ ofxstatement-plugins-20210310+nmu1/ofxstatement-al_bank/setup.py	2022-11-05 18:34:31.0 +0200
@@ -1,9 +1,9 @@
 #!/usr/bin/python3
 
-from distutils.core import setup
-
 from setuptools import find_packages
 
+from distutils.core import setup
+
 version = "0.2.1"
 
 with open('README.rst') as f:
diff -Nru ofxstatement-plugins-20210310/ofxstatement-be-argenta/setup.py ofxstatement-plugins-20210310+nmu1/ofxstatement-be-argenta/setup.py
--- ofxstatement-plugins-20210310/ofxstatement-be-argenta/setup.py	2021-03-10 10:12:18.0 +0200
+++ ofxstatement-plugins-20210310+nmu1/ofxstatement-be-argenta/setup.py	2022-11-05 18:34:12.0 +0200
@@ -31,14 +31,11 @@
   namespace_packages=['ofxstatement', 'ofxstatement.plugins'],
   entry_points={
   'ofxstatement': ['argenta = ofxstatement.plugins.argenta:ArgentaPlugin'],
-  'console_scripts': ['ofx-argenta-convert = ofxstatement_be_argenta.convert:convert']
   },
   install_requires=[
   'ofxstatement>=0.6.1',
-  'openpyxl>=2.6.2',
-  'click>=6.7'
+  'openpyxl',
   ],
-  test_suite='ofxstatement.plugins.tests',
   include_package_data=True,
   zip_safe=True
   )
diff -Nru ofxstatement-plugins-20210310/ofxstatement-bubbas/src/ofxstatement/plugins/dkb_cc.py ofxstatement-plugins-20210310+nmu1/ofxstatement-bubbas/src/ofxstatement/plugins/dkb_cc.py
--- ofxstatement-plugins-20210310/ofxstatement-bubbas/src/ofxstatement/plugins/dkb_cc.py	2021-03-10 10:12:18.0 +0200
+++ ofxstatement-plugins-20210310+nmu1/ofxstatement-bubbas/src/ofxstatement/plugins/dkb_cc.py	2022-11-05 18:34:12.0 +0200
@@ -30,6 +30,7 @@
 line[4]=line[4].replace('.','').replace(',','.')
 # fill statement line according to mappings
 sl = 

Bug#1022126: mpt3sas broken with xen dom0

[Taavi Ansper]

Hi

Same problem here. We upgraded our SAS card firmware to the latest, but it did 
not help.

Kernel 5.10.0-18 is still working fine.

We are also using Xen Virtualization.

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

--
Taavi Ansper
taavi.ans...@cyber.ee
+372 5905 2861

Bug#1023508: ITP: django-yarnpkg -- Integrate Django with yarnpkg

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: django-yarnpkg
  Version : 6.0.3
  Upstream Author : Dominik George 
* URL : https://edugit.org/AlekSIS/libs/django-yarnpkg
* License : Apache-2.0
  Programming Lang: Python
  Description : Integrate Django with yarnpkg

  Easy way to use yarnpkg with your Django project.
  .
  Yarn packages are specified in the Django settings file.
 
I plan to maintain this package as part of the Python team.

This is a dependancy of AlekSIS [1]

   1: https://edugit.org/AlekSIS/official/AlekSIS-Core

Bug#1023506: libgdal-grass: FTBFS with GDAL 3.6.0

[Bas Couwenberg]

Source: libgdal-grass
Version: 1.0.1-1
Severity: important
Tags: upstream ftbfs
User: debian-...@lists.debian.org
Usertags: gdal-3.6
Control: forwarded -1 https://github.com/OSGeo/gdal-grass/issues/12

Dear Maintainer,

Your package FTBFS with GDAL 3.6.0:

 grass.cpp:106:17: error: 'const char* GRASSDataset::_GetProjectionRef()' 
marked 'override', but does not override
   106 | const char *_GetProjectionRef(void) override;
   | ^
 grass.cpp: In member function 'virtual const OGRSpatialReference* 
GRASSDataset::GetSpatialRef() const':
 grass.cpp:108:16: error: 'GetSpatialRefFromOldGetProjectionRef' was not 
declared in this scope
   108 | return GetSpatialRefFromOldGetProjectionRef();
   |^~~~

The full buildlog is attached.

Kind Regards,

Bas
dpkg-checkbuilddeps: error: Unmet build dependencies: grass (>= 8.2.0) 
grass-dev (>= 8.2.0) libgdal-dev (>= 3.5.0)
W: Unmet build-dependency in source
dh clean
   dh_clean
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building libgdal-grass using existing 
./libgdal-grass_1.0.1.orig.tar.gz
dpkg-source: info: building libgdal-grass in libgdal-grass_1.0.1-2.debian.tar.xz
dpkg-source: info: building libgdal-grass in libgdal-grass_1.0.1-2.dsc
I: Generating source changes file for original dsc
dpkg-genchanges: info: not including original source code in upload
I: Copying COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.3114667
I: forking: cp -al /var/cache/pbuilder/base-sid+rebuild.cow 
/var/cache/pbuilder/build/cow.3114667
I: removed stale ilistfile /var/cache/pbuilder/build/cow.3114667/.ilist
I: forking: chroot /var/cache/pbuilder/build/cow.3114667 cowdancer-ilistcreate 
/.ilist 'find . -xdev -path ./home -prune -o \( \( -type l -o -type f \) -a 
-links +1 -print0 \) | xargs -0 stat --format '%d %i ''
I: Invoking pbuilder
I: forking: pbuilder build --debbuildopts  --debbuildopts  --buildplace 
/var/cache/pbuilder/build/cow.3114667 --buildresult /var/cache/pbuilder/result/ 
--mirror http://ftp.nl.debian.org/debian/ --distribution sid --no-targz 
--internal-chrootexec 'chroot /var/cache/pbuilder/build/cow.3114667 cow-shell' 
/home/bas/tmp/debian/libgdal-grass_1.0.1-2.dsc
I: Running in no-targz mode
I: pbuilder: network access will be disabled during build
I: Current time: Sat Nov  5 17:24:49 CET 2022
I: pbuilder-time-stamp: 1667665489
I: copying local configuration
W: --override-config is not set; not updating apt.conf Read the manpage 
for details.
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: redirecting /dev/ptmx to /dev/pts/ptmx
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [/home/bas/tmp/debian/libgdal-grass_1.0.1-2.dsc]
I: copying [/home/bas/tmp/debian/libgdal-grass_1.0.1.orig.tar.gz]
I: copying [/home/bas/tmp/debian/libgdal-grass_1.0.1-2.debian.tar.xz]
I: Extracting source
dpkg-source: warning: extracting unsigned source package 
(libgdal-grass_1.0.1-2.dsc)
dpkg-source: info: extracting libgdal-grass in libgdal-grass-1.0.1
dpkg-source: info: unpacking libgdal-grass_1.0.1.orig.tar.gz
dpkg-source: info: unpacking libgdal-grass_1.0.1-2.debian.tar.xz
I: using fakeroot in build.
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper-compat (= 12), grass (>= 8.2.0), grass-dev (>= 8.2.0), 
libgdal-dev (>= 3.5.0), libpq-dev, pkg-config
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 15362 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on debhelper-compat (= 12); however:
  Package debhelper-compat is not installed.
 pbuilder-satisfydepends-dummy depends on grass (>= 8.2.0); however:
  Package grass is not installed.
 pbuilder-satisfydepends-dummy depends on grass-dev (>= 8.2.0); however:
  Package grass-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libgdal-dev (>= 3.5.0); 

Bug#1013729: rust-zbus: Please upgrade to version 2.2.0

[Jonas Smedegaard]

Peter Michael Green wrote:
> rust-secret-service - no upstream fix, no rdeps, no binarys

A release embracing the newer zbus seems to come out soon, according to
this issue (with not very revealing subject):
https://github.com/hwchen/secret-service-rs/issues/42 - at the end of
that discussion was a release which apparently then pulled again, likely
due to wanting to resolve this other issue as well for same major
release bump: https://github.com/hwchen/secret-service-rs/pull/58


> I can't find any upstream changelog

If you mean for zbus crate (not libslirp crate) then it seems
upstream (annoyingly) summarizes changes oly in release notes, e.g.
here: https://gitlab.freedesktop.org/dbus/zbus/-/releases/zbus-3.0.0


A interesting more general note from zbus upstream is this:
https://github.com/hwchen/secret-service-rs/issues/42#issuecomment-1183694993

That's for the bump from v2 to v3, though.  But since that bump might be
harmless for most users, could be the previous bump is as well - perhaps
simply ask upstream maintainer about any specific concerns.


 - 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#1022430: osc: diff for NMU version 0.169.1-1.1

[Stefano Rivera]

Control: tags 1022430 + patch
Control: tags 1022430 + pending

Dear maintainer,

I've prepared an NMU for osc (versioned as 0.169.1-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,

SR
diff -Nru osc-0.169.1/debian/changelog osc-0.169.1/debian/changelog
--- osc-0.169.1/debian/changelog	2021-01-09 11:08:08.0 +0200
+++ osc-0.169.1/debian/changelog	2022-11-05 18:02:07.0 +0200
@@ -1,3 +1,10 @@
+osc (0.169.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Patch: Support setuptools 60. (Closes: #1022430)
+
+ -- Stefano Rivera   Sat, 05 Nov 2022 18:02:07 +0200
+
 osc (0.169.1-1) unstable; urgency=high
 
   * New upstream release (Closes: #96, CVE-2019-3681)
diff -Nru osc-0.169.1/debian/patches/series osc-0.169.1/debian/patches/series
--- osc-0.169.1/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ osc-0.169.1/debian/patches/series	2022-11-05 18:02:07.0 +0200
@@ -0,0 +1 @@
+setuptools-60.patch
diff -Nru osc-0.169.1/debian/patches/setuptools-60.patch osc-0.169.1/debian/patches/setuptools-60.patch
--- osc-0.169.1/debian/patches/setuptools-60.patch	1970-01-01 02:00:00.0 +0200
+++ osc-0.169.1/debian/patches/setuptools-60.patch	2022-11-05 18:02:07.0 +0200
@@ -0,0 +1,34 @@
+From: Stefano Rivera 
+Date: Sat, 5 Nov 2022 17:46:58 +0200
+Subject: Import setuptools before distutils
+
+Setuptools 60 bundles distutils and installs its own version into
+sys.path. Make sure this happens before any other distutils imports.
+
+Forwarded: not-needed, upstream has stripped their setup.py down
+Bug-Debian: https://bugs.debian.org/1022430
+---
+ setup.py | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/setup.py b/setup.py
+index 118e8a5..7cacc9c 100755
+--- a/setup.py
 b/setup.py
+@@ -1,5 +1,7 @@
+ #!/usr/bin/env python
+ 
++import setuptools
++
+ from distutils.core import setup
+ import distutils.core
+ from distutils.command import build, install_data
+@@ -7,8 +9,6 @@ import gzip
+ import os.path
+ import sys
+ 
+-import setuptools
+-
+ import osc.core
+ from osc import commandline
+ 

Bug#1023505: include verification steps in commit message for out-of-date-standards-version

[Jelmer Vernooij]

Package: lintian-brush
Version: 0.133
Severity: wishlist

lintian-brush will verify that all conditions documented in the Debian policy
upgrade checklist 
(https://www.debian.org/doc/debian-policy/upgrading-checklist.html)
have been met before bumping the Standards-Version.

However, this isn't made clear in any way in the Janitor merge proposals or
the commits/changelog entries that it creates.

It might make sense to list all the individual verification steps in the commit 
message.
I think it'd be a bit verbose to list all the verifications in the changelog 
message, but
perhaps we could at least mention that verification has taken place.


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

Kernel: Linux 6.0.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 lintian-brush depends on:
ii  devscripts   2.22.2
ii  python3  3.10.6-1
ii  python3-asyncpg  0.26.0-1
ii  python3-breezy   3.3.0+bzr7661-2
ii  python3-debian   0.1.48
ii  python3-debmutate0.61
ii  python3-distro-info  1.2
ii  python3-dulwich  0.20.46-2
ii  python3-iniparse 0.5-1
ii  python3-iso8601  1.0.2-1
ii  python3-levenshtein  0.12.2-2+b2
ii  python3-pyinotify0.9.6-2
ii  python3-ruamel.yaml  0.17.16-1
ii  python3-semver   2.10.2-3
ii  python3-tomlkit  0.11.5-1
ii  python3-tqdm 4.64.0-2
ii  python3-upstream-ontologist  0.1.25-2

Versions of packages lintian-brush recommends:
ii  debhelper 13.10.1
ii  decopy0.2.4.7-0.2
ii  dos2unix  7.4.3-1
ii  gpg   2.2.40-1
ii  lintian   2.115.3
ii  ognibuild 0.0.13-1
ii  python3-bs4   4.11.1-2
ii  python3-docutils  0.17.1+dfsg-2
ii  python3-lxml  4.9.1-1+b1
ii  python3-markdown  3.4.1-2

Versions of packages lintian-brush suggests:
ii  brz-debian 2.8.74
ii  git-buildpackage   0.9.29
pn  gnome-pkg-tools
ii  po-debconf 1.0.21+nmu1
ii  postgresql-common  245

-- debconf-show failed

Bug#1023118: distro-info-data 0.51+deb11u3 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1023118 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: distro-info-data
Version: 0.51+deb11u3

Explanation: add Ubuntu 23.04, Lunar Lobster; update Debian ELTS end dates; 
correct Debian 8 (jessie) release date

Bug#1022860: powerline-gitstatus 1.3.2-0+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1022860 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: powerline-gitstatus
Version: 1.3.2-0+deb11u1

Explanation: fix command injection via malicious repository config 
[CVE-2022-42906]

Bug#1020596: mod-wsgi 4.7.1-3+deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1020596 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==

Package: mod-wsgi
Version: 4.7.1-3+deb11u1

Explanation: drop X-Client-IP header when it is not a trusted header 
[CVE-2022-2255]

Bug#1023504: pipewire: moc play no sound if pulseaudio purged from system

[Patrice Duroux]

Maybe, another solution for you is to configure ALSA to go by Pipewire
directly using the sample configuration file provided by pipewire-alsa (not
installed on my system):
/usr/share/doc/pipewire/examples/alsa.conf.d/99-pipewire-default.conf

Replacing /etc/alsa/conf.d/99-pulse.conf by this one should work.

Bug#1023373: Further bug discussion

[Teus Benschop]

Hi Bastian,

Thank you for the further clarification.

You wrote:
> 1) For dealing with non-source files see §4.16.

Paragraph 4.16 of the DPM [1] does not mention “non-source files”.
It is about “missing sources”.
There was a bug report on this issue [2].
The file "quill/source/docs/_includes/analytics.html” landed in the Bibledit 
source to fix that bug.

[1] 
https://www.debian.org/doc/debian-policy/ch-source.html#missing-sources-debian-missing-sources
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017083

You wrote:
> 2) The script calls https://www.google-analytics.com/analytics.js which is a 
> privacy breach.
> I do not know the Policy section which applies to this but it is 
> certainly a violation of the social contract,
> which says: "Our priorities are our users and free software”.

You are correct that the file "quill/source/docs/_includes/analytics.html” 
makes a call to Google Analytics.
But I also see that this call is never executed by Bibledit.
The call to Google Analytics can even never be made by Bibledit, because this 
call is not found in the file “quill.min.js|.
This is the final minified version from Quill that Bibledit uses.
Therefore when referring to the social contract, where it says “Our priorities 
are our users and free software”,
Bibledit does prioritise the users and free software in this context.
Because Bibledit never calls Google Analytics.

After thinking over all these things, it now becomes even more unclear to me 
what the exact bug is that this report is about.

My questions are:
1. Since there’s no policy violation, and no violation of the social contract, 
and no functional error, what exactly is the bug?
2. Since there’s no violation of policy or social contract, and the package is 
not unfit for release, why has this bug been tagged release critical?

A few suggestion are these:
1. To no longer make this bug release critical.
2. Perhaps make this bug a wishlist item instead.
3. Perhaps close this bug since there’s no bug found yet.

You wrote:
> You should really have a look at the lintian output.
> There are more privacy-breach-generic tagged errors in the quill files.
> Those should be addressed as well.
 
I agree with you, and have had a look a couple of times, now and in the past.
I agree that these should be addressed too.

Anyway, these are a few of my thoughts about this bug, and thank you for your 
eagerness to make Bibledit a perfect Debian package.

Teus.

Bug#1023504: pipewire: moc play no sound if pulseaudio purged from system

[Patrice Duroux]

Hi,

I think you need then to have also pipewire-pulse package installed if your
config configuration for ALSA is to go by Pulse.
On my side, mocp is working on my pipewire system.

Regards,
Patrice

Bug#1020640: libglew2.2: Glew built without, wxwidgets with EGL support

[Andreas Metzler]

Control: block 1023279 by 1020640

On 2022-10-10 Andreas Metzler  wrote:
> On 2022-10-03 Alastair McKinstry  wrote:
> > As maintainer would be open to changing Glew to EGL support, but need to
> > understand better the consequences.

[...]

Mandriva also enables glew egl but pulls a patchset from glew GIT head
https://github.com/OpenMandrivaAssociation/glew/tree/master and indeed
if I build glew GIT head (egl build, i.e. SYSTEM=linux-egl) and run
hugin against it it just works and does not crash.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1023504: pipewire: moc play no sound if pulseaudio purged from system

[Thom]

Package: pipewire
Version: 0.3.59-1+b1
Severity: normal
X-Debbugs-Cc: thom1...@gmail.com

Dear Maintainer,

I try to switch from pulseaudio to pipewire step by step through debian wiki 
guide. [1]
My previous setup pulseaudio + moc work pretty well.
This is the reason why i think this bug should be assight to pipewire.
So after installing pipewire pipewire-alsa wireplumber moc still have the 
posibillity to play sound.
But aftert I purge pulseaudio from system the sound is gone.

mpv and cmus works fine by the way.

Some reserch show that presence of
/etc/alsa/conf.d/99-pulse.conf
make sence in my case.

Can you please provide some hook for applications using alsa in case pulseaudio 
not present in system?

Thanks.


[1] https://wiki.debian.org/PipeWire#Debian_Testing.2FUnstable



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-0-amd64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 pipewire depends on:
ii  init-system-helpers  1.65.2
ii  libpipewire-0.3-modules  0.3.59-1+b1
ii  pipewire-bin 0.3.59-1+b1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#1023484: libsystemd0: upgrade from 251.6-1 to 252-2 fails with timed out (service_start_timeout=25000ms)

[Michael Biebl]

Control: reassign -1 systemd
Control: forcemerge 944645 -1

Am 05.11.22 um 15:23 schrieb Martin-Éric Racine:

#10 0xb7deeacf in manager_unref_uid_internal (uid_refs=0x109db30,
uid=4294948095, destroy_now=, _clean_ipc=0xb7a51bc0
) at ../src/core/manager.c:4269
 c = 
 n = 
 __PRETTY_FUNCTION__ = "manager_unref_uid_internal"
 __func__ = "manager_unref_uid_internal"
#11 0xb7e47eee in unit_unref_uid_internal (u=0x105f560,


Given it's the same Geode LX system and systemd aborts in 
manager_unref_uid_internal, let's merge the two issues.


This might be a hardware/toolchain specific issue, fwiw.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023503: busybox-static: "ALERT! UUID=xxx does not exist. Dropping to a shell!" since 1:1.35.0-3

[Stefan Berzl]

Package: busybox-static
Version: 1:1.35.0-3
Severity: normal

Hello everynyan!

Since 1:1.35.0-3, initramfs doesn't find the UUID of the root partition
anymore and drops me to a shell. In the shell however, the uuid is
listed in both /dev/disk/by-uuid and blkid.

At first, I didn't even know how I would boot going forward. First I
tried seting rootdelay in grub, but without any success. Only randomly
would I try to go root=/dev/sda2, setting the root partition by path,
thereby being able to see my login screen again.

Unsure of what to do, I tune2fs -U random every uuid and change the
fstab accordingly, followed by update-initramfs -u and update-grub.
When rebooting, initramfs just complains that it can't locate the new
uuid. Next I randomly downgrade packages that apt updated recently.
Ultimately I discover that when using busybox-static 1:1.35.0-2, the
problem is gone. When upgrading back to 1:1.35.0-3, it's there again.

There you go,

Bye


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

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

-- no debconf information

Bug#1023484: libsystemd0: upgrade from 251.6-1 to 252-2 fails with timed out (service_start_timeout=25000ms)

[Martin-Éric Racine]

On Sat, Nov 5, 2022 at 4:11 PM Martin-Éric Racine
 wrote:
>
> On Sat, Nov 5, 2022 at 4:02 PM Michael Biebl  wrote:
> >
> > Am 05.11.22 um 14:54 schrieb Martin-Éric Racine:
> > > On Sat, Nov 5, 2022 at 3:53 PM Michael Biebl  wrote:
> > >>
> > >> Control: tags -1 + moreinfo
> > >>
> > >> Am 05.11.22 um 10:25 schrieb Martin-Éric Racine:
> > >>>
> > >>> Message from syslogd@[localhost] at Nov  5 11:09:11 ...
> > >>>systemd[1]: Caught  from our own process.
> > >>>
> > >>
> > >>
> > >> Is this the same Geode system as in
> > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944645 ?
> > >>
> > >> If so, I think it's essentially the same issue.
> > >
> > > It probably is a return of the same issue.
> >
> > Is it the same Geode system?
>
> Yup.
>
> Martin-Éric

Here's what I get with the dbgsym packages installed:

$ sudo coredumpctl debug 1217
Failed to check if any systemd-coredump@.service units are running:
Yhteys aikakatkaistu
   PID: 1217 (systemd)
   UID: 0 (root)
   GID: 0 (root)
Signal: 6 (ABRT)
 Timestamp: Sat 2022-11-05 16:18:35 EET (1min 21s ago)
  Command Line: /sbin/init noquiet nosplash
Executable: /usr/lib/systemd/systemd
 Control Group: /init.scope
  Unit: init.scope
 Slice: -.slice
   Boot ID: 523225b0d5a24a65a1d62f1300f6c7eb
Machine ID: 1063a9d1fb9df6e371ea9f94491345ed
  Hostname: geode
   Storage:
/var/lib/systemd/coredump/core.systemd.0.523225b0d5a24a65a1d62f1300f6c7eb.1217.166765791500.zst
(present)
  Size on Disk: 531.6K
   Package: systemd/252-2
  build-id: e37b62ee63de4c1b55753371b32724427a4800ad
   Message: Process 1217 (systemd) of user 0 dumped core.

Module libsystemd-shared-252.so from deb systemd-252-2.i386
Module libsystemd-core-252.so from deb systemd-252-2.i386
Module systemd from deb systemd-252-2.i386
Stack trace of thread 1217:
#0  0xb7f23559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#1  0xb77d6de6 __kill (libc.so.6 + 0x36de6)
#2  0x0045b0c0 crash (systemd + 0xd0c0)
#3  0xb7f23570 __kernel_rt_sigreturn
(linux-gate.so.1 + 0x570)
#4  0xb7f23559 __kernel_vsyscall
(linux-gate.so.1 + 0x559)
#5  0xb7825ec7 __pthread_kill_implementation
(libc.so.6 + 0x85ec7)
#6  0xb77d6b41 __GI_raise (libc.so.6 + 0x36b41)
#7  0xb77c0262 __GI_abort (libc.so.6 + 0x20262)
#8  0xb7a24ffb log_assert_failed
(libsystemd-shared-252.so + 0x4fffb)
#9  0xb7deeacf manager_unref_uid_internal
(libsystemd-core-252.so + 0xa8acf)
#10 0xb7e47eee unit_unref_uid_internal
(libsystemd-core-252.so + 0x101eee)
#11 0xb7e3bff0 unit_free
(libsystemd-core-252.so + 0xf5ff0)
#12 0xb7df050c manager_dispatch_cleanup_queue
(libsystemd-core-252.so + 0xaa50c)
#13 0xb7df5e81 manager_loop
(libsystemd-core-252.so + 0xafe81)
#14 0x004540e0 main (systemd + 0x60e0)
#15 0xb77c13b5 __libc_start_call_main
(libc.so.6 + 0x213b5)
#16 0xb77c147f __libc_start_main_impl
(libc.so.6 + 0x2147f)
#17 0x00456507 _start (systemd + 0x8507)
ELF object binary architecture: Intel 80386

GNU gdb (Debian 12.1-3) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/systemd/systemd...
Reading symbols from
/usr/lib/debug/.build-id/e3/7b62ee63de4c1b55753371b32724427a4800ad.debug...
[New LWP 1217]
[New LWP 1]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `/sbin/init noquiet nosplash'.
Program terminated with signal SIGABRT, Aborted.
#0  0xb7f23559 in __kernel_vsyscall ()
[Current thread is 1 (LWP 1217)]

handle SIG33 pass nostop noprint
##
set pagination off
##
backtrace full
#0  0xb7f23559 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb77d6de6 in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
No locals.
#2  0x0045b0c0 in crash 

Bug#1023502: rust-maplit: please update to v1.0.2

[Jonas Smedegaard]

Source: rust-maplit
Version: 1.0.1-1
Severity: normal
Tags: upstream

Please update to newer upstream release v1.0.2, needed by projects I am
preparing for Debian.

 - Jonas

Bug#1023484: libsystemd0: upgrade from 251.6-1 to 252-2 fails with timed out (service_start_timeout=25000ms)

[Martin-Éric Racine]

On Sat, Nov 5, 2022 at 4:02 PM Michael Biebl  wrote:
>
> Am 05.11.22 um 14:54 schrieb Martin-Éric Racine:
> > On Sat, Nov 5, 2022 at 3:53 PM Michael Biebl  wrote:
> >>
> >> Control: tags -1 + moreinfo
> >>
> >> Am 05.11.22 um 10:25 schrieb Martin-Éric Racine:
> >>>
> >>> Message from syslogd@[localhost] at Nov  5 11:09:11 ...
> >>>systemd[1]: Caught  from our own process.
> >>>
> >>
> >>
> >> Is this the same Geode system as in
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944645 ?
> >>
> >> If so, I think it's essentially the same issue.
> >
> > It probably is a return of the same issue.
>
> Is it the same Geode system?

Yup.

Martin-Éric

Bug#1023484: libsystemd0: upgrade from 251.6-1 to 252-2 fails with timed out (service_start_timeout=25000ms)

[Michael Biebl]

Am 05.11.22 um 14:54 schrieb Martin-Éric Racine:

On Sat, Nov 5, 2022 at 3:53 PM Michael Biebl  wrote:


Control: tags -1 + moreinfo

Am 05.11.22 um 10:25 schrieb Martin-Éric Racine:


Message from syslogd@[localhost] at Nov  5 11:09:11 ...
   systemd[1]: Caught  from our own process.




Is this the same Geode system as in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944645 ?

If so, I think it's essentially the same issue.


It probably is a return of the same issue.


Is it the same Geode system?



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023484: libsystemd0: upgrade from 251.6-1 to 252-2 fails with timed out (service_start_timeout=25000ms)

[Martin-Éric Racine]

On Sat, Nov 5, 2022 at 3:53 PM Michael Biebl  wrote:
>
> Control: tags -1 + moreinfo
>
> Am 05.11.22 um 10:25 schrieb Martin-Éric Racine:
> >
> > Message from syslogd@[localhost] at Nov  5 11:09:11 ...
> >   systemd[1]: Caught  from our own process.
> >
>
>
> Is this the same Geode system as in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944645 ?
>
> If so, I think it's essentially the same issue.

It probably is a return of the same issue.

Martin-Éric

Bug#1023484: libsystemd0: upgrade from 251.6-1 to 252-2 fails with timed out (service_start_timeout=25000ms)

[Michael Biebl]

Control: tags -1 + moreinfo

Am 05.11.22 um 10:25 schrieb Martin-Éric Racine:


Message from syslogd@[localhost] at Nov  5 11:09:11 ...
  systemd[1]: Caught  from our own process.




Is this the same Geode system as in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944645 ?


If so, I think it's essentially the same issue.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023501: busybox-static: version 1:1.35.0-3 breaks boot on hppa

[John David Anglin]

Package: busybox-static
Version: 1:1.35.0-2
Severity: normal

Dear Maintainer,

With 1:1.35.0-3, boot ends in initramfs:

Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... 
   
mdadm: No arrays found in config file or automatically
done.
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
mdadm: error opening /dev/md?*: No such file or directory
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
mdadm: No arrays found in config file or automatically
Begin: Running /scripts/local-block ... mdadm: No arrays found in config file 
or
automatically
done.
done.
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  LABEL=ROOT2 does not exist.  Dropping to a shell!


BusyBox v1.35.0 (Debian 1:1.35.0-3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

dave@mx3210:~$ cat /proc/cmdline
root=LABEL=ROOT2 console=ttyS0 HOME=/ rootfstype=xfs clocksource=jiffies 
TERM=xterm palo_kernel=2/vmlinuz

The LABEL=ROOT2 does exist:
dave@mx3210:~$ ls /dev/disk/by-label
BOOT2  DAVE  HOME2  ROOT2  VAR2

There are no mdadm arrays on system.

Reverting to 1:1.35.0-2 and updating affected initrd.img files fixes 

Bug#1022111: python-stem: pypy-stem ships a Python2 version

[Bastian Germann]

I have just NMUed the package to get rid of pypy-stem.
The only affected reverse dependency is vanguards.
The changes are in the git repository.

Bug#1023493: libmpg123-dev: trying to overwrite shared '/usr/include/mpg123.h', which is different from other instances of package libmpg123-dev:i386

[Thomas Orgis]

Am Sat, 05 Nov 2022 12:07:57 +
schrieb Witold Baryluk : 

>  trying to overwrite shared '/usr/include/mpg123.h', which is
> different from other instances of package libmpg123-dev:i386

Oh, dear. I broke multiarch headers again. By trying to fix BSDs that
don't react to _FILE_OFFSET_BITS at all, I introduced a build
dependency in the header. Again. Dammit.

For i386, you want largefile names. for x86-64, you don't. This is about

#if !defined(MPG123_LARGESUFFIX) && 1

or

#if !defined(MPG123_LARGESUFFIX) && 0


(the value of @BUILD_NO_LARGENAME@ in mpg123.h.in). The 0 or 1 is
determined by AC_SYS_LARGEFILE detecting largefile-sensitivity or not.
Linux/i386 is sensitive, Linux/x86-64 is not.

So either you need to scope the mpg123.h into the multiarch
sub-directories or it needs enhancement to figure out
largefile-sensitivity from macros alone. There's a reason this is no
simple macro hack but figured out at configure-time.

Since we do have off_t in the API (an error I regret but which I am
committed to for backwards compatibility), I guess the API and thus the
header _is_ architecture-specific, as not just the size of off_t
varies, but even the state of it having a fixed size at all.

Bug#1023494: apt: package cache file is corrupted after upgrade from 2.5.2 to 2.5.4

[Shengjing Zhu]

On Sat, Nov 5, 2022 at 8:58 PM Julian Andres Klode  wrote:
>
> On Sat, Nov 05, 2022 at 08:53:29PM +0800, Shengjing Zhu wrote:
> > Hi,
> >
> > On Sat, Nov 5, 2022 at 8:49 PM Julian Andres Klode  wrote:
> > >
> > > On Sat, Nov 05, 2022 at 08:08:41PM +0800, Shengjing Zhu wrote:
> > > > Package: apt
> > > > Version: 2.5.4
> > > > Severity: important
> > > > X-Debbugs-Cc: z...@debian.org
> > > >
> > > > Dear Maintainer,
> > > >
> > > > After upgrade to 2.5.4, `apt-cache --no-generate pkgnames ''` gives me:
> > > >
> > > > E: The package cache file is corrupted, it has the wrong hash
> > >
> > > Yes, this is of course expected. The version is hashed into the
> > > cache hash, and you told it to not generate a new cache, so it
> > > can't make any progress here.
> >
> > Could you elaborate "you told it to not generate a new cache"?
> > I don't see any special configuration there.
>
> You literally used --no-generate
>

Ok. However this is what is in the bash completion scripts.

I find the problem because apt's bash completion stops working today.
So users are expected to do an `apt clean && apt update` to regenerate
the cache after upgrading apt?

-- 
Shengjing Zhu

Bug#1023494: apt: package cache file is corrupted after upgrade from 2.5.2 to 2.5.4

[Julian Andres Klode]

On Sat, Nov 05, 2022 at 08:53:29PM +0800, Shengjing Zhu wrote:
> Hi,
> 
> On Sat, Nov 5, 2022 at 8:49 PM Julian Andres Klode  wrote:
> >
> > On Sat, Nov 05, 2022 at 08:08:41PM +0800, Shengjing Zhu wrote:
> > > Package: apt
> > > Version: 2.5.4
> > > Severity: important
> > > X-Debbugs-Cc: z...@debian.org
> > >
> > > Dear Maintainer,
> > >
> > > After upgrade to 2.5.4, `apt-cache --no-generate pkgnames ''` gives me:
> > >
> > > E: The package cache file is corrupted, it has the wrong hash
> >
> > Yes, this is of course expected. The version is hashed into the
> > cache hash, and you told it to not generate a new cache, so it
> > can't make any progress here.
> 
> Could you elaborate "you told it to not generate a new cache"?
> I don't see any special configuration there.

You literally used --no-generate

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1023494: apt: package cache file is corrupted after upgrade from 2.5.2 to 2.5.4

[Shengjing Zhu]

Hi,

On Sat, Nov 5, 2022 at 8:49 PM Julian Andres Klode  wrote:
>
> On Sat, Nov 05, 2022 at 08:08:41PM +0800, Shengjing Zhu wrote:
> > Package: apt
> > Version: 2.5.4
> > Severity: important
> > X-Debbugs-Cc: z...@debian.org
> >
> > Dear Maintainer,
> >
> > After upgrade to 2.5.4, `apt-cache --no-generate pkgnames ''` gives me:
> >
> > E: The package cache file is corrupted, it has the wrong hash
>
> Yes, this is of course expected. The version is hashed into the
> cache hash, and you told it to not generate a new cache, so it
> can't make any progress here.

Could you elaborate "you told it to not generate a new cache"?
I don't see any special configuration there.

PS, the reproducible steps in docker have a `rm
/etc/apt/apt.conf.d/docker-clean` line.

-- 
Shengjing Zhu

Bug#1023500: grpc-java: FTBFS with protobuf 3.21

[GCS]

Source: grpc-java
Version: 1.26.0+ds-1
Severity: important
Usertags: protobuf3_21
Tags: ftbfs patch bookworm sid

Hi,

I would like to start the Protobuf transition. Your package fails to
build since it tries to include a header which is moved to a new name.
Simple patch is attached to update this.
Please be prepared to upload the updated package when the transition starts.

Thanks,
Laszlo/GCS
Description: protobuf header rename
 Use the new header name for ProtoBuf 3.26+
Author: Laszlo Boszormenyi (GCS) 
Last-Update: 2022-10-04

---

--- grpc-java-1.26.0+ds.orig/compiler/src/java_plugin/cpp/java_generator.cpp
+++ grpc-java-1.26.0+ds/compiler/src/java_plugin/cpp/java_generator.cpp
@@ -22,7 +22,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 

Bug#1023279: Segfault on startup; stack overflow involving libwx

[Andreas Metzler]

On 2022-11-01 Michael Deegan  wrote:
> Package: hugin
> Version: 2021.0.0+dfsg-3
> Severity: important

> Console output:
[...]
> ERROR: 22:42:22.231532 (./src/hugin1/hugin/GLViewer.cpp:133) 
> SetUpContext(): Error initialising GLEW: Unknown error.
> Segmentation fault

> I'm wondering if it's the result of a recent libc upgrade, but I'm not about
> to attempt a downgrade to verify. :P I did try running Hugin in a libvirt
> VM, but I think there it's being fussy about the virtual environment
> (despite having working direct-rendering opengl).
[...]

It is WX related, problably missing EGL support in glew. 

It worked my in own tests. I realize now that was because I have this
setting in ~/.config/hugin.conf:
[GLPreviewFrame]
[...]
isShown=0

(i.e. The OpenGL Preview window does not autoopen). I then need two
klicks to actually open it (the first try fails) but apart from that
hugin works.

Does this workaround also work at your system?

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1021951: man-db: less(1) option injection

[Colin Watson]

On Tue, Oct 18, 2022 at 12:35:53PM +0200, Jakub Wilk wrote:
> * Colin Watson , 2022-10-18 00:12:
> > https://gitlab.com/cjwatson/man-db/-/commit/09304c00a4a3dea95da5d1f0aa1ad4c20c292f3b
> 
> Unfortunately this isn't quite right.
> 
> The fix broke prompts for man pages that had special characters in their
> titles. For example, for apt.conf.5 the prompt looks like this:
> 
>  Manual page aptconf(5) line 1 ...
[...]
> All in all, I think --use-backslash is not worth the trouble. Maybe just
> replace dollars with something harmless (say, question marks)? I doubt there
> are any non-nefarious use cases for dollars man page titles.

OK, I see your point.  Done:

  
https://gitlab.com/cjwatson/man-db/-/commit/0d80ec4d5c987acb502a7787240f56e3cec65497

(Sorry for the delay; I've been travelling.)

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1023499: src:python-suitesparse-graphblas: fails to migrate to testing for too long: FTBFS on i386

[Paul Gevers]

Source: python-suitesparse-graphblas
Version: 6.2.4.0-3
Severity: serious
Control: close -1 7.2.0.0-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:python-suitesparse-graphblas has been 
trying to migrate for 61 days [2]. Hence, I am filing this bug. Your 
package failed to build on i386 while it built successfully there in the 
past.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=python-suitesparse-graphblas



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023498: cura-engine: FTBFS with protobuf 3.21

[GCS]

Source: cura-engine
Version: 1:4.13.0-1
Severity: important
Usertags: protobuf3_21
Tags: ftbfs bookworm sid

Hi,

I would like to start the Protobuf 3.29 transition soon, it's a;ready
available from experimental. While your package builds fine with it,
self-testing fails:
The following tests FAILED:
  2 - GCodeExportTest (SEGFAULT)
  3 - InfillTest (SEGFAULT)
  4 - LayerPlanTest (SEGFAULT)
  5 - MergeInfillLinesTest (SEGFAULT)
  6 - PathOrderMonotonicTest (SEGFAULT)
  7 - TimeEstimateCalculatorTest (SEGFAULT)
  8 - SlicePhaseTest (SEGFAULT)
  9 - SettingsTest (SEGFAULT)
 10 - ArcusCommunicationTest (SEGFAULT)
 11 - ArcusCommunicationPrivateTest (SEGFAULT)
 17 - PolygonConnectorTest (SEGFAULT)
 18 - PolygonTest (SEGFAULT)
 19 - PolygonUtilsTest (SEGFAULT)

However, I realized you have a newer upstream version packaged in
experimental. It needs a newer libarcus package version which is also
available from experimental. With that version, your package builds
and self-tests correctly.

Regards,
Laszlo/GCS

Bug#1023497: libarcus: FTBFS with protobuf 3.21

[GCS]

Source: libarcus
Version: 5.0.0-1
Severity: important
Usertags: protobuf3_21
Tags: ftbfs patch experimental

Hi,

I do plan to start the Protobuf 3.29 transition which is already
available from experimental. While your package in Sid compiles as
expected, the experimental version is not. As it's needed for the
cura-engine package, the version which is in experimental I provide
you a simple patch.
Please be prepared to apply it and upload to Sid when the Protobuf
transition starts.

Thanks,
Laszlo/GCS
Description: warning is no longer an option for SetTotalBytesLimit()
 Just remove the second argument.
Author: Laszlo Boszormenyi (GCS) 

---
Last-Update: 2022-11-05

--- libarcus-5.0.0.orig/src/Socket_p.h
+++ libarcus-5.0.0/src/Socket_p.h
@@ -128,9 +128,6 @@ namespace Arcus
 
 static const int keep_alive_rate = 500; //Number of milliseconds between sending keepalive packets
 
-// This value determines when protobuf should warn about very large messages.
-static const int message_size_warning = 400 * 1048576;
-
 // This value determines when protobuf should error out because the message is too large.
 // Due to the way Protobuf is implemented, messages large than 512MiB will cause issues.
 static const int message_size_maximum = 500 * 1048576;
@@ -548,7 +545,7 @@ namespace Arcus
 
 google::protobuf::io::ArrayInputStream array(wire_message->data, wire_message->size);
 google::protobuf::io::CodedInputStream stream();
-stream.SetTotalBytesLimit(message_size_maximum, message_size_warning);
+stream.SetTotalBytesLimit(message_size_maximum);
 if(!message->ParseFromCodedStream())
 {
 error(ErrorCode::ParseFailedError, "Failed to parse message:" + std::string(wire_message->data));

Bug#1023496: target-factory: FTBFS with protobuf 3.21

[GCS]

Source: target-factory
Version: 2.5-7
Severity: important
Usertags: protobuf3_21
Tags: ftbfs bookworm sid

Hi,

Building your package with Protobuf 3.21.9 release available in
experimental works. On the other hand it causes symbols difference for
your library. Snippet of those:
 libtarget-factory.so.2 libtarget-factory2 #MINVER#
+ _Z38descriptor_table_target_2eproto_getterv@Base 2.5-7
+ _ZN5vitis2ai10Target_Alu12_class_data_E@Base 2.5-7
- _ZN5vitis2ai10Target_Alu16default_instanceEv@Base 2.0
+#MISSING: 2.5-7# _ZN5vitis2ai10Target_Alu16default_instanceEv@Base 2.0
+#MISSING: 2.5-7# _ZN5vitis2ai10Target_Alu21InitAsDefaultInstanceEv@Base 2.0

Please be prepared to update your library symbols file when the
transition starts.

Regards,
Laszlo/GCS

Bug#992743: RFP: furo -- clean customisable Sphinx documentation theme

[Jonas Smedegaard]

Quoting Georges Khaznadar (2022-11-05 11:15:53)
> Jonas Smedegaard a écrit :
> > Quoting Georges Khaznadar (2022-11-04 19:49:04)
> > > *all* sources are contained in the upstream package, copyright owners
> > > and license details are in the file debian/copyright.
> > 
> > Please don't stuff sources from multiple upstream sources together - see
> > Debian Policy § 4.13.
> 
> May I compare the intented package furo with other packages?

Sure.  Just please keep in mind that two wrongs don't make a right:
Similar issues in other packages might be similar bugs on those packages
(rather than proof that your package is not buggy).

That said, it makes great sense to compare against other packages for
inspiration and for getting a better understanding of how to possibly
approach some issues (and certainly helps to compare against packages
maintained by those you discuss issues with ;-) ).

Concretely, however, I fail to recognize your point in comparing against
abiword: True, there are multiple copyright holders and multiple
licenses involved, but what I pointed out being an issue was (not that,
but instead) you as package maintainer stuffing together multiple
upstream sources in one source package.


> If we look at /usr/share/doc/abiword/copyright, there are more than
> one author and more than one free software license in the list. 
> 
> Regarding furo, the source which does not come from the main developer
> is gumshoe-patched.js, authored by Chris Ferdinandi three years ago,
> under MIT license. cfernandi's original work is at 
> https://github.com/cferdinandi/gumshoe/blob/master/src/js/gumshoe/gumshoe.js
> and Pradyun Gedam (furo's author) is maintaining a modified version of
> the script, quoting the original autor.

What I reacted on was your mentioning use of npm and pip.

Fine that a source package contains sources for a fork of another
project, when the fork is intended for use uniquely as part of this
project.

If the fork is not maintained by upstream, then better to try avoid that
fork.  Often best approach is to identify need for forking and propose
the original-of-the-fork proj́ect to adopt needed changes.  Another more
tricky approach is to "fork during build" by coordinating with the
Debian maintainer of original-of-the-fork project to provide source, and
use that to apply a locally-by-you maintained patch during your build.

If the fork is intended for reuse across multiple projects, then better
to maintain packaging of that fork as a separate source package.

If the fork contains (not only source but also) generated files, then
best to regenerate those files during build.  Yes, it is also an option
to ensure in other ways that the source *can* produce the exact included
generated code using only locally Debian-packaged tools, but that is
often more tricky than simply regenerating the code.


> I have been applying Debian Policy § 4.13 quite a few times, most of
> them about embedded copies of Javascript libraries like jquery,
> jquery-ui, bootstrap, and so on, which are often embedded by developers
> publishing their code. In such a case, the Policy states that "the
> Debian packaging should ensure that binary packages reference the
> libraries already in Debian", which I do.
> 
> As far as `apt-file` can tell me, there is currently no debian package
> referring to gumshoe.js; if I apply the Policy in a stric fashion, then
> "If the included code is not already in Debian, it should be packaged
> separately as a prerequisite if possible.", and as a footnote in the
> policy I can read "Having multiple copies of the same code in Debian is
> inefficient, often creates either static linking or shared library
> conflicts, and, most importantly, increases the difficulty of handling
> security vulnerabilities in the duplicated code."
> 
> However, as there is no debian package currently using gumshoe.js,
> packaging it separately would not reduce any redundancy. On the other
> hand, which version of the script should be packaged? cferdinandi's
> version? As my goal is to package furo, which is used by the last
> version od sympy, which I am maintaining, sould I rather package 
> separately gumshoe-patched.js, which was modified by Pradyun Gedam?
> 
> I am feeling that this point in our discussion is much about the level
> of granularity of debian packaging: the smallest the grains, the more
> flexibility for reusing them in combination with others. However
> packages reused by a single other package are not beneficial.

Your approach "increases the difficulty of handling security
vulnerabilities in the duplicated code", as you quote yourself.  That's
the issue that concerns me here (not, as you seem to try frame it, mere
nitpicking over busywork).

Also, to answer your (inmplied) question: Yes, I do find it beneficial
that our users could do "apt install libjs-gumshoe".

Or, if the fork is truly needed, our users might quite possibly instead
find beneficial to be able to do "apt install 

Bug#1023495: transition: ruby3.1

[Antonio Terceiro]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi, I would like to plan the ruby 3.1 transition. As soon as we have the
tracker I will perform all the test rebuilds necessary and report any
bugs.

Ben file:

title = "ruby3.1 as default";
is_affected = (.depends ~ /ruby3.0/ | .depends ~ /ruby3.1/) & !.source ~ 
/^(ruby3.0|ruby3.1|ruby-defaults)$/;
is_good = .depends ~ "ruby3.1" | .depends ~ "libruby3.1" | ! (.depends ~ 
"ruby3.0" | .depends ~ "libruby3.0");
is_bad = ! (.depends ~ "ruby3.1" | .depends ~ "libruby3.1") & (.depends ~ 
"ruby3.0" | .depends ~ "libruby3.0");


signature.asc
Description: PGP signature

Bug#1023494: apt: package cache file is corrupted after upgrade from 2.5.2 to 2.5.4

[Shengjing Zhu]

Package: apt
Version: 2.5.4
Severity: important
X-Debbugs-Cc: z...@debian.org

Dear Maintainer,

After upgrade to 2.5.4, `apt-cache --no-generate pkgnames ''` gives me:

E: The package cache file is corrupted, it has the wrong hash

I can reproduce this in a docker container.

Steps:

 start 
zhsj@debian:~$ docker run --rm -it debian:testing-slim bash
root@319d23ccf45d:/# dpkg -l|grep apt
ii  apt 2.5.2 amd64
commandline package manager
ii  libapt-pkg6.0:amd64 2.5.2 amd64
package management runtime library
root@319d23ccf45d:/# rm /etc/apt/apt.conf.d/docker-clean 
root@319d23ccf45d:/# apt update
Get:1 http://deb.debian.org/debian testing InRelease [164 kB]
Get:2 http://deb.debian.org/debian-security testing-security InRelease [48.0 kB]
Get:3 http://deb.debian.org/debian testing-updates InRelease [49.6 kB]
Get:4 http://deb.debian.org/debian testing/main amd64 Packages [8706 kB]
Fetched 8967 kB in 5s (1641 kB/s)   
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
53 packages can be upgraded. Run 'apt list --upgradable' to see them.
root@319d23ccf45d:/# apt-cache --no-generate pkgnames 'docker.io'
docker.io
root@319d23ccf45d:/# apt install apt
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  usr-is-merged
Use 'apt autoremove' to remove it.
The following additional packages will be installed:
  libapt-pkg6.0
Suggested packages:
  apt-doc aptitude | synaptic | wajig dpkg-dev gnupg | gnupg2 | gnupg1 
powermgmt-base
Recommended packages:
  ca-certificates
The following packages will be upgraded:
  apt libapt-pkg6.0
2 upgraded, 0 newly installed, 0 to remove and 51 not upgraded.
Need to get 2264 kB of archives.
After this operation, 272 kB disk space will be freed.
Do you want to continue? [Y/n] 
Get:1 http://deb.debian.org/debian testing/main amd64 libapt-pkg6.0 amd64 2.5.4 
[902 kB]
Get:2 http://deb.debian.org/debian testing/main amd64 apt amd64 2.5.4 [1362 kB]
Fetched 2264 kB in 1s (1860 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 6593 files and directories currently installed.)
Preparing to unpack .../libapt-pkg6.0_2.5.4_amd64.deb ...
Unpacking libapt-pkg6.0:amd64 (2.5.4) over (2.5.2) ...
Setting up libapt-pkg6.0:amd64 (2.5.4) ...
(Reading database ... 6593 files and directories currently installed.)
Preparing to unpack .../archives/apt_2.5.4_amd64.deb ...
Unpacking apt (2.5.4) over (2.5.2) ...
Setting up apt (2.5.4) ...
Processing triggers for libc-bin (2.34-7) ...
root@319d23ccf45d:/# apt-cache --no-generate pkgnames 'docker.io'
E: The package cache file is corrupted, it has the wrong hash

 end 

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "false";
APT::Install-Suggests "false";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::AutoRemove "";
APT::AutoRemove::RecommendsImportant "false";
APT::AutoRemove::SuggestsImportant "false";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";

Bug#1023493: libmpg123-dev: trying to overwrite shared '/usr/include/mpg123.h', which is different from other instances of package libmpg123-dev:i386

[Witold Baryluk]

Package: libmpg123-dev
Version: 1.31.0-1
Severity: serious
Justification: multiarch spec
X-Debbugs-Cc: witold.bary...@gmail.com

Dear Maintainer,

Unpacking libmpg123-dev:i386 (1.31.0-1) over (1.30.2-1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-9aeVDc/03-libmpg123-dev_1.31.0-1_i386.deb (--unpack):
 trying to overwrite shared '/usr/include/mpg123.h', which is different from 
other instances of package libmpg123-dev:i386




Regards,
Witold

Bug#1019805: 4pane: Please transition to wxwidgets3.2

[david]

>On Fri, 4 Nov 2022, da...@4pane.co.uk wrote:
>
 My apologies for the delay in replying. While the fix itself was easy, I
 wanted to incorporate it into the forthcoming 4pane release, avoiding the
 hassle of an extra RFS.

 I've now done this and uploaded it to mentors
 (https://mentors.debian.net/package/4pane/ and
 https://mentors.debian.net/debian/pool/main/4/4pane/4pane_8.0-1.dsc).
 However that gives only a few days for a sponsor to appear before 4pane is
 autoremoved on 8/11. So if you, or someone you know, would be able to do
 this I'd be most grateful. Or if it's possible to delay the autoremoval...
>>>
>>> I'm happy to sponsor.
>>
>> That's great! Thank you.
>>
>>> However, the first thing I notice is that the package
>>> still Build-Depends on libwxgtk3.0-gtk3-dev...
>>> Scott
>>
>> Argh! I'd not noticed that. Now fixed and re-uploaded.
>>
>> I didn't add libwxgtk3.0-gtk3-dev to Build-Conflicts, but it doesn't seem to
>> be necessary: a test build picked the 3.2-dev even though both were present.
>> However I can easily do so if you prefer.
>
>Uploaded.
>
>Can you please commit that Build-Depends change to your packaging repo and
>also tag it "debian/8.0-1"?

Done.

Many thanks for the upload!

David

Bug#1014537: unnamed packaging files in a multibinary package should be an error

[Niels Thykier]

Control: tags 1023056 moreinfo
Control: tags 1023057 moreinfo

Axel Beckert:

Hi Niels,

Niels Thykier wrote:

I understand that you are unsatisfied with this proposal and that is
fair.


Thanks.


Though from my point of view, your email makes it hard for me to want to
engage with you to find a solution that would (ideally) satisfy your desires


I'm sorry, but at that point I have to say the very same about your
previous e-mail. IMHO this is not a one-sided thing. See below for an
explanation.


> [...]

Hi Axel,

First off, thanks for your reply.  I very much appreciate you reaching 
out here and putting your concerns forward as that enables to find 
common ground and work on resolving the conflict. :)


Also, sorry for the late reply. My "post-work" mental bandwidth this 
week has not enabled me to have adequate capacity for my follow up until 
now.



As for your concerns, I have read them and I feel that we have two 
conflicts that have been entangled into one.  Therefore, I would like to 
first attempt to untangle them and solve them separately.  As I see it, 
the current conflict is this bug (#1014537) but there is also the 
initial conflict related to the changelog trimming.



As I understood you, your issues are - *for this bug specifically*:


 1) You feel that I have made a final decision.  Here you mention the
cloning of bug and the debian/{TODO,README.Debian} as two things
that made you feel the decision to be final.

 2) While you agreed with Steve's feature request you did not feel my
proposed solution to Steve's request matched what you had expected
of me.

- For completeness, it is a bit unclear to me whether you also feel
  this ties in to point about changes not being discussed on the
  proper channel. It is possible for me to see narrative that given
  you also felt the proposal was a final decision - but maybe I am
  over reading you here.

 3) Current frustration with the changelog trimming.  I think a very
quick summary is that you feel changelog trimming proposal was not
discussed on the proper channels and also you strongly disagree with
the concept itself.

 - Note I am deliberately keeping this short because I understand it
   as an existing source of frustration caused by a different
   conflict.  Notably, this is the separate conflict I want to
   untangle from the current one about unnamed packaging files.
   However, since you explicitly brought the frustration caused by
   that conflict, I felt the summary would be incomplete without
   mentioning this part as well.

I hope you feel that is an accurate summary of the conflict related to 
*this* bug about unnamed packaging files in multi-binary packages.


  If you do *not* feel it was a good summary, then please stop reading
  more of this email and tell me where I misunderstood or misread you.

  The rest of my email is based on the above being a reasonably accurate
  understand of the conflict.  If I missed the mark on understanding
  you, the rest of the email will probably just feel like an aggravating
  straw man discussion to you and that is not what either of us want.


In a face to face discussion, I would normally wait for you to confirm 
that my summary was good enough. However, I am going to risk optimizing 
a bit by reducing the number of email round trips because I suspect the 
conflict related to this bug will be easy to resolve.




  => Again, if you felt I misread you above, please stop here and tell
 me where I was wrong.





I would like to start by addressing the part where you felt I made a 
final decision. My previous email was *not* intended to be a final 
decision. It was my request for feedback on my proposed solution.


Diving a bit deeper in what I intended with the actions you mentioned as 
making it feel like a final decision:


 * The cloned bug was me noting gregor suggesting a lintian tag for this
   and me thinking "let me just do it immediately, so I do not forget".
   Admittedly, the bugs should probably have been tagged moreinfo as
   well because the actual requested change had not (and is still not)
   fleshed out yet.  I have done this now.

 * My mention of debian/{TODO,README.Debian} was related to the part
   where I was leaving these files as exceptions to Steve's request.  If
   Steve (or someone else) wanted this particular exception "undone", I
   wanted that person to drive the discussion to show there was
   consensus for that change.

I hope the above clarified my actions and made it clear that I never 
intended this to be a "final decision".




As for my proposal not being what you had expected.  My intention with 
the email was to discuss my proposed solution. We all have different 
priorities and I made my proposal in a way I felt were aligned with the 
original proposal while also helping me with some of my priorities. 
However, I was aware that it was a potential controversial point, so 

Bug#1019425: dkms 3.0.6-2 not signing modules

[Holger Schröder]

Upstream has fixed this issue.


https://github.com/dell/dkms


...

Bug#1021668: xen: CVE-2022-33749 CVE-2022-33748 CVE-2022-33747 CVE-2022-33746

[Hans van Kranenburg]

Hi :)

On 04/11/2022 22:51, Salvatore Bonaccorso wrote:
> Hi Hans
> 
> On Fri, Nov 04, 2022 at 02:59:29PM +0100, Hans van Kranenburg wrote:
>> Aha!
>>
>> On 02/11/2022 21:53, Salvatore Bonaccorso wrote:
>>> Hi,
>>>
>>> On Wed, Nov 02, 2022 at 08:02:26PM +0100, Hans van Kranenburg wrote:
 Hi,

 On 10/19/22 21:55, Moritz Muehlenhoff wrote:
>>> For the latest set of Xen issues my estimate is that we can postpone
>>> them until the next batch, they seem all of moderate/limited impact.
>>> But let me know if you think otherwise.
>>
>> I agree. Let's do them together with the new stuff that's planned for
>> Nov 1st, https://xenbits.xen.org/xsa/
>
> Ack, I've updated the Security Tracker.

 I'm having a look at this now, and while writing the changelog entry, I
 run into the following thing:

 XSA-403 has 4 CVE numbers. AFAIUI the first two are about the fixes done
 to Linux, and the other two are about changes to Xen. Shouldn't the
 Debian security tracker reflect that?

 CVE-2022-26365 CVE-2022-33740 -> src:linux only ?
 CVE-2022-33741 CVE-2022-33742 -> src:xen only ?
>>>
>>> Speaking for src:linux I do not think we need to change the tracking:
>>>
>>> CVE-2022-26365: 2f446ffe9d73 ("xen/blkfront: fix leaking data in shared 
>>> pages")
>>> CVE-2022-33740: 307c8de2b023 ("xen/netfront: fix leaking data in shared 
>>> pages")
>>> CVE-2022-33741: 4491001c2e0f ("xen/netfront: force data bouncing when 
>>> backend is untrusted")
>>> CVE-2022-33742: 2400617da7ee ("xen/blkfront: force data bouncing when 
>>> backend is untrusted")
>>
>> Riiight. Thanks, now I get why I cannot find any CVE number related to
>> XSA-403 listed in the Xen upstream changes (at least for 4.14 which I'm
>> working on now). They're all over there at the Linux side.
> 
> It looks that there are still changes needed on the xen side, at least
> that is my understanding reading through 
> https://xenbits.xen.org/xsa/advisory-403.html 
> Quoting the advisory:
> 
> | For the stable branches (Xen 4.16.x - Xen 4.13.x) patch 1 introduces 
> support to
> | libxl for libxl_{disk,nic}_backend_untrusted environment variable to be 
> used in
> | order to set whether disk and network backends should be trusted.  Patch 2
> | reverts patch 1 and instead provides the more fine grained per-device 
> options
> | that break the libxl ABI.
> | 
> | Note that applying patch 2 to any of the stable releases will require a 
> rebuild
> | of any consumers of the libxl library, as it introduces an ABI breakage and
> | hence won't be applied to the official repository stable branches.  Users of
> | stable releases wanting to use the functionality provided by patch 2 will 
> need
> | to apply it manually.
> 
> This is the reason that in fact for those four CVEs, weh ave marked
> for bullseye:
> 
> [bullseye] - xen  (Too intrusive too backport)
> 
> The "signaling of whether a frontend should consider a backend as
> potentially malicious can be done **from either the Linux kernel
> command line or the toolstack.**" (highlighting is added by me).
> 
> So IMHO it is similarly correct to track src:xen under those CVEs, and
> they are marked as fixed with 4.16.2-1. *But* for bullseye, they can
> be ignored due to above reasons.

Yes, so the Xen part is about the "reporting whether the backend is to
be trusted".

That 'patch 1', the all-or-nothing option to signal the guest kernel is
now included with this update. But neither that change, nor the more
fine-grained patch 2 is directly linked to a CVE number. That change on
itself will not fix anything for any of the 4 CVE numbers.

Also, for 4.16 the story is the same, by the way. It's only in 4.17
which is to be released in the upcoming week that the otherwise lilbxl
ABI breaking changes are fully included, but even that doesn't change
anything for the CVE administration.

After all, it is a bit of a moot point for us. The only scenario in
which all of this is relevant is when using a 'driver domain' to
delegate the blk/net backend part to another untrusted guest domain.
Using this functionality is not properly enabled/supported out of the
box in our package builds for Debian.

Sometimes these XSA are like a little scavenger hunt.

Hans

Bug#1023492: linux-signed-amd64: Cannot boot with message "cryptsetup: Waiting for encrypted source device UUID=xxxx..."

[Hideki Yamane]

Source: linux-signed-amd64
Version: 6.0.6+2
Severity: important

Dear Maintainer,

 I cannot boot my amd64 PC with linux-image-6.0.0-2-amd64, it just shows
 "cryptsetup: Waiting for encrypted source device UUID=" again and again,
 then falled down to busybox shell. With 6.0.0-1 works, 6.1~rc3+1~exp1 in
 experimental also does not work.


$ LANG=C df -h -x tmpfs
Filesystem   Size  Used Avail Use% Mounted on
udev  15G 0   15G   0% /dev
/dev/mapper/tiny--vg-system  328G  224G  104G  69% /
/dev/sda2235M  221M  1.8M 100% /boot
/dev/mapper/tiny--vg-home559G  391G  168G  70% /home
/dev/nvme0n1p1   256M   34M  223M  14% /boot/efi


$ mount|grep mapper
/dev/mapper/tiny--vg-system on / type btrfs 
(rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
/dev/mapper/tiny--vg-home on /home type btrfs 
(rw,relatime,compress=zstd:3,ssd,space_cache,subvolid=5,subvol=/)



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

Kernel: Linux 6.0.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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#1023491: ovmf-ia32 lacks non-secboot firmware images, but qemu does not (yet) support secboot

[Alain Knaff]

Package: ovmf-ia32
Version: 2020.11-2+deb11u1

Hi,

Recently I wanted to analyze behavior of a 32-bit EFI OS bootfile, and
wanted to setup a KVM with 32 bit UEFI to do this.

However, qemu/kvm apparently does not (yet) support .secboot.fd UEFI
images, but these are the only ones available in ovmf-ia32.

Qemu just hangs on "Gues has not initialized the display (yet)" when
given a secboot image (when specified with -drive if=pflash...), or
fails immediately with "could not load PC BIOS ..." when specified with
-bios (but the latter happens with any 4M firmware image)

Eventually, I got ahead by getting an old RPM from Fedora 30, which does
also contain a non-secboot firmware image. This booted just fine on my
Debian Qemu.

Please bring back non-secboot images, until qemu can support secboot (or
until they supply readily discoverable documentation how to use secboot).

N.B. Non-secboot images are available alright in the 64bit version of
ovmf, but unfortunately I needed an 32bit UEFI for my tests.

Regards,

Alain

Bug#1022577: llvm-toolchain-15 fails with LLVM ERROR when using mesa

[Simon McVittie]

Control: retitle -1 llvm-toolchain-15: Mesa on armel,armhf fails with LLVM 
ERROR: Cannot select
Control: tags -1 + patch fixed-upstream

On Mon, 24 Oct 2022 at 12:45:01 +0300, Adrian Bunk wrote:
> https://buildd.debian.org/status/fetch.php?pkg=mutter=armhf=43.0-3=1666029584=0
> 
> ...
> # Start of pipeline tests
> LLVM ERROR: Cannot select: 0x1300f80: v4i32 = ARMISD::VCMPZ 0x1301c70, 
> Constant:i32<2>
>   0x1301c70: v4i32,ch = ARMISD::VLD1DUP<(load (s32) from %ir.212)> 0xdf9afc, 
> 0x131c538:1, Constant:i32<4>
> 0x131c538: i32,i32,ch = load<(load (s32) from %ir.209, align 8), 
> > 0xdf9afc, 0x12fb7e0, Constant:i32<64>
>   0x12fb7e0: i32,ch = CopyFromReg 0xdf9afc, Register:i32 %23
> 0x12e99c0: i32 = Register %23
>   0x131a9a8: i32 = Constant<64>
> 0x1319fd0: i32 = Constant<4>
>   0x131a2e8: i32 = Constant<2>
> In function: fs_variant_partial
> ...
> 
> 
> Some discussion is in
> https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-15/+bug/1993800

According to upstream bug 
this is fixed by commit
.

smcv

Bug#1022526: python-ssdeep: FTBFS: distutils.errors.DistutilsClassError: command class must subclass Command

[Helmut Grohne]

Control: tags -1 + upstream

On Sun, Oct 23, 2022 at 03:37:36PM +0200, Lucas Nussbaum wrote:
> Source: python-ssdeep
> Version: 3.1+dfsg-3
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20221023 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

At the time when I introduced python-ssdeep to Debian, fuzzy hashing was
not a thing. tlsh didn't exist. Now it is there and tlsh seems
technically supperior albeit incompatible. So unless there is some
compatibility reason for keeping ssdeep, I think it should be RoQAed.

And no, updating it to 3.4 does not fix the ftbfs.

Would someone handle dnstwist, which is the only remaining dependency?

Helmut

Bug#992743: RFP: furo -- clean customisable Sphinx documentation theme

[Georges Khaznadar]

Hi Jonas,

Jonas Smedegaard a écrit :
> Quoting Georges Khaznadar (2022-11-04 19:49:04)
> > *all* sources are contained in the upstream package, copyright owners
> > and license details are in the file debian/copyright.
> 
> Please don't stuff sources from multiple upstream sources together - see
> Debian Policy § 4.13.

May I compare the intented package furo with other packages? If we look
at /usr/share/doc/abiword/copyright, there are more than one author and
more than one free software license in the list. 

Regarding furo, the source which does not come from the main developer
is gumshoe-patched.js, authored by Chris Ferdinandi three years ago,
under MIT license. cfernandi's original work is at 
https://github.com/cferdinandi/gumshoe/blob/master/src/js/gumshoe/gumshoe.js
and Pradyun Gedam (furo's author) is maintaining a modified version of
the script, quoting the original autor.

I have been applying Debian Policy § 4.13 quite a few times, most of
them about embedded copies of Javascript libraries like jquery,
jquery-ui, bootstrap, and so on, which are often embedded by developers
publishing their code. In such a case, the Policy states that "the
Debian packaging should ensure that binary packages reference the
libraries already in Debian", which I do.

As far as `apt-file` can tell me, there is currently no debian package
referring to gumshoe.js; if I apply the Policy in a stric fashion, then
"If the included code is not already in Debian, it should be packaged
separately as a prerequisite if possible.", and as a footnote in the
policy I can read "Having multiple copies of the same code in Debian is
inefficient, often creates either static linking or shared library
conflicts, and, most importantly, increases the difficulty of handling
security vulnerabilities in the duplicated code."

However, as there is no debian package currently using gumshoe.js,
packaging it separately would not reduce any redundancy. On the other
hand, which version of the script should be packaged? cferdinandi's
version? As my goal is to package furo, which is used by the last
version od sympy, which I am maintaining, sould I rather package 
separately gumshoe-patched.js, which was modified by Pradyun Gedam?

I am feeling that this point in our discussion is much about the level
of granularity of debian packaging: the smallest the grains, the more
flexibility for reusing them in combination with others. However
packages reused by a single other package are not beneficial.

> > However this black box took human-readable source files (SASS source
> > files and JS scripts) and created human-readable target files (CSS files
> > and JS scripts).
> 
> Whether generated code is human-readable or not is irrelevant for the
> policy that all source must be in Debian.  Instead it is a must that all
> sources and also all tooling to generate is in Debian.

I agree with you. This is ensured by the way Debian packages are
rebuilt: they are inside a clean environment, and no access to
Internet, with the exception of Debian package repositories.

I did not package furo differently. So, the point is to decide whether
the two files in debian/patches can be allowed: furo.dist-info.patch
(19K), and furo.patch (213K), which were manually derived from the
source (using pip for the first one, and webpack tainted by non-debian
plugins for the second one), then thoroughly reviewed to detect
irregularities.

On the other hand, reading your previous e-mails in this thread, I
discovered that you packaged rsass a few months ago, many thanks for
that work! Maybe rsass would provide the right solution to furo's
packaging difficulties, as compiling the sass source files is the
trickiest point?

Unfortunately, when I gave try, the result was disappointing:
--8<---
$ rsass furo.sass
Error: "furo.sass" is not a css or sass file.
--8<---
$ cat furo.sass
@import "~normalize.css"

@import "variables"
@import "base"
@import "scaffold"
@import "content"
@import "components"

@import "shame"
--8<---

As rsass' man page tells it, I had a look at https://sass-lang.com/,
particularly https://sass-lang.com/documentation/at-rules/import to know
whether "@import" should be supported or not. That page announces @import's
usage would be discontinued, if favor of @use. However, even when every
@import are replaced by @use, rsass complains that the file furo.sass is
"not a css or sass file".

Then I had a try with ruby's sass command. It could compile source sass
files, with a small patch applied (replacing a few ":" by "\:" and
erasing a few comments). The only caveat was that 
`@import "~normalize.css"`  could not be interpreted. However this latter
import can be made with a short sed script.

I read also in your previous e-mails that you would like sass files to
be distributed under /usr/share/sass, so other people can reuse them.

Given the current instabilities of rsass ans 

Bug#1023488: aspcud FTCBFS: needs a native build pass for lemon

[Helmut Grohne]

Source: aspcud
Version: 1:1.9.6-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

aspcud fails to cross build from source, because it needs a native build
pass for lemon. Even though I was tempted to just use the lemon binary
package here, that does not work, because these lemon forks are too
different. Thus, it really needs to build aspcud's lemon. I'm attaching
a patch for your convenience.

Helmut
diff --minimal -Nru aspcud-1.9.6/debian/changelog aspcud-1.9.6/debian/changelog
--- aspcud-1.9.6/debian/changelog   2022-09-05 20:28:46.0 +0200
+++ aspcud-1.9.6/debian/changelog   2022-11-04 11:00:13.0 +0100
@@ -1,3 +1,10 @@
+aspcud (1:1.9.6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Add a native build pass for lemon. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 04 Nov 2022 11:00:13 +0100
+
 aspcud (1:1.9.6-1) unstable; urgency=medium
 
   * New upstream release (closes: #1017131,#1000852).
diff --minimal -Nru aspcud-1.9.6/debian/clean aspcud-1.9.6/debian/clean
--- aspcud-1.9.6/debian/clean   1970-01-01 01:00:00.0 +0100
+++ aspcud-1.9.6/debian/clean   2022-11-04 10:58:54.0 +0100
@@ -0,0 +1,2 @@
+debian/lemon
+debian/lemon.cmake
diff --minimal -Nru aspcud-1.9.6/debian/rules aspcud-1.9.6/debian/rules
--- aspcud-1.9.6/debian/rules   2022-09-05 20:28:46.0 +0200
+++ aspcud-1.9.6/debian/rules   2022-11-04 11:00:13.0 +0100
@@ -1,7 +1,17 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+include /usr/share/dpkg/buildtools.mk
+
 %:
dh $@
 
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+override_dh_auto_configure:
+   $(CC_FOR_BUILD) -o debian/lemon lemon/lemon.c
+   printf 'add_executable(lemon IMPORTED GLOBAL)\nset_property(TARGET 
lemon PROPERTY IMPORTED_LOCATION "$(CURDIR)/debian/lemon")\n' > 
debian/lemon.cmake
+   dh_auto_configure -- -DIMPORT_LEMON=$(CURDIR)/debian/lemon.cmake
+endif
+
 override_dh_auto_clean:
-rm -rf build/release/*

Bug#1023486: Please add loong64 support to dpkg

[Helmut Grohne]

On Sat, Nov 05, 2022 at 06:08:03PM +0800, 张丹丹 wrote:
> - Add support for loongarch64 CPU.

Thank you for filing this much better bug. It is now properly formatted,
has good metadata and a useful usertag. Please be consistent in
continuing to use this usertag for further related bugs on any Debian
package.

Reviewed-by: Helmut Grohne 

Please do merge it with the other two bugs you created earlier though.

Please be patient about this. However simple this patch may look, it
usually takes significant time to make it appear in dpkg.

Guillem, please try merging it before the bookworm release. I think this
can go in after the toolchain freeze still.

Helmut

Bug#1023490: libio-aio-perl FTCBFS: does not pass --host to configure

[Helmut Grohne]

Source: libio-aio-perl
Version: 4.79-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libio-aio-perl fails to cross build from source, because Makefile.PL
invokes configure without passing --host. Given that the relevant
invocation is upstream, any solution affects upstream. As such, I
propose deriving the host argument from the compiler (which is correctly
detected by Makefile.PL). What do you think? I'm attaching a patch for
your convenience.

Helmut
--- libio-aio-perl-4.79.orig/Makefile.PL
+++ libio-aio-perl-4.79/Makefile.PL
@@ -63,8 +63,10 @@
   $ENV{LDFLAGS}  = "$Config{ldflags} $Config{ccdlflags}";
   $ENV{LINKER}   = $Config{ld}; # nonstandard
   $ENV{LIBS} = "-L$Config{archlibexp}/CORE -L$Config{privlibexp} -lperl $Config{perllibs}";
+  my $hostflag = "";
+  $hostflag = "--host=$1" if ($Config{cc} =~ m/(.+-.+-.+)-g?cc/);
 
-  system $ENV{SHELL}, -c => "./configure --prefix \Q$Config{prefixexp}\E"
+  system $ENV{SHELL}, -c => "./configure --prefix \Q$Config{prefixexp}\E $hostflag"
  and exit $? >> 8;
}
 }

Bug#1023489: glibmm2.4 FTCBFS: libxml-parser-perl cross unsatisfiable

[Helmut Grohne]

Source: glibmm2.4
Version: 2.66.5-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

glibmm2.4 can no longer be cross built from source as it started
depending on libxml-parser-perl, which happens to be cross
unsatisfiable as it would cross grade perl. It actually wants the build
architecture instance, but we cannot mark libxml-parser-perl Multi-Arch:
foreign. Thus the dependency should be annotated :native. I'm attaching
a patch for your convenience.

Helmut
diff --minimal -Nru glibmm2.4-2.66.5/debian/changelog 
glibmm2.4-2.66.5/debian/changelog
--- glibmm2.4-2.66.5/debian/changelog   2022-09-19 15:29:06.0 +0200
+++ glibmm2.4-2.66.5/debian/changelog   2022-11-04 08:57:24.0 +0100
@@ -1,3 +1,10 @@
+glibmm2.4 (2.66.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate libxml-parser-perl dependency :native. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 04 Nov 2022 08:57:24 +0100
+
 glibmm2.4 (2.66.5-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru glibmm2.4-2.66.5/debian/control 
glibmm2.4-2.66.5/debian/control
--- glibmm2.4-2.66.5/debian/control 2022-09-19 15:29:06.0 +0200
+++ glibmm2.4-2.66.5/debian/control 2022-11-04 08:57:23.0 +0100
@@ -15,7 +15,7 @@
xsltproc,
libglib2.0-dev (>= 2.61.2),
libsigc++-2.0-dev (>= 2.9.1),
-   libxml-parser-perl ,
+   libxml-parser-perl:native ,
meson (>= 0.54.0),
pkg-config,
mm-common (>= 0.9.10)

Bug#1023487: libsgml-parser-opensp-perl FTCBFS: hard codes the build architecture C++ compiler

[Helmut Grohne]

Source: libsgml-parser-opensp-perl
Version: 0.994-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libsgml-parser-opensp-perl fails to cross build from source, because the
Makefile.PL hard codes the build architecture C++ compiler. I'm
attaching a patch for your convenience to make it use the host one and
thus make libsgml-parser-opensp-perl cross buildable.

Helmut
diff --minimal -Nru libsgml-parser-opensp-perl-0.994/debian/changelog 
libsgml-parser-opensp-perl-0.994/debian/changelog
--- libsgml-parser-opensp-perl-0.994/debian/changelog   2022-06-18 
23:48:03.0 +0200
+++ libsgml-parser-opensp-perl-0.994/debian/changelog   2022-11-04 
11:18:05.0 +0100
@@ -1,3 +1,10 @@
+libsgml-parser-opensp-perl (0.994-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use a triplet-prefixed compiler. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 04 Nov 2022 11:18:05 +0100
+
 libsgml-parser-opensp-perl (0.994-5) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru libsgml-parser-opensp-perl-0.994/debian/patches/cross.patch 
libsgml-parser-opensp-perl-0.994/debian/patches/cross.patch
--- libsgml-parser-opensp-perl-0.994/debian/patches/cross.patch 1970-01-01 
01:00:00.0 +0100
+++ libsgml-parser-opensp-perl-0.994/debian/patches/cross.patch 2022-11-04 
11:17:43.0 +0100
@@ -0,0 +1,13 @@
+--- libsgml-parser-opensp-perl-0.994.orig/Makefile.PL
 libsgml-parser-opensp-perl-0.994/Makefile.PL
+@@ -13,8 +13,8 @@
+ else
+ {
+ # assume some compatible Linux
+-$options{LD}   = "g++";
+-$options{CC}   = "g++";
++$options{CC}   = $ENV{CXX} || "g++";
++$options{LD}   = $options{CC};
+ $options{LIBS} = "-lstdc++ -losp";
+ }
+ 
diff --minimal -Nru libsgml-parser-opensp-perl-0.994/debian/patches/series 
libsgml-parser-opensp-perl-0.994/debian/patches/series
--- libsgml-parser-opensp-perl-0.994/debian/patches/series  2022-06-18 
23:48:03.0 +0200
+++ libsgml-parser-opensp-perl-0.994/debian/patches/series  2022-11-04 
11:16:30.0 +0100
@@ -1,2 +1,3 @@
 doc_misspelling.patch
 binnmu_rebuild_fix.patch
+cross.patch
diff --minimal -Nru libsgml-parser-opensp-perl-0.994/debian/rules 
libsgml-parser-opensp-perl-0.994/debian/rules
--- libsgml-parser-opensp-perl-0.994/debian/rules   2022-06-18 
23:48:03.0 +0200
+++ libsgml-parser-opensp-perl-0.994/debian/rules   2022-11-04 
11:18:02.0 +0100
@@ -1,5 +1,8 @@
 #!/usr/bin/make -f
 
+DPKG_EXPORT_BUILDTOOLS=1
+include /usr/share/dpkg/buildtools.mk
+
 PACKAGE = $(shell dh_listpackages)
 TMP = $(CURDIR)/debian/$(PACKAGE)
 

Bug#1023119: RFS: cruft-ng/0.9.47 with new dh-cruft binary package -- tool that help identify system files)

[Alexandre Detiste]

It's there:

https://mentors.debian.net/package/cruft-ng/

Bug#1023486: Please add loong64 support to dpkg

[张丹丹]

Package: dpkg
Version: 1.21.10
Severity: wishlist
Tags: patch
User: debian-de...@lists.debian.org
Usertags: loongarch64


According to the result of disscussion from 
debian-d...@lists.debian.org(https://lists.debian.org/debian-dpkg/2022/11/msg1.html),
 guil...@debian.org, hel...@subdivi.de, *@loongson.cn and so on.
Dpkg architecture of loong64 just determine the name of the software packages.
Should add loong64 architecture to dpkg package?

- Add support for loongarch64 CPU.
Here is a simple patch to dpkg for the loongarch64.
Please download from attachment.

- Have an official GNU triplet in the GNU config project. 
https://git.savannah.gnu.org/cgit/config.git/commit/?id=c8ddc8472f8efcadafc1ef53ca1d863415fddd5f

- GNU binutils, gcc, and the respective libc project have merged by upstream.
Binutils: 
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=binutils/NEWS;hb=refs/heads/binutils-2_39-branch
Gcc: https://gcc.gnu.org/gcc-12/changes.html
Glibc: https://sourceware.org/pipermail/libc-alpha/2022-August/141193.html


- Please tell me if I've missed something.

Dandan Zhang


dpkg-1.21.10-loongarch64-support.patch
Description: Binary data

Bug#1023485: Shipped blkid is incompatible with the one in util-linux, break cryptsetup

[Vincent Bernat]

Package: busybox-static
Version: 1:1.35.0-3
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

blkid was added as an applet in busybox. This makes it available in initramfs in
place of the one from util-linux. This prevents cryptsetup to works as the
syntax used is not recognized by busybox.

 10:58 ❱ blkid -l -t UUID=255e21df-9261-47b5-ac37-b4ae4c435a37 -o device
/dev/nvme0n1p3
 10:59 ❱ busybox blkid -l -t UUID=255e21df-9261-47b5-ac37-b4ae4c435a37 -o device
 10:59 ❱ sudo busybox blkid -l -t UUID=255e21df-9261-47b5-ac37-b4ae4c435a37 -o 
device

cryptsetup-initramfs could parse the output of busybox blkid, but this seems
more fragile. It seems easiest to not ship blkid in busybox (hence the bug
against busybox).

- -- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), 
(101, 'experimental-debug'), (101, 'experimental')
Architecture: amd64 (x86_64)

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmNmNPMSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5xT0QAKDHldn2kpQ+q5++vOpu05hYLsz9VkWp
ud2ZH+gNXc85qDHvTN+kKu+h1nMbK8Qk/x6o/orRzvRBAwmJ6XE06tBBulOahoKi
q8dxYorvXQJV3bI7ua1JYsYKTybguE/omN27IguopQdzE1Bac5fkfcKwni5QHEdi
oOda3FNVAdQiZ7mh77nBaD9NtqG4lzMb4rbxwQ5ZGG2BOypVQ7CHnoyPt813PjSI
eh76R5cW9/KgyqbWo4mGVGtZ8DqmVY+BLuVKH0+g+zreieRlbTLhJakwYCUJ4SNS
6ye9M58xtgviBbDUBl4ae7LV9ARSa9RpG6wkLgVw36CrD/QAwAoSsjJwcPRg2xGH
P7O8nyT+tyP3xFmNGAHfJpLO/CPh8B3rNJABSO6F8hGzoh2Ej8zFfmEZ3CfchnmR
SatUtS5yBlvU3wvkdK0VMDpXOdqqJjDkexjm28vriBvyAUi07OBsbqtEILGgJXb6
bOXv6hGWg5F/qA+OgjWdu6YJUbBrZVH7gvePbr5lmwwGItDc0UIrAZxZ5/1FIi5G
G9+NTS+kpFFT0uvD8F6HaqZrPGTSDJM5DSoHxZLkYSYJjZzbrC2Fk9w3AaE7/6u/
05EVetREI89NvCt7GJbvS0jCWIlk3JVMAfbDvoNm6vqqTGJPEMjW81ABkJk6QKpF
3UcOjdL4nGqS
=KLT1
-END PGP SIGNATURE-

Bug#1023484: libsystemd0: upgrade from 251.6-1 to 252-2 fails with timed out (service_start_timeout=25000ms)

[Martin-Éric Racine]

Package: libsystemd0
Version: 252-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Setting up libsystemd0:i386 (252-2) ...
Setting up libsystemd-shared:i386 (252-2) ...
Setting up systemd (252-2) ...
Installing new version of config file /etc/systemd/logind.conf ...
Installing new version of config file /etc/systemd/system.conf ...
Installing new version of config file /etc/systemd/user.conf ...

Message from syslogd@[localhost] at Nov  5 11:09:11 ...
 systemd[1]: Caught  from our own process.

Message from syslogd@[localhost] at Nov  5 11:09:11 ...

Message from syslogd@[localhost] at Nov  5 11:09:11 ...
 systemd[1]: Caught  from our own process.
 systemd[1]: Caught  from our own process.

Message from syslogd@[localhost] at Nov  5 11:09:11 ...
 systemd[1]: Caught  from our own process.

Broadcast message from systemd-journald@geode (Sat 2022-11-05 11:09:11 EET):

systemd[1]: Caught  from our own process.


Broadcast message from systemd-journald@geode (Sat 2022-11-05 11:09:11 EET):

systemd[1]: Caught  from our own process.


Message from syslogd@[localhost] at Nov  5 11:09:16 ...
 systemd[1]: Caught , dumped core as pid 2154.

Broadcast message from systemd-journald@geode (Sat 2022-11-05 11:09:16 EET):

systemd[1]: Caught , dumped core as pid 2154.


Message from syslogd@[localhost] at Nov  5 11:09:16 ...
 systemd[1]: Caught , dumped core as pid 2154.

Message from syslogd@[localhost] at Nov  5 11:09:16 ...
 systemd[1]: Caught , dumped core as pid 2154.

Broadcast message from systemd-journald@geode (Sat 2022-11-05 11:09:16 EET):

systemd[1]: Caught , dumped core as pid 2154.


Message from syslogd@[localhost] at Nov  5 11:09:16 ...
 systemd[1]: Caught , dumped core as pid 2154.

Message from syslogd@[localhost] at Nov  5 11:09:17 ...
 systemd[1]: Freezing execution.

Message from syslogd@[localhost] at Nov  5 11:09:17 ...
 systemd[1]: Freezing execution.

Broadcast message from systemd-journald@geode (Sat 2022-11-05 11:09:17 EET):

systemd[1]: Freezing execution.


Message from syslogd@[localhost] at Nov  5 11:09:17 ...
 systemd[1]: Freezing execution.

Message from syslogd@[localhost] at Nov  5 11:09:17 ...
 systemd[1]: Freezing execution.

Broadcast message from systemd-journald@geode (Sat 2022-11-05 11:09:17 EET):

systemd[1]: Freezing execution.

(Reading database ... 58347 files and directories currently installed.)
Preparing to unpack .../systemd-sysv_252-2_i386.deb ...
Unpacking systemd-sysv (252-2) over (251.6-1) ...


- -- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'testing')
Architecture: i386 (i586)

Kernel: Linux 6.0.0-2-686 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libsystemd0 depends on:
ii  libc62.35-4
ii  libcap2  1:2.44-1
ii  libgcrypt20  1.10.1-2
ii  liblz4-1 1.9.4-1
ii  liblzma5 5.2.7-0.1
ii  libzstd1 1.5.2+dfsg-1

libsystemd0 recommends no packages.

libsystemd0 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmNmLBkACgkQrh+Cd8S0
17bXPQ//ctq5bH4LrVB+gs4vDfzWWi3RKXYlXtr28U4IxDB/ka2ucCc6sJ1ZddQM
mTv+dKWagqHKHurhWQ3Q47PJ5ZGrYfOyh4aUs2Mf/VyqOWYgAeuDkzvjoSKicxkK
xahdGvM8/Ao8gFGo+8qXBEF7am0yQAKa8z6opJTV02BreFWYqijS6fvNgw1tkmRY
CSThEibFLffgrHK9FmFL0yIvsm7YzRjSX8yQZCehLKTckxQClm4YS90nvPcgp73r
jzIrahjdaARq7xy6NhdsYLoLDlKmaax4xy+maPoIlukDgEcx5Ni1RLay+TmRh6GS
QUXFuVFbObKsfcD2yV1OvcBYIlyyZQBQKh10KsSQq+Ugtn777CDzADKTep1uwdw2
ewmLv0a4dgnRR6b7RH/UwRDTk/mn0cUBrB259REDOYW8q5ypbQLIipa9WvejKnH9
XCxbEt+qpMb7qLLBjn7Mv1v6sy599PRVsf/y90676kxQv/p74SLge2wiDDcAL0Z4
HTNqyaWCrxhDUSfkPZz8A9Hme9XYNMb6b8F6cVtPs5RfyLY1fL4T6fjjKBivRLps
PqopW8p8E/l2alzZiLXUcCCmXFGalI2YUVGYsvSmpJiC6/Up4UgylUOXpRFIinpu
k4h+hFjlovY0mWc2iqY/E0kJl1kRbI9m3ucnq43kNmQWYC9uTCc=
=T89C
-END PGP SIGNATURE-

Bug#1023483: systemd upgrade to 252-2 breaks suspend, suspend-then-hibernate

[Sonke]

Package: systemd
Version: 252-2
Severity: normal
X-Debbugs-Cc: s.hu...@gmx.net

Dear Maintainer,

recently, the following systemd-related packages where updated on my two
laptops:
ibnss-systemd
libpam-systemd
libsystemd0
libsystemd0
libsystemd-shared
libudev1
libudev1
systemd
systemd-sysv
systemd-timesyncd
udev

Since the update, I have the following issues with suspend and
suspend-then-hibernate:

Suspend (seemingly random):
When the laptop is put into s2idle (e.g. after idling a while or by
closing the lid), sometimes (not easily reproducible) the display stays
off and keyboard, touchpad and touchscreen are not repsonsive.
I can connect to the system by ssh, though.

Suspend-then-hibernate (reproducible every time):
When the laptop is put into s2idle and suspend-then-hibernate is
activated, no hibernation occurs even after multiples of HibernateDelaySec.
When the system is woken up before HibernateDelaySec has passed, it
usually wakes up normally but sometimes doesn't (see above).
When the system is woken up after HibernateDelaySec has passed, the
display always remains off and input devices are not responsive. Still,
ssh connection is possible then as well.

The system log shows the Lid close events as well as entering respective
suspend states and waking up again. No obvious errosr are reported in
connection with the wake up.

Downgrading the above-mentioned packages to version 251-6 solves this
issue.

The laptops in question are a Surface Go3 and a Thinkpad X1 Yoga
Titanium, running Debian testing/Sid mix with KDE Plasma on
wayland as desktop environment.

On the Thinkpad, the suspend issue was seen with both s2idle and s2ram,
as well as kernels 5.19.11-1, 6.0.5-1 and 6.0.6-2.

Please let me know if you need more information.

Regards,
Sönke

-- Package-specific info:

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

Kernel: Linux 6.0.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
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 depends on:
ii  libacl12.3.1-1
ii  libaudit1  1:3.0.7-1.1+b1
ii  libblkid1  2.38.1-1.1+b1
ii  libc6  2.35-4
ii  libcap21:2.44-1
ii  libcryptsetup122:2.5.0-6
ii  libfdisk1  2.38.1-1.1+b1
ii  libgcrypt201.10.1-2
ii  libkmod2   30+20220905-1
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.2.7-0.1
ii  libmount1  2.38.1-1.1+b1
ii  libseccomp22.5.4-1+b1
ii  libselinux13.4-1+b2
ii  libssl33.0.7-1
ii  libsystemd-shared  252-2
ii  libsystemd0252-2
ii  libzstd1   1.5.2+dfsg-1
ii  mount  2.38.1-1.1+b1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.4-1
ii  systemd-timesyncd [time-daemon]  252-2

Versions of packages systemd suggests:
ii  libfido2-11.12.0-1
ii  libtss2-esys-3.0.2-0  3.2.0-1+b1
ii  libtss2-mu0   3.2.0-1+b1
pn  libtss2-rc0   
ii  policykit-1   122-1
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.4-1
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 252-2
ii  libpam-systemd 252-2
ii  udev   252-2

-- Configuration Files:
/etc/systemd/sleep.conf changed:
[Sleep]
HibernateDelaySec=120min


-- no debconf information