Bug#1011234: fakeroot doesn't correctly detect copied device nodes on ia64

[Mattias Ellert]

Control: tag 1011234 +patch

The attached patch fixes the issue:

Mattias

diff -ur fakeroot-1.28.orig/libfakeroot.c fakeroot-1.28/libfakeroot.c
--- fakeroot-1.28.orig/libfakeroot.c	2022-03-04 14:21:41.0 +
+++ fakeroot-1.28/libfakeroot.c	2022-05-20 04:57:29.491263557 +
@@ -99,6 +99,8 @@
  #if defined __linux__
   #if defined (__aarch64__)
#define _STAT_VER 0
+  #elif defined (__ia64__)
+   #define _STAT_VER 1
   #elif defined (__powerpc__) && __WORDSIZE == 64
#define _STAT_VER 1
   #elif defined (__riscv) && __riscv_xlen==64


smime.p7s
Description: S/MIME cryptographic signature

Bug#1004421: ITS: cadaver

[Arnaud Rebillout]

CC Sebastian Harl in case it helps

Sebastian are you Ok if I take over this package and maintain it within 
pkg-security-team?


Cheers

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1011324: qr-tools: trivial suggestions simplifying the Debian packaging

[Nicolas Boulenguez]

Source: qr-tools
Severity: wishlist
Tags: patch

Hello.
The attached commits arguably improve the Debian packaging,
without changing the binary packages as far as I know.
Please apply the ones you find relevant.
Thanks.
>From 4d854152b72c73a2b51444e2f03e733cce7a35bd Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 19 May 2022 16:10:56 +0200
Subject: [PATCH 1/5] Replace get-orig-source with Files-Excluded

The Debian policy recommends to replace the get-orig-source target in
debian/rules with a debian/watch file when possible.  The
Files-Excluded field in debian/copyright now allows uscan to fully
replace a hand-written target.
---
 debian/copyright |  1 +
 debian/rules | 16 
 2 files changed, 1 insertion(+), 16 deletions(-)

diff --git a/debian/copyright b/debian/copyright
index a43fbe6..4439bbf 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,6 +1,7 @@
 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: qr-tools
 Source: https://launchpad.net/qr-tools
+Files-Excluded: *.old *.qm
 
 Files: *
 Copyright: 2011 David Green 
diff --git a/debian/rules b/debian/rules
index a00d717..ad434a4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,19 +17,3 @@ execute_after_dh_auto_clean:
 	echo $(DEB_VERSION_UPSTREAM)
 	rm -rf $(CURDIR)/build
 	find -name "*.qm" | xargs rm -f
-
-PACKAGE = qr-tools
-
-BZR_REVISION := $(shell echo $(DEB_VERSION_UPSTREAM) | awk -F"~" '{ print $$2 }' | sed 's/bzr//' )
-TARBALL = $(PACKAGE)_$(DEB_VERSION_UPSTREAM).orig.tar
-.PHONY: get-orig-source
-get-orig-source:
-	echo $(DEB_VERSION_UPSTREAM)
-	bzr export $(CURDIR)/$(TARBALL) -r $(BZR_REVISION) "lp:qr-tools"
-	tar xf $(CURDIR)/$(TARBALL)
-	find $(PACKAGE)_$(DEB_VERSION_UPSTREAM).orig -name "*.qm" | xargs rm -f
-	find $(PACKAGE)_$(DEB_VERSION_UPSTREAM).orig -name "*.old" | xargs rm -f
-	tar cf  $(CURDIR)/$(TARBALL) $(PACKAGE)_$(DEB_VERSION_UPSTREAM).orig
-	xz -9 $(CURDIR)/$(TARBALL)
-	rm -rf $(PACKAGE)_$(DEB_VERSION_UPSTREAM).orig
-	echo "  "$(TARBALL).xz" created; move it to the right destination to build the package"
-- 
2.30.2

>From c1788d799f7495070354198d8fcc9a0e29ab80cc Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 19 May 2022 16:13:54 +0200
Subject: [PATCH 2/5] debian/rules: replace override_dh_clean with debian/clean

A separate debian/clean file seems consistent with qtqr.dirs.
---
 debian/clean | 2 ++
 debian/rules | 6 --
 2 files changed, 2 insertions(+), 6 deletions(-)
 create mode 100644 debian/clean

diff --git a/debian/clean b/debian/clean
new file mode 100644
index 000..7045335
--- /dev/null
+++ b/debian/clean
@@ -0,0 +1,2 @@
+build/
+*.qm
diff --git a/debian/rules b/debian/rules
index ad434a4..2925b96 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,6 @@
 #!/usr/bin/make -f
 
 export QT_SELECT := 5
-include /usr/share/dpkg/pkg-info.mk
 
 %:
 	dh $@ --buildsystem=pybuild
@@ -12,8 +11,3 @@ execute_after_dh_auto_build:
 execute_after_dh_auto_install:
 	install -m 644 $(CURDIR)/qtqr.py $(CURDIR)/debian/qtqr/usr/bin/qtqr
 	install -m 644 $(CURDIR)/icon.png $(CURDIR)/debian/qtqr/usr/share/pixmaps/qtqr.png
-
-execute_after_dh_auto_clean:
-	echo $(DEB_VERSION_UPSTREAM)
-	rm -rf $(CURDIR)/build
-	find -name "*.qm" | xargs rm -f
-- 
2.30.2

>From 918bbe8a0b42207d57c7b70201344c7a2ee87f6a Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 19 May 2022 16:20:19 +0200
Subject: [PATCH 3/5] Update copyright years for the packaging

---
 debian/copyright | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/debian/copyright b/debian/copyright
