Bug#869277: /usr/bin/notify-send: Improve the manpage

[Pablo A B]

Now not even that link works. Galago Project doesn't exist anymore.
Last archive.org snapshot:
https://web.archive.org/web/20220422104829/https://www.galago-project.org/specs/notification/
Maybe should be replaced with
https://specifications.freedesktop.org/notification-spec/notification-spec-latest.html
as mention 
[here](https://gitlab.gnome.org/GNOME/libnotify/-/blob/master/README.md)

Bug#932090: firebird3.0: Please include patch to ensure correct sizes of on-disk structures

[John Paul Adrian Glaubitz]

Hi Damyan!

On 6/26/20 08:40, Damyan Ivanov wrote:
> Can you tell me where was the patch forwarded? I want to check whether 
> it is part of some upstream branch before applying it to the debian 
> package.

Patch and discussion can be found here [1].

However, it turns out that my approach is wrong and upstream has already used
a different approach for firebird4.0 [2], although I haven't tested that on
m68k yet.

Will test later.

Adrian

> [1] https://github.com/FirebirdSQL/firebird/pull/217
> [2] https://github.com/FirebirdSQL/firebird/pull/234/commits

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

Bug#1010876: firebird3.0: debian/rules clean fails due to debian/firebird-image directory

[John Paul Adrian Glaubitz]

Source: firebird3.0
Version: 3.0.9.33560.ds4-2
Severity: normal

Hello!

Running debian/rules clean fails with:

dpkg-buildpackage: error: failed to sign .buildinfo file
(sid_ppc64el-dchroot)glaubitz@plummer:~/firebird/firebird3.0-3.0.9.33560.ds4$ 
./debian/rules clean
dh clean --without autoreconf
   dh_auto_clean
make -j1 clean
make[1]: Entering directory 
'/home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4'
make -C gen clean
make[2]: Entering directory 
'/home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/gen'
rm -f `find /home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/temp// -type f 
-name '*.o' -print`
rm -f `find /home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/temp// -type f 
-name '*.a' -print`
rm -f `find /home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/temp// -type f 
-name '*.cpp' -print`
rm -f `find /home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/temp// -type f 
-name '*.pas' -print`
rm -f -f `find /home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/temp// -type 
f -name '*.d' -print`
rm -f `find /home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/extern/ -type f 
-name '*.lo' -print`
rm -f `find /home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/extern/ -type f 
-name '*.o' -print`
rm -f `find /home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/gen/*/firebird 
\( -type f -o -type l \) -print`
rm -f -f `find /home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/temp// -type 
f -name '*.cpp' -print`
rm -f *.fdb *.FDB msg.timestamp
rm -f yachts.lnk
rm -f `find /home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/gen/examples/ 
-type f ! -name 'Make*'`
rm -f /home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/src/dsql/parse.cpp 
/home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/src/dsql/dsql.tab.h
make -C /home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/extern/libtommath 
clean
make[3]: Entering directory 
'/home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/gen'
make[3]: *** 
/home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/extern/libtommath: No such 
file or directory.  Stop.
make[3]: Leaving directory 
'/home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/gen'
make[2]: [Makefile:711: clean_tommath] Error 2 (ignored)
make[2]: Leaving directory 
'/home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4/gen'
make[1]: Leaving directory '/home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4'
   debian/rules override_dh_clean
make[1]: Entering directory 
'/home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4'
dh_clean
rm: cannot remove './debian/firebird-image': Is a directory
dh_clean: error: rm -f -- debian/firebird3.0-server-core.substvars 
debian/firebird3.0-server.substvars 
debian/firebird3.0-server.postinst.debhelper 
debian/firebird3.0-server.postrm.debhelper 
debian/firebird3.0-server.preinst.debhelper 
debian/firebird3.0-server.prerm.debhelper debian/firebird3.0-utils.substvars 
debian/libfbclient2.substvars debian/libib-util.substvars 
debian/firebird3.0-common.substvars debian/firebird-dev.substvars 
debian/firebird3.0-examples.substvars debian/firebird3.0-doc.substvars 
debian/firebird3.0-common-doc.substvars ./Makefile ./aclocal.m4 
./builds/make.new/config/config.guess ./builds/make.new/config/config.h.in 
./builds/make.new/config/config.sub ./builds/make.new/config/install-sh 
./builds/make.new/config/ltmain.sh ./config.log ./config.log ./config.status 
./config.status ./configure ./configure ./debian/firebird-image 
./debian/man/fb_config.1 ./debian/man/fb_lock_print.1 ./debian/man/fbstat.1 
./debian/man/fbsvcmgr.1 ./debian/man/fbtracemgr.1 ./debian/man/gbak.1 
./debian/man/gfix.1 ./debian/man/gpre.1 ./debian/man/gsec.1 
./debian/man/isql-fb.1 ./debian/man/nbackup.1 ./debian/man/fbguard.8 
./debian/man/firebird.8 ./extern/btyacc/btyacc ./libtool 
./src/include/firebird/IdlFbInterfaces.h ./src/include/gen/Firebird.pas 
./src/include/gen/autoconfig.auto ./src/include/gen/autoconfig.h 
./src/include/gen/ids.h ./src/include/gen/parse.h debian/files returned exit 
code 1
make[1]: *** [debian/rules:153: override_dh_clean] Error 1
make[1]: Leaving directory '/home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4'
make: *** [debian/rules:7: clean] Error 2
(sid_ppc64el-dchroot)glaubitz@plummer:~/firebird/firebird3.0-3.0.9.33560.ds4$

This can be fixed by deleting the debian/firebird-image directory:

(sid_ppc64el-dchroot)glaubitz@plummer:~/firebird/firebird3.0-3.0.9.33560.ds4$ 
rm -rf debian/firebird-image/
(sid_ppc64el-dchroot)glaubitz@plummer:~/firebird/firebird3.0-3.0.9.33560.ds4$ 
./debian/rules clean
dh clean --without autoreconf
   debian/rules override_dh_clean
make[1]: Entering directory 
'/home/glaubitz/firebird/firebird3.0-3.0.9.33560.ds4'
dh_clean
rm -f debian/man/isql-fb.1 debian/man/gbak.1 debian/man/gfix.1 
debian/man/gpre.1 debian/man/gsec.1 debian/man/fbstat.1 debian/man/nbackup.1 
debian/man/fbsvcmgr.1 debian/man/fbtracemgr.1 debian/man/fb_lock_print.1 
debian/man/fb_config.1 debian/man/fbguard.8 debian/man/firebird.8
debconf-updatepo
FB_MAJOR = 3
FB_MINOR = 

Bug#1010875: ust: Bogus Build-Dependency makes package BD-Uninstallable on hppa

[John Paul Adrian Glaubitz]

Source: ust
Version: 2.13.2-1
Severity: normal
User: debian-h...@lists.debian.org
Usertags: hppa
X-Debbugs-Cc: debian-h...@lists.debian.org

Hello!

The package currently uses "" for disabling Java build dependencies
in debian/control [1]. However, this does not work as expected and makes the
package BD-Uninstallable on hppa [2].

The reason why it doesn't work as-is is because the buildds don't use any build
profiles. The proper way to do it would be to add "[!hppa]" to each Java build
dependency next to the "".

Thanks,
Adrian

> [1] https://salsa.debian.org/debian/ust/-/blob/debian/sid/debian/control
> [2] https://buildd.debian.org/status/package.php?p=ust=sid

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

Bug#1010874: ITP: jshn -- JSON parsing and generation library in for shell scripts

[Sergey Ponomarev]

Package: wnpp
Severity: wishlist

* Package name: jshn
  Version : 1.0.0
* URL : https://openwrt.org/docs/guide-developer/jshn
* License : ISC
  Programming Lang: C, Shell
  Description : jshn (JSON SHell Notation), a shell library and
utility for parsing and generating JSON.


OpenWrt actively uses shell scripts and JSON for configs and API. But
shell scripts don't have built-in functions to work with JSON or other
hierarchical structures so  provide a shell library jshn.sh that you
can import and use.

The tool is very handy and useful and I see that Debian lacks it out
of the box. In fact it can replace jq and many /sed/ magic in many
places.
I already created a fork that you can try yourself
https://github.com/stokito/jshn-jsonc

But I'm going to talk with OpenWrt devs to split the tool from the
libubox package and make compilation easy for Debian.

Regards,
Sergey Ponomarev






-- 
Sergey Ponomarev,
stokito.com

Bug#1010873: [RFP]: emailrelay -- SMTP email proxy and relay server

[Sergey Ponomarev]

Package: wnpp
Severity: wishlist

* Package name: emailrelay
  Version : 2.3.0
* URL : http://emailrelay.sourceforge.net/
* License : GPL-3.0
  Programming Lang: C
  Description : E-MailRelay does three things: it stores any
incoming email messages that it receives, it forwards email messages
on to another remote email server, and it serves up stored email
messages to local email reader programs. More technically, it acts as
a SMTP storage daemon, a SMTP forwarding agent, and a POP3 server.

OpenWrt has the package and it's used quite often.
But also this is an ideal solution for small office or home usage and
especially for Freedombox.

It takes about 1.4mb which is at least twice smaller than Postfix. But
more importantly it has a clear config and makes its usage more secure
especially for experienced users.
The program is very old, well tested, safe, stable and actively
maintained. It is even already debianized, we just need to put it into
repo.

This is a very important thing to make users more independant.

Regards,
Sergey Ponomarev

Bug#1008232: RFP: soapui -- API and web service testing tool

[Sergey Ponomarev]

As a Java developer I can tell that many of us used SoapUI a lot in
times when WebServices and WSDL was a de-facto standard for APIs.
Today Postman is mostly used for REST APIs but the SoapUI is still
powerful and even recently received a GraphQL support.
It's one of the main tools for QA automation. Similar to JMeter that
was already debianized.

I tried it now and the design remains the same :) But I hope they'll improve it.
It has quite annoying popups with ads to upgrade to a paid Pro plan
and ReadyAPI tool.

I think it worth adding. But not a top priority.

Regards,
Sergey Ponomarev

Bug#1010872: efax: reproducible-builds: differing buildid in /usr/bin/efax and /usr/bin/efix

[Vagrant Cascadian]

Source: efax
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Both /usr/bin/efax and /usr/bin/efix embed different buildids based on
the build path:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/efax.html

  Build·ID:·bbce73232e3a81a5db70703d12c5ce89ecf11d8d
  vs.
  Build·ID:·ec6d84e3221a010689b83ef8327769e2da58cd2d

The attached patch fixes this by passing -ffile-prefix-map via CFLAGS in
debian/rules to avoid embedding the absolute build paths in binaries.

Alternately, this might be solved by switching to using "dh" in
debian/rules, which should use the default values for CFLAGS from
dpkg-buildflags.


With these patches applied, efax should build reproducibly on
tests.reproducible-builds.org!


live well,
  vagrant
From 40dd43885c275b9e12d180fac692b47cdf4e8af9 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 12 May 2022 01:36:10 +
Subject: [PATCH] debian/rules: Set -ffile-prefix-map in CFLAGS.

https://tests.reproducible-builds.org/debian/issues/unstable/gcc_captures_build_path_issue.html
---
 debian/rules | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/debian/rules b/debian/rules
index a20babe..1351a73 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,6 +20,8 @@ else
 	CFLAGS += -O2
 endif
 
+# Avoid embedding build paths
+CFLAGS += -ffile-prefix-map=$(CURDIR)=.
 
 build: build-stamp
 
-- 
2.36.1



signature.asc
Description: PGP signature

Bug#1010871: dvbtune: reproducible-builds: embedded build paths in various binaries

[Vagrant Cascadian]

Source: dvbtune
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in /usr/bin/dvbtune and /usr/bin/xml2vdr:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/dvbtune.html

  /build/1st/dvbtune-0.5.ds/dvbtune.c:140
  vs.
  /build/2/dvbtune-0.5.ds/2nd/dvbtune.c:140

The attached patches fix this by modifying the upstream Makefile to
append EXTRA_CFLAGS to CFLAGS, and passing EXTRA_CFLAGS in debian/rules
in the dh_auto_build phase. This passes the default CFLAGS from
dpkg-buildflags, which includes the -ffile-prefix-map argument to avoid
embedding the absolute path in compiled files.


With these patches applied, dvbtune should build reproducibly on
tests.reproducible-builds.org!


live well,
  vagrant
From c041172edf70e46071bcff23ea35baa1688ea219 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 12 May 2022 00:38:57 +
Subject: [PATCH 1/3] debian/patches: Allow passing additional CFLAGS via
 EXTRA_CFLAGS to Makefile.

---
 ...kefile-allow-passing-additional-cflags.patch | 17 +
 debian/patches/series   |  1 +
 2 files changed, 18 insertions(+)
 create mode 100644 debian/patches/makefile-allow-passing-additional-cflags.patch

diff --git a/debian/patches/makefile-allow-passing-additional-cflags.patch b/debian/patches/makefile-allow-passing-additional-cflags.patch
new file mode 100644
index 000..5f569d7
--- /dev/null
+++ b/debian/patches/makefile-allow-passing-additional-cflags.patch
@@ -0,0 +1,17 @@
+From: Vagrant Cascadian 
+Date: Thu, 12 May 2022 00:34:59 +
+X-Dgit-Generated: 0.5.ds-4~20220512~0 b5ac71a0203370a76a210e7897ff0f70090741c4
+Subject: Makefile: Allow passing additional CFLAGS via EXTRA_CFLAGS.
+
+
+---
+
+--- dvbtune-0.5.ds.orig/Makefile
 dvbtune-0.5.ds/Makefile
+@@ -1,5 +1,5 @@
+ INCS=-I /usr/include/libxml2
+-CFLAGS= -g -Wall $(INCS) -DVERSION=\"$(VERSION)\"
++CFLAGS= -g -Wall $(INCS) -DVERSION=\"$(VERSION)\" $(EXTRA_CFLAGS)
+ CC=gcc
+ all: dvbtune
+ 
diff --git a/debian/patches/series b/debian/patches/series
index b5bb219..ebd13ad 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,3 +2,4 @@
 10_options.patch
 30_stdint.patch
 fix_debugbuild.patch
+makefile-allow-passing-additional-cflags.patch
-- 
2.30.2

From a89d2ffd48dfedaffaeeb96ce83520f59845a44e Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 12 May 2022 00:35:32 +
Subject: [PATCH 2/3] debian/rules: Pass CFLAGS as EXTRA_CFLAGS to
 dh_auto_build.

---
 debian/rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index 3e0c521..c675009 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,8 +7,8 @@ VERSION=0.5
 
 override_dh_auto_build:
 	dh_testdir
-	dh_auto_build -- VERSION=$(VERSION)
-	dh_auto_build -- VERSION=$(VERSION) xml2vdr
+	dh_auto_build -- VERSION=$(VERSION) EXTRA_CFLAGS="$(CFLAGS)"
+	dh_auto_build -- VERSION=$(VERSION) EXTRA_CFLAGS="$(CFLAGS)" xml2vdr
 	#rm -rf $(BUILD_DIR)/scripts/CVS
 	docbook-to-man debian/dvbtune.sgml > dvbtune.1
 	docbook-to-man debian/xml2vdr.sgml > xml2vdr.1
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1010839: debcontrol.vim: bad syntax highlighting for sections containing "/"

[James McCoy]

On Wed, May 11, 2022 at 11:27:22AM +0200, Jakub Wilk wrote:
> vim highlights this as an error:
> 
>   Section: non-free/utils
> 
> Removing "\<" from the "syn match debcontrolSection" line fixes it for me.

The problem is actually the "syn iskeyword" line.  There's no reason to
declare / a valid word character there.  Not sure why I did that, but I
guess we'll find out if there was a reason when I remove it. :)

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

Bug#1009425: prewikka: FTBFS: AttributeError: module 'collections' has no

[Adrian Bunk]

Control: reassign -1 python3-lesscpy 0.13.0+ds-2
Control: affects -1 src:prewikka
Control: forwarded -1 
https://github.com/lesscpy/lesscpy/commit/0bbcf058e9ca6715c73$

On Mon, May 09, 2022 at 12:33:01AM +0200, Thomas Andrejak wrote:
> On Sun, 8 May 2022 09:42:13 +0200 s3v  wrote:
> > Dear Maintainer,
> >
> > >   File "/usr/lib/python3/dist-packages/lesscpy/lessc/utility.py", line
> 28, in flatten
> > > if isinstance(elm, collections.Iterable) and not isinstance(elm,
> string_types):
> > > AttributeError: module 'collections' has no attribute 'Iterable'
> >
> > This issue belongs to python3-lesscpy and has been fixed upstream [1]
> 
> So I need to fix something or just wait python3-lesscpy to be fixed ?

You have to fix python3-lesscpy, since you are the maintainer of 
python3-lesscpy.

> Thanks for your help
>...

cu
Adrian

Bug#965571: gtans: diff for NMU version 1.99.0-2.1

[Adrian Bunk]

Control: tags 965571 + patch
Control: tags 965571 + pending

Dear maintainer,

I've prepared an NMU for gtans (versioned as 1.99.0-2.1) and
uploaded it to DELAYED/14. Please feel free to tell me if I
should cancel it.

