Bug#874207: Debian package for ‘geckodriver’

[Paul Wise]

Control: clone -1 -2
Control: reassign -2 firefox-esr

On Wed, 26 Feb 2020 16:09:20 +0800 Paul Wise wrote:

> I noticed that Ubuntu have a firefox-geckodriver package built from
> their firefox source package, so perhaps that could be used:

Presumably we will want firefox-esr-geckodriver too, cloning.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#982381: Workaround to get s3ql functional again

[Anthony DeRobertis]

Package: s3ql
Version: 3.7.0+dfsg-2
Followup-For: Bug #982381

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A workaround, at least if (like me) you've got S3QL running as a
dedicated user:

As the s3ql-user, run: pip3 install --user trio==0.18.0

This will install a newer version of trio (0.18.0) in ~/.local/lib —
once this bug is fixed, you can remove it.

- -- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing-debug'), (500, 
'stable-updates'), (500, 'testing'), (500, 'stable'), (130, 'unstable-debug'), 
(130, 'unstable'), (120, 'experimental-debug'), (120, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages s3ql depends on:
ii  fuse3 [fuse]  3.10.3-1
ii  libc6 2.31-12
ii  libjs-sphinxdoc   3.4.3-2
ii  libsqlite3-0  3.34.1-3
ii  procps2:3.3.17-5
ii  psmisc23.4-2
ii  python3   3.9.2-3
ii  python3-apsw  3.34.0-r1-1
ii  python3-cryptography  3.3.2-1
ii  python3-defusedxml0.6.0-2
ii  python3-dugong3.8.1+dfsg-1
ii  python3-google-auth   1.5.1-3
ii  python3-google-auth-oauthlib  0.4.2-1
ii  python3-pkg-resources 52.0.0-3
ii  python3-pyfuse3   3.2.0-2
ii  python3-requests  2.25.1+dfsg-2
ii  python3-systemd   234-3+b4
ii  python3-trio  0.13.0-2

s3ql recommends no packages.

s3ql suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCYLmngRUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf6kkwCfckQ/FVPZa3RBFNBC3PR6PJrfmUUA
n3d/GbFiwu8Spi1gwUrh0DKZmxth
=ZUtK
-END PGP SIGNATURE-

Bug#989452: bdebstrap: passing --target=- fails

[Vagrant Cascadian]

Package: bdebstrap
Version: 0.1.1-1
Severity: normal
X-Debbugs-Cc: vagr...@debian.org

I'm trying to create a squashfs image using zstd compression, and when
using mmdebstrap, this basically works using - as the image argument, as
it outputs a tarball on stdout, which I can pass to tar2sqfs with my
custom tar2sqfs arguments.

According to the bdebstrap manpage, the --target=- argument should be
valid.

   --target TARGET, TARGET
  The optional target argument can either be the path to a
  directory, the path to a tarball filename, the path to a squashfs
  image or -.


When I try to pass to pass --target=- to bdebstrap, it fails:

  $ bdebstrap --target=- --name
  zstdimage2 sid  | tar2sqfs --no-skip --exportable --compressor zstd 
--block-size 1048576 sid.squashfs
  2021-06-03 21:24:49,599 bdebstrap INFO: Creating output directory
  './zstdimage2'...
  2021-06-03 21:24:49,599 bdebstrap INFO: Saving configuration to
  './zstdimage2/config.yaml'.
  2021-06-03 21:24:49,602 bdebstrap INFO: Setting environment variable
  BDEBSTRAP_NAME=zstdimage2
  2021-06-03 21:24:49,603 bdebstrap INFO: Setting environment variable
  BDEBSTRAP_OUTPUT_DIR=/tmp/bdebstrap-output
  2021-06-03 21:24:49,603 bdebstrap INFO: Setting environment variable
  SOURCE_DATE_EPOCH=1622780689
  2021-06-03 21:24:49,603 bdebstrap INFO: Calling mmdebstrap -v
  "--essential-hook=mkdir -p \"\$1/tmp/bdebstrap-output\""
  "--customize-hook=chroot \"\$1\" dpkg-query
  -f='${Package}\t${Version}\n' -W >
  \"\$1/tmp/bdebstrap-output/manifest\"" "--customize-hook=sync-out
  \"/tmp/bdebstrap-output\" \"./zstdimage2\"" "--customize-hook=rm -rf
  \"\$1/tmp/bdebstrap-output\"" sid ./zstdimage2/-
  I: automatically chosen mode: unshare
  I: chroot architecture amd64 is equal to the host's architecture
  I: automatically chosen format: directory
  E: cannot create /tmp/tmp.bz2O8rD4SF/zstdimage2: Permission denied;
  cannot create /tmp/tmp.bz2O8rD4SF/zstdimage2/-: Permission denied;
  cannot create /tmp/tmp.bz2O8rD4SF/zstdimage2/-//etc: Permission denied;
  cannot create /tmp/tmp.bz2O8rD4SF/zstdimage2/-//etc/apt: Permission
  denied; cannot create
  /tmp/tmp.bz2O8rD4SF/zstdimage2/-//etc/apt/apt.conf.d: Permission denied
  W: listening on child socket failed:
  2021-06-03 21:24:50,141 bdebstrap INFO: Execution time: 0.546 seconds
  2021-06-03 21:24:50,141 bdebstrap ERROR: mmdebstrap failed with exit
  code 1. See above for details.
  reading tar header: short read


Or passing in the image output positional argument:

  $ bdebstrap --name zstdimage sid - | tar2sqfs --no-skip --exportable 
--compressor zstd --block-size 1048576 sid.squashfs
  2021-06-03 21:23:39,044 bdebstrap INFO: Creating output directory
  './zstdimage'...
  2021-06-03 21:23:39,044 bdebstrap INFO: Saving configuration to
  './zstdimage/config.yaml'.
  2021-06-03 21:23:39,047 bdebstrap INFO: Setting environment variable
  BDEBSTRAP_NAME=zstdimage
  2021-06-03 21:23:39,047 bdebstrap INFO: Setting environment variable
  BDEBSTRAP_OUTPUT_DIR=/tmp/bdebstrap-output
  2021-06-03 21:23:39,047 bdebstrap INFO: Setting environment variable
  SOURCE_DATE_EPOCH=1622780619
  2021-06-03 21:23:39,048 bdebstrap INFO: Calling mmdebstrap -v
  "--essential-hook=mkdir -p \"\$1/tmp/bdebstrap-output\""
  "--customize-hook=chroot \"\$1\" dpkg-query
  -f='${Package}\t${Version}\n' -W >
  \"\$1/tmp/bdebstrap-output/manifest\"" "--customize-hook=sync-out
  \"/tmp/bdebstrap-output\" \"./zstdimage\"" "--customize-hook=rm -rf
  \"\$1/tmp/bdebstrap-output\"" sid ./zstdimage/-
  I: automatically chosen mode: unshare
  I: chroot architecture amd64 is equal to the host's architecture
  I: automatically chosen format: directory
  E: cannot create /tmp/tmp.bz2O8rD4SF/zstdimage: Permission denied;
  cannot create /tmp/tmp.bz2O8rD4SF/zstdimage/-: Permission denied; cannot
  create /tmp/tmp.bz2O8rD4SF/zstdimage/-//etc: Permission denied; cannot
  create /tmp/tmp.bz2O8rD4SF/zstdimage/-//etc/apt: Permission denied;
  cannot create /tmp/tmp.bz2O8rD4SF/zstdimage/-//etc/apt/apt.conf.d:
  Permission denied
  W: listening on child socket failed:
  2021-06-03 21:23:39,560 bdebstrap INFO: Execution time: 0.522 seconds
  2021-06-03 21:23:39,561 bdebstrap ERROR: mmdebstrap failed with exit
  code 1. See above for details.
  reading tar header: short read


Thanks for developing and maintaining bdebstrap!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#989406: wireguard-dkms makes little sense with the bullseye kernel

[Daniel Kahn Gillmor]

On Thu 2021-06-03 01:37:25 +0300, Adrian Bunk wrote:
> Overall it feels like a package with high CVE risk and 0 users
> in bullseye.

I agree with Jason that some people may use non-standard, older kernels
with bullseye, so there is some value in continuing to provide
wireguard-dkms in bullseye to help those folks.  (i'm thinking about
people running older hardware that has had support dropped in newer
kernels, for example).  It is not going to be exactly 0 users, but i
expect the number to be small.  At the same time, a package with a small
number of users presents a smaller attack surface if a CVE does come up.

The stock kernels already avoid people accidentally pulling in
wireguard-dkms by default if they just "apt install wireguard".

At some point, though, people who choose to run their own (non-debian)
kernel will need to effectively take responsibility for their kernel
modules as well, so i do not expect Debian to continue shipping
wireguard-dkms indefinitely.  I do not expect to ship it in bookworm
(bullseye+1), for example.

--dkg

Bug#968683: resolvconf and wireguard-tools

[Daniel Kahn Gillmor]

On Mon 2020-10-12 09:35:56 +0200, Jack Henschel wrote:

> I also just ran into this issue yesterday.
> I installed `wireguard-tools` on a minimal Debian Buster system and 
> `wg-quick` gave me the same error:
>
>> wg-quick up wg0
>> ...
>> 
>> [#] resolvconf -a wg0 -m 0 -x
>> /usr/bin/wg-quick: line 32: resolvconf: command not found
>
> Is there a particular reason why `wireguard-tools` only "suggests" resolvconf 
> but does not depend on it?
> From my point of view, resolvconf should be a hard dependency.
>
> As mentioned before, installing the `resolvconf` package fixed the issue.

Some users of wireguard-tools may never need to use wg-quick (e.g. they
might just use /usr/bin/wg)

Or, if they do use wg-quick, they might not use it with a configuration
that tries to adjust the system resolvers.

Finally, the resolvconf interface might be supplied by a number of
different implementations -- either resolvconf, openresolv, or
systemd-resolved's alias of resolvectl could be the relevant
implementations.

please see #930735 for more discussion.

   --dkg


signature.asc
Description: PGP signature

Bug#425405: Not a bug

[Jonathan Nieder]

Hi,

Jonas Smedegaard wrote:

> I agree that this is unlikely a bug in Ghostscript.
>
> The test PDF provided by Jonathan Nieder _is_ searchable with Evince
> 3.38.2-1.
>
> If same file was not searchable with Evince available in January 2011,
> then the issue might be the encoding of the strings in the PDF, or it
> might be something else that confused that older release of Evince.
>
> But that test file was produced by LibreOffice.  I would expect that a
> file generated by cups-pdf would instead have cups-pdf as creator in the
> metadata.
>
> I therefore suspect that the test PDF file should be ignored for this
> issue, and that the originally reported issue is a different one:
[...]
> For the record: If you suspect that an issue is in Ghostscript then
> please provide the ghostscript command that causes this issue - without
> that the only possible action is to tag it as unreproducible and close
> it, which is not really helpful.

This response is puzzling.  The example that I produced was a simple
postscript file and then a ps2pdf command that invokes ghostscript to
produce this issue.  I don't understand why you're insisting
simultaneously that I should have

- used cups-pdf instead of using ghostscript directly
- used ghostscript directly instead of using a larger pipeline that
  invokes it

since I don't see how those are possible to do at the same time.

[...]
> Ghostscript primarily renders a "painting" and secondarily preserves as
> metadata high-level information like strings of text and color spaces.
>
> One way metadata is lost is if CUPS filters use Postsript as
> intermediary format.  That was the case in the past but the default
> should nowadays use PDF as intermediary format.

This analysis seems spot-on; I think you have correctly described the
issue.

[...]
> This issue is highly likely a duplicate of 847462 - thus merging.

IIUC that bug was fixed by switching to the pdftocairo renderer.
Thanks much, this makes a lot of sense to me.

Sincerely,
Jonathan

Bug#989451: Please backport "net: usb: cdc_ncm: don't spew notifications" (de658a195ee23ca6aaffe197d1d2ea040beea0a2)

[Josh Triplett]

Package: src:linux
Version: 5.10.40-1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

Some USB Ethernet devices using the cdc_ncm driver produce several of
these messages per second:

Jun 03 19:25:17 s kernel: cdc_ncm 3-2.2:2.0 enx(mac address): 1000 mbit/s 
downlink 1000 mbit/s uplink

This results in substantial log noise and disk usage.

Please consider backporting the upstream patch "net: usb: cdc_ncm: don't
spew notifications" (git commit
de658a195ee23ca6aaffe197d1d2ea040beea0a2), which fixes this problem.

Thank you,
Josh Triplett

Bug#573254: (no subject)

[Sam Pinkus]

  
  
Issue still exists in upstream. Is considered very minor and won't
be fixed. See https://github.com/rsnapshot/rsnapshot/issues/281

Thanks,

Sam.

-- 
  PGP:
0xA53455C1

  

Bug#989448: unblock: htmldoc/1.9.11-4

[Håvard Flaget Aasen]

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

Please unblock package htmldoc

This release adds patches to fix 8 CVE's and closes: #989437.

There are two things which is not needed in this release.
Though the changes is not related to the code. I added the file
'debian/gbp.conf' since I changed the repository layout. I also fixed a
minor error in the previous changelog entry, added a missing '#' in a
'close bug' statement.

[ Reason ]
CVE-2021-23158, CVE-2021-23165, CVE-2021-23180, CVE-2021-23191,
CVE-2021-23206, CVE-2021-26252, CVE-2021-26259 and CVE-2021-26948

[ Impact ]

[ Tests ]
I have manually tested CVE-2021-23158, CVE-2021-23165, CVE-2021-23180,
CVE-2021-23206 and CVE-2021-26252
The issues in GitHub provided files that failed, before the fix was
applied, and succeeded with this release.

[ Risks ]
I consider this to be of minor risk. Code is coming from upstream, which
also has released a new version with the changes.

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

[ Other info ]

unblock htmldoc/1.9.11-4

Regards,
Håvard
diff -Nru htmldoc-1.9.11/debian/changelog htmldoc-1.9.11/debian/changelog
--- htmldoc-1.9.11/debian/changelog 2021-05-10 16:10:41.0 +0200
+++ htmldoc-1.9.11/debian/changelog 2021-06-03 21:29:16.0 +0200
@@ -1,7 +1,16 @@
+htmldoc (1.9.11-4) unstable; urgency=medium
+
+  * Add patches to fix many CVE's. Closes: #989437
+Fix: CVE-2021-23158, CVE-2021-23165, CVE-2021-23180, CVE-2021-23191,
+CVE-2021-23206, CVE-2021-26252, CVE-2021-26259, CVE-2021-26948.
+  * Switch to DEP-14 layout
+
+ -- Håvard Flaget Aasen   Thu, 03 Jun 2021 21:29:16 
+0200
+
 htmldoc (1.9.11-3) unstable; urgency=medium
 
   * Add patch to mitigate buffer-overflow caused by integer-overflow in
-image_load_gif() Closes: 984765 and fixes CVE-2021-20308
+image_load_gif() Closes: #984765 and fixes CVE-2021-20308
 
  -- Håvard Flaget Aasen   Mon, 10 May 2021 16:10:41 
+0200
 
diff -Nru htmldoc-1.9.11/debian/gbp.conf htmldoc-1.9.11/debian/gbp.conf
--- htmldoc-1.9.11/debian/gbp.conf  1970-01-01 01:00:00.0 +0100
+++ htmldoc-1.9.11/debian/gbp.conf  2021-05-23 08:32:55.0 +0200
@@ -0,0 +1,3 @@
+[DEFAULT]
+debian-branch = debian/latest
+upstream-branch = upstream/latest
diff -Nru 
htmldoc-1.9.11/debian/patches/CVE-2021-23158-CVE-2021-23191-CVE-2021-26252.patch
 
htmldoc-1.9.11/debian/patches/CVE-2021-23158-CVE-2021-23191-CVE-2021-26252.patch
--- 
htmldoc-1.9.11/debian/patches/CVE-2021-23158-CVE-2021-23191-CVE-2021-26252.patch
1970-01-01 01:00:00.0 +0100
+++ 
htmldoc-1.9.11/debian/patches/CVE-2021-23158-CVE-2021-23191-CVE-2021-26252.patch
2021-06-03 21:29:16.0 +0200
@@ -0,0 +1,128 @@
+From: Michael R Sweet 
+Date: Thu, 1 Apr 2021 09:37:58 -0400
+Subject: CVE-2021-23158, CVE-2021-23191, CVE-2021-26252
+
+Fix JPEG error handling (Issue #415)
+
+Origin: upstream, 
https://github.com/michaelrsweet/htmldoc/commit/369b2ea1fd0d0537ba707f20a2f047b6afd2fbdc
+Bug: https://github.com/michaelrsweet/htmldoc/issues/412
+Bug: https://github.com/michaelrsweet/htmldoc/issues/414
+Bug: https://github.com/michaelrsweet/htmldoc/issues/415
+Bug-Debian: https://bugs.debian.org/989437
+---
+ htmldoc/file.c |  9 -
+ htmldoc/image.cxx  | 38 +++---
+ htmldoc/ps-pdf.cxx |  5 +
+ 3 files changed, 44 insertions(+), 8 deletions(-)
+
+diff --git a/htmldoc/file.c b/htmldoc/file.c
+index 20229c1..9f017de 100644
+--- a/htmldoc/file.c
 b/htmldoc/file.c
+@@ -1000,8 +1000,15 @@ file_rlookup(const char *filename)  /* I - Filename 
*/
+ 
+ 
+   for (i = web_files, wc = web_cache; i > 0; i --, wc ++)
++  {
+ if (!strcmp(wc->name, filename))
+-  return (wc->url);
++{
++  if (!strncmp(wc->url, "data:", 5))
++return ("data URL");
++  else
++return (wc->url);
++}
++  }
+ 
+   return (filename);
+ }
+diff --git a/htmldoc/image.cxx b/htmldoc/image.cxx
+index 8f53050..74abfac 100644
+--- a/htmldoc/image.cxx
 b/htmldoc/image.cxx
+@@ -1336,6 +1336,15 @@ image_load_gif(image_t *img,/* I - Image pointer */
+ }
+ 
+ 
++typedef struct hd_jpeg_err_s  // JPEG error manager extension
++{
++  struct jpeg_error_mgr   jerr;   // JPEG error manager information
++  jmp_buf retbuf; // setjmp() return buffer
++  charmessage[JMSG_LENGTH_MAX];
++  // Last error message
++} hd_jpeg_err_t;
++
++
+ /*
+  * 'image_load_jpeg()' - Load a JPEG image file.
+  */
+@@ -1347,14 +1356,21 @@ image_load_jpeg(image_t *img,  /* I - Image pointer */
+ int load_data)/* I - 1 = load image data, 0 = just info */
+ {
+   struct jpeg_decompress_struct   cinfo;  /* Decompressor info */
+-  struct jpeg_error_mgr 

Bug#989444: Debian: jemalloc: add arc support

[Vineet Gupta]

Update: upstream change has just now been merged.

Thx,
-Vineet

Bug#989444: Debian: jemalloc: add arc support

[Vineet Gupta]

Source: jemalloc
Severity: normal
Tags: patch

Hi,

This is needed to bootstrap arc port.

Merge request exist in upstream jemalloc:
https://github.com/jemalloc/jemalloc/pull/2070

And also in debian
https://salsa.debian.org/debian/jemalloc/-/merge_requests/5

Thx,
-Vineet

Bug#793687: (no subject)

[Sam Pinkus]

  
  
Cannot reproduce on upstream source. This appears to have been fixed
in upstream master and in last tagged release (1.4.3, Nov 17 2019).

Thanks,

Sam.

-- 
  PGP:
0xA53455C1

  

Bug#859099: (no subject)

[Sam Pinkus]

Cannot reproduce. This appears to have been fixed in upstream master and 
in last tagged release (1.4.3, Nov 17 2019).


Thanks,

Sam.

--

*PGP*: 0xA53455C1

Bug#989443: Debian: libffi: update symbols for ARC

[Vineet Gupta]

Source: libffi
Severity: normal
Tags: patch

Hi,

This is needed to bootstrap arc port.
Patch attached.

Thx,
-Vineet
--- a/debian/libffi7.symbols.orig	2021-04-02 04:04:04.290554369 +
+++ b/debian/libffi7.symbols	2021-04-02 04:05:46.914554369 +
@@ -1,6 +1,6 @@
 libffi.so.7 libffi7 #MINVER#
  (symver)LIBFFI_BASE_7.0 3.3~20180313
  (symver)LIBFFI_CLOSURE_7.0 3.3~20180313
- (symver|arch=!hppa !ia64 !m68k !nios2 !riscv64 !sh4)LIBFFI_GO_CLOSURE_7.0 3.3~20180313
- (symver|arch=!hppa !ia64 !m68k !mips !mipsel !mips64 !mips64el !nios2 !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !sh4)LIBFFI_COMPLEX_7.0 3.3~20180313
+ (symver|arch=!arc !hppa !ia64 !m68k !nios2 !riscv64 !sh4)LIBFFI_GO_CLOSURE_7.0 3.3~20180313
+ (symver|arch=!arc !hppa !ia64 !m68k !mips !mipsel !mips64 !mips64el !nios2 !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !sh4)LIBFFI_COMPLEX_7.0 3.3~20180313
  (symver)LIBFFI_BASE_7.1 3.3~20180313

Bug#989442: Debian: openssl: Add ARC target

[Vineet Gupta]

Source: openssl
Severity: normal
Tags: patch

Hi,

This is needed to bootstrap arc port.
Patch attached.

Thx,
-Vineet
From 3268f18d797fb807a91a71266243e37749711b81 Mon Sep 17 00:00:00 2001
From: Vineet Gupta 
Date: Thu, 3 Jun 2021 12:12:46 -0700
Subject: [PATCH] ARC arc target

Signed-off-by: Vineet Gupta 
---
 debian/patches/debian-targets-arc.patch | 12 
 debian/patches/series   |  1 +
 2 files changed, 13 insertions(+)
 create mode 100644 debian/patches/debian-targets-arc.patch

diff --git a/debian/patches/debian-targets-arc.patch b/debian/patches/debian-targets-arc.patch
new file mode 100644
index ..66be6afece80
--- /dev/null
+++ b/debian/patches/debian-targets-arc.patch
@@ -0,0 +1,12 @@
+--- a/Configurations/20-debian.conf
 b/Configurations/20-debian.conf
+@@ -13,6 +13,9 @@ my %targets = (
+ 		inherit_from => [ "debian-alpha" ],
+ 		cflags => add("-mcpu=ev5"),
+ 	},
++	"debian-arc" => {
++		inherit_from => [ "linux-generic32", "debian" ],
++	},
+ 	"debian-arm64" => {
+ 		inherit_from => [ "linux-aarch64", "debian" ],
+ 	},
diff --git a/debian/patches/series b/debian/patches/series
index 54001c0d7f22..ebc70bc7101a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@ no-symbolic.patch
 pic.patch
 c_rehash-compat.patch
 Set-systemwide-default-settings-for-libssl-users.patch
+debian-targets-arc.patch
-- 
2.25.1

Bug#989440: Debian: gmp: add support for arc

[Vineet Gupta]

Source: gmp
Severity: normal
Tags: patch

Hi,

To bootstrap arc port we need symbols file update in gmp.
Patch attached.

Thx,
-Vineet
From 5894e168f3a19e2f113f672697cf8bb078a65a9f Mon Sep 17 00:00:00 2001
From: Vineet Gupta 
Date: Thu, 3 Jun 2021 11:33:05 -0700
Subject: [PATCH] Update symbols file for arc

Signed-off-by: Vineet Gupta 
---
 debian/libgmp10.symbols | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/debian/libgmp10.symbols b/debian/libgmp10.symbols
index 966cdc558c49..568049034d51 100644
--- a/debian/libgmp10.symbols
+++ b/debian/libgmp10.symbols
@@ -218,7 +218,7 @@ libgmp.so.10 libgmp10 #MINVER#
  (arch=any-i386)__gmpn_add_n_pentium@Base 2:5.1.1
  __gmpn_add_n_sub_n@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_n_x86@Base 2:5.1.1
- (arch=!hppa !mips !mipsel !m68k !nios2 !riscv64 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_add_nc@Base 0
+ (arch=!arc !hppa !mips !mipsel !m68k !nios2 !riscv64 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_add_nc@Base 0
  (arch=any-i386)__gmpn_add_nc_atom@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_nc_k6@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_nc_k7@Base 2:5.1.1
@@ -227,9 +227,9 @@ libgmp.so.10 libgmp10 #MINVER#
  (arch=any-i386)__gmpn_add_nc_pentium@Base 2:5.1.1
  (arch=any-i386)__gmpn_add_nc_x86@Base 2:5.1.1
  (arch=any-amd64)__gmpn_addaddmul_1msb0@Base 0
- (arch=!hppa !m68k !mips !mips64 !mips64el !mipsel !nios2 !riscv64 !sh3 !sh4 !sparc !sparc64 !tilegx)__gmpn_addlsh1_n@Base 2:6.2.0
+ (arch=!arc !hppa !m68k !mips !mips64 !mips64el !mipsel !nios2 !riscv64 !sh3 !sh4 !sparc !sparc64 !tilegx)__gmpn_addlsh1_n@Base 2:6.2.0
  (arch=any-i386)__gmpn_addlsh1_n_init@Base 2:5.1.1
- (arch=!armel !armhf !hppa !m68k !mips !mips64 !mips64el !mipsel !nios2 !powerpc !powerpcspe !riscv64 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx)__gmpn_addlsh2_n@Base 2:6.2.0
+ (arch=!arc !armel !armhf !hppa !m68k !mips !mips64 !mips64el !mipsel !nios2 !powerpc !powerpcspe !riscv64 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx)__gmpn_addlsh2_n@Base 2:6.2.0
  (arch=any-i386)__gmpn_addlsh2_n_init@Base 2:5.1.1
  (arch=any-amd64)__gmpn_addlsh_n@Base 0
  __gmpn_addmul_1@Base 0
@@ -273,7 +273,7 @@ libgmp.so.10 libgmp10 #MINVER#
  __gmpn_brootinv@Base 2:5.1.1
  __gmpn_bsqrt@Base 2:5.1.1
  __gmpn_bsqrtinv@Base 2:5.1.1
- (arch=hurd-i386 i386 kfreebsd-i386 riscv64 s390x sh4 sparc64)__gmpn_clz_tab@Base 2:6.2.0
+ __gmpn_clz_tab@Base 2:6.2.0
  __gmpn_cmp@Base 0
  __gmpn_cnd_add_n@Base 2:6.0.0
  (arch=any-i386)__gmpn_cnd_add_n_atom@Base 2:5.1.1
@@ -398,7 +398,7 @@ libgmp.so.10 libgmp10 #MINVER#
  __gmpn_hgcd_reduce_itch@Base 2:5.1.1
  __gmpn_hgcd_step@Base 2:5.1.1
  __gmpn_invert@Base 0
- (arch=!hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !riscv64 !sparc !sparc64 !sh3 !sh4 !tilegx !any-i386)__gmpn_invert_limb@Base 0
+ (arch=!arc !hppa !mips !mipsel !mips64 !mips64el !m68k !nios2 !riscv64 !sparc !sparc64 !sh3 !sh4 !tilegx !any-i386)__gmpn_invert_limb@Base 0
  __gmpn_invertappr@Base 0
  __gmpn_ior_n@Base 0
  __gmpn_iorn_n@Base 0
@@ -508,7 +508,7 @@ libgmp.so.10 libgmp10 #MINVER#
  (arch=any-i386)__gmpn_mul_1_pentium@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1_pentium_mmx@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1_x86@Base 2:5.1.1
- (arch=!any-i386 !armel !armhf !hppa !m68k !mips !mips64 !mips64el !mipsel !nios2 !powerpc !powerpcspe !riscv64 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx)__gmpn_mul_1c@Base 2:6.2.0
+ (arch=!any-i386 !arc !armel !armhf !hppa !m68k !mips !mips64 !mips64el !mipsel !nios2 !powerpc !powerpcspe !riscv64 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx)__gmpn_mul_1c@Base 2:6.2.0
  (arch=any-i386)__gmpn_mul_1c_atom_sse2@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1c_k6@Base 2:5.1.1
  (arch=any-i386)__gmpn_mul_1c_k7@Base 2:5.1.1
@@ -571,13 +571,13 @@ libgmp.so.10 libgmp10 #MINVER#
  __gmpn_redc_n@Base 0
  __gmpn_remove@Base 0
  __gmpn_rootrem@Base 0
- (arch=!alpha !any-i386 !armel !armhf !hppa !m68k !mips !mips64 !mips64el !mipsel !nios2 !powerpc !powerpcspe !riscv64 !sh3 !sh4 !sparc !sparc64 !tilegx)__gmpn_rsblsh1_n@Base 2:6.2.0
- (arch=!alpha !any-i386 !armel !armhf !hppa !m68k !mips !mips64 !mips64el !mipsel !nios2 !powerpc !powerpcspe !riscv64 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx)__gmpn_rsblsh2_n@Base 2:6.2.0
- (arch=!alpha !arm64 !armel !armhf !hppa !ia64 !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_rsblsh_n@Base 0
- (arch=!alpha !any-i386 !hppa !m68k !mips !mips64 !mips64el !mipsel !nios2 !powerpc !powerpcspe !riscv64 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx)__gmpn_rsh1add_n@Base 2:6.2.0
- (arch=!alpha !arm64 !armel !armhf !hppa !ia64 !mips !mipsel !mips64 !mips64el !m68k !nios2 !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !s390x !sh3 !sh4 !sparc !sparc64 !tilegx !any-i386)__gmpn_rsh1add_nc@Base 0
- (arch=!alpha !any-i386 !hppa !m68k !mips !mips64 !mips64el !mipsel !nios2 !powerpc !powerpcspe !riscv64 !s390x !sh3 !sh4 

Bug#989450: bdebstrap: Unconditionally passes verbose "-v" option to mmdebstrap

[Vagrant Cascadian]

Package: bdebstrap
Version: 0.1.1-1
Severity: wishlist
X-Debbugs-Cc: Vagrant Cascadian 

bdebstrap is a nice way to pass complicated commands to mmdebstrap,
thanks!

There appears to be no way to disable the "-v" argument passed to
mmdebstrap.

While I can see value in increased verbosity in some situations, it
would be nice to be able to get mmdebstrap's simple and minimal progress
bar output while still using bdebstrap for the configuration and other
features it provides.

Simply removing the "-v" argument in /usr/bin/bdebstrap appears to work
fine, though obviously people who want the increased verbosity will need
to add it back somehow.

Thanks!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#989449: unblock: exabgp/4.2.8-2

[Vincent Bernat]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please unblock package exabgp

[ Reason ]
When run as root, ExaBGP won't be able to access the FIFO owned by the
exabgp user. Make ExaBGP run as exabgp user to fix this situation. No
need to run as root as the process has the CAP_NET_ADMIN and can
therefore bind to port 179 if needed.

[ Impact ]
ExaBGP does not work out-of-the box. See #886568 and #989447.

[ Tests ]
Several users confirmed the issue is fixed in 4.2.8-2. Change has also
been accepted upstream.

[ Risks ]
This is a leaf package. Change is small. User can still fix the
problem itself if we introduce another issue.

[ 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 exabgp/4.2.8-2


-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmC5W6QSHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5CnkQAIkOlUHYhz0grHKmD9OiUjfT7R+gF8tp
/t+Vh6bMMIaFxkX/4k+uhnNoUqoKEs/563x8mvBOzyQJFADsiNTeHV0nALbiFTPr
Yx/SrdoySYRefauB6rSmOjfXaeMo4Qkd5Nhd3xZYI0dgMs2MWFI34KXfDKIT52NA
UHA1NXL6RzDbKEEmp4/iSBtpWGj4Qk118r0clQtISUbkIPci34RFbf/Lu5x+YJuf
xrJdjYQOQZKK3aFZy4oSvh6pwq678mckHJ3gXOUboHhwV76chhhyqC1xRI1a4mI9
eI1jx3I1Y+qqu6IxDEA7+IA7MP6aW3DYXKLYlE5u5ZwK4Dns/qrtpGI9Eq00YUCx
TGGBqswRn1h+CORDZYrkZNRnYo5x7kXamg4axzqrGGQv+FChDBQmb8zudzB6K1xv
DKRyQHBZlbwhb8+XSvcIWjM42BgAkkuU4bMLosJTcryNZsjvlrXkCu/Q8ST97LfB
9gOnViSZNhyps+mlOUecZvkyEV81W8xoBQyZh3AMKt56GXFFl+IB3AyQkLtD/Ebg
j8w/gAECb3SF93tkw7hfIYOIt5ZRlYZGXWZ26+sZkI+h80R2HcOLDCqW05Aj1cMK
v7nXCxZR7ZLVYMaBGnvHU7atAFazESu5ZGeUYXrRA3lS1S715XwwfDgLMqVt2pEm
S+Zlt5wPiY7E
=Md+w
-END PGP SIGNATURE-
diff --git a/debian/changelog b/debian/changelog
index 8d8be4a94d23..05580f6f4a6c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+exabgp (4.2.8-2) unstable; urgency=medium
+
+  * Patch exabgp.service to fix socket creation on start.
+Closes: #886568.
+
+ -- Vincent Bernat   Sun, 02 May 2021 17:48:55 +0200
+
 exabgp (4.2.8-1) unstable; urgency=medium
 
   * New upstream release.
diff --git 
a/debian/patches/0001-Patch-exabgp.service-to-fix-socket-creation-on-start.patch
 
b/debian/patches/0001-Patch-exabgp.service-to-fix-socket-creation-on-start.patch
new file mode 100644
index ..78d26f73f093
--- /dev/null
+++ 
b/debian/patches/0001-Patch-exabgp.service-to-fix-socket-creation-on-start.patch
@@ -0,0 +1,38 @@
+From: Vincent Bernat 
+Date: Sun, 2 May 2021 17:47:10 +0200
+Subject: Patch exabgp.service to fix socket creation on start
+
+Patch from Marco d'Itri.
+
+Closes: #886568.
+---
+ etc/systemd/exabgp.service | 15 ++-
+ 1 file changed, 6 insertions(+), 9 deletions(-)
+
+diff --git a/etc/systemd/exabgp.service b/etc/systemd/exabgp.service
+index 17ce886..b2da5ba 100644
+--- a/etc/systemd/exabgp.service
 b/etc/systemd/exabgp.service
+@@ -7,16 +7,13 @@ After=network.target
+ ConditionPathExists=/etc/exabgp/exabgp.conf
+ 
+ [Service]
+-#User=exabgp
+-#Group=exabgp
+ Environment=exabgp_daemon_daemonize=false
+-PermissionsStartOnly=true
+-ExecStartPre=-mkfifo /run/exabgp.in
+-ExecStartPre=-mkfifo /run/exabgp.out
+-ExecStartPre=chmod 600 /run/exabgp.in
+-ExecStartPre=chmod 600 /run/exabgp.out
+-ExecStartPre=chown exabgp.exabgp /run/exabgp.in
+-ExecStartPre=chown exabgp.exabgp /run/exabgp.out
++User=exabgp
++Group=exabgp
++RuntimeDirectory=exabgp
++RuntimeDirectoryMode=0750
++ExecStartPre=-/usr/bin/mkfifo /run/exabgp/exabgp.in
++ExecStartPre=-/usr/bin/mkfifo /run/exabgp/exabgp.out
+ ExecStart=/usr/sbin/exabgp /etc/exabgp/exabgp.conf
+ ExecReload=/bin/kill -USR1 $MAINPID
+ Restart=always
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index ..24c1c8f183a2
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-Patch-exabgp.service-to-fix-socket-creation-on-start.patch

Bug#989434: libsepol 3.2: cherry-pick fix for role attributes

[Christian Göttsche]

Source: libsepol
Version: 3.2-1
Severity: serious

Please cherry-pick commit f7431d0e0ed9 ("libsepol: Expand role
attributes in constraint expressions") [1], as it fixes a regression
using role attributes in constraints reported at [2].
Otherwise role attributes in constraints are not validated, introduced with [3].


[1]: 
https://github.com/SELinuxProject/selinux/commit/f7431d0e0ed9f695a6a8af74c3f239f80649a167
[2]: 
https://lore.kernel.org/selinux/CAJ2a_Dd_tccbWwA_S8nnRvpAVJW8EcrU3t3R7e=mcthsx0l...@mail.gmail.com/t/#u
[3]: 
https://github.com/SELinuxProject/selinux/commit/0861c659b59cb106bad1b1d0c9f511a7140a1023

Bug#989447: exabgp service keeps restarting indifinitely

[Lucas da Vila]

Package: exabgp
Version: 4.2.8-1
Severity: normal
X-Debbugs-Cc: ldav...@syt.net

Dear Maintainer,

   * What led up to the situation?
   After installing the exabgp package and creating the
   /etc/exabgp/exabgp.conf file I've tried to start the service `service
   exabgp start`. Exabgp started and announced the route to a route-server
   buy the route was flapping because the exabgp service was restart
   periodically.
   This error showed up 
   ```
   | api | command from process not
   understood : error: a named pipe exists and we can not read/write to
   it ( /run/exabgp.in )
   | process | Too many death for api-internal-cli-fe70ad58 (5) 
terminating program
   | reactor | Problem when sending message(s) to helper program, 
stopping
   | reactor | performing shutdown
   ```

   The /run/exabgp.in has the followinf permissions:
   ```
   # ls -l /run/exabgp*
   prw--- 1 exabgp exabgp  0 Jun  1 22:30 /run/exabgp.in
   prw--- 1 exabgp exabgp  0 Jun  1 22:30 /run/exabgp.out
   ```

   I think it's permissions issue beetween the user running de process
   and the user that owns the files.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 I've removed the comment on the lines `User=exabgp` and
 `Group=exagp` in the /lib/systemd/system/exabgp.service 

   * What was the outcome of this action?
   The exabgp service stopped restarting, and the error didn't appear
   anymore




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

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

Versions of packages exabgp depends on:
ii  adduser3.118
ii  debconf1.5.75
ii  dpkg   1.20.9
ii  lsb-base   11.1.0
ii  python3-exabgp 4.2.8-1
ii  python3-pkg-resources  52.0.0-3
ii  ucf3.0043

exabgp recommends no packages.

exabgp suggests no packages.

-- no debconf information

Bug#989446: unblock: apt-transport-s3/2.0.0-2

[Marcin Kulisz]

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

Please unblock package apt-transport-s3

We need this package to be included in the Bullseye release, changeset is
minimal and only contains fix for the RC bug (#986647).
Impact of this change should be minimal as the change is really simple type
casting.
Set of manual tests including fetching and installing packages via apt with this
transport has been run successfully.

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

unblock apt-transport-s3/2.0.0-2

*** /tmp/apt-transport-s3.debdiff
diff -Nru apt-transport-s3-2.0.0/debian/changelog 
apt-transport-s3-2.0.0/debian/changelog
--- apt-transport-s3-2.0.0/debian/changelog 2019-08-27 14:22:40.0 
+0100
+++ apt-transport-s3-2.0.0/debian/changelog 2021-06-03 20:20:49.0 
+0100
@@ -1,3 +1,9 @@
+apt-transport-s3 (2.0.0-2) unstable; urgency=medium
+
+  * Applying patch fixing string opperations (Closes: #986647)
+
+ -- Marcin Kulisz   Thu, 03 Jun 2021 20:20:49 +0100
+
 apt-transport-s3 (2.0.0-1) unstable; urgency=medium
 
   [ Hayden Myers ]
diff -Nru 
apt-transport-s3-2.0.0/debian/patches/0001-Added-explicit-string-casing-Closes-986647.patch
 
apt-transport-s3-2.0.0/debian/patches/0001-Added-explicit-string-casing-Closes-986647.patch
--- 
apt-transport-s3-2.0.0/debian/patches/0001-Added-explicit-string-casing-Closes-986647.patch
 1970-01-01 01:00:00.0 +0100
+++ 
apt-transport-s3-2.0.0/debian/patches/0001-Added-explicit-string-casing-Closes-986647.patch
 2021-06-03 20:20:49.0 +0100
@@ -0,0 +1,24 @@
+From: Marcin Kulisz 
+Date: Thu, 3 Jun 2021 20:10:24 +0100
+Subject: Added explicit string casing (Closes: #986647)
+
+---
+ s3 | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/s3 b/s3
+index 01b1d9d..83a6dfa 100755
+--- a/s3
 b/s3
+@@ -187,8 +187,9 @@ class AWSCredentials(object):
+ 
+ if data.get("AccessKeyId") is None:
+ self.__get_role()
+-data = 
self.__request_json(urllib.parse.urljoin(self.credentials_metadata,
+-self.iamrole))
++data = self.__request_json(urllib.parse.urljoin(
++str(self.credentials_metadata, 'utf-8'),
++str(self.iamrole, 'utf-8')))
+ 
+ self.access_key = data['AccessKeyId']
+ if self.access_key is None or self.access_key == '':
diff -Nru apt-transport-s3-2.0.0/debian/patches/series 
apt-transport-s3-2.0.0/debian/patches/series
--- apt-transport-s3-2.0.0/debian/patches/series1970-01-01 
01:00:00.0 +0100
+++ apt-transport-s3-2.0.0/debian/patches/series2021-06-03 
20:20:49.0 +0100
@@ -0,0 +1 @@
+0001-Added-explicit-string-casing-Closes-986647.patch

Bug#989399: nauty FTCBFS -- multiple reasons

[Étienne Mollier]

Control: severity -1 important

Greetings everyone,

focusing on the baseline violation aspect…

Helmut Grohne, on 2021-06-02:
> The check does not want to know whether the compiler supports
> popcnt (which could be determined using AC_LINK_IFELSE), but whether the
> CPU does and AC_LINK_IFELSE does not suffice here.
> 
> Unfortunately such opportunistic use of the popcnt instruction violates
> the i386 baseline as it does not include SSE4 at this time. This is a
> serious bug. For Debian, such detection is not appropriate. Debian
> builds must pass --disable-popcnt for any-i386. If the package is deemed
> unusable without such performance optimizations, it should at least
> depend on the appropriate isa-support package likely sse4.2-support.

I have looked up the issue, and rebuilt the package on a popcnt
enabled CPU.  When disassembling the binary packages, I have
seen no traces of *cnt instructions, neither in the libraries,
nor in executable programs.  I do see the following in the build
log, which is quite concerning:

CC=gcc
CFLAGS=-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security
MORECFLAGS= -mpopcnt -march=native
 ~

The -march=native would cause even worse baseline violations
than -mpopcnt, especially if the build occurs on very recent
hardware.  To eliminate both of these entries off the equation,
one would have to configure the build with both --disable-popcnt
and --enable-generic.


Fortunately, note that the MORECFLAGS variable does not make it
down to build options, although it is concatenated into CFLAGS
in makefile.in.  This seems to explain why I don't see baseline
violations in the resulting binary objects on my end.  Still,
standard Debian options are accounted for properly.  I believe
our dh build process never uses upstream's makefile.in template,
but an entirely autoreconf-ed one instead, which does not know
anything of MORECFLAGS, hence the proper result in spite of the
confusing options.

Since the compilation does seem to result in baseline clean
binaries, I dropped the severity to "important".  I prefer not
closing the bug, since I guess plans to adjust the logic for
cross buildability could, eventually, end up injecting such
option properly in the build process.  Of course, please feel
free to readjust the severity, if I missed an important thing in
the problem at play.

Hope this helps,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/8, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#981794: RFS: gftools/0.5.2+dfsg-1 [ITP] -- Google Fonts Tools

[Romain Porte]

03/06/2021 09:27, Tobias Frost :
> On Wed, Jun 02, 2021 at 11:57:51PM +0200, Romain Porte wrote:
>> Hi tobi,
>>
>> On Wed, 02 Jun 2021 17:02:06 +0200 Tobias Frost  wrote:
>>
>> I have fixed this issue by renaming the dependency to the correct name
>> (python3-ots instead of python3-opentype-sanitizer). New package version
>> has just been signed and uploaded to mentors [1]. The commit that
>> provides the fix was also pushed to the Salsa repository [2].
>>
> Thanks for the quick update!
>
> The package seems good, beside d/copyright:
> - Copyright years are missing
> - d/copyright is incomplete/inaccurate:
> for example: file bin/gftools-fix-ascii-fontmetadata.py has:
> # Copyright 2013 The Font Bakery Authors.
> # Copyright 2017 The Google Font Tools Authors
> (- optional: Its customary to say "Apache-2.0", not "Apache-2" as license
>identifier in d/copyright, this is also the SPDX identifier for it.)
>
> So, after you've reviewed and updated c/copyright, ping me again.

Thanks for the review, new proposal sent to mentors (#7) and commits
pushed to salsa to fix all of the listed issues.


> (Note: I'm usually not sponsoring python, but as this package blocks other 
> RFSs,
> I'm doing an exception here. If someone with more experience in this field 
> wants
> to chime in, I'd be happy.)

I usually work with the Python team, but to me this package makes more
sense to be in the Debian Fonts team. I think I applied all of the good
practises enforced by the Debian Python team on their packages, so there
should not be any issues even from a Python perspective.

Thanks in advance for the review/upload and cheers,

Romain.

Bug#988442: unblock: linux/5.10.40-1

[Cyril Brulebois]

Cyril Brulebois  (2021-06-02):
> Paul Gevers  (2021-06-01):
> > On 01-06-2021 08:06, Salvatore Bonaccorso wrote:
> > > The version is not 4 days in unstable, looks good to me to let it
> > > migrate to testing (unless Cyril spotted issues in recent d-i tests).
> > 
> > I'm still good to go.
> 
> Tests look good, please let it migrate. :)

JFTR: Hinted myself, along with other l10n-only or bugfixes for d-i
packages. Will keep an eye on this, and close this bug report once
migration has happend (just in case some bit is missing/some typo
happened or something).


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


signature.asc
Description: PGP signature

Bug#989445: "Command not found" when dragging file into folder ending in ".deb".

[Brian Woods]

Package: nemo
Version: 4.6.5+ulyana

uname -a: Linux ##ComputerName## 5.4.0-72-generic #80-Ubuntu SMP Mon
Apr 12 17:35:00 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux


Issue: Dragging a file into a folder with a ".deb" extension results
in a popup error stating:

Could not open "the_name_of_the_file_being_dragged"
Command not found


This appears to happen with multiple archive extensions such as ".zip" as well.

Bug#988830: [pre-approval] unblock e2fsprogs [Was: Bug#987641: e2fsprogs: FTBFS on armel/armhf with a 64-bit kernel]

[Paul Gevers]

Control: tags -1 = confirmed d-i

Hi Theodore,

Sorry it took so long.

On 20-05-2021 19:40, Theodore Y. Ts'o wrote:
> That patch is rather long, but it's all mostly of the form:
> 
> - tail = (struct ext4_fc_tail *)ext4_fc_tag_val(tl);
> + memcpy(, ext4_fc_tag_val(tl), sizeof(tail));
> 
> So the risks are very low.

As I can't judge this myself, I'll take your word for it. If the upload
can happen in the next couple of days, let's have this in unstable and
if nothing is reported, have it in bullseye.

Let's leave out the rest.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#988214: fixed in rails 2:6.0.3.7+dfsg-1

[Paul Gevers]

Hi Utkarsh,

On 27-05-2021 21:51, Paul Gevers wrote:
> You haven't answered my question: "does rails still work with the old
> version of ruby-marcel and can the version bump be reverted"

Ping. Without a proper answer, I can't decide.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#987262: [pre-approval] unblock: node-lodash/4.17.21+dfsg+~cs8.31.189.20210220-2

[Paul Gevers]

Hi Pirate,

On Thu, 22 Apr 2021 13:50:18 +0200 Ivo De Decker  wrote:
> It seems the RC bug fix is unrelated to the new upstream. Please prepare an
> upload based on the version currently in testing that only contains the 
fix
> for the RC bug, not the new upsteam.

Are you going to follow up on this? If not, please close this bug.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#989441: Missing Nvidia /lib/firmware/nouveau/nv106_fuc084

[Paul van der Vlis]

Package: firmware-nonfree
Version: 20210315-2

I did install a computer with this videocard with Debian 11 RC1:
0b:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 
710] (rev a1)


This firmware file was missing: /lib/firmware/nouveau/nv106_fuc084

Without it, vdpauinfo did tell that all decoder capabilities where not 
supported. With the file, some of them where supported.


from https://nouveau.freedesktop.org/VideoAcceleration.html

$ mkdir /tmp/nouveau
$ cd /tmp/nouveau
$ wget https://raw.github.com/envytools/firmware/master/extract_firmware.py
$ wget 
http://us.download.nvidia.com/XFree86/Linux-x86/325.15/NVIDIA-Linux-x86-325.15.run

$ sh NVIDIA-Linux-x86-325.15.run --extract-only
$ python2 extract_firmware.py  # this script is for python 2 only
# mkdir /lib/firmware/nouveau
# cp -d nv* vuc-* /lib/firmware/nouveau/


With regards,
Paul van der Vlis

--
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Bug#989439: CVE-2020-22033 CVE-2020-22021 CVE-2020-22019 CVE-2020-22015 CVE-2020-21041

[Moritz Muehlenhoff]

Package: ffmpeg
Version: 7:4.3.2-0+deb11u1
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

A few security issues:

CVE-2020-22033:
https://trac.ffmpeg.org/ticket/8246
https://trac.ffmpeg.org/ticket/8241
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=82ad1b76751bcfad5005440db48c46a4de5d6f02

CVE-2020-22021:
https://trac.ffmpeg.org/ticket/8240
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=7971f62120a55c141ec437aa3f0bacc1c1a3526b

CVE-2020-22019:
https://trac.ffmpeg.org/ticket/8246
https://trac.ffmpeg.org/ticket/8241
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=82ad1b76751bcfad5005440db48c46a4de5d6f02

CVE-2020-22015:
https://trac.ffmpeg.org/ticket/8190
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=4c1afa292520329eecd1cc7631bc59a8cca95c46

CVE-2020-21041:
https://trac.ffmpeg.org/ticket/7989
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=5d9f44da460f781a1604d537d0555b78e29438ba

Cheers,
 Moritz

Bug#989354: smokeping: Classical initscript (Sysvinit) fails to stop daemon

[Gabriel Filion]

Hi there Patrik,

Thanks for the change you've submitted! As you said, the init script is 
still there in the package so we might as well keep it maintained.


I've committed your change to salsa and it should make it to the next 
upload.


I'll see if I can gather the efforts necessary to get an upload soon to 
debian


Cheers!

Bug#987504: imagemagick: attempt to perform an operation not allowed by the security policy `EPS'

[Moritz Mühlenhoff]

Am Wed, May 19, 2021 at 08:49:01PM +0200 schrieb Paul Gevers:
> Hi,
> 
> First off, thanks Adrian for raising the concern. In general, at this
> stage we don't like packages breaking other packages.

This should have been fixed in unstable for a long time, I pinged the maintainer
multiple times even. imagemagick badly needs co-maintainers, the current state
is not sustainable at all. imagemagick only saw one maintainer upload in 2020...

> If I understand correctly, not having this patch in bullseye can be
> considered a security regression.

Yes, we should not revert this and rather fix fallout in the handful
of affected packages. This patch e.g. prevented the exploitability of
https://insert-script.blogspot.com/2020/11/imagemagick-shell-injection-via-pdf.html
and will prevent other issues in the future.

Cheers,
 Moritz

Bug#989438: CVE-2021-31855

[Moritz Muehlenhoff]

Source: kf5-messagelib
Severity: grave
Tags: security
X-Debbugs-Cc: Debian Security Team 

https://kde.org/info/security/advisory-20210429-1.txt

Patch:
https://commits.kde.org/messagelib/3b5b171e91ce78b966c98b1292a1bcbc8d984799

Cheers,
 Moritz

Bug#989437: CVE-2021-23165 CVE-2021-26948 CVE-2021-26259 CVE-2021-26252 CVE-2021-23206 CVE-2021-23191 CVE-2021-23180 CVE-2021-23158

[Moritz Muehlenhoff]

Package: htmldoc
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

CVE-2021-26948:
https://github.com/michaelrsweet/htmldoc/issues/410
https://github.com/michaelrsweet/htmldoc/commit/008861d8339c6ec777e487770b70b95b1ed0c1d2

CVE-2021-26259;
https://github.com/michaelrsweet/htmldoc/issues/417
https://github.com/michaelrsweet/htmldoc/commit/0ddab26a542c74770317b622e985c52430092ba5

CVE-2021-26252:
https://github.com/michaelrsweet/htmldoc/issues/412
https://github.com/michaelrsweet/htmldoc/commit/369b2ea1fd0d0537ba707f20a2f047b6afd2fbdc

CVE-2021-23206:
https://github.com/michaelrsweet/htmldoc/issues/416
https://github.com/michaelrsweet/htmldoc/commit/ba61a3ece382389ae4482c7027af8b32e8ab4cc8

CVE-2021-23191:
https://github.com/michaelrsweet/htmldoc/issues/415
https://github.com/michaelrsweet/htmldoc/commit/369b2ea1fd0d0537ba707f20a2f047b6afd2fbdc

CVE-2021-23180:
https://github.com/michaelrsweet/htmldoc/issues/418
https://github.com/michaelrsweet/htmldoc/commit/19c582fb32eac74b57e155cffbb529377a9e751a

CVE-2021-23165
https://github.com/michaelrsweet/htmldoc/issues/413
https://github.com/michaelrsweet/htmldoc/commit/369b2ea1fd0d0537ba707f20a2f047b6afd2fbdc

CVE-2021-23158
https://github.com/michaelrsweet/htmldoc/issues/414
https://github.com/michaelrsweet/htmldoc/commit/369b2ea1fd0d0537ba707f20a2f047b6afd2fbdc
Crash in CLI tool, no security impact

Cheers,
 Moritz

Bug#989436: websimba: project's website is wrong

[Berthold Humkamp]

Package: websimba
Version: 0.8.4-6
Severity: minor
X-Debbugs-Cc: timew...@network-application.de

Dear Maintainer,

the project's website isn't reachable. (for sale)

Maybe this project is dead.

Best regards,
Berthold


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

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

Versions of packages websimba depends on:
ii  apache22.4.46-4
ii  debconf [debconf-2.0]  1.5.75
ii  simba  0.8.4-6
ii  wwwconfig-common   0.3.0+nmu1

websimba recommends no packages.

websimba suggests no packages.

Bug#989431: nftables runs to early at system boot

[Friedemann Stoyan]

On  3.06.21 17:49, Arturo Borrero Gonzalez wrote:
> On 6/3/21 5:26 PM, F.Stoyan wrote:
> > 
> > nftables runs to early at system boot. At this time not all interfaces are 
> > available:
> > 
> > # journalctl -b -3 --unit=systemd-networkd.service --unit=nftables.service 
> > --no-hostname
> > -- Journal begins at Fri 2021-05-28 15:13:07 CEST, ends at Thu 2021-06-03 
> > 17:08:05 CEST. --
> > Jun 03 15:18:23 nft[414]: /etc/nftables.conf:12:21-31: Error: Interface 
> > does not exist
> > Jun 03 15:18:23 nft[414]: define SSID-MEDIA = enp1s0f0.66
> > Jun 03 15:18:23 nft[414]: ^^^
> > Jun 03 15:18:23 nft[414]: /etc/nftables.conf:11:21-31: Error: Interface 
> > does not exist
> > Jun 03 15:18:23 nft[414]: define SSID-LABOR = enp1s0f0.65
> > Jun 03 15:18:23 nft[414]: ^^^
> 
> I guess you are using interface index in your ruleset, rather than interface

Yes, indeed!

> names. If you use interface name (i.e, iffname oifname etc) then the
> interface don't need to exist when loading the ruleset.
> 
> Loading the ruleset *before* the interfaces are up ensures that no network
> traffic bypass the firewall policy.
> 
> Is up to you to configure the systemd unit to load before/after the network.

Thanks for the explanation. So everything is clear now. I think you can close
the bugreport.

Best regards
F. Stoyan

Bug#989435: simba: project website is wrong

[Berthold Humkamp]

Package: simba
Version: 0.8.4-6
Severity: minor
X-Debbugs-Cc: timew...@network-application.de

Dear Maintainer,

the project website isn't reachable any longer.

Maybe the project is dead, as I can't find any information about it.

Best regards,
Berthold


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

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

Versions of packages simba depends on:
ii  dbconfig-common 2.0.19
ii  debconf [debconf-2.0]   1.5.75
ii  libdatetime-perl2:1.54-1
ii  libhtml-template-perl   2.97-1.1
ii  liblog-dispatch-perl2.70-1
ii  liblog-log4perl-perl1.54-1
ii  libmodule-pluggable-perl5.2-1
ii  libnumber-format-perl   1.75-1.1
ii  libropkg-perl   0.4-1.3
ii  libsql-abstract-perl1.87-1
ii  libxml-rss-perl 1.62-1
ii  mariadb-client-10.5 [virtual-mysql-client]  1:10.5.10-2
ii  perl5.32.1-4

simba recommends no packages.

simba suggests no packages.

Bug#989433: tcpdump: -Z doesn't seem to work properly

[Dennis Boone]

Package: tcpdump
Version: 4.99.0-2
Severity: normal
X-Debbugs-Cc: d...@msu.edu

According to the manpage, if run as root, tcpdump switches to the
tcpdump user.  It's supposed to be possible to override this behavior
by using the "-Z root" command line option.

The following session was executed as root:

ozymandias 179 # tcpdump -r /tmp/ax0.cap -Z root
tcpdump: /tmp/ax0.cap: Permission denied
ozymandias 180 # tcpdump -r /tmp/ax0.cap -Z tcpdump
tcpdump: /tmp/ax0.cap: Permission denied
ozymandias 181 # dir /tmp/ax0.cap 
-rw-r--r-- 1 tcpdump tcpdump 434176 jun  3 11:41 /tmp/ax0.cap

Order of the "-r" and "-Z" options make no difference.

If one chown's the file root:root, then tcpdump will read it.

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

Kernel: Linux 5.10.0-7-amd64 (SMP w/20 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages tcpdump depends on:
ii  adduser 3.118
ii  libc6   2.31-12
ii  libpcap0.8  1.10.0-2
ii  libssl1.1   1.1.1k-1

tcpdump recommends no packages.

Versions of packages tcpdump suggests:
ii  apparmor  2.13.6-10

-- no debconf information

Bug#989370: closed by Chris Hofstaedtler (Re: Bug#989370: general: In bonding network configuration, hwaddress crashes networking service, fails to restart)

[Dachshund Digital]

Chris,

Please open this bug again... I have confirmed the bug exists on 
straight Debian 10 (on AMD64 Hardware).  On reboot or direct restart of 
networking, the networking is broken.  The only change between the two 
files below is first has hwaddr set under bond0, the other file that 
line is commented out.


The following interfaces file fails... Note the hwaddr line under bond0 
is enabled...


-

# cat /etc/network/interfaces

source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

auto bond0
iface bond0 inet dhcp
    hwaddress 01:02:03:04:05:06

    #address 192.168.1.71
    #netmask 255.255.255.0
    #gateway 192.168.1.1

    bond-slaves ens33 ens36
    #bond-slaves none

    bond-mode active-backup
    bond-miimon 100
    bond-downdelay 200
    bond-updelay 200

auto ens33
iface ens33 inet manual
    #00:0C:29:88:B0:32
    #Below Ignored As Expected
    hwaddr 00:00:00:00:00:33
    bond-master bond0
    bond-primary ens33
    bond-mode active-backup

auto ens36
iface ens36 inet manual
    #00:0C:29:88:B0:3C
    #Below Ignored As Expected
    hwaddr 00:00:00:00:00:36
    bond-master bond0
    bond-primary ens33
    bond-mode active-backup

-


Comment out the hwaddr line under the bond0 configuration the interface 
file works...


-

# cat /etc/network/interfaces

source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

auto bond0
iface bond0 inet dhcp
    #hwaddress 01:02:03:04:05:06

    #address 192.168.1.71
    #netmask 255.255.255.0
    #gateway 192.168.1.1

    bond-slaves ens33 ens36
    #bond-slaves none

    bond-mode active-backup
    bond-miimon 100
    bond-downdelay 200
    bond-updelay 200

auto ens33
iface ens33 inet manual
    #00:0C:29:88:B0:32
    #Below Ignored As Expected
    hwaddr 00:00:00:00:00:33
    bond-master bond0
    bond-primary ens33
    bond-mode active-backup

auto ens36
iface ens36 inet manual
    #00:0C:29:88:B0:3C
    #Below Ignored As Expected
    hwaddr 00:00:00:00:00:36
    bond-master bond0
    bond-primary ens33
    bond-mode active-backup

# ping www.google.com
PING www.google.com (142.250.188.228) 56(84) bytes of data.
64 bytes from lax31s15-in-f4.1e100.net (142.250.188.228): icmp_seq=1 
ttl=115 time=16.4 ms
64 bytes from lax31s15-in-f4.1e100.net (142.250.188.228): icmp_seq=2 
ttl=115 time=17.4 ms

^C
--- www.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 3ms
rtt min/avg/max/mdev = 16.355/16.862/17.369/0.507 ms
root@insane:~# ping -c 1 www.google.com
PING www.google.com (142.250.188.228) 56(84) bytes of data.
64 bytes from lax31s15-in-f4.1e100.net (142.250.188.228): icmp_seq=1 
ttl=115 time=15.7 ms


--- www.google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 15.737/15.737/15.737/0.000 ms

-

Debian 10 Information...

# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;

# uname -a
Linux insane 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) 
x86_64 GNU/Linux


-

Thanks,

-DD


On 6/3/2021 04:42, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the general package:

#989370: general: In bonding network configuration, hwaddress crashes 
networking service, fails to restart

It has been closed by Chris Hofstaedtler .

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Chris Hofstaedtler 
 by
replying to this email.

Bug#989061: Update protobuf to new upstream 3.15.5 or later

[GCS]

On Sat, May 29, 2021 at 8:34 PM Pirate Praveen  wrote:
> Thanks, I have built it here
> https://people.debian.org/~praveen/devel/pool/main/p/protobuf/
 I see. Then just for the record, I further updated the protobuf package[1].

Regards,
Laszlo/GCS
[1] dget -x https://people.debian.org/~gcs/protobuf_3.17.2-1.dsc

Bug#989432: extlinux writes ldlinux.c32 and ldlinux.sys in multiple fragments

[Josh Triplett]

Package: extlinux
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

On a freshly created and nearly empty filesystem, after extlinux
--install creates ldlinux.c32 and ldlinux.sys, they're both fragmented:

$ filefrag ldlinux.*
ldlinux.c32: 3 extents found
ldlinux.sys: 2 extents found

extlinux could avoid this in several different ways, most easily by
reserving enough space for the file up-front using ftruncate.

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

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

Versions of packages extlinux depends on:
ii  libc6  2.31-12

Versions of packages extlinux recommends:
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3

extlinux suggests no packages.

-- no debconf information

Bug#989431: nftables runs to early at system boot

[Arturo Borrero Gonzalez]

On 6/3/21 5:26 PM, F.Stoyan wrote:


nftables runs to early at system boot. At this time not all interfaces are 
available:

# journalctl -b -3 --unit=systemd-networkd.service --unit=nftables.service 
--no-hostname
-- Journal begins at Fri 2021-05-28 15:13:07 CEST, ends at Thu 2021-06-03 
17:08:05 CEST. --
Jun 03 15:18:23 nft[414]: /etc/nftables.conf:12:21-31: Error: Interface does 
not exist
Jun 03 15:18:23 nft[414]: define SSID-MEDIA = enp1s0f0.66
Jun 03 15:18:23 nft[414]: ^^^
Jun 03 15:18:23 nft[414]: /etc/nftables.conf:11:21-31: Error: Interface does 
not exist
Jun 03 15:18:23 nft[414]: define SSID-LABOR = enp1s0f0.65
Jun 03 15:18:23 nft[414]: ^^^


I guess you are using interface index in your ruleset, rather than interface 
names. If you use interface name (i.e, iffname oifname etc) then the interface 
don't need to exist when loading the ruleset.


Loading the ruleset *before* the interfaces are up ensures that no network 
traffic bypass the firewall policy.


Is up to you to configure the systemd unit to load before/after the network.

Bug#989431: nftables runs to early at system boot

[F.Stoyan]

Package: nftables
Version: 0.9.8-3
Severity: normal
Tags: patch

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

nftables runs to early at system boot. At this time not all interfaces are 
available:

# journalctl -b -3 --unit=systemd-networkd.service --unit=nftables.service 
--no-hostname
-- Journal begins at Fri 2021-05-28 15:13:07 CEST, ends at Thu 2021-06-03 
17:08:05 CEST. --
Jun 03 15:18:23 nft[414]: /etc/nftables.conf:12:21-31: Error: Interface does 
not exist
Jun 03 15:18:23 nft[414]: define SSID-MEDIA = enp1s0f0.66
Jun 03 15:18:23 nft[414]: ^^^
Jun 03 15:18:23 nft[414]: /etc/nftables.conf:11:21-31: Error: Interface does 
not exist
Jun 03 15:18:23 nft[414]: define SSID-LABOR = enp1s0f0.65
Jun 03 15:18:23 nft[414]: ^^^
Jun 03 15:18:23 systemd-networkd[440]: Enumeration completed
Jun 03 15:18:23 systemd[1]: Started Network Service.
Jun 03 15:18:23 systemd-networkd[440]: enp1s0f0.66: netdev ready
Jun 03 15:18:23 systemd-networkd[440]: enp1s0f0.64: netdev ready
Jun 03 15:18:23 systemd-networkd[440]: enp1s0f0.32: netdev ready
Jun 03 15:18:23 systemd-networkd[440]: enp1s0f0.34: netdev ready
Jun 03 15:18:23 systemd-networkd[440]: enp1s0f0.65: netdev ready
Jun 03 15:18:23 systemd-networkd[440]: enp1s0f0.33: netdev ready
Jun 03 15:18:23 systemd-networkd[440]: enp1s0f0.35: netdev ready
Jun 03 15:18:23 systemd-networkd[440]: enp1s0f0.36: netdev ready
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0: Link UP
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.32: Link UP
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.33: Link UP
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.34: Link UP
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.35: Link UP
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.36: Link UP
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.64: Link UP
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.65: Link UP
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.66: Link UP
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0: Gained carrier
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.32: Gained carrier
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.33: Gained carrier
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.34: Gained carrier
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.35: Gained carrier
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.36: Gained carrier
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.64: Gained carrier
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.65: Gained carrier
Jun 03 15:18:24 systemd-networkd[440]: enp1s0f0.66: Gained carrier
Jun 03 15:18:26 systemd-networkd[440]: enp1s0f0.36: Gained IPv6LL
Jun 03 15:18:26 systemd-networkd[440]: enp1s0f0.66: Gained IPv6LL
Jun 03 15:18:26 systemd-networkd[440]: enp1s0f0.65: Gained IPv6LL
Jun 03 15:18:26 systemd-networkd[440]: enp1s0f0.35: Gained IPv6LL
Jun 03 15:18:26 systemd-networkd[440]: enp1s0f0: Gained IPv6LL
Jun 03 15:18:26 systemd-networkd[440]: enp1s0f0.33: Gained IPv6LL
Jun 03 15:18:26 systemd-networkd[440]: enp1s0f0.64: Gained IPv6LL
Jun 03 15:18:26 systemd-networkd[440]: enp1s0f0.32: Gained IPv6LL
Jun 03 15:18:26 systemd-networkd[440]: enp1s0f0.34: Gained IPv6LL

Running nftables after network-target solves the issue:

# journalctl -b --unit=systemd-networkd.service --unit=nftables.service 
--no-hostname
-- Journal begins at Fri 2021-05-28 15:13:07 CEST, ends at Thu 2021-06-03 
17:17:01 CEST. --
Jun 03 16:22:36 systemd-networkd[435]: Enumeration completed
Jun 03 16:22:36 systemd[1]: Started Network Service.
Jun 03 16:22:36 systemd[1]: Starting nftables...
Jun 03 16:22:36 systemd-networkd[435]: enp1s0f0.36: netdev ready
Jun 03 16:22:36 systemd-networkd[435]: enp1s0f0.66: netdev ready
Jun 03 16:22:36 systemd-networkd[435]: enp1s0f0.32: netdev ready
Jun 03 16:22:36 systemd-networkd[435]: enp1s0f0.34: netdev ready
Jun 03 16:22:36 systemd-networkd[435]: enp1s0f0.64: netdev ready
Jun 03 16:22:36 systemd-networkd[435]: enp1s0f0.65: netdev ready
Jun 03 16:22:36 systemd-networkd[435]: enp1s0f0.33: netdev ready
Jun 03 16:22:37 systemd-networkd[435]: enp1s0f0.35: netdev ready
Jun 03 16:22:37 systemd-networkd[435]: enp1s0f0: Link UP
Jun 03 16:22:37 systemd-networkd[435]: enp1s0f0.32: Link UP
Jun 03 16:22:37 systemd-networkd[435]: enp1s0f0.33: Link UP
Jun 03 16:22:37 systemd-networkd[435]: enp1s0f0.34: Link UP
Jun 03 16:22:37 systemd-networkd[435]: enp1s0f0.35: Link UP
Jun 03 16:22:37 systemd-networkd[435]: enp1s0f0.36: Link UP
Jun 03 16:22:37 systemd-networkd[435]: enp1s0f0.64: Link UP
Jun 03 16:22:37 systemd-networkd[435]: enp1s0f0.65: Link UP
Jun 03 16:22:37 systemd-networkd[435]: enp1s0f0.66: Link UP
Jun 03 16:22:37 systemd-networkd[435]: enp1s0f0: Gained carrier
Jun 03 

Bug#989430: urxvt-config-reload perl plugin stops working after 19_sigsegv_perl_environ.diff

[Ryan Kavanagh]

Package: rxvt-unicode
Version: 9.22-11
Severity: normal

According to a user in #rxvt-unicode, the perl plugin
https://github.com/regnarg/urxvt-config-reload no longer works in 9.25. They
bisected the issue and the first bad commit is
https://github.com/exg/rxvt-unicode/commit/7e804cd0f4edd5f2f60f39d8baf4f872b6d63756
which we applied as 19_sigsegv_perl_environ.diff. Reverting the change makes
the plugin work again. They filed a bug report with the plugin author:
https://github.com/regnarg/urxvt-config-reload/issues/20

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

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

Versions of packages rxvt-unicode depends on:
ii  base-passwd   3.5.50
ii  libc6 2.31-12
ii  libfontconfig12.13.1-4.2
ii  libgcc-s1 10.2.1-6
ii  libgdk-pixbuf-2.0-0   2.42.2+dfsg-1
ii  libglib2.0-0  2.66.8-1
ii  libperl5.32   5.32.1-4
ii  libstartup-notification0  0.12-6+b1
ii  libx11-6  2:1.7.1-1
ii  libxft2   2.3.2-2
ii  libxrender1   1:0.9.10-1
ii  ncurses-base  6.2+20201114-2
ii  ncurses-term  6.2+20201114-2

Versions of packages rxvt-unicode recommends:
ii  fonts-dejavu2.37-2
ii  fonts-vlgothic [fonts-japanese-gothic]  20200720-1

Versions of packages rxvt-unicode suggests:
ii  sensible-utils  0.0.14

-- no debconf information

-- 
|)|/  Ryan Kavanagh  | GPG: 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac |  BD95 8F7B F8FC 4A11 C97A

Bug#974678: ITP: openh264 -- H.264 encoding and decoding

[Sam Hartman]

> "Bastian" == Bastian Germann  writes:

Bastian> There are H.264 patents that are applicable. I do not know
Bastian> how the existing H.264 implementations in Debian handle
Bastian> this, e.g. x264 or ffmpeg. According to the legal FAQ,
Bastian> these seem to be ignored.

I suspect you meant to say that there are H.264 patents that may be
applicable and that Debian should evaluate this risk using its normal
proocesses and policies for looking at software patents.

THOSE PROCESSES DO NOT INVOLVE debian-legal.  Discussing patents in a
public forum may result in speculative communication--like the assertion
above where you said that patents are applicable and where you probably
meant to say that the patents may be applicable--being produced in
response to allegations of patent infringement.
That harms Debian.
Thus, we have a policy that we discuss patents only in privileged
communication.
See https://www.debian.org/legal/patent


and if you are concerned about a specific patent risk, write to
pate...@debian.org.


signature.asc
Description: PGP signature

Bug#989429: policykit-1: CVE-2021-3560: local privilege escalation using polkit_system_bus_name_get_creds_sync()

[Salvatore Bonaccorso]

Control: tags -1 + patch

On Thu, Jun 03, 2021 at 03:49:02PM +0200, Salvatore Bonaccorso wrote:
> Source: policykit-1
> Version: 0.105-30
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> Forwarded: https://gitlab.freedesktop.org/polkit/polkit/-/issues/140
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> Control: found -1 0.105-26
> 
> Hi,
> 
> The following vulnerability was published for policykit-1.
> 
> CVE-2021-3560[0]:
> | local privilege escalation using
> | polkit_system_bus_name_get_creds_sync()
> 
> The issue was introduced upstream with [2] in 0.113 but the
> introducing change is in Debian as well (and Ubuntu[3]).
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2021-3560
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3560
> [1] https://gitlab.freedesktop.org/polkit/polkit/-/issues/140
> [2] 
> https://gitlab.freedesktop.org/polkit/polkit/-/commit/bfa5036bfb93582c5a87c44b847957479d911e38
> [3] https://ubuntu.com/security/notices/USN-4980-1
> [4] https://bugzilla.redhat.com/show_bug.cgi?id=1961710
> 
> Can you fix this targetted please for bullseye and ask the release
> team for an unblock?

Attached the patch.

Regards,
Salvatore
--- a/src/polkit/polkitsystembusname.c
+++ b/src/polkit/polkitsystembusname.c
@@ -435,6 +435,9 @@ polkit_system_bus_name_get_creds_sync (PolkitSystemBusName   *system_bus
   while (!((data.retrieved_uid && data.retrieved_pid) || data.caught_error))
 g_main_context_iteration (tmp_context, TRUE);
 
+  if (data.caught_error)
+goto out;
+
   if (out_uid)
 *out_uid = data.uid;
   if (out_pid)

Bug#989429: policykit-1: CVE-2021-3560: local privilege escalation using polkit_system_bus_name_get_creds_sync()

[Salvatore Bonaccorso]

Source: policykit-1
Version: 0.105-30
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://gitlab.freedesktop.org/polkit/polkit/-/issues/140
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.105-26

Hi,

The following vulnerability was published for policykit-1.

CVE-2021-3560[0]:
| local privilege escalation using
| polkit_system_bus_name_get_creds_sync()

The issue was introduced upstream with [2] in 0.113 but the
introducing change is in Debian as well (and Ubuntu[3]).

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-3560
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3560
[1] https://gitlab.freedesktop.org/polkit/polkit/-/issues/140
[2] 
https://gitlab.freedesktop.org/polkit/polkit/-/commit/bfa5036bfb93582c5a87c44b847957479d911e38
[3] https://ubuntu.com/security/notices/USN-4980-1
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1961710

Can you fix this targetted please for bullseye and ask the release
team for an unblock?

Regards,
Salvatore

Bug#989428: libx265-dev: pygdal does not like to the right version

[ldng]

Package: libx265-dev
Version: 3.4-2
Severity: normal
X-Debbugs-Cc: l...@free.fr

Dear Maintainer,

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

   * What led up to the situation?

When installing pygdal in a python 3.6 virtualenv on debian 11 (bullseye) and
try to import it, it generates the following error :
OSError: libx265.so.165: cannot open shared object file: No such file or
directory

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

$ pyenv --version
pyenv 2.0.0

It's used to create a Python 3.6 virtualenv

pip --version
pip 21.1.2 from /home/$foo/.pyenv/versions/3.6.13/envs/$bar/lib/python3.6/site-
packages/pip (python 3.6)

When cloning the pygdal repo and compiling in the version 3.2.1 matching the
installed version, with python setup.py bdist_wheel, it seems to link to an
unexisting library :

$ ldd build/lib.linux-x86_64-3.6/osgeo/_gdal.cpython-36m-x86_64-linux-gnu.so
...
libde265.so.0 => /usr/lib/x86_64-linux-gnu/libde265.so.0
(0x7fe1a8d39000)
libx265.so.165 => not found
libdav1d.so.4 => /usr/lib/x86_64-linux-gnu/libdav1d.so.4
(0x7fe1a8c03000)
...

The library available is : /usr/lib/x86_64-linux-gnu/libx265.so.192

Could be a pygdal issue though.



-- 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-6-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 libx265-dev depends on:
ii  libx265-192  3.4-2

libx265-dev recommends no packages.

Versions of packages libx265-dev suggests:
pn  libx265-doc  

Bug#989310: partx: /dev/$VG/$LV: adding partition #4 failed: Invalid argument

[Thorsten Glaser]

Hi Chris,

>Right. Thanks for the report, however could I ask you to directly
>report this to upstream? I don't think this is a Debian peculiarity
>and I cannot think of anything useful that I could add to an
>upstream bug report.

could you please do that? I have no relationship with upstream and
no desire to register in just another bugtracker, and I’m not even
sure which component is even part of the problem.

Thanks,
//mirabilos
-- 
DevRef 3.1.4.

Bug#986399: sgf2dg: The sgf2dg program fails to start on bullseye

[John Green]

An update.  The problem was solved by purging (apt-get purge sgf2dg) and
reinstalling the package.
There must have been something bad in my installation.  I do not know what
that was because
I have not consciously changed or played with any components of sgf2dg.

The lesson is to try a purge and reinstall before making another bug report.

Thanks,

John Green.

On Mon, 05 Apr 2021 09:10:59 +0100 John Green  wrote:
> Package: sgf2dg
> Version: 4.252-1
> Severity: important
> X-Debbugs-Cc: gree...@hotmail.com
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where
appropriate ***
>
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
> The sgf2dg program fails to start. It reports an error message that
> begins as follows.
>
> Can't locate Games/Go/Diagram.pm in @INC (you may need to install the
Games::Go::Diagram module)
>
> The error message ends as follows.
>
> BEGIN failed--compilation aborted at /usr/bin/sgf2dg line 53.
>
> This issue did not occur on Debian 10.  I do not know perl, so cannot
> investigate or fix the problem myself.
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing-security
>   APT policy: (500, 'testing-security'), (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.27 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages sgf2dg depends on:
> ii  libc6  2.31-11
> ii  perl   5.32.1-3
>
> Versions of packages sgf2dg recommends:
> ii  libpdf-create-perl   1.46-1
> ii  libpostscript-file-perl  2.23+dfsg-1
>
> sgf2dg suggests no packages.
>
> -- no debconf information
>
>

Bug#989427: unblock:jverein/2.8.18+git20200921.6212a59+dfsg-7

[Mechtilde Stehmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-java-maintainers%40lists.alioth.debian.org

Please unblock
jverein (2.8.18+git20200921.6212a59+dfsg-7)

It fixed #988929

Piuparts tests are ok now
this package can be built reproducible.

There are no more packages depending on jverein
There are no packages which conflict.

Thanks in advance

Mechtilde

-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F
diff -Nru jverein-2.8.18+git20200921.6212a59+dfsg/debian/changelog jverein-2.8.18+git20200921.6212a59+dfsg/debian/changelog
--- jverein-2.8.18+git20200921.6212a59+dfsg/debian/changelog	2020-11-15 21:02:11.0 +0100
+++ jverein-2.8.18+git20200921.6212a59+dfsg/debian/changelog	2021-05-31 21:11:16.0 +0200
@@ -1,3 +1,37 @@
+jverein (2.8.18+git20200921.6212a59+dfsg-7) unstable; urgency=medium
+
+  * [898b6cb] Added runtime dependency libmail-java 
+  it doesn't come with ${misc}Depends (Closes: 988929)
+  so the link should work
+
+ -- Mechtilde Stehmann   Mon, 31 May 2021 21:11:16 
+0200
+
+jverein (2.8.18+git20200921.6212a59+dfsg-6) unstable; urgency=medium
+
+  * [0fb9fe3] Bumped standard version in d/control
+  * [e5cd2c7] Removed unused links. Added link to /usr/bin (Closes: 988929)
+  * [f9b1f92] Improved path to icon in d/j*.install
+  * [5efad9c] Improved name of executable
+  * [ad9a0ec] Improved  d/j*.lintian-overrides
+  * [1df7f13] Added required manpage
+
+ -- Mechtilde Stehmann   Sun, 23 May 2021 09:18:27 
+0200
+
+jverein (2.8.18+git20200921.6212a59+dfsg-5) unstable; urgency=medium
+
+  * source upload only
+
+ -- Mechtilde Stehmann   Sun, 25 Apr 2021 07:52:28 
+0200
+
+jverein (2.8.18+git20200921.6212a59+dfsg-4) unstable; urgency=medium
+
+  [ Mechtilde ]
+  * [d86a379] Improved README.md  Thanks Bernhard Reiter
+  * [f816baf] Added content of the Merge Request - thanks Bernhard Reiter
+  * [4ebf81f] Changed path to jameica and hibiscus to be reproducible at 
buildd
+
+ -- Mechtilde Stehmann   Sat, 24 Apr 2021 11:41:42 
+0200
+
 jverein (2.8.18+git20200921.6212a59+dfsg-3) unstable; urgency=medium
 
   * [b7a57da] Added another part to patch file
diff -Nru jverein-2.8.18+git20200921.6212a59+dfsg/debian/control jverein-2.8.18+git20200921.6212a59+dfsg/debian/control
--- jverein-2.8.18+git20200921.6212a59+dfsg/debian/control	2020-11-14 16:55:35.0 +0100
+++ jverein-2.8.18+git20200921.6212a59+dfsg/debian/control	2021-05-31 20:48:50.0 +0200
@@ -30,7 +30,7 @@
  , libyaml-snake-java
  , libzxing-core-java
  , libzxing-javase-java
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
 Rules-Requires-Root: no
 Vcs-Git: https://salsa.debian.org/java-team/jverein.git/
 Vcs-Browser: https://salsa.debian.org/java-team/jverein
@@ -44,6 +44,7 @@
 , hibiscus
 , libhbci4j-core-java
 , libitext5-java
+, libmail-java
 , libobantoo-java
 , libsuper-csv-java
 , libswtchart-java
diff -Nru jverein-2.8.18+git20200921.6212a59+dfsg/debian/jverein.1 jverein-2.8.18+git20200921.6212a59+dfsg/debian/jverein.1
--- jverein-2.8.18+git20200921.6212a59+dfsg/debian/jverein.1	1970-01-01 01:00:00.0 +0100
+++ jverein-2.8.18+git20200921.6212a59+dfsg/debian/jverein.1	2021-05-22 19:01:12.0 +0200
@@ -0,0 +1,18 @@
+.TH JVEREIN 1 "MAY 22, 2021"
+.\" Please adjust this date whenever revising the manpage.
+.SH NAME
+jverein \- Tool to administrate an association
+.SH SYNOPSIS
+.B jverein
+.SH DESCRIPTION
+jverein is an open source association administration with a connection
+to the homebanking software Hibiscus, which is also under open source
+license. The implementation is done with Java. The procedure
+thus guaranteed on many platforms. Jameica is used as the GUI framework
+for this plugin.
+
+.SH AUTHOR
+jverein was written by Heiner Jostkleigrewe heiner(at)jost-net.de
+.PP
+This manual page was written by Mechtilde Stehmann ,
+for the Debian project (but may be used by others).
diff -Nru jverein-2.8.18+git20200921.6212a59+dfsg/debian/jverein.desktop jverein-2.8.18+git20200921.6212a59+dfsg/debian/jverein.desktop
--- jverein-2.8.18+git20200921.6212a59+dfsg/debian/jverein.desktop	2020-11-14 17:18:57.0 +0100
+++ jverein-2.8.18+git20200921.6212a59+dfsg/debian/jverein.desktop	2021-05-22 18:07:08.0 +0200
@@ -8,8 +8,8 @@
 Comment=Administration of an Association
 Comment[de]=Vereinssoftware
 
-Exec=jameica
-Icon=jverein-icon
+Exec=jverein
+Icon=jverein-icon.png
 Terminal=false
 Type=Application
 Categories=Office
diff -Nru jverein-2.8.18+git20200921.6212a59+dfsg/debian/jverein.install jverein-2.8.18+git20200921.6212a59+dfsg/debian/jverein.install
--- jverein-2.8.18+git20200921.6212a59+dfsg/debian/jverein.install	2020-11-14 18:50:46.0 +0100
+++ jverein-2.8.18+git20200921.6212a59+dfsg/debian/jverein.install	2021-05-22 21:23:21.0 +0200
@@ -1,4 +1,4 @@
 releases/jverein	

Bug#989399: nauty FTCBFS -- multiple reasons

[Andrius Merkys]

Hi Nilesh,

On 2021-06-03 13:05, Nilesh Patra wrote:
> On Thu, 3 Jun 2021 at 13:10, Andrius Merkys  > wrote:
> On 2021-06-02 19:29, Nilesh Patra wrote:
> > Nauty fails to cross build due to two reasons:
> >
> > 1. It uses AC_RUN_IFELSE testing which cannot heppen during cross
> build
> >    Simply replacing it by AC_LINK_IFELSE does the trick. Please
> find the
> >    patch for this below, and consider applying
> 
> I have no experience with this, alas.
> 
> This patch that I suggested is actually wrong, as you might see in
> Helmut's message.
> But more importantly, we ended up discovering that this is a *Release
> critical*  bug instead.
> Please consider fixing it ASAP if you have some free cycles.

I am aware of Helmut's response and the severity of the problem.
However, I have no experience with fixing i386 baseline violation. I may
give a look, but I am not sure anything will come out of that.

> Indeed, help2man should not call the compiled executables. Nevertheless
> it may still be used to produce manpages from static text, see [2] for
> example.
> 
> This looks nice, there is also ronn and node-marked-man which can do
> similar stuff via README.

I was not aware of ronn and node-marked-man - thanks, I will give them a
look.

> But doing so isn't always possible because several times we have
> multiple binaries and we need separate manual page for each binary.
> In such a case, we need to maintain a maintainer manpage

True indeed.

> [2]
> 
> https://salsa.debian.org/debian/libemf2svg/-/blob/df56bd1149cf512b6a232052437d04310bd90982/debian/rules#L11
> 
> 

Best,
Andrius

Bug#989245: python3-django needs to depends on libjs-jquery, not only recommend this package

[Chris Lamb]

Hi Carsten,

> I'd say there is a gap which is difficult to handle in the end by only
> pointing and strictly using our more technically packaging policy in
> contrary to make the system much as possible user friendly. But o.k., I
> see your point and will respect the decision of the package maintainers.

Firstly, I totally understand this sentiment. Whilst the close
adherence to rules across a large distribution is a net welfare for
all manner of reasons I won't belabour here, it would be a cliche
to remark that there will always be scenarios where they should not
apply. Indeed, I am sure you could fill a handsome book with famous
quotes to this effect.

> > This is all to say that given that your custom patchy2 package calls
> > collectstatic during its own package configuration stage, would it not
> > make more sense to specify libjs-query as a Depends on your package
> > instead?
>
> Our application has no dependency on libjs-jquery so adding a direct
> dependency to this package wouldn't be the correct thing to me.

However, I don't believe this statement is entirely accurate. Your
application calls "collectstatic" during it's postinst script in order
to collate all of the assets for a kind of "web runtime", so in a
certain sense then, your package *does* have a dependency on
libjs-jquery that none of the Django-related packages in Debian has --
at the very least, none of them call "collectstatic". It us thus your
package thus warrants the Depends-level relation, not any of the
others. (Or alternatively, as you write, through your configuration
management system.)  I would gladly concede that this is a subjective
judgement coached in technical language.

Anyway, thanks for your reply and for closing the bug. And, circling
back to my remarks above about not being overly wedded to rules, I am
very happy to re-explore this in the future if it comes up repeatedly
for others.


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#988820: libddsc-doc: broken symlinks: /usr/share/doc/libddsc-dev/html/_static/*.js -> ../../../../../javascript/sphinxdoc/1.0/*.js

[Timo Röhling]

Control: tags -1 + pending

* Andreas Beckmann  [2021-05-19 22:42]:

This looks like a superfluous '../' in the targets.

I looks like dh_sphinxdoc got confused because there are two sphinx
builds (main doc and example doc) in the package, and I symlinked
the _static folder of one to the other.

Running dh_sphinxdoc first and symlinking _static afterwards fixes the issue:

https://salsa.debian.org/roehling/cyclonedds/-/commit/07abf460e36b714c5d57264bcc799898a7165e56

Cheers
Timo


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


signature.asc
Description: PGP signature

Bug#989426: unblock: python-django/2:2.2.24-1

[Chris Lamb]

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

Dear Release Team,

Please consider unblocking python-django 2:2.2.24-1. It actually
constitutes two versions, the first addressing security releases which
should be uncontroversial and the second (2:2.2.23-1) fixes a
regression from the previous version. Quoting from the debdiff (which
can be found attached):

   * Fixed a regression in Django 2.2.21 where saving ``FileField`` would raise 
a
 ``SuspiciousFileOperation`` even when a custom
 :attr:`~django.db.models.FileField.upload_to` returns a valid file path
 (:ticket:`32718`).

This unblock would also incorporate a minor upstream change to the
documentation that points to Libera.chat over Freenode for the
project's IRC channel.

  python-django (2:2.2.24-1) unstable; urgency=medium

* New upstream security release. (Closes: #989394)

  - CVE-2021-33203: Potential directory traversal via admindocs

Staff members could use the admindocs TemplateDetailView view to
check the existence of arbitrary files. Additionally, if (and only
if) the default admindocs templates have been customized by the
developers to also expose the file contents, then not only the
existence but also the file contents would have been exposed.

As a mitigation, path sanitation is now applied and only files
within the template root directories can be loaded.

This issue has low severity, according to the Django security
policy.

Thanks to Rasmus Lerchedahl Petersen and Rasmus Wriedt Larsen from
the CodeQL Python team for the report.

  - CVE-2021-33571: Possible indeterminate SSRF, RFI, and LFI attacks
since validators accepted leading zeros in IPv4 addresses

URLValidator, validate_ipv4_address(), and
validate_ipv46_address() didn't prohibit leading zeros in octal
literals. If you used such values you could suffer from
indeterminate SSRF, RFI, and LFI attacks.

validate_ipv4_address() and validate_ipv46_address() validators
were not affected on Python 3.9.5+.

This issue has medium severity, according to the Django security
policy.

   -- Chris Lamb   Wed, 02 Jun 2021 16:15:13 +0100


  python-django (2:2.2.23-1) unstable; urgency=medium

* New upstream release.
  

   -- Chris Lamb   Thu, 13 May 2021 10:41:04 +0100


As mentioned above, the full debdiff is attached.


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

debdiff
Description: Binary data

Bug#989425: unblock: libpam-chroot/0.9-5

[Javier Fernández-Sanguino Peña]

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

Please unblock package libpam-chroot

[ Reason ]
This version includes fixes to build properly the package including:
- Installing the PAM module in the correct location (#980047)
- Supporting cross bulding of source (949080)
- Document that libpam-chroot is not recommended to be used with OpenSSH as it
  is difficult to setup and there are better alternatives (527564)

[ Impact ]
Users cannot use the package as it is as the pam_chroot library is not
installed in the correct location.

Users trying to follow the instructions in the README file to setup OpenSSH
will end up with a non-working setup.

If the unblock is not granted this is not, however, a major issue as not many
users use this package and chroot functionalities are, in general, not that
much used anymore as people have in general now moved to containers.

[ Tests ]
Tested locally in the developer's machine.

[ Risks ]
Very low risk changes introduced in the package.

[ 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 libpam-chroot/0.9-5


Thank you for your support,

Javier
diff -u libpam-chroot-0.9/Makefile libpam-chroot-0.9/Makefile
--- libpam-chroot-0.9/Makefile
+++ libpam-chroot-0.9/Makefile
@@ -5,6 +5,8 @@
 CPPFLAGS=-I.
 LDFLAGS=-shared
 DESTDIR=/
+LIBDIR=$(DESTDIR)/lib/security
+INSTALL?=install
 
 OUT=pam_chroot.so
 CONF=chroot.conf
@@ -20,3 +22,3 @@
 install:
-   install -s -o0 -g0 -m755 $(OUT) $(DESTDIR)/lib/security
+   $(INSTALL) -s -o0 -g0 -m755 $(OUT) $(LIBDIR)
install -m640 $(CONF) $(DESTDIR)/etc/security
diff -u libpam-chroot-0.9/debian/README.Debian 
libpam-chroot-0.9/debian/README.Debian
--- libpam-chroot-0.9/debian/README.Debian
+++ libpam-chroot-0.9/debian/README.Debian
@@ -73,15 +73,22 @@
 Setting up OpenSSH with libpam-chroot
 -
 
+!!! WARNING !!
 NOTE: OpenSSH supports, since the 4.9 release, the definition of
 chrooted enviroments. For more information see the 'ChrootDirectory'
-directive in sshd_config (5).
+directive in sshd_config (5). 
+
+Setting up OpenSSH libpam-chroot is *not* recommended and most likely will not
+work. The following information is provided for those users that want to tinker
+with pam-chroot and SSH.
+
+ WARNING !!
 
 
 Many systems want to setup a restricted remote access to a system in
 which users are confined to their user directories, but are unable to
-"see" the whole system. If you want to develop this using OpenSSH you
-will need to:
+"see" the whole system. If you want to develop this using OpenSSH 
+and libpam-chroot you will need to:
 
 0) Setup a chroot environment for your users. Make sure that
 environment includes the standard tools they will need (like their
@@ -147,7 +154,29 @@
 pam-chroot at all.
 
+4) In order for chroots to work with newer OpenSSH versions the chroot
+directory of a user needs to include both the /proc filesystem and
+the /dev/pts
+
+- If /proc is not mounted in the chroot, SSH access will be interrupted
+  with the message:
+
+  Connection reset by peer
+  Connection to  closed.
+
+  To mount /proc do the following:
+  mount -t proc /proc /proc
+
+- If /dev/pts is not mounted, the SSH login will freeze after
+  authentication with the message:
+
+ PTY allocation request failed on channel 0
+
+  To mount /dev do the following:
+  mount --rbind /dev /dev
+
+
  --
  Javier Fernandez-Sanguino 
- Wed, 27 Oct 2010 02:01:26 +0200
+ Thu, 03 Jun 2021 13:26:58 +0200
 
 
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,19 @@
+libpam-chroot (0.9-5) unstable; urgency=high
+
+  * debian/rules: Install the PAM module in the right location 
+(Closes: #980047)
+  * Fix FTCBFS: (Closes: #949080, #437385)
++ Let dh_auto_build pass cross tools to make.
++ Make install substitutable.
++ Pass a non-stripping install to make install.
+Thanks Helmut Grohne for the patch
+  * debian/README.Debian: discourage users from using this module with
+OpenSSH as this feature is available already in the daemon (see option
+ChrootDirectory) and the setup might not work due to changes in OpenSSH
+(Closes: #527564)
+
+ -- Javier Fernandez-Sanguino Pen~a   Thu, 03 Jun 2021 
12:57:43 +0200
+
 libpam-chroot (0.9-4.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u libpam-chroot-0.9/debian/dirs libpam-chroot-0.9/debian/dirs
--- libpam-chroot-0.9/debian/dirs
+++ libpam-chroot-0.9/debian/dirs
@@ -1,2 +1 @@
 etc/security
-lib/security
diff -u libpam-chroot-0.9/debian/rules 

Bug#934349: (no subject)

[Sam Pinkus]

  
  
This is fixed on latest upstream master. As yet, there is no tagged
version that includes the fix for this however. 


-- 
  PGP:
0xA53455C1

  

Bug#989274: Sway PR

[Daniel Eklof]

Sway PR to restore SIGPIPE: https://github.com/swaywm/sway/pull/6306

Bug#989424: RFS: radsecproxy/1.8.2-4~bpo10+1 -- RADIUS protocol proxy supporting RadSec

[Sven Hartge]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: radsecproxy
   Version : 1.8.2-4~bpo10+1
   Upstream Author : Fabian Mauchle 
 * URL : https://radsecproxy.github.io/
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/debian/radsecproxy
   Section : net

It builds those binary packages:

  radsecproxy - RADIUS protocol proxy supporting RadSec

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/r/radsecproxy/radsecproxy_1.8.2-4~bpo10+1.dsc


Changes since the last upload:

 radsecproxy (1.8.2-4~bpo10+1) buster-backports; urgency=medium
 .
   * Rebuild for buster-backports.

Grüße,
Sven!



OpenPGP_signature
Description: OpenPGP digital signature

Bug#869247: (no subject)

[Sam Pinkus]

  
  
This is expected behavior. rsnapshot man page:


   cmd_preexec
  
     Full path (plus any arguments) to preexec script
  (optional).  This script will run immediately before each backup
  operation (but not any rotations). If the
     execution fails, rsnapshot will stop immediately.
  
     cmd_postexec
  
     Full path (plus any arguments) to postexec script
  (optional).  This script will run immediately after each backup
  operation (but not any rotations). If the
     execution fails, rsnapshot will stop immediately.


Thanks,

Sam.

-- 
  PGP:
0xA53455C1

  

Bug#986637: Advertisement Require https://planet.ubuntu.com/

[Katie Maya]

Hello,

I am a professional blogger outreach service provider. I have several
clients and their running orders. https://planet.ubuntu.com/

I am working for my several clients & outreach to get them quality guest
post links.


I would like to have your website list where you can provide guest posts
with a do-follow link to my client website. *Please let me know your
charges & TAT.*

Now I will be waiting for your positive reply.

Bug#989423: anki: Anki not displaying any decks after clicking "Study Now"

[Jack Thomson]

Package: anki
Version: 2.1.15+dfsg-3
Severity: important

Dear Maintainer,

   * What led up to the situation?
   - I installed anki via apt, and neither creating decks nor importing
 decks seems to work. The terminal constantly prints:

 "JS error on line 1: Uncaught ReferenceError: $ is not defined
  JS error on line 34: Uncaught ReferenceError: $ is not defined
  JS error on line 99: Uncaught ReferenceError: $ is not defined
  JS error on line 109: Uncaught ReferenceError: $ is not defined"

All the menus, seem to function well enough. I'm not too educated on
the matter, but could it be something to do with Wayland?

   * What outcome did you expect instead?

   I expected to be able to see the deck! It seems like it's not
   rendering at all.


-- 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-6-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages anki depends on:
ii  libjs-jquery3.5.1+dfsg+~3.5.5-7
ii  libjs-jquery-flot   4.2.1+dfsg-5
ii  libjs-jquery-ui 1.12.1+dfsg-8
ii  libjs-mathjax   2.7.9+dfsg-1
ii  libqt5core5a5.15.2+dfsg-5
ii  python3 3.9.2-3
ii  python3-bs4 4.9.3-1
ii  python3-decorator   4.4.2-2
ii  python3-distro  1.5.0-1
ii  python3-distutils   3.9.2-1
ii  python3-jsonschema  3.2.0-3
ii  python3-markdown3.3.4-1
ii  python3-pyaudio 0.2.11-1.3+b1
ii  python3-pyqt5   5.15.2+dfsg-3
ii  python3-pyqt5.qtwebchannel  5.15.2+dfsg-3
ii  python3-pyqt5.qtwebengine   5.15.2-2
ii  python3-requests2.25.1+dfsg-2
ii  python3-send2trash  1.6.0~b1+git20210122.2eb3242-1

Versions of packages anki recommends:
ii  python3-matplotlib  3.3.4-1

Versions of packages anki suggests:
pn  dvipng   
ii  lame 3.100-3
ii  mplayer  2:1.4+ds1-1

-- no debconf information

Bug#989310: partx: /dev/$VG/$LV: adding partition #4 failed: Invalid argument

[Chris Hofstaedtler]

* Thorsten Glaser  [210531 21:09]:
> I’m trying to use partx instead of kpartx to make partitions
> available to the system, but it completely fails:
> 
> tglase@tglase:~ $ sudo partx -a -v - /dev/vg-tglase/ufs   
>   
> partition: none, disk: /dev/vg-tglase/ufs, lower: 0, upper: 0
> /dev/vg-tglase/ufs: partition table type 'dos' detected
> range recount: max partno=4, lower=0, upper=0
> partx: /dev/vg-tglase/ufs: adding partition #4 failed: Invalid argument
> partx: /dev/vg-tglase/ufs: error adding partition 4
> 
> Doing this with kpartx works…
[..]

Right. Thanks for the report, however could I ask you to directly
report this to upstream? I don't think this is a Debian peculiarity
and I cannot think of anything useful that I could add to an
upstream bug report.

Thanks!
Chris

Bug#989420: buster-pu: package isc-dhcp/4.4.1-2+deb10u1

[Cyril Brulebois]

Salvatore Bonaccorso  (2021-06-03):
> This brings the update to address CVE-2021-25217 / #989157 in buster
> (the fix was applied already as NMU in unstable and unblocked
> accordingly).
> 
> The debian/changelog entry is
> 
> +isc-dhcp (4.4.1-2+deb10u1) buster; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * A buffer overrun in lease file parsing code can be used to exploit a
> +common vulnerability shared by dhcpd and dhclient (CVE-2021-25217)
> +(Closes: #989157)
> +
> + -- Salvatore Bonaccorso   Thu, 03 Jun 2021 12:59:09 +0200
> 
> The debdiff attached accordingly. But it needs a d-i ack as well from
> Cyril as it produces udebs.

No objections, thanks.


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


signature.asc
Description: PGP signature

Bug#989420: buster-pu: package isc-dhcp/4.4.1-2+deb10u1

[Salvatore Bonaccorso]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: car...@debian.org,k...@debian.org

Hi Stable release managers,

This brings the update to address CVE-2021-25217 / #989157 in buster
(the fix was applied already as NMU in unstable and unblocked
accordingly).

The debian/changelog entry is

+isc-dhcp (4.4.1-2+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * A buffer overrun in lease file parsing code can be used to exploit a
+common vulnerability shared by dhcpd and dhclient (CVE-2021-25217)
+(Closes: #989157)
+
+ -- Salvatore Bonaccorso   Thu, 03 Jun 2021 12:59:09 +0200

The debdiff attached accordingly. But it needs a d-i ack as well from
Cyril as it produces udebs.

Regards,
Salvatore
diff -Nru isc-dhcp-4.4.1/debian/changelog isc-dhcp-4.4.1/debian/changelog
--- isc-dhcp-4.4.1/debian/changelog 2018-12-11 04:55:12.0 +0100
+++ isc-dhcp-4.4.1/debian/changelog 2021-06-03 12:59:09.0 +0200
@@ -1,3 +1,12 @@
+isc-dhcp (4.4.1-2+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * A buffer overrun in lease file parsing code can be used to exploit a
+common vulnerability shared by dhcpd and dhclient (CVE-2021-25217)
+(Closes: #989157)
+
+ -- Salvatore Bonaccorso   Thu, 03 Jun 2021 12:59:09 +0200
+
 isc-dhcp (4.4.1-2) unstable; urgency=medium
 
   * Set initial address to 0.0.0.0 on hurd (closes: #875566).
diff -Nru isc-dhcp-4.4.1/debian/patches/4.4.2.CVE-2021-25217.patch 
isc-dhcp-4.4.1/debian/patches/4.4.2.CVE-2021-25217.patch
--- isc-dhcp-4.4.1/debian/patches/4.4.2.CVE-2021-25217.patch1970-01-01 
01:00:00.0 +0100
+++ isc-dhcp-4.4.1/debian/patches/4.4.2.CVE-2021-25217.patch2021-06-03 
12:59:09.0 +0200
@@ -0,0 +1,29 @@
+Description: A buffer overrun in lease file parsing code can be used to 
exploit a common vulnerability shared by dhcpd and dhclient
+Origin: vendor
+Bug-Debian: https://bugs.debian.org/989157
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2021-25217
+Forwarded: not-needed
+Author: Salvatore Bonaccorso 
+Last-Update: 2021-05-26
+
+diff --git a/common/parse.c b/common/parse.c
+index 386a6321..fc7b39c6 100644
+--- a/common/parse.c
 b/common/parse.c
+@@ -5556,13 +5556,14 @@ int parse_X (cfile, buf, max)
+   skip_to_semi (cfile);
+   return 0;
+   }
+-  convert_num (cfile,  [len], val, 16, 8);
+-  if (len++ > max) {
++  if (len >= max) {
+   parse_warn (cfile,
+   "hexadecimal constant too long.");
+   skip_to_semi (cfile);
+   return 0;
+   }
++  convert_num (cfile,  [len], val, 16, 8);
++  len++;
+   token = peek_token (, (unsigned *)0, cfile);
+   if (token == COLON)
+   token = next_token (,
diff -Nru isc-dhcp-4.4.1/debian/patches/series 
isc-dhcp-4.4.1/debian/patches/series
--- isc-dhcp-4.4.1/debian/patches/series2018-11-18 07:13:45.0 
+0100
+++ isc-dhcp-4.4.1/debian/patches/series2021-06-03 12:59:09.0 
+0200
@@ -16,3 +16,5 @@
 bind-includes.patch
 
 configure.patch
+
+4.4.2.CVE-2021-25217.patch

Bug#987874: [pre-approval] unblock: osspd/1.3.2-12

[Ralf Jung]

Dear release team,

osspd maintainer here. Version 1.3.2-12 has hit unstable now that my new key is 
finally in the keyring.



> diff --git a/debian/changelog b/debian/changelog
> index c412732..9481d07 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,17 @@
> +osspd (1.3.2-12) unstable; urgency=low
> +
> +  [ Sébastien Noel ]
> +  * cherrypick 2 commits from upstream GIT:
> ++ d/p/GIT-fix-adsp_se.patch
> ++ d/p/GIT-fix-compiler-warnings.patch
> +  * Add workaround for pulseaudio >= 13
> +d/p/Hack-to-work-with-modern-PulseAudio.patch  (Closes: #986662)
> +
> +  [ Ralf Jung ]
> +  * Switch to debhelper compat level 13.

Changing compat levels is no longer acceptable for bullseye. Please
revert.


Ah, that's a bummer. I was not aware of this policy, sorry for that.
Doing a revert upload sounds like a lot of hassle though that this package is 
probably not worth -- so in this case it likely makes more sense to simply 
remove the package from testing, and let it re-migrate after the release. The 
current testing version (1.3.2-11) is broken with current PulseAudio, so 
shipping it as-is makes no sense.



+Pre-Depends: ${misc:Pre-Depends}


Why?


Because lintian told me a pre-depends on "init-system-helpers" was missing, and 
this was the easiest way to get that dependency.


Kind regards,
Ralf

Bug#989419: dash: remove obsolete upgrade path from ash versions predating sarge

[Helmut Grohne]

Package: dash
Version: 0.5.11+git20210120+802ebd4-1
Tags: patch

dash.postinst still contains code that handles diversions of /bin/sh
performed by ash. At least since sarge, ash no longer performs such
diversions. Since skipping stable release upgrades is unsupported, this
code can go away without replacement. Please consider applying the
attached patch.

Why is this useful?
 * Less code means less opportunities for bugs.
 * When whole maintainer scripts can be removed, things become easier
   for dpkg.
 * Less code needs to be updated for DPKG_ROOT.

Helmut
diff --minimal -Nru dash-0.5.11+git20210120+802ebd4/debian/changelog 
dash-0.5.11+git20210120+802ebd4/debian/changelog
--- dash-0.5.11+git20210120+802ebd4/debian/changelog2021-03-04 
10:22:32.0 +0100
+++ dash-0.5.11+git20210120+802ebd4/debian/changelog2021-06-03 
12:36:17.0 +0200
@@ -1,3 +1,10 @@
+dash (0.5.11+git20210120+802ebd4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * dash.postinst: Remove upgrade path from pre-sarge ash. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 03 Jun 2021 12:36:17 +0200
+
 dash (0.5.11+git20210120+802ebd4-1) unstable; urgency=medium
 
   * New upstream snapshot.
diff --minimal -Nru dash-0.5.11+git20210120+802ebd4/debian/dash.postinst 
dash-0.5.11+git20210120+802ebd4/debian/dash.postinst
--- dash-0.5.11+git20210120+802ebd4/debian/dash.postinst2021-03-04 
10:22:32.0 +0100
+++ dash-0.5.11+git20210120+802ebd4/debian/dash.postinst2021-06-03 
12:36:11.0 +0200
@@ -73,37 +73,6 @@
replace_with_link $dfile $ltarget $distrib
 }
 
-initial_binsh_setup() {
-   dfile=$1 ltarget=$2 distrib=${3:-$dfile.distrib} ashfile=$4
-   diverter=$(dpkg-divert --listpackage $dfile)
-   truename=$(dpkg-divert --truename $dfile)
-
-   if [ -z "$diverter" ]; then
-   # good.
-   return
-   fi
-
-   if [ "$diverter" = ash ]; then
-   dpkg-divert --package ash --no-rename --remove $dfile
-   dpkg-divert --package dash --no-rename --divert $distrib --add 
$dfile
-
-   if [ "$truename" != "$distrib" ] && [ -e "$truename" ]; then
-   mv "$truename" "$distrib"
-   fi
-   replace_with_link $dfile $ltarget
-   return
-   fi
-
-   if
-   [ -h $dfile ] &&
-   [ -f $dfile ] &&
-   [ -f $ashfile ] &&
-   cmp $dfile $ashfile
-   then
-   replace_with_link $dfile $ltarget
-   fi
-}
-
 add_shell() {
if ! type add-shell > /dev/null 2>&1; then
return
@@ -118,13 +87,8 @@
debconf=yes
 fi
 
-if [ "$1" = configure ] && [ -z "$2" ]; then
-   initial_binsh_setup /bin/sh dash '' /bin/ash
-   initial_binsh_setup /usr/share/man/man1/sh.1.gz dash.1.gz \
-   /usr/share/man/man1/sh.distrib.1.gz \
-   /usr/share/man/man1/ash.1.gz
-   add_shell
-elif [ "$1" = configure ] && dpkg --compare-versions "$2" lt 0.4.18; then
+# The empty version string used for initial configuration also compares less.
+if [ "$1" = configure ] && dpkg --compare-versions "$2" lt 0.4.18; then
add_shell
 fi
 

Bug#984761: dcraw: buffer-overflow caused by integer-overflow in foveon_load_camf()

[Filip Hroch]

Dear Salvatore,

unfortunatelly, I have not fixed it yet.

I suppose to report it to upstream author -- Mr. Coffin.
In past, I send patches without any response.

The last upstream version of dcraw has been issued
tree years ago, so I've some worry about him.

Regards,
FH


Salvatore Bonaccorso  writes:


Hi Filip, Wooseok

On Tue, Mar 09, 2021 at 05:41:51PM +0100, Filip Hroch wrote:

Dear Wooseok,

I'll look on this.

Note, that I'm maintaining only Debian packaging.
I am not upstream autor; I can fix only the bugs
which does not induce extensive changes in whole
structure of the source code.


Can you please report the issue upstream? Or was this reported
upstream?

Regards,
Salvatore



--
F. Hroch , Masaryk University,
Dept. of theor. physics and astrophysics, Brno, Moravia, CZ

Bug#984520: 'error: symbol "grub_register_command_lockdown" not found' and then lightdm fails to start

[Colin Watson]

On Thu, Jun 03, 2021 at 11:07:27AM +0200, Jesús Ángel wrote:
> I am also facing this error every now and then. Sometimes GRUB doesn't
> boot and keeps showing "error: symbol `grub_register_command_lockdown'
> not found.".
> On pressing any key, GRUB restarts and I get the same error again.

If you're getting this non-deterministically, it suggests that you have
multiple possible boot disks and either your firmware is picking one or
the other inconsistently, or GRUB isn't properly configured to install
to the right ones.  You should run "dpkg-reconfigure grub-pc" and select
all the disks that your firmware might boot from at the "GRUB install
devices:" prompt.

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

Bug#961197: debmirror does not clean up temporary files created under /tmp

[Colin Watson]

On Mon, May 25, 2020 at 10:35:39PM -0700, Kees Cook wrote:
> I think this patch will fix the problem...

> --- debmirror~2020-05-25 22:33:49.328041109 -0700
> +++ debmirror 2020-05-25 22:32:12.255722606 -0700
> @@ -2326,6 +2326,8 @@
>  push (@errlog,$@);
>  $num_errors++;
>}
> +  unlink($content_filename);
> +  unlink($signature_filename);
>  }
>  if (! $got_gpg) {
>say("Release gpg signature does not verify, file missing.");

Sorry I missed this for a year.  Looks fine - applying.

Thanks,

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

Bug#989418: unblock: libpappsomspp/0.8.25-2

[Filippo Rusconi]

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

unblock libpappsomspp/0.8.25-2

Please unblock package libpappsomspp

Greetings, Fellow Developers,

I would like in this mail to advocate the unblocking of the transition for two
packages:

- libpappsomspp
- minexpert2

minexpert2 depends on libpappsomspp.

[ Reason ]

The libpappsomspp and minexpert2 software packages are developed in my
laboratory and are in daily use since a large number of weeks. The last versions
in unstable (libpappsomspp: 0.8.25-2, minexpert2: 8.1.1-1) work flawlessly in
our hands.


Would you mind to unblock their migration to testing ?

[ Impact ]
It would be very sad if these last versions failed to enter the next stable
release because a number of labs rely on that software piece, in particular
because they use Ubuntu.

[ Risks ]
As mentioned above, the software at hand is stable.

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

In the sincere hope you will agree to this request,

most sincerely,

Filippo


-- 

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Research scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
  http://www.debian.org

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

[Sebastian Ramacher]

Hi Andreas

On 2021-06-03 01:41:37 +0200, Andreas Beckmann wrote:
> On 02/06/2021 22.22, Sebastian Ramacher wrote:
> > So, what if we use the free versions between 103 and 200 to transition
> > to a Debian-specific version? Attached is a patch that does that. It's
> > not an optimal solution as we would have a release with a
> > Debian-specific SOVERSIONs. For good reason, we usually try to avoid
> > those. So, it would be good for someone more familiar with the users of
> > hdf5 to check if that would be an issue in this specific case.
> 
> Can we be even more explicit about that and use a SOVERSION like "106deb" ?
> That might be a bit tricky with libtool, though.

Unless somebody knows how to do that with libtool, 103deb or something
similar won't work.

> I think you should only remove Conflicts/Replaces on libhdf5*-103 and
> leave all other there. (Have they been in buster already?)
> 
> You definitively want to have a
>   Breaks: libhdf5-foo-10x(-1)
> in each libhdf5-foo-106 package as we don't want to mix the current
> bullseye packages with your proposed packages

Why though? Adding this Breaks will require us to do a lock step
transition. At this stage of the freeze, I don't want one potential
build failure holding hdf5 back from transitioning to bullseye.

Unless there is a really good reason why they'd be needed, let's avoid
them.

> Wouldn't it be sufficient to rename only the packages where the
> soversion is the same in buster and bullseye?

Yes, but I didn't have this table at hand and some of those SOVERSIONs
are still derived from the same version. For example, all
.*hl_fortran.so have the same SOVERSION.

> I'll try to make a table:
> 
> library   buster  
> bullseyeproposed soversion
> 
> libhdf5_serial.so.103 libhdf5-103 libhdf5-103-1   
> 103deb or 106
> libhdf5_serial_fortran.so.100 libhdf5-103 n/a 
> -
> libhdf5_serial_fortran.so.102 n/a 
> libhdf5-fortran-102 keep
> libhdf5_serial_hl.so.100  libhdf5-103 libhdf5-hl-100  
> 100deb or 106
> libhdf5_serialhl_fortran.so.100   libhdf5-103 
> libhdf5-hl-fortran-100  100deb or 106
> 
> libhdf5_cpp.so.103libhdf5-cpp-103 
> libhdf5-cpp-103-1   103deb or 106
> libhdf5_hl_cpp.so.100 libhdf5-cpp-103 
> libhdf5-hl-cpp-100  100deb or 106
> 
> libhdf5_mpich.so.103  libhdf5-mpich-103   
> libhdf5-mpich-103-1 103deb or 106
> libhdf5_mpich_fortran.so.100  libhdf5-mpich-103   n/a 
> -
> libhdf5_mpich_fortran.so.102  n/a 
> libhdf5-mpich-fortran-102   keep
> libhdf5_mpich_hl.so.100   libhdf5-mpich-103   
> libhdf5-mpich-hl-100100deb or 106
> libhdf5_mpichhl_fortran.so.100libhdf5-mpich-103   
> libhdf5-mpich-hl-cpp-100100deb or 106
> 
> libhdf5_mpich_cpp.so.103  n/a 
> libhdf5-mpich-cpp-103-1 keep or 103
> libhdf5_mpich_hl_cpp.so.100   n/a 
> libhdf5-mpich-hl-cpp-100keep
> 
> libhdf5_openmpi.so.103libhdf5-openmpi-103 
> libhdf5-openmpi-103-1   103deb or 106
> libhdf5_openmpi_fortran.so.100libhdf5-openmpi-103 n/a 
> -
> libhdf5_openmpi_fortran.so.102n/a 
> libhdf5-openmpi-fortran-102 keep
> libhdf5_openmpi_hl.so.100 libhdf5-openmpi-103 
> libhdf5-openmpi-hl-100  100deb
> libhdf5_openmpihl_fortran.so.100  libhdf5-openmpi-103 
> libhdf5-openmpi-hl-fortran-100  100deb
> 
> libhdf5_openmpi_cpp.so.103n/a 
> libhdf5-openmpi-cpp-103-1   keep or 103
> libhdf5_openmpi_hl_cpp.so.100 n/a 
> libhdf5-openmpi-hl-cpp-100  keep

libhdf5_{serial,mpich,openmpi}_fortran.so.102 can be kept. All the
others can't. Updated patch attached (also with the changes to TOOLS and
JAVA revertred as are not relevant).

> Well, having different sonames for libhdf5_cpp.so and libhdf5_*mpi*_cpp.so
> might be difficult and non-intuitive.

… it's also not possible without touching more parts of the buidl system.

> But at least you don't have to touch libhdf5*-fortran-102 ;-)
> 
> 
> BUT: This would still only solve the co-installability mess of hdf5,
> the gdal problem is still there.

One step after the other :)

Cheers
-- 
Sebastian Ramacher
diff -Nru hdf5-1.10.6+repack/debian/changelog 
hdf5-1.10.6+repack/debian/changelog
--- hdf5-1.10.6+repack/debian/changelog 2020-04-24 20:00:42.0 +0200
+++ hdf5-1.10.6+repack/debian/changelog 2021-06-02 21:33:00.0 +0200
@@ -1,3 

Bug#989399: nauty FTCBFS -- multiple reasons

[Nilesh Patra]

Hello Andrius

On Thu, 3 Jun 2021 at 13:10, Andrius Merkys  wrote:

> Hi Nilesh,
>
> On 2021-06-02 19:29, Nilesh Patra wrote:
> > Nauty fails to cross build due to two reasons:
> >
> > 1. It uses AC_RUN_IFELSE testing which cannot heppen during cross build
> >Simply replacing it by AC_LINK_IFELSE does the trick. Please find the
> >patch for this below, and consider applying
>
> I have no experience with this, alas.
>

This patch that I suggested is actually wrong, as you might see in Helmut's
message.
But more importantly, we ended up discovering that this is a *Release
critical*  bug instead.
Please consider fixing it ASAP if you have some free cycles.

More details in Helmut's email[0] again

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989399#10

 >> [1]:
https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/createmanpages

> Indeed, help2man should not call the compiled executables. Nevertheless
> it may still be used to produce manpages from static text, see [2] for
> example.


This looks nice, there is also ronn and node-marked-man which can do
similar stuff via README.
But doing so isn't always possible because several times we have multiple
binaries and we need separate manual page for each binary.
In such a case, we need to maintain a maintainer manpage

createmanpages is a viable option too.
>
> [2]
>
> https://salsa.debian.org/debian/libemf2svg/-/blob/df56bd1149cf512b6a232052437d04310bd90982/debian/rules#L11
>

Nilesh

Bug#425405: Not a bug

[Jonas Smedegaard]

Control: reassign -1 printer-driver-cups-pdf
Control: unarchive 847462
Control: forcemerge -1 847462

Quoting alex (2021-06-03 09:36:51)
> How Ghostscript can guess what Unicode code points
> correspond to the characters in the sample PS file?
> The PS file gives no clues at all.
> 
> Modern programs can search the attached PDF file by
> assuming that encoding is ASCII of some standard encoding
> similar to ASCII..
> 
> IMHO it is not a bug. At least it is not a Ghostscript bug.

I agree that this is unlikely a bug in Ghostscript.

The test PDF provided by Jonathan Nieder _is_ searchable with Evince 
3.38.2-1.

If same file was not searchable with Evince available in January 2011, 
then the issue might be the encoding of the strings in the PDF, or it 
might be something else that confused that older release of Evince.

But that test file was produced by LibreOffice.  I would expect that a 
file generated by cups-pdf would instead have cups-pdf as creator in the 
metadata.

I therefore suspect that the test PDF file should be ignored for this 
issue, and that the originally reported issue is a different one: 
Ghostscript primarily renders a "painting" and secondarily preserves as 
metadata high-level information like strings of text and color spaces.

One way metadata is lost is if CUPS filters use Postsript as 
intermediary format.  That was the case in the past but the default 
should nowadays use PDF as intermediary format.

Another way that metadata is "lost" is if it was not really there in the 
first place - e.g. because it was dropped before being handed to 
Ghostscript.

For the record: If you suspect that an issue is in Ghostscript then 
please provide the ghostscript command that causes this issue - without 
that the only possible action is to tag it as unreproducible and close 
it, which is not really helpful.

This issue is highly likely a duplicate of 847462 - thus merging.


 - 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#989417: mc could recognize foot’s default TERM

[Grzegorz Szymaszek]

Package: mc
Version: 3:4.8.26-1

Dear Maintainer,

foot is a “fast, lightweight and minimalistic Wayland terminal
emulator”[1]. Its Debian package is recommended by the Debian sway (a
Wayland compositor) package[2]. Its default TERM value is “foot”, which
is unrecognized by the mc version packaged in bullseye, and prevents mc
from updating the terminal window title, handling mouse events and key
shortcuts like Shift+Tab (in mc dialogs).

Recently a patch was merged upstream[3] that adds foot to the recognized
TERMs. Please consider backporting it in bullseye.

[1]: https://codeberg.org/dnkl/foot
[2]: https://packages.debian.org/bullseye/sway
[3]: https://midnight-commander.org/ticket/4251

-- 
Grzegorz


signature.asc
Description: PGP signature

Bug#989416: unblock: homebank/5.5.2-1

[Francesco Namuri]

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

Please unblock package homebank

(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)

[ Reason ]
Just some small bugfixes.

[ Impact ]
Low.

[ Tests ]
Manually tested in my environment.

[ Risks ]
The changes should be trivial.

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

[ Other info ]
The  attacched diff is filtered to exclude .po file changes.

unblock homebank/5.5.2-1


homebank_5.5.2-1.filterd.diff.gz
Description: application/gzip

Bug#989415: network-manager: Intel WiFi on Thinkpad X280 cannot connect: reason=CONN_FAILED

[Tommaso Gagliardoni]

Package: network-manager
Version: 1.30.0-2
Severity: important
X-Debbugs-Cc: donotre...@gagliardoni.net

Dear Maintainer,

not sure exactly when it started because I use regularly my laptop connected
via ethernet. This is a Lenovo Thinkpad X280 with Debian testing and Gnome.
Connection to any WiFi network fails with no apparent reason. The card is
turned on, in fact I can scan existing WiFi's but whenever I try to connect it
fails. I am dual-booting with Windows and the problem does not appear there, so
I guess it's not a hardware problem. Also, I'm 100% sure the wifi key is
correct.

This is my first bug report here, apologies if I mess up.

Here is what I see:

# lspci |grep -i wireless
---8<---8<---8<---8<---8<
3b:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)
---8<---8<---8<---8<---8<

# journalctl -f
---8<---8<---8<---8<---8<
May 21 18:01:30 myhostname NetworkManager[639]:   [1621591290.4929]
device (wlp59s0): Activation: starting connection 'WiFi_mySSID' (0123abcd-
just-00an-uuid-0123456789ab)
May 21 18:01:30 myhostname NetworkManager[639]:   [1621591290.4930]
audit: op="connection-add-activate" uuid="0123abcd-just-00an-uuid-0123456789ab"
name="WiFi_mySSID" pid=957 uid=1000 result="success"
May 21 18:01:30 myhostname NetworkManager[639]:   [1621591290.4954]
device (wlp59s0): state change: disconnected -> prepare (reason 'none', sys-
iface-state: 'managed')
May 21 18:01:30 myhostname NetworkManager[639]:   [1621591290.4958]
manager: NetworkManager state is now CONNECTING
May 21 18:01:30 myhostname NetworkManager[639]:   [1621591290.4962]
device (wlp59s0): state change: prepare -> config (reason 'none', sys-iface-
state: 'managed')
May 21 18:01:30 myhostname NetworkManager[639]:   [1621591290.4966]
device (wlp59s0): Activation: (wifi) access point 'WiFi_mySSID' has security,
but secrets are required.
May 21 18:01:30 myhostname NetworkManager[639]:   [1621591290.4966]
device (wlp59s0): state change: config -> need-auth (reason 'none', sys-iface-
state: 'managed')
May 21 18:01:30 myhostname NetworkManager[639]:   [1621591290.4968] sup-
iface[0123456789abcdef,0,wlp59s0]: wps: type pbc start...
May 21 18:01:30 myhostname wpa_supplicant[655]: wlp59s0: WPS-PBC-ACTIVE
May 21 18:01:30 myhostname NetworkManager[639]:   [1621591290.5077]
device (wlp59s0): supplicant interface state: disconnected -> scanning
May 21 18:01:30 myhostname NetworkManager[639]:   [1621591290.5077]
device (p2p-dev-wlp59s0): supplicant management interface state: disconnected
-> scanning
May 21 18:01:55 myhostname NetworkManager[639]:   [1621591315.7216]
device (wlp59s0): state change: need-auth -> prepare (reason 'none', sys-iface-
state: 'managed')
May 21 18:01:55 myhostname NetworkManager[639]:   [1621591315.7221]
device (wlp59s0): state change: prepare -> config (reason 'none', sys-iface-
state: 'managed')
May 21 18:01:55 myhostname NetworkManager[639]:   [1621591315.7223]
device (wlp59s0): Activation: (wifi) connection 'WiFi_mySSID' has security, and
secrets exist.  No new secrets needed.
May 21 18:01:55 myhostname NetworkManager[639]:   [1621591315.7224]
Config: added 'ssid' value 'WiFi_mySSID'
May 21 18:01:55 myhostname NetworkManager[639]:   [1621591315.7224]
Config: added 'scan_ssid' value '1'
May 21 18:01:55 myhostname NetworkManager[639]:   [1621591315.7224]
Config: added 'bgscan' value 'simple:30:-70:86400'
May 21 18:01:55 myhostname NetworkManager[639]:   [1621591315.7224]
Config: added 'key_mgmt' value 'WPA-PSK WPA-PSK-SHA256 FT-PSK'
May 21 18:01:55 myhostname NetworkManager[639]:   [1621591315.7224]
Config: added 'auth_alg' value 'OPEN'
May 21 18:01:55 myhostname NetworkManager[639]:   [1621591315.7224]
Config: added 'psk' value ''
May 21 18:01:55 myhostname wpa_supplicant[655]: wlp59s0: SME: Trying to
authenticate with 00:ff:aa:55:00:ff (SSID='WiFi_mySSID' freq=2412 MHz)
May 21 18:01:55 myhostname kernel: wlp59s0: authenticate with 00:ff:aa:55:00:ff
May 21 18:01:55 myhostname NetworkManager[639]:   [1621591315.7474]
device (wlp59s0): supplicant interface state: scanning -> authenticating
May 21 18:01:55 myhostname NetworkManager[639]:   [1621591315.7475]
device (p2p-dev-wlp59s0): supplicant management interface state: scanning ->
authenticating
May 21 18:01:55 myhostname kernel: wlp59s0: send auth to 00:ff:aa:55:00:ff (try
1/3)
May 21 18:01:55 myhostname wpa_supplicant[655]: wlp59s0: Trying to associate
with 00:ff:aa:55:00:ff (SSID='WiFi_mySSID' freq=2412 MHz)
May 21 18:01:55 myhostname NetworkManager[639]:   [1621591315.7629]
device (wlp59s0): supplicant interface state: authenticating -> associating
May 21 18:01:55 myhostname NetworkManager[639]:   [1621591315.7630]
device (p2p-dev-wlp59s0): supplicant management interface state: authenticating
-> associating
May 21 18:01:55 myhostname kernel: wlp59s0: authenticated
May 21 18:01:55 myhostname kernel: wlp59s0: 

Bug#989407: tpm-tss: CVE-2020-24455 not in buster

[Salvatore Bonaccorso]

Hi Bastian,

On Thu, Jun 03, 2021 at 11:27:25AM +0200, Bastian Germann wrote:
> Am 03.06.21 um 10:48 schrieb Salvatore Bonaccorso:
> > p.s.: why did you filled this as bug against the package? ;-)
> > 
> 
> What is the official way to get info in the security tracker corrected?
> Sending an arbitrary mail to the security team?

Either that, or use the debian-security-tracker mailing list to notify
that there is soemthing which is not correctly tracked, then we can
look at.

https://lists.debian.org/debian-security-tracker/

It was quite concicence that I spotted your bugreport actually thanks
to the CVE mentioning in the subject, and was looking at the
##debian-devel-changes IRC channel, so was able to followup.

Thank you,

Regards,
Salvatore

Bug#989414: gnome-software: High memory usage

[Paul Menzel]

Package: gnome-software
Version: 3.38.1-1
Severity: normal
Forwarded: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/941


Dear Debian folks,


After 13 days of uptime, gnome-software used almost 2 GB of memory.

XXX 1396  0.0 12.1 3093792 1974280 ? Sl   Mai21   3:18  | 
\_ /usr/bin/gnome-software --gapplication-service


```
$ sudo pmap 1396 | sort -h -k2
1396:   /usr/bin/gnome-software --gapplication-service
55996ec97000  4K rw--- gnome-software
7f06fa7fd000  4K -   [ anon ]
7f06fb7ff000  4K -   [ anon ]
7f0703fff000  4K -   [ anon ]
7f071cffa000  4K -   [ anon ]
7f071f7ff000  4K -   [ anon ]
7f073412c000  4K -   [ anon ]
7f0734d3e000  4K -   [ anon ]
7f0735b6f000  4K - libnss_resolve.so.2
[…]
7f06e0379000  61980K -   [ anon ]
7f073016b000  64084K -   [ anon ]
7f068800  64136K rw---   [ anon ]
7f073815  64192K -   [ anon ]
7f06a8021000  65404K -   [ anon ]
7f0714021000  65404K -   [ anon ]
7f0718021000  65404K -   [ anon ]
7f073c021000  65404K -   [ anon ]
7f0740021000  65404K -   [ anon ]
7f06f000  65512K rw---   [ anon ]
7f068c00  65516K rw---   [ anon ]
7f07  65532K rw---   [ anon ]
7f069000  65536K rw---   [ anon ]
7f069c00  65536K rw---   [ anon ]
7f06a000  65536K rw---   [ anon ]
7f06b800  65536K rw---   [ anon ]
7f06c000  65536K rw---   [ anon ]
7f06c800  65536K rw---   [ anon ]
7f06d000  65536K rw---   [ anon ]
7f06d400  65536K rw---   [ anon ]
7f06dc00  65536K rw---   [ anon ]
7f06e400  65536K rw---   [ anon ]
7f06e800  65536K rw---   [ anon ]
7f06f400  65536K rw---   [ anon ]
7f070400  65536K rw---   [ anon ]
7f070c00  65536K rw---   [ anon ]
7f071000  65536K rw---   [ anon ]
7f072000  65536K rw---   [ anon ]
7f072400  65536K rw---   [ anon ]
7f06b000  99168K rw---   [ anon ]
7f072800 131072K rw---   [ anon ]
559970823000 258424K rw---   [ anon ]
 gesamt  3093792K
```

Upstream says [1] it’s probably fixed in version 40


Kind regards,

Paul


[1]: https://gitlab.gnome.org/GNOME/gnome-software/-/issues/941
[2]: https://gitlab.gnome.org/GNOME/gnome-software/-/blob/gnome-40/NEWS
[3]: https://tecnocode.co.uk/2020/06/09/heap-profiling-of-gnome-software/

Bug#989332: libwebkit2gtk-4.0-37: May 30 upgrade for DSA-4923-1 broke the epiphany browser

[Alberto Garcia]

On Thu, Jun 03, 2021 at 01:37:45AM +0200, Jose wrote:
> > Can you install gstreamer1.0-plugins-good and try again?
> 
> That was the issue. Thank you for helping.
> 
> I don't understand why it was working before the libwebkit2gtk
> update.  Maybe this is a dependency that should be added to the
> epiphany package?

WebKitGTK requires gstreamer1.0-plugins-good in order to play audio.
In earlier versions if the plugins were not found it would simply not
play any audio but continue browsing (that's why the plugins are not a
hard dependency but a recommendation).

This changed in WebKitGTK 2.32, so we either have to make it a
dependency or make it work again without the plugins installed.

I'll fix this for bullseye, but I'm not sure if there will be a new
security update just for this.

Berto

Bug#984520: 'error: symbol "grub_register_command_lockdown" not found' and then lightdm fails to start

[Jesús Ángel]

Package: grub2
Version: 2.02+dfsg1-20+deb10u4
Followup-For: Bug #984520

Dear Maintainer,

I am also facing this error every now and then. Sometimes GRUB doesn't
boot and keeps showing "error: symbol `grub_register_command_lockdown'
not found.".
On pressing any key, GRUB restarts and I get the same error again.

I can fix the issue by booting into a Knoppix live, mounting the
filesystem under
/mnt, chrooting into it and running grub-install /dev/sda. However, it's
quite
annoying and time-wasting.

I wonder how is it possible to fix the problem just by running the
grub-install
command again. I don't know either what's triggering this issue, but I
think the
one to blame is some kernel upgrade which triggers a grub-update.


Yours faithfully,

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/root / ext4 rw,relatime,errors=remount-ro 0 0
/dev/vda1 /boot ext3 rw,relatime,errors=remount-ro 0 0
/dev/mapper/var /var ext4 rw,relatime,errors=remount-ro 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(fd0) /dev/fd0
(hd0) /dev/vda
(hd1) /dev/vdb
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root  b80ab3af-3b43-40f4-99b1-168a721ea949
else
  search --no-floppy --fs-uuid --set=root b80ab3af-3b43-40f4-99b1-168a721ea949
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=30
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=30
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-b80ab3af-3b43-40f4-99b1-168a721ea949' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint='hd0,msdos1'  
0dfb2e8d-27fe-4ff5-bf51-3d873f3910b9
else
  search --no-floppy --fs-uuid --set=root 
0dfb2e8d-27fe-4ff5-bf51-3d873f3910b9
fi
echo'Loading Linux 4.19.0-16-amd64 ...'
linux   /vmlinuz-4.19.0-16-amd64 
root=UUID=b80ab3af-3b43-40f4-99b1-168a721ea949 ro  quiet systemd.show_status=1 
acpi=force net.ifnames=0 biosdevname=0 
rd.luks.name=c9430ec8-ae4b-4a84-9371-9746e87fff7c=root rd.neednet=1 
ip=10.0.0.121:::255.255.255.0:tornavacas:eth1:none:10.0.0.103:10.0.0.104
echo'Loading initial ramdisk ...'
initrd  /initrd.img-4.19.0-16-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-b80ab3af-3b43-40f4-99b1-168a721ea949' {
menuentry 'Debian GNU/Linux, with Linux 4.19.0-16-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-4.19.0-16-amd64-advanced-b80ab3af-3b43-40f4-99b1-168a721ea949' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
insmod 

Bug#989406:

[Jason A. Donenfeld]

Many people run Debian on different kernels. Therefore the dkms remains
useful and should not be removed.

Bug#425405: Not a bug

[alex]

How Ghostscript can guess what Unicode code points
correspond to the characters in the sample PS file?
The PS file gives no clues at all.

Modern programs can search the attached PDF file by
assuming that encoding is ASCII of some standard encoding
similar to ASCII..

IMHO it is not a bug. At least it is not a Ghostscript bug.

Bug#989400: [debian-mysql] Bug#989400: mariadb-server-10.5: MariaDB fail to execute CONVERT TO CHARACTER

[Dmitriy Rabotyagov]

Hi!

I think I can't get 10.5.9? I'm missing some repo that contains previously 
built versions? Or you mean to build own deb packages for it?

~# apt-cache policy mariadb-server-10.5
mariadb-server-10.5:
  Installed: 1:10.5.10-2
  Candidate: 1:10.5.10-2
  Version table:
 *** 1:10.5.10-2 500
500 http://deb.debian.org/debian bullseye/main amd64 Packages
100 /var/lib/dpkg/status
~# 




03.06.2021, 10:26, "Otto Kekäläinen" :
> Hello!
>
> Seems upstream devs are working on https://jira.mariadb.org/browse/MDEV-25672
> Once 10.5.11 is available we will work to quickly introduce it to Debian.
>
> You can get the previous version in Debian (10.5.9) and deploy that on
> your systems if you want. We don't plan to do any Debian-wide special
> tricks for this one, we will just wait until there is a new upstream
> release.


-- 
Kind Regards,
Dmitriy Rabotyagov

Bug#989399: nauty FTCBFS -- multiple reasons

[Andrius Merkys]

Hi Nilesh,

On 2021-06-02 19:29, Nilesh Patra wrote:
> Nauty fails to cross build due to two reasons:
> 
> 1. It uses AC_RUN_IFELSE testing which cannot heppen during cross build
>Simply replacing it by AC_LINK_IFELSE does the trick. Please find the
>patch for this below, and consider applying

I have no experience with this, alas.

> 2. It uses help2man during build, and the same has also been
>autotoolised - this isn't allowed during build. It looks like there's 
> particularly
>no good way to fix it, and probably compiling twice once for build
>arch, and once for host is un-needed extra work.
>I'd suggest removing the help2man invocations from autotools, not
>generate this during build, but simply maintain maintainer manpage,
>using for example createmanpages script[1]
>Talking to upstream and asking them to vendor their own manpages from
>next release can also be a nice option.
> 
>If it is too much hassle for you, I'm willing to do so myself and
>even maintain the package
> 
> [1]: 
> https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/createmanpages

Indeed, help2man should not call the compiled executables. Nevertheless
it may still be used to produce manpages from static text, see [2] for
example. createmanpages is a viable option too.

[2]
https://salsa.debian.org/debian/libemf2svg/-/blob/df56bd1149cf512b6a232052437d04310bd90982/debian/rules#L11

Best,
Andrius

Bug#989400: [debian-mysql] Bug#989400: mariadb-server-10.5: MariaDB fail to execute CONVERT TO CHARACTER

[Otto Kekäläinen]

Hello!

Seems upstream devs are working on https://jira.mariadb.org/browse/MDEV-25672
Once 10.5.11 is available we will work to quickly introduce it to Debian.

You can get the previous version in Debian (10.5.9) and deploy that on
your systems if you want. We don't plan to do any Debian-wide special
tricks for this one, we will just wait until there is a new upstream
release.

Bug#981794: RFS: gftools/0.5.2+dfsg-1 [ITP] -- Google Fonts Tools

[Tobias Frost]

On Wed, Jun 02, 2021 at 11:57:51PM +0200, Romain Porte wrote:
> Hi tobi,
> 
> On Wed, 02 Jun 2021 17:02:06 +0200 Tobias Frost  wrote:
> 
> I have fixed this issue by renaming the dependency to the correct name
> (python3-ots instead of python3-opentype-sanitizer). New package version
> has just been signed and uploaded to mentors [1]. The commit that
> provides the fix was also pushed to the Salsa repository [2].
>

Thanks for the quick update!

The package seems good, beside d/copyright:
- Copyright years are missing
- d/copyright is incomplete/inaccurate:
for example: file bin/gftools-fix-ascii-fontmetadata.py has:
# Copyright 2013 The Font Bakery Authors.
# Copyright 2017 The Google Font Tools Authors
(- optional: Its customary to say "Apache-2.0", not "Apache-2" as license
   identifier in d/copyright, this is also the SPDX identifier for it.)

So, after you've reviewed and updated c/copyright, ping me again.

(Note: I'm usually not sponsoring python, but as this package blocks other RFSs,
I'm doing an exception here. If someone with more experience in this field wants
to chime in, I'd be happy.)

Cheers,
-- 
tobi

Bug#989413: Build network-manager 1.14.6-2+deb10u1 on Debian 10 failed

[莊敬中]

Package: network-manager

Version: 1.14.6-2+deb10u1

I downloaded src code and debian from 
https://packages.debian.org/zh-tw/source/buster/network-manager
Try to use dpkg-buildpackage -uc -us -b -nc to build debian package locally
It failed and showed the following error

debian/org.freedesktop.NetworkManager.pkla: 1: 
debian/org.freedesktop.NetworkManager.pkla: [Adding: not found 
debian/org.freedesktop.NetworkManager.pkla: 2: 
debian/org.freedesktop.NetworkManager.pkla: unix-group:sudo: not found 
debian/60-network-manager.rules: 1: debian/60-network-manager.rules: Syntax 
error: word unexpected (expecting ")") debian/01-ifupdown: called with unknown 
action `' dh_install: debian/network-manager.install is marked executable but 
does not appear to an executable config. dh_install: dh_install: If 
debian/network-manager.install is intended to be an executable config file, 
please ensure it can dh_install: be run as a stand-alone script/program (e.g. 
"./debian/network-manager.install") dh_install: Otherwise, please remove the 
executable bit from the file (e.g. chmod -x "debian/network-manager.install") 
dh_install: dh_install: Please see "Executable debhelper config files" in 
debhelper(7) for more information. dh_install: dh_install: 
debian/network-manager.install (executable config) returned exit code 1 
make[1]: *** [debian/rules:61: override_dh_install] Error 25 make[1]: Leaving 
directory '/debian/NetworkManager-1.14.6' make: *** [debian/rules:8: binary] 
Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2

I checked debian/60-network-manager.rules and it seems no unsuitable syntax
Try chmod -x "debian/network-manager.install" and it still didn't work for me
My OS is Debian GNU/Linux 10 (buster), running on docker
Kernel version is Linux a1b9afe10133 5.4.72-microsoft-standard-WSL2 #1 SMP Wed 
Oct 28 23:40:43 UTC 2020 x86_64 GNU/Linux

Bug#989412: unblock: ifupdown-extra/0.32

[Javier Fernández-Sanguino Peña]

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

Please unblock package ifupdown-extra

[ Reason ]

There is a bug (#987310) in the package in testing which prevents the
static-routes script (/etc/network/if-up.d/20static-routes) from working
properly when the package is configured to include them.

I have also taken the opportunity to:
- fix the script so it exits gracefully if called directly (i.e.
  when the interface to act on is not set)
- fix the script so that the 'status' check works properly when the gateways
  have a defined name in the /etc/hosts
- update the documentation (README) to warn users about the behaviour of one
  script.

[ Impact ]

If the package is not unblocked users installing this package and trying to set
static routes will have their routes added to the 'blackhole' configuration
instead.

[ Tests ]
Tested locally in developer's machine with different configuration variations. 
The script runs as expected (adding, removing and checking the status
of routes added in /etc/network/routes

[ Risks ]
Changes in the package are trivial, there is very low risk

[ 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 ifupdown-extra/0.32

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-1-686-pae (SMP w/4 CPU threads)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru ifupdown-extra-0.31/debian/changelog 
ifupdown-extra-0.32/debian/changelog
--- ifupdown-extra-0.31/debian/changelog2020-09-19 09:09:41.0 
+0200
+++ ifupdown-extra-0.32/debian/changelog2021-06-03 08:13:30.0 
+0200
@@ -1,3 +1,16 @@
+ifupdown-extra (0.32) unstable; urgency=high
+
+  * if-up-scripts/static-routes:
+ - Fix syntax error in script which causes routes added to be converted
+   into "blackhole" routes (Closes: 987310)
+ - Fail properly if the inteface (IFACE) is not defined when the script
+   is called
+ - Use route -n instead of 'route' to properly identify status of routes
+   when the gateways are in the hosts file
+  * debian/README: Describe caveats related to network link tests
+
+ -- Javier Fernández-Sanguino Peña   Thu, 03 Jun 2021 
08:13:30 +0200
+
 ifupdown-extra (0.31) unstable; urgency=medium
 
   * Fix some network scripts to adapt to the naming scheme introduced 
diff -Nru ifupdown-extra-0.31/debian/README ifupdown-extra-0.32/debian/README
--- ifupdown-extra-0.31/debian/README   2020-09-19 09:09:37.0 +0200
+++ ifupdown-extra-0.32/debian/README   2021-06-03 08:13:30.0 +0200
@@ -16,8 +16,12 @@
 submit it as a bug report to the package.
 
 
-Known limitations
-
+Known limitations:
+--
+
+---
+Interface names
+---
 
 Starting with v197, systemd/udev creates predictable network interface names
 for all local Ethernet, WLAN and WWAN interfaces. However, system
@@ -42,6 +46,22 @@
 systemd.net-naming scheme: 
https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html
 
 
+--
+Network link checks
+--
+
+The script that tests the network link is run inmediately after an interface is
+administratively configured up. However, the underlying hardware sometime it
+takes some time to establish and negotiate a link. This is heavily dependant on
+the hardware itself and the system it is connected to (e.g. if auto negotiation
+of an interface is enabled or the duplex/mode are forced in the interface). 
+
+Due to this time interval for the link to fully stablise it is possible that
+the check-network-cable might generate false negative error messages on
+systems. 
+
+If this is your case, you are encourage to disable the script by editing
+/etc/default/network-test and changing the variable DO_CABLETEST to 'no'
 
 --
 Javier Fernández-Sanguino
diff -Nru ifupdown-extra-0.31/if-up-scripts/static-routes 
ifupdown-extra-0.32/if-up-scripts/static-routes
--- ifupdown-extra-0.31/if-up-scripts/static-routes 2020-08-15 
01:30:37.0 +0200
+++ ifupdown-extra-0.32/if-up-scripts/static-routes 2021-06-03 
08:13:30.0 +0200
@@ -51,6 +51,11 @@
 # Default value
 VERBOSITY=${VERBOSITY:-0}
 
+[ "$IFACE" ] || {
+$OUTPUT "ERROR: Variable IFACE not set in environment"
+exit 1
+}
+
 # https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901612
 if [ ${IFACE} = "--all" ]; then IFACE="[[:alnum:]]+"; fi
 
@@ -80,7 +85,7 @@
cat $ROUTEFILE | egrep "^[^#].*[[:space:]]${IFACE}[[:space:]]*$" | 
while read network netmask gateway interface ; do
 if [ -n "$interface" ] && [ -n "$network" ] && [ -n 

Bug#989411: podman: Please add zsh completion to podman package.

[Jan Srzednicki]

Package: podman
Version: 3.0.1+dfsg1-2
Severity: wishlist
Tags: patch
X-Debbugs-Cc: k...@wrzask.pl

Dear Maintainer,

   * What led up to the situation?

I'm using zsh, completion for podman is not installed by the package
(only bash completion is included).

Solution is simple:

$ podman completion zsh -f /usr/share/zsh/vendor-completions/_podman

... will produce the completion file in a proper location for zsh
autolads.

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

Kernel: Linux 5.10.16.3-microsoft-standard-WSL2 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages podman depends on:
ii  conmon   2.0.25+ds1-1
ii  containernetworking-plugins  0.9.0-1+b3
ii  crun 0.17+dfsg-1
ii  golang-github-containers-common  0.33.4+ds1-1
ii  init-system-helpers  1.60
ii  iptables 1.8.7-1
ii  libc62.31-12
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libgpgme11   1.14.0-1+b2
ii  libseccomp2  2.5.1-1
ii  runc 1.0.0~rc93+ds1-5

Versions of packages podman recommends:
ii  buildah   1.19.6+dfsg1-1+b2
ii  fuse-overlayfs1.4.0-1
ii  golang-github-containernetworking-plugin-dnsname  1.1.1+ds1-4+b4
ii  slirp4netns   1.0.1-2
ii  tini  0.19.0-1
ii  uidmap1:4.8.1-1

Versions of packages podman suggests:
pn  containers-storage  
ii  docker-compose  1.25.0-1

-- no debconf information

Bug#989410: nss breaks dogtag-pki autopkgtest on ppc64el: [SSL: LENGTH_MISMATCH] length mismatch (_ssl.c:1123)

[Paul Gevers]

Source: nss, dogtag-pki
Control: found -1 nss/2:3.66-1
Control: found -1 dogtag-pki/10.10.2-3
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
nssfrom testing2:3.66-1
dogtag-pki from testing10.10.2-3
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/ppc64el/d/dogtag-pki/12741349/log.gz

autopkgtest [18:46:23]: test pkispawn: [---
 IP address is 192.168.122.76
 Hostname was:
 /etc/hosts now has:
127.0.0.1   localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

192.168.122.76 autopkgtest.debci autopkgtest
Starting installation...
Completed installation for pki-tomcat
Notice: Trust flag u is set automatically if the private key is present.
ERROR: SSLError: HTTPSConnectionPool(host='autopkgtest.debci',
port=8443): Max retries exceeded with url: /ca/rest/installer/setupCert
(Caused by SSLError(SSLError(1, '[SSL: LENGTH_MISMATCH] length mismatch
(_ssl.c:1123)')))
  File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line
575, in main
scriptlet.spawn(deployer)
  File
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
line 995, in spawn
cert = deployer.setup_cert(client, tag)
  File
"/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py", line
355, in setup_cert
return client.setupCert(request)
  File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in
setupCert
response = self.connection.post(
  File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
return func(self, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
r = self.session.post(
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590,
in post
return self.request('POST', url, data=data, json=json, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542,
in request
resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655,
in send
r = adapter.send(request, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 514,
in send
raise SSLError(e, request=request)

Loading deployment configuration from debian/tests/deploy.cfg.
Installation log: /var/log/pki/pki-ca-spawn.20210602184645.log
Installing CA into /var/lib/pki/pki-tomcat.

Installation failed: HTTPSConnectionPool(host='autopkgtest.debci',
port=8443): Max retries exceeded with url: /ca/rest/installer/setupCert
(Caused by SSLError(SSLError(1, '[SSL: LENGTH_MISMATCH] length mismatch
(_ssl.c:1123)')))

 CA spawn failed:
2021-06-02 18:47:26 ERROR: SSLError:
HTTPSConnectionPool(host='autopkgtest.debci', port=8443): Max retries
exceeded with url: /ca/rest/installer/setupCert (Caused by
SSLError(SSLError(1, '[SSL: LENGTH_MISMATCH] length mismatch
(_ssl.c:1123)')))
  File "/usr/lib/python3/dist-packages/pki/server/pkispawn.py", line
575, in main
scriptlet.spawn(deployer)
  File
"/usr/lib/python3/dist-packages/pki/server/deployment/scriptlets/configuration.py",
line 995, in spawn
cert = deployer.setup_cert(client, tag)
  File
"/usr/lib/python3/dist-packages/pki/server/deployment/__init__.py", line
355, in setup_cert
return client.setupCert(request)
  File "/usr/lib/python3/dist-packages/pki/system.py", line 389, in
setupCert
response = self.connection.post(
  File "/usr/lib/python3/dist-packages/pki/client.py", line 55, in wrapper
return func(self, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/pki/client.py", line 293, in post
r = self.session.post(
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 590,
in post
return self.request('POST', url, data=data, json=json, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542,
in request
resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655,
in send
r = adapter.send(request, 

Bug#989404: wtf: Very outdated; missing entries such as LGTM

[Alejandro Colomar (man-pages)]

Hi Bruno,

On 6/3/21 8:00 AM, Bruno Kleinert wrote:

I cannot reproduce your report, maybe you had a typo in the command?

The wtf query on a sid/unstable works:

fuddl@flutschi  :~$ dpkg-query -W -f '${Version}\n' 
bsdgames

2.17-28

fuddl@flutschi  :~$ wtf lgtm

LGTM: looks good to me


Yes, it looks like I had a typo... those that you try many times and 
have a look at them and you don't realize...

Now I tried and yes, it works.  Black magic :)


Invalid bug. EBCAK.

Cheers,

Alex

--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/

Bug#979614: seamly2d: virtually dead fork of valentina

[dismine]

Hi,

My name is Roman, and I am the developer of the Valentina project.

> Seamly2D is a fork of Valentina.

Technically it is not true. I have left the original project. Thus, current
Valentina is a fork of what is left of Valentina after rename.

> well, compared to valentina it seems to have way more pull requests and
is at least very responsive to requests.

Technically this may be true. Don't follow their code base anymore. But I
know better than most what it takes to add a really significant change. I
don't know what do you mean by "very responsive to requests" when they
cannot deliver any significant feature. How they can cover any need of
pattern maker except of kind words? If low number of PRs and slow progress
was caused by me back then, then why do we have this bug report? Something
is not right here.

Do you know a list of changes to Valentina since the fork? Can you compare
two lists for the projects? Do you think some small PRs can beat a
number of my changes?

> I think keeping one of them in Debian is the better option.

Before doing this, please check if the packages will be compatible. I mean,
there is a chance we still use the same names of libraries. I don't care
much about versions of internal libraries. Thus, S2D can rely on the same
library name, but on API/ABI level they will not be compatible with
Valentina.

> Any idea why there is a fork at all?

Susan and I have different points of view on how to develop the project.
Plus there must be only one leader. I am more than happy that I have made a
fork.

> Seems to me that Seamly2D is similarly a one-woman-show - difference
(disregarding sexes) being that one is good with code and the other is good
with words and people.

I must admit that she is a very passionate woman in what she does. PR is
her strong side, not mine. I have realized that trying to explain people
that S2D is "dead" without developers is pointless for people who don't
understand the importance of developers and expertise. They see good people
around with promises of a bright future. How long you can lie to people
like this? Well quite long, up to 4 years. My solution? Don't waist time on
talking. Show them real progress and real pattern making application.

> I was hoping that the strong community of Seamly2D would lead to more
sample documents than the relatively few shipped with Valentina

I have ideas why people are not willing to share their patterns. Pattern
makers at all are very far from open source and participating in it. They
mostly care about making patterns and asking for features. A complete
separate world to what I had expected.

> But I might be wrong.  Or maybe code is largely "done" and only _need_
smaller polishing.

What? No! Code is far from "done". S2D just struggled to find a developer.
It would be interesting to see how they would manage to port code to Qt 6.
:)

> Was probably easy as the valentina-project page points to seamly now,
which is rather sad.

Susan controlled a forum and the project web page. No way she would give me
opportunity to win in PR war. :D

> I also gave that a try: and they are not compatible anymore, although

> seamly still says valentina format. Which is.. stupid.

This is something new for me. I did not have reports from users. Don't plan
to fix, though.

> "Susan Spencer got the valentina-project.org domain name and the website
as part of the separation deal."

It was a divorce. I was a gentleman and left my "wife" a house, a car, our
dog and our bugs. But not my expertise and my name.

- Roman

Bug#983095: pidgin: 5353/udp probe every 2 sec

[Richard Laager]

On 5/16/21 7:50 PM, Richard Laager wrote:

So it's happening in a child process.


Gary had an idea here... Pidgin generally only uses child processes for 
DNS. Is it possible that you have some NSS plugin that is doing this?


Specifically, do you have libnss-mdns installed? I do, and I still can't 
reproduce the problem. But maybe you can try removing it to see if that 
fixes it? (Obviously, you can reinstall it either way.)


--
Richard

Bug#989404: wtf: Very outdated; missing entries such as LGTM

[Bruno Kleinert]

> Today I wanted to know what LGTM means.  I didn't find it with wtf(1),
> so I went looking for the upstream source code to try to patch it.

Hi  Alex,

I cannot reproduce your report, maybe you had a typo in the command?

The wtf query on a sid/unstable works:

fuddl@flutschi:~$ dpkg-query -W -f '${Version}\n' bsdgames
2.17-28
fuddl@flutschi:~$ wtf lgtm
LGTM: looks good to me

Cheers,
Bruno



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