Bug#973715: RE: Bug#973715: fwupd-amd64-signed holding off fwupd update results in segfaulting binary

[Limonciello, Mario]

Paul,

I don't have the power to manually run it. So there is nothing I can do. With 
the new 1.5.6-1 upload someone will need to manually run it again.

Get Outlook for Android


From: Paul Gevers 
Sent: Thursday, February 18, 2021, 00:09
To: 973...@bugs.debian.org
Subject: Bug#973715: RE: Bug#973715: fwupd-amd64-signed holding off fwupd 
update results in segfaulting binary

Hi Mario,

LOn Mon, 16 Nov 2020 16:01:34 + "Limonciello, Mario"
 wrote:
> As @Steve McIntyre mentions, it's a manual process to kick off the re-signing.
> It needs to be done when 1.5.1-2 is ready to migrate.

There's users of unstable too. In my opinion, if you can't relax the
constraints, you'll have to kick it off as soon as it's needed in
unstable, not when it's ready to migrate.

Paul

Bug#958647: Issue is known and intentional in util-linux

[Roland Clobus]

retitle 958647 live-build: becoming root requires 'su -'
tags 958647 wontfix confirmed
thanks

Hello farrier,

This is neither a bug in live-build, nor in util-linux, it has become
the intended behaviour of 'su'.

The documentation for util-linux 2.32-0.4 [1] explains that 'su -' is
the recommended way to become root since 2018-08-03.

With kind regards,
Roland Clobus

[1] /usr/share/doc/util-linux/NEWS.Debian.gz





OpenPGP_signature
Description: OpenPGP digital signature

Bug#932989: gcc-avr: which MCUs are not supported by upstream gcc?

[Hakan Ardo]

OK, so upstream does indeed currently seem to be ahead. That has not always
been the case historically. I'm fine with switching if anyone steps up to
do the work. I've put the packages up for adoption, but I'll be happy to
give some support...

On Thu, Feb 11, 2021 at 10:57 AM Benjamin Valentin <
benjamin.valen...@beuth-hochschule.de> wrote:

> Just comparing the output of avr-gcc --target-help gives
>
> --- gcc-5.4.txt 2021-02-11 09:56:37.490084599 +0100
> +++ gcc-10.2.txt2021-02-11 09:56:30.918162094 +0100
> @@ -160,9 +160,14 @@
>  attiny13
>  attiny13a
>  attiny15
> +attiny1614
> +attiny1616
> +attiny1617
>  attiny1634
>  attiny167
>  attiny20
> +attiny212
> +attiny214
>  attiny22
>  attiny2313
>  attiny2313a
> @@ -173,8 +178,13 @@
>  attiny261
>  attiny261a
>  attiny28
> +attiny3214
> +attiny3216
> +attiny3217
>  attiny4
>  attiny40
> +attiny412
> +attiny414
>  attiny416
>  attiny417
>  attiny4313
> @@ -186,6 +196,7 @@
>  attiny461a
>  attiny48
>  attiny5
> +attiny814
>  attiny816
>  attiny817
>  attiny828
>
> So gcc10 actually knows about some more parts.
> I don't know if there are any missing patches upstream though.
> Arch seems to carry the latest upstream gcc for AVR with no complaints
> though.
>


-- 
Håkan Ardö

Bug#983012: plasma-desktop: installing plasma-desktop does not pull kmix

[Norbert Preining]

Hi Johannes,

> #981597. After reinstalling plasma-desktop, I had not sound applet in my
> task bar, and kmix was not installed.

Hmmm, I don't have kmix installed either ... but I do have a sound
applet in my systray.

> Please add a dependency on kmix to plasma-desktop or to one of the
> packages it depends on, if this is more suitable.

kmix doesn't help here, it must be something else that is missing, since
I don't have kmix and I have a sound applet ;-)

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research Labs  +  IFMGA Guide + TU Wien + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#981597: plasma-desktop: Same problem on a system set up with stretch

[Norbert Preining]

Hi Johannes,

> system, but running buster. I can confirm that I had to completely
> remove all kde related packages including plasma-desktop to be able to

Did you do dist-upgrade? I simple upgrade might not find a proper
solution because several packages need to be removed.

It is really hard to debug this, and in general it seems to be an apt
problem not being able to find a solution, while there definitely is
one, as you have shown yourself by installing it afterwards ;-)

So, without more debugging - and that is not possible since you have
already upgraded your system, it is really hard to say why all this
happened.

Best

Norbert


--
PREINING Norbert  https://www.preining.info
Fujitsu Research Labs  +  IFMGA Guide + TU Wien + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#983017: 9base: flaky autopkgtest on i386: stack smashing detected

[Paul Gevers]

Source: 9base
Version: 1:6-10
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

shoogle has an autopkgtest, great. However, on i386 it fails more often
than it passes [1].

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

On top of that stack smashing seems a serious issue on it's own.

I copied the output at the bottom of this report. Can you please look
into it and make the test more robust (against network issues). If you
keep the test that requires internet, you should add the needs-internet
restriction too.

Paul

[1] https://ci.debian.net/packages/9/9base/testing/i386/

https://ci.debian.net/data/autopkgtest/testing/i386/9/9base/10243149/log.gz

