Bug#931933: Reassigned "Debian 10.0 sid hppa refuses to boot on HP C8000"

[Juhani Numminen]

Control: reassign 931933 src:linux
Control: found 931933 4.19.37-5
Control: retitle 931933 linux-image-4.19.0-5-parisc64-smp: Debian 10.0 sid hppa 
refuses to boot on HP C8000

Reassigning from kernel-package which is responsible for building a custom
kernel package. I got the impression that this bug report is about the one
provided in Debian repositories.

Bug#952845: transition: proj

[Sebastiaan Couwenberg]

On 3/18/20 11:51 PM, Emilio Pozuelo Monfort wrote:
> On 18/03/2020 19:02, Sebastiaan Couwenberg wrote:
>> On 3/18/20 10:49 AM, Emilio Pozuelo Monfort wrote:
>>> On 18/03/2020 09:56, Sebastiaan Couwenberg wrote:
 On 3/18/20 12:41 AM, Emilio Pozuelo Monfort wrote:
> On 01/03/2020 11:03, Bas Couwenberg wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>> Control: forwarded -1 
>> https://release.debian.org/transitions/html/auto-proj.html
>> Control: block -1 by 951655 951656
>>
>> For the Debian GIS team I'd like to transition to PROJ 7.
>>
>> It's not such a major change as the previous transition to PROJ 6 
>> (#931949).
>>
>> There were a few FTBFS with the RCs in experimental, but all except 
>> r-cran-sf
>> have been fixed in the mean time. There is a patch in the BTS for 
>> r-cran-sf,
>> which also fixes the FTBFS of r-cran-lwgeom when r-cran-sf is rebuilt.
>
> Let's go ahead.

 Thanks!

 proj (7.0.0-1) has been uploaded to unstable and is built & installed on
 all release architectures.
>>>
>>> And now on the non-release architectures too. binNMUs scheduled.
>>
>> Please give back therion, r-cran-rgdal & r-cran-sf with a dep-wait on
>> libproj-dev (>= 7.0.0-2), that fixes the pkg-config issues.
> 
> Scheduled.

therion, r-cran-rgdal & r-cran-sf are all good now.

>> Once r-cran-sf has been rebuilt successfully r-cran-lwgeom should built
>> successfully too.
> 
> I will schedule that tomorrow.

r-cran-lwgeom is still TODO.

>> openorienteering-mapper should build successfully now that gdal has been
>> rebuilt with PROJ 7. This may be the fix for qgis too.
> 
> openorienteering-mapper given back and built. qgis given back.

openorienteering-mapper is good now too.

The giveback of qgis on amd64 built successfully, it can be givenback on
the other architectures too.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#934665: upload grpc and protobuf to unstable

[GCS]

On Wed, Mar 18, 2020 at 10:03 PM Salvatore Bonaccorso  wrote:
> On Mon, Dec 23, 2019 at 05:47:39PM +0530, Pirate Praveen wrote:
> > On Mon, 18 Nov 2019 11:27:28 +0530 Pirate Praveen 
> > wrote:
> > > missed anbox from the second list sent by Nilesh. Now confirmed anbox
> > > also fails.
> >
> > It's been a month since we filed bugs with failing packages, can we request
> > transition now?
>
> Out of interest, was there any progress with this?
 It's really the time to push this now. Recently rebuilt affected
packages with the new protobuf package version and there's only one
FTBFS (lazily maintained package with low popcon). I couldn't get the
auto-grpc transition tracker, will try to find that out this
afternoon.

Cheers,
Laszlo/GCS

Bug#954239: RFP: python-b4 -- helper utility to work with patches made available via a public-inbox archive

[Salvatore Bonaccorso]

Package: wnpp
Severity: wishlist

* Package name: python-b4
  Version : v0.3.3 (or later)
  Upstream Author : Konstantin Ryabitsev 
* URL : https://git.kernel.org/pub/scm/utils/b4/b4.git
* License : GPL
  Programming Lang: Python
  Description : helper utility to work with patches made available via a 
public-inbox archive

This is a helper utility to work with patches made available via a
public-inbox archive like lore.kernel.org. It is written to make it
easier to participate in a patch-based workflows, like those used in
the Linux kernel development.

For the package name, not sure if python-b4 or b4 is more appropriate.

Regards,
Salvatore

Bug#954250: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode

[Martin-Éric Racine]

Package: python3-yaml
Version: 5.3.1-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Setting up python3-yaml (5.3.1-1) ...
/usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering 
(buffering=1) isn't supported in binary mode, the default buffer size will be 
used
  self.stdin = io.open(p2cwrite, 'wb', bufsize)


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages python3-yaml depends on:
ii  libc62.30-2
ii  libyaml-0-2  0.2.2-1
ii  python3  3.8.2-1

python3-yaml recommends no packages.

python3-yaml suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAl5zQjgACgkQrh+Cd8S0
17bH2xAAuhg3ljtiGy+FCcX84TKpL6tkGod3cR2Iy24hPAtWzqLCknG1L0B98Ogl
EQRmxOzxVbkOKYGBSzYsZpIOW0MjJSqISbBRohzgk0YpyPmXPWXlwEwZpqvZ4fJa
WmmTZdj6Y4DOJtl1i49Ti6uk/PzS5Lp8453mkKzpJ8qgSwh/XrpuD5r1b+C/bSts
G6qVW6svWaRbbYqsyZ4/Q3MlttIjD8Q3q3JprA7kuyzVy+hGbC428oxwhYvjj7gU
qYTf4m4IV16/h2vYZn573Z8BEy766uqMhv8N1ntZ8A5VmtbJQcjbPNzJAFTxW9cX
N6GsoeLE1unLIsueEm8x0UMewSz8/G8QogJZUDLsBrxGPCYXr7JTBwwHItLNvBSD
4YjfSJWMI+dI1GLUZFAII/vERdTpDAAmQtdnH88fVfgyIlgRrEB8azK9oZPVdE64
1qU7lts3HqdDZw5KFn3ITRv87Yc2VgJe4IldWHMm3+HcAj3i1xWW1t+rdvnsb01d
rcwtDuB72OnA581WPQOMWDQ3k7yjYuDs7p55A7liQoP6yq4c9XxZrkFYUStRIaiK
wyoRRyMdAWcqz5ohg3Nt2n5KLTeW9m13paHmS+1qJRhfLH1OxBQRdch7VKvxWlaS
RUqjjL9J42RyYcb2xXshvB3SQjVyHHkVBLWDO/fdavVAouDx9Xk=
=EPA1
-END PGP SIGNATURE-

Bug#954253: python3-pybel: Missing dependency on unpackaged bel_resources

[Adrian Bunk]

Package: python3-pybel
Version: 0.14.5-1
Severity: serious
Control: block 950662 by -1

https://buildd.debian.org/status/fetch.php?pkg=pybel=all=0.14.5-1=1583338001=0
...
   dh_python3 -i -O--buildsystem=pybuild
I: dh_python3 pydist:224: Cannot find package that provides bel_resources. 
Please add package that provides it to Build-Depends or add "bel_resources 
python3-bel-resources" line to debian/py3dist-overrides or add proper 
dependency to Depends by hand and ignore this info.
...


https://ci.debian.net/packages/p/pybel/unstable/amd64/
...
Testing with python3.7:
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pybel/__init__.py", line 5, in 
from .canonicalize import edge_to_bel, to_bel_script, to_bel_script_gz, 
to_bel_script_lines
  File "/usr/lib/python3/dist-packages/pybel/canonicalize.py", line 11, in 

import bel_resources.constants
ModuleNotFoundError: No module named 'bel_resources'

Bug#953171: gammaray: Enable statemachineviewer plugin

[Daniele E. Domenichelli]

Sorry, I forgot to add the gammaray-plugin-statemachineviewer.install in
previous patch, this one should be working properly

On 05/03/2020 14:48, Daniele E. Domenichelli wrote:
> Package: gammaray
> Version: 2.11.0-1
> Severity: wishlist
> Tags: patch
> Control: block -1 by 953159
> 
> Dear Maintainer,
> 
> Please enable gammaray statemachineviewer plugin.
> This plugin requires kdstatemachineeditor that I'm try to package (see
> #953159 and #953170)
> 
> I'm attaching a patch that should enable the plugin as soon as the
> kdstatemachineeditor-dev package is available.
> 
> Regards,
>  Daniele
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (500, 'stable'), (300, 'unstable'), (150, 
> 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages gammaray depends on:
> ii  libc6 2.29-10
> ii  libdw10.176-1.1
> ii  libgcc-s1 10-20200222-1
> ii  libkf5syntaxhighlighting5 5.62.0-3
> ii  libqt53dcore5 5.12.5+dfsg-1+b3
> ii  libqt53drender5   5.12.5+dfsg-1+b3
> ii  libqt5core5a [qtbase-abi-5-12-5]  5.12.5+dfsg-8
> ii  libqt5designer5   5.12.5-2+b2
> ii  libqt5gui55.12.5+dfsg-8
> ii  libqt5network55.12.5+dfsg-8
> ii  libqt5printsupport5   5.12.5+dfsg-8
> ii  libqt5qml55.12.5-5
> ii  libqt5quick5  5.12.5-5
> ii  libqt5script5 5.12.5+dfsg-2
> ii  libqt5scripttools55.12.5+dfsg-2
> ii  libqt5svg55.12.5-2
> ii  libqt5webenginewidgets5   5.12.5+dfsg-6+b1
> ii  libqt5widgets55.12.5+dfsg-8
> ii  libstdc++610-20200222-1
> ii  qml-module-qt3d   5.12.5+dfsg-1+b3
> ii  qml-module-qtquick-controls   5.12.5-1+b1
> ii  qml-module-qtquick-scene3d5.12.5+dfsg-1+b3
> 
> Versions of packages gammaray recommends:
> ii  gdb  8.3.1-1
> 
> gammaray suggests no packages.
> 
> -- no debconf information
> 

>From c0d9f42dec3da55925d2c0cc55e82673f6eb6831 Mon Sep 17 00:00:00 2001
From: "Daniele E. Domenichelli" 
Date: Thu, 5 Mar 2020 13:30:54 +0100
Subject: [PATCH 1/3] Enable gammaray-plugin-statemachineviewer package

---
 debian/control| 9 +
 debian/gammaray-plugin-statemachineviewer.install | 1 +
 debian/gammaray.install   | 1 -
 3 files changed, 10 insertions(+), 1 deletion(-)
 create mode 100644 debian/gammaray-plugin-statemachineviewer.install

diff --git a/debian/control b/debian/control
index 5b84049..8b1492b 100644
--- a/debian/control
+++ b/debian/control
@@ -33,6 +33,7 @@ Build-Depends: cmake,
qttranslations5-l10n,
qtwayland5,
qtwebengine5-dev [amd64 arm64 armhf i386 mipsel],
+   kdstatemachineeditor-dev,
xauth,
xvfb
 Standards-Version: 4.4.0
@@ -113,6 +114,14 @@ Enhances: gammaray
 Description: Qt5Positioning type support for GammaRay
  This plugin adds support for Qt5Positioning types into GammaRay.
 
+Package: gammaray-plugin-statemachineviewer
+Architecture: any
+Depends: gammaray (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
+Enhances: gammaray
+Description: State Machine Viewer plugin for GammaRay
+ This plugin can be used to monitor State Machine State within a QtStateMachine
+ or QtSCXML application.
+
 Package: gammaray-dev
 Architecture: any
 Section: libdevel
diff --git a/debian/gammaray-plugin-statemachineviewer.install b/debian/gammaray-plugin-statemachineviewer.install
new file mode 100644
index 000..9d8bfc8
--- /dev/null
+++ b/debian/gammaray-plugin-statemachineviewer.install
@@ -0,0 +1 @@
+usr/lib/*/gammaray/*/qt5*/gammaray_statemachineviewer*
diff --git a/debian/gammaray.install b/debian/gammaray.install
index 68fd888..b7d1004 100644
--- a/debian/gammaray.install
+++ b/debian/gammaray.install
@@ -19,7 +19,6 @@ usr/lib/*/gammaray/*/qt5*/gammaray_qtivi_ui.so
 usr/lib/*/gammaray/*/qt5*/gammaray_sceneinspector*
 usr/lib/*/gammaray/*/qt5*/gammaray_scriptenginedebugger*
 usr/lib/*/gammaray/*/qt5*/gammaray_signalmonitor*
-usr/lib/*/gammaray/*/qt5*/gammaray_statemachineviewer*
 usr/lib/*/gammaray/*/qt5*/gammaray_styleinspector*
 usr/lib/*/gammaray/*/qt5*/gammaray_sysinfo_plugin.so
 usr/lib/*/gammaray/*/qt5*/gammaray_sysinfo_ui_plugin.so
-- 
2.25.1

Bug#954134: [d-i bullseye alpha2] installing grub fails

[Steve McIntyre]

On Thu, Mar 19, 2020 at 09:26:25AM +0100, Holger Wansing wrote:
>Hi,
>
>Steve McIntyre  wrote:
>> One silly question: what media are you using with the Thinkpad? Is it
>> the same USB stick (or whatever) every time? Can you verify it's
>> written OK?
>
>I used the same USB stick for alpha1 and alpha2, re-flashing it over and
>over again.
>And I have checked installation media integrity with alpha2, it reports
>no error, "image is valid".

Hmmm, OK. Wondering what's causing this then. I'll try another
installation test on a physical machine and get back to you.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Dance like no one's watching. Encrypt like everyone is.
 - @torproject

Bug#954134: [d-i bullseye alpha2] installing grub fails

[Holger Wansing]

Hi,

Steve McIntyre  wrote:
> On Thu, Mar 19, 2020 at 09:26:25AM +0100, Holger Wansing wrote:
> >Hi,
> >
> >Steve McIntyre  wrote:
> >> One silly question: what media are you using with the Thinkpad? Is it
> >> the same USB stick (or whatever) every time? Can you verify it's
> >> written OK?
> >
> >I used the same USB stick for alpha1 and alpha2, re-flashing it over and
> >over again.
> >And I have checked installation media integrity with alpha2, it reports
> >no error, "image is valid".
> 
> Hmmm, OK. Wondering what's causing this then. I'll try another
> installation test on a physical machine and get back to you.

I noticed a difference between a alpha1 and alpha2 install on the Thinkpad:
in alpha1 I get the message that the new Debian seems to be the only OS
on the machine. However, on alpha2 install I did not get that message.

But I see no relevant changing in os-prober between alpha1 and 2 which
would explain that ...

I wonder if it's a kernel issue somehow?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#953950: python-twisted: twisted version 14.0.2-3+deb8u1 in jessie (security) is broken

[Simon McVittie]

On Thu, 19 Mar 2020 at 12:33:09 +0100, Etienne Allovon wrote:
> Subject: python-twisted: twisted version 14.0.2-3+deb8u1 in jessie
> (security) is broken

Debian 8 'jessie' is no longer supported by the mainstream Debian
security team or by the maintainers of individual packages. Instead, it
is maintained by the Debian LTS subproject. Please contact the debian-lts
mailing list  if you encounter regressions
in jessie or jessie-security packages.

(LTS people: please see the bug for details, and please make sure the
message is getting out to LTS users that they should be contacting the
LTS team and not the bug tracking system.)

If you do not have a specific reason to stay on Debian 8 'jessie',
also consider upgrading to Debian 9 'stretch', and then from there to
Debian 10 'buster', which is the current stable release.

smcv

Bug#954134: [d-i bullseye alpha2] installing grub fails

[Steve McIntyre]

On Thu, Mar 19, 2020 at 12:42:48PM +0100, Holger Wansing wrote:
>Hi,
>
>Steve McIntyre  wrote:
>> On Thu, Mar 19, 2020 at 09:26:25AM +0100, Holger Wansing wrote:
>> >Hi,
>> >
>> >Steve McIntyre  wrote:
>> >> One silly question: what media are you using with the Thinkpad? Is it
>> >> the same USB stick (or whatever) every time? Can you verify it's
>> >> written OK?
>> >
>> >I used the same USB stick for alpha1 and alpha2, re-flashing it over and
>> >over again.
>> >And I have checked installation media integrity with alpha2, it reports
>> >no error, "image is valid".
>> 
>> Hmmm, OK. Wondering what's causing this then. I'll try another
>> installation test on a physical machine and get back to you.
>
>I noticed a difference between a alpha1 and alpha2 install on the Thinkpad:
>in alpha1 I get the message that the new Debian seems to be the only OS
>on the machine. However, on alpha2 install I did not get that message.
>
>But I see no relevant changing in os-prober between alpha1 and 2 which
>would explain that ...
>
>I wonder if it's a kernel issue somehow?

Hmmm. Can you try wiping the partition table in between tests?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait:   https://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

Bug#954256: python-pip-whl: Editable installs broken: can't find __main__ module

[Alexander Clausen]

Package: python-pip-whl
Version: 20.0.2-2
Severity: normal

Dear pip Maintainers,

trying to install a package in a virtualenv with the -e switch fails with the 
following
error:

=
$ pip install -e . --isolated
Obtaining file:///tmp/pypa2
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  ERROR: Command errored out with exit status 1:
   command: /tmp/venv/bin/python3.8 
/tmp/venv/share/python-wheels/pep517-0.7.0-py2.py3-none-any.whl/pep517/_in_process.py
 get_requires_for_build_wheel /tmp/tmp0hod1rxb
   cwd: /tmp/pypa2
  Complete output (1 lines):
  /tmp/venv/bin/python3.8: can't find '__main__' module in 
'/tmp/venv/share/python-wheels/pep517-0.7.0-py2.py3-none-any.whl/pep517/_in_process.py'
  
ERROR: Command errored out with exit status 1: /tmp/venv/bin/python3.8 
/tmp/venv/share/python-wheels/pep517-0.7.0-py2.py3-none-any.whl/pep517/_in_process.py
 get_requires_for_build_wheel /tmp/tmp0hod1rxb Check the logs for full command 
output.
=

Steps to reproduce:

1) Create virtualenv:

$ python3 -m venv /tmp/venv/
$ source /tmp/venv/bin/activate

2) Create a minimal Python package:

$ mkdir pypa && cd pypa
$ echo "from setuptools import setup; setup()" > setup.py
$ touch pyproject.toml

3) Try to install it:

$ pip install --isolated -e .

(the isolated is needed for me as I have additional indexes in my config)

This fails with the error pasted above. Replacing pip with the upstream package

$ pip install --force pip

makes the editable install work just fine.

Thanks,

Alexander


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

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

Versions of packages python-pip-whl depends on:
ii  ca-certificates  20190110

python-pip-whl recommends no packages.

python-pip-whl suggests no packages.

-- no debconf information

Bug#929405: Sorry to resemble on your privacy am NELSON DELOR i have important issue to exchange view on please contact me on my office authorized Email: nelsondelor...@gmail.com. Thanks.

[NELSON DELOR]

Bug#954256: [Python-modules-team] Bug#954256: python-pip-whl: Editable installs broken: can't find __main__ module

[Scott Kitterman]

Thanks.  The virtualenv package needs updating following the recent pip update. 
 I'm working on it.

Scott K

Bug#954247: postfix: postfix.service has status active after systemd instance unit failed to start

[Christian Göttsche]

Package: postfix
Version: 3.5.0-1

Hi,

currently the instance unit postfix@.service is linked with PartOf= to
the main postfix.service.
This results in a active postfix.service in case the instance
postfix@.service has failed to start.
Is this by design or is a stronger bonding appropriate?


E.g.: (the actual start failure is due to an unrelated SELinux misconfiguration)

Mar 18 12:47:40 server systemd[1]: postfix.service: Succeeded.
Mar 18 12:47:40 server audit[1]: SERVICE_STOP pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:systemd_t:s0
msg='unit=postfix comm="systemd" exe="/lib/systemd/systemd" hostname=?
addr=? terminal=? res=success'
Mar 18 12:47:40 server systemd[1]: Stopped Postfix Mail Transport Agent.
Mar 18 12:47:40 server systemd[1]: Stopping Postfix Mail Transport Agent...
Mar 18 12:47:40 server systemd[1]: Starting Postfix Mail Transport
Agent (instance -)...
Mar 18 12:47:40 server audit[2440]: AVC avc:  denied  { search } for
pid=2440 comm="postsuper" name="defer" dev="sda1" ino=1315503
scontext=system_u:system_r:postfix_multi_t:s0
tcontext=system_u:object_r:postfix_chroot_defer_t:s0 tclass=dir
permissive=0
Mar 18 12:47:40 server audit[2440]: SYSCALL arch=c03e syscall=257
success=no exit=-13 a0=ff9c a1=55620f14b250 a2=90800 a3=0 items=1
ppid=2401 pid=2440 auid=4294967295 uid=113 gid=118 euid=113 suid=113
fsuid=113 egid=118 sgid=118 fsgid=118 tty=(none) ses=429496>
Mar 18 12:47:40 server audit: CWD cwd="/var/spool/postfix"
Mar 18 12:47:40 server audit: PATH item=0 name="defer/C"
nametype=UNKNOWN cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0
Mar 18 12:47:40 server audit: PROCTITLE proctitle="/usr/sbin/postsuper"
Mar 18 12:47:40 server postmulti[2440]: postsuper: fatal:
scan_dir_push: open directory defer/C: Permission denied
Mar 18 12:47:40 server postfix/postsuper[2440]: fatal: scan_dir_push:
open directory defer/C: Permission denied
Mar 18 12:47:41 server postfix/postfix-script[2441]: fatal: Postfix
integrity check failed!
Mar 18 12:47:42 server systemd[1]: postfix@-.service: Control process
exited, code=exited, status=1/FAILURE
Mar 18 12:47:42 server systemd[1]: postfix@-.service: Failed with
result 'exit-code'.
Mar 18 12:47:42 server audit[1]: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:systemd_t:s0
msg='unit=postfix@- comm="systemd" exe="/lib/systemd/systemd"
hostname=? addr=? terminal=? res=failed'
Mar 18 12:47:42 server systemd[1]: Failed to start Postfix Mail
Transport Agent (instance -).
Mar 18 12:47:42 server systemd[1]: Starting Postfix Mail Transport Agent...
Mar 18 12:47:42 server systemd[1]: Finished Postfix Mail Transport Agent.
Mar 18 12:47:42 server audit[1]: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:systemd_t:s0
msg='unit=postfix comm="systemd" exe="/lib/systemd/systemd" hostname=?
addr=? terminal=? res=success'


$ systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
 Loaded: loaded (/lib/systemd/system/postfix.service; enabled;
vendor preset: enabled)
 Active: active (exited) since Wed 2020-03-18 12:47:42 CET; 22s ago
Process: 2442 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
   Main PID: 2442 (code=exited, status=0/SUCCESS)

Mar 18 12:47:42 server systemd[1]: Starting Postfix Mail Transport Agent...
Mar 18 12:47:42 server systemd[1]: Finished Postfix Mail Transport Agent.


$ systemctl status postfix@-
● postfix@-.service - Postfix Mail Transport Agent (instance -)
 Loaded: loaded (/lib/systemd/system/postfix@.service;
enabled-runtime; vendor preset: enabled)
 Active: failed (Result: exit-code) since Wed 2020-03-18 12:47:42
CET; 26s ago
   Docs: man:postfix(1)
Process: 2341 ExecStartPre=/usr/lib/postfix/configure-instance.sh
- (code=exited, status=0/SUCCESS)
Process: 2394 ExecStart=/usr/sbin/postmulti -i - -p start
(code=exited, status=1/FAILURE)

Mar 18 12:47:40 server systemd[1]: Starting Postfix Mail Transport
Agent (instance -)...
Mar 18 12:47:40 server postmulti[2440]: postsuper: fatal:
scan_dir_push: open directory defer/C: Permission denied
Mar 18 12:47:40 server postfix/postsuper[2440]: fatal: scan_dir_push:
open directory defer/C: Permission denied
Mar 18 12:47:41 server postfix/postfix-script[2441]: fatal: Postfix
integrity check failed!
Mar 18 12:47:42 server systemd[1]: postfix@-.service: Control process
exited, code=exited, status=1/FAILURE
Mar 18 12:47:42 server systemd[1]: postfix@-.service: Failed with
result 'exit-code'.
Mar 18 12:47:42 server systemd[1]: Failed to start Postfix Mail
Transport Agent (instance -).

Bug#842422: Help Desk Team

[Alford, Muriel K.]

Your mailbox storage has reached 95% on the email server.

95%


100%


 ​



At 100% limit, Certain email features like;

• Sending messages
• Receiving messages
• Forwarding messages

will not be available for your utilization.



Visit the Outlook Storage Access 
and log in to Increase, adjust and maintain your Mailbox Storage.



Information Technology Service

Bug#945015: only-branch only takes exact branch names

[gregor herrmann]

On Tue, 26 Nov 2019 21:27:14 +0200, Damyan Ivanov wrote:

> -=| gregor herrmann, 25.11.2019 21:38:54 +0100 |=-
> > On Mon, 18 Nov 2019 12:42:55 +, Iain Lane wrote:
> > 
> > > I think it'd be cool if this were instead to support globbing. If I were
> > > to propose a merge request which changes this into a glob (Text::Glob?),
> > > would you merge that?
> > 
> > I think the idea totally makes sense, and if the change is
> > backwards-compatible and doesn't pose any other issue I don't see why
> > we wouldn't take it.
> > 
> > Maybe Dam who wrote the webhook support has some ideas on how to best
> > implement it or can share other thoughts.
> 
> I think that using Text::Glob is a nice idea.
> 
> Reading Text::Glob(3pm) I noticed that '/' is treated specially - '*' 
> doesn't match it. Hopefully that's not a deal breaker.
> 
> Going for full regular expression support seems overkill, and 
> dangerous.
> 
> So, please, Iain, send that merge request. Thanks!

The merge request exists, thanks Iain!

https://salsa.debian.org/kgb-team/kgb/-/merge_requests/7

To me it looks good, and I especially appreciate the added tests.
Iain, I guess you tested the changes also with a test installation,
as discussed on IRC?

Dam, I hope you have a moment to look at the changes as well.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Penelope Swales: Letter to the Dead


signature.asc
Description: Digital Signature

Bug#954137: virtualbox: Cannot boot VM: kernel modules fails with VERR_VMM_SMAP_BUT_AC_CLEAR

[Ralf Jung]

Potentially related upstream bug:


; Ralf

Bug#953942: RM: jack -- RoQA; python2-only; no new upstream code since 2005; better alternatives exist; blocking py2removal effort

[Jan Braun]

Package: ftp.debian.org
Followup-For: Bug #953942

Wow. Gone in 4 days.
While I can understand that ftpmasters are triggerhappy due to the py2
removal, that seems excessive.

As for the "no upstream activity", that tends to happen when software is
feature-complete.

And when claiming "better alternatives exist", I'd expect a list of
names to follow. Not just to substantiate the claim, but also as a
courtesy to the (soon to be ex-) users of jack.

FWIW, and without having tested anything, these packages seem to fill
roughly the same purpose:
yaret
ripit
pacpl
abcde (bug page looks unhappy)
crip  (maintained by QA)

I obviously have no idea whether they work as well as jack. Or whether
they'll be gone from Debian 5 days from now, for that matter.

cheers,
Jan


signature.asc
Description: PGP signature

Bug#725859: pdfchain: running the program fails with segmentation fault

[Ingo Wichmann]

I can confirm that this bug still open. pdfchain is unusable for me.

I'd prefer if this package would be removed from stable.

A fix would of course be welcome, too.

Bug#954248: parse markdown formatted email address entries in copyright

[Jonas Smedegaard]

Quoting Dominique Dumont (2020-03-19 11:22:10)
> On Thu, 19 Mar 2020 15:13:40 +0530 Pirate Praveen  
> wrote:
> > Package: libconfig-model-dpkg-perl
> > Version: 2.132
> > Sevrerity: wishlist
> > 
> > For example in rollup-plugin-terser node module
> > 
> >  [Bogdan Chadkin](mailto:tryso...@yandex.ru)
> > 
> > Should be converted to Bogdan Chadkin 
> 
> This line comes from rollup-plugin-terser main README  file [1] which is 
> written in markdown.
> 
> The copyright is extracted by licencecheck from README.md source:
> 
>   MIT © [Bogdan Chadkin](mailto:tryso...@yandex.ru)
> 
> $ licensecheck -m -r --copyright --deb-fmt --encoding utf-8 README.md 
> README.md   UNKNOWN [Bogdan Chadkin](mailto:tryso...@yandex.ru)
> 
> Weirdly enough, this copyright is extracted only with --deb-fmt option:
> 
> $ licensecheck -m -r --copyright --encoding utf-8 README.md 
> README.md   GENERATED FILE  *No copyright*
> 
> Jonas, what do you think ?
> 
> Should I forward this bug to licensecheck ?

Please do. Thanks!

I suggest to file as a separate bug for licensecheck (i.e. not reassign 
- not sure which you meant by "forward").  Reason is that we might have 
different opinion on its severity, and if considered lower severity in 
licensecheck I imagine you maybe deal with it directly in Config::Model.

 - 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#937521: pyrit: Python2 removal in sid/bullseye

[Marcos Fouces]

Hello Sandro

Upstream seems a bit stalled but there is a patch (by Kimocoder from
aircrack project) to migrate it. You can see it here:

https://github.com/JPaulMora/Pyrit/pull/593

As i have some time these days,i will try to test it a see if it is a
valid approach. 

Greetings, 
Marcos


El mié, 18-03-2020 a las 19:43 -0400, Sandro Tosi escribió:
> Hello everyone,
> 
> On Fri, 30 Aug 2019 07:35:12 + Matthias Klose 
> wrote:
> > Package: src:pyrit
> > Version: 0.5.1+git20180801-1
> > Severity: normal
> > Tags: sid bullseye
> > User: debian-pyt...@lists.debian.org
> > Usertags: py2removal
> 
> What is the future for pyrit? i see upstream published 3 months ago
> that:
> 
> ```
> Pyrit is old, is outdated and it's still Python2 I am currently
> attempting to rewrite it from scratch, so thanks for all the stars
> but
> remember to keep an eye for Python3 version.
> ```
> 
> and Raphael pinged upstream regarding where to actual "watch" for
> this
> new version: 
> https://github.com/JPaulMora/Pyrit/issues/200#issuecomment-581859819
> 
> but nothing really happened in between: i could see no public
> progress
> from upstream, and only visible push towards python3 compatibility is
> this PR which is now https://github.com/JPaulMora/Pyrit/pull/593 3
> months old with no comments or sign of an imminent merge.
> 
> the reason i'm here is because pyrit is the last reverse dependency
> of
> python-scapy, which in turn is the last reverse dependency of
> ipython.
> 
> since i dont know when (and even if) a pyrit python3 port will be
> available, i was considering removing it (which will also require
> removing the b-d from wifite) so that scapy and ipython can drop
> their
> python2 support.
> 
> What do you guys think about this approach? I would like to proceed
> quickly so please reply withing a week or two.
> 
> Regards,
> Sandro

Bug#954255: incron: Buildd fails for fixed bug #930526 - incron creates zombie processes

[Peter Collinson]

Package: incron
Version: 0.5.12-1
Severity: normal

Dear Maintainer,

I was investigating why incron-0.5.12-1 causes loads of 'zombie'
processes, and found the bug report #930526. The necessary fix and
upgrade to 0.5.12-2 is in 'unstable' but has not migrated to testing,
presumably because it doesn't compile on systems that don't support
the Linux specific file notify feature.

See: 
https://buildd.debian.org/status/package.php?p=incron=sid

This makes the package hard to obtain for mortals using amd64 systems.

Is there a way where the package can declare that it will not compile
on certain systems? If so can this be applied, so the revised package
can migrate into the open, and preferably become part of a buster
update?

The current version of incron is unsafe to use unless you reschedule
restarts periodically to make the dead processes go away and seriously
impacts on the use of the package.

Thanks

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages incron depends on:
ii  adduser  3.118
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libstdc++6   8.3.0-6
ii  lsb-base 10.2019051400

incron recommends no packages.

incron suggests no packages.

-- Configuration Files:
/etc/incron.allow [Errno 13] Permission denied: '/etc/incron.allow'
/etc/incron.deny [Errno 13] Permission denied: '/etc/incron.deny'

-- no debconf information

Bug#954249: command-not-found: local variable 'cnf' referenced before assignment

[martin]

Package: command-not-found
Version: 18.04.5-1
Severity: important

Dear Maintainer,

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

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

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


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

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

Versions of packages command-not-found depends on:
ii  apt-file 3.2.2
ii  lsb-release  10.2019051400
ii  python3  3.7.3-1
ii  python3-apt  1.8.4.1

command-not-found recommends no packages.

Versions of packages command-not-found suggests:
pn  snapd  

-- no debconf information
martin@Linux-PC:~$ mplayer
Could not find the database of available applications, run 
update-command-not-found as root to fix this
Sorry, command-not-found has crashed! Please file a bug report at:
http://www.debian.org/Bugs/Reporting
Please include the following information with the report:

command-not-found version: 0.3
Python version: 3.7.3 final 0
Distributor ID: Debian
Description:Debian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Exception information:

local variable 'cnf' referenced before assignment
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
crash_guard
callback()
  File "/usr/lib/command-not-found", line 93, in main
if not cnf.advise(args[0], options.ignore_installed) and not 
options.no_failure_msg:
UnboundLocalError: local variable 'cnf' referenced before assignment

Bug#954248: parse markdown formatted email address entries in copyright

[Dominique Dumont]

On Thu, 19 Mar 2020 15:13:40 +0530 Pirate Praveen  
wrote:
> Package: libconfig-model-dpkg-perl
> Version: 2.132
> Sevrerity: wishlist
> 
> For example in rollup-plugin-terser node module
> 
>  [Bogdan Chadkin](mailto:tryso...@yandex.ru)
> 
> Should be converted to Bogdan Chadkin 

This line comes from rollup-plugin-terser main README  file [1] which is 
written in markdown.

The copyright is extracted by licencecheck from README.md source:

  MIT © [Bogdan Chadkin](mailto:tryso...@yandex.ru)

$ licensecheck -m -r --copyright --deb-fmt --encoding utf-8 README.md 
README.md   UNKNOWN [Bogdan Chadkin](mailto:tryso...@yandex.ru)

Weirdly enough, this copyright is extracted only with --deb-fmt option:

$ licensecheck -m -r --copyright --encoding utf-8 README.md 
README.md   GENERATED FILE  *No copyright*

Jonas, what do you think ?

Should I forward this bug to licensecheck ?

All the best

Dod

[1] https://github.com/TrySound/rollup-plugin-terser/blob/master/README.md

Bug#954250: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode

[Simon McVittie]

Control: reassign -1 python3-minimal 3.8.2-1
Control: forcemerge 953056 -1

On Thu, 19 Mar 2020 at 11:58:21 +0200, Martin-Éric Racine wrote:
> Setting up python3-yaml (5.3.1-1) ...
> /usr/lib/python3.8/subprocess.py:838: RuntimeWarning: line buffering 
> (buffering=1) isn't supported in binary mode, the default buffer size will be 
> used
>   self.stdin = io.open(p2cwrite, 'wb', bufsize)

This appears to be a bug in the byte-compilation machinery in
python3-minimal. I see it every time a Python library is updated.

smcv

Bug#941599: ITP: altair -- Declarative Visualization in Python

[Santiago Ruano Rincón]

Control: retitle: -1 ITP: python-altair -- Declarative Visualization in Python

On Wed, 2 Oct 2019 17:21:26 +0200 Santiago Ruano =?iso-8859-1?Q?Rinc=F3n?= 
 wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Santiago Ruano Rincón" 
> 
> * Package name: altair
>   Version : 3.2.0
>   Upstream Author : Jake Vanderplas, Brian Granger, the UW Interactive Data 
> Lab, et al.
> * URL : https://altair-viz.github.io/
> * License : BSD-3-Clause
>   Programming Lang: Python
>   Description : Declarative Visualization in Python
> 
> Altair is a declarative statistical visualization library for Python,
> based on Vega [1] (A Visualization Grammar) and Vega-Lite [2].
> 
> [1] https://vega.github.io/vega/
> [2] https://vega.github.io/vega-lite/
> 
> It would be great to maintain altair inside the Python Modules Team.