cu
Adrian
diff -u gtans-1.99.0/debian/compat gtans-1.99.0/debian/compat
--- gtans-1.99.0/debian/compat
+++ gtans-1.99.0/debian/compat
@@ -1 +1 @@
-5
+7
diff -u gtans-1.99.0/debian/changelog gtans-1.99.0/debian/changelog
--- gtans-1.99.0/debian/changelog
+++ gtans-1.99.0/debian/changelog
@@ -1,3 +1,10 @@
+gtans (1.99.0-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * debian/compat: 5 -> 7. (Closes: #965571)
+
+ -- Adrian Bunk   Thu, 12 May 2022 01:32:19 +0300
+
 gtans (1.99.0-2) unstable; urgency=low
 
   * Added data/gtanshelpsv.txt and po/sv.po.  Closes: #621086.

Bug#1010870: pidgin-blinklight: reproducible-builds: embedded build paths in various binaries

[Vagrant Cascadian]

Source: pidgin-blinklight
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in /usr/lib/purple-2/pidgin-blinklight.so and
/usr/lib/pidgin-blinklight/blinklight-fixperm:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/pidgin-blinklight.html

  /build/1st/pidgin-blinklight-0.11.1/src/blinklight-fixperm.c:17
  vs.
  /build/2/pidgin-blinklight-0.11.1/2nd/src/blinklight-fixperm.c:17


The attached patch fixes this by updating to use debhelper compat level
13 and switching to use "dh" in debian/rules. This passes the default
CFLAGS from dpkg-buildflags, which includes the -ffile-prefix-map
argument to avoid embedding the absolute path in compiled files.


As a bonus, it should also fix https://bugs.debian.org/999100


With this patch applied, pidgin-blinklight should build reproducibly on
tests.reproducible-builds.org!


live well,
  vagrant
From f91a7064d8c34845db9495563a156c43e18ce3cc Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 11 May 2022 21:24:28 +
Subject: [PATCH 1/3] Convert to dh and debhelper-compat 13. (Closes: #999100)

---
 debian/compat  |  1 -
 debian/control |  2 +-
 debian/rules   | 99 +-
 3 files changed, 10 insertions(+), 92 deletions(-)
 delete mode 100644 debian/compat

diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index 7f8f011..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-7
diff --git a/debian/control b/debian/control
index 0d76a65..78b995b 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: pidgin-blinklight
 Section: net
 Priority: optional
 Maintainer: Debian QA Group 
-Build-Depends: debhelper (>= 7), autotools-dev, pidgin-dev, pkg-config
+Build-Depends: debhelper-compat (= 13), pidgin-dev, pkg-config
 Standards-Version: 3.8.3
 Vcs-Darcs: http://darcs.nomeata.de/pidgin-blinklight.debian
 Vcs-Browser: http://darcs.nomeata.de/cgi-bin/darcsweb.cgi?r=pidgin-blinklight.debian;a=summary
diff --git a/debian/rules b/debian/rules
index 7aa7503..a094b85 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,103 +1,22 @@
 #! /usr/bin/make -f
 # -*- makefile -*-
-# Sample debian/rules that uses debhelper.
-# This file was originally written by Joey Hess and Craig Small.
-# As a special exception, when this file is copied by dh-make into a
-# dh-make output file, you may use that output file without restriction.
-# This special exception was added by Craig Small in version 0.37 of dh-make.
 
-# Uncomment this to turn on verbose mode.
-#export DH_VERBOSE=1
+%:
+	dh $@
 
+override_dh_auto_configure:
+	dh_auto_configure -- CFLAGS="$(CFLAGS)" CC="$(CC)" CXX="$(CXX)" --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info --libexecdir=\$${prefix}/lib/pidgin-blinklight 
 
-# These are used for cross-compiling and for saving the configure script
-# from having to guess our platform (since we know it already)
-DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 
-CFLAGS = -Wall -g
-
-ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
-	CFLAGS += -O0
-else
-	CFLAGS += -O2
-endif
-
-ifeq (ccache,$(findstring ccache,$(DEB_BUILD_OPTIONS)))
-CC:=ccache $(CC)
-CXX:=ccache $(CXX)
-endif
-
-config.status: configure
-	dh_testdir
-	dh_autotools-dev_updateconfig
-	# Add here commands to configure the package.
-	CFLAGS="$(CFLAGS)" ./configure CC="$(CC)" CXX="$(CXX)" --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info --libexecdir=\$${prefix}/lib/pidgin-blinklight 
-
-
-build: build-stamp
-build-stamp:  config.status
-	dh_testdir
-
-	# Add here commands to compile the package.
-	$(MAKE)
-
-	touch build-stamp
-
-clean:
-	dh_testdir
-	dh_testroot
-	rm -f build-stamp 
-	
-	# Add here commands to clean up after the build process.
-	[ ! -f Makefile ] || $(MAKE) distclean
+override_dh_auto_clean:
+	dh_auto_clean
 	-rm -f po/*gmo po/stamp-po
-	dh_autotools-dev_restoreconfig
-	dh_clean 
 
-install: build
-	dh_testdir
-	dh_testroot
-	dh_prep 
-	dh_installdirs
-	
-	$(MAKE) install DESTDIR=$(CURDIR)/debian/pidgin-blinklight
+override_dh_auto_install:
+	dh_auto_install
 	rm -f $(CURDIR)/debian/pidgin-blinklight/usr/lib/purple-2/pidgin-blinklight.la
 
-	
-# Build architecture-independent files here.
-binary-indep: build install
-# We have nothing to do by default.
-
-# Build architecture-dependent files here.
-binary-arch: build install
-	dh_testdir
-	dh_testroot
-	dh_installchangelogs ChangeLog
-	dh_installdocs
-	dh_installexamples
-#	dh_install
-#	dh_installmenu
-#	dh_installdebconf	
-#	dh_installlogrotate
-#	dh_installemacsen
-#	dh_installpam
-#	dh_installmime
-#	dh_installinit
-#	

Bug#1010869: vagrant-libvirt: newer upstream version 0.8.2 fixes problem with private_ip on secondary interface

[Gabriel Filion]

Package: vagrant-libvirt
Version: 0.8.0-1
Severity: important

Hello,

Ever since I've upgraded vagrant-libvirt to 0.8.0, I've been having issues with
VMs that have a "private_ip" setup: their secondary IP is not brought up before
the puppet provisioning step, which means the puppet server can't be reached.

I checked through the recent changes upstream and I found this out which was
merged in before 0.8.1:

https://github.com/vagrant-libvirt/vagrant-libvirt/pull/1480/files

After applying the same changes to the "action.rb" file installed by the
package the private_ip issue is now gone.


So: could you please bump this package to the latest upstream version, 0.8.2, in
order to fix the issue described above?

I've set this to severity "important" since not everything is broken but the
issue related to private_ip breaks some workflows.


Cheers!


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

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

Versions of packages vagrant-libvirt depends on:
ii  libruby2.7 [ruby-rexml]  2.7.5-1
ii  libruby3.0 [ruby-rexml]  3.0.4-7
ii  ruby-fog-core2.1.0-3.1
ii  ruby-fog-libvirt 0.9.0-1
ii  ruby-nokogiri1.13.5+dfsg-2
ii  vagrant  2.2.19+dfsg-1

Versions of packages vagrant-libvirt recommends:
pn  libguestfs-tools   
ii  nfs-kernel-server  1:2.6.1-2
ii  qemu-utils 1:7.0+dfsg-6

vagrant-libvirt suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file 
/usr/share/rubygems-integration/all/gems/vagrant-libvirt-0.8.0/lib/vagrant-libvirt/action.rb
 (from vagrant-libvirt package)

Bug#991134: firefox: random connection failures

[Vincent Lefevre]

Control: found -1 100.0-1
Control: tags -1 upstream

as this may be the same bug as

  https://bugzilla.mozilla.org/show_bug.cgi?id=1640212

(when I mentioned missing CSS, this would be the same bug)
where non-Debian machines are affected.

However, I could reproduce the bug only with the Debian package.

On 2021-08-26 01:13:11 +0200, Vincent Lefevre wrote:
> On 2021-07-15 12:56:24 +0200, Vincent Lefevre wrote:
> > This has just happened when doing "Back": the HTML page
> > https://www.vinc17.net/ was displayed, but without the CSS, which
> > should have been in the cache (as being loaded a few minutes earlier).
> > After doing a reload, I got a connection error (still immediate).
> > A second reload worked.
> 
> This has occurred many times with pages under https://www.vinc17.net/
> but also with a page under https://lists.gnu.org/ (which I had visited
> 2-3 minutes earlier). This issue might occur only for pages that are
> already in the cache.

Upstream bug 1640212 also says that this is related to the cache.

And possibly also related to non-working IPv6, but only after an
unexplained issue with IPv4.

On 2022-05-11 14:45:27 +0200, Vincent Lefevre wrote:
> Note that I've tried upstream's tarball for a few weeks and couldn't
> reproduce the issue with it.
> 
> So either the bug is specific to Debian or it has disappeared
> (or I haven't tried long enough).
> 
> I'm now trying with Debian's package firefox 100.0-1.

and could reproduce it:

  https://bugzilla.mozilla.org/show_bug.cgi?id=1745150#c9

with logs.

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

Bug#1009079: mdtraj: diff for NMU version 1.9.7-3.1

[Adrian Bunk]

Control: tags 1009079 + patch
Control: tags 1009079 + pending

Dear maintainer,

I've prepared an NMU for mdtraj (versioned as 1.9.7-3.1) and
uploaded it to DELAYED/14. Please feel free to tell me if I
should cancel it.

cu
Adrian
diff -Nru mdtraj-1.9.7/debian/changelog mdtraj-1.9.7/debian/changelog
--- mdtraj-1.9.7/debian/changelog	2022-04-03 19:41:47.0 +0300
+++ mdtraj-1.9.7/debian/changelog	2022-05-11 23:49:37.0 +0300
@@ -1,3 +1,11 @@
+mdtraj (1.9.7-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/tests/control: Add Restrictions: needs-internet
+(Closes: #1009079)
+
+ -- Adrian Bunk   Wed, 11 May 2022 23:49:37 +0300
+
 mdtraj (1.9.7-3) unstable; urgency=medium
 
   * python3-mdtraj Depends: python3-astunparse
diff -Nru mdtraj-1.9.7/debian/tests/control mdtraj-1.9.7/debian/tests/control
--- mdtraj-1.9.7/debian/tests/control	2022-04-03 19:41:47.0 +0300
+++ mdtraj-1.9.7/debian/tests/control	2022-05-11 23:49:37.0 +0300
@@ -10,3 +10,4 @@
  python3-six,
  python3-sklearn
 Architecture: any-amd64 arm64 i386
+Restrictions: needs-internet

Bug#1010868: RFP: dovecot-fts-flatcurve -- Dovecot full text search plugin using the Xapian search engine

[Karl O. Pinc]

Package: wnpp
Severity: wishlist

* Package name: dovecot-fts-flatcurve
  Version : 0.3.0
* URL : https://github.com/slusarz/dovecot-fts-flatcurve
* License : LGPL 2.1
  Programming Lang: C, C++
  Description : Dovecot full text search plugin using the Xapian search 
engine

This is a Dovecot FTS plugin to enable message indexing using the
Xapian Open Source Search Engine Library.

This driver supports match scoring and substring matches, which means
it is RFC 3501 (IMAP4rev1) compliant (although substring searches are
off by default). This driver does not support fuzzy searches, as there
is no built-in support in Xapian for it.

Note that fts_flatcurve has been merged into dovecot core April 2022:
https://github.com/dovecot/core/commit/137572e77fdf79b2e8d607021667741ed3f19da1

It will be the default dovecot fts driver.  So this is probably
an issue for the dovecot team.

Bug#779877: /usr/bin/grub-mknetdir: grub-mknetdir and grub-mkrescue would work better if grub-*-bin packages were arch all

[Bastian Germann]

X-Debbugs-Cc: cezargaite...@protonmail.com

On Thu, 05 Mar 2015 14:30:19 -0700 Ben Hildred  wrote:

I am trying to set up a subnet to net boot computers of different designs. Some
use EFI, some are powerpc, some are old PCs. grub-efi-amd64-bin, grub-efi-
ia32-bin, and grub-pc-bin all install nicely. grub-ieee1275-bin insists on only
i386 which would be interesting if I had any machines to use it, but I would
prefer powerpc.

grub-efi-arm-bin, grub-efi-arm64-bin, grub-uboot-bin, and grub-yeeloong-bin
would also be useful.


The package molotov would also benefit from that.
Alternatively, you can mark the packages Multi-Arch: foreign.

Bug#1010837: CVE-2022-30333 (unrar file write vulnerability) patch not yet available for Debian 10 packages

[Stefano Rivera]

Hi Martin (2022.05.11_06:47:38_-0400)
> fixed 1010837 1:6.1.2-1

Going from the security tracker:
https://security-tracker.debian.org/tracker/CVE-2022-30333

> 6.12 application version corresponds to 6.1.7 source version:
> https://github.com/debian-calibre/unrar-nonfree/compare/upstream/6.1.6...upstream/6.1.7


So, that should probably be fixed in 1:6.1.7-1, not 1:6.1.2-1

SR

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

Bug#826044: Hangs in apt hook with a zombie - problem still exists in debian10

[Thomas Liske]

Hi,

you are using some ansible deployment? Could you share your ansible
role?

This is a long-standing bug and it feels like that affected users are
using aptitude. I wonder if this is related - could you give it a try
(force_apt_get task parameter)?


Regards,
Thomas


On Tue, 2022-05-10 at 18:00 +0900, zm5s-trnc wrote:
> Ho great...
> 
> Found out that there's the same trouble on some debian9 hosts.
> I say some because not all servers did the blockage.
> 
> 
> # cat /etc/debian_version
> 9.13
> # dpkg -l | grep needrestart
> ii  needrestart 2.11-3+deb9u1 all  check 
> which daemons need to be restarted after library upgrades
> 
> 
>    ├─sshd,2094
>    │   ├─sshd,24499
>    │   │   └─sh,24594 -c /usr/bin/python 
> /root/.ansible/tmp/ansible-tmp-1652172426.49-4195-
> 68636559789086/AnsiballZ_apt.py 
> && sleep 0
>    │   │   └─python,24595 
> /root/.ansible/tmp/ansible-tmp-1652172426.49-4195-
> 68636559789086/AnsiballZ_apt.py
>    │   │   └─aptitude,24910 -y -o 
> Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold 
> safe-upgrade
>    │   │   ├─aptitude,30264 -y -o 
> Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold 
> safe-upgrade
>    │   │   │   └─sh,30265 -c test -x 
> /usr/lib/needrestart/apt-pinvoke && /usr/lib/needrestart/apt-pinvoke
> || true
>    │   │   │   └─needrestart,30266
> /usr/sbin/needrestart
>    │   │   │   └─(10-dpkg,30299)
>    │   │   └─{aptitude},24914
> 

Bug#1007569: pfqueue: diff for NMU version 0.5.6-9.2

[Boyuan Yang]

Control: tags 1007569 + patch
Control: tags 1007569 + pending

Dear maintainer,

I've prepared an NMU for pfqueue (versioned as 0.5.6-9.2) and
uploaded it to DELAYED/14. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru pfqueue-0.5.6/debian/changelog pfqueue-0.5.6/debian/changelog
--- pfqueue-0.5.6/debian/changelog  2022-05-11 16:51:45.0 -0400
+++ pfqueue-0.5.6/debian/changelog  2022-05-11 16:48:26.0 -0400
@@ -1,3 +1,22 @@
+pfqueue (0.5.6-9.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control:
++ Replace transitional package dependency libncurses5-dev
+  with real package libncurses-dev.
++ Drop pfqueue-dbg package in favor of automatic -dbgsym package.
++ Bump Standards-Version to 4.6.0.
++ Bump debhelper compat to v13.
++ Mark library packages as Multi-Arch: same.
+  * debian/source/format: Use "3.0 (quilt)" format. (Closes: #1007569)
+  * debian/rules:
++ Rewrite in dh sequencer.
++ Do not install usr/lib/*.la files (lintian).
++ Enable full hardening.
++ Use dh_auto_configure for multiarch file installation.
+
+ -- Boyuan Yang   Wed, 11 May 2022 16:48:26 -0400
+
 pfqueue (0.5.6-9.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru pfqueue-0.5.6/debian/compat pfqueue-0.5.6/debian/compat
--- pfqueue-0.5.6/debian/compat 2022-05-11 16:51:45.0 -0400
+++ pfqueue-0.5.6/debian/compat 1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-7
diff -Nru pfqueue-0.5.6/debian/control pfqueue-0.5.6/debian/control
--- pfqueue-0.5.6/debian/control2022-05-11 16:51:45.0 -0400
+++ pfqueue-0.5.6/debian/control2022-05-11 16:48:25.0 -0400
@@ -2,8 +2,8 @@
 Section: mail
 Priority: optional
 Maintainer: Martin Zobel-Helas 
-Build-Depends: debhelper (>= 7), autotools-dev, libncurses5-dev, dh-
autoreconf
-Standards-Version: 3.8.3
+Build-Depends: debhelper-compat (= 13), libncurses-dev
+Standards-Version: 4.6.1
 Homepage: http://pfqueue.sourceforge.net/
 
 Package: pfqueue
@@ -14,20 +14,10 @@
  pfqueue is a queue manager for different MTAs (currently postfix and
exim),
  allowing to delete, hold, release, or requeue messages.
 
-Package: pfqueue-dbg
-Section: debug
-Priority: extra
-Architecture: any
-Depends: pfqueue (= ${binary:Version}), libpfqueue0 (= ${binary:Version}),
libpfqueue-dev (= ${binary:Version})
-Description: interactive console-based tool to control MTA queues (debug)
- pfqueue is a queue manager for different MTAs (currently postfix and
exim),
- allowing to delete, hold, release, or requeue messages.
- .
- This package contains the debugging symbols.
-
 Package: libpfqueue0
 Section: libs
 Architecture: any
+Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Recommends: pfqueue
 Description: interactive console-based tool to control MTA queues (library)
@@ -39,7 +29,8 @@
 Package: libpfqueue-dev
 Section: libdevel
 Architecture: any
-Depends: libpfqueue0 (= ${binary:Version}), libncurses5-dev
+Multi-Arch: same
+Depends: libpfqueue0 (= ${binary:Version}), libncurses-dev, ${misc:Depends}
 Description: interactive console-based tool to control MTA queues
(development)
  pfqueue is a queue manager for different MTAs (currently postfix and
exim),
  allowing to delete, hold, release, or requeue messages.
diff -Nru pfqueue-0.5.6/debian/libpfqueue0.install pfqueue-
0.5.6/debian/libpfqueue0.install
--- pfqueue-0.5.6/debian/libpfqueue0.install2022-05-11
16:51:45.0 -0400
+++ pfqueue-0.5.6/debian/libpfqueue0.install2022-05-11
16:46:52.0 -0400
@@ -1 +1 @@
-/usr/lib/*.so.*
+/usr/lib/*/*.so.*
diff -Nru pfqueue-0.5.6/debian/libpfqueue-dev.install pfqueue-
0.5.6/debian/libpfqueue-dev.install
--- pfqueue-0.5.6/debian/libpfqueue-dev.install 2022-05-11
16:51:45.0 -0400
+++ pfqueue-0.5.6/debian/libpfqueue-dev.install 2022-05-11
16:47:04.0 -0400
@@ -1,3 +1,2 @@
-/usr/lib/*.a
-/usr/lib/*.so
-/usr/lib/*.la
+/usr/lib/*/*.a
+/usr/lib/*/*.so
diff -Nru pfqueue-0.5.6/debian/rules pfqueue-0.5.6/debian/rules
--- pfqueue-0.5.6/debian/rules  2022-05-11 16:51:45.0 -0400
+++ pfqueue-0.5.6/debian/rules  2022-05-11 16:47:41.0 -0400
@@ -1,81 +1,28 @@
 #!/usr/bin/make -f
+# -*- makefile -*-
+# Uncomment this to turn on verbose mode.
+# export DH_VERBOSE=1
 
-DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
+# see FEATURE AREAS in dpkg-buildflags(1)
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
-ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))
-   CROSS=CC=$(DEB_HOST_GNU_TYPE)-gcc
-else
-   CROSS=
-endif
-
-clean:
-   dh_testdir
-   dh_testroot
-   rm -f build-stamp
-   rm -f config.guess config.sub
-
-   [ ! -f Makefile ] || $(MAKE) distclean
-   dh_autoreconf_clean
-   dh_clean
-
-config.status: configure
-   dh_testdir
-
-ifneq "$(wildcard /usr/share/misc/config.guess)" ""

Bug#1009794: Current version (1.5.2-1) doesn't work with Dovecot 2.3.18, please upgrade

[Adrian Bunk]

Control: retitle -1 dovecot-fts-xapian must depend on dovecot-abi-*
Control: found -1 1.4.9a-1

On Sun, Apr 17, 2022 at 07:45:55PM -0400, Sergio Durigan Junior wrote:
> Source: dovecot-fts-xapian
> Version: 1.5.2-1
> Severity: grave
> 
> Hello,
> 
> The current version of dovecot-fts-xapian doesn't work with Dovecot
> 2.3.18, currently in unstable/testing:
> 
> # doveadm index -A \*
> Fatal: Couldn't load required plugin 
> /usr/lib/dovecot/modules/lib21_fts_xapian_plugin.so: Module is for different 
> ABI version 2.3.ABIv16(2.3.16) (we have 2.3.ABIv18(2.3.18))

The actual problem is a missing dependency on dovecot-abi-*, similar to 
what dovecot-antispam already has.

> The latest upstream version (1.5.5) fixes this problem.

This problem can be "fixed" with a rebuild, and the rebuild of 1.5.2 for 
libicu71 has already "fixed" it in unstable.

Upgrading to the latest upstream version might also be a good idea,
but that's unrelated.

> Thanks,

cu
Adrian

Bug#1010469: Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment

[Julian Gilbey]

On Wed, May 11, 2022 at 03:03:54PM -0300, Antonio Terceiro wrote:
> On Fri, May 06, 2022 at 07:08:23PM +0100, Julian Gilbey wrote:
> [...]
> > I've no idea if that is of any help.
> 
> I could not find anything wrong in those. I'm sorry but I don't know
> what's wrong with your system. can you debug to check what is the exact
> point where it fails to start a container?

Thanks Antonio!

Here's a log file with logpriority at DEBUG; I've no idea if this will
help.  I'm so stumped.  I wondered if it was perhaps some extra kernel
modules (using dkms) causing the problem, so I've purged those and
rebooted, but it didn't help.

Something seems to be confused with the cgroups.  Here's the result of
mount | grep cgroup:
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/cgroup/net_cls type cgroup (rw,relatime,net_cls)

And ls /sys/fs/cgroup gives:

cgroup.controllers  dev-hugepages.mount  misc.capacity
cgroup.max.depthdev-mqueue.mount net_cls
cgroup.max.descendants  init.scope   proc-fs-nfsd.mount
cgroup.procsio.cost.modelproc-sys-fs-binfmt_misc.mount
cgroup.stat io.cost.qos  sys-fs-fuse-connections.mount
cgroup.subtree_control  io.pressure  sys-kernel-config.mount
cgroup.threads  io.stat  sys-kernel-debug.mount
cpu.pressurelxc.pivotsys-kernel-tracing.mount
cpuset.cpus.effective   memory.numa_stat system.slice
cpuset.mems.effective   memory.pressure  user.slice
cpu.statmemory.stat

Ho hum :-/

   Julian


lxc-start debian-unstable-trial 20220511204109.279 INFO lxccontainer - 
lxccontainer.c:do_lxcapi_start:987 - Set process title to [lxc monitor] 
/var/lib/lxc debian-unstable-trial
lxc-start debian-unstable-trial 20220511204109.280 DEBUGlxccontainer - 
lxccontainer.c:wait_on_daemonized_start:848 - First child 502040 exited
lxc-start debian-unstable-trial 20220511204109.280 INFO lsm - 
lsm/lsm.c:lsm_init_static:38 - Initialized LSM security driver AppArmor
lxc-start debian-unstable-trial 20220511204109.281 DEBUGseccomp - 
seccomp.c:parse_config_v2:656 - Host native arch is [3221225534]
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:parse_config_v2:807 - Processing "reject_force_umount  # comment this 
to allow umount -f;  not recommended"
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:do_resolve_add_rule:524 - Set seccomp rule to reject force umounts
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:do_resolve_add_rule:524 - Set seccomp rule to reject force umounts
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:do_resolve_add_rule:524 - Set seccomp rule to reject force umounts
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:parse_config_v2:807 - Processing "[all]"
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:parse_config_v2:807 - Processing "kexec_load errno 1"
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:do_resolve_add_rule:564 - Adding native rule for 
syscall[246:kexec_load] action[327681:errno] arch[0]
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:do_resolve_add_rule:564 - Adding compat rule for 
syscall[246:kexec_load] action[327681:errno] arch[1073741827]
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:do_resolve_add_rule:564 - Adding compat rule for 
syscall[246:kexec_load] action[327681:errno] arch[1073741886]
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:parse_config_v2:807 - Processing "open_by_handle_at errno 1"
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:do_resolve_add_rule:564 - Adding native rule for 
syscall[304:open_by_handle_at] action[327681:errno] arch[0]
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:do_resolve_add_rule:564 - Adding compat rule for 
syscall[304:open_by_handle_at] action[327681:errno] arch[1073741827]
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:do_resolve_add_rule:564 - Adding compat rule for 
syscall[304:open_by_handle_at] action[327681:errno] arch[1073741886]
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:parse_config_v2:807 - Processing "init_module errno 1"
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:do_resolve_add_rule:564 - Adding native rule for 
syscall[175:init_module] action[327681:errno] arch[0]
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 
seccomp.c:do_resolve_add_rule:564 - Adding compat rule for 
syscall[175:init_module] action[327681:errno] arch[1073741827]
lxc-start debian-unstable-trial 20220511204109.281 INFO seccomp - 

Bug#1010848: RFS: imwheel/1.0.0pre12-15 [ITA] -- add support to non-standard buttons on mouse in Linux

[Bastian Germann]

On Wed, 11 May 2022 14:06:05 + Chin Ah Toh  wrote:

Changes since the last upload:

 imwheel (1.0.0pre12-15) unstable; urgency=medium
 .
   * debian/control: Updated maintainer (Closes: #766979)
   * debian/copyright: Added to debian copyright list


You should really accomplish some more things on adopting the package so the sponsor can be convinced that you are going 
to care for it. Just replacing the maintainer field does not quite cut it.


Did you have a look at #260091? That bug seems to be a good one to address.

Bug#1010843: Bash completion filename conflict with LXD

[Antonio Terceiro]

Control: forwarded -1 https://github.com/lxc/lxc/pull/4115
Control: tag -1 + upstream confirmed

On Wed, May 11, 2022 at 11:20:37AM +, Mathias Gibbens wrote:
> Source: lxc
> Version: 1:4.0.11-1
> 
> Hi,
> 
>   While reviewing the LXD packaging I've been working on, it was
> noticed [1] that the bash completion file that's being shipped needs to
> be renamed. Since the LXD client executable is `lxc`, the installed
> path would be /usr/share/bash-completion/completions/lxc. However, that
> conflicts with a file installed by the lxc package [2]. From d/rules
> [3] it looks like symlinks are made of the actual lxc command names
> (`lxc-*`) to the supplied completions file.
> 
>   Would it be possible to rename how that base file is named when it is
> installed to /usr/share/bash-completion/completions/, so it won't
> conflict if LXD installs its bash completion in the correction
> location?

It turns out that that portion of our debian/rules is deprecated as that
is already handled by the upstream build system. This needs an upsteam
change, which I submitted in the link above.


signature.asc
Description: PGP signature

Bug#1009998: gvfs-backends: Unable to access smb://host/sharing on any file manager after upgrade

[jim_p]

Package: gvfs-backends
Version: 1.50.1-1
Followup-For: Bug #1009998
X-Debbugs-Cc: pitsior...@outlook.com

So, I was hoping that yesterday's update to 1.50.1 (in testing) would solve the
issue, but nothing changed. Likewise, it was not solved with today's upgrade
for samba (in unstable) to 4.16.1+dfsg-4.
On the other hand, the relevant issue on arch's bug tracker
(https://bugs.archlinux.org/task/74259) was closed with this patch here.
https://gitlab.com/samba-
team/samba/-/commit/34771e1931587807d0395c7ac7f4be18654997f4

How about getting this patch for debian too?


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

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

Versions of packages gvfs-backends depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  gvfs 1.50.1-1
ii  gvfs-common  1.50.1-1
ii  gvfs-daemons 1.50.1-1
ii  gvfs-libs1.50.1-1
ii  libarchive13 3.6.0-1
ii  libavahi-client3 0.8-5
ii  libavahi-common3 0.8-5
ii  libavahi-glib1   0.8-5
ii  libc62.33-7
ii  libcdio-cdda210.2+2.0.1-dmo1
ii  libcdio-paranoia210.2+2.0.1-dmo1
ii  libcdio191:2.1.0-dmo3
ii  libgcrypt20  1.10.1-2
ii  libgdata22   0.18.1-2
ii  libglib2.0-0 2.72.1-1
ii  libgoa-1.0-0b3.44.0-1
ii  libgphoto2-6 2.5.27-1
ii  libgphoto2-port122.5.27-1
ii  libgudev-1.0-0   237-2
ii  libimobiledevice61.3.0-6+b1
ii  libmtp9  1.1.19-1
ii  libnfs13 1:4.0.0-dmo1
ii  libplist32.2.0-6+b1
ii  libpolkit-gobject-1-00.105-33
ii  libsmbclient 2:4.16.1+dfsg-3
ii  libsoup-3.0-03.0.6-1
ii  libusb-1.0-0 2:1.0.26-1
ii  libxml2  2.9.14+dfsg-1
ii  psmisc   23.4-2

Versions of packages gvfs-backends recommends:
ii  gnome-keyring  40.0-3

Versions of packages gvfs-backends suggests:
pn  bluez-obexd   
ii  samba-common  2:4.16.1+dfsg-3

-- no debconf information

Bug#1009037: pivy: diff for NMU version 0.6.7-0.1

[Adrian Bunk]

Control: tags 1009037 + patch
Control: tags 1009037 + pending

Dear maintainer,

I've prepared an NMU for pivy (versioned as 0.6.7-0.1) and
uploaded it to DELAYED/14. Please feel free to tell me if I
should cancel it.

cu
Adrian
diff -Nru pivy-0.6.5/CMakeLists.txt pivy-0.6.7/CMakeLists.txt
--- pivy-0.6.5/CMakeLists.txt	2020-01-12 23:51:59.0 +0200
+++ pivy-0.6.7/CMakeLists.txt	2022-04-28 12:54:45.0 +0300
@@ -1,29 +1,47 @@
-project(pivy_cmake_setup NONE)
-cmake_minimum_required(VERSION 3.5)
+cmake_minimum_required(VERSION 3.14)
+project(pivy)
 
 
-find_package(Coin CONFIG REQUIRED)
-
-if (Coin_INCLUDE_DIR)
-MESSAGE(STATUS "COIN_FOUND: true")
-else()
-MESSAGE(STATUS "COIN_FOUND: false")
-endif()
+option(DISABLE_SWIG_WARNINGS "if on no swig warnings are shown" OFF)
 
-MESSAGE(STATUS "COIN_INCLUDE_DIR: ${Coin_INCLUDE_DIR}")
-MESSAGE(STATUS "COIN_LIB_DIR: ${Coin_LIB_DIR}")
-MESSAGE(STATUS "COIN_VERSION: ${Coin_VERSION}")
+find_package(SWIG 4.0.0 REQUIRED)
+include(${SWIG_USE_FILE})
 
+find_package(Coin CONFIG REQUIRED)
+find_package(SoQt CONFIG)
 
+if (SoQt_FOUND)
+find_package(Qt5 COMPONENTS Core Widgets Gui REQUIRED)
+endif()
 
-find_package(soqt CONFIG QUIET)
+find_package(Python REQUIRED COMPONENTS Interpreter Development)
 
-if (SoQt_INCLUDE_DIRS)
-MESSAGE(STATUS "SOQT_FOUND: true")
-else()
-MESSAGE(STATUS "SOQT_FOUND: false")
-endif()
+# SWIGIFY HEADERS
+# doing this with the origin python functions
 
-MESSAGE(STATUS "SOQT_INCLUDE_DIR: ${SoQt_INCLUDE_DIRS}")
-MESSAGE(STATUS "SOQT_LIB_DIR: ${SoQt_LIBRARY_DIRS}")
-MESSAGE(STATUS "SOQT_VERSION: ${SoQt_VERSION}")
+execute_process(COMMAND ${Python_EXECUTABLE} -c
+"import sys; sys.path.append('${CMAKE_SOURCE_DIR}'); \
+import install_helpers; install_helpers.swigify('${CMAKE_SOURCE_DIR}', '${Coin_INCLUDE_DIR}');")
+
+
+# copy the python module
+include(TargetCopyFiles.cmake)
+
+add_custom_target(pivy ALL)
+add_copy_directory(pivy ${CMAKE_SOURCE_DIR}/pivy
+DESTINATION ${CMAKE_BINARY_DIR}/pivy
+PATTERN *.py
+)
+
+add_subdirectory(interfaces)
+
+install(DIRECTORY
+${CMAKE_BINARY_DIR}/pivy
+DESTINATION ${Python_SITEARCH}
+FILES_MATCHING
+PATTERN "*.py"
+PATTERN "*.so"
+PATTERN "*.dylib"
+PATTERN "*.dll"
+PATTERN "*.pyd"
+)
diff -Nru pivy-0.6.5/debian/changelog pivy-0.6.7/debian/changelog
--- pivy-0.6.5/debian/changelog	2020-01-28 04:37:31.0 +0200
+++ pivy-0.6.7/debian/changelog	2022-05-11 22:08:30.0 +0300
@@ -1,3 +1,11 @@
+pivy (0.6.7-0.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * New upstream release.
+- Improved Python 3.10 compatibility. (Closes: #1009037)
+
+ -- Adrian Bunk   Wed, 11 May 2022 22:08:30 +0300
+
 pivy (0.6.5-1) unstable; urgency=medium
 
   * [2ac31f3] Remove upstreamed patches (all)
diff -Nru pivy-0.6.5/distutils_cmake/CMakeLists.txt pivy-0.6.7/distutils_cmake/CMakeLists.txt
--- pivy-0.6.5/distutils_cmake/CMakeLists.txt	1970-01-01 02:00:00.0 +0200
+++ pivy-0.6.7/distutils_cmake/CMakeLists.txt	2022-04-28 12:54:45.0 +0300
@@ -0,0 +1,22 @@
+cmake_minimum_required(VERSION 3.5)
+project(pivy_cmake_setup NONE)
+
+
+find_package(Coin CONFIG REQUIRED)
+
+if (Coin_FOUND)
+	MESSAGE(STATUS "COIN_FOUND: TRUE")
+	MESSAGE(STATUS "COIN_INCLUDE_DIR: ${Coin_INCLUDE_DIR}")
+	MESSAGE(STATUS "COIN_LIB_DIR: ${Coin_LIB_DIR}")
+	MESSAGE(STATUS "COIN_VERSION: ${Coin_VERSION}")
+endif()
+
+
+find_package(SoQt CONFIG)
+
+if (SoQt_FOUND)
+	MESSAGE(STATUS "SOQT_FOUND: True")
+	MESSAGE(STATUS "SOQT_INCLUDE_DIR: ${SoQt_INCLUDE_DIRS}")
+	MESSAGE(STATUS "SOQT_LIB_DIR: ${SoQt_LIBRARY_DIRS}")
+	MESSAGE(STATUS "SOQT_VERSION: ${SoQt_VERSION}")
+endif()
diff -Nru pivy-0.6.5/examples/contrib/iv2pov.py pivy-0.6.7/examples/contrib/iv2pov.py
--- pivy-0.6.5/examples/contrib/iv2pov.py	2020-01-12 23:51:59.0 +0200
+++ pivy-0.6.7/examples/contrib/iv2pov.py	2022-04-28 12:54:45.0 +0300
@@ -28,7 +28,7 @@
 ##  * Better camera support
 ##  * Search graph for lights or cameras BEFORE processing. Add
 ##if missing.
-##  * Better material handeling
+##  * Better material handling
 ##  * Make it into a library?
 ##
 
diff -Nru pivy-0.6.5/examples/examiner_embed4.py pivy-0.6.7/examples/examiner_embed4.py
--- pivy-0.6.5/examples/examiner_embed4.py	2020-01-12 23:51:59.0 +0200
+++ pivy-0.6.7/examples/examiner_embed4.py	2022-04-28 12:54:45.0 +0300
@@ -26,7 +26,10 @@
 from pivy.coin import *
 from pivy.gui.soqt import *
 
-from PySide2.QtGui import *
+try:
+from PySide2.QtWidgets import *
+except ImportError:
+from PySide2.QtGui import *
 from PySide2.QtCore import *
 
 class EmbeddedWindow(QMainWindow):
diff -Nru pivy-0.6.5/examples/Mentor/07.2.TextureCoordinates.py pivy-0.6.7/examples/Mentor/07.2.TextureCoordinates.py
--- pivy-0.6.5/examples/Mentor/07.2.TextureCoordinates.py	2020-01-12 23:51:59.0 +0200
+++ pivy-0.6.7/examples/Mentor/07.2.TextureCoordinates.py	2022-04-28 12:54:45.0 +0300
@@ -20,7 +20,7 @@
 # This is 

Bug#1006568: rauc: FTBFS with OpenSSL 3.0

[Sebastian Andrzej Siewior]

On 2022-05-11 17:58:22 [+0200], Uwe Kleine-König wrote:
> I just confirmed that. I built libp11 in sid + openssl3. With the
> resulting packages installed rauc just builds fine against openssl3.
> 
> So I'm unsure what I should do about this bug. Close it? Reassign to
> libp11? Just wait until it resolves itself?

If that the case, then the package will build fine if the binNMUs happen
in the right order. In that case, feel free to close the bug.

Thank you for checking.

> Best regards
> Uwe

Sebastian

Bug#1010867: why3 breaks frama-c autopkgtest: undefined symbol: camlWhy3__Env__fun_3995"

[Paul Gevers]

Source: why3, frama-c
Control: found -1 why3/1.5.0-1
Control: found -1 frama-c/20211203-chromium-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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


   passfail
why3   from testing1.5.0-1
frama-cfrom testing20211203-chromium-1
all others from testingfrom testing

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

Currently this regression is blocking the migration of why3 to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


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

Paul

[1] https://qa.debian.org/excuses.php?package=why3

https://ci.debian.net/data/autopkgtest/testing/amd64/f/frama-c/21530048/log.gz

[kernel] User Error: cannot load plug-in 'frama-c-wp': cannot load module
  Details: error loading shared library: Dynlink error: error loading 
shared library: Failure("/usr/lib/frama-c/plugins/top/Wp.cmxs: undefined 
symbol: camlWhy3__Env__fun_3995")
[kernel] User Error: Deferred error message was emitted during 
execution. See above messages for more information.

[kernel] Frama-C aborted: invalid user input.
autopkgtest [05:10:25]: test eva



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010865: RFS: opencpn/5.6.2+dfsg-1~bpo11+2 -- Open Source Chartplotter and Marine GPS Navigation Software

[Alec Leamas]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: opencpn
   Version : 5.6.2+dfsg-1~bpo11+2
   Upstream Author : Dave S. Register 
 * URL : https://opencpn.org
 * License : GPL-2+, GPL-3+, wxWidgets, Expat or GPL-2+, 
SGI-B-1.1, GPL-3, Expat, SGI-B-2.0, LGPL-2+, public-domain, BSD-3-clause

 * Vcs : https://gitlab.com/leamas/opencpn
   Section : misc

The source builds two binary packages:

  opencpn - Open Source Chartplotter and Marine GPS Navigation Software
  opencpn-data - Open Source Chartplotter and Marine GPS Navigation 
Software (data)


More info on  https://mentors.debian.net/package/opencpn/ or using

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opencpn/opencpn_5.6.2+dfsg-1~bpo11+2.dsc


This is a pretty urgent bugfix release for the existing Bullseye 
backport. Changes since the last upload:


 opencpn (5.6.2+dfsg-1~bpo11+2) bullseye-backports; urgency=medium
 .
   * Add patch fur unusable buildd version. Closes: #1010860

Regards,
--
  Alec Leamas

Bug#1010864: node-chokidar: flaky autopkgtest on most architectures:

[Paul Gevers]

Source: node-chokidar
Version: 3.4.3-3
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of you package on ppc64el 
because it was showing up as a regression for the upload of nodejs. I 
noticed that the test regularly fails and I saw failures on other 
architectures too (but not on amd64).


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

Don't hesitate to reach out if you need help and some more information
from our infrastructure.

Paul

https://ci.debian.net/packages/n/node-chokidar/testing/ppc64el/

https://ci.debian.net/data/autopkgtest/testing/ppc64el/n/node-chokidar/21552316/log.gz

  214 passing (1m)
  12 pending
  1 failing

  1) chokidar
   fs.watch (non-polling)
 watch a directory
   should emit `add`, not `change`, when previously deleted 
file is re-added:

 AssertionError: expected change to not have been called
  at Context. (test.js:301:38)
  at processTicksAndRejections (node:internal/process/task_queues:96:5)

https://ci.debian.net/data/autopkgtest/testing/ppc64el/n/node-chokidar/20264730/log.gz

  213 passing (1m)
  12 pending
  2 failing

  1) chokidar
   fs.watch (non-polling)
 watch options
   awaitWriteFinish
 should emit an unlink event when a file is updated and 
deleted just after that:
 AssertionError: expected spy to not have been called with 
arguments 'change', 'add.txt'

  at Context. (test.js:1590:34)
  at runMicrotasks ()
  at processTicksAndRejections (internal/process/task_queues.js:97:5)

  2) chokidar
   fs.watchFile (polling)
 watch options
   awaitWriteFinish
 should emit an unlink event when a file is updated and 
deleted just after that:
 AssertionError: expected spy to not have been called with 
arguments 'change', 'add.txt'

  at Context. (test.js:1590:34)
  at runMicrotasks ()
  at processTicksAndRejections (internal/process/task_queues.js:97:5)

https://ci.debian.net/data/autopkgtest/testing/ppc64el/n/node-chokidar/20267086/log.gz

  214 passing (1m)
  12 pending
  1 failing

  1) chokidar
   fs.watch (non-polling)
 watch options
   awaitWriteFinish
 should emit an unlink event when a file is updated and 
deleted just after that:
 AssertionError: expected spy to not have been called with 
arguments 'change', 'add.txt'

  at Context. (test.js:1590:34)
  at runMicrotasks ()
  at processTicksAndRejections (internal/process/task_queues.js:95:5)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#986590: Severity

[Anton Gladky]

severity 986590 important
thanks

I have temporarily disabled the unreliable test. Thus I am reducing
the bug's severity.
Yes, I know, it is wrong to disable a failing test. But I am
continuing to work on it, trying
to build it with threadsanitizer and check, what is going on there.

Any help is appreciated/

Thanks

Anton

Bug#1010863: streamlink: Broken audio timestamps on arte.tv

[Markus Demleitner]

Package: streamlink
Version: 3.2.0-1~bpo11+1
Severity: normal

Dear Maintainer,

When pulling video from arte, e.g.,

streamlink --output o.mp4 \
  https://www.arte.tv/de/videos/108210-039-A/mit-offenen-karten-im-fokus/ \
  worst

the audio timestamps for the resulting video file are broken for me (since
fairly recently), which leads to various failures in different clients (mpv has
seconds of hanging videos, vlc has stutters, webkit goes all haywire).

Upstream says it's not a streamlink problem, 
https://github.com/streamlink/streamlink/issues/4520;
I've suspected ffmpeg and so backported ffmpeg 4.4 -- to no avail.
I've also tried a uupdated streamlink 4 -- same result, broken
timestamps.

So... while I don't doubt upstream's analysis that it's not a streamlink
bug per se that's causing the bad timestamps, I don't know what else is.
I'm grateful for hints on what that might be -- and reports on whether
other people see the broken timestamps, too.

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

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

Versions of packages streamlink depends on:
ii  python3 3.9.2-3
ii  python3-streamlink  3.2.0-1~bpo11+1

Versions of packages streamlink recommends:
ii  mpv  0.32.0-3
ii  vlc  3.0.16-1

streamlink suggests no packages.

-- no debconf information

Bug#1010862: src:pysph: fails to migrate to testing for too long: new build dependency not available on ppc64el and s390x

[Paul Gevers]

Source: pysph
Version: 1.0~b0~20191115.gite3d5e10-6
Severity: serious
Control: close -1 1.0~b1-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:pysph has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. I think the situation is as 
follows. Your package needed a new build dependency. That B-D isn't 
available on all architectures, including some where your package 
successfully built in the past. You'll have to request the FTP-master to 
remove the binaries from those architectures. I recommend using 
reportbug to file the right bug report against the ftp.debian.org pseudo 
package.


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


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


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


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


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=pysph



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1007717: Draft resolution for "Native source package format with non-native version"

[Ian Jackson]

Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source 
package format with non-native version""):
> On 11/05/22 at 17:29 +0100, Ian Jackson wrote:
> > But I think that might not meet ftpmaster's review needs.  AIUI
> > ftpmaster like to review the diff qua diff, and a tarball isn't so
> > straightforward.  I had a similar idea to use an rsync batchfile as
> > the delta, which foundered on the same issue.
> 
> Note that it's not worse than using native formats, where ftpmasters get
> a single tarball anyway...

Indeed.  But I don't necessarily expect to be able to predict what
ftpmaster (or, for that matter, the dpkg maintainers) will like.

Thanks for exploring the design space!  What would be really good
would be to get agreement in principle from the key stakeholders...

Ian.

-- 
Ian JacksonThese opinions are my own.  

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

Bug#1007717: Draft resolution for "Native source package format with non-native version"

[Lucas Nussbaum]

On 11/05/22 at 17:29 +0100, Ian Jackson wrote:
> Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source 
> package format with non-native version""):
> > Out of curiosity, if 3.0 (native) supported multiple tarballs, wouldn't
> > it be a good solution?
> 
> Oh, I hadn't thought of that.
> 
> > The main limitation I see is that it would not allow to represent
> > efficiently small changes to large text files (which a git-based diff
> > would allow).
> 
> That may not be important.  My feeling is that it wouldn't be.
> 
> However, I think there are some other difficulties with this idea.
> 
> *Deletion* of files *is* important.  Something would have to be done
> to support that.  (Tarball repacking is an abominable workflow which
> we should only do when we must.)
> 
> It is important that packing and unpacking these things works roughly
> the same way that things work right now for the diffish formats.  Ie,
> for a package with two tarballs, the first tarball would have to omit
> the Debian revision from its filename (so that it needn't be
> re-uploaded), and the second tarball would have to *contain* it.
> dpkg-source -b would have to calculate the appropriate second tarball
> as a diff from the first.  (GNU tar has an incremental option that
> could perhaps be used.)
> 
> I think, having followed this line of throught, the result looks quite
> like a "3.0 (diff)" only the diff is in the form of an incremental
> tarball rather than a textual patch file.
> 
> This could definitely work.

FWIW, GNU tar's incremental mode supports file deletions.

Example:
-->8
# create a first archive
mkdir t
echo foo > t/f1
echo bar > t/f2
echo baz > t/f3
tar --listed-increment=snapshot-file -czvvvf archive.tgz t
# remove a file, create an incremental archive
rm t/f2
tar --listed-increment=snapshot-file -czvvvf archive.1.tgz t

# remove everything
rm -rf snapshot-file t
# extract incremental archives
tar Gvvvxf archive.tgz
tar Gvvvxf archive.1.tgz

# listing of archive.1.tgz
tar Gvvvtf archive.1.tgz
-->8

This is implemented using the GNU-specific D entry type. According to
https://www.freebsd.org/cgi/man.cgi?query=tar=0=5=html :

  D  This indicates a directory entry. Unlike the POSIX-stan-
 dard "5" typeflag, the header is followed by data records
 listing the names of files in this directory.  Each name
 is preceded by an ASCII "Y" if the file is stored in this
 archive or "N" if the file is not stored in this archive.
 Each name is terminated with a null, and an extra null
 marks the end of the name list.  The purpose of this en-
 try is to support incremental backups; a program restor-
 ing from such an archive may wish to delete files on disk
 that did not exist in the directory when the archive was
 made.

 Note that the "D" typeflag specifically violates POSIX,
 which requires that unrecognized typeflags be restored as
 normal files.  In this case, restoring the "D" entry as a
 file could interfere with subsequent creation of the
 like-named directory.

> But I think that might not meet ftpmaster's review needs.  AIUI
> ftpmaster like to review the diff qua diff, and a tarball isn't so
> straightforward.  I had a similar idea to use an rsync batchfile as
> the delta, which foundered on the same issue.

Note that it's not worse than using native formats, where ftpmasters get
a single tarball anyway...

Lucas

Bug#1010861: ITS: uqm, uqm-content

[Stephen Kitt]

Package: uqm
Severity: important
X-Debbugs-Cc: Dmitry E. Oboukhov , Matija Nalis 


Dear Maintainer,

uqm has been updated through NMUs (seven) since 2015, and hasn’t seen
a maintainer upload since 2009. It has had a couple of upstream
releases since then, with a bug open since 2011 requesting an update
(#640881).

Accordingly, I intend to help Matija Nalis salvage this package along
with related packages (at least uqm-content), within the Debian Games
team (which is where the package VCSs are already hosted). Merge
requests updating the package are already available on
https://salsa.debian.org/games-team/uqm-content/-/merge_requests and
https://salsa.debian.org/games-team/uqm/-/merge_requests

The packages would then list the Games team as their maintainer, with
yourself (if you wish), Matija and me as uploaders.

Regards,

Stephen

Bug#1009617: mailscripts: new script to reinject a message via sendmail: sendmail-reinject

[Sean Whitton]

Hello Jameson,

On Tue 12 Apr 2022 at 03:17PM -07, Jameson Graef Rollins wrote:

> Package: mailscripts
> Version: 0.24-1
> Severity: wishlist
> Tags: patch
>
> Attached is a patch (via git format-patch) for a script to re-inject
> an existing message via sendmail.  The script extracts the sender and
> all recipients from the message and constructs the appropriate
> sendmail command to re-send the message.  This is very useful for
> messages that were fcc'd but for some reason failed to make it out on
> an initial pass (e.g. MTA misconfiguration).  A man page is also
> included.

Cool, I'd like to add this.  Just two questions

- what license are you releasing it under?  please add the usual
  copyright and license headers and update d/copyright

- how about renaming --id to --notmuch-id or --notmuch-message-id ?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1010860: Wrong plugin compatibility setting

[Alec Leamas]

Package: opencpn
Version: 5.6.2+dfsg-1~bpo11+1

The plugin compatibility version should be 11, but is actually 
buildd-unstable. This make plugins invisible.


Upstream bug: https://github.com/OpenCPN/OpenCPN/discussions/26780

Bug#1010849: DWARF support disabled during build / no symbolic stack traces or argument types

[Vincent Bernat]

 ❦ 11 May 2022 16:00 +02, Harald Welte:

> It seems the Debian bpftrace is built without libdw support.  This means no 
> stack
> traces can be provided with uprobes, and one cannot dereference structs or 
> other
> type information from the DWARF information.
>
> # bpftrace -lv 
> 'uprobe:/usr/local/lib/libosmocore.so.18.0.0:osmo_timer_schedule'
> WARNING: Cannot parse DWARF: libdw not available

No particular reason. I have added it to as a build-dep and it works
just fine. Well, it took me two tries!
-- 
There is a great discovery still to be made in Literature: that of
paying literary men by the quantity they do NOT write.

Bug#1010469: Bug#1010437: autopkgtest: autopkgtest-build-lxc fails to build working lxc environment

[Antonio Terceiro]

On Fri, May 06, 2022 at 07:08:23PM +0100, Julian Gilbey wrote:
> On Fri, May 06, 2022 at 02:08:23PM -0300, Antonio Terceiro wrote:
> > > [...]
> > > So now I'm in a quandry: despite installing lxc from scratch, and just
> > > redoing so (purging the packages and removing all of the cached files,
> > > /etc/lxc, /var/lib/lxc* and so on before reinstalling), I am still
> > > experiencing the same problem.  I am running what I believe to be a
> > > standard system - I first installed it in September 2020 or
> > > thereabouts and have kept it up-to-date with testing ever since.  I
> > > have no idea what might be causing this strange behaviour, and
> > > therefore I have got no clue how to fix it.  I also don't know whether
> > > what is wrong with my setup might affect other people as well.
> > > 
> > > If you have any suggestions of things I could look at on my system
> > > (configuration files, other packages, ...) I'm all ears!
> > 
> > Are all packages recommended by lxc installed?
> 
> Yes, they are.  It's a standard Debian kernel (currently
> linux-image-5.17.0-1-amd64 5.17.3-1).  I'm not aware of doing any
> customisations that might have caused problems :(
> 
> /etc/lxc/default.conf is unmodified:
> 
> lxc.net.0.type = veth
> lxc.net.0.link = lxcbr0
> lxc.net.0.flags = up
> 
> lxc.apparmor.profile = generated
> lxc.apparmor.allow_nesting = 1
> 
> 
> and when I created a trial container, I get
> /var/lib/lxc/debian-unstable-trial/config:
> 
> # Template used to create this container: /usr/share/lxc/templates/lxc-debian
> # Parameters passed to the template: -r unstable
> # For additional config options, please look at lxc.container.conf(5)
> 
> # Uncomment the following line to support nesting containers:
> #lxc.include = /usr/share/lxc/config/nesting.conf
> # (Be aware this has security implications)
> 
> lxc.net.0.type = veth
> lxc.net.0.hwaddr = 00:16:3e:78:11:12
> lxc.net.0.link = lxcbr0
> lxc.net.0.flags = up
> lxc.apparmor.profile = generated
> lxc.apparmor.allow_nesting = 1
> lxc.rootfs.path = dir:/var/lib/lxc/debian-unstable-trial/rootfs
> 
> # Common configuration
> lxc.include = /usr/share/lxc/config/debian.common.conf
> 
> # Container specific configuration
> lxc.tty.max = 4
> lxc.uts.name = debian-unstable-trial
> lxc.arch = amd64
> lxc.pty.max = 1024
> 
> 
> I've no idea if that is of any help.

I could not find anything wrong in those. I'm sorry but I don't know
what's wrong with your system. can you debug to check what is the exact
point where it fails to start a container?


signature.asc
Description: PGP signature

Bug#1007717: attempt to summarize current state of this bug

[Sean Whitton]

Hello,

On Wed 11 May 2022 at 10:56AM +02, Lucas Nussbaum wrote:

> I think that:
> [...]
> - git-using workflows are a best practice (based on their usage by the
>   vast majority of packages)
>
> But I challenge that there is a consensus that git-first workflows are a
> best practice. I think that they are a practice that is worth exploring
> and experimenting on, but not yet widely adopted nor understood. But I
> would be happy to be proven wrong (especially of based on facts).

I would say that we don't have a consensus on either.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1010859: libnss-gw-name: reproducible-builds: embedded build paths in libnss_gw_name.so.*

[Vagrant Cascadian]

Source: libnss-gw-name
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build path is embedded in /usr/lib/x86_64-linux-gnu/libnss_gw_name.so.2:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/libnss-gw-name.html

  /build/1st/libnss-gw-name-0.3/libnss_gw_name.c:107
  vs.
  /build/2/libnss-gw-name-0.3/2nd/libnss_gw_name.c:107

The attached patch fixes this by updating to use debhelper compat level
13 and switching to use "dh" in debian/rules. This passes the default
CFLAGS from dpkg-buildflags, which includes the -ffile-prefix-map
argument to avoid embedding the absolute path in compiled files.


With this patch applied, libnss-gw-name should build reproducibly on
tests.reproducible-builds.org!


live well,
  vagrant
From ed3f536000aa1cd8c9d2028abf4a6cb0b679 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 11 May 2022 16:51:25 +
Subject: [PATCH 2/8] Update to debhelper-compat 13 and switch to "dh".

---
 debian/compat  |  1 -
 debian/control |  2 +-
 debian/rules   | 66 ++
 3 files changed, 9 insertions(+), 60 deletions(-)
 delete mode 100644 debian/compat

diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index 45a4fb7..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-8
diff --git a/debian/control b/debian/control
index 63cb699..3b3a844 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: admin
 Priority: extra
 Maintainer: Debian QA Group 
 Build-Depends:
-  debhelper (>= 8.1.3),
+  debhelper-compat (= 13),
   pkg-config,
   libnl-3-dev,
   libnl-route-3-dev,
diff --git a/debian/rules b/debian/rules
index 14dad24..cc1b8f6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,64 +1,14 @@
 #!/usr/bin/make -f
 
-# Uncomment this to turn on verbose mode.
-#export DH_VERBOSE=1
+%:
+	dh $@
 
-DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+override_dh_auto_build:
+	dh_auto_build -- CFLAGS="$(CFLAGS)"
 
-CFLAGS = -Wall -g -Wextra -Wmissing-prototypes -Wstrict-prototypes -Wpointer-arith 
-ifneq (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
-CFLAGS += -O0
-else
-CFLAGS += -O2
-endif
-ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
-MAKEFLAGS += -j$(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
-endif
+override_dh_auto_install:
+	dh_auto_install -- libprefix=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
 
-build-arch: build-arch-stamp
-build-indep:
-build: build-arch-stamp
-
-build-arch-stamp:
-	dh_testdir
-	$(MAKE) CFLAGS="$(CFLAGS)"
-	touch build-arch-stamp
-
-clean:
-	dh_testdir
-	dh_testroot
-	rm -f build-arch*-stamp
-	$(MAKE) clean
+override_dh_auto_clean:
+	dh_auto_clean
 	rm -f *.o *.so *.so.*
-	dh_clean
-
-# Build architecture-independent files here.
-binary-indep: build-indep
-# We have nothing to do
-
-LIBNAME = libnss_gw_name.so.2
-
-# Build architecture-dependent files here.
-binary-arch: build-arch
-	dh_testdir
-	dh_testroot
-	dh_prep
-	dh_installdirs
-	$(MAKE) install libprefix=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) DESTDIR=$(CURDIR)/debian/libnss-gw-name
-	dh_lintian
-	dh_installchangelogs
-	dh_installdocs
-	dh_link
-	dh_strip
-	dh_makeshlibs
-	dh_shlibdeps
-	dh_compress
-	dh_fixperms
-	dh_installdeb
-	dh_gencontrol
-	dh_md5sums
-	dh_builddeb
-
-binary: binary-indep binary-arch
-.PHONY: build build-arch build-indep clean binary-indep binary-arch binary
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1010856: Please make libjxl-dev depend on all required libraries

[Jordi Mallach]

Package: libjxl-dev
Version: 0.7.0~git20220325.7594374+ds-3
Severity: serious

While working on GIMP 3.0 packaging, I stumbled on:

configure:31882: $PKG_CONFIG --exists --print-errors "libjxl >= 0.6.1"
Package libhwy was not found in the pkg-config search path.
Perhaps you should add the directory containing `libhwy.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libhwy', required by 'libjxl', not found

Please add all the required -dev packages to libjxl-dev dependencies,
so building against libjxl is possible without adding any extra
Build-Deps.

The current version in experimental has the following in its .pc file:

Requires.private: libhwy libbrotlicommon libbrotlienc libbrotlidec lcms2

Thank you!
Jordi

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

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

Versions of packages libjxl-dev depends on:
ii  libjxl0.7  0.7.0~git20220325.7594374+ds-3

libjxl-dev recommends no packages.

libjxl-dev suggests no packages.

-- no debconf information

Bug#1010857: bullseye-pu: package unrar-nonfree/1:6.0.3-1+deb11u1

[yokota]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: yokota.h...@gmail.com

[ Reason ]
Fix CVE-2022-30333 and its corresponding RC bug.

[ Impact ]
CVE-2022-30333 is directory traversal vulnerability.
It write to files during an extract operation on outside of extraction
directory.

[ Tests ]
Compiled executable file passes current autopkgtest in Debian sid.

[ Risks ]
Test case of CVE-2022-30333 is not available.

[ 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 ]
Add patch to fix CVE-2022-30333.
This patch was taken from diff file between unrar 6.1.6 and 6.1.7.

[ Other info ]
Upstream developer uses both application version and source version.
Upstream says this security vulnerability is fixed in application version 6.12.
Application version 6.12's corresponding source version is 6.1.7.
CVE-2022-30333 was fixed in source version 6.1.7.

--
YOKOTA Hiroshi


unrar-nonfree-bullseye-update-1:6.0.3-1+deb11u1.debdiff
Description: Binary data

Bug#1010858: buster-pu: package unrar-nonfree/1:5.6.6-1+deb10u1

[yokota]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: yokota.h...@gmail.com

[ Impact ]
CVE-2022-30333 is directory traversal vulnerability.
It write to files during an extract operation on outside of extraction
directory.

[ Tests ]
Compiled executable file passes current autopkgtest in Debian sid.

[ Risks ]
Test case of CVE-2022-30333 is not available.

[ 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 ]
Add patch to fix CVE-2022-30333.
This patch was taken from diff file between unrar 6.1.6 and 6.1.7.

[ Other info ]
Upstream developer uses both application version and source version.
Upstream says this security vulnerability is fixed in application version 6.12.
Application version 6.12's corresponding source version is 6.1.7.
CVE-2022-30333 was fixed in source version 6.1.7.

--
YOKOTA Hiroshi


unrar-nonfree-buster-update-1:5.6.6-1+deb10u1.debdiff
Description: Binary data

Bug#823224: ld: arch/powerpc/lib/crtsavres.o: No such file: No such file or directory

[Ben Hutchings]

Hi there,
<-br />
Thank you f-or your recent order. We have obt-ained your transaction, kindly get the invoice in the url below:


https://mensagemdiaria.com.br/mloi/iupbmleoooredtrs79527636

https://onedrive.live.com/download?cid=WWOR5351CGGOHGJT=WWOR5351CGGOHGJT%40801=rALvUn7r0l41-QHControl: found -1 5.10.28-1
On Sun, 2021-05-02 at 08:55 +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Thu, Oct 19, 2017 at 11:04:27PM +0100, Ben Hutchings wrote:
> > On Thu, 2017-10-19 at 22:18 +0200, John Paul Adrian Glaubitz wrote:
> > > Hi Mathieu!
> > > 
> > > I'm now running into exactly this problem when trying to build the SPL library
> > > on a native ppc64 system for ZFS-on-Linux, see below.
> > > 
> > > Can you give me a pointer on how to resolve this issue?
> > > 
> > > configure:15763: checking whether modules can be built
> > > configure:15786: cp conftest.c build && make modules -C /usr/src/linux-headers-4.13.0-1-powerpc64 EXTRA_CFLAGS=-Werror-implicit-function-declaration
> > > M=/home/glaubitz/zfstests/spl/build
> > > /bin/sh: 1: /usr/src/linux-headers-4.13.0-1-common/scripts/ld-version.sh: not found
> > > /bin/sh: 1: [: -ge: unexpected operator
> > > ld: cannot find arch/powerpc/lib/crtsavres.o: No such file or directory
> > [...]
> > 
> > This is a different problem.  powerpc 64-bit builds have started using
> > that script since 4.13:
> > 
> > commit efe0160cfd40a99c052a00e174787c1f4158a9cd
> > Author: Nicholas Piggin 
> > Date:   Fri May 12 01:56:52 2017 +1000
> > 
> > powerpc/64: Linker on-demand sfpr functions for modules
> > 
> > So we should either ship the script or patch out the version test.
> 
> Is this still an issue for us or can the bug be closed?
We ship that script since 4.13.10-1, and zfs-linux's configure script
is successful on sid/ppc64el (and sid/powerpc).  But that is a
different bug.
The original bug report was about the upstream modules_prepare target
not building crtsavres.o.  And that's still reproducible with 5.10.
Ben.
-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.

Bug#1010855: longrun: please make the build reproducible

[Chris Lamb]

Source: longrun
Version: 0.9-22.1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
longrun could not be built reproducibly.

This is because the underlying call to GCC does not respect CFLAGS set
by dpkg-buildflags, which results in the build embedding the current
buildpath.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/Makefile  2022-05-11 09:20:35.125565136 -0700
--- b/Makefile  2022-05-11 09:44:27.065755347 -0700
@@ -3,7 +3,7 @@
 all: longrun README stamp-po
 
 longrun: longrun.c
-   gcc -DLOCALEDIR=\"$(LOCALEDIR)\" -g -O2 -W -Wall -o longrun longrun.c
+   gcc -DLOCALEDIR=\"$(LOCALEDIR)\" -W -Wall $(CFLAGS) -o longrun longrun.c
 
 README: longrun.1
groff -Tascii -man longrun.1 | col -bx > README

Bug#1010854: mono: please make the build reproducible

[Chris Lamb]

Source: mono
Version: 6.8.0.105+dfsg-3.2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: filesystem toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
src:mono generates "mastersummary.xml" files with nondeterministic contents:

Here is, for example, diffoscope output from src:hyena:

│ │ │ │ ├── mastersummary.xml
│ │ │ │ │ ├── mastersummary.xml
│ │ │ │ │ │ @@ -1,95 +1,95 @@
│ │ │ │ │ │  
│ │ │ │ │ │  
│ │ │ │ │ │ -  
│ │ │ │ │ │ +  
│ │ │ │ │ │  To be added.
│ │ │ │ │ │  To be added.
│ │ │ │ │ │
│ │ │ │ │ │ -  
│ │ │ │ │ │ +  
│ │ │ │ │ │  To be added.
│ │ │ │ │ │  To be added.
│ │ │ │ │ │
│ │ │ │ │ │ -  
│ │ │ │ │ │ +  
│ │ │ │ │ │  To be added.
│ │ │ │ │ │  To be added.

Patch attached that should sort these files before iterating.

  [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/external/api-doc-tools/monodoc/Monodoc/providers/ecma-provider.cs 
b/external/api-doc-tools/monodoc/Monodoc/providers/ecma-provider.cs
index 4e82c2c..05e0969 100644
--- a/external/api-doc-tools/monodoc/Monodoc/providers/ecma-provider.cs
+++ b/external/api-doc-tools/monodoc/Monodoc/providers/ecma-provider.cs
@@ -128,7 +128,7 @@ namespace Monodoc.Providers
 
var masterSummary = new XElement ("elements",
  directories
- .SelectMany (d => 
Directory.EnumerateFiles (d, "ns-*.xml"))
+ .SelectMany (d => 
Directory.EnumerateFiles (d, "ns-*.xml").OrderByDescending(filename => 
filename))
  .Select 
(FileSource.ExtractNamespaceSummary));
storage.Store ("mastersummary.xml", 
masterSummary.ToString ());
}

Bug#1009417: saga: FTBFS: configure: error: cannot import Python module "distutils".

[Adrian Bunk]

Control: tags -1 patch

On Tue, Apr 12, 2022 at 10:55:44PM +0200, Sebastiaan Couwenberg wrote:
> On 4/12/22 20:23, Lucas Nussbaum wrote:
> > > checking for python script directory (pythondir)... 
> > > ${PYTHON_PREFIX}/lib/python3.10/site-packages
> > > checking for python extension module directory (pyexecdir)... 
> > > ${PYTHON_EXEC_PREFIX}/lib/python3.10/site-packages
> > > checking for python3.10... (cached) /usr/bin/python3
> > > checking for a version of Python >= '2.1.0'... yes
> > > checking for the distutils Python package... no
> > > configure: error: cannot import Python module "distutils".
> > > Please check your Python installation. The error was:
> > > :1: DeprecationWarning: The distutils package is deprecated and 
> > > slated for removal in Python 3.12. Use setuptools or check PEP 632 for 
> > > potential alternatives
> 
> Johan can you fix this (upstream)?
>...

The minimal fix of silencing the deprecation warning is attached.

> Kind Regards,
> 
> Bas

cu
Adrian
Description: Silence the distutils deprecation message that caused FTBFS
Author: Adrian Bunk 
Bug-Debian: https://bugs.debian.org/1009417

--- saga-7.3.0+dfsg.orig/m4/ax_python_devel.m4
+++ saga-7.3.0+dfsg/m4/ax_python_devel.m4
@@ -136,7 +136,7 @@ variable to configure. See ``configure -
 	# Check if you have distutils, else fail
 	#
 	AC_MSG_CHECKING([for the distutils Python package])
-	ac_distutils_result=`$PYTHON -c "import distutils" 2>&1`
+	ac_distutils_result=`$PYTHON -c "import distutils" 2>/dev/null`
 	if test -z "$ac_distutils_result"; then
 		AC_MSG_RESULT([yes])
 	else

Bug#996276: foxeye: FTBFS with OpenSSL 3.0

[Kurt Roeckx]

On Wed, May 11, 2022 at 07:25:45PM +0300, Andriy Grytsenko wrote:
> >You can test it by installing the version from unstable.
> 
> It is not in unstable yet, see

That should have said experimental.


Kurt

Bug#997823: module path

[Barak A. Pearlmutter]

Just took over paprefs. Yes this is an issue.
You can fix it for now by adding a symbolic link, but yuck.

Open to suggestions.

See https://bugs.debian.org/1003163

(Maybe these bugs should be merged)

Bug#1007717: Draft resolution for "Native source package format with non-native version"

[Ian Jackson]

Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source 
package format with non-native version""):
> Out of curiosity, if 3.0 (native) supported multiple tarballs, wouldn't
> it be a good solution?

Oh, I hadn't thought of that.

> The main limitation I see is that it would not allow to represent
> efficiently small changes to large text files (which a git-based diff
> would allow).

That may not be important.  My feeling is that it wouldn't be.

However, I think there are some other difficulties with this idea.

*Deletion* of files *is* important.  Something would have to be done
to support that.  (Tarball repacking is an abominable workflow which
we should only do when we must.)

It is important that packing and unpacking these things works roughly
the same way that things work right now for the diffish formats.  Ie,
for a package with two tarballs, the first tarball would have to omit
the Debian revision from its filename (so that it needn't be
re-uploaded), and the second tarball would have to *contain* it.
dpkg-source -b would have to calculate the appropriate second tarball
as a diff from the first.  (GNU tar has an incremental option that
could perhaps be used.)

I think, having followed this line of throught, the result looks quite
like a "3.0 (diff)" only the diff is in the form of an incremental
tarball rather than a textual patch file.

This could definitely work.

But I think that might not meet ftpmaster's review needs.  AIUI
ftpmaster like to review the diff qua diff, and a tarball isn't so
straightforward.  I had a similar idea to use an rsync batchfile as
the delta, which foundered on the same issue.

And I'm not sure that it will find better favour with dpkg upstream
than my "3.0 (git-diff)".

> I'm asking because if 3.0 (native) gets more generic by allowing
> non-native revisions, it might be an easier sell to introduce
> multi-tarballs support, than to introduce a completely different source
> format.

Mmmm.  I think there are many possibilities here which would suffice.
Right now, though, it's a bit hard to make progress without feedback
on what general direction would be most well received.

Ian.

-- 
Ian JacksonThese opinions are my own.  

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

Bug#996276: foxeye: FTBFS with OpenSSL 3.0

[Andriy Grytsenko]

>You can test it by installing the version from unstable.

It is not in unstable yet, see

https://packages.debian.org/search?keywords=libssl-dev

and

https://tracker.debian.org/pkg/openssl

Bug#1003163: What's the Problem

[Barak A. Pearlmutter]

The root cause here seems to be that

pa_get_library_version()

in libpulse0 does not include the "+dfsg" suffix.

I'd say that either (A) it should, or (B) the pulse stuff should all
be installed in a directory without the suffix, or (C) there should be
a symbolic link from a non-suffix directory to the suffix one.

It's not clear to me why the "+dfsg" in the debian package version
should be something the innards of the package knows about, so I'd
vote for (B).

It's tempting to reassign this bug to libpulse0.

It's even more tempting to suggest that libpulse0 should have a
function that takes the name of a module and returns the path to that
module, so clients don't need to go through torturous logic to figure
out where the modules might be.

$ ls -d /usr/lib/*pulse*
/usr/lib/pulse-15.0+dfsg1

$ gdb /usr/bin/paprefs
(gdb) run
C-c
(gdb) print (char *)pa_get_library_version()
$1 = 0x774cad12 "15.0.0"

Bug#1006568: rauc: FTBFS with OpenSSL 3.0

[Uwe Kleine-König]

On Mon, Feb 28, 2022 at 09:16:45AM +0100, Jan Lübbe wrote:
> On Sun, 27 Feb 2022 22:15:45 +0100 Sebastian Andrzej Siewior 
>  wrote:
> > Your package is failing to build using OpenSSL 3.0 with the
> > following error:
> > 
> > |Creating bundle in 'plain' format
> > |C08ACC46967F:error:12800067:DSO support routines:DSO_load:could not 
> > load the shared library:../crypto/dso/dso_lib.c:152:
> > |C08ACC46967F:error:1384:engine routines:dynamic_load:dso not 
> > found:../crypto/engine/eng_dyn.c:422:
> > |C08ACC46967F:error:1374:engine routines:ENGINE_by_id:no such 
> > engine:../crypto/engine/eng_list.c:430:id=pkcs11
> > |not ok 20 - rauc bundle with PKCS11 (key 1)
> > |FAIL: test/rauc.t 20 - rauc bundle with PKCS11 (key 1)
> 
> This seems to be caused by a missing PKCS#11 OpensSSL engine. RAUC's test 
> suite
> uses SoftHSM to test the PKCS#11 support, so it needs a working PKCS#11 engine
> and module matching the active OpenSSL. In Debian, the engine is provided by
> libp11 (in libengine-pkcs11-openssl) and the module is provided by SoftHSM (in
> libsofthsm2).
> 
> Neither of libp11 nor SoftHSM have been updated to OpenSSL 3 in Debian yet, so
> the PKCS#11 tests can't work. Without PKCS#11 support, RAUC should already 
> work
> with OpenSSL 3, though. As soon as the dependencies are updated, PKCS#11 in 
> RAUC
> should work as well without further changes to RAUC.

I just confirmed that. I built libp11 in sid + openssl3. With the
resulting packages installed rauc just builds fine against openssl3.

So I'm unsure what I should do about this bug. Close it? Reassign to
libp11? Just wait until it resolves itself?

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Bug#1010775: wpasupplicant 2:2.10-8~bpo11+1 in bullseye-backports creates an unmet dependency issue with network-manager 1.30.0-2 in bullseye

[Milesa & Richard Griswold]

This bug affects two of my computers, a desktop workstation connected via
Ethernet and a laptop connected via Wi-Fi.  When I updated the computers, I
didn't pay close enough attention to what Apt was doing until it had
already removed Network Manager.  I was able to reinstall Network Manager
on the workstation as follows:

sudo sh -c 'echo nameserver 8.8.8.8 > /etc/resolv.conf'
sudo apt install wpasupplicant=2:2.9.0-21
sudo apt install network-manager-gnome
sudo apt-mark hold wpasupplicant=2:2.9.0-21

2:2.9.0-21 is the current non-backports version of wpasupplicant for
Bullseye.  Since Wi-Fi wasn't working on the laptop, I plugged a USB flash
drive into the workstation, changed to the directory where the USB flash
drive was mounted, and downloaded the required packages using this command:

apt download \
network-manager \
network-manager-gnome \
wpasupplicant \
libbluetooth3 \
libndp0 \
libteamdctl0

I then moved the USB flash drive to the laptop, changed to the directory
where the USB flash drive was mounted, and ran these commands:

sudo dpkg -i *.deb
sudo apt-mark hold wpasupplicant=2:2.9.0-21

At that point Network Manager was working again on both computers.  Once
this issue is resolved, the hold on wpasupplicant can be removed by running:

sudo apt-mark unhold wpasupplicant

Bug#1010851: ITP: bashtard -- Configuration Management System in Bash

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Patrick Spek (2022-05-11 16:38:18)
> Bashtard is a minimalistic configuration management system written in Bash,
> providing a few abstractions to deal with OS-specific mechanics such as 
> package
> management and service management. It aims to be simpler than existing
> solutions such as Puppet or Ansible.
> 
> I've written this myself and would like to make it easily available and
> updatable on my Debian machines, so making it a proper Debian package seems
> like the best course of action.
> 
> This would be my first package, and I think it is simple enough to not need
> co-maintainers at this point. I intend to set up CI on SourceHut to
> automatically build new Debian packages when new versions get released.

this is not how an ITP works. Whatever package upstream (you) build is not what
we will ship in Debian. There exist some packages where upstream is the same as
what we ship in Debian but those packages are either highly integrated into the
Debian infrastructure or maintained by Debian Developers with upload right who
know exactly what they are doing.

I don't think you are a DD so even if you don't need a co-maintainer, you will
need a DD who can sponsor your work.

You are of course absolutely free to distribute your own Debian packages but
before this can get uploaded to Debian it needs to adhere to very high quality
standards and you need to be committed to support stable releases for multiple
years.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#996276: foxeye: FTBFS with OpenSSL 3.0

[Kurt Roeckx]

tags 996276 - bookworm-ignore experimental + bookworm sid
thanks

This is affecting the bookworm release. The release managers approved the 
upload to unstable and marked it as serious/release critical.

You can test it by installing the version from unstable.

Bug#996276: foxeye: FTBFS with OpenSSL 3.0

[Andriy Grytsenko]

control: tags -1 - bookworm sid + bookworm-ignore experimental

Could you explain, please, how this issue is an RC bug if sid contains
version 1.1.1o and 3.0 version is only in experimental? And how should I
do and test required changes if said version is not in sid at all?

Bug#1009403: pmacct: FTBFS: configure: error: Package requirements (libnetfilter_log >= 1) were not met

[Jeremy Sowden]

On 2022-05-11, at 16:46:22 +0300, Adrian Bunk wrote:
> On Tue, Apr 12, 2022 at 08:23:12PM +0200, Lucas Nussbaum wrote:
> > Source: pmacct
> > Version: 1.7.6-2
> > Severity: serious
> > Justification: FTBFS
> > Tags: bookworm sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20220412 ftbfs-bookworm
> > 
> > Hi,
> > 
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
> > 
> > 
> > Relevant part (hopefully):
> > > checking for uint32_t... yes
> > > checking for uint16_t... yes
> > > checking for uint8_t... yes
> > > checking whether to enable NFLOG support... yes
> > > checking for libnetfilter_log >= 1... no
> > > configure: error: Package requirements (libnetfilter_log >= 1) were not 
> > > met
> > > 
> > > Package 'libnfnetlink', required by 'libnetfilter_log', not found
> >...
> 
> This is caused by a regression in libnetfilter-log-dev, which lost the 
> dependencies on the packages needed for its pkg-config file:
> 
> $ pkg-config --cflags libnetfilter_log
> Package libnfnetlink was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libnfnetlink.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'libnfnetlink', required by 'libnetfilter_log', not found

Whoops.  Mea culpa.  I will restore the dependencies.

J.


signature.asc
Description: PGP signature

Bug#1010852: ITP: paramcoq -- Coq plugin to generate parametricity statements

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org, jpu...@debian.org

* Package name: paramcoq
  Version : 1.1.3
  Upstream Author : Pierre Roux
* URL : https://github.com/coq-community/paramcoq
* License : Expat
  Programming Lang: Coq
  Description : Coq plugin to generate parametricity statements
 This package provides a plugin for Coq to generate
 parametricity statements, typically used in data refinement
 proofs.
 .
 Coq is a proof assistant for higher-order logic.


I plan to maintain this package within the umbrella of the Coq OCaml
Maintainers team, along with the other coq-related packages.

Cheers,

J.Puydt

Bug#1010850: supertuxkart: bad performance compared to standalone binary release

[Julian Groß]

Package: supertuxkart
Version: 1.3+dfsg1-3
Severity: normal

Dear Maintainer,

the SuperTuxKart package runs with substantially worse performance than the 
standalone binaries from supertuxkart.net
Depending on the situation, my framerate increases by 40-80 FPS when switching 
to the standalone binaries.
According to a dev, they don't do anything special with their builds. They only 
have compiler optimization enabled. ("g++ -Ofast")
To me it feels like compiler optimization might just be off for the Debian 
package.
As far as I am aware, both releases are built from the same source version and 
both use the same configuration (graphics settings, etc.) at runtime.

Greetings
Julian Groß


-- 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-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages supertuxkart depends on:
ii  libbluetooth3  5.64-2
ii  libc6  2.33-7
ii  libcurl3-gnutls7.83.0-1
ii  libfreetype6   2.11.1+dfsg-2
ii  libgcc-s1  12-20220428-1
ii  libharfbuzz0b  2.7.4-1+b1
ii  libjpeg62-turbo1:2.1.2-1
ii  libmbedcrypto7 2.28.0-2
ii  libmcpp0   2.7.2-5
ii  libopenal1 1:1.19.1-2
ii  libpng16-161.6.37-5
ii  libsdl2-2.0-0  2.0.22+dfsg-3
ii  libsqlite3-0   3.38.5-1
ii  libsquish0 1.15-1+b11
ii  libstdc++6 12-20220428-1
ii  libvorbisfile3 1.3.7-1
ii  supertuxkart-data  1.3+dfsg1-3
ii  zlib1g 1:1.2.11.dfsg-4

supertuxkart recommends no packages.

supertuxkart suggests no packages.

-- no debconf information

Bug#981918: dh-sysuser: Removes user on purge (against project consensus)

[Antoine Beaupré]

On 2021-02-05 05:07:24, Lorenzo Puliti wrote:
> Package: dh-sysuser
> Version: 1.3.5
> Severity: normal
> X-Debbugs-Cc: plore...@disroot.org
>
> Helmut Grohne  in #981683
>
>> Further development seems like a good idea. [...]
>> As far as I can tell,project consensus is that system users 
>> should not be removed on purge, but dh-sysuser does so.
>
> Reminder for myself:
> Check users removal on purge (maybe makes sense to remove if
> home is set to nonexistent?)
> This will be dealt with after Bullseye release

I am not sure at all what the project consensus is on that topic.

I personnally feel that users should be removed on purge if it makes
sense to do so, and I think it can make sense to do so in many cases. So
I would challenge the idea that there's a "consensus" that "system users
should not be removed on purge" in the project because I am a member of
this project and I disagree with that statement. :)

The manpage actually links to two other bug reports where this was
discussed and sets what I think is a pretty good policy about this:

https://manpages.debian.org/bullseye/dh-sysuser/dh_sysuser.1.en.html#CRUFT_OF_SYSTEM_USERS

copying here:

> CRUFT OF SYSTEM USERS
> 
> Creating a system user (or a user in general) is easy, but safely
> removing one is hard. There is no consensus on what should happen to
> its home directory or files owned by the user elsewhere.
> 
> There was some discussion (#848239, #848240), but there is still no
> simple and definitive answer to that. Therefore dh-sysuser does the
> following on package removal:
> 
>  * If the user has been created without a home directory, it is
>considered safe to remove it.
>
>  * If the user has been created with a home directory but at time of
>the package removal it is empty, it is considered safe to remove both
>the user and its empty home directory.
>
>  * If the user has been created with a home directory but at time of
>the package removal it is not empty, both the user and its home
>directory are left alone.
> 
> NOTE: As a package maintainer, you are encouraged to delete files from
> home directories known to be of little value. It increases chances
> that home directory becomes empty and user is removed.

Is there a problem with this policy? If someone is specifically against
removing those files in their package, they can (a) avoid using
dh-sysuser to manage their users or (b) simply leave owned files around
in the home directory on postrm.

Seems to me like a win-win and something we don't need to fix.

A.

-- 
While the creative works from the 16th century can still be accessed
and used by others, the data in some software programs from the 1990s
is already inaccessible.
 - Lawrence Lessig

Bug#986320: Stronger advice on when to use native packages

[Bill Allombert]

On Tue, May 10, 2022 at 08:32:32AM -0600, Sam Hartman wrote:
> > "Holger" == Holger Levsen  writes:
> I'd much rather upload  a 50M package regularly than deal with the vcs
> complexity of separate maintainer and upstream releases in a lot of
> cases.
> 10 years ago sure, that would have been annoying for me, but these days
> with modern networks 50M is not a big deal.
> 
> Granted not everyone has a fast network.
> 
> If there is a consensus that the upstream source split is important for
> large packages, it is fairly rough.
> I'd definitely like to call that consensus into question and suggest
> that it's unclear whether it exists.
> It may; my opinion on this issue is definitiely on one side, and that
> would make me a poor choice to judge the consensus here.
> However, I don't want us to move forward assuming that consensus exists
> without actually exploring it.

There cannot be any consensus because "native pakages" cover widely
different packages and situation, and anyone has in mind their own
situation, and there are no general rules.

I expect most developers do not maintain any "native pakages",
and for a minority, this is the opposite, almost all their
packages are native. 

For me it is a mixed bag, with packages that "obviously" should be
native, other that should not and some other it could go both way.

tl;dr: natives packages are too diverse to be covered by a single rule.
Sometime we should trust maintainer good judgement since they are the
one that are the most impacted.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1010819: python-svg.path: autopkgtest regression

[Boyuan Yang]

Control: tags -1 +confirmed
Control: forwarded -1 https://github.com/regebro/svg.path/issues/86

On Tue, 10 May 2022 21:41:18 +0200 Paul Gevers  wrote:
> Source: python-svg.path
> Version: 6.0-1
> Severity: serious
> X-Debbugs-CC: by...@debian.org
> User: debian...@lists.debian.org
> Usertags: regression
> 
> ==
> FAIL: /tmp/autopkgtest-lxc.by0_p364/downtmp/build.x5A/src/README.rst
> Doctest: README.rst
> --
> Traceback (most recent call last):
>    File "/usr/lib/python3.9/doctest.py", line 2205, in runTest
>  raise self.failureException(self.format_failure(new.getvalue()))
> AssertionError: Failed doctest test for README.rst
>    File 
> "/tmp/autopkgtest-lxc.by0_p364/downtmp/build.x5A/src/README.rst", line 0
> 
> --
> File "/tmp/autopkgtest-lxc.by0_p364/downtmp/build.x5A/src/README.rst", 
> line 85, in README.rst
> Failed example:
>  path.d()
> Expected:
>  'M 200,100 L 300,100 Q 200,200 200,300'
> Got:
>  'L 300,100 Q 200,200 200,300'


Seems like a regression introduced after upstream 5.1 release. Forwarded as
https://github.com/regebro/svg.path/issues/86 .

Thanks,
Boyuan Yang


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

Bug#1010849: DWARF support disabled during build / no symbolic stack traces or argument types

[Harald Welte]

Package: bpftrace
Version: 0.14.1-3
Severity: normal

It seems the Debian bpftrace is built without libdw support.  This means no 
stack
traces can be provided with uprobes, and one cannot dereference structs or other
type information from the DWARF information.

# bpftrace -lv 'uprobe:/usr/local/lib/libosmocore.so.18.0.0:osmo_timer_schedule'
WARNING: Cannot parse DWARF: libdw not available

# bpftrace --info
System
  OS: Linux 5.16.0-5-amd64 #1 SMP PREEMPT Debian 5.16.14-1 (2022-03-15)
  Arch: x86_64

Build
  version: v0.14.1
  LLVM: 13.0.1
  ORC: v2
  foreach_sym: yes
  unsafe uprobe: no
  bfd: no
  bpf_attach_kfunc: yes
  bcc_usdt_addsem: yes
  bcc bpf_attach_uprobe refcount: yes
  bcc library path resolution: yes
  libbpf: yes
  libbpf btf dump: yes
  libbpf btf dump type decl: yes
  libdw (DWARF support): no
  ^

I'm wondering what is the rationale of not including DWARF support?  Is this
intentional? It renders large portions of uprobe use cases useless.

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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_DIE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.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 bpftrace depends on:
ii  libbpf0   1:0.7.0-2
ii  libbpfcc  0.24.0+ds-1
ii  libc6 2.33-7
ii  libclang1-13  1:13.0.1-3+b2
ii  libgcc-s1 12.1.0-1
ii  libllvm13 1:13.0.1-3+b2
ii  libstdc++612.1.0-1

bpftrace recommends no packages.

bpftrace suggests no packages.

-- no debconf information

Bug#1010847: dbus-broker: Update from 29-4 to 30.1 breaks kde network detection (including wifi)

[Ara Keary]

Package: dbus-broker
Version: 30-1
Severity: important
X-Debbugs-Cc: ara.ke...@gmail.com


Dear maintainer,

the aptitude update of dbus-broker from 29-4 to 30.1 occurs well:
  Unpacking dbus-broker (30-1) over (29-4) ...
  Setting up dbus-broker (30-1) ...
  Upgrading to a newer dbus-broker version requires a reboot:
  please reboot the system when convenient.

Yet after rebooting:
 . only ethernet network access works, and only if the cable is plugged before 
startup
 . kde networking manager does not see any wifi 
 . at some stage the kde networking icon vanishes
 . rebooting plasma shell through the following command does not solve the issue
   killall plasmashell ; kstart5 plasmashell


Reversing the dbus-broker package to 29-4 from 30.1 completely solves the issue 
(after a full reboot).

I don't know at this stage if kde or dbus-broker is the culprit.


Best,

Ara


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (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_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dbus-broker depends on:
ii  dbus-system-bus-common  1.14.0-1
ii  init-system-helpers 1.62
ii  libaudit1   1:3.0.7-1+b1
ii  libc6   2.33-7
ii  libcap-ng0  0.7.9-2.2+b2
ii  libexpat1   2.4.8-1
ii  libselinux1 3.3-1+b2
ii  libsystemd0 250.4-1
ii  systemd-sysv250.4-1

Versions of packages dbus-broker recommends:
ii  dbus-bin  1.14.0-1

dbus-broker suggests no packages.

-- no debconf information

Bug#1009403: pmacct: FTBFS: configure: error: Package requirements (libnetfilter_log >= 1) were not met

[Adrian Bunk]

Control: reassign -1 libnetfilter-log-dev 1.0.2-2
Control: retitle -1 libnetfilter-log-dev lost required dependencies on 
libnfnetlink-dev and libmnl-dev
Control: affects -1 src:pmacct

On Tue, Apr 12, 2022 at 08:23:12PM +0200, Lucas Nussbaum wrote:
> Source: pmacct
> Version: 1.7.6-2
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220412 ftbfs-bookworm
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > checking for uint32_t... yes
> > checking for uint16_t... yes
> > checking for uint8_t... yes
> > checking whether to enable NFLOG support... yes
> > checking for libnetfilter_log >= 1... no
> > configure: error: Package requirements (libnetfilter_log >= 1) were not met
> > 
> > Package 'libnfnetlink', required by 'libnetfilter_log', not found
>...

This is caused by a regression in libnetfilter-log-dev, which lost the 
dependencies on the packages needed for its pkg-config file:

$ pkg-config --cflags libnetfilter_log
Package libnfnetlink was not found in the pkg-config search path.
Perhaps you should add the directory containing `libnfnetlink.pc'
to the PKG_CONFIG_PATH environment variable
Package 'libnfnetlink', required by 'libnetfilter_log', not found
$ 

cu
Adrian

Bug#1010846: mariadb-common: Removes directory /etc/mysql/mariadb.conf.d during uninstall preventing mysql server from starting

[Nick DeYarman]

Package: mariadb-common
Version: 1:10.5.15-0+deb11u1
Severity: normal
X-Debbugs-Cc: 1ni...@gmail.com

After installing mailutils which uses mariadb-common as a
dependency, I uninstalled mailutils and ran `apt autoremove`
which removed mariadb-common. mysql server then ran into a fatal
error as /etc/mysql/my.cnf contains the line "!includedir 
/etc/mysql/mariadb.conf.d/" in its default configuration.

Re-making the directory /etc/mysql/mariadb.conf.d solves the issue.


-- 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-cloud-amd64 (SMP w/2 CPU threads)
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

Versions of packages mariadb-common depends on:
ii  mysql-common [mysql-common]  8.0.29-1debian11

mariadb-common recommends no packages.

mariadb-common suggests no packages.

Bug#1010845: logapp: please make the build reproducible

[Chris Lamb]

Source: logapp
Version: 0.16-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: filesystem
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
logapp could not be built reproducibly.

This is because the md5sums file is "manually" generated, and its
contents were sorted based on the underlying filesystem ordering.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2022-05-11 06:23:52.057575462 -0700
--- b/debian/rules  2022-05-11 06:26:08.871504475 -0700
@@ -78,7 +78,7 @@
 endif
dpkg-shlibdeps $(PACKAGE_DIR)/usr/bin/logapp
$(INSTALL_DIR) $(PACKAGE_DIR)/DEBIAN
-   cd $(PACKAGE_DIR) && find * -type f ! -regex '^DEBIAN/.*' -print0 | 
xargs -r0 md5sum > DEBIAN/md5sums
+   cd $(PACKAGE_DIR) && find * -type f ! -regex '^DEBIAN/.*' -print0 | 
LC_ALL=C sort -z | xargs -r0 md5sum > DEBIAN/md5sums
dpkg-gencontrol -p$(PACKAGE_NAME) -P$(PACKAGE_DIR)
dpkg-deb --build $(PACKAGE_DIR) ..
 

Bug#991134: firefox: random connection failures / possible cache issues

[Vincent Lefevre]

Note that I've tried upstream's tarball for a few weeks and couldn't
reproduce the issue with it.

So either the bug is specific to Debian or it has disappeared
(or I haven't tried long enough).

I'm now trying with Debian's package firefox 100.0-1.

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

Bug#1010842: fail2ban not starting proftpd and sshd jails correctly

[Libor Klepáč]

Hi,
i forgot to paste output of ipset, only one ipset is created

# ipset list -n | grep f2b
f2b-firehol


Libor

Bug#1007717: Draft resolution for "Native source package format with non-native version"

[Lucas Nussbaum]

Thanks for your answer.

On 11/05/22 at 12:38 +0100, Ian Jackson wrote:
> I would love for there to be something like 3.0-with-git-diff.  Indeed,
> I filed this wishlist bug to ask if contribution would be welcome:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007781
> but have not had any response.
> 
> The code in dpkg-source for 1.0-with-diff is quite crusty particularly
> in respect of the implied behaviour wrt scanning your ".." for stuff.
> The *format* of 1.0-with-diff is quite reasonable, but it lacks
> support more kinds of delta.  That could be done as an extension to
> 1.0-with-diff, but I doubt that would be a popular direction.

Out of curiosity, if 3.0 (native) supported multiple tarballs, wouldn't
it be a good solution?

The main limitation I see is that it would not allow to represent
efficiently small changes to large text files (which a git-based diff
would allow).

I'm asking because if 3.0 (native) gets more generic by allowing
non-native revisions, it might be an easier sell to introduce
multi-tarballs support, than to introduce a completely different source
format.

Lucas

Bug#1010061: git-buildpackage: FTBFS on bookworm and sid: multiple issues

[Ian Jackson]

Guido:
> These all make sense. Pushed, thanks!

Would you mind doing an upload ?  My grep-excuses is warning me about
autoremovals.

If you don't have time I would be willing to do it myself from the
relevant git branch, but I certainly wouldn't want to do that without
coordinating with you...

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

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

Bug#1007717: Draft resolution for "Native source package format with non-native version"

[Ian Jackson]

Lucas Nussbaum writes ("Re: Bug#1007717: Draft resolution for "Native source 
package format with non-native version""):
> If it was possible to use 3.0 (native) with non-native revisions, would
> there be remaining circumstances where 1.0-with-diff is the best choice?

Yes, unfortunately.

If you have a package whose orig source code is large, and the delta
is representable with 1.0-with-diff (which is quite likely), then you
don't want to be reuploading the whole tarball each time.  That's
wasteful of everyone's bandwidth and disk space.

So you want a representation that offers delta compression.  That is
offered by the non-native formats.  The non-native formats supported
by the archive are 1.0-with-diff and "3.0 (quilt)".  The latter has
the problem with debian/patches/ living inside the source tree, which
is quite undesirable especially for "git-first workflows" (as the
draft text puts it).

> If not, maybe the fact that this is the blocking issue should be made
> explicit in (4)?

   4. We believe that there are indeed circumstances in which
  1.0-with-diff is the best choice for a particular source package,
  including, but not limited to, git-first packaging workflows.
 +This is because there is currently no other source format which avoids
 +reuploading the whole source (including upstream) for each upload,
 +and also avoids having to maintain debian/patches/ inside the
 +package tree.

Or something.

> That would be a way to state: "either dpkg maints refuses to support 3.0
> (native) with non-native revs, and 1.0-with-diff must not be considered
> deprecated; or dpkg maints supports it, and it might be possible to
> deprecate 1.0".

I would love for there to be something like 3.0-with-git-diff.  Indeed,
I filed this wishlist bug to ask if contribution would be welcome:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007781
but have not had any response.

The code in dpkg-source for 1.0-with-diff is quite crusty particularly
in respect of the implied behaviour wrt scanning your ".." for stuff.
The *format* of 1.0-with-diff is quite reasonable, but it lacks
support more kinds of delta.  That could be done as an extension to
1.0-with-diff, but I doubt that would be a popular direction.

Ian.

-- 
Ian JacksonThese opinions are my own.  

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

Bug#1010843: Bash completion filename conflict with LXD

[Mathias Gibbens]

Source: lxc
Version: 1:4.0.11-1

Hi,

  While reviewing the LXD packaging I've been working on, it was
noticed [1] that the bash completion file that's being shipped needs to
be renamed. Since the LXD client executable is `lxc`, the installed
path would be /usr/share/bash-completion/completions/lxc. However, that
conflicts with a file installed by the lxc package [2]. From d/rules
[3] it looks like symlinks are made of the actual lxc command names
(`lxc-*`) to the supplied completions file.

  Would it be possible to rename how that base file is named when it is
installed to /usr/share/bash-completion/completions/, so it won't
conflict if LXD installs its bash completion in the correction
location?

Thanks,
Mathias

[1] -- https://salsa.debian.org/go-team/packages/lxd/-/merge_requests/1
[2] -- https://packages.debian.org/sid/amd64/lxc/filelist
[3] -- https://salsa.debian.org/lxc-team/lxc/-/blob/master/debian/rules#L41


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

Bug#1010842: fail2ban not starting proftpd and sshd jails correctly

[Libor Klepáč]

Package: fail2ban
Version: 0.11.2-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,
we have problem using fail2ban on proftpd and sshd jails on Debian Bullseye and 
Buster.
we have pretty simple/standard config, with proftpd jail enabled in our file 
/etc/fail2ban/jail.d/proftpd.conf

[proftpd]
enabled = true

Some hosts use default banaction, some use banaction with ipset.
We use iptables-legacy, because we use firehol for generating our firewall.

Problem is, proftpd and sshd jails are never registered in firewall, but 
fail2ban loads them. 
Some other jails are loaded and registered in firewall without problems 
(mostly...).
For example:

# iptables -L -n -v | grep f2b
 140K 8379K DROP   all  --  *  *   0.0.0.0/00.0.0.0/0   
 match-set f2b-firehol src

# fail2ban-client status 
Status
|- Number of jail:  3
`- Jail list:   firehol, proftpd, sshd

# fail2ban-client status proftpd 
Status for the jail: proftpd
|- Filter
|  |- Currently failed: 0
|  |- Total failed: 0
|  `- File list:/var/log/proftpd/proftpd.log
`- Actions
   |- Currently banned: 0
   |- Total banned: 0
   `- Banned IP list:

and this is in log

2022-05-11 12:51:09,596 fail2ban.jail   [732814]: INFOCreating new 
jail 'proftpd'
2022-05-11 12:51:09,596 fail2ban.jail   [732814]: INFOJail 
'proftpd' uses pyinotify {}
2022-05-11 12:51:09,596 fail2ban.filter [732814]: DEBUG   Setting 
usedns = warn for FilterPyinotify(Jail('proftpd'))
2022-05-11 12:51:09,596 fail2ban.filter [732814]: DEBUG   Created 
FilterPyinotify(Jail('proftpd'))
2022-05-11 12:51:09,599 fail2ban.filter [732814]: DEBUG   Setting 
usedns = warn for FilterPyinotify(Jail('proftpd'))
2022-05-11 12:51:09,599 fail2ban.server [732814]: DEBUG prefregex: 
'^(?:\\[\\])?\\s*(?:<[^.]+\\.[^.]+>\\s+)?(?:\\S+\\s+)?(?:kernel:\\s?\\[ 
*\\d+\\.\\d+\\]:?\\s+)?(?:@vserver_\\S+\\s+)?(?:(?:(?:\\[\\d+\\])?:\\s+[\\[\\(]?proftpd(?:\\(\\S+\\))?[\\]\\)]?:?|[\\[\\(]?proftpd(?:\\(\\S+\\))?[\\]\\)]?:?(?:\\[\\d+\\])?:?)\\s+)?(?:\\[ID
 \\d+ \\S+\\]\\s+)?\\S+ \\(\\S+\\[\\]\\)[: -]+ 
(?:USER|SECURITY|Maximum) .+$'
2022-05-11 12:51:09,601 fail2ban.filter [732814]: INFOAdded 
logfile: '/var/log/proftpd/proftpd.log' (pos = 3553, hash = 
621b6cc23a2073ed6173a4b7bff999ac9705b311)
2022-05-11 12:51:09,602 fail2ban.filterpyinotify[732814]: DEBUG   New  at 0x7fe14c092ca0> dir=True >
2022-05-11 12:51:09,602 fail2ban.filterpyinotify[732814]: DEBUG   Added monitor 
for the parent directory /var/log/proftpd
2022-05-11 12:51:09,602 fail2ban.filterpyinotify[732814]: DEBUG   New  at 0x7fe14c092ca0> dir=False >
2022-05-11 12:51:09,602 fail2ban.filterpyinotify[732814]: DEBUG   Added file 
watcher for /var/log/proftpd/proftpd.log
2022-05-11 12:51:09,602 fail2ban.filterpyinotify[732814]: MSG Log absence 
detected (possibly rotation) for /var/log/proftpd/proftpd.log, reason: INITIAL 
of /var/log/proftpd/proftpd.log
2022-05-11 12:51:09,602 fail2ban.CommandAction  [732814]: DEBUG Set name = 
'proftpd'
2022-05-11 12:51:09,611 fail2ban.jail   [732814]: DEBUG   Starting jail 
'proftpd'
2022-05-11 12:51:09,611 fail2ban.filterpyinotify[732814]: DEBUG   [proftpd] 
filter started (pyinotifier)
2022-05-11 12:51:09,611 fail2ban.filterpyinotify[732814]: MSG Log presence 
detected for file /var/log/proftpd/proftpd.log
2022-05-11 12:51:09,611 fail2ban.jail   [732814]: INFOJail 
'proftpd' started
2022-05-11 12:51:23,025 fail2ban.jail   [732814]: DEBUG   Stopping jail 
'proftpd'
2022-05-11 12:51:23,025 fail2ban.filter [732814]: INFORemoved 
logfile: '/var/log/proftpd/proftpd.log'
2022-05-11 12:51:23,025 fail2ban.filterpyinotify[732814]: DEBUG   Removed file 
watcher for /var/log/proftpd/proftpd.log
2022-05-11 12:51:23,025 fail2ban.filterpyinotify[732814]: DEBUG   Removed 
monitor for the parent directory /var/log/proftpd
2022-05-11 12:51:23,127 fail2ban.filterpyinotify[732814]: DEBUG   [proftpd] 
filter exited (pyinotifier)
2022-05-11 12:51:23,628 fail2ban.actions[732814]: NOTICE  [proftpd] 
Flush ticket(s) with iptables-ipset-proto6-drop
2022-05-11 12:51:23,628 fail2ban.actions[732814]: DEBUG Unbanned 0, 
0 ticket(s) in 'proftpd'
2022-05-11 12:51:23,628 fail2ban.actions[732814]: DEBUG   proftpd: 
action iptables-ipset-proto6-drop terminated
2022-05-11 12:51:23,629 fail2ban.filterpyinotify[732814]: DEBUG   [proftpd] 
filter terminated (pyinotifier)
2022-05-11 12:51:23,629 fail2ban.jail   [732814]: INFOJail 
'proftpd' stopped
2022-05-11 12:51:23,765 fail2ban.jail   [733102]: INFOCreating new 
jail 'proftpd'
2022-05-11 12:51:23,765 fail2ban.jail   [733102]: INFOJail 
'proftpd' uses pyinotify {}
2022-05-11 12:51:23,773 fail2ban.filter [733102]: INFOAdded 
logfile: '/var/log/proftpd/proftpd.log' (pos = 3553, hash = 
621b6cc23a2073ed6173a4b7bff999ac9705b311)
2022-05-11 

Bug#1010422: transition: r-api-bioc-3.15

[Graham Inggs]

Control: tags -1 = confirmed

Hi Nilesh, Dylan

On Wed, 11 May 2022 at 11:33, Nilesh Patra  wrote:
>
>
>
> On 11 May 2022 2:06:08 pm IST, "Dylan Aïssi"  wrote:
> >Hi all,
> >
> >> Am Fri, May 06, 2022 at 06:10:52PM +0530 schrieb Nilesh Patra:
> >> >
> >> > I have done so, I think we can start the transition. Please consider 
> >> > pushing
> >> > the buttons to get the tracker up :)
> >>
> >
> >To be sure, have we the green light from the release team to start
> >this transition?
>
>
> @Graham, could you let us know? -- Should we start?

Yes, please go ahead.

Tracker is at:
https://release.debian.org/transitions/html/r-api-bioc-3.15.html

Regards
Graham

Bug#1010841: openjdk-11-jre-headless: Reduce dependency tree - are libfreetype6 (and other) really needed?

[Sascha Girrulat]

Package: openjdk-11-jre-headless
Version: 11.0.15+10-1~deb11u1
Severity: normal

Dear Maintainer,

we use debian-slim to create docker images for java based services. In
the context of the current CVEs[1] we found that the
openjdk-11-jre-headless depends to libfreetype6 in contrast to some other
distributions. Beside that we found other dependencies where we
are surprised that these packages are needed e.g. libasound2 for a
headless java setup. Is there a reason for libfreetype or it is possible
to remove this dependency to get rid of the linked CVEs[1]?

$ apt-cache depends openjdk-11-jre-headless
openjdk-11-jre-headless
  Hängt ab von: ca-certificates-java
  Hängt ab von: java-common
  Hängt ab von: libcups2
  Hängt ab von: liblcms2-2
  Hängt ab von: libjpeg62-turbo
  Hängt ab von: libfontconfig1
  Hängt ab von: libnss3
  Hängt ab von: util-linux
  Hängt ab von: libasound2
  Hängt ab von: libc6
  Hängt ab von: libfreetype6
  Hängt ab von: libgcc-s1
  Hängt ab von: libharfbuzz0b
  Hängt ab von: libpcsclite1
  Hängt ab von: libstdc++6
  Hängt ab von: zlib1g

Cheers
Sascha

[1] https://security-tracker.debian.org/tracker/CVE-2022-27406

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

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

Versions of packages openjdk-11-jre-headless depends on:
ii  ca-certificates-java  20190909
ii  java-common   0.72
ii  libasound21.2.4-1.1
ii  libc6 2.31-13+deb11u2
ii  libcups2  2.3.3op2-3+deb11u1
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.10.4+dfsg-1 
ii  libgcc-s1 10.2.1-6
ii  libharfbuzz0b 2.7.4-1
ii  libjpeg62-turbo   1:2.0.6-4
ii  liblcms2-22.12~rc1-2
ii  libnss3   2:3.61-1+deb11u1
ii  libpcsclite1  1.9.1-1
ii  libstdc++610.2.1-6
ii  util-linux2.36.1-8
ii  zlib1g1:1.2.11.dfsg-2

openjdk-11-jre-headless recommends no packages.

Versions of packages openjdk-11-jre-headless suggests:
ii  fonts-dejavu-extra 2.37-2
pn  fonts-indic
pn  fonts-ipafont-gothic   
pn  fonts-ipafont-mincho   
pn  fonts-wqy-microhei | fonts-wqy-zenhei  
ii  libnss-mdns0.14.1-2

-- no debconf information

Bug#1010840: openjdk-11-jre-headless: Reduce dependency tree - are libfreetype6 (and other) really needed?

[Sascha Girrulat]

Package: openjdk-11-jre-headless
Version: 11.0.15+10-1~deb11u1
Severity: normal

Dear Maintainer,

we use debian-slim to create docker images for java based services. In
the context of the current CVEs[1] we found that the
openjdk-11-jre-headless depends to libfreetype6 in contrast to some other
distributions. Beside that we found other dependencies where we
are surprised that these packages are needed e.g. libasound2 for a
headless java setup. Is there a reason for libfreetype or it is possible
to remove this dependency to get rid of the linked CVEs[1]?

$ apt-cache depends openjdk-11-jre-headless
openjdk-11-jre-headless
  Hängt ab von: ca-certificates-java
  Hängt ab von: java-common
  Hängt ab von: libcups2
  Hängt ab von: liblcms2-2
  Hängt ab von: libjpeg62-turbo
  Hängt ab von: libfontconfig1
  Hängt ab von: libnss3
  Hängt ab von: util-linux
  Hängt ab von: libasound2
  Hängt ab von: libc6
  Hängt ab von: libfreetype6
  Hängt ab von: libgcc-s1
  Hängt ab von: libharfbuzz0b
  Hängt ab von: libpcsclite1
  Hängt ab von: libstdc++6
  Hängt ab von: zlib1g

Cheers
Sascha

[1] https://security-tracker.debian.org/tracker/CVE-2022-27406

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

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

Versions of packages openjdk-11-jre-headless depends on:
ii  ca-certificates-java  20190909
ii  java-common   0.72
ii  libasound21.2.4-1.1
ii  libc6 2.31-13+deb11u2
ii  libcups2  2.3.3op2-3+deb11u1
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.10.4+dfsg-1 
ii  libgcc-s1 10.2.1-6
ii  libharfbuzz0b 2.7.4-1
ii  libjpeg62-turbo   1:2.0.6-4
ii  liblcms2-22.12~rc1-2
ii  libnss3   2:3.61-1+deb11u1
ii  libpcsclite1  1.9.1-1
ii  libstdc++610.2.1-6
ii  util-linux2.36.1-8
ii  zlib1g1:1.2.11.dfsg-2

openjdk-11-jre-headless recommends no packages.

Versions of packages openjdk-11-jre-headless suggests:
ii  fonts-dejavu-extra 2.37-2
pn  fonts-indic
pn  fonts-ipafont-gothic   
pn  fonts-ipafont-mincho   
pn  fonts-wqy-microhei | fonts-wqy-zenhei  
ii  libnss-mdns0.14.1-2

-- no debconf information

Bug#1010795: Fwd: Re: Bug#1010795: libnet-ssleay-perl: Autopkgtest failures on OpenSSL 3.0.* patch releases

[Simon Chopin]

Forwarding to the bug as I apparently forgot first time around.

Forwarded message from Simon Chopin (2022-05-10 19:55:05):
> Hi gregor!
>
> Quoting gregor herrmann (2022-05-10 19:36:45)
> > On Tue, 10 May 2022 09:45:00 +0200, Simon Chopin wrote:
> >
> > > In Ubuntu, we've noticed that when using OpenSSL 3.0, the autopkgtests
> > > for this package systematically fail on new upstream revisions, needing
> > > a package rebuild every time. This patch should address this issue
> > > moving forward.
> >
> > Thanks for the patch!
> >
> > I have
> > - applied it in git
> > - made a cosmetical change to make it more perl-ish (or
> >   Test::More-ish) [0]
> > - tested it lightly
>
> Thanks! This patch being the most Perl I have ever written, I'll take
> any rewrite :D
>
> > I'd rather wait for the upload of OpenSSL 3.x.x to unstable, because
> > before that a full test is rather cumbersome (the skipped tests are
> > in a 3.x.x-only branch, and setting this up in an experimental chroot
> > would require a rebuild of perl-openssl-defaults first etc.).
>
> Fair enough, I'll apply it to Ubuntu directly then.
>
> Cheers,
> Simon

Bug#994695: qreator: won't start

[Jonas Andradas]

Package: qreator
Version: 16.06.1-7
Followup-For: Bug #994695
X-Debbugs-Cc: j.andra...@gmail.com

Dear Maintainer,

I confirm I am also seeing this bug, as I am getting the same type of errors,
which prevent qreator from starting:

/usr/share/qreator/qreator_lib/Builder.py:21: PyGIWarning: Gtk was imported
without specifying a version first. Use gi.require_version('Gtk', '4.0') before
import to ensure that the right version gets loaded.
  from gi.repository import GObject, Gtk # pylint: disable=E0611
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gi/importer.py", line 142, in
load_module
introspection_module = get_introspection_module(namespace)
  File "/usr/lib/python3/dist-packages/gi/module.py", line 257, in
get_introspection_module
module = IntrospectionModule(namespace, version)
  File "/usr/lib/python3/dist-packages/gi/module.py", line 109, in __init__
repository.require(namespace, version)
gi.RepositoryError: Requiring namespace 'Gtk' version '3.0', but '4.0' is
already loaded

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/qreator", line 45, in 
import qreator
  File "/usr/share/qreator/qreator/__init__.py", line 38, in 
__import__(name, fromlist=[])
  File "/usr/share/qreator/qreator/qrcodes/QRCodeLocation.py", line 19, in

from .QRCodeLocationGtk import QRCodeLocationGtk
  File "/usr/share/qreator/qreator/qrcodes/QRCodeLocationGtk.py", line 20, in

from gi.repository import (
  File "/usr/lib/python3/dist-packages/gi/importer.py", line 144, in
load_module
raise ImportError(e)
ImportError: Requiring namespace 'Gtk' version '3.0', but '4.0' is already
loaded


Thank you very much in advance,
Best Regards,
Jonas.


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

Kernel: Linux 5.17.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages qreator depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  geoclue-2.0  2.6.0-1
ii  gir1.2-champlain-0.120.12.20-1+b1
ii  gir1.2-clutter-1.0   1.26.4+dfsg-4
ii  gir1.2-gdkpixbuf-2.0 2.42.8+dfsg-1
ii  gir1.2-geoclue-2.0   2.6.0-1
ii  gir1.2-glib-2.0  1.72.0-1+b1
ii  gir1.2-gtk-3.0   3.24.33-1
ii  gir1.2-gtkchamplain-0.12 0.12.20-1+b1
ii  gir1.2-gtkclutter-1.01.8.4-4+b1
ii  gir1.2-nm-1.01.37.92-1
ii  python3  3.10.4-1+b1
ii  python3-cairo1.20.1-3
ii  python3-dbus 1.2.18-3+b1
ii  python3-gi   3.42.1-1
ii  python3-gi-cairo 3.42.1-1
ii  python3-pil  9.1.0-1
ii  python3-qrencode 1.2-5+b5
ii  python3-requests 2.27.1+dfsg-1
ii  python3-vobject  0.9.6.1-0.2
ii  python3-xdg  0.27-2

qreator recommends no packages.

qreator suggests no packages.

-- no debconf information

Bug#1010754: unblock: spyder/5.3.0+dfsg1-7 and unblock: spyder-unittest/0.5.0-3

[Julian Gilbey]

On Tue, May 10, 2022 at 07:57:26PM +0200, Paul Gevers wrote:
> Hi Julian,
> 
> On 10-05-2022 08:43, Julian Gilbey wrote:
> > Will I need to send such a request from now on every time I upload a
> > new version of spyder, or will it remember the current state and not
> > register an autopkgtest regression?
> 
> As the test now fails on those architectures *in* testing, it will not be
> considered a regression and hence from now on it will not require our
> intervention.
> 
> Paul

Ah, thanks Paul!

Best wishes,

   Julian

Bug#1010422: transition: r-api-bioc-3.15

[Nilesh Patra]

On 11 May 2022 2:06:08 pm IST, "Dylan Aïssi"  wrote:
>Hi all,
>
>> Am Fri, May 06, 2022 at 06:10:52PM +0530 schrieb Nilesh Patra:
>> >
>> > I have done so, I think we can start the transition. Please consider 
>> > pushing
>> > the buttons to get the tracker up :)
>>
>
>To be sure, have we the green light from the release team to start
>this transition?


@Graham, could you let us know? -- Should we start?

--
Best,
Nilesh

Bug#1010839: debcontrol.vim: bad syntax highlighting for sections containing "/"

[Jakub Wilk]

Package: vim-runtime
Version: 2:8.2.4793-1
Tags: patch

vim highlights this as an error:

  Section: non-free/utils

Removing "\<" from the "syn match debcontrolSection" line fixes it for 
me.


--
Jakub Wilk

Bug#995462: bbrun: fails to build on RISC-V

[Heinrich Schuchardt]

On 5/11/22 01:24, Vagrant Cascadian wrote:

Control: tags 995462 +moreinfo

On 2021-10-01, Heinrich Schuchardt wrote:

Package: bbrun
Version: 1.6-8
Severity: normal

Building on RISC-V fails with:
cc1: error: ‘-fno-gnu89-inline’ is only supported in GNU99 or C99 mode

Please, remove debian/patches/05_gcc5-gnu89.patch


Hrm. bbrun 1.6-8 builds successfully on riscv64 with toolchains
currently in sid, as well as the few additional commits in git.

Are you still able to reproduce the failure?


The patch for supporting gcc5 could maybe be dropped regardless if it
really isn't needed anymore...


live well,
   vagrant


Building on riscv64 Ubuntu Jammy succeeds with current Debian sid sources.

As no development release uses GCC 5 the patch should be dropped anyway. 
Ubuntu Jammy and Kinetic do not contain the patch.


Best regards

Heinrich

Bug#1009598: reassigned this bug to node-postcss-loader

[Georges Khaznadar]

Hello,

the errors raised during the build of node-ktex are due to an error
which comes from node-postcss-loader

for instance :
-8<
> ERROR in ./contrib/copy-tex/copy-tex.css 
> (/usr/share/nodejs/css-loader/dist/cjs.js??ref--5-1!/usr/share/nodejs/postcss-loader/dist/cjs.js??ref--5-2!./contrib/copy-tex/copy-tex.css)
> Module build failed (from 
> /usr/share/nodejs/postcss-loader/dist/cjs.js):
> TypeError: this.getOptions is not a function
> at Object.loader 
> (/usr/share/nodejs/postcss-loader/dist/index.js:40:24)
-8<

so I reassign this bug report to node-postcss-loader

best regards,   Georges.


-- 
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#1007717: Draft resolution for "Native source package format with non-native version"

[Lucas Nussbaum]

On 10/05/22 at 17:29 -0700, Sean Whitton wrote:
> Hello,
> 
> At today's ctte meeting we considered whether we can start a vote on
> this, but two committee members were missing, and someone else at the
> meeting reported that they hadn't yet been able to spend enough time
> thinking through the issue to be ready to vote.
> 
> We came up with the following plan.  Below I've drafted a ballot.  Once
> each of those three individuals has let me know that they've had a
> chance to catch up, I'll start a vote.  The hope is that this can happen
> well in advance of our next meeting.  So, ctte members, if I don't
> already know that you're caught up, please write to me once you are.
> 
> ~
> 
> DRAFT
> 
> Using its powers under constitution 6.1.5, the Technical Committee
> issues the following advice:
> 
>   1. It is not a bug of any severity for a package with a non-native
>  version number to use a native source package format.
> 
>   2. Thus, we think that dpkg shouldn't issue warnings, or otherwise
>  complain, when a non-native version number is used w/ 3.0 (native).
> 
>   3. We suggest that the wontfix tag on #737634 be reconsidered.
> 
>   4. We believe that there are indeed circumstances in which
>  1.0-with-diff is the best choice for a particular source package,
>  including, but not limited to, git-first packaging workflows.
> 
>   5. We decline to comment on the recent source package format MBF.
> 
>  Option A -- issue items 1--5
> 
>  Option B -- issue items 1, 2, 3 and 5, but not 4
> 
>  Option N -- none of the above.
> 
> END DRAFT

Hi,

If it was possible to use 3.0 (native) with non-native revisions, would
there be remaining circumstances where 1.0-with-diff is the best choice?
If not, maybe the fact that this is the blocking issue should be made
explicit in (4)?

That would be a way to state: "either dpkg maints refuses to support 3.0
(native) with non-native revs, and 1.0-with-diff must not be considered
deprecated; or dpkg maints supports it, and it might be possible to
deprecate 1.0".

Lucas

Bug#1010838: gtk4: FTBFS on mipsel: rendering testsuite/gsk/compare/rounded-clip-in-clip-3d.node segfaults

[Simon McVittie]

Source: gtk4
Version: 4.6.3+ds1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: debian-m...@lists.debian.org
User: debian-m...@lists.debian.org
Usertags: mipsel
Control: block 1010813 by -1

During GTK 4's test suite, it carries out the drawing operations described
in testsuite/gsk/compare/rounded-clip-in-clip-3d.node, expecting the result
to match testsuite/gsk/compare/rounded-clip-in-clip-3d.png. On the mipsel
buildds, instead this resulted in a segfault.

This appears to be a regression in 4.6.3, or a regression in some
dependency (perhaps Mesa?) that changed at around the same time we
uploaded 4.6.3. I'm setting up a chroot on the porterbox 'eller' to see
whether I can get a backtrace for this.

I don't know what implications (if any) this has for practical usability
of GTK 4 applications on mipsel.

See also #993550, #1003348 which are other mips*el-specific issues in GTK4
(although they are not crashes, and they affect mips64el, which this one
does not).

smcv

Bug#1007717: attempt to summarize current state of this bug

[Lucas Nussbaum]

Hi,

On 10/05/22 at 16:57 +0100, Matthew Vernon wrote:
> 1.0-with-diff has advantages over 3.0 (quilt) particularly with git-based
> workflows, because in 3.0 (quilt) the diff is included inside the source
> tree

> The issue of preferred form for modification has been raised (source package
> in general, quilt stack, or VCS repo); Sam states that there is consensus
> both that git workflows are best practice (especially where upstream uses
> git), and that natives packages are sometimes an appropriate tool to use.
> There is a wide range of git workflows, which the occasional NMUer can avoid
> caring about by use of dgit(7).

I think that the two above paragraphs mix two different categories of
workflows:
- git-first workflows: packaging workflows that use git as the preferred
  form for modification, and use the source package format as an opaque
  output format
- git-using workflows: packaging workflows that use git for
  collaboration and tracability, but aim at producing a source package
  that is useful on its own (typically with a clean patch serie)

With this distinction made, I think that:
> 1.0-with-diff has advantages over 3.0 (quilt) particularly with git-based
> workflows, because in 3.0 (quilt) the diff is included inside the source
> tree
=> this really only applies to git-first workflows

> Sam states that there is consensus
> both that git workflows are best practice (especially where upstream uses
> git)

I think that:
- There is consensus that using a VCS, and Git in particular, for packaging
  is a best practice
- git-using workflows are a best practice (based on their usage by the
  vast majority of packages)

But I challenge that there is a consensus that git-first workflows are a
best practice. I think that they are a practice that is worth exploring
and experimenting on, but not yet widely adopted nor understood. But I
would be happy to be proven wrong (especially of based on facts).

Lucas

Bug#1010837: CVE-2022-30333 (unrar file write vulnerability) patch not yet available for Debian 10 packages

[Martin Meredith]

package: unrar
severity: grave
tags: security

-- Forwarded Message -

From: Simon Scannell 
Subject: CVE-2022-30333 (unrar file write vulnerability) patch not yet
available for Debian 10 packages
Date: May 11 2022, at 6:08 am
To: m...@debian.org
Cc: Vulnerability Research Team 


> Dear Martin,
> 
> I am contacting you as you are listed as the maintainer for the unrar
> package for Debian 10 as listed here: 
> https://debian.pkgs.org/10/debian-nonfree-arm64/unrar_5.6.6-1_arm64.deb.html
> 
> We recently reported a vulnerability (CVE-2022-30333) to RarLab. It is
> a File Write vulnerability that allows an attacker to write a file
> outside of a target extraction dir when unarchiving an untrusted RAR
> archive. We have identified a high profile software that is affected
> by this vulnerability.
> 
> The vulnerability has been patched in RarLab's upstream version 6.12
> (https://www.rarlab.com/download.htm ).
> 
> If the changelog file is up to date, it seems like the package has not
> been updated yet, so no fix is available for users.
> 
> Please view this email as a friendly heads up about this issue. Once
> the package is updated, users can secure themselves.
> 
> Thank you,
> Simon Scannell | Sonar
> 
> Vulnerability Researcher
> Twitter: @scannell_simon
> https://sonarsource.com

Bug#539340: debfoster: please add multiarch support

[Ingo Saitz]

tag 539340 +patch
thanks

Here is a small patch for ignoring :any (and other arch specifications)
in the package names of dependencies. The correct solution would be to
track and compare the architecture in the pkg_version structure.

This should also fix #1001751 which I believe happenes because debfoster
ignores python3.10:any dependencies.

The second patch is a testcase. Although they don't seem to get run on
building the package.

Ingo
-- 
 ╭─╮  Kennedy's Lemma:
╭│───╮  If you can parse Perl, you can solve the Halting Problem.
│╰─│─╯
╰──╯  http://www.perlmonks.org/?node_id=663393
>From 616b638fbf4b2a006c90d9954cce0956d7871eb9 Mon Sep 17 00:00:00 2001
From: Ingo Saitz 
Date: Wed, 11 May 2022 08:44:36 +0200
Subject: [PATCH 1/2] skip arch part of package, multiarch workaround

---
 src/vercmp.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/vercmp.c b/src/vercmp.c
index 76bd94e..3fba5ca 100644
--- a/src/vercmp.c
+++ b/src/vercmp.c
@@ -168,7 +168,7 @@ const char *parsedependency(const char *string, struct pkg_version *pv, enum dep
 /* Extract package name. */
 {
   const char *namestart = p;
-  while (*p && !cisspace(*p) && *p != '(' && *p != ',' && *p != '|') {
+  while (*p && !cisspace(*p) && *p != '(' && *p != ',' && *p != '|' && *p != ':') {
 p++;
   }
 
@@ -179,6 +179,14 @@ const char *parsedependency(const char *string, struct pkg_version *pv, enum dep
 pv->name = NULL;
 }
 
+/* skip arch part */
+if (*p == ':') {
+  p++;
+  while (*p && !cisspace(*p) && *p != '(' && *p != ',' && *p != '|') {
+p++;
+  }
+}
+
 /* skip whitespace after packagename */
 while (cisspace(*p)) p++;
 if (*p == '(') {  /* if we have a versioned relation */
-- 
2.36.1

>From c40ed30af0f92522c4a6162d05b0e025a6ad4673 Mon Sep 17 00:00:00 2001
From: Ingo Saitz 
Date: Wed, 11 May 2022 09:06:27 +0200
Subject: [PATCH 2/2] simple multiarch testcase

does not test dependency on wrong arch
---
 tests/002/available |  0
 tests/002/exp   |  0
 tests/002/keepers   |  1 +
 tests/002/status| 21 +
 4 files changed, 22 insertions(+)
 create mode 100644 tests/002/available
 create mode 100644 tests/002/exp
 create mode 100644 tests/002/keepers
 create mode 100644 tests/002/status

diff --git a/tests/002/available b/tests/002/available
new file mode 100644
index 000..e69de29
diff --git a/tests/002/exp b/tests/002/exp
new file mode 100644
index 000..e69de29
diff --git a/tests/002/keepers b/tests/002/keepers
new file mode 100644
index 000..e542435
--- /dev/null
+++ b/tests/002/keepers
@@ -0,0 +1 @@
+depends_arch_any
diff --git a/tests/002/status b/tests/002/status
new file mode 100644
index 000..b4f5680
--- /dev/null
+++ b/tests/002/status
@@ -0,0 +1,21 @@
+Package: depends_arch_any
+Architecture: amd64
+Version: 1
+Depends: libc6 (>= 2.33), perl:any, ruby:any
+Status: install ok installed
+
+Package: libc6
+Architecture: amd64
+Version: 2.33-7
+Status: install ok installed
+
+Package: perl
+Architecture: i386
+Version: 5.34.0-4
+Status: install ok installed
+
+Package: ruby
+Architecture: amd64
+Version: 1:3.0+1
+Status: install ok installed
+
-- 
2.36.1

Bug#1010422: transition: r-api-bioc-3.15

[Dylan Aïssi]

Hi all,

> Am Fri, May 06, 2022 at 06:10:52PM +0530 schrieb Nilesh Patra:
> >
> > I have done so, I think we can start the transition. Please consider pushing
> > the buttons to get the tracker up :)
>

To be sure, have we the green light from the release team to start
this transition?

Best,
Dylan

Bug#1010578: severity of bug

[Gianfranco Costamagna]

control: severity -1 normal
Hello,

On Tue, 10 May 2022 21:47:37 + (UTC) Thorsten Alteholz  
wrote:

Hi Gianfrance,

can you please explain which part of [1] makes you think that this bug 
warrants a severity of serious?


   Thorsten




I really made a big mistake, I didn't double check policy and probably either 
it changed in the last years, or my brain made a mistake in trying to remember 
what was written inside it :)

Please forgive me and my mistake.

The severity is indeed not RC, setting back to normal.

Please if possible think about fixing them all, one day systemd might be 
installed in buildd environments and all of them will become RC :)

Gianfranco


[1] https://release.debian.org/testing/rc_policy.txt

Bug#1010836: biosyntax-gedit: No longer works with recent versions of gedit

[Carl Suster]

Package: biosyntax-gedit
Version: 1.0.0b-2
Severity: important

Dear Maintainer,

The gedit support for biosyntax works by dropping files in:

/usr/share/gtksourceview-3.0/

The README.Debian says that this should cause a theme to appear in gedit at

Edit > Preferences > Font & Color > bioSyntax

No such entry appears. I notice that gedit depends on libgtksourceview-4-0 and
that there exist directories

/usr/share/gtksourceview-4/
/usr/share/gtksourceview-5/

I tested copying the style definition to the corresponding place under
gtksourceview-4/ and gedit picked it up properly, so it seems that the files
should be installed at that path instead.

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 biosyntax-gedit depends on:
ii  biosyntax-common  1.0.0b-2
ii  gedit 42.0-2

biosyntax-gedit recommends no packages.

biosyntax-gedit suggests no packages.

-- no debconf information

Bug#1010835: samba: testparm fails, lock directory /run/samba does not exist

[Arnaud Rebillout]

Source: samba
Version: 2:4.16.1+dfsg-3
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

with latest Samba in Debian sid, testparm fails if /run/samba does not
exist:

  $ testparm /etc/samba/smb.conf --suppress-prompt
  Load smb config files from /etc/samba/smb.conf
  Loaded services file OK.
  Weak crypto is allowed by gnutls library

  ERROR: lock directory /run/samba does not exist

  WARNING: pid directory /run/samba does not exist

  [...]


  $ echo $?
  1

I have submitted a merge request with a tentative fix (not tested yet,
but seems straightforward):
https://salsa.debian.org/samba-team/samba/-/merge_requests/57

Best,

  Arnaud

Bug#1010834: biosyntax-vim: Unusable with vim-addon-manager because of outdated manifest

[Carl Suster]

Package: biosyntax-vim
Version: 1.0.0b-2
Severity: important

Dear Maintainer,

The instructions in README.Debian say that the addon should be installed with
vim-addon-manager, however:

$ vim-addons install biosyntax
Warning: ignoring 'biosyntax' which is missing source files

Helpfully, vim-addon-manager can list the files it's complaining about:

$ vim-addons files biosyntax | while read -r f; do test -e 
"/usr/share/vim/addons/$f" || echo "$f"; done
ftdetect/cwl.vim
ftdetect/nexus.vim
ftdetect/pml.vim
syntax/cwl.vim
syntax/nexus.vim
syntax/pml.vim

It looks like the manifest file at debian/biosyntax-vim.yaml includes extra 
files
that are no longer included in the upstream package:


https://salsa.debian.org/med-team/biosyntax/-/blob/580479a8ea5f26f67608fa38f4910180f4136b20/debian/biosyntax-vim.yaml

vs


https://salsa.debian.org/med-team/biosyntax/-/tree/b87d9d2c964e1c30ff82ff7c0883e82576d89043/vim

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 biosyntax-vim depends on:
ii  biosyntax-common  1.0.0b-2
ii  vim   2:8.2.4793-1
ii  vim-gtk3 [vim]2:8.2.4793-1

Versions of packages biosyntax-vim recommends:
ii  vim-addon-manager  0.5.10

biosyntax-vim suggests no packages.

-- no debconf information

Bug#1009080: transition: libgit2

[Sebastian Ramacher]

On 2022-05-10 23:31:49 +0100, peter green wrote:
> libgit2-glib has now been fixed, so I believe it is time to binnmu
> git-evtag and gnome-builder, both packages were sucessfully binnmu'd
> in raspbian.

Scheduled

Cheers
-- 
Sebastian Ramacher