Bug#1007234: Test suite fails on all but amd64 arches

[Bryan Henderson]

I haven't heard of this before.

I'm sure this is easy to diagnose for someone who can reproduce it.  I can't,
since I don't have access to a system other than AMD64.

I can tell from reading the code that what is happening is there is a
a negative number somewhere that there shouldn't be.  My best guess is that
the 2's complement arithmetic hack for interpreting the run-length-encoding
in the function 'readPackBitsRow16' in converter/other/pnmtopalm/palmtopnm.c
isn't doing what it's expected to do.  In particular, the line

  int const signedIncount = (signed char)incountByte

might be declaring a positive number, whereas it's supposed to be negative
(which means -signedIncount below is negative whereas it is expected to be
positive).

-- 
Bryan Henderson   San Jose, California

Bug#991541: Related merge request

[Marco Villegas]

Dear maintainer,

I have added a related merge request on salsa fast-forwarding the
related git sub-module to the fixed version.
https://salsa.debian.org/php-team/pear/php-pear/-/merge_requests/3

Not entirely sure if gitlab is the best route to help in this package
case, but since I saw a couple of MRs closed, I decided to go that way.

Let me know if other changes would be needed, or any other feedback,

Best,

-Marco

Bug#1007959: uftrace: Intent to NMU

[paul cannon]

On Sat, Mar 19, 2022 at 01:42:03PM +, Fukui Daichi wrote:
> I've prepared an NMU [0] for uftrace (0.9.4-0.2) and would like to upload it 
> to DELAYED/7 though the maintainer lists himself in the low threshold nmu 
> list.
> 
> This patch is a new upstream release (0.11-0.1) and adjusts the existing 
> patch accordingly.
> Having said that, it looks like Gurkan had already uploaded an experimental 
> one [1].
> 
> Is this patch still helpful?

This looks like good work! But we've gotten ourselves into a bit of a
problem with respect to the package; Gürkan didn't realize I already had
packaging tracked on Github, and started a Git structure from scratch,
so it redoes history. I'm going to try to figure out how to stop a
package from experimental from being promoted to unstable and roll a
0.11-2 package.

Your changes might be helpful ones; I'll be able to tell more easily
once I have history straightened out more!

Paul Cannon

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

[Adam Williamson]

Just reporting I found the same problem on Fedora 36. Filed here:
https://bugzilla.redhat.com/show_bug.cgi?id=2066527 .
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

Bug#1007899: network-manager: L2TP-VPN doesn't work with network-manager version 1.36.2-1 (works with 1.34.0-1)

[Douglas Kosovic]

I suspect this is the same as the following upstream NetworkManager 1.36.2
routing bug:
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/946

I assume you have enabled the "Use this connection only for resources on
its network" checkbox in the VPN connection's IPv4 settings? In which
case network-manager 1.36.2 doesn't appear to be adding any routes for
the VPN connection like it does if the checkbox isn't enabled or did
with earlier versions of NetworkManager.

Bug#1008076: network-manager-pptp-gnome: debianTim gnome-shell[2856]: Object 0x7ff6d80d16f0 of type IBusText has been finalized while it was still owned by gjs, this is due to invalid memory managemen

[Tim McConnell]

Package: network-manager-pptp-gnome
Version: 1.2.10-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation? attempting to create a VPN
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Tried adding the VPN multiple ways, none works
   * What was the outcome of this action? VPN either immeadiat;y fails
or runs
for a minute then fails with title
   * What outcome did you expect instead? A working VPN

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


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

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

Versions of packages network-manager-pptp-gnome depends on:
ii  libc6 2.33-7
ii  libglib2.0-0  2.70.4-1
ii  libgtk-3-0    3.24.33-1
ii  libnm0    1.36.2-1
ii  libnma0   1.8.34-1
ii  libsecret-1-0 0.20.5-2
ii  network-manager-pptp  1.2.10-1

network-manager-pptp-gnome recommends no packages.

network-manager-pptp-gnome suggests no packages.

-- no debconf information

Bug#1008075: 0ad: Apply patches from Ubuntu to fix build with glibc 2.35 & python 3.10

[Jeremy Bicha]

Source: 0ad
Version: 0.0.25b-1.1
Tags: +patch

Please consider applying these changes from Ubuntu to fix 0ad's build
with python3 3.10 and glibc 2.35

https://launchpadlibrarian.net/590597657/0ad_0.0.25b-1.1_0.0.25b-1.1ubuntu1.diff.gz

Thank you,
Jeremy Bicha

Bug#1007167: Already fixed upstream

[Rodolfo Ribeiro Gomes]

This issue was fixed in 1.4.2 via this commit:
https://github.com/synfig/synfig/commit/e68ca6ff55a6d6f86220d187bc5df27633382397

Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Sebastian Andrzej Siewior]

On 2022-03-21 22:11:17 [+0100], Julien Cristau wrote:
> Hi,
Hi,

> Specifically, we were hoping to better understand the risk of openssl
> changes breaking existing setups.  It's possible the issues with gnutls
> and libnet-ssleay-perl tests were narrowly scoped enough that that risk
> is low, but we're just not sure right now.  Other input would be
> welcome.

No matter how it turns out, I'm fine with it.
It would be nice in in case of postponing it, to keep in pu for the
following point release so that it receives more test coverage. [Unless
of course if this means that the pu is canceled.]

> Thanks,
> Julien

Sebastian

Bug#1008062: buster-pu: package gnutls28/3.6.7-4+deb10u7.1

[Sebastian Andrzej Siewior]

On 2022-03-21 22:04:08 [+0100], Salvatore Bonaccorso wrote:
> Hi Sebastian,
Hi Salvatore,

> > +gnutls28 (3.6.7-4+deb10u7.1) buster; urgency=medium
> 
> As not yet uploaded, can you change this to 3.6.7-4+deb10u8 instead.

Just did so.

> Regards,
> Salvatore

Sebastian

Bug#810018: Bug #810018: Consider shipping pidof with procps

[Josh Triplett]

On Mon, Mar 21, 2022 at 02:01:14PM +0100, Andreas Henriksson wrote:
> On Mon, Mar 21, 2022 at 10:34:58AM +, Mark Hindley wrote:
> > Craig,
> > 
> > Thanks for this.
> > 
> > This dates from before my detailed involvement with this area of Debian. I 
> > have
> > read through the bug report, but apologies if I have missed pertinent 
> > detail.
> []
> >  3) A desire to reduce the Essential set.
> > 
> > I understand and appreciate the general motivation for this. However, 
> > moving
> > pidof to procps would make procps Essential and it is already about 20 
> > times
> > bigger than sysvinit-utils, so it does not achieve the aim.
> [...]
> 
> I don't see why you think pidof (and thus entire procps) must be
> Essential. That would indeed be counter-productive. (I haven't re-read
> the discussion, but I'm pretty sure we already covered this.)
> 
> As I've already proven elsewhere sysvinit-utils (with or without pidof,
> which AFAIR is the only semi-useful utility left in that binary package)
> can be made non-essential without any problems already.
> 
> > What do you think?
> 
> I think apart from reducing the essential set, it is also useful to
> eliminate pointless differences.
> 
> The distributions I've looked at (that are not just following along as a
> debian derivate) uses procps pidof already.

