Bug#1053911: cron: Option to disable X-Cron-Env header in emails

[Jay]

Package: cron
Version: 3.0pl1-162
Severity: wishlist

Dear Maintainer,

   * What led up to the situation?

I checked the headers in emails sent by cron

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I searched the internet, manual, and source code for an option to disable the 
X-Cron-Env email header.

   * What was the outcome of this action?

No outcome.  I could not disable the X-Cron-Env email header without modifying 
the source code.

   * What outcome did you expect instead?

I expected an option to disable the X-Cron-Env email header.

-- Package-specific info:
--- EDITOR:
not set

--- /usr/bin/editor:
/usr/bin/nano

--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 43648 Mar  2  2023 /usr/bin/crontab

--- /var/spool/cron:
drwxr-xr-x 5 root root 4096 Oct 27  2019 /var/spool/cron

--- /var/spool/cron/crontabs:
drwx-wx--T 2 root crontab 4096 Oct 12 09:42 /var/spool/cron/crontabs

--- /etc/cron.d:
drwxr-xr-x 2 root root 4096 Jun 29 23:57 /etc/cron.d

--- /etc/cron.daily:
drwxr-xr-x 2 root root 4096 Oct  5 06:44 /etc/cron.daily

--- /etc/cron.hourly:
drwxr-xr-x 2 root root 4096 Jun 22 12:49 /etc/cron.hourly

--- /etc/cron.monthly:
drwxr-xr-x 2 root root 4096 Jun 22 12:49 /etc/cron.monthly

--- /etc/cron.weekly:
drwxr-xr-x 2 root root 4096 Oct 12 09:17 /etc/cron.weekly


-- System Information:
Debian Release: 12.2
  APT prefers stable-security
  APT policy: (900, 'stable-security'), (900, 'stable'), (800, 'testing'), 
