date:20191222

Source: sudo
Version: 1.8.29-1
Severity: important
Tags: security upstream

Hi,

The following vulnerabilities were published for sudo, and adressed
for both in 1.8.30b2[2].

CVE-2019-19232[0]:
| In Sudo through 1.8.29, an attacker with access to a Runas ALL sudoer
| account can impersonate a nonexistent user by invoking sudo with a
| numeric uid that is not associated with any user.


CVE-2019-19234[1]:
| In Sudo through 1.8.29, the fact that a user has been blocked (e.g.,
| by using the ! character in the shadow file instead of a password
| hash) is not considered, allowing an attacker (who has access to a
| Runas ALL sudoer account) to impersonate any blocked user.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-19232
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19232
[1] https://security-tracker.debian.org/tracker/CVE-2019-19234
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19234
[2] https://www.sudo.ws/devel.html#1.8.30b2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#947224: Access To Private Log File

2019-12-22 Thread Ankit Devnalkar

Package: ion
Version: 3.2.0~dfsg1-1clang1

While surfing clang.debian.net, I found a private log file is accessible to
the world. As it is giving 403(Forbidden) while surfing other directories
on same path, I am sure this one is private log file and might be opened
accidentally. Also, attaching screenshots for reference.

path :
https://clang.debian.net/logs/2014-09-03/ion_3.2.0~dfsg1-1_unstable_clang.log
-- 
 Thanks & Regards,
Ankit Devnalkar

*Cybersecurity Analyst & Independent Researcher*
M:+91 8377870329
E: ankitdevnal...@gmail.com

Bug#947223: xwayland: Unable to utilize monitor at its full native 2560x1080 resolution

2019-12-22 Thread skyguide

Package: xwayland
Version: 2:1.20.4-1
Severity: important

After a switch by Debian project to a wayland protocol, I am not able to use a 
full resolution of our monitors. 
Monitors are LG-29UM57-P. Their default and native resolution is 2560x1080.

Monitor is connected to PC via DisplayPort interface. 

This issue only manifested after migrating from GNU/Debian v8 Jessie to 
GNU/Debian v 9 Stretch and to GNU/Debian v10 Buster. 

Monitor functioned as expected under Debian 8 Jessie at it's full 2560x1080 
resolution. 
There was no change in hardware what so ever. Once Debian Stretch was 
installed, it is no longer possible to set a monitor resolution to it's native 
resolution. 

Same issue with Debian 10 Buster. 

Please advise what can be done (other than rolling back to Debian Jessie) to 
switch XServer+Wayland to a proper full resolution. 

Please note, exact same hardware PC/Graphical card + displayport cable + 
Monitor worked as expected with Debian Jessie, therefor this is not a hardware 
limitation. 

Thank you for looking in to this matter. 

HW details: 
System:Host: t420 Kernel: 4.19.0-6-amd64 x86_64 bits: 64 Desktop: Gnome 
3.30.2 Distro: Debian GNU/Linux 10 (buster)
Machine:   Type: Laptop System: LENOVO product: 4178C9U v: ThinkPad T420
CPU:   Topology: Dual Core model: Intel Core i7-2640M bits: 64 type: MT MCP 
L2 cache: 4096 KiB 
   Speed: 798 MHz min/max: 800/3500 MHz Core speeds (MHz): 1: 798 2: 
797 3: 797 4: 797 
Graphics:  Device-1: Intel 2nd Generation Core Processor Family Integrated 
Graphics driver: i915 v: kernel 
   Display: wayland server: X.Org 1.20.4 driver: i915 resolution: 
1600x900~60Hz, 1920x1080~60Hz 
   OpenGL: renderer: Mesa DRI Intel Sandybridge Mobile v: 3.3 Mesa 
18.3.6 


Damien 



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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 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 xwayland depends on:
ii  libaudit1   1:2.8.4-3
ii  libbsd0 0.9.1-2
ii  libc6   2.28-10
ii  libdrm2 2.4.97-1
ii  libegl1 1.1.0-1
ii  libepoxy0   1.5.3-0.1
ii  libgbm1 18.3.6-2
ii  libgcrypt20 1.8.4-5
ii  libgl1  1.1.0-1
ii  libpixman-1-0   0.36.0-1
ii  libselinux1 2.8-1+b1
ii  libsystemd0 241-7~deb10u2
ii  libunwind8  1.2.1-9
ii  libwayland-client0  1.16.0-1
ii  libxau6 1:1.0.8-1+b2
ii  libxdmcp6   1:1.1.2-3
ii  libxfont2   1:2.0.3-1
ii  libxshmfence1   1.3-1
ii  xserver-common  2:1.20.4-1

xwayland recommends no packages.

xwayland suggests no packages.

-- no debconf information

Bug#947205: fwupd.shutdown failed with exit status 2

2019-12-22 Thread Mario.Limonciello

It's fixed upstream by this commit:

https://github.com/fwupd/fwupd/commit/1db7e987ae9cf1b81117040762e90db6c15b5202

Which should be part of next release.

On Dec 22, 2019 16:00, Jochen Sprickerhof  wrote:

[EXTERNAL EMAIL]

Package: fwupd
Version: 1.3.5-1
Severity: normal

Hi,

when shutting down my system, systemd prints:

/lib/systemd/system-shutdown/fwupd.shutdown failed with exit status 2

looking into fwupd.shutdown, I guess this should normally be prevented by

[ -f /var/lib/fwupd/pending.db ] || exit 0

And it's all fine if I remove the pending.db. But running

fwupdmgr refresh

creates the file again, although

fwupdmgr get-updates

tells me that there are no updates.

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