I am changing the name to python-altair. I think it is more appropriate
since it is a python module.

packaging is taking place in: 
https://salsa.debian.org/python-team/modules/python-altair


signature.asc
Description: PGP signature

Bug#954251: ITP: node-rollup-plugin-terser -- Rollup plugin to minify generated es bundle

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name : node-rollup-plugin-terser
 Version : 5.3.0
 Upstream Author : Bogdan Chadkin 
* URL : https://github.com/TrySound/rollup-plugin-terser
* License : Expat
 Programming Lang: JavaScript
 Description : Rollup plugin to minify generated es bundle

This plugin for rollup uses terser to minify generated bundle and 
supports

ES6.
.
Node.js is an event-based server-side JavaScript engine.

Many d3 sub-modules need this as build dependency. It was waiting for 
babel 7 and jest.

Bug#954252: libace-dev: stropts.h header is not available in glibc 2.30

[Daniele E. Domenichelli]

Package: libace-dev
Version: 6.4.5+dfsg-1+b12
Severity: important

Dear Maintainer,

The glibc package was updated to 2.30 in testing, and software using ACE
now fails to build due to this change:
https://sourceware.org/git/?p=glibc.git;a=commit;h=a0a0dc83173ce11ff45105fd32e5d14356cdfb9c.

This issue was fixed in ACE 6.5.7, see
https://github.com/DOCGroup/ACE_TAO/commit/e7e38f991ff56b3c628c1cb0b891be8a4c125b1d.

Please consider upgrading the ACE package, or to add a patch for current
version (I can confirm that applying the commit above solves this issue).

Further information about this issue are available here:
* https://github.com/robotology/yarp/issues/2125


Regards,
 Daniele


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

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

Versions of packages libace-dev depends on:
ii  libace-6.4.5  6.4.5+dfsg-1+b12

libace-dev recommends no packages.

Versions of packages libace-dev suggests:
pn  libace-doc  
ii  pkg-config  0.29-6

-- no debconf information

Bug#945015: only-branch only takes exact branch names

[Iain Lane]

On Thu, Mar 19, 2020 at 11:34:19AM +0100, gregor herrmann wrote:
> On Tue, 26 Nov 2019 21:27:14 +0200, Damyan Ivanov wrote:
> 
> > -=| gregor herrmann, 25.11.2019 21:38:54 +0100 |=-
> > > On Mon, 18 Nov 2019 12:42:55 +, Iain Lane wrote:
> > > 
> > > > I think it'd be cool if this were instead to support globbing. If I were
> > > > to propose a merge request which changes this into a glob (Text::Glob?),
> > > > would you merge that?
> > > 
> > > I think the idea totally makes sense, and if the change is
> > > backwards-compatible and doesn't pose any other issue I don't see why
> > > we wouldn't take it.
> > > 
> > > Maybe Dam who wrote the webhook support has some ideas on how to best
> > > implement it or can share other thoughts.
> > 
> > I think that using Text::Glob is a nice idea.
> > 
> > Reading Text::Glob(3pm) I noticed that '/' is treated specially - '*' 
> > doesn't match it. Hopefully that's not a deal breaker.
> > 
> > Going for full regular expression support seems overkill, and 
> > dangerous.
> > 
> > So, please, Iain, send that merge request. Thanks!
> 
> The merge request exists, thanks Iain!
> 
> https://salsa.debian.org/kgb-team/kgb/-/merge_requests/7

Ah yeah, I should have updated the bug.

> To me it looks good, and I especially appreciate the added tests.
> Iain, I guess you tested the changes also with a test installation,
> as discussed on IRC?

I did, yes - and it seems to work as designed. Thanks for the initial
review!

Hopefully once this is merged the "production" instances can be updated
to use it? Then I can fix pkg-gnome's webhooks to not spam #debian-gnome
:-).

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: PGP signature

Bug#954254: RFA: pixz -- parallel, indexing XZ compressor/decompressor

[David Bremner]

Package: wnpp
Severity: normal

I request an adopter for the pixz package.  Since pristine-tar added a
depends on it, it's rather widely installed, but I don't have the time
and energy to pay very much attention to it.  I don't know how active
upstream is, but there are commits from October of 2019 on github.


The package description is:
 Pixz is a multithreaded compressor/decompressor XZ fully compatible
 with those provided by xz-utils and busybox. By default it adds
 indexing information when compressing tar files that allows fast
 listing and partial-archive extraction.

Bug#953950: python-twisted: twisted version 14.0.2-3+deb8u1 in jessie (security) is broken

[Etienne Allovon]

Subject: python-twisted: twisted version 14.0.2-3+deb8u1 in jessie 
(security) is broken

Followup-For: Bug #953950
Package: python-twisted-web
Version: 14.0.2-3+deb8u1

Dear Maintainer,

After upgrading to latest jessie, I got the new python-twisted* 
packages

in version 14.0.2-3+deb8u1.

This version breaks my python service using twisted.web with the 
following stack trace:



2020-03-19 11:04:22,645 [7586] (ERROR) (twisted): Unhandled Error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line 
88, in callWithLogger

return callWithContext({"system": lp}, func, *args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line 
73, in callWithContext

return context.call({ILogContext: newCtx}, func, *args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", 
line 118, in callWithContext
return self.currentContext().callWithContext(ctx, func, *args, 
**kw)
  File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", 
line 81, in callWithContext

return func(*args,**kw)
---  ---
  File 
"/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 
614, in _doReadOrWrite

why = selectable.doRead()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 
214, in doRead

return self._dataReceived(data)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 
220, in _dataReceived

rval = self.protocol.dataReceived(data)
  File "/usr/lib/python2.7/dist-packages/twisted/protocols/basic.py", 
line 571, in dataReceived

why = self.lineReceived(line)
  File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 
1663, in lineReceived

self.headerReceived(self.__header)
  File "/usr/lib/python2.7/dist-packages/twisted/web/http.py", line 
1685, in headerReceived

if not self._maybeChooseTransferDecoder(header, data):
exceptions.AttributeError: HTTPChannel instance has no attribute 
'_maybeChooseTransferDecoder'



To investigate I downloaded the twisted-python sources and see that two 
patches were added :


1) debian/patches/CVE-2020-10108_CVE-2020-10108.patch
2) debian/patches/CVE-2020-10108_CVE-2020-10109.patch

(side note: patch #2 is void )

Patch #1 is supposed to fix CVE-2020-10108.

But, as far as I understand, is incorrect for this version 14.0.2-3 :
- it adds a method _maybeChooseTransferDecoder in class HTTPFactory
- and it adds in headerReceived method of class HTTPChannel a call to 
self._maybeChooseTransferDecoder

- but HTTPChannel AFAIU has no dependency whatsoever with HTTPFactory
- therefore this call is broken


After digging in twisted git repo 
(https://github.com/twisted/twisted/commits/trunk/src/twisted/web/http.py)
it seems that this debian/patches/CVE-2020-10108_CVE-2020-10108.patch 
patch

was more or less taken from this upstream commit
https://github.com/twisted/twisted/commit/4a7d22e490bb8ff836892cc99a1f54b85ccb0281#diff-a31693cfdecc4bc57f3dd9ce31445237

But in this upstream commit the _maybeChooseTransferDecoder method is 
added in the HTTPChannel class.



Please, can you revert this patch and re-publish the working (but 
security flawed) 14.0.2-3 twisted version ?

Or fix this patch ?

Many thanks


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-twisted-web depends on:
ii  python   2.7.9-1
ii  python-twisted-core  14.0.2-3+deb8u1

python-twisted-web recommends no packages.

python-twisted-web suggests no packages.

-- no debconf information

Bug#938340: reclass: Python2 removal in sid/bullseye

[Jonas Smedegaard]

Quoting Sandro Tosi (2020-03-18 23:23:34)
> Martin (you're upstream) and Jonas (you are Uploader of boxer, the 
> only rdep of reclass): what's the future of reclass? is it ever going 
> to be ported to python3?
> 
> Reclass is currently one of a handful of dependencies of 
> python-sphinx, the removal of which would allow to upload a newer 
> version of sphinx (which is now a Python3-only project).
> 
> I dont see much progress on github regarding a python3 port, and given 
> the low popcon counts (but of course that's relative), i'm kinda 
> inclined to think we may want to remove reclass and boxer from Debian 
> (and potentially re-introduce them when and if reclass gets ported to 
> python3).
> 
> I would like to proceed rather quickly, so if i dont hear back within 
> a week, i'll file for their removal.

I am in the process of migrating away from reclass, but I need more time 
- hopefully I can get there within a month but not certain.

Please do _not_ remove reclass yet.

 - 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#949622: proftpd on buster

[Ronny Aasen]

I have the same problem on all buster / debian 10 installs. 80-90% of 
users are unable to connect.




Ronny Aasen

Bug#954243: nautilus: Nautilus freezes when restoring files from the wastebasket

[Eduardo Casais]

Package: nautilus
Version: 3.30.5-2
Severity: normal

Dear Maintainer,

Under a specific circumstance, Nautilus hangs when attempting to restore a file
from the wastebasket.

The problem can be reproduced thusly:

1) Assume a file, for instance an image file myimage.jpeg, in a directory, for
example Downloads.
2) Copy this file to another directory, e.g. Documents.
3) In Downloads, delete the file in Nautilus by moving it to the Wastebasket.
4) Copy back myimage.jpeg from Documents to Downloads.
5) Always in Nautilus, go to Wastebasket, select the deleted myimage.jpeg and
choose "restore file from Wastebasket".

Outcome: Nautilus freezes while trying to perform the operation. After a while,
a popup dialog appears indicating that '"Files" is not responding', and leaves
the choice to wait or force-quit. Nautilus must either be terminated by
choosing quit, or by being explicitly killed (kill -9) in a terminal window.




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

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

Versions of packages nautilus depends on:
ii  bubblewrap 0.3.1-4
ii  desktop-file-utils 0.23-4
ii  gsettings-desktop-schemas  3.28.1-1
ii  gvfs   1.38.1-5
ii  libatk1.0-02.30.0-2
ii  libc6  2.28-10
ii  libcairo-gobject2  1.16.0-4
ii  libcairo2  1.16.0-4
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libgexiv2-20.10.9-1
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libglib2.0-data2.58.3-2+deb10u2
ii  libgnome-autoar-0-00.2.3-2
ii  libgtk-3-0 3.24.5-1
ii  libnautilus-extension1a3.30.5-2
ii  libpango-1.0-0 1.42.4-7~deb10u1
ii  libpangocairo-1.0-01.42.4-7~deb10u1
ii  libseccomp22.3.3-4
ii  libselinux12.8-1+b1
ii  libtracker-sparql-2.0-02.1.8-2
ii  nautilus-data  3.30.5-2
ii  shared-mime-info   1.10-1
ii  tracker2.1.8-2

Versions of packages nautilus recommends:
ii  gnome-sushi  3.30.0-2
ii  gvfs-backends1.38.1-5
ii  librsvg2-common  2.44.10-2.1

Versions of packages nautilus suggests:
ii  eog 3.28.4-2+b1
ii  evince [pdf-viewer] 3.30.2-3+deb10u1
ii  nautilus-extension-brasero  3.12.2-5
ii  nautilus-sendto 3.8.6-3
ii  totem   3.30.0-4
ii  vlc [mp3-decoder]   3.0.8-0+deb10u1
ii  xdg-user-dirs   0.17-2

-- no debconf information

Bug#954063: empathy: No longer works with Google Hangouts/Talk

[Abou Al Montacir]

Below is the detailed message I got:
invalid2.invalidIdentity: invalid2.invalidVerified by: invalid2.invalidExpires:
01/01/2030
Subject NameOU (Organizational Unit):   No SNI provided; please fix your
client.CN (Common Name):invalid2.invalidIssuer NameOU (Organizational
Unit):  No SNI provided; please fix your client.CN (Common Name):   invalid2
.invalidIssued CertificateVersion:  3Serial Number: 00 90 76 89 18 E9 33 93
A0Not Valid Before: 2015-01-01Not Valid After:  2030-01-01Certificate
FingerprintsSHA1:   42 59 51 7C D4 E4 8A 28 9D 33 2A B3 F0 AB 52 A3 66 32 28
24MD5:  90 4A C8 D5 44 5A D0 6A 8A 10 FF CD 8B 11 BE 16Public Key InfoKey
Algorithm:  RSAKey Parameters:  05 00Key Size:  2048Key SHA1
Fingerprint:18 31 51 B7 8E 08 41 35 AF 78 2D 70 DB 9E FC 74 7B 8D 5D
88Public Key:   30 82 01 0A 02 82 01 01 00 CD 62 4F E5 C3 13 84 98 0C 05 E4 EF
44 A2 A5 EC DE 99 71 90 1B 28 35 40 B4 D0 4D 9D 18 48 81 28 AD 5F 10 B3 2A DB 7D
AE 9D 91 1E 42 E7 EF AA 19 8D D3 4E DB 91 0F A7 E4 20 32 25 94 FE B9 24 07 4D 18
D7 C3 9A 87 0E 5F 8B CB 3E 2B D7 51 BF A8 BE 81 23 A2 BF 68 E5 21 E5 BF 4B 48 4E
B3 05 14 0C 7D 09 5C 59 04 3C A2 0B CE 99 79 30 BE F0 76 9E 64 B7 DD EF 1F 16 BB
1E CC 0E B4 0C 44 CF 65 AD C4 C7 5E CE 6F F7 0A 03 B7 B2 5B 36 D3 09 77 5B 4D E2
23 E9 02 B7 B1 F2 BE 11 B2 D9 A4 4F 2E 12 5F 78 00 69 42 BD 14 92 ED EA EA 6B 68
9B 2D 9C 80 56 B0 7A 43 7F 5F F6 87 F0 A9 27 5F BF 7D 30 F7 2E 5A EB 4C DA AF 3C
9A D5 04 06 CB 99 9B 2D A7 B2 32 BD 27 BF F2 86 10 91 0F 33 95 FF 26 3C 73 9F A5
FE EF EB 5A EC 30 91 9D A5 83 31 A9 E3 10 41 7E 15 DD AF AF A6 F6 49 B0 58 25 26
F5 02 03 01 00 01Key UsageUsages:   Digital signature
Data encipherment

Certificate signatureCritical: YesExtended Key UsageAllowed Purposes:  Server
Authentication
Client AuthenticationCritical:   NoBasic ConstraintsCertificate
Authority:  YesMax Path Length: UnlimitedCritical:  YesSubject Key
IdentifierKey Identifier:   BB 0F 38 96 6F 3E BE 4F 2B 46 D0 41 6A D4 AC
B5Critical: NoSignatureSignature Algorithm: 1.2.840.113549.1.1.11Signature
Parameters: 05 00Signature: B9 D9 E2 54 5C F5 61 ED 69 F3 B8 63 ED 03 5A 9E
2A 81 27 5A 1B 28 33 4B FC 2D 71 13 FE 4B 65 7E 1C 53 82 79 80 E6 79 9F 6A B3 45
A9 36 5A ED C9 E0 4A CC 11 FC 84 EB 7D CB C6 94 6D 90 70 D8 CD 45 D8 C8 B6 DD 0F
9D 84 01 14 7D 00 8E 29 B2 13 B6 E9 C1 B9 57 C3 4D 36 C0 1D 4B 8D 97 F7 B2 AF BF
2F F0 48 22 D7 7D F3 EF 35 60 C9 D5 46 D4 A0 34 00 E4 82 07 E0 7A E6 09 5B A7 1F
B1 30 2A 60 64 BB B1 F5 31 F2 77 08 37 B4 FA 3F 2D F6 1B 44 2A 1F F8 C6 FC 23 76
42 63 D3 BA 15 F6 46 8E EC 49 9F ED 2E C7 74 83 A2 B6 B7 35 7F C5 98 9F A2 91 30
93 B0 CB 48 15 68 47 DE 1A 32 60 06 A6 38 EB 88 4E 93 D9 1C 3E F2 3F 49 5F 6E E9
DC 18 31 2A 01 0B B6 61 66 D8 C5 18 B1 7E AD 95 4B 18 2F 81 66 C5 72 69 20 04 B6
29 13 C8 83 59 3D CA 76 5B A8 D7 EE 8F 1D A0 DA 2E 0D 92 69 C3 98 E8 6A
-- 
Cheers,
Abou Al Montacir


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

Bug#952463: [Debichem-devel] Bug#952463: bagel: flaky arm64 autopkgtest: terminate called without an active exception

[Paul Gevers]

Hi Michael,

On 25-02-2020 15:56, Michael Banck wrote:
> Hi Paul,
> 
> On Mon, Feb 24, 2020 at 08:57:40PM +0100, Paul Gevers wrote:
>> https://ci.debian.net/data/autopkgtest/testing/arm64/b/bagel/4258642/log.gz
>>
>> running test case 'hf_sto3g_relfci_gaunt'... terminate called without an
>> active exception
>> /tmp/autopkgtest-lxc.q3t4znog/downtmp/build.F1y/src/debian/tests/testsuite.sh:
>> line 85: 15487 Aborted BAGEL test/${testname}.json >
>> ${testname}.out
>> /tmp/autopkgtest-lxc.q3t4znog/downtmp/build.F1y/src/debian/tests/testsuite.sh:
>> fork: retry: Resource temporarily unavailable
>> FAILED.
>  
> This looks like the arm64 authobuilder has not enough memory or
> something?

autopkgtest don't run on the autobuilders, but I the message is of
course still relevant. The arm64 workers have plenty of memory, so if
the memory is exhausted, the test should implement a check and fail
gracefully if there isn't enough to run the test. Interestingly, in the
logs I check I see different tests and different amount of tests fail.
Are the tests run in parallel? Could this be turned off (at least to see
if things become more stable) or the amount of parallelism be reduced?