(800, 'oldstable'), (775, 'oldoldstable'), (700, 'unstable'), (600, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages cron depends on:
ii  cron-daemon-common   3.0pl1-162
ii  init-system-helpers  1.65.2
ii  libc62.36-9+deb12u3
ii  libpam-runtime   1.5.2-6+deb12u1
ii  libpam0g 1.5.2-6+deb12u1
ii  libselinux1  3.4-1+b6
ii  sensible-utils   0.0.17+nmu1

Versions of packages cron recommends:
ii  nullmailer [mail-transport-agent]  1:2.2-4

Versions of packages cron suggests:
ii  anacron2.3-36
pn  checksecurity  
ii  logrotate  3.21.0-1

Versions of packages cron is related to:
pn  libnss-ldap   
pn  libnss-ldapd  
pn  libpam-ldap   
pn  libpam-mount  
pn  nis   
ii  nscd  2.36-9+deb12u3

-- no debconf information

Bug#1032793: Grsync not asking for password

[Padmanabhan R]

Hi,

I just want to ask if there is any chance that this issue will be fixed.
Like Mark Rognss suggested, the password can be entered in the terminal if
grsync is started from the terminal (thanks for that tip!). But it will be
great if the GUI-launched version is also fixed.

This bug has been around for more than six months, I guess.

My system info:
Linux kestrel 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-2
(2023-07-27) x86_64 GNU/Linux,  Debian 12.2

Thanks
Padman

Bug#1053910: zfs: use zpool user properties instead of zfs user properties for scrub and trim cron scripts

[M. Zhou]

Source: zfs-linux
Version: 2.2.0-1~exp1
Severity: normal

zpool user property is supported now. We can use this feature for the
cron scripts instead of abusing the zfs user property at root dataset.
https://github.com/openzfs/zfs/pull/11680

Bug#1053761: bullseye-pu: package llvm-toolchain-16/16.0.6-15~deb11u1

[Andres Salomon]

On Fri, Oct 13 2023 at 11:32:57 AM -04:00:00, Andres Salomon 
 wrote:



On Fri, Oct 13 2023 at 02:59:08 PM +01:00:00, Adam D. Barratt 
 wrote:

On Wed, 2023-10-11 at 06:37 +0100, Adam D. Barratt wrote:

 Control: tags -1 + confirmed

 On Tue, 2023-10-10 at 12:21 -0400, Andres Salomon wrote:
 > Chromium newest version FTBFS on bullseye with clang-13, but 
works

 > fine with clang-16.
 >


[...]

 Please go ahead.



Unfortunately the package isn't getting built anywhere, because it
Build-Depends on llvm-spirv-16, which also isn't in bullseye.

How did you manage to build the amd64 upload for NEW?



I don't have llvm-spirv-16 installed in the container where I built 
it, but I do have the 'hello' package installed. It looks like that's 
not going to work for i386 though, so shall I also build/upload 
llvm-spirv-16? Alternatively, it looks like an unreleased version of 
clang-16 (1:16.0.6-16) has changed the build-dep to allow for 
llvm-spirv-14 or llvm-spirv-15 
(https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/9af30d9926b6e93580262310fa652d19fcc15869). 
I could try changing the build-dep to the clang-11 and clang-13 
equivalent of 'llvm-spirv' and uploading llvm-toolchain-16 
1:16.0.6-15~deb11u2.






I built deb11u2 with the following changes from 16.0.6-15. Chromium 
successfully builds against it. Let me know if you want me to file a 
separate release.d.o bug for it, or just upload it, or what.




diff -urN a/llvm-toolchain-16-16.0.6/debian/changelog 
b/llvm-toolchain-16-16.0.6/debian/changelog
--- a/llvm-toolchain-16-16.0.6/debian/changelog 2023-09-11 
13:40:42.0 +
+++ b/llvm-toolchain-16-16.0.6/debian/changelog 2023-10-13 
16:25:00.0 +

@@ -1,3 +1,16 @@
+llvm-toolchain-16 (1:16.0.6-15~deb11u2) bullseye; urgency=medium
+
+  * Build-dep on llvm-spirv instead of llvm-spirv-16 to make sbuild 
happy.

+
+ -- Andres Salomon   Fri, 13 Oct 2023 16:25:00 
+

+
+llvm-toolchain-16 (1:16.0.6-15~deb11u1) bullseye; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for bullseye.
+
+ -- Andres Salomon   Tue, 10 Oct 2023 05:55:47 
+

+
llvm-toolchain-16 (1:16.0.6-15) unstable; urgency=medium

  * Second attempt to refresh D158066.patch (Closes: #1049362)
diff -urN a/llvm-toolchain-16-16.0.6/debian/control 
b/llvm-toolchain-16-16.0.6/debian/control
--- a/llvm-toolchain-16-16.0.6/debian/control   2023-09-10 
06:14:34.0 +
+++ b/llvm-toolchain-16-16.0.6/debian/control   2023-10-13 
16:24:09.0 +

@@ -23,7 +23,7 @@
libctypes-ocaml-dev [amd64 arm64 armhf ppc64el riscv64 s390x],
dh-exec, dh-ocaml [amd64 arm64 armhf ppc64el riscv64 s390x],
libpfm4-dev [linux-any], python3-setuptools, libz3-dev,
-llvm-spirv-16 [ amd64 arm64 armel armhf i386 mips64el ppc64el 
riscv64 s390x ]  | hello [!i386],
+llvm-spirv [ amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 
s390x ]  | hello [!i386],

spirv-tools [ linux-any ] | hello [ !i386],
wasi-libc | hello [ !any-i386],
libcurl4-openssl-dev | libcurl-dev,

Bug#1053909: anbox: Failed to start as either binder or ashmem kernel drivers are not loaded

[Alex Relis]

Additional info: after running modinfo binder_linux and modinfo 
ashmem_linux, it looks like I have binder but don't have ashmem.


Further research also tells me that Anbox's development is inactive, so 
I might just give up on this. Just thought I'd let you know about the 
status of this package.

--
Have a good night
Alex


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053909: anbox: Failed to start as either binder or ashmem kernel drivers are not loaded

[Alex Relis]

Package: anbox
Version: 0.0~git20210106-1
Severity: important

Dear Maintainer,

I'm looking to use Anbox to run some Android apps. Unfortunately, opening 
Anbox's application launcher results in a splash screen that says "Starting..." 
but then closes.
Running `anbox session-manager` returns the following error message:
[ 2023-10-14 03:35:16] [session_manager.cpp:146@operator()] Failed to start as 
either binder or ashmem kernel drivers are not loaded

So from the looks of it, it seems that Anbox's required kernel modules, ashmem 
and binder, are not included with this package at all. This would render Anbox 
unusuable on Debian.

Please package the required Anbox kernel modules so that Anbox can run without 
crashing.

Thanks,
Alex

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

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

Versions of packages anbox depends on:
ii  init-system-helpers 1.65.2
ii  iptables1.8.9-2
ii  libboost-filesystem1.74.0   1.74.0+ds1-21
ii  libboost-iostreams1.74.01.74.0+ds1-21
ii  libboost-log1.74.0  1.74.0+ds1-21
ii  libboost-program-options1.74.0  1.74.0+ds1-21
ii  libboost-thread1.74.0   1.74.0+ds1-21
ii  libc6   2.36-9+deb12u3
ii  libegl1 1.6.0-1
ii  libgcc-s1   12.2.0-14
ii  libgles21.6.0-1
ii  liblxc1 1:5.0.2-1+deb12u1
ii  libprotobuf-lite23  3.12.4-1
ii  libsdbus-c++0   0.8.3-4
ii  libsdl2-2.0-0   2.26.5+dfsg-1
ii  libsdl2-image-2.0-0 2.6.3+dfsg-1
ii  libstdc++6  12.2.0-14
ii  libsystemd0 252.17-1~deb12u1
ii  lxc 1:5.0.2-1+deb12u1

Versions of packages anbox recommends:
ii  dbus-user-session  1.14.10-1~deb12u1

anbox suggests no packages.

-- no debconf information

Bug#1053899: "Get books" not working: TypeError: ResultsView.__init__()

[yokota]

Hello Nicolas,

> In current version of Calibre in Bookworm, the "Get books" menu doesn't
> work, and give this error when accessing it:

Thank you, fix was pushed at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053908

--
YOKOTA Hiroshi

Bug#1053908: bookworm-pu: package calibre/6.13.0+repack-2+deb12u2

[YOKOTA Hiroshi]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: cali...@packages.debian.org, yokota.h...@gmail.com
Control: affects -1 + src:calibre


[ Reason ]
Fix Debian bug 1053899
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053899

[ Impact ]
"Get books" window not working

[ Tests ]
Build time test passed.
Trivial manual test passed.

[ Risks ]
Tests are done on Debian unstable, not Debian bookworm.

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

[ Changes ]
Add patch "fix crash in Get Books when regenerating UIC files".

[ Other info ]
Upstream fix:
https://github.com/kovidgoyal/calibre/commit/f4fe3f254d3de0dd51722b3b5e08112ae82ebf51

Bug#1053907: RFS: xca/2.5.0-1 -- x509 Certification Authority management tool based on QT

[Thomas Ward]

Package: sponsorship-requests
Severity: normal
Control: submitter -1 tew...@ubuntu.com


Dear mentors,

*Note: While I have DM status and can upload, there is a situation where 
my signing key privkey is irrecoverable, due to computer death and the 
destruction of my yubikey holding the privkey as well in a car accident. 
This is why this is being filed with a Sponsorship request until I can 
find 2 DDs willing to sign my replacement key.*



I am looking for a sponsor for my package "xca":

* Package name : xca
Version : 2.5.0-1
Upstream contact : Christian Hohnstaedt 
* URL : https://hohnstaedt.de/xca/
* License : BSD-3-clause
* Vcs : https://salsa.debian.org/debian/xca
Section : x11

The source builds the following binary packages:

xca - x509 Certification Authority management tool based on QT

To access further information about this package, please visit the 
following URL:


https://mentors.debian.net/package/xca/

Alternatively, you can download the package with 'dget' using this command:

dget -x https://mentors.debian.net/debian/pool/main/x/xca/xca_2.5.0-1.dsc

Changes since the last upload:

xca (2.5.0-1) unstable; urgency=medium
.
* New upstream release (2.5.0)
* Upstream now uses CMake for builds, which invalidates multiple quilt
patches.
* Dropped patches from d/patches:
- xca-240-ossl3.patch: Already included in 2.5.0
- 0001-Remove-misc-Info.plist-in-clean-target.patch: Obsolete due
to CMake move.
- 0002-pkg-config-remove-hardcoding.patch: Obsolete due to
CMake move.
* d/control: Update build dependencies because we use CMake; use XCA
upstream git home for build-dependencies list.
* d/rules: Numerous changes to adapt for CMake build environment
as changed by Upstream.

Regards,


Thomas

Bug#1002527: "milter-greylist -u user" considered harmful

[Amin Bandali]

X-Debbugs-CC: m...@renich.org, b...@debian.org, t...@zhadum.org.uk, 
t...@debian.org

Hello,

How do folks feel about the attached patch (against
https://salsa.debian.org/debian/milter-greylist)?  It implements
Matthias's proposal of allowing the use of a user (and/or group)
other than 'greylist' for systemd users as well.

I understand it may not be a 100% "solution" that everyone would be
happy with (e.g. postinst configure still sets 'greylist' as the owner
user and group for /var/lib/milter-greylist), but I think it's an
improvement over the current situation, as it makes milter-greylist
respect the corresponding setting in its configuration file, and also
adds an example of more suitable 'socket' and 'user' settings values
to the configuration file for use with a chrooted Postfix.

I'd appreciate any comments/feedback on this, but if there aren't any,
I'd ask Tobi to sponsor it to unstable for me.

Thanks,
-a

>From cbfdd5fb0dcc45639b313eea5cdf2f580be18f52 Mon Sep 17 00:00:00 2001
From: Amin Bandali 
Date: Fri, 13 Oct 2023 01:28:35 -0400
Subject: [PATCH] Set user greylist in greylist.conf instead of
 milter-greylist.service

---
 debian/changelog   | 12 
 debian/milter-greylist.service |  2 +-
 debian/patches/greylist.conf   | 19 ---
 3 files changed, 25 insertions(+), 8 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 3a05494..f36f77a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+milter-greylist (4.6.4-1.2) unstable; urgency=medium
+
+  * QA upload.
+  * Non-maintainer upload.
+  * Set user greylist in the configuration file rather than as a
+command-line option in the service file (which always takes
+precedence) to allow easier customization. (Closes: #1002527)
+- debian/milter-greylist.service
+- debian/patches/greylist.conf
+
+ -- Amin Bandali   Fri, 13 Oct 2023 18:43:39 -0400
+
 milter-greylist (4.6.4-1.1) unstable; urgency=medium
 
   * QA upload.
diff --git a/debian/milter-greylist.service b/debian/milter-greylist.service
index b5a6e80..bcef86f 100644
--- a/debian/milter-greylist.service
+++ b/debian/milter-greylist.service
@@ -5,7 +5,7 @@ Before=postfix.service
 
 [Service]
 Type=forking
-ExecStart=/usr/sbin/milter-greylist -u greylist
+ExecStart=/usr/sbin/milter-greylist
 Restart=on-failure
 PrivateTmp=true
 
diff --git a/debian/patches/greylist.conf b/debian/patches/greylist.conf
index 6e1d33d..216aae9 100644
--- a/debian/patches/greylist.conf
+++ b/debian/patches/greylist.conf
@@ -8,23 +8,28 @@ Index: milter-greylist-4.5.11/greylist.conf
 ===
 --- milter-greylist-4.5.11.orig/greylist.conf	2014-07-30 09:29:48.543484591 +0100
 +++ milter-greylist-4.5.11/greylist.conf	2014-07-30 09:29:48.539484522 +0100
-@@ -6,11 +6,17 @@
+@@ -6,11 +6,21 @@
  #
  
  pidfile "/var/run/milter-greylist.pid"
 -socket "/var/milter-greylist/milter-greylist.sock"
 -dumpfile "/var/milter-greylist/greylist.db" 600
++socket "/var/run/milter-greylist/milter-greylist.sock"
 +dumpfile "/var/lib/milter-greylist/greylist.db" 600
  dumpfreq 1
-+
-+# For sendmail use the following two lines
-+socket "/var/run/milter-greylist/milter-greylist.sock"
- user "smmsp"
+-user "smmsp"
++user "greylist"
  
-+# For Postfix uncomment the following two lines and comment out the
-+# sendmail ones above.
++# If using Postfix rather than Sendmail, uncomment the following
++# socket and user settings and comment out the socket and user above.
 +#socket "/var/run/milter-greylist/milter-greylist.sock" 660
 +#user "postfix"
++
++# If using a chrooted Postfix, you might want to use something like
++# the following instead (where "/var/spool/postfix" is the Postfix
++# chroot):
++#socket "/var/spool/postfix/milter-greylist/milter-greylist.sock" 660
++#user "greylist:postfix"
  
  # Log milter-greylist activity to a file
  #stat ">>/var/milter-greylist/greylist.log" \
-- 
2.39.2

Bug#1053906: ITP: bison-mode -- Emacs major mode for editing lex, yacc, and bison files

[Xiyue Deng]

Package: wnpp
Owner: Xiyue Deng 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-emac...@lists.debian.org

* Package name: bison-mode
  Version : 0.3
  Upstream Author : Eric Beuscher , Wilfred Hughes 

* URL or Web page : https://github.com/Wilfred/bison-mode
* License : GPL-2+
  Description : Emacs major mode for editing lex, yacc, and bison files

This package provides a GNU Emacs major mode for editing lex, yacc files, as
well as their extension formats like flex, bison, and jison.  It provides
flex-mode, bison-mode, and jison-mode to add syntax highlighting and electric
support when editing the corresponding types of files.

I intend to maintain this package within the Debian Emacsen team.

Bug#1053905: emacs-common-non-dfsg: not included among emacs 29 backported packages

[Brandon C. Irizarry]

Package: emacs-common-non-dfsg
Version: 1:28.2+1-2
Severity: wishlist
X-Debbugs-Cc: brandon.iriza...@gmail.com

Dear Maintainer,

I recently installed the Emacs 29 Bookworm backport; however, the
documentation is still at version 28. I tried to install
emacs-common-non-dfsg from backports, but no backport exists for it
yet. This message is a simple request for the backport to be made.

Thanks!

- Brandon

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

Kernel: Linux 6.1.31-antix.1-amd64-smp (SMP w/4 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 /usr/bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages emacs-common-non-dfsg depends on:
ii  dpkg  1.21.22
ii  install-info  6.8-6+b1

emacs-common-non-dfsg recommends no packages.

emacs-common-non-dfsg suggests no packages.

-- no debconf information

Bug#1053904: location-update can take very long to restart

[Aaron M. Ucko]

Package: location
Version: 0.9.16-2.1
Severity: normal

I've found that restarting location-update (as needrestart prompts me
to do after upgrading Python or a shared library it uses) can take
ages, to the point where I generally give up and kill the systemctl
process, letting the start job continue in the background.  Curiously,
the service starts fine on boot.

Could you please take a look?  Please let me know if I can provide any
further information that would be helpful.

Thanks!

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

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

Versions of packages location depends on:
ii  python3   3.11.4-5+b1
ii  python3-location  0.9.16-2.1

location recommends no packages.

location suggests no packages.

-- debconf-show failed

Bug#1053903: RM: eja -- RoQA; unmaintained; severely outdated

[Bastian Germann]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
Control: affects -1 + src:eja

Please remove eja. I have announced the removal in #1050596. The package seems 
to be unmaintained
(lacking behind upstream by several major versions) and upstream also seems to 
have ceased development.

Bug#1053902: imapfilter: unnecessarily build-depends on obsolete pcre3 library

[Bastian Germann]

I am going to upload a NMU to fix this.
The changes are pushed to Vcs-Git.

Bug#1053901: tech-ctte: Repeal merged-/usr file movement moratorium

[Christoph Berg]

Re: Sean Whitton
> Package: tech-ctte
> 
> I call for votes on the following resolution.
> Voting lasts for one week or until the outcome is no longer in doubt.
> 
> === BEGIN
> 
> OPTION A:
> 
> The Technical Committee formally repeals its moratorium recommending
> that maintainers of individual packages should not proactively move
> files from the root filesystem to corresponding locations under /usr in
> the data.tar.* of packages (see #1035831).
> 
> Under Constitution 6.1.5, the Technical Committee now recommends that
> maintainers consult with those driving the merged-/usr transition before
> moving files from the root filesystem to corresponding locations under
> /usr in the data.tar.* of packages.
> 
> The transition driver, which at the time of writing is Helmut Grohne, is
> using a phased approach, in which the moratorium is rolled back for only
> certain classes of packages, and changes, at a time.  In addition,
> restructuring uploads should be targeted at experimental, and left for
> three days.  This is in order that automated testing by dumat can occur.
> 
> We recommend following , as edited by
> the transition driver(s).  If there is any doubt as to whether a change
> you wish to make is appropriate, please seek explicit approval from the
> transition driver(s).
> 
> OPTION N:
> 
> None of the above.
> 
> === END

I vote A > N.

Christoph


signature.asc
Description: PGP signature

Bug#1053902: imapfilter: unnecessarily build-depends on obsolete pcre3 library

[Bastian Germann]

Source: imapfilter
Version: 1:2.8.1-1
Severity: serious
User: matthew-pcre...@debian.org
Usertags: obsolete-pcre3

(wording copied from MBF by Matthew Vernon)

Dear maintainer,

Your package still build-depends on the old, obsolete PCRE libraries
(i.e. libpcre3-dev). This has been end of life for a while now, and
upstream do not intend to fix any further bugs in it. Accordingly, I
would like to remove the pcre3 libraries from Debian.

The newer PCRE2 library was first released in 2015, and has been in
Debian since stretch. Upstream's documentation for PCRE2 is available
here: https://pcre.org/current/doc/html/

Many large projects that use PCRE have made the switch now (e.g. git,
php); it does involve some work, but we are now at the stage where
PCRE should not be used, particularly if it might ever be exposed to
untrusted input.

This mass bug filing was discussed on debian-devel@ in
https://lists.debian.org/debian-devel/2021/11/msg00176.html

Bug#1053901: tech-ctte: Repeal merged-/usr file movement moratorium

[Sean Whitton]

Hello,

On Fri 13 Oct 2023 at 09:59pm +01, Sean Whitton wrote:

> === BEGIN
>
> OPTION A:
>
> The Technical Committee formally repeals its moratorium recommending
> that maintainers of individual packages should not proactively move
> files from the root filesystem to corresponding locations under /usr in
> the data.tar.* of packages (see #1035831).
>
> Under Constitution 6.1.5, the Technical Committee now recommends that
> maintainers consult with those driving the merged-/usr transition before
> moving files from the root filesystem to corresponding locations under
> /usr in the data.tar.* of packages.
>
> The transition driver, which at the time of writing is Helmut Grohne, is
> using a phased approach, in which the moratorium is rolled back for only
> certain classes of packages, and changes, at a time.  In addition,
> restructuring uploads should be targeted at experimental, and left for
> three days.  This is in order that automated testing by dumat can occur.
>
> We recommend following , as edited by
> the transition driver(s).  If there is any doubt as to whether a change
> you wish to make is appropriate, please seek explicit approval from the
> transition driver(s).
>
> OPTION N:
>
> None of the above.
>
> === END

I vote

A > N

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1051650: cmake: Problems finding libraries on Alpha

[Adrian Bunk]

On Fri, Sep 15, 2023 at 08:57:15PM +0200, Timo Röhling wrote:
> Hi Adrian,

Hi Timo,

thanks for taking a look (and sorry for the late reply).

> On Mon, 11 Sep 2023 01:20:53 +0300 Adrian Bunk  wrote:
> > 1. The problem is about not finding a library,
> > it happens in many packages with many libraries.
> > 
> > 2. The problem happens only on alpha.
> > 
> > 3. There is no such problem with non-cmake build systems.
> > 
> > 4. The problem started after the release of bookworm.
> > It might be a regression in cmake 3.26 or somewhere else (glibc?).
> Do you think the bug is reproducible with a small shell script
> such as:
> 
> set -e
> while sleep 5
> do
> mkdir /tmp/_build
>   cmake -B /tmp/_build -S /path/to/project/with/required/find_library
>   rm -rf /tmp/_build
> done

Yes, I would suspect this should reproduce this bug with a package like 
the mentioned fcitx5-skk.

I'm adding the debian-alpha list to Cc since I don't have access to 
Alpha hardware and I cannot reproduce the problem locally with qemu
since my local qemu setup is apparently in some relevant way different
from the qemu buildds where the problem does happen.

> If yes, we could try this with a rebuilt CMake 3.25 and see if
> this is truly a CMake regression. I looked at the code and could not
> spot anything suspicious yet, so this would certainly be
> instructive.
> 
> Cheers
> Timo

Thanks
Adrian

Bug#1053901: tech-ctte: Repeal merged-/usr file movement moratorium

[Sean Whitton]

Package: tech-ctte

I call for votes on the following resolution.
Voting lasts for one week or until the outcome is no longer in doubt.

=== BEGIN

OPTION A:

The Technical Committee formally repeals its moratorium recommending
that maintainers of individual packages should not proactively move
files from the root filesystem to corresponding locations under /usr in
the data.tar.* of packages (see #1035831).

Under Constitution 6.1.5, the Technical Committee now recommends that
maintainers consult with those driving the merged-/usr transition before
moving files from the root filesystem to corresponding locations under
/usr in the data.tar.* of packages.

The transition driver, which at the time of writing is Helmut Grohne, is
using a phased approach, in which the moratorium is rolled back for only
certain classes of packages, and changes, at a time.  In addition,
restructuring uploads should be targeted at experimental, and left for
three days.  This is in order that automated testing by dumat can occur.

We recommend following , as edited by
the transition driver(s).  If there is any doubt as to whether a change
you wish to make is appropriate, please seek explicit approval from the
transition driver(s).

OPTION N:

None of the above.

=== END

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1053900: cryptsetup: Support multiple OpenPGP SmartCards in "decrypt_gnupg-sc"

[Christoph Chvojka]

Package: cryptsetup
Version: 2:2.6.1-5


New feature description
"/usr/lib/cryptsetup/scripts/decrypt_gnupg-sc" currently only supports
one OpenPGP Key.
Please add an option to support multiple OpenPGP Keys.


Further description
To enable this an option would be to replace the current call of
"decrypt_gpg" like in this patch:
--- /usr/lib/cryptsetup/scripts/decrypt_gnupg-sc2023-04-21
00:54:29.0 +0200
+++ decrypt_gnupg-sc2023-10-13 22:24:16.044055384 +0200
@@ -40,5 +40,10 @@
 exit 1
 fi
 
-decrypt_gpg "$1"
+key_email=$(run_gpg --batch --quiet --no-tty --card-status | sed -nE
"s/.*<(.*)>.*/\1/p")
+if [ -f "$1-${key_email}" ]; then
+  decrypt_gpg "$1-${key_email}"
+else
+  decrypt_gpg "$1"
+fi
 exit $?



Additionally "/usr/share/initramfs-tools/hooks/cryptgnupg-sc" needs to
be adapted to also include the available files for the individual
OpenPGP Keys.
Based on the above code an individual CRYPTTAB_KEY would have as suffix
"-${key_email}".
If the CRYPTTAB_KEY is "cryptkey.gpg" an individual one
for firstname.lastn...@debian.org would be like
"cryptkey.gpg-firstname.lastn...@debian.org".

With this adaption "decrypt_gnupg-sc" would try to use the individual
CRYPTTAB_KEY first put fallback to the generic CRYPTTAB_KEY if it can't
be found. If multiple individual CRYPTTAB_KEY are provided it would
pick the right one based on the e-mail address of the key.

Thx & Kind regards,
Christoph

Bug#1053899: "Get books" not working: TypeError: ResultsView.__init__()

[Nicolas Sergent]

Package: calibre
Version: 6.13.0+repack-2+deb12u1
Severity: normal
Tags: patch

Dear Maintainer,

In current version of Calibre in Bookworm, the "Get books" menu doesn't
work, and give this error when accessing it:

calibre, version 6.13.0
ERROR: Unhandled exception: TypeError:ResultsView.__init__()
got an unexpected keyword argument 'parent'

calibre 6.13  embedded-python: False
Linux-6.1.0-10-amd64-x86_64-with-glibc2.36 Linux ('64bit', 'ELF')
('Linux', '6.1.0-10-amd64', '#1 SMP PREEMPT_DYNAMIC Debian 6.1.37-1
(2023-07-03)')
Python 3.11.2
Interface language: en_GB
Successfully initialized third party plugins: DeDRM (10, 0, 3) &&
Kindle hi-res covers (0, 5, 0) && Obok DeDRM (10, 0, 3)
Traceback (most recent call last):
  File "/usr/lib/calibre/calibre/gui2/actions/store.py", line 49, in do_search
return self.search()
   ^
  File "/usr/lib/calibre/calibre/gui2/actions/store.py", line 55, in search
sd = SearchDialog(self.gui, self.gui, query)
 ^^^
  File "/usr/lib/calibre/calibre/gui2/store/search/search.py", line
38, in __init__
self.setupUi(self)
  File "/usr/lib/calibre/calibre/gui2/store/search/search_ui.py", line
84, in setupUi
self.results_view = ResultsView(parent=self.verticalLayoutWidget)
^
TypeError: ResultsView.__init__() got an unexpected keyword argument 'parent'


Applying this upstream patch solves the issue on my system:
https://github.com/kovidgoyal/calibre/commit/f4fe3f254d3de0dd51722b3b5e08112ae82ebf51

Let me know if you need any further info!

BW

Khapin


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

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

Versions of packages calibre depends on:
ii  ca-certificates20230311
ii  calibre-bin6.13.0+repack-2+deb12u1
ii  fonts-liberation2  2.1.5-1
ii  libjpeg-turbo-progs1:2.1.5-2
ii  libjxr-tools   1.2~git20170615.f752187-5
ii  libqt6webenginecore6-bin   6.4.2-final+dfsg-1
ii  optipng0.7.7-2+b1
ii  poppler-utils  22.12.0-2+b1
ii  pyqt6-dev-tools6.4.2-1
ii  python33.11.2-1+b1
ii  python3-apsw   3.40.0.0-2+b1
ii  python3-bs44.11.2-2
ii  python3-chm0.8.6-3+b4
ii  python3-css-parser 1.0.8-1
ii  python3-cssselect  1.2.0-2
ii  python3-dateutil   2.8.2-2
ii  python3-feedparser 6.0.10-1
ii  python3-html2text  2020.1.16-2
ii  python3-html5-parser   0.4.10-8+b1
ii  python3-html5lib   1.1-3
ii  python3-jeepney0.8.0-3
ii  python3-lxml   4.9.2-1+b1
ii  python3-markdown   3.4.1-2
ii  python3-mechanize  1:0.4.8+pypi-5
ii  python3-msgpack1.0.3-2+b1
ii  python3-netifaces  0.11.0-2+b1
ii  python3-pil9.4.0-1.1+b1
ii  python3-pkg-resources  66.1.1-1
ii  python3-py7zr  0.11.3+dfsg-5
ii  python3-pycryptodome   3.11.0+dfsg1-4
ii  python3-pygments   2.14.0+dfsg-1
ii  python3-pyparsing  3.0.9-1
ii  python3-pyqt6  6.4.2-1
ii  python3-pyqt6.qtquick  6.4.2-1
ii  python3-pyqt6.qtsvg6.4.2-1
ii  python3-pyqt6.qtwebengine  6.4.0-1
ii  python3-pyqt6.sip  13.4.1-1
ii  python3-regex  0.1.20221031-1+b1
ii  python3-routes 2.5.1-3
ii  python3-speechd0.11.4-2
ii  python3-zeroconf   0.47.3-1
ii  python3.11 3.11.2-6
ii  xdg-utils  1.1.3-4.1

Versions of packages calibre recommends:
ii  python3-dnspython  2.3.0-1
ii  python3-ipython8.5.0-4
ii  qt6-wayland6.4.2-1
ii  udisks22.9.4-4

Versions of packages calibre suggests:
ii  python3-unrardll  0.1.5-6+b1

-- no debconf information

Bug#1023047: wsjtx: No transmit audio

[Christoph Berg]

Re: erebion
> According to Pavucontrol there is no audio, as wsjtx does not show up. That
> is while transmitting, haven't tried to receive last time as I did not have
> the required cable with me.
> 
> I think input was broken as well, but to be sure I'd need to have another
> look.

You don't need the radio connected, you can also let wsjtx record
audio from the local mic and check if the ambient noise shows up on
the waterfall. (Same for TX and local speaker of course.)

If wsjtx doesn't show up, I don't really know where to look further.
(Frustratingly, I have the same issue atm with wfview. I currently
blame pipewire, but I think it did work before.)

Christoph

Bug#1053898: Hardening rsyslog.service breaks debian/tests/logcheck autopkgtest

[Michael Biebl]

Source: rsyslog
Version: 8.2310.0-1
Severity: serious
X-Debbugs-Cc: Richard Lewis 


The latest update of rsyslog enabled various systemd hardening and
security features, specifically:

CapabilityBoundingSet=CAP_BLOCK_SUSPEND CAP_CHOWN CAP_LEASE CAP_NET_ADMIN 
CAP_NET_BIND_SERVICE CAP_SYS_RESOURCE CAP_SYSLOG
SystemCallFilter=@system-service
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectSystem=full
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectClock=yes
ProtectControlGroups=yes
ProtectHostname=yes


It turns out that `PrivateTmp=yes` breaks the logcheck autopkgtest.

@Richard: as author of that test, could you please that a look at this
issue. It currently prevents rsyslog from migrating to testing.

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


Regards,
Michael

Bug#1053896: Acknowledgement (content very outdated)

[Thomas Lange]

It seems that on https://www.debian.org/doc/user-manuals#java-faq we
publish the a version from 2014 from
https://salsa.debian.org/ddp-team/java-faq
which is much more outdated that the version in the package
java-policy.

-- 
regards Thomas

Bug#1053897: src:ansible-core: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: ansible-core
Version: 2.14.9-2
Severity: serious
Control: close -1 2.14.10-1
Tags: sid trixie
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 30 days as having a Release Critical bug in 
testing [1]. Your package src:ansible-core has been trying to migrate 
for 31 days [2]. Hence, I am filing this bug. The version in unstable 
fails its own autopkgtest.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=ansible-core



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053896: content very outdated

[Thomas Lange]

Package: java-policy
Version: 0.57


Hi,

the Java FAQ is very outdated. It only covers i386 and java 6/7 up to
Debian wheezy. There are links to alioth and it talks about
icedtea-7-plugin.

The salsa repo shows that it was not updated since 9 years.

Maybe we should remove the FAQ.
--
regards Thomas

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Antoine Beaupré]

On 2023-10-13 11:40:17, Antoine Beaupré wrote:

[...]

> What's the magic setting to make apt check those updates on its own? I
> often get confused between unattended-upgrades and apt there...

Answering my own question, again, on my Debian bookworm machine, there's
a `/etc/cron.daily/apt-compat` script (for systemd-less systems) and a
`apt-daily.service` service. The latter does
`/usr/lib/apt/apt.systemd.daily update` which, if
`APT::Periodic::Update-Package-Lists` is set in apt-config(8), will
periodically update the package list.

I believe that is the canonical and normal way of doing this.

Bug#1053895: bookworm-pu: package node-undici/5.15.0+dfsg1+~cs20.10.9.3-1+deb12u2

[Yadd]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: node-und...@packages.debian.org
Control: affects -1 + src:node-undici

[ Reason ]
node-undici doesn't clear Cookie and Host headers on cross-origin
redirect.

[ Impact ]
Medium security issue

[ Tests ]
No new test here

[ Risks ]
No risk, patch is trivial

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

[ Changes ]
Drop headers Host/Cookie unless same-origin

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 92c0de8..168ee34 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-undici (5.15.0+dfsg1+~cs20.10.9.3-1+deb12u2) bookworm; urgency=medium
+
+  * Delete cookie and host headers on cross-origin redirect
+(Closes: #1053879, CVE-2023-45143)
+
+ -- Yadd   Fri, 13 Oct 2023 22:14:45 +0400
+
 node-undici (5.15.0+dfsg1+~cs20.10.9.3-1+deb12u1) bookworm; urgency=medium
 
   * Fix security issues (Closes: #1031418):
diff --git a/debian/patches/CVE-2023-45143.patch 
b/debian/patches/CVE-2023-45143.patch
new file mode 100644
index 000..c196bd2
--- /dev/null
+++ b/debian/patches/CVE-2023-45143.patch
@@ -0,0 +1,24 @@
+Description: delete 'cookie' and 'host' headers on cross-origin redirect
+Author: Khafra 
+Origin: upstream, https://github.com/nodejs/undici/commit/e041de35
+Bug: https://github.com/nodejs/undici/security/advisories/GHSA-wqq4-5wpv-mx2g
+ https://github.com/nodejs/undici/security/advisories/GHSA-q768-x9m6-m9qp
+Bug-Debian: https://bugs.debian.org/1053879
+Forwarded: not-needed
+Applied-Upstream: 5.26.2, commit:e041de35
+Reviewed-By: Yadd 
+Last-Update: 2023-10-13
+
+--- a/lib/fetch/index.js
 b/lib/fetch/index.js
+@@ -1204,6 +1204,10 @@
+   if (!sameOrigin(requestCurrentURL(request), locationURL)) {
+ // https://fetch.spec.whatwg.org/#cors-non-wildcard-request-header-name
+ request.headersList.delete('authorization')
++
++// "Cookie" and "Host" are forbidden request-headers, which undici 
doesn't implement.
++request.headersList.delete('cookie')
++request.headersList.delete('host')
+   }
+ 
+   // 14. If request’s body is non-null, then set request’s body to the first 
return
diff --git a/debian/patches/series b/debian/patches/series
index ce1440a..297000a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -8,3 +8,4 @@ drop-ssl-tests.patch
 CVE-2023-23936.patch
 CVE-2023-24807.patch
 update-httpbin.org-test-timeout.patch
+CVE-2023-45143.patch

Bug#998105: Still not fixed in Debian

[Sven Geuer]

Control: reopen -1 =

I reopen this bug as it is still not fixed in Debian.

The fact that it has been fixed upstream is documented by the fixed-
upstream tag, while this alone is not reason enough to close the bug.
The fixed version needs to be packaged in Debian first.

Sorry,
Sven
-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#1053894: etbemon: please consider upgrading to 3.0 source format

[Bastian Germann]

Source: etbemon
Version: 1.3.6-4.1
Severity: wishlist

This package is among the few that still use source format 1.0.
Please upgrade it to source format 3.0:
https://wiki.debian.org/Projects/DebSrc3.0

Bug#1053893: Please update VCS links

[Santiago Ruano Rincón]

Source: robber
Severity: normal

Dear robber maintainer(*),

I think your plain is to maintain robber inside the python-team/packages
namespace. Could you please move the repository there?

After that, the VCS* fields should be updated. If I am not wrong, the
correct location would be:

diff --git a/debian/control b/debian/control
index 48a54cd..809620f 100644
--- a/debian/control
+++ b/debian/control
@@ -15,8 +15,8 @@ Build-Depends:
 Testsuite: autopkgtest-pkg-python
 Standards-Version: 4.6.2
 Homepage: https://github.com/EastAgile/robber.py
-Vcs-Browser: https://salsa.debian.org/debian/python-team/robber
-Vcs-Git: https://salsa.debian.org/debian/python-team/robber.git
+Vcs-Browser: https://salsa.debian.org/python-team/packages/robber
+Vcs-Git: https://salsa.debian.org/python-team/packages/robber.git
 
 Package: python3-robber
 Architecture: all

* Congratulations for your first package in Debian!

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

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


signature.asc
Description: PGP signature

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Antoine Beaupré]

On 2023-10-13 11:59:23, Antoine Beaupré wrote:
> severity 1028212 serious
> tags 1028212 +patch

[...]

> From 3b17a4dcb8caa56191c5be523c874a7f470bd04a Mon Sep 17 00:00:00 2001

[...]

> diff --git a/apt_info.py b/apt_info.py
> index eb1a642..9b1b675 100755
> --- a/apt_info.py
> +++ b/apt_info.py

[...]

>  registry = CollectorRegistry()
>  _write_pending_upgrades(registry, cache)
>  _write_held_upgrades(registry, cache)

That patch doesn't actually apply cleanly on bookworm because upstream
did some refactoring, the attached patch should work better.

A.
-- 
C'est avec les pierres de la loi qu'on a bâti les prisons,
et avec les briques de la religion, les bordels.
- William Blake
>From 28c179ddfd3d7e0f5bc49b93f924f0dffba5b71d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Fri, 13 Oct 2023 12:29:48 -0400
Subject: [PATCH] do not run apt update or simulate apt dist-upgrade
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is causing all sorts of problems. The first of which is that
we're hitting our poor mirrors every time the script is ran, which, in
the Debian package configuration, is *every 15 minutes* (!!).

The second is that this locks the cache and makes this script
needlessly stumble upon a possible regression in APT from Debian
bookworm and Ubuntu 22.06:

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2003851

That still has to be confirmed: it's possible that `apt update` can
hang for a long time, but that shouldn't concern us if we delegate
this work out of band.

I also do not believe actually performing the `dist-upgrade`
calculations is necessary to compute the pending upgrades at all. I've
done work with python-apt for other projects and haven't found that to
be required: the cache has the necessary information about pending
upgrades.

Closes: #179

Signed-off-by: Antoine Beaupré 
---
 apt_info.py | 9 -
 1 file changed, 9 deletions(-)

diff --git a/apt_info.py b/apt_info.py
index 59f3ad7..81a276b 100755
--- a/apt_info.py
+++ b/apt_info.py
@@ -9,7 +9,6 @@
 
 import apt
 import collections
-import contextlib
 import os
 
 _UpgradeInfo = collections.namedtuple("_UpgradeInfo", ["labels", "count"])
@@ -90,14 +89,6 @@ def _write_reboot_required():
 def _main():
 cache = apt.cache.Cache()
 
-# First of all, attempt to update the index. If we don't have permission
-# to do so (or it fails for some reason), it's not the end of the world,
-# we'll operate on the old index.
-with contextlib.suppress(apt.cache.LockFailedException, apt.cache.FetchFailedException):
-cache.update()
-
-cache.open()
-cache.upgrade(True)
 _write_pending_upgrades(cache)
 _write_held_upgrades(cache)
 _write_autoremove_pending(cache)
-- 
2.39.2

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Antoine Beaupré]

On 2023-10-13 09:17:49, Kyle Fazzari wrote:

[...]

> I don't entirely agree, but disagreement is okay. I do at least 
> recommend accompanying this with a cache age statistic, as we discussed 
> earlier.

Right, that would be a better way of going around doing that. I have a
separate upstream issue about this, and we can track that problem
there:

https://github.com/prometheus-community/node-exporter-textfile-collector-scripts/issues/180

We might be able to squeeze that metric along with the hotfix here, that
said, we just need to make sure of the better way of reporting that
metric.

a.
-- 
I've got to design so you can put it together out of garbage cans. In
part because that's what I started from, but mostly because I don’t
trust the industrial structure—they might decide to suppress us
weirdos and try to deny us the parts we need.
   - Lee Felsenstein

Bug#1053892: lintian: Stop emitting masked tags

[Raphaël Hertzog]

Package: lintian
Version: 2.116.3
Severity: wishlist
X-Debbugs-Cc: raph...@freexian.com

I just discovered the existence of masked tags and of the "Screen"
mechanism to exclude some tags. I also notice that they are
displayed together with overriden tags when you use --show-overrides.
Yet they are very different.

I believe that a tag that lintian decided to suppress should simply never be
emitted, not even as a masked tag. Thus I would suggest to stop emitting
masked tags.

But if you disagree with this, it might make sense to offer the
possibility to handle masked tags separately from overriden tags.

(Again this is a followup from a discussion here
https://salsa.debian.org/freexian-team/debusine/-/merge_requests/300#note_434002)

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

Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 lintian depends on:
ii  binutils2.41-5
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.22.0
ii  dpkg-dev1.22.0
ii  file1:5.45-2
ii  gettext 0.21-13+b1
ii  gpg 2.2.40-1.1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.15.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.29-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.37-1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.0
ii  libemail-address-xs-perl1.05-1+b1
ii  libencode-perl  3.19-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.636-1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1
ii  libsereal-encoder-perl  5.004+ds-1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.21-1
ii  libwww-mechanize-perl   2.17-1
ii  libwww-perl 6.72-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.86+ds-1
ii  lzip [lzip-decompressor]1.23-6
ii  lzop1.04-2
ii  man-db  2.12.0-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-9
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.4.4-0.1

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.41-5
ii  libtext-template-perl  1.61-1

-- no debconf information

Bug#1053891: lintian: Document the existence of classification tags in the manual page

[Raphaël Hertzog]

Package: lintian
Version: 2.116.3
Severity: wishlist
X-Debbugs-Cc: raph...@freexian.com

Hello,

the conversation in
https://salsa.debian.org/freexian-team/debusine/-/merge_requests/300#note_434002
led me to realize that as a simple lintian user reading the manual page,
you can't discover the existence of classification tags and you can't
figure out the syntax to enable the display of those tags.

Please improve the manual page to explain what classification tags are,
that they are considered like normal tags with a priority lower than
everything else and that you can enable them with "--display-level
+=classification".

BTW in general, the whole explanation about --display-level is pretty
confusing, it's not clear to me what "S|C|S/C" is supposed to mean for
instance. And there's no global sorted list of usable severity so
it's hard to predict the result of --display-level '>=classification'.

Cheers,

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

Kernel: Linux 6.5.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 lintian depends on:
ii  binutils2.41-5
ii  bzip2   1.0.8-5+b1
ii  diffstat1.65-1
ii  dpkg1.22.0
ii  dpkg-dev1.22.0
ii  file1:5.45-2
ii  gettext 0.21-13+b1
ii  gpg 2.2.40-1.1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.15.0-1
ii  libapt-pkg-perl 0.1.40+b2
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b1
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b1
ii  libclone-perl   0.46-1
ii  libconfig-tiny-perl 2.29-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.37-1
ii  libdata-dpath-perl  0.58-2
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-2+b1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.0
ii  libemail-address-xs-perl1.05-1+b1
ii  libencode-perl  3.19-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-2
ii  libipc-run3-perl0.048-3
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b1
ii  libperlio-utf8-strict-perl  0.010-1
ii  libproc-processtable-perl   0.636-1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1
ii  libsereal-encoder-perl  5.004+ds-1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-1
ii  libterm-readkey-perl2.38-2+b1
ii  libtext-levenshteinxs-perl  0.03-5+b1
ii  libtext-markdown-discount-perl  0.16-1
ii  libtext-xslate-perl 3.5.9-1+b2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b1
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2
ii  liburi-perl 5.21-1
ii  libwww-mechanize-perl   2.17-1
ii  libwww-perl 6.72-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b1
ii  libyaml-libyaml-perl0.86+ds-1
ii  lzip [lzip-decompressor]1.23-6
ii  lzop1.04-2
ii  man-db  2.12.0-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.36.0-9
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.4.4-0.1

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.41-5
ii  libtext-template-perl  1.61-1

-- no debconf information

Bug#1053890: cachefilesd: please install and use the system .service file to start

[David Härdeman]

Package: cachefilesd
Version: 0.10.10-0.3
Severity: wishlist

Dear Maintainer,

the cachefilesd upstream package includes a systemd .service file, it'd be nice 
if it could be installed and used by the Debian package as well.

Even nicer would be to use a modernized/sandboxed version of the .service file 
(see attachment, I've forwarded it to the upstream maintainer as well).

Cheers,
David

PS
Might also be helpful to add a "Homepage: 
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/cachefilesd.git/; 
header to the debian/control file?[Unit]
Description=Local network file caching management daemon
Documentation=man:cachefilesd(8) man:cachefilesd.conf(5)
ConditionFileNotEmpty=/etc/cachefilesd.conf
ConditionPathIsDirectory=/var/cache/fscache
Wants=modprobe@cachefiles.service
After=modprobe@cachefiles.service
Before=remote-fs.target

[Service]
Type=simple
ProtectSystem=strict
ReadWritePaths=/var/cache/fscache
ProtectHome=tmpfs
PrivateTmp=yes
PrivateDevices=no
DeviceAllow=/dev/cachefiles
DevicePolicy=closed
PrivateNetwork=yes
PrivateIPC=yes
PrivateUsers=no
ProtectHostname=yes
ProtectClock=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectKernelLogs=yes
ProtectControlGroups=yes
RestrictAddressFamilies=none
RestrictNamespaces=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
PrivateMounts=yes
SystemCallFilter=@basic-io @file-system @io-event @setuid @signal @sync
SystemCallErrorNumber=EPERM
SystemCallArchitectures=native
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_SETGID CAP_SYS_ADMIN CAP_DAC_OVERRIDE
RuntimeDirectory=cachefilesd
ExecStart=/sbin/cachefilesd -n -p /run/cachefilesd/cachefilesd.pid

[Install]
WantedBy=multi-user.target

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Kyle Fazzari]

On 10/13/23 09:14, Antoine Beaupré wrote:

On 2023-10-13 09:05:35, Kyle Fazzari wrote:

On 10/13/23 08:26, Julian Andres Klode wrote:

Also please do not run apt update in the background or try to
calculate dist upgrades, that is evil and you're breaking stuff.
If you want to check for updates, make sure the periodic apt service
is configured to run. You are entitled to one run per day. If you
do not operate the mirror infrastructure please do not run your own
updates out of band.


A fair critique, although as I mentioned in an earlier email, this
collector cannot do its job if it's running on a significantly
out-of-date cache. At the same time, if feels out of scope for this
Debian package to ensure the periodic apt service is configured to run.
Feels like a rock and a hard place. Thoughts?


I think this is a deployment issue. People who provision this package
should *not* expect it to run `apt update`: I certainly didn't, and the
previous (shell) implementation didn't either.

We have other tools that continuously pull mirrors, and as jak stated,
APT can be configured to do so as well (although I'm not sure what the
canonical way of doing so).

So let's not do this here.


I don't entirely agree, but disagreement is okay. I do at least 
recommend accompanying this with a cache age statistic, as we discussed 
earlier.


Kyle

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Antoine Beaupré]

On 2023-10-13 09:05:35, Kyle Fazzari wrote:
> On 10/13/23 08:26, Julian Andres Klode wrote:
>> Also please do not run apt update in the background or try to
>> calculate dist upgrades, that is evil and you're breaking stuff.
>> If you want to check for updates, make sure the periodic apt service
>> is configured to run. You are entitled to one run per day. If you
>> do not operate the mirror infrastructure please do not run your own
>> updates out of band.
>
> A fair critique, although as I mentioned in an earlier email, this 
> collector cannot do its job if it's running on a significantly 
> out-of-date cache. At the same time, if feels out of scope for this 
> Debian package to ensure the periodic apt service is configured to run. 
> Feels like a rock and a hard place. Thoughts?

I think this is a deployment issue. People who provision this package
should *not* expect it to run `apt update`: I certainly didn't, and the
previous (shell) implementation didn't either.

We have other tools that continuously pull mirrors, and as jak stated,
APT can be configured to do so as well (although I'm not sure what the
canonical way of doing so).

So let's not do this here.

-- 
A developed country is not a place where the poor have cars. It's
where the rich use public transportation.
- Gustavo Petro 

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Kyle Fazzari]

On 10/13/23 08:26, Julian Andres Klode wrote:

Also please do not run apt update in the background or try to
calculate dist upgrades, that is evil and you're breaking stuff.
If you want to check for updates, make sure the periodic apt service
is configured to run. You are entitled to one run per day. If you
do not operate the mirror infrastructure please do not run your own
updates out of band.


A fair critique, although as I mentioned in an earlier email, this 
collector cannot do its job if it's running on a significantly 
out-of-date cache. At the same time, if feels out of scope for this 
Debian package to ensure the periodic apt service is configured to run. 
Feels like a rock and a hard place. Thoughts?


Kyle

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Antoine Beaupré]

severity 1028212 serious
tags 1028212 +patch
thanks

Also, considering what jak said about scripts that shouldn't hit mirrors
more than once a day, I'm going to mark this as release critical.

The rationale is that we're doing what I consider "is a severe violation
of Debian policy". While i am not sure there's a written policy of how
often you should hit mirrors, this is *definitely* too often. In our
modest fleet of 100 servers, hitting the mirrors every 15 minutes is
equivalent to generating one "hit" (which is possibly multiple HTTP
requests) *every nine seconds*!

So we need to fix this, and we need to fix it in bookworm, and IMHO,
ASAP. I'll certainly deploy the attached patch in production on our end
to see what comes up.

-- 
Do not use your energy to worry.
Use your energy to believe, to create, to learn, to think, and to grow.
- Richard Feynman
>From 3b17a4dcb8caa56191c5be523c874a7f470bd04a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Fri, 13 Oct 2023 11:44:17 -0400
Subject: [PATCH] do not run apt update or simulate apt dist-upgrade
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is causing all sorts of problems. The first of which is that
we're hitting our poor mirrors every time the script is ran, which, in
the Debian package configuration, is *every 15 minutes* (!!).

The second is that this locks the cache and makes this script
needlessly stumble upon a possible regression in APT from Debian
bookworm and Ubuntu 22.06:

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2003851

That still has to be confirmed: it's possible that `apt update` can
hang for a long time, but that shouldn't concern us if we delegate
this work out of band.

I also do not believe actually performing the `dist-upgrade`
calculations is necessary to compute the pending upgrades at all. I've
done work with python-apt for other projects and haven't found that to
be required: the cache has the necessary information about pending
upgrades.

Closes: #179

Signed-off-by: Antoine Beaupré 
---
 apt_info.py | 10 --
 1 file changed, 10 deletions(-)

diff --git a/apt_info.py b/apt_info.py
index eb1a642..9b1b675 100755
--- a/apt_info.py
+++ b/apt_info.py
@@ -10,7 +10,6 @@
 
 import apt
 import collections
-import contextlib
 import os
 from prometheus_client import CollectorRegistry, Gauge, generate_latest
 
@@ -83,15 +82,6 @@ def _write_reboot_required(registry):
 def _main():
 cache = apt.cache.Cache()
 
-# First of all, attempt to update the index. If we don't have permission
-# to do so (or it fails for some reason), it's not the end of the world,
-# we'll operate on the old index.
-with contextlib.suppress(apt.cache.LockFailedException, apt.cache.FetchFailedException):
-cache.update()
-
-cache.open()
-cache.upgrade(True)
-
 registry = CollectorRegistry()
 _write_pending_upgrades(registry, cache)
 _write_held_upgrades(registry, cache)
-- 
2.39.2

Bug#1053359: U-Boot: please package starfive_visionfive2_defconfig in U-Boot v2023.10

[Heinrich Schuchardt]

U-Boot v2023.01 introduced SPL code to detect the memory size on the 
different VisionFive 2 boards and adjust the device-tree accordingly.


This relies on reading the EEPROM. Unfortunately the Designware I2C 
driver has an issue. So the following patch is needed:


[PATCH v2] i2c: designware_i2c: adjust timing calculation
https://lore.kernel.org/u-boot/20231013130939.19803-1-heinrich.schucha...@canonical.com/

Best regards

Heinrich

Bug#1053889: mirror submission for drmirror.physi.uni-heidelberg.de

[Tobias Mueller]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: drmirror.physi.uni-heidelberg.de
Archive-architecture: amd64 i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Tobias Mueller 
Country: DE Germany
Location: Heidelberg
Sponsor: Physikalisches Institut Uni Heidelberg https://physi.uni-heidelberg.de




Trace Url: http://drmirror.physi.uni-heidelberg.de/debian/project/trace/
Trace Url: 
http://drmirror.physi.uni-heidelberg.de/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://drmirror.physi.uni-heidelberg.de/debian/project/trace/drmirror.physi.uni-heidelberg.de

Bug#1053747: [Debian-on-mobile-maintainers] Bug#1053747: Upload phosh to bookworm-backports ?

[Pirate Praveen]

On Wed, 11 Oct 2023 11:07:57 +0200 Guido =?iso-8859-1?Q?G=FCnther?= 
 wrote:

> Hi Praveen,
> I'm always in favour of providing newer phosh to users but see below 
for details:

>
> On Tue, Oct 10, 2023 at 02:33:52PM +0530, Pirate Praveen via 
Debian-on-mobile-maintainers wrote:

> > Package: phosh
> > Version: 0.32.0-1
> > Severity: wishlist
> >
> > I think it'd be a good idea to provide new versions of phosh (with 
phoc,
> > wlroots, feedbackd) via bookworm-backports. I was earlier daily 
driving
> > mobian trixie on my Librem 5 but since its automatic suspend broke 
I could
> > not continue using it [1]. So I'm using mobian bookworm but I miss 
the newer
> > phosh (especially easy access to suspend button, which I use often 
for power

> > saving).
> >
> > I have built the debs already and started using it from yesterday. 
I have
> > shared the debs in my personal repo [2]. I'd like to upload and 
help
> > maintain it in bookworm-backports if you are okay with the idea of 
providing

> > official backports.
>
> I'm okay with the idea if you sign up to handle bug reports 
concerning

> the backported versions. If that makes sense to you and Mobian has no
> objections (as I think running it together with Mobian will be the 
main

> use case for most people) we should maintain the backported branch in
> the DebianOnMobile git too.
>
> Note that backporting phosh will imply backporting phoc at some point
> and might also break phosh-mobile-settings at some point (and that
> requires newer libadwaita already (which requires newer GTK). That
> shouldn't' prevent us from backporting just now, just wanted to lay 
out

> that it might get a bit more involved in the future.

I tried backporting phosh-mobile-settings now, as you mentioned it 
needs newer libadwaita, which in turn needs newer glib and gtk4. So I 
think gnome team won't like the official backports.


Arnaud,

Do you think it would be a good idea to have bookworm-backports suite 
in mobian repo and upload these there?


As for bugs, I think keeping up with new upstream versions would be a 
good strategy. If I go with byzantium experience, I'd think you will 
support newer versions on crimson, so having bookworm-backports should 
be easier to maintain.

> Cheers and thanks for having a look at this,
>  -- Guido
>
> >
> > Since pureos crimson is not yet useable, I think this would be 
useful for

> > many who want a newer base OS.
> >
> > [1] 


> > [2] 
> >
> > ___
> > Debian-on-mobile-maintainers mailing list
> > debian-on-mobile-maintain...@alioth-lists.debian.net
> > 


> >
>
>

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Antoine Beaupré]

On 2023-10-13 11:40:17, Antoine Beaupré wrote:

[...]

> I agree this is a little odd and that the prometheus apt plugin should
> probably not be the one handling the cache update.

I have made a patch upstream for this:

https://github.com/prometheus-community/node-exporter-textfile-collector-scripts/pull/181

I believe this would fix this issue as far as apt_info.py is concerned.

I do feel there's an outstanding issue here in apt, however, but that's
probably better served by another bug report.

[...]

> Could you expand on this? What's the proper pythonic way of doing this?
>
> The script currently does:
>
> cache = apt.cache.Cache()
> with contextlib.suppress(apt.cache.LockFailedException, 
> apt.cache.FetchFailedException):
> cache.update()
>
> cache.open()
> cache.upgrade(True)
>
> What's the locking part here? Is this sufficient?
>
> cache = apt.cache.Cache()

I have just done that, @jak it would be great if you could just +1 the
above...

Thanks again!

Bug#1053888: dh-dist-zilla: does not run 'dzil clean' on dh_clean

[Dominique Dumont]

Package: dh-dist-zilla
Version: 1.4.1
Severity: normal

Dear Maintainer,

Due to bug #1049036, I have to run cleanup files generated by dzil build.

These files are handled upstream by this config in dist.ini:

[Run::Clean]
run = rm -rf lib/Config/Model/models/

Unfortunately, "dzil clean" is not called by default when running dh_clean.

Could you add that to dh-dist-zilla ?

All the best


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

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 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 dh-dist-zilla depends on:
ii  debhelper   13.11.6
ii  libdist-zilla-perl  6.030-1
ii  perl5.36.0-9

Versions of packages dh-dist-zilla recommends:
ii  devscripts  2.23.6

Versions of packages dh-dist-zilla suggests:
ii  libdist-zilla-app-command-authordebs-perl  0.003-2
ii  pristine-tar   1.50
ii  xz-utils   5.4.4-0.1

-- no debconf information

Bug#1053887: apt does not error and exit under some circumstances

[Tianyu Chen]

Control: found 2.7.6

Control: tags -1 patch


Patch available https://salsa.debian.org/apt-team/apt/-/merge_requests/308


Tianyu Chen @ deepin
From 74f31de1d980c28ba7ba509fc683ccca92db55b4 Mon Sep 17 00:00:00 2001
From: Tianyu Chen 
Date: Fri, 13 Oct 2023 23:16:25 +0800
Subject: [PATCH] apt-pkg/cacheset.cc: set ShowErrors to true when no version
 matched

Enforce helper.canNotGetVersion to show error if no version matched.

Regression-of: 572810e9f321237873d1536c88991d7825c6f1db
Closes: #1053887
---
 apt-pkg/cacheset.cc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/apt-pkg/cacheset.cc b/apt-pkg/cacheset.cc
index e52f76272..ee0dcee28 100644
--- a/apt-pkg/cacheset.cc
+++ b/apt-pkg/cacheset.cc
@@ -491,10 +491,13 @@ bool VersionContainerInterface::FromString(VersionContainerInterface * const vci
 			V = Match.Find(P);
 			helper.setLastVersionMatcher(ver);
 			if (V.end()) {
+bool errors = true;
+errors = helper.showErrors(true);
 if (verIsRel == true)
 	V = helper.canNotGetVersion(CacheSetHelper::RELEASE, Cache, P);
 else
 	V = helper.canNotGetVersion(CacheSetHelper::VERSIONNUMBER, Cache, P);
+helper.showErrors(errors);
 			}
 		}
 		if (V.end() == true)
-- 
2.33.1

Bug#1053747: [Debian-on-mobile-maintainers] Bug#1053747: Upload phosh to bookworm-backports ?

[Pirate Praveen]

On Tue, 10 Oct 2023 23:56:54 +0200 Arnaud Ferraris 
 wrote:

> Hi,
>
> Le 10/10/2023 à 11:03, Pirate Praveen via 
Debian-on-mobile-maintainers a

> écrit :
> > Package: phosh
> > Version: 0.32.0-1
> > Severity: wishlist
> >
> > I think it'd be a good idea to provide new versions of phosh (with 
phoc,
> > wlroots, feedbackd) via bookworm-backports. I was earlier daily 
driving
> > mobian trixie on my Librem 5 but since its automatic suspend broke 
I
> > could not continue using it [1]. So I'm using mobian bookworm but 
I miss
> > the newer phosh (especially easy access to suspend button, which I 
use

> > often for power saving).
>
> As discussed in the Mobian issue you mention, the auto-suspend 
problem

> you're experiencing is only happening with recent versions of phosh,
> which basically reset the idle counter when a critical notification 
happens.

>
> Providing a backported version of phosh wouldn't help there, and the
> solution should be provided by upstream gnome-settings-daemon[1]. In 
the

> meantime, you can work around this issue by executing, for example:
>
>gsettings set sm.puri.phosh.notifications wakeup-screen-triggers 
'[]'


Thanks this fixes the auto suspend, though one motivation for getting 
newer phosh was its suspend inhibition when wifi tethering is active, 
which is also disabled with this setting. But I can live with that 
until gnome-settings-daemon is fixed. This means I have to remember to 
toggle suspend when charging each time I turn on or off wifi tethering. 
I was using a script earlier to launch tethering and inhibit suspend 
earlier, I will go back to it until this gets fixed.


> Cheers,
> Arnaud
>
> [1]
> 


>
> >
> > I have built the debs already and started using it from yesterday. 
I
> > have shared the debs in my personal repo [2]. I'd like to upload 
and
> > help maintain it in bookworm-backports if you are okay with the 
idea of

> > providing official backports.
> >
> > Since pureos crimson is not yet useable, I think this would be 
useful

> > for many who want a newer base OS.
> >
> > [1] 


> > [2] 
> >
> > ___
> > Debian-on-mobile-maintainers mailing list
> > debian-on-mobile-maintain...@alioth-lists.debian.net
> > 


>
>
>

Bug#966218: firmware: failed to load iwl-debug-yoyo.bin (-2)

[Miguel A. Rojas]

found 966218 linux/6.5.6-1
found 966218 firmware-iwlwifi/20230515-3
Bug still running around ;)

regards

Bug#1053887: apt does not error and exit under some circumstances

[Tianyu Chen]

Package: apt
Version: 2.6.0-1deepin5
Severity: normal
X-Debbugs-Cc: black-desk , lichengg...@uniontech.com, 
sweetyf...@deepin.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

When a system is configured with no sources.list, or removing all
`Packages` files under /var/lib/apt/lists, running apt install with
a ReGex matching a local package and a non-existent version, apt doesn't
work as expected. For instance, running `apt installing '^apt$=1`
is not failing.

Steps to Reproduce:
1. Remove sources.list and Removing all files under sources.list.d/
2. Run apt update to clean all caches
3. Run apt install '^apt$'=1000

Expected Behavior:
$ LANG=C apt install '^apt$'=1000
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package apt is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Version '1000' for 'apt' was not found
$ echo $?
100

Actual Behavior:
$ LANG=C apt install '^apt$'=1000
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'apt' for regex '^apt$'
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
$ echo $?
0

After bisecting the source, we found that this bug is introduced in "Allow 
=version
and /release selector on virtual packages" 
(572810e9f321237873d1536c88991d7825c6f1db).
In apt-pkg/cacheset.cc:493, when `Match.Find()` fails, the program runs
helper.canNotGetVersion(CacheSetHelper::VERSIONNUMBER, Cache, P).
However, ShowErrors are set previously in apt-pkg/cacheset.cc:468:

if (pkgset.getConstructor() != CacheSetHelper::UNKNOWN)
errors = helper.showErrors(false);

When attempting inserting error "Version '%s' for '%s' was not found" in
canNotGetVerFromVersionNumber, the error is ignored with ShowError=false;

A possible fix is to set ShowErrors to true before helper.canNotGetVersion()
and set it back afterwards.

Thanks!

Tianyu Chen @ deepin

- -- System Information:
Distributor ID: Deepin
Description:Deepin 23
Release:23
Codename:   beige
Architecture: x86_64

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

Versions of packages apt depends on:
ii  adduser 3.131-1deepin2
ii  base-passwd 3.6.0
ii  deepin-keyring  2021.06.07-1
ii  gpgv2.2.27-2+rb1
ii  libapt-pkg6.0   2.6.0-1deepin5
ii  libc6   2.35-deepin3
ii  libgcc-s1   11.2.0-deepin2+rb2
ii  libgnutls30 3.7.2-2
ii  libseccomp2 2.5.4-1
ii  libstdc++6  11.2.0-deepin2+rb2
ii  libsystemd0 254-1

Versions of packages apt recommends:
ii  ca-certificates  20211016

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.13.1-1+dde
ii  dpkg-dev1.21.20-1deepin2+rb6
ii  gnupg   2.2.27-2+rb1
pn  powermgmt-base  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEEymuVC2ScVNxadrE1GcPUSWHDMHwFAmUpYroWHHN3ZWV0eWZp
c2hAZGVlcGluLm9yZwAKCRAZw9RJYcMwfKCqD/40LtQrTl1oSwIYp8rqol6MJFTD
G6g9Lb8fKG43B9mulA6o0K3LTBiIx3iFJFKy3WGMv3sce608SXYbcTX3ypHKokkh
/XX+LmblDRixN/Oz0qhzPEJDMbS7wslY2c1NxqJRxSFlPoglT8JNhCLYuIHEaUSP
4mLF79JcPTvYf659GTtfJKDpafyb03oMtCkMxlJW7n2HT53jhtvZN6lwr7D+GPqp
goNRUgBVeDyiNC5AqBSnB/fogSoB/yBcwhOwQ9fy8lWgiBEn/Lk2NNN9D0htfzJK
S5K1Qq6W3A7/jmqqZ3GkNnhZASwBBbB6GSrVMXYXgIsr9fNp31+5ZduqmDBxgno0
/k8oivKw6IR4y95AWvL2y7EaEGcR6u1VIVEIKIIapeuHwDw+1XjRuCxPzT+jJGOn
sxNU/QZ23j+LzlMRlXZfKV0sk3WFaxV0zIdWhH12h3sfd62gI2W43jYWVrRltYaU
OtpYo4HC7tV+60KeIVPXIUNcwZHS+8mTq6vNaJS73rdYaVVKHSHE8TbJaGfZe3Qo
As7ZSD0FYnS9kV9icQ0x5uKzbqHSE4JVkihewO8mWoYDDXBNcgoiRoXEV9vTSuEY
eabrQTR2j2xUf/pWDX9rmZFVjMDJGImH3VvE2a981hq5OYgH0L0XCEpFJV84dAyM
g7EoWii8wrMK53LLUw==
=X3oU
-END PGP SIGNATURE-

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Antoine Beaupré]

On 2023-10-13 17:26:38, Julian Andres Klode wrote:
> On Fri, Oct 13, 2023 at 10:29:10AM -0400, Antoine Beaupré wrote:
>> On 2023-10-12 21:25:20, Kyle Fazzari wrote:
>> > On 10/11/23 22:45, Antoine Beaupré wrote:
>> >> On 2023-10-11 22:30:16, Kyle Fazzari wrote:
>> >>> On 10/11/23 19:24, Antoine Beaupré wrote:
>> >> 
>> >> [...]
>> >> 
>> >>> Yeah I won't lie, my immediate thought was "huh, I've never seen that
>> >>> happen." Then my follow-up was "actually, how would I even know?" But at
>> >>> the same time, I could make that argument for a lot of collectors! Is
>> >>> there an established pattern for gathering this kind of data?
>> >> 
>> >> Filing a timestamp and duration of the last run is typical.
>> >
>> > Very good.
>> >
>> > By the way, I came across this Ubuntu bug today, which sounds eerily 
>> > familiar, no?
>> >
>> >  https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2003851
>> 
>> Oh wow, so that would mean a bug in APT itself. And a regression too,
>> because we certainly never witnessed this in buster or bullseye...
>> 
>> I wonder if we should clone this bug into apt...
>
> If you use apt-cacher-ng, stop using it. apt is *not* compatible
> with apt-cacher-ng. We already have bugs for that, and the only
> way things will change is if we gets https HTTP/2 on the mirrors
> and then can switch to libcurl.

We are not using apt-cacher-ng, and are now seeing this problem with
unattended-upgrades as well.

> Also please do not run apt update in the background or try to
> calculate dist upgrades, that is evil and you're breaking stuff.
> If you want to check for updates, make sure the periodic apt service
> is configured to run. You are entitled to one run per day. If you
> do not operate the mirror infrastructure please do not run your own
> updates out of band.

I agree this is a little odd and that the prometheus apt plugin should
probably not be the one handling the cache update.

What's the magic setting to make apt check those updates on its own? I
often get confused between unattended-upgrades and apt there...

> Then you may calculate the upgrade, but don't open the cache
> with locking so you don't go block other clients.

Could you expand on this? What's the proper pythonic way of doing this?

The script currently does:

cache = apt.cache.Cache()
with contextlib.suppress(apt.cache.LockFailedException, 
apt.cache.FetchFailedException):
cache.update()

cache.open()
cache.upgrade(True)

What's the locking part here? Is this sufficient?

cache = apt.cache.Cache()

> Generally speaking it is likely that we will come up with a daemon
> on the road to Ubuntu 26.04 that you can ask to check for updates
> if it hasn't (again please don't if you don't own your infra) and
> then query for available upgrades; but it's nothing for the next 12 months.

Okay, that makes sense. So the Debian package here clearly has a bug
because it hits those mirrors every 15 minutes, that's definitely
something that needs to change.

> Also Kyle's emails don't arrive at all, well one did in the
> entire thread.

I'm not sure what to say about this... I don't have access to either
Kyle's, Ubuntu's or Debian.org infrastructure to diagnose this... Would
you prefer we move this discussion in the GitHub issue tracker or the
Launchpad issue?

Thanks for your feedback!

-- 
The reasonable man adapts himself to the world.
The unreasonable man persists in trying to adapt the world to himself.
Therefore, all progress depends on the unreasonable man.
- George Bernard Shaw

Bug#1053761: bullseye-pu: package llvm-toolchain-16/16.0.6-15~deb11u1

[Andres Salomon]

On Fri, Oct 13 2023 at 02:59:08 PM +01:00:00, Adam D. Barratt 
 wrote:

On Wed, 2023-10-11 at 06:37 +0100, Adam D. Barratt wrote:

 Control: tags -1 + confirmed

 On Tue, 2023-10-10 at 12:21 -0400, Andres Salomon wrote:
 > Chromium newest version FTBFS on bullseye with clang-13, but works
 > fine with clang-16.
 >


[...]

 Please go ahead.



Unfortunately the package isn't getting built anywhere, because it
Build-Depends on llvm-spirv-16, which also isn't in bullseye.

How did you manage to build the amd64 upload for NEW?



I don't have llvm-spirv-16 installed in the container where I built it, 
but I do have the 'hello' package installed. It looks like that's not 
going to work for i386 though, so shall I also build/upload 
llvm-spirv-16? Alternatively, it looks like an unreleased version of 
clang-16 (1:16.0.6-16) has changed the build-dep to allow for 
llvm-spirv-14 or llvm-spirv-15 
(https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/9af30d9926b6e93580262310fa652d19fcc15869). 
I could try changing the build-dep to the clang-11 and clang-13 
equivalent of 'llvm-spirv' and uploading llvm-toolchain-16 
1:16.0.6-15~deb11u2.

Bug#1050603: syncthing: Reenable QUIC feature

[Thomas Butz]

You should be able to avoid future go version incompatibilities by upgrading to 
syncthing >=1.24.0. The quic-go library shipped with these versions no longer 
forks crypto/tls.

Bug#1053886: apt autoremove removes old kernel (ignoring default configuration)

[Miguel A. Rojas]

Hi there,

I think this could be related to the fact that current kernel packages 
naming convention don't match the regular expression in 
/etc/apt/apt.conf.d/01autoremove.


There are some '.' that the regular expression doesn't take care of.

NeverAutoRemove
 {
   "^firmware-linux.*";
   "^linux-firmware$";
   "^linux-image-[a-z0-9]*$";
   "^linux-image-[a-z0-9]*-[a-z0-9]*$";
 };

Regards

Bug#1053812: Pretty sure #1053812 is fixed in 4.2

[Russ Allbery]

Jonathan Kamens  writes:

> So, Russ sent me his apt-listchanges database and I took a lot at it and
> it was very messed up.

> There was a bug in 4.1 which was uncovered and fixed a couple of days ago
> as a result of Alexandre Detiste's push to add typing hints to the
> program. This bug would have caused the type of corruption that I saw in
> Russ's database, so I'm pretty sure it will go away in 4.2.

I installed 4.2 locally and then did an apt upgrade and everything worked
correctly, so I am also hopeful.  4.2 is on its way to experimental now.

-- 
Russ Allbery (r...@debian.org)  

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Julian Andres Klode]

