Bug#1040096: python-eventlet: deprecation of Python libraries asyncore and asynchat

[thomas]

That is the point: it is not calling it, but monkey-patching (ie: replacing) 
the system lib. 


I wont be able to work on this soon, even for just testing it (see my [VAC] 
message in -private), so I would welcome anyone's help. 


Cheers, 


Thomas Goirand 


On Jul 11, 2023 3:03 AM, Louis-Philippe Véronneau  wrote:

On 2023-07-05 07 h 38, Thomas Goirand wrote: 
> On 7/2/23 03:44, Louis-Philippe Véronneau wrote: 
>> Source: python-eventlet 
>> Severity: important 
>> User: debian-pyt...@lists.debian.org 
>> Usertags: asyncore-asynchat-deprecation 
>> 
>> Dear maintainer(s), 
>> 
>> In Python 3.6, asyncore and asynchat have been formally marked as 
>> deprecated. Code that imports these libraries will no longer work from 
>> Python 3.12, which is currently in Trixie. 
>> 
>> Since python-eventlet uses either of these Python libraries, please 
>> prepare for this removal and migrate away from them. 
>> 
>> See this link for more details: 
>> https://peps.python.org/pep-0594/#deprecated-modules 
> 
> Hi Louis, 
> 
> The only place where I can see the use of these libs, is where Eventlet 
> is monkey patching that lib. See 
> https://github.com/eventlet/eventlet/blob/master/eventlet/green/asyn{core,chat}.py.
>  In such a case, do we still have an issue? 
> 
> Cheers, 
> 
> Thomas Goirand (zigo) 
> 

I'm not familiar enough with this code, but if the import is called with 
python 3.12, it will fail. I don't know how much this library depends on it. 

You can always test it out yourself with python3.12 (currently in trixie 
and sid). 

Cheers, 

-- 
   ⢀⣴⠾⠻⢶⣦⠀ 
   ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau 
   ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org 
   ⠈⠳⣄ 

Bug#1040896: raspi-firmware: Unable to uninstall raspi-firmware on amd64 systems

[William Chung]

Package: raspi-firmware
Version: 1.20220830+ds-1
Severity: important
X-Debbugs-Cc: wiiliamchung...@gmail.com

Dear Maintainer,

Users are not able to uninstall raspi-firmware on amd64 systems, as the
initramfs hook will exit with the following error:

>   raspi-firmware: missing /boot/firmware, did you forget to mount it?
>   run-parts: /etc/initramfs/post-update.d//z50-raspi-firmware exited with
>   return code 1
>   run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
>   dpkg: error processing package linux-image-6.1.0-10-amd64 (--configure):
>installed linux-image-6.1.0-10-amd64 package post-installation script
>subprocess returned error exit status 1
>   dpkg: dependency problems prevent configuration of linux-image-amd64:
>linux-image-amd64 depends on linux-image-6.1.0-10-amd64 (= 6.1.37-1);
>however:
> Package linux-image-6.1.0-10-amd64 is not configured yet.
>
>   dpkg: error processing package linux-image-amd64 (--configure):
>dependency problems - leaving unconfigured
>   Errors were encountered while processing:
>linux-image-6.1.0-10-amd64
>linux-image-amd64
>   E: Sub-process /usr/bin/dpkg returned an error code (1)

To purge raspi-firmware, users will need to prevent
/etc/kernel/postinst.d/z50-raspi-firmware from triggering.

A current workaround is to add `exit 0` at the first line of
/etc/kernel/postinst.d/z50-raspi-firmware

I don't know where raspi-firmware was pulled in from, but the package  was
found in both systems where I installed debian bookworm (12) using the amd64
KDE live image. I assume that raspi-firmware is included by default.

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

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

Versions of packages raspi-firmware depends on:
ii  dosfstools  4.2-1
ii  dpkg1.21.22

raspi-firmware recommends no packages.

Versions of packages raspi-firmware suggests:
ii  bluez-firmware 1.2-9
ii  firmware-brcm80211 20230210-5
ii  firmware-misc-nonfree  20230210-5

Bug#1040895: xen-tools: Should run debootstrap etc. through eatmydata

[Samuel Thibault]

Package: xen-tools
Version: 4.9.2-1
Severity: normal

Hello,

dpkg is extra cautious when installing packages and thus emits sync()
barriers to make sure things don't get corrupt on power loss. But when
creating a VM, we don't need such safety, we can just recreate it from
scratch. So xen-create-image's call to debootstrap should use eatmydata,
to avoid the costly sync() calls and thus get way faster.

Samuel

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

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

Versions of packages xen-tools depends on:
ii  debootstrap   1.0.128+nmu2
ii  libconfig-inifiles-perl   3.03-2
ii  libdata-validate-domain-perl  0.10-1.1
ii  libdata-validate-ip-perl  0.31-1
ii  libdata-validate-uri-perl 0.07-2
ii  libfile-slurp-perl.32-2
ii  libfile-which-perl1.27-2
ii  libsort-versions-perl 1.62-3
ii  libtext-template-perl 1.61-1
ii  mount 2.38.1-5+b1
ii  openssh-client1:9.3p1-1
ii  perl  5.36.0-7

Versions of packages xen-tools recommends:
ii  debian-archive-keyring  2023.3
ii  debootstrap 1.0.128+nmu2
ii  e2fsprogs   1.47.0-2
pn  libexpect-perl  
ii  lvm22.03.16-2
pn  rinse   
ii  ubuntu-archive-keyring  2020.06.17.1-1
ii  ubuntu-keyring [ubuntu-archive-keyring] 2020.06.17.1-1
ii  xen-hypervisor-4.14-amd64 [xen-hypervisor]  4.14.5+94-ge49571868d-1
ii  xen-hypervisor-4.17-amd64 [xen-hypervisor]  4.17.1+2-gb773c48e36-1
ii  xen-utils-4.14 [xen-utils]  4.14.5+94-ge49571868d-1
ii  xen-utils-4.17 [xen-utils]  4.17.1+2-gb773c48e36-1

Versions of packages xen-tools suggests:
ii  btrfs-progs6.3.1-1
pn  cfengine2  
ii  grub-xen-host  2.06-13
ii  reiserfsprogs  1:3.6.27-6
ii  xfsprogs   6.3.0-1

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.

Bug#1040894: cap_iab.3 and cap_launch.3: defects fixed in a newer version 2.69

[Bjarni Ingi Gislason]

Package: libcap-dev
Version: 1:2.66-4
Severity: normal

Dear Maintainer,

  Lintian reports defects in two man pages.

  The latest version has fixed these, so providing it would be
beneficial.


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

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

Versions of packages libcap-dev depends on:
ii  libc62.37-5
ii  libcap2  1:2.66-4

libcap-dev recommends no packages.

Versions of packages libcap-dev suggests:
ii  manpages-dev  6.03-2

-- no debconf information

Bug#1040893: ocaml-qcheck: autopkgtest failures with ocaml-dune 3.9

[Dan Bungert]

Source: ocaml-qcheck
Version: 0.20-1
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com

Dear Maintainer,

On Sid and Ubuntu Mantic, autopkgtest failures can be observed.

The first failure has to do with dropping the dune -> ocaml-dune transitional
package:
  Package dune is not available, but is referred to by another package.
  This may mean that the package is missing, has been obsoleted, or
  is only available from another source
  However the following packages replace it:
ocaml-dune

  E: Package 'dune' has no installation candidate
Updating the package name in the test dependencies is sufficient.

If that is resolved, the following failure is seen:
  autopkgtest [20:11:29]: test test: [---
  Error: No dune-project file has been found. A default one is assumed but the
  project might break when dune is upgraded. Please create a dune-project file.
  Hint: generate the project file with: $ dune init project 
  autopkgtest [20:11:30]: test test: ---]

To address the second problem, I propose adding a dune-project file for
autopkgtest use.

Please see the attached debdiff which addresses both of the above issues.
Thanks.

-Dan
diff -Nru ocaml-qcheck-0.20/debian/changelog ocaml-qcheck-0.20/debian/changelog
--- ocaml-qcheck-0.20/debian/changelog  2023-02-03 22:46:04.0 -0700
+++ ocaml-qcheck-0.20/debian/changelog  2023-07-11 17:35:58.0 -0600
@@ -1,3 +1,10 @@
+ocaml-qcheck (0.20-2) unstable; urgency=medium
+
+  * fix autopkgtest - update ocaml-dune test dependency, supply a dune project
+file for examples
+
+ -- Dan Bungert   Tue, 11 Jul 2023 17:35:58 -0600
+
 ocaml-qcheck (0.20-1) unstable; urgency=medium
 
   [ Stéphane Glondu ]
diff -Nru ocaml-qcheck-0.20/debian/tests/control 
ocaml-qcheck-0.20/debian/tests/control
--- ocaml-qcheck-0.20/debian/tests/control  2023-02-03 22:46:04.0 
-0700
+++ ocaml-qcheck-0.20/debian/tests/control  2023-07-11 17:35:58.0 
-0600
@@ -1,3 +1,3 @@
 Tests: test
-Depends: ocaml-nox, ocaml-findlib, dune, @
+Depends: ocaml-nox, ocaml-findlib, ocaml-dune, @
 Restrictions: allow-stderr
diff -Nru ocaml-qcheck-0.20/debian/tests/dune-project-examples 
ocaml-qcheck-0.20/debian/tests/dune-project-examples
--- ocaml-qcheck-0.20/debian/tests/dune-project-examples1969-12-31 
17:00:00.0 -0700
+++ ocaml-qcheck-0.20/debian/tests/dune-project-examples2023-07-11 
17:35:58.0 -0600
@@ -0,0 +1,2 @@
+(lang dune 2.2)
+(name qcheck-examples)
diff -Nru ocaml-qcheck-0.20/debian/tests/test 
ocaml-qcheck-0.20/debian/tests/test
--- ocaml-qcheck-0.20/debian/tests/test 2023-02-03 22:46:04.0 -0700
+++ ocaml-qcheck-0.20/debian/tests/test 2023-07-11 17:35:58.0 -0600
@@ -6,6 +6,7 @@
 trap "rm -rf ${testdir}" 0 INT QUIT ABRT PIPE TERM
 
 cp -r "$(dirname "$0")/../../example" "${testdir}/example"
+cp debian/tests/dune-project-examples "${testdir}/example/dune-project"
 
 cd "${testdir}/example"
 

Bug#1040892: nvtop: disabling one GPU aborts with "We should not be processing a client id twice per update"

[rozbrajaczpoziomow]

Package: nvtop
Version: 3.0.1-1
Severity: normal

Dear Maintainer,