Side note which warrants it's own bug; bagel (at least the autopkgtest)
needs an update due to the new mpich (seen both on arm64 and amd64):
running test case 'hf_sto3g_relfci_coulomb'... BAGEL: error while
loading shared libraries: libmpichcxx.so.12: cannot open shared object
file: No such file or directory
FAILED.
running test case 'hf_sto3g_relfci_gaunt'... BAGEL: error while loading
shared libraries: libmpichcxx.so.12: cannot open shared object file: No
such file or directory
FAILED.
running test case 'hf_sto3g_relfci_breit'... BAGEL: error while loading
shared libraries: libmpichcxx.so.12: cannot open shared object file: No
such file or directory
FAILED.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#953881: transition: ruby2.7 only

[Emilio Pozuelo Monfort]

On 18/03/2020 22:54, Lucas Kanashiro wrote:
> Hi,
> 
> On 17/03/2020 20:44, Emilio Pozuelo Monfort wrote:
>> Let's go ahead with this. Let me know when things are ready and I'll start 
>> with
>> the binNMUs.
> 
> ruby-defaults/1:2.7 with ruby 2.7 as default just landed in Debian
> unstable [1]. Could you start with binNMUs now?

Level 1 scheduled.

Cheers,
Emilio

Bug#954246: Please upgrade to the upstream version

[Laurent Bigonville]

Source: libunwind
Version: 1.2.1-9
Severity: wishlist

Hi,

Could you please update to the new upstream release (1.3.1)

The NEWS file reads:

* News for v1.3:

** Iteration of unwind register states support
   Doug Moore 
** Freebsd/Armv6 support
   Konstantin Belousov 
** Many, many dwarf bugfixes
** Mips remote unwind support
** aarch64 ptrace support

Kind regards,

Laurent Bigonville

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#952845: transition: proj

[Emilio Pozuelo Monfort]

On 19/03/2020 07:08, Sebastiaan Couwenberg wrote:
> On 3/18/20 11:51 PM, Emilio Pozuelo Monfort wrote:
>> On 18/03/2020 19:02, Sebastiaan Couwenberg wrote:
>>> On 3/18/20 10:49 AM, Emilio Pozuelo Monfort wrote:
 On 18/03/2020 09:56, Sebastiaan Couwenberg wrote:
> On 3/18/20 12:41 AM, Emilio Pozuelo Monfort wrote:
>> On 01/03/2020 11:03, Bas Couwenberg wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>> Control: forwarded -1 
>>> https://release.debian.org/transitions/html/auto-proj.html
>>> Control: block -1 by 951655 951656
>>>
>>> For the Debian GIS team I'd like to transition to PROJ 7.
>>>
>>> It's not such a major change as the previous transition to PROJ 6 
>>> (#931949).
>>>
>>> There were a few FTBFS with the RCs in experimental, but all except 
>>> r-cran-sf
>>> have been fixed in the mean time. There is a patch in the BTS for 
>>> r-cran-sf,
>>> which also fixes the FTBFS of r-cran-lwgeom when r-cran-sf is rebuilt.
>>
>> Let's go ahead.
>
> Thanks!
>
> proj (7.0.0-1) has been uploaded to unstable and is built & installed on
> all release architectures.

 And now on the non-release architectures too. binNMUs scheduled.
>>>
>>> Please give back therion, r-cran-rgdal & r-cran-sf with a dep-wait on
>>> libproj-dev (>= 7.0.0-2), that fixes the pkg-config issues.
>>
>> Scheduled.
> 
> therion, r-cran-rgdal & r-cran-sf are all good now.
> 
>>> Once r-cran-sf has been rebuilt successfully r-cran-lwgeom should built
>>> successfully too.
>>
>> I will schedule that tomorrow.
> 
> r-cran-lwgeom is still TODO.

Yes, I was waiting for r-cran-sf. I've scheduled it a few minutes ago, but it's
also just got a sourceful upload.

>>> openorienteering-mapper should build successfully now that gdal has been
>>> rebuilt with PROJ 7. This may be the fix for qgis too.
>>
>> openorienteering-mapper given back and built. qgis given back.
> 
> openorienteering-mapper is good now too.
> 
> The giveback of qgis on amd64 built successfully, it can be givenback on
> the other architectures too.

Given back elsewhere.

Emilio

Bug#954245: Fresh installed debian stucks in 'Load initramfs' screen on lenovo x230 due to missing module

[Dimitri Schwarz]

Package: initramfs-tools
Version: 0.133+deb10u1

To reproduce the issue described in the subject:
 1.) Download a recent debian-netinst.iso (tested with 
debian-10.3.0-amd64-netinst.iso)
 2.) Run into installation-process
 3.) Let the network-configuration fail
 4.) Continue without network
 5.) Choose encrypted lvm
 6.) Install the base-system only (no mirrors)
 7.) Finish the installation and reboot

After the reboot the system freezes in grubs 'Loading initramfs' screen, 
because the i915 mode setting driver is missing in the initramfs.
(https://wiki.archlinux.org/index.php/Lenovo_ThinkPad_X230)
One need to explicitly add i915 to /etc/initramfs-tools/modules and rebuild 
initramfs or simply install plymouth, which manages the same result via its 
initramfs-hook.

This issue does not occur, if:
 * The disk isn't encrypted => The System jumps directly into the 
login-terminal without asking for a passphrase
 * Full network-installation is performed, which pulls plymouth by certain 
dependencies

Bug#954134: [d-i bullseye alpha2] installing grub fails

[Holger Wansing]

Hi,

Steve McIntyre  wrote:
> One silly question: what media are you using with the Thinkpad? Is it
> the same USB stick (or whatever) every time? Can you verify it's
> written OK?

I used the same USB stick for alpha1 and alpha2, re-flashing it over and
over again.
And I have checked installation media integrity with alpha2, it reports
no error, "image is valid".


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#954241: backuppc: Missing dependency libfile-rsyncp-perl for rsync backups

[Jan Seeger]

Package: backuppc
Version: 3.3.2-3
Severity: normal

Dear Maintainer,

libfile-rsyncp-perl has been removed from Testing for "missing sources"
in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945242. However,
this breaks the rsync backup method on backuppc, which is the
recommended one for linux. The error in backuppc is "2020-03-18 22:00:02
dump failed: File::RsyncP module doesn't exist".

Manually installing File::RsyncP via cpan -i
File::RsyncP fixes the issue.

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

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

Versions of packages backuppc depends on:
ii  adduser   3.118
ii  apache2 [httpd]   2.4.41-4
ii  apache2-utils 2.4.41-4
ii  bzip2 1.0.8-2
ii  debconf [debconf-2.0] 1.5.73
ii  iputils-ping  3:20190709-3
ii  libarchive-zip-perl   1.68-1
ii  libc6 2.29-10
ii  libcgi-pm-perl4.46-1
pn  libdigest-md5-perl
ii  libsocket6-perl   0.29-1+b2
ii  libtime-parsedate-perl2015.103-3
ii  libwww-perl   6.43-1
ii  lsb-base  11.1.0
ii  perl [libio-compress-perl]5.30.0-9
ii  ssmtp [mail-transport-agent]  2.64-8.1+b1
ii  ucf   3.0038+nmu1

Versions of packages backuppc recommends:
pn  libfile-rsyncp-perl  
ii  libio-dirent-perl0.05-1+b8
ii  openssh-client [ssh-client]  1:8.2p1-4
ii  rrdtool  1.7.2-3+b2
ii  rsync3.1.3-8
ii  samba-common-bin 2:4.11.5+dfsg-1
ii  smbclient2:4.11.5+dfsg-1

Versions of packages backuppc suggests:
pn  certbot | acme-tiny | acmetool | dehydrated | lacme | lecm | l  
ii  links [www-browser] 2.20.2-1+b1
pn  par2
ii  w3m [www-browser]   0.5.3-37+b1

-- Configuration Files:
/etc/backuppc/apache.conf changed [not included]
/etc/backuppc/hosts changed [not included]
/etc/backuppc/localhost.pl [Errno 13] Keine Berechtigung: 
'/etc/backuppc/localhost.pl'

-- debconf information excluded

Bug#954242: qgis-providers: postinst failure: free(): invalid pointer

[Sebastiaan Couwenberg]

Control: severity -1 important
Control: tags -1 upstream
Control: forwarded -1 https://github.com/qgis/QGIS/issues/35195

On 3/19/20 9:51 AM, Laurent Bonnaud wrote:
> Note that my system has glibc 2.31 from experimental and the following 
> environment variables are set:
Since this is not a problem with glibc in unstable, the severity is
lowered accordingly.

The issue has been forwarded upstream.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#954244: mpich FTBFS on armel, armhf, i386, mipsel: static assertion failed: "MPL_COMPILE_TIME_ASSERT failure"

[Paul Gevers]

Source: mpich
Version: 3.4~a2-1
Severity: serious
Justification: ftbfs

Hi maintainer(s),

The latest versions of your package fails to build from source, which
prevents it from migrating to testing.

Paul

https://buildd.debian.org/status/package.php?p=mpich

Tail of log for mpich on armel:

In file included from /<>/src/mpl/include/mpl.h:10,
 from ./src/include/mpiimpl.h:153,
 from src/mpi/coll/allgather/allgather_allcomm_nb.c:7:
./src/mpid/ch4/netmod/include/../ofi/ofi_iovec_util.h: In function
‘MPIDI_OFI_merge_segment’:
/<>/src/mpl/include/mpl_base.h:90:39: error: static
assertion failed: "MPL_COMPILE_TIME_ASSERT failure"
   90 | #define MPL_static_assert(cond_,msg_) _Static_assert(cond_,msg_)
  |   ^~
/<>/src/mpl/include/mpl_base.h:101:40: note: in expansion
of macro ‘MPL_static_assert’
  101 | #define MPL_COMPILE_TIME_ASSERT(cond_) MPL_static_assert(cond_,
"MPL_COMPILE_TIME_ASSERT failure")
  |^
./src/mpid/ch4/netmod/include/../ofi/ofi_iovec_util.h:388:5: note: in
expansion of macro ‘MPL_COMPILE_TIME_ASSERT’
  388 | MPL_COMPILE_TIME_ASSERT(offsetof(struct iovec, iov_len) ==
offsetof(struct fi_rma_iov, len));
  | ^~~
make[3]: *** [Makefile:32896: src/mpi/attr/lib_libmpich_la-dup_fn.lo]
Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: *** [Makefile:32910:
src/mpi/coll/allgather/lib_libmpich_la-allgather_intra_recursive_doubling.lo]
Error 1
make[3]: *** [Makefile:32903:
src/mpi/coll/allgather/lib_libmpich_la-allgather_allcomm_nb.lo] Error 1
make[3]: *** [Makefile:32889: src/mpi/attr/lib_libmpich_la-attrutil.lo]
Error 1
make[3]: Leaving directory '/<>'
make[2]: *** [Makefile:45372: all-recursive] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [Makefile:13561: all] Error 2
make[1]: Leaving directory '/<>'
dh_auto_build: error: make -j4 returned exit code 2
make: *** [debian/rules:69: build-arch] Error 25



signature.asc
Description: OpenPGP digital signature

Bug#948552: any update on the soname issue in libschroedinger-maeparser1

[merkys]

Hi,

On 2020-02-23 18:29, shirish शिरीष wrote:
> Any update on the soname issue in getting the
> libschroedinger-maeparser1 issue resolved, just pinging. It's the only
> reason for not installing openbabel.

I will update the package to the newest upstream release, at the same
time using the correct soname. I will upload to experimental first in
order to carry a proper transition. I am currently blocked by #954146
(false-positive lintian error), will upload once it goes away.

Best,
Andrius

Bug#954240: influxdb: Package installation fails if User "influxdb" is not stored locally (e.g. from LDAP)

[Andreas Maus]

Package: influxdb
Version: 1.6.4-1+b22
Severity: normal
Tags: patch

Good day .*.

The installation of the influxdb package fails if the service user
"influxdb" is not present in /etc/passwd but is defined externally,
e.g. in a central LDAP directory (OpenLDAP, 389-dc, ...) or even NIS/NIS+, ...

The postinstallation script looks for the user in /etc/passwd:

[...]
# create an influxdb group and user
if ! grep -q influxdb /etc/passwd; then
[...]

and tries to add the account if it not present in this file.

If the account is stored in externally (LDAP,NIS, ...) the
postinst script tries to add the user and will fail, because
the system is able to resolve the account name and UID.

In an "containerized" (e.g. LXC) environment with a central storage
for the InfluxDB data the useraccounts are usually managed in a
central location.

Solution:

In the file influxdb.postinst the lookup in /etc/passwd should be
replaced by "getent passwd ...":

-->8--

--- influxdb.postinst.original  2020-03-19 07:35:05.264027783 +0100
+++ influxdb.postinst   2020-03-19 07:35:06.224028230 +0100
@@ -21,7 +21,7 @@
 case "$1" in
 configure|reconfigure)
 # create an influxdb group and user
-if ! grep -q influxdb /etc/passwd; then
+if ! getent passwd influxdb >/dev/null 2>/dev/null; then
 adduser --system --home /var/lib/influxdb --no-create-home influxdb
 addgroup --system influxdb
 adduser influxdb influxdb

--8<--

So long,

Andreas.

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

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

Versions of packages influxdb depends on:
ii  adduser   3.118
ii  libc6 2.28-10
ii  lsb-base  10.2019051400

influxdb recommends no packages.

influxdb suggests no packages.

-- Configuration Files:
/etc/influxdb/influxdb.conf changed:
reporting-enabled = false
bind-address = "127.0.0.1:8088"
[meta]
  # Where the metadata/raft database is stored
  dir = "/var/lib/influxdb/meta"
  # Automatically create a default retention policy when creating a database.
  retention-autocreate = true
  # If log messages are printed for the meta service
  logging-enabled = true
[data]
  # The directory where the TSM storage engine stores TSM files.
  dir = "/var/lib/influxdb/data"
  # The directory where the TSM storage engine stores WAL files.
  wal-dir = "/var/lib/influxdb/wal"
  # The amount of time that a write will wait before fsyncing.  A duration
  # greater than 0 can be used to batch up multiple fsync calls.  This is 
useful for slower
  # disks or when WAL write contention is seen.  A value of 0s fsyncs every 
write to the WAL.
  # Values in the range of 0-100ms are recommended for non-SSD disks.
  wal-fsync-delay = "100ms"
  # The type of shard index to use for new shards.  The default is an in-memory 
index that is
  # recreated at startup.  A value of "tsi1" will use a disk based index that 
supports higher
  # cardinality datasets.
  index-version = "inmem"
  # Trace logging provides more verbose output around the tsm engine. Turning
  # this on can provide more useful output for debugging tsm engine issues.
  # trace-logging-enabled = false
  # Whether queries should be logged before execution. Very useful for 
troubleshooting, but will
  # log any sensitive data contained within a query.
  query-log-enabled = false
  # Settings for the TSM engine
  # CacheMaxMemorySize is the maximum size a shard's cache can
  # reach before it starts rejecting writes.
  # Valid size suffixes are k, m, or g (case insensitive, 1024 = 1k).
  # Values without a size suffix are in bytes.
  # cache-max-memory-size = "1g"
  # CacheSnapshotMemorySize is the size at which the engine will
  # snapshot the cache and write it to a TSM file, freeing up memory
  # Valid size suffixes are k, m, or g (case insensitive, 1024 = 1k).
  # Values without a size suffix are in bytes.
  # cache-snapshot-memory-size = "25m"
  # CacheSnapshotWriteColdDuration is the length of time at
  # which the engine will snapshot the cache and write it to
  # a new TSM file if the shard hasn't received writes or deletes
  # cache-snapshot-write-cold-duration = "10m"
  # CompactFullWriteColdDuration is the duration at which the engine
  # will compact all TSM files in a shard if it hasn't received a
  # write or delete
  # compact-full-write-cold-duration = "4h"
  # The maximum number of concurrent full and level compactions that can run at 
one time.  A
  # value of 0 results in 50% of runtime.GOMAXPROCS(0) used at runtime.  Any 
number greater
  # than 0 limits compactions to that 

Bug#954186: RFS: libxtrxdsp/0.0.1+git20190830.eec2864-2 -- Library of DSP functions, developed for XTRX SDR

[Christoph Berg]

Re: Sepi Gair 2020-03-18 
<370975eaac3fc60a4dc57cb13d003dc9ac47d78b.ca...@email.cz>
>  * Package name: libxtrxdsp
>Version : 0.0.1+git20190830.eec2864-2

Hi Sepi,

I suggest we wait with this upload until the -1 version has passed
NEW.

Christoph

Bug#947756: ripit: Unescaped left brace in regex will be fatal in Perl 5.32

[Dominique Dumont]

On Mon, 30 Dec 2019 02:41:10 +0100 Roman Czyborra  wrote:
> Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
5.32), passed through in regex; marked by <-- HERE in m/^\??({ <-- HERE ([^{}]
+)}|.)/ at /usr/share/perl5/MP3/Tag.pm line 2944.
> Unescaped left brace in regex is deprecated here (and will be fatal in Perl 
5.32), passed through in regex; marked by <-- HERE in m/^({ <-- HERE [^{}]+}|
\w)/ at /usr/share/perl5/MP3/Tag.pm line 2956.
> Use of uninitialized value $ENV{"LANG"} in string at /usr/bin/ripit line 
359.
> 

This problem has been fixed upstream in version 1.15

See change log of https://metacpan.org/pod/MP3::Tag

All the best

Bug#954248: parse markdown formatted email address entries in copyright

[Pirate Praveen]

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

For example in rollup-plugin-terser node module

[Bogdan Chadkin](mailto:tryso...@yandex.ru)

Should be converted to Bogdan Chadkin 

Bug#861789: Please provide database.target as a synchronization point for applications providing databases and needing databases

[Christoph Berg]

Re: Michael Biebl 2020-03-18 <27361fa3-c814-8787-6e10-c5d13956a...@debian.org>
> My concerns are still the same as I outlined above, so I think such a
> database.target would not be too useful given it would only be very
> vaguely defined.

Also, we shouldn't invent a snowflake solution in Debian that isn't
standard elsewhere in the systemd world.

We barely moved from specul Debian init scripts to standard service
files shipped with upstream sources, let's not complicate things again
without coordinating this.

Christoph

