Bug#1059551: Remove obsolete command 'dget'

[Otto Kekäläinen]

Package: devscripts
Version: 2.23.7

Currently devscripts contains package 'dget' [1] for downloading
Debian binary/source packages.

Everything it does can be done using apt-get. The man page itself
explicitly says 'dget package should be implemented in apt-get install
-d.', which it kind of today is as you can run 'apt-get download' to
download the binary packages of anything, and no root permissions are
required.

Thus the tools dget is obsolete, and should be removed, or replace
with a minimal bash script that simply states 'This tool is
deprecated. Please use "apt-get download" or "apt-get source".'

[1] https://manpages.debian.org/unstable/devscripts/dget.1.en.html

Bug#1059550: jellyfish: add loong64 support

[Zhang Na]

Source: jellyfish
Version: 2.3.1-1
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,
  
  Please add loong64 support in debian/control, thanks!

-- 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=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
>From 59324455b12992fad1eb016174805c4a26661131 Mon Sep 17 00:00:00 2001
From: Zhang Na 
Date: Thu, 28 Dec 2023 07:03:30 +
Subject: [PATCH] add loong64 support

---
 debian/control | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/debian/control b/debian/control
index 77a0fba..9c13507 100644
--- a/debian/control
+++ b/debian/control
@@ -29,7 +29,7 @@ Homepage: https://github.com/gmarcais/Jellyfish
 Rules-Requires-Root: no
 
 Package: jellyfish
-Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64
+Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64 loong64
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  libjellyfish-2.0-2 (= ${binary:Version})
@@ -49,7 +49,7 @@ Description: count k-mers in DNA sequences
  format using the "jellyfish dump" command.
 
 Package: libjellyfish-2.0-2
-Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64
+Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64 loong64
 Multi-Arch: same
 Section: libs
 Depends: ${shlibs:Depends},
@@ -73,7 +73,7 @@ Description: count k-mers in DNA sequences (dynamic library 
of jellyfish)
  jellyfish is linked to.
 
 Package: libjellyfish-2.0-dev
-Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64
+Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64 loong64
 Section: libdevel
 Depends: ${misc:Depends},
  libjellyfish-2.0-2 (= ${binary:Version})
@@ -96,7 +96,7 @@ Description: count k-mers in DNA sequences (development files 
of jellyfish)
  header files)
 
 Package: python3-dna-jellyfish
-Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64
+Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64 loong64
 Section: python
 Depends: ${python3:Depends},
  ${misc:Depends},
@@ -119,7 +119,7 @@ Description: count k-mers in DNA sequences (Python bindings 
of jellyfish)
  This package contains the Python bindings of jellyfish.
 
 Package: libjellyfish-perl
-Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64
+Architecture: amd64 arm64 armel armhf i386 mips64el ppc64el hppa hurd-i386 
ia64 kfreebsd-amd64 kfreebsd-i386 riscv64 loong64
 Multi-Arch: same
 Section: perl
 Depends: ${perl:Depends},
-- 
2.43.0

Bug#1035466: postfix 3.5.23-0+deb11u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: postfix
Version: 3.5.23-0+deb11u1

Explanation: new upstream stable release; address SMTP smuggling issue 
[CVE-2023-51764]

Bug#1059549: mirror submission for mirrors.jxust.edu.cn

[Ge Huang]

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

Submission-Type: new
Site: mirrors.jxust.edu.cn
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 
mips mips64el mipsel powerpc ppc64el riscv64 s390x
Archive-http: /debian/
Maintainer: Ge Huang 
Country: CN China
Location: Ganzhou City, Jiangxi Province
Sponsor: Jiangxi University of Science & Technology https://www.jxust.edu.cn




Trace Url: http://mirrors.jxust.edu.cn/debian/project/trace/
Trace Url: 
http://mirrors.jxust.edu.cn/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.jxust.edu.cn/debian/project/trace/mirrors.jxust.edu.cn

Bug#1059545: webext-ublock-origin-firefox: I get YouTube ads when Private Browsing

[Markus Koschany]

Hello,

> Hi,
> Lately I've been getting YouTube ads when I play videos on private windows.
> This among other YouTube bugs (slow loading and such) have been fixed for
> testing and unstable.   If they can be backported it would be great.
> 
> 
> (can be reproduced on a VM with defaults)

My intention was to backport ublock-origin to Bookworm in January 2024. This
will be a normal point update as usual, so you have to enable bookworm
proposed-updates for early access. I try to update Bullseye as well. Stay tuned
and a happy new year 2024.

Markus


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

Bug#1059548: mirror listing update for mirrors.jxust.edu.cn

[Ge Huang]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: mirrors.jxust.edu.cn
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 
mips mips64el mipsel powerpc ppc64el riscv64 s390x
Archive-http: /debian/
Maintainer: Ge Huang 
Country: CN China
Location: Ganzhou City, Jiangxi Province
Sponsor: Jiangxi University of Science & Technology https://www.jxust.edu.cn




Trace Url: http://mirrors.jxust.edu.cn/debian/project/trace/
Trace Url: 
http://mirrors.jxust.edu.cn/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.jxust.edu.cn/debian/project/trace/mirrors.jxust.edu.cn

Bug#1059547: mirror listing update for mirrors.jxust.edu.cn

[Ge Huang]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: mirrors.jxust.edu.cn
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 hurd-amd64 i386 
mips mips64el mipsel powerpc ppc64el riscv64 s390x
Archive-http: /debian/
Maintainer: Ge Huang 
Country: CN China
Location: Ganzhou City, Jiangxi Province
Sponsor: Jiangxi University of Science & Technology https://www.jxust.edu.cn




Trace Url: http://mirrors.jxust.edu.cn/debian/project/trace/
Trace Url: 
http://mirrors.jxust.edu.cn/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.jxust.edu.cn/debian/project/trace/mirrors.jxust.edu.cn

Bug#1059330: transition: shapelib

[Sebastiaan Couwenberg]

On 12/27/23 21:16, Sebastian Ramacher wrote:

On 2023-12-22 16:39:57 +0100, Bas Couwenberg wrote:

Shapelib 1.6.0 bumps the SONAME requiring a transition.

All rdeps built successfully with the new version as summarized below.


Please go ahead.


Thanks. shapelib (1.6.0-1) has been uploaded to unstable and is now 
built & installed on all release architectures.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1059546: pylint generates false positive 'import-error' with local editable modules.

[Mike Castle]

Package: pylint
Version: 2.16.2-2
Severity: important
Tags: upstream
X-Debbugs-Cc: dalg...@gmail.com

Dear Maintainer,

This *might* be https://github.com/pylint-dev/pylint/issues/8829 .  However, I
am new to this bits of the Python eco-system, so not confident in my
assessment.

When trying to run pylint against a module that imports an _editable_ module
install, a false positive 'import-error' is given.

To reproduce, I used the following toy module:
$ find -type f -exec printf '\n%s\n' {} \; -exec cat {} \;

./pyproject.toml
[project]
name = 'ttt'
version = '0'

./ttt/__init__.py

./ttt/pylintbug.py
"""Docstring."""

def bug_func():
"""Bug."""
print('I am the bug_func')

And this module for testing:
$ cat t.py
"""Docstring."""

from ttt import pylintbug

pylintbug.bug_func()


With the module not installed, nothing works, as expected:
# nothing installed
$ pip list --user ; date
Wed Dec 27 07:31:09 PM PST 2023

$ python --version
Python 3.11.2

$ python t.py
Traceback (most recent call last):
  File "/home/nexus/t.py", line 3, in 
from ttt import pylintbug
ModuleNotFoundError: No module named 'ttt'

$ pylint --rcfile /dev/null t.py
* Module t
t.py:3:0: E0401: Unable to import 'ttt' (import-error)

--
Your code has been rated at 0.00/10 (previous run: 0.00/10, +0.00)


Install the module:

$ pip install --break-system-packages .
Defaulting to user installation because normal site-packages is not writeable
Processing /home/nexus/src/ttt
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: ttt
  Building wheel for ttt (pyproject.toml) ... done
  Created wheel for ttt: filename=ttt-0-py3-none-any.whl size=1225 
sha256=051948400d275bad5c31d656ef0394f8a43232d00754ab826bbe18dcd67d1c60
  Stored in directory: 
/tmp/pip-ephem-wheel-cache-upb4wjrt/wheels/c3/93/be/4d7b95f07076bb565c6c69548aef2e2868a95b899b724660dd
Successfully built ttt
Installing collected packages: ttt
Successfully installed ttt-0

And everything works as expected:
$ pip list --user ; date
Package Version
--- ---
ttt 0
Wed Dec 27 07:32:56 PM PST 2023

$ python t.py
I am the bug_func

$ pylint --rcfile /dev/null t.py


Your code has been rated at 10.00/10 (previous run: 0.00/10, +10.00)


Now, install the module and reinstall in _editable_ mode (-e):

$ pip uninstall --break-system-packages -y ttt
Found existing installation: ttt 0
Uninstalling ttt-0:
  Successfully uninstalled ttt-0

$ pip install --break-system-packages -e .
Defaulting to user installation because normal site-packages is not writeable
Obtaining file:///home/nexus/src/ttt
  Installing build dependencies ... done
  Checking if build backend supports build_editable ... done
  Getting requirements to build editable ... done
  Preparing editable metadata (pyproject.toml) ... done
Building wheels for collected packages: ttt
  Building editable for ttt (pyproject.toml) ... done
  Created wheel for ttt: filename=ttt-0-0.editable-py3-none-any.whl size=2313 
sha256=20eacec25143d7c0f57fed066c7c57dbed566853edc944919e1029a65349822b
  Stored in directory: 
/tmp/pip-ephem-wheel-cache-2sxotfjx/wheels/c3/93/be/4d7b95f07076bb565c6c69548aef2e2868a95b899b724660dd
Successfully built ttt
Installing collected packages: ttt
Successfully installed ttt-0


Now, executing the 't.py' script works, but pylint fails with the false
positive:

$ pip list --user ; date
Package Version Editable project location
--- --- -
ttt 0   /home/nexus/src/ttt
Wed Dec 27 07:35:24 PM PST 2023

$ python t.py
I am the bug_func

$ pylint --rcfile /dev/null t.py
* Module t
t.py:3:0: E0401: Unable to import 'ttt' (import-error)


Your code has been rated at 0.00/10 (previous run: 10.00/10, -10.00)


Reinstalling the module in regular mode and it works again:

$ pip list --user ; date
Package Version
--- ---
ttt 0
Wed Dec 27 07:38:27 PM PST 2023

$ python t.py
I am the bug_func

$ pylint --rcfile /dev/null t.py


Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)


-- 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-16-amd64 (SMP w/6 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 pylint depends on:
ii  python33.11.2-1+b1
ii  python3-astroid2.14.2-1
ii  python3-dill   

Bug#1059545: webext-ublock-origin-firefox: I get YouTube ads when Private Browsing

[nelson g]

Package: webext-ublock-origin-firefox
Version: 1.46.0+dfsg-1
Severity: important
X-Debbugs-Cc: konoh...@yahoo.com

Hi,
Lately I've been getting YouTube ads when I play videos on private windows.
This among other YouTube bugs (slow loading and such) have been fixed for
testing and unstable.   If they can be backported it would be great.


(can be reproduced on a VM with defaults)


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

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

webext-ublock-origin-firefox depends on no packages.

Versions of packages webext-ublock-origin-firefox recommends:
ii  firefox-esr  115.6.0esr-1~deb12u1

Versions of packages webext-ublock-origin-firefox suggests:
pn  ublock-origin-doc  

-- no debconf information

Bug#1059508: tcsh: Compilation failed on multiple architectures

[Zhang Na]

Please try again,  I did not occur this error. This has nothing to do 
with the architecture, perhaps you can help solve this permission problem.



## -- ##
## Detailed failed tests. ##
## -- ##

# -*- compilation -*-
68. commands.at:1041: testing nice ...
./commands.at:1045: tcsh -f -c 'nice set var=1; echo $?var'
--- /dev/null    2023-08-30 13:17:09.0 +
+++ /<>/testsuite.dir/at-groups/68/stderr 2023-09-01 
09:12:12.022965657 +

@@ -0,0 +1 @@
+setpriority: Permission denied.
68. commands.at:1041: 68. nice (commands.at:1041): FAILED (commands.at:1045)

Bug#1056738: bullseye-pu: minizip/1.1-8+deb11u1

[Thorsten Alteholz]

On Tue, 19 Dec 2023, Jonathan Wiltshire wrote:

Please go ahead.


great, thanks ...

... and uploaded.

  Thorsten

Bug#1056935: bullseye-pu: libde265/1.0.11-0+deb11u2

[Thorsten Alteholz]

On Tue, 19 Dec 2023, Jonathan Wiltshire wrote:

Please go ahead.


great, thanks ...

... and uploaded.

  Thorsten

Bug#1059544: libpipewire-0.3-modules-x11: package requires libcanberra-pulse be installed

[Brent Roman]

Package: libpipewire-0.3-modules-x11
Version: 0.3.65-3
Severity: important
X-Debbugs-Cc: br...@mbari.org

Dear Maintainer,

   * What led up to the situation?
   Trying to make x11 bell work under pipewire
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   No audio output until I manually installed libcanberra-pulse
   * What was the outcome of this action?
   Without libcanberra-pulse, ca_open_context complains pulse driver unavailable
   * What outcome did you expect instead?
   Installing libpipewire-0.3-modules-x11 should have pulled in
   libcanberra-pulse as a dependency

libpipewire-0.3-modules-x11  should depend on libcanberra-pulse


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

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

Versions of packages libpipewire-0.3-modules-x11 depends on:
ii  libc6  2.36-9+deb12u3
ii  libcanberra0   0.30-10
ii  libpipewire-0.3-0  0.3.65-3
ii  libx11-6   2:1.8.4-2+deb12u2
ii  libxfixes3 1:6.0.0-2

libpipewire-0.3-modules-x11 recommends no packages.

libpipewire-0.3-modules-x11 suggests no packages.

-- no debconf information

Bug#1059543: gpsd: Globalsat BU-353N5 not matched by udev

[Taneli Hukkinen]

Package: gpsd
Version: 3.22-4.1+b1
Severity: wishlist
X-Debbugs-Cc: taneli.hukki...@proton.me

Dear Maintainer,

The udev rule created by gpsd does not match a Globalsat BU-353N5 device.
The lsusb entry of this chip is "ID 067b:23a3 Prolific Technology, Inc. ATEN 
Serial Bridge". 
I was able to make it work by adding the following line to 
/lib/udev/rules.d/60-gpsd.rules

ATTRS{idVendor}=="067b", ATTRS{idProduct}=="23a3", SYMLINK+="gps%n", 
TAG+="systemd", ENV{SYSTEMD_WANTS}="gpsdctl@%k.service"

I understand that (as seems to be the case with some other devices) the chip 
may be too generic that adding it causes more harm than good.


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

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

Versions of packages gpsd depends on:
ii  adduser3.134
ii  libbluetooth3  5.66-1+deb12u1
ii  libc6  2.36-9+deb12u3
ii  libdbus-1-31.14.10-1~deb12u1
ii  libgps28   3.22-4.1+b1
ii  libusb-1.0-0   2:1.0.26-1
ii  netbase6.4
ii  python33.11.2-1+b1
ii  systemd-sysv   252.19-1~deb12u1
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages gpsd recommends:
ii  gpsd-tools  3.22-4.1+b1
ii  udev252.19-1~deb12u1

Versions of packages gpsd suggests:
ii  apparmor  3.0.8-3
ii  dbus  1.14.10-1~deb12u1
ii  gpsd-clients  3.22-4.1+b1

-- no debconf information

Bug#1059542: groff-base: eqn mathml output doesn't understand left floor/right floor (or \[rf])

[наб]

Package: groff-base
Version: 1.23.0-3
Version: 1.22.4-10
Severity: normal

Dear Maintainer,

I'm trying to assemble some equations.
MathML is convenient for high-res renders and embedding.

One such is:
  w = left floor l 39 over 40 right floor

When rendering images with eqn2graph and groff -Thtml (both attached),
this yields the expected ⌊ and ⌋ wrapping.

However, when rendering with eqn -TMathML and groff -Txhtml (likewise),
this yields "w = floor l³⁹⁄₄₉ floor". Also \[lf] and \[lf] are "unknown
eqn/troff special char [rl]f", but they obviously ought to be given that
they are understood by groff.

Best,
наб

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

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

Versions of packages groff-base depends on:
ii  libc6 2.36-9+deb12u3
ii  libgcc-s1 12.2.0-14
ii  libstdc++612.2.0-14
ii  libuchardet0  0.0.7-1

groff-base recommends no packages.

Versions of packages groff-base suggests:
ii  groff  1.22.4-10

-- no debconf information
.if !dEQ .ds EQ
.if !dEN .ds EN
.EQ
wunknown eqn/troff special char lfunknown eqn/troff special char rffloorl3940floor
.EN


binGSJicdKuIJ.bin
Description: application/xhtml


signature.asc
Description: PGP signature

Bug#1039607: libjansi-java: causes maven to always output escape character

[tony mancill]

On Sat, Dec 23, 2023 at 03:54:45PM -0800, tony mancill wrote:
> On Sat, Jul 15, 2023 at 03:56:01PM +0200, Emmanuel Bourg wrote:
> > On 08/07/2023 20:22, tony mancill wrote:
> > 
> > > Emmanuel, do you recall what prompted the change?
> > 
> > I think the issue is that when Maven runs in pbuilder, the TTY isn't
> > detected and colors get disabled (batch mode isn't used for Debian builds
> > though). If anything is changed please ensure that building with pdebuild
> > preserves the colors.
> 
> Looking at the sources (finally), jansi already supports a mode to
> "force" [1] escape sequences, even when the output is not a terminal.  I
> propose that we revert the patch and update the Java build tooling to
> set the property as desired for our builds.
> 
> Once I get this tested and the property configured, I'll upload to
> experimental.

The following are now available in experimental:

libjansi-java_2.4.0-3_all.deb
maven-debian-helper_2.6.5~exp1_all.deb

The maven-debian-helper change is here [1].  The two packages have been
tested in conjunction to ensure that:

- Maven output is colorized by default when invoked during Debian
  package builds that depend on maven-debian-helper.

- Direct `mvn` Maven output is not colorized by default.

- MAVEN_OPTS, or any other mechanism to set the JVM property jansi.mode,
  can be used to specify the mode and override the default behavior.

I believe this covers the (large) majority of Debian build cases and
restores the upstream behavior, but please let me know if I've missed
something.  The version of gradle in Debian depends on libjansi1-java,
and so wasn't impacted by the patch to jansi (version 2.x).

Assuming there aren't any concerns, I plan to upload maven-debian-helper
and then the jansi package to unstable on January 7th.

Thanks,
tony

[1] 
https://salsa.debian.org/java-team/maven-debian-helper/-/commit/082b5b639880e8b3b1c1e98f5ae4f649e3b83b67


signature.asc
Description: PGP signature

Bug#1059541: apertium: FTBFS with utfcpp 4.x

[Boyuan Yang]

Source: apertium
Version: 3.8.3-3
Severity: important
Tags: patch
Forwarded: https://github.com/apertium/apertium/issues/193

Currently apertium fails to build from source using utfcpp 4.x (currently
in Debian Experimental).

The upstream issue is at https://github.com/apertium/apertium/issues/193 .
The upstream patch is at https://github.com/apertium/apertium/issues/193 .

Thanks,
Boyuan Yang


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

Bug#1059540: apt: Infinite loop when config file is a directory

[as]

Package: apt
Version: 2.6.1
Severity: normal
X-Debbugs-Cc: none

The following causes apt-get to go into an infinite busy loop:

```
$ mkdir /tmp/empty
$ apt-get -c /tmp/empty
```

This affects the latest dev build as well.

I submitted a fix here:
https://salsa.debian.org/apt-team/apt/-/merge_requests/314

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

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

Versions of packages apt depends on:
ii  adduser 3.134
ii  debian-archive-keyring  2023.3+deb12u1
ii  gpgv2.2.40-1.1
ii  libapt-pkg6.0   2.6.1
ii  libc6   2.36-9+deb12u3
ii  libgcc-s1   12.2.0-14
ii  libgnutls30 3.7.9-2+deb12u1
ii  libseccomp2 2.5.4-1+b3
ii  libstdc++6  12.2.0-14
ii  libsystemd0 252.17-1~deb12u1

Versions of packages apt recommends:
ii  ca-certificates  20230311

Versions of packages apt suggests:
pn  apt-doc 
ii  dpkg-dev1.21.22
ii  gnupg   2.2.40-1.1
pn  powermgmt-base  
ii  synaptic0.91.3

Bug#1055312: adduser: "addgroup user group" is mentioned in man page but does not work anymore (ex bug 664869)

[theofficialgman]

This bug has been reported by multiple users across multiple bug reports.
It is functionality that has existed since 1995 and is well adopted and
expected in scripts and documentation (both the manpage and 3rd party). Fix
the manpage and revert the patch and accept that this is intended and
necessary functionality. Breaking something that has existed for 25 years
just because the documentation isn't as clear as you would like is not a
valid excuse.

Bug#1059511: pocl: FTBFS on many architectures: The testsuite has failed

[Andreas Beckmann]

Control: retitle -1 pocl: FTBFS on riscv64: testsuite fails: can't link 
double-float modules with soft-float modules
Control: severity -1 wishlist

On 27/12/2023 09.54, Bo YU wrote:

The same issue happend on 5.0 also:
https://buildd.debian.org/status/package.php?p=pocl=experimental

But from upstream 5.0 release note, there is support well expect 4 tests
failed. So what is your advice here about the issue?


In the buildlog I see

  13% tests passed, 228 tests failed out of 263

Errors seem to happen at OpenCL kernel build time:

  LLVM ERROR: unable to write nop sequence of 2 bytes

and mostly

  /usr/bin/ld: /lib/riscv64-linux-gnu/libm.so: can't link double-float
  modules with soft-float modules

  /usr/bin/ld: failed to merge target specific data of file
  /lib/riscv64-linux-gnu/libm.so

  /usr/bin/ld: /lib/riscv64-linux-gnu/libgcc_s.so.1: can't link double-float
  modules with soft-float modules

  /usr/bin/ld: failed to merge target specific data of file
  /lib/riscv64-linux-gnu/libgcc_s.so.1

  /usr/bin/ld: /lib/riscv64-linux-gnu/libc.so.6: can't link double-float
  modules with soft-float modules

  /usr/bin/ld: failed to merge target specific data of file
  /lib/riscv64-linux-gnu/libc.so.6

  /usr/bin/ld: /lib/ld-linux-riscv64-lp64d.so.1: can't link double-float
  modules with soft-float modules

  /usr/bin/ld: failed to merge target specific data of file
  /lib/ld-linux-riscv64-lp64d.so.1

  /usr/bin/ld: /lib/riscv64-linux-gnu/libgcc_s.so.1: can't link double-float
  modules with soft-float modules

  /usr/bin/ld: failed to merge target specific data of file
  /lib/riscv64-linux-gnu/libgcc_s.so.1

  error: linker command failed with exit code 1 (use -v to see invocation)

  Final linking of kernel test_shuffle_2_2 failed.


I'd suggest postponing further analysis until sid has pocl 5.0 and
switched from llvm-15 to llvm-16. These two changes will *not* happen in
a single upload.


Andreas

Bug#1057302: Bug#1057234: sbuild: Generates weird messages in /var/log/syslog

[Richard Lewis]

On Sun, 3 Dec 2023 00:06:23 +0100 =?UTF-8?B?UHJldcOfZSwgSGlsbWFy?=
 wrote:
> On 02.12.2023 08:30, Johannes Schauer Marin Rodrigues wrote:
> > Quoting Hilmar Preusse (2023-12-01 23:10:36)
>
> Hi,
>
> >> I run sbuild as following:
> >>
> >> sbuild --no-run-lintian --arch-all --dist=sid *.dsc -d 
> >> unstable-amd64-sbuild
> >>
> >> , where unstable-amd64-sbuild references a chroot. Updating the chroot is 
> >> done:
> >>
> >> sudo sbuild-update -udcar unstable-amd64-sbuild
> >>
> >> Both commands generate weird messages in /var/log/syslog like this:
> >>
> >> 2023-12-01T09:36:52.230653+01:00 haka2 schroot[3182]: [unstable-
> >> amd64-sbuild-327cf8c2-30d1-4469-aa7b-9bc3653dbc45 chroot] (root->root) 
> >> Running
> >> command: "perl -e #012use strict;#012
> >> use warnings;#012use POSIX;#012

> > it may also be an issue with schroot, no? I do not think sbuild at any point
> > tells schroot to write anything to syslog.

I think this is done by the calls to debug, eg here:

https://salsa.debian.org/debian/sbuild/-/blob/main/lib/Sbuild/Chroot.pm?ref_type=heads#L811
debug("Running command: ", join(" ", @$command), "\n");

debug() is defined at
https://salsa.debian.org/debian/sbuild/-/blob/main/lib/Sbuild.pm?ref_type=heads#L336

to print to STDERR, which systemd will then connect to the journal (i
don't know how this last bit works, i think
it happens from schroot  - but the lines to write are generated by sbuild)

Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)