On Fri, Oct 13, 2023 at 10:29:10AM -0400, Antoine Beaupré wrote:
> On 2023-10-12 21:25:20, Kyle Fazzari wrote:
> > On 10/11/23 22:45, Antoine Beaupré wrote:
> >> On 2023-10-11 22:30:16, Kyle Fazzari wrote:
> >>> On 10/11/23 19:24, Antoine Beaupré wrote:
> >> 
> >> [...]
> >> 
> >>> Yeah I won't lie, my immediate thought was "huh, I've never seen that
> >>> happen." Then my follow-up was "actually, how would I even know?" But at
> >>> the same time, I could make that argument for a lot of collectors! Is
> >>> there an established pattern for gathering this kind of data?
> >> 
> >> Filing a timestamp and duration of the last run is typical.
> >
> > Very good.
> >
> > By the way, I came across this Ubuntu bug today, which sounds eerily 
> > familiar, no?
> >
> >  https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2003851
> 
> Oh wow, so that would mean a bug in APT itself. And a regression too,
> because we certainly never witnessed this in buster or bullseye...
> 
> I wonder if we should clone this bug into apt...

If you use apt-cacher-ng, stop using it. apt is *not* compatible
with apt-cacher-ng. We already have bugs for that, and the only
way things will change is if we gets https HTTP/2 on the mirrors
and then can switch to libcurl.