index 4439bbf..c724391 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -8,8 +8,9 @@ Copyright: 2011 David Green 
 License: GPL-3+
 
 Files: debian/*
-Copyright: 2012 Koichi Akabe 
-   2017 Boyuan Yang <073p...@gmail.com>
+Copyright: 2022  Georges Khaznadar 
+   2012-2014 Koichi Akabe 
+   2017-2021 Boyuan Yang <073p...@gmail.com>
2019 Gianfranco Costamagna 
 License: GPL-3+
 
-- 
2.30.2

>From edb05c34672c8f9127f3365095599f41c13af5c8 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 19 May 2022 16:21:24 +0200
Subject: [PATCH 4/5] debian/rules: prefer Make loops over shell loops

so that each executed command is visible in logs.
---
 debian/rules | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index 2925b96..e906aad 100755
--- a/debian/rules
+++ b/debian/rules
@@ -5,8 +5,11 @@ export QT_SELECT := 5
 %:
 	dh $@ --buildsystem=pybuild
 
-execute_after_dh_auto_build:
-	(for i in $(CURDIR)/qtqr_*.ts; do lrelease -nounfinished $$i -qm $$(echo $$i | sed -e 's/ts$$/qm/g'); done)
+ts = $(wildcard qtqr_*.ts)
+qm = $(ts:ts=qm)
+execute_after_dh_auto_build: $(qm)
+$(qm): %.qm: %.ts
+	lrelease -nounfinished $< -qm $@
 
 execute_after_dh_auto_install:
 	install -m 644 $(CURDIR)/qtqr.py $(CURDIR)/debian/qtqr/usr/bin/qtqr
-- 
2.30.2

>From 

Bug#1011323: lablgtk2: Please remove the obsolete gtkgl/glarea component

[Nicolas Boulenguez]

Source: lablgtk2
Severity: minor
Tags: patch
X-Debbugs-Cc: 967...@bugs.debian.org

Hello.
No package depends on liblablgtk2-gl-ocaml, and it is the last package
depending on libgtkgl2, which should be removed from Debian (#967808).
Please consider removing it.

Bug#1011322: waypipe: ftbfs on riscv64 (Timeout: 2)

[Bo YU]

Package: waypipe
Version: 0.8.2-3
Severity: normal
Tags: ftbfs, patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Dear Maintainer,

The waypipe package has a ftbfs issue on riscv64 arch:

```
Summary of Failures:

7/8 How well buffers are replicatedTIMEOUT40.09s   
killed by signal 15 SIGTERM
8/8 Whether diff operations successfully roundtrip TIMEOUT60.12s   
killed by signal 15 SIGTERM


Ok: 6   
Expected Fail:  0   
Fail:   0   
Unexpected Pass:0   
Skipped:0   
Timeout:2   
dh_auto_test: error: cd obj-riscv64-linux-gnu && LC_ALL=C.UTF-8 
MESON_TESTTHREADS=4 meson test returned exit code 2
make: *** [debian/rules:8: binary-arch] Error 25
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

```
The full buildd log is here:

https://buildd.debian.org/status/fetch.php?pkg=waypipe=riscv64=0.8.2-3=1650239386=0

The attached patch is simple to disable tests like mips do that.

If you need me to do more test, please let me know.

BR,
Bo
diff -Nru waypipe-0.8.2/debian/rules waypipe-0.8.2/debian/rules
--- waypipe-0.8.2/debian/rules  2021-12-01 15:39:26.0 +
+++ waypipe-0.8.2/debian/rules  2021-12-01 15:39:26.0 +
@@ -16,7 +16,7 @@
dh_auto_configure -- -Dwith_avx2=false -Dwith_avx512f=false 
-Dwith_neon_opts=false -Dwith_sse3=false
 endif
 
-ifneq (, $(filter $(DEB_HOST_ARCH),mipsel mips64el))
+ifneq (, $(filter $(DEB_HOST_ARCH),mipsel mips64el riscv64))
 override_dh_auto_test:
@echo "Skipping tests on $(DEB_HOST_ARCH)."
 endif

Bug#1011166: [Debian-on-mobile-maintainers] Bug#1011166: pidgin breaks chatty autopkgtest: error while loading shared libraries: libjabber.so.0

[Richard Laager]

On 5/19/22 04:04, Evangelos Ribeiro Tzaras wrote:

Thanks for the patch! I'll upload a fixed version soon.


If you upload a new version, you (or I) can then close the binNMU 
request, bug #1011201.


--
Richard


OpenPGP_signature
Description: OpenPGP digital signature

Bug#516285: y/n prompts

[Matt Barry]

tags #516285 patch
thanks

I've created a small patch that may address this issue; merge request
available here:

https://salsa.debian.org/debian/adduser/-/merge_requests/18

Cheers,
Matt


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

Bug#695188: Pong

[Matt Barry]

This bug is almost ten years old; a patch was added almost five years
ago.


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

Bug#1007022: podman: starting rootless container fails with: can't get final child's PID from pipe: EOF

[Arnaud Rebillout]

I can reproduce it locally.

For background: I just setup a new machine, and I installed both 
docker.io and podman. Since docker.io depends on runc, and podman 
depends on crun|runc, only runc was installed.


The issue is fixed after installing crun manually (note that both runc 
and crun can be installed on the system, it doesn't seem to cause any 
issue).


Cheers,

Arnaud

Bug#1011321: ITP: flask-jwt-extended -- Flask extension that provides JWT support

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org, 
j...@nahmias.net, lily.gilb...@hey.com

* Package name: flask-jwt-extended
  Version : 4.4.0
  Upstream Author : Lily Acadia Gilbert 
* URL : https://github.com/vimalloc/flask-jwt-extended
* License : Expat
  Programming Lang: Python
  Description : Flask extension that provides JWT support

 Flask-JWT-Extended not only adds support for using JSON Web Tokens (JWT) to
 Flask for protecting routes, but also many helpful (and optional) features
 built in to make working with JSON Web Tokens easier. These include:
 .
  * Adding custom claims to JSON Web Tokens
  * Automatic user loading (current_user).
  * Custom claims validation on received tokens
  * Refresh tokens
  * First class support for fresh tokens for making sensitive changes.
  * Token revoking/blocklisting
  * Storing tokens in cookies and CSRF protection


Needed as a dependency of Flask-AppBuilder.
I plan to maintain this as part of the Debian Python Team (DPT).

Bug#1011320: ITP: luajit2 -- OpenResty's Branch of LuaJIT 2

[M. Zhou]

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

* Package name: luajit2
* URL : https://github.com/openresty/luajit2
* License : MIT/X
  Description : OpenResty's Branch of LuaJIT 2

I'm going to remove ppc64el support from src:luajit,
let's see if this derivative works for IBM architectures
based on suggestions.

Bug#1004511: luajit SEGFAULTS on ppc64el

[M. Zhou]

Hi Paul,

> Not convinced I'm totally right there's no key packages in the list 
> above, but let's go this route unless somebody puts up the effort to 
> *maintain* the ppc64el parts.

Based on the discussion on -devel, it seems that it's impossible
to keep maintaining the ppc64el support for src:luajit. I plan to
remove the architecture.

OpenSUSE's effort has been mentioned, but according to their OBS
changelog, they could do nothing but leave a broken ppc64el package
as well.

Luajit2 (src:luajit2) as a new package maybe able to bring luajit
back to ppc64el / s390x. May give it a try in the future.

Bug#1011318: fp terminal ide does not compile hello world

[Steve Greenburg]

Package: fp-ide
Version: 3.2.2

When I run 'fp' without arguments from the package fp-ide (free pascal 
compiler) I get the borland-style IDE terminal. Then I type in the following 
hello world program, save as hello.pas, then hit alt-F9 to compile. However I 
get an error that a unit (the pascal term for a library?) is not available, 
rather than it compiling the file.

begin   
  
   writeln('hello world');  
  
end.

(1,1) Fatal: Can't find unit system used by Program 
 ▲
(0) Fatal: Compilation aborted 

(Note the period after the 'end' keyword.) However the unit files are 
available. In fact if I add the following line to the 
Options->Directories->Unit Directories submenu then the compilation succeeds 
(fp creates a temporary cfg file in the current directory with the new path):
/usr/lib/x86_64-linux-gnu/fpc/3.2.2/units/x86_64-linux/*

The config file is /etc/fpc.cfg and it mentions the above path but with 
symbols. For example it has '$fpcversion' instead of '3.2.2'. Strangely the 
'fpc' compiler itself uses this file but has no problems. I have tested this on 
latest debian testing. I'm not sure how to fix the problem in fp itself however 
other than through the GUI or why it's not using the fpc.cfg file properly.

-Steve

Bug#1001776: yt-dlp: further improve 0002-Disable-upstream-s-autoupdate-mechanism.patch

[Unit 193]

Howdy,

On closer review, this patch isn't actually needed at all since 2012[0][1], so 
I'm not really sure why it's there in the first place.


The output now without the patch (and not updating to the latest) is:

Latest version: 2022.05.18, Current version: 2022.04.08
ERROR: It looks like you installed yt-dlp with a package manager, pip or 
setup.py; Use that to update

Which seems more useful than the current text anyway, as it tells you the latest 
version.  One could argue that it "phones home", but with -U you already to do 
just that anyway.


I may just drop the patch instead.


[0]: 
https://github.com/ytdl-org/youtube-dl/commit/cb6ff87fbb05e421f77b57a79699c647866ceb09#diff-fce3fb374a1c20a703ac379c9a2f3c39ee0fe8d155d8c05a07b6b41450215869
[1]: 
https://github.com/ytdl-org/youtube-dl/commit/f9bd64c09897ebbd3a3278fe21e7ae798c6fc140

~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#1011317: dkms: spurious messages "Module build for kernel ... was skipped" for non-installed kernels

[Vincent Lefevre]

Package: dkms
Version: 3.0.3-1
Severity: minor

I got the following during an upgrade of the nvidia packages:

Building for 5.14.0-1-amd64, 5.14.0-2-amd64, 5.14.0-3-amd64, 5.14.0-4-amd64, 
5.15.0-1-amd64, 5.15.0-3-amd64, 5.16.0-1-amd64, 5.16.0-2-amd64, 5.16.0-3-amd64, 
5.16.0-4-amd64, 5.17.0-1-amd64 and 5.17.0-2-amd64
Module build for kernel 5.14.0-1-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
Module build for kernel 5.14.0-2-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
Module build for kernel 5.14.0-3-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
Module build for kernel 5.14.0-4-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
Module build for kernel 5.15.0-1-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
Module build for kernel 5.15.0-3-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
Module build for kernel 5.16.0-1-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
Module build for kernel 5.16.0-2-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
Module build for kernel 5.16.0-3-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.
Module build for kernel 5.16.0-4-amd64 was skipped since the
kernel headers for this kernel does not seem to be installed.

but the only installed kernels are 5.17.0-1-amd64 and 5.17.0-2-amd64
(note that I'm talking about the kernel images, not the kernel headers).
The other kernels had been installed in the past, but I removed them
(I keep 2 kernels only).

The dkms(8) man page says:

  $autoinstall_all_kernels
  used by the common postinst for DKMS modules. It controls if the
  build should be done for all installed kernels or only  for  the
   ^
  current  and  latest  installed  kernel.  It has no command line
  equivalent.

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

Kernel: Linux 5.17.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.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 dkms depends on:
ii  build-essential 12.9
ii  clang-10 [c-compiler]   1:10.0.1-8+b1
ii  clang-11 [c-compiler]   1:11.1.0-6+b2
ii  clang-12 [c-compiler]   1:12.0.1-20+b1
ii  clang-13 [c-compiler]   1:13.0.1-4
ii  clang-3.5 [c-compiler]  1:3.5.2-5
ii  clang-3.6 [c-compiler]  1:3.6.2-4
ii  clang-3.7 [c-compiler]  1:3.7.1-3+b2
ii  clang-7 [c-compiler]1:7.0.1-12
ii  clang-8 [c-compiler]1:8.0.1-10+b1
ii  clang-9 [c-compiler]1:9.0.1-20+b1
ii  coreutils   8.32-4.1
ii  dctrl-tools 2.24-3+b1
ii  dpkg-dev1.21.7
ii  gcc [c-compiler]4:11.2.0-2
ii  gcc-10 [c-compiler] 10.3.0-15
ii  gcc-11 [c-compiler] 11.3.0-3
ii  gcc-12 [c-compiler] 12.1.0-2
ii  gcc-4.6 [c-compiler]4.6.4-7
ii  gcc-4.8 [c-compiler]4.8.5-4
ii  gcc-4.9 [c-compiler]4.9.4-2
ii  gcc-5 [c-compiler]  5.5.0-12
ii  gcc-6 [c-compiler]  6.5.0-2
ii  gcc-8 [c-compiler]  8.4.0-7
ii  gcc-9 [c-compiler]  9.4.0-5
ii  kmod29-1
ii  lsb-release 11.1.0
ii  make4.3-4.1
ii  patch   2.7.6-7
ii  tcc [c-compiler]0.9.27+git20200814.62c30a4a-1

Versions of packages dkms recommends:
ii  fakeroot 1.28-1
ii  linux-headers-amd64 [linux-headers-generic]  5.17.6-1
ii  sudo 1.9.10-3

Versions of packages dkms suggests:
ii  e2fsprogs  1.46.5-2
ii  menu   2.1.49

-- Configuration Files:
/etc/dkms/framework.conf changed:
verbose="1"
autoinstall_all_kernels="1"


-- no debconf information

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

Bug#1001776: yt-dlp: further improve 0002-Disable-upstream-s-autoupdate-mechanism.patch

[Unit 193]

Howdy,

Might be useful to note that this was never sent to me, the BTS doesn't actually 
send replies by default.



On Fri, 31 Dec 2021 20:18:14 +0100, Christoph Anton Mitterer wrote:


Hey Uni 193.

First, thanks for maintaining this.

Are you going to do that in https://salsa.debian.org/debian/yt-dlp ?


No.  As the Vcs-* show, I don't have this on salsa.debian.org.


I'd have written an update to 0002-Disable-upstream-s-autoupdate-
mechanism.patch, which completely removes the run_update and
update_self functions... (better not have it in the code at all, so it
cannot be "accidentally" called by some other place in the code).


Bit hard to review a patch I can't see, but functionally how will this change 
things?  So far it sounds like it just enlarges it (thus increasing the 
likelihood of conflicts) without much of a benefit.


If you wanted to adapt the patch, dropping the current __init__.py changes and 
then only modify run_update to exit with the message (or one like it) that's in 
parser.error now, that would seem to be about equal to the current changes but 
fulfill your desire to neuter run_update completely.



~Unit 193
Unit193 @ Libera
Unit193 @ OFTC

Bug#1011292: openssh-client: scp -O should be doable with a configuration file entry (in ~/.ssh/config)

[Colin Watson]

On Thu, May 19, 2022 at 07:28:38PM +0200, Raphaël Hertzog wrote:
> dput and dput-ng are using "scp" and don't offer any simple way to
> configure command line parameters and the switch to "sftp-behind-the-back"
> broke dput for me with some targets (cf #1011063).
> 
> I would have liked to be able to add something like this in ~/.ssh/config:
> 
> Host deb.freexian.com
> UseLegacyScp true
> 
> And be done with it. But there's no such option. It would be nice if
> upstream could implement this.

It would be best if you could forward this upstream yourself
(https://bugzilla.mindrot.org/), since that way you can advocate for it
directly.

Thanks,

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#1010202: MatIO test failures against HDF5 1.12.0

[Gilles Filippini]

Hi,

Thomas Beutlich a écrit le 19/05/2022 à 22:36 :

Hi Sébastien,

seems I was right (and somehow remembered correctly) with my guess of 
some concurrency issue when running the testsuite. For my own test setup 
I chose to go with serial execution of the testsuite (if matio is built 
with libhdf5 support).


Best regards,
Thomas

Am 19.05.2022 um 10:06 schrieb Sébastien Villemot:

Hi Thomas,

It turns out that running the testsuite sequentially fixes the problem,
as explained by Gilles Filippini (who maintains HDF5 in Debian), see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010202#25

Where do we go from here? We now have a workaround, but that’s hardly
satisfactory.

If possible, please reply by
putting p...@debian.org and 1010...@bugs.debian.org in CC, so that this
it is properly tracked in our system.

Best regards,

Le mardi 03 mai 2022 à 20:59 +0200, Thomas Beutlich a écrit :

Hi Sébastien,
it is the same test case that fails for three different HDF5-based
MAT files. My guess is some concurrency issue of the hdf5lib. Can you
please try:
* to run the testsuite sequentially
  * to not build libhdf with --enable-parallel, i.e. to have the
serial version of hdf5lib
  * set env var HDF5_USE_FILE_LOCKING=FALSE


Setting the above environment variable fixes the problem when running 
the testsuite in parallel mode.


Best,

_g.

Bug#1011314: Does not include an autopkgtest

[Sebastien Bacher]

Package: libldac
Version: 2.0.2.3+git20200429+ed310a0-4

It would be nicer if the package had autopkgtests testing. The attached 
patch is adding a trivial build test on the model of the ones used for 
most GNOME libraries, it ensure that a simple case builds and that the 
dev isn't missing any depends. We are using that change in Ubuntu now as 
having tests is a requirement for supported packages and libldac is a 
pipewrire depends.


Thanks for considering

diff -Nru libldac-2.0.2.3+git20200429+ed310a0/debian/changelog libldac-2.0.2.3+git20200429+ed310a0/debian/changelog
--- libldac-2.0.2.3+git20200429+ed310a0/debian/changelog	2020-07-16 19:03:09.0 +0200
+++ libldac-2.0.2.3+git20200429+ed310a0/debian/changelog	2022-05-19 15:50:16.0 +0200
@@ -1,3 +1,9 @@
+libldac (2.0.2.3+git20200429+ed310a0-5) unstable; urgency=medium
+
+  * debian/tests: add a basic build autopkgtest for the library
+
+ -- Sebastien Bacher   Thu, 19 May 2022 15:50:16 +0200
+
 libldac (2.0.2.3+git20200429+ed310a0-4) unstable; urgency=medium
 
   * Rebuild with no source changes.
diff -Nru libldac-2.0.2.3+git20200429+ed310a0/debian/tests/build libldac-2.0.2.3+git20200429+ed310a0/debian/tests/build
--- libldac-2.0.2.3+git20200429+ed310a0/debian/tests/build	1970-01-01 01:00:00.0 +0100
+++ libldac-2.0.2.3+git20200429+ed310a0/debian/tests/build	2022-05-19 15:45:50.0 +0200
@@ -0,0 +1,35 @@
+#!/bin/sh
+# autopkgtest check: Build and run a program against libldac, to verify that
+# the headers and pkg-config file are installed correctly
+
+set -e
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
+cat < libldac_test.c
+#include 
+#include 
+#include 
+
+int main(void)
+{
+	HANDLE_LDAC_BT ldac;
+
+	assert(ldacBT_get_handle());
+
+	return 0;
+}
+EOF
+
+# deliberately word-splitting pkg-config output:
+# shellcheck disable=SC2046
+"${CROSS_COMPILE}gcc" -o libldac_test libldac_test.c \
+$("${CROSS_COMPILE}pkg-config" --cflags --libs ldacBT-enc)
+echo "build: OK"
+[ -x libldac_test ]
+./libldac_test
+echo "run: OK"
diff -Nru libldac-2.0.2.3+git20200429+ed310a0/debian/tests/control libldac-2.0.2.3+git20200429+ed310a0/debian/tests/control
--- libldac-2.0.2.3+git20200429+ed310a0/debian/tests/control	1970-01-01 01:00:00.0 +0100
+++ libldac-2.0.2.3+git20200429+ed310a0/debian/tests/control	2022-05-19 15:41:13.0 +0200
@@ -0,0 +1,3 @@
+Tests: build
+Depends: build-essential, pkg-config, libldacbt-enc-dev
+Restrictions: allow-stderr superficial

Bug#1011313: RFS: python-decouple/3.6-3 -- Helps you to organize your Django/Flask settings

[Matt Barry]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-decouple":

 * Package name: python-decouple
   Version : 3.6-3
   Upstream Author : Henrique Bastos 
 * URL : https://github.com/henriquebastos/python-decouple
 * License : MIT
 * Vcs : https://salsa.debian.org/debian/python-decouple
   Section : python

The source builds the following binary packages:

  python3-decouple - Helps you to organize your Django/Flask settings

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

  https://mentors.debian.net/package/python-decouple/

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

  dget -x
https://mentors.debian.net/debian/pool/main/p/python-decouple/python-decouple_3.6-3.dsc

Or, the git repository (forked from the main branch):

  https://salsa.debian.org/zaharazod/python-decouple.git

Changes since the last upload:

 python-decouple (3.6-3) unstable; urgency=medium
 .
   * copyright fixes
   * lintian fixes
   * new upstream version (3.6)

Regards,
-- 
  Matt Barry

Bug#980957: llvm-toolchain-11 autopkgtest segfaults on armhf

[Adrian Bunk]

Control: clone -1 -2
Control: reassign -2  src:llvm-toolchain-14
Control: retitle -2 llvm-toolchain-14 autopkgtest segfaults on armhf
Control: notforwarded -2
Control: severity -2 serious
Control: block 1009923 by -1

On Tue, Sep 21, 2021 at 04:28:12PM -0400, Nicholas D Steeves wrote:
> Hi Gianfranco,
> 
> On Sun, Mar 28, 2021 at 09:11:49PM +0200, Gianfranco Costamagna wrote:
> > control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=27659
> > control: affects -1 src:binutils
> > 
> > Invoking the clang with -V shows a failure in ld.bdf linker, a failure that 
> > doesn't happen with gold linker and with object files (crt*.o) copied on 
> > local directory.
> > 
> > I opened a bug against binutils people to track it down, hopefully they can 
> > sort what is segfaulting there.
> > 
> 
> Does the following upstream reverted commit unblock this bug, thus
> unblocking llvm-toolchain-12 from migrating to testing?
> 
>   https://sourceware.org/bugzilla/show_bug.cgi?id=27659#c17

It is now included in the binutils in unstable, and does not appear to 
have fixed it.

This issue is also present in llvm-toolchain-14, and currently blocking 
testing migration there:
https://ci.debian.net/packages/l/llvm-toolchain-14/unstable/armhf/

> Regards,
> Nicholas

cu
Adrian

Bug#1011311: RFS: colordiff/1.0.20-1 -- tool to colorize 'diff' output

[Dave Ewart]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: colordiff
   Version : 1.0.20-1
   Upstream Author : Dave Ewart da...@sungate.co.uk
 * URL : http://www.colordiff.org/
 * License : GPL-2+
 * Vcs : https://github.com/daveewart/colordiff
   Section : text

The source builds the following binary packages:

  colordiff - tool to colorize 'diff' output

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/colordiff/colordiff_1.0.20-1.dsc

Changes since the last upload:

 colordiff (1.0.20-1) unstable; urgency=medium
 .
   * New upstream release.
   * Minor packaging tidying.
   * Updates standards version to 4.6.0, added Rules-Require-Root.

Background: I've been developing 'colordiff' for more than 20 years, but in the
Debian ecosystem I've never uploaded the packages myself.  Rather I've been
building the packages and various individuals have sponsored the uploads.
However my most recent sponsor Colin Tuckley (since 2007) is no longer able to
do so.


Regards,
-- 
Dave Ewart, da...@sungate.co.uk

Bug#1010998: simh: Upstream license change conflicts with DFSG

[Joan Touzet]

As an alternative, Bob Supnik's "classic" version continues to release - 
version 2.12-2 just released 25 April 2022 - and would be an excellent 
replacement. http://simh.trailing-edge.com/


Unfortunately, that version still must overcome the licensing issues 
outlined in Debian bug #824883.

Bug#1011204: autopkgtest: test_transient_apt_failure test-case regressed in Debian 11 or earlier

[Paul Gevers]

Hi Simon,

On 18-05-2022 11:26, Simon McVittie wrote:

autopkgtest: WARNING: Test dependencies are unsatisfiable - calling apt install 
on test deps directly for further data about failing dependencies in test logs


This debugging code has been added not too long ago in revision 
70cd342682742cfdf1229ee5a5ceb6193e36f2c4. Maybe that's the cause?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010669: Acknowledgement (Does not include an autopkgtest)

[Sebastien Bacher]

Updated version of the patch fixing the depends

Le 06/05/2022 à 15:21, Debian Bug Tracking System a écrit :

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1010669: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010669.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Nobuhiro Iwamatsu 

If you wish to submit further information on this problem, please
send it to 1010...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.
diff -Nru ell-0.50/debian/changelog ell-0.50/debian/changelog
--- ell-0.50/debian/changelog	2022-04-22 12:05:21.0 +0200
+++ ell-0.50/debian/changelog	2022-05-06 15:06:10.0 +0200
@@ -1,3 +1,9 @@
+ell (0.50-2) unstable; urgency=medium
+
+  * debian/tests: add a trivial build autopkgtest
+
+ -- Sebastien Bacher   Fri, 06 May 2022 15:06:10 +0200
+
 ell (0.50-1) unstable; urgency=medium
 
   [ upstream ]
diff -Nru ell-0.50/debian/tests/build ell-0.50/debian/tests/build
--- ell-0.50/debian/tests/build	1970-01-01 01:00:00.0 +0100
+++ ell-0.50/debian/tests/build	2022-05-06 14:43:27.0 +0200
@@ -0,0 +1,35 @@
+#!/bin/sh
+# Copyright 2020 Collabora Ltd.
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+set -eux
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
+cd "$AUTOPKGTEST_TMP"
+
+cat > trivial.c <
+
+int main(void)
+{
+	l_log_set_stderr();
+
+	if (!l_main_init())
+		return -1;
+		
+	l_info("Trivial");
+	return 0;
+}
+EOF
+
+# Deliberately word-splitting pkg-config's output:
+# shellcheck disable=SC2046
+"${CROSS_COMPILE}gcc" -otrivial trivial.c $("${CROSS_COMPILE}pkg-config" --cflags --libs ell)
+echo "build: OK"
+./trivial
+echo "run: OK"
diff -Nru ell-0.50/debian/tests/control ell-0.50/debian/tests/control
--- ell-0.50/debian/tests/control	1970-01-01 01:00:00.0 +0100
+++ ell-0.50/debian/tests/control	2022-05-06 14:20:35.0 +0200
@@ -0,0 +1,3 @@
+Tests: build
+Depends: libglib2.0-dev, build-essential, libell-dev
+Restrictions: allow-stderr, superficial

Bug#1011091: Systems with more than 4 memory slots not supported yet, not instantiating SPD

[Diederik de Haas]

Control: forwarded -1 
https://lore.kernel.org/linux-i2c/3837611652787...@vla1-3991b5027d7d.qloud-c.yandex.net/

On Thursday, 19 May 2022 18:45:04 CEST Diederik de Haas wrote:
> Control: forwarded -1 https://www.spinics.net/lists/linux-i2c/msg56885.html

Updated forwarded to lore.kernel.org address as that's better IMO.

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

Bug#1011070: sssd-ad-common: Binary linked against an old version of so

[Shane Frasier]

Hello,

I was able to get past this, and I think this bug can be closed.
Normally when I install packages from backports I use a command like
"apt-get install -t bullseye-backports freeipa-client", but in this
case there is no freeipa-client package in the main bullseye package
repo.  Therefore, I was able to run the command "apt-get install
freeipa-client" to install freeipa-client from backports but all
dependencies from the non-backports package repos where possible.

Thank you,
Shane Frasier

Bug#1009179: dkms: Upstream has removed mkdeb|mkdsc|mkbmdeb

[Antoine Beaupre]

Package: dkms
Version: 2.8.4-3
Followup-For: Bug #1009179

I'd like to also signal that I'm interested in keeping this
functionality around. I looked at the current dkms source and it's not
*that* complicatd. It's basically one (rather big, 100 lines) shell
function which does everything.

Also, it seems to me we should be able to get away with just
replicating mkdsc: once we have a source package, we can use our
normal tools to build the rest...

It looks like it's basically:

invoke_command "cp -ar '$DEBDIR/' '$temp_dir_debian'" "copying template"
invoke_command "cp -Lpr '$dkms_tree/$module/$module_version/source' 
'$temp_dir_debian/$module-$module_version'" "Copying source tree"
invoke_command "dpkg-buildpackage -S -us -uc 1>/dev/null" "Building source 
package" || \

Now obviously, maybe those templates are gone too so we'd need to keep
that up to date, but it seems that's somewhat feasible...

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

Kernel: Linux 5.10.0-14-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.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 dkms depends on:
ii  build-essential  12.9
ii  coreutils8.32-4+b1
ii  dctrl-tools  2.24-3+b1
ii  dpkg-dev 1.20.9
ii  gcc [c-compiler] 4:10.2.1-1
ii  gcc-10 [c-compiler]  10.2.1-6
ii  kmod 28-1
ii  lsb-release  11.1.0
ii  make 4.3-4.1
ii  patch2.7.6-7

Versions of packages dkms recommends:
ii  fakeroot 1.25.3-1.1
ii  linux-headers-amd64 [linux-headers-generic]  5.10.113-1
ii  sudo 1.9.5p2-3

Versions of packages dkms suggests:
ii  e2fsprogs  1.46.2-2
pn  menu   

-- debconf-show failed

Bug#1011249:

[Andreas Hasenack]

I created this PR:
https://salsa.debian.org/debian/cyrus-sasl2/-/merge_requests/11

Bug#1011014: libsdl2-dev: double-promotion warning when including SDL_rect.h indirectly

[Simon McVittie]

Control: tags -1 + fixed-upstream

On Sun, 15 May 2022 at 12:25:59 +0200, Manuel Bilderbeek wrote:
> Our application openMSX compiles against SDL2 (see the Debian package). As of
> the recent update of SDL2 in testing it generates many warnings during
> compilation, in an SDL2 header file... for instance:
> 
> /usr/include/SDL2/SDL_rect.h: In function ‘SDL_bool 
> SDL_FRectEqualsEpsilon(const SDL_FRect*, const SDL_FRect*, float)’:
> /usr/include/SDL2/SDL_rect.h:255:37: warning: implicit conversion from 
> ‘float’ to ‘double’ to match other operand of binary expression 
> [-Wdouble-promotion]
>   255 | ((SDL_fabs(a->x - b->x) <= epsilon) &&

Thanks, fixed upstream by .

(I have to wonder whether this warning is providing openMSX with a
practical benefit, though: these days even cheap embedded CPUs have a
double-precision FPU.)

smcv

Bug#1004511: luajit SEGFAULTS on ppc64el

[Paul Gevers]

clone 1004511 -1 -14
block 1004511 by -1
retitle -1 please replace (build) dependency luajit with lua on ppc64el 
retitle 1004511 RM: luajit [ppc64el] -- ROP; segfaults

severity 1004511 normal
reassign 1004511 ftp.debian.org
clone -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11 -12 -13
reassign -1 src:aegisub 3.2.2+dfsg-6
reassign -2 src:ettercap 1:0.8.3.1-6
reassign -3 src:knot-resolver 5.4.4-1
reassign -4 src:love 11.3-1
reassign -5 src:luakit 1:2.3-1
reassign -6 src:nageru 2.1.0-1
reassign -7 src:nginx 1.20.2-2
reassign -8 src:obs-studio 27.2.4+dfsg1-1
reassign -9 src:rspamd 3.2-1
reassign -10 src:snort 2.9.15.1-6
reassign -11 src:sysbench 1.0.20+ds-2
reassign -12 src:trafficserver 9.1.2+ds-1
reassign -13 src:uwsgi-plugin-luajit 0.0.7
retitle -14 please prevent successful build on ppc64el until it works
thanks

Hi,

On 19-05-2022 16:34, Frédéric Bonnard wrote:

Hi Paul,
sorry for the late reply.
As I said on debian-devel, I've not enough expertise nor hope on that
topic.
Switching to lua is the way I went a few times, instead on relying on
luajit.


F.

On Mon, 02 May 2022 07:55:50 +0200 Paul Gevers  wrote:

If this issue is difficult to fix, how about removing luajit from
ppc64el? I noticed that the only reverse (build) dependent key package
of luajit (src:efl) already switched to plain lua on ppc64el (probably
because of this issue).


Not convinced I'm totally right there's no key packages in the list 
above, but let's go this route unless somebody puts up the effort to 
*maintain* the ppc64el parts.


The list above only includes direct depends of libluajit-5.1, I still 
need to figure out which packages build depend on libluajit-5.1-dev on 
ppc64el and successfully build there.


For the bug which remains assigned to luajit, I want it to ensure that 
in the future we don't accidentally have a successful build on ppc64el 
with broken content, so please either drop ppc64el from the list of 
architectures for which it builds or, better, add a build-time test that 
fails while luajit segfaults.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008829: pysrs-bin: envfrom2srs and srs2envtol fails with ModuleNotFoundError: No module named 'ConfigParser'

[Bjørn Mork]

Hefee  writes:

> Control: severity -1 normal

Why do you insist on keeping broken packages in Debian?

>> # envfrom2srs
>> Traceback (most recent call last):
>>   File "/usr/bin/envfrom2srs", line 14, in 
>> from ConfigParser import ConfigParser, DuplicateSectionError
>> ModuleNotFoundError: No module named 'ConfigParser'
>> 
>> # srs2envtol
>> Traceback (most recent call last):
>>   File "/usr/bin/srs2envtol", line 14, in 
>> from ConfigParser import ConfigParser, DuplicateSectionError
>> ModuleNotFoundError: No module named 'ConfigParser'
>>
>> No need to clutter the archive with broken and untested packages.
>> Please remove
>
> can you please use a less offensive language. 

Sorry.  What's the less offensice way to describe broken and untested?

> It is only the two example scripts, that are not properly ported to Python 3.

You are installing known broken examples in $PATH? But why!  

Well, whatever.  Thanks for not caring about quality


Bjørn

Bug#1011295: linux: Add support for Areca ARC-1886 series RAID controllers

[Salvatore Bonaccorso]

Source: linux
Version: 4.19.235-1
Severity: normal
Tags: buster
X-Debbugs-Cc: car...@debian.org

In 4.19.y in buster systems with Areca ARC-1886 series RAID
controllers cannot be supported. Please consider backporting the
required support as well back to buster.

The commits adding support up to upstream

https://git.kernel.org/linus/ae897ae28f9a1da2e04779a16f0a1112804a58fb

are conained already in buster (inclusive a followup commit
https://git.kernel.org/linus/d9a231226f28261a787535e08d0c78669e1ad010
which got backported to 5.10.52 as well from 5.14-rc1).

Merge request for review (a second pair of eyes is needed):

https://salsa.debian.org/kernel-team/linux/-/merge_requests/478

Regards,
Salvatore

Bug#793244: git-crypt: change of type in system_error might break with GCC-5

[Boyuan Yang]

Control: found 793244 0.5.0-1
Control: fixed 793244 0.7.0-0.1
Control: close 793244
X-Debbugs-CC: a...@andrewayer.name d...@debian.org

On Wed, 22 Jul 2015 13:33:34 + Matthias Klose  wrote:
> Package: src:git-crypt
> Severity: important
> Tags: sid stretch
> User: debian-...@lists.debian.org
> Usertags: gcc-pr66145
> 
> GCC PR libstdc++/66145 is a regression in GCC 5 which won't be fixed
> upstream in time for the GCC defaults change.  The work around is to
> rebuild the affected packages after GCC 5 is the default compiler.
> Please look at the code and decide, if the package is affected. If
> not, please just close the issue.  If it's a real issue, I'll add
> the packages affected to libstdc++6's Breaks attributes, with the
> version of the package at the time of the defaults change.
> 
> See
https://wiki.debian.org/GCC5#libstdc.2B-.2B-_c.2B-.2B-11_incompatibilities_.284.9_and_5.29
> for further information.
> 
> To build with GCC 5,install the gcc, g++, gfortran, ... packages
> from experimental (apt-get -t experimental install g++).

With the GCC 5 transition completed long long ago, I believe at least the
most recent upload in Sid is not affected by GCC's change. Closing this bug
accordingly. If there are anything that I'm missing, please feel free to
make corrections.

Thanks,
Boyuan Yang


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

Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file

[Philip Hands]

Philip Hands  writes:

>   
> https://salsa.debian.org/philh/localechooser/-/commit/24206bbaccb9619302bab5ca603fb214841ebf58#63952ea2967253e426478ffea08ddc67c3bff9d8_98_92

I just noticed: that commit's line order was mangled while rebasing.

This is what it should have been:

  
https://salsa.debian.org/philh/localechooser/-/commit/1e511957c05724bb417c07a84894bcb999a95b28

The subsequent commits in both versions of that branch did arrive at the
same destination, even if the middle bit was a bit tangled.

You may prefer to test the image produced from this later version of the
branch though, in which case the pipeline that built it can be found
here:

  https://salsa.debian.org/philh/localechooser/-/pipelines/379661

which (after a couple of triggers) gives rise to this mini.iso:

  
https://salsa.debian.org/installer-team/debian-installer/-/jobs/2786465/artifacts/file/public/gtk-mini.iso

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#1011241: kodi: Unable to change timezone (Kodi only uses system’s timezone)

[Vasyl Gello]

>Thank you so much for your work on packaging Kodi and for dealing with this so 
>quickly

Glad to help!

>I’ll try to build it myself from salsa, but if you can share debs for Kodi 19 
>(in case I’m not able to build it), that’d be great :)

Here you go:

https://transfer.sh/NJmitK/kodi_19.4+dfsg2-2_amd64.deb
https://transfer.sh/NJmitK/kodi-addons-dev_19.4+dfsg2-2_amd64.deb
https://transfer.sh/NJmitK/kodi-addons-dev-common_19.4+dfsg2-2_all.deb
https://transfer.sh/NJmitK/kodi-bin_19.4+dfsg2-2_amd64.deb
https://transfer.sh/NJmitK/kodi-bin-dbgsym_19.4+dfsg2-2_amd64.deb
https://transfer.sh/NJmitK/kodi-data_19.4+dfsg2-2_all.deb
https://transfer.sh/NJmitK/kodi-eventclients-common_19.4+dfsg2-2_all.deb
https://transfer.sh/NJmitK/kodi-eventclients-dev_19.4+dfsg2-2_amd64.deb
https://transfer.sh/NJmitK/kodi-eventclients-dev-common_19.4+dfsg2-2_all.deb
https://transfer.sh/NJmitK/kodi-eventclients-kodi-send_19.4+dfsg2-2_amd64.deb
https://transfer.sh/NJmitK/kodi-eventclients-ps3_19.4+dfsg2-2_amd64.deb
https://transfer.sh/NJmitK/kodi-eventclients-python_19.4+dfsg2-2_amd64.deb
https://transfer.sh/NJmitK/kodi-eventclients-wiiremote_19.4+dfsg2-2_amd64.deb
https://transfer.sh/NJmitK/kodi-eventclients-wiiremote-dbgsym_19.4+dfsg2-2_amd64.deb
https://transfer.sh/NJmitK/kodi-eventclients-zeroconf_19.4+dfsg2-2_amd64.deb
https://transfer.sh/NJmitK/kodi-repository-kodi_19.4+dfsg2-2_all.deb
https://transfer.sh/NJmitK/kodi-tools-texturepacker_19.4+dfsg2-2_amd64.deb
https://transfer.sh/NJmitK/kodi-tools-texturepacker-dbgsym_19.4+dfsg2-2_amd64.deb

I hope Mattia uploads both branches soon anyway, but to double check after me, 
the build is provided.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1011294: libabsl-dev: spurious -Wl flag in some pkg-config entries

[Benjamin Barenblat]

Package: libabsl-dev
Version: 0~20210324.2-3

Some of the pkg-config files installed with libabsl-dev contain errors.
For instance, absl_base.pc contains

Libs: -L${libdir} -Wl -labsl_base

The extra -Wl causes compilation to fail with

g++: error: unrecognized command-line option ‘-Wl’; did you mean ‘-W’?

Bug#1011210: RM: android-platform-system-core/1:10.0.0+r36-10 -- ROM; NVIU

[Adam D. Barratt]

On Thu, 2022-05-19 at 18:10 +0900, Roger Shimizu wrote:
> I didn‘t know there's "Testing follows removal automatically" rule,
> and just saw the wiki [1] says ftpmaster can only remove from sid &
> experimental.
> 
> I guess we should choose "testing follows removal automatically".
> 
> [1] 
> https://wiki.debian.org/ftpmaster_Removals#Removals_from_testing.2C_stable_and_oldstable
> 

For completeness, that section also says:

"
Note that in most cases it is unnecessary to request removal of your
package from both testing and unstable. Once the package is removed
from unstable, it will automatically be removed from testing once there
are no dependencies keeping it there.
"

Regards,

Adam

Bug#1011293: psad: gettimg logs flooded with scan reports for IP6 neigbor discovery

[Tim McConnell]

Package: psad
Version: 2.4.6-2
Severity: important
Tags: ipv6
X-Debbugs-Cc: tmcconnell...@gmail.com

Dear Maintainer,

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

What led up to the situation? Not sure, I installed psad and Snort rules etc.

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

What was the outcome of this action? getting flooded with this notification:
=-=-=-=-=-=-=-=-=-=-=-= Thu May 19 12:07:51 2022 =-=-=-=-=-=-=-=-=-=-=-=


 Danger level: [3] (out of 5) Multi-Protocol

 Scanned destinations: 1

   Source: fe80::::4a4e:fcff:fef0:69b8
  DNS: [No reverse dns info available]

  Destination: ff02:::::::0001
  DNS: [No reverse dns info available]

   Overall scan start: Thu May 19 11:37:16 2022
   Total email alerts: 26491
  Syslog hostname: DebianTim

 Global stats:
   chain:   interface:  protocol:  packets:
   INPUTenp1s0  icmp6  613

[+] Whois Information (source IP):
Unknown AS number or IP network. Please upgrade this program.

=-=-=-=-=-=-=-=-=-=-=-= Thu May 19 12:07:51 2022 =-=-=-=-=-=-=-=-=-=-=-=
I have NFTables set to this:
# ICMPv6 packets which must not be dropped, see
https://tools.ietf.org/html/rfc4890#section-4.4.1
meta nfproto ipv6 icmpv6 type { destination-unreachable,
packet-too-big, time-exceeded, parameter-problem, echo-reply, echo-request, nd-
router-solicit, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert, 148,
149 } accept
ip6 saddr fe80::/10 icmpv6 type { 130, 131, 132, 143, 151, 152,
153 } accept

# count and drop any other traffic
counter drop
What outcome did you expect instead?
Not to have 36,878 messages that I have been scanned for IP6 neighbor
protocols.
How do I configure PSAD to ignore these and quit getting false positives?
*** End of the template - remove these template lines ***


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

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

Versions of packages psad depends on:
ii  bsd-mailx [mailx]  8.1.2-0.20220412cvs-1
ii  exim4-daemon-light [mail-transport-agent]  4.95-5
ii  init-system-helpers1.62
ii  iproute2   5.17.0-2
ii  iptables   1.8.7-1
ii  libc6  2.33-7
ii  libcarp-clan-perl  6.08-1
ii  libdate-calc-perl  6.4-1.1
ii  libiptables-chainmgr-perl  1.6-2
ii  libiptables-parse-perl 1.6-2
ii  libnet-ip-perl 1.26-2
ii  libunix-syslog-perl1.1-3+b4
ii  lsb-base   11.1.0
ii  mailutils [mailx]  1:3.15-2
ii  net-tools  1.60+git20181103.0eebece-1
ii  perl   5.34.0-4
ii  psmisc 23.5-1
ii  rsyslog [system-log-daemon]8.2204.1-1
ii  whois  5.5.13

psad recommends no packages.

Versions of packages psad suggests:
ii  fwsnort  1.6.8-1

-- Configuration Files:
/etc/psad/psad.conf changed:
EMAIL_ADDRESSES root@localhost;
HOSTNAME_DebianTim_;
HOME_NET   DebianTim;
EXTERNAL_NETany;
FW_SEARCH_ALL   Y;
FW_MSG_SEARCH   DROP;
IFCFGTYPE   ifconfig;
DANGER_LEVEL1   5;### Number of packets.
DANGER_LEVEL2   15;
DANGER_LEVEL3   150;
DANGER_LEVEL4   1500;
DANGER_LEVEL5   1;
DL1_UNIQUE_HOSTS10;
DL2_UNIQUE_HOSTS20;
DL3_UNIQUE_HOSTS50;
DL4_UNIQUE_HOSTS100;
DL5_UNIQUE_HOSTS500;
CHECK_INTERVAL  5;
SNORT_SID_STR   SID;
PORT_RANGE_SCAN_THRESHOLD   1;
PORT_RANGE_SWEEP_THRESHOLD  0; ### a single port by default, see the 
DL1_UNIQUE_HOSTS var
PROTOCOL_SCAN_THRESHOLD 5;
ENABLE_PERSISTENCE  Y;
SCAN_TIMEOUT3600;  ### seconds
PERSISTENCE_CTR_THRESHOLD   5;
MAX_SCAN_IP_PAIRS   0;
SHOW_ALL_SIGNATURES Y;
ALERTING_METHODSALL;
AUTO_DETECT_JOURNALCTL  Y;
ENABLE_SYSLOG_FILE  Y;
IPT_WRITE_FWDATAY;
IPT_SYSLOG_FILE /var/log/messages;
SYSLOG_DAEMON   syslogd;
ENABLE_FW_MSG_READ_CMD  N;
FW_MSG_READ_CMD 

Bug#1011292: openssh-client: scp -O should be doable with a configuration file entry (in ~/.ssh/config)

[Raphaël Hertzog]

Package: openssh-client
Version: 1:9.0p1-1+b1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: raph...@freexian.com

dput and dput-ng are using "scp" and don't offer any simple way to
configure command line parameters and the switch to "sftp-behind-the-back"
broke dput for me with some targets (cf #1011063).

I would have liked to be able to add something like this in ~/.ssh/config:

Host deb.freexian.com
UseLegacyScp true

And be done with it. But there's no such option. It would be nice if
upstream could implement this.

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages openssh-client depends on:
ii  adduser   3.121
ii  dpkg  1.21.7
ii  libc6 2.33-7
ii  libedit2  3.1-20210910-1
ii  libfido2-11.11.0-1+b1
ii  libgssapi-krb5-2  1.19.2-2+b2
ii  libselinux1   3.3-1+b2
ii  libssl3   3.0.3-4
ii  passwd1:4.11.1+dfsg1-2
ii  zlib1g1:1.2.11.dfsg-4

Versions of packages openssh-client recommends:
ii  xauth  1:1.1.1-1

Versions of packages openssh-client suggests:
pn  keychain 
pn  libpam-ssh   
pn  monkeysphere 
ii  ssh-askpass-gnome [ssh-askpass]  1:9.0p1-1+b1

-- no debconf information

Bug#1010393: installation-reports: No swap partition which disables hibernate

[Pascal Hambourg]

Le 19/05/2022 à 14:48, Andreas Tille a écrit :


OK, I tried again.  I confirm the automatic installer now created a
swap partition inside encrypted LVM (no idea whether I simply looked
at the wrong place this morning.)  However, that swap partition is
only 1GB thus way to small to enable hibernation of 64GB memory.
(See attached screenshot.)


Known issue. Multiple bug reports such as #987503 have been reported.


I manually removed both partitions and recreated with 64GB swap.


You could also reserve some free space in the volume group and use it to 
extend the swap logical volume. This way, no need to remove the volumes.



On the freshly installed system lsblk now shows

 ...vg-swap_1 254:1   0 59,6G  0 lvm[SWAP]

Hmmm, it seems I need to add some more GB to enable hibernation since
this is my main purpose to create such a large swap.  Is there some kind
of formula how I need to size the swap space to enable dumping all
memory?


The installer talks in decimal GB whereas lsblk talks in binary GiB.
1 GiB ~ 1,07 GB

IIUC hibernation does not require as much swap as RAM, but "enough" free 
swap for what needs to be dumped into the hibernation image such as 
process data, but not clean disk cache.

Bug#1011291: dput: scp upload method can break due to implicit sftp usage

[Raphaël Hertzog]

Source: dput
Version: 1.1.0
Severity: important
X-Debbugs-Cc: raph...@freexian.com

This is the equivalent of #1011063 for dput instead of dput-ng.

When you run dput with openssh >= 9, and when dput is configured to use
"scp", "scp" will rely on the sftp protocol to do its job (unless you
pass the -O command line parameter).

When the server side has configured a forced command to restrict scp to a
specific directory (which is a good practice given scp's deficiencies),
then scp will badly fail.

Here's an example script that is configured with a ForceCommand associated
to the SSH key used for upload:

#!/bin/sh

case "$SSH_ORIGINAL_COMMAND" in
scp\ *)
exec scp -p -d -t /srv/deb.freexian.com/extended-lts/incoming
;;
chmod\ *)
find /srv/deb.freexian.com/extended-lts/incoming -user 
$(whoami) -type f | xargs --no-run-if-empty chmod 0644
exit 0
;;
*)
echo "ERROR: Forbidden command: $SSH_ORIGINAL_COMMAND"
echo "This SSH access can only be used to upload Debian 
packages."
exit 1
;;
esac


A recent scp will call /usr/lib/sftp-server as the remote command and the
case will match the third case and the sftp protocol will be confused by
the answer.

There's no good way to tweak that script to force sftp-server to be
restricted to a specific directory.

So either you switch to always "sftp" and do some other setup to restrict
sftp (with the Chroot directive), or you switch to "always plain scp"
by passing -O when you call scp.

Thus I'm suggesting that dput starts passing -O to scp when it detects a
recent OpenSSH. Or at least that it offers a way to pass command line
options to scp.

AfAIK ssh_config_options does not work for this. I's not an option that
can be passed to "-o" and it's really specific to scp and not to ssh
(which also gets called for the chmod IIRC).

Note that my "proper" fix to this regression has been to force usage of
sftp and to restrict sftp-server to a chroot, but dput has no support of
sftp so I had to switch to dput-ng. It would certainly makes sense for
dput to gain an sftp method!

Cheers,

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Bug#1011241: kodi: Unable to change timezone (Kodi only uses system’s timezone)

[Vasyl Gello]

I pushed both master and experimental branch.

Please let me know if you need prebuilt Debian packages.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#1011063: scp: Received message too long 1163022927

[Raphael Hertzog]

On Mon, 16 May 2022 07:44:26 -0400 Stefano Rivera  wrote:
> Now that openssh 1:9.0p1-1 uses the SFTP protocol by default, uploads to
> services using scp are broken.

Note that not all uploads are broken. They are broken when the server side
has a forced command that is expecting scp usage. I have this for example:


#!/bin/sh

case "$SSH_ORIGINAL_COMMAND" in
scp\ *)
exec scp -p -d -t /srv/deb.freexian.com/extended-lts/incoming
;;
chmod\ *)
find /srv/deb.freexian.com/extended-lts/incoming -user 
$(whoami) -type f | xargs --no-run-if-empty chmod 0644
exit 0
;;
*)
echo "ERROR: Forbidden command: $SSH_ORIGINAL_COMMAND"
echo "This SSH access can only be used to upload Debian 
packages."
exit 1
;;
esac


But without the "-O" option, scp will now call /usr/lib/sftp-server and
the case will match the third case generating unexpected noise for the
SFTP protocol.

There's no good way to tweak that script to force sftp-server to be
restricted to a specific directory.

So either you switch to always "sftp" and do some other setup to restrict
sftp (with the Chroot directive), or you switch to "always plain scp"
by passing -O when you call scp.

Cheers,
-- 
Raphaël Hertzog

Bug#1008829: pysrs-bin: envfrom2srs and srs2envtol fails with ModuleNotFoundError: No module named 'ConfigParser'

[Hefee]

Control: severity -1 normal

Hey,

> # envfrom2srs
> Traceback (most recent call last):
>   File "/usr/bin/envfrom2srs", line 14, in 
> from ConfigParser import ConfigParser, DuplicateSectionError
> ModuleNotFoundError: No module named 'ConfigParser'
> 
> # srs2envtol
> Traceback (most recent call last):
>   File "/usr/bin/srs2envtol", line 14, in 
> from ConfigParser import ConfigParser, DuplicateSectionError
> ModuleNotFoundError: No module named 'ConfigParser'
>
> No need to clutter the archive with broken and untested packages.
> Please remove

can you please use a less offensive language. 

It is only the two example scripts, that are not properly ported to Python 3.

With a big warning in the top of the file:
 # Use only if absolutely necessary.  It is *very* inefficient and
 # a security risk.

This was fixed upstream, but they not have released a new version.

Regards,

hefee

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

Bug#1011091: Systems with more than 4 memory slots not supported yet, not instantiating SPD

[Diederik de Haas]

Control: forwarded -1 https://www.spinics.net/lists/linux-i2c/msg56885.html

On Thursday, 19 May 2022 18:30:49 CEST Сергей Фёдоров wrote:
> So far I haven't received a response from any of the four:

It sometimes takes a while.

> But if I get an answer, then I still don't understand how I should tell BTS.

The first line of this email informed the BTS of the upstream conversation, so 
you don't have to do anything more (wrt that).

> will anyone from BTS read it?

All messages to the BTS are (also) send to the maintainer(s), that's how I 
noticed your issue to begin with :)

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

Bug#1011189: partman-auto-lvm/guided_size defaults to invalid value

[Stephen Gelman]

On May 19, 2022 at 2:12:54 AM, Cyril Brulebois  wrote:

> Hi Stephen,
>
> Stephen Gelman  (2022-05-17):
>
> In trying to track down this bug, I found that
>
> partman-auto-lvm/guided_size was added and according to
>
>
> https://salsa.debian.org/installer-team/partman-auto-lvm/-/blob/master/debian/partman-auto-lvm.templates#L77-L79
> ,
>
> defaults to a value of "some number". Unsurprisingly, this is not a
>
> valid number configuration option, so the maximum size doesn't get set
>
> properly. Setting "d-i partman-auto-lvm/guided_size string max" in my
>
> preseed restores the previous behavior. I believe there are two issues
>
> here:
>
>
> 1. "partman-auto-lvm/guided_size" should default to "max" in order to
>
>maintain compatibility with previous releases.
>
> 2. When "partman-auto-lvm/guided_size" is set to an invalid value it
>
>seems that the code does not behave properly. I'm not sure what behavior
>
>I'd expect, but I don't think the behavior I am seeing of picking the
>
>minimum size for each partition is correct.
>
>
> Without trying to second guess why this default value is there instead
> of something else, you can check partman-auto-lvm/perform_recipe_by_lvm
> and the few db_subst calls.
>
> I suppose the big difference between preseeding and not preseeding is the
> seen flag checked at the top of the while loop. I don't remember all the
> details around preseeding but I'd think "auto" means most questions are
> flagged as seen, which means you don't get the default replacement you'd
> get with an interactive installation.
>
>
> I'm not too sure how to best approach a possible fix. While the issue
> has cost you some debugging time, having to be explicit about how much
> space should be used for LVM doesn't look /that/ bad to me (even if that
> means that recipes that had been working for some releases no longer
> do).
>
> That being said, maybe there are some places in the documentation and/or
> examples where we should add that.
>
>
> Cheers,
> --
> Cyril Brulebois (k...@debian.org)
> D-I release manager -- Release team member -- Freelance Consultant
>

Understood. I do think that newer example preseeds
have partman-auto-lvm/guided_size set to max, so there shouldn’t be a
documentation issue (other than the general lack of documentation around
the preseed file but that is unrelated to this!) My personal preference
would be for the debian-installer to raise an error if this value is
missing - that would have saved me a ton of debugging time. Expecting it to
be set does seem very reasonable to me, but I think if an older preseed
isn’t going to work properly we at least owe it to the user to surface a
proper error message.

Stephen

Bug#1007913: What news with wine 7.0?

[Berillions]

You’ll have Wine 7.0 in Debian repo when Wine 9 stable will release.

You want the latest stable/development version ?

Build it yourself :-)
Envoyé de mon iPhone

> Le 19 mai 2022 à 16:03, Jérôme Marant  a écrit :
> 
> 
> Hi,
> 
> So wine 7 is not going to be packaged anytime soon?
> 
> Regards,
> 
>> Le ven. 1 avr. 2022 à 15:28, Antoine Le Gonidec 
>>  a écrit :
>> Le 31/03/2022 à 14:39, Jérôme Marant a écrit :
>> > Is wine 7 been week-end on?
>> > It looks like 6.x are been uploaded instead. What's the point?
>> 
>> The point is not to burn out the package maintainer with one huge messy 
>> changeset, and to provide us users with a mostly bug-free package thanks to 
>> incremental updates that are easier to review.
>> 
>> I advise either patience, or using WineHQ packages if you really can not 
>> wait. Keeping in mind that if Michael keeps the upload rate he had lately, 
>> we can expect him to reach 7.0 in less than 2 weeks from now.

Bug#1011290: tor: Unhandled OpenSSL errors found at ../src/lib/tls/tortls.c:190

[Francois Marier]

Package: tor
Version: 0.4.7.7-1
Severity: normal

Every day when I restart the tor daemon, I see the following in my logs:

  May 19 05:05:01 Tor[2928143]: Unhandled OpenSSL errors found at 
../src/lib/tls/tortls.c:190:
  May 19 05:05:01 Tor[2928143]: TLS error: could not load the shared library 
(in DSO support routines:dlfcn_load:---)
  May 19 05:05:01 Tor[2928143]: TLS error: could not load the shared library 
(in DSO support routines:DSO_load:---)
  May 19 05:05:01 Tor[2928143]: TLS error: error loading dso (in configuration 
file routines:module_load_dso:---)
  May 19 05:05:01 Tor[2928143]: TLS error: unknown module name (in 
configuration file routines:module_run:---)

I haven't noticed it causing any problems so far, but I've not really looked
into it.

Francois

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

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

Versions of packages tor depends on:
ii  adduser 3.121
ii  libc6   2.33-7
ii  libcap2 1:2.44-1
ii  libevent-2.1-7  2.1.12-stable-5+b1
ii  liblzma55.2.5-2.1
ii  libseccomp2 2.5.4-1
ii  libssl1.1   1.1.1o-1
ii  libsystemd0 250.4-1
ii  libzstd11.5.2+dfsg-1
ii  lsb-base11.1.0
ii  runit-helper2.13.0
ii  zlib1g  1:1.2.11.dfsg-4

Versions of packages tor recommends:
ii  logrotate3.19.0-2
ii  tor-geoipdb  0.4.7.7-1
ii  torsocks 2.3.0-3

Versions of packages tor suggests:
ii  apparmor-utils   3.0.4-2
pn  mixmaster
pn  nyx  
pn  obfs4proxy   
pn  socat
pn  torbrowser-launcher  

-- Configuration Files:
/etc/apparmor.d/system_tor changed:
profile system_tor flags=(attach_disconnected) {
  #include 
  #include 
  #include 
}

-- no debconf information

Bug#1010422: Britney fails to pin complete set in "Provides" api transitions [Was: Bug#1010422: transition: r-api-bioc-3.15]

[Andreas Tille]

Hi Paul,

Am Thu, May 19, 2022 at 01:07:59PM +0200 schrieb Paul Gevers:
> @tille, removals are work for *us*, they are not free lunch. Please fix the
> package that prevent migration.

There is no clean fix.  The packages featuring r-bioc-api-3.15 just need
some new predependencies.  These are hanging in new since some days.
Just pretending the new predependencies are not needed is not a fix,
IMHO.  So we can do nothing but wait.
 
> PS: for every transition we ask packages that need to go through NEW to be
> prepared in experimental such that during the transition, we don't need to
> wait for it.

I agree that in principle experimental would be cleaner.  On the other
hand its a lot more manual work.  I wonder whether it is a real problem
to leave the new r-bioc-* packages waiting in unstable until the
preconditions might have cleared NEW.  Is this not yet finished
transition in some way creating work?  I mean we have uploaded lots of
packages pretty fast - hopefully faster than in other transitions.  So
we are now waiting a bit.  May be my view on transitions is to naive and
there is really a problem if its delayed a couple of days more.  I plan
to give some hint to ftpmaster in the beginning of next week but I do
not want to create more pressure than needed.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#1011282: device-tree-compiler: provide pylibfdt

[Vagrant Cascadian]

Control: block 1011282 by 877125

On 2022-05-19, Bastian Germann wrote:
> Please provide a package python3-libfdt. It would be appreciated for dt-schema
> which only an old version can be packaged of right now, see #1005301.

I've tried several times, but always get stuck with:

  https://bugs.debian.org/877125

There was a hint at a proposed path forward ~2019, but I wasn't able to
get it to work...

Would be happy to see this fixed as well!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1011288: linux-image-5.17.0-1-amd64: amdgpu DRM goes into re-init loop when headless, eventually fails (5.17.0)

[Derek Upham]

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

Dear Maintainer,

This is a change of behavior from linux-image-5.16.0-6-amd64 to
linux-image-5.17.0-1-amd64.  The bug affects linux-image-5.17.0-1-amd64.
Booting 5.16.0 avoids the problem.

The host is a desktop machine using a physical AMD Radeon RX 470 card.
It connects over DisplayPort to a KVM, and from there DisplayPort to a
4K monitor.

The bug triggers when my host loses its connection to the monitor.
This may happen when I flip at the KVM, or it may happen when the
monitor turns off due to normal screensaver and power manager actions.
In the attached kernel log, I simply powered off the monitor and left
for several minutes.  (HDMI might not have the same behavior; it's my
understanding that DisplayPort aggressively reaps monitor connections
on any sort of disconnect, including powering off, while HDMI and DVI
do not.)

The kernel's DRM module goes into a loop where it re-initializes, up
to multiple times per minute.  If I reconnect the monitor within a
short time, the re-initialization stops.  If I don't reconnect, the
DRM module starts reporting "ring gfx timeout" errors as well.  Here's
a previous boot example, where I had finished using the computer for
the night.  The kernel reported errors after 12 minutes of
re-initialization logs:

  May 18 22:33:42 [drm] PCIE GART of 256M enabled (table at 0x00F40090).
  May 18 22:33:42 [drm] UVD and UVD ENC initialized successfully.
  May 18 22:33:43 [drm] VCE initialized successfully.
  [. . .]
  May 18 22:45:09 [drm] PCIE GART of 256M enabled (table at 0x00F40090).
  May 18 22:45:09 [drm] UVD and UVD ENC initialized successfully.
  May 18 22:45:09 [drm] VCE initialized successfully.
  May 18 22:45:19 [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, 
but soft recovered
  May 18 22:45:27 [drm] PCIE GART of 256M enabled (table at 0x00F40090).
  May 18 22:45:27 [drm] UVD and UVD ENC initialized successfully.
  May 18 22:45:27 [drm] VCE initialized successfully.
  May 18 22:45:37 [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, 
but soft recovered
  May 18 22:45:47 [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, 
but soft recovered
  May 18 22:46:00 [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, 
but soft recovered
  May 18 22:46:07 [drm] PCIE GART of 256M enabled (table at 0x00F40090).
  May 18 22:46:08 [drm] UVD and UVD ENC initialized successfully.
  May 18 22:46:08 [drm] VCE initialized successfully.

The logs show a few more re-initializations and "ring gfx timeout"
errors.  Shortly afterwards the kernel started faulting:

  May 18 22:47:12 [drm] PCIE GART of 256M enabled (table at 0x00F40090).
  May 18 22:47:12 [drm] UVD and UVD ENC initialized successfully.
  May 18 22:47:12 [drm] VCE initialized successfully.
  May 18 22:47:12 amdgpu :01:00.0: amdgpu: GPU fault detected: 147 
0x4802 for process Xorg pid 881 thread Xorg:cs0 pid 954
  May 18 22:47:12 amdgpu :01:00.0: amdgpu:   
VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0800
  May 18 22:47:12 amdgpu :01:00.0: amdgpu:   
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E048002
  May 18 22:47:12 amdgpu :01:00.0: amdgpu: VM fault (0x02, vmid 7, pasid 
32769) at page 2048, read from 'TC4' (0x54433400) (72)
  May 18 22:47:22 [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, 
signaled seq=663205, emitted seq=663207
  May 18 22:47:22 [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process 
information: process Xorg pid 881 thread Xorg:cs0 pid 954
  May 18 22:47:22 amdgpu :01:00.0: amdgpu: GPU reset begin!
  May 18 22:47:23 amdgpu :01:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] 
*ERROR* ring kiq_2.1.0 test failed (-110)
  May 18 22:47:23 [drm:gfx_v8_0_hw_fini [amdgpu]] *ERROR* KCQ disable failed
  May 18 22:47:23 amdgpu: cp is busy, skip halt cp
  May 18 22:47:23 [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize 
parser -125!
  May 18 22:47:23 amdgpu: rlc is busy, skip halt rlc
  May 18 22:47:23 amdgpu :01:00.0: amdgpu: BACO reset
  May 18 22:47:23 amdgpu :01:00.0: amdgpu: GPU reset succeeded, trying to 
resume
  May 18 22:47:23 [drm] PCIE GART of 256M enabled (table at 0x00F40090).
  May 18 22:47:23 [drm] VRAM is lost due to GPU reset!
  May 18 22:47:23 [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize 
parser -125!
  May 18 22:47:24 [drm] UVD and UVD ENC initialized successfully.
  May 18 22:47:24 [drm] VCE initialized successfully.
  May 18 22:47:24 amdgpu :01:00.0: amdgpu: recover vram bo from shadow start
  May 18 22:47:24 amdgpu :01:00.0: amdgpu: recover vram bo from shadow done
  May 18 22:47:24 [drm] Skip scheduling IBs!
  May 18 22:47:24 [drm] Skip scheduling IBs!
  May 18 22:47:24 amdgpu :01:00.0: amdgpu: GPU reset(10) succeeded!
  May 18 22:47:24 [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize 
parser -125!
  May 18 22:47:49 [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed 

Bug#1011287: bullseye-pu: package orca/3.38.2-2

[Samuel Thibault]

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

(the same was submitted for buster-pu)

[ Reason ]
The upload of webkit2gtk 2.36 into stable-sec and oldstable-sec
introduced severe accessibility regressions in stable and oldstable, the
upstream bug report is here:
https://gitlab.gnome.org/GNOME/orca/-/issues/244

[ Impact ]
This breaks structural navigation commands (“next/previous heading,
next/previous form field, list of all headings, list of all form fields,
etc., etc.”) which people use to make sense out of web pages which are
not making efforts to be accessible. It also breaks helper scripts that
Orca uses to make navigation smooth. In my tests, it was making Orca
completely silent in yelp for instance...

[ Tests ]
This was manually tested by usptream and in Debian.

[ Risks ]
The proposed changes come from upstream, and are very defensive, see the
attached changes and description below.

[ 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 ]
git-webkitgtk1 just additionally accepts WebKitGTK as an alias for WebKitGtk,

git-webkitgtk2 catches an exception and logs a warning instead of making
orca completely silent.
diff -Nru orca-3.38.2/debian/changelog orca-3.38.2/debian/changelog
--- orca-3.38.2/debian/changelog2020-12-23 22:02:25.0 +0100
+++ orca-3.38.2/debian/changelog2022-05-19 15:50:44.0 +0200
@@ -1,3 +1,12 @@
+orca (3.38.2-2) bullseye; urgency=high
+
+  * debian/patches/git-webkitgtk1: Fix screen reading of webkitgtk 2.36 which
+changed its toolkit name
+  * debian/patches/git-webkitgtk2: Fix screen reading of webkitgtk 2.36 which
+doesn't implement Collection any more.
+
+ -- Samuel Thibault   Thu, 19 May 2022 15:50:44 +0200
+
 orca (3.38.2-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru orca-3.38.2/debian/patches/git-webkitgtk1 
orca-3.38.2/debian/patches/git-webkitgtk1
--- orca-3.38.2/debian/patches/git-webkitgtk1   1970-01-01 01:00:00.0 
+0100
+++ orca-3.38.2/debian/patches/git-webkitgtk1   2022-05-19 15:50:44.0 
+0200
@@ -0,0 +1,53 @@
+commit 957e11b3c232632ec0e781b5d765c3000bcd1fb4
+Author: Joanmarie Diggs 
+Date:   Tue May 17 12:21:11 2022 +0200
+
+Handle WebKitGtk's change in toolkit name casing
+
+WebKitGtk objects now expose the toolkit name as WebKitGTK. Our
+script mapping for toolkits should probably not be case sensitive.
+For the purpose of making newer releases of WebKitGtk still work
+with older, stable versions of Orca, this commit just handles
+the alternative casing for WebKitGtk.
+
+Note that in some cases (e.g. Yelp), native caret navigation via
+F7 does not seem to be reliably toggled. That is a feature of either
+the app or the toolkit; not of Orca. This commit does not impact that.
+
+See issue #244
+
+---
+ src/orca/script_manager.py  |3 +++
+ src/orca/scripts/toolkits/WebKitGtk/script_utilities.py |2 +-
+ 2 files changed, 4 insertions(+), 1 deletion(-)
+
+--- a/src/orca/script_manager.py
 b/src/orca/script_manager.py
+@@ -59,6 +59,8 @@ class ScriptManager:
+  'pluma': 'gedit',
+  'org.gnome.gedit': 'gedit',
+ }
++self._toolkitNames = \
++{'WebKitGTK': 'WebKitGtk'}
+ 
+ self.setActiveScript(None, "__init__")
+ self._desktop = pyatspi.Registry.getDesktop(0)
+@@ -135,6 +137,7 @@ class ScriptManager:
+ else:
+ attrs = dict([attr.split(':', 1) for attr in attributes])
+ name = attrs.get('toolkit', '')
++name = self._toolkitNames.get(name, name)
+ 
+ return name
+ 
+--- a/src/orca/scripts/toolkits/WebKitGtk/script_utilities.py
 b/src/orca/scripts/toolkits/WebKitGtk/script_utilities.py
+@@ -58,7 +58,7 @@ class Utilities(script_utilities.Utiliti
+ return False
+ 
+ attrs = self.objectAttributes(obj)
+-return attrs.get('toolkit', '') == 'WebKitGtk'
++return attrs.get('toolkit', '') in ['WebKitGtk', 'WebKitGTK']
+ 
+ def getCaretContext(self):
+ # TODO - JD: This is private, but it's only here temporarily until we
diff -Nru orca-3.38.2/debian/patches/git-webkitgtk2 
orca-3.38.2/debian/patches/git-webkitgtk2
--- orca-3.38.2/debian/patches/git-webkitgtk2   1970-01-01 01:00:00.0 
+0100
+++ orca-3.38.2/debian/patches/git-webkitgtk2   2022-05-19 15:50:44.0 
+0200
@@ -0,0 +1,43 @@
+commit e9d8a3e5faa71531a615002dc37bcfda12d15abb
+Author: Joanmarie Diggs 
+Date:   Tue May 17 14:14:09 2022 +0200
+
+Structural Navigation: Handle unimplemented collection interface error
+
+The collection interface is something applications and toolkits get
+"for free" from 

Bug#1011286: buster-pu: package orca/3.30.1-2

[Samuel Thibault]

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

(the same was submitted for bullseye-pu)

[ Reason ]
The upload of webkit2gtk 2.36 into stable-sec and oldstable-sec
introduced severe accessibility regressions in stable and oldstable, the
upstream bug report is here:
https://gitlab.gnome.org/GNOME/orca/-/issues/244

[ Impact ]
This breaks structural navigation commands (“next/previous heading,
next/previous form field, list of all headings, list of all form fields,
etc., etc.”) which people use to make sense out of web pages which are
not making efforts to be accessible. It also breaks helper scripts that
Orca uses to make navigation smooth. In my tests, it was making Orca
completely silent in yelp for instance...

[ Tests ]
This was manually tested by usptream and in Debian.

[ Risks ]
The proposed changes come from upstream, and are very defensive, see the
attached changes and description below.

[ 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 ]
git-webkitgtk1 just additionally accepts WebKitGTK as an alias for WebKitGtk,

git-webkitgtk2 catches an exception and logs a warning instead of making
orca completely silent.
diff -Nru orca-3.30.1/debian/changelog orca-3.30.1/debian/changelog
--- orca-3.30.1/debian/changelog2018-10-20 12:36:06.0 +0200
+++ orca-3.30.1/debian/changelog2022-05-19 15:50:44.0 +0200
@@ -1,3 +1,12 @@
+orca (3.30.1-2) buster; urgency=high
+
+  * debian/patches/git-webkitgtk1: Fix screen reading of webkitgtk 2.36 which
+changed its toolkit name
+  * debian/patches/git-webkitgtk2: Fix screen reading of webkitgtk 2.36 which
+doesn't implement Collection any more.
+
+ -- Samuel Thibault   Thu, 19 May 2022 15:50:44 +0200
+
 orca (3.30.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru orca-3.30.1/debian/patches/git-webkitgtk1 
orca-3.30.1/debian/patches/git-webkitgtk1
--- orca-3.30.1/debian/patches/git-webkitgtk1   1970-01-01 01:00:00.0 
+0100
+++ orca-3.30.1/debian/patches/git-webkitgtk1   2022-05-19 15:50:44.0 
+0200
@@ -0,0 +1,53 @@
+commit 957e11b3c232632ec0e781b5d765c3000bcd1fb4
+Author: Joanmarie Diggs 
+Date:   Tue May 17 12:21:11 2022 +0200
+
+Handle WebKitGtk's change in toolkit name casing
+
+WebKitGtk objects now expose the toolkit name as WebKitGTK. Our
+script mapping for toolkits should probably not be case sensitive.
+For the purpose of making newer releases of WebKitGtk still work
+with older, stable versions of Orca, this commit just handles
+the alternative casing for WebKitGtk.
+
+Note that in some cases (e.g. Yelp), native caret navigation via
+F7 does not seem to be reliably toggled. That is a feature of either
+the app or the toolkit; not of Orca. This commit does not impact that.
+
+See issue #244
+
+---
+ src/orca/script_manager.py  |3 +++
+ src/orca/scripts/toolkits/WebKitGtk/script_utilities.py |2 +-
+ 2 files changed, 4 insertions(+), 1 deletion(-)
+
+--- a/src/orca/script_manager.py
 b/src/orca/script_manager.py
+@@ -56,6 +56,8 @@ class ScriptManager:
+  'mate-notification-daemon': 'notification-daemon',
+  'pluma':'gedit',
+ }
++self._toolkitNames = \
++{'WebKitGTK': 'WebKitGtk'}
+ 
+ self.setActiveScript(None, "__init__")
+ self._desktop = pyatspi.Registry.getDesktop(0)
+@@ -130,6 +132,7 @@ class ScriptManager:
+ else:
+ attrs = dict([attr.split(':', 1) for attr in attributes])
+ name = attrs.get('toolkit', '')
++name = self._toolkitNames.get(name, name)
+ 
+ return name
+ 
+--- a/src/orca/scripts/toolkits/WebKitGtk/script_utilities.py
 b/src/orca/scripts/toolkits/WebKitGtk/script_utilities.py
+@@ -61,7 +61,7 @@ class Utilities(script_utilities.Utiliti
+ attrs = dict([attr.split(':', 1) for attr in obj.getAttributes()])
+ except:
+ return False
+-return attrs.get('toolkit', '') == 'WebKitGtk'
++return attrs.get('toolkit', '') in ['WebKitGtk', 'WebKitGTK']
+ 
+ def getCaretContext(self):
+ # TODO - JD: This is private, but it's only here temporarily until we
diff -Nru orca-3.30.1/debian/patches/git-webkitgtk2 
orca-3.30.1/debian/patches/git-webkitgtk2
--- orca-3.30.1/debian/patches/git-webkitgtk2   1970-01-01 01:00:00.0 
+0100
+++ orca-3.30.1/debian/patches/git-webkitgtk2   2022-05-19 15:50:44.0 
+0200
@@ -0,0 +1,43 @@
+commit e9d8a3e5faa71531a615002dc37bcfda12d15abb
+Author: Joanmarie Diggs 
+Date:   Tue May 17 14:14:09 2022 +0200
+
+Structural Navigation: Handle unimplemented collection interface error
+
+The 

Bug#1011087: RFS: libshout-idjc/2.4.4-1 -- broadcast streaming library with IDJC extensions

[Bastian Germann]

Control: reopen -1

On Wed, 18 May 2022 20:30:39 +0200 Dennis Braun  wrote:

Ok thx, uploaded again.

Bug#1011285: RM: libricohcamerasdk [armel, i386] -- RoM; NBS no longer builds on armel, i386

[Thorsten Alteholz]

Package: ftp.debian.org
Severity: normal

The package no longer builds on armel, i386.

  Thorsten

Bug#1005719: bug #1005719: mumble: FTBFS with OpenSSL 3.0

[Chris Knadle]

Mumble 1.3 is not buildable with OpenSSL 3.0 and there is no patch available to 
allow doing so. There was an upstream attempt to backport patches for Mumble 1.4 
for Mumble 1.3 but there were enough issues that the effort had to be abandoned.


https://github.com/mumble-voip/mumble/pull/5354

I'm currently trying to package Mumble 1.4 which could resolve the problem, but 
running into issues with the build refactoring including a switch to using 
CMake. I'm working with upstream to try to resolve the build failures.


   -- Chris

--
Chris Knadle
chris.kna...@coredump.us

Bug#976439: wminput: Aborts with "undefined symbol: PyVarObject_CallFunction"

[Georges Khaznadar]

Hallo Bernd,

many thanks for your MR! this is a great job.

Best regards,   Georges.

Bernd Zeimetz a écrit :
> 
> 
> Hi,
> 
> with this MR applied, it does not crash at least.
> https://salsa.debian.org/georgesk/cwiid/-/merge_requests/1
> 
> Not tested yet.
> 
> Bernd
> 
> -- 
>  Bernd ZeimetzDebian GNU/Linux Developer
>  http://bzed.dehttp://www.debian.org
>  GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1011093: sip6: fails to process __delattr__ in libarcus 5.0~beta (works with sip 6.5)

[Sebastian Kuzminsky]

On 5/19/22 05:42, Dmitry Shachnev wrote:

Hi Sebastian!

On Mon, May 16, 2022 at 01:18:11PM -0600, Sebastian Kuzminsky wrote:

Package: sip6
Version: 6.6.1+dfsg-2
Severity: important
X-Debbugs-Cc: s...@highlab.com

When trying to build libArcus 5.0~beta (part of the Cura slicer),
sip-build 6.6 produces bogus C++ output that fails to compile:

[...]
sippyArcuspart3.cpp:424:102: error: ‘sipName___delattr__’ was not declared in 
this scope; did you mean ‘sipName___setattr__’?


Can you please check if this upstream commit fixes the issue for you?

https://riverbankcomputing.com/hg/sip/rev/a5601579b8ad


Yes, that upstream commit fixes the libArcus build problem, good find!

:-)

--
Sebastian Kuzminsky

Bug#1004511: luajit SEGFAULTS on ppc64el

[Frédéric Bonnard]

Hi Paul,
sorry for the late reply.
As I said on debian-devel, I've not enough expertise nor hope on that
topic.
Switching to lua is the way I went a few times, instead on relying on
luajit.


F.

On Mon, 02 May 2022 07:55:50 +0200 Paul Gevers  wrote:
> Hi,
> 
> On 24-04-2022 12:00, Paul Gevers wrote:
> > On Sat, 29 Jan 2022 19:32:53 +0100 Paul Gevers  wrote:
> >> With a recent upload of luajit the autopkgtest of knot-resolver fails 
> >> in testing when that autopkgtest is run with the binary packages of 
> >> luajit from unstable. It passes when run with only packages from 
> >> testing. In tabular form:
> > 
> > knot-resolver has been removed from testing due to this bug report, but 
> > can't migrate back because a newer version fails to build on ppc64el. 
> > Also other reverse dependencies of luajit show SEGFAULT in their 
> > autopkgtest on ppc64el, so this seems a problem in luajit. Unfortunately 
> > (Release Team member opinion) luajit is a key package so can't be 
> > trivially removed. Can you (maintainer and ppc64el porters) please have 
> > a look?
> 
> If this issue is difficult to fix, how about removing luajit from 
> ppc64el? I noticed that the only reverse (build) dependent key package 
> of luajit (src:efl) already switched to plain lua on ppc64el (probably 
> because of this issue).
> 
> Paul


signature.asc
Description: PGP signature

Bug#1011284: popularity-contest: d/postinst: remove bash dependency, fix shellcheck

[наб]

Source: popularity-contest
Version: 1.74
Severity: wishlist
Tags: patch

Dear Maintainer,

d/postinst hard-depends on bash to generate random days/hours/minutes;
however,
  od -d -An -N2 /dev/urandom
is equivalent to
  bash -c 'echo $RANDOM'
‒ patch 1 replaces the latter with the former;
od is part of coreutils, and -d is a legacy switch so it's available on
all implementations (and we already use it as a fallback for hostid
generation).

If we did -N1 we'd read only one byte, instead of 2, but that'd impact
the distribution after mod, so I left that as-were.

Patch 2 fixes remaining shellcheck annotations in d/postinst.

Patches apply to current Salsa HEAD; I included gbp dch d/changelog
output inside, as seems to be the custom. Feel free to drop it,
of course.

Best,
наб

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

Kernel: Linux 5.10.0-14-amd64 (SMP w/24 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
From 9e8bc1745a452a43c31a5b8142b12ee40602c32d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=BD=D0=B0=D0=B1?= 
Date: Thu, 19 May 2022 16:52:23 +0200
Subject: [PATCH 1/2] Use od instead of bash to generate random numbers in
 d/postinst
X-Mutt-PGP: OS

---
 debian/changelog | 6 ++
 debian/postinst  | 6 +++---
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index ceca4e4..f84d701 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+popularity-contest (1.75) UNRELEASED; urgency=medium
+
+  * Use od instead of bash to generate random numbers in d/postinst
+
+ -- наб   Thu, 19 May 2022 16:52:49 +0200
+
 popularity-contest (1.74) unstable; urgency=medium
 
   * debian/rules: add missing targets. Closes: #999319 Thanks Lucas Nussbaum
diff --git a/debian/postinst b/debian/postinst
index 1501d5c..bb7b2b2 100755
--- a/debian/postinst
+++ b/debian/postinst
@@ -38,12 +38,12 @@ generate_id() {
 
 # Select a random day to submit on, to spread the load over time, unless it is already set.
 select_random_day() {
-DAY=`bash -c 'echo $(($RANDOM % 7))'`
+	DAY=$(( $(od -d -An -N2 /dev/urandom) % 7))
 }
 
 generate_crond() {
-  MIN=`bash -c 'echo $(($RANDOM % 60))'`
-  HOUR=`bash -c 'echo $(($RANDOM % 24))'`
+  MIN=$(( $(od -d -An -N2 /dev/urandom) % 60))
+  HOUR=$(( $(od -d -An -N2 /dev/urandom) % 24))
   FILE=/etc/cron.daily/popularity-contest
   cat > /etc/cron.d/popularity-contest /dev/null 2>&1; then
-MY_HOSTID=`uuidgen -r | tr -d -`
+MY_HOSTID=$(uuidgen -r | tr -d -)
 elif test -r /proc/sys/kernel/random/uuid; then
-MY_HOSTID=`tr -d - < /proc/sys/kernel/random/uuid`
+MY_HOSTID=$(tr -d - < /proc/sys/kernel/random/uuid)
 else
-MY_HOSTID=`od -x -An -N16 /dev/urandom | tr -d ' '`
+MY_HOSTID=$(od -x -An -N16 /dev/urandom | tr -d ' ')
 fi;
 }
 
@@ -98,7 +98,7 @@ case "$1" in
 # Workaround for bug #237874 triggered on hurd.  The
 # problem was fixed in version 1.15, 2004-03-20.
 
-  $EMPTYID) generate_id;;
+  "$EMPTYID") generate_id;;
 # Workaround for bug #240603 triggered by md5sums change
 # of behaviour with stdin. version 1.17, 2004-04-12.
   *-)  MY_HOSTID="${MY_HOSTID%  -}";;
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1011283: ITP:php-amphp-byte-stream -- stream abstraction to make working with non-blocking I/O simple

[Katharina Drexel]

Package: wnpp

* Package name: php-amphp-byte-stream
  Upstream Author : Daniel Lowrey 
* License : MIT
  Description : amphp/byte-stream is a stream abstraction for Amp.
 .
 Amp is a non-blocking concurrency framework for PHP. It provides an event loop,
 promises and streams as a base for asynchronous programming.

Regards
Katharina

Bug#1010949: Reply to MIchael Biebl's message

[Michael Biebl]

Am 19.05.22 um 03:49 schrieb Joshua Brickel:

Okay, you got me convinced. So I guess I should try the one kernel below.

Is there a howto page on how to do this and make sure grub knows about 
it too?




grub is not involved in resume from suspend.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011282: device-tree-compiler: provide pylibfdt

[Bastian Germann]

Source: device-tree-compiler
Severity: wishlist
Version: 1.6.1-1

Please provide a package python3-libfdt. It would be appreciated for dt-schema
which only an old version can be packaged of right now, see #1005301.

If you do not want to build it from this source package the alternative is 
creating
a new package from https://github.com/devicetree-org/pylibfdt. I would convert 
this
issue to an RFP in this case.

Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file

[Michael Tokarev]

19.05.2022 17:23, Philip Hands wrote:

Michael Tokarev  writes:


19.05.2022 15:59, Philip Hands wrote:
...

Actually, I'm unable to resist the urge to remove the redundant use of
cat (that was already there), so how about doing it in a single sed:

LEVEL=$(sed "/^${LOCALE%%_*}/"'{ print $4 ; exit }' 
/usr/share/localechooser/languagelist)


That smells like awk usage, not sed ;)


Doh!

I started out with awk, as it's cleaner for this, and then noticed that
we don't have awk enabled in d-i's busybox, so changed to sed.


Is there a reason we don't have awk in busybox? Maybe it's time to enable it?
Some stuff, like this one, is really easier to do with awk.

(and I'm still waiting for a reply from Chris Boot about busybox).

Thanks,

/mjt

Bug#922102: ITP: libopusenc -- High-level API for encoding Ogg Opus audio streams

[IOhannes m zmoelnig]

On Sun, 18 Oct 2020 16:10:28 +0200 David Heidelberg  wrote:

On Tue, 12 Feb 2019 12:43:37 +1030 Ron  wrote:
 > Package: wnpp
 > Severity: wishlist
 > Owner: Ron 
 >
 > * Package name: libopusenc
 >   Version : 0.2.1


any news on this?

3 years have passed since the ITP, 1½ years have passed since the followup.

if Ron is no longer interested in packaging libopusenc, i would be happy 
to take over (under the umbrella of the multimedia-team).


gfamsdr
IOhannes


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1003366: reportbug: open-iscsi-udeb : iscsid unable to start. Missing libsystemd.so.0 in installer environment

[Eugene Losowski-Gallagher]

Hi All,

I have a patch:
0001-iscsid-in-udeb-not-dependent-on-libsystemd-Closes-10.patch
(attached)

Unfortunately I cannot create merge requests direct, or via email on the
project.

On Tue, 11 Jan 2022 at 20:03, Eugene Losowski-Gallagher <
eugene.losowskigallag...@googlemail.com> wrote:

> Hi Ritesh,
>
> Thank you for the clarification on using "iscsistart".
>
> I have followed this up through the installer.
>
> To explain the use-case in its entirety:
> 1) Use starts a machine on a TGT enabled (iscsi-target) network
> 2) User tests the network by entering the host name of the tgt
># This is the step that fails! - uses "iscsiadm" which is dependent on
> "iscsid"
> 3) User selects the drives they want to use, and then proceed with setup
> (formatting etc)
> -- Installer continues as normal ---
>
>
> Explanation of 2)
> To perform the discovery and testing of the tgt the installer uses:
> "iscsiadm"
>   This works via communicating with "iscsid"
>   And that takes us back to the libsystemd.so.0 dependency.
> So we need to get "iscsid" running without the "libsystemd" dependency.
>
>
> Explanation of 3)
> "iscsistart"
> 1) This is an application to start the initiator
> - As far as I am aware this works fine, just requires a lot of parameters
> to begin
>
>
> So thinking about this (and looking at the repositories for the original
> and debian versions):
> 1) The upstream repository (https://github.com/open-iscsi/open-iscsi) has
> a "NO_SYSTEMD" build
> 2) The project gets built with autoconf (and this might the the cause of
> my woes) - as systemd is detected at build time.
> This is confirmed in the "debian/control" file - where it is a build
> dependency.
>
>
> To move forward on this:
> Q1) Is it at all possible to make a "NO_SYSTEMD" build for the
> "open-iscsi-udeb" package
> - this is a define present in:
>   https://github.com/open-iscsi/open-iscsi
> This will require some change(s) in the build setup for the udeb
> (crucially not change the normal package!)
>
> Please can you let me know if that (i.e 2x builds) is acceptable?
>
>
> That should in theory resolve the issue properly:
> 1) *-udeb is not installed on the system
> 2) systemd is (still) not used in the installer environment
> 3) iscsid will start as it is not linked to systemd
> 4) This allows iscsiadm to discover the iSCSI drives
> 5) Installer for partman-iscsi works properly
>
>
> I hope this allows (at least in theory) a way forward.
> - At least explaining why it doesn't work as expected.
>
> The practicalities might be more difficult - but with your approval of the
> overall strategy I can work on it.
>
> Many thanks
>
> Eugene
>


-- 

*Eugene Losowski-Gallagher*
*Mob: *07825160923
From 5c31bbac1c04855eedd27c5b113ef83bc8ac4caa Mon Sep 17 00:00:00 2001
From: Eugene Losowski-Gallagher 
Date: Mon, 16 May 2022 21:32:55 +0100
Subject: [PATCH] iscsid in udeb not dependent on libsystemd (Closes: #1003366)

---
 debian/rules | 29 ++---
 usr/Makefile |  3 +++
 2 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/debian/rules b/debian/rules
index 2451953..22ccf63 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,9 +20,24 @@ override_dh_auto_configure:
 
 override_dh_auto_build:
 	@# Let debhelper pass configure flags.
+	# Build standard open-iscsi
 	dh_auto_configure --sourcedirectory=iscsiuio
-
 	CFLAGS="$(CPPFLAGS) $(CFLAGS)" dh_auto_build
+	mkdir -p usr-deb
+	mv usr/iscsid usr-deb/iscsid
+	mv usr/iscsistart usr-deb/iscsistart
+	mv usr/iscsiadm usr-deb/iscsiadm
+ifneq ($(UDEB),)
+	(cd usr; make clean)
+	# Build No libsystemd version first for udeb integration
+	export NO_SYSTEMD=1; CFLAGS="$(CPPFLAGS) $(CFLAGS)" dh_auto_build
+	@# Move binaries to udeb directory
+	mkdir -p usr-udeb
+	mv usr/iscsid usr-udeb/iscsid
+	mv usr/iscsistart usr-udeb/iscsistart
+	mv usr/iscsiadm usr-udeb/iscsiadm
+endif
+
 
 override_dh_auto_install:
 
@@ -33,9 +48,9 @@ override_dh_auto_install:
 	dh_install -p libopeniscsiusr-dev libopeniscsiusr/libopeniscsiusr/ usr/include/
 
 	@# open-iscsi
-	dh_install -p open-iscsi usr/iscsid sbin/
-	dh_install -p open-iscsi usr/iscsistart sbin/
-	dh_install -p open-iscsi usr/iscsiadm sbin/
+	dh_install -p open-iscsi usr-deb/iscsid sbin/
+	dh_install -p open-iscsi usr-deb/iscsistart sbin/
+	dh_install -p open-iscsi usr-deb/iscsiadm sbin/
 	dh_install -p open-iscsi utils/iscsi_discovery sbin/
 	dh_install -p open-iscsi utils/iscsi-iname sbin/
 	dh_install -p open-iscsi etc/iscsid.conf etc/iscsi/
@@ -63,9 +78,9 @@ override_dh_auto_install:
 
 ifneq ($(UDEB),)
 	@# open-iscsi-udeb
-	dh_install -p open-iscsi-udeb usr/iscsid sbin/
-	dh_install -p open-iscsi-udeb usr/iscsistart sbin/
-	dh_install -p open-iscsi-udeb usr/iscsiadm sbin/
+	dh_install -p open-iscsi-udeb usr-udeb/iscsid sbin/
+	dh_install -p open-iscsi-udeb usr-udeb/iscsistart sbin/
+	dh_install -p open-iscsi-udeb usr-udeb/iscsiadm sbin/
 	dh_install -p open-iscsi-udeb utils/iscsi_discovery sbin/
 	dh_install 

Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file

[Philip Hands]

Michael Tokarev  writes:

> 19.05.2022 15:59, Philip Hands wrote:
> ...
>> Actually, I'm unable to resist the urge to remove the redundant use of
>> cat (that was already there), so how about doing it in a single sed:
>> 
>>LEVEL=$(sed "/^${LOCALE%%_*}/"'{ print $4 ; exit }' 
>> /usr/share/localechooser/languagelist)
>
> That smells like awk usage, not sed ;)

Doh!

I started out with awk, as it's cleaner for this, and then noticed that
we don't have awk enabled in d-i's busybox, so changed to sed.

I seem to have messed up what I put in the email ... that's not what's
in the commit:

  
https://salsa.debian.org/philh/localechooser/-/commit/24206bbaccb9619302bab5ca603fb214841ebf58#63952ea2967253e426478ffea08ddc67c3bff9d8_98_92

  sed -ne "/^${LOCALE%%_*}/"'{ s/^[[:alpha:]]*;\([[:digit:]]\);.*/\1/p; q}' 
