Bug#1052866: python-plaster: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andreas Tille]

Hi,

I upgraded python-plaster to latest upstream - but this did not changed
the test suite error.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1061659: src:golang-github-hanwen-go-fuse: fails to migrate to testing for too long: i386 autopkgtest regression

[Paul Gevers]

Source: golang-github-hanwen-go-fuse
Version: 2.1.0+git20220822.58a7e14-1
Severity: serious
Control: close -1 2.4.2-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:golang-github-hanwen-go-fuse has been 
trying to migrate for 31 days [2]. Hence, I am filing this bug. The 
version in unstable fails its own autopkgtest on i386.


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=golang-github-hanwen-go-fuse



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#988730: CVE-2017-18641

[Salvatore Bonaccorso]

Hi,

On Sun, Jan 28, 2024 at 12:51:58AM +, Mathias Gibbens wrote:
> Control: tags -1 + wontfix
> 
>   lxc-templates is essentially deprecated upstream in favor of
> distrobuilder. From the launchpad discussion:

Thanks for the update. Do you know of any plans of making
distrobuilder available?

Regards,
Salvatore

Bug#1052826: Broken entrypoints package: actually a pybuild issue?

[Andreas Tille]

Hi Jullien,

upstream page[1] says:

  This package is in maintenance-only mode. New code should use the
  importlib.metadata module in the Python standard library to find and
  load entry points.

So it seems we do not need adapt you patch very frequently since
no changes will be to be expected (but the dependencies of entrypoint
should be adapted.

Kind regards
Andreas.

[1] https://github.com/takluyver/entrypoints

-- 
http://fam-tille.de

Bug#1061658: mesa-vulkan-drivers: unnecessarily hard-depends on python3:any

[Solomon Williamson]

Package: mesa-vulkan-drivers
Version: 23.3.4-1
Severity: normal
X-Debbugs-Cc: lark...@parsoma.net

Dear Maintainer,

mesa-vulkan-drivers appaers to list python3:any under its Depends:
packages due to /usr/bin/mesa-overlay-control.py, but this script,
whilst potentially useful, is not necessary for many use cases for
mesa-vulkan-drivers.

I would expect to be able to install mesa-vulkan-drivers without pulling
in Python if a system doesn't otherwise require it, as
Depends: libvulkan1, python3:any, libc6 (>= 2.34),
libdrm-amdgpu1 (>= 2.4.110), libdrm2 (>= 2.4.107-4), libelf1 (>= 0.142),
libexpat1 (>= 2.0.1), libgcc-s1 (>= 3.4), libllvm17, libstdc++6 (>= 11),
libwayland-client0 (>= 1.20.0), libx11-xcb1 (>= 2:1.8.7), ...

triggers.

-- Package-specific info:
glxinfo:

glxinfo is not available (missing mesa-utils package).

/usr/share/bug/xserver-xorg-core/script not available

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

Kernel: Linux 6.6.13-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)

Versions of packages mesa-vulkan-drivers depends on:
ii  libc6   2.37-14
ii  libdrm-amdgpu1  2.4.120-1
ii  libdrm2 2.4.120-1
ii  libelf1 0.190-1+b1
ii  libexpat1   2.5.0-2+b2
ii  libgcc-s1   14-20240127-1
ii  libllvm17   1:17.0.6-5
ii  libstdc++6  14-20240127-1
ii  libvulkan1  1.3.268.0-1
ii  libwayland-client0  1.22.0-2.1
ii  libx11-xcb1 2:1.8.7-1
ii  libxcb-dri3-0   1.15-1
ii  libxcb-present0 1.15-1
ii  libxcb-randr0   1.15-1
ii  libxcb-shm0 1.15-1
ii  libxcb-sync11.15-1
ii  libxcb-xfixes0  1.15-1
ii  libxcb1 1.15-1
ii  libxshmfence1   1.3-1
ii  libzstd11.5.5+dfsg2-2
ii  python3 3.11.6-1
ii  zlib1g  1:1.3.dfsg-3+b1

mesa-vulkan-drivers recommends no packages.

mesa-vulkan-drivers suggests no packages.

-- no debconf information

Bug#1061657: wayland-protocols: Upgrade of Wayland broke a program

[Janusz S . Bień]

Package: wayland-protocols
Version: 1.31-1
Severity: normal
X-Debbugs-Cc: none, Janusz S. Bień 

This is probably not the right place to report my problem, please
reassign as appropriate.

A routine upgrade of Debian to bullseye (which, I understand, included
an upgrade of Wayland) broke a program very important for me. Here is
more information:

https://forum.qt.io/topic/154144/debian-after-upgrading-the-system-the-program-became-unusable-how-to-approach-the-problem/
https://github.com/jsbien/djview4shapes/issues/5

I will appreciate very much your help.

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

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

-- no debconf information

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#1061656: Bad blocks does not support large disks

[TarotApprentice]

Package: e2fsprogsVersion: 1.47.0-2
Tried running badblocks on new Seagate 22TB drive to test before use. Command 
was “badblocks -b 4096 /dev/sdh1” and got the “must be 32-bit value” error 
message. According to fdisk its optimal block size is 4096. I was able to get 
it to run using a block size of 8192 but most larger HDD use 4K as optimal.
There is Debian bug 764636 which relates to an earlier version of e2fsprogs so 
it doesn’t appear to have been addressed.

Bug#1061655: wine: FTBFS with error: unknown conversion type character ‘I’ in format [-Werror=format=]

[Petter Reinholdtsen]

Package: wine
Version: 9.0~repack-2
Severity: serious

The source package fail to build on armel and armhf with the following error.

programs/winedbg/info.c:356:27: error: unknown conversion type character ‘I’ in 
format [-Werror=format=]
  356 | dbg_printf("'0x%0*I64lld' is not a valid module address\n", 
ADDRWIDTH, base);
  |   ^
programs/winedbg/info.c:356:20: error: too many arguments for format 
[-Werror=format-extra-args]
  356 | dbg_printf("'0x%0*I64lld' is not a valid module address\n", 
ADDRWIDTH, base);
  |^~~

The build failures are available from
https://buildd.debian.org/status/package.php?p=wine >.

The issue seem to have been introduced in an upstream commit 2021-10-12:

commit 3a869c1f9ba8a35eb0781fc5cb0b6684a9a7960b
Author: Eric Pouech 
Date:   Tue Oct 12 18:10:58 2021 +0200

winedbg: Simplify some printing of addresses.

Signed-off-by: Eric Pouech 
Signed-off-by: Alexandre Julliard 

diff --git a/programs/winedbg/info.c b/programs/winedbg/info.c
index dc0e6591f1f..477438d83e3 100644
--- a/programs/winedbg/info.c
+++ b/programs/winedbg/info.c
@@ -284,7 +284,7 @@ void info_win32_module(DWORD64 base)
 HeapFree(GetProcessHeap(), 0, im.modules);
 
 if (base && !num_printed)
-dbg_printf("'0x%x%08x' is not a valid module address\n", (DWORD)(base 
>> 32), (DWORD)b
ase);
+dbg_printf("'0x%0*I64x' is not a valid module address\n", ADDRWIDTH, 
base);
 }
 
 struct class_walker



I do not understand the printf() notation well enough to understand what
is wrong.  According to printf(3) in glibc 2.36, the I flag was added in
glibc 2.2.  Could it be a compiler error, that the compiler do not
understand this "new" flag?

-- 
Happy hacking
Petter Reinholdtsen

Bug#1061654: RFS: vdr-plugin-wirbelscan/2023.10.15-1 [ITP] -- Wirbelscan plugin for VDR

[Phil Wyett]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "vdr-plugin-wirbelscan":

 * Package name : vdr-plugin-wirbelscan
   Version  : 2023.10.15-1
   Upstream contact : Winfried Koehler 
 * URL  : https://www.gen2vdr.de/wirbel/wirbelscan/index2.html
 * License  : GPL-2.0-only
 * Vcs  : https://salsa.debian.org/kathenas/vdr-plugin-wirbelscan
   Section  : video

The source builds the following binary packages:

  vdr-plugin-wirbelscan - Wirbelscan plugin for VDR

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

  https://mentors.debian.net/package/vdr-plugin-wirbelscan/

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

  dget -x
https://mentors.debian.net/debian/pool/main/v/vdr-plugin-wirbelscan/vdr-plugin-wirbelscan_2023.10.15-1.dsc

Changes for the initial release:

 vdr-plugin-wirbelscan (2023.10.15-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1061649)

Note:

VCS etc. will be created once the package has been accepted into experimental.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

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




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

Bug#1061653: RFS: dpkg-dev-el/37.11 [RC] [Team] -- Emacs helpers specific to Debian development

[Xiyue Deng]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "dpkg-dev-el":

 * Package name : dpkg-dev-el
   Version  : 37.11
   Upstream contact : Debian Emacsen Team 
 * URL  : https://salsa.debian.org/emacsen-team/dpkg-dev-el
 * License  : GPL-2+
 * Vcs  : https://salsa.debian.org/emacsen-team/dpkg-dev-el
   Section  : lisp

The source builds the following binary packages:

  elpa-dpkg-dev-el - Emacs helpers specific to Debian development
  dpkg-dev-el - Transition package, dpkg-dev-el to elpa-dpkg-dev-el

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

  https://mentors.debian.net/package/dpkg-dev-el/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dpkg-dev-el/dpkg-dev-el_37.11.dsc