Kernel: Linux 5.3.0-3-amd64 (SMP w/8 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 fwupd depends on:
ii  libc6  2.29-6
ii  libefiboot137-2
ii  libefivar1 37-2
ii  libelf10.176-1.1
ii  libfwupd2  1.3.5-1
ii  libfwupdplugin11.3.5-1
ii  libglib2.0-0   2.62.3-2
ii  libgnutls303.6.11.1-2
ii  libgpg-error0  1.36-7
ii  libgpgme11 1.13.1-1
ii  libgudev-1.0-0 233-1
ii  libgusb2   0.3.0-1
ii  libjson-glib-1.0-0 1.4.4-2
ii  libpolkit-gobject-1-0  0.105-26
ii  libsmbios-c2   2.4.1-1
ii  libsoup2.4-1   2.68.2-1
ii  libsqlite3-0   3.30.1-1
ii  libtss2-esys0  2.3.1-3
ii  libxmlb1   0.1.14-1
ii  shared-mime-info   1.10-1

Versions of packages fwupd recommends:
pn  bolt  
pn  fwupd-signed  
ii  python3   3.7.5-3

fwupd suggests no packages.

-- no debconf information

Bug#947222: rain: Default delay is in wrong units, making it effectively 0

2019-12-22 Thread Asher Gordon

Package: bsdgames
Version: 2.17-28
Severity: normal
Tags: patch

Dear Maintainer,

In bsdgames 2.17.20, #579062[1] was supposedly fixed. However, `delay'
is passed to usleep()[2]. Since the "fix" changed the default value of
`delay' to 120, that makes the default delay 120 *micro*seconds instead
of 120 *milli*seconds, making it practically the same as 0. Note that
when "-d" is parsed, the integer argument is multiplied by 1000 before
being used for the delay.

The default delay should be 12, not 120. See the following patch
(apply with 'patch -p0 < fix-delay.patch'):
--- rain/rain.c~	2018-10-13 20:05:55.0 -0400
+++ rain/rain.c	2019-12-22 23:41:11.723230711 -0500
@@ -70,7 +70,7 @@
 {
 	int x, y, j;
 	long cols, lines;
-	unsigned int delay = 120;
+	unsigned int delay = 12;
 	unsigned long val = 0;
 	int ch;
 	char *ep;
Suggestion: Include this in
0005-rain-Update-default-delay.-Closes-579062.patch rather than creating
a new patch.

See also: #723808


Thanks,
Asher


Footnotes: 
[1]  Which suggests that the default delay should be changed to 120
 milliseconds.

[2]  Which has not been in POSIX since POSIX.1-2008 and has been
 obsolete since POSIX.1-2001. But that is a different issue.

-- 
By necessity, by proclivity, and by delight, we all quote.  In fact, it is as
difficult to appropriate the thoughts of others as it is to invent.
-- R. Emerson
-- Quoted from a fortune cookie program
(whose author claims, "Actually, stealing IS easier.")
[to which I reply, "You think it's easy for me to
misconstrue all these misquotations?!?"  Ed.]

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68

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

Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bsdgames depends on:
ii  libc62.29-3
ii  libfl2   2.6.4-6.2
ii  libgcc1  1:9.2.1-21
ii  libncurses6  6.1+20191019-1
ii  libstdc++6   9.2.1-21
ii  libtinfo66.1+20191019-1
ii  wamerican [wordlist] 2018.04.16-1
ii  wamerican-insane [wordlist]  2018.04.16-1
ii  wbritish [wordlist]  2018.04.16-1

bsdgames recommends no packages.

bsdgames suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#920147: [Debian-science-sagemath] Bug#920147: sagemath FTBFS on mipsel and mips64el

2019-12-22 Thread peter green


On 23/12/2019 04:15, Ximin Luo wrote:

I've set the severity of this bug to important, because it should not block 
migration.

If this were a regression then it would be RC, but since sagemath is already 
not in testing, it is not a regression. There is no reason or policy to block 
migration because it *remains* missing on some release architectures.


Out of date binaries in unstable will block migration, even if there is no rc 
bug. If you want this package to migrate to testing you will need to request 
removal from the ftpmasters.

Bug#937385: pyalsaaudio: diff for NMU version 0.8.4-1.1

Control: tags 937385 + patch


Dear maintainer,

I've prepared an NMU for pyalsaaudio (versioned as 0.8.4-1.1). The diff
is attached to this message.

Regards.

diff -Nru pyalsaaudio-0.8.4/debian/changelog pyalsaaudio-0.8.4/debian/changelog
--- pyalsaaudio-0.8.4/debian/changelog	2018-09-21 10:45:13.0 -0400
+++ pyalsaaudio-0.8.4/debian/changelog	2019-12-22 23:11:25.0 -0500
@@ -1,3 +1,10 @@
+pyalsaaudio (0.8.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python3 support; Closes: #937385
+
+ -- Sandro Tosi   Sun, 22 Dec 2019 23:11:25 -0500
+
 pyalsaaudio (0.8.4-1) unstable; urgency=medium
 
   * New upstream version 0.8.4 (closes: #613091, #909226)
diff -Nru pyalsaaudio-0.8.4/debian/control pyalsaaudio-0.8.4/debian/control
--- pyalsaaudio-0.8.4/debian/control	2018-09-21 10:45:13.0 -0400
+++ pyalsaaudio-0.8.4/debian/control	2019-12-22 23:09:33.0 -0500
@@ -4,12 +4,9 @@
 Maintainer: Paul Brossier 
 Build-Depends: debhelper (>= 10~),
dh-python,
-   python-all-dev (>= 2.3.5-11),
-   python-setuptools,
python3-all-dev,
python3-setuptools,
libasound2-dev,
-   python-sphinx,
python3-sphinx,
libjs-jquery,
libjs-underscore
@@ -18,17 +15,6 @@
 Vcs-Git: https://salsa.debian.org/multimedia-team/pyalsaaudio.git
 Vcs-Browser: https://salsa.debian.org/multimedia-team/pyalsaaudio
 
-Package: python-alsaaudio
-Architecture: any
-Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}
-Recommends: libjs-jquery, libjs-underscore
-Description: Alsa bindings for Python
- This package contains wrappers for accessing the ALSA API from Python.
- Access to PCM devices and Mixer is supported. Access to MIDI sequencers
- is not supported yet.
- .
- This package provides the alsaaudio module for Python 2.
-
 Package: python3-alsaaudio
 Architecture: any
 Depends: ${python3:Depends}, ${shlibs:Depends}, ${misc:Depends}
diff -Nru pyalsaaudio-0.8.4/debian/python-alsaaudio.docs pyalsaaudio-0.8.4/debian/python-alsaaudio.docs
--- pyalsaaudio-0.8.4/debian/python-alsaaudio.docs	2017-08-21 13:12:11.0 -0400
+++ pyalsaaudio-0.8.4/debian/python-alsaaudio.docs	1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-TODO
-doc/html/
diff -Nru pyalsaaudio-0.8.4/debian/python-alsaaudio.examples pyalsaaudio-0.8.4/debian/python-alsaaudio.examples
--- pyalsaaudio-0.8.4/debian/python-alsaaudio.examples	2018-09-21 09:37:01.0 -0400
+++ pyalsaaudio-0.8.4/debian/python-alsaaudio.examples	1969-12-31 19:00:00.0 -0500
@@ -1,3 +0,0 @@
-mixertest.py
-playbacktest.py
-recordtest.py
diff -Nru pyalsaaudio-0.8.4/debian/rules pyalsaaudio-0.8.4/debian/rules
--- pyalsaaudio-0.8.4/debian/rules	2018-09-21 09:29:12.0 -0400
+++ pyalsaaudio-0.8.4/debian/rules	2019-12-22 23:11:25.0 -0500
@@ -5,7 +5,7 @@
 export PYBUILD_TEST_ARGS=cd '{build_dir}'; python{version} {dir}/test.py -v
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_clean:
 	dh_auto_clean --buildsystem=pybuild
@@ -15,7 +15,7 @@
 
 override_dh_auto_build:
 	dh_auto_build --buildsystem=pybuild
-	cd doc && make
+	cd doc && $(MAKE) SPHINXBUILD=/usr/share/sphinx/scripts/python3/sphinx-build
 
 override_dh_auto_install:
 	dh_auto_install --buildsystem=pybuild
@@ -25,7 +25,5 @@
 
 override_dh_installdocs:
 	dh_installdocs
-	ln -sf /usr/share/javascript/jquery/jquery.js debian/python-alsaaudio/usr/share/doc/python-alsaaudio/html/_static/jquery.js
-	ln -sf /usr/share/javascript/underscore/underscore.js debian/python-alsaaudio/usr/share/doc/python-alsaaudio/html/_static/underscore.js
 	ln -sf /usr/share/javascript/jquery/jquery.js debian/python3-alsaaudio/usr/share/doc/python3-alsaaudio/html/_static/jquery.js
 	ln -sf /usr/share/javascript/underscore/underscore.js debian/python3-alsaaudio/usr/share/doc/python3-alsaaudio/html/_static/underscore.js
diff -Nru pyalsaaudio-0.8.4/debian/tests/control pyalsaaudio-0.8.4/debian/tests/control
--- pyalsaaudio-0.8.4/debian/tests/control	2018-09-21 07:39:26.0 -0400
+++ pyalsaaudio-0.8.4/debian/tests/control	2019-12-22 23:11:13.0 -0500
@@ -1,3 +1,3 @@
-Tests: py2xtests, py3xtests
+Tests: py3xtests
 Depends: @
 Restrictions: allow-stderr
diff -Nru pyalsaaudio-0.8.4/debian/tests/py2xtests pyalsaaudio-0.8.4/debian/tests/py2xtests
--- pyalsaaudio-0.8.4/debian/tests/py2xtests	2018-09-21 07:38:31.0 -0400
+++ pyalsaaudio-0.8.4/debian/tests/py2xtests	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-python2 test.py -v

Bug#920147: [Debian-science-sagemath] Bug#920147: sagemath FTBFS on mipsel and mips64el

2019-12-22 Thread Ximin Luo

I've set the severity of this bug to important, because it should not block 
migration.

If this were a regression then it would be RC, but since sagemath is already 
not in testing, it is not a regression. There is no reason or policy to block 
migration because it *remains* missing on some release architectures.

X

Tobias Hansen:
> On 1/22/19 8:59 AM, peter green wrote:
>> sagemath versions from 8.4-2 through to 8.6-2 have failed to build on mipsel 
>> and mips64el.
> snip
>> This will need to be dealt with one way or the other (either by fixing the 
>> build failures or by requesting removal of the old binaries) before sagemath 
>> can migrate to testing.
>>
> Are you sure? I thought old binaries only prevent migration when they are in 
> testing. sagemath is not in testing at the moment.
> 
> Now migration is of course blocked by this RC bug.
> 
> Best,
> 
> Tobias
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#937724: python-efilter: diff for NMU version 1.5-2.1

Control: tags 937724 + patch


Dear maintainer,

I've prepared an NMU for python-efilter (versioned as 1.5-2.1). The diff
is attached to this message.

Regards.

diff -Nru python-efilter-1.5/debian/changelog python-efilter-1.5/debian/changelog
--- python-efilter-1.5/debian/changelog	2016-12-05 05:13:51.0 -0500
+++ python-efilter-1.5/debian/changelog	2019-12-22 23:06:46.0 -0500
@@ -1,3 +1,10 @@
+python-efilter (1.5-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937724
+
+ -- Sandro Tosi   Sun, 22 Dec 2019 23:06:46 -0500
+
 python-efilter (1.5-2) unstable; urgency=medium
 
   * Fix copyright owner (Closes: #846629)
diff -Nru python-efilter-1.5/debian/control python-efilter-1.5/debian/control
--- python-efilter-1.5/debian/control	2016-12-02 07:18:25.0 -0500
+++ python-efilter-1.5/debian/control	2019-12-22 23:06:30.0 -0500
@@ -3,29 +3,17 @@
 Priority: optional
 Maintainer: Hilko Bengen 
 Build-Depends: debhelper (>=9), dh-python,
- python-all (>= 2.6.6-3~),python3-all,
- python-setuptools, python3-setuptools,
- python-pytest, python3-pytest,
- python-dateutil (>> 2), python3-dateutil (>> 2),
- python-six (>> 1.4.0), python3-six (>> 1.4.0),
- python-tz (>> 2011), python3-tz (>> 2011),
+ python3-all,
+ python3-setuptools,
+ python3-pytest,
+ python3-dateutil (>> 2),
+ python3-six (>> 1.4.0),
+ python3-tz (>> 2011),
 Standards-Version: 3.9.8
 Homepage: https://pypi.python.org/pypi/efilter
-X-Python-Version: >= 2.6
-X-Python3-Version: >= 3.2
 Vcs-Git: git://anonscm.debian.org/collab-maint/python-efilter.git
 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/python-efilter.git
 
-Package: python-efilter
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends},
-Description: EFILTER query language (Python 2)
- EFILTER is a general-purpose destructuring and search language implemented in 
- Python, and suitable for integration with any Python project that requires a 
- search function for some of its data.
- .
- This package installs the library for Python 2.
-
 Package: python3-efilter
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends},
diff -Nru python-efilter-1.5/debian/rules python-efilter-1.5/debian/rules
--- python-efilter-1.5/debian/rules	2016-12-02 07:23:26.0 -0500
+++ python-efilter-1.5/debian/rules	2019-12-22 23:06:43.0 -0500
@@ -3,7 +3,7 @@
 export PYBUILD_NAME=efilter
 
 %:
-	dh $@  --with python2,python3 --buildsystem=pybuild
+	dh $@  --with python3 --buildsystem=pybuild
 
 # Tests don't work because efilter_tests module is missing.
 override_dh_auto_test:

Bug#937570: python-acora: diff for NMU version 2.2-1.2

Control: tags 937570 + patch


Dear maintainer,

I've prepared an NMU for python-acora (versioned as 2.2-1.2). The diff
is attached to this message.

Regards.

diff -Nru python-acora-2.2/debian/changelog python-acora-2.2/debian/changelog
--- python-acora-2.2/debian/changelog	2019-06-03 11:03:53.0 -0400
+++ python-acora-2.2/debian/changelog	2019-12-22 23:03:28.0 -0500
@@ -1,3 +1,10 @@
+python-acora (2.2-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937570
+
+ -- Sandro Tosi   Sun, 22 Dec 2019 23:03:28 -0500
+
 python-acora (2.2-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-acora-2.2/debian/control python-acora-2.2/debian/control
--- python-acora-2.2/debian/control	2019-01-22 12:54:44.0 -0500
+++ python-acora-2.2/debian/control	2019-12-22 23:03:10.0 -0500
@@ -3,29 +3,15 @@
 Priority: optional
 Maintainer: Hilko Bengen 
 Build-Depends: debhelper (>= 12), dh-python,
- python-all-dev (>= 2.6.6-3~), python3-all-dev,
- python-setuptools, python3-setuptools,
- cython, cython3,
- python-pytest, python3-pytest,
+ python3-all-dev,
+ python3-setuptools,
+ cython3,
+ python3-pytest,
 Standards-Version: 4.3.0
 Homepage: https://pypi.python.org/pypi/acora
-X-Python-Version: >= 2.6
-X-Python3-Version: >= 3.2
 Vcs-Git: https://salsa.debian.org/debian/python-acora.git
 Vcs-Browser: https://salsa.debian.org/debian/python-acora.git
 
-Package: python-acora
-Architecture: any
-Depends: ${python:Depends}, ${misc:Depends}, ${shlibs:Depends},
-Description: fast multi-keyword text search engine (Python 2)
- Acora is 'fgrep' for Python, a fast multi-keyword text search engine.
- .
- Based on a set of keywords and the Aho-Corasick algorithm, it
- generates a search automaton and runs it over string input, either
- unicode or bytes.
- .
- This package installs the library for Python 2.
-
 Package: python3-acora
 Architecture: any
 Depends: ${python3:Depends}, ${misc:Depends}, ${shlibs:Depends},
diff -Nru python-acora-2.2/debian/python-acora.docs python-acora-2.2/debian/python-acora.docs
--- python-acora-2.2/debian/python-acora.docs	2019-01-22 12:47:30.0 -0500
+++ python-acora-2.2/debian/python-acora.docs	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-README.rst
diff -Nru python-acora-2.2/debian/rules python-acora-2.2/debian/rules
--- python-acora-2.2/debian/rules	2019-06-03 11:03:15.0 -0400
+++ python-acora-2.2/debian/rules	2019-12-22 23:03:23.0 -0500
@@ -10,4 +10,4 @@
 	dh_auto_test
 
 %:
-	dh $@  --with python2,python3 --buildsystem=pybuild
+	dh $@  --with python3 --buildsystem=pybuild

Bug#938016: python-pefile: diff for NMU version 2019.4.18-1.1

Control: tags 938016 + patch


Dear maintainer,

I've prepared an NMU for python-pefile (versioned as 2019.4.18-1.1). The diff
is attached to this message.

Regards.

diff -Nru python-pefile-2019.4.18/debian/changelog python-pefile-2019.4.18/debian/changelog
--- python-pefile-2019.4.18/debian/changelog	2019-04-20 06:03:33.0 -0400
+++ python-pefile-2019.4.18/debian/changelog	2019-12-22 22:40:14.0 -0500
@@ -1,3 +1,10 @@
+python-pefile (2019.4.18-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938016
+
+ -- Sandro Tosi   Sun, 22 Dec 2019 22:40:14 -0500
+
 python-pefile (2019.4.18-1) unstable; urgency=medium
 
   * New upstream version 2019.4.18
diff -Nru python-pefile-2019.4.18/debian/control python-pefile-2019.4.18/debian/control
--- python-pefile-2019.4.18/debian/control	2019-04-20 06:03:24.0 -0400
+++ python-pefile-2019.4.18/debian/control	2019-12-22 22:39:49.0 -0500
@@ -3,41 +3,14 @@
 Priority: optional
 Maintainer: Hilko Bengen 
 Build-Depends: debhelper (>= 12~), dh-python,
- python, python3,
- python-future, python3-future,
+ python3,
+ python3-future,
  python3-setuptools,
 Standards-Version: 4.3.0
 Homepage: https://github.com/erocarrera/pefile/
 Vcs-Git: https://salsa.debian.org/debian/python-pefile.git
 Vcs-Browser: https://salsa.debian.org/debian/python-pefile
 
-Package: python-pefile
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}, python-future,
-Description: Portable Executable (PE) parsing module for Python
- pefile is a Python module to read and work with Portable Executable (PE)
- files. Most of the information in the PE header is accessible, as well as all
- the sections, section information and data.
- .
- All the basic PE file structures are available with their default names as
- attributes of the returned instance.
- .
- Processed elements such as the import table are made available with lowercase
- names, to differentiate them from the upper case basic structure names.
- .
- pefile has been tested against the limits of valid PE headers; that is,
- Windows malware. Lots of packed malware attempt to abuse the format beyond its
- standard use.
- .
- Some of the tasks that pefile makes possible are:
-  * Modifying and writing back to the PE image
-  * Header inspection
-  * Section analysis
-  * Retrieving data
-  * Warnings for suspicious and malformed values
-  * Packer detection with PEiD signatures
-  * PEiD signature generation
-
 Package: python3-pefile
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}, python3-future,
diff -Nru python-pefile-2019.4.18/debian/python3-pefile.install python-pefile-2019.4.18/debian/python3-pefile.install
--- python-pefile-2019.4.18/debian/python3-pefile.install	2019-04-20 06:00:06.0 -0400
+++ python-pefile-2019.4.18/debian/python3-pefile.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-/usr/lib/python3*
diff -Nru python-pefile-2019.4.18/debian/python-pefile.examples python-pefile-2019.4.18/debian/python-pefile.examples
--- python-pefile-2019.4.18/debian/python-pefile.examples	2019-04-20 06:00:06.0 -0400
+++ python-pefile-2019.4.18/debian/python-pefile.examples	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-debian/pefile-match
diff -Nru python-pefile-2019.4.18/debian/python-pefile.install python-pefile-2019.4.18/debian/python-pefile.install
--- python-pefile-2019.4.18/debian/python-pefile.install	2019-04-20 06:00:06.0 -0400
+++ python-pefile-2019.4.18/debian/python-pefile.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-/usr/lib/python2*
diff -Nru python-pefile-2019.4.18/debian/rules python-pefile-2019.4.18/debian/rules
--- python-pefile-2019.4.18/debian/rules	2019-04-20 06:03:24.0 -0400
+++ python-pefile-2019.4.18/debian/rules	2019-12-22 22:40:02.0 -0500
@@ -2,7 +2,7 @@
 #export DH_VERBOSE=1
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_test:

Bug#886568: exabgp is not able to create its command pipe

2019-12-22 Thread Marco d'Itri

On Jan 07, Alfredo Sola  wrote:

> exabgp does not create its pipeby default. These commands need to be 
> run as root before exabgp can start correctly:
Adding this to exabgp.service will take care of it.
I also added some hardening.
AmbientCapabilities and CapabilityBoundingSet are not needed unless 
exabgp needs to be listening on port 179.

[Service]
User=exabgp
Group=exabgp
#AmbientCapabilities=CAP_NET_BIND_SERVICE
#CapabilityBoundingSet=CAP_NET_BIND_SERVICE
RuntimeDirectory=exabgp
RuntimeDirectoryMode=0750
ExecStartPre=-/usr/bin/mkfifo /run/exabgp/exabgp.in
ExecStartPre=-/usr/bin/mkfifo /run/exabgp/exabgp.out
ProtectSystem=strict
ProtectHome=yes
PrivateDevices=yes
PrivateTmp=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes
ProtectKernelModules=yes
NoNewPrivileges=yes
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictNamespaces=yes
RestrictRealtime=yes
LockPersonality=yes
MemoryDenyWriteExecute=yes
SystemCallArchitectures=native
SystemCallErrorNumber=EPERM
SystemCallFilter=@system-service

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#937838: python-intervaltree-bio: diff for NMU version 1.0.1-3.1

Control: tags 937838 + patch


Dear maintainer,

I've prepared an NMU for python-intervaltree-bio (versioned as 1.0.1-3.1). The 
diff
is attached to this message.

Regards.

diff -Nru python-intervaltree-bio-1.0.1/debian/changelog python-intervaltree-bio-1.0.1/debian/changelog
--- python-intervaltree-bio-1.0.1/debian/changelog	2019-01-26 18:10:54.0 -0500
+++ python-intervaltree-bio-1.0.1/debian/changelog	2019-12-22 22:35:33.0 -0500
@@ -1,3 +1,10 @@
+python-intervaltree-bio (1.0.1-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937838
+
+ -- Sandro Tosi   Sun, 22 Dec 2019 22:35:33 -0500
+
 python-intervaltree-bio (1.0.1-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru python-intervaltree-bio-1.0.1/debian/control python-intervaltree-bio-1.0.1/debian/control
--- python-intervaltree-bio-1.0.1/debian/control	2019-01-26 18:10:54.0 -0500
+++ python-intervaltree-bio-1.0.1/debian/control	2019-12-22 22:34:57.0 -0500
@@ -5,30 +5,16 @@
 Priority: optional
 Build-Depends: debhelper (>= 12~),
dh-python,
-   python-all,
-   python-setuptools,
-   python-intervaltree,
python3-all,
python3-setuptools,
python3-intervaltree,
 # Test-Depends:
-   python-pytest,
python3-pytest
 Standards-Version: 4.3.0
 Vcs-Browser: https://salsa.debian.org/med-team/python-intervaltree-bio
 Vcs-Git: https://salsa.debian.org/med-team/python-intervaltree-bio.git
 Homepage: https://github.com/konstantint/intervaltree-bio
 
-Package: python-intervaltree-bio
-Architecture: all
-Depends: ${misc:Depends},
- ${python:Depends}
-Description: Interval tree convenience classes for genomic data -- Python 2 library
- Convenience classes for loading UCSC genomic annotation records into
- a set of interval tree data structures.
- .
- This package provides the Python 2 library.
-
 Package: python3-intervaltree-bio
 Architecture: all
 Depends: ${misc:Depends},
diff -Nru python-intervaltree-bio-1.0.1/debian/rules python-intervaltree-bio-1.0.1/debian/rules
--- python-intervaltree-bio-1.0.1/debian/rules	2019-01-26 18:10:54.0 -0500
+++ python-intervaltree-bio-1.0.1/debian/rules	2019-12-22 22:35:05.0 -0500
@@ -8,7 +8,7 @@
 export PYBUILD_NAME=intervaltree-bio
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
diff -Nru python-intervaltree-bio-1.0.1/debian/tests/control python-intervaltree-bio-1.0.1/debian/tests/control
--- python-intervaltree-bio-1.0.1/debian/tests/control	2019-01-26 18:10:54.0 -0500
+++ python-intervaltree-bio-1.0.1/debian/tests/control	2019-12-22 22:35:29.0 -0500
@@ -1,11 +1,4 @@
 Test-Command:
-	python2 -m pytest --verbose --datadir debian/data
-Depends:
-	python-intervaltree-bio,
-	python-pytest
-Restrictions: rw-build-tree
-
-Test-Command:
 	python3 -m pytest --verbose --datadir debian/data
 Depends:
 	python3-intervaltree-bio,

Bug#947221: RM: bibus -- ROM; Python 2-only, dead upstream

2019-12-22 Thread Stuart Prescott

Package: ftp.debian.org
Severity: normal

bibus has no Python 2 support and it is dead upstream. There seems to be
little prospect of this package being ported to Python 3.

thanks
Stuart

Bug#937837: python-intervaltree: diff for NMU version 3.0.2-1.1

Control: tags 937837 + patch


Dear maintainer,

I've prepared an NMU for python-intervaltree (versioned as 3.0.2-1.1). The diff
is attached to this message.

Regards.

diff -Nru python-intervaltree-3.0.2/debian/changelog python-intervaltree-3.0.2/debian/changelog
--- python-intervaltree-3.0.2/debian/changelog	2019-01-22 13:08:49.0 -0500
+++ python-intervaltree-3.0.2/debian/changelog	2019-12-22 22:30:31.0 -0500
@@ -1,3 +1,10 @@
+python-intervaltree (3.0.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937837
+
+ -- Sandro Tosi   Sun, 22 Dec 2019 22:30:31 -0500
+
 python-intervaltree (3.0.2-1) unstable; urgency=medium
 
   * New upstream version 3.0.2
diff -Nru python-intervaltree-3.0.2/debian/control python-intervaltree-3.0.2/debian/control
--- python-intervaltree-3.0.2/debian/control	2019-01-22 13:07:34.0 -0500
+++ python-intervaltree-3.0.2/debian/control	2019-12-22 22:30:17.0 -0500
@@ -3,31 +3,15 @@
 Priority: optional
 Maintainer: Hilko Bengen 
 Build-Depends: debhelper (>= 12), dh-python,
- python-all (>= 2.6.6-3~),python3-all,
- python-setuptools, python3-setuptools,
- python-sortedcontainers, python3-sortedcontainers,
- python-pytest, python3-pytest,
+ python3-all,
+ python3-setuptools,
+ python3-sortedcontainers,
+ python3-pytest,
 Standards-Version: 4.3.0
 Homepage: https://pypi.python.org/pypi/intervaltree
-X-Python-Version: >= 2.6
-X-Python3-Version: >= 3.2
 Vcs-Git: https://salsa.debian.org/debian/python-intervaltree.git
 Vcs-Browser: https://salsa.debian.org/debian/python-intervaltree
 
-Package: python-intervaltree
-Architecture: all
-Multi-Arch: foreign
-Depends: ${python:Depends}, ${misc:Depends}
-Description: mutable, self-balancing interval tree (Python 2)
- This library contains a mutable, self-balancing interval tree
- implementation for Python. Queries may be by point, by range overlap,
- or by range envelopment.
- .
- It was designed to allow tagging text and time intervals, where the
- intervals include the lower bound but not the upper bound.
- .
- This package installs the library for Python 2.
-
 Package: python3-intervaltree
 Architecture: all
 Multi-Arch: foreign
diff -Nru python-intervaltree-3.0.2/debian/python-intervaltree.docs python-intervaltree-3.0.2/debian/python-intervaltree.docs
--- python-intervaltree-3.0.2/debian/python-intervaltree.docs	2019-01-22 13:03:25.0 -0500
+++ python-intervaltree-3.0.2/debian/python-intervaltree.docs	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-README.*
\ No newline at end of file
diff -Nru python-intervaltree-3.0.2/debian/rules python-intervaltree-3.0.2/debian/rules
--- python-intervaltree-3.0.2/debian/rules	2019-01-22 13:03:25.0 -0500
+++ python-intervaltree-3.0.2/debian/rules	2019-12-22 22:30:25.0 -0500
@@ -3,5 +3,5 @@
 export PYBUILD_NAME=intervaltree
 
 %:
-	dh $@  --with python2,python3 --buildsystem=pybuild
+	dh $@  --with python3 --buildsystem=pybuild

Bug#936401: dirspec: diff for NMU version 13.10-1.1

Control: tags 936401 + patch
Control: tags 942974 + patch


Dear maintainer,

I've prepared an NMU for dirspec (versioned as 13.10-1.1). The diff
is attached to this message.

Regards.

diff -Nru dirspec-13.10/debian/changelog dirspec-13.10/debian/changelog
--- dirspec-13.10/debian/changelog	2015-09-20 17:50:02.0 -0400
+++ dirspec-13.10/debian/changelog	2019-12-22 22:26:02.0 -0500
@@ -1,3 +1,10 @@
+dirspec (13.10-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #942974, #936401
+
+ -- Sandro Tosi   Sun, 22 Dec 2019 22:26:02 -0500
+
 dirspec (13.10-1) unstable; urgency=medium
 
   * Sync version number with ubuntu (no changes)
diff -Nru dirspec-13.10/debian/control dirspec-13.10/debian/control
--- dirspec-13.10/debian/control	2015-09-20 17:49:41.0 -0400
+++ dirspec-13.10/debian/control	2019-12-22 22:26:00.0 -0500
@@ -5,28 +5,12 @@
  dh-python,
  debhelper (>= 7.0.50),
  pep8,
- pyflakes,
- python,
- python-all (>= 2.6.6-3),
- python-setuptools,
- python-testtools,
+ pyflakes3,
  python3-all,
  python3-setuptools,
  python3-testtools
 Maintainer: Micah Anderson 
 Standards-Version: 3.9.4
-X-Python-Version: >= 2.6
-X-Python3-Version: >= 3.1
-
-Package: python-dirspec
-Architecture: all
-Depends: ${misc:Depends},
- ${python:Depends}
-Description: Python User Folders Specification Library
- A library for handling the XDG Base Directory specification, and the
- XDG User Directories for music, videos, etc…
- .
- This package contains the Python 2.x version of the library.
 
 Package: python3-dirspec
 Architecture: all
diff -Nru dirspec-13.10/debian/patches/py3k-tests.patch dirspec-13.10/debian/patches/py3k-tests.patch
--- dirspec-13.10/debian/patches/py3k-tests.patch	1969-12-31 19:00:00.0 -0500
+++ dirspec-13.10/debian/patches/py3k-tests.patch	2019-12-22 22:24:24.0 -0500
@@ -0,0 +1,20 @@
+--- a/run-tests
 b/run-tests
+@@ -16,9 +16,6 @@
+ 
+ set -e -x
+ 
+-# Run the tests
+-python ./setup.py build test clean
+-
+ # Only run the python3 tests if available
+ if [ -x "`which python3`" ]; then
+ python3 ./setup.py build test clean
+@@ -27,6 +24,6 @@ else
+ fi
+ 
+ # Run the style checks
+-pyflakes dirspec setup.py
++pyflakes3 dirspec setup.py
+ pep8 --exclude=.pc --repeat . setup.py
+ 
diff -Nru dirspec-13.10/debian/patches/series dirspec-13.10/debian/patches/series
--- dirspec-13.10/debian/patches/series	2015-09-20 17:33:20.0 -0400
+++ dirspec-13.10/debian/patches/series	2019-12-22 22:23:45.0 -0500
@@ -1,3 +1,4 @@
 pep8_problems
 00_ignore_pc.patch
 fix_PEP8-E128
+py3k-tests.patch
diff -Nru dirspec-13.10/debian/python3-dirspec.install dirspec-13.10/debian/python3-dirspec.install
--- dirspec-13.10/debian/python3-dirspec.install	2013-03-26 14:02:56.0 -0400
+++ dirspec-13.10/debian/python3-dirspec.install	1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-usr/lib/python3*/*-packages/*
-
diff -Nru dirspec-13.10/debian/python-dirspec.install dirspec-13.10/debian/python-dirspec.install
--- dirspec-13.10/debian/python-dirspec.install	2013-03-26 14:02:56.0 -0400
+++ dirspec-13.10/debian/python-dirspec.install	1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-usr/lib/python2*/*-packages/*
-
diff -Nru dirspec-13.10/debian/rules dirspec-13.10/debian/rules
--- dirspec-13.10/debian/rules	2013-03-26 14:02:56.0 -0400
+++ dirspec-13.10/debian/rules	2019-12-22 22:23:02.0 -0500
@@ -1,26 +1,13 @@
 #!/usr/bin/make -f
 
-PYTHON2=$(shell pyversions -vr)
 PYTHON3=$(shell py3versions -vr)
 
 %:
-	dh $@ --with python2,python3 --fail-missing
+	dh $@ --with python3 --fail-missing --buildsystem=pybuild
 
 override_dh_auto_test:
 	./run-tests
 
-build-python%:
-	python$* setup.py build
-
-override_dh_auto_build: $(PYTHON3:%=build-python%)
-	dh_auto_build
-
-install-python%:
-	python$* setup.py install --root=$(CURDIR)/debian/tmp --install-layout=deb
-
-override_dh_auto_install: $(PYTHON3:%=install-python%)
-	dh_auto_install
-
 override_dh_auto_clean:
 	dh_auto_clean
 	rm -rf build

Bug#947220: lvm2: System unbootable with cached root and latest kernel

2019-12-22 Thread Stefanos Harhalakis

Package: lvm2
Version: 2.03.02-3
Severity: critical
Justification: breaks the whole system

The system with the latest kernel from testing and the latest lvm2 is 
unbootable when the root filesystem is a cached lvm volume.

During boot, it says:
device-mapper: table: 253:3: cache: Error creating cache's policy
device-mapper: reload ioctl on (253:3) failed: Invalid argument
/sbin/modprobe failed: 1
/sbin/modprobe failed: 1

This repeats a couple of times and it drops to the initramfs shell. From there, 
it's possible to boot by removing the cache:

lvm lvchange --splitcache vg/root

Then boot and reattach:

lvconvert --type cache --cachepool root-cache vg/root

I've seen #862136 but I'm not sure if it's the same (haven't tested). I tested 
all three policies (smq, mq, cleaner) during the troubleshoting and none worked.

Another potential cause is this error that lvs throws after booting:

Unknown feature in status: 8 171/2048 128 1897/81920 235 840 562 2581 0 1897 0 
3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 smq 0 
rw -
Unknown feature in status: 8 337/3072 128 7578/163840 23719 28981 8025 4909 0 
7578 0 3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 
smq 0 rw -
Unknown feature in status: 8 341/3072 128 7018/163840 3369 32447 96 77 0 7018 0 
3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 smq 0 
rw -
Unknown feature in status: 8 341/3072 128 7018/163840 3369 32447 96 77 0 7018 0 
3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 smq 0 
rw -
Unknown feature in status: 8 337/3072 128 7578/163840 23719 28981 8025 4909 0 
7578 0 3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 
smq 0 rw -
Unknown feature in status: 8 171/2048 128 1897/81920 235 840 562 2581 0 1897 0 
3 metadata2 writethrough no_discard_passdown 2 migration_threshold 2048 smq 0 
rw -

(I have 3 cached partitions, it's 2 lines per partition)

which sounds like there is something that lvm doesn't understand at boot (?)

Note: the system was bootable with a much earlier kernel (4.19.0-4), probably 
with an older version of lvm2. I haven't tested falling back to that.

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

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

Versions of packages lvm2 depends on:
ii  dmeventd  2:1.02.155-3
ii  dmsetup   2:1.02.155-3
ii  libaio1   0.3.112-5
ii  libblkid1 2.34-0.1
ii  libc6 2.29-2
ii  libdevmapper-event1.02.1  2:1.02.155-3
ii  libdevmapper1.02.12:1.02.155-3
ii  libreadline5  5.2+dfsg-3+b13
ii  libselinux1   2.9-2+b2
ii  libsystemd0   242-7
ii  libudev1  242-7
ii  lsb-base  11.1.0

Versions of packages lvm2 recommends:
ii  thin-provisioning-tools  0.7.6-2.1

lvm2 suggests no packages.

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

-- debconf-show failed

Bug#937660: python-configshell-fb: diff for NMU version 1.1.fb25-1.1

Control: tags 937660 + patch


Dear maintainer,

I've prepared an NMU for python-configshell-fb (versioned as 1.1.fb25-1.1). The 
diff
is attached to this message.

Regards.

diff -Nru python-configshell-fb-1.1.fb25/debian/changelog python-configshell-fb-1.1.fb25/debian/changelog
--- python-configshell-fb-1.1.fb25/debian/changelog	2019-08-02 08:19:14.0 -0400
+++ python-configshell-fb-1.1.fb25/debian/changelog	2019-12-22 22:07:08.0 -0500
@@ -1,3 +1,10 @@
+python-configshell-fb (1.1.fb25-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937660
+
+ -- Sandro Tosi   Sun, 22 Dec 2019 22:07:08 -0500
+
 python-configshell-fb (1.1.fb25-1) unstable; urgency=medium
 
   * New upstream version 1.1.fb25
diff -Nru python-configshell-fb-1.1.fb25/debian/control python-configshell-fb-1.1.fb25/debian/control
--- python-configshell-fb-1.1.fb25/debian/control	2019-08-02 08:19:14.0 -0400
+++ python-configshell-fb-1.1.fb25/debian/control	2019-12-22 22:06:36.0 -0500
@@ -7,10 +7,6 @@
Christian Seiler 
 Build-Depends: debhelper (>= 11~),
dh-python,
-   python-all,
-   python-pyparsing,
-   python-setuptools,
-   python-six,
python3-all,
python3-pyparsing,
python3-setuptools,
@@ -20,29 +16,6 @@
 Vcs-Git: https://salsa.debian.org/linux-blocks-team/python-configshell-fb.git
 Vcs-Browser: https://salsa.debian.org/linux-blocks-team/python-configshell-fb
 
-Package: python-configshell-fb
-Architecture: all
-Depends: ${misc:Depends},
- ${python:Depends},
- python-pyparsing,
- python-six,
- python-urwid,
-Conflicts: python-configshell
-Breaks: python-configshell-fb-doc (<= 1.1.24-1~)
-Replaces: python-configshell-fb-doc (<= 1.1.24-1~)
-Description: Python library for building configuration shells - Python 2
- The configshell-fb package is a Python library that provides a
- framework for building simple but nice CLI-based applications.
- .
- The configshell-fb package is a fork of the "configshell" code
- written by RisingTide Systems. The "-fb" differentiates between the
- original and this version. Please ensure to use either all "fb"
- versions of the targetcli components -- targetcli, rtslib, and
- configshell, or stick with all non-fb versions, since they are no
- longer strictly compatible.
- .
- This package contains the Python 2 module.
-
 Package: python3-configshell-fb
 Architecture: all
 Depends: ${misc:Depends},
diff -Nru python-configshell-fb-1.1.fb25/debian/python3-configshell-fb.install python-configshell-fb-1.1.fb25/debian/python3-configshell-fb.install
--- python-configshell-fb-1.1.fb25/debian/python3-configshell-fb.install	2019-08-01 04:36:56.0 -0400
+++ python-configshell-fb-1.1.fb25/debian/python3-configshell-fb.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python3*
diff -Nru python-configshell-fb-1.1.fb25/debian/python-configshell-fb.install python-configshell-fb-1.1.fb25/debian/python-configshell-fb.install
--- python-configshell-fb-1.1.fb25/debian/python-configshell-fb.install	2019-08-01 04:36:56.0 -0400
+++ python-configshell-fb-1.1.fb25/debian/python-configshell-fb.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python2*
diff -Nru python-configshell-fb-1.1.fb25/debian/rules python-configshell-fb-1.1.fb25/debian/rules
--- python-configshell-fb-1.1.fb25/debian/rules	2019-08-02 08:01:49.0 -0400
+++ python-configshell-fb-1.1.fb25/debian/rules	2019-12-22 22:07:04.0 -0500
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with python3,python2 -Spybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_clean:
 	dh_auto_clean

Bug#946951: can't start wine: chdir to /run/user/1000/wine/server-805-14c0be6 : No such file or directory

2019-12-22 Thread Jeff Smith

BACKGROUND:
Debian's wine build applies temporary-directory.patch which modifies
libwine to change the location of wineserver's temp dir.

WHAT CHANGED:
With wine commit fe13f7a3b0d0ad709676aa046cb4c9da260900cf
create_server_dir() quit depending on wine_get_server_dir() from
libwine.  This was a part of making the wine server no longer depend
on libwine.

TO FIX:
Debian's temporary-directory.patch will need to be updated to also
make changes to create_server_dir() in server/request.c so that the
directory matches that for init_server_dir() in libs/wine/config.c

Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

2019-12-22 Thread Ximin Luo

Control: reassign -1 reprepro 5.3.0-1
Control: retitle -1 reprepro imposes arbitrary limits on control files that are 
successfully parsed by other debian tools

Ximin Luo:
> [..]
> I'll take a look at reprepro in the next 2-3 weeks; arbitrary limits like 
> 256K should be pretty easy to fix (have you tried simply configuring the BDB 
> limits?).

The relevant code in reprepro is indexfile.c

line 66:f->size = 256*1024;

Change this to something like 4MB would be a short hacky fix to the current 
issue, I don't think even the extreme rust examples have a 4MB control field 
yet.

A long-term fix would be to fix this:

line 151-166:
if (f->size - f->ofs <= 2048) {
/* Adding code to enlarge the buffer in this case
 * is risky as hard to test properly.
 *
 * Also it is almost certainly caused by some
 * mis-representation of the file or perhaps
 * some attack. Requesting all existing memory in
 * those cases does not sound very useful. */

fprintf(stderr,
"Error parsing %s line %d: Ridiculous long (>= 256K) control chunk!\n",
f->filename,
f->startlinenumber);
f->failed = true;
return RET_ERROR;
}

One reasonable option would be to rip out this code and use whatever dpkg 
itself is using to parse the fields.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#936924: Moving libsvm to Debian Science team

2019-12-22 Thread Chen-Tse Tsai

Hi Christian, All,

I'm working on an update which removes dependency on cdbs and python2. I'm
using liblinear package as the reference. I'll send you something for
review some time this week.

Thanks,
Chen-Tse


On Sat, Dec 21, 2019 at 4:26 PM Christian Kastner  wrote:

> Hi all,
>
> Regarding liblinear: I thought I already set the Maintainer to Debian
> Science Team, I guess I missed it.
>
> On 2019-12-21 20:11, Chen-Tse Tsai wrote:
> > I've created an account on Salsa.
> >
> > Do you think we should remove cdbs and use another build system
> > instead? Please let me know if you have any suggestion. I'm not
> > familiar with other build systems.
>
> Yep, the Debian Policy was updated and recommends dh now.
>
> @Andreas: Chen-Tse and I discussed upgrading the package in October (I
> think), but both did not have the time back then.
>
> I could also help with some work starting on the 27th or so. As
> src:liblinear and src:libsvm have the same upstream, they are quite
> similar WRT to building, so src:liblinear (which is up to date) might
> have some helpful ideas.
>
> Given that the last libsvm update was a while ago, I wouldn't be
> surprised if a transition were necessary.
>

Bug#941947: marked as done (RFS: misspell-fixer/0.1-1 [ITP] -- Tool for fixing common misspellings, typos in source code)

2019-12-22 Thread Paul Wise

> From: Adam Borowski 

> While I agree with remarks about proliferation of similar tools, it is not a
> reason to stop new development.  As your tool can fix the problems, it's
> interesting.

FYI codespell can also fix problems using the -w option.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#947219: RM: zhpy -- RoQA; Dead Upstream; Affected by Python2 Removal

2019-12-22 Thread Boyuan Yang

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: dreamerwolf...@gmail.com

Dear FTP Masters,

According to https://bugs.debian.org/93 and https://bugs.debian.org/945979
  , package zhpy has a dead upstream and no activity from package maintainer
(no maintainer upload for 9 years) in Debian. Since this package is now
affected by Python2 removal, please consider removing it from the archive.

-- 
Best,
Boyuan Yang


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

Bug#842896: minicom: diff for NMU version 2.7.1-1.1

2019-12-22 Thread Boyuan Yang

Control: tags -1 + patch  pending

Dear maintainer,

I've prepared an NMU for minicom (versioned as 2.7.1-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru minicom-2.7.1/debian/changelog minicom-2.7.1/debian/changelog
--- minicom-2.7.1/debian/changelog  2017-08-13 11:25:34.0 -0400
+++ minicom-2.7.1/debian/changelog  2019-12-22 21:06:26.0 -0500
@@ -1,3 +1,16 @@
+minicom (2.7.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control:
++ Update project homepage on salsa.debian.org. (Closes: #900092)
++ Add missing build-dependency debhelper (with compat level
+  of 12).
+  * debian/rules:
++ Use buildflags.mk and buildtools.mk to properly set CFLAGS
+  and $(STRIP). This fixes FTCBFS. (Closes: #842896)
+
+ -- Boyuan Yang   Sun, 22 Dec 2019 21:06:26 -0500
+
 minicom (2.7.1-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru minicom-2.7.1/debian/control minicom-2.7.1/debian/control
--- minicom-2.7.1/debian/control2017-08-13 11:17:46.0 -0400
+++ minicom-2.7.1/debian/control2019-12-22 20:57:08.0 -0500
@@ -3,9 +3,9 @@
 Priority: optional
 Maintainer: Martin A. Godisch 
 Uploaders: Jordi Mallach 
-Build-Depends: autotools-dev, gettext, libncurses5-dev
+Build-Depends: debhelper-compat (= 12), gettext, libncurses5-dev
 Standards-Version: 4.0.1
-Homepage: https://alioth.debian.org/projects/minicom/
+Homepage: https://salsa.debian.org/minicom-team/minicom
 
 Package: minicom
 Architecture: any
diff -Nru minicom-2.7.1/debian/rules minicom-2.7.1/debian/rules
--- minicom-2.7.1/debian/rules  2017-08-13 11:25:34.0 -0400
+++ minicom-2.7.1/debian/rules  2019-12-22 21:06:24.0 -0500
@@ -2,6 +2,12 @@
 #
 # $Id: rules,v 1.15.2.5 2005/11/05 12:01:25 godisch Exp $
 
+DPKG_EXPORT_BUILDFLAGS = 1
+DPKG_EXPORT_BUILDTOOLS = 1
+include /usr/share/dpkg/default.mk
+include /usr/share/dpkg/buildflags.mk
+include /usr/share/dpkg/buildtools.mk
+
 BUILDDIR = debian/minicom
 DEBDIR   = $(BUILDDIR)/DEBIAN
 DOCDIR   = $(BUILDDIR)/usr/share/doc/minicom
@@ -15,14 +21,6 @@
CONFFLAGS += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
 endif
 
-CFLAGS = -Wall -g
-ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
-   CFLAGS += -O0
-else
-   CFLAGS += -O2
-endif
-export CFLAGS
-
 clean:
$(testdir)
rm -f configure-stamp build-stamp
@@ -61,7 +59,7 @@
$(MAKE) DESTDIR=$(CURDIR)/debian/minicom install
chmod -R go=u-w $(BUILDDIR)
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-   cd $(BUILDDIR)/usr/bin && strip -R .comment -R .note ascii-xfr minicom
runscript
+   cd $(BUILDDIR)/usr/bin && $(STRIP) -R .comment -R .note ascii-xfr
minicom runscript
 endif
install -p -D -m 0644 debian/desktop
$(BUILDDIR)/usr/share/applications/minicom.desktop
find $(BUILDDIR)/usr/share/man -type f -print0 | xargs -0 gzip -9


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

Bug#947178: RFS: dmidecode/3.2-3 -- SMBIOS/DMI table decoder

2019-12-22 Thread Paul Wise

On Sun, Dec 22, 2019 at 7:42 PM Jörg Frings-Fürst wrote:

> I use now /usr/sbin/dmidecode -V. Uploaded to mentors and into git.

Things like that should be marked as trivial autopkgtests:

https://lists.debian.org/msgid-search/8b000c23ac2defbfeea7d5a0bc28ec2e3df55baa.ca...@debian.org

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#947218: O: coco-doc -- Documentation for the Coco/R Compiler Generator

2019-12-22 Thread Boyuan Yang

Package: wnpp

The original maintainer of package coco-doc is apparently not active
anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills.  Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.  If you are still uncertain
about how to adopt the package, please feel free to let me know or seek help
from other Debian Developers.

Some information about this package:

Package: coco-doc
Binary: coco-doc
Version: 20060919.0-1
Maintainer: Debian QA Group 
Build-Depends: debhelper-compat (= 12)
Architecture: all
Standards-Version: 4.4.1
Format: 3.0 (quilt)
Files:
 2ad5d1004838641b6fc50b7a32c0341d 1851 coco-doc_20060919.0-1.dsc
 c89e3c463058f02e86c5bdca3a45bca6 697324 coco-doc_20060919.0.orig.tar.gz
 e6f5d4997a17761db45c732b9312d8b5 2504 coco-doc_20060919.0-1.debian.tar.xz
Vcs-Browser: https://salsa.debian.org/debian/coco-doc
Vcs-Git: https://salsa.debian.org/debian/coco-doc.git
Checksums-Sha256:
 827a7bd197fed9a0de7df83fc4fbd85fc78455cd2d0864be3b219628afd91aa1 1851 coco-
doc_20060919.0-1.dsc
 be98dedb29757bd37ae6b21b08499a55c233a7ed90511b1c5811c4b7f68fba98 697324 coco-
doc_20060919.0.orig.tar.gz
 9591e4d383ae14d5c0ded861a45db69a9486eb296da37a4c985f922211578a3f 2504 coco-
doc_20060919.0-1.debian.tar.xz
Homepage: http://ssw.jku.at/Coco/
Package-List: 
 coco-doc deb doc optional arch=all
Directory: pool/main/c/coco-doc
Priority: source
Section: doc

Package: coco-doc
Version: 20060919.0-1
Priority: optional
Section: doc
Maintainer: Debian QA Group 
Installed-Size: 774 kB
Homepage: http://ssw.jku.at/Coco/
Tag: devel::code-generator, devel::doc, devel::lang:java, made-of::pdf,
 role::documentation
Download-Size: 696 kB
APT-Sources: http://deb.debian.org/debian unstable/main amd64 Packages
Description: Documentation for the Coco/R Compiler Generator
 Coco/R is a compiler generator, which takes an attributed grammar of a source
 language and generates a scanner and a parser for this language. The scanner
 works as a deterministic finite automaton. The parser uses recursive descent.
 LL(1) conflicts can be resolved by a multi-symbol lookahead or by semantic
 checks. Thus the class of accepted grammars is LL(k) for an arbitrary k.
 .
 See /usr/share/doc/cocosourcesdoc.


-- 
Regards,
Boyuan Yang


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

Bug#947105: [Pkg-puppet-devel] Bug#947105: puppet: Default install uses outdated configuration file and directory locations

2019-12-22 Thread Todd H. Poole

Hi Louis-Philippe, Thomas,

Appreciate your responses. Feel free to adjust the severity. The reportbug
docs[1] defined "important" as "a bug which has a major effect on the
usability of a package, without rendering it completely unusable" so that's
just what I went with.

As for usability, given that all of Debian's man pages, all of PuppetLab's
(fairly thorough) online docs, and all of the top internet search results
and StackOverflow posts relevant to Puppet 5.x assume/use the post-2015
config file and directory locations, it seemed reasonable to say this had
"a major effect on usability". Puppet is sufficiently complex that
referring to these external resources feels pretty common, so if those
external resources don't accurately capture Debian's differences, usability
suffers.

As for /etc/puppetlabs/puppet being longer to type than /etc/puppet/, I
agree with you in principle, but in practice, the vast majority of users
have shells that support path completion which reduces the difference down
to one or two extra key strokes (/e[TAB]pu[TAB] vs. /e[TAB]pu[TAB]p[TAB]).
The hundreds of milliseconds consumed by those extra keystrokes are surely
dwarfed by the tens of minutes those same users might spend searching for
and reading through docs which are all going to be consistent with
themselves and other platforms, but silently inconsistent with Debian's
packages.

As for /etc/puppet being clearer than /etc/puppetlabs/puppet - eh, they
both seem equally clear to me. I can't imagine many people wondering what
software might be inside /etc/puppetlabs.

As for abnormal vendor advertising, I'm not sure I see it like that. It
honestly just strikes me as a choice some engineer was forced to make so as
not to collide with previous installations during the 3.x to 4.x
transition. Doesn't feel like an intentional advertising effort on behalf
of PuppetLabs to me.

As for departing from prior behavior, I'll give you that: that's why there
was so much messaging around the 4.x release and such a strong up-tick in
the quality of the upstream docs around that time. If you were to change
this now, I'd absolutely advocate doing so as part of your Puppet 6.x
release.

At the end of the day, it's your guys' call, but being consistent with a
universe of supporting documentation built up (and continuing to build up)
from years of StackOverflow posts, years of blog posts, years of forum
posts, years of search engine results, and reams of man pages and upstream
docs would seem to me to be far more valuable than preserving behavior that
changed in early 2015.

[1]https://www.debian.org/Bugs/Developer#severities

Something to think about,
Todd

Bug#947064: fourier: problem with font lookup

2019-12-22 Thread Norbert Preining

Hi Michel,

Norbert from the TeX Live project here.

Thanks for your work on the Fourier fonts. I would like to report a
problem that appears with the current setup: The file
fourier-orns.sty
uses fontconfig lookup to find the fonts:
\newfontfamily\FourierOrns{FourierOrns}
which means that the font is only searched via fontconfig and **not**
via kpathsea.

But on most systems, the fonts in the various TeX directories are
**not** searched for system fonts and they need to be activated
manually.

I think it would be better to search the fonts via kpathsea/filename
lookup, by changing the above line to

  \newfontfamily\FourierOrns{FourierOrns-Regular.otf}[
BoldFont   = FourierOrns-Bold.otf ,
ItalicFont = FourierOrns-Italic.otf ,
BoldItalicFont = FourierOrns-BoldItalic.otf ]

Thanks a lot for considering

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#947217: shorewall: man page shorewall-masq(5) seems to be missing

2019-12-22 Thread Roberto C. Sanchez

Package: shorewall
Version: 5.2.3.2-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The man page shorewall-masq(5) seems to be missing.  It should be
included in the shorewall package.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEIYZ1DR4ae5UL01q7ldFmTdL1kUIFAl4ACbkACgkQldFmTdL1
kUI+dA//eTPS2WA78HqHpphoW8v6NCzlXyprLzelgUToQYFyAuC9LftXjWabCCsC
35Ui3iwti8SJr0WrNA5JWLe0GT3N+eogXMAJ01QwrXQ6A3g5Cr0wogT8u/69/K/C
RqFMhgPNrN5axfoKgn2MBbLGXlyzkQQ3WSgV+Pkw6p3K+ttEGTQ0jZAK6TbsTf3X
hOkIY0mJ62HjFKifXxQ+5gyoPz7HFTb4HBf3w5i1vzGIxJPov/xKpFvtV6oyjlfK
4NlNsi8EQSfLANM5nmTkYhKBqBARkWD8ETrKHsRUTUDpaL64nAqV/vW8tqRivKVf
EGuMRqJHfBX868f9EIqP2TBsO/x1cmncw2pMiTRRjvz9O970G+IuAL9fFmxAoC8F
WL4o9DOutXoKiYMiCxsrNeI0BIq7TRHuHTCtjxSEDu99808ZgFV0E32j1RJVuY4D
ilPlnvZck/nOChFJ1bTV6WBoL6N33GL7SaAwZUIYi045ZOUbH0nkjCeDlBNkBKw5
lsSbq2LVTdPVdBWh5AwPXdVlTfDUiSt8iI7X7KRCfTqBv2jWSqw0lhvfVWVO0V/J
xsYnD5/OovbcZs6QT3ZqiMvrIgEXdfMwvsCaCMJ4OsUvFkFEUkPkML+AvlmblfZa
WwIlC+TYDn4otsqA49d4YBEEG/cA02VMTxc4DVfzdQmUnHYNp68=
=S7OF
-END PGP SIGNATURE-

Bug#947064: texlive-fonts-extra: fourier-orns.sty broken, docs using the Fourier font no longer compile

2019-12-22 Thread Norbert Preining

Hi,

> ! I can't find file `FourierOrns'.

Indeed, looking into the fourier-orns.sty I see
\newfontfamily\FourierOrns{FourierOrns}
which means that the font is only searched via fontconfig and **not**
via kpathsea.

There are two ways to solve this:

Search the font via filename

You need to edit fourier-orns.sty (copy it to the current working
directory) and change the above line to read like

  \newfontfamily\FourierOrns{FourierOrns-Regular.otf}[
BoldFont   = FourierOrns-Bold.otf ,
ItalicFont = FourierOrns-Italic.otf ,
BoldItalicFont = FourierOrns-BoldItalic.otf ]

After that the files and thus the font will be found.

Make the fonts available to fontconfig
--

By adding an entry to 
/etc/fonts/local.conf
for the respective directory, the fonts are made available to
fontconfig. It works with the following content:




/usr/share/texlive/texmf-dist/fonts/opentype/public/fourier


followed by an `fc-cache -s` as root.

We don't activate all of the fonts automatically since this has broken
fontconfig several times, so we leave activation of fonts to the
discretion of the user/admin.

I will try to report upstream of fourier package that they should try to
locate the fonts via file name instead of font name.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#947216: yapps2: should this package be removed?

Source: yapps2
Severity: serious

Python 2 is end-of-life, and there are no more rdeps for python-yapps2, but
python3-yapps2 seems broken beyond repair: #911753, #911752.

I believe this is a good enough reason to have this package removed from debian.
if i dont hear back within a week with a good reason to keep it, i'll file for
its removal.

Thanks,
Sandro

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

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

Bug#947215: RFS: coinor-csdp/6.2.0-1 [QA] -- A software package for semidefinite programming

2019-12-22 Thread Sudip Mukherjee

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "coinor-csdp"

 * Package name: coinor-csdp
   Version : 6.2.0-1
   Upstream Author : Brian Borchers 
 * URL : https://projects.coin-or.org/Csdp
 * License : CPL-1.0
 * Vcs : https://salsa.debian.org/sudip-guest/csdp.git
   Section : science

It builds those binary packages:

  coinor-csdp - A software package for semidefinite programming
  coinor-csdp-doc - A software package for semidefinite programming
  coinor-csdp-dbg - A software package for semidefinite programming

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

  https://mentors.debian.net/package/coinor-csdp

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/coinor-csdp/coinor-csdp_6.2.0-1.dsc

Changes since the last upload:

   * QA upload.
   * Update to upstream 6.2.0.
   * Update Standards-Version to 4.4.1.
   * Update compat level to 12.
   * Remove dependency on cdbs.
   * Remove Uploader.
   * Modify the patch for Makefile.
   * Push to salsa and update Vcs.

Note:
coinor-csdp-dbg has been kept so that this new version provides all the
packages that the old version provided. Maybe, in the next update,
coinor-csdp-dbg can be dropped in favour of -dbgsym.

-- 
Regards
Sudip

Bug#947214: RFS: trace-cmd/2.8.3-3 -- Utility for retrieving and analyzing function tracing in the kernel

2019-12-22 Thread Sudip Mukherjee

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "trace-cmd"

 * Package name: trace-cmd
   Version : 2.8.3-3
   Upstream Author : Steven Rostedt 
 * URL : http://kernelshark.org/
 * License : GPL-2
 * Vcs : https://github.com/sudipm-mukherjee/trace-cmd.git
   Section : devel

It builds those binary packages:

  trace-cmd - Utility for retrieving and analyzing function tracing in the 
kernel
  kernelshark - Utilities for graphically analyzing function tracing in the 
kernel.

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

  https://mentors.debian.net/package/trace-cmd

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/trace-cmd/trace-cmd_2.8.3-3.dsc

Changes since the last upload:

   * Fix FTCBFS, thanks to Helmut Grohne. (Closes: #946296)


-- 
Regards
Sudip

Bug#936240: broccoli-python: diff for NMU version 0.63-1.1

Control: tags 936240 + patch


Dear maintainer,

I've prepared an NMU for broccoli-python (versioned as 0.63-1.1). The diff
is attached to this message.

Regards.

diff -Nru broccoli-python-0.63/debian/changelog broccoli-python-0.63/debian/changelog
--- broccoli-python-0.63/debian/changelog	2019-02-08 03:08:51.0 -0500
+++ broccoli-python-0.63/debian/changelog	2019-12-22 17:51:56.0 -0500
@@ -1,3 +1,11 @@
+broccoli-python (0.63-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #936240
+  * Compile extension for all supported python3 versions
+
+ -- Sandro Tosi   Sun, 22 Dec 2019 17:51:56 -0500
+
 broccoli-python (0.63-1) unstable; urgency=medium
 
   * New upstream version 0.63
diff -Nru broccoli-python-0.63/debian/control broccoli-python-0.63/debian/control
--- broccoli-python-0.63/debian/control	2019-02-07 12:11:01.0 -0500
+++ broccoli-python-0.63/debian/control	2019-12-22 17:51:54.0 -0500
@@ -4,7 +4,7 @@
 Maintainer: Hilko Bengen 
 Build-Depends: debhelper (>= 12~),
  dh-python,
- python-dev, python3-dev,
+ python3-all-dev,
  libbroccoli-dev,
  swig,
 Standards-Version: 4.3.0
@@ -12,14 +12,6 @@
 Vcs-Git: https://salsa.debian.org/bro-team/broccoli-python.git
 Vcs-Browser: https://salsa.debian.org/bro-team/broccoli-python
 
-Package: python-broccoli
-Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
-Description: Python 2 bindings for Broccoli
- This package provides Python bindings for Broccoli, Bro's client
- communication library. In general, the bindings provide the same
- functionality as Broccoli's C API.
-
 Package: python3-broccoli
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}
diff -Nru broccoli-python-0.63/debian/python3-broccoli.install broccoli-python-0.63/debian/python3-broccoli.install
--- broccoli-python-0.63/debian/python3-broccoli.install	2019-02-08 03:07:43.0 -0500
+++ broccoli-python-0.63/debian/python3-broccoli.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-/usr/lib/python3*
diff -Nru broccoli-python-0.63/debian/python-broccoli.install broccoli-python-0.63/debian/python-broccoli.install
--- broccoli-python-0.63/debian/python-broccoli.install	2019-02-08 03:07:32.0 -0500
+++ broccoli-python-0.63/debian/python-broccoli.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-/usr/lib/python2*
diff -Nru broccoli-python-0.63/debian/rules broccoli-python-0.63/debian/rules
--- broccoli-python-0.63/debian/rules	2019-02-08 03:07:08.0 -0500
+++ broccoli-python-0.63/debian/rules	2019-12-22 17:47:11.0 -0500
@@ -6,7 +6,7 @@
 include /usr/share/dpkg/default.mk
 
 %:
-	dh $@ --with python2 --buildsystem pybuild
+	dh $@ --with python3 --buildsystem pybuild
 
 override_dh_auto_configure:
 	swig -python broccoli_intern.i

Bug#947213: sieve-connect: new upstream version

2019-12-22 Thread itd


Package: sieve-connect
Version: 0.88-1
Severity: wishlist
Tags: patch

Dear Maintainer,

thanks for maintaining sieve-connect.

As of 2019-03-29 sieve-connect version 0.90 is available.  Please
consider packaging it.  Feel free to use the patch [1] as you think fit
to do so.

Thanks again.

Kind regards
itd

[1]: 
https://salsa.debian.org/itd-guest/sieve-connect/compare/master...fixes

Bug#947212: wordpress: 5.3.2 new upstream bug-fixing release available.

2019-12-22 Thread debbug


Package: wordpress
Version: 5.2.4
Severity: critical

Dear Maintainer,

   * What led up to the situation?
   Wordpress 5.3 was released on November 12, 2019 with the latest
   maintenance/security release on December 18, 2019. Since then the
   Debian wordpress package has not been updated from 5.2.4 leaving 
   instances at unnecessary and avoidable risk.


Please consider updating Debian wordpress packages to upstream versions.

To reduce exposure of wordpress instances deploying Debian wordpress 
packages I am offering updated and packaged versions of the 
Debian wordpress packages (tested OK) for sponsored [2] NMU [1]. I intend 
on contributing updates on a regular basis.


Severity "critical" is chosen for this issue being security-related on a large
scale putting many users' systems and data at risk.

@Craig In addition to our past PMs, I'm merely formally reporting this 
critical bug for public reference on 3rd party advise.


--
1: https://mentors.debian.net/package/wordpress
2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D947143


signature.asc
Description: PGP signature

Bug#947133: tightvnc NMU: tightvnc_1.3.9-9_1.3.9-9.1.debdiff (security upload)

2019-12-22 Thread Ola Lundqvist

Thanks.

Den sön 22 dec. 2019 23:02Mike Gabriel  skrev:

> Hi Ola,
>
> On  Sa 21 Dez 2019 19:27:24 CET, Ola Lundqvist wrote:
>
> > Thank you. You can skip the delay.
> >
>
> just issues a
>
>dcut reschedule -f tightvnc_1.3.9-9.1_source.changes -d 0
>
> Greets,
> Mike
> --
>
> mike gabriel aka sunweaver (Debian Developer)
> mobile: +49 (1520) 1976 148
> landline: +49 (4351) 486 14 27
>
> GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
> mail: sunwea...@debian.org, http://sunweavers.net
>
>

Bug#947211: Regression in libsoxr0 0.1.3-2 makes ffmpeg segfault

2019-12-22 Thread Etienne Dechamps

Package: libsoxr0
Version: 0.1.3-2
Control: fixed -1 0.1.3-1

Steps to reproduce:

$ sox -n -r 44100 test.wav synth 1 sine 1000
$ ffmpeg -i test.wav -filter:a "aresample=48000:resampler=soxr" testout.wav
ffmpeg version 4.2.1-2 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 9 (Debian 9.2.1-15)
  configuration: --prefix=/usr --extra-version=2 --toolchain=hardened
--libdir=/usr/lib/x86_64-linux-gnu
--incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl
--disable-stripping --enable-avresample --disable-filter=resample
--enable-avisynth --enable-gnutls --enable-ladspa --enable-libaom
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca
--enable-libcdio --enable-libcodec2 --enable-libflite
--enable-libfontconfig --enable-libfreetype --enable-libfribidi
--enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame
--enable-libmysofa --enable-libopenjpeg --enable-libopenmpt
--enable-libopus --enable-libpulse --enable-librsvg
--enable-librubberband --enable-libshine --enable-libsnappy
--enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora
--enable-libtwolame --enable-libvidstab --enable-libvorbis
--enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265
--enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi
--enable-lv2 --enable-omx --enable-openal --enable-opengl
--enable-sdl2 --enable-libdc1394 --enable-libdrm --enable-libiec61883
--enable-chromaprint --enable-frei0r --enable-libx264 --enable-shared
  libavutil  56. 31.100 / 56. 31.100
  libavcodec 58. 54.100 / 58. 54.100
  libavformat58. 29.100 / 58. 29.100
  libavdevice58.  8.100 / 58.  8.100
  libavfilter 7. 57.100 /  7. 57.100
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale  5.  5.100 /  5.  5.100
  libswresample   3.  5.100 /  3.  5.100
  libpostproc55.  5.100 / 55.  5.100
Input #0, wav, from 'test.wav':
  Duration: 00:00:01.00, bitrate: 1411 kb/s
Stream #0:0: Audio: pcm_s32le ([1][0][0][0] / 0x0001), 44100 Hz,
mono, s32, 1411 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (pcm_s32le (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Segmentation fault (core dumped)

Stack trace:
Thread 1 "ffmpeg" received signal SIGSEGV, Segmentation fault.
__memmove_avx_unaligned_erms () at
../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:416
416 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No
such file or directory.
(gdb) bt
#0  __memmove_avx_unaligned_erms () at
../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:416
#1  0x706c6dcd in memcpy (__len=3556, __src=,
__dest=0x0) at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#2  _soxr_interleave_f (data_type=,
dest0=0x556386c0, src=, n=889, ch=1,
seed=0x55635e00) at ./src/data-io.c:204
#3  0x706c260f in soxr_output_1ch (p=p@entry=0x55635ce0,
i=i@entry=0, dest=dest@entry=0x7fffd1a0, len=,
len@entry=1146, separated=separated@entry=true)
at ./src/soxr.c:664
#4  0x706c3e71 in soxr_process (p=p@entry=0x55635ce0,
in=in@entry=0x7fffcf80, ilen0=, ilen0@entry=1024,
idone0=idone0@entry=0x7fffcee8,
out=out@entry=0x7fffd1a0, olen=olen@entry=1146,
odone0=0x7fffcef0) at ./src/soxr.c:794
#5  0x763bdba3 in process (c=0x55635ce0,
dst=0x7fffd1a0, dst_size=1146, src=0x7fffcf80, src_size=1024,
consumed=0x7fffcf7c) at src/libswresample/soxr_resample.c:90
#6  0x763be5b3 in resample (s=s@entry=0x5561d900,
out_param=out_param@entry=0x7fffd870,
out_count=out_count@entry=1146,
in_param=in_param@entry=0x556208d0,
in_count=in_count@entry=1024) at src/libswresample/swresample.c:537
#7  0x763bef3e in swr_convert_internal
(s=s@entry=0x5561d900, out=out@entry=0x55620f30,
out_count=out_count@entry=1146, in=in@entry=0x556206b0,
in_count=in_count@entry=1024)
at src/libswresample/swresample.c:646
#8  0x763bfa8c in swr_convert_internal (in_count=1024,
in=0x556206b0, out_count=1146, out=0x55620f30,
s=0x5561d900) at src/libswresample/swresample.c:589
#9  swr_convert (s=0x5561d900, out_arg=0x55636440,
out_count=out_count@entry=1146, in_arg=,
in_count=, in_count@entry=1024) at
src/libswresample/swresample.c:766
#10 0x77ccd67f in filter_frame
(inlink=inlink@entry=0x556333c0, insamplesref=) at
src/libavfilter/af_aresample.c:217
#11 0x77d238ad in ff_filter_frame_framed (frame=, link=0x556333c0) at src/libavfilter/avfilter.c:1071
#12 ff_filter_frame_to_filter (link=0x556333c0) at
src/libavfilter/avfilter.c:1219
#13 ff_filter_activate_default (filter=) at
src/libavfilter/avfilter.c:1268
#14 ff_filter_activate (filter=) at
src/libavfilter/avfilter.c:1430
#15 0x77d26a7b in ff_filter_graph_run_once
(graph=graph@entry=0x55619e40) at
src/libavfilter/avfiltergraph.c:1454
#16 0x77d286f8 in push_frame (graph=0x55619e40) at
src/libavfilter/buffersrc.c:187
#17

