Bug#989975: Please rebase cloud-init to latest released version in Debian

[Yuhua Zou]

Package: cloud-init
Version: 20.2
Severity: Serious

The version of package cloud-init in official repository of Debian 10.9 is 20.2.
This version 20.2 is far behind the latest released version 21.2.
Please check https://github.com/canonical/cloud-init

With cloud-init version >=21.1, we can support the feature “guest OS 
customization with cloud-init engine” in vmware vsphere.
Would you please help rebase the package cloud-init to the latest released 
version in Debian?   Thanks

Best regards
Yuhua Zou

Bug#927209: found 927209 in 5.10.40-1

[Salvatore Bonaccorso]

Hi Sam,

On Wed, Jun 16, 2021 at 04:45:18PM +0100, Sam Morris wrote:
> found 927209 5.10.40-1

Given you are able to reproduce the issue with a recent kernel then,
could you bring the issue to upstream?

Might be similar/same to
https://bugzilla.redhat.com/show_bug.cgi?id=1572625 but that was as
well not concluded.

Regards,
Salvatore

Bug#989968: ITP: beebasm -- Portable 6502 assembler with BBC Micro style syntax

[Dave Lambley]

Package: wnpp
Severity: wishlist
Owner: Dave Lambley 

* Package name: beebasm
  Version : 1.09
  Upstream Author : Rich Talbot-Watkins 
* URL : http://www.retrosoftware.co.uk/wiki/index.php/BeebAsm
* License : GPL3+
  Programming Lang: C++
  Description : Portable 6502 assembler with BBC Micro style syntax

BeebAsm is a 6502 assembler designed specially for developing programs for the
BBC Micro. It has features not available in other cross assemblers. It uses
syntax reminiscent of BBC BASIC's built-in assembler, and is able to output
its object code directly into emulator-ready DFS disc images.

The software is stable, but continues to be maintained.

As I am not a Debian Developer, I will need a sponsor for this package.

Bug#989970: Returns "neutral" despite "-all"

[martin f krafft]

Package: libspf2-2
Version: 1.2.10-7+b5
Severity: normal

The domain `madduck.net` has a simple SPF policy:

"v=spf1 ip4:188.174.253.166/32 ip6:2001:a60:902f::bcae:fda6/128 -all"

However, both `policyd-spf` as well as `spfquery` fail to report a 
negative result when email is being delivered from another IP. The 
following shows a debug run of `spfquery`, and it yields exactly the 
same result as if `policyd-spf` saw a message with those cornerstone 
data.


```
% spfquery.libspf2 -ip 130.60.75.242 -sender madd...@madduck.net -rcpt-to 
martin@tahi.ventures -helo diamond.madduck.net -debug
spf_compile.c:523Debug: Parsing macro starting at 
Please%_see%_http://www.openspf.org/Why?id=%{S}=%{C}=%{R}
spf_compile.c:1210   Debug: Compiling record v=spf1 
spf_dns.c:54 Debug: DNS[cache] lookup: madduck.net TXT (16)
spf_dns.c:54 Debug: DNS[resolv] lookup: madduck.net TXT (16)
spf_dns.c:66 Debug: DNS[resolv] found record
spf_dns.c:69 Debug: DOMAIN: madduck.net  TYPE: TXT (16)
spf_dns.c:76 Debug: TTL: 0  RR found: 1  herrno: 0  source: resolv
spf_dns.c:94 Debug: - TXT: v=spf1 ip4:188.174.253.166/32 -all
spf_dns.c:66 Debug: DNS[cache] found record
spf_dns.c:69 Debug: DOMAIN: madduck.net  TYPE: TXT (16)
spf_dns.c:76 Debug: TTL: 0  RR found: 1  herrno: 0  source: resolv
spf_dns.c:94 Debug: - TXT: v=spf1 ip4:188.174.253.166/32 -all
spf_server.c:402 Debug: get_record(madduck.net): NETDB_SUCCESS
spf_server.c:443 Debug: found SPF record: v=spf1 ip4:188.174.253.166/32 -all
spf_compile.c:1210   Debug: Compiling record v=spf1 ip4:188.174.253.166/32 -all
spf_compile.c:1314   Debug: Name starts at  ip4:188.174.253.166/32 -all
spf_compile.c:1408   Debug: Adding mechanism type 5
spf_compile.c:847Debug: SPF_c_mech_add: type=5, value=:188.174.253.166/32 
-all
spf_compile.c:1314   Debug: Name starts at  all
spf_compile.c:1408   Debug: Adding mechanism type 8
spf_compile.c:847Debug: SPF_c_mech_add: type=8, value=
spf_interpret.c:491  Debug: ip_match:  130.60.75.242 == 188.174.253.166  (/32 
255.255.255.255):  0
--vv--
Context: Main query
Response result: fail
Response reason: mechanism
Response err: No errors
StartError
EndError
--^^--
spf_compile.c:1210   Debug: Compiling record v=spf1 mx:@tahi.ventures
spf_compile.c:1314   Debug: Name starts at  mx:@tahi.ventures
spf_compile.c:1408   Debug: Adding mechanism type 2
spf_compile.c:847Debug: SPF_c_mech_add: type=2, value=:@tahi.ventures
spf_compile.c:689Debug: Parsing domainspec starting at @tahi.ventures, cidr 
is optional
spf_compile.c:523Debug: Parsing macro starting at @tahi.ventures
spf_dns.c:54 Debug: DNS[cache] lookup: @tahi.ventures MX (15)
spf_dns.c:54 Debug: DNS[resolv] lookup: @tahi.ventures MX (15)
spf_dns_resolv.c:311 Debug: query failed: err = -1  Unknown host (1): 
@tahi.ventures
spf_dns.c:66 Debug: DNS[resolv] found record
spf_dns.c:69 Debug: DOMAIN: @tahi.ventures  TYPE: MX (15)
spf_dns.c:76 Debug: TTL: 0  RR found: 0  herrno: 1  source: resolv
spf_dns.c:66 Debug: DNS[cache] found record
spf_dns.c:69 Debug: DOMAIN: @tahi.ventures  TYPE: MX (15)
spf_dns.c:76 Debug: TTL: 0  RR found: 0  herrno: 1  source: resolv
spf_interpret.c:824  Debug: found 0 MX records for @tahi.ventures  (herrno: 1)
--vv--
Context: 2mx query
Response result: neutral
Response reason: default
Response err: No errors
StartError
EndError
--^^--
failneutral
Please see 
http://www.openspf.org/Why?id=madduck%40madduck.net=130.60.75.242=spfquery
 : Reason: default
spfquery: 130.60.75.242 is neither permitted nor denied by domain of madduck.net
Received-SPF: neutral (spfquery: 130.60.75.242 is neither permitted nor denied 
by domain of madduck.net) client-ip=130.60.75.242; 
envelope-from=madd...@madduck.net; helo=diamond.madduck.net;
```

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libspf2-2 depends on:
ii  libc6  2.31-12

libspf2-2 recommends no packages.

libspf2-2 suggests no packages.


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#913696: debdelta: Script accesses internal dpkg database

[Guillem Jover]

Hi!

[ Sorry, it seems I missed replying to this. ]

On Sat, 2019-02-02 at 10:59:05 +0100, A Mennucc1 wrote:
> I see your point;
> 
> but (as the name " dpkg_L_faster" suggests), using the dpkg commands to
> obtain meta-information is quite slow; so I will have to think about it

Ok, the dpkg_L function can be improved substantially by querying
multiple packages at once, batched up to the ARG_MAX command-line
limit. This should improve the query substantially up to or even
faster times than the current code.

If you need the entire files database, you could instead do something
like:

  ,---
  dpkg-query \