Bug#924440: ghc8.6.3.so: undefined symbol: gtk_cell_accessible_parent_get_row_header_cells

[Joachim Breitner]

On Wed, 13 Mar 2019 00:47:43 +0100 Roy Sindre Norangshol 
 wrote:
> While trying to compile latest taffybar using stack as explained in
> https://github.com/taffybar/taffybar/issues/365#issuecomment-394188834 ,
> it seems to be greeted with missing unexported symbols from this library.

I can confirm the issue, also trying to build taffybar (with cabal, not
stack, so that choice does not seem to affect it.)



-- 
Joachim “nomeata” Breitner • nome...@debian.org • https://j.oach.im/
  

Bug#954242: qgis-providers: postinst failure: free(): invalid pointer

[Laurent Bonnaud]

Package: qgis-providers
Version: 3.10.3+dfsg-1+b1
Severity: serious


Dear Maintainer,

here is the problem:

Setting up qgis-providers (3.10.3+dfsg-1+b1) ...
free(): invalid pointer
Aborted (core dumped)
dpkg: error processing package qgis-providers (--configure):
 installed qgis-providers package post-installation script subprocess returned 
error exit status 134


Note that my system has glibc 2.31 from experimental and the following 
environment variables are set:

MALLOC_PERTURB_=117
MALLOC_CHECK_=3


Running "valgrind /usr/lib/qgis/crssync" finds many memory errors, and the 
first one is:

==34194== Invalid free() / delete / delete[] / realloc()
==34194==at 0x4838EAB: operator delete(void*) (vg_replace_malloc.c:586)
==34194==by 0x76643D5: __cxa_finalize (cxa_finalize.c:83)
==34194==by 0xEC8FF62: ??? (in /usr/lib/x86_64-linux-gnu/libproj.so.15.3.1)
==34194==by 0x400FF92: _dl_fini (dl-fini.c:138)
==34194==by 0x7663DD6: __run_exit_handlers (exit.c:108)
==34194==by 0x7663F89: exit (exit.c:139)
==34194==by 0x764CCF1: (below main) (libc-start.c:342)
==34194==  Address 0x1796f740 is 0 bytes inside a block of size 17 free'd
==34194==at 0x4838EAB: operator delete(void*) (vg_replace_malloc.c:586)
==34194==by 0x76643D5: __cxa_finalize (cxa_finalize.c:83)
==34194==by 0x7B12702: ??? (in /usr/lib/x86_64-linux-gnu/libproj.so.19.0.0)
==34194==by 0x400FF92: _dl_fini (dl-fini.c:138)
==34194==by 0x7663DD6: __run_exit_handlers (exit.c:108)
==34194==by 0x7663F89: exit (exit.c:139)
==34194==by 0x764CCF1: (below main) (libc-start.c:342)
==34194==  Block was alloc'd at
==34194==at 0x4837DEF: operator new(unsigned long) (vg_replace_malloc.c:344)
==34194==by 0x7B0E91F: ??? (in /usr/lib/x86_64-linux-gnu/libproj.so.19.0.0)
==34194==by 0x7B11A2C: ??? (in /usr/lib/x86_64-linux-gnu/libproj.so.19.0.0)
==34194==by 0x400FC09: call_init.part.0 (dl-init.c:72)
==34194==by 0x400FD08: call_init (dl-init.c:30)
==34194==by 0x400FD08: _dl_init (dl-init.c:119)
==34194==by 0x40010C9: ??? (in /usr/lib/x86_64-linux-gnu/ld-2.31.so)


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

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

Versions of packages qgis-providers depends on:
ii  dpkg  1.20.0
ii  libc6 2.31-0experimental0
ii  libexpat1 2.2.9-1
ii  libgcc-s1 10-20200312-2
ii  libgdal26 3.0.4+dfsg-1+b1
ii  libhdf5-103   1.10.4+repack-11
ii  libnetcdf15   1:4.7.3-1
ii  libpq512.2-1+b1
ii  libqca-qt5-2  2.2.1-2
ii  libqca-qt5-2-plugins  2.2.1-2
ii  libqgis-core3.10.33.10.3+dfsg-1+b1
ii  libqgis-gui3.10.3 3.10.3+dfsg-1+b1
ii  libqscintilla2-qt5-15 2.11.2+dfsg-6
ii  libqt5core5a [qtbase-abi-5-12-5]  5.12.5+dfsg-9
ii  libqt5gui55.12.5+dfsg-9
ii  libqt5network55.12.5+dfsg-9
ii  libqt5sql55.12.5+dfsg-9
ii  libqt5sql5-sqlite 5.12.5+dfsg-9
ii  libqt5webkit5 5.212.0~alpha4-1
ii  libqt5widgets55.12.5+dfsg-9
ii  libqt5xml55.12.5+dfsg-9
ii  libspatialite75.0.0~beta0-1~exp4
ii  libsqlite3-0  3.31.1-4
ii  libstdc++610-20200312-2
ii  libxml2   2.9.10+dfsg-4
ii  qgis-providers-common 3.10.3+dfsg-1

qgis-providers recommends no packages.

qgis-providers suggests no packages.

-- no debconf information

-- 
Laurent.

Bug#954259: src:innoextract: fails to migrate to testing for too long

[Paul Gevers]

Source: innoextract
Version: 1.7-2
Severity: serious
Control: fixed -1 1.8-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:innoextract
in its current version in unstable has been trying to migrate for 63
days [2]. Hence, I am filing this bug.

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

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

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

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

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#954258: src:r-cran-ranger: fails to migrate to testing for too long

[Paul Gevers]

Source: r-cran-ranger
Version: 0.11.2-1
Severity: serious
Control: fixed -1 0.12.1-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:r-cran-ranger
in its current version in unstable has been trying to migrate for 63
days [2]. Hence, I am filing this bug.

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

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

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

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

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#954266: qemu-system-x86: graphical-mode monitor doesn't work

[Jakub Wilk]

Package: qemu-system-x86
Version: 1:4.2-3

I can switch to the monitor using Ctrl-Alt-2; but when I start typing a 
command, nothing happens.


Work-around: text-mode monitor (-monitor stdio) works as it should.


-- System Information:
Architecture: i386

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu 1.0.0+git-20190125.36a4c85-5
ii  libaio1   0.3.112-5
ii  libasound21.2.2-2.1
ii  libbrlapi0.7  6.0+dfsg-5
ii  libc6 2.30-2
ii  libcacard01:2.6.1-1
ii  libcapstone3  4.0.1+really+3.0.5-1+b2
ii  libepoxy0 1.5.4-1
ii  libfdt1   1.6.0-1
ii  libgbm1   19.3.3-1
ii  libgcc-s1 [libgcc1]   10-20200312-2
ii  libglib2.0-0  2.64.1-1
ii  libgnutls30   3.6.12-2
ii  libibverbs1   28.0-1+b1
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libncursesw6  6.2-1
ii  libnettle73.5.1+really3.5.1-2
ii  libnuma1  2.0.12-1+b1
ii  libpixman-1-0 0.36.0-1
ii  libpng16-16   1.6.37-2
ii  librdmacm128.0-1+b1
ii  libsasl2-22.1.27+dfsg-2
ii  libseccomp2   2.4.3-1
ii  libslirp0 4.1.0-2
ii  libspice-server1  0.14.2-4
ii  libtinfo6 6.2-1
ii  libusb-1.0-0  2:1.0.23-2
ii  libusbredirparser10.8.0-1+b1
ii  libvdeplug2   2.3.2+r586-2.2
ii  libvirglrenderer1 0.8.2-1
ii  libxendevicemodel14.11.3+24-g14b62ab3e5-1
ii  libxenevtchn1 4.11.3+24-g14b62ab3e5-1
ii  libxenforeignmemory1  4.11.3+24-g14b62ab3e5-1
ii  libxengnttab1 4.11.3+24-g14b62ab3e5-1
ii  libxenmisc4.114.11.3+24-g14b62ab3e5-1
ii  libxenstore3.04.11.3+24-g14b62ab3e5-1
ii  libxentoolcore1   4.11.3+24-g14b62ab3e5-1
ii  qemu-system-common1:4.2-3
ii  qemu-system-data  1:4.2-3
ii  seabios   1.13.0-1
ii  zlib1g1:1.2.11.dfsg-2

--
Jakub Wilk

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Diederik de Haas]

On donderdag 19 maart 2020 14:59:56 CET mario.limoncie...@dell.com wrote:
> Sorry - I see now that was from a while back.

And also a different user (OP).


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

Bug#954257: python3-audit: SWIG-related type errors render module unusable

[Laurent Bigonville]

Package: python3-audit
Version: 1:2.8.5-2
Severity: grave
Control: forward -1 https://github.com/linux-audit/audit-userspace/issues/120

Looks like #927946 is back/was not properly fixed

This only affects unstable (and probably bullseye)

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages python3-audit depends on:
ii  libaudit11:2.8.5-2+b1
ii  libauparse0  1:2.8.5-2+b1
ii  libc62.30-2
ii  python3  3.8.2-1

python3-audit recommends no packages.

python3-audit suggests no packages.

-- no debconf information

Bug#954192: exim4-config: prdr_enable = true breaks exim4+dkimproxy when using multiple recipients

[Marc Haber]

On Wed, Mar 18, 2020 at 06:32:05AM +0100, Niki Hammler wrote:
> This worked flawlessly until jessie (for me, from 2008 until now). However, 
> with prdr_enable = true, exim4 hangs when looping back the message when
> using multiple recipients. It hangs with message:
> 
>   353 PRDR content analysis beginning

That happens when dkimproxy re-delivers the message back to exim? What's
the SMTP dialog before? Does exim advertise PRDR? Does the client
request it?

> I verified the issue observing the traffic transmitted to dkimproxy while 
> sending a message to only one recipient:
> 
> # ngrep -d lo -W byline -q port 10028
> [...]
> T 127.0.0.1:10028 -> 127.0.0.1:48486 [AP]
> 250 OK id=1jEPuw-0005Cq-IJ.
> 
> T 127.0.0.1:48486 -> 127.0.0.1:10028 [AP]
> QUIT.
> 
> T 127.0.0.1:10028 -> 127.0.0.1:48486 [AP]
> 221 mail.nobaq.net closing connection.
> 
> 
> All good, just as expected.
> Now repeating the whole thing while sending the message to TWO recipients:
> 
> # ngrep -d lo -W byline -q port 10028
> [...]
> DATA.
> [...]
> T 127.0.0.1:10028 -> 127.0.0.1:48586 [AP]
> 353 PRDR content analysis beginning.

The things you have left out would have been interesting.

> Setting
> 
>   prdr_enable = false
> 
> fixes the issue. But this is far from optimal.

I am not sure, but if the value for prdr_enable is expanded at
connection-time, one could use an expression that expands to "true" in
the default case and to "false" in the "I am talking to dkimproxy" case.

Generally, having messages looped out of exim and in again is seldomly a
good idea because internal information is lost between the two exim
runs.

> At the very least, information about prdr (and implications) would be useful 
> to prevent people from debugging for days why suddenly after
> 12 years there are weird redeliveries and mails stuck in the queue.

prdr has a (short) explanation in exim's spec.txt. I don't think that it
should be the responsibility of the packaging to explain every feature
of e-mail transport.

> Furthermore, a Debian-style control macro would be desirable that allows more 
> flexible control without directly changing the config file
> (like MAIN_TLS_ADVERTISE_HOSTS etc).

Agreed. Can we have a documented patch please?

The dkimproxy package could also dump a configuration snippet. Allowing
this is one of the reasons we came up with split config.

> The next best solution would require exim4 changes directly in order to 
> prevent use of PRDR in the exim<->dkimproxy loop.

How would that be done?

> And the best solution would be to fix this bug altogether but I am not 
> completely sure why exim4 is hanging there in the first place
> and how much it is related to dkimproxy.

I do see "interesting behavior" but not yet a bug, let alone in exim.

Greetings
Marc


-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#954239: RFP: python-b4 -- helper utility to work with patches made available via a public-inbox archive

[Hector Oron]

Hello Salvatore,

Missatge de Salvatore Bonaccorso  del dia dj., 19
de març 2020 a les 7:18:
>
> Package: wnpp
> Severity: wishlist
>
> * Package name: python-b4
>   Version : v0.3.3 (or later)
>   Upstream Author : Konstantin Ryabitsev 
> * URL : https://git.kernel.org/pub/scm/utils/b4/b4.git
> * License : GPL
>   Programming Lang: Python
>   Description : helper utility to work with patches made available via a 
> public-inbox archive
>
> This is a helper utility to work with patches made available via a
> public-inbox archive like lore.kernel.org. It is written to make it
> easier to participate in a patch-based workflows, like those used in
> the Linux kernel development.
>
> For the package name, not sure if python-b4 or b4 is more appropriate.

I have done initial packaging at
  https://salsa.debian.org/zumbi/python-b4

If you are fine with it, I'll upload it, so it can go through NEW
queue and move it into Debian Python Modules Team (eventually).

Regards
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#954265: ITP: grok-jpeg2000 -- Grok is an implementation of Part 1 of the JPEG 2000 standard. It aims for speed and stability.

[Aaron Boxer]

Package: wnpp
Severity: wishlist
Owner: Aaron Boxer 

* Package name: grok-jpeg2000
  Version : 5.0.0
  Upstream Author : Aaron Boxer 
* URL : https://github.com/GrokImageCompression/grok
* License : AGPL
  Programming Lang: C++
  Description : Grok is an implementation of Part 1 of the JPEG 2000
standard. It aims for speed and stability.


Grok is one of only two actively developed open source implementations of
the JPEG 2000 standard, the other being OpenJPEG. Grok performance is equal
to
or greater than OpenJPEG, and it also provides more features such as:
1. end to end support of ICC colour profiles
2. support for meta-data such as IPTC, XML and XMP
3. support for new Part 15 of the standard, which promises 5 to 10 times
decoding speedup

I have been maintaining this library since 2016, and I will maintain the
debian package. I am looing for a sponsor to submit the package.

Thanks!
Aaron

Bug#954264: openvpn-auth-radius: Support for verify-client-cert openvpn 2.4 directive

[Alexander Herr]

Package: openvpn-auth-radius
Version: 2.1-7
Severity: normal
Tags: upstream

Dear Maintainer,

the current version only checks for the 'client-cert-not-required' directive in
the  openvpn server configuration. This directive has become deprecated since 
version 2.4 of openvpn.

A potential fix has been discussed at the corresponding github issue #14.

A currently available remedy for users is to include both the 
'client-cert-not-required' and the 'verify-client-cert [none|optional]' 
directives in the server configuration. This works for openvpn version 2.4, as
the option is marked as deprecated, but will stop working for version >=2.5. 

All the best.


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

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

Versions of packages openvpn-auth-radius depends on:
ii  libc62.28-10
ii  libgcc1  1:8.3.0-6
ii  libgcrypt20  1.8.4-5
ii  libstdc++6   8.3.0-6
ii  openvpn  2.4.7-1

openvpn-auth-radius recommends no packages.

openvpn-auth-radius suggests no packages.

-- no debconf information

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Mario.Limonciello]

> -Original Message-
> From: Diederik de Haas 
> Sent: Thursday, March 19, 2020 8:53 AM
> To: Limonciello, Mario
> Cc: 943...@bugs.debian.org
> Subject: Re: Bug#943343: fwupd: fwupd-refresh.service failed to start
> Refresh fwupd metadata and update motd.
> 
> On donderdag 19 maart 2020 14:42:56 CET mario.limoncie...@dell.com
> wrote:
> > Has your system been rebooted recently?
> 
> Yes. I usually shutdown my system at night.
> 
> > I check on my (working) system and I don't have /run/motd.d as a
> > symlink to /run/private/motd.d. For my system /run/motd.d is a real
> > directory with a subdirectory "fwupd".
> >
> > I have a suspicion this is related to the issue.
> 
> I don't have a /run/private directory and also no /run/motd.d.
> I do have /run/motd.dynamic which is the same as "uname -nrsvm" (uname -
> a minus the GNU/Linux part)

In your first post you had:

And about the runtime directory:
$ ls -ld /run/motd.d
lrwxrwxrwx 1 root root 14 oct 23 16:06 /run/motd.d -> private/motd.d
$ ls -ld /run/private/
drwx-- 3 root root 60 oct 23 16:06 /run/private/
$ sudo ls -ld /run/private/motd.d
drwxr-xr-x 2 62803 62803 40 oct 23 16:06 /run/private/motd.d
$ sudo ls -l /run/private/motd.d
total 0

Bug#938340: reclass: Python2 removal in sid/bullseye

[Sandro Tosi]

> I am in the process of migrating away from reclass, but I need more time
> - hopefully I can get there within a month but not certain.

is there a public repo we can track your progress? just note that
simply removing reclass from debian wont make it stop working on
machines that already have it installed (and it would we always
available on snapshots.d.o if necessary).

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#954269: buster-pu: package manila/1:7.0.0-1 CVE-2020-9543

[Thomas Goirand]

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

Dear Stable Release Team,

The security team told me that this update is a no-DSA. Can I upload this
Manila update to proposed-updates then?

If you didn't know, Manila is OpenStack's file system share as a service
(like for example, NFS share as a service, running on top of a Cinder or
a Ceph block storage, or CephFS, or a proprietary NAS, etc.).

FYI, the security bug is that anyone knowing an UUID of a Manila share,
can basically do whatever it wants with it. It's no DSA because guessing
such an UUID isn't practical, and an operator would likely notice if one
is attempting to brute-force. I still think it deserves patching Buster.

Debdiff attached.

Cheers,