Exactly. And there have already been issues in which pidof's behavior
changed in unexpected ways because of the needs of sysvinit (e.g.
https://bugs.debian.org/926896 ). Decoupling the two makes such issues
less likely, and removes the one way in which systems not otherwise
using sysvinit have a dependency on sysvinit components.

I wouldn't expect procps to become essential; ideally packages that use
pidof in scripts would add an appropriate dependency. (This would help
people building minimal containers/chroots.) But orthogonally, I think
there's value in migrating pidof to procps.

Bug#1008056: buster-pu: package libnet-ssleay-perl/1.85-2.1

[Adrian Bunk]

Control: retitle -1 buster-pu: package libnet-ssleay-perl/1.85-2+deb10u1

On Mon, Mar 21, 2022 at 10:02:15PM +0100, Salvatore Bonaccorso wrote:
> Hi Adrian,

Hi Salvatore,

> On Mon, Mar 21, 2022 at 05:55:00PM +0200, Adrian Bunk wrote:
> > --- libnet-ssleay-perl-1.85/debian/changelog2018-09-02 
> > 23:19:51.0 +0300
> > +++ libnet-ssleay-perl-1.85/debian/changelog2022-03-21 
> > 17:36:31.0 +0200
> > @@ -1,3 +1,11 @@
> > +libnet-ssleay-perl (1.85-2.1) buster; urgency=medium
> 
> Minor "nitpick" on the version, but to be consistent I would use
> 1.85-2+deb10u1 (as well for avoid a hypotetical existing 1.85-2.1 in a
> previous unstable upload).

thanks for noticing, updated.

> Regards,
> Salvatore

cu
Adrian

diff -Nru libnet-ssleay-perl-1.85/debian/changelog 
libnet-ssleay-perl-1.85/debian/changelog
--- libnet-ssleay-perl-1.85/debian/changelog2018-09-02 23:19:51.0 
+0300
+++ libnet-ssleay-perl-1.85/debian/changelog2022-03-21 17:36:31.0 
+0200
@@ -1,3 +1,11 @@
+libnet-ssleay-perl (1.85-2+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fix for test failures with OpenSSL 1.1.1n.
+(Closes: #1008055)
+
+ -- Adrian Bunk   Mon, 21 Mar 2022 17:36:31 +0200
+
 libnet-ssleay-perl (1.85-2) unstable; urgency=medium
 
   [ Damyan Ivanov ]
diff -Nru 
libnet-ssleay-perl-1.85/debian/patches/0001-Use-2048-bit-RSA-keys-certificates-in-tests.patch
 
libnet-ssleay-perl-1.85/debian/patches/0001-Use-2048-bit-RSA-keys-certificates-in-tests.patch
--- 
libnet-ssleay-perl-1.85/debian/patches/0001-Use-2048-bit-RSA-keys-certificates-in-tests.patch
   1970-01-01 02:00:00.0 +0200
+++ 
libnet-ssleay-perl-1.85/debian/patches/0001-Use-2048-bit-RSA-keys-certificates-in-tests.patch
   2022-03-21 17:36:17.0 +0200
@@ -0,0 +1,714 @@
+From d7b8428e7810f5e1729a197a076df0226b509fab Mon Sep 17 00:00:00 2001
+From: Chris Novakovic 
+Date: Wed, 1 May 2019 10:24:02 +0100
+Subject: Use 2048-bit RSA keys/certificates in tests
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The test suite makes heavy use of t/data/key.pem and t/data/cert.pem,
+which involves the use of 1024-bit RSA keys. Several Linux distributions
+now ship with an OpenSSL configuration file that sets the security level
+to 2 by default, which forbids the use of keys this short, causing tests
+that use them to fail.
+
+The test suite includes 2048-bit RSA keys and certificates
+(t/data/testcert_key_2048.pem and t/data/testcert_wildcard.crt.pem
+respectively), which are already in use in some (usually newer) tests.
+Retire the 1024-bit keys in favour of the 2048-bit keys:
+
+* Replace all remaining uses of t/data/key.pem in the test suite with
+  t/data/testcert_key_2048.pem.
+* Create t/data/testcert_key_2048.pem.e (testcert_key_2048.pem encrypted
+  with AES-256-CBC using the passphrase "secret") and replace all
+  remaining uses of t/data/key.pem.e in the test suite with
+  testcert_key_2048.pem.e.
+* Replace all remaining uses of t/data/cert.pem in the test suite with
+  t/data/testcert_wildcard.crt.pem.
+* Create 2048-bit CA key at t/data/test_CA1_2048.key.pem and
+  certificates at t/data/test_CA1_2048.crt.pem and
+  t/data/testcert_wildcard_CA1_2048.crt.pem, and use them in
+  t/local/07_sslecho.t and t/local/36_verify.t in place of the 1024-bit
+  CA keys/certificates. Thanks to Heikki Vatiainen for debugging and
+  fixing this.
+* Remove the digest check for t/data/cert.pem in t/local/50_digest.t
+  altogether: the same digests for t/data/binary-test.file are already
+  tested, and it's not clear what benefit another one provides.
+* In t/local/07_sslecho.t, don't make assumptions about the chain of
+  trust for the certificates being used; this breaks the tests when
+  keys/certificates other than the old 1024-bit ones are used. Thanks to
+  Heikki Vatiainen for debugging and fixing this.
+* Remove references to t/data/key.pem and t/data/cert.pem from the
+  Net::SSLeay documentation (they probably shouldn't have been there
+  anyway).
+* Remove the calls to Net::SSLeay::CTX_set_security_level(..., 1) from
+  all tests that used t/data/key.pem and t/data/cert.pem, since the new
+  key/certificate will work at security level 2, and no OS is currently
+  known to mandate a higher security level than this - setting the
+  security level in this way was a temporary fix for this problem, added
+  in commit d0ee5d91.
+
+This fixes RT#126270 and the remainder of RT#128025. Thanks to Petr
+Písař and Slaven Rezić for the reports.
+---
+ lib/Net/SSLeay.pod|  4 +-
+ t/data/cert.pem   | 23 --
+ t/data/key.pem| 15 
+ t/data/key.pem.e  | 17 -
+ t/data/test_CA1_2048.crt.pem  | 20 +
+ t/data/test_CA1_2048.key.pem  | 28 +++
+ t/data/testcert_key_2048.pem.e| 30 
+ 

Bug#1008072: buster-pu: package s390-dasd/0.0.74~deb10u1

[Cyril Brulebois]

Cyril Brulebois  (2022-03-21):
> Hopefully that's fine, but I could understand if you'd prefer
> 0.0.64+deb10u1 with just the dasd-config.c change. At least initially,
> it seemed to make sense to use the same approach for both buster and
> bullseye uploads.

Changes were prepared days ago, forgot the “please open bug reports”
reply from Adam… *and* managed not to spot the bullseye (instead of
buster) in the changelog until after having sent the opu request…

Fixed debdiff attached…


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru s390-dasd-0.0.64/dasd-config.c s390-dasd-0.0.74~deb10u1/dasd-config.c
--- s390-dasd-0.0.64/dasd-config.c	2018-08-10 21:25:00.0 +0200
+++ s390-dasd-0.0.74~deb10u1/dasd-config.c	2022-03-18 13:08:33.0 +0100
@@ -390,7 +390,7 @@
 	debconf_subst (client, TEMPLATE_PREFIX "formatting", "device", channel_current->name);
 	debconf_progress_start (client, 0, drive_geo.cylinders - 1, TEMPLATE_PREFIX "formatting");
 
-	snprintf (buf, sizeof (buf), "dasdfmt -l LX%04x -b 4096 -m 1 -f %s -y", channel_device (channel_current->name), dev);
+	snprintf (buf, sizeof (buf), "dasdfmt -l LX%04x -b 4096 -m 1 %s -y", channel_device (channel_current->name), dev);
 	ret = di_exec_shell_full (buf, format_handler, NULL, NULL, NULL, NULL, NULL, NULL);
 
 	debconf_progress_stop (client);
diff -Nru s390-dasd-0.0.64/debian/changelog s390-dasd-0.0.74~deb10u1/debian/changelog
--- s390-dasd-0.0.64/debian/changelog	2019-05-28 07:41:41.0 +0200
+++ s390-dasd-0.0.74~deb10u1/debian/changelog	2022-03-21 22:24:45.0 +0100
@@ -1,3 +1,112 @@
+s390-dasd (0.0.74~deb10u1) buster; urgency=medium
+
+  * Rebuild for buster.
+
+ -- Cyril Brulebois   Mon, 21 Mar 2022 22:24:45 +0100
+
+s390-dasd (0.0.74) unstable; urgency=medium
+
+  [ Dipak Zope ]
+  * Stop passing deprecated -f option to dasdfmt, which was dropped in
+s390-tools 1.37.1-1 (Closes: #1004292).
+
+ -- Cyril Brulebois   Fri, 18 Mar 2022 13:12:26 +0100
+
+s390-dasd (0.0.73) unstable; urgency=medium
+
+  * Team upload
+
+  [ Updated translations ]
+  * Finnish (fi.po) by Kimmo Kujansuu
+
+ -- Holger Wansing   Fri, 23 Jul 2021 19:30:21 +0200
+
+s390-dasd (0.0.72) unstable; urgency=medium
+
+  * Team upload
+
+  [ Updated translations ]
+  * Lithuanian (lt.po) by Gediminas Murauskas
+
+ -- Holger Wansing   Thu, 08 Jul 2021 23:38:27 +0200
+
+s390-dasd (0.0.71) unstable; urgency=medium
+
+  * Team upload
+
+  [ Updated translations ]
+  * Arabic (ar.po) by Fahim Sabah
+
+ -- Holger Wansing   Tue, 01 Jun 2021 21:05:44 +0200
+
+s390-dasd (0.0.70) unstable; urgency=medium
+
+  * Team upload
+
+  [ Updated translations ]
+  * Lithuanian (lt.po) by Kornelijus Tvarijanavičius
+
+ -- Holger Wansing   Fri, 02 Apr 2021 12:10:09 +0200
+
+s390-dasd (0.0.69) unstable; urgency=medium
+
+  * Team upload
+
+  [ Updated translations ]
+  * Greek (el.po) by george k
+  * Hindi (hi.po) by KushagraKarira
+  * Kabyle (kab.po) by Selyan Sliman Amiri
+  * Tamil (ta.po) by Vasudevan Tirumurti
+
+ -- Holger Wansing   Sat, 20 Feb 2021 19:26:43 +0100
+
+s390-dasd (0.0.68) unstable; urgency=medium
+
+  * Team upload
+
+  [ Philipp Kern ]
+  * Remove myself from uploaders.
+
+  [ Updated translations ]
+  * Occitan (oc.po) by Quentin PAGÈS
+
+ -- Philipp Kern   Sun, 27 Dec 2020 14:30:11 +0100
+
+s390-dasd (0.0.67) unstable; urgency=medium
+
+  * Team upload
+
+  [ Updated translations ]
+  * Basque (eu.po) by Iñaki Larrañaga Murgoitio
+  * Persian (fa.po) by Seyed Hany Hosseini
+  * Norwegian Bokmal (nb.po) by Allan Nordhøy
+  * Serbian (sr.po) by Filipovic Dragan
+
+  [ New translations ]
+  * Kabyle (kab.po) by Slimane Selyan Amiri
+  * Occitan (oc.po) by Quentin PAGÈS
+
+ -- Holger Wansing   Fri, 06 Nov 2020 18:48:50 +0100
+
+s390-dasd (0.0.66) unstable; urgency=medium
+
+  * Team upload
+
+  [ Updated translations ]
+  * Marathi (mr.po) by Prachi Joshi
+
+ -- Holger Wansing   Sat, 07 Mar 2020 21:31:15 +0100
+
+s390-dasd (0.0.65) unstable; urgency=medium
+
+  * Team upload
+
+  [ Updated translations ]
+  * Croatian (hr.po) by gogogogi
+  * Portuguese (pt.po) by Miguel Figueiredo
+
+ -- Holger Wansing   Wed, 13 Nov 2019 23:43:24 +0100
+
 s390-dasd (0.0.64) unstable; urgency=medium
 
   * Team upload
diff -Nru s390-dasd-0.0.64/debian/control s390-dasd-0.0.74~deb10u1/debian/control
--- s390-dasd-0.0.64/debian/control	2018-11-25 21:19:34.0 +0100
+++ s390-dasd-0.0.74~deb10u1/debian/control	2021-02-08 13:55:26.0 +0100
@@ -2,7 +2,7 @@
 Section: debian-installer
 Priority: standard
 Maintainer: Debian Install System Team 
-Uploaders: Bastian Blank , Philipp Kern 
+Uploaders: Bastian Blank 
 Build-Depends: debhelper (>= 9), po-debconf (>= 0.5.0), libsysfs-dev, libdebconfclient0-dev (>=0.47), libdebian-installer-dev
 Vcs-Browser: https://salsa.debian.org/installer-team/s390-dasd
 Vcs-Git: https://salsa.debian.org/installer-team/s390-dasd.git
diff 

Bug#1008074: bullseye-pu: package s390-dasd/0.0.74~deb11u1

[Cyril Brulebois]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Dipak Zope1 

Hi,

Dipak Zope was kind enough to dig into s390x issues, and found s390-dasd
to be the missing piece in bullseye. I'm therefore proposing this change
to unbreak s390-dasd.

[ Reason ]

An option was dropped from a CLI tool that gets called in the installer
context, and we didn't remove it from our execve call.

[ Impact ]

Formatting fails on s390x systems.

[ Tests ]

Dipak Zope did the testing, and has an @ibm.com address, which sounds
good enough for me. :)

[ Risks ]

It cannot work without the fix.

[ 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 stable
  [x] the issue is verified as fixed in unstable

This is a trivial backport of the package uploaded to unstable a few
days ago.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru s390-dasd-0.0.73/dasd-config.c s390-dasd-0.0.74~deb11u1/dasd-config.c
--- s390-dasd-0.0.73/dasd-config.c  2020-10-24 15:22:32.0 +0200
+++ s390-dasd-0.0.74~deb11u1/dasd-config.c  2022-03-18 13:08:33.0 
+0100
@@ -390,7 +390,7 @@
debconf_subst (client, TEMPLATE_PREFIX "formatting", "device", 
channel_current->name);
debconf_progress_start (client, 0, drive_geo.cylinders - 1, 
TEMPLATE_PREFIX "formatting");
 
-   snprintf (buf, sizeof (buf), "dasdfmt -l LX%04x -b 4096 -m 1 -f %s -y", 
channel_device (channel_current->name), dev);
+   snprintf (buf, sizeof (buf), "dasdfmt -l LX%04x -b 4096 -m 1 %s -y", 
channel_device (channel_current->name), dev);
ret = di_exec_shell_full (buf, format_handler, NULL, NULL, NULL, NULL, 
NULL, NULL);
 
debconf_progress_stop (client);
diff -Nru s390-dasd-0.0.73/debian/changelog 
s390-dasd-0.0.74~deb11u1/debian/changelog
--- s390-dasd-0.0.73/debian/changelog   2021-07-23 19:30:21.0 +0200
+++ s390-dasd-0.0.74~deb11u1/debian/changelog   2022-03-18 13:15:56.0 
+0100
@@ -1,3 +1,17 @@
+s390-dasd (0.0.74~deb11u1) bullseye; urgency=medium
+
+  * Rebuild for bullseye.
+
+ -- Cyril Brulebois   Fri, 18 Mar 2022 13:15:56 +0100
+
+s390-dasd (0.0.74) unstable; urgency=medium
+
+  [ Dipak Zope ]
+  * Stop passing deprecated -f option to dasdfmt, which was dropped in
+s390-tools 1.37.1-1 (Closes: #1004292).
+
+ -- Cyril Brulebois   Fri, 18 Mar 2022 13:12:26 +0100
+
 s390-dasd (0.0.73) unstable; urgency=medium
 
   * Team upload

Bug#1008063: transition: nodejs

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-03-21 18:54:38 +0100, Jérémy Lal wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: Debian Javascript Maintainers 
> 
> 
> Hi,
> 
> this transition correspond to a nodejs 12 -> 14 major major bump.
> 
> I carefully checked (twice, actually) that all build-dependencies of
> - libnode-dev (arch-dependent)
> - nodejs (arch-independent)
> can be rebuilt using latest libnode-dev / nodejs, though of course
> only the arch-dependent ones are concerned by this transition.

Please go ahead

Cheers

> 
> Ben file:
> 
> title = "nodejs";
> is_affected = .depends ~ "libnode72" | .depends ~ "libnode83";
> is_good = .depends ~ "libnode83";
> is_bad = .depends ~ "libnode72";
> 
> Thank you for considering.
> 
> Jérémy

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1006944: transition: proj

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-03-08 18:11:58 +0100, Bas Couwenberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
> Control: block -1 by 998833
> Control: forwarded -1 
> https://release.debian.org/transitions/html/auto-proj.html
> 
> For the Debian GIS team I'd like to transition to PROJ 9.
> 
> Unlike previous transitions, no major breaking changes were introduced.
> 
> Everything except mysql-workbench built successfully as summarized below.
> 
> 
> Transition: proj
> 
>  libproj22 (8.2.1-1) -> libproj25 (9.0.0-1~exp2)
> 
> The status of the most recent rebuilds is as follows.
> 
>  atlas-ecmwf (0.27.0-1) OK
>  gammaray(2.11.2-2) OK
>  libgeotiff  (1.7.0-2)  OK
>  mshr(2019.2.0~git20200924.c27eb18+dfsg1-7) OK
>  octave-octproj  (2.0.1-5)  OK
>  osm2pgsql   (1.6.0+ds-1)   OK
>  pdl (1:2.076-1)OK
>  proj-rdnap  (2008+2018-5)  OK
>  python-pyproj   (3.3.0-2)  OK
>  spatialite  (5.0.1-2)  OK
>  survex  (1.4.2-1)  OK
>  xygrib  (1.2.6.1-1)OK
> 
>  gdal(3.4.1+dfsg-1) OK
>  gnudatalanguage (1.0.1-3)  OK
>  librasterlite2  (1.1.0~beta1-2)OK
>  magics++(4.10.1-1) OK
>  python-cartopy  (0.20.2+dfsg-1)OK
>  spatialite-tools(5.0.1-1)  OK
>  xastir  (2.1.6-4)  OK
> 
>  cdo (2.0.4-1)  OK
>  grass   (7.8.7-1)  OK
>  mapnik  (3.1.0+ds-1)   OK
>  mapserver   (7.6.4-2)  OK
>  merkaartor  (0.19.0+ds-2)  OK
>  metview (5.14.1-1) OK
>  mysql-workbench (8.0.26+dfsg-1)FTFBS 
> (#998833)
>  ncl (6.6.2-10) OK
>  openorienteering-mapper (0.9.5-3)  OK
>  pdal(2.3.0+ds-2)   OK
>  postgis (3.2.1+dfsg-1) OK
>  qmapshack   (1.16.1-1) OK
>  r-cran-rgdal(1.5-28+dfsg-1)OK
>  r-cran-sf   (1.0-6+dfsg-1) OK
>  r-cran-terra(1.5-21-2) OK
>  saga(7.3.0+dfsg-7) OK
>  spatialite-gui  (2.1.0~beta1-1)OK
>  sumo(1.12.0+dfsg1-1)   OK
>  vtk7(7.1.1+dfsg2-10.1) OK
>  vtk9(9.1.0+really9.1.0+dfsg2-3)OK
> 
>  freecad (0.19.4+dfsg1-1)   OK
>  qgis(3.22.4+dfsg-3)OK
>  r-cran-lwgeom   (0.2-8-1)  OK
>  therion (6.0.5-2)  OK

Please go ahead

Cheers

> 
> 
> Kind Regards,
> 
> Bas
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1006293: bullseye-pu: package plasma-desktop/4:5.20.5-4

[Patrick Franz]

Hi,

On Fri, 18 Mar 2022 16:22:56 +0100 Julien Cristau  
wrote:
[...]
> Can you clarify the issue and how the 3 affected packages interact?  
The
> mailing list links seem to talk about plasma-discover's KNS backend so 
I guess
> I understand that part, how are plasma-desktop and knewstuff involved?

knewstuff is the framework that actually downloads the data. The patch 
for that package changes the URL from which updates are downloaded as 
updates were fetched from the "wrong" URL.

plasma-desktop triggers the process to check for updates.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1008073: lp-solve: New upstream release (5.5.2.11, 2020-12-31)

[Florian Ernst]

Package: lp-solve
Version: 5.5.2.5-2
Severity: wishlist

Dear maintainer,

there are two new upstream releases available, cf.
.

The attached debian/watch provides a start to allow uscan to detect them
and to download the new upstream tarballs.

Please update the package when you think it is due time.

Cheers,
Flo
version=4
https://sf.net/lpsolve/ \
lp_solve_@ANY_VERSION@_source@ARCHIVE_EXT@ debian
opts="component=doc" https://sf.net/lpsolve/ \
lp_solve_@ANY_VERSION@_doc@ARCHIVE_EXT@ same uupdate


signature.asc
Description: PGP signature

Bug#1007141: BUG Report - OCFS2 Hangs when mount volume in second node

[Valentin Vidic]

On Sun, Mar 13, 2022 at 03:19:55PM +0100, Valentin Vidic wrote:
> Thanks for the report, I will try to reproduce the problem with the
> versions in unstable, but it would be good if you could share the errors
> that are being reported and perhaps also the cluster configuration for
> reproducing this problem.

Ok, it seems I can reproduce the problem with linux-image-5.16.0-4-amd64
(5.16.12-1) and ocfs2-tools (1.8.7-1). It is caused by FS features
usrquota and grpquota enabled by --fs-feature-level=max-features. If
these are not enabled the filesystem mounts without problems. Otherwise
the error is as follows:

[  389.111864] ocfs2: Mounting device (254,16) on (node 2, slot 0) with ordered 
data mode.
[  389.160182] BUG: kernel NULL pointer dereference, address: 0398
[  389.160295] #PF: supervisor read access in kernel mode
[  389.160343] #PF: error_code(0x) - not-present page
[  389.160390] PGD 0 P4D 0 
[  389.160432] Oops:  [#1] PREEMPT SMP PTI
[  389.160477] CPU: 0 PID: 836 Comm: mount.ocfs2 Not tainted 5.16.0-4-amd64 #1  
Debian 5.16.12-1
[  389.160591] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
1.14.0-2 04/01/2014
[  389.160714] RIP: 0010:ocfs2_qinfo_lock_res_init+0x44/0x50 [ocfs2]
[  389.161290] Code: 00 00 00 48 63 b3 b8 01 00 00 e8 87 bb ff ff 49 89 d8 48 
89 ee ba 08 00 00 00 48 8b 83 b0 01 00 00 48 c7 c1 a0 e0 dc c0 5b 5d <48> 8b b8 
98 03 00 00 e9 70 c4 ff ff 0f 1f 44 00 00 41 56 41 89 ce
[  389.161460] RSP: 0018:b2c0c0047be8 EFLAGS: 00010282
[  389.161510] RAX:  RBX:  RCX: c0dce0a0
[  389.161619] RDX: 0008 RSI: 8b685c343c30 RDI: b2c0c0047bb8
[  389.161747] RBP: 8b685c343c00 R08: 8b685c343c00 R09: 
[  389.161809] R10: b2c0c0047bb0 R11: c0d8f030 R12: 8b685c343c18
[  389.161868] R13: 8b68462d3ec8 R14:  R15: 8b6848fb6800
[  389.161929] FS:  7f7956901c00() GS:8b687ec0() 
knlGS:
[  389.162009] CS:  0010 DS:  ES:  CR0: 80050033
[  389.162060] CR2: 0398 CR3: 0554a004 CR4: 00370ef0
[  389.162129] Call Trace:
[  389.162184]  
[  389.162211]  ocfs2_local_read_info+0xb9/0x6f0 [ocfs2]
[  389.162479]  ? ocfs2_local_check_quota_file+0x197/0x390 [ocfs2]
[  389.162774]  dquot_load_quota_sb+0x216/0x470
[  389.162849]  ? preempt_count_add+0x68/0xa0
[  389.162895]  dquot_load_quota_inode+0x85/0x100
[  389.162943]  ocfs2_enable_quotas+0xa0/0x1c0 [ocfs2]
[  389.163151]  ocfs2_fill_super.cold+0xc8/0x1bf [ocfs2]
[  389.163374]  mount_bdev+0x185/0x1b0
[  389.163431]  ? ocfs2_initialize_super.isra.0+0xf40/0xf40 [ocfs2]
[  389.163673]  legacy_get_tree+0x27/0x40
[  389.163726]  vfs_get_tree+0x25/0xb0
[  389.163764]  path_mount+0x465/0xac0
[  389.163804]  __x64_sys_mount+0x103/0x140
[  389.163844]  do_syscall_64+0x3b/0xc0
[  389.163919]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  389.164016] RIP: 0033:0x7f7956e0258a
[  389.164057] Code: 48 8b 0d e9 28 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 
0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d b6 28 0d 00 f7 d8 64 89 01 48
[  389.164206] RSP: 002b:7fff9be78718 EFLAGS: 0246 ORIG_RAX: 
00a5
[  389.164273] RAX: ffda RBX:  RCX: 7f7956e0258a
[  389.164334] RDX: 55bffbe230ae RSI: 55bffc7ec370 RDI: 55bffc7f33f0
[  389.164395] RBP: 7fff9be788d0 R08: 55bffc7f3390 R09: 7fff9be76110
[  389.164454] R10:  R11: 0246 R12: 55bffbe230ae
[  389.164514] R13: 55bffc7ec301 R14: 7fff9be787c0 R15: 7fff9be78740
[  389.166469]  
[  389.168355] Modules linked in: ocfs2 quota_tree ocfs2_dlmfs ocfs2_stack_o2cb 
ocfs2_dlm ocfs2_nodemanager ocfs2_stackglue sctp ip6_udp_tunnel udp_tunnel 
libcrc32c intel_rapl_msr intel_rapl_common intel_pmc_core_pltdrv intel_pmc_core 
kvm_intel kvm irqbypass ghash_clmulni_intel snd_hda_codec_generic ledtrig_audio 
snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi aesni_intel crypto_simd qxl 
snd_hda_codec cryptd drm_ttm_helper rapl snd_hda_core ttm snd_hwdep snd_pcm 
serio_raw snd_timer iTCO_wdt pcspkr intel_pmc_bxt iTCO_vendor_support 
drm_kms_helper snd virtio_rng rng_core soundcore virtio_balloon virtio_console 
cec evdev joydev i6300esb rc_core watchdog qemu_fw_cfg button auth_rpcgss 
sunrpc drm fuse configfs ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 
crc32c_generic hid_generic usbhid hid virtio_net net_failover failover 
virtio_blk ahci xhci_pci libahci libata xhci_hcd crct10dif_pclmul 
crct10dif_common crc32_pclmul crc32c_intel virtio_pci virtio_pci_legacy_dev 
virtio_pci_modern_dev
[  389.168645]  virtio psmouse usbcore scsi_mod i2c_i801 i2c_smbus scsi_common 
lpc_ich usb_common virtio_ring
[  389.187016] CR2: 0398
[  389.188963] ---[ end trace 571e3ca036b59855 ]---
[  389.190493] RIP: 0010:ocfs2_qinfo_lock_res_init+0x44/0x50 

Bug#1008072: buster-pu: package s390-dasd/0.0.74~deb10u1

[Cyril Brulebois]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Dipak Zope1 

Hi,

Dipak Zope was kind enough to dig into s390x issues, and found s390-dasd
to be the missing piece in bullseye. I'm therefore proposing this change
to unbreak s390-dasd.

[ Reason ]

An option was dropped from a CLI tool that gets called in the installer
context, and we didn't remove it from our execve call.

[ Impact ]

Formatting fails on s390x systems.

[ Tests ]

Dipak Zope did the testing, and has an @ibm.com address, which sounds
good enough for me. :)

[ Risks ]

It cannot work without the fix.

[ 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 stable
  [x] the issue is verified as fixed in unstable

This is a trivial backport of the package uploaded to unstable a few
days ago. The diff against buster is larger than the one for bullseye
(catching up not only from 0.0.73 to 0.0.74, but from 0.0.64), but
that's mostly about l10n updates (and dropping pkern from Uploaders):

kibi@tokyo:~/debian-installer/packages (master=)$ diffstat -w 80 
s390-dasd+buster.diff 
 dasd-config.c|2 
 debian/changelog |  109 +++
 debian/control   |2 
 debian/po/ar.po  |9 ++
 debian/po/el.po  |   15 ++--
 debian/po/eu.po  |   32 +-
 debian/po/fa.po  |   35 ++-
 debian/po/fi.po  |7 +-
 debian/po/hi.po  |   33 ++
 debian/po/hr.po  |   40 ++---
 debian/po/kab.po |  163 
+
 debian/po/lt.po  |   19 +++---
 debian/po/mr.po  |   23 ---
 debian/po/nb.po  |   13 ++--
 debian/po/oc.po  |  167 
+++
 debian/po/pt.po  |8 +-
 debian/po/sr.po  |6 -
 debian/po/ta.po  |   21 --
 18 files changed, 592 insertions(+), 112 deletions(-)

Hopefully that's fine, but I could understand if you'd prefer
0.0.64+deb10u1 with just the dasd-config.c change. At least initially,
it seemed to make sense to use the same approach for both buster and
bullseye uploads.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
diff -Nru s390-dasd-0.0.64/dasd-config.c s390-dasd-0.0.74~deb10u1/dasd-config.c
--- s390-dasd-0.0.64/dasd-config.c  2018-08-10 21:25:00.0 +0200
+++ s390-dasd-0.0.74~deb10u1/dasd-config.c  2022-03-18 13:08:33.0 
+0100
@@ -390,7 +390,7 @@
debconf_subst (client, TEMPLATE_PREFIX "formatting", "device", 
channel_current->name);
debconf_progress_start (client, 0, drive_geo.cylinders - 1, 
TEMPLATE_PREFIX "formatting");
 
-   snprintf (buf, sizeof (buf), "dasdfmt -l LX%04x -b 4096 -m 1 -f %s -y", 
channel_device (channel_current->name), dev);
+   snprintf (buf, sizeof (buf), "dasdfmt -l LX%04x -b 4096 -m 1 %s -y", 
channel_device (channel_current->name), dev);
ret = di_exec_shell_full (buf, format_handler, NULL, NULL, NULL, NULL, 
NULL, NULL);
 
debconf_progress_stop (client);
diff -Nru s390-dasd-0.0.64/debian/changelog 
s390-dasd-0.0.74~deb10u1/debian/changelog
--- s390-dasd-0.0.64/debian/changelog   2019-05-28 07:41:41.0 +0200
+++ s390-dasd-0.0.74~deb10u1/debian/changelog   2022-03-18 13:16:33.0 
+0100
@@ -1,3 +1,112 @@
+s390-dasd (0.0.74~deb10u1) bullseye; urgency=medium
+
+  * Rebuild for buster.
+
+ -- Cyril Brulebois   Fri, 18 Mar 2022 13:16:33 +0100
+
+s390-dasd (0.0.74) unstable; urgency=medium
+
+  [ Dipak Zope ]
+  * Stop passing deprecated -f option to dasdfmt, which was dropped in
+s390-tools 1.37.1-1 (Closes: #1004292).
+
+ -- Cyril Brulebois   Fri, 18 Mar 2022 13:12:26 +0100
+
+s390-dasd (0.0.73) unstable; urgency=medium
+
+  * Team upload
+
+  [ Updated translations ]
+  * Finnish (fi.po) by Kimmo Kujansuu
+
+ -- Holger Wansing   Fri, 23 Jul 2021 19:30:21 +0200
+
+s390-dasd (0.0.72) unstable; urgency=medium
+
+  * Team upload
+
+  [ Updated translations ]
+  * Lithuanian (lt.po) by Gediminas Murauskas
+
+ -- Holger Wansing   Thu, 08 Jul 2021 23:38:27 +0200
+
+s390-dasd (0.0.71) unstable; urgency=medium
+
+  * Team upload
+
+  [ Updated translations ]
+  * Arabic (ar.po) by Fahim Sabah
+
+ -- Holger Wansing   Tue, 01 Jun 2021 21:05:44 +0200
+
+s390-dasd (0.0.70) unstable; urgency=medium
+
+  * Team upload
+
+  [ Updated translations ]
+  * Lithuanian (lt.po) by Kornelijus Tvarijanavičius
+
+ -- Holger Wansing   Fri, 02 Apr 2021 12:10:09 +0200
+
+s390-dasd (0.0.69) unstable; urgency=medium
+
+  * Team upload
+
+  [ Updated translations ]
+  * Greek (el.po) by george k
+  * Hindi (hi.po) by KushagraKarira
+  * Kabyle (kab.po) by Selyan Sliman Amiri
+  * Tamil (ta.po) by Vasudevan Tirumurti
+
+ -- Holger Wansing   Sat, 20 Feb 2021 

Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Julien Cristau]

Hi,

Specifically, we were hoping to better understand the risk of openssl
changes breaking existing setups.  It's possible the issues with gnutls
and libnet-ssleay-perl tests were narrowly scoped enough that that risk
is low, but we're just not sure right now.  Other input would be
welcome.

Thanks,
Julien

On Mon, Mar 21, 2022 at 08:23:20PM +, Adam D. Barratt wrote:
> On Sun, 2022-03-20 at 22:00 +0100, Paul Gevers wrote:
> > Dear Sebastian, Kurt,
> > 
> > On 19-03-2022 12:33, Adam D Barratt wrote:
> > > Upload details
> > > ==
> > > 
> > > Package: openssl
> > > Version: 1.1.1n-0+deb10u1
> > > 
> > > Explanation: new upstream release
> > 
> > We're seeing a regression in buster in the autopkgtest of gnutls28
> > with 
> > the new version of openssl on all tested architectures. Can you
> > please 
> > have a look and advise? (bullseye doesn't seem to have the test
> > anymore, 
> > hence it doesn't fail).
> 
> Thanks to both Kurt and Sebastian for quickly identifying the issue
> here, and to Adrian Bunk for the libnet-ssleay-perl fix.
> 
> There's been some continued discussion today as to whether we feel
> comfortable releasing the update with the 10.12 point release when we
> have only been finding such issues during the week leading up to the
> point release.
> 
> I fully appreciate that the large delays in getting to this point were
> mostly on our part, and that postponing the release until 10.13 would
> likely be frustrating, but the worry is that we don't have a good view
> of the changes that might be user-affecting in order to be comfortable
> with potential behaviour changes landing in oldstable - for example,
> the libnet-ssleay-perl issue appears to be related to 1024-bit keys no
> longer being accepted by default; while in general this is obviously a
> desirable behaviour, it is nonetheless a change in the behaviour
> compared to the current package in buster.
> 
> The situation is also slightly complicated by the fact the debian-
> installer uses OpenSSL internally, so we are also under internal time
> pressure to reach a conclusion, in order to be able to proceed with the
> installer build for the point release, rather than being able to leave
> the decision until the end of the week.
> 
> Thank you for bearing with us.
> 
> Regards,
> 
> Adam
> 

Bug#1006656: Intel NUC 11: kodi doesn't show

[Harald Dunkel]

After installing the intel-media-va-driver package it worked until
yesterday. Today it doesn't, but that seems to be the fault of a new
libigdgmm12 package.


Regards

Harri

Bug#1008062: buster-pu: package gnutls28/3.6.7-4+deb10u7.1

[Salvatore Bonaccorso]

Hi Sebastian,

On Mon, Mar 21, 2022 at 06:48:37PM +0100, Sebastian Andrzej Siewior wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: pu
> Tags: buster
> Severity: normal
> 
> I prepared an update to fix the debci regression caused by the openssl
> update. The complete analysis is in #959469.
> 
> The patch affects only the testsuite which is run as part of debci. The
> testsuite which is run as part of the build build process is not
> affeccted. The runtime code of the package is also not affected by the
> patch.
> Therefore I believe the impact is minimal.
> I did verify this change in a local chroot.
> 
> Sebastian

> diff -Nru gnutls28-3.6.7/debian/changelog gnutls28-3.6.7/debian/changelog
> --- gnutls28-3.6.7/debian/changelog   2021-05-14 13:33:38.0 +0200
> +++ gnutls28-3.6.7/debian/changelog   2022-03-21 14:52:01.0 +0100
> @@ -1,3 +1,11 @@
> +gnutls28 (3.6.7-4+deb10u7.1) buster; urgency=medium

As not yet uploaded, can you change this to 3.6.7-4+deb10u8 instead.

Regards,
Salvatore

Bug#1008056: buster-pu: package libnet-ssleay-perl/1.85-2.1

[Salvatore Bonaccorso]

Hi Adrian,

On Mon, Mar 21, 2022 at 05:55:00PM +0200, Adrian Bunk wrote:
> --- libnet-ssleay-perl-1.85/debian/changelog  2018-09-02 23:19:51.0 
> +0300
> +++ libnet-ssleay-perl-1.85/debian/changelog  2022-03-21 17:36:31.0 
> +0200
> @@ -1,3 +1,11 @@
> +libnet-ssleay-perl (1.85-2.1) buster; urgency=medium

Minor "nitpick" on the version, but to be consistent I would use
1.85-2+deb10u1 (as well for avoid a hypotetical existing 1.85-2.1 in a
previous unstable upload).

Regards,
Salvatore

Bug#1007992: libigdgmm12: new version causes segfaults

[Harald Dunkel]

kodi is affected, too. Attached you can find kodi's log file.
AFAICT it *does* try vdpau first, but then it exits.

Regards
Harri

kodi.log.gz
Description: GNU Zip compressed data

Bug#959469:

[Wesley Redondo]

I would like to stop receiving these emails

Bug#1008061: [Pkg-javascript-devel] Bug#1008061: Bug#1008061: Bug#1008061: node-builtins: Returns a wrong list of builtins module

[Jérémy Lal]

On Mon, Mar 21, 2022 at 8:15 PM Yadd  wrote:

>
>
> Le 21 mars 2022 19:04:24 GMT+01:00, "Jérémy Lal"  a
> écrit :
> >On Mon, Mar 21, 2022 at 6:57 PM Yadd  wrote:
> >
> >>
> >>
> >> On 21/03/2022 18:15, Yadd wrote:
> >> > Package: node-builtins
> >> > Version: 4.0.0-1
> >> > Severity: important
> >> >
> >> > Hi,
> >> >
> >> > node-builtins returns a static modules list which is up-to date for
> >> > Node.js < 11. It should be patched to use node-builtin-modules result
> >> > for node.js >= 12
> >> >
> >>
> >> Comparison:
> >>
> >> $ node
> >>  > require("builtins")()
> >> [
> >>'assert', 'buffer',  'child_process',
> >>'cluster','console', 'constants',
> >>'crypto', 'dgram',   'dns',
> >>'domain', 'events',  'fs',
> >>'http',   'https',   'module',
> >>'net','os',  'path',
> >>'punycode',   'querystring', 'readline',
> >>'repl',   'stream',  'string_decoder',
> >>'sys','timers',  'tls',
> >>'tty','url', 'util',
> >>'vm', 'zlib','v8',
> >>'process','inspector',   'async_hooks',
> >>'http2',  'perf_hooks',  'trace_events',
> >>'worker_threads'
> >> ]
> >>  > require("builtin-modules")
> >> [
> >>'assert','async_hooks','buffer',
> >>'child_process', 'cluster','console',
> >>'constants', 'crypto', 'dgram',
> >>'dns',   'domain', 'events',
> >>'fs','http',   'http2',
> >>'https', 'inspector',  'module',
> >>'net',   'os', 'path',
> >>'perf_hooks','process','punycode',
> >>'querystring',   'readline',   'repl',
> >>'stream','string_decoder', 'timers',
> >>'tls',   'trace_events',   'tty',
> >>'url',   'util',   'v8',
> >>'vm','wasi',   'worker_threads',
> >>'zlib'
> >> ]
> >>
> >
> >Good catch,
> >do you want me to do it ?

>
> >Jérémy
>
> Yes, thanks !


Suggested approach would break the module API:

require('builtins')({ version: '6.0.0' })
require('builtins')({ version: '6.0.0', experimental: true })

it's supposed to be queryable.

I'd rather fix the list.

Jérémy

Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Wesley Redondo]

How do I stop these emails

On Mon, Mar 21, 2022, 3:27 PM Adam D. Barratt 
wrote:

> On Sun, 2022-03-20 at 22:00 +0100, Paul Gevers wrote:
> > Dear Sebastian, Kurt,
> >
> > On 19-03-2022 12:33, Adam D Barratt wrote:
> > > Upload details
> > > ==
> > >
> > > Package: openssl
> > > Version: 1.1.1n-0+deb10u1
> > >
> > > Explanation: new upstream release
> >
> > We're seeing a regression in buster in the autopkgtest of gnutls28
> > with
> > the new version of openssl on all tested architectures. Can you
> > please
> > have a look and advise? (bullseye doesn't seem to have the test
> > anymore,
> > hence it doesn't fail).
>
> Thanks to both Kurt and Sebastian for quickly identifying the issue
> here, and to Adrian Bunk for the libnet-ssleay-perl fix.
>
> There's been some continued discussion today as to whether we feel
> comfortable releasing the update with the 10.12 point release when we
> have only been finding such issues during the week leading up to the
> point release.
>
> I fully appreciate that the large delays in getting to this point were
> mostly on our part, and that postponing the release until 10.13 would
> likely be frustrating, but the worry is that we don't have a good view
> of the changes that might be user-affecting in order to be comfortable
> with potential behaviour changes landing in oldstable - for example,
> the libnet-ssleay-perl issue appears to be related to 1024-bit keys no
> longer being accepted by default; while in general this is obviously a
> desirable behaviour, it is nonetheless a change in the behaviour
> compared to the current package in buster.
>
> The situation is also slightly complicated by the fact the debian-
> installer uses OpenSSL internally, so we are also under internal time
> pressure to reach a conclusion, in order to be able to proceed with the
> installer build for the point release, rather than being able to leave
> the decision until the end of the week.
>
> Thank you for bearing with us.
>
> Regards,
>
> Adam
>
>

Bug#1004563: (no subject)

[Achim Schaefer]

Still the same issueSubject: Re: enblend and enfuse depend on libgsl25 that is 
nonexistent and replaced by libgsl27
Message-ID: <164789523968.487488.17880797647457551802.report...@data.zuhause.xx>
X-Mailer: reportbug 11.4.1
Date: Mon, 21 Mar 2022 21:40:39 +0100

Package: enblend
Version: 4.2-8
Followup-For: Bug #1004563
X-Debbugs-Cc: bts.debian@schaefer-home.eu




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

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de:en_GB:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages enblend depends on:
ii  libc62.33-7
ii  libgcc-s112-20220319-1
ii  libgomp1 12-20220319-1
ii  libgsl25 2.7+dfsg-2
ii  liblcms2-2   2.12~rc1-2
ii  libstdc++6   12-20220319-1
ii  libtiff5 4.3.0-6
ii  libvigraimpex11  1.11.1+dfsg-8

Versions of packages enblend recommends:
ii  hugin  2021.0~beta1+dfsg-1

enblend suggests no packages.

-- no debconf information

Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Adam D. Barratt]

On Sun, 2022-03-20 at 22:00 +0100, Paul Gevers wrote:
> Dear Sebastian, Kurt,
> 
> On 19-03-2022 12:33, Adam D Barratt wrote:
> > Upload details
> > ==
> > 
> > Package: openssl
> > Version: 1.1.1n-0+deb10u1
> > 
> > Explanation: new upstream release
> 
> We're seeing a regression in buster in the autopkgtest of gnutls28
> with 
> the new version of openssl on all tested architectures. Can you
> please 
> have a look and advise? (bullseye doesn't seem to have the test
> anymore, 
> hence it doesn't fail).

Thanks to both Kurt and Sebastian for quickly identifying the issue
here, and to Adrian Bunk for the libnet-ssleay-perl fix.

There's been some continued discussion today as to whether we feel
comfortable releasing the update with the 10.12 point release when we
have only been finding such issues during the week leading up to the
point release.

I fully appreciate that the large delays in getting to this point were
mostly on our part, and that postponing the release until 10.13 would
likely be frustrating, but the worry is that we don't have a good view
of the changes that might be user-affecting in order to be comfortable
with potential behaviour changes landing in oldstable - for example,
the libnet-ssleay-perl issue appears to be related to 1024-bit keys no
longer being accepted by default; while in general this is obviously a
desirable behaviour, it is nonetheless a change in the behaviour
compared to the current package in buster.

The situation is also slightly complicated by the fact the debian-
installer uses OpenSSL internally, so we are also under internal time
pressure to reach a conclusion, in order to be able to proceed with the
installer build for the point release, rather than being able to leave
the decision until the end of the week.

Thank you for bearing with us.

Regards,

Adam

Bug#1007707: Update Indonesian translation

[Paul Gevers]

Hi Holger,

On Fri, 18 Mar 2022 21:38:11 +0100 Holger Wansing  
wrote:

Andika Triwidada  wrote (Tue, 15 Mar 2022 11:26:40 +):
> 
> Attached is update to Indonesian translation.


Just applied to GIT.
Thanks


Shall we have an upload of this soon and do the ftp-master dance with 
this package to have it finally migrate to testing (#998353)?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005833: src:ruby-redis: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Hi,

On Tue, 15 Feb 2022 19:49:08 +0100 Paul Gevers  wrote:
The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:ruby-redis has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. There is already a bug about 
the autopkgtest failure. This seems like it really needs to be solved 
between ruby-redis and ruby-fakeredis.


Is there any progress on this issue? Is no progress is there another way 
to move the problem forward? E.g. revert ruby-redis to the previous 
version if redis and fakeredis can agree on the change in behavior?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008071: RM: xcal -- RoQA; unmaintained, RC-buggy

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove xcal. It's dead upstream, unmaintained (last upload
in 2008) and there's three RC bugs.

Cheers,
Moritz

Bug#1008059: systemd-timesyncd restarted on every router advertisment

[Adam Dinwoodie]

On Mon, Mar 21, 2022 at 07:24:54PM +, Adam Dinwoodie wrote:
> On Mon, Mar 21, 2022 at 05:57:10PM +0100, Michael Biebl wrote:
> > Control: reassign dhcpcd5
> > 
> > Am 21.03.22 um 17:39 schrieb Michael Biebl:
> > > 
> > > Am 21.03.22 um 17:36 schrieb Michael Biebl:
> > > 
> > > > Is that a result of /etc/dhcp/dhclient-exit-hooks.d/timesyncd ?
> > > > 
> > > > What happens if you remove that dhclient hook
> > > 
> > > 
> > > Actually, I think it might be
> > > dhcpcd5: /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf
> > > 
> > > which triggers the service restart, i.e. it would be a dhcpcd5 issue.
> > 
> > Reassigning accordingly.
> > 
> > # cat /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf
> > # vi: ft=sh
> > 
> > SERVERFILE_IPV4="/run/systemd/timesyncd.conf.d/01-dhcpcd.ipv4.$interface.conf"
> > SERVERFILE_IPV6="/run/systemd/timesyncd.conf.d/01-dhcpcd.ipv6.$interface.conf"
> > 
> > reload_config() {
> > systemctl try-restart systemd-timesyncd.service || :
> > }
> 
> Fantastic, thank you!  I've confirmed that replacing that line with a
> simple `:` stops this behaviour.

And I think I've found the bug: the `add_servers` function in
60-ntp-common.conf attempts to work out if it needs to rebuild the
server file, and only actually rebuild and reload the configuration if
it's necessary.  But the test it uses doesn't work when there are no
configured NTP servers, such as because someone is using SNTP with
systemd-timesyncd and the default Debian time server.

I think the patch below should resolve this:

diff -ur old/60-ntp-common.conf new/60-ntp-common.conf
--- old/debian/hooks/60-ntp-common.conf 2022-03-21 19:49:03.518699860 +
+++ new/debian/hooks/60-ntp-common.conf 2022-03-21 19:51:32.216039388 +
@@ -3,6 +3,8 @@
 add_servers() {
if [ -f "$SERVERFILE" ] && [ "$new_ntp_servers" = "$old_ntp_servers" ]; 
then
return
+   elif [ ! -f "$SERVERFILE" ] && [ -z "$new_ntp_servers" ]; then
+   return
fi
 
rm -f "$SERVERFILE"

Bug#1008070: RM: bopm -- RoQA; unmaintained, RC-buggy, alternatives exist

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove bopm. It's unmaintained (last upload a decade ago), RC buggy,
dead upstream and a maintained fork (hopm) is in the archive.

Cheers,
Moritz

Bug#1001595: src:gcc-defaults-mipsen: fails to migrate to testing for too long

[Paul Gevers]

Hi mips porters,

On Sun, 12 Dec 2021 21:51:28 +0100 Paul Gevers  wrote:
The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:gcc-defaults-mipsen has been trying to 
migrate for 62 days [2].


It's been 161 days now. We expect from you to solve these kind of 
issues, especially if they have been brought to your attention.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008059: systemd-timesyncd restarted on every router advertisment

[Adam Dinwoodie]

On Mon, Mar 21, 2022 at 05:57:10PM +0100, Michael Biebl wrote:
> Control: reassign dhcpcd5
> 
> Am 21.03.22 um 17:39 schrieb Michael Biebl:
> > 
> > Am 21.03.22 um 17:36 schrieb Michael Biebl:
> > 
> > > Is that a result of /etc/dhcp/dhclient-exit-hooks.d/timesyncd ?
> > > 
> > > What happens if you remove that dhclient hook
> > 
> > 
> > Actually, I think it might be
> > dhcpcd5: /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf
> > 
> > which triggers the service restart, i.e. it would be a dhcpcd5 issue.
> 
> Reassigning accordingly.
> 
> # cat /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf
> # vi: ft=sh
> 
> SERVERFILE_IPV4="/run/systemd/timesyncd.conf.d/01-dhcpcd.ipv4.$interface.conf"
> SERVERFILE_IPV6="/run/systemd/timesyncd.conf.d/01-dhcpcd.ipv6.$interface.conf"
> 
> reload_config() {
>   systemctl try-restart systemd-timesyncd.service || :
> }

Fantastic, thank you!  I've confirmed that replacing that line with a
simple `:` stops this behaviour.

Bug#1008069: src:luajit: fails to migrate to testing for too long: SEGFAULT on ppc64el

[Paul Gevers]

Source: luajit
Version: 2.1.0~beta3+dfsg-6
Severity: serious
Control: close -1 2.1.0~beta3+git20210112+dfsg-2
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1004511

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:luajit has been trying to migrate for 61 
days [2]. Hence, I am filing this bug.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008068: src:ocrad: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Source: ocrad
Version: 0.27-2
Severity: serious
Control: close -1 0.28-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1004508

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:ocrad has been trying to migrate for 61 
days [2]. Hence, I am filing this bug.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006909: impressive: Fails to find any pages in the presentation

[Martin Fiedler]

Hi Gunnar,

thanks for the analysis, and thanks for confirming that mupdf-tools was
indeed missing.

Anyway, I think there is a slight misunderstanding about which external
tool Impressive requires:
For *analysis* (i.e. checking how many pages there are, extracting
hyperlinks etc.), Impressive needs "mutool" from mupdf-tools or "pdftk"
from pdftk-java(*).
For *rendering* (i.e. converting PDF pages to bitmaps), Impressive needs
"mutool" from mupdf-tools or "pdftoppm" from poppler-utils.
So, pdftk is in no way involved in how the slides look on screen, while
mutool serves double duty for analysis and rendering.


I can confirm impressive works with my presentation (although the
rendering looks a bit less polished) after installing mupdf-tools.

That's interesting. Can you upload a pair of example screenshots and/or
an affected document somewhere? In my testing, I've always found MuPDF's
results to be equal (and sometimes even superior) to Poppler's. You are,
in fact, the first user who complains about the rendering quality, and
I'd like to understand what's going on.


I think the result for having both installed should be to default for
the best renderer.


That's exactly what it does :) Impressive picks MuPDF over Poppler
because of two reasons: (a) it's faster, and (b) it doesn't require
temporary files.

That being said, you don't need to uninstall anything to force
Impressive to use a specific renderer, as there's a command-line option
to override the renderer: "-P mutool" uses MuPDF, "-P pdftoppm" uses
Poppler, "-P gs" uses GhostScript.

Best regards,
Martin Fiedler


(*) As said a few mails back, there is one -- optional -- feature that
still requires pdftk(-java), and that's extraction of the page titles.
If you don't need that, but have mupdf-tools, you can get rid of pdftk-java.
This restriction will possibly vanish sonn, because literally an hour
*after* I released 0.13.1, a user informed me that mutool can indeed
also extract page titles if you ask nicely ...

Bug#1008066: ITP: photoqt -- Fast and highly configurable image viewer

[Gürkan Myczko]

Package: wnpp
Severity: wishlist
Owner: Gürkan Myczko 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: photoqt
  Version : 2.5
  Upstream Authors: Lukas Spies 
  URL : https://photoqt.org/
* License : GPL-2+
  Description : Fast and highly configurable image viewer
 This is a fast and highly configurable image viewer with a simple and 
nice

 interface.

Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?

[Diederik de Haas]

On maandag 21 maart 2022 19:49:56 CET Dominique Dumont wrote:
> On Monday, 21 March 2022 09:57:59 CET Thorsten Leemhuis wrote:
> > Dominique/Salvatore/Eric, what's the status of this regression?
> > According to the debian bug tracker the problem is solved with 5.16 and
> > 5.17, but was 5.15 ever fixed?
> 
> I don't think so.
> 
> On kernel side, the commit fixing this issue is
> e55a3aea418269266d84f426b3bd70794d3389c8 .
> 
> According to the logs of [1] , this commit landed in v5.17-rc3

It was included in 5.15.22, but the newest 5.15 kernel uploaded to Debian was 
5.15.15, so their is no fixed 5.15 in Debian.
It was also included in 5.16.8 and the earlier version in Debian which had 
that commit was 5.16.10 (uploaded 2022-02-18 to Unstable). Current version in 
Unstable is 5.16.14. Testing/Bookworm now had 5.16.12.
In Experimental, on 2022-02-12, 5.17-rc3 was uploaded.

HTH,
  Diederik

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

Bug#1008061: [Pkg-javascript-devel] Bug#1008061: Bug#1008061: Bug#1008061: node-builtins: Returns a wrong list of builtins module

[Yadd]

Le 21 mars 2022 19:04:24 GMT+01:00, "Jérémy Lal"  a écrit :
>On Mon, Mar 21, 2022 at 6:57 PM Yadd  wrote:
>
>>
>>
>> On 21/03/2022 18:15, Yadd wrote:
>> > Package: node-builtins
>> > Version: 4.0.0-1
>> > Severity: important
>> >
>> > Hi,
>> >
>> > node-builtins returns a static modules list which is up-to date for
>> > Node.js < 11. It should be patched to use node-builtin-modules result
>> > for node.js >= 12
>> >
>>
>> Comparison:
>>
>> $ node
>>  > require("builtins")()
>> [
>>'assert', 'buffer',  'child_process',
>>'cluster','console', 'constants',
>>'crypto', 'dgram',   'dns',
>>'domain', 'events',  'fs',
>>'http',   'https',   'module',
>>'net','os',  'path',
>>'punycode',   'querystring', 'readline',
>>'repl',   'stream',  'string_decoder',
>>'sys','timers',  'tls',
>>'tty','url', 'util',
>>'vm', 'zlib','v8',
>>'process','inspector',   'async_hooks',
>>'http2',  'perf_hooks',  'trace_events',
>>'worker_threads'
>> ]
>>  > require("builtin-modules")
>> [
>>'assert','async_hooks','buffer',
>>'child_process', 'cluster','console',
>>'constants', 'crypto', 'dgram',
>>'dns',   'domain', 'events',
>>'fs','http',   'http2',
>>'https', 'inspector',  'module',
>>'net',   'os', 'path',
>>'perf_hooks','process','punycode',
>>'querystring',   'readline',   'repl',
>>'stream','string_decoder', 'timers',
>>'tls',   'trace_events',   'tty',
>>'url',   'util',   'v8',
>>'vm','wasi',   'worker_threads',
>>'zlib'
>> ]
>>
>
>Good catch,
>do you want me to do it ?
>
>Jérémy

Yes, thanks !

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#1008065: megapixels: Update description for GTK4

[Jeremy Bicha]

Source: megapixels
Version: 1.4.3-1
Severity: minor

The package description for megapixels says it's a GTK3 app but that's
no longer true.

Thank you,
Jeremy Bicha

Bug#1005129: bullseye-pu: package nvidia-graphics-drivers/470.103.01-1~deb11u1

[Adam D. Barratt]

On Mon, 2022-03-21 at 11:03 +0100, Andreas Beckmann wrote:
> On 20/03/2022 00.45, Adam D. Barratt wrote:
> > The window closes "tomorrow", which is mostly "when Adam has had
> > enough", but is usually by the start of the 19:52 dinstall at the
> > latest.
> 
> Not sure if relative date "tomorrow" meant Sunday or Monday. If it's
> too 
> late now, no problem, we can postpone the remaining updates for the
> next 
> point release (and have NEW processed by then, too).

Apologies for the confusion - "tomorrow" was Sunday, so it is indeed
too late for 11.3 now.

We have nvidia-graphics-drivers-tesla-450 and nvidia-modprobe in p-u
ready to be part of the point release. My understanding from your
previous comments is that should work OK without the remaining updates,
but please yell if I've misunderstood.

Regards,

Adam

Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?

[Thorsten Leemhuis]

On 21.03.22 19:49, Dominique Dumont wrote:
> On Monday, 21 March 2022 09:57:59 CET Thorsten Leemhuis wrote:
>> Dominique/Salvatore/Eric, what's the status of this regression?
>> According to the debian bug tracker the problem is solved with 5.16 and
>> 5.17, but was 5.15 ever fixed?
> 
> I don't think so.
> 
> On kernel side, the commit fixing this issue is
> e55a3aea418269266d84f426b3bd70794d3389c8 . 
> 
> According to the logs of [1] , this commit landed in v5.17-rc3
> 
> HTH
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

And from there it among others got backported to 5.15.22:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.15.y=8a15ac1786c92dce6ecbeb4e4c237f5f80c2c703

https://lwn.net/Articles/884107/

Another indicator that Eric's problem is something else.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I'm getting a lot of
reports on my table. I can only look briefly into most of them and lack
knowledge about most of the areas they concern. I thus unfortunately
will sometimes get things wrong or miss something important. I hope
that's not the case here; if you think it is, don't hesitate to tell me
in a public reply, it's in everyone's interest to set the public record
straight.

Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?

[Dominique Dumont]

Hi

On Monday, 21 March 2022 09:57:59 CET Thorsten Leemhuis wrote:
> Dominique/Salvatore/Eric, what's the status of this regression?
> According to the debian bug tracker the problem is solved with 5.16 and
> 5.17, but was 5.15 ever fixed?

I don't think so.

On kernel side, the commit fixing this issue is
e55a3aea418269266d84f426b3bd70794d3389c8 . 

According to the logs of [1] , this commit landed in v5.17-rc3

HTH

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Bug#1007988: ITP: golang-github-iglou-eu-go-wildcard -- Fast and light wildcard pattern matching

[Francisco Vilmar Cardoso Ruviaro]

Hi Adrien,

On 2022-03-21 17:17 +, Adrien Kara wrote:
> Hi Vilmar,
> 
> I'm not sure what you mean by "maintain it"? 
> 
> 
> Do you want to maintain a Debian package ? It's great, and let me know if I 
> can be helpful.
> 

Yes, I will maintain the Debian package with the go-team, you can see that the 
package has gone to NEW:
https://ftp-master.debian.org/new/golang-github-iglou-eu-go-wildcard_1.0.3-1.html

> Do you want to fork the git repository? You are obviously free to do so, but 
> I still maintain my repository, so I'm not sure a fork is necessary?
> 
> In any case, I'll be happy to look into your problem/response if you have 
> any.


Regards,
-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008061: [Pkg-javascript-devel] Bug#1008061: Bug#1008061: node-builtins: Returns a wrong list of builtins module

[Jérémy Lal]

On Mon, Mar 21, 2022 at 6:57 PM Yadd  wrote:

>
>
> On 21/03/2022 18:15, Yadd wrote:
> > Package: node-builtins
> > Version: 4.0.0-1
> > Severity: important
> >
> > Hi,
> >
> > node-builtins returns a static modules list which is up-to date for
> > Node.js < 11. It should be patched to use node-builtin-modules result
> > for node.js >= 12
> >
>
> Comparison:
>
> $ node
>  > require("builtins")()
> [
>'assert', 'buffer',  'child_process',
>'cluster','console', 'constants',
>'crypto', 'dgram',   'dns',
>'domain', 'events',  'fs',
>'http',   'https',   'module',
>'net','os',  'path',
>'punycode',   'querystring', 'readline',
>'repl',   'stream',  'string_decoder',
>'sys','timers',  'tls',
>'tty','url', 'util',
>'vm', 'zlib','v8',
>'process','inspector',   'async_hooks',
>'http2',  'perf_hooks',  'trace_events',
>'worker_threads'
> ]
>  > require("builtin-modules")
> [
>'assert','async_hooks','buffer',
>'child_process', 'cluster','console',
>'constants', 'crypto', 'dgram',
>'dns',   'domain', 'events',
>'fs','http',   'http2',
>'https', 'inspector',  'module',
>'net',   'os', 'path',
>'perf_hooks','process','punycode',
>'querystring',   'readline',   'repl',
>'stream','string_decoder', 'timers',
>'tls',   'trace_events',   'tty',
>'url',   'util',   'v8',
>'vm','wasi',   'worker_threads',
>'zlib'
> ]
>

Good catch,
do you want me to do it ?

Jérémy

Bug#1008064: po4a: HTML links with dash get stray backslash

[Petter Reinholdtsen]

Package: po4a
Version: 0.62-1

I ran into this problem while converting linuxcnc to use po4a to handle
translated documentation.

The problem is that working links in the English original is replaced
with broken links in the translated files, even though the original
English text is used because the translated string is missing.

The following script demonstrate the problem.

  test-po4a-html-links ===
#!/bin/sh

cat << EOF > po4a.cfg
[po4a_langs] es
[po4a_paths] documentation.pot $lang:documentation_$lang.po
[po4a_alias:xhtml_def] man opt:"--keep 0"
[type: xhtml_def] gcode.html $lang:gcode_$lang.html
EOF

cat << EOF > gcode.html
http://www.w3.org/TR/html4/strict.dtd;>



G0Rapid Move


EOF

cat << EOF > g-code.html
http://www.w3.org/TR/html4/strict.dtd;>


G0
G0 described.

EOF

po4a po4a.cfg

grep HREF gcode.html
grep HREF gcode_es.html
==

This is the output I get:

% sh test-po4a-html-links
 (1 entries)
Error: 'msginit -i /scratch/pere/src/linuxcnc/po4a-fail/documentation.pot 
--locale  -o 
/scratch/pere/src/linuxcnc/po4a-fail/documentation_.po --no-translator 
>/dev/null' exited 
with value 1.
G0Rapid Move
G0Rapid Move
%

Note how "g-code.html" become "g\-code.html" in the translated file,
thus breaking the link.  I expected both to use "g-code.html".

-- 
Happy hacking
Petter Reinholdtsen

Bug#1008063: transition: nodejs

[Jérémy Lal]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: Debian Javascript Maintainers 


Hi,

this transition correspond to a nodejs 12 -> 14 major major bump.

I carefully checked (twice, actually) that all build-dependencies of
- libnode-dev (arch-dependent)
- nodejs (arch-independent)
can be rebuilt using latest libnode-dev / nodejs, though of course
only the arch-dependent ones are concerned by this transition.

Ben file:

title = "nodejs";
is_affected = .depends ~ "libnode72" | .depends ~ "libnode83";
is_good = .depends ~ "libnode83";
is_bad = .depends ~ "libnode72";

Thank you for considering.

Jérémy

Bug#1008061: [Pkg-javascript-devel] Bug#1008061: node-builtins: Returns a wrong list of builtins module

[Yadd]

On 21/03/2022 18:15, Yadd wrote:

Package: node-builtins
Version: 4.0.0-1
Severity: important

Hi,

node-builtins returns a static modules list which is up-to date for
Node.js < 11. It should be patched to use node-builtin-modules result
for node.js >= 12



Comparison:

$ node
> require("builtins")()
[
  'assert', 'buffer',  'child_process',
  'cluster','console', 'constants',
  'crypto', 'dgram',   'dns',
  'domain', 'events',  'fs',
  'http',   'https',   'module',
  'net','os',  'path',
  'punycode',   'querystring', 'readline',
  'repl',   'stream',  'string_decoder',
  'sys','timers',  'tls',
  'tty','url', 'util',
  'vm', 'zlib','v8',
  'process','inspector',   'async_hooks',
  'http2',  'perf_hooks',  'trace_events',
  'worker_threads'
]
> require("builtin-modules")
[
  'assert','async_hooks','buffer',
  'child_process', 'cluster','console',
  'constants', 'crypto', 'dgram',
  'dns',   'domain', 'events',
  'fs','http',   'http2',
  'https', 'inspector',  'module',
  'net',   'os', 'path',
  'perf_hooks','process','punycode',
  'querystring',   'readline',   'repl',
  'stream','string_decoder', 'timers',
  'tls',   'trace_events',   'tty',
  'url',   'util',   'v8',
  'vm','wasi',   'worker_threads',
  'zlib'
]

Bug#999443: pulseaudio: Muted microphone is unmuted when resuming from sleep

[Ben Goodwin]

Package: pulseaudio
Followup-For: Bug #999443
X-Debbugs-Cc: vbgoodw...@gmail.com

This problem is resolved in pulseaudio version 15.0+dfsg1-4.


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser 3.120
ii  init-system-helpers 1.62
ii  libasound2  1.2.6.1-2
ii  libasound2-plugins  1.2.6-1
ii  libc6   2.33-7
ii  libcap2 1:2.44-1
ii  libdbus-1-3 1.14.0-1
ii  libfftw3-single33.3.8-2
ii  libgcc-s1   12-20220313-1
ii  libglib2.0-02.70.4-1
ii  libgstreamer-plugins-base1.0-0  1.20.0-2
ii  libgstreamer1.0-0   1.20.0-1
ii  libice6 2:1.0.10-1
ii  libltdl72.4.6-15
ii  liborc-0.4-01:0.4.32-2
ii  libpulse0   15.0+dfsg1-4
ii  libsm6  2:1.2.3-1
ii  libsndfile1 1.0.31-2
ii  libsoxr00.1.3-4
ii  libspeexdsp11.2~rc1.2-3
ii  libstdc++6  12-20220313-1
ii  libsystemd0 250.4-1
ii  libtdb1 1.4.5-2
ii  libudev1250.4-1
ii  libwebrtc-audio-processing1 0.3-1+b1
ii  libx11-62:1.7.2-2+b1
ii  libx11-xcb1 2:1.7.2-2+b1
ii  libxcb1 1.14-3
ii  libxtst62:1.2.3-1
ii  lsb-base11.1.0
ii  pulseaudio-utils15.0+dfsg1-4

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.14.0-1
ii  libpam-systemd [logind]  250.4-1
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
pn  paprefs  
ii  pavucontrol  5.0-2
pn  pavumeter
ii  udev 250.4-1

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = 

Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Andreas Metzler]

X-Debbugs-Cc: gnutl...@packages.debian.org, Kurt Roeckx , Paul 
Gevers , Sebastian Andrzej Siewior 

On 2022-03-21 Sebastian Andrzej Siewior  wrote:
> On 2022-03-21 00:12:11 [+0100], To Kurt Roeckx wrote:
> > doesn't help here but
> >  -cipher "ALL:@SECLEVEL=1"

> > does. 

> Only debci is affected. The package builds because this testsuite is not
> part of the build process.
> I prepared a NMU against Buster for gnutls. I can open later today a
> buster-pu and do the upload unless someone objects or gnutls folks have
> something in their queue.
> Please let me know.

Hello Sebastian,

thanks for taking care, feel free to NMU.

cu Andreas

PS: Style nitpick: As can be see from "ls debian/patches/" I think it is
a very good idea to use patch filenames with obvious sorting.


signature.asc
Description: PGP signature

Bug#1008062: buster-pu: package gnutls28/3.6.7-4+deb10u7.1

[Sebastian Andrzej Siewior]

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

I prepared an update to fix the debci regression caused by the openssl
update. The complete analysis is in #959469.

The patch affects only the testsuite which is run as part of debci. The
testsuite which is run as part of the build build process is not
affeccted. The runtime code of the package is also not affected by the
patch.
Therefore I believe the impact is minimal.
I did verify this change in a local chroot.

Sebastian
diff -Nru gnutls28-3.6.7/debian/changelog gnutls28-3.6.7/debian/changelog
--- gnutls28-3.6.7/debian/changelog	2021-05-14 13:33:38.0 +0200
+++ gnutls28-3.6.7/debian/changelog	2022-03-21 14:52:01.0 +0100
@@ -1,3 +1,11 @@
+gnutls28 (3.6.7-4+deb10u7.1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport testcompat-openssl-improve-testing-against-secured-O.patch to
+pass testsuite with openssl 1.1.1e.
+
+ -- Sebastian Andrzej Siewior   Mon, 21 Mar 2022 14:52:01 +0100
+
 gnutls28 (3.6.7-4+deb10u7) buster; urgency=medium
 
   * 46_handshake-reject-no_renegotiation-alert-if-handshake.patch pulled from
diff -Nru gnutls28-3.6.7/debian/patches/series gnutls28-3.6.7/debian/patches/series
--- gnutls28-3.6.7/debian/patches/series	2021-05-11 18:13:03.0 +0200
+++ gnutls28-3.6.7/debian/patches/series	2022-03-21 08:35:24.0 +0100
@@ -23,3 +23,4 @@
 47_rel3.6.16_04-pre_shared_key-avoid-use-after-free-around-realloc.patch
 47_rel3.6.16_05-_gnutls_buffer_resize-account-for-unused-area-if-AGG.patch
 47_rel3.6.16_06-str-suppress-Wunused-function-if-AGGRESSIVE_REALLOC-.patch
+testcompat-openssl-improve-testing-against-secured-O.patch
diff -Nru gnutls28-3.6.7/debian/patches/testcompat-openssl-improve-testing-against-secured-O.patch gnutls28-3.6.7/debian/patches/testcompat-openssl-improve-testing-against-secured-O.patch
--- gnutls28-3.6.7/debian/patches/testcompat-openssl-improve-testing-against-secured-O.patch	1970-01-01 01:00:00.0 +0100
+++ gnutls28-3.6.7/debian/patches/testcompat-openssl-improve-testing-against-secured-O.patch	2022-03-21 08:37:07.0 +0100
@@ -0,0 +1,274 @@
+From: Dimitri John Ledkov 
+Date: Mon, 21 Mar 2022 07:44:25 +0100
+Subject: [PATCH] testcompat-openssl: improve testing against secured OpenSSL
+
+[bigeasy: This is backport of commit fbd3e261513d641dce6bd1b2c368ce25e79dc094 ]
+
+In Debian, and soon Ubuntu, OpenSSL is compiled with SECLEVEL=2 and
+requiring minimum TLSv1.2. However, smaller hashes/keys/versions are
+allowed if one enables SECLEVEL=1. Do so when testing pre v1.2 algos,
+and thus enabling testing more compatability combinations.
+
+Signed-off-by: Dimitri John Ledkov 
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ tests/suite/testcompat-main-openssl | 67 +
+ 1 file changed, 30 insertions(+), 37 deletions(-)
+
+diff --git a/tests/suite/testcompat-main-openssl b/tests/suite/testcompat-main-openssl
+index d2708bfa8c710..2ea762faebaca 100755
+--- a/tests/suite/testcompat-main-openssl
 b/tests/suite/testcompat-main-openssl
+@@ -74,7 +74,6 @@ NO_TLS1_2=$?
+ 
+ test $NO_TLS1_2 != 0 && echo "Disabling interop tests for TLS 1.2"
+ 
+-
+ ${SERV} version|grep -e '[1-9]\.[1-9]\.[0-9]' >/dev/null 2>&1
+ if test $? = 0;then
+ 	NO_DH_PARAMS=0
+@@ -82,18 +81,8 @@ else
+ 	NO_DH_PARAMS=1
+ fi
+ 
+-# Do not use DSS or curves <=256 bits in 1.1.1+ because these
+-# are not accepted by openssl on debian.
+-${SERV} version|grep -e '[1-9]\.[1-9]\.[1-9]' >/dev/null 2>&1
+-if test $? = 0;then
+-	NO_DSS=1
+-	FIPS_CURVES=1
+-else
+-	${SERV} ciphers -v ALL 2>&1|grep -e DHE-DSS >/dev/null 2>&1
+-	NO_DSS=$?
+-fi
+-
+-test $FIPS_CURVES = 1 && echo "Running with FIPS140-2 enabled curves enabled"
++${SERV} ciphers -v ALL 2>&1|grep -e DHE-DSS >/dev/null 2>&1
++NO_DSS=$?
+ 
+ if test $NO_DSS != 0;then
+ 	echo "Disabling interop tests for DSS ciphersuites"
+@@ -121,6 +110,10 @@ NO_NULL=$?
+ 
+ test $NO_NULL != 0 && echo "Disabling interop tests for NULL ciphersuites"
+ 
++${SERV} ecparam -list_curves 2>&1|grep -e prime192v1 >/dev/null 2>&1
++NO_PRIME192v1=$?
++
++test $NO_PRIME192v1 != 0 && echo "Disabling interop tests for prime192v1 ecparam"
+ 
+ if test "${NO_DH_PARAMS}" = 0;then
+ 	OPENSSL_DH_PARAMS_OPT=""
+@@ -218,7 +211,7 @@ run_client_suite() {
+ 
+ 	#-cipher RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-AES128-SHA
+ 	eval "${GETPORT}"
+-	launch_bare_server $$ s_server -cipher "ALL" -quiet -www -accept "${PORT}" -keyform pem -certform pem -tls1 ${OPENSSL_DH_PARAMS_OPT} -key "${RSA_KEY}" -cert "${RSA_CERT}" ${DSA_PARAMS} -Verify 1 -CAfile "${CA_CERT}" >/dev/null
++	launch_bare_server $$ s_server -cipher "ALL:@SECLEVEL=1" -quiet -www -accept "${PORT}" -keyform pem -certform pem -tls1 ${OPENSSL_DH_PARAMS_OPT} -key "${RSA_KEY}" -cert "${RSA_CERT}" ${DSA_PARAMS} -Verify 1 -CAfile "${CA_CERT}" >/dev/null
+ 	PID=$!
+ 	wait_server ${PID}
+ 
+@@ -267,9 +260,9 @@ run_client_suite() 

Bug#1008056: [Pkg-openssl-devel] Bug#1008056: buster-pu: package libnet-ssleay-perl/1.85-2.1

[Sebastian Andrzej Siewior]

On 2022-03-21 17:55:00 [+0200], Adrian Bunk wrote:

> >   * Backport upstream fix for test failures with OpenSSL 1.1.1n.
> > (Closes: #1008055)

Thank you Adrian.

Sebastian

Bug#1006909: impressive: Fails to find any pages in the presentation

[Gunnar Wolf]

Yaroslav Halchenko dijo [Mon, Mar 21, 2022 at 09:08:34AM -0400]:
> > > Hmmm... But please do take note that I _did_ have mupdf-tools
> > > installed when Impressive failed to analyze the PDF
> > > document.
> 
> > Did you though? Impressive detected "Poppler/Xpdf" as the renderer,
> > which is an indicator of the absence of mupdf-tools. If you can confirm
> > that "mutool -v" works on your system (in the sense of: prints a version
> > number instead of a "command not found" message), I'd have some homework
> > to do though ;)
> 
> Dear Gunnar,
> 
> Could you please confirm that mupdf-tools were installed and
> functioning?  I know that sounds implausible given that it is a hard
> dependency but having no pdftk{,-java} installed I was able to use
> impressive just fine.

I am writing finally from the computer I regularly use for my classes
-- I did have mupdf, but *not* mupdf-tools. I can confirm impressive
works with my presentation (although the rendering looks a bit less
polished) after installing mupdf-tools.

Ugh -- and the ugly rendering remains even if I install pdftk-java
(that is, it seems that having both installed in the system,
impressive will default to mupdf-tools?); I got back my "nice"
rendering only after purging mupdf-tools.

So:

- with mupdf-tools 1.19.0+ds1-2 and pdftk-java 3.2.2-1:
  - Rendering is ugly
  - Impressive reports:
 
Welcome to Impressive version 0.13.0-beta2 (SVN r298)
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
PDF renderer: MuPDF 1.4 or newer
OpenGL renderer: FD630

- with mupdf-tools 1.19.0+ds1-2 and pdftk-java 3.2.2-1:
  - Rendering is nicer
  - Impressive reports:
Welcome to Impressive version 0.13.0-beta2 (SVN r298)
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
PDF renderer: Xpdf/Poppler
OpenGL renderer: FD630

- with mupdf-tools 1.19.0+ds1-2 and pdftk-java uninstalled:
  - Rendering is ugly
  - Impressive reports:
Welcome to Impressive version 0.13.0-beta2 (SVN r298)
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
PDF renderer: MuPDF 1.4 or newer
pdftkParse() FAILED
OpenGL renderer: FD630

- with both mupdf-tools and pdftk-java uninstalled:
  - No rendering
  - Impressive reports:
Welcome to Impressive version 0.13.0-beta2 (SVN r298)
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
PDF renderer: Xpdf/Poppler
pdftkParse() FAILED
WARNING: The input file 
`/home/gwolf/vcs/sistemas_operativos/laminas/08_algoritmos_planif_proc.pdf' 
could not be analyzed.
The presentation doesn't have any pages, quitting.

I think the result for having both installed should be to default for
the best renderer. If none are available, of course, impressive should
fail -- but the message it conveys is quite cryptic (it does not say
the renderer is not there; in fact, it points at xpdf/poppler. Why
does it fail?)

But more than impressive's message... if either pdftk-java or
mupdf-tools are required for impressive to be useful, they should be
declared as alternative dependencies (defaulting to... well, that's
your criteria ).

Thanks!

Bug#915117: xdg-desktop-portal: Recommend a backend?

[Simon McVittie]

Control: tags -1 + wontfix

On Fri, 30 Nov 2018 at 11:37:16 -0500, Jeremy Bicha wrote:
> Should xdg-desktop-portal recommend the virtual package
> xdg-desktop-portal-backend?

I don't think it should, because that would be a circular Recommends
(Depends in one direction, Recommends in the other) which would prevent
x-d-p and its backends from being cleaned up when unused.

> I see that Debian's Flatpak has this so maybe we should just copy it:
> Recommends: xdg-desktop-portal-gtk | xdg-desktop-portal-backend

I think packages that *use* xdg-desktop-portal, such as Flatpak, should
be the ones responsible for doing this.

smcv

Bug#1008061: node-builtins: Returns a wrong list of builtins module

[Yadd]

Package: node-builtins
Version: 4.0.0-1
Severity: important

Hi,

node-builtins returns a static modules list which is up-to date for
Node.js < 11. It should be patched to use node-builtin-modules result
for node.js >= 12

Bug#1006920: please split out a libtbbmalloc2 package, both in tbb and onetbb

[Jose Luis Rivero]

On Tue, 8 Mar 2022 10:30:53 +0100 Matthias Klose  wrote:
>
> For Ubuntu, I'm going to rename the old libtbb-dev and libtbb-doc
packages to
> libtbb2-dev and libtbb2-doc, not sure if that's something you also want
to do in
> Debian, but for the next Ubuntu release we need to ship both versions, or
we
> need to remove packages like numba.

Following this up, the split of the libraries is breaking some common use
cases in the robotics community, see
https://github.com/ros-planning/navigation2/pull/2852#issuecomment-1072789270
.

I think that it will handle nicely in Debian, for the next Ubuntu I've
requested a sync from the experimental version (which is able to use new
tbb)
https://bugs.launchpad.net/ubuntu/+source/gazebo/+bug/1965780

Thanks.

Bug#1008059: systemd-timesyncd restarted on every router advertisment

[Michael Biebl]

Control: reassign dhcpcd5

Am 21.03.22 um 17:39 schrieb Michael Biebl:


Am 21.03.22 um 17:36 schrieb Michael Biebl:


Is that a result of /etc/dhcp/dhclient-exit-hooks.d/timesyncd ?

What happens if you remove that dhclient hook



Actually, I think it might be
dhcpcd5: /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf

which triggers the service restart, i.e. it would be a dhcpcd5 issue.


Reassigning accordingly.

# cat /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf
# vi: ft=sh

SERVERFILE_IPV4="/run/systemd/timesyncd.conf.d/01-dhcpcd.ipv4.$interface.conf"
SERVERFILE_IPV6="/run/systemd/timesyncd.conf.d/01-dhcpcd.ipv6.$interface.conf"

reload_config() {
systemctl try-restart systemd-timesyncd.service || :
}



OpenPGP_signature
Description: OpenPGP digital signature

Bug#934025: chromium: can't access mic ( no audio input ), works fine in firefox

[Gabriel]

Hi All
Iǘe just tested that in my pc

Versión 90.0.4430.212 (Build para desarrolladores) built on Debian 10.9, 
running on Debian 10.11 (64 bits)


and works fine

Cheers
Gabriel

El 20/3/22 a las 04:19, Andres Salomon escribió:


Hi,

Can you tell me if this issue is resolved with the latest chromium 
(v99) or not?


Thanks,

Andres


On Tue, 06 Aug 2019 01:08:00 -0700 Ximin Luo wrote:

> Package: chromium
> Version: 76.0.3809.87-2+b1
> Severity: important
>
> Dear Maintainer,
>
> Chromium can't access the microphone, the result is the same from 
multiple websites

> (meet.jit.si, appear.in, google meet, etc)
>
> When visiting 
https://webrtc.github.io/samples/src/content/getusermedia/volume/

> the console says:
>
> navigator.MediaDevices.getUserMedia error: Requested device not 
found NotFoundError

>
> Note that this bug is separate from #923028, I do not see any 
console messages about
> "not allowed to start", the audio device(s) themselves are invisible 
to chromium.

>
> I have looked in the following files:
>
> /etc/chromium/master_preferences
> /usr/share/chromium/master_preferences
> ~/.config/chromium/Default/Preferences
>
> and there is no key "audio_capture_enabled" anywhere. So the issue 
seems distinct

> from #885155 #884887 #889067 as well.
>
> X
>
>
> -- System Information:
> Debian Release: bullseye/sid
> APT prefers testing
> APT policy: (990, 'testing'), (500, 'stable'), (300, 'unstable'), 
(200, 'experimental')

> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)

> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages chromium depends on:
> ii chromium-common 76.0.3809.87-2+b1
> ii libasound2 1.1.8-1
> ii libatk-bridge2.0-0 2.30.0-5
> ii libatk1.0-0 2.30.0-2
> ii libatomic1 9.1.0-10
> ii libatspi2.0-0 2.30.0-7
> ii libavcodec58 7:4.1.4-1
> ii libavformat58 7:4.1.4-1
> ii libavutil56 7:4.1.4-1
> ii libc6 2.28-10
> ii libcairo-gobject2 1.16.0-4
> ii libcairo2 1.16.0-4
> ii libcups2 2.2.10-6
> ii libdbus-1-3 1.12.16-1
> ii libdrm2 2.4.97-1
> ii libevent-2.1-6 2.1.8-stable-4
> ii libexpat1 2.2.7-1

Bug#1007222: transition: onetbb

[Jose Luis Rivero]

On Mon, 14 Mar 2022 02:30:08 +0100 Matthias Klose  wrote:
> >
> > I have not tested by myself, but I heard from an archlinux
> > developer that this API bump breaks a lot packages. And
> > some upstreams decided to disable or drop tbb support as
> > a result. I guess we can take similar measures for short
> > term workaround.
>
> "I heard from archlinux" is not good enough.  I sent you email about this
> without getting a reply, then filed #1006920, without getting a reply,
now this
> incomplete proposal. you may want to look at all the build rdeps for
libtbb2-dev
> in Ubuntu to get an overview what at least breaks:
>
> $ reverse-depends -b libtbb2-dev
>
> Reverse-Testsuite-Triggers
>
> * intel-mkl
>
>
>
> Reverse-Build-Depends
>
...
>
> * gazebo
>

Speaking as the maintainer of Gazebo, upstream has released a new 11.10.2
version that is compatible with new tbb. I've uploaded it to experimental,
it builds fine. The package should be ready for the transition as far as I
can tell.

Thanks guys for working on the transition.

Bug#1008059: systemd-timesyncd restarted on every router advertisment

[Michael Biebl]

Am 21.03.22 um 17:36 schrieb Michael Biebl:


Is that a result of /etc/dhcp/dhclient-exit-hooks.d/timesyncd ?

What happens if you remove that dhclient hook



Actually, I think it might be
dhcpcd5: /lib/dhcpcd/dhcpcd-hooks/64-timesyncd.conf

which triggers the service restart, i.e. it would be a dhcpcd5 issue.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008059: systemd-timesyncd restarted on every router advertisment

[Michael Biebl]

Am 21.03.22 um 17:23 schrieb Adam Dinwoodie:

Package: systemd-timesyncd
Version: 250.4-1
Severity: normal
Tags: ipv6

Dear Maintainer,

I'm seeing systemd restart systemd-timesyncd.service approximately every
10 seconds, lining up with when I see a log showing that my router has
advertised its IPv6 address.

If I run `journalctl -f`, the output is full of lines like the
following:

```
Mar 21 15:53:56 lucy.dinwoodie.org dhcpcd[452]: eth0: Router Advertisement from 
fe80::be99:11ff:fe69:4300
Mar 21 15:53:57 lucy.dinwoodie.org systemd[1]: Stopping Network Time 
Synchronization...
Mar 21 15:53:57 lucy.dinwoodie.org systemd[1]: systemd-timesyncd.service: 
Deactivated successfully.
Mar 21 15:53:57 lucy.dinwoodie.org systemd[1]: Stopped Network Time 
Synchronization.
Mar 21 15:53:57 lucy.dinwoodie.org systemd[1]: Starting Network Time 
Synchronization...
Mar 21 15:53:57 lucy.dinwoodie.org systemd[1]: Started Network Time 
Synchronization.
Mar 21 15:53:57 lucy.dinwoodie.org systemd-timesyncd[6426]: Initial 
synchronization to time server 162.159.200.1:123 (0.debian.pool.ntp.org).
Mar 21 15:54:06 lucy.dinwoodie.org dhcpcd[452]: eth0: Router Advertisement from 
fe80::be99:11ff:fe69:4300
Mar 21 15:54:07 lucy.dinwoodie.org systemd[1]: Stopping Network Time 
Synchronization...
Mar 21 15:54:07 lucy.dinwoodie.org systemd[1]: systemd-timesyncd.service: 
Deactivated successfully.
Mar 21 15:54:07 lucy.dinwoodie.org systemd[1]: Stopped Network Time 
Synchronization.
Mar 21 15:54:07 lucy.dinwoodie.org systemd[1]: Starting Network Time 
Synchronization...
Mar 21 15:54:07 lucy.dinwoodie.org systemd[1]: Started Network Time 
Synchronization.
Mar 21 15:54:07 lucy.dinwoodie.org systemd-timesyncd[6463]: Initial 
synchronization to time server 178.62.18.76:123 (0.debian.pool.ntp.org).
```



Is that a result of /etc/dhcp/dhclient-exit-hooks.d/timesyncd ?

What happens if you remove that dhclient hook



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008060: pcb: pcb-gtk could suggest pcb-rnd (natural upgrade path when gtk2 phases out)

[debbug2]

Source: pcb
Severity: minor

Dear Maintainer,

gtk2 is likely to be removed from Debian in the not too far future, 
#947713.

I am following the development of pcb, and I don't think the project has 
the resources for porting to gtk3 or gtk4 (there are hardly any commits 
these days at all). Which means a gtk2 removal would force users to use 
pcb-lesstif, which doesn't differ only in the GUI toolkit but offers 
reduced GUI functionality (less widgets, less dialog boxes). Or it would 
force users to switch to another layout editor.

Meanwhile pcb-rnd, which once started as a fork of pcb, runs fine with 
gtk4 with latest librnd (already available in Debian sid). pcb-rnd can 
read and write all native file formats of pcb. It has changed and 
progressed a lot since the original fork, but the basic concepts and the 
GUI are still somewhat similar to pcb's so pcb users would find it more 
familiar than e.g. KiCad.

If gtk2 is phased out and pcb won't provide a gtk3/gtk4 HID by then, pcb 
users will either need to "downgrade" to pcb-lesstif or "upgrade" to 
pcb-rnd or learn a totally different branch of EDA from scratch. For 
anyone who installs pcb-gtk, it may be easy to find pcb-lesstif, but it 
may be less trivial to find pcb-rnd as a "natural upgrade path".

Thus I propose pcb-gtk could Suggest pcb-rnd. This would help users learn 
about pcb-rnd as a natural alternative to pcb-gtk, before they are forced 
to change their habits, may pcb fail to port to gtk3/gtk4 in time.



-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 3 (beowulf)
Release:3
Codename:   beowulf
Architecture: x86_64

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

Bug#1008059: systemd-timesyncd restarted on every router advertisment

[Adam Dinwoodie]

Package: systemd-timesyncd
Version: 250.4-1
Severity: normal
Tags: ipv6

Dear Maintainer,

I'm seeing systemd restart systemd-timesyncd.service approximately every
10 seconds, lining up with when I see a log showing that my router has
advertised its IPv6 address.

If I run `journalctl -f`, the output is full of lines like the
following:

```
Mar 21 15:53:56 lucy.dinwoodie.org dhcpcd[452]: eth0: Router Advertisement from 
fe80::be99:11ff:fe69:4300
Mar 21 15:53:57 lucy.dinwoodie.org systemd[1]: Stopping Network Time 
Synchronization...
Mar 21 15:53:57 lucy.dinwoodie.org systemd[1]: systemd-timesyncd.service: 
Deactivated successfully.
Mar 21 15:53:57 lucy.dinwoodie.org systemd[1]: Stopped Network Time 
Synchronization.
Mar 21 15:53:57 lucy.dinwoodie.org systemd[1]: Starting Network Time 
Synchronization...
Mar 21 15:53:57 lucy.dinwoodie.org systemd[1]: Started Network Time 
Synchronization.
Mar 21 15:53:57 lucy.dinwoodie.org systemd-timesyncd[6426]: Initial 
synchronization to time server 162.159.200.1:123 (0.debian.pool.ntp.org).
Mar 21 15:54:06 lucy.dinwoodie.org dhcpcd[452]: eth0: Router Advertisement from 
fe80::be99:11ff:fe69:4300
Mar 21 15:54:07 lucy.dinwoodie.org systemd[1]: Stopping Network Time 
Synchronization...
Mar 21 15:54:07 lucy.dinwoodie.org systemd[1]: systemd-timesyncd.service: 
Deactivated successfully.
Mar 21 15:54:07 lucy.dinwoodie.org systemd[1]: Stopped Network Time 
Synchronization.
Mar 21 15:54:07 lucy.dinwoodie.org systemd[1]: Starting Network Time 
Synchronization...
Mar 21 15:54:07 lucy.dinwoodie.org systemd[1]: Started Network Time 
Synchronization.
Mar 21 15:54:07 lucy.dinwoodie.org systemd-timesyncd[6463]: Initial 
synchronization to time server 178.62.18.76:123 (0.debian.pool.ntp.org).
```

There's no great immediate impact, but it seems like this shouldn't be
happening.  And there is clearly some impact in terms of unnecessary
disk churn, unnecessary network usage, unnecessary load on NTP servers,
and -- still minor, but most relevant to my immediate interests --
ability to spot interesting logs in journald.

Some searching online led me to a very old systemd bug[0], but that was
apparently resolved in systemd 219, so definitely shouldn't be relevant
now.

[0]: https://bugs.freedesktop.org/show_bug.cgi?id=87505

Other searches pointed me to other people reporting similar
problems[1][2] with no resolution. It's possibly of interest is that
they're all folk (like me) running on a Raspberry Pi.  At least in my
case, however, I understand the only difference between what I'm running
and a regular arm64 Debian installation is that there are a few driver
and firmware packages shipped from the Raspberry Pi Foundation.
Certainly all the systemd packages I'm using have come straight from
deb.debian.org repositories.

[1]: https://raspberrypi.stackexchange.com/q/133605/145463
[2]: https://forums.raspberrypi.com/viewtopic.php?t=324473

Given that, I suspect whatever the issue is may be due to one or more of
(a) folks using Raspberry Pis are going to be running an arm-based
architecture, or (b) folks using Pis are more likely to be running very
minimal Debian installations, so are more likely to have not installed
packages that might not be listed as dependencies but whose absence
causes non-obvious problems.

Admittedly there's also (c) there's something up with the config that's
used on Raspberry Pis by default, but I've done my best to rule that
out: I can't see anything in the documentation for dhcpcd,
systemd-networkd or systemd-timesyncd that would cause this behaviour,
nor anything in any of the configuration in /etc/systemd/.

I'm seeing this behaviour on /bullseye (247.3-6), /bullseye-backports
(250.4-1~bpoll+1), and /sid (250.4-1).

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (850, 'testing'), (500, 'unstable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.103-v8+ (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd-timesyncd depends on:
ii  adduser  3.118
ii  libc62.33-7
ii  systemd  250.4-1

systemd-timesyncd recommends no packages.

systemd-timesyncd suggests no packages.

-- no debconf information

Bug#1007971: Key location is deprecated? Show me!

[Julian Andres Klode]

Control: tag -1 wontfix

On Sat, Mar 19, 2022 at 08:46:17PM +0100, Harald Dunkel wrote:
> Package: apt
> Version: 2.4.1
> Severity: wishlist
> 
> apt update gives me several messages like
> 
> W: http://example.com/debian/dists/unstable/InRelease: Key is stored in 
> legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION 
> section in apt-key(8) for details.
> W: https://download.something.com/linux/debian/dists/buster/InRelease: Key is 
> stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the 
> DEPRECATION section in apt-key(8) for details.
> W: https://updates.ohnonotagain.org/desktop/apt/dists/xenial/InRelease: Key 
> is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the 
> DEPRECATION section in apt-key(8) for details.
> 
> This could be much more helpful if it would actually show the key id
> it was looking for. *All* warnings and errors about some key id should
> show it.

I don't think this is going to happen. It adds additional work,
keyid is the wrong thing to show (fpr would be the right thing),
and you really should not have to bother with GPG keys at all,
just files.

I think we should also hide from error messages which keys are
missing.

Showing key ids of any form just leads to people Googling for
key ids and finding weird instructions on how to add them.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#1008058: RFS: streamlink/3.2.0-1~bpo11+1 -- CLI for extracting video streams from various websites to a video player

[Alexis Murzeau]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-backpo...@lists.debian.org

Dear mentors,

I am looking for a sponsor for my package "streamlink" into Debian
bullseye-backports repository.

 * Package name: streamlink
   Version : 3.2.0-1~bpo11+1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  python3-streamlink - Python module for extracting video streams from various 
websites
  python3-streamlink-doc - CLI for extracting video streams from various 
websites (documentation)
  streamlink - CLI for extracting video streams from various websites to a 
video player

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_3.2.0-1~bpo11+1.dsc

Changes since the last upload to bullseye-backports:
streamlink (3.2.0-1~bpo11+1) bullseye-backports; urgency=medium

  * Rebuild for bullseye-backports.
  * Update changelog for 3.1.1-1~bpo11+1 release

 -- Alexis Murzeau   Mon, 21 Mar 2022 16:18:02 +0100

streamlink (3.2.0-1) unstable; urgency=medium

  * d/README.source: update with basic instructions
  * d/README.source: fix gbp tag and add push to remote
  * d/rules: add LANG var to have reproducible builds (See #998059)
  * New upstream version 3.2.0
  * d/patches: update patches
  * lintian-overrides: adjust filter for changelogs

 -- Alexis Murzeau   Sat, 05 Mar 2022 22:55:24 +0100


Differences from testing package (3.2.0-1):
  * d/README.source: added more information about the package maintenance

Regards,
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|





signature.asc
Description: OpenPGP digital signature

Bug#1008056: buster-pu: package libnet-ssleay-perl/1.85-2.1

[Adrian Bunk]

On Mon, Mar 21, 2022 at 05:46:21PM +0200, Adrian Bunk wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: Debian Perl Group 
> , Debian OpenSSL Team 
> 
> 
>   * Backport upstream fix for test failures with OpenSSL 1.1.1n.
> (Closes: #1008055)
> 
> The fix touches only tests and documentation:
>  b/lib/Net/SSLeay.pod|4 -
>  b/t/data/test_CA1_2048.crt.pem  |   20 ++
>  b/t/data/test_CA1_2048.key.pem  |   28 
>  b/t/data/testcert_key_2048.pem.e|   30 +
>  b/t/data/testcert_wildcard_CA1_2048.crt.pem |   89 
> 
>  b/t/local/05_passwd_cb.t|2
>  b/t/local/07_sslecho.t  |   52 +---
>  b/t/local/08_pipe.t |6 -
>  b/t/local/36_verify.t   |8 +-
>  b/t/local/40_npn_support.t  |4 -
>  b/t/local/41_alpn_support.t |4 -
>  b/t/local/42_info_callback.t|4 -
>  b/t/local/50_digest.t   |   24 +--
>  b/t/local/61_threads-cb-crash.t |2
>  b/t/local/64_ticket_sharing.t   |9 +-
>  t/data/cert.pem |   23 ---
>  t/data/key.pem  |   15 
>  t/data/key.pem.e|   17 -
>  18 files changed, 221 insertions(+), 120 deletions(-)

And here comes the missing attachment with the diff.

cu
Adrian

diff -Nru libnet-ssleay-perl-1.85/debian/changelog 
libnet-ssleay-perl-1.85/debian/changelog
--- libnet-ssleay-perl-1.85/debian/changelog2018-09-02 23:19:51.0 
+0300
+++ libnet-ssleay-perl-1.85/debian/changelog2022-03-21 17:36:31.0 
+0200
@@ -1,3 +1,11 @@
+libnet-ssleay-perl (1.85-2.1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport upstream fix for test failures with OpenSSL 1.1.1n.
+(Closes: #1008055)
+
+ -- Adrian Bunk   Mon, 21 Mar 2022 17:36:31 +0200
+
 libnet-ssleay-perl (1.85-2) unstable; urgency=medium
 
   [ Damyan Ivanov ]
diff -Nru 
libnet-ssleay-perl-1.85/debian/patches/0001-Use-2048-bit-RSA-keys-certificates-in-tests.patch
 
libnet-ssleay-perl-1.85/debian/patches/0001-Use-2048-bit-RSA-keys-certificates-in-tests.patch
--- 
libnet-ssleay-perl-1.85/debian/patches/0001-Use-2048-bit-RSA-keys-certificates-in-tests.patch
   1970-01-01 02:00:00.0 +0200
+++ 
libnet-ssleay-perl-1.85/debian/patches/0001-Use-2048-bit-RSA-keys-certificates-in-tests.patch
   2022-03-21 17:36:17.0 +0200
@@ -0,0 +1,714 @@
+From d7b8428e7810f5e1729a197a076df0226b509fab Mon Sep 17 00:00:00 2001
+From: Chris Novakovic 
+Date: Wed, 1 May 2019 10:24:02 +0100
+Subject: Use 2048-bit RSA keys/certificates in tests
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The test suite makes heavy use of t/data/key.pem and t/data/cert.pem,
+which involves the use of 1024-bit RSA keys. Several Linux distributions
+now ship with an OpenSSL configuration file that sets the security level
+to 2 by default, which forbids the use of keys this short, causing tests
+that use them to fail.
+
+The test suite includes 2048-bit RSA keys and certificates
+(t/data/testcert_key_2048.pem and t/data/testcert_wildcard.crt.pem
+respectively), which are already in use in some (usually newer) tests.
+Retire the 1024-bit keys in favour of the 2048-bit keys:
+
+* Replace all remaining uses of t/data/key.pem in the test suite with
+  t/data/testcert_key_2048.pem.
+* Create t/data/testcert_key_2048.pem.e (testcert_key_2048.pem encrypted
+  with AES-256-CBC using the passphrase "secret") and replace all
+  remaining uses of t/data/key.pem.e in the test suite with
+  testcert_key_2048.pem.e.
+* Replace all remaining uses of t/data/cert.pem in the test suite with
+  t/data/testcert_wildcard.crt.pem.
+* Create 2048-bit CA key at t/data/test_CA1_2048.key.pem and
+  certificates at t/data/test_CA1_2048.crt.pem and
+  t/data/testcert_wildcard_CA1_2048.crt.pem, and use them in
+  t/local/07_sslecho.t and t/local/36_verify.t in place of the 1024-bit
+  CA keys/certificates. Thanks to Heikki Vatiainen for debugging and
+  fixing this.
+* Remove the digest check for t/data/cert.pem in t/local/50_digest.t
+  altogether: the same digests for t/data/binary-test.file are already
+  tested, and it's not clear what benefit another one provides.
+* In t/local/07_sslecho.t, don't make assumptions about the chain of
+  trust for the certificates being used; this breaks the tests when
+  keys/certificates other than the old 1024-bit ones are used. Thanks to
+  Heikki Vatiainen for debugging and fixing this.
+* Remove references to t/data/key.pem and t/data/cert.pem from the
+  Net::SSLeay documentation (they probably shouldn't have been there
+  anyway).
+* Remove the calls to 

Bug#913310: nfs-common: Systemd does not correctly read /etc/default/nfs-common

[Marco Gaiarin]

Mandi! Ben Hutchings
  In chel di` si favelave...

> What is the actual problem you are trying to solve?

digging harder on my email folders... in october 2018 i was trying to
make NFSv4 work in a Samba/AD/Kerberos environment.

Probably after that i've found a way to circumvent the need, probably
switching to CIFS.

Some more hint on samba mailing list thread starting at:

https://lists.samba.org/archive/samba/2018-October/218969.html
https://lists.samba.org/archive/samba/2018-November/219218.html


Sorry, i don't remember more...

Bug#1007165: [Pkg-privacy-maintainers] Bug#1007165: Bug#1007165: please import upstream v21.1.0

[Antoine Beaupré]

I'm working on uploading v22 right now.

-- 
In a racist society it is not enough to be non-racist, we must be antiracist.
- Angela Davis 

Bug#1008056: buster-pu: package libnet-ssleay-perl/1.85-2.1

[Adrian Bunk]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: Debian Perl Group , 
Debian OpenSSL Team 

  * Backport upstream fix for test failures with OpenSSL 1.1.1n.
(Closes: #1008055)

The fix touches only tests and documentation:
 b/lib/Net/SSLeay.pod|4 -
 b/t/data/test_CA1_2048.crt.pem  |   20 ++
 b/t/data/test_CA1_2048.key.pem  |   28 
 b/t/data/testcert_key_2048.pem.e|   30 +
 b/t/data/testcert_wildcard_CA1_2048.crt.pem |   89 
 b/t/local/05_passwd_cb.t|2
 b/t/local/07_sslecho.t  |   52 +---
 b/t/local/08_pipe.t |6 -
 b/t/local/36_verify.t   |8 +-
 b/t/local/40_npn_support.t  |4 -
 b/t/local/41_alpn_support.t |4 -
 b/t/local/42_info_callback.t|4 -
 b/t/local/50_digest.t   |   24 +--
 b/t/local/61_threads-cb-crash.t |2
 b/t/local/64_ticket_sharing.t   |9 +-
 t/data/cert.pem |   23 ---
 t/data/key.pem  |   15 
 t/data/key.pem.e|   17 -
 18 files changed, 221 insertions(+), 120 deletions(-)

Bug#1008055: libnet-ssleay-perl/buster FTBFS and autopkgtest failure with OpenSSL 1.1.1n

[Adrian Bunk]

Source: libnet-ssleay-perl
Version: 1.85-2
Severity: serious
Tags: ftbfs
Forwarded: 
https://github.com/radiator-software/p5-net-ssleay/commit/a3d40e9a7d89903be20de7c0973da90ebb3293bf
Control: close -1 1.88-1

https://ci.debian.net/data/autopkgtest/oldstable/amd64/libn/libnet-ssleay-perl/20203562/log.gz

...
Test Summary Report
---
t/local/40_npn_support.t (Wstat: 512 Tests: 7 Failed: 4)
  Failed tests:  2-3, 5-6
  Non-zero exit status: 2
t/local/41_alpn_support.t(Wstat: 256 Tests: 6 Failed: 3)
  Failed tests:  2-3, 5
  Non-zero exit status: 1
t/local/42_info_callback.t   (Wstat: 512 Tests: 2 Failed: 2)
  Failed tests:  1-2
  Non-zero exit status: 2
Files=32, Tests=2993,  5 wallclock secs ( 0.25 usr  0.07 sys +  4.37 cusr  0.51 
csys =  5.20 CPU)
Result: FAIL

Bug#1008054: Remove debian-es.org links from website

[Enrico Zini]

Package: www.debian.org
Severity: normal

Hello,

it looks like the debian-es.org domain has expired and has been picked
up by some cybersquatter.

We have some links to it in the website, which should probably be
removed.


Thanks,

Enrico

Bug#1008053: cups-client: lpoptions as root doesn't update /etc/cups/lpoptions

[Yair Yarom]

Package: cups-client
Version: 2.3.3op2-3+deb11u1huji
Severity: normal
Tags: patch

Dear Maintainer,

Running lpoptions as root (e.g. "lpoptions -d mafil") should update
/etc/cups/lpoptions to be the defaults for all users (at least it was in the
past and still claim to do so in the manual). But instead it tries to update
/root/.cups/lpoptions.

Attached is a patch to fix it (to actually check the uid instead of home).

-- System Information:
Debian Release: 11.2
  APT prefers stable-security
  APT policy: (910, 'stable-security'), (900, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.104-aufs-2 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_IL.UTF-8, LC_CTYPE=en_IL.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en_GB:en
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages cups-client depends on:
ii  adduser  3.118
ii  cups-common  2.3.3op2-3+deb11u1huji
ii  libc62.31-13+deb11u2
ii  libcups2 2.3.3op2-3+deb11u1huji

cups-client recommends no packages.

Versions of packages cups-client suggests:
ii  cups   2.3.3op2-3+deb11u1
ii  cups-bsd   2.3.3op2-3+deb11u1
ii  smbclient  2:4.13.13+dfsg-1~deb11u2

-- no debconf information
--- a/cups/dest.c
+++ b/cups/dest.c
@@ -2067,7 +2067,11 @@
 
   snprintf(filename, sizeof(filename), "%s/lpoptions", cg->cups_serverroot);
 
-  if (cg->home)
+  if (cg->home
+#ifndef _WIN32
+  && getuid() != 0
+#endif
+  )
   {
/*
 * Create ~/.cups subdirectory...

Bug#994622: bullseye-pu: package network-manager/1.30.6-1~deb11u1

[Michael Biebl]

Am 21.03.22 um 15:56 schrieb Julien Cristau:

On Mon, Mar 21, 2022 at 03:46:01PM +0100, Michael Biebl wrote:


Am 21.03.22 um 15:36 schrieb Julien Cristau:


Yes.  Thanks for the due diligence.


Just a quick question:
Which version number should I pick?

a/ 1.30.6-1~deb11u1
b/ 1.30.6-1+deb11u1
c/ 1.30.6-2


I think, now that I have made changes (with the revert of the WPA3 bits)
compared to 1.30.6-1, b/ is the most suitable one. But I wanted to double
check before I upload.


b/ sounds good :)


Uploaded.
Thanks a lot for your review, Julien.

Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006507: mit-scheme: FTBFS with OpenSSL 3.0

[Nick Rosbrook]

Package: mit-scheme
Version: 11.2-2
Followup-For: Bug #1006507
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to fix the mit-scheme build:

  * d/p/0001-microcode-Make-definition-for-chacha_core-match-decl.patch:
Pull in upstream patch to fix -Werror=array-parameter build error.
(LP: #1965163).

Thanks,
Nick
diff -Nru 
mit-scheme-11.2/debian/patches/0001-microcode-Make-definition-for-chacha_core-match-decl.patch
 
mit-scheme-11.2/debian/patches/0001-microcode-Make-definition-for-chacha_core-match-decl.patch
--- 
mit-scheme-11.2/debian/patches/0001-microcode-Make-definition-for-chacha_core-match-decl.patch
  1969-12-31 19:00:00.0 -0500
+++ 
mit-scheme-11.2/debian/patches/0001-microcode-Make-definition-for-chacha_core-match-decl.patch
  2022-03-16 13:36:47.0 -0400
@@ -0,0 +1,29 @@
+Description: Make definition for chacha_core match declaration.
+ Makes no semantic difference but some compilers object now.
+Origin: upstream, 
https://git.savannah.gnu.org/cgit/mit-scheme.git/commit/?id=837bb3f1ca75f867e115bf3a195de2f78517dce1
+Last-Update: 2022-03-16
+---
+From 837bb3f1ca75f867e115bf3a195de2f78517dce1 Mon Sep 17 00:00:00 2001
+From: Taylor R Campbell 
+Date: Fri, 7 May 2021 16:02:08 +
+Subject: [PATCH] microcode: Make definition for chacha_core match declaration.
+
+Makes no semantic difference but some compilers object now.
+---
+ src/microcode/chacha.i | 6 --
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+--- a/src/microcode/chacha.i
 b/src/microcode/chacha.i
+@@ -77,8 +77,10 @@
+ static const uint8_t chacha_core_constant32[16] = "expand 32-byte k";
+ 
+ void
+-chacha_core(uint8_t *out, const uint8_t *in, const uint8_t *k,
+-const uint8_t *c)
++chacha_core(uint8_t out[chacha_core_OUTPUTBYTES],
++const uint8_t in[chacha_core_INPUTBYTES],
++const uint8_t k[chacha_core_KEYBYTES],
++const uint8_t c[chacha_core_CONSTBYTES])
+ {
+   uint32_t x0,x1,x2,x3,x4,x5,x6,x7,x8,x9,x10,x11,x12,x13,x14,x15;
+   uint32_t j0,j1,j2,j3,j4,j5,j6,j7,j8,j9,j10,j11,j12,j13,j14,j15;
diff -Nru mit-scheme-11.2/debian/patches/series 
mit-scheme-11.2/debian/patches/series
--- mit-scheme-11.2/debian/patches/series   2021-08-25 06:09:35.0 
-0400
+++ mit-scheme-11.2/debian/patches/series   2022-03-16 13:15:56.0 
-0400
@@ -4,3 +4,4 @@
 0004-makeinfo-5-fix.patch
 0005-man-page.patch
 0007-verbose-texi2dvi.patch
+0001-microcode-Make-definition-for-chacha_core-match-decl.patch

Bug#994622: bullseye-pu: package network-manager/1.30.6-1~deb11u1

[Julien Cristau]

On Mon, Mar 21, 2022 at 03:46:01PM +0100, Michael Biebl wrote:
> 
> Am 21.03.22 um 15:36 schrieb Julien Cristau:
> 
> > Yes.  Thanks for the due diligence.
> 
> Just a quick question:
> Which version number should I pick?
> 
> a/ 1.30.6-1~deb11u1
> b/ 1.30.6-1+deb11u1
> c/ 1.30.6-2
> 
> 
> I think, now that I have made changes (with the revert of the WPA3 bits)
> compared to 1.30.6-1, b/ is the most suitable one. But I wanted to double
> check before I upload.
> 
b/ sounds good :)

Thanks,
Julien

Bug#1003293: buster-pu: package postfix/3.4.14-0+deb10u1

[Scott Kitterman]

On Saturday, March 19, 2022 12:42:32 PM EDT Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2022-01-07 at 13:01 -0500, Scott Kitterman wrote:
> > This is similar to #1003261 for bullseye, although there are fewer
> > Debian specific changes because most weren't applicable to or would
> > have
> > been more invasive for buster.
> > 
> > I've put together my usual postfix post-release update.  Because I'm
> > behind, it's rather larger than usual.  Also, a number of packaging
> > bugs
> > that apply to buster have been recently fixed in Bookworm, so the low
> 
> Please feel free to go ahead; sorry for the delay.

Uploaded.

Scott K

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

Bug#1003261: bullseye-pu: package postfix/3.5.6-1

[Scott Kitterman]

On Saturday, March 19, 2022 12:12:35 PM EDT Julien Cristau wrote:
> Control: tag -1 confirmed
> 
> On Fri, Jan 07, 2022 at 12:37:35AM -0500, Scott Kitterman wrote:
> > Package: release.debian.org
> > Severity: normal
> > Tags: bullseye
> > User: release.debian@packages.debian.org
> > Usertags: pu
> > 
> > I've put together my usual postfix post-release update.  Because I'm
> > behind, it's rather larger than usual.  Also, a number of packaging bugs
> > that apply to bullseye have been recently fixed in Bookworm, so the low
> > risk changes there have been backported too.
> > 
> > The diff is rather large, so I don't include it in the original bug
> > report to increase the chances this makes it to the mailing list.
> 
> Go ahead, thanks.
> 
> I noticed a typo in postfix.postinst:
> +   # If the user has picked something other than sntp, keep it
> 
> s/sntp/smtp/ :)

Thanks.  Fixed in git for the next upload to Unstable.

Uploaded.

Scott K

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

Bug#1008052: python-pecan FTBFS: build tests fail with python3.10

[Nick Rosbrook]

Package: python-pecan
Version: 1.3.3-4
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to fix the build tests when
using python3.10:

  * debian/patches/fix-tests-on-python-3.10.patch: Pull in upstream patch to
fix build tests on python3.10 (LP: #1965132).

Thanks,
Nick
diff -Nru python-pecan-1.3.3/debian/patches/fix-tests-on-python-3.10.patch 
python-pecan-1.3.3/debian/patches/fix-tests-on-python-3.10.patch
--- python-pecan-1.3.3/debian/patches/fix-tests-on-python-3.10.patch
1969-12-31 19:00:00.0 -0500
+++ python-pecan-1.3.3/debian/patches/fix-tests-on-python-3.10.patch
2022-03-18 15:41:48.0 -0400
@@ -0,0 +1,87 @@
+Description: Fix tests to work on Python 3.10
+Origin: upstream, 
https://github.com/pecan/pecan/pull/131/commits/f189d0eafbaacc5b5093bb8854cd2068e22b6c08
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/python-pecan/+bug/1965132
+---
+From f189d0eafbaacc5b5093bb8854cd2068e22b6c08 Mon Sep 17 00:00:00 2001
+From: Evangelos Foutras 
+Date: Wed, 8 Dec 2021 07:01:16 +0200
+Subject: [PATCH] Fix tests to work on Python 3.10
+
+Python 3.10 adds the class name to the exception; adjust four tests
+affected by this change.
+
+Fixes: https://github.com/pecan/pecan/issues/130
+---
+ pecan/tests/test_base.py | 18 +-
+ pecan/tests/test_no_thread_locals.py | 20 ++--
+ 2 files changed, 27 insertions(+), 11 deletions(-)
+--- a/pecan/tests/test_base.py
 b/pecan/tests/test_base.py
+@@ -456,8 +456,12 @@
+ assert type(ex) == TypeError
+ assert ex.args[0] in (
+ "index() takes exactly 2 arguments (1 given)",
+-"index() missing 1 required positional argument: 'id'"
+-)  # this messaging changed in Python 3.3
++"index() missing 1 required positional argument: 'id'",
++(
++"TestControllerArguments.app_..RootController."
++"index() missing 1 required positional argument: 'id'"
++),
++)  # this messaging changed in Python 3.3 and again in Python 3.10
+ 
+ def test_single_argument(self):
+ r = self.app_.get('/1')
+@@ -994,9 +998,13 @@
+ except Exception as ex:
+ assert type(ex) == TypeError
+ assert ex.args[0] in (
+-"eater() takes at least 2 arguments (1 given)",
+-"eater() missing 1 required positional argument: 'id'"
+-)  # this messaging changed in Python 3.3
++"eater() takes exactly 2 arguments (1 given)",
++"eater() missing 1 required positional argument: 'id'",
++(
++"TestControllerArguments.app_..RootController."
++"eater() missing 1 required positional argument: 'id'"
++),
++)  # this messaging changed in Python 3.3 and again in Python 3.10
+ 
+ def test_one_remainder(self):
+ r = self.app_.get('/eater/1')
+--- a/pecan/tests/test_no_thread_locals.py
 b/pecan/tests/test_no_thread_locals.py
+@@ -361,9 +361,13 @@
+ except Exception as ex:
+ assert type(ex) == TypeError
+ assert ex.args[0] in (
+-"index() takes exactly 4 arguments (3 given)",
+-"index() missing 1 required positional argument: 'id'"
+-)  # this messaging changed in Python 3.3
++"index() takes exactly 2 arguments (1 given)",
++"index() missing 1 required positional argument: 'id'",
++(
++"TestControllerArguments.app_..RootController."
++"index() missing 1 required positional argument: 'id'"
++),
++)  # this messaging changed in Python 3.3 and again in Python 3.10
+ 
+ def test_single_argument(self):
+ r = self.app_.get('/1')
+@@ -763,9 +767,13 @@
+ except Exception as ex:
+ assert type(ex) == TypeError
+ assert ex.args[0] in (
+-"eater() takes at least 4 arguments (3 given)",
+-"eater() missing 1 required positional argument: 'id'"
+-)  # this messaging changed in Python 3.3
++"eater() takes exactly 2 arguments (1 given)",
++"eater() missing 1 required positional argument: 'id'",
++(
++"TestControllerArguments.app_..RootController."
++"eater() missing 1 required positional argument: 'id'"
++),
++)  # this messaging changed in Python 3.3 and again in Python 3.10
+ 
+ def test_one_remainder(self):
+ r = self.app_.get('/eater/1')
diff -Nru python-pecan-1.3.3/debian/patches/series 

Bug#1008051: ITP: golang-github-chromedp-cdproto -- Commands, types, events for Chrome DevTools

[Guilherme de Paula Xavier Segundo]

Package: wnpp
Severity: wishlist
Owner: Guilherme de Paula Xavier Segundo 
X-Debbugs-Cc: debian-de...@lists.debian.org, guilherme@gmail.com

* Package name: golang-github-chromedp-cdproto
  Version : 0.0~git20220321.7bc2623-1
  Upstream Author : Kenneth Shaw 
* URL : https://github.com/chromedp/cdproto
* License : Expat
  Programming Lang: Go
  Description : Commands, types, events for Chrome DevTools

 Contains the generated commands, types, and events for the Chrome
 DevTools Protocol domains. This package is generated by the cdproto-gen
 command. Refer to that project and to the main chromedp project for
 information on using the commands, types, and events available here.

Bug#994622: bullseye-pu: package network-manager/1.30.6-1~deb11u1

[Michael Biebl]

Am 21.03.22 um 15:36 schrieb Julien Cristau:


Yes.  Thanks for the due diligence.


Just a quick question:
Which version number should I pick?

a/ 1.30.6-1~deb11u1
b/ 1.30.6-1+deb11u1
c/ 1.30.6-2


I think, now that I have made changes (with the revert of the WPA3 bits) 
compared to 1.30.6-1, b/ is the most suitable one. But I wanted to 
double check before I upload.


Regards,
Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#994622: bullseye-pu: package network-manager/1.30.6-1~deb11u1

[Julien Cristau]

Control: tag -1 confirmed

On Mon, Mar 21, 2022 at 03:28:48PM +0100, Michael Biebl wrote:
> 
> Hi Julien
> 
> Am 18.03.22 um 16:46 schrieb Julien Cristau:
> > Control: tag -1 moreinfo
> > 
> > Hi Michael,
> > 
> > Sorry it took so long to get to this.  I've got a couple of questions
> > from the NEWS file; will keep looking at the actual diff though.
> > 
> > On Mon, Sep 20, 2021 at 01:09:00PM +0200, Michael Biebl wrote:
> > > ===
> > > NetworkManager-1.30.6
> > > Overview of changes since NetworkManager-1.30.4
> > > ===
> > > 
> > > * By default, don't touch existing traffic control (TC) configuration
> > >on devices.
> > 
> > This sounds like it could cause unexpected changes.  Unsure about the
> > risk here.
> 
> The relevant bug report is
> https://bugzilla.redhat.com/show_bug.cgi?id=1928078
> 
> From the git commit
> "
> core,libnm: don't touch device TC configuration by default
> 
[...]
> 
> So, the new default behavior seems better than the previous one.
> 
> "
> 
> I'd say the above reasoning makes sense to me.
> 
I wasn't arguing that any of these changes were bad, they do sound like
improvements, my question was around the potential for unexpected side
effects, which we try to avoid in stable, even when it means having to
live with known bugs.  I'm happy to trust your judgement there, just
wanted to raise this.

[...]
> > > * Enable WPA3 for Wi-Fi connections with key_mgmt=WPA-PSK
> > 
> > What's the regression risk here, of things working without WPA3 but not
> > with it enabled?
> 
> That one I indeed missed. Thanks for spotting it. It has indeed the
> potential to break existing setups (as evidenced by [1]), although I think
> that would also need a newer wpasupplicant in stable.
> 
> The relevant upstream issue is
> https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/638
> 
> I think reverting these commits for stable would make sense.
> 
> Julien, if I revert the three commits from this MR, would you be ok with the
> upload?
> 
Yes.  Thanks for the due diligence.

Cheers,
Julien

Bug#1008050: golang-github-valyala-fasthttp: autopkgtest regression: 32-bit tests running on s390x

[Nick Rosbrook]

Package: golang-github-valyala-fasthttp
Version: 1:1.31.0-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to fix autopkgtest on s390x:

  * debian/patches/0001-bytesconv-add-appropriate-build-tags-for-s390x.patch:
Add appropriate build tags for s390x. This fixes an autopkgtest regression
on this architecture (LP: #1965134).

Thanks,
Nick
diff -Nru 
golang-github-valyala-fasthttp-1.31.0/debian/patches/0001-bytesconv-add-appropriate-build-tags-for-s390x.patch
 
golang-github-valyala-fasthttp-1.31.0/debian/patches/0001-bytesconv-add-appropriate-build-tags-for-s390x.patch
--- 
golang-github-valyala-fasthttp-1.31.0/debian/patches/0001-bytesconv-add-appropriate-build-tags-for-s390x.patch
  1969-12-31 19:00:00.0 -0500
+++ 
golang-github-valyala-fasthttp-1.31.0/debian/patches/0001-bytesconv-add-appropriate-build-tags-for-s390x.patch
  2022-03-16 09:52:43.0 -0400
@@ -0,0 +1,73 @@
+Description: Add appropriate build tags for s390x
+ The bytesconv 32-bit tests fail on s390x, because it is a 64-bit
+ architecture. Add the appropriate build flags so that 32-bit tests do
+ not run on this architecture.
+Author: Nick Rosbrook 
+Forwarded: https://github.com/valyala/fasthttp/pull/1250
+Last-Update: 2022-03-16
+---
+From d6c6e4a7cc9c17158dc2c93090e5b7d26ca42e15 Mon Sep 17 00:00:00 2001
+From: Nick Rosbrook 
+Date: Wed, 16 Mar 2022 09:41:03 -0400
+Subject: [PATCH] bytesconv: add appropriate build tags for s390x
+
+The bytesconv 32-bit tests fail on s390x, because it is a 64-bit
+architecture. Add the appropriate build flags so that 32-bit tests do
+not run on this architecture.
+---
+ bytesconv_32.go  | 4 ++--
+ bytesconv_32_test.go | 4 ++--
+ bytesconv_64.go  | 4 ++--
+ bytesconv_64_test.go | 4 ++--
+ 4 files changed, 8 insertions(+), 8 deletions(-)
+diff --git a/bytesconv_32.go b/bytesconv_32.go
+index 6a6fec2..b574883 100644
+--- a/bytesconv_32.go
 b/bytesconv_32.go
+@@ -1,5 +1,5 @@
+-//go:build !amd64 && !arm64 && !ppc64 && !ppc64le
+-// +build !amd64,!arm64,!ppc64,!ppc64le
++//go:build !amd64 && !arm64 && !ppc64 && !ppc64le && !s390x
++// +build !amd64,!arm64,!ppc64,!ppc64le,!s390x
+ 
+ package fasthttp
+ 
+diff --git a/bytesconv_32_test.go b/bytesconv_32_test.go
+index cec5aa9..3f5d5de 100644
+--- a/bytesconv_32_test.go
 b/bytesconv_32_test.go
+@@ -1,5 +1,5 @@
+-//go:build !amd64 && !arm64 && !ppc64 && !ppc64le
+-// +build !amd64,!arm64,!ppc64,!ppc64le
++//go:build !amd64 && !arm64 && !ppc64 && !ppc64le && !s390x
++// +build !amd64,!arm64,!ppc64,!ppc64le,!s390x
+ 
+ package fasthttp
+ 
+diff --git a/bytesconv_64.go b/bytesconv_64.go
+index 1300d5a..94d0ec6 100644
+--- a/bytesconv_64.go
 b/bytesconv_64.go
+@@ -1,5 +1,5 @@
+-//go:build amd64 || arm64 || ppc64 || ppc64le
+-// +build amd64 arm64 ppc64 ppc64le
++//go:build amd64 || arm64 || ppc64 || ppc64le || s390x
++// +build amd64 arm64 ppc64 ppc64le s390x
+ 
+ package fasthttp
+ 
+diff --git a/bytesconv_64_test.go b/bytesconv_64_test.go
+index 5351591..0689809 100644
+--- a/bytesconv_64_test.go
 b/bytesconv_64_test.go
+@@ -1,5 +1,5 @@
+-//go:build amd64 || arm64 || ppc64 || ppc64le
+-// +build amd64 arm64 ppc64 ppc64le
++//go:build amd64 || arm64 || ppc64 || ppc64le || s390x
++// +build amd64 arm64 ppc64 ppc64le s390x
+ 
+ package fasthttp
+ 
+-- 
+2.32.0
+
diff -Nru golang-github-valyala-fasthttp-1.31.0/debian/patches/series 
golang-github-valyala-fasthttp-1.31.0/debian/patches/series
--- golang-github-valyala-fasthttp-1.31.0/debian/patches/series 1969-12-31 
19:00:00.0 -0500
+++ golang-github-valyala-fasthttp-1.31.0/debian/patches/series 2022-03-16 
09:44:45.0 -0400
@@ -0,0 +1 @@
+0001-bytesconv-add-appropriate-build-tags-for-s390x.patch

Bug#1005005: Regression from 3c196f056666 ("drm/amdgpu: always reset the asic in suspend (v2)") on suspend?

[Thorsten Leemhuis]

On 21.03.22 13:07, Éric Valette wrote:
> My problem has never been fixed.
>
> The proposed patch has been applied to 5.15. I do not remerber which version 
> 28 maybe.
> 
> I still have à RIP in pm_suspend. Did not test the Last two 15 versions.
> 
> I can leave with 5.10 est using own compiled kernels.
> 
> Thanks for asking.

This thread/the debian bug report
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005005 ) is getting
long which makes things hard to grasp. But to me it looks a lot like the
problem you are facing is different from the problem that others ran
into and bisected -- but I might be totally wrong there. Have you ever
tried reverting 3c196f05 to seem if it helps (sorry if that's
mentioned in the bug report somewhere, as I said, it became long)? I
guess a bisection from your side really would help a lot; but before you
go down that route you might want to give 5.17 and the latest 5.15.y
kernel a try.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I'm getting a lot of
reports on my table. I can only look briefly into most of them and lack
knowledge about most of the areas they concern. I thus unfortunately
will sometimes get things wrong or miss something important. I hope
that's not the case here; if you think it is, don't hesitate to tell me
in a public reply, it's in everyone's interest to set the public record
straight.

Bug#994622: bullseye-pu: package network-manager/1.30.6-1~deb11u1

[Michael Biebl]

Hi Julien

Am 18.03.22 um 16:46 schrieb Julien Cristau:

Control: tag -1 moreinfo

Hi Michael,

Sorry it took so long to get to this.  I've got a couple of questions
from the NEWS file; will keep looking at the actual diff though.

On Mon, Sep 20, 2021 at 01:09:00PM +0200, Michael Biebl wrote:

===
NetworkManager-1.30.6
Overview of changes since NetworkManager-1.30.4
===

* By default, don't touch existing traffic control (TC) configuration
   on devices.


This sounds like it could cause unexpected changes.  Unsure about the
risk here.


The relevant bug report is
https://bugzilla.redhat.com/show_bug.cgi?id=1928078

From the git commit
"
core,libnm: don't touch device TC configuration by default

NetworkManager supports a very limited set of qdiscs. If users want to
configure a unsupported qdisc, they need to do it outside of
NetworkManager using tc.

The problem is that NM also removes all qdiscs and filters during
activation if the connection doesn't contain a TC setting. Therefore,
setting TC configuration outside of NM is hard because users need to
do it *after* the connection is up (for example through a dispatcher
script).

Let NM consider the presence (or absence) of a TC setting in the
connection to determine whether NM should configure (or not) qdiscs
and filters on the interface. We already do something similar for
SR-IOV configuration.

Since new connections don't have the TC setting, the new behavior
(ignore existing configuration) will be the default. The impact of
this change in different scenarios is:

 - the user previously configured TC settings via NM. This continues
   to work as before;

 - the user didn't set any qdiscs or filters in the connection, and
   expected NM to clear them from the interface during activation.
   Here there is a change in behavior, but it seems unlikely that
   anybody relied on the old one;

 - the user didn't care about qdiscs and filters; NM removed all
   qdiscs upon activation, and so the default qdisc from kernel was
   used. After this change, NM will not touch qdiscs and the default
   qdisc will be used, as before;

 - the user set a different qdisc via tc and NM cleared it during
   activation. Now this will work as expected.

So, the new default behavior seems better than the previous one.

"

I'd say the above reasoning makes sense to me.



* Prefer the IPv4 address to determine the system hostname via address
   lookup.


Likewise.  What's the reasoning to do this in a stable update?


From the relevant git commit
"
policy: prefer IPv4 to determine the hostname

When determining the hostname, it is preferable to evaluate devices in
a predictable order to avoid that the hostname changes between
different boots.

The current order is based first on hostname priority, then on the
presence of a best default route, and then on activation order.

The activation order is not a very strong condition, as it is
basically useless for devices that are autoactivated at boot.

As we already prefer IPv4 over IPv6 within the same connection, also
prefer it when 2 connections have the same priority and the same
default route status, to achieve better predictability.

https://bugzilla.redhat.com/show_bug.cgi?id=1970335

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/895
"

Makes sense to me as well.


* Enable WPA3 for Wi-Fi connections with key_mgmt=WPA-PSK


What's the regression risk here, of things working without WPA3 but not
with it enabled?


That one I indeed missed. Thanks for spotting it. It has indeed the 
potential to break existing setups (as evidenced by [1]), although I 
think that would also need a newer wpasupplicant in stable.


The relevant upstream issue is
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/638

I think reverting these commits for stable would make sense.

Julien, if I revert the three commits from this MR, would you be ok with 
the upload?


Michael



[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003907
[2] 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/638


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1008049: RFS: simple-revision-control/1.29-1 [ITA] -- single-file and single-user revision control system

[Daichi Fukui]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "simple-revision-control":

 * Package name: simple-revision-control
   Version : 1.29-1
   Upstream Author : Eric S. Raymond 
 * URL : https://gitlab.com/esr/src
 * License : BSD-2-clause
 * Vcs : https://salsa.debian.org/debian/simple-revision-control
   Section : vcs

The source builds the following binary packages:

  simple-revision-control - single-file and single-user revision control
system

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

  https://mentors.debian.net/package/simple-revision-control/

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

  dget -x
https://mentors.debian.net/debian/pool/main/s/simple-revision-control/simple-revision-control_1.29-1.dsc

Changes since the last upload:

 simple-revision-control (1.29-1) unstable; urgency=medium
 .
   * New maintainer (Closes: #983803)
   * New upstream release

Regards,
Fukui

Bug#995624: pktstat FTBFS: error: format not a string literal and no format arguments [-Werror=format-security]

[Nick Rosbrook]

Package: pktstat
Version: 1.8.5-7
Followup-For: Bug #995624
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to fix the pktstat build.

  * debian/patches/0001-Fix-format-string-error-with-recent-ncurses.patch:
Add patch to fix -Werror=format-security build error (LP: #1965174).

Thanks,
Nick
diff -Nru 
pktstat-1.8.5/debian/patches/0001-Fix-format-string-error-with-recent-ncurses.patch
 
pktstat-1.8.5/debian/patches/0001-Fix-format-string-error-with-recent-ncurses.patch
--- 
pktstat-1.8.5/debian/patches/0001-Fix-format-string-error-with-recent-ncurses.patch
 1969-12-31 19:00:00.0 -0500
+++ 
pktstat-1.8.5/debian/patches/0001-Fix-format-string-error-with-recent-ncurses.patch
 2022-03-17 13:23:20.0 -0400
@@ -0,0 +1,26 @@
+Description: Fix format string error with recent ncurses
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995624
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/pktstat/+bug/1965174
+Author: Sven Joachim 
+Last-Update: 2022-03-16
+---
+From f3368493fe0365f7f37064fb0ae5fd1fba50fc36 Mon Sep 17 00:00:00 2001
+From: Sven Joachim 
+Date: Thu, 14 Oct 2021 19:40:32 +0200
+Subject: [PATCH] Fix format string error with recent ncurses
+
+---
+ display.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/display.c
 b/display.c
+@@ -669,7 +669,7 @@
+   attron(A_REVERSE);
+   printw("%c", h->name[0]);
+   attroff(A_UNDERLINE);
+-  printw((char *)h->name + 1);
++  printw("%s", (char *)h->name + 1);
+   attrset(0);
+   printw(" ");
+   }
diff -Nru pktstat-1.8.5/debian/patches/series 
pktstat-1.8.5/debian/patches/series
--- pktstat-1.8.5/debian/patches/series 2021-08-24 15:20:56.0 -0400
+++ pktstat-1.8.5/debian/patches/series 2022-03-16 15:17:07.0 -0400
@@ -1 +1,2 @@
 10-CVE-2013-0350-bug-701211-no-tmp.patch
+0001-Fix-format-string-error-with-recent-ncurses.patch

Bug#997847: golang-github-hashicorp-go-slug: autopkgtest regression: testdata/archive-dir: no such file or directory

[Nick Rosbrook]

Package: golang-github-hashicorp-go-slug
Version: 0.7.0-1
Followup-For: Bug #997847
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to fix autopkgtest
regressions:

  * debian/patches/disable-strange-tests.patch: Refresh the patch to include
new tests that try to access testdata/archive-dir. This fixes an
autopkgtest failure (LP: #1965429).

Thanks,
Nick
diff -Nru 
golang-github-hashicorp-go-slug-0.7.0/debian/patches/disable-strange-tests.patch
 
golang-github-hashicorp-go-slug-0.7.0/debian/patches/disable-strange-tests.patch
--- 
golang-github-hashicorp-go-slug-0.7.0/debian/patches/disable-strange-tests.patch
2021-10-05 14:31:50.0 -0400
+++ 
golang-github-hashicorp-go-slug-0.7.0/debian/patches/disable-strange-tests.patch
2022-03-17 14:36:15.0 -0400
@@ -1,11 +1,20 @@
 Description: some tests require files in paths that are not compatible with 
Debian packaging
  in order to make life easier, these tests are disabled
 Author: Thorsten Alteholz 
-Index: golang-github-hashicorp-go-slug-0.7.0/slug_test.go
-===
 golang-github-hashicorp-go-slug-0.7.0.orig/slug_test.go2021-10-06 
06:10:32.879315260 +
-+++ golang-github-hashicorp-go-slug-0.7.0/slug_test.go 2021-10-06 
06:13:39.728065809 +
-@@ -14,231 +14,231 @@
+--- a/slug_test.go
 b/slug_test.go
+@@ -2,10 +2,8 @@
+ 
+ import (
+   "archive/tar"
+-  "bytes"
+   "compress/gzip"
+   "errors"
+-  "io"
+   "io/ioutil"
+   "os"
+   "path/filepath"
+@@ -14,338 +12,338 @@
"testing"
  )
  
@@ -234,6 +243,113 @@
 -  t.Fatalf("\nexpect:\n%#v\n\nactual:\n%#v", expect, meta)
 -  }
 -}
+-
+-func TestPackWithoutIgnoring(t *testing.T) {
+-  slug := bytes.NewBuffer(nil)
+-
+-  // By default NewPacker() creates a Packer that does not use
+-  // .terraformignore or dereference symlinks.
+-  p, err := NewPacker()
+-  if err != nil {
+-  t.Fatalf("err: %v", err)
+-  }
+-
+-  meta, err := p.Pack("testdata/archive-dir", slug)
+-  if err != nil {
+-  t.Fatalf("err: %v", err)
+-  }
+-
+-  gzipR, err := gzip.NewReader(slug)
+-  if err != nil {
+-  t.Fatalf("err: %v", err)
+-  }
+-
+-  tarR := tar.NewReader(gzipR)
+-  var (
+-  fileList []string
+-  slugSize int64
+-  )
+-
+-  for {
+-  hdr, err := tarR.Next()
+-  if err == io.EOF {
+-  break
+-  }
+-  if err != nil {
+-  t.Fatalf("err: %v", err)
+-  }
+-
+-  fileList = append(fileList, hdr.Name)
+-  if hdr.Typeflag == tar.TypeReg || hdr.Typeflag == tar.TypeRegA {
+-  slugSize += hdr.Size
+-  }
+-  }
+-
+-  // baz.txt would normally be ignored, but should not be
+-  var bazFound bool
+-  for _, file := range fileList {
+-  if file == "baz.txt" {
+-  bazFound = true
+-  }
+-  }
+-  if !bazFound {
+-  t.Fatal("expected file baz.txt to be present, but not found")
+-  }
+-
+-  // .terraform/file.txt would normally be ignored, but should not be
+-  var dotTerraformFileFound bool
+-  for _, file := range fileList {
+-  if file == ".terraform/file.txt" {
+-  dotTerraformFileFound = true
+-  }
+-  }
+-  if !dotTerraformFileFound {
+-  t.Fatal("expected file .terraform/file.txt to be present, but 
not found")
+-  }
+-
+-  // Check the metadata
+-  expect := {
+-  Files: fileList,
+-  Size:  slugSize,
+-  }
+-  if !reflect.DeepEqual(meta, expect) {
+-  t.Fatalf("\nexpect:\n%#v\n\nactual:\n%#v", expect, meta)
+-  }
+-}
+-
+-func TestUnpack(t *testing.T) {
+-  // First create the slug file so we can try to unpack it.
+-  slug := bytes.NewBuffer(nil)
+-
+-  if _, err := Pack("testdata/archive-dir", slug, true); err != nil {
+-  t.Fatalf("err: %v", err)
+-  }
+-
+-  // Create a dir to unpack into.
+-  dst, err := ioutil.TempDir("", "slug")
+-  if err != nil {
+-  t.Fatalf("err: %v", err)
+-  }
+-  defer os.RemoveAll(dst)
+-
+-  // Now try unpacking it.
+-  if err := Unpack(slug, dst); err != nil {
+-  t.Fatalf("err: %v", err)
+-  }
+-
+-  // Verify all the files
+-  verifyFile(t, filepath.Join(dst, "foo.txt"), 0, "foo\n")
+-  verifyFile(t, filepath.Join(dst, "bar.txt"), 0, "bar\n")
+-  verifyFile(t, filepath.Join(dst, "sub", "bar.txt"), os.ModeSymlink, 
"../bar.txt")
+-  verifyFile(t, filepath.Join(dst, "sub", "zip.txt"), 0, "zip\n")
+-
+-  // Check that we can 

Bug#1008048: RM: xen [i386] -- ROM; ANAIS; stop building for i386

[Hans van Kranenburg]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: pkg-xen-de...@lists.alioth.debian.org

Hi,

Starting with Xen version 4.16, we're dropping support for the i386 arch.

There are currently already no reverse dependencies left on i386 
specific packages in unstable. We have worked together with collectd, 
libvirt and qemu maintainers to have their packages changed to remove 
i386 related xen things.


So, I understand that we now can ask for removal of the leftover Xen 
4.14 packages in i386, which will unblock the migration of Xen 4.16 to 
testing.


Thanks,
Hans van Kranenburg
Debian Xen Team

Bug#108587: Hello

[OKENWA2019]

I also wrote you a previous message two days ago but no response from you,

Bug#959469: openssl 1.1.1n-0+deb10u1 flagged for acceptance

[Sebastian Andrzej Siewior]

On 2022-03-21 00:12:11 [+0100], To Kurt Roeckx wrote:
> doesn't help here but
>-cipher "ALL:@SECLEVEL=1"
> 
> does. 

Only debci is affected. The package builds because this testsuite is not
part of the build process.
I prepared a NMU against Buster for gnutls. I can open later today a
buster-pu and do the upload unless someone objects or gnutls folks have
something in their queue.
Please let me know.

> > Kurt

Sebastian
diff -Nru gnutls28-3.6.7/debian/changelog gnutls28-3.6.7/debian/changelog
--- gnutls28-3.6.7/debian/changelog	2021-05-14 13:33:38.0 +0200
+++ gnutls28-3.6.7/debian/changelog	2022-03-21 14:52:01.0 +0100
@@ -1,3 +1,11 @@
+gnutls28 (3.6.7-4+deb10u7.1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport testcompat-openssl-improve-testing-against-secured-O.patch to
+pass testsuite with openssl 1.1.1e.
+
+ -- Sebastian Andrzej Siewior   Mon, 21 Mar 2022 14:52:01 +0100
+
 gnutls28 (3.6.7-4+deb10u7) buster; urgency=medium
 
   * 46_handshake-reject-no_renegotiation-alert-if-handshake.patch pulled from
diff -Nru gnutls28-3.6.7/debian/patches/series gnutls28-3.6.7/debian/patches/series
--- gnutls28-3.6.7/debian/patches/series	2021-05-11 18:13:03.0 +0200
+++ gnutls28-3.6.7/debian/patches/series	2022-03-21 08:35:24.0 +0100
@@ -23,3 +23,4 @@
 47_rel3.6.16_04-pre_shared_key-avoid-use-after-free-around-realloc.patch
 47_rel3.6.16_05-_gnutls_buffer_resize-account-for-unused-area-if-AGG.patch
 47_rel3.6.16_06-str-suppress-Wunused-function-if-AGGRESSIVE_REALLOC-.patch
+testcompat-openssl-improve-testing-against-secured-O.patch
diff -Nru gnutls28-3.6.7/debian/patches/testcompat-openssl-improve-testing-against-secured-O.patch gnutls28-3.6.7/debian/patches/testcompat-openssl-improve-testing-against-secured-O.patch
--- gnutls28-3.6.7/debian/patches/testcompat-openssl-improve-testing-against-secured-O.patch	1970-01-01 01:00:00.0 +0100
+++ gnutls28-3.6.7/debian/patches/testcompat-openssl-improve-testing-against-secured-O.patch	2022-03-21 08:37:07.0 +0100
@@ -0,0 +1,274 @@
+From: Dimitri John Ledkov 
+Date: Mon, 21 Mar 2022 07:44:25 +0100
+Subject: [PATCH] testcompat-openssl: improve testing against secured OpenSSL
+
+[bigeasy: This is backport of commit fbd3e261513d641dce6bd1b2c368ce25e79dc094 ]
+
+In Debian, and soon Ubuntu, OpenSSL is compiled with SECLEVEL=2 and
+requiring minimum TLSv1.2. However, smaller hashes/keys/versions are
+allowed if one enables SECLEVEL=1. Do so when testing pre v1.2 algos,
+and thus enabling testing more compatability combinations.
+
+Signed-off-by: Dimitri John Ledkov 
+Signed-off-by: Sebastian Andrzej Siewior 
+---
+ tests/suite/testcompat-main-openssl | 67 +
+ 1 file changed, 30 insertions(+), 37 deletions(-)
+
+diff --git a/tests/suite/testcompat-main-openssl b/tests/suite/testcompat-main-openssl
+index d2708bfa8c710..2ea762faebaca 100755
+--- a/tests/suite/testcompat-main-openssl
 b/tests/suite/testcompat-main-openssl
+@@ -74,7 +74,6 @@ NO_TLS1_2=$?
+ 
+ test $NO_TLS1_2 != 0 && echo "Disabling interop tests for TLS 1.2"
+ 
+-
+ ${SERV} version|grep -e '[1-9]\.[1-9]\.[0-9]' >/dev/null 2>&1
+ if test $? = 0;then
+ 	NO_DH_PARAMS=0
+@@ -82,18 +81,8 @@ else
+ 	NO_DH_PARAMS=1
+ fi
+ 
+-# Do not use DSS or curves <=256 bits in 1.1.1+ because these
+-# are not accepted by openssl on debian.
+-${SERV} version|grep -e '[1-9]\.[1-9]\.[1-9]' >/dev/null 2>&1
+-if test $? = 0;then
+-	NO_DSS=1
+-	FIPS_CURVES=1
+-else
+-	${SERV} ciphers -v ALL 2>&1|grep -e DHE-DSS >/dev/null 2>&1
+-	NO_DSS=$?
+-fi
+-
+-test $FIPS_CURVES = 1 && echo "Running with FIPS140-2 enabled curves enabled"
++${SERV} ciphers -v ALL 2>&1|grep -e DHE-DSS >/dev/null 2>&1
++NO_DSS=$?
+ 
+ if test $NO_DSS != 0;then
+ 	echo "Disabling interop tests for DSS ciphersuites"
+@@ -121,6 +110,10 @@ NO_NULL=$?
+ 
+ test $NO_NULL != 0 && echo "Disabling interop tests for NULL ciphersuites"
+ 
++${SERV} ecparam -list_curves 2>&1|grep -e prime192v1 >/dev/null 2>&1
++NO_PRIME192v1=$?
++
++test $NO_PRIME192v1 != 0 && echo "Disabling interop tests for prime192v1 ecparam"
+ 
+ if test "${NO_DH_PARAMS}" = 0;then
+ 	OPENSSL_DH_PARAMS_OPT=""
+@@ -218,7 +211,7 @@ run_client_suite() {
+ 
+ 	#-cipher RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-AES128-SHA
+ 	eval "${GETPORT}"
+-	launch_bare_server $$ s_server -cipher "ALL" -quiet -www -accept "${PORT}" -keyform pem -certform pem -tls1 ${OPENSSL_DH_PARAMS_OPT} -key "${RSA_KEY}" -cert "${RSA_CERT}" ${DSA_PARAMS} -Verify 1 -CAfile "${CA_CERT}" >/dev/null
++	launch_bare_server $$ s_server -cipher "ALL:@SECLEVEL=1" -quiet -www -accept "${PORT}" -keyform pem -certform pem -tls1 ${OPENSSL_DH_PARAMS_OPT} -key "${RSA_KEY}" -cert "${RSA_CERT}" ${DSA_PARAMS} -Verify 1 -CAfile "${CA_CERT}" >/dev/null
+ 	PID=$!
+ 	wait_server ${PID}
+ 
+@@ -267,9 +260,9 @@ run_client_suite() {
+ 	kill ${PID}
+ 	wait
+ 
+-	if test "${FIPS_CURVES}" != 1; then
++	if test "${FIPS_CURVES}" != 1 && test 

Bug#1008047: xscreensaver: power management settings are ignored

[Francesco Potortì]

Package: xscreensaver
Version: 6.02+dfsg1-2
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

After a reboot, Xscreensaver does not power off the screen as it used
to, even if no change was done to the configuration.

This is an always-running box, so after reboot presumably Xscreensaver,
the kernel and libraries had different running versions.

For the sake of logging, I have set timeouts to small numbers.  Here are
the configuration file and the log.  In the log you see that, after
3 minutes from start, the screen fades out and a screen saver is
started.  After 4' from start the screen should have gone to sleep,
and after 5' from start it should have shut down, but none of this
happened and instead, after 6' from start anohter screen saver was
selected and started.



 start of ~/.xscreensaver 

# XScreenSaver Preferences File
# Written by xscreensaver-demo 6.02 for pot on Mon Mar 21 13:56:12 2022.
# https://www.jwz.org/xscreensaver/

timeout:0:03:00
cycle:  0:03:00
lock:   False
lockTimeout:0:00:00
passwdTimeout:  0:00:30
visualID:   default
installColormap:True
verbose:False
splash: True
splashDuration: 0:00:05
demoCommand:xscreensaver-demo
nice:   10
fade:   True
unfade: False
fadeSeconds:0:00:09
ignoreUninstalledPrograms:False
font:   *-medium-r-*-140-*-m-*
dpmsEnabled:True
dpmsQuickOff:   False
dpmsStandby:0:03:00
dpmsSuspend:0:04:00
dpmsOff:0:05:00
grabDesktopImages:  True
grabVideoFrames:False
chooseRandomImages: True
imageDirectory: /home/pot/Pictures/foto

mode:   random
selected:   -1

textMode:   url
textLiteral:XScreenSaver
textFile:   
textProgram:fortune
textURL:https://planet.debian.org/rss20.xml
dialogTheme:default

programs: \
-   maze -root  \n\
- GL:   superquadrics -root \n\
attraction -root\n\
blitspin -root  \n\
greynetic -root \n\
helix -root \n\
hopalong -root  \n\
imsmap -root\n\
-   noseguy -root   \n\
-   pyro -root  \n\
qix -root   \n\
-   rocks -root \n\
rorschach -root \n\
decayscreen -root   \n\
flame -root \n\
halo -root  \n\
slidescreen -root   \n\
pedal -root \n\
bouboule -root  \n\
braid -root \n\
coral -root \n\
deco -root  \n\
drift -root \n\
fadeplot -root  \n\
galaxy -root\n\
goop -root  \n\
grav -root  \n\
ifs -root   \n\
unicode -root   \n\
- GL:   jigsaw -root\n\
julia -root \n\
kaleidescope -root  \n\
- GL:   moebius -root   \n\
moire -root \n\
  GL:   morph3d -root   \n\
-   mountain -root  \n\
munch -root \n\
penrose -root 

Bug#1008046: installation-reports: installer bring the computer in stop by detecting network hardware

[Andreas Matthus]

Package: installation-reports
Severity: important


Boot method: USB
Image version:  "Bookworm" - Unofficial amd64 NETINST with firmware
20211223-09:01
Date: 

Machine: motherboard  PRO Z690-A WIFI (MS-7D25)
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[E]
Configure network:  [ ]
Detect media:   [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:

The board has  Intel Corporation Ethernet Controller I225-V (rev 03). Hardware-
detection of that crash the system (mouse freeze, no reaction of all). Hard-
poweroff is the only way to end the process. After I disabled the netword-card
in BIOS and use a usb-netcard instead of that the installation works fine. Than
I can reenable I225-V in BIOS and the network over that works too.


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20211223-00:01:37"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux amadeb22 5.15.0-2-amd64 #1 SMP Debian 5.15.5-2 (2021-12-18) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:4650] 
(rev 05)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7d25]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device 
[8086:4692] (rev 0c)
lspci -knn: DeviceName: Onboard - Video
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7d25]
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Device 
[8086:464f] (rev 05)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7d25]
lspci -knn: 00:0a.0 Signal processing controller [1180]: Intel Corporation 
Device [8086:467d] (rev 01)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Device [8086:7ae0] 
(rev 11)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7d25]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 RAM memory [0500]: Intel Corporation Device [8086:7aa7] 
(rev 11)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: 00:14.3 Network controller [0280]: Intel Corporation Device 
[8086:7af0] (rev 11)
lspci -knn: DeviceName: Onboard - Ethernet
lspci -knn: Subsystem: Intel Corporation Device [8086:0094]
lspci -knn: Kernel modules: iwlwifi
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Device 
[8086:7ae8] (rev 11)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7d25]
lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Device 
[8086:7ae2] (rev 11)
lspci -knn: DeviceName: Onboard - SATA
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7d25]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1a.0 PCI bridge [0604]: Intel Corporation Device [8086:7ac8] 
(rev 11)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Device [8086:7ab8] 
(rev 11)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation Device [8086:7abc] 
(rev 11)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:7a84] 
(rev 11)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7d25]
lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Device [8086:7ad0] 
(rev 11)
lspci -knn: DeviceName: Onboard - Sound
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:9d25]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel, snd_sof_pci_intel_tgl
lspci -knn: 00:1f.4 SMBus [0c05]: Intel Corporation Device [8086:7aa3] (rev 11)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Micro-Star International Co., Ltd. [MSI] Device 
[1462:7d25]
lspci -knn: 00:1f.5 Serial bus controller [0c80]: Intel Corporation Device 
[8086:7aa4] (rev 11)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: 

Bug#810018: Bug #810018: Consider shipping pidof with procps

[Andreas Henriksson]

Hello Mark, Craig,

On Mon, Mar 21, 2022 at 10:34:58AM +, Mark Hindley wrote:
> Craig,
> 
> Thanks for this.
> 
> This dates from before my detailed involvement with this area of Debian. I 
> have
> read through the bug report, but apologies if I have missed pertinent detail.
[]
>  3) A desire to reduce the Essential set.
> 
> I understand and appreciate the general motivation for this. However, 
> moving
> pidof to procps would make procps Essential and it is already about 20 
> times
> bigger than sysvinit-utils, so it does not achieve the aim.
[...]

I don't see why you think pidof (and thus entire procps) must be
Essential. That would indeed be counter-productive. (I haven't re-read
the discussion, but I'm pretty sure we already covered this.)

As I've already proven elsewhere sysvinit-utils (with or without pidof,
which AFAIR is the only semi-useful utility left in that binary package)
can be made non-essential without any problems already.

> What do you think?

I think apart from reducing the essential set, it is also useful to
eliminate pointless differences.

The distributions I've looked at (that are not just following along as a
debian derivate) uses procps pidof already.

Finally I have to say that I will not object to just closing this bug
report (even though I think the original motivation still holds true),
because atleast I don't have the energy to fight for forward movement
anymore.

Regards,
Andreas Henriksson

Bug#1006909: impressive: Fails to find any pages in the presentation

[Yaroslav Halchenko]

On Tue, 15 Mar 2022, Martin Fiedler wrote:

> Hi Gunnar,

> > Hmmm... But please do take note that I _did_ have mupdf-tools
> > installed when Impressive failed to analyze the PDF
> > document.

> Did you though? Impressive detected "Poppler/Xpdf" as the renderer,
> which is an indicator of the absence of mupdf-tools. If you can confirm
> that "mutool -v" works on your system (in the sense of: prints a version
> number instead of a "command not found" message), I'd have some homework
> to do though ;)

Dear Gunnar,

Could you please confirm that mupdf-tools were installed and
functioning?  I know that sounds implausible given that it is a hard
dependency but having no pdftk{,-java} installed I was able to use
impressive just fine.

or Martin -- did you do some homework and figured smth out which is now
released?

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
WWW:   http://www.linkedin.com/in/yarik

Bug#1008045: bullseye-pu: package node-mermaid/8.7.0+ds+~cs27.17.17-3+deb11u1

[Yadd]

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

[ Reason ]
node-mermaid is vulnerable to XSS attack (CVE-2021-23648)

[ Impact ]
medium vulnerability

[ Tests ]
Test passed, new upstream test not applicable here

[ Risks ]
Low risk, patch is 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 (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Decode HTML entities before parsing URLs

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 3bfa0f2..32f71e8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+node-mermaid (8.7.0+ds+~cs27.17.17-3+deb11u1) bullseye; urgency=medium
+
+  * Decode html entities before sanitizing (Closes: CVE-2021-23648)
+
+ -- Yadd   Mon, 21 Mar 2022 14:06:12 +0100
+
 node-mermaid (8.7.0+ds+~cs27.17.17-3) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2021-23648.patch 
b/debian/patches/CVE-2021-23648.patch
new file mode 100644
index 000..3571ee3
--- /dev/null
+++ b/debian/patches/CVE-2021-23648.patch
@@ -0,0 +1,46 @@
+Description: decode html entities before sanitizing (fixes XSS)
+Author: Blade Barringer 
+Origin: upstream, https://github.com/braintree/sanitize-url/commit/8f7371ce
+Bug: https://github.com/braintree/sanitize-url/pull/40
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2022-03-21
+
+--- a/sanitize-url/index.js
 b/sanitize-url/index.js
+@@ -1,6 +1,7 @@
+ 'use strict';
+ 
+ var invalidPrototcolRegex = /^(%20|\s)*(javascript|data)/im;
++const htmlEntitiesRegex = 

Bug#1008044: ITP: openvpn-dco-dkms -- DCO (Data-Channel Offload) kernel module for OpenVPN

[Bernhard Schmidt]

Package: wnpp
Severity: wishlist
Owner: Bernhard Schmidt 

* Package name: openvpn-dco-dkms
  Version : Git Snapshot
  Upstream Author : Antonio Quartulli 
* URL : https://github.com/OpenVPN/ovpn-dco
* License : GPL-2.0
  Programming Lang: C
  Description : DCO (Data-Channel Offload) kernel module for OpenVPN

OpenVPN Data Channel Offload in the linux kernel (ovpn-dco)
.
This kernel module allows OpenVPN to offload any data plane management to the
linux kernel, thus allowing it to exploit any Linux low level API, while
avoiding expensive and slow payload transfer between kernel space and user
space. You need a matching dco-enabled OpenVPN to use this, the feature is
supposed to land in OpenVPN 2.6.
.
This package uses DKMS to automatically build the ovpn-dco kernel module.