autopkgtest [18:26:16]: test command14: RP=/usr/lib/plan9/bin;
$RP/fortune debian/tests/lorem.txt | $RP/sha1sum
autopkgtest [18:26:16]: test command14: [---
*** stack smashing detected ***: terminated
bash: line 1:  3091 Done$RP/fortune
debian/tests/lorem.txt
  3092 Aborted | $RP/sha1sum
autopkgtest [18:26:16]: test command14: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983015: breezy FTFBS with nocheck profile: Missing Build-Depends: python3-setuptools

[Helmut Grohne]

Source: breezy
Version: 3.1.0-8
Severity: important
Tags: ftfbs patch

breezy fails to build from source when enabling the nocheck profile,
because the setuptools module cannot be found. Please consider applying
the attached patch to add it to Build-Depends.

Helmut
diff --minimal -Nru breezy-3.1.0/debian/changelog breezy-3.1.0/debian/changelog
--- breezy-3.1.0/debian/changelog   2020-12-06 16:06:43.0 +0100
+++ breezy-3.1.0/debian/changelog   2021-02-17 22:23:49.0 +0100
@@ -1,3 +1,10 @@
+breezy (3.1.0-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing python3-setuptools to Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 17 Feb 2021 22:23:49 +0100
+
 breezy (3.1.0-8) unstable; urgency=medium
 
   * Add patch 21_extssh: add support for extssh URLs.
diff --minimal -Nru breezy-3.1.0/debian/control breezy-3.1.0/debian/control
--- breezy-3.1.0/debian/control 2020-12-06 16:06:43.0 +0100
+++ breezy-3.1.0/debian/control 2021-02-17 22:23:47.0 +0100
@@ -20,6 +20,7 @@
python3-launchpadlib,
python3-paramiko,
python3-patiencediff,
+   python3-setuptools,
python3-six,
python3-sphinx (>= 1.0.7+dfsg),
python3-subunit ,

Bug#983016: botan: move sphinx dependency to B-D-I

[Helmut Grohne]

Source: botan
Version: 2.17.3+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

botan cannot be cross built from source, because its python3-sphinx
dependency is not satisfiable. It turns out that it is only needed for
building the -doc package, so it should be movable to B-D-I. When doing
so, the build fails finding rst2man. That script comes with
python3-docutils, which is part of python3-sphinx' dependency tree. When
moving it, the python3-docutils dependency must be added. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru botan-2.17.3+dfsg/debian/changelog 
botan-2.17.3+dfsg/debian/changelog
--- botan-2.17.3+dfsg/debian/changelog  2020-12-22 07:15:56.0 +0100
+++ botan-2.17.3+dfsg/debian/changelog  2021-02-17 14:29:22.0 +0100
@@ -1,3 +1,13 @@
+botan (2.17.3+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Move python3-sphinx to B-D-I.
++ Explicitly B-D: python3-docutils for rst2man no longer implied by
+  python3-sphinx.
+
+ -- Helmut Grohne   Wed, 17 Feb 2021 14:29:22 +0100
+
 botan (2.17.3+dfsg-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru botan-2.17.3+dfsg/debian/control 
botan-2.17.3+dfsg/debian/control
--- botan-2.17.3+dfsg/debian/control2020-11-05 17:57:32.0 +0100
+++ botan-2.17.3+dfsg/debian/control2021-02-17 14:29:22.0 +0100
@@ -5,14 +5,16 @@
 Build-Depends:
  debhelper-compat (= 12),
  dh-python,
- python3-sphinx,
  libbz2-dev,
  liblzma-dev,
  libssl-dev,
  libsqlite3-dev,
  libtspi-dev,
  zlib1g-dev,
- python3-all-dev
+ python3-all-dev,
+ python3-docutils,
+Build-Depends-Indep:
+ python3-sphinx,
 Standards-Version: 4.5.0
 Homepage: https://botan.randombit.net/
 

Bug#983014: manpages-de: Fails to upgrade from 4.2.0-1 to 4.9.1-5: This installation run will require temporarily removing the essential package manpages-de:amd64 due to a Conflicts/Pre-Depends loop.

[Axel Beckert]

Package: manpages-de
Version: 4.9.1-5
Severity: serious

On several of my systems, manpages-de fails to upgrade from 4.2.0-1 to
4.9.1-5 as follows:

Get:1 https://debian.ethz.ch/debian sid/main amd64 manpages-de all 4.9.1-5 
[2750 kB]
Fetched 2750 kB in 0s (12.8 MB/s)
E: This installation run will require temporarily removing the essential 
package manpages-de:amd64 due to a Conflicts/Pre-Depends loop. This is often 
bad, but if you really want to do it, activate the APT::Force-LoopBreak option.
E: Internal Error, Could not early remove manpages-de:amd64 (2)

I though have no idea why apt regards manpages-de as
essential. X-Debbugs-Cc'ing the APT developers at
de...@lists.debian.org.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

manpages-de depends on no packages.

manpages-de recommends no packages.

Versions of packages manpages-de suggests:
ii  man-db [man-browser]  2.9.4-1
ii  manpages  5.10-1

-- no debconf information

Bug#983013: m2crypto: autopkgtest needs update for new version of openssl: M2Crypto.RSA.RSAError: sslv3 rollback attack

[Paul Gevers]

Source: m2crypto
Version: 0.37.1-1
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, open...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:openssl

Dear maintainer(s),

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

   passfail
opensslfrom testing1.1.1j-1
m2crypto   from testing0.37.1-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.  I *think*
this may be related to CVE-2020-25657 "bleichenbacher timing attacks in
the RSA decryption API" against m2crypto, hence I file this bug against
m2crypto.

Currently this regression is blocking the migration of openssl to
testing [1]. Of course, openssl shouldn't just break your autopkgtest
(or even worse, your package), but it seems to me that the change in
openssl was intended and your package needs to update to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from openssl should really add
a versioned Breaks on the unfixed version of (one of your) package(s).
Note: the Breaks is nice even if the issue is only in the autopkgtest as
it helps the migration software to figure out the right versions to
combine in the tests.

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/m/m2crypto/10541025/log.gz

=== FAILURES
===
___ RSATestCase.test_public_encrypt


self = 

@unittest.skipIf(m2.OPENSSL_VERSION_NUMBER < 0x1010103f,
 'Relies on fix which happened only in OpenSSL 1.1.1c')
def test_public_encrypt(self):
priv = RSA.load_key(self.privkey)
# pkcs1_padding, pkcs1_oaep_padding
for padding in self.e_padding_ok:
p = getattr(RSA, padding)
ctxt = priv.public_encrypt(self.data, p)
ptxt = priv.private_decrypt(ctxt, p)
self.assertEqual(ptxt, self.data)

# sslv23_padding
ctxt = priv.public_encrypt(self.data, RSA.sslv23_padding)
>   res = priv.private_decrypt(ctxt, RSA.sslv23_padding)

tests/test_rsa.py:129:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 
data =
b'wf\xdc\xa5\xdf\xca\x95\xc7;\xa4\xdfEWUm/\xa1m\xd8\xa1\x14s&\x1bid\xf4c\\\xbcI\x90[<\x8dE\x89\x1f\xbf\xe9y=\xef\xa9z\...2\xb7\xaaO\x89\x88\xf7P\xee\x9f\xaf\x19B?\x1f\n\xe5\x18Q9\x186\x97gj\x0e)0mg@\xed\xe4~\xf3\xc4\xbe\x1dK#\x9f/\r"N%\x8d'
padding = 2

def private_decrypt(self, data, padding):
# type: (bytes, int) -> bytes
assert self.check_key(), 'key is not initialised'
>   return m2.rsa_private_decrypt(self.rsa, data, padding)
E   M2Crypto.RSA.RSAError: sslv3 rollback attack

/usr/lib/python3/dist-packages/M2Crypto/RSA.py:82: RSAError



OpenPGP_signature
Description: OpenPGP digital signature

Bug#981597: plasma-desktop: Same problem on a system set up with stretch

[Johannes Ranke]

Package: plasma-desktop
Version: 4:5.20.5-3
Followup-For: Bug #981597

I was recently upgrading my system originally set up as a stretch
system, but running buster. I can confirm that I had to completely
remove all kde related packages including plasma-desktop to be able to
do the upgrade to bullseye. This was a bit frightening, but after the
upgrade to bullseye, I was able to install plasma-desktop and got back
almost all of the KDE programs I was using.

Thanks for maintaining KDE in Debian!

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

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

Versions of packages plasma-desktop depends on:
ii  accountsservice  0.6.55-3
ii  breeze   4:5.20.5-2
ii  kactivitymanagerd5.20.5-1
ii  kde-cli-tools4:5.20.5-2
ii  kded55.78.0-2
ii  kio  5.78.0-4
ii  kpackagetool55.78.0-3
ii  libaccounts-qt5-11.16-2
ii  libc62.31-9
ii  libcrypt11:4.4.17-1
ii  libglib2.0-0 2.66.7-1
ii  libibus-1.0-51.5.23-2
ii  libkaccounts24:20.12.1-1
ii  libkf5activities55.78.0-2
ii  libkf5activitiesstats1   5.78.0-2
ii  libkf5authcore5  5.78.0-2
ii  libkf5baloo5 5.78.0-2
ii  libkf5codecs55.78.0-2
ii  libkf5completion55.78.0-3
ii  libkf5configcore55.78.0-4
ii  libkf5configgui5 5.78.0-4
ii  libkf5configwidgets5 5.78.0-2
ii  libkf5coreaddons55.78.0-2
ii  libkf5crash5 5.78.0-3
ii  libkf5dbusaddons55.78.0-2
ii  libkf5declarative5   5.78.0-2
ii  libkf5globalaccel-bin5.78.0-2
ii  libkf5globalaccel5   5.78.0-2
ii  libkf5guiaddons5 5.78.0-3
ii  libkf5i18n5  5.78.0-2
ii  libkf5iconthemes55.78.0-2
ii  libkf5itemviews5 5.78.0-2
ii  libkf5kcmutils5  5.78.0-3
ii  libkf5kdelibs4support5   5.78.0-2
ii  libkf5kiocore5   5.78.0-4
ii  libkf5kiofilewidgets55.78.0-4
ii  libkf5kiogui55.78.0-4
ii  libkf5kiowidgets55.78.0-4
ii  libkf5notifications5 5.78.0-2
ii  libkf5notifyconfig5  5.78.0-2
ii  libkf5package5   5.78.0-3
ii  libkf5plasma55.78.0-3
ii  libkf5plasmaquick5   5.78.0-3
ii  libkf5quickaddons5   5.78.0-2
ii  libkf5runner55.78.0-3
ii  libkf5service-bin5.78.0-2
ii  libkf5service5   5.78.0-2
ii  libkf5solid5 5.78.0-2
ii  libkf5sonnetcore55.78.0-2
ii  libkf5sonnetui5  5.78.0-2
ii  libkf5wallet-bin 5.78.0-2
ii  libkf5wallet55.78.0-2
ii  libkf5widgetsaddons5 5.78.0-2
ii  libkf5windowsystem5  5.78.0-2
ii  libkf5xmlgui55.78.0-2
ii  libkworkspace5-5 4:5.20.5-3
ii  libnotificationmanager1  4:5.20.5-3
ii  libphonon4qt5-4  4:4.11.1-3
ii  libprocesscore9  4:5.20.5-1
ii  libqt5concurrent55.15.2+dfsg-4
ii  libqt5core5a 5.15.2+dfsg-4
ii  libqt5dbus5  5.15.2+dfsg-4
ii  libqt5gui5   5.15.2+dfsg-4
ii  libqt5network5   5.15.2+dfsg-4
ii  libqt5qml5   5.15.2+dfsg-4
ii  libqt5quick5 5.15.2+dfsg-4
ii  libqt5quickwidgets5  5.15.2+dfsg-4
ii  libqt5sql5   5.15.2+dfsg-4
ii  libqt5widgets5   5.15.2+dfsg-4
ii  libqt5x11extras5 5.15.2-2
ii  libqt5xml5   5.15.2+dfsg-4
ii  libscim8v5   1.4.18-2.2
ii  libstdc++6   10.2.1-6
ii  libtaskmanager6abi1 

Bug#983009: linux-image-5.10.0-0.bpo.3-cloud-amd64: ecryptfs quietly removed

[Bastian Blank]

Control: tags -1 wontfix

On Thu, Feb 18, 2021 at 04:50:05PM +1100, Hamish Moffatt wrote:
> ecryptfs has been silently removed from the 5.10 kernel packages. This
> is not mentioned in the changelog.

Actually it is mentioned:

|  * [cloud] Disable some further filesystems. (closes: #977005)

Bastian

-- 
We have phasers, I vote we blast 'em!
-- Bailey, "The Corbomite Maneuver", stardate 1514.2

Bug#983012: plasma-desktop: installing plasma-desktop does not pull kmix

[Johannes Ranke]

Package: plasma-desktop
Version: 4:5.20.5-3
Severity: important

Dear Debian Qt/KDE maintainers,

I had to reinstall plasma-desktop upon the upgrade to bullseye, see
#981597. After reinstalling plasma-desktop, I had not sound applet in my
task bar, and kmix was not installed.

Please add a dependency on kmix to plasma-desktop or to one of the
packages it depends on, if this is more suitable.

I think users rightfully expect to see a sound volume applet after
installing a KDE desktop environment.

Thanks, Johannes

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

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

Versions of packages plasma-desktop depends on:
ii  accountsservice  0.6.55-3
ii  breeze   4:5.20.5-2
ii  kactivitymanagerd5.20.5-1
ii  kde-cli-tools4:5.20.5-2
ii  kded55.78.0-2
ii  kio  5.78.0-4
ii  kpackagetool55.78.0-3
ii  libaccounts-qt5-11.16-2
ii  libc62.31-9
ii  libcrypt11:4.4.17-1
ii  libglib2.0-0 2.66.7-1
ii  libibus-1.0-51.5.23-2
ii  libkaccounts24:20.12.1-1
ii  libkf5activities55.78.0-2
ii  libkf5activitiesstats1   5.78.0-2
ii  libkf5authcore5  5.78.0-2
ii  libkf5baloo5 5.78.0-2
ii  libkf5codecs55.78.0-2
ii  libkf5completion55.78.0-3
ii  libkf5configcore55.78.0-4
ii  libkf5configgui5 5.78.0-4
ii  libkf5configwidgets5 5.78.0-2
ii  libkf5coreaddons55.78.0-2
ii  libkf5crash5 5.78.0-3
ii  libkf5dbusaddons55.78.0-2
ii  libkf5declarative5   5.78.0-2
ii  libkf5globalaccel-bin5.78.0-2
ii  libkf5globalaccel5   5.78.0-2
ii  libkf5guiaddons5 5.78.0-3
ii  libkf5i18n5  5.78.0-2
ii  libkf5iconthemes55.78.0-2
ii  libkf5itemviews5 5.78.0-2
ii  libkf5kcmutils5  5.78.0-3
ii  libkf5kdelibs4support5   5.78.0-2
ii  libkf5kiocore5   5.78.0-4
ii  libkf5kiofilewidgets55.78.0-4
ii  libkf5kiogui55.78.0-4
ii  libkf5kiowidgets55.78.0-4
ii  libkf5notifications5 5.78.0-2
ii  libkf5notifyconfig5  5.78.0-2
ii  libkf5package5   5.78.0-3
ii  libkf5plasma55.78.0-3
ii  libkf5plasmaquick5   5.78.0-3
ii  libkf5quickaddons5   5.78.0-2
ii  libkf5runner55.78.0-3
ii  libkf5service-bin5.78.0-2
ii  libkf5service5   5.78.0-2
ii  libkf5solid5 5.78.0-2
ii  libkf5sonnetcore55.78.0-2
ii  libkf5sonnetui5  5.78.0-2
ii  libkf5wallet-bin 5.78.0-2
ii  libkf5wallet55.78.0-2
ii  libkf5widgetsaddons5 5.78.0-2
ii  libkf5windowsystem5  5.78.0-2
ii  libkf5xmlgui55.78.0-2
ii  libkworkspace5-5 4:5.20.5-3
ii  libnotificationmanager1  4:5.20.5-3
ii  libphonon4qt5-4  4:4.11.1-3
ii  libprocesscore9  4:5.20.5-1
ii  libqt5concurrent55.15.2+dfsg-4
ii  libqt5core5a 5.15.2+dfsg-4
ii  libqt5dbus5  5.15.2+dfsg-4
ii  libqt5gui5   5.15.2+dfsg-4
ii  libqt5network5   5.15.2+dfsg-4
ii  libqt5qml5   5.15.2+dfsg-4
ii  libqt5quick5 5.15.2+dfsg-4
ii  libqt5quickwidgets5  5.15.2+dfsg-4
ii  libqt5sql5   5.15.2+dfsg-4
ii  libqt5widgets5   5.15.2+dfsg-4
ii  libqt5x11extras5 5.15.2-2
ii  libqt5xml5   5.15.2+dfsg-4
ii  libscim8v5   1.4.18-2.2
ii  libstdc++6   10.2.1-6
ii  libtaskmanager6abi1 

Bug#983011: libapache2-mod-php7.3: Package updates should trigger an Apache restart

[Björn Wiberg]

Package: libapache2-mod-php7.3
Version: 7.3.27-1~deb10u1
Severity: normal

When libapache2-mod-php7.3 is updated, Apache (systemctl service "apache2") 
does not get restarted automatically.
I would expect Apache to be restarted automatically after the package update.

Example update session (via cron-apt):

Feb 18 04:54:05 glimmer cron-apt: The following packages will be upgraded:
Feb 18 04:54:05 glimmer cron-apt:   libapache2-mod-php7.3 libssl1.1 openssl 
php7.3-bcmath php7.3-cli
Feb 18 04:54:05 glimmer cron-apt:   php7.3-common php7.3-curl php7.3-gd 
php7.3-intl php7.3-json php7.3-mbstring
Feb 18 04:54:05 glimmer cron-apt:   php7.3-mysql php7.3-opcache php7.3-readline 
php7.3-soap php7.3-sqlite3
Feb 18 04:54:05 glimmer cron-apt:   php7.3-xml php7.3-xmlrpc php7.3-zip
Feb 18 04:54:05 glimmer cron-apt: apt-listchanges: Reading changelogs...
Feb 18 04:54:05 glimmer cron-apt: apt-listchanges: Changelogs
--
Feb 18 04:54:05 glimmer cron-apt: Unpacking php7.3-gd (7.3.27-1~deb10u1) over 
(7.3.19-1~deb10u1) ...#015
Feb 18 04:54:05 glimmer cron-apt: Preparing to unpack 
.../13-php7.3-curl_7.3.27-1~deb10u1_amd64.deb ...#015
Feb 18 04:54:05 glimmer cron-apt: Unpacking php7.3-curl (7.3.27-1~deb10u1) over 
(7.3.19-1~deb10u1) ...#015
Feb 18 04:54:05 glimmer cron-apt: Preparing to unpack 
.../14-php7.3-bcmath_7.3.27-1~deb10u1_amd64.deb ...#015
Feb 18 04:54:05 glimmer cron-apt: Unpacking php7.3-bcmath (7.3.27-1~deb10u1) 
over (7.3.19-1~deb10u1) ...#015
Feb 18 04:54:05 glimmer cron-apt: Preparing to unpack 
.../15-libapache2-mod-php7.3_7.3.27-1~deb10u1_amd64.deb ...#015
Feb 18 04:54:05 glimmer cron-apt: Unpacking libapache2-mod-php7.3 
(7.3.27-1~deb10u1) over (7.3.19-1~deb10u1) ...#015
Feb 18 04:54:05 glimmer cron-apt: Preparing to unpack 
.../16-php7.3-cli_7.3.27-1~deb10u1_amd64.deb ...#015
Feb 18 04:54:05 glimmer cron-apt: Unpacking php7.3-cli (7.3.27-1~deb10u1) over 
(7.3.19-1~deb10u1) ...#015
Feb 18 04:54:05 glimmer cron-apt: Preparing to unpack 
.../17-php7.3-common_7.3.27-1~deb10u1_amd64.deb ...#015
Feb 18 04:54:05 glimmer cron-apt: Unpacking php7.3-common (7.3.27-1~deb10u1) 
over (7.3.19-1~deb10u1) ...#015
Feb 18 04:54:05 glimmer cron-apt: Preparing to unpack 
.../18-openssl_1.1.1d-0+deb10u5_amd64.deb ...#015
--
Feb 18 04:54:05 glimmer cron-apt: Setting up php7.3-sqlite3 (7.3.27-1~deb10u1) 
...#015
Feb 18 04:54:05 glimmer cron-apt: Setting up php7.3-mbstring (7.3.27-1~deb10u1) 
...#015
Feb 18 04:54:05 glimmer cron-apt: Setting up php7.3-json (7.3.27-1~deb10u1) 
...#015
Feb 18 04:54:05 glimmer cron-apt: Setting up php7.3-readline (7.3.27-1~deb10u1) 
...#015
Feb 18 04:54:05 glimmer cron-apt: Setting up php7.3-cli (7.3.27-1~deb10u1) 
...#015
Feb 18 04:54:05 glimmer cron-apt: Setting up libapache2-mod-php7.3 
(7.3.27-1~deb10u1) ...#015
Feb 18 04:54:05 glimmer cron-apt: libapache2-mod-php7.3: not switching MPM - 
already enabled#015
Feb 18 04:54:05 glimmer cron-apt: Processing triggers for libc-bin (2.28-10) 
...#015
Feb 18 04:54:05 glimmer cron-apt: Processing triggers for man-db (2.8.5-2) 
...#015

Systemctl status output of the apache2 service:

root@glimmer:~# systemctl status apache2
● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: 
enabled)
   Active: active (running) since Sat 2021-02-13 12:05:05 CET; 4 days ago
 Docs: https://httpd.apache.org/docs/2.4/
  Process: 602 ExecStart=/usr/sbin/apachectl start (code=exited, 
status=0/SUCCESS)
  Process: 10813 ExecReload=/usr/sbin/apachectl graceful (code=exited, 
status=0/SUCCESS)
 Main PID: 1015 (apache2)
Tasks: 11 (limit: 4915)
   Memory: 4.8G
   CGroup: /system.slice/apache2.service
   ├─ 1015 /usr/sbin/apache2 -k start
   ├─10818 /usr/sbin/apache2 -k start
   ├─11790 /usr/sbin/apache2 -k start
   ├─11791 /usr/sbin/apache2 -k start
   ├─11792 /usr/sbin/apache2 -k start
   ├─11840 /usr/sbin/apache2 -k start
   ├─11906 /usr/sbin/apache2 -k start
   ├─12425 /usr/sbin/apache2 -k start
   ├─13525 /usr/sbin/apache2 -k start
   ├─13574 /usr/sbin/apache2 -k start
   └─25411 /usr/sbin/apache2 -k start

feb 18 00:00:02 glimmer systemd[1]: Reloading The Apache HTTP Server.
feb 18 00:00:02 glimmer systemd[1]: Reloaded The Apache HTTP Server.
Warning: Journal has been rotated since unit was started. Log output is 
incomplete or unavailable.

root@glimmer:~# journalctl -u apache2
-- Logs begin at Wed 2021-02-17 10:29:01 CET, end at Thu 2021-02-18 07:33:36 
CET. --
feb 18 00:00:02 glimmer systemd[1]: Reloading The Apache HTTP Server.
feb 18 00:00:02 glimmer systemd[1]: Reloaded The Apache HTTP Server.
root@glimmer:~#

As can be seen from the "Active" status, Apache was not restarted automatically.

Best regards
Björn


-- Package-specific info:
 Additional PHP 7.3 information 

 PHP 7.3 SAPI (php7.3query -S): 

 PHP 7.3 Extensions (php7.3query -M -v): 

 Configuration files: 
[PHP]

Bug#983010: mdocml breaks debiman autopkgtest: different output

[Paul Gevers]

Source: mdocml, debiman
Control: found -1 mdocml/1.14.5-1
Control: found -1 debiman/0.0~git20200217.fc82521-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
mdocml from testing1.14.5-1
debimanfrom testing0.0~git20200217.fc82521-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. Normally I
would assign this bug to debiman as it captures the output of a
different program (so it seems to me) in the test. However, we're in the
freeze and this is a new upstream release (which we request to be
reluctant with), so please *align* quickly how to best move forward.

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/d/debiman/10541019/log.gz

=== CONT  TestToHTML/i3lock
2021/02/18 04:13:33 mandocd not found, falling back to fork+exec for
each manpage
=== CONT  TestToHTML/refs
2021/02/18 04:13:33 mandocd not found, falling back to fork+exec for
each manpage
=== CONT  TestToHTML/i3lock
convert_test.go:92: unexpected conversion result: (diff from want →
got):
--- /tmp/debiman-849248825  2021-02-18 04:13:33.034473409 +
+++ /tmp/debiman-376692162  2021-02-18 04:13:33.034473409 +
@@ -7,67 +7,76 @@
   
 
 
-
-
+
+
+
 NAME¶
 i3lock - improved screen locker
-
+
+
+
 SYNOPSIS¶
 i3lock [-v] [-c color]
-
+
+
+
 DESCRIPTION¶
 i3lock is a simple screen locker like slock. After
starting it, you will
   see a white screen (you can configure the color/an image).
You can return to
   your screen by entering your password.
-
+
+
+
 IMPROVEMENTS¶
 
   •
   i3lock forks, so you can combine it with an alias to
suspend to RAM (run
   i3lock  echo mem 
/sys/power/state to get a
   locked screen after waking up your computer from suspend
to RAM)
-
-
   •
   You can specify either a background color or a PNG image
which will be
   displayed while your screen is locked.
-
-
   •
   You can specify whether i3lock should bell upon a wrong
password.
-
-
   •
   i3lock uses PAM and therefore is compatible with LDAP, etc.
-
-
+
+
   
 
+
+
 OPTIONS¶
 
   -v, --version
   Display the version of your i3lock
-
+
   
-
-
   -c rrggbb,
--color=rrggbb
   Turn the screen into the given color instead of white.
Color must be given
   in 3-byte format: rrggbb (i.e. ff is red).
-
+
   
 
+
+
 DPMS¶
 The -d (--dpms) option.
-
+
   verbatim
 
-
+
+
+
 SEE ALSO¶
 xautolock(1) - use i3lock as your screen saver
-
+
+
+
 AUTHOR¶
-Michael Stapelberg michael+i3lock@example.invalid
+Michael Stapelberg michael+i3lock@example.invalid
+
+
 
   
 JANUARY 2012

=== CONT  TestToHTML/refs
convert_test.go:92: unexpected conversion result: (diff from want →
got):
--- /tmp/debiman-144560851  2021-02-18 04:13:33.034473409 +
+++ /tmp/debiman-918139460  2021-02-18 04:13:33.034473409 +
@@ -7,22 +7,26 @@
   
 
 
+
 NAME¶
 refs - test file
-
+
+
+
 SEE ALSO¶
 http://w3m.sourceforge.net;>project website
-
-More details can be found in the i3lock(1) or refs(1) man pages.
-
-References to i3-msg(1)
might cause trouble when matching on word boundaries.
-
-References 

Bug#983009: linux-image-5.10.0-0.bpo.3-cloud-amd64: ecryptfs quietly removed

[Hamish Moffatt]

Package: src:linux
Version: 5.10.13-1~bpo10+1
Severity: normal

ecryptfs has been silently removed from the 5.10 kernel packages. This
is not mentioned in the changelog.

I upgraded linux-image-cloud-amd64 from buster-backports from 5.9 to 5.10. My 
system no longer boots because I depend on ecryptfs for protection of some data 
directories.


-- Package-specific info:
** Version:
Linux version 5.10.0-0.bpo.3-cloud-amd64 (debian-ker...@lists.debian.org) 
(gcc-8 (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP 
Debian 5.10.13-1~bpo10+1 (2021-02-11)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-0.bpo.3-cloud-amd64 
root=UUID=1951b2f8-a55c-490c-9ecf-3a5e7f95f4fb ro quiet nosplash vga=770 
net.ifnames=0

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: BinaryLane
product_name: A.2040
product_version: 
chassis_vendor: Bochs
chassis_version: 
bios_vendor: Bochs
bios_version: Bochs

** Loaded modules:
tun
binfmt_misc
nf_log_ipv6
ip6t_REJECT
nf_reject_ipv6
intel_rapl_msr
intel_rapl_common
iosf_mbi
xt_hl
crct10dif_pclmul
crc32_pclmul
ip6_tables
ghash_clmulni_intel
ip6t_rt
nf_log_ipv4
aesni_intel
nf_log_common
xt_LOG
crypto_simd
ipt_REJECT
cryptd
glue_helper
nf_reject_ipv4
nft_limit
xt_limit
xt_addrtype
xt_tcpudp
xt_conntrack
evdev
virtio_balloon
serio_raw
nft_compat
button
nft_counter
nf_conntrack_netbios_ns
nf_conntrack_broadcast
nf_nat_ftp
nf_nat
nf_conntrack_ftp
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
nf_tables
libcrc32c
nfnetlink
ip_tables
x_tables
autofs4
ata_generic
virtio_net
ata_piix
net_failover
virtio_blk
failover
libata
crc32c_intel
virtio_pci
scsi_mod
virtio_ring
virtio

** PCI devices:
not available

** USB devices:
not available


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

Kernel: Linux 5.10.0-0.bpo.3-cloud-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-5.10.0-0.bpo.3-cloud-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133+deb10u1
ii  kmod26-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-0.bpo.3-cloud-amd64 recommends:
ii  apparmor 2.13.2-10
ii  firmware-linux-free  3.4

Versions of packages linux-image-5.10.0-0.bpo.3-cloud-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02+dfsg1-20+deb10u3
pn  linux-doc-5.10  

Versions of packages linux-image-5.10.0-0.bpo.3-cloud-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#983008: silver-platter: autopkgtest regression: cannot import name 'debcommit' from 'breezy.plugins.debian.changelog'

[Paul Gevers]

Source: silver-platter
Version: 0.4.1-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

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

   passfail
silver-platter from testing0.4.1-1
all others from testingfrom testing

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

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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

Paul

[1] https://qa.debian.org/excuses.php?package=silver-platter

https://ci.debian.net/data/autopkgtest/testing/amd64/s/silver-platter/10539975/log.gz

==
ERROR: test_debian_upstream (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_debian_upstream
Traceback (most recent call last):
  File "/usr/lib/python3.9/unittest/loader.py", line 154, in
loadTestsFromName
module = __import__(module_name)
  File
"/tmp/autopkgtest-lxc.k6jl00if/downtmp/build.OAF/src/silver_platter/tests/test_debian_upstream.py",
line 21, in 
from ..debian.upstream import (
  File
"/tmp/autopkgtest-lxc.k6jl00if/downtmp/build.OAF/src/silver_platter/debian/upstream.py",
line 73, in 
from breezy.plugins.debian.changelog import debcommit
ImportError: cannot import name 'debcommit' from
'breezy.plugins.debian.changelog'
(/usr/lib/python3/dist-packages/breezy/plugins/debian/changelog.py)



OpenPGP_signature
Description: OpenPGP digital signature

Bug#981699: thinkfan: fails on upgrade

[cruncher]

Package: thinkfan
Version: 1.2.1-2
Followup-For: Bug #981699


I have the same problem:
ERROR: Error scanning /sys/devices/pci:00/:00:03.1/:27:00.0/hwmon:
No such file or directory


Regards



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

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

Versions of packages thinkfan depends on:
ii  init-system-helpers  1.60
ii  libatasmart4 0.19-5
ii  libc62.31-9
ii  libgcc-s110.2.1-6
ii  libstdc++6   10.2.1-6
ii  libyaml-cpp0.6   0.6.3-9

thinkfan recommends no packages.

thinkfan suggests no packages.

-- Configuration Files:
/etc/default/thinkfan changed [not included]
/etc/thinkfan.conf changed [not included]

Bug#983007: tqdm breaks backblaze-b2 autopkgtest: The wheel package is not available.

[Paul Gevers]

Source: tqdm, backblaze-b2
Control: found -1 tqdm/4.56.2-1
Control: found -1 backblaze-b2/1.3.8-4
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
tqdm   from testing4.56.2-1
backblaze-b2   from testing1.3.8-4
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/b/backblaze-b2/10523984/log.gz

[*] testing on python3.9:
running nosetests
running egg_info
creating b2.egg-info
writing b2.egg-info/PKG-INFO
writing dependency_links to b2.egg-info/dependency_links.txt
writing entry points to b2.egg-info/entry_points.txt
writing requirements to b2.egg-info/requires.txt
writing top-level names to b2.egg-info/top_level.txt
writing manifest file 'b2.egg-info/SOURCES.txt'
reading manifest file 'b2.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'b2.egg-info/SOURCES.txt'
WARNING: The wheel package is not available.
/usr/bin/python3.9: No module named pip
error: Command '['/usr/bin/python3.9', '-m', 'pip',
'--disable-pip-version-check', 'wheel', '--no-deps', '-w',
'/tmp/tmp7u77k0jh', '--quiet', 'tqdm>=4.5.0']' returned non-zero exit
status 1.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983006: apt-cacher-ng apparmor profile denies access to /proc/sys/kernel/random/uuid which is read during restarts

[Paul Wise]

Package: apparmor-profiles-extra
Version: 1.30
Severity: normal
File: /etc/apparmor.d/usr.sbin.apt-cacher-ng
X-Debbugs-CC: apt-cacher...@packages.debian.org
Usertags: apparmor

When I restart apt-cacher-ng, it tried to read a random UUID from Linux
and gets denied because the apparmor profile does not allow it. Despite
that denial it still gets started fine.

   Feb 18 13:06:09 sudo[682638]: pabs : TTY=pts/5 ; PWD=/home/pabs ; 
USER=root ; COMMAND=/bin/systemctl restart apt-cacher-ng.service
   Feb 18 13:06:09 sudo[682638]: pam_unix(sudo:session): session opened for 
user root(uid=0) by (uid=1000)
   Feb 18 13:06:09 systemd[1]: Stopping Apt-Cacher NG software download proxy...
   Feb 18 13:06:10 systemd[1]: apt-cacher-ng.service: Succeeded.
   Feb 18 13:06:10 systemd[1]: Stopped Apt-Cacher NG software download proxy.
   Feb 18 13:06:10 systemd[1]: Starting Apt-Cacher NG software download proxy...
   Feb 18 13:06:10 kernel: audit: type=1400 audit(1613624770.098:70): 
apparmor="DENIED" operation="open" profile="apt-cacher-ng" 
name="/proc/sys/kernel/random/uuid" pid=682652 comm="apt-cacher-ng" 
requested_mask="r" denied_mask="r" fsuid=139 ouid=0
   Feb 18 13:06:10 kernel: audit: type=1400 audit(1613624770.098:71): 
apparmor="DENIED" operation="open" profile="apt-cacher-ng" 
name="/proc/sys/kernel/random/uuid" pid=682652 comm="apt-cacher-ng" 
requested_mask="r" denied_mask="r" fsuid=139 ouid=0
   Feb 18 13:06:10 systemd[1]: Started Apt-Cacher NG software download proxy.
   Feb 18 13:06:10 sudo[682638]: pam_unix(sudo:session): session closed for 
user root

It appears as though this access comes from libevent:

   $ for f in $(ldd /usr/sbin/apt-cacher-ng | grep -o '/[^ )]*') ; do strings 
$f | grep -q /uuid && echo $f ; fi ; done
   /usr/lib/x86_64-linux-gnu/libevent_core-2.1.so.7
   /usr/lib/x86_64-linux-gnu/libevent-2.1.so.7

I think this started when I upgraded to 3.6-1:

   Start-Date: 2021-02-18  12:15:20
   Commandline: /usr/bin/unattended-upgrade
   Upgrade: apt-cacher-ng:amd64 (3.5-3, 3.6-1)
   End-Date: 2021-02-18  12:15:31

This version does have some libevent related changes:

   $ zcat /usr/share/doc/apt-cacher-ng/changelog.gz | sed -n '/(3.6)/,/(3.5)/p' 
| grep -A1 libevent
 * Using asynchronous libevent DNS resolver instead of getaddrinfo from OS,
   since the later turned out to be unreliable in stress tests

I'm not sure if these changes could have caused the change in behaviour
to trying to use the Linux kernel random UUID file, so I am CCing the
maintainer of the apt-cacher-ng package.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages apparmor-profiles-extra depends on:
ii  apparmor  2.13.6-9

apparmor-profiles-extra recommends no packages.

apparmor-profiles-extra suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#973715: RE: Bug#973715: fwupd-amd64-signed holding off fwupd update results in segfaulting binary

[Paul Gevers]

Hi Mario,

LOn Mon, 16 Nov 2020 16:01:34 + "Limonciello, Mario"
 wrote:
> As @Steve McIntyre mentions, it's a manual process to kick off the re-signing.
> It needs to be done when 1.5.1-2 is ready to migrate.

There's users of unstable too. In my opinion, if you can't relax the
constraints, you'll have to kick it off as soon as it's needed in
unstable, not when it's ready to migrate.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983005: RFS: janet/1.15.2-1 [ITP] -- Dynamic language and bytecode VM

[Bradford D. Boyle]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: janet
   Version : 1.15.2-1
   Upstream Author : Calvin Rose 
 * URL : https://janet-lang.org/
 * License : MIT
 * Vcs : [fill in URL of packaging vcs]
   Section : misc

It builds those binary packages:

  libjanet1.15 - header files Janet
  libjanet-dev - Shared Janet runtime library (version 1.15)
  janet - Dynamic language and bytecode VM

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/j/janet/janet_1.15.2-1.dsc

Changes for the initial release:

 janet (1.15.2-1) unstable; urgency=medium
 .
   * Initial release (Closes: #983003)

Regards,
-- 
  Bradford D. Boyle

Bug#905015: xserver-xorg-input-elographics: Xorg hangs on start when touchscreen does not answer

[Frank Heckenbach]

> This was a bug in X server 1.19 fixed in 1.19.4 with
> https://gitlab.freedesktop.org/xorg/xserver/-/commit/d8f63717e05ae8d820ceae74216916ebd180441d
> 
> Unfortunately this bug is in the X server in stretch and won't get fixed 
> there now that stretch is LTS, but the versions in buster and later 
> should be fine.

I guess that explains why I got reports of touchscreens not working
reliably in buster:

I had applied the above patch to xserver-xorg-input-elographics,
after duly checking it hadn't been applied yet. But of course, I had
no way of knowing that the problem was fixed another way in another
package.

The result now was apparently an overcorrection, resulting in
timeouts being too short and sometimes timing out ...

Bug#983004: bind9: CVE-2020-8625

[Salvatore Bonaccorso]

Source: bind9
Version: 1:9.16.11-2
Severity: grave
Tags: security upstream fixed-upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1:9.11.5.P4+dfsg-5.1+deb10u2
Control: found -1 1:9.11.5.P4+dfsg-5.1
Control: fixed -1 1:9.11.5.P4+dfsg-5.1+deb10u3

Hi,

The following vulnerability was published for bind9.

CVE-2020-8625[0]:
| BIND servers are vulnerable if they are running an affected version
| and are configured to use GSS-TSIG features. In a configuration which
| uses BIND's default settings the vulnerable code path is not exposed,
| but a server can be rendered vulnerable by explicitly setting valid
| values for the tkey-gssapi-keytab or tkey-gssapi-
| credentialconfiguration options. Although the default configuration is
| not vulnerable, GSS-TSIG is frequently used in networks where BIND is
| integrated with Samba, as well as in mixed-server environments that
| combine BIND servers with Active Directory domain controllers. The
| most likely outcome of a successful exploitation of the vulnerability
| is a crash of the named process. However, remote code execution, while
| unproven, is theoretically possible. Affects: BIND 9.5.0 -
| 9.11.27, 9.12.0 - 9.16.11, and versions BIND 9.11.3-S1 -
| 9.11.27-S1 and 9.16.8-S1 - 9.16.11-S1 of BIND Supported Preview
| Edition. Also release versions 9.17.0 - 9.17.1 of the BIND 9.17
| development branch


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-8625
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8625
[1] https://kb.isc.org/v1/docs/cve-2020-8625
[2] 
https://gitlab.isc.org/isc-projects/bind9/commit/b04cb88462863d762093760ffcfe1946200e30f5

Regards,
Salvatore

Bug#983003: ITP: janet -- Dynamic language and bytecode VM

[Bradford D. Boyle]

Package: wnpp
Severity: wishlist
Owner: "Bradford D. Boyle" 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: janet
  Version : 1.15.2
  Upstream Author : Calvin Rose 
* URL : https://janet-lang.org/
* License : MIT
  Programming Lang: C
  Description : Dynamic language and bytecode VM

Janet is a functional and imperative programming language
and bytecode interpreter. It is a lisp-like language, but
lists are replaced by other data structures (arrays, tables
(hash table), struct (immutable hash table), tuples). The
language also supports bridging to native code written in
C, meta-programming with macros, and bytecode assembly.

There is a REPL for trying out the language, as well as the
ability to run script files. This client program is
separate from the core runtime, so Janet can be embedded in
other programs. Try Janet in your browser at
https://janet-lang.org.

Bug#982519: zstd: Race condition allows attacker to access world-readable destination file

[Salvatore Bonaccorso]

On Thu, Feb 11, 2021 at 08:33:58AM +0100, Sebastien Delafond wrote:
> Package: zstd
> Version: 1.4.8+dfsg-1
> Severity: grave
> Tags: security
> X-Debbugs-Cc: t...@security.debian.org
> 
> The recently applied patch still creates the file with the default
> umask[0], before chmod'ing down to 0600, so an attacker could still open
> it in the meantime.

FTR, this has been fixed upstream.

https://github.com/facebook/zstd/commit/a774c5797399040af62db21d8a9b9769e005430e

Regards,
Salvatore

Bug#983002: plocate: updatedb fails with "/var/lib/plocate/: Operation not supported"

[Daniel Lewart]

Package: plocate
Version: 1.1.3-1 and 1.1.4-1
Severity: important

Steinar,

updatedb fails with:
/var/lib/plocate/: Operation not supported

However, writing to a database in a different directory works fine.

Please see the transcript below.

Thank you!
Daniel Lewart
Urbana, Illinois
---
$ uname -a
Linux debian 5.10.0-3-amd64 #1 SMP Debian 5.10.13-1 (2021-02-06) x86_64 
GNU/Linux

$ sudo updatedb
/var/lib/plocate/: Operation not supported

$ sudo updatedb -o /tmp/plocate.db

$ ls -l /tmp/plocate.db
-rw-r- 1 root plocate 4590032 Feb 17 21:00 /tmp/plocate.db

$ sudo mv /tmp/plocate.db /var/lib/plocate/

$ locate plocate
/etc/cron.daily/plocate
/etc/systemd/system/timers.target.wants/plocate-updatedb.timer
/usr/bin/plocate
...

Bug#944188: /etc/msmtprc password disclosure

[Simon Deziel]

On 2021-02-17 8:30 p.m., Simon McVittie wrote:

On Wed, 17 Feb 2021 at 18:01:26 -0500, Simon Deziel wrote:

1) you are worried that since msmtp wasn't written with setgid in mind,
there's a risk of someone elevating their privileges to $USER:msmtp to
execute code

=> Doesn't that just give you read access to /etc/msmtprc?


I don't know, I don't use msmtp. Presumably yes?

If this is worth protecting by using OS-level security boundaries,
then it seems to me that it's worth protecting in a way that isn't
easily defeated - otherwise the effect is to give sysadmins a false
sense of security.


If by easily defeated, you mean leaking the SMTP password with 'msmtp 
--debug' then I fully agree. If on the other hand you are implying that 
the setgid feature could be abused to leak the SMTP password, then I 
wouldn't consider this easily defeated.



2) Glib should be hardened to treat setgid processes specially to make it
more secure. Doing so breaks the msmtp libsecret integration.


Yes, ish. It's more like: GLib should ideally be hardened to treat all
processes that have the AT_SECURE flag equally specially. AT_SECURE is
the kernel telling us "you have privileges, be careful not to trust your
parent process", and ideally GLib would always respond to that by being
as careful as possible.

However, GLib 2.66.4-2 tried being as careful as possible, and it turns
out to make programs (at least msmtp and gnome-keyring) regress, by
preventing them from learning the address of the D-Bus session bus. At the
moment, GLib is second-guessing that warning from the kernel and asking
"but am I *really* privileged, or just *slightly* privileged?" in order to
keep msmtp and gnome-keyring working, but that's extra security exposure -
and not just in msmtp, but also in programs that are protecting something
more important than a SMTP password.


Thanks for the clear explanation!


GLib is not really in a position to know that setgid msmtp is any less
dangerous than setgid shadow, or setgid adm, or setgid sudo. If we tried
to hard-code which privileges are genuinely important and which privileges
are unimportant, that would scale really badly.


Agreed.


I would recommend removing the setgid support from msmtp, and recommending
that people who want a system-wide authenticating MTA whose credentials
are not disclosed to unprivileged users


Doing so by default would let everyone read creds from /etc/msmtprc which
sounds easier than abusing a setgid (even one not designed to run that way).


If Debian wasn't telling sysadmins "it's safe to put msmtp credentials in
/etc/msmtprc, unprivileged users won't be able to read them", then they
could make their own decision about whether it's acceptable for unprivileged
users on their systems to be able to see the SMTP password.

If that's fine for that particular sysadmin's threat model, then the setgid
mechanism would be unnecessary.

If not, then that sysadmin should probably be choosing something "heavier"
than msmtp, that does put a real security boundary between users and
SMTP credentials, and treats it as a security vulnerability with CVE IDs
and advisories if that boundary fails - like exim or postfix. And, yes,
that often implies running a daemon. The sysadmin will have to decide
whether that's worth it.


That said, msmtp is really nice due to not having to run a daemon.


Of course - I don't use msmtp myself, but I've used similar small
SMTP-sending implementations like esmtp in the past, and I recognise the
advantages of that architecture. However, this architecture comes with
limitations, and I think it's important to be realistic about what msmtp
can and can't promise.

>

As a user, I guess I wouldn't mind having that setgid behind a debconf
question. Would that middle ground work?


I'm not sure that really helps. If the sysadmin doesn't trust msmtp
to keep passwords safe from unprivileged users, they can just not put
those passwords in /etc/msmtprc, or at the other extreme, if they don't
care whether unprivileged users can read those passwords, then they can
make it world-readable. The problem case is in the middle, where msmtp
is promising that it will protect the credentials, and the sysadmin
believes its promise, but actually they should not have done. If a
sysadmin is in that position, then they'll answer the debconf question
"yes, make it setgid" and then be disappointed or angry when their
passwords are disclosed.

If msmtp is promising to protect the credentials from unprivileged users,
under at least some configurations, then it needs to be designed to do
that. If it's going to do that in a way that lives up to that promise, > then 
every line of code that ends up in its process space (including
libraries) needs to have been written, or at least reviewed, while
thinking "what's the worst possible way this could be tricked by a
malicious user?" - otherwise it's just providing a false sense of
security.


That represents a *lot* of effort and as you pointed out, 

Bug#978965: closed by Debian FTP Masters (reply to Boyuan Yang ) (Bug#978965: fixed in materia-gtk-theme 20200916-0.1)

[Kushagra Karira]

Hi, the theme was included in testing today, and after the update I'm still
facing a problem in the shell theme and as a result world clock and weather
are overlapping.
The screenshot from my system has been attached below


On Mon, Feb 8, 2021 at 2:39 AM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the materia-gtk-theme package:
>
> #978965: materia-gtk-theme: Support for Gnome 3.38
>
> It has been closed by Debian FTP Masters 
> (reply to Boyuan Yang ).
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Debian FTP Masters <
> ftpmas...@ftp-master.debian.org> (reply to Boyuan Yang )
> by
> replying to this email.
>
>
> --
> 978965: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978965
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 978965-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sun, 07 Feb 2021 21:05:36 +
> Subject: Bug#978965: fixed in materia-gtk-theme 20200916-0.1
> Source: materia-gtk-theme
> Source-Version: 20200916-0.1
> Done: Boyuan Yang 
>
> We believe that the bug you reported is fixed in the latest version of
> materia-gtk-theme, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 978...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Boyuan Yang  (supplier of updated materia-gtk-theme
> package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Fri, 05 Feb 2021 15:29:54 -0500
> Source: materia-gtk-theme
> Architecture: source
> Version: 20200916-0.1
> Distribution: unstable
> Urgency: medium
> Maintainer: Sagar Ippalpalli 
> Changed-By: Boyuan Yang 
> Closes: 978965
> Changes:
>  materia-gtk-theme (20200916-0.1) unstable; urgency=medium
>  .
>[ Leandro Cunha ]
>* Non-maintainer upload.
>* New upstream release.
>* debian/control:
>  - Added in Build-Depends meson and sassc.
>* debian/rules:
>  - Fixed FTBFS and add support to build system with meson.
>* Fixed support for Gnome 3.38. (Closes: #978965)
>  .
>[ Boyuan Yang ]
>* Bump debhelper compat to v13.
>+ BUmp Standards-Version to 4.5.1.
> Checksums-Sha1:
>  ef4cb7db04c97466b8ce48a2e936db49b1015133 1987
> materia-gtk-theme_20200916-0.1.dsc
>  16348d5014e03bda779bcf5bfe2bd23c4d76a280 267560
> materia-gtk-theme_20200916.orig.tar.gz
>  b8152c0d197a9a3f2f3ec5f9301bb99b00e0a9c4 2424
> materia-gtk-theme_20200916-0.1.debian.tar.xz
>  d03c82a440119dc39e1ed2d5ae443190ab44ef03 6331
> materia-gtk-theme_20200916-0.1_amd64.buildinfo
> Checksums-Sha256:
>  d3186eef4f64a913dd0b7a4ecde9bc74fe46028d71748a4b1e90f9eb3398139c 1987
> materia-gtk-theme_20200916-0.1.dsc
>  5c524a0a80fc1a7b66ca8dd414b8023d5859bd6657827dceef1c93d2d9ef7dff 267560
> materia-gtk-theme_20200916.orig.tar.gz
>  88b6bbb97b9d1c9eba2fa1f37950a66ca6bc66637cbc3da82c02a5f422665852 2424
> materia-gtk-theme_20200916-0.1.debian.tar.xz
>  c1eb3f1e0a9cae0f51733934e0f12b811840bf3f6f048d23362f35be6bd66770 6331
> materia-gtk-theme_20200916-0.1_amd64.buildinfo
> Files:
>  cbf15dd6e66bf61ba62b466901260645 1987 x11 optional
> materia-gtk-theme_20200916-0.1.dsc
>  c9c9f2851c9677879801a7e04b8d3643 267560 x11 optional
> materia-gtk-theme_20200916.orig.tar.gz
>  da21eac556190ed0ad79e6c78b963589 2424 x11 optional
> materia-gtk-theme_20200916-0.1.debian.tar.xz
>  4a45290ecf96a19220038fe43fa878e7 6331 x11 optional
> materia-gtk-theme_20200916-0.1_amd64.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEfncpR22H1vEdkazLwpPntGGCWs4FAmAdq0UACgkQwpPntGGC
> Ws7Bzg//aEhT1F8T3hH0yWouswX/xi82me8eDIxowXMWhDHG52jJtnuAdW/HG/Kj
> m/ywh3kEnO3AhSb3oxEkQnZO7Qj4UKF4sfhB2jj88dEIU6NUfSjdhbAK8dm7W7Yq
> UI3l2A4dNLGk0FiE+ozWzVMwKb3V/913RQYOq5aHBt77rr6/jtIGE/6bfaIqanOl
> s3VuAEGT+6bHE1lC3aZaNWN3Kda5ACm1BvYQCG/346UWd0izH2VXmcuPYuyzveTT
> 2WIj33LNe4jRHcHGUX/oBpSjMyX0+VGXG+tso9vxG3BCqEMxavTAvS4NMSzcKuBW
> WSJF1GW/FlwVPExLfWihKTxnWRYbJpN+cCLHQK6T1dfeWkL0Nglq9MiAcJNPvtEU
> QPuJbKyrkcwaeYP2KNrTC4dKanuqtHCt3jkNc4I5F2MYDZAVi80OHIaQMf2UDtCj
> MrAq1Va/HUgnC5PxyXusjl9wnNuSx00yBMc95VeEmORn5OG2x4Q3BlTksgdyyUJc
> ZoIoTFP/7mCCXxKlbHq3Qt6KoRTqlfhuNrgcPGV2BGHnp0zeaWuZlCP1tR7vC7uO
> dlbmp83ZRlBQ65Wgh2sVCxsMhHxnrZWTZI1tl384MjJJuF9lbEnlfrxsdfZh2o/H
> jJOTP0bSqXxrIsHQNVrCuis7qi6IlSXYLUt8Wq5pVYOGDjUofSY=
> =g08B
> -END 

Bug#982947: clinfo reports fatal error

[Rebecca N. Palmer]

On 17/02/2021 10:00, Andreas Beckmann wrote:

Note to self: `reportbug clinfo` should report all installed ICDs


Feel free to borrow beignet-opencl-icd.bug-script

Bug#982996: buster-pu: package awstats/7.6+dfsg-2

[Håvard Flaget Aasen]

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

These  are the same changes which was implemented in stretch, two
upstream patches. Both of these patches resolves a path traversal flaw,
which was first discovered with CVE-2017-1000501.


[ Reason ]
This update fixes bug #891469 and #977197 which is CVE-2020-29600
and CVE-2020-35176

[ Impact ]
Possibility to parse and read files in /etc directory

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable


Regards,
Håvard


diff -Nru awstats-7.6+dfsg/debian/changelog awstats-7.6+dfsg/debian/changelog
--- awstats-7.6+dfsg/debian/changelog   2018-02-02 02:21:35.0 +0100
+++ awstats-7.6+dfsg/debian/changelog   2021-02-02 09:35:23.0 +0100
@@ -1,3 +1,19 @@
+awstats (7.6+dfsg-2+deb10u1) buster; urgency=medium
+
+  * Non-maintainer upload.
+  * CVE-2020-29600: cgi-bin/awstats.pl?config= accepts an absolute
+pathname, even though it was intended to only read a file in the
+/etc/awstats/awstats.conf format. NOTE: this issue exists because of
+an incomplete fix for CVE-2017-1000501. Closes: #891469
+  * CVE-2020-35176: in AWStats through 7.8, cgi-bin/awstats.pl?config=
+accepts a partial absolute pathname (omitting the initial /etc), even
+though it was intended to only read a file in the
+/etc/awstats/awstats.conf format. NOTE: this issue exists because of
+an incomplete fix for CVE-2017-1000501 and CVE-2020-29600.
+Closes: #977190
+
+ -- Håvard Flaget Aasen   Tue, 02 Feb 2021 09:35:23 
+0100
+
 awstats (7.6+dfsg-2) unstable; urgency=medium

   * QA upload.
diff -Nru awstats-7.6+dfsg/debian/patches/CVE-2020-29600.patch 
awstats-7.6+dfsg/debian/patches/CVE-2020-29600.patch
--- awstats-7.6+dfsg/debian/patches/CVE-2020-29600.patch1970-01-01 
01:00:00.0 +0100
+++ awstats-7.6+dfsg/debian/patches/CVE-2020-29600.patch2021-02-02 
09:35:23.0 +0100
@@ -0,0 +1,55 @@
+From: Laurent Destailleur 
+Date: Mon, 17 Dec 2018 12:59:51 +0100
+Subject: [PATCH] FIX #90
+
+Fixes #90/CVE-2020-29600
+
+Origin: upstream, 
https://github.com/eldy/awstats/commit/d4d815d0caae3dbae83ac70a1ae4581bd57cf376
+Bug: https://github.com/eldy/awstats/issues/90
+Bug-Debian: https://bugs.debian.org/#891469
+Last-Update: 2021-02-02
+Reviewed-by: Håvard Flaget Aasen 
+
+---
+ wwwroot/cgi-bin/awstats.pl | 34 ++
+ 1 file changed, 18 insertions(+), 16 deletions(-)
+
+--- a/wwwroot/cgi-bin/awstats.pl
 b/wwwroot/cgi-bin/awstats.pl
+@@ -1781,21 +1781,21 @@
+   }
+
+   #CL - Added to open config if full path is passed to awstats
+-  if ( !$FileConfig ) {
+-
+-  my $SiteConfigBis = File::Spec->rel2abs($SiteConfig);
+-  debug("Finally, try to open an absolute path : $SiteConfigBis", 
2);
+-
+-  if ( -f $SiteConfigBis && open(CONFIG, "$SiteConfigBis")) {
+-  $FileConfig = "$SiteConfigBis";
+-  $FileSuffix = '';
+-  if ($Debug){debug("Opened config: $SiteConfigBis", 2);}
+-  $SiteConfig=$SiteConfigBis;
+-  }
+-  else {
+-  if ($Debug){debug("Unable to open config file: 
$SiteConfigBis", 2);}
+-  }
+-  }
++#if ( !$FileConfig ) {
++#
++# my $SiteConfigBis = File::Spec->rel2abs($SiteConfig);
++# debug("Finally, try to open an absolute path : $SiteConfigBis", 
2);
++#
++# if ( -f $SiteConfigBis && open(CONFIG, "$SiteConfigBis")) {
++# $FileConfig = "$SiteConfigBis";
++# $FileSuffix = '';
++# if ($Debug){debug("Opened config: $SiteConfigBis", 2);}
++# $SiteConfig=$SiteConfigBis;
++# }
++# else {
++# if ($Debug){debug("Unable to open config file: 
$SiteConfigBis", 2);}
++# }
++# }
+
+   if ( !$FileConfig ) {
+   if ($DEBUGFORCED || !$ENV{'GATEWAY_INTERFACE'}){
diff -Nru awstats-7.6+dfsg/debian/patches/CVE-2020-35176.patch 
awstats-7.6+dfsg/debian/patches/CVE-2020-35176.patch
--- awstats-7.6+dfsg/debian/patches/CVE-2020-35176.patch1970-01-01 
01:00:00.0 +0100
+++ awstats-7.6+dfsg/debian/patches/CVE-2020-35176.patch2021-02-02 
09:35:23.0 +0100
@@ -0,0 +1,33 @@
+From: Beuc 
+Date: Thu, 17 Dec 2020 18:14:43 +0100
+Subject: Only look for configuration in dedicated awstats directories
+
+Fixes #195/CVE-2020-35176
+
+Origin: upstream, 
https://github.com/eldy/AWStats/pull/196/commits/0d4d4c05f8e73be8f71dd361dc55cbd52858b823
+Bug: https://github.com/eldy/awstats/issues/195
+Bug-Debian: https://bugs.debian.org/#977190
+---
+ 

Bug#981009: Charybdis abandoned upstream, do not ship in bullseye

[Sadie Powell]

Charybdis' development was terminated due to (among other reasons) threats by a 
former maintainer. It probably won't be revived.

It's successor is probably Solanum (https://github.com/solanum-ircd/solanum) 
which is a fork that is led by freenode and OFTC people some of whom were 
contributors to Charybdis. It might be a good idea to package that instead when 
it gets a release?

~ Sadie

Bug#982987: tech-ctte: Call for votes for new CTTE member

[Sean Whitton]

Hello,

On Wed 17 Feb 2021 at 12:45PM -06, Gunnar Wolf wrote:

> ===BEGIN
>
> The Technical Committee recommends that Christoph Berg  be
> appointed by the Debian Project Leader to the Technical Committee.
>
> A: Recommend to appoint Christoph Berg 
> B: Further Discussion
>
> ===END

I vote

A > B

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#983000: zram-tools: Ship better defaults to suite swap on all hardware

[Sunil Mohan Adapa]

Package: zram-tools
Version: 0.3.2.1-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Please consider updating the defaults to make the package suitable for
installation on most Debian machines.

swap-on-zram has the potential to replace conventional swap. Fedora has done
this[1] by default not just for IoT devices but even for desktops. In
FreedomBox, I have proposed to use it as the default swap solution[2].

The current defaults lead to a hard-coded 256MiB of swap space. This is useful
for single board computers with about 512MiB of RAM but not very useful for
other machines. Instead, consider making that 50% of the available RAM. On
systems that don't typically use swap, this will only incur a 0.1% overhead[3].
RAM will not be get pre-allocated for the zram device. It is only allocated
when necessary.

Further, the configuration file /etc/default/zramswap has incorrect description
for PERCENT parameter. It says, "Specifies the amount of RAM that should be
used for zram based on a percentage the total amount of available memory This
takes precedence and overrides SIZE below". The disksize kernel parameter for
the zram device computed using the above configuration option is about the
amount of space available in the newly create block device. The amount of RAM
that the device will consume depends on compression. Typically 1:2 compression
is expected. So, if PERCENT is set to 50% on a 8GiB machine, then 4GiB of swap
space will be available and on an average case that will consume 2GiB of RAM.

What I am proposing is this:

- -# Specifies the amount of RAM that should be used for zram
- -# based on a percentage the total amount of available memory
+# Specifies the size of swap space that should be created with the zram device
+# computed as a percentage of the total amount of available memory.
 # This takes precedence and overrides SIZE below
- -#PERCENT=50
+PERCENT=50

Thank you for packaging and maintaining zram-tools. Also consider systemd-zram-
generator[4].

Links:
1) https://fedoraproject.org/wiki/Changes/SwapOnZRAM
2) https://salsa.debian.org/freedombox-team/freedombox/-/merge_requests/2033
3)
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-
guide/blockdev/zram.rst
4) https://github.com/systemd/zram-generator/

- --
Sunil



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

Kernel: Linux 5.9.0-0.bpo.5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IN.UTF-8, LC_CTYPE=en_IN.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_IN.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zram-tools depends on:
ii  bc  1.07.1-2+b1

zram-tools recommends no packages.

zram-tools suggests no packages.

- -- Configuration Files:
/etc/default/zramswap changed [not included]

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEE5xPDY9ZyWnWupXSBQ+oc/wqnxfIFAmAtxbYRHHN1bmlsQG1l
ZGhhcy5vcmcACgkQQ+oc/wqnxfImUBAArorWb/sGYvZ16N7nMTIK+U/8mciG8LZ7
kF6l3eSweGXjp9eyaP4xjyTAT9JuXfgbey3msR0JR0mjQvAFN2Fp3wNws3h4xC0O
DmrPn2LGczamjX0FZyUs4tDG22zhv7PFPX3NqNtusjZE5WRWxNJrNChl3gBjydW7
QqW7k/vcm2ajpz3csDubVehvIE5qMkK83DFs+/cspQpN7W/B0wgW066mQ9FOGlq5
ozogZKHS6BreDgR7YFxS5EV0HGyG+1umCAAWfMmnY9PK85yGBccWzutcqC81d/xW
PiazkvXWA5U8tlCt+ev8E1OGBwMRxlAq0Vri0rq9+wI0bHHxHCDvOPMtz+p1Yrhh
XzvsocbqqqkmM7VfWova+97zM+QS6RmzwhgfuaALNHtND7F5eeXcZFpbDI+ldr5b
LltQsRBDuHpRFYPPvdy4j4BgN0mbIRgQweLTit3m+iKVXlOtm9TEQlp9E8hXSlg9
2RnBbjhXjFtLhpqoaX1qQZUOGLb8FFTENkWYDljzeP1JjjdpVWGt6/YgMGDTFSX2
mvHdRFSIFKlQR7x99DxMBOcufHmBr75V0j1Rp+S0PWuwYhzwZpHT7yWxFaSghksM
vDVc/ZGJQ+BBBFOXrFHfnlESXqyYelGyubnfU+8xwlRzP7Adpx04s+BxGpdFddgm
LtJEr1/RggI=
=4ibq
-END PGP SIGNATURE-

Bug#956015: anarchism, new upstream version 15.4

[Samuel Henrique]

Hello everyone :)

there's a "new" upstream version available, 15.4 (17-Mar-2020), does someone
> of you maybe have the capacity to package it? I'd be more than happy to
> assist
> and help out, but I cannot drive this... and the freeze is near :)
>

Ok, so the task we have here is to scrape the new version, preferably with
afaq-dl:
https://0xacab.org/ju/afaq-dl
And then package the result.

I didn't have much free time so I gave it a shot and realized that afaq-dl
seems to be written in python2, I didn't have time to download python2 and
the deps to properly test it.
There's also the possibility that the tool won't work with the new release,
I have the impression that the website changed considerably (I haven't
confirmed so I might be wrong).

I don't think I will have the time to run the scrapper (and motivation to
debug it), but I can package the new version if somebody does that[0].


> last and most importantly, I hope you are doing well in these... times!
>
> ⬛ to you and to be stored in this bug log forever!  :)
>

That's nice :)
I'm good and I hope you're all doing well too

[0] I understand that packaging the new release, after we scrape it, might
be an easy task and that the bulk of the work is still left to be done,
sorry.

Cheers,

-- 
Samuel Henrique 

Bug#944188: /etc/msmtprc password disclosure

[Simon McVittie]

On Wed, 17 Feb 2021 at 18:01:26 -0500, Simon Deziel wrote:
> 1) you are worried that since msmtp wasn't written with setgid in mind,
> there's a risk of someone elevating their privileges to $USER:msmtp to
> execute code
> 
> => Doesn't that just give you read access to /etc/msmtprc?

I don't know, I don't use msmtp. Presumably yes?

If this is worth protecting by using OS-level security boundaries,
then it seems to me that it's worth protecting in a way that isn't
easily defeated - otherwise the effect is to give sysadmins a false
sense of security.

> 2) Glib should be hardened to treat setgid processes specially to make it
> more secure. Doing so breaks the msmtp libsecret integration.