Changes since the last upload:

 dpkg-dev-el (37.11) unstable; urgency=medium
 .
   * Team upload.
   * d/control: add elpa-debian-el to Build-Depends (Closes: #1061650).

Regards,
-- 
  Xiyue Deng

Bug#1061650: elpa-dpkg-dev-el: fails to install: debian-bts-control.el:85:2: Error: Cannot open load file: No such file or directory, debian-bug

[Xiyue Deng]

Control: tags -1 pending

Hi Andreas,

Andreas Beckmann  writes:

> Package: elpa-dpkg-dev-el
> Version: 37.10
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package failed to install.
>
>>From the attached log (scroll to the bottom...):
>
>   Setting up elpa-dpkg-dev-el (37.10) ...
>   Install emacsen-common for emacs
>   emacsen-common: Handling install of emacsen flavor emacs
>   Install elpa-dpkg-dev-el for emacs
>   install/dpkg-dev-el-37.10: Handling install of emacsen flavor emacs
>   install/dpkg-dev-el-37.10: byte-compiling for emacs
>
>   In toplevel form:
>   debian-bts-control.el:85:2: Error: Cannot open load file: No such file or 
> directory, debian-bug
>
>   In debian-changelog-mode:
>   debian-changelog-mode.el:1382:4: Warning: `easy-menu-add' is an obsolete 
> function (as of 28.1); this was always a no-op in Emacs and can be safely 
> removed.
>   debian-changelog-mode.el:1382:18: Warning: reference to free variable 
> `debian-changelog-menu'
>   debian-changelog-mode.el:1423:4: Warning: `make-face' called with 2 
> arguments, but accepts only 1
>   debian-changelog-mode.el:1428:4: Warning: `set-face-foreground' called with 
> 5 arguments, but accepts only 2 or 3
>
>   In end of data:
>   debian-changelog-mode.el:1679:12: Warning: the function 
> `set-extent-property' is not known to be defined.
>   debian-changelog-mode.el:1676:25: Warning: the function `make-extent' is 
> not known to be defined.
>   debian-changelog-mode.el:1654:18: Warning: the function `delete-extent' is 
> not known to be defined.
>   debian-changelog-mode.el:1653:42: Warning: the function 
> `extent-end-position' is not known to be defined.
>   debian-changelog-mode.el:1652:42: Warning: the function 
> `extent-start-position' is not known to be defined.
>   debian-changelog-mode.el:1651:22: Warning: the function `extent-detached-p' 
> is not known to be defined.
>   debian-changelog-mode.el:1625:14: Warning: the function `set-keymap-name' 
> is not known to be defined.
>   debian-changelog-mode.el:880:4: Warning: the function 
> `debian-bug-build-bug-menu' is not known to be defined.
>
>   In toplevel form:
>   debian-control-mode.el:198:11: Warning: `max-specpdl-size' is an obsolete 
> variable (as of 29.1).
>   debian-control-mode.el:206:11: Warning: `max-specpdl-size' is an obsolete 
> variable (as of 29.1).
>
>   In debian-control-mode:
>   debian-control-mode.el:269:4: Warning: `easy-menu-add' is an obsolete 
> function (as of 28.1); this was always a no-op in Emacs and can be safely 
> removed.
>   debian-control-mode.el:270:34: Warning: reference to free variable 
> `goto-address-highlight-p'
>
>   In end of data:
>   debian-control-mode.el:424:28: Warning: the function `position' is not 
> known to be defined.
>   debian-control-mode.el:408:43: Warning: the function `subseq' is not known 
> to be defined.
>
>   In debian-copyright-mode:
>   debian-copyright.el:76:16: Warning: reference to free variable 
> `goto-address-highlight-p'
>
>   In toplevel form:
>   dpkg-dev-el.el:118:44: Warning: reference to free variable `filename'
>
>   In readme-debian-update-timestamp:
>   readme-debian.el:64:2: Warning: docstring wider than 80 characters
>   readme-debian.el:67:6: Warning: `goto-line' is for interactive use only; 
> use `forward-line' instead.
>
>   In readme-debian-mode:
>   readme-debian.el:119:14: Warning: `write-contents-hooks' is an obsolete 
> variable (as of 22.1); use `write-contents-functions' instead.
>
>   In end of data:
>   readme-debian.el:118:8: Warning: the function `make-local-hook' is not 
> known to be defined.
>   ERROR: install script from elpa-dpkg-dev-el package failed
>   dpkg: error processing package elpa-dpkg-dev-el (--configure):
>installed elpa-dpkg-dev-el package post-installation script subprocess 
> returned error exit status 1
>   Errors were encountered while processing:
>elpa-dpkg-dev-el
>
>
> Cheers,
>
> Andreas
>
>

Thanks for detecting the bug!  It looks like without byte-compiling we
weren't able to detect such issue when building.  I have added the
missing dependency of elpa-debian-el[1] and prepared another version on
mentors[2] for which I would need a sponsor.  TIA!

[1] 
https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/5d6a77b97440ee9da7d0209bf7e7579506c8b8b2
[2] https://mentors.debian.net/package/dpkg-dev-el/

-- 
Xiyue Deng

Bug#1042325: python-miio: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Scott Talbert]

On Sat, 27 Jan 2024, Andreas Tille wrote:


Control: tags -1 help

Hi,

I upgraded python-miio in Git.  Unfortunately there are some test suite 
errors[1]
Any help would be welcome
Andreas.


Fixed.

Bug#550255:

[Timothy Pearson]

Is this still a problem?  If so, the package to install will be rss-glx-dbgsym, 
and a "thread apply all bt" in GDB would give the needed debug information once 
the flux process hangs.

Bug#1061652: bookworm-pu: package rss-glx/0.9.1-6.4+deb12u1

[Timothy Pearson]

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

[ Reason ]
The current rss-glx package in Bookworm contains two bugs that
render it unusable for a large percentage of its target audience
without direct intervention (to move files to the correct location)
or recompilation (if the user's GPU doesn't automatically flush
before buffer swap).

[ Impact ]
rss-glx continues to silently fail for a significant proportion
of its target user base.

[ Tests ]
Tested in several modes on a POWER host with an AMD GPU, using
the open source GPU drivers.

[ Risks ]
The only risk would be potentially triggering a latent GPU driver
bug that I am unaware of on non-AMD hardware.  Such a bug would
need to be fixed in the relevant driver, as the operation order
now used in the updated rss-glx source is correct per standards.

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

[ Changes ]
 * debian/patches/glfinish.patch: Call GLFinish() prior to glXSwapBuffers()
   (Closes: #1061507)
 * Install screensavers into /usr/libexec/xscreensaver (Closes: #979490)dpkg-source: warning: extracting unsigned source package (/disk2/SCREENSAVERS/NEW.FOR_UPLOAD/rss-glx_0.9.1-6.4.dsc)
diff -Nru rss-glx-0.9.1/debian/changelog rss-glx-0.9.1/debian/changelog
--- rss-glx-0.9.1/debian/changelog	2021-10-16 08:11:19.0 -0500
+++ rss-glx-0.9.1/debian/changelog	2024-01-27 08:41:00.0 -0600
@@ -1,3 +1,12 @@
+rss-glx (0.9.1-6.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/glfinish.patch: Call GLFinish() prior to glXSwapBuffers()
+(Closes: #1061507)
+  * Install screensavers into /usr/libexec/xscreensaver (Closes: #979490)
+
+ -- Timothy Pearson   Sat, 27 Jan 2024 08:41:00 -0600
+
 rss-glx (0.9.1-6.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru rss-glx-0.9.1/debian/patches/glfinish.patch rss-glx-0.9.1/debian/patches/glfinish.patch
--- rss-glx-0.9.1/debian/patches/glfinish.patch	1969-12-31 18:00:00.0 -0600
+++ rss-glx-0.9.1/debian/patches/glfinish.patch	2024-01-25 10:43:27.0 -0600
@@ -0,0 +1,12 @@
+Index: rss-glx-0.9.1/src/driver.c
+===
+--- rss-glx-0.9.1.orig/src/driver.c
 rss-glx-0.9.1/src/driver.c
+@@ -238,6 +238,7 @@
+ 
+ 		if (drawEnabled) {
+ 			hack_draw (XStuff, (double)now.tv_sec + now.tv_usec / 100.0f, frameTimeSoFar / 100.0f);
++			glFinish();
+ 
+ 			glXSwapBuffers (XStuff->display, XStuff->window);
+ 		}
diff -Nru rss-glx-0.9.1/debian/patches/series rss-glx-0.9.1/debian/patches/series
--- rss-glx-0.9.1/debian/patches/series	2021-10-16 08:05:56.0 -0500
+++ rss-glx-0.9.1/debian/patches/series	2024-01-27 08:41:00.0 -0600
@@ -2,3 +2,4 @@
 pixelcity-cpp.patch
 readme.patch
 include-cstddef.patch
+glfinish.patch
diff -Nru rss-glx-0.9.1/debian/rules rss-glx-0.9.1/debian/rules
--- rss-glx-0.9.1/debian/rules	2011-05-27 10:01:25.0 -0500
+++ rss-glx-0.9.1/debian/rules	2024-01-27 08:41:00.0 -0600
@@ -15,12 +15,12 @@
 override_dh_auto_configure:
 	dh_auto_configure -- --with-configdir=/usr/share/xscreensaver/config \
 		--with-kdessconfigdir=/usr/share/kde4/services/ScreenSavers \
-		--bindir=/usr/lib/xscreensaver --enable-static=no \
+		--bindir=/usr/libexec/xscreensaver --enable-static=no \
 		LDFLAGS=-Wl,--as-needed
 
 override_dh_auto_install:
 	dh_auto_install
-	mv $(CURDIR)/debian/rss-glx/usr/lib/xscreensaver/rss-glx_install.pl \
+	mv $(CURDIR)/debian/rss-glx/usr/libexec/xscreensaver/rss-glx_install.pl \
 		$(CURDIR)/debian/rss-glx/usr/bin/rss-glx_install
 	cp $(CURDIR)/debian/desktop_files/*.desktop \
 		$(CURDIR)/debian/rss-glx/usr/share/applications/screensavers

Bug#1061651: wiki.debian.org/eSCL ScannerShare.com domain is for sale

[Luc]

Package: www.debian.org
Severity: normal


Hello everyone at the end of https://wiki.debian.org/eSCL article there is
a link to a domain which is for sale so not available anymore.

Bug#1061650: elpa-dpkg-dev-el: fails to install: debian-bts-control.el:85:2: Error: Cannot open load file: No such file or directory, debian-bug

[Andreas Beckmann]

Package: elpa-dpkg-dev-el
Version: 37.10
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install.

>From the attached log (scroll to the bottom...):

  Setting up elpa-dpkg-dev-el (37.10) ...
  Install emacsen-common for emacs
  emacsen-common: Handling install of emacsen flavor emacs
  Install elpa-dpkg-dev-el for emacs
  install/dpkg-dev-el-37.10: Handling install of emacsen flavor emacs
  install/dpkg-dev-el-37.10: byte-compiling for emacs

  In toplevel form:
  debian-bts-control.el:85:2: Error: Cannot open load file: No such file or 
directory, debian-bug

  In debian-changelog-mode:
  debian-changelog-mode.el:1382:4: Warning: `easy-menu-add' is an obsolete 
function (as of 28.1); this was always a no-op in Emacs and can be safely 
removed.
  debian-changelog-mode.el:1382:18: Warning: reference to free variable 
`debian-changelog-menu'
  debian-changelog-mode.el:1423:4: Warning: `make-face' called with 2 
arguments, but accepts only 1
  debian-changelog-mode.el:1428:4: Warning: `set-face-foreground' called with 5 
arguments, but accepts only 2 or 3

  In end of data:
  debian-changelog-mode.el:1679:12: Warning: the function `set-extent-property' 
is not known to be defined.
  debian-changelog-mode.el:1676:25: Warning: the function `make-extent' is not 
known to be defined.
  debian-changelog-mode.el:1654:18: Warning: the function `delete-extent' is 
not known to be defined.
  debian-changelog-mode.el:1653:42: Warning: the function `extent-end-position' 
is not known to be defined.
  debian-changelog-mode.el:1652:42: Warning: the function 
`extent-start-position' is not known to be defined.
  debian-changelog-mode.el:1651:22: Warning: the function `extent-detached-p' 
is not known to be defined.
  debian-changelog-mode.el:1625:14: Warning: the function `set-keymap-name' is 
not known to be defined.
  debian-changelog-mode.el:880:4: Warning: the function 
`debian-bug-build-bug-menu' is not known to be defined.

  In toplevel form:
  debian-control-mode.el:198:11: Warning: `max-specpdl-size' is an obsolete 
variable (as of 29.1).
  debian-control-mode.el:206:11: Warning: `max-specpdl-size' is an obsolete 
variable (as of 29.1).

  In debian-control-mode:
  debian-control-mode.el:269:4: Warning: `easy-menu-add' is an obsolete 
function (as of 28.1); this was always a no-op in Emacs and can be safely 
removed.
  debian-control-mode.el:270:34: Warning: reference to free variable 
`goto-address-highlight-p'

  In end of data:
  debian-control-mode.el:424:28: Warning: the function `position' is not known 
to be defined.
  debian-control-mode.el:408:43: Warning: the function `subseq' is not known to 
be defined.

  In debian-copyright-mode:
  debian-copyright.el:76:16: Warning: reference to free variable 
`goto-address-highlight-p'

  In toplevel form:
  dpkg-dev-el.el:118:44: Warning: reference to free variable `filename'

  In readme-debian-update-timestamp:
  readme-debian.el:64:2: Warning: docstring wider than 80 characters
  readme-debian.el:67:6: Warning: `goto-line' is for interactive use only; use 
`forward-line' instead.

  In readme-debian-mode:
  readme-debian.el:119:14: Warning: `write-contents-hooks' is an obsolete 
variable (as of 22.1); use `write-contents-functions' instead.

  In end of data:
  readme-debian.el:118:8: Warning: the function `make-local-hook' is not known 
to be defined.
  ERROR: install script from elpa-dpkg-dev-el package failed
  dpkg: error processing package elpa-dpkg-dev-el (--configure):
   installed elpa-dpkg-dev-el package post-installation script subprocess 
returned error exit status 1
  Errors were encountered while processing:
   elpa-dpkg-dev-el


Cheers,

Andreas


elpa-dpkg-dev-el=37.10_emacs.log.gz
Description: application/gzip

Bug#1061649: ITP: vdr-plugin-wirbelscan -- This plugin performs channel scans for digital tv cards

[Phil Wyett]

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

* Package name: vdr-plugin-wirbelscan
  Version : 2023.10.15
  Upstream Author : Winfried Koehler 
* URL : https://github.com/wirbel-at-vdr-portal/wirbelscan-dev
* License : GPL-2
  Programming Lang: C++
  Description : This plugin performs channel scans for digital tv cards.

Notes:

* Goal is to take over from embedded wirbelscan code currently in some Debian 
packages.
* Description will need some tuning.
* Package will need a sponsor if my DD/with upload process is not completed.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

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




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

Bug#1061648: gnat-13-x86-64-linux-gnu: needs to inherit the Conflicts from gnat-13

[Andreas Beckmann]

Package: gnat-13-x86-64-linux-gnu
Version: 13.2.0-12
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package gnat-13-x86-64-linux-gnu.
  Preparing to unpack .../5-gnat-13-x86-64-linux-gnu_13.2.0-12_amd64.deb ...
  Unpacking gnat-13-x86-64-linux-gnu (13.2.0-12) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-N8eYXp/5-gnat-13-x86-64-linux-gnu_13.2.0-12_amd64.deb 
(--unpack):
   trying to overwrite '/usr/bin/x86_64-linux-gnu-gnatgcc', which is also in 
package gnat-12 12.3.0-14
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-N8eYXp/5-gnat-13-x86-64-linux-gnu_13.2.0-12_amd64.deb

There are currently

Package: gnat-13
Version: 13.2.0-12
Depends: gnat-13-x86-64-linux-gnu (= 13.2.0-12), gcc-13-base (= 13.2.0-12), 
gcc-13 (>= 13)
Suggests: gnat-13-doc, ada-reference-manual-2012, gnat-13-sjlj
Conflicts: gnat-10, gnat-11, gnat-12, gnat-4.9, gnat-5, gnat-6, gnat-7, gnat-8, 
gnat-9

but these Conflicts are no longer effective (and can probably be
removed) due to the introduction of gnat-13-

This bug probably affects all gnat-13- packages for all
architectures.


cheers,

Andreas

Bug#988730: CVE-2017-18641

[Mathias Gibbens]

Control: tags -1 + wontfix

  lxc-templates is essentially deprecated upstream in favor of
distrobuilder. From the launchpad discussion:

On 2020-02-05, Stéphane Graber wrote:
> Back in LXC 3.0 we moved the legacy template scripts to their own
> repository at https://github.com/lxc/lxc-templates and they are now
> community maintained without security/lts commitments on them on our
> side. Ubuntu still ships lxc-templates but it does so in universe
> rather than main, matching the upstream commitment.

  And there was a discussion in debian-lts[1] about marking this CVE as
no-dsa or ignored, which is how things are flagged in the security
tacker.

  Given the amount of work required for very little gain and an
inactive upstream, I'm tagging this bug as wontfix.

Mathias

[1] -- https://lists.debian.org/debian-lts/2020/02/msg00102.html


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

Bug#1061647: libgccjit-14-doc: missing Breaks+Replaces: libgccjit-13-doc (and maybe more old versions)

[Andreas Beckmann]

Package: libgccjit-14-doc
Version: 14-20240127-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libgccjit-14-doc_14-20240127-1_all.deb ...
  Unpacking libgccjit-14-doc (14-20240127-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libgccjit-14-doc_14-20240127-1_all.deb (--unpack):
   trying to overwrite '/usr/share/info/libgccjit-figures/factorial.png', which 
is also in package libgccjit-13-doc 13.2.0-10
  Errors were encountered while processing:
   /var/cache/apt/archives/libgccjit-14-doc_14-20240127-1_all.deb

The files in conflict are

  usr/share/info/libgccjit-figures/factorial.png
  usr/share/info/libgccjit-figures/factorial1.png
  usr/share/info/libgccjit-figures/sum-of-squares.png
  usr/share/info/libgccjit-figures/sum-of-squares1.png
  usr/share/info/libgccjit.info.gz


cheers,

Andreas


libgccjit-13-doc=13.2.0-10_libgccjit-14-doc=14-20240127-1.log.gz
Description: application/gzip

Bug#1061636: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Johannes Schauer Marin Rodrigues]

Quoting Francesco Poli (wintermute) (2024-01-27 19:44:15)
> As I said in bug report [#1061634], I've been able to create a QEMU/KVM
> virtual machine image for autopkgtests:
> 
>   $ mkdir -p ~/var/cache/sbuild/
>   $ cd /dev/shm
>   $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
> --size=25G --boot=efi sid sid-amd64.img
>   $ chmod 660 sid-amd64.img
>   $ mv -i sid-amd64.img ~/var/cache/sbuild/
> 
> [#1061634]: 
> 
> It works for autopkgtests, but I wanted to use the same virtual machine
> image to build Debian packages with sbuild-qemu.
> The first thing I tested is the update of the VM image with
> sbuild-qemu-update:
> 
>   $ sbuild-qemu-update --arch=amd64 sid-amd64.img
>   qemu-system-x86_64 -enable-kvm -object 
> rng-random,filename=/dev/urandom,id=rng0 -device 
> virtio-rng-pci,rng=rng0,id=rng-device0 -device virtio-serial -nic 
> user,model=virtio -m 1024 -smp 1 -nographic sid-amd64.img
> 
> This command does not seem to work: it uses 100 % of one CPU core and
> seemingly does nothing, until I interrupt it by pressing [Ctrl+C].
> 
> Is there any special tweak or configuration needed to use
> sbuild-qemu-update with mmdebstrap-autopkgtest-build-qemu VM images?
> Where is this documented?
> 
> Otherwise, if this is an actual bug, please fix
> mmdebstrap-autopkgtest-build-qemu

The images you create with mmdebstrap-autopkgtest-build-qemu require efi. But
sbuild-qemu does pass the --boot parameter to autopkgtest-virt-qemu. If you are
on amd64 and if your image is for amd64, then autopkgtest-virt-qemu will
default to bios boot which is incompatible with the images created by
mmdebstrap-autopkgtest-build-qemu. You could add a dirty local hack to
sbuild-qemu and let it add --boot=efi via --autopkgtest-virt-server-opt to see
if this is it. If that is the problem, please re-assign this bug to sbuild.

> or help sbuild-qemu developers to fix sbuild-qemu-update.

Did you look up who the sbuild developers are? ;)

> Thanks for your time and dedication!

Thank you for your bugs!! <3

cheers, josch

signature.asc
Description: signature

Bug#1061634: mmdebstrap: possible mmdebstrap-autopkgtest-build-qemu improvements

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Francesco Poli (wintermute) (2024-01-27 19:20:08)
> I've been able to create a QEMU/KVM virtual machine image for autopkgtests:
> 
>   $ mkdir -p ~/var/cache/sbuild/
>   $ cd /dev/shm
>   $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
> --size=25G --boot=efi sid sid-amd64.img
>   $ chmod 660 sid-amd64.img
>   $ mv -i sid-amd64.img ~/var/cache/sbuild/
> 
> It is able to run autopkgtests:
> 
>   $ autopkgtest --output-dir ./${SRCPKG}_autopkgtest.out \
> --summary./${SRCPKG}_autopkgtest.summary \
> --apt-upgrade -B ./${SRCPKG}_amd64.changes -- \
> qemu --boot=efi --overlay-dir /dev/shm \
> ~/var/cache/sbuild/sid-amd64.img
> 
> My comments / suggestions for improvements:
> 
>   * I had to manually fix the permissions, since the image file was
> originally created with the following weird ones:
> 
>   $ ls -l --si sid-amd64.img 
>   -rw-r-xrwx 1 $USER $USER 27G Jan 27 17:48 sid-amd64.img

those are some funny permission bits. When I run
mmdebstrap-autopkgtest-build-qemu I get:

$ ls -lha disk.img
-rw-r--r-- 1 josch josch 26G Jan 28 00:03 disk.img

Looks fine to me.

> I think the file permissions should be set (possibly at the end of the
> mmdebstrap-autopkgtest-build-qemu run) as they would "naturally" result
> from the user's umask:
> 
>   $ cd /dev/shm
>   $ touch foo
>   $ ls -l --si foo 
>   -rw-rw 1 $USER $USER 0 Jan 27 19:00 foo

They are set, taking the user's umask into account. What is your umask?

> That's why I manually changed the permissions at the end:
> 
>   $ chmod 660 sid-amd64.img
>   $ ls -l --si sid_amd64.img
>   -rw-rw 1 $USER $USER 27G Jan 27 17:48 sid-amd64.img
> 
> I suggest that mmdebstrap-autopkgtest-build-qemu applies this fix
> automatically.

Lets first understand the problem before adding a workaround.
mmdebstrap-autopkgtest-build-qemu runs this command to set the permissions:

chmod "$(printf %o "$(( 0666 - 0$(umask) ))")" "$IMAGE"

Could you add some debugging output to the script to figure out what went wrong
and where?

>   * I was surprised to see a 25 GiB image fit into a 7.7 GiB filesystem:
> 
>   $ cd /dev/shm
>   $ ls -l -h sid-amd64.img
>   -rw-rw 1 $USER $USER 26G Jan 27 17:48 sid-amd64.img
>   $ df -h .
>   Filesystem  Size  Used Avail Use% Mounted on
>   tmpfs   7.7G  765M  7.0G  10% /dev/shm
> 
> Well, the mystery is solved by looking at the allocated size:
> 
>   $ ls -l -h -s sid-amd64.img 
>   662M -rw-rw 1 $USER $USER 26G Jan 27 17:48 sid-amd64.img
> 
> Would it be less confusing, if mmdebstrap-autopkgtest-build-qemu created
> .qcow2 images?

I don't understand why sparse files are confusing to you. Why would qcow images
be less confusing? Can you list some reasons why qcow2 should be preferred over
raw images? Compression comes to mind but that is at the cost of doing that
compression in the first place and it is not obvious to me whether cpu cycles
or disk space are more scarce. For example, my platform is an ARM Cortex A53.
To give you some idea how slow it is: it takes 30 seconds before a youtube
video starts playing. At the same time, the system has a 2 TB hard disk. I much
prefer a bigger disk image which needs less CPU when I want to create and use
it. What is your use-case?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1061646: falcosecurity-libs: build-depends on unavailable libluajit-5.1-dev

[Dima Kogan]

Thanks for the note. 0.14.1-2 makes the build work on arm64, and I
wanted to get that done, before thinking of other arches. I' about to
apply your suggested patches.

Bug#1061646: falcosecurity-libs: build-depends on unavailable libluajit-5.1-dev

[Aurelien Jarno]

Source: falcosecurity-libs
Version: 0.14.1-2
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

falcosecurity-libs now build-depends unconditionally on
libluajit-5.1-dev. This prevents the package to be buildable on some
architectures where it was available before: ppc64el for release
architectures, and riscv64 and ppc64 for non-release architectures.

The version 0.14.1-1 force libsinsp to be linked to a few additional
libraries, including -lluajit-5.1. This causes FTBFS on architectures
where it was not build-depended on. This has been wrongly fixed in
version 0.14.1-2 by changing the build-depends on libluajit-5.1-dev to
be unconditional.

The patch below fixes the issue by using the ${LUAJIT_LIB} cmake
variable instead of using -lluajit-5.1 and reverting the
build-dependency changes. At the same time, the list of architectures
which have libluajit-5.1-dev has been updated to reflect the current
status.

--- falcosecurity-libs-0.14.1/debian/control
+++ falcosecurity-libs-0.14.1/debian/control
@@ -21,7 +21,7 @@
protobuf-compiler,
protobuf-compiler-grpc,
libprotobuf-dev,
-   libluajit-5.1-dev,
+   libluajit-5.1-dev [amd64 arm64 armel armhf i386 mips64el s390x] 
| liblua5.1-0-dev,
libelf-dev,
libre2-dev,
libcap-dev,
--- 
falcosecurity-libs-0.14.1/debian/patches/libsinsp-added-missing-libraries.patch
+++ 
falcosecurity-libs-0.14.1/debian/patches/libsinsp-added-missing-libraries.patch
@@ -7,7 +7,7 @@
"${JSONCPP_LIB}"
"${RE2_LIB}"
 +  -lprotobuf
-+  -lluajit-5.1
++  "${LUAJIT_LIB}"
 +  -lgrpc++
  )
  

Bug#1061645: transition: poco

[Bastian Germann]

Package: release.debian.org
Control: affects -1 poco
X-Debbugs-Cc: p...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: transition
Severity: normal
Control: forwarded -1 https://release.debian.org/transitions/html/auto-poco.html

poco is available in experimental with the libraries' SOVERSIONs at 100.
This transition is from SOVERSION 80.
The auto-generated Ben file is okay and all reverse dependencies build fine.

Bug#1001105: can I help with pyvista packaging?

[Andreas Tille]

Hi Francesco,

thanks a lot for the fix - the package is uploaded to new.

Kind regards
   Andreas.

Am Sat, Jan 27, 2024 at 10:23:20PM +0100 schrieb Francesco Ballarin:
> A first version is available at
> https://salsa.debian.org/science-team/python-pyvista
> in case you want to have a look before I/we change it from UNRELEASED
> to unstable.
> 
> autopkgtest passes.
> test-crossbuild-arm64 is failing, but is allowed to do so, not sure if
> it is relevant.
> 
> As agreed, interactive plotting within jupyter is not considered for now.
> 
> Cheers,
> Francesco
> 
> 
> On Sat, Jan 27, 2024 at 7:08 PM Andreas Tille  wrote:
> >
> > Am Sat, Jan 27, 2024 at 06:28:14PM +0100 schrieb Francesco Ballarin:
> > > OK Andreas, I'll push to master. Let me take the lead on that, and I'll 
> > > come back to you and Drew with progress and questions.
> >
> > Perfectly fine for me.
> >
> > > I think I have some ideas on how to get started on the basic package.
> > >
> > > The full package (i.e., all optional components that one can install with 
> > > "pip install pyvista[all]") will be much more complex, because it depends 
> > > on trame, which comes split in five interdependent packages
> > > 
> > > trame3.2.4
> > > trame-client 2.11.2
> > > trame-server 2.11.7
> > > trame-vtk2.5.8
> > > trame-vuetify2.3.1
> > > 
> > > and who knows how many dependencies each one of those have.
> >
> > Sounds complex and I'd love to stay in background given that I need to
> > care for >1000 packages.
> >
> > > Down the line I'd want to have that too, because that's what I actually 
> > > need for plotting within jupyter notebooks in my libraries, see for 
> > > instance
> > > https://viskex.github.io/tutorials/01_introduction/tutorial_plot_subdomains_3d_dolfinx.html
> > > but let's start with a less ambitious goal ;)
> >
> > +1
> >
> > > I think that the error you see is because python3-vtk9 is only built for 
> > > python 3.11, but unit tests are getting run with python 3.12.
> > > At the moment, I'd like to disable that part adding an empty 
> > > override_dh_auto_test-indep and run tests with autopkgtest only, so that 
> > > I can have a clearer idea on the difference between dependencies required 
> > > for building the package vs dependencies required for testing it, because 
> > > I know from experience that there are a few packages that are only needed 
> > > for testing pyvista.
> >
> > Perfectly fine for me.  Feel free to turn the RFP in ITP and I can
> > sponsor the upload if needed.
> >
> > Thanks a lot for your help
> > Andreas.
> >
> > --
> > http://fam-tille.de
> [http://static.unicatt.it/ext-portale/5xmille_firma_mail_2023.jpg] 
> 
> 
> 

-- 
http://fam-tille.de

Bug#1050256: AppArmor breaks locking non-fs Unix sockets

[John Johansen]

On 1/27/24 01:21, Salvatore Bonaccorso wrote:

Hi John,

On Sun, Dec 31, 2023 at 04:24:47AM +, Mathias Gibbens wrote:

On Sat, 2023-12-30 at 16:44 +0100, Salvatore Bonaccorso wrote:

John, did you had a chance to work on this backport for 6.1.y stable
upstream so we could pick it downstream in Debian in one of the next
stable imports? Cherry-picking 1cf26c3d2c4c ("apparmor: fix apparmor
mediating locking non-fs unix sockets") does not work, if not
havinging the work around e2967ede2297 ("apparmor: compute policydb
permission on profile load") AFAICS, so that needs a 6.1.y specific
backport submitted to sta...@vger.kernel.org ?

I think we could have people from this bug as well providing a
Tested-by when necessary. I'm not feeling confident enough to be able
to provide myself such a patch to sent to stable (and you only giving
an Acked-by/Reviewed-by), so if you can help out here with your
upstream hat on that would be more than appreciated and welcome :)

Thanks a lot for your work!


   I played around with this a bit the past week as well, and came to
the same conclusion as Salvatore did that commits e2967ede2297 and
1cf26c3d2c4c need to be cherry-picked back to the 6.1 stable tree.

   I've attached the two commits rebased onto 6.1.y as patches to this
message. Commit e2967ede2297 needed a little bit of touchup to apply
cleanly, and 1cf26c3d2c4c just needed adjustments for line number
changes. I included some comments at the top of each patch.

   With these two commits cherry-picked on top of the 6.1.69 kernel, I
can boot a bookworm system and successfully start a service within a
container that utilizes `PrivateNetwork=yes`. Rebooting back into an
unpatched vanilla 6.1.69 kernel continues to show the problem.

   While I didn't see any immediate issues (ie, `aa-status` and log
files looked OK), I don't understand the changes in the first commit
well enough to be confident in sending these patches for inclusion in
the upstream stable tree on my own.


Do you had a chance to look at this for 6.1.y upstream?

Asking/Poking since the point release dates are now clear:

https://lists.debian.org/debian-security/2024/01/msg5.html

if possible I would like to include those fixes, but only if they are
at least queued fror 6.1.y itself to not diverge from upstream.

Otherwise we will wait another round, but which means usually 2 months
for the point release cadence.


I am looking at it right now, I should be done with it today

Bug#1042325: python-miio: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andreas Tille]

Control: tags -1 help

Hi,

I upgraded python-miio in Git.  Unfortunately there are some test suite 
errors[1]
Any help would be welcome
 Andreas.


[1] https://salsa.debian.org/python-team/packages/miio/-/jobs/5212674

-- 
http://fam-tille.de

Bug#995053: dh_assistant command for listing installed files

[Niels Thykier]

Jelmer Vernooij:

Hi Niels,

[... past correspondence removed ]
> Part of the challenge here is that I'm still trying to figure out
exactly what we can do here as well.



Hi Jelmer

I have news on what is possible. It is not directly what you asked for, 
but I think you will find it interesting.


 $ apt satisfy 'debhelper (>= 13.13), dh-debputy (>= 0.1.18)'
 $ git clone https://salsa.debian.org/debian/debhelper && cd debhelper
 # or another package of choice
 $ debputy tool-support annotate-debian-directory
{
"result": [
{
"path": "debian/changelog",
"binary-package": "debhelper",
"file-categories": [
"ppf-file"
],
"documentation-uris": [
"man:dh_installchangelogs(1)"
]
},
{
"path": "debian/copyright",
"binary-package": "debhelper",
"install-path": "/usr/share/doc/debhelper/copyright",
"install-pattern": "usr/share/doc/{owning_package}/copyright",
"file-categories": [
"ppf-file"
],
"documentation-uris": [
"man:dh_installdocs(1)"
]
},
{
"path": "debian/debhelper.docs",
"binary-package": "debhelper",
"install-path": "/usr/share/doc/debhelper",
"config-features": [
"dh-docs-only",
"dh-dollar-subst",
"dh-executable-config",
"dh-filearray",
"dh-install-list-fixed-dest-dir"
],
"install-pattern": "usr/share/doc/{owning_package}",
"file-categories": [
"pkg-helper-config"
],
"documentation-uris": [
"man:dh_installdocs(1)"
]
},
[...]
{
"path": "debian/debhelper.install",
"binary-package": "debhelper",
"config-features": [
"dh-dollar-subst",
"dh-executable-config",
"dh-filedoublearray",
"dh-glob-after-execute",
"dh-install-list-dest-dir-like-dh_install",
"dh-late-glob",
"dh-partial-glob",
"dh-exec-rename"
],
"file-categories": [
"pkg-helper-config"
],
"documentation-uris": [
"man:dh_install(1)"
]
},
[...]
],
"reference-datasets": [
"config-features",
"file-categories"
]
}
   # Reference data accessible as JSON via:
   $ debputy tool-support export-reference-data --output-format=json
   # or in terminal as ASCII art text:
   $ debputy tool-support export-reference-data config-features

The output works the "same" whether the package is built using `dh` or 
`debputy`. For many files, they will only be tagged if the relevant 
helper is active (only applies to dynamically resolved files, static 
files like `debian/debputy.manifest` is always tagged even though 
debputy is not used).  Output for classic debhelper or helper-less 
packages is ... not tested at all and probably not helpful. For classic 
debhelper, I support it will be okayish but not fully aligned with the 
tools used in d/rules. For helper-less, you will probably not get a lot 
of useful output.


With this output, you will get insights into:

 1) Which files in debian is or might be picked up by some tool. It also
lists (to the Janitor) irrelevant files, because the underlying code
can also be used find documentation for known packaging files.

 2) Where a file like debian/pam is installed in the package, `debputy`
will attempt to provide you resolve the path for you assuming it was
given a pattern for it in the `install-path` attribute. Note
especially debian/pam is exciting because the path changes in compat
13 and I think you will like this one. These are tagged with
`ppf-file`

 3) With files debian/docs, `debputy` will provide you with the dest