Also please do not run apt update in the background or try to
calculate dist upgrades, that is evil and you're breaking stuff.
If you want to check for updates, make sure the periodic apt service
is configured to run. You are entitled to one run per day. If you
do not operate the mirror infrastructure please do not run your own
updates out of band.

Then you may calculate the upgrade, but don't open the cache
with locking so you don't go block other clients.

Generally speaking it is likely that we will come up with a daemon
on the road to Ubuntu 26.04 that you can ask to check for updates
if it hasn't (again please don't if you don't own your infra) and
then query for available upgrades; but it's nothing for the next 12 months.

Also Kyle's emails don't arrive at all, well one did in the
entire thread.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1053886: apt autoremove removes old kernel (ignoring default configuration)

[Miguel Angel]

Package: apt
Version: 2.7.3
Severity: normal
X-Debbugs-Cc: mianro...@gmail.com

Beside the fact that kernel packages should not removed by default
(according to /etc/apt/apt.conf.d/01autoremove), older kernel packages are 
removed
after executing 'apt autoremove'.

Regards

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
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:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || 
true; fi";
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 "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::netrc "auth.conf";
Dir::Etc::netrcparts "auth.conf.d";
Dir::Etc::parts "apt.conf.d";
Dir::Etc::preferences "preferences";
Dir::Etc::preferencesparts "preferences.d";
Dir::Etc::trusted "trusted.gpg";
Dir::Etc::trustedparts "trusted.gpg.d";
Dir::Etc::apt-file-main "apt-file.conf";
Dir::Bin "";
Dir::Bin::methods "/usr/lib/apt/methods";
Dir::Bin::solvers "";
Dir::Bin::solvers:: "/usr/lib/apt/solvers";
Dir::Bin::planners "";