[Drew Parsons]

Hi Alistair, given the complexity around hacking openmpi to accommodate 
placing the mod files under /usr/include, I'm starting to wonder whether 
it's the best way of resolving Bug#1058526 in the first place.


I did it bit of background reading on the fortran mod files.  There's a 
fair bit of dissent about them, and no consensus on a proper location.  
e.g. https://fortranwiki.org/fortran/show/Library+distribution
The files are binary dependent (and compiler version dependent), and not 
clear that /usr/include is the best place for them anyway.


mpich seems to be fine placing them in 
/usr/lib/x86_64-linux-gnu/fortran/gfortran-mod-15/mpich, and openmpi 
seemed to be happy enough doing the same up until Bug#1058526.


Is there a different way of resolving Bug#1058526 without moving the mod 
files to /usr/include?


Drew

Bug#1059534: DEP17: handle /usr-move for gzip and its diversions by zutils

[Helmut Grohne]

reassign 1059534 zutils
found 1059534 zutils/1.12-3
user helm...@debian.org
usertags 1059534 = dep17p3
thanks

On Wed, Dec 27, 2023 at 06:13:07PM +0100, Helmut Grohne wrote:
> For gzip the story is relatively simple. It moves all the files, but it
> must not be unpacked when there is a version of zutils installed that
> hasn't duplicated its diversions yet. The best we can do here is adding
> versioned Conflicts (not Breaks). I caution that this is not entirely
> bullet-proof. If you `echo zutils deinstall | dpkg --set-selections` and
> then `dpkg --unpack new_gzip.deb`, it'll unpack the moved gzip first and
> then remove zu old zutils that lacks the duplicated diversions. Even in
> this case, the gzip package would continue working after the upgrade.

Looking closer, it turns out my patch really wasn't moving stuff. I've
now updated the patch and could actually reproduce the loss as detailed
above. The updated patch includes a mitigation, but this only happens in
postinst. From unpack of gzip until gzip.postinst, some files may be
missing. This is a violation of Debian policy section 3.8. I fear there
is nothing we can do about this policy violation.

I note that while we will violate policy here, the violation is
time-limited (unpack gzip -> gzip.postinst) and there is no known way to
experience it unless interacting with dpkg directly. So anyone
performing the upgrade using apt (or aptitude or some graphical
frontend) will never experience this problem. I hope this is ok-ish.

> For zutils, the story is less easy. In order to avoid apt issuing a
> temporary removal of zutils (and thus trigger the wrongly ordered
> unpacks above), zutils must not issue versioned breaks for gzip and
> therefore it must carry the aliased diversions during the trixie cycle
> (and not just during the upgrade).
 
No change here.

> So I've developed these patches (both attached). Since piuparts doesn't
> deal well with testing essential packages, I've developed test cases
> using mmdebstrap (also attached) and performed the --set-selections test
> manually. Everything looks fine, but I keep the fingers crossed.

Tests rerun successfully.

> I ask you to upload these changes to experimental (not unstable). Once
> both updates are in experimental, dumat will be able to analyze and
> we'll also see what other kinds of QA says. Then once that works for
> both packages, we can upload zutils to unstable and then gzip.

Unchanged.

Sorry for the initially broken gzip patch.