/usr/share/localechooser/languagelist

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#1011281: ITS: opus

[Debian/GNU]

Source: opus
Version: 1.3.1-0.1
Severity: important

Dear Maintainer,



I intend to salvage the package "opus", for the following reasons:

- no visible packaging activity for 1249 days
  - the last upload by the current maintainer was on 2018-12-23
  - there has been an NMU upload on 2020-09-26 for the new upstream
release 1.3.1 (released in spring 2019) [#934809], that has gone
unacknowledged so far.

I'm doing this ITS in lieu with my other ITSs for opus-tools, opusfile
and libogg, as i think they belong together.
(Otherwise I would not file an ITS for this specific package, as it is
in definitely better shape than the other three).


I'm happy with co-maintaining the package (although my stance at
maintenance is definitely more aggressive with regard to updating to the
latest and greatest source format, dh-compat and the like).
I would more than welcome maintenance of the package under the
multimedia-team umbrella.

it would be great to hear something from the current maintainer of
"opus".

cheers

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

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

Bug#1005858: gh,gitsome: File conflict, both ship /usr/bin/gh

[Antoine Beaupré]

On 2022-02-27 10:09:32, Paul Wise wrote:
> Control: forwarded -1 https://github.com/donnemartin/gitsome/issues/177
>
> On Sat, 26 Feb 2022 23:43:14 +0800 SZ Lin (林上智) wrote:
>
>> The "gitsome" has used "gh" since 2017, and thus would you mind renaming
>> the "gh" in your package to avoid the conflict issue?
>
> Since gh is the official GitHub client, probably it should retain "gh"
> and gitsome should move to "git some" or similar, as I have suggested
> in the above upstream issue. The only commentor there agreed with me.