Bug#1053885: manpages generation for many commands is flawed

[Osamu Aoki]

Source: lxd
Version: 5.0.2-5
Severity: normal
Tags: upstream

Problem: 

Manpages of lxd-client are sometimes unintelligible.  For example:

```
$ man lxc launch
LXD - Command line client(1)   LXD - Command line client(1)

NAME
   lxc-launch - Create and start instances from images

SYNOPSIS
   lxc launch [:] [:][] [flags]
...
Auto generated by spf13/cobra  May 2023  LXD - Command line client(1)
```

Please compare odd SYNOPSIS in the above manpage with `-h` option result
of the command as below..

```
$ lxc launch -h
Description:
  Create and start instances from images

Usage:
  lxc launch [:] [:][] [flags]
...
```

Proposed interim fix:

Add README.Debian for affected binary packages mentioning manpaage
problem and guide people to use `-h` option with command to get
intelligible help.

Speculated root cause and fix path:

As noted at the bottom of manpage, this is generated from help message
of the corresponding command.  I don't know how exacly it process help
message but it processing seems to drop words between "<" and ">".

If plain text markup is converted to XML and then passed to xml2man or
xmlto type processor, this kind of problem may happen unless "<" and ">"
are escaped properly before their processing.

I understand this is upstream problem but I don't know where to send
this bug report due to lxd and incus situation.  This is probably needs
fix to the manpage generation script or rewrite all manpage without
problematic "<" and ">".