I have a multi-GPU system:
$ lspci -s :00:02.0
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 
v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
$ lspci -s :03:00.0
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
[AMD/ATI] Navi 24 [Radeon RX 6400/6500 XT/6500M] (rev c1)
and am presently using both, but debian nvtop isn't compiled with i915
support, and I don't really care what happens there, and thus I've
disabled the "Xeon" one in Setup, GPU Select>; this caused the following
on the next update, and on restart
nvtop: ./src/extract_gpuinfo_amdgpu.c:946: parse_drm_fdinfo_amd: 
Assertion `!cache_entry_check && "We should not be processing a client id twice 
per update"' failed.
Aborted
config attached.

Best,

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

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

Versions of packages nvtop depends on:
ii  libc6 2.36-9
ii  libncursesw6  6.4-4
ii  libsystemd0   252.6-1
ii  libtinfo6 6.4-4

nvtop recommends no packages.

nvtop suggests no packages.

-- no debconf information
; Please do not edit this file.
; The file is automatically generated and modified by nvtop by pressing F12.
; If you wish to modify an option, use nvtop's setup window (F2) and follow up 
by saving the preference (F12).
[GeneralOption]
UseColor = true
UpdateInterval = 1000
ShowInfoMessages = true

[HeaderOption]
UseFahrenheit = false
EncodeHideTimer = 3.00e+01

[ChartOption]
ReverseChart = false

[ProcessListOption]
HideNvtopProcess = true
SortOrder = descending
SortBy = memory
DisplayField = pId
DisplayField = user
DisplayField = gpuId
DisplayField = type
DisplayField = gpuRate
DisplayField = memory
DisplayField = cpuUsage
DisplayField = cpuMem
DisplayField = cmdline

[Device]
Pdev = :00:02.0
Monitor = true
ShownInfo = gpuRate
ShownInfo = gpuMemRate


[Device]
Pdev = :03:00.0
Monitor = false
ShownInfo = gpuRate
ShownInfo = gpuMemRate

Bug#1040791: bookworm-pu: package schleuder-cli/0.1.0-4+deb12u1

[Georg Faerber]

Hi Adam,

On 23-07-11 21:46:01, Adam D. Barratt wrote:
> Please go ahead.

Thanks, uploaded.

Cheers,
Georg

Bug#1040891: fp-compiler-3.2.0:arm64 configure failure: EInvalidOp: Invalid floating point operation

[Mollusk]

Package: fp-compiler-3.2.0:arm64
Version: 3.2.0+dfsg-12
Severity: important
X-Debbugs-Cc: debian.os...@aleeas.com

Dear Maintainer,

fp-compiler-3.2.0:arm64 completely fails on my system and has never worked.
See below following error: 

sudo dpkg --audit

The following packages are only half configured, probably due to problems
configuring them the first time.  The configuration should be retried using
dpkg --configure  or the configure menu option in dselect:
 fp-compiler-3.2.0:arm64 Free Pascal - compiler

sudo dpkg --configure fp-compiler-3.2.0:arm64

Setting up fp-compiler-3.2.0:arm64 (3.2.0+dfsg-12) ...
An unhandled exception occurred at $00470960:
EInvalidOp: Invalid floating point operation
  $00470960
  $00472FC0
  $00472F04
  $00470FA8
  $00400EEC
  $00402ACC
  $99446E18
  $00400668

dpkg: error processing package fp-compiler-3.2.0:arm64 (--configure):
 installed fp-compiler-3.2.0:arm64 package post-installation script subprocess 
returned error exit status 217
Errors were encountered while processing:
 fp-compiler-3.2.0:arm64

-- System Information:
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable')
Architecture: arm64 (aarch64)

Kernel: Linux 5.10.0-23-arm64 (SMP w/4 CPU threads)
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 fp-compiler-3.2.0 depends on:
ii  binutils   2.35.2-2
ii  debconf [debconf-2.0]  1.5.77
ii  fp-units-rtl-3.2.0 3.2.0+dfsg-12
ii  libc6  2.31-13+deb11u6

Versions of packages fp-compiler-3.2.0 recommends:
ii  fp-utils-3.2.0  3.2.0+dfsg-12

Versions of packages fp-compiler-3.2.0 suggests:
ii  fp-docs-3.2.0  3.2.0+dfsg-12

-- debconf information:
  fp-compiler/rename_cfg: true
  fp-compiler/windres-select: Select manually
  fp-compiler/windres:

Bug#1040890: bullseye-pu: package nvidia-settings-tesla/525.125.06-1~deb12u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
This is a rebuild of nvidia-settings/525.125.06-1~deb12u1 as
nvidia-settings-tesla/525.125.06-1~deb12u1 fixing a potential crash.

[ Impact ]
minor bugfix

[ Tests ]
none, requires nvidia GPU and driver usage to be tested

[ Risks ]
low, in contrib

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

[ Changes ]

[ Other info ]
I prefer to keep nvidia-settings and nvidia-settings-tesla in sync.


Andreas
diff --git a/debian/changelog b/debian/changelog
index f3df7e0..bddb60e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,33 @@
+nvidia-settings-tesla (525.125.06-1~deb12u1) bookworm; urgency=medium
+
+  * Rebuild for bookworm.
+
+ -- Andreas Beckmann   Wed, 12 Jul 2023 01:19:40 +0200
+
+nvidia-settings-tesla (525.125.06-1) unstable; urgency=medium
+
+  * Rebuild as nvidia-settings-tesla.
+
+ -- Andreas Beckmann   Wed, 12 Jul 2023 00:04:57 +0200
+
+nvidia-settings (525.125.06-1) unstable; urgency=medium
+
+  * New upstream release 525.125.06.
+  * New upstream release 525.105.17.
+- Fixed a bug that could cause the nvidia-settings control panel to
+  crash when resetting the display layout.
+  * Upload to unstable.
+
+ -- Andreas Beckmann   Tue, 11 Jul 2023 23:27:45 +0200
+
+nvidia-settings (525.85.05-2) experimental; urgency=medium
+
+  * Move source package back to contrib.
+  * libxnvctrl0, libxnvctrl-dev are now built by src:libxnvctrl.
+  * Upload to experimental.
+
+ -- Andreas Beckmann   Tue, 18 Apr 2023 22:28:02 +0200
+
 nvidia-settings-tesla (525.85.05-1) unstable; urgency=medium
 
   * Rebuild as nvidia-settings-tesla.
diff --git a/debian/copyright b/debian/copyright
index 1c62a8b..d41447d 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -10,7 +10,7 @@ Disclaimer:
  proprietary NVIDIA drivers in non-free.
 
 Files: *
-Copyright: (C) 2004-2021 NVIDIA Corporation
+Copyright: (C) 2004-2023 NVIDIA Corporation
 License: GPL-2
 
 Files: samples/*
diff --git a/doc/version.mk b/doc/version.mk
index 36f5738..33fa123 100644
--- a/doc/version.mk
+++ b/doc/version.mk
@@ -1,4 +1,4 @@
-NVIDIA_VERSION = 525.85.05
+NVIDIA_VERSION = 525.125.06
 
 # This file.
 VERSION_MK_FILE := $(lastword $(MAKEFILE_LIST))
diff --git a/samples/version.mk b/samples/version.mk
index 36f5738..33fa123 100644
--- a/samples/version.mk
+++ b/samples/version.mk
@@ -1,4 +1,4 @@
-NVIDIA_VERSION = 525.85.05
+NVIDIA_VERSION = 525.125.06
 
 # This file.
 VERSION_MK_FILE := $(lastword $(MAKEFILE_LIST))
diff --git a/src/gtk+-2.x/ctkslimm.c b/src/gtk+-2.x/ctkslimm.c
index ed1ca88..d476f59 100644
--- a/src/gtk+-2.x/ctkslimm.c
+++ b/src/gtk+-2.x/ctkslimm.c
@@ -1292,7 +1292,7 @@ static nvDisplayPtr setup_display(CtkMMDialog 
*ctk_mmdialog)
 void update_mosaic_dialog_ui(CtkMMDialog *ctk_mmdialog, nvLayoutPtr layout)
 {
 nvModeLineItemPtr iter;
-char *id;
+char *id = NULL;
 
 if (ctk_mmdialog == NULL) {
 return;
@@ -1300,6 +1300,7 @@ void update_mosaic_dialog_ui(CtkMMDialog *ctk_mmdialog, 
nvLayoutPtr layout)
 
 if (layout) {
 ctk_mmdialog->layout = layout;
+ctk_mmdialog->cur_modeline = NULL;
 }
 
 parse_slimm_layout(ctk_mmdialog,
@@ -1307,12 +1308,14 @@ void update_mosaic_dialog_ui(CtkMMDialog *ctk_mmdialog, 
nvLayoutPtr layout)
_mmdialog->h_overlap_parsed,
_mmdialog->v_overlap_parsed);
 
-id = g_strdup(ctk_mmdialog->cur_modeline->data.identifier);
+if (ctk_mmdialog->cur_modeline) {
+id = g_strdup(ctk_mmdialog->cur_modeline->data.identifier);
+}
 
 setup_display(ctk_mmdialog);
 
 iter = ctk_mmdialog->modelines;
-while (iter->next) {
+while (id && iter->next) {
 if (strcmp(id, iter->modeline->data.identifier) == 0) {
 ctk_mmdialog->cur_modeline = iter->modeline;
 break;
diff --git a/src/libXNVCtrl/version.mk b/src/libXNVCtrl/version.mk
index 36f5738..33fa123 100644
--- a/src/libXNVCtrl/version.mk
+++ b/src/libXNVCtrl/version.mk
@@ -1,4 +1,4 @@
-NVIDIA_VERSION = 525.85.05
+NVIDIA_VERSION = 525.125.06
 
 # This file.
 VERSION_MK_FILE := $(lastword $(MAKEFILE_LIST))
diff --git a/src/nvml.h b/src/nvml.h
index 0da0f8c..9ac2324 100644
--- a/src/nvml.h
+++ b/src/nvml.h
@@ -1,5 +1,5 @@
 /*
- * Copyright 1993-2022 NVIDIA Corporation.  All rights reserved.
+ * Copyright 1993-2023 NVIDIA Corporation.  All rights reserved.
  *
  * NOTICE TO USER:
  *
@@ -525,6 +525,7 @@ typedef enum nvmlValueType_enum
 NVML_VALUE_TYPE_UNSIGNED_LONG = 2,
 NVML_VALUE_TYPE_UNSIGNED_LONG_LONG = 3,
 NVML_VALUE_TYPE_SIGNED_LONG_LONG = 4,
+NVML_VALUE_TYPE_SIGNED_INT = 5,
 
 // Keep this last
 NVML_VALUE_TYPE_COUNT
@@ -537,6 +538,7 @@ typedef enum nvmlValueType_enum
 

Bug#1040889: giac FTBFS on !amd64: FAIL chk_fhan0

[Adrian Bunk]

Source: giac
Version: 1.9.0.57+dfsg2-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=giac=1.9.0.57%2Bdfsg2-1

...
33c33
< 
4.0*(x+0.49788349552099382283094073616854227304830384829676320412646603489)*(x+0.80901699437494742410229341718281905886015458990288143106772431135263023140945+0.58778525229247312916870595463907276859765243764314599107227248075727847416235*I)*(x+0.80901699437494742410229341718281905886015458990288143106772431135263023140945-0.58778525229247312916870595463907276859765243764314599107227248075727847416235*I)*(x-0.30901699437494742410229341718281905886015458990288143106772431135263023140945+0.9510565162951535721164397938214340569863412575022244730564443015317008520*I)*(x-0.30901699437494742410229341718281905886015458990288143106772431135263023140945-0.9510565162951535721164397938214340569863412575022244730564443015317008520*I)*(x+0.50423652873866744096133134925237086727128317399273251261816211367+0.31757869575771877431763872202300318623834849619459415460408363224777378859822e-15*I),
---
> 4.0*(x+0.49788328925430029686609811928022330782155585549767058946497075172)*(x+0.80901699437494742410229341718281905886015458990288143106772431135263023140945+0.58778525229247312916870595463907276859765243764314599107227248075727847416235*I)*(x+0.80901699437494742410229341718281905886015458990288143106772431135263023140945-0.58778525229247312916870595463907276859765243764314599107227248075727847416235*I)*(x-0.30901699437494742410229341718281905886015458990288143106772431135263023140945+0.9510565162951535721164397938214340569863412575022244730564443015317008520*I)*(x-0.30901699437494742410229341718281905886015458990288143106772431135263023140945-0.9510565162951535721164397938214340569863412575022244730564443015317008520*I)*(x+0.50423695020762139072415632649460476103935691753889574803974870605+0.31797400722558614463582272906881192689588258358870001378007305967449842289426e-15*I),
36c36
< 
4.0*(x+0.49788349552099382283094073616854227304830384829676320412646603489)*(x+0.50423652873866744096133134925237086727128317399273251261816211367+0.31757869575771877431763872202300318623834849619459415460408363224777378859822e-15*I)*(x^2-0.61803398874989484820458683436563811772030917980576286213544862270526046281890*x+1.)*(x^2+1.6180339887498948482045868343656381177203091798057628621354486227052604628189*x+1.),
---
> 4.0*(x+0.49788328925430029686609811928022330782155585549767058946497075172)*(x+0.50423695020762139072415632649460476103935691753889574803974870605+0.31797400722558614463582272906881192689588258358870001378007305967449842289426e-15*I)*(x^2-0.61803398874989484820458683436563811772030917980576286213544862270526046281890*x+1.)*(x^2+1.6180339887498948482045868343656381177203091798057628621354486227052604628189*x+1.),
5,7c5,7
< 2.8438669798515,
< 2.8438669798515,
< 2.8438669798515,
---
> 2.8438669798516,
> 2.8438669798516,
> 2.843866979851565477695440,
32,33c32,33
< 
4.4*(x+0.4995802767719425726646262389673108)*(x+0.5004197233049305707985262184456402)*(x+0.80901699437494469055404981865454965242+0.58778525229247103432520509730405154890*I)*(x+0.80901699437494469055404981865454965242-0.58778525229247103432520509730405154890*I)*(x-0.30901699437494853421122297627742029997+0.95105651629515245315101034450709359529*I)*(x-0.30901699437494853421122297627742029997-0.95105651629515245315101034450709359529*I),
< 
4.0*(x+0.49788349552099382283094073616854227304830384829676320412646603489)*(x+0.80901699437494742410229341718281905886015458990288143106772431135263023140945+0.58778525229247312916870595463907276859765243764314599107227248075727847416235*I)*(x+0.80901699437494742410229341718281905886015458990288143106772431135263023140945-0.58778525229247312916870595463907276859765243764314599107227248075727847416235*I)*(x-0.30901699437494742410229341718281905886015458990288143106772431135263023140945+0.9510565162951535721164397938214340569863412575022244730564443015317008520*I)*(x-0.30901699437494742410229341718281905886015458990288143106772431135263023140945-0.9510565162951535721164397938214340569863412575022244730564443015317008520*I)*(x+0.50423652873866744096133134925237086727128317399273251261816211367+0.31757869575771877431763872202300318623834849619459415460408363224777378859822e-15*I),
---
> 4.4*(x+0.8090169944+0.5877852523*I)*(x+0.8090169944-0.5877852523*I)*(x-0.3090169944+0.9510565163*I)*(x-0.3090169944-0.9510565163*I)*(x+0.5+6.773255088e-09*I)*(x+0.5-6.773255088e-09*I),
> 

Bug#1040888: rust-condure FTBFS on architectures with unsigned char

[Adrian Bunk]

Source: rust-condure
Version: 1.10.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=rust-condure=ppc64el=1.10.0-1=1689116835=0

...
error[E0308]: mismatched types
   --> src/lib.rs:161:13
|
158 | if libc::getpwnam_r(
| arguments to this function are incorrect
...
161 | buf.as_mut_ptr() as *mut i8,
| ^^^ expected `u8`, found `i8`
|
= note: expected raw pointer `*mut u8`
   found raw pointer `*mut i8`
note: function defined here

error[E0308]: mismatched types
   --> src/lib.rs:188:13
|
185 | if libc::getgrnam_r(
| arguments to this function are incorrect
...
188 | buf.as_mut_ptr() as *mut i8,
| ^^^ expected `u8`, found `i8`
|
= note: expected raw pointer `*mut u8`
   found raw pointer `*mut i8`
note: function defined here

For more information about this error, try `rustc --explain E0308`.
error: could not compile `condure` due to 2 previous errors
...

Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server

[Alexandru Mihail]

Hello again,

>In short, considering debian-legal's input, should I mention the NCSA
>copyright notice in debian/copyright for Files: htpasswd.c, adding a
>separate License: NCSA field to clarify the provenance of said source
>?

After a bit more research into how other projects treat NCSA bits I'd
propose something along the lines of:

debian/copyright:

Files: htpasswd.c
Copyright: 1993-1994 Rob McCool 
Copyright: 1997 Jef Poskanzer  ?
License: NCSA
 

License: NCSA
This code is in the public domain. Specifically, we give to the public
domain all rights for future licensing of the source code, all resale
rights, and all publishing rights.

We ask, but do not require, that the following message be included in
all derived works:

Portions developed at the National Center for Supercomputing
Applications at the University of Illinois at Urbana-Champaign.

THE UNIVERSITY OF ILLINOIS GIVES NO WARRANTY, EXPRESSED OR IMPLIED,
FOR THE SOFTWARE AND/OR DOCUMENTATION PROVIDED, INCLUDING, WITHOUT
LIMITATION, WARRANTY OF MERCHANTABILITY AND WARRANTY OF FITNESS FOR A
PARTICULAR PURPOSE.

Also, looking into your concerns about public domain in other countries
(specifically referring to NCSA's :"This code is in the public
domain"):

Excerpt from https://wiki.debian.org/DFSGLicenses#Public_Domain :

Q: Since Debian is usually quite careful when it comes to legal issues,
I'm wondering what the official view point is here?

A: The official viewpoint is that the software must meet the
requirements of the DFSG. Generally, a CC0-style PD dedication is
viewed as sufficient for all jurisdictions, and can satisfy the DFSG if
source is available.

Q: Jurisdictions for Public Domain?

A: We are unaware of a case where a jurisdiction has upheld a copyright
claim to a work which has been dedicated to the public domain
everywhere. This is a potential theoretical source of problems, but
there's enough actual problems with copyright and licensing for us to
concentrate our limited time on them instead. 

Q: Should there be a lintian error if the "license" is Public Domain
and a copyright holder is specified?

A: No.

Q: Should Public Domain perhaps be prohibited in general?

A: Definitely not. 

Best,
Alexandru Mihail


On Thu, 2023-07-06 at 23:54 +0300, Alexandru Mihail wrote:
> Hello Nicholas,
> > That's ok, you don't need to find the original version.  Remember
> > that
> > it's a fork and child relationship,
> 
> Yes, I'm terribly sorry, I'm familiar with the fork-child
> relationship
> but I still found your analogy very helpful and concise, I might
> present it to my interns (if that's O.K), thanks a lot for the
> reminder. I was extremely tired when I wrote the last e-mail.
> 
> In short, considering debian-legal's input, should I mention the NCSA
> copyright notice in debian/copyright for Files: htpasswd.c, adding a
> separate License: NCSA field to clarify the provenance of said source
> ?
> 
> 
> I will fix the /patches issues  we discussed in a later commit and
> would also like to propose a mechanism for integrating PAM (Pluggable
> Authentication Modules) into mini-httpd. I am currently in the
> negotiation phase  with my employer to grant an exception for this
> particular patch in order for it to be upstreamed into debian/patches
> (since, remember, we're the de-facto upstream here) and for my code
> to
> become GPL licensed). PAM support (which would be toggled via a
> Makefile parameter) could provide tangible improvements for the 
> users
> of mini-httpd and might even increase the server's popularity. The
> AUTH
> mechanism in mini-httpd is arguably heavily antiquated and prone to
> DDos attacks, MitM, scalability issues, etc. PAM would also enable
> AAA
> solutions to interoperate with mini-httpd almost seamlessly (such as
> Radius, TACACS+) which is becoming increasingly relevant in today's
> SSO/IoT central trust-based use cases.
> 
> > P.S. Please acknowledge: Have you read the DFSG yet, and do you
> > understand why it's important?
> Yes I have and yes I do, it is one of the main reasons I decided to
> start contributing to DebianWiki (and now mini-httpd) to begin with.
> :)
> 
> > I confirm receipt of your mail, and I see an attached signature. 
> > Where
> > can I download your public key?
> 
> I'd like to ask you the same question, since I'd like to add your
> address to my keyring. I've read a bit of documentation which
> suggests
> using Ubuntu's HKP which seems a bit off-axis. I understand that the
> Debian Public Key Server is for DDs and DMs only (I am not yet a DM).
> I could perhaps use my DebianWiki personal page to link to my public
> key, but I do not know if that solution would be accepted or would
> sound absurd. I should find a better solution after some research.
> 
> Stay safe and thanks for your time,
> Alexandru Mihail
> 
> 
> On Wed, 2023-07-05 at 21:01 -0400, Nicholas D Steeves wrote:
> > Hi Alexandru,
> > 
> > Alexandru Mihail  writes:
> > 
> > > After yet some more software archaeology, 

Bug#1040887: anacrontab.5: some remarks and editorial fixes for the manual

[Bjarni Ingi Gislason]

Package: anacron
Version: 2.3-37
Severity: minor
Tags: patch

Dear Maintainer,

here are some notes and editorial fixes for the man page.

The patch is in the attachment.

-.-.

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"groff -man -Z" instead of "nroff -man"

  Read the output of "diff -u" with "less -R" or similar.

-.-.

Output from "mandoc -T lint anacrontab.5":

mandoc: anacrontab.5:14:2: WARNING: skipping paragraph macro: PP empty

-.-.

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.


28:can be any shell command. The fields can be separated by blank spaces or 
tabs.
31:can only be set to monthly at the present time. This will ensure jobs

-.-.

The section part for a manual page is set in roman font.

52:.B anacron(8)

-.-.

Test nr. 55:

Protect a period (.) or a apostrophe (') with '\&' from becoming a
control character, if it could end up at the start of a line (by
splitting the line into more lines).

48:lines with white-space followed by a '#' followed by an arbitrary comment.
50:You can continue a line onto the next line by ending it with a '\e'.

-.-.

Name of a manual is set in bold, the section in roman.
See man-pages(7).

7:describes the jobs controlled by \fBanacron(8)\fR.  Its lines can be of

-.-.

Output from "test-nroff -man -b -ww -z -rCHECKSTYLE=3":


[ "test-groff" is a developmental version of "groff" ]

Input file is ./anacrontab.5

Output from "test-groff -b -mandoc -dAD=l -rF0 -rHY=0 -t -w w -z 
-rSTYLECHECK=3":
an.tmac::13: style: 3 leading space(s) on input line
an.tmac::16: style: 3 leading space(s) on input line
an.tmac::37: style: 3 leading space(s) on input line

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

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

Versions of packages anacron depends on:
ii  libc6  2.37-5
ii  lsb-base   11.6
ii  sysvinit-utils [lsb-base]  3.07-1

Versions of packages anacron recommends:
ii  cron [cron-daemon]  3.0pl1-162

Versions of packages anacron suggests:
ii  exim4-daemon-light [mail-transport-agent]  4.96-16
pn  powermgmt-base 
ii  rsyslog [system-log-daemon]8.2306.0-1

-- no debconf information
The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"groff -man -Z" instead of "nroff -man"

  Read the output of "diff -u" with "less -R" or similar.

-.-.

Output from "mandoc -T lint anacrontab.5":

mandoc: anacrontab.5:14:2: WARNING: skipping paragraph macro: PP empty

-.-.

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.


28:can be any shell command. The fields can be separated by blank spaces or 
tabs.
31:can only be set to monthly at the present time. This will ensure jobs

-.-.

The section part for a manual page is set in roman font.

52:.B anacron(8)

-.-.

Test nr. 55:

Protect a period (.) or a apostrophe (') with '\&' from becoming a
control character, if it could end up at the start of a line (by
splitting the line into more lines).

48:lines with white-space followed by a '#' followed by an arbitrary comment.
50:You can continue a line onto the next line by ending it with a '\e'.

-.-.

Name of a manual is set in bold, the section in roman.
See man-pages(7).

7:describes the jobs controlled by \fBanacron(8)\fR.  Its lines can be of

-.-.

Output from "test-nroff -man -b -ww -z -rCHECKSTYLE=3":


[ "test-groff" is a developmental version of "groff" ]

Input file is 

Bug#1034779: pcre2: Please drop sparc from the JIT architectures in debian/rules

[Matthew Vernon]

Hi,

On 11/07/2023 10:21, John Paul Adrian Glaubitz wrote:

On Mon, 2023-04-24 at 23:28 +0100, Matthew Vernon wrote:

Hi,

On 24/04/2023 10:28, John Paul Adrian Glaubitz wrote:


While we're currently not building Debian for 32-bit SPARC (sparc),
it's still being bootstrapped in the Debian rebootstrap project [1].

The CI job for sparc is currently failing because pcre2 is still being
configured with "--enable-jit" while JIT support [2] for 32-bit SPARC was
dropped upstream [3]. See also for the corresponding change in buildroot [4].


I can remove sparc, certainly. Is this something you would like me to
try and get through the freeze? If not, I'd like to hold off making any
pcre2 uploads until after the release.


Any chance this can be done now?


Thanks for the reminder, and sorry it was necessary. I've pushed 10.42-2 
to unstable, which disables JIT on sparc.


Regards,

Matthew

Bug#1040886: filespooler: phasing out clap version 3.

[Peter Green]

Package: filespooler
Tags: trixie, sid

We have ended up with three versions of the clap crate in Debian.
I'd like to reduce that number. Ideally to only one, but reducing
it from three versions to two would be an improvement.

I'm looking at clap v3 first for a few reasons.

* it was only the "latest version" for less than a year.
* Less software in Debian seems to use v3 than v2.
* We are currently patching clap v3 to work with newer
versions of clap-lex, I'm not sure how sustainable
this is.

I would normally file an upstream bug report first, but I was
unable to find an upstream bugtracker, the upstream source
is hosted on salsa.debian.org and the upstream developer
is a member of the Debian rust team. So filling a debian
bug immediately seemed reasonable.

Bug#1040885: anacron.8: some remarks and editorial fixes for the manual

[Bjarni Ingi Gislason]

Package: anacron
Version: 2.3-37
Severity: minor
Tags: patch

Dear Maintainer,

here are some notes and editorial fixes for the man page.

The patch is in the attachment.

-.-.

The difference between the formatted outputs can be seen with:

  nroff -man  > 
  nroff -man  > 
  diff -u  

and for groff, using

"groff -man -Z" instead of "nroff -man"

  Use "less -R" or similar to read the output of "diff -u".

-.-.

Output from "mandoc -T lint anacron.8":

mandoc: anacron.8:26:38: STYLE: whitespace at end of input line
mandoc: anacron.8:64:93: STYLE: input text line longer than 80 bytes: the 
address containe...
mandoc: anacron.8:107:71: STYLE: whitespace at end of input line
mandoc: anacron.8:134:2: WARNING: skipping paragraph macro: PP after SH
mandoc: anacron.8:167:2: WARNING: skipping paragraph macro: PP after SH
mandoc: anacron.8:184:100: STYLE: input text line longer than 80 bytes: Mail 
comments, sugge...
mandoc: anacron.8:190:86: STYLE: input text line longer than 80 bytes: The code 
base was ma...
mandoc: anacron.8:191:87: STYLE: input text line longer than 80 bytes: During 
2004-2006, it...

-.-.

Change '-' (\-) to '\(en' (en-dash) for a numeric range.
GNU gnulib has recently (2023-06-18) updated its
"build_aux/update-copyright" to recognize "\(en" in man pages.

anacron.8:191:During 2004-2006, it was maintained by Pascal Hakim 
.
anacron.8:192:During 2009-2014, it was maintained by Peter Eisentraut 
.

-.-.

Mark a full stop (.) and the exclamation mark (!) with "\&",
if it does not mean an end of a sentence.
This is a preventive action,
the paragraph could be reshaped, e.g., after changes.

When typing, one does not always notice when the line wraps after the
period.
There are too many examples of input lines in manual pages,
that end with an abbreviation point.

This marking is robust, and independent of the position on the line.

It corresponds to "\ " in TeX, and to "@:" in Texinfo.


71:"Active" jobs (i.e. jobs that Anacron already decided

-.-.

Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.

5:.B anacron \fR[\fB-s\fR] [\fB-f\fR] [\fB-n\fR] [\fB-d\fR] [\fB-q\fR]
6:[\fB-t anacrontab\fR] [\fB-S spooldir\fR] [\fIjob\fR] ...
8:.B anacron [\fB-S spooldir\fR] -u [\fB-t anacrontab\fR] \fR[\fIjob\fR] ...
10:.B anacron \fR[\fB-V\fR|\fB-h\fR]
12:.B anacron -T [\fB-t anacrontab\fR]
54:Unless the \fB-d\fR option is given (see below), Anacron forks to the
58:Unless the \fB-s\fR or \fB-n\fR options are given, Anacron starts jobs
78:.B -f
81:.B -u
85:.B -s
89:.B -n
92:file.  This options implies \fB-s\fR.
94:.B -d
99:.B -q
100:Suppress messages to standard error.  Only applicable with \fB-d\fR.
102:.B -t anacrontab
105:.B -T
110:.B -S spooldir
114:.B -V
117:.B -h

-.-.

Add a comma (or \&) after "e.g." and "i.e.", or use English words
(man-pages(7).
Abbreviation points should be protected against being interpreted as
an end of sentence, if they are not, and that independent of the
current place on the line.

71:"Active" jobs (i.e. jobs that Anacron already decided

-.-.

Wrong distance between sentences.

  Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) ("Conventions for source file layout") and
"info groff" ("Input Conventions").

  The best procedure is to always start a new sentence on a new line,
at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

  The amount of space between sentences in the output can then be
controlled with the ".ss" request.


106:Anacrontab testing. The configuration file will be tested for validity. If
108:return 1. Valid anacrontabs will return 0.
111:Use the specified spooldir to store timestamps in. This option is required 
for
138:On activation, anacron will check if it missed some jobs. If yes, it will 
start
144:connected to the computer. It is meant to reduce power usage and extend
148:supply. Please read Debian-specific documentation in
164:This file provides systemd timer for anacron. Currently the service is
187:. The current implementation is a complete rewrite 
by

-.-.

Protect a period (.) or a apostrophe (') with '\&' from becoming a
control character, if it could end up at the start of a line (by
splitting the line into more lines).

184:Mail comments, suggestions and bug reports to Sean 'Shaleh' Perry 
.
190:The code base was maintained by Sean 'Shaleh' Perry 
.

-.-.

SYNOPSIS: variable (replaceable) text is typeset in italic, see man-page(7).

-.-.

Spelling:

the Debian Project -> The Deb...

-.-.

Avoid a hyphenation in an email address by using '\%' in front of it.

-.-.

Output from "test-nroff -man -b -ww -z -rCHECKSTYLE=3":


[ "test-groff" is a developmental version of "groff" ]

Input file is ./anacron.8

Output from "test-groff -b -mandoc -dAD=l -rF0 -rHY=0 -t -w w -z 

Bug#1040398: python-pytest-benchmark: undeclared dependency on python3-py

[Timo Röhling]

Hi,

On Wed, 05 Jul 2023 15:09:26 +0200 =?utf-8?q?Timo_R=C3=B6hling?= 
 wrote:

The latest upstream release 4.0.0 has fixed the bug. Alternatively, you
could add python3-py to your Depends.

I have just uploaded the latter fix (adding python3-py as
dependency) to DELAYED/2, as ihis bug is blocking the pytest
migration.


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Bug#1040818: libxml2 2.9.14+dfsg-1.3~deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: libxml2
Version: 2.9.14+dfsg-1.3~deb12u1

Explanation: fix NULL pointer dereference issue [CVE-2022-2309]

Bug#1040863: yajl 2.1.0-3+deb12u2 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: yajl
Version: 2.1.0-3+deb12u2

Explanation: fix denial of service issue [CVE-2017-16516], integer overflow 
issue [CVE-2022-24795]

Bug#1040805: systemd 252.12-1~deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: systemd
Version: 252.12-1~deb12u1

Explanation: new upstream stable release

Bug#1040760: marco 1.26.1-3+deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: marco
Version: 1.26.1-3+deb12u1

Explanation: show correct window title when owned by superuser

Bug#1039861: nvidia-graphics-drivers-tesla-470 470.199.02-1~deb12u1 flagged for acceptance

[Adam D Barratt]

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

Hi,

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

Thanks for your contribution!

Upload details
==

Package: nvidia-graphics-drivers-tesla-470
Version: 470.199.02-1~deb12u1

Explanation: new upstream stable release; security fixes [CVE-2023-25515 
CVE-2023-25516]

Bug#1040884: dovecot: stop shipping unsupported lucene fts backend

[Noah Meyerhans]

Source: dovecot
Version: 1:2.3.19.1+dfsg1-2.1
Severity: normal

The Dovecot Lucene FTS backend is not supported and should not be built or
shipped by Debian.  Supported alternatives (dovecot-solr and
dovecot-fts-xapian) are available in Debian and users should migrate to those
instead.


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

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

Bug#1022981: Problem could have been caused by modprobe configuration

[Diederik de Haas]

On Tuesday, 11 July 2023 23:27:13 CEST Juergen Kosel wrote:
> And on my PC was a /etc/modprobe.d/sound.conf ...
> 
> Editing this file and assign index 5 solves the problem for me.
> But is this file needed at all?

Normally you would only use such files/configuration when the *default* does 
not 
do the 'right' thing.
So it's useful to try whether the default now does do the right thing.

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

Bug#1040883: In dark themes the 'eye' to show the typed password isn't visible

[Joerg Schiermeier, Bielefeld/Germany]

Package: pinentry-qt
Version: 1.2.1-1
Severity: normal

Hello!

This is a visual problem with pinentry-qt in dark themes:
When I switch on a dark theme, the 'eye' which is clickable and shows then the 
typed password readable, isn't really visible.

This behaviour should be altered.

Please see the attached Screenshots:
  1) 0_pinentry-qt_2023-07-11_light.png
  2) 1_pinentry-qt_2023-07-11_dark.png

-- 
Yours sincerely
Joerg Schiermeier



-- System Information:
Debian Release: trixie/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.3.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), 
LANGUAGE=de:en_GB:es
Shell: /bin/sh linked to /usr/bin/dash
Init: OpenRC (via /run/openrc), PID 1: init

Versions of packages pinentry-qt depends on:
ii  libassuan0  2.5.5-5
ii  libc6   2.37-5
ii  libgcc-s1   13.1.0-7
ii  libgpg-error0   1.46-1
ii  libncursesw66.4+20230625-1
ii  libqt5core5a5.15.10+dfsg-2
ii  libqt5gui5  5.15.10+dfsg-2
ii  libqt5widgets5  5.15.10+dfsg-2
ii  libstdc++6  13.1.0-7
ii  libtinfo6   6.4+20230625-1

pinentry-qt recommends no packages.

Versions of packages pinentry-qt suggests:
ii  pinentry-doc  1.2.1-1

-- no debconf information

Bug#1040415: bullseye-pu: package pacemaker/2.1.5-1+deb12u1

[Ferenc Wágner]

"Adam D. Barratt"  writes:

> Assuming that all of the changes are in unstable (or not required
> there), please go ahead.

Hi Adam,

All three patches are cherry-picks (although one required manual
backporting) from 2.1.6, which is already in testing.
Source-only upload done, hope it's all right.
-- 
Thanks,
Feri.

Bug#1022981: Problem could have been caused by modprobe configuration

[Juergen Kosel]

Hello,

I had just found
https://unix.stackexchange.com/questions/303471/alsa-audio-device-reordering-cannot-find-the-slot-for-index-0-range-0-1-erro

And on my PC was a /etc/modprobe.d/sound.conf from 2020 (when the PC was 
upgraded to Bullsye) with the content:


```
alias snd-card-0 snd-hda-intel
options snd-hda-intel index=0
```

Through the update to Bookworm the USB camera was detectedearlier than 
before and got already the index 0 :-(

Editing this file and assign index 5 solves the problem for me.
But is this file needed at all?

Greetings
Juergen


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040882: [INTL:ro] Romanian debconf templates translation-revision/update of postfix

[Remus-Gabriel Chelu]

Package: postfix
Version: 3.8.1-2
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «debconf_postfix.ro.po» 
file.
-- 
Thanks,
Remus-Gabriel

debconf_postfix.ro.po
Description: Binary data

Bug#1040881: bookworm-pu: package llvm-defaults/0.55.7~deb12u1

[Andreas Beckmann]

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

[ Reason ]
Since some of the libraries build from the llvm suites are not
co-installable (this is expressed by Conflicts/Replaces/Provides of a
virtual package), this is sometimes tricky for apt to figure out since
it involves removing an installed package in order to install another
one with the same score ...
Adding more Breaks against the default versions from oldstable moves the
scores in favor of installing the new packages and removing the obsolete
ones.
There was also a bad symlink in the liblld-dev package, which as
pointing to lldb headers ...

[ Impact ]
Upgrades may have kept some packages at the version from oldstable even
though there is a newer version in stable.

[ Tests ]
I've performed local piuparts bullseye->bookworm upgrade tests with the
patched packages as upgrade targets and it has resolved all incomplete
upgrade issues.

[ Risks ]
Low. All the new Breaks are against packages not in bookworm, so
should not affect new installations.

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

[ Changes ]
  * Add Breaks against not co-installable packages for smoother upgrades from
bullseye.  (Closes: #1036580)
  * Fix /usr/include/lld symlink.  (Closes: #1036577)
  * Silent the breaks-without-version lintian warnings

[ Other info ]
n/a

Andreas
diff --git a/debian/changelog b/debian/changelog
index ac0c76b..9873b51 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,21 @@
+llvm-defaults (0.55.7~deb12u1) bookworm; urgency=medium
+
+  * Rebuild for bookworm.
+
+ -- Andreas Beckmann   Tue, 11 Jul 2023 22:52:44 +0200
+
+llvm-defaults (0.55.7) unstable; urgency=medium
+
+  [ Andreas Beckmann ]
+  * Add Breaks against not co-installable packages for smoother upgrades from
+bullseye.  (Closes: #1036580)
+  * Fix /usr/include/lld symlink.  (Closes: #1036577)
+
+  [ Sylvestre Ledru ]
+  * Silent the breaks-without-version lintian warnings
+
+ -- Sylvestre Ledru   Tue, 11 Jul 2023 13:00:54 +0200
+
 llvm-defaults (0.55.6) unstable; urgency=medium
 
   * Add s390x in the lld supported archs
diff --git a/debian/control b/debian/control
index 051a071..44e1959 100644
--- a/debian/control
+++ b/debian/control
@@ -254,6 +254,7 @@ Architecture: any
 Section: libdevel
 Depends: ${shlibs:Depends}, ${misc:Depends},
  liblldb-${pv:llvm}-dev ${reqv:llvm}
+Breaks: lldb-11, python3-lldb-11
 Multi-Arch: same
 Description: Next generation, high-performance debugger, header files
  LLDB is a next generation, high-performance debugger. It is built as a set of
@@ -266,6 +267,7 @@ Package: lldb
 Architecture: any
 Depends: lldb-${pv:llvm} ${reqv:llvm}, ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
+Breaks: lldb-11, python3-lldb-11
 Multi-Arch: same
 Description: Next generation, high-performance debugger
  LLDB is a next generation, high-performance debugger. It is built as a set of
@@ -308,7 +310,7 @@ Section: python
 Architecture: any
 Depends: python3-lldb-${pv:llvm} ${reqv:llvm}, ${misc:Depends}
 Replaces: python-lldb (<< 0.49~exp2)
-Breaks: python-lldb (<< 0.49~exp2)
+Breaks: python-lldb (<< 0.49~exp2), python3-lldb-11
 Description: Next generation, high-performance debugger, python lib
  LLDB is a next generation, high-performance debugger. It is built as a set of
  reusable components which highly leverage existing libraries in the larger 
LLVM
@@ -348,6 +350,7 @@ Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: libc++1-${pv:llvm} ${reqv:llvm}, ${shlibs:Depends}, ${misc:Depends}
+Breaks: libc++1-11, libc++abi1-11
 Description: LLVM C++ Standard library
  libc++ is another implementation of the C++ standard library.
  .
@@ -368,6 +371,7 @@ Section: libdevel
 Architecture: any
 Multi-Arch: same
 Depends: libc++-${pv:llvm}-dev ${reqv:llvm}, ${misc:Depends}
+Breaks: libc++1-11, libc++abi1-11
 Description: LLVM C++ Standard library (development files)
  libc++ is another implementation of the C++ standard library
  .
@@ -390,6 +394,7 @@ Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: libc++abi1-${pv:llvm} ${reqv:llvm}, ${shlibs:Depends}, ${misc:Depends}
+Breaks: libc++abi1-11
 Description: LLVM low level support for a standard C++ library
  libc++abi is another implementation of low level support for a standard C++
  library.
@@ -407,6 +412,7 @@ Section: libdevel
 Architecture: any
 Multi-Arch: same
 Depends: libc++abi-${pv:llvm}-dev ${reqv:llvm}, ${misc:Depends}
+Breaks: libc++abi1-11
 Description: LLVM low level support for a standard C++ library (development 
files)
  libc++abi is another implementation of low level support for a standard C++
  library.
diff --git 

Bug#1022981: Problem might be Bookworm related

[Juergen Kosel]

Hello,

I have just booted with the old kernel from Bullseye (5.10.0-22-amd64) 
and even with this kernel the problem occurs now (which was not the case 
with Bullseye user land).

Also now the dmesg contains this lines:

[4.068265] usbcore: registered new interface driver uvcvideo
[4.068961] USB Video Class driver (1.1.1)
[4.070952] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[4.071636] iTCO_wdt: Found a Intel PCH TCO device (Version=4, 
TCOBASE=0x0400)

[4.079588] cryptd: max_cpu_qlen set to 1000
[4.080360] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[4.091550] AVX2 version of gcm_enc/dec engaged.
[4.092258] AES CTR mode by8 optimization enabled
[4.132127] cx23885: cx23885 driver version 0.0.4 loaded
[4.135922] usb 1-4: current rate 33186 is different from the runtime 
rate 48000

[4.139668] usbcore: registered new interface driver snd-usb-audio
[4.141056] cx23885 :03:00.0: enabling device ( -> 0002)
[4.141993] cx23885: CORE cx23885[0]: subsystem: 0070:c12a, board: 
Hauppauge WinTV Starburst [card=53,autodetected]
[4.183988] snd_hda_intel :00:1f.3: cannot find the slot for 
index 0 (range 0-0), error: -16

[4.184682] snd_hda_intel :00:1f.3: Error creating card!
[4.185423] snd_hda_intel: probe of :00:1f.3 failed with error -16
[4.189865] snd_hda_intel :01:00.1: cannot find the slot for 
index 0 (range 0-0), error: -16

[4.190684] snd_hda_intel :01:00.1: Error creating card!
[4.191434] snd_hda_intel: probe of :01:00.1 failed with error -16



Greetings
Juergen


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040880: nsis: CVE-2023-37378

[Salvatore Bonaccorso]

Source: nsis
Version: 3.08-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.06.1-1

Hi,

The following vulnerability was published for nsis.

CVE-2023-37378[0]:
| Nullsoft Scriptable Install System (NSIS) before 3.09 mishandles
| access control for an uninstaller directory.


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

Regards,
Salvatore

Bug#1040716: libc6: Stack Traces

[Tim McConnell]

On Tue, 2023-07-11 at 22:34 +0200, Aurelien Jarno wrote:
> Hi,
> 
> On 2023-07-11 15:28, Tim McConnell wrote:
> > 
> > 
> > On Tue, 2023-07-11 at 21:11 +0200, Aurelien Jarno wrote:
> > > Hi,
> > > 
> > > On 2023-07-11 11:21, Tim McConnell wrote:
> > > > 
> > > > 
> > > > On Mon, 2023-07-10 at 23:17 +0200, Aurelien Jarno wrote:
> > > > > You might want
> > > > > to upgrade to version 2.37-5 to check if it solves your issue
> > > > Okay that's done and it's still doing it. The entry from
> > > > Journalctl
> > > > shows module libudev1 if that's of any use. 
> > > >  
> > > > Started systemd-coredump@1785-616863-0.service - Process Core
> > > > Dump
> > > > (PID
> > > > 616863/UID 0).
> > > > Jul 11 10:52:06 DebianTim systemd-coredump[616865]: Process
> > > > 616847
> > > > (collectd) of user 0 dumped core.
> > > >     
> > > >     Module
> > > > libudev.so.1
> > > > from deb systemd-252.11-1.amd64
> > > >     Stack trace
> > > > of
> > > > thread 616848:
> > > >     #0 
> > > > 0x7fce1335e9f2 __memmove_ssse3 (libc.so.6 + 0x16d9f2)
> > > >     #1 
> > > > 0x7fce131156d9 rrd_write (librrd.so.8 + 0x346d9)
> > > >     #2 
> > > > 0x7fce13120acd n/a (librrd.so.8 + 0x3facd)
> > > >     #3 
> > > > 0x7fce13122962 n/a (librrd.so.8 + 0x41962)
> > > >     #4 
> > > > 0x7fce1317c370 n/a (rrdtool.so + 0x3370)
> > > >     #5 
> > > > 0x7fce132793ec start_thread (libc.so.6 + 0x883ec)
> > > >     #6 
> > > > 0x7fce132f9a1c __clone3 (libc.so.6 + 0x108a1c)
> > > >     
> > > 
> > > Thanks for the details. This shows that the binary crashing
> > > regularly
> > > is
> > > collectd. This is very unlikely that the issue is linked to the
> > > locales,
> > > and your test is confirming that.
> > > 
> > > It's also not clear that it's a glibc issue, it's more likely an
> > > issue
> > > in collectd or librrd8. It appears that systemd-coredump saved a
> > > coredump when the process crashed. You should be able do use
> > > "coredumpctl" to get the list of cores. You can select one
> > > coredump
> > > and
> > > examine it with gdb using "coredumpctl debug ". Then when
> > > under
> > > gdb
> > > you should be able to run "thread apply all bt" to get the
> > > backtrace.
> > > That should allows to better understand the issue.
> > > 
> > > Regards
> > > Aurelien
> > > 
> > I'm unsure how helpful this is ( I am not a programmer) but: 
> > thread apply all bt
> 
> Thanks, that's already much more useful. However I forgot to tell you
> to
> install the libc6-dbg package before getting the backtrace, sorry
> about
> that. Could you please install it and follow the same procedure
> again?
> 
> Thanks
> Aurelien
> 
It's already there, any others? 

Bug#833012: uscan: don't look for OpenPGP signatures by appending .asc to a query string

[Matthias Geiger]

I think I ran into this bug today.

https://gitlab.gnome.org/cheywood/iotas and 
https://gitlab.gnome.org/World/Shortwave only publish unsigned tarballs. 
uscan thinks there is a .asc file present though:


```