And I agree with you. The gitsome package already installs two binaries:
one is called "gh" and the other is called "gitsome". It seems to me it
could simply drop the "gh" alias and none would be the worse.

SZ, in your February 26 message[1], you explicitly asked the gh package
maintainers to rename their package, which was refused. It seems the
concensus that has developped in the following thread is that it is
instead your package, gitsome, that should have its binary renamed.

Pabs suggested `gitsome` could also be renamed to `git-some` which would
make it visible as a `git some` subcommand, from what I understand. It
seems like the `gh` alias is kind of an alias unrelated with the main
functionality of the package.

SZ, do you agree with removing the `gh` binary from the `gitsome` binary
package? I'd be happy to send a NMU to do this if you agree, which would
unblock `gh` from migrating into testing.

Otherwise, how can we reach consensus on this? The policy says that if
we can't reach consensus, *both* packages need to be renamed, and that
seems like a situation where we would all lose.

I'll also point out that the upstream issue hasn't seen any activity
since pabs commented on it in February, so it doesn't seem like we can
count on upstream to fix this for us. The issue has been open for 2
years now.

Thank you for your time!

[1]: 
https://lists.debian.org/msgid-search/CAFk6z8Mw0kFHehm_a7=0bmdt6mzff03sewx+y93xy42bkq7...@mail.gmail.com