Osamu

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

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

Bug#1053866: transition: jpeg-xl

[Mathieu Malaterre]

On Fri, Oct 13, 2023 at 11:57 AM Sebastian Ramacher
 wrote:
>
> Control: tags -1 moreinfo
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-jpeg-xl.html
>
> On 2023-10-13 10:44:31 +0200, Mathieu Malaterre wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> > This is a minor SONAME transiton. Two (unused anywhere) symbols were
> > removed.
>
> Are the reverse dependencies known to build with the new version?

Nope. I've requested an account on debomatic-amd64 to run the following:

% cat jxl.commands
rebuild ffmpeg_7:6.0-7 unstable experimental
rebuild geeqie_1:2.1-1 unstable experimental
rebuild gimp_2.10.34-1 unstable experimental
rebuild graphicsmagick_1.4+really1.3.42-1 unstable experimental
rebuild imlib2_1.12.1-1 unstable experimental
rebuild kimageformats_5.107.0-3 unstable experimental
rebuild krita_1:5.2.0+dfsg-1 unstable experimental
rebuild swayimg_1.12-1 unstable experimental
rebuild vips_8.14.5-1 unstable experimental
rebuild webkit2gtk_2.42.1-2 unstable experimental
rebuild wpewebkit_2.42.1-1 unstable experimental


will post back when I get access.

Thanks !

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Johannes Schauer Marin Rodrigues]

Hi,

On Wed, 14 Sep 2022 12:29:13 +0200 Pascal Hambourg  
wrote:
> Sorry to insist, but IMO this issue should really be worked out. I once
> suggested the following simple formula :
> 
>  max swap size = min(RAM size, disk space * R)
> 
> with R being a ratio between 0 and 100% to be defined.
> 
> For example with R=5%, the swap size would be limited to either the RAM size
> or 5% of available disk space, whichever is lower.
> 
> Doesn't that sound reasonable for most setups, at least more than the current
> formula ?

the default partitioning scheme now has made hibernation impossible for three
whole stable releases. I have no experience in writing d-i code but just so
that *something* happens I submitted this merge request to partman-auto:

https://salsa.debian.org/installer-team/partman-auto/-/merge_requests/12

This MR keeps the partman-auto/cap-ram setting because it has now been in
partman-auto for so long that likely other users of d-i have started depending
on its existence. Instead, I raised the limit imposed by partman-auto/cap-ram
while at the same time adding a new setting I called partman-auto/perc-ram
which (if I'm reading the code correctly) should cap the swap size at X percent
of the remaining free disk space. This way, d-i should continue to work even in
situations where there is more RAM than disk space for which commit 7966fcd was
designed in the first place.

This is a draft MR because it is untested. Maybe somebody could help and review
and test it.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Antoine Beaupré]

On 2023-10-12 21:25:20, Kyle Fazzari wrote:
> On 10/11/23 22:45, Antoine Beaupré wrote:
>> On 2023-10-11 22:30:16, Kyle Fazzari wrote:
>>> On 10/11/23 19:24, Antoine Beaupré wrote:
>> 
>> [...]
>> 
>>> Yeah I won't lie, my immediate thought was "huh, I've never seen that
>>> happen." Then my follow-up was "actually, how would I even know?" But at
>>> the same time, I could make that argument for a lot of collectors! Is
>>> there an established pattern for gathering this kind of data?
>> 
>> Filing a timestamp and duration of the last run is typical.
>
> Very good.
>
> By the way, I came across this Ubuntu bug today, which sounds eerily 
> familiar, no?
>
>  https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2003851

Oh wow, so that would mean a bug in APT itself. And a regression too,
because we certainly never witnessed this in buster or bullseye...

I wonder if we should clone this bug into apt...

a.
-- 
The illusion of freedom will continue as long as it's profitable to
continue the illusion. At the point where the illusion becomes too
expensive to maintain, they will just take down the scenery, they will
pull back the curtains, they will move the tables and chairs out of
the way and you will see the brick wall at the back of the theater.
 - Frank Zappa

Bug#1031572: Homepage addition is pending

[Andreas Beckmann]

Control: reopen -1

On Sun, 27 Aug 2023 12:48:52 +1200 Andrew Ruthven  wrote:

Version: 3.01-1

I added a Homepage line to d/control in version 3.01-1, currently in
experimental, but will be uploaded to unstable shortly.


No such package version reached experimental or sid, yet.


Andreas

Bug#1053881: tracker-miners: CVE-2023-5557

[Jeremy Bícha]

Control: fixed -1 3.4.5-1
Control: block -1 by 1053238

On Fri, Oct 13, 2023 at 9:27 AM Moritz Mühlenhoff  wrote:
> The following vulnerability was published for tracker-miners.
>
> CVE-2023-5557[0]:

My first attempt at packaging the update for Unstable ran into build
test failures on 32-bit architectures and ppc64el.

Thank you,
Jeremy Bícha

Bug#1053761: bullseye-pu: package llvm-toolchain-16/16.0.6-15~deb11u1

[Adam D. Barratt]

On Wed, 2023-10-11 at 06:37 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2023-10-10 at 12:21 -0400, Andres Salomon wrote:
> > Chromium newest version FTBFS on bullseye with clang-13, but works
> > fine with clang-16.
> > 
> 
[...]
> Please go ahead.
> 

Unfortunately the package isn't getting built anywhere, because it
Build-Depends on llvm-spirv-16, which also isn't in bullseye.

How did you manage to build the amd64 upload for NEW?

Regards,

Adam

Bug#1043404: Acknowledgement (with linux 6.4.4 mariadbd is at 100% wait for one cpu)

[Séverine Wiltgen]

Hello,

I have the same problem again but this time with kernel 
linux-image-6.5.0-1-amd64  6.5.3-1


uname -a gives
Linux 6.5.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.5.3-1 (2023-09-13) 
x86_64 GNU/Linux


This time, no need to run any particular services, the server is a fresh 
install with no added packages (no mariadb running). In a top, i can see 
this, the process which uses cpu is scsi_eh_1.


%Cpu0  :  0.0 us,  2.7 sy,  0.0 ni,  0.0 id, 97.3 wa,  0.0 hi,  0.0 si, 
0.0 st
%Cpu1  :  0.3 us,  0.3 sy,  0.0 ni, 68.1 id, 30.9 wa,  0.0 hi,  0.3 si, 
0.0 st

MiB Mem :   3913.1 total,   3643.2 free,323.7 used,127.2 buff/cache
MiB Swap:976.0 total,976.0 free,  0.0 used.   3589.3 avail Mem

PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ 
COMMAND
170 root  20   0   0  0  0 D  67.4   0.0   3:18.88 
scsi_eh_1


This appears just after a reboot, there are no running commands  writing 
to disk.


When I reboot on the previous kernel (linux-image-6.4.0-4-amd64 
6.4.13-1), I don't have the same issue.
I have this problem on several servers, but I am not sure this is the 
same issue than my firt report. A google search with scsi_eh_1 high cpu 
use shows this bug for example

https://lore.kernel.org/all/7611d95d0aada3814a5b140661b3b5188b8b86bb.ca...@redhat.com/T/

Thanks,
--
Séverine Wiltgen
0658739663
Administratrice Système
Pôle exploitation
Conformément à la charte du droit à la déconnexion de Mediapart,
les mails envoyés le soir, la nuit, ou le weekend n’appellent pas de 
réponse immédiate.

Bug#1053884: libjettison-java: CVE-2023-5072

[Moritz Mühlenhoff]

Source: libjettison-java
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libjettison-java.

CVE-2023-5072[0]:
| Denial of Service  in JSON-Java versions up to and including
| 20230618.  A bug in the parser means that an input string of modest
| size can lead to indefinite amounts of memory being used.

https://github.com/stleary/JSON-java/issues/758
https://github.com/stleary/JSON-java/issues/771
https://github.com/stleary/JSON-java/pull/772/


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-5072
https://www.cve.org/CVERecord?id=CVE-2023-5072

Please adjust the affected versions in the BTS as needed.

Bug#1053883: jenkins-json: CVE-2023-5072

[Moritz Mühlenhoff]

Source: jenkins-json
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for jenkins-json.

CVE-2023-5072[0]:
| Denial of Service  in JSON-Java versions up to and including
| 20230618.  A bug in the parser means that an input string of modest
| size can lead to indefinite amounts of memory being used.

https://github.com/stleary/JSON-java/issues/758
https://github.com/stleary/JSON-java/issues/771
https://github.com/stleary/JSON-java/pull/772/


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-5072
https://www.cve.org/CVERecord?id=CVE-2023-5072

Please adjust the affected versions in the BTS as needed.

Bug#1053882: libjson-java: CVE-2023-5072

[Moritz Mühlenhoff]

Source: libjson-java
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libjson-java.

CVE-2023-5072[0]:
| Denial of Service  in JSON-Java versions up to and including
| 20230618.  A bug in the parser means that an input string of modest
| size can lead to indefinite amounts of memory being used.

https://github.com/stleary/JSON-java/issues/758
https://github.com/stleary/JSON-java/issues/771
https://github.com/stleary/JSON-java/pull/772/


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-5072
https://www.cve.org/CVERecord?id=CVE-2023-5072

Please adjust the affected versions in the BTS as needed.

Bug#1053881: tracker-miners: CVE-2023-5557

[Moritz Mühlenhoff]

Source: tracker-miners
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for tracker-miners.

CVE-2023-5557[0]:
| A flaw was found in the tracker-miners package. A weakness in the
| sandbox allows a maliciously-crafted file to execute code outside
| the sandbox if the tracker-extract process has first been
| compromised by a separate vulnerability.

https://gitlab.gnome.org/GNOME/tracker-miners/-/issues/277
https://gitlab.gnome.org/GNOME/tracker-miners/-/merge_requests/480

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-5557
https://www.cve.org/CVERecord?id=CVE-2023-5557

Please adjust the affected versions in the BTS as needed.

Bug#1053878: gpac: CVE-2023-42298 CVE-2023-5520

[Moritz Mühlenhoff]

Source: gpac
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for gpac.

CVE-2023-42298[0]:
| An issue in GPAC GPAC v.2.2.1 and before allows a local attacker to
| cause a denial of service via the Q_DecCoordOnUnitSphere function of
| file src/bifs/unquantize.c.

https://github.com/gpac/gpac/issues/2567
https://github.com/gpac/gpac/commit/16c4fafc2881112eba7051cac48f922eb2b94e06

CVE-2023-5520[1]:
| Out-of-bounds Read in GitHub repository gpac/gpac prior to 2.2.2.

https://huntr.dev/bounties/681e42d0-18d4-4ebc-aba0-c5b0f77ac74a
https://github.com/gpac/gpac/commit/5692dc729491805e0e5f55c21d50ba1e6b19e88e


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-42298
https://www.cve.org/CVERecord?id=CVE-2023-42298
[1] https://security-tracker.debian.org/tracker/CVE-2023-5520
https://www.cve.org/CVERecord?id=CVE-2023-5520

Please adjust the affected versions in the BTS as needed.

Bug#1053880: node-babel7: CVE-2023-45133

[Moritz Mühlenhoff]

Source: node-babel7
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for node-babel7.

CVE-2023-45133[0]:
| Babel is a compiler for writingJavaScript. In `@babel/traverse`
| prior to versions 7.23.2 and 8.0.0-alpha.4 and all versions of
| `babel-traverse`, using Babel to compile code that was specifically
| crafted by an attacker can lead to arbitrary code execution during
| compilation, when using plugins that rely on the `path.evaluate()`or
| `path.evaluateTruthy()` internal Babel methods. Known affected
| plugins are `@babel/plugin-transform-runtime`; `@babel/preset-env`
| when using its `useBuiltIns` option; and any "polyfill provider"
| plugin that depends on `@babel/helper-define-polyfill-provider`,
| such as `babel-plugin-polyfill-corejs3`, `babel-plugin-polyfill-
| corejs2`, `babel-plugin-polyfill-es-shims`, `babel-plugin-polyfill-
| regenerator`. No other plugins under the `@babel/` namespace are
| impacted, but third-party plugins might be. Users that only compile
| trusted code are not impacted. The vulnerability has been fixed in
| `@babel/traverse@7.23.2` and `@babel/traverse@8.0.0-alpha.4`. Those
| who cannot upgrade `@babel/traverse` and are using one of the
| affected packages mentioned above should upgrade them to their
| latest version to avoid triggering the vulnerable code path in
| affected `@babel/traverse` versions: `@babel/plugin-transform-
| runtime` v7.23.2, `@babel/preset-env` v7.23.2, `@babel/helper-
| define-polyfill-provider` v0.4.3, `babel-plugin-polyfill-corejs2`
| v0.4.6, `babel-plugin-polyfill-corejs3` v0.8.5, `babel-plugin-
| polyfill-es-shims` v0.10.0, `babel-plugin-polyfill-regenerator`
| v0.5.3.

