Bug#1072299: Compositor-related crashes

[Daniel Richard G.]

I'm going to need a spot of help with this.

I have Chromium running under GDB, with surprisingly low overhead (I can
browse like normal if I drop the --single-process flag). As far as I
could find, the "trap invalid opcode" error reported in syslog is
synonymous with a SIGILL, so I set "handle SIGILL stop pass".
Unfortunately, the trap errors continue to occur without GDB stopping
execution.

Do you know how to set this up to get to a backtrace? Maybe a way of
disabling the signal/crash handler?

Bug#1072556: RFS: elpa-rust-mode/1.0.5+git20240520.d00d83d-1 [ITA] [RC] -- Major Emacs mode for editing Rust source code

[Xiyue Deng]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "elpa-rust-mode":

 * Package name : elpa-rust-mode
   Version  : 1.0.5+git20240520.d00d83d-1
   Upstream contact : The Rust Project Developers 
 * URL  : https://github.com/rust-lang/rust-mode
 * License  : Apache-2.0 or MIT
 * Vcs  : https://salsa.debian.org/emacsen-team/rust-mode
   Section  : editors

The source builds the following binary packages:

  elpa-rust-mode - Major Emacs mode for editing Rust source code

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

  https://mentors.debian.net/package/elpa-rust-mode/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/elpa-rust-mode/elpa-rust-mode_1.0.5+git20240520.d00d83d-1.dsc