...

uscan info: Not downloading, using existing file: iotas-0.1.16.tar.bz2
uscan info: Start checking for common possible upstream OpenPGP 
signature files

uscan warn: Possible OpenPGP signature found at:
https://gitlab.gnome.org/cheywood/iotas/-/archive/0.1.16/iotas-0.1.16.tar.bz2.asc
 * Add opts=pgpsigurlmangle=s/$/.asc/ or opts=pgpmode=auto to debian/watch
 * Add debian/upstream/signing-key.asc.
 See uscan(1) for more details
uscan info: End checking for common possible upstream OpenPGP signature 
files

uscan info: Missing OpenPGP signature.
uscan info: New orig.tar.* tarball version (oversionmangled): 0.1.16
...

```

The asc leads to a 404 (when being logged in to GNOME gitlab) and the 
login page otherwise. These are the only two cases where I had this bug 
(note that I do maintain a few other


packages hosted at GNOMES GL instance).


regards,

werdahias



OpenPGP_0x18BD106B3B6C5475.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040879: redis: CVE-2023-36824: Heap overflow in COMMAND GETKEYS and ACL evaluation

[Salvatore Bonaccorso]

Source: redis
Version: 5:7.0.11-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for redis.

CVE-2023-36824[0]:
| Redis is an in-memory database that persists on disk. In Redit 7.0
| prior to 7.0.12, extracting key names from a command and a list of
| arguments may, in some cases, trigger a heap overflow and result in
| reading random heap memory, heap corruption and potentially remote
| code execution. Several scenarios that may lead to authenticated
| users executing a specially crafted `COMMAND GETKEYS` or `COMMAND
| GETKEYSANDFLAGS`and authenticated users who were set with ACL rules
| that match key names, executing a specially crafted command that
| refers to a variadic list of key names. The vulnerability is patched
| in Redis 7.0.12.


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-36824
https://www.cve.org/CVERecord?id=CVE-2023-36824
[1] https://github.com/redis/redis/security/advisories/GHSA-4cfx-h9gq-xpx3

Regards,
Salvatore

Bug#1040791: bookworm-pu: package schleuder-cli/0.1.0-4+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2023-07-10 at 16:38 +, Georg Faerber wrote:
> Ruby 3.1, as shipped in bookworm, changes the way values are escaped,
> in
> contrast to Ruby <= 3.0. This was fixed upstream in schleuder-cli
> quite
> some time ago, but so far not released.
> 
> The patch was pulled into Debian unstable via 0.1.0-5.
> 

Please go ahead.

Regards,

Adam

Bug#1040878: precious: phasing out clap version 3.

[Peter Green]

Package: precious
Tags: trixie, sid, fixed-upstream

We have ended up with three versions of the clap crate in Debian.
I'd like to reduce that number. Ideally to only one, but reducing
it from three versions to two would be an improvement.

I'm looking at clap v3 first for a few reasons.

* it was only the "latest version" for less than a year.
* Less software in Debian seems to use v3 than v2.
* We are currently patching clap v3 to work with newer
versions of clap-lex, I'm not sure how sustainable
this is.

I looked at the upstream repo for precious and they seem
to have updated to clap v4 in git, but haven't yet included
that in a release.

https://github.com/containers/netavark/commit/f0d5cc86ba3460a2c8e73d734f32a5095d60813a

Please consider moving to clap v4.

Bug#1040770: bookworm-pu: package nvidia-settings/525.125.06-1~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2023-07-10 at 13:54 +0200, Andreas Beckmann wrote:
> In prepararion to upgrading nvidia-graphics-drivers(-tesla) to the
> 535
> series (a new LTSB branch announced last week and supported until
> June 2026, i.e. sufficient for bookworm) I'd like to split
> src:nvidia-settings (building binary packages in main and contrib)
> into
> src:libxnvctrl (in main) and src:nvidia-settings (in contrib).
> src:libxnvctrl will most likely see no further updates over the
> lifetime
> of bookworm, while src:nvidia-settings will need new upstream
> releases
> going into stable as the driver packages get updated.
> As a side effect of this decoupling, bin:nvidia-settings will no
> longer
> be a key package, removing a lot of contrib and non-free packages
> from
> the key package set.
> At the same time I'd like to update nvidia-settings to a new upstream
> release fixing a crash.
> 

Please go ahead.

Regards,

Adam

Bug#1040768: bullseye-pu: package libxnvctrl/525.85.05-3~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2023-07-10 at 12:22 +0200, Andreas Beckmann wrote:
> In prepararion to upgrading nvidia-graphics-drivers(-tesla) to the
> 535
> series (a new LTSB branch announced last week and supported until
> June 2026, i.e. sufficient for bookworm) I'd like to split
> src:nvidia-settings (building binary packages in main and contrib)
> into
> src:libxnvctrl (in main) and src:nvidia-settings (in contrib).
> src:libxnvctrl will most likely see no further updates over the
> lifetime
> of bookworm, while src:nvidia-settings.
> As a side effect of this decoupling, bin:nvidia-settings will no
> longer
> be a key package, removing a lot of contrib and non-free packages
> from
> the key package set.
> 

Please go ahead, and we'll keep our fingers crossed everything works
out as planned.

> [ Other info ]
> This package may require stable-NEW processing.
> 

It /will/.

Regards,

Adam

Bug#1040686: libpdfbox-java: Missing build dependency on lcdf-typetool OR extraneous other relation in debian/

[Andreas Beckmann]

Control: severity -1 important

On Sun, 09 Jul 2023 05:59:51 -0400 Theodoric Stier  
wrote:

This package fails to build when lcdf-typetool is not installed, but
only during packaging. It appears not to be used during the build.
Maybe it's supposed to be a build dependency. If it isn't supposed to
be a build dependency, then the build should succeed without its presence.


I can't reproduce the FTBFS using the bookworm source package in minimal 
sid and bookworm pbuilder chroots (there is only the message 
'dpkg-query: no packages found matching lcdf-typetools' in the output 
which does not seem fatal), therefore this probably does not need a fix 
in (old-)stable and I'm downgrading the severity accordingly.


Andreas

Bug#1040765: bookworm-pu: package nvidia-modprobe/535.54.03-1~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2023-07-10 at 10:42 +0200, Andreas Beckmann wrote:
> In prepararion to upgrading nvidia-graphics-drivers(-tesla) to the
> 535
> series (a new LTSB branch announced last week and supported until
> June 2026, i.e. sufficient for bookworm) I'd like to update
> nvidia-modprobe to a new upstream release.
> 

Please go ahead.

Regards,

Adam

Bug#1040782: Me too

[Laurent Martelli]

I confirm this bug. I have a Wacom Intuos Pro M, and when one of the
associated input devices is not disabled in the input devices
settings, I soon as I start to draw with the tablet's pen, Gimp
crashes.

$ LANG=C dpkg -l *wacom*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version  Architecture Description
+++----
ii  libwacom-bin 2.6.0-1  amd64Wacom model
feature query library -- binaries
ii  libwacom-common  2.6.0-1  all  Wacom model
feature query library (common files)
ii  libwacom9:amd64  2.6.0-1  amd64Wacom model
feature query library
un  wacom-tools(no description
available)
ii  xserver-xorg-input-wacom 1.2.0-1  amd64X.Org X server
-- Wacom input driver





```
GNU Image Manipulation Program version 2.10.34
git-describe: GIMP_2_10_34
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
12.2.0-14' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2
--prefix=/usr --with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-bTRWOB/gcc-12-12.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Debian 12.2.0-14)

