Bug#1032557: Bookworm is not affected

[Andreas Tille]

Control: tags -1 bookworm-ignore
Control: tags -1 - bookworm

Inside bookworm the testing the autopkgtest works.

-- 
http://fam-tille.de

Bug#1016903: Update debian patches for enabling git-updates.diff in gcc-12-12.2.0-14 and 17

[Ricky X. Y. LIU]

diff -Narup a/debian/patches/gcc-distro-specs.diff 
b/debian/patches/gcc-distro-specs.diff
--- a/debian/patches/gcc-distro-specs.diff  2022-10-31 21:50:28.0 
+0800
+++ b/debian/patches/gcc-distro-specs.diff  2023-04-07 09:57:08.034297864 
+0800
@@ -1,20 +1,19 @@
 # DP: Add empty distro and hardening specs

 a/src/gcc/gcc.cc
-+++ b/src/gcc/gcc.cc
-@@ -27,6 +27,11 @@ CC recognizes how to compile each input
- Once it knows which kind of compilation to perform, the procedure for
+--- a/src/gcc/gcc.cc   2023-04-06 08:20:07.0 +0800
 b/src/gcc/gcc.cc   2023-04-07 09:54:02.948157378 +0800
+@@ -28,6 +28,10 @@ Once it knows which kind of compilation
  compilation is specified by a string called a "spec".  */

+ #define INCLUDE_STRING
 +/* Inject some default compilation flags which are used as the default.
 +   Done by the packaging build system.  Should that be done in the headers
 +   gcc/config//*.h instead?  */
 +#include "distro-defaults.h"
-+
  #include "config.h"
  #include "system.h"
  #include "coretypes.h"
-@@ -984,6 +989,90 @@ proper position among the other output f
+@@ -986,6 +990,90 @@ proper position among the other output f
  #define LINK_GCC_C_SEQUENCE_SPEC "%G %{!nolibc:%L %G}"
  #endif

@@ -105,7 +104,7 @@
  #ifndef LINK_SSP_SPEC
  #ifdef TARGET_LIBC_PROVIDES_SSP
  #define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-all" \
-@@ -1040,7 +1129,7 @@ proper position among the other output f
+@@ -1042,7 +1130,7 @@ proper position among the other output f
  #ifndef LINK_PIE_SPEC
  #ifdef HAVE_LD_PIE
  #ifndef LD_PIE_SPEC
@@ -114,7 +113,7 @@
  #endif
  #else
  #define LD_PIE_SPEC ""
-@@ -1157,6 +1246,7 @@ proper position among the other output f
+@@ -1159,6 +1247,7 @@ proper position among the other output f
 "%{flto|flto=*:%
Subject: Update debian patches for enabling git-updates.diff in 
gcc-12-12.2.0-14 and 17

Dear,

The patch git-updates.diff including bug fixes from release/gcc-12 branch have 
not been enabled in rules.patch, for gcc-12-12.2.0-14 and -17 (sid and exp).
( see  
https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-12-debian/debian/rules.patch
 line 15~17 )

To enable git-updates.diff, some of debian patches need to be updated :

debian/patches/gcc-distro-specs.diff
and
debian/patches/gcc-multilib-multiarch.diff