-- 
Tu connaîtras la vérité de ton chemin à ce qui te rend heureux.
- Aristote

Bug#1011279: [Pkg-javascript-devel] Bug#1011279: node-dateformat CJS file does not provide the same API than ES file

[Yadd]

On 19/05/2022 15:50, Yadd wrote:

Package: node-dateformat
Version: 5.0.3-1
Severity: serious
Tags: ftbfs
Justification: FTBFS
Control: affects -1 grunt node-lightgallery

Following upstream doc, `import d from 'dateformat'` is a function. The
file built with `babeljs --plugins @babel/transform-modules-commonjs`
produces an Object, usable function is d.default. This breaks grunt (try
to build node-lightgallery for example).

This can be fixed using `mjs2cjs -a` and a custom `debian/index.cjs`


Grunt code:

// lib/grunt/template.js
template.date = require('dateformat');

// ...
  return template.date(now, format);
// => error: template.date is not a function

Bug#1006519: Already fixed in 2.6.0~git20220510+dco-1 in experimental

[Michael Biebl]

On Sun, 15 May 2022 16:02:48 +0300 Adrian Bunk  wrote:

Version: 2.6.0~git20220510+dco-1

openvpn (2.6.0~git20220510+dco-1) experimental; urgency=medium
...
  * Build against OpenSSL 3.0

 -- Bernhard Schmidt   Fri, 13 May 2022 00:01:35 +0200


