Bug#1058081: nvidia-graphics-drivers: Include systemd power management services and scripts

[Jian-Hong Pan]

Package: nvidia-graphics-drivers
Version: 530.41.03-3

Hi,

I follow the discussion of "nvidia-graphics-drivers: please package
systemd power management scripts" [1] and
* Install new package nvidia-suspend-common: So, there are the systemd
unit files and "nvidia-sleep.sh"
* Set NVreg_PreserveVideoMemoryAllocations: So, nvidia's parameter
"InitializeSystemMemoryAllocations" is 1
$ grep InitializeSystemMemoryAllocations /proc/driver/nvidia/params
InitializeSystemMemoryAllocations: 1

Also, took Fedora's gdm patch "udev: Stick with wayland on hybrid
nvidia with vendor driver" [2]

Then, the system uses GNOME Wayland!

$ printenv XDG_SESSION_TYPE
wayland

However, system fails to suspend and shows the error in log:

systemd-sleep[2781]: /usr/bin/nvidia-sleep.sh: line 33: chvt: command not found
systemd-sleep[2794]: /dev/sda:
systemd-sleep[2794]:  setting Advanced Power Management level to 0xfe (254)
systemd-sleep[2794]:  APM_level= 254
systemd[1]: systemd-suspend.service: Main process exited, code=exited,
status=1/FAILURE
systemd[1]: systemd-suspend.service: Failed with result 'exit-code'.
systemd[1]: Failed to start System Suspend.
systemd[1]: Dependency failed for Suspend.
systemd[1]: suspend.target: Job suspend.target/start failed with
result 'dependency'.
systemd[1]: Stopped target Sleep.
systemd-logind[459]: Operation 'sleep' finished

The "chvt" should be provided by kbd package.
After I install kbd, the system can suspend & resume correctly.

I think kbd should be the dependency of nvidia-suspend-common.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038006
[2]: 
https://src.fedoraproject.org/rpms/gdm/blob/rawhide/f/0001-udev-Stick-with-wayland-on-hybrid-nvidia-with-vendor.patch

Jian-Hong Pan

Bug#1057171: libitext5-java: FTBFS with bouncycastle 1.77

[tony mancill]

On Thu, Nov 30, 2023 at 11:06:56PM +0100, Markus Koschany wrote:
> Source: libitext5-java
> Version: 5.5.13.3-2
> Severity: serious
> Tags: ftbfs sid
> User: a...@debian.org
> Usertags: bouncycastle-1.77

There are PDF signature and encryption test cases running as part of the
build, and I did some desk-testing of programs that depend on
libitext5-java: jameica/hibiscus and mobile-atlas-creator, which I was
able to use to generates a PDF - and everything seems fine at runtime.

I'll keep an eye out for any runtime issues with digitally signed PDFs
and move on to libitext-java.

Bug#1058078: [Pkg-javascript-devel] Bug#1058078: FTBFS: ESLint couldn't find the config "not-an-aardvark/node" to extend from

[Yadd]

Control: tags -1 + patch

On 12/12/23 09:59, Yadd wrote:

Package: node-eslint-plugin-eslint-plugin
Version: 2.3.0+~0.3.0-4
Severity: serious
Tags: ftbfs
Justification: ftbfs

Hi,

when trying to reproduce node-eslint-plugin-eslint-plugin build, sbuild
fails. Below relevant logs:

eslint --format tap Xcomposer
TAP version 13
1..2
ok 1 - /<>/Xcomposer/lib/rule-composer.js
ok 2 - /<>/Xcomposer/tests/lib/rule-composer.js

eslint --format tap . --ignore-pattern '!.*'

Oops! Something went wrong! :(

ESLint: 6.4.0.

ESLint couldn't find the config "not-an-aardvark/node" to extend from. Please 
check that the name of the config is correct.

The config "not-an-aardvark/node" was referenced from the config file in 
"/<>/.pc/2002_avoid_eslint-plugin-self.patch/.eslintrc.yml".

If you still have problems, please stop by https://gitter.im/eslint/eslint to 
chat with the team.

make[1]: *** [debian/rules:38: override_dh_auto_test] Error 2


Hi Jonas,

this patch seems to fix the problem:

--- a/debian/rules
+++ b/debian/rules
@@ -35,7 +35,7 @@ override_dh_auto_build: $(DOCS) $(CHANGELOGS)

 override_dh_auto_test:
$(ESLINT) Xcomposer
-   $(ESLINT) . --ignore-pattern '!.*'
+   $(ESLINT) . --ignore-pattern .pc
$(MOCHA) --recursive Xcomposer/tests
$(MOCHA) --recursive tests

Bug#1057124: RFS: harmony/0.7.2-1 [ITA] -- program and library for creating and managing Discord accounts

[Paul Wise]

On Thu, 2023-11-30 at 08:33 +0100, Patrick ZAJDA wrote:

> I am looking for a sponsor for my package "harmony":

Apologies for the delay.

Once these two issues are fixed I will sponsor the package:

> * Suppress Lintian warning about man page

It is incorrect to suppress valid lintian warnings, instead you should
either ignore them or fix them, probably upstream in this case.

While this package isn't possible to autopkgtest easily since it is for
a live proprietary service, you could add superficial testing that the
Python module can be imported; in the Source section of debian/control:

   Testsuite: autopkgtest-pkg-python
   
Here is some documentation related to that:
   
   https://wiki.debian.org/Python/LibraryStyleGuide#autopkgtest
   https://wiki.debian.org/ContinuousIntegration/autopkgtest
   
https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst

These issues may be interesting to work on if you have spare time:

Upstream may like to modernise the Python packaging:

   https://packaging.python.org/en/latest/tutorials/packaging-projects/

pycodestyle/pydocstyle/pyflakes3/pylint/vulture/ruff report some
(likely minor) code issues if you want to contribute fixes upstream.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1058080: node-eslint-plugin-eslint-plugin: Please add this patch for node-ajv >= 8

[Yadd]

Package: node-eslint-plugin-eslint-plugin
Version: 2.3.0+~0.3.0-3
Severity: important
Tags: ftbfs patch upstream
X-Debbugs-Cc: y...@debian.org

Hi,

here is a patch that updates AJV schemas. It is compatible with current
node-ajv 6 and node-ajv >= 8

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index e799068..317e5a4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+node-eslint-plugin-eslint-plugin (2.3.0+~0.3.0-4) UNRELEASED; urgency=medium
+
+  * Team upload
+
+ -- Yadd   Tue, 12 Dec 2023 09:38:42 +0400
+
 node-eslint-plugin-eslint-plugin (2.3.0+~0.3.0-3) unstable; urgency=medium
 
   * add patch cherry-picked upstream
diff --git a/debian/patches/2006_prepare-for-ajv-8.patch 
b/debian/patches/2006_prepare-for-ajv-8.patch
new file mode 100644
index 000..669
--- /dev/null
+++ b/debian/patches/2006_prepare-for-ajv-8.patch
@@ -0,0 +1,27 @@
+Description: prepare for ajv 8
+Author: Yadd 
+Forwarded: no
+Last-Update: 2023-12-12
+
+--- a/lib/rules/meta-property-ordering.js
 b/lib/rules/meta-property-ordering.js
+@@ -21,7 +21,7 @@
+ fixable: 'code',
+ schema: [{
+   type: 'array',
+-  elements: { type: 'string' },
++  items: { type: 'string' },
+ }],
+   },
+ 
+--- a/lib/rules/test-case-property-ordering.js
 b/lib/rules/test-case-property-ordering.js
+@@ -22,7 +22,7 @@
+ fixable: 'code',
+ schema: [{
+   type: 'array',
+-  elements: { type: 'string' },
++  items: { type: 'string' },
+ }],
+   },
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 5eb779a..1de9aa5 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@
 2003_avoid_eslint-config-not-an-aardvark.patch
 2004_avoid_eslint-config-airbnb-base.patch
 2005_no-require-jsdoc.patch
+2006_prepare-for-ajv-8.patch

Bug#1058079: tar: CVE-2023-39804: Incorrectly handled extension attributes in PAX archives can lead to a crash

[Salvatore Bonaccorso]

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

Hi,

The following vulnerability was published for tar.

CVE-2023-39804[0]:
| Incorrectly handled extension attributes in PAX archives can lead to
| a crash


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-39804
https://www.cve.org/CVERecord?id=CVE-2023-39804
[1]  
https://git.savannah.gnu.org/cgit/tar.git/commit/?id=a339f05cd269013fa133d2f148d73f6f7d4247e4
 

Regards,
Salvatore

Bug#1058078: FTBFS: ESLint couldn't find the config "not-an-aardvark/node" to extend from

[Yadd]

Package: node-eslint-plugin-eslint-plugin
Version: 2.3.0+~0.3.0-4
Severity: serious
Tags: ftbfs
Justification: ftbfs

Hi,

when trying to reproduce node-eslint-plugin-eslint-plugin build, sbuild
fails. Below relevant logs:

eslint --format tap Xcomposer
TAP version 13
1..2
ok 1 - /<>/Xcomposer/lib/rule-composer.js
ok 2 - /<>/Xcomposer/tests/lib/rule-composer.js

eslint --format tap . --ignore-pattern '!.*'

