Bug#1038152: supertuxkart: Supertuxkart does not start - missing NotoColorEmoji.ttf

[Federico]

Package: supertuxkart
Version: 1.4+dfsg-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: matta2...@gmail.com

Dear Maintainer,

after clean apt install, STK does not start.

[info   ] SharedGPUObjects: Hardware Skinning enabled, method: TBO, max bones:
1024
[info   ] ShaderFilesManager: Compiling shader:
/usr/share/games/supertuxkart/data/shaders/screenquad.vert
[info   ] ShaderFilesManager: Compiling shader:
/usr/share/games/supertuxkart/data/shaders/motion_blur.frag
[info   ] ShaderFilesManager: Compiling shader:
/usr/share/games/supertuxkart/data/shaders/lightning.frag
[info   ] ShaderFilesManager: Compiling shader:
/usr/share/games/supertuxkart/data/shaders/primitive2dlist.vert
[info   ] ShaderFilesManager: Compiling shader:
/usr/share/games/supertuxkart/data/shaders/transparent.frag
[info   ] ShaderFilesManager: Compiling shader:
/usr/share/games/supertuxkart/data/shaders/texturedquad.vert
[info   ] ShaderFilesManager: Compiling shader:
/usr/share/games/supertuxkart/data/shaders/uniformcolortexturedquad.frag
[info   ] ShaderFilesManager: Compiling shader:
/usr/share/games/supertuxkart/data/shaders/texturedquad.frag
[info   ] ShaderFilesManager: Compiling shader:
/usr/share/games/supertuxkart/data/shaders/coloredquad.vert
[info   ] ShaderFilesManager: Compiling shader:
/usr/share/games/supertuxkart/data/shaders/coloredquad.frag
[info   ] ShaderFilesManager: Compiling shader:
/usr/share/games/supertuxkart/data/shaders/colortexturedquad.vert
[info   ] ShaderFilesManager: Compiling shader:
/usr/share/games/supertuxkart/data/shaders/colortexturedquad.frag
[info   ] irr_driver: GLSL supported.
[info   ] GUI: Loading skin data from file:
/usr/share/games/supertuxkart/data/skins/peach/stkskin.xml
[fatal  ] [FileManager]: Can not find file 'NotoColorEmoji.ttf' in
'/usr/share/games/supertuxkart/data/ttf/'

Can not find file 'NotoColorEmoji.ttf   ' in
'/usr/share/games/supertuxkart/data/ttf/'


/usr/share/games/supertuxkart/data/ttf> ls -la
total 4588
drwxr-xr-x  2 root root4096 May 29 11:15 .
drwxr-xr-x 20 root root4096 May 29 11:15 ..
lrwxrwxrwx  1 root root  58 Feb 28 23:00 Cantarell-Regular.otf ->
../../../../fonts/opentype/cantarell/Cantarell-Regular.otf
lrwxrwxrwx  1 root root  50 Feb 28 23:00 NotoColorEmoji.ttf ->
../../../../fonts/truetype/noto/NotoColorEmoji.ttf
lrwxrwxrwx  1 root root  61 Feb 28 23:00 NotoNaskhArabicUI-Regular.ttf ->
../../../../fonts/truetype/noto/NotoNaskhArabicUI-Regular.ttf
lrwxrwxrwx  1 root root  58 Feb 28 23:00 NotoSansHebrew-Regular.ttf ->
../../../../fonts/truetype/noto/NotoSansHebrew-Regular.ttf
lrwxrwxrwx  1 root root  61 Feb 28 23:00 NotoSansMalayalam-Regular.ttf ->
../../../../fonts/truetype/noto/NotoSansMalayalam-Regular.ttf
lrwxrwxrwx  1 root root  56 Feb 28 23:00 NotoSansThai-Regular.ttf ->
../../../../fonts/truetype/noto/NotoSansThai-Regular.ttf
-rw-r--r--  1 root root   50384 Oct 31  2022 SigmarOne.otf
-rw-r--r--  1 root root 4626376 Oct 31  2022 wqy-microhei.ttf

/usr/share/games/supertuxkart/data/ttf> ls -la

../../../../fonts/truetype/noto/NotoColorEmoji.ttf
bash: ../../../../fonts/truetype/noto/NotoColorEmoji.ttf: No such file or
directory

Maybe there is a dependency issue, missing a noto package to install
NotoColorEmoji.ttf

Do you mind checking it?

Thanks,


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 supertuxkart depends on:
ii  libbluetooth3  5.66-1
ii  libc6  2.36-9
ii  libcurl3-gnutls7.88.1-10
ii  libfreetype6   2.12.1+dfsg-5
ii  libgcc-s1  12.2.0-14
ii  libharfbuzz0b  6.0.0+dfsg-3
ii  libjpeg62-turbo1:2.1.5-2
ii  libmbedcrypto7 2.28.3-1
ii  libmcpp0   2.7.2-5
ii  libopenal1 1:1.19.1-2
ii  libpng16-161.6.39-2
ii  libsdl2-2.0-0  2.26.5+dfsg-1
ii  libsqlite3-0   3.40.1-2
ii  libsquish0 1.15-3
ii  libstdc++6 12.2.0-14
ii  libvorbisfile3 1.3.7-1
ii  supertuxkart-data  1.4+dfsg-2
ii  zlib1g 1:1.2.13.dfsg-1

supertuxkart recommends no packages.

supertuxkart suggests no packages.

-- no debconf information

Bug#1037875: u-boot: ftbfs with GCC-13

[Matthias Klose]

On 15.06.23 20:52, Vagrant Cascadian wrote:

On 2023-06-14, Matthias Klose wrote:

The package fails to build in a test rebuild on at least amd64 with
gcc-13/g++-13, but succeeds to build with gcc-12/g++-12. The
severity of this report will be raised before the trixie release.

The full build log can be found at:
http://qa-logs.debian.net/2023/05/22/logs/u-boot_2023.01+dfsg-2_unstable_gccexp.log
The last lines of the build log are at the end of this report.


It appears that the only reason this failed is the corresponding
packages from gcc-13-cross or some other related cross packages were not
available in the test environment:

The following packages have unmet dependencies:
  libgcc-13-dev-arm64-cross : Depends: libgcc-s1-arm64-cross (>= 
13.1.0-2cross1) but 12.2.0-14cross1 is to be installed
  Depends: libgomp1-arm64-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
  Depends: libitm1-arm64-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
  Depends: libatomic1-arm64-cross (>= 
13.1.0-2cross1) but 12.2.0-14cross1 is to be installed
  Depends: libasan8-arm64-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
  Depends: liblsan0-arm64-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
  Depends: libtsan2-arm64-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
  Depends: libubsan1-arm64-cross (>= 
13.1.0-2cross1) but 12.2.0-14cross1 is to be installed
  Depends: libhwasan0-arm64-cross (>= 
13.1.0-2cross1) but 12.2.0-14cross1 is to be installed
  libgcc-13-dev-armhf-cross : Depends: libgcc-s1-armhf-cross (>= 
13.1.0-2cross1) but 12.2.0-14cross1 is to be installed
  Depends: libgomp1-armhf-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
  Depends: libatomic1-armhf-cross (>= 
13.1.0-2cross1) but 12.2.0-14cross1 is to be installed
  Depends: libasan8-armhf-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
  Depends: libubsan1-armhf-cross (>= 
13.1.0-2cross1) but 12.2.0-14cross1 is to be installed
  libgcc-13-dev-i386-cross : Depends: libgcc-s1-i386-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: libgomp1-i386-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: libitm1-i386-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: libatomic1-i386-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: libasan8-i386-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: libubsan1-i386-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: libquadmath0-i386-cross (>= 
13.1.0-2cross1) but 12.2.0-14cross1 is to be installed
E: Unable to correct problems, you have held broken packages.


Wild guess is these need to be explicitly pulled in by the test
environment in addition to the packages from the gcc-13 source
package...


closing, I forgot to update the cross compilers for the test rebuild.

Bug#1037064: maven-verifier depends on downloading sources at build time

[tony mancill]

On Sat, Jun 03, 2023 at 12:58:17PM +0200, gregor herrmann wrote:
> On Fri, 02 Jun 2023 21:40:10 -0700, Steve Langasek wrote:
> 
> > While this is not a build failure, it does mean building the package has a
> > dependency on software outside of main, which I believe is a serious policy
> > violation.
> 
> The network access during build is a policy violation in itself:
> 
> 4.9
> …
> For packages in the main archive, required targets must not
> attempt network access, except, via the loopback interface, to
> services on the build host that have been started by the build.

For posterity, I tested locally using network namespaces and described
here [1].  Specifically:

# create a chroot including the build-deps
# (maybe there's an easier way?)

sudo sbuild-createchroot --no-deb-src --chroot-mode=schroot \
   --chroot-prefix=1037064 \
   
--include=debhelper,default-jdk,junit4,libeclipse-sisu-maven-plugin-java,libmaven-parent-java,libmaven-resolver-transport-http-java,libmaven-shared-utils-java,libmodello-maven-plugin-java,maven-debian-helper
 \
   unstable /data/chroot/1037064-amd64-sbuild http://localhost:3142/debian

# create the namespace
sudo ip netns add no-net

# build
sudo ip netns exec no-net sbuild --no-apt-update --no-apt-upgrade \
--no-apt-distupgrade --no-run-lintian --chroot=1037064-amd64-sbuild

# clean up
/usr/sbin/sbuild-destroychroot 1037064-amd64-sbuild

[1] 
https://wiki.debian.org/sbuild#Disabling_network_access_for_dpkg-buildpackage

Bug#1037444: bookworm-pu: package kanboard/1.2.26+ds-4

[Joe Nahmias]