directory for the file (usr/share/doc/) via the
`install-path`. Additionally, the `config-features` will enumerate
known tags for the file. The description for these tags are in the
reference data ("config-features").

 4) Some files will appear multiple times if they are processed multiple
times (such as, debian/changelog, which will be installed once per
package).

 5) `debputy` will resolve *obvious* uses of `dh $@ --with foo` for you.
Sequences in Build-Depends will also be resolved. Sequences not
installed will work but cause reduced data availability and an
"issues" section in the json file (which in some cases will tell you
which sequences are missing, so you can install them and re-run the
tool).

The [debhelper-documentation plugin] is probably the most interesting 
source of data for you. Most likely, it 

Bug#1001105: can I help with pyvista packaging?

[Francesco Ballarin]

A first version is available at
https://salsa.debian.org/science-team/python-pyvista
in case you want to have a look before I/we change it from UNRELEASED
to unstable.

autopkgtest passes.
test-crossbuild-arm64 is failing, but is allowed to do so, not sure if
it is relevant.

As agreed, interactive plotting within jupyter is not considered for now.

Cheers,
Francesco


On Sat, Jan 27, 2024 at 7:08 PM Andreas Tille  wrote:
>
> Am Sat, Jan 27, 2024 at 06:28:14PM +0100 schrieb Francesco Ballarin:
> > OK Andreas, I'll push to master. Let me take the lead on that, and I'll 
> > come back to you and Drew with progress and questions.
>
> Perfectly fine for me.
>
> > I think I have some ideas on how to get started on the basic package.
> >
> > The full package (i.e., all optional components that one can install with 
> > "pip install pyvista[all]") will be much more complex, because it depends 
> > on trame, which comes split in five interdependent packages
> > 
> > trame3.2.4
> > trame-client 2.11.2
> > trame-server 2.11.7
> > trame-vtk2.5.8
> > trame-vuetify2.3.1
> > 
> > and who knows how many dependencies each one of those have.
>
> Sounds complex and I'd love to stay in background given that I need to
> care for >1000 packages.
>
> > Down the line I'd want to have that too, because that's what I actually 
> > need for plotting within jupyter notebooks in my libraries, see for instance
> > https://viskex.github.io/tutorials/01_introduction/tutorial_plot_subdomains_3d_dolfinx.html
> > but let's start with a less ambitious goal ;)
>
> +1
>
> > I think that the error you see is because python3-vtk9 is only built for 
> > python 3.11, but unit tests are getting run with python 3.12.
> > At the moment, I'd like to disable that part adding an empty 
> > override_dh_auto_test-indep and run tests with autopkgtest only, so that I 
> > can have a clearer idea on the difference between dependencies required for 
> > building the package vs dependencies required for testing it, because I 
> > know from experience that there are a few packages that are only needed for 
> > testing pyvista.
>
> Perfectly fine for me.  Feel free to turn the RFP in ITP and I can
> sponsor the upload if needed.
>
> Thanks a lot for your help
> Andreas.
>
> --
> http://fam-tille.de
[http://static.unicatt.it/ext-portale/5xmille_firma_mail_2023.jpg] 

Bug#1031267: debmany: shell injection

[Jakub Wilk]

Possible alternative approach: if the path contains any suspicious 
characters, create a temporary symlink with a safe name, and pass that 
symlink to eval instead.


I'm not sure it's a _better_ approach, but maybe worth considering.

(I stole the idea from run-mailcap(1).)

* Axel Beckert , 2023-02-19 05:47:
So I came up with the following fix which uses command instead of eval, 
and bash pattern substitution to replace %s with the file name instead 
letting printf inside an $() doing the substitution:


I fear that someone might be using -m or -o with shell constructs that 
this change will break. Maybe it's a good tradeoff, but it should be 
documented.



+  cmdarr=($@)


You should disable glob expansion here.


+  for i in ${!cmdarr[@]}; do
+cmdarr[$i]="${cmdarr[$i]/\%s/$replacement}"
+  done


You should either replace all %s occurrences, or just the first one. The 
above code sits oddly in the middle: it replaces the first occurrence in 
every argument.



-  eval $(printf "gzip -dc $PWD/$return | $othercmdline")
+  gzip -dc "$PWD/$return" | replace_percent_s_and_execute '-' 
"$othercmdline"


Passing "-" instead of skipping the argument is another potential 
incompatibility. 


--
Jakub Wilk

Bug#1061644: octave-dev: The package should include an ld.so.conf fragment pointing to the shared libraries

[Antony Donovan]

Package: octave-dev
Version: 7.3.0-2
Severity: normal
Tags: patch

Dear Maintainer,

I installed octave-dev and after building a standalone executable with
mkoctfile it failed to run.

I realized that what was needed was an ld.so.conf fragment containing
the directory where the shared libraries were located.

I created that fragment, with the contents
/usr/lib/x86_64-linux-gnu/octave/7.3.0, named it octave-dev.conf,
put that file in /etc/ld.so.conf.d, and ran ldconfig.

This fixed the issue of running the standalone octave executable.


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

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

Versions of packages octave-dev depends on:
ii  g++   4:12.2.0-3
ii  gcc   4:12.2.0-3
ii  gfortran  4:12.2.0-3
ii  libblas-dev [libblas.so]  3.11.0-2
ii  libc6 2.36-9+deb12u3
ii  libfftw3-dev  3.3.10-1
ii  libgcc-s1 12.2.0-14
ii  libgl-dev 1.6.0-1
ii  libgl1-mesa-dev   22.3.6-1+deb12u1
ii  libhdf5-dev   1.10.8+repack1-1
ii  liblapack-dev [liblapack.so]  3.11.0-2
ii  libncurses-dev [libncurses5-dev]  6.4-4
ii  libreadline-dev   8.2-1.3
ii  libstdc++612.2.0-14
ii  octave7.3.0-2

octave-dev recommends no packages.

octave-dev suggests no packages.

-- no debconf information

Bug#1061622: Some e-mail attachments are invisible

[BohwaZ]

Thank you, from previous discussion it was my understanding that
upstream didn't want to fix this issue, I asked again, just to be
sure.

This issue comes back biting us every single month, it's very annoying to users.


On Sat, 27 Jan 2024 at 20:49, Guilhem Moulin  wrote:
>
> Control: reassign -1 roundcube-core 1.6.6+dfsg-1
> Control: forwarded -1 https://github.com/roundcube/roundcubemail/issues/5051
> Control: tag -1 upstream
>
> On Sat, 27 Jan 2024 at 15:38:43 +0100, BohwaZ wrote:
> > I am suggesting this patch here as upstream doesn't want to fix
> > this longstanding issue:
> > https://github.com/roundcube/roundcubemail/pull/9150
>
> Upstream has given a rationale for not accepting that PR, but that
> doesn't mean they're not interested in fixing the issue in the first
> place (I note that issue 5051 is still open).
>
> Not keen to maintain such a patch though in Debian, but leaving this bug
> open to track its status upstream (via forwarded URL).
>
> --
> Guilhem.



-- 
 bohwaZ
 http://bohwaz.net/

Bug#1057509: jcabi-log: FTBFS with default Java 21

[tony mancill]

On Thu, Jan 25, 2024 at 02:19:34PM +1300, Vladimir Petko wrote:
> The issue is no longer reproducible when built against lombok 1.18.24-2

The updated lombok package has been uploaded with your patch.
Thank you for contributing to Debian!

Bug#1061643: debmany -x: can't show compressed files in /usr/share/doc

[Jakub Wilk]

Package: debian-goodies
Version: 0.88.1
Severity: minor

If you use the -x option, debmany cannot show compressed files in 
/usr/share/doc: it tries to run xdg-run without arguments, which doesn't 
work.


I guess -k might have the same problem.

--
Jakub Wilk

Bug#1061642: make-dfsg: README file refers to nonexistent files

[Thure Duehrsen]

Source: make-dfsg
Version: 4.3
Severity: minor
Tags: upstream
X-Debbugs-Cc: t.duehr...@gmx.net

Dear Maintainer,

After browsing to the source package `make-dfsg' for the `make' binary
package,

https://packages.debian.org/source/sid/make-dfsg

and unpacking the amd64 version of

   .../debian/pool/main/m/make-dfsg/make-dfsg_4.3.orig.tar.gz,

(which applies to both bookworm and sid), the README file, in lines 13
and 17, refers to the file `INSTALL', which does not exist in the
source tree.

The same file, in lines 10 and 101, refers to the file `README.git',
which does not exist in the source tree either.


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

Kernel: Linux 6.1.0-17-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: 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

Bug#1061641: debmany: -k, -x underdocumented

[Jakub Wilk]

Package: debian-goodies
Version: 0.88.1
Severity: minor

The man page says -x is shorthand for "-m 'xdg-open man:%s'", but in 
reality is also sets viewer for other files.


The -k option has the same issue.

--
Jakub Wilk

Bug#1054086: lsm: let dh_installsystemd choose the location of units

[Lucas Castro]

Em 24/01/2024 03:22, Helmut Grohne escreveu:

On Tue, Jan 23, 2024 at 05:25:21PM -0300, Lucas Castro wrote:

dh_installsystemd look only for maintainer scripts. That means it looks only
for scripts residing in debian/ folder.

I guess you should know about that, therefore you propose to create a
symlink from systemd file provided by upstream.

That's not the reason for proposing the change. The reason is that we
need to move the units from /lib/systemd/system to
/usr/lib/systemd/system in trixie but not bookworm. Encoding this in a
debian/*.install file is not simple, but we updated dh_installsystemd to
do exactly that.


systemd file .service will be moved to the /usr/lib/systemd/system 
folder and close this bug.






Sorry, I'm not going to apply the solution proposed on the next release, but
I take a look what it should be the best approach for this.

I do not insist on using my approach. It merely is the one I considered
most suitable at the time of submitting the bug. Alternatively, you may
employ dh_movetousr or update the location in debian/lsm.install (though
extra work is required in case of backporting for the last option). The
point of this bug is to not ship aliased locations such as /lib.

Helmut



OpenPGP_0x42F79A5E0A4D5598.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061640: please use recommends instead of depends for meta packages

[Matthias Klose]

Package: src:forensics-all
Version: 3.47
Severity: important
Tags: sid trixie

please use recommends instead of depends for meta packages.

There is no need to have dependencies instead of recommendations.

Bug#1061639: FTBFS on riscv64: tries to uses rdcycle, privileged since kernel 6.6

[Aurelien Jarno]

Source: gromacs
Version: 2023.3-1
Severity: important
Tags: ftbfs patch upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear maintainer,

Since the build daemons have been upgraded to kernel 6.6, gromacs FTBFS
with SIGILL in the testsuite:

| 69% tests passed, 26 tests failed out of 83
| 
| Label Time Summary:
| GTest  = 156.25 sec*proc (81 tests)
| IntegrationTest=  44.87 sec*proc (25 tests)
| MpiTest=  21.70 sec*proc (19 tests)
| QuickGpuTest   =  25.14 sec*proc (17 tests)
| SlowGpuTest=  26.10 sec*proc (14 tests)
| SlowTest   =  99.77 sec*proc (13 tests)
| UnitTest   =  11.62 sec*proc (43 tests)
| 
| Total Test time (real) = 156.87 sec
| 
| The following tests FAILED:
| 1 - GmxapiExternalInterfaceTests (ILLEGAL)
| 4 - NbLibSamplesTestArgon (ILLEGAL)
| 5 - NbLibSamplesTestMethaneWater (ILLEGAL)
| 8 - NbLibTprTests (ILLEGAL)
| 9 - NbLibIntegrationTests (ILLEGAL)
|42 - GmxTimingTests (ILLEGAL)
|60 - MdrunOutputTests (ILLEGAL)
|61 - MdrunModulesTests (ILLEGAL)
|62 - MdrunIOTests (ILLEGAL)
|63 - MdrunTestsOneRank (ILLEGAL)
|64 - MdrunTestsTwoRanks (ILLEGAL)
|65 - MdrunSingleRankAlgorithmsTests (ILLEGAL)
|66 - MdrunNonIntegratorTests (ILLEGAL)
|67 - MdrunTpiTests (ILLEGAL)
|68 - MdrunMpiTests (ILLEGAL)
|72 - MdrunMpi1RankPmeTests (ILLEGAL)
|73 - MdrunMpi2RankPmeTests (ILLEGAL)
|74 - MdrunCoordinationBasicTests1Rank (ILLEGAL)
|75 - MdrunCoordinationBasicTests2Ranks (ILLEGAL)
|76 - MdrunCoordinationCouplingTests1Rank (ILLEGAL)
|77 - MdrunCoordinationCouplingTests2Ranks (ILLEGAL)
|78 - MdrunCoordinationConstraintsTests1Rank (ILLEGAL)
|79 - MdrunCoordinationConstraintsTests2Ranks (ILLEGAL)
|80 - MdrunFEPTests (ILLEGAL)
|81 - MdrunPullTests (ILLEGAL)
|83 - MdrunVirtualSiteTests (ILLEGAL)
| Errors while running CTest
| make: *** [debian/rules:113: build-basic] Error 8
| dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

A full build log is available here:
https://buildd.debian.org/status/fetch.php?pkg=gromacs=riscv64=2023.3-1%2Bb1=1706327375=0

This happens because the rdcycle instruction has been changed to a
privileged instruction starting with this kernel version.

A patch to fix the issue has been submitted upstream [1]. Would it be
possible to include it in the next upload?

Thanks
Aurelien

[1] https://gitlab.com/gromacs/gromacs/-/merge_requests/4040

Bug#1061622: Some e-mail attachments are invisible

[Guilhem Moulin]

Control: reassign -1 roundcube-core 1.6.6+dfsg-1
Control: forwarded -1 https://github.com/roundcube/roundcubemail/issues/5051
Control: tag -1 upstream

On Sat, 27 Jan 2024 at 15:38:43 +0100, BohwaZ wrote:
> I am suggesting this patch here as upstream doesn't want to fix
> this longstanding issue:
> https://github.com/roundcube/roundcubemail/pull/9150

Upstream has given a rationale for not accepting that PR, but that
doesn't mean they're not interested in fixing the issue in the first
place (I note that issue 5051 is still open).

Not keen to maintain such a patch though in Debian, but leaving this bug
open to track its status upstream (via forwarded URL).

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1061547: freeipmi: ipmi-sensors - internal IPMI error with kcs driver

[Fabio Fantoni]

unfortunately at the moment there is a regression related to those 2 
functions which has caused the build to fail in almost all architectures


https://buildd.debian.org/status/package.php?p=freeipmi=sid

I also reported upstream:

https://github.com/chu11/freeipmi-mirror/issues/70

I tried to do some quick revert tests but unfortunately at the moment I 
didn't succeed and I don't have enough time to prepare a sufficiently 
updated Debian on my raspberry (for reproduce the issue) to continue 
with the tests


any help is welcome



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061605: scipy: tests skipped during build and autopkgtest not in sync

[Drew Parsons]

Source: scipy
Followup-For: Bug #1061605

Easy enough to relax tolerances or skip tests if we needed to.
test_maxiter_worsening was giving problems on other arches.

But strange the test only started failing when pythran was deactivated.
I've reactivated it in 1.10.1-8, we'll see if it restores success.

Bug#1024830: ERROR: Unable to connect to servers to test latency.

[Peter Wienemann]

Hi,

speedtest-cli 2.1.3-2 works for me on Bookworm.

Best regards,

Peter

Bug#1061638: rust-colored: please update to v2.0.4

[Jonas Smedegaard]

Source: rust-colored
Version: 2.0.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to at least v2.0.4.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmW1VusACgkQLHwxRsGg
ASHV3Q//TNSJT9cAzDp5bn5cZ2n2dv7o4Mopm3whQZhuAaMPdWi1fKjde39T+F8U
dQFq/qq+WNla8NpCif26XpAY1ov0Zx0C7XXsLwFW9aAwvhbUPMlcMWFkOfhxkOnv
V4oNL975Ue907tC4mq2X4/xYS5+wzyGBHrBLst5C4HvEeYuDzxyccjxCydY37Jyu
css33PVFpdBbz7G6QBw8K6LkUhbry7cqTc1Qnou77SZfgX5koPw3ACNYeORFyfoY
H6fhlcGXbMaKyYSnoodShlZMl4qh3xY2VN3wutUfcdz7KRnwjiyvZX2b53iYs+m4
rCNfTScUgeOIpqIjBGgxhQ9+S7RdsvM18aOEN+436+tMxgVEMcQVgltrW588xOOs
OA+yH/aGgwlOrO1QjtpDFl510HbbipCvuJdacZfik1S8N9n2JmIwE7jFVbXuxO+z
9CLKFbmUZvcItHOcKqghvajjizYJXXo7WVXctF5b2erT6ObSqM0dyQuMsqLj58Ry
zhI+0mkgwm7gtgjoVoYJP09VNLLiWuphpHemv4RPGar2iEmgBu8ja3r1IUU0RQLp
rYoIBZyJ/GoVnftcEBtuqfY1mTt+EHRCp52iTxJ0r8TulK8lPZ1vN0d0L+CYFtKM
OO6xlnKVy9UFprvvPPEpbP9EhJRDqVl0ud10R/DxIAskTr0nCDU=
=h4T7
-END PGP SIGNATURE-

Bug#772523: preseeding get_domain using DHCP is broken

[Raphaël Halimi]

(sorry, accidental Ctrl+Enter...)

With Bookworm, it totally broke.

If the preseeding happens after netcfg (url=...), when setting the 
hostname from the kernel parameters, d-i keeps it, but does not get the 
domain from DHCP as before; only setting both a hostname and a domain 
name makes things work (but now keeps the domain from the kernel 
parameters, which may be more appropriate).


If the preseeding happens before netcfg (file=...), whatever hostname 
and/or domain is set in the kernel paramaters, and whatever domain the 
DHCP sends, d-i uses the values from the preseed file 
(unassigned-hostname and unassigned-domain).


So, currently, the only way to make things work with an installation 
medium, is to unset both netcfg/get_hostname and netcfg/get_domain in 
the preseed file, and set hostname and domain in the kernel parameters.


(for convenience, I attached a text file in markdown format with the 
results of these tests).


This is a big change from the behavior of previous netcfg versions (I 
use preseeding since Wheezy, both with PXE or installation media), and 
this new behavior makes things more complicated: before, we just 
configured bogus values in the preseed file, and if the machine was not 
registered in the DNS but the DHCP provided a valid domain name, 
specifying a hostname in the kernel parameters was sufficient. Now, we 
have to specify both the hostname and the domain name in the kernel 
command line (think of non-QWERTY keyboards...), and this makes me 
consider this a severe regression.


It also partly contradicts the various documentations (like the ones 
mentioned above).


I sincerely hope this will be fixed in a forthcoming point release.

Feel free to ask me if you need to test stuff, I have a suitable 
environment to test preseeding for both PXE or installation media.


Best regards,

--
Raphaël HalimiBullseye


netcfg before preseed (url=...)


### cmdline: none
hostname=debian, no domain name

### cmdline: hostname=
hostname from cmdline, domain from DHCP

### cmdline: hostname=, domain=
hostname from cmdline, domain from DHCP (different from cmdline)

preseed before netcfg (file=...)


### cmdline: none
hostname and domain from preseed file (unassigned-hostname, unassigned-domain)

### cmdline: hostname=
hostname from cmdline, domain from DHCP

### cmdline: hostname=, domain=
hostname from cmdline, domain from DHCP (different from cmdline)

Bookworm


netcfg before preseed (url=...)


### cmdline: none
hostname=debian, no domain name

### cmdline: hostname=
hostname from cmdline, no domain

### cmdline: hostname=, domain=
hostname and domain from cmdline

preseed before netcfg (file=...)


### cmdline: none
hostname and domain from preseed file (unassigned-hostname, unassigned-domain)

### cmdline: hostname=
hostname and domain from preseed file (unassigned-hostname, unassigned-domain)

### cmdline: hostname=, domain=
hostname and domain from preseed file (unassigned-hostname, unassigned-domain)

Bug#1061637: RFP: jami-greenscreen-plugin -- a greenscrenn plugin for jami

[Matthias Geiger]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: band...@gnu.org, werdah...@riseup.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: jami-greenscreen-plugin
  Version : ???
  Upstream Contact: Savoir-faire Linux
* URL : 
https://review.jami.net/plugins/gitiles/jami-plugins/+/refs/heads/master
* License : GPL-3
  Programming Lang: C++
  Description : a greenscreen plugin for jami

This plugin provides a greenscreen plugin for Jami to blur the
background. It would be nice to have in Debian. Imho the source package
should be called jami-plugins since the source contains other plugins,
too.

best,

werdahias

-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmW1UCIVHHdlcmRhaGlh
c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1AdcP/ROPL+MVuCfJsRvCqu2CC/zfOw8V
dwCKUvSIry+zd07uDj181/CilIWTXdIr30NzBx3boFAtxxX5PtrPclW6hpaUJ5YK
1mSSRQzmcQAy+S3ZqE9J/pdpvdFXGq4VTHlaadFucQY80kfk9MQmt7WlEDtZTTIe
GA5DKY7ISPegdtFPwNmq7WzVlo/SGxKPCINWh+847JgZiAG/ebSVd2oYnJxzXXWY
Y47pe458cDGq5ZG1fOH+8PILbAbJCeaQeSWkKtkqnJZHQHACEWrcjOwaYeC3OZt/
urBLbgWDGJ0Z+zx1ikzvrXFfw1qsq3COpmFeye6nK9sULPSrgID9WC8JL9e6EmEM
8xZBmJhijyjTNWmMP0VQyD1gYkUKOiWVbK1meCt0cglk4sB2e2S3BfjcX6C8kEB3
OPiDPIls5C93cIuupOQDzZR1TDAJD6n2U0Ixyb087hOR9UuGA1HMkPbYIliHS1YG
hY15I93wKSJKrOQS1tBwdUvhXj/XJakQfI8B6CWnh5mrFbbkBvXN856pTlOLNUec
e6IbhqEfIrvWdUyO2YcSUcUYcGNCkeKDCloUe4XTd+6Y0JApq0WPL9tfSdKYcDf/
5xZv6WDRHZ81VwxPP9wRsrwnLQa5jgqdmNVFiKUYUSVbgnqSphztLTYqrMYtkbRa
WcxKFd4GarjjdFO3
=iSCg
-END PGP SIGNATURE-

Bug#1061636: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli (wintermute)]

Package: mmdebstrap
Version: 1.4.1-1
Severity: normal

Hello again Johannes!

As I said in bug report [#1061634], I've been able to create a QEMU/KVM
virtual machine image for autopkgtests:

  $ mkdir -p ~/var/cache/sbuild/
  $ cd /dev/shm
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--size=25G --boot=efi sid sid-amd64.img
  $ chmod 660 sid-amd64.img
  $ mv -i sid-amd64.img ~/var/cache/sbuild/

[#1061634]: 

It works for autopkgtests, but I wanted to use the same virtual machine
image to build Debian packages with sbuild-qemu.
The first thing I tested is the update of the VM image with
sbuild-qemu-update:

  $ sbuild-qemu-update --arch=amd64 sid-amd64.img
  qemu-system-x86_64 -enable-kvm -object 
rng-random,filename=/dev/urandom,id=rng0 -device 
virtio-rng-pci,rng=rng0,id=rng-device0 -device virtio-serial -nic 
user,model=virtio -m 1024 -smp 1 -nographic sid-amd64.img

This command does not seem to work: it uses 100 % of one CPU core and
seemingly does nothing, until I interrupt it by pressing [Ctrl+C].

Is there any special tweak or configuration needed to use
sbuild-qemu-update with mmdebstrap-autopkgtest-build-qemu VM images?
Where is this documented?

Otherwise, if this is an actual bug, please fix
mmdebstrap-autopkgtest-build-qemu
or help sbuild-qemu developers to fix sbuild-qemu-update.

Thanks for your time and dedication!



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

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

Versions of packages mmdebstrap depends on:
ii  apt  2.7.10
ii  perl 5.38.2-3
ii  python3  3.11.6-1

Versions of packages mmdebstrap recommends:
ii  arch-test0.21-1
ii  fakechroot   2.20.1+ds-15
ii  fakeroot 1.33-1
ii  gpg  2.2.40-1.1+b1
ii  libdistro-info-perl  1.7
ii  libdpkg-perl 1.22.2
ii  mount2.39.3-6
ii  uidmap   1:4.13+dfsg1-3+b1

Versions of packages mmdebstrap suggests:
pn  apt-transport-tor  
ii  apt-utils  2.7.10
ii  ca-certificates20230311
ii  debootstrap1.0.134
ii  distro-info-data   0.60
ii  dpkg-dev   1.22.2
pn  genext2fs  
ii  perl-doc   5.38.2-3
pn  qemu-user  
pn  qemu-user-static   
pn  squashfs-tools-ng  
ii  systemd255.2-4

-- no debconf information

Bug#772523: preseeding get_domain using DHCP is broken

[Raph]

Dear developers,

I confirm that something broke between Bullseye and Bookworm (IIRC it 
worked even with Bookworm RC2) regarding netcfg's behavior when the 
host's IP address can't be found in the DNS.


I also think it's a different bug from the one originally reported 
(which were for Jessie). Maybe a new one should be created for this big 
regression in Bookworm.


The behavior also changes according to when the preseeding happens: 
before netcfg (when installation is performed from an installation media 
and the preseed file is specified with kernel parameter file=...) or 
after netcfg (when installation is performed from a PXE server and the 
preseed file is specified with kernel parameter url=...).


Note that when IP address (assigned by DHCP) is found in the DNS, 
everything works as before, whether netcfg is performed before or after 
the preseeding.


I performed a number of tests with a VM and the IP address missing from 
the DNS, and the preseed file containing "d-i netcfg/get_hostname string 
unassigned-hostname" and "d-i netcfg/get_domain string 
unassigned-domain" (as suggested in [1]).


[1] https://www.debian.org/releases/bookworm/example-preseed.txt

With Bullseye, if the preseeding happens after netcfg (url=...), without 
hostname or domain kernel parameters, d-i chooses "debian" as hostname 
and sets no domain name. With a hostname set in kernel parameters, d-i 
keeps it and sets the domain name from DHCP. With both hostname and 
domain set in kernel parameters, d-i keeps the hostname, but still sets 
the domain name from DHCP, ignoring the one provided in kernel parameters.


If the preseeding happens before netcfg (file=...), without hostname or 
domain kernel parameters, d-i uses the ones from the preseed file 
(unassigned-hostname and unassigned-domain). When hostname or hostname 
and domain are specified in kernel parameters, it behaves as above 
(hostname from kernel parameters and domain from DHCP).


This behavior is consistent with the aforementioned example preseed 
file, and also with documentation in [2] (and particularly B.2.3, "Auto 
mode").


[2] https://www.debian.org/releases/stable/i386/apbs02.en.html

With Bookworm, everything











--
Raph

Bug#1056770: braillefont: Description in debian/control has a new line in the middle of a sentence

[Judit Foglszinger]

s/liik/look (:


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

Bug#1061635: bind9: Missing version dependency on libuv1

[Greg Alexander]

Subject: Missing version dependency on libuv1
Package: bind9
X-Debbugs-Cc: d...@galexander.org
Version: 1:9.19.19-1
Severity: normal

I used "apt install" to upgrade bind9:amd64 to version 1:9.19.19-1.
apt failed and then I got this error from everything bind-related, such
as dig in bind9-dnsutils:

   # dig deb.devuan.org @192.168.100.254
   netmgr/netmgr.c:167:isc_netmgr_create(): fatal error: libuv version
   too old: running with libuv 1.40.0 when compiled with libuv 1.46.0
   will lead to libuv failures
   Aborted

I had libuv1:amd64 version 1.40.0-1.  I was eventually able to upgrade
libuv1 to version 1.46.0-3, and that resolved my problems.

I think the correct resolution would be to change the dependency in the
bind9-libs manifest file.  bind9-libs currently depends on:

   Depends: ..., libuv1 (>= 1.38.0), ...

It should probably be changed to

   Depends: ..., libuv1 (>= 1.46.0), ...

Thanks!!!
- Greg


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux ascii
Release:9
Codename:   n/a
Architecture: x86_64

Kernel: Linux 5.10.104 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages bind9-dnsutils depends on:
ii  bind9-host [host]  1:9.19.19-1
ii  bind9-libs 1:9.19.19-1
ii  libc6  2.37-12
ii  libedit2   3.1-20181209-1
ii  libidn2-0  2.0.5-1
ii  libkrb5-3  1.20.1-2
ii  libprotobuf-c1 1.3.1-1+b1

bind9-dnsutils recommends no packages.

bind9-dnsutils suggests no packages.

-- no debconf information
Report will be sent to Debian Bug Tracking System 

Bug#1056770: braillefont: Description in debian/control has a new line in the middle of a sentence

[Judit Foglszinger]

Hi,

did reformat the long description - the newline ended up at the same position 
of the sentence as before,
but I think, it should liik more sane now -

 braillefont runs interactively on the console -
 one can enter a (short) text, that will be converted into a bitmapped version
 and printed using the Braille range of Unicode.   

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

Bug#1061634: mmdebstrap: possible mmdebstrap-autopkgtest-build-qemu improvements

[Francesco Poli (wintermute)]

Package: mmdebstrap
Version: 1.4.1-1
Severity: normal

Hello Johannes!

I've been able to create a QEMU/KVM virtual machine image for autopkgtests:

  $ mkdir -p ~/var/cache/sbuild/
  $ cd /dev/shm
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--size=25G --boot=efi sid sid-amd64.img
  $ chmod 660 sid-amd64.img
  $ mv -i sid-amd64.img ~/var/cache/sbuild/

It is able to run autopkgtests:

  $ autopkgtest --output-dir ./${SRCPKG}_autopkgtest.out \
--summary./${SRCPKG}_autopkgtest.summary \
--apt-upgrade -B ./${SRCPKG}_amd64.changes -- \
qemu --boot=efi --overlay-dir /dev/shm \
~/var/cache/sbuild/sid-amd64.img

My comments / suggestions for improvements:

  * I had to manually fix the permissions, since the image file was
originally created with the following weird ones:

  $ ls -l --si sid-amd64.img 
  -rw-r-xrwx 1 $USER $USER 27G Jan 27 17:48 sid-amd64.img

I think the file permissions should be set (possibly at the end of the
mmdebstrap-autopkgtest-build-qemu run) as they would "naturally"
result from the user's umask:

  $ cd /dev/shm
  $ touch foo
  $ ls -l --si foo 
  -rw-rw 1 $USER $USER 0 Jan 27 19:00 foo

That's why I manually changed the permissions at the end:

  $ chmod 660 sid-amd64.img
  $ ls -l --si sid_amd64.img
  -rw-rw 1 $USER $USER 27G Jan 27 17:48 sid-amd64.img

I suggest that mmdebstrap-autopkgtest-build-qemu applies this fix
automatically.

  * I was surprised to see a 25 GiB image fit into a 7.7 GiB filesystem:

  $ cd /dev/shm
  $ ls -l -h sid-amd64.img
  -rw-rw 1 $USER $USER 26G Jan 27 17:48 sid-amd64.img
  $ df -h .
  Filesystem  Size  Used Avail Use% Mounted on
  tmpfs   7.7G  765M  7.0G  10% /dev/shm

Well, the mystery is solved by looking at the allocated size:

  $ ls -l -h -s sid-amd64.img 
  662M -rw-rw 1 $USER $USER 26G Jan 27 17:48 sid-amd64.img

Would it be less confusing, if mmdebstrap-autopkgtest-build-qemu created
.qcow2 images?


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

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

Versions of packages mmdebstrap depends on:
ii  apt  2.7.10
ii  perl 5.38.2-3
ii  python3  3.11.6-1

Versions of packages mmdebstrap recommends:
ii  arch-test0.21-1
ii  fakechroot   2.20.1+ds-15
ii  fakeroot 1.33-1
ii  gpg  2.2.40-1.1+b1
ii  libdistro-info-perl  1.7
ii  libdpkg-perl 1.22.2
ii  mount2.39.3-6
ii  uidmap   1:4.13+dfsg1-3+b1

Versions of packages mmdebstrap suggests:
pn  apt-transport-tor  
ii  apt-utils  2.7.10
ii  ca-certificates20230311
ii  debootstrap1.0.134
ii  distro-info-data   0.60
ii  dpkg-dev   1.22.2
pn  genext2fs  
ii  perl-doc   5.38.2-3
pn  qemu-user  
pn  qemu-user-static   
pn  squashfs-tools-ng  
ii  systemd255.2-4

-- no debconf information

Bug#1020561: python3-scipy: Scipy upgrade requires c++ compiler

[Drew Parsons]

Package: python3-scipy
Followup-For: Bug #1020561

Confirmed that tests still pass (amd64) if python3-pythran is forcibly
not installed.

Making an audit of where pythran is actually used (in v.10),
at runtime that is:

scipy/interpolate
_rbfinterp_pythran.py
see also setup.py, meson.build

scipy/optimize
_group_columns.py
used by ._numdiff.group_columns

scipy/linalg
_matfuncs_sqrtm_triu.py
(not clear that this is used. meson.build refers to the cython variant
_matfuncs_sqrtm_triu.pyx)

scipy/stats
_stats_pythran.py
_hypotests.py
_stats_mstats_common.py

scipy/signal
_spectral.py


The pythran definitions are supplied as
# pythran export ...

So they are enclosed in comments.
If pythran is not present then the definition is handled as a normal
comment, i.e. ignored.

At build time python extensions are built using these definitions via
meson.build
e.g. interpolate/_rbfinterp_pythran.cpython-39-x86_64-linux-gnu.so
But once these a built pythran is not needed to rebuild them.

This does confuse me, I thought the advantage of pythran was a jit
optimisation at runtime. In this case pythran just provides an
automated means of running cython, rather than an optimisation to the
runtime cpu.  Not clear then what the advantage of
optimize/_group_columns.py is over optimize/_group_columns.pyx
Perhaps the pythran variant is better tuned.

So, what is pythran is doing is essentially replacing the .py file
with a .so library.  It's an ahead-of-time compiler, not a
just-in-time compiler.

Conclusion:, we want to use pythran at build time.  But there's no further
reason to depend on it at runtime (not even as Recommends)

Bug#1001105: can I help with pyvista packaging?

[Drew Parsons]

On 2024-01-27 18:28, Francesco Ballarin wrote:

OK Andreas, I'll push to master. Let me take the lead on that, and
I'll come back to you and Drew with progress and questions.

I think I have some ideas on how to get started on the basic package.


Thanks Francesco and Andreas.  Will be interesting to see the dolfinx 
demos running in their full pyvista livery.




The full package (i.e., all optional components that one can install
with "pip install pyvista[all]") will be much more complex, because it
depends on trame, which comes split in five interdependent packages

...

and who knows how many dependencies each one of those have.

...

but let's start with a less ambitious goal ;)


I agree, get the basic functionality in place first :)




I think that the error you see is because python3-vtk9 is only built
for python 3.11, but unit tests are getting run with python 3.12.


This is annoying problem, constrained by cmake limitations.  Other 
packages are also affected, like spglib, which then constrains pymatgen. 
The problem is that cmake does not allow for building python modules 
over multiple python versions.  The FEniCS project has been smarter 
about it, keeping the C++ library and the python module build separate 
(the first using cmake, the latter using setup/pyproject).


Not much we can do about it with vtk9 in the short term. Complaints 
should be pushed to kitware though.
They seem to think it should be done in your source, which is pretty 
weird.

https://gitlab.kitware.com/cmake/cmake/-/issues/21797

Different source dirs makes little sense, but possibly cmake could be 
run multiple times, once for each python, in separate build dirs.

Bug#1001105: can I help with pyvista packaging?

[Andreas Tille]

Am Sat, Jan 27, 2024 at 06:28:14PM +0100 schrieb Francesco Ballarin:
> OK Andreas, I'll push to master. Let me take the lead on that, and I'll come 
> back to you and Drew with progress and questions.

Perfectly fine for me.
 
> I think I have some ideas on how to get started on the basic package.
> 
> The full package (i.e., all optional components that one can install with 
> "pip install pyvista[all]") will be much more complex, because it depends on 
> trame, which comes split in five interdependent packages
> 
> trame3.2.4
> trame-client 2.11.2
> trame-server 2.11.7
> trame-vtk2.5.8
> trame-vuetify2.3.1
> 
> and who knows how many dependencies each one of those have.

Sounds complex and I'd love to stay in background given that I need to
care for >1000 packages.

> Down the line I'd want to have that too, because that's what I actually need 
> for plotting within jupyter notebooks in my libraries, see for instance
> https://viskex.github.io/tutorials/01_introduction/tutorial_plot_subdomains_3d_dolfinx.html
> but let's start with a less ambitious goal ;)

+1
 
> I think that the error you see is because python3-vtk9 is only built for 
> python 3.11, but unit tests are getting run with python 3.12.
> At the moment, I'd like to disable that part adding an empty 
> override_dh_auto_test-indep and run tests with autopkgtest only, so that I 
> can have a clearer idea on the difference between dependencies required for 
> building the package vs dependencies required for testing it, because I know 
> from experience that there are a few packages that are only needed for 
> testing pyvista.

Perfectly fine for me.  Feel free to turn the RFP in ITP and I can
sponsor the upload if needed.

Thanks a lot for your help
Andreas. 

-- 
http://fam-tille.de

Bug#1010220: Reproduced the issue and found a workaround

[will]

I experienced the same symptoms that the original creator of this bug did where 
it would take 30 seconds to start Firefox and waybar (amongst other 
applications) on my Debian 12 installation. I'm currently running:

sway 1.7-6
xdg-desktop-portal 1.16.0-2
xdg-desktop-portal-wlr 0.7.0-1
xdg-desktop-portal-gtk 1.14.1-1

I was able to work around the issue by adding the following lines to the end of 
my ~/.config/sway/config file:

exec "dbus-update-activation-environment --systemd --all "
exec "dbus-update-activation-environment --systemd XDG_CURRENT_DESKTOP=sway "

Hopefully this can help anyone else who stumbles on this bug report. After 
trying a lot of different solutions I stumbled on this one that was helpfully 
suggested on Reddit:

https://www.reddit.com/r/swayvm/comments/14lf3yl/comment/k70hsrl/

Bug#1060275: asterisk: Codec translation notice

[Jonas Smedegaard]

Quoting List Support via Pkg-voip-maintainers (2024-01-27 15:28:06)
> 
> Le 26/01/2024 à 15:47, Jonas Smedegaard a écrit :
> >> That was my interrogation.
> >>
> >> For what I get for information from asterisk developpers, this message
> >> is not an original one so one of the Debian applied patch seems to be
> >> the culpit. On which place can I see all of them to check ? Even if my
> >> knowledge in C is zero, my eyes are OK ;)
> > More eyes are good :-)
> >
> > Patches applied are here:
> > https://salsa.debian.org/pkg-voip-team/asterisk/-/tree/debian/latest/debian/patches
> 
> I went through debian asterisk source file and all patches, nowhere I 
> found nothing like "lost frames(s)". I thought third-party/resample 
> could be the missing part but as I didn´t find reference to it in the 
> stock asterisk source...

That phrase exists in debian/patches/2016_opus_plc.patch which is
derived from Xopus/enable_native_plc.patch which (thanks to
debian/watch) is fetched from original at
https://github.com/traud/asterisk-opus/blob/asterisk-13.7/enable_native_plc.patch


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#1061547: freeipmi: ipmi-sensors - internal IPMI error with kcs driver

[Yannick Martin]

Le 27/01/2024 à 16:44, Fabio Fantoni a écrit :

Il 26/01/2024 09:48, Yannick Martin ha scritto:

Hello,

Since freeipmi-1.6.9, ipmi queries via kcs driver may not work.
I opened an issue on upstream project: 
http://savannah.gnu.org/support/?111010


Is it possible to rebuild bookworm freeipmi packages with this ?

Regards


Thanks for report, for now I uploaded to unstable.

About do a stable proposed update is not easy/fast: 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable


If patch is small and risk of regression is small is possible.

The fix is only this upstream commit 
https://github.com/chu11/freeipmi-mirror/commit/379c8569711d808c3366a99d1dfac5e414858800 
and not other patch need to be applied to bookworm version?




Hello

Yes, only this patch is needed.

Regards

Bug#1042620: New upstream version of flufl.i18n fails its test

[Andreas Tille]

Hi,

I checked some random DPT packages and had a look into flufl.i18n.

Unfortunately the new upstream version fails its test as you can
see in Salsa CI[1].

Any help is welcome
Andreas.


[1] https://salsa.debian.org/python-team/packages/flufl.i18n/-/jobs/5148646

-- 
http://fam-tille.de

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

[Francesco Poli]

On Thu, 25 Jan 2024 13:32:00 +0100 Johannes Schauer Marin Rodrigues wrote:

> Hi Francesco,

Hello Johannes!

> 
> Quoting Johannes Schauer Marin Rodrigues (2024-01-23 08:56:24)
[...]
> > Amongst other improvements, if "$IMAGE" cannot be accessed by the unshared
> > user, it will error out early with a (hopefully) helpful error message.
> 
> this has now been uploaded as mmdebstrap 1.4.1.

Sorry, I haven't got around to testing it before the upload...

I've just tested it, after upgrading to mmdebstrap/1.4.1-1 from Debian
sid.

> Are you satisfied with the resolution?

That's certainly a significant improvement over the previous state of
affairs!

> Do you have other remarks? I'm going to make another bugfix release
> very soon, so if you like some more changes to be included, now is the time to
> speak up. :)

Yes, I have other remarks.   :-)
But maybe I should include them in brand new bug reports...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp3FJnMWKjNt.pgp
Description: PGP signature

Bug#1034327: nmodl: reproducible-builds: Embedded build path in /usr/bin/nmodl

[Nilesh Patra]

On Sat, Jan 27, 2024 at 09:09:12PM +0530, Nilesh Patra wrote:
> > The build path is embedded in /usr/bin/nmodl:
> >
> >  
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/nmodl.html
> >
> >  /build/1st/nmodl-0.5/obj-x86_64-linux-gnu/share/nmodl/nrnunits.lib
> >  vs.
> >  /build/2/nmodl-0.5/2nd/obj-x86_64-linux-gnu/share/nmodl/nrnunits.lib
> 
> Thanks for the patch, I have applied it. can I ask you to forward it upstream 
> as well?

Seems this patch causes the package to FTBFS so I dropped it. However, I see 
salsa CI
as green even w/o this patch so I'm keeping this bug as closed.

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1061630: syntax/deb822sources.vim: keywords may be highlighted incorrectly in file paths

[James Addison]

Followup-For: Bug #1061630
Control: forwarded -1 
https://salsa.debian.org/vim-team/vim-debian/-/merge_requests/15
Control: tags -1 patch

Bug#1061633: libtemplates-parser: autopkgtest needs update for new version of gcc-12

[Paul Gevers]

Source: libtemplates-parser
Version: 23.0.0-3
Severity: serious
X-Debbugs-CC: gcc...@packages.debian.org
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:gcc-12

Dear maintainer(s),

With a recent upload of gcc-12 the autopkgtest of libtemplates-parser 
fails in testing when that autopkgtest is run with the binary packages 
of gcc-12 from unstable. It passes when run with only packages from 
testing. In tabular form:


   passfail
gcc-12 from testing12.3.0-14
libtemplates-parserfrom testing23.0.0-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of gcc-12 to testing 
[1]. Of course, gcc-12 shouldn't just break your autopkgtest (or even 
worse, your package), so please investigate.


If this is a real problem in your package (and not only in your 
autopkgtest), the right binary package(s) from gcc-12 should really add 
a versioned Breaks on the unfixed version of (one of your) package(s). 
Note: the Breaks is nice even if the issue is only in the autopkgtest as 
it helps the migration software to figure out the right versions to 
combine in the tests.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=gcc-12

https://ci.debian.net/data/autopkgtest/testing/amd64/libt/libtemplates-parser/42388674/log.gz

 30s Changing to object directory of "P": 
"/tmp/autopkgtest-lxc.xtf31hge/downtmp/autopkgtest_tmp/"
 30s /usr/bin/gcc-12 -c -x ada -gnatA -gnatec=/tmp/GNAT-TEMP-03.TMP 
-gnatem=/tmp/GNAT-TEMP-04.TMP 
/tmp/autopkgtest-lxc.xtf31hge/downtmp/build.69k/src/docs/src/demo.adb

 30s /usr/libexec/gprbuild/gprbind demo.bexch
 30s /usr/bin/gnatbind -shared -o b__demo.adb 
/tmp/autopkgtest-lxc.xtf31hge/downtmp/autopkgtest_tmp/demo.ali -x 
-F=/tmp/GNAT-TEMP-05.TMP -O=/tmp/GNAT-TEMP-07.TMP
 30s error: "templates_parser_tasking__standard_tasking.adb" must be 
compiled
 30s error: 
("/usr/lib/x86_64-linux-gnu/ada/adalib/templates_parser/templates_parser_tasking__standard_tasking.ali" 
is obsolete and read-only)

 30s gprbind: invocation of gnatbind failed
 30s gprbuild: unable to bind demo.adb
 30s autopkgtest [11:05:41]: test link-with-shared



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061632: lix: new upstream and some other packaging updates

[Patrice Duroux]

Package: lix
Version: 0.9.29-1.1
Severity: wishlist

Dear Maintainer,

You can consider this message:
https://lists.debian.org/debian-devel-games/2024/01/msg00023.html
And use my fork on Salsa to pick whatever may help.

Regards,
Patrice


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

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

Bug#1061631: libgnatcoll: autopkgtest needs update for new version of gcc-12

[Paul Gevers]

Source: libgnatcoll
Version: 23.0.0-3
Severity: serious
X-Debbugs-CC: gcc...@packages.debian.org
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:gcc-12

Dear maintainer(s),

With a recent upload of gcc-12 the autopkgtest of libgnatcoll fails in 
testing when that autopkgtest is run with the binary packages of gcc-12 
from unstable. It passes when run with only packages from testing. In 
tabular form:


   passfail
gcc-12 from testing12.3.0-14
libgnatcollfrom testing23.0.0-3
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of gcc-12 to testing 
[1]. Of course, gcc-12 shouldn't just break your autopkgtest (or even 
worse, your package), so please investigate.


If this is a real problem in your package (and not only in your 
autopkgtest), the right binary package(s) from gcc-12 should really add 
a versioned Breaks on the unfixed version of (one of your) package(s). 
Note: the Breaks is nice even if the issue is only in the autopkgtest as 
it helps the migration software to figure out the right versions to 
combine in the tests.


More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=gcc-12

https://ci.debian.net/data/autopkgtest/testing/amd64/libg/libgnatcoll/42388673/log.gz

 30s Changing to object directory of "proj": 
"/tmp/autopkgtest-lxc.mdq8ugbr/downtmp/autopkgtest_tmp/"
 30s /usr/bin/gcc-12 -c -x ada -gnatA -gnata 
-gnatec=/tmp/GNAT-TEMP-03.TMP -gnatem=/tmp/GNAT-TEMP-04.TMP 
/tmp/autopkgtest-lxc.mdq8ugbr/downtmp/autopkgtest_tmp/exec.adb

 31s /usr/libexec/gprbuild/gprbind exec.bexch
 31s /usr/bin/gnatbind -shared -o b__exec.adb 
/tmp/autopkgtest-lxc.mdq8ugbr/downtmp/autopkgtest_tmp/exec.ali -x 
-F=/tmp/GNAT-TEMP-05.TMP -O=/tmp/GNAT-TEMP-07.TMP

 31s error: "gnatcoll-projects.adb" must be compiled
 31s error: 
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatcoll/gnatcoll-projects.ali" 
is obsolete and read-only)

 31s error: "gnatcoll-projects-krunch.adb" must be compiled
 31s error: 
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatcoll/gnatcoll-projects-krunch.ali" 
is obsolete and read-only)

 31s error: "gnatcoll-projects-normalize.adb" must be compiled
 31s error: 
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatcoll/gnatcoll-projects-normalize.ali" 
is obsolete and read-only)

 31s error: "gpr-tree.adb" must be compiled
 31s error: 
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-tree.ali" is obsolete 
and read-only)

 31s error: "gpr-env.adb" must be compiled
 31s error: ("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-env.ali" 
is obsolete and read-only)

 31s error: "gpr-util.adb" must be compiled
 31s error: 
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-util.ali" is obsolete 
and read-only)

 31s error: "gpr-ali.adb" must be compiled
 31s error: ("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-ali.ali" 
is obsolete and read-only)

 31s error: "gpr-conf.adb" must be compiled
 31s error: 
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-conf.ali" is obsolete 
and read-only)

 31s error: "gpr-nmsc.adb" must be compiled
 31s error: 
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-nmsc.ali" is obsolete 
and read-only)

 31s error: "gpr-part.adb" must be compiled
 31s error: 
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-part.ali" is obsolete 
and read-only)

 31s error: "gpr-dect.adb" must be compiled
 31s error: 
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-dect.ali" is obsolete 
and read-only)

 31s error: "gpr-strt.adb" must be compiled
 31s error: 
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-strt.ali" is obsolete 
and read-only)

 31s error: "gpr-proc.adb" must be compiled
 31s error: 
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-proc.ali" is obsolete 
and read-only)

 31s error: "gpr-knowledge.adb" must be compiled
 31s error: 
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-knowledge.ali" is 
obsolete and read-only)

 31s error: "gpr-sdefault.adb" must be compiled
 31s error: 
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-sdefault.ali" is 
obsolete and read-only)

 31s error: "gpr_build_util.adb" must be compiled
 31s error: 
("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr_build_util.ali" is 
obsolete and read-only)

 31s error: "gpr-pp.adb" must be compiled
 31s error: ("/usr/lib/x86_64-linux-gnu/ada/adalib/gnatprj/gpr-pp.ali" 
is obsolete and read-only)

 31s gprbind: invocation of gnatbind failed
 31s gprbuild: unable to bind exec.adb
 31s autopkgtest [11:05:42]: test projects



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061630: syntax/deb822sources.vim: keywords may be highlighted incorrectly in file paths

[James Addison]

Package: vim-runtime
Version: 2:9.1.0016-1
Severity: minor

Dear Maintainer,

This is a cosmetic issue that affects syntax highlighting of DEB822-format
apt source-list files.

Directory paths within these files can contain substrings that are incorrectly
matched by some of the deb822sources.vim syntax match patterns.

For example:

When 'Signed-By' is set to '/usr/share/keyrings/debian-archive-keyring.gpg',
then the substring 'deb' within 'debian' in the filename gets highlighted as a
keyword.

I've tested a potential fix: adding word-boundary guards ('\<' and '\>') around
each of the keyword matches (such as deb822sourcesType), and will open a merge
request to suggest that.

Note: although I have _not_ been able to replicate this for the single-line
apt sourcelist format (highlighted by the similar debsources.vim syntax file),
where the 'signed-by' option is configured by placing it within square
brackets, it would likely be worth applying pattern edits consistently in both.

Regards,
James A
(the author of the syntax file containing this bug)

Bug#998095: lxc-templates: lxc-create using alpine template fails with mknod error

[Mathias Gibbens]

Control: tags -1 + pending

  Thanks for the report! I've verified the issue, and it will be fixed
in the next upload of lxc-templates.

Mathias


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

Bug#1055869: lxc-templates: need upgrade from upstream for templates issue

[Mathias Gibbens]

Control: tags -1 + pending

  Thanks for the reports! I'm working on packaging the latest snapshot
of lxc-templates, which will fix both issues.

Mathias


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

Bug#1061629: Sort the output of -L

[Mikko Viinamäki]

Package: dlocate
Version: 1.07+nmu1
Severity: wishlist

Is there any reason for the current ordering of the output? If no I think 
sorting it would make alot of sense as currently we dont get the list of all 
files in a folder in one cluster or files in alphabetical order. If there is a 
reason, maybe it could be mentioned on the manual page.

E.g. "dlocate -L ncal" output (on bullseye) looks just ugly and wrong to me, 
note the 3rd binary mentioned close to end and how the ncal man page preceeds the cal man 
page.

/.
/usr
/usr/bin
/usr/bin/ncal
/usr/share
/usr/share/doc
/usr/share/doc/ncal
/usr/share/doc/ncal/NEWS.Debian.gz
/usr/share/doc/ncal/changelog.gz
/usr/share/doc/ncal/copyright
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/ncal.1.gz
/usr/bin/cal
/usr/share/man/man1/cal.1.gz

Bug#1061612: coreutils: cp -n deprecation warning gives questionable advice

[Michael Stone]

On Sat, Jan 27, 2024 at 02:00:14PM +0100, Sven Joachim wrote:

Package: coreutils
Version: 9.4-3+b1

,
| $ cp -n /bin/true tmp
| cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
`

The advice to use the --update=none option is highly questionable,
because this option is even less portable than -n.  It is not available
in coreutils older than 9.3 or in other cp implementations.


There is no alternative that I can see. I didn't create this situation, 
it was created upstream. You can continue to use -n and ignore the 
warning, but in future if debian stops patching -n to behave the way it 
always has in order to match upstream, stuff will break. If debian keeps 
patching -n, then then anything you write in debian will be depending on 
behavior that differs in other distributions and will break everywhere 
else (except older versions of those distributions). It's a mess.


This warning isn't for debian developers of existing packages, because 
debian is maintaining compatibility (at least for now); you'll see a 
warning message but the actual behavior hasn't changed and won't change 
in debian without some coordination with affected packages. But for 
developers with *new* upstream code that uses -n, which behavior does 
the code expect? There are now two answers and *the only solution is to 
not use -n*; it's not possible to simply file bugs with packages and fix 
it once, because this is an ongoing incompatibility. I understand that 
the messages are somewhat obnoxious, but my attempt to address the 
situation upstream instead failed.

Bug#672250:

[Timothy Pearson]

Would it be possible for someone that can reproduce this bug to do the 
following:

 * Install the rss-glx-dbgsym package
 * Provoke the bug
 * Attach gdb to the running process with 'gdb --pid '
 * Grab a backtrace and upload here?

If I can see where the process is stuck I'm willing to take a quick look to see 
if it can be easily fixed.

Thanks!

Bug#1061628: Finnish locale uses w for week, should be v

[Mikko Viinamäki]

Package: ncal
Version: 12.1.7+nmu3

In Finnish locale, if I choose cal-like output and week numbers to be 
displayed, the letter w is used (for week) but instead the letter v (for 
viikko) should be used. I wonder if this string didn't get translated, perhaps 
other (non-English) locales are also affected.

ie. LC_TIME=fi_FI ncal -bw
(needs Finnish locale installed)

Bug#1061627: jpeg-xl: 0.8 failing autopkgtest

[Jeremy Bícha]

Source: jpeg-xl
Version: 0.8.2-1
Severity: serious

jpeg-xl in Experimental has a failing autopkgtest. This will need to
be fixed before it is possible for jpeg-xl 0.8.2 to reach Testing.

Log excerpt
---
Test - Lossless Roundtrip
JPEG XL encoder v0.8.2 [AVX2,SSE4,SSSE3,SSE2]
./lib/extras/dec/color_hints.cc:54: No color_space/icc_pathname given,
assuming sRGB
Read 320x320 image, 1228816 bytes, 814.0 MP/s
Encoding [Modular, lossless, effort: 7],
./lib/jxl/encode.cc:263: Only JXL_BIT_DEPTH_FROM_PIXEL_FORMAT is
implemented for float types.
./lib/jxl/encode.cc:1848: Invalid input bit depth
JxlEncoderAddImageFrame() failed.
EncodeImageJXL() failed.

Full logs
---
https://release.debian.org/britney/pseudo-excuses-experimental.html#jpeg-xl

https://ci.debian.net/packages/j/jpeg-xl/unstable/amd64/

Thank you,
Jeremy Bícha

Bug#1061547: freeipmi: ipmi-sensors - internal IPMI error with kcs driver

[Fabio Fantoni]

Il 26/01/2024 09:48, Yannick Martin ha scritto:

Hello,

Since freeipmi-1.6.9, ipmi queries via kcs driver may not work.
I opened an issue on upstream project: http://savannah.gnu.org/support/?111010

Is it possible to rebuild bookworm freeipmi packages with this ?

Regards


Thanks for report, for now I uploaded to unstable.

About do a stable proposed update is not easy/fast: 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable


If patch is small and risk of regression is small is possible.

The fix is only this upstream commit 
https://github.com/chu11/freeipmi-mirror/commit/379c8569711d808c3366a99d1dfac5e414858800 
and not other patch need to be applied to bookworm version?




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061626: dials: Switch libmsgpack-dev to libmsgpack-cxx-dev

[James McCoy]

Source: dials
Version: 3.17.0+dfsg3-1
Severity: normal
Tags: patch
Control: block 1018679 by -1

Dear maintainer,

libmsgpack-dev's C++ bindings were split out to a separate binary
package -- libmsgpack-cxx-dev -- in 4.1.1-1 to follow upstream's
separation of the project. dials Build-Depends on libmsgpack-dev and
uses the C++ library, so it needs to switch to libmsgpack-cxx-dev.

Cheers, 
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#1061625: bullseye-pu: package postfix/3.5.23-0+deb11u1

[Scott Kitterman]

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

[ Reason ]
This is the next in our normal postfix maintenance releases.  It
consists soley of updates to the SMTP Smuggling processing that were
released near the end of December.  I think it would be better to get
this in now for the next point release so that the fixes that most of
our users see are the final form.

[ Impact ]
Users will have the older version of the SMTP Smuggling fixes which mean
they are unable to sanitize outbound mail and then will have to consider
the inbound processing changes later instead of all at once.

[ Tests ]
The package has a reasonably extensive autopkgtest, although it does not
have specific tests for SMTP Smuggling, it does ensure the changes do
not cause regressions.  The tests pass when run locally.  Additionally,
I have installed the package on one of my servers to verified it is
still working as expected.

[ Risks ]
Risk is negligible.  No changes from the upstream release and upstream
is known to be very careful.  The risk is primarily on not updating as
there are changes (backward compatible, so there's no issue if someone
already dealt with SMTP Smuggling based on the December release) in how
some of the related controls work.  If we don't update, then behavior on
Debian will differ from user expectations.  The alternative would be to
hold this until the next point release, which I don't think would be a
good idea.

[ 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 ]
-  Security (outbound SMTP smuggling): with the default setting
   "cleanup_replace_stray_cr_lf = yes" Postfix will replace
   stray  or  characters in message content with a
   space character. This prevents Postfix from enabling
   outbound (remote) SMTP smuggling, and it also makes evaluation
   of Postfix-added DKIM etc. signatures independent from how
   a remote mail server handles stray  or  characters.
   Files: global/mail_params.h, cleanup/cleanup.c,
   cleanup/cleanup_message.c, mantools/postlink, proto/postconf.proto.
 - Security (inbound SMTP smuggling): with "smtpd_forbid_bare_newline
   = normalize" (default "no" for Postfix < 3.9), the Postfix
   SMTP server requires the standard End-of-DATA sequence
   ., and otherwise allows command or message
   content lines ending in the non-standard , processing
   them as if the client sent the standard .
   The alternative setting, "smtpd_forbid_bare_newline = reject"
   will reject any command or message that contains a bare
   , and is more likely to cause problems with legitimate
   clients.
   For backwards compatibility, local clients are excluded by
   default with "smtpd_forbid_bare_newline_exclusions =
   $mynetworks".
   Files: mantools/postlink, proto/postconf.proto,
   global/mail_params.h, global/smtp_stream.c, global/smtp_stream.h,
   smtpd/smtpd.c, smtpd/smtpd_check.[hc].

[ Other info ]
I do not think an SUA is required for this update.  The capability
provided by the December SUA is sufficient until the next point release.

Scott K
diff -Nru postfix-3.5.23/debian/changelog postfix-3.5.24/debian/changelog
--- postfix-3.5.23/debian/changelog 2023-12-26 16:07:38.0 -0500
+++ postfix-3.5.24/debian/changelog 2024-01-27 10:21:04.0 -0500
@@ -1,3 +1,36 @@
+postfix (3.5.24-0+deb11u1) bullseye; urgency=medium
+
+  [Wietse Venema]
+
+  * 3.5.24
+-  Security (outbound SMTP smuggling): with the default setting
+   "cleanup_replace_stray_cr_lf = yes" Postfix will replace
+   stray  or  characters in message content with a
+   space character. This prevents Postfix from enabling
+   outbound (remote) SMTP smuggling, and it also makes evaluation
+   of Postfix-added DKIM etc. signatures independent from how
+   a remote mail server handles stray  or  characters.
+   Files: global/mail_params.h, cleanup/cleanup.c,
+   cleanup/cleanup_message.c, mantools/postlink, proto/postconf.proto.
+ - Security (inbound SMTP smuggling): with "smtpd_forbid_bare_newline
+   = normalize" (default "no" for Postfix < 3.9), the Postfix
+   SMTP server requires the standard End-of-DATA sequence
+   ., and otherwise allows command or message
+   content lines ending in the non-standard , processing
+   them as if the client sent the standard .
+   The alternative setting, "smtpd_forbid_bare_newline = reject"
+   will reject any command or message that contains a bare
+   , and is more likely to cause problems with legitimate
+   clients.
+   For backwards compatibility, local clients are excluded by
+   default with "smtpd_forbid_bare_newline_exclusions =
+   

Bug#1061624: bookworm-pu: package postfix/3.7.9-0+deb12u1

[Scott Kitterman]

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

[ Reason ]
This is the next in our normal postfix maintenance releases.  It
consists soley of updates to the SMTP Smuggling processing that were
released near the end of December.  I think it would be better to get
this in now for the next point release so that the fixes that most of
our users see are the final form.

[ Impact ]
Users will have the older version of the SMTP Smuggling fixes which mean
they are unable to sanitize outbound mail and then will have to consider
the inbound processing changes later instead of all at once.

[ Tests ]
The package has a reasonably extensive autopkgtest, although it does not
have specific tests for SMTP Smuggling, it does ensure the changes do
not cause regressions.  The tests pass when run locally.  Additionally,
I have installed the package on one of my servers to verified it is
still working as expected.

[ Risks ]
Risk is negligible.  No changes from the upstream release and upstream
is known to be very careful.  The risk is primarily on not updating as
there are changes (backward compatible, so there's no issue if someone
already dealt with SMTP Smuggling based on the December release) in how
some of the related controls work.  If we don't update, then behavior on
Debian will differ from user expectations.  The alternative would be to
hold this until the next point release, which I don't think would be a
good idea.

[ 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 ]
-  Security (outbound SMTP smuggling): with the default setting
   "cleanup_replace_stray_cr_lf = yes" Postfix will replace
   stray  or  characters in message content with a
   space character. This prevents Postfix from enabling
   outbound (remote) SMTP smuggling, and it also makes evaluation
   of Postfix-added DKIM etc. signatures independent from how
   a remote mail server handles stray  or  characters.
   Files: global/mail_params.h, cleanup/cleanup.c,
   cleanup/cleanup_message.c, mantools/postlink, proto/postconf.proto.
 - Security (inbound SMTP smuggling): with "smtpd_forbid_bare_newline
   = normalize" (default "no" for Postfix < 3.9), the Postfix
   SMTP server requires the standard End-of-DATA sequence
   ., and otherwise allows command or message
   content lines ending in the non-standard , processing
   them as if the client sent the standard .
   The alternative setting, "smtpd_forbid_bare_newline = reject"
   will reject any command or message that contains a bare
   , and is more likely to cause problems with legitimate
   clients.
   For backwards compatibility, local clients are excluded by
   default with "smtpd_forbid_bare_newline_exclusions =
   $mynetworks".
   Files: mantools/postlink, proto/postconf.proto,
   global/mail_params.h, global/smtp_stream.c, global/smtp_stream.h,
   smtpd/smtpd.c, smtpd/smtpd_check.[hc].

[ Other info ]
I do not think an SUA is required for this update.  The capability
provided by the December SUA is sufficient until the next point release.

Scott K
diff -Nru postfix-3.7.9/debian/changelog postfix-3.7.10/debian/changelog
--- postfix-3.7.9/debian/changelog  2023-12-24 12:33:24.0 -0500
+++ postfix-3.7.10/debian/changelog 2024-01-26 18:44:58.0 -0500
@@ -1,3 +1,36 @@
+postfix (3.7.10-0+deb12u1) bookworm; urgency=medium
+
+  [Wietse Venema]
+
+  * 3.7.10
+- Security (outbound SMTP smuggling): with the default setting
+  "cleanup_replace_stray_cr_lf = yes" Postfix will replace
+  stray  or  characters in message content with a
+  space character. This prevents Postfix from enabling
+  outbound (remote) SMTP smuggling, and it also makes evaluation
+  of Postfix-added DKIM etc. signatures independent from how
+  a remote mail server handles stray  or  characters.
+  Files: global/mail_params.h, cleanup/cleanup.c,
+  cleanup/cleanup_message.c, mantools/postlink, proto/postconf.proto.
+- Security (inbound SMTP smuggling): with "smtpd_forbid_bare_newline
+  = normalize" (default "no" for Postfix < 3.9), the Postfix
+  SMTP server requires the standard End-of-DATA sequence
+  ., and otherwise allows command or message
+  content lines ending in the non-standard , processing
+  them as if the client sent the standard .
+  The alternative setting, "smtpd_forbid_bare_newline = reject"
+  will reject any command or message that contains a bare
+  , and is more likely to cause problems with legitimate
+  clients.
+  For backwards compatibility, local clients are excluded by
+  default with "smtpd_forbid_bare_newline_exclusions =
+  $mynetworks".
+  

Bug#1034327: nmodl: reproducible-builds: Embedded build path in /usr/bin/nmodl

[Nilesh Patra]

> The build path is embedded in /usr/bin/nmodl:
>
>  
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/nmodl.html
>
>  /build/1st/nmodl-0.5/obj-x86_64-linux-gnu/share/nmodl/nrnunits.lib
>  vs.
>  /build/2/nmodl-0.5/2nd/obj-x86_64-linux-gnu/share/nmodl/nrnunits.lib

Thanks for the patch, I have applied it. can I ask you to forward it upstream 
as well?

Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1061620: autopkgtest: Ignores multiple comma-separated values in Testsuite

[Paul Gevers]

Hi,

On 27-01-2024 15:41, Paul Gevers wrote:
Indeed, autopkgtest doesn't look at d/control at all. Both 
autopkgtest-pkg-python and autopkgtest-pkg-pybuild are things that 
autodep8 deals with and it needs to do the right thing. Reassigning.


This seems to be problematic (note the "^" and "$" in the expression):

detect_by_control_field() {
  local pkgtype="$1"
  [ -f debian/control ] &&
grep-dctrl --quiet \
-F XS-Testsuite,Testsuite \
-r "^autopkgtest-pkg-$packagetype\$" debian/control
}

Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061620: autopkgtest: Ignores multiple comma-separated values in Testsuite

[Paul Gevers]

Control: reassign -1 autodep8

Hi Jérémy,

On 27-01-2024 14:41, Jérémy Lal wrote:

Testsuite: autopkgtest-pkg-python, autopkgtest-pkg-pybuild

tests two different things, and having both is nice.


Ack.


However it seems autopkgtest doesn't consider the field can have multiple 
values,
it only runs one of them - or actually it might fallback to a default test,
because it doesn't recognize the field value.


Indeed, autopkgtest doesn't look at d/control at all. Both 
autopkgtest-pkg-python and autopkgtest-pkg-pybuild are things that 
autodep8 deals with and it needs to do the right thing. Reassigning.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061623: rocblas: Switch libmsgpack-dev to libmsgpack-cxx-dev

[James McCoy]

Source: rocblas
Version: 5.5.1+dfsg-3
Severity: normal
Tags: patch
Control: block 1018679 by -1

Dear maintainer,

libmsgpack-dev's C++ bindings were split out to a separate binary
package -- libmsgpack-cxx-dev -- in 4.1.1-1 to follow upstream's
separation of the project. rocblas Build-Depends on libmsgpack-dev and
uses the C++ library, so it needs to switch to libmsgpack-cxx-dev.

The pending 6.x version of msgpack-cxx (currently in experimental) also
changed the CMake config name to msgpack-cxx.  This has been accounted
for upstream.

I've attached a patch which addresses both of these points.

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

Kernel: Linux 6.6.13-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
diffstat for rocblas-5.5.1+dfsg rocblas-5.5.1+dfsg

 control|2 -
 patches/0020-msgpack-names.patch   |   22 
 patches/0021-msgpack-cxx-support.patch |   35 +
 patches/series |2 +
 5 files changed, 67 insertions(+), 1 deletion(-)

diff -Nru rocblas-5.5.1+dfsg/debian/control rocblas-5.5.1+dfsg/debian/control
--- rocblas-5.5.1+dfsg/debian/control   2023-09-19 04:28:14.0 -0400
+++ rocblas-5.5.1+dfsg/debian/control   2024-01-27 09:04:18.0 -0500
@@ -21,7 +21,7 @@
rocminfo,
patchelf,
rocm-cmake (>= 5.3.0),
-   libmsgpack-dev,
+   libmsgpack-cxx-dev,
libblas-dev,
libgtest-dev
 Build-Depends-Indep: dh-sequence-sphinxdoc ,
diff -Nru rocblas-5.5.1+dfsg/debian/patches/0020-msgpack-names.patch 
rocblas-5.5.1+dfsg/debian/patches/0020-msgpack-names.patch
--- rocblas-5.5.1+dfsg/debian/patches/0020-msgpack-names.patch  1969-12-31 
19:00:00.0 -0500
+++ rocblas-5.5.1+dfsg/debian/patches/0020-msgpack-names.patch  2024-01-27 
09:04:20.0 -0500
@@ -0,0 +1,22 @@
+From c1fa5b358d8cbe601754ef5ea4b695d895a34f62 Mon Sep 17 00:00:00 2001
+From: Torre Zuk <42548444+torre...@users.noreply.github.com>
+Date: Tue, 28 Nov 2023 09:02:43 -0700
+Subject: [PATCH] fix for newer windows vcpkg msgpack (#1827)
+
+---
+ Tensile/Source/lib/CMakeLists.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Tensile/Source/lib/CMakeLists.txt 
b/Tensile/Source/lib/CMakeLists.txt
+index f8cc527c83..d3f4b697fb 100644
+--- a/tensile/Tensile/Source/lib/CMakeLists.txt
 b/tensile/Tensile/Source/lib/CMakeLists.txt
+@@ -98,7 +98,7 @@ if(TENSILE_USE_LLVM OR TENSILE_USE_MSGPACK)
+ endif()
+ 
+ if(TENSILE_USE_MSGPACK)
+-find_package(msgpack REQUIRED)
++find_package(msgpack REQUIRED NAMES msgpack msgpack-c)
+ target_compile_definitions(TensileHost PUBLIC -DTENSILE_MSGPACK=1)
+ 
+ if(TARGET msgpackc-cxx)
diff -Nru rocblas-5.5.1+dfsg/debian/patches/0021-msgpack-cxx-support.patch 
rocblas-5.5.1+dfsg/debian/patches/0021-msgpack-cxx-support.patch
--- rocblas-5.5.1+dfsg/debian/patches/0021-msgpack-cxx-support.patch
1969-12-31 19:00:00.0 -0500
+++ rocblas-5.5.1+dfsg/debian/patches/0021-msgpack-cxx-support.patch
2024-01-27 09:04:20.0 -0500
@@ -0,0 +1,35 @@
+From 0d942a6a8bfa8557171716dbcc1236adc806c9c5 Mon Sep 17 00:00:00 2001
+From: Torre Zuk <42548444+torre...@users.noreply.github.com>
+Date: Wed, 6 Dec 2023 13:14:49 -0700
+Subject: [PATCH] another vcpkg version package name fix (#1836)
+
+* more vcpkg package options
+
+-
+
+Co-authored-by: Zuk 
+---
+ Tensile/Source/lib/CMakeLists.txt | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/Tensile/Source/lib/CMakeLists.txt 
b/Tensile/Source/lib/CMakeLists.txt
+index d3f4b697fb..3fa647d6ec 100644
+--- a/tensile/Tensile/Source/lib/CMakeLists.txt
 b/tensile/Tensile/Source/lib/CMakeLists.txt
+@@ -98,13 +98,15 @@ if(TENSILE_USE_LLVM OR TENSILE_USE_MSGPACK)
+ endif()
+ 
+ if(TENSILE_USE_MSGPACK)
+-find_package(msgpack REQUIRED NAMES msgpack msgpack-c)
++find_package(msgpack REQUIRED NAMES msgpack msgpack-cxx msgpack-c)
+ target_compile_definitions(TensileHost PUBLIC -DTENSILE_MSGPACK=1)
+ 
+ if(TARGET msgpackc-cxx)
+ get_target_property(msgpack_inc msgpackc-cxx 
INTERFACE_INCLUDE_DIRECTORIES)
+ elseif(TARGET msgpackc)
+ get_target_property(msgpack_inc msgpackc 
INTERFACE_INCLUDE_DIRECTORIES)
++elseif(TARGET msgpack-cxx)
++get_target_property(msgpack_inc msgpack-cxx 
INTERFACE_INCLUDE_DIRECTORIES)
+ endif()
+ 
+ if(DEFINED msgpack_inc)
diff -Nru rocblas-5.5.1+dfsg/debian/patches/series 
rocblas-5.5.1+dfsg/debian/patches/series
--- rocblas-5.5.1+dfsg/debian/patches/series 

Bug#1060275: asterisk: Codec translation notice

[List Support]

Le 26/01/2024 à 15:47, Jonas Smedegaard a écrit :

That was my interrogation.

For what I get for information from asterisk developpers, this message
is not an original one so one of the Debian applied patch seems to be
the culpit. On which place can I see all of them to check ? Even if my
knowledge in C is zero, my eyes are OK ;)

More eyes are good :-)

Patches applied are here:
https://salsa.debian.org/pkg-voip-team/asterisk/-/tree/debian/latest/debian/patches


I went through debian asterisk source file and all patches, nowhere I 
found nothing like "lost frames(s)". I thought third-party/resample 
could be the missing part but as I didn´t find reference to it in the 
stock asterisk source...


--
Daniel

Bug#1061621: filament: FTBFS: too few arguments to function call, expected 3, have 2

[Sebastian Ramacher]

Source: filament
Version: 1.9.25+dfsg2-12
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=filament=amd64=1.9.25%2Bdfsg2-12%2Bb2=1706352699=0

make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
[ 93%] Building CXX object 
filament/benchmark/CMakeFiles/benchmark_filament.dir/benchmark_filament.cpp.o
cd /<>/obj-x86_64-linux-gnu/filament/benchmark && /usr/bin/clang++ 
-DFILAMENT_DFG_LUT_SIZE=128 -DFILAMENT_DRIVER_SUPPORTS_VULKAN 
-DFILAMENT_ENABLE_MATDBG=0 -DFILAMENT_MIN_COMMAND_BUFFERS_SIZE_IN_MB=1 
-DFILAMENT_OPENGL_HANDLE_ARENA_SIZE_IN_MB=2 
-DFILAMENT_PER_FRAME_COMMANDS_SIZE_IN_MB=1 
-DFILAMENT_PER_RENDER_PASS_ARENA_SIZE_IN_MB=2 -DFILAMENT_SUPPORTS_XCB 
-DFILAMENT_SUPPORTS_XLIB -DSYSTRACE_TAG=2 
-I/<>/filament/benchmark/../src 
-I/<>/libs/utils/include -I/<>/libs/math/include 
-I/<>/filament/include -I/<>/filament/backend/include 
-I/<>/libs/filabridge/include -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wdate-time -D_FORTIFY_SOURCE=2 -DNDEBUG -std=c++17 -fstrict-aliasing 
-Wno-unknown-pragmas -Wno-unused-function -fPIC -MD -MT 
filament/benchmark/CMakeFiles/benchmark_filament.dir/benchmark_filament.cpp.o 
-MF CMakeFiles/benchmark_filament.dir/benchmark_filament.cpp.o.d -o 
CMakeFiles/benchmark_filament.dir/benchmark_filament.cpp.o -c 
/<>/filament/benchmark/benchmark_filament.cpp
/<>/libs/filagui/src/ImGuiExtensions.cpp:122:58: error: too few 
arguments to function call, expected 3, have 2
const bool hovered = ImGui::ItemHoverable(inner_bb, 0);
 ^
/usr/include/imgui/imgui_internal.h:3037:29: note: 'ItemHoverable' declared here
IMGUI_API bool  ItemHoverable(const ImRect& bb, ImGuiID id, 
ImGuiItemFlags item_flags);
^
1 error generated.
make[3]: *** [libs/filagui/CMakeFiles/filagui.dir/build.make:116: 
libs/filagui/CMakeFiles/filagui.dir/src/ImGuiExtensions.cpp.o] Error 1
make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
make[2]: *** [CMakeFiles/Makefile2:1027: 
libs/filagui/CMakeFiles/filagui.dir/all] Error 2

Cheers
-- 
Sebastian Ramacher

Bug#1061620: autopkgtest: Ignores multiple comma-separated values in Testsuite

[Jérémy Lal]

Package: autopkgtest
Version: 5.32
Severity: normal

Having in debian/control:
Testsuite: autopkgtest-pkg-python, autopkgtest-pkg-pybuild

tests two different things, and having both is nice.

However it seems autopkgtest doesn't consider the field can have multiple 
values,
it only runs one of them - or actually it might fallback to a default test,
because it doesn't recognize the field value.

Code concerned is in lib/testdesc.py

This won't run:
https://sources.debian.org/src/python-keycloak/3.3.0+dfsg-2/debian/control/?hl=30#L30



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

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

Versions of packages autopkgtest depends on:
ii  apt-utils   2.7.10
ii  libdpkg-perl1.22.2
ii  mawk1.3.4.20231126-1
ii  procps  2:4.0.4-2+b1
ii  python3 3.11.6-1
ii  python3-debian  0.1.49

Versions of packages autopkgtest recommends:
ii  autodep8  0.28
ii  fakeroot  1.33-1

Versions of packages autopkgtest suggests:
pn  docker.io
pn  fakemachine  
ii  genisoimage  9:1.1.11-3.4
pn  incus
ii  lxc  1:5.0.3-2
pn  lxd  
ii  ovmf 2023.11-5
pn  ovmf-ia32
ii  podman   4.8.3+ds1-2
ii  python3-distro-info  1.7
pn  qemu-efi-aarch64 
pn  qemu-efi-arm 
ii  qemu-system  1:8.2.0+ds-5
ii  qemu-utils   1:8.2.0+ds-5
ii  schroot  1.6.13-3+b3
ii  util-linux   2.39.3-6
ii  vmdb20.28-1
ii  zerofree 1.1.1-1

-- no debconf information

Bug#892293: closed by Drew Parsons (reply to dpars...@debian.org) (Re: Bug#892293 paraview: errors when saving animations as AVI files [regression])

[Francesco Poli]

On Thu, 04 Jan 2024 11:15:03 + Debian Bug Tracking System wrote:

> Control: fixed 892293 5.11.0+dfsg-1
> 
> Looks like this has been fixed now.
> The .avi animation file is generated fine in paraview 5.11

Yes, I can confirm that the .avi animation is correctly saved by
paraview/5.11.2+dfsg-4 and it is even in the format that is most
portable in my experience (mjpeg yuv420p).

Thanks for checking this bug report!

Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp8walXfa8Zk.pgp
Description: PGP signature

Bug#1061619: read.c OOP_RD_NUL_DISCARD is broken

[Ian Jackson]

Package: liboop4
Version: 1.0.1-2.1

Fixes this compiler warning:

  read.c: In function 'on_process':
  read.c:402:38: warning: comparison between pointer and zero character 
constant [-Wpointer-compare]
   notnul < buf+thisrecsz && notnul == '\0';
^~
  read.c:402:31: note: did you mean to dereference the pointer?
   notnul < buf+thisrecsz && notnul == '\0';

History of this fix: See #579604.  I am tidying up my own
program (innduct), which I find it still has a copy of this file.
Comparing the files I find this one difference.  I seem to have fixed
this bug in 2022 without noticing that I ought to be sending the fix
upstream.  So, apologies for the delay reporting this.

Patch attached.

Thanks,
Ian.

>From 732e5f352205cc1d67ee28ea68fa02869aba5551 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Sat, 27 Jan 2024 13:03:00 +
Subject: [PATCH] read.c: Fix missing dereference - bug with OOP_RD_NUL_DISCARD

Fixes this compiler warning:

  read.c: In function 'on_process':
  read.c:402:38: warning: comparison between pointer and zero character 
constant [-Wpointer-compare]
   notnul < buf+thisrecsz && notnul == '\0';
^~
  read.c:402:31: note: did you mean to dereference the pointer?
   notnul < buf+thisrecsz && notnul == '\0';
 ^

I think the impact would be that OOP_RD_NUL_DISCARD would pass through
(fail to discard) all but the first nul in each buffer-full.

I wrote this file originally.  I don't know why I didn't use memchr
instead of this open-coded loop.  But, I'm don't think it's a good
idea to refactor it now.
---
 read.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/read.c b/read.c
index 38cba00..deaadb5 100644
--- a/read.c
+++ b/read.c
@@ -399,7 +399,7 @@ static void *on_process(oop_source *oop, oop_read *rd, int 
try_read) {
   }
   assert(rd->style.nul_mode == OOP_RD_NUL_DISCARD);
   for (notnul= nul+1;
-  notnul < buf+thisrecsz && notnul == '\0';
+  notnul < buf+thisrecsz && *notnul == '\0';
   notnul++);
   thisrecsz-= (notnul-nul);
   checked= nul-buf;
-- 
2.20.1


-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1061618: src:haskell-misfortune: unsatisfied build dependency in testing: libghc-regex-pcre-doc

[Paul Gevers]

Source: haskell-misfortune
Version: 0.1.2.1-3
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061617: src:roundcube: unsatisfied build dependency in testing: php-bacon-qr-code

[Paul Gevers]

Source: roundcube
Version: 1.6.6+dfsg-1
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061616: New upstream version 0.43.0

[Guido Günther]

Source: pixman
Version: 0.42.2-1
Severity: wishlist

There's a new upstream version. It seems pixman gave up on the odd/even split:

   https://gitlab.freedesktop.org/pixman/pixman/-/issues/87#note_2243045

It seems there's some details to be sorted out but e.g. having it in
expermental would be awesome as wlroots is about to bump it's dependency.
Cheers,
 -- Guido


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

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

Bug#1061615: src:nanobind: unsatisfied build dependency in testing: python3-torch

[Paul Gevers]

Source: nanobind
Version: 1.8.0-3
Severity: serious
Tags: sid trixie
User: debian...@lists.debian.org
Usertags: edos-uninstallable

Dear maintainer(s),

Dose [1] is reporting a build issue with your package, it's missing a
build dependency. Obviously your build dependencies shouldn't be
removed from testing, but unfortunately there are multiple scenarios
where that can happen nevertheless. To uphold our social contract,
Debian requires that packages can be rebuild from source in the suite
we are shipping them, so currently this is a serious issue with your
package in testing.python3-torch

Can you please investigate the situation and figure out how to resolve
it? Regularly, if the build dependency is available in unstable,
helping the maintainer of your Build-Depends to enable migration to
testing is a great way to solve the issue. If your build dependency is
gone from unstable and testing, you'll have to fix the build process
in some other way.

Paul

Note: this bug report was sent after some quick manual checks using a
template. Please reach out to me if you believe I made a mistake in my
process.

[1] https://qa.debian.org/dose/debcheck/src_testing_main/latest/amd64.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061449: linux-image-6.7-amd64: a boot message from amdgpu

[Salvatore Bonaccorso]

Hi

In Debian (https://bugs.debian.org/1061449) we got the following
quotred report:

On Wed, Jan 24, 2024 at 07:38:16PM +0100, Patrice Duroux wrote:
> Package: src:linux
> Version: 6.7.1-1~exp1
> Severity: normal
> 
> Dear Maintainer,
> 
> Giving a try to 6.7, here is a message extracted from dmesg:
> 
> [4.177226] [ cut here ]
> [4.177227] WARNING: CPU: 6 PID: 248 at
> drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_factory.c:387
> construct_phy+0xb26/0xd60 [amdgpu]
> [4.177658] Modules linked in: amdgpu(+) i915(+) sd_mod drm_exec amdxcp
> gpu_sched drm_buddy nvme i2c_algo_bit drm_suballoc_helper drm_display_helper
> ahci nvme_core hid_generic crc32_pclmul libahci crc32c_intel t10_pi cec libata
> crc64_rocksoft_generic ghash_clmulni_intel rc_core drm_ttm_helper
> crc64_rocksoft sha512_ssse3 i2c_hid_acpi ttm rtsx_pci_sdmmc i2c_hid xhci_pci
> crc_t10dif sha512_generic mmc_core scsi_mod xhci_hcd drm_kms_helper video hid
> crct10dif_generic intel_lpss_pci crct10dif_pclmul i2c_i801 sha256_ssse3
> intel_lpss crc64 thunderbolt drm e1000e usbcore sha1_ssse3 rtsx_pci i2c_smbus
> scsi_common crct10dif_common idma64 usb_common battery wmi button aesni_intel
> crypto_simd cryptd
> [4.177689] CPU: 6 PID: 248 Comm: (udev-worker) Not tainted 6.7-amd64 #1
> Debian 6.7.1-1~exp1
> [4.177691] Hardware name: Dell Inc. Precision 7540/0T2FXT, BIOS 1.29.0
> 11/03/2023
> [4.177692] RIP: 0010:construct_phy+0xb26/0xd60 [amdgpu]
> [4.178050] Code: b9 01 00 00 00 83 fe 01 74 40 48 8b 82 f8 03 00 00 89 f2
> 48 c7 c6 00 35 a7 c1 48 8b 40 10 48 8b 00 48 8b 78 08 e8 ba b7 5b fb <0f> 0b 
> 49
> 8b 87 d0 01 00 00 b9 0f 00 00 00 48 8b 80 e8 04 00 00 48
> [4.178052] RSP: 0018:aad300857408 EFLAGS: 00010246
> [4.178053] RAX:  RBX: 96df636a1700 RCX:
> c000efff
> [4.178054] RDX:  RSI: efff RDI:
> 0001
> [4.178055] RBP: 96df4d379c00 R08:  R09:
> aad3008571d0
> [4.178056] R10: 0003 R11: bded2428 R12:
> aad300857474
> [4.178057] R13: c1933140 R14: aad3008577d0 R15:
> 96df43e82000
> [4.178058] FS:  7fcd5d9648c0() GS:96e2cc38()
> knlGS:
> [4.178060] CS:  0010 DS:  ES:  CR0: 80050033
> [4.178061] CR2: 7fcd5d932a6d CR3: 000103e9a004 CR4:
> 003706f0
> [4.178062] DR0:  DR1:  DR2:
> 
> [4.178063] DR3:  DR6: fffe0ff0 DR7:
> 0400
> [4.178063] Call Trace:
> [4.178066]  
> [4.178067]  ? construct_phy+0xb26/0xd60 [amdgpu]
> [4.178422]  ? __warn+0x81/0x130
> [4.178426]  ? construct_phy+0xb26/0xd60 [amdgpu]
> [4.178784]  ? report_bug+0x171/0x1a0
> [4.178787]  ? handle_bug+0x3c/0x80
> [4.178789]  ? exc_invalid_op+0x17/0x70
> [4.178790]  ? asm_exc_invalid_op+0x1a/0x20
> [4.178793]  ? construct_phy+0xb26/0xd60 [amdgpu]
> [4.179149]  ? construct_phy+0xb26/0xd60 [amdgpu]
> [4.179507]  link_create+0x1b2/0x200 [amdgpu]
> [4.179865]  create_links+0x135/0x420 [amdgpu]
> [4.180196]  dc_create+0x321/0x640 [amdgpu]
> [4.180529]  amdgpu_dm_init.isra.0+0x2a0/0x1ed0 [amdgpu]
> [4.180881]  ? sysvec_apic_timer_interrupt+0xe/0x90
> [4.180883]  ? asm_sysvec_apic_timer_interrupt+0x1a/0x20
> [4.180885]  ? delay_tsc+0x37/0xa0
> [4.180889]  dm_hw_init+0x12/0x30 [amdgpu]
> [4.181240]  amdgpu_device_init+0x1e42/0x24a0 [amdgpu]
> [4.181517]  amdgpu_driver_load_kms+0x19/0x190 [amdgpu]
> [4.181793]  amdgpu_pci_probe+0x165/0x4c0 [amdgpu]
> [4.182067]  local_pci_probe+0x42/0xa0
> [4.182070]  pci_device_probe+0xc7/0x240
> [4.182072]  really_probe+0x19b/0x3e0
> [4.182075]  ? __pfx___driver_attach+0x10/0x10
> [4.182076]  __driver_probe_device+0x78/0x160
> [4.182078]  driver_probe_device+0x1f/0x90
> [4.182079]  __driver_attach+0xd2/0x1c0
> [4.182081]  bus_for_each_dev+0x85/0xd0
> [4.182083]  bus_add_driver+0x116/0x220
> [4.182085]  driver_register+0x59/0x100
> [4.182087]  ? __pfx_amdgpu_init+0x10/0x10 [amdgpu]
> [4.182356]  do_one_initcall+0x58/0x320
> [4.182359]  do_init_module+0x60/0x240
> [4.182361]  init_module_from_file+0x89/0xe0
> [4.182364]  idempotent_init_module+0x120/0x2b0
> [4.182366]  __x64_sys_finit_module+0x5e/0xb0
> [4.182367]  do_syscall_64+0x61/0x120
> [4.182370]  ? do_syscall_64+0x70/0x120
> [4.182372]  entry_SYSCALL_64_after_hwframe+0x6e/0x76
> [4.182375] RIP: 0033:0x7fcd5e130f19
> [4.182376] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89
> f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 
> 01
> f0 ff ff 73 01 c3 48 8b 0d cf 1e 0d 00 f7 d8 64 89 01 48
> [4.182378] RSP: 002b:7ffd314afa38 EFLAGS: 0246 ORIG_RAX:
> 0139
> [4.182379] RAX: ffda 

Bug#1061614: Mark symbols not seen building with -O3 as optional.

[Matthias Klose]

Package: src:gensio
Version: 2.8.2-3
Tags: patch

Mark symbols not seen building with -O3 as optional.
Patch at
https://launchpadlibrarian.net/711397503/gensio_2.8.2-3_2.8.2-3ubuntu1.diff.gz

also there seems to be one library gone (all archs):

dh_makeshlibs -a --exclude=libexec
dpkg-gensymbols: warning: some libraries disappeared in the symbols 
file: libgensiotcl.so.6
dpkg-gensymbols: warning: debian/libgensio6/DEBIAN/symbols doesn't match 
completely debian/libgensio6.symbols

--- debian/libgensio6.symbols (libgensio6_2.8.2-3_amd64)
+++ dpkg-gensymbolsxdVAbG   2024-01-27 03:15:15.736867101 +
@@ -820,5 +820,3 @@
  _ZTVN7gensios12gensio_errorE@Base 2.8.2
  _ZTVN7gensios4AddrE@Base 2.8.2
  _ZTVN7gensios8Os_FuncsE@Base 2.8.2
-libgensiotcl.so.6 libgensio6 #MINVER#
- gensio_tcl_funcs_alloc@Base 2.8.2

Bug#1061610: debhelper: cp --update=none requires coreutils 9.3 or newer

[Sven Joachim]

On 2024-01-27 13:46 +0100, Sven Joachim wrote:

> Package: libdebhelper-perl
> Version: 13.12
> Severity: important
> X-Debbugs-Cc: Sven Joachim , debian-h...@lists.debian.org
>
> Commit 018a0c9a7164f ("Dh_Lib.pm: Fix warning from `cp -n`") uses cp's
> --update=none option which has been introduced rather recently, namely
> in coreutils 9.3.  Older versions of cp do not understand this option,
> complain and refuse to operate.  For instance dh_update_autotools_config
> fails with older coreutils:
>
> ,
> | $ cp --version | head -n1
> | cp (GNU coreutils) 9.1
> | $ dh_update_autotools_config
> | cp: option '--update' doesn't allow an argument
> | Try 'cp --help' for more information.
> | dh_update_autotools_config: error: cp -a --update=none
> | --reflink=auto config.guess
> | 
> debian/.debhelper/bucket/files/ec2577614252326f889df1de97b9a457c03a9a94811048563c211a44496d8ba3.tmp
> | returned exit code 1
> `
>
> This is obviously bad for backports, more urgently it is going to make
> many packages FTBFS on hurd-i386 which is stuck at coreutils 9.1-1.
>
> I will open a separate bug on coreutils for giving the questionable
> advice to use the --update=none option.

Reported as #1061612.

Cheers,
   Sven

Bug#1061613: src:stellarium: fails to migrate to testing for too long: FTBFS on armel, ppc64el and s390x

[Paul Gevers]

Source: stellarium
Version: 23.3-1
Severity: serious
Control: close -1 23.4-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:stellarium has been trying to migrate for 
31 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build on armel, ppc64el and s390x as reported in bug 1060802.


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=stellarium



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061552: crmsh broken with python3-parallax 1.0.6

[wferi]

Indeed, parallax.run was added only in version 1.0.7 by
https://github.com/krig/parallax/commit/38bac0eb3cb20e9df8cbbf585cf9353793ffdba2.
Thanks for the report!
--
Feri (only acknowledging it; I don't use crmsh, so no promises).

Bug#1061262: ecdh-nist-p256: stack dump on boot

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

On Sun, Jan 21, 2024 at 06:43:11PM +0100, Kjell M. Myksvoll wrote:
> Package: ecdh-nist-p256
> Severity: normal
> X-Debbugs-Cc: kjell.myksv...@gmail.com
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> Reboot after package updates.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
> 
> [3.334317] [ cut here ]
> [3.334319] alg: self-tests for ecdh-nist-p256 using 
> ecdh-nist-p256-generic failed (rc=-14)
> [3.334325] WARNING: CPU: 27 PID: 461 at crypto/testmgr.c:5936 
> alg_test+0x516/0x630
> [3.334331] Modules linked in: ecdh_generic(+) ecc crc16 amdgpu(+) 
> i2c_algo_bit drm_ttm_helper ttm video drm_suballoc_helper amdxcp drm_buddy 
> gpu_sched drm_display_helper drm_kms_helper xhci_pci nvme drm xhci_hcd 
> nvme_core t10_pi crc32c_intel cec usbcore crc64_rocksoft crc64 rc_core 
> crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common usb_common 
> gpio_amdpt wmi gpio_generic
> [3.334369] CPU: 27 PID: 461 Comm: cryptomgr_test Not tainted 
> 6.5.0-5-amd64 #1  Debian 6.5.13-1
> [3.334372] Hardware name: System manufacturer System Product Name/PRIME 
> X399-A, BIOS 1601 04/14/2023
> [3.334374] RIP: 0010:alg_test+0x516/0x630
> [3.334377] Code: ff ff 4c 89 e6 4c 89 e7 41 89 c7 e8 e4 f4 fe ff e9 37 ff 
> ff ff 44 89 f9 48 89 ea 4c 89 ee 48 c7 c7 38 08 0c 98 e8 1a 5d b5 ff <0f> 0b 
> e9 7d fe ff ff 48 89 c2 48 89 ee 48 c7 c7 70 07 0c 98 45 89
> [3.334379] RSP: 0018:bd2844e97e10 EFLAGS: 00010286
> [3.334381] RAX:  RBX: 007e RCX: 
> c0007fff
> [3.334383] RDX:  RSI: 7fff RDI: 
> 0001
> [3.334385] RBP: 987682aeee00 R08:  R09: 
> bd2844e97ca0
> [3.334386] R10: 0003 R11: 987deedfffe8 R12: 
> 007f
> [3.334388] R13: 987682aeee80 R14:  R15: 
> fff2
> [3.334390] FS:  () GS:987def0c() 
> knlGS:
> [3.334392] CS:  0010 DS:  ES:  CR0: 80050033
> [3.334393] CR2: 7fe96d9ba840 CR3: 00010c7ea000 CR4: 
> 003506e0
> [3.334395] Call Trace:
> [3.334398]  
> [3.334399]  ? alg_test+0x516/0x630
> [3.334401]  ? __warn+0x81/0x130
> [3.334406]  ? alg_test+0x516/0x630
> [3.334409]  ? report_bug+0x171/0x1a0
> [3.334413]  ? prb_read_valid+0x1b/0x30
> [3.334417]  ? srso_return_thunk+0x5/0x10
> [3.334422]  ? handle_bug+0x3c/0x80
> [3.334426]  ? exc_invalid_op+0x17/0x70
> [3.334429]  ? asm_exc_invalid_op+0x1a/0x20
> [3.334435]  ? alg_test+0x516/0x630
> [3.334438]  ? psi_memstall_leave+0xb0/0xb0
> [3.334441]  ? srso_return_thunk+0x5/0x10
> [3.33]  ? finish_task_switch.isra.0+0x8f/0x2d0
> [3.334449]  ? srso_return_thunk+0x5/0x10
> [3.334452]  ? __schedule+0x3e2/0xb20
> [3.334457]  ? __pfx_cryptomgr_test+0x10/0x10
> [3.334460]  cryptomgr_test+0x24/0x40
> [3.334464]  kthread+0xe8/0x120
> [3.334468]  ? __pfx_kthread+0x10/0x10
> [3.334471]  ret_from_fork+0x34/0x50
> [3.334475]  ? __pfx_kthread+0x10/0x10
> [3.334478]  ret_from_fork_asm+0x1b/0x30
> [3.334486]  
> [3.334487] ---[ end trace  ]---
> 
>* What outcome did you expect instead?
> 
> No stack dump.

Please test 6.6.13-1 from unstable and 6.7.1-1~exp1 from experimental
as the 6.5.y series won't get any more updates. Does the bug show up
there as well?

Regards,
Salvatore

Bug#1061612: coreutils: cp -n deprecation warning gives questionable advice

[Sven Joachim]

Package: coreutils
Version: 9.4-3+b1

,
| $ cp -n /bin/true tmp
| cp: warning: behavior of -n is non-portable and may change in future; use 
--update=none instead
`

The advice to use the --update=none option is highly questionable,
because this option is even less portable than -n.  It is not available
in coreutils older than 9.3 or in other cp implementations.

The result is that package maintainers follow the deprecation advice
likely without also introducing a versioned dependency on coreutils,
causing problems for backports and partial upgrades.  There is also one
Debian port (hurd-i386) which does not even have a recent enough
coreutils version.

See 1061610 in debhelper, which I have just opened.

Bug#1060052: Status?

[Salvatore Bonaccorso]

Hi,

On Thu, Jan 25, 2024 at 02:55:52AM +, Dennis Haney wrote:
> Can we please get a new release of a stable kernel?
> This keeps crashing our machines, and it is a pain manually updating
> to the 6.5 kernel on all of them.

A fix for this issue will be released with the upcoming point releases
scheduled on 10th of february as per
https://lists.debian.org/debian-release/2024/01/msg00399.html . The
kernel will be latest available as well one week earlier in
bookworm-proposed-updates.

Regards,
Salvatore

Bug#1061611: RFS: tapecalc/20240110-1 -- full-screen tape editor that lets the user edit a calculation

[Victor Westerhuis]

Package: sponsorship-requests
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear mentors,

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

 * Package name : tapecalc
   Version  : 20240110-1
   Upstream contact : Thomas E. Dickey 
 * URL  : https://invisible-island.net/add/add.html
 * License  : X11, MIT-old
 * Vcs  : https://salsa.debian.org/debian/tapecalc
   Section  : math

The source builds the following binary packages:

  tapecalc - full-screen tape editor that lets the user edit a calculation

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/tapecalc/tapecalc_20240110-1.dsc

Changes since the last upload:

 tapecalc (20240110-1) unstable; urgency=medium
 .
   * New upstream version 20240110.
   * Update copyright years.
   * Update d/upstream/signing-key.asc.
- --

Vriendelijke groet, Kind regards,

Victor Westerhuis

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmW09GwTHHZpY3RvckB3
ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+8iMEACPTI3ZsjLqyttxffhI09omXsSTcioS
Q2rPc8z1Qy+2sxUUVpy0s5yfV1iWA4fN0swBPWfpu//QxLD8SLxgwP639F5Xh/VX
VVzVYbnIm5AmqUL8Nx3KWxXPuhNSLo0TCvS5imFE6C4y633frdBA+cCbl+F/Kien
oS0wilohN+ChF5XYGRluBNvsLN7dfjVyqRDBkV61i6l7MeljbNV2oxuYo+Vn30zX
IVcYMKyQykAwSk0vsI58P9GpA9URKYf9RMfPqJ8BXVK+fbsCVt86N6cVrbOBYWfj
BcAostv3wYhPwkNe/SyZWk/i6aBDZFCgixxz2x9Y8ofGtkvNu5rolPAqN2DfjEnJ
Jt7487mBg6eYuR2PnRpUwIuImA5WxiO4NXMNlE4rZkBwv4yOeh3eBjaQo6BL5PCz
1MjYh+7tOd/EdR2FoVBnn+MmhK9hoqq1nq1gsC1fRlogSMz3KUfgvhMnPFL2dzKs
x+cFR7uyTUIDf3wcmgtLOwGUgTxpTZHX5QiVtuHHR+Lf0PqrA+FQy8W6xruM5DUX
VELZwPYNejMLjYCH13JW6JrIixXrLqrTOBTlOIuM6lFiAnIl6l7NMBWmxmU5FXZL
B573Tyo0+vvY8rEmFwVILGJ9yN5E1IgtYpc0dHMEQ+aIpOLZvv3P3KkuS81k3z6Z
8QqkVD2YbX/FIw==
=W93B
-END PGP SIGNATURE-