Thomas Goirand (zigo)
diff -Nru manila-7.0.0/debian/changelog manila-7.0.0/debian/changelog
--- manila-7.0.0/debian/changelog   2018-09-05 15:53:37.0 +0200
+++ manila-7.0.0/debian/changelog   2020-03-09 15:53:45.0 +0100
@@ -1,3 +1,11 @@
+manila (1:7.0.0-1+deb10u1) buster; urgency=medium
+
+  * CVE-2020-9543: Manila allows other project users to view, update, delete,
+or share resources that do not belong to them. Applied upstream patch:
+share_networks: enable project_only API only (Closes: #953581).
+
+ -- Thomas Goirand   Mon, 09 Mar 2020 15:53:45 +0100
+
 manila (1:7.0.0-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru 
manila-7.0.0/debian/patches/CVE-2020-9543_share_networks_enable_project_only_API_only.patch
 
manila-7.0.0/debian/patches/CVE-2020-9543_share_networks_enable_project_only_API_only.patch
--- 
manila-7.0.0/debian/patches/CVE-2020-9543_share_networks_enable_project_only_API_only.patch
 1970-01-01 01:00:00.0 +0100
+++ 
manila-7.0.0/debian/patches/CVE-2020-9543_share_networks_enable_project_only_API_only.patch
 2020-03-09 15:53:45.0 +0100
@@ -0,0 +1,124 @@
+Description: CVE-2020-9543: share_networks: enable project_only API only
+ At the moment, the share_network database API which the web
+ API layer interacts with directly does not have any checking
+ for project_id which means that a user has the ability to run
+ operations against any other share_network if they have the ID.
+ .
+ This patch implements the usage of project_only in the database
+ query which ensures that administrators still have the behaviour
+ of getting any share network they want, but users can only pull
+ up those which are part of their context/authenticated project.
+ .
+ This patch also adjusts a few other tests due to the fact that
+ the existing tests would run a lot of inserts with a different
+ project_id than the context, which is not allowed in this new
+ API behaviour.  Therefore, the instances that involved projects
+ different than the context were converted to elevated ones.
+ .
+ There was also an instance where they were being created with a
+ project_id that did not match the fake context, therefore the
+ context was adjusted accordingly as well.
+Author: Mohammed Naser 
+Date: Fri, 31 Jan 2020 16:13:24 +0100
+Change-Id: Id67a939a475c4ac06d546b7e095bd10f1a6d2619
+Origin: upstream
+Bug-Debian: https://bugs.debian.org/953581
+Last-Update: 2020-03-09
+
+Index: manila/manila/db/sqlalchemy/api.py
+===
+--- manila.orig/manila/db/sqlalchemy/api.py
 manila/manila/db/sqlalchemy/api.py
+@@ -3330,7 +3330,8 @@ def _security_service_get_query(context,
+ def _network_get_query(context, session=None):
+ if session is None:
+ session = get_session()
+-return (model_query(context, models.ShareNetwork, session=session).
++return (model_query(context, models.ShareNetwork, session=session,
++project_only=True).
+ options(joinedload('share_instances'),
+ joinedload('security_services'),
+ joinedload('share_servers')))
+Index: manila/manila/tests/db/sqlalchemy/test_api.py
+===
+--- manila.orig/manila/tests/db/sqlalchemy/test_api.py
 manila/manila/tests/db/sqlalchemy/test_api.py
+@@ -1966,7 +1966,7 @@ class ShareNetworkDatabaseAPITestCase(Ba
+ share_nw_dict2['project_id'] = 'fake project 2'
+ result1 = db_api.share_network_create(self.fake_context,
+   self.share_nw_dict)
+-result2 = db_api.share_network_create(self.fake_context,
++result2 = db_api.share_network_create(self.fake_context.elevated(),
+   share_nw_dict2)
+ 
+ self._check_fields(expected=self.share_nw_dict, actual=result1)
+@@ -1999,6 +1999,33 @@ class ShareNetworkDatabaseAPITestCase(Ba
+ self.assertEqual(0, len(result['share_instances']))
+ self.assertEqual(0, len(result['security_services']))
+ 
++def _create_share_network_for_project(self, project_id):
++  

Bug#954271: libsys-sigaction-perl: arm64 autopkgtest time out

[Paul Gevers]

Source: libsys-sigaction-perl
Version: 0.23-1
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: timeout

Dear maintainer(s),

libsys-sigaction-perl fails its autopkgtest on arm64 due to a time out
after 2h47. Can you please investigate the situation?

To avoid wasting lots of time on the ci.debian.net infrastructure, I
have added your package to the ignore list for arm64.

Paul

https://ci.debian.net/data/autopkgtest/unstable/arm64/libs/libsys-sigaction-perl/4495428/log.gz

autopkgtest [02:37:46]: test autodep8-perl-build-deps:
/usr/share/pkg-perl-autopkgtest/runner build-deps
autopkgtest [02:37:46]: test autodep8-perl-build-deps:
[---
t/alternatives.t ..
1..2
in subname defined sighander() sig speced as 'ALRM'
ok 1 - $testval = 1;  was set by signal handler
in coderef defined signal handler signal speced as SIGALRM
ok 2 - $testval = 1;  was set by signal handler
ok
t/inline_nested.t .
1..4
in sighandler: level 3
in sighandler: level 2
in sighandler: level 1
in sighandler: level 0
ok 1 - (level 0 is not 0 as expected)
level 0 = 1
ok 2 - (level 1 is not 0 as expected)
level 1 = 2
ok 3 - (level 2 is not 0 as expected)
level 2 = 3
ok 4 - (level 3 is not 0 as expected)
level 3 = 4
ok
t/mask.t ..
1..14
ok 1 - sigHUP called (1)
ok 2 - sig mask delayed INT and USR1(2)
ok 3 - sigINT_1 called(3) failure: (3!=3) this should have been delayed
by mask until sigHUP finished
ok 4 - sig mask delayed USR1 (signaled from sigHUP)(4)
ok 5 - sigUSR called (5) failure: (5!=5) it should have been delayed by
mask until sigHUP finished)
ok 6 - reach 6th test after first kill
ok 7 - sigHUP_2 called
ok 8 - sigINT_2 called (8)
ok 9 - sigINT_2 exiting (9)
ok 10 - sigUSR2 called (10)
ok 11 - sigHUP_2 ending
ok 12 - hup=1 (1)
ok 13 - int=1 (1)
ok 14 - usr=2 (2)
ok
t/name.t ..
1..3
ok 1 - use Sys::SigAction;
ok 2 - SIGINT => INT
ok 3 - 9 => KILL
ok
t/number.t 
1..4
ok 1 - use Sys::SigAction;
ok 2 - INT => SIGINT
ok 3 - KILL => SIGKILL
ok 4 - HUP => SIGHUP
ok
t/recursive_nested.t ..
1..40
starting pass 1
testing nested signal handlers to a depth of 10
initializing @levels array to 0 for all depths

ok 1 - pass 1: $levels[9] was initialed to 0
ok 2 - pass 1: $levels[8] was initialed to 0
ok 3 - pass 1: $levels[7] was initialed to 0
ok 4 - pass 1: $levels[6] was initialed to 0
ok 5 - pass 1: $levels[5] was initialed to 0
ok 6 - pass 1: $levels[4] was initialed to 0
ok 7 - pass 1: $levels[3] was initialed to 0
ok 8 - pass 1: $levels[2] was initialed to 0
ok 9 - pass 1: $levels[1] was initialed to 0
ok 10 - pass 1: $levels[0] was initialed to 0
  entered do_level( 1 )
entered do_level( 2 )
  entered do_level( 3 )
entered do_level( 4 )
  entered do_level( 5 )
entered do_level( 6 )
  entered do_level( 7 )
entered do_level( 8 )
  entered do_level( 9 )
entered do_level( 10 )
in ALRM handler at depth of 10
  in ALRM handler at depth of 9
in ALRM handler at depth of 8
  in ALRM handler at depth of 7
in ALRM handler at depth of 6
  in ALRM handler at depth of 5
in ALRM handler at depth of 4
  in ALRM handler at depth of 3
in ALRM handler at depth of 2
  in ALRM handler at depth of 1

ok 11 - pass 1: $levels[9] was set by the signal handler to 10
ok 12 - pass 1: $levels[8] was set by the signal handler to 9
ok 13 - pass 1: $levels[7] was set by the signal handler to 8
ok 14 - pass 1: $levels[6] was set by the signal handler to 7
ok 15 - pass 1: $levels[5] was set by the signal handler to 6
ok 16 - pass 1: $levels[4] was set by the signal handler to 5
ok 17 - pass 1: $levels[3] was set by the signal handler to 4
ok 18 - pass 1: $levels[2] was set by the signal handler to 3
ok 19 - pass 1: $levels[1] was set by the signal handler to 2
ok 20 - pass 1: $levels[0] was set by the signal handler to 1
starting pass 2
testing nested signal handlers to a depth of 10
initializing @levels array to 0 for all depths

ok 21 - pass 2: $levels[9] was initialed to 0
ok 22 - pass 2: $levels[8] was initialed to 0
ok 23 - pass 2: $levels[7] was initialed to 0
ok 24 - pass 2: $levels[6] was initialed to 0
ok 25 - pass 2: $levels[5] was initialed to 0
ok 26 - pass 2: $levels[4] was initialed to 0
ok 27 - pass 2: $levels[3] was initialed to 0
ok 28 - pass 2: $levels[2] was initialed to 0
ok 29 - pass 2: $levels[1] was initialed to 0
ok 30 - pass 2: $levels[0] was initialed to 0
  entered do_level( 1 )
entered do_level( 2 )
  entered do_level( 3 )
entered do_level( 4 )
  entered do_level( 5 )
entered do_level( 6 )
  entered do_level( 7 )
entered do_level( 8 )
  entered do_level( 9 )
entered do_level( 10 )
in ALRM handler at depth of 10

Bug#954089: libplack-perl: Please verify server identity via SSL

[Damyan Ivanov]

-=| Felix Lechner, 18.03.2020 04:05:22 -0700 |=-
> Hi,
> 
> On Wed, Mar 18, 2020 at 3:18 AM Damyan Ivanov  wrote:
> >
> > Fixing the root of the problem seems better for me for two reasons:
> 
> I wish I had checked with the Debian Perl team before filing the bugs.

That would have been nice, but there's no real harm done. The problem 
is real and needs to be reported and fixed one way or another. Thank 
you for caring.

> > we may have a chance convincing
> > HTTP::Tiny's author to flip the default
> 
> Please note the module is part of Perl core. Their support may be needed also.

Certainly.

-=| gregor herrmann, 18.03.2020 17:35:11 +0100 |=-
> On Wed, 18 Mar 2020 12:18:34 +0200, Damyan Ivanov wrote:
> 
> > Fixing the root of the problem seems better for me for two 
> > reasons:
> > 
> >  1) fix what is broken instead of working around it in numerous places
> >  2) consumers outside of Debian would benefit too
> 
> I agree, also with the rest of your mail. Thanks for moving this forward!
>  
> > But to fully measure the impact, it would be nice to have the number 
> > of failing packages built with a patched HTTP::Tiny.
> 
> I have one small concern: As the change is about checking remote SSL
> certs, and tests don't/can't/must not call out to the internet, is it
> possible that we won't really catch all potential issues?

Noted. The test rebuilds should be done without the usual isolation 
from the Internet.

I guess a closer inspection of the affected packages is needed.


-- dam

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Mario.Limonciello]

> -Original Message-
> From: Diederik de Haas 
> Sent: Thursday, March 19, 2020 7:57 AM
> To: Limonciello, Mario
> Cc: 943...@bugs.debian.org
> Subject: Re: Bug#943343: fwupd: fwupd-refresh.service failed to start
> Refresh fwupd metadata and update motd.
> 
> On woensdag 18 maart 2020 22:40:22 CET mario.limoncie...@dell.com wrote:
> > I suspect this is related to an upgrade from the intermediary version
> > that had problematic objects/permissions created.
> 
> > Can you please try to check whether there are broken symlinks in
> > /var/lib/private or /var/cache/private?
> 
> It seems there are no symlinks, so also not broken symlinks.
> 
> root@bagend:~# ls -la /var/lib/private/
> total 12
> drwx--  3 root root 4096 mei  3  2018 .
> drwxr-xr-x 82 root root 4096 mrt 19 08:47 ..
> drwxr-xr-x  2 root root 4096 jan 10  2019 systemd root@bagend:~# ls -la
> /var/lib/private/systemd/ total 8 drwxr-xr-x 2 root root 4096 jan 10  2019 .
> drwx-- 3 root root 4096 mei  3  2018 ..
> root@bagend:~# ls -la /var/cache/private/ total 16
> drwx--  4 root  root  4096 okt  9 21:36 .
> drwxr-xr-x 22 root  root  4096 mrt  9 11:56 ..
> drwxr-xr-x  2 62803 62803 4096 jul 30  2019 fwupd drwxr-xr-x  2 62803 62803
> 4096 okt  9 21:36 fwupdmgr root@bagend:~# ls -la
> /var/cache/private/fwupd/ total 720
> drwxr-xr-x 2 62803 62803   4096 jul 30  2019 .
> drwx-- 4 root  root4096 okt  9 21:36 ..
> -rw-r--r-- 1 62803 62803 722862 jul 30  2019 metadata.xmlb
> -rw-r--r-- 1 62803 62803   1471 jul 30  2019 metainfo.xmlb
> root@bagend:~# ls -la /var/cache/private/fwupdmgr/ total 8 drwxr-xr-x 2
> 62803 62803 4096 okt  9 21:36 .
> drwx-- 4 root  root  4096 okt  9 21:36 ..
> 
> 
> FTR: My system is a fully up-to-date Sid system # systemd --version systemd
> 245 (245.2-1)
> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP
> ++LIBCRYPTSETUP GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID
> +ELFUTILS
> ++KMOD +IDN2 -IDN
> +PCRE2 default-hierarchy=hybrid

Has your system been rebooted recently?  
I check on my (working) system and I don't have /run/motd.d as a symlink to 
/run/private/motd.d.
For my system /run/motd.d is a real directory with a subdirectory "fwupd".

I have a suspicion this is related to the issue.

Bug#954239: RFP: python-b4 -- helper utility to work with patches made available via a public-inbox archive

[Santiago Ruano Rincón]

El 19/03/20 a las 07:15, Salvatore Bonaccorso escribió:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: python-b4
>   Version : v0.3.3 (or later)
>   Upstream Author : Konstantin Ryabitsev 
> * URL : https://git.kernel.org/pub/scm/utils/b4/b4.git
> * License : GPL
>   Programming Lang: Python
>   Description : helper utility to work with patches made available via a 
> public-inbox archive
> 
> This is a helper utility to work with patches made available via a
> public-inbox archive like lore.kernel.org. It is written to make it
> easier to participate in a patch-based workflows, like those used in
> the Linux kernel development.
> 
> For the package name, not sure if python-b4 or b4 is more appropriate.

IMHO, if it's an application, b4 would be more appropriate. If it's a python
module, then python-b4.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#954267: add --set-paste-button option to fix for bad trackpads with annoying middle button

[borislav nikolov]

Package: consolation
Version: 0.0.7-1

Hi,
thank you so much for writing this! I was struggling with gpm for a
while because of /dev/input/mice not sending buttons properly for
trackpads.

For me middle button is just annoyingly difficult to press on t440p,
and I wanted to use the "right" button (top right area) as paste
button.


I added a quick patch/hack (attached), that adds --set-paste-button
option, that allows me to use the right button.

again, thank you for writing this!

PS:
I am new to the debian community, and I apologize if this is not the
right way to send a patch.
commit a1479d8a87e99ffaff22587969b63cd1f48bfae8
Author: borislav nikolov 
Date:   Thu Mar 19 14:23:33 2020 +0100

add --set-paste-button

diff --git a/src/Makefile.in b/src/Makefile.in
index 88337c7..a8129ba 100644
--- a/src/Makefile.in
+++ b/src/Makefile.in
@@ -1,7 +1,7 @@
-# Makefile.in generated by automake 1.15 from Makefile.am.
+# Makefile.in generated by automake 1.15.1 from Makefile.am.
 # @configure_input@
 
-# Copyright (C) 1994-2014 Free Software Foundation, Inc.
+# Copyright (C) 1994-2017 Free Software Foundation, Inc.
 
 # This Makefile.in is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
diff --git a/src/action.c b/src/action.c
index 1df6070..9ff7bba 100644
--- a/src/action.c
+++ b/src/action.c
@@ -108,27 +108,17 @@ release_left_button(void)
 }
 
 void
-press_middle_button(void)
+press_paste_button(int b)
 {
   if (mouse_reporting != MOUSE_REPORTING_OFF)
   {
-button = BUTTON_MIDDLE;
+button = b;
 report_pointer((int)xx,(int)yy,button);
   }
   else
 paste();
 }
 
-void
-release_middle_button(void)
-{
-  if (mouse_reporting == MOUSE_REPORTING_X11)
-  {
-button = BUTTON_RELEASED;
-report_pointer((int)xx,(int)yy,button);
-  }
-}
-
 void
 press_right_button(void)
 {
@@ -145,7 +135,7 @@ press_right_button(void)
 }
 
 void
-release_right_button(void)
+release_button(void)
 {
   if (mouse_reporting == MOUSE_REPORTING_X11)
   {
@@ -154,6 +144,7 @@ release_right_button(void)
   }
 }
 
+
 void
 vertical_axis(double v)
 {
diff --git a/src/consolation.h b/src/consolation.h
index 5290d65..a70b3b9 100644
--- a/src/consolation.h
+++ b/src/consolation.h
@@ -56,11 +56,10 @@ void set_lut(const char *word_chars);
 void set_pointer(double x, double y);
 void move_pointer(double x, double y);
 void press_left_button(void);
-void release_left_button(void);
-void press_middle_button(void);
-void release_middle_button(void);
 void press_right_button(void);
-void release_right_button(void);
+void release_left_button(void);
+void release_button(void);
+void press_paste_button(int b);
 void vertical_axis(double v);
 
 /* input.c */
diff --git a/src/input.c b/src/input.c
index 5bed228..bf74ae0 100644
--- a/src/input.c
+++ b/src/input.c
@@ -82,6 +82,14 @@ handle_pointer_button_event(struct libinput_event *ev)
   int button;
   button = libinput_event_pointer_get_button(p);
   state = libinput_event_pointer_get_button_state(p);
+  if (button == options.paste_button) {
+if (state==LIBINPUT_BUTTON_STATE_PRESSED)
+  press_paste_button(button);
+else
+  release_button();
+return;
+  }
+
   switch(button)
   {
   case BTN_LEFT:
@@ -90,17 +98,11 @@ handle_pointer_button_event(struct libinput_event *ev)
 else
   release_left_button();
 break;
-  case BTN_MIDDLE:
-if (state==LIBINPUT_BUTTON_STATE_PRESSED)
-  press_middle_button();
-else
-  release_middle_button();
-break;
   case BTN_RIGHT:
 if (state==LIBINPUT_BUTTON_STATE_PRESSED)
   press_right_button();
 else
-  release_right_button();
+  release_button();
 break;
   }
 }
@@ -245,6 +247,7 @@ usage(void)
  "--set-click-method=[none|clickfinger|buttonareas]  set the desired click method\n"
  "--set-scroll-method=[none|twofinger|edge|button] ... set the desired scroll method\n"
  "--set-scroll-button=BTN_MIDDLE ... set the button to the given button code\n"
+ "--set-paste-button=BTN_MIDDLE ... use this button code to paste\n"
  "--set-profile=[adaptive|flat] set pointer acceleration profile\n"
  "--set-speed= set pointer acceleration speed (allowed range [-1, 1]) \n"
  "--set-tap-map=[lrm|lmr] ... set button mapping for tapping\n"
diff --git a/src/shared.c b/src/shared.c
index 2c08956..606861c 100644
--- a/src/shared.c
+++ b/src/shared.c
@@ -79,6 +79,7 @@ tools_init_options(struct tools_options *options)
 	options->click_method = -1;
 	options->scroll_method = -1;
 	options->scroll_button = -1;
+	options->paste_button = BTN_MIDDLE;
 	options->speed = 0.0;
 	options->profile = LIBINPUT_CONFIG_ACCEL_PROFILE_NONE;
 }
@@ -194,6 +195,20 @@ tools_parse_option(int option,
 			return 1;
 		}
 		break;
+	case OPT_PASTE_BUTTON:
+		if (!optarg) {
+			return 1;
+		}
+		options->paste_button =
+		libevdev_event_code_from_name(EV_KEY,
+	  optarg);
+		if (options->paste_button == -1) {

Bug#941666: ITP: vega-datasets -- Collection of datasets used in Vega and Vega-Lite examples

[Santiago Ruano Rincón]

Control: retitle -1 ITP: python-vega-datasets -- Collection of datasets used in 
Vega and Vega-Lite examples

On Thu, 3 Oct 2019 16:48:20 +0200 Santiago Ruano =?iso-8859-1?Q?Rinc=F3n?= 
 wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Santiago Ruano Rincón" 
> 
> * Package name: vega-datasets
>   Version : 0.7
>   Upstream Author : Jake Vanderplas
> * URL : https://github.com/altair-viz/vega_datasets
> * License : MIT and others.
>   Programming Lang: Python
>   Description : Python package for offline access to vega datasets
> 
> This is a collection of datasets used in vega examples.
> 
> This is required to build altair (See ITP bug https://bugs.debian.org/941599),
> especially to run the test suite.
> 
> Similar to altair, it would be great to maintain it within the Python
> Modules Team.

Changing title to python-vega-datasets, since it's a python-module.

Packaging is taking place at 
https://salsa.debian.org/python-team/modules/python-vega-datasets/


signature.asc
Description: PGP signature

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Diederik de Haas]

On donderdag 19 maart 2020 14:42:56 CET mario.limoncie...@dell.com wrote:
> Has your system been rebooted recently?

Yes. I usually shutdown my system at night.

> I check on my (working) system and I don't have /run/motd.d as a symlink to
> /run/private/motd.d. For my system /run/motd.d is a real directory with a
> subdirectory "fwupd".
> 
> I have a suspicion this is related to the issue.

I don't have a /run/private directory and also no /run/motd.d.
I do have /run/motd.dynamic which is the same as "uname -nrsvm" (uname -a 
minus the GNU/Linux part)

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

Bug#954270: kmc: arm64 autopkgtest time out

[Paul Gevers]

Source: kmc
Version: 2.3+dfsg-7
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: timeout

Dear maintainer(s),

kmc fails its autopkgtest on arm64 due to a time out after
2h47. Can you please investigate the situation?

To avoid wasting lots of time on the ci.debian.net infrastructure, I
have added your package to the ignore list for arm64.

Paul

https://ci.debian.net/data/autopkgtest/testing/arm64/k/kmc/4557365/log.gz

autopkgtest [14:57:08]: test build-lib: [---
build: OK
*autopkgtest [17:43:48]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.psdr2acq/downtmp/build.SOh/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.psdr2acq/downtmp/build-lib-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.psdr2acq/downtmp/build-lib-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.psdr2acq/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.psdr2acq/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=32; unset
LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY
LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.psdr2acq/downtmp/build.SOh/src/debian/tests/build-lib;
touch /tmp/autopkgtest-lxc.psdr2acq/downtmp/build-lib-stdout
/tmp/autopkgtest-lxc.psdr2acq/downtmp/build-lib-stderr;
/tmp/autopkgtest-lxc.psdr2acq/downtmp/build.SOh/src/debian/tests/build-lib
2> >(tee -a /tmp/autopkgtest-lxc.psdr2acq/downtmp/build-lib-stderr >&2)
> >(tee -a /tmp/autopkgtest-lxc.psdr2acq/downtmp/build-lib-stdout);"
(kind: test)
autopkgtest [17:43:49]: test build-lib: ---]



signature.asc
Description: OpenPGP digital signature

Bug#937643: Reverting python2-rm

[Scott Kitterman]

I'm about to upload this with python2 restored.  Python-automat, which is a 
dependency of python-twisted-core (which is not close to being removed) 
depends on this and currently can't migrate to Testing because of the lack of 
this package.

This is entangled with the python3.8 as default transition, so we just need to 
put this back for now.

Scott K

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

Bug#954273: simka: arm64 autopkgtest time out

[Paul Gevers]

Source: simka
Version: 1.5.1-4
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: timeout

Dear maintainer(s),

simka fails its autopkgtest on arm64 due to a time out after
2h47. Can you please investigate the situation?

To avoid wasting lots of time on the ci.debian.net infrastructure, I
have added your package to the ignore list for arm64.

Paul

https://ci.debian.net/data/autopkgtest/unstable/arm64/s/simka/4487330/log.gz

autopkgtest [12:26:34]: test run-unit-test: [---
A.fasta
B.fasta
C.fasta
D_paired_1.fasta
D_paired_2.fasta
dataset_metadata.csv
potara_job
simkaMin
simka_input.txt
simple_test.py
simple_test.sh
truth
__results__
test_simkaMin.py
truth_simkaMin
truth_simkaMin_symetrical
Testing simka

Creating input
Nb input datasets: 5

autopkgtest [15:13:14]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.igtubv5x/downtmp/build.vzK/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.igtubv5x/downtmp/run-unit-test-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.igtubv5x/downtmp/run-unit-test-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.igtubv5x/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.igtubv5x/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=32; unset
LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY
LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; chmod
+x
/tmp/autopkgtest-lxc.igtubv5x/downtmp/build.vzK/src/debian/tests/run-unit-test;
touch /tmp/autopkgtest-lxc.igtubv5x/downtmp/run-unit-test-stdout
/tmp/autopkgtest-lxc.igtubv5x/downtmp/run-unit-test-stderr;
/tmp/autopkgtest-lxc.igtubv5x/downtmp/build.vzK/src/debian/tests/run-unit-test
2> >(tee -a /tmp/autopkgtest-lxc.igtubv5x/downtmp/run-unit-test-stderr
>&2) > >(tee -a
/tmp/autopkgtest-lxc.igtubv5x/downtmp/run-unit-test-stdout);" (kind: test)
autopkgtest [15:13:15]: test run-unit-test: ---]



signature.asc
Description: OpenPGP digital signature

Bug#953982: wine-development: wine in Debian fails to start "Uru", but upstream wine works fine (regression)

[Diafero]

Version 5.0-3 also seems affected.

$ wine --version
wine-5.0 (Debian 5.0-3)

Kind regards
diafero

On 18.03.20 01:52, Michael Gilbert wrote:
> control: tag -1 moreinfo
> control: severity -1 minor
> 
> On Sun, Mar 15, 2020 at 7:21 AM Diafero wrote:
>> But with recent versions (I tried 5.1 and 5.2)
> 
> Could you test whether wine 5.0-3 (not wine-development) works or not?
>  This will help determine which patches are most likely the problem.
> 
> Best wishes,
> Mike
> 

Bug#954262: src:sumaclust: fails to migrate to testing for too long

[Paul Gevers]

Source: sumaclust
Version: 1.0.31-2
Severity: serious
Control: fixed -1 1.0.34-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:sumaclust in
its current version in unstable has been trying to migrate for 60 days
[2]. Hence, I am filing this bug.

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

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

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

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

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#954263: abcde: Overwrites previous rip file if CD release consists of multiple CDs

[Diederik de Haas]

Package: abcde
Version: 2.9.3-1
Severity: important

I encountered this issue when ripping "Simple Minds Live - In the city
of lights" which consists of 2 CDs.
On the first CD rip, it creates Live_in_the_City_of_Light.flac. On the
second CD rip, it simply overwrites that file (without
asking/confirming).

The command I used was "abcde -1 -o flac -a default,cue". If you add "-W
1" (or "-W 2"), then it updates the metadata of the file, but not the
filename itself.

I think this can be fixed if you add "_cdX", where 'X' is the "-W" 
parameter value, to the filename (and update the .cue file accordingly).


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

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

Versions of packages abcde depends on:
ii  cd-discid   1.4-1+b1
ii  cdparanoia  3.10.2+debian-13
ii  flac1.3.2-3
ii  libmusicbrainz-discid-perl  0.04-1+b1
ii  libwebservice-musicbrainz-perl  1.0.4-2
ii  sensible-utils  0.0.12
ii  vorbis-tools1.4.0-11
ii  wget1.20.1-1.1

Versions of packages abcde recommends:
ii  bsd-mailx8.1.2-0.20180807cvs-1
ii  glyrc1.0.10-1
ii  imagemagick  8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
ii  perl [libdigest-sha-perl]5.28.1-6
ii  vorbis-tools 1.4.0-11

Versions of packages abcde suggests:
pn  atomicparsley
pn  distmp3  
ii  eject2.1.5+deb1+cvs20081104-13.2
ii  eyed30.8.8-1
pn  id3  
pn  id3v2
ii  mkcue1-6
pn  mp3gain  
ii  normalize-audio  0.7.7-15
pn  vorbisgain   

-- no debconf information

Bug#954260: src:slurm-llnl: fails to migrate to testing for too long

[Paul Gevers]

Source: slurm-llnl
Version: 19.05.3.2-2
Severity: serious
Control: fixed -1 19.05.5-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:slurm-llnl in
its current version in unstable has been trying to migrate for 62 days
[2]. Hence, I am filing this bug.

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

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

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

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

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#954261: src:pyspread: fails to migrate to testing for too long

[Paul Gevers]

Source: pyspread
Version: 1.99.0.0-2
Severity: serious
Control: fixed -1 1.99.0.1-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

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

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

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

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

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

Paul

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




signature.asc
Description: OpenPGP digital signature

Bug#953942: RM: jack -- RoQA; python2-only; no new upstream code since 2005; better alternatives exist; blocking py2removal effort

[Scott Kitterman]

On Thursday, March 19, 2020 7:14:12 AM EDT you wrote:
> Package: ftp.debian.org
> Followup-For: Bug #953942
> 
> Wow. Gone in 4 days.
> While I can understand that ftpmasters are triggerhappy due to the py2
> removal, that seems excessive.
> 
> As for the "no upstream activity", that tends to happen when software is
> feature-complete.
> 
> And when claiming "better alternatives exist", I'd expect a list of
> names to follow. Not just to substantiate the claim, but also as a
> courtesy to the (soon to be ex-) users of jack.
> 
> FWIW, and without having tested anything, these packages seem to fill
> roughly the same purpose:
> yaret
> ripit
> pacpl
> abcde (bug page looks unhappy)
> crip  (maintained by QA)
> 
> I obviously have no idea whether they work as well as jack. Or whether
> they'll be gone from Debian 5 days from now, for that matter.

Removals are reversible if someone is interested in maintaining the package.  
The FTP Team processes hundreds of removals a year and so we're dependent on 
the inputs we get being reasonably accurate.  If the removal was wrong, 
someone can upload it again.

Scott K

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

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Diederik de Haas]

On woensdag 18 maart 2020 22:40:22 CET mario.limoncie...@dell.com wrote:
> I suspect this is related to an upgrade from the intermediary version that
> had problematic objects/permissions created.
 
> Can you please try to check whether there are broken symlinks in
> /var/lib/private or /var/cache/private?

It seems there are no symlinks, so also not broken symlinks. 

root@bagend:~# ls -la /var/lib/private/
total 12
drwx--  3 root root 4096 mei  3  2018 .
drwxr-xr-x 82 root root 4096 mrt 19 08:47 ..
drwxr-xr-x  2 root root 4096 jan 10  2019 systemd
root@bagend:~# ls -la /var/lib/private/systemd/
total 8
drwxr-xr-x 2 root root 4096 jan 10  2019 .
drwx-- 3 root root 4096 mei  3  2018 ..
root@bagend:~# ls -la /var/cache/private/
total 16
drwx--  4 root  root  4096 okt  9 21:36 .
drwxr-xr-x 22 root  root  4096 mrt  9 11:56 ..
drwxr-xr-x  2 62803 62803 4096 jul 30  2019 fwupd
drwxr-xr-x  2 62803 62803 4096 okt  9 21:36 fwupdmgr
root@bagend:~# ls -la /var/cache/private/fwupd/
total 720
drwxr-xr-x 2 62803 62803   4096 jul 30  2019 .
drwx-- 4 root  root4096 okt  9 21:36 ..
-rw-r--r-- 1 62803 62803 722862 jul 30  2019 metadata.xmlb
-rw-r--r-- 1 62803 62803   1471 jul 30  2019 metainfo.xmlb
root@bagend:~# ls -la /var/cache/private/fwupdmgr/
total 8
drwxr-xr-x 2 62803 62803 4096 okt  9 21:36 .
drwx-- 4 root  root  4096 okt  9 21:36 ..


FTR: My system is a fully up-to-date Sid system 
# systemd --version
systemd 245 (245.2-1)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN 
+PCRE2 default-hierarchy=hybrid

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

Bug#945015: only-branch only takes exact branch names

[Damyan Ivanov]

-=| gregor herrmann, 19.03.2020 11:34:19 +0100 |=-
> The merge request exists, thanks Iain!
> 
> https://salsa.debian.org/kgb-team/kgb/-/merge_requests/7
> 
> To me it looks good, and I especially appreciate the added tests.
> Iain, I guess you tested the changes also with a test installation,
> as discussed on IRC?
> 
> Dam, I hope you have a moment to look at the changes as well.

Looks good to me.

This:

-  ... not grep { ... } @{...}
+  ... not any  { } @{...}

is a nice catch :)

The only things missing for me are:

 * addition of Iain in the copyright notices and debian/copyright
 * addition of the new (build) dependencies to Build.PL

But I guess these can be made at release time as well.


-- dam

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Mario.Limonciello]