Yes, ish. It's more like: GLib should ideally be hardened to treat all
processes that have the AT_SECURE flag equally specially. AT_SECURE is
the kernel telling us "you have privileges, be careful not to trust your
parent process", and ideally GLib would always respond to that by being
as careful as possible.

However, GLib 2.66.4-2 tried being as careful as possible, and it turns
out to make programs (at least msmtp and gnome-keyring) regress, by
preventing them from learning the address of the D-Bus session bus. At the
moment, GLib is second-guessing that warning from the kernel and asking
"but am I *really* privileged, or just *slightly* privileged?" in order to
keep msmtp and gnome-keyring working, but that's extra security exposure -
and not just in msmtp, but also in programs that are protecting something
more important than a SMTP password.

GLib is not really in a position to know that setgid msmtp is any less
dangerous than setgid shadow, or setgid adm, or setgid sudo. If we tried
to hard-code which privileges are genuinely important and which privileges
are unimportant, that would scale really badly.

> > I would recommend removing the setgid support from msmtp, and recommending
> > that people who want a system-wide authenticating MTA whose credentials
> > are not disclosed to unprivileged users
> 
> Doing so by default would let everyone read creds from /etc/msmtprc which
> sounds easier than abusing a setgid (even one not designed to run that way).

If Debian wasn't telling sysadmins "it's safe to put msmtp credentials in
/etc/msmtprc, unprivileged users won't be able to read them", then they
could make their own decision about whether it's acceptable for unprivileged
users on their systems to be able to see the SMTP password.