--showformat='Package: ${Package}\nFiles:\n${db-fsys:Files}\n' \
--show
  `---

> BTW: you write
> 
> >  And finally, the contents and its format, will be changing in
> > the near future.

> May you please point me to some more info regarding this change?

This would be .

Thanks,
Guillem

Bug#989969: unblock: pylint/2.7.2-3

[Sandro Tosi]

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

Please unblock package pylint

This fixes the RC bug 968897, by introducing a transitional package

[ Reason ]
fixig an RC bug

[ Impact ]
minimal/none, it's a new package

[ Tests ]
none

[ Risks ]
minimal/none

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock pylint/2.7.2-3
diff --git a/debian/changelog b/debian/changelog
index bae2d32..9a67377 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+pylint (2.7.2-3) unstable; urgency=medium
+
+  * source only upload
+
+ -- Sandro Tosi   Wed, 16 Jun 2021 21:12:44 -0400
+
+pylint (2.7.2-2) unstable; urgency=medium
+
+  * Team upload
+  * debian/control
+- Introduce pylint3 trantional package for smooth upgrade (Closes: #968897)
+
+ -- Hideki Yamane   Mon, 14 Jun 2021 23:03:38 +0900
+
 pylint (2.7.2-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/control b/debian/control
index a60b507..cca8351 100644
--- a/debian/control
+++ b/debian/control
@@ -58,7 +58,7 @@ Depends: python3-astroid (>= 2.4.0),
 Recommends: python3-tk,
 Suggests: pylint-doc,
   python3-mccabe,
-Breaks: pylint3,
+Breaks: pylint3 (<< 2.7.2-2),
 python3-pylint-django (<< 2.0),
 python3-pylint-plugin-utils (<< 0.4),
 python3-pytest-pylint (<< 0.10),
@@ -83,3 +83,9 @@ Description: Python 3 code static checker and UML diagram 
generator
* pyreverse3: an UML diagram generator
* symilar3: an independent similarities checker
* epylint3: Emacs and Flymake compatible Pylint
+
+Package: pylint3
+Architecture: all
+Depends: pylint
+Description: Transitional dummy package
+ This is transitional dummy package for pylint, you can safely remove it.

Bug#989951: The autopkgtests are failing with the new tiff version

[Robert Ancell]

This is due to the new tiff headers adding deprecation defines and is fixed
in the following PR. Not sure how active upstream is, this may be worth
carrying as a Debian patch.
https://github.com/pearu/pylibtiff/pull/128

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Gilles Filippini]

Sebastian Ramacher a écrit le 16/06/2021 à 17:22 :

Thanks for uploading the fix!

Unfortunately, the changes to the S3 virtual file driver caused
regressions in hdf5's reverse dependencies (some of them are caused by
missing dependencies for -lcrypto and -lcurl). See
https://qa.debian.org/excuses.php?package=hdf5. Could you please prepare
another upload reverting this change?


Done. I'll re-introduce this change after the release.

Best,

_g.

Bug#989967: RM: aeskeyfind [alpha arm64 armel armhf hppa m68k mips64el mipsel ppc64 ppc64el riscv64 s390x sh4 sparc64 x32] -- ANAIS; Disabled architectures

[Samuel Henrique]

Package: ftp.debian.org
X-Debbugs-Cc: samuel...@debian.org
Severity: normal

As per #989179, all the architectures but amd64 and i386 were disabled
and now the removal of cruft is required for the package to migrate to
testing.

You can get a summarized description of the issue in the unblock
request at #989918

[0] https://bugs.debian.org/989179
[1] https://bugs.debian.org/989918

Cheers,

-- 
Samuel Henrique 

Bug#982758: webext-browserpass: Failed to install on upgrade to bullseye

[Michael Meskes]

Hi all,

> Indeed. Using a clean Sid chroot, installing webext-browserpass from
> Buster and then upgrading does not exhibit this issue.

I tried with a stable chroot, then installed all the webext* packages you have
installed and then upgraded webext-browserpass. Works like a charm.

> Good question. My gut feeling at least says that the RC severity is
> justified as quite some people ran into it and it actually causes apt
> to abort in a quite nasty way.

I see your point, the problem is with this setting nobody is getting the
software because of some of us having issues in the upgrade. I'd love to get
this fixed before the freeze, but no matter what I tried I cannot reproduce.

> I currently suspect a relation to respectively overlap with a similar
> symlink/directory switch of maybe one of the directories mentioned
> above.

I thought so, too, but again, cannot identify the culprit.

> (It also seems important to not just remove but really purge the
> current package in case it was installed befotrehand. But I assume you
> either did that or used a fresh install.)

Yeah, the latter.

> Will soonish upgrade another productive Buster desktop to Bullseye
> where webext-browserpass is installed. Will have a close eye on the
> moment when upgrading webext-browserpass respectively will upgrade
> that package in a separate package upgrade from the remainder.

Did you find out anything more?

Thanks,
Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De
Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org

Bug#989963: tclap: reproducible-builds: Embeds build path, binary paths and SHELL in example Makefiles

[Dirk Eddelbuettel]

Hi there,

On 16 June 2021 at 13:52, Vagrant Cascadian wrote:
| Source: tclap
| Severity: normal
| Tags: patch
| User: reproducible-bui...@lists.alioth.debian.org
| Usertags: buildpath usrmerge shell
| X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
| 
| The build path, several binary paths, and the value of the SHELL
| variable are embedded in example Makefiles shipped in the package:
| 
|   
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/tclap.html
| 
|   /usr/share/doc/libtclap-dev/docs/Makefile.gz
| 
|   AUTOMAKE·=·${SHELL}·'/build/1st/tclap-1.2.4/config/missing'·automake-1.16
|   vs.
|   AUTOMAKE·=·${SHELL}·'/build/2/tclap-1.2.4/2nd/config/missing'·automake-1.16
| 
|   GREP·=·/bin/grep
|   vs.
|   GREP·=·/usr/bin/grep
| 
|   SHELL·=·/bin/bash
|   vs.
|   SHELL·=·/bin/sh
| 
| 
| Since these values may differ with the installed system, in order to use
| the example Makefiles, a person would have to regenerate them from
| Makefile.am or Makefile.in, which are also provided.
| 
| The attached patch removes the Makefiles in debian/rules.

Let me try that! I presume we want an upload to experimental?

Thanks for looking into this!

Dirk

| If that is somehow not an option, an alternate option would be to
| sanitize the Makefiles stripping the build path (or replacing with
| /usr/src?), and possibly passing various variables to configure
| (e.g. GREP=/bin/grep, SHELL=/bin/sh, ...).
| 
| 
| Thanks for maintaining tclap!
| 
| 
| live well,
|   vagrant
| 
| From 08de495eeae4305e7e68486e69b8b830e39e4797 Mon Sep 17 00:00:00 2001
| From: Vagrant Cascadian 
| Date: Wed, 16 Jun 2021 20:21:30 +
| Subject: [PATCH] debian/rules: Remove example Makefiles for reproducible
|  builds.
| 
| The shipped Makefiles embed build paths, the content of the SHELL
| variable, and paths to various binaries (e.g. /bin/grep
| vs. /usr/bin/grep).
| ---
|  debian/rules | 3 +++
|  1 file changed, 3 insertions(+)
| 
| diff --git a/debian/rules b/debian/rules
| index 4c64ef9..b849adf 100755
| --- a/debian/rules
| +++ b/debian/rules
| @@ -9,6 +9,9 @@ override_dh_installdocs:
|   dh_installdocs
|  # edd 10 Jun 2011 prune CVS directory
|   find debian/ -name CVS -type d | xargs rm -rf
| + # Remove example Makefiles for reproducible builds as they
| + # embed the build path, SHELL and various paths to utilities
| + find debian/ -name Makefile -type f | xargs rm -f
|  
|  override_dh_auto_test:
|   echo "Skipping checks for now"
| -- 
| 2.20.1
| 
| x[DELETED ATTACHMENT signature.asc, application/pgp-signature]

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#989966: gtk-sharp3: reproducible-builds: Set locale to ensure .dll files are reproducible

[Vagrant Cascadian]

Source: gtk-sharp3
Severity: minor
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Various .dll files such as ./usr/lib/cli/pango-sharp-3.0/pango-sharp.dll
produce different binaries depending on the locale used in
reprotest.

The attached patch sets the LC_ALL and LANG environment variables from
debian/rules to ensure the C.UTF-8 locale is used.

Thanks for maintaining gtk-sharp3!

live well,
  vagrant
From 5522089eb51dae3c1c0d4e809e0033b8501043df Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 16 Jun 2021 21:20:41 +
Subject: [PATCH 2/2] Build with C.UTF-8 locale to ensure reproducible builds
 of .dll files.

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

diff --git a/debian/rules b/debian/rules
index bedbbda..b2d623e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,10 @@
 
 DEB_API_VERSION = 2.99.3
 
+# Set locale to ensure .dll files are built reproducibly.
+export LC_ALL=C.UTF-8
+export LANG=C.UTF-8
+
 # override libdir to workaround multi-arched pkg-config paths
 override_dh_auto_configure:
 	dh_auto_configure -- \
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#989965: gtk-sharp3: reproducible-builds: Example Makefiles embed build paths and binary paths

[Vagrant Cascadian]

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

The build path, several binary paths, and the value of the SHELL
variable are embedded in example Makefiles shipped in the package:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/diffoscope-results/gtk-sharp3.html

  ACLOCAL·=·${SHELL}·/build/1st/gtk-sharp3-2.99.3/missing·aclocal-1.14
  vs.
  ACLOCAL·=·${SHELL}·/build/2/gtk-sharp3-2.99.3/2nd/missing·aclocal-1.14

  GREP·=·/bin/grep
  vs.
  GREP·=·/usr/bin/grep

  SHELL·=·/bin/bash
  vs.
  SHELL·=·/bin/sh

Since these values may differ with the installed system, in order to use
the example Makefiles, a person would have to regenerate them from
Makefile.am or Makefile.in, which are also provided.

The attached patch adjusts debian/gtk-sharp3-examples.install to avoid
installing the Makefiles.

If that is somehow not an option, an alternate option would be to
sanitize the Makefiles stripping the build path (or replacing with
/usr/src?), and possibly passing various variables to configure
(e.g. GREP=/bin/grep, SHELL=/bin/sh, ...).

Thanks for maintaining gtk-sharp3!

live well,
  vagrant
From f8cfb91164ef09f34b3f820c7fe4ad53a419bccb Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 16 Jun 2021 21:06:10 +
Subject: [PATCH 1/2] Do not install example Makefiles.

The example Makefiles embed build paths, binary paths (e.g. /bin/grep
vs. /usr/bin/grep) and the value of the SHELL variable.

Since these values may differ with the installed system, in order to use
the example Makefiles, a person would have to regenerate them from
Makefile.am or Makefile.in, which are also provided.
---
 debian/gtk-sharp3-examples.install | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/gtk-sharp3-examples.install b/debian/gtk-sharp3-examples.install
index 8d73b12..f486eca 100644
--- a/debian/gtk-sharp3-examples.install
+++ b/debian/gtk-sharp3-examples.install
@@ -2,5 +2,5 @@ sample/*.cs	/usr/share/gtk-sharp3-examples/
 sample/*.exe	/usr/share/gtk-sharp3-examples/
 sample/GtkDemo/*.cs	/usr/share/gtk-sharp3-examples/GtkDemo
 sample/GtkDemo/*.exe	/usr/share/gtk-sharp3-examples/GtkDemo
-sample/Makefile	/usr/share/gtk-sharp3-examples/
-sample/pixmaps/	/usr/share/gtk-sharp3-examples/
+sample/pixmaps/Makefile.*	/usr/share/gtk-sharp3-examples/pixmaps/
+sample/pixmaps/*.png	/usr/share/gtk-sharp3-examples/pixmaps/
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#951374: gh cli -- Getting it ready

[Brian Thompson]

Is anyone getting the gh CLI tool ready for packaging?  If not,
I can adopt it.  I use it quite heavily and am fairly familiar
with its development team if I have any questions.
-- 
Best regards,

Brian

Bug#989964: unblock (pre-approval): flatpak/1.10.2-2

[Simon McVittie]

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

Would you be willing to accept an update to flatpak before full freeze?

[ Reason ]
Fix regressions for apps that use the "subsandbox" feature, such as
Chromium.

[ Impact ]
Flatpak apps that use the subsandbox interface to run part of themselves
under tighter restrictions or with a different library stack can cause
the flatpak-portal service to run out of file descriptors, preventing
subsequent subsandboxes from starting (#989934, non-RC).
Subsandboxes might run with unintended environment variables or without
forwarding an intended file descriptor from the main app, or fail to
start altogether (#989935, non-RC). I would rate the severity of both
bugs as important, or maybe normal.

The backported changes also fix some minor memory leaks, which I backported
in order to make the subsandbox changes apply cleanly. There's no bug
report for these, but if there was, I'd rate it as minor severity.

[ Tests ]
This is a straightforward backport of changes from upstream git master
(soon to be released as 1.11.2), where they are covered by new automated
tests. The tests are somewhat intrusive so I'm not backporting those
right now, although they might be included in 1.10.3 upstream.

I've run manual tests for these two bugs on a bullseye system as described
on .

There is autopkgtest coverage for Flatpak generally, although not yet for
this specific feature. It can't be run on ci.debian.net due to not having
isolation-machine testbeds available (flatpak doesn't work inside lxc),
but I run the autopkgtests in a qemu VM before each upload.

[ Risks ]
The changes are isolated to flatpak-portal (other than a few trivial
memory-leak fixes elsewhere in the codebase), so the only programs that
could regress are Flatpak apps that use the subsandbox interface, and
those are the ones already affected by the bugs that I'm fixing.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing
  (preliminary debdiff, not yet released)

[ Other info ]
If the SRMs allow it, I would like to follow the Flatpak 1.10.x release
branch during bullseye until it is discontinued upstream, as I did
for 0.8.x in stretch and 1.2.x in buster. I am an upstream maintainer
and will be checking what gets backported into 1.10.x to make sure
it remains manageable. Like previous stable branches, it will contain
security fixes, bug fixes, and perhaps targeted feature enhancements
where they are required for compatibility with apps and runtimes that
users are likely to install.

We'll hopefully have a 1.10.3 upstream release reasonably soon, which could
either go to bullseye before release or be saved for a stable update as part
of the 11.1 point release, depending on timing and what the release team
think of the diffstat.

Thanks,
smcv
diff --git a/debian/changelog b/debian/changelog
index e4bb4964d..d36ce25db 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,21 @@
+flatpak (1.10.2-2) UNRELEASED; urgency=medium
+
+  * Backport changes from upstream git to fix regressions when apps invoke
+flatpak-spawn --env=... to launch a subsandbox.
+- d/p/Fix-several-memory-leaks.patch:
+  Fix minor memory leaks so that subsequent backports apply cleanly
+- d/p/portal-Don-t-leak-fd-used-for-serialized-environment.patch:
+  Don't leak a file descriptor each time flatpak-spawn --env=... is used
+  (Closes: #989934)
+- d/p/portal-Use-a-GArray-to-store-fds.patch,
+  d/p/portal-Remap-env-fd-into-child-process-s-fd-space.patch:
+  When an app uses flatpak-spawn --env=... --forward-fd=..., ensure
+  that the file descriptors do not collide, which could result in the
+  subsandbox failing to launch or being launched with wrong environment
+  variables. (Closes: #989935)
+
+ -- Simon McVittie   Wed, 16 Jun 2021 10:48:08 +0100
+
 flatpak (1.10.2-1) unstable; urgency=medium
 
   * New upstream stable release
diff --git a/debian/patches/Fix-several-memory-leaks.patch b/debian/patches/Fix-several-memory-leaks.patch
new file mode 100644
index 0..2f0b53064
--- /dev/null
+++ b/debian/patches/Fix-several-memory-leaks.patch
@@ -0,0 +1,86 @@
+From: Phaedrus Leeds 
+Date: Sun, 2 May 2021 21:53:02 -0500
+Subject: Fix several memory leaks
+
+(cherry picked from commit 404d7c6941baf63d1b3ccbe9ee9d34f3ff12f35f)
+
+Applied-upstream: 1.10.3, commit:b912053c6cc556f131465c1fd877d7bd0b433539
+---
+ app/flatpak-builtins-document-export.c | 6 +++---
+ common/flatpak-dir.c   | 7 ---
+ common/flatpak-utils.c | 1 +
+ portal/flatpak-portal.c| 2 +-
+ 4 files changed, 9 insertions(+), 7 deletions(-)
+
+diff --git a/app/flatpak-builtins-document-export.c b/app/flatpak-builtins-document-export.c
+index 15f1ad1..e701a82 

Bug#944968: popularity-contest: Program accesses internal dpkg database

[Guillem Jover]

On Sat, 2020-12-12 at 15:33:47 +0100, Bill Allombert wrote:
> On Thu, Nov 28, 2019 at 08:55:00PM +, Niels Thykier wrote:
> > While it would take a bit of restructuring / refactoring, I think it
> > would be possible to use a single dpkg-query for everything and still be
> > able to process the data in a "streaming" fashion.
> > 
> > As an example, using the following:
> > 
> >   dpkg-query --show \
> > --showformat='${status} ${package}\n${db-fsys:Files}\n\n'

> I am trying to implement this to see how well this perform.
> Unfortunately it seems it does not provide a stable interface across release,
> but maybe I am doing something wrong.
> 
> dpkg-query --show --showformat='${status} 
> ${package}\n${db-fsys:Files}\n\n'|head -n1
> 
> On buster:
> deinstall ok config-files 0ad
> 
> On sid:
> (Lecture de la base de données... 134812 fichiers et répertoires déjà
> installés.)

For others following along at home (and myself), this was filed as #977240,
and fixed in dpkg 1.20.6. (Was asked about a missing reply here, which I
though I was owing after fixing it, then found about the bug. :)

Thanks,
Guillem

Bug#989963: tclap: reproducible-builds: Embeds build path, binary paths and SHELL in example Makefiles

[Vagrant Cascadian]

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

The build path, several binary paths, and the value of the SHELL
variable are embedded in example Makefiles shipped in the package:

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

  /usr/share/doc/libtclap-dev/docs/Makefile.gz

  AUTOMAKE·=·${SHELL}·'/build/1st/tclap-1.2.4/config/missing'·automake-1.16
  vs.
  AUTOMAKE·=·${SHELL}·'/build/2/tclap-1.2.4/2nd/config/missing'·automake-1.16

  GREP·=·/bin/grep
  vs.
  GREP·=·/usr/bin/grep

  SHELL·=·/bin/bash
  vs.
  SHELL·=·/bin/sh


Since these values may differ with the installed system, in order to use
the example Makefiles, a person would have to regenerate them from
Makefile.am or Makefile.in, which are also provided.

The attached patch removes the Makefiles in debian/rules.

If that is somehow not an option, an alternate option would be to
sanitize the Makefiles stripping the build path (or replacing with
/usr/src?), and possibly passing various variables to configure
(e.g. GREP=/bin/grep, SHELL=/bin/sh, ...).


Thanks for maintaining tclap!


live well,
  vagrant

From 08de495eeae4305e7e68486e69b8b830e39e4797 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Wed, 16 Jun 2021 20:21:30 +
Subject: [PATCH] debian/rules: Remove example Makefiles for reproducible
 builds.

The shipped Makefiles embed build paths, the content of the SHELL
variable, and paths to various binaries (e.g. /bin/grep
vs. /usr/bin/grep).
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 4c64ef9..b849adf 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,6 +9,9 @@ override_dh_installdocs:
 	dh_installdocs
 # edd 10 Jun 2011 prune CVS directory
 	find debian/ -name CVS -type d | xargs rm -rf
+	# Remove example Makefiles for reproducible builds as they
+	# embed the build path, SHELL and various paths to utilities
+	find debian/ -name Makefile -type f | xargs rm -f
 
 override_dh_auto_test:
 	echo "Skipping checks for now"
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#989962: debian-bullseye-DI-rc2-amd64-DVD-1.iso image on flash media flash fails to boot on a system that does not support secure boot

[David George Henderson III]

Package: grub-efi-amd64

The system is a Dell Precision T1200 E3, 16GB of memory,booting off 
flash copy of debian-bullseye-DI-rc2-amd64-DVD-1.iso


Booting the rc2 version flash drive fails to go into the normal menus.

    (note bug 989810 my experiences with rc1 ; it installed as expected 
but the installed system failed to boot)


The delivers the following messages and halts(I had only a few seconds 
to capture the gist):


MoklistRT out of resources

MoklistXRT out of resources

import moc state() -- didn't have time to even get the gist of this 
error message

Bug#989839: Bug#989843: thunderbird: Problem loading page: NS_ERROR_NET_INADEQUATE_SECURITY

[Kevin Locke]

On Wed, 2021-06-16 at 11:55 -0600, Kevin Locke wrote:
> Setting a breakpoint on SSL_GetChannelInfo revealed that it is called by
> PreliminaryHandshakeDone with len = 128 by 78.10.0 and len = 136 by
> 78.11.0, which causes `len > sizeof inf` to fail and return SECFailure
> (because `sizeof inf` is 128).
> 
> It appears that SSLChannelInfo added pskType in NSS 3.54, echAccepted
> in NSS 3.60, and isFIPS in NSS 3.66.  Perhaps there is a version
> mismatch?

After a bit more testing, I realized thunderbird 1:78.10.2-1 was built
with libnss3-dev 2:3.63-1 and thunderbird 1:78.11.0-1 was built with
libnss3-dev 2:3.66-1.  I am only able to reproduce the issue with
libnss3 2:3.61-1, not libnss3 2:3.67-1 from unstable.

Cheers,
Kevin

https://buildd.debian.org/status/fetch.php?pkg=thunderbird=amd64=1%3A78.11.0-1=1622744401=0
https://buildd.debian.org/status/fetch.php?pkg=thunderbird=amd64=1%3A78.10.2-1=1621535757=0

Bug#989961: picard-tools: Wrong classpath in PicardCommandLine

[Vincent Danjean]

Package: picard-tools
Version: 2.24.1+dfsg-1
Severity: normal
Tags: patch

  Hi,

  The package correctly depends on libcommons-math3-java,
but /usr/share/java/commons-math3.jar is not added in the classpath
in /usr/bin/PicardCommandLine, leading to errors (in some situations)
such as:
[Tue Jun 15 15:59:20 CEST 2021] picard.analysis.CollectWgsMetrics done. Elapsed 
time: 135.31 minutes.
Runtime.totalMemory()=6954156032
To get help, see http://broadinstitute.github.io/picard/index.html#GettingHelp
Exception in thread "main" java.lang.NoClassDefFoundError: 
org/apache/commons/math3/random/RandomGenerator
at 
picard.analysis.CollectWgsMetrics$WgsMetrics.calculateDerivedFields(CollectWgsMetrics.java:433)
at 
picard.analysis.CollectWgsMetrics$WgsMetrics.(CollectWgsMetrics.java:248)
at 
picard.analysis.CollectWgsMetrics.generateWgsMetrics(CollectWgsMetrics.java:551)
at 
picard.analysis.CollectWgsMetrics.generateWgsMetrics(CollectWgsMetrics.java:591)
at 
picard.analysis.AbstractWgsMetricsCollector.getMetrics(AbstractWgsMetricsCollector.java:175)
at 
picard.analysis.AbstractWgsMetricsCollector.addToMetricsFile(AbstractWgsMetricsCollector.java:132)
at 
picard.analysis.WgsMetricsProcessorImpl.addToMetricsFile(WgsMetricsProcessorImpl.java:127)
at picard.analysis.CollectWgsMetrics.doWork(CollectWgsMetrics.java:494)
at 
picard.cmdline.CommandLineProgram.instanceMain(CommandLineProgram.java:295)
at 
picard.cmdline.PicardCommandLine.instanceMain(PicardCommandLine.java:103)
at picard.cmdline.PicardCommandLine.main(PicardCommandLine.java:113)
Caused by: java.lang.ClassNotFoundException: 
org.apache.commons.math3.random.RandomGenerator
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
... 11 more

  Adding the jar to the classpath in the script fixes the problem.

  Regards
Vincent

-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages picard-tools depends on:
ii  default-jre [java6-runtime] 2:1.11-72
ii  libpicard-java  2.24.1+dfsg-1
ii  openjdk-11-jre [java6-runtime]  11.0.12+4-1
ii  openjdk-17-jre [java6-runtime]  17~24-1

picard-tools recommends no packages.

picard-tools suggests no packages.

-- no debconf information

Bug#986709: Removal certainly seems like the wrong solution

[Lennart Sorensen]

Now Debian has a release with a useful package missing.  What ever
happened to orphaning a package if you didn't want to maintain it anymore?
I certainly see nothing that make the claim that it isn't suitable for
release justified.  It is working very well and does not appear to have
any serious bugs.  Good thing you didn't remove it from sid.  The removal
from bullseye was clearly wrong and unjustified.  Not the correct way
to handle a package (I am surprised it got removed in fact).

As for the idea restic is a useful replacement, not a chance.  That design
is way too complicated and they are not even at a release where they
declare the api or repo format stable.  rsnapshot nicely provides a
backup that you can look at with standard tools and recover things
however is most convinient.

And someone did just do some updates upstream and make a 1.4.4 release
a few days ago.

-- 
Len Sorensen

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Christoph Berg]

Re: Adrian Bunk
> > FEHLER:  XX000: konnte Bibliothek 
> > »/usr/lib/postgresql/11/lib/postgis-2.5.so« nicht laden: 
> > /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required 
> > by /usr/lib/x86_64-linux-gnu/libSFCGAL.so.1)
> > 
> > So there seems to be some additional incompatibility in libsfcgal1 -> libc6.
> >...
> 
> It's already in the package dependencies:
> 
> Package: libsfcgal1
> Version: 1.3.9-2
> Depends: ..., libc6 (>= 2.29),...
> 
> This won't work unless you upgrade libc6 to the bullseye version.

I think had dist-upgraded to sid at that point. Though I can repeat
the test tomorrow to be sure.

Christoph

Bug#989902: [RESOLVED] bug=989902

[null data]

After a couple of system reboots on this particular computer, this problem was 
resolved.

Two other Debian systems applied the change directly.

Thank you.

Bug#989843: thunderbird: Problem loading page: NS_ERROR_NET_INADEQUATE_SECURITY

[Davi Silva Santos]

Dear Maintainer,

I can also confirm the NS_ERROR_NET_INADEQUATE_SECURITY bug with
Thunderbird 78.11 on Debian 11 Testing, yet it seems to be limited to
Gmail accounts and the extension store.

Office 365 accounts are unaffected by the anomalous behaviour and
synchronise normally with TLS/SSL enabled.

Regards,
Davi.

Bug#989750: unblock: lxc/1:4.0.6-2

[Sebastian Ramacher]

On 2021-06-11 21:55:59 +0200, Pierre-Elliott Bécue wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package lxc
> 
> LXC 4.0.6-1 suffers from many issues that, in my opinion require an
> update before the release of Bullseye to make our users more comfortable
> using it.
> 
>  1. Running unprivileged containers until LXC4 was as simple as running
> the same LXC commands as a non-root user or as root but with
> containers config mapping subuids/subgids. Since systemd migrated to
> pure CGroupv2 hierarchy, there is a need for either a systemd
> service, or a call to systemd-run as a user. This makes the whole
> less simple to use and understand for a user.
> 
> I included two scripts to wrap these systemd-run calls and make the
> whole more usable. I linked their manpages to lxc-start and
> lxc-attach as the arguments are passed to these commands.
>  2. Consequentially, I wrote some more documentation in d/NEWS and
> d/README.Debian to help our users understanding how to work with
> unprivileged containers as soon as they will dist-upgrade.
>  3. Historically, a lxc container had its /proc/sys/net writeable by
> root when /proc was mounted with the "mixed" option in LXC
> configuration. Upstream broke that and fixed it recently in a commit
> in GitHub
> https://github.com/lxc/lxc/commit/563ec46266b8967f0ee60e0032bbe66b3b37207c
> I imported that patch as not having /proc/sys/net writeable will
> break things for our users.
>  4. In lxc-net configuration, we added a comment to allow users to honor
> systemd's dnsmasq more easily if needed. As it's a comment, it has
> no impact.
> 
> Almost all these changes are in debian/ directory and present no risk
> for LXC to dysfunction at all. There is just the patch mentioned in 3
> which is imported from upstream, and which changes the code. It has been
> tested upstream and the code alteration is minimal.
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> If you need any more intel, please do poke me!
> 
> I have not yet uploaded the changes to unstable, as I prefer waiting for
> your feedback.

ACK, please go ahead and remove the moreinfo tag once the package is
available in unstable.

Cheers

> 
> Thanks!
> 
> unblock lxc/1:4.0.6-2

> diff -Nru lxc-4.0.6/debian/changelog lxc-4.0.6/debian/changelog
> --- lxc-4.0.6/debian/changelog2021-01-31 18:29:40.0 +0100
> +++ lxc-4.0.6/debian/changelog2021-06-11 21:43:41.0 +0200
> @@ -1,3 +1,18 @@
> +lxc (1:4.0.6-2) unstable; urgency=medium
> +
> +  * d/contrib/lxc-net: Add a commented dnsmasq reference for the users to be
> +able to use this configuration if needed.
> +  * d/contrib/bin/lxc-unpriv-{start,attach} helper scripts to make
> +unprivileged containers easier to start manually
> +  * d/README.Debian: Added some intel about how to handle properly
> +unprivileged containers and systemd user sessions, and potential
> +filesystem ACL issues/implications
> +(Closes: #989317, 987293)
> +  * d/p/0007: Makes the containers able to have /proc/sys/net rw
> +(Closes: #981980)
> +
> + -- Pierre-Elliott Bécue   Fri, 11 Jun 2021 21:43:41 +0200
> +
>  lxc (1:4.0.6-1) unstable; urgency=medium
>  
>* New upstream version 4.0.6
> diff -Nru lxc-4.0.6/debian/contrib/bin/lxc-unpriv-attach 
> lxc-4.0.6/debian/contrib/bin/lxc-unpriv-attach
> --- lxc-4.0.6/debian/contrib/bin/lxc-unpriv-attach1970-01-01 
> 01:00:00.0 +0100
> +++ lxc-4.0.6/debian/contrib/bin/lxc-unpriv-attach2021-06-11 
> 21:25:58.0 +0200
> @@ -0,0 +1,13 @@
> +#!/bin/bash
> +
> +if ! ps ux|grep "[s]ystemd --user" > /dev/null 2>&1; then
> +echo "Can't start an unprivileged container on a pure CGroups v2 host 
> without a systemd user session running."
> +echo "If you are trying to get a non-interactive user to have 
> unprivileged containers running, you need to"
> +echo "enable lingering sessions for that user, via loginctl 
> enable-linger ${USER} as root."
> +exit 1
> +fi
> +
> +export XDG_RUNTIME_DIR="/run/user/$UID"
> +export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/bus"
> +
> +/usr/bin/systemd-run --user --scope -p "Delegate=yes" /usr/bin/lxc-attach 
> "$@"
> diff -Nru lxc-4.0.6/debian/contrib/bin/lxc-unpriv-start 
> lxc-4.0.6/debian/contrib/bin/lxc-unpriv-start
> --- lxc-4.0.6/debian/contrib/bin/lxc-unpriv-start 1970-01-01 
> 01:00:00.0 +0100
> +++ lxc-4.0.6/debian/contrib/bin/lxc-unpriv-start 2021-06-11 
> 21:25:42.0 +0200
> @@ -0,0 +1,13 @@
> +#!/bin/bash
> +
> +if ! ps ux|grep "[s]ystemd --user" > /dev/null 2>&1; then
> +echo "Can't start an unprivileged container on a pure CGroups v2 host 
> without a systemd user session running."
> +  

Bug#989855: [Debian-med-packaging] Bug#989855: ntcard FTBFS on 32bit: error: comparison is always true due to limited range of data type

[Étienne Mollier]

Control: tag -1 patch pending upstream
Control: forwarded -1 https://github.com/bcgsc/ntCard/pull/52

Hi, I could come up with a seemingly working patch for ntCard on
32 bit CPU.  The patch is pushed on Salsa[1] and might make it
on next package upload.

[1]: 
https://salsa.debian.org/med-team/ntcard/-/blob/master/debian/patches/32bits.patch

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/6, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#989425: Libpam-chroot/0.9-5 uploaded

[Javier Fernandez-Sanguino]

tags 989425 -moreinfo
thanks

Libpam-chroot 0.9-5 has been uploaded to unstable.

Best regards

Javier

Bug#987378: yara breaks golang-github-hillu-go-yara autopkgtest + ftbfs

[Paul Gevers]

Control: reassign -1 src:yara 4.1.0~rc2-1
Control: tags -1 = ftbfs
Control: affects -1 golang-github-hillu-go-yara
Control: retitle -1 yara causes ftbfs of + autopktest regression in 
golang-github-hillu-go-yara

Hi Hilko,

On Fri, 23 Apr 2021 22:53:52 +0200 Hilko Bengen 
wrote:> Done, see above. (I hope I have whispered the right things at
the BTS.)

notfound just removes the found version, but you claim the issue is with
yara, so it needs to be reassigned. Hopefully I got that right here.

Paul





OpenPGP_signature
Description: OpenPGP digital signature

Bug#989836: Bug#989851: pre-approval unblock: uwsgi/2.0.19.1-8

[Jonas Smedegaard]

[ replying via bugreport ]

Quoting Thomas Goirand (2021-06-16 19:20:44)
> Can I NMU uwsgi as per the discussion with the release team? Should it 
> be 2.0.19.1-7.1 or 2.0.19.1-8? Should I also open a merge request on 
> Salsa?

Yes, please use standard procedure for NMUs - i.e. release as -7.1 and 
share the changes with nmudiff (not using salsa).


Thanks,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Adrian Bunk]

On Wed, Jun 16, 2021 at 06:15:45PM +0200, Christoph Berg wrote:
>...
> $ psql cb
> psql (13.3 (Debian 13.3-1), Server 11.12 (Debian 11.12-0+deb10u1))
> 
> 17:38 cbe@cb =# select geom from country where geom is not null limit 1;
> FEHLER:  XX000: konnte Bibliothek »/usr/lib/postgresql/11/lib/postgis-2.5.so« 
> nicht laden: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found 
> (required by /usr/lib/x86_64-linux-gnu/libSFCGAL.so.1)
> 
> So there seems to be some additional incompatibility in libsfcgal1 -> libc6.
>...

It's already in the package dependencies:

Package: libsfcgal1
Version: 1.3.9-2
Depends: ..., libc6 (>= 2.29),...

This won't work unless you upgrade libc6 to the bullseye version.

> Christoph

cu
Adrian

Bug#989839: Bug#989843: thunderbird: Problem loading page: NS_ERROR_NET_INADEQUATE_SECURITY

[Kevin Locke]

Comparing the log.moz_log from running thunderbird with MOZ_LOG=nsHttp:3
and MOZ_LOG_FILE=log in the environment shows
Http2Session::ConfirmTLSProfile gets version=304 from
ssl->GetSSLVersionUsed() in 78.10.0 and version=
(nsISSLSocketControl::SSL_VERSION_UNKNOWN) in 78.11.0, which causes
Http2Session::ConfirmTLSProfile "FAILED due to lack of TLS1.2" and
INADEQUATE_SECURITY[1]:

I/nsHttp Http2Session::ConfirmTLSProfile 0x7f78dbdb7000 version=
I/nsHttp Http2Session::ConfirmTLSProfile 0x7f78dbdb7000 FAILED due to lack 
of TLS1.2
I/nsHttp Http2Session::SessionError 0x7f78dbdb7000 reason=0xc 
mPeerGoAwayReason=0x1f
I/nsHttp Http2Session::ReadSegments 0x7f78dbdb7000 returning 
INADEQUATE_SECURITY 804b0052

Setting a breakpoint on SSL_GetChannelInfo revealed that it is called by
PreliminaryHandshakeDone with len = 128 by 78.10.0 and len = 136 by
78.11.0, which causes `len > sizeof inf` to fail and return SECFailure
(because `sizeof inf` is 128).

It appears that SSLChannelInfo added pskType in NSS 3.54, echAccepted
in NSS 3.60, and isFIPS in NSS 3.66.  Perhaps there is a version
mismatch?

Best,
Kevin

[ConfirmTLSProfile]: 
https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/netwerk/protocol/http/Http2Session.cpp#l4194
[PreliminaryHandshakeDone]: 
https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/security/manager/ssl/nsNSSCallbacks.cpp#l700
[SSL_GetChannelInfo]: 
https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/security/nss/lib/ssl/sslinfo.c#l13
[SSLChannelInfo FF78]: 
https://hg.mozilla.org/releases/mozilla-esr78/file/FIREFOX_78_11_0esr_RELEASE/security/nss/lib/ssl/sslt.h#l293
[SSLChannelInfo tip]: 
https://hg.mozilla.org/mozilla-central/file/tip/security/nss/lib/ssl/sslt.h#l299

Bug#989960: RFS: sane-backends/1.0.32-2 [RC] -- API library for scanners

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "sane-backends":

   Package name: sane-backends
   Version : 1.0.32-2
   Upstream Author : 
   URL : http://www.sane-project.org
   License : LGPL-2.1+, GPL-2+ with sane exception, Artistic, 
 GFDL-1.1, GPL-2, GPL-2+, GPL-3+
   Vcs : https://jff.email/cgit/sane-backends.git
   Section : graphics

It builds those binary packages:

  libsane - API library for scanners [transitional package]
  libsane-dev - API development library for scanners [development files]
  libsane1 - API library for scanners
  libsane-common - API library for scanners -- documentation and support files
  sane-utils - API library for scanners -- utilities

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

  https://mentors.debian.net/package/sane-backends/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.0.32-2.dsc

or from

 git https://jff.email/cgit/sane-backends.git?h=release%2Fdebian%2F1.0.32-2


Changes since the last upload:

 sane-backends (1.0.32-2) experimental; urgency=high
 .
   * debian/sane-utils.postrm: Fix pathfind handling (Closes: #989879).



CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#980047: libpam-chroot: diff for NMU version 0.9-4.4

[Javier Fernandez-Sanguino]

Dear Adrian,

Thank you for preparing the NMU but please cancel it. I have just uploaded
version 0.9-5 to unstable to fix the RC bugs.
Sorry for the delay.

Best regards,

Javier


On Wed, 16 Jun 2021 at 13:48, Adrian Bunk  wrote:

> Control: tags 980047 + patch
> Control: tags 980047 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for libpam-chroot (versioned as 0.9-4.4) and
> uploaded it to DELAYED/2. Please feel free to tell me if I should cancel
> it.
>
> cu
> Adrian
>

Bug#988329: RFS: usbredir/0.9.0-1 -- Simple USB host TCP server

[Lin Qigang]

I changed this package to target experimental because of the code freeze. If I 
need to do anything else, please let me know. The repository is here 
https://salsa.debian.org/linqigang/usbredir.

Lin Qigang 
GPG Fingerprint:  8CAD 1250 8EE0 3A41 7223  03EC 7096 F91E D75D 028F

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Tuesday, June 1st, 2021 at 3:05 AM, Tobias Frost  wrote:

> Control: retitle -1 usbredir/0.9.0-1 -- [ITA] Simple USB host TCP server
> 

> Control: tags -1 moreinfo
> 

> (Retitling the RFS bug to indicate that this an ITA.)
> 

> On Mon, 10 May 2021 16:08:10 + LQi254 lqi...@protonmail.com wrote:
> 

> > This is my first package and I am very excited!
> 

> I just wanted to give you a short heads-up why you maybe did not get an 
> response
> 

> already.
> 

> First, many thanks for contributing to Debian and wanting to adpopt usbredi

signature.asc
Description: OpenPGP digital signature

Bug#989959: unbound: Corrupt/empty trust anchor file is not healed upon start

[Dennis Filder]

Package: unbound
Version: 1.13.1-1
Severity: normal
Tags: patch

I ran out of space on /var and unbound still tried to update the root
trust anchor file which ended up empty.  Then later after reboot the
package-helper failed to detect and recover from that, and
unbound.service failed to start.

With the attached patch (which adds a rudimentary sanity check) and
freshly freed disk space unbound started normally.  However, a better
solution might be to test more carefully for sufficient disk space
when making changes to the file or using 2 oversized files in rotation
and never truncating them.

Regards,
Dennis

P.S.: I also noticed that unbound.service under [Service] defines no
StateDirectory=/var/lib/unbound to ensure that it is mounted on start.
Description: Update the root trust anchor file if it fails a simple sanity check
 This uses sed instead of grep -v to print all non-comment lines as
 the latter adds a newline to its output, and we want to interpret the
 absence of a newline as indicator of corruption.
 .
 The regex could be written more specific, e.g. mention "DNSKEY" etc.
Author: Dennis Filder 
--- package-helper-orig
+++ package-helper
@@ -78,11 +78,14 @@
 if $ROOT_TRUST_ANCHOR_UPDATE; then
 if [ -n "$ROOT_TRUST_ANCHOR_FILE" ]; then
 if [ -r "$DNS_ROOT_KEY_FILE" ]; then
-if [ ! -e "$ROOT_TRUST_ANCHOR_FILE" -o "$DNS_ROOT_KEY_FILE" -nt "$ROOT_TRUST_ANCHOR_FILE" ]; then
+if [ ! -e "$ROOT_TRUST_ANCHOR_FILE" -o "$DNS_ROOT_KEY_FILE" -nt "$ROOT_TRUST_ANCHOR_FILE" \
+		   -o "$(sed -n '/^[[:space:]]*[^;]/p' < "$ROOT_TRUST_ANCHOR_FILE" | tr -cd '\n' |wc -c)" -eq 0 ]; then
 if [ ! -e "$ROOT_TRUST_ANCHOR_FILE" ]; then
 echo "$ROOT_TRUST_ANCHOR_FILE does not exist, copying from $DNS_ROOT_KEY_FILE"
 elif [ "$DNS_ROOT_KEY_FILE" -nt "$ROOT_TRUST_ANCHOR_FILE" ]; then
 echo "Overwriting older file $ROOT_TRUST_ANCHOR_FILE with newer file $DNS_ROOT_KEY_FILE"
+elif [ "$(sed -n '/^[[:space:]]*[^;]/p' < "$ROOT_TRUST_ANCHOR_FILE" | tr -cd '\n' |wc -c)" -eq 0 ]; then
+echo "Overwriting corrupt/incomplete file $ROOT_TRUST_ANCHOR_FILE with file $DNS_ROOT_KEY_FILE"
 fi
 install -m 0644 -o unbound -g unbound "$DNS_ROOT_KEY_FILE" "$ROOT_TRUST_ANCHOR_FILE"
 fi

Bug#988923: RFS: distorm3/3.5.2b-1 -- powerful disassembler library for x86/AMD64 binary streams (Python3 bindings)

[Lin Qigang]

Hi to you too!

I am targeting experimental instead. I reuploaded the package to mentors. 


Also I couldnt find documentation for new contributors for making changes to 
the Salsa git repository. Do I need to make a pull request or certain 
permissions? My repo is here https://salsa.debian.org/linqigang/distorm3

Lin Qigang 
GPG Fingerprint:  8CAD 1250 8EE0 3A41 7223  03EC 7096 F91E D75D 028F

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐

On Monday, May 31st, 2021 at 8:58 PM, Adam Borowski  wrote:

> On Fri, May 21, 2021 at 02:51:36PM +, Lin Qigang wrote:
> 

> > -   Package name : distorm3
> > 

> > Version : 3.5.2b-1
> 

> > Changes since the last upload:
> > 

> > distorm3 (3.5.2b-1) unstable; urgency=medium
> > 

> > .
> > 

> > -   New upstream release.
> > -   Removed fix_init_python patch
> > -   debian/patches: Added patch to update the library version number
> > -   debian/*.links: Updated symbolic links to new upstream version
> > -   debian/not-installed: Account for varying python3 directory naming 
> > scheme
> > -   debian/patches: Added makefile library version fix patch
> > -   debian/libdistorm3-3.symbols: Updated symbols to 3.5.2b
> > -   debian/python3-distorm: Account for varying python3 directory naming 
> > scheme
> > -   debian/rules: Account for upstream build changes
> > -   debian/copyright: Updated packaging copyright years
> > -   debian/control: Updated maintainer
> > -   Release to unstable
> 

> Hi!
> 

> This upload is targetted at unstable, which is currently affected by the
> 

> hard freeze. Only targetted fixes are permitted, not whole new upstream
> 

> releases (unless the upstream release consists of nothing but fixes...).
> 

> Thus, your options here would be:
> 

> -   targetting experimental instead, or
> -   waiting until after Bullseye is released
> 

> Meow!
> 

> --
> 

> ⢀⣴⠾⠻⢶⣦⠀ The oldest dated printed book includes the following license 
> grant:
> 

> ⣾⠁⢠⠒⠀⣿⡁ Reverently made for universal free distribution by Wang Jie
> 

> ⢿⡄⠘⠷⠚⠋⠀ on behalf of his two parents on the 15th of the 4th moon of
> 

> ⠈⠳⣄ the 9th year of Xiantong [11 May 868].

signature.asc
Description: OpenPGP digital signature

Bug#989947: ITP: gmenuharness -- GMenu harness library

[Mike Gabriel]

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

* Package name: gmenuharness
  Version : 0.1.4
  Upstream Author : Marius Gripsgard 
* URL : https://gitlab.com/ubports/core/gmenuharness/
* License : LGPL-3
  Programming Lang: C++
  Description : GMenu harness library

 This package will provide the GMenu harness shared library.
 .
 This library is useful for testing GMenuModel structures and required
 for building code components of the Lomiri Operating Environment.
 .
 This package will be maintained under the umbrella of the UBports
 Packaging Team.

Bug#989851: pre-approval unblock: uwsgi/2.0.19.1-8

[Graham Inggs]

Control: tags -1 + confirmed

On Wed, 16 Jun 2021 at 17:21, Jonas Smedegaard  wrote:
> Correct: the changes in debian/2.0.19.1-7 should not affect Debian.

Thanks.  That was fortunate timing, uwsgi/2.0.19.1-7 and
uwsgi-plugin-php/0.0.12 are both in testing now.

> Sorry for the mess.

No harm done. :-)

Thomas, please go ahead and upload to unstable, and remove the
moreinfo tag once it is built.

Bug#978649: lxqt: LXQt Debian VM Install gives two IP addresses on network interface

[mds]

You can fix this issue by removing "/etc/network/interfaces":
sudo rm /etc/network/interfaces

To avoid problems with DNS, remove also "/etc/resolv.conf":
sudo rm /etc/resolv.conf

Bug#989597: release.debian.org: upgrade issue: non-coinstallability of libgdal20 and libgdal28

[Christoph Berg]

Re: Sebastiaan Couwenberg
> Options for a working postgis database after distribution upgrade
> include recreating the databases by running your ETL process on the new
> cluster after upgrade, or using symlink hacks to workaround the
> version-in-extension-filename issue:
> 
>  http://blog.cleverelephant.ca/2016/08/postgis-upgrade.html

This is the infamous "symlink" hack that was occasionally needed in
the past, but I don't think it is necessary for this issue sind we are
talking about proper "CREATE EXTENSION postgis" installed, not the old
wild-west style with 1000 free-floating functions create in the
database.

> The hard upgrade procedure from the upstream docs may be an option too:
> 
>  http://postgis.net/docs/manual-3.1/postgis_administration.html#upgrading
> 
> In my experience, recreating the database is the simplest solution.

Before I answer this, I gave upgrading buster with
postgresql-11-postgis-2.5{,-scripts} to sid with postgresql-13-postgis-3
a try. As expected, libgdal20 and postgresql-11-postgis-2.5 were
removed during the process, and trying to access geometry data in the
old postgresql-11 database fails:

# select geom from country where geom is not null limit 1;
FEHLER:  58P01: konnte nicht auf Datei »$libdir/postgis-2.5« zugreifen: Datei 
oder Verzeichnis nicht gefunden


To see what would happen if we made libgdal20 and libgdal28
co-installable, I force-installed the old packages:

$ sudo dpkg -i --force-depends 
/var/cache/apt/archives/libgdal20_2.4.0+dfsg-1+b1_amd64.deb  
/var/cache/apt/archives/postgresql-11-postgis-2.5_2.5.1+dfsg-1_amd64.deb
[...]
Entpacken von postgresql-11-postgis-2.5 (2.5.1+dfsg-1) ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von libgdal20:
 gdal-data (3.2.2+dfsg-1) beschädigt libgdal20 (<< 2.5.0~) und ist installiert.
  Zu konfigurierende Version von libgdal20 auf dem System ist 2.4.0+dfsg-1+b1.

dpkg: Fehler beim Bearbeiten des Paketes libgdal20 (--install):
 Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: postgresql-11-postgis-2.5: Abhängigkeitsprobleme, wird aber trotzdem wie 
gefordert konfiguriert:
 postgresql-11-postgis-2.5 hängt ab von libgdal20 (>= 2.0.1); aber:
  Paket libgdal20 ist noch nicht konfiguriert.

postgresql-11-postgis-2.5 (2.5.1+dfsg-1) wird eingerichtet ...
Trigger für libc-bin (2.31-12) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
 libgdal20

Ignoring these errors I proceeded to try reading the old geometry data:

$ psql cb
psql (13.3 (Debian 13.3-1), Server 11.12 (Debian 11.12-0+deb10u1))

17:38 cbe@cb =# select geom from country where geom is not null limit 1;
FEHLER:  XX000: konnte Bibliothek »/usr/lib/postgresql/11/lib/postgis-2.5.so« 
nicht laden: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found 
(required by /usr/lib/x86_64-linux-gnu/libSFCGAL.so.1)

So there seems to be some additional incompatibility in libsfcgal1 -> libc6.


At that point, I think fixing that isn't feasible, and we should
instead put proper upgrade instructions into the release notes. My
plan would be the following:

sudo -u postgres pg_dumpall -f postgres11.dump
... do the upgrade
sudo apt install postgresql-13-postgis-3
#sudo pg_createcluster 13 main --start  # automatically created by postgresql-13
sudo -u postgres psql -p 5433 -Xf postgres11.dump

# select geom from country where geom is not null limit 1;
geom
──
 010620E6100100010

Would such instructions in the release notes be an acceptable
resolution for this bug? We can additionally point to the "hard"
upgrade instruction mentioned above for people still using the
non-extension installation methode.


> > If I am not mistaken, Andreas proposed in another thread to introduce a
> > postgis-2.5-built-against-postgresql-13 package to help with the
> > upgrades. Would this be a viable option?
> 
> No. I'm not going to maintain multiple versions of postgis.

postgis-2.5-built-against-postgresql-13 wouldn't help since we need to
get the data out of the old postgresql-11 first.

> It will be one less package I have to maintain in Debian, I can just
> chuck in my personal repo and not bother any further.

Please don't, you are doing useful work here. I appreciate your
efforts.

Christoph

Bug#942799: Stretch: Wrong startup under gdb

[Kevin Locke]

On Wed, 2021-06-16 at 09:22 -0600, Kevin Locke wrote:
> I've attached a patch which changes the quoting to fix the issue with
> the hope that you may find it more acceptable than Christophe's patch.

Please ignore the previous patch.  It was sent with insufficient testing
and did not handle the quoting in ${TB_GDB_DEFAULT_OPTS} in the way it
appears to be intended.

I've attached v2 of the patch which quotes ${TB_ARGS[@]} using
`printf ' %q'` then uses eval to perform word splitting on the combined
command string.  In my testing it handled spaces and special characters
in ${TB_GDB_DEFAULT_OPTS} and arguments following -g in the way that I
would expect.  See what you think.

Cheers,
Kevin
>From 50bcc2bb310a25fe2a1e6e39528c385c4c98569d Mon Sep 17 00:00:00 2001
Message-Id: <50bcc2bb310a25fe2a1e6e39528c385c4c98569d.1623858686.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Wed, 16 Jun 2021 09:08:10 -0600
Subject: [PATCH v2] Fix quoting for -g in thunderbird-wrapper.sh

Running `thunderbird -g` produces the following error:

INFO  -> Starting Thunderbird with GDB ...
INFO  -> LANG= /usr/bin/gdb -ex "handle SIG38 nostop" -ex "handle SIGPIPE nostop" -ex "run" /usr/lib/thunderbird/thunderbird
/usr/bin/thunderbird: line 254: /usr/bin/gdb -ex "handle SIG38 nostop" -ex "handle SIGPIPE nostop" -ex "run" /usr/lib/thunderbird/thunderbird : No such file or directory

This occurs because exec is passed a single argument, which it
interprets as a file name that does not exist.  Instead, use the
following steps:

1. Build a command string which combines ${TB_GDB_DEFAULT_OPTS} and
   ${TB_ARGS[@]} (using `printf ' %q'`).
2. Print the command string with output_info.
3. Run it using `eval` (for word splitting) and `exec` (to replace the
   shell process with gdb, as before).

Signed-off-by: Kevin Locke 
---

Changes since v1:
 - Use eval to handle quoting in ${TB_GDB_DEFAULT_OPTS}, since word
   splitting does not consider quotes in variables.

 debian/thunderbird-wrapper.sh | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/debian/thunderbird-wrapper.sh b/debian/thunderbird-wrapper.sh
index 7546724f136..b76f522654e 100755
--- a/debian/thunderbird-wrapper.sh
+++ b/debian/thunderbird-wrapper.sh
@@ -250,8 +250,9 @@ else
 if [ -f /usr/bin/gdb ]; then
 if dpkg-query -W -f='${Version}' thunderbird-dbgsym &>/dev/null ; then
 output_info "Starting Thunderbird with GDB ..."
-output_info "LANG= /usr/bin/gdb ${TB_GDB_DEFAULT_OPTS} -ex \"run\" ${MOZ_LIBDIR}/${MOZ_APP_NAME} ${TB_ARGS[@]}"
-LANG='' exec "/usr/bin/gdb ${TB_GDB_DEFAULT_OPTS} -ex \"run\" ${MOZ_LIBDIR}/${MOZ_APP_NAME} ${TB_ARGS[@]}"
+TB_ARGS_LINE="/usr/bin/gdb ${TB_GDB_DEFAULT_OPTS} -ex run ${MOZ_LIBDIR}/${MOZ_APP_NAME}$(printf ' %q' "${TB_ARGS[@]}")"
+output_info "LANG= $TB_ARGS_LINE"
+LANG='' eval "exec $TB_ARGS_LINE"
 else
 output_info "No package 'thunderbird-dbgsym' installed! Please install first and restart."
 output_info "More information how to adjust your sources.list to being able installing"
-- 
2.30.2

Bug#942799: Stretch: Wrong startup under gdb

[Kevin Locke]

On Mon, 2019-10-21 at 19:53 +0200, Carsten Schoenert wrote:
> Am 21.10.19 um 19:40 schrieb Christophe DELAHAYE:
>> I tried to run Thunderbird under GDB to characterize a crash, but the
>> command line built by the start script is wrong.
> 
> could you give please an example what is going wrong.
> This part of the script was tested several times so before I will apply
> any patch I need to understand what is causing issues.

I am able to reproduce the issue with thunderbird 1:78.11.0-1 by running
`thunderbird -g` which prints:

INFO  -> Starting Thunderbird with GDB ...
INFO  -> LANG= /usr/bin/gdb -ex "handle SIG38 nostop" -ex "handle SIGPIPE 
nostop" -ex "run" /usr/lib/thunderbird/thunderbird 
/usr/bin/thunderbird: line 254: /usr/bin/gdb -ex "handle SIG38 nostop" -ex 
"handle SIGPIPE nostop" -ex "run" /usr/lib/thunderbird/thunderbird : No such 
file or directory

Then exits with code 127.  The issue occurs because exec is passed a
single argument on line 254, which bash interprets as a path that does
not exist.

I've attached a patch which changes the quoting to fix the issue with
the hope that you may find it more acceptable than Christophe's patch.

Thanks for considering,
Kevin
>From 119b82022ef8887aea70b0104922a38ce9e020cb Mon Sep 17 00:00:00 2001
Message-Id: <119b82022ef8887aea70b0104922a38ce9e020cb.1623856383.git.ke...@kevinlocke.name>
From: Kevin Locke 
Date: Wed, 16 Jun 2021 09:08:10 -0600
Subject: [PATCH] Fix quoting for -g in thunderbird-wrapper.sh

Running `thunderbird -g` produces the following error:

INFO  -> Starting Thunderbird with GDB ...
INFO  -> LANG= /usr/bin/gdb -ex "handle SIG38 nostop" -ex "handle SIGPIPE nostop" -ex "run" /usr/lib/thunderbird/thunderbird
/usr/bin/thunderbird: line 254: /usr/bin/gdb -ex "handle SIG38 nostop" -ex "handle SIGPIPE nostop" -ex "run" /usr/lib/thunderbird/thunderbird : No such file or directory

This occurs because exec is passed a single argument, which it
interprets as a file name that does not exist.  Remove the surrounding
quotes so that each argument is passed separately.

Signed-off-by: Kevin Locke 
---
 debian/thunderbird-wrapper.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/thunderbird-wrapper.sh b/debian/thunderbird-wrapper.sh
index 7546724f136..2e088812b72 100755
--- a/debian/thunderbird-wrapper.sh
+++ b/debian/thunderbird-wrapper.sh
@@ -251,7 +251,7 @@ else
 if dpkg-query -W -f='${Version}' thunderbird-dbgsym &>/dev/null ; then
 output_info "Starting Thunderbird with GDB ..."
 output_info "LANG= /usr/bin/gdb ${TB_GDB_DEFAULT_OPTS} -ex \"run\" ${MOZ_LIBDIR}/${MOZ_APP_NAME} ${TB_ARGS[@]}"
-LANG='' exec "/usr/bin/gdb ${TB_GDB_DEFAULT_OPTS} -ex \"run\" ${MOZ_LIBDIR}/${MOZ_APP_NAME} ${TB_ARGS[@]}"
+LANG='' exec /usr/bin/gdb ${TB_GDB_DEFAULT_OPTS} -ex run "${MOZ_LIBDIR}/${MOZ_APP_NAME}" "${TB_ARGS[@]}"
 else
 output_info "No package 'thunderbird-dbgsym' installed! Please install first and restart."
 output_info "More information how to adjust your sources.list to being able installing"
-- 
2.30.2

Bug#989958: libopencv-*-dev: Missing pkg-config file (.pc)

[Alejandro Colomar]

Package: libopencv-core-dev
Version: 4.5.1+dfsg-4
Severity: important
Tags: upstream
X-Debbugs-Cc: alx.manpa...@gmail.com

Dear Maintainer,

This bug actually does apply to all of the *-dev libopencv packages.

None of them contain the needed pkg-conig files for their use, making
necessary to install 'libopencv', and making useless the separation into
smaller packages.

If you can't install that file in every binary package, you may
create a new binary package that only contains the .pc file,
let's say libopencv-pc, and make all packages depend on it.


Thanks,

Alex


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

Kernel: Linux 5.10.0-6-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, 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 libopencv-core-dev depends on:
ii  libopencv-core4.5  4.5.1+dfsg-4
ii  libtbb-dev 2020.3-1
ii  zlib1g-dev 1:1.2.11.dfsg-2

libopencv-core-dev recommends no packages.

libopencv-core-dev suggests no packages.

-- no debconf information

Bug#989936: make clean should clean images-tmp dir

[Wolfgang Schweer]

[ hox...@noramail.jp, 2021-06-16 ]
> Package: debian-edu-doc
> Version: 2.11.24
> Severity: wishlist
> 
> Dear Debian Edu team,
> 
> After making "make" error on .po task such like syntax error,
> debian-edu-doc/documentation/common/Makefile.common fails at
> "mkdir images-tmp". 
> 
> Since "make clean" does not purge that tmp dir,
> "make" keep failing even after fixing the error on .po file.
 
Thanks, confirmed. This should be fixed for Bookworm.

Wolfgang


signature.asc
Description: PGP signature

Bug#989937: some non CDATA commands are hard to read

[Wolfgang Schweer]

[ hox...@noramail.jp, 2021-06-16 ]
> Package: debian-edu-doc
> Version:2.11.24
> Severity: wishlist
> 
> Dear Debian Edu team,
> 
> Some commands for upgrading written in section 12 "upgrade"
> are "listitem" type in po files (not "CDATA").
> 
> As a result some of crucial texts are rendered as
> list items which I think it could confuse readers a bit
> (by depth of list and wrap on browser).
> 
> e.g. 12.2.1. ldapvi manipulation (iPXE)
> 
> Perhaps "computeroutput" and/or "CDATA" be nice,
> for both readers and translators, I think.
 
Thanks for the hint. The related chapter has been reworked (waiting for 
revision), see:
https://wiki.debian.org/DebianEdu/Documentation/Bullseye/Upgrades

Wolfgang


signature.asc
Description: PGP signature

Bug#989851: pre-approval unblock: uwsgi/2.0.19.1-8

[Jonas Smedegaard]

Quoting Graham Inggs (2021-06-16 17:12:00)
> Hi Thomas, Jonas
> 
> On Wed, 16 Jun 2021 at 16:07, Thomas Goirand  wrote:
> > I'm hereby attaching the output of:
> > git diff -u -r debian/2.0.19.1-6 -r debian/2.0.19.1-7
> 
> Thanks.
> 
> > Maybe you could unblock debian/2.0.19.1-7 considering this is a 
> > target patch? Otherwise, Jonas may agree to revert the patch?
> 
> According to the upstream commit message, these TSRMLS_* macros were 
> inert since PHP 7.  If you and Jonas can agree that this makes no 
> difference for bullseye, then I will unblock uwsgi/2.0.19.1-7 and let 
> uwsgi-plugin-php/0.0.12 migrate.  Thereafter, you can upload 
> uwsgi/2.0.19.1-8.

Correct: the changes in debian/2.0.19.1-7 should not affect Debian.

Sorry for the mess.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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

signature.asc
Description: signature

Bug#988722: postgresql-common: Upgrading cluster with postgis does not migrate tables using postgis

[Sebastian Ramacher]

Hi

On 2021-06-14 20:21:05, Gilles Filippini wrote:
> Hi Andreas,
> 
> Andreas Beckmann a écrit le 14/06/2021 à 10:18 :
> > On 08/06/2021 13.05, Sebastian Ramacher wrote:
> > > > Here it is. Now testing upgrades ...
> > > > There were some new symbols ... but they appeared independently of my
> > > > changes (I built in bullseye, not sid, in case it does matter).
> > 
> > Tests have not shown any problems. And in combination with patched gdal
> > and friends we have achieved co-installability ;-)
> 
> This is good news. Thanks for this work.
> 
> > > Thanks Andreas! Once that tests are done and the packages was uploaded,
> > > please let me know so that I can add the appropriate hints on the
> > > release team side.
> > > 
> > > FWIW, the symbol is a template instantiation of a function from the
> > > standard library and should be marked as optional.
> > 
> > Attached is a new version of the patch. Some wording was tweaked and
> > 'optional' added.
> > 
> > The new packages are still available as cruft in sid, so we should be
> > able to avoid NEW.
> > 
> > Gilles, do you want to do the upload or shall I NMU it?
> 
> I'll try to upload this evening.

Thanks for uploading the fix!

Unfortunately, the changes to the S3 virtual file driver caused
regressions in hdf5's reverse dependencies (some of them are caused by
missing dependencies for -lcrypto and -lcurl). See
https://qa.debian.org/excuses.php?package=hdf5. Could you please prepare
another upload reverting this change?

Thanks in advance

Cheers
Sebastian
-- 
Sebastian Ramacher

Bug#989945: libbackuppc-xs-perl FTCBFS: missing dependency on perl-xs-dev

[Axel Beckert]

Hi Helmut,

Helmut Grohne wrote:
> On Wed, Jun 16, 2021 at 03:28:44PM +0200, Axel Beckert wrote:
> > I noticed that you didn't specify a severity — which implies just a
> > "normal" severity. So I assume this is nothing which needs to go in
> > for bullseye, right?
> 
> This is all correct. I tend to drop the severity as unnecessary line
> noise.

Ok. I tend to only remove it if I don't care about the actual
severity, i.e. as a hint to the maintainer to decide on the severity
on its own and that I won't argue on severity changes.

> In general, when I file bugs at non-rc severity during (any kind
> of) freeze, I do point out when I think it should be fixed for a
> particular release. When there is any kind of urgency, I say so
> explicitly in the submission.

That's definitely a good practice.

I mostly asked because FTBFS is usually of RC-severity and from my
point of view, FTCBFS is not that far away from FTBFS.

> The question of whether normal bugs should be fixed during freeze

JFTR: I didn't ask that. I more or less asked if you forgot to set a
(RC-) severity, because it looked like the bug report was not written
with reportbug (or M-x debian-bug) as the typical reportbug footer was
missing as well. And it happens not seldom that the one or other
pseudo header gets forgotten when bug reports are written manually in
a mail client. BTDT. (Didn't check the mail headers back then. Did so
now and to my surprise the bug report was actually written with
reportbug. Oh well. :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#989851: pre-approval unblock: uwsgi/2.0.19.1-8

[Graham Inggs]

Hi Thomas, Jonas

On Wed, 16 Jun 2021 at 16:07, Thomas Goirand  wrote:
> I'm hereby attaching the output of:
> git diff -u -r debian/2.0.19.1-6 -r debian/2.0.19.1-7

Thanks.

> Maybe you could unblock debian/2.0.19.1-7 considering this is a target
> patch? Otherwise, Jonas may agree to revert the patch?

According to the upstream commit message, these TSRMLS_* macros were
inert since PHP 7.  If you and Jonas can agree that this makes no
difference for bullseye, then I will unblock uwsgi/2.0.19.1-7 and let
uwsgi-plugin-php/0.0.12 migrate.  Thereafter, you can upload
uwsgi/2.0.19.1-8.

Regards
Graham

Bug#989957: pocsuite3/1.7.5-1 [ITP] -- an open-sourced remote vulnerability testing framework.

[Tian]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: pocsuite3
   Version : 1.7.5-1
   Upstream Author : fenix from knownsec 404 team 
 * URL : http://pocsuite.org
 * License : GPL2.0
 * Vcs : https://github.com/knownsec/pocsuite3
   Section : python3

It builds those binary packages:

  pocsuite3 - an open-sourced remote vulnerability testing framework.

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pocsuite3/pocsuite3_1.7.5-1.dsc

Changes for the initial release:

 pocsuite3 (1.7.5-1) unstable; urgency=low
 .
   * source package automatically created by stdeb 0.10.0

Regards,
-- 
  fenix

Bug#989956: libopenmpt: new upstream release branch 0.5

[Jörn Heusipp]

Source: libopenmpt
Version: 0.4.11
Severity: wishlist
X-Debbugs-Cc: osm...@problemloesungsmaschine.de

Dear Maintainer,

Updating to libopenmpt 0.5 will involve changes in packaging because we 
(libopenmpt upstream) have split out the libopenmpt-modplug emulation layer 
into a completely separate upsteam package. See 
,
 
,
 . 
In the end, this will simplify future updates to libopenmpt-modplug, because we 
can now follow libmodplug API and ABI changes more closely and independently of 
libopenmpt versions and API/ABI guarantees.

Updating to libopenmpt 0.5 and libopenmpt-modplug 0.8.9.0-openmpt1 (same ABI 
change as in the matching libmodplug version) will also fix #958377.

If you encounter any problems updating, or have suggestions which we can 
integrate to make packaging and updating easier, please feel free to contact me.


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, s390x, armhf, arm64, ppc64el

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#989955: libopenmpt: new upstream release 0.4.21

[Jörn Heusipp]

Source: libopenmpt
Version: 0.4.11
Severity: important
X-Debbugs-Cc: osm...@problemloesungsmaschine.de

Dear Maintainer,

libopenmpt 0.4.x has new upstream release 0.4.21. This fixes, amongst many 
other fixes, a security vulnerability:
https://lib.openmpt.org/libopenmpt/2021/04/11/security-updates-0.5.8-0.4.20-0.3.29/

I'm the libopenmpt upstream maintainer. If you encounter any problems updating, 
please feel free to contact me and ask for assistence.

Seeing that Debian 11 is going into freeze soon, I highly suggest updating to 
the latest libopenmpt version now.

If updating to 0.5 causes too much trouble by now, updating to at least 0.4.21 
should be trivial. Even though libopenmpt deprecated the included 
libopenmpt-modplug emulation layer in 0.4.13 (see 
), 
0.4.x still continues (and will continue) to ship it (staying with libmodplug 
0.8.8.5 API/ABI).

Updating to 0.5 and the split-out libopenmpt-modplug package will be required 
to fix #958377 though, which appears to be desireable to support VLC.


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, s390x, armhf, arm64, ppc64el

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#989954: cif-api FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: cif-api
Version: 0.4.2-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

cif-api fails to cross build from source, because the upstream configure
script uses the build architecture pkg-config. The simple solution is to
replace the relevant AC_PATH_PROG with AC_PATH_TOOL. A better solution
would likely be using PKG_CHECK_MODULES. Please consider applying the
attached patch for the simple solution.

Helmut
--- cif-api-0.4.2.orig/m4/ax_icuio.m4
+++ cif-api-0.4.2/m4/ax_icuio.m4
@@ -43,7 +43,7 @@
   AC_LANG_PUSH([C])
   AC_REQUIRE([AC_PROG_CPP])dnl
   AC_REQUIRE([AC_PROG_SED])dnl
-  AC_PATH_PROG([PKG_CONFIG], [pkg-config], [:])
+  AC_PATH_TOOL([PKG_CONFIG], [pkg-config], [:])
   AS_IF([test "${PKG_CONFIG}" = :], [AC_MSG_ERROR([The 'pkg-config' command was not found])])
 
   ICU_PKG=

Bug#989953: imgvtopgm FTCBFS: builds for the build architecture

[Helmut Grohne]

Source: imgvtopgm
Version: 2.0-9
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

imgvtopgm fails to cross build from source, because it configures for
the build architecture. Unfortunately, its configure script is too old
to understand the --host flag. Instead, one is supposed to export the
cross tools via the environment. The easiest way of doing so - deferring
the task to dpkg's buildtools.mk - makes imgvtopgm cross buildable.
Please consider applying the attached patch.

Helmut
diff -u imgvtopgm-2.0/debian/changelog imgvtopgm-2.0/debian/changelog
--- imgvtopgm-2.0/debian/changelog
+++ imgvtopgm-2.0/debian/changelog
@@ -1,3 +1,10 @@
+imgvtopgm (2.0-9.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Export cross tools for configure. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 16 Jun 2021 16:59:10 +0200
+
 imgvtopgm (2.0-9) unstable; urgency=low
 
   * debian/control:
diff -u imgvtopgm-2.0/debian/rules imgvtopgm-2.0/debian/rules
--- imgvtopgm-2.0/debian/rules
+++ imgvtopgm-2.0/debian/rules
@@ -7,6 +7,9 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+DPKG_EXPORT_BUILDTOOLS=1
+-include /usr/share/dpkg/buildtools.mk
+
 CFLAGS = -Wall
 
 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))

Bug#989952: libopenmpt: missing security patches (r12118, r14531) in stable

[Jörn Heusipp]

Source: libopenmpt
Version: 0.4.3
Severity: normal
Tags: upstream
X-Debbugs-Cc: osm...@problemloesungsmaschine.de

Dear Maintainer,

It looks like libopenmpt in Debian 10 Buster (stable) is missing patches for 
the following security vulnerabilities:

libopenmpt 0.4.8 (2019-09-30)
[Sec] Possible crash due to out-of-bounds read when playing an OPL note 
with active filter in S3M or MPTM files (r12118).
https://source.openmpt.org/browse/openmpt?op=comp[]=%2Fbranches%2FOpenMPT-1.28@12116[]=%2Fbranches%2FOpenMPT-1.28%2F@12118
https://github.com/OpenMPT/openmpt/commit/5b6503eeb35ae41e496a23640c7750351e808ea7

libopenmpt 0.4.20 (2021-04-11)
[Sec] Possible null-pointer dereference read caused by a sequence of 
openmpt::module::read, openmpt::module::set_position_order_row pointing to an 
invalid pattern, and another openmpt::module::read call. To trigger the crash, 
pattern 0 must not exist in the file and the tick speed before the position 
jump must be lower than the initial speed of the module. (r14531)
https://source.openmpt.org/browse/openmpt?op=comp[]=%2Fbranches%2FOpenMPT-1.28@14520[]=%2Fbranches%2FOpenMPT-1.28%2F@14531
https://github.com/OpenMPT/openmpt/commit/b6f4b8a731576b77afc2cc73441991e110a72252

If you encounter any trouble or problems backporting the fixes to 0.4.3, please 
feel free to ask for help, as I am the libopenmpt upstream maintainer.


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, s390x, armhf, arm64, ppc64el

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
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=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#989951: The autopkgtests are failing with the new tiff version

[Sebastien Bacher]

Package: pylibtiff
Version:  0.4.2-6

The autopkgtests are failing with tiff/4.3.0 from experimental
https://ci.debian.net/packages/p/pylibtiff/unstable/amd64/

'NameError: name '__attribute__' is not defined'

Bug#989950: libconfig-model-dpkg-perl: Add support for output without wild cards

[Walter Lozano]

Package: libconfig-model-dpkg-perl
Version: 2.132
Severity: wishlist

Dear Maintainer,

I would like to have the option to generate a report without using wildcards,
since that makes it self-contained. This is useful in cases where the report is
consumed by other systems.

To allow it, I proposed a MR to add the support for optional argument "long"
which avoid squashing copyright_id.

https://salsa.debian.org/perl-team/modules/packages/libconfig-model-dpkg-
perl/-/merge_requests/4



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

Kernel: Linux 5.8.0-55-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libconfig-model-dpkg-perl depends on:
ii  debhelper  12.10ubuntu1
ii  libapt-pkg-perl0.1.36build3
ii  libarray-intspan-perl  2.003-1
ii  libconfig-model-backend-yaml-perl  2.133-2
ii  libconfig-model-perl   2.138-2
ii  libexporter-lite-perl  0.08-1
ii  liblog-log4perl-perl   1.49-1
ii  libmouse-perl  2.5.9-1
ii  libparse-recdescent-perl   1.967015+dfsg-2
ii  libsoftware-licensemoreutils-perl  1.004-1
ii  libsort-versions-perl  1.62-1
ii  libtext-autoformat-perl1.75-1
ii  libtext-levenshtein-damerau-perl   0.41-1
ii  liburi-perl1.76-2
ii  libwww-perl6.43-1
ii  libyaml-libyaml-perl   0.81+repack-1
ii  licensecheck   3.0.45-1
ii  lintian2.62.0
ii  perl [libmodule-corelist-perl] 5.30.0-9ubuntu0.2

Versions of packages libconfig-model-dpkg-perl recommends:
ii  libconfig-model-tkui-perl  1.371-2

libconfig-model-dpkg-perl suggests no packages.

-- no debconf information

Bug#989851: pre-approval unblock: uwsgi/2.0.19.1-8

[Thomas Goirand]

On 6/16/21 1:14 PM, Graham Inggs wrote:
> Control: tags -1 + moreinfo
> 
> Hi Thomas
> 
> On Mon, 14 Jun 2021 at 21:12, Thomas Goirand  wrote:
>>   [x] attach debdiff against the package in testing
> 
> You've attached a debdiff against uwsgi/2.0.19.1-7 in unstable, which
> is currently blocked [1].
> I think it will be best if 2.0.19.1-7 migrates to testing before you
> go ahead and upload.
> 
> Someone needs to file an unblock request justifying the changes
> between 2.0.19.1-6 and 2.0.19.1-7, hence including Jonas in this
> discussion.
> 
> Regards
> Graham
> 
> 
> [1] https://qa.debian.org/excuses.php?package=uwsgi
> 

Hi Graham,

As you may see in https://bugs.debian.org/989191 the release -7 just
adds a patch to avoid FTBFS in Focal, which Jonas uploaded by mistake to
Sid thinking Sid was affected.

I'm hereby attaching the output of:
git diff -u -r debian/2.0.19.1-6 -r debian/2.0.19.1-7

(which hopefully matches the debdiff)

Maybe you could unblock debian/2.0.19.1-7 considering this is a target
patch? Otherwise, Jonas may agree to revert the patch?

Cheers,

Thomas Goirand (zigo)
diff --git a/debian/changelog b/debian/changelog
index 7b1449f8..70389417 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+uwsgi (2.0.19.1-7) unstable; urgency=medium
+
+  * add patch cherry-picked upstream
+to remove PHP TSRMLS_* macros;
+unfuzz another upstream cherry-picked patch;
+see bug#989191, thanks to Bryce Harrington
+
+ -- Jonas Smedegaard   Fri, 28 May 2021 07:56:03 +0200
+
 uwsgi (2.0.19.1-6) unstable; urgency=medium
 
   * fix permissions of runtime dir in uwsgi-emperor;
diff --git a/debian/patches/020210221~0f2ef52.patch 
b/debian/patches/020210221~0f2ef52.patch
new file mode 100644
index ..379d9795
--- /dev/null
+++ b/debian/patches/020210221~0f2ef52.patch
@@ -0,0 +1,252 @@
+escription: plugins/php: remove TSRMLS_* macros
+ They are gone in PHP 8 and were inert since PHP 7.
+Origin: upstream, https://github.com/unbit/uwsgi/commit/0f2ef52
+Author: Riccardo Magliocchetti 
+Forwarded: yes
+Last-Update: 2021-05-28
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/plugins/php/php_plugin.c
 b/plugins/php/php_plugin.c
+@@ -74,7 +74,7 @@
+ 
+ 
+ #ifdef UWSGI_PHP7
+-static size_t sapi_uwsgi_ub_write(const char *str, size_t str_length 
TSRMLS_DC)
++static size_t sapi_uwsgi_ub_write(const char *str, size_t str_length)
+ #else
+ static int sapi_uwsgi_ub_write(const char *str, uint str_length TSRMLS_DC)
+ #endif
+@@ -89,7 +89,7 @@
+   return str_length;
+ }
+ 
+-static int sapi_uwsgi_send_headers(sapi_headers_struct *sapi_headers 
TSRMLS_DC)
++static int sapi_uwsgi_send_headers(sapi_headers_struct *sapi_headers)
+ {
+   sapi_header_struct *h;
+   zend_llist_position pos;
+@@ -124,7 +124,7 @@
+ }
+ 
+ #ifdef UWSGI_PHP7
+-static size_t sapi_uwsgi_read_post(char *buffer, size_t count_bytes TSRMLS_DC)
++static size_t sapi_uwsgi_read_post(char *buffer, size_t count_bytes)
+ #else
+ static int sapi_uwsgi_read_post(char *buffer, uint count_bytes TSRMLS_DC)
+ #endif
+@@ -151,7 +151,7 @@
+ }
+ 
+ 
+-static char *sapi_uwsgi_read_cookies(TSRMLS_D)
++static char *sapi_uwsgi_read_cookies()
+ {
+   uint16_t len = 0;
+   struct wsgi_request *wsgi_req = (struct wsgi_request *) 
SG(server_context);
+@@ -164,55 +164,55 @@
+   return NULL;
+ }
+ 
+-static void sapi_uwsgi_register_variables(zval *track_vars_array TSRMLS_DC)
++static void sapi_uwsgi_register_variables(zval *track_vars_array)
+ {
+   int i;
+   struct wsgi_request *wsgi_req = (struct wsgi_request *) 
SG(server_context);
+-  php_import_environment_variables(track_vars_array TSRMLS_CC);
++  php_import_environment_variables(track_vars_array);
+ 
+   if (uphp.server_software) {
+   if (!uphp.server_software_len) uphp.server_software_len = 
strlen(uphp.server_software);
+-  php_register_variable_safe("SERVER_SOFTWARE", 
uphp.server_software, uphp.server_software_len, track_vars_array TSRMLS_CC);
++  php_register_variable_safe("SERVER_SOFTWARE", 
uphp.server_software, uphp.server_software_len, track_vars_array);
+   }
+   else {
+-  php_register_variable_safe("SERVER_SOFTWARE", "uWSGI", 5, 
track_vars_array TSRMLS_CC);
++  php_register_variable_safe("SERVER_SOFTWARE", "uWSGI", 5, 
track_vars_array);
+   }
+ 
+   for (i = 0; i < wsgi_req->var_cnt; i += 2) {
+   php_register_variable_safe( 
estrndup(wsgi_req->hvec[i].iov_base, wsgi_req->hvec[i].iov_len),
+   wsgi_req->hvec[i + 1].iov_base, wsgi_req->hvec[i + 
1].iov_len,
+-  track_vars_array TSRMLS_CC);
++  track_vars_array);
+ }
+ 
+-  php_register_variable_safe("PATH_INFO", wsgi_req->path_info, 
wsgi_req->path_info_len, track_vars_array TSRMLS_CC);
++  php_register_variable_safe("PATH_INFO", wsgi_req->path_info, 
wsgi_req->path_info_len, 

Bug#989945: libbackuppc-xs-perl FTCBFS: missing dependency on perl-xs-dev

[Helmut Grohne]

Hi Axel,

On Wed, Jun 16, 2021 at 03:28:44PM +0200, Axel Beckert wrote:
> I noticed that you didn't specify a severity — which implies just a
> "normal" severity. So I assume this is nothing which needs to go in
> for bullseye, right?

This is all correct. I tend to drop the severity as unnecessary line
noise. In general, when I file bugs at non-rc severity during (any kind
of) freeze, I do point out when I think it should be fixed for a
particular release. When there is any kind of urgency, I say so
explicitly in the submission.

I do wonder though whether I should include a faq in my bug submissions.
The question of whether normal bugs should be fixed during freeze does
come up more than once even though it is answered by the freeze policy
already.

Helmut

Bug#989949: poedit: ships /usr/share/icons/hicolor/icon-theme.cache

[Andreas Beckmann]

Package: poedit
Version: 3.0-5
Severity: serious

poedit has a file conflict with other buggy packages shipping the
icon-theme.cache, too

Andreas

Bug#988715: atmel-firmware: diff for NMU version 1.3-4.1

[Adrian Bunk]

Control: tags 988715 + patch
Control: tags 988715 + pending

Dear maintainer,

I've prepared an NMU for atmel-firmware (versioned as 1.3-4.1) and uploaded
it to DELAYED/2. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -u atmel-firmware-1.3/debian/rules atmel-firmware-1.3/debian/rules
--- atmel-firmware-1.3/debian/rules
+++ atmel-firmware-1.3/debian/rules
@@ -34,6 +34,7 @@
 		-d debian/tmp/usr/share/man/man8\
 	-d debian/tmp/usr/share/doc/$(package)
 	install -m 755 debian/postinst debian/tmp/DEBIAN
+	install -m 644 debian/conffiles debian/tmp/DEBIAN
 	install -m 755 atmel_fwl.pl debian/tmp/usr/sbin/atmel_fwl
 	install -m 644 atmel.conf debian/tmp/etc/pcmcia
 	install -m 644 images/* debian/tmp/lib/firmware
diff -u atmel-firmware-1.3/debian/changelog atmel-firmware-1.3/debian/changelog
--- atmel-firmware-1.3/debian/changelog
+++ atmel-firmware-1.3/debian/changelog
@@ -1,3 +1,10 @@
+atmel-firmware (1.3-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Restore /etc/pcmcia/atmel.conf being a conffile. (Closes: #988715)
+
+ -- Adrian Bunk   Wed, 16 Jun 2021 15:17:00 +0300
+
 atmel-firmware (1.3-4) unstable; urgency=low
 
* remove problematic dependencies. (closes: #492271)

Bug#989945: libbackuppc-xs-perl FTCBFS: missing dependency on perl-xs-dev

[Axel Beckert]

Hi Helmut,

thanks for the bug report.

Helmut Grohne wrote:
> Source: libbackuppc-xs-perl
> Version: 0.62-1
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> libbackuppc-xs-perl fails to cross build from source, because it builds
> a perl extension without depending on perl-xs-dev. During native builds,
> the relevant pieces are implicitly avilable due to the dependencies
> induced by debhelper. For performing cross builds however, all perl
> extensions must add perl-xs-dev to Build-Depends. Please consider
> applying the attached patch.

Will do.

I noticed that you didn't specify a severity — which implies just a
"normal" severity. So I assume this is nothing which needs to go in
for bullseye, right?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#907576: . dream -- A Software Digital Radio Mondiale Receiver

[Brian Thompson]

Garie,

TL;DR Use an IDE or text editor on your machine.

Local IDEs/text editors are used to develop the vast, vast majority of
software.  Most developers develop on their own machines instead of in
the browser.  It doesn't make sense to develop in a browser-based IDE
(at least not yet) since they are missing vital functionality.  Whole
OSes can't be replicated in the browser, whereby the browser greatly
limits access to common development tools.

Best regards,

Brian

On June 15, 2021, GMiller  wrote:
> Hello Christoph
> >Re: GMiller > For  the subject project, I have encountered a
> roadblock while attempting to use the 'Salsa Web Terminal'. I filed
> Gitlab Issue 233 (see attachments) seeking information to prepare a
> 'gitlab-webide.yml' file (I searched but could find no documentation
> on it). The response to 233 >says "To upload designs, you'll need to
> enable LFS and have an admin enable hashed storage". 
>  >>Sorry, I can help you with packaging hamradio software, but please
> use a normal editor like everyone else. There is no need to bother
> with funky web stuff, especially if it doesn't work out of the box.
> Christoph
>
> I am not sure I understand your comment. Are you saying in effect,
> don't use a Salsa IDE to build/test the project? Instead use an IDE on
> my local machine to build/test and develop any code changes? Is that
> how most Salsa projects are doing it?
> Thanks for your patience
> Garie Miller wb9awa
> Sent with ProtonMail  Secure Email.

Bug#989948: unblock: polari/3.38.0-2

[Laurent Bigonville]

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

Hello,

Please unblock package polari

With everything happening in the IRC world ATM, I think it's important
that libera.chat is being added to the default list of IRC network.

The favorite flag is only used for the initial setup dialog that is
being displayed on the first run for polari.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing


unblock polari/3.38.0-2
diff -Nru polari-3.38.0/debian/changelog polari-3.38.0/debian/changelog
--- polari-3.38.0/debian/changelog  2020-10-01 00:52:45.0 +0200
+++ polari-3.38.0/debian/changelog  2021-06-16 12:46:04.0 +0200
@@ -1,3 +1,11 @@
+polari (3.38.0-2) unstable; urgency=medium
+
+  * d/p/networks-Add-Libera-Chat.patch: Add Libera.chat network
+  * d/p/favorite-liberachat.patch: Mark Libera Chat as favorite instead of
+Freenode
+
+ -- Laurent Bigonville   Wed, 16 Jun 2021 12:46:04 +0200
+
 polari (3.38.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru polari-3.38.0/debian/patches/favorite-liberachat.patch 
polari-3.38.0/debian/patches/favorite-liberachat.patch
--- polari-3.38.0/debian/patches/favorite-liberachat.patch  1970-01-01 
01:00:00.0 +0100
+++ polari-3.38.0/debian/patches/favorite-liberachat.patch  2021-06-16 
12:46:04.0 +0200
@@ -0,0 +1,22 @@
+Description: Mark Libera Chat as favorite instead of Freenode
+Forwarded: no
+Bug: https://gitlab.gnome.org/GNOME/polari/-/issues/169
+
+--- a/data/resources/networks.json
 b/data/resources/networks.json
+@@ -269,7 +269,6 @@
+   {
+ "name": "Freenode",
+ "id": "freenode",
+-"favorite": true,
+ "servers": [
+   { "ssl": true, "port": 6697, "address": "chat.freenode.net" },
+   { "ssl": true, "port": 7000, "address": "chat.freenode.net" },
+@@ -391,6 +390,7 @@
+   {
+ "name": "Libera Chat",
+ "id": "liberachat",
++"favorite": true,
+ "servers": [
+   { "ssl": true, "port": 6697, "address": "irc.libera.chat" },
+   { "ssl": false, "port": 6667, "address": "irc.libera.chat" }
diff -Nru polari-3.38.0/debian/patches/networks-Add-Libera-Chat.patch 
polari-3.38.0/debian/patches/networks-Add-Libera-Chat.patch
--- polari-3.38.0/debian/patches/networks-Add-Libera-Chat.patch 1970-01-01 
01:00:00.0 +0100
+++ polari-3.38.0/debian/patches/networks-Add-Libera-Chat.patch 2021-06-16 
12:46:04.0 +0200
@@ -0,0 +1,28 @@
+From: =?utf-8?q?Florian_M=C3=BCllner?= 
+Date: Thu, 20 May 2021 21:41:35 +0200
+Subject: networks: Add Libera Chat
+
+https://gitlab.gnome.org/GNOME/polari/-/merge_requests/187
+---
+ data/resources/networks.json | 8 
+ 1 file changed, 8 insertions(+)
+
+diff --git a/data/resources/networks.json b/data/resources/networks.json
+index f509c87..bf85295 100644
+--- a/data/resources/networks.json
 b/data/resources/networks.json
+@@ -388,6 +388,14 @@
+   { "ssl": false, "port": 6667, "address": "irc.krstarica.com" }
+ ]
+   },
++  {
++"name": "Libera Chat",
++"id": "liberachat",
++"servers": [
++  { "ssl": true, "port": 6697, "address": "irc.libera.chat" },
++  { "ssl": false, "port": 6667, "address": "irc.libera.chat" }
++]
++  },
+   {
+ "name": "Librenet",
+ "id": "librenet",
diff -Nru polari-3.38.0/debian/patches/series 
polari-3.38.0/debian/patches/series
--- polari-3.38.0/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ polari-3.38.0/debian/patches/series 2021-06-16 12:46:04.0 +0200
@@ -0,0 +1,2 @@
+networks-Add-Libera-Chat.patch
+favorite-liberachat.patch

Bug#989922: thunderbird: testing: NS_ERROR_NET_INADEQUATE_SECURITY?

[Henry Schwanbeck]

Package: thunderbird
Version: 1:78.11.0-1
Followup-For: Bug #989922

Hello,

same issue here, I use a plugin to get my mails from MS Exchange OWA, but
totally impossible at the moment due to NS_ERROR_NET_INADEQUATE_SECURITY.
I now updated to version 89 from experimental but that one has the same
problem.


Best regards,

Henry

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

Kernel: Linux 5.10.0-7-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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages thunderbird depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libbotan-2-172.17.3+dfsg-2
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-12
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libicu67 67.1-6
ii  libjson-c5   0.15-2
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.1-1
ii  libx11-xcb1  2:1.7.1-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxext6 2:1.3.3-1.1
ii  libxrender1  1:0.9.10-1
ii  psmisc   23.4-2
ii  x11-utils7.7+5
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages thunderbird recommends:
ii  hunspell-de-at [hunspell-dictionary]  20161207-9
ii  hunspell-de-ch [hunspell-dictionary]  20161207-9
ii  hunspell-de-de [hunspell-dictionary]  20161207-9
ii  hunspell-en-us [hunspell-dictionary]  1:2019.10.06-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.6-10
ii  fonts-lyx 2.3.6-1
ii  libgssapi-krb5-2  1.18.3-5
ii  libgtk2.0-0   2.24.33-2

Bug#988213: debian: iotjs: CVE-2020-24344

[Philippe Coval]

‌Hi,
Is this issue blocking debian release ? Apparently not (it's not RC)

Anyway I plan to fix this upstream's side, please review:

http://github.com/jerryscript-project/iotjs/pull/1973‌

http://github.com/jerryscript-project/iotjs/pull/1923‌

Then I'll update the snapshot package and rebase packaging on it.

Regards

--
https://purl.org/rzr/




 

Bug#989912: libregexp-pattern-license-perl: No deterministic results are provided

[Walter Lozano]

Hi Jonas,

On 6/16/21 2:50 AM, Jonas Smedegaard wrote:

Quoting Walter Lozano (2021-06-16 04:12:23)

On 6/15/21 9:17 PM, Jonas Smedegaard wrote:

Quoting Walter Lozano (2021-06-15 20:42:53)

As as user of licensecheck I found it does not provide
deterministic results on some circumstances. And example of this is
gnutls28/m4/ax_code_coverage.m4 which is detected as UNKNOWN or
LGPL.

After some debugging I found that the root cause could be in
libregexp-pattern-license-perl, I have proposed a fix which you
can find in

https://salsa.debian.org/perl-team/modules/packages/libregexp-pattern-license-
perl/-/merge_requests/1

I hope you can help me to clarify this issue.

Great - thanks a lot!

I suspect that this might be bug#982849.

Yes, it looks exactly the same issue I faced. I hope you can confirm
and fix it

I will certainly do that.
In relation to this, I find that the problem is more evident at least 
after these commits, which are related to versioning


 * eddc64dd1f0e6f9bd1769ef580a217aa4be762b8 (synthesize subject pattern
   name: optimize version matching)
 * cd75d77da201260bc9deef4631d5c4d3a42fa41d (add license patterns
   lgpl_2 lgpl-2_1 lgpl-3)

I hope this information is useful.

Please keep all conversation about the bug here - *not* at salsa.

Perfect, I will do that. To be honest I was not sure how to submit the
proposed fix, I also tried to submitted directly to

https://salsa.debian.org/build-common-team/regexp-pattern-license

but I was not able to see a way to send a MR.

Please advice what is the best way to contribute.

Sorry, I am aware that reporting issues can be confusing, and am happy
that you figured out _some_ way to get your findings across.

I use salsa.debian.org as a place to publicly store the git repo but
*not* to track issues or negotiate change proposals or run continuous
integration tests or any other of the many things that Gitlab can do.

I use bugs.debian.org to track issues.

Best way to report and discuss issues is to use bugs.debian.org, and
best way to propose a change is to attach a patch to an email sent to an
issue tracked in bugs.debian.org.

As you are already aware, some parts of Licensecheck is maintained in
other libraries.  Git repos exist separately for Debian packaging and
upstream development of these libraries, but that should not matter for
issue tracking.

E.g. https://metacpan.org/dist/App-Licensecheck/view/bin/licensecheck
and https://metacpan.org/dist/App-Licensecheck links to
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=licensecheck for issue
reporting, and https://www.debian.org/Bugs/Reporting covers issue
reporting in Debian.

I find it unhelpful that salsa.debian.org by default enables duplicate
issue tracking services, and I disable those to limit the risk of
confusion - but sometimes I forget that, and also sometimes others that
I collaborate with may disagree and (re)enable them.

If you have suggestions for ways I could maybe improve communicating how
to best report issues, then please do share.

Thanks for clarifying, and for taking the time to investigate the issue. 
Next time I will send you a patch  as an attachment.


Regards,

Walter

Bug#989946: [pre-approval] unblock: opencv/4.5.1+dfsg-5

[Jochen Sprickerhof]

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

Please unblock package opencv

[ Reason ]
OpenCV specified dependencies between its library packages manually in
addition to ${shlibs:Depends}. According to the git history was
introduced ~10 years ago (no explanation in the commit) and was not
really kept up to date over the years. This resulted in circular
dependencies between the packages as reported in #979809.

[ Impact ]
Quoting from the bug:

| Circular dependencies involving shared libraries are known to cause problems
| during upgrade between stable releases, so we should try to avoid them.

Though I have not seen related problems on real systems.

[ Tests ]
I have compared the package dependencies before and after the patch. For
packages where the manually specified library match, ${shlibs:Depends}
defines them as (>= 4.5.1+dfsg), instead of the manually specified (=
4.5.1+dfsg-4), which I think is more correct.
For packages where additional library dependencies where specified, I
used readelf -d to make sure that those are actually not needed.

[ Risks ]
I think the risk is pretty low, ${shlibs:Depends} works well to the best
of my knowledge. On the other hand I can see that the consequences may
not be completely obvious. Given that the bugs are not release critical,
I'm fine with postponing this to bookworm as well. This is why I ask for
a pre-approval first. I could also upload to experimental and provide
some script to compare the packages if that helps.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock opencv/4.5.1+dfsg-5
diff --git a/debian/changelog b/debian/changelog
index a680a4890..645901c47 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+opencv (4.5.1+dfsg-5) unstable; urgency=medium
+
+  * Team upload.
+  * Drop depends between library packages (Closes: #979809)
+  * Drop ${java:Depends}/${java:Recommends} (undefined)
+  * Update libgdcm-dev arch list (Closes: #987621)
+
+ -- Jochen Sprickerhof   Wed, 16 Jun 2021 14:09:47 +0200
+
 opencv (4.5.1+dfsg-4) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/control b/debian/control
index bc9ffbedf..7dbe1c235 100644
--- a/debian/control
+++ b/debian/control
@@ -213,8 +213,7 @@ Package: libopencv-ml4.5
 Architecture: any
 Multi-Arch: same
 Section: libs
-Depends: libopencv-core4.5 (= ${binary:Version}),
- ${misc:Depends},
+Depends: ${misc:Depends},
  ${shlibs:Depends}
 Pre-Depends: ${misc:Pre-Depends}
 Description: computer vision Machine Learning library
@@ -256,8 +255,7 @@ Package: libopencv-imgproc4.5
 Architecture: any
 Multi-Arch: same
 Section: libs
-Depends: libopencv-core4.5 (= ${binary:Version}),
- ${misc:Depends},
+Depends: ${misc:Depends},
  ${shlibs:Depends}
 Pre-Depends: ${misc:Pre-Depends}
 Description: computer vision Image Processing library
@@ -278,7 +276,7 @@ Package: libopencv-imgcodecs-dev
 Architecture: any
 Multi-Arch: same
 Section: libdevel
-Depends: libgdcm-dev [!hppa !m68k !powerpcspe !riscv64 !sh4],
+Depends: libgdcm-dev [!alpha !hppa !ia64 !kfreebsd-amd64 !kfreebsd-i386 !m68k 
!powerpcspe !sh4 !x32],
  libopencv-imgcodecs4.5 (= ${binary:Version}),
  libopencv-imgproc-dev (= ${binary:Version}),
  ${misc:Depends}
@@ -300,8 +298,7 @@ Package: libopencv-imgcodecs4.5
 Architecture: any
 Multi-Arch: same
 Section: libs
-Depends: libopencv-imgproc4.5 (= ${binary:Version}),
- ${misc:Depends},
+Depends: ${misc:Depends},
  ${shlibs:Depends}
 Pre-Depends: ${misc:Pre-Depends}
 Description: computer vision Image Codecs library
@@ -343,8 +340,7 @@ Package: libopencv-video4.5
 Architecture: any
 Multi-Arch: same
 Section: libs
-Depends: libopencv-imgproc4.5 (= ${binary:Version}),
- ${misc:Depends},
+Depends: ${misc:Depends},
  ${shlibs:Depends}
 Pre-Depends: ${misc:Pre-Depends}
 Description: computer vision Video analysis library
@@ -388,8 +384,7 @@ Package: libopencv-videoio4.5
 Architecture: any
 Multi-Arch: same
 Section: libs
-Depends: libopencv-imgcodecs4.5 (= ${binary:Version}),
- ${misc:Depends},
+Depends: ${misc:Depends},
  ${shlibs:Depends}
 Pre-Depends: ${misc:Pre-Depends}
 Description: computer vision Video I/O library
@@ -432,9 +427,7 @@ Package: libopencv-objdetect4.5
 Architecture: any
 Multi-Arch: same
 Section: libs
-Depends: libopencv-highgui4.5 (= ${binary:Version}),
- libopencv-ml4.5 (= ${binary:Version}),
- ${misc:Depends},
+Depends: ${misc:Depends},
  ${shlibs:Depends}
 Pre-Depends: ${misc:Pre-Depends}
 Description: computer vision Object Detection library
@@ -488,8 +481,7 @@ Package: libopencv-highgui4.5
 Architecture: any
 Multi-Arch: same
 Section: libs
-Depends: libopencv-videoio4.5 (= ${binary:Version}),
- ${misc:Depends},
+Depends: ${misc:Depends},
   

Bug#989141: Some news ?

[Benjamin Renard]

Hello,

Do you have some news about this bug ? The proposed patch can be applied 
or it's not safe ?



Regards,

--
Benjamin Renard

Bug#989945: libbackuppc-xs-perl FTCBFS: missing dependency on perl-xs-dev

[Helmut Grohne]

Source: libbackuppc-xs-perl
Version: 0.62-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libbackuppc-xs-perl fails to cross build from source, because it builds
a perl extension without depending on perl-xs-dev. During native builds,
the relevant pieces are implicitly avilable due to the dependencies
induced by debhelper. For performing cross builds however, all perl
extensions must add perl-xs-dev to Build-Depends. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru libbackuppc-xs-perl-0.62/debian/changelog 
libbackuppc-xs-perl-0.62/debian/changelog
--- libbackuppc-xs-perl-0.62/debian/changelog   2020-07-04 19:23:24.0 
+0200
+++ libbackuppc-xs-perl-0.62/debian/changelog   2021-06-16 14:10:44.0 
+0200
@@ -1,3 +1,10 @@
+libbackuppc-xs-perl (0.62-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Missing build dependency on perl-xs-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 16 Jun 2021 14:10:44 +0200
+
 libbackuppc-xs-perl (0.62-1) unstable; urgency=medium
 
   * Import new upstream release 0.62.
diff --minimal -Nru libbackuppc-xs-perl-0.62/debian/control 
libbackuppc-xs-perl-0.62/debian/control
--- libbackuppc-xs-perl-0.62/debian/control 2020-07-04 19:03:57.0 
+0200
+++ libbackuppc-xs-perl-0.62/debian/control 2021-06-16 14:10:44.0 
+0200
@@ -6,6 +6,7 @@
 Priority: optional
 Standards-Version: 4.5.0
 Build-Depends: debhelper-compat (= 13),
+   perl-xs-dev,
zlib1g-dev
 Homepage: https://github.com/backuppc/backuppc-xs
 Vcs-Git: https://salsa.debian.org/debian/libbackuppc-xs-perl.git

Bug#986709: Bad idea

[Fabio Muzzi]

Removing an useful and stable software such as rsnapshot is not a good idea, 
IMHO.



--
Fabio "Kurgan" Muzzi

- IZ4UFQ -

"Il massimo danno con il minimo sforzo"

Bug#988713: pipemeter: diff for NMU version 1.1.5-1.1

[Adrian Bunk]

Control: tags 988713 + pending

Dear maintainer,

I've prepared an NMU for pipemeter (versioned as 1.1.5-1.1) and uploaded 
it to DELAYED/2. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru pipemeter-1.1.5/debian/changelog pipemeter-1.1.5/debian/changelog
--- pipemeter-1.1.5/debian/changelog	2021-01-09 21:51:04.0 +0200
+++ pipemeter-1.1.5/debian/changelog	2021-06-16 15:05:01.0 +0300
@@ -1,3 +1,11 @@
+pipemeter (1.1.5-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply patch from Dennis Filder moving the man page to the
+correct location. (Closes: #988713)
+
+ -- Adrian Bunk   Wed, 16 Jun 2021 15:05:01 +0300
+
 pipemeter (1.1.5-1) unstable; urgency=medium
 
   * New upstream release (Closes: #972958)
diff -Nru pipemeter-1.1.5/debian/rules pipemeter-1.1.5/debian/rules
--- pipemeter-1.1.5/debian/rules	2010-09-29 13:19:45.0 +0300
+++ pipemeter-1.1.5/debian/rules	2021-06-16 15:04:54.0 +0300
@@ -6,3 +6,8 @@
 
 %:
 	dh $@ 
+
+override_dh_auto_configure:
+	sed -i '/[)][/]man[/]man1/s@/man/man1@/share/man/man1@' Makefile.in
+	dh_auto_configure
+	sed -i '/[)][/]share[/]man[/]man1/s@/share/man/man1@/man/man1@' Makefile.in

Bug#989944: /usr/share/misc/config.sub: add support for csky

[Helmut Grohne]

Package: autotools-dev
Version: 20180224.1+nmu1
File: /usr/share/misc/config.sub
Tags: upstream fixed-upstream
User: helm...@debian.org
Usertags: rebootstrap

Please add support for the csky processor architecture to
/usr/share/misc/config.sub. This has already happend upstream. Updating
to 2019-01-01 definitely is sufficient.

Helmut

Bug#989943: unattended-upgrades blocking other cron.daily scripts or "'invoke-rc.d rsyslog rotate' called during shutdown sequence."

[Tomas Pospisek]

Package: unattended-upgrades
Version: 1.11.2
Severity: normal

Hi!

There are several systems where I get

Date: Tue, 15 Jun 2021 06:00:17 +0200
From: Cron Daemon
Subject: Cron  test -x /usr/sbin/anacron || ( cd / && run-parts 
--report /etc/cron.daily )

/etc/cron.daily/logrotate:
invoke-rc.d: -
invoke-rc.d: WARNING: 'invoke-rc.d rsyslog rotate' called
invoke-rc.d: during shutdown sequence.
invoke-rc.d: enabling safe mode: initscript policy layer disabled
invoke-rc.d: -

whenever unattended-upgrades needs to reboot. *Before* the
reboot the system looks like this:

root   835  0.0  0.0   8504  2336 ?Ss   Jun15   0:00 
/usr/sbin/cron
root 12595  0.0  0.0   9120  2316 ?S06:25   0:00  \_ 
/usr/sbin/CRON
root 12596  0.0  0.0   2388   700 ?Ss   06:25   0:00  \_ 
/bin/sh -c test -x /usr/sbin/anacron || ( cd / && run-parts --report 
/etc/cron.daily )
root 12597  0.0  0.0   2284   688 ?S06:25   0:00  
\_ run-parts --report /etc/cron.daily
root 12598  0.0  0.0   2388   764 ?S06:25   0:00
  \_ /bin/sh /usr/lib/apt/apt.systemd.daily
root 12733  0.0  0.0   2388  1488 ?S06:41   0:00
  \_ /bin/sh /usr/lib/apt/apt.systemd.daily lock_is_held
root 13047  0.0  0.2 123308 34548 ?Sl   06:41   0:00
  \_ /usr/bin/python3 /usr/bin/unattended-upgrade
root 13057  0.0  0.0   2372  1752 ?S06:41   0:00
  \_ /sbin/shutdown -r 06:00

In human language: this morning at 06:25 cron.daily ran,
which triggered unattended-upgrades, which triggered
`/sbin/shutdown -r 06:00`.

Now one problem here is that `/sbin/shutdown -r 06:00` is
actually blocking. It will *not* exit, but instead will
count waiting time to zero and reboot after.

We are on a system with `sysv-rc` and not `systemd`. I have
*not* verified whether `shutdown -r $TIME` behavior is
identical on a `systemd` system.

The system apparently shut down at:

# cat /var/log/messages
Jun 15 06:00:14 dom shutdown[13634]: shutting down for system reboot

also

# cat /var/log/daemon.log
Jun 15 06:00:15 dom init: Switching to runlevel: 6

also

# last -F
reboot   system boot  4.19.0-16-amd64  Tue Jun 15 06:00:28 2021 - Wed Jun 
16 10:34:57 2021 (1+04:34)

So my interpretation is this:

1. cron.daily runs
2. it executes unattended-upgrade
3. unattended-upgrade blocks when it calls shutdown -r 06:00
4. in our case that stops the other cron.daily tasks that are
   sorted after /etc/cron.daily/apt-compat (that is pretty
   much all others since apt-compat is first in the alphabet)
   from running
5. the clock hits 06:00:00 and shutdown exits (this is my
   guess - I think it's the same behavior as with
   `shutdown -r now` which also exits and so you sometimes
   see/get back to the prompt before the sytstem *actually*
   warm reboots)
6. after `shutdown -r 06:00` exits unattended-upgrade
   finishes whatever it was doing, exits and cron.daily continues
   with the execution with the other scripts in /etc/cron.daily/
   that alphabetically follow apt-compat, which makes a
   mess, because we're actually in runlevel 6/shutdown
   now. which triggers the warning we saw above from
   logrotate/cron.

Now what would a "correct" or "better" behavior be?

I suggest to trigger an asynchronous shutdown, that is *not*
to wait for `shutdown -r $TIME` to come back so that whatever
daily menial taks are scheduled via /etc/cron.daily are able
to be executed.

In other words: fork & exec shutdown...

?

Thanks a lot for maintaining unattended-upgrades Greetings,
*t


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

Kernel: Linux 4.19.0-16-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  lsb-base   10.2019051400
ii  lsb-release10.2019051400
ii  python33.7.3-1
ii  python3-apt1.8.4.3
ii  python3-dbus   1.2.8-3
ii  python3-distro-info0.21
ii  ucf3.0038+nmu1
ii  xz-utils   5.2.4-1

Versions of packages unattended-upgrades recommends:
ii  cron [cron-daemon]  3.0pl1-134+deb10u1

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20180807cvs-1
pn  needrestart
ii  nullmailer [mail-transport-agent]  1:2.2-3
pn  powermgmt-base 
ii  python3-gi 3.30.4-1

-- debconf information:
* 

Bug#971897: gpiozero: diff for NMU version 1.4.1-1.3

[Adrian Bunk]

Control: tags 971897 + patch
Control: tags 971897 + pending

Dear maintainer,

I've prepared an NMU for gpiozero (versioned as 1.4.1-1.3) and uploaded 
it to DELAYED/2. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -Nru gpiozero-1.4.1/debian/changelog gpiozero-1.4.1/debian/changelog
--- gpiozero-1.4.1/debian/changelog	2019-08-30 22:40:05.0 +0300
+++ gpiozero-1.4.1/debian/changelog	2021-06-16 14:50:22.0 +0300
@@ -1,3 +1,11 @@
+gpiozero (1.4.1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add the missing dependency on python3-pkg-resources.
+(Closes: #971897)
+
+ -- Adrian Bunk   Wed, 16 Jun 2021 14:50:22 +0300
+
 gpiozero (1.4.1-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gpiozero-1.4.1/debian/control gpiozero-1.4.1/debian/control
--- gpiozero-1.4.1/debian/control	2019-08-30 22:40:05.0 +0300
+++ gpiozero-1.4.1/debian/control	2021-06-16 14:50:22.0 +0300
@@ -22,6 +22,7 @@
  python3-rpi.gpio [armel armhf arm64],
  ${misc:Depends},
  ${python3:Depends},
+ python3-pkg-resources
 Recommends:
  python3-pigpio [!armel !armhf !arm64]
 Suggests:

Bug#980047: libpam-chroot: diff for NMU version 0.9-4.4

[Adrian Bunk]

Control: tags 980047 + patch
Control: tags 980047 + pending

Dear maintainer,

I've prepared an NMU for libpam-chroot (versioned as 0.9-4.4) and 
uploaded it to DELAYED/2. Please feel free to tell me if I should cancel it.

cu
Adrian
diff -u libpam-chroot-0.9/debian/changelog libpam-chroot-0.9/debian/changelog
--- libpam-chroot-0.9/debian/changelog
+++ libpam-chroot-0.9/debian/changelog
@@ -1,3 +1,10 @@
+libpam-chroot (0.9-4.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Move pam_chroot.so to multiarch location. (Closes: #980047)
+
+ -- Adrian Bunk   Wed, 16 Jun 2021 14:41:17 +0300
+
 libpam-chroot (0.9-4.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u libpam-chroot-0.9/debian/rules libpam-chroot-0.9/debian/rules
--- libpam-chroot-0.9/debian/rules
+++ libpam-chroot-0.9/debian/rules
@@ -31,6 +31,8 @@
 
 	# Add here commands to install the package into debian/libpam-chroot
 	$(MAKE) install DESTDIR=$(CURDIR)/debian/libpam-chroot
+	mkdir -p $(CURDIR)/debian/libpam-chroot/lib/$(DEB_HOST_MULTIARCH)
+	mv $(CURDIR)/debian/libpam-chroot/lib/security $(CURDIR)/debian/libpam-chroot/lib/$(DEB_HOST_MULTIARCH)/security
 
 
 # Build architecture-independent files here.

Bug#506033: libscotchmetis-dev: Please add METIS_PartMesh* functions

[Drew Parsons]

Package: libscotchmetis-dev
Followup-For: Bug #506033
X-Debbugs-Cc: Anton Gladky 

Hi Anton, chasing up Scotch Metis compatibility, do you see any more
use at this point in time for METIS_mCPartGraphKway and
METIS_mCPartGraphRecursive ?

If I read the Metis history correctly, these functions appeared in
Metis v4 but were not in Metis v3, and have been removed again in
Metis v5.

Metis v5 seems to have simplified the API, there's only
METIS_PartGraphKway and METIS_PartGraphRecursive.

I imagine it's simpler for Scotch if they only need to provide
Metis v5 compatibility.

Bug#989942: libdeflate FTCBFS: multiple reasons

[Helmut Grohne]

Source: libdeflate
Version: 1.7-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libdeflate fails to cross build from source for two reasons. First of
all, it does not pass any cross tools to make and thus builds for the
build architecture failing to find -lz, which is only installed for the
host architecture. The easiest way to fix this is using dh_auto_build.

A bigger issue is the use of profile guided optimization. This really is
unsupportable in cross builds as the premise is that we cannot run the
code. I propose automatically disabling pgo when performing a cross
build. The results will not be the same as native builds, but at least,
you get a working package.

Please consider applying the attached patch.

Helmut
diff --minimal -Nru libdeflate-1.7/debian/changelog 
libdeflate-1.7/debian/changelog
--- libdeflate-1.7/debian/changelog 2021-01-03 14:36:39.0 +0100
+++ libdeflate-1.7/debian/changelog 2021-06-16 12:51:19.0 +0200
@@ -1,3 +1,12 @@
+libdeflate (1.7-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Automatically skip pgo when DEB_BUILD_PROFILES contains cross.
+
+ -- Helmut Grohne   Wed, 16 Jun 2021 12:51:19 +0200
+
 libdeflate (1.7-1) unstable; urgency=medium
 
   * New upstream version
diff --minimal -Nru libdeflate-1.7/debian/rules libdeflate-1.7/debian/rules
--- libdeflate-1.7/debian/rules 2021-01-03 14:32:37.0 +0100
+++ libdeflate-1.7/debian/rules 2021-06-16 12:51:19.0 +0200
@@ -7,30 +7,34 @@
 %:
dh $@
 
+ifeq (,$(filter cross,$(DEB_BUILD_PROFILES)))
+PROFILING_FLAG = -fprofile-use
+else
+PROFILING_FLAG =
+endif
 
 override_dh_auto_build:
-   make CFLAGS="$(shell dpkg-buildflags --get CFLAGS) -fprofile-generate" \
+ifeq (,$(filter cross,$(DEB_BUILD_PROFILES)))
+   dh_auto_build -- CFLAGS="$(shell dpkg-buildflags --get CFLAGS) 
-fprofile-generate" \
LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS) 
-fprofile-generate"\
CPPFLAGS="$(shell dpkg-buildflags --get CPPFLAGS)"\
-   V=1 PREFIX=/usr DESTDIR=$(CURDIR)/debian/tmp -j$(shell nproc)\
-   "INSTALL=install --strip-program=true"\
+   V=1 PREFIX=/usr DESTDIR=$(CURDIR)/debian/tmp \
all test_programs
for level in $(shell seq 1 12); do \
./benchmark -$${level} ./lib/deflate_compress.c > /dev/null; \
done
-   make CFLAGS="$(shell dpkg-buildflags --get CFLAGS) -fprofile-use" \
-   LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS) -fprofile-use"\
+endif
+   dh_auto_build -- CFLAGS="$(shell dpkg-buildflags --get CFLAGS) 
$(PROFILING_FLAG)" \
+   LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS) 
$(PROFILING_FLAG)"\
CPPFLAGS="$(shell dpkg-buildflags --get CPPFLAGS)"\
-   V=1 PREFIX=/usr DESTDIR=$(CURDIR)/debian/tmp -j$(shell nproc)\
-   "INSTALL=install --strip-program=true"\
+   V=1 PREFIX=/usr DESTDIR=$(CURDIR)/debian/tmp \
all test_programs
 
 override_dh_auto_install:
-   make CFLAGS="$(shell dpkg-buildflags --get CFLAGS) -fprofile-use" \
-   LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS) -fprofile-use"\
+   dh_auto_build -- CFLAGS="$(shell dpkg-buildflags --get CFLAGS) 
$(PROFILING_FLAG)" \
+   LDFLAGS="$(shell dpkg-buildflags --get LDFLAGS) 
$(PROFILING_FLAG)"\
CPPFLAGS="$(shell dpkg-buildflags --get CPPFLAGS)"\
-   V=1 PREFIX=/usr DESTDIR=$(CURDIR)/debian/tmp -j$(shell nproc)\
-   "INSTALL=install --strip-program=true"\
+   V=1 PREFIX=/usr DESTDIR=$(CURDIR)/debian/tmp \
install
 
 override_dh_auto_test:

Bug#989941: libapache2-mod-ldap-userdir FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: libapache2-mod-ldap-userdir
Version: 1.1.19-2.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libapache2-mod-ldap-userdir fails to cross build from source, because it
configures for the build architecture. The easiest way of passing the
relevant --host flag - using dh_auto_configure - makes
libapache2-mod-ldap-userdir cross buildable. Please consider applying
the attached patch.

Helmut
diff --minimal -Nru libapache2-mod-ldap-userdir-1.1.19/debian/changelog 
libapache2-mod-ldap-userdir-1.1.19/debian/changelog
--- libapache2-mod-ldap-userdir-1.1.19/debian/changelog 2013-07-10 
22:37:13.0 +0200
+++ libapache2-mod-ldap-userdir-1.1.19/debian/changelog 2021-06-16 
12:36:51.0 +0200
@@ -1,3 +1,10 @@
+libapache2-mod-ldap-userdir (1.1.19-2.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to configure. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 16 Jun 2021 12:36:51 +0200
+
 libapache2-mod-ldap-userdir (1.1.19-2.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff --minimal -Nru libapache2-mod-ldap-userdir-1.1.19/debian/rules 
libapache2-mod-ldap-userdir-1.1.19/debian/rules
--- libapache2-mod-ldap-userdir-1.1.19/debian/rules 2012-06-25 
01:05:35.0 +0200
+++ libapache2-mod-ldap-userdir-1.1.19/debian/rules 2021-06-16 
12:36:49.0 +0200
@@ -9,8 +9,7 @@
 build: build-stamp
 build-stamp:
dh_testdir
-
-   ./configure
+   dh_auto_configure
$(MAKE)
chrpath -d .libs/mod_ldap_userdir.so
 

Bug#989940: sbrsh FTCBFS: successfully cross builds a broken package

[Helmut Grohne]

Source: sbrsh
Version: 7.6.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

sbrsh successfully performs a cross build, but the resulting package
contains binaries for the build architecture. The easiest way of fixing
that is using dh_auto_build. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru sbrsh-7.6.1/debian/changelog 
sbrsh-7.6.1+nmu1/debian/changelog
--- sbrsh-7.6.1/debian/changelog2009-03-09 09:38:54.0 +0100
+++ sbrsh-7.6.1+nmu1/debian/changelog   2021-06-16 13:24:00.0 +0200
@@ -1,3 +1,10 @@
+sbrsh (7.6.1+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 16 Jun 2021 13:24:00 +0200
+
 sbrsh (7.6.1) unstable; urgency=low
 
   * Add limits.h include, closes: #518849
diff --minimal -Nru sbrsh-7.6.1/debian/control sbrsh-7.6.1+nmu1/debian/control
--- sbrsh-7.6.1/debian/control  2009-03-09 09:39:32.0 +0100
+++ sbrsh-7.6.1+nmu1/debian/control 2021-06-16 13:23:39.0 +0200
@@ -2,7 +2,7 @@
 Section: net
 Priority: extra
 Maintainer: Riku Voipio 
-Build-Depends: debhelper (>= 5)
+Build-Depends: debhelper (>= 7)
 Standards-Version: 3.8.0
 
 Package: sbrshd
diff --minimal -Nru sbrsh-7.6.1/debian/rules sbrsh-7.6.1+nmu1/debian/rules
--- sbrsh-7.6.1/debian/rules2009-03-09 09:39:56.0 +0100
+++ sbrsh-7.6.1+nmu1/debian/rules   2021-06-16 13:23:59.0 +0200
@@ -6,10 +6,10 @@
 build: sbrshd sbrsh
 
 sbrshd:
-   $(MAKE) sbrshd
+   dh_auto_build -- sbrshd
 
 sbrsh:
-   $(MAKE) sbrsh
+   dh_auto_build -- sbrsh
 
 binary: binary-arch
 

Bug#989939: unblock: vala/0.48.18-1

[Rico Tzschichholz]

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

Please unblock package vala

Vala 0.48.18

 * Various improvements and bug fixes:
  - codegen:
+ GArray, GByteArray and GPtrArray are reference counted
+ Replace wrongly hard coded usage of G_OBJECT_GET_CLASS
+ Mark entry point method implementation "_vala_main" as static
+ Improve check for GLib.Source derived classes
  - vala: Parameter following params-array parameter is not allowed

 * Bindings:
  - Update GLib bindings to 2.66 - Sync GLib symbol additions with 0.50.9
  - glib-2.0: Add missing has_typedef attributes on SourceFuncs delegates
  - pango: Mark language parameter of AttrIterator.get_font() as out

 * Various improvements and bug fixes:
  - codegen:
+ Apply gconstpointer to gpointer cast to GenericType only
+ Fix access to captured generics in async method of interfaces (2)
+ Use if-clause for is_in_destructor() condition to be more clear
+ Add missing "_return" label and "_inner_error*_" declaration in dtors
+ Don't use G_GNUC_INTERNAL on implicit type specific fields
  - vala:
+ length-type of arrays must not be nullable
+ Report a warning for unhandled errors in destructors
  - parser:
+ Minor semantic checks to improve error messages
+ Allow empty member-initializer and accept trailing comma
+ Include INTERR token in source_reference of parsed types

[ Reason ]
Vala 0.48.x series is a Long-Term support version and receives important bug
fixes and binding fixes.

https://gitlab.gnome.org/GNOME/vala/-/issues/537
https://gitlab.gnome.org/GNOME/vala/-/issues/1176
https://gitlab.gnome.org/GNOME/vala/-/issues/1178

[ Impact ]
Vala 0.48.x gained updated bindings for glib 2.66 which were backported from
0.50.9.
Currently vala 0.48.17-1 provides bindings for glib 2.64 only.

[ Tests ]
The vala 0.48.x series is constantly used by current package set of Debian
testing.
The upstream test suite is extended with every release.
http://ci.vala-project.org:8010/builders/vala-0.48/builds/49

[ Risks ]
Vala is a compiler and affects every reverse-dependency.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] There are no packaging changes other than the changelog itself
  [X] attach debdiff against the package in testing

[ Other info ]
https://gitlab.gnome.org/GNOME/vala/-/compare/7a59191b7fc5d4c7b77f42ab0e7806011a5c71dd...5587fe63a9489cdcb2fdd91a820c34e54ddbe3e0

unblock vala/0.48.18-1
diff --git a/codegen/valaccodebasemodule.vala b/codegen/valaccodebasemodule.vala
index 7d06fde1f..e24394863 100644
--- a/codegen/valaccodebasemodule.vala
+++ b/codegen/valaccodebasemodule.vala
@@ -1113,8 +1113,6 @@ public abstract class Vala.CCodeBaseModule : 
CodeGenerator {
 
if (f.is_private_symbol ()) {
flock.modifiers = CCodeModifiers.STATIC;
-   } else if (context.hide_internal && 
f.is_internal_symbol ()) {
-   flock.modifiers = CCodeModifiers.INTERNAL;
} else {
flock.modifiers = CCodeModifiers.EXTERN;
}
@@ -1132,8 +1130,6 @@ public abstract class Vala.CCodeBaseModule : 
CodeGenerator {
cdecl.add_declarator (new 
CCodeVariableDeclarator (get_variable_array_length_cname (f, dim)));
if (f.is_private_symbol ()) {
cdecl.modifiers = 
CCodeModifiers.STATIC;
-   } else if (context.hide_internal && 
f.is_internal_symbol ()) {
-   cdecl.modifiers = 
CCodeModifiers.INTERNAL;
} else {
cdecl.modifiers = 
CCodeModifiers.EXTERN;
}
@@ -1149,8 +1145,6 @@ public abstract class Vala.CCodeBaseModule : 
CodeGenerator {
cdecl.add_declarator (new 
CCodeVariableDeclarator (get_ccode_delegate_target_name (f)));
if (f.is_private_symbol ()) {
cdecl.modifiers = CCodeModifiers.STATIC;
-   } else if (context.hide_internal && 
f.is_internal_symbol ()) {
-   cdecl.modifiers = 
CCodeModifiers.INTERNAL;
} else {
cdecl.modifiers = CCodeModifiers.EXTERN;
}
@@ -1161,8 +1155,6 @@ public abstract class Vala.CCodeBaseModule : 
CodeGenerator {
cdecl.add_declarator (new 
CCodeVariableDeclarator (get_ccode_delegate_target_destroy_notify_name (f)));
   

Bug#989851: pre-approval unblock: uwsgi/2.0.19.1-8

[Graham Inggs]

Control: tags -1 + moreinfo

Hi Thomas

On Mon, 14 Jun 2021 at 21:12, Thomas Goirand  wrote:
>   [x] attach debdiff against the package in testing

You've attached a debdiff against uwsgi/2.0.19.1-7 in unstable, which
is currently blocked [1].
I think it will be best if 2.0.19.1-7 migrates to testing before you
go ahead and upload.

Someone needs to file an unblock request justifying the changes
between 2.0.19.1-6 and 2.0.19.1-7, hence including Jonas in this
discussion.

Regards
Graham


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

Bug#989294: unblock: insighttoolkit4/4.13.3withdata-dfsg1-4.1

[Andreas Beckmann]

Control: tag -1 - moreinfo

On 31/05/2021 13.54, Sebastian Ramacher wrote:

On 2021-05-31 13:32:33, Andreas Beckmann wrote:



Please unblock package insighttoolkit4

Let's add some Breaks for smoother upgrades from buster due to the hdf5
library renames.


Let's wait a bit before unblocking this one. We need to figure out how
to deal with #988722. If we end up doing a transition for that, this
Breaks is not necessary (and potentially harmful).


With hdf5 and gdal made co-installable, I still find incomplete upgrades 
involving libinsighttoolkit4.12. The remaining non-coinstallable library 
is libnifti2/buster from src:nifticlib (The changelog in the NMU is now 
outdated (still mentioning the hdf5 renames).)


libnifti2/buster contained
/usr/lib/libnifticdf.so.2
/usr/lib/libniftiio.so.2
/usr/lib/libznz.so.2

which have been split into separate packages in bullseye:

libnifticdf2: /usr/lib/x86_64-linux-gnu/libnifticdf.so.2
libniftiio2: /usr/lib/x86_64-linux-gnu/libniftiio.so.2
libznz3: /usr/lib/x86_64-linux-gnu/libznz.so.3 (SONAME BUMP)

Would a transitional metapackage work like for libhdf5*-103?

# apt-cache rdepends libnifti2
libnifti2
Reverse Depends:
  dicomnifti
  elastix
  fsl-5.0-core
  gifti-bin
  libgiftiio0
  libinsighttoolkit4.12
  libmdc3
  libmia-2.4-4
  libnifti-dev
  libsimpleitk1.0
  mia-tools
  minc-tools
  mitools
  nifti-bin
  odin
  python-nifti

installing all of them and thereafter checking for the users of libznz.so.2:

# dpkg -S $(grep -r libznz.so.2 /usr | awk '{print $3}') | cut -d: -f1 | 
sort -u

dicomnifti
elastix
fsl-5.0-core
gifti-bin
libgiftiio0
libmdc3
libnifti2
libsimpleitk1.0
mitools
nifti-bin
odin

reintroducing libnifti2 as a transitional package depending on 
libnifticdf2, libniftiio2 would have to add versioned Breaks against all 
users of libznz.so.2
OK. that would work for libinsighttoolkit4.12 but if any of the other 
packages is installed, co-installability is gone again.


We could also drop the Breaks: libnifti2 from libniftiio2 as there is no 
direct file conflict due to multiarchification. But then we would allow 
having two versions of libniftiio.so.2 installed, one linked against 
libznz.so.2 the other against libznz.so.3.


So I'd favor adding the Breaks against libinsighttoolkit4.12

An example package affected by this is libotb-apps, with the Breaks 
added the upgrade resolves to


-  The following packages have been kept back:
-libotb-apps
+  The following packages will be REMOVED:
+libinsighttoolkit4.12 libnifti2 libotbapplicationengine-6.6-1
+libotbcarto-6.6-1 libotbcommandline-6.6-1 libotbcommandlineparser-6.6-1
+libotbcommon-6.6-1 libotbcurladapters-6.6-1 libotbedge-6.6-1
+libotbextendedfilename-6.6-1 libotbfuzzy-6.6-1 libotbgdaladapters-6.6-1
+libotbice-6.6-1 libotbimagebase-6.6-1 libotbimageio-6.6-1
+libotbimagemanipulation-6.6-1 libotbiobsq-6.6-1 libotbiogdal-6.6-1
+libotbiokml-6.6-1 libotbiolum-6.6-1 libotbiomstar-6.6-1 
libotbioonera-6.6-1

+libotbiorad-6.6-1 libotbiotilemap-6.6-1 libotblearningbase-6.6-1
+libotbmapla-6.6-1 libotbmathparser-6.6-1 libotbmetadata-6.6-1
+libotbmonteverdi-6.6-1 libotbmonteverdicore-6.6-1 
libotbmonteverdigui-6.6-1
+libotbossimadapters-6.6-1 libotbpolarimetry-6.6-1 
libotbprojection-6.6-1

+libotbqtwidget-6.6-1 libotbrcc8-6.6-1 libotbsampling-6.6-1
+libotbstatistics-6.6-1 libotbstreaming-6.6-1 libotbsupervised-6.6-1
+libotbtestkernel-6.6-1 libotbvectordatabase-6.6-1 
libotbvectordataio-6.6-1

+libotbwavelet-6.6-1


Andreas

Bug#989938: mupdf: Wrapper script interferes with SIGHUP

[Martin Mares]

Package: mupdf
Version: 1.14.0+ds1-4+deb10u2
Severity: normal

The man page of mupdf documents that we can send SIGHUP to mupdf to make it
reload the file. However, this is broken by the wrapper script provided by 
Debian:
when the script receives a SIGHUP, it terminates instead of forwarding the 
SIGHUP
to the mupdf binary.


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

Kernel: Linux 4.19.0-16-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mupdf depends on:
ii  libc62.28-10
ii  libfreetype6 2.9.1-3+deb10u2
ii  libharfbuzz0b2.3.1-1
ii  libjbig2dec0 0.16-1
ii  libjpeg62-turbo  1:1.5.2-2+deb10u1
ii  libopenjp2-7 2.3.0-2+deb10u2
ii  libx11-6 2:1.6.7-1+deb10u2
ii  libxext6 2:1.3.3-1+b2
ii  zlib1g   1:1.2.11.dfsg-1

mupdf recommends no packages.

Versions of packages mupdf suggests:
ii  mupdf-tools  1.14.0+ds1-4+deb10u2

-- no debconf information

Bug#989937: some non CDATA commands are hard to read

[hoxp18]

Package: debian-edu-doc
Version:2.11.24
Severity: wishlist

Dear Debian Edu team,

Some commands for upgrading written in section 12 "upgrade"
are "listitem" type in po files (not "CDATA").

As a result some of crucial texts are rendered as
list items which I think it could confuse readers a bit
(by depth of list and wrap on browser).

e.g. 12.2.1. ldapvi manipulation (iPXE)

Perhaps "computeroutput" and/or "CDATA" be nice,
for both readers and translators, I think.

regards,

Bug#989936: make clean should clean images-tmp dir

[hoxp18]

Package: debian-edu-doc
Version: 2.11.24
Severity: wishlist

Dear Debian Edu team,

After making "make" error on .po task such like syntax error,
debian-edu-doc/documentation/common/Makefile.common fails at
"mkdir images-tmp". 

Since "make clean" does not purge that tmp dir,
"make" keep failing even after fixing the error on .po file.

regards,

Bug#989918: unblock: aeskeyfind/1:1.0-11

[Graham Inggs]

Control: tags -1 + moreinfo

Hi Samuel

As can be seen in aeskeyfind's excuses [1]:

not blocked: has successful autopkgtest

You'll need to file a RoM; ANAIS bug against ftp.debian.org [2]
requesting removal of aeskyfind's binaries on the architectures where
it no longer builds.
Please close this bug, or remove the moreinfo tag once the removals
have been done, if aeskeyfind still needs aging.

Regards
Graham


[1] https://qa.debian.org/excuses.php?package=aeskeyfind
[2] https://wiki.debian.org/ftpmaster_Removals

Bug#989344: ogre-1.12: diff for NMU version 1.12.10+dfsg2-1.1

[Simon McVittie]

On Wed, 16 Jun 2021 at 09:02:00 +0200, Andreas Beckmann wrote:
> On Sun, 13 Jun 2021 23:42:57 +0100 Simon McVittie  wrote:
> > I see the Ogre package overrides the package-name-doesnt-match-sonames
> > lintian tag because it is really a bundle of multiple shared libraries
> > libOgreMain.so.1.12.10, libOgreOverlay.so.1.12.10 and so on, which were
> > presumably considered to be too small to package separately.
> 
> IIRC, Lintian does not issue package-name-doesnt-match-sonames if one of the
> bundled libraries does match

In this case, that doesn't seem to apply: there is no libOgre.so.1.12.10,
the closest equivalent is libOgreMain.so.1.12.10.

> Bundling libraries with matching SOVERSION should not be a problem (as long
> as it stays in sync).

... and as long as upstream (or even the Debian maintainer!) never
removes one of the libraries without bumping the SONAME of the rest.
That situation is what prompted breaking up the Pango and gdk-pixbuf
families of libraries - in each case, upstream removed a deprecated
library in its entirety, resulting in less ABI being provided than had
previously been the case, even though each of the remaining SONAMEs had
an ABI compatible with all its previous versions.

smcv

Bug#989935: flatpak-portal --env= can interfere with --forward-fd=

[Simon McVittie]

Package: flatpak
Version: 1.8.5-1
Severity: important
Tags: upstream fixed-upstream
Forwarded: https://github.com/flatpak/flatpak/issues/4286
Control: found -1 1.2.5-0+deb10u2

In the flatpak-portal service in flatpak >= 1.8.5-1, when a Flatpak app
launches a subsandbox (a separate container for part of itself, perhaps
with more restrictions or a different runtime library stack) using
flatpak-spawn --env=... --forward-fd=... or equivalent D-Bus calls,
depending on the specific file descriptors passed to --forward-fd=...,
they might collide with the temporary fd used to transfer the environment
variables. If this happens, the subsandbox will either fail to start, or
run with unintended environment variables.

Minimal(ish) manual test: in one terminal run

/usr/libexec/flatpak-portal -vr

and in another terminal run

flatpak run --command=bash org.gnome.Weather -euxc \
'echo 15 > /tmp/15; echo 16 > /tmp/16; echo 17 > /tmp/17; while 
flatpak-spawn --env=FOO=bar --forward-fd=15 --forward-fd=16 --forward-fd=17 sh 
-euxc "$1" 15

Bug#989934: flatpak-portal fd leak when apps run flatpak-spawn --env=...

[Simon McVittie]

Package: flatpak
Version: 1.8.5-1
Severity: important
Tags: upstream fixed-upstream
Control: found -1 1.2.5-0+deb10u2

The flatpak-portal service in flatpak >= 1.8.5-1 leaks a file descriptor
every time a Flatpak app launches a subsandbox (a separate container for
part of itself, perhaps with more restrictions or a different runtime
library stack) using flatpak-spawn --env=... or equivalent D-Bus calls.

Minimal reproducer: in one terminal run

/usr/libexec/flatpak-portal -vr

and in another, run

flatpak run --command=bash org.gnome.Weather -euxc \
'while flatpak-spawn --env=FOO=bar sh -euxc "$1"; do :; done' \
sh \
'test "$FOO" = bar'

(org.gnome.Weather is just an example, it can be any app). Terminate
the flatpak run loop with Ctrl+C after a few seconds.

Ignore lines of output that say "F: ioctl(0, TIOCSCTTY, 0) failed:
Operation not permitted"; these are harmless.

Good result: in the flatpak-portal -vr output, you see the same --env-fd=
every time.

Bad result: the number after --env-fd= keeps going up.

The real-world impact is that if Flatpak apps launch enough subsandboxes,
the subsandbox interface will stop working for the rest of the login
session, causing other Flatpak apps to fail to work. Chromium is a notable
example of a Flatpak app that uses subsandboxes.

smcv

Bug#907541: [openjdk-8] Bind to a multicast address fails

[Andre Naujoks]

Am 15.06.21 um 18:39 schrieb Thorsten Glaser:

Hi Andre,


This was supposed to be fixed upstream in Java 12:
https://bugs.openjdk.java.net/browse/JDK-8210493

However it was taken back again (see last comment in that issue) and is now
supposedly fixed in java 13:
https://bugs.openjdk.java.net/browse/JDK-8215294
https://bugs.openjdk.java.net/browse/JDK-8216417


thanks for this information bundle, it helps tremendously.


As far as I am aware, it works with current Java versions in Debian (>= 13).

I am not sure if Debian actually wants to carry this for the versions <13, as
the patch somehow introduced other issues (see the upstream bug-reports).


As far as I understand, the original patch indeed introduced issues,
so it’s probably not something we want to have in 8 and 11. The fix
in 13+ is not backportable because they basically rewrote the entire
socket classes’ implementations.

I guess this won’t be fixed in 8 and, more importantly, 11 currently.


Sad but understandable. I guess this can be closed again then.

Thanks for taking a look at this, though.

Regards
  Andre



bye,
//mirabilos

Bug#989933: xfce4-sensors-plugin: One drivetemp monitored disk is always missing after reboot

[Stephan Seitz]

Package: xfce4-sensors-plugin
Version: 1.3.92-2
Severity: normal

Dear Maintainer,

my notebook has one hdd (sda) and one ssd (sdb) which I’m monitoring with 
the drivetemp module.

After reboot the sdb monitor is always missing and I have to re-add it.

Shade and sweet water!

Stephan

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

Kernel: Linux 5.12.10 (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 /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages xfce4-sensors-plugin depends on:
ii  libc62.31-12
ii  libcairo21.16.0-5
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libnotify4   0.7.9-3
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libsensors5  1:3.6.0-7
ii  libx11-6 2:1.7.1-1
ii  libxfce4panel-2.0-4  4.16.2-1
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util74.16.0-1
ii  libxnvctrl0  460.56-1

Versions of packages xfce4-sensors-plugin recommends:
ii  hddtemp 0.3-beta15-54
ii  lm-sensors  1:3.6.0-7

Versions of packages xfce4-sensors-plugin suggests:
pn  xsensors  

-- no debconf information

-- 
|If your life was a horse, you'd have to shoot it.|

Bug#989916: unblock: gcc-mingw-w64/24.2

[Graham Inggs]

Control: tags -1 + moreinfo confirmed

Hi Stephen

There's a typo in your changelog, the bug number should be #989862:

+gcc-mingw-w64 (24.2) unstable; urgency=medium
+
+  * Fix gcov handling: we need to tell GCC that we have headers, without
+telling it where, and then we need to correct its default assumption
+about where they are. Closes: #989682. LP: #1883933, #1920988.
+
+ -- Stephen Kitt   Sat, 12 Jun 2021 18:54:10 +0200

Other than that, please go ahead and upload to unstable, and remove
the moreinfo tag once it has built.

Regards
Graham

Bug#989932: makedumpfile FTCBFS from amd64 to arm64: derives architcture from uname

[Helmut Grohne]

Source: makedumpfile
Version: 1:1.6.8-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

makedumpfile fails to cross build from source when building on amd64 for
arm64, because the upstream Makefile passes the architecture to gcc via
a macro and detects it using uname. As such, the __x86_64__ macro is set
and a structure is defined twice. makedumpfile does support cross
building, but one has to explicitly define a TARGET variable to do so.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru makedumpfile-1.6.8/debian/changelog 
makedumpfile-1.6.8/debian/changelog
--- makedumpfile-1.6.8/debian/changelog 2021-04-08 00:32:38.0 +0200
+++ makedumpfile-1.6.8/debian/changelog 2021-06-16 11:33:25.0 +0200
@@ -1,3 +1,10 @@
+makedumpfile (1:1.6.8-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS for arm64: Pass a suitable TARGET= to make. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 16 Jun 2021 11:33:25 +0200
+
 makedumpfile (1:1.6.8-4) unstable; urgency=medium
 
   [ Ioanna Alifieraki ]
diff --minimal -Nru makedumpfile-1.6.8/debian/rules 
makedumpfile-1.6.8/debian/rules
--- makedumpfile-1.6.8/debian/rules 2021-04-08 00:32:38.0 +0200
+++ makedumpfile-1.6.8/debian/rules 2021-06-16 11:33:24.0 +0200
@@ -5,8 +5,13 @@
 %:
dh $@
 
+MAKE_SETTINGS = LINKTYPE=dynamic USELZO=on
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+MAKE_SETTINGS += TARGET=$(DEB_HOST_ARCH)
+endif
+
 override_dh_auto_build:
-   dh_auto_build -- LINKTYPE=dynamic USELZO=on
+   dh_auto_build -- $(MAKE_SETTINGS)
 
 override_dh_auto_install:
dh_auto_install --destdir debian/tmp

Bug#989928: mirror submission for mirrors.cloud.tencent.com

[Peter Palfrader]

On Wed, 16 Jun 2021, shaynefei wrote:

> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: mirrors.cloud.tencent.com
> Type: leaf
> Archive-architecture: amd64 arm64 armel armhf i386 mips mips64el mipsel 
> powerpc ppc64el s390x
> Archive-http: /debian/
> Maintainer: shaynefei 
> Country: CN China

Something is wrong/weird with this mirror.

The tracefile at
http://mirrors.cloud.tencent.com/debian/project/trace/mirrors.cloud.tencent.com
appears to be broken/partial.  Can you investigate?


-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#989839: Upgrading Firefox to 78.11 fixes this problem with Thunderbird

[Carsten Schoenert]

Argh,

I wasn't ready for sending ...

Am 16.06.21 um 10:22 schrieb Carsten Schoenert:

> I'm using locally FF 88.0 from experiemntal

... and the problems are the same if you use FF 78.10.0 from testing.

The underlying issues haven't been solved.

-- 
Regards
Carsten

Bug#989839: Upgrading Firefox to 78.11 fixes this problem with Thunderbird

[Carsten Schoenert]

Hello Àlex,

Am 16.06.21 um 09:42 schrieb Àlex:
...
> To fix-it, package maintainers have to upgrade Firefox from 78.10 to 
> 78.11 , and then Thunderbird will start working fine again. Or downgrade 
> Thunderbird again to 78.10, the same version that Firefox.
> 
> It would be nice if in the future Firefox packages upgrade the same day 
> or days before than Thunderbird, so Thunderbird doesn't stop working.

having such an requirement would be a issue as both packages are
independent from each other.
Thunderbird uses nothing from the Firefox package. So updating Firefox
would be nothing more than a workaround.

Also FF 78.11.0 has a requirement on libnss3 >= 3.51.1 so also Firefox
is working with the available older version of this library.

I'm using locally FF 88.0 from experiemntal

-- 
Regards
Carsten

Bug#909567: ITP: opensnitch -- Port of the Little Snitch application firewall

[Harald Dunkel]

Upstream seems to provide Debian support:

https://github.com/evilsocket/opensnitch/tree/master/debian

Bug#989931: Package zeal is missing in debian 11 "Bullseye"

[Волков Сергей Игоревич]

Package: zeal
Version: 1:0.6.1-1.2

Hello!
zeal was REMOVED from testing 2020-12-27
Migration status for zeal (- to 1:0.6.1-1.2): BLOCKED .

The bug  has been 
fixed and there is no reason to block migration.

It is a very important package so I hope it will be ported to Bullseye as soon 
as possible.

Thank you!



---
___

С уважением,
зав. лабораторией ИТ
экономического факультета ЮФУ
Волков Сергей Игоревич.

Bug#989930: python3-yaml: please add Breaks against python-yaml and unversioned python from buster

[Andreas Beckmann]

Package: python3-yaml
Version: 5.3.1-4
Severity: serious
Tags: patch

Hi,

I'm trying to solve some incomplete upgrades from buster to bullseye.
I.e. apt tries to keep some obsolete packages from buster installed and
therefore cannot upgrade some other packages instead of removing the
obsolete bits and upgrading everything upgradable. This usually needs
some additional Breaks to be added to guide apt to the right way.

One challenge upgrading from buster is to get rid of the unversioned
python and friends along with most of the packages Python 2 modules.
The ros-* stack is a bit problematic here, but this can be solved by
adding some Breaks in python3-yaml. (Sounds a bit non-intuitive to add
them to a python3-* package, but there is no better fitting package with
a sufficiently high score involved in these scenarios.)

I've run a lot of upgrade tests and the results look very promising that
we can improve the number of clean upgrade paths with this patch.


Andreas
diff -Nru pyyaml-5.3.1/debian/changelog pyyaml-5.3.1/debian/changelog
--- pyyaml-5.3.1/debian/changelog   2021-05-21 17:11:00.0 +0200
+++ pyyaml-5.3.1/debian/changelog   2021-06-14 00:30:26.0 +0200
@@ -1,3 +1,16 @@
+pyyaml (5.3.1-5) UNRELEASED; urgency=medium
+
+  * python3-yaml: Copy Breaks: python (<< 2.7.18), python-minimal (<< 2.7.18),
+libpython-stdlib (<< 2.7.18) from python2.7 and add
+Breaks: python-yaml (<< 5.3.1-2) for smoother upgrades from buster.
+In some upgrade scenarios (mostly involving ros-* packages) these Breaks
+in python2.7 were ineffective because the unversioned python packages got
+higher scores. Copying the Breaks to python3-yaml which is the first
+python package scoring higher than the to-be-removed packages solves these
+issues.  (Closes: #-1)
+
+ -- Andreas Beckmann   Mon, 14 Jun 2021 00:30:26 +0200
+
 pyyaml (5.3.1-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru pyyaml-5.3.1/debian/control pyyaml-5.3.1/debian/control
--- pyyaml-5.3.1/debian/control 2021-05-21 17:11:00.0 +0200
+++ pyyaml-5.3.1/debian/control 2021-06-14 00:30:26.0 +0200
@@ -15,6 +15,11 @@
 Architecture: any
 Multi-Arch: allowed
 Depends: ${python3:Depends}, ${shlibs:Depends}, ${misc:Depends}
+Breaks:
+ python (<< 2.7.18),
+ python-minimal (<< 2.7.18),
+ libpython-stdlib (<< 2.7.18),
+ python-yaml (<< 5.3.1-2),
 Description: YAML parser and emitter for Python3
  Python3-yaml is a complete YAML 1.1 parser and emitter for Python3.  It can
  parse all examples from the specification. The parsing algorithm is simple