Bug#990086: release-notes: deprecations not obvious from table of contents [was: apt-key is deprecated in bullseye, how to manage keys instead]

[Andrei POPESCU]

Control: retitle -1 release-notes: deprecations not obvious from the table of 
contents
Control: severity -1 minor

On Du, 20 iun 21, 09:40:14, Julian Andres Klode wrote:
> 
> I suggested wording for it in Bug#980743: release-notes: bullseye is
> the final release to ship apt-key - that I opened back in January,
> and it was added in April. So this is a duplicate.

Indeed, I seemed to remember this, but couldn't find it just by looking 
at the table of contents, because it's under "Deprecated components for 
bullseye".

Maybe we should have sub-headings for each component?

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#985980: allow dpkg-buildflags to query for a specific feature

[Nicolas Boulenguez]

Package: dpkg-dev
Followup-For: Bug #985980

A space-separated list of enabled features may be useful on its own,
and would not increase the complexity in Makefiles.

features := $(shell dpkg-buildflags --enabled-features optimize)
ifneq (,$(filter lto,$(features)))
  ...
endif
ifneq (,$(filter pgo,$(features)))
  ...

For symetry, a '--disabled-features AREA' option would be nice.

For consistency with '--query-features AREA', both should report
unknown AREAs with an exit status of 1.

Bug#872381: dpkg-dev: optimize Makefile snippets for debian/rules

[Nicolas Boulenguez]

Package: dpkg-dev
Version: 1.20.9
Followup-For: Bug #872381

The attached commits are, once more, manually rebased on the current
HEAD.
>From ad7a566e7966f7c8062a044d0c2df0b07b0011d7 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Mon, 29 Jul 2019 14:38:32 +0200
Subject: [PATCH 1/8] scripts/mk: simplify Makefile.am with sed --in-place
 option

---
 scripts/mk/Makefile.am | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/scripts/mk/Makefile.am b/scripts/mk/Makefile.am
index 9f0462eca..92e95c429 100644
--- a/scripts/mk/Makefile.am
+++ b/scripts/mk/Makefile.am
@@ -9,18 +9,8 @@ dist_pkgdata_DATA = \
 	pkg-info.mk \
 	vendor.mk
 
-do_path_subst = $(AM_V_GEN) sed \
-	-e "s:dpkg_datadir[[:space:]]*=[[:space:]]*[^[:space:]]*:dpkg_datadir = $(pkgdatadir):"
-
 install-data-hook:
-	mv $(DESTDIR)$(pkgdatadir)/default.mk \
-	   $(DESTDIR)$(pkgdatadir)/default.mk.tmp
-	$(do_path_subst) <$(DESTDIR)$(pkgdatadir)/default.mk.tmp \
-	 >$(DESTDIR)$(pkgdatadir)/default.mk
-	rm -f $(DESTDIR)$(pkgdatadir)/default.mk.tmp
-
-	mv $(DESTDIR)$(pkgdatadir)/buildtools.mk \
-	   $(DESTDIR)$(pkgdatadir)/buildtools.mk.tmp
-	$(do_path_subst) <$(DESTDIR)$(pkgdatadir)/buildtools.mk.tmp \
-	 >$(DESTDIR)$(pkgdatadir)/buildtools.mk
-	rm -f $(DESTDIR)$(pkgdatadir)/buildtools.mk.tmp
+	$(AM_V_GEN) sed --in-place \
+	  's:dpkg_datadir[[:space:]]*=[[:space:]]*[^[:space:]]*:dpkg_datadir = $(pkgdatadir):' \
+	  $(DESTDIR)$(pkgdatadir)/buildtools.mk \
+	  $(DESTDIR)$(pkgdatadir)/default.mk
-- 
2.30.2

>From 0eeea0412d1d4320a48c410aa789e09bcc7c05b3 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 11 Feb 2021 15:36:15 +0100
Subject: [PATCH 2/8] scripts: test SOURCE_DATE_EPOCH

Set SOURCE_DATE_EPOCH either from the environment or the Debian changelog.
Check that the value is (re)exported.
---
 scripts/t/mk.t   | 9 -
 scripts/t/mk/pkg-info.mk | 2 ++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/scripts/t/mk.t b/scripts/t/mk.t
index 10e030a16..25e25d56c 100644
--- a/scripts/t/mk.t
+++ b/scripts/t/mk.t
@@ -16,7 +16,7 @@
 use strict;
 use warnings;
 
-use Test::More tests => 10;
+use Test::More tests => 11;
 use Test::Dpkg qw(:paths);
 
 use File::Spec::Functions qw(rel2abs);
@@ -131,6 +131,13 @@ foreach my $tool (keys %buildtools) {
 delete $ENV{"${tool}_FOR_BUILD"};
 }
 
+delete $ENV{SOURCE_DATE_EPOCH};
+$ENV{TEST_SOURCE_DATE_EPOCH} = `date +%s -d "Tue, 04 Aug 2015 16:13:50 +0200"`;
+chomp $ENV{TEST_SOURCE_DATE_EPOCH};
+test_makefile('pkg-info.mk');
+
+$ENV{SOURCE_DATE_EPOCH} = 100;
+$ENV{TEST_SOURCE_DATE_EPOCH} = 100;
 test_makefile('pkg-info.mk');
 
 test_makefile('vendor.mk');
diff --git a/scripts/t/mk/pkg-info.mk b/scripts/t/mk/pkg-info.mk
index 22a2bf44f..c0e3287b5 100644
--- a/scripts/t/mk/pkg-info.mk
+++ b/scripts/t/mk/pkg-info.mk
@@ -7,3 +7,5 @@ test:
 	test "$(DEB_VERSION_UPSTREAM_REVISION)" = "2:3.4-5-6"
 	test "$(DEB_VERSION_UPSTREAM)" = "2:3.4-5"
 	test "$(DEB_DISTRIBUTION)" = "suite"
+	test '$(SOURCE_DATE_EPOCH)' = '$(TEST_SOURCE_DATE_EPOCH)'
+	test "$${SOURCE_DATE_EPOCH}" = '$(TEST_SOURCE_DATE_EPOCH)'
-- 
2.30.2

>From 15661098522a9805472fa0c283e00a8f2d7ffc70 Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Thu, 11 Feb 2021 15:45:03 +0100
Subject: [PATCH 3/8] scripts/t: slightly optimize hash traversals

Iterate on key/value pairs instead of iterating on keys then search
for each value.
---
 scripts/t/mk.t | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/scripts/t/mk.t b/scripts/t/mk.t