I made a patch to update these debian patches, so that the build of 
gcc-12-12.2.0-14 and -17 work normally, and PR 106322 is included.
[https://salsa.debian.org/assets/twitter_card-570ddb06edf56a2312253c5872489847a0f385112ddbcd71ccfa1570febab5d2.jpg]
debian/rules.patch · gcc-12-debian · Debian GCC Maintainers / GCC · 
GitLab
Debian Salsa Gitlab
salsa.debian.org




Thanks,
Best Regards,
Ricky X.Y. LIU





CONFIDENTIALITY NOTICE:

The content of this email and any attachments (“Email”) is confidential, may be 
privileged, subject to copyright and may be read, copied and used only by the 
intended recipient.

If you are not the intended recipient, please notify the sender by return email 
or telephone immediately and erase all copies (including any attachments) and 
do not disclose the Email or any part of it to any person. Any use, retention, 
disclosure, copying, printing, forwarding or dissemination of the Email is 
strictly prohibited if you are not the intended recipient.

ASTRI reserve the right to monitor all email communications through ASTRI’s 
networks.

Bug#1016903: Update debian patches for enabling git-updates.diff in gcc-12-12.2.0-14 and 17

[Ricky X. Y. LIU]

Dear,

The patch git-updates.diff including bug fixes from release/gcc-12 branch have 
not been enabled in rules.patch, for gcc-12-12.2.0-14 and -17 (sid and exp).
( see  
https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-12-debian/debian/rules.patch
 line 15~17 )

To enable git-updates.diff, some of debian patches need to be updated :

debian/patches/gcc-distro-specs.diff
and
debian/patches/gcc-multilib-multiarch.diff

I made a patch to update these debian patches, so that the build of 
gcc-12-12.2.0-14 and -17 work normally, and PR 106322 is included.
[https://salsa.debian.org/assets/twitter_card-570ddb06edf56a2312253c5872489847a0f385112ddbcd71ccfa1570febab5d2.jpg]
debian/rules.patch · gcc-12-debian · Debian GCC Maintainers / GCC · 
GitLab
Debian Salsa Gitlab
salsa.debian.org




Thanks,
Best Regards,
Ricky X.Y. LIU





CONFIDENTIALITY NOTICE:

The content of this email and any attachments (“Email”) is confidential, may be 
privileged, subject to copyright and may be read, copied and used only by the 
intended recipient.

If you are not the intended recipient, please notify the sender by return email 
or telephone immediately and erase all copies (including any attachments) and 
do not disclose the Email or any part of it to any person. Any use, retention, 
disclosure, copying, printing, forwarding or dissemination of the Email is 
strictly prohibited if you are not the intended recipient.

ASTRI reserve the right to monitor all email communications through ASTRI’s 
networks.


diff -Narup a/debian/patches/gcc-distro-specs.diff b/debian/patches/gcc-distro-specs.diff
--- a/debian/patches/gcc-distro-specs.diff	2022-10-31 21:50:28.0 +0800
+++ b/debian/patches/gcc-distro-specs.diff	2023-04-07 09:57:08.034297864 +0800
@@ -1,20 +1,19 @@
 # DP: Add empty distro and hardening specs
 
 a/src/gcc/gcc.cc
-+++ b/src/gcc/gcc.cc
-@@ -27,6 +27,11 @@ CC recognizes how to compile each input
- Once it knows which kind of compilation to perform, the procedure for
+--- a/src/gcc/gcc.cc	2023-04-06 08:20:07.0 +0800
 b/src/gcc/gcc.cc	2023-04-07 09:54:02.948157378 +0800
+@@ -28,6 +28,10 @@ Once it knows which kind of compilation
  compilation is specified by a string called a "spec".  */
  
+ #define INCLUDE_STRING
 +/* Inject some default compilation flags which are used as the default.
 +   Done by the packaging build system.  Should that be done in the headers
 +   gcc/config//*.h instead?  */
 +#include "distro-defaults.h"
-+
  #include "config.h"
  #include "system.h"
  #include "coretypes.h"
-@@ -984,6 +989,90 @@ proper position among the other output f
+@@ -986,6 +990,90 @@ proper position among the other output f
  #define LINK_GCC_C_SEQUENCE_SPEC "%G %{!nolibc:%L %G}"
  #endif
  
@@ -105,7 +104,7 @@
  #ifndef LINK_SSP_SPEC
  #ifdef TARGET_LIBC_PROVIDES_SSP
  #define LINK_SSP_SPEC "%{fstack-protector|fstack-protector-all" \
-@@ -1040,7 +1129,7 @@ proper position among the other output f
+@@ -1042,7 +1130,7 @@ proper position among the other output f
  #ifndef LINK_PIE_SPEC
  #ifdef HAVE_LD_PIE
  #ifndef LD_PIE_SPEC
@@ -114,7 +113,7 @@
  #endif
  #else
  #define LD_PIE_SPEC ""
-@@ -1157,6 +1246,7 @@ proper position among the other output f
+@@ -1159,6 +1247,7 @@ proper position among the other output f
 "%{flto|flto=*:%

Bug#1034022: zfs filesystems are mounted before local filesystems

[Antonio Russo]

Hello,

This is the use case for the zfs-mount-generator(8).

The man page EXAMPLES section has a quick start guide.

Best,
Antonio

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005318: Any update for this request?

[Winnie Yue]

Hi,

Could you please upgrade cloud-init to the latest release 23.1.1? Your help 
will be greatly appreciated. Thanks.

Best regards,
Winnie

Bug#1034040: How useful is debian/ibus-keyman.postinst?

[Gunnar Hjalmarsson]

Package: ibus-keyman
Version: 16.0.139-4

Hi!

Without being sure I actually found a bug, I would like to raise a 
discussion as a follow-up of  (which 
hasn't been well received so far). The unblock discussion made me aware 
of this script:


https://github.com/keymanapp/keyman/blob/master/linux/debian/ibus-keyman.postinst

The script makes me think of im-config, which sets the applicable 
environment variables and starts ibus-daemon at login.


I suppose the purpose with the script is to make ibus-keyman instantly 
usable in the same session as it is installed. I imagine that may work 
if ibus-daemon was already running and thus the needed environment 
variables already set for the session. But what if ibus was pulled as a 
dependency when installing ibus-keyman? Will keyman work in a meaningful 
way even if the variables are not present?


If the answer to that question is "no", wouldn't it be more 
straightforward to instruct the users to relogin before starting to use 
keyman, and thus drop the postinst script?


I may well have misunderstood it, and if so, I would appreciate a brief 
explanation of the intention with the script.


--
Rgds,
Gunnar

Bug#1034039: bullseye-pu: package libpod/3.0.1+dfsg1-3+deb11u1

[Reinhard Tartler]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: lib...@packages.debian.org, siret...@tauware.de
Control: affects -1 + src:libpod

[ Reason ]
This code change picks up code changes in golang-github-containers-psgo
and golang-github-containers-storage to fix CVE-2022-1227. This is reported
as 1020907. This addresses a priviledge escalation issue when using
'podman top'. Upstream has more information in this issue in
https://bugzilla.redhat.com/show_bug.cgi?id=2070368

Additionally, another upstream code change is being backported to address
CVE-2022-27649. This is reported as #1020906. This is to address a
capability escalation issue on file descriptors that were not intended
to have inheritable capabilities.

[ Impact ]
Without this update, users remain vulnerable to the issues explained above.

[ Tests ]
I've manually built and installed the built package in a kvm virtual machine
and conducted some basic tests.

[ Risks ]
All patches have been cherry picked from the branches that redhat also
includes in RHEL.

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

[ Changes ]
diff --git a/debian/changelog b/debian/changelog
index 12a2268bb..dbd215727 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+libpod (3.0.1+dfsg1-3+deb11u2) bullseye; urgency=medium
+
+  * CVE-2022-1227: pickup changes in containers/psgo, Closes: #1020907
+  * CVE-2022-27649: do not set the inheritable capabilities, Closes: #1020906
+
+ -- Reinhard Tartler   Wed, 05 Apr 2023 21:00:36 -0400
+
 libpod (3.0.1+dfsg1-3+deb11u1) bullseye; urgency=medium
 
   * Rebuild against containers-common to pickup seccomp updates required
diff --git a/debian/control b/debian/control
index 3df797b30..a8834b883 100644
--- a/debian/control
+++ b/debian/control
@@ -21,8 +21,8 @@ Build-Depends: debhelper-compat (= 12)
 ,golang-github-containers-common-dev (>= 0.33.4+ds1-1+deb11u1)
 ,golang-github-containers-image-dev (>= 5.10.2)
 ,golang-github-containers-ocicrypt-dev
-,golang-github-containers-psgo-dev
-,golang-github-containers-storage-dev (>= 1.24.6)
+,golang-github-containers-psgo-dev (>= 1.5.2-1+deb11u1)
+,golang-github-containers-storage-dev (>= 1.24.6+dfsg1-1+deb11u1)
 ,golang-github-coreos-bbolt-dev (>= 1.3.3~)
 ,golang-github-coreos-go-iptables-dev (>= 0.4.2~)
 ,golang-github-coreos-go-systemd-dev (>= 20~)
diff --git a/debian/patches/0001-do-not-set-the-inheritable-capabilities.patch 
b/debian/patches/0001-do-not-set-the-inheritable-capabilities.patch
new file mode 100644
index 0..3d7666b91
--- /dev/null
+++ b/debian/patches/0001-do-not-set-the-inheritable-capabilities.patch
@@ -0,0 +1,109 @@
+From d2848c0281ed94992c4b23c5899e36afc1af Mon Sep 17 00:00:00 2001
+From: Andre Moreira Magalhaes 
+Date: Mon, 19 Sep 2022 11:03:21 -0300
+Subject: [PATCH] do not set the inheritable capabilities
+
+The kernel never sets the inheritable capabilities for a process, they
+are only set by userspace.  Emulate the same behavior.
+
+Closes: CVE-2022-27649
+
+(backported from upstream commit 7b368768c2990b9781b2b6813e1c7f91c7e6cb13)
+---
+ libpod/oci_conmon_linux.go   | 7 +--
+ pkg/specgen/generate/security.go | 7 +--
+ test/e2e/run_test.go | 6 +++---
+ 3 files changed, 13 insertions(+), 7 deletions(-)
+
+diff --git a/libpod/oci_conmon_linux.go b/libpod/oci_conmon_linux.go
+index 38ffba7d2..b073feee1 100644
+--- a/libpod/oci_conmon_linux.go
 b/libpod/oci_conmon_linux.go
+@@ -1281,11 +1281,14 @@ func prepareProcessExec(c *Container, options 
*ExecOptions, env []string, sessio
+   } else {
+   pspec.Capabilities.Bounding = 
ctrSpec.Process.Capabilities.Bounding
+   }
++
++  // Always unset the inheritable capabilities similarly to what the 
Linux kernel does
++  // They are used only when using capabilities with uid != 0.
++  pspec.Capabilities.Inheritable = []string{}
++
+   if execUser.Uid == 0 {
+   pspec.Capabilities.Effective = pspec.Capabilities.Bounding
+-  pspec.Capabilities.Inheritable = pspec.Capabilities.Bounding
+   pspec.Capabilities.Permitted = pspec.Capabilities.Bounding
+-  pspec.Capabilities.Ambient = pspec.Capabilities.Bounding
+   } else {
+   if user == c.config.User {
+   pspec.Capabilities.Effective = 
ctrSpec.Process.Capabilities.Effective
+diff --git a/pkg/specgen/generate/security.go 
b/pkg/specgen/generate/security.go
+index fb45d87db..c18f83217 100644
+--- a/pkg/specgen/generate/security.go
 b/pkg/specgen/generate/security.go
+@@ -130,6 +130,10 @@ func securityConfigureGenerator(s *specgen.SpecGenerator, 
g *generate.Generator,
+ 
+   configSpec := g.Config
+   

Bug#1034038: Please push babel.sty v3.87 or later into the upcoming distribution

[Al Ma]

Package: texlive-latex-base
Version: 2022.20230122-2
Severity: wishlist
Please push the changes in babel.dtx due to commit cd59ff0 (cf. 
https://github.com/latex3/babel/commit/cd59ff0, 
https://github.com/latex3/babel/commit/cd59ff0, changes in line 15797-15798) 
into Debian.  This amounts to babel v3.87 or later and solves 
https://tex.stackexchange.com/questions/680690 
https://tex.stackexchange.com/questions/680690.  Ideally, the update should 
have a chance to propagate to the upcoming stable before the final freeze.
Gratefully,
Alma

Bug#1033921: debian-installer: Weekly build of d-i fails to find ipw2x00 firmware package

[Pascal Hambourg]

On 06/04/2023 at 20:56, Cyril Brulebois wrote:

Pascal Hambourg  (2023-04-06):

A difference between the two relevant sections in check-missing-firmware is
that install_firmware_pkg() is executed in a pipeline when a
Contents-firmware file is present, and not when it is not present. I do not
know enough about debconf to figure out how the pipeline may interfere with
it. Maybe something to do with standard input and output ?


Very useful information, thanks.

And yes, something related to pipes and possibly some missing passthrough
setting was my wild guess (as rubberducked on IRC), so that seems plausible.


Ugly attached patch works for me as PoC.
Copy fd 0 into fd 9 (because it looked unused) before entering the 
pipeline, and restore it when running install_firmware_pkg.diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh
index 5db0e180..efdecf6f 100755
--- a/check-missing-firmware.sh
+++ b/check-missing-firmware.sh
@@ -324,6 +324,7 @@ check_for_firmware() {
 		# packages, saving us from iterating over each firmware *.deb:
 		if [ -f $dir/Contents-firmware ]; then
 			log "lookup with $dir/Contents-firmware"
+			{
 			grep -f /tmp/grepfor $dir/Contents-firmware | while read fw_file fw_pkg_file component; do
 # Don't install a package for each file it ships!
 if grep -qs "^$fw_pkg_file$" /tmp/pkginstalled 2>/dev/null; then
@@ -331,10 +332,11 @@ check_for_firmware() {
 fi
 if check_deb_arch "$dir/$fw_pkg_file"; then
 	log "installing firmware package $dir/$fw_pkg_file ($component)"
-	install_firmware_pkg "$dir/$fw_pkg_file" "$component" || true
+	install_firmware_pkg "$dir/$fw_pkg_file" "$component" <&9 || true
 	echo "$fw_pkg_file" >> /tmp/pkginstalled
 fi
 			done
+			} 9<&0
 			continue
 		fi
 

Bug#1034037: unblock: qt6-tools/6.4.2-1

[Patrick Franz]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: delta...@debian.org

Please unblock package qt6-tools

[ Reason ]
Qt 6.4.2 was released in January 2023. In order to get the transition done in 
time,
we received pre-release tarballs from The Qt Company to prepare the packaging 
and we
completed the transition in time.
Since those were pre-release tarballs, we marked the version as 6.4.2~rc1. 
After the
release, it turned out that the pre-release tarballs were identical to the 
official
6.4.2 tarballs. We then reuploaded every package and marked the packages as 
version
6.4.2 to reflect this.
The rc1 version of qt6-tools is in bookworm, but the "official" 6.4.2 is not 
yet.
It was uploaded in January, but its migration has been blocked by 
llvm-toolchain-15.

We'd like to request an unblock such that qt6-tools 6.4.2-1 can migrate to 
testing 
once llvm-toolchain-15 has migrated.

[ Impact ]
The impact is minimal as this is merely a cosmetic change.

[ Tests ]
No additional tests have been run.

[ Risks ]
The risks are minimal as it is the same tarball simply rebuilt.
The checksums for both tarballs are identical, see
https://tracker.debian.org/news/1402882/accepted-qt6-tools-642rc1-1-source-into-experimental/
and
https://tracker.debian.org/news/1414695/accepted-qt6-tools-642-1-source-into-unstable/

[ 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 testing

[ Other info ]
-

unblock qt6-tools/6.4.2-1
diffstat for qt6-tools-6.4.2~rc1 qt6-tools-6.4.2

 changelog |7 +++
 1 file changed, 7 insertions(+)

diff -Nru qt6-tools-6.4.2~rc1/debian/changelog qt6-tools-6.4.2/debian/changelog
--- qt6-tools-6.4.2~rc1/debian/changelog2022-12-30 16:59:08.0 
+0100
+++ qt6-tools-6.4.2/debian/changelog2023-01-29 00:54:45.0 +0100
@@ -1,3 +1,10 @@
+qt6-tools (6.4.2-1) unstable; urgency=medium
+
+  [ Patrick Franz ]
+  * Switch to the official 6.4.2 tarball, the tarball is the same.
+
+ -- Patrick Franz   Sun, 29 Jan 2023 00:54:45 +0100
+
 qt6-tools (6.4.2~rc1-2) unstable; urgency=medium
 
   [ Patrick Franz ]

Bug#1034036: galternatives doesn't set the default browser

[Ron Murray]

Package: galternatives
Version: 1.0.9
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

   I'm not sure what package to file this bug under, but I picked
galternatives because it's probably the most common way Debian users
(and others?) want to change default applications. Note that, as far
as I know, there's nothing wrong with galternatives itself: please
assign this bug to whichever package you consider to be most
appropriate.

   It all started when I installed the Vivaldi browser on my Debian
testing system. It worked fine in itself, but when I clicked on a link
in an email (using evolution and bluemail gave the same result), it
brought up vivaldi instead of my regular browser (Firefox). I checked
/etc/alternatives/x-www-browser, and it pointed to Firefox, just as
I'd set it. Still, clicking on email links brought up vivaldi instead
of Firefox.

   It's taken me quite some time to find out why this is happening. I
first discovered, using 'ps auxf', that the instance of vivaldi
brought up by clicking on an email link was called by
'/lib/systemd/systemd --user'. So systemd was involved. The plot
thickened.

   Today, I figured it out. Gnome. Now, I don't have Gnome installed
on my Debian testing box, but I installed it on a VM, and found that
gnome-control-center sets these things, *even when you don't have
Gnome installed*. I installed just gnome-control-center on my Debian
testing box, set it up as I wanted, and now clicking on an email link
brings up Firefox, as it's supposed to.

   This means that, for some default applications anyway,
galternatives is useless for setting them up, and, unless you have
gnome-control-center installed, there's no way to set them up at all.

   I'm not sure what the solution is here. Perhaps galternatives could
be modified to fix it, or perhaps a new application is in
order. Another alternative would be to install gnome-control-center at
all times, and provide instructions to use it if needed. (I don't
recommend this: the thing's ugly).

 .Ron Murray

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

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

Versions of packages galternatives depends on:
ii  gir1.2-gdkpixbuf-2.0  2.42.10+dfsg-1+b1
ii  gir1.2-gtk-3.03.24.37-2
ii  python3   3.11.2-1
ii  python3-gi3.42.2-3+b1

Versions of packages galternatives recommends:
ii  pkexec   122-3
ii  python3-xdg  0.28-2

galternatives suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJCBAEBCgAsFiEETZlw4yMXM0sUHntjEvfoZbXi52EFAmQvSEkOHHJqbXhAcmpt
eC5uZXQACgkQEvfoZbXi52Hm5w//VU59thhwWZgh1SoYF9+WleEsQUdacsSj+6m9
xMiHC83wiXDyXLA4TeYYD3qddIGTCr5dekgRrK4SX+ZF1a1YSdm3iw/NPXpFf8Yy
ASLhSU3b7FpzJjH+vmzCbQ6asYngmSRtLYGMgcbASh+0GgFQbZh9GsvBGJp3yu5x
Byrm5lUnu9gNZfGmAqSnsUhL9xJmpppvYKe3Ojknw1EXwMTKx/iCoNZDyzJ8bGO5
QsDrDPWKGK6O3tyTPEqYwaHN0PPw+1wJjGAEPhC8tAmO5dNtbLN0JDWtREiYG1Fv
9SUsmg3Jp//2bPfpqCOVrlm2obowmO8eV3R/4GL8mQDXmMMPTGRyI7nHDYn+hzLZ
89sCH32+vJ0i8if2yJP1lk938e9Yvko9gjKSnbB8Bz5aWiYtxMHbhWE5lTHJ1MrK
0IaaAbEcs4C/3bEPVyFtAVims/33+g6QgiOkQN48DJIQceLDymKFhxkR+9gcJ4OB
pOWsZN8E3A/6LnCxv0WdBqHvfl+rniwRwIP2Uk8A8SUxbiP1rVhmIS/eyJ1ARF3z
miAhOieNFpxwioba9EKRWknlA56qW5Aj19+yQOy7lhz3dRmHNWQH/WjH6ICBfznd
bGrAQxpnN/6PenJL21b5wqyEShzKv+g/CRSP/Ws9g7VHBjCdMNu+F14R0bAsXQXj
7B0CYp8=
=gwca
-END PGP SIGNATURE-

Bug#1034035: linux-image-6.1.0-7-amd64: linux image installation fails dkms step if headers are absent

[Russ Hamilton]

Package: linux-image-6.1.0-7-amd64
Version: linux-image-6.1.0-7-amd64
Severity: normal
X-Debbugs-Cc: brusshamil...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
I was trying to install the linux-image-6.1.0-7-amd64 package on my bullseye
system (needed newer drivers).
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I enabled the debian unstable list in my apt sources, but pinned a preference
for bullseye packages.
Then I ran `sudo apt-get install linux-image-6.1.0-7-amd64`
   * What was the outcome of this action?
The installation appeared to have succeeded (apt returned succeess), but on
further examination kernel modules for necessary drivers were missing. A close
inspection of the installation log revealed the lines:
```
/etc/kernel/postinst.d/dkms:
dkms: running auto installation service for kernel 6.1.0-7-amd64:Error! Your
kernel headers for kernel 6.1.0-7-amd64 cannot be found.
Please install the linux-headers-6.1.0-7-amd64 package,
or use the --kernelsourcedir option to tell DKMS where it's located
.
```
   * What outcome did you expect instead?
I expected either the linux 6.1.0 kernel image to be installed and any dynamic
kernel modules built or for the installation to fail due to impossible
dependencies.


Comments:
1. If the kernel installation requires the headers to function properly, then
they should probably be a package dependency.
2. If dkms fails then we should probably consider the linux image installation
as having failed and revert to a consistent state instead of continuing.

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

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

Versions of packages linux-image-6.1.0-7-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.140
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-6.1.0-7-amd64 recommends:
ii  apparmor 2.13.6-10
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.1.0-7-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-efi-amd64  2.06-3~deb11u5

Bug#1033802: dropbear-initramfs: sleep and cat not found

[Guilhem Moulin]

On Thu, 06 Apr 2023 at 23:15:59 +0200, Guilhem Moulin wrote:
> On Thu, 06 Apr 2023 at 18:56:49 +0200, William Desportes wrote:
>> The system does not have ipconfig installed,
>
> What do you mean?  Your main system (outside) initramfs stage might lack

Misplaced parenthesis, that should have been “Your main system (outside
initramfs stage) might lack …”

> Anyway, the ‘/run/net-*.conf’ glob and the ipconfig call both come
> initramfs-tools' configure_networking().  As I wrote before if these
> fail it's most likely because there is nothing blocking at initramfs
> stage, so execution is handed over to init(1) before
> configure_networking() has a chance to terminate (it runs in the
> background).  This, again, smells like #1015810.

What are you trying to do by the way?  Are you installing
dropbear-initramfs on that machine not because you *need* to get a
remote initramfs shell in order to boot, but to have a way to remotely
access access the machine should something break at early boot stage?

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1033995: qtbase-opensource-src: Fix accessibility of qt5 applications run as root

[Samuel Thibault]

Hello,

Dmitry Shachnev, le jeu. 06 avril 2023 22:15:01 +0300, a ecrit:
> On Thu, Apr 06, 2023 at 06:20:04PM +0200, Samuel Thibault wrote:
> > Oh, I didn't notice that there was a recorded test failure.
> >
> > I don't see how the failure can be related to the change...
> >
> > Cc-ing Frederik, in case he remembers / realizes something.
> 
> I just want to add some context. We are talking about this change:
> 
> https://codereview.qt-project.org/c/qt/qtbase/+/205196
> 
> Frederik, perhaps you can rebase and see if the tests still fail?

Not sure Frederik is still working for KDE, I have pushed the rebase,
let's see.

Samuel

Bug#1029218: dkms should perform reproducible build of modules

[Daniel Richard G.]

On Tue, 2023 Apr  4 12:07-04:00, Andreas Beckmann wrote:
> We should probably file a bug against diffoscope to make it aware of 
> this file "modification"

Done: https://bugs.debian.org/1034034

Please tweak or elaborate as needed.

>> Is a unique signature being added to the modules? I noticed that
>> /var/lib/dkms/mok.{key,pub} differ between the two systems.
>
> That's probably the reason. Not sure if something could/should be
> done about that difference. We should probably take this to the
> reproducible builds people
> https://wiki.debian.org/ReproducibleBuilds ...

My thoughts would be

1. I'm vaguely aware that on secure-boot-enabled systems, the kernel and
   kernel modules need to be signed. But setting that up for things one
   builds themselves is non-trivial (the whole key-enrolling mess), and
   necessarily needs to be opt-in. My expectation is that if one doesn't
   explicitly request that, no signing should be performed (the
   signatures would be either unused or rejected anyway), and thus no
   caveat should need to be made on kernel modules differing.

2. Can't these things use a detached signature? That would make the
   reproducible aspect much easier to deal with.

(Is dkms the proper place to address this?)


--Daniel


-- 
Daniel Richard G. || sk...@iskunk.org
My ASCII-art .sig got a bad case of Times New Roman.

Bug#1033802: dropbear-initramfs: sleep and cat not found

[Guilhem Moulin]

On Thu, 06 Apr 2023 at 18:56:49 +0200, William Desportes wrote:
> with cryptsetup it does not like rescue mode initramfs updates.

Hm?  Installing cryptsetup-initramfs, and letting it unlock devices
(incl.  those holding the root FS) at early boot stage, definitely
doesn't prevent rescue mode or getting an initramfs shell.

> That said I have a new one (I did not install the basic system utilities):
>
> It now says: init-premount/dropbear: line 366: ipconfig: not found
>
> And right after the message about net-*.conf

dropbear-initramfs doesn't call ipconfig or configure the network
directly.  All it does is: call initramfs-tools' configure_networking()
at init-premount stage, and bring the interface down at init-bottom
stage.

> The system does not have ipconfig installed,

What do you mean?  Your main system (outside) initramfs stage might lack
/usr/bin/ipconfig but that is irrelevant.  What matters is that the
binary is available at initramfs stage.

> I would say this is a bug that should be fixed in the dropbear script.
> Or added a as a package dependency/requirement ?

Nope.  The /usr/bin/ipconfig binary from the initramfs image comes from
/usr/lib/klibc/bin/ipconfig which dropbear-initramfs indirectly has a
hard Depends: on…

Anyway, the ‘/run/net-*.conf’ glob and the ipconfig call both come
initramfs-tools' configure_networking().  As I wrote before if these
fail it's most likely because there is nothing blocking at initramfs
stage, so execution is handed over to init(1) before
configure_networking() has a chance to terminate (it runs in the
background).  This, again, smells like #1015810.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#1034033: upgrading to bookworm created problems by forcing me to rewrite ".so" / config files.

[Elias Tsolis]

Package:|maintonly|

My syslog is full of such messages reaching gigas. What to do? I try 
to trunctuate logs. I know about logrotation.


These bugs happened after upgrading to bookworm sid debian. I 
installed 2.7.6.1 glib from source succesfully.


Two problems mainly exists:

  * fuse: failed to access mountpoint /run/user/1000/gvfs: Transport
endpoint is not connected" and
  * undefined symbol "g_task_set_static_name"

For the 2nd one I think - in upgrading process - i have overwritten 
some .so/config files (otherwise no upgrade). Normally, i think, glib 
installation must "rewrite" those ones. But i have found from other 
programs that this is not the case. So i deleted them by searching 
wrong / older associations. Here, I dont know what is the wrong 
association / older versions.


Purging / removing glibs is not solution, 11GB claims to uninstall 
with hundred of packages. So, I would like to find specific files or 
associations that are wrong and to replace them.


```
|Apr 05 22:58:47 eliasc systemd[1250]: Starting gvfs-daemon.service - 
Virtual filesystem service... Apr 05 22:58:47 eliasc 
dbus-daemon[1962]: [session uid=1000 pid=1962] Successfully activated 
service 'org.gtk.vfs.Daemon' Apr 05 22:58:47 eliasc systemd[1250]: 
Started gvfs-daemon.service - Virtual filesystem service. Apr 05 
22:58:47 eliasc gvfsd[3236934]: fuse: failed to access mountpoint 
/run/user/1000/gvfs: Transport endpoint is not connected Apr 05 
22:58:47 eliasc gvfsd[3236935]: /usr/local/libexec/gvfsd-trash: 
symbol lookup error: 
/usr/local/lib/x86_64-linux-gnu/gvfs/libgvfsdaemon.so: undefined 
symbol: g_task_set_static_name Apr 05 22:58:47 eliasc gvfsd[3236929]: 
g_dbus_method_invocation_return_error: assertion 
'G_IS_DBUS_METHOD_INVOCATION (invocation)' failed Apr 05 22:58:47 
eliasc kernel: gvfsd[3236929]: segfault at 5558b66d4a06 ip 
7f291fbef645 sp 7fff7851e8f8 error 4 in 
libgobject-2.0.so.0.7400.6[7f291fbc5000+32000] Apr 05 22:58:47 eliasc 
kernel: Code: 00 00 00 00 00 48 c1 ed 02 48 8d 05 75 4d 02 00 48 8b 
34 e8 eb bc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 85 ff 74 
4b <48> 8b 07 48 85 c0 74 43 48 8b 00 48 3d fc 03 00 00 76 18 48 83 
e0 Apr 05 22:58:47 eliasc systemd[1250]: gvfs-daemon.service: Main 
process exited, code=dumped, status=11/SEGV Apr 05 22:58:47 eliasc 
systemd[1250]: gvfs-daemon.service: Failed with result 'core-dump'. 
Apr 05 22:58:52 eliasc dbus-daemon[1962]: [session uid=1000 pid=1962] 
Activating via systemd: service name='org.gtk.vfs.Daemon' 
unit='gvfs-daemon.service' requested by ':1.311988' (uid=1000 
pid=2870626 comm="/opt/firefox/firefox" label="unconfined") Apr 05 
22:58:52 eliasc systemd[1250]: Starting gvfs-daemon.service - Virtual 
filesystem service... Apr 05 22:58:52 eliasc dbus-daemon[1962]: 
[session uid=1000 pid=1962] Successfully activated service 
'org.gtk.vfs.Daemon' Apr 05 22:58:52 eliasc systemd[1250]: Started 
gvfs-daemon.service - Virtual filesystem service. Apr 05 22:58:52 
eliasc gvfsd[3236946]: fuse: failed to access mountpoint 
/run/user/1000/gvfs: Transport endpoint is not connected Apr 05 
22:58:52 eliasc gvfsd[3236947]: /usr/local/libexec/gvfsd-trash: 
symbol lookup error: 
/usr/local/lib/x86_64-linux-gnu/gvfs/libgvfsdaemon.so: undefined 
symbol: g_task_set_static_name Apr 05 22:58:52 eliasc gvfsd[3236941]: 
g_dbus_method_invocation_return_error: assertion 
'G_IS_DBUS_METHOD_INVOCATION (invocation)' failed Apr 05 22:58:52 
eliasc kernel: gvfsd[3236941]: segfault at 557b24d4d03a ip 
7f50a16a5645 sp 7ffe1db4ad08 error 4 in 
libgobject-2.0.so.0.7400.6[7f50a167b000+32000] Apr 05 22:58:52 eliasc 
kernel: Code: 00 00 00 00 00 48 c1 ed 02 48 8d 05 75 4d 02 00 48 8b 
34 e8 eb bc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 85 ff 74 
4b <48> 8b 07 48 85 c0 74 43 48 8b 00 48 3d fc 03 00 00 76 18 48 83 
e0 Apr 05 22:58:52 eliasc systemd[1250]: gvfs-daemon.service: Main 
process exited, code=dumped, status=11/SEGV Apr 05 22:58:52 eliasc 
systemd[1250]: gvfs-daemon.service: Failed with result 'core-dump'. 
Apr 05 22:58:57 eliasc dbus-daemon[1962]: [session uid=1000 pid=1962] 
Activating via systemd: service name='org.gtk.vfs.Daemon' 
unit='gvfs-daemon.service' requested by ':1.311988' (uid=1000 
pid=2870626 comm="/opt/firefox/firefox" label="unconfined") Apr 05 
22:58:57 eliasc systemd[1250]: Starting gvfs-daemon.service - Virtual 
filesystem service... Apr 05 22:58:57 eliasc dbus-daemon[1962]: 
[session uid=1000 pid=1962] Successfully activated service 
'org.gtk.vfs.Daemon' Apr 05 22:58:57 eliasc systemd[1250]: Started 
gvfs-daemon.service - Virtual filesystem service. Apr 05 22:58:57 
eliasc gvfsd[3236957]: fuse: failed to access mountpoint 
/run/user/1000/gvfs: Transport endpoint is not connected Apr 05 
22:58:57 eliasc gvfsd[3236958]: /usr/local/libexec/gvfsd-trash: 
symbol lookup error: 
/usr/local/lib/x86_64-linux-gnu/gvfs/libgvfsdaemon.so: undefined 
symbol: g_task_set_static_name Apr 

Bug#1032104: linux: ppc64el iouring corrupted read

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi
On Sun, Mar 19, 2023 at 05:02:19PM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Sat, Mar 18, 2023 at 11:19:29PM -0700, Otto Kekäläinen wrote:
> > Any updates on this one?
> > 
> > I am still seeing the main.index_merge_innodb failure in
> > https://buildd.debian.org/status/fetch.php?pkg=mariadb=ppc64el=1%3A10.11.2-2%7Eexp1=1678728871=0
> > and rebuild 
> > https://buildd.debian.org/status/fetch.php?pkg=mariadb=ppc64el=1%3A10.11.2-2%7Eexp1=1679174850=0.
> > 
> > Logs show: Kernel: Linux 5.10.0-21-powerpc64le #1 SMP Debian
> > 5.10.162-1 (2023-01-21) ppc64el (ppc64le)
> 
> Remember that with the 5.10.162 upstream version the io_uring code was
> rebased to the 5.15-stable one. So it is likely, and it maches the
> verison ranges, that the regression was introduced with this
> particular changes. Ideally someone with access to the given
> architecture, can verify that the issue is gone with the current
> 5.10.175 upstream (where there were several followup fixes, in
> particular e.g. a similar one for s390x), and if not, reports the
> problem to upstream.
> 
> Paul Gevers asked if the issues are gone as well with 6.1.12-1
> (or later 6.1.y series versions, which will land in bookworm). That
> would be valuable information to know as well to exclude we do not
> have the issue as well in bookworm.

Were you able to verify this?

Regards,
Salvatore

Bug#1034032: rust-bitflags: autopkgtest regression: error[E0277]: the trait bound `SerdeFlags: Deserialize<'_>` is not satisfied

[Paul Gevers]

Source: rust-bitflags
Version: 1.3.2-2
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails. Can you 
please investigate the situation and fix it? I copied some of the output 
at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-bitflags/32255138/log.gz

 Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=glob 
CARGO_MANIFEST_DIR=/tmp/tmp.u55zB0qp8W/registry/glob-0.3.0 
CARGO_PKG_AUTHORS='The Rust Project Developers' 
CARGO_PKG_DESCRIPTION='Support for matching file paths against Unix 
shell style patterns.
' CARGO_PKG_HOMEPAGE='https://github.com/rust-lang/glob' 
CARGO_PKG_LICENSE=MIT/Apache-2.0 CARGO_PKG_LICENSE_FILE='' 
CARGO_PKG_NAME=glob 
CARGO_PKG_REPOSITORY='https://github.com/rust-lang/glob' 
CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=0.3.0 
CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=3 
CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' 
LD_LIBRARY_PATH='/tmp/tmp.u55zB0qp8W/target/debug/deps:/usr/lib' rustc 
--crate-name glob /tmp/tmp.u55zB0qp8W/registry/glob-0.3.0/src/lib.rs 
--error-format=json 
--json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type 
lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -C 
metadata=18ed03da62dd1beb -C extra-filename=-18ed03da62dd1beb --out-dir 
/tmp/tmp.u55zB0qp8W/target/x86_64-unknown-linux-gnu/debug/deps --target 
x86_64-unknown-linux-gnu -L 
dependency=/tmp/tmp.u55zB0qp8W/target/x86_64-unknown-linux-gnu/debug/deps 
-L dependency=/tmp/tmp.u55zB0qp8W/target/debug/deps --cap-lints warn -C 
debuginfo=2 --cap-lints warn -C linker=x86_64-linux-gnu-gcc -C 
link-arg=-Wl,-z,relro --remap-path-prefix 
/usr/share/cargo/registry/bitflags-1.3.2=/usr/share/cargo/registry/bitflags-1.3.2 
--remap-path-prefix /tmp/tmp.u55zB0qp8W/registry=/usr/share/cargo/registry`

warning: trait objects without an explicit `dyn` are deprecated
   --> /usr/share/cargo/registry/glob-0.3.0/src/lib.rs:294:32
|
294 | fn cause() -> Option<> {
|^
|
= note: `#[warn(bare_trait_objects)]` on by default
= warning: this is accepted in the current edition (Rust 2015) but 
is a hard error in Rust 2021!
= note: for more information, see 


help: use `dyn`
|
294 - fn cause() -> Option<> {
294 + fn cause() -> Option< Error> {
|

warning: use of deprecated associated function 
`std::error::Error::description`: use the Display impl or to_string()

   --> /usr/share/cargo/registry/glob-0.3.0/src/lib.rs:291:20
|
291 | self.error.description()
|^^^
|
= note: `#[warn(deprecated)]` on by default

warning: `glob` (lib) generated 2 warnings
   Compiling once_cell v1.17.0
 Running `CARGO=/usr/bin/cargo CARGO_CRATE_NAME=once_cell 
CARGO_MANIFEST_DIR=/tmp/tmp.u55zB0qp8W/registry/once_cell-1.17.0 
CARGO_PKG_AUTHORS='Aleksey Kladov ' 
CARGO_PKG_DESCRIPTION='Single assignment cells and lazy values.' 
CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='MIT OR Apache-2.0' 
CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=once_cell 
CARGO_PKG_REPOSITORY='https://github.com/matklad/once_cell' 
CARGO_PKG_RUST_VERSION=1.56 CARGO_PKG_VERSION=1.17.0 
CARGO_PKG_VERSION_MAJOR=1 CARGO_PKG_VERSION_MINOR=17 
CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE='' 
LD_LIBRARY_PATH='/tmp/tmp.u55zB0qp8W/target/debug/deps:/usr/lib' rustc 
--crate-name once_cell --edition=2021 
/tmp/tmp.u55zB0qp8W/registry/once_cell-1.17.0/src/lib.rs 
--error-format=json 
--json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type 
lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 
--cfg 'feature="alloc"' --cfg 'feature="default"' --cfg 'feature="race"' 
--cfg 'feature="std"' -C metadata=de70ba2dc91f60b7 -C 
extra-filename=-de70ba2dc91f60b7 --out-dir 
/tmp/tmp.u55zB0qp8W/target/x86_64-unknown-linux-gnu/debug/deps --target 
x86_64-unknown-linux-gnu -L 
dependency=/tmp/tmp.u55zB0qp8W/target/x86_64-unknown-linux-gnu/debug/deps 
-L dependency=/tmp/tmp.u55zB0qp8W/target/debug/deps --cap-lints warn -C 
debuginfo=2 --cap-lints warn -C linker=x86_64-linux-gnu-gcc -C 
link-arg=-Wl,-z,relro --remap-path-prefix 
/usr/share/cargo/registry/bitflags-1.3.2=/usr/share/cargo/registry/bitflags-1.3.2 
--remap-path-prefix 

Bug#1034030: rust-async-stream: autopkgtest regression: error[E0658]: yield syntax is experimental

[Paul Gevers]

Source: rust-async-stream
Version: 0.3.3-1
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails since December 
2022. Can you please investigate the situation and fix it? I copied some 
of the output at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-async-stream/32102899/log.gz

test tests/ui/yield_in_async.rs ... mismatch

EXPECTED:

error[E0658]: yield syntax is experimental
 --> tests/ui/yield_in_async.rs:6:13
  |
6 | yield 123;
  | ^
  |
  = note: see issue #43122 
 for more information


error[E0727]: `async` generators are not yet supported
 --> tests/ui/yield_in_async.rs:6:13
  |
6 | yield 123;
  | ^

error[E0271]: type mismatch resolving `<[static 
generator@$DIR/src/lib.rs:201:9: 201:67] as Generator>::Yield 
== ()`

  --> tests/ui/yield_in_async.rs:4:5
   |
4  | / stream! {
5  | | let f = async {
6  | | yield 123;
7  | | };
8  | |
9  | | let v = f.await;
10 | | };
   | |_^ expected `()`, found integer
   |
note: required by a bound in `from_generator`
  --> $RUST/core/src/future/mod.rs
   |
   | T: Generator,
   |^^ required by this bound in 
`from_generator`
   = note: this error originates in the macro `stream` (in Nightly 
builds, run with -Z macro-backtrace for more info)



ACTUAL OUTPUT:

error[E0658]: yield syntax is experimental
 --> tests/ui/yield_in_async.rs:6:13
  |
6 | yield 123;
  | ^
  |
  = note: see issue #43122 
 for more information


error[E0727]: `async` generators are not yet supported
 --> tests/ui/yield_in_async.rs:6:13
  |
6 | yield 123;
  | ^

error[E0271]: type mismatch resolving `<[static 
generator@$DIR/src/lib.rs:201:9: 201:67] as Generator>::Yield 
== ()`

  --> tests/ui/yield_in_async.rs:4:5
   |
4  | / stream! {
5  | | let f = async {
6  | | yield 123;
7  | | };
8  | |
9  | | let v = f.await;
10 | | };
   | |_^ expected `()`, found integer
   |
note: required by a bound in `std::future::from_generator`
   = note: this error originates in the macro `stream` (in Nightly 
builds, run with -Z macro-backtrace for more info)


note: If the actual output is the correct output you can bless it by 
rerunning

  your test with the environment variable TRYBUILD=overwrite

test tests/ui/yield_in_closure.rs ... mismatch

EXPECTED:

error[E0658]: yield syntax is experimental
 --> tests/ui/yield_in_closure.rs:7:17
  |
7 | yield v;
  | ^^^
  |
  = note: see issue #43122 
 for more information


error[E0277]: expected a `FnOnce<(,)>` closure, found 
`[generator@$DIR/src/lib.rs:201:9: 201:67]`

--> tests/ui/yield_in_closure.rs:6:14
 |
6| .and_then(|v| {
 |   expected an `FnOnce<(,)>` closure, 
found `[generator@$DIR/src/lib.rs:201:9: 201:67]`

 |
 = help: the trait `FnOnce<(,)>` is not implemented for 
`[generator@$DIR/src/lib.rs:201:9: 201:67]`

note: required by a bound in `Resultand_then`
--> $RUST/core/src/result.rs
 |
 | pub fn and_then Result>(self, op: 
F) -> Result {
 |   ^ required by 
this bound in `Resultand_then`



ACTUAL OUTPUT:

error[E0658]: yield syntax is experimental
 --> tests/ui/yield_in_closure.rs:7:17
  |
7 | yield v;
  | ^^^
  |
  = note: see issue #43122 
 for more information


error[E0277]: expected a `FnOnce<(,)>` closure, found 
`[generator@$DIR/src/lib.rs:201:9: 201:67]`

 --> tests/ui/yield_in_closure.rs:6:14
  |
6 

Bug#1034029: debian-edu-router: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: debian-edu-router
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034028: ruby-rails-assets-jquery: autopkgtest regression: Don't know how to build task 'assets:precompile'

[Paul Gevers]

Source: ruby-rails-assets-jquery
Version: 3.5.1+dfsg-1
Severity: serious
Control: tags -1 bookworm-ignore
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails since November 
2021. Can you please investigate the situation and fix it? I copied some 
of the output at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-rails-assets-jquery/32420365/log.gz

Use `bundle info [gemname]` to see where a bundled gem is installed.
+ cat
+ cat
+ cat
+ cat
+ bundle exec rake assets:precompile
rake aborted!
Don't know how to build task 'assets:precompile' (See the list of 
available tasks with `rake --tasks`)


(See full trace by running task with --trace)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#946846: The autopkgtests are failing with the current rails version

[Paul Gevers]

Control: severity -1 serious
Control: tags -1 bookworm-ignore

Hi,

On Mon, 16 Dec 2019 14:53:18 +0100 Sebastien Bacher  
wrote:

Package: ruby-rails-assets-highlightjs
Version:
9.12.0-2

The autopkgtest have been failing for a while
https://ci.debian.net/packages/r/ruby-rails-assets-highlightjs/unstable/amd64/

FileNotFound: couldn't find file 'activestorage' with type 
'application/javascript'


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033995: qtbase-opensource-src: Fix accessibility of qt5 applications run as root

[Dmitry Shachnev]

Hi Frederik and Samuel,

On Thu, Apr 06, 2023 at 06:20:04PM +0200, Samuel Thibault wrote:
> Oh, I didn't notice that there was a recorded test failure.
>
> I don't see how the failure can be related to the change...
>
> Cc-ing Frederik, in case he remembers / realizes something.

I just want to add some context. We are talking about this change:

https://codereview.qt-project.org/c/qt/qtbase/+/205196

Frederik, perhaps you can rebase and see if the tests still fail?

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1034027: ruby-rails-assets-fine-uploader: autopkgtest regression: Don't know how to build task 'assets:precompile'

[Paul Gevers]

Source: ruby-rails-assets-fine-uploader
Version: 5.13.0-2
Severity: serious
Control: tags -1 bookworm-ignore sid bookworm
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Your package has an autopkgtest, great. However, it fails since November 
2021. Can you please investigate the situation and fix it? I copied some 
of the output at the bottom of this report.


The release team has announced [1] that failing autopkgtest on amd64 and 
arm64 are considered RC in testing. [Release Team member hat on] Because 
we're currently in the hard freeze for bookworm, I have marked this bug 
as bookworm-ignore. Targeted fixes are still welcome.


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2019/07/msg2.html

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-rails-assets-fine-uploader/32420363/log.gz

Bundle complete! 3 Gemfile dependencies, 25 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
+ cat
+ cat
+ cat
+ cat
+ bundle exec rake assets:precompile
rake aborted!
Don't know how to build task 'assets:precompile' (See the list of 
available tasks with `rake --tasks`)


(See full trace by running task with --trace)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033921: debian-installer: Weekly build of d-i fails to find ipw2x00 firmware package

[Cyril Brulebois]

Pascal Hambourg  (2023-04-06):
> A difference between the two relevant sections in check-missing-firmware is
> that install_firmware_pkg() is executed in a pipeline when a
> Contents-firmware file is present, and not when it is not present. I do not
> know enough about debconf to figure out how the pipeline may interfere with
> it. Maybe something to do with standard input and output ?

Very useful information, thanks.

And yes, something related to pipes and possibly some missing passthrough
setting was my wild guess (as rubberducked on IRC), so that seems plausible.


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


signature.asc
Description: PGP signature

Bug#1034016: unblock (pre-approval): debos/1.1.1-2.1

[Andreas Henriksson]

Hello,

On Thu, Apr 06, 2023 at 05:52:32PM +0100, Christopher Obbard wrote:
> Hi Andreas,
> 
> On Thu, 2023-04-06 at 18:45 +0200, Andreas Henriksson wrote:
[...]
> > IMHO it feels much safer to just go with a targeted upload [...]
> 
> Let's go with your NMU, since you've done all of the work already, then I
> will upload the new version into unstable once development opens.
> 
> How does that sound?
> 
> PS: Can you push your source to salsa?

Pushed to salsa (incl. tag)!

dput new version, so should hopefully he accepted for unstable soon!

Thanks for the quick followup!

Regards,
Andreas Henriksson

Bug#1026204: tar FTBFS on armel, armhf, i386, hppa, powerpc and sparc64

[Paul Gevers]

Control: tags -1 pending patch

Hi all,

On Tue, 31 Jan 2023 18:27:27 +0100 Andreas Henriksson  
wrote:

> So, please use this hunk instead. It compiles for me on amd64 and 32-bit hppa.
> 
> export DEB_BUILD_MAINT_OPTIONS = future=+lfs
> export DEB_CFLAGS_MAINT_APPEND = -Wall -Wno-analyzer-null-argument

Might be useful to add a comment here saying:

# Workaround gnulib issue: The below three lines can be dropped once tar >= 
1.35 is used.
> ifneq ($(shell dpkg-architecture -qDEB_TARGET_ARCH_BITS),64)
> export DEB_CPPFLAGS_MAINT_APPEND = -D_TIME_BITS=64
> endif
> 
> DPKG_EXPORT_BUILDFLAGS = 1

> include /usr/share/dpkg/buildflags.mk
> ---


I have uploaded the attached debdiff to DELAYED/2 and pushed my changes 
to salsa. If nobody shouts that I understood the intentions correctly 
and/or cancels the upload, it should land in two days in unstable


Paul
diff -Nru tar-1.34+dfsg/debian/changelog tar-1.34+dfsg/debian/changelog
--- tar-1.34+dfsg/debian/changelog  2022-11-20 15:52:41.0 +0100
+++ tar-1.34+dfsg/debian/changelog  2023-04-06 16:25:47.0 +0200
@@ -1,3 +1,11 @@
+tar (1.34+dfsg-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build with lfs and -D_TIME_BITS=64 on 32 bits archs (Closes: #1026204)
+Thanks to Andreas Henriksson and Helge Deller
+
+ -- Paul Gevers   Thu, 06 Apr 2023 16:25:47 +0200
+
 tar (1.34+dfsg-1.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru tar-1.34+dfsg/debian/rules tar-1.34+dfsg/debian/rules
--- tar-1.34+dfsg/debian/rules  2022-11-19 16:38:39.0 +0100
+++ tar-1.34+dfsg/debian/rules  2023-04-06 16:25:47.0 +0200
@@ -1,15 +1,23 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
+
 DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
 CONFARGS = --host=$(DEB_HOST_GNU_TYPE)
 endif
 
-CFLAGS = `dpkg-buildflags --get CFLAGS`
-CFLAGS += -Wall -Wno-analyzer-null-argument
-LDFLAGS += `dpkg-buildflags --get LDFLAGS`
-CPPFLAGS = `dpkg-buildflags --get CPPFLAGS`
+export DEB_BUILD_MAINT_OPTIONS = future=+lfs
+export DEB_CFLAGS_MAINT_APPEND = -Wall -Wno-analyzer-null-argument
+# Workaround gnulib issue: The below three lines can be dropped once
+# tar >= 1.35 is used.
+ifeq (32,$(DEB_HOST_ARCH_BITS))
+export DEB_CPPFLAGS_MAINT_APPEND = -D_TIME_BITS=64
+endif
+
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
 
 export BUILD_DATE = $(shell dpkg-parsechangelog | sed -n -e 's/^Date: //p')
 


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034026: podman-docker: missing /usr/share/user-tmpfiles.d/podman-docker.conf

[Scott Edlund]

package: podman-docker

version: 4.3.1+ds1-6


podman-docker.conf was configured for use with rootless podman starting 
in 4.3.0rc1 .   Please install the tmpfiles configuration also in 
user-tmpfiles.


See 
https://github.com/containers/podman/commit/b47c54ab69d56f05bc586e443d04fe572de8ff8f

Bug#1020478: Ready to Implement

[Soren Stoutner]

The dependencies are finally in place so this can be implemented.

To make things simpler for dictionary packagers, we are using a virtual 
package and an unversioned path for the conversion tool so that dictionary 
packagers don’t have to make modifications to their packages when the versions 
of Qt change in Debian.

All you should need to do is the following:

1.  Build-depend on `convert-bdic`.
2.  Use /usr/bin/convert-bdic to do the dictionary conversion.
3.  Place the .bdic files in /usr/share/hunspell-bdic.

More detailed information can be found in the dictionary packager 
documentation at:

file:///usr/share/doc/dictionaries-common-dev/dsdt-policy.html#hunspell-bdic

Thanks,

Soren

-- 
Soren Stoutner
so...@stoutner.com

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

Bug#1034025: mirror submission for mirror.cse.iitk.ac.in

[IIT Kanpur]

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

Submission-Type: new
Site: mirror.cse.iitk.ac.in
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: IIT Kanpur 
Country: IN India
Location: India




Trace Url: http://mirror.cse.iitk.ac.in/debian/project/trace/
Trace Url: 
http://mirror.cse.iitk.ac.in/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.cse.iitk.ac.in/debian/project/trace/mirror.cse.iitk.ac.in

Bug#1034024: RM: tiledb -- ROM remove remaining experimental upload too

[Dirk Eddelbuettel]

Package: ftp.debian.org
Severity: normal

In #1033410 we suggested that package tiledb may not be a perfect fit for
Debian and suggested its removal.

Reverse dependencies have been taken care of, and the package is now removed
from testing and unstable.  However, a one-off upload to experimental
remains. It should be probably be removed too.

Thanks, Dirk

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1033802: dropbear-initramfs: sleep and cat not found

[William Desportes]

> Doesn't look like a dropbear-initramfs bug, possibly a missing module if
the device isn't exposed at initramfs stage.

I re-installed the machine, at this point I no longer have the sleep and cat 
missing bug.
Not sure If I want to try having it back, with cryptsetup it does not like 
rescue mode initramfs updates.

That said I have a new one (I did not install the basic system utilities):

It now says: init-premount/dropbear: line 366: ipconfig: not found

And right after the message about net-*.conf

The system does not have ipconfig installed, I would say this is a bug that 
should be fixed in the dropbear script.
Or added a as a package dependency/requirement ?

--
William Desportes

Bug#1034016: unblock (pre-approval): debos/1.1.1-2.1

[Christopher Obbard]

Hi Andreas,

On Thu, 2023-04-06 at 18:45 +0200, Andreas Henriksson wrote:
> Hello Chris,
> 
> On Thu, Apr 06, 2023 at 04:37:30PM +0100, Christopher Obbard wrote:
> > Hi Andreas,
> > 
> > As the upstream maintainer, I can just tag a new version upstream as 1.1.2 
> > & pick that in Debian.
> > Then I hope it can flow into bookworm?
> 
> I wonder if the release team will accept a new upstream release at this
> point in the freeze We're pretty deep into the hard freeze at this
> point (but I don't have enough insight into how the release team works
> these days, it seems much more relaxed than in the old times where I was
> more involved and basically any extra character would get you a NACK,
> specially an "unneccessary" upstream version number change).
> 
> Do you have time to do all the work and still accept a potential NO from
> the release team? Please be honest to yourself.
> 
> IMHO it feels much safer to just go with a targeted upload (which is now
> also already approved), but if you feel strongly about it and also think
> you have time to pursue a new release then just send me a NACK on the
> NMU (ASAP! I'm ready to upload *now*) and I will not pursue it.

Let's go with your NMU, since you've done all of the work already, then I
will upload the new version into unstable once development opens.

How does that sound?

PS: Can you push your source to salsa?


Thanks!
Chris

> 
> > 
> > The past few months have been... quite crazy in my personal life so I
> > haven't gotten around to doing this as yet. Huge apologies for that,
> > it is on my radar this week.
> > 
> > Hope that is acceptable to you?
> 
> No need to apologize. We're all busy sometimes and that's why we have
> NMUs so we can help each other out. (I've also been quite busy or the
> NMU would have happened much sooner in the release cycle.)
> Thanks for all the work you have had time to do!
> 
> > 
> > Thanks,
> > 
> > Chris
> 
> Regards,
> Andreas Henriksson
> 
> PS. Feel free to ignore my NMU and just upload the new upstream release
> once we're past the freeze/release and the development opens up again.

Bug#1034023: nmu: python-libzim_2.1.0+ds-1

[Bastian Germann]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal

Hello,

Due to a zimlib's version reset to 8.1.0+really8.0.0-1, python-libzim 
2.1.0+ds-1 (which needs 8.1.x) started FTBFS.
zimlib is at 8.1.1 now and python-libzim should build successfully again.

Please rebuild python-libzim against the new zimlib.

  nmu python-libzim_2.1.0+ds-1 . ANY . -m 'Rebuild against the new zimlib'

Bug#1034016: unblock (pre-approval): debos/1.1.1-2.1

[Andreas Henriksson]

Hello Chris,

On Thu, Apr 06, 2023 at 04:37:30PM +0100, Christopher Obbard wrote:
> Hi Andreas,
> 
> As the upstream maintainer, I can just tag a new version upstream as 1.1.2 & 
> pick that in Debian.
> Then I hope it can flow into bookworm?

I wonder if the release team will accept a new upstream release at this
point in the freeze We're pretty deep into the hard freeze at this
point (but I don't have enough insight into how the release team works
these days, it seems much more relaxed than in the old times where I was
more involved and basically any extra character would get you a NACK,
specially an "unneccessary" upstream version number change).

Do you have time to do all the work and still accept a potential NO from
the release team? Please be honest to yourself.

IMHO it feels much safer to just go with a targeted upload (which is now
also already approved), but if you feel strongly about it and also think
you have time to pursue a new release then just send me a NACK on the
NMU (ASAP! I'm ready to upload *now*) and I will not pursue it.

> 
> The past few months have been... quite crazy in my personal life so I
> haven't gotten around to doing this as yet. Huge apologies for that,
> it is on my radar this week.
> 
> Hope that is acceptable to you?

No need to apologize. We're all busy sometimes and that's why we have
NMUs so we can help each other out. (I've also been quite busy or the
NMU would have happened much sooner in the release cycle.)
Thanks for all the work you have had time to do!

> 
> Thanks,
> 
> Chris

Regards,
Andreas Henriksson

PS. Feel free to ignore my NMU and just upload the new upstream release
once we're past the freeze/release and the development opens up again.

Bug#1032650: ITP: nvme-stas -- NVMe STorage Appliance Services

[Benjamin Drung]

On Fri, 2023-03-10 at 17:12 +0100, Daniel Baumann wrote:
> On 3/10/23 16:33, Benjamin Drung wrote:
> > My preference is that I will do the initial packaging
> > and you become the maintainer and I only an uploader for it.
> 
> sounds like win-win, thanks :)
> 
> > Where should I put the packaging git repository? To
> > https://salsa.debian.org/debian/nvme-stas?
> 
> sounds good, can always be changed anytime later if needed.

Pushed the packaging to https://salsa.debian.org/debian/nvme-stas and
uploaded 2.2.1-1.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1019732: apt-listbugs: undefined method `default' for " # returns password\n":String

[Antonio Terceiro]

On Sun, Apr 02, 2023 at 05:44:37PM +0200, Francesco Poli wrote:
> On Sun, 2 Apr 2023 09:42:54 -0300 Antonio Terceiro wrote:
> 
> > On Sat, Apr 01, 2023 at 08:28:28PM +0200, Francesco Poli wrote:
> [...]
> > > Hi Antonio,
> > > is there a better alternative SOAP client library for Ruby in Debian?
> [...]
> > I have no idea, I never worked on anything that needed to support SOAP,
> > except the occasional patch for apt-listbugs itself. savon looks more
> > active, having a release last December. But maybe just updating soap4r
> > based on that fork (which seems abandoned in 2018) is good enough? I
> > don't know.
> 
> Antonio,
> do you think it makes sense, if I reassign the bug report to
> ruby-soap4r?
> 
> The circumstantial evidence collected during the investigation that you
> and Vincent have carried out seems to suggest that the issue is
> probably due to ruby-soap4r, although we do not have conclusive
> evidence...
> 
> Having the bug report reassigned to ruby-soap4r may serve as a reminder
> to try to update the Debian package to a more active (or a less-long
> abandoned!) fork of soap4r. Not now, of course, but after bookworm
> has been released.

I'm also not sure whether soap4r is definitively the origin of the bug.
I also don't think that moving the bug around is going to be of any
help.


signature.asc
Description: PGP signature

Bug#1034015: exim4: exim paniclog on lenovo has non-zero size

[Andreas Metzler]

On 2023-04-06 Wensheng Xie  wrote:
> Package: exim4
> Severity: important
> X-Debbugs-Cc: none, Wensheng Xie 

[...]
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  Sending/receiving emails to local users is ok;
>  LAN users receiving emails from server PC is ok, but cannot send
>  emails.
>* What was the outcome of this action?
>  exim paniclog /var/log/exim4/paniclog on lenovo has non-zero size, mail 
> system might be broken. Up to 10 lines are quoted below.

> 2023-03-17 23:26:36 daemon_notifier_socket bind: Address already in use
> 2023-03-17 23:31:06 socket bind() to port 25 for address 127.0.0.1 failed: 
> Address already in use: daemon abandoned
> 2023-03-17 23:31:34 socket bind() to port 25 for address 127.0.0.1 failed: 
> Address already in use: daemon abandoned
>* What outcome did you expect instead?
>  There is no error, and emails for LAN users via port 25 should work.

Looks like there is another program liestening on port 25.

cu Andreas

Bug#1033995: qtbase-opensource-src: Fix accessibility of qt5 applications run as root

[Samuel Thibault]

Dmitry Shachnev, le jeu. 06 avril 2023 19:10:28 +0300, a ecrit:
> I don't like that this change has not been merged upstream because of
> test failures,

Oh, I didn't notice that there was a recorded test failure.

I don't see how the failure can be related to the change...

Cc-ing Frederik, in case he remembers / realizes something.

> But I looked at the KDE branch, and the last three commits they have there [1]
> seem to be related to the same problem. At least, the comment talks about the
> the same thing as your description:
> 
> // Only connect on next loop run, connections to our enabled signal are
> // only established after the ctor returns.
> 
> But these changes depend on AT_SPI_BUS_ADDRESS environment variable. Can we
> rely on it in Debian?

No, that variable is not usually set. root-owned applications get the
bus address from the X11 root window property.

It's unfortunate that this fix didn't see Frederik's patch which should
be way more straightforward to fix things.

Samuel

> --
> Dmitry Shachnev

> diff --git a/src/platformsupport/linuxaccessibility/dbusconnection.cpp 
> b/src/platformsupport/linuxaccessibility/dbusconnection.cpp
> index 45ddc8e496..cc734abc63 100644
> --- a/src/platformsupport/linuxaccessibility/dbusconnection.cpp
> +++ b/src/platformsupport/linuxaccessibility/dbusconnection.cpp
> @@ -69,6 +69,21 @@ QT_BEGIN_NAMESPACE
>  DBusConnection::DBusConnection(QObject *parent)
>  : QObject(parent), m_a11yConnection(QString()), m_enabled(false)
>  {
> +// If the bus is explicitly set via env var it overrides everything else.
> +QByteArray addressEnv = qgetenv("AT_SPI_BUS_ADDRESS");
> +if (!addressEnv.isEmpty()) {
> +// Only connect on next loop run, connections to our enabled signal 
> are
> +// only established after the ctor returns.
> +QMetaObject::invokeMethod(
> +this,
> +[this, addressEnv] {
> +m_enabled = true;
> +connectA11yBus(QString::fromLocal8Bit(addressEnv));
> +},
> +Qt::QueuedConnection);
> +return;
> +}
> +
>  // Start monitoring if "org.a11y.Bus" is registered as DBus service.
>  QDBusConnection c = QDBusConnection::sessionBus();
>  if (!c.isConnected()) {

Bug#1034022: zfs filesystems are mounted before local filesystems

[Dietz Proepper]

Package: zfsutils-linux
Version: 2.1.9-1~bpo11+1
Severity: important
X-Debbugs-Cc: dietz.deb...@scanthis.de

Hi,
I have the following problem:
given:
- a system with mixed zfs/ext4 fses
- /var resides on an ext4 fs
- /var/lib/docker shall be zfs
then:
- first the zfs fses gets mounted (on the root fs)
- then, local fses get mounted, hiding the zfs fs mounted on /var/lib/docker
  from root fs.

The reason seems to be, that /lib/systemd/system/zfs-mount.service
contains a "Before=local-fs.target" dependency which can not be overridden.
My workaround here is quite simple, a separate unit for zfs mounts.

But would it perhaps make sense to chang the mount order? *FIRST* the
standard mounts ("local fs") and *THEN* the special ones?

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

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

Versions of packages zfsutils-linux depends on:
ii  init-system-helpers  1.64~bpo11+1
ii  libblkid12.36.1-8+deb11u1
ii  libc62.31-13+deb11u5
ii  libnvpair3linux  2.1.9-1~bpo11+1
ii  libuuid1 2.36.1-8+deb11u1
ii  libuutil3linux   2.1.9-1~bpo11+1
ii  libzfs4linux 2.1.9-1~bpo11+1
ii  libzpool5linux   2.1.9-1~bpo11+1
ii  python3  3.9.2-3

Versions of packages zfsutils-linux recommends:
ii  lsb-base11.1.0
ii  zfs-dkms [zfs-modules]  2.1.9-1~bpo11+1
ii  zfs-zed 2.1.9-1~bpo11+1

Versions of packages zfsutils-linux suggests:
pn  nfs-kernel-server  
ii  samba-common-bin   2:4.17.7+dfsg-1~bpo11+1
ii  zfs-initramfs  2.1.9-1~bpo11+1

-- Configuration Files:
/etc/sudoers.d/zfs [Errno 13] Keine Berechtigung: '/etc/sudoers.d/zfs'

-- no debconf information

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

Bug#1033995: qtbase-opensource-src: Fix accessibility of qt5 applications run as root

[Dmitry Shachnev]

Hi Samuel!

On Thu, Apr 06, 2023 at 01:57:25AM +0200, Samuel Thibault wrote:
> Hello,
>
> Currently, qt5 applications, when run in sudo, are not accessible to
> screen readers. This is because the accessibility layer does not manage
> to connect to the accessibility bus to export the application content:
>
> https://bugreports.qt.io/browse/QTBUG-43674
>
> [...]
>
> This is particularly important because the calamares installer is based
> on qt5 and runs as root, and it currently is completely inaccessible to
> blind users, and this fix makes it possible for blind users to use it.
>
> I have confirmed that this fixes the issue for bookworm, would it be
> possible to upload to unstable? I'll then handle requesting the unblock
> from the release team.

I understand the importance of this patch, but I don't like that this change
has not been merged upstream because of test failures, and did not have any
activity for the last 5 years.

But I looked at the KDE branch, and the last three commits they have there [1]
seem to be related to the same problem. At least, the comment talks about the
the same thing as your description:

// Only connect on next loop run, connections to our enabled signal are
// only established after the ctor returns.

But these changes depend on AT_SPI_BUS_ADDRESS environment variable. Can we
rely on it in Debian? If yes, can you please check if those commits fix the
issue with calamares? I have attached them as a single patch for convenience.

[1]: 
https://invent.kde.org/qt/qt/qtbase/-/commits/kde/5.15/src/platformsupport/linuxaccessibility/dbusconnection.cpp

--
Dmitry Shachnev
diff --git a/src/platformsupport/linuxaccessibility/dbusconnection.cpp b/src/platformsupport/linuxaccessibility/dbusconnection.cpp
index 45ddc8e496..cc734abc63 100644
--- a/src/platformsupport/linuxaccessibility/dbusconnection.cpp
+++ b/src/platformsupport/linuxaccessibility/dbusconnection.cpp
@@ -69,6 +69,21 @@ QT_BEGIN_NAMESPACE
 DBusConnection::DBusConnection(QObject *parent)
 : QObject(parent), m_a11yConnection(QString()), m_enabled(false)
 {
+// If the bus is explicitly set via env var it overrides everything else.
+QByteArray addressEnv = qgetenv("AT_SPI_BUS_ADDRESS");
+if (!addressEnv.isEmpty()) {
+// Only connect on next loop run, connections to our enabled signal are
+// only established after the ctor returns.
+QMetaObject::invokeMethod(
+this,
+[this, addressEnv] {
+m_enabled = true;
+connectA11yBus(QString::fromLocal8Bit(addressEnv));
+},
+Qt::QueuedConnection);
+return;
+}
+
 // Start monitoring if "org.a11y.Bus" is registered as DBus service.
 QDBusConnection c = QDBusConnection::sessionBus();
 if (!c.isConnected()) {


signature.asc
Description: PGP signature

Bug#1034021: RFS: gnss-sdr/0.0.18-1 -- Global navigation satellite systems software defined receiver

[Carles Fernandez]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gnss-sdr":

* Package name : gnss-sdr
   Version  : 0.0.18-1
   Upstream contact : Carles Fernandez 
* URL  : https://gnss-sdr.org
* License  : BSD-2-clause, Apple-Permissive, Apache-2.0, Zlib, LGPL-3+, 
Permissive, BSD-3-clause, Expat, BSD-3-Clause, GPL-3+
* Vcs  : https://salsa.debian.org/debian-hamradio-team/gnss-sdr
   Section  : hamradio

The source builds the following binary packages:

  gnss-sdr - Global navigation satellite systems software defined receiver

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

  https://mentors.debian.net/package/gnss-sdr/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnss-sdr/gnss-sdr_0.0.18-1.dsc

Changes since the last upload:

gnss-sdr (0.0.18-1) unstable; urgency=medium
.
   * First release of upstream version 0.0.18
   * Standards-Version updated to 4.6.2
   * Add Build-Conflicts: libopenblas-dev to debian/control (Closes: #1018917)
   * Add -DENABLE_ZMQ=ON to debian/rules
   * Updated debian/copyright file

Regards, 

Carles Fernandez

  










Dr. Carles Fernández-Prades 
Senior Researcher
Head of Navigation & Positioning

Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
Av. Carl Friedrich Gauss, 7 - Building B4
08860 - Castelldefels
Tel.: +34 93 645 29 00

DATA PROTECTION INFORMATION. Data controller: CENTRE TECNOLOGIC DE 
TELECOMUNICACIONS DE CATALUNYA (G62616586):

We inform you that your identification data and the data contained in the 
emails and attached files can be incorporated into our databases, in order to 
maintain professional and / or commercial relationships, and that it will be 
preserved throughout the relationship. According to the current regulations, 
you can exercise your right to access, rectification, erasure, restriction of 
processing, to portability and to object by sending an email to d...@cttc.cat. 
This message and any attached document, where appropriate, may be confidential 
and intended for the original recipient only.

L'informem que les seves dades identificatives i les compreses als correus 
electrònics i fitxers adjunts poden ser incorporades a les nostres bases de 
dades amb la finalitat de mantenir relacions professionals i/o comercials i, 
que seran conservades mentre es mantingui aquesta relació. Si ho desitja, pot 
exercir el seu dret d'accés, rectificació, supressió, limitació del tractament, 
portabilitat i objecció enviant un correu electrònic a d...@cttc.cat. 
Aquest missatge i qualsevol document adjunt, en el seu cas, pot ser 
confidencial i destinat únicament a la persona o entitat a qui s'hagi enviat. 

Before printing this e-mail or attachments, be sure it is necessary. It is in 
our hands to protect the environment.

Bug#1034005: ibus-kkc FTCBFS: configures for the build architecture

[Gunnar Hjalmarsson]

Control: tags -1 + pending

Thanks Helmut! Pushed your change to the repo.

--
Rgds,
Gunnar

Bug#1034016: unblock (pre-approval): debos/1.1.1-2.1

[Christopher Obbard]

Hi Andreas,

As the upstream maintainer, I can just tag a new version upstream as 1.1.2 & 
pick that in Debian.
Then I hope it can flow into bookworm?

The past few months have been... quite crazy in my personal life so I haven't 
gotten around to doing this as yet. Huge apologies for that, it is on my radar 
this week.

Hope that is acceptable to you?

Thanks,

Chris


On Thu, 2023-04-06 at 15:51 +0200, Andreas Henriksson wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: de...@packages.debian.org
> Control: affects -1 + src:debos
> 
> 
> Hello release-team,
> 
> I'm looking for a pre-approval for an unblock of my NMU of debos,
> which contains 3 commits cherry-picked from upstream.
> 
> The main bug to fix is https://bugs.debian.org/1027787
> The current version of debos in bookworm is not compatible with
> bookworm. The maintainer promised me to deal with this if I
> submitted an upstream PR where he merged my patch for it,
> but apparently never found the time to update the debian
> package.
> 
> While at it I also cherry-picked 2 documentation fixes.
> 
> I'm attaching a debdiff, but if you'd like to avoid reading
> patch-in-patch these are the commits:
> https://github.com/go-debos/debos/commit/18998ffaf78321e111d9823b3180eca3fa4593f6
> https://github.com/go-debos/debos/commit/f4ff78305513a90eca089e33f7bba35bffa96bd1
> https://github.com/go-debos/debos/commit/c8c5075853aab9e1ac6ae07a3a7c2b070aa38a62
> 
> 
> unblock debos/1.1.1-2.1

Bug#1032948: linux-image-6.1.0-5-amd64: oops in ucsi_acpi_notify

[Salvatore Bonaccorso]

Hi Julien,

On Thu, Apr 06, 2023 at 02:10:31PM +0200, Julien Cristau wrote:
> Control: tag -1 upstream fixed-upstream patch
> 
> On Tue, Apr  4, 2023 at 22:03:28 +0200, Diederik de Haas wrote:
> 
> > On Tuesday, 4 April 2023 13:11:16 CEST Julien Cristau wrote:
> > > On Mon, Apr  3, 2023 at 15:16:42 +0200, Diederik de Haas wrote:
> > > > On Saturday, 18 March 2023 23:10:39 CEST Diederik de Haas wrote:
> > > > 
> > > > On Monday, 3 April 2023 14:57:02 CEST Julien Cristau wrote:
> > > > > > Not sure why patchwork still shows v2 of the patch as v4 is 
> > > > > > available
> > > > > > here:
> > > > > > https://lore.kernel.org/all/20230308154244.722337-1-hdego...@redhat.com/
> > > > > 
> > > > > I'll give the patch series you linked in the other reply a go now.
> > > > 
> > > > FTR: 2 out of the 3 patches have landed in 6.1.22
> > > 
> > > Thanks for letting me know.  I've built 6.1.22 from upstream and it
> > > doesn't seem to crash.
> > 
> > That's awesome :-) Let's hope it stays that way now ;-)
> > 
> > You may have seen it on IRC already, but could you test a
> > Debian 6.1.20-1 kernel with (only) those patches applied?
> > These are the URLs:
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y=1c5abcb13491da8c049f20462189c12c753ba978
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y=1e8525f37871741a52370627633962f8bdcab15a
> > 
> > If you need help with that, feel free to ask :-)
> > 
> > If we know that fixes the issue too, then we have the option of going for
> > a 6.1.20-2 release with just those 2 patches (and what's already in -2 now).
> > 
> Testing this now:
> 
> linux (6.1.20-1a~test) UNRELEASED; urgency=medium
> 
>   * Testing patches ../0001-usb-ucsi-Fix-NULL-pointer-deref-in-
> ucsi_connector_ch.patch ../0001-usb-ucsi_acpi-Increase-the-command-
> completion-timeou.patch
> 
>  -- Julien Cristau   Wed, 05 Apr 2023 11:09:30 +
> 
> and it doesn't seem to crash, as far as I can tell.

Great, thanks! Then I'm going to pick those two commits as well for
6.1.20-2 and do that before continuing on 6.1.23.

Regards,
Salvatore

Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Paul Gevers]

Hi Markus,

Thanks for following-up. It further clarified pieces.

On 06-04-2023 15:14, Markus Koschany wrote:

I always rebuild all reverse-dependencies with ratt before I upload a Java
library package. From my Java experience I know this uncovers almost all
problems. Rhino is not some obscure C/C++ library. It is a Javascript engine
written in Java. You can install reverse-dependencies and run them against the
new rhino version. If the package works, then there is no further action
required. Could I have missed a corner case? Maybe.


If you believe it to be a corner case (that you elaborate on later on), 
then I trust you on that. The corner case just looked like a transition 
from our side (Release Team) of the story.



 From dojo developer documentation:

"Note that the linkage requires the same version of Rhino used to build the
shrinksafe.jar. In versions prior to Dojo 1.3, ShrinkSafe was bundled into
Rhino by way of patch, and shipped as custom_rhino.jar."


Thanks for that piece of info.


We can do a binNMU for all reverse-dependencies but I do not think it is
necessary.


Good to know, I wasn't particularly liking the idea.


Also, given that shrinksafe is from a different source than rhino, this
qualifies as a transition (it *needs* changes in different (binary)
packages).


I cannot remember when we asked for a Java library transition in the past.
shrinksafe is, as I pointed out before, a special case. It was once part of the
rhino distribution and probably should have tightened the dependency on a
specific rhino version in the first place.


Ok, let's have the dojo maintainers tighten the relation then in their 
next upload.



2. shrinksafe has no reverse-dependencies


So it can be easily removed, but that's not a great service to its users.


No, we don't want to remove neither shrinksafe nor any other package. Please
don't exaggerate the problem at hand.


Well, autoremoval was about to do that in a few days if nobody intervened.


The solution is to tighten the dependency on rhino and adjust the autopkgtest
accordingly.


If the dependency is tightened, autopkgtest will do the right thing.


6. Regarding Openrefine: It does only work with rhino 1.7.14 in unstable.
Hence
why I tightened the dependency on rhino to 1.7.14. The current version of
rhino
in testing breaks the Javascript application.


Suggesting even more that this is a real transition.


You are misunderstanding the problem. OpenRefine does not work with Rhino in
testing. The new rhino in unstable fixes the problem. Again, rhino 1.7.14 is
the solution, not the cause of the problem.
[...]


Yes, I typed this before I had further insights and forgot to review 
this piece. Indeed, you're right.



I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5
today, where I'll add an appropriate Breaks to src:rhino and an
appropriate versioned Depends to src:dojo. Please let me know if you
object or want to handle this yourself.


Fine with me and thanks!


I'll also reschedule rhino then.

Thanks for your help and contributions for bookworm.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028104: libboost-dev: Boost with C++20 uses unavailable std functions

[Anton Gladky]

Hi Paul,

Yes i will do it.


Paul Gevers  schrieb am Do., 6. Apr. 2023, 14:36:

> Hi,
>
> On Tue, 21 Mar 2023 21:58:11 +0100 Paul Gevers  wrote:
> > On Sun, 08 Jan 2023 00:26:39 +0100 Andreas Beckmann 
> wrote:
> > > This happens with g++-12 but not with g++-11.
> > > It is fixed in the boost version in experimental.
> >
> > Any chance for a *targeted* fix in bookworm?
>
> Ping. (No is also an answer).
>
> Paul
>

Bug#977027: [Pkg-javascript-devel] Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Paul Gevers]

Hi,

On 06-04-2023 14:50, Bastien ROUCARIES wrote:

On 06-04-2023 12:54, Paul Gevers wrote:

I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5


Please find the debdiffs attached.


Go ahead


Thanks, I have rescheduled dojo to 0 days and it got accepted.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034020: openal-soft: please upgrade to 1.23

[Fabian Greffrath]

Source: openal-soft
Version: 1:1.19.1-2
Severity: wishlist

Hi there,

please upgrade the openal-soft package to upstream version 1.23!

The 1.19.1 release which is currently in Debian exhibits some serious
clicking when sounds are played repeatedly in Doom source ports and
reportedly these clinks are fixed in newer versions (at least 1.21.1):

https://github.com/fabiangreffrath/woof/pull/973#issuecomment-1499154366

Also, you may want to upgrade the Homepage field in debian/control and
the debian/watch file to point to the new upstream location at
https://github.com/kcat/openal-soft

Thanks!

Cheers,

 - Fabian


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

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

Bug#1034016: unblock (pre-approval): debos/1.1.1-2.1

[Sebastian Ramacher]

On 2023-04-06 15:51:38 +0200, Andreas Henriksson wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: de...@packages.debian.org
> Control: affects -1 + src:debos
> 
> 
> Hello release-team,
> 
> I'm looking for a pre-approval for an unblock of my NMU of debos,
> which contains 3 commits cherry-picked from upstream.

Please go ahead

Cheers

> 
> The main bug to fix is https://bugs.debian.org/1027787
> The current version of debos in bookworm is not compatible with
> bookworm. The maintainer promised me to deal with this if I
> submitted an upstream PR where he merged my patch for it,
> but apparently never found the time to update the debian
> package.
> 
> While at it I also cherry-picked 2 documentation fixes.
> 
> I'm attaching a debdiff, but if you'd like to avoid reading
> patch-in-patch these are the commits:
> https://github.com/go-debos/debos/commit/18998ffaf78321e111d9823b3180eca3fa4593f6
> https://github.com/go-debos/debos/commit/f4ff78305513a90eca089e33f7bba35bffa96bd1
> https://github.com/go-debos/debos/commit/c8c5075853aab9e1ac6ae07a3a7c2b070aa38a62
> 
> 
> unblock debos/1.1.1-2.1

> diff -Nru debos-1.1.1/debian/changelog debos-1.1.1/debian/changelog
> --- debos-1.1.1/debian/changelog  2022-10-31 11:16:08.0 +0100
> +++ debos-1.1.1/debian/changelog  2023-03-16 10:09:37.0 +0100
> @@ -1,3 +1,13 @@
> +debos (1.1.1-2.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Cherry-pick upstream commit that unbreaks bookworm (Closes: #1027787)
> +  * Cherry-pick upstream doc fix for non-free-firmware
> +  * Cherry-pick upstream example fix for interactive password prompt
> +(Closes: #1006823)
> +
> + -- Andreas Henriksson   Thu, 16 Mar 2023 10:09:37 +0100
> +
>  debos (1.1.1-2) unstable; urgency=medium
>  
>* Run autopkgtest in an isolated virtual machine
> diff -Nru debos-1.1.1/debian/patches/0001-Limit-old-suite-workaround.patch 
> debos-1.1.1/debian/patches/0001-Limit-old-suite-workaround.patch
> --- debos-1.1.1/debian/patches/0001-Limit-old-suite-workaround.patch  
> 1970-01-01 01:00:00.0 +0100
> +++ debos-1.1.1/debian/patches/0001-Limit-old-suite-workaround.patch  
> 2023-03-16 10:09:37.0 +0100
> @@ -0,0 +1,65 @@
> +From: Andreas Henriksson 
> +Date: Tue, 3 Jan 2023 01:12:42 +0100
> +Subject: Limit old suite workaround
> +
> +The workaround for https://github.com/go-debos/debos/issues/361
> +that was applied in 
> https://github.com/go-debos/debos/commit/b3c1f76bcc1dbd55fef584b8ddbda33f12733116
> +breaks recipes for bookworm and newer.
> +
> +Signed-off-by: Andreas Henriksson 
> +(cherry picked from commit 18998ffaf78321e111d9823b3180eca3fa4593f6)
> +---
> + actions/debootstrap_action.go | 26 +-
> + 1 file changed, 25 insertions(+), 1 deletion(-)
> +
> +diff --git a/actions/debootstrap_action.go b/actions/debootstrap_action.go
> +index e354ff4..e7c2587 100644
> +--- a/actions/debootstrap_action.go
>  b/actions/debootstrap_action.go
> +@@ -53,6 +53,7 @@ package actions
> + import (
> + "fmt"
> + "io"
> ++"log"
> + "os"
> + "path"
> + "strings"
> +@@ -158,6 +159,24 @@ func (d *DebootstrapAction) RunSecondStage(context 
> debos.DebosContext) error {
> + return err
> + }
> + 
> ++// Guess if suite is something before usr-is-merged was introduced
> ++func (d *DebootstrapAction) isLikelyOldSuite() bool {
> ++switch strings.ToLower(d.Suite) {
> ++case "sid", "unstable":
> ++return false
> ++case "testing":
> ++return false
> ++case "bookworm":
> ++return false
> ++case "trixie":
> ++return false
> ++case "forky":
> ++return false
> ++default:
> ++return true
> ++}
> ++}
> ++
> + func (d *DebootstrapAction) Run(context *debos.DebosContext) error {
> + d.LogStart()
> + cmdline := []string{"debootstrap"}
> +@@ -204,7 +223,12 @@ func (d *DebootstrapAction) Run(context 
> *debos.DebosContext) error {
> + cmdline = append(cmdline, fmt.Sprintf("--variant=%s", 
> d.Variant))
> + }
> + 
> +-cmdline = append(cmdline, "--exclude=usr-is-merged")
> ++// workaround for https://github.com/go-debos/debos/issues/361
> ++if d.isLikelyOldSuite() {
> ++log.Println("excluding usr-is-merged as package is not in 
> suite")
> ++cmdline = append(cmdline, "--exclude=usr-is-merged")
> ++}
> ++
> + cmdline = append(cmdline, d.Suite)
> + cmdline = append(cmdline, context.Rootdir)
> + cmdline = append(cmdline, d.Mirror)
> diff -Nru 
> debos-1.1.1/debian/patches/0002-Include-non-free-firmware-component-in-Simple-exampl.patch
>  
> debos-1.1.1/debian/patches/0002-Include-non-free-firmware-component-in-Simple-exampl.patch
> --- 
> debos-1.1.1/debian/patches/0002-Include-non-free-firmware-component-in-Simple-exampl.patch
> 1970-01-01 01:00:00.0 

Bug#1034018: shotwell: New upstream bugfix release

[Jeremy Bícha]

Patches attached.

Thank you,
Jeremy Bícha
From b50f7e6507cf2e09c3eda1b43d781c5613509bc1 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Thu, 6 Apr 2023 08:33:27 -0400
Subject: [PATCH 1/2] debian/control: Build-Depend on libportal-gtk3-dev

Closes: #1034018
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 4e57bbe2..4ea4ac2e 100644
--- a/debian/control
+++ b/debian/control
@@ -24,6 +24,7 @@ Build-Depends:
  libgudev-1.0-dev (>= 145),
  libicu-dev,
  libjson-glib-dev,
+ libportal-gtk3-dev,
  libraw-dev (>= 0.14),
  librest-dev (>= 0.7),
  libsoup2.4-dev (>= 2.26.0),
-- 
2.39.2

From c46dd1bbbee921fec8484b071742a452f9c677dd Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Thu, 6 Apr 2023 09:15:16 -0400
Subject: [PATCH 2/2] Depend on xdg-desktop-portal-gnome |
 xdg-desktop-portal-backend

for "Set as Desktop Background"

Gbp-Dch: Full
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 4ea4ac2e..322515f3 100644
--- a/debian/control
+++ b/debian/control
@@ -51,6 +51,7 @@ Depends:
  dconf-cli,
  default-dbus-session-bus | dbus-session-bus,
  librsvg2-common,
+ xdg-desktop-portal-gnome | xdg-desktop-portal-backend,
  webp-pixbuf-loader
 Replaces: shotwell-common (<< 0.26.2-1)
 Description: digital photo organizer
-- 
2.39.2

Bug#1034017: shotwell: Add additional patches for webp support

[Jeremy Bícha]

Patches attached.

Thank you,
Jeremy Bícha
From f7fd3f136792eb4eb0f22f91ad72c6a156ffc4f9 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Thu, 6 Apr 2023 08:32:43 -0400
Subject: [PATCH 1/3] debian/control: Build-Depend on libwebp-dev

---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 500616b4..2340c6f3 100644
--- a/debian/control
+++ b/debian/control
@@ -31,6 +31,7 @@ Build-Depends:
  libsqlite3-dev (>= 3.5.9),
  libunity-dev,
  libwebkit2gtk-4.0-dev,
+ libwebp-dev,
  libxml2 (>= 2.6.32),
  meson,
  ninja-build,
-- 
2.39.2

From 1ec0ee79d5b105a54fb7be6305052d53d2a4bb16 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Thu, 6 Apr 2023 08:31:48 -0400
Subject: [PATCH 3/3] Cherry-pick 2 more patches required for webp support to
 work

LP: #1993881
Closes: #1034017
---
 debian/patches/0101-webp.patch | 425 +
 debian/patches/0102-webp.patch |  22 ++
 debian/patches/series  |   2 +
 3 files changed, 449 insertions(+)
 create mode 100644 debian/patches/0101-webp.patch
 create mode 100644 debian/patches/0102-webp.patch

diff --git a/debian/patches/0101-webp.patch b/debian/patches/0101-webp.patch
new file mode 100644
index ..175c08d0
--- /dev/null
+++ b/debian/patches/0101-webp.patch
@@ -0,0 +1,425 @@
+From: Jens Georg 
+Date: Wed, 30 Aug 2017 21:46:55 +0200
+Subject: Support reading WEBP
+
+https://bugzilla.gnome.org/show_bug.cgi?id=717880
+
+Requires a gexiv2 linked against exiv2 0.26 which currently works in the
+flatpak and on F28, but NOT on Debian/Ubuntu 18.04
+
+(cherry picked from commit f032a58dca391b1833c6ea70785bb3b63abc68c7)
+---
+ meson.build |   3 +
+ src/meson.build |   3 +-
+ src/photos/PhotoFileFormat.vala |  18 ++-
+ src/photos/WebPSupport.vala | 240 
+ vapi/libwebp.vapi   |   5 +
+ vapi/libwebpdemux.vapi  |  43 +++
+ 6 files changed, 309 insertions(+), 3 deletions(-)
+ create mode 100644 src/photos/WebPSupport.vala
+ create mode 100644 vapi/libwebp.vapi
+ create mode 100644 vapi/libwebpdemux.vapi
+
+diff --git a/meson.build b/meson.build
+index 5d08d30..2316377 100644
+--- a/meson.build
 b/meson.build
+@@ -66,6 +66,9 @@ libexif = dependency('libexif', version : '>= 0.6.16')
+ unity = dependency('unity', required : false)
+ portal = [ dependency('libportal', version: '>= 0.5'), dependency('libportal-gtk3', version: '>= 0.5')]
+ 
++webpdemux = dependency('libwebpdemux')
++webp = dependency('libwebp')
++
+ unity_available = false
+ if unity.found() and get_option('unity-support')
+   unity_available = true
+diff --git a/src/meson.build b/src/meson.build
+index a532eec..8cab77d 100644
+--- a/src/meson.build
 b/src/meson.build
+@@ -29,7 +29,7 @@ face_sources = (['faces/FacesBranch.vala',
+ 
+ shotwell_deps = [gio, gee, sqlite, gtk, sqlite, posix, gphoto2,
+  gstreamer_pbu, gio_unix, gudev, gexiv2, gmodule,
+- libraw, libexif, sw_plugin, portal, version]
++ libraw, libexif, sw_plugin, portal, version, webpdemux, webp]
+ if unity_available
+ shotwell_deps += [unity]
+ endif
+@@ -73,6 +73,7 @@ executable('shotwell',
+ 'photos/RawSupport.vala',
+ 'photos/PngSupport.vala',
+ 'photos/TiffSupport.vala',
++'photos/WebPSupport.vala',
+ 'plugins/Plugins.vala',
+ 'plugins/StandardHostInterface.vala',
+ 'plugins/ManifestWidget.vala',
+diff --git a/src/photos/PhotoFileFormat.vala b/src/photos/PhotoFileFormat.vala
+index e642008..94ca752 100644
+--- a/src/photos/PhotoFileFormat.vala
 b/src/photos/PhotoFileFormat.vala
+@@ -58,12 +58,13 @@ public enum PhotoFileFormat {
+ TIFF,
+ BMP,
+ GIF,
++WEBP,
+ UNKNOWN;
+ 
+ // This is currently listed in the order of detection, that is, the file is examined from
+ // left to right.  (See PhotoFileInterrogator.)
+ public static PhotoFileFormat[] get_supported() {
+-return { JFIF, RAW, PNG, TIFF, BMP, GIF };
++return { JFIF, RAW, PNG, TIFF, BMP, GIF, WEBP };
+ }
+ 
+ public static PhotoFileFormat[] get_writeable() {
+@@ -141,7 +142,10 @@ public enum PhotoFileFormat {
+ 
+ case GIF:
+ return 5;
+-
++
++case WEBP:
++return 6;
++
+ case UNKNOWN:
+ default:
+ return -1;
+@@ -169,6 +173,9 @@ public enum PhotoFileFormat {
+ case 5:
+ return GIF;
+ 
++case 6:
++return WEBP;
++
+ default:
+ return UNKNOWN;
+ }
+@@ -249,6 +256,10 @@ public enum PhotoFileFormat {
+ Photos.GifFileFormatDriver.init();
+ break;
+ 
++case WEBP:
++Photos.WebpFileFormatDriver.init();
++break;

Bug#1034019: pipewire: Tascam Portacapture x8 Not Working as USB Mic in Interface Mode

[Zachary E. Braun]

Package: pipewire
Version: 0.3.65-3
Severity: normal
X-Debbugs-Cc: report...@enekk.xyz

Dear Maintainer,

   First, appologies if this is the wrong package to report this to.
   I have a Tascam Portacapture X8 which is able to work as an audio interface. 
 In theory, the built-in microphones should pass to the operating system while 
the device itself should be able to monitor system audio.  The latter, system 
aduio, works fine; however, I cannot get the microphones to pass back to 
Debian.  

   I was able to test this device on OSX; microphone input worked as expected. 

   I have included the verbose output from lsusb for the device at the end of 
the standard "System Information" section.

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

Kernel: Linux 6.1.0-7-amd64 (SMP w/4 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 pipewire depends on:
ii  adduser  3.132
ii  init-system-helpers  1.65.2
ii  libpipewire-0.3-modules  0.3.65-3
ii  pipewire-bin 0.3.65-3

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

-- lsusb -d 0644:8074 -v 

Bus 003 Device 013: ID 0644:8074 TEAC Corp. Portacapture X8
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  239 Miscellaneous Device
  bDeviceSubClass 2 
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize064
  idVendor   0x0644 TEAC Corp.
  idProduct  0x8074 
  bcdDevice2.00
  iManufacturer   1 TASCAM
  iProduct2 Portacapture X8
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x0182
bNumInterfaces  4
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xc0
  Self Powered
MaxPower0mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass 8 Mass Storage
  bInterfaceSubClass  6 SCSI
  bInterfaceProtocol 80 Bulk-Only
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
Interface Association:
  bLength 8
  bDescriptorType11
  bFirstInterface 1
  bInterfaceCount 3
  bFunctionClass  1 Audio
  bFunctionSubClass   0 
  bFunctionProtocol  32 
  iFunction   0 
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   0
  bInterfaceClass 1 Audio
  bInterfaceSubClass  1 Control Device
  bInterfaceProtocol 32 
  iInterface  0 
  AudioControl Interface Descriptor:
bLength 9
bDescriptorType36
bDescriptorSubtype  1 (HEADER)
bcdADC   2.00
bCategory   8
wTotalLength   0x004b
bmControls   0x00
  AudioControl Interface Descriptor:
bLength 8
bDescriptorType36
bDescriptorSubtype 10 (CLOCK_SOURCE)
bClockID7
bmAttributes3 Internal programmable clock 
bmControls   0x03
  Clock Frequency Control (read/write)
bAssocTerminal  0
iClockSource0 
  AudioControl Interface Descriptor:
bLength12
bDescriptorType36
bDescriptorSubtype  3 (OUTPUT_TERMINAL)
bTerminalID 2
  

Bug#1034018: shotwell: New upstream bugfix release

[Jeremy Bícha]

Source: shotwell
Version: 0.30.17-1
Severity: wishlist

There is a new shotwell 0.30.18 release.

https://gitlab.gnome.org/GNOME/shotwell/-/compare/shotwell-0.30.17...shotwell-0.30.18

In my follow-up email, I'm attaching 2 patches that may help you
package the new version.

Thank you,
Jeremy Bícha

Bug#1034017: shotwell: Add additional patches for webp support

[Jeremy Bícha]

Source: shotwell
Version: 0.30.17-1
Tags: patch.

Shotwell claims to support webp images, but it is missing the patches
for this feature to work. This issue was originally reported at
https://launchpad.net/bugs/1993881

In my followup email, I'll attach the git patches I used to fix this
issue in Ubuntu.

Thank you,
Jeremy Bícha

Bug#1034016: unblock (pre-approval): debos/1.1.1-2.1

[Andreas Henriksson]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: de...@packages.debian.org
Control: affects -1 + src:debos


Hello release-team,

I'm looking for a pre-approval for an unblock of my NMU of debos,
which contains 3 commits cherry-picked from upstream.

The main bug to fix is https://bugs.debian.org/1027787
The current version of debos in bookworm is not compatible with
bookworm. The maintainer promised me to deal with this if I
submitted an upstream PR where he merged my patch for it,
but apparently never found the time to update the debian
package.

While at it I also cherry-picked 2 documentation fixes.

I'm attaching a debdiff, but if you'd like to avoid reading
patch-in-patch these are the commits:
https://github.com/go-debos/debos/commit/18998ffaf78321e111d9823b3180eca3fa4593f6
https://github.com/go-debos/debos/commit/f4ff78305513a90eca089e33f7bba35bffa96bd1
https://github.com/go-debos/debos/commit/c8c5075853aab9e1ac6ae07a3a7c2b070aa38a62


unblock debos/1.1.1-2.1
diff -Nru debos-1.1.1/debian/changelog debos-1.1.1/debian/changelog
--- debos-1.1.1/debian/changelog2022-10-31 11:16:08.0 +0100
+++ debos-1.1.1/debian/changelog2023-03-16 10:09:37.0 +0100
@@ -1,3 +1,13 @@
+debos (1.1.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-pick upstream commit that unbreaks bookworm (Closes: #1027787)
+  * Cherry-pick upstream doc fix for non-free-firmware
+  * Cherry-pick upstream example fix for interactive password prompt
+(Closes: #1006823)
+
+ -- Andreas Henriksson   Thu, 16 Mar 2023 10:09:37 +0100
+
 debos (1.1.1-2) unstable; urgency=medium
 
   * Run autopkgtest in an isolated virtual machine
diff -Nru debos-1.1.1/debian/patches/0001-Limit-old-suite-workaround.patch 
debos-1.1.1/debian/patches/0001-Limit-old-suite-workaround.patch
--- debos-1.1.1/debian/patches/0001-Limit-old-suite-workaround.patch
1970-01-01 01:00:00.0 +0100
+++ debos-1.1.1/debian/patches/0001-Limit-old-suite-workaround.patch
2023-03-16 10:09:37.0 +0100
@@ -0,0 +1,65 @@
+From: Andreas Henriksson 
+Date: Tue, 3 Jan 2023 01:12:42 +0100
+Subject: Limit old suite workaround
+
+The workaround for https://github.com/go-debos/debos/issues/361
+that was applied in 
https://github.com/go-debos/debos/commit/b3c1f76bcc1dbd55fef584b8ddbda33f12733116
+breaks recipes for bookworm and newer.
+
+Signed-off-by: Andreas Henriksson 
+(cherry picked from commit 18998ffaf78321e111d9823b3180eca3fa4593f6)
+---
+ actions/debootstrap_action.go | 26 +-
+ 1 file changed, 25 insertions(+), 1 deletion(-)
+
+diff --git a/actions/debootstrap_action.go b/actions/debootstrap_action.go
+index e354ff4..e7c2587 100644
+--- a/actions/debootstrap_action.go
 b/actions/debootstrap_action.go
+@@ -53,6 +53,7 @@ package actions
+ import (
+   "fmt"
+   "io"
++  "log"
+   "os"
+   "path"
+   "strings"
+@@ -158,6 +159,24 @@ func (d *DebootstrapAction) RunSecondStage(context 
debos.DebosContext) error {
+   return err
+ }
+ 
++// Guess if suite is something before usr-is-merged was introduced
++func (d *DebootstrapAction) isLikelyOldSuite() bool {
++  switch strings.ToLower(d.Suite) {
++  case "sid", "unstable":
++  return false
++  case "testing":
++  return false
++  case "bookworm":
++  return false
++  case "trixie":
++  return false
++  case "forky":
++  return false
++  default:
++  return true
++  }
++}
++
+ func (d *DebootstrapAction) Run(context *debos.DebosContext) error {
+   d.LogStart()
+   cmdline := []string{"debootstrap"}
+@@ -204,7 +223,12 @@ func (d *DebootstrapAction) Run(context 
*debos.DebosContext) error {
+   cmdline = append(cmdline, fmt.Sprintf("--variant=%s", 
d.Variant))
+   }
+ 
+-  cmdline = append(cmdline, "--exclude=usr-is-merged")
++  // workaround for https://github.com/go-debos/debos/issues/361
++  if d.isLikelyOldSuite() {
++  log.Println("excluding usr-is-merged as package is not in 
suite")
++  cmdline = append(cmdline, "--exclude=usr-is-merged")
++  }
++
+   cmdline = append(cmdline, d.Suite)
+   cmdline = append(cmdline, context.Rootdir)
+   cmdline = append(cmdline, d.Mirror)
diff -Nru 
debos-1.1.1/debian/patches/0002-Include-non-free-firmware-component-in-Simple-exampl.patch
 
debos-1.1.1/debian/patches/0002-Include-non-free-firmware-component-in-Simple-exampl.patch
--- 
debos-1.1.1/debian/patches/0002-Include-non-free-firmware-component-in-Simple-exampl.patch
  1970-01-01 01:00:00.0 +0100
+++ 
debos-1.1.1/debian/patches/0002-Include-non-free-firmware-component-in-Simple-exampl.patch
  2023-03-16 10:09:37.0 +0100
@@ -0,0 +1,23 @@
+From: Daniel Andersson 
+Date: Fri, 24 Feb 2023 18:20:43 +0100
+Subject: Include non-free-firmware component in 

Bug#1033637: linux-image-amd64: amdgpu - External displays connected through Thinkpad Ultra Dock not turn on after suspend

[Stefan K]

Hello,

short update:
I've tried Kernel 6.2 and Kernel 6.3.0-rc4, only Kernel 6.3 works fine. Kernel 
6.2 had the same issue..
Kernel from here: https://iam.tj/projects/debian/

best regards
Stefan

Bug#1034012: libzstd: Possible data corruption in zstd 1.5.x

[Peter Pentchev]

control: notfound -1 1.5.4+dfsg2-4

On Thu, Apr 06, 2023 at 03:02:20PM +0300, Andrey Semashev wrote:
> Package: libzstd1
> Version: 1.5.4+dfsg2-3
> Source: libzstd
> 
> It was discovered that zstd versions from 1.5.0 to 1.5.4, inclusively,
> may exhibit data corruption on high compression levels (>= 13). This is
> fixed in zstd 1.5.5 and outlined in the release notes and the related
> pull request:
> 
> https://github.com/facebook/zstd/releases/tag/v1.5.5
> https://github.com/facebook/zstd/pull/3517
> 
> Please consider upgrading to zstd 1.5.5 or backporting the patch with
> the fix.
 
Hi,

Thanks for filing this bug report.

The patch is already included in libzstd 1.5.4+dfsg2-5 in unstable;
I guess I will have to ask the release managers for a freeze exception so
that this version migrates to testing.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#1034015: exim4: exim paniclog on lenovo has non-zero size

[Wensheng Xie]

Package: exim4
Severity: important
X-Debbugs-Cc: none, Wensheng Xie 

Dear Maintainer,

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

   * What led up to the situation?
 Installed exim4 and setup localhost as mailserver
 
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Sending/receiving emails to local users is ok;
 LAN users receiving emails from server PC is ok, but cannot send
 emails.
   * What was the outcome of this action?
 exim paniclog /var/log/exim4/paniclog on lenovo has non-zero size, mail 
system might be broken. Up to 10 lines are quoted below.

2023-03-17 23:26:36 daemon_notifier_socket bind: Address already in use
2023-03-17 23:31:06 socket bind() to port 25 for address 127.0.0.1 failed: 
Address already in use: daemon abandoned
2023-03-17 23:31:34 socket bind() to port 25 for address 127.0.0.1 failed: 
Address already in use: daemon abandoned
   * What outcome did you expect instead?
 There is no error, and emails for LAN users via port 25 should work.

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


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

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

Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Markus Koschany]

Hello,

Am Donnerstag, dem 06.04.2023 um 12:54 +0200 schrieb Paul Gevers:
> Hi,
> 
> On Sun, 26 Mar 2023 16:26:00 +0200 Markus Koschany  wrote:
> > 1. There is no transition needed because only shrinksafe is affected by the
> > new
> > rhino version.
> 
> I'm wondering how you know, did you test (without rebuilding) all the 
> reverse dependencies? If so, how did you do that? (I'm worried we're 
> missing cases like src:dojo).

I always rebuild all reverse-dependencies with ratt before I upload a Java
library package. From my Java experience I know this uncovers almost all
problems. Rhino is not some obscure C/C++ library. It is a Javascript engine
written in Java. You can install reverse-dependencies and run them against the
new rhino version. If the package works, then there is no further action
required. Could I have missed a corner case? Maybe. But there is always a risk
whenever you change something. Remember why we did the upgrade in the first
place. We did fix two RC bugs and just hit a special case with a leaf package
(shrinksafe)

From dojo developer documentation:

"Note that the linkage requires the same version of Rhino used to build the
shrinksafe.jar. In versions prior to Dojo 1.3, ShrinkSafe was bundled into
Rhino by way of patch, and shipped as custom_rhino.jar."

We can do a binNMU for all reverse-dependencies but I do not think it is
necessary.

> 
> Also, given that shrinksafe is from a different source than rhino, this 
> qualifies as a transition (it *needs* changes in different (binary) 
> packages).

I cannot remember when we asked for a Java library transition in the past.
shrinksafe is, as I pointed out before, a special case. It was once part of the
rhino distribution and probably should have tightened the dependency on a
specific rhino version in the first place. 

> 
> > 2. shrinksafe has no reverse-dependencies
> 
> So it can be easily removed, but that's not a great service to its users.

No, we don't want to remove neither shrinksafe nor any other package. Please
don't exaggerate the problem at hand.


> > 3. We had the exact same problem before [1]. Back then the fix was to
> > rebuild
> > the package and to fix the shrinksafe tests by setting a specific
> > Javascript
> > version. [2] Since just rebuilding dojo also fixes the problem, I assume
> > that
> > we don't have to change this option.
> 
> Well, rebuilding without fixing the underlying issue is just papering 
> over. I'd like to get a proper (future proof) solution in place, see 
> below. (And yes, we can paper over for bookworm now).

The solution is to tighten the dependency on rhino and adjust the autopkgtest
accordingly. 

> > 4. I have rebuilt all rhino reverse-dependencies successfully.
> 
> Yes, normal transitions are handled that way, we (the Release Team) 
> schedule binNMU's for those (albeit we can't do arch:all that way).

As I said this is standard procedure for Java libraries which I touch. It does
not imply a transition is needed.

> > 6. Regarding Openrefine: It does only work with rhino 1.7.14 in unstable.
> > Hence
> > why I tightened the dependency on rhino to 1.7.14. The current version of
> > rhino
> > in testing breaks the Javascript application.
> 
> Suggesting even more that this is a real transition.

You are misunderstanding the problem. OpenRefine does not work with Rhino in
testing. The new rhino in unstable fixes the problem. Again, rhino 1.7.14 is
the solution, not the cause of the problem.
[...]
> 



> 
> I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5 
> today, where I'll add an appropriate Breaks to src:rhino and an 
> appropriate versioned Depends to src:dojo. Please let me know if you 
> object or want to handle this yourself.

Fine with me and thanks!


Markus


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

Bug#1033975: unblock: webp-pixbuf-loader/0.2.1-1

[David Heidelberg]

On 06/04/2023 08:50, Sebastian Ramacher wrote:

Control: tags -1 moreinfo

On 2023-04-05 12:46:52 +0200, David Heidelberg wrote:

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: webp-pixbuf-loa...@packages.debian.org
Control: affects -1 + src:webp-pixbuf-loader

Please unblock package webp-pixbuf-loader

[ Reason ]
Version 0.0.5 contains multiple bugs and 0.2.0 [1] I pushed was solution
to these problems. Sadly meanwhile 0.2.1 [2] was release with another fix,
which we pushed, but it didn't got into timeframe for 10 days acceptance.

Please provide some information on the issues that were fixed which does
not require us to read upstream changelogs. And since webp-pixbuf-loader
is a key package, the main question for me is whether those bugs could
be fixed with a targetted fix on top of 0.0.5-5 instead.


Hello Sebastian.

Two main bugs present in 0.0.5 solved by moving tovards to 0.2.1 is:

- Exchanging animation for static image leaks memory
- Fixes endianess bug while reading values from buffer

As you see, the webp-pixbuf-loader isn't huge project and backporting 
fixes from recent version would be a piece of cake on top of 0.2.1, on 
other hand having to backport on 0.0.5, I would be afraid to introduce 
more issues and also would be pretty time consuming.


David

P.S. Whole project changelog, see there is multiple 
README/CI/build/tests work, so only few commits regarding to the 
functionality. Also the project has much better tests now, so that 
should also be ensuring, that later in bookworm cycle it won't get 
broken by hotfixes.


```
decd327 (tag: 0.2.1) tests: move test samples to data subfolder
d0e1568 tests: add NULL GError test for all codepaths
7af088d tests: commit missing meson changes for icc profile test
f708996 io-webp.c: add ICC profile storage support
eaa4ea0 (tag: 0.2.0) io-webp.c: add function to check supported format 
options
48d9524 io-webp.c: simplify string to 0-100 int conversion for quality 
option

2e1c547 README: add missing CI badges
a0f8a92 README: add CI badges
2f950fd (tag: 0.1.2) ci: add macos build
19e18d7 tests: add save test and rework test infrastructure
17b87ec io-webp.c: bring back save functionality
c84d336 (tag: 0.1.1) io-webp.c: configure decoder output to write in pixbuf
219ae4c io-webp.c: simplify method naming and order implementations
bf0fca2 io-webp.c: remove WRITABLE flag
0dcbc1e (tag: 0.1.0) Update license headers
c80df7a meson: improve warnings for query_loaders script
3624980 ci: install valgrind through apt
2d67225 ci: add valgrind leak checks
7c891f9 tests: fix double free in t4.c
982d28b Simplified implementation of both static and animated webp 
implementation

1169cbc docs: add homebrew installation note
f91f79c (tag: 0.0.7) meson: enforcing all endian related includes breaks 
msys2 builds

39deda6 Show an error if no endian related header is found
88c1f65 Do not run query-loaders upon install, show a warning that it 
has to be run instead

0f78520 meson: make update cache dir optional
10667e3 meson: break loop if one of the endianness headers is found
7805f51 Fix building on *BSD OS's and Solaris
9482c8f meson: fix link arguments for tests
61fb6ed tests: t3.c refactor and minimize test code
cad173d tests: revert t3.c refactoring to fix windows build failure
ea511d0 ci: print logs on test errors
909b52e Build plugin as shared module instead
cf9ad75 tests: refactor animation test code into a single simplified test
26e9ebf Add Windows CI
652ebc0 tests: Refactor t4.c to remove unneeded code
43d3d77 meson: do not retrieve system triad on non Linux systems
90b1f41 tests: remove deprecation warnings for GTimeVal
43c6624 meson: allow nested variable definition for the gdk pixbuf 
module path for relocatable installations
e2f io-webp.c: Remove memory leak from use of heap allocated 
save_context

faf4eba tests: Remove unnecessary GError
08aa6ed ci: Remove fedora.yml workflow
702ad40 ci: Add Fedora workflow
1e1cad7 (tag: 0.0.6) ci: use ninja -C for the build dir
ee74005 ci: use latest ubuntu to get up to date meson
9bbbc46 Add checkout step
e3ef3ea ci: Fix workflow path
eb06324 Add initial GitHub Actions CI script
64f2b2f Update build instructions in README.md
cfac732 meson: automatically detect gdk-pixbuf-query-loaders path on Debian
d4c2057 Removing travis file as free plans do not cover us anymore
4e84549 io-webp.io: Fixes endianess bug while reading values from buffer
```




[1] https://github.com/aruiz/webp-pixbuf-loader/releases/tag/0.2.0
[2] https://github.com/aruiz/webp-pixbuf-loader/releases/tag/0.2.1

[ Impact ]

Buggy user experience on old codebase, multiple critical and not resolved bugs.

[ Tests ]
The package has autopkgtests, which has been extended in 0.2.0 and
0.2.1.

[ Risks ]
Package itself is very small and after codebase rework, the fixes are
incremental and self-explaining covered with tests.

[ Checklist ]
   [ ] all changes are documented in the 

Bug#1009776: podman: Packages uidmap and slirp4netns should be full dependencies

[Faidon Liambotis]

On Fri, Aug 19, 2022 at 02:16:19PM +0200, Andrej Shadura wrote:
> > I have to respectfully disagree here. In Debian, "Recommends"
> > relationships are installed by default, and your message indicates to me
> > that you have configured your system to not install them. It furthermore
> > seems to me that this bug is asking for a convenience that is making
> > your non-standard setup easier, while making other setups where podman
> > is used only in 'root' mode, impossible to install without idmap and
> > friends.
> > I'm going to leave this bug open to remind myself to think about this
> > from time to time, but I still wanted to document my thinking process
> > here more clearly.
> 
> There’s another thing, which I mentioned but I should have made more clear.
> The upstream states the rootless mode is the main mode of operation, hence I
> think it should be available regardless of Recommends, don’t you think?
> 
> Also, from what I gathered talking to Debian and Ubuntu users of podman who
> are not DDs, many of them are frustrated by papercuts like this one, so in
> general I think the package should be made to work as effortlessly as
> possible. So even if the user hasn’t got Recommends installation enabled,
> podman should probably be packaged not to make them stumble upon this.

It's months later and this is a drive-by comment but:

First of all, I'd say that rootless is the main differentiator from
Docker, but far from being a "main mode". Podman works equally well in
rootless and rootful configurations, with the latter being the mode that
one would use as a 1:1 Docker replacement, or in production environment
scenarios where more performant or advanced network configurations are
required.

Second,  according to Policy § 7.2, "The Recommends field should list
packages that would be found together with this one in all but unusual
installations". If folks explicitly pass --no-install-recommends to apt
(or the equivalent preferences.d), then they get to keep the pieces when
things break; I wouldn't call that a papercut. The installation /is/
effortless out of the box, unless one decides that they want to do
something against the maintainer's recommendations, in which case they
should be able to, but with (a bit of) a price to pay.

Hard-Depending on dependencies that are not actually required in common
modes of operation, in this case e.g. servers using podman for
production services, doesn't serve our users -- it just forces
unnecessary cruft on their system, for little benefit to others.

Note that I'm not on a quest against rootless: a couple of years back,
on #987207, I argued to downgrade iptables from Depends to Recommends,
for the same reasosn but to the benefit of rootless users: to avoid the
cruft in rootless configurations :)

So I'm definitely +1 to mark this as wontfix, FWIW.

Best,
Faidon

Bug#1032826: Debian RT Incorrect redirection for dgit-repos

[Ian Jackson]

Control: close -1

We have fixed this by changing the Apache configuration on the server,
for the vhost git.dgit.debian.org.

Thanks to DSA for their help.  (See [rt.debian.org #9169].)

Ian.

-- 
Ian JacksonThese opinions are my own.  

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

Bug#977027: [Pkg-javascript-devel] Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Bastien ROUCARIES]

Le jeu. 6 avr. 2023 à 11:24, Paul Gevers  a écrit :
>
> Control: tags -1 pending patch
>
> On 06-04-2023 12:54, Paul Gevers wrote:
> > I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5
>
> Please find the debdiffs attached.

Go ahead
>
> Paul
> --
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#1034013: dkms: rebuild kernel modules on upgrades of kernel without stable abi

[Andreas Beckmann]

Package: dkms
Version: 3.0.10-6
Severity: important
X-Debbugs-Cc: Johannes Schauer Marin Rodrigues 

Currently dkms builds kernel modules (if marked with AUTOINSTALL=yes)

* on installation and upgrade of a *-dkms package for all installed
  kernel (header)s

* on initial installation of of a linux-{headers,image} package for all
  installed *-dkms packages

but not after upgrades of linux-{headers,image}-$KVERS (unless $KVERS
changed) where version (x.y.0) and abi (-z-)  don't change.

This is probably OK for kernels with a stable ABI, but not for kernels
w/o a stable ABI as specially documented for '-trunk-' (and '-0-'
nowadays, too?). For these kernels all dkms modules should be rebuilt on
every linux-{headers,image}-$KVER upgrade (where $KVER did not change)

Andreas

Bug#1032948:

[Costas Drogos]

On Wed, Apr 5, 2023 at 5:57 PM Costas Drogos  wrote:
>
> Hi,
>
> I'm also affected by this - recent lenovo laptop with a dock that
> connects/removes multiple usb devices at the same time. Been getting
> the oops after every resumption or every time multiple usb devices got
> reset, with 6.1.0-6 and 6.1.0-7.
>
> Built and booted a patched debian 6.1.20 and been using it for ~1hr
> now without experiencing any issues. Connected and disconnected the
> dock (and its devices) multiple times, suspended/resumed twice as
> well.
>
> I'd prefer to keep using it for some more time before calling it a
> success, but it certainly feels better. With the normal kernel
> disconnecting the dock was triggering a crash almost every time.
>

Still stable throughout the day with the patched kernel. No oopses or
crashes after unplugging the dock or random usb devices and
suspending/resuming multiple times since yesterday.

It seems these patches solve the issue - for my combination of devices at least!

best,
Costas

Bug#1028104: libboost-dev: Boost with C++20 uses unavailable std functions

[Paul Gevers]

Hi,

On Tue, 21 Mar 2023 21:58:11 +0100 Paul Gevers  wrote:

On Sun, 08 Jan 2023 00:26:39 +0100 Andreas Beckmann  wrote:
> This happens with g++-12 but not with g++-11.
> It is fixed in the boost version in experimental.

Any chance for a *targeted* fix in bookworm?


Ping. (No is also an answer).

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#956752: Bug 956752: linux-image-rt-amd64: No access to EFI variables possible with rt kernels

[Sercan Sarı]

Here is the workaround accessing EFI variables with rt-kernels:  #1021245 -
linux-image-5.10.0-18-rt-amd64: can't access EFIVARS when using rt version
of kernel - Debian Bug report logs

Bug#1034012: libzstd: Possible data corruption in zstd 1.5.x

[Andrey Semashev]

Package: libzstd1
Version: 1.5.4+dfsg2-3
Source: libzstd

It was discovered that zstd versions from 1.5.0 to 1.5.4, inclusively,
may exhibit data corruption on high compression levels (>= 13). This is
fixed in zstd 1.5.5 and outlined in the release notes and the related
pull request:

https://github.com/facebook/zstd/releases/tag/v1.5.5
https://github.com/facebook/zstd/pull/3517

Please consider upgrading to zstd 1.5.5 or backporting the patch with
the fix.

Bug#1034011: shotwell: Fails to build with vala 0.56-6

[Jeremy Bícha]

Source: shotwell
Version: 0.30.17-1
Severity: important
Tags: ftbfs trixie patch

shotwell fails to build with vala 0.56.6 from Experimental.

A sample build log from Ubuntu 23.04 is at
https://launchpadlibrarian.net/657577451/buildlog_ubuntu-lunar-amd64.shotwell_0.30.17-1ubuntu1_BUILDING.txt.gz

This can be fixed by cherry-picking
https://gitlab.gnome.org/GNOME/shotwell/-/commit/1c8760ed7

Thank you,
Jeremy Bícha

Bug#1032948: linux-image-6.1.0-5-amd64: oops in ucsi_acpi_notify

[Julien Cristau]

Control: tag -1 upstream fixed-upstream patch

On Tue, Apr  4, 2023 at 22:03:28 +0200, Diederik de Haas wrote:

> On Tuesday, 4 April 2023 13:11:16 CEST Julien Cristau wrote:
> > On Mon, Apr  3, 2023 at 15:16:42 +0200, Diederik de Haas wrote:
> > > On Saturday, 18 March 2023 23:10:39 CEST Diederik de Haas wrote:
> > > 
> > > On Monday, 3 April 2023 14:57:02 CEST Julien Cristau wrote:
> > > > > Not sure why patchwork still shows v2 of the patch as v4 is available
> > > > > here:
> > > > > https://lore.kernel.org/all/20230308154244.722337-1-hdego...@redhat.com/
> > > > 
> > > > I'll give the patch series you linked in the other reply a go now.
> > > 
> > > FTR: 2 out of the 3 patches have landed in 6.1.22
> > 
> > Thanks for letting me know.  I've built 6.1.22 from upstream and it
> > doesn't seem to crash.
> 
> That's awesome :-) Let's hope it stays that way now ;-)
> 
> You may have seen it on IRC already, but could you test a
> Debian 6.1.20-1 kernel with (only) those patches applied?
> These are the URLs:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y=1c5abcb13491da8c049f20462189c12c753ba978
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.1.y=1e8525f37871741a52370627633962f8bdcab15a
> 
> If you need help with that, feel free to ask :-)
> 
> If we know that fixes the issue too, then we have the option of going for
> a 6.1.20-2 release with just those 2 patches (and what's already in -2 now).
> 
Testing this now:

linux (6.1.20-1a~test) UNRELEASED; urgency=medium

  * Testing patches ../0001-usb-ucsi-Fix-NULL-pointer-deref-in-
ucsi_connector_ch.patch ../0001-usb-ucsi_acpi-Increase-the-command-
completion-timeou.patch

 -- Julien Cristau   Wed, 05 Apr 2023 11:09:30 +

and it doesn't seem to crash, as far as I can tell.

Cheers,
Julien

Bug#1034010: shotwell: Should depend on webp-pixbuf-loader

[Jeremy Bícha]

Source: shotwell
Version: 0.30.17-1
Severity: important

Shotwell now has Build-Depends: webp-pixbuf-loader. This is incorrect:
webp-pixbuf-loader is not required to Build the package.

However, Shotwell's .desktop has been patched to declare that it has
support for opening web files. It cannot open webp files unless
webp-pixbuf-loader is installed.

Therefore, please move webp-pixbuf-loader from Build-Depends to Depends.

Thank you,
Jeremy Bícha

Bug#1033703: gffread: autopkgtest regression: test dependency not in testing

[Paul Gevers]

Control: tags -1 bookworm-ignore
Control: tags -1 - bookworm

Hi

On Thu, 30 Mar 2023 19:04:08 +0200 Paul Gevers  wrote:

Control: tags -1 bookworm


[Release Team member hat on] Because 
we're currently in the hard freeze, I've marked this bug as 
bookworm-ignore, but targeted fixes are welcome.


Sorry, I had a typo.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033981: command-not-found: Incompatible with deb822 apt sources

[H.-Dirk Schmitt]

Am Mittwoch, dem 05.04.2023 um 17:21 +0200 schrieb Julian Andres Klode:
> > WARNING:root:could not open file
> > '/etc/apt/sources.list.d/bookworm.security.sources': Unable to
> > parse section data
> > Same for all other sources files in deb822 format.
> 
> 23.04.0 is the version I introduced deb822 support, so yes, it
> absolutely does support it, older versions ignore the files.
> 
> The warning says the file is wrong (or the parser).

I think the parser in incorrect.
The file is processed by apt correctly. 
> 
> I think you may be missing an empty line at the end or your comments
> trip up the parser. It is generally expected that comments are part
> of sections and there are no fraudulent sections that consist of just
> comments.
> 

IMHO should the simple 'bash-like' comment format nether confuse a
parser. This comment line  can be eleminated before the content parsing
is done. 


I attached the whole content of my /apt/sources.list.d.



apt-deb822.tar
Description: Unix tar archive

Bug#1034009: gocryptfs: Missing fuse in package dependency

[Christian Frost]

Package: gocryptfs
Version: 1.8.0-1+b6
Severity: normal
X-Debbugs-Cc: debian-bugrep...@frost-it.de

Dear Maintainer,

please add the fuse package as an dependency for gocryptfs.

See https://github.com/rfjakob/gocryptfs the section Installation.

"The fuse package from your distribution must be installed for mounting to 
work."

Mounting is an essential component in gocryptfs. So setting fuse as an 
installation dependency it makes the use of gocryptfs more comportable after an
installation. Otherwise you must install it manual, that is the current way.

Thanks,
Christian


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

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

Versions of packages gocryptfs depends on:
ii  libc6  2.31-13+deb11u5
ii  libfuse2   2.9.9-5
ii  libssl1.1  1.1.1n-0+deb11u4

gocryptfs recommends no packages.

gocryptfs suggests no packages.

-- no debconf information

Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Paul Gevers]

Control: tags -1 pending patch

On 06-04-2023 12:54, Paul Gevers wrote:

I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5


Please find the debdiffs attached.

Paul
diff -Nru rhino-1.7.14/debian/changelog rhino-1.7.14/debian/changelog
--- rhino-1.7.14/debian/changelog   2023-02-18 00:46:00.0 +0100
+++ rhino-1.7.14/debian/changelog   2023-04-06 13:10:20.0 +0200
@@ -1,3 +1,10 @@
+rhino (1.7.14-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Add versioned Breaks on shrinksafe (Closes: #977027)
+
+ -- Paul Gevers   Thu, 06 Apr 2023 13:10:20 +0200
+
 rhino (1.7.14-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru rhino-1.7.14/debian/control rhino-1.7.14/debian/control
--- rhino-1.7.14/debian/control 2023-02-18 00:46:00.0 +0100
+++ rhino-1.7.14/debian/control 2023-04-06 13:10:20.0 +0200
@@ -31,6 +31,7 @@
 Section: java
 Architecture: all
 Depends: ${misc:Depends}
+Breaks: shrinksafe (<< 1.17.2+dfsg1-2.1~)
 Suggests: rhino
 Description: Libraries for rhino Java Script Engine
  Rhino is an implementation of the JavaScript language written
diff -Nru dojo-1.17.2+dfsg1/debian/changelog dojo-1.17.2+dfsg1/debian/changelog
--- dojo-1.17.2+dfsg1/debian/changelog  2022-08-13 18:48:08.0 +0200
+++ dojo-1.17.2+dfsg1/debian/changelog  2023-04-06 12:59:48.0 +0200
@@ -1,3 +1,10 @@
+dojo (1.17.2+dfsg1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Add versioned (Build-)Depends on rhino/librhino-java (Closes: #977027)
+
+ -- Paul Gevers   Thu, 06 Apr 2023 12:59:48 +0200
+
 dojo (1.17.2+dfsg1-2) unstable; urgency=medium
 
   * Add jdupes to build-dep
diff -Nru dojo-1.17.2+dfsg1/debian/control dojo-1.17.2+dfsg1/debian/control
--- dojo-1.17.2+dfsg1/debian/control2022-08-13 18:47:45.0 +0200
+++ dojo-1.17.2+dfsg1/debian/control2023-04-06 12:59:48.0 +0200
@@ -6,7 +6,7 @@
   Bastien Roucariès 
 Build-Depends: debhelper-compat (= 13), nodejs,
  javahelper
-Build-Depends-Indep: default-jdk, rhino, rsync , jdupes 
+Build-Depends-Indep: default-jdk, rhino (>= 1.7.14), rsync , jdupes 

 Standards-Version: 4.6.1.0
 Rules-Requires-Root: no
 Homepage: https://dojotoolkit.org
@@ -63,7 +63,7 @@
 
 Package: shrinksafe
 Architecture: all
-Depends: ${misc:Depends}, ${java:Depends}, librhino-java
+Depends: ${misc:Depends}, ${java:Depends}, librhino-java (>= 1.7.14)
 Description: JavaScript compression system
  ShrinkSafe is a JavaScript compression system. It can typically reduce the
  size of your scripts by a third or more, depending on your programming style.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033942: nmu: ppl_1:1.2-8.1

[Lev Lamberov]

Hi Paul,

Чт 06 апр 2023 @ 12:05 Paul Gevers :

> On 05-04-2023 07:38, Lev Lamberov wrote:
>> Вт 04 апр 2023 @ 21:42 Paul Gevers :
>>> On 04-04-2023 15:05, Lev Lamberov wrote:
 Please, rebuild ppl against swi-prolog 9.0.4+dfsg-2 in unstable. The
 ppl package in unstable and testing was build against the older
 swi-prolog version, containing older library. For more information,
 please see this swi-prolog [bug].

 [bug] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033636
>>>
>>> It's a shame we discussed this in bug 1022253 [1]. Do you know what was
>>> flawed in our assessment?
>>>
>>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022253#24
>> 
>> Yes, turns out I was wrong.
>
> I've scheduled the binNMU's, but as discussed in bug 1033636, please fix 
> this properly after the bookworm release. Following standard workflows 
> prevents this particular problem.

Thank you!

Regards,
Lev

Bug#1034007: wmwork FTCBFS: uses the build architecture strip

[Helmut Grohne]

Source: wmwork
Version: 0.2.6-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

wmwork fails to cross build from source, because debian/rules hard codes
the build architecture strip. I'm attaching a patch to make it use the
host architecture one via dpkg's buildtools.mk for your convenience.

Helmut
diff --minimal -Nru wmwork-0.2.6/debian/changelog wmwork-0.2.6/debian/changelog
--- wmwork-0.2.6/debian/changelog   2020-07-26 12:55:33.0 +0200
+++ wmwork-0.2.6/debian/changelog   2023-04-06 12:50:28.0 +0200
@@ -1,3 +1,10 @@
+wmwork (0.2.6-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Use the host architecture strip, closes: #-1.
+
+ -- Helmut Grohne   Thu, 06 Apr 2023 12:50:28 +0200
+
 wmwork (0.2.6-4) unstable; urgency=medium
 
   * source-only upload
diff --minimal -Nru wmwork-0.2.6/debian/rules wmwork-0.2.6/debian/rules
--- wmwork-0.2.6/debian/rules   2015-06-07 18:52:29.0 +0200
+++ wmwork-0.2.6/debian/rules   2023-04-06 12:50:27.0 +0200
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/buildtools.mk
+
 BUILDDIR = debian/wmwork
 DEBDIR   = $(BUILDDIR)/DEBIAN
 DOCDIR   = $(BUILDDIR)/usr/share/doc/wmwork
@@ -53,7 +55,7 @@
 
$(MAKE) -C src install DESTDIR=$(CURDIR)/debian/wmwork
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-   strip -R .comment -R .note $(BUILDDIR)/usr/bin/wmwork
+   $(STRIP) -R .comment -R .note $(BUILDDIR)/usr/bin/wmwork
 endif
gzip -9n $(BUILDDIR)/usr/share/man/man1/wmwork.1
install -D -o root -g root -m 0644 debian/menu 
$(BUILDDIR)/usr/share/menu/wmwork

Bug#1034008: ircd-hybrid FTCBFS: AC_RUN_IFELSE

[Helmut Grohne]

Source: ircd-hybrid
Version: 1:8.2.43+dfsg.1-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ircd-hybrid fails to cross build from source, because it uses
AC_RUN_IFELSE. This macro doesn't work during cross compilation.
Fortunately, it is only ever used for checking whether a compile-time
constant is large enough. Such constants can also be extracted using
AC_COMPUTE_INT and this macro has special handling for cross
compilation. I'm attaching a patch for your convenience.

Helmut
--- ircd-hybrid-8.2.43+dfsg.1.orig/m4/ax_arg_with_tls.m4
+++ ircd-hybrid-8.2.43+dfsg.1/m4/ax_arg_with_tls.m4
@@ -5,11 +5,9 @@
 if test "$with_tls" = "openssl" ||
test "$with_tls" = "auto"; then
 AC_CHECK_HEADER([openssl/opensslv.h], [
-  AC_RUN_IFELSE([
-AC_LANG_PROGRAM([
-  #include 
-  #include ], [
-  exit(!(OPENSSL_VERSION_NUMBER >= 0x1010100fL)); ])], [AC_CHECK_LIB([crypto], [RSA_free], [], [], [])], [], [])])
+  AC_COMPUTE_INT([OPENSSL_VERSION_NUMBER],[OPENSSL_VERSION_NUMBER],[#include ])
+  AS_IF([test "$OPENSSL_VERSION_NUMBER" -ge $((0x1010100f))],[AC_CHECK_LIB([crypto], [RSA_free], [], [], [])])
+])
 
 AS_IF([test "$ac_cv_lib_crypto_RSA_free" = "yes"], [AC_CHECK_LIB([ssl], [SSL_connect])], [])
 
@@ -24,11 +22,9 @@
   if test "$ac_cv_lib_ssl_SSL_connect" != "yes"; then
 
 AC_CHECK_HEADER([gnutls/gnutls.h], [
-  AC_RUN_IFELSE([
-AC_LANG_PROGRAM([
-  #include 
-  #include ], [
-  exit(!(GNUTLS_VERSION_NUMBER >= 0x030605)); ])], [AC_CHECK_LIB([gnutls], [gnutls_init], [], [], [])], [], [])])
+  AC_COMPUTE_INT([GNUTLS_VERSION_NUMBER],[GNUTLS_VERSION_NUMBER],[#include ])
+  AS_IF([test "$GNUTLS_VERSION_NUMBER" -ge $((0x030605))],[AC_CHECK_LIB([gnutls], [gnutls_init], [], [], [])])
+])
 
 AC_MSG_CHECKING([for GnuTLS 3.6.5 and above])
 AS_IF([test "$ac_cv_lib_gnutls_gnutls_init" = "yes"],
@@ -43,11 +39,9 @@
  test "$ac_cv_lib_gnutls_gnutls_init" != "yes"; then
 
 AC_CHECK_HEADER([wolfssl/ssl.h], [
-  AC_RUN_IFELSE([
-AC_LANG_PROGRAM([
-  #include 
-  #include ], [
-  exit(!(LIBWOLFSSL_VERSION_HEX >= 0x04003000)); ])], [AC_CHECK_LIB([wolfssl], [wolfSSL_X509_digest], [], [], [])], [], [])])
+  AC_COMPUTE_INT([LIBWOLFSSL_VERSION_HEX],[LIBWOLFSSL_VERSION_HEX],[#include ])
+  AS_IF([test "$LIBWOLFSSL_VERSION_HEX" -ge $((0x04003000))],[AC_CHECK_LIB([wolfssl], [wolfSSL_X509_digest], [], [], [])])
+])
 
 AC_MSG_CHECKING([for wolfSSL 4.3.0 and above built with extended/full OpenSSL compatibility layer])
 AS_IF([test "$ac_cv_lib_wolfssl_wolfSSL_X509_digest" = "yes"],

Bug#1034005: ibus-kkc FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: ibus-kkc
Version: 1.5.22-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ibus-kkc fails to cross build from source, because it configures for the
build architecture. If you look into a native build, you can spot that
it actually configures twice: once during override_dh_autoreconf and
once during dh_auto_configure. It is that former invocation that fails
during cross builds and it is that former invocation that is entirely
useless. Let's skip it to make cross builds succeed. I'm attaching a
patch for your convenience.

Helmut
diff --minimal -Nru ibus-kkc-1.5.22/debian/changelog 
ibus-kkc-1.5.22/debian/changelog
--- ibus-kkc-1.5.22/debian/changelog2022-09-27 22:09:18.0 +0200
+++ ibus-kkc-1.5.22/debian/changelog2023-04-05 21:33:01.0 +0200
@@ -1,3 +1,10 @@
+ibus-kkc (1.5.22-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Configure only once. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 05 Apr 2023 21:33:01 +0200
+
 ibus-kkc (1.5.22-3) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru ibus-kkc-1.5.22/debian/rules ibus-kkc-1.5.22/debian/rules
--- ibus-kkc-1.5.22/debian/rules2022-09-27 22:04:41.0 +0200
+++ ibus-kkc-1.5.22/debian/rules2023-04-05 21:32:59.0 +0200
@@ -16,7 +16,7 @@
dh $@
 
 override_dh_autoreconf:
-   ./autogen.sh
+   NOCONFIGURE=1 ./autogen.sh
 
 execute_before_dh_auto_configure:
sed -i 's!jp!default!' 
src/kkc.xml.in.in  

Bug#1034006: libowfat FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: libowfat
Version: 0.32-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libowfat fails to cross build from source, because it builds for the
build architecture. To cross build libowfat one is supposed to supply
either CCC or CROSS. Beyond that, it fails to use CCC for the linker
step. I'm attaching a patch for your convenience.

Helmut
diff --minimal -Nru libowfat-0.32/debian/changelog 
libowfat-0.32/debian/changelog
--- libowfat-0.32/debian/changelog  2022-11-10 16:32:49.0 +0100
+++ libowfat-0.32/debian/changelog  2023-04-06 09:31:10.0 +0200
@@ -1,3 +1,11 @@
+libowfat (0.32-5) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: (Closes: #-1)
++ Pass CCC to make.
++ cross.patch: Use CCC for linking as well.
+
+ -- Helmut Grohne   Thu, 06 Apr 2023 09:31:10 +0200
+
 libowfat (0.32-4) unstable; urgency=high
 
   * QA upload
diff --minimal -Nru libowfat-0.32/debian/patches/cross.patch 
libowfat-0.32/debian/patches/cross.patch
--- libowfat-0.32/debian/patches/cross.patch1970-01-01 01:00:00.0 
+0100
+++ libowfat-0.32/debian/patches/cross.patch2023-04-06 09:31:10.0 
+0200
@@ -0,0 +1,9 @@
+--- libowfat-0.32.orig/GNUmakefile
 libowfat-0.32/GNUmakefile
+@@ -394,5 +394,5 @@
+   ln -sf $< $@
+ 
+ libowfat.so.0: $(ALL_OBJS)
+-  $(CC) -shared -Wl,-soname=$@ $(LDFLAGS) $^ -o $@
++  $(CCC) -shared -Wl,-soname=$@ $(LDFLAGS) $^ -o $@
+ 
diff --minimal -Nru libowfat-0.32/debian/patches/series 
libowfat-0.32/debian/patches/series
--- libowfat-0.32/debian/patches/series 2022-11-10 16:31:16.0 +0100
+++ libowfat-0.32/debian/patches/series 2023-04-06 09:31:10.0 +0200
@@ -6,3 +6,4 @@
 07-fix-FD_CLOEXEC.patch
 08-clang-ftbfs.diff
 fix_gcc10.patch
+cross.patch
diff --minimal -Nru libowfat-0.32/debian/rules libowfat-0.32/debian/rules
--- libowfat-0.32/debian/rules  2022-11-10 16:31:16.0 +0100
+++ libowfat-0.32/debian/rules  2023-04-06 09:31:10.0 +0200
@@ -1,5 +1,7 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/buildtools.mk
+
 CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS)
 CFLAGS:=$(shell dpkg-buildflags --get CFLAGS) $(CPPFLAGS) -I.
 CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS) $(CPPFLAGS)
@@ -9,9 +11,9 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) -f $(CURDIR)/GNUmakefile CFLAGS="$(CFLAGS) -fPIC" DIET='' 
libowfat.so
+   $(MAKE) -f $(CURDIR)/GNUmakefile CCC=$(CC) CFLAGS="$(CFLAGS) -fPIC" 
DIET='' libowfat.so
$(MAKE) -f $(CURDIR)/GNUmakefile clean
-   $(MAKE) -f $(CURDIR)/GNUmakefile CFLAGS="$(CFLAGS)" DIET=''
+   $(MAKE) -f $(CURDIR)/GNUmakefile CCC=$(CC) CFLAGS="$(CFLAGS)" DIET=''
rm entities.h
 
 override_dh_installchangelogs:

Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Paul Gevers]

Hi,

On Sun, 26 Mar 2023 16:26:00 +0200 Markus Koschany  wrote:

1. There is no transition needed because only shrinksafe is affected by the new
rhino version.


I'm wondering how you know, did you test (without rebuilding) all the 
reverse dependencies? If so, how did you do that? (I'm worried we're 
missing cases like src:dojo).


Also, given that shrinksafe is from a different source than rhino, this 
qualifies as a transition (it *needs* changes in different (binary) 
packages).



2. shrinksafe has no reverse-dependencies


So it can be easily removed, but that's not a great service to its users.


3. We had the exact same problem before [1]. Back then the fix was to rebuild
the package and to fix the shrinksafe tests by setting a specific Javascript
version. [2] Since just rebuilding dojo also fixes the problem, I assume that
we don't have to change this option.


Well, rebuilding without fixing the underlying issue is just papering 
over. I'd like to get a proper (future proof) solution in place, see 
below. (And yes, we can paper over for bookworm now).



4. I have rebuilt all rhino reverse-dependencies successfully.


Yes, normal transitions are handled that way, we (the Release Team) 
schedule binNMU's for those (albeit we can't do arch:all that way).



6. Regarding Openrefine: It does only work with rhino 1.7.14 in unstable. Hence
why I tightened the dependency on rhino to 1.7.14. The current version of rhino
in testing breaks the Javascript application.


Suggesting even more that this is a real transition.


7. Summary: I recommend to rebuild dojo to fix the autopkgtests. I suggest to
reconsider the current autopkgtest behavior. At least there should be a warning
or a note for maintainers in the future that dojo requires a rebuild whenever
rhino changes.


In Debian we normally handle that by either real or virtual abi packages 
(although in your other message you mention you didn't know of the 
breakage, so I guess that wouldn't have helped in this particular case, 
but it would have given you the knob to fix it after the discovery of 
the breakage). We have a huge collection of examples in Debian for that. 
If rhino (the binary) were to Provides an abi, than dojo could Depends 
on that (with the right version inserted during the build). The Release 
Team tooling [1] would then pick up when the ABI is bumped such that 
binNMU's can be scheduled (or the appropriate people can be notified in 
case of arch:all).


I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5 
today, where I'll add an appropriate Breaks to src:rhino and an 
appropriate versioned Depends to src:dojo. Please let me know if you 
object or want to handle this yourself.


Normally we would defer the new upstream version and transition at this 
stage of the release, but I want rhino to migrate to bookworm.


Paul

[1] https://release.debian.org/transitions/


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1033632: qa.debian.org: sourceforge redirector for debian/watch files fails with a 500 error

[Christian Marillat]

On 06 avril 2023 11:26, Peter B  wrote:

> I think this problem is now resolved.
> The big red ERROR texts in the Watch column on my DDPO page are slowly going 
> away.

I don't know. I re-written my watch files to check sourceforge.net
instead of qa.debian.org

Christian

Bug#1033632: qa.debian.org: sourceforge redirector for debian/watch files fails with a 500 error

[Peter B]

I think this problem is now resolved.
The big red ERROR texts in the Watch column on my DDPO page are slowly going 
away.


Cheers,
Peter


On Wed, 29 Mar 2023 08:05:01 +0200 Christian Marillat  
wrote:
> Package: qa.debian.org
> Severity: normal
>
> Dear Maintainer,
>
> For several days sf.php no longer works:
>
> ,
> | uscan warn: In watchfile debian/watch, reading webpage
> | https://qa.debian.org/watch/sf.php/synfig/ failed: 500 Error
> `
>
> Christian
>
>

Bug#1034004: afl++: afl-clang(-fast) does not support -m32 due to missing afl-compiler-rt-32.o

[Jonathan Neuschäfer]

Package: afl++
Version: 4.04c-3
Severity: normal

Hello,

When trying to use "afl-clang -m32" on amd64, it fails, even though
clang itself supports -m32:

$ clang -m32 hello.c -o hello
$ ./hello
hello
$ afl-clang -m32 hello.c -o hello
afl-cc++4.04c by Michal Zalewski, Laszlo Szekeres, Marc Heuse - mode: 
LLVM-PCGUARD

[-] PROGRAM ABORT : -m32 is not supported by your compiler
 Location : edit_params(), src/afl-cc.c:1217

$

Strace reveals that the error happens after afl-clang fails to find 
afl-compiler-rt-32.o:

access("/usr/bin/../lib/afl//afl-compiler-rt-32.o", R_OK) = -1 ENOENT (No such 
file or directory)

Inclusion of afl-compiler-rt-32.o in amd64 builds of afl++ would be useful
because -m32 helps in certain fuzzing scenarios (using AddressSanitizer plus a
virtual memory limit).


Best regards,
jn


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

Kernel: Linux 6.1.0-7-amd64 (SMP w/12 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 afl++ depends on:
ii  build-essential  12.9
ii  clang1:14.0-55.6
ii  clang-14 1:14.0.6-12
ii  libc62.36-8
ii  libgcc-s112.2.0-14
ii  libpython3.113.11.2-6
ii  libstdc++6   12.2.0-14
ii  procps   2:4.0.2-3

Versions of packages afl++ recommends:
ii  afl++-doc  4.04c-3

Versions of packages afl++ suggests:
pn  gnuplot  

-- no debconf information

Bug#1033942: nmu: ppl_1:1.2-8.1

[Paul Gevers]

Hi Lev,

On 05-04-2023 07:38, Lev Lamberov wrote:

Вт 04 апр 2023 @ 21:42 Paul Gevers :

On 04-04-2023 15:05, Lev Lamberov wrote:

Please, rebuild ppl against swi-prolog 9.0.4+dfsg-2 in unstable. The
ppl package in unstable and testing was build against the older
swi-prolog version, containing older library. For more information,
please see this swi-prolog [bug].

[bug] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033636


It's a shame we discussed this in bug 1022253 [1]. Do you know what was
flawed in our assessment?

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022253#24


Yes, turns out I was wrong.


I've scheduled the binNMU's, but as discussed in bug 1033636, please fix 
this properly after the bookworm release. Following standard workflows 
prevents this particular problem.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1034003: certbot: Implement --no-random-sleep-on-renew on systemd timer

[Dan Poltawski]

Package: certbot
Version: 1.12.0-2
Severity: wishlist
Tags: patch

Dear Maintainer,

Upstream implemented a flag `--no-random-sleep-on-renew` for the use of
packagers - see https://github.com/certbot/certbot/issues/6596

The current behaviour leaves the systemd service 'activating' for more
5+ mins while the random sleep is taking place. We monitor for this
state because its often a sign of failure of services.

It's not necessary for this due to the RandomizedDelaySec in the systemd
timer itself.

It would be good to implement this option so that the service doesn't
get stuck activating for a long period of time and so i've attached a
patch.

thanks,

Dan


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

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

Versions of packages certbot depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  python33.9.2-3
ii  python3-certbot1.12.0-2

certbot recommends no packages.

Versions of packages certbot suggests:
pn  python-certbot-doc  
pn  python3-certbot-apache  
pn  python3-certbot-nginx   

-- debconf information excluded
>From 7be2e1fff7a48bdf6647259f37a09218c24c90bc Mon Sep 17 00:00:00 2001
From: Dan Poltawski 
Date: Thu, 6 Apr 2023 10:30:30 +0100
Subject: [PATCH 1/1] systemd: prevent randomised timer in certbot renew

This is already being handled by RandomizedDelaySec in the timer
---
 debian/certbot.service | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/certbot.service b/debian/certbot.service
index d5e13f2..bd4f95b 100644
--- a/debian/certbot.service
+++ b/debian/certbot.service
@@ -4,5 +4,5 @@ 
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
 Documentation=https://certbot.eff.org/docs
 [Service]
 Type=oneshot
-ExecStart=/usr/bin/certbot -q renew
+ExecStart=/usr/bin/certbot -q renew --no-random-sleep-on-renew
 PrivateTmp=true
-- 
2.39.2

Bug#1034002: ldapvi: Chase referrals option [-C, --chase] not documented

[Sam Morris]

Package: ldapvi
Version: 1.7-10+b6
Severity: minor

There is a rather useful -C option which can be used to disable referral
chasing:

$ ldapvi -C no

$ ldapvi --chase=no

It's not in the --help output nor the man page.

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

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

Versions of packages ldapvi depends on:
ii  libc6  2.36-8
ii  libcrypt1  1:4.4.33-2
ii  libglib2.0-0   2.74.6-1
ii  libldap-2.5-0  2.5.13+dfsg-5
ii  libpopt0   1.19+dfsg-1
ii  libreadline8   8.2-1.3
ii  libtinfo6  6.4-2

ldapvi recommends no packages.

ldapvi suggests no packages.

-- no debconf information

Bug#1034001: bullseye-pu: package nvidia-graphics-drivers-tesla-450/450.236.01-1~deb11u1

[Andreas Beckmann]

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

Hi,

I'd like to update nvidia-graphics-drivers-tesla-450 in bullseye to a
new upstream release fixing a few CVEs.
It comes with some packaging changes to keep the packaging of the many
nvidia driver branches in sync, this time mostly cleanup of some cruft
bits, some renaming and translation updates.
This is a rebuild of the version form sid with no further changes.

nvidia-graphics-drivers-tesla-450 (450.236.01-1~deb11u1) bullseye; 
urgency=medium

  * Rebuild for bullseye.

 -- Andreas Beckmann   Thu, 06 Apr 2023 10:05:02 +0200

nvidia-graphics-drivers-tesla-450 (450.236.01-1) unstable; urgency=medium

  * New upstream Tesla release 450.236.01 (2023-03-30).
* Fixed CVE-2023-0184, CVE-2023-0189, CVE-2023-0180, CVE-2023-0185,
  CVE-2023-0198, CVE-2023-0199, CVE-2023-0188, CVE-2023-0190,
  CVE-2023-0194, CVE-2023-0195, CVE-2023-0191.  (Closes: #1033778)
  https://nvidia.custhelp.com/app/answers/detail/a_id/5452
* Improved compatibility with recent Linux kernels.

  [ Andreas Beckmann ]
  * Refresh patches.
  * Support acpi_op_remove callback returning void to fix kernel module build
for Linux 6.2.
  * nvidia-tesla-450-alternative: Access kmod config files over a versioned
symlink (510.108.03-3).
  * Add versioned Provides: nvidia-kernel-dkms-any (515.65.01-1).
  * New Brazilian Portuguese (pt_BR) debconf translations by Paulo Henrique de
Lima Santana.  (Closes: #1028265)
  * Updated Turkish (tr) debconf translations by Atila KOÇ. (Closes: #1033544)
  * Bump Standards-Version to 4.6.2. No changes needed.

 -- Andreas Beckmann   Thu, 06 Apr 2023 09:17:36 +0200


Andreas


ngd-tesla-450-450.236.01-1~deb11u1.diff.gz
Description: application/gzip

Bug#1034000: snapshot.debian.org: Unusual number of 503s on snapshot.d.o

[Mike Hommey]

Package: snapshot.debian.org
Severity: normal

We've seen an unusual number of 503s (and maybe other errors, because
debootstrap is not super verbose about what's happening) coming up from
snapshot.debian.org.

Examples of urls that recently failed (but later worked):

503s:
http://snapshot.debian.org/archive/debian-debug/20221204T212138Z/dists/bullseye-proposed-updates-debug/InRelease
http://snapshot.debian.org/archive/debian/20221204T212138Z/pool/main/d/debootstrap/debootstrap_1.0.123%2bdeb11u1_all.deb

Unknown error codes:
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/acl/acl_2.2.52-2_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/alsa-lib/libasound2_1.0.28-1_i386.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/at-spi2-atk/libatk-bridge2.0-0_2.14.0-2_i386.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/a/at-spi2-core/libatspi2.0-0_2.14.0-1_i386.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/e/e2fsprogs/e2fsprogs_1.42.12-2+b1_i386.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/g/gtk+3.0/libgtk-3-0_3.14.5-1+deb8u1_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/h/harfbuzz/libharfbuzz0b_0.9.35-2_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/k/krb5/libk5crypto3_1.12.1+dfsg-19+deb8u4_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/libs/libsepol/libsepol1_2.3-2_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/n/nettle/libhogweed2_2.7.1-5+deb8u2_i386.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/p/po-debconf/po-debconf_1.0.16+nmu3_all.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/p/procps/libprocps3_3.3.9-9+deb8u1_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/p/procps/procps_3.3.9-9+deb8u1_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/s/systemd/systemd_215-17+deb8u7_amd64.deb
http://snapshot.debian.org/archive/debian/20210208T213147Z/pool/main/t/tzdata/tzdata_2018e-0+deb8u1_all.deb

Mike

Bug#1033999: webkit2gtk: FTBFS on hurd-i386 (disable GBM support)

[Laurent Bigonville]

Source: webkit2gtk
Version: 2.39.1-1
Severity: important
Tags: ftbfs

Hello,

It seems that webkit FTBFS again on hurd-i386

The issue seems to be the fact that libgbm is missing:

-- Could NOT find GBM (missing: GBM_LIBRARIES GBM_INCLUDE_DIR)
CMake Error at Source/cmake/OptionsGTK.cmake:403 (message):
  GBM is required for USE_GBM

I guess that should be disabled on that arch?

Kind regards,
Laurent Bigonville


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

Kernel: Linux 6.1.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#1032392: python3-scikit-rf: import fails: AttributeError: module 'collections' has no attribute 'Sequence'

[Theppitak Karoonboonyanan]

Uploaded Josef Schneider's NMU to DELAYED/2-day queue.

Regards,
-- 
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/

Bug#1033761: nautilus-scripts-manager: nautilus-script-manager throws exception under bookworm

[Andreas Beckmann]

Followup-For: Bug #1033761

Actually, the problem starts even earlier:

# nautilus-scripts-manager
Traceback (most recent call last):
  File "/usr/bin/nautilus-scripts-manager", line 21, in 
from gi.repository import Pango, Gtk, GLib
  File "/usr/lib/python3/dist-packages/gi/importer.py", line 131, in load_module
raise ImportError('cannot import name %s, '
ImportError: cannot import name Pango, introspection typelib not found

nautilus-scripts-manager has insufficient dependencies, for bullseye
(and buster and stretch) this can be solved by a dependency on
gir1.2-gtk-3.0 (maybe with alternatives), for bookworm one could also
depend on gir1.2-gtk-4.0 as
alternative.


Andreas

Bug#1033975: unblock: webp-pixbuf-loader/0.2.1-1

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-04-05 12:46:52 +0200, David Heidelberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: webp-pixbuf-loa...@packages.debian.org
> Control: affects -1 + src:webp-pixbuf-loader
> 
> Please unblock package webp-pixbuf-loader
> 
> [ Reason ]
> Version 0.0.5 contains multiple bugs and 0.2.0 [1] I pushed was solution
> to these problems. Sadly meanwhile 0.2.1 [2] was release with another fix,
> which we pushed, but it didn't got into timeframe for 10 days acceptance.

Please provide some information on the issues that were fixed which does
not require us to read upstream changelogs. And since webp-pixbuf-loader
is a key package, the main question for me is whether those bugs could
be fixed with a targetted fix on top of 0.0.5-5 instead.

> [1] https://github.com/aruiz/webp-pixbuf-loader/releases/tag/0.2.0
> [2] https://github.com/aruiz/webp-pixbuf-loader/releases/tag/0.2.1
> 
> [ Impact ]
> 
> Buggy user experience on old codebase, multiple critical and not resolved 
> bugs.
> 
> [ Tests ]
> The package has autopkgtests, which has been extended in 0.2.0 and
> 0.2.1.
> 
> [ Risks ]
> Package itself is very small and after codebase rework, the fixes are
> incremental and self-explaining covered with tests.
> 
> [ Checklist ]
>   [ ] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [p] attach debdiff against the package in testing
> 
> [ Other info ]
> I attach diff against the previously sent 0.2.0, since that was targeted
> to get into bookworm. If requested, I can send debdiff against 0.0.5.

The debdiff between testing and the version in unstable is the relevant
one.

Cheers

> 
> ```
> --- webp-pixbuf-loader-0.2.0/debian/changelog 2023-02-26 11:55:51.0 
> +0100
> +++ webp-pixbuf-loader-0.2.1/debian/changelog 2023-03-04 01:30:48.0 
> +0100
> @@ -1,3 +1,11 @@
> +webp-pixbuf-loader (0.2.1-1) UNRELEASED; urgency=medium
> +
> +  [ David Heidelberg ]
> +  * New upstream version 0.2.1 (Closes: #1032334)
> +  * d/tests: extend tests by two new upstream tests
> +
> + -- David Heidelberg   Sat, 04 Mar 2023 01:30:48 +0100
> +
>  webp-pixbuf-loader (0.2.0-1) unstable; urgency=medium
>  
>* New upstream version 0.2.0
> diff -Nru webp-pixbuf-loader-0.2.0/debian/tests/determinism-test 
> webp-pixbuf-loader-0.2.1/debian/tests/determinism-test
> --- webp-pixbuf-loader-0.2.0/debian/tests/determinism-test2023-02-26 
> 11:55:51.0 +0100
> +++ webp-pixbuf-loader-0.2.1/debian/tests/determinism-test2023-03-04 
> 01:30:48.0 +0100
> @@ -4,7 +4,7 @@
>  
>  set -eu
>  
> -gdk-pixbuf-thumbnailer -s 128 tests/t1.webp test1.png
> +gdk-pixbuf-thumbnailer -s 128 tests/data/t1.webp test1.png
>  file -i test1.png | grep -qFw image/png
> -gdk-pixbuf-thumbnailer -s 128 tests/t1.webp test2.png
> +gdk-pixbuf-thumbnailer -s 128 tests/data/t1.webp test2.png
>  cmp -s test1.png test2.png
> diff -Nru webp-pixbuf-loader-0.2.0/debian/tests/upstream-tests 
> webp-pixbuf-loader-0.2.1/debian/tests/upstream-tests
> --- webp-pixbuf-loader-0.2.0/debian/tests/upstream-tests  2023-02-26 
> 11:55:51.0 +0100
> +++ webp-pixbuf-loader-0.2.1/debian/tests/upstream-tests  2023-03-04 
> 01:30:48.0 +0100
> @@ -4,8 +4,10 @@
>  
>  set -ex
>  
> -TEST_FILE="./tests/t1.webp" ./obj*/tests/t1
> -TEST_FILE="./tests/t2.webp" ./obj*/tests/t2
> -TEST_FILE="./tests/t3.webp" ./obj*/tests/t3
> -TEST_FILE="./tests/t1.webp" ./obj*/tests/t4
> -TEST_FILE="./tests/t2.webp" ./obj*/tests/t_save
> +TEST_FILE="./tests/data/t1.webp" ./obj*/tests/t1
> +TEST_FILE="./tests/data/t2.webp" ./obj*/tests/t2
> +TEST_FILE="./tests/data/t3.webp" ./obj*/tests/t3
> +TEST_FILE="./tests/data/t1.webp" ./obj*/tests/t4
> +TEST_FILE="./tests/data/t2.webp" ./obj*/tests/t_save
> +TEST_FILE="./tests/data/t2.webp" ./obj*/tests/t_icc
> +TEST_FILE="./tests/data/t2.webp" ./obj*/tests/t_null_error
> diff -Nru webp-pixbuf-loader-0.2.0/io-webp.c 
> webp-pixbuf-loader-0.2.1/io-webp.c
> --- webp-pixbuf-loader-0.2.0/io-webp.c2023-02-23 23:30:45.0 
> +0100
> +++ webp-pixbuf-loader-0.2.1/io-webp.c2023-03-04 00:36:54.0 
> +0100
> @@ -12,6 +12,7 @@
>  
>  #include "io-webp.h"
>  #include "io-webp-anim.h"
> +#include 
>  
>  static gpointer
>  begin_load (GdkPixbufModuleSizeFunc size_func,
> @@ -192,7 +193,7 @@
>  write_file (const uint8_t *data, size_t data_size, const WebPPicture *const 
> pic)
>  {
>FILE *const out = (FILE *) pic->custom_ptr;
> -  return data_size ? (fwrite (data, data_size, 1, out) == 1) : 1;
> +  return data_size == fwrite (data, sizeof (guchar), data_size, out) ? TRUE 
> : FALSE;
>  }
>  
>  /* Encoder write callback to accumulate output data in a GByteArray */
> @@ -207,7 +208,7 @@
>  static gboolean
>  is_save_option_supported (const gchar *option_key)
>  {
> -  char *options[3] = { "quality", "preset", NULL };
> +  char 

Bug#1033856: unblock: mpv/0.35.1-2

[Sebastian Ramacher]

On 2023-04-05 21:57:55 +0200, Sebastian Ramacher wrote:
> On 2023-04-05 19:11:25 +0200, Paul Gevers wrote:
> > Control: tags -1 moreinfo
> > 
> > Hi Sebastian,
> > 
> > On 02-04-2023 22:06, Sebastian Ramacher wrote:
> > >[x] attach debdiff against the package in testing
> > 
> > The debdiff that I get with $(d) contains two new patches that are not part
> > of d/p/series and were not part of your debdiff (they look like copies of
> > existing patches with a different number. Was that intentional?
> 
> That was a mistake - I failed to call gbp pq export with the right
> flags. I'll upload a new version cleaning that up.

Uploaded -3 and here's the new debdiff.

Cheeers
-- 
Sebastian Ramacher
diff -Nru mpv-0.35.1/debian/changelog mpv-0.35.1/debian/changelog
--- mpv-0.35.1/debian/changelog 2023-01-29 20:55:34.0 +0100
+++ mpv-0.35.1/debian/changelog 2023-04-06 08:25:35.0 +0200
@@ -1,3 +1,16 @@
+mpv (0.35.1-3) unstable; urgency=medium
+
+  * debian/patches: Remove duplicate patches
+
+ -- Sebastian Ramacher   Thu, 06 Apr 2023 08:25:35 +0200
+
+mpv (0.35.1-2) unstable; urgency=medium
+
+  * debian/patches: Apply upstream patches for yt-dlp 2023.03.04 compatibility
+(Closes: #1033595, #1033609)
+
+ -- Sebastian Ramacher   Fri, 31 Mar 2023 20:46:51 +0200
+
 mpv (0.35.1-1) unstable; urgency=medium
 
   * New upstream version 0.35.1
diff -Nru 
mpv-0.35.1/debian/patches/0003-ytdl_hook-init-fragment-requires-other-fragments.patch
 
mpv-0.35.1/debian/patches/0003-ytdl_hook-init-fragment-requires-other-fragments.patch
--- 
mpv-0.35.1/debian/patches/0003-ytdl_hook-init-fragment-requires-other-fragments.patch
   1970-01-01 01:00:00.0 +0100
+++ 
mpv-0.35.1/debian/patches/0003-ytdl_hook-init-fragment-requires-other-fragments.patch
   2023-03-31 20:46:45.0 +0200
@@ -0,0 +1,25 @@
+From: Christoph Heinrich 
+Date: Fri, 3 Mar 2023 00:45:45 +0100
+Subject: ytdl_hook: init fragment requires other fragments
+
+With dash the first fragment was always considered an init fragment if
+there wasn't a duration. However that only makes sense when there are
+also other fragments, so check if there are other fragments in addition
+to the lack of a duration.
+---
+ player/lua/ytdl_hook.lua | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/player/lua/ytdl_hook.lua b/player/lua/ytdl_hook.lua
+index f40579a..faaff8c 100644
+--- a/player/lua/ytdl_hook.lua
 b/player/lua/ytdl_hook.lua
+@@ -295,7 +295,7 @@ local function edl_track_joined(fragments, protocol, 
is_live, base)
+ local args = ""
+ 
+ -- assume MP4 DASH initialization segment
+-if not fragments[1].duration then
++if not fragments[1].duration and #fragments > 1 then
+ msg.debug("Using init segment")
+ args = args .. ",init=" .. edl_escape(join_url(base, 
fragments[1]))
+ offset = 2
diff -Nru 
mpv-0.35.1/debian/patches/0004-ytdl_hook-only-log-error-when-no-fallback-url-availa.patch
 
mpv-0.35.1/debian/patches/0004-ytdl_hook-only-log-error-when-no-fallback-url-availa.patch
--- 
mpv-0.35.1/debian/patches/0004-ytdl_hook-only-log-error-when-no-fallback-url-availa.patch
   1970-01-01 01:00:00.0 +0100
+++ 
mpv-0.35.1/debian/patches/0004-ytdl_hook-only-log-error-when-no-fallback-url-availa.patch
   2023-03-31 20:46:45.0 +0200
@@ -0,0 +1,36 @@
+From: Christoph Heinrich 
+Date: Fri, 3 Mar 2023 00:50:58 +0100
+Subject: ytdl_hook: only log error when no fallback url available
+
+An error indicates that something doesn't work, but as long as a
+safe url is available, playback is still expected to work.
+
+Thus reduce logging level of MP4 DASH without fragments message and
+add a new error message for when there is no safe url available either.
+
+Also adds a missing space.
+---
+ player/lua/ytdl_hook.lua | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/player/lua/ytdl_hook.lua b/player/lua/ytdl_hook.lua
+index faaff8c..362f433 100644
+--- a/player/lua/ytdl_hook.lua
 b/player/lua/ytdl_hook.lua
+@@ -307,7 +307,7 @@ local function edl_track_joined(fragments, protocol, 
is_live, base)
+ -- if not available in all, give up.
+ for i = offset, #fragments do
+ if not fragments[i].duration then
+-msg.error("EDL doesn't support fragments" ..
++msg.verbose("EDL doesn't support fragments " ..
+  "without duration with MP4 DASH")
+ return nil
+ end
+@@ -421,6 +421,7 @@ local function formats_to_edl(json, formats, 
use_all_formats)
+ track.protocol, json.is_live,
+ track.fragment_base_url)
+ if not edl_track and not url_is_safe(track.url) then
++msg.error("No safe URL or supported fragmented stream available")
+ return nil
+ end
+ 
diff -Nru mpv-0.35.1/debian/patches/series mpv-0.35.1/debian/patches/series
--- mpv-0.35.1/debian/patches/series2023-01-29 

Bug#1033998: protobof: FTBFS on 32 bit arches: error: static assertion failed

[Sebastian Ramacher]

Source: protobuf
Version: 3.21.12-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org, hel...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=protobuf=i386=3.21.12-2=1680729111=0

g++ -DHAVE_CONFIG_H -I. -I..  -I./../third_party/googletest/googletest/include 
-I./../third_party/googletest/googlemock/include -Wdate-time 
-D_FORTIFY_SOURCE=2 -pthread -DHAVE_PTHREAD=1 -DHAVE_ZLIB=1 -Wall 
-Wno-sign-compare -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o 
google/protobuf/protobuf_test-extension_set_unittest.o `test -f 
'google/protobuf/extension_set_unittest.cc' || echo 
'./'`google/protobuf/extension_set_unittest.cc
In file included from ./google/protobuf/implicit_weak_message.h:39,
 from ./google/protobuf/generated_message_util.h:54,
 from ./google/protobuf/generated_message_bases.h:40,
 from ./google/protobuf/unittest.pb.h:26,
 from google/protobuf/extension_set_unittest.cc:39:
./google/protobuf/repeated_field.h: In instantiation of ‘constexpr int 
google::protobuf::internal::RepeatedFieldLowerClampLimit() [with T = long long 
int; int kRepHeaderSize = 4]’:
google/protobuf/extension_set_unittest.cc:871:3:   required from here
./google/protobuf/repeated_field.h:81:27: error: static assertion failed
   81 |   static_assert(sizeof(T) <= kRepHeaderSize, "");
  | ~~^
./google/protobuf/repeated_field.h:81:27: note: the comparison reduces to ‘(8 
<= 4)’
./google/protobuf/repeated_field.h: In instantiation of ‘constexpr int 
google::protobuf::internal::RepeatedFieldLowerClampLimit() [with T = long long 
unsigned int; int kRepHeaderSize = 4]’:
google/protobuf/extension_set_unittest.cc:873:3:   required from here
./google/protobuf/repeated_field.h:81:27: error: static assertion failed
./google/protobuf/repeated_field.h:81:27: note: the comparison reduces to ‘(8 
<= 4)’
./google/protobuf/repeated_field.h: In instantiation of ‘constexpr int 
google::protobuf::internal::RepeatedFieldLowerClampLimit() [with T = double; 
int kRepHeaderSize = 4]’:
google/protobuf/extension_set_unittest.cc:881:3:   required from here
./google/protobuf/repeated_field.h:81:27: error: static assertion failed
./google/protobuf/repeated_field.h:81:27: note: the comparison reduces to ‘(8 
<= 4)’
make[4]: *** [Makefile:6691: 
google/protobuf/protobuf_test-extension_set_unittest.o] Error 1

While I can understand the motivation behind #103398, please test such
changes during the freeze in experimental first.

Cheers
-- 
Sebastian Ramacher