Changes since the last upload:

 elpa-rust-mode (1.0.5+git20240520.d00d83d-1) unstable; urgency=medium
 .
   [ Nicholas D Steeves ]
   * Drop emacs24 from Enhances (package does not exist in bullseye).
   * Matthew Kraai has moved to Emeritus status; remove him from
 Uploaders on his request.
 .
   [ Xiyue Deng ]
   * Sync to latest upstream snapshot (d00d83d) (Closes: #1072555)
   * Drop obsolete patches
   * Skip upstream Makefile which relies on eask
   * Drop obsolete override_dh_auto_test and refine override_dh_auto_clean
   * Include all source files in d/elpa
   * Migrate from compat to debhelper-compat version 13
   * Drop unnecessary parameter "--parallel" with debhelper-compat 13
   * Drop obsolete version requirements from dh-elpa and emacs
   * Declare Standards-Version 4.7.0; no change needed
   * Extend package description using upstream introduction
   * Drop Built-Using from "Architecture: all" package
   * Add myself as uploader (Closes: 1021460)
   * Modernize d/watch with special substitute strings
   * Rename license from Expat to MIT following upstream
   * Use https in Format URL
   * Update copyright years
   * Add copyright information for debian/*
   * Add Upstream-Contact
   * Add d/upstream/metadata
   * Add "Rules-Requires-Root: no" to source package
   * Add ${elpa:Depends} to Depends of binary package

Regards,
-- 
Xiyue Deng

Bug#1071977: tmux: /lib/x86_64-linux-gnu/libtinfo.so.6: version `NCURSES6_TINFO_6.4.current' 404

[Romain Francoise]

Downgrading this bug while we wait for more information for the submitter.

-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#1072555: elpa-rust-mode: This is an obsolete snapshot of the packaging

[Xiyue Deng]

Package: elpa-rust-mode
Version: 1.0.5+git20240301.6d86af4-1
Severity: serious

Dear Maintainer,

This is a placeholder bug for the current version in unstable, which is
now being obsoleted by a newer snapshot prepared on mentors[1].

[1] https://mentors.debian.net/package/elpa-rust-mode/

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

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

Versions of packages elpa-rust-mode depends on:
ii  dh-elpa-helper  2.1.2~bpo12+0manphiz1
ii  emacsen-common  3.0.5

Versions of packages elpa-rust-mode recommends:
ii  emacs  1:29.3+1-3~bpo12+1
ii  emacs-gtk [emacs]  1:29.3+1-3~bpo12+1

elpa-rust-mode suggests no packages.

-- no debconf information

Bug#1072554: RFS: emacs-dart-mode/1.0.7+git20240523.44beb62-2 -- Major mode for editing Dart files

[Xiyue Deng]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "emacs-dart-mode":

 * Package name : emacs-dart-mode
   Version  : 1.0.7+git20240523.44beb62-2
   Upstream contact : Jen-Chieh Shen 
 * URL  : https://github.com/emacsorphanage/dart-mode
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/emacsen-team/emacs-dart-mode
   Section  : editors

The source builds the following binary packages:

  elpa-dart-mode - Major mode for editing Dart files

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

  https://mentors.debian.net/package/emacs-dart-mode/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/emacs-dart-mode/emacs-dart-mode_1.0.7+git20240523.44beb62-2.dsc

Changes since the last upload:

 emacs-dart-mode (1.0.7+git20240523.44beb62-2) unstable; urgency=medium
 .
   * Source-only upload

This is required for emacs-dart-mode to migrate to testing

Regards,
-- 
Xiyue Deng

Bug#1072553: RFS: emacs-corfu-terminal/0.7-2 -- Corfu popup on terminal

[Xiyue Deng]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "emacs-corfu-terminal":

 * Package name : emacs-corfu-terminal
   Version  : 0.7-2
   Upstream contact : Akib Azmain Turja 
 * URL  : https://codeberg.org/akib/emacs-corfu-terminal
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/emacsen-team/emacs-corfu-terminal
   Section  : editors

The source builds the following binary packages:

  elpa-corfu-terminal - Corfu popup on terminal

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

  https://mentors.debian.net/package/emacs-corfu-terminal/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/emacs-corfu-terminal/emacs-corfu-terminal_0.7-2.dsc

Changes since the last upload:

 emacs-corfu-terminal (0.7-2) unstable; urgency=medium
 .
   * Source-only upload

This is required for it to migrate to testing.

Regards,
-- 
Xiyue Deng

Bug#1072552: RFS: clojure-mode/5.19.0-1 -- extra font-locking for clojure-mode

[Xiyue Deng]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "clojure-mode":

 * Package name : clojure-mode
   Version  : 5.19.0-1
   Upstream contact : Bozhidar Batsov 
 * URL  : https://github.com/clojure-emacs/clojure-mode
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/emacsen-team/clojure-mode
   Section  : lisp

The source builds the following binary packages:

  elpa-clojure-mode - Emacs major mode for Clojure code
  elpa-clojure-mode-extra-font-locking - extra font-locking for clojure-mode

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

  https://mentors.debian.net/package/clojure-mode/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/clojure-mode/clojure-mode_5.19.0-1.dsc

Changes since the last upload:

 clojure-mode (5.19.0-1) unstable; urgency=medium
 .
   * New upstream release
   * Add d/salsa-ci.yml with default settings
   * Stop using single-debian-patch to be compatible with dgit
   * Update Standards-Version to 4.7.0; no change needed
   * Keep testing files
   * Add patch to drop code for detecting clojure-mode source directory
 - This fixes autopkgtest stucking
   * Reinstate dh_elpa_test now that autopkgtest is fixed
   * Update debian copyright year in d/copyright
   * Add `Rules-Requires-Rules: no' in d/control

Regards,
-- 
Xiyue Deng

Bug#1072549: gl4es: Broken autopkgtest: unconditionally depends on gcc-multilib

[Bo YU]

Hi,

Thanks for reporting it.

On Tue, Jun 4, 2024 at 9:48 AM Boyuan Yang  wrote:
>
> Source: gl4es
> Version: 1.1.6+ds-1
> Severity: grave
> X-Debbugs-CC: tsu.y...@gmail.com ship...@gmail.com
>
> Dear Debian gl4es package maintainers,
>
> As currently shown on the package tracker 
> https://tracker.debian.org/pkg/gl4es ,
> package gl4es is experiencing autopkgtest failures on some architectures. 
> Looking
> deeper, it seems that gl4es unconditionally depends on binary package 
> gcc-multilib,
> which is not available on certain architectures.
>
> I am not sure why we need gcc-multilib in autopkgtest tests. Please adjust the
> source code accordingly, possibly following one of the following options:
>
> * Limit autopkgtest architectures and only run it where gcc-multilib is 
> available.
> * Rework on autopkgtest script so that gcc-multilib is not needed, and only 
> depends on
> the native gcc tools.
> * If gl4es only supports a limited set of architectures, please consider 
> limiting the
> supported hardware architecture in debian/control file.

Personally I would like to improve it based on option 2 andI will fix
it in the next days.

Thanks again for your reminder.:)

BR,
Bo
>
> I have zero knowledge on how gl4es works, so I cannot recommend a best option 
> for you.
> Please take a look and solve this issue properly.
>
> Thanks,
> Boyuan Yang

Bug#1072551: libextractor: Add build support for loongarch64

[zhangdandan]

Source: libextractor
Version: 1:1.13-4
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the libextractor failed for loong64 in the Debian Package 
Auto-Building environment.
The reason is the lack of loongarch64 support in 
debian/libextractor-plugins-misc.install.

The error log is as follows,
```
..
  dh_missing -a
dh_missing: warning: 
usr/lib/loongarch64-linux-gnu/libextractor/libextractor_elf.so exists in 
debian/tmp but is not installed to anywhere

dh_missing: error: missing files, aborting
```
The full build log can be found at 
https://buildd.debian.org/status/logs.php?pkg=libextractor=1%3A1.13-4=loong64.


I have added the loongarch64 support to the libextractor source package. 
And built successfully on my local ENV.

Please consider the patch I attached.
If you have any questions, you can contact me at any time.

thanks,
Dandan Zhang

diff --git a/debian/libextractor-plugins-misc.install b/debian/libextractor-plugins-misc.install
index ac95e13..fc290c7 100755
--- a/debian/libextractor-plugins-misc.install
+++ b/debian/libextractor-plugins-misc.install
@@ -1,7 +1,7 @@
 #! /usr/bin/dh-exec
 usr/lib/*/*/libextractor_deb.so
 usr/lib/*/*/libextractor_dvi.so
-[any-amd64 any-i386 alpha arm64 armel armhf ia64 mips64el ppc64el riscv64 sh4] usr/lib/*/*/libextractor_elf.so
+[any-amd64 any-i386 alpha arm64 armel armhf ia64 loong64 mips64el ppc64el riscv64 sh4] usr/lib/*/*/libextractor_elf.so
 usr/lib/*/*/libextractor_it.so
 usr/lib/*/*/libextractor_man.so
 usr/lib/*/*/libextractor_mime.so

Bug#1072550: RFS: Komac/2.2.1 [ITP] -- The Community Manifest Creator for WinGet

[solomoncyj]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name : Komac
   Version  : 2.1-1
 * URL  : https://github.com/russellbanks/Komac
 * License  : GPL-3.0 license
 * Vcs  : https://github.com/russellbanks/Komac
The source builds the following binary packages:

  komac- the Community Manifest Creator for WinGet

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

  https://github.com/russellbanks/Komac

Bug#1072549: gl4es: Broken autopkgtest: unconditionally depends on gcc-multilib

[Boyuan Yang]

Source: gl4es
Version: 1.1.6+ds-1
Severity: grave
X-Debbugs-CC: tsu.y...@gmail.com ship...@gmail.com

Dear Debian gl4es package maintainers,

As currently shown on the package tracker https://tracker.debian.org/pkg/gl4es ,
package gl4es is experiencing autopkgtest failures on some architectures. 
Looking
deeper, it seems that gl4es unconditionally depends on binary package 
gcc-multilib,
which is not available on certain architectures.

I am not sure why we need gcc-multilib in autopkgtest tests. Please adjust the
source code accordingly, possibly following one of the following options:

* Limit autopkgtest architectures and only run it where gcc-multilib is 
available.
* Rework on autopkgtest script so that gcc-multilib is not needed, and only 
depends on
the native gcc tools.
* If gl4es only supports a limited set of architectures, please consider 
limiting the
supported hardware architecture in debian/control file.

I have zero knowledge on how gl4es works, so I cannot recommend a best option 
for you.
Please take a look and solve this issue properly.

Thanks,
Boyuan Yang


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

Bug#1072548: instead: Please package new upstream release 3.5.1

[Boyuan Yang]

Source: instead
Version: 3.3.2-1.1
Tags: sid
X-Debbugs-CC: joe.s...@gmail.com
Severity: normal

Dear Debian instead package maintainer,

A new upstream release of package instead is available. Please consider 
packaging
it in Debian. Feel free to let me know if you need any package sponsorship.

Thanks,
Boyuan Yang


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

Bug#1072547: FTBS: Compile error on loongarch

[wuruilong]

Source: rocksdb
Version: 8.9.1-2
Severity: normal
Tags: patch
X-Debbugs-Cc: wuruil...@loongson.cn
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear Maintainer,

Incorrectly set compilation options for rocksdb caused compilation to fail on 
loongarch. The attached patch has fixed this issue, please refer to the patch 
code changes.

wuruilong
-- System Information:
Debian Release: trixie/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)

Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Description: 
 TODO: Put a short summary on the line above and replace this paragraph
 with a longer explanation of this change. Complete the meta-information
 with other relevant fields (see below for details). To make it easier, the
 information below has been extracted from the changelog. Adjust it or drop
 it.
 .
 rocksdb (8.9.1-2) unstable; urgency=medium
 .
   * Upload to Sid.
   * Add loong64 architecture support (closes: #1059023).
Author: Laszlo Boszormenyi (GCS) 
Bug-Debian: https://bugs.debian.org/1059023

---
The information above should follow the Patch Tagging Guidelines, please
checkout https://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: (upstream|backport|vendor|other), (|commit:)
Bug: 
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: (no|not-needed|)
Applied-Upstream: , (|commit:)
Reviewed-By: 
Last-Update: 2024-06-04

--- rocksdb-8.9.1.orig/CMakeLists.txt
+++ rocksdb-8.9.1/CMakeLists.txt
@@ -237,8 +237,8 @@ endif(CMAKE_SYSTEM_PROCESSOR MATCHES "s3
 if(CMAKE_SYSTEM_PROCESSOR MATCHES "loongarch64")
   CHECK_C_COMPILER_FLAG("-march=loongarch64" HAS_LOONGARCH64)
   if(HAS_LOONGARCH64)
-set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -mcpu=loongarch64 -mtune=loongarch64")
-set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mcpu=loongarch64 
-mtune=loongarch64")
+set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -march=loongarch64 -mtune=loongarch64")
+set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=loongarch64 
-mtune=loongarch64")
   endif(HAS_LOONGARCH64)
 endif(CMAKE_SYSTEM_PROCESSOR MATCHES "loongarch64")
 

Bug#1060200: intel-microcode: diff for NMU version 3.20240531.1+nmu1

[Henrique de Moraes Holschuh]

Hello Chris,

Did you test the result?   Does the system boots with an updated microcode 
after the change ?

It has to be tested with mkinitramfs and Dracut, the resulting early-initramfs 
must be "almost" byte-equal (timestamps can change, but not the paths/filenames 
inside, nor the *offset* where the data starts relative to start-of-file. THIS 
IS IMPORTANT.

I believe it should really just work with mkinitramfs, since we ask iucode_tool 
to generate the early-initramfs in that case, and iucode_tool doesn't care 
where the source data is, as long as it can read it.  One should still test it 
to be sure.

Dracut, I haven't looked into what it is doing. Hopefully it also uses 
iucode_tool nowadays...

-- 
  Henrique de Moraes Holschuh 

Bug#1072546: ITP: xcb-util-errors -- Helper library for printing information about X11 errors

[Boyuan Yang]

Package: wnpp
Owner: Boyuan Yang 
Severity: wishlist

* Package name: xcb-util-errors
  Version : 1.0.1
  Upstream Contact: Uli Schlachter
* URL : https://gitlab.freedesktop.org/xorg/lib/libxcb-errors
* License : Expat
  Programming Lang: C
  Description : Helper library for printing information about X11 errors

 xcb-util-errors is a utility library that gives human readable names
 to error codes and event codes and also to major and minor numbers.
 .
 The necessary information is drawn from xcb-proto's protocol descriptions.
 .
 This library is especially useful when working with extensions and is mostly
 useful for debugging.


Thanks,
Boyuan Yang


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

Bug#996824: smokeping fails to start (timeout) if DNS temporarily unavailable

[Michael Deegan]

Package: smokeping
Version: 2.7.3-2
Followup-For: Bug #996824

Uhh, it's not just DNS being unavailable that's the problem (that's a local
network configuration problem) but rather some DNS names being unresolvable
on account of an upstream network problem (eg.  waiting for my connection to
my ISP to establish).

The problem I'd like to solve is that I can't monitor my perfectly reachable
LAN hosts if one or more WAN hosts are unreachable/unresolvable.


-- System Information:
Debian Release: 12.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldoldstable-updates'), (500, 'oldoldstable-debug'), (500, 'oldoldstable'), 
(500, 'stable'), (500, 'oldstable'), (490, 'testing'), (400, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT)
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 smokeping depends on:
ii  adduser3.134
ii  debianutils5.7-0.5~deb12u1
ii  exim4-daemon-light [mail-transport-agent]  4.96-15+deb12u4
ii  fping  5.1-1
ii  init-system-helpers1.65.2
pn  libcgi-fast-perl   
pn  libconfig-grammar-perl 
ii  libdigest-hmac-perl1.04+dfsg-2
pn  libjs-cropper  
pn  libjs-prototype
pn  libjs-scriptaculous
pn  librrds-perl   
pn  libsnmp-session-perl   
ii  liburi-perl5.17-1
ii  libwww-perl6.68-1
ii  lsb-base   11.6
ii  perl   5.36.0-7+deb12u1
ii  sysvinit-utils [lsb-base]  3.06-4
ii  ucf3.0043+nmu1

Versions of packages smokeping recommends:
pn  apache2 | apache2 | httpd  
pn  apache2 | httpd-cgi
ii  bind9-dnsutils [dnsutils]  1:9.18.24-1
ii  dnsutils   1:9.18.24-1
pn  echoping   
ii  libsocket6-perl0.29-3

Versions of packages smokeping suggests:
ii  curl   7.88.1-10+deb12u5
pn  libauthen-radius-perl  
pn  libinfluxdb-lineprotocol-perl  
ii  libio-pty-perl 1:1.17-1
ii  libio-socket-ssl-perl  2.081-2
pn  libnet-dns-perl
pn  libnet-ldap-perl   
pn  libnet-openssh-perl
pn  libnet-telnet-perl 
pn  libobject-result-perl  
ii  libpath-tiny-perl  0.144-1
ii  openssh-client 1:9.2p1-2+deb12u2

-MD

-- 
-
Michael Deegan   Hugaholic  https://www.deegan.id.au/
  Jung, zr jbeel?  --

Bug#1072545: new version fixes bug #1040672

[Bjarni Ingi Gislason]

Package: zstd
Version: 1.5.5+dfsg2-2
Severity: normal

Dear Maintainer,

  This software should be updated as it fixes the bug report #1040672.

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

Kernel: Linux 6.7.12-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages zstd depends on:
ii  libc6   2.38-11
ii  libgcc-s1   14-20240330-1
ii  liblz4-11.9.4-2
ii  liblzma55.6.1+really5.4.5-1
ii  libstdc++6  14-20240330-1
ii  zlib1g  1:1.3.dfsg+really1.3.1-1

zstd recommends no packages.

zstd suggests no packages.

-- no debconf information

Bug#1072251: segfaults

[Tim McConnell]

225.685069] mate-notificati[2355]: segfault at 7f1d01af5004 ip
7f1b0ece7a31 sp 7fff799b9688 error 4 in libgobject-
2.0.so.0.8000.2[7f1b0ecbb000+35000] likely on CPU 1 (core 1, socket 0)
[  225.685114] Code: 75 59 02 00 48 8b 34 e8 e9 2f ff ff ff 66 66 2e 0f
1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 85 ff 74 47 48 8b 07 48 85 c0 74
3f <48> 8b 00 48 3d fc 03 00 00 77 2c 48 8d 15 3d 59 02 00 48 c1 e8 02
[  904.856569] mate-notificati[4216]: segfault at 7ff1536a9384 ip
7ff6ce052a31 sp 7fff74291d78 error 4 in libgobject-
2.0.so.0.8000.2[7ff6ce026000+35000] likely on CPU 4 (core 0, socket 0)
[  904.856579] Code: 75 59 02 00 48 8b 34 e8 e9 2f ff ff ff 66 66 2e 0f
1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 85 ff 74 47 48 8b 07 48 85 c0 74
3f <48> 8b 00 48 3d fc 03 00 00 77 2c 48 8d 15 3d 59 02 00 48 c1 e8 02
[ 1004.774139] mate-notificati[4343]: segfault at 7fb6eb115b93 ip
7fb133ae7a31 sp 7ffdf25b3cc8 error 4 in libgobject-
2.0.so.0.8000.2[7fb133abb000+35000] likely on CPU 0 (core 0, socket 0)
[ 1004.774191] Code: 75 59 02 00 48 8b 34 e8 e9 2f ff ff ff 66 66 2e 0f
1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 85 ff 74 47 48 8b 07 48 85 c0 74
3f <48> 8b 00 48 3d fc 03 00 00 77 2c 48 8d 15 3d 59 02 00 48 c1 e8 02

traps: mate-panel[1689] trap int3 ip:7f4a1e8e6137 sp:7ffc49bad960
error:0 in libglib-2.0.so.0.8000.2[7f4a1e8a+9d000]
[ 5492.234209] traps: clock-applet[18195] trap int3 ip:7f38ae5e5137
sp:7ffe0a62f4c0 error:0 in libglib-2.0.so.0.8000.2[7f38ae59f000+9d000]
[ 5495.985929] traps: clock-applet[18208] trap int3 ip:7f1a48780137
sp:7ffeee1df1b0 error:0 in libglib-2.0.so.0.8000.2[7f1a4873a000+9d000]

Bug#1072321: add package for opentelemetry/otlp (and other grpc modules?)

[David Mandelberg]

Hi,

Sorry for the noise, but I learned about the axosyslog fork (which I 
just filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072543 
for) after I filed this bug. The OTLP features that I want to use look 
like they'll be in axosyslog but not syslog-ng, so I'm not sure I 
actually care about an otlp package for syslog-ng. Should I close this bug?

Bug#1072543: RFP: axosyslog -- cloud-native, syslog-ng compatible logging agent

[David Mandelberg]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: syslog-ng-maintain...@alioth-lists.debian.net

* Package name: axosyslog
  Version : 4.7.1
  Upstream Author : Axoflow
* URL : https://github.com/axoflow/axosyslog
* License : GPL and LGPL
  Programming Lang: C
  Description : cloud-native, syslog-ng compatible logging agent

AxoSyslog was recently forked[0] from syslog-ng, which is already in 
Debian. And its developers are working on some features that I could 
really use.


 [0] https://axoflow.com/axosyslog-syslog-ng-fork/

Bug#1072542: RM: cutefish-core -- ROM; dead upstream; low popcorn

[Arun Kumar Pariyar]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: a...@debian.org

Dear FTP Team,

Please remove cutefish-core from unstable as it is not maintained in
the upstream anymore and there are no reverse dependencies.

Thank you
--
Arun Kumar Pariyar


OpenPGP_0x4B542AF704F74516.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072471: libaio1t64: Missing libaio.so.1 compat symlink in the base (ie non udeb) package

[Guillem Jover]

Control: forwarded -1 https://marc.info/?l=linux-aio=171745321208314

Hi!

On Sun, 2024-06-02 at 14:28:31 +, Romain Geissler wrote:
> Package: libaio1t64
> Version: 0.3.113-8
> Severity: normal

> When installing the "new" package libaio1t64 package in Debian testing
> or Ubuntu Noble, the previously available libaio.so.1 file/symlink is no
> longer available. This effectively breaks non-debian built package like
> for example the Oracle Instant client which would need a libaio.so.1
> compat symlink to "work". This was for example reported in Oracle forums
> here:
> https://forums.oracle.com/ords/r/apexds/community/q?question=instant-client-on-ubuntu-24-04-noble-numbat-7244

> I see that for #1067831 you added a compat symlink, but only for the
> udeb package, and apparently in the dicussion the idea to add this
> symlink in the base package rather the udeb one was ruled out. However
> in practice it means third party binaries like the oracle ones are still
> broken unless a symlink is manually created.

In the Debian context this was intended to be a temporary
non-intrusive solution that would not stomp over upstream, until this
had been agreed with them. My intention has always been to revert the
local SONAME bump before the next Debian release. Ubuntu will have to
deal with this however best they see fit.

> If there is really an issue with adding it in the package, can we at
> least consider Raphael Hertzog's propsal to add it as a postinstall
> step (checking if the libaio.so.1 exists and if not symlink it) ?

I was able to verify whether part of the Linux kernel fix I had in mind
solved the test suite issues (and were not caused by faulty libaio
changes), and have now submitted the libaio and Linux fixes upstream, at:

  https://marc.info/?l=linux-aio=171745321208314

so ideally, if they agree with the API/ABI changes, I'd then revert
the SONAME transition in Debian and provide the t64 backwards compat
symlinks in the libaio1 package. Otherwise I'll work with upstream on
a suitable API/ABI change, and in that case I would not be able to
provide backwards compat symlinks.

Thanks,
Guillem

Bug#635834: Revisiting inclusion of AcroTeX/eForms in TeX Live in light of advancements in libre PDF readers

[Karl Berry]

Hi John - are there any other packages that support such PDF
functionality?

AcroTeX et al. are problematic not just because of the reader end, but
also because of the writer end, some of which required Adobe software.
The author (Donald Story) was (understandably) not interested in teasing
out the proprietary-required stuff from the non-proprietary-required
stuff. He eventually told me "just don't put my packages in TeX Live".
He passed away in 2022, and I haven't seen any notes about further
development from other people.

His work, all in all, is quite a complex set of packages and figuring
out what can be done isn't something I'm ever going to be able to take on.

P.S. I'm having trouble subscribing, so please CC me on replies.

If you want me to subscribe you to the tex-live list by hand, no
problem.  I had to put up a lot of barriers on the subscription page due
to subscribe bombers. --thanks, karl.

Bug#1064396: libinput: diff for NMU version 1.25.0-1.1

[Chris Hofstaedtler]

Control: tags 1064396 + patch
Control: tags 1064396 + pending


Dear maintainer,

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

Regards.

diff -Nru libinput-1.25.0/debian/changelog libinput-1.25.0/debian/changelog
--- libinput-1.25.0/debian/changelog	2024-02-05 13:20:23.0 +0100
+++ libinput-1.25.0/debian/changelog	2024-06-03 23:45:58.0 +0200
@@ -1,3 +1,12 @@
+libinput (1.25.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Michael Biebl ]
+  * Install udev rules and helpers into /usr. (Closes: #1064396)
+
+ -- Chris Hofstaedtler   Mon, 03 Jun 2024 23:45:58 +0200
+
 libinput (1.25.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru libinput-1.25.0/debian/libinput10-udeb.install libinput-1.25.0/debian/libinput10-udeb.install
--- libinput-1.25.0/debian/libinput10-udeb.install	2024-01-24 16:25:22.0 +0100
+++ libinput-1.25.0/debian/libinput10-udeb.install	2024-06-03 23:45:56.0 +0200
@@ -1,3 +1,3 @@
-lib/udev
+usr/lib/udev
 usr/lib/*/libinput.so.10*
 usr/share/libinput
diff -Nru libinput-1.25.0/debian/libinput-bin.install libinput-1.25.0/debian/libinput-bin.install
--- libinput-1.25.0/debian/libinput-bin.install	2024-01-24 16:25:22.0 +0100
+++ libinput-1.25.0/debian/libinput-bin.install	2024-06-03 23:45:56.0 +0200
@@ -1,2 +1,2 @@
-lib/udev
+usr/lib/udev
 usr/share/libinput
diff -Nru libinput-1.25.0/debian/rules libinput-1.25.0/debian/rules
--- libinput-1.25.0/debian/rules	2024-01-24 16:25:22.0 +0100
+++ libinput-1.25.0/debian/rules	2024-06-03 23:45:56.0 +0200
@@ -7,12 +7,12 @@
 override_dh_auto_configure:
 	dh_auto_configure -B build-deb -- \
 		-Ddocumentation=false \
-		-Dudev-dir=/lib/udev
+		-Dudev-dir=/usr/lib/udev
 
 ifeq ($(with_udeb),yes)
 	dh_auto_configure -B build-udeb -- \
 		-Ddocumentation=false \
-		-Dudev-dir=/lib/udev \
+		-Dudev-dir=/usr/lib/udev \
 		-Dlibwacom=false
 endif
 

Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

[Santiago Vila]

El 3/6/24 a las 23:10, Helmut Grohne escribió:

On Wed, May 29, 2024 at 03:14:59PM +0200, Helmut Grohne wrote:

Since noble includes these changes and I'd get this done sooner rather
than later, how about moving forward with June 5th after 22:30 UTC (such
that all buildds have regenerated their chroots before the upload)?


I got vaguely positive feedback from Paul Gevers on this date. Hence, I
plan to upload after the June 5th mirror push and allocate time for
handling unexpected fallout.

dash, base-files and bash are fully migrated at the time of this
writing. glibc migrated -11 and -12 still has 5 autopkgtest regressions.
util-linux migrated -6, -7 has a piuparts regression and -8 hopefully
gets tested soon. I hope that both migrate before the planned upload and
will consult with the release team on whether to bump back or go ahead.

I have rebased and retested the patches in
https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo.

Andrew, Aurelien, Chris, Matthias, Santiago: Any objections?


For base-files, please use branch "wip-202406" here:

git clone https://salsa.debian.org/sanvila/base-files-not-yet/

(I've just made such branch the default) and upload as is.

This will avoid sending signed files.

Thanks.

Bug#1072538: dracut-core: systemd-cryptsetup missing from generated image

[Thomas Lange]

You are right. It seems that the pacakge does not include the new
dracut module systemd-cryptsetup which handles this.

I will prepare a new version soon.

-- 
regards Thomas

Bug#1072389: patches to make cruft-ng work without locate

[Jochen Sprickerhof]

* Alexandre Detiste  [2024-06-03 22:01]:

Le lun. 3 juin 2024 à 21:32, Jochen Sprickerhof  a écrit :

>The scripts in explain/ ought to be run inside the chroot.

Good point. You could actually use unshare to make it work without root
but I would also prefer option 2.
What do you think of a slow adoption as in explain.cc
set's the DPKG_ROOT variable and all explain scripts
get a test -z $DPKG_ROOT || exit 0 at the top.
Then we can fix them individually as far as it makes sense.


Let's do that, that's the simplest.


OK, I actually opted for CRUFT_ROOT to stay out of the DPKG namespace. 
MR is here:


https://salsa.debian.org/detiste-guest/cruft-ng/-/merge_requests/1

Can you have a look before I modify more scripts?


I gave you write access.


Thanks, I pushed a small fixup commit.


This could be team-managed but I don't know inside which team it would fit.
Maybe QA ? Maybe here: https://packages.debian.org/unstable/forensics-all


Maybe just move it to https://salsa.debian.org/debian


I use it nowadays to guess what messy people did before me on some filesystems,
they were merely lazy, not evil, they did not tried to hide their tweaks at all;
I don't know if that count as forensics.


Yeah, same here. Btw. what do you think of dropping explain/python3-pip? 
I think cruft-ng should rather report all non package files and it is 
easy enough for the user to filter out /usr/local if they want.


signature.asc
Description: PGP signature

Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

[Chris Hofstaedtler]

* Helmut Grohne  [240603 23:11]:
> On Wed, May 29, 2024 at 03:14:59PM +0200, Helmut Grohne wrote:
> > Since noble includes these changes and I'd get this done sooner rather
> > than later, how about moving forward with June 5th after 22:30 UTC (such
> > that all buildds have regenerated their chroots before the upload)?
> 
> I got vaguely positive feedback from Paul Gevers on this date. Hence, I
> plan to upload after the June 5th mirror push and allocate time for
> handling unexpected fallout.
> 
> dash, base-files and bash are fully migrated at the time of this
> writing. glibc migrated -11 and -12 still has 5 autopkgtest regressions.
> util-linux migrated -6, -7 has a piuparts regression and -8 hopefully
> gets tested soon. I hope that both migrate before the planned upload and
> will consult with the release team on whether to bump back or go ahead.
> 
> I have rebased and retested the patches in
> https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo.
> 
> Andrew, Aurelien, Chris, Matthias, Santiago: Any objections?

For util-linux: no objections.

> You may send me signed uploads (.dsc + source chanages) and I will
> otherwise move ahead with regular NMUs. If you send signed changes, I
> recommend encrypting them using my gpg key.

Please NMU util-linux, to cut short any waiting time.

Chris



signature.asc
Description: PGP signature

Bug#1072541: gedit: Update to 47

[Jeremy Bícha]

Source: gedit
Version: 46.2-3
Severity: wishlist
Control: affects -1 src:gedit-plugins
Control: block -1 by 1072540

There is a new version of gedit available. However, it requires a new
version of tepl which has been renamed to libgedit-tepl (no other
reverse dependencies except gedit-plugins which has also been
updated). More importantly, it intentionally breaks translations. See
the blocking bug.

Thank you,
Jeremy Bícha

Bug#1072540: gedit: 47 drops all translations

[Jeremy Bícha]

Source: gedit
Severity: important
Tags: l10n
X-Debbugs-CC: budgie-desktop-environm...@packages.debian.org

gedit 47 has disabled all translations because key UI libraries are
not hosted on https://gitlab.gnome.org/ . This is particularly
frustrating because it is the gedit maintainer's decision to move the
libraries to https://github.com/gedit-technology

Thank you,
Jeremy Bícha

Bug#1051237: transition: move files from / to /usr to finalize /usr-merge

[Helmut Grohne]

On Wed, May 29, 2024 at 03:14:59PM +0200, Helmut Grohne wrote:
> Since noble includes these changes and I'd get this done sooner rather
> than later, how about moving forward with June 5th after 22:30 UTC (such
> that all buildds have regenerated their chroots before the upload)?

I got vaguely positive feedback from Paul Gevers on this date. Hence, I
plan to upload after the June 5th mirror push and allocate time for
handling unexpected fallout.

dash, base-files and bash are fully migrated at the time of this
writing. glibc migrated -11 and -12 still has 5 autopkgtest regressions.
util-linux migrated -6, -7 has a piuparts regression and -8 hopefully
gets tested soon. I hope that both migrate before the planned upload and
will consult with the release team on whether to bump back or go ahead.

I have rebased and retested the patches in
https://salsa.debian.org/helmutg/bootstrap-usrmerge-demo.

Andrew, Aurelien, Chris, Matthias, Santiago: Any objections?

You may send me signed uploads (.dsc + source chanages) and I will
otherwise move ahead with regular NMUs. If you send signed changes, I
recommend encrypting them using my gpg key.

Helmut

Bug#1069359: python-cooler: FTBFS due to TypeError in dask.dataframe import

[Étienne Mollier]

Control: tags -1 + confirmed
Control: block -1 by 1068422
Control: retitle -1 python-cooler: FTBFS due to TypeError in dask.dataframe 
import

Hi,

After some investigations, it seems that #1069359 affecting
python-cooler is actually a manifestation of #1068422 affecting
dask, more precisely all attempts to load dataframe.  I adjust
the bug metadata to reflect that.  The relevant call trace looks
like:

tests/test_create.py:24: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ 
/usr/lib/python3/dist-packages/dask/dataframe/__init__.py:98: in 

from dask.dataframe import backends, dispatch, rolling
/usr/lib/python3/dist-packages/dask/dataframe/backends.py:15: in 

from dask.dataframe.core import DataFrame, Index, Scalar, Series, 
_Frame
/usr/lib/python3/dist-packages/dask/dataframe/core.py:36: in 
from dask.dataframe import methods
/usr/lib/python3/dist-packages/dask/dataframe/methods.py:34: in 
from dask.dataframe.utils import is_dataframe_like, is_index_like, 
is_series_like
/usr/lib/python3/dist-packages/dask/dataframe/utils.py:20: in 
from dask.dataframe import (  # noqa: F401 register pandas 
extension types
/usr/lib/python3/dist-packages/dask/dataframe/_dtypes.py:9: in 
from dask.dataframe.extensions import make_array_nonempty, 
make_scalar
/usr/lib/python3/dist-packages/dask/dataframe/extensions.py:8: in 

from dask.dataframe.accessor import (
/usr/lib/python3/dist-packages/dask/dataframe/accessor.py:126: in 

class DatetimeAccessor(Accessor):
/usr/lib/python3/dist-packages/dask/dataframe/accessor.py:81: in 
__init_subclass__
_bind_property(cls, pd_cls, attr, min_version)
/usr/lib/python3/dist-packages/dask/dataframe/accessor.py:35: in 
_bind_property
setattr(cls, attr, property(derived_from(pd_cls, 
version=min_version)(func)))
/usr/lib/python3/dist-packages/dask/utils.py:983: in wrapper
method.__doc__ = _derived_from(
/usr/lib/python3/dist-packages/dask/utils.py:936: in _derived_from
method_args = get_named_args(method)
/usr/lib/python3/dist-packages/dask/utils.py:697: in get_named_args
s = inspect.signature(func)
/usr/lib/python3.12/inspect.py:3310: in signature
return Signature.from_callable(obj, follow_wrapped=follow_wrapped,
/usr/lib/python3.12/inspect.py:3054: in from_callable
return _signature_from_callable(obj, sigcls=cls,
/usr/lib/python3.12/inspect.py:2642: in _signature_from_callable
call = _descriptor_get(call, obj)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ 

descriptor = 
obj = 

def _descriptor_get(descriptor, obj):
if isclass(descriptor):
return descriptor
get = getattr(type(descriptor), '__get__', _sentinel)
if get is _sentinel:
return descriptor
>   return get(descriptor, obj, type(obj))
E   TypeError: descriptor '__call__' for 'type' objects doesn't 
apply to a 'property' object


Looking through cooler code, it seems dask.dataframe is an
optional component, and it may be possible to resolve the
present issue without waiting for resolution of the problem in
dask.  It would however require active reintroduction of dask in
the build dependencies, once the root cause is fixed, to get the
original test coverage on tracks.  On the other hand, skipping
tests involving unconditional loading of dask.dataframe would
probably permit reintroduction of python-cooler in testing, even
without dask.  I'm not implementing such skip right now: lookup
of the dask bug upstream[1] suggests there may be options to get
the issue sorted at the source.

[1]: https://github.com/dask/dask/pull/11035

In hope this helps,
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/4, please excuse my verbosity
   `-on air: Moon Safari - Bluebells


signature.asc
Description: PGP signature

Bug#1072539: ipywidgets: Recent changes introduced nodejs dependency limiting portability

[John Paul Adrian Glaubitz]

Source: ipywidgets
Version: 8.1.2-3
Severity: important

Hello,

the recent change to obsolete some binary packages in ipywidgets [1] introduced 
a hard
dependency on nodejs which is available on a limited set of architectures only 
making
ipywidgets uninstallable on a number of architectures:

- alpha
- hppa
- hurd-amd64
- hurd-i386
- m68k
- powerpc
- ppc64
- sh4
- sparc64
- x32

Would it be possible to revert this change to remove the introduced dependency 
on nodejs
again?

Thanks,
Adrian

> [1] 
> https://salsa.debian.org/python-team/packages/ipywidgets/-/commit/ab52650adf13fd9f82f66dc1b328d04128496dcf

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1070835: OBS does not correctly implement the bootstrap protocol

[Dmitry Baryshkov]

Package: ed
Followup-For: Bug #1070835

To slightly improve the suggestion, instead of skipping ed I ended up
forcebly installing usrmerge:

%if %_repository == "Debian_Unstable" || %_repository == "Debian_Testing"
Preinstall: usrmerge
Runscripts: usrmerge
%endif


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

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

Versions of packages ed depends on:
ii  libc6  2.38-11

ed recommends no packages.

ed suggests no packages.

-- no debconf information

Bug#1060200: intel-microcode: diff for NMU version 3.20240531.1+nmu1

[Chris Hofstaedtler]

Control: tags 1060200 + patch
Control: tags 1060200 + pending


Dear maintainer,

I've prepared an NMU for intel-microcode (versioned as 3.20240531.1+nmu1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru intel-microcode-3.20240531.1/debian/changelog intel-microcode-3.20240531.1+nmu1/debian/changelog
--- intel-microcode-3.20240531.1/debian/changelog	2024-06-01 16:49:47.0 +0200
+++ intel-microcode-3.20240531.1+nmu1/debian/changelog	2024-06-03 22:45:50.0 +0200
@@ -1,3 +1,11 @@
+intel-microcode (3.20240531.1+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install aliased files into /usr (DEP17 M2) (Closes: #1060200)
+  * Add superficial autopkgtest for initramfs hook.
+
+ -- Chris Hofstaedtler   Mon, 03 Jun 2024 22:45:50 +0200
+
 intel-microcode (3.20240531.1) unstable; urgency=medium
 
   * New upstream microcode datafile 20240531
diff -Nru intel-microcode-3.20240531.1/debian/initramfs.hook intel-microcode-3.20240531.1+nmu1/debian/initramfs.hook
--- intel-microcode-3.20240531.1/debian/initramfs.hook	2024-06-01 16:47:45.0 +0200
+++ intel-microcode-3.20240531.1+nmu1/debian/initramfs.hook	2024-06-03 22:44:38.0 +0200
@@ -45,7 +45,7 @@
 	IUCODE_TOOL=/usr/sbin/iucode_tool
 fi
 
-IUCODE_FW_DIR=/lib/firmware/intel-ucode
+IUCODE_FW_DIR=/usr/lib/firmware/intel-ucode
 if [ "$MODULES" = "most" ]; then
 	IUCODE_TOOL_INITRAMFS=early
 	IUCODE_TOOL_SCANCPUS=no
diff -Nru intel-microcode-3.20240531.1/debian/intel-microcode.dirs intel-microcode-3.20240531.1+nmu1/debian/intel-microcode.dirs
--- intel-microcode-3.20240531.1/debian/intel-microcode.dirs	2024-06-01 16:46:07.0 +0200
+++ intel-microcode-3.20240531.1+nmu1/debian/intel-microcode.dirs	2024-06-03 22:44:38.0 +0200
@@ -1,3 +1,3 @@
-lib/firmware/intel-ucode
+usr/lib/firmware/intel-ucode
 etc/default
 etc/modprobe.d
diff -Nru intel-microcode-3.20240531.1/debian/rules intel-microcode-3.20240531.1+nmu1/debian/rules
--- intel-microcode-3.20240531.1/debian/rules	2024-06-01 16:46:07.0 +0200
+++ intel-microcode-3.20240531.1+nmu1/debian/rules	2024-06-03 22:44:38.0 +0200
@@ -32,13 +32,13 @@
 	dh_install
 
 	# split microcode pack
-	$(IUCODE_TOOL) -q --write-firmware="$(PKGDIR)/lib/firmware/intel-ucode" $(IUCODE_FILE)
+	$(IUCODE_TOOL) -q --write-firmware="$(PKGDIR)/usr/lib/firmware/intel-ucode" $(IUCODE_FILE)
 
 	# apply best-effort blacklist
 	if [ -r debian/ucode-blacklist.txt ] ; then \
 		cat debian/ucode-blacklist.txt | while read -r fn crap ; do \
-			if [ -r "$(PKGDIR)/lib/firmware/intel-ucode/$${fn}" ] ; then \
-mv "$(PKGDIR)/lib/firmware/intel-ucode/$${fn}" "$(PKGDIR)/lib/firmware/intel-ucode/$${fn}.initramfs" ;\
+			if [ -r "$(PKGDIR)/usr/lib/firmware/intel-ucode/$${fn}" ] ; then \
+mv "$(PKGDIR)/usr/lib/firmware/intel-ucode/$${fn}" "$(PKGDIR)/usr/lib/firmware/intel-ucode/$${fn}.initramfs" ;\
 echo "Renaming blacklisted microcode $${fn}" ; \
 			fi ; \
 		done ; \
diff -Nru intel-microcode-3.20240531.1/debian/tests/control intel-microcode-3.20240531.1+nmu1/debian/tests/control
--- intel-microcode-3.20240531.1/debian/tests/control	1970-01-01 01:00:00.0 +0100
+++ intel-microcode-3.20240531.1+nmu1/debian/tests/control	2024-06-03 22:44:38.0 +0200
@@ -0,0 +1,7 @@
+Tests: initramfs
+Architecture: amd64
+Depends:
+ @,
+ linux-image-amd64,
+ initramfs-tools,
+Restrictions: needs-root, allow-stderr, superficial
diff -Nru intel-microcode-3.20240531.1/debian/tests/initramfs intel-microcode-3.20240531.1+nmu1/debian/tests/initramfs
--- intel-microcode-3.20240531.1/debian/tests/initramfs	1970-01-01 01:00:00.0 +0100
+++ intel-microcode-3.20240531.1+nmu1/debian/tests/initramfs	2024-06-03 22:44:38.0 +0200
@@ -0,0 +1,12 @@
+#!/bin/bash
+set -ex -o pipefail
+
+update-initramfs -kall -u
+INITRDS=(/boot/initrd.img-*)
+
+unmkinitramfs "${INITRDS[0]}" initramfs/
+find initramfs/
+
+test -e initramfs/early/kernel/x86/microcode/GenuineIntel.bin
+echo '# everything seems ok'
+

Bug#1072538: dracut-core: systemd-cryptsetup missing from generated image

[Mourad De Clerck]

Package: dracut-core
Version: 102-1
Severity: important

Hi,

As of version 102-1 the generated initrd leaves my system unbootable, as my root
filesystem in luks-encrypted.

After investigating it looks like the systemd-cryptsetup binary is simply 
missing.

I looked through /usr/lib/dracut/modules.d/90crypt/module-setup.sh and couldn't
find an instance where this binary is installed.

I added the line:

inst_multiple systemd-cryptsetup cryptsetup

… to the install() function of that file, regenerated my initrd, and it works 
again.

It'd be nice to get a proper fix.

Thank you,

-- Mourad DC

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

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

Versions of packages dracut-core depends on:
ii  cpio2.15+dfsg-1
ii  dracut-install  102-1
ii  e2fsprogs   1.47.1-1
ii  kmod32+20240327-1
ii  libc6   2.38-12
ii  libkmod232+20240327-1
ii  udev256~rc3-7

Versions of packages dracut-core recommends:
ii  binutils   2.42-4
pn  console-setup  
ii  cryptsetup 2:2.7.2-2
pn  dmraid 
ii  dmsetup2:1.02.196-1+b1
ii  kpartx 0.9.7-7
pn  lvm2   
pn  mdadm  
ii  pigz   2.8-1
ii  pkgconf1.8.1-1+b2
ii  systemd256~rc3-7

dracut-core suggests no packages.

-- no debconf information

Bug#1072537: ostinato: Ostinato is no longer open-source since April 2024

[Bernhard Ehlers]

Package: ostinato
Version: 1.3.0-1+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: behl...@mailbox.org

Dear Maintainer,

in April 2024 it was announced, that Ostinato is no longer open-source,
for details see .

So I think, that Ostinato should be removed from future Debian versions.


Best regards

Bernhard Ehlers


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

Kernel: Linux 6.1.0-21-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages ostinato depends on:
ii  libc6  2.38-10
ii  libgcc-s1  14-20240330-1
ii  libnl-3-2003.7.0-0.3
ii  libnl-route-3-200  3.7.0-0.3
ii  libpcap0.8t64  1.10.4-5
ii  libprotobuf32t64   3.21.12-8.2
ii  libqt5core5t64 5.15.13+dfsg-2
ii  libqt5gui5t64  5.15.13+dfsg-2
ii  libqt5network5t64  5.15.13+dfsg-2
ii  libqt5script5  5.15.13+dfsg-2
ii  libqt5widgets5t64  5.15.13+dfsg-2
ii  libstdc++6 14-20240330-1

Versions of packages ostinato recommends:
ii  gawk   1:5.2.1-2+b1
ii  tshark 4.2.5-1
ii  wireshark  4.2.5-1

ostinato suggests no packages.

-- no debconf information

Bug#1059372: amd64-microcode: diff for NMU version 3.20240116.2+nmu1

[Chris Hofstaedtler]

Control: tags 1059372 + patch
Control: tags 1059372 + pending


Dear maintainer,

I've prepared an NMU for amd64-microcode (versioned as 3.20240116.2+nmu1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru amd64-microcode-3.20240116.2/debian/amd64-microcode.dirs amd64-microcode-3.20240116.2+nmu1/debian/amd64-microcode.dirs
--- amd64-microcode-3.20240116.2/debian/amd64-microcode.dirs	2024-02-15 20:56:06.0 +0100
+++ amd64-microcode-3.20240116.2+nmu1/debian/amd64-microcode.dirs	2024-06-03 22:40:58.0 +0200
@@ -1,5 +1,5 @@
 etc/default
 etc/modprobe.d
-lib/firmware/amd-ucode
-lib/firmware/amd
-lib/firmware/amdtee
+usr/lib/firmware/amd-ucode
+usr/lib/firmware/amd
+usr/lib/firmware/amdtee
diff -Nru amd64-microcode-3.20240116.2/debian/amd64-microcode.install amd64-microcode-3.20240116.2+nmu1/debian/amd64-microcode.install
--- amd64-microcode-3.20240116.2/debian/amd64-microcode.install	2024-02-15 20:56:06.0 +0100
+++ amd64-microcode-3.20240116.2+nmu1/debian/amd64-microcode.install	2024-06-03 22:41:10.0 +0200
@@ -1,3 +1,3 @@
-amd-ucode/*bin	lib/firmware/amd-ucode
-amdtee/*lib/firmware/amdtee
-amd/*sev*bin	lib/firmware/amd
+amd-ucode/*bin	usr/lib/firmware/amd-ucode
+amdtee/*usr/lib/firmware/amdtee
+amd/*sev*bin	usr/lib/firmware/amd
diff -Nru amd64-microcode-3.20240116.2/debian/changelog amd64-microcode-3.20240116.2+nmu1/debian/changelog
--- amd64-microcode-3.20240116.2/debian/changelog	2024-02-15 20:56:06.0 +0100
+++ amd64-microcode-3.20240116.2+nmu1/debian/changelog	2024-06-03 22:41:28.0 +0200
@@ -1,3 +1,10 @@
+amd64-microcode (3.20240116.2+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Install files into /usr instead of /. (Closes: 1059372)
+
+ -- Chris Hofstaedtler   Mon, 03 Jun 2024 22:41:28 +0200
+
 amd64-microcode (3.20240116.2) unstable; urgency=medium
 
   * Add AMD-TEE firmware to the package (closes: #1062678)
diff -Nru amd64-microcode-3.20240116.2/debian/initramfs.hook amd64-microcode-3.20240116.2+nmu1/debian/initramfs.hook
--- amd64-microcode-3.20240116.2/debian/initramfs.hook	2024-02-06 19:46:38.0 +0100
+++ amd64-microcode-3.20240116.2+nmu1/debian/initramfs.hook	2024-06-03 22:41:23.0 +0200
@@ -31,7 +31,7 @@
 :
 }
 
-AUCODE_FW_DIR=/lib/firmware/amd-ucode
+AUCODE_FW_DIR=/usr/lib/firmware/amd-ucode
 AMD64UCODE_INITRAMFS=auto
 [ -r ${AMD64UCODE_CONFIG} ] && . ${AMD64UCODE_CONFIG}
 

Bug#1072389: patches to make cruft-ng work without locate

[Alexandre Detiste]

Le lun. 3 juin 2024 à 21:32, Jochen Sprickerhof  a écrit :
> >The scripts in explain/ ought to be run inside the chroot.
>
> Good point. You could actually use unshare to make it work without root
> but I would also prefer option 2.
> What do you think of a slow adoption as in explain.cc
> set's the DPKG_ROOT variable and all explain scripts
> get a test -z $DPKG_ROOT || exit 0 at the top.
> Then we can fix them individually as far as it makes sense.

Let's do that, that's the simplest.

cruft is 25 years old, at least all the Perl parts are gone
but some of these scripts are not my style.

> There are also some the only make sense on a running system like WSL2
> where I would just keep the exit 0 at the top.

Also AUTOPKGTEST & cowdancer
They don't need any change at all.

For example $COWDANCER_ILISTFILE & $DPKG_ROOT
would never be set a the same time.

> >You can fork this on Salsa which is now the main repository.
>
> Right, do you prefer a merge request there?

I gave you write access.


This could be team-managed but I don't know inside which team it would fit.
Maybe QA ? Maybe here: https://packages.debian.org/unstable/forensics-all

I use it nowadays to guess what messy people did before me on some filesystems,
they were merely lazy, not evil, they did not tried to hide their tweaks at all;
I don't know if that count as forensics.

Greetings

Bug#1072536: RFS: git-credential-azure/0.3.0-1 -- Git credential helper for Azure Repos

[M Hickford]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "git-credential-azure":

 * Package name : git-credential-azure
   Version  : 0.3.0-1
   Upstream contact : M Hickford 
 * URL  : https://github.com/hickford/git-credential-azure
 * License  : Apache-2.0
 * Vcs  :
https://salsa.debian.org/go-team/packages/git-credential-azure
   Section  : golang

The source builds the following binary packages:

  git-credential-azure - Git credential helper for Azure Repos

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

  https://mentors.debian.net/package/git-credential-azure/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/git-credential-azure/git-credential-azure_0.3.0-1.dsc

Changes since the last upload:

 git-credential-azure (0.3.0-1) unstable; urgency=medium
 .
   * New upstream version

Regards,
-- 
  M Hickford

Bug#1072535: puma: flaky autopkgtest

[Paul Gevers]

Source: puma
Version: 6.4.2-4
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of your package because it 
showed up as regression for glibc. I noticed that it regularly fails. 
This particularly on happens on amd64, where our host is used to run 
many tests in parallel, so this may be a race condition under load.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

https://ci.debian.net/packages/p/puma/testing/amd64/47272763/

189s   1) Error:
189s TestPluginSystemd#test_systemd_notify_usr2_hot_restart_cluster:
189s Errno::EPIPE: Broken pipe
189s 
/tmp/autopkgtest-lxc.7lvlk_yq/downtmp/build.uxb/src/test/test_plugin_systemd.rb:90:in 
`write'
189s 
/tmp/autopkgtest-lxc.7lvlk_yq/downtmp/build.uxb/src/test/test_plugin_systemd.rb:90:in 
`assert_restarts_with_systemd'
189s 
/tmp/autopkgtest-lxc.7lvlk_yq/downtmp/build.uxb/src/test/test_plugin_systemd.rb:42:in 
`test_systemd_notify_usr2_hot_restart_cluster'
189s 
/tmp/autopkgtest-lxc.7lvlk_yq/downtmp/build.uxb/src/test/helper.rb:90:in 
`block (4 levels) in run'

189s /usr/lib/ruby/3.1.0/timeout.rb:107:in `block in timeout'
189s /usr/lib/ruby/3.1.0/timeout.rb:117:in `timeout'
189s 
/tmp/autopkgtest-lxc.7lvlk_yq/downtmp/build.uxb/src/test/helper.rb:88:in 
`block (3 levels) in run'


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072534: RFS: git-credential-oauth/0.11.3-1 -- Git credential helper for GitHub and other forges using OAuth

[M Hickford]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: debian...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "git-credential-oauth":

 * Package name : git-credential-oauth
   Version  : 0.11.3-1
   Upstream contact : M Hickford 
 * URL  : https://github.com/hickford/git-credential-oauth
 * License  : Apache-2.0
 * Vcs  :
https://salsa.debian.org/go-team/packages/git-credential-oauth
   Section  : golang

The source builds the following binary packages:

  git-credential-oauth - Git credential helper for GitHub and other
forges using OAuth

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

  https://mentors.debian.net/package/git-credential-oauth/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/git-credential-oauth/git-credential-oauth_0.11.3-1.dsc

Changes since the last upload:

 git-credential-oauth (0.11.3-1) unstable; urgency=medium
 .
   * New upstream version.

Regards,
-- 
  M Hickford

Bug#1072533: procps: flaky autopkgtest:

[Paul Gevers]

Source: procps
Version: 2:4.0.4-4
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of your package, because it 
showed up in the glibc regressions. I noticed that it regularly fails on 
amd64, ppc64el and s390x. For your info, as it seems to correlate, those 
are the architectures where multiple tests run in parallel, each in 
their own lxc container.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

E.g.

https://ci.debian.net/packages/p/procps/testing/amd64/47064938/

 52s autopkgtest [06:08:26]: test vmstat: [---
 53s test_no_arguments
 53s ASSERT:value line
 53s shunit2:ERROR test_no_arguments() returned non-zero 
return code.

 53s test_forks
 53s test_disk
 53s
 53s Ran 3 tests.
 53s
 53s FAILED (failures=2)
 53s autopkgtest [06:08:27]: test vmstat: ---]


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072492: gnupg2: [INTL:nl] Dutch translation for the gnupg2 package

[Frans Spiesschaert]

Andreas Metzler schreef op ma 03-06-2024 om 18:29 [+0200]:
> 
> Hello Frans,

Hi Andreas,

> 
> thank you. On what gnupg version did you base the translation?

The translation is based on gnupg2_2.2.43-6

>  Has it
> already been sent upstream?

I don't think so, while I didn't sent it upstream.

> 
> cu Andreas

Bug#1072532: dh-sequence-phpcomposer: stop creating libpcre3 dependencies

[Chris Hofstaedtler]

Control: affects 1072532 src:php-ml-iri
Control: affects 1072532 src:php-mockery

On Thu, May 23, 2024 at 08:18:45PM +0200, Bastian Germann wrote:
> The dependency generation in share/php/pkgtools/base/dependency.php for
> "lib-" prefixed composer dependencies needs fixing. I caught it by it using
> libpcre3, which should be libpcre2-8-0 now. But some other generated names
> are also outdated and should be brought in sync with the current php
> interpreter version.

I've cloned #1071684 as #1072532 and set it to serious, as libpcre3
dependencies really must go away now.
Given the interpreter already uses libpcre2*, they are wrong and
probably useless. Please stop generating them ASAP, so pcre3 can be
removed from testing.

Chris

Bug#1071684: pkg-php-tools: composer library dependency generation

[Chris Hofstaedtler]

Hi,

On Thu, May 23, 2024 at 08:18:45PM +0200, Bastian Germann wrote:
> The dependency generation in share/php/pkgtools/base/dependency.php for
> "lib-" prefixed composer dependencies needs fixing. I caught it by it using
> libpcre3, which should be libpcre2-8-0 now. But some other generated names
> are also outdated and should be brought in sync with the current php
> interpreter version.

I've cloned this bug and set it to serious, as libpcre3 dependencies
really must go away now.
Given the interpreter already uses libpcre2*, they are wrong and
useless. Please stop generating them ASAP, so pcre3 can be removed
from testing.

Chris

Bug#1072389: patches to make cruft-ng work without locate

[Jochen Sprickerhof]

Hi Alexandre,

* Alexandre Detiste  [2024-06-03 10:04]:

The scripts in explain/ ought to be run inside the chroot.

The systemd script for example was already adapted to work without a
running init.

This could be done with chroot() and a bind mount of /usr/libexec/cruft or
alternatively modifying every script to support DPKG_ROOT.

I think option 1 will require root while option 2 will work in the non-root
mode too.

I slightly prerer option 2 which allows more case-by-case handling.


Good point. You could actually use unshare to make it work without root 
but I would also prefer option 2. What do you think of a slow adoption 
as in explain.cc set's the DPKG_ROOT variable and all explain scripts 
get a test -z $DPKG_ROOT || exit 0 at the top. Then we can fix them 
individually as far as it makes sense.


I also had a quick look into them, for those just running find and echo 
it should be ease to adopt. For those running dpkg-query or 
update-alternatives and alike there is a --root option we could use. 
There are also some the only make sense on a running system like WSL2 
where I would just keep the exit 0 at the top.



You can fork this on Salsa which is now the main repository.


Right, do you prefer a merge request there?

Cheers Jochen


signature.asc
Description: PGP signature

Bug#1000015: mp4h: diff for NMU version 1.3.1-17.1

[Chris Hofstaedtler]

Dear maintainer,

I've prepared an NMU for mp4h (versioned as 1.3.1-17.1). The diff
is attached to this message.

Regards.

diff -Nru mp4h-1.3.1/debian/changelog mp4h-1.3.1/debian/changelog
--- mp4h-1.3.1/debian/changelog	2018-06-27 02:04:54.0 +0200
+++ mp4h-1.3.1/debian/changelog	2024-06-03 21:06:36.0 +0200
@@ -1,3 +1,13 @@
+mp4h (1.3.1-17.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Yavor Doganov ]
+  * debian/patches/pcre2.patch: New; port to PCRE2 (Closes: #115).
+  * debian/control (Build-Depends): Replace libpcre3-dev with libpcre2-dev.
+
+ -- Chris Hofstaedtler   Mon, 03 Jun 2024 21:06:36 +0200
+
 mp4h (1.3.1-17) unstable; urgency=medium
 
   [ Axel Beckert ]
diff -Nru mp4h-1.3.1/debian/control mp4h-1.3.1/debian/control
--- mp4h-1.3.1/debian/control	2018-06-27 01:46:42.0 +0200
+++ mp4h-1.3.1/debian/control	2024-06-03 21:06:14.0 +0200
@@ -9,7 +9,7 @@
fakeroot,
gettext,
libltdl-dev,
-   libpcre3-dev,
+   libpcre2-dev,
libtool,
tidy
 Build-Conflicts: autoconf2.13,
diff -Nru mp4h-1.3.1/debian/patches/pcre2.patch mp4h-1.3.1/debian/patches/pcre2.patch
--- mp4h-1.3.1/debian/patches/pcre2.patch	1970-01-01 01:00:00.0 +0100
+++ mp4h-1.3.1/debian/patches/pcre2.patch	2024-06-03 21:06:14.0 +0200
@@ -0,0 +1,449 @@
+Description: Port to PCRE2.
+Bug-Debian: https://bugs.debian.org/115
+Author: Yavor Doganov 
+Forwarded: no
+Last-Update: 2023-12-10
+---
+
+--- mp4h.orig/src/Makefile.am
 mp4h/src/Makefile.am
+@@ -17,7 +17,7 @@
+ if LOADABLE_MODULES
+ mp4h_LDFLAGS = -export-dynamic
+ endif
+-mp4h_LDADD   = -lm $(top_builddir)/lib/libmp4h.a -lpcre @LIBINTL@ $(MODULE_LDADD)
++mp4h_LDADD   = -lm $(top_builddir)/lib/libmp4h.a -lpcre2-8 @LIBINTL@ $(MODULE_LDADD)
+ 
+ include_HEADERS = mp4h.h
+ noinst_HEADERS  = builtin.h
+--- mp4h.orig/src/builtin.c
 mp4h/src/builtin.c
+@@ -373,7 +373,7 @@
+ static char * utf8char_skip __P ((char *, int));
+ static int utf8char_strlen __P ((char *));
+ static int encoding_strlen __P ((char *));
+-static void substitute __P ((struct obstack *, const char *, const char *, int *));
++static void substitute __P ((struct obstack *, const char *, const char *, size_t *));
+ static void string_regexp __P ((struct obstack *, int, token_data **, int, const char *));
+ static void subst_in_string __P ((struct obstack *, int, token_data **, int));
+ static void generic_variable_lookup __P ((MP4H_BUILTIN_PROTO, boolean));
+@@ -382,6 +382,8 @@
+ static int array_member __P ((const char *, symbol *, boolean));
+ static int sort_function __P ((const void *, const void *));
+ static void logical_to_physical_paths __P ((char **));
++static void * pcre_malloc (size_t, void *);
++static void pcre_free (void *, void *);
+ 
+ /*  This symbol controls breakings of flow statements.  */
+ static symbol varbreak;
+@@ -398,7 +400,12 @@
+ struct lconv *my_locale;
+ 
+ /*  Table of characters used by PCRE with non-C locales  */
+-static const unsigned char *re_tableptr = NULL;
++static const uint8_t *re_tableptr = NULL;
++
++/*  PCRE contexts needed for custom memory management and adding
++non-builtin character tables.  */
++static pcre2_general_context *gen_ctxt;
++static pcre2_compile_context *comp_ctxt;
+ 
+ /*  Timer  */
+ static struct tms elapsed_time;
+@@ -662,12 +669,22 @@
+ | Initialise all builtin and predefined macros.  |
+ `---*/
+ 
++static void *
++pcre_malloc (size_t size, void *ptr)
++{
++  return xmalloc (size);
++}
++
++static void
++pcre_free (void *ptr, void *tag)
++{
++  xfree (ptr);
++}
++
+ void
+ builtin_init (void)
+ {
+   install_builtin_table (builtin_tab);
+-  pcre_malloc = xmalloc;
+-  pcre_free   = xfree;
+ }
+ 
+ /*---.
+@@ -688,18 +705,22 @@
+   varstack_check ();
+ }
+ 
+-static pcre *
++static pcre2_code *
+ xre_compile (const char *pattern, int cflags)
+ {
+-  pcre *patcomp;
+-  const char *errbuf;
+-  int erroffset;
++  pcre2_code *patcomp;
++  PCRE2_UCHAR errbuf[120];
++  int errcode;
++  size_t erroffset;
+ 
+   if (document_encoding == ENCODING_UTF8)
+-  cflags |= PCRE_UTF8;
+-  patcomp = pcre_compile (pattern, cflags, , , re_tableptr);
++  cflags |= PCRE2_UTF;
++  pcre2_set_character_tables (comp_ctxt, re_tableptr);
++  patcomp = pcre2_compile ((PCRE2_SPTR) pattern, PCRE2_ZERO_TERMINATED,
++   cflags, , , comp_ctxt);
+   if (patcomp == 0)
+ {
++  pcre2_get_error_message (errcode, errbuf, sizeof (errbuf));
+   MP4HERROR ((warning_status, 0,
+ _("Warning:%s:%d: Bad regular expression `%s' at position %d: %s"),
+  CURRENT_FILE_LINE, pattern, erroffset, errbuf));
+@@ -822,11 +843,10 @@
+   register char *cp;
+   char *name;
+   int i, j, special_chars;
+-  pcre *re;
+-  pcre_extra *re_extra = NULL;
+-  const char *errptr = NULL;
++  

Bug#1072531: 389-ds-base: CVE-2024-2199

[Moritz Mühlenhoff]

Source: 389-ds-base
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for 389-ds-base.

CVE-2024-2199[0]:
| A denial of service vulnerability was found in 389-ds-base ldap
| server. This issue may allow an authenticated user to cause a server
| crash while modifying `userPassword` using malformed input.

https://bugzilla.redhat.com/show_bug.cgi?id=2267976


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-2024-2199
https://www.cve.org/CVERecord?id=CVE-2024-2199

Please adjust the affected versions in the BTS as needed.

Bug#1072530: smarty3: CVE-2024-35226

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for smarty3.

CVE-2024-35226[0]:
| Smarty is a template engine for PHP, facilitating the separation of
| presentation (HTML/CSS) from application logic. In affected versions
| template authors could inject php code by choosing a malicious file
| name for an extends-tag. Sites that cannot fully trust template
| authors should update asap. All users are advised to update. There
| is no patch for users on the v3 branch. There are no known
| workarounds for this vulnerability.

https://github.com/smarty-php/smarty/security/advisories/GHSA-4rmg-292m-wg3w
https://github.com/smarty-php/smarty/commit/76881c8d33d80648f70c9b0339f770f5f69a87a2
 (support/4)
https://github.com/smarty-php/smarty/commit/0be92bc8a6fb83e6e0d883946f7e7c09ba4e857a
 (v5.2.0)


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-2024-35226
https://www.cve.org/CVERecord?id=CVE-2024-35226

Please adjust the affected versions in the BTS as needed.

Bug#1072529: smarty4: CVE-2024-35226

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for smarty4.

CVE-2024-35226[0]:
| Smarty is a template engine for PHP, facilitating the separation of
| presentation (HTML/CSS) from application logic. In affected versions
| template authors could inject php code by choosing a malicious file
| name for an extends-tag. Sites that cannot fully trust template
| authors should update asap. All users are advised to update. There
| is no patch for users on the v3 branch. There are no known
| workarounds for this vulnerability.

https://github.com/smarty-php/smarty/security/advisories/GHSA-4rmg-292m-wg3w
https://github.com/smarty-php/smarty/commit/76881c8d33d80648f70c9b0339f770f5f69a87a2
 (support/4)
https://github.com/smarty-php/smarty/commit/0be92bc8a6fb83e6e0d883946f7e7c09ba4e857a
 (v5.2.0)


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-2024-35226
https://www.cve.org/CVERecord?id=CVE-2024-35226

Please adjust the affected versions in the BTS as needed.

Bug#635834: Revisiting inclusion of AcroTeX/eForms in TeX Live in light of advancements in libre PDF readers

[John Scott]

Hello,

I must disclaim that I've not used these packages yet and would welcome being 
informed if I'm mistaken.

It looks like both TeX Live and Debian have had reservations about shipping 
AcroTeX and eForms because at the time it was considered, the only PDF readers 
that appeared to support the features were proprietary ones. However, it seems 
that free PDF viewers have made great strides in the past several years 
especially in supporting these advanced features, so I think their inclusion in 
the standard distribution should be reconsidered.

Free PDF viewers, especially Okular with the Poppler backend, have gained 
support for many of the features that have been standardized, including non-XFA 
forms, digital/cryptographic signature support, and JavaScript, all things that 
eForms appears to assist in making. There are probably still some things that 
AcroTeX and eForms can do that only proprietary readers support, but unless 
software patents muddy the waters, it seems like this can improve in client 
software at any time.

Frankly I'm itching to use this functionality in my documents, but as a strong 
advocate for free software as well, I'd like to be informed if there are any 
freedom or distribution issues remaining.

Thanks,
John

P.S. I'm having trouble subscribing, so please CC me on replies.

-- 
Homepage: https://johnscott.me
Contact info:
as a vCard: https://johnscott.me/me/me.vcf
or as an LDAP directory entry: 
ldap://johnscott.me/CN=John%20Scott,DC=johnscott,DC=me


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


smime.p7s
Description: S/MIME cryptographic signature

Bug#1072528: tcpdf: CVE-2024-22641

[Moritz Mühlenhoff]

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

Hi,

The following vulnerability was published for tcpdf. I realise
you're aware given you replied to the upstream issue, but also
filing in the BTS for completeness:

CVE-2024-22641[0]:
| TCPDF version 6.6.5 and before is vulnerable to ReDoS (Regular
| Expression Denial of Service) if parsing an untrusted SVG file.

https://github.com/tecnickcom/TCPDF/issues/724


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-2024-22641
https://www.cve.org/CVERecord?id=CVE-2024-22641

Please adjust the affected versions in the BTS as needed.

Bug#1072527: Mark libreswan as EOLed in Bullseye

[Moritz Muehlenhoff]

Source: debian-security-support
Version: 1:13+2024.05.15
Severity: wishlist
X-Debbugs-Cc: d...@fifthhorseman.net

Security support for libreswan in Bullseye is EOLed, the recent
security fixes for CVE-2023-38710 are too intrusive/risky to
backport (also see https://github.com/libreswan/libreswan/issues/1233)

Cheers,
Moritz

Bug#1058769: amazon-ec2-net-utils: diff for NMU version 2.4.1-1.1

[Chris Hofstaedtler]

* Noah Meyerhans  [240603 20:48]:
> On Thu, May 30, 2024 at 04:54:07PM +0200, Chris Hofstaedtler wrote:
> > I've prepared an NMU for amazon-ec2-net-utils (versioned as 2.4.1-1.1) and
> > uploaded it to DELAYED/14. Please feel free to tell me if I
> > should delay it longer.
> 
> Hi Chris. Please cancel the NMU; I just uploaded 2.4.1-2 built from the
> cloud team's git repo to include this change.

Cancelled.

Thanks!

Chris

Bug#1058769: amazon-ec2-net-utils: diff for NMU version 2.4.1-1.1

[Noah Meyerhans]

On Thu, May 30, 2024 at 04:54:07PM +0200, Chris Hofstaedtler wrote:
> I've prepared an NMU for amazon-ec2-net-utils (versioned as 2.4.1-1.1) and
> uploaded it to DELAYED/14. Please feel free to tell me if I
> should delay it longer.

Hi Chris. Please cancel the NMU; I just uploaded 2.4.1-2 built from the
cloud team's git repo to include this change.

Thanks

noah

Bug#1010445: mono-complete: Mono package in Debian is very outdated (6.8 but should be 6.12)

[Andrey Rakhmatullin]

On Mon, Jun 03, 2024 at 06:49:13PM +0200, Antoine Le Gonidec wrote:
> Please consider lowering this bug report severity.
> 
> While it would indeed be really nice to get a more recent build of Mono
> in Debian repositories (I am sure the Debian Mono Group would be happy
> to get help with this)
(assuming it still exists)

> keeping the current outdated build is much more useful than not having
> access to Mono at all from Debian repositories.
Considering the amount of packages depending on mono, removing it from
testing is probably out of question anyway, but that's up tio the Release
and Security teams. Also, "keeping the outdated unmaintained package is
better than not keeping it" is overturned by one of those teams quite
often.

> More generally requests for the packaging of new upstream releases
> tend to use a "wishlist" severity level, not "important" and even less
> "serious".
Indeed, the completely correct state would be a wishlist bug "the version
is too old" and a serious bug "the package is unmaintained", with the
exactly same result but more paperwork, but it's a common practice to not
make a separate bug report of the second type and just bump the severity
of a related one.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#1072526: netcfg removes DHCP ipv6 addresses after configuration finishes

[Steffen Kieß]

Package: netcfg
Version: 1.187

When netcfg is finished configuring the interface, it will call 
kill_dhcp_client() (from netcfg_activate_dhcp()), which will send 
SIGTERM and then SIGKILL to dhcp6c. When dhcp6c gets a SIGTERM, it will 
send a DHCP6 Release message and remove the IP from the interface, which 
means that the installer will have no (public) IP anymore, and 
installation from network will fail.


This happens both in an IPv6-only and in a dual-stack configuration 
(though in a dual-stack configuration there still will be an IPv4 
address, which means the installation will probably succeed).


A possible workaround is to switch to another console with Alt+F3 after 
the DHCP6 configuration was done but before netcfg finishes and kill the 
dhcp6c process with -9 (to prevent it from releasing the IP).

Bug#1071187: battery-stats: battery-graph error: unrecognized option -title

[gregor herrmann]

Control: tag -1 + patch

> % battery-graph 
> unrecognized option -title
> line 0: Cannot load input from 'Battery Graph'

Attached is a patch which fixes this issue for me.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
--- a/usr/bin/battery-graph	2024-01-20 00:52:13.0 +0100
+++ b/usr/bin/battery-graph	2024-06-03 19:35:42.271192074 +0200
@@ -184,6 +184,10 @@
 
 
 (   
+if [ -n "$title" ] ; then
+	echo "set title \"$title\""
+fi
+
 if $text ; then
 	echo set terminal dumb ${COLUMNS:-$(tput cols)} ${LINES:-$(tput lines)}
 fi
@@ -218,7 +222,7 @@
 		echo ", g(x -($TIME_LAST_DISCHARGE_BEGIN-$adjustment) ) title (B<0?sprintf(\"slope= (%.2f +/- %.2f) %/h\", B*3600, B_err*3600):\"\") lc rgb \"black\" lt 2 "
 fi
 
-)  | gnuplot -persist ${geometry:+-geometry} $geometry ${title:+-title} "${title}" ; rm -f $TMPFILENAME
+)  | gnuplot -persist ${geometry:+-geometry} $geometry ; rm -f $TMPFILENAME
 
 
 # TODO Have to decide if we want to clean up or leave the file for us to zoom in/out in the graph


signature.asc
Description: Digital Signature

Bug#1072524: systemd: On a debian trixie, after upgrading systemd to latest version the system fails to reboot.

[Luca Boccassi]

On Mon, 3 Jun 2024 at 18:29, Christophe Trophime
 wrote:
>
> Hi,
> could you please just tell what info do you need?

As already mentioned: did you customize the kernel command line?
Cgroupsv2 has been the default for years

> - Original Message -
> > From: "Luca Boccassi" 
> > To: 1072...@bugs.debian.org
> > Cc: "Christophe Trophime" 
> > Sent: Monday, June 3, 2024 6:53:19 PM
> > Subject: Re: systemd: On a debian trixie, after upgrading systemd to latest 
> > version the system fails to reboot.
>
> > Control: tags -1 moreinfo
> >
> > On Mon, 03 Jun 2024 18:41:12 +0200 Christophe Trophime
> >  wrote:
> >> Package: systemd
> >> Version: 256~rc3
> >> Severity: important
> >> X-Debbugs-Cc: christophe.troph...@lncmi.cnrs.fr
> >>
> >> Dear Maintainer,
> >>
> >> After upgrading systemd the machine does not reboot.
> >> The error message says:
> >>
> >> systemd freezing execution
> >> refusing to run under cgroup v1, SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1
> >> shall be passed to kernel command line
> >>
> >>
> >> As far as I have understood cgroup v1 is no longer supported.
> >> So I think I have 2 choices:
> >> * add the variable to the kernel starting command line,
> >> * disable cgroup v1
> >>
> >> The point is that I cannot figure out how to do?
> >> Cannot find how to set the variable, nor how to eventually disable
> >> cgroup v1?
> >>
> >> Which packages may use the cgroup v1 features?
> >> I'm using container tools like docker (nvidia-container), singularity
> > and charliecloud
> >>
> >> Thanks for your help
> >> Best
> >> C
> >>
> >> PS: cannot provide any additional info about my debian trixie host.
> >
> > cgroupsv2 is the default and has been since Bookworm, did you apply
> > some custom kernel command line that disables it?
> >
> > --
> > Kind regards,
> > Luca Boccassi

Bug#1072525: s390x install Debootstrap warning

[Berli Gayathri]

Package: installation-reports

When I tried installing  different debian images(buster, bookworm and sid) I 
run into this Problem (from log console ):

in the /var/log/syslog I have seen installation is failing because of packages 
breaking which are not installed yet
May 27 10:02:59 debootstrap: dpkg: error processing package s390-tools 
(--configure):
May 27 10:02:59 debootstrap:  dependency problems - leaving unconfigured
May 27 10:02:59 debootstrap: Errors were encountered while processing:
May 27 10:02:59 debootstrap:  s390-tools
May 27 10:03:00 debootstrap: dpkg: dependency problems prevent configuration of 
s390-tools:
May 27 10:03:00 debootstrap:  s390-tools depends on libcurl4 (>= 7.16.2); 
however:
May 27 10:03:00 debootstrap:   Package l
May 27 10:03:00 debootstrap: ibcurl4 is not installed.
May 27 10:03:00 debootstrap:  s390-tools depends on libfuse2 (>= 2.8); however:
May 27 10:03:00 debootstrap:   Package libfuse2 is not installed.
May 27 10:03:00 debootstrap:
May 27 10:03:00 debootstrap: dpkg: error processing package s390-tools 
(--configure):
May 27 10:03:00 debootstrap:  dependency problems - leaving unconfigured
May 27 10:03:00 debootstrap: Errors were encountered while processing:
May 27 10:03:00 debootstrap:  s390-tools
May 27 10:03:01 debootstrap: dpkg: dependency problems prevent configuration of 
s390-tools:
May 27 10:03:01 debootstrap:  s390-tools depends on libcurl4 (>= 7.16.2); 
however:
May 27 10:03:01 debootstrap:   Package l
May 27 10:03:01 debootstrap: ibcurl4 is not installed.
May 27 10:03:01 debootstrap:  s390-tools depends on libfuse2 (>= 2.8); however:
May 27 10:03:01 debootstrap:   Package libfuse2 is not installed.
May 27 10:03:01 debootstrap:
May 27 10:03:01 debootstrap: dpkg: error processing package s390-tools 
(--configure):
May 27 10:03:01 debootstrap:  dependency problems - leaving unconfigured
May 27 10:03:01 debootstrap: Errors were encountered while processing:
May 27 10:03:01 debootstrap:  s390-tools
May 27 10:45:27 base-installer: error: exiting on error 
base-installer/debootstrap-failed
May 27 10:45:33 main-menu[382]: WARNING **: Configuring 'bootstrap-base' failed 
with error code 1
May 27 10:45:33 main-menu[382]: WARNING **: Menu item 'bootstrap-base' failed.
May 27 10:45:40 main-menu[382]: INFO: Modifying debconf priority limit from 
'high' to 'medium'
May 27 10:45:40 debconf: Setting debconf/priority to medium
May 27 10:45:40 depthcharge-tools-installer: Not installing to non-ChromeOS 
board.
May 27 10:46:59 main-menu[382]: INFO: Menu item 'di-utils-shell' selected



Installation failed in step install base system, not only with the debian 
buster but also with the debian bookworm and the latest sid images as well. The 
link below points to the place from where I picked the images.

https://snapshot.debian.org/archive/debian/20220731T213859Z/dists/bookworm/main/installer-s390x/20210731/images/generic/
https://d-i.debian.org/daily-images/s390x/daily/generic/


The final error message, while installing the Debian from GUI based installer 
is as below.
Warning: Failure while configuring base pacakges. This will be re-attempted up 
to five times.


The same issue I have seen while trying to setup the qemu host on the x86 
architecture for s390x target
$qemu-system-s390x -blockdev 
driver=file,node-name=dasd1,filename=/root/gayathri/LPAR/debian-buster-DI-rc1-s390x-netinst.iso
 -device virtio-scsi -device scsi-cd,drive=dasd1,bootindex=1 -nographic
LOADPARM=[]
Using virtio-scsi.
SCSI CD-ROM detected.
! Cannot IPL this ISO image !

Thanks,
Berli Gayathri.

Bug#1010445: mono-complete: Mono package in Debian is very outdated (6.8 but should be 6.12)

[Antoine Le Gonidec]

Please consider lowering this bug report severity.

While it would indeed be really nice to get a more recent build of Mono
in Debian repositories (I am sure the Debian Mono Group would be happy
to get help with this), keeping the current outdated build is much more
useful than not having access to Mono at all from Debian repositories.

Here we rely extensively on the Debian-provided 6.8 build to run
non-free games built on top of the XNA/FNA engine through
./play.it (https://wiki.debian.org/Games/PlayIt). Losing these packages
would make us rely on the binaries and libraries shipped by the game
developers instead, that are usually older than the current Debian
build.

More generally requests for the packaging of new upstream releases
tend to use a "wishlist" severity level, not "important" and even less
"serious".


pgpLS55jyDxJZ.pgp
Description: Signature digitale OpenPGP

Bug#1072524: systemd: On a debian trixie, after upgrading systemd to latest version the system fails to reboot.

[Luca Boccassi]

Control: tags -1 moreinfo

On Mon, 03 Jun 2024 18:41:12 +0200 Christophe Trophime
 wrote:
> Package: systemd
> Version: 256~rc3
> Severity: important
> X-Debbugs-Cc: christophe.troph...@lncmi.cnrs.fr
> 
> Dear Maintainer,
> 
> After upgrading systemd the machine does not reboot.
> The error message says:
> 
> systemd freezing execution
> refusing to run under cgroup v1, SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1
> shall be passed to kernel command line
> 
> 
> As far as I have understood cgroup v1 is no longer supported.
> So I think I have 2 choices:
> * add the variable to the kernel starting command line,
> * disable cgroup v1
> 
> The point is that I cannot figure out how to do?
> Cannot find how to set the variable, nor how to eventually disable
> cgroup v1?
> 
> Which packages may use the cgroup v1 features?
> I'm using container tools like docker (nvidia-container), singularity
and charliecloud
> 
> Thanks for your help
> Best
> C
> 
> PS: cannot provide any additional info about my debian trixie host.

cgroupsv2 is the default and has been since Bookworm, did you apply
some custom kernel command line that disables it?

-- 
Kind regards,
Luca Boccassi


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

Bug#1072524: systemd: On a debian trixie, after upgrading systemd to latest version the system fails to reboot.

[Christophe Trophime]

Package: systemd
Version: 256~rc3
Severity: important
X-Debbugs-Cc: christophe.troph...@lncmi.cnrs.fr

Dear Maintainer,

After upgrading systemd the machine does not reboot.
The error message says:

systemd freezing execution
refusing to run under cgroup v1, SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1
shall be passed to kernel command line


As far as I have understood cgroup v1 is no longer supported.
So I think I have 2 choices:
* add the variable to the kernel starting command line,
* disable cgroup v1

The point is that I cannot figure out how to do?
Cannot find how to set the variable, nor how to eventually disable
cgroup v1?

Which packages may use the cgroup v1 features?
I'm using container tools like docker (nvidia-container), singularity and 
charliecloud

Thanks for your help
Best
C

PS: cannot provide any additional info about my debian trixie host.

Bug#1072522: cozy: File conflict with blackbox-terminal/0.14.0-3: /usr/share/icons/hicolor/scalable/actions/settings-symbolic.svg

[Manuel Traut]

Hi Axel,

thanks for reporting.

On Mon, Jun 03, 2024 at 05:08:41PM +0200, Axel Beckert wrote:
> Package: cozy
> Severity: serious
> Version: 1.3.0-2
> Control: affects -1 blackbox-terminal
> 
> Hi Manuel,
> 
> installing cozy fails if blackbox-terminal (at least at version
> 0.14.0-3) is also installed due to a file conflict at
> /usr/share/icons/hicolor/scalable/actions/settings-symbolic.svg (and
> potentially further files as dpkg always only reports the first
> occurrence):
> 
> Preparing to unpack .../11-cozy_1.3.0-2_all.deb ...
> Unpacking cozy (1.3.0-2) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-RrJabH/11-cozy_1.3.0-2_all.deb (--unpack):
>  trying to overwrite 
> '/usr/share/icons/hicolor/scalable/actions/settings-symbolic.svg', which is 
> also in package blackbox-terminal 0.14.0-3
> 
> The probably easiest and cleanest way to fix this is to rename the
> file. Best way would be if neither package would use such a generic file
> name. (X-Debbugs-Cc'ed the blackbox-terminal maintainers.)
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
> (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), 
> (1, 'buildd-experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: sysvinit (via /sbin/init)
> LSM: AppArmor: enabled

I pushed a version that shall fix this bug to salsa.

Can you please have a quick look and if it is OK for you, it would be nice if
you could upload the package.

Thanks
Manuel

Bug#1072492: gnupg2: [INTL:nl] Dutch translation for the gnupg2 package

[Andreas Metzler]

On 2024-06-02 Frans Spiesschaert  wrote:
> Package: gnupg2 
> Severity: wishlist 
> Tags: l10n patch 

> Dear Maintainer, 

> Please find attached the updated Dutch po file for the gnupg2 package. 
> A draft has been posted to the debian-l10n-dutch mailing list allowing for
> review. 
> Please add it to your next package revision. 
> It should be put as "po/nl.po" in your package build tree. 
[...]

Hello Frans,

thank you. On what gnupg version did you base the translation? Has it
already been sent upstream?

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

Bug#944139: Another possible solution

[John Bazik]

I can confirm that Christopher's patch, 
https://salsa.debian.org/debian/debmirror/-/merge_requests/15, fixes the 
original problem.

John

Bug#1072515: general: Repeating cracking sound in headphones when nothing is playing.

[Christian Böck]

On Mon, 3 Jun 2024 12:42:17 +0200 Andrius Merkys  wrote:
> Hi Christian,
>
> On 2024-06-03 11:38, Christian Böck wrote:
> > when using headphones with my laptop (Thinkpad W550s) I get a repeating
> > cracking (~1sec intervalls) when nothing is playing.
>
> I have a similar issue on a workstation with Ubuntu 22.04. What is your
> operating system version? I believe the issue started manifesting once I
> installed Jack. Do you have Jack on your machine?
>
> Andrius
>
>

Hi Andrius!

I'm running an up-to-date Debian 12 64Bit (bookworm) and I don't have 
Jack installed.
After some messing with duckduckgo the problem seems to be, that the 
system puts the audio-chip to sleep, but not the headphone-amplifier.

I hope someone from Debian can fix it.

Bug#1072523: ITP: azure-nvme-utils -- Utilities to assist managing NVMe devices on Azure

[Chris Patterson]

Package: wnpp
Severity: wishlist

* Package name: azure-nvme-utils
  Version : 0.1.4
  Upstream Author : Chris Patterson 
* URL : https://github.com/Azure/azure-nvme-utils
* License : Expat
  Programming Lang: C
  Description : Utilities to assist managing NVMe devices on Azure

This package provides azure-nvme-id for NVMe device identification and udev
rules to provide symlinks using available identifiers.

Bug#1072522: cozy: File conflict with blackbox-terminal/0.14.0-3: /usr/share/icons/hicolor/scalable/actions/settings-symbolic.svg

[Axel Beckert]

Package: cozy
Severity: serious
Version: 1.3.0-2
Control: affects -1 blackbox-terminal

Hi Manuel,

installing cozy fails if blackbox-terminal (at least at version
0.14.0-3) is also installed due to a file conflict at
/usr/share/icons/hicolor/scalable/actions/settings-symbolic.svg (and
potentially further files as dpkg always only reports the first
occurrence):

Preparing to unpack .../11-cozy_1.3.0-2_all.deb ...
Unpacking cozy (1.3.0-2) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-RrJabH/11-cozy_1.3.0-2_all.deb (--unpack):
 trying to overwrite 
'/usr/share/icons/hicolor/scalable/actions/settings-symbolic.svg', which is 
also in package blackbox-terminal 0.14.0-3

The probably easiest and cleanest way to fix this is to rename the
file. Best way would be if neither package would use such a generic file
name. (X-Debbugs-Cc'ed the blackbox-terminal maintainers.)

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

Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#1072521: fakeroot hangs on some commands with faked-sysv using 100% CPU

[Pierre-Elliott Bécue]

Package: fakeroot
Version: 1.34-1
Severity: critical

Hello,

Assigning to fakeroot for now, but not sure it's not something for ftp.d.o (a
binNMU) or libc6.

Today, after an upgrade, I am not able to build packages with sbuild as
it hanks with this process tree:

(TZ is CEST)

peb 8859  0.1  0.0  24048 17644 pts/4Ss   14:15   0:09  |   \_ zsh
peb   224642  3.2  0.1  37664 32640 pts/4S+   16:24   0:00  |   |   \_ 
/usr/bin/perl /usr/bin/sbuild -As --source-only-changes
peb   224665  0.0  0.0   2596  1536 pts/4S+   16:24   0:00  |   |   
\_ /bin/sh /usr/bin/fakeroot debian/rules clean
peb   224680  0.0  0.0   6196  2304 pts/4S+   16:24   0:00  |   |   
\_ /usr/bin/make -f debian/rules clean

In parallel, one can find a faked-sysv process eating all a CPU resources.

peb   225847  100  0.0   2440   648 pts/4R+   16:25   0:02  \_ 
/usr/bin/faked-sysv

When running make -f debian/rules clean directly, everything works well.

Running it through fakeroot with strace gives:

❯ LC_ALL=C strace /bin/sh /usr/bin/fakeroot 
~/git/cgg/projects/OaaSiS/packaging/libbnxtre/libbnxtre/debian/rules clean
execve("/bin/sh", ["/bin/sh", "/usr/bin/fakeroot", 
"/home/peb/git/cgg/projects/OaaSi"..., "clean"], 0x7ffd1e5d6348 /* 66 vars */) 
= 0
brk(NULL)   = 0x55d974431000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f07e4275000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=103847, ...}, AT_EMPTY_PATH) = 0
mmap(NULL, 103847, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f07e425b000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P~\2\0\0\0\0\0"..., 832) 
= 832
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 
784, 64) = 784
newfstatat(3, "", {st_mode=S_IFREG|0755, st_size=1933688, ...}, AT_EMPTY_PATH) 
= 0
pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 
784, 64) = 784
mmap(NULL, 1985936, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f07e4076000
mmap(0x7f07e409c000, 1404928, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26000) = 0x7f07e409c000
mmap(0x7f07e41f3000, 348160, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x17d000) = 0x7f07e41f3000
mmap(0x7f07e4248000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d1000) = 0x7f07e4248000
mmap(0x7f07e424e000, 52624, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f07e424e000
close(3)= 0
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f07e4073000
arch_prctl(ARCH_SET_FS, 0x7f07e4073740) = 0
set_tid_address(0x7f07e4073a10) = 233801
set_robust_list(0x7f07e4073a20, 24) = 0
rseq(0x7f07e4074060, 0x20, 0, 0x53053053) = 0
mprotect(0x7f07e4248000, 16384, PROT_READ) = 0
mprotect(0x55d9731b3000, 8192, PROT_READ) = 0
mprotect(0x7f07e42a7000, 8192, PROT_READ) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, 
rlim_max=RLIM64_INFINITY}) = 0
munmap(0x7f07e425b000, 103847)  = 0
getuid()= 1000
getgid()= 1000
getpid()= 233801
rt_sigaction(SIGCHLD, {sa_handler=0x55d9731a8550, sa_mask=~[RTMIN RT_1], 
sa_flags=SA_RESTORER, sa_restorer=0x7f07e40b3580}, NULL, 8) = 0
geteuid()   = 1000
getrandom("\x87\x75\x90\x03\xa9\x28\xe2\x59", 8, GRND_NONBLOCK) = 8
brk(NULL)   = 0x55d974431000
brk(0x55d974452000) = 0x55d974452000
getppid()   = 233798
newfstatat(AT_FDCWD, 
"/home/peb/git/cgg/projects/OaaSiS/packaging/libbnxtre/libbnxtre", 
{st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD, ".", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
openat(AT_FDCWD, "/usr/bin/fakeroot", O_RDONLY) = 3
fcntl(3, F_DUPFD, 10)   = 10
close(3)= 0
fcntl(10, F_SETFD, FD_CLOEXEC)  = 0
geteuid()   = 1000
getegid()   = 1000
rt_sigaction(SIGINT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGINT, {sa_handler=0x55d9731a8550, sa_mask=~[RTMIN RT_1], 
sa_flags=SA_RESTORER, sa_restorer=0x7f07e40b3580}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGQUIT, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1], 
sa_flags=SA_RESTORER, sa_restorer=0x7f07e40b3580}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGTERM, {sa_handler=SIG_DFL, sa_mask=~[RTMIN RT_1], 
sa_flags=SA_RESTORER, 

Bug#1072520: bash: Update to debhelper 13; use standard dh sequence

[Gioele Barabucci]

Package: src:bash
Version: 5.2.21-2
Tags: patch

Dear bash maintainer,

could you please update the bash packaging to debhelper compat 13 and 
make `debian/rules` use the standard dh sequence?


You can find a set of patches at

https://salsa.debian.org/gioele/bash/-/compare/shell-sh...rules-std-dh

The updated `debian/rules` file is much shorter and simpler to follow 
compared to the current hand-written set of rules.


`debian/rules` could be further improved and simplified. However this 
will lead to small changes in the resulting packages.


diffoscope says that the binary packages generated using the proposed 
set of patch are identical to the current binary packages (except for 
unavoidable build ID changes in `.gnu_debuglink`).


Please note that these patches build on the `nodoc`, `rrr-no` and 
`shell-sh` series related to , 
 and .


Regards,

--
Gioele Barabucci

Bug#1072512: debci: mutter fails tests

[Jeremy Bícha]

Control: severity -1 important
Control: tags -1 upstream

On Mon, Jun 3, 2024 at 4:16 AM Drew Parsons  wrote:
> Source: mutter
> Version: 44.8-3.1
> Severity: serious
> Justification: debci
> Control: affects -1 libxcursor-dev
>
> mutter is failing tests in debci.
> This is blocking migration of libxcursor to testing.

The tests passed on retry and libxcursor is no longer blocked from
migrating. Sorry that the autopkgtests are flaky. :(

Thank you,
Jeremy Bícha

Bug#1072519: GCC 14 is slower due to --enable-checking=yes,extra,rtl

[Dimitrij Mijoski]

Package: gcc-14
Version: 14.1.0-1

GCC 14 in Debian seems to be twice as slow as GCC 13.
This was initially discovered on Reddit: 
https://www.reddit.com/r/cpp/comments/1cfzydb/gcc_14_twice_as_slow_as_gcc_13/

It seems that the following change is the cause: 
https://salsa.debian.org/toolchain-team/gcc/-/commit/6841377c19943a968b974aa7d65d78079bd5a884

That change is still active.

Bug#1072518: RFS: debpic/1.0.0 [ITP] -- build Debian packages in an isolated Docker environment

[Aidan]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package debpic:

 * Package name : debpic
 * Version  : 1.0.0
 * Upstream contact : Aidan Gallagher (aidg...@gmail.com)
 * URL  : https://github.com/aidan-gallagher/debpic
 * License  : LGPL-2.0+
 * Vcs  : https://github.com/aidan-gallagher/debpic.git

The source builds the following binary packages:

  debpic

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

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


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

  dget -x
https://mentors.debian.net/debian/pool/main/d/debpic/debpic_1.0.0.dsc

Changes since the last upload:

   * Initial Release.

Regards,
Aidan Gallagher

Bug#935426: mailcap.order entries aren't always keyed by package name

[Sergio.Gelato]

On Mon, Jun 03, 2024 at 01:43:54PM +0200, Charles Plessy wrote:
> I just tried using dpkg-query to find with package the desktop file
> belongs to.  However, this is way too slow for a script that may be run
> multiple times when packages are installed or removed.
> 
> At the moment I do not see another solution than documenting the issue
> better in the manual page of update-mime.
> 
> Do you have a better suggestion?

In the short term, no. In the longer run, though, I'd propose to make
debhelper generate files in /usr/lib/mime/packages/ for any packages
that install .desktop files in /usr/share/applications/, and then
change update-mime to no longer parse the .desktop files itself (unless
explicitly told to by a command-line option, perhaps). This may require
some adjustments to Debian policy.

I haven't researched the development history of update-mime, but the
parsing of the .desktop files feels like it was added as an
afterthought and doesn't fit in very well; I would either drop it
or redesign the whole thing.

Bug#1009122: systemd-quotacheck : does not work on root file system

[Luca Boccassi]

Control: tags -1 -upstream
Control: close -1

On Tue, 5 Jul 2022 00:28:21 +0200 Michael Biebl 
wrote:
> Control: tags -1 + upstream
> On Fri, 8 Apr 2022 10:32:05 +0200 Laurent Bonnaud 
>  wrote:
> > On 4/7/22 18:41, Laurent Bonnaud wrote:
> > 
> > > However I got it to work nevertheless by adding the "ro" mount
option
> > > in /etc/fstab for the root file system
> > 
> > This "solves" the quotacheck problem, but unfortunately it has many
other negative consequences, such as:
> > 
> > Apr 08 05:01:29 hostname systemd[1]: swapfile.swap: Swap process
exited, code=exited, status=255/EXCEPTION
> > Apr 08 05:01:29 hostname systemd[1]: swapfile.swap: Failed with
result 'exit-code'.
> > Apr 08 05:01:29 hostname systemd[1]: Failed to activate swap
/swapfile.
> > 
> > Apr 08 05:01:30 hostname systemd-tmpfiles[522]: rm_rf(/tmp): Read-
only file system
> > 
> > Apr 08 05:01:30 hostname systemd[539]: systemd-timesyncd.service:
Failed to set up mount namespacing: /run/systemd/unit-root/dev: Read-
only file system
> > Apr 08 05:01:30 hostname systemd[539]: systemd-timesyncd.service:
Failed at step NAMESPACE spawning /lib/systemd/systemd-timesyncd: Read-
only file system
> > 
> > Such this "solution" can only be used as a "one shot" trick
followed by a proper reboot with a rw file system.
> 
> 
> I assume you are using stable.
> Can you please test, if you can still reproduce this with v250 from 
> bullseye-backports and if so, report this upstream at
> https://github.com/systemd/systemd/issues

No answer nor upstream report in 2 years, closing.

-- 
Kind regards,
Luca Boccassi


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

Bug#1072517: /etc/apparmor.d/cockpit-desktop in Zeile 1: Could not open 'abi/4.0'

[Michael Biebl]

Package: cockpit-ws
Version: 317-1
Severity: serious
File: /etc/apparmor.d/cockpit-desktop

During todays boot I encountered the following failure:

× apparmor.service - Load AppArmor profiles
 Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; preset: 
enabled)
 Active: failed (Result: exit-code) since Mon 2024-06-03 14:35:42 CEST; 
1min 55s ago
 Invocation: 05781cbd4c8c4e7e96203d87010c5716
   Docs: man:apparmor(7)
 https://gitlab.com/apparmor/apparmor/wikis/home/
Process: 1014 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, 
status=1/FAILURE)
   Main PID: 1014 (code=exited, status=1/FAILURE)

Jun 03 14:35:42 mars apparmor.systemd[1014]: Restarting AppArmor
Jun 03 14:35:42 mars apparmor.systemd[1014]: Reloading AppArmor profiles
Jun 03 14:35:42 mars apparmor.systemd[1026]: AppArmor-Analysefehler f?r 
/etc/apparmor.d in profile /etc/apparmor.d/cockpit-desktop in Zeile 1: Could 
not open 'abi/4.0': Datei oder Verzeichnis nicht gefunden
Jun 03 14:35:42 mars apparmor.systemd[1040]: Skipping profile in 
/etc/apparmor.d/disable: usr.bin.thunderbird
Jun 03 14:35:42 mars apparmor.systemd[1065]: AppArmor-Analysefehler f?r 
/etc/apparmor.d/cockpit-desktop in profile /etc/apparmor.d/cockpit-desktop in 
Zeile 1: Could not open 'abi/4.0': Datei oder Verzeichnis nicht gefunden
Jun 03 14:35:42 mars apparmor.systemd[1134]: Skipping profile in 
/etc/apparmor.d/disable: usr.bin.thunderbird
Jun 03 14:35:42 mars apparmor.systemd[1014]: Error: At least one profile failed 
to load
Jun 03 14:35:42 mars systemd[1]: apparmor.service: Main process exited, 
code=exited, status=1/FAILURE
Jun 03 14:35:42 mars systemd[1]: apparmor.service: Failed with result 
'exit-code'.
Jun 03 14:35:42 mars systemd[1]: Failed to start apparmor.service - Load 
AppArmor profiles.

I suppose, the cockpit-desktop AA profile uses features that are not
available on Debian:

# apt-cache policy apparmor
apparmor:
  Installed: 3.0.13-2
  Candidate: 3.0.13-2
  Version table:
 *** 3.0.13-2 500
500 http://deb.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status


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

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

Versions of packages cockpit-ws depends on:
ii  adduser 3.137
ii  glib-networking 2.80.0-1
ii  libc6   2.38-12
ii  libcrypt1   1:4.4.36-4
ii  libglib2.0-0t64 2.80.2-2
ii  libgnutls30t64  3.8.5-4
ii  libgssapi-krb5-21.20.1-6+b1
ii  libjson-glib-1.0-0  1.8.0-2+b1
ii  libpam0g1.5.3-7
ii  libsystemd0 256~rc3-7
ii  openssl 3.2.1-3
ii  systemd 256~rc3-7

cockpit-ws recommends no packages.

Versions of packages cockpit-ws suggests:
ii  python33.11.8-1
pn  sssd-dbus  

-- no debconf information

Bug#935426: mailcap.order entries aren't always keyed by package name

[Charles Plessy]

Le Thu, Aug 22, 2019 at 03:25:06PM +0200, Sergio Gelato a écrit :
> 
> "The order of entries in the /etc/mailcap file can be altered by editing
>  the /etc/mailcap.order file. Each line of that file specifies a package
>  and an optional mime type."
> 
> This only holds true if the package adds a file to /usr/lib/mime/packages.
> Many /etc/mailcap entries, however, are obtained by parsing files in
> /usr/share/applications; in that case the "package" name is taken to be
> the name of the .desktop file, minus the .desktop suffix.

Le Sat, Feb 10, 2024 at 01:01:49PM +0100, Dietrich Clauss a écrit :
> 
> This is still the case in bookworm.
> 
> To make 'zathura' the default PDF viewer, I have to use the line
> 
> | org.pwmt.zathura-pdf-poppler:application/pdf
> 
> in .

Dear Sergio and Dietrich,

I just tried using dpkg-query to find with package the desktop file
belongs to.  However, this is way too slow for a script that may be run
multiple times when packages are installed or removed.

At the moment I do not see another solution than documenting the issue
better in the manual page of update-mime.

Do you have a better suggestion?

Have a nice day,

Charles Plessy

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://fediscience.org/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Bug#1027773: setting sysctl net.ipv4.ping_group_range

[Luca Boccassi]

On Mon, 3 Jun 2024 at 12:44, Diederik de Haas  wrote:
>
> On Monday, 3 June 2024 13:29:48 CEST Luca Boccassi wrote:
> > as we get near the Trixie freeze (say, September)
>
> Wait, wut? Isn't that usually in/around January?

Yes, but that's the final deadline, changes should be done earlier
than that, hence the September-ish hint

Bug#1027773: setting sysctl net.ipv4.ping_group_range

[Diederik de Haas]

On Monday, 3 June 2024 13:29:48 CEST Luca Boccassi wrote:
> as we get near the Trixie freeze (say, September)

Wait, wut? Isn't that usually in/around January?


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

Bug#1027773: setting sysctl net.ipv4.ping_group_range

[Luca Boccassi]

Control: tags -1 pending

On Tue, 03 Jan 2023 12:05:10 +0100 Luca Boccassi 
wrote:
> On Tue, 3 Jan 2023 03:26:37 +0100 Marco d'Itri  wrote:
> > On Jan 03, Adam Borowski  wrote:
> > 
> > > Debian's default sysctl settings should reside in procps (as it
> owns
> > > /sbin/sysctl and /etc/sysctl* settings) rather than some
unrelated
> > > package.
> > Nowadays systemd is a source of common sysctl settings among
> different 
> > distributions.
> 
> Shipping 50-default.conf sounds good to me, it has sensible defaults,
> and /etc/sysctl.conf(.d/*) takes precedence anyway if it contains any
> local redefinition:
> 
> https://salsa.debian.org/systemd-team/systemd/-/merge_requests/187

As mentioned on the MR< this issue of missing good default sysctls
keeps biting, so I intend to have it fixed for Trixie. Kernel team, if
you strongly prefer to have the kernel source package own it, that is
fine by me, but bear in mind it has to be installed in containers
(without linux-image) too by default, so it would have to be either an
existing or new package that is always installed everywhere that
systemd-sysctl is installed.
If you want to devise such a solution that is of course fine by me, but
please note that if one is not available as we get near the Trixie
freeze (say, September) I will merge this MR instead so that these bugs
can be fixed.

Salvatore, it might be worth considering bringing this up for your next
kernel weekly meeting.

-- 
Kind regards,
Luca Boccassi


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

Bug#1072515: general: Repeating cracking sound in headphones when nothing is playing.

[Andrius Merkys]

Hi Christian,

On 2024-06-03 11:38, Christian Böck wrote:

when using headphones with my laptop (Thinkpad W550s) I get a repeating
cracking (~1sec intervalls) when nothing is playing.


I have a similar issue on a workstation with Ubuntu 22.04. What is your 
operating system version? I believe the issue started manifesting once I 
installed Jack. Do you have Jack on your machine?


Andrius

Bug#1064126: libvirt: install NSS modules into /usr

[Helmut Grohne]

Hi Andrea,

I think Michael and Chris already said most of the relevant things, but
Chris asked me to chime in.

On Tue, Feb 27, 2024 at 10:53:12PM +0100, Andrea Bolognani wrote:
> Note that "at the same time" can mean two things in this context:
> 
>   1) when upgrading from bookworm to trixie;
>   2) when upgrading testing/unstable.
> 
> I'm sure that 1) can be handled correctly, but the prospect of
> causing file loss for 2) by accident is not particularly appealing
> and I'd like to avoid it if at all possible.

Your worry is reasonable. However, deferring these changes is going to
make it worse as we have less time to handle possible breakage. The way
to avoid the 2) scenario is to upload to experimental (with upgrade
problems), have dumat detect all the issues, fix them there and only
then (once the analyzer is happy) move to unstable.

> As I've explained we want to preserve backportability as much as
> possible, which pretty much rules out the current patch. At the very
> least we'd have to use dh_movetousr instead.

I fear that you are between a rock and a hard place here. The time64 and
/usr-move transitions very much are not backportable in a sane way. In
particular, the existence of a P1 problem (as you suggest there will be)
rules out dh_movetousr. It gets even worse though. If you backport,
you're supposed to move units back to aliased paths (due to the file
move moratorium still being in place for bookworm and due to bookworm's
debhelper not adding maintainer scripts or moved units). So when you
upgrade from bookworm-backports to trixie (in a distant future), you
have a new upgrade path and the trixie package will need even more
mitigations. Yes, this is suboptimal.

> What I still fail to understand, and please bear with me because the
> issue is most likely on my side, is how the fallout from a "bad" file
> move would be dealt with.
> 
> Suppose that I made the usr-merge upload today, and the package
> restructure upload in a month. At that point, dumat would detect that
> file loss could occur, report it and... What then?

Ideally, your restructuring upload goes to experimental, so all of
experimental users have broken systems then. When dumat reports an
issue, I'll investigate the cause and propose a solution (patch) and
file an rc bug. That tells you that you're not good to move to unstable
as is and gives the two of us time to discuss solutions and the
integration into the package.

> Have reliable mitigations been developed for all possible file loss
> scenarios?  Is it guaranteed that such mitigations, when applied,
> will protect from file loss not just the people running stable, but
> also those running testing and unstable?

No. We're enumerating badness here. We're limiting the damage that has
already been done. We've looked at lots of problems and tried to
identify as many as possible problems and specifically test for known
problem categories. False negatives are possible and have happened
indeed. But then, what we have makes it fairly unlikely for users to
practically experience those problems. The goal definitely is to not
have any file loss in bookworm -> trixie nor testing/unstable upgrade
scenarios. The guarantee you are looking for does not exist, but we're
making a good effort at it and I believe that we have a fairly good
track record of actually supporting this transition when problems arise.
For instance, the diversions in molly-guard turned out to be way more
difficult to mitigate than originally anticipated and while it took
quite a bit longer, we now have a working solution. Likewise, when
piuparts or the debian-installer was broken, we sent patches rather than
disappearing. I fear there is not much more that we can do here than
promise supporting you in the event of fallout.

> My instincts tell me that it would be much easier to reason about
> this if the two transitions happened at the same time rather than
> potentially months apart. This is my main concern with applying the
> usr-merge changes when we still don't have a clear picture of what
> the final state of the package will look like.

Interestingly, my instinct (and that of Michael and Chris) tell exactly
the opposite story. Many of the /usr-move issues are interaction
problems between multiple packages. When we look for problems, we don't
look for recent history, but use a static analyzer that precisely pin
points where to look. The earlier we move stuff, the more capacity we
have for keeping up the support promise.

So yes, I also recommend moving stuff to /usr as soon as possible and in
particular without the restructuring changes (as that allows us to
analyze the move already).

What I don't have is a good answer about backports. In the face of P1
problems, backports are difficult to get right. Indeed, doing a backport
now and then saying "no more bookworm-backports after /usr-move and
restructuring" can be a sensible thing, but you pay with less support
from us in the event of fallout.

I'm also 

Bug#1072300: RM: phppgadmin/7.13.0+dfsg-2

[Moritz Mühlenhoff]

Am Fri, May 31, 2024 at 03:53:13PM -0300 schrieb Leandro Cunha:
> Package: release.debian.org
> Control: affects -1 + src:phppgadmin
> X-Debbugs-Cc: phppgad...@packages.debian.org
> User: release.debian@packages.debian.org
> Usertags: rm
> X-Debbugs-Cc: leandrocunha...@gmail.com
> Severity: normal
> 
> Reason and request
> I open this bug to request the removal of the phppgadmin package
> version 7.13.0+dfsg-2 from the current stable version of Debian

I suppose it should also be removed from bullseye/oldstable, right?
If so, can you please file a separate bug for it?

Cheers,
Moritz

Bug#1072516: "command -v" prints to the terminal

[Marco d'Itri]

Package: mailcap
Version: 3.71gg
Severity: important
X-Debbugs-Cc: jcris...@debian.org, anto...@debian.org
Control: affects -1 mutt

After upgrading mailcap, when opening a message with mutt I see strings 
like "/usr/bin/vim" and "/usr/bin/evince" printed in random places.
Looks like it is caused by this change:

  79285fc update-mime: convert .desktop file's TryExec to a
  test= field for the mailcap entry (Closes: #964173)

On a more general note, I am not sure that it is a good idea to 
automatically add entries for text/plain since they cause a useless 
shell exec in mutt every time a message is opened (maybe the mutt 
maintainer can add some insight?).

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

Kernel: Linux 6.8.11-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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 mailcap depends on:
ii  media-types  10.1.0
ii  perl 5.38.2-5

Versions of packages mailcap recommends:
ii  bzip2 1.0.8-5.1
ii  file  1:5.45-3
ii  xz-utils  5.6.1+really5.4.5-1

mailcap suggests no packages.

-- Configuration Files:
/etc/mailcap.order changed [not included]

-- no debconf information

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1066835: (no subject)

[wuruilong]

Dear Maintainer,

The upstream has been merged in with the following link: 
https://github.com/universal-ctags/ctags/pull/3958

Please update the software version or merge the attached patch.

wuruilong

Bug#1072515: general: Repeating cracking sound in headphones when nothing is playing.

[Christian Böck]

Package: general
Severity: normal
X-Debbugs-Cc: deb...@funtech.org

Dear Maintainer,

when using headphones with my laptop (Thinkpad W550s) I get a repeating
cracking (~1sec intervalls) when nothing is playing.

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I used headphones for the first time with Debian.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I can't find a fitting setting, so I did nothing.

   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

Bug#1072505: systemd: /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.

[Luca Boccassi]

Control: tags -1 wontfix
Control: close -1

On Mon, 03 Jun 2024 10:54:15 +0700 "Damir R. Islamov"
 wrote:
> Package: systemd
> Version: 256~rc3-7
> Severity: minor
> 
> Dear Maintainer,
> 
> Every time the systemd package is being configured,
> it return a warnung
> /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path
"/run/lock", ignoring.

It's expected and harmless, just ignore it as the message says

-- 
Kind regards,
Luca Boccassi


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

Bug#1072035: dns-root-data: New IPs for b.root-servers-net 2023-11-27

[Jonas Meier]

Hi Richard

The fix for Debian 12 and 11 is tracked in #1072035

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

Jonas

Bug#1072501: ITP: systemd-boot-installer -- Install systemd-boot on a hard disk

[Luca Boccassi]

On Mon, 3 Jun 2024 at 02:22, Cyril Brulebois  wrote:
>
> Hi,
>
> Luca Boccassi  (2024-06-03):
> > Package: wnpp
> > Severity: wishlist
> > Owner: Luca Boccassi 
> > X-Debbugs-Cc: debian-de...@lists.debian.org
> >
> > * Package name: systemd-boot-installer
> >   Version : 0.1
> >   Upstream Author : Luca Boccassi 
> > * URL : 
> > https://salsa.debian.org/installer-team/systemd-boot-installer
> > * License : GPL-2.0-or-later
> >   Programming Lang: shell
> >   Description : debian-installer component to install systemd-boot
> > as the bootloader
>
> Could we have some kind of heads-up via X-D-Cc to debian-boot@ for such
> things, please? Discovering we have a new package under our namespace
> via a “Processing” mail from ftpmaster is awkward.

Sorry, since it needs to go through NEW I uploaded at the same time as
I sent this:

https://lists.debian.org/debian-boot/2024/06/msg00013.html

so I thought it would be enough heads-up.

Bug#1062800: RFP: pyside6 -- Qt6 for Python

[Stuart Prescott]

Control: retitle 1062800 ITP: pyside6 -- Qt6 for Python

There is substantial work towards packaging at:

https://salsa.debian.org/qt-kde-team/qt6/pyside6

The package is built for Qt 6.6 which is in experimental; the package is 
approximately ready for upload to NEW.


Maintainers who know the Qt stack and understand the details of how 
pyside works are desperately needed. Please join the Qt/KDE packaging 
team (if not already a member) and add yourself to d/control!



--
Stuart Prescott   http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer  http://www.debian.org/   stu...@debian.org
GPG fingerprint   90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#1070770: lintian: check for testing presence of "nodocs" in DEB_BUILD_OPTIONS

[Andrius Merkys]

On 2024-06-02 19:49, Louis-Philippe Véronneau wrote:> Sounds like a 
plan. I made the changed you proposed and also made sure
the tag will output the problematic BUILD_OPTION. That way, when/if 
someone wants to make it more generic, it'll be possible to pass other 
invalid BUILD_OPTION.


The tag outputted currently looks like:

foobar (source): debian-rules-invalid-build-option nodocs [debian/rules:2]


Great, thanks a lot. I reviewed the code and I think it is good to be 
merged as is. Tag name is appropriate and future-proof for other checks 
for DEB_BUILD_OPTIONS.


Thanks,
Andrius

Bug#1021460: ITA: elpa-rust-mode -- Major Emacs mode for editing Rust source code

[Gianfranco Costamagna]

happily sponsored thanks!
G.
On Sat, 02 Mar 2024 04:50:56 -0800 Xiyue Deng  wrote:

Control: retitle -1 ITA: elpa-rust-mode -- Major Emacs mode for editing Rust 
source code
Control: tags -1 pending

I'd like to adopt this package.  I have prepared the updated package on
mentors[1] and have filed a separate RFS bug[2].

[1] https://mentors.debian.net/package/elpa-rust-mode/
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065302
--
Xiyue Deng




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072514: libgnutls30: Disabled KTLS support

[Daniel Salzman]

Source: libgnutls30
Version: 3.7.9-2+deb12u1
Severity: wishlist
X-Debbugs-Cc: daniel.salz...@nic.cz

Dear Maintainer,

The GnuTLS library is built with KTLS support disabled. If the `--enable-ktls` 
configure option is added to CONFIGUREARGS
in debian/rules, the library builds successfully. Also, TLS offloading seems to 
work well.

Could you please enable this feature in the package?

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

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

-- no debconf information

Bug#1070729: wireplumber: 0.5 breaks unmodified configurations because of incompatible state format

[Dylan Aïssi]

Hi,

Le mer. 8 mai 2024 à 05:21, Grzesiek11  a écrit :
>
> As mentioned by the NEWS entry, 0.5 replaces the old configuration
> system with a new one utilizing JSON. It also states this should be
> transparent for systems using only Debian configuration, however the
> state format (for files stored in $XDG_STATE_HOME/wireplumber) is also
> incompatible, causing unmodified configurations to break.
>
> The workaround I used is removing the state directory and restarting the
> service, causing it to regenerate.

I just uploaded wireplumber 0.5.3 in sid. This version seems to fix a
potential duplicated bug. Could you check if this version fix your issue
once the package lands in apt repository?

Thanks,

Dylan

Bug#1060103: transition: imagemagick7

[Emilio Pozuelo Monfort]

Hi Bastien,

On 02/06/2024 14:38, Bastien Roucariès wrote:

Le dimanche 2 juin 2024, 11:17:33 UTC Sebastian Ramacher a écrit :

On 2024-02-02 17:21:43 +, Bastien Roucariès wrote:

Le vendredi 2 février 2024, 16:53:10 UTC Sebastian Ramacher a écrit :

Control: tags -1 moreinfo

Hi Bastien

On 2024-01-05 22:35:44 +, Bastien Roucariès wrote:

Package: release.debian.org
Severity: important
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: ftpmas...@debian.org

Imagemagick will need a new major bump

I achieved to get imagemagick 7 build for experimental (it is only on salsa not
uploaded yet).

Every package include a version in the package name (except legacy package name
and perl*) so I plan to do some step by step migration, because it is mainly
coinstallable with imagemagick 6.


Why does this migration require co-instabillity with the old version?
This makes the transition overly complicated. Do you expect major
changes required in reverse dependencies of imagemagick's shared
library?


The problem is not the library but the command line interface that may need 
change.

Librarry will break (I think here about php module that will need a update), 
but it is treatable.

convert6 is not fully compatible with convert7

convert6 will be co installable with convert7 in order to test, and convert 
will be provided by alternative system.


If they are not fully compatible, then alternatives are not an option.


They are 95% compatible


How many packages are we talking about? Have bugs been filed for
packages thar are not compatible with convert7?


The problem is chicken and eggs problem. If you could not test then you could 
not report bug.
A least both should be in experimental for running a full archive rebuild


Not really. I also don't think the 3-step migration plan in experimental you're 
proposing makes much sense.


What we need here is to know how many packages fail to build against imagemagick 
7. And for that, the package doesn't even need to be in experimental. Also, you 
don't need to perform a full archive rebuild, just rebuilding those packages 
that build-depend on imagemagick would be enough.


Once that is done and we're ready to go, after going through experimental as 
src:imagemagick (no renamed package), then we would start the transition and 
scheduled the necessary binNMUs, and raise any bugs to serious.


That'd be the ideal scenario. But we don't know how feasible that is until we 
know how many packages will need source changes, and for that we need the 
results of the test rebuilds.


Cheers,
Emilio

Bug#1072389: patches to make cruft-ng work without locate

[Alexandre Detiste]

Hi,

The scripts in explain/ ought to be run inside the chroot.

The systemd script for example was already adapted to work without a
running init.

This could be done with chroot() and a bind mount of /usr/libexec/cruft or
alternatively modifying every script to support DPKG_ROOT.

I think option 1 will require root while option 2 will work in the non-root
mode too.

I slightly prerer option 2 which allows more case-by-case handling.

You can fork this on Salsa which is now the main repository.

https://debconf22.debconf.org/talks/23-what-is-dpkg_root-and-what-is-it-not/

Greetings

Le dim. 2 juin 2024, 20:41, Jochen Sprickerhof  a
écrit :

> * Alexandre Detiste  [2024-06-02 12:54]:
> >I'm impressed ! This will get merged.
>
> \o/
>
> I have also implemented a --root option to check chroot, see the
> attached patch.
>

Bug#1072383: lintian: flag packages bloated by auxiliary tests/docs/examples

[Andrius Merkys]

Hi Aaron,

On 2024-06-02 05:41, Aaron M. Ucko wrote:

A number of binary packages accompany their primary content by tests,
examples, and/or other documentation that appreciably increase their
size, in some cases by more than an order of magnitude, and as such
would be very reasonable to split out.  Could Lintian please flag such
packages so as to encourage such splitting?  I know Perl and would be
happy to draft a patch if that would be helpful.


I would really welcome such check in lintian. I am often bitten by such 
situations when trying to minimize the size of my VMs/containers. I 
think lintian hint encouraging maintainers to split off large auxiliary 
content would be nice and would happily review your patch.


Best,
Andrius

Bug#998820: lintian: overly generic python modules /usr/lib/python3/dist-packages/benchmarks/*.py

[Andrius Merkys]

On 2024-06-03 08:51, Andreas Beckmann wrote:

Followup-For: Bug #998820

Then we also have

/usr/lib/python3/dist-packages/build/lib/doc/conf.py
  ^^^
e.g. nxtomo 1.2.3-2

usr/lib/python3/dist-packages/build/lib/docs/conf.py
 
e.g. pipenv 2023.12.1+ds-1


Just thinking out loud: would it make sense to warn about all the files 
that are installed under /usr/lib/python3/dist-packages/, but outside 
the package directory? E.g. all files from python3-nxtomo in 
/usr/lib/python3/dist-packages/, but outside 
/usr/lib/python3/dist-packages/nxtomo/. I guess such approach may 
produce false-positives for plugin packages.


Another solution would be to simply warn about specific paths, such as:

/usr/lib/python3/dist-packages/build/*
/usr/lib/python3/dist-packages/docs/*
/usr/lib/python3/dist-packages/__init__.py
...

Does it make sense to name lintian tag 
'python-package-installs-overly-generic-path'?


Best,
Andrius