https://github.com/babel/babel/security/advisories/GHSA-67hx-6x53-jw92
https://github.com/babel/babel/pull/16033
https://github.com/babel/babel/commit/b13376b346946e3f62fc0848c1d2a23223314c82


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-45133
https://www.cve.org/CVERecord?id=CVE-2023-45133

Please adjust the affected versions in the BTS as needed.

Bug#1053879: node-undici: CVE-2023-45143

[Moritz Mühlenhoff]

Source: node-undici
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for node-undici.

CVE-2023-45143[0]:
| Undici is an HTTP/1.1 client written from scratch for Node.js. Prior
| to version 5.26.2, Undici already cleared Authorization headers on
| cross-origin redirects, but did not clear `Cookie` headers. By
| design, `cookie` headers are forbidden request headers, disallowing
| them to be set in RequestInit.headers in browser environments. Since
| undici handles headers more liberally than the spec, there was a
| disconnect from the assumptions the spec made, and undici's
| implementation of fetch. As such this may lead to accidental leakage
| of cookie to a third-party site or a malicious attacker who can
| control the redirection target (ie. an open redirector) to leak the
| cookie to the third party site. This was patched in version 5.26.2.
| There are no known workarounds.

https://github.com/nodejs/undici/security/advisories/GHSA-wqq4-5wpv-mx2g
https://github.com/nodejs/undici/security/advisories/GHSA-q768-x9m6-m9qp
https://github.com/nodejs/undici/commit/e041de359221ebeae04c469e8aff4145764e6d76


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-45143
https://www.cve.org/CVERecord?id=CVE-2023-45143

Please adjust the affected versions in the BTS as needed.

Bug#1053877: zabbix: CVE-2023-32721 CVE-2023-32722 CVE-2023-32723 CVE-2023-32724

[Moritz Mühlenhoff]

Source: zabbix
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for zabbix.

CVE-2023-32721[0]:
| A stored XSS has been found in the Zabbix web application in the
| Maps element if a URL field is set with spaces before URL.

https://support.zabbix.com/browse/ZBX-23389

CVE-2023-32722[1]:
| The zabbix/src/libs/zbxjson module is vulnerable to a buffer
| overflow when parsing JSON files via zbx_json_open.

https://support.zabbix.com/browse/ZBX-23390

CVE-2023-32723[2]:
| Request to LDAP is sent before user permissions are checked.

https://support.zabbix.com/browse/ZBX-23230

CVE-2023-32724[3]:
| Memory pointer is in a property of the Ducktape object. This leads
| to multiple vulnerabilities related to direct memory access and
| manipulation.

https://support.zabbix.com/browse/ZBX-23391

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-32721
https://www.cve.org/CVERecord?id=CVE-2023-32721
[1] https://security-tracker.debian.org/tracker/CVE-2023-32722
https://www.cve.org/CVERecord?id=CVE-2023-32722
[2] https://security-tracker.debian.org/tracker/CVE-2023-32723
https://www.cve.org/CVERecord?id=CVE-2023-32723
[3] https://security-tracker.debian.org/tracker/CVE-2023-32724
https://www.cve.org/CVERecord?id=CVE-2023-32724

Please adjust the affected versions in the BTS as needed.

Bug#985260:

[c . buhtz]

Dear Francesco,

can you please have a look at the latest upstream release of Back In 
Time. Upstream assumes the problem is solved. Can you confirm this?


Kind
Christian

Bug#1053876: Update package ignition

[Senkel, Christoph]

Package: ignition
Version: 2.16.2

Please update the package to its latest (2.16.2) upstream version. This version 
has a new dependency on golang-github-containers-libhvee.
https://salsa.debian.org/chrinorse/ignition

--
Christoph Senkel
Professional Service Consultant
+49 2166 9901-193 phone
christoph.sen...@netapp.com
www.netapp.de
 
Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen 
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail 
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und 
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte 
Weitergabe dieser E-Mail und ihrer Inhalte sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are 
not the intended addressee or have received this e-mail in error, please notify 
the sender immediately and destroy this e-mail. Any unauthorized copying, 
disclosure or distribution of the material in this e-mail is strictly forbidden.

NetApp Deutschland GmbH, Karl-Hammerschmidt-Str. 1, 85609 Aschheim,
Handelsregister: AG München HRB113907, VAT#: DE 182 196 996,
Geschäftsführer: Peter Wüst, James McGowan

Bug#1053875: Add package golang-github-containers-libhvee to repository

[Senkel, Christoph]

Package: golang-github-containers-libhvee
Version: 0.4.0

The package is currently missing in Debian. The latest version of ignition 
(2.16.2) has a dependency on libhvee.
Please add the package.
https://salsa.debian.org/chrinorse/golang-github-containers-libhvee

--
Christoph Senkel
Professional Service Consultant
+49 2166 9901-193 phone
christoph.sen...@netapp.com
www.netapp.de
 
Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen 
enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail 
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und 
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte 
Weitergabe dieser E-Mail und ihrer Inhalte sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are 
not the intended addressee or have received this e-mail in error, please notify 
the sender immediately and destroy this e-mail. Any unauthorized copying, 
disclosure or distribution of the material in this e-mail is strictly forbidden.

NetApp Deutschland GmbH, Karl-Hammerschmidt-Str. 1, 85609 Aschheim,
Handelsregister: AG München HRB113907, VAT#: DE 182 196 996,
Geschäftsführer: Peter Wüst, James McGowan

Bug#1053874: slurm-wlm: Discussion of compile-time interdependencies

[zhangdandan]

Package: slurm-wlm
Version: 23.02.5-1
Severity: wishlist
Tags: ftbfs
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Phenomenon I noticed while following the BD-Uninstallable list in Debian 
Package Auto-Building environment [1].

- hdf5 build-depends on missing: libmpich-dev:loong64
Please see the link [2].
- mpich build-depends on missing: libslurm-dev:loong64
Please see the link [3].
- slurm-wlm build-depends on missing: hdf5-helpers:loong64
Please see the link [4].

Please pay attention to the above interdependencies phenomenon.
After analyzing, I've compiled the slurm-wlm's unreleased version 
without the dependencies packages of hdf5. And updated to debian ports 
pool-loong64 repository.


Your suggestions are welcome.
If the friends in Debian community have any questions, can contact me 
anytime.



[1]:https://buildd.debian.org/status/architecture.php?a=loong64=sid
[2]:https://buildd.debian.org/status/package.php?p=hdf5=sid
[3]:https://buildd.debian.org/status/package.php?p=mpich=sid
[4]:https://buildd.debian.org/status/package.php?p=slurm-wlm=sid

thanks,
Dandan Zhang

Bug#1053867: Adding cols info to table break PDF generation

[Petter Reinholdtsen]

I just discovered that xsltproc and fop are able to process this table.
Here is an updated Makefile to demonstrate it:

cat > Makefile << EOF
all: tabell.pdf tabell-fop.pdf

tabell.xml: tabell.adoc
asciidoctor -b docbook5 -d book tabell.adoc
tabell.pdf: tabell.xml
dblatex tabell.xml

tabell-fop.fo: tabell.xml
xsltproc --output tabell-fop.fo ../data/stylesheet-fo.xsl tabell.xml 
tabell-fop.pdf: tabell-fop.fo
fop -c ../data/fop-params.xconf -fo tabell-fop.fo -pdf tabell-fop.pdf 
EOF

-- 
Happy hacking
Petter Reinholdtsen

Bug#1053873: cronie: Crond with high load after 19-01-2038

[Tony de Goede]

Package: cronie
Version: cron
Severity: serious
Justification: linux system unstable

Dear Maintainer,

   When setting the time to 19 Jan 2038 3:14 GMT using "date 011903142038"
the crond gets high load.

   Inspection of the cronie code, the meanloop of cron is controlled by a
time value that becomes buggie after 0x7fff (19/01/2038)
   Probably cron_sleep is wrong. The actual sleep() is never called after
2038
   The time is used to calculate the delay value but when used as unsigned
the value becomes negative.
   it will continously run in the loop causing a high load of the cron
daemon.

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

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

Bug#1053872: systemd with high load after 19-01-2038

[Tony de Goede]

Package: systemd
Version: 252.12-1~deb12u1
Severity: serious
Justification: linux system unstable

Dear Maintainer,

   When setting the time to 19 Jan 2038 3:14 GMT using "date 011903142038"
the systemd gets high load.
   At 7 seconds after 3:14 the date is correct in the kernel but systemd
   get high load.
   After disable systemd-journald the error from systemd is reported to
   console: "Time has been changed"
   Inspection of the systemd code, I found lines in manager.c and others
   calling timerfd_settime using struct itimerspec with seconds set to
TIME_T_MAX.
   The define TIME_T_MAX is 0x7fff which is used to set a time which
   blocks the call until an event triggers the timer. The TIME_T_MAX is
19/01/2038 3:14:07.
   After 2038 this define does not work for ABS_TIME in settime.
   Implementation of a blocked timer is wrong using this TIME_T_MAX in
ABS_TIME value.
   Create a timeout relative to current time or calculate a better
   absolute time.


-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  libacl12.3.1-3
ii  libaudit1  1:3.0.9-1
ii  libblkid1  2.38.1-5+b1
ii  libc6  2.36-9+deb12u1
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-4~deb12u1
ii  libfdisk1  2.38.1-5+b1
ii  libgcrypt201.10.1-3
ii  libkmod2   30+20221128-1
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.1-0.2
ii  libmount1  2.38.1-5+b1
ii  libp11-kit00.24.1-2
ii  libseccomp22.5.4-1+b3
ii  libselinux13.4-1+b6
ii  libssl33.0.9-1
ii  libsystemd-shared  252.12-1~deb12u1
ii  libsystemd0252.12-1~deb12u1
ii  libzstd1   1.5.4+dfsg2-5
ii  mount  2.38.1-5+b1

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.8-2~deb12u1
ii  systemd-timesyncd [time-daemon]  252.12-1~deb12u1

Versions of packages systemd suggests:
ii  libfido2-11.12.0-2+b1
ii  libqrencode4  4.1.1-1
ii  libtss2-esys-3.0.2-0  3.2.1-3
ii  libtss2-mu0   3.2.1-3
ii  libtss2-rc0   3.2.1-3
ii  policykit-1   122-3
ii  polkitd   122-3
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.8-2~deb12u1
pn  dracut 
ii  initramfs-tools0.142
ii  libnss-systemd 252.12-1~deb12u1
ii  libpam-systemd 252.12-1~deb12u1
ii  udev   252.12-1~deb12u1

-- no debconf information

Bug#1053867: Acknowledgement (Adding cols info to table break PDF generation)

[Petter Reinholdtsen]

Note, this is quite similar to https://bugs.debian.org/1053149 >.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1053871: virt-viewer becomes unresponsive when a Display is removed

[Jonas Andradas]

Package: virt-viewer
Version: 11.0-3
Severity: normal
X-Debbugs-Cc: j.andra...@gmail.com

Dear Maintainer,

When interacting with a virtual machine using virt-viewer, a secondary display
can be added, which acts as a second monitor within the VM.

However, if this display is removed from virt-viewer using its menu, virt-
viewer becomes unresponsive: it is not possible to interact with the menus,
manage the window or interact with the VM (through virt-viewer).

It should be noted that the VM is not hang or frozen: if one opens virt-manager
and accesses the VM, this forces a disconnection from virt-viewer (which
closes) and the VM is running fine. The virt-manager window with the VM could
be closed then, and virt-viewer re-opened, allowing in further interaction to
proceed normally.


Thanks,
Jonas.


-- System Information:
Distributor ID: Ubuntu
Description:Ubuntu 22.04.2 LTS
Release:22.04
Codename:   jammy
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_AUX
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 virt-viewer depends on:
ii  libc6   2.37-12
ii  libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1
ii  libglib2.0-02.78.0-2
ii  libgtk-3-0  3.24.38-5
ii  libgtk-vnc-2.0-01.3.1-1
ii  libgvnc-1.0-0   1.3.1-1
ii  libpango-1.0-0  1.51.0+ds-2
ii  libspice-client-glib-2.0-8  0.42-2
ii  libspice-client-gtk-3.0-5   0.42-2
ii  libvirt-glib-1.0-0  4.0.0-3
ii  libvirt09.8.0-1
ii  libvte-2.91-0   0.74.0-2
ii  libxml2 2.9.14+dfsg-1.3

virt-viewer recommends no packages.

Versions of packages virt-viewer suggests:
ii  netcat-openbsd [netcat]  1.225-1
ii  netcat-traditional [netcat]  1.10-47

-- debconf-show failed

Bug#1053870: CVE-2023-42118: integer underflow in libspf2 resulting in RCE

[Bert Van de Poel]

Package: libspf2-2
Version: 1.2.10-7.1~deb11u1
Severity: critical
Tags: security patch
Justification: root security hole
X-Debbugs-Cc: Debian Security Team 


As already outlined on 
https://security-tracker.debian.org/tracker/CVE-2023-42118 there's a known 
security issue in libspf2 found through a security review of Exim by the Zero 
Day Initiative. An integer underflow in libspf2 was found which can be used to 
perform RCEs. A patch on https://github.com/shevek/libspf2/pull/44 is available 
and has been merged into the main repository. All relevant links are already 
available on the Debian Security Tracker.

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

Kernel: Linux 5.10.0-25-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set 
LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libspf2-2 depends on:
ii  libc6  2.31-13+deb11u7

libspf2-2 recommends no packages.

libspf2-2 suggests no packages.

-- debconf information excluded

Bug#1053852: btrfsd: Segfault in libgobject-2.0.so.0.7800.0[7fcec2dff000+34000]

[Vincent Blut]

Package: btrfsd
Version: 0.2.0-1
Followup-For: Bug #1053852

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: tags -1 fixed-upstream

Hi Matthias,

I built btrfsd with 59145f1 (utils: Don't free result twice when checking if 
device is on
battery) applied, that fixes the issue. Thanks!

Have a good day,
Vincent

-BEGIN PGP SIGNATURE-

iHUEARYKAB0WIQSRJQjHKbAUfuoc+DAQn1qAt/bgAQUCZSkWGgAKCRAQn1qAt/bg
AeIwAQDwHqQfIi2iEr3HUORgLk1CNXknX3VdaP90pxPg3p3jzwD8DBPwjqqHqUsr
b6LXQ0VKKNxqb9dJ04cB6Fzljh8NWg8=
=C4ko
-END PGP SIGNATURE-

Bug#1053869: alsa-ucm-conf: Devices profiles using ucm2/common/pcm/split.conf won't load (undefined var)

[Clément Hermann]

Package: alsa-ucm-conf
Version: 1.2.10-1
Severity: normal
Tags: upstream

Dear Alsa team,

Since 1.2.10, profiles using ucm2/common/pcm/split.conf won't load (at
least on Arturia Minifuse 1 and 2, and Motu M4). As a result, for cards
with more than 2 outputs, the default surround profile is loaded instead.