> From: Limonciello, Mario
> Sent: Thursday, March 19, 2020 8:58 AM
> To: Diederik de Haas
> Cc: 943...@bugs.debian.org
> Subject: RE: Bug#943343: fwupd: fwupd-refresh.service failed to start
> Refresh fwupd metadata and update motd.
> 
> > -Original Message-
> > From: Diederik de Haas 
> > Sent: Thursday, March 19, 2020 8:53 AM
> > To: Limonciello, Mario
> > Cc: 943...@bugs.debian.org
> > Subject: Re: Bug#943343: fwupd: fwupd-refresh.service failed to start
> > Refresh fwupd metadata and update motd.
> >
> > On donderdag 19 maart 2020 14:42:56 CET mario.limoncie...@dell.com
> > wrote:
> > > Has your system been rebooted recently?
> >
> > Yes. I usually shutdown my system at night.
> >
> > > I check on my (working) system and I don't have /run/motd.d as a
> > > symlink to /run/private/motd.d. For my system /run/motd.d is a real
> > > directory with a subdirectory "fwupd".
> > >
> > > I have a suspicion this is related to the issue.
> >
> > I don't have a /run/private directory and also no /run/motd.d.
> > I do have /run/motd.dynamic which is the same as "uname -nrsvm"
> (uname
> > - a minus the GNU/Linux part)
> 
> In your first post you had:
> 
> And about the runtime directory:
> $ ls -ld /run/motd.d
> lrwxrwxrwx 1 root root 14 oct 23 16:06 /run/motd.d -> private/motd.d $ ls -ld
> /run/private/
> drwx-- 3 root root 60 oct 23 16:06 /run/private/ $ sudo ls -ld
> /run/private/motd.d drwxr-xr-x 2 62803 62803 40 oct 23 16:06
> /run/private/motd.d $ sudo ls -l /run/private/motd.d total 0

Sorry - I see now that was from a while back.

Bug#954268: enigmail: autopkgtest times out after 2h47 or 5h35 if keyserver can't be reached

[Paul Gevers]

Source: enigmail
Version: 2:2.1.5+ds1-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: timeout

Dear maintainer(s),

The worker fleet of ci.d.n doesn't have the reliable network we would
wish for, but your package fails in an unpleasant way if a keyserver
can't be reached. Can you please detect the issue and fail more
gracefully, such that the test doesn't need to be killed by autopkgtest
after 2:47 hours idle time because of the autopkgtest timeout?

Paul

https://ci.debian.net/packages/e/enigmail/testing/arm64/

https://ci.debian.net/data/autopkgtest/testing/arm64/e/enigmail/4384388/log.gz

2020-02-26 17:05:54.370 [DEBUG] enigmailCommon.jsm: dispatchEvent
f=resizeDlg
2020-02-26 18:05:54.188 [DEBUG] keyRefreshService.jsm: Either no
keyservers exist or the protocols specified are invalid. Will recheck in
an hour.
2020-02-26 19:05:54.190 [DEBUG] keyRefreshService.jsm: Either no
keyservers exist or the protocols specified are invalid. Will recheck in
an hour.