# Libraries #
using babl version 0.1.106 (compiled against version 0.1.98)
using GEGL version 0.4.44 (compiled against version 0.4.42)
using GLib version 2.74.6 (compiled against version 2.74.5)
using GdkPixbuf version 2.42.10 (compiled against version 2.42.10)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.50.14 (compiled against version 1.50.12)
using Fontconfig version 2.14.1 (compiled against version 2.14.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Abandon

Stack trace:
```

# Stack traces obtained from PID 56416 - Thread 56416 #

[New LWP 56417]
[New LWP 56418]
[New LWP 56419]
[New LWP 56420]
[New LWP 56421]
[New LWP 56422]
[New LWP 56423]
[New LWP 56424]
[New LWP 56425]
[New LWP 56427]
[New LWP 56531]
[New LWP 56544]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__GI___libc_read (nbytes=256, buf=0x7ffed56c5a70, fd=17) at
../sysdeps/unix/sysv/linux/read.c:26
  Id   Target Id   Frame
* 1Thread 0x7f626ed61300 (LWP 56416) "gimp"
__GI___libc_read (nbytes=256, buf=0x7ffed56c5a70, fd=17) at
../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7f626e4316c0 (LWP 56417) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3Thread 0x7f626dc306c0 (LWP 56418) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  4Thread 0x7f626542f6c0 (LWP 56419) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5Thread 0x7f626d42f6c0 (LWP 56420) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  6Thread 0x7f626cc2e6c0 (LWP 56421) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  7Thread 0x7f6267fff6c0 (LWP 56422) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  8Thread 0x7f62677fe6c0 (LWP 56423) "worker"  syscall () at
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  9Thread 0x7f62662fd6c0 (LWP 56424) "gmain"
0x7f626fa549ef in __GI___poll (fds=0x562b2d842f20, nfds=2,
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  10   Thread 0x7f6246c0 (LWP 56425) "gdbus"
0x7f626fa549ef in 

Bug#1040877: netavark: phasing out clap version 3.

[Peter Green]

reassign 1040877 netavark
thanks

> Package: aardvark-dns

Sorry this bug report was supposed to be for netavark


Tags: trixie, sid, fixed-upstream

We have ended up with three versions of the clap crate in Debian.
I'd like to reduce that number. Ideally to only one, but reducing
it from three versions to two would be an improvement.

I'm looking at clap v3 first for a few reasons.

* it was only the "latest version" for less than a year.
* Less software in Debian seems to use v3 than v2.
* We are currently patching clap v3 to work with newer
versions of clap-lex, I'm not sure how sustainable
this is.

I looked at the upstream repo for aardvark-dons and they seem
to have updated to clap v4 in release 1.7.0, the fix also
doesn't look like it would be horrible to backport

https://github.com/containers/netavark/commit/f0d5cc86ba3460a2c8e73d734f32a5095d60813a

Please consider moving to clap v4.

Bug#1040756: bookworm-pu: package spip/4.1.9+dfsg-1+deb12u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2023-07-10 at 07:28 +0200, David Prévot wrote:
> Another upstream release fixed a security issue. It introduces some
> factorisation adding two more clean up in sessions. We agreed with
> the
> security team that this don’t warrant a DSA.
> 
> https://blog.spip.net/Mise-a-jour-de-maintenance-et-securite-sortie-de-SPIP-4-2-4-SPIP-4-1-11.html
> 
> 

Please go ahead.

Regards,

Adam

Bug#1040876: Acknowledgement (aardvark-dns: phasing out clap version 3.)

[Peter Green]

> 
https://github.com/containers/netavark/commit/f0d5cc86ba3460a2c8e73d734f32a5095d60813a

Sorry, the homepage link for aardvark-dns pointed me to the netavark repo,
the commit for aardvark-dns is.

https://github.com/containers/aardvark-dns/commit/e6ce1a5bb8b2a91edb1424a6f32d7281c0dfce03

Bug#1022981: linux-image-6.1.0-9-amd64: No sound after upgrade from Bullseye to Bookworm

[Juergen Kosel]

Package: src:linux
Version: 6.1.27-1
Followup-For: Bug #1022981

Dear Maintainer,


I have upgraded from Bullseye to Bookworm on 2023-07-09.
After the upgrade the sound card was not available.
lspci: 00:1f.3 Audio device: Intel Corporation 100 Series/C230
Series Chipset Family HD Audio Controller (rev 31)
Only an USB headset became active, if plugged in.


I thought, that it is the same issue as discussed in
https://forums.debian.net/viewtopic.php?t=153430

So I tried several proposals from this page,
including reset of the computer.


After the reset the sound card was working in SOME cases.
But in most cases it is not working.

dmesg indicates that this is a problem of the kernel:

```
[5.058232] snd_hda_intel :00:1f.3: cannot find the slot for 
index 0 (range 0-0), error: -16

[5.058933] snd_hda_intel :00:1f.3: Error creating card!
[5.062791] snd_hda_intel: probe of :00:1f.3 failed with error -16
[5.063526] snd_hda_intel :01:00.1: cannot find the slot for 
index 0 (range 0-0), error: -16
[5.064137] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 
470.182.03  Fri Feb 24 03:29:56 UTC 2023

[5.064212] snd_hda_intel :01:00.1: Error creating card!
[5.066609] snd_hda_intel: probe of :01:00.1 failed with error -16
```



-- Package-specific info:
** Version:
Linux version 6.1.0-9-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.27-1 (2023-05-08)


** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64 
root=UUID=83029ae7-127e-4e74-98cc-1fd9dffe0a1e ro panic=5 
fsck.repair=yes console=tty0 panic=5 fsck.repair=yes apparmor=1 
security=apparmor


** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[4.308306] input: Sleep Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input2

[4.308797] EDAC ie31200: No ECC support
[4.311241] ACPI: button: Sleep Button [SLPB]
[4.311855] input: Power Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input3

[4.313210] ACPI: button: Power Button [PWRB]
[4.313823] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4

[4.324870] intel_pmc_core INT33A1:00:  initialized
[4.347422] ACPI: button: Power Button [PWRF]
[4.348455] r8169 :02:00.0: firmware: direct-loading firmware 
rtl_nic/rtl8168h-2.fw
[4.378898] Generic FE-GE Realtek PHY r8169-0-200:00: attached PHY 
driver (mii_bus:phy_addr=r8169-0-200:00, irq=MAC)

[4.574769] r8169 :02:00.0 eth0: Link is Down
[4.696493] nvidia: loading out-of-tree module taints kernel.
[4.697088] nvidia: module license 'NVIDIA' taints kernel.
[4.697643] Disabling lock debugging due to kernel taint
[4.827187] nvidia: module verification failed: signature and/or 
required key missing - tainting kernel

[4.834069] input: PC Speaker as /devices/platform/pcspkr/input/input5
[4.837138] ee1004 1-0051: 512 byte EE1004-compliant SPD EEPROM, 
read-only
[4.837744] ee1004 1-0053: 512 byte EE1004-compliant SPD EEPROM, 
read-only

[4.938278] iTCO_vendor_support: vendor-support=0
[4.940872] nvidia-nvlink: Nvlink Core is being initialized, major 
device number 242


[4.944062] mei_me :00:16.0: enabling device ( -> 0002)
[4.946097] usb 1-4: Found UVC 1.00 device USB 2.0 Camera (2ce3:c670)
[4.947156] nvidia :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem
[4.955416] input: USB 2.0 Camera as 
/devices/pci:00/:00:14.0/usb1/1-4/1-4:1.0/input/input6

[4.956179] usbcore: registered new interface driver uvcvideo
[4.972779] iTCO_wdt iTCO_wdt: Found a Intel PCH TCO device 
(Version=4, TCOBASE=0x0400)

[4.973643] iTCO_wdt iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[5.058232] snd_hda_intel :00:1f.3: cannot find the slot for 
index 0 (range 0-0), error: -16

[5.058933] snd_hda_intel :00:1f.3: Error creating card!
[5.062791] snd_hda_intel: probe of :00:1f.3 failed with error -16
[5.063526] snd_hda_intel :01:00.1: cannot find the slot for 
index 0 (range 0-0), error: -16
[5.064137] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 
470.182.03  Fri Feb 24 03:29:56 UTC 2023

[5.064212] snd_hda_intel :01:00.1: Error creating card!
[5.066609] snd_hda_intel: probe of :01:00.1 failed with error -16
[5.067375] cx23885: cx23885 driver version 0.0.4 loaded
[5.069045] RAPL PMU: API unit is 2^-32 Joules, 3 fixed counters, 
655360 ms ovfl timer

[5.069723] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[5.070379] RAPL PMU: hw unit of domain package 2^-14 Joules
[5.071048] RAPL PMU: hw unit of domain dram 2^-14 Joules
[5.078235] cryptd: max_cpu_qlen set to 1000
[5.079038] usb 1-4: current rate 33186 is different from the runtime 
rate 48000

[

Bug#1040739: bullseye-pu: package desktop-base/12.0.6+nmu1~deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2023-07-09 at 23:49 +0200, Andreas Beckmann wrote:
> When the emeral theme was added to the alternatives, it was forgotten
> to
> add that to the alternatives removal, too.
> 
> [ Impact ]
> Leaving broken alternatives after package removal, probably only
> noticable by QA tooling.
> 

Please go ahead.

Regards,

Adam

Bug#1040683: bookworm-pu: package node-webpack/5.75.0+dfsg+~cs17.16.14-1+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2023-07-09 at 11:58 +0400, Yadd wrote:
> node-webpack is vulnerable to cross-realm object access
> (#1032904, CVE-2023-28154).
> 

Please go ahead.

Regards,

Adam

Bug#1039911: transition: sdl12-compat taking over libsdl1.2-dev

[Simon McVittie]

On Tue, 11 Jul 2023 at 22:08:55 +0200, Sebastian Ramacher wrote:
> On 2023-06-29 13:26:03 +0100, Simon McVittie wrote:
> > As previously mentioned on -devel, I would like src:sdl12-compat to
> > take over the libsdl1.2-dev and libsdl1.2debian binary package names
> > from src:libsdl1.2 during the trixie cycle. This mirrors a transition
> > that already took place in several other distributions such as Fedora
> > and Arch.
> 
> Please go ahead and raise the remaining regression bugs to serious.

Thanks, I'll upload the equivalent of sdl12-compat/experimental to
unstable soon.

In the end none of the build regressions needed raising to RC:

- #1039479, #1039575, #1039581 have been fixed
- #1012232, #1039439, #1039574 have workarounds in upstream
  sdl12-compat, which I backported into Debian already

The two runtime regressions #1038738, #1038741 are currently tracked as
bugs in both sdl12-compat and the relevant game (it's not clear which
side a fix should come from), and I don't think they're bad enough to
qualify as RC (the game can still be played, and in particular using
native X11 instead of Xwayland is a workaround).

smcv

Bug#1040716: libc6: Stack Traces

[Aurelien Jarno]

Hi,

On 2023-07-11 15:28, Tim McConnell wrote:
> 
> 
> On Tue, 2023-07-11 at 21:11 +0200, Aurelien Jarno wrote:
> > Hi,
> > 
> > On 2023-07-11 11:21, Tim McConnell wrote:
> > > 
> > > 
> > > On Mon, 2023-07-10 at 23:17 +0200, Aurelien Jarno wrote:
> > > > You might want
> > > > to upgrade to version 2.37-5 to check if it solves your issue
> > > Okay that's done and it's still doing it. The entry from Journalctl
> > > shows module libudev1 if that's of any use. 
> > >  
> > > Started systemd-coredump@1785-616863-0.service - Process Core Dump
> > > (PID
> > > 616863/UID 0).
> > > Jul 11 10:52:06 DebianTim systemd-coredump[616865]: Process 616847
> > > (collectd) of user 0 dumped core.
> > >     
> > >     Module
> > > libudev.so.1
> > > from deb systemd-252.11-1.amd64
> > >     Stack trace of
> > > thread 616848:
> > >     #0 
> > > 0x7fce1335e9f2 __memmove_ssse3 (libc.so.6 + 0x16d9f2)
> > >     #1 
> > > 0x7fce131156d9 rrd_write (librrd.so.8 + 0x346d9)
> > >     #2 
> > > 0x7fce13120acd n/a (librrd.so.8 + 0x3facd)
> > >     #3 
> > > 0x7fce13122962 n/a (librrd.so.8 + 0x41962)
> > >     #4 
> > > 0x7fce1317c370 n/a (rrdtool.so + 0x3370)
> > >     #5 
> > > 0x7fce132793ec start_thread (libc.so.6 + 0x883ec)
> > >     #6 
> > > 0x7fce132f9a1c __clone3 (libc.so.6 + 0x108a1c)
> > >     
> > 
> > Thanks for the details. This shows that the binary crashing regularly
> > is
> > collectd. This is very unlikely that the issue is linked to the
> > locales,
> > and your test is confirming that.
> > 
> > It's also not clear that it's a glibc issue, it's more likely an
> > issue
> > in collectd or librrd8. It appears that systemd-coredump saved a
> > coredump when the process crashed. You should be able do use
> > "coredumpctl" to get the list of cores. You can select one coredump
> > and
> > examine it with gdb using "coredumpctl debug ". Then when under
> > gdb
> > you should be able to run "thread apply all bt" to get the backtrace.
> > That should allows to better understand the issue.
> > 
> > Regards
> > Aurelien
> > 
> I'm unsure how helpful this is ( I am not a programmer) but: 
> thread apply all bt

Thanks, that's already much more useful. However I forgot to tell you to
install the libc6-dbg package before getting the backtrace, sorry about
that. Could you please install it and follow the same procedure again?

Thanks
Aurelien

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

Bug#1040680: bookworm-pu: package node-openpgp-seek-bzip/1.0.5-2+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2023-07-09 at 09:35 +0400, Yadd wrote:
> src:node-openpgp-seek-bzip provides:
>  * a Node.js module (node-openpgp-seek-bzip)
>  * command-line scripts (seek-bzip)
> 
> This second package is unusable due to missing files and broken
> links.
> 

Please go ahead.

Regards,

Adam

Bug#1040877: aardvark-dns: phasing out clap version 3.

[Peter Green]

Package: aardvark-dns
Tags: trixie, sid, fixed-upstream

We have ended up with three versions of the clap crate in Debian.
I'd like to reduce that number. Ideally to only one, but reducing
it from three versions to two would be an improvement.

I'm looking at clap v3 first for a few reasons.

* it was only the "latest version" for less than a year.
* Less software in Debian seems to use v3 than v2.
* We are currently patching clap v3 to work with newer
versions of clap-lex, I'm not sure how sustainable
this is.

I looked at the upstream repo for aardvark-dons and they seem
to have updated to clap v4 in release 1.7.0, the fix also
doesn't look like it would be horrible to backport

https://github.com/containers/netavark/commit/f0d5cc86ba3460a2c8e73d734f32a5095d60813a

Please consider moving to clap v4.

Bug#1040678: bookworm-pu: package node-dottie/2.0.2-4+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2023-07-09 at 09:09 +0400, Yadd wrote:
> node-dottie is vulnerable to prototype pollution (#1040592,
> CVE-2023-26132)
> 

Please go ahead.

Regards,

Adam

Bug#1040563: bookworm-pu: package node-tough-cookie/4.0.0-2+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2023-07-08 at 06:23 +0400, Yadd wrote:
> On 7/7/23 21:43, Jonathan Wiltshire wrote:
> > Control: tag -1 moreinfo
> > 
> > On Fri, Jul 07, 2023 at 09:01:40PM +0400, Yadd wrote:
> > > [ Reason ]
> > > node-tough-cookie is vulnerable to prototype pollution
> > 
> > How has this been fixed in unstable? You'll need an upload there
> > anyway for
> > version ordering.
> > 
> > Thanks,
> 
> Hi,
> 
> upload already done in unstable
> 

Please go ahead.

Regards,

Adam

Bug#1040864:

[Andreas Hasenack]

So I took a stab at backporting the upstream patches, and there are many:

$ grep ^commit debian/patches/doc-build-with-newer-cairo-*.patch
debian/patches/doc-build-with-newer-cairo-1.patch:commit
c22ae5ed4ca8d7e5568be7d5a930ee388117703e
debian/patches/doc-build-with-newer-cairo-2.patch:commit
9df76e22464a0b6302b7c1cda980a35b39185bc4
debian/patches/doc-build-with-newer-cairo-3.patch:commit
293d3beaf03c8798899332b7a948b32c4a3da3e9
debian/patches/doc-build-with-newer-cairo-4.patch:commit
966d69c603b5a6ae22e3132b6ecc6a39b86e52ab
debian/patches/doc-build-with-newer-cairo-5.patch:commit
7b2a6027775b0158304635a98de0f9b5672f163a
debian/patches/doc-build-with-newer-cairo-6.patch:commit
8129939c312e4b5060042fdb93bd071b7b133381
debian/patches/doc-build-with-newer-cairo-7.patch:commit
e002e293d9dc956a0634b3a4bcc8d93e655582d5

This looks risky. It's probably best to update to 1.9.7. What do you think?

My WIP branch is at
https://code.launchpad.net/~ahasenack/ubuntu/+source/doxygen/+git/doxygen/+ref/mantic-doxygen-cairo-compat

Bug#1040415: bullseye-pu: package pacemaker/2.1.5-1+deb12u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2023-07-09 at 23:37 +0200, Ferenc Wágner wrote:
> Control: tag -1 - confirmed
> 
> Jonathan Wiltshire  writes:
> 
> > On Wed, Jul 05, 2023 at 07:14:09PM +0200, Ferenc Wágner wrote:
> > 
> > > Shortly after the release of bookworm we got a report that
> > > Pacemaker
> > > regressed in certain migration scenarios when compared to the
> > > bullseye
> > > version.  Upstream identified the cause (a bug already fixed in
> > > 2.1.6),
> > > and after backporting the fix the submitter acknowledged that
> > > they can't
> > > reproduce the bug anymore with the proposed packages.
> > > https://bugs.clusterlabs.org/show_bug.cgi?id=5521
> > > Pacemaker package bug opened after discussion on the mailing
> > > list:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040165
> > 
> > Please go ahead, and bear in mind the upload window closes next
> > weekend.
> 
> Thanks, Jonathan!  Does it mean that I have to upload before 15th of
> July?
> 

If you want to be sure of the update making it into 12.1, yes.

> On the other hand, meanwhile upstream notified me that to fully fix
> this
> bug I need to backport one more patch, which in turn required
> including
> a third one.  So the debdiff grew a little, please reconfirm the
> upload:
> 

Assuming that all of the changes are in unstable (or not required
there), please go ahead.

Regards,

Adam

Bug#1040716: libc6: Stack Traces

[Tim McConnell]

On Tue, 2023-07-11 at 21:11 +0200, Aurelien Jarno wrote:
> Hi,
> 
> On 2023-07-11 11:21, Tim McConnell wrote:
> > 
> > 
> > On Mon, 2023-07-10 at 23:17 +0200, Aurelien Jarno wrote:
> > > You might want
> > > to upgrade to version 2.37-5 to check if it solves your issue
> > Okay that's done and it's still doing it. The entry from Journalctl
> > shows module libudev1 if that's of any use. 
> >  
> > Started systemd-coredump@1785-616863-0.service - Process Core Dump
> > (PID
> > 616863/UID 0).
> > Jul 11 10:52:06 DebianTim systemd-coredump[616865]: Process 616847
> > (collectd) of user 0 dumped core.
> >     
> >     Module
> > libudev.so.1
> > from deb systemd-252.11-1.amd64
> >     Stack trace of
> > thread 616848:
> >     #0 
> > 0x7fce1335e9f2 __memmove_ssse3 (libc.so.6 + 0x16d9f2)
> >     #1 
> > 0x7fce131156d9 rrd_write (librrd.so.8 + 0x346d9)
> >     #2 
> > 0x7fce13120acd n/a (librrd.so.8 + 0x3facd)
> >     #3 
> > 0x7fce13122962 n/a (librrd.so.8 + 0x41962)
> >     #4 
> > 0x7fce1317c370 n/a (rrdtool.so + 0x3370)
> >     #5 
> > 0x7fce132793ec start_thread (libc.so.6 + 0x883ec)
> >     #6 
> > 0x7fce132f9a1c __clone3 (libc.so.6 + 0x108a1c)
> >     
> 
> Thanks for the details. This shows that the binary crashing regularly
> is
> collectd. This is very unlikely that the issue is linked to the
> locales,
> and your test is confirming that.
> 
> It's also not clear that it's a glibc issue, it's more likely an
> issue
> in collectd or librrd8. It appears that systemd-coredump saved a
> coredump when the process crashed. You should be able do use
> "coredumpctl" to get the list of cores. You can select one coredump
> and
> examine it with gdb using "coredumpctl debug ". Then when under
> gdb
> you should be able to run "thread apply all bt" to get the backtrace.
> That should allows to better understand the issue.
> 
> Regards
> Aurelien
> 
I'm unsure how helpful this is ( I am not a programmer) but: 
thread apply all bt

Thread 12 (Thread 0x7fae021f96c0 (LWP 9783)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true,
abstime=0x7fae021f8e60, op=393, expected=0, futex_word=0x556c7b80d488)
at ./nptl/futex-internal.c:57
#1  __futex_abstimed_wait_common
(futex_word=futex_word@entry=0x556c7b80d488, expected=expected@entry=0,
clockid=clockid@entry=0, abstime=abstime@entry=0x7fae021f8e60,
private=private@entry=0, cancel=cancel@entry=true) at ./nptl/futex-
internal.c:87
#2  0x7fae08a3b1bb in __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x556c7b80d488, expected=expected@entry=0,
clockid=clockid@entry=0, abstime=abstime@entry=0x7fae021f8e60,
private=private@entry=0) at ./nptl/futex-internal.c:139
#3  0x7fae08a3dafc in __pthread_cond_wait_common
(abstime=0x7fae021f8e60, clockid=0, mutex=0x556c7b80d4a0,
cond=0x556c7b80d460) at ./nptl/pthread_cond_wait.c:503
#4  ___pthread_cond_timedwait64 (cond=0x556c7b80d460,
mutex=0x556c7b80d4a0, abstime=0x7fae021f8e60) at
./nptl/pthread_cond_wait.c:643
#5  0x556c7b7e83a2 in  ()
#6  0x7fae08a3e3ec in start_thread (arg=) at
./nptl/pthread_create.c:444
#7  0x7fae08abea1c in clone3 () at
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Thread 11 (Thread 0x7fae08c1a740 (LWP 9776)):
#0  0x7fae08a84a25 in __GI___clock_nanosleep
(clock_id=clock_id@entry=0, flags=flags@entry=0, req=0x7fff754277f0,
rem=0x7fff754277f0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:48
#1  0x7fae08a893f3 in __GI___nanosleep (req=,
rem=) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#2  0x556c7b7de16b in  ()
#3  0x556c7b7de7a8 in run_loop ()
#4  0x556c7b7dd934 in main ()

Thread 10 (Thread 0x7fae041fd6c0 (LWP 9779)):
#0  __futex_abstimed_wait_common64 (private=0, cancel=true,
abstime=0x0, op=393, expected=0, futex_word=0x556c7b80d3e8) at
./nptl/futex-internal.c:57
#1  __futex_abstimed_wait_common
(futex_word=futex_word@entry=0x556c7b80d3e8, expected=expected@entry=0,
clockid=clockid@entry=0, abst--Type  for more, q to quit, c to
continue without paging-- 
ime=abstime@entry=0x0, private=private@entry=0,
cancel=cancel@entry=true) at ./nptl/futex-internal.c:87
#2  0x7fae08a3b1bb in __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x556c7b80d3e8, expected=expected@entry=0,
clockid=clockid@entry=0, abstime=abstime@entry=0x0,
private=private@entry=0) at ./nptl/futex-internal.c:139
#3  0x7fae08a3d818 in __pthread_cond_wait_common (abstime=0x0,
clockid=0, 

Bug#1040876: aardvark-dns: phasing out clap version 3.

[Peter Green]

Package: aardvark-dns
Tags: trixie, sid, fixed-upstream

We have ended up with three versions of the clap crate in Debian.
I'd like to reduce that number. Ideally to only one, but reducing
it from three versions to two would be an improvement.

I'm looking at clap v3 first for a few reasons.

* it was only the "latest version" for less than a year.
* Less software in Debian seems to use v3 than v2.
* We are currently patching clap v3 to work with newer
  versions of clap-lex, I'm not sure how sustainable
  this is.

I looked at the upstream repo for aardvark-dons and they seem
to have updated to clap v4 in release 1.7.0, the fix also
doesn't look like it would be horrible to backport

https://github.com/containers/netavark/commit/f0d5cc86ba3460a2c8e73d734f32a5095d60813a

Please consider moving to clap v4.

Bug#1035635: tox: Upgrading to tox 4

[stefanor]

Hi Sebastian (2023.07.11_20:06:16_+)
> Except to speed up removal of some of the reverse dependencies, do you
> need anything from our side? It doesn't look like rebuilds are required.

Nope, beyond that it was just an FYI.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1040874: ocaml-dune: Please add ocaml:Provides to d/control

[Dan Bungert]

Source: ocaml-dune
Version: 3.9.0-2
Severity: normal
X-Debbugs-Cc: daniel.bung...@canonical.com

Dear Maintainer,

utop shows the following in testing migration:
* libutop-ocaml-dev/amd64 has unsatisfiable dependency

Attempting an install of libutop-ocaml-dev reports:
 libutop-ocaml-dev : Depends: libdune-ocaml-dev-v9190 but it is not installable

I believe that adding the ocaml:Provides will resolve this. Debdiff attached.

-Dan
diff -Nru ocaml-dune-3.9.0/debian/changelog ocaml-dune-3.9.0/debian/changelog
--- ocaml-dune-3.9.0/debian/changelog   2023-07-05 02:40:57.0 -0600
+++ ocaml-dune-3.9.0/debian/changelog   2023-07-11 13:41:34.0 -0600
@@ -1,3 +1,10 @@
+ocaml-dune (3.9.0-3) unstable; urgency=medium
+
+  * Rebuild against new OCAML ABIs.
+  * Add dh_ocaml compatible substitution variables per OCaml packaging policy
+
+ -- Dan Bungert   Tue, 11 Jul 2023 13:41:34 -0600
+
 ocaml-dune (3.9.0-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru ocaml-dune-3.9.0/debian/control ocaml-dune-3.9.0/debian/control
--- ocaml-dune-3.9.0/debian/control 2023-07-05 02:40:57.0 -0600
+++ ocaml-dune-3.9.0/debian/control 2023-07-11 13:41:34.0 -0600
@@ -22,7 +22,9 @@
  whitedune (<< 0.30.10-2.2),
  dune (<< 1.6.2-3)
 Replaces: jbuilder (<< 1.0~beta20-1), whitedune (<< 0.30.10-2.2), dune (<< 
1.6.2-3)
-Provides: jbuilder
+Provides:
+ jbuilder,
+ ${ocaml:Provides}
 Depends:
  ${ocaml:Depends},
  ${shlibs:Depends},
@@ -41,6 +43,8 @@
  ${ocaml:Depends},
  ${shlibs:Depends},
  ${misc:Depends}
+Provides:
+ ${ocaml:Provides}
 Suggests:
  ocaml-findlib
 Description: composable build system for OCaml projects (libraries)

Bug#1040872: Fwd: API change in 8.0.0-1 (was: Re: Accepted harfbuzz 8.0.0-1 (source amd64 all) into unstable)

[Rene Engelhard]

Hi,

oops, forgot to replace submit with 1040...@bugs.debian.org. Forwarding.

Regards,

Rene


 Weitergeleitete Nachricht 
Betreff: Re: API change in 8.0.0-1 (was: Re: Accepted harfbuzz 8.0.0-1 
(source amd64 all) into unstable)

Datum: Tue, 11 Jul 2023 22:07:11 +0200
Von: Rene Engelhard 
Organisation: Debian Project
An: sub...@bugs.debian.org
Kopie (CC): 1035...@bugs.debian.org, James Addison 

Hi,

Am 11.07.23 um 21:38 schrieb Rene Engelhard:
[...] Because with that change you cause FTBFS in packages:


https://codesearch.debian.net/search?q=HB_LANGUAGE_INVALID=1

While some of it are internal copies I see pango, freetype, libreoffice 
etc.



libreoffice fails as of now with:


[...]

So a discussion on IRC turned out that this probably "only" is a problem 
for C++, not C. Still it is a problem.


I'll do

diff --git a/vcl/source/font/PhysicalFontFace.cxx 
b/vcl/source/font/PhysicalFontFace.cxx

index aa9a9327f708..a19b393be098 100644
--- a/vcl/source/font/PhysicalFontFace.cxx
+++ b/vcl/source/font/PhysicalFontFace.cxx
@@ -38,6 +38,13 @@

 #include 

+#if HB_VERSION_ATLEAST(8, 0, 0) // Debian-only, see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035669

+#if HB_LANGUAGE_INVALID == 0
+#undef HB_LANGUAGE_INVALID
+#define HB_LANGUAGE_INVALID ((hb_language_t) 0)
+#endif
+#endif
+
 namespace vcl::font
 {
 PhysicalFontFace::PhysicalFontFace(const FontAttributes& rDFA)

in libreoffice for now (which should work in old and new harfbuzz), but...


Please revert.


... I still think that should be done.

Regards,


Rene

Bug#1039911: transition: sdl12-compat taking over libsdl1.2-dev

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2023-06-29 13:26:03 +0100, Simon McVittie wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: debian-devel-ga...@lists.debian.org, 
> libsdl...@packages.debian.org
> 
> As previously mentioned on -devel, I would like src:sdl12-compat to
> take over the libsdl1.2-dev and libsdl1.2debian binary package names
> from src:libsdl1.2 during the trixie cycle. This mirrors a transition
> that already took place in several other distributions such as Fedora
> and Arch.

Thanks for the in-depth analysis. Please go ahead and raise the
remaining regression bugs to serious.

Cheers
-- 
Sebastian Ramacher

Bug#1035635: tox: Upgrading to tox 4

[Sebastian Ramacher]

Control: tags -1 moreinfo

Hi Stefano

On 2023-06-12 16:26:34 -0400, Stefano Rivera wrote:
> Hi Release Team!
> 
> For the tox 4 transition, I have changes in dh-python staged (and in
> experimental) but the autopkgtests require tox 4, so I can't upload them
> until we're ready to pull the trigger on the transition.
> 
> All the fallout I could find is documented in blocking bugs of this bug
> and the dh-python bug (1035675).
> 
> Some of the fixes were staged in experimental, because we were in freeze
> at the time.
> 
> Some of the packages need upstream work, and would have to be removed
> from testing for the transition.
> 
> Please let me know when we should go ahead with this.

Except to speed up removal of some of the reverse dependencies, do you
need anything from our side? It doesn't look like rebuilds are required.

Cheers
-- 
Sebastian Ramacher

Bug#1035669: API change in 8.0.0-1 (was: Re: Accepted harfbuzz 8.0.0-1 (source amd64 all) into unstable)

[Rene Engelhard]

Hi,

Am 11.07.23 um 21:38 schrieb Rene Engelhard:
[...] Because with that change you cause FTBFS in packages:


https://codesearch.debian.net/search?q=HB_LANGUAGE_INVALID=1

While some of it are internal copies I see pango, freetype, libreoffice 
etc.



libreoffice fails as of now with:


[...]

So a discussion on IRC turned out that this probably "only" is a problem 
for C++, not C. Still it is a problem.


I'll do

diff --git a/vcl/source/font/PhysicalFontFace.cxx 
b/vcl/source/font/PhysicalFontFace.cxx

index aa9a9327f708..a19b393be098 100644
--- a/vcl/source/font/PhysicalFontFace.cxx
+++ b/vcl/source/font/PhysicalFontFace.cxx
@@ -38,6 +38,13 @@

 #include 

+#if HB_VERSION_ATLEAST(8, 0, 0) // Debian-only, see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035669

+#if HB_LANGUAGE_INVALID == 0
+#undef HB_LANGUAGE_INVALID
+#define HB_LANGUAGE_INVALID ((hb_language_t) 0)
+#endif
+#endif
+
 namespace vcl::font
 {
 PhysicalFontFace::PhysicalFontFace(const FontAttributes& rDFA)

in libreoffice for now (which should work in old and new harfbuzz), but...


Please revert.


... I still think that should be done.

Regards,


Rene

Bug#1040817: glibc: Please ignore some tests on sparc64

[John Paul Adrian Glaubitz]

Hi!

On Tue, 2023-07-11 at 20:59 +0200, John Paul Adrian Glaubitz wrote:
> With the above fix for the audit tests, the tests to ignore should be:
> 
> FAIL: elf/tst-rtld-run-static
> FAIL: nptl/tst-cancel24-static
> FAIL: socket/tst-socket-timestamp
> FAIL: stdlib/isomac

Just verified this. With both patches above applied, the failures reduce
to the four tests above.

Adrian

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

Bug#1040714: dhcpcd: Missing epoch from souce package version

[Salvatore Bonaccorso]

Hi,

On Tue, Jul 11, 2023 at 10:37:44PM +0300, Martin-Éric Racine wrote:
> On Tue, Jul 11, 2023 at 10:05 PM Salvatore Bonaccorso  
> wrote:
> > On Tue, Jul 11, 2023 at 06:30:38PM +0300, Martin-Éric Racine wrote:
> > > Reintroducing the epoch produces the following Lintian ERROR:
> > >
> > > E: dhcpcd source:
> > > epoch-changed-but-upstream-version-did-not-go-backwards 10.0.1-2 ->
> > > 1:10.0.1-3 [debian/changelog:1]
> >
> > The lintian tag in it's intention is clear. But I believe in this case
> > it reports in error. Because the history of the dhcpcd source package
> > is as follows, cutting of some irrelevant inbetween steps:
> >
> > 0.4-1 -> 1.3.8-0.1 -> 1:0.70-5 (epoch introduced here), then moved
> > upwards -> 1:3.2.3-11 / 1:3.2.3-11+deb7u1 which was the last version
> > available for a while.
> >
> > But then we dropped to 10.0.1-1 (which already missed the epoch).
> >
> > Now the lintian just only checks 10.0.1-2 -> 1:10.0.1-3 and thinks to
> > report that the epoch addition is an error, but it would not if all
> > the 10.0.1-1, 10.0.1-2 versions already had the epoch still.
> >
> > Does this make sense?
> 
> Makes sense to me.
> 
> Uploaded to Mentors. Please note that Mentors forces me to 'debuild
> -sa' because it cannot find the 'orig' on its repository even though
> it's already in unstable.

Thanks! Boyuan (CC'ed), can you take it from there and would you be
willing to sponsor Martin-Éric's work as you did for the previous two
uploads?

Regards,
Salvatore

Bug#1040873: src:shoelaces: fails to migrate to testing for too long: indirectly Build Depends on new package with issues

[Paul Gevers]

Source: shoelaces
Version: 1.2.0+ds-1
Severity: serious
Control: close -1 1.3.2+ds-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:shoelaces has been trying to migrate for 
32 days [2]. Hence, I am filing this bug. Your package has a Built-Using 
version of golang-github-go-kit-kit that is in unstable, but that fails 
to migrate to testing because its new Build-Depends isn't able to 
migrate to testing.


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


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


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


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


Paul

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


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1038668: veryfasttree_4.0.1+dfsg-1_amd64.changes REJECTED

[Andreas Tille]

Hi Thorsten,
uploaded with GPL-3.  Thanks for quick checking
 Andreas.

Am Tue, Jul 11, 2023 at 07:00:10PM + schrieb Thorsten Alteholz:
> 
> Hi Andreas,
> 
> according to [1] the code from Stephane Guindon was added 2019-05-11 whereas 
> according to [2] the license of pyhml was already changed to GPL-3 in 
> 2018-08-29 ...
> Was the code really based on an earlier version?
> 
>   Thorsten
> 
> [1] 
> https://github.com/citiususc/veryfasttree/blame/master/src/NeighbourJoining.tcc
>  
> [2] 
> https://github.com/stephaneguindon/phyml/commit/0893faa043c47bf5bc78c5388900fec5b7e77205
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#1038668: veryfasttree_4.0.1+dfsg-1_amd64.changes REJECTED

[PIÑEIRO POMAR CESAR ALFREDO]

Dear Thorsten,

As the author of the tool, I can provide an answer. I started implementing 
VeryFastTree in April 2019, using FastTree 2.1.10 
(http://www.microbesonline.org/fasttree/FastTree-2.1.10.c) as the base, which 
was the latest version at that time. This version was released on April 11, 
2017 (http://www.microbesonline.org/fasttree/ChangeLog), although the function 
attributed to Stephane Guindon, according to the author, was included in 
version 2.1.0 on October 15, 2009.

Best regards, and thanks to both of you for your work,

César

De: Thorsten Alteholz 
Enviado: martes, 11 de julio de 2023 21:00
Para: Debian Med Packaging Team ; 
PIÑEIRO POMAR CESAR ALFREDO ; ti...@debian.org 

Asunto: veryfasttree_4.0.1+dfsg-1_amd64.changes REJECTED

[No suele recibir correo electrónico de ftpmas...@ftp-master.debian.org. 
Descubra por qué esto es importante en 
https://aka.ms/LearnAboutSenderIdentification ]

Hi Andreas,

according to [1] the code from Stephane Guindon was added 2019-05-11 whereas 
according to [2] the license of pyhml was already changed to GPL-3 in 
2018-08-29 ...
Was the code really based on an earlier version?

  Thorsten

[1] 
https://github.com/citiususc/veryfasttree/blame/master/src/NeighbourJoining.tcc
[2] 
https://github.com/stephaneguindon/phyml/commit/0893faa043c47bf5bc78c5388900fec5b7e77205



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

Bug#1040714: dhcpcd: Missing epoch from souce package version

[Martin-Éric Racine]

On Tue, Jul 11, 2023 at 10:05 PM Salvatore Bonaccorso  wrote:
> On Tue, Jul 11, 2023 at 06:30:38PM +0300, Martin-Éric Racine wrote:
> > Reintroducing the epoch produces the following Lintian ERROR:
> >
> > E: dhcpcd source:
> > epoch-changed-but-upstream-version-did-not-go-backwards 10.0.1-2 ->
> > 1:10.0.1-3 [debian/changelog:1]
>
> The lintian tag in it's intention is clear. But I believe in this case
> it reports in error. Because the history of the dhcpcd source package
> is as follows, cutting of some irrelevant inbetween steps:
>
> 0.4-1 -> 1.3.8-0.1 -> 1:0.70-5 (epoch introduced here), then moved
> upwards -> 1:3.2.3-11 / 1:3.2.3-11+deb7u1 which was the last version
> available for a while.
>
> But then we dropped to 10.0.1-1 (which already missed the epoch).
>
> Now the lintian just only checks 10.0.1-2 -> 1:10.0.1-3 and thinks to
> report that the epoch addition is an error, but it would not if all
> the 10.0.1-1, 10.0.1-2 versions already had the epoch still.
>
> Does this make sense?

Makes sense to me.

Uploaded to Mentors. Please note that Mentors forces me to 'debuild
-sa' because it cannot find the 'orig' on its repository even though
it's already in unstable.

Martin-Éric

Bug#1038668: veryfasttree_4.0.1+dfsg-1_amd64.changes REJECTED

[Thorsten Alteholz]

Hi Andreas,

according to [1] the code from Stephane Guindon was added 2019-05-11 whereas 
according to [2] the license of pyhml was already changed to GPL-3 in 
2018-08-29 ...
Was the code really based on an earlier version?

  Thorsten

[1] 
https://github.com/citiususc/veryfasttree/blame/master/src/NeighbourJoining.tcc 
[2] 
https://github.com/stephaneguindon/phyml/commit/0893faa043c47bf5bc78c5388900fec5b7e77205



===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


___
Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

Bug#1040872: API change in 8.0.0-1 (was: Re: Accepted harfbuzz 8.0.0-1 (source amd64 all) into unstable)

[Rene Engelhard]

Package: libharfbuzz-dev

Version: 8.0.0-1

Severity: serious


Hi,


Am 11.07.23 um 19:00 schrieb Debian FTP Masters:

Format: 1.8
Date: Mon, 10 Jul 2023 04:00:02 +0200
Source: harfbuzz
Binary: gir1.2-harfbuzz-0.0 libharfbuzz-bin libharfbuzz-bin-dbgsym 
libharfbuzz-cairo0 libharfbuzz-cairo0-dbgsym libharfbuzz-dev 
libharfbuzz-doc libharfbuzz-gobject0 libharfbuzz-gobject0-dbgsym 
libharfbuzz-icu0 libharfbuzz-icu0-dbgsym libharfbuzz-subset0 
libharfbuzz-subset0-dbgsym libharfbuzz0-udeb libharfbuzz0b 
libharfbuzz0b-dbgsym

Architecture: source amd64 all
Version: 8.0.0-1
Distribution: unstable
Urgency: medium
Maintainer: أحمد المحمودي (Ahmed El-Mahmoudy) 

Changed-By: أحمد المحمودي (Ahmed El-Mahmoudy) 


Description:
 gir1.2-harfbuzz-0.0 - OpenType text shaping engine (GObject 
introspection data)

 libharfbuzz-bin - OpenType text shaping engine (utility)
 libharfbuzz-cairo0 - OpenType text shaping engine Cairo backend
 libharfbuzz-dev - Development files for OpenType text shaping engine
 libharfbuzz-doc - Documentation files for the HarfBuzz library
 libharfbuzz-gobject0 - OpenType text shaping engine ICU backend 
(GObject library)

 libharfbuzz-icu0 - OpenType text shaping engine ICU backend
 libharfbuzz-subset0 - OpenType text shaping engine (subset library)
 libharfbuzz0-udeb - OpenType text shaping engine (udeb)
 libharfbuzz0b - OpenType text shaping engine (shared library)
Closes: 1030612 1035669 1037687 1039498
Changes:
 harfbuzz (8.0.0-1) unstable; urgency=medium
[...]
   * Add invalid-language-zero.patch to remove typecast from
 HB_LANGUAGE_INVALID definition.
 Thanks to James Addison James Addison 
 (Closes: #1035669)


You can't just do that. This changes public API and if at all should be 
done upstream.


I see it's at https://github.com/harfbuzz/harfbuzz/issues/4263 and this 
should be done there. Because with that change you cause FTBFS in packages:


https://codesearch.debian.net/search?q=HB_LANGUAGE_INVALID=1

While some of it are internal copies I see pango, freetype, libreoffice etc.


libreoffice fails as of now with:

/home/rene/LibreOffice/git/libreoffice-7-6/vcl/source/font/PhysicalFontFace.cxx: 
In member function 'rtl::OUString 
vcl::font::PhysicalFontFace::GetName(vcl::font::NameID, const 
LanguageTag&) const':
/home/rene/LibreOffice/git/libreoffice-7-6/vcl/source/font/PhysicalFontFace.cxx:477:42: 
error: invalid conversion from 'hb_language_t' {aka 'const 
hb_language_impl_t*'} to 'int' [-fpermissive]
  477 | aHbLang = hb_language_from_string(aLanguage.getStr(), 
aLanguage.getLength());

  | ~~~^~~
  |  |
  |  hb_language_t {aka 
const hb_language_impl_t*}
/home/rene/LibreOffice/git/libreoffice-7-6/vcl/source/font/PhysicalFontFace.cxx:480:57: 
error: invalid conversion from 'int' to 'hb_language_t' {aka 'const 
hb_language_impl_t*'} [-fpermissive]
  480 | auto nName = hb_ot_name_get_utf16(pHbFace, aNameID, 
aHbLang, nullptr, nullptr);

  | ^~~
  | |
  | int
In file included from /usr/include/harfbuzz/hb-ot-color.h:37,
 from /usr/include/harfbuzz/hb-ot.h:33,
 from 
/home/rene/LibreOffice/git/libreoffice-7-6/vcl/inc/font/PhysicalFontFace.hxx:37,
 from 
/home/rene/LibreOffice/git/libreoffice-7-6/vcl/inc/sft.hxx:53,
 from 
/home/rene/LibreOffice/git/libreoffice-7-6/vcl/source/font/PhysicalFontFace.cxx:30:
/usr/include/harfbuzz/hb-ot-name.h:150:40: note:   initializing argument 
3 of 'unsigned int hb_ot_name_get_utf16(hb_face_t*, hb_ot_name_id_t, 
hb_language_t, unsigned int*, uint16_t*)'

  150 |   hb_language_t    language,
  |   ~^~~~
/home/rene/LibreOffice/git/libreoffice-7-6/vcl/source/font/PhysicalFontFace.cxx:484:42: 
error: invalid conversion from 'hb_language_t' {aka 'const 
hb_language_impl_t*'} to 'int' [-fpermissive]

  484 | aHbLang = hb_language_from_string("en", 2);
  |   ~~~^
  |  |
  |  hb_language_t {aka 
const hb_language_impl_t*}
/home/rene/LibreOffice/git/libreoffice-7-6/vcl/source/font/PhysicalFontFace.cxx:485:56: 
error: invalid conversion from 'int' to 'hb_language_t' {aka 'const 
hb_language_impl_t*'} [-fpermissive]
  485 | nName = hb_ot_name_get_utf16(pHbFace, aNameID, aHbLang, 
nullptr, nullptr);

  | ^~~
  |    |
  |    int
/usr/include/harfbuzz/hb-ot-name.h:150:40: note:   initializing argument 
3 of 'unsigned int hb_ot_name_get_utf16(hb_face_t*, hb_ot_name_id_t, 
hb_language_t, unsigned int*, uint16_t*)'

  150 | 

Bug#1040871: reportbug fails to start

[Laurent Martelli]

Package: reportbug
Version: 12.0.0
Severity: grave

Reportbug fails to start. It seems to relate to the removal of a deprecated
function in python 3.11.

Traceback (most recent call last):
  File "/usr/bin/reportbug", line 40, in 
from reportbug import utils
  File "/usr/lib/python3/dist-packages/reportbug/utils.py", line 70, in

from . import debbugs   # noqa: E402
^
  File "/usr/lib/python3/dist-packages/reportbug/debbugs.py", line 33, in

import debianbts
  File "/usr/lib/python3/dist-packages/debianbts/__init__.py", line 1, in

from debianbts.debianbts import *  # noqa
^
  File "/usr/lib/python3/dist-packages/debianbts/debianbts.py", line 22, in

from pysimplesoap.client import SoapClient
  File "/usr/lib/python3/dist-packages/pysimplesoap/__init__.py", line 16,
in 
from . import client, server, simplexml, transport
  File "/usr/lib/python3/dist-packages/pysimplesoap/client.py", line 33, in

from .transport import get_http_wrapper, set_http_wrapper, get_Http
  File "/usr/lib/python3/dist-packages/pysimplesoap/transport.py", line
109, in 
if 'timeout' in inspect.getargspec(httplib2.Http.__init__)[0]:
^^
AttributeError: module 'inspect' has no attribute 'getargspec'. Did you
mean: 'getargs'?

Bug#1023477: (no subject)

[Jelmer Vernooij]

retitle 1023477 RFP: libtypec -- user-space library for accessing USB-C/USB-PD 
metadata
thanks

I replied to your email to me about this ITP a couple of days ago, but
perhaps that got lost in a spam filter somewhere:

> Hi Colin,
>
> I originally started on this but didn't get very far. IIRC there were
> some issues building on Debian, and then I got distracted by other
> things before I could resolve those.
>
> If you're interested in taking over the ITP, please feel free to
> do so.
>
> Cheers,
>
> Jelmer

Bug#1040716: libc6: Stack Traces

[Aurelien Jarno]

Hi,

On 2023-07-11 11:21, Tim McConnell wrote:
> 
> 
> On Mon, 2023-07-10 at 23:17 +0200, Aurelien Jarno wrote:
> > You might want
> > to upgrade to version 2.37-5 to check if it solves your issue
> Okay that's done and it's still doing it. The entry from Journalctl
> shows module libudev1 if that's of any use. 
>  
> Started systemd-coredump@1785-616863-0.service - Process Core Dump (PID
> 616863/UID 0).
> Jul 11 10:52:06 DebianTim systemd-coredump[616865]: Process 616847
> (collectd) of user 0 dumped core.
> 
> Module libudev.so.1
> from deb systemd-252.11-1.amd64
> Stack trace of
> thread 616848:
> #0 
> 0x7fce1335e9f2 __memmove_ssse3 (libc.so.6 + 0x16d9f2)
> #1 
> 0x7fce131156d9 rrd_write (librrd.so.8 + 0x346d9)
> #2 
> 0x7fce13120acd n/a (librrd.so.8 + 0x3facd)
> #3 
> 0x7fce13122962 n/a (librrd.so.8 + 0x41962)
> #4 
> 0x7fce1317c370 n/a (rrdtool.so + 0x3370)
> #5 
> 0x7fce132793ec start_thread (libc.so.6 + 0x883ec)
> #6 
> 0x7fce132f9a1c __clone3 (libc.so.6 + 0x108a1c)
> 

Thanks for the details. This shows that the binary crashing regularly is
collectd. This is very unlikely that the issue is linked to the locales,
and your test is confirming that.

It's also not clear that it's a glibc issue, it's more likely an issue
in collectd or librrd8. It appears that systemd-coredump saved a
coredump when the process crashed. You should be able do use
"coredumpctl" to get the list of cores. You can select one coredump and
examine it with gdb using "coredumpctl debug ". Then when under gdb
you should be able to run "thread apply all bt" to get the backtrace.
That should allows to better understand the issue.

Regards
Aurelien

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

Bug#1040867: bug#1040867 could be with cloud-init rather than ifupdown

[Nate Childers]

After reviewing the contents of /etc/network/interfaces.d/50-cloud-init 
containing the call to the missing route command it occurred to me that this 
may be an issue with cloud-init instead.

Bug#1030952: npm depends on webpack and 200+ other packages

[PurkkaKoodari]

I'm unfamiliar with the Debian JS packaging process, but based on a 
quick search on npm, it would seem to me that this could be quite simple 
to resolve: Turn node-postcss-selector-parser into a concrete package, 
which would then contain only node-postcss-selector-parser, and depend 
on node-util-deprecate and node-cssesc (the latter being a virtual 
package provided by node-css-selector-tokenizer).


I'm sure I'm not the only one with node-css-loader pinned at 5.0.1 to 
avoid installing webpack just for npm, so would enjoy seeing this fixed.

Bug#1040714: dhcpcd: Missing epoch from souce package version

[Salvatore Bonaccorso]

Hi martin-Eric,

On Tue, Jul 11, 2023 at 06:30:38PM +0300, Martin-Éric Racine wrote:
> On Mon, Jul 10, 2023 at 7:30 PM Martin-Éric Racine
>  wrote:
> >
> > On Mon, Jul 10, 2023 at 7:05 PM Salvatore Bonaccorso  
> > wrote:
> > > On Sun, Jul 09, 2023 at 10:39:59PM +0300, Martin-Éric Racine wrote:
> > > > On Sun, Jul 9, 2023 at 10:33 PM Salvatore Bonaccorso 
> > > >  wrote:
> > > > > On Sun, Jul 09, 2023 at 09:25:33PM +0200, Salvatore Bonaccorso wrote:
> > > > > > Source: dhcpcd
> > > > > > Version: 10.0.1-1
> > > > > > Severity: serious
> > > > > > Justification: Debian version goes backwards from previous released 
> > > > > > versions
> > > > > > X-Debbugs-Cc: car...@debian.org
> > > > > >
> > > > > > Hi
> > > > > >
> > > > > > The new src:dhcpcd has a lower version of any previous released
> > > > > > src:dhcpd version, which had an epoch:
> > > > >
> > > > > Apologies for the typo, should be src:dhcpcd in both cases obviously
> > > > > :(
> > > >
> > > > Which is a slightly different issue than what Andtreas reported at
> > > > #1037190.  Sorry.
> > >
> > > No problem, just reopenng while we discuss it.
> >
> > Agreed.
> >
> > > > Unless I'm mistaken, we're basically looking at 2 separate issues:
> > > >
> > > > 1) bin:dhcpcd from Wheezy has a higher epoch that the one in Bookworm.
> > > > This is easily fixed as explained in #1037190 for Bookworm.
> > > >
> > > > 2) Since transiting the source from src:dhcpcd5 to src:dhcpcd we're
> > > > missing an epoch for everything. This requires reverting the above fix
> > > > and simply introducing an epoch for the whole src and binaries.
> > >
> > > Yes correct, this is maninly as well what I was referring to. But that
> > > would solve as well at same time the former issue right, if we drop
> > > all special casing for epoch on the binary packages, is this correct?
> >
> > In Trixie, for the version, it would. Just insert the epoch for the
> > whole source (which would apply to the binaries generated too) and
> > we're done.
> >
> > However, we still need that preinst script to clean up possible Wheezy
> > leftovers.
> >
> > In Bookworm, we'll still need the version mingle just for one binary
> > target. debdiff for stable-proposed-updates are on #1037190 and the
> > upload is ready on Mentors.
> >
> > > So if we add the epoch to the whole src;dhcpcd version, and to the
> > > produced binaries I think all the issues should be resolved.
> > >
> > > My background is here:
> > > https://security-tracker.debian.org/tracker/source-package/dhcpcd
> > > e.g. https://security-tracker.debian.org/tracker/CVE-2002-1403 will be
> > > considered not yet fixed, because for dpkg:
> > >
> > > $ dpkg --compare-versions 1:1.3.22pl2-2 lt 10.0.1-1
> > > $ echo $?
> > > 1
> >
> > I was actually wondering how to close those old CVE against the old fork.
> >
> > > > Or have I misunderstood the issue?
> > >
> > > No, I think we are on the same page in my understnding!
> >
> > Excellent.
> 
> Reintroducing the epoch produces the following Lintian ERROR:
> 
> E: dhcpcd source:
> epoch-changed-but-upstream-version-did-not-go-backwards 10.0.1-2 ->
> 1:10.0.1-3 [debian/changelog:1]

The lintian tag in it's intention is clear. But I believe in this case
it reports in error. Because the history of the dhcpcd source package
is as follows, cutting of some irrelevant inbetween steps:

0.4-1 -> 1.3.8-0.1 -> 1:0.70-5 (epoch introduced here), then moved
upwards -> 1:3.2.3-11 / 1:3.2.3-11+deb7u1 which was the last version
available for a while.

But then we dropped to 10.0.1-1 (which already missed the epoch).

Now the lintian just only checks 10.0.1-2 -> 1:10.0.1-3 and thinks to
report that the epoch addition is an error, but it would not if all
the 10.0.1-1, 10.0.1-2 versions already had the epoch still.

Does this make sense?

Regards,
Salvatore

Bug#1040870: Document how to use IGNORE_SMTP_LINE_LENGTH_LIMIT

[Dan Jacobson]

Package: exim4-config
Version: 4.96-16

Users need to set
IGNORE_SMTP_LINE_LENGTH_LIMIT=true
else they cannot forward messages except ones with short lines.

Alas,

# update-exim4.conf --verbose
using non-split configuration scheme from /etc/exim4/exim4.conf.template
undocumented line IGNORE_SMTP_LINE_LENGTH_LIMIT=true found in
/etc/exim4/update-exim4.conf.conf, generating exim macro

Bug#1040869: [INTL:ro] Translation-revision of "dselect" to Romanian

[Remus-Gabriel Chelu]

Package: dselect
Version: 1.21.22
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the «dselect_1.21.22_ro.po» 
file.
-- 
Thanks,
Remus-Gabriel

dselect_1.21.22_ro.po
Description: Binary data

Bug#1040817: glibc: Please ignore some tests on sparc64

[John Paul Adrian Glaubitz]

On Tue, 2023-07-11 at 20:57 +0200, Aurelien Jarno wrote:
> > Correction: These two tests should be ignored as well:
> > 
> > FAIL: elf/tst-rtld-run-static
> > FAIL: nptl/tst-cancel24-static
> 
> Noted.
> 
> > So, it's only this failure that just got fixed today upstream [1]:
> > 
> > FAIL: nptl/tst-cancel30
> 
> Ok, I see it's also fixed on the 2.37 branch, I'll pull it from there.

And there is now a fix for the audit issues:

> https://patchwork.sourceware.org/project/glibc/patch/20230711151558.314216-1-adhemerval.zane...@linaro.org/

And re-enable the 32-bit tests then.

Adrian

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

Bug#1040817: glibc: Please ignore some tests on sparc64

[John Paul Adrian Glaubitz]

Hi!

On Tue, 2023-07-11 at 20:52 +0200, Aurelien Jarno wrote:
> > According to upstream, the following audit tests are not going to be
> > fixed soon since the SPARC ABI makes it more difficult:
> > 
> > FAIL: elf/tst-audit24a
> > FAIL: elf/tst-audit24b
> > FAIL: elf/tst-audit24c
> > FAIL: elf/tst-audit24d
> 
> Ok.

It happens that Adhemerval just posted a patch for the audit issue a few hours 
ago:

> https://patchwork.sourceware.org/project/glibc/patch/20230711151558.314216-1-adhemerval.zane...@linaro.org/

So, we might not have the blacklist these as well.

> > These are going to be fixed upstream soon, the fixes are supposedly
> > trivial:
> > 
> > FAIL: elf/tst-rtld-run-static
> > FAIL: nptl/tst-cancel24-static
> > FAIL: nptl/tst-cancel30
> 
> Great.
> 
> > This test is supposedly a kernel issue:
> > 
> > FAIL: socket/tst-socket-timestamp
> > 
> > And this one allegedly not related to sparc64:
> > 
> > FAIL: stdlib/isomac
> 
> What do you mean by "allegedly not related to sparc64"? This failure
> only appears on sparc*. The sparc32 has the following comment in
> debian/testsuite-xfail-debian.mk to ignore the failure:
> 
>   # Even if configured using --with-long-double-128, the biarch32 compiler
>   # on sparc64 defaults to 64-bit doubles, causing the failure below. This
>   # should be fixed by the following gcc patch:
>   # http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00318.html
>   test-xfail-stdlib/isomac = yes
> 
> Can you please check if there is a similar issue with the GCC
> configuration on sparc64?

That was the comment by Adhemerval when he looked at the issue.

> > So, my suggestion would be to ignore the following tests for now:
> > 
> > FAIL: elf/tst-audit24a
> > FAIL: elf/tst-audit24b
> > FAIL: elf/tst-audit24c
> > FAIL: elf/tst-audit24d
> > FAIL: socket/tst-socket-timestamp
> > FAIL: stdlib/isomac
> 
> Ok.
> 
> > And looking at the testsuite results with 32-bit tests enabled [1], it 
> > looks like
> > the failures are the same. So, I think we can just ignore the above tests 
> > and then
> > re-enable testing on 32 bit as well.
> 
> It appears that none of those fails on sparc32. Looking at it again, it
> even appears that the sparc32 build passed the testsuite without issue,
> so there was no need to disable it.

Hmm, then I actually mixed up the two testsuites, sorry. You can re-enable it 
then.

With the above fix for the audit tests, the tests to ignore should be:

FAIL: elf/tst-rtld-run-static
FAIL: nptl/tst-cancel24-static
FAIL: socket/tst-socket-timestamp
FAIL: stdlib/isomac

Adrian

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

Bug#1040817: glibc: Please ignore some tests on sparc64

[Aurelien Jarno]

Hi,

On 2023-07-11 14:33, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> On Tue, 2023-07-11 at 06:17 +0200, John Paul Adrian Glaubitz wrote:
> > These are going to be fixed upstream soon, the fixes are supposedly
> > trivial:
> > 
> > FAIL: elf/tst-rtld-run-static
> > FAIL: nptl/tst-cancel24-static
> > FAIL: nptl/tst-cancel30
> > 
> > This test is supposedly a kernel issue:
> > 
> > FAIL: socket/tst-socket-timestamp
> > 
> > And this one allegedly not related to sparc64:
> > 
> > FAIL: stdlib/isomac
> > 
> > So, my suggestion would be to ignore the following tests for now:
> > 
> > FAIL: elf/tst-audit24a
> > FAIL: elf/tst-audit24b
> > FAIL: elf/tst-audit24c
> > FAIL: elf/tst-audit24d
> > FAIL: socket/tst-socket-timestamp
> > FAIL: stdlib/isomac
> 
> Correction: These two tests should be ignored as well:
> 
> FAIL: elf/tst-rtld-run-static
> FAIL: nptl/tst-cancel24-static

Noted.

> So, it's only this failure that just got fixed today upstream [1]:
> 
> FAIL: nptl/tst-cancel30

Ok, I see it's also fixed on the 2.37 branch, I'll pull it from there.

Cheers
Aurelien

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

Bug#1040817: glibc: Please ignore some tests on sparc64

[Aurelien Jarno]

Hi,

On 2023-07-11 06:17, John Paul Adrian Glaubitz wrote:
> Source: glibc
> Version: 2.37-5
> Severity: normal
> User: debian-sp...@lists.debian.org
> Usertags: sparc64
> X-Debbugs-Cc: debian-sp...@lists.debian.org
> 
> Hi!
> 
> The list of currently failing tests on sparc64 is:
> 
> FAIL: elf/tst-audit24a
> FAIL: elf/tst-audit24b
> FAIL: elf/tst-audit24c
> FAIL: elf/tst-audit24d
> FAIL: elf/tst-rtld-run-static
> FAIL: nptl/tst-cancel24-static
> FAIL: nptl/tst-cancel30
> FAIL: socket/tst-socket-timestamp
> FAIL: stdlib/isomac
> 
> According to upstream, the following audit tests are not going to be
> fixed soon since the SPARC ABI makes it more difficult:
> 
> FAIL: elf/tst-audit24a
> FAIL: elf/tst-audit24b
> FAIL: elf/tst-audit24c
> FAIL: elf/tst-audit24d

Ok.

> These are going to be fixed upstream soon, the fixes are supposedly
> trivial:
> 
> FAIL: elf/tst-rtld-run-static
> FAIL: nptl/tst-cancel24-static
> FAIL: nptl/tst-cancel30

Great.

> This test is supposedly a kernel issue:
> 
> FAIL: socket/tst-socket-timestamp
> 
> And this one allegedly not related to sparc64:
> 
> FAIL: stdlib/isomac

What do you mean by "allegedly not related to sparc64"? This failure
only appears on sparc*. The sparc32 has the following comment in
debian/testsuite-xfail-debian.mk to ignore the failure:

  # Even if configured using --with-long-double-128, the biarch32 compiler
  # on sparc64 defaults to 64-bit doubles, causing the failure below. This
  # should be fixed by the following gcc patch:
  # http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00318.html
  test-xfail-stdlib/isomac = yes

Can you please check if there is a similar issue with the GCC
configuration on sparc64?

> So, my suggestion would be to ignore the following tests for now:
> 
> FAIL: elf/tst-audit24a
> FAIL: elf/tst-audit24b
> FAIL: elf/tst-audit24c
> FAIL: elf/tst-audit24d
> FAIL: socket/tst-socket-timestamp
> FAIL: stdlib/isomac

Ok.

> And looking at the testsuite results with 32-bit tests enabled [1], it looks 
> like
> the failures are the same. So, I think we can just ignore the above tests and 
> then
> re-enable testing on 32 bit as well.

It appears that none of those fails on sparc32. Looking at it again, it
even appears that the sparc32 build passed the testsuite without issue,
so there was no need to disable it.

Cheers
Aurelien

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

Bug#1040868: bookworm-pu: package glibc/2.36-9+deb12u1

[Aurelien Jarno]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: gl...@packages.debian.org, debian-b...@lists.debian.org
Control: affects -1 + src:glibc

[ Reason ]
The upstream stable branch got a few fixes during the bookworm freeze
period, and this update pulls them into the debian package. In short:
 - Fix a buffer overflow and memory corruption in the gmon
   functionality.
 - Fix a deadlock in getaddrinfo() and system() functions
 - Fix y2038 support in strftime on 32-bit architectures.
 - Fix possible segmentation fault in applications using sgetsgent()
   when /etc/gshadow contains very long lines
 - Fix support for old C90 compilers.

In addition this include a Slovak translation update fixing typos, that
also arrived during the bookworm freeze.

[ Impact ]
In case the update isn't approved, systems will be left with the above
issues which are not critical but can affect some applications.

[ Tests ]
The upstream fixes come with additional tests, which represent a
significant part of the diff.

[ Risks ]
The changes to do not affect critical part of the library, and come with
additional tests. The upstream changes have been in some distribution
for a few months and in experimental for more than a month, and the
translation changes in experimental for more than 3 weeks. All of them
are in sid for more than ten days.

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

[ Changes ]
Please find below the changelog with additional explanations:

* debian/patches/git-updates.diff: update from upstream stable branch:
  - Affecting bookworm release architectures:
- Improve mcount overflow handling in gmon.
- Fix a buffer overflow in gmon (CVE-2023-0687).
- Fix a memory corruption when incorrectly calling gmon functions
  repeatedly on in wrong order.

=> Those are three security issues affecting the gmon feature of
glibc, one of them has a CVE entry, but it is disputed. The binaries
we ship in packages are not gmon enabled, but users might do that
and use them in production, so it's better to fix them.  More
details can be found on the upstream BTS:
https://sourceware.org/bugzilla/show_bug.cgi?id=27576
https://sourceware.org/bugzilla/show_bug.cgi?id=29444
https://sourceware.org/bugzilla/show_bug.cgi?id=30101

- Fix a deadlock in getaddrinfo (__check_pf) with deferred cancellation.

=> This fixes a deadlock that can happen in some rare cases
involving thread cancellation. It is known to affect zookeeper,
however it is not clear if it can be reproduced with the Debian
package. More details can be found on the upstream BTS:
https://sourceware.org/bugzilla/show_bug.cgi?id=20975

- Fix y2038 support in strftime on 32-bit architectures.

=> This fixes the %s format specification of strftime to return the
correct string after y2038 instead of failing and returning -1 on
32-bit architectures when compiling with -D_TIME_BITS=64. There are
very few packages building that way yet, but coreutils is one of
them and is likely affected. More details can be found on the
upstream BTS:
https://sourceware.org/bugzilla/show_bug.cgi?id=30053

- Fix corner case parsing of /etc/gshadow which can return bad pointers
  causing segfaults in applications.

=> This fixes the parsing of /etc/gshadow when it contains very long
lines, and causes sgetsgent() to not return any data while still
indicating success. This can cause a segmentation fault in
applications using this function. More details can be found on the
upstream BTS: https://sourceware.org/bugzilla/show_bug.cgi?id=30151

- Fix a deadlock in system() when called concurrently from multiple
  threads.

=> This fix an issue when system() is called from multiple threads.
While the upstream BTS contains a reproducer, it is not clear if it
is affect more than custom code or if Debian packages are affected.
More details can be found on the upstream BTS:
https://sourceware.org/bugzilla/show_bug.cgi?id=30163

- cdefs: limit definition of fortification macros to __FORTIFY_LEVEL > 0
  to support old C90 compilers.

=> This fixes the glibc headers to correctly support for old C90
compilers that user might use on their system. It's not clear if we
ship such a compiler as a Debian package though.

  - Not affecting bookworm release architectures:
- Fix LFS POSIX lock constants for powerpc64.
- Fix GL(dl_phdr) and GL(dl_phnum) for static builds.  Closes: #1028200.
  - Not affecting debian architectures:
- Fix LFS POSIX lock constants on 32 bit arch with 64 bit default
  time_t.

  => The above fixes are fixing upstream which do not concern bookworm
  release 

Bug#1040867: ifupdown: ifup exits with /bin/sh: 1: route: not found

[Nate Childers]

Package: ifupdown
Version: 0.8.41
Severity: important

Dear Maintainer,

   * What led up to the situation?

Bringing up a new debian 12 system with a static network-configuration 
supplied by cloud-init

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

Logged in via console and added a static route manually. 

   * What was the outcome of this action?

System worked as expected for that session but would not have a route 
on subseqent boots.

   * What outcome did you expect instead?

System would work without further modification

   * Additional statments:

This seems like an undeclared, or perhaps modified dependency. I was 
able to determine that the route command is provided by the net-tools package. 
Once that was installed then ifupdown worked as expected. Its possible that 
this command used to be provided by the current dependencies and something 
there changed? Please let me know if you need any additional details. Here's 
the output of `systemctl status networking.service` that lead me to this 
conclusion.

-- Boot 1be256fba6244cb19d698f10d0d4acca --
Jul 11 12:01:54 nbc9-d12-dev-01 systemd[1]: Starting networking.service - Raise 
network interfaces...
Jul 11 12:01:54 nbc9-d12-dev-01 ifup[780]: /bin/sh: 1: route: not found
Jul 11 12:01:54 nbc9-d12-dev-01 systemd[1]: Finished networking.service - Raise 
network interfaces.



-- Package-specific info:
--- /etc/network/interfaces:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens192
iface ens192 inet dhcp

--- /etc/network/interfaces.d/*:
# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 10.236.81.22/24
dns-nameservers 152.3.72.100 152.3.70.100
dns-search oit.duke.edu
post-up route add default gw 10.236.81.1 || true
pre-down route del default gw 10.236.81.1 || true

--- up and down scripts installed:
/etc/network/if-down.d:
total 4
-rwxr-xr-x 1 root root 759 Dec  9  2022 resolved

/etc/network/if-post-down.d:
total 0

/etc/network/if-pre-up.d:
total 4
-rwxr-xr-x 1 root root 344 Dec 20  2022 ethtool

/etc/network/if-up.d:
total 16
-rwxr-xr-x 1 root root 1685 Dec 20  2022 ethtool
-rwxr-xr-x 1 root root 1048 Jan 16 18:31 ntpsec-ntpdate
-rwxr-xr-x 1 root root 4663 Dec  9  2022 resolved


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

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

Versions of packages ifupdown depends on:
ii  adduser   3.134
ii  iproute2  6.1.0-3
ii  libc6 2.36-9

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.3-P1-2

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

-- no debconf information

Bug#873959: stax: Unresponsive and buggy controls

[Trent Gamblin]

Hello I made Stax, and Stax 2 but I didn't see this before.

I'll take a look at it sometime. The double inputs are probably because it 
doesn't use events, it would need a whole new input system to fix it. What it 
does it check if the button is currently pressed, so based on the flow of the 
game (based on timing) it could tick of twice quickly...

As for the pause menu taking a lot of cpu time, I'm not sure, these old games 
were made for DOS where a busy loop was normal so it needs a better 
implementation as well probably.

I wouldn't expect a fix next week but I do fix bugs in all my games eventually 
if I have time, but I'm slower than I used to be.

Bug#1040866: ITP: golang-github-linode-linodego -- Go client for Linode REST v4 API

[Daniel Swarbrick]

Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-linode-linodego
  Version : 1.18.0-1
  Upstream Contact: Linode
* URL : https://github.com/linode/linodego
* License : Expat
  Programming Lang: Go
  Description : Go client for Linode REST v4 API

Go client for Linode REST v4 API (https://developers.linode.com/api/v4).

This is a dependency of Linode service discovery in Prometheus, which is
currently patched out. I will co-maintain this as a member of the Debian
Go Packaging Team.

Bug#982648: RFP: filius -- Filius is a tool for enhancing computer science lessons on networks.

[Andreas B. Mundt]

Package: wnpp
Followup-For: Bug #982648
X-Debbugs-Cc: a...@debian.org, debian-j...@lists.debian.org

Control: retitle -1 ITP: filius -- educational network simulator
Control: block -1 by 1040528

Hi,

I started to package filius for Debian, a draft package is already
available[1].  First, some maven data needs to be added to the
libhtmlparser-java package [2] and libsemantic-version-java [3] needs
to be included in Debian too.  I'll do some more polishing and then
coordinate the uploads with the Debian Java team. Any tests are of
course welcome.

Best regards,

  Andi


[1] https://salsa.debian.org/andi/filius
[2] https://salsa.debian.org/java-team/libhtmlparser-java/-/merge_requests/1
[3] https://salsa.debian.org/andi/libsemantic-version-java

Bug#1040001: Role of tibble? (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)

[Paul Gevers]

Hi Dirk,

On 11-07-2023 02:43, Dirk Eddelbuettel wrote:

I still have hopes that we can let technical excellence rule and not require
blunt instruments such as forced recompilation.


I'm totally on board for technical excellence, although I think we have 
different things in mind when we say that.


In Debian, with more QA than we ever had before, we're finding a class 
of issues that often went unnoticed years ago. One of these things is 
that partial upgrades can leave you in a bad state. So more and more we 
see that packages "have to" add Breaks to tell apt that when you want to 
upgrade package X, you also have to upgrade package Y if you happen to 
have that installed. As package Y can not tell that, package X has to 
add the Breaks on the broken version of Y. As an example, see the list 
of Breaks in libc6 [1]. While partial upgrades aren't officially 
supported, we rely on them nevertheless (even if only for QA (piuparts, 
autopkgtest)), and as a Release Team member I consider that class of 
fixes technical excellence: ensuring as best as we can that the user 
that upgrades a package keeps a working system.


While a rebuild of everything combined with bumping the "api" would 
achieve that, I'm much more in favor of targeted Breaks, like we have 
been discussing here. It's typically more work, but it's more correct.


For the future, with the recent change in dh-r, r-base will be much less 
impacted by this "problem" as the new uploads of reverse dependencies 
can migrate *before* r-base, and hence this class of issues will 
disappear once that happens (autopkgtest failures are retried after a 
day). So unless somebody investigates the issues in time, the retry will 
pass after the migration and the issue will no longer block r-base. I 
can live with that, but I find it a shame nevertheless.


So, what do you say: technical excellence and you add the Breaks? Or we 
let this slip in? I prefer the former, I can live with the latter.


Paul

[1] https://tracker.debian.org/media/packages/g/glibc/control-2.37-5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1040840: tp-smapi-dkms: Thinkpad fails to wake from sleep correctly with tp-smapi-dkms after bookworm upgrade

[Evgeni Golov]

Hi,

On Tue, Jul 11, 2023 at 02:24:38PM +0200, Caren Hern wrote:
> After upgrading to from bulleye to bookworm (Kernel version 6.1.0-9) I 
> experienced frequent freezes after wake.
> The power LED would light up, and I was able to toggle the keyboard 
> backlight, but no other buttons responded (such as Fn-Lock light)
> and the screen was black. One single time the screen showed the login window, 
> but still everything was unresponsive.

I've not seen that on my X201s, but I don't suspend too much.

Are you using Suspend (to RAM) or Hibernate (to Disk)?
> 
> After trying various changes I removed all install DKMS modules one by one, 
> until I found that just with tp-smapi-dkms uninstalled there has been no 
> freezes in the last week (before the machine would freeze approx. 60% of 
> times after wake, multiple times a day).
> 
> Thinkpad T470

tp-smapi shouldn't work on that model at all and refuse to load.
(but I have no matching machine to verify that behaviour)

Confused
Evgeni

Bug#1040783: libvirt-daemon: libvirt firewalld zone is missing

[Niccolò Belli]

I've found the root of the problem: I was connecting to libvirt via ssh 
using an unprivileged user part of the libvirt group. That works for 
most of the tasks but not for creating the firewalld libvirt zone. Using 
root, while being less than ideal, works fine.

Bug#1039720: Acknowledgement (gnome-online-accounts: google account stop working files and calendar. Not able to re create online account.)

[Sergio Zamora]

Hi,

Ok.


same behaviour: /The button tried to do something, but the window 
finally frozen./






- This worked fine during all the ' testing ' cycle, and stopped working 
one or two weeks before Bookworm became stable.


- No custom settings

- I use the nvidia-driver from apt.


Thank you for your time

Regards.




On 11-07-23 12:36, Alberto Garcia wrote:

WEBKIT_DISABLE_COMPOSITING_MODE=1 gnome-control-center

Bug#1024216: mkchromecast: please change dependency from youtube-dl to yt-dlp

[Adrian Bunk]

Control: tags -1 bookworm

On Tue, Jul 11, 2023 at 12:56:27PM -0400, Andres Salomon wrote:
> Control: tags -1 - bookworm
> 
> On Tue, Jul 11 2023 at 12:45:13 PM +03:00:00, Adrian Bunk 
> wrote:
> > Control: tags -1 bookworm trixie sid
> > 
> > On Wed, Jan 04, 2023 at 01:42:22AM -0500, Andres Salomon wrote:
> > >  On Wed, 16 Nov 2022 00:58:30 -0500 Andres Salomon
> > > mailto:dilin...@queued.net>>
> > >  wrote:
> > >  > Package: src:mkchromecast
> > >  > Version: 0.3.9~git20200902+db2964a-2
> > >  > Severity: normal
> > >  >
> > >  > We are planning to remove the youtube-dl package in the next
> > > Debian
> > >  > release, as upstream development had issues and has stagnated (see
> > >  > <> ). The upstream package was
> > > forked, and
> > >  > active development now happens in yt-dlp (which is an almost*
> > > drop-in
> > >  > replacement for youtube-dl). Since your package depends on it,
> > > please
> > >  > test your package with yt-dlp and update the dependency to replace
> > >  > "youtube-dl" with "yt-dlp" once you've verified that it works
> > > correctly
> > >  > with your package.
> > >  >
> > >  > This bug is filed as normal for now, but will likely become
> > >  > release-critical once the new youtube-dl dummy package is
> > > uploaded to
> > >  > unstable.
> > >  >
> > > 
> > >  The new youtube-dl dummy package has now been uploaded to unstable.
> > > However,
> > >  I'm not raising the severity on this bug because youtube-dl is only
> > > used if
> > >  mkchromecast is called with '-y '. So that will now be broken
> > > until you
> > >  switch to yt-dlp, but mkchromecast appears usable without that
> > >  functionality.
> > > 
> > >  It looks like it calls "youtube-dl -o - ", which should work
> > > with a
> > >  simple replacement to "yt-dlp -o - ".
> > 
> > The fix will then also require backporting to bookworm,
> > due to the youtube-dl dummy package not providing a wrapper.
> 
> No, it won't. See the above comment about how it only calls youtube-dl if
> supplied with the -y argument, and therefore is perfectly usable without
> youtube-dl. Unless the release team and maintainer feel otherwise and want
> to see it fixed in a point release, it doesn't really rise to the level of
> release-critical for bookworm.

The release team doesn't actually care about bug severities in *stable 
and there is no requirement that only RC bugs could be fixed in *stable, 
but this helps other people like me looking at what bugs should be 
fixed there.

This bug looks like something someone (probably me) might want to fix 
also in bookworm.

cu
Adrian

Bug#1040865: bullseye-pu: package yajl/2.1.0-3+deb11u2

[Tobias Frost]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: y...@packages.debian.org
Control: affects -1 + src:yajl

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

Previous o-s-p-u upload was #1040137; two additional CVEs have
been fixed since then and the fix for CVE-2023-33460 has been found
to be incomplete.

This upload is part of fixing yajl for every release. So far sid, buster
(DLA-3492), stretch and jessie (ELA-892-1) has been targeted.
bookworm s-p-u is pending, see #1040863

CVE-2017-16516

When a crafted JSON file is supplied to yajl, the process might
crash with a SIGABRT in the yajl_string_decode function in
yajl_encode.c. This results potentially in a denial of service.

CVE-2022-24795

The 1.x branch and the 2.x branch of `yajl` contain an integer overflow
which leads to subsequent heap memory corruption when dealing with large
(~2GB) inputs.

CVE-2023-33460

There's a memory leak in yajl 2.1.0 with use of yajl_tree_parse function,
which potentially cause out-of-memory in server and cause crash.


[ Risks ]
Required changes are minimal, see debdiff. Package testsuite passes.

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


For unstable, the fixes are in 2.1.0-5. I have already uploaded to the s-p-u 
queue.
diff -Nru yajl-2.1.0/debian/changelog yajl-2.1.0/debian/changelog
--- yajl-2.1.0/debian/changelog 2023-07-02 13:31:39.0 +0200
+++ yajl-2.1.0/debian/changelog 2023-07-11 19:55:30.0 +0200
@@ -1,3 +1,15 @@
+yajl (2.1.0-3+deb11u2) bullseye; urgency=medium
+
+  [Tobias Frost]
+  * Non-maintainer upload.
+  * Cherry pick John's CVE fixes from 2.1.0-4 and 2.1.0-5
+
+  [John Stamp]
+  * Patch CVE-2017-16516 and CVE-2022-24795 (Closes: #1040036)
+  * The patch for CVE-2023-33460 turned out to be incomplete. Fix that. 
(Closes: #1039984)
+
+ -- Tobias Frost   Tue, 11 Jul 2023 19:55:30 +0200
+
 yajl (2.1.0-3+deb11u1) bullseye; urgency=medium
 
   * Non-maintainer upload.
diff -Nru yajl-2.1.0/debian/patches/CVE-2017-16516.patch 
yajl-2.1.0/debian/patches/CVE-2017-16516.patch
--- yajl-2.1.0/debian/patches/CVE-2017-16516.patch  1970-01-01 
01:00:00.0 +0100
+++ yajl-2.1.0/debian/patches/CVE-2017-16516.patch  2023-07-10 
19:32:01.0 +0200
@@ -0,0 +1,22 @@
+Description: Fix for CVE-2017-16516
+ Potential buffer overread: A JSON file can cause denial of service.
+Origin: 
https://github.com/brianmario/yajl-ruby/commit/a8ca8f476655adaa187eedc60bdc770fff3c51ce
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040036
+Bug: https://github.com/lloyd/yajl/issues/248
+---
+ src/yajl_encode.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/src/yajl_encode.c
 b/src/yajl_encode.c
+@@ -139,8 +139,8 @@
+ end+=3;
+ /* check if this is a surrogate */
+ if ((codepoint & 0xFC00) == 0xD800) {
+-end++;
+-if (str[end] == '\\' && str[end + 1] == 'u') {
++if (end + 2 < len && str[end + 1] == '\\' && str[end 
+ 2] == 'u') {
++end++;
+ unsigned int surrogate = 0;
+ hexToDigit(, str + end + 2);
+ codepoint =
diff -Nru yajl-2.1.0/debian/patches/CVE-2022-24795.patch 
yajl-2.1.0/debian/patches/CVE-2022-24795.patch
--- yajl-2.1.0/debian/patches/CVE-2022-24795.patch  1970-01-01 
01:00:00.0 +0100
+++ yajl-2.1.0/debian/patches/CVE-2022-24795.patch  2023-07-10 
19:32:01.0 +0200
@@ -0,0 +1,30 @@
+Description: Fix for CVE-2022-24795
+ An integer overflow will lead to heap memory corruption with large (~2GB) 
inputs.
+Origin: 
https://github.com/ppisar/yajl/commit/23cea2d7677e396efed78bbf1bf153961fab6bad
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040036
+Bug: https://github.com/lloyd/yajl/issues/239
+---
+ src/yajl_buf.c | 12 +++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/src/yajl_buf.c
 b/src/yajl_buf.c
+@@ -45,7 +45,17 @@
+ 
+ need = buf->len;
+ 
+-while (want >= (need - buf->used)) need <<= 1;
++if (((buf->used > want) ? buf->used : want) > (size_t)(buf->used + want)) 
{
++/* We cannot allocate more memory than SIZE_MAX. */
++abort();
++}
++while (want >= (need - buf->used)) {
++if (need >= (size_t)((size_t)(-1)<<1)>>1) {
++/* need would overflow. */
++abort();
++}
++need <<= 1;
++}
+ 
+ if (need != buf->len) {
+ buf->data = (unsigned char *) YA_REALLOC(buf->alloc, 

Bug#1040864: doxygen: upcoming FTBFS with cairo >= 1.17.6

[Andreas Hasenack]

Package: doxygen
Version: 1.9.4-4
Severity: normal

Dear maintainer,

Cairo 1.17.6 (or close to it) introduced a change[1] in how certain
PDF elements are generated which introduces a build failure in the
doxygen docs[2], as well as in other packages that use doxygen (like
fenics-dolfinx).

That version of cairo is durrently in debian experimental. As soon as
that moves to unstable, the FTBFS will start. Ubuntu is seeing it
right now[4]:

Generating XML output for file generation.cpp
Generating XML output for file generation.h
Generating XML output ferror: Failed to extract bounding box from
generated diagram file
/<>/cpp/doc/latex/d2/d97/classdolfinx_1_1io_1_1FidesWriter__inherit__graph.pdf
 (warning treated as error, aborting now)
Segmentation fault (core dumped)
make[1]: *** [debian/rules:168: override_dh_auto_install-indep] Error 139
make[1]: Leaving directory '/<>'
make: *** [debian/rules:125: binary] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess
returned exit status 2


The upstream bug report[2] had a lot of back and forth until the final
set of fixes made it into the doxygen 1.9.7 release[3]

I collected the commits, and this is the set, where some bits are even
reverted in follow-up commits:

commit 8129939c312e4b5060042fdb93bd071b7b133381
Author: Dimitri van Heesch 
Date:   Thu Jan 5 11:16:24 2023 +0100

issue #9319: Doc build fails with cairo 1.17.6

- Improve detection of "flate" encoded streams

commit 7b2a6027775b0158304635a98de0f9b5672f163a
Author: Dimitri van Heesch 
Date:   Wed Jan 4 10:55:36 2023 +0100

issue #9319: Doc build fails with cairo 1.17.6

commit 293d3beaf03c8798899332b7a948b32c4a3da3e9
Author: albert-github 
Date:   Sun Nov 6 14:07:42 2022 +0100

issue #9319 Doc build fails with cairo 1.17.6

Implementing the use of the environment variable so that always
the non compressed version is written.

commit 9df76e22464a0b6302b7c1cda980a35b39185bc4
Author: albert-github 
Date:   Sat May 7 18:07:26 2022 +0200

issue #9319 Doc build fails with cairo 1.17.6

Fixed compilation issue with the `ceil` function.

commit c22ae5ed4ca8d7e5568be7d5a930ee388117703e
Author: albert-github 
Date:   Sat May 7 17:55:25 2022 +0200

issue #9319 Doc build fails with cairo 1.17.6

The `\MediaBox` field is written as:
```
sscanf(p+bblen,"%d %d %d %d",,,width,height)
```
bur read with
```
sscanf(p+bblen,"%d %d %d %d",,,width,height)
```
this has been corrected.

It doesn't apply cleanly, because a big one is this, which introduces
a vendored gunzip library:

commit 966d69c603b5a6ae22e3132b6ecc6a39b86e52ab
Author: Dimitri van Heesch 
Date:   Wed Jan 4 10:38:58 2023 +0100

Add TinyDeflate as dependency

Maybe others are needed still, this is where I stopped. It seems safer
to update to the new upstream 1.9.7 instead, I suppose.

A short-term workaround would be to call doxygen with
CAIRO_DEBUG_PDF=1. That will tell cairo to not use compression with
those PDF elements, and then the doxygen parsing would work. Problem
is that this would have to be done for all packages that call doxygen
and are affected by this bug, and also it relies on some
cairo-specific behavior which might change.


1. 
https://gitlab.freedesktop.org/cairo/cairo/-/commit/bd514f6b08c1b31a75948fd99c147319e5aa649f
2. https://github.com/doxygen/doxygen/issues/9319
3. https://www.doxygen.nl/manual/changelog.html#log_1_9_7
4. https://bugs.launchpad.net/ubuntu/+source/doxygen/+bug/2026834

Bug#1040863: bookworm-pu: package yajl/2.1.0-3+deb12u2

[Tobias Frost]

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

Previous s-p-u upload was #1040136, two additional CVEs have
been fixed since then and the fix for CVE-2023-33460 has been found
to be incomplete.

This upload is part of fixing yajl for every release. So far sid, buster
(DLA-3492), stretch and jessie (ELA-892-1) has been targeted.

CVE-2017-16516

When a crafted JSON file is supplied to yajl, the process might
crash with a SIGABRT in the yajl_string_decode function in
yajl_encode.c. This results potentially in a denial of service.

CVE-2022-24795

The 1.x branch and the 2.x branch of `yajl` contain an integer overflow
which leads to subsequent heap memory corruption when dealing with large
(~2GB) inputs.

CVE-2023-33460

There's a memory leak in yajl 2.1.0 with use of yajl_tree_parse function,
which potentially cause out-of-memory in server and cause crash.


[ Risks ]
Required changes are minimal, see debdiff. Package testsuite passes.

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


For unstable, the fixes are in 2.1.0-5. I have already uploaded to the s-p-u 
queue.
diff -Nru yajl-2.1.0/debian/changelog yajl-2.1.0/debian/changelog
--- yajl-2.1.0/debian/changelog 2023-07-01 14:55:44.0 +0200
+++ yajl-2.1.0/debian/changelog 2023-07-10 18:06:21.0 +0200
@@ -1,3 +1,15 @@
+yajl (2.1.0-3+deb12u2) bookworm; urgency=medium
+
+  [Tobias Frost]
+  * Non-maintainer upload.
+  * Cherry pick John's CVE fixes from 2.1.0-4 and 2.1.0-5
+
+  [John Stamp]
+  * Patch CVE-2017-16516 and CVE-2022-24795 (Closes: #1040036)
+  * The patch for CVE-2023-33460 turned out to be incomplete. Fix that. 
(Closes: #1039984)
+
+ -- Tobias Frost   Mon, 10 Jul 2023 18:06:21 +0200
+
 yajl (2.1.0-3+deb12u1) bookworm; urgency=medium
 
   * Non-maintainer upload.
diff -Nru yajl-2.1.0/debian/patches/CVE-2017-16516.patch 
yajl-2.1.0/debian/patches/CVE-2017-16516.patch
--- yajl-2.1.0/debian/patches/CVE-2017-16516.patch  1970-01-01 
01:00:00.0 +0100
+++ yajl-2.1.0/debian/patches/CVE-2017-16516.patch  2023-07-10 
18:06:21.0 +0200
@@ -0,0 +1,22 @@
+Description: Fix for CVE-2017-16516
+ Potential buffer overread: A JSON file can cause denial of service.
+Origin: 
https://github.com/brianmario/yajl-ruby/commit/a8ca8f476655adaa187eedc60bdc770fff3c51ce
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040036
+Bug: https://github.com/lloyd/yajl/issues/248
+---
+ src/yajl_encode.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/src/yajl_encode.c
 b/src/yajl_encode.c
+@@ -139,8 +139,8 @@
+ end+=3;
+ /* check if this is a surrogate */
+ if ((codepoint & 0xFC00) == 0xD800) {
+-end++;
+-if (str[end] == '\\' && str[end + 1] == 'u') {
++if (end + 2 < len && str[end + 1] == '\\' && str[end 
+ 2] == 'u') {
++end++;
+ unsigned int surrogate = 0;
+ hexToDigit(, str + end + 2);
+ codepoint =
diff -Nru yajl-2.1.0/debian/patches/CVE-2022-24795.patch 
yajl-2.1.0/debian/patches/CVE-2022-24795.patch
--- yajl-2.1.0/debian/patches/CVE-2022-24795.patch  1970-01-01 
01:00:00.0 +0100
+++ yajl-2.1.0/debian/patches/CVE-2022-24795.patch  2023-07-10 
18:06:21.0 +0200
@@ -0,0 +1,30 @@
+Description: Fix for CVE-2022-24795
+ An integer overflow will lead to heap memory corruption with large (~2GB) 
inputs.
+Origin: 
https://github.com/ppisar/yajl/commit/23cea2d7677e396efed78bbf1bf153961fab6bad
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040036
+Bug: https://github.com/lloyd/yajl/issues/239
+---
+ src/yajl_buf.c | 12 +++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/src/yajl_buf.c
 b/src/yajl_buf.c
+@@ -45,7 +45,17 @@
+ 
+ need = buf->len;
+ 
+-while (want >= (need - buf->used)) need <<= 1;
++if (((buf->used > want) ? buf->used : want) > (size_t)(buf->used + want)) 
{
++/* We cannot allocate more memory than SIZE_MAX. */
++abort();
++}
++while (want >= (need - buf->used)) {
++if (need >= (size_t)((size_t)(-1)<<1)>>1) {
++/* need would overflow. */
++abort();
++}
++need <<= 1;
++}
+ 
+ if (need != buf->len) {
+ buf->data = (unsigned char *) YA_REALLOC(buf->alloc, buf->data, need);
diff -Nru yajl-2.1.0/debian/patches/CVE-2023-33460.patch 
yajl-2.1.0/debian/patches/CVE-2023-33460.patch
--- yajl-2.1.0/debian/patches/CVE-2023-33460.patch  2023-07-01 
14:51:32.0 +0200
+++ 

Bug#1040799: nmu: libnginx-mod-http-modsecurity_1.0.3-1+b1

[Adam D. Barratt]

Control: tags -1 + bookworm confirmed

On Tue, 2023-07-11 at 04:50 +, Tobias Frost wrote:
> ( sent to early) please do a binnmu for bookworm:
> 
> nmu libnginx-mod-http-modsecurity_1.0.3-1+b1 . ANY . bookworm . -m
> "rebuild against pcre2 (Closes: #1037226)" 

As it turns out, the version specification there needs to be for the
source. As only amd64 currently has a binNMU, I've scheduled that as:

nmu 2 libnginx-mod-http-modsecurity_1.0.3-1 . ANY . bookworm . -m "Rebuild 
against pcre2 (Closes: #1037226)"

in order to ensure that the version numbers line up afterwards.

Regards,

Adam

Bug#1040862: hdf5: S3 VFD pulls in networking dependencies (libcurl), please package it as a VFD plugin

[Václav Šmilauer]

Source: hdf5
Version: 1.10.7+repack-4ubuntu2
Severity: wishlist

Dear Maintainer,

currently, libhdf5_serial.so compiles the s3 Virtual File Driver (VFD)
support into the library itself, which leads to inflated .so
dependencies: libcurl.so pulls in about 20 other (networking, crypto)
libs -- below is the output from lddtree. 

Starting from version 1.13.0, HDF5 should support virtual file drivers
(VFDs) as plugins [1], similar to already existing filtering plugins.

This report suggests to package the S3 VFD as a plugin, if possible,
considering that most HDF5 users won't use s3 and the number of
indirect dependencies is high.

Thank you for considering this option. Your packaging work is
appreciated.


$ lddtree /lib/x86_64-linux-gnu/libhdf5_serial.so.103

libhdf5_serial.so.103 => /lib/x86_64-linux-gnu/libhdf5_serial.so.103 
(interpreter => none)
libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3
libcurl.so.4 => /lib/x86_64-linux-gnu/libcurl.so.4
libnghttp2.so.14 => /lib/x86_64-linux-gnu/libnghttp2.so.14
libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0
libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2
librtmp.so.1 => /lib/x86_64-linux-gnu/librtmp.so.1
libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30
libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0
libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8
libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6
ld-linux-x86-64.so.2 => 
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6
libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8
libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10
libssh.so.4 => /lib/x86_64-linux-gnu/libssh.so.4
libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5
libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2
libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0
libldap-2.5.so.0 => /lib/x86_64-linux-gnu/libldap-2.5.so.0
libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2
liblber-2.5.so.0 => /lib/x86_64-linux-gnu/liblber-2.5.so.0
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1
libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1
libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1
libsz.so.2 => /lib/x86_64-linux-gnu/libsz.so.2
libaec.so.0 => /lib/x86_64-linux-gnu/libaec.so.0
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6



[1]
https://www.hdfgroup.org/wp-content/uploads/2021/10/HDF5-VFD-Plugins-HUG.pdf

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

Kernel: Linux 5.15.0-71-generic (SMP w/16 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
(ignored: LC_ALL set to C.UTF-8), LANGUAGE=en_US:cs:sk
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1040858: nmu: libnginx-mod-http-modsecurity_1.0.3-1+b1

[Adam D. Barratt]

On Tue, 2023-07-11 at 17:14 +0100, Adam D. Barratt wrote:
> On Tue, 2023-07-11 at 17:01 +0200, Tobias Frost wrote:
> > nmu libnginx-mod-http-modsecurity_1.0.3-1+b3 . ANY . unstable . -m
> > "rebuild against pcre2 (Closes: #1037226)"
> > 
> [...]
> > As Adam said in #1040799, this needs to be fixed first in unstable,
> > this is
> > why I'm filing this bug. ("b3" is required to ensure that unstable
> > is
> > newr than stable)
> > 
> 
> FTR, the syntax for that is:
> 
> nmu 3 libnginx-mod-http-modsecurity . ANY . unstable . -m "rebuild
> against pcre2 (Closes: #1037226)"
> 

Scheduled.

For clarity, I agree with Paul that this is likely to be papering over
a real bug in one or more of the packages involved, which should be
resolved. Unfortunately, it's also the best solution I can think of
that doesn't leave the package broken in stable for at least another
two months. :-(

Regards,

Adam

Bug#910273: severity of 910273 is important

[Olivier Berger]

Hi.

Ouch, I had lst track myself of this issue. Obviously it kinda solved
itself in between (or I have a disk filling-up unnoticed ;-).

I guess we can probably close now (Oh, I don't remember how to close
properly in the BTS when no longer applicable :-/).

Thanks for caring.

Best regards,

Yves-Alexis Perez  writes:

> On Fri, Oct 05, 2018 at 04:14:41PM +0200, Olivier Berger wrote:
>> severity 910273 important
>> thanks
>> 
>> I wasn't quite sure, but the impact is quite nasty, so raising severity
>> in the hope someone more knowledgable has hints on the likeliness it may
>> happen to anyone else in the next stable...
>
> Hey Olivier, it seems this one went under my radar for a *long time*.
> Did it get solved in the end? I never experienced this one myself.
>
> Regards,
> -- 
> Yves-Alexis Perez
>

-- 
Olivier BERGER
https://www-public.imtbs-tsp.eu/~berger_o/ - OpenPGP 2048R/0xF9EAE3A65819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)