```
~$ alsaucm listcards
ALSA lib ucm_subs.c:807:(uc_mgr_get_substituted_value) variable 
'${var:__Device}' is not defined in this context!
ALSA lib parser.c:2024:(parse_verb_file) error: 
/USB-Audio/Arturia/Minifuse-12-HiFi.conf failed to parse device
ALSA lib main.c:1554:(snd_use_case_mgr_open) error: failed to import hw:1 use 
case configuration -22
ALSA lib parser.c:2965:(uc_mgr_scan_master_configs) Unable to open '-hw:1': 
Invalid argument
alsaucm: error failed to get card list: Invalid argument
```

Issue is known upstream
(https://github.com/alsa-project/alsa-ucm-conf/issues/346) and fixed by 
https://github.com/alsa-project/alsa-ucm-conf/commit/b68aa52acdd2763fedad5eec0f435fbf43e5ccc6

Applying the change directly in
`/usr/share/alsa/ucm2/common/pcm/split.conf` fixes the issue (hence the
local modification reported by reportbug). I guess the next release of
alsa-ucm-conf will include it, but in the meantime, I suggest applying
it as a patch in Debian.

I can provide a MR on salsa if it helps.

Cheers,

nodens

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

Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 alsa-ucm-conf depends on:
ii  libasound2  1.2.10-1

alsa-ucm-conf recommends no packages.

alsa-ucm-conf suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/alsa/ucm2/common/pcm/split.conf (from 
alsa-ucm-conf package)

Bug#1053866: transition: jpeg-xl

[Sebastian Ramacher]

Control: tags -1 moreinfo
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-jpeg-xl.html

On 2023-10-13 10:44:31 +0200, Mathieu Malaterre wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> This is a minor SONAME transiton. Two (unused anywhere) symbols were
> removed.

Are the reverse dependencies known to build with the new version?

Cheers
-- 
Sebastian Ramacher

Bug#1053551: ftbfs on amd64 when building binary-arch

[Simon Richter]

Hi,

On 10/13/23 03:03, Simon Richter wrote:

makes the problem reproducible even when building with -j2, and 
regardless of whether building _all packages in the same build or not. 
I'll check tomorrow about gcc 13 and if that also happens upstream.


gcc 13 is okay, because of 0bfc503c [1]. This patch does not apply 
cleanly to gcc-12, because gm2 is a separate archive there, and the file 
looks a bit different.


There are a few dependency rules in the file that seem to do the same 
thing, but use the wrong target name, so they are ignored, and this 
doesn't seem to be a complete set anyway. I'm trying with the same 
addition of an order-only dependency that the gcc-13 commit does, if 
that fixes it, that should be good enough for now.


Is the separate Modula2 tree still maintained? For us, the one-line fix 
should probably be sufficient, but from an upstream perspective, this 
should be looked at properly (but might be moot after the merge into 
gcc-13).


   Simon

[1] 
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=00bfc503cc3b3e8f354afeac9b482649418fb70f

Bug#1053868: RFP: IMSProg -- Linux programmer for CH341a devices.

[Mikhail Medvedev]

Package: IMSProg
Severity: Request For Package
IMSProg - Linux IMSProg - I2C, SPI and MicroWire EEPROM/Flash chip 
programmer for CH341a devices.
It supports 24xxx, 25xxx, 93xxx, and 95xxx series chips. IMSProg - 
software with graphical interface based on QT5.

Github: https://github.com/bigbigmdm/IMSProg/
DEB_Package: 
https://github.com/bigbigmdm/IMSProg/tree/main/release/debian_package
I am the developer of this program. Please add IMSProg to the Debian 
repository.


Regards, Mikhail Medvedev

Bug#1053867: Adding cols info to table break PDF generation

[Petter Reinholdtsen]

Package: asciidoctor
Version: 2.0.18-2

I ran into this strange problem while typesetting a book using
asciidoctor.  Is this a problem with asciidoctor or dblatex?

The problem is reproduced using the following shell commands:

cat > tabell.adoc < Makefile <


http://docbook.org/ns/docbook; 
xmlns:xl="http://www.w3.org/1999/xlink; version="5.0" xml:lang="en">

Untitled
2023-10-13




Kjennskap til fristens lengde











Riktig svar

Ikke-kjøpere pst.
A-utvalget pst.
Kjøpere pst.



Kortere enn 10 dager
14
(7)
13
(7)
10
(6)


X
10 dager
32
(15)
37
(19)
57
(37)



14 dager/lengre enn 14 
dager
54
(26)
50
(25)
33
(21)



Sum for de svar som er 
gitt
100

100

100







Prosentbasis
n=617

n=822

n=467




Vet ikke

(24)

(23)

(18)



Har ikke hørt om 
fristen

(28)

(26)

(18)



Sum for alle 
prosentbasis

(n=1297)

(n=1609)

(n=7321)







I do not see anything obviously wrong with this one either.  Any clue
what is going wrong?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1053866: transition: jpeg-xl

[Mathieu Malaterre]

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

This is a minor SONAME transiton. Two (unused anywhere) symbols were
removed.

Current status in exp:
https://buildd.debian.org/status/package.php?p=jpeg-xl=experimental

Thanks

Ben file:

title = "jpeg-xl";
is_affected = .depends ~ "libjxl0.7" | .depends ~ "libjxl0.8";
is_good = .depends ~ "libjxl0.8";
is_bad = .depends ~ "libjxl0.7";

Bug#1053568: ITP: python-lib25519 -- Python wrapper around lib25519 library

[Simon Josefsson]

Hi.  I'm happy to review, co-maintain and sponsor this package.  Initial
review:

- Could you add debian/tests/ infrastructure?

- It installs a "top_level.txt" file, is this intentional?  Lintian
complaint:
I: python3-lib25519: package-contains-documentation-outside-usr-share-doc 
[usr/lib/python3/dist-packages/lib25519-20230630.1.dist-info/top_level.txt]

/Simon


signature.asc
Description: PGP signature

Bug#1053569: ITP: python-mceliece -- Python wrapper around libmceliece library

[Simon Josefsson]

Hi.  I'm happy to review, co-maintain and sponsor this package.  Initial
review:

- Could you add debian/tests/ infrastructure?

- It installs a "top_level.txt" file, is this intentional?  Lintian
complaint: I: python3-mceliece:
package-contains-documentation-outside-usr-share-doc
[usr/lib/python3/dist-packages/mceliece-20230612.1.dist-info/top_level.txt]

/Simon


signature.asc
Description: PGP signature

Bug#1053488: ITP: django-jsonfield -- Reusable JSONField for Django Models

[Raphael Hertzog]

Hello Edward,

On Thu, 05 Oct 2023, Edward Betts wrote:
>   jsonfield is a reusable model field that allows you to store validated JSON,
>   automatically handling serialization to and from the database. It is
>   particularly useful when your app needs to be database-agnostic or when the
>   built-in JSONField's extended querying is not being leveraged.
> 
> This library is a dependancy of the django-bulk-update module.
> 
> I plan to maintain this package as part of the Python team.

It seems a bad idea to me to introduce this library into Debian. Django
has a native JSONField that is database agnostic for a few releases now:
https://docs.djangoproject.com/en/4.2/ref/models/fields/#jsonfield

And I used to maintain an external "jsonfield" already which I recently
removed for that precise reason:
https://tracker.debian.org/pkg/python-django-jsonfield

Thus I think that you should work with django-bulk-update upstream to
make it possible to use Django's native field.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager

[Free Ekanayaka]

Mathias Gibbens  writes:

> On Sun, 2023-10-08 at 12:19 +0100, Free Ekanayaka wrote:
>> It seems that v6 of golang-github-checkpoint-restore-go-criu is in
>> experimental:
>> 
>> https://packages.debian.org/experimental/golang-github-checkpoint-restore-go-criu-dev
>> 
>> Not sure if there are blockers for it to move to unstable (maybe we'd
>> need to drop the patch currently applied to the LXD package?).
>
>   31/35 of the rdeps of golang-github-checkpoint-restore-go-criu build
> fine with v6.3.0 from experimental -- the big blocker is runc. Its most
> recent release (1.1.9) still depends on v5, although in the upstream
> main branch it's been switched to v6. Given that runc is a fundamental
> container library, I'll want to confer with the Go Packaging Team on
> how to move forward with this.
>
>   (And LXD currently has a patch to revert the simple use of go-criu,
> so when v6 lands in unstable that's a simple thing to remove.)

It sounds good to me to use the patch for the Incus package as well, and
remove it later on when the situation unblocks.

>> Once Incus 1.0 LTS is out we could opt for uploading only LTS updates
>> to unstable and development releases to experimental.
>
>   That's the mental idea I've had for LXD as well, although I haven't
> actually done that yet. One of the tricky things would be managing two
> distinct upstream branches (upstream-lts and upstream-dev maybe?) and
> then merging Debian-specific packaging changes from unstable <->
> experimental.

Yeah, maybe something like that.

>
>> >   Just a minor note -- if LXD keeps its established release
>> > schedule, I'm expecting LXD 6.0.x to ship in trixie.
>> 
>> Yes, although I would personally keep Debian's LXD at version 5.0.x
>> for trixie and point users to the lxd-to-incus migration tool, to
>> migrate from LXD 5.0.x to Incus 1.0.x, which should be be a superset
>> of LXD 6.0.x.
>> 
>> That's of course just [my] take, I understand that there might be
>> interest from other DDs/users (e.g. you) to update the Debian's
>> package to LXD 6.0.x.
>
>   With my DD hat on, I don't want to artificially hold back the version
> of LXD in trixie solely to make life easier for Incus -- especially if
> there's a 6.0 LTS release out with plenty of time before freezes start.
> Doing so would be a disservice to users wishing to run LXD and have the
> latest LTS release available in trixie.

Note that LXD's recommended installation way is via snapd, which should
be available in Debian, so Debian users wishing to run 6.0 LTS would
have that option, albeit not "native".

That being said, I certainly understand your reasoning.

>   I know there will be a growing delta between LXD and Incus as time
> goes on, but I would also suspect Incus will want to support migrations
> from newer versions of LXD as best as it can.

Yeah, I think so, I'm just not sure how much that will be practically
feasible, so probably the answer is "it depends". I'll ask Stéphane too
about this. I don't think there's any certainty here, but he should be
able to provide an educated guess about whether Incus 1.0 might be able
to support migrations from LXD 6.0.

>
>> >   Currently in unstable there are only three rdeps of src:raft:
>> > dqlite, golang-github-canonical-go-dqlite, and lxd. So it would
>> > certainly be doable to switch the upstream of src:raft -- if Laszlo
>> > is open to doing so, it should be a pretty easy transition.
>> > Probably the trickiest thing would be the versions: I'd like to
>> > avoid a package epoch bump if possible, and we'd also have to
>> > consider the .so versioning.
>> 
>> Why do think an epoch is needed? I believe it can be done without
>> epochs. Anyway, if the idea gets consenus I'll coordinate with Laszlo
>> about that.
>
>   Looks like you've picked an initial release version of 0.17.7, so I
> guess that side-steps the epoch bump issue in Debian's packaging, but I
> don't know about resetting the .so version back to zero.

Yeah, there was a bit of a mess in the past with .so versions. It should
have been kept to 0 all the way in the first place, and ABI compatibilty
should have not been broken.

>From now on, I'll make sure that the .so version stays at 0 and that all
releases in the 0.x series are backward-compatible both in terms of API
and ABI.

In the long term I plan to eventually have a 1.x series too, which will
likely break ABI compatibility, and require a .so version bump to 1, but
that's relatively far in the future.

> Is there anything in Policy about a "backwards" transition?

I don't think there's any hard rule, or at least I didn't find anything
specific about that in:

https://www.debian.org/doc/debian-policy/ch-sharedlibs.html

> While there wouldn't be API compatibility, this would introduce two
> different "libraft.so.0" files into the archive. (And a future ".so.1"
> and ".so.2".) Maybe we could find another C library that changed its
> upstream to see how they handled it? Mostly I just don't want to
> 

Bug#980536: CMA=64M insufficient for starting firefox on RPi4B with 2xFullHD

[ibu ☉ radempa]

Hi Gunnar,

on a RPi4B with 8G RAM and two Full HD displays connected I am running 
bookworm. After upgrading firefox (102.15.1esr-1~deb12u1 to 
115.3.0esr-1~deb12u1) recently, it failed to start and threw multiply:


```
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
Failed to create scanout resource
```

After setting CMA=128M in /etc/default/raspi-firmware, update-initramfs 
and reboot firefox started properly and is usable.


```
# grep -i cma /proc/meminfo
CmaTotal: 131072 kB
CmaFree:   48612 kB
```

And if I run mpv (with CMA=128M) in addition to firefox, I occasionally 
also get the above error.


I suggest removing the notice in /etc/default/raspi-firmware concerning 
RPi4, or referring to this bug, and maybe updating other docs and the 
image when you find time, because I guess firefox is a frequently used 
application on this device and if it fails, it would push off users.


Cheers,
ibu

Bug#1050531: ITP: libmceliece -- Classic McEliece microlibrary

[Simon Josefsson]

Hi.  I'm happy to rewview, sponsor and co-maintain this package.  I
created https://salsa.debian.org/debian/libmceliece as a hopefully
better place to maintian the package in?

I did a review of the package and it looks fine, and I'm ready to upload
it.  Do you have any other changes pending?

/Simon


signature.asc
Description: PGP signature

Bug#1053865: prody: incompatible with python3-biopython > 1.79

[Andrius Merkys]

Source: prody
Version: 2.3.1+dfsg-3
Severity: serious
Justification: FTBFS
Tags: sid ftbfs
Forwarded: https://github.com/prody/ProDy/issues/1723

Hello,

prody FTBFS with python3-biopython > 1.79:

==
FAIL: testBuildMSAlocal 
(prody.tests.sequence.test_analysis.TestBuildMSA.testBuildMSAlocal)

--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.11_prody/build/prody/tests/sequence/test_analysis.py", 
line 1210, in testBuildMSAlocal

assert_array_equal(expect, result)
  File 
"/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 
985, in assert_array_equal

assert_array_compare(operator.__eq__, x, y, err_msg=err_msg,
  File "/usr/lib/python3.11/contextlib.py", line 81, in inner
return func(*args, **kwds)
   ^^^
  File 
"/usr/lib/python3/dist-packages/numpy/testing/_private/utils.py", line 
862, in assert_array_compare

raise AssertionError(msg)
AssertionError:
Arrays are not equal

Mismatched elements: 2 / 2 (100%)
 x: array([and 26 gaps)>,
   gaps)>],

  dtype=object)
 y: array([,
   ],
  dtype=object)

The upstream knows about the issue.

Best,
Andrius

Bug#1053761: llvm-toolchain-16 16.0.6-15~deb11u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 1053761 = 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: llvm-toolchain-16
Version: 16.0.6-15~deb11u1

Explanation: new backported package to support builds of newer chromium versions

Bug#1028722: prody: FTBFS: AssertionError: 3205 != 3211 : selection 'abs(x) == sqrt(sq(x))' for Selection 'all' failed, expected 3211, selected 3205

[Andrius Merkys]

Hello,

On 2023-10-12 21:22, Santiago Vila wrote:

To summarize: The failing test is buggy because when it fails
it does not necessarily mean that the package was misbuilt,
and in my opinion the best thing to do would be to disable it,
both in stable and unstable.

Trivial patch in the second attach.


Many thanks for investigating this issue. I will apply your patch, but 
prody would still FTBFS in sid and trixie due to unrelated 
incompatibility with python3-biopython.


Best,
Andrius