signature.asc
Description: OpenPGP digital signature

Bug#954272: slurmd: SLURM not working with OpenMPI

[Lars Veldscholte]

Package: slurmd
Version: 19.05.3.2-2+b1
Severity: important

Dear Maintainer,

I am trying to get SLURM working on a single node. I have installed and 
configured slurmd and slurmctld.

A simple test like `srun hostname` works, even on multiple cores. However, when 
trying to use MPI, it crashes with the following error message:

*** An error occurred in MPI_Init
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
***and potentially your MPI job)

This happens even in the most simple "Hello World" case, as long as the program 
is MPI-enabled.

I am trying to use OpenMPI (4.0.2) from the Debian repositories. `srun --mpi 
list` returns:

srun: MPI types are...
srun: openmpi
srun: pmi2
srun: none

I have tried all options, but the result is the same in all cases.

Maybe this is user error, as this is my first time setting up SLURM, but I have 
not been able to find any possible causes/solutions and I am kind of stuck at 
this point.

Regards,

Lars

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

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

Versions of packages slurmd depends on:
ii  libc62.30-2
ii  libhwloc15   2.1.0+dfsg-4
ii  liblz4-1 1.9.2-2
ii  libnuma1 2.0.12-1+b1
ii  libpam0g 1.3.1-5
ii  lsb-base 11.1.0
ii  munge0.5.13-2+b1
ii  openssl  1.1.1d-2
ii  slurm-wlm-basic-plugins  19.05.3.2-2+b1
ii  ucf  3.0038+nmu1
ii  zlib1g   1:1.2.11.dfsg-2

slurmd recommends no packages.

slurmd suggests no packages.

-- no debconf information

Bug#954279: src:openjdk-11: Vcs-* metadata is outdated

[Tianon Gravi]

Package: src:openjdk-11
Version: 11~18-1
Severity: minor

Here's the current Vcs-* values for the openjdk-11 source:

| Vcs-Browser: https://code.launchpad.net/~openjdk/openjdk/openjdk11
| Vcs-Bzr: http://bazaar.launchpad.net/~openjdk/openjdk/openjdk11

These 404, and it'd be great if they could be updated to where these
sources actually get pushed (to avoid having to dig into
sources.debian.org just for historical data). :)

Thanks for your work on packaging OpenJDK!


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#954278: rust-cookie-factory: autopkgtest failure.

[peter green]

Source: rust-cookie-factory
Version: 0.3.0-1
Severity: serious


error[E0432]: unresolved import `io_compat`
   --> src/lib.rs:32:21
|
32 | pub use io_compat::*;
| ^ help: a similar path exists: 
`crate::io_compat`
|
= note: `use` statements changed in Rust 2018; read more at 



And a bunch more similar-looking errors.

This is happening on both the unstable->testing migration tests and the plain 
unstable checks, the testing version of the package does not appear to have an 
autopkgtest.

Bug#954280: debmirror: Option --exclude-deb-section=tex excludes "text" section as well

[kpp]

Package: debmirror
Version: 1:2.32
Severity: normal

I tried to download repository without "tex" section and found that 
"less" package was not downloaded.


Later I found that all packages in section "text" were not downloaded. 
If I remove option -exclude-deb-section=tex both section "tex" and 
"text" are downloaded.


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debmirror depends on:
ii  bzip21.0.6-9.2~deb10u1
pn  libdigest-md5-perl   
ii  libdigest-sha-perl   6.02-1+b1
ii  liblockfile-simple-perl  0.208-1
ii  libnet-inet6glue-perl0.603-2
ii  libwww-perl  6.36-2
ii  perl [libnet-perl]   5.28.1-6
ii  rsync3.1.3-6
ii  xz-utils 5.2.4-1

Versions of packages debmirror recommends:
ii  ed 1.15-1
ii  gpgv   2.2.12-1+deb10u1
ii  patch  2.7.6-3+deb10u1

Versions of packages debmirror suggests:
ii  gnupg  2.2.12-1+deb10u1

-- debconf-show failed

Bug#954274: gzip: stdin: warning: file timestamp out of range for gzip format

[Christian Göttsche]

Maybe a duplicate of #504333 [1] ?

What is the mtime of /var/log/syslog.1 ? (ls -l /var/log/syslog.1)


[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504333

Bug#954281: zsh completion file not installed

[Laurent Bigonville]

Source: bluez
Version: 5.50-1
Severity: wishlist

Hello,

When rebuilding the package I saw that
usr/share/zsh/site-functions/_bluetoothctl was not installed.

Shouldn't that file be installed?

Kind regards,

Laurent Bigonville

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

-- no debconf information

Bug#954282: Please move daemon to /usr/libexec/bluetooth instead of /usr/lib/bluetooth

[Laurent Bigonville]

Package: bluez
Version: 5.50-1
Severity: wishlist
Tags: patch

Hello,

Now that debian supports the FHS 3.0 and that FHS 3.0 describes the
/usr/libexec directory, the daemons should probably be moved there.

Debhelper >= 12 already sets --libexecdir to /usr/libexec by default

Please find a patch that fixes this

Kind regards,

Laurent Bigonville

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages bluez depends on:
ii  dbus  1.12.16-2
ii  kmod  27-2
ii  libasound21.2.2-2.1
ii  libc6 2.30-2
ii  libdbus-1-3   1.12.16-2
ii  libdw10.176-1.1
ii  libglib2.0-0  2.64.1-1
ii  libreadline8  8.0-4
ii  libudev1  245.2-1
ii  lsb-base  11.1.0
ii  udev  245.2-1

bluez recommends no packages.

Versions of packages bluez suggests:
ii  pulseaudio-module-bluetooth  13.0-5

-- no debconf information
diff -Nru bluez-5.52/debian/bluez.install bluez-5.52/debian/bluez.install
--- bluez-5.52/debian/bluez.install 2019-11-13 05:26:08.0 +0100
+++ bluez-5.52/debian/bluez.install 2020-03-19 16:33:22.0 +0100
@@ -1,7 +1,7 @@
 src/main.conf etc/bluetooth
 profiles/input/input.conf etc/bluetooth
 profiles/network/network.conf etc/bluetooth
-usr/lib/bluetooth/bluetoothd
+usr/libexec/bluetooth/bluetoothd
 usr/bin/bluetoothctl
 usr/bin/bccmd
 usr/bin/bluemoon
diff -Nru bluez-5.52/debian/bluez.links bluez-5.52/debian/bluez.links
--- bluez-5.52/debian/bluez.links   2019-11-13 05:26:08.0 +0100
+++ bluez-5.52/debian/bluez.links   2020-03-19 16:33:42.0 +0100
@@ -1 +1 @@
-usr/lib/bluetooth/bluetoothd usr/sbin/bluetoothd
+usr/libexec/bluetooth/bluetoothd usr/sbin/bluetoothd
diff -Nru bluez-5.52/debian/bluez-obexd.install 
bluez-5.52/debian/bluez-obexd.install
--- bluez-5.52/debian/bluez-obexd.install   2019-11-13 05:26:08.0 
+0100
+++ bluez-5.52/debian/bluez-obexd.install   2020-03-19 16:33:35.0 
+0100
@@ -1,3 +1,3 @@
-usr/lib/bluetooth/obexd
+usr/libexec/bluetooth/obexd
 usr/share/dbus-1/services/org.bluez.obex.service
 usr/lib/systemd/user/obex.service
diff -Nru bluez-5.52/debian/rules bluez-5.52/debian/rules
--- bluez-5.52/debian/rules 2019-11-13 05:26:08.0 +0100
+++ bluez-5.52/debian/rules 2020-03-19 16:33:00.0 +0100
@@ -6,7 +6,6 @@
 CONFIGURE_FLAGS := \
--disable-silent-rules \
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
-   --libexec=\$${prefix}/lib/ \
--enable-static \
--enable-tools \
--enable-cups \

Bug#954274: y2038 problem

[Christian Göttsche]

Oops, I missed the reply from Adam.

He might be right.
You might want to try out adding the line

compressoptions "-n"

to /etc/logrotate.conf

Bug#932617: any update on this as I still got it today with the update (again)

[shirish शिरीष]

Hi all,

See -

$ adequate fwupd
fwupd: obsolete-conffile /etc/dbus-1/system.d/org.freedesktop.fwupd.conf
fwupd: obsolete-conffile /etc/fwupd/remotes.d/fwupd.conf

I wanna try fwupd but once the above obsolete conffiles are removed. I
do know it's a work in progress but still. FWIW, the package got
updated to 1.3.9.2

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#954274: y2038 problem

[Adam Borowski]

Sergio: could you take a look at dates in your /var/log (and subpaths)?
I'm pretty sure you have post-2038 (or pre- 1901-12-13) files there.

I see this one a lot, as for me this happens because of a bug in Allwinner
A64 chipset which causes large forward time jumps.

I've filed this in gzip as #950519, that might be a better solution as it'd
solve the same problem globally rather than just for logrotate.

But if we'd want to fix it here, in logrotate, it's just a two-character
patch that adds -n to gzip's invocation.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
⠈⠳⣄

Bug#953950: python-twisted: twisted version 14.0.2-3+deb8u1 in jessie (security) is broken

[Chris Lamb]

Hi all,

> Please, can you […] revert this patch and re-publish the working (but
> security flawed) 14.0.2-3 twisted version ?

I will take charge of fixing this in jessie with the utmost urgency.

Thank you for raising this issue.


Regards,

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

Bug#697200: 10 ваших долазних порука је суспендовано

[Vasilka Tabakova]

МИЦРОСОФТ ОБАВЕШТЕЊЕ МЕМО

10 ваших долазних порука је суспендовано, а рачун е-поште такође ће ускоро бити 
суспендован јер ваш налог за е-пошту није верификован ове године. кликните на 
потврди одмах доле да бисте верификовали рачун е-поште


ПОТВРДИТЕ САДА



Хвала на разумевању



Мицрософт Верифицатион Теам



Мицрософт Оутлоок Цопиригхт © 2020 .Инц. Сва права задржана.

Bug#919134: Python and PIE

[Giovanni Pellerano]

Hello Doko,

is there any update on this issue?

Thank you for your attention,

best,

Giovanni Pellerano

Il giorno mer 20 nov 2019 alle ore 18:45 Giovanni Pellerano
 ha scritto:
>
> Hello all,
>
> I've performed some benchmarks following the instructions provided by
> Michele 
> (https://github.com/freedomofpress/securedrop/issues/1861#issuecomment-554035468).
>
> Please find attached the results.
>
> From my tests its seems to not exist any particular performance loss;
> actually some tests results in a gain.
>
> please let me know if there is something else I could support
> retesting to possibly speed up the progress on the integration of the
> proposed patch.
>
> Best,
>
> Giovanni
>
> Il giorno sab 9 nov 2019 alle ore 18:19 Michele Orrù
>  ha scritto:
> >>
> >> seriously?  For a few months you are writing emails without subject 
> >> landing in
> >> my spam folder, and then you are starting threats?
> >
> >
> > Hi Doko,
> >
> > as I wrote privately immediately after:
> >
> >> reading back my email it sounds a lot like a threat.
> >> When I wrote the email I was just thinking that I should give a heads up 
> >> because it's been now more than one month and I don't know what else to do 
> >> besides asking other dd.
> >>
> >> So, please forgive the tone in my previous email Matthias.
> >
> >
> > I'm not trying to threaten you, I just want to help you out improve debian, 
> > and from my (naïve) perspective reaching out to other DD was the logical 
> > solution for no answer.
> >
> > That said, I'm sorry for the subject line. I'm relatively new here: I 
> > didn't know if my b.d.o email will be processed adding the issue number in 
> > the subject, and I didn't know if the subject will be embedded in the 
> > message and cause confusion. Besides email to b.d.o:
> > - I tried to reach out to you on irc, over public channels and in private;
> > - people tried to reach out to you via ubuntu bug tracker: 
> > https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1452115.
> >  Perhaps you can give me some slack, and we can all move on? Holger already 
> > told me that was stupid.
> >
> > Now that this bug has come to your attention again:
> >
> >> I also doubt very much your numbers, 2.5 - 5 times slower is not expected. 
> >> PIE
> >> has some impact, but not that bad.
> >
> >
> > Even before measuring performance loss (which could be due to intel turbo 
> > being active on my machine for a start, and I'm happy to test again so that 
> > you can double-check my steps), do you think performances are crucial for 
> > enabling PIE on /usr/bin/python3?
> >
> > If not, would you mind if I try to help out updating the package? It's a 
> > relatively easy issue and I could learn something about packaging in the 
> > process.
> > If yes, could you please explain to me how this is different from python2?
> >
> > Apologising again,
> > --
> > μ.
>
>
>
> --
> Ing. Giovanni Pellerano - Founding Member and CTO
> giovanni.peller...@hermescenter.org | +39.328.9590046
>
> HERMES - Center for Transparency and Digital Human Rights
> Associazione No Profit | Via Aretusa 34, IT-20129 Milan, Italy
> t. +39-02-87186005 (voicemail) | f. +39-02-87162573
> TaxCode: IT-97621810155 | EuropeAid: IT-2012-AOD-0806909254
> w. https://www.hermescenter.org | m. i...@hermescenter.org



-- 
Ing. Giovanni Pellerano - Founding Member and CTO
giovanni.peller...@hermescenter.org | +39.328.9590046

HERMES - Center for Transparency and Digital Human Rights
Associazione No Profit | Via Aretusa 34, IT-20129 Milan, Italy
t. +39-02-87186005 (voicemail) | f. +39-02-87162573
TaxCode: IT-97621810155 | EuropeAid: IT-2012-AOD-0806909254
w. https://www.hermescenter.org | m. i...@hermescenter.org

Bug#954274: gzip: stdin: warning: file timestamp out of range for gzip format

[Sergio Belkin]

Package: logrotate
Version: 3.14.0-4
Severity: important



-- Package-specific info:
Contents of /etc/logrotate.d
total 52
-rw-r--r-- 1 root root 120 Apr 18  2019 alternatives
-rw-r--r-- 1 root root 173 May 28  2019 apt
-rw-r--r-- 1 root root 130 Aug 28  2018 btmp
-rw-r--r-- 1 root root 112 Apr 18  2019 dpkg
-rw-r--r-- 1 root root 165 Jun 17  2019 libvirtd
-rw-r--r-- 1 root root 143 Jun 17  2019 libvirtd.libxl
-rw-r--r-- 1 root root 141 Jun 17  2019 libvirtd.lxc
-rw-r--r-- 1 root root 142 Jun 17  2019 libvirtd.qemu
-rw-r--r-- 1 root root  94 Nov  4  2018 ppp
-rw-r--r-- 1 root root 501 Feb 26  2019 rsyslog
-rw-r--r-- 1 root root 677 Jan  1  2019 speech-dispatcher
-rw-r--r-- 1 root root 235 Jun  8  2019 unattended-upgrades
-rw-r--r-- 1 root root 145 Feb 19  2018 wtmp


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_AR:es (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages logrotate depends on:
ii  anacron 2.3-28
ii  cron [cron-daemon]  3.0pl1-134+deb10u1
ii  libacl1 2.2.53-4
ii  libc6   2.28-10
ii  libpopt01.16-12
ii  libselinux1 2.8-1+b1
ii  systemd-sysv241-7~deb10u3

Versions of packages logrotate recommends:
pn  bsd-mailx | mailx  

logrotate suggests no packages.

-- no debconf information


journalctl shows the following message:

mar 19 10:36:48 debian systemd[1]: Starting Rotate log files...
mar 19 10:36:48 debian logrotate[463]: error: Compressing program wrote 
following message to stderr when compressing log /var/log/sys
mar 19 10:36:48 debian logrotate[463]: gzip: stdin: warning: file timestamp out 
of range for gzip format
mar 19 10:36:49 debian logrotate[463]: error: failed to compress log 
/var/log/syslog.1
mar 19 10:36:49 debian systemd[1]: logrotate.service: Main process exited, 
code=exited, status=1/FAILURE
mar 19 10:36:49 debian systemd[1]: logrotate.service: Failed with result 
'exit-code'.
mar 19 10:36:49 debian systemd[1]: Failed to start Rotate log files.

Bug#954276: cloud-init - RuntimeError: dictionary keys changed during iteration

[Bastian Blank]

Package: cloud-init
Version: 20.1-1
Severity: serious

cloud-init 20.1-1 fails to provision Azure:

| 2020-03-19 14:31:48,840 - util.py[DEBUG]: Running module disk_setup () failed
| Traceback (most recent call last):
|   File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 848, in 
_run_modules
| ran, _r = cc.run(run_name, mod.handle, func_args,
|   File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
| return self._runners.run(name, functor, args, freq, clear_on_fail)
|   File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 185, in run
| results = functor(*args)
|   File "/usr/lib/python3/dist-packages/cloudinit/config/cc_disk_setup.py", 
line 129, in handle
| update_disk_setup_devices(disk_setup, cloud.device_name_to_device)
|   File "/usr/lib/python3/dist-packages/cloudinit/config/cc_disk_setup.py", 
line 166, in update_disk_setup_devices
| for origname in disk_setup.keys():
| RuntimeError: dictionary keys changed during iteration

Bastian

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

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

Versions of packages cloud-init depends on:
pn  cloud-guest-utils   
ii  fdisk   2.34-0.1
ii  gdisk   1.0.5-1
pn  ifupdown
ii  locales 2.29-10
ii  lsb-base11.1.0
ii  lsb-release 11.1.0
ii  net-tools   1.60+git20180626.aebd88e-1
ii  procps  2:3.3.15-2+b1
ii  python3 3.7.5-3
pn  python3-configobj   
ii  python3-jinja2  2.10.1-2
pn  python3-jsonpatch   
pn  python3-jsonschema  
pn  python3-oauthlib
ii  python3-requests2.22.0-2
ii  python3-six 1.14.0-2
ii  python3-yaml5.3-2
ii  util-linux  2.34-0.1

Versions of packages cloud-init recommends:
pn  eatmydata  
ii  sudo   1.8.31-1

Versions of packages cloud-init suggests:
pn  btrfs-progs  
ii  e2fsprogs1.45.5-2
pn  xfsprogs