If that's fine for that particular sysadmin's threat model, then the setgid
mechanism would be unnecessary.

If not, then that sysadmin should probably be choosing something "heavier"
than msmtp, that does put a real security boundary between users and
SMTP credentials, and treats it as a security vulnerability with CVE IDs
and advisories if that boundary fails - like exim or postfix. And, yes,
that often implies running a daemon. The sysadmin will have to decide
whether that's worth it.

> That said, msmtp is really nice due to not having to run a daemon.

Of course - I don't use msmtp myself, but I've used similar small
SMTP-sending implementations like esmtp in the past, and I recognise the
advantages of that architecture. However, this architecture comes with
limitations, and I think it's important to be realistic about what msmtp
can and can't promise.

> As a user, I guess I wouldn't mind having that setgid behind a debconf
> question. Would that middle ground work?

I'm not sure that really helps. If the sysadmin doesn't trust msmtp
to keep passwords safe from unprivileged users, they can just not put
those passwords in /etc/msmtprc, or at the other extreme, if they don't
care whether unprivileged users can read those passwords, then they can
make it world-readable. The problem case is in the middle, where msmtp
is promising that it will protect the credentials, and the sysadmin
believes its promise, but actually they should not have done. If a
sysadmin is in that position, then they'll answer the debconf question
"yes, make it setgid" and then be disappointed or angry when their
passwords are disclosed.

If msmtp is promising to protect the credentials from unprivileged users,
under at least some configurations, then it needs to be designed to do
that. If it's going to do that in a way that lives up to that promise,
then every line of code that ends up in its process space (including
libraries) needs to have been written, or at least reviewed, while
thinking "what's the worst possible way this could be tricked by a
malicious user?" - otherwise it's just providing a false sense of
security.

If this is not a use-case that the upstream developer supports, then I
think that's dangerous, because upstream will be happily writing code that
assumes the calling user is trusted (because under normal circumstances,
they are!), and it's up to the Debian maintainers to audit for code that
will break their assumptions whenever they update the Debian package.

Shared library dependencies 

Bug#982162: msmtp: cannot read custom aliases file (Permission denied)

[Simon Deziel]

Hello Hugo,

On 2021-02-06 11:13 p.m., Hugo Villeneuve wrote:

Source: msmtp
Version: 1.8.3
Severity: normal

Dear Maintainer,
when specifying a custom aliases file in /etc/msmtprc configuration file like 
this:

 aliases   /etc/aliases.msmtp

msmtp returns the following error:

$> echo -e "foo" | msmtp -t postmaster
msmtp: /etc/aliases.msmtp: Permission denied

Here are the permissions of the file:
$> ls -al /etc/aliases.msmtp
-rw-r--r-- 1 root root  75 Feb  6 21:44 /etc/aliases.msmtp


That is not a common configuration but a valid one nevertheless.


Here is the dmesg output that I observed that seems to indicate it is a problem 
with AppArmor (which I know nothing about):

[1051574.267096] audit: type=1400 audit(1612667641.178:68): apparmor="DENIED" operation="open" profile="/usr/bin/msmtp" 
name="/etc/aliases.msmtp" pid=17563 comm="sendmail" requested_mask="r" denied_mask="r" fsuid=0 ouid=0


Indeed, the default Apparmor profile only allows reading a handful of 
files. You have several options available to make it work:


1) move the aliases file to /etc/aliases
2) add a custom rule to the local override file
3) disable msmtp's Apparmor profile

For instructions on how to do 2 and 3, please refer to msmtp's 
NEWS.Debian.gz.


Regards,
Simon

Bug#982999: mysql-8.0: FTBFS on hppa - ut_allocator does not support over-aligned types

[John David Anglin]

Source: mysql-8.0
Version: 8.0.23-3
Severity: normal
Tags: patch

Dear Maintainer,

Currently, the build fails with the following error:

cd /<>/builddir/storage/innobase && /usr/bin/hppa-linux-gnu-g++ 
-DBOOST_GEOMETRY_SQRT_CHECK_FINITENESS -DCOMPILER_HINTS -DHAVE_CONFIG_H 
-DHAVE_FALLOC_FL_ZERO_RANGE=1 -DHAVE_FALLOC_PUNCH_HOLE_AND_KEEP_SIZE=1 
-DHAVE_IB_GCC_ATOMIC_THREAD_FENCE=1 -DHAVE_IB_GCC_SYNC_SYNCHRONISE=1 
-DHAVE_IB_LINUX_FUTEX=1 -DHAVE_LZ4=1 -DHAVE_NANOSLEEP=1 -DHAVE_SCHED_GETCPU=1 
-DHAVE_TLSv13 -DLINUX_NATIVE_AIO=1 -DLOG_SUBSYSTEM_TAG=\"InnoDB\" 
-DLZ4_DISABLE_DEPRECATE_WARNINGS -DMUTEX_EVENT -DMYSQL_SERVER -DPFS_DIRECT_CALL 
-DRAPIDJSON_NO_SIZETYPEDEFINE -DRAPIDJSON_SCHEMA_USE_INTERNALREGEX=0 
-DRAPIDJSON_SCHEMA_USE_STDREGEX=1 -DUNIV_LINUX -D_FILE_OFFSET_BITS=64 
-D_GNU_SOURCE -D_USE_MATH_DEFINES -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-I/<>/builddir -I/<>/builddir/include 
-I/<> -I/<>/include 
-I/<>/storage/innobase -I/<>/storage/innobase/include 
-I/<>/storage/innobase/handler -I/<>/sql 
-I/<>/sql/auth -isystem /<>/extra/rapidjson/include 
-isystem /usr/include/editline -std=c++14 -fno-omit-frame-pointer -g -O2 
-ffile-prefix-map=/<>=. -Wformat -Werror=format-security -Wall 
-Wextra -Wformat-security -Wvla -Wundef -Woverloaded-virtual -Wcast-qual 
-Wimplicit-fallthrough=2 -Wstringop-truncation -Wsuggest-override -Wlogical-op 
-Wno-unused-parameter -Wno-cast-qual -DDBUG_OFF -ffunction-sections 
-fdata-sections -O2 -g -DNDEBUG -fPIC   -Wdate-time -D_FORTIFY_SOURCE=2 -o 
CMakeFiles/innobase.dir/api/api0api.cc.o -c 
/<>/storage/innobase/api/api0api.cc
In file included from /<>/storage/innobase/include/sync0types.h:42,
 from /<>/storage/innobase/include/univ.i:588,
 from /<>/storage/innobase/os/file.h:47,
 from /<>/storage/innobase/include/os0file.h:47,
 from /<>/storage/innobase/include/api0misc.h:40,
 from /<>/storage/innobase/api/api0api.cc:41:
/<>/storage/innobase/include/ut0new.h: In instantiation of ‘class 
ut_allocator > >’:
/<>/storage/innobase/include/ut0new.h:1033:19:   required from 
‘void ut_delete(T*) [with T = PolicyMutex >]’
/<>/storage/innobase/include/dict0mem.h:2568:5:   required from 
here
/<>/storage/innobase/include/ut0new.h:583:28: error: static 
assertion failed: ut_allocator does not support over-aligned types. Use 
aligned_memory or another similar allocator for this type.
  583 |   static_assert(alignof(T) <= alignof(std::max_align_t),
  | ~~~^~~~
make[4]: *** [storage/innobase/CMakeFiles/innobase.dir/build.make:85: 
storage/innobase/CMakeFiles/innobase.dir/api/api0api.cc.o] Error 1

See:
https://buildd.debian.org/status/fetch.php?pkg=mysql-8.0=hppa=8.0.23-3=1613526368=0

This issue on hppa is the alignment for the pthread mutex is 16 bytes.  This
exceeds the alignment required for all standard types.  This occurred because
the PA 1.x ldcw semaphore instruction requires the semaphore be 16 byte aligned.

The attached patch which was a quick hack works around this issue and allows
mysql-8.0 to build successfully on hppa.  Please install and send upstream
if it is a sutable fix.

Regards,
Dave Anglin

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.10.16+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Index: mysql-8.0-8.0.23/storage/innobase/include/ut0new.h
===
--- mysql-8.0-8.0.23.orig/storage/innobase/include/ut0new.h
+++ mysql-8.0-8.0.23/storage/innobase/include/ut0new.h
@@ -537,7 +537,11 @@ are contiguous in memory. This means tha
 ut_new_pfx_t the resulting pointer must be aligned to the alignment requirement
 of std::max_align_t. Ref. C++ standard: 6.6.5 [basic.align], 11.3.4 [dcl.array]
 */
+#if defined(__hppa__) && defined(__linux__)
+struct alignas(16) ut_new_pfx_t {
+#else
 struct alignas(std::max_align_t) ut_new_pfx_t {
+#endif
 #ifdef UNIV_PFS_MEMORY
 
   /** Performance schema key. Assigned to a name at startup via
@@ -580,9 +584,15 @@ class ut_allocator {
   typedef size_t size_type;
   typedef ptrdiff_t difference_type;
 
+#if defined(__hppa__) && defined(__linux__)
+  static_assert(alignof(T) <= 16,
+"ut_allocator does not support over-aligned types. Use "
+"aligned_memory or another similar allocator for this type.");
+#else
   static_assert(alignof(T) <= alignof(std::max_align_t),
 "ut_allocator does not support over-aligned types. Use "
 "aligned_memory or another similar allocator for this type.");
+#endif
   /** Default constructor.
   @param[in] key  performance schema key. */
   explicit ut_allocator(PSI_memory_key key = 

Bug#663255: Bonjour

[Peter Schuck]

Nous supprimons tous les comptes de messagerie inutilisés de l'année 2020 et 
augmentons la taille de la boîte aux lettres vers la version 2021 mise à 
niveau. Pour continuer à utiliser votre compte de messagerie, vous devez 
vérifier votre compte.

Tous les comptes non vérifiés seront supprimés 24 heures après avoir reçu cette 
notification.

Cliquez ici pour valider votre compte

et cliquez sur Soumettre pour continuer à utiliser votre compte zimbra.

Bug#982998: chkrootkit chkproc uses incorrect value for max_pid

[Greg Schmidt]

Package: chkrootkit
Version: 0.54-1
Severity: normal
X-Debbugs-Cc: g_w_schm...@sbcglobal.net

Dear Maintainer,
   * What led up to the situation?

Executed chkrotkit and had a error in the report

`Checking `bindshell'...not infected
 Checking `lkm'...  OooPS, not expected 3778733 value
 chkproc: Warning: Possible LKM Trojan installed
 chkdirs: nothing detected

Hmm, what does that mean?

grabbed the source and see that while reading thru the output from a 'ps maux'
the pid field is checked against MAX_PROCESSES

ret = atol(p);
if ( ret < 0 || ret > MAX_PROCESSES )
{
fprintf (stderr, " OooPS, not expected %ld value\n", ret);
exit (2);
}

and 
#define MAX_PROCESSES 9

BUT on my system the value of pid_max is much higher 
root@desk1:~# cat /proc/sys/kernel/pid_max
4194304

Maybe the tool could use the /proc value rather than
a compiled in value. 

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

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

Versions of packages chkrootkit depends on:
ii  binutils   2.35.1-7
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.31-9
ii  net-tools  1.60+git20181103.0eebece-1
ii  openssh-client 1:8.4p1-3
ii  procps 2:3.3.16-5

chkrootkit recommends no packages.

chkrootkit suggests no packages.

-- debconf information:
  chkrootkit/diff_mode: false
  chkrootkit/run_daily_opts: -q
  chkrootkit/run_daily: false

Bug#976801: Bug#982871: lintian-brush: Should not set "Testsuite: autopkgtest-pkg-perl" if debian/tests/control is present

[Jelmer Vernooij]

On Tue, Feb 16, 2021 at 08:41:05AM +0200, Andrius Merkys wrote:
> Hello,
> 
> On 2021-02-15 22:12, gregor herrmann wrote:
> > On Mon, 15 Feb 2021 20:29:51 +0100, Axel Beckert wrote:
> >> Jelmer Vernooij wrote:
>  So please stop adding "Testsuite:" headers if debian/tests/control is
>  already present.
> 
>  Luckily the testsuite declared in debian/tests/control was still run, so
>  it didn't completely break autopkgtest for this package, but at least
>  caused unnecessary tests being tried to run, but then skipped.
> >>> Thanks for the bug report.
> >>>
> >>> It looks like this is also a bug in lintian, since it reports
> >>> team/pkg-perl/testsuite/no-team-tests for equivs:
> >>>
> >>> https://lintian.debian.org/tags/team/pkg-perl/testsuite/no-team-tests.html
> >>
> >> Hmmm, I have recently worked on debsums (similar case of a native
> >> pkg-perl-team package which also has a debian/tests/control file) and
> >> I can't remember having seen that warning. Then again I had the
> >> feeling that the lintian tags on the web are often outdated.
> >>
> >> Just checked: Yeah, it's overridden there. (Overridden by myself in
> >> 2015. :-)
> > 
> > Heh :)
> > 
> > I think that's a know, hm, behaviour lintian. I thought there even
> > was a bug report about it but I can't find it right now.
> 
> I had similar (same?) experience with lintian's
> team/pkg-perl/testsuite/no-team-tests due to the package having both
> "Testsuite: autopkgtest-pkg-perl" and debian/tests/control. I filed that
> as bug in lintian, #976801.

This seems to be a slightly different issue. Should
autopkgtest-pkg-perl still be added to Testsuite if there are
other testsuites present, i.e. should this lintian issue still be
raised as the team/pkg-perl/testsuite/no-team-tests description
suggests if "autopkgtest-pkg-perl" is not present but some other
Testsuite setting is?

Cheers,

Jelmer


signature.asc
Description: PGP signature

Bug#979326: ITP: crust -- SCP firmware for sunxi SoCs

[Jonas Smedegaard]

Quoting Nicolas Boulenguez (2021-02-18 00:02:02)
> Hello.
> Do you think these packages are ready for an upload to experimental?
> Should the Maintainer become 'the Tinker team'?
> Do you agree with the Uploaders?
> https://salsa.debian.org/debian/binutils-or1k-elf
> https://salsa.debian.org/debian/gcc-or1k-elf
> https://salsa.debian.org/debian/crust-firmware

It seems crust-firmware is missing upstream and pristine-tar branches.

Otherwise looks good to me (did a quick copyright check for 
crut-firmware but couldn't spot any flaws in your copyright file).


 - 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#980856: bridge-utils: ignores bridge_hw

[Santiago Garcia Mantinan]

> > > Btw, the discrepancy in behavior explained in Bug#980752 remains. With
> > The problem is with neither, I believe.
> Oh? What would cause this then?

Like I have explained to you in other bugs, I could replicate the problem
and found that it was a problem with bridge-utils, I have assigned #980752
to bridge-utils and added a patch to fix that on the bug report.

> Yes, they all have bridge=br0 in their config.

Ok, I've been looking at your interfaces and I have some sugestions to make,
removal of hwaddress statements, leave just the bridge_hw ones, remove all
the ipv6 statements if they don't provide real meaning and I would extend
this to any other stuff you have written. I would leave it like this:

allow-hotplug wlxdongle1mac wlxdongle2mac wlxdongle3mac wlxdongle4mac 
wlxdongle5mac
auto br0

iface br0 inet dhcp
hwaddress enp4s0mac
bridge_hw enp4s0mac
bridge_ports regex (en|wl).*

iface wlxdongle1mac inet manual
hostapd /etc/hostapd/hostapd-wlxdongle1mac.conf

iface wlxdongle2mac inet manual
hostapd /etc/hostapd/hostapd-wlxdongle2mac.conf

iface wlxdongle3mac inet manual
hostapd /etc/hostapd/hostapd-wlxdongle3mac.conf

iface wlxdongle4mac inet manual
hostapd /etc/hostapd/hostapd-wlxdongle4mac.conf

iface wlxdongle5mac inet manual
hostapd /etc/hostapd/hostapd-wlxdongle5mac.conf

I have tested this after applying the patch I sent to bug #980752 with a new
dongle I have just bought and seems to work ok with a similar configuration.

Can you please apply the patch on #980752 to your system and modify the
configuration like I suggest and let me know how things go?

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#944188: /etc/msmtprc password disclosure

[Simon Deziel]

On 2021-02-03 7:26 a.m., Simon McVittie wrote:

On Tue, 05 Nov 2019 at 10:02:23 -0500, Simon Deziel wrote:

On 2019-11-05 9:29 a.m., Jakub Wilk wrote:

If /etc/msmtprc is readable by group msmtp (as suggested in
README.Debian), any user can acquire password from that file


Nice catch! Having /etc/msmtprc group readable is AFAIK, a "debianism".
I don't know if upstream endorses this method of restricting access
to the default account's password.


Even if this specific attack did not exist, if msmtp is not specifically


Right, I'll be ignoring this (upstream) fixable problem for the sake of 
discussion.



designed to be safe to use with elevated privileges, then I think it's
a security-significant, Debian-specific bug to be making it setgid
in Debian.

Privileged (setuid/setgid/setcap) executables need to be written in a
defensive/paranoid way. They have to be specifically designed to distrust
their whole execution environment - environment variables, command-line
options, resource limits and so on - and every library they are linked
to needs to be specifically designed to do the same. Otherwise, there is
often a way for an attacker to trick the process into executing arbitrary
code with its elevated privileges, which gives the attacker access to
those elevated privileges. Please see
 for
a lot more information on this topic.

In this case, the elevated privilege is the ability to read files that
are 0640 root:msmtp, such as /etc/msmtprc in the configuration suggested
by Debian-specific documentation in this package.

This came to my attention because I was recently involved in hardening
GLib so that it is more difficult to use as an attack vector to get
elevated privileges like this. This made GLib distrust environment
variables, which ended up breaking msmtp's support for retrieving
passwords from libsecret
(see ,
).
Note that GLib is not really designed to be used in processes that run
with elevated privileges, so the GLib upstream maintainers consider this
to be security hardening to mitigate it being used in an unsafe way,
rather than a fix for a vulnerability in GLib.

For now, GLib upstream has partially reverted that change, weakening the
security hardening in order to fix the regression, and I'm going to do
the same in Debian. This should stop msmtp from regressing in terms of
which features work, but I cannot guarantee that it does not make msmtp
exploitable. If I find a concrete attack, I will report it privately to
the security team.


If I understand, the problem is twofold:

1) you are worried that since msmtp wasn't written with setgid in mind, 
there's a risk of someone elevating their privileges to $USER:msmtp to 
execute code


=> Doesn't that just give you read access to /etc/msmtprc?


2) Glib should be hardened to treat setgid processes specially to make 
it more secure. Doing so breaks the msmtp libsecret integration.




I would recommend removing the setgid support from msmtp, and recommending
that people who want a system-wide authenticating MTA whose credentials
are not disclosed to unprivileged users


Doing so by default would let everyone read creds from /etc/msmtprc 
which sounds easier than abusing a setgid (even one not designed to run 
that way).



should be using a fully-featured MTA that was designed to act as a
security boundary, like Exim or Postfix.
I don't fully understand your concerns but I trust you on their 
seriousness. That said, msmtp is really nice due to not having to run a 
daemon. I understand that makes it harder to secure the plain text creds 
that are in its config file.


I've been using msmtp for years on hundreds of machine and never used 
the libsecret integration. I'm sure I'm not alone so it would be nice to 
not go back to having /etc/msmtprc world-readable for all of us.


As a user, I guess I wouldn't mind having that setgid behind a debconf 
question. Would that middle ground work?


Regards,
Simon

Bug#979326: ITP: crust -- SCP firmware for sunxi SoCs

[Nicolas Boulenguez]

Hello.
Do you think these packages are ready for an upload to experimental?
Should the Maintainer become 'the Tinker team'?
Do you agree with the Uploaders?
https://salsa.debian.org/debian/binutils-or1k-elf
https://salsa.debian.org/debian/gcc-or1k-elf
https://salsa.debian.org/debian/crust-firmware

Bug#982995: Installation Report

[Raymond Burkholder]

On 2/17/21 3:20 PM, Jeff Forsyth wrote:

Comments/Problems:

RPI4 with 4GiB Ram.  This system is netbooted using RPI-UEFI 1.22 and
iPXE 1.2.x.

DNSMASQ send the RPI-UEFI to the RPI.  The RPI-UEFI pulls the arm64
EFI/ipxe.  The iPXE

shows a menu for booting into the Debian Installer.  The Installer
loads and starts the

interactive menu installation system.  Everything seems good until
input is required.  The

keyboard is dead.


You are probably using a serial port to monitor progress?

If so, you need the following appended on the kernel line to redirect to 
the serial console:


kernel debian-installer/amd64/linux TERM=linux ..  yadda yadda ... 
console=ttyS0,115200n -- console=ttyS0,115200n8

Bug#982997: unblock: python-hdf5storage/0.1.15+git20200608.09dfc5f-2

[Drew Parsons]

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

Please unblock package python-hdf5storage

[ Reason ]

Upstream has identified the problem affecting random failure of tests
reported in RC Bug#971806.  It was in a random number used to label
the numpy dtype.

They have prepared a small patch, already commited to the upstream
main branch and applied in
python-hdf5storage/0.1.15+git20200608.09dfc5f-2


[ Impact ]

Preventing python-hdf5storage from migrating to bullseye will have a
negative impact on hdf5storage users attempting to upgrade from
buster, stranding them with a deprecated version of the package.


[ Tests ]

debian/tests run the affected test, which was
test_write_readback.TestPythonMatlabFormat.test_dtype_structured_with_offsets_titles
in tests/test_write_readback.py

This test is now expected to succeed reliably.


[ Risks ]

Minimal clear patch (+6-2 lines) in a leaf package not affecting other
packages.  Very low risk.


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

(the package is not currently in testing, the diff is taken against
the preceding version in unstable)


unblock python-hdf5storage/0.1.15+git20200608.09dfc5f-2
diff -Nru python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/changelog 
python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/changelog
--- python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/changelog  
2020-08-07 16:39:18.0 +0200
+++ python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/changelog  
2021-02-17 21:33:33.0 +0100
@@ -1,3 +1,13 @@
+python-hdf5storage (0.1.15+git20200608.09dfc5f-2) unstable; urgency=medium
+
+  * Team upload.
+  * debian patch fix_dtype_random_title_1444936.patch applies
+upstream commit #1444936 to fix random dtype titles used in tests.
+Closes: #971806.
+  * Standards-Version: 4.5.1
+
+ -- Drew Parsons   Wed, 17 Feb 2021 21:33:33 +0100
+
 python-hdf5storage (0.1.15+git20200608.09dfc5f-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/control 
python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/control
--- python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/control
2020-08-07 16:39:18.0 +0200
+++ python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/control
2021-02-17 21:33:33.0 +0100
@@ -18,7 +18,7 @@
python3-sphinx,
python3-sphinx-rtd-theme,
python3-setuptools
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
 Vcs-Browser: https://salsa.debian.org/science-team/python-hdf5storage
 Vcs-Git: https://salsa.debian.org/science-team/python-hdf5storage.git
 Homepage: https://github.com/frejanordsiek/hdf5storage
diff -Nru 
python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/patches/fix_dtype_random_title_1444936.patch
 
python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/patches/fix_dtype_random_title_1444936.patch
--- 
python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/patches/fix_dtype_random_title_1444936.patch
   1970-01-01 01:00:00.0 +0100
+++ 
python-hdf5storage-0.1.15+git20200608.09dfc5f/debian/patches/fix_dtype_random_title_1444936.patch
   2021-02-17 21:33:33.0 +0100
@@ -0,0 +1,32 @@
+From 144493620a76e44f9012a22f163b14cd5e6cc61b Mon Sep 17 00:00:00 2001
+From: Freja Nordsiek 
+Date: Wed, 17 Feb 2021 19:46:07 +0100
+Subject: [PATCH] Fixed bug (Issue #104) in generating random titles for the
+ dtype fields in the unit tests, which must be unique.
+
+---
+ tests/test_write_readback.py | 8 ++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+Index: python-hdf5storage/tests/test_write_readback.py
+===
+--- python-hdf5storage.orig/tests/test_write_readback.py   2021-02-17 
21:24:21.288834712 +0100
 python-hdf5storage/tests/test_write_readback.py2021-02-17 
21:24:21.284834709 +0100
+@@ -846,11 +846,15 @@
+ while s in names and s[0].isdigit():
+ s = random_str_ascii(random.randint(1, 10))
+ names.append(s)
++titles = []
++for _ in range(len(names)):
++s = random_str_some_unicode(random.randint(1, 10))
++while s in titles:
++s = random_str_some_unicode(random.randint(1, 10))
++titles.append(s)
+ formats = [(random.choice(base_dtypes),
+ random_numpy_shape(random.randint(1, 4), 10))
+for _ in range(len(names))]
+-titles = [random_str_some_unicode(random.randint(1, 10))
+-  for _ in range(len(names))]
+ offsets = [random.randint(0, 100)
+for _ in range(len(names))]
+ desc = {'names': names,
diff -Nru 

Bug#982985: RFP: multi-timer -- App to set multiple timers sequentially.

[Scorpion2185]

Package: wnpp
Severity: wishlist

* Package name: multi-timer
  Version : 0.0.1
  Upstream Author : https://askubuntu.com/users/307523/wineunuuchs2unix
* URL : https://github.com/Scorpion2185/multi-
timer/blob/main/README.md
* License : GPL
  Programming Lang: Shell
  Description : App to set multiple timers sequentially.

It requires yad.

You may get this error:

yad: cannot create shared memory for key 12345: File exists

(ipcrm -M 12345 fix it).

When it is open if you launch it again this may happen. You can also lose the
settings.

Settings are saved in your home with in the .multi-timer file.

You have to manually set the number of timers for the resolution.

With too many you can' t reach the bottom of the multi-timer' s window, (with
low resolution).

It does not work with many timers, for a 4k monitor for example.

Can you fix that? And add an option in the app that allows to set number of the
timers.
In the script it is explained how to change the quantity of timers and the
supported values.

An option to save/load the configurations can be add? It will be really useful.

Can you add a speech synthesizer? That says the timer' s name when it ends.
(This is a major improvement.)

Can you make the progress bars and the countdowns bigger?
For an easier reading, on monitor with high resolution there is a lot of space.
So you can see clearly the timers even if you are far from the screen.

I cannot find another app that allows you to set multiple timers sequentially.
Useful for training and more.

Bug#982995:

[Jeff Forsyth]

This was a netboot attempt.

Bug#982995: Installation Report

[Jeff Forsyth]

Package: installation-reports

Boot method: 
Image version: 
https://d-i.debian.org/daily-images/arm64/daily/netboot/debian-installer/arm64/linux
2021-02-17 02:07
Date: 2021-02-17 19:14

Machine: RPI4
Processor:
Memory: 4G
Partitions:

Output of lspci -knn (or lspci -nn):

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

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

Comments/Problems:

RPI4 with 4GiB Ram.  This system is netbooted using RPI-UEFI 1.22 and
iPXE 1.2.x.

DNSMASQ send the RPI-UEFI to the RPI.  The RPI-UEFI pulls the arm64
EFI/ipxe.  The iPXE

shows a menu for booting into the Debian Installer.  The Installer
loads and starts the

interactive menu installation system.  Everything seems good until
input is required.  The

keyboard is dead.

Bug#982950: ssh.service starts sshd before network is online: please switch to After=network-online.target instead of just After=network.target

[Thomas Goirand]

Hi Colin,

Thanks a lot for taking the time to provide very valuable information.
It's helping me a lot.

On 2/17/21 12:11 PM, Colin Watson wrote:
> On Wed, Feb 17, 2021 at 11:46:57AM +0100, Thomas Goirand wrote:
>> On 2/17/21 10:14 AM, Colin Watson wrote:
>>> Are you using ListenAddress in sshd_config?
>>
>> Yes, with the same IP as above, in order to make sure ssh isn't
>> listening on a public IP (which would be a security concern for us).
> 
> Oh, that's vital information for this bug

I'm surprised ...

> using ListenAddress changes
> the constraints on sshd startup, somewhat as described in README.Debian.

I've read it, and the only part of the README.Debian that talks about
something related, is about the removal of the if-up hook. I don't see
any startup constraint changes described there. What did I miss?

The launchpad bug entry about the ifupdown hook removal is specifically
discussing the fact that in my case, I'd be affected. Indeed, I am. I
then wonder what's advised then...

> In that case I think this is at least arguably a case of needing to keep
> your configuration in sync, isn't it?  You've made a change to
> sshd_config, so you need to change other parts of the system to support
> that change.

I'm not convinced that using a custom ListenAddress implies repairing
the boot process, no.

By default, sshd_config has this:

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

Having these commented out is an invitation to un-comment and use them
with custom values. Basically, what you wrote above is that doing this
breaks sshd. Hopefully, you'll agree that this isn't what one would
expect! :)

If that's really the case and one should do either the systemd ordering
hack I'm doing, or the net.ipv4.ip_nonlocal_bind sysctl tweak, then IMO
it'd be worse either:

1/ removing ListenAddress from the example sshd_config
2/ adding comments just above the directive, explaining what we're
discussing in this bug entry.

>> Maybe setting-up net.ipv4.ip_nonlocal_bind=1 (in sysctl.conf) would fix
>> my issue, no?
> 
> That's the system-wide version of IP_FREEBIND.  OpenSSH upstream seems
> to have decided not to support IP_FREEBIND
> (https://bugzilla.mindrot.org/show_bug.cgi?id=2512)

If I understand well what's in this bug entry, upstream seems to suggest
to do what I did:
1/ ListenAddress
2/ Add an override so that sshd starts After=network-online.target

However, it's looking like you're saying one shouldn't do 2/ at all?
Could you explain why? I've been using After=network-online.target in
most daemons I maintain, and now I'm wondering if that's wrong...
Then if I shouldn't do After=network-online.target, do you believe that
the sysctl hack is better?

> but the sysctl should work if you're OK with it being system-wide.

I'd very much prefer if this could be a per-socket thing, but I already
do this because that's how I setup haproxy that binds on a VIP (which
can move from one host to another). Though now, I wonder if there's an
option in HAProxy so it could use IP_FREEBIND on its own. Which would
then lead me to say I would prefer to not use a system-wide thing...

> I'd also recommend at least considering other approaches to implementing
> your security policy that avoid the ordering complexities of
> ListenAddress, since there are other ways to prevent incoming
> connections on public IP addresses.  Approaches I can think of include:
> 
>  * Reject connections to port 22 at the firewall level (perhaps a
>firewall on the local host).

Considering the interaction with OpenStack Neutron, this could
potentially be hard to maintain: Neutron is doing a lot of iptables
stuff on its own, and I prefer if I don't touch that at all, either on
compute nodes or network nodes. So the option to use ListenAddress
looked a way nicer for my use case.

>  * It might be worth experimenting with Match LocalAddress in
>sshd_config.  I haven't played with that much myself, and it's
>poorly-documented, but I *think* that might allow you to reject any
>connections that aren't directed to appropriate addresses.

>From my experience, it's best to not expose the ssh port at all if
possible, as brute-forcing the port may lead brokenness.

On 2/17/21 9:42 PM, Chris Hofstaedtler wrote:
> But if you do this, you'll end up delaying start of sshd for up to
> 120seconds in error cases. And even then, you might not get what you
> want (if you read systemd-networkd-wait-online.service(8)
> carefully).

This talks about networkd. Unless things have changed, I don't think
Debian is using this by default (yet?).

> Services that use After=network-online.target are generally broken,
> please do not introduce that.

Can you explain why?

> As discussed already, IP_FREEBIND is a thing.

As per the bug entry Collin pointed out, it looks like it isn't a thing
in sshd at least...

> The system-wide sysctl
> is a common workaround, especially for "bgp-on-the-host" setups, for
> all sorts of servers/daemons.

Bug#982949: Please allow libvirt-python 7.0.0 into bullseye

[Paul Gevers]

Hi Bernd,

On 17-02-2021 22:30, Bernd Zeimetz wrote:
> On Wed, 2021-02-17 at 18:37 +0100, Paul Gevers wrote:
>> libvirt-python is a key package.
> 
> and it should match libvirt. Having libvirt-python 6.x and libvirt 7.0
> is (imho, ymmv...) much worse than an completely (from us) untested
> libvirt-python.

I understood from the request that it's an option to patch 6.x. Because,
if Guido believes it really should match, than why did he file an
unblock request? We're only in the soft freeze right now, only *new*
packages are blocked and we age packages a bit more, so technically
there's nothing to unblock at this moment. Currently it's still the
maintainers call what's right for bullseye. We, as the release team, ask
for targeted fixes. If you consider this out-of-sync to be an issue of
its' own, than please, align with Guido and I have good faith that
you'll do the best in Debian interest, keeping our guidelines in the
freeze policy [1] into account. I suggest to really not wait to long,
because after the hard freeze starts, this indeed requires an unblock
from us. If the package (whichever option you choose) can migrate before
that, that would be great.

Paul

[1] https://release.debian.org/bullseye/freeze_policy.html#soft



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982671: Supporting unbound in stretch by upgrading to 1.9

[Markus Koschany]

Am Mittwoch, den 17.02.2021, 15:21 -0500 schrieb Robert Edmonds:
> Markus Koschany wrote:
[...]
> > Please feel free to reassign and/or adjust the bug report as necessary.
> 
> I get the following error message from the BTS. Do I need to do
> "reassign 982671 unbound1.9" instead?

I also got some error messages but it seems the bug reports are now reassigned
to src:unbound1.9. The errors are probably related to the fact that the source
package only and ever existed in Stretch 

> OK. I understand the src:unbound1.9 package in stretch does not support
> the Python bindings. Does LTS intend to continue supporting the embedded
> Python scripting support in the src:unbound1.9 package's daemon?

I'd prefer to not change anything of the existing src:unbound1.9 package. So if
users want to create their own python modules we don't need to remove the --
with-pythonmodule configuration option because this should not conflict with
existing packages in my opinion. But since we can't foresee all possible corner
cases, then I would say, use this feature at your own risk. Currently only the
unbound daemon as it is shipped by upstream is our main support goal.

Regards,

Markus


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

Bug#982949: Please allow libvirt-python 7.0.0 into bullseye

[Bernd Zeimetz]

Hi Paul,

On Wed, 2021-02-17 at 18:37 +0100, Paul Gevers wrote:
> libvirt-python is a key package.

and it should match libvirt. Having libvirt-python 6.x and libvirt 7.0
is (imho, ymmv...) much worse than an completely (from us) untested
libvirt-python.


Thanks,

Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#982979: kiwix-serve: symbol lookup error

[Kunal Mehta]

Hi,

On 2/17/21 10:08 AM, Von wrote:

Package: kiwix-tools
Version: 3.1.2-2
Severity: important
X-Debbugs-Cc: rekae...@outlook.com

Dear Maintainer,

kiwix-serve fails to run and throws symbol lookup error regardless
command line arguments.

kiwix-serve was not usable at all.

outcome:
 --
$ kiwix-serve /srv/Library/Zim/wikipedia_en_computer_maxi_2021-01.zim 
-p 8000
kiwix-serve: symbol lookup error: kiwix-serve: undefined symbol: 
_ZN5kiwix5splitERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES7_b

$ kiwix-serve
kiwix-serve: symbol lookup error: kiwix-serve: undefined symbol: 
_ZN5kiwix5splitERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES7_b


Thanks for reporting!

That symbol demangles to:
kiwix::split(std::__cxx11::basic_string, 
std::allocator > const&, std::__cxx11::basic_stringstd::char_traits, std::allocator > const&, bool)


It looks like 
https://github.com/kiwix/kiwix-lib/commit/08464f23bc0756fc99e2e1559f95d325f52fba87 
was an unintentional ABI break.


I'll upload a fix shortly and add a (trivial) autopkgtest to catch these 
regressions automatically in the future.


-- Kunal

Bug#982994: lintian-brush breaks silver-platter autopkgtest: cannot import name 'guess_upstream_metadata' from 'lintian_brush.upstream_metadata'

[Paul Gevers]

Source: lintian-brush, silver-platter
Control: found -1 lintian-brush/0.96
Control: found -1 silver-platter/0.4.0-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
lintian-brush  from testing0.96
silver-platter from testing0.4.0-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

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

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

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

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
lintian-brush/0.96. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=lintian-brush

https://ci.debian.net/data/autopkgtest/testing/amd64/s/silver-platter/10520217/log.gz

autopkgtest [05:11:28]: test testsuite: [---
failed to open trace file: [Errno 13] Permission denied:
'/you-should-use-TestCaseInTempDir-if-you-need-a-log-file'
.xE.../usr/lib/python3/dist-packages/breezy/transport/local.py:66:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-9770pft7.tmp/silver_platter.tests.test_publish.CheckProposalDiffGitTests.test_changes/work/proposal/.git/objects/pack/pack-f9067441426220454e5ad13206da4816a7dc1b26.idx'>
  super(LocalTransport, self).__init__(base)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/transport/local.py:66:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-9770pft7.tmp/silver_platter.tests.test_publish.CheckProposalDiffGitTests.test_indep/work/proposal/.git/objects/pack/pack-f9067441426220454e5ad13206da4816a7dc1b26.idx'>
  super(LocalTransport, self).__init__(base)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/transport/local.py:66:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-9770pft7.tmp/silver_platter.tests.test_publish.CheckProposalDiffGitTests.test_indep/work/proposal/.git/objects/pack/pack-a5b46f750283ac9120774bd37f5f4690fd133ff5.idx'>
  super(LocalTransport, self).__init__(base)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/transport/local.py:66:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-9770pft7.tmp/silver_platter.tests.test_publish.CheckProposalDiffGitTests.test_no_new_commits/work/proposal/.git/objects/pack/pack-f9067441426220454e5ad13206da4816a7dc1b26.idx'>
  super(LocalTransport, self).__init__(base)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
/usr/lib/python3/dist-packages/breezy/transport/local.py:66:
ResourceWarning: unclosed file <_io.BufferedReader
name='/tmp/testbzr-9770pft7.tmp/silver_platter.tests.test_publish.CheckProposalDiffGitTests.test_no_op_commits/work/proposal/.git/objects/pack/pack-f9067441426220454e5ad13206da4816a7dc1b26.idx'>
  super(LocalTransport, self).__init__(base)
ResourceWarning: Enable tracemalloc to get the object allocation traceback
.
==
ERROR: test_debian_upstream (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: test_debian_upstream
Traceback (most recent call last):
  File "/usr/lib/python3.9/unittest/loader.py", line 154, in
loadTestsFromName
module = __import__(module_name)
  File
"/tmp/autopkgtest-lxc.1xg43ak_/downtmp/build.7XC/src/silver_platter/tests/test_debian_upstream.py",
line 21, in 
from ..debian.upstream import (
  File
"/tmp/autopkgtest-lxc.1xg43ak_/downtmp/build.7XC/src/silver_platter/debian/upstream.py",
line 129, in 
from lintian_brush.upstream_metadata import (
ImportError: cannot import name 'guess_upstream_metadata' from
'lintian_brush.upstream_metadata'
(/usr/lib/python3/dist-packages/lintian_brush/upstream_metadata.py)


--
Ran 43 tests in 3.141s

FAILED 

Bug#982987: tech-ctte: Call for votes for new CTTE member

[Elana Hashman]

On Wed, Feb 17, 2021 at 12:45:05PM -0600, Gunnar Wolf wrote:
> ===BEGIN
> 
> The Technical Committee recommends that Christoph Berg  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> A: Recommend to appoint Christoph Berg 
> B: Further Discussion
> 
> ===END

I have not worked with or interacted with Christoph. Hence, I abstain
from voting.

- e


signature.asc
Description: PGP signature

Bug#982993: python-aiohttp breaks python-molotov autopkgtest: result changed

[Paul Gevers]

Source: python-aiohttp, python-molotov
Control: found -1 python-aiohttp/3.7.3-1
Control: found -1 python-molotov/2.1-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
python-aiohttp from testing3.7.3-1
python-molotov from testing2.1-1
all others from testingfrom testing

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

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

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

Paul

[1] https://qa.debian.org/excuses.php?package=python-aiohttp

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-molotov/10531551/log.gz

=== FAILURES
===
 TestRunner.test_delay
_

self = 

@dedicatedloop
def test_delay(self):
with catch_sleep() as delay:

@scenario(weight=10, delay=0.1)
async def here_three(session):
_RES.append(3)

stdout, stderr, rc = self._test_molotov(
"--delay",
".6",
"--console-update",
"0",
"-cx",
"--max-runs",
"2",
"-s",
"here_three",
"molotov.tests.test_run",
)
wanted = "SUCCESSES: 2"
self.assertTrue(wanted in stdout, stdout)
>   self.assertEqual(delay, [1, 0.1, 1, 0.6, 1, 0.1, 1, 0.6, 1])
E   AssertionError: Lists differ: [1, 0.1, 1, 0.6, 1, 0.1, 1,
0.6, 1, 1] != [1, 0.1, 1, 0.6, 1, 0.1, 1, 0.6, 1]
E
E   First list contains 1 additional elements.
E   First extra element 9:
E   1
E
E   - [1, 0.1, 1, 0.6, 1, 0.1, 1, 0.6, 1, 1]
E   ?  ---
E
E   + [1, 0.1, 1, 0.6, 1, 0.1, 1, 0.6, 1]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982924: what-is-python: The python-is-python3 and python-dev-is-python3 packages should not exist

[Zack Weinberg]

On Wed, Feb 17, 2021 at 3:17 PM Dimitri John Ledkov
 wrote:
> In Bullseye release file:/usr/bin/python is not reserved, but
> intentionally unused.

That is not good enough.  It needs to be reserved.

> In Bullseye release neither deb:python2 nor deb:python3 packages own
> /usr/bin/python.

Yes, I know.  That's fine as long as there is not, **and never will
be**, any package within Debian that creates /usr/bin/python as
anything other than a link to python2.  The existence of the
python-is-python3 package breaks this constraint.

> No packages in Bullseye may depend, or build-depend on neither
> deb:python, nor deb:python-is-python* packages.

That is not good enough.  The existence of the python-is-python3
package means that there can exist Debian installations in which
/usr/bin/python executes python3, breaking **unpackaged** software.
Hence the bug report.

(A sysadmin could of course `ln -s python3 /usr/bin/python`
themselves, but then that would be their error, not a bug in Debian.)

> Thus it is a leaf package without any dependencies. By definition not
> impacting any unrelated software.

I am concerned with this package's effect on **unpackaged** software
written by end-users and present on existing Debian systems.  I hope
you will understand that "unrelated software" does not just mean
software within Debian.

zw

Bug#982992: node-regjsparser breaks node-regexpu-core autopkgtest: Missing expected exception (Error).

[Paul Gevers]

Source: node-regjsparser, node-regexpu-core
Control: found -1 node-regjsparser/0.6.6+ds-1
Control: found -1 node-regexpu-core/4.7.1-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

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

   passfail
node-regjsparser   from testing0.6.6+ds-1
node-regexpu-core  from testing4.7.1-1
all others from testingfrom testing

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

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

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

Paul

[1] https://qa.debian.org/excuses.php?package=node-regjsparser

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-regexpu-core/10530585/log.gz

  718 passing (816ms)
  1 failing

  1) unicodePropertyEscapes
   throws without the `u` flag:
 AssertionError [ERR_ASSERTION]: Missing expected exception (Error).
  at Context. (tests/tests.js:592:10)
  at callFn (/usr/share/nodejs/mocha/lib/runnable.js:364:21)
  at Test.Runnable.run (/usr/share/nodejs/mocha/lib/runnable.js:352:5)
  at Runner.runTest (/usr/share/nodejs/mocha/lib/runner.js:677:10)
  at /usr/share/nodejs/mocha/lib/runner.js:801:12
  at next (/usr/share/nodejs/mocha/lib/runner.js:594:14)
  at /usr/share/nodejs/mocha/lib/runner.js:604:7
  at next (/usr/share/nodejs/mocha/lib/runner.js:486:14)
  at Immediate._onImmediate
(/usr/share/nodejs/mocha/lib/runner.js:572:5)
  at processImmediate (internal/timers.js:461:21)



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977990: os-autoinst: FTBFS on i386: 3/3 Test #3: test-perl-testsuite ..............***Failed 332.81 sec

[Paul Gevers]

Hi Frédéric,

On 15-02-2021 10:39, Frédéric Bonnard wrote:
> indeed Paul, the test is flaky, probably a timing issue. I had already
> changed some related parameter that made the tests pass reliably on
> my i386 builder, but saw afterward that it still failed on debian's
> builder and couldn't reproduce it :
> https://salsa.debian.org/debian/os-autoinst/-/commit/38b2f4aefafbdf7ab59ce223ef208c540409a001
> I guess, we could increase CI related timeouts here and there but that's
> what I tried to avoid when changing CI variable, and I was happy to see
> things work.. but not on all i386 builders :)
> May we close that bug for now ?
If the forth time worked because of sheer luck, then please no, keep the
bug open until the build is less flaky. We need packages to be build
without failure [1]. Having to baby-sit flaky is not really an option as
there are too many packages in the Debian archive.

Also, your commit message suggests that the upstream change that's
needed isn't in Debian yet?

Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982991: matrix-synapse: not suitable for inclusion into bullseye

[Andrej Shadura]

Package: src:matrix-synapse
Severity: normal
Tags: upstream
X-Debbugs-Cc: Dan Callahan , t...@security.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

As has been discussed with the upstream and the security team, it’s best
to not include Synapse in stable releases just yet. It was originally
included in Buster, but as freeze happened just a few months before
the release of 1.0, Buster ended up with a version missing important
code updates and it had to be removed when backporting security fixes
was proven to be infeasible (see #959723).

Dan Callahan of Element writes:

> Unfortunately, I expect an even greater rate of code churn and security
> fixes throughout 2021, and my team does not currently have the capacity
> to assist with backporting fixes, nor to maintain a long-lived stable
> branch. I've mentioned my concerns to the package maintainer, but I'm
> concerned that he may be overly optimistic and we'll find ourselves
> repeating the pain of removing matrix-synapse from a Debian release.

> Shipping software with known vulnerabilities in stable harms users
> and places their servers at risk. Pulling a package from the archive
> inconveniences users, creates work for the release managers, and reflects
> poorly on the packaged software.

The security team also agreed and pointed out #959723 was something that
shouldn’t be repeated.

This bug will be raised in severity to "serious" when Bullseye freezes
completely, which will likely to happen in April. Before that, keeping
it at a lower severity should enable backports to Buster.

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQSD3NF/RLIsyDZW7aHoRGtKyMdyYQUCYC2DLQAKCRDoRGtKyMdy
YcE0AP40cBSFlfN5Jygc1uRWvLpVzMWMtcTZ1s5n3XoFEkn+UAD/fwmeoBZtuKrU
VK7FZkaSaX3nL7XvVWEhWrGAG+5j9wE=
=jPGI
-END PGP SIGNATURE-

Bug#982988: footnotehyper: crashes with "Too many }'s."

[Norbert Preining]

Hi 

> https://ctan.org/ctan-ann/id/mailman.3887.1612536880.2532.ctan-...@ctan.org

Thanks, reproduced. I cherry-picked the upstream fixed to texlive-base -3
and uploaded it just now. Should be in sid in short time, and testing in
10 days.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Fujitsu Research Labs  +  IFMGA Guide + TU Wien + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#982950: ssh.service starts sshd before network is online: please switch to After=network-online.target instead of just After=network.target

[Chris Hofstaedtler]

* Thomas Goirand  [210217 20:38]:
> # cat /etc/systemd/system/ssh.service.d/override.conf 
> [Unit]
> After=network-online.target auditd.service
> 
> But IMO, this is very wrong to mandate doing this, and not having ssh
> connectivity after a reboot, is kind of a grave problem.
> 
> So, could you hard-wire this in the openssh-server package directly, so Debian
> users can avoid such an override? Indeed After=network.target doesn't tell you
> that network is ready. After=network-online.target does, and that's IMO what
> the ssh daemon should be using.

But if you do this, you'll end up delaying start of sshd for up to
120seconds in error cases. And even then, you might not get what you
want (if you read systemd-networkd-wait-online.service(8)
carefully).

Services that use After=network-online.target are generally broken,
please do not introduce that.

As discussed already, IP_FREEBIND is a thing. The system-wide sysctl
is a common workaround, especially for "bgp-on-the-host" setups, for
all sorts of servers/daemons.

Chris

Bug#982894: How to reproduce

[Johannes Weißl]

Sorry for the spelling in my original mail, I was too tired.

Here is how you can reproduce the bug:

root@ec2-instance:~# cat /etc/resolv.conf
domain eu-central-1.compute.internal
search eu-central-1.compute.internal
nameserver 172.31.0.2
root@ec2-instance:~# fallocate -l 1TB /etc/bigfile
fallocate: fallocate failed: No space left on device
root@ec2-instance:~# dhclient
RTNETLINK answers: File exists
/sbin/dhclient-script: 54: echo: echo: I/O error
/sbin/dhclient-script: 72: echo: echo: I/O error
/sbin/dhclient-script: 77: echo: echo: I/O error
root@ec2-instance:~# cat /etc/resolv.conf
root@ec2-instance:~# rm /etc/bigfile

With my patch, dhclient leaves the valid /etc/resolv.conf unmodified instead of 
making it empty / corrupt.

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=211261 for a similar 
problem with dhcp3-client.

Bug#982990: btrfs-progs: "btrfs device add" fails adding logical volume (LVM)

[Leonardo]

Package: btrfs-progs
Version: 5.10.1-1

Kernel version: 5.10.0-3-amd64
Steps to recreate:
Create two volume groups: i.e. enuoda-blu, enuoda-red
Create two logical volumes: i.e. enuoda-blu/lvol0, enuoda-red/lvol0
Create a btrfs filesystem on one logical volume and mount it:
# mkfs.btrfs /dev/mapper/enuoda--blu-lvol0
# mount /dev/mapper/enuoda--blu-lvol0 /mnt/enuoda

Then try to add the second volume and fails:
# btrfs device add -f /dev/mapper/enuoda-red-lvol0 /mnt/enuoda
ERROR: error adding device 'dm-4': No such file or directory
^^^ HERE IT IS ^^^
No output in dmesg.
(tested on raspberrypi with buster (kernel 5.10.11-v7+
btrfs-progs:5.10-1~bpo10+1), works flawlessly)
Same results if the two logical volumes are in the same volume group.

Instead, directly creating a btrfs filesystem over two logical volumes
works fine:
# mkfs.btrfs -f /dev/mapper/enuoda--blu-lvol0 /dev/mapper/enuoda--red-lvol0
btrfs-progs v5.10.1
See http://btrfs.wiki.kernel.org for more information.

Label:  (null)
UUID:   c5c64454-d05b-4ed2-b644-6ef84b87561b
Node size:  16384
Sector size:4096
Filesystem size:20.00GiB
Block group profiles:
  Data: single8.00MiB
  Metadata: RAID1   256.00MiB
  System:   RAID1 8.00MiB
SSD detected:   no
Incompat features:  extref, skinny-metadata
Runtime features:
Checksum:   crc32c
Number of devices:  2
Devices:
   IDSIZE  PATH
110.00GiB  /dev/mapper/enuoda--blu-lvol0
210.00GiB  /dev/mapper/enuoda--red-lvol0

Bug#982671: Supporting unbound in stretch by upgrading to 1.9

[Robert Edmonds]

Markus Koschany wrote:
> Hello,
> 
> Am Mittwoch, den 17.02.2021, 14:09 -0500 schrieb Robert Edmonds:
> > Hi,
> > 
> > #982671 / #982672 is incorrectly reported against the python-unbound
> > package. It should instead be against the unbound binary package because
> > this functionality is in the unbound daemon.
> 
> Please feel free to reassign and/or adjust the bug report as necessary.

I get the following error message from the BTS. Do I need to do
"reassign 982671 unbound1.9" instead?

> reassign 982671 unbound 1.9.0-2+deb10u2~deb9u1
Bug #982671 [python-unbound] python-unbound: unbound doesn't start with 
python module enabled
Bug #982672 [python-unbound] python-unbound: unbound doesn't start with 
python module enabled
Bug reassigned from package 'python-unbound' to 'unbound'.
Bug reassigned from package 'python-unbound' to 'unbound'.
No longer marked as found in versions unbound1.9/1.9.0-2+deb10u2~deb9u1.
No longer marked as found in versions unbound1.9/1.9.0-2+deb10u2~deb9u1.
Ignoring request to alter fixed versions of bug #982671 to the same values 
previously set
Ignoring request to alter fixed versions of bug #982672 to the same values 
previously set
Bug #982671 [unbound] python-unbound: unbound doesn't start with python 
module enabled
Bug #982672 [unbound] python-unbound: unbound doesn't start with python 
module enabled
There is no source info for the package 'unbound' at version 
'1.9.0-2+deb10u2~deb9u1' with architecture ''
--> Unable to make a source version for version '1.9.0-2+deb10u2~deb9u1'
Marked as found in versions 1.9.0-2+deb10u2~deb9u1.
Marked as found in versions 1.9.0-2+deb10u2~deb9u1.
> thanks

> We don't intend to build the python bindings for unbound1.9. This decision was
> intentional, so here are the alternatives. 
> 
> 1. Don't upgrade unbound 1.6 if you are sure, you are not affected by the
>existing security vulnerabilities.
> 
> 2. I could remove the configure option --with-pyunbound and announce this with
> a new DLA, this would it make explicit that the python bindings are not
> supported.
> 
> However the end result will always be the same. You can't use the existing
> python bindings with the 1.9 version.
> 
> Regards,
> 
> Markus

OK. I understand the src:unbound1.9 package in stretch does not support
the Python bindings. Does LTS intend to continue supporting the embedded
Python scripting support in the src:unbound1.9 package's daemon?

-- 
Robert Edmonds
edmo...@debian.org

Bug#982924: what-is-python: The python-is-python3 and python-dev-is-python3 packages should not exist

[Dimitri John Ledkov]

In Bullseye release file:/usr/bin/python is not reserved, but
intentionally unused.
In Bullseye release neither deb:python2 nor deb:python3 packages own
/usr/bin/python.
This is a Bullseye Release Goal with consensus from all
cpythons/pypys/etc interpreter maintainers, modules maintainers, and
app maintainers.
Specifically cpython2.7 is still around to allow for re-bootstrapping
of pypy* ecosystem on existing or new architectures.
No packages in Bullseye may depend, or build-depend on neither
deb:python, nor deb:python-is-python* packages.
Thus it is a leaf package without any dependencies. By definition not
impacting any unrelated software.
It is intended for this package, and all of its binaries to be removed
in some future Debian release after the next one.
I hope you notice the irony in the package name src:what-is-python, it
is meant for local admins to deploy as compatibility with their
respective venvs and other estates only.
It is intended for nobody to use "/usr/bin/python" outside of venv for
now. And for them to change their scripts to use either python3 or
python2 explicitly.

I want to say this bug report is "bullseye-ignore" or "wontfix".

Bug#982987: tech-ctte: Call for votes for new CTTE member

[Simon McVittie]

On Wed, 17 Feb 2021 at 12:45:05 -0600, Gunnar Wolf wrote:
> ===BEGIN
> 
> The Technical Committee recommends that Christoph Berg  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> A: Recommend to appoint Christoph Berg 
> B: Further Discussion
> 
> ===END

I vote A > B.

smcv

Bug#982989: codonw FTCBFS: Multiple reasons

[Nilesh Patra]

Source: codonw
Version: 1.4.4-5
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
X-Debbugs-CC: debian-cr...@lists.debian.org

Hi,

codonw fails to cross build due to two reasons:

    * It hardcodes $(MAKE) in d/rules. This is virtually useless since after 
the hardening.patch applied, the only rules for "all" in "codonw" itself. So 
the override_dh_auto_build can simply be dropped
   Patch for the same is given below
    * It uses help2man for manpage, best way forward here would be to use 
maintainer manual page with the createmanpages script[1] that several 
debian-med packages use and not use help2man during build time.

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

diff --git a/debian/rules b/debian/rules
index 59082e0..7a81398 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,9 +13,6 @@ override_dh_clean:
 override_dh_auto_clean:
 rm -rf *.o *.coa *.blk *.out *raw codonw codonW.log
 
-override_dh_auto_build:
-    $(MAKE) codonw
-
 override_dh_installdocs:
 mkdir -p debian/codonw/usr/share/doc/codonw
 cp *.txt debian/codonw/usr/share/doc/codonw

Bug#982988: footnotehyper: crashes with "Too many }'s."

[Louis-Philippe Véronneau]

Package: texlive-latex-recommended
Version: 2020.20210202-2
Severity: important

Dear maintainers,

While working on a document with pandoc that uses a latex template, I
hit this error:

https://github.com/Wandmalfarbe/pandoc-latex-template/issues/226

It seems the problem is caused by an error in `footnotehyper` that was
fixed a few weeks ago:

https://ctan.org/ctan-ann/id/mailman.3887.1612536880.2532.ctan-...@ctan.org

You should be able to reproduce the error I'm getting using these steps:

$ wget
https://raw.githubusercontent.com/Wandmalfarbe/pandoc-latex-template/master/eisvogel.tex

$ printf '\n---\ntitle: foo\ntables: true\n...\n\n#Foosbar\n' > foo.md

$ pandoc foo.md -o foo.pdf --template eisvogel.tex

> Error producing PDF.
! Too many }'s.
\FNH@check@a ...tnotes \expandafter \@gobble \fi }
  {}}\@secondoftwo
\scantoke...
l.286 \begin{document}

Apparently the problem is fixed when using the latest footnotehyper
version (1.1d, Debian currently has 1.1c), but I haven't tested that myself.

I'm unfamiliar with this package, so I'm not sure the severity is the
right one. All I know is that the current version of footnotehyper
breaks my current setup and I have to disable features to be able to
build again.

Thanks for maintaining this package.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄

Bug#982671: Supporting unbound in stretch by upgrading to 1.9

[Markus Koschany]

Hello,

Am Mittwoch, den 17.02.2021, 14:09 -0500 schrieb Robert Edmonds:
> Hi,
> 
> #982671 / #982672 is incorrectly reported against the python-unbound
> package. It should instead be against the unbound binary package because
> this functionality is in the unbound daemon.

Please feel free to reassign and/or adjust the bug report as necessary.


>  The error message cited in
> the original report is an error message generated by the unbound daemon:
> 
> [123376:0] error: module init for module python failed
> 
> Based on the original report this failure occurred after the bug
> reporter upgraded to src:unbound1.9's unbound package in oldstable.
> 
> The embedded Python scripting support is in the unbound daemon and
> enabled by the the '--with-pythonmodule' parameter to the unbound
> configure script. It results in this dependency in the built unbound
> package:
> 
> $ dpkg-deb -I unbound_1.9.0-2+deb10u2~deb9u1_amd64.deb | grep '^ Depends:'
>  Depends: adduser, dns-root-data, lsb-base (>= 3.0-6), openssl,
>  unbound-anchor, init-system-helpers (>= 1.18~), libc6 (>= 2.17),
>  libevent-2.0-5 (>= 2.0.10-stable), libfstrm0 (>= 0.2.0), libprotobuf-c1
>  vv
>  (>= 1.0.1), libpython3.5 (>= 3.5.0~b1), libssl1.1 (>= 1.1.0),
>  ^^
>  libsystemd0
> 
> The python{3,}-unbound packages implement the Python extension module
> bindings for the C libunbound library. The Python extension module is
> enabled by the '--with-pyunbound' parameter to the unbound configure
> script.

We don't intend to build the python bindings for unbound1.9. This decision was
intentional, so here are the alternatives. 

1. Don't upgrade unbound 1.6 if you are sure, you are not affected by the
   existing security vulnerabilities.

2. I could remove the configure option --with-pyunbound and announce this with
a new DLA, this would it make explicit that the python bindings are not
supported.

However the end result will always be the same. You can't use the existing
python bindings with the 1.9 version.

Regards,

Markus




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

Bug#982671: Supporting unbound in stretch by upgrading to 1.9

[Robert Edmonds]

Markus Koschany wrote:
> Hi,
> 
> Am Mittwoch, den 17.02.2021, 12:43 -0500 schrieb Robert Edmonds:
> [...]
> > Hi,
> > 
> > It looks like #982671 / #982672 was assigned by the BTS to src:unbound
> > rather than src:unbound1.9. I attempted to re-assign the bug to
> > src:unbound1.9 with notfound/found but I don't think that worked since I
> > don't see it on
> > https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=unbound1.9.
> > 
> > This bug also should have been reported against the unbound binary
> > package built by src:unbound1.9, not python-unbound, because the bug
> > appears to be about src:unbound1.9's unbound daemon failing to start. My
> > understanding is that the embedded Python scripting support in the
> > unbound daemon (which is built on stretch against Python 3, not Python 2
> > anyway) does not require the python-unbound or python3-unbound packages,
> > which are unrelated Python extension module bindings for the APIs in the
> > C libunbound library.
> > 
> > Also, it looks like the upload of unbound1.9 1.9.0-2+deb10u2~deb9u1
> > dropped the python-unbound and python3-unbound binary packages. It's not
> > clear why and it would be nice if the reason were documented in
> > debian/changelog.
> > 
> 
> python{3}-unbound is no longer supported in Stretch. See also DSA-4694-1. [1] 
> We only support the unbound daemon, unbound-host, unbound-anchor and
> libunbound8. Since unbound does not require the python bindings, both packages
> were dropped from src:unbound1.9. I suggest to mark this bug as wontfix.
> 
> Regards,
> 
> Markus
> 
> [1] https://lists.debian.org/debian-security-announce/2020/msg00098.html

Hi,

#982671 / #982672 is incorrectly reported against the python-unbound
package. It should instead be against the unbound binary package because
this functionality is in the unbound daemon. The error message cited in
the original report is an error message generated by the unbound daemon:

[123376:0] error: module init for module python failed

Based on the original report this failure occurred after the bug
reporter upgraded to src:unbound1.9's unbound package in oldstable.

The embedded Python scripting support is in the unbound daemon and
enabled by the the '--with-pythonmodule' parameter to the unbound
configure script. It results in this dependency in the built unbound
package:

$ dpkg-deb -I unbound_1.9.0-2+deb10u2~deb9u1_amd64.deb | grep '^ Depends:'
 Depends: adduser, dns-root-data, lsb-base (>= 3.0-6), openssl,
 unbound-anchor, init-system-helpers (>= 1.18~), libc6 (>= 2.17),
 libevent-2.0-5 (>= 2.0.10-stable), libfstrm0 (>= 0.2.0), libprotobuf-c1
 vv
 (>= 1.0.1), libpython3.5 (>= 3.5.0~b1), libssl1.1 (>= 1.1.0),
 ^^
 libsystemd0

The python{3,}-unbound packages implement the Python extension module
bindings for the C libunbound library. The Python extension module is
enabled by the '--with-pyunbound' parameter to the unbound configure
script.

-- 
Robert Edmonds
edmo...@debian.org

Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

[Elana Hashman]

Hi Niels,

Most of the arguments in this and previous bugs are anecdotal. It would
be helpful to provide a concrete analysis of the disk space savings that
compression provides, and whether it is a reasonable default.

There is a discussion about KDE debug symbols requiring 10Gi of disk
space a decade ago, but not what the original compressed size was, for
example...

Would you be able to research some representative slice of popular
packages that would be affected by the policy change (at least 10) and
share the on-disk sizes with compression vs. without?

Personally, I think if there is not much difference in size, it would
make sense to not compress as the default. If there are orders of
magnitude in difference, the status quo probably still makes sense, as
it does provide benefits.


Matthias,

You and the original report mention "tooling issues". Can you please
provide some examples of tools that do not currently support working
with compressed symbols and the resulting effects on developer workflow?

Thanks,

- e


signature.asc
Description: PGP signature

Bug#982678: systemd: journalctl does not repect SYSTEMD_COLORS=0 - colors are still shown

[Brian Potkin]

On Tue 16 Feb 2021 at 13:44:37 +0200, Jari Aalto wrote:

> On 2021-02-15 21:01, Brian Potkin wrote:
> > On Sat 13 Feb 2021 at 15:43:12 +0200, Jari Aalto wrote:
> > 
> > > It's Debian mainter's job to forward bugs to upstream.
> > 
> > If there are jobs to apportion out, yours is to assist a
> > maintainer, especially one as assiduous in their *volunteer*
> > work as Michael Biebl, in every possible way.
> > 
> > So - get on with it. Push the issue upstream. You'll feel
> > better for it and be awarded points :).
> 
> The maintainer of the Debian package is primarily responsible for all
> work related to packages. This includes packaging, getting neew
> versions, keeping in contact with the upstream, forwarding bugs,
> following bugs and marking bugs accordingly in the BTS.
> 
> See the Debian maintainer's manual and links in previous messages for
> the rationale of the Debian Maintainer's duties.

You were being requested to lighten the burden on a maintainer of
systemd. Are you familiar with the word "jobsworth"?

-- 
Brian.

Bug#982987: tech-ctte: Call for votes for new CTTE member

[Gunnar Wolf]

Gunnar Wolf dijo [Wed, Feb 17, 2021 at 12:45:05PM -0600]:
> ===BEGIN
> 
> The Technical Committee recommends that Christoph Berg  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> A: Recommend to appoint Christoph Berg 
> B: Further Discussion
> 
> ===END

I vote:

A > B


signature.asc
Description: PGP signature

Bug#982970: offlineimap3: broken folderincludes config option

[Sudip Mukherjee]

Hi Santiago,

On Wed, Feb 17, 2021 at 2:30 PM Santiago Ruano Rincón
 wrote:
>
> Package: offlineimap3
> Version: 0.0~git20210105.00d395b+dfsg-3
> Severity: normal
> Tags: upstream
>
> Dear Sudip,
>
> offlineimap3 is not able to handle the folderincludes config, that
> worked with offlineimap. I got this when trying to sync (tested with two
> different accounts):
>
>   'str' object has no attribute 'decode'

Can you please test with the PR at
https://github.com/OfflineIMAP/offlineimap3/pull/47/ and check if it
fixes your issue..
I could reproduce the problem in my setup and the above PR fixes the
problem for me. I have not tested enough to know if it breaks
something else.


-- 
Regards
Sudip

Bug#982903: gitlab: Internal error caused by missing gitaly-git2go binary

[Pirate Praveen]

On 2021, ഫെബ്രുവരി 17 8:27:19 PM IST, Pirate Praveen  
wrote:
>
>From what I understood from the logs, the error is coming from golang-git2go 
>and not from gitaly.
>

I got gitaly-git2go built but it is not yet ready for an upload.

1. gitaly 13.7 worked but not 13.6
2. Used snapshot.debian.org for git2go 1.0
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#982987: tech-ctte: Call for votes for new CTTE member

[Gunnar Wolf]

Package: tech-ctte
Severity: normal

Given that Philip Hands' term in the Technical Committee finished in
December, I want first of all to thank him on behalf ot the rest of
the Committee members for his good work during the term, and call for
votes to accept a new TC member.

So, voting will begin now, and end when the outcome is no longer in
doubt, or one week from now.

===BEGIN

The Technical Committee recommends that Christoph Berg  be
appointed by the Debian Project Leader to the Technical Committee.

A: Recommend to appoint Christoph Berg 
B: Further Discussion

===END


signature.asc
Description: PGP signature

Bug#982671: Supporting unbound in stretch by upgrading to 1.9

[Markus Koschany]

Hi,

Am Mittwoch, den 17.02.2021, 12:43 -0500 schrieb Robert Edmonds:
[...]
> Hi,
> 
> It looks like #982671 / #982672 was assigned by the BTS to src:unbound
> rather than src:unbound1.9. I attempted to re-assign the bug to
> src:unbound1.9 with notfound/found but I don't think that worked since I
> don't see it on
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=unbound1.9.
> 
> This bug also should have been reported against the unbound binary
> package built by src:unbound1.9, not python-unbound, because the bug
> appears to be about src:unbound1.9's unbound daemon failing to start. My
> understanding is that the embedded Python scripting support in the
> unbound daemon (which is built on stretch against Python 3, not Python 2
> anyway) does not require the python-unbound or python3-unbound packages,
> which are unrelated Python extension module bindings for the APIs in the
> C libunbound library.
> 
> Also, it looks like the upload of unbound1.9 1.9.0-2+deb10u2~deb9u1
> dropped the python-unbound and python3-unbound binary packages. It's not
> clear why and it would be nice if the reason were documented in
> debian/changelog.
> 

python{3}-unbound is no longer supported in Stretch. See also DSA-4694-1. [1] 
We only support the unbound daemon, unbound-host, unbound-anchor and
libunbound8. Since unbound does not require the python bindings, both packages
were dropped from src:unbound1.9. I suggest to mark this bug as wontfix.

Regards,

Markus

[1] https://lists.debian.org/debian-security-announce/2020/msg00098.html


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

Bug#982986: RFP: pure-maps -- full-featured map and navigation application

[Martin]

Package: wnpp
Severity: wishlist

* Package name: pure-maps
  Version : 2.5.0
  Upstream Author : Osmo Salomaa , Rinigus 

* URL : https://github.com/rinigus/pure-maps
* License : GPL-3+
  Programming Lang: C++
  Description : full-featured map and navigation application

Pure Maps is an application for Sailfish OS and Linux to display
vector and raster maps, places, routes, and provide navigation
instructions with a flexible selection of data and service
providers.

Supported platforms:
 - Kirigami: FLAVOR=kirigami
 - QtControls: FLAVOR=qtcontrols
 - Sailfish: FLAVOR=silica
 - Ubuntu Touch: FLAVOR=uuitk

Bug#960153: ca-certificates-java: Failed to install ca-certificates-java on Beagle Bone Black

[Paul Gevers]

control: reassign -1 openjdk-11-jre-headless 11.0.7+10-3~deb10u1
control: severity -1 serious

On Sun, 7 Feb 2021 19:24:46 +0100 Chris Hofstaedtler 
wrote:
> * Robert Nelson  [210207 18:23]:
> > I fixed this locally in our BeagleBoard.org Debian Repo with this quick 
> > patch:
> 
> > -java -Xmx64m -jar $JAR -storepass "$storepass"
> > +java -Xmx64m -XX:-AssumeMP -jar $JAR -storepass "$storepass"
> 
> If this helps, someone please explain why this is not a bug in the
> used JRE/JDK?
> I fail to see how this is a bug in ca-certificates-java.

So, then let's reassign to openjdk-11-jre-headless to ask for the
maintainers opinion.

Also, it would be great if it could be confirmed to still happen in
bullseye. Robert, are you in the position to do that?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#953289: ABI change in libsoxr 0.1.3

[Max Kellermann]

On 2021/02/17 18:58, Sebastian Ramacher  wrote:
> I've now reread the upstream bug report once again, and it appears as if
> mpd is missing a call to soxr_clear before reusing a context. Hence,
> I'm reassigning this bug to mpd.

That's not correct.  soxr_clear() was not documented to be necessary.
It still is not documented that way.  An undocumented internal change
made it effectively necessary.  That is what my bug report is about.

Max

Bug#982984: Mirror blocked due to repeated errors

[Russ Allbery]

Package: apt-cacher-ng
Version: 3.6-1
Severity: normal

I have a fairly generic apt-cacher-ng configuration that I use for
sbuild.  (The only configuration I've changed is to add BindAddress:
localhost and change the Debian backend to https://deb.debian.org/debian/)
Relatively recently I've noticed sbuild update failing with some
regularity with the following error:

source:buster-i386-sbuild: Performing update.
Err:1 http://localhost:3142/debian buster InRelease
  502  Mirror blocked due to repeated errors [IP: ::1 3142]

Restarting apt-cacher-ng clears up this problem and then sbuild update
works as normal.  This might (or might not; it happens a few minutes
earlier than this error) be correlated with the following error message:

Feb 17 09:17:16 gwaihir apt-cacher-ng[833]: [warn] Call to getaddrinfo_async 
with no evdns_base configured.
Feb 17 09:17:19 gwaihir apt-cacher-ng[833]: [warn] Call to getaddrinfo_async 
with no evdns_base configured.
Feb 17 09:17:21 gwaihir apt-cacher-ng[833]: [warn] Call to getaddrinfo_async 
with no evdns_base configured.

It's more strongly correlated with this error that's logged in
/var/log/apt-cacher-ng/apt-cacher.err:

Mon Feb 15 09:19:50 2021|Failure to create replacement of 
debrep/dists/stretch/InRelease - CHECK FOLDER PERMISSIONS!
Mon Feb 15 09:19:50 2021|Failure to create replacement of 
debrep/dists/stretch/Release - CHECK FOLDER PERMISSIONS!

There doesn't seem to be anything odd about the permissions of those
directories under /var/cache/apt-cacher-ng.  They're all owned by
apt-cacher-ng:apt-cacher-ng and are mode 2755.

Probably related, temporary working files seem to be left behind in
/var/cache/apt-cacher-ng/debrep/dists sometimes (but not for every
occurence of this error):

buster:
InRelease  InRelease.head  InRelease1613585303  contrib/  main/  non-free/

sid:
InRelease  InRelease.head  contrib/  main/  non-free/

These files, when they appear, are zero-length.

-- Package-specific info:

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

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

Versions of packages apt-cacher-ng depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.74
ii  dpkg 1.20.7.1
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-9
ii  libevent-2.1-7   2.1.12-stable-1
ii  libevent-pthreads-2.1-7  2.1.12-stable-1
ii  libgcc-s110.2.1-6
ii  liblzma5 5.2.5-1.0
ii  libssl1.11.1.1i-3
ii  libstdc++6   10.2.1-6
ii  libsystemd0  247.3-1
ii  libwrap0 7.6.q-31
ii  lsb-base 11.1.0
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages apt-cacher-ng recommends:
ii  ca-certificates  20210119

Versions of packages apt-cacher-ng suggests:
pn  avahi-daemon  
pn  doc-base  
ii  libfuse2  2.9.9-3

-- Configuration Files:
/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
'/etc/apt-cacher-ng/security.conf'

-- debconf information:
  apt-cacher-ng/cachedir: keep
  apt-cacher-ng/proxy: keep
  apt-cacher-ng/port: keep
  apt-cacher-ng/bindaddress: keep
* apt-cacher-ng/tunnelenable: false
  apt-cacher-ng/gentargetmode: No automated setup

Bug#982983: spyder: Needs to add a dependency on python3-xdg

[Alejandro Ramon Ballesta]

Package: spyder
Version: 4.2.1+dfsg1-1
Severity: important

Dear Maintainer,

Trying to launch spyder fails with the error "The 'pyxdg>=0.26'
distribution was not found and is required by spyder". Installing the 
python3-xdg package solves the issue.


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (990, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages spyder depends on:
ii  ipython37.20.0-1
ii  python3 3.9.1-1
ii  python3-spyder  4.2.1+dfsg1-1

spyder recommends no packages.

spyder suggests no packages.

Versions of packages python3-spyder depends on:
ii  libjs-jquery  3.5.1+dfsg+~3.5.5-7
ii  libjs-mathjax 2.7.9+dfsg-1
ii  pylint2.6.0-1
ii  python3   3.9.1-1
ii  python3-atomicwrites  1.4.0-2
ii  python3-chardet   4.0.0-1
ii  python3-cloudpickle   1.6.0-1
ii  python3-diff-match-patch  20200713-1
ii  python3-intervaltree  3.0.2-1.1
ii  python3-ipython   7.20.0-1
ii  python3-jedi  0.18.0-1
ii  python3-jsonschema3.2.0-3
ii  python3-keyring   22.0.1-1
ii  python3-nbconvert 5.6.1-2
ii  python3-numpydoc  1.1.0-3
ii  python3-parso 0.8.1-1
ii  python3-pexpect   4.8.0-1
ii  python3-pickleshare   0.7.5-3
ii  python3-pkg-resources 52.0.0-1
ii  python3-psutil5.8.0-1
ii  python3-pygments  2.7.1+dfsg-1
ii  python3-pyls  0.36.2-3
ii  python3-pyls-black0.4.6-3
ii  python3-pyls-spyder   0.3.0-3
ii  python3-qdarkstyle2.8.1+ds1-2
ii  python3-qtawesome 1.0.2-1
ii  python3-qtconsole 5.0.2-2
ii  python3-qtpy  1.9.0-3
ii  python3-sphinx3.4.3-1
ii  python3-spyder-kernels1.10.1-2
ii  python3-textdistance  4.2.0-2
ii  python3-three-merge   0.1.1-2
ii  python3-watchdog  1.0.2-2
ii  python3-zmq   20.0.0-1+b1
ii  spyder-common 4.2.1+dfsg1-1

Versions of packages python3-spyder suggests:
pn  cython3 
ii  python3-matplotlib  3.3.4-1
ii  python3-numpy   1:1.19.5-1
pn  python3-pandas  
ii  python3-pil 8.1.0-1
ii  python3-scipy   1.6.0-2
pn  python3-sympy   

Versions of packages python3-pyqt5 depends on:
ii  libc6 2.31-9
ii  libgcc-s1 10.2.1-6
ii  libpython3.9  3.9.1-4
ii  libqt5core5a [qtbase-abi-5-15-2]  5.15.2+dfsg-4
ii  libqt5dbus5   5.15.2+dfsg-4
ii  libqt5designer5   5.15.2-3
ii  libqt5gui55.15.2+dfsg-4
ii  libqt5help5   5.15.2-3
ii  libqt5network55.15.2+dfsg-4
ii  libqt5printsupport5   5.15.2+dfsg-4
ii  libqt5test5   5.15.2+dfsg-4
ii  libqt5widgets55.15.2+dfsg-4
ii  libqt5xml55.15.2+dfsg-4
ii  libstdc++610.2.1-6
ii  python3   3.9.1-1
ii  python3-pyqt5.sip 12.8.1-1+b2

Versions of packages python3-pyqt5 suggests:
pn  python3-pyqt5-dbg  

-- no debconf information

Bug#982899: duply: new test for decryption keys breaks symmetric encryption

[Sean Whitton]

control: tag -1 + fixed-upstream

Hello,

On Mon 15 Feb 2021 at 06:15PM -07, Sean Whitton wrote:

> Package: duply
> Version: 2.3-1
> Control: forwarded -1 https://sourceforge.net/p/ftplicity/bugs/124/
> Control: fixed -1 duply/2.1-1
>
> Dear maintainer,
>
> The new code which checks the availability of encryption secret keys
> fails when using symmetric encryption, i.e., when GPG_PW is set but
> GPG_KEYS_ENC and GPG_KEY_SIGN are not set.  Looking at the new code, it
> does not seem to take into account this long-supported way of using
> duply, so I think this is a regression from buster.

This is fixed in upstream release 2.3.1; could it be uploaded, please?

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#980809: Matrix package default tolerance on s390x (Re: Bug#980809: rmatrix: breaks autopkgtest of r-cran-glmmtmb on s390x)

[Dirk Eddelbuettel]

On 17 February 2021 at 16:58, Graham Inggs wrote:
| Hi Dirk
| 
| On Wed, 17 Feb 2021 at 15:10, Dirk Eddelbuettel  wrote:
| > Graham:  What does that bigendian box say for   Sys.info()[["machine"]]   ?
| 
| The other big-endian box I tested was perotto.debian.net [*], it says:
| 
| > Sys.info()[["machine"]]
| [1] "ppc64"
| 
| > Should we test for endianness instead?  And then maybe try to roll up to the
| > cause of the difference?
| 
| I've just tested on 32-bit big-endian and the glmmTMB problem does not
| occur there, so at this stage I would say test for big-endian **and**
| 64 bits.
| 
| Just to be clear, is the fix you are proposing in Matrix going to fix
| the glmmTMB error?

No. That may well be something else.

| If a bug shows up on 64-bit big-endian, but not on little-endian or
| 32-bit big-endian, then it's usually a sign that somewhere a 64-bit
| variable is incorrectly being read or written to as a 32-bit variable.

CRAN uses a Solaris machine for some endianness variability but I believe
that machine runs only 32bit.

Dirk
 
| Regards
| Graham
| 
| 
| [*] https://db.debian.org/machines.cgi?sortby=purpose=dcs

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

Bug#982982: u-boot: Add support for the pinetab platform

[Nicolas Boulenguez]

Source: u-boot
Severity: wishlist
Tags: patch

The part adding a defconfig is forwarded to the u-boot mailing list
and is here for information.  Once it has been applied upstream, the
other parts should be sufficient to enable the pinetab in Debian.
>From cc1e13e7956e0a6720ff479eb3e86823c664eb3a Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Wed, 17 Feb 2021 18:45:27 +0100
Subject: [PATCH 2/2] Add support for the pinetab platform

The patch adding a defconfig has been forwarded to u-boot upstream.
---
 debian/bin/u-boot-install-sunxi   |  1 +
 .../0001-configs-add-PineTab-defconfig.patch  | 29 +++
 debian/patches/series |  2 ++
 debian/targets|  3 ++
 4 files changed, 35 insertions(+)
 create mode 100644 debian/patches/pinetab/0001-configs-add-PineTab-defconfig.patch

diff --git a/debian/bin/u-boot-install-sunxi b/debian/bin/u-boot-install-sunxi
index 7e5d1087d8..8be14dbf3d 100755
--- a/debian/bin/u-boot-install-sunxi
+++ b/debian/bin/u-boot-install-sunxi
@@ -10,6 +10,7 @@ if [ -z "$TARGET" ] && [ -f "${dtmodel}" ]; then
 	case "$dtmodelname" in
 		Pinebook) TARGET="/usr/lib/u-boot/pinebook" ;;
 		"Pine64 PinePhone (1."[12]")") TARGET='/usr/lib/u-boot/pinephone' ;;
+		PineTab) TARGET="/usr/lib/u-boot/pinetab" ;;
 		Pine64+) TARGET="/usr/lib/u-boot/pine64_plus" ;;
 		"Pine64 LTS") TARGET="/usr/lib/u-boot/pine64-lts" ;;
 		"Olimex A20-OLinuXino-LIME2") TARGET="/usr/lib/u-boot/A20-OLinuXino-Lime2"; itbfiles= ;;
diff --git a/debian/patches/pinetab/0001-configs-add-PineTab-defconfig.patch b/debian/patches/pinetab/0001-configs-add-PineTab-defconfig.patch
new file mode 100644
index 00..03b9c32f33
--- /dev/null
+++ b/debian/patches/pinetab/0001-configs-add-PineTab-defconfig.patch
@@ -0,0 +1,29 @@
+From 2c346cacb4b0841051bceb27a57058020860ab8b Mon Sep 17 00:00:00 2001
+From: Arnaud Ferraris 
+Date: Wed, 2 Sep 2020 09:53:50 +0200
+Subject: [PATCH] configs: add PineTab defconfig
+
+--- /dev/null
 b/configs/pinetab_defconfig
+@@ -0,0 +1,21 @@
++CONFIG_ARM=y
++CONFIG_ARCH_SUNXI=y
++CONFIG_SPL=y
++CONFIG_IDENT_STRING=""
++CONFIG_MACH_SUN50I=y
++CONFIG_SUNXI_DRAM_LPDDR3_STOCK=y
++CONFIG_DRAM_CLK=552
++CONFIG_DRAM_ZQ=3881949
++CONFIG_MMC_SUNXI_SLOT_EXTRA=2
++# CONFIG_VIDEO_DE2 is not set
++CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pinetab"
++# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
++CONFIG_BOOTDELAY=0
++CONFIG_SYS_CONSOLE_INFO_QUIET=y
++# CONFIG_DISPLAY_CPUINFO is not set
++# CONFIG_DISPLAY_BOARDINFO is not set
++# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
++# CONFIG_SPL_BANNER_PRINT is not set
++# CONFIG_SPL_POWER_SUPPORT is not set
++# CONFIG_NET is not set
++# CONFIG_EFI_LOADER is not set
diff --git a/debian/patches/series b/debian/patches/series
index 6e737632d3..745b81bf22 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -19,3 +19,5 @@ riscv64/qemu-riscv64_smode-sifive-fu540-fix-extlinux-define-.patch
 n900/bootz_and_raw_initrd.patch
 
 rk3399/disable-preboot
+
+pinetab/0001-configs-add-PineTab-defconfig.patch
diff --git a/debian/targets b/debian/targets
index a2855f6daf..04c5b31978 100644
--- a/debian/targets
+++ b/debian/targets
@@ -259,6 +259,9 @@ arm64	sunxi		pinebook	/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.b
 # Arnaud Ferraris  (1.1, 1.2)
 arm64	sunxi		pinephone	/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pinephone-1.1.dtb arch/arm/dts/sun50i-a64-pinephone-1.2.dtb u-boot-sunxi-with-spl.fit.itb
 
+# Arnaud Ferraris 
+arm64	sunxi		pinetab		/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pinetab.dtb u-boot-sunxi-with-spl.fit.itb
+
 # Jonas Smedegaard 
 arm64	sunxi		teres_i		/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin u-boot-nodtb.bin arch/arm/dts/sun50i-a64-teres-i.dtb u-boot-sunxi-with-spl.fit.itb
 
-- 
2.30.0

Bug#982981: u-boot: Enable version 1.1 of the pinephone

[Nicolas Boulenguez]

Source: u-boot
Severity: wishlist
Tags: patch

Please enable version 1.1 (1.0 was a prototype, 1.2 is already
enabled)..
>From 881a4dcc90562dafc7f0971e349b9be98b04f04b Mon Sep 17 00:00:00 2001
From: Nicolas Boulenguez 
Date: Wed, 17 Feb 2021 18:40:08 +0100
Subject: [PATCH 1/2] Enable version 1.1 of the pinephone

---
 debian/bin/u-boot-install-sunxi | 2 +-
 debian/targets  | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/debian/bin/u-boot-install-sunxi b/debian/bin/u-boot-install-sunxi
index 4153fb8ea5..7e5d1087d8 100755
--- a/debian/bin/u-boot-install-sunxi
+++ b/debian/bin/u-boot-install-sunxi
@@ -9,7 +9,7 @@ if [ -z "$TARGET" ] && [ -f "${dtmodel}" ]; then
 	dtmodelname=$(cat $dtmodel)
 	case "$dtmodelname" in
 		Pinebook) TARGET="/usr/lib/u-boot/pinebook" ;;
-		"Pine64 PinePhone (1.2)") TARGET='/usr/lib/u-boot/pinephone' ;;
+		"Pine64 PinePhone (1."[12]")") TARGET='/usr/lib/u-boot/pinephone' ;;
 		Pine64+) TARGET="/usr/lib/u-boot/pine64_plus" ;;
 		"Pine64 LTS") TARGET="/usr/lib/u-boot/pine64-lts" ;;
 		"Olimex A20-OLinuXino-LIME2") TARGET="/usr/lib/u-boot/A20-OLinuXino-Lime2"; itbfiles= ;;
diff --git a/debian/targets b/debian/targets
index d8aeaac582..a2855f6daf 100644
--- a/debian/targets
+++ b/debian/targets
@@ -255,8 +255,9 @@ arm64	sunxi		pine64-lts	/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot
 # Vagrant Cascadian 
 arm64	sunxi		pinebook	/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pinebook.dtb u-boot-sunxi-with-spl.fit.itb
 
-# Benoit Delcour 
-arm64	sunxi		pinephone	/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pinephone-1.2.dtb u-boot-sunxi-with-spl.fit.itb
+# Benoit Delcour  (1.2)
+# Arnaud Ferraris  (1.1, 1.2)
+arm64	sunxi		pinephone	/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin u-boot-nodtb.bin arch/arm/dts/sun50i-a64-pinephone-1.1.dtb arch/arm/dts/sun50i-a64-pinephone-1.2.dtb u-boot-sunxi-with-spl.fit.itb
 
 # Jonas Smedegaard 
 arm64	sunxi		teres_i		/usr/lib/arm-trusted-firmware/sun50i_a64/bl31.bin u-boot.bin spl/sunxi-spl.bin u-boot-nodtb.bin arch/arm/dts/sun50i-a64-teres-i.dtb u-boot-sunxi-with-spl.fit.itb
-- 
2.30.0

Bug#982980: chromium: Update to version 88.0.4324.182 (security-fixes)

[Sedat Dilek]

Package: chromium
Version: 88.0.4324.150-1
Severity: normal
X-Debbugs-Cc: sedat.di...@gmail.com

Dear Maintainer,

please update to version 88.0.4324.182.
[1] shows several CVEs Security Fixes labeled with "High".

Thanks.

Regards,
- Sedat -

[1] https://chromereleases.googleblog.com/search/label/Stable%20updates
[2] https://security-tracker.debian.org/tracker/source-package/chromium

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (99, 'buildd-unstable'), (99, 
'buildd-experimental'), (99, 'experimental'), (99, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.11.0-3-amd64-clang13-ias (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common  88.0.4324.150-1
ii  libasound2   1.2.4-1.1
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libatomic1   10.2.1-6
ii  libatspi2.0-02.38.0-2
ii  libavcodec58 7:4.3.1-8
ii  libavformat587:4.3.1-8
ii  libavutil56  7:4.3.1-8
ii  libc62.31-9
ii  libcairo21.16.0-5
ii  libcups2 2.3.3op2-3
ii  libdbus-1-3  1.12.20-1
ii  libdrm2  2.4.104-1
ii  libevent-2.1-7   2.1.12-stable-1
ii  libexpat12.2.10-1
ii  libflac8 1.3.3-2
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgbm1  20.3.4-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.7-1
ii  libgtk-3-0   3.24.24-1
ii  libharfbuzz0b2.7.4-1
ii  libicu67 67.1-6
ii  libjpeg62-turbo  1:2.0.6-1
ii  libjsoncpp24 1.9.4-4
ii  liblcms2-2   2.12~rc1-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1
ii  libopenjp2-7 2.4.0-3
ii  libopus0 1.3.1-0.1
ii  libpango-1.0-0   1.46.2-3
ii  libpng16-16  1.6.37-3
ii  libpulse014.2-1
ii  libre2-9 20210201+dfsg-1
ii  libsnappy1v5 1.1.8-1
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.7.0-2
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxml2  2.9.10+dfsg-6.3+b1
ii  libxrandr2   2:1.5.1-1
ii  libxslt1.1   1.1.34-4
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages chromium recommends:
ii  chromium-sandbox  88.0.4324.150-1

Versions of packages chromium suggests:
pn  chromium-driver  
ii  chromium-l10n88.0.4324.150-1
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6   2.31-9
ii  libstdc++6  10.2.1-6
ii  libx11-62:1.7.0-2
ii  libxext62:1.3.3-1.1
ii  x11-utils   7.7+5
ii  xdg-utils   1.1.3-4
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium-common recommends:
ii  chromium-sandbox88.0.4324.150-1
ii  fonts-liberation1:1.07.4-11
ii  gnome-shell [notification-daemon]   3.38.3-2
ii  libgl1-mesa-dri 20.3.4-1
ii  libu2f-udev 1.1.10-3
ii  notification-daemon 3.20.0-4
ii  plasma-workspace [notification-daemon]  4:5.20.5-3
ii  system-config-printer   1.5.14-1
ii  upower  0.99.11-2

Versions of packages chromium-sandbox depends on:
ii  libc6  2.31-9

-- Configuration Files:
/etc/chromium.d/default-flags changed [not included]

-- no debconf information

Bug#953289: ABI change in libsoxr 0.1.3

[Sebastian Ramacher]

Control: reassign -1 mpd 0.22.4-1
Control: forwarded -1 https://github.com/MusicPlayerDaemon/MPD/issues/773
Control: severity -1 normal

On 2021-01-15 22:44:37 +0100, Paul Gevers wrote:
> Hi all,
> 
> On Sat, 7 Mar 2020 09:57:02 +0100 Max Kellermann  wrote:
> > Package: libsoxr0
> > Version: 0.1.3-2
> > 
> > In version 0.1.3, libsoxr has made an undocumented ABI change which
> > causes MPD (Music Player Daemon) to crash:
> > 
> >  https://github.com/MusicPlayerDaemon/MPD/issues/773
> > 
> > The commit which changed the ABI was:
> >  
> > https://sourceforge.net/p/soxr/code/ci/52888cd410ae356bf3aa26d8fa106754b8fd8990
> 
> Any progress here? The transition freeze already started. How do you
> propose we solve this issue?

I've now reread the upstream bug report once again, and it appears as if
mpd is missing a call to soxr_clear before reusing a context. Hence,
I'm reassigning this bug to mpd.

Also lowering the severity as no ABI breakage seems to be involved.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#982976: systemd-coredump user is created by something other than its derived systemd packages

[Michael Biebl]

Am 17.02.21 um 18:33 schrieb Michael Biebl:
We could remove the explicit adduser/addgroup calls from systemd and its 
subpackages and simply call

systemd-sysusers /usr/lib/sysusers.d/systemd.conf
so those systemd users/groups are setup in one place and we don't 
duplicate the information. Dunno.




Something like this, maybe

https://salsa.debian.org/systemd-team/systemd/-/merge_requests/121



OpenPGP_signature
Description: OpenPGP digital signature

Bug#982978: RM: moblin-sound-theme -- RoM; Useless; Unmaintained

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove

Dear FTP Masters,

According to the discussion in https://bugs.debian.org/979244 , the
package maintainer requested to have the package moblin-sound-theme
removed from Debian since it is useless now.

Thanks,
Boyuan Yang


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

Bug#982711: [PATCH] bsdowl: FTBFS: bmake[2]: don't know how to make distclean. Stop

[Dennis Filder]

Control: tag -1 + patch

I suspect this issue is due to the same changes that caused #982717.
Also whoever wrote d/rules was apparently unaware that debhelper
supports bmake.  The patch reworks that and applies the same override
as the one for #982717.  After building with this patch debdiff showed
no differences in the file list, so I guess it works alright.

Whoever takes care of this should also take care of #980793.  Though
with a popcon of 5, apparently nothing build-depending on it, and the
maintainer unresponsive maybe this shouldn't be shipped anymore.

Regards,
Dennis.


bsdowl-fix-982711.patch.gz
Description: application/gzip

Bug#982717: udfclient: FTBFS: bmake[1]: no target to make.

[Dennis Filder]

On Wed, Feb 17, 2021 at 12:49:25PM +0100, Pali Rohár wrote:

> Hello Dennis! Thank you for investigation and the patch. Will you update
> also the package? Or should I do it? Note that I do not have Debian
> Developer permissions so I can update new version of package only to
> mentors server (which takes a long to appear in Debian archive...).

I have no upload permission anywhere, so you'll have to do it.  If you
feel like the normal process will take too long you could either ask
around on IRC, set the help tag, ask the release team for advice, or
as a last resort, contact a mentor/DD directly.  If you mention that
it's a small change and include a debdiff they're probably glad to
help.

Regards,
Dennis.

Bug#980793: [PATCH] bsdowl: piuparts failure

[Dennis Filder]

Control: tag -1 + patch

The attached patch fixes this.

Whoever takes care of this should also take care of #982711.


bsdowl-fix-980793-piuparts.patch.gz
Description: application/gzip

Bug#982977: RFS: td-system-tools/1.1.5-1

[Thomas Dreibholz]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "td-system-tools
":

  * Package name: td-system-tools
Version: 1.1.5-1
Upstream Author: Thomas Dreibholz mailto:dre...@iem.uni-due.de>>
  * URL: https://www.uni-due.de/~be0001/system-info/
  * License: GPL-3+
  * Section: utils

This package contains programs for printing basic system information and
for system maintenance. System-Info displays basic status information
about the system: hostname, uptime, CPU, memory statistics, disk space
statistics, SSH public key hashes, and networking information.
Furthermore, it can be configured to show one or more banners (for
example, a project name). System-Info can be configured to be
automatically run when logging in, providing the user an up-to-date
overview of the system. System-Maintenance runs basic system maintenance
tasks: trying to repair broken package management, updating the package
management databases, installing all available updates, checking for old
kernels and removing them, trim SSD or unmap unused storage.

"td-system-tools " builds
these binary packages:

  * td-system-configure-grub - Helper tool to adjust GRUB configuration
  * td-system-info - Print basic system information and banners
  * td-system-maintenance - Perform basic system maintenance
  * td-system-tools - Metapackage for system information and maintenance
tools

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

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

dget -x 
https://mentors.debian.net/debian/pool/main/t/td-system-tools/td-system-tools_1.1.5-1.dsc

More information about "td-system-tools
" can be obtained from
https://www.uni-due.de/~be0001/system-info/.

Most recent changelog entry:

td-system-tools (1.1.5-1ubuntu1) focal; urgency=medium

  * New upstream release.
  * debian/control: Updated standards version to 4.5.1.0.

-- Thomas Dreibholz > Wed, 17 Feb 2021
18:32:00 +0100

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

===
 Thomas Dreibholz

 SimulaMet -- Simula Metropolitan Centre for Digital Engineering
 Centre for Resilient Networks and Applications
 Pilestredet 52
 0167 Oslo, Norway
---
 E-Mail: dre...@simula.no
 Homepage:   http://simula.no/people/dreibh
===



signature.asc
Description: OpenPGP digital signature

Bug#982949: Please allow libvirt-python 7.0.0 into bullseye

[Paul Gevers]

Control: tags -1 moreinfo

Hi Guido,

On 17-02-2021 08:50, Guido Günther wrote:
> #982695 made me aware i totally forgot to update libvirt-python with
> recent libvirt before the freeze, hence the build failure. I've
> prepared 7.0.0-1 in experimental a couple of days ago and it would be
> great to have that version in bullseye since it matches the libvirt
> version. The diff is a bit larger due to the introduction of type hints
> etc upstream
> 
>http://honk.sigxcpu.org/tmp/7.0.0-1.diff
> 
> Would that be o.k. to upload to sid to fix #982695? Otherwise I'll look
> at fixing just the build failure on top of 6.1.0-1.

libvirt-python is a key package. Please fix this without a new upstream
release unless you can explain that it's a targeted fix. It doesn't look
like that though from the version number.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#972724: dh_missing: allow dealing with manually (cp commands in d/rules) installed files

[Niels Thykier]

Norbert Preining:
> Package: debhelper
> Version: 13.2.1
> Severity: normal
> X-Debbugs-Cc: pkg-kde-t...@alioth-lists.debian.net
> 
> Hi
> 

Hi,

> sometimes we need to install files depending on the architecture, so
> some files are *not* installed on a subset of the architectures (example
> kdeplasma-addons).  This seems to be impossible with dh_install's .install
> files, so what we are doing is copy the files in d/rules.
> 

Indeed, this is not possible using only native debhelper features.
Depending on the concrete scenario, you might be able to rely on dh-exec
for this though.

> But these files are not seen by dh_install because it only checks the
> logged files, and not the *actually* installed files
> 
> (BTW **why** does dh_missing not compare the actually installed files in
> debian/$package/ against the files in debian/tmp, and instead relies on
> all helpers correctly updating the list of installed files? This seems
> rather error prone as we see).
> 

Checking what is installed fails in the general case for "binary-indep"
vs "binary-arch" builds and when the file in question is only produced
either "always", "only in the -indep case" or "only in the -arch case".

Jumping through some hoops, the looping method can handle these (by
having the dh_* log what it "would have" installed in all cases).

Obviously it has its flaws.  The case you present here being one of them
(the other being additional complexity in helper tools)

> Of course I can stash them into d/not-installed, but that sounds wrong,
> since these files **are** installed, only not via a debhelper tool.
> 
> Best
> 
> Norbert
> 
> [...]
To my knowledge, you can use the following work arounds for this issue:

 * Use dh-exec and its filtering in combination with the debhelper tool.
 * (Ab)use debian/not-installed
 * (Ab)use another means to get a dh_tool to install it.
 * Manually register the file as installed[1]

~Niels

[1]:

It should be something like:

  mkdir -p debian/.debhelper/generated/${package}/
  echo "usr/lib/file-or-dir/you/want/dh_missing/to/know/about >> \
   debian/.debhelper/generated/${package}/installed-by-debian-rules

You can either always run it or only when the file is correctly
installed.  See /usr/share/doc/debhelper/PROGRAMMING.gz section "Logging
helpers and dh_missing:" (notably "Other helpers:" beneath it) for the
exact details.

Bug#982976: systemd-coredump user is created by something other than its derived systemd packages

[Michael Biebl]

Am 17.02.21 um 18:27 schrieb Eric Desrochers:
It may have some effect in certain corner cases. One I have in mind is 
CIS hardening benchmark which provides prescriptive guidance for 
establishing a secure IT Infrastructure, with specific requirement 
related to home directory.


Sorry, I don't understand how this is a problem.

I don't see why systemd-coredump user would be implicitly 
created, unless it is necessary without its corresponding binary 
package, systemd-coredump,  installed.


As said, it is shipped in a single sysusers file and I don't really 
think it's worth splitting up that file.
We create a lot of "basic" system users/groups in base-passwd which 
aren't necessarily used either.


We could remove the explicit adduser/addgroup calls from systemd and its 
subpackages and simply call

systemd-sysusers /usr/lib/sysusers.d/systemd.conf
so those systemd users/groups are setup in one place and we don't 
duplicate the information. Dunno.


Michael



OpenPGP_signature
Description: OpenPGP digital signature