Oops! Something went wrong! :(

ESLint: 6.4.0.

ESLint couldn't find the config "not-an-aardvark/node" to extend from. Please 
check that the name of the config is correct.

The config "not-an-aardvark/node" was referenced from the config file in 
"/<>/.pc/2002_avoid_eslint-plugin-self.patch/.eslintrc.yml".

If you still have problems, please stop by https://gitter.im/eslint/eslint to 
chat with the team.

make[1]: *** [debian/rules:38: override_dh_auto_test] Error 2

Bug#1058077: portalocker: lock on NFS mount not working

[Salvatore Bonaccorso]

Source: portalocker
Version: 2.2.1-1
Severity: normal
Tags: upstream
Forwarded: https://github.com/wolph/portalocker/issues/92
X-Debbugs-Cc: car...@debian.org,ald...@ee.ethz.ch

Hi

Locking on NFS mount does not work with portalocker, as a simple
reproducer:

, [ test-lock.py ]
| import portalocker
|
| file = open('/mnt/test.lock', mode='a')
|
| portalocker.lock(file, flags=portalocker.LOCK_SH|portalocker.LOCK_NB)
`

which result in

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/portalocker/portalocker.py", 
line 138, in lock
fcntl.flock(file_.fileno(), flags)
OSError: [Errno 9] Bad file descriptor

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/mnt/./test-lock.py", line 5, in 
portalocker.lock(file, 
flags=portalocker.LOCK_SH|portalocker.LOCK_NB)
  File "/usr/lib/python3/dist-packages/portalocker/portalocker.py", 
line 142, in lock
raise exceptions.LockException(exc_value, fh=file_)
portalocker.exceptions.LockException: [Errno 9] Bad file descriptor

There is nothing specific which can be done in Debian at this point in
time, just filling the report referencing to the respective upstream
issue, so it can be fixed downstream as well.

Regards,
Salvatore

Bug#1057364: mate-panel: weather report broken in clock/weather applet in bookworm

[okgomdjgbmoij]

the fix was pushed with the latest point release

On 04/12/2023 01:14, mike wrote:

Package: mate-panel
Version: 1.27.0-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: okgomdjgbm...@gmail.com

Dear Maintainer,

like the title says.

It would be nice to backport the fix.

-- 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/2 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mate-panel depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9+deb12u3
ii  libcairo21.16.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libgtk-layer-shell0  0.8.0-1
ii  libice6  2:1.0.10-1
ii  libmate-desktop-2-17 1.26.0-2
ii  libmate-menu21.26.0-3
ii  libmate-panel-applet-4-1 1.27.0-1
ii  libmateweather1  1.26.0-1.1
ii  libpango-1.0-0   1.50.12+ds-1
ii  librda0  0.0.5-1.1
ii  libsm6   2:1.2.3-1
ii  libwayland-client0   1.21.0-1
ii  libwnck-3-0  43.0-3
ii  libx11-6 2:1.8.4-2+deb12u2
ii  libxrandr2   2:1.5.2-2+b1
ii  mate-desktop 1.26.0-2
ii  mate-menus   1.26.0-3
ii  mate-panel-common1.27.0-1
ii  mate-polkit  1.26.1-3

mate-panel recommends no packages.

mate-panel suggests no packages.

-- no debconf information

Bug#1039736: ledger print creates invalid syntax

[Martin Michlmayr]

* Helmut Grohne  [2023-06-28 20:40]:
> $ printf "bucket X\n/11/11 c\n  Y  1\n" | ledger -f - print
> /11/11 c
> Y  1

Alexis pointed out that this is the same as 
https://github.com/ledger/ledger/issues/604

Note that there are a lot of bugs about `print` creating invalid
syntax (see below).

Some of them can be avoided with `print --raw` (but unfortunately not
this one).

Some related bugs:
https://github.com/ledger/ledger/issues/1768
https://github.com/ledger/ledger/issues/1974
https://github.com/ledger/ledger/issues/2100
https://github.com/ledger/ledger/issues/1033
https://github.com/ledger/ledger/issues/1212

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#1058076: openjdk-17-jdk: Fix original file

[Landon Smith]

Package: openjdk-17-jdk
Version: 17.0.9+9-2
Followup-For: Bug #1058076
X-Debbugs-Cc: pleat_00_quo...@icloud.com

Dear Maintainer,

Is there some way I can edit the original report? The file I attatched
accidentally leaked a bunch a private info in the java command line even though
I modified the file to remove that info. Thanks!


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

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

Versions of packages openjdk-17-jdk depends on:
ii  libc62.37-12
ii  openjdk-17-jdk-headless  17.0.9+9-2
ii  openjdk-17-jre   17.0.9+9-2
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages openjdk-17-jdk recommends:
ii  libxt-dev  1:1.2.1-1.1

Versions of packages openjdk-17-jdk suggests:
pn  openjdk-17-demo
pn  openjdk-17-source  
pn  visualvm   

-- no debconf information

Bug#1057969: linux-image-6.1.0-15-amd64: suspend/resume broken in 6.1.66 on Lenovo Thinkpad X230

[Steve VanDevender]

Salvatore Bonaccorso writes:
 > Control: tags -1 + moreinfo
 > 
 > Hi Steve,
 > 
 > On Sun, Dec 10, 2023 at 07:41:15PM -0800, Steve VanDevender wrote:
 > > Package: src:linux
 > > Version: 6.1.66-1
 > > Severity: grave
 > > Tags: upstream
 > > Justification: renders package unusable
 > > 
 > > I would have tried to report this from the 6.1.66 kernel but once a
 > > suspend is attempted network access is also broken so I have had to
 > > reboot into a working kernel in order to report the bug.
 > > 
 > > The problem may be related to the wireless network drivers since some
 > > processes that can't be frozen for suspend are NetworkManager,
 > > wpa-supplicant, and iw.
 > > 
 > > I have included boot messages from the affected kernel through an
 > > attempt to suspend the system including the traces from the processes
 > > that seem to get wedged by an attempt to suspend.
 >
 > I cannot test for the regression explicitly myself, but 6.1.67 was
 > released with just db46c77f3d51 ("Revert "wifi: cfg80211: fix CQM for
 > non-range use""). Would you be in the position of do a test build with
 > that commit (or with 6.1.67 upstream) to verify your issue goes away?

I was able to build a test kernel from the Debian sources for 6.1.66
and the patch from 6.1.67 (thanks to Diederik's instructions) and
install it on my laptop and it does solve the problem with
suspend/resume.

I did forget to include that this problem must have been introduced
after 6.1.64 (which I ran for a few days) since that kernel version
did not have the suspend/resume problem.  But the commit reverted in
6.1.67 was clearly the cause of the problem.

 > Regards,
 > Salvatore

Bug#1054015: ckb-next: diff for NMU version 0.6.0+dfsg-0.2

[Chris Hofstaedtler]

Control: tags 1054015 + pending


Dear maintainer,

I've prepared an NMU for ckb-next (versioned as 0.6.0+dfsg-0.2) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

This applies the same treatment to the udev install path.

Chris

diff -Nru ckb-next-0.6.0+dfsg/debian/changelog ckb-next-0.6.0+dfsg/debian/changelog
--- ckb-next-0.6.0+dfsg/debian/changelog	2023-07-12 11:27:30.0 +0200
+++ ckb-next-0.6.0+dfsg/debian/changelog	2023-12-12 02:58:13.0 +0100
@@ -1,3 +1,13 @@
+ckb-next (0.6.0+dfsg-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Let udev.pc decide where to install rules to.
+
+  [ Helmut Grohne ]
+  * Let systemd.pc decide where to install units to. (Closes: #1054015)
+
+ -- Chris Hofstaedtler   Tue, 12 Dec 2023 02:58:13 +0100
+
 ckb-next (0.6.0+dfsg-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru ckb-next-0.6.0+dfsg/debian/control ckb-next-0.6.0+dfsg/debian/control
--- ckb-next-0.6.0+dfsg/debian/control	2023-07-12 11:27:30.0 +0200
+++ ckb-next-0.6.0+dfsg/debian/control	2023-12-12 02:58:13.0 +0100
@@ -12,6 +12,8 @@
libxcb-ewmh-dev,
libxcb-screensaver0-dev,
libxcb1-dev,
+   pkgconf,
+   systemd-dev,
qtbase5-dev (>= 5.5.1),
qttools5-dev,
zlib1g-dev
diff -Nru ckb-next-0.6.0+dfsg/debian/rules ckb-next-0.6.0+dfsg/debian/rules
--- ckb-next-0.6.0+dfsg/debian/rules	2023-07-12 11:27:30.0 +0200
+++ ckb-next-0.6.0+dfsg/debian/rules	2023-12-12 02:58:13.0 +0100
@@ -19,6 +19,7 @@
 override_dh_auto_configure:
 	dh_auto_configure -- \
 		-DCMAKE_INSTALL_LIBEXECDIR=lib/$(DEB_HOST_MULTIARCH) \
-		-DSYSTEMD_UNIT_INSTALL_DIR=/lib/systemd/system \
+		-DSYSTEMD_UNIT_INSTALL_DIR=$(shell pkgconf --variable=systemdsystemunitdir systemd) \
+		-DUDEV_RULE_DIRECTORY=$(shell pkgconf --variable=udevdir udev)/rules.d \
 		-DDISABLE_UPDATER=ON \
 		-DFORCE_INIT_SYSTEM='systemd;sysvinit'

Bug#1058074: rust-hyper-rustls - autopkgtest failure

[Peter Green]

Package: rust-hyper-rustls
Version: 0.24.2-1
Severity: serious
Tags: patch

The autopkgtest for rust-hyper-rustls is failing, because the code in
test_alpn_http2 requires a runtime, but the feature requirements for
the test do not specify one.

A debdiff fixing this is attatched.diff -Nru rust-hyper-rustls-0.24.2/debian/changelog 
rust-hyper-rustls-0.24.2/debian/changelog
--- rust-hyper-rustls-0.24.2/debian/changelog   2023-12-02 20:25:28.0 
+
+++ rust-hyper-rustls-0.24.2/debian/changelog   2023-12-12 01:18:39.0 
+
@@ -1,3 +1,11 @@
+rust-hyper-rustls (0.24.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix feature requirements for test_alpn_http to prevent autopkgtest
+failure.
+
+ -- Peter Michael Green   Tue, 12 Dec 2023 01:18:39 +
+
 rust-hyper-rustls (0.24.2-1) unstable; urgency=medium
 
   * unfuzz patches
diff -Nru 
rust-hyper-rustls-0.24.2/debian/patches/1002_test-requires-runtime.patch 
rust-hyper-rustls-0.24.2/debian/patches/1002_test-requires-runtime.patch
--- rust-hyper-rustls-0.24.2/debian/patches/1002_test-requires-runtime.patch
1970-01-01 00:00:00.0 +
+++ rust-hyper-rustls-0.24.2/debian/patches/1002_test-requires-runtime.patch
2023-12-12 01:18:17.0 +
@@ -0,0 +1,20 @@
+Description: tests_alpn_http2 fails to build if no runtime is enabled
+ Add feature guards so it doesn't cause autopkgtest failure.
+Author: Peter Michael Green 
+Last-Update: 2023-12-12
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+Index: rust-hyper-rustls-0.24.2/src/connector/builder.rs
+===
+--- rust-hyper-rustls-0.24.2.orig/src/connector/builder.rs
 rust-hyper-rustls-0.24.2/src/connector/builder.rs
+@@ -353,7 +353,7 @@ mod tests {
+ }
+ 
+ #[test]
+-#[cfg(all(not(feature = "http1"), feature = "http2"))]
++#[cfg(all(not(feature = "http1"), feature = "http2", any(feature = 
"native-tokio", feature = "tokio-runtime")))]
+ fn test_alpn_http2() {
+ let roots = rustls::RootCertStore::empty();
+ let tls_config = rustls::ClientConfig::builder()
diff -Nru rust-hyper-rustls-0.24.2/debian/patches/series 
rust-hyper-rustls-0.24.2/debian/patches/series
--- rust-hyper-rustls-0.24.2/debian/patches/series  2022-12-06 
11:57:28.0 +
+++ rust-hyper-rustls-0.24.2/debian/patches/series  2023-12-12 
01:16:36.0 +
@@ -1,3 +1,4 @@
 1001_http1.patch
+1002_test-requires-runtime.patch
 2001_webpki-roots.patch
 2004_tests_broken.patch

Bug#1058075: lockdown: RM for trixie?

[Chris Hofstaedtler]

Source: lockdown
Severity: important

Hi,

lockdown missed bullseye and bookworm. It has an rc bug open since at
least 2020.

To me, it appears as if nobody cares about lockdown. Is it worth keeping
it around in unstable?

I would suggest to file an RM bug in a few weeks.

Chris

Bug#1058073: RM: niceshaper -- RoQA; unmaintained; rc-buggy; missed bookworm

[Chris Hofstaedtler]

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

Dear ftpmasters,

please remove niceshaper.
It was removed from testing in 2020, has seen its last upload in 2016,
and since the removal nobody cared about doing anything about the open
rc bug.

Thanks,
Chris

Bug#1058072: linux-image-6.5.0-0.deb12.1-amd64: Backport 6.5 kernel for bookworm is very good

[debian user]

Package: src:linux
Version: 6.5.3-1~bpo12+1
Severity: wishlist
Tags: upstream

Dear Maintainer,

$ uptime
 19:56:14 up 27 days,  8:01,  3 users,  load average: 0.69, 0.49, 0.45

$ apt policy linux-image-6.5.0-0.deb12.1-amd64
linux-image-6.5.0-0.deb12.1-amd64:
  Installed: 6.5.3-1~bpo12+1
  Candidate: 6.5.3-1~bpo12+1
  Version table:
 *** 6.5.3-1~bpo12+1 100
100 /var/lib/dpkg/status

I wish you the the best.  I wish you all the best.

Thanks,
bw

-- Package-specific info:
** Version:
Linux version 6.5.0-0.deb12.1-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.5.3-1~bpo12+1 (2023-10-08)

** Command line:
BOOT_IMAGE=/vmlinuz root=UUID=2c03d937-09c2-4f1f-9d40-4901f2cdd3f0 ro quiet 
splash loglevel=3

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: HP
product_name: HP Laptop 15-ef2xxx
product_version: 
chassis_vendor: HP
chassis_version: Chassis Version
bios_vendor: AMI
bios_version: F.30
board_vendor: HP
board_name: 887A
board_version: 59.22

** Loaded modules:
sr_mod
cdrom
ccm
xpad
ff_memless
rfcomm
cmac
algif_hash
algif_skcipher
af_alg
ipheth
qrtr
bnep
intel_rapl_msr
sunrpc
intel_rapl_common
binfmt_misc
btusb
btrtl
btbcm
nls_ascii
edac_mce_amd
snd_ctl_led
btintel
nls_cp437
snd_hda_codec_realtek
kvm_amd
btmtk
snd_hda_codec_generic
vfat
bluetooth
ledtrig_audio
kvm
snd_hda_codec_hdmi
rtw88_8822ce
fat
snd_hda_intel
rtw88_8822c
irqbypass
sha3_generic
snd_soc_dmic
snd_acp3x_pdm_dma
snd_acp3x_rn
uvcvideo
snd_intel_dspcfg
rtw88_pci
jitterentropy_rng
ghash_clmulni_intel
snd_soc_core
videobuf2_vmalloc
snd_intel_sdw_acpi
rtw88_core
snd_hda_codec
sha512_ssse3
snd_compress
uvc
sha512_generic
snd_hda_core
videobuf2_memops
snd_pci_acp6x
ctr
snd_hwdep
mac80211
videobuf2_v4l2
snd_pci_acp5x
aesni_intel
drbg
hp_wmi
snd_pcm
videodev
libarc4
snd_rn_pci_acp3x
crypto_simd
ansi_cprng
sparse_keymap
snd_timer
snd_acp_config
videobuf2_common
cryptd
ecdh_generic
cfg80211
joydev
sp5100_tco
platform_profile
snd
snd_soc_acpi
apple_mfi_fastcharge
mc
rapl
ecc
wmi_bmof
pcspkr
k10temp
watchdog
rfkill
soundcore
ccp
snd_pci_acp3x
sg
ac
amd_pmc
acpi_tad
hid_multitouch
serio_raw
evdev
msr
parport_pc
ppdev
lp
parport
fuse
loop
efi_pstore
dm_mod
configfs
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
btrfs
blake2b_generic
xor
raid6_pq
libcrc32c
crc32c_generic
sd_mod
ums_realtek
uas
usb_storage
amdgpu
scsi_mod
scsi_common
amdxcp
drm_buddy
gpu_sched
i2c_algo_bit
nvme
drm_suballoc_helper
nvme_core
drm_display_helper
t10_pi
cec
crc64_rocksoft
rc_core
crc64
xhci_pci
drm_ttm_helper
crc_t10dif
xhci_hcd
ttm
hid_generic
crct10dif_generic
usbcore
drm_kms_helper
crct10dif_pclmul
crc32_pclmul
i2c_hid_acpi
video
i2c_hid
drm
crc32c_intel
i2c_piix4
usb_common
crct10dif_common
battery
button
wmi
hid

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne 
Root Complex [1022:1630]
Subsystem: Hewlett-Packard Company Renoir/Cezanne Root Complex 
[103c:887a]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe 
Dummy Host Bridge [1022:1632]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.4 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne 
PCIe GPP Bridge [1022:1634] (prog-if 00 [Normal decode])
Subsystem: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP 
Bridge [1022:1453]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe 
Dummy Host Bridge [1022:1632]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
[1022:790b] (rev 51)
Subsystem: Advanced Micro Devices, Inc. 

Bug#1058071: mirror submission for mirrors.cat.pdx.edu

[Sage Imel]

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

Submission-Type: new
Site: mirrors.cat.pdx.edu
Archive-architecture: amd64 arm64 armhf hurd-amd64 i386 riscv64
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Sage Imel 
Country: US United States
Location: Portland State University, Portland, OR




Trace Url: http://mirrors.cat.pdx.edu/debian/project/trace/
Trace Url: http://mirrors.cat.pdx.edu/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.cat.pdx.edu/debian/project/trace/mirrors.cat.pdx.edu

Bug#1058070: python-cobra: please remove extraneous dependency on deprecated python3-future

[Alexandre Detiste]

Source: python-cobra
Version: 0.26.3-2
Severity: important

Dear Maintainers,

python3-future is buggy and being removed out of Debian.

Your package declares an hardcoded dependency in d/control.

Current /setup.cfg also declare such dependency,
so it's better to first try to update to 0.29.


install_requires = 
appdirs ~=1.4
depinfo ~=1.7
diskcache ~=5.0
future<--


Greetings,

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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1058069: duplicity: please package a new version and drop dependency on python3-future

[Alexandre Detiste]

Source: duplicity
Version: 1.2.2-2
Severity: normal


The python3-future library is being removed from Debian:
it is unmaintained upstream & obsolete
and didn't build with Python 3.12.


duplicity is the top 1 remaining user of python3-future

Please package a new version of duplicity.

Greetings,


> rel.2.1.2 (2023-09-27)
>
> Adjust debian/control and requirements.txt. [Kenneth Loafman]
>
>   Change boto to boto3.
>   Remove python3-future.
>  Fixes #761.


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1057978: Almost removed most of my system

[Jeremy Davis]

(Random Debian user who has used unstable/Sid - sharing my 2c)

Hi Dan,

On 11/12/23 20:40, Tianyu Chen wrote:

On Mon, 11 Dec 2023 15:22:24 +0800 Dan Jacobson  wrote:

Today I out of habit hit RET to the following.
It removed much of my system.
https://www.reddit.com/r/Crostini/comments/alytbc/comment/kcv98ks/
Next time I'll be more careful and not trust it.
I didn't realize how long the list was when I hit RET.
Maybe there should be a second question if the removal list is longer

than 20 packages.

You're using unstable, so you should be more careful with your actions,
especially full-upgrade. If I guessed it right, the reason caused this is
the ongoing transition of python3.12.



Further to Tianyu's note re running unstable, I highly recommend NEVER 
blindly doing a 'full-upgrade' when running Sid!


This[1] seems like a pretty solid workflow giving you the least chance 
of issues.


[1] https://forums.debian.net/viewtopic.php?p=633248#p633248

I ran Sid for a few years myself and there were a number of times that I 
had to pin specific packages to stop breakages (while upgrading as much 
as I could). Removal of important packages/tools/dependencies that would 
lead to a broken state weren't uncommon in my experience.


Whilst I suspect that you could create an apt hook to do what you want 
(i.e. fail/warn if more than x packages are being removed), that still 
won't avoid potential issues. It's not uncommon for packages and their 
dependencies to uploaded at different times - which will cause issues, 
e.g.[2].


[2] https://forums.debian.net/viewtopic.php?t=153857

If you want to be able to run updates blindly without worrying about 
breakages, just use stable. Issues are still possible, just much less 
likely; and when they do occur, almost always less severe (tend to be 
annoying bugs, rather than show stoppers).


I moved back to stable during Bookworm because the cost/benefit of 
running Sid just didn't add up for me (I didn't really need all the 
newer packages, just a few - that I now update via other methods).


If you want to have bleeding edge packages, use Sid - but very 
carefully! If you're not attached to Debian, then a "proper" rolling 
release - that is rolling by design (e.g. Arch) might be a better option 
for you?



Also, this mail list is used for tracking aptitude bugs, not for user
support.


Apologies on the noise...

Cheers,
Jeremy


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058044: miredo: Change default server

[Chris Hofstaedtler]

On Mon, Dec 11, 2023 at 05:30:28PM +0100, Marco Moock wrote:
> The name teredo-debian.remlab.net doesn't resolve anymore as the operator 
> closed down the service.
> teredo-debian.remlab.net can be used instead.

You gave the same server name twice here. Which service could work
nowadays?

C

Bug#1042049: lintian: FTBFS: 3 tests failed

[Richard Lewis]

On Thu, 7 Dec 2023 22:05:29 +1300 Vladimir Petko
 wrote:
> As of today there are more test failures:



> Test Summary Report
> ---
> debian/test-out/eval/checks/documentation/manual/manpage-errors-from-man/generic.t
> debian/test-out/eval/checks/documentation/manual/surplus-manpage/generic.t
> debian/test-out/eval/checks/documentation/manual/manpages-general/generic.t

think these are already fixed in git

> debian/test-out/eval/checks/systemd/kill-mode-none/generic.t
(etc).

This MR fixes these failures:
https://salsa.debian.org/lintian/lintian/-/merge_requests/487

these are all because of usrmerge putting service files in
usr/lib/systemd rather than lib/systemd -- add "usr/" to the message
in the hints file for each

(and updates the description of the tests in CONTRIBUTING.md and
t/recipes/README)

It also includes https://salsa.debian.org/lintian/lintian/-/merge_requests/485

Thanks for considering

Bug#1057959: dhcpcd gets stopped during upgrade but never started again

[Maximilian Engelhardt]

On Montag, 11. Dezember 2023 08:51:36 CET Martin-Éric Racine wrote:
[...]
> 
> Unless I misunderstood, this is due to a change of debhelper behavior
> since compatibility level 10. This leaves me with two possible
> solutions:
> 
> 1) No dh_install option. This will restart after upgrade (default since dh
> 10).
> 
> 2) Add --no-stop-on-upgrade --no-restart-after-upgrade options. This
> will explicitely disable stop and restart actions.
> 
> Maximilian, which one of these two would make the most sense to you?
> 
> Here, I only use the binaries via ifupdown (i.e. only dhcpcd-base), so
> I have no preference.
> 
> Martin-Éric

Hi Martin-Éric,

I think for me both options should work. I guess for maximising uptime it 
would make sense to not restart dhcpcd and if it is important enough (e.g. due  
a security bug) inform the user (e.g. via NEWS) that a manual restart should 
happen as soon as possible.

Now that I think more about it, not stopping and starting automatically is 
probably the better option, because if something goes wrong during the update 
or the update is just stuck at a prompt it could else leave the system without 
network connectivity.
Better that stopping and starting again some time later would probably be just 
doing an restart once (stop and directly start again without delay) if that's 
possible.

Thanks,
Maxi

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

Bug#990913: ausweisapp2: creates config in '~/.config/Unknown Organization'

[Christoph Anton Mitterer]

Hey.

Few weeks ago I've again stumbled over this, and tried to fix it, but
my Qt coding skills are worse than absolutely zero ^^

I did however found e.g. this:
https://gitlab.cs.fau.de/rudis/passt-mac/-/commit/00d4f8fc2c729b1baf723cacd2b5942b032b6784
which seems a commit that fixes a similar problem.

Maybe this helps someone who knows Qt to craft a fix.


I further tried to contact upstream (Ticket: INC-2023-124927) but was
told, that they provide no Linux support:

On Thu, 2023-11-16 at 10:58 +, support.ausweisa...@governikus.de wrote:
> Der Bund stellt aktuell leider keine offiziell unterstützte Version
> der AusweisApp für Linux bereit.
> Diese Entscheidung wurde auf Grundlage der geringen Marktverbreitung
> von Linux und der zusätzlich starken Fragmentierung der Linux-
> Distributionen getroffen.
> 
> ...
> 
> Bitte haben Sie jedoch Verständnis dafür, dass wir (die Governikus
> KG) als mit der Entwicklung der AusweisApp2 beauftragte Firma für den
> Einsatz unter Linux keinen Support leisten können.

and they've close-ignored the ticket right away ^^


Cheers,
Chris.

Bug#1043240: transition: pandas 1.5 -> 2.1

[Rebecca N. Palmer]

On 10/12/2023 20:16, Julian Gilbey wrote:
> [...]I'd be in favour of doing the pandas
> transition now, which will allow Cython 3.0 to move into unstable.

Cython 3 is already in unstable; pandas is currently using cython-legacy.

And yes, my list of packages broken by pandas 2.x is those identified by 
builds and autopkgtests.


On 11/12/2023 17:31, Matthias Klose wrote:

On 11.12.23 08:12, Matthias Klose wrote:
up to the maintainers. But please wait at least until the current 
pandas and numpy migrated to testing, e.g. that the autopkg tests of 
pandas and numpy triggered by python3-defaults pass.


I just nmued pyrle and sorted-nearest, having dependencies on 
cython3-legacy, letting the pyranges autopkg tests fail. Once this 
succeeds, pandas should be able to migrate.


pandas' testing migration is also blocked by its build-dependency on 
python-xarray, and xarray's on python-sparse and cfgrib.


If necessary, pandas can be built without xarray, but this skips some 
tests and probably adds some error messages to the documentation (the 
examples are run at build time).

Bug#1057624: ausweisapp2: new upstream version (and name)

[Christoph Anton Mitterer]

Hey John.


On Wed, 2023-12-06 at 09:17 +0100, John Paul Adrian Glaubitz wrote:
> I am naturally aware of the new release because I am in direct
> contact with
> one of the upstream maintainers. The withheld update to 2.x is
> intentional
> for two reasons.

Ah I see. :-)

Then I wrongly thought you might have missed the new major version,
when I saw that new package versions got released from the old major
branch :-D


> The user interface
> basically now looks like a scaled up phone app on the desktop which I
> consider
> a huge step back.

Yeah,... I don't know why so many people think that smartphone UIs are
the way to go I mean smartphones and their UI style do have their
fixed place in the world, but one cannot really professionally work
with them.


> Overall, there is no urgent need to update to version 2.x right now,
> so I rather
> want to take my time to come up with a proper transition plan with
> the potential
> prospect of a better user interface.

Absolutely fine :-)


How's your contact with upstream? Few week ago I wrote upstream about
that still annoying #
.
But I was told quite quickly in an automated-reply fashion, that there
is no Linux support.


Cheers,
Chris.

Bug#1056461: python-canmatrix's autopkg tests fail with Python 3.12

[IOhannes m zmoelnig]

Source: python-canmatrix
Followup-For: Bug #1056461


This seems to really be a bug in python3-future:


```sh
$ python3-c "import past.builtins"

$ python3.12 -c "import past.builtins"
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/past/builtins/__init__.py", line 54, in 

from past.builtins.misc import (apply, chr, cmp, execfile, intern, oct,
  File "/usr/lib/python3/dist-packages/past/builtins/misc.py", line 45, in 

from imp import reload
ModuleNotFoundError: No module named 'imp'

```
i've therefore reassigned this bug.



Doing a quick check on python-future, it seems that the v0.18.3 release
(available since 2023-01-13) fixes the issue at hand, as it includes


so i wonder, why we still ship 0.18.2

(i see that andreas has updated the package to 0.18.2 *today* :-))

cheers,
gfmdsa
IOhannes

Bug#1033482: also here

[Alberto Garcia]

Control: fixed -1 1.0.128+nmu2+deb12u1

On Thu, Dec 07, 2023 at 10:23:59AM +0100, Paolo Greppi wrote:

> Alberto's workaround (sudo apt install -t bookworm-backports
> debootstrap) worked for me.

This is working fine with the new version of debootstrap in bookworm,
i.e version 1.0.128+nmu2+deb12u1 from Debian 12.4

Berto

Bug#1057959: dhcpcd gets stopped during upgrade but never started again

[Jeremy Davis]

Just a random Debian user passerby; chiming in with my 2c...

On 11/12/23 18:51, Martin-Éric Racine wrote:

[...] This leaves me with two possible
solutions:

1) No dh_install option. This will restart after upgrade (default since dh 10).



Assuming that I understand correctly (this option will start/restart 
dhcp post install - i.e. in postinst) then I think this would be the 
preferred path wouldn't it?



2) Add --no-stop-on-upgrade --no-restart-after-upgrade options. This
will explicitely disable stop and restart actions.


Perhaps I'm missing something, but if the dhcpd binary is updated, don't 
we need to restart the service to ensure that we're using the updated 
binary?


In the case of a security update to dhcpd, wouldn't this leave the 
vulnerable service running until next reboot and/or manual service restart?




In summary; option 1 seems like the "correct" path to me. But perhaps 
I'm missing something?


Regardless, thanks for your work on Debian. All you awesome volunteers 
rock! :)


Cheers,
Jeremy


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058068: libcdb-dev: libcdb.pc went missing

[Chris Hofstaedtler]

Package: libcdb-dev
Version: 0.80-3
Severity: important
Control: affects -1 src:pdns

Hey,

libcdb-dev in stable ships libcdb.pc. The version in sid is missing this
file.

Given it still exists in the source package and stuff happens to it in
d/rules, I assume it should also be installed.

Thanks,
Chris

Bug#1058067: Mimedefang's relay_is_blacklisted_multi removes the wrong filedescriptor from its IO::Select set resulting in SERVFAIL

[Alain Knaff]

Package: mimedefang
Version: 3.3-1

Hi,

relay_is_blacklisted_multi sends out its multiple DNS requests at once,
and then uses IO::Select to wait for the various answers as they come in.

It has a loop in which it intends to remove each socket from the
IO::Select set as soon as it is done with it (i.e. received and
processed the answer).

However, it accidentally removes the wrong socket: $sock instead of $rsock.

$sock is a now useless variable from a previous loop (should have been
"my" to that loop), which just happens to be the highest socket of the set.

The result of this issue is that that last socket is dropped from the
set, even if it hasn't received an answer, meaning that if this socket
isn't the first one to receive an answer, its answer will never be
processed, resulting in a SERVFAIL on that query.

Here is a patch:

--- ./usr/share/perl5/Mail/MIMEDefang/Net.pm2023-01-30
18:00:55.0 +0100
+++ /usr/share/perl5/Mail/MIMEDefang/Net.pm 2023-11-20
11:54:23.448414007 +0100
@@ -386,7 +386,7 @@
 @ready = $sel->can_read($expire);
 foreach my $rsock (@ready) {
   my $pack = $res->bgread($rsock);
-  $sel->remove($sock);
+  $sel->remove($rsock);
   my $sdomain = $sock_to_domain{$rsock};
   undef($rsock);
   my($rr, $rcode);


Btw, this issue no longer exists in the most recent upstream version

Thanks,

Alain

Bug#1058066: sponsorship-requests: Request sponsored upload for mini-httpd_1.30-6

[Alexandru Mihail]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "mini-httpd":

 * Package name : mini-httpd
   Version  : 1.30-6
   Upstream contact : Jef Poskanzer j...@mail.acme.com
 * URL  : https://www.acme.com/software/mini_httpd/
 * License  : BSD-2-clause
 * Vcs  : https://salsa.debian.org/debian/mini-httpd.git

The source builds the following binary packages:

  mini-httpd_1.30-6_arch.deb

For more information please see
https://salsa.debian.org/debian/mini-httpd.git
and 
https://salsa.debian.org/debian/mini-httpd/-/tags/debian%2F1.30-6


Changes since the last upload:

mini-httpd (1.30-6) unstable; urgency=medium

  * Modified 0003-fix-change-index-document-root and
0005-cgi-php to push index.mini-httpd.html to the end of known
index.* array, modified install script to copy the provided 
index.html into /var/www/html/index.html,
if not present (Closes: #1057842)
  * Moved package provided index.html file to
/usr/share/doc/mini-httpd/examples, to avoid lintian warning  
regarding doc location


Regards,
Alexandru Mihail
mini-httpd maintainer



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

Bug#1058065: Acknowledgement (pyxnat: please remove extraneous depedency on python3-future)

[Alexandre Detiste]

control: tag -1 +patch

I'm checking the code in my previous fork !

So this PR first need to be applied.
 https://github.com/pyxnat/pyxnat/pull/179

This can be used as a temporary patch

Bug#1058038: texlive-extra: Blocker bug

[Preuße]

On 11.12.2023 21:30, Chris Hofstaedtler wrote:

On Mon, Dec 11, 2023 at 02:57:35PM +, Hilmar Preusse wrote:


Hi,


Severity: normal



This bug blocks the migration for now, I'll close
it, once the other two packages tend to migrate.


Pretty sure severity: normal does not block => raising.

Thanks for pointing that out. reportbug must have have downgraded my bug 
b/c I did not specify justification for "serious".


H.
--
sigfault



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057693: valgrind: i386 vex x86->IR: unhandled instruction bytes: 0x2E 0x8D 0xB4 0x26

[Felix Geyer]

On Fri, 8 Dec 2023 15:48:27 +0100 Emanuele Rocca  wrote:
> Hi Simon,
>
> On 2023-12-07 08:39, Simon Josefsson wrote:
> > During debci autopkgtest of a new version of libgssglue on i386 I got
> > a failure like this, which is fatal and execution halts.
> >
> > 117s vex x86->IR: unhandled instruction bytes: 0x2E 0x8D 0xB4 0x26
>
> The problem can be reproduced with valgrind 3.19 as well:
>
> $ autopkgtest --shell-fail libgssglue_0.8-1.dsc ~/Downloads/valgrind_3.19.0-1_i386.deb -- 
schroot sid-i386-sbuild

>
> [...]
>
> (sid-i386-sbuild)root@ariel:/tmp/autopkgtest.lmoplT/build.hLF/src# valgrind /usr/bin/gsasl 2>&1 
| grep ^vex

> vex x86->IR: unhandled instruction bytes: 0x2E 0x8D 0xB4 0x26
> (sid-i386-sbuild)root@ariel:/tmp/autopkgtest.lmoplT/build.hLF/src# valgrind 
--version
> valgrind-3.19.0

I'm pretty sure this is caused by glibc 2.37-13

valgrind's own testsuite fails with that version on i386:
https://ci.debian.net/packages/v/valgrind/testing/i386/40850077/

#1057428 is a similar report and there are more autopkgtest failures on
https://qa.debian.org/excuses.php?package=glibc

Cheers,
Felix

Bug#1000112: kjs: depends on obsolete pcre3 library

[Bastian Germann]

okular and khelpcenter make kjs a key package via khtml.
While it is optional in okular, khelpcenter requires khtml.
This is changing with the 24.08.x versions, which will be part of Plasma 6.
When khelpcenter upgrades to a khtml-free version, this should be followed-up.

Bug#1058065: pyxnat: please remove extraneous depedency on python3-future

[Alexandre Detiste]

Source: pyxnat
Severity: normal

Dear Maintainers,

python3-future is being removed from Debian.

The current sources still contain stales references to "future".

These have been removed upstream since,
so any new release would also fix the problem.

Greetings


$ grep future -r
setup.py:   'future>=0.16'],
requirements.txt:future>=0.16
requirements-dev.txt:future>=0.16


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1056126: closed by Debian FTP Masters (reply to Sylvestre Ledru ) (Bug#1056126: fixed in llvm-toolchain-17 1:17.0.6-1)

[Norbert Lange]

Well, its fixed, but why libclang-17.so.17 was used instead of libclang-17.so.1?
there is already libLLVM-17.so.1, so this is a pretty unique scheme,
which I haven't seen elsewhere.

Am Mi., 29. Nov. 2023 um 12:09 Uhr schrieb Debian Bug Tracking System
:
>
> This is an automatic notification regarding your Bug report
> which was filed against the libclang1-17 package:
>
> #1056126: libclang1-17: libclang-17.so.1 uses wrong SONAME
>
> It has been closed by Debian FTP Masters  
> (reply to Sylvestre Ledru ).
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters 
>  (reply to Sylvestre Ledru 
> ) by
> replying to this email.
>
>
> --
> 1056126: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056126
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 1056126-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Wed, 29 Nov 2023 11:04:09 +
> Subject: Bug#1056126: fixed in llvm-toolchain-17 1:17.0.6-1
> Source: llvm-toolchain-17
> Source-Version: 1:17.0.6-1
> Done: Sylvestre Ledru 
>
> We believe that the bug you reported is fixed in the latest version of
> llvm-toolchain-17, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 1056...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Sylvestre Ledru  (supplier of updated llvm-toolchain-17 
> package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Tue, 28 Nov 2023 11:43:43 +0100
> Source: llvm-toolchain-17
> Architecture: source
> Version: 1:17.0.6-1
> Distribution: unstable
> Urgency: medium
> Maintainer: LLVM Packaging Team 
> Changed-By: Sylvestre Ledru 
> Closes: 1056126 1056580
> Changes:
>  llvm-toolchain-17 (1:17.0.6-1) unstable; urgency=medium
>  .
>[ Matthias Klose ]
>* Further limit the number of parallel processes
>* Don't build-depend on llvm-spirv-17 on armel and mipsel (LLVM 17 is not
>  yet built on these architectures).
>* Fix stripping build flags on Ubuntu/ppc64el.
>* libclang1-17: Only encode the major version in the soname. Closes: 
> #1056126.
>* libclang1-17: Provide a symlink for the last soname with the full 
> version.
>* Restore the patch for D148945, searching /usr/lib/llvm-17/lib by default.
>  Closes: #1056580.
>  .
>[ Sylvestre Ledru ]
>* New upstream release
>* Add a symlink for libc++experimental.a to /usr/lib/*/libc++experimental.a
>  to fix https://github.com/llvm/llvm-project/issues/72753
>* try to relax the wasi-libc dep declaration for apt.llvm.org
>* add a check that, if we are going to build wasm, wasi-libc is installed
>  on the system
>  .
>[ John Paul Adrian Glaubitz ]
>* Don't install *clang_rt* on sparc and sparc64
> Checksums-Sha1:
>  a3450ba385c7ccfb083e14d989fede733ce53c3b 8059 llvm-toolchain-17_17.0.6-1.dsc
>  87dbe5554a6f3e070c6e99771c9084db4cecc132 148234752 
> llvm-toolchain-17_17.0.6.orig.tar.xz
>  d51aeac61ef5fcde54b2f9a7de688b18f70d3b0b 170576 
> llvm-toolchain-17_17.0.6-1.debian.tar.xz
>  41a2ee3d793304d4ef35a80c9ab04a200cdbe1d6 34446 
> llvm-toolchain-17_17.0.6-1_amd64.buildinfo
> Checksums-Sha256:
>  34e3a75d69e5725db857d79592cf5b986bf97e8257bc4fa06d8cd8ceca8b04a4 8059 
> llvm-toolchain-17_17.0.6-1.dsc
>  04c12edc1995d9bb15da30d69f0207dda43b7833eaa989176c099e465cd38aee 148234752 
> llvm-toolchain-17_17.0.6.orig.tar.xz
>  9e813430eb46998cd0e5e4bce44693fb18225dfd6bab4ae7c6d3403d2847be1a 170576 
> llvm-toolchain-17_17.0.6-1.debian.tar.xz
>  c65ceda88a43cc7175d97ff8a41baf67a531d03ed54d1a654bb725be5266f072 34446 
> llvm-toolchain-17_17.0.6-1_amd64.buildinfo
> Files:
>  d7f128fa9f1360b22306386bfbdce8ae 8059 devel optional 
> llvm-toolchain-17_17.0.6-1.dsc
>  c8e30b4d7a52a4535e0a8e98df21c1e6 148234752 devel optional 
> llvm-toolchain-17_17.0.6.orig.tar.xz
>  f63f1d7d8680c2d17d7f0a95924c8179 170576 devel optional 
> llvm-toolchain-17_17.0.6-1.debian.tar.xz
>  6e33c052d4044d67dc052ca883ba74c7 34446 devel optional 
> llvm-toolchain-17_17.0.6-1_amd64.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEtg21mU05vsTRqVzPfmUo2nUvG+EFAmVnEiAACgkQfmUo2nUv
> G+HK6BAAkqLRSXlBOqLp2znV9xP2LYnybsIZE78/sWYK+l70dGQ9aAEYU7JW9Ql5
> DtzUZzBKrluYaxnkoFepTIsxDcvjfq3LHEGIqs5v5IfcMVTDAHBRFdV3mPAcYna9
> mp3ulK7kk192sVHBnh7dBX6S/DqxYfMZFJxQMUKAsczCU8eOevglW6C1CFF/CgC0
> 

Bug#1057856: glibc: mktime now returns clock for UTC with isdst=1

[Paulo Tomé]

Hello,

Thank you for the quick answer and the details provided.

You can submit the test program to the upstream bugzilla, no problem.

Best regards,
Paulo Tomé

On Mon, Dec 11, 2023 at 9:36 PM Aurelien Jarno  wrote:

> Hi,
>
> On 2023-12-09 18:23, Paulo Tomé wrote:
> > Package: libc6
> > Version: 2.36-9+deb12u3
> > Severity: normal
> > Tags: upstream
> > X-Debbugs-Cc: paulo.t...@gmail.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 ***
> >
> > After compiling Erlang from source (erlang.org) a test case failed. The
> > test case detects if local time is converted correctly to universal time
> > even if isdst=1 for the UTC timezone. The following issue reports the
> > details: https://github.com/erlang/otp/issues/7938
> >
> > I created a small test program that reproduces the behavior. The program
> > calls mktime for a certain date, with isdst=1 in the tm struct.
>
> Thanks for the details and for the reproducer, that's very helpful.
>
> > When setting TZ=UTC in the environment, mktime returns a valid clock
> > offset by one hour. In previous versions of glibc (tested 2.35 on Ubuntu
> > LTS 22.04.3) the same call to mktime returns -1. The error (-1) makes
> > sense, since the UTC timezone does not have DST.
> >
> > After downloading the Debian glibc-source for 2.36, I see a patch that
> > could explain this behavior.
> >
> > /usr/src/glibc/debian/patches/git-updates.diff
> >
> > +  /* No unusual DST offset was found nearby.  Assume one-hour DST.
> */
> > +  t += 60 * 60 * dst_difference;
> > +  if (mktime_min <= t && t <= mktime_max && convert_time (convert,
> t, ))
> > +   goto offset_found;
> > +
> >__set_errno (EOVERFLOW);
> >return -1;
> >  }
> >
> > This change was not present on the other glibc I tested (2.35 on
> > Ubuntu). I checked upstream glibc 2.38 and the change is in the source.
>
> Yes, I confirm this changes explains the behaviour you are observing. It
> comes from the following upstream commit, which has been introduced in
> the 2.37 release and backported in the 2.34, 2.35 and 2.36 upstream
> stable trees:
>
>
> https://sourceware.org/git/?p=glibc.git;a=commit;h=83859e1115269cf56d21669361d4ddbe2687831c
>
> > I'm not sure if this is a bug, but for the UTC timezone I would expect
> > an error if we asked for the time with DST.
>
> This not clear to me if it is a bug or not. Quoting the standard (ISO C
> or POSIX):
>
>   A positive or 0 value for tm_isdst shall cause mktime() to presume
>   initially that Daylight Savings Time, respectively, is or is not in
>   effect for the specified time. A negative value for tm_isdst shall
>   cause mktime() to attempt to determine whether Daylight Savings Time
>   is in effect for the specified time.
>
> The word "presume initially" looks like an initial guess should be
> provided (for disambiguating two identical dates), but it doesn't
> enforce the result.
>
> That said, looking at the FreeBSD libc implementation, it seems the
> original glibc behaviour is the correct one. The best is probably to
> report the issue upstream.
>
> > For reference, this is the test program:
>
> Thanks. Do you mind if I submit your test program to the upstream
> bugzilla? Or do you prefer to submit the bug yourself?
>
> Regards
> Aurelien
>
> --
> Aurelien Jarno  GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://aurel32.net
>

Bug#1058063: Fwd: postgresql-15 package missing on Stable

[Jiachen Meng]

Hi Christoph,

Thanks for the quick response! We tried it again with the following inside
a Dockerfile:

FROM debian:bookworm-slim
RUN apt-get clean && apt-get update && apt-get install -y
--no-install-recommends libpq-dev=15.5-0+deb12u1
postgresql-client-15=15.5-0+deb12u1

And we get the following error:

4.786 Fetched 16.6 MB in 1s (11.4 MB/s)
4.786 E: Failed to fetch
http://deb.debian.org/debian/pool/main/p/perl/libperl5.36_5.36.0-7%2bdeb12u1_amd64.deb
 Hash Sum mismatch
4.786Hashes of expected file:
4.786 -
SHA256:4b48b8f0b06c2c667d52117edcef69af6896bcfe69a4f4bde47b89590b83875e
4.786 - MD5Sum:425c1a1ba4ab0afb863a9793c5bfc5a4 [weak]
4.786 - Filesize:4217504 [weak]
4.786Hashes of received file:
4.786 -
SHA256:e9a39c08d7c6b5559b80d3c48bd6b8f3ecdf5cb959f378f0d25f4b8a72fc4142
4.786 - MD5Sum:94403405a5e7bf25b22e96a4367e3495 [weak]
4.786 - Filesize:4217504 [weak]
4.786Last modification reported: Thu, 30 Nov 2023 05:56:53 +
4.786 E: Unable to fetch some archives, maybe run apt-get update or try
with --fix-missing?

Seems the similar error is also happening with another package (so maybe
it's beyond the postgresql) but wanted to update you on it. Thanks a lot!

Best,
JM

On Mon, Dec 11, 2023 at 3:58 PM Christoph Berg  wrote:

> Re: Jiachen Meng
> > #12 3.627 E: Version '15.3-0+deb12u1' for 'postgresql-client-15' was not
> > found
> >
> > The command was:  apt-get install -y --no-install-recommends
> > postgresql-client-15=15.3-0+deb12u1
>
> Hi,
>
> the current version is 15.5-0+deb12u1.
>
> > Also on the package tracker page it says "package is gone":
> > https://tracker.debian.org/pkg/postgresql-15.
>
> Tracker tracks unstable, that's developer information.
> End users should refer to
> https://packages.debian.org/bookworm/postgresql-15
>
> Christoph
>

Bug#1050015: okular: Drop khtml and kjs

[Bastian Germann]

Control: forwarded -1 https://phabricator.kde.org/T11539

On Fri, 18 Aug 2023 14:26:46 +0200 Sune Stolborg Vuorela  
wrote:

Note that okular 23.08 has migrated away from kjs.


libkf5kjs-dev is ist in Build-Depends. Please drop it with your next upload.

Before end of the year, upstream will also have likely have a plan on what to 
do with khtml.


I have forwarded this bug to the upstream issue.

Bug#1057856: glibc: mktime now returns clock for UTC with isdst=1

[Aurelien Jarno]

Hi,

On 2023-12-09 18:23, Paulo Tomé wrote:
> Package: libc6
> Version: 2.36-9+deb12u3
> Severity: normal
> Tags: upstream
> X-Debbugs-Cc: paulo.t...@gmail.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 ***
> 
> After compiling Erlang from source (erlang.org) a test case failed. The
> test case detects if local time is converted correctly to universal time
> even if isdst=1 for the UTC timezone. The following issue reports the
> details: https://github.com/erlang/otp/issues/7938
> 
> I created a small test program that reproduces the behavior. The program
> calls mktime for a certain date, with isdst=1 in the tm struct.

Thanks for the details and for the reproducer, that's very helpful. 

> When setting TZ=UTC in the environment, mktime returns a valid clock
> offset by one hour. In previous versions of glibc (tested 2.35 on Ubuntu
> LTS 22.04.3) the same call to mktime returns -1. The error (-1) makes
> sense, since the UTC timezone does not have DST.
> 
> After downloading the Debian glibc-source for 2.36, I see a patch that
> could explain this behavior.
> 
> /usr/src/glibc/debian/patches/git-updates.diff
> 
> +  /* No unusual DST offset was found nearby.  Assume one-hour DST.  */
> +  t += 60 * 60 * dst_difference;
> +  if (mktime_min <= t && t <= mktime_max && convert_time (convert, t, 
> ))
> +   goto offset_found;
> +
>__set_errno (EOVERFLOW);
>return -1;
>  }
> 
> This change was not present on the other glibc I tested (2.35 on
> Ubuntu). I checked upstream glibc 2.38 and the change is in the source.

Yes, I confirm this changes explains the behaviour you are observing. It
comes from the following upstream commit, which has been introduced in
the 2.37 release and backported in the 2.34, 2.35 and 2.36 upstream
stable trees:

https://sourceware.org/git/?p=glibc.git;a=commit;h=83859e1115269cf56d21669361d4ddbe2687831c

> I'm not sure if this is a bug, but for the UTC timezone I would expect
> an error if we asked for the time with DST.

This not clear to me if it is a bug or not. Quoting the standard (ISO C
or POSIX):

  A positive or 0 value for tm_isdst shall cause mktime() to presume
  initially that Daylight Savings Time, respectively, is or is not in
  effect for the specified time. A negative value for tm_isdst shall
  cause mktime() to attempt to determine whether Daylight Savings Time
  is in effect for the specified time.

The word "presume initially" looks like an initial guess should be
provided (for disambiguating two identical dates), but it doesn't
enforce the result.

That said, looking at the FreeBSD libc implementation, it seems the
original glibc behaviour is the correct one. The best is probably to
report the issue upstream.

> For reference, this is the test program:
 
Thanks. Do you mind if I submit your test program to the upstream
bugzilla? Or do you prefer to submit the bug yourself?

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1056440: pyopengl's autopkg tests fail with Python 3.12

[Sebastiaan Couwenberg]

Control: block -1 by 1058031

This seems to be fixed upstream:

 https://github.com/mcfletch/pyopengl/issues/99

The pyopengl test suite fails because pygame FTBFS with Python 3.12 
(#1058031) this likely also affects the autopkgtest.


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

Bug#910664: Acknowledgement (ghc: ghc package can no longer be cross-compiled)

[Helmut Grohne]

Hi Ilias,

On Mon, Dec 11, 2023 at 10:08:49PM +0200, Ilias Tsitsimpis wrote:
> On Sun, Dec 10, 2023 at 09:01PM, Helmut Grohne wrote:
> > First and foremost, ghc now actively refuses being cross build with an
> > $(error ...). Would you mind weakening this to a $(warning ...)? While
> > that you don't want to support cross building of ghc, would you mind
> > others (like me) supporting it? Yes, it would still fail, but then
> > https://crossqa.debian.net/src/ghc could show a more useful reason for
> > that failure.
> 
> The reason I have this as an $(error ...) is because the new Hadrian
> build system doesn't support cross-compiling GHC [1]. This is not a
> limitation of our Debianization (i.e., it's not that we refuse to
> cross-build GHC, we *cannot* cross-build GHC), this is upstream
> limitation. Given that, I believe $(error ...) is more appropriate here
> than $(warning ...).
> 
> [1] https://gitlab.haskell.org/ghc/ghc/-/issues/23975

I'm not yet entirely convinced that it cannot work, but I certainly
agree that it does not work now. However, the $(error ...) completely
hides the reason. I'd like to see a cross build failure that shows why
this cannot work and that failure only comes about much later. What
advantage do you see in hiding this failure from QA systems?

> The resulting stage1 tools are a cross-compiler, not the final
> cross-compiled binaries (this is why they are prefixed with the host gnu
> triplet). I am not sure how we will handle this, I am waiting to see on
> what upstream will do to support cross-building GHC. For now, I believe
> applying the attached patch doesn't help.

To me, this looks fairly obvious. The stage1 tools are not installed
into any .deb at any time. What we install into a .deb is the stage2.
All that we need stage1 for is running it during build. This is where my
patch helps. And quite objectively, the patch helps in the sense that
the build goes further once you apply it.

> GHC does *not* use the same terminology as Debian. GHC requires that
> HOST and BUILD are the same. You can read more about this here [2],
> though keep in mind this document is severely outdated with the Hadrian
> build system.
> 
> [2] 
> https://gitlab.haskell.org/ghc/ghc/-/wikis/building/cross-compiling#terminology-and-background

That page carefully explains that it uses the same terminology as
Debian. It also says that host and build must equal which translates to
"cross compilation is not supported at all", because the definition of a
cross build is build and host being different from one another.

However, that page also goes on and says that stage2 is being built
using stage1. Since stage1 is a cross compiler, stage1 runs on the build
machine and hence we are building stage2 on our build machine. And since
stage2 runs on the target, the stage2 build process effectively has
build differ from host contradicting what the page says earlier. So
indeed, something is wrong here. From my pov, the information that most
likely is wrong is that ghc cannot be cross compiled.

> I believe we need to work with upstream to add support for
> cross-compiling GHC to the new Hadrian build system. As explained here [3],
> this is currently not possible. I tested everything I could think of,
> but I don't see how we can move forward without reworking how the
> Hadrian build system works. Upstream has started working on this, but
> it's moving slowly [4].

I agree that we need to work with upstream. However, we also should make
it work on the Debian side as good as possible, but currently it aborts
early saying that this cannot work. Can we move incrementally and enable
as much as works?

> In summary, as a result of the switch to the Hadrian build system, we
> are now unable to cross-compile GHC. Since this issue now has all the
> latest context, I propose we keep it open and work here on
> cross-building GHC.

The Debian build does not get far enough to demonstrate this failure.
Talking to upstream is much easier if you can point them at failing
build logs and we currently cannot, because we are still facing issues
before even running Hadrian.

Regarding that --build flag, I now see that we actually run configure
twice. Connecting what you said earlier, I guess that one of those
invocations is for the stage1 compiler and the second one is for the
stage2 compiler though I may be wrong. If that guess is correct, then
yes, the stage1 compiler definitely needs --host=$(DEB_BUILD_GNU_TYPE),
but doing it like that still passes host architecture compiler flags and
you end up running e.g. aarch64-linux-gnu-gcc -fcf-protection or
x86_64-linux-gnu-gcc -mbranch-protection=standard and fail either way.
So the way to pass that --host flag is:

dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_configure 
--reload-all-buildenv-variables -- $(CONFIGURE_ARGS)
# CONFIGURE_ARGS contains neither --build nor --host, but it contains 
--target

Then when we build stage2, we are using stage1 and there we probably

Bug#1058064: yaz FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: yaz
Version: 5.34.0-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

yaz fails to cross build from source, because it hard codes the build
architecture pkg-config in two occasions. It thus fails finding the
relevant .pc files and fails. I'm attaching a patch for your
convenience.

Helmut
--- yaz-5.34.0.orig/m4/ac_check_icu.m4
+++ yaz-5.34.0/m4/ac_check_icu.m4
@@ -18,7 +18,7 @@
 	  AC_ARG_WITH(icu,[  --with-icu[=PREFIX]   use ICU libs in PREFIX], icudir=$withval)
 	  if test "$icudir" != "no"; then
 	  if test "$icudir" = "yes" -o "$icudir" = "default"; then
-		  AC_PATH_PROG([pkgconfigpath], [pkg-config], [NONE])
+		  AC_PATH_TOOL([pkgconfigpath], [pkg-config], [NONE])
 		  if test -x $pkgconfigpath; then
 		  AC_MSG_CHECKING([for icu-i18n via pkg-config])
 		  if $pkgconfigpath --exists icu-i18n; then
--- yaz-5.34.0.orig/m4/yaz_libxml2.m4
+++ yaz-5.34.0/m4/yaz_libxml2.m4
@@ -1,5 +1,5 @@
 AC_DEFUN([YAZ_LIBXML2],[
-AC_PATH_PROG([pkgconfigpath], [pkg-config], [NONE])
+AC_PATH_TOOL([pkgconfigpath], [pkg-config], [NONE])
 pkgmodule=""
 xml2dir=default
 XML2_VER=""

Bug#1057967: linux-image-6.1.0-15-amd64 renders my physical bookworm/gnome computer largely unusable

[Kevin Price]

Breaking news:

Am 11.12.23 um 19:14 schrieb Salvatore Bonaccorso:
> I have put binary packages for amd64 built in
> https://people.debian.org/~carnil/tmp/linux/1057967/

I confirm this test kernel is working fine for me, even with non-free
broadcom-sta.

(sent from
"
cat /proc/version

Linux version 6.1.0-0.a.test-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.66-1a~test (2023-12-11)
"

through

"
modinfo wl

filename:   /lib/modules/6.1.0-0.a.test-amd64/updates/dkms/wl.ko
license:MIXED/Proprietary
alias:  pci:v*d*sv*sd*bc02sc80i*
depends:cfg80211
…"
)

Thank you Salvatore. Let's get this into stable soon.
-- 
Kevin Price

Bug#1057783: libc6:amd64.postinst may lack of response for a long time.

[Aurelien Jarno]

Hi,

On 2023-12-08 21:04, ChenPi11 wrote:
> Package: libc6
> Version: 2.37-13
> Severity: normal
> Tags: d-i
> X-Debbugs-Cc: wushengwuxi-msctino...@outlook.com
> 
> Dear Maintainer,
> 
> When apt was configuring the libc6:amd64 after I upgraded all packages, It 
> lack of response for a long time (more than 3 hours).
> Then, I founded that `ischroot` program was blocking the post-install
> script. I think the bug is ischroot's at first. But it ONLY unresponsive here.
> I know the apt is not in chroot, so I removed the command and set
> `TELINIT` to `no`. After I did this, the configure process became
> normaly.

Thanks for the report. It happens that the call to ischroot is essential
to not break the system when executing in a chroot. Therefore we have to
understand why ischroot is hanging.

As the problem is not reproducible here, could you please use strace
with the -p option on the hanging ischroot process to get a better idea
why it hangs?

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net

Bug#1058046: systemd: unable to run fsck at boot

[Alessandro Ogier]

On 12/11/23 20:20, Michael Biebl wrote:

Is expecting a clean "fsck -n -f XXX" run wrong?



Have you tried "fsck.mode=force fsck.repair=yes" as well?


while not suspecting a defect in the manual pages, I tried all 
combinations of yes/auto yes/preen. I have also tried rebooting now with 
these parameters, and I see the same output in the journal.


Tomorrow I'll try to replicate this on some other machine which I have, 
and maybe on a vm if I can figure out how to fake some filesystem error.



Thank you, regards


alessandro

Bug#1058063: postgresql-15 package missing on Stable

[Jiachen Meng]

Package: postgresql-15
Version: 15.5-0+deb12u1

When I try to get the package it reports an error like below:
#12 3.623 Package postgresql-client-15 is not available, but is referred to
by another package.
#12 3.623 This may mean that the package is missing, has been obsoleted, or
#12 3.623 is only available from another source
#12 3.623
#12 3.627 E: Version '15.3-0+deb12u1' for 'postgresql-client-15' was not
found

The command was:  apt-get install -y --no-install-recommends
postgresql-client-15=15.3-0+deb12u1

Also on the package tracker page it says "package is gone":
https://tracker.debian.org/pkg/postgresql-15.

Bug#1058052: linux-image-6.1.0-15-amd64 breaks suspend

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Mon, Dec 11, 2023 at 04:02:16PM -0300, Dr. André Desgualdo Pereira wrote:
> Package: src:linux
> Version: 6.1.66-1
> Severity: important
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>Updating the kernel.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>Booting from an older kernel fix the issue.
>* What was the outcome of this action?
>Bug is fixed by using an older kernel version.
>* What outcome did you expect instead?
>I expect updating the kernel doesn't break functionality.
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- Package-specific info:
> ** Kernel log: boot messages should be attached

Can you please attach the boot logs as well, which might be including
traces we are interested in to better understand the problem?

Regards,
Salvatore

Bug#1042244: Bug#1056419: [Help] Re: python-future: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andreas Tille]

Hi Alexandre,

Am Mon, Dec 11, 2023 at 09:18:16PM +0100 schrieb Alexandre Detiste:
> > https://github.com/lebigot/uncertainties/releases/tag/3.1.7
> 
> +1

OK.
 
> > Also we should probably get rid of python-future at some point.
> 
> I removed it from three games this week-end
> and filled 6 more bugs since to remove extraneous stale dependency.
> 
> There are in fact more fake stale dependencies than remaining true ones
> It takes like 10 minutes to review one package.
> It's a peaceful life.
> 
> https://salsa.debian.org/games-team/ardentryst/-/commit/fc6901b0e90b6bb3ec19b23c1c2d458d653b2d4a
> 
> I will continue this review.

I've seen your bug reports on some Debian Med packages and will try
to fix these as quickly as possible.
 
Thanks a lot for your invesigation and the bug reports
   Andreas.

-- 
http://fam-tille.de

Bug#1058038: texlive-extra: Blocker bug

[Chris Hofstaedtler]

Control: severity -1 serious

On Mon, Dec 11, 2023 at 02:57:35PM +, Hilmar Preusse wrote:
> Severity: normal

> This bug blocks the migration for now, I'll close
> it, once the other two packages tend to migrate.

Pretty sure severity: normal does not block => raising.

C

Bug#1058041: ncurses: breaks `hg histedit` (_curses.error: endwin() returned ERR)

[Thomas Dickey]

On Mon, Dec 11, 2023 at 05:47:23PM +0100, Sven Joachim wrote:
> On 2023-12-11 16:22 +0100, Julien Cristau wrote:
> 
> > Source: ncurses
> > Version: 6.4+20231121-1
> > Severity: important
> > Control: affects -1 mercurial
> > X-Debbugs-Cc: jcris...@debian.org
> >
> > Hi,
> >
> > Since a ncurses upgrade in testing recently `hg histedit` seems to
> > crash consistently, upon trying to apply the changes:
> >
> >> Traceback (most recent call last):
> >>   File "/usr/bin/hg", line 59, in 
> >> dispatch.run()
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 142, 
> >> in run
> >> status = dispatch(req)
> >>  ^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 231, 
> >> in dispatch
> >> status = _rundispatch(req)
> >>  ^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 275, 
> >> in _rundispatch
> >> ret = _runcatch(req) or 0
> >>   ^^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 456, 
> >> in _runcatch
> >> return _callcatch(ui, _runcatchfunc)
> >>^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 466, 
> >> in _callcatch
> >> return scmutil.callcatch(ui, func)
> >>^^^
> >>   File "/usr/lib/python3/dist-packages/mercurial/scmutil.py", line 152, in 
> >> callcatch
> >> return func()
> >>^^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 446, 
> >> in _runcatchfunc
> >> return _dispatch(req)
> >>^^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1271, 
> >> in _dispatch
> >> return runcommand(
> >>^^^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 904, 
> >> in runcommand
> >> ret = _runcommand(ui, options, cmd, d)
> >>   
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1283, 
> >> in _runcommand
> >> return cmdfunc()
> >>^
> >>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1269, 
> >> in 
> >> d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
> >> ^
> >>   File "/usr/lib/python3/dist-packages/mercurial/util.py", line 1878, in 
> >> check
> >> return func(*args, **kwargs)
> >>^
> >>   File "/usr/lib/python3/dist-packages/hgext/histedit.py", line 1918, in 
> >> histedit
> >> return _chistedit(ui, repo, freeargs, opts)
> >>
> >>   File "/usr/lib/python3/dist-packages/hgext/histedit.py", line 1764, in 
> >> _chistedit
> >> curses.endwin()
> >> _curses.error: endwin() returned ERR
> 
> I am not familiar with Mercurial, but most likely this has been
> triggered by the following change in the 2023111 patchlevel:
> 
> ,
> | 2023
> | + modify endwin() to return an error if it is called again without an
> |   intervening screen update (report by Rajeev Pillai, NetBSD #57592).
> `
> 
> NetBSD #57592 is
> https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57592 .

sounds plausible.  fwiw, handling error returns (other than throwing an
exception) is something that developers should do.

I suspect that making ncurses not return error-codes is a step in the wrong
direction.  The example in the NetBSD bug report was clearly a defect in
the application using ncurses.

In this case, I chose to make it behave like SVr4 curses.  Explaining this
nicely in a portability section of the manpage is still on my to-do list,
but it's clear in the note that I made.  NetBSD curses returns no error,
but it's based on some code to handle SIGTSTP.

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

Bug#1058062: python-cloup accesses the network while building the docs

[Matthias Klose]

Package: src:python-cloup
Version: 3.0.3-1
Severity: serious
Tags: sid trixie

python-cloup accesses the network while building the docs:

[...]
[autosummary] generating autosummary for: index.rst, pages/aliases.rst, 
pages/arguments.rst, pages/changelog.rst, pages/constraints.rst, 
pages/contributing.rst, pages/credits.rst, pages/formatting.rst, 
pages/installation.rst, pages/misc.rst, pages/option-groups.rst, 
pages/sections.rst

loading intersphinx inventory from https://docs.python.org/objects.inv...
loading intersphinx inventory from 
https://click.palletsprojects.com/objects.inv...

WARNING: failed to reach any of the inventories with the following issues:
intersphinx inventory 'https://docs.python.org/objects.inv' not 
fetchable due to : 
HTTPSConnectionPool(host='docs.python.org', port=443): Max retries 
exceeded with url: /objects.inv (Caused by ProxyError('Cannot connect to 
proxy.', NewConnectionError('at 0x7ffbe549a4d0>: Failed to establish a new connection: [Errno 111] 
Connection refused')))

WARNING: failed to reach any of the inventories with the following issues:
intersphinx inventory 'https://click.palletsprojects.com/objects.inv' 
not fetchable due to : 
HTTPSConnectionPool(host='click.palletsprojects.com', port=443): Max 
retries exceeded with url: /objects.inv (Caused by ProxyError('Cannot 
connect to proxy.', 
NewConnectionError('0x7ffbe54fcb90>: Failed to establish a new connection: [Errno 111] 
Connection refused')))

building [mo]: targets for 0 po files that are out of date
writing output...
building [html]: targets for 12 source files that are out of date

Bug#1042244: Bug#1056419: [Help] Re: python-future: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Alexandre Detiste]

Le lun. 11 déc. 2023 à 17:02, Jochen Sprickerhof  a écrit :
> I think the right thing here is to package the new uncertainties version
> which drops the past import:
>
> https://github.com/lebigot/uncertainties/releases/tag/3.1.7

+1

> Also we should probably get rid of python-future at some point.

I removed it from three games this week-end
and filled 6 more bugs since to remove extraneous stale dependency.

There are in fact more fake stale dependencies than remaining true ones
It takes like 10 minutes to review one package.
It's a peaceful life.

https://salsa.debian.org/games-team/ardentryst/-/commit/fc6901b0e90b6bb3ec19b23c1c2d458d653b2d4a

I will continue this review.

The existing bugs can be tagged someway if that helps.

Greetings


python3-gnocchi  0
python3-mir-eval 1
dioptas  2
python3-bioxtasraw   2
openqa-client3
rocketcea3
graide   5
python3-emperor  5
python3-grapefruit   6
python3-stomper  6
python3-junitparser  7
python3-pyhamtools   8
python3-pyxnat   11
onionbalance 16
python3-graphite216
python3-picopore 16
turing   16
autoradio17 #1054207
python3-biomaj3  24
python3-flask-autoindex  25
python3-scikit-rf26
radon29
osdlyrics30
python3-pyswarms 30
python3-pyocd34
bugwarrior   40
python3-gnocchiclient47
buildbot-worker  63
python3-bibtexparser 71
weechat-matrix   71
gnome-keysign82---> upstream
python3-proselint83
python3-cpuset   90
python3-mdp  143   old_div
python3-yade 192   c++
python3-plaso212   RM
python3-uncertainties262   package new version
chirp321   non
duplicity10757

Bug#1058041: ncurses: breaks `hg histedit` (_curses.error: endwin() returned ERR)

[Sven Joachim]

On 2023-12-11 17:47 +0100, Sven Joachim wrote:

> On 2023-12-11 16:22 +0100, Julien Cristau wrote:
>
>> Source: ncurses
>> Version: 6.4+20231121-1
>> Severity: important
>> Control: affects -1 mercurial
>> X-Debbugs-Cc: jcris...@debian.org
>>
>> Hi,
>>
>> Since a ncurses upgrade in testing recently `hg histedit` seems to
>> crash consistently, upon trying to apply the changes:
>>
>>> Traceback (most recent call last):
>>>   File "/usr/bin/hg", line 59, in 
>>> dispatch.run()
>>>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 142, in 
>>> run
>>> status = dispatch(req)
>>>  ^
>>>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 231, in 
>>> dispatch
>>> status = _rundispatch(req)
>>>  ^
>>>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 275, in 
>>> _rundispatch
>>> ret = _runcatch(req) or 0
>>>   ^^
>>>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 456, in 
>>> _runcatch
>>> return _callcatch(ui, _runcatchfunc)
>>>^
>>>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 466, in 
>>> _callcatch
>>> return scmutil.callcatch(ui, func)
>>>^^^
>>>   File "/usr/lib/python3/dist-packages/mercurial/scmutil.py", line 152, in 
>>> callcatch
>>> return func()
>>>^^
>>>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 446, in 
>>> _runcatchfunc
>>> return _dispatch(req)
>>>^^
>>>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1271, 
>>> in _dispatch
>>> return runcommand(
>>>^^^
>>>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 904, in 
>>> runcommand
>>> ret = _runcommand(ui, options, cmd, d)
>>>   
>>>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1283, 
>>> in _runcommand
>>> return cmdfunc()
>>>^
>>>   File "/usr/lib/python3/dist-packages/mercurial/dispatch.py", line 1269, 
>>> in 
>>> d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
>>> ^
>>>   File "/usr/lib/python3/dist-packages/mercurial/util.py", line 1878, in 
>>> check
>>> return func(*args, **kwargs)
>>>^
>>>   File "/usr/lib/python3/dist-packages/hgext/histedit.py", line 1918, in 
>>> histedit
>>> return _chistedit(ui, repo, freeargs, opts)
>>>
>>>   File "/usr/lib/python3/dist-packages/hgext/histedit.py", line 1764, in 
>>> _chistedit
>>> curses.endwin()
>>> _curses.error: endwin() returned ERR
>
> I am not familiar with Mercurial, but most likely this has been
> triggered by the following change in the 2023111 patchlevel:
>
> ,
> | 2023
> | + modify endwin() to return an error if it is called again without an
> |   intervening screen update (report by Rajeev Pillai, NetBSD #57592).
> `

I now had a look at the histedit code, and it does this:

,
| with util.with_lc_ctype():
| rc = curses.wrapper(functools.partial(_chisteditmain, repo, 
rules))
| curses.echo()
| curses.endwin()
`

AFAICS, invoking curses.echo() and curses.endwin() is superfluous
because curses.wrapper already does that for you, and calling
curses.endwin() twice throws an error with the newer ncurses.  Removing
those two lines should fix the problem.

Cheers,
   Sven

Bug#910664: Acknowledgement (ghc: ghc package can no longer be cross-compiled)

[Ilias Tsitsimpis]

Hi Helmut,

On Sun, Dec 10, 2023 at 09:01PM, Helmut Grohne wrote:
> First and foremost, ghc now actively refuses being cross build with an
> $(error ...). Would you mind weakening this to a $(warning ...)? While
> that you don't want to support cross building of ghc, would you mind
> others (like me) supporting it? Yes, it would still fail, but then
> https://crossqa.debian.net/src/ghc could show a more useful reason for
> that failure.

The reason I have this as an $(error ...) is because the new Hadrian
build system doesn't support cross-compiling GHC [1]. This is not a
limitation of our Debianization (i.e., it's not that we refuse to
cross-build GHC, we *cannot* cross-build GHC), this is upstream
limitation. Given that, I believe $(error ...) is more appropriate here
than $(warning ...).

[1] https://gitlab.haskell.org/ghc/ghc/-/issues/23975

> Then when you get past the $(error ...), stage1 tools are not found. In
> a cross build, ghc prefixes these with the host gnu triplet. A bit of
> renaming is required to make this work. (patch attached)

The resulting stage1 tools are a cross-compiler, not the final
cross-compiled binaries (this is why they are prefixed with the host gnu
triplet). I am not sure how we will handle this, I am waiting to see on
what upstream will do to support cross-building GHC. For now, I believe
applying the attached patch doesn't help.

> And then we run into:
> 
> On Tue, Oct 09, 2018 at 03:24:41PM +0200, John Paul Adrian Glaubitz wrote:
> > This change to the debian/rules file helps to get a bit further:
> > 
> > --- debian/rules.orig   2018-09-26 11:08:46.0 +0200
> > +++ debian/rules2018-10-09 15:22:43.080942145 +0200
> > @@ -126,6 +126,7 @@
> > echo 'V=1' >> mk/build.mk
> > dh_auto_configure -- \
> > $(EXTRA_CONFIGURE_FLAGS) \
> > +   --host=$(DEB_BUILD_GNU_TYPE) \
> > --with-system-libffi --libdir=/usr/lib
> >  
> >  override_dh_auto_build:
> > 
> > But it will still fail with:
> 
> I think this is wrong. The current ghc packaging includes this flag, but
> ghc uses the same terminology as Debian, so when we say
> --host=$(DEB_BUILD_GNU_TYPE) we ask it to produce a cross compiler, but
> we really wanted a cross built ghc. One of the issues referenced from
> the earlier $(error ...) also hints that this value is wrong for --host:
> https://gitlab.haskell.org/ghc/ghc/-/issues/22006 Unless you have strong
> reasons for why that should be correct, I suggest that we change it to
> --host=$(DEB_HOST_GNU_TYPE). (not included in patch)

GHC does *not* use the same terminology as Debian. GHC requires that
HOST and BUILD are the same. You can read more about this here [2],
though keep in mind this document is severely outdated with the Hadrian
build system.

[2] 
https://gitlab.haskell.org/ghc/ghc/-/wikis/building/cross-compiling#terminology-and-background

> So this is where we are. I think we can make progress here if you want
> to support this work. I'm also a big fan of actionable bug reports and
> in having a patch, this bug becomes actionable. Given that you (ghc
> maintainers) are evidently not interested in doing the work here, I also
> suggest that you close this bug when applying the patch and letting
> cross users file new bugs with new patches. Let me know what you think
> about this.

I believe we need to work with upstream to add support for
cross-compiling GHC to the new Hadrian build system. As explained here [3],
this is currently not possible. I tested everything I could think of,
but I don't see how we can move forward without reworking how the
Hadrian build system works. Upstream has started working on this, but
it's moving slowly [4].

In summary, as a result of the switch to the Hadrian build system, we
are now unable to cross-compile GHC. Since this issue now has all the
latest context, I propose we keep it open and work here on
cross-building GHC.

[3] https://gitlab.haskell.org/ghc/ghc/-/issues/23975#note_526546
[4] https://gitlab.haskell.org/ghc/ghc/-/issues/23975#note_530201

Thanks,

-- 
Ilias

Bug#1058061: insilicoseq: please ensure python3-future doesn't end un in "Depends:"

[Alexandre Detiste]

Source: insilicoseq
Severity: important


Dear Maintainers,

The removal of old unmaintained python3-future is being investigated.

A quick review of your package show stale references to "future" in:
- setup.py
- debian/control

Please patch them out and also report setup.py upstream.

Greetings,

Alexandre


$ grep future -r
setup.py:  'pysam>=0.15.1', 'future',
debian/control:   python3-future,
Pipfile.lock:"future": {
Pipfile:future = "*"
$ grep past -r
$ 



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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads & dust)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

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

[Drew Parsons]

Source: adios2
Followup-For: Bug #1058018
Control: severity -1 important

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.

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

Bug#1058060: python3-ntp: invalid escapes warnings during package install

[Christoph Anton Mitterer]

Package: python3-ntp
Version: 1.2.2+dfsg1-3
Severity: normal


Hey.

When upgrading to the current version, I got.
Setting up python3-ntp (1.2.2+dfsg1-3) ...
/usr/lib/python3/dist-packages/ntp/util.py:641: SyntaxWarning: invalid escape 
sequence '\]'
  m = re.match("([:.[\]]|\w)*", inhost)
/usr/lib/python3/dist-packages/ntp/util.py:1398: SyntaxWarning: invalid escape 
sequence '\%'
  if not c.isalnum() and c not in "/.:[] \%\n":


Cheers,
Chris.


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.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 python3-ntp depends on:
ii  libbsd0  0.11.7-4
ii  libc62.37-13
ii  libssl3  3.1.4-2
ii  python3  3.11.6-1

python3-ntp recommends no packages.

python3-ntp suggests no packages.

-- no debconf information

Bug#1058059: ditaa fails to build from source in sid

[Vladimir Petko]

Source: ditaa
Version: 0.10+ds1-1.3
Severity: important
Tags: ftbfs

Dear Maintainer,

The package fails to build from source in the sid chroot.
The relevant part of the build log:


dh binary --with javahelper
   dh_update_autotools_config
   dh_autoreconf
   jh_linkjars
   jh_build
xargs: /usr/lib/jvm/default-java/bin/javac: No such file or directory
jh_build: error: find ./src/org/ -name '*.java' -and -type f -print0 | xargs -s
512000 -0 /usr/lib/jvm/default-java/bin/javac -g -cp
/usr/share/java/junit4.jar:/usr/lib/jvm/default-
java/lib/tools.jar:/usr/share/java/commons-cli.jar:/usr/share/java/batik-
bridge.jar:/usr/share/java/batik-dom.jar:/usr/share/java/batik-
gvt.jar:/usr/share/java/batik-svg-dom.jar:/usr/share/java/batik-awt-
util.jar:/usr/share/java/xml-apis-ext.jar:/usr/share/java/batik-
libs.jar:/usr/share/java/jericho-html.jar:debian/_jh_build.ditaa -d
debian/_jh_build.ditaa -encoding ISO8859-1 -source 7 -target 7  returned exit
code 127
make: *** [debian/rules:11: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Build finished at 2023-12-11T19:58:05Z
--


-- System Information:
Debian Release: trixie/sid
  APT prefers mantic-updates
  APT policy: (500, 'mantic-updates'), (500, 'mantic-security'), (500, 
'mantic'), (100, 'mantic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#1057843: linux: ext4 data corruption in 6.1.64-1

[Salvatore Bonaccorso]

As there were some questions along in this thread let me summarize
some points:

The issue affects fs/ext4 code, so no other filesystems are affected
(e.g. btrfs).

The issue affects all kernels which have the commit 91562895f803
("ext4: properly sync file size update after O_SYNC direct IO") from
6.7-rc1 (which is present in 6.6.3, 6.5.13 and 6.1.64) but when commit
936e114a245b ("iomap: update ki_pos a little later in
iomap_dio_complete") from 6.5-rc1 is missing (which was backported to
5.15.142 and 6.1.66 additionally).

The only upstream combination where that reverse and missing commit
happened was 6.1.64 and 6.1.65. 

Debian is affected as per 6.1.64-1 upload which was the kernel aimed
for 12.3 point release.

The issue affects file corruption when direct IO writes are involved.
O_DIRECT writes did not properly update current file position after
the write so data and file was getting mangled.

While this does not affect every write ever happend on the system on a
ext4 filesystem with a broken kernel, O_DIRECT writes might be quite
common in in programms trying to get high performance. It might be
argued that it is not that common, but it's not inexistant.

TTOMK, such file corruptions cannot be easily detected. Candidates to
check are every modified file written since booted with the broken
kernel 6.1.64-1.

Poeple still not having booted into 6.1.66-1 are urged to do so.

Regards,
Salvatore

Bug#1058058: nipype: please remove extraneous dependency on python3-future

[Alexandre Detiste]

Source: nipype
Severity: important

Dear Maintainer,

The remove of python3-future is being investigated:
it's obsolete and unmaintained and causes problems with Py3.12

It seems your package required it a long time ago.

Please now remove the hardcoded python3-future in d/control
and check everything still works.

Greetings,

Alexandre Detiste


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1056900: sstp-client: Build failures with ppp-2.5.0

[Eivind Naess]

 Sorry, I had the wrong branch of sstp-client checked out. Bastian, could you 
please review my changes and upload if you see nothing wrong with it. 
Otherwise, please let me know and I'll fix / update my notes.
Regards,- Eivind
På mandag 11. desember 2023 kl. 10:07:35 PST skrev Eivind Naess 
 følgende:  
 
  I don't think it is released yet, and I don't think there is anything 
blocking it. Let me have a day or two to figure it out. High priority stuff at 
work
På mandag 11. desember 2023 kl. 09:39:06 PST skrev Bastian Germann 
 følgende:  
 
 Hi Eivind,

I see you have released 1.0.19. Does this fix the issue?
If so, please hand in a package update.

Thanks,
Bastian

Bug#1056531: cython 3.x (for Python 3.12)

[Julian Gilbey]

On Mon, Dec 11, 2023 at 08:06:41PM +0100, Matthias Klose wrote:
> > [...]
> > Excellent - I didn't know about that.  Are you OK for me to upload
> > versions of cython and cython-legacy which depend on this to fix the
> > Python 3.12 breakage?
> 
> not for cython, which won't need that soonish for 3.0.x.  and if you have to
> update the b-d to cython3-legacy, why not add the zombie-imp dependency as
> well manually for the few packages that need it?

The problem is not with other packages importing imp (which need to
be fixed in such a case), rather that pyximport (in
cython/cython-legacy) imports imp.  So it's cython that needs to be
patched.

I'm wondering what the provisional timescale for cython 3.0.x is?
Should I just leave my package with an autopkgtest failure until
cython 3.0.x is in unstable or ideally testing?  That's why I was
thinking of also patching cython in the short term until we are ready
for cython 3.0.x to enter unstable.

Best wishes,

   Julian

Bug#1058057: impacket: please remove erroneous extraneous reference to 'future' from setup.py

[Alexandre Detiste]

Source: impacket
Severity: important
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Dear Maitainer,

Upstream mistakenly added 'future' to the requirements in setup.py

Maybe they tought it was needed to get the
"from __future__ import ..." statements working.

That would had been "from future import ..." / "from past import ...".

Nowadays it means that your package is pulling in python3-future.
This library is obsolete and mostly unmaintained
and should be removed from Debian.

So please patch it out from the build.

Greetings,

Alexandre


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1057857: reverse dependencies

[Thorsten Alteholz]

Control: tags -1 + moreinfo

Hi Ilias,

there are reverse dependencies that need to be taken care of.
Please file for each package a different RM bug.

Please remove the moreinfo tag once that is done.

  Thorsten

Bug#1054152: rasdaemon: frequent crashes of rasdaemon

[piorunz]

On 11/12/2023 14:20, Russell Coker wrote:

We have 2 different issues here.  The first one is a SEGV related to sqlite,
that might be a sqlite bug.  Have you tried writing a simple sqlite program or
using a sqlite utility to see if it also crashes?


Sorry, I have no ability to write such a program.


The issue being discussed now is separate.  As most of this bug report is now
about the other issue could you file a different bug just about the sqlite
side of things and we can then reassign it to sqlite if appropriate?


SIGBUS problem will go away in no time, as this has not come back since
I installed patch earlier today. Looks like this fixes it.
Tai, please import this 1 line change to Debian Stable, that would be
awesome if you could.

And now we can come back to the issue from my original report.
I am waiting for another crash to give you more information.

--
With kindest regards, Piotr.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄

Bug#1058046: systemd: unable to run fsck at boot

[Michael Biebl]

[please always CC the bug report on replies]

Am 11.12.23 um 19:47 schrieb Alessandro Ogier:

Ciao,

 thanks for your reply.

I see there is something more complex than I'm able to figure out, but I 
must report that upon reboot some trivial problems with the filesystem 
persist so it doesn't seem like anything has really done.


Is expecting a clean "fsck -n -f XXX" run wrong?



Have you tried "fsck.mode=force fsck.repair=yes" as well?
Afaics, the initrd does not understand "auto".

https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/master/init#L182-192


fastboot|fsck.mode=skip)
fastboot=y
;;
forcefsck|fsck.mode=force)
forcefsck=y
;;
fsckfix|fsck.repair=yes)
fsckfix=y
;;
fsck.repair=no)
fsckfix=n
;;


regards,
Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058056: multiqc: please remove extraneous dependency on python3-future

[Alexandre Detiste]

Source: multiqc
Severity: normal
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Dear Maintainers,

Your package's setup.py declares an extraneous
dependency on old compatibility layer python3-future.

> setup.py:"future>0.14.0",

But it doesn't need it at all:
no import of "past" or "future" libraries.


Please report it upstream and in the meantime
build a package with this line patched-out.

Greetings,

Alexandre


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1058055: galpy: please remove extraneous dependency on python3-future

[Alexandre Detiste]

Source: galpy
Version: 1.8.1-2
Severity: important
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Dear Maintainer,

The removal of the python3-future library is being evaluated.

It's obsolete & unmaitained upstream.


Your package seems not to have required python3-future for a long time.
Please remove the hardcoded dependency from debian/control.

Greetings,



/tmp/galpy $ grep future -r
setup.py:# Note for the futureL could now get the actual compiler in the 
BuildExt class
debian/control: python3-future,
debian/control: python3-future,
debian/changelog:  * Add python3-future as build and package dependency
/tmp/galpy $ grep past -r
HISTORY.txt:  examples to the user's clipboard for easy pasting into a Python
/tmp/galpy $ 


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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1056531: cython 3.x (for Python 3.12)

[Matthias Klose]

On 11.12.23 19:55, Julian Gilbey wrote:

On Mon, Dec 11, 2023 at 04:34:17PM +0100, Matthias Klose wrote:

On 11.12.23 16:19, Julian Gilbey wrote:

On Mon, Dec 11, 2023 at 08:09:31AM +0100, Matthias Klose wrote:

[...]
You could package a non-conflicting cython-legacy, however that would
require more changes, also how to build it.


Hi Matthias,

Unfortunately, at least some of cython3-legacy doesn't currently work
with Python 3.12, and is the primary cause of (at least) #1056531.
cython3 provides the pyximport module, and that uses the imp module
which has been removed from Python 3.12.

Two possible ways forward on this particular bug:

- Disable all of the cython tests for this package for the time being,
until cython 3.x migrates to testing - this is simple and effective.

- Patch cython3-legacy to use importlib rather than imp.  This is
probably a good thing to do anyway.  (It may also be good to do this
with cython3 version 0.x currently in testing/unstable until cython
3.x is able to be uploaded to unstable.)  Then have my package's
autopkgtest depend on cython3-legacy (unless cython3 0.x is also
patched).


I won't working on this. Have you tried to depend on the python3-zombie-imp
instead?


Excellent - I didn't know about that.  Are you OK for me to upload
versions of cython and cython-legacy which depend on this to fix the
Python 3.12 breakage?


not for cython, which won't need that soonish for 3.0.x.  and if you 
have to update the b-d to cython3-legacy, why not add the zombie-imp 
dependency as well manually for the few packages that need it?

Bug#1058053: binwalk: should at least Recommend: python3-capstone

[Matthias Geiger]

Package: binwalk
Version: 2.3.4+dfsg1-1
Severity: minor
X-Debbugs-Cc: werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainers,

thanks for providing binwalk. When digging into a firmware file I
noticed that the --disasm / -Y option does not work unless the required
dependency, python3-capstone, is installed. See upstreams readme [0].

binwalk should recommend capstone too so this option can work as
intended.

[0] https://github.com/ReFirmLabs/binwalk/blob/master/INSTALL.md#dependencies

best,

werdahias


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

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

Versions of packages binwalk depends on:
ii  python3  3.11.6-1
ii  python3-binwalk  2.3.4+dfsg1-1

binwalk recommends no packages.

binwalk suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmV3XT8VHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1I2gP/A2JR6u5iLeIRvr5KX5H/H17HQKg
05gVQyw8STHo4Pze/7xrkI05EmG9H/m0PVl1wKVG5e9VJ4sCTb3OBSNmZrTeVsTu
1xPcAKFT8hJGErrNQ7kdiqs4w8CeFTyTQot1F3UPEY0EHijVZiIN11OSgSwLmp03
KDGtYqmeUwj4uokN1HrctpE0B792zLtV2WmZTgVABfaDqHW0I/ScmjqHiZpBnwQ9
yaFxOBLlGDNPVQI4M//mpLy06A9lG7p3NTU9kCLiqMC7wDsKivFRz59SwfsjAJPf
hYe6N2s8kha/yW8PengiOibrAkr5aFZH7AxBwP39YgrKuuqBy6BGH3izy6RRsK9u
vuKa4HNngkMguERQqDX55jqZFLlrM8Qo3pAUfGCuGEovbtTnSTUteUz6chDUVsiU
QnI4Wsvm4ISOcqKZxP1js1l6c2lPsMB1cZNbICTvRb4F6Ncen2KpJINSrautG46E
xSioxgj1bquHBUl/ebcydboOTRcVyen+YwaDFZRYyXBnHjpYobbhVgzz4KF4X3pI
L+HqujZr7MBI3wbN7+poj65hEYy68asndVapYDOsM8a1+UmaEnAblI3aEmVJ6YXf
JL+dDrnzCfXh1X9XLvd9a5Mhw84mnWQAtFcp8LKD3xLsxD6fQ5RkDNLtsUBpcW3+
c+N4lMm2X8thMfoy
=375O
-END PGP SIGNATURE-

Bug#1058054: python3-sorted-nearest installs .pyx and .c files

[Matthias Klose]

Package: python3-sorted-nearest
Version: 0.0.38+dfsg-1.1

just seen that python3-sorted-nearest installs .pyx and .c files, both 
probably don't belong into the binary package.

Bug#1058052: linux-image-6.1.0-15-amd64 breaks suspend

[Dr . André Desgualdo Pereira]

Package: src:linux
Version: 6.1.66-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
   Updating the kernel.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   Booting from an older kernel fix the issue.
   * What was the outcome of this action?
   Bug is fixed by using an older kernel version.
   * What outcome did you expect instead?
   I expect updating the kernel doesn't break functionality.

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


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: CLEVO
product_name: P150HMx
product_version: Not Applicable
chassis_vendor: CLEVO   
chassis_version: Not Applicable
bios_vendor: American Megatrends Inc.
bios_version: 4.6.4
board_vendor: CLEVO
board_name: P150HMx
board_version: Not Applicable

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor 
Family DRAM Controller [8086:0104] (rev 09)
Subsystem: CLEVO/KAPOK Computer 2nd Generation Core Processor Family 
DRAM Controller [1558:5102]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd Generation Core 
Processor Family PCI Express Root Port [8086:0101] (rev 09) (prog-if 00 [Normal 
decode])
Subsystem: CLEVO/KAPOK Computer Xeon E3-1200/2nd Generation Core 
Processor Family PCI Express Root Port [1558:5102]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series 
Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
Subsystem: CLEVO/KAPOK Computer 6 Series/C200 Series Chipset Family MEI 
Controller [1558:5102]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset 
Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 05) (prog-if 20 [EHCI])
Subsystem: CLEVO/KAPOK Computer 6 Series/C200 Series Chipset Family USB 
Enhanced Host Controller [1558:5102]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset 
Family High Definition Audio Controller [8086:1c20] (rev 05)
Subsystem: CLEVO/KAPOK Computer 6 Series/C200 Series Chipset Family 
High Definition Audio Controller [1558:5102]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset 
Family PCI Express Root Port 1 [8086:1c10] (rev b5) (prog-if 00 [Normal decode])
Subsystem: CLEVO/KAPOK Computer 6 Series/C200 Series Chipset Family PCI 
Express Root Port 1 [1558:5102]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1c.1 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset 
Family PCI Express Root Port 2 [8086:1c12] (rev b5) (prog-if 00 [Normal decode])
Subsystem: CLEVO/KAPOK Computer 6 Series/C200 Series Chipset Family PCI 
Express Root Port 2 [1558:5102]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1c.2 PCI bridge [0604]: Intel 

Bug#1058051: Acknowledgement (django-q: please remove old extraneous dependency on python3-future)

[Alexandre Detiste]

It's officially stated in the upstream changelog:




## [v1.3.1](https://github.com/koed00/django-q/tree/v1.3.1) (2020-07-02)

[Full Changelog](https://github.com/koed00/django-q/compare/v1.3.0...v1.3.1)

--
- How is logging handled [\#209](https://github.com/Koed00/django-q/issues/209)
- ask close\_old\_connections use!
[\#198](https://github.com/Koed00/django-q/issues/198)

**Merged pull requests:**

- Updates botocore, certifi, chardet, docutils, idna and psutil
[\#267](https://github.com/Koed00/django-q/pull/267)
([Koed00](https://github.com/Koed00))
- Replaces some relative imports
[\#264](https://github.com/Koed00/django-q/pull/264)
([Koed00](https://github.com/Koed00))
- Updates packages and Django version
[\#263](https://github.com/Koed00/django-q/pull/263)
([Koed00](https://github.com/Koed00))
- Use 32 bits integer for repeat field to avoid overflow with frequent
scheduled tasks [\#262](https://github.com/Koed00/django-q/pull/262)
([gchardon-hiventy](https://github.com/gchardon-hiventy))
- Error reporter [\#261](https://github.com/Koed00/django-q/pull/261)
([danielwelch](https://github.com/danielwelch))
- Remove dependency `future`
[\#247](https://github.com/Koed00/django-q/pull/247)
([benjaoming](https://github.com/benjaoming))


Le lun. 11 déc. 2023 à 20:00, Debian Bug Tracking System
 a écrit :
> If you wish to submit further information on this problem, please
> send it to 1058...@bugs.debian.org.

Bug#1058046: systemd: unable to run fsck at boot

[Alessandro Ogier]

Ciao,

thanks for your reply.

I see there is something more complex than I'm able to figure out, but I 
must report that upon reboot some trivial problems with the filesystem 
persist so it doesn't seem like anything has really done.


Is expecting a clean "fsck -n -f XXX" run wrong?


thx, ciao


On 12/11/23 19:39, Michael Biebl wrote:
> Am 11.12.23 um 18:30 schrieb Alessandro -oggei- Ogier:
>> Package: systemd
>> Version: 255-1
>> Severity: normal
>>
>> Dear Maintainer,
>>
>>  while doing some checks for the recent kernel ext4 problem, I've
>> noticed fsck does not seem to be able to run at boot, the command
>>
>> journalctl -u systemd-fsck-root
>>
>> reports:
>>
>> -- Boot 2bb7b10680a74ab4854998cb33154999 --
>> dic 11 18:17:16 orso systemd[1]: systemd-fsck-root.service - File System
>> Check on Root Device was skipped because of an unmet condition check
>> (ConditionPathExists=!/run/initramfs/fsck-root).
>>
>
> this flag file means, that the / fs has already been checked by the 
initrd.

>
>

Bug#1058051: django-q: please remove old extraneous dependency on python3-future

[Alexandre Detiste]

Source: django-q
Version: 1.3.9-5
Severity: important

The python3-future is an old temporary solution
to have a billingual Python 2 + 3 codebase.

django-q doens't need it at all anymore.

The removal of python3-future is being investigated,
so please remove your package from the list to fix :-)

Greeting,



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

Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1056531: cython 3.x (for Python 3.12)

[Julian Gilbey]

On Mon, Dec 11, 2023 at 04:34:17PM +0100, Matthias Klose wrote:
> On 11.12.23 16:19, Julian Gilbey wrote:
> > On Mon, Dec 11, 2023 at 08:09:31AM +0100, Matthias Klose wrote:
> > > [...]
> > > You could package a non-conflicting cython-legacy, however that would
> > > require more changes, also how to build it.
> > 
> > Hi Matthias,
> > 
> > Unfortunately, at least some of cython3-legacy doesn't currently work
> > with Python 3.12, and is the primary cause of (at least) #1056531.
> > cython3 provides the pyximport module, and that uses the imp module
> > which has been removed from Python 3.12.
> > 
> > Two possible ways forward on this particular bug:
> > 
> > - Disable all of the cython tests for this package for the time being,
> >until cython 3.x migrates to testing - this is simple and effective.
> > 
> > - Patch cython3-legacy to use importlib rather than imp.  This is
> >probably a good thing to do anyway.  (It may also be good to do this
> >with cython3 version 0.x currently in testing/unstable until cython
> >3.x is able to be uploaded to unstable.)  Then have my package's
> >autopkgtest depend on cython3-legacy (unless cython3 0.x is also
> >patched).
> 
> I won't working on this. Have you tried to depend on the python3-zombie-imp
> instead?

Excellent - I didn't know about that.  Are you OK for me to upload
versions of cython and cython-legacy which depend on this to fix the
Python 3.12 breakage?

Best wishes,

   Julian

Bug#1052443: ITA: librepfunc -- set of C++ classes and utilities for building multimedia tools

[Phil Wyett]

Hi Fab, Apostolos and all,

My name is Phil Wyett (kathenas) and I am in the process of taking over as the 
maintainer of
'librepfunc'.

I would ask that no commits or releases take place without my approval until 
the transition is
complete.

I thank you for your assistance with this transition and hope we will work 
together in the future.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




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

Bug#1052444: ITA: w-scan-cpp -- DVB channel scanner (successor of w_scan)

[Phil Wyett]

Hi Fab and all,

My name is Phil Wyett (kathenas) and I am in the process of taking over as the 
maintainer of
'w-scan-cpp'.

I would ask that no commits or releases take place without my approval until 
the transition is
complete.

I thank you for your assistance with this transition and hope we will work 
together in the future.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




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

Bug#1058050: RM: amtk/experimental -- RoM; superseded by libgedit-amtk

[Jeremy Bícha]

Package: ftp.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: a...@packages.debian.org
Control: affects -1 + src:amtk

The amtk source package was removed from Unstable with
https://bugs.debian.org/1056584

Please remove it from Experimental too.

Note that the binary package gir1.2-amtk-5 is now built by the source
package libgedit-amtk

On behalf of the Debian GNOME team,
Jeremy Bícha

Bug#1058046: systemd: unable to run fsck at boot

[Michael Biebl]

Am 11.12.23 um 18:30 schrieb Alessandro -oggei- Ogier:

Package: systemd
Version: 255-1
Severity: normal

Dear Maintainer,

 while doing some checks for the recent kernel ext4 problem, I've
noticed fsck does not seem to be able to run at boot, the command

journalctl -u systemd-fsck-root

reports:

-- Boot 2bb7b10680a74ab4854998cb33154999 --
dic 11 18:17:16 orso systemd[1]: systemd-fsck-root.service - File System
Check on Root Device was skipped because of an unmet condition check
(ConditionPathExists=!/run/initramfs/fsck-root).



this flag file means, that the / fs has already been checked by the initrd.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058049: [mk-build-deps] "arch all" packages are architecture-specific

[Stephen Gildea]

Package: devscripts
Version: 2.23.6
Tags: patch

The packages mk-build-deps builds work on only one architecture, even if the
built package architecture is "all".  This is because the generated package
always includes a dependency on "build-essential:", where  is a
specific architecture.

Because of this limitation, when I need a build-depends package for a second
architecture, I must re-run mk-build-deps.  This gives me a new package with
the same name and same architecture, but a different Depends line.

The problem is fixed with this 2-line patch, which removes the architecture
specification from "build-essential" when building an "all" package.

--- devscripts-2.23.6/scripts/mk-build-deps.pl
+++ devscripts/scripts/mk-build-deps.pl
@@ -566,7 +566,8 @@ sub build_equiv {
 deps_iterate($negative, $handle_native_archqual);
 
 my $pkgname;
-my $buildess = "build-essential:$buildarch";
+my $buildess = "build-essential";
+$buildess .= ":$buildarch" if $packagearch ne "all";
 if ($buildarch eq $hostarch) {
 $pkgname = "$opts->{name}-$opts->{type}";
 } else {

Bug#1057967: linux-image-6.1.0-15-amd64 renders my physical bookworm/gnome computer largely unusable

[Salvatore Bonaccorso]

Hi,

On Mon, Dec 11, 2023 at 01:27:07PM +0100, Kevin Price wrote:
> Thank you Salvatore!
> 
> Am 11.12.23 um 12:37 schrieb Salvatore Bonaccorso:
> > It still would be helpfull if you can get to the logs of the previous
> > boot. After booting back in the working kernel, do you have anything
> > sensible logged in the previous boot log? If so can you share that
> > please?
> 
> Sure. Here's my boot.log.

I was more interested to get some nformation from the kernel. If you
get dmesg output that would be good, maybe the journalctl from the bug
otherwise, which will help to get more context.

> 
> The first one at "Mon Dec 11 00:54:03 CET 2023" is the faulty 6.1.0-15.
> 
> The 2nd one at "Mon Dec 11 01:13:38 CET 2023" is the working 6.1.0-13.
> 
> Need any more logfiles or testing? I intend to test
> debian-live-12.4.0-amd64-gnome.iso on my computer, IOT rule out any
> local config peculiarities, FWIW.
> 
> > I'm right now curious to find out if we see the same as
> > #1057969 and if the upstream commit db46c77f3d51 ("Revert "wifi:
> > cfg80211: fix CQM for non-range use"") in 6.1.67 upstream fixes the
> > issue.
> 
> Please let me know what kernel version you want me to test, if they're
> provides as debian binaries. I'd be glad to help, probably not only for
> my own sake. Bear with me I'm unwilling to build kernel packages myself,
> due to lack of computing resources. HTH

I have put binary packages for amd64 built in
https://people.debian.org/~carnil/tmp/linux/1057967/

*but* they are completely unofficial builds. To give assurance of
provenance I have generated a sha256sum file as well for the uploaded
files and signed it with my key in the Debian keyring.

If you personal policy allows you to install such packages please test
with those, otherwise we need you to have built your own packages.

Regards,
Salvatore

Bug#1056253: rust-ripasso-cursive - FTBFS with rust-ripasso 0.6.4

[Alexander Kjäll]

Hi

I'm sorry for the semver breakage, the last version was a bit stressed
out due to the security problems with libgit2 not verifying server
signatures (that has since been fixed).

I think the best path forward might be to package the latest versions,
I have started that but not finished yet due to some real life things
taking all my free time lately.

best regards
Alexander Kjäll

Bug#1057238: debian-policy: Take dpkg-build-api into account for Rules-Requires-Root

[Bill Allombert]

On Sat, Dec 02, 2023 at 01:22:04AM +0100, Guillem Jover wrote:
> Package: debian-policy
> Version: 4.6.2.0
> Severity: wishlist
> 
> Hi!
> 
> Starting with dpkg 1.22.0, it implements a dpkg-build-api mechanism
> similar in concept to the debhelper-compat levels.
> 
> You can check its documentation in the dpkg-build-api(7) and
> dpkg-buildapi(1) manual pages.
> 
> I think at least the part that involves the Rules-Requires-Root field
> which in level 1 defaults to value «no» instead of «binary-targets»
> should be documented in the Debian policy.

Note that I proposed that in bug #229357 in 2004, this was even fully 
implemented,
commited to the VCS and finally reverted without explanation.
I am still not sure why I suffered so much hostility over such a simple design.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1056900: sstp-client: Build failures with ppp-2.5.0

[Eivind Naess]

 I don't think it is released yet, and I don't think there is anything blocking 
it. Let me have a day or two to figure it out. High priority stuff at work
På mandag 11. desember 2023 kl. 09:39:06 PST skrev Bastian Germann 
 følgende:  
 
 Hi Eivind,

I see you have released 1.0.19. Does this fix the issue?
If so, please hand in a package update.

Thanks,
Bastian
  

Bug#1057843: Bug patching

[Sergiu]

Hi

Any new information, when will this be patched?
There are packages that can not be installed like nvidia-driver because
while installing it updates the system and the process fails.

Isn't possible to remove from the repo the corrupted kernel so that people
can install other packages?


Regards,
Sergiu

Bug#1053702: NIST data feed to be retired in December 2023

[Emilio Pozuelo Monfort]

Control: forwarded -1 
https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/155


On 02/11/2023 07:01, Salvatore Bonaccorso wrote:

Control: tags -1 + confirmed

Hi,

On Mon, Oct 09, 2023 at 11:48:59AM +0200, Bastian Blank wrote:

Package: security-tracker
Severity: important

The security tracker currently uses the JSON feeds as linked from
https://nvd.nist.gov/vuln/data-feeds.  Those data feeds will be retired
on December, 15th 2023, so in a bit more then two months.  After that
the information will be only available via the API.

See also the announcement:
https://nvd.nist.gov/General/News/change-timeline


Thanks. TTBOMK, but will have to check, we only nowdays use the NVD
feed for the descriptions. If that's the case we will switch to the
MITRE provided feeds as we use for the rest already.


Done in the above MR.

Cheers,
Emilio

Bug#1058048: RFS: urlview/1c-1 [RC] -- Extracts URLs from text

[наб]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name : urlview
   Version  : 1c-1
   Upstream contact : https://lists.sr.ht/~nabijaczleweli/urlview-ng
 * URL  : https://sr.ht/~nabijaczleweli/urlview-ng
 * License  : GPL-2+, 0BSD
 * Vcs  : https://git.sr.ht/~nabijaczleweli/urlview.deb
   Section  : misc

The source builds the following binary packages:

  urlview - Extracts URLs from text

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/u/urlview/urlview_1c-1.dsc

Changes since the last upload:

 urlview (1c-1) unstable; urgency=medium
 .
   * d/control: drop the ill-conceived shellcheck dep
   * Downgrade sensible-utils to Recommends: ‒
 very-nice-to-have in default configuration,
 but by no means absolutely required (Closes: #906725)
   * Revert UCF addition (Closes: #1057675)
   * New upstream version 1c (+ changelog & NEWS) (Closes: #1057411, #1043334)
   * d/copyright: update for 1c

Regards,
-- 
  наб


signature.asc
Description: PGP signature

Bug#1058047: gammapy: FTBFS with Python 3.12

[Graham Inggs]

Source: gammapy
Version: 1.1-3
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.12

Hi Maintainer

gammapy FTBFS [1] with Python 3.12 as a supported version.  I've
copied what I hope is the relevant part of the log below.

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=gammapy


=== FAILURES ===
_ test_parameter_name __

def test_parameter_name():
with pytest.raises(RuntimeError):

>   class MyTestModel:

gammapy/modeling/models/tests/test_core.py:256:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = Parameter(name='wrong-name', value=3.0, factor=3.0, scale=1.0,
unit=Unit(dimensionless), min=nan, max=nan, frozen=False,
id=0x8e307aa0)
owner = .MyTestModel'>
name = 'par'

def __set_name__(self, owner, name):
if not self._name == name:
>   raise ValueError(f"Expected parameter name '{name}', got 
> {self._name}")
E   ValueError: Expected parameter name 'par', got wrong-name
E   Error calling __set_name__ on 'Parameter' instance 'par'
in 'MyTestModel'

gammapy/modeling/parameter.py:165: ValueError

Bug#1056900: sstp-client: Build failures with ppp-2.5.0

[Bastian Germann]

Hi Eivind,

I see you have released 1.0.19. Does this fix the issue?
If so, please hand in a package update.

Thanks,
Bastian

Bug#1043240: transition: pandas 1.5 -> 2.1

[Matthias Klose]

On 11.12.23 08:12, Matthias Klose wrote:

On 10.12.23 14:06, Rebecca N. Palmer wrote:
Is this an acceptable amount of breakage or should we continue to 
wait? Bear in mind that if we wait too long, we may be forced into it 
by some transition further up the stack (e.g. a future Python or 
numpy) that breaks pandas 1.x.


up to the maintainers. But please wait at least until the current pandas 
and numpy migrated to testing, e.g. that the autopkg tests of pandas and 
numpy triggered by python3-defaults pass.


I just nmued pyrle and sorted-nearest, having dependencies on 
cython3-legacy, letting the pyranges autopkg tests fail. Once this 
succeeds, pandas should be able to migrate.

Bug#1057843: linux: ext4 data corruption in 6.1.64-1

[Dennis Grevenstein]

On Mon, 11 Dec 2023 10:38:40 +0100 helios.sola...@gmx.ch wrote:
> I have been running debian 12.3 with kernel 6.1.64-1 for a few hours,
> how can I find out whether the file system has been corrupted?

yes, I would also appreciate an explanation who could be affected,
how to diagnose the problem, and what needs to be done.
Please note that not all the users of Debian stable are kernel hackers
who will be able to look at the filesystem code and understand the
full extent of the problem.

thanks,
Dennis

Bug#1057369: otpclient is producing incorrect codes

[devel]

Hello,

downgrading `optclient` to the bookworm version (which implies the installation
of libcotp12) fixes the problem for me.

(please note, that *new* OTP keys created in a newer version of otpclient need
to be discarded and created again)

I just opened an upstream issue [1] for otclient regarding the strict version
requirement.

Lars

[1] https://github.com/paolostivanin/OTPClient/issues/329

Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6

[Sune Stolborg Vuorela]

On Monday, December 11, 2023 5:26:14 PM CET Lisandro Damián Nicanor Pérez 
Meyer wrote:

> > +1 from me. qtchooser is no longer supported for Qt >= 6, so going
> > this way is just awesome.
> 
> Also worth to mention: this is something I should have done myself,
> but I currently lack the needed time, so Helmut took over. Many thanks
> to Helmut for this.

Agreed. Both to approach and to thanks to Helmut

/Sune

-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Bug#1058045: gitlab: login using web-based 2FA fails

[Mohammed Bilal]

Package: gitlab
Version: 16.0.8+ds1-2~fto12+2
Severity: important

Dear Maintainer,

Relevant section from the logs:

-

OpenSSL::PKey::PKeyError (pkeys are immutable on OpenSSL 3.0):

app/services/webauthn/authenticate_service.rb:54:in `verify_webauthn_credential'
app/services/webauthn/authenticate_service.rb:22:in `execute'
app/controllers/concerns/authenticates_with_two_factor.rb:90:in 
`authenticate_with_two_factor_via_webauthn'
app/controllers/concerns/authenticates_with_two_factor.rb:51:in 
`authenticate_with_two_factor'
lib/gitlab/middleware/memory_report.rb:13:in `call'
lib/gitlab/middleware/speedscope.rb:13:in `call'
lib/gitlab/database/load_balancing/rack_middleware.rb:23:in `call'
lib/gitlab/jira/middleware.rb:19:in `call'
lib/gitlab/middleware/go.rb:20:in `call'
lib/gitlab/etag_caching/middleware.rb:21:in `call'
lib/gitlab/middleware/query_analyzer.rb:11:in `block in call'
lib/gitlab/database/query_analyzer.rb:37:in `within'
lib/gitlab/middleware/query_analyzer.rb:11:in `call'
lib/gitlab/middleware/multipart.rb:173:in `call'
lib/gitlab/middleware/read_only/controller.rb:50:in `call'
lib/gitlab/middleware/read_only.rb:18:in `call'
lib/gitlab/middleware/same_site_cookies.rb:27:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/middleware/handle_malformed_strings.rb:21:in `call'
lib/gitlab/middleware/handle_ip_spoof_attack_error.rb:25:in `call'
lib/gitlab/middleware/request_context.rb:15:in `call'
lib/gitlab/middleware/webhook_recursion_detection.rb:15:in `call'
config/initializers/fix_local_cache_middleware.rb:11:in `call'
lib/gitlab/middleware/compressed_json.rb:45:in `call'
lib/gitlab/middleware/rack_multipart_tempfile_factory.rb:19:in `call'
lib/gitlab/middleware/sidekiq_web_static.rb:20:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:79:in `call'
lib/gitlab/middleware/release_env.rb:13:in `call'



Regards

Bug#1054657: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics)

[Sebastian Ramacher]

On 2023-12-11 16:57:34 +0100, Andreas Tille wrote:
> Am Mon, Dec 11, 2023 at 01:36:38PM +0100 schrieb Sebastian Ramacher:
> > > OK, but what is your suggestion?  Reverting and have broken tests due to
> > > the pandoc issue?
> > 
> > pandoc is fixed in unstable.
> 
> Really?  Salsa CI[1] says:
> 
>pandoc : Depends: pandoc-data (>= 3.0.1+ds) but 3.0.1-3 is to be installed
> 
> I uploaded anyway and hope this will be cured somehow.

This issue was fixed in 3.0.1+ds-3 which was uploaded today.

Cheers
-- 
Sebastian Ramacher