Helmut
diff -Nru gzip-1.12/debian/changelog gzip-1.12/debian/changelog
--- gzip-1.12/debian/changelog  2022-04-10 04:22:26.0 +0200
+++ gzip-1.12/debian/changelog  2023-12-23 07:46:32.0 +0100
@@ -1,3 +1,10 @@
+gzip (1.12-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move files to /usr (closes: #-1)
+
+ -- Helmut Grohne   Sat, 23 Dec 2023 07:46:32 +0100
+
 gzip (1.12-1) sid; urgency=high
 
   * new upstream release
diff -Nru gzip-1.12/debian/clean gzip-1.12/debian/clean
--- gzip-1.12/debian/clean  1970-01-01 01:00:00.0 +0100
+++ gzip-1.12/debian/clean  2023-12-23 07:46:32.0 +0100
@@ -0,0 +1 @@
+gzip.postinst
diff -Nru gzip-1.12/debian/control gzip-1.12/debian/control
--- gzip-1.12/debian/control2022-04-10 04:05:08.0 +0200
+++ gzip-1.12/debian/control2023-12-23 07:27:28.0 +0100
@@ -16,6 +16,7 @@
 Pre-Depends: ${shlibs:Depends}
 Depends: dpkg (>= 1.15.4) | install-info
 Suggests: less
+Conflicts: zutils (<< 1.12-3.1~)
 Description: GNU compression utilities
  This package provides the standard GNU file compression utilities, which
  are also the default compression tools for Debian.  They typically operate
diff -Nru gzip-1.12/debian/dirs gzip-1.12/debian/dirs
--- gzip-1.12/debian/dirs   2022-04-09 04:15:18.0 +0200
+++ gzip-1.12/debian/dirs   2023-12-23 07:46:32.0 +0100
@@ -1,3 +1,2 @@
-bin
 usr/share/info
 usr/share/man/man1
diff -Nru gzip-1.12/debian/gzip.postinst.gen gzip-1.12/debian/gzip.postinst.gen
--- gzip-1.12/debian/gzip.postinst.gen  1970-01-01 01:00:00.0 +0100
+++ gzip-1.12/debian/gzip.postinst.gen  2023-12-23 07:46:32.0 +0100
@@ -0,0 +1,23 @@
+#!/bin/sh
+
+echo "#!/bin/sh"
+echo
+echo "set -e"
+echo
+# The following if block (and probably the entire maintainer script) can be
+# removed after trixie.
+echo 'if test "$1" = configure && test -n "$2"; then'
+
+for f in zcat zcmp zdiff zegrep zfgrep zgrep; do
+   echo "  if ! test -e /usr/bin/$f; then"
+   echo "cat >/usr/bin/$f <<'END_OF_SCRIPT'"
+   cat "debian/gzip/usr/bin/$f"
+   echo END_OF_SCRIPT
+   echo "chown 0:0 /usr/bin/$f"
+   echo "chmod 0755 /usr/bin/$f"
+   echo "  fi"
+done
+
+echo fi
+echo
+echo "#DEBHELPER#"
diff -Nru gzip-1.12/debian/rules gzip-1.12/debian/rules
--- gzip-1.12/debian/rules  2022-04-09 04:15:18.0 +0200
+++ gzip-1.12/debian/rules  2023-12-23 07:46:32.0 +0100
@@ -47,9 +47,9 @@
 _topdir=$(call 

Bug#1030118: drbd-utils: Warning in initscript about missing /var/lib/linstor/loop_device_mapping

[tux2bsd]

> On Saturday, December 16th, 2023 at 3:18 PM, tux2bsd wrote:
> 
> > I've submitted a fix upstream, with any luck it's accepted

It has been accepted:

https://github.com/LINBIT/drbd-utils/pull/38

tux2bsd

Bug#1059484: rasdaemon: autopkgtest failure: cannot access '/var/lib/rasdaemon/ras-mc_event.db'

[Taihsiang Ho (tai271828)]

Hi Paul,

Thanks for reporting the issue. I will take a look.

-tai

On Tue, Dec 26, 2023 at 7:09 PM Paul Gevers  wrote:
>
> Source: rasdaemon
> Version: 0.8.0-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: fails-always
>
> Dear maintainer(s),
>
> You recently added an autopkgtest to your package rasdaemon, great.
> However, it fails. Currently this failure is blocking the migration to
> testing [1]. Can you please investigate the situation and fix it?
>
> I copied some of the output at the bottom of this report.
>
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
>
> Paul
>
> [1] https://qa.debian.org/excuses.php?package=rasdaemon
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/r/rasdaemon/40156577/log.gz
>
>   34s ls: cannot access '/var/lib/rasdaemon/ras-mc_event.db': No such
> file or directory
>   34s autopkgtest [11:52:08]: test ras-mc-ctl

Bug#1059539: bugs.debian.org: Updating multiple packages made my system really slow with opening GTK applications

[Ziga Lausegger]

Package: bugs.debian.org
Severity: important

Dear Maintainer,

My last 2 updates made my debian system really slow when opening GTK 
applications. Before this update, GTK applications were opening normally 
but now applications like Firefox, Thunar, Waybar... open really slowly 
(after 20 seconds)! Another symptom that started to happen after this 
update is that original Dropbox client application is not shown any 
longer in the system tray (Waybar).


The update that I did is this one that I took from /var/lib/apt/history.log:



Start-Date: 2023-12-24  21:27:24

Commandline: apt install libwebkit2gtk-4.0-37

Requested-By: ziga (1000)

Install: bubblewrap:amd64 (0.8.0-2, automatic), libwpebackend-fdo-1.0-1:amd64 
(1.14.2-1, automatic), xdg-desktop-portal-gtk:amd64 (1.14.1-1, automatic), 
libmanette-0.2-0:amd64 (0.2.6-3+b1, automatic), libwoff1:amd64 (1.0.2-2, 
automatic), libwpe-1.0-1:amd64 (1.14.0-1, automatic), 
libjavascriptcoregtk-4.0-18:amd64 (2.42.4-1~deb12u1, automatic), 
libwebkit2gtk-4.0-37:amd64 (2.42.4-1~deb12u1), xdg-dbus-proxy:amd64 (0.1.4-3, 
automatic), xdg-desktop-portal:amd64 (1.16.0-2, automatic)

End-Date: 2023-12-24  21:27:31

Start-Date: 2023-12-24  21:29:06

Commandline: apt upgrade

Requested-By: ziga (1000)

Install: linux-image-6.1.0-16-amd64:amd64 (6.1.67-1, automatic)

Upgrade: libfreeimage3:amd64 (3.18.0+ds2-9, 3.18.0+ds2-9+deb12u1), 
libperl5.36:amd64 (5.36.0-7, 5.36.0-7+deb12u1), libcups2:amd64 
(2.4.2-3+deb12u4, 2.4.2-3+deb12u5), libcurl4:amd64 (7.88.1-10+deb12u4, 
7.88.1-10+deb12u5), libreoffice-calc:amd64 (4:7.4.7-1, 4:7.4.7-1+deb12u1), 
udev:amd64 (252.17-1~deb12u1, 252.19-1~deb12u1), exfatprogs:amd64 (1.2.0-1, 
1.2.0-1+deb12u1), uno-libs-private:amd64 (4:7.4.7-1, 4:7.4.7-1+deb12u1), 
libreoffice-base-core:amd64 (4:7.4.7-1, 4:7.4.7-1+deb12u1), libnghttp2-14:amd64 
(1.52.0-1, 1.52.0-1+deb12u1), libcurl3-gnutls:amd64 (7.88.1-10+deb12u4, 
7.88.1-10+deb12u5), openssh-client:amd64 (1:9.2p1-2+deb12u1, 
1:9.2p1-2+deb12u2), libreoffice-core:amd64 (4:7.4.7-1, 4:7.4.7-1+deb12u1), 
cups-bsd:amd64 (2.4.2-3+deb12u4, 2.4.2-3+deb12u5), systemd-timesyncd:amd64 
(252.17-1~deb12u1, 252.19-1~deb12u1), perl:amd64 (5.36.0-7, 5.36.0-7+deb12u1), 
tzdata:amd64 (2023c-5, 2023c-5+deb12u1), cups-common:amd64 (2.4.2-3+deb12u4, 
2.4.2-3+deb12u5), libpam-systemd:amd64 (252.17-1~deb12u1, 252.19-1~deb12u1), 
libreoffice-common:amd64 (4:7.4.7-1, 4:7.4.7-1+deb12u1), ure:amd64 (4:7.4.7-1, 
4:7.4.7-1+deb12u1), bluetooth:amd64 (5.66-1, 5.66-1+deb12u1), libminizip1:amd64 
(1.1-8+b1, 1.1-8+deb12u1), libgs10-common:amd64 (10.0.0~dfsg-11+deb12u2, 
10.0.0~dfsg-11+deb12u3), cups-client:amd64 (2.4.2-3+deb12u4, 2.4.2-3+deb12u5), 
cups-ppdc:amd64 (2.4.2-3+deb12u4, 2.4.2-3+deb12u5), cups-daemon:amd64 
(2.4.2-3+deb12u4, 2.4.2-3+deb12u5), libtiffxx6:amd64 (4.5.0-6, 
4.5.0-6+deb12u1), gimp-data:amd64 (2.10.34-1, 2.10.34-1+deb12u2), 
linux-compiler-gcc-12-x86:amd64 (6.1.55-1, 6.1.67-1), libtiff6:amd64 (4.5.0-6, 
4.5.0-6+deb12u1), libgs10:amd64 (10.0.0~dfsg-11+deb12u2, 
10.0.0~dfsg-11+deb12u3), libsystemd0:amd64 (252.17-1~deb12u1, 
252.19-1~deb12u1), libnss-systemd:amd64 (252.17-1~deb12u1, 252.19-1~deb12u1), 
openssh-server:amd64 (1:9.2p1-2+deb12u1, 1:9.2p1-2+deb12u2), 
libuno-purpenvhelpergcc3-3:amd64 (4:7.4.7-1, 4:7.4.7-1+deb12u1), 
libuno-cppu3:amd64 (4:7.4.7-1, 4:7.4.7-1+deb12u1), libqpdf29:amd64 (11.3.0-1, 
11.3.0-1+deb12u1), libuno-cppuhelpergcc3-3:amd64 (4:7.4.7-1, 
4:7.4.7-1+deb12u1), fonts-opensymbol:amd64 (4:102.12+LibO7.4.7-1, 
4:102.12+LibO7.4.7-1+deb12u1), systemd:amd64 (252.17-1~deb12u1, 
252.19-1~deb12u1), libudev1:amd64 (252.17-1~deb12u1, 252.19-1~deb12u1), 
linux-kbuild-6.1:amd64 (6.1.55-1, 6.1.67-1), cups-ipp-utils:amd64 
(2.4.2-3+deb12u4, 2.4.2-3+deb12u5), ghostscript:amd64 (10.0.0~dfsg-11+deb12u2, 
10.0.0~dfsg-11+deb12u3), libreoffice-style-colibre:amd64 (4:7.4.7-1, 
4:7.4.7-1+deb12u1), gimp:amd64 (2.10.34-1, 2.10.34-1+deb12u2), 
linux-image-amd64:amd64 (6.1.55-1, 6.1.67-1), libgimp2.0:amd64 (2.10.34-1, 
2.10.34-1+deb12u2), libgstreamer-plugins-bad1.0-0:amd64 (1.22.0-4+deb12u2, 
1.22.0-4+deb12u4), libreoffice-writer:amd64 (4:7.4.7-1, 4:7.4.7-1+deb12u1), 
xserver-common:amd64 (2:21.1.7-3+deb12u2, 2:21.1.7-3+deb12u4), 
libuno-salhelpergcc3-3:amd64 (4:7.4.7-1, 4:7.4.7-1+deb12u1), base-files:amd64 
(12.4+deb12u2, 12.4+deb12u4), distro-info-data:amd64 (0.58, 0.58+deb12u1), 
libbluetooth3:amd64 (5.66-1, 5.66-1+deb12u1), python3-uno:amd64 (4:7.4.7-1, 
4:7.4.7-1+deb12u1), perl-base:amd64 (5.36.0-7, 5.36.0-7+deb12u1), 
openssh-sftp-server:amd64 (1:9.2p1-2+deb12u1, 1:9.2p1-2+deb12u2), 
libuno-sal3:amd64 (4:7.4.7-1, 4:7.4.7-1+deb12u1), cups-core-drivers:amd64 
(2.4.2-3+deb12u4, 2.4.2-3+deb12u5), libsystemd-shared:amd64 (252.17-1~deb12u1, 
252.19-1~deb12u1), systemd-sysv:amd64 (252.17-1~deb12u1, 252.19-1~deb12u1), 
bluez:amd64 (5.66-1, 5.66-1+deb12u1), libgnutls30:amd64 (3.7.9-2, 
3.7.9-2+deb12u1), cups:amd64 (2.4.2-3+deb12u4, 2.4.2-3+deb12u5), curl:amd64 
(7.88.1-10+deb12u4, 7.88.1-10+deb12u5), 

Bug#1053825: Screensaver with only blank does not work after suspend

[Klaus Ethgen]

Hi Salvatore,

Am Mi den 27. Dez 2023 um 21:24 schrieb Salvatore Bonaccorso:
> I do realize, but given we have nobody else reporting similar
> behaviour we need to rely on you bisecting the breaking change so it
> might be reported upstream. But that said, in meanwhile we have
> 6.6.8-1 uploaded to unstable. It would be great if you can report back
> if that version resolves the issue.

I already installed the kernel and test it. As a site note, it does not
work with dkms anymore as the header links are in /usr/lib/modules where
no kernel is able to find them.

However, I will keep an eye on it and see if the bug is fixed (as I did
with the kernels in between.) Give me some time as the bug is not that
relyable.

> If it's still reproducibe, check first that it's as well reproducible
> with an untained kernel because othwerise an upstream report might not
> be accepted.

On that system I use untained kernel (I did not on a different system
with nvidia, but there I use my own kernel and the bug is related to amd
GPU.)

Regards
   Klaus
-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C


signature.asc
Description: PGP signature

Bug#1053825: Screensaver with only blank does not work after suspend

[Salvatore Bonaccorso]

Hi Klaus,

On Sat, Oct 21, 2023 at 08:34:55AM +0100, Klaus Ethgen wrote:
> Hi,
> 
> Am Do den 19. Okt 2023 um 20:46 schrieb Salvatore Bonaccorso:
> > On Thu, Oct 12, 2023 at 06:57:20AM +0100, Klaus Ethgen wrote:
> > > Package: src:linux
> > > Version: 6.5.6-1
> > > Severity: critical
> > > Tags: security
> > > X-Debbugs-Cc: Debian Security Team 
> > > 
> > > It is not fully clear for me, where exactly this bug happens. First I
> > > was thinking about xscreensaver but that package got not updated for
> > > ages. The bug happens with updates from kernel 6.4.0 to 6.5.0.
> > 
> > So you are saying this happens solely after switching from 6.4.y
> > series to 6.5.y series. Thus I assume 6.5.3-1 in testing as well
> > exposes the issue.
> 
> Might be but I cannot test that due to the other AMD display related
> bug.
> 
> > > I use xscreensaver with fvwm3 on my amd laptop. xscreensaver is set up
> > > to only blank the screen.
> 
> I first thought, that it does not happen with fvwm2 but I also see it
> with fvwm2 but not that often.
> 
> > > When I lock the screen and press a key or moving the mouse, everything
> > > is fine. But when I go to suspend too ram after locking and waking up
> > > the laptop, the password dialog gets showed as usual but I can see the
> > > full desktop content with probably sensitive material on in. Although, I
> > > cannot interact with the desktop, it is a security break to reveal the
> > > content without authenticating.
> > > 
> > > It might be related, when I have a PSI chat window on the screen but on
> > > different desktop, it gets moved to the current one. That definitively
> > > also came with the new kernel.
> > 
> > Can you please attach as well the kernel log once you triggered the
> > behaviour? Anything suspicious logged? 
> 
> I could. But there is no hint and no unusual log entry.
> 
> > Next, can you bisect the kernel between a good known upstream version
> > and 6.5.6? Can you as well test 6.5.7 upstream to see if it fixes the
> > issue?
> 
> That would take many time to recompile kernel, test it for several hours
> and try again.

I do realize, but given we have nobody else reporting similar
behaviour we need to rely on you bisecting the breaking change so it
might be reported upstream. But that said, in meanwhile we have
6.6.8-1 uploaded to unstable. It would be great if you can report back
if that version resolves the issue.

If it's still reproducibe, check first that it's as well reproducible
with an untained kernel because othwerise an upstream report might not
be accepted.

Can you check that?

Regards,
Salvatore

Bug#1059535: transition: abseil

[Rene Engelhard]

Hi,

Am 27.12.23 um 19:15 schrieb Benjamin Barenblat:

Although doing a transition now will break some packages in sid, I
believe waiting is likely to cause more issues. Upstreams (LibreOffice
in particular) are starting to use features from the new version of
Abseil,


Actually it's not LibreOffice but LibreOffice indirectly via pdfium 
(which makes chromium also be affected if it did build without using the 
embedded copy of abseil).



That said libreoffice builds (both sids and experimentals version). 
Tested on amd64 only, but



Regards,


Rene

Bug#1059358: transition: wolfssl

[Sebastian Ramacher]

Control: tags -1 confirmed

Hi Bastian

On 2023-12-23 14:30:39 +0100, Bastian Germann wrote:
> Package: release.debian.org
> Control: affects -1 wolfssl
> X-Debbugs-Cc: wolf...@packages.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> Severity: normal
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-wolfssl.html
> 
> wolfssl is available in experimental with libwolfssl42.
> This transition is from libwolfssl41.
> The auto-generated Ben file is okay and all reverse dependencies build fine.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1059330: transition: shapelib

[Sebastian Ramacher]

Control: tags -1 confirmed

Hi Bas

On 2023-12-22 16:39:57 +0100, Bas Couwenberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: shape...@packages.debian.org
> Control: affects -1 + src:shapelib
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-shapelib.html
> 
> Shapelib 1.6.0 bumps the SONAME requiring a transition.
> 
> All rdeps built successfully with the new version as summarized below.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1059272: transition: tango

[Sebastian Ramacher]

Control: tags -1 confirmed

Hi Santiago

On 2023-12-22 08:36:17 -0300, Santiago Ruano Rincón wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: ta...@packages.debian.org, thomas.br...@byte-physics.de
> Control: affects -1 + src:tango
> 
> Dear Release Team,
> 
> I would like to upload tango 9.5.0 to unstable. There has been a SONAME
> bump from 9.4.2. Its reverse dependency pytango 9.5.0 builds and works
> well. Both are available in experimental.
> 
> This set of uploads are needed to fix the pytango FTBFS bugs in unstable
> related to python3.12:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055733
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1049843
> 
> Even if there is only one reverse dependency, I prefer to ask: May I go
> ahead?

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1058935: reverse dependencies

[Luca Boccassi]

Control: tags -1 -moreinfo

On Thu, 21 Dec 2023 17:48:53 + (UTC) Thorsten Alteholz
 wrote:
> Control: tags -1 + moreinfo
> 
> Hi Luca,
> 
> there are reverse dependencies that need to be taken care of:
> 
> Checking reverse dependencies...
> # Broken Build-Depends:
> collectd: libdpdk-dev
> openvswitch: libdpdk-dev (22.11.3-2~ >=)
> uhd: libdpdk-dev (20 >=)
> 
> In case they matter, this needs to be addressed first. Please remove
the 
> moreinfo tag once that is done.

These are all gone now, thanks.

-- 
Kind regards,
Luca Boccassi

Bug#1059538: flask-socketio: Please package recent version 5.3.6

[Carsten Schoenert]

Source: flask-socketio
Version: 5.3.2-1
Severity: wishlist

Dear Maintainer,

please consider updating your package to the current most recent version
5.3.6.

We are in prearation for updating Flask to version 3.x in unstable in
the next future. For now we've upload Flask and Werkzeug 3.x to
experimental.

The current version of flask-socketio in unstable and testing is failing
in the autopkgtest with python3-werkzeug 3.0.1-1 and python3-flask 3.0.0-1
available in experimental.

https://ci.debian.net/packages/f/flask-socketio/unstable/amd64/41360754/

Updating your package to the most recent version should fix the failing
tests hopefully.

Regards
Carsten

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/4 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

Bug#1059537: man-db: please (provide an option to) remove the 5-column right margin

[наб]

Package: man-db
Version: 2.12.0-1
Version: 2.11.2-2
Severity: wishlist

Dear Maintainer,

I just noticed this and now it's bugging me to no end.
Given
  $ stty size
  48 122
the debug output (attached) says 
  Terminal width 122
  Using 118-character lines

Similarly, stty size -> 54 172 -> "groff", ..., "-rLL=167n", "-rLT=167n".

Faking a five-column-wider teletype via
  alias man='MANWIDTH=$(stty size | { read -r _ w; echo $(( w + 5 )); }) man'
draws the manual at full width.

I don't really see why there's a right margin,
if no left margin is enforced.

Best,
наб

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

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

Versions of packages man-db depends on:
ii  bsdextrautils  2.38.1-5+b1
ii  debconf [debconf-2.0]  1.5.82
ii  groff-base 1.22.4-10
ii  libc6  2.36-9+deb12u3
ii  libgdbm6   1.23-3
ii  libpipeline1   1.5.7-1
ii  libseccomp22.5.4-1+b3
ii  zlib1g 1:1.2.13.dfsg-1

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor3.0.8-3
ii  groff   1.22.4-10
ii  less590-2
ii  lynx [www-browser]  2.9.0dev.12-1
ii  w3m [www-browser]   0.5.3+git20230121-2

-- Configuration Files:
/etc/manpath.config changed:
MANDATORY_MANPATH   /usr/man
MANDATORY_MANPATH   /usr/share/man
MANDATORY_MANPATH   /usr/local/share/man
MANPATH_MAP /bin/usr/share/man
MANPATH_MAP /usr/bin/usr/share/man
MANPATH_MAP /sbin   /usr/share/man
MANPATH_MAP /usr/sbin   /usr/share/man
MANPATH_MAP /usr/local/bin  /usr/local/man
MANPATH_MAP /usr/local/bin  /usr/local/share/man
MANPATH_MAP /usr/local/sbin /usr/local/man
MANPATH_MAP /usr/local/sbin /usr/local/share/man
MANPATH_MAP /usr/X11R6/bin  /usr/X11R6/man
MANPATH_MAP /usr/bin/X11/usr/X11R6/man
MANPATH_MAP /usr/games  /usr/share/man
MANPATH_MAP /opt/bin/opt/man
MANPATH_MAP /opt/sbin   /opt/man
MANDB_MAP   /usr/man/var/cache/man/fsstnd
MANDB_MAP   /usr/share/man  /var/cache/man
MANDB_MAP   /usr/local/man  /var/cache/man/oldlocal
MANDB_MAP   /usr/local/share/man/var/cache/man/local
MANDB_MAP   /usr/X11R6/man  /var/cache/man/X11R6
MANDB_MAP   /opt/man/var/cache/man/opt
MANDB_MAP   /snap/man   /var/cache/man/snap
SECTION 1 n l 8 3 0 2 3type 3posix 3pm 3perl 3am 5 4 9 6 7
NOCACHE


-- debconf information:
  man-db/install-setuid: false
  man-db/auto-update: true
ruid=1000, euid=1000
rgid=1000, egid=1000
From the config file /etc/manpath.config:
  Mandatory mandir `/usr/man'.
  Mandatory mandir `/usr/share/man'.
  Mandatory mandir `/usr/local/share/man'.
  Path `/bin' mapped to mandir `/usr/share/man'.
  Path `/usr/bin' mapped to mandir `/usr/share/man'.
  Path `/sbin' mapped to mandir `/usr/share/man'.
  Path `/usr/sbin' mapped to mandir `/usr/share/man'.
  Path `/usr/local/bin' mapped to mandir `/usr/local/man'.
  Path `/usr/local/bin' mapped to mandir `/usr/local/share/man'.
  Path `/usr/local/sbin' mapped to mandir `/usr/local/man'.
  Path `/usr/local/sbin' mapped to mandir `/usr/local/share/man'.
  Path `/usr/X11R6/bin' mapped to mandir `/usr/X11R6/man'.
  Path `/usr/bin/X11' mapped to mandir `/usr/X11R6/man'.
  Path `/usr/games' mapped to mandir `/usr/share/man'.
  Path `/opt/bin' mapped to mandir `/opt/man'.
  Path `/opt/sbin' mapped to mandir `/opt/man'.
  Global mandir `/usr/man', catdir `/var/cache/man/fsstnd'.
  Global mandir `/usr/share/man', catdir `/var/cache/man'.
  Global mandir `/usr/local/man', catdir `/var/cache/man/oldlocal'.
  Global mandir `/usr/local/share/man', catdir `/var/cache/man/local'.
  Global mandir `/usr/X11R6/man', catdir `/var/cache/man/X11R6'.
  Global mandir `/opt/man', catdir `/var/cache/man/opt'.
  Global mandir `/snap/man', catdir `/var/cache/man/snap'.
  Added sections: `1', `n', `l', `8', `3', `0', `2', `3type', `3posix', `3pm', 
`3perl', `3am', `5', `4', `9', `6', `7'.
is a tty
using pager as pager
path directory /home/nabijaczleweli/bin is not in the config file
path directory /usr/local/sbin is in the config file
  adding /usr/local/man to manpath
  adding /usr/local/share/man to manpath
path directory 

Bug#1059536: groff-base: mdoc nroff output (Nm, Dt) broken since 1.23

[наб]

Package: groff-base
Version: 1.23.0-3
Severity: normal

Dear Maintainer,

This isn't about the many other font changes, especially the troff ones
(though changing Cm/Fl to CR from CB in troff mode
 is basically violence against the user,
 and changing Pa from C to I and Xr from B to nothing is awful)
because I'm the only psycho who actually renders PDFs and can patch this,
or even the other nroff font changes
(Sx I->Dq is weird, especially contrasted with Xr R->I
 (which I'm not gonna complain too much about but it is odd;
  you don't need any font because there's a big sexion specifier there);
 I might even agree with Li R->B);
(it would be nice if reversions were provided by default
 or with an easy opt-in in Debian I've personally been using
   .\" Comparing groff-base 1.23.0-3 with 1.22.4-10
   .\" Based on 
https://paste.sr.ht/~nabijaczleweli/e897d091aa5b62c284c6c996d90253023b6271f7
   .\"
   .\" 1.23 effectively aliases Sx to Dq. undo this
   .als Sx doc-generic-macro
   .ds doc-Sx-usage section_header
   .
   .ie n \{ .
   .\" doc-nroff
   .ds doc-Li-font \f[R]
   .\" \f[B] in 1.23
   .
   .ds doc-Sx-font \f[I]
   .\" dropped in 1.23
   .
   .ds doc-Xr-font \f[R]
   .\" \f[I] in 1.23
   . \}
   .el \{ .
   .\" doc-ditroff
   .ds doc-Sx-font \f[B]
   .\" dropped in 1.23
   .
   .ds doc-Xr-font \f[C]
   .\" \f[I] in 1.23
   .
   .ds doc-page-topic-font \f[R]
   .\" \f[I] in 1.23; used to be called doc-caption-font
   .
   .ds doc-Cm-font \f[CB]
   .\" \f[CR] in 1.23
   .
   .ds doc-Fl-font \f[CB]
   .\" \f[CR] in 1.23
   .
   .ds doc-Pa-font \f[C]
   .\" \f[I] in 1.23
   . \}
 since, commit date says, 2023-11-14)
this is about the two "obviously-broken" changes.

1:
The first invocation of Nm in NAME is broken:
it correctly saves the first argument to the string register,
but it draws the argument in R instead of B.
This is in contrast to every other use of Nm
(and, thus, every other reference to the object the Nms refer to).
This is baffling and confusing; please revert this
(a quick peep at
   https://sources.debian.org/src/groff/1.23.0-3/tmac/doc.tmac/#L1166
 shows that this is an explicit change).

This is much harder to correct (I'd say impossible) for a casual user,
though I've added this to my mdoc.local
(it's not pretty nor is it nice but it does work against 1.23.0-3):
  .\" Handle '.Nm ...' in "Name" section: use the Nm font! It doesn't anymore 
in 1.23.
  .als Nm_old Nm
  .rm Nm
  .de Nm
  .if \\n[doc-in-name-section] \{\
  .  if "\\*[doc-topic-name]"" \
  .ds doc-topic-name "\\$1\"
  .  nr doc-in-name-section 0
  .\}
  .Nm_old \\$@
  ..

2:
Dt is misrendered but only in nroff mode.
Given
  .Dt A_B_C 9
In troff mode, and in 1.22.4-10, the top left and right corners were "A_B_C(9)".
In 1.23.0-3 in nroff they are "\fIA_B_C\fP(9)", which:
(a) why would you need this?
(b) completely breaks manuals with underscores in the name,
because "\fIA_B_C\fP(9)" and "A_B_C(9)" and "\fIA B C\fP(9)"
are all drawn identically.
I didn't have the time or the energy to root-cause this.

Best,
наб

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

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

Versions of packages groff-base depends on:
ii  libc6 2.36-9+deb12u3
ii  libgcc-s1 12.2.0-14
ii  libstdc++612.2.0-14
ii  libuchardet0  0.0.7-1

groff-base recommends no packages.

Versions of packages groff-base suggests:
ii  groff  1.22.4-10

-- no debconf information


signature.asc
Description: PGP signature

Bug#1055005: [Pkg-pascal-devel] Bug#1055005: Bug#1055005: lazarus-ide-2.2: gdb 13 dynamic array crash (regression: gdb 10 working)

[Abou Al Montacir]

On Thu, 2023-11-02 at 16:01 +, Peter B wrote:
> On 29/10/2023 08:27, Jonas Bechtel wrote:
> > Following conditions have to be met to reproduce the problem:
> > 
> > * The line must be in an extra unit (not application form class unit)
> > * gdb 13 must be installed (gdb 10 does not crash)
> 
> Given that the crash only occurs with gdb 13 and not with gdb 10,
> surely this is a bug in gdb, not with the Lazarus IDE?
> 
> gdb is pretty flakey...
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=gdb;dist=unstable
As a workaround, one can use Lazarus internal fpDebugger until we can understand
what is this issue exactly.
-- 
Cheers,
Abou Al Montacir


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

Bug#1059457:

[Brian Sammon]

> 
> If qemu-system-gui package is already installed you can just look at the l
> in it, - the list gives a good hint.  It should, - I hope anyway - be 
> enough to read the
> description already.  At the very least, almost no one looks at READMEs 
> inside packages,
> but some do look at the descriptions, especially before installing something. 
>  Maybe
> the description should be improved a bit.

Okay... it sounds like we're approaching agreement here.  I _did_ read the 
package description of qemu-system-gui (before creating this bug) and I'm still 
not clear what the package is for, or whether I should install it.

I have a suspicion that this is an important (for qemu) package, but I'm 
unclear about how/why.

I created this bug to say in essence that I think the documentation of this 
package needs to be improved.  I don't have my heart set on README.Debian as 
the means of doing it.  I would be happy with an improved package description.

I would be willing to submit a patch, if/when I understand the package enough 
that I could compose such documentation.

> Let's use another example. qemu-system-arm recommends (or suggests, don't 
> but let's assume it is Recommends) samba.  The reason is that qemu can us
> mode to share a directory on the host to the guest system it is running.  
> samba should carry a README explaining how it is used with qemu-system-arm

To follow this example-- I think samba should contain documentation explaining 
its primary purpose.  I suspect it does.  If there was a package called 
something like qemu-system-samba, I would expect that its primary purpose would 
be something directly related to qemu, and I would hope its documentation would 
explain how to use it with qemu.

> Your question comes from the lack of understanding what qemu itself is 
> and how to use it.

That's for sure!  I've never used qemu before.  I've used virtualbox and VMWare 
in the past.

> (and this is obvious from the list of files in the package).

I've had a lot of people on the internet lately tell me that something I'm 
confused about is "obvious".  Usually it means "if you've used this thing for 
as many years as I have, it's obvious".

> https://www.qemu.org/docs/master/system/invocation.html#hxtool-3 is the 
> part relevant to
> this context - qemu-system-gui provides sdl and gtk *modules* for qemu-
> system-* packages

Ah, yes!  This URL (and the fact that you suggested it) are very informative.

Would it be correct to say:
  This package enables the "gtk" and "sdl" display types used with the
  "-display" argument of qemu
?

If that is accurate, I think a sentence like that would be exactly the kind of 
addition to the qemu-system-gui documentation that I'm looking for (whether 
it's the package description, or README.Debian, or some other place)

Bug#1012289: Bug #1012289: Following up on Lintian

[Simon Quigley]

Hello,

In most recent Ubuntu cycles, I've taken on the "archive bootstrapping" 
responsibility of adding the new Ubuntu codename to Lintian. I remember 
having some deeper conversations with the former Lintian maintainer 
regarding further contributions and maintenance, but I also recall some 
politics, and quite frankly, *I don't care*. Regardless, Lintian is 
something I look at every cycle.

I'm writing today to express my concern about the current state of 
Lintian maintenance. I already understand that there is an RFH filed 
against Lintian, but that has not received any sort of followup since 
2022. The most recent Lintian upload is from March 2023, and as of the 
time of writing, there are 26 open merge requests[1].

I also understand that this is a volunteer team. My goal here is not to 
diminish the work of the current maintainers in any way, quite the 
opposite. I would simply like to ask, "do you need help?"

I'm not volunteering to take over Lintian entirely, nor do I want to. 
That being said, I would be motivated to sort through the current MR 
list and at least shave off some technical debt. If this is something 
you are open to, or if anyone else would be open to this as well, I 
think it is a worthwhile effort.

Lintian is crucially important for Debian development as it stands 
today. Before sponsoring a package, before uploading our own packages, 
and even once in the archive, we run Lintian all the time. I do not 
believe it is too late to put some additional minds behind this, to 
ensure Lintian survives for years to come. I simply feel as if *someone* 
should bump this thread, so we do not lose sight of it.

Thank you for your time. Please do let me know if you have any 
questions, or if I can do anything else to help.

[1] https://salsa.debian.org/lintian/lintian/-/merge_requests

Warm regards,

--
Simon Quigley
si...@tsimonq2.net
tsimonq2 on LiberaChat and OFTC
@tsimonq2:ubuntu.com on Matrix
5C7A BEA2 0F86 3045 9CC8
C8B5 E27F 2CF8 458C 2FA4


smime.p7m
Description: smime.p7m

Bug#1059376: [Pkg-pascal-devel] Bug#1059376: Bug#1059376: Bug#1059376: Bug#1059376: lcl is wrongly marked Multi-Arch: foreign

[Abou Al Montacir]

On Wed, 2023-12-27 at 12:01 +0100, Helmut Grohne wrote:
> > Please review this patch, and I'll upload it if you find it OK.
> 
> Reviewing M-A:same annotations is hard. Would you mind uploading to
> unstable (as the multiarch hinter does not look at experimental) and if
> it complains about M-A:same reupload with those M-A:same removed?
I'll wait one day more until current version reaches testing, then upload.
-- 
Cheers,
Abou Al Montacir


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

Bug#1059535: transition: abseil

[Benjamin Barenblat]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: abs...@packages.debian.org, Rene Engelhard 
Control: affects -1 + src:abseil

Abseil 20230802 has been out for a while, and I'd like to transition sid
to it. The new version has a new ABI (with a new SONAME and new binary
package names).

Tests for 20230802.1-2 in experimental are green on all supported
architectures except mips64el and riscv64. mips64el had no installable
libc when the builders ran; I expect it'll be fine when the transition
actually happens. Large parts of Abseil (including the version already
in sid) are broken on riscv64 right now because of
https://bugs.debian.org/1059532; transitioning doesn't introduce any new
issues.

A number of packages in sid depend directly on Abseil. To give early
warning of breakages, I've done trial rebuilds as appropriate on the
amd64 porterbox. Packages that work fine with the new version:

  - grpc
  - libgav1
  - libphonenumber
  - mujoco
  - open-vm-tools
  - ycmd

Packages that are broken by the new version:

  - mozc: FTBFS because it depends on a symbol in the absl::internal
namespace that changed without warning

  - re2: FTBFS because it needs changes to some symbols files

  - s2geometry: FTBFS because it hard-codes std=c+11 and the new version
requires -std=c++14 or later (https://bugs.debian.org/1059228)

  - webrtc-audio-processing: FTBFS because it relies on transitive
#includes that have changed

Packages that I'm not sure about:

  - dm-tree: has an active FTBFS (https://bugs.debian.org/1055686)

  - ortools: has an active FTBFS (https://bugs.debian.org/1024790)

  - libreoffice: too big to build on a porterbox, so left untested

Although doing a transition now will break some packages in sid, I
believe waiting is likely to cause more issues. Upstreams (LibreOffice
in particular) are starting to use features from the new version of
Abseil, and keeping the old version in sid is starting to create work
for other DDs. The breakages in sid will have to be fixed eventually
anyway, and none of them should be challenging to repair.

Ben file:

title = "abseil";
is_affected = .depends ~ /\blibabsl20220623\b/ | .depends ~ 
/\blibabsl20230802\b/;
is_good = .depends ~ /\blibabsl20230802\b/;
is_bad = .depends ~ /\blibabsl20220623\b/;

Bug#1059530: mate-desktop: Pyside6 combobox inside a groupbox doesn't render selected option but does whilst window is resizing

[aa bb]

Some more digging into this shows that actually, the selected text IS rendered, but it's white. On a light grey background. Forcing the text to be black by adding a stylesheet is the dirty way of fixing it.

 

I've also added it to qt's bug tracker:

 

https://bugreports.qt.io/browse/PYSIDE-2564

Bug#1057295: bcachefs-tools: breaks "mount" if the package is installed

[Jonathan Carter]

Hi

On 2023/12/02 22:22, Adam Borowski wrote:

A simple workaround would be to just drop the /sbin/mount.bcachefs symlink
until rust pieces are back.  But alas, I see that the helper is needed for


I've now done so, and uploaded it to experimental. At least on my 
system, things seem to work fine after a reboot once this package is 
installed.


-Jonathan

Bug#1059533: DEP17: handle /usr-move for gzip and its diversions by zutils

[Helmut Grohne]

Package: gzip
Version: 1.12-1
User: helm...@debian.org
Usertags: dep17m2
Tags: patch
Control: clone -1 -2
Control: reassign -2 zutils/1.12-3
Control: block -1 by -2

Hi,

as part of DEP17, I am looking into moving aliased files in essential
packages from / to /usr. gzip is one such package. Unfortunately, moving
its files from / to /bin causes breakage. zutils diverts e.g. /bin/zcmp
and once gzip moves that to /usr/bin/zcmp, the diversions issued by
zutils become ineffective (DEP17 P3) causing unintended file overwrites.

Mitigating these has turned out to be non-trival and I think we now have
a good understanding of the edge cases having gone through them with
molly-guard. I propose duplicating diversions (DEP17 M18) here as well.

For gzip the story is relatively simple. It moves all the files, but it
must not be unpacked when there is a version of zutils installed that
hasn't duplicated its diversions yet. The best we can do here is adding
versioned Conflicts (not Breaks). I caution that this is not entirely
bullet-proof. If you `echo zutils deinstall | dpkg --set-selections` and
then `dpkg --unpack new_gzip.deb`, it'll unpack the moved gzip first and
then remove zu old zutils that lacks the duplicated diversions. Even in
this case, the gzip package would continue working after the upgrade.

For zutils, the story is less easy. In order to avoid apt issuing a
temporary removal of zutils (and thus trigger the wrongly ordered
unpacks above), zutils must not issue versioned breaks for gzip and
therefore it must carry the aliased diversions during the trixie cycle
(and not just during the upgrade).

So I've developed these patches (both attached). Since piuparts doesn't
deal well with testing essential packages, I've developed test cases
using mmdebstrap (also attached) and performed the --set-selections test
manually. Everything looks fine, but I keep the fingers crossed.

I ask you to upload these changes to experimental (not unstable). Once
both updates are in experimental, dumat will be able to analyze and
we'll also see what other kinds of QA says. Then once that works for
both packages, we can upload zutils to unstable and then gzip.

Thanks for your cooperation

Helmut
diff -Nru gzip-1.12/debian/changelog gzip-1.12/debian/changelog
--- gzip-1.12/debian/changelog  2022-04-10 04:22:26.0 +0200
+++ gzip-1.12/debian/changelog  2023-12-23 07:46:32.0 +0100
@@ -1,3 +1,10 @@
+gzip (1.12-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move files to /usr (closes: #-1)
+
+ -- Helmut Grohne   Sat, 23 Dec 2023 07:46:32 +0100
+
 gzip (1.12-1) sid; urgency=high
 
   * new upstream release
diff -Nru gzip-1.12/debian/control gzip-1.12/debian/control
--- gzip-1.12/debian/control2022-04-10 04:05:08.0 +0200
+++ gzip-1.12/debian/control2023-12-23 07:27:28.0 +0100
@@ -16,6 +16,7 @@
 Pre-Depends: ${shlibs:Depends}
 Depends: dpkg (>= 1.15.4) | install-info
 Suggests: less
+Conflicts: zutils (<< 1.12-3.1~)
 Description: GNU compression utilities
  This package provides the standard GNU file compression utilities, which
  are also the default compression tools for Debian.  They typically operate
diff -Nru gzip-1.12/debian/rules gzip-1.12/debian/rules
--- gzip-1.12/debian/rules  2022-04-09 04:15:18.0 +0200
+++ gzip-1.12/debian/rules  2023-12-23 07:26:46.0 +0100
@@ -47,7 +47,7 @@
 _topdir=$(call shellescape,$(shell pwd))
 
 CONFIGURE_ARGS=--prefix=/usr \
-   --bindir=/bin \
+   --bindir=/usr/bin \
--infodir=${_topdir}/debian/gzip/usr/share/info \
--mandir=${_topdir}/debian/gzip/usr/share/man \
--disable-silent-rules
diff -Nru zutils-1.12/debian/changelog zutils-1.12/debian/changelog
--- zutils-1.12/debian/changelog2023-06-16 11:37:05.0 +0200
+++ zutils-1.12/debian/changelog2023-12-23 07:46:00.0 +0100
@@ -1,3 +1,10 @@
+zutils (1.12-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * DEP17 M18: Duplicate aliased diversions (Closes: #-1).
+
+ -- Helmut Grohne   Sat, 23 Dec 2023 07:46:00 +0100
+
 zutils (1.12-3) sid; urgency=medium
 
   * Uploading to sid.
diff -Nru zutils-1.12/debian/rules zutils-1.12/debian/rules
--- zutils-1.12/debian/rules2023-06-13 08:08:48.0 +0200
+++ zutils-1.12/debian/rules2023-12-23 07:46:00.0 +0100
@@ -6,7 +6,7 @@
dh ${@}
 
 override_dh_auto_configure:
-   dh_auto_configure -- --exec-prefix=/ CXX=$(CXX)
+   dh_auto_configure -- CXX=$(CXX)
 
 override_dh_auto_install:
dh_auto_install -- DESTDIR=$(CURDIR)/debian/zutils
diff -Nru zutils-1.12/debian/zutils.postrm zutils-1.12/debian/zutils.postrm
--- zutils-1.12/debian/zutils.postrm2023-06-13 08:08:48.0 +0200
+++ zutils-1.12/debian/zutils.postrm2023-12-23 07:45:29.0 +0100
@@ -6,7 +6,8 @@
remove)
for FILE in zcat 

Bug#1059376: [Pkg-pascal-devel] Bug#1059376: Bug#1059376: Bug#1059376: lcl is wrongly marked Multi-Arch: foreign

[Helmut Grohne]

On Tue, Dec 26, 2023 at 10:36:16PM +0100, Abou Al Montacir wrote:
> Please review this patch, and I'll upload it if you find it OK.

Reviewing M-A:same annotations is hard. Would you mind uploading to
unstable (as the multiarch hinter does not look at experimental) and if
it complains about M-A:same reupload with those M-A:same removed?

> diff --git a/debian/control b/debian/control
> index 118454ff..e8e7c0a8 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -232,6 +232,7 @@ Description: Lazarus Components Library - command line 
> build tools
>  
>  Package: lcl-units-3.0
>  Architecture: any
> +Multi-Arch: same

Verify using m-a hinter.

>  Depends: lcl-gtk2-3.0 (= ${binary:Version}) | lcl-qt5-3.0 (= 
> ${binary:Version}),
>   ${fpc-abi:Depends},
>   ${misc:Depends},
> @@ -263,6 +264,7 @@ Description: Lazarus Components Library - backend 
> independent components
>  
>  Package: lcl-nogui-3.0
>  Architecture: any
> +Multi-Arch: same

Verify using m-a hinter.

>  Depends: fp-units-base,
>   fp-units-fcl,
>   fp-units-rtl,
> @@ -298,6 +300,7 @@ Description: Lazarus Components Library - no GUI backend
>  
>  Package: lcl-gtk2-3.0
>  Architecture: any
> +Multi-Arch: same

Verify using m-a hinter.

>  Depends: fp-units-base,
>   fp-units-fcl,
>   fp-units-gtk2,
> @@ -333,6 +336,7 @@ Description: Lazarus Components Library - GTK+ backend
>  
>  Package: lcl-qt5-3.0
>  Architecture: any
> +Multi-Arch: same

Verify using m-a hinter.

>  Depends: fp-units-base,
>   fp-units-fcl,
>   fp-units-rtl,
> @@ -521,8 +525,8 @@ Description: IDE for Free Pascal - Last Qt version 
> dependency package
>   currently just depends on the GTK+ version.
>  
>  Package: lcl
> -Architecture: all
> -Multi-Arch: foreign
> +Architecture: any
> +Multi-Arch: same

The architecture change looks good. Removing M-A:foreign looks good.
Verify M-A:same using the hinter.

>  Depends: lcl-3.0,
>   ${misc:Depends}
>  Description: Lazarus Components Library - LCL dependency package
> @@ -571,7 +575,8 @@ Description: Lazarus Components Library - command line 
> build tools dependency pa
>   applications.
>  
>  Package: lcl-units
> -Architecture: all
> +Architecture: any

Agreed.

> +Multi-Arch: same

Verify using m-a hinter. Not useful unless lcl-units-3.0 is M-A:same.

>  Depends: lcl-units-3.0,
>   ${misc:Depends}
>  Description: Lazarus Components Library - backend independent components 
> dependency package
> @@ -595,7 +600,8 @@ Description: Lazarus Components Library - backend 
> independent components depende
>   the package containing common components.
>  
>  Package: lcl-nogui
> -Architecture: all
> +Architecture: any

Agreed.

> +Multi-Arch: same

Verify using m-a hinter. Not useful unless lcl-nogui-3.0 is M-A:same.

>  Depends: lcl-nogui-3.0,
>   ${misc:Depends}
>  Description: Lazarus Components Library - no GUI backend dependency package
> @@ -620,7 +626,8 @@ Description: Lazarus Components Library - no GUI backend 
> dependency package
>   applications and command line tools.
>  
>  Package: lcl-gtk2
> -Architecture: all
> +Architecture: any

Agreed.

> +Multi-Arch: same

Verify using m-a hinter. Not useful unless lcl-gtk2-3.0 is M-A:same.

>  Depends: lcl-gtk2-3.0,
>   ${misc:Depends}
>  Description: Lazarus Components Library - GTK+ backend dependency package
> @@ -645,7 +652,8 @@ Description: Lazarus Components Library - GTK+ backend 
> dependency package
>   applications.
>  
>  Package: lcl-qt5
> -Architecture: all
> +Architecture: any

Agreed.

> +Multi-Arch: same

Verify using m-a:hinter. Not useful unless lcl-qt5-3.0 is M-A:same.

>  Depends: lcl-qt5-3.0,
>   ${misc:Depends}
>  Description: Lazarus Components Library - Qt backend dependency package
> diff --git a/debian/control.in b/debian/control.in
> index c7bf9c55..f85a8317 100644
> --- a/debian/control.in
> +++ b/debian/control.in

Skip as these are duplicate changes.

Helmut

Bug#1059532: abseil:riscv64: uses privileged rdcycle instruction

[Benjamin Barenblat]

Source: abseil
Version: 20220623.1-1
Severity: normal
Tags: upstream
Control: forwarded -1 https://github.com/abseil/abseil-cpp/pull/1550

On RISC-V, Abseil's cycle counter uses the rdcycle instruction, which is
a privileged instruction when running on Debian's Linux kernels. This
causes some widely used Abseil functions (e.g., certain member functions
on absl::Mutex) to crash with a SIGILL.

Bug#1059531: thunderbird: calendar shows repeating events after end date

[Martin]

Package: thunderbird
Version: 1:115.5.0-1~deb12u1

I see the following event in my calendar:

Title:  redacted
Calendar:   MS Exchange
Start Date: Tue, 2024-01-02 15:00
End Date:   Tue, 2024-01-02 16:30
Repeat: 	Occurs every 2 weeks effective 2022-02-01 until 2023-12-05  
from 15:00 to 16:30.


This should not be possible, right?

Bug#1039990: [Pkg-javascript-devel] Bug#1039990: nodejs: CVE-2023-30581 CVE-2023-30588 CVE-2023-30589 CVE-2023-30590

[Moritz Mühlenhoff]

Am Wed, Dec 27, 2023 at 05:18:52PM +0100 schrieb Jérémy Lal:
> Le mer. 27 déc. 2023 à 17:16, Moritz Mühlenhoff  a écrit :
> 
> > [ Also adding Paul Gevers for awareness, for context we're bumping nodejs
> >   in Bookworm to the latest 18.x security/LTS release ]
> >
> > On Wed, Dec 27, 2023 at 03:03:20PM +0100 Jérémy Lal wrote:
> >
> > > I don't think so, there are all either node-undici-related, or just test
> > > suites regressions.
> > > Here are the details:
> > >
> > > node-zx is a regression in the test suite only, fixed there:
> > >
> > https://salsa.debian.org/js-team/node-zx/-/commit/a7d2861413480261890db147ea367a252192c9f2
> > >
> > > node-yaml is caused by missing node-undici
> > >
> > > node-v8-compile-cache is a regression in the test suite only, fixed
> > there:
> > >
> > https://salsa.debian.org/js-team/node-v8-compile-cache/-/commit/df42bdbfe84811e4da11d8c3d8ef3148d8a77bcc
> > >
> > > node-babel7 is a regression in the test suite, fixed there:
> > >
> > https://salsa.debian.org/js-team/node-babel/-/commit/e5c88f4d765e4d64b60c9cf333dedb89abba39c5
> > >
> > > node-re2 is caused by missing node-undici
> >
> > Great, thanks for the detailed analysis!
> >
> > This means the update to .19 will regress autopkgtests for node-zx,
> > node-v8-compile-cache
> > and node-babel7, but since these are all only test suite regressions, we
> > can just go
> > ahead and fix the tests in a subsequent bookworm point update, ok?
> >
> 
> Ok, so I suppose js-team would need to upload those three packages to t-p-u

Indeed: Not testing-proposed-updates (which is only for the testing 
distribution), but
instead for stable-proposed-updates, which is a very similar process:
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#special-case-uploads-to-the-stable-and-oldstable-distributions

Cheers,
Moritz

Bug#1059530: mate-desktop: Pyside6 combobox inside a groupbox doesn't render selected option but does whilst window is resizing

[Peter Thompson]

Package: mate-desktop
Version: 1.26.2-1
Severity: important
X-Debbugs-Cc: theoneando...@gmx.us

Dear Maintainer,

Creating Qt GUI in python for a project and discovered the problem. 

Minimum python code below. I've tested in KDE and it works as expected.

Python 3.11

```
from PySide6.QtWidgets import QApplication, QFrame, QGroupBox, QComboBox, 
QWidget, QVBoxLayout
import sys

class MyWidget(QWidget):
def __init__(self):
super().__init__()

groupbox = QGroupBox(self)
groupbox_layout = QVBoxLayout(groupbox)

combo = QComboBox(groupbox)
combo.addItems(["Option 1", "Option 2", "Option 3"])
groupbox_layout.addWidget(combo)

layout = QVBoxLayout(self)
layout.addWidget(groupbox)

app = QApplication(sys.argv)
window = MyWidget()
window.show()
sys.exit(app.exec())
```

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

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

Versions of packages mate-desktop depends on:
ii  hicolor-icon-theme0.17-2
ii  libc6 2.37-13
ii  libglib2.0-0  2.78.3-1
ii  libgtk-3-03.24.39-1
ii  libmate-desktop-2-17  1.26.2-1
ii  mate-desktop-common   1.26.2-1

Versions of packages mate-desktop recommends:
ii  mate-user-guide  1.26.2-1

Versions of packages mate-desktop suggests:
ii  mate-desktop-environment  1.26.0+1

-- no debconf information

Bug#1059393: [trivia: Re: ABACuS arXiv.2310.09977]

[Boud Roukema]

On Tue, 26 Dec 2023, Boud Roukema wrote:


PS: Conspiracy theory (numerology): this bug number is 105000 +
101*93, while the ArXiv ID after YYMM is 101*97. Common to
both is 101*p where p is a prime and p < 100 . ;)


Correction: 101*93 = 9393, but 11*907 = 9977. So much for the conspiracy ;).
Boud

Bug#1039990: [Pkg-javascript-devel] Bug#1039990: nodejs: CVE-2023-30581 CVE-2023-30588 CVE-2023-30589 CVE-2023-30590

[Jérémy Lal]

Le mer. 27 déc. 2023 à 17:16, Moritz Mühlenhoff  a écrit :

> [ Also adding Paul Gevers for awareness, for context we're bumping nodejs
>   in Bookworm to the latest 18.x security/LTS release ]
>
> On Wed, Dec 27, 2023 at 03:03:20PM +0100 Jérémy Lal wrote:
>
> > I don't think so, there are all either node-undici-related, or just test
> > suites regressions.
> > Here are the details:
> >
> > node-zx is a regression in the test suite only, fixed there:
> >
> https://salsa.debian.org/js-team/node-zx/-/commit/a7d2861413480261890db147ea367a252192c9f2
> >
> > node-yaml is caused by missing node-undici
> >
> > node-v8-compile-cache is a regression in the test suite only, fixed
> there:
> >
> https://salsa.debian.org/js-team/node-v8-compile-cache/-/commit/df42bdbfe84811e4da11d8c3d8ef3148d8a77bcc
> >
> > node-babel7 is a regression in the test suite, fixed there:
> >
> https://salsa.debian.org/js-team/node-babel/-/commit/e5c88f4d765e4d64b60c9cf333dedb89abba39c5
> >
> > node-re2 is caused by missing node-undici
>
> Great, thanks for the detailed analysis!
>
> This means the update to .19 will regress autopkgtests for node-zx,
> node-v8-compile-cache
> and node-babel7, but since these are all only test suite regressions, we
> can just go
> ahead and fix the tests in a subsequent bookworm point update, ok?
>

Ok, so I suppose js-team would need to upload those three packages to t-p-u
?

Bug#1039990: [Pkg-javascript-devel] Bug#1039990: nodejs: CVE-2023-30581 CVE-2023-30588 CVE-2023-30589 CVE-2023-30590

[Moritz Mühlenhoff]

[ Also adding Paul Gevers for awareness, for context we're bumping nodejs
  in Bookworm to the latest 18.x security/LTS release ]

On Wed, Dec 27, 2023 at 03:03:20PM +0100 Jérémy Lal wrote:

> I don't think so, there are all either node-undici-related, or just test
> suites regressions.
> Here are the details:
> 
> node-zx is a regression in the test suite only, fixed there:
> https://salsa.debian.org/js-team/node-zx/-/commit/a7d2861413480261890db147ea367a252192c9f2
> 
> node-yaml is caused by missing node-undici
> 
> node-v8-compile-cache is a regression in the test suite only, fixed there:
> https://salsa.debian.org/js-team/node-v8-compile-cache/-/commit/df42bdbfe84811e4da11d8c3d8ef3148d8a77bcc
> 
> node-babel7 is a regression in the test suite, fixed there:
> https://salsa.debian.org/js-team/node-babel/-/commit/e5c88f4d765e4d64b60c9cf333dedb89abba39c5
> 
> node-re2 is caused by missing node-undici

Great, thanks for the detailed analysis!

This means the update to .19 will regress autopkgtests for node-zx, 
node-v8-compile-cache
and node-babel7, but since these are all only test suite regressions, we can 
just go
ahead and fix the tests in a subsequent bookworm point update, ok?

Cheers,
Moritz

Bug#1059520: opendkim: Crashes when postfix accesses opendkim.sock

[David Bürgin]

Hello Markus,

> i just got this:
> Dec 27 15:14:01 mitschnet-neu opendkim[77553]: E9121540408: DKIM
> verification successful
> Dec 27 15:14:01 mitschnet-neu opendkim[77553]: E9121540408: s=20230601
> d=gmail.com a=rsa-sha256 SSL
> 
> when receiving an email.

Good, this means that communication with the milter is fine. Next would
be checking if signing table and signing keys are set up correctly.

Note that signing with opendkim is generally working well, so this is
likely a problem with *your* setup and configuration.

Ciao,
David

Bug#1059520: Fwd: Bug#1059520: opendkim: Crashes when postfix accesses opendkim.sock

[David Bürgin]

 Forwarded Message 
Subject: Re: Bug#1059520: opendkim: Crashes when postfix accesses opendkim.sock
Date: Wed, 27 Dec 2023 16:44:16 +0100
From: Markus Mitsch 
To: David Bürgin 

Hi David,
The output of:

---> ls -al /var/run/opendkim
drwxr-x---  2 opendkim opendkim  80 Dec 27 15:37 .
drwxr-xr-x 24 root root 700 Dec 27 15:17 ..
-rw-r--r--  1 root root   6 Dec 27 15:37 opendkim.pid
srwxrwx---  1 opendkim opendkim   0 Dec 27 15:37 opendkim.sock


---> groups postfix | grep opendkim
postfix : postfix mail opendkim


---> postconf | grep smtpd_milters
non_smtpd_milters = $smtpd_milters
smtpd_milters = unix:/run/opendkim/opendkim.sock
-

postfix does not run chrooted.

i just got this:
Dec 27 15:14:01 mitschnet-neu opendkim[77553]: E9121540408: DKIM
verification successful
Dec 27 15:14:01 mitschnet-neu opendkim[77553]: E9121540408: s=20230601
d=gmail.com a=rsa-sha256 SSL

when receiving an email.

Greetings
Markus

Bug#1059529: pybuild-autopkgtest: before-pybuild-autopkgtest target presence breaks autopkgtest

[Julian Gilbey]

Package: dh-python
Version: 6.20231223
Severity: normal

I have a package where I used a before-pybuild-autopkgtest in the
debian/rules file, but when I run autopkgtest, it fails with the error
message (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059334):

dh before-pybuild-autopkgtest --buildsystem=pybuild
dh: error: Unknown sequence before-pybuild-autopkgtest (choose from: binary 
binary-arch binary-indep build build-arch build-indep clean install 
install-arch install-indep)
make: *** [debian/rules:13: before-pybuild-autopkgtest] Error 25
pybuild-autopkgtest: error: /tmp/pJ8OcCInAE/run before-pybuild-autopkgtest 
returned exit code 2

That's clearly wrong!  It appears that that "%:" recipe overrides
every other recipe in debian/rules, and is called when "debian/rules
before-pybuild-autopkgtest" is called.  I don't know if there's any
way to override this behaviour.

Best wishes,

   Julian

Bug#1058863: libqwt-qt5-dev: invalid conversion from ‘int’ to ‘QwtPlotLayout::Option’

[Yadd]

Hi Gudjon,

yes I'm trying to build ovito. you can find my temporary repository on 
g...@salsa.debian.org:yadd/ovito.git


Best regards,
Yadd

Bug#1059528: french translation sudo ldap go away

[bubub]

Package: sudo
Version: 1.9.15p3-1
Severity: whishlist
Tags: patch l10n

Dear mainteners,
Hello, please find the updated french translation for sudo-ldap attached,
proofread by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind regards,
have a nice day,

bubu

fr.po.xz
Description: application/xz

Bug#1059527: dpkg: [INTL:sv] Update Swedish translation ("main" branch)

[Peter Krefting]

Package: dpkg
Severity: wishlist
Tags: l10n patch

Updated PO files for the main branch (as of 
f1f96f483deb071aa49dfce92c918154d287bf42; i.e version 1.22.2) can be 
downloaded here:


https://raw.githubusercontent.com/nafmo/dpkg-l10n-sv/1b76c07c4620de4548402bc249c523580f28b2fb/man/po/sv.po
https://raw.githubusercontent.com/nafmo/dpkg-l10n-sv/1b76c07c4620de4548402bc249c523580f28b2fb/po/sv.po
https://raw.githubusercontent.com/nafmo/dpkg-l10n-sv/1b76c07c4620de4548402bc249c523580f28b2fb/scripts/po/sv.po
(no changes to dselect/po/sv.po)

or by pulling commit 1b76c07c4620de4548402bc249c523580f28b2fb ("main") 
from https://github.com/nafmo/dpkg-l10n-sv.git





--
\\// Peter - http://www.softwolves.pp.se/

Bug#1059520: opendkim: Crashes when postfix accesses opendkim.sock

[David Bürgin]

What’s the output of:

ls -al /var/run/opendkim
groups postfix | grep opendkim
postconf | grep smtpd_milters

Is postfix running in a chroot? See master.cf.


Here are settings that work:

/etc/opendkim.conf:

UserID  opendkim
UMask   0117
Socket  local:/var/spool/postfix/opendkim/opendkim.sock
PidFile /run/opendkim/opendkim.pid


$ sudo ls -al /var/spool/postfix/opendkim
total 4
drwxr-x---  2 opendkim opendkim   27 Dec  9 19:52 .
drwxr-xr-x 26 root root 4096 May 24  2023 ..
srw-rw  1 opendkim opendkim0 Dec  9 19:52 opendkim.sock

$ groups postfix | grep opendkim
postfix : postfix opendkim […]

$ postconf | grep smtpd_milters
non_smtpd_milters = $smtpd_milters
smtpd_milters = […] unix:opendkim/opendkim.sock […]


Do follow a sensible tutorial such as:
https://wiki.debian.org/opendkim

The segmentation fault is surprising to me, though. It may also indicate
that you have a really unusual system that no one else has.

Bug#1059526: kde-plasma-desktop: Cursor flickers in Present Windows with Firefox Flatpak running

[Reece]

Package: kde-plasma-desktop
Version: 5:142
Severity: minor
X-Debbugs-Cc: reecebugreports.scrubbed...@aleeas.com

Dear Maintainer,

   * What led up to the situation?

   Using Present Windows with Firefox Flatpak running and not playing a video.

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

   Presenting all windows while Firefox Flatpak is running while showing a 
static image

   * What was the outcome of this action?

   The cursor starts to flicker

   * What outcome did you expect instead?

   The cursor doesn't flicker

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

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

Versions of packages kde-plasma-desktop depends on:
ii  kde-baseapps  4:22.12.3+5.142
ii  plasma-desktop4:5.27.5-2
ii  plasma-workspace  4:5.27.5-2+deb12u1
ii  udisks2   2.9.4-4
ii  upower0.99.20-2

Versions of packages kde-plasma-desktop recommends:
ii  kwin-x11  4:5.27.5-3
ii  sddm  0.19.0-5
ii  xserver-xorg  1:7.7+23

Versions of packages kde-plasma-desktop suggests:
ii  kdeconnect  22.12.3-1

-- no debconf information

Bug#1059525: linux-image-6.1.0-16-amd64: Secure Boot is active but mokutil and dmesg says "Secure boot disabled" but just with an NVME not with an HDD/SSD

[.]

Package: src:linux
Version: 6.1.67-1
Severity: serious
X-Debbugs-Cc: yelcnce01w76dbotr...@gmail.com

Dear Maintainer,

* What led up to the situation?
I started Debian 12 on an Intel NUC with Crucial P5 Plus NVME and 
noticed that Secure Boot is not active, only if an NVME is installed.
When the NVME is fitted, the Debian Live Stick also changes the secure 
boot state to disabled. This does not happen with Debian if the NVME is 
removed and only one HDD is used. In Bios Secure Boot is enabled.


With NVME and active Secure Boot, Kernel starts properly
dmesg | grep -i secure
[0.00] secureboot: Secure boot disabled
[1.294078] Loaded X.509 cert 'Debian Secure Boot CA: 
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[1.294088] Loaded X.509 cert 'Debian Secure Boot Signer 2022 - 
linux: 14011249c2675ea8e5148542202005810584b25f'

mokutil --sb-state
This system doesn't support Secure Boot

With NVME and active Secure Boot and Mainboard Lockdown-Pins
dmesg | grep -i secure
[0.00] Kernel is locked down from EFI Secure Boot; see man 
kernel_lockdown.7

[0.00] secureboot: Secure boot enabled
[1.287502] Loaded X.509 cert 'Debian Secure Boot CA: 
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[1.287513] Loaded X.509 cert 'Debian Secure Boot Signer 2022 - 
linux: 14011249c2675ea8e5148542202005810584b25f'
[1.295587] integrity: Loaded X.509 cert 'Debian Secure Boot CA: 
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'

mokutil --sb-state
SecureBoot enabled

* What exactly did you do (or not do) that was effective (or
ineffective)?
The behavior changes when I set the lockdown-pins on the mainboard from 
the Intel NUC. Then Secure Boot is activ with these NVME.


* What was the outcome of this action?
* What outcome did you expect instead?
Secure Boot should always be active and if not, Debian should not start.



-- Package-specific info:
** Version:
Linux version 6.1.0-16-amd64 (debian-ker...@lists.debian.org) (gcc-12 
(Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.67-1 (2023-12-12)


** Command line:
BOOT_IMAGE=/vmlinuz-6.1.0-16-amd64 root=/dev/mapper/lvgdeb-debix ro 
rootflags=subvol=@rootfs quiet


** Not tainted

** Kernel log:
[   13.280197] BTRFS info: devid 1 device path /dev/mapper/lvgdeb-debix 
changed to /dev/dm-1 scanned by (udev-worker) (590)
[   13.280714] BTRFS info: devid 1 device path /dev/dm-1 changed to 
/dev/mapper/lvgdeb-debix scanned by (udev-worker) (590)

[   13.298823] intel_pmc_core INT33A1:00:  initialized
[   13.317186] resource sanity check: requesting [mem 
0xfedc-0xfedc], which spans more than pnp 00:03 [mem 
0xfedc-0xfedc7fff]
[   13.317191] caller igen6_probe+0x199/0x7d0 [igen6_edac] mapping 
multiple BARs
[   13.321118] EDAC MC0: Giving out device to module igen6_edac 
controller Intel_client_SoC MC#0: DEV :00:00.0 (INTERRUPT)
[   13.321700] Serial bus multi instantiate pseudo device driver 
INT3515:00: error -ENXIO: IRQ index 1 not found
[   13.321729] Serial bus multi instantiate pseudo device driver 
INT3515:00: error -ENXIO: Error requesting irq at index 1
[   13.324335] EDAC MC1: Giving out device to module igen6_edac 
controller Intel_client_SoC MC#1: DEV :00:00.0 (INTERRUPT)

[   13.324397] EDAC igen6 MC1: HANDLING IBECC MEMORY ERROR
[   13.324399] EDAC igen6 MC1: ADDR 0x7fffe0
[   13.324400] EDAC igen6 MC0: HANDLING IBECC MEMORY ERROR
[   13.324401] EDAC igen6 MC0: ADDR 0x7fffe0
[   13.325163] EDAC igen6: v2.5.1
[   13.389497] ee1004 0-0050: 512 byte EE1004-compliant SPD EEPROM, 
read-only

[   13.412053] mei_me :00:16.0: enabling device ( -> 0002)
[   13.422361] cfg80211: Loading compiled-in X.509 certificates for 
regulatory database
[   13.422472] cfg80211: Loaded X.509 cert 'b...@debian.org: 
577e021cb980e0e820821ba7b54b4961b8b4fadf'
[   13.422560] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 
3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'

[   13.422646] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[   13.423298] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db
[   13.423325] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db.p7s

[   13.424187] input: PC Speaker as /devices/platform/pcspkr/input/input8
[   13.522204] mei_hdcp 
:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound :00:02.0 
(ops i915_hdcp_component_ops [i915])
[   13.522505] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 
655360 ms ovfl timer

[   13.522510] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[   13.522513] RAPL PMU: hw unit of domain package 2^-14 Joules
[   13.522514] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[   13.522515] RAPL PMU: hw unit of domain psys 2^-14 Joules
[   13.530500] Intel(R) Wireless WiFi driver for Linux
[   13.530763] iwlwifi :00:14.3: enabling device ( -> 0002)
[   13.547682] iwlwifi :00:14.3: firmware: direct-loading firmware 
iwlwifi-so-a0-gf-a0-72.ucode
[   

Bug#1059524: bookworm-pu: package mate-screensaver/1.26.1-1+deb12u1

[Mike Gabriel]

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

Two memory leaks were resolved upstream and cherry-picked into this
bookworm-pu.

[ Reason ]
In mate-screensaver's preferences tool two memory leaks were discovered
and resolved by upstream.

[ Impact ]
Memleaks persist for mate-screensaver in bookworm if this upload gets rejected.

[ Tests ]
Manual smoke test.

[ Risks ]
Possible regression. Users of mate-screensaver will be affected.

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

[ Changes ]

+  * debian/patches:
++ Add 0001_mate-screensaver-preferences-fix-memory-leak.patch and
+  0002_mate-screensaver-preferences-fix-memory-leak.patch, fixing two
+  memleaks in the preferences tool of mate-screensaver.

[ Other info ]
None.
diff -Nru mate-screensaver-1.26.1/debian/changelog 
mate-screensaver-1.26.1/debian/changelog
--- mate-screensaver-1.26.1/debian/changelog2021-12-14 07:45:02.0 
+0100
+++ mate-screensaver-1.26.1/debian/changelog2023-12-27 15:32:39.0 
+0100
@@ -1,3 +1,12 @@
+mate-screensaver (1.26.1-1+deb12u1) bookworm; urgency=medium
+
+  * debian/patches:
++ Add 0001_mate-screensaver-preferences-fix-memory-leak.patch and
+  0002_mate-screensaver-preferences-fix-memory-leak.patch, fixing two
+  memleaks in the preferences tool of mate-screensaver.
+
+ -- Mike Gabriel   Wed, 27 Dec 2023 15:32:39 +0100
+
 mate-screensaver (1.26.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
mate-screensaver-1.26.1/debian/patches/0001_mate-screensaver-preferences-fix-memory-leak.patch
 
mate-screensaver-1.26.1/debian/patches/0001_mate-screensaver-preferences-fix-memory-leak.patch
--- 
mate-screensaver-1.26.1/debian/patches/0001_mate-screensaver-preferences-fix-memory-leak.patch
  1970-01-01 01:00:00.0 +0100
+++ 
mate-screensaver-1.26.1/debian/patches/0001_mate-screensaver-preferences-fix-memory-leak.patch
  2023-12-27 15:30:26.0 +0100
@@ -0,0 +1,198 @@
+From 8c12ca79d237a36e7d41a644b24c0753cafc968c Mon Sep 17 00:00:00 2001
+From: rbuj 
+Date: Fri, 22 Oct 2021 17:24:56 +0200
+Subject: [PATCH 1/2] mate-screensaver-preferences: fix memory leak
+
+Signed-off-by: Mike Gabriel 
+---
+ src/mate-screensaver-preferences.c | 125 +++--
+ 1 file changed, 64 insertions(+), 61 deletions(-)
+
+diff --git a/src/mate-screensaver-preferences.c 
b/src/mate-screensaver-preferences.c
+index 3c7621a..46e780e 100644
+--- a/src/mate-screensaver-preferences.c
 b/src/mate-screensaver-preferences.c
+@@ -934,10 +934,14 @@ drag_data_received_cb (GtkWidget*widget,
+ static char *
+ time_to_string_text (long time)
+ {
+-  char *secs, *mins, *hours, *string;
+-  int   sec, min, hour;
+-
+-  int n, inc_len, len_minutes;
++  char  *secs, *mins, *hours, *string;
++  char  *chk_hour_str, *chk_minute_str, *chk_hour_minute_str;
++  char  *chk_ascii_str;
++  intsec, min, hour;
++  size_t chk_ascii_len;
++  intlen_minutes;
++  intn, inc_len;
++  intdiff;
+ 
+   sec = time % 60;
+   time = time - sec;
+@@ -954,60 +958,63 @@ time_to_string_text (long time)
+   secs = g_strdup_printf (ngettext ("%d second",
+ "%d seconds", sec), sec);
+ 
+-  inc_len = strlen (g_strdup_printf (_("%s %s"),
+-g_strdup_printf (ngettext ("%d hour",
+-   "%d hours", 1), 1),
+-g_strdup_printf (ngettext ("%d minute",
+-   "%d minutes", 59), 59))) - 
1;
++  /* inc_len = it's the lenght of the string "1 hour 59 minutes" */
++  chk_hour_str = g_strdup_printf (ngettext ("%d hour",
++"%d hours", 1), 1);
++  chk_minute_str = g_strdup_printf (ngettext ("%d minute",
++  "%d minutes", 59), 59);
++  chk_hour_minute_str = g_strdup_printf (_("%s %s"),
++ chk_hour_str, chk_minute_str);
++  inc_len = strlen (chk_hour_minute_str) - 1;
++  g_free (chk_hour_str);
++  g_free (chk_minute_str);
++  g_free (chk_hour_minute_str);
+ 
+   len_minutes = 0;
+-
+   for (n = 2; n < 60; n++)
+   {
+-  if (n < 10)
+-  {
+-  if ((strlen (g_str_to_ascii (g_strdup_printf (ngettext 
("%d minute",
+-  
"%d minutes", n), n), NULL)) - 2) > len_minutes)
++  char   *minute_str= g_strdup_printf 

Bug#1059523: RFS: streamlink/6.5.0-1~bpo12+1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

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

Dear mentors,

I am looking for a sponsor for my package "streamlink" into Debian
bookworm-backports repository.

  * Package name: streamlink
Version : 6.5.0-1~bpo12+1
Upstream Author : Streamlink Team
  * URL : https://streamlink.github.io/
  * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
  * Vcs : https://salsa.debian.org/amurzeau/streamlink/
Section : python

It builds those binary packages:

  python3-streamlink - Python module for extracting video streams from
various websites
  streamlink - CLI for extracting video streams from various websites
to a video player


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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_6.5.0-1~bpo12+1.dsc



Differences from testing package (6.4.2-1~bpo12+1):
  * d/control,rules: remove doc package because of missing dependencies
on bookworm.


Changes since the previous backported version in bookworm:
streamlink (6.5.0-1~bpo12+1) bookworm-backports; urgency=medium

  * Rebuild for bookworm-backports.

 -- Alexis Murzeau   Wed, 27 Dec 2023 14:57:17 +0100

streamlink (6.5.0-1) unstable; urgency=medium

  * New upstream version 6.5.0

 -- Alexis Murzeau   Tue, 19 Dec 2023 23:18:39 +0100

Regards,

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|


OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1039990: [Pkg-javascript-devel] Bug#1039990: nodejs: CVE-2023-30581 CVE-2023-30588 CVE-2023-30589 CVE-2023-30590

[Jérémy Lal]

Le mer. 27 déc. 2023 à 14:43, Moritz Mühlenhoff  a écrit :

> Am Thu, Dec 21, 2023 at 11:26:27PM +0100 schrieb Jérémy Lal:
> > Le jeu. 21 déc. 2023 à 20:34, Moritz Mühlenhoff  a
> écrit :
> >
> > > Am Thu, Dec 21, 2023 at 11:29:12AM +0100 schrieb Jérémy Lal:
> > > > Le jeu. 21 déc. 2023 à 10:54, Moritz Muehlenhoff  a
> > > écrit :
> > > >
> > > > > On Thu, Dec 21, 2023 at 06:43:35AM +0100, Salvatore Bonaccorso
> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > [CC'ing node-undici uploader]
> > > > >
> > > >
> > > > [CC-ing the good email address for node-undici uploader]
> > > >
> > > > Attached is a debdiff for a node-undici update (which backports what
> has
> > > > been done in testing).
> > >
> > > Looks good to me, please build with -sa (since it's the first upload
> > > to bookworm-security) and upload to security-master.
> > >
> >
> > Note that nodejs 18.19.0 doesn't need this node-undici version to be
> built,
> > only typescript consumers need it (when rebuilding packages in bookworm,
> > or when simply using a typescript compiler in bookworm).
>
> I checked the autopkgtest results for 18.19 on bookworm (it's running
> on security-master and isn't public at this point) and there are
> five packages marked as regressing, for which I'm attaching the logs.
>
> Two have explicit references to the node-undici (but since the new
> node-undici isn't installed into the archive yet, these will only
> recover when it's out).
>
> Could you please do a quick pass over these if the other three are also
> related or whether we potentially also need to update other packages
> in bookworm?


I don't think so, there are all either node-undici-related, or just test
suites regressions.
Here are the details:

node-zx is a regression in the test suite only, fixed there:
https://salsa.debian.org/js-team/node-zx/-/commit/a7d2861413480261890db147ea367a252192c9f2

node-yaml is caused by missing node-undici

node-v8-compile-cache is a regression in the test suite only, fixed there:
https://salsa.debian.org/js-team/node-v8-compile-cache/-/commit/df42bdbfe84811e4da11d8c3d8ef3148d8a77bcc

node-babel7 is a regression in the test suite, fixed there:
https://salsa.debian.org/js-team/node-babel/-/commit/e5c88f4d765e4d64b60c9cf333dedb89abba39c5

node-re2 is caused by missing node-undici

Jérémy

Bug#1059522: bookworm-pu: package caja/1.26.1-1+deb12u1

[Mike Gabriel]

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

Two issue fixes have been cherry-picked from upstream to resolve caja
bugs in Debian bookworm. (The fixed bugs have not been filed against
Debian BTS, though).

[ Reason ]
(a) Graphical rendering glitches could be observed when using MATE in
remote sessions and the session window getting resized. This behaviour
also occurs on resolution changes.
(b) Wrong informal date string calculation could be observed when the
informal date format is in use.

[ Impact ]
Rejection will not be critical to end users. More a nice to have fix-up.

[ Tests ]
Manual tests.

[ Risks ]
To MATE desktop users and other caja users, in case this introduces a
regression.

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

[ Changes ]

+  * debian/patches:
++ Add 0001_caja-desktop-window-Fix-the-xrandr-error.patch and
+  0002_Replace-deprecated-code-from-xrandr-fix.patch. Fix desktop
+  (background) rendering artifacts after resolution changes (or
+  window resizings when MATE runs in a remote session).
++ Add 0003_caja-file-fix-yesterday-today-informal-date-bug.patch and
+  0004_caja-file-fix-future-informal-date-bug.patch. Fix usage of the
+  informal date format.

[ Other info ]
None.
diff -Nru caja-1.26.1/debian/changelog caja-1.26.1/debian/changelog
--- caja-1.26.1/debian/changelog2022-07-23 23:32:12.0 +0200
+++ caja-1.26.1/debian/changelog2023-12-27 14:44:09.0 +0100
@@ -1,3 +1,16 @@
+caja (1.26.1-1+deb12u1) bookworm; urgency=medium
+
+  * debian/patches:
++ Add 0001_caja-desktop-window-Fix-the-xrandr-error.patch and
+  0002_Replace-deprecated-code-from-xrandr-fix.patch. Fix desktop
+  (background) rendering artifacts after resolution changes (or
+  window resizings when MATE runs in a remote session).
++ Add 0003_caja-file-fix-yesterday-today-informal-date-bug.patch and
+  0004_caja-file-fix-future-informal-date-bug.patch. Fix usage of the
+  informal date format.
+
+ -- Mike Gabriel   Wed, 27 Dec 2023 14:44:09 +0100
+
 caja (1.26.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
caja-1.26.1/debian/patches/0001_caja-desktop-window-Fix-the-xrandr-error.patch 
caja-1.26.1/debian/patches/0001_caja-desktop-window-Fix-the-xrandr-error.patch
--- 
caja-1.26.1/debian/patches/0001_caja-desktop-window-Fix-the-xrandr-error.patch  
1970-01-01 01:00:00.0 +0100
+++ 
caja-1.26.1/debian/patches/0001_caja-desktop-window-Fix-the-xrandr-error.patch  
2023-12-27 13:50:53.0 +0100
@@ -0,0 +1,34 @@
+From e98fd06346d621d84ea1df97b018f204a9a7e641 Mon Sep 17 00:00:00 2001
+From: yangxiaojuan 
+Date: Tue, 27 Jun 2023 15:56:18 +0800
+Subject: [PATCH 1/4] caja-desktop-window: Fix the xrandr error
+
+fix https://github.com/mate-desktop/caja/issues/1096
+
+Signed-off-by: Mike Gabriel 
+---
+ src/caja-desktop-window.c | 7 ++-
+ 1 file changed, 2 insertions(+), 5 deletions(-)
+
+diff --git a/src/caja-desktop-window.c b/src/caja-desktop-window.c
+index 061b11b7..bb31b2c6 100644
+--- a/src/caja-desktop-window.c
 b/src/caja-desktop-window.c
+@@ -155,12 +155,9 @@ caja_desktop_window_screen_size_changed (GdkScreen
 *screen,
+ CajaDesktopWindow *window)
+ {
+ int width_request, height_request;
+-int scale;
+-
+-scale = gdk_window_get_scale_factor (gdk_screen_get_root_window (screen));
+ 
+-width_request = WidthOfScreen (gdk_x11_screen_get_xscreen (screen)) / 
scale;
+-height_request = HeightOfScreen (gdk_x11_screen_get_xscreen (screen)) / 
scale;
++width_request = gdk_screen_get_width(screen);
++height_request = gdk_screen_get_height(screen);
+ 
+ g_object_set (window,
+   "width_request", width_request,
+-- 
+2.39.2
+
diff -Nru 
caja-1.26.1/debian/patches/0002_Replace-deprecated-code-from-xrandr-fix.patch 
caja-1.26.1/debian/patches/0002_Replace-deprecated-code-from-xrandr-fix.patch
--- 
caja-1.26.1/debian/patches/0002_Replace-deprecated-code-from-xrandr-fix.patch   
1970-01-01 01:00:00.0 +0100
+++ 
caja-1.26.1/debian/patches/0002_Replace-deprecated-code-from-xrandr-fix.patch   
2023-12-27 13:47:09.0 +0100
@@ -0,0 +1,32 @@
+From aa80005f4f2f0fe3cfbc2517213167397c1a1ce0 Mon Sep 17 00:00:00 2001
+From: lukefromdc 
+Date: Thu, 29 Jun 2023 08:05:44 -0400
+Subject: [PATCH 2/4] Replace deprecated code from xrandr fix
+
+*In x11 we can anchor the desktop size to the root window
+instead of the screen or (possibly multiple)monitors
+
+Signed-off-by: Mike Gabriel 
+---
+ src/caja-desktop-window.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git 

Bug#1059521: ITP: rust-pikchr -- PIC-like diagramming language to SVG converter

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-pikchr
  Version : 0.1.3
  Upstream Contact: Daniel Silverstone 
* URL : https://github.com/kinnison/pikchr
* License : Apache-2.0 or Expat
  Programming Lang: Rust and C
  Description : PIC-like diagramming language to SVG converter

 Pikchr (pronounced "picture") is a PIC-like markup language
 for diagrams in technical documentation.
 Pikchr is designed to be embedded in fenced code blocks of Markdown
 or similar mechanisms of other documentation markup languages.

This package will be maintained in the collaborative debian section of
Salsa, at https://salsa.debian.org/debian/rust-pikchr

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmWMK6cACgkQLHwxRsGg
ASFeBA//bcFWS7kwUJXjVM6FgPmF6PCAFwFp+S03F2zH/b/GuynbvG1hyptVsV1e
DokQYTG9jMPTrEy0UVw2popVegodkVHzPAXQZdy1TRR3r3wvpO0ezhikcTwbobpX
lXMN0tAbfOTFdTQYi3aqYsmJA+9yCX6KmM2RSLdeR89javonW05T9SfzQSEUtKeX
vDLtBA9JyICe/ox8Ymq/S7Zj6m8hoEK81ZsrBu2+x7O7lnI3g9X7/le7JxN2SyAr
njunNioSq8bEHmGD8pMNbGadei+N2Eq8AyxinsZTbGF3Goc6eaz1ePfiNHeBST4v
/hDfgc5n+xXegZfxfuR/q8e2jHd52RyVC0bsEOZ13W8eSMhCCyhF3AuTBI/3YUWW
yoXyrBez3d+Wf/G3FU5kXCfPTF5pmoCKVq7dr90nWsyFp4zH5HlFHyOVAw31oef1
oxZu+81AS9ch6NtKJycxyQE3+ZiFiJ8dcALcZWAM1noMV5pYEeN1ciJFnAmMlCeB
UfcFhdJYJI+/82+fWkBQMwPYkSPn1bhNX7aAabGs++CJkBcU9AeNQ/nv7AJ4xrCE
nWiC1tWAmOmzTmEC5CJZzrkm3u5+4Syjp4Q5FwivEzRq6X9DpuXs4xOgCizfYz1o
Zuy/0pKdDR5p4MhHFVtm3ahIIwQmdmhxXEFesMJUZQse+S3MjaM=
=9MTY
-END PGP SIGNATURE-

Bug#1059395: libacl1, debhelper: changelog not detected as binNMU

[Gioele Barabucci]

Control: tags -1 - moreinfo
Control: tags -1 + patch
Control: retitle -1 debhelper: binNMU changelog not created w/ --no-trim

On 26/12/23 13:19, Sven Joachim wrote:

On 2023-12-26 12:34 +0100, Gioele Barabucci wrote:

This binNMU changelog entry would normally be separated into
changelog.Debian.${DEB_HOST_ARCH}.gz, as can be seen in
/usr/share/doc/libxext6/ at the time of writing.


dh_installchangelogs still has the same behavior as before when it
comes to binNMU and their arch-specific changelogs, independent of the
trimming logic.


That is not the case, AFAICS.  This is what you installed in commit
af652db00:


Thanks Sven for the analysis, you're right.

A fix for this issue is available at 
https://salsa.debian.org/debian/debhelper/-/merge_requests/117


Regards,

--
Gioele Barabucci

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

[Stéphane Graber]

Yeah, it's my current plan to keep providing image server access to Debian
users until the trixie release or until Incus makes it to
bookworm-backports whichever happens first.

We don't really want to block access to users who don't have a good way out.

So while the published plan is fast paced and sounds pretty strict, we
fully expect to be making exceptions where they make sense and where a
clear timeline is known (as is the case with the trixie release).

Stéphane

On Wed, Dec 27, 2023, 1:03 p.m. Free Ekanayaka  wrote:

> Free Ekanayaka  writes:
>
> > Raphael Hertzog  writes:
> >
> >> Hello,
> >>
> >> On Tue, 26 Dec 2023, Mathias Gibbens wrote:
> >>> On Mon, 2023-12-25 at 12:52 +0100, Raphael Hertzog wrote:
> >>> > I would really like to see incus in unstable/testing and even in
> >>> > bookworm-backports at some point.
> >>>
> >>>   Given the large number of new/updated dependencies for Incus, it
> >>> would be a lot of work to properly prepare a release for bookworm-
> >>> backports once Incus gets into unstable. Not saying that it couldn't be
> >>> done, but I don't know if it would be worth the effort. If you would
> >>> like to use Incus on bookworm right now, probably the best approach
> >>> would be to install the package from Stéphane's repo:
> >>> https://github.com/zabbly/incus.
> >>
> >> If we want to run debusine on a DSA-managed servers, we need to have
> >> packages available on official Debian repositories, hence
> >> bookworm-backports as installing packages from testing/unstable is out
> of
> >> question. :-|
> >
> > I agree with Mathias that having Incus in bookworm-backports requires
> > quite a bit of work. It's probably doable (although we'll have to assess
> > if that'd introduce tricky dependency conflicts), but perhaps having
> > some more folks helping with it would make it more feasible.
>
> BTW, assuming that you don't need any "new" feature from later lxd/incus
> releases, one option would be to have debusine conditionally use the lxd
> package from bookworm when running on bookworm and incus when running on
> trixie (or alternatively just use lxd on both and migrate later on down the
> road). I think that would be much less work than backporting.
>
> The only problem would be that the image server run by LinuxContainers
> is going to phase out support for LXD [0], so at some point bookworm's
> lxd package will stop being able to pull images from there.
>
> One workaround would be to have Stéphane make an exception to the phase
> out plan, and let bookworm's lxd keep working normally (at least until
> trixie is released). I'm not sure how much he's willing to do that, but
> I believe he's open to that possibility if other options (like
> backporting incus) are not quite viable.
>
> [0]
> https://discuss.linuxcontainers.org/t/important-notice-for-lxd-users-image-server/18479
>

Bug#1059449: game-data-packager: Fate of Atlantis fails to start without "scumm:" prefix

[Alexandre Detiste]

Hi,

I have briefly discussed the situation of the Scummvm plugin
with Simon last month in Cambridge.

We agreed that there is too much intelligence in the generated, "unfixable"
(unless someone takes the time to repack the game), generated .deb's;
and that some or most of this intelligence should be moved
to automatically upgradable game-data-packager-runtime.

So actually (option a) the .desktop file would looks like this:
> > +Exec=/usr/share/games/game-data-packager[runtime] fate-of-atlantis-en-data

_or_ (option b) game-data-packager-runtime would ship .desktop files
pre-generated for each game but that would mean spamming
the various desktop environments with so many TryExec=
and I don't know if they would cope

I prefer option a.

I'm getting back at this in 2024

Greetings

Le lun. 25 déc. 2023 à 22:00, Mathias Gibbens  a écrit :
> > --- a/fate-of-atlantis-en-data.desktop2023-12-25 20:44:49.888531966 
> > +
> > +++ b/fate-of-atlantis-en-data.desktop2023-12-25 20:44:46.200557922 
> > +
> > @@ -6,4 +6,4 @@
> >  Terminal=false
> >  Type=Application
> >  Categories=Game;AdventureGame;
> > -Exec=scummvm -p /usr/share/games/fate-of-atlantis-en atlantis
> > +Exec=scummvm -p /usr/share/games/fate-of-atlantis-en scumm:atlantis

Bug#1059520: opendkim: Crashes when postfix accesses opendkim.sock

[Markus Mitsch]

Package: opendkim
Version: 2.11.0~beta2-8+deb12u1
Severity: important
X-Debbugs-Cc: markusmitsc...@gmail.com

Dear Maintainer,
when i send an email via postfix from localhost postfix logs the following:
warning: milter unix:/run/opendkim/opendkim.sock: can't read SMFIC_EOH reply 
packet header: Application error

when i inspect the opendkim log i see:
opendkim.service: Failed with result 'signal'.
opendkim.service: Main process exited, code=killed, status=11/SEGV

running opendkim from command line with "-vf" gives "segmentation fault" in the 
moment i send an email.

Please let me know if you need something else.

Greetings,
Markus

-- 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-16-cloud-amd64 (SMP w/4 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages opendkim depends on:
ii  adduser3.134
ii  dns-root-data  2023010101
ii  init-system-helpers1.65.2
ii  libbsd00.11.7-2
ii  libc6  2.36-9+deb12u3
ii  libdb5.3   5.3.28+dfsg2-1
ii  libldap-2.5-0  2.5.13+dfsg-5
ii  liblua5.3-05.3.6-2
ii  libmemcached11 1.1.4-1
ii  libmilter1.0.1 8.17.1.9-2
ii  libopendbx11.4.6-16+b1
ii  libopendkim11  2.11.0~beta2-8+deb12u1
ii  librbl12.11.0~beta2-8+deb12u1
ii  libssl33.0.11-1~deb12u2
ii  libunbound81.17.1-2+deb12u1
ii  libvbr22.11.0~beta2-8+deb12u1
ii  sysvinit-utils [lsb-base]  3.06-4

Versions of packages opendkim recommends:
ii  opendkim-tools  2.11.0~beta2-8+deb12u1

opendkim suggests no packages.

-- Configuration Files:
/etc/opendkim.conf changed:
Syslog  yes
SyslogSuccess   yes
Canonicalizationrelaxed/simple
Modesv
OversignHeaders From
UserID  opendkim
UMask   007
Socket  local:/run/opendkim/opendkim.sock
PidFile /run/opendkim/opendkim.pid
TrustAnchorFile /usr/share/dns/root.key
InternalHosts   refile:/etc/opendkim/trusted
ExternalIgnoreList  refile:/etc/opendkim/trusted
SigningTablerefile:/etc/opendkim/signing.table
KeyTable/etc/opendkim/key.table
SignatureAlgorithm  rsa-sha256


-- no debconf information

Bug#1059519: wxmaxima: Not working

[user]

Package: wxmaxima
Version: 22.12.0-1
Severity: important
X-Debbugs-Cc: u...@hotmail.com

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages wxmaxima depends on:
ii  libc6  2.36-9+deb12u3
ii  libgcc-s1  12.2.0-14
ii  libstdc++6 12.2.0-14
ii  libwxbase3.2-1 3.2.2+dfsg-2
ii  libwxgtk-webview3.2-1  3.2.2+dfsg-2
ii  libwxgtk3.2-1  3.2.2+dfsg-2
ii  maxima 5.46.0-11

Versions of packages wxmaxima recommends:
ii  maxima-doc  5.46.0-11

Versions of packages wxmaxima suggests:
pn  fonts-jsmath 
ii  ibus-gtk31.5.27-5
ii  texlive-latex-extra  2022.20230122-4

-- no debconf information

Bug#1059518: initramfs-tools-core: mkinitramfs with `MODULES=most` doesn't correctly identify dependent modules, caused BIOS-installed system to fail booting on btrfs rootfs with xxhash checksum

[hastalavista_debian]

Package: initramfs-tools-core
Version: 0.142
Severity: important

mkinitramfs fails to detect that kernel module `xxhash_generic` should be
installed to init ramdisk, when the rootfs is on a btrfs filesystem with
checksum algorithm xxhash, and the disk partition table is msdos. This resulted
in the system being unbootable because the init ramdisk lacks kernel xxhash
support:

BTRFS info (device sda2): first mount of filesystem fs-uuid
BTRFS error (device sda2): error allocating xxhash64 hash for checksum
BTRFS error (device sda2): open_ctree failed
mount: mounting /dev/sda2 on /root failed: No such file or directory
Failed to mount /dev/sda2 as root filesystem.

Busybox v1.35.0 (Debian 1:1.35.0-4+b3) built-in shell (ash)
(Omitted)

After I added `xxhash_generic` to `/etc/initramfs-tools/modules` and
regenerated the init ramdisk the system booted without issue.

UEFI-installed system is unaffected (in fact I have been using btrfs rootfs
with xxhash as checksum alg on UEFI-only machines for almost a year so this
came as a big surprise when I found that it doesn't even boot), probably due to
xxhash module being marked as a dependency of another thing?

I would also like to propose that we add a (debug) option to include all
available kernel modules in init ramdisk, which may help debug issues like this
in the future.


For the debugging process I went through see:
https://paste.debian.net/1302284/
if anyone is interested.


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

Kernel: Linux 6.1.0-15-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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 initramfs-tools-core depends on:
ii  coreutils9.1-1
ii  cpio 2.13+dfsg-7.1
ii  e2fsprogs1.47.0-2
ii  klibc-utils  2.0.12-1
ii  kmod 30+20221128-1
ii  logsave  1.47.0-2
ii  udev 252.19-1~deb12u1

Versions of packages initramfs-tools-core recommends:
ii  busybox-static [busybox]  1:1.35.0-4+b3
ii  zstd  1.5.4+dfsg2-5

Versions of packages initramfs-tools-core suggests:
pn  bash-completion  

-- no debconf information

Bug#726249: snarf: proposed removal

[Serafeim Zanikolas]

reassign -1 src:snarf
retitle -1 snarf: proposed removal
usertags: proposed-removal
thanks

snarf has very few users, better alternatives exist, has not had a
maintainer in 10y, and no active upstream

Bug#1059517: gdcm: add build support for loongarch64

[zhangdandan]

Source: gdcm
Version: 3.0.22-2
Severity: wishlist
Tags: patch ftbfs
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the gdcm failed for loong64 in the my local loong64 environment.
We need to add build support for loongarch64 in d/control.
Please consider the patch I have attached.

I would like to remind you that compilation dependency of gdcm is 
libvtk9-dev (vtk9 lacks loongarch64 support), I have submitted a bug 
request to vtk9 to support loongarch64, please see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054471.
The gdcm source package was compiled successfully on my local loong64 
rootfs environment, for examples,

```
..
   dh_md5sums -O--buildsystem=cmake\+ninja
   dh_builddeb -O--buildsystem=cmake\+ninja
dpkg-deb: 正在 '../libgdcm3.0_3.0.22-2_loong64.deb' 中构建软件包 
'libgdcm3.0'。
dpkg-deb: 正在 '../libgdcm-tools_3.0.22-2_loong64.deb' 中构建软件包 
'libgdcm-tools'。
dpkg-deb: 正在 '../libgdcm3.0-dbgsym_3.0.22-2_loong64.deb' 中构建软件包 
'libgdcm3.0-dbgsym'。

..
dpkg-deb: 正在 '../python3-vtkgdcm_3.0.22-2_loong64.deb' 中构建软件包 
'python3-vtkgdcm'。
dpkg-deb: 正在 '../libgdcm-java-dbgsym_3.0.22-2_loong64.deb' 中构建软件包 
'libgdcm-java-dbgsym'。

 dpkg-genbuildinfo -O../gdcm_3.0.22-2_loong64.buildinfo
 dpkg-genchanges -O../gdcm_3.0.22-2_loong64.changes
..
```

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

thanks,
Dandan Zhang

diff -Nru gdcm-3.0.22/debian/control gdcm-3.0.22/debian/control
--- gdcm-3.0.22/debian/control  2023-10-30 14:38:48.0 +
+++ gdcm-3.0.22/debian/control  2023-12-07 09:37:28.0 +
@@ -185,7 +185,7 @@
  This is the documentation for gdcm and vtkgdcm
 
 Package: libgdcm-java
-Architecture: alpha amd64 arm64 armel armhf i386 ia64 m68k mips64el mipsel 
powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32
+Architecture: alpha amd64 arm64 armel armhf i386 ia64 loong64 m68k mips64el 
mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32
 Section: java
 Depends: ${java:Depends}, ${misc:Depends}, ${shlibs:Depends}
 Suggests: java-virtual-machine
diff -Nru gdcm-3.0.22/debian/control.in gdcm-3.0.22/debian/control.in
--- gdcm-3.0.22/debian/control.in   2023-10-30 14:38:48.0 +
+++ gdcm-3.0.22/debian/control.in   2023-12-07 09:37:28.0 +
@@ -185,7 +185,7 @@
  This is the documentation for gdcm and vtkgdcm
 
 Package: libgdcm-java
-Architecture: alpha amd64 arm64 armel armhf i386 ia64 m68k mips64el mipsel 
powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32
+Architecture: alpha amd64 arm64 armel armhf i386 ia64 loong64 m68k mips64el 
mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32
 Section: java
 Depends: ${java:Depends}, ${misc:Depends}, ${shlibs:Depends}
 Suggests: java-virtual-machine

Bug#1018700: same issue, resolved with upgrade to version 1:115.6.0-1~deb12u1

[Jaap Eldering]

A bit late, but I wanted to say that I had the same issue after upgrading one 
of my systems to Bookworm, but not on other two systems which are set up fairly 
similarly, at least one of which I've been upgrading since Woody. Also, on this 
system where the email folders wouldn't show, the issue was resolved by 
upgrading to the latest version 1:115.6.0-1~deb12u1, without any other changes 
made.

Jaap

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

[Free Ekanayaka]

Free Ekanayaka  writes:

> Raphael Hertzog  writes:
>
>> Hello,
>>
>> On Tue, 26 Dec 2023, Mathias Gibbens wrote:
>>> On Mon, 2023-12-25 at 12:52 +0100, Raphael Hertzog wrote:
>>> > I would really like to see incus in unstable/testing and even in
>>> > bookworm-backports at some point.
>>> 
>>>   Given the large number of new/updated dependencies for Incus, it
>>> would be a lot of work to properly prepare a release for bookworm-
>>> backports once Incus gets into unstable. Not saying that it couldn't be
>>> done, but I don't know if it would be worth the effort. If you would
>>> like to use Incus on bookworm right now, probably the best approach
>>> would be to install the package from Stéphane's repo:
>>> https://github.com/zabbly/incus.
>>
>> If we want to run debusine on a DSA-managed servers, we need to have
>> packages available on official Debian repositories, hence
>> bookworm-backports as installing packages from testing/unstable is out of
>> question. :-|
>
> I agree with Mathias that having Incus in bookworm-backports requires
> quite a bit of work. It's probably doable (although we'll have to assess
> if that'd introduce tricky dependency conflicts), but perhaps having
> some more folks helping with it would make it more feasible.

BTW, assuming that you don't need any "new" feature from later lxd/incus
releases, one option would be to have debusine conditionally use the lxd
package from bookworm when running on bookworm and incus when running on
trixie (or alternatively just use lxd on both and migrate later on down the
road). I think that would be much less work than backporting.

The only problem would be that the image server run by LinuxContainers
is going to phase out support for LXD [0], so at some point bookworm's
lxd package will stop being able to pull images from there.

One workaround would be to have Stéphane make an exception to the phase
out plan, and let bookworm's lxd keep working normally (at least until
trixie is released). I'm not sure how much he's willing to do that, but
I believe he's open to that possibility if other options (like
backporting incus) are not quite viable.

[0] 
https://discuss.linuxcontainers.org/t/important-notice-for-lxd-users-image-server/18479

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

[Free Ekanayaka]

Raphael Hertzog  writes:

> Hello,
>
> On Tue, 26 Dec 2023, Mathias Gibbens wrote:
>> On Mon, 2023-12-25 at 12:52 +0100, Raphael Hertzog wrote:
>> > I would really like to see incus in unstable/testing and even in
>> > bookworm-backports at some point.
>> 
>>   Given the large number of new/updated dependencies for Incus, it
>> would be a lot of work to properly prepare a release for bookworm-
>> backports once Incus gets into unstable. Not saying that it couldn't be
>> done, but I don't know if it would be worth the effort. If you would
>> like to use Incus on bookworm right now, probably the best approach
>> would be to install the package from Stéphane's repo:
>> https://github.com/zabbly/incus.
>
> If we want to run debusine on a DSA-managed servers, we need to have
> packages available on official Debian repositories, hence
> bookworm-backports as installing packages from testing/unstable is out of
> question. :-|

I agree with Mathias that having Incus in bookworm-backports requires
quite a bit of work. It's probably doable (although we'll have to assess
if that'd introduce tricky dependency conflicts), but perhaps having
some more folks helping with it would make it more feasible.

Bug#1059516: chasquid: install systemd units into /usr

[Chris Hofstaedtler]

Source: chasquid
Version: 1.11-2
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: dep17m2

Hi!

Your package installs systemd units into /lib/systemd/system, using
a hardcoded path in debian/*.install. For the ongoing Debian
UsrMerge effort [1] these files should move to /usr in the trixie
cycle.

I'm attaching a trivial patch for your convenience.

However, please still read the wiki page on moving files, especially
if you intend to backport to bookworm or earlier. The patch has
already been checked by a local dumat copy.

Other options include using dh_installsystemd or discovering the
correct install path using pkg-config (systemd.pc).

If during the trixie cycle your package will undergo structural
changes or any other file moves, please also see the wiki and upload
to experimental first when these changes are done.

Chris

[1] https://wiki.debian.org/UsrMerge
diff -Nru chasquid-1.11/debian/changelog chasquid-1.11/debian/changelog
--- chasquid-1.11/debian/changelog	2023-02-27 14:18:59.0 +0100
+++ chasquid-1.11/debian/changelog	2023-12-27 12:41:58.0 +0100
@@ -1,3 +1,11 @@
+chasquid (1.11-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install systemd units into /usr instead of /. (Closes: #-1)
+Build-Depend on newer debhelper supporting that path.
+
+ -- Chris Hofstaedtler   Wed, 27 Dec 2023 12:41:58 +0100
+
 chasquid (1.11-2) unstable; urgency=medium
 
   * Fix systemd config files (revert to 1.10 for Debian)
diff -Nru chasquid-1.11/debian/control chasquid-1.11/debian/control
--- chasquid-1.11/debian/control	2023-02-27 14:17:31.0 +0100
+++ chasquid-1.11/debian/control	2023-12-27 12:41:23.0 +0100
@@ -4,7 +4,7 @@
 Maintainer: Debian Go Packaging Team 
 Uploaders: Martina Ferrari ,
Alberto Bertogli 
-Build-Depends: debhelper (>= 13~),
+Build-Depends: debhelper (>= 13.11.6~),
debhelper-compat (= 13),
dh-golang (>= 1.18~),
golang-any,
diff -Nru chasquid-1.11/debian/install chasquid-1.11/debian/install
--- chasquid-1.11/debian/install	2023-02-27 14:17:31.0 +0100
+++ chasquid-1.11/debian/install	2023-12-27 12:41:08.0 +0100
@@ -9,5 +9,5 @@
 # Override the service and sockets, as we make small Debian-specific
 # changes to it, and retain the 1.10 structure (it was changed in 1.11 and we
 # have not yet updated the Debian package to it).
-debian/systemd/*.service	lib/systemd/system/
-debian/systemd/*.socket		lib/systemd/system/
+debian/systemd/*.service	usr/lib/systemd/system/
+debian/systemd/*.socket		usr/lib/systemd/system/

Bug#1059370: Installation did not work: Kernel panic, see below

[Pascal Hambourg]

I forgot to mention it, but please also reply to the bug report address, 
not only me.


On 27/12/2023 at 12:17, Christian Kirsch wrote:

Yes, thank you! I hadn't dared to execute these commands. But they
worked, very good.
So 'update-grub' and 'grub-install' fits the Problem.


I wonder which one was actually needed. I should have suggested to run 
one and reboot, then run the other one only if the issue persisted.


So maybe GRUB was not properly installed after all. But I am failing to 
figure out what could have gone wrong. Can you compress and attach the 
installation log (/var/log/installer/syslog) please ?



I also activated 'GRUB_DISABLE_OS_PROBER=false' so Ubuntu is also taken
along, for all cases (so said in germany...).
Then this process is finished for me and I thank you for your help,
Christian

Am Mittwoch, dem 27.12.2023 um 11:15 +0100 schrieb Pascal Hambourg:


Basically, the Debian installer just installs required grub packages and
runs grub-install and update-grub in the target system environment so if
GRUB loads and displays the menu, it is unlikely that the installer did
something wrong.

After booting into Debian through Ubuntu's GRUB menu, you can try to
re-run these commands and reboot with Debian GRUB. If it does not fix
the error, then the issue probably lies in GRUB itself and the bug
may be reassigned to grub2.

Bug#1059515: mdns-reflector: installs new files into /

[Chris Hofstaedtler]

Source: mdns-reflector
Version: 0.0.1+git20230914.4b4cd3b-1
User: helm...@debian.org
Usertags: dep17m2

Hi,

your package mdns-reflector started installing (for unstable) new files into /,
instead of placing them below /usr. For the Debian UsrMerge effort [1], these
need to move to /usr.

Filelist:
 ./lib/
 ./lib/systemd/
 ./lib/systemd/system/
 ./lib/systemd/system/mdns-reflector.service
 ./lib/systemd/system/mdns-reflector@.service

Please see wiki page [1] about moving files.

Given there are just systemd service units, it can be beneficial to use
dh_installsystemd, instead of installing using dh_install.
Alternatively, `pkg-config --variable=systemdsystemunitdir systemd`
also knows the "correct" place (this is usually suitable for fixing
upstream). You'll need to add Build-Depends: systemd-dev for that.

Thanks,
Chris

[1] https://wiki.debian.org/UsrMerge

Bug#1059514: please enable snaphot_autoextend_threshold and thin_pool_autoextend_threshold by default

[Harald Dunkel]

Package: lvm2
Version: 2.03.16-2

I would highly recommend to set snaphot_autoextend_threshold and
thin_pool_autoextend_threshold to 70 (or another reasonable value)
by default than disabling the autoextend feature. AFAICT the dmeventd
infrastructure is in place, anyway.

Without autoextend a snapshot exceeding its limits is fatal. The
default warnings dmeventd writes to syslog are easy to miss.


Regards

Harri

Bug#1058938: onionprobe 1.0.0+ds-2.1+deb12u1 flagged for acceptance

[Jonathan Wiltshire]

package release.debian.org
tags 1058938 = bookworm pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: onionprobe
Version: 1.0.0+ds-2.1+deb12u1

Explanation: fix initialisation of Tor if using hashed passwords

Bug#1055092: rust-hashbrown: please upgrade to v0.14

[Peter Green]

preliminary analysis of reverse dependencies.

btm
 upstream uses 0.14 debian is currently down-patching.

rust-ahash
 dev dependency only, tests pass with dependency bumped.

rust-chumsky
 new upstream uses 0.14 and is not semver breaking.

rust-dashmap
 new upstream uses 0.14 and is not semver breaking.

rust-hashlink
 new upstream uses 0.14 and is not semver breaking.

rust-imara-diff
 upstream has bumped dependency to 0.14 in git but hasn't released yet
 no code changes were made with dependency bump.

rust-indexmap
 new upstream uses 0.14 but new upstreram is semver breaking
 I think it makes most sense to do these two together.

rust-lru
 new upstream uses 0.14 but new upstream is semver breaking,
 upstream made no code changes when bumping dependency,
 I think patching is the way to go here.
 I was able to get a successful test with the dependeny bumped.

rust-ordered-multimap
 new upstream uses 0.14 but new upstream is semver breaking and has too high 
msrv.
 I think patching is the way to go here.
 Version in debian builds ok after bumping dependency.

rust-regalloc2
 jonas package
 upstream still on hashbrown 0.13
 builds ok and tests pass after bumping dependency.

rust-rkyv
 upstream has bumped in git, but not yet included in a release.
 builds ok and tests pass after bumping dependency
 note: building with --all-features fails for unrelated reasons.

rust-unicode-linebreak
 new upstream has moved to shipping pre-generated tables, eliminating the 
dependency on hashbrown.
 version in Debian builds/tests ok with dependency bumped.

rust-wasmtime (librust-cranelift-dev)
 jonas package
 version in unstable/experimental is broken.
 version in testing is rather old.
 hoping the release team will file a "fails to migrate to testing for too long" 
in the not to distant future.
 upstream version in unstable/experimental uses 0.14, downpatched in Debian
 upstream version in testing uses 0.13, downpatched in Debian.

Bug#1059163: cpio: Path traversal vulnerability

[Ingo Brückl]

On Fri, 22 Dec 2023 13:43:18 +1100, Aníbal Monsalve Salazar wrote:

> I have been working on a new Debian version of cpio for the last couple
> of days. I hope to upload it today. I will appreciate it very much if
> you could give it a try after uploading it.

It looks good to me.

Regards,

Ingo

Bug#1058018: libadios2-common-core-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/cmake/adios2/adios2-config.cmake

[Paul Gevers]

Hi Drew,

On Mon, 11 Dec 2023 20:24:01 +0100 Drew Parsons  wrote:

Control: severity -1 important


Helmut disagreed with your call here and asked the Release Team on IRC 
to have a check.



Call it teething issues. This is a new package, so I'm trying to avoid
making debian/control more verbose than it needs to be by not crowding
the fields with the strict specifications needed to avoid this error.


I agree with Helmut that under normal circumstances this bug is an RC 
issue and I think you agree too. I think that adding a versioned 
Breaks/Replaces that you can drop after the release of trixie isn't too 
much to ask for something that has been part of trixie already. Having 
said that, I'm not going to overrule you.



Once the new version migrates to testing, I'll close this bug and we
can pretend it never happened.


For next time, I ask you to consider either using experimental to iron 
out things like this and/or ensure your package doesn't migrate to 
testing until you believe you're done. Having said that, unstable does 
have users. E.g. our derivatives often pull from unstable, so even for 
those it's nice to do the right thing. I'm sure you don't know of all 
our derivatives when they freeze, and hence if they happened to have 
released to their stable the thing that now breaks.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059513: UnicodeDecodeError: invalid continuation byte

[Rainer Dorsch]

Package: cups-tea4cups
Version: 3.14~alpha0+svn3576-2
Severity: normal

Dear Maintainer,

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

Many thanks for maintaining the cups package.

I use tea4cups to power on and off my network printer.

For some jobs I see exceptions in tea4cups which stop the print job:

rd@home:~$ grep "Job 1512" /var/log/cups/error_log
I [27/Dec/2023:10:46:25 +0100] [Job 1512] Adding start banner page "none".
I [27/Dec/2023:10:46:25 +0100] [Job 1512] Queued on "CP1525nw" by "rd".
I [27/Dec/2023:10:46:25 +0100] [Job 1512] File of type application/postscript 
queued by "rd".
I [27/Dec/2023:10:46:25 +0100] [Job 1512] Adding end banner page "none".
I [27/Dec/2023:10:47:26 +0100] [Job 1512] Started filter 
/usr/lib/cups/filter/gstopdf (PID 28163)
I [27/Dec/2023:10:47:26 +0100] [Job 1512] Started filter 
/usr/lib/cups/filter/pdftopdf (PID 28164)
I [27/Dec/2023:10:47:26 +0100] [Job 1512] Started filter 
/usr/lib/cups/filter/gstoraster (PID 28165)
I [27/Dec/2023:10:47:26 +0100] [Job 1512] Started filter 
/usr/lib/cups/filter/hpcups (PID 28168)
I [27/Dec/2023:10:47:26 +0100] [Job 1512] Started backend 
/usr/lib/cups/backend/tea4cups (PID 28170)
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) : Traceback 
(most recent call last):
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :   File 
\"/usr/lib/cups/backend/tea4cups\", line 1177, in initBackend
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) : answer = 
cupsserver.getJobAttributes(self.JobId)
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :  
^^^
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :   File 
\"/usr/lib/cups/backend/tea4cups\", line 784, in getJobAttributes
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) : return 
self.doRequest(req)
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :
^^^
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :   File 
\"/usr/lib/cups/backend/tea4cups\", line 762, in doRequest
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) : 
wrapper.logDebug(\"request content: %s\"%str(r.raw.content))
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :
^
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) : 
AttributeError: \'HTTPResponse\' object has no attribute \'content\'
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) : During 
handling of the above exception, another exception occurred:
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) : Traceback 
(most recent call last):
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :   File 
\"/usr/lib/cups/backend/tea4cups\", line 1547, in 
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) : 
wrapper.initBackend()
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :   File 
\"/usr/lib/cups/backend/tea4cups\", line 1183, in initBackend
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) : 
(ippfilename, answer) = self.parseIPPRequestFile()
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :
 ^^
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :   File 
\"/usr/lib/cups/backend/tea4cups\", line 1233, in parseIPPRequestFile
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) : ippmessage 
= IPPRequest(ippdatafile.read())
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :
 ^^
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :   File 
\"\", line 322, in decode
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) : 
UnicodeDecodeError: \'utf-8\' codec can\'t decode byte 0xe7 in position 760: 
invalid continuation byte
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) : Traceback 
(most recent call last):
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :   File 
\"/usr/lib/cups/backend/tea4cups\", line 1177, in initBackend
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) : answer = 
cupsserver.getJobAttributes(self.JobId)
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :  
^^^
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :   File 
\"/usr/lib/cups/backend/tea4cups\", line 784, in getJobAttributes
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) : return 
self.doRequest(req)
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :
^^^
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS (PID 28170) :   File 
\"/usr/lib/cups/backend/tea4cups\", line 762, in doRequest
E [27/Dec/2023:10:47:44 +0100] [Job 1512] Tea4CUPS 

Bug#1059370: Installation did not work: Kernel panic, see below

[Pascal Hambourg]

Le 26/12/2023 à 20:35, Christian Kirsch wrote:

Thank you for your feedback.
I can probably support the assumption about Grub: I have installed
another partition with Ubuntu. Ubuntu recognizes the Debian partition
and updates the grub correctly. Debian can now be started from there.
This would mean that there is an error in the Debian iso file for the
grub management in the EFI-Partition.


Basically, the Debian installer just installs required grub packages and 
runs grub-install and update-grub in the target system environment so if 
GRUB loads and displays the menu, it is unlikely that the installer did 
something wrong.


After booting into Debian through Ubuntu's GRUB menu, you can try to 
re-run these commands and reboot with Debian GRUB. If it does not fix 
the error, then the issue probably lies in GRUB itself and the bug may 
be reassigned to grub2.



Am Sonntag, dem 24.12.2023 um 00:28 +0100 schrieb Pascal Hambourg:

On 23/12/2023 at 20:52, Christian Kirsch wrote:


When booting (first item), message on Debian screen:
"Arbeitsspeicher
erschöpft" ("Memory exhausted").


It matches the German translation for "out of memory" in GRUB.


Then start in a black terminal screen with Kernel panic: "Kernel
panic
- not syncing: VHS Unable to mount root fs on unknown-block(0,0)"


It looks like a consequence of GRUB failure to load the initramfs
properly.

Bug#1059512: stopping unsuccessful with sysvinit

[Matus UHLAR - fantomas]

Package: postfwd
Version: 1.35-5

with sysvinit, the init script only tries to stop postfwd with --pidfile 
option:


start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE && rm -rf 
$PIDFILE

this causes start-stop-daemon to complain and not stop the daemon:

Stopping postfwd: start-stop-daemon: matching only on non-root pidfile 
/var/run/postfwd.pid is insecure

in some circumstances this can also remove pidfile while postfwd is running

I'm attaching patch that adds "--name" argument to start-stop-daemon, which 
makes the stopping work safely.


I have tested this on Debian 10 and Debian 12, with both postfwd1 and 
postfwd2, patch fixes both cases.



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
99 percent of lawyers give the rest a bad name.
--- /etc/init.d/postfwd.orig	2021-01-06 21:49:07.0 +0100
+++ /etc/init.d/postfwd	2023-12-26 17:05:55.385432922 +0100
@@ -20,6 +20,7 @@
 NAME=postfwd
 DAEMON=/usr/sbin/${NAME}
 PIDFILE=/var/run/$NAME.pid
+PROCNAME=/usr/sbin/postf
 DESC=postfwd
 
 . /lib/lsb/init-functions
@@ -79,7 +80,7 @@
 	;;
   stop)
 	echo -n "Stopping $DESC: "
-	start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE && rm -rf $PIDFILE
+	start-stop-daemon --stop --quiet --oknodo --name $PROCNAME --pidfile $PIDFILE --remove-pidfile
 echo "$NAME."
 	;;
   reload)

Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)

[Drew Parsons]

On 2023-12-27 09:51, Alastair McKinstry wrote:

On 27/12/2023 08:45, Drew Parsons wrote:

...
I guess the problem must be the common files from openmpi-common in 
/usr/share/openmpi/. They're not actually arch-independent.  Do 
mpif90.openmpi and the other components actively read them at runtime?

..

This appears to be it. I've been building on arm64 recently (a VM on a
mac) and don't see this.

There appears to be a mechanism for including ${includedir} and
${libdir} and evaluating the wrapper-data files at runtime. My hacking
on these files in d/rules is causing the errors. I'll work on a better
solution.



I can see at the lowest level the location is pkgdatadir at l.110 (and 
elsewhere) in ompi/tools/wrappers/Makefile.am
Not clear if hacking it at that point will interfere with the orterun 
binary finding them.
If not, then it could in principle be replaced with something like 
$(pkglibdir)/$(datadir) (i.e. in a share subdir under the openmpi 
libdir). Might call it "pkglibdatadir".


The default value for pkgdatadir is set as $(datadir)/@PACKAGE@, l.129 
in toplevel Makefile.in
datadir is the autotool default ${prefix}/share (i.e. /usr/share), 
https://www.gnu.org/software/automake/manual/html_node/Standard-Directory-Variables.html


If orterun can be trained to look for the wrapper txt files in 
pkglibdatadir (presumably as well as pkgdatadir, not instead of), then 
setting and using "pkglibdatadir" instead of pkgdatadir in 
ompi/tools/wrappers/Makefile.am "might" be simple and reliable. 
Reliability depends on whether any other component uses these wrapper 
txt files.

Bug#1059511: pocl: FTBFS on many architectures: The testsuite has failed

[Bo YU]

Source: pocl
Version: 4.0-3 
Severity: important

Dear Maintainer,

I am looking at the build issue from riscv64 port view but it can not be
build many arches:
https://buildd.debian.org/status/package.php?p=pocl

It seems even updated the symbols file still failed due to exist
debian/stamp-failed-testsuite file.

```
run_dh_makeshlibs:
dh_makeshlibs
delayed_check_dh_auto_test_result: run_dh_makeshlibs
@set -ex; if test -f debian/stamp-failed-testsuite ; then \
echo "* The testsuite has failed! *" ; \
exit 1 ; \
fi  
   @test -f 
obj-*/Testing/Temporary/LastTest.log && echo 'The testsuite has passed all 
tests.' || echo '*** The testsuite was *NOT* ru
n! ***'

```

The same issue happend on 5.0 also:
https://buildd.debian.org/status/package.php?p=pocl=experimental

But from upstream 5.0 release note, there is support well expect 4 tests
failed. So what is your advice here about the issue?

http://portablecl.org/docs/html/notes_5_0.html#risc-v-cpu-support-improved


-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1059273: missing path /var/lib/ntp/drift-tmp in apparmor.d/usr.sbin.ntpd

[Stefan Bauer]

Sorry to bother you with this. We indeed modified the ntp.conf.

Shame on me :/

This bug can be closed.

Stefan

> Richard Laager  hat am 24.12.2023 21:59 CET geschrieben:
> 
>  
> On 2023-12-22 05:32, Stefan Bauer wrote:
> > Apparmor denies creation of /var/lib/ntp/drift-tmp.
> 
> Where are you getting /var/lib/ntp/drift from?
> 
> The ntpsec package in Debian has (from when both ntp and ntpsec existed 
> in Debian) everything namespaced under "ntpsec". It uses 
> /var/lib/ntpsec/ntp.drift in the default config file.
> 
> Maybe you have something different set. What does "grep driftfile 
> /etc/ntpsec/ntp.conf" say?
> 
> -- 
> Richard

Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)

[Alastair McKinstry]

On 27/12/2023 08:45, Drew Parsons wrote:

On 2023-12-26 12:45, Drew Parsons wrote:


I can manually reproduce the error trivially on an arm64 chroot
(amdahl.debian.org).  Copying hello.f90 from openmpi's debian/tests
and manually running
  mpif90 -o hello hello.f90
reproduces the error reference to the x86_64 include path on the 
arm64 machine.


`mpif90.openmpi -print-search-dirs` only shows aarch64 paths though.


I guess the problem must be the common files from openmpi-common in 
/usr/share/openmpi/. They're not actually arch-independent.  Do 
mpif90.openmpi and the other components actively read them at runtime?


For instance, /usr/share/openmpi/mpif90.openmpi-wrapper-data.txt contains
fmoddir=/usr/include/x86_64-linux-gnu/fortran/gfortran-mod-15

Since openmpi-common is marked Arch: all, it's only built once, on 
amd64, hence x86_64-linux-gnu gets carried to the other arches. The 
compiler_flags variables is also affected, alongside as fmoddir.


It looks like only the mpi fortran wrapper txts are affected,
mpif77-wrapper-data.txt
mpif77.openmpi-wrapper-data.txt
mpif90-wrapper-data.txt
mpif90.openmpi-wrapper-data.txt
mpifort-wrapper-data.txt
mpifort.openmpi-wrapper-data.txt

Should these be moved from openmpi-common to libopenmpi-dev (or 
openmpi-bin)

at /usr/lib//openmpi/share ?


This appears to be it. I've been building on arm64 recently (a VM on a 
mac) and don't see this.


There appears to be a mechanism for including ${includedir} and 
${libdir} and evaluating the wrapper-data files at runtime. My hacking 
on these files in d/rules is causing the errors. I'll work on a better 
solution.



Alastair


--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie

Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)

[Drew Parsons]

On 2023-12-26 12:45, Drew Parsons wrote:


I can manually reproduce the error trivially on an arm64 chroot
(amdahl.debian.org).  Copying hello.f90 from openmpi's debian/tests
and manually running
  mpif90 -o hello hello.f90
reproduces the error reference to the x86_64 include path on the arm64 
machine.


`mpif90.openmpi -print-search-dirs` only shows aarch64 paths though.


I guess the problem must be the common files from openmpi-common in 
/usr/share/openmpi/. They're not actually arch-independent.  Do 
mpif90.openmpi and the other components actively read them at runtime?


For instance, /usr/share/openmpi/mpif90.openmpi-wrapper-data.txt 
contains

fmoddir=/usr/include/x86_64-linux-gnu/fortran/gfortran-mod-15

Since openmpi-common is marked Arch: all, it's only built once, on 
amd64, hence x86_64-linux-gnu gets carried to the other arches.  The 
compiler_flags variables is also affected, alongside as fmoddir.


It looks like only the mpi fortran wrapper txts are affected,
mpif77-wrapper-data.txt
mpif77.openmpi-wrapper-data.txt
mpif90-wrapper-data.txt
mpif90.openmpi-wrapper-data.txt
mpifort-wrapper-data.txt
mpifort.openmpi-wrapper-data.txt

Should these be moved from openmpi-common to libopenmpi-dev (or 
openmpi-bin)

at /usr/lib//openmpi/share ?

Bug#1059510: bowtie2: add build support for loongarch64

[zhangdandan]

Source: bowtie2
Version: 2.5.1-1
Severity: wishlist
Tags: patch ftbfs
User: debian-loonga...@lists.debian.org
Usertags: loong64

Dear maintainers,

Compiling the bowtie2 failed for loong64 in the my local loong64 
environment.

We need to add build support for loongarch64 in d/control.

The bowtie2 source package was compiled successfully on my local loong64 
rootfs environment.

Please consider the patch I have attached.
Your opinions are welcome.

thanks,
Dandan Zhang

diff -Nru bowtie2-2.5.1/debian/control bowtie2-2.5.1/debian/control
--- bowtie2-2.5.1/debian/control2023-09-12 11:15:56.0 +
+++ bowtie2-2.5.1/debian/control2023-09-12 11:16:13.0 +
@@ -22,7 +22,7 @@
 Rules-Requires-Root: no
 
 Package: bowtie2
-Architecture: any-amd64 arm64 mips64el ppc64el ia64 m68k ppc64 riscv64 sh4 
sparc64
+Architecture: any-amd64 arm64 mips64el ppc64el ia64 loong64 m68k ppc64 riscv64 
sh4 sparc64
 Depends: python3,
  ${misc:Depends},
  ${shlibs:Depends},

Bug#1059509: release-notes: script -t is deprecated, should we recommend --log-timing?

[Paul Gevers]

Package: release-notes
Severity: minor

Note to self. I just stumbled upon $(man script):
"""
   -t[file], --timing[=file]
   Output timing data to standard error, or to file when given. 
This option is deprecated in favour of --log-timing where the file

   argument is not optional.
"""

We use the -t option in the "4.4.1. Recording the session" section, so 
we should probably revisit that.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059508: tcsh: Compilation failed on multiple architectures

[Zhang Na]

Source: tcsh
Version: 6.24.10-3
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn

Dear Maintainer,

  https://buildd.debian.org/status/package.php?p=tcsh=sid
  Compilation failed on multiple architectures, the reason for failure is the 
same. You should compile using regular users instead of root. The shell prompts 
for root and user are different, and testing will result in errors for root.
  I have verified on Loong64.
  Many packages depend on tcsh, please help compile them through,
  thanks!

   my test:
   dh_md5sums
   dh_builddeb
dpkg-deb: building package 'tcsh-dbgsym' in 
'../tcsh-dbgsym_6.24.10-3_loong64.deb'.
dpkg-deb: building package 'tcsh' in '../tcsh_6.24.10-3_loong64.deb'.
 dpkg-genbuildinfo -O../tcsh_6.24.10-3_loong64.buildinfo
 dpkg-genchanges -O../tcsh_6.24.10-3_loong64.changes
dpkg-genchanges: info: not including original source code in upload
 dpkg-source --after-build .
dpkg-buildpackage: info: binary and diff upload (original source NOT included)
zhangna@localhost:~/tcsh-1/tcsh-6.24.10$ ls ../
build.log  tcsh_6.24.10-3.debian.tar.xz  
tcsh_6.24.10-3_loong64.changes
tcsh-6.24.10   tcsh_6.24.10-3.dsc
tcsh_6.24.10-3_loong64.deb
tcsh-dbgsym_6.24.10-3_loong64.deb  tcsh_6.24.10-3_loong64.buildinfo  
tcsh_6.24.10.orig.tar.gz
zhangna@localhost:~$ arch
loongarch64



-- 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=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

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

[Raphael Hertzog]

Hello,

On Tue, 26 Dec 2023, Mathias Gibbens wrote:
> On Mon, 2023-12-25 at 12:52 +0100, Raphael Hertzog wrote:
> > I would really like to see incus in unstable/testing and even in
> > bookworm-backports at some point.
> 
>   Given the large number of new/updated dependencies for Incus, it
> would be a lot of work to properly prepare a release for bookworm-
> backports once Incus gets into unstable. Not saying that it couldn't be
> done, but I don't know if it would be worth the effort. If you would
> like to use Incus on bookworm right now, probably the best approach
> would be to install the package from Stéphane's repo:
> https://github.com/zabbly/incus.

If we want to run debusine on a DSA-managed servers, we need to have
packages available on official Debian repositories, hence
bookworm-backports as installing packages from testing/unstable is out of
question. :-|

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


signature.asc
Description: PGP signature

Bug#1059507: golang-github-dvsekhvalnov-jose2go: CVE-2023-50658

[Salvatore Bonaccorso]

Source: golang-github-dvsekhvalnov-jose2go
Version: 1.5-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for 
golang-github-dvsekhvalnov-jose2go.

CVE-2023-50658[0]:
| The jose2go component before 1.6.0 for Go allows attackers to cause
| a denial of service (CPU consumption) via a large p2c (aka PBES2
| Count) value.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-50658
https://www.cve.org/CVERecord?id=CVE-2023-50658
[1] 
https://github.com/dvsekhvalnov/jose2go/commit/a4584e9dd7128608fedbc67892eba9697f0d5317

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1059275: Accepted libde265 1.0.15-1 (source) into unstable

[Salvatore Bonaccorso]

Source: libde265
Source-Version: 1.0.15-1

On Wed, Dec 27, 2023 at 06:19:05AM +, Debian FTP Masters wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Format: 1.8
> Date: Thu, 21 Dec 2023 09:29:24 +0100
> Source: libde265
> Architecture: source
> Version: 1.0.15-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Multimedia Maintainers 
> Changed-By: Joachim Bauch 
> Changes:
>  libde265 (1.0.15-1) unstable; urgency=medium
>  .
>* New upstream version 1.0.15
>* Fixes CVE-2023-49465, CVE-2023-49467, CVE-2023-49468.
>* Add patch to fix "Libs.private" in libde265.pc.
> Checksums-Sha1:
>  fc3e0a8e93895afd3e19220269d7b279c56d79d6 1872 libde265_1.0.15-1.dsc
>  4f242cf6bfa60502f235c66f43567b0a07a2c6c9 846016 libde265_1.0.15.orig.tar.gz
>  fdbd467cd52efaf81bee326edc9162161cbc6b3c 136584 
> libde265_1.0.15-1.debian.tar.xz
>  899dd31db14cbd76bce9a9e87c8e642c82160e5d 10275 
> libde265_1.0.15-1_source.buildinfo
> Checksums-Sha256:
>  41fe11a559a57a8cdf19978c55f58f0d83de78c61e1367f8b73d05bdcce416eb 1872 
> libde265_1.0.15-1.dsc
>  00251986c29d34d3af7117ed05874950c875dd9292d016be29d3b3762666511d 846016 
> libde265_1.0.15.orig.tar.gz
>  70cb236e55972d2d1bc062bacd68320ad402e0d378c79c99224a512208c90e5b 136584 
> libde265_1.0.15-1.debian.tar.xz
>  60245a25b8fe4f5aedd25fc0dd2f88d91d87336a50fb79d7481250b9884673a7 10275 
> libde265_1.0.15-1_source.buildinfo
> Files:
>  1465ca3bc716747f1fa103d84ff2f77e 1872 libs optional libde265_1.0.15-1.dsc
>  d61e9fb8052b8d90d76ab67fd84e018d 846016 libs optional 
> libde265_1.0.15.orig.tar.gz
>  cb1776e588f121c4180a1fc8de0e23f7 136584 libs optional 
> libde265_1.0.15-1.debian.tar.xz
>  5a5466e504be3cc41cce0ca9eee12ab1 10275 libs optional 
> libde265_1.0.15-1_source.buildinfo
> 
> -BEGIN PGP SIGNATURE-
> 
> iQEzBAEBCAAdFiEEhhz+aYQl/Bp4OTA7O1LKKgqv2VQFAmWLvNIACgkQO1LKKgqv
> 2VRBQQf/TVnrFGdZHgXjuTQU4ncsPZVkIB68F9ZzCc4XHY4I8blbQ2O9JTte3jA6
> 575wbyq11lb626VvApfVcqKbtXBasYl7KDFkVUATyloBKu21IAcRshITYYPJJ5vE
> gdkiuC1MsqwzCg18hwnkM/hgo7cMaNbcCxaD/SDMepHliZM7vukO1lmccpOsQq9i
> umh9OvJeIzLCECEBdAZ08szm8sAwJEA6+YgNsnAlwDMxDeKoIevfChT7u4y5F+m1
> WUCBI8uIi9+pbvuVv0ehQDHqfx+3/VjNn27G0z1J+HlsRq11yOv4R66AlcvfVTJ8
> e0UCFaQdZtwqn0XRzovyyIba6lMmLA==
> =xhY5
> -END PGP SIGNATURE-
>