index 25e25d56c..139b19455 100644
--- a/scripts/t/mk.t
+++ b/scripts/t/mk.t
@@ -74,10 +74,15 @@ sub cmd_get_vars {
 
 my %arch = cmd_get_vars($ENV{PERL}, "$srcdir/dpkg-architecture.pl", '-f');
 
-delete $ENV{$_} foreach keys %arch;
-$ENV{"TEST_$_"} = $arch{$_} foreach keys %arch;
+while (my ($k, $v) = each %arch) {
+delete $ENV{$k};
+$ENV{"TEST_$k"} = $v;
+}
 test_makefile('architecture.mk', 'without envvars');
-$ENV{$_} = $arch{$_} foreach keys %arch;
+
+while (my ($k, $v) = each %arch) {
+$ENV{$k} = $v;
+}
 test_makefile('architecture.mk', 'with envvars');
 
 $ENV{DEB_BUILD_OPTIONS} = 'parallel=16';
@@ -88,8 +93,10 @@ delete $ENV{TEST_DEB_BUILD_OPTION_PARALLEL};
 
 my %buildflag = cmd_get_vars($ENV{PERL}, "$srcdir/dpkg-buildflags.pl");
 
-delete $ENV{$_} foreach keys %buildflag;
-$ENV{"TEST_$_"} = $buildflag{$_} foreach keys %buildflag;
+while (my ($k, $v) = each %buildflag) {
+delete $ENV{$k};
+$ENV{"TEST_$k"} = $v;
+}
 test_makefile('buildflags.mk');
 
 my %buildtools = (
@@ -112,11 +119,11 @@ my %buildtools = (
 PKG_CONFIG => 'pkg-config',
 );
 
-foreach my $tool (keys %buildtools) {
+while (my ($tool, $default) = each %buildtools) {
 delete $ENV{$tool};
-$ENV{"TEST_$tool"} = "$ENV{DEB_HOST_GNU_TYPE}-$buildtools{$tool}";
+$ENV{"TEST_$tool"} = "$ENV{DEB_HOST_GNU_TYPE}-$default";
 delete $ENV{"${tool}_FOR_BUILD"};
-

Bug#968963: dpkg-dev: architecture.mk is slow

[Nicolas Boulenguez]

Package: dpkg-dev
Version: 1.20.9
Followup-For: Bug #968963
Control: severity 872381 normal
Control: tags -1 patch
Control: merge -1 872381

This bug duplicates 872381, which carries a patch.

Bug#990106:

[Davide Beatrici]

After leaving the computer on for a while I reproduced the problem on 5.10.0-6 
as well, even after disconnecting the SPDIF cable.

Considering that I've been using this machine for at least one year and I've 
never encountered the issue, I believe the relay in the amplifier is going bad 
and pushing noise into mains.
I would expect the power supply to filter it out though, as it's a quality one: 
Sharkoon SilentStorm Cool Zero 850W.
Out of curiosity, were there perhaps changes related to power management in the 
platform or amdgpu drivers?

Bug#990113: release.debian.org: Permission to upload armadillo: sparse matrix bug fix

[Kumar Appaiah]

Package: release.debian.org
Severity: normal

Dear Release Team,

Please permit me to upload the attached targeted fix from upstream
that fixed erroneous calculations relating to sparse diagonal
matrices. This fix is needed to prevent some numerical errors, and I
request you to consider this positively.

Thanks.

Kumar
>From 158c2a523c29b1aa883fd410e4b695c8f9859944 Mon Sep 17 00:00:00 2001
From: Kumar Appaiah 
Date: Mon, 21 Jun 2021 09:43:47 +0530
Subject: [PATCH] Add patch from upstream for fixing sparse matrix related bug.

---
 debian/changelog |  6 +++
 debian/patches/armadillo_spdiag_bugfix.patch | 53 
 debian/patches/series|  2 +-
 3 files changed, 60 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/armadillo_spdiag_bugfix.patch

diff --git a/debian/changelog b/debian/changelog
index 730ef566..1a405ec6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+armadillo (1:10.1.2+dfsg-6) unstable; urgency=medium
+
+  * Add patch from upstream for fixing sparse matrix related bug.
+
+ -- Kumar Appaiah   Mon, 21 Jun 2021 09:43:00 +0530
+
 armadillo (1:10.1.2+dfsg-5) unstable; urgency=medium
 
   * Add patches from upstream for pinv and rcond bugs
diff --git a/debian/patches/armadillo_spdiag_bugfix.patch b/debian/patches/armadillo_spdiag_bugfix.patch
new file mode 100644
index ..e0c62748
--- /dev/null
+++ b/debian/patches/armadillo_spdiag_bugfix.patch
@@ -0,0 +1,53 @@
+--- armadillo-10.1.2/include/armadillo_bits/spglue_merge_meat.hpp	2016-06-17 02:22:12.0 +1000
 armadillo-10.1.2-spdiag-bugfix/include/armadillo_bits/spglue_merge_meat.hpp	2021-06-21 12:10:16.212683012 +1000
+@@ -485,7 +485,7 @@
+   
+   while( (x_it != x_end) || (y_it != y_end) )
+ {
+-eT out_val;
++eT out_val = eT(0);
+ 
+ const uword x_it_col = x_it.col();
+ const uword x_it_row = x_it.row();
+@@ -508,28 +508,29 @@
+   {
+   if((x_it_col < y_it_col) || ((x_it_col == y_it_col) && (x_it_row < y_it_row))) // if y is closer to the end
+ {
+-out_val = (*x_it);
++if(x_it_col != x_it_row)  { out_val = (*x_it); }  // don't take values from the main diagonal of A
+ 
+ ++x_it;
+ }
+   else
+ {
+-out_val = (*y_it);
++if(y_it_col == y_it_row)  { out_val = (*y_it); use_y_loc = true; }  // take values only from the main diagonal of B
+ 
+ ++y_it;
+-
+-use_y_loc = true;
+ }
+   }
+ 
+-access::rw(out.values[count]) = out_val;
+-
+-const uword out_row = (use_y_loc == false) ? x_it_row : y_it_row;
+-const uword out_col = (use_y_loc == false) ? x_it_col : y_it_col;
+-
+-access::rw(out.row_indices[count]) = out_row;
+-access::rw(out.col_ptrs[out_col + 1])++;
+-++count;
++if(out_val != eT(0))
++  {
++  access::rw(out.values[count]) = out_val;
++  
++  const uword out_row = (use_y_loc == false) ? x_it_row : y_it_row;
++  const uword out_col = (use_y_loc == false) ? x_it_col : y_it_col;
++  
++  access::rw(out.row_indices[count]) = out_row;
++  access::rw(out.col_ptrs[out_col + 1])++;
++  ++count;
++  }
+ }
+   
+   const uword out_n_cols = out.n_cols;
diff --git a/debian/patches/series b/debian/patches/series
index 4a679fbd..83b685e8 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,4 +2,4 @@ armadillo_sign_bugfix.patch
 armadillo_princomp_bugfix.patch
 armadillo_pinv_bugfix.patch
 armadillo_rcond_bugfix.patch
-
+armadillo_spdiag_bugfix.patch
-- 
2.30.1

Bug#990072: Update

[Matthew Darwin]

kernel 4.19.194-1a~test resolved the issue

Applied 
https://lore.kernel.org/stable/20210614102643.875096...@linuxfoundation.org/ 
using the process described at 
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html


--
Matthew Darwin
matt...@mdarwin.ca
http://www.mdarwin.ca

Bug#725313: ohai has invalid names in the "listeners" section

[Paul Wise]

On Thu, 03 Oct 2013 17:59:25 -0700 Simon Heath wrote:

> I just installed ohai on a debian-testing system and ran it, and noticed
> that in the "listeners" section it produces junk output for the names
> of the processes listening on all the ports.

ohai has been removed from Debian and recently reintroduced with a new
version, it would be great if you could re-test this issue. Please note
that you will need to install the version from experimental as the
version in unstable is missing a dependency version.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#990093: Bug#990092: partitionmanager: Missing File System Support dialog points to outdated cryptsetup project location

[email]

When cryptsetup is not installed on the system, the "Missing File System 
Support Package" dialog box dispays that cryptsetup is missing but points to an 
old location [1] where the project was hosted. The project has now been moved 
to gitlab [2] but the link in the dialog box does not seem to have been updated.

[1] https://code.google.com/p/cryptsetup/
[2] https://gitlab.com/cryptsetup/cryptsetup

Bug#990112: installation-report: 10.10.0-amd64-DVD-1 booted in Xen PV mode

[Lionel Elie Mamane]

Package: installation-reports
Version: 2.71
Severity: normal

(report done from another macn

-- Package-specific info:

Boot method: DVD (Xen PV mode)
Image version: 
https://cdimage.debian.org/debian-cd/current/amd64/bt-dvd/debian-10.10.0-amd64-DVD-1.iso.torrent
 2021-06-19 19:20
Date: 2021-06-20 evening

Machine: Xen PV DomU


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

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

Comments/Problems:


Problem 1: The CD is not recognised as a valid source of package, and
thus grub installation fails; my assumption is that it requires
grub-common from the CD but doesn't have it.

So I loaded the extra installer module pppoe in order to get an
Internet connection and use a network mirror to get packages. That
failed to work, because the pppoe kernel module failed to load, which
is:

Problem 2: the ppoe installer module needs "depmod" but doesn't run it

"depmod" run from the shell fixed that.

Then I selected a network mirror, namely http / Luxembourg / deb.debian.org

Problem 3: the selected network mirror is not used.

I ended up going to the shell again, chrooting into /target, editing
/etc/sources.lst with nano to put the requested deb.debian.org mirror
source, and after "apt-get update && apt-get install grub-xen" the
installer finished correctly. Note also that the "security updates"
and "updates" lines in source.list were commented out "because they
failed to validate".

"Install tasks" worked OK, but the only task available was "basic
system utilities" or something like that, again that's because nothing
in sources.list, not the CD and not the network mirror.

Bug#990043: dialog: Layout changes break existing scripts and libraries

[Thomas Dickey]

On Fri, Jun 18, 2021 at 06:07:30PM +0200, Florent Rougon wrote:
> Package: dialog
> Version: 1.3-20201126-1
> Severity: normal
> 
> Dear maintainer,
> 
> It appears that some rather drastic layout changes in dialog --timebox
> and --fselect happened somewhere between dialog 1.3-20190211-1 (buster)
> and 1.3-20201126-1 (currently in unstable). These changes break
> pythondialog's test suite in two places

I'm working on a fix.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#990083: Further testing

[Fabrice Quenneville]

Hello

So I've got my NAS back on and tested, everything is fine there and Kodi
crashed again on a transition. I think rebooting the NAS when I suspected
it was the source of the Kodi issues is what caused my NAS issues... But
just a remount of the subvolumes after an errorless check and some btrfs
diagnostics and no errors found... The only thing I could see is a few
machines on my network saturating the NAS and simultaneous backups but it's
never been an issue before with much more load than now.

So I've had two events since:

   - The first one I was not ready so I only captured a regular log:
2021-06-20-04∶22∶27
   PM-kodi.log
   
   - Just now, where It froze on a transition and exited userspace bringing
   the OS back to a gnome login screen. 2021-06-20-19∶30 PM-kodi2.log
    This time
   I was waiting for it and had a file explorer ready on the problematic PC
   and another PC on the same part of my network. While the problematic PC was
   temporarily frozen so I could not test opening a video on another app, I
   was able to open one on the other PC with no problem. (I opened a random
   video as I didn't remember what was next on kodi.)
   - As soon as I could get the log (sftp was also not responding on the
   kodi machine) I also tested the problematic video file and there's nothing
   wrong with the video file that had just crashed userspace.
   - And when I logged in there was no sound but that video file was
   working fine. (sorry for the two logs I opened two kodi instances for a few
   seconds by error.). 2021-06-20-19∶50 PM-kodi.log
    and
2021-06-20-19∶52
   PM-kodi.log
   

After a reboot everything is back to normal.

Thanks

-- 
*Fabrice Quenneville*

Bug#987169: RFS: newlib/3.3.0-1.1 [NMU] -- C library and math library for embedded systems

[John Scott]

Control: tags -1 -moreinfo

On Tue, 08 Jun 2021 21:38:56 + John Scott 
wrote:
> On Tue, 2021-06-01 at 07:52 +0200, Tobias Frost wrote:
> > > I haven't encountered the maintainer previously, but believe in
> > > good faith that these changes would be welcome and that the
> > > LowThresholdNmu criterion are met by addressing a bug with
> > > important severity. My interest in this bug, to introduce a 
> > > newlib-source binary package, is to unblock my progress on
> > > gcc-sh-elf, which is otherwise almost ready.
> > Probably still a good idea to CC them or file a bug in the BTS to
> > document your intentions, as adding a binary package is not a usual
> > change, even if the NMU criterias are fulfilled.
> Okay, I made some noise on the bug report today and Cc'ed the debian-
> toolchain mailing list on it. I'm not touching the moreinfo tag yet 
> to give them time to respond.

It's been about two weeks and I've garnered some interest from others,
so I'm removing the moreinfo tag.


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

Bug#990106: Switching on/off 5.1 audio amplifier/receiver causes graphics card to turn off

[Davide Beatrici]

Package: linux-image-5.10.0-7-amd64
Version: 5.10.40-1

I have a 5.1 audio amplifier/receiver connected to a Gigabyte X570 AORUS PRO 
(Realtek ALC1220) via SPDIF.

After updating from 5.10.0-6-amd64 to 5.10.0-7-amd64, the AMD Vega 56 graphics 
card turns off as soon as I switch the amplifier on or off.

The first time I encountered the issue was when shutting down Debian, leading 
me to suspect it was either a race condition that was never triggered before or 
an electricity spike.

That turned out not to be the case, because I can reliably reproduce the issue 
and I confirmed that it doesn't happen in 5.10.0-6-amd64.

Once the graphics card is turned off the computer seems to remain responsive 
and SysRq commands work.

Bug#990111: unblock: python-virtualenv/20.4.0+ds-2

[Stefano Rivera]

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

Please unblock package python-virtualenv

 python-virtualenv (20.4.0+ds-2) unstable; urgency=medium
 .
   * Patch: Fix --upgrade-embed-wheels.
   * Replace the pkg_resources addition part of
 debian_update_for_available_wheels.patch with include-pkg_resources.patch
 which will only include pkg_resources when using Debian's bundled
 setuptools wheel. (Closes: #976796)

[ Reason ]
The --upgrade-embed-wheels option was not working at all, it would
crash, if you attempted to use it. This was fixed upstream later in
20.4.x, so cherry-picked that trivial patch.

Relatedly, we got to the bottom of #976796, which was caused by upgraded
wheels, which would include pkg_resources in the setuptools wheel
(Debian splits it into its own binary package). This could cause a race
on unpacking, crashing.

[ Impact ]
If a user has an upgraded virtualenv wheel cache, then virtualenv
becomes unreliable, due to a race (two threads unpacking the target
files).

[ Tests ]
Manually tested 4 variants:
--seeder pip before and after --upgrade-embed-wheels
--seeder app-data and after --upgrade-embed-wheels

Autopkgtests verify that the basic functionality is unaffected.

[ Risks ]
The changes are relatively straightforward, and should improve
robustness.

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

unblock python-virtualenv/20.4.0+ds-2
diff -Nru python-virtualenv-20.4.0+ds/debian/changelog 
python-virtualenv-20.4.0+ds/debian/changelog
--- python-virtualenv-20.4.0+ds/debian/changelog2021-01-22 
23:40:18.0 -0400
+++ python-virtualenv-20.4.0+ds/debian/changelog2021-06-20 
17:31:30.0 -0400
@@ -1,3 +1,13 @@
+python-virtualenv (20.4.0+ds-2) unstable; urgency=medium
+
+  * Patch: Fix --upgrade-embed-wheels.
+  * Replace the pkg_resources addition part of
+debian_update_for_available_wheels.patch with include-pkg_resources.patch
+which will only include pkg_resources when using Debian's bundled
+setuptools wheel. (Closes: #976796)
+
+ -- Stefano Rivera   Sun, 20 Jun 2021 17:31:30 -0400
+
 python-virtualenv (20.4.0+ds-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
python-virtualenv-20.4.0+ds/debian/patches/debian_update_for_available_wheels.patch
 
python-virtualenv-20.4.0+ds/debian/patches/debian_update_for_available_wheels.patch
--- 
python-virtualenv-20.4.0+ds/debian/patches/debian_update_for_available_wheels.patch
 2021-01-22 23:40:18.0 -0400
+++ 
python-virtualenv-20.4.0+ds/debian/patches/debian_update_for_available_wheels.patch
 2021-06-20 17:31:30.0 -0400
@@ -1,42 +1,17 @@
-From: Debian Python Modules Team
- 
-Date: Sat, 21 Mar 2020 03:16:18 -0400
+From: Scott Kitterman 
+Date: Sun, 20 Jun 2021 13:49:30 -0400
 Subject: Update base embed to include pip provided wheels for --no-download
 
 Generate wheel lists and attributes for base install to match pip wheel
 versions and add pkg_resources to the base install for no download.
 
-Author: Scott Kitterman 
 Origin: vendor
 Forwarded: not-needed
 Last-Update: 2020-07-15
 ---
- src/virtualenv/seed/embed/base_embed.py  |  7 ++-
  src/virtualenv/seed/wheels/embed/__init__.py | 15 +++
- 2 files changed, 21 insertions(+), 1 deletion(-)
+ 1 file changed, 15 insertions(+)
 
-diff --git a/src/virtualenv/seed/embed/base_embed.py 
b/src/virtualenv/seed/embed/base_embed.py
-index c794e83..bc9cec8 100644
 a/src/virtualenv/seed/embed/base_embed.py
-+++ b/src/virtualenv/seed/embed/base_embed.py
-@@ -43,11 +43,16 @@ class BaseEmbed(Seeder):
- }
- 
- def distribution_to_versions(self):
--return {
-+dv = {
- distribution: getattr(self, "{}_version".format(distribution))
- for distribution in self.distributions()
- if getattr(self, "no_{}".format(distribution)) is False
- }
-+# Debian specific: Since Debian splits out pkg_resources from
-+# setuptools, for a local virtualenv, we need to add it to the base.
-+if not self.download:
-+dv['pkg_resources'] = None
-+return dv
- 
- @classmethod
- def add_parser_arguments(cls, parser, interpreter, app_data):
 diff --git a/src/virtualenv/seed/wheels/embed/__init__.py 
b/src/virtualenv/seed/wheels/embed/__init__.py
 index f63ec1d..4c1a4a7 100644
 --- a/src/virtualenv/seed/wheels/embed/__init__.py
diff -Nru 
python-virtualenv-20.4.0+ds/debian/patches/disable-periodic-update.patch 
python-virtualenv-20.4.0+ds/debian/patches/disable-periodic-update.patch
--- python-virtualenv-20.4.0+ds/debian/patches/disable-periodic-update.patch
2021-01-22 23:40:18.0 -0400
+++ python-virtualenv-20.4.0+ds/debian/patches/disable-periodic-update.patch
2021-06-20 17:31:30.0 -0400
@@ -11,7 +11,7 @@
  1 

Bug#990092: kmod: Enable zstd support

[Marco d'Itri]

On Jun 20, Andres Freund  wrote:

> Since version 28 kmod supports zstd compression [1]. As using xz module 
> compression
> makes building kernels painfully slow, and zstd achieves pretty decent ratios
> at a much lower compression time, it would be good to have support for that
> zstd in kmod.
The Debian kmod package supports lzma, but has never enabled support for 
xz.
If you are interested to pursue this then please provide statistics 
(space saved, time and memory for compression and decompression) for
zstd and xz and use cases.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#990110: Knockd Wishlist Item - Listen on Interface without IP Address

[Erased Hammer]

Package: knockd
Version: 0.7-1
Severity: wishlist

Problem: When attempting to make knockd listen on an interface without
an IP Address, the debug output says "could not get IP address for
[INTERFACE]". Knockd exits immediately after.

Solution:
Knockd should support listening on interfaces that do not have IP
Addresses. Bridged vlan interfaces do not contain IP Addresses,
despite receiving traffic destined for the local machine. Some
commercial applications of debian (such as Untangle) split
bidirectional communication across two vlan interfaces, the receiving
interface being the unaddressed one.

Uname -a:
4.19.0-11-untangle-amd64 #1 SMP Debian 4.19.146-1 (2020-09-29) x86_64 GNU/Linux

Bug#913431: Debian Installer Bullseye RC 2 release

[Vincent Danjean]

  Hi,

On 14/06/2021 23:26, Cyril Brulebois wrote:
> The Debian Installer team[1] is pleased to announce the second
> release candidate of the installer for Debian 11 "Bullseye".
> 
[...]
> Feedback for this release
> =
> 
> We need your help to find bugs and further improve the installer, so
> please try it. Installation images, and everything else you will need
> are available at our web site[3].

  Would someone give a feedback to the (old) patch proposed
in #913431 in order to be able to also use power-of-two units
in the Debian Installer? Is the bug badly assigned?
  I just tested RC2, power-of-two units are still refused
when partitionning a disk with the installer.

  Regards,
Vincent

PS: I'm not subscribed to debian-boot, please CC me if needed.

Bug#990109: wget2: The man-page is too new and lists options not available in the binary

[Anders Andersson]

Package: wget2
Version: 1.99.1-2.2
Severity: normal

Reading the man-page for wget2 I found the option "--unlink" that I wanted to
use, but wget2 complains about "Unknown option 'unlink'".

$ man wget2 | grep -A1 unlink
   --unlink
   Force Wget2 to unlink file instead of clobbering existing file.  This
   option is useful for downloading to the directory with hardlinks.

$ wget2 --unlink
Unknown option 'unlink'

$ wget2 --version
GNU Wget2 1.99.1 - multithreaded metalink/file/website downloader

$ man wget2 | head -n 1 | cut -c -60
WGET2(1)GNU Wget2 1.99.1


I see that '--unlink' is added in GNU Wget2 1.99.2:
https://lists.gnu.org/archive/html/info-gnu/2019-09/msg1.html



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

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 wget2 depends on:
ii  libc6 2.31-12
ii  libgpgme111.14.0-1+b2
ii  libpcre2-8-0  10.36-2
ii  libwget0  1.99.1-2.2

Versions of packages wget2 recommends:
ii  ca-certificates  20210119

wget2 suggests no packages.

-- no debconf information

Bug#990108: ITP: obs-websocket -- WebSockets API for OBS Studio

[Benjamin Drung]

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

* Package name: obs-websocket
  Version : 4.9.0
  Upstream Author : Stéphane Lepin 
* URL : https://github.com/Palakis/obs-websocket
* License : GPL-2+
  Programming Lang: C++
  Description : WebSockets API for OBS Studio

 A Websocket API for OBS Studio. The websocket server runs on port  and the
 protocol is based on the OBSRemote protocol (including authentication) with
 some additions specific to OBS Studio.

I will be using this plugin for OBS myself. I will maintain this plugin
as part of the Debian Multimedia Maintainers, because this team
maintains obs-studio.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#892058: Thanks

[Aurélien COUDERC]

Thanks for the heads up, that’s really useful !

Happy hacking,
--
Aurélien

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Sebastian Ramacher]

On 2021-06-20 21:43:45 +0200, Moritz Muehlenhoff wrote:
> On Sat, Jun 19, 2021 at 09:33:37PM +0200, Sebastian Ramacher wrote:
> > Hallo Carsten
> > 
> > On 2021-06-19 09:00:13 +0200, Carsten Schoenert wrote:
> > > Hello Kevin, hello Sebastian,
> > > 
> > > thanks for working on this issue in between times, I wasn't able to do
> > > anything practically the last days.
> > > 
> > > Am 18.06.21 um 23:31 schrieb Kevin Locke:
> > > > Hi Sebastian,
> > > > 
> > > > On Fri, 2021-06-18 at 22:26 +0200, Sebastian Ramacher wrote:
> > > >> Thanks for this detailed analysis. That actually means that the symbol
> > > >> file for libnss3 2:3.67-1 is broken. It would need to bump the minimum
> > > >> version requirement for all symbols that works with SSLChannelInfo. 
> > > >> From
> > > >> your description, at least the version for SSL_GetChannelInfo would 
> > > >> need
> > > >> to be bumped. If thunderbird would then be built against a libnss3
> > > >> version with a fixed symbol files, it would pick up tight enought
> > > >> dependencies.
> > > >>
> > > >> So ideally the bug against thunderbird would be reassigned to libnss3
> > > >> 2:3.67-1 and its severits raised to serious. Once fixed, we can rebuild
> > > >> thunderbird to pick up the correct depedencies.
> > > > 
> > > > Good point.  Fixing the libnss3 symbol file sounds like the right fix to
> > > > me.  As far as I can tell SSL_GetChannelInfo is the only symbol which
> > > > takes SSLChannelInfo.  I've opened https://bugs.debian.org/990058 with
> > > > the proposed fix.
> > > 
> > > Fixing libnss3 is obviously the correct thing anyway. But this will take
> > > its time to get it landed into bullseye.
> > > 
> > > >> But since that version of libnss3 is not in bullseye, the rebuild would
> > > >> not be abile to migrate. Ideally libnss3 would be reverted to the
> > > >> version in bullseye to avoid this issue. Otherwise I can schedule
> > > >> binNMUs of thunderbird in tpu, but that means that we would need to do
> > > >> that for any thunderbird upload that we want in bullseye until the
> > > >> release. That is suboptimal - it's more work with less testing.
> > > > 
> > > > That may be tricky.  firefox 88.0.1-1 in unstable depends on
> > > > libnss3 (>= 2:3.63~).  If the maintainers are willing to upload an NSS
> > > > version between 2:3.63 and 2:3.65, I believe that would solve the issue
> > > > without breaking firefox.  (2:3.63-1 is the only suitable version
> > > > in debian/changelog.)  I've opened https://bugs.debian.org/990059 to
> > > > discuss.
> > > 
> > > To prevent quite a lot of work on all involved parties with not that
> > > much gain in the end I'd suggest to go back to my option B that was to
> > > (re)build Thunderbird with it's internal shipped NSS version.
> > 
> > If that's fine with the security team -- thunderbird updates in stable
> > releases have been performed via DSAs so far -- it's fine with me.
> > Adding the security team to CC.
> 
> No problem at all, this happened for firefox/thunderbird in the past before
> already.

ACK, unblocked the upload that reverts to the embedded nss.

Cheers

> 
> Cheers,
> Moritz
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#990059: Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Moritz Muehlenhoff]

On Sat, Jun 19, 2021 at 09:33:37PM +0200, Sebastian Ramacher wrote:
> Hallo Carsten
> 
> On 2021-06-19 09:00:13 +0200, Carsten Schoenert wrote:
> > Hello Kevin, hello Sebastian,
> > 
> > thanks for working on this issue in between times, I wasn't able to do
> > anything practically the last days.
> > 
> > Am 18.06.21 um 23:31 schrieb Kevin Locke:
> > > Hi Sebastian,
> > > 
> > > On Fri, 2021-06-18 at 22:26 +0200, Sebastian Ramacher wrote:
> > >> Thanks for this detailed analysis. That actually means that the symbol
> > >> file for libnss3 2:3.67-1 is broken. It would need to bump the minimum
> > >> version requirement for all symbols that works with SSLChannelInfo. From
> > >> your description, at least the version for SSL_GetChannelInfo would need
> > >> to be bumped. If thunderbird would then be built against a libnss3
> > >> version with a fixed symbol files, it would pick up tight enought
> > >> dependencies.
> > >>
> > >> So ideally the bug against thunderbird would be reassigned to libnss3
> > >> 2:3.67-1 and its severits raised to serious. Once fixed, we can rebuild
> > >> thunderbird to pick up the correct depedencies.
> > > 
> > > Good point.  Fixing the libnss3 symbol file sounds like the right fix to
> > > me.  As far as I can tell SSL_GetChannelInfo is the only symbol which
> > > takes SSLChannelInfo.  I've opened https://bugs.debian.org/990058 with
> > > the proposed fix.
> > 
> > Fixing libnss3 is obviously the correct thing anyway. But this will take
> > its time to get it landed into bullseye.
> > 
> > >> But since that version of libnss3 is not in bullseye, the rebuild would
> > >> not be abile to migrate. Ideally libnss3 would be reverted to the
> > >> version in bullseye to avoid this issue. Otherwise I can schedule
> > >> binNMUs of thunderbird in tpu, but that means that we would need to do
> > >> that for any thunderbird upload that we want in bullseye until the
> > >> release. That is suboptimal - it's more work with less testing.
> > > 
> > > That may be tricky.  firefox 88.0.1-1 in unstable depends on
> > > libnss3 (>= 2:3.63~).  If the maintainers are willing to upload an NSS
> > > version between 2:3.63 and 2:3.65, I believe that would solve the issue
> > > without breaking firefox.  (2:3.63-1 is the only suitable version
> > > in debian/changelog.)  I've opened https://bugs.debian.org/990059 to
> > > discuss.
> > 
> > To prevent quite a lot of work on all involved parties with not that
> > much gain in the end I'd suggest to go back to my option B that was to
> > (re)build Thunderbird with it's internal shipped NSS version.
> 
> If that's fine with the security team -- thunderbird updates in stable
> releases have been performed via DSAs so far -- it's fine with me.
> Adding the security team to CC.

No problem at all, this happened for firefox/thunderbird in the past before
already.

Cheers,
Moritz

Bug#986735: add some superficial DEP-8 tests to libstrophe

[John Scott]

On Sun, 20 Jun 2021 19:22:52 + John Scott 
wrote:
> I've spruced up the patch a little bit and and made it work on 
> systems not running systemd. The new patch which may be applied with 
> 'git am' to debian/experimental is attached
Forgot to close the bug in the changelog entry...
From 7871954461d561f3bdd76d236085b992052cbc6a Mon Sep 17 00:00:00 2001
From: John Scott 
Date: Sun, 20 Jun 2021 15:30:31 -0400
Subject: [PATCH] Add two superficial DEP-8 tests to test the installed
 package.

---
 debian/changelog  | 10 ++
 debian/tests/build-examples   |  5 +
 debian/tests/control  |  7 +++
 debian/tests/in-band-registration | 27 +++
 4 files changed, 49 insertions(+)
 create mode 100755 debian/tests/build-examples
 create mode 100644 debian/tests/control
 create mode 100755 debian/tests/in-band-registration

diff --git a/debian/changelog b/debian/changelog
index b4318ae..303aa36 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+libstrophe (0.11.0~git20210323.d7a28f9-2) UNRELEASED; urgency=medium
+
+  [ John Scott ]
+  * Add two superficial DEP-8 tests to test the installed package:
+- check that the installed examples can be compiled
+- try making a user using in-band registration on a local server
+(Closes: #986735)
+
+ -- John Scott   Sun, 20 Jun 2021 15:30:31 -0400
+
 libstrophe (0.11.0~git20210323.d7a28f9-1) experimental; urgency=medium
 
   * Team upload
diff --git a/debian/tests/build-examples b/debian/tests/build-examples
new file mode 100755
index 000..115ed22
--- /dev/null
+++ b/debian/tests/build-examples
@@ -0,0 +1,5 @@
+#!/bin/sh
+set -e
+cd "$AUTOPKGTEST_TMP"
+find /usr/share/doc/libstrophe-dev/examples -name '*.c' -exec \
+	sh -c  'gcc {} $(pkg-config --cflags --libs libstrophe) -o $(basename {} .c)' \;
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..3cd62c9
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,7 @@
+Tests: build-examples
+Depends: libstrophe-dev, gcc, pkg-config
+Restrictions: superficial
+
+Tests: in-band-registration
+Depends: libstrophe-dev, gcc, pkg-config, prosody
+Restrictions: isolation-container, needs-root, superficial
diff --git a/debian/tests/in-band-registration b/debian/tests/in-band-registration
new file mode 100755
index 000..75a2684
--- /dev/null
+++ b/debian/tests/in-band-registration
@@ -0,0 +1,27 @@
+#!/bin/sh
+set -e
+
+# Allow in-band registration
+sed -i 's/allow_registration.*$/allow_registration = true/' /etc/prosody/prosody.cfg.lua
+
+# We're probably using an auto-generated self-signed certificate; don't require that clients trust it.
+sed -i 's/c2s_require_encryption.*$/c2s_require_encryption = false/' /etc/prosody/prosody.cfg.lua
+prosodyctl check config
+service prosody restart
+
+cd "$AUTOPKGTEST_TMP"
+cp /usr/share/doc/libstrophe-dev/examples/register.c .
+
+# Delete the block that tries TLS; it may not be trusted.
+sed -i '/child = xmpp_stanza_get_child_by_name(stanza, "starttls")/,/}/d' register.c
+
+gcc register.c -o register $(pkg-config --cflags --libs libstrophe)
+printf "foo\nbar\n" | (./register foo@localhost 2>&1)
+
+prosodyctl deluser foo@localhost
+
+# As an assertion check, let's validate that trying to delete a non-existent user returns failure.
+prosodyctl deluser nonexistent@localhost 2>&1 || FAILED=1
+if [ "$FAILED" != "1" ]
+then exit 1
+fi
-- 
2.30.2



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

Bug#986735: add some superficial DEP-8 tests to libstrophe

[John Scott]

I've spruced up the patch a little bit and and made it work on systems
not running systemd. The new patch which may be applied with 'git am'
to debian/experimental is attached
From a0ec674ae155d4e4596078f286e4f2c29e3aca27 Mon Sep 17 00:00:00 2001
From: John Scott 
Date: Sat, 10 Apr 2021 12:38:10 -0400
Subject: [PATCH] Add two superficial DEP-8 tests to test the installed
 package.

---
 debian/changelog  |  9 +
 debian/tests/build-examples   |  5 +
 debian/tests/control  |  7 +++
 debian/tests/in-band-registration | 27 +++
 4 files changed, 48 insertions(+)
 create mode 100755 debian/tests/build-examples
 create mode 100644 debian/tests/control
 create mode 100755 debian/tests/in-band-registration

diff --git a/debian/changelog b/debian/changelog
index b4318ae..6f661b1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+libstrophe (0.11.0~git20210323.d7a28f9-2) UNRELEASED; urgency=medium
+
+  [ John Scott ]
+  * Add two superficial DEP-8 tests to test the installed package:
+- check that the installed examples can be compiled
+- try making a user using in-band registration on a local server
+
+ -- Debian XMPP Maintainers   Sun, 20 Jun 2021 14:41:49 -0400
+
 libstrophe (0.11.0~git20210323.d7a28f9-1) experimental; urgency=medium
 
   * Team upload
diff --git a/debian/tests/build-examples b/debian/tests/build-examples
new file mode 100755
index 000..115ed22
--- /dev/null
+++ b/debian/tests/build-examples
@@ -0,0 +1,5 @@
+#!/bin/sh
+set -e
+cd "$AUTOPKGTEST_TMP"
+find /usr/share/doc/libstrophe-dev/examples -name '*.c' -exec \
+	sh -c  'gcc {} $(pkg-config --cflags --libs libstrophe) -o $(basename {} .c)' \;
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..3cd62c9
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,7 @@
+Tests: build-examples
+Depends: libstrophe-dev, gcc, pkg-config
+Restrictions: superficial
+
+Tests: in-band-registration
+Depends: libstrophe-dev, gcc, pkg-config, prosody
+Restrictions: isolation-container, needs-root, superficial
diff --git a/debian/tests/in-band-registration b/debian/tests/in-band-registration
new file mode 100755
index 000..75a2684
--- /dev/null
+++ b/debian/tests/in-band-registration
@@ -0,0 +1,27 @@
+#!/bin/sh
+set -e
+
+# Allow in-band registration
+sed -i 's/allow_registration.*$/allow_registration = true/' /etc/prosody/prosody.cfg.lua
+
+# We're probably using an auto-generated self-signed certificate; don't require that clients trust it.
+sed -i 's/c2s_require_encryption.*$/c2s_require_encryption = false/' /etc/prosody/prosody.cfg.lua
+prosodyctl check config
+service prosody restart
+
+cd "$AUTOPKGTEST_TMP"
+cp /usr/share/doc/libstrophe-dev/examples/register.c .
+
+# Delete the block that tries TLS; it may not be trusted.
+sed -i '/child = xmpp_stanza_get_child_by_name(stanza, "starttls")/,/}/d' register.c
+
+gcc register.c -o register $(pkg-config --cflags --libs libstrophe)
+printf "foo\nbar\n" | (./register foo@localhost 2>&1)
+
+prosodyctl deluser foo@localhost
+
+# As an assertion check, let's validate that trying to delete a non-existent user returns failure.
+prosodyctl deluser nonexistent@localhost 2>&1 || FAILED=1
+if [ "$FAILED" != "1" ]
+then exit 1
+fi
-- 
2.30.2



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

Bug#990089: linux-image-4.19.0-17-amd64: lxc-attach fails with Failed to set AppArmor label unconfined

[Salvatore Bonaccorso]

Hi Mark,

On Sun, Jun 20, 2021 at 10:44:29AM +0100, Mark Grant wrote:
> Package: src:linux
> Version: 4.19.194-1
> Severity: normal
> 
> Dear Maintainer,
> 
> After upgrading from linux-image-4.19.0-16-amd64 to 
> linux-image-4.19.0-17-amd64
> attaching an unprivileged linux container fails with the message:
> lxc-attach: debian-buster-amd64-basic: lsm/lsm.c: lsm_process_label_set_at: 
> 174
> Operation not permitted - Failed to set AppArmor label "unconfined"
> Rebooting into linux-image-4.19.0-16-amd64 with no other changes, the lxc
> system works as expected.

I think this is the same issue as in #990072, would you be able to
test the patch as commited
https://salsa.debian.org/kernel-team/linux/-/commit/d3fc7c8514bed949d8797cfd3a50a1bed95629c0
?

Regards,
Salvatore
From: Kees Cook 
Date: Tue, 8 Jun 2021 10:12:21 -0700
Subject: proc: Track /proc/$pid/attr/ opener mm_struct
Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit?id=1f41b8f9577907fba56684231c7be89c8243d960
Bug-Debian: https://bugs.debian.org/990072

commit 591a22c14d3f45cc38bd1931c593c221df2f1881 upstream.

Commit bfb819ea20ce ("proc: Check /proc/$pid/attr/ writes against file opener")
tried to make sure that there could not be a confusion between the opener of
a /proc/$pid/attr/ file and the writer. It used struct cred to make sure
the privileges didn't change. However, there were existing cases where a more
privileged thread was passing the opened fd to a differently privileged thread
(during container setup). Instead, use mm_struct to track whether the opener
and writer are still the same process. (This is what several other proc files
already do, though for different reasons.)

Reported-by: Christian Brauner 
Reported-by: Andrea Righi 
Tested-by: Andrea Righi 
Fixes: bfb819ea20ce ("proc: Check /proc/$pid/attr/ writes against file opener")
Cc: sta...@vger.kernel.org
Signed-off-by: Kees Cook 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman 
---
 fs/proc/base.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/proc/base.c b/fs/proc/base.c
index bc736ea1192a..9f331abc202d 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2535,6 +2535,11 @@ static int proc_pident_readdir(struct file *file, struct dir_context *ctx,
 }
 
 #ifdef CONFIG_SECURITY
+static int proc_pid_attr_open(struct inode *inode, struct file *file)
+{
+	return __mem_open(inode, file, PTRACE_MODE_READ_FSCREDS);
+}
+
 static ssize_t proc_pid_attr_read(struct file * file, char __user * buf,
   size_t count, loff_t *ppos)
 {
@@ -2565,7 +2570,7 @@ static ssize_t proc_pid_attr_write(struct file * file, const char __user * buf,
 	int rv;
 
 	/* A task may only write when it was the opener. */
-	if (file->f_cred != current_real_cred())
+	if (file->private_data != current->mm)
 		return -EPERM;
 
 	rcu_read_lock();
@@ -2613,9 +2618,11 @@ static ssize_t proc_pid_attr_write(struct file * file, const char __user * buf,
 }
 
 static const struct file_operations proc_pid_attr_operations = {
+	.open		= proc_pid_attr_open,
 	.read		= proc_pid_attr_read,
 	.write		= proc_pid_attr_write,
 	.llseek		= generic_file_llseek,
+	.release	= mem_release,
 };
 
 static const struct pid_entry attr_dir_stuff[] = {
-- 
2.32.0

Bug#990107: linux-image-4.19.0-17-amd64: lxc-attach Operation not permitted - Failed to set AppArmor label

[Benoît Ganne]

Package: src:linux
Version: 4.19.194-1
Severity: normal

Since upgrading to linux-image-4.19.0-17-amd64 from 
linux-image-4.19.0-16-amd64, I can no longer enter my lxc container with 
the command 'lxc-attach'. It fails with the message:


lxc-attach: shire: lsm/lsm.c: lsm_process_label_set_at: 174 Operation 
not permitted - Failed to set AppArmor label 
"lxc-shire_//&:lxc-shire_<-var-lib-lxc>:

unconfined"

Reverting to linux-image-4.19.0-16-amd64 version 4.19.181-1 (the 
previous kernel) fixes the issue.


The lxc config for this container is the following:

lxc.include = /usr/share/lxc/config/common.conf
lxc.include = /usr/share/lxc/config/userns.conf
lxc.arch = linux64
lxc.apparmor.profile = generated
lxc.apparmor.allow_nesting = 1
lxc.idmap = u 0 10 90
lxc.idmap = g 0 10 90
lxc.rootfs.path = dir:/var/lib/lxc/shire/rootfs
lxc.uts.name = shire
lxc.net.0.type = empty
lxc.mount.entry=/data/home home none bind 0 0
lxc.mount.entry=/data/mail var/mail none bind 0 0

And the auto-generated AppArmor profile:

#include 
profile "lxc-shire_" 
flags=(attach_disconnected,mediate_deleted) {

  ### Base profile
  capability,
  dbus,
  file,
  network,
  umount,

  # Allow us to receive signals from anywhere.
  signal (receive),

  # Allow us to send signals to ourselves
  signal peer=@{profile_name},

  # Allow other processes to read our /proc entries, futexes, perf 
tracing and
  # kcmp for now (they will need 'read' in the first place). 
Administrators can

  # override with:
  #   deny ptrace (readby) ...
  ptrace (readby),

  # Allow other processes to trace us by default (they will need 'trace' in
  # the first place). Administrators can override with:
  #   deny ptrace (tracedby) ...
  ptrace (tracedby),

  # Allow us to ptrace ourselves
  ptrace peer=@{profile_name},

  # ignore DENIED message on / remount
  deny mount options=(ro, remount) -> /,
  deny mount options=(ro, remount, silent) -> /,

  # allow tmpfs mounts everywhere
  mount fstype=tmpfs,

  # allow hugetlbfs mounts everywhere
  mount fstype=hugetlbfs,

  # allow mqueue mounts everywhere
  mount fstype=mqueue,

  # allow fuse mounts everywhere
  mount fstype=fuse,
  mount fstype=fuse.*,

  # deny access under /proc/bus to avoid e.g. messing with pci devices 
directly

  deny @{PROC}/bus/** wklx,

  # deny writes in /proc/sys/fs but allow binfmt_misc to be mounted
  mount fstype=binfmt_misc -> /proc/sys/fs/binfmt_misc/,
  deny @{PROC}/sys/fs/** wklx,

  # allow efivars to be mounted, writing to it will be blocked though
  mount fstype=efivarfs -> /sys/firmware/efi/efivars/,

  # block some other dangerous paths
  deny @{PROC}/kcore rwklx,
  deny @{PROC}/sysrq-trigger rwklx,

  # deny writes in /sys except for /sys/fs/cgroup, also allow
  # fusectl, securityfs and debugfs to be mounted there (read-only)
  mount fstype=fusectl -> /sys/fs/fuse/connections/,
  mount fstype=securityfs -> /sys/kernel/security/,
  mount fstype=debugfs -> /sys/kernel/debug/,
  deny mount fstype=debugfs -> /var/lib/ureadahead/debugfs/,
  mount fstype=proc -> /proc/,
  mount fstype=sysfs -> /sys/,
  mount options=(rw, nosuid, nodev, noexec, remount) -> /sys/,
  deny /sys/firmware/efi/efivars/** rwklx,
  # note, /sys/kernel/security/** handled below
  mount options=(ro, nosuid, nodev, noexec, remount, strictatime) -> 
/sys/fs/cgroup/,


  # deny reads from debugfs
  deny /sys/kernel/debug/{,**} rwklx,

  # allow paths to be made slave, shared, private or unbindable
  # FIXME: This currently doesn't work due to the apparmor parser 
treating those as allowing all mounts.

#  mount options=(rw,make-slave) -> **,
#  mount options=(rw,make-rslave) -> **,
#  mount options=(rw,make-shared) -> **,
#  mount options=(rw,make-rshared) -> **,
#  mount options=(rw,make-private) -> **,
#  mount options=(rw,make-rprivate) -> **,
#  mount options=(rw,make-unbindable) -> **,
#  mount options=(rw,make-runbindable) -> **,

  # allow bind-mounts of anything except /proc, /sys and /dev
  mount options=(rw,bind) /[^spd]*{,/**},
  mount options=(rw,bind) /d[^e]*{,/**},
  mount options=(rw,bind) /de[^v]*{,/**},
  mount options=(rw,bind) /dev/.[^l]*{,/**},
  mount options=(rw,bind) /dev/.l[^x]*{,/**},
  mount options=(rw,bind) /dev/.lx[^c]*{,/**},
  mount options=(rw,bind) /dev/.lxc?*{,/**},
  mount options=(rw,bind) /dev/[^.]*{,/**},
  mount options=(rw,bind) /dev?*{,/**},
  mount options=(rw,bind) /p[^r]*{,/**},
  mount options=(rw,bind) /pr[^o]*{,/**},
  mount options=(rw,bind) /pro[^c]*{,/**},
  mount options=(rw,bind) /proc?*{,/**},
  mount options=(rw,bind) /s[^y]*{,/**},
  mount options=(rw,bind) /sy[^s]*{,/**},
  mount options=(rw,bind) /sys?*{,/**},

  # allow various ro-bind-*re*-mounts
  mount options=(ro,remount,bind),
  mount options=(ro,remount,bind,nosuid),
  mount options=(ro,remount,bind,noexec),
  mount options=(ro,remount,bind,nodev),
  mount options=(ro,remount,bind,nosuid,noexec),
  mount options=(ro,remount,bind,noexec,nodev),
  mount 

Bug#989103: pulseaudio crashes on startup

[Hideki Yamane]

control: tags -1 -moreinfo
control: tags -1 -unreproducible
control: tags -1 +patch

Hi,

On Mon, 7 Jun 2021 22:37:11 +0300 Igor Kovalenko  
wrote:
> I confirm this is a regression in pulseaudio-14.0, fixed in pulseaudio
> master now.
> 
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/576

 Thank you, let's patch for debian package, then.
 I've attached patches not MR, since some commits were already done
 in master branch.



-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp
>From 7b3a5ada2664e16a44edec2f0abe65f5a12f4fc1 Mon Sep 17 00:00:00 2001
From: Hideki Yamane 
Date: Mon, 21 Jun 2021 02:32:42 +0900
Subject: [PATCH 2/2] note to changelog

---
 debian/changelog | 9 +
 1 file changed, 9 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index dffa6bc8..5ede7839 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+pulseaudio (14.2-2.1) unstable; urgency=medium
+
+  * NMU.
+  * debian/patches
+- Add: 0003-Bug-989103-alsa-mixer-check-if-mapping-is-NULL-befor.patch
+  (Closes: #989103)
+
+ -- Hideki Yamane   Mon, 21 Jun 2021 02:31:10 +0900
+
 pulseaudio (14.2-2) unstable; urgency=medium
 
   * Stop installing the console kit module.
-- 
2.32.0

>From fef59ed6742bdec063267122fdb360826adaed18 Mon Sep 17 00:00:00 2001
From: Hideki Yamane 
Date: Mon, 21 Jun 2021 02:27:34 +0900
Subject: [PATCH 1/2] Add
 0003-Bug-989103-alsa-mixer-check-if-mapping-is-NULL-befor.patch

---
 ...mixer-check-if-mapping-is-NULL-befor.patch | 39 +++
 debian/patches/series |  1 +
 2 files changed, 40 insertions(+)
 create mode 100644 debian/patches/0003-Bug-989103-alsa-mixer-check-if-mapping-is-NULL-befor.patch

diff --git a/debian/patches/0003-Bug-989103-alsa-mixer-check-if-mapping-is-NULL-befor.patch b/debian/patches/0003-Bug-989103-alsa-mixer-check-if-mapping-is-NULL-befor.patch
new file mode 100644
index ..c9f84b66
--- /dev/null
+++ b/debian/patches/0003-Bug-989103-alsa-mixer-check-if-mapping-is-NULL-befor.patch
@@ -0,0 +1,39 @@
+From: Hideki Yamane 
+Date: Mon, 21 Jun 2021 02:25:34 +0900
+Subject: Bug#989103 alsa-mixer: check if mapping is NULL before using it
+
+Taken from upstream git, see
+https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/commit/79cb1369fc4d22966cb65253e9da2ccda2f25b45?merge_request_iid=576
+---
+ src/modules/alsa/alsa-sink.c   | 3 ++-
+ src/modules/alsa/alsa-source.c | 3 ++-
+ 2 files changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
+index f7fef8a..84cdb15 100644
+--- a/src/modules/alsa/alsa-sink.c
 b/src/modules/alsa/alsa-sink.c
+@@ -2107,7 +2107,8 @@ static void find_mixer(struct userdata *u, pa_alsa_mapping *mapping, const char
+ u->mixers = pa_hashmap_new_full(pa_idxset_string_hash_func, pa_idxset_string_compare_func,
+ NULL, (pa_free_cb_t) pa_alsa_mixer_free);
+ 
+-mdev = pa_proplist_gets(mapping->proplist, "alsa.mixer_device");
++if (mapping)
++mdev = pa_proplist_gets(mapping->proplist, "alsa.mixer_device");
+ if (mdev) {
+ u->mixer_handle = pa_alsa_open_mixer_by_name(u->mixers, mdev, true);
+ } else {
+diff --git a/src/modules/alsa/alsa-source.c b/src/modules/alsa/alsa-source.c
+index 76370f8..083f928 100644
+--- a/src/modules/alsa/alsa-source.c
 b/src/modules/alsa/alsa-source.c
+@@ -1813,7 +1813,8 @@ static void find_mixer(struct userdata *u, pa_alsa_mapping *mapping, const char
+ u->mixers = pa_hashmap_new_full(pa_idxset_string_hash_func, pa_idxset_string_compare_func,
+ NULL, (pa_free_cb_t) pa_alsa_mixer_free);
+ 
+-mdev = pa_proplist_gets(mapping->proplist, "alsa.mixer_device");
++if (mapping)
++mdev = pa_proplist_gets(mapping->proplist, "alsa.mixer_device");
+ if (mdev) {
+ u->mixer_handle = pa_alsa_open_mixer_by_name(u->mixers, mdev, false);
+ } else {
diff --git a/debian/patches/series b/debian/patches/series
index 54c06fdd..fe50543a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 disable-autospawn.patch
 tests-fix-use-of-uninitialized-variable-cpu_info.patch
+0003-Bug-989103-alsa-mixer-check-if-mapping-is-NULL-befor.patch
-- 
2.32.0

Bug#983146: 983146 RFS: bung/3.0.7-2 [ITP] -- backup next generation

[Tobias Frost]

Hi Charles, 

(I'm sorry I did not  have time for a complete review, so this one is possibly
incomplete and focuses mostly on that what lintian told me.)

There are a few typos:
I: bung: typo-in-manual-page usr/share/man/man5/bung-common.5.gz Overriden 
Overridden
I: bung: typo-in-manual-page usr/share/man/man5/bung-common.5.gz minumum minimum
I: bung: typo-in-manual-page usr/share/man/man5/check_hotplug_usage.5.gz 
decribed described
I: bung: typo-in-manual-page usr/share/man/man5/hotplug_bu.5.gz decribed 
described
I: bung: typo-in-manual-page usr/share/man/man5/hotplug_bu_launcher.5.gz 
decribed described
I: bung: typo-in-manual-page usr/share/man/man5/mysql_bu.5.gz decribed described
I: bung: typo-in-manual-page usr/share/man/man5/openldap_bu.5.gz decribed 
described
I: bung: typo-in-manual-page usr/share/man/man5/postgres_bu.5.gz decribed 
described
I: bung: typo-in-manual-page usr/share/man/man5/rsync_bu.5.gz decribed described
I: bung: typo-in-manual-page usr/share/man/man5/super_bu.5.gz decribed described
I: bung: typo-in-manual-page usr/share/man/man5/sysinfo_bu.5.gz varaibles 
variables
I: bung: typo-in-manual-page usr/share/man/man5/template_file.5.gz folllowed 
followed
I: bung: typo-in-manual-page usr/share/man/man5/templated_bu.5.gz decribed 
described
I: bung: typo-in-manual-page usr/share/man/man5/templated_bu.5.gz decribed 
described
I: bung: typo-in-manual-page usr/share/man/man8/bung-common.8.gz decribed 
described
I: bung: typo-in-manual-page usr/share/man/man8/check_hotplug_usage.8.gz 
decribed described
I: bung: typo-in-manual-page usr/share/man/man8/hotplug_bu.8.gz decribed 
described
I: bung: typo-in-manual-page usr/share/man/man8/hotplug_bu_launcher.8.gz 
decribed described
I: bung: typo-in-manual-page usr/share/man/man8/mysql_bu.8.gz decribed described
I: bung: typo-in-manual-page usr/share/man/man8/openldap_bu.8.gz decribed 
described
I: bung: typo-in-manual-page usr/share/man/man8/postgres_bu.8.gz decribed 
described
I: bung: typo-in-manual-page usr/share/man/man8/remote_agent.8.gz decribed 
described
I: bung: typo-in-manual-page usr/share/man/man8/rsync_bu.8.gz decribed described
I: bung: typo-in-manual-page usr/share/man/man8/rsync_restore.8.gz decribed 
described
I: bung: typo-in-manual-page usr/share/man/man8/super_bu.8.gz decribed described
I: bung: typo-in-manual-page usr/share/man/man8/sysinfo_bu.8.gz decribed 
described
I: bung: typo-in-manual-page usr/share/man/man8/templated_bu.8.gz decribed 
described

A spare manpage:
I: bung: spare-manual-page usr/share/man/man8/bung-common.8.gz

Old Standard Version:
I: bung source: out-of-date-standards-version 4.1.4 (released 2018-04-05) 
(current is 4.5.1)
(See the Debian Policy for the upgrade checklist; this will then fix also:
P: bung source: silent-on-rules-requiring-root


Old Compat level, using d/compat:
P: bung source: package-uses-old-debhelper-compat-version 11
P: bung source: uses-debhelper-compat-file


Others (partly needs to be checked if valid)
I: bung source: older-debian-watch-file-standard 3
I: bung: possible-documentation-but-no-doc-base-registration


- d/patches/series can be deleted -- there are no patches
- maybe add a d/source/metadata -- see https://wiki.debian.org/UpstreamMetadata
- d/README.Debian is not needed, contains no important infromation. delete it.
- d/changelog targets "UNRELEASED". (Maybe useful: Use dc -r ""  to update it 
and
  update the timestamp.)
- d/control, package description.
- The short package description should explain a bit more a bout bung than
"backup system".
- The extended description maybe should be not only a bullet point list,
  more free text elaborating a bit more about bung, why one wants it and
  its key features. (I know this is usually quite hard, maybe take a look at
  other packages how this is usually done)


Again, sorry, ENOTIME for a complete review, but you can work on those (small) 
issues
already :)


On Sat, Jun 19, 2021 at 09:12:54AM +0530, Charles wrote:
> Thanks tobi, I appreciate the guidance
> 
> bung/3.0.7-2 is now at https://mentors.debian.net/package/bung (3.0.7-2 is
> signed, 3.0.7-1 was not)

-- 
Cheers, 
tobi

Bug#990042: libnet-amazon-perl: Net::Amazon broken with Amazon API changes?

[gregor herrmann]

On Fri, 18 Jun 2021 18:05:12 +0200, gregor herrmann wrote:

> A very brief web search indicates that this API endpoint is retired.
> Which would make Net::Amazon disfunctional …

Upstream came to the same conclusion:

https://github.com/boumenot/p5-Net-Amazon/issues/9#issuecomment-864191600 

> - If Net::Amazon is indeed disfunctional we either need a fix quickly
>   or it shouldn't be in the bullseye release

It looks like there won't be a fix (unless someone appears out of the
blue and rewrites the whole thing), so libnet-amazon-perl should not
be shipped with bullseye (and can probably removed from the archive
alltogether).


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Die Schmetterlinge: Auf unserm langen Weg


signature.asc
Description: Digital Signature

Bug#986821: freecad: Garbled menu makes freecad unusable

[Tobias Frost]

On Sun, Jun 20, 2021 at 01:35:09AM +0200, Michael Jarosch wrote:
> It's been a while…
> 
> Sorry!

Np, thanks for following up!
> 
> Am 16.04.21 um 12:19 schrieb Tobias Frost:
> > Another random idea: Can you try to create a new user and try from
> > there. Just to
> > ensure that there isnt something with your user account (E.g I had a silly 
> > bug where
> > I had something in $HOME/.local shadowing stuff some time ago…)
> 
> I took the time and tried another fresh user - and you were right: FreeCAD
> started up undamaged.
> 
> Now, I'm trying to kill the old config that caused the problem, but that
> seams not to be that easy.
> First of all, I discovered a ~/.FreeCAD AND a ~/.config/FreeCAD directory
> which are both freshly created when renaming them. (Still, that didn't make
> a difference in appearance…)
> Second: I don't know, which file in ~/.local/share is to be deleted/renamed.
> All I can find is a freecad.xml in ~/.local/share/mime/packages and some
> icons in another directory but they don't seem to be involved in my problem.
 
> Another idea?

Its a bit of a big hammer, but you could try stracing it, to see which files
are accessed in your home directory. Maybe that gives a hint…

> Greets!
> 

Bug#990105: Invalid icon name in mate-volume-control.desktop

[Fabrice Creuzot]

Package: mate-media
Version: 1.24.1-1

https://packages.debian.org/bullseye/mate-media

There are translations for the "Icon".
There is also a comment: "Do NOT translate or transliterate this text"

But there is a line translated: "Icon[fr]=multimedia-volume-contrôle"

Please remove all translated icons (it's useless no?)
Or please fix this line to: "Icon[fr]=multimedia-volume-control"

Thanks.

Bug#989270: [Python-modules-team] Bug#989270: Package updated upstream

[Henning Sprang]

On Fri 4. Jun 2021 at 18:35, Emmanuel Arias  wrote:

>
> Hello,
>
> New upstream is ready, but we should wait until the freeze finishes and
> after
> new release of pytest-lazy-fixture is uploaded (see #989471).
>
> I will need sponsorship for this upload.
>

Sorry for the late reply…

I myself can not upload or sponsor, but i talked to Carsten (email aboce)
and he agreed to help!




-- 
Henning Sprang
http://www.sprang.de

Bug#990104: Use of uninitialized value in english/international/l10n/scripts/gen-files.pl

[Laura Arjona Reina]

Package: www.debian.org
Severity: normal
User: www.debian@packages.debian.org
Usertags: scripts
X-Debbugs-CC: debian-i...@lists.debian.org

Hi all,
looking at the build logs of the website ( 
https://www-master.debian.org/build-logs/webwml/wml_run.log ) I've found some 
Perl warnings when building the l10n-related pages:

perl ../../../../english/international/l10n/scripts/gen-files.pl 
--sort=../../../../english/international/l10n/data/popcon --dist=unstable 
--l10ndir=../../../../english/international/l10n  --langs --po --podebconf 
--po4a
Use of uninitialized value in hash element at 
../../../../english/international/l10n/scripts/../../../../Perl/Debian/L10n/Db.pm
 line 264,  line 26457.
[...]
Use of uninitialized value within %LanguageList in concatenation (.) or string 
at ../../../../english/international/l10n/scripts/gen-files.pl line 331.
[...]

(the "[...]" means a lot (hundreds) of repetitions of the same warning).

I've seen this script is called in these makefiles:

english/international/l10n/po4a/Makefile:39:perl 
$(L10N_DIR)/scripts/gen-files.pl --sort=$(SORT_PKGS) --dist=$(DIST) 
--l10ndir=$(L10N_DIR)  --langs --po --podebconf --po4a

english/international/l10n/po/Makefile:46:  perl 
$(L10N_DIR)/scripts/gen-files.pl --sort=$(SORT_PKGS) --dist=$(DIST) 
--l10ndir=$(L10N_DIR)  --langs --po --podebconf --po4a

english/international/l10n/po-debconf/Makefile:52:  perl 
$(L10N_DIR)/scripts/gen-files.pl --sort=$(SORT_PKGS) --dist=$(DIST) 
--l10ndir=$(L10N_DIR)  --langs --po --podebconf --po4a

but I don't know how to fix the issue. I'm creating this bug as a request for 
help.

Kind regards,

Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#990103: gitlab: Conflicting dependencies on google-protobuf prevent package configuration during update

[Maximilian Stein]

Package: gitlab
Version: 13.12.3+ds1-4~fto10+1
Severity: important

Dear Maintainer,

Unfortunately, upgrade to Gitlab 13.12.3+ds1-4~fto10+1 and gitaly
13.12.1+dfsg-4~fto10+1 fails since dependencies on google-protobuf are
conflicting apperently:

---

Setting up gitlab (13.12.3+ds1-4~fto10+1) ...
fatal: not a git repository (or any of the parent directories): .git
fatal: not a git repository (or any of the parent directories): .git
Bundler could not find compatible versions for gem "google-protobuf":
  In Gemfile:
google-protobuf (~> 3.14)

grpc (~> 1.30, >= 1.30.2) was resolved to 1.30.2, which depends on
  google-protobuf (~> 3.12)

gitlab-labkit (~> 0.17.1) was resolved to 0.17.1, which depends on
  pg_query (~> 2.0) was resolved to 2.0.3, which depends on
google-protobuf (~> 3.15, >= 3.15.5)

Could not find gem 'google-protobuf (~> 3.15, >= 3.15.5)', which is required by 
gem 'pg_query (~> 2.0)', in any of the sources.
dpkg: error processing package gitlab (--configure):
 installed gitlab package post-installation script subprocess returned error 
exit status 1
Setting up gitaly (13.12.1+dfsg-4~fto10+1) ...
Resolving dependencies...
Bundler could not find compatible versions for gem "google-protobuf":
  In Gemfile:
grpc (~> 1.30, >= 1.30.2) was resolved to 1.30.2, which depends on
  googleapis-common-protos-types (~> 1.0) was resolved to 1.0.6, which 
depends on
google-protobuf (~> 3.14)

grpc (~> 1.30, >= 1.30.2) was resolved to 1.30.2, which depends on
  google-protobuf (~> 3.12)

gitlab-labkit (~> 0.17.1) was resolved to 0.17.1, which depends on
  pg_query (~> 2.0) was resolved to 2.0.3, which depends on
google-protobuf (~> 3.15, >= 3.15.5)
dpkg: error processing package gitaly (--configure):
 installed gitaly package post-installation script subprocess returned error 
exit status 6
Errors were encountered while processing:
 gitlab
 gitaly
E: Sub-process /usr/bin/dpkg returned an error code (1)



I tried to manually edit the Gemfile without success. How can I fix
the configuration?

Best,
Maximilian

Bug#990102: nmu: qosmic_1.6.0-4

[Peter]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: pe...@pblackman.plus.com

nmu qosmic_1.6.0-4 . ANY . unstable . -m "Rebuild using flam3_3.1.1-4"


flam3 has been updated, mainly to fix a rendering problem,
https://tracker.debian.org/media/packages/f/flam3/changelog-3.1.1-4

and qosmic builds using flam3 via static library.
qosmic was last built using flam3_3.1.1-2+b1

Please nmu qosmic on ANY.


Regards,
Peter

Bug#976796: Sporadically fails to create virtualenv with Python 3.9

[Stefano Rivera]

Hi Daniel (2021.06.14_13:48:37_-0400)
> Turns out there is a file
> ~/.local/share/virtualenv/wheel/3.9/embed/1/setuptools.json with the
> following content:
> 
> {
>   "completed": "2021-05-17T17:34:03.491147Z",
>   "periodic": true,
>   "started": "2021-05-17T17:33:59.488436Z",
>   "versions": [
> {
>   "filename": "setuptools-56.2.0-py3-none-any.whl",
>   "found_date": "2021-05-17T17:33:59.597757Z",
>   "release_date": "2021-05-09T17:40:49.00Z"
> },
> {
>   "filename": "setuptools-56.1.0-py3-none-any.whl",
>   "found_date": "2021-05-17T17:34:01.067885Z",
>   "release_date": "2021-05-04T21:35:13.00Z"
> },
> {
>   "filename": "setuptools-56.0.0-py3-none-any.whl",
>   "found_date": "2021-05-17T17:34:02.299115Z",
>   "release_date": "2021-04-09T00:24:04.00Z"
> }
>   ]
> }
> 
> Removing this file causes this problem to go away!

Aha. Yes, that looks like it may be our culprit.

Those setuptools versions are newer than the ones we use in pip in
Debian, we are still using 44.1.1, for compatibility with Python 2.7.
So, those must have come from the Internet.
Setuptools from the internet will also contain pkg_resources, which is a
separate package in Debian.

Which lead me to find the bug in debian_update_for_available_wheels.patch
It assumes that we're only using data from the internet if "--download"
is passed. However, once it has been updated with
"--upgrade-embed-wheels", it'll be used, even without "--download".

Thanks, again!

SR

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

Bug#989612: mke2fs -E offset=N still warns about existing partition table at the beginning

[Josh Triplett]

On Thu, 17 Jun 2021 10:39:20 +0200 Paul Gevers  wrote:
> On Tue, 08 Jun 2021 09:14:41 -0700 Josh Triplett 
> wrote:
> > mke2fs with -E offset=N does not seem to take the offset into account
> > when checking the target to see if it seems to already contain
> > something.
> 
> Same as for bug 989630, do you know if this is a regression?

Definitely not a regression, no.

Bug#989630: mke2fs with size limit and default discard will discard data after size limit

[Josh Triplett]

On Sun, Jun 20, 2021 at 10:39:13AM -0400, Theodore Ts'o wrote:
> On Sat, Jun 19, 2021 at 08:44:52PM -0700, Josh Triplett wrote:
> > On Thu, Jun 17, 2021 at 10:36:48AM +0200, Paul Gevers wrote:
> > > On Tue, 08 Jun 2021 20:22:39 -0700 Josh Triplett 
> > > wrote:
> > > > Package: e2fsprogs
> > > > Version: 1.46.2-2
> > > > Severity: important
> > > > X-Debbugs-Cc: j...@joshtriplett.org
> > > > 
> > > > "important" because this does cause data loss; not filing as
> > > > release-critical because using mke2fs on a full disk or full disk image
> > > > with a specified size to write a partition may be a niche use case.
> > > 
> > > Do you know if this is a regression with respect to the version in
> > > bullseye (1.46.2-1)?
> > 
> > I'm fairly sure this bug has existed for quite a long time. Please don't
> > let it affect propagation of new versions.
> 
> Indeed, this bug has been around since 2008, and most of the time,
> people only use the size option when they are creating an file system
> in a image file, where this wouldn't matter.  And if they are running
> mke2fs on a partition with a size limit, which is unlikely to begin
> with, it's even more unlikely they would care about what came after
> the file system in the partition.
> 
> That's why no one noticed or complained for 13 years; and so I would
> consider "important" to be a stretch.  :-)

The only reason I used "important" was because it could cause data loss;
I *absolutely* agree that it's an obscure combination of options, though
one that seemed natural to use together.  I only figured out this issue
after spending a while debugging why a virtual machine image wouldn't
boot, before finding that the subsequent EFI system partition had been
partially overwritten.

- Josh

Bug#989269: Package updated upstream

[Emmanuel Arias]

Hi,

thanks for the report. I've just push to salsa the new upstream release.
I mark this issue as pending after freeze end and we can upload to
unstable, if there's any objection.

Cheers,

-- 
Emmanuel Arias
@eamanu
yaerobi.com

Bug#990101: clang-11: Problem building mixed C & C++ code with UBSan sanitizer

[Nikolay Shaplov]

Package: clang-11
Version: 1:11.0.1-2~bpo10+1
Severity: normal

If I have a mixed C/C++ code with classes with virtual function in it, and I
am trying to build it with BUSan with -fno-sanitize-recover=undefined option,
then I get undefined reference error messages

/home/nataraj/test/ubsan_cpp_c/library.cpp:8: undefined reference to 
`__ubsan_vptr_type_cache'
/usr/bin/ld: /home/nataraj/test/ubsan_cpp_c/library.cpp:8: undefined reference 
to `__ubsan_handle_dynamic_type_cache_miss_abort'

I can fix these undefined references by specifying explicitly linking to
clang_rt.ubsan_standalone_cxx-x86_64 library, but this is not how it should
work as I can guess.

Here I offer a sample project that allows to reproduce the problem. (I am not
sure I will be able to add attach via reportbug, if not, I will attach it in
the next message)

When I buitld this project as written in build_ubsan_broken.sh:

make clean

CC=clang-11 CXX=clang++-11 \
CFLAGS="-fsanitize=undefined -fno-sanitize-recover=undefined" \
CXXFLAGS="-fsanitize=undefined -fno-sanitize-recover=undefined" \
LDFLAGS="-fsanitize=undefined -fno-sanitize-recover=undefined"\
 make

building will fail.

But if I add -Wl,--whole-archive -L/usr/lib/clang/11/lib/linux/ 
-lclang_rt.ubsan_standalone_cxx-x86_64 -Wl,--no-whole-archive
to LDFLAGS (see build_ubsan_wokarounded.sh), it will successfully build:

make clean

# Using hack suggested in 
http://clang-developers.42468.n3.nabble.com/fsanitize-undefined-and-shared-libraries-td4029561.html#a4029653
CC=clang-11 CXX=clang++-11 \
CFLAGS="-fsanitize=undefined -fno-sanitize-recover=undefined" \
CXXFLAGS="-fsanitize=undefined -fno-sanitize-recover=undefined" \
LDFLAGS="-fsanitize=undefined -fno-sanitize-recover=undefined 
-Wl,--whole-archive -L/usr/lib/clang/11/lib/linux/ 
-lclang_rt.ubsan_standalone_cxx-x86_64 -Wl,--no-whole-archive"\
 make

I guess this should be fixed and symbols from 
clang_rt.ubsan_standalone_cxx-x86_64 should be added to some library that are
linked by default when you use -fsanitize=undefined

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages clang-11 depends on:
ii  binutils2.31.1-16
ii  libc6   2.28-10
ii  libc6-dev   2.28-10
ii  libclang-common-11-dev  1:11.0.1-2~bpo10+1
ii  libclang-cpp11  1:11.0.1-2~bpo10+1
ii  libclang1-111:11.0.1-2~bpo10+1
ii  libgcc-8-dev8.3.0-6
ii  libgcc1 1:8.3.0-6
ii  libllvm11   1:11.0.1-2~bpo10+1
ii  libobjc-8-dev   8.3.0-6
ii  libstdc++-8-dev 8.3.0-6
ii  libstdc++6  8.3.0-6

Versions of packages clang-11 recommends:
pn  libomp-11-dev  
ii  llvm-11-dev1:11.0.1-2~bpo10+1
ii  python33.7.3-1

Versions of packages clang-11 suggests:
pn  clang-11-doc  

-- no debconf information


ubsan_cpp_c.tgz
Description: application/gzip

Bug#990077: unblock: apache2/2.4.48-3

[Yadd]

Control: tags -1 - moreinfo
Control: retitle -1 unblock: apache2/2.4.48-3

Le 20/06/2021 à 16:35, Sebastian Ramacher a écrit :
> Control: tags -1 moreinfo
> 
> On 2021-06-19 18:13:16 +0200, Yadd wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: unblock
>> X-Debbugs-Cc: secur...@debian.org
>>
>> Please unblock package apache2
>>
>> [...]
>> 
>> diff --git a/debian/apache2-data.lintian-overrides 
>> b/debian/apache2-data.lintian-overrides
>> [...]
>> +apache2 (2.4.47-1) experimental; urgency=medium
>> +
>> +  * Update upstream keys file
>> +  * New upstream version 2.4.47
>> +  * Refresh patches
>> +
>> + -- Yadd   Thu, 29 Apr 2021 08:03:33 +0200
>> +
>> +apache2 (2.4.48-1) experimental; urgency=medium
> 
> I suppose this should be 2.4.46-6 (unstable) instead. Could you please
> fix that?
> 
> Cheers

Sorry, done.

Cheers,
Yadd

unblock apache2/2.4.48-3



OpenPGP_signature
Description: OpenPGP digital signature

Bug#990100: zfs-dkms: Kernel Call Trace in arc_hdr_set_compress+0x50/0x50

[James Youngman]

Package: zfs-dkms
Version: 2.0.3-1~bpo10+1
Severity: minor

Dear Maintainer,

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

* Don't know what provoked the call trace.  This machine is mostly
  used for "zfs recv", it is the target of ZFS replication but
  otherwise is simply a standby machine.


* Not sure what provokes/prevents this problem, but it has not
  happened for a couple of days now.

  This machine has been running ZFS - the same pools - for years without 
problem.   Recent changes:
  
  1. Upgraded from ZFS 0.7.12 to 2.0.3.
  2. Upgraded the pools to add support for recent features.

* What was the outcome of this action?

The machine still seems usable, so I'm not sure there's been any
permanent side effect (hence "minor" rating).

Here are some call traces from /var/log/messages:

Jun 13 00:00:05 asteroid rsyslogd:  [origin software="rsyslogd" 
swVersion="8.1901.0" x-pid="1945" x-info="https://www.rsyslog.com;] rsyslogd 
was HUPed
Jun 13 00:00:08 asteroid colord[2885]: failed to get session [pid 4565]: No 
data available
Jun 13 00:00:13 asteroid colord[2885]: failed to get session [pid 4565]: No 
data available
Jun 13 00:19:55 asteroid kernel: [ 7281.246851] perf: interrupt took too long 
(2507 > 2500), lowering kernel.perf_event_max_sample_rate to 79750
Jun 13 02:40:23 asteroid kernel: [15709.868559] txg_syncD0   817
  2 0x8000
Jun 13 02:40:23 asteroid kernel: [15709.868636] Call Trace:
Jun 13 02:40:23 asteroid kernel: [15709.868686]  __schedule+0x29f/0x840
Jun 13 02:40:23 asteroid kernel: [15709.868743]  schedule+0x28/0x80
Jun 13 02:40:23 asteroid kernel: [15709.868805]  cv_wait_common+0xfb/0x130 [spl]
Jun 13 02:40:23 asteroid kernel: [15709.868870]  ? finish_wait+0x80/0x80
Jun 13 02:40:23 asteroid kernel: [15709.869125]  arc_read+0x1ad/0x1200 [zfs]
Jun 13 02:40:23 asteroid kernel: [15709.869354]  ? 
arc_hdr_set_compress+0x50/0x50 [zfs]
Jun 13 02:40:23 asteroid kernel: [15709.869617]  dsl_scan_visitbp+0x213/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.869879]  dsl_scan_visitbp+0x5ac/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.870139]  dsl_scan_visitbp+0x2c0/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.870399]  dsl_scan_visitbp+0x2c0/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.870659]  dsl_scan_visitbp+0x2c0/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.870918]  dsl_scan_visitbp+0x2c0/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.871178]  dsl_scan_visitbp+0x2c0/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.871438]  dsl_scan_visitbp+0x2c0/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.871698]  dsl_scan_visitbp+0x81b/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.871958]  
dsl_scan_visit_rootbp+0xe7/0x150 [zfs]
Jun 13 02:40:23 asteroid kernel: [15709.87]  dsl_scan_visitds+0x18c/0x4c0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.872357]  ? try_to_wake_up+0x54/0x470
Jun 13 02:40:23 asteroid kernel: [15709.872417]  ? __wake_up_common+0x7a/0x190
Jun 13 02:40:23 asteroid kernel: [15709.872476]  ? _cond_resched+0x15/0x30
Jun 13 02:40:23 asteroid kernel: [15709.872531]  ? __kmalloc_node+0x1ea/0x2c0
Jun 13 02:40:23 asteroid kernel: [15709.872602]  ? spl_kmem_alloc+0xc6/0x110 
[spl]
Jun 13 02:40:23 asteroid kernel: [15709.872677]  ? spl_kmem_alloc+0xc6/0x110 
[spl]
Jun 13 02:40:23 asteroid kernel: [15709.872752]  ? 
tsd_hash_search.isra.2+0x42/0x90 [spl]
Jun 13 02:40:23 asteroid kernel: [15709.872834]  ? tsd_set+0x21c/0x480 [spl]
Jun 13 02:40:23 asteroid kernel: [15709.873091]  dsl_scan_sync+0x869/0x1330 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.873364]  spa_sync+0x5fa/0xfb0 [zfs]
Jun 13 02:40:23 asteroid kernel: [15709.873421]  ? _cond_resched+0x15/0x30
Jun 13 02:40:23 asteroid kernel: [15709.873680]  ? 
spa_txg_history_init_io+0xfe/0x110 [zfs]
Jun 13 02:40:23 asteroid kernel: [15709.873961]  txg_sync_thread+0x29f/0x480 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.874029]  ? __switch_to_asm+0x35/0x70
Jun 13 02:40:23 asteroid kernel: [15709.874292]  ? 
txg_thread_exit.isra.9+0x60/0x60 [zfs]
Jun 13 02:40:23 asteroid kernel: [15709.874375]  ? __thread_exit+0x20/0x20 [spl]
Jun 13 02:40:23 asteroid kernel: [15709.874448]  
thread_generic_wrapper+0x6f/0x80 [spl]
Jun 13 02:40:23 asteroid kernel: [15709.874520]  kthread+0x112/0x130
Jun 13 02:40:23 asteroid kernel: [15709.874570]  ? kthread_bind+0x30/0x30
Jun 13 02:40:23 asteroid kernel: [15709.874624]  ret_from_fork+0x22/0x40
Jun 13 02:42:24 asteroid kernel: [15830.706295] txg_syncD0   817
  2 0x8000
Jun 13 02:42:24 asteroid kernel: [15830.706372] Call Trace:
Jun 13 02:42:24 asteroid kernel: [15830.706426]  __schedule+0x29f/0x840
Jun 13 02:42:24 asteroid kernel: [15830.706484]  schedule+0x28/0x80
Jun 13 02:42:24 asteroid kernel: [15830.706547]  cv_wait_common+0xfb/0x130 [spl]
Jun 13 02:42:24 asteroid kernel: [15830.706612]  ? finish_wait+0x80/0x80
Jun 13 02:42:24 asteroid kernel: [15830.706869]  

Bug#990099: zfs-dkms: Kernel Call Trace in arc_hdr_set_compress+0x50/0x50

[James Youngman]

Package: zfs-dkms
Version: 2.0.3-1~bpo10+1
Severity: minor

Dear Maintainer,

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

* Don't know what provoked the call trace.  This machine is mostly
  used for "zfs recv", it is the target of ZFS replication but
  otherwise is simply a standby machine.


* Not sure what provokes/prevents this problem, but it has not
  happened for a couple of days now.

  This machine has been running ZFS - the same pools - for years without 
problem.   Recent changes:
  
  1. Upgraded from ZFS 0.7.12 to 2.0.3.
  2. Upgraded the pools to add support for recent features.

* What was the outcome of this action?

The machine still seems usable, so I'm not sure there's been any
permanent side effect (hence "minor" rating).

Here are some call traces from /var/log/messages:

Jun 13 00:00:05 asteroid rsyslogd:  [origin software="rsyslogd" 
swVersion="8.1901.0" x-pid="1945" x-info="https://www.rsyslog.com;] rsyslogd 
was HUPed
Jun 13 00:00:08 asteroid colord[2885]: failed to get session [pid 4565]: No 
data available
Jun 13 00:00:13 asteroid colord[2885]: failed to get session [pid 4565]: No 
data available
Jun 13 00:19:55 asteroid kernel: [ 7281.246851] perf: interrupt took too long 
(2507 > 2500), lowering kernel.perf_event_max_sample_rate to 79750
Jun 13 02:40:23 asteroid kernel: [15709.868559] txg_syncD0   817
  2 0x8000
Jun 13 02:40:23 asteroid kernel: [15709.868636] Call Trace:
Jun 13 02:40:23 asteroid kernel: [15709.868686]  __schedule+0x29f/0x840
Jun 13 02:40:23 asteroid kernel: [15709.868743]  schedule+0x28/0x80
Jun 13 02:40:23 asteroid kernel: [15709.868805]  cv_wait_common+0xfb/0x130 [spl]
Jun 13 02:40:23 asteroid kernel: [15709.868870]  ? finish_wait+0x80/0x80
Jun 13 02:40:23 asteroid kernel: [15709.869125]  arc_read+0x1ad/0x1200 [zfs]
Jun 13 02:40:23 asteroid kernel: [15709.869354]  ? 
arc_hdr_set_compress+0x50/0x50 [zfs]
Jun 13 02:40:23 asteroid kernel: [15709.869617]  dsl_scan_visitbp+0x213/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.869879]  dsl_scan_visitbp+0x5ac/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.870139]  dsl_scan_visitbp+0x2c0/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.870399]  dsl_scan_visitbp+0x2c0/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.870659]  dsl_scan_visitbp+0x2c0/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.870918]  dsl_scan_visitbp+0x2c0/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.871178]  dsl_scan_visitbp+0x2c0/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.871438]  dsl_scan_visitbp+0x2c0/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.871698]  dsl_scan_visitbp+0x81b/0xcf0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.871958]  
dsl_scan_visit_rootbp+0xe7/0x150 [zfs]
Jun 13 02:40:23 asteroid kernel: [15709.87]  dsl_scan_visitds+0x18c/0x4c0 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.872357]  ? try_to_wake_up+0x54/0x470
Jun 13 02:40:23 asteroid kernel: [15709.872417]  ? __wake_up_common+0x7a/0x190
Jun 13 02:40:23 asteroid kernel: [15709.872476]  ? _cond_resched+0x15/0x30
Jun 13 02:40:23 asteroid kernel: [15709.872531]  ? __kmalloc_node+0x1ea/0x2c0
Jun 13 02:40:23 asteroid kernel: [15709.872602]  ? spl_kmem_alloc+0xc6/0x110 
[spl]
Jun 13 02:40:23 asteroid kernel: [15709.872677]  ? spl_kmem_alloc+0xc6/0x110 
[spl]
Jun 13 02:40:23 asteroid kernel: [15709.872752]  ? 
tsd_hash_search.isra.2+0x42/0x90 [spl]
Jun 13 02:40:23 asteroid kernel: [15709.872834]  ? tsd_set+0x21c/0x480 [spl]
Jun 13 02:40:23 asteroid kernel: [15709.873091]  dsl_scan_sync+0x869/0x1330 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.873364]  spa_sync+0x5fa/0xfb0 [zfs]
Jun 13 02:40:23 asteroid kernel: [15709.873421]  ? _cond_resched+0x15/0x30
Jun 13 02:40:23 asteroid kernel: [15709.873680]  ? 
spa_txg_history_init_io+0xfe/0x110 [zfs]
Jun 13 02:40:23 asteroid kernel: [15709.873961]  txg_sync_thread+0x29f/0x480 
[zfs]
Jun 13 02:40:23 asteroid kernel: [15709.874029]  ? __switch_to_asm+0x35/0x70
Jun 13 02:40:23 asteroid kernel: [15709.874292]  ? 
txg_thread_exit.isra.9+0x60/0x60 [zfs]
Jun 13 02:40:23 asteroid kernel: [15709.874375]  ? __thread_exit+0x20/0x20 [spl]
Jun 13 02:40:23 asteroid kernel: [15709.874448]  
thread_generic_wrapper+0x6f/0x80 [spl]
Jun 13 02:40:23 asteroid kernel: [15709.874520]  kthread+0x112/0x130
Jun 13 02:40:23 asteroid kernel: [15709.874570]  ? kthread_bind+0x30/0x30
Jun 13 02:40:23 asteroid kernel: [15709.874624]  ret_from_fork+0x22/0x40
Jun 13 02:42:24 asteroid kernel: [15830.706295] txg_syncD0   817
  2 0x8000
Jun 13 02:42:24 asteroid kernel: [15830.706372] Call Trace:
Jun 13 02:42:24 asteroid kernel: [15830.706426]  __schedule+0x29f/0x840
Jun 13 02:42:24 asteroid kernel: [15830.706484]  schedule+0x28/0x80
Jun 13 02:42:24 asteroid kernel: [15830.706547]  cv_wait_common+0xfb/0x130 [spl]
Jun 13 02:42:24 asteroid kernel: [15830.706612]  ? finish_wait+0x80/0x80
Jun 13 02:42:24 asteroid kernel: [15830.706869]  

Bug#990065: unblock: squid-deb-proxy/0.8.15+nmu1

[Cyril Brulebois]

Sebastian Ramacher  (2021-06-20):
> I'm not an apparmor expert, but is this enough? Shouldn't there also be
> a profile for the binary that uses this abstraction?
> 
> In any case, the package builds an udeb. Cyril, could you please (N)ACK
> for D-I?

Such apparmor things are no factor for d-i, no objections.


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


signature.asc
Description: PGP signature

Bug#989612: mke2fs -E offset=N still warns about existing partition table at the beginning

[Theodore Ts'o]

On Thu, Jun 17, 2021 at 10:39:20AM +0200, Paul Gevers wrote:
> Control: block 988830 by -1
> 
> Hi Josh, Theodore,
> 
> On Tue, 08 Jun 2021 09:14:41 -0700 Josh Triplett 
> wrote:
> > mke2fs with -E offset=N does not seem to take the offset into account
> > when checking the target to see if it seems to already contain
> > something.
> 
> Same as for bug 989630, do you know if this is a regression?

Nope, this has been around since 2013, and Josh is the first person to
have noticed and complained.

The offset feature is super-rare, and most of the time it's used only
as part of an automated image-building script where the image contains
a partition table as well as one or more file systems.

- Ted

Bug#989630: mke2fs with size limit and default discard will discard data after size limit

[Theodore Ts'o]

On Sat, Jun 19, 2021 at 08:44:52PM -0700, Josh Triplett wrote:
> On Thu, Jun 17, 2021 at 10:36:48AM +0200, Paul Gevers wrote:
> > On Tue, 08 Jun 2021 20:22:39 -0700 Josh Triplett 
> > wrote:
> > > Package: e2fsprogs
> > > Version: 1.46.2-2
> > > Severity: important
> > > X-Debbugs-Cc: j...@joshtriplett.org
> > > 
> > > "important" because this does cause data loss; not filing as
> > > release-critical because using mke2fs on a full disk or full disk image
> > > with a specified size to write a partition may be a niche use case.
> > 
> > Do you know if this is a regression with respect to the version in
> > bullseye (1.46.2-1)?
> 
> I'm fairly sure this bug has existed for quite a long time. Please don't
> let it affect propagation of new versions.

Indeed, this bug has been around since 2008, and most of the time,
people only use the size option when they are creating an file system
in a image file, where this wouldn't matter.  And if they are running
mke2fs on a partition with a size limit, which is unlikely to begin
with, it's even more unlikely they would care about what came after
the file system in the partition.

That's why no one noticed or complained for 13 years; and so I would
consider "important" to be a stretch.  :-)

- Ted

Bug#990077: unblock: apache2/2.4.48-2

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-06-19 18:13:16 +0200, Yadd wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: secur...@debian.org
> 
> Please unblock package apache2
> 
> [ Reason ]
> In the past we had some problems to follow CVE fixes for Apache2. For
> Buster, we had to import the whole http2 module from 2.4.46 into 2.4.38
> because it was impossible to apply the upstream fix due to module
> changes. This isolated import was really risky but we didn't found a
> better way.
> 
> Now the story restarts with CVE-2021-31618. The upstream fix is simple
> but refers to other changes. In particular the whole SSL stack changed.
> Even for Bullseye, there are too many differences between 2.4.46 and
> 2.4.48 to apply this fix.
> 
> Apache2 is RFH for years, but has too many reverse dependencies to be
> removed from Bullseye (even if there are some alternatives).
> 
> Our current apache2 policy keeps a lot of (maybe unimportant) CVE
> opened.
> 
> So we decided to follow upstream changes for Bullseye. So this is the
> last version which fixes 6 CVEs (one grave)/
> 
> [ Impact ]
> Multiple security issues.
> 
> [ Tests ]
> Tests passed (autopkgtest)
> 
> [ Risks ]
> Patch isn't trivial, but it looks like upstream provides version fully
> tested.
> 
> [ Checklist ]
>   [X] all changes are documented in the d/changelog
>   [X] I reviewed all changes and I approve them
>   [X] attach debdiff against the package in testing
> 
> [ Other info ]
> The dedbiff contains only debian/* changes. I found not interessant to
> provide the real debdiff which is really big.
> 
> Cheers,
> Yadd
> 
> unblock apache2/2.4.48-2

> diff --git a/debian/apache2-data.lintian-overrides 
> b/debian/apache2-data.lintian-overrides
> index 902735d7..fa617892 100644
> --- a/debian/apache2-data.lintian-overrides
> +++ b/debian/apache2-data.lintian-overrides
> @@ -1 +1,5 @@
>  debian-changelog-file-is-a-symlink
> +package-contains-documentation-outside-usr-share-doc 
> usr/share/apache2/default-site/index.html
> +package-contains-documentation-outside-usr-share-doc 
> usr/share/apache2/error/include/bottom.html
> +package-contains-documentation-outside-usr-share-doc 
> usr/share/apache2/error/include/spacer.html
> +package-contains-documentation-outside-usr-share-doc 
> usr/share/apache2/error/include/top.html
> diff --git a/debian/apache2.logrotate b/debian/apache2.logrotate
> index 37c5f22e..9d2356da 100644
> --- a/debian/apache2.logrotate
> +++ b/debian/apache2.logrotate
> @@ -1,20 +1,20 @@
>  /var/log/apache2/*.log {
> - daily
> - missingok
> - rotate 14
> - compress
> - delaycompress
> - notifempty
> - create 640 root adm
> - sharedscripts
> - postrotate
> -if invoke-rc.d apache2 status > /dev/null 2>&1; then \
> -invoke-rc.d apache2 reload > /dev/null 2>&1; \
> -fi;
> - endscript
> - prerotate
> - if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
> - run-parts /etc/logrotate.d/httpd-prerotate; \
> - fi; \
> - endscript
> +daily
> +missingok
> +rotate 14
> +compress
> +delaycompress
> +notifempty
> +create 640 root adm
> +sharedscripts
> +prerotate
> + if [ -d /etc/logrotate.d/httpd-prerotate ]; then
> + run-parts /etc/logrotate.d/httpd-prerotate
> + fi
> +endscript
> +postrotate
> + if pgrep -f ^/usr/sbin/apache2 > /dev/null; then
> + invoke-rc.d apache2 reload
> + fi
> +endscript
>  }
> diff --git a/debian/changelog b/debian/changelog
> index fa775057..fef71d5b 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,4 +1,40 @@
> -apache2 (2.4.46-6) unstable; urgency=medium
> +apache2 (2.4.48-2) unstable; urgency=medium
> +
> +  * Back to unstable: Apache2 will follow upstream changes for Bullseye
> +
> +  [ Christian Ehrhardt ]
> +  * d/t/control, d/t/check-http2: basic test for http2 (Closes: #884068)
> +
> + -- Yadd   Sat, 19 Jun 2021 17:50:29 +0200
> +
> +apache2 (2.4.48-1) experimental; urgency=medium
> +
> +  [ Daniel Lewart ]
> +  * Update apache2.logrotate (Closes: #979813)
> +
> +  [ Andreas Hasenack ]
> +  * Avoid test suite failure (Closes: #985012)
> +
> +  [ Yadd ]
> +  * Update lintian overrides
> +  * Re-export upstream signing key without extra signatures.
> +
> +  [ Ondřej Surý ]
> +  * New upstream version 2.4.48 (Closes: CVE-2019-17567, CVE-2020-13938,
> +CVE-2020-13950, CVE-2020-35452, CVE-2021-26690, CVE-2021-26691,
> +CVE-2021-30641, CVE-2021-31618)
> +
> + -- Ondřej Surý   Tue, 08 Jun 2021 08:29:35 +0200
> +
> +apache2 (2.4.47-1) experimental; urgency=medium
> +
> +  * Update upstream keys file
> +  * New upstream version 2.4.47
> +  * Refresh patches
> +
> + -- Yadd   Thu, 29 Apr 2021 08:03:33 +0200
> +
> +apache2 (2.4.48-1) experimental; urgency=medium

I suppose this should be 2.4.46-6 

Bug#989839: Thunderbird 1:78.11.0-1 in testing lacks full functionality

[Carsten Schoenert]

Hello Sebastian,

Am 19.06.21 um 21:33 schrieb Sebastian Ramacher:
...
>> To prevent quite a lot of work on all involved parties with not that
>> much gain in the end I'd suggest to go back to my option B that was to
>> (re)build Thunderbird with it's internal shipped NSS version.
> 
> If that's fine with the security team -- thunderbird updates in stable
> releases have been performed via DSAs so far -- it's fine with me.
> Adding the security team to CC.

thanks, I pushed 1:78.11.0-2 to unstable.
This will fix the current issues for the users.

-- 
Regards
Carsten

Bug#990008: Kernel Bug re PCI power state

[MK]

As a further update, I have opened a Kernel bug ( 
https://bugzilla.kernel.org/show_bug.cgi?id=213481 ), as this appears to be a 
bug introduced with commit 4514d991d99211f225d83b7e640285f29f0755d0 ( 
https://github.com/torvalds/linux/commit/4514d991d99211f225d83b7e640285f29f0755d0
 ) to the kernel which, in the 5.10.x branch was introduced in 5.10.36.
It would appear something about this change that the e1000e driver is not 
handling properly on this system, causing the card to not work.
Hopeful for a fix and may be wise to incorporate into the current kernel before 
the final release of Debian 11, as this will likely break other users' systems 
on the upgrade from Debian 10 to 11.

Bug#990065: unblock: squid-deb-proxy/0.8.15+nmu1

[Sebastian Ramacher]

Control: tags -1 moreinfo d-i

On 2021-06-19 15:33:48 +0900, Hideki Yamane wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package squid-deb-proxy
> 
> [ Reason ]
>  squid-deb-proxy needs its apparmor profile to work.
> 
> [ Impact ]
>  squid-deb-proxy does not work on bullseye
>  (There's a alternative, so not grave for all users).
> 
> [ Tests ]
>  Tested on KVM bullseye environment, it does not work well without
>  this changes as the bug report says, and patched system works fine.
> 
> [ Risks ]
>  None, IMHO.
>   - It's leaf package
>   - Its change does not affect its behavior, it's just for apparmor and
> does not affect other package, too.
>   - Code is trivial one
> 
> [ Checklist ]
>   [x] all changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in testing
> 
> 
> unblock squid-deb-proxy/0.8.15+nmu1

> diff -Nru squid-deb-proxy-0.8.15/debian/apparmor-profiles/squid-deb-proxy 
> squid-deb-proxy-0.8.15+nmu1/debian/apparmor-profiles/squid-deb-proxy
> --- squid-deb-proxy-0.8.15/debian/apparmor-profiles/squid-deb-proxy   
> 1970-01-01 09:00:00.0 +0900
> +++ squid-deb-proxy-0.8.15+nmu1/debian/apparmor-profiles/squid-deb-proxy  
> 2021-06-14 23:38:09.0 +0900
> @@ -0,0 +1,6 @@
> +# vim:syntax=apparmor
> +
> +/etc/squid-deb-proxy/** r,
> +/var/log/squid-deb-proxy/* rw,
> +/run/squid-deb-proxy.pid rwk,
> +/var/cache/squid-deb-proxy/** rw,
> diff -Nru squid-deb-proxy-0.8.15/debian/changelog 
> squid-deb-proxy-0.8.15+nmu1/debian/changelog
> --- squid-deb-proxy-0.8.15/debian/changelog   2020-01-19 03:00:55.0 
> +0900
> +++ squid-deb-proxy-0.8.15+nmu1/debian/changelog  2021-06-14 
> 23:41:11.0 +0900
> @@ -1,3 +1,10 @@
> +squid-deb-proxy (0.8.15+nmu1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Add apparmor profiles to work (Closes: #932501)
> +
> + -- Hideki Yamane   Mon, 14 Jun 2021 23:41:11 +0900
> +
>  squid-deb-proxy (0.8.15) unstable; urgency=medium
>  
>[ Graham Cantin ]
> diff -Nru squid-deb-proxy-0.8.15/debian/squid-deb-proxy.dirs 
> squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.dirs
> --- squid-deb-proxy-0.8.15/debian/squid-deb-proxy.dirs2020-01-10 
> 19:02:40.0 +0900
> +++ squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.dirs   2021-06-14 
> 23:40:40.0 +0900
> @@ -1,2 +1,3 @@
>  etc/resolvconf/update-libc.d
> +etc/apparmor.d/abstractions/squid-deb-proxy
>  var/log/squid-deb-proxy
> diff -Nru squid-deb-proxy-0.8.15/debian/squid-deb-proxy.install 
> squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.install
> --- squid-deb-proxy-0.8.15/debian/squid-deb-proxy.install 2020-01-10 
> 19:02:40.0 +0900
> +++ squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.install
> 2021-06-14 23:40:21.0 +0900
> @@ -1,3 +1,4 @@
>  ../update-libc.d etc/resolvconf/
>  etc/squid-deb-proxy
>  init-common.sh usr/share/squid-deb-proxy/
> +../apparmor-profiles/* etc/apparmor.d/abstractions/squid-deb-proxy/

I'm not an apparmor expert, but is this enough? Shouldn't there also be
a profile for the binary that uses this abstraction?

In any case, the package builds an udeb. Cyril, could you please (N)ACK
for D-I?

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#986527: sagemath: FTBFS: addressing for Bullseye & newcomer suggestions

[John Scott]

On Wed, 09 Jun 2021 00:32:02 + John Scott 
wrote:
> I believe it's in the best interest of Debian users that this bug be
> downgraded for Bullseye so Sage can be used in the mostly-wholesome
> shape it's in, but since I lack expertise in maintaining it I too 
> will leave this to someone else.

If you're looking for someone that can be committed to fixing issues in
SageMath for the duration of the stable release cycle, I think I can
step up to the plate, with the caveat that I will have to learn as I go
since I don't yet know Python, but would like to learn and could seize
this opportunity. (C is my forte, so perhaps I can help with some
dependencies.)

I've sent a merge request to add a superficial autopkgtest checking
that 'sage -v' works, as it has broken in the past, and would
appreciate if it could be merged (I believe this is appropriate during
the freeze):
https://salsa.debian.org/science-team/sagemath/-/merge_requests/14

Please let me know if there is any other low-hanging fruit I could work
on as a newcomer to get acquainted with the package.


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

Bug#990098: RFP: lua-format -- A Lua code formatter

[Kim Alvefur (Zash)]

Package: wnpp
Severity: wishlist

* Package name: lua-format
  Version : 1.3.6
  Upstream Author : Koihik 
* URL : https://github.com/Koihik/LuaFormatter
* License : Apache 2.0
  Programming Lang: C++
  Description : A Lua code formatter

A configurable code formatter for the Lua language.

I have been using this for a while, installed via LuaRocks, and it works fine.

Bug#990097: duperemove: Searching duplicate extends aborts with ERROR: hash-tree.h:80

[Benedikt Wildenhain (BO)]

Package: duperemove
Version: 0.11.2-3
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I ran the following command:
duperemove -dr --hashfile=/root/$VOLUME.hash /mnt/$VOLUME
with /mnt/$VOLUME being a btrfs device. This has worked before. (I plan
do rerun the job at a later point of time to check reproducability,
however this process takes several hours so it won't be possible today)

   * What was the outcome of this action?

The action was aborted with the following messages:

[28851/28851] (100.00%) csum: /mnt/$VOLUME/$somefile
Total files:  28851
Total extent hashes: 961397
Loading only duplicated hashes from hashfile.
Hashing completed. Using 2 threads to calculate duplicate extents. This may 
take some time.
ERROR: hash-tree.h:80
ERROR: hash-tree.h:80
[stack trace follows]
duperemove(print_stack_trace+0x2e) [0x55584fc9c93e]
duperemove(+0xcd2c) [0x55584fc9ed2c]
duperemove(+0xd0ac) [0x55584fc9f0ac]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x7b9a4) [0x7f3ac07079a4]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x7b0bd) [0x7f3ac07070bd]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8ea7) [0x7f3ac02f7ea7]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f3ac0481def]
Aborted

   * What outcome did you expect instead?
duperemove should have find duplicate files and deduplicate them.

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

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

Versions of packages duperemove depends on:
ii  libc6 2.31-12
ii  libglib2.0-0  2.66.8-1
ii  libsqlite3-0  3.34.1-3

duperemove recommends no packages.

duperemove suggests no packages.

-- no debconf information

Regards,
Benedikt Wildenhain

Bug#843846: AU.- I HAVE A PROPOSAL TO DISCUSS WITH YOU

[Matthew ADE]

Bug#990096: jenkins.debian.org: README refers to alioth.debian.org to trigger a job

[Roland Clobus]

Package: jenkins.debian.org
Severity: wishlist

The README document refers to alioth.debian.org for triggering a rescheduling.
This no longer works, since alioth is shut down some time ago.
Is there an alternative?

With kind regards,
Roland Clobus

Quote:
* If you are in the reproducible team you can reschedule packages by yourself:
** log into alioth.debian.org via ssh, in the team home
(/home/groups/reproducible/) there is a reschedule.sh script you can call. Use
the --help switch to get the online help.

Bug#990095: libkcapi-dev: Please ship pkgconfig file

[Andreas Metzler]

Package: libkcapi-dev
Version: 1.2.1-1
Severity: wishlist

Hello,

upstream generates a pkgconfig file, please ship it.

cu Andreas

Bug#899086: xserver-xorg-video-amdgpu: completely fails to detect AMD RX 550 (which uses the Polaris 12 chipset) unless firmware-amd-graphics package installed

[Simon Iremonger (debian)]

Alan and bug 899086,

Please try testing if this situation is improved or fixed in debian
testing (to soon become bullseye) images, similarly to as you did
before.

In fact the cdimage address you linked seems to be still exactly correct!.

I'd like to see bug-report either closed or updated for bullseye.
Given all the changes/massive improvements in amdgpu modesetting
I expect the situation to be considerably improved, at least!.

--Simon

Bug#990094: upgrade failed: efivarfs_get_variable: No such file

[G Smith]

Package: shim-helpers-amd64-signed
Version: 1+15.4+5~deb10u1

I tried upgrading to the latest Debian stable release (10.10) on a 3yr
old desktop and received an installation error. The system failed to
upgrade shim-helpers-amd64-signed and shim-signed:amd64. The
reproducible command and response are below:

-
$ ~: sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  linux-headers-4.19.0-14-amd64 linux-headers-4.19.0-14-common
  linux-image-4.19.0-14-amd64
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up shim-helpers-amd64-signed (1+15.4+5~deb10u1) ...
Installing for x86_64-efi platform.
grub-install: warning: efivarfs_get_variable:
open(/sys/firmware/efi/efivars/blk0-47c7b225-c42a-11d2-8e57-00a0c969723b):
No such file or directory.
grub-install: warning: efi_get_variable: ops->get_variable failed: No
such file or directory.
grub-install: warning: device_get: could not access
/sys/block/sda/device/device: No such file or directory.
grub-install: warning: get_file: could not open file
"/sys/devices/pci:00/firmware_node/path" for reading: No such file
or directory.
grub-install: warning: get_file: could not open file
"/sys/devices/pci:00/firmware_node/hid" for reading: No such file
or directory.
grub-install: warning: parse_acpi_hid_uid: could not read
devices/pci:00/firmware_node/hid: No such file or directory.
grub-install: warning: device_get: parsing pci_root failed: No such
file or directory.
grub-install: warning: efi_va_generate_file_device_path_from_esp:
could not get ESP disk info: No such file or directory.
grub-install: warning: efi_generate_file_device_path_from_esp: could
not generate File DP from ESP: No such file or directory.
grub-install: error: failed to register the EFI boot entry: No such
file or directory.
dpkg: error processing package shim-helpers-amd64-signed (--configure):
 installed shim-helpers-amd64-signed package post-installation script
subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of shim-signed:amd64:
 shim-signed:amd64 depends on shim-helpers-amd64-signed (>=
1+15.4+2~deb10u1); however:
  Package shim-helpers-amd64-signed is not configured yet.

dpkg: error processing package shim-signed:amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 shim-helpers-amd64-signed
 shim-signed:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)


The directory requested in the first warning message
(/sys/firmware/efi/efivars/) exists and contains about 60 files.
However I see no file resembling anything the upgrade is looking for.
I am using EFI

$ ~: sudo dmesg | grep "EFI v"
[0.00] efi: EFI v2.40 by American Megatrends


--

In case it is of help:

$ ~: efibootmgr -v
BootCurrent: 
Timeout: 1 seconds
BootOrder: ,0003,0002,0001
Boot* debian
HD(1,GPT,c4162bc4-5eaf-4fec-afe3-d72750348806,0x800,0x10)/File(\EFI\DEBIAN\SHIMX64.EFI)
Boot0001* CD/DVD
Drive   BBS(CDROM,,0x0)..GO..NOo.M.A.T.S.H.I.T.A.D.V.D.R.W.
.U.J.8.A.7.A.FA...>..Gd-.;.A..MQ..L.
. . . . . . . .R.W.6.6. . .2.0.7.4.5.7BO
Boot0002* Hard DriveBBS(HD,,0x0)..GO..NOo.S.a.m.s.u.n.g.
.S.S.D. .8.5.0. .P.R.O.
.1.T.BA...>..Gd-.;.A..MQ..L.3.S.2.D.X.N.J.0.0.4.5.0.4.5.
.T. . . . BO..NOo.W.D.C.
.W.D.6.0.0.2.F.R.Y.Z.-.0.1.W.D.5.B.0A...>..Gd-.;.A..MQ..L.C.N.M.H.Z.W.S.J.
. . . . . . . . . . . BO


Please let me know if any additional information is needed.

Thank you.

Bug#990093: partitionmanager: Missing File System Support dialog points to outdated cryptsetup project location

[Aashutosh]

Package: partitionmanager
Version: 20.12.2-2
Severity: minor
Tags: a11y

Dear Maintainer,

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

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

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


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

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

Versions of packages partitionmanager depends on:
ii  kio   5.78.0-4
ii  libc6 2.31-12
ii  libkf5configcore5 5.78.0-4
ii  libkf5configgui5  5.78.0-4
ii  libkf5configwidgets5  5.78.0-2
ii  libkf5coreaddons5 5.78.0-4
ii  libkf5crash5  5.78.0-3
ii  libkf5dbusaddons5 5.78.0-2
ii  libkf5i18n5   5.78.0-2
ii  libkf5jobwidgets5 5.78.0-2
ii  libkf5kiocore55.78.0-4
ii  libkf5kiogui5 5.78.0-4
ii  libkf5widgetsaddons5  5.78.0-2
ii  libkf5xmlgui5 5.78.0-2
ii  libkpmcore10  20.12.3-2
ii  libqt5core5a  5.15.2+dfsg-7
ii  libqt5gui55.15.2+dfsg-7
ii  libqt5widgets55.15.2+dfsg-7
ii  libstdc++610.2.1-6

partitionmanager recommends no packages.

Versions of packages partitionmanager suggests:
pn  btrfs-progs
ii  dosfstools 4.2-1
pn  hfsplus
pn  hfsutils   
pn  jfsutils   
ii  ntfs-3g1:2017.3.23AR.3-4
pn  reiser4progs   
pn  reiserfsprogs  
pn  xfsprogs   

-- no debconf information

Bug#980561: Fix für Bullseye

[Philipp Kolmann]

Hi,

I have faced the same issue and with several sources across the internet 
I was able to fix it for me.


1.) Adding a wwsympa.service
2.) Changing the apache config.

Maybe this helps someone facing the issues while updating to bullseye.

cheers
Philipp
--- /etc/apache2/conf-available/sympa.conf_ORIG	2021-03-12 14:55:03.799536684 +0100
+++ /etc/apache2/conf-available/sympa.conf	2021-06-20 13:24:42.543000224 +0200
@@ -18,8 +18,8 @@
 Require all granted
 
 
-ScriptAlias /sympa /usr/lib/cgi-bin/sympa/wwsympa-wrapper.fcgi
-
+
+SetHandler "proxy:unix:/run/sympa/wwsympa.socket|fcgi://"
 Require all granted
-
+
 
[Unit]
Description=WWSympa - Web interface for Sympa mailing list manager
After=syslog.target sympa.service
 
[Service]
Type=forking
PIDFile=/run/sympa/wwsympa.pid
ExecStart=/usr/bin/spawn-fcgi -F $FCGI_CHILDREN \
-P /run/sympa/wwsympa.pid \
-s /run/sympa/wwsympa.socket \
-u $FCGI_USER -g $FCGI_GROUP $FCGI_OPTS -- \
/usr/lib/cgi-bin/sympa/wwsympa.fcgi
Environment="FCGI_CHILDREN=5"
Environment="FCGI_USER=sympa"
Environment="FCGI_GROUP=sympa"
Environment="FCGI_OPTS=-M 0600 -U www-data"
Restart=always

[Install]
WantedBy=multi-user.target

Bug#990092: kmod: Enable zstd support

[Andres Freund]

Package: kmod
Version: 28-1
Severity: wishlist

Hi,

Since version 28 kmod supports zstd compression [1]. As using xz module 
compression
makes building kernels painfully slow, and zstd achieves pretty decent ratios
at a much lower compression time, it would be good to have support for that
zstd in kmod.

Regards,

Andres Freund

[1] 
https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/commit/?id=3821e1971ec53fa9f2679ea988ee12db61c8

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

Kernel: Linux 5.13.0-rc6-andres-00267-g913ec3c22ef4 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_WARN
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)

Versions of packages kmod depends on:
ii  libc6  2.31-12
ii  libkmod2   28-1
ii  liblzma5   5.2.5-2
ii  libssl1.1  1.1.1k-1
ii  lsb-base   11.1.0

kmod recommends no packages.

kmod suggests no packages.

-- no debconf information

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

[Romain Francoise]

Right, this is indeed about apparmor.

The apparmor profile for tcpdump grants rw access to *.pcap. You're
using a capture file named "ax0.cap", which doesn't match. I couldn't
reproduce because I was testing the same scenario with the correct
extension. I guess the simple fix would be to also grant access to
*.cap in addition to *.pcap.

And in this case, "-Z root" doesn't restore the expected behavior
because the apparmor sandbox applies to the process even when it's
running as root, so it can only open files it owns or that otherwise
match the policy.

Bug#890357: Graphical issues with an RX 480

[Simon Iremonger (debian)]

Can you confirm this issue is/is-not relevant any more on either of:-
* Debian Bullseye (testing)
* Debian Buster (stable) with the backported version of kernel
(5.10.0-0.bpo.7)  installed.

Amdgpu has improved a long way since the time this bug report was
created, and would be good to get the bug closed or issue forwarded
upstream if still relevant.

--simon

Bug#990091: RFC: rmapi -- Go app that allows you to access your reMarkable tablet files through the Cloud API

[Johannes Schilling]

Package: wnpp
Severity: wishlist


* Package name: rmapi
  Upstream Author : Javier Uruen Val 
* URL : https://github.com/juruen/rmapi
* License : AGPL-3.0
  Programming Lang: Go
  Description : Go app that allows you to access your reMarkable
tablet files through the Cloud API
.
You can interact with the different API end-points through a shell.
However, you can also run commands non-interactively. This may come
in handy to script certain workflows such as taking automatic
backups or uploading documents programmatically.

Bug#990090: linux-source-4.19: Cannot install buster mips64el in qemu, panics

[Rich Ercolani]

Package: linux-source-4.19
Severity: normal

Dear Maintainer,

Trying to boot the buster installer inside qemu-system-mips64el
with my setup kernel panics almost instantly with the message
"No memory area to place a bootmap bitmap".

Using the incantation:
qemu-system-mips64el -M malta -cpu 5KEc -drive 
file=mips64el_buster_disk,format=raw -m 2048 -nographic -no-reboot  -net 
nic,model=virtio-net-pci -net user -kernel 
mips64el_buster/installer_old/vmlinux-4.19.0-5-5kc-malta -initrd 
mips64el_buster/installer_old/initrd.gz -append "console=ttyS0"

it panics, while the same with mips64el_disk and the 5.10.0-6-5kc-malta
kernel+initrd from bullseye works fine.

I first tried this with the 4.19.0-17-5kc-malta from 10.10, then I
tried it with the older installer kernel+initrd to see if it was a
regression from earlier buster or e.g. stretch. (As you can see from how I'm
reporting it, it appears to have been broken all buster.)

- Rich

Bug#990073: dpkg-gencontrol: please expand binary packages in Built-Using to source and version

[Nicolas Boulenguez]

Package: dpkg-dev
Followup-For: Bug #990073
Control: tags -1 + patch

Here is a proof of concept passing the following tests.
gcc   -> gcc-defaults (= .*)
bla (= 1), gcc, foo (= 2) -> bla (= 1), foo (= 2), gcc-defaults 
(= .*)
bla (= 1), gcc, g++, foo (= 2)-> bla (= 1), foo (= 2), gcc-defaults 
(= .*)
bla (= 1), foo (= 2) [arm64], g++ [arm64] -> bla (= 1)
bla, gcc, g++, foo (= 2)  -> error message with 'bla gcc g++'

--- a/man/dpkg-gencontrol.pod
+++ b/man/dpkg-gencontrol.pod
@@ -58,6 +58,10 @@ B
 also adds an entry for the binary package to
 B.
 
+Each unversioned dependency in the B field is assumed to
+be installed on the system (usually, via B), and
+replaced with the matching source package and version.
+
 =head1 OPTIONS
 
 =over
--- a/scripts/dpkg-gencontrol.pl
+++ b/scripts/dpkg-gencontrol.pl
@@ -293,6 +293,13 @@ foreach my $field (field_list_pkg_dep()) {
  reduce_profiles => 1, union => 1);
 error(g_("parsing package '%s' %s field: %s"), $oppackage,
   $field, $field_value) unless defined $dep;
+if ($field eq 'Built-Using'
+and (my @changed = grep { not defined $_->{'version'} } 
$dep->get_deps())) {
+my $debs = join(' ', map { $_->{'package'} } @changed);
+my @lines = `dpkg-query -Wf '\${source:Package} (= 
\${source:Version})\\n' $debs`;
+error(g_('failed to expand Built-Using: %s'), $debs) if $?;
+$_->parse_string(shift @lines) for (@changed);
+}
$dep->simplify_deps($facts);
 $dep->sort();
}

Bug#990089: linux-image-4.19.0-17-amd64: lxc-attach fails with Failed to set AppArmor label unconfined

[Mark Grant]

Package: src:linux
Version: 4.19.194-1
Severity: normal

Dear Maintainer,

After upgrading from linux-image-4.19.0-16-amd64 to linux-image-4.19.0-17-amd64
attaching an unprivileged linux container fails with the message:
lxc-attach: debian-buster-amd64-basic: lsm/lsm.c: lsm_process_label_set_at: 174
Operation not permitted - Failed to set AppArmor label "unconfined"
Rebooting into linux-image-4.19.0-16-amd64 with no other changes, the lxc
system works as expected.

Regrads,
Mark Grant



-- Package-specific info:
** Version:
Linux version 4.19.0-17-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.194-1 (2021-06-10)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-17-amd64 root=/dev/mapper/priam--vg-root ro

** Not tainted

** Kernel log:
[   14.211487] snd_hda_codec_realtek hdaudioC0D0:  Rear Mic=0x18
[   14.211554] snd_hda_codec_realtek hdaudioC0D0:  Line=0x1a
[   14.351839] input: HDA Intel PCH Front Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input10
[   14.351896] input: HDA Intel PCH Rear Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input11
[   14.351941] input: HDA Intel PCH Line as 
/devices/pci:00/:00:1f.3/sound/card0/input12
[   14.351981] input: HDA Intel PCH Line Out as 
/devices/pci:00/:00:1f.3/sound/card0/input13
[   14.352023] input: HDA Intel PCH Front Headphone as 
/devices/pci:00/:00:1f.3/sound/card0/input14
[   14.352071] input: HDA Intel PCH HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/sound/card0/input15
[   14.352116] input: HDA Intel PCH HDMI/DP,pcm=7 as 
/devices/pci:00/:00:1f.3/sound/card0/input16
[   14.352164] input: HDA Intel PCH HDMI/DP,pcm=8 as 
/devices/pci:00/:00:1f.3/sound/card0/input17
[   14.352214] input: HDA Intel PCH HDMI/DP,pcm=9 as 
/devices/pci:00/:00:1f.3/sound/card0/input18
[   14.352257] input: HDA Intel PCH HDMI/DP,pcm=10 as 
/devices/pci:00/:00:1f.3/sound/card0/input19
[   14.562406] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: 
errors=remount-ro
[   14.743100] EXT4-fs (sda1): mounting ext2 file system using the ext4 
subsystem
[   14.815334] EXT4-fs (sda1): mounted filesystem without journal. Opts: (null)
[   15.862180] audit: type=1400 audit(1624175633.583:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=651 
comm="apparmor_parser"
[   15.864947] audit: type=1400 audit(1624175633.583:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=651 comm="apparmor_parser"
[   15.876271] audit: type=1400 audit(1624175633.595:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=650 
comm="apparmor_parser"
[   15.879040] audit: type=1400 audit(1624175633.595:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=650 
comm="apparmor_parser"
[   15.881633] audit: type=1400 audit(1624175633.595:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=650 
comm="apparmor_parser"
[   15.916140] audit: type=1400 audit(1624175633.635:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/lxc-start" pid=654 
comm="apparmor_parser"
[   15.920983] audit: type=1400 audit(1624175633.639:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="virt-aa-helper" pid=649 
comm="apparmor_parser"
[   15.972116] audit: type=1400 audit(1624175633.691:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lxc-container-default" 
pid=659 comm="apparmor_parser"
[   15.975071] audit: type=1400 audit(1624175633.691:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lxc-container-default-cgns" 
pid=659 comm="apparmor_parser"
[   15.977826] audit: type=1400 audit(1624175633.691:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="lxc-container-default-with-mounting" pid=659 comm="apparmor_parser"
[   16.845248] usb 1-8: reset high-speed USB device number 3 using xhci_hcd
[   17.604508] new mount options do not match the existing superblock, will be 
ignored
[   17.807334] fuse init (API version 7.27)
[   22.361782] bridge: filtering via arp/ip/ip6tables is no longer available by 
default. Update your scripts to load br_netfilter if you need this.
[   22.363742] br0: port 1(enp6s0) entered blocking state
[   22.364289] br0: port 1(enp6s0) entered disabled state
[   22.364876] device enp6s0 entered promiscuous mode
[   22.438716] r8169 :06:00.0: firmware: direct-loading firmware 
rtl_nic/rtl8168h-2.fw
[   22.441377] Generic PHY r8169-600:00: attached PHY driver [Generic PHY] 
(mii_bus:phy_addr=r8169-600:00, irq=IGNORE)
[   22.555996] r8169 :06:00.0 enp6s0: Link is Down
[   22.563788] br0: port 1(enp6s0) entered blocking state
[   22.566219] br0: port 1(enp6s0) entered forwarding state
[   22.568706] IPv6: ADDRCONF(NETDEV_UP): br0: 

Bug#989943: maybe use at instead of shutdown -r $TIME

[Tomas Pospisek]

Argh, that should of course be:

--- /usr/bin/unattended-upgrade.orig2021-06-18 09:46:37.434386824 +0200
+++ /usr/bin/unattended-upgrade 2021-06-18 09:47:03.958639111 +0200
@@ -1353,11 +1353,12 @@
when = apt_pkg.config.find(
"Unattended-Upgrade::Automatic-Reboot-Time", "now")
logging.warning("Found %s, rebooting" % REBOOT_REQUIRED_FILE)
-cmd = ["/sbin/shutdown", "-r", when]
+cmd = ["/usr/bin/at", when]
try:
-shutdown_msg = subprocess.check_output(cmd, stderr=subprocess.STDOUT)
-if shutdown_msg.strip():
-logging.warning("Shutdown msg: %s", shutdown_msg.strip())
+p = subprocess.Popen(cmd, stdin=subprocess.PIPE, 
stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
+p_out = p.communicate(input=b'shutdown -r 
now\n')[0].decode('utf-8').strip()
+if p_out:
+logging.warning("Shutdown msg: %s", p_out)
except Exception as e:
logging.error("Failed to issue shutdown: %s", e)

(s/shutdown -h/shutdown -r/)

As always: feedback appreciated

Thanks & greetings,
*t

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Olaf van der Spek]

So I think it's not accepting new connections from the start of the
upgrade run until the end:
Setting up openssh-sftp-server (1:8.4p1-5) ...
Setting up console-setup (1.203) ...
Setting up mime-support (3.66) ...
Setting up openssh-server (1:8.4p1-5) ...
Installing new version of config file /etc/init.d/ssh ...
Installing new version of config file /etc/ssh/moduli ...
Replacing config file /etc/ssh/sshd_config with new version
rescue-ssh.target is a disabled or a static unit, not starting it.

Bug#989799: psmisc: Undeclared file conflict with manpages-de from buster-backports

[Helge Kreutzmann]

Hello all,
I locally build the backport for 4.10.0. I created a buster chroot,
installed manpages-de, manpages-fr and manpages-pl from backports and
did a dist-ugprade to current testing.

If I do this without the fix, the upgrade fails (as now expected),
however, a "apt-get -f install" seems to fix it.

On Mon, Jun 14, 2021 at 12:19:17PM +0200, Axel Beckert wrote:
> Craig Small wrote:
> > reassign -1 manpages-de
> 
> Might be the right place indeed, but maybe not in the way you'd
> expect. See below.
> 2) So I wonder if the buster-backports package of manpages-de could
>conflict with the psmisc and procps package in bullseye(*)? This
>should probably take care that it is upgraded before procps and
>psmisc are upgraded and hopefully solves the issue without too many
>side-effects.
> 
>(I'm not sure if Breaks/Replaces with ">>" or ">=" really work as
>expected. I've never seen that in use anywhere before. Taking
>Guillem into Cc so maybe he can tell something about if Conflicts
>or Breaks/Replaces are the better choice here.)
> 
>I only see these hopefully only minor disadvantages of that latter
>solution:
> 
>* Users need to have uptodate buster-backports package, i.e.
>  4.9.3-4~bpo10+2. If they don't upgrade to 4.9.3-4~bpo10+2 before
>  dist-upgrading and then upgrade with 4.9.3-4~bpo10+1 still being
>  installed, they will run into this issue again. Might be
>  something for the Release Notes.
> 
>* I'm not sure if apt gets confused while trying to find a good
>  order for dist-upgrading if the Conflicts/Breaks/Replaces is in
>  the old package and not the to-be-upgraded-to one. I hopefully
>  think that this is no issue, but I'm Cc'ing the APT team for
>  input on that to be on the safe side.

If I add the Conflicts as suggested and necessary, the same procedure
suceeds, i.e. the update happens as expected and all intended packages
(procps, psmics and the manpages-de, manpages-fr and manpages-pl) are
present in their version as of testing.

I'm now preparing the official upload to backports.

Greetings

Helge

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#990088: lld: please provide lld-link symlink

[Junichi Uekawa]

Package: lld
Version: 1:11.0-51+nmu5
Severity: wishlist

Dear Maintainer,

Seems like lld-11 package provides /usr/bin/lld-link-11 symlink, and
some documentation refers to lld-link. Please provide a lld-link
symlink.

[1] https://github.com/uchan-nos/mikanos-build/blob/master/day01/c/Makefile#L7

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

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

Versions of packages lld depends on:
ii  lld-11  1:11.0.1-2

lld recommends no packages.

lld suggests no packages.

-- no debconf information

Bug#681893: debconf should create /var/cache/debconf if it doesn't exist

[Marco d'Itri]

On Jul 17, Thiago Jung Bauermann  wrote:

> debconf should silently create the /var/cache/debconf directory instead
I do not believe that this is true, and it is definitely not generally 
true because not all programs accessing /var/cache/$something/ do that 
with root privileges.
So, while it is expected that files may disappear at any time from 
/var/cache/ the structure of subdirectories should be preserved.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#990069: openssh-server: Not accepting new connections during Debian 10 -> 11 upgrade

[Olaf van der Spek]

Op za 19 jun. 2021 om 13:13 schreef Colin Watson :
>
> On Sat, Jun 19, 2021 at 12:53:48PM +0200, Olaf van der Spek wrote:
> > During a Debian 10 -> 11 upgrade, the SSH server doesn't appear to be 
> > accepting new connections. IMO this is less than optimal, and not sure if 
> > this was always the case.
> > Would it be possible to keep accepting connections, or at least to make the 
> > time window in which SSH is down as short as possible?

FYI, this is when it's waiting for a reply to this question:
Configuring libc6:amd64
 | There are services installed on your system which need to be
restarted when certain libraries, such as libpam, libc, and libssl,
are upgraded. Since these restarts may cause interruptions   |
 | of service for the system, you will normally be prompted on each
upgrade for the list of services you wish to restart.  You can choose
this option to avoid being prompted; instead, all  |
 | necessary restarts will be done for you automatically so you can
avoid being asked questions on each library upgrade.
  |
 |

   |
 | Restart services during package upgrades without asking?

$ ssh localhost
kex_exchange_identification: read: Connection reset by peer
Connection reset by ::1 port 22

/var/log/auth:
Jun 20 10:00:43 alpha sshd[10140]: fatal: recv_rexec_state: buffer
error: incomplete message



> That's odd, because we already take care to do that.  Any chance of some
> logs?  I think the most useful things would be /var/log/dpkg.log,

2021-05-09 10:03:01 status installed systemd:amd64 241-7~deb10u7
2021-06-20 09:40:28 startup archives unpack
2021-06-20 09:40:28 upgrade base-files:amd64 10.3+deb10u9 10.3+deb10u10
2021-06-20 09:40:28 status half-configured base-files:amd64 10.3+deb10u9
2021-06-20 09:40:28 status unpacked base-files:amd64 10.3+deb10u9
2021-06-20 09:40:28 status half-installed base-files:amd64 10.3+deb10u9
2021-06-20 09:40:28 status triggers-pending man-db:amd64 2.8.5-2
2021-06-20 09:40:28 status unpacked base-files:amd64 10.3+deb10u10
2021-06-20 09:40:28 startup packages configure
2021-06-20 09:40:28 configure base-files:amd64 10.3+deb10u10 
2021-06-20 09:40:28 status unpacked base-files:amd64 10.3+deb10u10
2021-06-20 09:40:28 status half-configured base-files:amd64 10.3+deb10u10
2021-06-20 09:40:28 status installed base-files:amd64 10.3+deb10u10
2021-06-20 09:40:28 startup archives unpack
2021-06-20 09:40:28 upgrade libgcrypt20:amd64 1.8.4-5 1.8.4-5+deb10u1
2021-06-20 09:40:28 status triggers-pending libc-bin:amd64 2.28-10
2021-06-20 09:40:28 status half-configured libgcrypt20:amd64 1.8.4-5
2021-06-20 09:40:28 status unpacked libgcrypt20:amd64 1.8.4-5
2021-06-20 09:40:28 status half-installed libgcrypt20:amd64 1.8.4-5
2021-06-20 09:40:28 status unpacked libgcrypt20:amd64 1.8.4-5+deb10u1
2021-06-20 09:40:28 startup packages configure
2021-06-20 09:40:28 configure libgcrypt20:amd64 1.8.4-5+deb10u1 
2021-06-20 09:40:28 status unpacked libgcrypt20:amd64 1.8.4-5+deb10u1
2021-06-20 09:40:28 status half-configured libgcrypt20:amd64 1.8.4-5+deb10u1
2021-06-20 09:40:28 status installed libgcrypt20:amd64 1.8.4-5+deb10u1
2021-06-20 09:40:28 startup archives unpack
2021-06-20 09:40:28 upgrade libnettle6:amd64 3.4.1-1 3.4.1-1+deb10u1
2021-06-20 09:40:28 status half-configured libnettle6:amd64 3.4.1-1
2021-06-20 09:40:28 status unpacked libnettle6:amd64 3.4.1-1
2021-06-20 09:40:28 status half-installed libnettle6:amd64 3.4.1-1
2021-06-20 09:40:28 status unpacked libnettle6:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 startup packages configure
2021-06-20 09:40:28 configure libnettle6:amd64 3.4.1-1+deb10u1 
2021-06-20 09:40:28 status unpacked libnettle6:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 status half-configured libnettle6:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 status installed libnettle6:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 startup archives unpack
2021-06-20 09:40:28 upgrade libhogweed4:amd64 3.4.1-1 3.4.1-1+deb10u1
2021-06-20 09:40:28 status half-configured libhogweed4:amd64 3.4.1-1
2021-06-20 09:40:28 status unpacked libhogweed4:amd64 3.4.1-1
2021-06-20 09:40:28 status half-installed libhogweed4:amd64 3.4.1-1
2021-06-20 09:40:28 status unpacked libhogweed4:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 startup packages configure
2021-06-20 09:40:28 configure libhogweed4:amd64 3.4.1-1+deb10u1 
2021-06-20 09:40:28 status unpacked libhogweed4:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 status half-configured libhogweed4:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 status installed libhogweed4:amd64 3.4.1-1+deb10u1
2021-06-20 09:40:28 startup archives unpack
2021-06-20 09:40:29 upgrade libgnutls30:amd64 3.6.7-4+deb10u6 3.6.7-4+deb10u7
2021-06-20 09:40:29 status half-configured libgnutls30:amd64 3.6.7-4+deb10u6
2021-06-20 09:40:29 status unpacked libgnutls30:amd64 3.6.7-4+deb10u6
2021-06-20 09:40:29 status half-installed libgnutls30:amd64 3.6.7-4+deb10u6
2021-06-20 09:40:29 status 

Bug#990086: apt-key is deprecated in bullseye, how to manage keys instead

[Julian Andres Klode]

On Sun, Jun 20, 2021 at 10:20:42AM +0300, Andrei POPESCU wrote:
> Package: release-notes
> X-Debbugs-Cc: debian-u...@lists.debian.org, a...@packages.debian.org
> 
> On Sb, 19 iun 21, 22:07:35, Marco Möller wrote:
> > 
> > Command apt-key and its man page say that apt-key is deprecated, but do not
> > suggest an instead recommended tool. It is only mentioned that keys would
> > now be organized in /etc/apt/trusted.gpg.d/  . But how should I manage the
> > keys saved there, for instance how to update them, or what tool of the
> > Debian distribution is managing them there for the apt functionality of the
> > Debian OS?
> 
> As far as I understand it's as simple as dropping the keys in there. 
> 
> When a key changes/expires/etc. replace it with the new one (if provided 
> by the respective repository).
> 
> > Guiding me to a properly up-to-date documentation about this topic would be
> > welcome!
> 
> Indeed the documentation on this is a bit scarce, probably worth a 
> mention in the Release Notes.
> 
> Dear APT maintainers,
> 
> The short version appears to be this note to the 'add' command from 
> apt-key(8):
> 
> Note: Instead of using this command a keyring should be placed 
> directly in the /etc/apt/trusted.gpg.d/ directory with a descriptive 
> name and either "gpg" or "asc" as file extension.
> 
> where .gpg files are of type created with 'gpg --export' and .asc with
> 'gpg --armor --export'.
> 
> 
> Your confirmation (or even better, proposes wording) would be much 
> appreciated.

I suggested wording for it in Bug#980743: release-notes: bullseye is
the final release to ship apt-key - that I opened back in January,
and it was added in April. So this is a duplicate.

I'll leave the bug state to you, it ain't my package, and you might
want to add a second note, I don't know.

The long version is below.

# The direct translation
If you currently have:
“wget -qO- https://myrepo.example/myrepo.asc | sudo apt-key add –“

To translate this directly for buster (bionic) and newer, you can use:

“wget -qO /etc/apt/trusted.gpg.d/myrepo.asc https://myrepo.example/myrepo.asc“

Older (and all) releases only support unarmored files with an extension .gpg. 
If you care about them, provide one, and use

“wget -qO /etc/apt/trusted.gpg.d/myrepo.gpg https://myrepo.example/myrepo.gpg“

Some people will tell you to download the .asc and pipe it to gpg --dearmor, 
but gpg might not be installed, so really, just offer a .gpg one instead that 
is supported on all systems.

# Pretending to be safer by using signed-by

People say it's good practice to not use trusted.gpg.d and install the file 
elsewhere and then refer to it from the sources.list entry
by using signed-by=. So this looks a lot safer, because now 
your key can't sign other unrelated repositories. In
practice, security increase is minimal, since package maintainer scripts run as 
root anyway. But I guess it's better for publicity :)

As an example, here are the instructions to install signal-desktop from 
signal.org. As mentioned, gpg --dearmor use in there is not a good idea,
and I'd personally not tell people to modify /usr as it's supposed to be 
managed by the package manager, but we don't have an /etc/apt/keyrings
or similar at the moment; it's fine though if the keyring is installed by the 
package.

# NOTE: These instructions only work for 64 bit Debian-based
# Linux distributions such as Ubuntu, Mint etc.

# 1. Install our official public software signing key
wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg 
--dearmor > signal-desktop-keyring.gpg
cat signal-desktop-keyring.gpg | sudo tee -a 
/usr/share/keyrings/signal-desktop-keyring.gpg > /dev/null

# 2. Add our repository to your list of repositories
echo 'deb [arch=amd64 
signed-by=/usr/share/keyrings/signal-desktop-keyring.gpg] 
https://updates.signal.org/desktop/apt xenial main' |\
  sudo tee -a /etc/apt/sources.list.d/signal-xenial.list

# 3. Update your package database and install signal
sudo apt update && sudo apt install signal-desktop

I do wonder why they do wget | gpg --dearmor, pipe that into the file and then 
cat | sudo tee it, instead of having that all in one pipeline. Maybe they want 
nicer progress reporting.

# Summary

We have three scenarios:

For system image building, shipping the key in /etc/apt/trusted.gpg.d seems 
reasonable to me; you are the vendor sort of, so it can be globally trusted.

Chrome-style debs and repository config debs: If you ship a deb, embedding the 
sources.list.d snippet (calling it $myrepo.list) and shipping a $myrepo.gpg in 
/usr/share/keyrings is the best approach. Whether you ship that in product debs 
aka vscode/chromium or provide a repository configuration deb (let's call it 
myrepo-repo.deb) and then tell people to run apt update followed by apt install 
 depends on how many packages are in the repo, I guess.

Manual instructions (signal 

Bug#990087: kwin-wayland: Context menu does not appear in applications when no image selected as background on Plasma Wayland

[Silvério Santos]

Package: kwin-wayland
Version: 4:5.20.5-1
Severity: important

Dear Maintainer,

To recreate the problem:
Configure a unicolor background for the Plasma Wayland background.
Open an application, e.g. KMyMoney, right-click for a context menu, but it is
invisible.

The context menu appears in the same application, when:
- either running KDE with XWindow,
- or with Wayland, but with an image as the background,
- or with Wayland, first configure an image, then switch back to unicolor.

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

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

Versions of packages kwin-wayland depends on:
ii  kwayland-integration  5.20.5-1
ii  kwin-common   4:5.20.5-1
ii  kwin-wayland-backend-drm  4:5.20.5-1
ii  kwin-wayland-backend-wayland  4:5.20.5-1
ii  kwin-wayland-backend-x11  4:5.20.5-1
ii  libc6 2.31-12
ii  libcap2   1:2.44-1
ii  libcap2-bin   1:2.44-1
ii  libepoxy0 1.5.5-1
ii  libfontconfig12.13.1-4.2
ii  libfreetype6  2.10.4+dfsg-1
ii  libkf5coreaddons5 5.78.0-4
ii  libkf5crash5  5.78.0-3
ii  libkf5i18n5   5.78.0-2
ii  libkf5idletime5   5.78.0-2
ii  libkf5notifications5  5.78.0-2
ii  libkf5quickaddons55.78.0-2
ii  libkf5waylandclient5  4:5.78.0-2
ii  libkf5windowsystem5   5.78.0-2
ii  libkwaylandserver5 [libkwaylandserver5-5.20]  5.20.5-1
ii  libkwineffects12a 4:5.20.5-1
ii  libkwinglutils12  4:5.20.5-1
ii  libpipewire-0.3-0 0.3.19-4
ii  libqt5core5a [qtbase-abi-5-15-2]  5.15.2+dfsg-7
ii  libqt5dbus5   5.15.2+dfsg-7
ii  libqt5gui55.15.2+dfsg-7
ii  libqt5widgets55.15.2+dfsg-7
ii  libstdc++610.2.1-6
ii  libxcb-xfixes01.14-3
ii  libxcb1   1.14-3
ii  xwayland  2:1.20.11-1

kwin-wayland recommends no packages.

kwin-wayland suggests no packages.

Bug#990086: apt-key is deprecated in bullseye, how to manage keys instead

[Andrei POPESCU]

Package: release-notes
X-Debbugs-Cc: debian-u...@lists.debian.org, a...@packages.debian.org

On Sb, 19 iun 21, 22:07:35, Marco Möller wrote:
> 
> Command apt-key and its man page say that apt-key is deprecated, but do not
> suggest an instead recommended tool. It is only mentioned that keys would
> now be organized in /etc/apt/trusted.gpg.d/  . But how should I manage the
> keys saved there, for instance how to update them, or what tool of the
> Debian distribution is managing them there for the apt functionality of the
> Debian OS?

As far as I understand it's as simple as dropping the keys in there. 

When a key changes/expires/etc. replace it with the new one (if provided 
by the respective repository).

> Guiding me to a properly up-to-date documentation about this topic would be
> welcome!

Indeed the documentation on this is a bit scarce, probably worth a 
mention in the Release Notes.

Dear APT maintainers,

The short version appears to be this note to the 'add' command from 
apt-key(8):

Note: Instead of using this command a keyring should be placed 
directly in the /etc/apt/trusted.gpg.d/ directory with a descriptive 
name and either "gpg" or "asc" as file extension.

where .gpg files are of type created with 'gpg --export' and .asc with
'gpg --armor --export'.


Your confirmation (or even better, proposes wording) would be much 
appreciated.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#989644: iwd: After upgrading to 1.14-3, can no longer connect to access point

[Jonas Smedegaard]

control: tag -1 +upstream

Hi Alejandro and Timur,

Thanksd for your bug reporting.

IWD has seen only upstream changes since release 1.9 (packaging changes 
since then has only affected metadata and testsuite).

I have now released 1.15-1 to experimental.  Upstream changes between 
1.14 and 1.15 mentions no bugfixes, only feature improvements, but 
perhaps some of that anyway improves behavior on your MacBooks.

Please tell if 1.15-1 works for you or not.  And if it doesn't then also 
please consider reporting the issue upstream.  Better if you report it 
yourself, since you have the hardware needed to test things so I expect 
that me acting as proxy would only slow down the process for no benefit.

Upstream contact info is here (at the bottom): 
https://iwd.wiki.kernel.org/

If you do report the issue upstream, then please share a link to the 
upstream issue report here.


Kind regards,

 - Jonas

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

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

signature.asc
Description: signature

Bug#990085: ITP: django-rq -- Django integration with RQ (Redis Queue)

[Carsten Schoenert]

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

* Package name: django-rq
  Version : 2.4.1
  Upstream Author : Selwin Ong 
* URL : https://github.com/rq/django-rq
* License : MIT
  Programming Lang: Python
  Description : Django integration with RQ (Redis Queue)

 Django-RQ is a simple app that allows you to configure your queues in django's
 settings.py and easily use them in your project.

This package is a (build) dependency for netbox I consider to package.

The package will get maintained within the Debian Python Team.

Bug#974581: np longer able to set native resolution of Dell U3014

[Janusz S. Bień]

On Sat, Jun 19 2021 at 16:56 +01, Simon Iremonger (debian) wrote:
> Dear Janusz
>
> linux-image-amd64 linux-headers-amd64 have now come out in version
> 5.10.0-0.bpo.7 in buster-backports.
>
> Please confirm the issue is solved for you (or not) by using that
> kernel as above, so the bug report can be prgressed or closed.

Unfortunately there is no improvement.

Only the console output is displayed on the external monitor.

Actually I stopped using the laptop, during a quick test there was no
flickering, but it appeared usually after some time.

The monitor is OK because Windows uses it with no problem at the native
resolution.

Please note the problem seems specific to a particular model of laptop,
during a quick test with a desktop the problem doesn't occur even with
the default kernel.

Best regards

Janusz


-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#990083: kodi: Kodi hangs on transitions between playlist items with spinning wheel and no control

[Fabrice Quenneville]

Hi Vasyl / maintainers

I just got other errors from that NAS so I am starting to run diagnostics
but it will take awhile to troubleshoot and it is quite late here. But
everything is pointing to my NAS partially failing at the same time as I
updated Kodi. I will update as soon as I can / have definitive information.

Thanks

On Sun, Jun 20, 2021 at 1:31 AM Vasyl Gello  wrote:

> Hi Fabrice!
>
> Does the file '/mnt/media/TV Shows (en)/Seinfeld (1989)/Season
> 3/Seinfeld.S03E19.The.Limo.720p.WEBrip.AAC.EN-SUB.x264-[MULVAcoded].mkv'
> play for you correctly every time you start it not via playlist?
>
> From the logs I see that VAAPI on Intel integrated video (I suppose it is
> an integrated video) starts spewing 'COutput:StateMachine' errors.
>
> I am going to forward the bug to upstream and ask FernetMenta or ksooo
> about that StateMachine state. In my experience, these errors originate
> either from buffer jitter or from improperly-encoded mediafile.
> --
> Vasyl Gello
> --
>


-- 
*Fabrice Quenneville*