Bug#947146: buster-pu: package python-mistral-lib/1.0.0-1 CVE-2019-3866

2019-12-22 Thread Thomas Goirand

On 12/21/19 11:34 PM, Salvatore Bonaccorso wrote:
> Hi Thomas
> 
> [Disclaimer: not part of the stable release managers, so this reply is
> not authoritative]
> 
> Thanks for handling CVE-2019-3866 for unstable and buster.
> 
> On Sat, Dec 21, 2019 at 11:12:17PM +0100, Thomas Goirand wrote:
>> Package: release.debian.org
>> Severity: normal
>> Tags: buster
>> User: release.debian@packages.debian.org
>> Usertags: pu
>>
>> Dear Stable Release team,
>>
>> I'd like to upgrade python-mistral-lib to address CVE-2019-3866,
>> which is described in https://bugs.debian.org/946060. Please note
>> that this patch is only useful if you also approve the upload of
>> python-oslo.utils which I requested in #947142.
>>
>> Debdiff containing the patch is attached. Note that there's, as
>> much as I understand, no need to upgrade Mistral to address this
>> CVE (probably it would be needed in Stretch though...), as I believe
>> the issue is fully addressed by the update of python-mistral-lib
>> (at least, that's my understanding when reading the upstream bug
>> entry at https://bugs.launchpad.net/tripleo/+bug/1850843).
> 
> Question (which apply as well for the unstable upload which was just
> done): the python-mistral-lib patch depends on the fixed version of
> python-oslo.utils. Wouldn't that need a versioned dependency
> python-oslo.utils?
> 
> Regards,
> Salvatore

Hi,

There's currently no dependency at all on python3-oslo.utils, because
it's not completely needed. It looks like it is needed only some usage
of Mistral only (like the one TripleO is doing), when calling
generate_unicode_uuid(), is_valid_uuid() or utc_now_sec() from
mistral_lib.utils.

So no, I don't think we should add an artificial hard runtime dependency
on oslo.utils, as long as upstream isn't doing it in requirements.txt.

Your thoughts?

Cheers,

Thomas Goirand (zigo)

Bug#508043: debbugs: Patch to turn link underlines into dotted lines.

2019-12-22 Thread nyov

tags 508043 patch

Hello.

Attached is a CSS fragment that will turn link underlines into dotted lines.
diff --git a/html/bugs.css b/html/bugs.css
index 7bddb101..401e1095 100644
--- a/html/bugs.css
+++ b/html/bugs.css
@@ -39,6 +39,7 @@ h3 {
 a:link {
 color: #1b56ce;
 font-weight: bold;
+text-decoration: underline dotted;
 }
 
 a:visited {
@@ -56,7 +57,7 @@ a:link:hover, a:visited:hover {
 .link, .link abbr, .link abbr:hover {
 color: #1b56ce;
 font-weight: bold;
-text-decoration: underline;
+text-decoration: underline dotted;
 }
 
 .link span:hover {

Bug#947105: [Pkg-puppet-devel] Bug#947105: puppet: Default install uses outdated configuration file and directory locations

2019-12-22 Thread Thomas Goirand

On 12/21/19 3:46 AM, Todd H. Poole wrote:
> Package: puppet
> Version: 5.5.10-4
> Severity: important
> 
> Hi Maintainers,
> 
> In early 2015, upstream Puppet changed the location of several core config 
> files and directories with the release of Puppet 4.0. Today, almost 5 years 
> later, a default install of Puppet 5.5 on Debian 10 still uses those old 
> config file and directory locations.
> 
> For example, per Debian's Puppet man page[1], the upstream Puppet docs[2], 
> and innumerable web search results, the default config directory ("confdir") 
> for Puppet should be /etc/puppetlabs/puppet/, but in Puppet 5.5.10-4 on 
> Debian 10, it's still /etc/puppet/.

I don't see this as an issue. Why would the package include the vendor
name? Why Debian can't choose, if we feel /etc/puppet is better?

> Similar issues exist for all other config file and directory locations 
> changed in Puppet 4.0[3].

Are you suggesting that Debian should use /opt? Hopefully, you are not.

> Although not package-breaking, inconsistencies like these present usability 
> problems for those coming from other distributions or for those who were 
> previously using Puppet's official open source packages.

Though for those who come from Debian and discovered puppet there, it
looks like the upstream decision to move to /etc/puppetlabs is a bad
decision that does abnormal vendor advertising.

> Could a Maintainer update the Debian Puppet package so that Puppet's behavior 
> on Debian matches the documented behavior in the man pages, upstream docs, 
> and upstream packages?

I'd vote for leaving things the way they are now. I wont close the bug,
as I have only uploaded puppet once to Debian, but I suggest the other
uploaders to do so.

Cheers,

Thomas Goirand (zigo)

Bug#947210: xwiimote FTCBFS: configures for the build architecture

Source: xwiimote
Version: 2-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

xwiimote fails to cross build from source, because it fails to configure
for the build architecture. It actually tries configuring twice. Once
via ./autogen.sh and then a second time via dh_auto_configure. The first
invocation selects the wrong architecture and fails. It also is
redundant and can be skipped entirely. Once doing so, xwiimote cross
builds successfully and speeds up native builds. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru xwiimote-2/debian/changelog xwiimote-2/debian/changelog
--- xwiimote-2/debian/changelog 2014-07-19 08:57:41.0 +0200
+++ xwiimote-2/debian/changelog 2019-12-22 23:17:35.0 +0100
@@ -1,3 +1,10 @@
+xwiimote (2-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Configure once via dh_auto_configure only. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 22 Dec 2019 23:17:35 +0100
+
 xwiimote (2-3) unstable; urgency=medium
 
   * Upload to unstable.
diff --minimal -Nru xwiimote-2/debian/rules xwiimote-2/debian/rules
--- xwiimote-2/debian/rules 2014-07-19 08:37:07.0 +0200
+++ xwiimote-2/debian/rules 2019-12-22 23:17:33.0 +0100
@@ -18,7 +18,7 @@
dh $@
 
 override_dh_auto_configure:
-   ./autogen.sh
+   NOCONFIGURE=1 ./autogen.sh
dh_auto_configure -- $(confflags)
 
 override_dh_auto_clean:

Bug#947209: lastpass-cli FTCBFS: runs cmake for the build architecture

Source: lastpass-cli
Version: 1.3.3-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

lastpass-cli fails to cross build from source, because it does not pass
cross flags to cmake. It uses debhelper's makefile buildsystem to invoke
a Makefile, which runs cmake and make. This is backwards and since
debhelper is not in control of the cmake invocation, important flags go
missing. Switching the buildsystem to cmake (and thus sidestepping the
toplevel Makefile) makes lastpass-cli cross buildable. It also makes
verbosity (including DEB_BUILD_OPTIONS=terse) just work. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru lastpass-cli-1.3.3/debian/changelog 
lastpass-cli-1.3.3/debian/changelog
--- lastpass-cli-1.3.3/debian/changelog 2019-07-20 22:13:20.0 +0200
+++ lastpass-cli-1.3.3/debian/changelog 2019-12-22 23:10:32.0 +0100
@@ -1,3 +1,10 @@
+lastpass-cli (1.3.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let debhelper call cmake. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 22 Dec 2019 23:10:32 +0100
+
 lastpass-cli (1.3.3-2) unstable; urgency=medium
 
   * Sourceful upload to unstable to ensure migration to testing.
diff --minimal -Nru lastpass-cli-1.3.3/debian/rules 
lastpass-cli-1.3.3/debian/rules
--- lastpass-cli-1.3.3/debian/rules 2019-07-20 22:13:20.0 +0200
+++ lastpass-cli-1.3.3/debian/rules 2019-12-22 23:10:32.0 +0100
@@ -10,10 +10,10 @@
 CXXFLAGS += $(CPPFLAGS)
 
 %:
-   dh $@
+   dh $@ --buildsystem=cmake --builddirectory=build
 
 override_dh_auto_build:
-   dh_auto_build -- all doc-man VERBOSE=1
+   dh_auto_build -- all doc-man
 
 override_dh_auto_clean:
dh_auto_clean

Bug#947207: chromium: Video is garbled on twitch.tv, most other video sites

2019-12-22 Thread Thue

Package: chromium
Version: 79.0.3945.79-1
Severity: normal

Dear Maintainer,
The hardware video support seems to have broken in a recent update. E.g. 
https://www.twitch.tv/videos/290265920 .

Turning off "Use hardware acceleration when available" in the settings fixes it.

Upstream bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1036725

Regards, Thue


*** 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: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages chromium depends on:
ii  chromium-common  79.0.3945.79-1
ii  libasound2   1.1.9-1
ii  libatk-bridge2.0-0   2.34.1-2
ii  libatk1.0-0  2.34.1-1
ii  libatomic1   9.2.1-21
ii  libatspi2.0-02.34.0-3
ii  libavcodec58 7:4.2.1-2
ii  libavformat587:4.2.1-2
ii  libavutil56  7:4.2.1-2
ii  libc62.29-6
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libcups2 2.3.0-7
ii  libdbus-1-3  1.12.16-2
ii  libdrm2  2.4.100-4
ii  libevent-2.1-7   2.1.11-stable-1
ii  libexpat12.2.9-1
ii  libflac8 1.3.3-1
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.10.1-2
ii  libgcc1  1:9.2.1-21
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-1
ii  libglib2.0-0 2.62.3-2
ii  libgtk-3-0   3.24.13-1
ii  libharfbuzz0b2.6.4-1
ii  libicu63 63.2-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3+b1
ii  liblcms2-2   2.9-4
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.23-1
ii  libnss3  2:3.47.1-1
ii  libopenjp2-7 2.3.1-1
ii  libopus0 1.3-1+b1
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpci3  1:3.6.2-6
ii  libpng16-16  1.6.37-1
ii  libpulse013.0-3
ii  libre2-5 20191101+dfsg-1
ii  libsnappy1v5 1.1.7-2
ii  libstdc++6   9.2.1-21
ii  libva2   2.5.0-2
ii  libvpx6  1.8.1-2
ii  libwebp6 0.6.1-2+b1
ii  libwebpdemux20.6.1-2+b1
ii  libwebpmux3  0.6.1-2+b1
ii  libx11-6 2:1.6.8-1
ii  libx11-xcb1  2:1.6.8-1
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-8
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2.2
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

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

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1

Versions of packages chromium-common recommends:
ii  chromium-sandbox79.0.3945.79-1
ii  fonts-liberation1:1.07.4-10
ii  gnome-shell [notification-daemon]   3.34.2-1
ii  libgl1-mesa-dri 19.3.1-2
ii  libu2f-udev 1.1.10-1
ii  notification-daemon 3.20.0-4
ii  plasma-workspace [notification-daemon]  4:5.14.5.1-4
ii  system-config-printer   1.5.12-1
ii  upower  0.99.11-1

Versions of packages chromium-sandbox depends on:
ii  libatomic1  9.2.1-21
ii  libc6   2.29-6
ii  libgcc1 1:9.2.1-21
ii  libstdc++6  9.2.1-21

-- no debconf information

Bug#947208: youtube-dl 2019.11.28 is available

2019-12-22 Thread Francois Marier

Package: youtube-dl
Version: 2019.09.28-1
Severity: wishlist

A new version of youtube-dl is available upstream. The one in Debian is a
few months old and is missing a few new sites.

Francois

Bug#947182: libjpeg-turbo-progs: jpegexiforient fails if APP1 doesn't occur immediately after JFIF header


Control: tag -1 wontfix

Hi all,

On  So 22 Dez 2019 17:57:27 CET, Ondřej Surý wrote:


Hi Anselm,

see https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/  
why this is a very bad idea.


I am not going to apply the patch to the Debian, nor should it be  
applied upstream. The program violation specification (Digikam)  
should be fixed instead. Applying robustness principle to work  
around bad implementation (instead of work around for bad  
specification) is always wrong.


Ondřej


Updating the bug status with wontfix tag.

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpLww4xXOwcJ.pgp
Description: Digitale PGP-Signatur

Bug#947206: fonttools: Please allow python3-munkres as an alternative to python3-scipy

2019-12-22 Thread Steve Langasek

Package: fonttools
Version: 4.0.2-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64.  We are keeping fonttools on i386 as an
indirect build-dependency of harfbuzz, but it depends on python3-scipy which
is less than ideal to keep as part of a partial i386 port.

It turns out that fonttools upstream can also use the Architecture: all
python3-munkres as an alternative to python3-scipy, so I've uploaded the
attached change to Ubuntu so we can drop scipy on i386.  Would this be a
change you would be willing to consider for Debian as well?

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru fonttools-4.0.2/debian/control fonttools-4.0.2/debian/control
--- fonttools-4.0.2/debian/control  2019-10-12 23:13:35.0 -0500
+++ fonttools-4.0.2/debian/control  2019-12-22 15:09:55.0 -0600
@@ -11,7 +11,7 @@
  python3-all,
  python3-brotli (>= 1.0.7),
  python3-pytest,
- python3-scipy (>= 1.2.2),
+ python3-scipy (>= 1.2.2) | python3-munkres,
  python3-setuptools,
  python3-sympy,
  python3-fs (>= 2.4.11),
@@ -29,7 +29,7 @@
 Depends:
  python3-brotli (>= 1.0.7),
  python3-pkg-resources,
- python3-scipy (>= 1.2.2),
+ python3-scipy (>= 1.2.2) | python3-munkres,
  python3-sympy,
  python3-fs (>= 2.4.11),
  ${misc:Depends},

Bug#947133: tightvnc NMU: tightvnc_1.3.9-9_1.3.9-9.1.debdiff (security upload)


Hi Ola,

On  Sa 21 Dez 2019 19:27:24 CET, Ola Lundqvist wrote:


Thank you. You can skip the delay.



just issues a

  dcut reschedule -f tightvnc_1.3.9-9.1_source.changes -d 0

Greets,
Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpcoYyj0NswT.pgp
Description: Digitale PGP-Signatur

Bug#947205: fwupd.shutdown failed with exit status 2

2019-12-22 Thread Jochen Sprickerhof

Package: fwupd
Version: 1.3.5-1
Severity: normal

Hi,

when shutting down my system, systemd prints:

/lib/systemd/system-shutdown/fwupd.shutdown failed with exit status 2

looking into fwupd.shutdown, I guess this should normally be prevented by

[ -f /var/lib/fwupd/pending.db ] || exit 0

And it's all fine if I remove the pending.db. But running

fwupdmgr refresh

creates the file again, although

fwupdmgr get-updates

tells me that there are no updates.

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

Kernel: Linux 5.3.0-3-amd64 (SMP w/8 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 fwupd depends on:
ii  libc6  2.29-6
ii  libefiboot137-2
ii  libefivar1 37-2
ii  libelf10.176-1.1
ii  libfwupd2  1.3.5-1
ii  libfwupdplugin11.3.5-1
ii  libglib2.0-0   2.62.3-2
ii  libgnutls303.6.11.1-2
ii  libgpg-error0  1.36-7
ii  libgpgme11 1.13.1-1
ii  libgudev-1.0-0 233-1
ii  libgusb2   0.3.0-1
ii  libjson-glib-1.0-0 1.4.4-2
ii  libpolkit-gobject-1-0  0.105-26
ii  libsmbios-c2   2.4.1-1
ii  libsoup2.4-1   2.68.2-1
ii  libsqlite3-0   3.30.1-1
ii  libtss2-esys0  2.3.1-3
ii  libxmlb1   0.1.14-1
ii  shared-mime-info   1.10-1

Versions of packages fwupd recommends:
pn  bolt  
pn  fwupd-signed  
ii  python3   3.7.5-3

fwupd suggests no packages.

-- no debconf information

Bug#936282: tagging 936282

gotcha, thanks

On Sun, Dec 22, 2019 at 4:36 PM Bernd Zeimetz  wrote:
>
>
>
> On 12/22/19 10:32 PM, Sandro Tosi wrote: > it's been more than a month
> this bus was marked as pending, is this> going to be uploaded and fixed
> soon? thanks
>
> https://ftp-master.debian.org/new/ceph_14.2.4-1.html
>
>
>
>
> --
>  Bernd ZeimetzDebian GNU/Linux Developer
>  http://bzed.dehttp://www.debian.org
>  GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



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

Bug#936282: tagging 936282

2019-12-22 Thread Bernd Zeimetz




On 12/22/19 10:32 PM, Sandro Tosi wrote: > it's been more than a month
this bus was marked as pending, is this> going to be uploaded and fixed
soon? thanks

https://ftp-master.debian.org/new/ceph_14.2.4-1.html




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

Bug#947204: stretch-pu: package x2goclient/4.0.5.2-2+deb9u1

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

Hi,

I have just uploaded x2goclient 4.0.5.2-2+deb9u1 with the following change:

++ Add libssh-regression-fix-CVE-2019-14889.patch. In src/sshprocess.cpp:
+  strip ~/, ~user{,/}, ${HOME}{,/} and $HOME{,/} from destination paths
+  in scp mode. Fixes: #1428. This was already necessary for pascp (PuTTY-
+  based Windows solution for Kerberos support), but newer libssh versions
+  with the CVE-2019-14889 also interpret paths as literal strings.
+  (Closes: #947129).

It was discovered that the fix for CVE-2019-14889/libssh (currently
applied in libssh/jessie and libssh/testing+sid) causes a regression in
X2Go Client (copying of files via scp from client to server during session
startup, resulting in a GUI error message that can be clicked away).

The above patch makes X2Go Client robust against the libssh fix being
applied. As a pre-caution, I'd like to see this to be released to Debian 
stretch.

The security team has tagged CVE-2019-14889 as  and provisioning
of a fix for CVE-2019-14889 must be thoroughly tracked for regressions in
other packages in testing/unstable.

Greets,
Mike

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru x2goclient-4.0.5.2/debian/changelog 
x2goclient-4.0.5.2/debian/changelog
--- x2goclient-4.0.5.2/debian/changelog 2016-11-30 08:31:54.0 +0100
+++ x2goclient-4.0.5.2/debian/changelog 2019-12-22 14:53:58.0 +0100
@@ -1,3 +1,15 @@
+x2goclient (4.0.5.2-2+deb9u1) stretch; urgency=medium
+
+  * debian/patches:
++ Add libssh-regression-fix-CVE-2019-14889.patch. In src/sshprocess.cpp:
+  strip ~/, ~user{,/}, ${HOME}{,/} and $HOME{,/} from destination paths
+  in scp mode. Fixes: #1428. This was already necessary for pascp (PuTTY-
+  based Windows solution for Kerberos support), but newer libssh versions
+  with the CVE-2019-14889 also interpret paths as literal strings.
+  (Closes: #947129).
+
+ -- Mike Gabriel   Sun, 22 Dec 2019 14:53:58 +0100
+
 x2goclient (4.0.5.2-2) unstable; urgency=medium
 
   * Rebuild against libssl1.0-dev (via libssh-dev 0.7.3-2).
diff -Nru 
x2goclient-4.0.5.2/debian/patches/libssh-regression-fix-CVE-2019-14889.patch 
x2goclient-4.0.5.2/debian/patches/libssh-regression-fix-CVE-2019-14889.patch
--- 
x2goclient-4.0.5.2/debian/patches/libssh-regression-fix-CVE-2019-14889.patch
1970-01-01 01:00:00.0 +0100
+++ 
x2goclient-4.0.5.2/debian/patches/libssh-regression-fix-CVE-2019-14889.patch
2019-12-22 14:53:58.0 +0100
@@ -0,0 +1,74 @@
+From ce559d163a943737fe4160f7233925df2eee1f9a Mon Sep 17 00:00:00 2001
+From: Mihai Moldovan 
+Date: Fri, 20 Dec 2019 20:27:31 +0100
+Subject: [PATCH] src/sshprocess.cpp: strip ~/, ~user{,/}, ${HOME}{,/} and
+ $HOME{,/} from destination paths in scp mode. Fixes: #1428.
+
+This was already necessary for pascp (PuTTY-based Windows solution for
+Kerberos support), but newer libssh versions with the CVE-2019-14889
+also interpret paths as literal strings.
+
+[sunweaver] - Patch ported to earlier version of x2goclient.
+
+---
+# debian/changelog   |  5 
+ src/sshprocess.cpp | 58 +-
+ 2 files changed, 37 insertions(+), 26 deletions(-)
+
+#diff --git a/debian/changelog b/debian/changelog
+#index 504d6ae..9f84281 100644
+#--- a/debian/changelog
+#+++ b/debian/changelog
+#@@ -135,6 +135,11 @@ x2goclient (4.1.2.2-0x2go1) UNRELEASED; urgency=medium
+#   sound weird first, but this behavior is consistent between all
+#   applications - tray icons can be clicked via either button and will
+#   always trigger a context menu. Let X2Go Client behave the same way.
+#+- src/sshprocess.cpp: strip ~/, ~user{,/}, ${HOME}{,/} and $HOME{,/} from
+#+  destination paths in scp mode. Fixes: #1428. This was already necessary
+#+  for pascp (PuTTY-based Windows solution for Kerberos support), but 
newer
+#+  libssh versions with the CVE-2019-14889 also interpret paths as literal
+#+  strings.
+#   * debian/control:
+# + Add build-depend on pkg-config.
+#   * x2goclient.spec:
+--- a/src/sshprocess.cpp
 b/src/sshprocess.cpp
+@@ -301,6 +301,38 @@
+ x2goDebug<<"Copying file via SshProcess object "< 
"getUser());
++
++dst.remove("~/");
++dst.remove("~" );
++
++dst.remove("${HOME}/");
++dst.remove("${HOME}");
++
++dst.remove("$HOME/");
++

Bug#936282: tagging 936282

On Mon, 18 Nov 2019 01:58:12 +0100 Bernd Zeimetz  wrote:
> tags 936282 + pending
> thanks
>
>
>

it's been more than a month this bus was marked as pending, is this
going to be uploaded and fixed soon? thanks!

Bug#946657: CVE-2019-19725 not fixed in 12.2.0-1

Control: reopen -1
Control: found -1 12.2.0-1

Hi Robert,

While looking for updates to be done for the security-tracker I
noticed that #946657 was closed:

On Sun, Dec 22, 2019 at 05:09:09PM +, Debian Bug Tracking System wrote:
>  sysstat (12.2.0-1) unstable; urgency=medium
>  .
>* New upstream stable version:
>  + fixes double free in check_file_actlst in check_file_actlst in
>sa_common.c (CVE-2019-19725, closes: #946657).

But this is not actually true I believe.
https://github.com/sysstat/sysstat/commit/a5c8abd4a481ee6e27a3acf00e6d9b0f023e20ed
is not applied in 12.2.0-1, and I do not see it applied as patch as
well.

Regards,
Salvatore

Bug#947203: lilyterm FTCBFS: autogen.sh uses the wrong pkg-config

Source: lilyterm
Version: 0.9.9.4+git20150208.f600c0-5
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

lilyterm fails to cross build from source, because its autogen.sh hard
codes the build architecture pkg-config and modifies configure.ac based
on the results. The misdetection results in a failure. It is best to
ship such detection in configure.ac, but there is a reason for not doing
that: The AM_PATH_GTK_2_0 macro is not vendored into lilyterm, so using
it would require a gtk2 installation.

I think it is best to drop support for gtk2 here given that gtk4 is
already considered useable. Once doing so, the logic can be moved from
autogen.sh to configure.ac. That in turn results in using the correct
pkg-config and cross builds succeed.

Please consider applying the attached patch.

Helmut
--- lilyterm-0.9.9.4+git20150208.f600c0.orig/autogen.sh
+++ lilyterm-0.9.9.4+git20150208.f600c0/autogen.sh
@@ -48,19 +48,6 @@
 Replace_Parameter BINARY
 echo ""
 
-# for GTK3+
-pkg-config --cflags gtk+-2.0 > /dev/null 2>&1
-if [ $? != 0 ]; then
-  sed -i 's/^AM_PATH_GTK_2_0.*/PKG_CHECK_MODULES([GTK], [gtk+-3.0])/g' configure.ac
-  pkg-config --cflags vte-2.91 > /dev/null 2>&1
-  if [ $? = 0 ]; then
-sed -i 's/^PKG_CHECK_MODULES(vte, \[vte >= .*/PKG_CHECK_MODULES(vte, [vte-2.91 >= 0.38.0],, AC_MSG_ERROR([You need libvte-2.91 >= 0.38.0 to build $_PACKAGE]))/g' configure.ac
-sed -i 's/^lilyterm_LDADD\(.*\)$/lilyterm_LDADD\1 -lX11/g' src/Makefile.am
-  else
-sed -i 's/^PKG_CHECK_MODULES(vte, \[vte >= .*/PKG_CHECK_MODULES(vte, [vte-2.90 >= 0.30.0],, AC_MSG_ERROR([You need libvte-2.90 >= 0.30.0 to build $_PACKAGE]))/g' configure.ac
-  fi
-fi
-
 set -x
 
 aclocal
--- lilyterm-0.9.9.4+git20150208.f600c0.orig/configure.ac
+++ lilyterm-0.9.9.4+git20150208.f600c0/configure.ac
@@ -12,9 +12,15 @@
 AM_PROG_CC_C_O
 
 # Checks for libraries.
-AM_PATH_GTK_2_0(2.8.0,,AC_MSG_ERROR([You need Gtk+ >= 2.8.0 to build $_PACKAGE]))
-AM_PATH_GLIB_2_0(2.12.0,,AC_MSG_ERROR([You need Glib >= 2.12.0 to build $_PACKAGE]))
-PKG_CHECK_MODULES(vte, [vte >= 0.12.0],, AC_MSG_ERROR([You need libvte >= 0.12.0 to build $_PACKAGE]))
+EXTRA_LINK_X11=
+PKG_CHECK_MODULES([GTK],[gtk+-3.0])
+PKG_CHECK_MODULES([VTE291],[vte-2.91],[
+  PKG_CHECK_MODULES([vte],[vte-2.91 >= 0.38.0],, AC_MSG_ERROR([You need libvte-2.91 >= 0.38.0 to build $_PACKAGE]))
+  EXTRA_LINK_X11=-lX11
+],[
+  PKG_CHECK_MODULES([vte],[vte-2.90 >= 0.30.0],, AC_MSG_ERROR([You need libvte-2.90 >= 0.30.0 to build $_PACKAGE]))
+])
+AC_SUBST([EXTRA_LINK_X11])
 
 AC_ARG_ENABLE(debug, AC_HELP_STRING([--enable-debug], [enable debug mode]),
 	  CFLAGS="$CFLAGS -g"
@@ -24,9 +30,6 @@
 	  CFLAGS="$CFLAGS -g"
 	  AC_DEFINE(REALMODE,, [disable run in safe mode]))
 
-PKG_CHECK_EXISTS(gtk+-2.0 < 2.12,
-		 AC_MSG_WARN([Using Gtk+ >= 2.12.0 to build $_PACKAGE is recommended]))
-
 AC_MSG_CHECKING([whether to install GNOME control-center default application definition])
 if $PKG_CONFIG --variable=keysdir gnome-default-applications >/dev/null ; then
  AC_MSG_RESULT([yes])
--- lilyterm-0.9.9.4+git20150208.f600c0.orig/src/Makefile.am
+++ lilyterm-0.9.9.4+git20150208.f600c0/src/Makefile.am
@@ -2,7 +2,7 @@
 
 bin_PROGRAMS = $_BINARY
 lilyterm_CFLAGS  = $(GTK_CFLAGS) $(vte_CFLAGS)
-lilyterm_LDADD   = $(GTK_LIBS) $(vte_LIBS) $(INTLLIBS)
+lilyterm_LDADD   = $(GTK_LIBS) $(vte_LIBS) $(INTLLIBS) $(EXTRA_LINK_X11)
 lilyterm_SOURCES = data.h lilyterm.h \
 		   misc.h misc.c \
 		   console.h console.c \

Bug#947202: nfsidmap manpage installed in section 5 instead of 8

Package: nfs-common
Version: 1:1.3.4-2.5
Severity: minor
Control: found -1 1:1.3.4-2.1

>From bug #924587 as reported by Sergio Gelato:

On Sun, Dec 22, 2019 at 06:25:18PM +0100, Sergio Gelato wrote:
> (Aside: the libnfsidmap2 package mistakenly has the nfsidmap man page
> in section 5 rather than 8, in both stretch and buster (I haven't checked 
> sid).
> Minor documentation bug.)

The manpage for nfsidmap comes from src:nfs-utils and installed in
nfs-common package, but it is installed wrongly in section 5 rather
than 8. From quick check in the build logs:

dh_installman
[...]
install -p -m0644 ./debian/tmp/usr/share/man/man8/nfsidmap.8 
debian/nfs-common/usr/share/man/man5/nfsidmap.5

Regards,
Salvatore

Bug#947201: buster-pu: package x2goclient/4.1.2.1-2+deb10u1

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

Hi,

I have just uploaded x2goclient 4.1.2.1-2+deb10u1 with the following change:

+  * debian/patches:
++ Add libssh-regression-fix-CVE-2019-14889.patch. In src/sshprocess.cpp:
+  strip ~/, ~user{,/}, ${HOME}{,/} and $HOME{,/} from destination paths
+  in scp mode. Fixes: #1428. This was already necessary for pascp (PuTTY-
+  based Windows solution for Kerberos support), but newer libssh versions
+  with the CVE-2019-14889 also interpret paths as literal strings.
+  (Closes: #947129).

It was discovered that the fix for CVE-2019-14889/libssh (currently
applied in libssh/jessie and libssh/testing+sid) causes a regression in
X2Go Client (copying of files via scp from client to server during session
startup, resulting in a GUI error message that can be clicked away).

The above patch makes X2Go Client robust against the libssh fix being
applied. As a pre-caution, I'd like to see this be released to Debian buster.

The security team has tagged CVE-2019-14889 as  and provisioning
of a fix for CVE-2019-14889 must be thoroughly tracked for regressions in
other packages in testing/unstable.

Greets,
Mike


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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru x2goclient-4.1.2.1/debian/changelog 
x2goclient-4.1.2.1/debian/changelog
--- x2goclient-4.1.2.1/debian/changelog 2018-08-13 21:48:20.0 +0200
+++ x2goclient-4.1.2.1/debian/changelog 2019-12-21 18:22:22.0 +0100
@@ -1,3 +1,15 @@
+x2goclient (4.1.2.1-2+deb10u1) buster; urgency=medium
+
+  * debian/patches:
++ Add libssh-regression-fix-CVE-2019-14889.patch. In src/sshprocess.cpp:
+  strip ~/, ~user{,/}, ${HOME}{,/} and $HOME{,/} from destination paths
+  in scp mode. Fixes: #1428. This was already necessary for pascp (PuTTY-
+  based Windows solution for Kerberos support), but newer libssh versions
+  with the CVE-2019-14889 also interpret paths as literal strings.
+  (Closes: #947129).
+
+ -- Mike Gabriel   Sat, 21 Dec 2019 18:22:22 +0100
+
 x2goclient (4.1.2.1-2) unstable; urgency=medium
 
   * debian/patches:
diff -Nru 
x2goclient-4.1.2.1/debian/patches/libssh-regression-fix-CVE-2019-14889.patch 
x2goclient-4.1.2.1/debian/patches/libssh-regression-fix-CVE-2019-14889.patch
--- 
x2goclient-4.1.2.1/debian/patches/libssh-regression-fix-CVE-2019-14889.patch
1970-01-01 01:00:00.0 +0100
+++ 
x2goclient-4.1.2.1/debian/patches/libssh-regression-fix-CVE-2019-14889.patch
2019-12-21 18:22:22.0 +0100
@@ -0,0 +1,110 @@
+From ce559d163a943737fe4160f7233925df2eee1f9a Mon Sep 17 00:00:00 2001
+From: Mihai Moldovan 
+Date: Fri, 20 Dec 2019 20:27:31 +0100
+Subject: [PATCH] src/sshprocess.cpp: strip ~/, ~user{,/}, ${HOME}{,/} and
+ $HOME{,/} from destination paths in scp mode. Fixes: #1428.
+
+This was already necessary for pascp (PuTTY-based Windows solution for
+Kerberos support), but newer libssh versions with the CVE-2019-14889
+also interpret paths as literal strings.
+---
+# debian/changelog   |  5 
+ src/sshprocess.cpp | 58 +-
+ 2 files changed, 37 insertions(+), 26 deletions(-)
+
+#diff --git a/debian/changelog b/debian/changelog
+#index 504d6ae..9f84281 100644
+#--- a/debian/changelog
+#+++ b/debian/changelog
+#@@ -135,6 +135,11 @@ x2goclient (4.1.2.2-0x2go1) UNRELEASED; urgency=medium
+#   sound weird first, but this behavior is consistent between all
+#   applications - tray icons can be clicked via either button and will
+#   always trigger a context menu. Let X2Go Client behave the same way.
+#+- src/sshprocess.cpp: strip ~/, ~user{,/}, ${HOME}{,/} and $HOME{,/} from
+#+  destination paths in scp mode. Fixes: #1428. This was already necessary
+#+  for pascp (PuTTY-based Windows solution for Kerberos support), but 
newer
+#+  libssh versions with the CVE-2019-14889 also interpret paths as literal
+#+  strings.
+#   * debian/control:
+# + Add build-depend on pkg-config.
+#   * x2goclient.spec:
+diff --git a/src/sshprocess.cpp b/src/sshprocess.cpp
+index 70c3b1c..aec5d0b 100644
+--- a/src/sshprocess.cpp
 b/src/sshprocess.cpp
+@@ -310,6 +310,38 @@ void SshProcess::start_cp(QString src, QString dst)
+ x2goDebug<<"Copying file via SshProcess object "< 
"getUser());
++
++dst.remove("~/");
++dst.remove("~" );
++
++dst.remove("${HOME}/");
++

Bug#940839: Same bug with 2.4.4

2019-12-22 Thread Gianpaolo Cugola

Sorry, my mistake, I meant 2.4.3.

G.

On Sun, Dec 22, 2019 at 9:24 PM John Scott  wrote:

> Hello,
>
> > Same situation here with openshot 2.4.4 from debian sid. I have an intel
> gpu.
> OpenShot 2.4.4 isn't in Debian Sid yet. Where did you install it from?
>

Bug#944913: python3-sphinx: Please update to Sphinx 2.2.1

2019-12-22 Thread Dmitry Shachnev

Hi Sandro!

On Sun, Dec 22, 2019 at 02:47:10PM -0500, Sandro Tosi wrote:
> > The current version packaged in Debian is very outdated,
> > even in unstable. Please consider packaging the current
> > upstream release.
>
> I'm echoing this request: the just released numpy/1.18.0 requires
> sphinx >= 2.2.0, so we cannot upgrade numpy without an updated sphinx.
> please consider package it at the earliest.

Unfortunately sphinx ≥ 2.0 dropped support for Python 2.

So I should either wait until all blocking bugs of #938528 are resolved, or
introduce a new source package like sphinx-python2 for the old version.

However the latter solution will mean that we can no longer have shared
sphinx-common and libjs-sphinxdoc packages, and we will need to have two
versions of dh_sphinxdoc too (or one version that will generate different
dependencies for old and new sphinx). This is something I wanted to avoid,
because it is extra work for supporting a Python 2 version that will be
dead in a few days.

Recently your script bumped many Python 2 removal bugs to RC, with the
intention to accelerate porting those packages to Python 3 (or getting them
removed). Maybe better to wait a couple of months and then just upload new
Sphinx and break its Python 2 reverse build-dependencies?

Can you patch old Sphinx support into numpy for the time being?

--
Dmitry Shachnev

signature.asc
Description: PGP signature

Bug#939095: RFS: axtls/2.1.5+ds-1 [ITP] -- Highly configurable client/server TLSv1.2 library

On Sun, Dec 22, 2019 at 10:33:02PM +0800, Yangfl wrote:
> Adam Borowski  于2019年12月16日周一 下午9:38写道：
> >
> > This time, it builds ok, but fails autopkgtests:
> >
> > autopkgtest [14:16:24]: test unittest.sh: [---
> > make: Entering directory '/tmp/autopkgtest.vLonTb/build.5od/src/ssl/test'
> > cc -I../../config -I../../ssl -I../../crypto -Wall -Wstrict-prototypes 
> > -Wshadow -fPIC  -g -c -o ssltest.o ssltest.c
> > cc   -o ../.././_stage/ssltest ssltest.o -lpthread -L ../.././_stage -laxtls
> > /usr/bin/ld: cannot open output file ../.././_stage/ssltest: No such file 
> > or directory
> >
> Reuploaded. Build and test passed on salsa.

Alas, still faisl for me, on two different machines:

autopkgtest [22:11:50]: test unittest.sh: [---
make: Entering directory '/tmp/autopkgtest.Fa7C0w/build.H2E/src/ssl/test'
cc -I../../config -I../../ssl -I../../crypto -Wall -Wstrict-prototypes -Wshadow 
-fPIC  -g -c -o ssltest.o ssltest.c
cc   -o ../.././_stage/ssltest ssltest.o -lpthread -L ../.././_stage -laxtls
make: Leaving directory '/tmp/autopkgtest.Fa7C0w/build.H2E/src/ssl/test'
make: Entering directory '/tmp/autopkgtest.Fa7C0w/build.H2E/src/samples'
make -C c
make[1]: Entering directory '/tmp/autopkgtest.Fa7C0w/build.H2E/src/samples/c'
cc -I../../config -I../../ssl -I../../crypto -Wall -Wstrict-prototypes -Wshadow 
-fPIC  -g -c -o axssl.o axssl.c
cc   -o ../.././_stage/axssl axssl.o -L../.././_stage -laxtls
make[1]: Leaving directory '/tmp/autopkgtest.Fa7C0w/build.H2E/src/samples/c'
make: Leaving directory '/tmp/autopkgtest.Fa7C0w/build.H2E/src/samples'
All AES tests passed
All MD5 tests passed
All SHA1 tests passed
All SHA256 tests passed
All SHA384 tests passed
All SHA512 tests passed
All HMAC tests passed
All BIGINT tests passed
All RSA tests passed
invalid digest: 2a 86 48 ce 38 04 03 
Error: Invalid X509 ASN.1 file (Unsupported digest)
invalid digest: 2a 86 48 ce 3d 04 03 03 
Error: Invalid X509 ASN.1 file (Unsupported digest)
All Certificate tests passed
SSL basic test passed
SSL unblocked test passed
 ALL TESTS PASSED 
# C SAMPLE ###
C Test passed
=== CERTIFICATE ISSUED TO ===
Common Name (CN):   localhost
Organization (O):   axTLS Project
=== CERTIFICATE ISSUED BY ===
Common Name (CN):   
Organization (O):   axTLS Project Dodgy Certificate Authority
Not Before: Fri Dec 30 21:04:27 2016
Not After:  Sun Sep  8 21:04:27 2030
RSA bitsize:1024
Sig Type:   SHA1
=== CERTIFICATE ISSUED TO ===
Common Name (CN):   
Organization (O):   axTLS Project Dodgy Certificate Authority
Basic Constraints:  critical, CA:TRUE, pathlen:1
Key Usage:  critical, Digital Signature, Key Cert Sign, CRL 
Sign
=== CERTIFICATE ISSUED BY ===
Common Name (CN):   
Organization (O):   axTLS Project Dodgy Certificate Authority
Not Before: Fri Dec 30 21:04:27 2016
Not After:  Sun Sep  8 21:04:27 2030
RSA bitsize:2048
Sig Type:   SHA1
CONNECTED
=== CERTIFICATE ISSUED TO ===
Common Name (CN):   localhost
Organization (O):   axTLS Project
=== CERTIFICATE ISSUED BY ===
Common Name (CN):   
Organization (O):   axTLS Project Dodgy Certificate Authority
Not Before: Fri Dec 30 21:04:27 2016
Not After:  Sun Sep  8 21:04:27 2030
RSA bitsize:1024
Sig Type:   SHA1
-BEGIN SSL SESSION PARAMETERS-
b4dd745eb50c1c26cb9ecd263cb604b8b4de69c8b4078939fc3caf279c327738
-END SSL SESSION PARAMETERS-
-BEGIN SSL SESSION PARAMETERS-
b4dd745eb50c1c26cb9ecd263cb604b8b4de69c8b4078939fc3caf279c327738
-END SSL SESSION PARAMETERS-
-BEGIN SSL SESSION PARAMETERS-
b4dd745eb50c1c26cb9ecd263cb604b8b4de69c8b4078939fc3caf279c327738
-END SSL SESSION PARAMETERS-
-BEGIN SSL SESSION PARAMETERS-
b4dd745eb50c1c26cb9ecd263cb604b8b4de69c8b4078939fc3caf279c327738
-END SSL SESSION PARAMETERS-
-BEGIN SSL SESSION PARAMETERS-
b4dd745eb50c1c26cb9ecd263cb604b8b4de69c8b4078939fc3caf279c327738
-END SSL SESSION PARAMETERS-
CIPHER is AES128-SHA256
C Test passed
=== CERTIFICATE ISSUED TO ===
Common Name (CN):   localhost
Organization (O):   axTLS Project
=== CERTIFICATE ISSUED BY ===
Common Name (CN):   
Organization (O):   axTLS Project Dodgy Certificate Authority
Not Before: Fri Dec 30 21:04:27 2016
Not After:  Sun Sep  8 21:04:27 2030
RSA bitsize:1024
Sig Type:   SHA1
=== CERTIFICATE ISSUED TO ===
Common Name (CN):   
Organization (O):   axTLS Project

Bug#945636: discus: Python2 removal in sid/bullseye

2019-12-22 Thread Paulo Henrique de Lima Santana


Hi,

Few months ago Nicolas Carrier  contacted me 
because he would like send patches to fix issues in this sofwtare, but 
he coudn't find and contact the upstream.


So, I am asking to Nicolas adopte the source code, fix the issues and 
convert it to python 3.


If he do that, I will be able to update the package too.

Best regards,

On Wed, 27 Nov 2019 23:58:47 + Sandro Tosi 
 wrote:

Source: discus
Version: 0.2.9-11
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests (the specific reason can be found searching this
source package in
https://people.debian.org/~morph/mass-bug-py2removal_take3.txt ).
Please stop using Python2, and fix this issue by one of the following
actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.
  
  This is the preferred option.


- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.




--
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Debian Developer
Diretor do Instituto para Conservação de Tecnologias Livres
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450

Bug#947151: [3dprinter-general] Bug#947151: cura: GUI unusable under scaled desktop

2019-12-22 Thread Gregor Riepl

> When running Cura under a scaled KDE desktop (1.3x scale), the font and 
> positioning of text makes Cura unusable. I have attached a screenshot of 
> what it looks like.

The bug is known, but I'm not sure if it is in python3-qt or in Cura itself.

I intend to package a recent Cura version very soon, hopefully this will fix
the issue. Please stay tuned.

Bug#947178: RFS: dmidecode/3.2-3 -- SMBIOS/DMI table decoder

On Sun, Dec 22, 2019 at 08:39:23PM +0100, Jörg Frings-Fürst wrote:
> > Which is because of dmidecode living in sbin.  As -V requires no
> > privileges,
> > you can run ｢/usr/sbin/dmidecove -V｣ without bothering about root.
> 
> I use now /usr/sbin/dmidecode -V. Uploaded to mentors and into git.

Awesome, it works now.

One last thing: why did you set Rules-Requires-Root to yes?  There's nothing
that'd require root privileges while building the package.  I've just
verified -- it builds ok and passes tests.

May I upload the version I tested, with s/binary-targets/no/ ?

Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#938053: python-publicsuffix: diff for NMU version 1.1.0-2.1

2019-12-22 Thread Evgeni Golov

Thanks Sandro, feel free to upload to sid without delay!

On December 22, 2019 8:23:22 PM UTC, Sandro Tosi  wrote:
>Control: tags 938053 + patch
>
>
>Dear maintainer,
>
>I've prepared an NMU for python-publicsuffix (versioned as 1.1.0-2.1). The diff
>is attached to this message.
>
>Regards.
>

Bug#938053: python-publicsuffix: diff for NMU version 1.1.0-2.1

On Sun, Dec 22, 2019 at 3:36 PM Evgeni Golov  wrote:
>
> Thanks Sandro, feel free to upload to sid without delay!

that's what i did :D :D

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

Bug#792137:

2019-12-22 Thread jibeh dodo

i sent you email before but no response,contact me please

שלחתי לך דוא"ל לפני כן אך אין תגובה, צור איתי קשר בבקשה

Bug#947200: RFS: ipmitool/1.8.18-8 -- utility for IPMI control with kernel driver or LAN interface (daemon)

2019-12-22 Thread Jörg Frings-Fürst

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "ipmitool"

   Package name: ipmitool
   Version : 1.8.18-8
   Upstream Author : Vernon Mauery 
   URL : https://github.com/ipmitool/ipmitool
   License : BSD-3-clause
   Vcs : https://jff.email/cgit/ipmitool.git
   Section : utils

It builds those binary packages:

  ipmitool - utility for IPMI control with kernel driver or LAN
interface (daemon)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/ipmitool/ipmitool_1.8.18-8.dsc

or from git

https://jff.email/cgit/ipmitool.git/?h=release%2Fdebian%2F1.8.18-8


Changes since the last upload:

   * New debian/patches/0130-Correct_lanplus_segment_violation.patch:
 - Fix lanplus segment violation for truncated response (Closes: #945764).
   * Declare compliance with Debian Policy 4.4.1.2 (No changes needed).
   * Switch to debhelper-compat:
 - debian/control: change to debhelper-compat (=12).
 - remove debian/compat.
   * debian/control:
 - Add Rules-Requires-Root: no.
   * debian/copyright:
 - Add 2019 to debian/*.

The build with sbuild and pdebuild and the tests with Lintain and
Piuparts are ok:

+--+
| Summary  |
+--+

Build Architecture: amd64
Build Type: full
Build-Space: 132000
Build-Time: 45
Distribution: sid
Host Architecture: amd64
Install-Time: 34
Job: /data/entwicklung/linux/debian/ipmitool/ipmitool_1.8.18-8.dsc
Lintian: info
Machine Architecture: amd64
Package: ipmitool
Package-Time: 175
Piuparts: pass
Source-Version: 1.8.18-8
Space: 132000
Status: successful
Version: 1.8.18-8

Finished at 2019-12-22T19:46:07Z
Build needed 00:02:55, 132000k disk space


Regards,


  Jörg Frings-Fürst


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#947193: please coordinate the provider of crypt.h

2019-12-22 Thread Marco d'Itri

On Dec 22, Helmut Grohne  wrote:

> I don't immediately see which of these options is "better". Both of them
> have advantages and disadvantages. For instances, the first option means
> more differences between musl and glibc, which tends to make porting
> harder.
It will also make software built with MUSL not work on systems with 
passwords hashed with modern methods.
But all this is up to the musl maintainer, so let me know if I should 
make some changes.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#938053: python-publicsuffix: diff for NMU version 1.1.0-2.1

Control: tags 938053 + patch


Dear maintainer,

I've prepared an NMU for python-publicsuffix (versioned as 1.1.0-2.1). The diff
is attached to this message.

Regards.

diff -Nru python-publicsuffix-1.1.0/debian/changelog python-publicsuffix-1.1.0/debian/changelog
--- python-publicsuffix-1.1.0/debian/changelog	2015-09-05 06:38:27.0 -0400
+++ python-publicsuffix-1.1.0/debian/changelog	2019-12-22 15:21:08.0 -0500
@@ -1,3 +1,10 @@
+python-publicsuffix (1.1.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938053
+
+ -- Sandro Tosi   Sun, 22 Dec 2019 15:21:08 -0500
+
 python-publicsuffix (1.1.0-2) unstable; urgency=medium
 
   * Fix FTBFS with non-UTF-8 locales (Closes: #795978)
diff -Nru python-publicsuffix-1.1.0/debian/control python-publicsuffix-1.1.0/debian/control
--- python-publicsuffix-1.1.0/debian/control	2015-08-09 14:09:47.0 -0400
+++ python-publicsuffix-1.1.0/debian/control	2019-12-22 15:20:46.0 -0500
@@ -2,25 +2,12 @@
 Maintainer: Evgeni Golov 
 Section: python
 Priority: optional
-Build-Depends: python-all (>= 2.6.6-3), python3-all, dh-python, debhelper (>= 7.0.50~), publicsuffix, python-setuptools, python3-setuptools
+Build-Depends: python3-all, dh-python, debhelper (>= 7.0.50~), publicsuffix, python3-setuptools
 Standards-Version: 3.9.6
 Homepage: https://pypi.python.org/pypi/publicsuffix
 Vcs-Git: git://anonscm.debian.org/collab-maint/python-publicsuffix.git
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/python-publicsuffix.git
 
-Package: python-publicsuffix
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}, publicsuffix, python-pkg-resources
-Description: Python module to get a domain suffix using the Public Suffix List
- This Python module allows you to get the public suffix of a domain name using
- the Public Suffix List from http://publicsuffix.org.
- .
- A public suffix is one under which Internet users can directly register
- names. Some examples of public suffixes are .com, .co.uk and pvt.k12.wy.us.
- Accurately knowing the public suffix of a domain is useful when handling
- web browser cookies, highlighting the most important part of a domain name
- in a user interface or sorting URLs by web site.
-
 Package: python3-publicsuffix
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}, publicsuffix, python3-pkg-resources
diff -Nru python-publicsuffix-1.1.0/debian/rules python-publicsuffix-1.1.0/debian/rules
--- python-publicsuffix-1.1.0/debian/rules	2015-08-09 07:18:21.0 -0400
+++ python-publicsuffix-1.1.0/debian/rules	2019-12-22 15:20:53.0 -0500
@@ -3,7 +3,7 @@
 export PYBUILD_NAME=publicsuffix
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_install:
 	dh_auto_install
diff -Nru python-publicsuffix-1.1.0/debian/tests/control python-publicsuffix-1.1.0/debian/tests/control
--- python-publicsuffix-1.1.0/debian/tests/control	2015-08-09 14:12:30.0 -0400
+++ python-publicsuffix-1.1.0/debian/tests/control	2019-12-22 15:21:02.0 -0500
@@ -1,7 +1,3 @@
-Test-Command: python2 tests.py -v
-Restrictions: allow-stderr
-Depends: python, python-publicsuffix
-
 Test-Command: python3 tests.py -v
 Restrictions: allow-stderr
 Depends: python3, python3-publicsuffix

Bug#940839: openshot-qt crashes immidiately

Are you still able to reproduce this bug? In your logs I noticed the following
> Debian Release: bullseye/sid
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable'),
>   (110, 'unstable')> 
> Architecture: amd64 (x86_64)

It looks like you have a mixture of stable, bullseye, and unstable packages 
and that might provoke this. Do you know how this happened?

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

Bug#940839: Same bug with 2.4.4

Hello,

> Same situation here with openshot 2.4.4 from debian sid. I have an intel 
gpu.
OpenShot 2.4.4 isn't in Debian Sid yet. Where did you install it from?


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

Bug#936740: ipe-tools supports Python 3

Control: tags -1 fixed-upstream

It looks like the current releases use Python 3 for svgtoipe now
https://github.com/otfried/ipe-tools/commit/60ccc014

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

Bug#937099: mypaint Python 3 support

Control: tags -1 fixed-upstream

MyPaint has released their first 2.0 beta with Python 3 support. The 
announcement suggests it's stable and it could use testing to find any 
remaining bugs.
See https://github.com/mypaint/mypaint/releases/tag/v2.0.0-beta.0

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

Bug#877106: pinta: Pinta 1.6-2 crashes on image scaling and other image manipulation.

This bug has been open for a while and blocks Pinta getting into Debian 
Bullseye. Can you confirm whether or not you can still reproduce this issue?

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

Bug#897777: kvmtool: ftbfs with GCC 8

Control: tags -1 fixed-upstream

I think this is fixed upstream. I found these commits that seem to be related:
https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/commit/?id=05755b29
https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/commit/?id=96eda741
https://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git/commit/?id=eaeaf608

The last commit doesn't appear to be necessary to build with GCC 8, but it is
the only additional error that was in Reproducible Builds's build with GCC 9.
This might be sufficient to build with that too.

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

Bug#925758: librecad: ftbfs with GCC-9

Control: forwarded -1 https://github.com/LibreCAD/LibreCAD/pull/
Control: tags -1 upstream fixed-upstream ftbfs

This has been fixed upstream. The change is at
https://github.com/shawncurry/LibreCAD/commit/3bc93383

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

Bug#947199: ITP: icoextract -- icon extractor for Windows PE files

2019-12-22 Thread James Lu

Package: wnpp
Severity: wishlist
Owner: James Lu 

* Package name: icoextract
  Version : 0.1.0
  Upstream Author : James Lu 
* URL : https://github.com/jlu5/icoextract
* License : MIT/Expat
  Programming Lang: Python
  Description : icon extractor for Windows PE files

icoextract is an icon extractor for Windows PE files (.exe/.dll),
written in Python. It also includes a thumbnailer script
(exe-thumbnailer) for Linux desktops.

This project is intended to supersede the current exe-thumbnailer[1],
which has technical limitations such as not supporting 256x256 (Vista+)
icons.

This package will be maintained in the Debian Wine Team.

Best,
James

[1]: https://github.com/exe-thumbnailer/exe-thumbnailer/issues/17



signature.asc
Description: OpenPGP digital signature

Bug#937841: python-iowait: diff for NMU version 0.1-1.2

Control: tags 937841 + patch


Dear maintainer,

I've prepared an NMU for python-iowait (versioned as 0.1-1.2). The diff
is attached to this message.

Regards.

diff -Nru python-iowait-0.1/debian/changelog python-iowait-0.1/debian/changelog
--- python-iowait-0.1/debian/changelog	2011-05-08 10:46:00.0 -0400
+++ python-iowait-0.1/debian/changelog	2019-12-22 15:15:00.0 -0500
@@ -1,3 +1,10 @@
+python-iowait (0.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937841
+
+ -- Sandro Tosi   Sun, 22 Dec 2019 15:15:00 -0500
+
 python-iowait (0.1-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru python-iowait-0.1/debian/control python-iowait-0.1/debian/control
--- python-iowait-0.1/debian/control	2011-02-28 12:16:49.0 -0500
+++ python-iowait-0.1/debian/control	2019-12-22 15:15:00.0 -0500
@@ -2,30 +2,13 @@
 Section: python
 Priority: optional
 Maintainer: Andrea Corbellini 
-Build-Depends: debhelper (>= 7.0.50~)
-Build-Depends-Indep: python-all (>= 2.6.6-3~), python3-all (>= 3.1.2-1~)
+Build-Depends: debhelper (>= 7.0.50~), dh-python
+Build-Depends-Indep: python3-all (>= 3.1.2-1~)
 Standards-Version: 3.9.1
-XS-Python-Version: >= 2.6
-XS-Python3-Version: >= 3.1
 Homepage: https://launchpad.net/python-iowait
 Vcs-Bzr: http://bazaar.launchpad.net/+branch/python-iowait/0.1
 Vcs-Browser: http://bazaar.launchpad.net/+branch/python-iowait/0.1/files
 
-Package: python-iowait
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Breaks: ${python:Breaks}
-XB-Python-Version: ${python:Versions}
-Description: Platform-independent module for I/O completion events
- Different operating systems provide different ways to wait for I/O completion
- events: there's select(), poll(), epoll() and kqueue(). For cross-platform
- applications it can be a pain to support all this system functions, especially
- because each one provides a different interface.
- .
- IOWait solves this problem by providing a unified interface and using always
- the best and faster function available in the platform. Its only limitation is
- that, on Windows, it only works for sockets.
-
 Package: python3-iowait
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
diff -Nru python-iowait-0.1/debian/rules python-iowait-0.1/debian/rules
--- python-iowait-0.1/debian/rules	2011-02-28 12:22:44.0 -0500
+++ python-iowait-0.1/debian/rules	2019-12-22 15:14:56.0 -0500
@@ -1,18 +1,4 @@
 #!/usr/bin/make -f
 
 %:
-	dh $@ --with python2
-
-override_dh_auto_install:
-	for pyver in $(shell pyversions -vr); do \
-		python$$pyver setup.py install \
-			--install-layout=deb --root "$(CURDIR)/debian/python-iowait"; \
-	done
-	for pyver in $(shell py3versions -sv); do \
-		python$$pyver setup.py install \
-			--install-layout=deb --root "$(CURDIR)/debian/python3-iowait"; \
-	done
-
-override_dh_python2:
-	dh_python2 -ppython-iowait
-	dh_python3 -ppython3-iowait
+	dh $@ --with python3 --buildsystem=pybuild

Bug#936966: londonlaw: Python2 removal in sid/bullseye

2019-12-22 Thread Juhani Numminen

On Fri, 30 Aug 2019 07:25:11 + Matthias Klose  wrote:
> Package: src:londonlaw
> Version: 0.2.1-20
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

Hello Fuddl,

Do you think we should remove londonlaw from Debian?
As far as I know, there is and will be no python3 support, because
upstream seems to be gone.
Fedora retired londonlaw in August. 
https://bugzilla.redhat.com/show_bug.cgi?id=1731636

Regards,
Juhani

Bug#944913: python3-sphinx: Please update to Sphinx 2.2.1

On Sun, 17 Nov 2019 16:51:39 +0100 Christian Grothoff
 wrote:
> Package: python3-sphinx
> Version: 1.8.5-3
> Severity: wishlist
>
> Dear Maintainer,
>
> The current version packaged in Debian is very outdated,
> even in unstable. Please consider packaging the current
> upstream release.

I'm echoing this request: the just released numpy/1.18.0 requires
sphinx >= 2.2.0, so we cannot upgrade numpy without an updated sphinx.
please consider package it at the earliest.

thanks!

Bug#946829: CVE-2019-19920

Control: clone 946829 -1
Control: retitle -1 sa-exim: CVE-2019-19920
Control: tags -1 + security

Hi,

On Thu, Dec 19, 2019 at 09:06:13AM +0200, Henrik Krohns wrote:
> 
> Hello,
> 
> This was really a vulnerability which allowed running any perl code or
> commands (even as root), for anyone able to write .cf files/rules.

MITRE has assigned CVE-2019-19920 for this issue itself. As your patch
adresses both the vulnerability and the compatibility I'm still just
for distinction, I'm cloning this bug accordingly (but patch can close
then both bugs).

https://marc.info/?l=spamassassin-users=157668107325768=2
https://marc.info/?l=spamassassin-users=157668305026635=2

Regards,
Salvatore

Bug#947178: RFS: dmidecode/3.2-3 -- SMBIOS/DMI table decoder

2019-12-22 Thread Jörg Frings-Fürst

Hello Adam,

many thanks for your review.

Am Sonntag, den 22.12.2019, 20:21 +0100 schrieb Adam Borowski:
> On Sun, Dec 22, 2019 at 04:23:14PM +0100, Jörg Frings-Fürst wrote:
> >Package name: dmidecode
> >Version : 3.2-3
> > Changes since the last upload:
> > 
> >* Fix Scan only /dev/mem for entry point on x86 (Closes:
> > #946911):
> >  - New debian/patches/0140-Fix_scan_entry_point.patch (Cherry
> > picked from
> >upstream Commit e12ec26e19e02281d3e7258c3aabb88a5cf5ec1d.
> >* Declare compliance with Debian Policy 4.4.1.2 (No changes
> > needed).
> >* Add Smoketest:
> >  - New debian/tests/control.
> >* Switch to debhelper-compat:
> >  - debian/control: Replace debhelper with debhelper-compat.
> >  - Remove debian/compat.
> >* debian/control: Add Rules-Requires-Root.
> >* Refresh debian/copyright.
> 
> Alas, fails autopkgtest:
> Preparing to unpack .../binaries/./dmidecode.deb ...
> Unpacking dmidecode (3.2-3) ...
> Setting up dmidecode (3.2-3) ...
> Setting up autopkgtest-satdep (0) ...
> (Reading database ... 9539 files and directories currently
> installed.)
> Removing autopkgtest-satdep (0) ...
> autopkgtest [20:18:30]: test command1: dmidecode -V
> autopkgtest [20:18:30]: test command1: [---
> bash: dmidecode: command not found
> autopkgtest [20:18:30]: test command1: ---]
> autopkgtest [20:18:30]: test command1:  - - - - - - - - - - results -
> - - - - - - - - -
> command1 FAIL non-zero exit status 127
> 
> Which is because of dmidecode living in sbin.  As -V requires no
> privileges,
> you can run ｢/usr/sbin/dmidecove -V｣ without bothering about root.
> 

I use now /usr/sbin/dmidecode -V. Uploaded to mentors and into git.
> 
> Meow!


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#936091: fixed in pyaff4 0.27-1

2019-12-22 Thread Scott Kitterman

On Sunday, December 22, 2019 2:32:32 PM EST Scott Kitterman wrote:
> For some reason, 0.27-1 isn't in the archive, so I've reopened the bug.

Nevermind.  I missed the source package name change.

Scott K

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

Bug#947188: RFS: ipmiutil/3.1.5-1 -- IPMI management utilities

2019-12-22 Thread Jörg Frings-Fürst

Hallo Adam,

many thanks for your review.

Am Sonntag, den 22.12.2019, 20:17 +0100 schrieb Adam Borowski:
> On Sun, Dec 22, 2019 at 06:38:55PM +0100, Jörg Frings-Fürst wrote:
> >Package name: ipmiutil
> >Version : 3.1.5-1
> > Changes since the last upload:
> > 
> >* New upstream release:
> >  - Refresh debian/patches/0105-typo.patch.
> >* debian/contol:
> >  - Add anacron to Depends.
> >* Switch to debhelper-compat:
> >  - debian/control: change to debhelper-compat (=12).
> >  - remove debian/compat.
> >* Declare compliance with Debian Policy 4.4.1.2 (No changes
> > needed).
> >* debian/control:
> >  - Add Rules-Requires-Root: no.
> >* debian/rules:
> >  - Remove useless man pages.
> >* Add Smoketest:
> >  - New debian/tests/control.
> 
> Alas, it fails autopkgtests:
> autopkgtest [20:15:22]: test command1: ipmiutil sel -?
> autopkgtest [20:15:22]: test command1: [---
> ipmiutil sel version 3.15
> Usage: ipmiutil sel [-bcdefmnprsuvwx] [-l 5] [-NUPREFTVYZ]
>-b  interpret Binary file with raw SEL data
>-c  Show canonical output with delimiters
>-d  Delete, Clears all SEL records
>-e  shows Extended sensor description if run locally
>-f  interpret File with ascii hex SEL data
>-l5 Show last 5 SEL records (reverse order)
>-r  Show uninterpreted raw SEL records in ascii hex
>-n  Show nominal/canonical output (same as -c)
>-s1 Show only Severity >= value (0,1,2,3)
>-u  use raw UTC time
>-v  Only show version information
>-w  Writes new SEL records to syslog
>-x  Display extra debug messages
>-p port  UDP Port of target system
>-N node  Nodename or IP address of target system
>-U user  Username for remote node
>-P/-R pswd  Remote Password
>-E   use password from Environment IPMI_PASSWORD
>-F   force driver type (e.g. imb, lan2)
>-J 0 use lanplus cipher suite 0: 0 thru 14, 3=default
>-T 1 use auth Type: 1=MD2, 2=MD5(default), 4=Pswd
>-V 2 use priVilege level: 2=user(default), 4=admin
>-Y   prompt for remote password
>-Z   set slave address of local MC
> ipmiutil sel, usage or help requested
> autopkgtest [20:15:23]: test command1: ---]
> autopkgtest [20:15:23]: test command1:  - - - - - - - - - - results -
> - - - - - - - - -
> command1 FAIL non-zero exit status 234
> 
> 
I have removed the test. Uploaded to mentors and into git.



> Meow!

CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#936091: fixed in pyaff4 0.27-1

2019-12-22 Thread Scott Kitterman

For some reason, 0.27-1 isn't in the archive, so I've reopened the bug.

Scott K

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

Bug#947197: ocaml-man: empty package in arch-indep builds

2019-12-22 Thread Pino Toscano

Package: ocaml-man
Version: 4.08.0-2
Severity: important
Control: affects -1 ocaml/4.08.1-5

Hi,

since the split in ocaml 4.08.0-1, ocaml-man is basically an empty
package when built in arch-indep builds. This happens most probably
because install-stamp-indep does nothing, so the generated man pages
are not copied to debian/tmp.
This also can be noticed when looking at 4.08.0-1, which was a binary
upload to NEW: since it was a full build, the man pages were copied
together with all the other files; subsequent ocaml uploads were
source-only, and thus the arch-indep builds produced empty ocaml-man
packages starting from 4.08.0-2.

Thanks,
-- 
Pino

Bug#947178: RFS: dmidecode/3.2-3 -- SMBIOS/DMI table decoder

On Sun, Dec 22, 2019 at 04:23:14PM +0100, Jörg Frings-Fürst wrote:
>Package name: dmidecode
>Version : 3.2-3

> Changes since the last upload:
> 
>* Fix Scan only /dev/mem for entry point on x86 (Closes: #946911):
>  - New debian/patches/0140-Fix_scan_entry_point.patch (Cherry picked from
>upstream Commit e12ec26e19e02281d3e7258c3aabb88a5cf5ec1d.
>* Declare compliance with Debian Policy 4.4.1.2 (No changes needed).
>* Add Smoketest:
>  - New debian/tests/control.
>* Switch to debhelper-compat:
>  - debian/control: Replace debhelper with debhelper-compat.
>  - Remove debian/compat.
>* debian/control: Add Rules-Requires-Root.
>* Refresh debian/copyright.

Alas, fails autopkgtest:
Preparing to unpack .../binaries/./dmidecode.deb ...
Unpacking dmidecode (3.2-3) ...
Setting up dmidecode (3.2-3) ...
Setting up autopkgtest-satdep (0) ...
(Reading database ... 9539 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [20:18:30]: test command1: dmidecode -V
autopkgtest [20:18:30]: test command1: [---
bash: dmidecode: command not found
autopkgtest [20:18:30]: test command1: ---]
autopkgtest [20:18:30]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 127

Which is because of dmidecode living in sbin.  As -V requires no privileges,
you can run ｢/usr/sbin/dmidecove -V｣ without bothering about root.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#947188: RFS: ipmiutil/3.1.5-1 -- IPMI management utilities

On Sun, Dec 22, 2019 at 06:38:55PM +0100, Jörg Frings-Fürst wrote:
>Package name: ipmiutil
>Version : 3.1.5-1

> Changes since the last upload:
> 
>* New upstream release:
>  - Refresh debian/patches/0105-typo.patch.
>* debian/contol:
>  - Add anacron to Depends.
>* Switch to debhelper-compat:
>  - debian/control: change to debhelper-compat (=12).
>  - remove debian/compat.
>* Declare compliance with Debian Policy 4.4.1.2 (No changes needed).
>* debian/control:
>  - Add Rules-Requires-Root: no.
>* debian/rules:
>  - Remove useless man pages.
>* Add Smoketest:
>  - New debian/tests/control.

Alas, it fails autopkgtests:
autopkgtest [20:15:22]: test command1: ipmiutil sel -?
autopkgtest [20:15:22]: test command1: [---
ipmiutil sel version 3.15
Usage: ipmiutil sel [-bcdefmnprsuvwx] [-l 5] [-NUPREFTVYZ]
   -b  interpret Binary file with raw SEL data
   -c  Show canonical output with delimiters
   -d  Delete, Clears all SEL records
   -e  shows Extended sensor description if run locally
   -f  interpret File with ascii hex SEL data
   -l5 Show last 5 SEL records (reverse order)
   -r  Show uninterpreted raw SEL records in ascii hex
   -n  Show nominal/canonical output (same as -c)
   -s1 Show only Severity >= value (0,1,2,3)
   -u  use raw UTC time
   -v  Only show version information
   -w  Writes new SEL records to syslog
   -x  Display extra debug messages
   -p port  UDP Port of target system
   -N node  Nodename or IP address of target system
   -U user  Username for remote node
   -P/-R pswd  Remote Password
   -E   use password from Environment IPMI_PASSWORD
   -F   force driver type (e.g. imb, lan2)
   -J 0 use lanplus cipher suite 0: 0 thru 14, 3=default
   -T 1 use auth Type: 1=MD2, 2=MD5(default), 4=Pswd
   -V 2 use priVilege level: 2=user(default), 4=admin
   -Y   prompt for remote password
   -Z   set slave address of local MC
ipmiutil sel, usage or help requested
autopkgtest [20:15:23]: test command1: ---]
autopkgtest [20:15:23]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 234


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#947196: mesa: "BadMatch" error on X_ShmPutImage in 24bpp; breaks openscad testsuite

2019-12-22 Thread Kristian Nielsen

Source: mesa
Version: mesa-19.3.1-2
Severity: important

Dear Maintainer,

Since upload to unstable of mesa 19.3.1-1/19.3.1-2, the openscad testsuite
breaks. This also shows up as a regression on
https://tracker.debian.org/pkg/mesa .

The root cause is the following failure to run openscad in a virtual
framebuffer. To reproduce:

$ xvfb-run -s "-screen 0 800x600x24" openscad /dev/null -o /tmp/1.png
Compiling design (CSG Products normalization)...
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 130 (MIT-SHM)
Minor opcode of failed request: 3 (X_ShmPutImage)
Serial number of failed request: 41
Current serial number in output stream: 42

(This requires that the packages "xvfb" and "openscad" are installed).
Interestingly, it does not fail when using 16 bpp:

$ xvfb-run -s "-screen 0 800x600x16" openscad /dev/null -o /tmp/1.png
Compiling design (CSG Products normalization)...
$ ls -l /tmp/1.png
-rw-r--r-- 1 root root 1948 Dec 21 23:44 /tmp/1.png

At this point I do not know the root cause of the problem (I'm happy to
follow suggested directions for debugging this further). I'm providing here
what information I have currently in case this affects migration of mesa to
testing.

That mesa 19.3.1 is the cause of the regression is based on the regression
shown by debci after upload of 19.3.1-1. It is also suggested by the similar
problem reported here:
https://stackoverflow.com/questions/59323267/x-error-of-failed-request-badmatch-on-x-shmputimage-major-opcode-130-minor

Even assuming mesa 19.3.1-1 introduces the problem, it still needs to be
determined if this is a bug in mesa, or if it is incorrect usage from
openscad code. The smaller example in the stackoverflow link might help
determine this (it shows the similar symptoms).

I can work-around the openscad test failure/regression in debci by changing
it to use 16bpp in the virtual framebuffer; this makes the entire testsuite
pass. But it would be nice to understand the root cause of the issue, in
case this affects also other usage than virtual framebuffer device (eg.
normal interactive use on X server from unstable); hence the initial
"important" severity.

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

Kernel: Linux 4.19.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect (systemd-nspawn from buster host)

Bug#947194: raxml FTCBFS: builds for the build architecture

Source: raxml
Version: 8.2.12+dfsg-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

raxml fails to cross build from source, because it does not pass cross
tools to make. The easiest way of fixing that - using dh_auto_build -
fixes this part, but raxml continues to fail, because it also uses
help2man. There are no good solutions to help2man. For that reason, this
patch leaves the help2man problem as is and only fixes the dh_auto_build
part. Here are the options for fixing help2man:

 * Stop using help2man.
 * Ship manual pages in an architecture:all package.
 * Build twice (once for help2man and once for real).
 * Extract the --help output using a script and run that instead of the
   built raxml binary.
 * Only support cross building with a nodoc profile excluing manual
   pages.

Please consider applying the attached patch as an incremental
improvement and close this bug when doing so even without fixing the
help2man part.

Helmut
diff --minimal -Nru raxml-8.2.12+dfsg/debian/changelog 
raxml-8.2.12+dfsg/debian/changelog
--- raxml-8.2.12+dfsg/debian/changelog  2019-12-16 17:54:43.0 +0100
+++ raxml-8.2.12+dfsg/debian/changelog  2019-12-22 09:02:16.0 +0100
@@ -1,3 +1,11 @@
+raxml (8.2.12+dfsg-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: Let dh_auto_build pass cross tools to make.
+(Closes: #-1)
+
+ -- Helmut Grohne   Sun, 22 Dec 2019 09:02:16 +0100
+
 raxml (8.2.12+dfsg-2) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru raxml-8.2.12+dfsg/debian/rules 
raxml-8.2.12+dfsg/debian/rules
--- raxml-8.2.12+dfsg/debian/rules  2019-12-16 15:03:35.0 +0100
+++ raxml-8.2.12+dfsg/debian/rules  2019-12-22 09:02:14.0 +0100
@@ -31,7 +31,7 @@
 override_dh_auto_build:
mkdir -p $(BINDIR)
set -e ; for mfile in $(MFILES); do \
-   $(MAKE) -f $${mfile} $(MFLAGS); \
+   dh_auto_build --buildsystem=makefile -- -f $${mfile} $(MFLAGS); \
curexe=`ls $(exe)* | head -n 1` ; \
if [ -e $(BINDIR)/$${curexe} ] ; then \
echo " ERROR: $${curexe} was created before!!" && false ; \

Bug#947193: please coordinate the provider of crypt.h

Package: musl-dev,libcrypt1-dev
Severity: important
User: helm...@debian.org
Usertags: rebootstrap

Both musl-dev and libcrypt1-dev contain crypt.h. I acknowledge that this
does not cause a file conflict, because musl's lives on a multiarch
path, but we have two conflicting headers in the search path and what
happens from there is pretty much undefined. It also happens that musl
ships an empty libcrypt.a as the main libc object includes all the
functions. So linking both musl and libxcrypt's libcrypt would be broken
as well. Quite obviously, there should be one and only one provider of
this functionality.

I see two options:

1. Retain status quo

   Before the introduction of libxcrypt, musl was providing these
   functions and continues to do so. libxcrypt should simply not build
   for musl-linux-any architectures. Thus libxcrypt would become a
   glibc-only thingy. Doing so is straight forward. You simply change
   the architecture fields of binary packages from "any" to
   "gnu-any-any". That means that libxcrypt only becomes a thing for
   glibc architectures.

2. Move crypt functionality to libxcrypt

   musl should stop building and including libcrypt and crypt.h
   functionality. It seems that musl upstream is not prepared for doing
   this. Work is needed on the musl side for doing this.

I don't immediately see which of these options is "better". Both of them
have advantages and disadvantages. For instances, the first option means
more differences between musl and glibc, which tends to make porting
harder. On the other hand, the first option is vastly simpler to
implement. Likely, this question should be discussed with upstreams as
well.

I defer this question to the respective maintainers and simply report
the problem here. Please coordinate a solution and reassign the bug as
appropriate.

Helmut

Bug#947195: qalculate-gtk FTCBFS: unsatisfiable Build-Depends: libxml-parser-perl