Berni, would you mind uploading this version to unstable?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011280: ITS: opus-tools

[Debian/GNU]

Source: opus-tools
Version: 0.1.10-1
Severity: important

Dear Maintainer,


I intend to salvage the package "opus-tools", for the following reasons:

- a new upstream release of "opus-tools" has been available for some
  years:
  - 0.2 (in 2018) [#910261]

- no visible packaging activity for 1942 days
  - the last upload by the current maintainer was 2017-01-23
  - there has been an NMU upload on 2022-02-03 to a serious FTBFS bug
[#965759], that has gone unacknowledged so far.
  - there are 2 open wishlist bug reports since 2018-04-10
not a single bug report has seen *any* reaction from the current
maintainer. neither has [#965759] (which is no longer open, as it
was closed by the aforementioned NMU]

I'm aware that the maintainer of "opus-tools" does not usually want to make
packaging changes without specific reasons, but I don't think that this
allows for completely ignoring open bug-reports of severity SERIOUS for
more than 1½ year.

I'm happy with co-maintaining the package (although my stance at
maintenance is definitely more aggressive with regard to updating to the
latest and greatest source format, dh-compat and the like).
I would more than welcome maintenance of the package under the
multimedia-team umbrella.


it would be great to hear something from the current maintainer of
"opus-tools".

cheers

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

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

Bug#655113: openoffice.org-dictionaries: Please make use of existing Debian infrastructure to make these appear under emacs, jed and mutt

[Agustin Martin]

Control: reassign -1 dictionaries-common,libreoffice-dictionaries

El dom, 19 dic 2021 a las 22:05, Agustin Martin
() escribió:
>
> If you consider that this is working well enough, I think this bug
> report can be closed.

Since there were no objections, I am reassigning this bug report to
both dictionaries-common and libreoffice-dictionaries and will mark it
as closed by dictionaries-common/1.28.14,

--
Agustin

Bug#1007913: What news with wine 7.0?

[Jérôme Marant]

Hi,

So wine 7 is not going to be packaged anytime soon?

Regards,

Le ven. 1 avr. 2022 à 15:28, Antoine Le Gonidec 
a écrit :

> Le 31/03/2022 à 14:39, Jérôme Marant a écrit :
> > Is wine 7 been week-end on?
> > It looks like 6.x are been uploaded instead. What's the point?
>
> The point is not to burn out the package maintainer with one huge messy
> changeset, and to provide us users with a mostly bug-free package thanks to
> incremental updates that are easier to review.
>
> I advise either patience, or using WineHQ packages if you really can not
> wait. Keeping in mind that if Michael keeps the upload rate he had lately,
> we can expect him to reach 7.0 in less than 2 weeks from now.
>

Bug#1011279: node-dateformat CJS file does not provide the same API than ES file

[Yadd]

Package: node-dateformat
Version: 5.0.3-1
Severity: serious
Tags: ftbfs
Justification: FTBFS
Control: affects -1 grunt node-lightgallery

Following upstream doc, `import d from 'dateformat'` is a function. The
file built with `babeljs --plugins @babel/transform-modules-commonjs`
produces an Object, usable function is d.default. This breaks grunt (try
to build node-lightgallery for example).

This can be fixed using `mjs2cjs -a` and a custom `debian/index.cjs`

Bug#1011278: ITS: libogg

[Debian/GNU]

Source: libogg
Version: 1.3.4-0.1
Severity: important

Dear Maintainer,

I intend to salvage the package "libogg", for the following reasons:

- "libogg" currently FTBFS (due to using a very outdated debhelper
  compat) [#965673]
- a new upstream release 1.3.5 of "libogg" has been released two years
  ago, with a bug [#1004545] opened for this in january 2022, with no
  feedback from the current maintainer
- the last upload of the package was an NMU, but never got acknowledged
  by the current maintainer.

- no visible packaging activity for 2913 days
  - the last upload by the current maintainer was 2014-05-28
  - there has been an unacknowledged NMU upload on 2021-01-13
  - there are 3 open bug reports, ranging from wishlist to *serious*
since 2020-07-20 (to be fair, one of the wishlist bugs has only
been filed in 2022-03-10)
not a single bug report has seen *any* reaction from the current
maintainer.

I'm aware that the maintainer of "libogg" does not usually want to make
packaging changes without specific reasons, but I don't think that this
allows for completely ignoring open bug-reports of severity SERIOUS for
more than 1½ year.

I'm happy with co-maintaining the package (although my stance at
maintenance is definitely more aggressive with regard to updating to the
latest and greatest source format, dh-compat and the like).
I would more than welcome maintenance of the package under the
multimedia-team umbrella.

it would be great to hear something from the current maintainer of
"libogg".

cheers

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

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

Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file

[Michael Tokarev]

19.05.2022 15:59, Philip Hands wrote:
...

Actually, I'm unable to resist the urge to remove the redundant use of
cat (that was already there), so how about doing it in a single sed:

   LEVEL=$(sed "/^${LOCALE%%_*}/"'{ print $4 ; exit }' 
/usr/share/localechooser/languagelist)


That smells like awk usage, not sed ;)

/mjt

Bug#1011254: The UDEB package "localechooser" contains probably some buggy source code in "05localechooser" file

[Philip Hands]

Jmkr  writes:

> Package: localechooser
> Version: 2.94
>
> Dear Maintainers,
>
> While working on my customized Debian installer (DI) I noticed that the 
> "./usr/lib/post-base-installer.d/05localechooser" file from the 
> "localechooser_2.93_*.udeb" package (at least for AMD64 and ARM64 
> architectures) contains probably buggy source code for calculating the 
> value of the "LEVEL" variable (on lines 87-91). The problems are in 
> "cut" commands (on lines 88 and 91) which should probably be:
> cut -f 1-3 -d \;
> cut -f 2 -d \;
>
> Currently the "LEVEL" variable seems to get the empty string value 
> because the "grep" command (on line 89) cannot find the language code 
> (because the first field is removed by the first "cut" command). Maybe 
> the "LANGUAGECODE" variable on line 83 could be avoided and merged into 
> the "LEVEL" variable if command substitution is done using "$(...)" 
> resulting in this proposed source code:
> LEVEL=$(cat /usr/share/localechooser/languagelist | \
>  cut -f 1-3 -d \; | \
>  grep $(echo $LOCALE | cut -f 1 -d _) | \
>  head -n 1 | \
>  cut -f 2 -d \;)

Yes, we were cutting off the LANGUAGECODE column before trying to grep
it, so the old code would never come up with a level of 3 or 4.

BTW I would suggest using:

  ${LOCALE%%_*} in place of the $(echo ... | cut ...)

Actually, I'm unable to resist the urge to remove the redundant use of
cat (that was already there), so how about doing it in a single sed:

  LEVEL=$(sed "/^${LOCALE%%_*}/"'{ print $4 ; exit }' 
/usr/share/localechooser/languagelist)

I've put that into this branch (with a few of other tweaks):

  https://salsa.debian.org/philh/localechooser/-/commits/bug1011254

and here is a mini-iso that includes that change:

  
https://salsa.debian.org/installer-team/debian-installer/-/jobs/2785179/artifacts/file/public/gtk-mini.iso

[note that it's built by infrastructure that's not under our direct
control, so such images should be viewed with a degree of suspicion]

If you'd like to test that, please do, otherwise perhaps you can suggest
a test that would determine that the code is behaving as you'd hope.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#1011277: RM: haskell-dpkg -- ROM; incompatible with current libdpkg and no upstream fix in the foreseeable future

[Sven Bartscher]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: pkg-haskell-maintain...@lists.alioth.debian.org

Dear FTP masters,

haskell-dpkg can't be built against current versions of libdpkg. The 
upstream maintainer has indicated that they will not be able to fix this 
problem for a long time. The package currently has no reverse 
dependencies. Under these circumstances it is probably best to remove 
the package from unstable for now, and reintroduce it at a later time if 
appropriate.


Regards
Sven


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010422: Britney fails to pin complete set in "Provides" api transitions [Was: Bug#1010422: transition: r-api-bioc-3.15]

[Nilesh Patra]

On 19 May 2022 2:25:23 pm IST, Andreas Tille  wrote:
>Am Thu, May 19, 2022 at 01:41:12PM +0530 schrieb Nilesh Patra:
>> 
>> I think we can workaround these anyway by editing the DESCRIPTION file -- 
>> maybe I'll do so and upload either late in the night today or early morning 
>> Tom.
>
>I do not think that editing DESCRIPTION is the prefered way to
>fix our transition.  As I wrote in my other mail removing them
>from testing manually should do the trick as well, IMHO.

I disagree.

I don't really think stalling the migration just for a couple of packages is a 
sensible thing to do.

There is not a functional difference (real API change) so keeping a couple of 
packages outdated (and that too because pre-deps are in new) is no big deal.

We already have tons of cran stuff being backdated due to several reasons, I 
don't think this situation is very different. I know the bioc api is different 
but there's no functional difference in working of package at all.

I would rather do what it takes and complete the transition, so as to unbreak 
packages and also not consume un-necessary bandwidth of release team members.

And so, I'd continue to patch description and upload anyway. If you're 
very/extremely against it, please do let me know soon so we figure out 
something else.

--
Best,
Nilesh

Bug#1011276: requests: Fix autopkgtest when http_proxy, https_proxy or no_proxy is set

[Olivier Gayot]

Package: requests
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Dear Maintainer,

When moving from 2.25.1+dfsg to 2.27.1+dfsg, we enabled the pytest
test-suite in autopkgtest.

Some of the tests fail when HTTP proxy variables are set:

FAILED 
tests/test_requests.py::TestRequests::test_errors[http://doesnotexist.google.com-ConnectionError]
FAILED 
tests/test_requests.py::TestRequests::test_respect_proxy_env_on_send_self_prepared_request
FAILED 
tests/test_requests.py::TestRequests::test_respect_proxy_env_on_send_session_prepared_request
FAILED 
tests/test_requests.py::TestRequests::test_respect_proxy_env_on_send_with_redirects
FAILED tests/test_requests.py::TestRequests::test_respect_proxy_env_on_get - ...
FAILED tests/test_requests.py::TestRequests::test_respect_proxy_env_on_request


*** /tmp/tmp877wny2v/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * Fix autopkgtest when http_proxy, https_proxy or no_proxy variable is set
(LP: #1974182)


Thanks for considering the patch.


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

Kernel: Linux 5.15.0-30-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
requests-2.27.1+dfsg/debian/patches/0002-Fix-tests-with-HTTP-proxy.patch 
requests-2.27.1+dfsg/debian/patches/0002-Fix-tests-with-HTTP-proxy.patch
--- requests-2.27.1+dfsg/debian/patches/0002-Fix-tests-with-HTTP-proxy.patch
1970-01-01 01:00:00.0 +0100
+++ requests-2.27.1+dfsg/debian/patches/0002-Fix-tests-with-HTTP-proxy.patch
2022-05-19 14:14:07.0 +0200
@@ -0,0 +1,83 @@
+Description: Fix autopkgtest when HTTP/HTTPS proxy is set
+ The pytest suite does not expect the http_proxy, https_proxy and no_proxy
+ variables to be present in the environment. They make pytest fail and
+ therefore autopkgtest fail as well.
+Author: Olivier Gayot 
+Bug: 
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/requests/+bug/1974182
+Forwarded: no
+Last-Update: 2022-05-19
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: b/tests/test_requests.py
+===
+--- a/tests/test_requests.py   2022-01-05 16:35:04.0 +0100
 b/tests/test_requests.py   2022-05-19 14:13:08.454208318 +0200
+@@ -535,8 +535,9 @@
+ ('http://fe80::5054:ff:fe5a:fc0', InvalidURL)
+ ))
+ def test_errors(self, url, exception):
+-with pytest.raises(exception):
+-requests.get(url, timeout=1)
++with override_environ(http_proxy=None, https_proxy=None):
++with pytest.raises(exception):
++requests.get(url, timeout=1)
+ 
+ def test_proxy_error(self):
+ # any proxy related error (address resolution, no route to host, etc) 
should result in a ProxyError
+@@ -557,14 +558,14 @@
+ requests.get(httpbin(), proxies={'http': 
'http:///example.com:8080'})
+ 
+ def test_respect_proxy_env_on_send_self_prepared_request(self, httpbin):
+-with override_environ(http_proxy=INVALID_PROXY):
++with override_environ(no_proxy=None, http_proxy=INVALID_PROXY):
+ with pytest.raises(ProxyError):
+ session = requests.Session()
+ request = requests.Request('GET', httpbin())
+ session.send(request.prepare())
+ 
+ def test_respect_proxy_env_on_send_session_prepared_request(self, 
httpbin):
+-with override_environ(http_proxy=INVALID_PROXY):
++with override_environ(no_proxy=None, http_proxy=INVALID_PROXY):
+ with pytest.raises(ProxyError):
+ session = requests.Session()
+ request = requests.Request('GET', httpbin())
+@@ -572,7 +573,7 @@
+ session.send(prepared)
+ 
+ def test_respect_proxy_env_on_send_with_redirects(self, httpbin):
+-with override_environ(http_proxy=INVALID_PROXY):
++with override_environ(no_proxy=None, http_proxy=INVALID_PROXY):
+ with pytest.raises(ProxyError):
+ session = requests.Session()
+ url = httpbin('redirect/1')
+@@ -581,13 +582,13 @@
+ session.send(request.prepare())
+ 
+ def test_respect_proxy_env_on_get(self, httpbin):
+-with override_environ(http_proxy=INVALID_PROXY):
++with override_environ(no_proxy=None, http_proxy=INVALID_PROXY):
+ with pytest.raises(ProxyError):
+ session = requests.Session()
+ session.get(httpbin())
+ 
+ def 

Bug#1011249: cyrus-sasl2: broken DIGEST-MD5 with openssl3

[Andreas Hasenack]

Hi,

On Wed, May 18, 2022 at 6:34 PM Bastian Germann  wrote:
> Should I take the upstream sasl patches which enable DIGEST-MD5 again or is

s/enable/fix/

:)

> it time to drop that mechanism, which is obsoleted by RFC6331 for 11 years?

It looks like upstream wants to obsolete DIGEST-MD5 and default it to
"no" in 2.2.0:

https://github.com/cyrusimap/cyrus-sasl/issues/726

There is also this comment from Howard
(https://github.com/cyrusimap/cyrus-sasl/issues/665#issuecomment-931753459)
"""
 As usual for deprecating/removing something like digestmd5, the
replacement (SCRAM) should be in wide use before the actual
deletion/removal.
"""

> What would I need to do on dropping it? An entry in NEWS, notifying the
> release team, something else?

Personally I think removing an authentication mechanism is a big deal,
as its removal will break sites that use it during an upgrade.
Definitely big flashy warnings are warranted.

In the meantime, I'll put up a PR with the minimal fix plus a new DEP8
test to catch the problem.

Bug#1001757: RFS: google-android-installers/1639148153 [NMU] -- Google's Android SDK

[Roger Shimizu]

Dear Fab,

Thanks for your work!
I already merged your MR to debian/exp branch.

Since there're 128 commits / patches for your one MR, it's actually
not possible for me to review deeply.
So I'd prefer to upload to experimental first.

Your upload to mentors seems to have some more commits / patches than MR.
So please make another MR to release all your patches to salsa.
After that I can sponsor the upload to experimental.

Cheers,
Roger

On Thu, May 19, 2022 at 6:59 PM Roger Shimizu  wrote:
>
> Dear Bastian,
>
> Thanks for the ping!
> I'll check this package later.
>
> Cheers,
> Roger
>
> On Thu, May 19, 2022 at 2:09 AM Bastian Germann  wrote:
> >
> > Hi Roger and List,
> >
> > Can you please comment on this and your plans on the 
> > google-android-installers package?
> > This is from sponsorship-requests and nobody cared about it in months.
> > I am not familiar with the Android build system.
> >
> > Hans-Christoph has commented on the Salsa MR to possibly make Fab Stz the 
> > new package maintainer.
> >
> > Thanks,
> > Bastian
> >
> > On Wed, 15 Dec 2021 14:13:32 +0100 Fab Stz  wrote:
> >  > I already sent an email on 21/Oct & 19/Nov to android-tools-
> >  > de...@lists.alioth.debian.org, Roger Shimizu  
> > concerning a
> >  > merge request for that package. I haven't seen an anwser yet.
> >  >
> >  > Message was:
> >  > Hello everybody,
> >  >
> >  > I updated the google-android-installers source package and created a 
> > merge
> >  > request available here:
> >  >
> >  > 
> > https://salsa.debian.org/android-tools-team/google-android-installers/-/merge_requests/3
> >  >
> >  > It automatically builds packages for almost all SDK components described 
> > in
> >  > Google's https://dl.google.com/android/repository/repository2-1.xml
> >  >
> >  > Among the covered components there is: build-tools, platforms, 
> > platform-tools,
> >  > cmdline-tools, emulator, ndk, sources.
> >  >
> >  > Could you have a look and give any feedback please?
> >  >
> >  > Once merged & approved, this is ready to be reused with the other SDK
> >  > repositories of Google. It will permit to create source packages for 
> > these
> >  > components: sys-img, add-on, extras...

Bug#1011275: ITP: golang-github-gorilla-schema -- Package gorilla/schema fills a struct with form values.

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-gorilla-schema
  Version : 1.2.0-1
  Upstream Author : Gorilla Web Toolkit
* URL : https://github.com/gorilla/schema
* License : BSD-3-clause
  Programming Lang: Go
  Description : Package gorilla/schema fills a struct with form values.
  Description : fills a struct with form values
 This package provides a Go library that implements methods to fill
 strics with form values.
 .
 It is provided by Gorilla which is a web toolkit for the Go
 programming language.

I intend to maintain this under the pkg-go umbrella. it is a build
dependency currently vendered by the podman package (and possibly others)

Bug#1010186: gnome-text-editor: Segfault when closing

[asciiwolf]

On Mon, 25 Apr 2022 16:33:04 -0400 Jeremy Bicha  
wrote:
> On Mon, Apr 25, 2022 at 4:27 PM Michel Le Bihan  wrote:
> > Package: gnome-text-editor
> > Version: gnome-text-editor
> >
> > gnome-text-editor segfaults when closing the app in the GUI
>
> Does that bug happen with gnome-text-editor 42.1-1 ? I'm asking
> because that version was supposed to fix a similar issue.
>
> Thank you,
> Jeremy Bicha
>
>

It still seems to happen with gnome-text-editor 42.1-1.

There was this crash recently fixed in upstream: 
https://gitlab.gnome.org/GNOME/gnome-text-editor/-/issues/371

It seems to be the same issue.

Daniel

Bug#1011268: release.debian.org: proposes autoremoving every package(?) when nvidia-graphics-drivers-tesla-470 is RC-buggy

[Paul Gevers]

Control: reassign -1 qa.debian.org

On 19-05-2022 12:37, Simon McVittie wrote:

Package: release.debian.org

dkms and nvidia-graphics-drivers-tesla-470 currently have RC bug #1010884
triggering autoremovals (it was closed today, so maybe it will cease to be
relevant soon).

I would expect the only packages affected by this to be packages that
specifically depend on dkms or on the NVIDIA proprietary driver.


It's a great surprise to me that this happened. I *suspect* it's due to 
that the fact that the bug you mentioned is assigned to both a key 
package and a non-key package. As one can imagine, autoremovals are 
based on bugs in testing. The bug in testing affects a non-key package, 
but I wouldn't be surprised if that once it takes the bug number in (for 
a non-key package) it isn't aware of the bts feature that a bug can be 
assigned to more packages and doesn't handle this case.



This seems very wrong. I'm fairly sure base-files doesn't depend on
graphics drivers, and in any case the NVIDIA proprietary driver is in
non-free, so by policy no package in main can possibly depend on it.


With the understanding above, I suspect it's just because of the removal 
of dkms, which is part of the key package set for $(reasons).



It might be better if autoremovals were evaluated something like this:

1. work out what autoremovals would take place if main was the only
archive area that existed;


Autoremoval is supposed to only remove non-key packages and completely 
ignore key packages. That's obviously not what happened, so a clear bug.


Technically the autoremoval is calculated by udd, hence reassigning there.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011274: ITP:php-amphp-http-client -- Asynchronous concurrent HTTP/2 and HTTP/1.1 client built on the Amp concurrency framework

[Katharina Drexel]

Package: wnpp

* Package name: php-amphp-http-client
  Upstream Author : Daniel Lowrey 
* License : MIT
  Description : Asynchronous concurrent HTTP/2 and HTTP/1.1 client
 .
 This package provides an asynchronous HTTP client for PHP based on Amp.
 Its API simplifies standards-compliant HTTP resource traversal and RESTful web
 service consumption without obscuring the underlying protocol. The library
 manually implements HTTP over TCP sockets; as such it has no dependency on
 ext/curl.

Regards
Katharina

Bug#1011093: sip6: fails to process __delattr__ in libarcus 5.0~beta (works with sip 6.5)

[Dmitry Shachnev]

Hi Sebastian!

On Mon, May 16, 2022 at 01:18:11PM -0600, Sebastian Kuzminsky wrote:
> Package: sip6
> Version: 6.6.1+dfsg-2
> Severity: important
> X-Debbugs-Cc: s...@highlab.com
>
> When trying to build libArcus 5.0~beta (part of the Cura slicer),
> sip-build 6.6 produces bogus C++ output that fails to compile:
>
> [...]
> sippyArcuspart3.cpp:424:102: error: ‘sipName___delattr__’ was not declared in 
> this scope; did you mean ‘sipName___setattr__’?

Can you please check if this upstream commit fixes the issue for you?

https://riverbankcomputing.com/hg/sip/rev/a5601579b8ad

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#1011269: [Pkg-samba-maint] Bug#1011269: winbind: Winbind does not start when "allow trusted domain" is set to "no"

[Michael Tokarev]

Control: tag -1 + pending

19.05.2022 13:42, Geert Lorang wrote:

Package: winbind
Version: 2:4.13.13+dfsg-1~deb11u3
Severity: normal

Dear Maintainer,

After upgrading from Debian Buster to Debian Bullseye winbind does not start 
anymore
because we have "allow trusted domain" set to "no" in smb.conf.

winbind exits immediately with:

init_domain_list: add_trusted_domain BUILTIN returned NT_STATUS_NO_SUCH_DOMAIN

This is (fixed) Samba bug https://bugzilla.samba.org/show_bug.cgi?id=14899


This is fixed in 2:4.13.13+dfsg-1~deb11u4 which is waiting for the
review and acceptance of the release team since Apr-15, see #1009726.

Hopefully I wont forget to mark this one as fixed when samba is accepted.

/mjt

Bug#1011210: RM: android-platform-system-core/1:10.0.0+r36-10 -- ROM; NVIU

[Paul Gevers]

Control: reassign -1 ftp.debian.org

Hi,

On 19-05-2022 11:10, Roger Shimizu wrote:

I guess we should choose "testing follows removal automatically".


reassigned.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010422: Britney fails to pin complete set in "Provides" api transitions [Was: Bug#1010422: transition: r-api-bioc-3.15]

[Paul Gevers]

Hi,

On 19-05-2022 10:55, Andreas Tille wrote:

Am Thu, May 19, 2022 at 01:41:12PM +0530 schrieb Nilesh Patra:

I think we can workaround these anyway by editing the DESCRIPTION file -- maybe 
I'll do so and upload either late in the night today or early morning Tom.


I do not think that editing DESCRIPTION is the prefered way to
fix our transition.  As I wrote in my other mail removing them
from testing manually should do the trick as well, IMHO.


Well, I just learned that some/most of these "required" uploads in this 
transition are not needed because of incompatibility of the package with 
the new api, but just your tooling being broken (in my opinion). If 
packages requiring r-api-bioc-* work with the next version, they should 
just pick up the r-api-bioc-* version when they are rebuild, like we do 
with nearly all other ecosystem in Debian. Only packages that don't work 
need an upload.


If all it takes is this;
https://salsa.debian.org/r-pkg-team/r-bioc-mofa/-/blob/7b010dcd1947e2b8b26da3ab49b957715cb83b5c/debian/patches/bioc-3.15.patch
to get the package working with the fresh bioconducter, that really 
shouldn't need manual changes and should be able to be picked up 
automatically.


@tille, removals are work for *us*, they are not free lunch. Please fix 
the package that prevent migration.


Paul

PS: for every transition we ask packages that need to go through NEW to 
be prepared in experimental such that during the transition, we don't 
need to wait for it.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1011273: sbuild: autopkgtest unshare is not running dscverify

[Dave Jones]

Package: sbuild
Version: 0.79.0-1ubuntu1
Severity: normal
Tags: patch

Dear Maintainer,

While working on merging the current sbuild from Debian unstable to 
Ubuntu I noticed something a bit odd in the "unshare" test (both in our 
delta with Debian, but also in the Debian original):

At the top of verify() in unshare [1], the routine attempts to assign 
its arguments to some variables:

verify_src="${1+no}"
verify_bin="${1+no}"

Unfortunately, there's a couple of errors here. Firstly only the first
argument is used ($2 never gets a look in). But secondly, the "+" 
expansion ("use alternative value") means that, if $1 is "" the result 
is "" but otherwise the result is "no". So verify_src and verify_bin can 
only *ever* be "no"; they can never be "yes". This means the dscverify 
sections later on never get called.

Our delta in Ubuntu compounds these mistakes by also making the orig and 
deb sections optional and ... also using $1 and the "+" expansion [2].
Oops!

Firstly, instead of relying on a bunch of boolean yes/no parameters I 
think it might be nicer to simply list the things we'd like verify to 
check (e.g. "verify orig deb dsc"), which I've done in a local branch. 
Once that change was in place I also discovered that dscverify still 
never ran because it never gets installed in the system setup by the 
qemu-wrapper script because devscripts is missing from EXTRA_DEPS there.

Finally, once this was all working I discovered that the .dsc file 
should *not* be checked when sbuild is run *without* the "--source" 
option because, although the .dsc file is produced in this case, it 
isn't signed (presumably because it doesn't get listed in the .changes) 
file. To fix this I separated the .dsc and .changes checks into their 
own sub-routines and modified the calls to verify() accordingly.

I'm attaching a patch which fixes the issue, but once I've got a bug 
number I'll propose the changes as an MR on salsa for convenience.

[1]: 
https://salsa.debian.org/debian/sbuild/-/blob/main/debian/tests/unshare#L71

[2]: 
https://git.launchpad.net/ubuntu/+source/sbuild/tree/debian/tests/unshare?h=applied/ubuntu/devel=23ce4fa3e9bbe83ca70a23224c2c3f8829078227#n80


Best regards,

Dave Jones.
diff --git a/debian/tests/unshare b/debian/tests/unshare
index 2c45a1fe..b9013eb1 100755
--- a/debian/tests/unshare
+++ b/debian/tests/unshare
@@ -20,6 +20,7 @@ chmod 700 "${AUTOPKGTEST_TMP}/gpghome"
 export GNUPGHOME="${AUTOPKGTEST_TMP}/gpghome"
 
 verify_orig() {
+   echo "verifying test-pkg_1.0.tar.xz" >&2
 cat << END | base64 -d > "${AUTOPKGTEST_TMP}/expected"
 /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/BBZdADoZSs4dfiUjFYSOxzYxnd+/m6AlVEVOGf2j
 nT6NK0F9XZ7LLydbY3I//WjMOM2RFpGUqZ8R8Q8lLmydB5SLN5ZQSPW3OJjHlzxVQmv2v3KUyPxo
@@ -47,6 +48,7 @@ END
 }
 
 verify_deb() {
+   echo "verifying test-pkg_1.0_all.deb" >&2
 cat << END | base64 -d > "${AUTOPKGTEST_TMP}/expected"
 ITxhcmNoPgpkZWJpYW4tYmluYXJ5ICAgMTQ2NzMxMDUxMiAgMCAgICAgMCAgICAgMTAwNjQ0ICA0
 ICAgICAgICAgYAoyLjAKY29udHJvbC50YXIueHogIDE0NjczMTA1MTIgIDAgICAgIDAgICAgIDEw
@@ -68,26 +70,31 @@ END
rm "${AUTOPKGTEST_TMP}/expected"
 }
 
-verify() {
-   verify_src="${1+no}"
-   verify_bin="${1+no}"
-   echo "verifying test-pkg_1.0.tar.xz" >&2
-   verify_orig
-   echo "verifying test-pkg_1.0_all.deb" >&2
-   verify_deb
+verify_dsc() {
# we shouldn't have to manually pass the keyring because the path is an
# implementation detail of gnupg (it used to be named pubring.gpg in
# the past) but dscverify ignores GNUPGHOME, see Debian bug #981008
-   if [ "$verify_bin" = "yes" ]; then
-   echo "verifying test-pkg_1.0.dsc" >&2
-   dscverify --keyring="${AUTOPKGTEST_TMP}/gpghome/pubring.kbx" 
"${AUTOPKGTEST_TMP}/test-pkg_1.0.dsc"
-   echo "verifying test-pkg_1.0_${nativearch}.changes" >&2
-   dscverify --keyring="${AUTOPKGTEST_TMP}/gpghome/pubring.kbx" 
"${AUTOPKGTEST_TMP}/test-pkg_1.0_${nativearch}.changes"
-   fi
-   if [ "$verify_src" = "yes" ]; then
-   echo "verifying test-pkg_1.0_source.changes" >&2
-   dscverify --keyring="${AUTOPKGTEST_TMP}/gpghome/pubring.kbx" 
"${AUTOPKGTEST_TMP}/test-pkg_1.0_source.changes"
-   fi
+   echo "verifying test-pkg_1.0.dsc" >&2
+   dscverify --keyring="${AUTOPKGTEST_TMP}/gpghome/pubring.kbx" \
+   "${AUTOPKGTEST_TMP}/test-pkg_1.0.dsc"
+}
+
+verify_bin_changes() {
+   echo "verifying test-pkg_1.0_${nativearch}.changes" >&2
+   dscverify --keyring="${AUTOPKGTEST_TMP}/gpghome/pubring.kbx" \
+   "${AUTOPKGTEST_TMP}/test-pkg_1.0_${nativearch}.changes"
+}
+
+verify_src_changes() {
+   echo "verifying test-pkg_1.0_source.changes" >&2
+   dscverify --keyring="${AUTOPKGTEST_TMP}/gpghome/pubring.kbx" \
+   "${AUTOPKGTEST_TMP}/test-pkg_1.0_source.changes"
+}
+
+verify() {
+   for thing in $*; do
+   verify_$thing
+   done
# remove 

Bug#1011271: bullseye-pu: package nvidia-graphics-drivers-legacy-390xx/390.151-1~deb11u1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
Control: clone -1 -2
Control: tags -2 = buster

Hi,

I'd like to update nvidia-graphics-drivers-legacy-390xx/non-free to a new
upstream release fixing some CVEs. 

It comes with the same packaging fixes and improvements that already
reached stable in the 
  nvidia-graphics-drivers 470.103.01-3~deb11u2
  nvidia-graphics-drivers-tesla-450 450.172.01-2~deb11u1
uploads.

The buster upload will only differ by adding a 'Rebuild for buster'
changelog entry with version number 390.151-1~deb10u1.


Andreas


ngd-390xx-390.151-1~deb11u1.diff.xz
Description: application/xz

Bug#1011270: ITP:php-amphp-amp -- Non-blocking concurrency framework for PHP

[Katharina Drexel]

Package: wnpp

* Package name: php-amphp-amp
  Upstream Author : Daniel Lowrey 
* License : MIT
  Description : Non-blocking concurrency framework for PHP
 Amp is a non-blocking concurrency framework for PHP. It provides an event loop,
 promises and streams as a base for asynchronous programming.
 .
 Promises in combination with generators are used to build coroutines, which
 allow writing asynchronous code just like synchronous code, without any
 callbacks.

Regards
Katharina
--

Bug#1011138: Workaround for bug #1011138

[Hopea Jonne]

Uninstalling libssl-dev helped, for some reason libssl-dev also ships with a 
libssl.so binary which may or may not be of same version as other ones.


--
Best regards,

HJ

Bug#1011269: winbind: Winbind does not start when "allow trusted domain" is set to "no"

[Geert Lorang]

Package: winbind
Version: 2:4.13.13+dfsg-1~deb11u3
Severity: normal

Dear Maintainer,

After upgrading from Debian Buster to Debian Bullseye winbind does not start 
anymore
because we have "allow trusted domain" set to "no" in smb.conf.

winbind exits immediately with:

init_domain_list: add_trusted_domain BUILTIN returned NT_STATUS_NO_SUCH_DOMAIN

This is (fixed) Samba bug https://bugzilla.samba.org/show_bug.cgi?id=14899

As a workaround we can set "allow trusted domain" to "yes" but like to avoid 
this
as we have a very large forest with many domains all over the world creating 
delays 
in resolving users & groups.

Is there a chance this can be considered a regression and the fix applied in 
the next Debian stable point release?

Thanks,
Geert

-- Package-specific info:
* /etc/samba/smb.conf present, but not attached
* /var/lib/samba/dhcp.conf not present

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

Kernel: Linux 5.10.0-14-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 winbind depends on:
ii  init-system-helpers  1.60
ii  libbsd0  0.11.3-1
ii  libc62.31-13+deb11u3
ii  libgnutls30  3.7.1-5
ii  libldap-2.4-22.4.57+dfsg-3
ii  libpopt0 1.18-2
ii  libtalloc2   2.3.1-2+b1
ii  libtdb1  1.4.3-1+b1
ii  libtevent0   0.10.2-1
ii  libwbclient0 2:4.13.13+dfsg-1~deb11u3
ii  lsb-base 11.1.0
ii  samba-common 2:4.13.13+dfsg-1~deb11u3
ii  samba-common-bin 2:4.13.13+dfsg-1~deb11u3
ii  samba-libs   2:4.13.13+dfsg-1~deb11u3

winbind recommends no packages.

Versions of packages winbind suggests:
ii  libnss-winbind  2:4.13.13+dfsg-1~deb11u3
ii  libpam-winbind  2:4.13.13+dfsg-1~deb11u3

-- no debconf information

Bug#1011268: release.debian.org: proposes autoremoving every package(?) when nvidia-graphics-drivers-tesla-470 is RC-buggy

[Simon McVittie]

Package: release.debian.org

dkms and nvidia-graphics-drivers-tesla-470 currently have RC bug #1010884
triggering autoremovals (it was closed today, so maybe it will cease to be
relevant soon).

I would expect the only packages affected by this to be packages that
specifically depend on dkms or on the NVIDIA proprietary driver.

However, looking at
https://udd.debian.org/cgi-bin/autoremovals.cgi
it looks as though literally every package is up for autoremoval:

Santiago Vila 
   base-files: buggy deps nvidia-graphics-drivers-tesla-470, flagged for 
removal in 36.8 days

This seems very wrong. I'm fairly sure base-files doesn't depend on
graphics drivers, and in any case the NVIDIA proprietary driver is in
non-free, so by policy no package in main can possibly depend on it.

It might be better if autoremovals were evaluated something like this:

1. work out what autoremovals would take place if main was the only
   archive area that existed;
2. then, do the same for the union of main, contrib and non-free, but
   ignore attempts to autoremove additional packages from main during this
   phase

That would mean that a RC-buggy main package could trigger autoremovals
from main, contrib and/or non-free, but RC-buggy contrib/non-free packages
could only trigger autoremovals from contrib/non-free.

smcv

Bug#988540: im-config: breaks the keyboard configuration

[Gunnar Hjalmarsson]

On 2022-04-08 22:57, Gunnar Hjalmarsson wrote:

The ibus dependency in the zoom .deb file is getting annoying.
Besides this bug there is , and the
other day I noticed this case:

https://github.com/mike-fabian/ibus-typing-booster/issues/107#issuecomment-1089262983

So I made an own attempt to get in touch with the zoom developers:

https://devforum.zoom.us/t/annoying-ibus-dependency-in-zoom-deb-files/67293


My attempt has been wasted time so far. If somebody else wants to chime 
in, please feel free. I have given up.


--
Gunnar

Bug#1001757: RFS: google-android-installers/1639148153 [NMU] -- Google's Android SDK

[Roger Shimizu]

Dear Bastian,

Thanks for the ping!
I'll check this package later.

Cheers,
Roger

On Thu, May 19, 2022 at 2:09 AM Bastian Germann  wrote:
>
> Hi Roger and List,
>
> Can you please comment on this and your plans on the 
> google-android-installers package?
> This is from sponsorship-requests and nobody cared about it in months.
> I am not familiar with the Android build system.
>
> Hans-Christoph has commented on the Salsa MR to possibly make Fab Stz the new 
> package maintainer.
>
> Thanks,
> Bastian
>
> On Wed, 15 Dec 2021 14:13:32 +0100 Fab Stz  wrote:
>  > I already sent an email on 21/Oct & 19/Nov to android-tools-
>  > de...@lists.alioth.debian.org, Roger Shimizu  concerning a
>  > merge request for that package. I haven't seen an anwser yet.
>  >
>  > Message was:
>  > Hello everybody,
>  >
>  > I updated the google-android-installers source package and created a merge
>  > request available here:
>  >
>  > 
> https://salsa.debian.org/android-tools-team/google-android-installers/-/merge_requests/3
>  >
>  > It automatically builds packages for almost all SDK components described in
>  > Google's https://dl.google.com/android/repository/repository2-1.xml
>  >
>  > Among the covered components there is: build-tools, platforms, 
> platform-tools,
>  > cmdline-tools, emulator, ndk, sources.
>  >
>  > Could you have a look and give any feedback please?
>  >
>  > Once merged & approved, this is ready to be reused with the other SDK
>  > repositories of Google. It will permit to create source packages for these
>  > components: sys-img, add-on, extras...