Attached is a revised debdiff between -2 and -2+deb12u1.
--Joe
diff -Nru kanboard-1.2.26+ds/debian/changelog 
kanboard-1.2.26+ds/debian/changelog
--- kanboard-1.2.26+ds/debian/changelog 2023-05-16 22:49:38.0 -0400
+++ kanboard-1.2.26+ds/debian/changelog 2023-06-15 23:02:33.0 -0400
@@ -1,3 +1,24 @@
+kanboard (1.2.26+ds-2+deb12u1) bookworm; urgency=high
+
+  * Cherry-pick security fixes from kanboard_1.2.26+ds-[34] for bookworm.
+  * backport fix for CVE-2023-32685 from kanboard v1.2.29
+
https://github.com/kanboard/kanboard/security/advisories/GHSA-hjmw-gm82-r4gv
+Based on upstream commits 26b6eeb & c9c1872.
+(cherry picked from commit d9b8d854f2d35831b04b84cfdda41cc7b49e3a28)
+(Closes: #1036874)
+  * backport security fixes from kanboard v1.2.30.
+ > CVE-2023-33956: Parameter based Indirect Object Referencing leading
+   to private file exposure
+ > CVE-2023-33968: Missing access control allows user to move and
+   duplicate tasks to any project in the software
+ > CVE-2023-33969: Stored XSS in the Task External Link Functionality
+ > CVE-2023-33970: Missing access control in internal task links feature
+(cherry picked from commit 4ad0ad220613bbf04bef559addba8c363fdf0dfa)
+(Closes: #1037167)
+  * point gbp & salsa at bookworm
+
+ -- Joseph Nahmias   Thu, 15 Jun 2023 23:02:33 -0400
+
 kanboard (1.2.26+ds-2) unstable; urgency=medium
 
   * properly test for lighty-enable-mod.
diff -Nru kanboard-1.2.26+ds/debian/gbp.conf kanboard-1.2.26+ds/debian/gbp.conf
--- kanboard-1.2.26+ds/debian/gbp.conf  2023-05-09 06:27:15.0 -0400
+++ kanboard-1.2.26+ds/debian/gbp.conf  2023-06-15 23:02:33.0 -0400
@@ -1,3 +1,3 @@
 [DEFAULT]
-debian-branch = debian/latest
+debian-branch = debian/bookworm
 pristine-tar = True
diff -Nru kanboard-1.2.26+ds/debian/patches/CVE-2023-32685.patch 
kanboard-1.2.26+ds/debian/patches/CVE-2023-32685.patch
--- kanboard-1.2.26+ds/debian/patches/CVE-2023-32685.patch  1969-12-31 
19:00:00.0 -0500
+++ kanboard-1.2.26+ds/debian/patches/CVE-2023-32685.patch  2023-06-15 
23:00:52.0 -0400
@@ -0,0 +1,111 @@
+Description: fix for CVE-2023-32685
+ Clipboard based cross-site scripting (blocked with default CSP)
+ https://github.com/kanboard/kanboard/security/advisories/GHSA-hjmw-gm82-r4gv
+Author: Frédéric Guillot 
+Origin: upstream
+Last-Update: 2023-05-24
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+diff --git a/assets/js/components/screenshot.js 
b/assets/js/components/screenshot.js
+index a8acd64..1130bd2 100644
+--- a/assets/js/components/screenshot.js
 b/assets/js/components/screenshot.js
+@@ -1,5 +1,4 @@
+ KB.component('screenshot', function (containerElement) {
+-var pasteCatcher = null;
+ var inputElement = null;
+ 
+ function onFileLoaded(e) {
+@@ -7,7 +6,6 @@ KB.component('screenshot', function (containerElement) {
+ }
+ 
+ function onPaste(e) {
+-// Firefox doesn't have the property e.clipboardData.items (only 
Chrome)
+ if (e.clipboardData && e.clipboardData.items) {
+ var items = e.clipboardData.items;
+ 
+@@ -24,69 +22,13 @@ KB.component('screenshot', function (containerElement) {
+ }
+ }
+ }
+-} else {
+-
+-// Handle Firefox
+-setTimeout(checkInput, 100);
+ }
+ }
+ 
+ function initialize() {
+-destroy();
+-
+-if (! window.Clipboard) {
+-// Insert the content editable at the top to avoid scrolling down 
in the board view
+-pasteCatcher = document.createElement('div');
+-pasteCatcher.id = 'screenshot-pastezone';
+-pasteCatcher.contentEditable = true;
+-pasteCatcher.style.opacity = 0;
+-pasteCatcher.style.position = 'fixed';
+-pasteCatcher.style.top = 0;
+-pasteCatcher.style.right = 0;
+-pasteCatcher.style.width = 0;
+-document.body.insertBefore(pasteCatcher, 
document.body.firstChild);
+-
+-pasteCatcher.focus();
+-
+-// Set the focus when clicked anywhere in the document
+-document.addEventListener('click', setFocus);
+-
+-// Set the focus when clicked in screenshot dropzone
+-
document.getElementById('screenshot-zone').addEventListener('click', setFocus);
+-}
+-
+ window.addEventListener('paste', onPaste, false);
+ }
+ 
+-function destroy() {
+-if (KB.exists('#screenshot-pastezone')) {
+-KB.find('#screenshot-pastezone').remove();
+-}
+-
+-document.removeEventListener('click', setFocus);
+-pasteCatcher = null;
+-}
+-
+-function setFocus() {
+-if (pasteCatcher !== null) {
+-pasteCatcher.focus();
+-}
+-}
+-
+-function checkInput() {
+-var child = pasteCatcher.childNodes[0];
+-
+-if (child) {
+-

Bug#1034771: generate_firmware_patterns failed: 512 at ./tmp/debian-cd/tools/make_disc_trees.pl line 1257

[Arnaud Rebillout]

On Sat, 03 Jun 2023 23:17:22 -0700 Vagrant Cascadian 
 wrote:

>
> This is because reprepro does not generate or support these
> dep11/Components-*.ym.gz files...
>
> https://bugs.debian.org/824521
>
> It might be possible to work around in similar to how debian-installer
> images are download in simple_cdd/tools/mirror_download.py

Another approach: debian-cd could make DEP11 optional, so that 
derivatives can opt out. I opened a merge request: 
https://salsa.debian.org/images-team/debian-cd/-/merge_requests/31


--
Arnaud Rebillout / OffSec / Kali Linux Developer

Bug#142568: gnome-breakout: Ball got stuck in undestructible brick

[Tassia Camoes Araujo]

Hello Lionel,

I hope this message finds you well.

Do you still think it is relevant to leave this bug open?
It's been quite a long time since it was reported, with no
reproducibility, IMHO it's very unlikely that the original issue could
be targeted.
Should we close this bug?

Thanks,

Tassia.

Bug#1038150: openssh-client: Please add the openssh-client group rename from "ssh" to "_ssh" to the bookworm release notes

[Alban Browaeys]

Package: openssh-client
Version: 1:9.2p1-2
Severity: important
X-Debbugs-Cc: pra...@yahoo.com

I cannot login anymore via ssh.
I have the openemediavault installed on this box to manage the setup and
it set AllowGroups to "root ssh" in /etc/ssh/sshd_config.
Thankfully I have a serial console to this ARM board and thus I can
still open a terminal on this box.

After the request from a user to rename the "ssh" group to free it for its
own use, the "ssh" group was rename to "_ssh" in
https://salsa.debian.org/ssh-team/openssh/-/commit/18da782ebe789d0cf107a550e474ba6352e68911

But other users as in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990456#35 or tools to
manage Debian have come to rely on this "ssh" group. This might be a
mistake. Still could you document this critical item in the bookworm
release notes?

Cheers,
Alban


-- System Information:
Debian Release: 12.0
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'stable'), (500, 'oldstable'), (90, 'experimental')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 6.1.11-rockchip64 (SMP w/6 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openssh-client depends on:
ii  adduser   3.134
ii  libc6 2.36-9
ii  libedit2  3.1-20221030-2
ii  libfido2-11.12.0-2+b1
ii  libgssapi-krb5-2  1.20.1-2
ii  libselinux1   3.4-1+b6
ii  libssl3   3.0.9-1
ii  passwd1:4.13+dfsg1-1+b1
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages openssh-client recommends:
pn  xauth  

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh
pn  monkeysphere  
pn  ssh-askpass   

-- no debconf information

Bug#1038122: cp: cannot stat '/tmp/odbcinst.ini.bak'

[Hugh McMaster]

Hi Simon and Alan,

On Fri, 16 Jun 2023 at 09:24, Simon McVittie wrote:
>
> Control: severity -1 serious
> Control: block 1038041 by -1
>
> On Fri, 16 Jun 2023 at 03:49:12 +0930, Arthur Marsh wrote:
> > Attempting to upgrade odbc related packages from 2.3.11-2 to 2.3.11-3
>
> > Setting up unixodbc-common (2.3.11-3) ...
> > cp: cannot stat '/tmp/odbcinst.ini.bak': No such file or directory
> > dpkg: error processing package unixodbc-common (--configure):
> >  installed unixodbc-common package post-installation script subprocess 
> > returned error exit status 1
>
> Here's a repeatable reproducer for this bug:
>
> $ podman run --rm -it debian:sid # not sid-slim to avoid #1038067
> # apt update
> # apt upgrade
> # apt install unixodbc-common
> # rm /etc/odbcinst.ini
> # apt install --reinstall unixodbc-common
> ...
> Unpacking unixodbc-common (2.3.11-3) over (2.3.11-3) ...
> Setting up unixodbc-common (2.3.11-3) ...
> cp: cannot stat '/tmp/odbcinst.ini.bak': No such file or directory
>
> I don't actively use this package (it's installed as a dependency) so
> I haven't *intentionally* modified or deleted /etc/odbcinst.ini, but it
> wasn't present on my laptop for whatever reason, causing this failure
> mode during upgrades. Deleting configuration files is usually treated
> as an intentional sysadmin change that should be preserved.

/etc/odbcinst.ini should definitely be created during postinst if not
already present.

In this case, the log should show an error on preinst as well.

> I think the regression of failing to upgrade is a considerably worse
> bug than the old conffile record still being present in dpkg's database
> (#1009152). Is there a user-visible impact of #1009152 that makes it worth
> having this extra complexity? I'm not at all sure that
> https://bugs.debian.org/1009152#15 is the
> right thing to be doing here.

I tested multiple new install and upgrade scenarios, although it seems
likely I didn't test this particular scenario.

There is no user impact, other than a slightly non-clean system.

rm_conffile renames the conffile to conffile.dpkg-bak, which is only
deleted during package purge.

I'm now thinking a much better approach is to test for the presence of
the backup file during postinst and copy it back as /etc/odbcinst.ini.

That would greatly simplify things and avoid any breakage that we are
seeing now. I'll test this thoroughly, of course.

> Not *directly* related to the failure to upgrade, but I'm also
> concerned by this package using a fixed filename in /tmp to save and
> restore a root-owned configuration file. /tmp is world-writeable, so
> the worst-case assumption needs to be that a malicious local user has
> created /tmp/odbcinst.ini.bak with crafted contents (maybe as a directory,
> or a symlink to a location of their choice, or as a hard link). If so,
> then I'm worried that there might be something they can do to cause a
> denial of service, or worse, overwrite something (/etc/odbcinst.ini or
> otherwise) with attacker-controlled contents. If this tricky save/restore
> transaction is needed, it would be safer to use a root-owned location
> in /etc or /var that is namespaced appropriately for the package, for
> example perhaps "/etc/odbcinst.ini.maintscript-temp" analogous to dpkg's
> .dpkg-old and so on.

Yes, mktemp or tempdir would be more appropriate, although retrieving
the path in a different script is not so easy.

Bug#1038122: cp: cannot stat '/tmp/odbcinst.ini.bak'

[Simon McVittie]

Control: severity -1 serious
Control: block 1038041 by -1

On Fri, 16 Jun 2023 at 03:49:12 +0930, Arthur Marsh wrote:
> Attempting to upgrade odbc related packages from 2.3.11-2 to 2.3.11-3

> Setting up unixodbc-common (2.3.11-3) ...
> cp: cannot stat '/tmp/odbcinst.ini.bak': No such file or directory
> dpkg: error processing package unixodbc-common (--configure):
>  installed unixodbc-common package post-installation script subprocess 
> returned error exit status 1

Here's a repeatable reproducer for this bug:

$ podman run --rm -it debian:sid # not sid-slim to avoid #1038067
# apt update
# apt upgrade
# apt install unixodbc-common
# rm /etc/odbcinst.ini
# apt install --reinstall unixodbc-common
...
Unpacking unixodbc-common (2.3.11-3) over (2.3.11-3) ...
Setting up unixodbc-common (2.3.11-3) ...
cp: cannot stat '/tmp/odbcinst.ini.bak': No such file or directory

I don't actively use this package (it's installed as a dependency) so
I haven't *intentionally* modified or deleted /etc/odbcinst.ini, but it
wasn't present on my laptop for whatever reason, causing this failure
mode during upgrades. Deleting configuration files is usually treated
as an intentional sysadmin change that should be preserved.

I think the regression of failing to upgrade is a considerably worse
bug than the old conffile record still being present in dpkg's database
(#1009152). Is there a user-visible impact of #1009152 that makes it worth
having this extra complexity? I'm not at all sure that
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009152#15 is the
right thing to be doing here.

Not *directly* related to the failure to upgrade, but I'm also
concerned by this package using a fixed filename in /tmp to save and
restore a root-owned configuration file. /tmp is world-writeable, so
the worst-case assumption needs to be that a malicious local user has
created /tmp/odbcinst.ini.bak with crafted contents (maybe as a directory,
or a symlink to a location of their choice, or as a hard link). If so,
then I'm worried that there might be something they can do to cause a
denial of service, or worse, overwrite something (/etc/odbcinst.ini or
otherwise) with attacker-controlled contents. If this tricky save/restore
transaction is needed, it would be safer to use a root-owned location
in /etc or /var that is namespaced appropriately for the package, for
example perhaps "/etc/odbcinst.ini.maintscript-temp" analogous to dpkg's
.dpkg-old and so on.

smcv

Bug#1038149: libmemcached-dev missing depends (recommends?) on libssl-dev for libcrypto.pc

[Tianon Gravi]

Package: libmemcached-dev
Version: 1.1.4-1
Severity: normal
X-Debbugs-Cc: tia...@debian.org

Dear Maintainer,

When running `pkg-config --exists libmemcached` after installing
libmemcached-dev, it returns a non-zero exit code.  When I run strace on
it, I can see that it's looking for libcrypto.pc.

The package currently has "libsasl2-dev" in Depends, which appears to
have a similar relationship declaration in "libmemcached.pc" to the (new
in libmemcached 1.1) relationship to "libcrypto", which makes me thing a
new Depends relationship here is appropriate, but I don't feel strongly
about it either way and think Recommends would be acceptable too. :)


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

Kernel: Linux 5.10.0-23-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages libmemcached-dev depends on:
ii  libhashkit-dev 1.1.4-1
ii  libmemcached11 1.1.4-1
ii  libmemcachedutil2  1.1.4-1
ii  libsasl2-dev   2.1.28+dfsg-10

libmemcached-dev recommends no packages.

libmemcached-dev suggests no packages.

-- no debconf information

Bug#1038148: aardvark-dns: FTBFS with new rust-async-broadcast.

[Peter Green]

Package: aardvark-dns
Version: 1.4.0-3
Severity: serious

rust-async-broadcast was recently updated to 0.5, the Debian dependencies
of aardvark-dns allow the new version but the cargo dependencies do not.
So the package FTBFS

When I removed the upper limit from the Cargo dependency the package built
successfully.

Debdiff attatched, I may or may not NMU this later.diff -Nru aardvark-dns-1.4.0/debian/changelog 
aardvark-dns-1.4.0/debian/changelog
--- aardvark-dns-1.4.0/debian/changelog 2023-01-15 07:05:56.0 +
+++ aardvark-dns-1.4.0/debian/changelog 2023-06-15 17:16:42.0 +
@@ -1,3 +1,10 @@
+aardvark-dns (1.4.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove upper limit from cargo dependency on async-broadcast.
+
+ -- Peter Michael Green   Thu, 15 Jun 2023 17:16:42 +
+
 aardvark-dns (1.4.0-3) unstable; urgency=medium
 
   [ Peter Green ]
diff -Nru aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 
aardvark-dns-1.4.0/debian/patches/update-dependencies.patch
--- aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 2023-01-15 
07:05:56.0 +
+++ aardvark-dns-1.4.0/debian/patches/update-dependencies.patch 2023-06-15 
17:16:38.0 +
@@ -1,7 +1,7 @@
-Index: aardvark-dns/Cargo.toml
+Index: aardvark-dns-1.4.0/Cargo.toml
 ===
 aardvark-dns.orig/Cargo.toml
-+++ aardvark-dns/Cargo.toml
+--- aardvark-dns-1.4.0.orig/Cargo.toml
 aardvark-dns-1.4.0/Cargo.toml
 @@ -14,19 +14,19 @@ exclude = ["/.cirrus.yml", "/.github/*"]
  # See more keys and their definitions at 
https://doc.rust-lang.org/cargo/reference/manifest.html
  
@@ -21,7 +21,8 @@
 +futures-util = { version = "0.3", default-features = false }
  signal-hook = "0.3.13"
  tokio = { version = "1.21.2", features = ["macros", "rt-multi-thread", "net"] 
}
- async-broadcast = "0.4.1"
+-async-broadcast = "0.4.1"
++async-broadcast = ">= 0.4.1"
  resolv-conf = "0.7.0"
 -nix = "0.25.0"
 +nix = "0.26"

Bug#996433: transmission-daemon: Transmission fails to send mail using exim4

[JT Hundley]

I have no idea. I assume upgrading transmission wouldn't ask me to keep an
older file here and I did not modify any of these files until I ran into
the issue. I did that test on a fresh install which rules out me messing up
the files :)
Also, I'm not sure how I missed your email about this, sorry about that.
I'm not sure if this bug is still present in the current stable version. I
found this ticket after looking to make a new one for transmission in
Debian 12.

On Wed, 13 Oct 2021 22:16:52 -0400 Sandro Tosi  wrote:
> control: tags -1 +moreinfo
>
> > It seems that this bug is caused by this change in Transmission:
https://github.com/transmission/transmission/pull/795
> > After changing my
> > /etc/systemd/system/multi-user.target.wants/transmission-daemon.service
> > to read "NoNewPrivileges=false" instead of true and reloading the
> > service and daemon, I find that transmission is properly sending emails
> > again.
>
> this is weird: that PR is included in the 3.00 release provided in
> debian, and infact the file
> /lib/systemd/system/transmission-daemon.service includes the PR
> change; how did you get that outdated file in /etc/systemd/system/ ?
>
> --
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi
>
>

Bug#1037980: [Bug#1037980] Description of my bug

[JT Hundley]

I've noticed the same behavior. I upgraded from Debian 11 to 12 and
transmission-daemon memory usage just goes up and up until my system starts
swapping hard and becomes unresponsive. This morning I caught it in the act
and saw it using 90% of 16G RAM. At some points, I noticed that
transmission-daemon was no longer running and I assumed that it had stopped
starting at boot. Now I suspect that the oom killer killed it, but I
haven't seen the oom killer in my logs. The only thing I've really done so
far is restart transmission-daemon to avoid exhausting memory. I haven't
added more torrents or changed my configuration in any way. Please let me
know what I can do or what information I can provide to help fix this
issue. Thanks!

Bug#1038146: wireplumber[…]: Failed to call Lookup: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for camera

[AlMa]

Package: wireplumber
Version: 0.4.13-1

In the depths of my log I discovered GDBus error reports:

Jun 15 04:42:15 AnonymizedMachineName wireplumber[1124]: 
GetManagedObjects() failed: org.freedesktop.DBus.Error.NameHasNoOwner
Jun 15 04:42:15 AnonymizedMachineName dbus-daemon[957]: [system] 
Successfully activated service 'org.freedesktop.UPower'
Jun 15 04:42:15 AnonymizedMachineName systemd[1]: Started upower.service 
- Daemon for power management.
Jun 15 04:42:15 AnonymizedMachineName gnome-shell[1312]: Running GNOME 
Shell (using mutter 43.4) as a X11 window and compositing manager
Jun 15 04:42:15 AnonymizedMachineName pipewire[1122]: spa.v4l2: 
'/dev/video4' VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL (I/O-Control) 
für das Gerät
Jun 15 04:42:15 AnonymizedMachineName pipewire[1122]: spa.v4l2: 
'/dev/video4' VIDIOC_ENUM_FRAMESIZES: Unpassender IOCTL (I/O-Control) 
für das Gerät
Jun 15 04:42:15 AnonymizedMachineName dbus-daemon[1129]: [session 
uid=119 pid=1129] Activating via systemd: service 
name='org.freedesktop.impl.portal.PermissionStore' 
unit='xdg-permission-store.service' requested by ':1.9' (uid=119 
pid=1124 comm="/usr/bin/wireplumber")
Jun 15 04:42:15 AnonymizedMachineName systemd[1083]: Starting 
xdg-permission-store.service - sandboxed app permission store...
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): EDID vendor "PHL", prod id 2374
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Using EDID range info for horizontal sync
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Using EDID range info for vertical refresh
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Printing DDC gathered Modelines:
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "2560x1440"x0.0  241.50  2560 2608 2640 2720 
1440 1443 1448 1481 +hsync +vsync (88.8 kHz eP)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "2560x1440"x0.0  296.00  2560 2568 2600 2666 
1440 1443 1448 1481 +hsync -vsync (111.0 kHz e)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "1920x1080"x0.0  174.50  1920 1968 2000 2080 
1080 1083 1088 1119 +hsync -vsync (83.9 kHz e)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "1920x1080"x0.0  148.50  1920 2008 2052 2200 
1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "640x480"x0.0   25.18  640 656 752 800  480 
490 492 525 -hsync -vsync (31.5 kHz e)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "720x480"x0.0   27.00  720 736 798 858  480 
489 495 525 -hsync -vsync (31.5 kHz e)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "1920x1080i"x0.0   74.25  1920 2008 2052 2200 
1080 1084 1094 1125 interlace +hsync +vsync (33.8 kHz e)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "1920x1080i"x0.0   74.25  1920 2448 2492 2640 
1080 1084 1094 1125 interlace +hsync +vsync (28.1 kHz e)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "1280x720"x0.0   74.25  1280 1390 1430 1650 
720 725 730 750 +hsync +vsync (45.0 kHz e)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "1280x720"x0.0   74.25  1280 1720 1760 1980 
720 725 730 750 +hsync +vsync (37.5 kHz e)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "1920x1080"x0.0  148.50  1920 2448 2492 2640 
1080 1084 1089 1125 +hsync +vsync (56.2 kHz e)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "720x576"x0.0   27.00  720 732 796 864  576 
581 586 625 -hsync -vsync (31.2 kHz e)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 
601 605 628 +hsync +vsync (37.9 kHz e)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "800x600"x0.0   36.00  800 824 896 1024  600 
601 603 625 +hsync +vsync (35.2 kHz e)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 
481 484 500 -hsync -vsync (37.5 kHz e)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "640x480"x0.0   31.50  640 664 704 832  480 
489 492 520 -hsync -vsync (37.9 kHz e)
Jun 15 04:42:15 AnonymizedMachineName /usr/libexec/gdm-x-session[1128]: 
(II) modeset(0): Modeline "640x480"x0.0   30.24  640 704 768 864  480 
483 486 525 -hsync 

Bug#755956: fixed

[Jeremy Sowden]

Control: fixed -1 1.2.3-1

Fixed upstream in 1.2.3:

  
http://git.netfilter.org/libnftnl/commit/?id=84d12cfacf8ddd857a09435f3d982ab6250d250c

J.


signature.asc
Description: PGP signature

Bug#1028910: wlroots: Please fix in stable - Invalid WLR_RENDERER value: "vulkan"

[Andrea Pappacoda]

Source: wlroots
Version: 0.15.1-6
Followup-For: Bug #1028910

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all, could you please consider backporting the fix into bookworm? While
Jinesh reported this as severity "normal", this missing renderer creates
serious flickering on Sway when the nvidia-driver package is installed, making
its usage frustrating at best.

I'm only a DM, so I can't do this myself, unfortunately.

Thanks for your work!


- -- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

-BEGIN PGP SIGNATURE-

iIoEARYIADIWIQS6VuNIvZRFHt7JcAdKkgiiRVB3pwUCZIuCexQcYW5kcmVhQHBh
cHBhY29kYS5pdAAKCRBKkgiiRVB3px2yAQDCB9I7ukp2O0TRXm/7+jOAZfg6WC2k
+qhkPFf0EUbtzAEAziFSGAX/AqC9J9nGhf97f2GcL9Eh2mSmCyIH1wRTMQc=
=FKtc
-END PGP SIGNATURE-

Bug#1038145: cgreen: FTBFS on s390x

[Steve Langasek]

Source: cgreen
Version: 1.5.1-1
Severity: serious
Justification: ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic

Dear maintainers,

cgreen > 1.4.1-1 fails to build from source on s390x:

[...]
Total Test time (real) =   3.57 sec

The following tests FAILED:
  3 - runner_test_cgreen_c (Failed)
  6 - runner_test_cgreen_cpp (Failed)
Errors while running CTest
Output from these tests are in: 
/<>/build/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely.
make[2]: *** [Makefile:33: test] Error 8
[...]

  
(https://buildd.debian.org/status/fetch.php?pkg=cgreen=s390x=1.5.1-1=1681718579=0)

This is a regression in architecture coverage, so will block the package
from testing until fixed or you get the ftp team to remove the old binaries.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1028602: transition: gnustep-base, gnustep-gui

[Sebastian Ramacher]

Control: tags -1 = confirmed

On 2023-01-13 15:15:10 +0200, Yavor Doganov wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: pkg-gnustep-maintain...@lists.alioth.debian.org
> Control: affects -1 + src:gnustep-base src:gnustep-gui
> 
> Dear Release team,
> 
> We would like your permission to carry out a GNUstep transition (two
> libraries simultaneously with one round of binNMUs):
> 
>   libgnustep-base1.28 -> 1.29
>   libgnustep-gui0.29  -> 0.30

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1037286: transition: libcamera 0.0.5

[Sebastian Ramacher]

Control: tags -1 confirm

On 2023-06-10 10:25:29 +0200, Dylan Aïssi wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> Please schedule a transition slot for libcamera 0.0.5.
> 
> The auto-generated ben tracker looks good:
> https://release.debian.org/transitions/html/auto-libcamera.html
> 
> The unique reverse dep (pipewire 0.3.71-1) builds fine with the
> new libcamera in experimental.

Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1038144: plaintext password get's written to the log in case of a postgres connection failure

[Markus Ziehe]

Package: pmacct
Version: 1.7.6-2
Severity: important

If pmacct cannot connect to the PostgreSQL database for whatever reason, 
pmacct writes the credentials in plain text to the log.


A bugfix has already been submitted to the official repository on GitHub 
by me as a merge request and accepted.


Now it just needs to be merged into the Debian version in the official 
Debian repositories.


Link to GitHub: https://github.com/pmacct/pmacct/pull/693

Bug#1037453: libmail-dmarc-perl: FTBFS with test failures when there's no network

[Noah Meyerhans]

Control: tags -1 + pending


On 6/12/2023 8:58 PM, Steve Langasek wrote:

I've applied the attached (very dirty) patch to libmail-dmarc-perl in
Ubuntu, which is sufficient to let the package build in Launchpad.  Having
looked at some of the surrounding tests, I'm not sure this would let the
package build in a completely offline environment - I think Launchpad
provides name resolution of a limited subset of domains, so some tests which
pass in Launchpad may also fail when offline.


Thanks. It seems to build in a completely disconnected environment with 
your patch applied, so let's start with it.

Bug#1012608: ITP: manim-ce -- Animation engine for explanatory math videos

[Timo Röhling]

As an update on this ITP, the last remaining blocker for this
ITP is the skia-pathops dependency. I intend to convince
upstream to use pyclipper instead.

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


signature.asc
Description: PGP signature

Bug#1038143: eprosima-idl-parser: new dependency openjdk-nashorn

[Timo Röhling]

Source: eprosima-idl-parser
Severity: wishlist
Control: block -1 by 1038142

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Starting with release 1.5.0, the IDL parser gained some expression
evaluation capabilities. Unfortunately, JDK 15+ no longer ship with the
Nashorn JavaScript Engine which is used to evaluate the math expressions.


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSLfw0ACgkQ+C8H+466
LVlW+gv/aAxxa6Wlp6XySiFcPetHdYpOvgkdvG3ZhSSYtX1XY+0PkfdAja9uZHJd
QfulZ77PEYGPwvpdjzO0CgBWCswrgRWeDemcoCU1gseUEBDLDiumJOqKzAFHik43
YQ2WeBo/AmgMPu3fGZeMxjY0FKy5KX4VG6P6UUBdxzW2g1INRWDqMS1m/2OqgsPe
ffSkIgmywsndLIvSKoun4rpfDpy/btteqNQW2qwd8Bld+zlyt/kskNOexeSXlS/h
PzmxCW5sn35YPKHGHg+Clof/x9B0+l14Rgt/4Ud5+af0wcglqyYQiT/2cMSPat4U
rk0PoYKvFiyRQywHYPx0B+ddTpwWozhjrfEoQ9J8rKc8L8kauCetBYbAAcUrbnm0
kst/seywzHpdolSPmoZng3CXn2kQSY+ppM90Bb0A1e2zn/gMCt+pWaCfNOS3JCEJ
m8ExTiU2mjcj4HH1uk9DOi0TW/aJetWOPKQdA1ixL2ME3x8vLUUJqxi0wPlp1X7W
iILPnHIF
=7bFu
-END PGP SIGNATURE-

Bug#1038142: RFP: openjdk-nashorn -- Standalone ECMAScript Nashorn Engine

[Timo Röhling]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-j...@lists.debian.org, team+robot...@tracker.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: openjdk-nashorn
  Version : 15.4
  Upstream Contact: Attila Szegedi
* URL : https://github.com/openjdk/nashorn
* License : GPL-2.0-only WITH Classpath-exception-2.0
  Programming Lang: Java
  Description : Standalone ECMAScript Engine for OpenJDK

Nashorn engine is an open source implementation of the ECMAScript
Edition 5.1 Language Specification. It also implements many new features
introduced in ECMAScript 6 including template strings; let, const, and
block scope; iterators and for..of loops; Map, Set, WeakMap, and WeakSet
data types; symbols; and binary and octal literals. It is written in
Java and runs on the Java Virtual Machine.

Nashorn used to be part of the JDK until Java 14. This project provides
a standalone version of Nashorn suitable for use with Java 11 and later.


This is a new dependency of src:eprosima-idl-parser, but I hope it is
generally useful for the Debian Java ecosystem. I would package it
myself, but I have limited Java packaging experience and I'm feeling out
of my depth.


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmSLfQsACgkQ+C8H+466
LVnoKwv8C9edyWnAkw9YmQmdPepXK0EOi8RN49jwIYN974SNh7PLKBKpHX789J/o
3TWzfRQTiKb6whTvJ+sKd8TN5Kb3dAjoDqQACCfDI4AwJ+jYBXz19zxuXBGYOQr/
a8wZF7W3UN5iuKVIhvaCXyF9moWvwNGfafrwP7Rzga+zGIjUcEAfZw1CFZrONco9
FsO0KJSKkZKilmT+dyFXVx6Y93L3JtNg85Nz0QbY+3hIl7wSkMYi2Le18BZ1FeXs
5o3Cr/y5ZhJYTLDL1NLCs3X2/CEFzYPCv6kfGWYJBxNoQqBN12m+SLkxV4ukE4Bl
py3nOkpLMRl/LedwVQYevUnl6w0GMgs5ooiMxMPiOW5KNgBaaW3/jGgAGHxtJBxE
qQ/IZzqb7QcmxLT4EmdbGBJFhXwyabeXDL/dX2gcjg4vsq8Vt3d2HyzqZ0tcr0St
R4HnSZp1LWCJ80t5HeM4kPUTiZt3LZszLMqwj/2rCpVsYKiu2Y9HLj+ssRGVye/z
LrGGUpFQ
=1qvc
-END PGP SIGNATURE-

Bug#1038141: xfce4-power-manager: display repeatedly turns on then off every 20 seconds once blank after time is reached

[Scott Lair]

Package: xfce4-power-manager
Version: 4.18.1-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Upgrade from bullseye to bookworm

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

Tried upgrading to latest xfce4-power-manager in sid.

Tried downgrading to latest version in bullseye.

   * What was the outcome of this action?

Same result

   * What outcome did you expect instead?

Display should power off after specified time (10 minutes by default) and 
remain off. Currently, the display
will turn off, then turn back on in about 25 seconds, display only a black 
screen, then turn back off. This 
repeats every 25 seconds or so.



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

Kernel: Linux 6.1.0-9-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

Versions of packages xfce4-power-manager depends on:
ii  libc6 2.36-9
ii  libcairo-gobject2 1.16.0-7
ii  libcairo2 1.16.0-7
ii  libglib2.0-0  2.74.6-2
ii  libgtk-3-03.24.37-2
ii  libnotify40.8.1-1
ii  libpango-1.0-01.50.12+ds-1
ii  libpangocairo-1.0-0   1.50.12+ds-1
ii  libupower-glib3   0.99.20-2
ii  libx11-6  2:1.8.4-2
ii  libxext6  2:1.3.4-1+b1
ii  libxfce4ui-2-04.18.4-1
ii  libxfce4util7 4.18.1-2
ii  libxfconf-0-3 4.18.0-2
ii  libxrandr22:1.5.2-2+b1
ii  upower0.99.20-2
ii  xfce4-power-manager-data  4.18.1-1

Versions of packages xfce4-power-manager recommends:
ii  libpam-systemd [logind]  252.6-1
ii  xfce4-power-manager-plugins  4.18.1-1

xfce4-power-manager suggests no packages.

-- no debconf information

Bug#1038140: bookworm-pu: package onionshare/2.6-5

[Hefee]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: onionsh...@packages.debian.org, 
pkg-privacy-maintain...@alioth-lists.debian.net, he...@debian.org
Control: affects -1 + src:onionshare

[ Reason ]
The version 2.6-4 does not install icons, desktop file and appstream metadata 
file at the
correct place (Closes: #1036691).  So users can only run onionshare via 
commandline.

[ Tests ]
Autopkgtests make sure, that the main parts of the package are still
functioning. Manual tests, that onionshare is listed in desktop menu and
that it has the correct icon. Same version is installed in sid.

[ Risks ]
No real risks, as it is only installing some files to correct places.

[ 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


Do I need to do update the version with a stable extension ~deb12u1 as there 
won't be any diff?
diff -Nru onionshare-2.6/debian/changelog onionshare-2.6/debian/changelog
--- onionshare-2.6/debian/changelog 2023-05-05 14:41:35.0 +0200
+++ onionshare-2.6/debian/changelog 2023-06-13 12:23:22.0 +0200
@@ -1,3 +1,10 @@
+onionshare (2.6-5) unstable; urgency=medium
+
+  * Install desktp/appmetadata at expected places. (Closes: #1036691)
+  * Install icons under usr/share/icons.
+
+ -- Sandro Knauß   Tue, 13 Jun 2023 12:23:22 +0200
+
 onionshare (2.6-4) unstable; urgency=medium
 
   * Mark chat-server test as flaky, as it fails on i386 also randomly.
diff -Nru onionshare-2.6/debian/rules onionshare-2.6/debian/rules
--- onionshare-2.6/debian/rules 2022-12-22 14:32:13.0 +0100
+++ onionshare-2.6/debian/rules 2023-06-06 21:21:03.0 +0200
@@ -4,6 +4,8 @@
 %:
dh $@ --buildsystem=pybuild
 
+SIZES = 16 32 64 128 256 512
+
 override_dh_auto_build:
PYBUILD_NAME=onionshare-cli dh_auto_build --buildsystem=pybuild 
--sourcedirectory cli --\
--after-build "CURDIR=$(CURDIR) BUILD_DIR={build_dir} 
$(CURDIR)/debian/missing-sources/uglifyjs.sh"
@@ -24,8 +26,22 @@
rm debian/onionshare/usr/bin/onionshare-cli
 
 execute_after_dh_auto_install:
-   mkdir -p debian/onionshare/usr/share
+   mkdir -p debian/onionshare/usr/share/metainfo
+   cp desktop/org.onionshare.OnionShare.appdata.xml 
debian/onionshare/usr/share/metainfo/
+   mkdir -p debian/onionshare/usr/share/applications
+   cp desktop/org.onionshare.OnionShare.desktop 
debian/onionshare/usr/share/applications/
+   
mv 
debian/onionshare/usr/lib/python3*/dist-packages/onionshare/resources 
debian/onionshare/usr/share/onionshare
+   
+   # Move icons to the places where they are searched
+   mkdir -p debian/onionshare/usr/share/icons/hicolor/scalable/apps
+   cp desktop/org.onionshare.OnionShare.svg 
debian/onionshare/usr/share/icons/hicolor/scalable/apps/
+   $(foreach size,$(SIZES), \
+   mkdir debian/onionshare/usr/share/icons/hicolor/$(size)x$(size); \
+   mv debian/onionshare/usr/share/onionshare/onionshare-$(size).png 
debian/onionshare/usr/share/icons/hicolor/$(size)x$(size)/org.onionshare.OnionShare.png;
 \
+   ln -s 
/usr/share/icons/hicolor/$(size)x$(size)/org.onionshare.OnionShare.png 
debian/onionshare/usr/share/onionshare/onionshare-$(size).png; \
+   ) true
+   
mkdir -p debian/onionshare-cli/usr/share
mv 
debian/onionshare-cli/usr/lib/python3*/dist-packages/onionshare_cli/resources 
debian/onionshare-cli/usr/share/onionshare-cli
 

Bug#1038139: debci-worker: Process leaks authentication data via amqp-tools

[Christian Kastner]

Package: debci
Version: 3.6
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 

Hi,

When using authentication in AMQP connections, the username and password
supplied in the --url option to amqp-consume resp. amqp-publish are
exposed in the proces list, see #1037322:

  $ pgrep -a ampq-consume
  62287 amqp-consume --url amqp://user:pass@192.168.0.1 --queue=myqueue

A patch has been accepted upstream to read the username and password
from a file. I assume this will make its way into ampq-tools soon.

Unless I'm mistaken, debci will need to be updated for this, e.g. by
adding a debci_amqp_pwfile config option + NEWS entry suggesting that
people migrate to this new option. I'd be happy to file an MR for this,
once ampq-tools has been fixed.

Best,
Christian


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

Kernel: Linux 6.1.0-0.deb11.7-amd64 (SMP w/24 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 debci depends on:
ii  adduser 3.118
pn  amqp-tools  
ii  curl7.88.1-7~bpo11+2
ii  dctrl-tools 2.24-3+b1
ii  debian-archive-keyring  2021.1.1+deb11u1
ii  debootstrap 1.0.128+nmu2~bpo11+1
ii  devscripts  2.22.2~bpo11+1
pn  distro-info 
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4.1
ii  jq  1.6-2.1
ii  libjs-bootstrap 3.4.1+dfsg-2
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
pn  libjs-jquery-flot   
pn  moreutils   
ii  netcat-openbsd  1.217-3
pn  parallel
ii  patchutils  0.4.2-1
pn  retry   
ii  rsync   3.2.7-1~bpo11+1
ii  ruby1:2.7+2
pn  ruby-activerecord   
pn  ruby-bunny  
pn  ruby-erubi  
pn  ruby-kaminari-activerecord  
pn  ruby-pg 
pn  ruby-sinatra
pn  ruby-sinatra-contrib
pn  ruby-sqlite3
pn  ruby-thor   
pn  sudo

Versions of packages debci recommends:
ii  systemd-timesyncd [time-daemon]  252.5-2~bpo11+1

Versions of packages debci suggests:
pn  apt-cacher-ng  

Bug#1038138: rust-diesel: FTBFS in unstable

[Steve Langasek]

Source: rust-diesel
Version: 2.0.3-1
Severity: serious
Justification: FTBFS
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic

Dear maintainers,

In trying to rebuild rust-diesel with the fix for bug #1038135, I've
discovered the package now fails to build from source in both Debian
unstable and Ubuntu mantic:

[...]
error[E0277]: the trait bound `FieldAttr: ToTokens` is not satisfied
   --> 
/<>/debian/cargo_registry/diesel_derives-2.0.1/src/attrs.rs:143:6
|
143 | impl Spanned for FieldAttr {
|  ^^^ the trait `ToTokens` is not implemented for `FieldAttr`
|
= help: the following other types implement trait `ToTokens`:
  &'a T
  &'a mut T
  Abi
  Abstract
  AndAnd
  AndEq
  AngleBracketedGenericArguments
  As
and 243 others
= note: required for `FieldAttr` to implement 
`quote::spanned::private::Sealed`
note: required by a bound in `quote::spanned::Spanned`
   --> /<>/debian/cargo_registry/quote-1.0.27/src/spanned.rs:6:20
|
6   | pub trait Spanned: private::Sealed {
|^^^ required by this bound in 
`quote::spanned::Spanned`

error[E0277]: the trait bound `StructAttr: ToTokens` is not satisfied
   --> 
/<>/debian/cargo_registry/diesel_derives-2.0.1/src/attrs.rs:242:6
|
242 | impl Spanned for StructAttr {
|  ^^^ the trait `ToTokens` is not implemented for `StructAttr`
|
= help: the following other types implement trait `ToTokens`:
  &'a T
  &'a mut T
  Abi
  Abstract
  AndAnd
  AndEq
  AngleBracketedGenericArguments
  As
and 243 others
= note: required for `StructAttr` to implement 
`quote::spanned::private::Sealed`
note: required by a bound in `quote::spanned::Spanned`
   --> /<>/debian/cargo_registry/quote-1.0.27/src/spanned.rs:6:20
|
6   | pub trait Spanned: private::Sealed {
|^^^ required by this bound in 
`quote::spanned::Spanned`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `diesel_derives` due to 2 previous errors
[...]

  
(https://launchpad.net/ubuntu/+source/rust-diesel/2.0.3-1ubuntu1/+build/26310394)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1038137: accountsservice: unit requires /usr/share/accountsservice/interfaces but it is not installed

[Luca Boccassi]

Package: accountsservice
Version: 22.08.8-6
Severity: important

Dear Maintainer(s),

accountsservice's unit has:

ReadOnlyPaths=\
  /usr/share/accountsservice/interfaces/ \
  /usr/share/dbus-1/interfaces/ \
  /var/log/wtmp \
  /run/systemd/seats/

But at least /usr/share/accountsservice/interfaces/ is not installed by
the package itself. As far as I can see on my machine, the malcontent
package installs files under it.

This means that on systemd's autopkgtest it fails to start. The
solution is very simple, just prefix each path listed there with "-" to
make it optional - if the directory exists on the host then it will be
made read-only, otherwise it will be ignored.

test_no_failed (__main__.ServicesTest.test_no_failed)
No failed units ...  journal for failed service accounts-daemon.service 
---
Jun 15 15:53:38 autopkgtest-lxc-cerudb systemd[1]: Starting Accounts Service...
Jun 15 15:53:38 autopkgtest-lxc-cerudb (s-daemon)[95]: accounts-daemon.service: 
Failed to set up mount namespacing: 
/run/systemd/mount-rootfs/usr/share/accountsservice/interfaces: No such file or 
directory
Jun 15 15:53:38 autopkgtest-lxc-cerudb (s-daemon)[95]: accounts-daemon.service: 
Failed at step NAMESPACE spawning /usr/libexec/accounts-daemon: No such file or 
directory
Jun 15 15:53:38 autopkgtest-lxc-cerudb systemd[1]: accounts-daemon.service: 
Main process exited, code=exited, status=226/NAMESPACE
Jun 15 15:53:38 autopkgtest-lxc-cerudb systemd[1]: accounts-daemon.service: 
Failed with result 'exit-code'.
Jun 15 15:53:38 autopkgtest-lxc-cerudb systemd[1]: Failed to start Accounts 
Service.
FAIL

-- 
Kind regards,
Luca Boccassi


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

Bug#1038136: RFS: budgie-backgrounds/1.0-1 [ITP] -- Default set of background images for the Budgie Desktop

[David Mohammed]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "budgie-backgrounds":

 * Package name : budgie-backgrounds
   Version  : 1.0-1
   Upstream contact : Budgie Developers 
 * URL  : https://github.com/buddiesofbudgie/budgie-backgrounds
 * License  : CC0-1.0
 * Vcs  :
https://github.com/ubuntubudgie/budgie-backgrounds/tree/debian
   Section  : misc

The source builds the following binary packages:

  budgie-backgrounds - Default set of background images for the Budgie Desktop

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

  https://mentors.debian.net/package/budgie-backgrounds/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/budgie-backgrounds/budgie-backgrounds_1.0-1.dsc

More Information:
I am the Debian Maintainer of the budgie-desktop and almost all of the
budgie-related packages contained in the archive.  I am also a team
member of the upstream budgie project github.com/buddiesofbudgie

Upstream have released a v1.0 of budgie-backgrounds.  This is intended
for all downstream projects to showcase budgie-desktop.

My future intention is to include this package as part of a wider
effort to provide Debian a first class introduction of budgie using
upstream budgie artifacts through a to-be-uploaded
"budgie-desktop-environment" in a similar way as the downstream Ubuntu
Budgie project (I am the project lead for this).  This will ensure a
consistent backgrounds, fonts, gtk style, icons etc rather than the
existing bare-bones budgie-desktop package.

Changes for the initial release:

 budgie-backgrounds (1.0-1) unstable; urgency=medium
 .
   * Initial Release (Closes: #1037965)

Regards,
-- 
  David Mohammed

Bug#1038135: rust-diesel: librust-diesel-dev uninstallable on 32-bit archs

[Steve Langasek]

Package: rust-diesel
Version: 2.0.3-1
Severity: serious
Tags: patch
Justification: uninstallable
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu mantic ubuntu-patch

Dear maintainers,

rust-diesel is not migrating to Debian testing because it depends on
librust-pq-sys-dev and librust-mysqlclient-sys-dev, neither of which is
buildable on 32-bit archs; but it does not build-depend on these packages,
so librust-diesel-dev builds uninstallable binary packages.

Either rust-diesel should build-depend on these packages so that binaries
are not built on architectures where they're unavailable, or the
dependencies should be relaxed so that the packages are installable.

For the moment, I've opted for the first of these in Ubuntu.  See attached
patch.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru rust-diesel-2.0.3/debian/control rust-diesel-2.0.3/debian/control
--- rust-diesel-2.0.3/debian/control2023-02-10 03:05:35.0 -0800
+++ rust-diesel-2.0.3/debian/control2023-06-15 13:22:18.0 -0700
@@ -8,7 +8,9 @@
  libstd-rust-dev ,
  librust-diesel-derives-2.0+32-column-tables-dev ,
  librust-diesel-derives-2.0+default-dev ,
- librust-diesel-derives-2.0+with-deprecated-dev 
+ librust-diesel-derives-2.0+with-deprecated-dev ,
+ librust-pq-sys-dev,
+ librust-mysqlclient-sys-dev
 Maintainer: Debian Rust Maintainers 

 Uploaders:
  kpcyrd ,

Bug#1037974: ddcci-dkms: code fails to build and package fails to install with Linux 6.3 headers

[Stephen Kitt]

Hi Paul,

On Thu, 15 Jun 2023 10:32:56 +0800, Paul Wise  wrote:
> When I try to install ddcci-dkms with the Linux 6.3 headers installed,
> the build of the code fails and then the install of the package fails.
> 
> I think there are two problems here:
> 
>  * The code needs to be adapted to the latest Linux kernel version.

I’ve applied candidate patches from the upstream repo to handle up to 6.4.

>  * The package should not fail to install when the module build fails.
>    This might be a problem in dkms itself, or in ddcci's integration.

This is the more interesting issue, but see #1029063. Admittedly the absence
of a ddcci module is unlikely to ever prevent a system from booting, so
perhaps we could have a way of telling dkms that build failures in a given
module shouldn’t be treated as errors. Andreas, what do you think?

Regards,

Stephen


pgpNUPqVo_amU.pgp
Description: OpenPGP digital signature

Bug#1036528: zutils: leftover conffiles

[Christoph Anton Mitterer]

Hey Daniel.

On Tue, 2023-06-13 at 07:45 +0200, Daniel Baumann wrote:
> thank you for your report, this has been fixed in 1.12-2:
> 
> https://git.progress-linux.org/users/daniel.baumann/debian/packages/zutils/commit/?id=4596dac645e794ca9153e92a99d176dfc357c2ce
> 
> I've confirmed that when upgrading from previous versions, with the
> installation of zutils 1.12-2, /etc/zutils gets removed:

Well there must have been at least one version release the where it
wasn't set properly, because otherwise I couldn't have seen the file as
obsolete conffile on my system :-)

I had only a short glance on it now, but AFAICs:

1.12~rc1-1 was the version that had the file dropped as conffile (but
   not cleaned up
1.12-1 hadn't fixed it either
1.12-2 removed the conffile, but with 1.12-1~


AFAIU the dpkg-maintscript-helper manpage, this means that anyone who
had installed 1.12-1 won't have the file ever cleaned up, as 1.12-1~
won't trigger it.

Instead, if you upload e.g. in the future 1.12-3, you'd need to use
1.12-3~ as version.


Cheers,
Chris.

Bug#1037198: locales: please parallelise locale-gen

[наб]

Hi!

On Thu, Jun 15, 2023 at 09:26:43PM +0200, Aurelien Jarno wrote:
> On 2023-06-07 16:04, наб wrote:
> > Posting as a bug per comment from Andrej; originally posted 2022-05-06 as
> >   https://salsa.debian.org/glibc-team/glibc/-/merge_requests/7
> > 
> > Patch based on current Salsa HEAD attached, incl. analysis.
> 
> Thanks for the patch. I looks good, I have a comment though.
> > MemFree: in /proc/meminfo is available on all supported Debian kernels,
> > and, indeed, exactly what procps free(1) uses
> What is the reason to use MemFree instead of MemAvailable.
That's what procps free(1) used, and all Debian kernels 
(kFreeBSD, Hurd, Linux) supported it.

> The Linux
> kernel tends to maintain MemFree close to 0 by using the free RAM as
> cache. MemAvailable also includes reclaimable memory blocks like cache
> or inactive pages and therefore sounds better suited.
Since I first posted this, procps free(1) started using MemAvailable to
evaluate free/used, so sure. I don't feel strongly either way.

A Hurd image from 2021 I have (bullseye branding) and the 2023 release
(bookworm branding) don't have MemAvailable, neither does kFreeBSD 10
(from the 2017 installer ISO; appears to be the latest from
 https://wiki.debian.org/Debian_GNU/kFreeBSD).

I've updated the Salsa revision and am including an updated patch here,
which overrides MemFree with MemAvailable if available.

Best,
наб
From d64e6b551948726dbe5cc6800e93a2d7b25d3f89 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Fri, 6 May 2022 01:22:10 +0200
Subject: [PATCH] Parallelise locale-gen if possible
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Mutt-PGP: OS

Assuming a very generous 200M free/localedef (because I saw a max RSS
of 147M w/time(1)), this will attempt to keep all jobs saturated,
and usually succeed. There's little starvation, since the vast majority
of time is spent in gzip(1) ‒ 1:14 user vs 27:55 sys

At 2.2ish seconds per locale, even on a low-end system of today with
4 CPUs (and 800 free MB), we can generate up to 4 locales at once
for 6.6s' speed-up. Assuming no super-pathological cases, this globally
scales in roughly ceil(locales/ncpus)*2.2s chunks, which is a massive
win

The only user-visible change is that, with nproc>1, the output is
  en_GB.UTF-8...
  
instead of
  en_GB.UTF-8... 

MemFree: in /proc/meminfo is available on all supported Debian kernels,
MemAvailable: only on Linux; procps free(1) uses MemAvailable to
estimate "used" space where available.
---
 debian/local/usr_sbin/locale-gen | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/debian/local/usr_sbin/locale-gen b/debian/local/usr_sbin/locale-gen
index 7fa3d772..30f70f5e 100755
--- a/debian/local/usr_sbin/locale-gen
+++ b/debian/local/usr_sbin/locale-gen
@@ -23,6 +23,19 @@ is_entry_ok() {
 	fi
 }
 
+nproc="$(nproc 2>/dev/null)" || nproc=1
+if [ "$nproc" -gt 1 ]; then
+	mem_free=0
+	while read -r k v _; do
+		[ "$k" = "MemFree:"  ] && mem_free="$v"  || :
+		[ "$k" = "MemAvailable:" ] && mem_free="$v" && break || :  # Prefer using MemAvailable on Linux; other Debian kernels only have MemFree
+	done < /proc/meminfo || :
+	mem_free=$(( mem_free / 1024 / 200 ))
+	[ "$mem_free" -lt 1 ] && mem_free=1 || :
+	[ "$mem_free" -lt "$nproc" ] && nproc="$mem_free" || :
+	jobs=0; pids=
+fi 2>/dev/null
+
 echo "Generating locales (this might take a while)..."
 while read -r locale charset; do
 	if [ -z "$locale" ] || [ "${locale#\#}" != "$locale" ]; then continue; fi
@@ -35,6 +48,7 @@ while read -r locale charset; do
 	locale_at="${locale#*@}"
 	[ "$locale_at" = "$locale" ] && locale_at= || locale_at="@$locale_at"
 	printf "  %s.%s%s..." "$locale_base" "$charset" "$locale_at"
+	[ "$nproc" -gt 1 ] && echo || :
 
 	if [ -e "$USER_LOCALES/$locale" ]; then
 		input="$USER_LOCALES/$locale"
@@ -46,7 +60,20 @@ while read -r locale charset; do
 			input="$USER_LOCALES/$input"
 		fi
 	fi
-	localedef -i "$input" -c -f "$charset" -A /usr/share/locale/locale.alias "$locale" || :
-	echo " done"
+	localedef -i "$input" -c -f "$charset" -A /usr/share/locale/locale.alias "$locale" &
+	if [ "$nproc" -gt 1 ]; then
+		pids="$pids$! "
+		jobs=$(( jobs + 1 ))
+
+		if [ "$jobs" -ge "$nproc" ]; then
+			wait "${pids%% *}" || :
+			jobs=$(( jobs - 1 ))
+			pids="${pids#* }"
+		fi
+	else
+		wait
+		echo " done"
+	fi
 done < "$LOCALEGEN"
+wait
 echo "Generation complete."
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1038134: g++-12: Conditional compilation error in optimized mode

[Michael Ivanov]

Package: g++-12
Version: 12.2.0-14
Severity: normal
X-Debbugs-Cc: iv...@isle.spb.ru

Dear Maintainer,

When I compile c++ code which has an error (method invoked on
null class pointer) the following problem occurs: the actual
call does not crash, since 'this' pointer is not really used
in called method, but conditional below works incorrectly.
Here's the simplified code in question:

  else {
 np = getstr(cp);
 if (!::strcasecmp(np, "info"))
current = channel->get_class(ErrorCode::Info);
 else if (!::strcasecmp(np, "internal"))
current = channel->get_class(ErrorCode::Internal);
 . . . . . .
 else {
Log::Error("%s:%d: unrecognized error class [%s]", _fname, _lineno, 
np);
current = 0;
continue;
 }
  }

  if (!channel || !current)
 continue;

  np = getstr(cp);

channel can be 0 after first 'else', but get_class() does not crash,
since it just returns a computed pointer to array item inside the
object, so that current is set to some invalid value like 0x120.
It proceeds to the 'if (!channel || !current)' conditional and
with given values (channel == 0, current == 0x120) continue should
be executed. Instead the control falls through to the next line.

This error occurs only when the code is compiled with -O2 or -O3.
When -O0 is used, the conditional works properly. The error is
not observed when compiled with g++-11.

The error also dissappears when I fix my error (replace first
'else {' by 'else if (channel) {').

If this information is of any interest I can send combined
c++/assembly listings for cases with and without optimization.

Best regards,

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

Kernel: Linux 5.10.0-23-amd64 (SMP w/2 CPU threads)
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 g++-12 depends on:
ii  gcc-1212.2.0-14
ii  gcc-12-base   12.2.0-14
ii  libc6 2.36-9
ii  libgmp10  2:6.2.1+dfsg1-1.1
ii  libisl23  0.25-1
ii  libmpc3   1.3.1-1
ii  libmpfr6  4.2.0-1
ii  libstdc++-12-dev  12.2.0-14
ii  libzstd1  1.5.4+dfsg2-5
ii  zlib1g1:1.2.13.dfsg-1

g++-12 recommends no packages.

Versions of packages g++-12 suggests:
pn  g++-12-multilib  
pn  gcc-12-doc   

-- no debconf information

Bug#1037510: texlive-lang-japanese: dangling symlinks due to missing dependencies

[Vincent Lefevre]

Hi,

On 2023-06-15 20:40:36 +0200, Preuße, Hilmar wrote:
> Currently we just suggest these 4 packages. I propose to promote the suggest
> to recommend. Do you think that would be sufficient?

Since Recommends are installed by default, I think that this would be
sufficient (this should also probably be documented). Alternatively,
the symbolic links could be provided by the packages that contain the
files, if this makes sense.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1038133: libx11: CVE-2023-3138

[Salvatore Bonaccorso]

Source: libx11
Version: 2:1.8.4-2
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libx11.

CVE-2023-3138[0]:
| Buffer overflows in InitExt.c in libX11

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-3138
https://www.cve.org/CVERecord?id=CVE-2023-3138
[1] 
https://gitlab.freedesktop.org/xorg/lib/libx11/-/commit/304a654a0d57bf0f00d8998185f0360332cfa36c
[2] https://www.openwall.com/lists/oss-security/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1037198: locales: please parallelise locale-gen

[Aurelien Jarno]

Hi,

On 2023-06-07 16:04, наб wrote:
> Package: locales
> Version: 2.36-9
> Severity: wishlist
> Tags: patch
> 
> Dear Maintainer,
> 
> Posting as a bug per comment from Andrej; originally posted 2022-05-06 as
>   https://salsa.debian.org/glibc-team/glibc/-/merge_requests/7
> 
> Patch based on current Salsa HEAD attached, incl. analysis.

Thanks for the patch. I looks good, I have a comment though.

> MemFree: in /proc/meminfo is available on all supported Debian kernels,
> and, indeed, exactly what procps free(1) uses

What is the reason to use MemFree instead of MemAvailable. The Linux
kernel tends to maintain MemFree close to 0 by using the free RAM as
cache. MemAvailable also includes reclaimable memory blocks like cache
or inactive pages and therefore sounds better suited.

Regards
Aurelien

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


signature.asc
Description: PGP signature

Bug#1038132: qtwebengine-opensource-src: FTBFS: ../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'

[Sebastian Ramacher]

Source: qtwebengine-opensource-src
Version: 5.15.13+dfsg-1~deb12u1
Severity: serious
Tags: ftbfs sid trixie
Justification: fails to build from source (but built successfully in the past)

https://buildd.debian.org/status/fetch.php?pkg=qtwebengine-opensource-src=amd64=5.15.13%2Bdfsg-1%7Edeb12u1%2Bb1=1686790387=0

FAILED: obj/third_party/ffmpeg/ffmpeg_internal/autorename_libavcodec_flacdec.o 
/usr/bin/gcc -MMD -MF 
obj/third_party/ffmpeg/ffmpeg_internal/autorename_libavcodec_flacdec.o.d 
-DHAVE_AV_CONFIG_H -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC 
-DFFMPEG_CONFIGURATION=NULL -DCHROMIUM_NO_LOGGING -D_ISOC99_SOURCE 
-D_LARGEFILE_SOURCE -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 
-DOFFICIAL_BUILD -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -DNDEBUG -DNVALGRIND 
-DDYNAMIC_ANNOTATIONS_ENABLED=0 
-I../../3rdparty/chromium/third_party/ffmpeg/chromium/config/Chrome/linux/x64 
-I../../3rdparty/chromium/third_party/ffmpeg 
-I../../3rdparty/chromium/third_party/ffmpeg/compat/atomics/gcc -Igen 
-I../../3rdparty/chromium -Igen -fPIC -Wno-deprecated-declarations 
-fomit-frame-pointer -w -std=c99 -pthread -fno-math-errno -fno-signed-zeros 
-fno-tree-vectorize -fno-strict-aliasing --param=ssp-buffer-size=4 
-fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC 
-pipe -pthread -m64 -g0 -fvisibility=hidden -Wno-unused-local-typedefs 
-Wno-maybe-uninitialized -Wno-deprecated-declarations 
-fno-delete-null-pointer-checks -Wno-comments -Wno-packed-not-aligned 
-Wno-dangling-else -Wno-missing-field-initializers -Wno-unused-parameter -O2 
-fno-ident -fdata-sections -ffunction-sections -I/usr/include/opus -std=gnu11 
-c 
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/autorename_libavcodec_flacdec.c
 -o obj/third_party/ffmpeg/ffmpeg_internal/autorename_libavcodec_flacdec.o
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h: Assembler 
messages:
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:116: Error: 
operand type mismatch for `sar'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
../../3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: 
operand type mismatch for `shr'
[3608/33093] /usr/bin/gcc -MMD -MF 
obj/third_party/ffmpeg/ffmpeg_internal/autorename_libavcodec_flacdsp.o.d 
-DHAVE_AV_CONFIG_H -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC 
-DFFMPEG_CONFIGURATION=NULL -DCHROMIUM_NO_LOGGING -D_ISOC99_SOURCE 
-D_LARGEFILE_SOURCE -DUSE_UDEV -DUSE_AURA=1 -DUSE_NSS_CERTS=1 -DUSE_OZONE=1 
-DOFFICIAL_BUILD -DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -DNDEBUG -DNVALGRIND 
-DDYNAMIC_ANNOTATIONS_ENABLED=0 
-I../../3rdparty/chromium/third_party/ffmpeg/chromium/config/Chrome/linux/x64 
-I../../3rdparty/chromium/third_party/ffmpeg 
-I../../3rdparty/chromium/third_party/ffmpeg/compat/atomics/gcc -Igen 
-I../../3rdparty/chromium -Igen -fPIC -Wno-deprecated-declarations 
-fomit-frame-pointer -w -std=c99 -pthread -fno-math-errno -fno-signed-zeros 
-fno-tree-vectorize -fno-strict-aliasing --param=ssp-buffer-size=4 
-fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC 
-pipe -pthread -m64 -g0 -fvisibility=hidden -Wno-unused-local-typedefs 
-Wno-maybe-uninitialized 

Bug#1038131: qt6-webengine: FTBFS: ../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125: Error: operand type mismatch for `shr'

[Sebastian Ramacher]

Source: qt6-webengine
Version: 6.4.2-final+dfsg-1
Severity: serious
Tags: ftbfs sid trixie
Justification: fails to build from source (but built successfully in the past)

https://buildd.debian.org/status/fetch.php?pkg=qt6-webengine=amd64=6.4.2-final%2Bdfsg-1%2Bb1=1686789322=0

FAILED: obj/third_party/ffmpeg/ffmpeg_internal/flacdec.o 
/usr/bin/cc -MMD -MF obj/third_party/ffmpeg/ffmpeg_internal/flacdec.o.d 
-DHAVE_AV_CONFIG_H -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC 
-DFFMPEG_CONFIGURATION=NULL -DCHROMIUM_NO_LOGGING -D_ISOC99_SOURCE 
-D_LARGEFILE_SOURCE -DUSE_UDEV -DUSE_AURA=1 -DUSE_OZONE=1 -DOFFICIAL_BUILD 
-DTOOLKIT_QT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES 
-DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 
-I../../../../../src/3rdparty/chromium/third_party/ffmpeg/chromium/config/Chrome/linux/x64
 -I../../../../../src/3rdparty/chromium/third_party/ffmpeg -Igen 
-I../../../../../src/3rdparty/chromium -fPIC -Wno-deprecated-declarations 
-fomit-frame-pointer -w -std=c99 -pthread -fno-math-errno -fno-signed-zeros 
-fno-tree-vectorize -fno-ident -fno-strict-aliasing --param=ssp-buffer-size=4 
-fstack-protector -Wno-unknown-pragmas -Wno-parentheses -Wno-sign-compare 
-Wno-stringop-overflow -Wno-stringop-overread -Wno-psabi -Wno-multichar 
-Wno-format-zero-length -fno-unwind-tables -fno-asynchronous-unwind-tables 
-fPIC -pipe -pthread -m64 -msse3 -gdwarf-4 -g1 -fvisibility=hidden 
-Wno-unused-local-typedefs -Wno-maybe-uninitialized 
-Wno-deprecated-declarations -fno-delete-null-pointer-checks -Wno-comments 
-Wno-packed-not-aligned -Wno-dangling-else -Wno-missing-field-initializers 
-Wno-unused-parameter -O2 -fdata-sections -ffunction-sections 
-I/usr/include/opus -std=gnu11 -c 
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/flacdec.c -o 
obj/third_party/ffmpeg/ffmpeg_internal/flacdec.o
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:
 Assembler messages:
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:116:
 Error: operand type mismatch for `sar'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
../../../../../src/3rdparty/chromium/third_party/ffmpeg/libavcodec/x86/mathops.h:125:
 Error: operand type mismatch for `shr'
ninja: build stopped: subcommand failed.
FAILED: src/core/None/x86_64/QtWebEngineCore.stamp 
src/core/None/x86_64/QtWebEngineCore 
/<>/obj-x86_64-linux-gnu/src/core/None/x86_64/QtWebEngineCore.stamp
 /<>/obj-x86_64-linux-gnu/src/core/None/x86_64/QtWebEngineCore 
cd /<>/obj-x86_64-linux-gnu/src/core && /usr/bin/ninja -C 
/<>/obj-x86_64-linux-gnu/src/core/None/x86_64 QtWebEngineCore
ninja: build stopped: subcommand failed.
dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j4 -v 
returned exit code 1
make: *** [debian/rules:31: binary-arch] Error 25

Cheers
-- 
Sebastian Ramacher

Bug#1038130: debian-live: amd64 live final release breaks intramfs-tool after install nvidia-driver firmware-misc-nonfree

[Jim Bolmgren]

Package: debian-live
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
I used the Bookworm live ISO to install onto my desktop
CPU - Intel i7
MOBO - Asus Z490P
GPU - RXT 3060 
Live ISO booted with the expected Nvidia graphics issues but everything seemed 
to install OK.
Installed the ISO and rebooted. At the initial grub window I edited the file 
and added the option nomodeset and F10 to finish the boot
Wayland login didn't complete so I switched to X11 and logged in
I checked the basic functions and everything seemed to have installed 
correctly. Added NFS folders and mounted them to access my NAS file server
Web browsing was working. Other packages ran OK including the install of a 
package which completed with no errors
I followed the URL - https://wiki.debian.org/NvidiaGraphicsDrivers to add the 
nvidia-driver firmware-misc-nonfree using apt
During the install close to the end of the installation I started noticing 
couple package install errors and mainly intramfs-tools errors
Rebooted and the 525 driver worked and I could configure my three monitors 
correctly
The issue started when I tried installing additional packages with apt and at 
the end of the install there was an intramfs-tool error but
 the application would open and run however opening gparted and trying to 
format a USB drive gave ma an error saying it could not update
 the kernel and the format failed.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I followed this link - https://forums.debian.net/viewtopic.php?t=154857
Removed the two z50raspi-firmware directories and ran the apt autoremove 
--purge raspi-firmware command

   * What was the outcome of this action?
I rebooted my desktop and tried installing additional packages with no 
intramfs-tools errors and the installation seems to be working correctly.

Bug#1037052: minidlna: CVE-2023-33476

[Paul Gevers]

control: found -1 1.3.0+dfsg-2.2

Hi,

On Fri, 02 Jun 2023 23:25:09 +0200 Salvatore Bonaccorso 
 wrote:

| ReadyMedia (MiniDLNA) versions from 1.1.15 up to 1.3.2 is vulnerable
| to Buffer Overflow.


Which means the version in testing (and stable) is also affected.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036912: pipewire-pulse: same bug but sddm in KDE Plasma

[C.Ch.]

Package: pipewire-pulse
Version: 0.3.65-3
Followup-For: Bug #1036912

Dear Maintainer,

I can confirm this bug too.
The thing is.. I'm using KDE Plasma and sddm to log in not gdm.
I can confirm pipewire-pulse works as expected if you restart it with:

systemctl --user restart pipewire-pulse.service

As a workaround I had been using:

pactl load-module module-native-protocol-tcp

Which also solves the problem until next reboot.
mpd work fines using any of the workarounds.

In my case using lsof -n -i :4713 in another TTY before login produces:

COMMANDPID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
pipewire- 1523 sddm   15u  IPv4  20934  0t0  TCP *:4713 (LISTEN)
pipewire- 1523 sddm   16u  IPv6  20935  0t0  TCP *:4713 (LISTEN)


systemctl --user status pipewire-pulse.service

Produces:

pipewire-pulse.service - PipeWire PulseAudio
 Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; enabled; 
preset: enabled)
 Active: active (running) since Wed 2023-06-14 11:28:23 -05; 18min ago
TriggeredBy: ● pipewire-pulse.socket
   Main PID: 2080 (pipewire-pulse)
  Tasks: 2 (limit: 76966)
 Memory: 17.9M
CPU: 156ms
 CGroup: 
/user.slice/user-1000.slice/user@1000.service/session.slice/pipewire-pulse.service
 └─2080 /usr/bin/pipewire-pulse

Jun 14 11:28:23 harpia systemd[2061]: Started pipewire-pulse.service - PipeWire 
PulseAudio.
Jun 14 11:28:23 harpia pipewire-pulse[2080]: mod.rt: Can't find 
org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Jun 14 11:28:23 harpia pipewire-pulse[2080]: mod.rt: found session bus but no 
portal
Jun 14 11:28:23 harpia pipewire-pulse[2080]: mod.protocol-pulse: server 
0x55f739398460: bind() failed: Address already in use
Jun 14 11:28:23 harpia pipewire-pulse[2080]: mod.protocol-pulse: pulse-server 
0x55f739397bb0: failed to start server on 'tcp:0.0.0.0:4713': Address already 
in use
Jun 14 11:28:23 harpia pipewire-pulse[2080]: mod.protocol-pulse: server 
0x55f7393988b0: bind() failed: Address already in use
Jun 14 11:28:23 harpia pipewire-pulse[2080]: mod.protocol-pulse: pulse-server 
0x55f739397bb0: failed to start server on 'tcp:[::]:4713': Address already in 
use
~



Here is my /usr/share/pipewire/pipewire-pulse.conf just in case (although the 
file seems not to be involved in the bug). 


# PulseAudio config file for PipeWire version "0.3.65" #
#
# Copy and edit this file in /etc/pipewire for system-wide changes
# or in ~/.config/pipewire for local changes.
#
# It is also possible to place a file with an updated section in
# /etc/pipewire/pipewire-pulse.conf.d/ for system-wide changes or in
# ~/.config/pipewire/pipewire-pulse.conf.d/ for local changes.
#

context.properties = {
## Configure properties in the system.
#mem.warn-mlock  = false
#mem.allow-mlock = true
#mem.mlock-all   = false
#log.level   = 2

#default.clock.quantum-limit = 8192
}

context.spa-libs = {
audio.convert.* = audioconvert/libspa-audioconvert
support.*   = support/libspa-support
}

context.modules = [
{ name = libpipewire-module-rt
args = {
nice.level   = -11
#rt.prio  = 88
#rt.time.soft = -1
#rt.time.hard = -1
}
flags = [ ifexists nofail ]
}
{ name = libpipewire-module-protocol-native }
{ name = libpipewire-module-client-node }
{ name = libpipewire-module-adapter }
{ name = libpipewire-module-metadata }

{ name = libpipewire-module-protocol-pulse
args = {
# contents of pulse.properties can also be placed here
# to have config per server.
}
}
]

# Extra scripts can be started here. Setup in default.pa can be moved in
# a script or in pulse.cmd below
context.exec = [
#{ path = "pactl"args = "load-module module-always-sink" }
#{ path = "pactl"args = "upload-sample my-sample.wav my-sample" }
#{ path = "/usr/bin/sh"  args = "~/.config/pipewire/default.pw" }
]

# Extra commands can be executed here.
#   load-module : loads a module with args and flags
#  args = " "
#  flags = [ "no-fail" ]
pulse.cmd = [
{ cmd = "load-module" args = "module-always-sink" flags = [ ] }
#{ cmd = "load-module" args = "module-switch-on-connect" }
#{ cmd = "load-module" args = "module-gsettings" flags = [ "nofail" ] }
]

stream.properties = {
#node.latency  = 1024/48000
#node.autoconnect  = true
#resample.quality  = 4
#channelmix.normalize  = false
#channelmix.mix-lfe= true
#channelmix.upmix  = true
#channelmix.upmix-method = psd  # none, simple
#channelmix.lfe-cutoff = 150
#channelmix.fc-cutoff  = 12000
#channelmix.rear-delay = 12.0
#channelmix.stereo-widen = 0.0
#channelmix.hilbert-taps = 0
#dither.noise = 0
}

pulse.properties = {
# the addresses this server listens on
server.address = [
"unix:native"
#"unix:/tmp/something"  

Bug#1038129: libcurl4-openssl-dev: Static library shouldn't use krb5

[John Goerzen]

Package: libcurl4-openssl-dev
Version: 7.88.1-10
Severity: normal

Hi,

I am attempting to enable curl support in dar.  dar provides a standard binary
and dar_static, which is to be used for emergency system rescues.

Curl provides a static version (.a).  Unfortunately, curl uses gssapi_krb5,
which is not available in a static version.   The result is an inability to link
a static program (due to being unable to find the krb5 symbols referenced in
libcurl.a).

The static version of libcurl.a should, therefore, be built without krb5 
support.

Thanks,

John


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

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

Versions of packages libcurl4-openssl-dev depends on:
ii  libcurl4  7.88.1-10

libcurl4-openssl-dev recommends no packages.

Versions of packages libcurl4-openssl-dev suggests:
pn  libcurl4-doc
pn  libidn-dev  
ii  libkrb5-dev 1.20.1-2
ii  libldap-dev [libldap2-dev]  2.5.13+dfsg-5
ii  libldap2-dev2.5.13+dfsg-5
pn  librtmp-dev 
pn  libssh2-1-dev   
ii  libssl-dev  3.0.9-1
ii  pkg-config  1.8.1-1
ii  pkgconf [pkg-config]1.8.1-1
ii  zlib1g-dev  1:1.2.13.dfsg-1

-- no debconf information

Bug#1038128: libkrb5-dev: Please provide static libraries (.a)

[John Goerzen]

Package: libkrb5-dev
Version: 1.20.1-2
Severity: normal

I am attempting to enable curl support in dar.  dar provides a standard binary
and dar_static, which is to be used for emergency system rescues.

Curl provides a static version (.a).  Unfortunately, curl uses gssapi_krb5,
which is not available in a static version.The result is an inability to
link a static program.

configure supports --enable-static.  I see in the changelog that it was enabled
in Debian in version 1.4.3-5, though that was dropped since for an unknown
reason.

It looks like enable-shared and enable-static may now conflict, so it may be
necessary to build twice (as with the kmod package) to achieve this.

Thanks,

John



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

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

Versions of packages libkrb5-dev depends on:
ii  krb5-multidev  1.20.1-2

libkrb5-dev recommends no packages.

Versions of packages libkrb5-dev suggests:
pn  krb5-doc  

-- no debconf information

Bug#1038127: src:mail-expire: fails to migrate to testing for too long: uploader built binaries

[Paul Gevers]

Source: mail-expire
Version: 0.9.1
Severity: serious
Control: close -1 0.9.2
Tags: sid trixie pending
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:mail-expire has been trying to migrate for 
71 days [2]. Hence, I am filing this bug.


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.


Your package is only blocked because the arch:all binary package(s) 
aren't built on a buildd. Unfortunately the Debian infrastructure 
doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will 
shortly do a no-changes source-only upload to DELAYED/15, closing this 
bug. Please let me know if I should delay or cancel that upload.


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1038125: src:eln: fails to migrate to testing for too long: new build dependencies not available

[Paul Gevers]

Source: eln
Version: 1.4.6-1
Severity: serious
Control: close -1 1.5.0-2
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:eln has been trying to migrate for 81 days 
[2] (yes, partially because of the freeze). Hence, I am filing this bug. 
Your package started to build depend on packages not available on all 
release architectures. You probably need to request removal of your 
binaries on those architectures, or fix the problem someway else.


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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1038126: src:python-pyo: fails to migrate to testing for too long: FTBFS on i386

[Paul Gevers]

Source: python-pyo
Version: 1.0.4-1
Severity: serious
Control: close -1 1.0.5-2
Tags: sid trixie ftbfs
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:python-pyo has been trying to migrate for 
80 days [2]. Hence, I am filing this bug. Your package failed to build 
from source on i386, while it built there successfully in the past.


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=python-pyo



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1038124: src:geoalchemy2: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: geoalchemy2
Version: 0.12.5-1
Severity: serious
Control: close -1 0.13.3-1
Tags: sid trixie
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1034304

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:geoalchemy2 has been trying to migrate for 
89 days [2] (yes, partially due to the freeze, but that's over now). 
Hence, I am filing this bug. Your package has an autopkgtest regression, 
I filed a bug for that in 1034304.


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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037875: u-boot: ftbfs with GCC-13

[Vagrant Cascadian]

On 2023-06-14, Matthias Klose wrote:
> The package fails to build in a test rebuild on at least amd64 with
> gcc-13/g++-13, but succeeds to build with gcc-12/g++-12. The
> severity of this report will be raised before the trixie release.
>
> The full build log can be found at:
> http://qa-logs.debian.net/2023/05/22/logs/u-boot_2023.01+dfsg-2_unstable_gccexp.log
> The last lines of the build log are at the end of this report.

It appears that the only reason this failed is the corresponding
packages from gcc-13-cross or some other related cross packages were not
available in the test environment:

The following packages have unmet dependencies:
 libgcc-13-dev-arm64-cross : Depends: libgcc-s1-arm64-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: libgomp1-arm64-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: libitm1-arm64-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: libatomic1-arm64-cross (>= 
13.1.0-2cross1) but 12.2.0-14cross1 is to be installed
 Depends: libasan8-arm64-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: liblsan0-arm64-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: libtsan2-arm64-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: libubsan1-arm64-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: libhwasan0-arm64-cross (>= 
13.1.0-2cross1) but 12.2.0-14cross1 is to be installed
 libgcc-13-dev-armhf-cross : Depends: libgcc-s1-armhf-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: libgomp1-armhf-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: libatomic1-armhf-cross (>= 
13.1.0-2cross1) but 12.2.0-14cross1 is to be installed
 Depends: libasan8-armhf-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 Depends: libubsan1-armhf-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
 libgcc-13-dev-i386-cross : Depends: libgcc-s1-i386-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
Depends: libgomp1-i386-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
Depends: libitm1-i386-cross (>= 13.1.0-2cross1) but 
12.2.0-14cross1 is to be installed
Depends: libatomic1-i386-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
Depends: libasan8-i386-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
Depends: libubsan1-i386-cross (>= 13.1.0-2cross1) 
but 12.2.0-14cross1 is to be installed
Depends: libquadmath0-i386-cross (>= 
13.1.0-2cross1) but 12.2.0-14cross1 is to be installed
E: Unable to correct problems, you have held broken packages.


Wild guess is these need to be explicitly pulled in by the test
environment in addition to the packages from the gcc-13 source
package...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1038123: qt6-webengine: Build with system libpng beginning with Qt6 WebEngine 6.5

[Soren Stoutner]

Source: qt6-webengine
Version: 6.4.2-final+dfsg-1
Severity: normal
Tags: upstream

Beginning with 6.5, Qt WebEngine will have the plumbing to build against a 
system libpng.

https://bugreports.qt.io/browse/QTBUG-112466

The purpose of this bug report is to provide a reminder that once 6.5 is 
released a build depends on libpng-dev needes to be added and likely a config 
option needs to be specified.

Bug#1037510: texlive-lang-japanese: dangling symlinks due to missing dependencies

[Preuße]

On 13.06.2023 18:00, Vincent Lefevre wrote:

Hi Vincent,


There is a dangling symlink on my machine:
/usr/share/texlive/texmf-dist/fonts/truetype/public/ipaex/ipaexm.ttf -> 
../../../../../../fonts/opentype/ipaexfont-mincho/ipaexm.ttf

This seems to be due to a missing dependency on fonts-ipaexfont-mincho.


Thanks for the report!

Currently we just suggest these 4 packages. I propose to promote the 
suggest to recommend. Do you think that would be sufficient?
Mhhh: these 4 packages have a (installed) size of 40MB. Maybe the is 
neglect-able given the size of texlive-lang-japanese (300MB).


Let me know what you think.

H.
--
sigfault



OpenPGP_0x0C871C4C653C1F59.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1038122: cp: cannot stat '/tmp/odbcinst.ini.bak'

[Arthur Marsh]

Package: unixodbc-common
Version: 2.3.11-3
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Attempting to upgrade odbc related packages from 2.3.11-2 to 2.3.11-3

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

Setting up unixodbc-common (2.3.11-3) ...
cp: cannot stat '/tmp/odbcinst.ini.bak': No such file or directory
dpkg: error processing package unixodbc-common (--configure):
 installed unixodbc-common package post-installation script subprocess returned 
error exit status 1

   * What was the outcome of this action?

incomplete upgrade

   * What outcome did you expect instead?

completed upgrade

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


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

Kernel: Linux 6.4.0-rc6+ (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- no debconf information

Bug#1038035: grub2: Depends on SDL 1.2

[Simon McVittie]

On Thu, 15 Jun 2023 at 16:09:57 +0200, Julian Andres Klode wrote:
> On Thu, Jun 15, 2023 at 12:45:14PM +0100, Simon McVittie wrote:
> > This package has a Depends or Build-Depends on SDL version 1.2, which
> > is unmaintained upstream. This is presumably only for grub-emu.
> 
> It works with the preload, so my preference right now is to rebuild with
> the compat -dev package for now

Please don't change your Build-Depends (I've tried to be clearer about
this in later batches of bug reports). It's fine for the version that
ships in trixie to be built against libsdl1.2-dev.

For testing that a build against sdl12-compat can work,
libsdl1.2-compat-dev has a versioned Provides on libsdl1.2-dev, so it
should satisfy your build-dependency as-is.

If there are no showstopper bugs, I'm hoping to make sdl12-compat take
over the libsdl1.2-dev name during the trixie cycle, so that "classic"
SDL 1.2 goes away completely and packages with Build-Depends: libsdl1.2-dev
will be built against sdl12-compat, with libsdl1.2-compat-dev becoming a
transitional package - that means most packages won't need source changes.

Thanks for testing!

> and try to solve SDL 2 upstream

Thank you, that is the long term answer to this. There's no urgency to
solve this in a Debian-specific way.

smcv

Bug#1038119: tang: CVE-2023-1672

[Christoph Biedl]

Salvatore Bonaccorso wrote...

> CVE-2023-1672[0]:
> | Fix race condition when creating/rotating keys
> 
> Please adjust the affected versions in the BTS as needed.

As I'm very short of time today, first in words only:

* Debian sid will see a new upstream version (containing the fixes)
  in the next hours.
* Debian 12 ("bookworm") and 11 ("Bullseye") will be fixed via an
  upcoming point release.
* Debian 10 ("buster") is *not* affected, tight permissions of the
  directory holding the keys were asserted.

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#1005308: Installation Report: Crash of Debian netinst iso in Xen HVM guest

[Abhinav Praveen]

This issue persists in the current Debain 12 installer: 
debian-12.0.0-amd64-netinst.iso
-- 
Abhinav Praveen

Bug#1037942: linphone-desktop: Call notification windows in the middle of the screen

[Dennis Filder]

X-Debbugs-CC: Samuel Wolf 

On Wed, Jun 14, 2023 at 05:15:52PM +0200, Samuel Wolf wrote:
> Package: linphone-desktop
> Version: 4.4.10-3
> Severity: minor
> X-Debbugs-Cc: samuelwol...@googlemail.com
>
> Dear Maintainer,
>
> since Debian 12 my call notification windows is not anymore in the right down 
> corner of my two screens.
> There are two white windows (size of call window) and two call notification 
> windows in the middle of the screen.
> Is this a known issue?

No, this is something new.  I suspect Qt 5.15.8 might have changed
something in its multi-monitor support which may have broken something
somewhere, probably in
linphone-app/src/components/notifier/Notifier.cpp:Notifier::createNotification().

It would help a lot if:

- you could confirm that the behaviour is still as expected if you disable one
  of your monitors,

- you could give the exact dimensions of your monitors and the exact
  coordinates and dimensions of the notification windows and the white
  rectangles,

- you could paste any stdout/stderr or logfile output that contains
  the string "Primary screen" if it appears anywhere,

- you could maybe prepare screenshot(s) that are not too large
  (e.g. maybe convert to 256 colour PNG, remove any Desktop wallpaper
  etc.) and post them here.

It would be important to know if the notification windows are actually
in the very center or slightly offset somehow in case the bug is
related to subpixel support.

As for how soon this bug will be fixed: I can't tell.  Everyone in
Qt-land will probably start the migration to Qt 6 in the near future
if they haven't already, and thus probably deprioritize polish-related
issues like this.

Since I use a single-monitor setup I won't notice if this bug still
persists, so consider posting here after a new version has been
uploaded whether or not it still manifests.

Regards.

Bug#1038105: upgrade-reports: resume from suspend/hibernate broken by upgrade from bullseye to bookworm

[mooff]

On Thu, 15 Jun 2023 09:26:12 -0400 Jeffrey Mark Siskind  wrote:
> Package: upgrade-reports
> Severity: important
> 
> (Please provide enough information to help the Debian
> maintainers evaluate the report efficiently - e.g., by filling
> in the sections below.)
> 
> My previous release is: bullseye
> I am upgrading to: bookworm
> Upgrade date: Tuesday 13 Jun 2023
> uname -a after upgrade:
> Linux sapiencia 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 
> (2023-05-08) x86_64 GNU/Linux
> Method: apt dist-upgrade
> 
> Contents of /etc/apt/sources.list:
> 
> deb https://deb.debian.org/debian/ bookworm main contrib non-free 
> non-free-firmware
> deb-src https://deb.debian.org/debian/ bookworm main contrib non-free 
> non-free-firmware
> 
> deb https://deb.debian.org/debian/ bookworm-updates main contrib non-free 
> non-free-firmware
> deb-src https://deb.debian.org/debian/ bookworm-updates main contrib non-free 
> non-free-firmware
> 
> deb https://deb.debian.org/debian-security bookworm-security main contrib 
> non-free non-free-firmware
> deb-src https://deb.debian.org/debian-security bookworm-security main contrib 
> non-free non-free-firmware
> 
> # deb https://apt.repos.intel.com/oneapi all main
> # deb-src https://apt.repos.intel.com/oneapi all main
> 
> - Were there any non-Debian packages installed before the upgrade?  If
>   so, what were they?
> 
> https://apt.repos.intel.com/oneapi
> 
> qobi@sapiencia>ls /etc/apt/sources.list.d
> google-chrome.listneurodebian.sources.list-bullseye  teams.list
> neurodebian.sources.list  skype-stable.list
> qobi@sapiencia>
> 
> - Was the system pre-update a 'pure' system only containing packages
>   from the previous release? If not, which packages were not from that
>   release?
> 
> No. it had
>https://apt.repos.intel.com/oneapi
>google-chrome.list
>neurodebian.sources.list
>skype-stable.list
>teams.list
> 
> - Did any packages fail to upgrade?
> 
> At first, it didn't upgrade nvidia-driver. It did after I added
> non-free-firmware.
> 
> - Were there any problems with the system after upgrading?
> 
> Yes.
> 
> My machine is a Lenovo P71. I run gnome. Under bullseye, it properly
> suspended/hibernated with I closed the lid and properly resumed when I

Hello qobi.

After upgrading to Bookworm without the "non-free-firmware" area, my system 
booted onto nouveau.

Did "apt install nvidia-driver".

And had a fun time trying to getting things working properly.

At some point, I decided to try the improved Wayland support.

I discovered that GDM wasn't booting into Wayland, because of these 
/lib/udev/rules.d/61-gdm3.rules:

> # Check if suspend/resume services necessary for working wayland support is 
> available
> TEST{0711}!="/usr/bin/nvidia-sleep.sh", GOTO="gdm_disable_wayland"
> TEST{0711}!="/usr/lib/systemd/system-sleep/nvidia", GOTO="gdm_disable_wayland"
> IMPORT{program}="/bin/sh -c \"sed -e 's/: /=/g' -e 
> 's/\([^[:upper:]]\)\([[:upper:]]\)/\1_\2/g' -e 's/[[:lower:]]/\U&/g' -e 
> 's/^/NVIDIA_/' /proc/driver/nvidia/params\""
> ENV{NVIDIA_PRESERVE_VIDEO_MEMORY_ALLOCATIONS}!="1", GOTO="gdm_disable_wayland"
> IMPORT{program}="/bin/sh -c 'echo NVIDIA_HIBERNATE=`systemctl is-enabled 
> nvidia-hibernate`'"
> ENV{NVIDIA_HIBERNATE}!="enabled", GOTO="gdm_disable_wayland"
> IMPORT{program}="/bin/sh -c 'echo NVIDIA_RESUME=`systemctl is-enabled 
> nvidia-resume`'"
> ENV{NVIDIA_RESUME}!="enabled", GOTO="gdm_disable_wayland"
> IMPORT{program}="/bin/sh -c 'echo NVIDIA_SUSPEND=`systemctl is-enabled 
> nvidia-suspend`'"
> ENV{NVIDIA_SUSPEND}!="enabled", GOTO="gdm_disable_wayland"

I hacked around these, then tried to satisfy their conditions, when I noticed 
resume didn't work.

Having written the above, and tracked something down, I now think the Wayland 
issue is a red herring, but it is what led me to discover what was likely the 
fix:

Adding this to /etc/modprobe.d/nvidia-options.conf:

> # Keep VRAM on suspend
> options nvidia-current NVreg_PreserveVideoMemoryAllocations=1

This doesn't seem to be the default via nvidia-driver (nvidia-options.conf from 
nvidia-kernel-support).

Long way for a shortcut. But if that doesn't fix it, at least you may have 
another thread to pull :-)

Bug#1032355: systemd-boot: bootctl install/update completely broken with /boot on ZFS

[наб]

Control: reopen -1
Control: forwarded -1 https://github.com/systemd/systemd/pull/28048

Ha ha. The person whom this affected got back to me after upgrading to
252.11-1, and it doesn't work.
Odd, since we tested the patch, and applying it before did work.

Turns out: there's two identical conditions, and, when testing, I edited
the correct XBOOTLDR one (around line 800) ‒ and distributed that to the
reporter ‒ but in my systemd upstream check-out,
I edited the one for the ESP around line 500:
  nabijaczleweli@tarta:~/uwu/s/systemd-252.11$ grep -n 'This one is not it' 
src/shared/find-esp.c
  530:if (!IN_SET(r, -ENOENT, -EADDRNOTAVAIL, -ENOTDIR, 
-ENOTTY)) /* This one is not it */
  817:if (!IN_SET(r, -ENOENT, -EADDRNOTAVAIL, -ENOTDIR)) /* This one is 
not it */
this, naturally, doesn't work, and not one of the five people that
looked at it noticed that the analysis and mechanics are correct,
but the diff is applied to the wrong hunk.

I'd opened a fixed PR, applying the patch to the second, required,
condition as well, at forwarded-to.

I'm attaching an equivalent version, based on the systemd-252.11 dsc;
I've verified myself that applying it to 252.11-1 fixes the issue
(see forwarded-to).

Sorry for the churn; I hope this can still make it into a bookworm
point release.

Best,
наб
--- systemd-252.11.orig/src/shared/find-esp.c
+++ systemd-252.11/src/shared/find-esp.c
@@ -814,7 +814,7 @@ int find_xbootldr_and_warn(
 r = verify_xbootldr(p, /* searching= */ true, unprivileged_mode, 
ret_uuid, ret_devid);
 if (r >= 0)
 goto found;
-if (!IN_SET(r, -ENOENT, -EADDRNOTAVAIL, -ENOTDIR)) /* This one is not 
it */
+if (!IN_SET(r, -ENOENT, -EADDRNOTAVAIL, -ENOTDIR, -ENOTTY)) /* This 
one is not it */
 return r;
 
 return -ENOKEY;


signature.asc
Description: PGP signature

Bug#1038121: tracker.debian.org: debian/patches check vs. single-debian-patch in debian/source/local-options

[Thorsten Glaser]

Package: tracker.debian.org
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de

Unsure if this is the right pseudopackage; if not, please reassign.

The “new” Debian tracker shows:

 debian/patches: 1 patch to forward upstream

The package however uses the single-debian-patch mechanism
to let a diff be autogenerated from the patched source in
VCS. This is therefore not a diff that could possibly be
forwarded, and possibly contains Debian-local diffs only.

(This is basically using 3.0 (quilt) like 1.0, and very valid.)

Bug#1037975: manpages-ro-dev: incorrect short description: mentions Russian instead of Romanian

[Helge Kreutzmann]

tags 1037975 + pending
thanks

Hello Paul,
thanks for spotting. Fixed in git and will be part of the next upload.

Greetings

  Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1038120: network-manager: WiFi connection by 5 GHz unavailable and fails

[Green]

Package: network-manager
Version: 1.42.4-1
Severity: important
Tags: ipv6 lfs
X-Debbugs-Cc: usergr...@users.sourceforge.net

Dear Maintainer,

Network Manager can connent by 2.4 GHz, but can NOT connect by 5 GHz.
Access point by 5 GHz does not indicated on its graphical inerface at all.

Wireless interface:

product: AR9287 Wireless Network Adapter (PCI-Express) [168C:2E]
vendor: Qualcomm Atheros [168C]
driver: ath9k
driverversion: 6.1.0-9-amd64

I assume that the Network Manager compiled by Debian has a bug, because on the 
contrary, a network-manager-gnome_1.20.0-4mx21_amd64.deb shipped with MX Linux 
works properly.

Best regards

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 network-manager depends on:
ii  adduser 3.134
ii  dbus [default-dbus-system-bus]  1.14.6-1
ii  libaudit1   1:3.0.9-1
ii  libbluetooth3   5.66-1
ii  libc6   2.36-9
ii  libcurl3-gnutls 7.88.1-10
ii  libglib2.0-02.74.6-2
ii  libgnutls30 3.7.9-2
ii  libjansson4 2.14-2
ii  libmm-glib0 1.20.4-1
ii  libndp0 1.8-1
ii  libnewt0.52 0.52.23-1+b1
ii  libnm0  1.42.4-1
ii  libpsl5 0.21.2-1
ii  libreadline88.2-1.3
ii  libselinux1 3.4-1+b6
ii  libsystemd0 252.6-1
ii  libteamdctl01.31-1
ii  libudev1252.6-1
ii  policykit-1 122-3
ii  polkitd 122-3
ii  udev252.6-1

Versions of packages network-manager recommends:
ii  dnsmasq-base [dnsmasq-base]  2.89-1
ii  libpam-systemd   252.6-1
ii  modemmanager 1.20.4-1
ii  ppp  2.4.9-1+1.1+b1
ii  wireless-regdb   2022.06.06-1
ii  wpasupplicant2:2.10-12

Versions of packages network-manager suggests:
pn  iptables   
pn  libteam-utils  

Versions of packages network-manager is related to:
ii  isc-dhcp-client  4.4.3-P1-2

-- no debconf information

Bug#1005512: irqtop: Errors in man pages

[Helge Kreutzmann]

Hello Axel,
On Thu, Jun 15, 2023 at 01:07:12AM +0200, Axel Beckert wrote:
> thanks for the bug report!

You are welcome.

> Helge Kreutzmann wrote:
> > Finally the issues I'm reporting have accumulated over time and are
> > not always discovered by me, so sometimes my description of the
> > problem my be a bit limited - do not hesitate to ask so we can clarify
> > them.
> 
> Yeah, I think that's the place where things went a bit wrong.
> 
> > Man page: irqtop.1
> > Issue:ethtool → B(8)
> 
> I'm sorry, but this is a groff-written man page, but your suggested
> change seems POD syntax.

That is correct. At manpages-l10n we do not see the original syntax
but only the "normalized" output as produced by po4a. So kindly
translate this back to groff.

> > "show extra eth stats (from ethtool)"
> 
> That line now renders in man like this:
> 
> "show extra eth stats (from B(8))"
> 
> I don't think that's wanted.

That is exactly as wanted. See man-pages(7) for the traditional
formating conventions. 

> Besides we render htop(1) and friends under "SEE ALSO" also without
> any special formatting.

Then this should be changed there as well. You can check many other
man pages who do.

> So I'll make it simply "ethtool(8)".

Maybe reconsider this (globally)?

Please not that there are tools out there which can identify the
B(8) and create appropriate hyperlinks; moreover it is good
to spot those links in the text.

> > Man page: irqtop.1
> > Issue:enouth → enough
> 
> "enouth" neither is nor ever was in this Debian package.

That is correct, that is only present in the version from Fedora 38.
Upstream told me, that the man page comes from Debian. Apologies if
Fedora is shipping a different man page. As downstream this is
sometimes hard to spot where a specific text is actually originating
from.

> > "Show per-cpu statistics by specified mode. Available modes are: B, "
> > "B, B. The default option B detects the width of "
> > "window, then shows the per-cpu statistics if the width of window is large "
> > "enouth to show a full line of statistics."
> 
> Neither is this text.

That's right, this is comming from Fedora again.

> A quick search on codesearch.debian.net reveals that this is part of
> the man page from the _other_ tool named irqtop, the one from
> util-linux:
> https://sources.debian.org/src/util-linux/2.38.1-5/sys-utils/irqtop.1.adoc/?hl=29#L29
> 
> Which is not yet shipped in a binary package in Debian as I didn't
> manage to start the migration between the two irqtops timely before
> the Bookworm freeze.
> 
> Please report that error against src:util-linux.

Thanks for pointing this out. Potentially for Fedora the util-linux
version is (already) shipped. 

I'll forward this appropriately. Thanks for checking!

Greetings

   Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1038119: tang: CVE-2023-1672

[Salvatore Bonaccorso]

Source: tang
Version: 11-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for tang.

CVE-2023-1672[0]:
| Fix race condition when creating/rotating keys


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-1672
https://www.cve.org/CVERecord?id=CVE-2023-1672
[1] 
https://github.com/latchset/tang/commit/8dbbed10870378f1b2c3cf3df2ea7edca7617096

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1037996: Acknowledgement (xfce4: xfce-Desktop will be crashed at start and than black Desktop)

[Dr. Hanisch]

Hello,

O wonder!
in a real installation and in a VM of siduction (trixie/sid) I can turns 
up the Desktop when I sometimes press the Keys "Strg+Alt+h" (Parcellite 
clipboard) on the black Desktop. For tI his must make oft-repeated after 
Login-Sound and waiting some time.


That is  however no solution for  this situation.

with regards
Ch. Hanisch


--
Mein öffentlicher Schlüssel ist auf dem Keyserver 'https://keys.openpgp.org' 
unterch-hani...@t-online.de  (E53DF487)

Bug#1038117: util-linux: resume building of static libs

[Chris Hofstaedtler]

Hi,

* Leo Antunes :
> It would be great if we could either re-introduce them or at least add
> a comment explaining the reasoning behind the removal (to avoid future
> me bumping into this again ;))

For Debian we just do the Debian thing: do not ship static libraries
except for very narrow within-Debian-use-cases.

I think if you do custom stuff for minimal containers etc, its best
if you bring your own libraries and do not rely on development
packages intended -for- Debian packages.

Chris

Bug#1033130: gcc-snapshot: FTBFS on hppa - sys/mman.h: No such file or directory

[John David Anglin]

On 2023-06-14 2:31 p.m., John David Anglin wrote:

On 2023-06-14 1:00 p.m., Matthias Klose wrote:

wondering if configuring with --disable-libgcc would help?

I don't need to do this when building the hppa64 gcc target by itself.

Linux may need libgcc.


I think configure must be finding the header in 
/usr/include/hppa-linux-gnu/sys/mman.h.
We don't have any headers for hppa64 installed at this time.

Something seems to have changed in the build mechanism between gcc-12 and 
gcc-13.

I have a debian non-buildd build of gcc-13 going.  Maybe it will help to find 
issue.

Build was successful using dpkg-buildpackage outside chroot.

--
John David Anglin  dave.ang...@bell.net

Bug#1038118: lcms2: please build static libs

[Leo Antunes]

Source: lcms2
Version: 2.14-2
Severity: normal

Dear Maintainers,

It would be great if we could start including the .a files in the -dev
packages. This would allow building static binaries against the library
(e.g. for minimal container cases)

Thanks!
Leo Antunes

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

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

Bug#1038114: Acknowledgement (hstr: no longer works with kernel linux-image-6.3.0-1-amd64)

[Václav Ovsík]

Workaround:

bobekpc:~# cat /etc/sysctl.d/10-hstr.conf
dev.tty.legacy_tiocsti = 1

-- 
Zito

Bug#1038117: util-linux: resume building of static libs

[Leo Antunes]

Source: util-linux
Version: 2.38.1-5+b1
Severity: normal

Dear Maintainers,

During the bump to dh13 a couple of years back the static libs were
removed from all *-dev packages[0].
This change has the unfortunate side-effect of making it impossible to
actually use the libraries in static builds (e.g. when building for
minimal container scenarios).

It would be great if we could either re-introduce them or at least add
a comment explaining the reasoning behind the removal (to avoid future
me bumping into this again ;))


Thanks!

[0] 
https://salsa.debian.org/debian/util-linux/-/commit/1e827a6811e2b22aacdd4b91b11aca9f103e5d12


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

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

-- no debconf information

Bug#1038116: debian-live: Fails to set selected locale properly

[Green]

Package: debian-live
Severity: important
Tags: l10n
X-Debbugs-Cc: usergr...@users.sourceforge.net

Dear Maintainer,

Calamares Installer Fails to set selected locale properly: which installs 
plenty of other locales and relative .deb  language packages that a user does 
not desire.
For example, the followings are automatically installed when ja_JP is selected:

 firefox-esr firefox-esr-l10n-ar firefox-esr-l10n-ast firefox-esr-l10n-be
  firefox-esr-l10n-bg firefox-esr-l10n-bn firefox-esr-l10n-bs
  firefox-esr-l10n-ca firefox-esr-l10n-cs firefox-esr-l10n-cy
  firefox-esr-l10n-da firefox-esr-l10n-de firefox-esr-l10n-el
  firefox-esr-l10n-en-gb firefox-esr-l10n-eo firefox-esr-l10n-es-ar
  firefox-esr-l10n-es-cl firefox-esr-l10n-es-es firefox-esr-l10n-es-mx
  firefox-esr-l10n-et firefox-esr-l10n-eu firefox-esr-l10n-fa
  firefox-esr-l10n-fi firefox-esr-l10n-fr firefox-esr-l10n-ga-ie
  firefox-esr-l10n-gl firefox-esr-l10n-gu-in firefox-esr-l10n-he
  firefox-esr-l10n-hi-in firefox-esr-l10n-hr firefox-esr-l10n-hu
  firefox-esr-l10n-id firefox-esr-l10n-is firefox-esr-l10n-it
  firefox-esr-l10n-ja firefox-esr-l10n-kk firefox-esr-l10n-km
  firefox-esr-l10n-kn firefox-esr-l10n-ko firefox-esr-l10n-lt
  firefox-esr-l10n-lv firefox-esr-l10n-mk firefox-esr-l10n-mr
  firefox-esr-l10n-nb-no firefox-esr-l10n-ne-np firefox-esr-l10n-nl
  firefox-esr-l10n-nn-no firefox-esr-l10n-pa-in firefox-esr-l10n-pl
  firefox-esr-l10n-pt-br firefox-esr-l10n-pt-pt firefox-esr-l10n-ro
  firefox-esr-l10n-ru firefox-esr-l10n-si firefox-esr-l10n-sk
  firefox-esr-l10n-sl firefox-esr-l10n-sq firefox-esr-l10n-sr
  firefox-esr-l10n-sv-se firefox-esr-l10n-ta firefox-esr-l10n-te
  firefox-esr-l10n-th firefox-esr-l10n-tr firefox-esr-l10n-uk
  firefox-esr-l10n-vi firefox-esr-l10n-zh-cn firefox-esr-l10n-zh-tw

This behavior shuld be immediately fixed. It seems to me that many users have 
trouble when an updated version of Firefox is released in future, and also it 
takes much time for updating process.

Best regards,
Green

Bug#1037996: Acknowledgement (xfce4: xfce-Desktop will be crashed at start and than black Desktop)

[Dr. Hanisch]

Hello,

after last D-U in siduction with updating the xfce-session the situation 
is the same. I have no stable Desktop-view, the Desktop will be black 
and no things will go away.


with regards
Ch. Hanisch

--
Mein öffentlicher Schlüssel ist auf dem Keyserver 'https://keys.openpgp.org' 
unter ch-hani...@t-online.de (E53DF487)

Bug#1038115: transition: gdal

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: g...@packages.debian.org
Control: affects -1 + src:gdal
Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html
Control: block -1 by 1030129 998833 1037920 984398 1037976

For the Debian GIS team I'd like to transition to GDAL 3.7.0.

Most reverse dependencies rebuilt successfully with GDAL 3.7.0 from 
experimental as summarized below.


mysql-workbench (8.0.32+dfsg-1) FTBFS due to ca-certificates-java (#1030129).
Once that is fixed it will likely FTBFS due to #998833.

ncl (6.6.2.dfsg.1-1) FTBFS due to hdf4 (4.2.16-1):

 /usr/include/hdf/dfi.h:128:2: error: #endif without #if
   128 | #endif /* H4_DFI_H */
   |  ^

This is fixed in hdf4 (4.2.16-2), but NCL still FTBFS:

 /usr/include/hdf/dfi.h:53:33: error: two or more data types in declaration 
specifiers
53 | #define float32 float
   | ^
 /usr/include/hdf/hdfi.h:121:16: note: in expansion of macro 'float32'
   121 | typedef float  float32;
   |^~~
 /usr/include/hdf/hdfi.h:121:1: warning: useless type name in empty declaration
   121 | typedef float  float32;
   | ^~~

hdf4 (4.2.16-3) contains a different fix for dfi.h that resolves this issue.

python-django (3:3.2.19-1) FTBFS due to an unrelated issue (#1037920).

vtk6 (6.3.0+dfsg2-8.1) FTBFS due to an unrelated issue (#984398).

opencv (4.6.0+dfsg-12) FTBFS due to ca-certificates-java (#1030129).
Removing the Java packages lets the package build successfully with GDAL 3.7.0.

osmcoastline (2.4.0-1) FTBFS due to changes in GDAL 3.7.0 (#1037976),
osmcoastline (2.4.0-2) contains a patch to fix this issue.


Transition: gdal

 libgdal32 (3.6.4+dfsg-1) -> libgdal33 (3.7.0+dfsg-1~exp1)

The status of the most recent rebuilds is as follows.

 cloudcompare(2.11.3-7.1)  OK
 fiona   (1.9.4-1) OK
 gmt (6.4.0+dfsg-2)OK
 grass   (8.2.1-1) OK
 libcitygml  (2.5.1-1) OK
 libosmium   (2.19.0-1)OK
 mapcache(1.14.0-1)OK
 mapnik  (3.1.0+ds-3)  OK
 mapproxy(1.16.0+dfsg-1)   OK
 mapserver   (8.0.1-1) OK
 merkaartor  (0.19.0+ds-3) OK
 mysql-workbench (8.0.32+dfsg-1)   FTBFS (#998833)
 ncl (6.6.2.dfsg.1-1)  OK
 octave-mapping  (1.4.2-3) OK
 openorienteering-mapper (0.9.5-3) OK
 openscenegraph  (3.6.5+dfsg1-8)   OK
 paraview(5.11.0+dfsg-1)   OK
 pgsql-ogr-fdw   (1.1.3-1) OK
 pktools (2.6.7.6+ds-4)OK
 postgis (3.3.3+dfsg-2)OK
 python-django   (3:3.2.19-1)  FTBFS (#1037920)
 qmapshack   (1.16.1-2)OK
 r-cran-rgdal(1.6-4+dfsg-1)OK
 r-cran-sf   (1.0-9+dfsg-1)OK
 r-cran-terra(1.7-3-1) OK
 rasterio(1.3.7-1) OK
 saga(9.0.2+dfsg-1)OK
 vtk6(6.3.0+dfsg2-8.1) FTBFS (#984398)
 vtk7(7.1.1+dfsg2-10.2)OK
 vtk9(9.1.0+really9.1.0+dfsg2-5)   OK

 facet-analyser  (0.0~git20221121142040.6be10b8+ds1-3) OK
 libgdal-grass   (1:1.0.2-4)   OK
 opencv  (4.6.0+dfsg-12)   FTBFS (#1030129)
 osmcoastline(2.4.0-2) OK
 qgis(3.28.7+dfsg-1)   OK
 sumo(1.15.0+dfsg-1)   OK

 otb (8.1.1+dfsg-1)OK


Kind Regards,

Bas

Bug#1038114: hstr: no longer works with kernel linux-image-6.3.0-1-amd64

[Vaclav Ovsik]

Package: hstr
Version: 2.6+ds-1
Severity: normal

Dear Maintainer,
today I did 

apt update && apt upgrade

My unstable box then received linux-image-6.3.0-1-amd64 (among other
things). I was surprised hstr no longer works with bash. Nothing is
injected back to terminal input to bash prompt.
Neither bash, nor hstr was upgraded.
After some investigation I tried to boot old kernel
linux-image-6.1.0-9-amd64 (6.1.27-1). hstr is ok with 6.1 kernel! 

Probably the following change is responsible :-/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033095

Best Regards
-- 
Zito



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

Kernel: Linux 6.3.0-1-amd64 (SMP w/6 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 hstr depends on:
ii  libc6 2.36-9
ii  libncursesw6  6.4-4
ii  libreadline8  8.2-1.3
ii  libtinfo6 6.4-4

hstr recommends no packages.

hstr suggests no packages.

-- no debconf information

Bug#1038106: upgrade-reports: 4G modem ceased to work upon upgrade from bullseye to bookworm

[Paul Gevers]

control: reassign -1 network-manager

Hi,

Let's reassign to network-manager first. If it doesn't belong there, the 
maintainers are hopefully in a better position to reassign further.


Paul

On 15-06-2023 15:25, Jeffrey Mark Siskind wrote:

Package: upgrade-reports
Severity: important

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

My previous release is: bullseye
I am upgrading to: bookworm
Upgrade date: Tuesday 13 Jun 2023
uname -a after upgrade:
Linux sapiencia 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 
(2023-05-08) x86_64 GNU/Linux
Method: apt dist-upgrade

Contents of /etc/apt/sources.list:

deb https://deb.debian.org/debian/ bookworm main contrib non-free 
non-free-firmware
deb-src https://deb.debian.org/debian/ bookworm main contrib non-free 
non-free-firmware

deb https://deb.debian.org/debian/ bookworm-updates main contrib non-free 
non-free-firmware
deb-src https://deb.debian.org/debian/ bookworm-updates main contrib non-free 
non-free-firmware

deb https://deb.debian.org/debian-security bookworm-security main contrib 
non-free non-free-firmware
deb-src https://deb.debian.org/debian-security bookworm-security main contrib 
non-free non-free-firmware

# deb https://apt.repos.intel.com/oneapi all main
# deb-src https://apt.repos.intel.com/oneapi all main

- Were there any non-Debian packages installed before the upgrade?  If
   so, what were they?

https://apt.repos.intel.com/oneapi

qobi@sapiencia>ls /etc/apt/sources.list.d
google-chrome.listneurodebian.sources.list-bullseye  teams.list
neurodebian.sources.list  skype-stable.list
qobi@sapiencia>

- Was the system pre-update a 'pure' system only containing packages
   from the previous release? If not, which packages were not from that
   release?

No. it had
https://apt.repos.intel.com/oneapi
google-chrome.list
neurodebian.sources.list
skype-stable.list
teams.list

- Did any packages fail to upgrade?

At first, it didn't upgrade nvidia-driver. It did after I added
non-free-firmware.

- Were there any problems with the system after upgrading?

Yes.

My machine is a Lenovo P71. It has a Lenovo provided builtin 4G
modem. I hae a SIM card and service provided by Verizon. I run
gnome. It has worked with gnome-control-center out of the box under
buster and bullseye. (It has worked ever since I purchased the machine
about 5 or 6 years ago. I don't recall exactly, but I believe I first
ran stretch. I used to use wvdial before I switched to gnome a few
years ago. It worked under stretch, with wvdial, and then with
gnome-control-center under buster and bullseye.)

My modem is detected.

qobi@sapiencia>lsusb
[...]
Bus 001 Device 012: ID 1199:9079 Sierra Wireless, Inc. EM7455
[...]

I get

qobi@sapiencia>nmcli connection up 277472a9-1672-461f-a6df-27a0200a5712
Error: Connection activation failed: The base network connection was 
interrupted
Hint: use 'journalctl -xe 
NM_CONNECTION=277472a9-1672-461f-a6df-27a0200a5712 + NM_DEVICE=cdc-wdm1' to get 
more details.
qobi@sapiencia>sudo journalctl -xe 
NM_CONNECTION=277472a9-1672-461f-a6df-27a0200a5712 + NM_DEVICE=cdc-wdm|tail
[sudo] password for qobi:
Jun 14 07:13:12 sapiencia NetworkManager[2477]:   [1686741192.6457] 
modem-broadband[cdc-wdm1]: failed to connect modem: Couldn't wait for 'enabled': new 
state is 'disabled'
Jun 14 07:13:13 sapiencia NetworkManager[2477]:   [1686741193.1576] 
modem-broadband[cdc-wdm1]: failed to connect modem: Couldn't wait for 'enabled': new 
state is 'disabled'
Jun 14 07:18:14 sapiencia NetworkManager[2477]:   [1686741494.1865] 
modem-broadband[cdc-wdm1]: failed to connect modem: Couldn't wait for 'enabled': new 
state is 'disabled'
Jun 14 07:18:14 sapiencia NetworkManager[2477]:   [1686741494.6988] 
modem-broadband[cdc-wdm1]: failed to connect modem: Couldn't wait for 'enabled': new 
state is 'disabled'
Jun 14 07:18:15 sapiencia NetworkManager[2477]:   [1686741495.2104] 
modem-broadband[cdc-wdm1]: failed to connect modem: Couldn't wait for 'enabled': new 
state is 'disabled'
Jun 14 07:18:15 sapiencia NetworkManager[2477]:   [1686741495.7223] 
modem-broadband[cdc-wdm1]: failed to connect modem: Couldn't wait for 'enabled': new 
state is 'disabled'
Jun 14 07:23:16 sapiencia NetworkManager[2477]:   [1686741796.2020] 
modem-broadband[cdc-wdm1]: failed to connect modem: Couldn't wait for 'enabled': new 
state is 'disabled'
Jun 14 07:23:16 sapiencia NetworkManager[2477]:   [1686741796.7141] 
modem-broadband[cdc-wdm1]: failed to connect modem: Couldn't wait for 'enabled': new 
state is 'disabled'
Jun 14 07:23:17 sapiencia NetworkManager[2477]:   [1686741797.2261] 
modem-broadband[cdc-wdm1]: failed to connect modem: Couldn't wait for 'enabled': new 
state is 'disabled'
Jun 14 07:23:17 sapiencia NetworkManager[2477]:   [1686741797.7382] 
modem-broadband[cdc-wdm1]: failed to 

Bug#1038105: upgrade-reports: resume from suspend/hibernate broken by upgrade from bullseye to bookworm

[Paul Gevers]

control: reassign -1 src:linux

Hi,

Although it was suggested that this may be due to firmware updates too, 
let's reassign to the linux source package for first triaging.


Paul

On 15-06-2023 15:26, Jeffrey Mark Siskind wrote:

Package: upgrade-reports
Severity: important

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

My previous release is: bullseye
I am upgrading to: bookworm
Upgrade date: Tuesday 13 Jun 2023
uname -a after upgrade:
Linux sapiencia 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 
(2023-05-08) x86_64 GNU/Linux
Method: apt dist-upgrade

Contents of /etc/apt/sources.list:

deb https://deb.debian.org/debian/ bookworm main contrib non-free 
non-free-firmware
deb-src https://deb.debian.org/debian/ bookworm main contrib non-free 
non-free-firmware

deb https://deb.debian.org/debian/ bookworm-updates main contrib non-free 
non-free-firmware
deb-src https://deb.debian.org/debian/ bookworm-updates main contrib non-free 
non-free-firmware

deb https://deb.debian.org/debian-security bookworm-security main contrib 
non-free non-free-firmware
deb-src https://deb.debian.org/debian-security bookworm-security main contrib 
non-free non-free-firmware

# deb https://apt.repos.intel.com/oneapi all main
# deb-src https://apt.repos.intel.com/oneapi all main

- Were there any non-Debian packages installed before the upgrade?  If
   so, what were they?

https://apt.repos.intel.com/oneapi

qobi@sapiencia>ls /etc/apt/sources.list.d
google-chrome.listneurodebian.sources.list-bullseye  teams.list
neurodebian.sources.list  skype-stable.list
qobi@sapiencia>

- Was the system pre-update a 'pure' system only containing packages
   from the previous release? If not, which packages were not from that
   release?

No. it had
https://apt.repos.intel.com/oneapi
google-chrome.list
neurodebian.sources.list
skype-stable.list
teams.list

- Did any packages fail to upgrade?

At first, it didn't upgrade nvidia-driver. It did after I added
non-free-firmware.

- Were there any problems with the system after upgrading?

Yes.

My machine is a Lenovo P71. I run gnome. Under bullseye, it properly
suspended/hibernated with I closed the lid and properly resumed when I
opened the lid. After the upgrade to bookworm, it appears to properly
suspend/hibernat with I close the lid. Sometimes (about 30% of the
time) it properly resumes when I open the lid. But about 70% of the
time, when I open the lid, the disk light flashes a few times for
about 20 seconds, then stops. The screen remains blank. It doesn't
respond to any keypresses or mouse movements. If I press the power
button briefly, nothing happens. If I press and hold the power button
for about 10 seconds, it turns off. The I can power on and boot up
fresh.

I don't know if I should file against pm-tools.

 Jeff (http: //engineering.purdue.edu/~qobi)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1037991: iptables: LSB-Tags in /etc/init.d/iptables missing

[Jeremy Sowden]

On 2023-06-15, at 10:41:57 +0200, Manfred Brandl wrote:
> Package: iptables
> Version: 1.8.9-2
> Severity: normal
> 
> Dear Maintainer,
> 
> the last three lines of the output from "apt purge anacron" read:
> ---
> insserv: warning: script 'iptables' missing LSB tags
> insserv: Default-Start undefined, assuming empty start runlevel(s) for script 
> `iptables'
> insserv: Default-Stop  undefined, assuming empty stop runlevel(s) for script 
> `iptables'
> ---
> 
> I asked ChatCPT and got the advice to include the following lines into
> /etc/init.d/iptables
> ---
> ### BEGIN INIT INFO
> # Provides:  iptables
> # Required-Start:$network
> # Required-Stop: $network
> # Default-Start: 2 3 4 5
> # Default-Stop:  0 1 6
> # Short-Description: Start iptables firewall
> # Description:   Start iptables firewall using saved configuration
> ### END INIT INFO
> ---
> 
> May I suggest that these lines (or the correct version of them) to be
> included in a following version of the package?

The iptables package doesn't include an init-script and, TTBOMK, it
never has.

My guess is that it was installed manually.

Does running `dpkg -S /etc/init.d/iptables` identify a package for it?

What's in it?

J.


signature.asc
Description: PGP signature

Bug#1037982: libnet-route-perl needs dependency net-tools voor system route command.

[gregor herrmann]

On Thu, 15 Jun 2023 09:28:55 +0200, Craig Manley wrote:

> Yes it's a runtime dependency.-Craig

Alright; I didn't interpret "Our builds were failing" as a missing
runtime dependency but I understand now.

I'm uploading a fixed package shortly.

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1038113: New upstream available

[Lee Garrett]

Source: triplea
Severity: wishlist
X-Debbugs-Cc: deb...@rocketjump.eu

Hello fine Debian Java maintainers,

triplea has had a few updates since the last upload. Current stable is
2.5.22294. Can we get some love for this package?

Thanks in advance!

~ lee


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

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

Bug#1037991: Antw: Re: Bug#1037991: iptables: LSB-Tags in /etc/init.d/iptables missing

[Manfred Brandl]

No, running `dpkg -S /etc/init.d/iptables` does not identify a package
for it.
I did delete /etc/init.d/iptables from my system as id did not come
with the packages.
Please Close the Bug.
M.
>>> 
Von: Jeremy Sowden 
An:Manfred Brandl ,
<1037...@bugs.debian.org>
Datum: 15.06.2023 16:01
Betreff: Re: Bug#1037991: iptables: LSB-Tags in /etc/init.d/iptables
missing
On 2023-06-15, at 10:41:57 +0200, Manfred Brandl wrote:
> Package: iptables
> Version: 1.8.9-2
> Severity: normal
> 
> Dear Maintainer,
> 
> the last three lines of the output from "apt purge anacron" read:
> ---
> insserv: warning: script 'iptables' missing LSB tags
> insserv: Default-Start undefined, assuming empty start runlevel(s)
for script `iptables'
> insserv: Default-Stop  undefined, assuming empty stop runlevel(s) for
script `iptables'
> ---
> 
> I asked ChatCPT and got the advice to include the following lines
into
> /etc/init.d/iptables
> ---
> ### BEGIN INIT INFO
> # Provides: iptables
> # Required-Start:$network
> # Required-Stop:   $network
> # Default-Start:   2 3 4 5
> # Default-Stop: 0 1 6
> # Short-Description: Start iptables firewall
> # Description:   Start iptables firewall using saved
configuration
> ### END INIT INFO
> ---
> 
> May I suggest that these lines (or the correct version of them) to
be
> included in a following version of the package?

The iptables package doesn't include an init-script and, TTBOMK, it
never has.

My guess is that it was installed manually.

Does running `dpkg -S /etc/init.d/iptables` identify a package for it?

What's in it?

J.

Angaben gemäß § 14 UGB:
Verkehrsverbund Steiermark GmbH
Firmensitz: Metahofgasse 16, 8020 Graz
Rechtsform: GmbH | FN: 38644f
Firmenbuchgericht: Landesgericht für ZRS Graz

Bug#1037925: [Pkg-nagios-devel] Bug#1037925: icingacli: Icinga is not compatible with php8.2

[Sebastiaan Couwenberg]

On 6/15/23 15:46, Gabriel Rolland wrote:

But it keeps giving me error of deprecated functions.


It should not be an error.

E_DEPRECATED is excluded from error reporting in the default php.ini 
configuration:


 error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT


Deprecated: Creation of dynamic property 
Zend_Validate_NotEmpty::$zfBreakChainOnFailure is deprecated in 
/usr/share/icingaweb2/library/vendor/Zend/Form/Element.php on line 2176


Where do you get this message?

Which page in icingaweb2 needs to be visited?

Kind Regards,

Bas

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

Bug#1033964: smarty3: CVE-2023-28447: Cross site scripting vulnerability in Javascript escaping

[Mike Gabriel]

Control: fixed -1  3.1.48-1
Control: close -1

Hi,

On  Mi 05 Apr 2023 07:54:40 CEST, Salvatore Bonaccorso wrote:


Source: smarty3
Version: 3.1.47-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team  


Control: clone -1 -2
Control: reassign -2 src:smarty4 4.3.0-1
Control: retitle -2 smarty4: CVE-2023-28447: Cross site scripting  
vulnerability in Javascript escaping


Hi,

The following vulnerability was published for smarty.

CVE-2023-28447[0]:
| Smarty is a template engine for PHP. In affected versions smarty did
| not properly escape javascript code. An attacker could exploit this
| vulnerability to execute arbitrary JavaScript code in the context of
| the user's browser session. This may lead to unauthorized access to
| sensitive user data, manipulation of the web application's behavior,
| or unauthorized actions performed on behalf of the user. Users are
| advised to upgrade to either version 3.1.48 or to 4.3.1 to resolve
| this issue. There are no known workarounds for this vulnerability.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-28447
https://www.cve.org/CVERecord?id=CVE-2023-28447
[1]  
https://github.com/smarty-php/smarty/security/advisories/GHSA-7j98-h7fp-4vwj


Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore


I only saw this bug report after uploading smarty3. Thus, closing it manually.

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpCz7DTdrG1Z.pgp
Description: Digitale PGP-Signatur

Bug#1038112: bglibs/sysdeps.h redeclares system functions and variables (with incomplete prototypes)

[Julian Andres Klode]

Package: libbg-dev
Version: 2.04+dfsg-2.1
Severity: important
X-Debbugs-Cc: j...@debian.org

The most funny tidbit is

extern int select();

which totally breaks compilation in a C++ compiler even if you wrap
everything into extern "C" block.

Regardless of that, the declarations in the system headers may have
additional attributes set that may or may not cause conflicts with
the redeclarations down the road so libbg-dev should not redeclare
them.

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

Kernel: Linux 6.3.0-4-generic (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.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 libbg-dev depends on:
pn  libbg2  
ii  libc6   2.37-0ubuntu2

Versions of packages libbg-dev recommends:
pn  bglibs-doc  

libbg-dev suggests no packages.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1038111: haproxy-log-analysis: current version not usable, new upstream release available

[Daniel Scharon]

Package: haproxy-log-analysis
Version: 2.0~b0-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

directly after installation of haproxy-log-analysis the postinst script throws
errors:

Selecting previously unselected package python3-haproxy-log-analysis.
Preparing to unpack .../python3-haproxy-log-analysis_2.0~b0-4_all.deb ...
Unpacking python3-haproxy-log-analysis (2.0~b0-4) ...
Selecting previously unselected package haproxy-log-analysis.
Preparing to unpack .../haproxy-log-analysis_2.0~b0-4_all.deb ...
Unpacking haproxy-log-analysis (2.0~b0-4) ...
Setting up python3-pkg-resources (66.1.1-1) ...
Setting up python3-haproxy-log-analysis (2.0~b0-4) ...
/usr/lib/python3/dist-packages/haproxy/filters.py:122: SyntaxWarning: "is not"
with a literal. Did you mea
n "!="?
  if start_value is not '':
/usr/lib/python3/dist-packages/haproxy/filters.py:125: SyntaxWarning: "is not"
with a literal. Did you mea
n "!="?
  if delta_value is not '':
/usr/lib/python3/dist-packages/haproxy/filters.py:128: SyntaxWarning: "is not"
with a literal. Did you mea
n "!="?
  if start_value is not '' and delta_value is not '':
/usr/lib/python3/dist-packages/haproxy/filters.py:128: SyntaxWarning: "is not"
with a literal. Did you mea
n "!="?
  if start_value is not '' and delta_value is not '':
/usr/lib/python3/dist-packages/haproxy/filters.py:132: SyntaxWarning: "is" with
a literal. Did you mean "=
="?
  if start_value is '':
Setting up haproxy-log-analysis (2.0~b0-4) ...


Also executing haproxy-log-analysis throws an error which makes it basically
unusable:

Traceback (most recent call last):
  File "/usr/bin/haproxy_log_analysis", line 33, in 
sys.exit(load_entry_point('haproxy-log-analysis==2.0b0', 'console_scripts',
'haproxy_log_analysis')())

  File "/usr/lib/python3/dist-packages/haproxy/main.py", line 289, in
console_script
main(arguments)
  File "/usr/lib/python3/dist-packages/haproxy/main.py", line 274, in main
for command in args['commands']:
TypeError: 'NoneType' object is not iterable


The currently in Debian available version of haproxy-log-analysis is 7 years
old. There have been several releases by upstream since then. The latest was
version 5.1.0 released on December 3rd, 2022.

Please update haproxy-log-analysis so that we have a working version in Debian
again.

Thank you and kind regards,
Daniel




-- System Information:


Versions of packages haproxy-log-analysis depends on:
ii  python3   3.9.2-3
pn  python3-haproxy-log-analysis  

haproxy-log-analysis recommends no packages.

Bug#1037537: Upgrade To Bookworm Fails with Roundcube Update

[Bryan K. Walton]

Thanks for the reply, Guilhem.

After restoring my VM back to Debian 11.7, I then tried upgrading
Roundcube, first:

# sed -i s/bullseye/bookworm/ /etc/apt/sources.list
# apt-get install roundcube-core

This worked.  I then was able to do the full upgrade to bookworm.

While I'm not sure why this worked, I'm happy to get the upgrade
completed.

Thanks,
Bryan

Bug#1038035: grub2: Depends on SDL 1.2

[Julian Andres Klode]

Control: tag -1 confirmed upstream

On Thu, Jun 15, 2023 at 12:45:14PM +0100, Simon McVittie wrote:
> Source: grub2
> Tags: trixie sid
> User: pkg-sdl-maintain...@lists.alioth.debian.org
> Usertags: libsdl1.2
> 
> This package has a Depends or Build-Depends on SDL version 1.2, which
> is unmaintained upstream. This is presumably only for grub-emu.
> 
> If possible, please port this package to SDL 2 and close this bug. There
> is a migration guide at ,
> and examples of successful ports from SDL 1.2 to SDL 2 can be found in
> the commit history of packages like darkplaces and ioquake3.
> 
> If it is not possible to port to SDL 2, please test the package with
> libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
> this bug open to track the package as still using SDL 1.2 APIs.
> 
> libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
> API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
> library in some other distributions like Fedora and Arch, and my intention
> is to do the same in Debian during the trixie release cycle.
> 
> The interesting scenarios to test with libsdl1.2-compat-shim are:
> 
> 1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
>such as "GNOME on Xorg" or XFCE.
>($XDG_RUNTIME_DIR/wayland-* should not exist)
> 2. Install libsdl1.2-compat-shim and run the program in a Wayland
>environment such as GNOME's default mode, using Xwayland.
>($XDG_RUNTIME_DIR/wayland-* should exist)
> 3. Install libsdl1.2-compat-shim and run the program in a Wayland
>environment, but this time with environment variable
>SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
>(this is not currently the default for SDL 2).
> 4. Install libsdl1.2-compat-dev and recompile the package.

It works with the preload, so my preference right now is to rebuild with
the compat -dev package for now, and try to solve SDL 2 upstream.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1038110: jupyterhub: config.yaml config file that comes in package is never read

[Guillaume Knispel]

Package: jupyterhub
Version: 3.0.0+ds1-1
Severity: important
X-Debbugs-Cc: xi...@australdx.fr

Dear Maintainer,

The jupyterhub Debian package comes with a
/etc/jupyterhub/config/jupyterhub_config.d/config.yaml configuration
file (that is an empty valid YAML file).

The package also includes a /usr/lib/systemd/system/jupyterhub.service
which passes that YAML configuration file path to the command to launch
JupyterHub:
 ExecStart=/usr/bin/python3 -m jupyterhub.app -f 
/etc/jupyterhub/config/jupyterhub_config.d/config.yaml --upgrade-db

The config.yaml was added by commit:
> commit d95b38e175f746b26992ccae18f61cecde5c3479
> Author: Roland Mas 
> Date:   Wed Jun 2 16:06:51 2021 +0200
>
> Add empty config file

The jupyterhub.service was added by commit:
> commit 306c215c07f978bf7292c06c50c02fa7a383
> Author: Roland Mas 
> Date:   Wed Jun 2 16:13:16 2021 +0200
>
> Add systemd service file
and the command line hasn't changed since then.

However, a source code analysis, an strace, and actually trying to put
configuration options in this file show that it is never read.
This is because only Python (with a .py extension) or JSON (with a
.json extension) files are supported, as you can check in method
_load_config_files() of
/usr/lib/python3/dist-packages/traitlets/config/application.py

Dynamically, launching:
 /var/lib/jupyterhub# strace -tt -ff -o jupyterhub.strace /usr/bin/python3 -m 
jupyterhub.app -f /etc/jupyterhub/config/jupyterhub_config.d/config.yaml 
--upgrade-db
confirms that the file is not read by analysis of the resulting straces.

Another way to check is to simply modify the config.yaml file and see
that no option we put in there have any effect.
Due to how _load_config_files() works, i.e. ignoring the extension and trying
to load .py and .json files on the basename, we can however create a new file
/etc/jupyterhub/config/jupyterhub_config.d/config.json, and its content
is taken into account (without even changing the command line).  See examples
at the end.

I suggest to remove the config.yaml file from the package, and
to modify the command line used to launch JupyterHub to:
 /usr/bin/python3 -m jupyterhub.app -f /etc/jupyterhub/jupyterhub_config.py 
--upgrade-db

I'm also unsure about the effect of
/etc/jupyterhub/config/jupyterhub_config.d/50-use-configurable-http-proxy.py
I suspect it has no effect.  In any case it does not appear in the
straces.  The whole /etc/jupyterhub/config subtree should maybe be removed.

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

Kernel: Linux 6.1.0-0.deb11.7-amd64 (SMP w/62 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages jupyterhub depends on:
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-4.1
ii  libjs-bootstrap   3.4.1+dfsg-3
ii  libjs-jquery  3.6.1+dfsg+~3.5.14-1
ii  libjs-prototype   1.7.3-1
ii  libjs-requirejs   2.3.6+ds+~2.1.34-2
ii  node-configurable-http-proxy  4.5.3+~cs15.2.4-3
ii  python3   3.11.2-1+b1
ii  python3-alembic   1.8.1-2
ii  python3-async-generator   1.10-4
ii  python3-bcrypt3.2.2-1
ii  python3-certipy   0.1.3-4
ii  python3-dateutil  2.8.2-2
ii  python3-jinja23.1.2-1
ii  python3-jupyter-telemetry 0.1.0-4
ii  python3-notebook  6.4.12-2.2
ii  python3-oauthlib  3.2.2-1
ii  python3-packaging 23.0-1
ii  python3-pamela1.0.0-3
ii  python3-prometheus-client 0.16.0-0.1
ii  python3-requests  2.28.1+dfsg-1
ii  python3-sqlalchemy1.4.46+ds1-1
ii  python3-tornado   6.2.0-3
ii  python3-traitlets 5.5.0-1

jupyterhub recommends no packages.

jupyterhub suggests no packages.

-- Configuration Files:
/etc/jupyterhub/config/jupyterhub_config.d/config.yaml changed:
---
Application:
  show_config_json: true
JupyterHub:
  port: 


-- no debconf information

*** /etc/jupyterhub/config/jupyterhub_config.d/config.json
{
  "Application": {
"show_config_json": true
  },
  "JupyterHub": {
"port": 
  }
}

Bug#1038109: Unify homepage CSS and how do we load CSS files

[Laura Arjona Reina]

Package: www.debian.org
User: www.debian@packages.debian.org
Usertag: design
Severity: normal

It would be nice to reorganize the styles we use in the homepage in a 
specific file. Currently we use, specifically for the homepage:


/5img-carousel-slider.css
./debhome.css
./startpage.css

The basic.wml and basic5.wml templates have this code to load the 
corresponding CSS depending if a page has the header MAINPAGE (used not 
only in frontpage, but also in the pages that have been redesigned, e.g. 
the ones under /intro, /doc, /devel...):


>
{#style#:type="text/css" />
  rel="stylesheet" type="text/css" media="all"/>

:#style#}


  
  
{#style#:type="text/css" />
   type="text/css" />
   rel="stylesheet" type="text/css" />
  rel="stylesheet" type="text/css" media="all"/>

:#style#}


But then in the redesigned pages we load more CSS within the page:



It would be nice to unify the different styles of the homepage in a 
single file, and also decide how do we load them (if via the template or 
in each .wml file separately), and use the same procedure for all the 
CSS we have in the website.


Note that a change in the basic*.wml templates probably triggers a 
rebuild of most of the website, so adding/removing a CSS file there has 
to be handled with care. This, and this bug, are the reasons behind 
changing the 5img-carousel-slider.css file to show 6 images instead of 5 
(see commit 
https://salsa.debian.org/webmaster-team/webwml/-/commit/221bc933118b9f05c063776d7ef41d75a9bf2858 
) without renaming the file, for now :/


Kind regards
--
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#1038103: Missing PHY module for Odroid N2+ in debian-installer (bookworm)

[Cyril Brulebois]

Control: reassign -1 src:linux 6.1.27-1

Hi Łukasz,

Łukasz Walkowski  (2023-06-15):
> When installing Debian using netboot current image and PXE on Odroid N2+,
> the PHY modules are missing from the initrd. This causes installation to
> fail, because of the missing networking.
> 
> A workaround is to repack initrd with modules copied from working bookworm
> installation.
> 
> The missing modules are:
> ./kernel/drivers/net/mdio/mdio-mux-meson-g12a.ko
> ./kernel/drivers/net/mdio/mdio-mux.ko
> 
> This is observed with the 'current' netboot image, dated 2023/06/07:
> Linux bootstrap 6.1.0-9-arm64 #1 SMP Debian 6.1.27-1 (2023-05-08) aarch64
> GNU/Linux

Thanks for the report and all the details.

Reassigning to the linux kernel, which should get an update to ship
those modules in the relevant udeb. Those probably should go along with
mdio-bcm-unimac in debian/installer/modules/arm64/nic-modules.

Hopefully that can be picked up for a point release.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1037925: icingacli: Icinga is not compatible with php8.2

[Gabriel Rolland]

Package: icingaweb2
Version: 2.11.4-2
Followup-For: Bug #1037925

Nothing to do, I purged all packages and reinstalled from scratch.
I also tried to download the sources and check that the php8.2.patch was 
correctly applied.

But it keeps giving me error of deprecated functions.

Deprecated: Creation of dynamic property 
Zend_Validate_NotEmpty::$zfBreakChainOnFailure is deprecated in 
/usr/share/icingaweb2/library/vendor/Zend/Form/Element.php on line 2176

Bug#1038108: telegram-desktop: New upstream version available (4.8.4)

[naoliv]

Source: telegram-desktop
Version: 4.6.5+ds-2
Severity: wishlist
X-Debbugs-Cc: nao...@gmail.com

Hi!

When possible, could we have the latest version available on Debian,
please?


Thank you!

Best regards,
Nelson

-- Package-specific info:

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

Kernel: Linux 6.3.0-0-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages telegram-desktop is related to:
ii  xdg-desktop-portal   1.16.0-2
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.1-1

-- no debconf information
[2023.06.14 15:12:13] Launched version: 4006005, install beta: [FALSE], alpha: 
0, debug mode: [FALSE]
[2023.06.14 15:12:13] Executable dir: /usr/bin/, name: telegram-desktop
[2023.06.14 15:12:13] Initial working dir: /home/naoliv/
[2023.06.14 15:12:13] Working dir: /home/naoliv/.local/share/TelegramDesktop/
[2023.06.14 15:12:13] Command line: telegram-desktop
[2023.06.14 15:12:13] Executable path before check: /usr/bin/telegram-desktop
[2023.06.14 15:12:13] Logs started
[2023.06.14 15:12:13] Launcher filename: org.telegram.desktop.desktop
[2023.06.14 15:12:13] We use allocator from /lib/x86_64-linux-gnu/libc.so.6
[2023.06.14 15:12:13] Connecting local socket to 
/tmp/c3e19020b3ade56b1b66d1c27d5eda3e-{87A94AB0-E370-4cde-98D3-ACC110C5967D}...
[2023.06.14 15:12:13] This is the only instance of Telegram, starting server 
and app...
[2023.06.14 15:12:13] Moved logging from 
'/home/naoliv/.local/share/TelegramDesktop/log_start1.txt' to 
'/home/naoliv/.local/share/TelegramDesktop/log.txt'!
[2023.06.14 15:12:13] Old start log 'log_start0.txt' found, deleted: [TRUE]
[2023.06.14 15:12:13] Global devicePixelRatio: 1
[2023.06.14 15:12:13] QT_DPI_ADJUSTMENT_POLICY: AdjustDpi
[2023.06.14 15:12:13] Primary screen DPI: 96.1263, Base: 96.
[2023.06.14 15:12:13] Computed screen scale: 100
[2023.06.14 15:12:13] DevicePixelRatio: 1
[2023.06.14 15:12:13] ScreenScale: 100
[2023.06.14 15:12:13] System tray available: [TRUE]
[2023.06.14 15:12:13] Icon theme: hicolor
[2023.06.14 15:12:13] Fallback icon theme: hicolor
[2023.06.14 15:12:13] App Info: reading settings...
[2023.06.14 15:12:13] App Info: reading encrypted settings...
[2023.06.14 15:12:13] Lang Info: Loaded cached, keys: 4996
[2023.06.14 15:12:13] OpenAL Logging Level: (not set)
[2023.06.14 15:12:13] Audio Playback Devices: Logi USB Headset Analog 
Stereo;Áudio interno Analog Stereo
[2023.06.14 15:12:13] Audio Playback Default Device: Logi USB Headset Analog 
Stereo
[2023.06.14 15:12:13] Audio Capture Devices: C920 PRO HD Webcam Analog 
Stereo;Monitor of Logi USB Headset Analog Stereo;Monitor of Áudio interno 
Analog Stereo;Áudio interno Analog Stereo
[2023.06.14 15:12:13] Audio Capture Default Device: C920 PRO HD Webcam Analog 
Stereo
[2023.06.14 15:12:13] App Info: reading accounts info...
[2023.06.14 15:12:13] App Info: reading encrypted info...
[2023.06.14 15:12:13] App Info: reading map...
[2023.06.14 15:12:13] App Info: reading encrypted map...
[2023.06.14 15:12:13] App Info: reading encrypted user settings...
[2023.06.14 15:12:13] App Info: encrypted user settings read.
[2023.06.14 15:12:13] App Info: reading encrypted mtp data...
[2023.06.14 15:12:13] MTP Info: read keys, current: 5, to destroy: 0
[2023.06.14 15:12:13] Map read time: 1
[2023.06.14 15:12:13] App Info: reading encrypted mtp config...
[2023.06.14 15:12:13] Export Info: Destroy top bar by controller removal.
[2023.06.14 15:12:13] OpenGL Profile: Compatibility.
[2023.06.14 15:12:13] OpenGL Renderer: Mesa Intel(R) UHD Graphics 770 (ADL-S 
GT1)
[2023.06.14 15:12:13] OpenGL Vendor: Intel
[2023.06.14 15:12:13] OpenGL Version: 4.6 (Compatibility Profile) Mesa 22.3.6
[2023.06.14 15:12:13] OpenGL Extensions: GL_ARB_texture_buffer_object_rgb32, 
GL_ARB_conditional_render_inverted, GL_ARB_draw_elements_base_vertex, 
GL_EXT_bgra, GL_ARB_fragment_program, GL_IBM_multimode_draw_arrays, 
GL_ATI_texture_float, GL_EXT_texture_filter_anisotropic, GL_EXT_semaphore, 
GL_NV_fragment_shader_interlock, GL_ARB_texture_rg, GL_ARB_derivative_control, 
GL_EXT_shader_integer_mix, GL_ARB_fragment_layer_viewport, 
GL_EXT_separate_specular_color, GL_ARB_multi_draw_indirect, 
GL_EXT_gpu_program_parameters, GL_NV_compute_shader_derivatives, GL_S3_s3tc, 
GL_ARB_shader_clock, GL_ARB_texture_compression_bptc, GL_KHR_robustness, 
GL_ARB_shader_texture_image_samples, GL_ARB_gpu_shader_int64, 
GL_ARB_compute_variable_group_size, GL_EXT_draw_range_elements, 
GL_ARB_framebuffer_sRGB, GL_EXT_copy_texture, GL_ARB_vertex_buffer_object, 
GL_EXT_blend_minmax, GL_ARB_tessellation_shader, GL_ARB_point_parameters, 
GL_ARB_occlusion_query, GL_NV_copy_image, GL_ARB_fragment_program_shadow, 

Bug#1038104: libclansdl-1.0v5: Extends an obsolete version of SDL

[Simon McVittie]

Package: libclansdl-1.0v5
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

libclansdl-1.0v5 extends SDL 1.2, which is unmaintained upstream
(superseded by SDL 2).

It looks as though nothing in Debian requires libclansdl-1.0v5: the only
package in Debian that would be broken by removing clanlib is trophy,
which does not use SDL. Would it be possible to disable building the SDL
part of clanlib, remove the libclansdl-1.0v5 binary package, and remove
the SDL-related parts from libclanlib-dev? That would be one less thing
in Debian that depends on libsdl1.2debian.

-- 
This bug report is part of a mass-bug-filing:

Bug#1038103: Missing PHY module for Odroid N2+ in debian-installer (bookworm)

[Łukasz Walkowski]

Package: debian-installer
Version: debian-installer/stable 20230607 arm64

When installing Debian using netboot current image and PXE on Odroid N2+,
the PHY modules are missing from the initrd. This causes installation to
fail, because of the missing networking.

A workaround is to repack initrd with modules copied from working bookworm
installation.

The missing modules are:
./kernel/drivers/net/mdio/mdio-mux-meson-g12a.ko
./kernel/drivers/net/mdio/mdio-mux.ko

This is observed with the 'current' netboot image, dated 2023/06/07:
Linux bootstrap 6.1.0-9-arm64 #1 SMP Debian 6.1.27-1 (2023-05-08) aarch64
GNU/Linux

Lukasz

Bug#1038100: libopenhmd: Build-Depends (unnecessarily?) on SDL 1.2

[Simon McVittie]

Package: libopenhmd
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Build-Depends on SDL version 1.2, which
is unmaintained upstream. I don't see any sign of a runtime dependency,
though.

If the dependency isn't actually necessary, please remove it and close
this bug.

Or, if there is a reason I'm not seeing why SDL is required, please
port this package to SDL 2 and close this bug. There is a migration
guide at , and examples
of successful ports from SDL 1.2 to SDL 2 can be found in the commit
history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038102: lv-tool-0.4: Depends on SDL 1.2

[Simon McVittie]

Package: lv-tool-0.4
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038101: libquicktime: Build-Depends (unnecessarily?) on SDL 1.2

[Simon McVittie]

Package: libquicktime
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Build-Depends on SDL version 1.2, which
is unmaintained upstream. I don't see any sign of a runtime dependency,
though.

If the dependency isn't actually necessary, please remove it and close
this bug.

Or, if there is a reason I'm not seeing why SDL is required, please
port this package to SDL 2 and close this bug. There is a migration
guide at , and examples
of successful ports from SDL 1.2 to SDL 2 can be found in the commit
history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038099: libdv-bin: Depends on SDL 1.2

[Simon McVittie]

Package: libdv-bin
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038098: libtheora-bin: Depends on SDL 1.2

[Simon McVittie]

Package: libtheora-bin
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038097: libde265-examples: Depends on SDL 1.2

[Simon McVittie]

Package: libde265-examples
Tags: trixie sid
User: pkg-sdl-maintain...@lists.alioth.debian.org
Usertags: libsdl1.2

This package has a Depends or Build-Depends on SDL version 1.2, which
is unmaintained upstream.

If possible, please port this package to SDL 2 and close this bug. There
is a migration guide at ,
and examples of successful ports from SDL 1.2 to SDL 2 can be found in
the commit history of packages like darkplaces and ioquake3.

If it is not possible to port to SDL 2, please test the package with
libsdl1.2-compat-shim (preferably version 1.2.64 or later), and leave
this bug open to track the package as still using SDL 1.2 APIs.

libsdl1.2-compat-shim is a compatibility layer that provides the SDL 1.2
API/ABI by using SDL 2: it has already replaced the "classic" SDL 1.2
library in some other distributions like Fedora and Arch, and my intention
is to do the same in Debian during the trixie release cycle.

It is *not* necessary to change dependencies from libsdl1.2debian to
libsdl1.2-compat-shim, or from libsdl1.2-dev to libsdl1.2-compat-dev.
My intention is to make a future version of sdl12-compat take over
the old package names, to minimize the changes that are required in
dependent packages.

The interesting scenarios to test with libsdl1.2-compat-shim are:

1. Install libsdl1.2-compat-shim and run the program in an X11 environment,
   such as "GNOME on Xorg" or XFCE.
   ($XDG_RUNTIME_DIR/wayland-* should not exist)
2. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment such as GNOME's default mode, using Xwayland.
   ($XDG_RUNTIME_DIR/wayland-* should exist)
3. Install libsdl1.2-compat-shim and run the program in a Wayland
   environment, but this time with environment variable
   SDL_VIDEODRIVER=wayland so that it uses the native Wayland interface
   (this is not currently the default for SDL 2).
4. Install libsdl1.2-compat-dev and recompile the package.

If any of those fail, please report it as a bug in the
libsdl1.2-compat-shim or libsdl1.2-compat-dev package as appropriate,
with "affects" pointing to the program that is affected.

Thanks,
smcv

-- 
This bug report is part of a mass-bug-filing:

Bug#1038068: additional info

[mh]

This is what I get when starting VLC for termial using Debian
kernel 6.1.0 (not freezing when switching channels):


[7f37640049e0] glconv_vaapi_x11 gl error: vaInitialize: unknown
libva error libva info: VA-API version 1.18.0 libva info: Trying to
open /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so libva info:
va_openDriver() returns -1 [7f37640049e0] glconv_vaapi_drm gl
error: vaInitialize: unknown libva error libva info: VA-API version
1.18.0 libva info: Trying to open
/usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so libva info:
va_openDriver() returns -1 [7f37640049e0] glconv_vaapi_drm gl
error: vaInitialize: unknown libva error [7f37640049e0] gl gl:
Initialized libplacebo v4.208.0 (API v208) [7f377c01cfc0] avcodec
decoder: Using NVIDIA VDPAU Driver Shared Library  470.182.03  Fri Feb
24 03:16:35 UTC 2023 for hardware decoding [hevc @ 0x7f3778005e40]
Failed setup for format vdpau: hwaccel initialisation returned error.
[7f377c01cfc0] avcodec decoder error: existing hardware
acceleration cannot be reused [7f37640049e0] gl gl: Initialized
libplacebo v4.208.0 (API v208) [7f37640049e0] gl gl: Initialized
libplacebo v4.208.0 (API v208) [7f377c343230] main decoder error:
buffer deadlock prevented [7f377c343ac0] mpeg4audio packetizer: AAC
channels: 2 samplerate: 48000 [hevc @ 0x7f3778005e40] Could not find
ref with POC 3592 [hevc @ 0x7f3778005e40] Could not find ref with POC
3596 [hevc @ 0x7f3778005e40] Could not find ref with POC 3600 [hevc @
0x7f3778005e40] Could not find ref with POC 3604 [hevc @
0x7f3778005e40] Could not find ref with POC 3608 [hevc @
0x7f3778005e40] Could not find ref with POC 3612 [hevc @
...
*

This is what I get when starting VLC for termial using Debian
kernel 6.3.0 (freezing):

**
VLC media player 3.0.18 Vetinari (revision 3.0.13-8-g41878ff4f2)
[5647f9d56440] main playlist: playlist is empty
[7f6c9c343e80] mpeg4audio packetizer: AAC channels: 2 samplerate:
48000 [7f6c9c01cc20] main decoder error: buffer deadlock prevented
[7f6c9c3435f0] main decoder error: buffer deadlock prevented
[7f6c8c004860] gl gl: Initialized libplacebo v4.208.0 (API v208)
libva info: VA-API version 1.18.0 libva error: vaGetDriverNameByIndex()
failed with unknown libva error, driver_na   me = (null)
[7f6c8c004860] glconv_vaapi_x11 gl error: vaInitialize: unknown
libva error libva info: VA-API version 1.18.0 libva info: Trying to
open /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so libva info:
va_openDriver() returns -1 [7f6c8c004860] glconv_vaapi_drm gl
error: vaInitialize: unknown libva error libva info: VA-API version
1.18.0 libva info: Trying to open
/usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so libva info:
va_openDriver() returns -1 [7f6c8c004860] glconv_vaapi_drm gl
error: vaInitialize: unknown libva error [7f6c8c004860] gl gl:
Initialized libplacebo v4.208.0 (API v208) [7f6c9c01cc20] avcodec
decoder: Using NVIDIA VDPAU Driver Shared Library  470.182.03  Fri Feb
24 03:16:35 UTC 2023 for hardware decoding [hevc @ 0x7f6c98004940]
Failed setup for format vdpau: hwaccel initialisation returned error.
[7f6c9c01cc20] avcodec decoder error: existing hardware
acceleration cannot be reused [7f6c8c004860] gl gl: Initialized
libplacebo v4.208.0 (API v208) [7f6c8c004860] gl gl: Initialized
libplacebo v4.208.0 (API v208) [hevc @ 0x7f6c98004940] Could not find
ref with POC -3956 [hevc @ 0x7f6c98004940] Could not find ref with POC
-3952 [hevc @ 0x7f6c98004940] Could not find ref with POC -3948
[hevc @ 0x7f6c98004940] Could not find ref with POC -3944
[hevc @ 0x7f6c98004940] Could not find ref with POC -3940
[hevc @ 0x7f6c98004940] Could not find ref with POC -3936
[hevc @ 0x7f6c98004940] Could not find ref with POC -3932
[hevc @ 0x7f6c98004940] Could not find ref with POC -3928
[hevc @ 0x7f6c98004940] Could not find ref with POC -3372
[hevc @ 0x7f6c98004940] Could not find ref with POC -3368
[hevc @ 0x7f6c98004940] Could not find ref with POC -3364
[hevc @ 0x7f6c98004940] Could not find ref with POC -3360
[hevc @ 0x7f6c98004940] Could not find ref with POC -3356
[hevc @ 0x7f6c98004940] Could not find ref with POC -3352
[hevc @ 0x7f6c98004940] Could not find ref with POC -3348
[hevc @ 0x7f6c98004940] Could not find ref with POC -3344
[hevc @ 0x7f6c98004940] Could not find ref with POC -3340


And the following I get as soon as I try to change ea dvb chanel


[hevc @ 0x7f6c98262f00] get_buffer() failed
[hevc @ 0x7f6c98262f00] thread_get_buffer() failed
[hevc @ 0x7f6c98004940] get_buffer() failed
[hevc @ 0x7f6c98004940] thread_get_buffer() failed


At this point VLC is frozen for the most part (video) and shutdown will
not complete.


The reason I posted this bug against the kernel and not against VLC is
that I assume this behaviour