date:20191012

Control: tags 915749 + patch
Control: tags 937460 + patch


Dear maintainer,

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

I've uploaded it directly to sid as it fixes an RC bug more than 9 months old.

I tried to build from the DPMT git, but for some reason the patch was always
gettin rejected, while it works out of simple debuild..

Regards.

diff -Nru pyiosxr-0.52/debian/changelog pyiosxr-0.52/debian/changelog
--- pyiosxr-0.52/debian/changelog	2017-11-12 14:18:39.0 -0500
+++ pyiosxr-0.52/debian/changelog	2019-10-13 00:56:59.0 -0400
@@ -1,3 +1,12 @@
+pyiosxr (0.52-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches/675bba17d3af7de14d0db52c01a83b7cc163e59e.patch
+- fix compatibility with pip >= 10; Closes: #915749
+  * Drop python2 support; Closes: #937460
+
+ -- Sandro Tosi   Sun, 13 Oct 2019 00:56:59 -0400
+
 pyiosxr (0.52-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru pyiosxr-0.52/debian/control pyiosxr-0.52/debian/control
--- pyiosxr-0.52/debian/control	2017-11-12 14:18:39.0 -0500
+++ pyiosxr-0.52/debian/control	2019-10-13 00:56:28.0 -0400
@@ -4,32 +4,18 @@
 Maintainer: Vincent Bernat 
 Uploaders: Debian Python Modules Team 
 Build-Depends: debhelper (>= 9), dh-python,
-   python-all, python3-all,
-   python-pexpect, python3-pexpect,
-   python-setuptools, python3-setuptools,
-   python-pip, python3-pip,
-   python-mock, python3-mock,
-   python-lxml, python3-lxml,
-   python-netmiko, python3-netmiko,
+   python3-all,
+   python3-pexpect,
+   python3-setuptools,
+   python3-pip,
+   python3-mock,
+   python3-lxml,
+   python3-netmiko,
 Standards-Version: 4.1.1
 Homepage: https://github.com/fooelisa/pyiosxr/
 Vcs-Git: https://anonscm.debian.org/git/python-modules/packages/pyiosxr.git
 Vcs-Browser: https://anonscm.debian.org/cgit/python-modules/packages/pyiosxr.git
 
-Package: python-pyiosxr
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends},
-Recommends: ${python:Recommends}
-Suggests: ${python:Suggests}
-XB-Python-Egg-Name: pyIOSXR
-Description: Python API for Cisco IOX-XR network devices (Python 2)
- This package provides a Python API to connect to network devices
- running Cisco IOS-XR. It can retrieve several information like
- interfaces. It can also modify the current configuration and execute
- arbitrary commands.
- .
- This package contains the Python 2 version.
-
 Package: python3-pyiosxr
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends},
diff -Nru pyiosxr-0.52/debian/patches/675bba17d3af7de14d0db52c01a83b7cc163e59e.patch pyiosxr-0.52/debian/patches/675bba17d3af7de14d0db52c01a83b7cc163e59e.patch
--- pyiosxr-0.52/debian/patches/675bba17d3af7de14d0db52c01a83b7cc163e59e.patch	1969-12-31 19:00:00.0 -0500
+++ pyiosxr-0.52/debian/patches/675bba17d3af7de14d0db52c01a83b7cc163e59e.patch	2019-10-13 00:29:26.0 -0400
@@ -0,0 +1,31 @@
+From b63443b4d09890a1de2b64b805ec4104a3ae1c36 Mon Sep 17 00:00:00 2001
+From: Patrick Ogenstad 
+Date: Sun, 15 Apr 2018 06:31:57 +0200
+Subject: [PATCH] Fix installation issue with pip 10, test on py3.6
+
+---
+ setup.py| 9 ++---
+ 2 files changed, 3 insertions(+), 7 deletions(-)
+
+diff --git a/setup.py b/setup.py
+index b1f7568..290911b 100644
+--- a/setup.py
 b/setup.py
+@@ -18,15 +18,10 @@
+ # the License.
+ 
+ from setuptools import setup, find_packages
+-from pip.req import parse_requirements
+-import uuid
+ 
+-# parse_requirements() returns generator of pip.req.InstallRequirement objects
+-install_reqs = parse_requirements('requirements.txt', session=uuid.uuid1())
+ 
+-# reqs is a list of requirement
+-# e.g. ['django==1.5.1', 'mezzanine==1.4.6']
+-reqs = [str(ir.req) for ir in install_reqs]
++with open("requirements.txt", "r") as fs:
++reqs = [r for r in fs.read().splitlines() if (len(r) > 0 and not r.startswith("#"))]
+ 
+ version = '0.52'
+ 
diff -Nru pyiosxr-0.52/debian/patches/series pyiosxr-0.52/debian/patches/series
--- pyiosxr-0.52/debian/patches/series	1969-12-31 19:00:00.0 -0500
+++ pyiosxr-0.52/debian/patches/series	2019-10-13 00:46:25.0 -0400
@@ -0,0 +1 @@
+675bba17d3af7de14d0db52c01a83b7cc163e59e.patch
diff -Nru pyiosxr-0.52/debian/rules pyiosxr-0.52/debian/rules
--- pyiosxr-0.52/debian/rules	2017-11-12 14:18:39.0 -0500
+++ pyiosxr-0.52/debian/rules	2019-10-13 00:56:34.0 -0400
@@ -2,4 +2,4 @@
 
 export PYBUILD_NAME=pyiosxr
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild

Bug#938547: sphinx-testing: diff for NMU version 0.8.1-1.1

Control: tags 938547 + patch
Control: tags 938547 + pending


Dear maintainer,

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

Regards.

diff -Nru sphinx-testing-0.8.1/debian/changelog sphinx-testing-0.8.1/debian/changelog
--- sphinx-testing-0.8.1/debian/changelog	2019-01-04 19:04:36.0 -0500
+++ sphinx-testing-0.8.1/debian/changelog	2019-10-13 00:07:12.0 -0400
@@ -1,3 +1,10 @@
+sphinx-testing (0.8.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938547
+
+ -- Sandro Tosi   Sun, 13 Oct 2019 00:07:12 -0400
+
 sphinx-testing (0.8.1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru sphinx-testing-0.8.1/debian/control sphinx-testing-0.8.1/debian/control
--- sphinx-testing-0.8.1/debian/control	2019-01-04 19:04:36.0 -0500
+++ sphinx-testing-0.8.1/debian/control	2019-10-13 00:07:00.0 -0400
@@ -4,15 +4,6 @@
 Maintainer: Kouhei Maeda 
 Build-Depends: debhelper (>= 9),
dh-python,
-   python-all,
-   python-setuptools,
-   python-nose,
-   python-flake8,
-   python-mock,
-   python-sphinx,
-   python-six,
-   python-jinja2,
-   python-pygments,
python3-all,
python3-setuptools,
python3-nose,
@@ -25,16 +16,6 @@
 Standards-Version: 4.3.0
 Homepage: http://bitbucket.org/tk0miya/sphinx-testing
 
-Package: python-sphinx-testing
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends},
- python-sphinx (>= 0.6),
- python-six
-Description: testing utility for Sphinx extensions
- sphinx-testing provides testing utility classes and functions for Sphinx
- extensions.
- See also pydoc sphinx_testing.
-
 Package: python3-sphinx-testing
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends},
diff -Nru sphinx-testing-0.8.1/debian/rules sphinx-testing-0.8.1/debian/rules
--- sphinx-testing-0.8.1/debian/rules	2019-01-04 18:28:30.0 -0500
+++ sphinx-testing-0.8.1/debian/rules	2019-10-13 00:07:09.0 -0400
@@ -9,7 +9,7 @@
 export PYBUILD_TEST_NOSE=1
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_installchangelogs:
 	dh_installchangelogs CHANGES.rst

Bug#891877: Have either synaptic removed or have it rebuilt with libgtk3-perl in it recommends.

2019-10-12 Thread intrigeri

Hi,

shirish शिरीष:
> Dunno if this is the right place to discuss it or not. Integri asked
> hence sharing.

Thanks for caring!

> There is also another package synaptic which still uses libgtk2-removal.

> $ aptitude why libgtk2-perl
> i   task-mate-desktop Recommends synaptic
> i A synaptic  Recommends libgtk2-perl (>= 1:1.130)

I don't particularly know Synaptic nor debconf so take all this with
a grain of salt: I might have misunderstood something fundamental.

AFAICT:

 - The synaptic codebase does not use libgtk2-perl directly.
 - This Recommends is historically in place so that the user
   can benefit from debconf's GNOME frontend.
 - debconf's GNOME frontend has been ported to libgtk3-perl 1.5 years
   ago (first released in 1.5.66):
   https://salsa.debian.org/pkg-debconf/debconf/commit/0250616b

Hence, the current "Recommends: libgtk2-perl" has been useless
for a year an a half. With libgtk2-perl being phased out,
this Recommends is now a more serious problem. On top of that,
a suitable dependency on libgtk3-perl is missing.

Jeremy Bicha filed #891877 a while ago, requesting that Synaptic's
dependencies are updated accordingly. I believe the actions Jeremy
suggested on #891877 will solve the problem shirish is raising here,
improve the life of Synaptic's users, and make it clearer what is the
status of libgtk2-perl in the archive.

Thoughts?

(Oh my, so many words for a bug that can be fixed by s/2/3/ in one
single place :)

Cheers,
-- 
intrigeri

Bug#938245: python-urlobject: diff for NMU version 2.4.0-1.1

Control: tags 938245 + patch
Control: tags 938245 + pending


Dear maintainer,

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

Regards.

diff -Nru python-urlobject-2.4.0/debian/changelog python-urlobject-2.4.0/debian/changelog
--- python-urlobject-2.4.0/debian/changelog	2016-07-05 10:57:17.0 -0400
+++ python-urlobject-2.4.0/debian/changelog	2019-10-12 23:56:03.0 -0400
@@ -1,3 +1,10 @@
+python-urlobject (2.4.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938245
+
+ -- Sandro Tosi   Sat, 12 Oct 2019 23:56:03 -0400
+
 python-urlobject (2.4.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru python-urlobject-2.4.0/debian/control python-urlobject-2.4.0/debian/control
--- python-urlobject-2.4.0/debian/control	2016-07-05 10:53:14.0 -0400
+++ python-urlobject-2.4.0/debian/control	2019-10-12 23:55:37.0 -0400
@@ -5,26 +5,12 @@
 Homepage: http://github.com/zacharyvoase/urlobject
 Build-Depends:
 dh-python,
-python-setuptools (>= 0.6.24),
 python3-setuptools (>= 0.6.24),
-python-all (>= 2.6.6-3),
-python3-all, python-sphinx (>= 1.0.7+dfsg) | python3-sphinx,
+python3-all, python3-sphinx,
 debhelper (>= 9),
-python-six, python3-six
+python3-six
 Standards-Version: 3.9.5
 
-Package: python-urlobject
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}, python-six, ${sphinxdoc:Depends}
-Provides: ${python:Provides}
-Description: utility class for manipulating URLs.
- URLObject is a utility class for manipulating URLs. The latest
- incarnation of this library builds upon the ideas of its
- predecessor, but aims for a clearer API, focusing on proper
- method names over operator overrides. It's also being developed
- from the ground up in a test-driven manner, and has full
- Sphinx documentation.
-
 Package: python3-urlobject
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}, python3-six, ${sphinxdoc:Depends}
diff -Nru python-urlobject-2.4.0/debian/python-urlobject.docs python-urlobject-2.4.0/debian/python-urlobject.docs
--- python-urlobject-2.4.0/debian/python-urlobject.docs	2016-07-05 10:53:14.0 -0400
+++ python-urlobject-2.4.0/debian/python-urlobject.docs	1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-doc/.build/html
-README.md
diff -Nru python-urlobject-2.4.0/debian/rules python-urlobject-2.4.0/debian/rules
--- python-urlobject-2.4.0/debian/rules	2016-07-05 10:53:14.0 -0400
+++ python-urlobject-2.4.0/debian/rules	2019-10-12 23:55:51.0 -0400
@@ -1,10 +1,9 @@
 #!/usr/bin/make -f
 
-export PYBUILD_DESTDIR_python2=debian/python-urlobject/
 export PYBUILD_DESTDIR_python3=debian/python3-urlobject/
 
 %:
-	dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
+	dh $@ --with python3,sphinxdoc --buildsystem=pybuild
 
 override_dh_auto_build:
 	dh_auto_build -v

Bug#937804: python-h2: diff for NMU version 3.0.1-4.1

Control: tags 937804 + patch
Control: tags 937804 + pending


Dear maintainer,

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

Regards.

diff -Nru python-h2-3.0.1/debian/changelog python-h2-3.0.1/debian/changelog
--- python-h2-3.0.1/debian/changelog	2018-03-30 10:30:24.0 -0400
+++ python-h2-3.0.1/debian/changelog	2019-10-12 23:45:46.0 -0400
@@ -1,3 +1,10 @@
+python-h2 (3.0.1-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937804
+
+ -- Sandro Tosi   Sat, 12 Oct 2019 23:45:46 -0400
+
 python-h2 (3.0.1-4) unstable; urgency=medium
 
   * Update Vcs-* to point to salsa.d.o
diff -Nru python-h2-3.0.1/debian/control python-h2-3.0.1/debian/control
--- python-h2-3.0.1/debian/control	2018-03-30 10:30:24.0 -0400
+++ python-h2-3.0.1/debian/control	2019-10-12 23:45:33.0 -0400
@@ -2,24 +2,14 @@
 Section: python
 Priority: optional
 Maintainer: Sebastien Delafond 
-Build-Depends: debhelper (>= 9), dh-python, python-all, python-setuptools,
- python-pytest, python-hyperframe (>= 5.0), python-hpack, python-enum34,
- python-hypothesis, python3-all, python3-setuptools, python3-pytest,
+Build-Depends: debhelper (>= 9), dh-python,
+ python3-all, python3-setuptools, python3-pytest,
  python3-hypothesis, python3-hyperframe, python3-hpack
 Standards-Version: 4.1.3
 Homepage: https://pypi.python.org/pypi/h2
 Vcs-Git: https://salsa.debian.org/debian/python-h2.git
 Vcs-Browser: https://salsa.debian.org/debian/python-h2
 
-Package: python-h2
-Architecture: all
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
-Description: Pure-Python HTTP/2 State-Machine based protocol implementation in Python
- This module contains a pure-Python HTTP/2 of a HTTP/2 protocol
- stack. It’s written from the ground up to be embeddable in whatever
- program you choose to use, ensuring that you can speak HTTP/2
- regardless of your programming paradigm.
-
 Package: python3-h2
 Architecture: all
 Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}
diff -Nru python-h2-3.0.1/debian/rules python-h2-3.0.1/debian/rules
--- python-h2-3.0.1/debian/rules	2018-03-30 10:30:24.0 -0400
+++ python-h2-3.0.1/debian/rules	2019-10-12 23:45:43.0 -0400
@@ -6,7 +6,7 @@
 export HYPOTHESIS_DATABASE_FILE = $(CURDIR)/debian/hypothesis
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_installchangelogs:
 	dh_installchangelogs HISTORY.rst

Bug#896358: python-flask-rdf: diff for NMU version 0.2.1-1.1

Control: tags 896358 + patch
Control: tags 896385 + patch
Control: tags 937760 + patch


Dear maintainer,

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

I've uploaded directly to unstable as it fixes 2 RC bugs opened for more than a
year.

Regards.

diff -Nru python-flask-rdf-0.2.1/debian/changelog python-flask-rdf-0.2.1/debian/changelog
--- python-flask-rdf-0.2.1/debian/changelog	2018-07-08 12:12:13.0 -0400
+++ python-flask-rdf-0.2.1/debian/changelog	2019-10-12 23:34:58.0 -0400
@@ -1,3 +1,11 @@
+python-flask-rdf (0.2.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937760, #896385
+  * add python3-rdflib to Depends; Closes: #896358
+
+ -- Sandro Tosi   Sat, 12 Oct 2019 23:34:58 -0400
+
 python-flask-rdf (0.2.1-1) unstable; urgency=medium
 
   * New upstream version 0.2.1
diff -Nru python-flask-rdf-0.2.1/debian/control python-flask-rdf-0.2.1/debian/control
--- python-flask-rdf-0.2.1/debian/control	2018-07-08 12:00:19.0 -0400
+++ python-flask-rdf-0.2.1/debian/control	2019-10-12 23:34:01.0 -0400
@@ -4,42 +4,21 @@
 Priority: optional
 Build-Depends: debhelper (>= 11),
dh-python,
-   python-all,
python3-all,
-   python-setuptools,
python3-setuptools,
-   python-mimeparse (>= 0.1.4),
python3-mimeparse,
-   python-rdflib,
python3-rdflib
 Standards-Version: 4.1.4
 Vcs-Browser: https://salsa.debian.org/irl/python-flask-rdf
 Vcs-Git: https://salsa.debian.org/irl/python-flask-rdf.git
 Homepage: https://pypi.python.org/pypi/flask_rdf
 
-Package: python-flask-rdf
-Architecture: all
-Depends: ${python:Depends},
- ${misc:Depends},
- python-mimeparse (>= 0.1.4)
-Description: Flask decorator to output RDF using content negotiation (Python 2)
- Apply the @flask_rdf decorator to a view function and return an rdflib
- Graph object. Flask_rdf will automatically format it into an RDF output
- format, depending on what the request’s Accept header says. If the view
- function returns something besides an rdflib graph, it will be passed
- through without modification.
- .
- Custom formats can be registered easily. After registering the new
- serializer with rdflib’s plugin support, use the decide_format method to
- register a new mimetype request to use the new formatter.
- .
- This package works with Python versions 2.x.
-
 Package: python3-flask-rdf
 Architecture: all
 Depends: ${python3:Depends},
  ${misc:Depends},
- python3-mimeparse
+ python3-mimeparse,
+ python3-rdflib
 Description: Flask decorator to output RDF using content negotiation (Python 3)
  Apply the @flask_rdf decorator to a view function and return an rdflib
  Graph object. Flask_rdf will automatically format it into an RDF output
diff -Nru python-flask-rdf-0.2.1/debian/rules python-flask-rdf-0.2.1/debian/rules
--- python-flask-rdf-0.2.1/debian/rules	2018-07-08 11:49:24.0 -0400
+++ python-flask-rdf-0.2.1/debian/rules	2019-10-12 23:30:59.0 -0400
@@ -1,20 +1,4 @@
 #!/usr/bin/make -f
 
-PYVERS=$(shell pyversions -sv)
-PY3VERS=$(shell py3versions -sv)
-
 %:
-	dh $@ --with python2,python3
-
-override_dh_auto_install:
-	dh_auto_install
-
-	set -e && for pyvers in $(PYVERS); do \
-		python$$pyvers setup.py install --install-layout=deb \
-		--root $(CURDIR)/debian/python-flask-rdf; \
-		done
-
-	set -e && for pyvers in $(PY3VERS); do \
-		python$$pyvers setup.py install --install-layout=deb \
-		--root $(CURDIR)/debian/python3-flask-rdf; \
-		done
+	dh $@ --with python3 --buildsystem=pybuild

Bug#941774: lintian: False positive for symbols-file-contains-current-version-with-debian-revision

2019-10-12 Thread Ross Vandegrift

On Sat, Oct 05, 2019 at 02:30:30AM -0400, Scott Kitterman wrote:
>  (optional=templinst|arch=!amd64 !arm64 
> !x32)_ZN8nitrokey5proto17ResponseDissectorILNS0_9CommandIDE0ERKNS0_14DeviceResponseILS2_0ENS0_7stick109GetStatus15ResponsePayload24status_translate_commandB5cxx11Ei@Base
>  3.5
> 
>  No dash anywhere.  In fact, in only dashes in the entire symbols file
>  are in the first three lines of the file:

I'm seeing a similar false positive:

E: libephysics1: symbols-file-contains-current-version-with-debian-revision on 
symbol 
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPcEEvT_S7_St20forward_iterator_tag@Base

Though in my case, there's no such symbol in the symbols file.  This is from a
local run of lintian 2.25.0, this version of libephysics1 hasn't been uploaded
yet.

Ross

Bug#937713: python-dnsq: diff for NMU version 1.1.2-1.1

Control: tags 937713 + patch
Control: tags 937713 + pending


Dear maintainer,

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

Regards.

diff -Nru python-dnsq-1.1.2/debian/changelog python-dnsq-1.1.2/debian/changelog
--- python-dnsq-1.1.2/debian/changelog	2014-03-11 11:16:25.0 -0400
+++ python-dnsq-1.1.2/debian/changelog	2019-10-12 23:18:04.0 -0400
@@ -1,3 +1,10 @@
+python-dnsq (1.1.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937713
+
+ -- Sandro Tosi   Sat, 12 Oct 2019 23:18:04 -0400
+
 python-dnsq (1.1.2-1) unstable; urgency=medium
 
   * New upstream version (now with licensing in upstream tarball)
diff -Nru python-dnsq-1.1.2/debian/control python-dnsq-1.1.2/debian/control
--- python-dnsq-1.1.2/debian/control	2014-03-11 11:15:43.0 -0400
+++ python-dnsq-1.1.2/debian/control	2019-10-12 23:17:55.0 -0400
@@ -5,8 +5,6 @@
 Build-Depends:
  debhelper (>= 9),
  dh-python,
- python-all (>= 2.6.6-3~),
- python-setuptools,
  python3-all,
  python3-setuptools
 Homepage: https://github.com/mailgun/dnsq
@@ -16,19 +14,6 @@
 Vcs-Git: git://anonscm.debian.org/collab-maint/python-dnsq.git
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/python-dnsq.git
 
-Package: python-dnsq
-Architecture: all
-Depends: 
- ${python:Depends},
- ${misc:Depends},
- python-dnspython,
- python-expiringdict
-Description: Python DNS query tool
- dnsq is a high-level wrapper around dnspython for making caching DNS
- queries from Python.
- .
- This is the Python 2 version of this package.
-
 Package: python3-dnsq
 Architecture: all
 Depends: 
diff -Nru python-dnsq-1.1.2/debian/rules python-dnsq-1.1.2/debian/rules
--- python-dnsq-1.1.2/debian/rules	2014-03-11 11:15:43.0 -0400
+++ python-dnsq-1.1.2/debian/rules	2019-10-12 23:18:01.0 -0400
@@ -2,4 +2,4 @@
 export PYBUILD_NAME=dnsq
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild

Bug#937098: myhdl: diff for NMU version 0.10-2.1

Control: tags 937098 + patch
Control: tags 937098 + pending


Dear maintainer,

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

Regards.

diff -Nru myhdl-0.10/debian/changelog myhdl-0.10/debian/changelog
--- myhdl-0.10/debian/changelog	2018-12-04 02:24:43.0 -0500
+++ myhdl-0.10/debian/changelog	2019-10-12 23:08:02.0 -0400
@@ -1,3 +1,10 @@
+myhdl (0.10-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937098
+
+ -- Sandro Tosi   Sat, 12 Oct 2019 23:08:02 -0400
+
 myhdl (0.10-2) unstable; urgency=medium
 
   * debian/control:
diff -Nru myhdl-0.10/debian/control myhdl-0.10/debian/control
--- myhdl-0.10/debian/control	2018-12-04 02:24:43.0 -0500
+++ myhdl-0.10/debian/control	2019-10-12 23:07:03.0 -0400
@@ -3,29 +3,13 @@
 Priority: optional
 Maintainer: Steffen Moeller 
 Uploaders: Ruben Undheim 
-Build-Depends: debhelper (>= 11), dh-python, python-all, python-setuptools, python3-all, python3-setuptools
+Build-Depends: debhelper (>= 11), dh-python, python3-all, python3-setuptools
 Build-Depends-Indep: python-sphinx, python3-sphinx
 Standards-Version: 4.2.1
 Homepage: http://www.myhdl.org
 Vcs-Git: https://salsa.debian.org/python-team/modules/myhdl.git
 Vcs-Browser: https://salsa.debian.org/python-team/modules/myhdl
 
-Package: python-myhdl
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Recommends: myhdl-cosimulation
-Suggests: myhdl-doc
-Section: python
-Description: Hardware description language for Python (Python 2)
- MyHDL turns Python into a hardware description and verification language,
- providing hardware engineers with the power of the Python ecosystem.
- .
- Python can then be used as an event-driven simulator using Python decorators
- actively to specify what corresponds to 'processes' in Verilog / VHDL and
- thereby achieve concurrency.
- .
- This package installs the library for Python 2.
-
 Package: python3-myhdl
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru myhdl-0.10/debian/rules myhdl-0.10/debian/rules
--- myhdl-0.10/debian/rules	2018-12-04 02:24:43.0 -0500
+++ myhdl-0.10/debian/rules	2019-10-12 23:08:02.0 -0400
@@ -6,7 +6,7 @@
 export PYBUILD_NAME=myhdl
 
 %:
-	dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
+	dh $@ --with python3,sphinxdoc --buildsystem=pybuild
 
 
 override_dh_auto_build:
@@ -21,9 +21,9 @@
 	  echo "I: Forgot to clean up prior to build? Otherwise investigate existence of debian/myhdl-cosimulation/usr/share/myhdl/cosimulation"; \
 	  rm -r debian/myhdl-cosimulation/usr/share/myhdl/cosimulation; \
 	fi
-	mv debian/python-myhdl/usr/share/myhdl/cosimulation debian/myhdl-cosimulation/usr/share/myhdl/
+	cp -a $(CURDIR)/cosimulation debian/myhdl-cosimulation/usr/share/myhdl/
 	# Remove empty dirs:
-	rmdir --ignore-fail-on-non-empty debian/python-myhdl/usr/share/myhdl debian/python3-myhdl/usr/share/myhdl
+	rmdir --ignore-fail-on-non-empty debian/python3-myhdl/usr/share/myhdl
 
 override_dh_installdocs:
 	dh_installdocs

Bug#938169: python-setuptools-git: diff for NMU version 1.2-2.1

Control: tags 938169 + patch
Control: tags 938169 + pending


Dear maintainer,

I've prepared an NMU for python-setuptools-git (versioned as 1.2-2.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru python-setuptools-git-1.2/debian/changelog python-setuptools-git-1.2/debian/changelog
--- python-setuptools-git-1.2/debian/changelog	2018-08-14 12:18:48.0 -0400
+++ python-setuptools-git-1.2/debian/changelog	2019-10-12 22:54:59.0 -0400
@@ -1,3 +1,10 @@
+python-setuptools-git (1.2-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938169
+
+ -- Sandro Tosi   Sat, 12 Oct 2019 22:54:59 -0400
+
 python-setuptools-git (1.2-2) unstable; urgency=medium
 
   * Correct python-setuptools dependency of Python 3 variant
diff -Nru python-setuptools-git-1.2/debian/control python-setuptools-git-1.2/debian/control
--- python-setuptools-git-1.2/debian/control	2018-08-14 12:18:48.0 -0400
+++ python-setuptools-git-1.2/debian/control	2019-10-12 22:54:17.0 -0400
@@ -2,29 +2,12 @@
 Section: python
 Priority: optional
 Maintainer: Laszlo Boszormenyi (GCS) 
-Build-Depends: debhelper (>= 11), dh-python, python3-docutils, python3-pygments, python-setuptools, python3-setuptools, python-all (>= 2.6.6-3~), python3-all (>= 3.1.2-7~), git
+Build-Depends: debhelper (>= 11), dh-python, python3-docutils, python3-pygments, python3-setuptools, python3-all (>= 3.1.2-7~), git
 Standards-Version: 4.1.5
 Homepage: https://github.com/wichert/setuptools-git
 X-Python-Version: >= 2.6
 X-Python3-Version: >= 3.0
 
-Package: python-setuptools-git
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}, python-setuptools, git
-Provides: ${python:Provides}
-XB-Python-Version: ${python:Versions}
-Description: plugin for setuptools that enables git integration
- This is a plugin for setup tools that enables Git integration.  Once
- installed, Setuptools can be told to include in a module distribution
- all the files tracked by git.  This is an alternative to explicit
- inclusion specifications with MANIFEST.in.
- .
- This package was formerly known as gitlsfiles.  The name change is the
- result of an effort by the setuptools plugin developers to provide a
- uniform naming convention.
- .
- This is the Python 2 version of the package.
-
 Package: python3-setuptools-git
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}, python3-setuptools, git
diff -Nru python-setuptools-git-1.2/debian/python-setuptools-git.docs python-setuptools-git-1.2/debian/python-setuptools-git.docs
--- python-setuptools-git-1.2/debian/python-setuptools-git.docs	2013-02-12 12:17:10.0 -0500
+++ python-setuptools-git-1.2/debian/python-setuptools-git.docs	1969-12-31 19:00:00.0 -0500
@@ -1,3 +0,0 @@
-AUTHORS.txt
-README.rst
-README.txt
diff -Nru python-setuptools-git-1.2/debian/python-setuptools-git.install python-setuptools-git-1.2/debian/python-setuptools-git.install
--- python-setuptools-git-1.2/debian/python-setuptools-git.install	2012-09-14 06:26:14.0 -0400
+++ python-setuptools-git-1.2/debian/python-setuptools-git.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-/usr/lib/python2*
diff -Nru python-setuptools-git-1.2/debian/rules python-setuptools-git-1.2/debian/rules
--- python-setuptools-git-1.2/debian/rules	2018-08-14 12:18:48.0 -0400
+++ python-setuptools-git-1.2/debian/rules	2019-10-12 22:54:50.0 -0400
@@ -6,17 +6,16 @@
 
 export GIT_CONFIG=$(CURDIR)/debian/gitconfig
 
-PYTHON2=$(shell pyversions -vr)
 PYTHON3=$(shell py3versions -vr)
 
 %:
-	dh $@ --with python2,python3
+	dh $@ --with python3 --buildsystem=pybuild
 
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
 test-python%:
 	python$* setup.py test -vv || true
 
-override_dh_auto_test: $(PYTHON2:%=test-python%) $(PYTHON3:%=test-python%)
+override_dh_auto_test: $(PYTHON3:%=test-python%)
 endif
 
 build-python%:

Bug#942250: RFS

2019-10-12 Thread Antonio Russo

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

Dear mentors,

I am looking for a sponsor for an extension to Inkscape, TeX Text [1],
that allows the insertion of LaTeX code into an Inkscape document, and
the subsequent editing of it at later times.  Please see my ITP [2],
mentors upload [3,4], and salsa packaging [5].

There are a couple outstanding issues, most importantly I don't understand
how Inkscape is getting dh_python3 to py3compile its extensions (and not
mine). I'd appreciate any help on that end, too.

Thank you,
Antonio Russo

[1] https://textext.github.io/textext
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942249
[3] https://mentors.debian.net/package/inkscape-ext-textext
[4] dget -x 
https://mentors.debian.net/debian/pool/main/i/inkscape-ext-textext/inkscape-ext-textext_0.12.0~git32-gfebf8f7-1.dsc
[5] https://salsa.debian.org/aerusso-guest/textext/

Bug#942246: src:sleepyhead: SleepyHead appears to have been replaced by OSCAR

2019-10-12 Thread Sergio Durigan Junior

On Saturday, October 12 2019, Adam Conrad wrote:

> According to a statement from the sleepyhead author[1] and the homepage
> for the OSCAR fork[2], sleepyhead development is dead, but continues on
> with OSCAR.  It's likely worth investigating packaging OSCAR, including
> a sleepyhead->oscar transitional package.
>
> ... Adam
>
> [1] https://jedimark.net/2019/02/08/sleepyhead-project-shutdown/
> [2] https://www.sleepfiles.com/OSCAR/

Thanks for the email.

I have already uploaded OSCAR; it's in NEW right now, waiting to be
reviewed.  I confess I hadn't thought about a transitional package, but
we can do that.  I will ask for the removal of sleepyhead from the
archives once OSCAR is accepted.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/

signature.asc
Description: PGP signature

Bug#942249: ITP: inkscape-ext-textext -- Re-editable LaTeX graphics for Inkscape

2019-10-12 Thread Antonio Russo

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

* Package name: inkscape-ext-textext
Version : 0.12.0~git36-gbbb55e6-1
Upstream Author : Jan Winkler
* URL : https://textext.github.io/textext
* License : AGPL
* Vcs : https://github.com/textext/textext
Section : graphics
Description : Re-editable LaTeX graphics for Inkscape

TexText is a Python plugin for the vector graphics editor Inkscape
providing the possibility to add and re-edit LaTeX generated SVG
elements to your drawing.

Key features
. Windows/Linux/MacOS support
. LaTeX generated SVG elements can be re-edited later
. Multi-line editor with syntax highlighting
. Compilation with PdfLaTeX, XeLaTeX or LuaLaTex
. Interoperable scaling in TexText and Inkscape
. Font size match with Inkscape text
. Customizable TeX preamble (additional packages, parskip, parindent, etc.)
. Colorization via TeX commands/Inkscape is kept after re-editing
. Alignment anchor of the produced output
. Preview images

The packaging [1,2] works (though I haven't tested it in pbuild yet, so there
might be some missing build dependencies). I'm also confused why py3compile
isn't being added by dh_python3 to the postinst script, so at least one
significant thing needs to be fixed.

Also, this is using upstream's "develop" branch, git commit febf8f7. Earlier
versions don't work with Inkscape 1.0 (beta), which has fully transitioned
to Python 3. There's no reason to waste time packaging things for Python 2,
so I suppose this is targeted at experimental, at least until upstream and
Inkscape make another release.

[1] https://mentors.debian.net/package/inkscape-ext-textext
[2]
https://mentors.debian.net/debian/pool/main/i/inkscape-ext-textext/inkscape-ext-textext_0.12.0~git32-gfebf8f7-1.dsc

Bug#942245: Ibus doesn't offer french-latin9 keymap

2019-10-12 Thread Gunnar Hjalmarsson

It struck me that you probably can edit the file 
/usr/share/ibus/component/simple.xml yourself.


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#942248: odb-api: FTBFS on hurd-i386

2019-10-12 Thread Samuel Thibault

Source: odb-api
Version: 0.18.1-7
Severity: important
Tags: patch

Hello,

odb-api currently FTBFS on hurd-i386 due to missing build rules.  I have
attached a patch that fixes this.

Samuel

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

Kernel: Linux 5.3.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Samuel
Progress (n.): The process through which the Internet has evolved from
smart people in front of dumb terminals to dumb people in front of smart
terminals.
Index: odb-api-0.18.1/cmake/FindAIO.cmake
===
--- odb-api-0.18.1.orig/cmake/FindAIO.cmake
+++ odb-api-0.18.1/cmake/FindAIO.cmake
@@ -9,7 +9,7 @@
 # OUTPUT:
 # RT_LIB  = the library to link against
 
-if( CMAKE_SYSTEM_NAME MATCHES "Linux" )
+if( CMAKE_SYSTEM_NAME MATCHES "Linux" OR CMAKE_SYSTEM_NAME MATCHES "GNU" )
 
find_package( Realtime )
 
Index: odb-api-0.18.1/ecbuild/cmake/FindAIO.cmake
===
--- odb-api-0.18.1.orig/ecbuild/cmake/FindAIO.cmake
+++ odb-api-0.18.1/ecbuild/cmake/FindAIO.cmake
@@ -9,7 +9,7 @@
 # OUTPUT:
 # RT_LIB  = the library to link against
 
-if( CMAKE_SYSTEM_NAME MATCHES "Linux" )
+if( CMAKE_SYSTEM_NAME MATCHES "Linux" OR CMAKE_SYSTEM_NAME MATCHES "GNU" )
 
find_package( Realtime )
 
Index: odb-api-0.18.1/ecbuild/share/ecbuild/cmake/FindAIO.cmake
===
--- odb-api-0.18.1.orig/ecbuild/share/ecbuild/cmake/FindAIO.cmake
+++ odb-api-0.18.1/ecbuild/share/ecbuild/cmake/FindAIO.cmake
@@ -9,7 +9,7 @@
 # OUTPUT:
 # RT_LIB  = the library to link against
 
-if( CMAKE_SYSTEM_NAME MATCHES "Linux" )
+if( CMAKE_SYSTEM_NAME MATCHES "Linux" OR CMAKE_SYSTEM_NAME MATCHES "GNU" )
 
find_package( Realtime )
 
Index: odb-api-0.18.1/odb/src/extras/ec/julian.h
===
--- odb-api-0.18.1.orig/odb/src/extras/ec/julian.h
+++ odb-api-0.18.1/odb/src/extras/ec/julian.h
@@ -29,7 +29,7 @@ Author: Dr. Umberto Modigliani, User Sup
 #include 
 #include 
 #include 
-#if !defined(__alpha) && !defined(linux) && !defined(_AIX43) && 
!defined(CYGWIN)
+#if !defined(__alpha) && !defined(linux) && !defined(_AIX43) && 
!defined(CYGWIN) && !defined(__GNU__)
 #include 
 #endif
 #include 
Index: odb-api-0.18.1/odb/src/compiler/regex.c
===
--- odb-api-0.18.1.orig/odb/src/compiler/regex.c
+++ odb-api-0.18.1/odb/src/compiler/regex.c
@@ -2,7 +2,7 @@
 
 /* See also lib/wildcard.c */
 
-#if defined(LINUX) || defined(SUN4) || defined(RS6K)
+#if defined(LINUX) || defined(SUN4) || defined(RS6K) || defined(__GNU__)
 /* Watch for this; This GNU-thing may now be okay for other systems, too */
 #include 
 #define REGEX_DEF(p)  regex_t p
Index: odb-api-0.18.1/odb/src/lib/wildcard.c
===
--- odb-api-0.18.1.orig/odb/src/lib/wildcard.c
+++ odb-api-0.18.1/odb/src/lib/wildcard.c
@@ -2,7 +2,7 @@
 #include "evaluate.h"
 #include "cdrhook.h"
 
-#if defined(LINUX) || defined(SUN4) || defined(RS6K) || defined(SV2)
+#if defined(LINUX) || defined(SUN4) || defined(RS6K) || defined(SV2) || 
defined(__GNU__)
 /* Watch for this; This GNU-thing may now be okay for other systems, too */
 #include 
 #define REGEX_DEF(p)  regex_t p
Index: odb-api-0.18.1/cmake/ecbuild_append_to_rpath.cmake
===
--- odb-api-0.18.1.orig/cmake/ecbuild_append_to_rpath.cmake
+++ odb-api-0.18.1/cmake/ecbuild_append_to_rpath.cmake
@@ -87,6 +87,11 @@ macro( ecbuild_append_to_rpath RPATH_DIR
 set( _done 1 )
 endif()
 
+   if( EC_OS_NAME STREQUAL "hurd" )
+   _path_append( CMAKE_INSTALL_RPATH 
"$ORIGIN/${RPATH_DIR}" )
+   set( _done 1 )
+   endif()
+
# fallback
 
if( NOT _done )
Index: odb-api-0.18.1/cmake/ecbuild_check_os.cmake

Bug#942245: Ibus doesn't offer french-latin9 keymap

2019-10-12 Thread Gunnar Hjalmarsson


This is probably a request you should make upstream:

https://github.com/ibus/ibus/issues/

Available XKB layouts seem to be hard coded in this file:

https://github.com/ibus/ibus/blob/master/engine/simple.xml.in

I don't know the criteria for the selection of XKB layouts; actually 
fr(latin9) was deleted as "useless" a few years ago...


https://github.com/phuang/ibus/commit/661bb47f

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#942247: RM: geary [s390x] -- ROM; ANAIS

2019-10-12 Thread Jeremy Bicha

Package: ftp.debian.org
X-Debbugs-CC: ge...@packages.debian.org, m...@vee.net

geary no longer builds on s390x because it has critical failures in
its build tests. Those failures indicate that geary probably does not
work on s390x.

We are unaware of anyone working on supporting geary on s390x and
would prefer not to ignore test failures in order to publish broken
binary packages.

Therefore, please remove geary on s390x from Debian Unstable.

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#942224: asymptote: VIM addon cannot be managed with vim-addons and fails to enable syntax highlighting

2019-10-12 Thread Norbert Preining

tag 942224 + pending
thanks

Hi Francesco,

On Sat, 12 Oct 2019, Francesco Poli (wintermute) wrote:
> But there seem to be two issues: there's no registry file (hence

Thanks for the explanation - not that I have any idea how to package vim
addons ;-)

I simply followed your advice now and the changes are alread in git,
see
https://github.com/debian-tex/asymptote/commit/22616928ec5da97cf1965b9fbaa01d0b0a78d8ad

Hope that is enough!

All the 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#942246: src:sleepyhead: SleepyHead appears to have been replaced by OSCAR

2019-10-12 Thread Adam Conrad

Package: src:sleepyhead
Severity: normal

According to a statement from the sleepyhead author[1] and the homepage
for the OSCAR fork[2], sleepyhead development is dead, but continues on
with OSCAR.  It's likely worth investigating packaging OSCAR, including
a sleepyhead->oscar transitional package.

... Adam

[1] https://jedimark.net/2019/02/08/sleepyhead-project-shutdown/
[2] https://www.sleepfiles.com/OSCAR/

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

Kernel: Linux 5.3.0-18-lowlatency (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#942172: clamav-daemon: After upgrade, clamd cannon create /var/run/clamav/clamd.ctl and stop.

2019-10-12 Thread Filipe Fonseca


Hello,

I did strike this in three boxes. Straight upgrade but opted not to touch 
config when asked. Don't know if it matters. However I did not find any 
reference to /etc/systemd/system/clamav-daemon.service.d/extend.conf in the 
package scripts as in stretch.


The chown did make the difference. And the extend.conf prior to the upgrade 
on further two boxes got the upgrade working, AFAICT.


Regards,
Filipe

On October 12, 2019 17:32:36 Hugo Lefeuvre  wrote:


Hi,


I did not notice this bug during my tests. I have just tried to reproduce
it by upgrading a jessie system from 0.100.3+dfsg-0+deb8u1 to
0.101.4+dfsg-0+deb8u1 and did not experience any issue restarting
clamav-daemon.


Furthermore, /var/run/clamav/ belonging to root:root or clamav:root does
not seem to change anything on my system. My understanding is that
/var/run/clamav/clamd.ctl is created by systemd, not by the daemon itself.


Also, I don't think chown clamav /var/run/clamav should survive a restart.


Filipe: did you also experience this bug?


Thanks.


regards,
Hugo


--
   Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C


--
filipe.fons...@farmingbits.com
+351.914593743

Bug#941432: [pkg-uWSGI-devel] Bug#941432: Bug#941432: Bug#941432: Bug#941432: uwsgi-core: Dependency libmatheval is getting out of bullseye

2019-10-12 Thread Pierre-Elliott Bécue

Le jeudi 03 octobre 2019 à 11:50:48+0200, Jonas Smedegaard a écrit :
> Quoting Alexandre Rossi (2019-10-02 15:04:54)
> > > > > > Do you have plans/solutions regarding this issue? Is it possible 
> > > > > > to drop uwsgi-core dependency on libmatheval1?
> > > > > 
> > > > > It should be as simple as not building the matheval plugin which is 
> > > > > not critical to uwsgi. Should I go on with this?
> > > > 
> > > > Yeah, I just wasn't sure that it'd be an acceptable solution for you.
> > > > 
> > > > But it's perfectly fine with me. :)
> > > 
> > > Well, I would say "tolerable" rather than "acceptable" - it is a real 
> > > annoyance since it will directly remove features now offered in uwsgi.
> > 
> > upstream says in 1.9.20 changelog:
> > 
> > The matheval support has been removed, while a generic “matheval” plugin
> > (for internal routing) is available (but not compiled in by default).
> > See below for the new way for making “math” in config files.
> > 
> > > @Alexandre: Make sure to add a NEWS entry warning users of the removal 
> > > of matheval - ideally enumerating explicitly all uwsgi options which has 
> > > disappeared and may silently wreak havoc on local systems.
> > > 
> > > Also, better check e.g. with codesearch.debian.net if any packages rely 
> > > on matheval-related uwsgi config options, and if so alert them with 
> > > bugreports.
> > 
> > Search on "uwsgi matheval" or "uwsgi math" yields no result.
> 
> Ah well, seems you got better knowledge here than me, Alex :-)

Thanks for taking the time to answer.

Do you require some assistance regarding a new upload of uwsgi? I'm
eager to dedicate some time to it if you can't do so. :)

With best regards,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature

Bug#942245: Ibus doesn't offer french-latin9 keymap

2019-10-12 Thread Pierre-Elliott Bécue

Source: ibus
Version: 1.5.19-4+b1
Severity: normal

Dear maintainer,

As far as I can see, it is not possible to do the equivalent of a
setxkbmap fr latin9 with ibus. French alternative and French are not
latin9. This forces me to either use ibus and have a bad default keymap
or to disable ibus (currently my choice, using im-config with no
profile).

Would it be possible to include "French (latin9)" in ibus choices of
keymap?

Cheers!

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

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

Bug#942244: xen-tools: xen-create-image does not work with lvm_thin

2019-10-12 Thread Andreas Sundstrom

Package: xen-tools
Version: 4.8-1
Severity: normal
Tags: patch

Dear Maintainer,

I have been using xen-create-image and LVM as the backing for the
disks for a long time. Now I have made a LVM ThinPool and was glad to
find support for that in xen-tools. However it fails to work due to
the name of the VG is specifed on the cmd-line for the lvcreate
command and it should not be that way when a ThinPool is used.

I have fixed the xen-create-image command on my machine and it works
with both regular LVM and LVM with ThinPool on my setup. See the patch
included in this report for the details on what I did.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/1 CPU core)
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 xen-tools depends on:
ii  debootstrap   1.0.114
ii  libconfig-inifiles-perl   3.01-1
ii  libdata-validate-domain-perl  0.10-1
ii  libdata-validate-ip-perl  0.27-1
ii  libdata-validate-uri-perl 0.07-1
ii  libfile-slurp-perl.26-1
ii  libfile-which-perl1.23-1
ii  libsort-versions-perl 1.62-1
ii  libterm-ui-perl   0.46-1
ii  libtext-template-perl 1.55-1
ii  openssh-client1:7.9p1-10+deb10u1
ii  perl  5.28.1-6

Versions of packages xen-tools recommends:
ii  debian-archive-keyring  2019.1
ii  e2fsprogs   1.44.5-1+deb10u2
pn  libexpect-perl  
ii  lvm22.03.02-3
pn  rinse   
ii  ubuntu-keyring [ubuntu-archive-keyring] 2018.09.18.1-5
ii  xen-hypervisor-4.11-amd64 [xen-hypervisor]  4.11.1+92-g6c33308a8d-2
ii  xen-utils-4.11 [xen-utils]  4.11.1+92-g6c33308a8d-2

Versions of packages xen-tools suggests:
pn  btrfs-progs | btrfs-tools  
pn  cfengine2  
ii  grub-xen-host  2.02+dfsg1-20
pn  reiserfsprogs  
pn  xfsprogs   

-- Configuration Files:
/etc/xen-tools/xen-tools.conf changed [not included]
/etc/xen-tools/xm.tmpl changed [not included]

-- no debconf information
--- /usr/bin/xen-create-image~  2019-02-09 01:56:51.0 +0100
+++ /usr/bin/xen-create-image   2019-10-12 21:33:07.0 +0200
@@ -3224,12 +3224,11 @@
 # The commands to create the volume.
 #
 my $disk_cmd =
-  "lvcreate $CONFIG{'lvm'} ".
-  ($lvm_needs_yes ? '--yes' : '').
-  ' '.
+  "lvcreate ".
+  ($lvm_needs_yes ? '--yes ' : '').
   ($CONFIG{ 'lvm_thin' } ?
"-T $CONFIG{'lvm'}/$CONFIG{'lvm_thin'} -V" :
-   '-L').
+   "$CONFIG{'lvm'} -L").
   " $partition->{'size'} -n $disk";
 
 #

Bug#941655: libreoffice-impress: Exported html pages have black backgrounds

2019-10-12 Thread Rene Engelhard

[ always keep the bug in the Cc so that discussions about the bug are
recorded ]

Hi,

On Sat, Oct 12, 2019 at 05:38:38PM +0200, Frank B. Brokken wrote:
> By desktop you mean window manager? That's afterstep (2.2.12-12+b1). There's

No, I mean desktop.

> My VLC plugin versions are currently 3.0.8-2+b1, except vlc-plugin-bittorrent
> (reported a version 2.6-1) and vlc-plugin-vlsub (reported at 0.10.2-2)

And here I actually meant vcl, not vlc. Aka libreoffice-gtk, -gtk3,
-qt5, -kde5.

But given yu use afterstep I believe you have neither installed not
explicitely choosen one of those.

Which makes this definitely unreproducible here, since that "gen"eric
one was what I tried in my chroot.

Regards,

Rene

Bug#942238: installer: update apt sources for security

2019-10-12 Thread Holger Wansing

Control: tags -1 + patch

Holger Wansing  wrote:
> 
> Pavel Kosina  wrote:
> > Package: installation-guide-amd64
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > *** Reporter, please consider answering these questions, where appropriate 
> > ***
> > 
> >* What led up to the situation?
> > In installation of debian 10, testing, there is bad entry to
> > /etc/apt/sources.list - installation procedure reports error when trying
> > contact old security repository (up to 9).
> > 
> > The instalation procedure should use the new one:
> > deb http://security.debian.org testing-security main contrib non-free
> > deb-src http://security.debian.org testing-security main contrib non-free
> 
> Despite being reported against the installation-guide, the reported problem
> is in the installer/the installed system and thus 'apt-setup'. 
> The installation-guide also needs an update though.
> 
> So clone, retitle and assigning to apt-setup.

Also, I created a patch for apt-setup (attached).


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/changelog b/debian/changelog
index 82ce863..13249d7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+apt-setup (1:0.154) UNRELEASED; urgency=medium
+
+  * Update apt sources lines for security from /updates to
+-security.
+
+ -- Holger Wansing   Sat, 12 Oct 2019 21:41:47 +0200
+
 apt-setup (1:0.153) unstable; urgency=medium
 
   * Team upload.
diff --git a/generators/91security b/generators/91security
index e9fa4c9..8ac9827 100755
--- a/generators/91security
+++ b/generators/91security
@@ -29,7 +29,7 @@ for dist in contrib non-free; do
 done
 
 # Don't test mirror if no network selected in netcfg
-echo "deb http://$host/debian-security $codename/updates $dists" >> $file
+echo "deb http://$host/debian-security $codename-security $dists" >> $file
 if db_get netcfg/dhcp_options && \
[ "$RET" = "Do not configure the network at this time" ]; then
 	CODE=9
@@ -52,6 +52,6 @@ if [ "$RET" = false ]; then
 	deb_src="# deb-src"
 fi
 
-echo "$deb_src http://$host/debian-security $codename/updates $dists" >> $file
+echo "$deb_src http://$host/debian-security $codename-security $dists" >> $file
 
 exit $CODE

Bug#942243: dh-cargo breaks rust-globset autopkgtest

Source: dh-cargo, rust-globset
Control: found -1 dh-cargo/21
Control: found -1 rust-globset/0.4.4-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of dh-cargo the autopkgtest of rust-globset fails
in testing when that autopkgtest is run with the binary packages of
dh-cargo from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
dh-cargo   from testing21
rust-globset   from testing0.4.4-1
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-globset/3146849/log.gz

   |
10 | extern crate lazy_static;
   | ^
   |
   = note: candidates:
   crate `lazy_static`:
/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblazy_static-3dccf987e121fa51.rlib
   crate `lazy_static`:
/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblazy_static-8397cca03aed289a.rlib

error[E0463]: can't find crate for `lazy_static`
  --> benches/bench.rs:10:1
   |
10 | extern crate lazy_static;
   | ^ can't find crate

error: aborting due to 2 previous errors




signature.asc
Description: OpenPGP digital signature

Bug#942242: gau2grid breaks psi4 autopkgtest: Running test scf-property... FAILED

Source: gau2grid, psi4
Control: found -1 gau2grid/2.0.1-2
Control: found -1 psi4/1:1.2.1-2
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of gau2grid the autopkgtest of psi4 fails in
testing when that autopkgtest is run with the binary packages of
gau2grid from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
gau2grid   from testing2.0.1-2
psi4   from testing1:1.2.1-2
all others from testingfrom testing

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/p/psi4/3146850/log.gz
autopkgtest [20:15:24]: test testsuite.sh: [---
Running test simint/scf5... OK
Skipping test gcp/hf3c
Running test python/energy... OK
Skipping test v2rdm_casscf/v2rdm3
Skipping test cfour/sp-rhf-ccsd_t_
Running test sapt1... OK
Skipping test libefp/qchem-qmefp-sp
Skipping test dftd3/energy
Running test erd/scf5... OK
Running test scf-property... FAILED
Skipping test mrcc/ccsdt
Running test dfmp2-1... OK
Running test fcidump... OK
Running test psi4numpy/rhf... OK
Running test psi4numpy/rhf-hessian... OK
Skipping test pcmsolver/scf
Skipping test pcmsolver/opt-fd
Skipping test dkh/molpro-2order
Skipping test pasture-ccsorttransqt2/ccenergy_driver
Skipping test gdma/gdma1
Running test json/schema-1-gradient... OK
Running test chemps2/scf-n2... OK
Running test casscf-sp... OK
Running test cc1... OK
Running test tu1-h2o-energy... OK
Skipping test snsmp2/he-he
Some tests failed
autopkgtest [20:16:55]: test testsuite.sh: ---]





signature.asc
Description: OpenPGP digital signature

Bug#942241: pyjwt: autopkgtest needs update for new version of pytest

Source: pyjwt
Version: 1.7.0-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, pyt...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:pytest

Dear maintainers,

With a recent upload of pytest the autopkgtest of pyjwt fails in testing
when that autopkgtest is run with the binary packages of pytest from
unstable. It passes when run with only packages from testing. In tabular
form:
   passfail
pytest from testing4.6.5-2
pyjwt  from testing1.7.0-2
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

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

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/p/pyjwt/3146643/log.gz
 ERRORS

_ ERROR collecting tests/test_utils.py
_
/usr/lib/python3/dist-packages/pluggy/hooks.py:289: in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:87: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:81: in 
firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
/usr/lib/python3/dist-packages/_pytest/python.py:234: in
pytest_pycollect_makeitem
res = list(collector._genfunctions(name, obj))
/usr/lib/python3/dist-packages/_pytest/python.py:410: in _genfunctions
self.ihook.pytest_generate_tests(metafunc=metafunc)
/usr/lib/python3/dist-packages/pluggy/hooks.py:289: in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:87: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:81: in 
firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
/usr/lib/python3/dist-packages/_pytest/python.py:137: in
pytest_generate_tests
metafunc.parametrize(*marker.args, **marker.kwargs)
/usr/lib/python3/dist-packages/_pytest/python.py:1004: in parametrize
function_definition=self.definition,
/usr/lib/python3/dist-packages/_pytest/mark/structures.py:130: in
_for_parametrize
if len(param.values) != len(argnames):
E   TypeError: object of type 'MarkDecorator' has no len()
=== 1 error in 0.50 seconds




signature.asc
Description: OpenPGP digital signature

Bug#942240: ITP: glktermw -- Curses-based interface library for interactive fiction programs

2019-10-12 Thread John Goerzen

Package: wnpp
Severity: wishlist
Owner: John Goerzen 

* Package name: glktermw
  Version : 1.0.4
  Upstream Author : Andrew Plotkin 
* URL : https://www.eblong.com/zarf/glk/index.html
* License : Custom permissive (DFSG-free)
  Programming Lang: C
  Description : Curses-based interface library for interactive fiction 
programs

Glk is a device-independent interface specification intended primarily for
interactive fiction implementations.  This library provides an ncurses-based glk
interface and includes Unicode support.  It is used by packages such as glulxe.

Bug#942239: ITP: glulxe -- Interpreter for glulx interactive fiction

2019-10-12 Thread John Goerzen

Package: wnpp
Severity: wishlist
Owner: John Goerzen 

* Package name: glulxe
  Version : 0.5.4
  Upstream Author : Andrew Plotkin 
* URL : https://eblong.com/zarf/glulx/
* License : MIT
  Programming Lang: C
  Description : Interpreter for glulx interactive fiction

glulxe is the authoritative interpreter for the Glulx interactive fiction
VM, which is a 32-bit update of the older Z-Machine standard.

This program can play games ending with .ulx, .gblorb, .glb, .blorb, and .blb.
glulxe can work with only a terminal; the optional graphics in some Glulx games
can be shown by using the package gargoyle-free instead.

Bug#942128: installation-guide-amd64: security apt resource

2019-10-12 Thread Holger Wansing

Control: clone -1 -2
Control: reassign -2 apt-setup
Control: retitle -2 installer: update apt sources for security


Pavel Kosina  wrote:
> Package: installation-guide-amd64
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> In installation of debian 10, testing, there is bad entry to
> /etc/apt/sources.list - installation procedure reports error when trying
> contact old security repository (up to 9).
> 
> The instalation procedure should use the new one:
> deb http://security.debian.org testing-security main contrib non-free
> deb-src http://security.debian.org testing-security main contrib non-free

Despite being reported against the installation-guide, the reported problem
is in the installer/the installed system and thus 'apt-setup'. 
The installation-guide also needs an update though.

So clone, retitle and assigning to apt-setup.



Holger


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

Bug#942237: fiat: autopkgtest needs update for new version of pytest

Source: fiat
Version: 2019.1.0-2
Severity: important
X-Debbugs-CC: debian...@lists.debian.org, pyt...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:pytest

Dear maintainers,

With a not so recent upload of pytest the autopkgtest of fiat fails in
testing when that autopkgtest is run with the binary packages of pytest
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
pytest from testing4.6.5-2
fiat   from testing2019.1.0-2
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

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

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/f/fiat/3146642/log.gz
autopkgtest [19:12:59]: test test-fiat: [---
= test session starts
==
platform linux -- Python 3.7.5rc1, pytest-4.6.5, py-1.8.0, pluggy-0.12.0
-- /usr/bin/python3
cachedir: .pytest_cache
rootdir: /tmp/autopkgtest-lxc.r2m_5z8m/downtmp/build.AVW/src
collecting ... Cloning reference data repository
Download reference data ok
collected 271 items / 2 errors / 269 selected

 ERRORS

 ERROR collecting test/unit/test_quadrature.py
_
Fixture "interval" called directly. Fixtures are not meant to be called
directly,
but are created automatically when test functions request them as
parameters.
See https://docs.pytest.org/en/latest/fixture.html for more information
about fixtures, and
https://docs.pytest.org/en/latest/deprecations.html#calling-fixtures-directly
about how to update your code.
_ ERROR collecting test/unit/test_reference_element.py
_
/usr/lib/python3/dist-packages/pluggy/hooks.py:289: in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:87: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:81: in 
firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
/usr/lib/python3/dist-packages/_pytest/python.py:234: in
pytest_pycollect_makeitem
res = list(collector._genfunctions(name, obj))
/usr/lib/python3/dist-packages/_pytest/python.py:410: in _genfunctions
self.ihook.pytest_generate_tests(metafunc=metafunc)
/usr/lib/python3/dist-packages/pluggy/hooks.py:289: in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:87: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:81: in 
firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
/usr/lib/python3/dist-packages/_pytest/python.py:137: in
pytest_generate_tests
metafunc.parametrize(*marker.args, **marker.kwargs)
/usr/lib/python3/dist-packages/_pytest/python.py:1004: in parametrize
function_definition=self.definition,
/usr/lib/python3/dist-packages/_pytest/mark/structures.py:130: in
_for_parametrize
if len(param.values) != len(argnames):
E   TypeError: object of type 'MarkDecorator' has no len()
=== warnings summary
===
test/regression/test_regression.py:169
  test/regression/test_regression.py:169: PytestCollectionWarning: yield
tests were removed in pytest 4.0 - test_quadrature will be ignored
def test_quadrature():

-- Docs: https://docs.pytest.org/en/latest/warnings.html
!!! Interrupted: 2 errors during collection

=

Bug#942236: doit: autopkgtest needs update for new version of pytest

Source: doit
Version: 0.31.1-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, pyt...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:pytest

Dear maintainers,

With a not so recent upload of pytest the autopkgtest of doit fails in
testing when that autopkgtest is run with the binary packages of pytest
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
pytest from testing4.6.5-2
doit   from testing0.31.1-2
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

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

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/d/doit/3146641/log.gz

TaskError - taskid:ut:tests/test_cmd_forget.py
PythonAction Error
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/doit/action.py", line 424, in execute
returned_value = self.py_callable(*self.args, **kwargs)
  File "/tmp/autopkgtest-lxc.xt18xr7t/downtmp/build.R0b/src/dodo.py",
line 32, in run_test
return not bool(pytest.main(test))
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line
63, in main
config = _prepareconfig(args, plugins)
  File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line
191, in _prepareconfig
raise TypeError(msg.format(args, type(args)))
TypeError: `args` parameter expected to be a list or tuple of strings,
got: 'tests/test_cmd_forget.py' (type: )


TaskError - taskid:ut:tests/test_cmd_forget.py
ut:tests/test_cmd_forget.py :

ut:tests/test_cmd_forget.py :






signature.asc
Description: OpenPGP digital signature

Bug#942235: dask: autopkgtest needs update for new version of pytest

Source: dask
Version: 1.0.0+dfsg-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org, pyt...@packages.debian.org
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:pytest

Dear maintainers,

With a not so recent upload of pytest the autopkgtest of dask fails in
testing when that autopkgtest is run with the binary packages of pytest
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
pytest from testing4.6.5-2
dask   from testing1.0.0+dfsg-2
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

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

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

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dask/3146640/log.gz

autopkgtest [19:13:10]: test command1: [---
Testing with python3.7:
= test session starts
==
platform linux -- Python 3.7.5rc1, pytest-4.6.5, py-1.8.0, pluggy-0.12.0
-- /usr/bin/python3.7
cachedir: .pytest_cache
rootdir: /tmp/autopkgtest-lxc.n16ld1px/downtmp/autopkgtest_tmp
collecting ... collected 5850 items / 2 errors / 7 skipped / 5841 selected

 ERRORS

_ ERROR collecting dataframe/io/tests/test_parquet.py
__
/usr/lib/python3/dist-packages/pluggy/hooks.py:289: in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:87: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:81: in 
firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
/usr/lib/python3/dist-packages/_pytest/python.py:234: in
pytest_pycollect_makeitem
res = list(collector._genfunctions(name, obj))
/usr/lib/python3/dist-packages/_pytest/python.py:410: in _genfunctions
self.ihook.pytest_generate_tests(metafunc=metafunc)
/usr/lib/python3/dist-packages/pluggy/hooks.py:289: in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:87: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:81: in 
firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
/usr/lib/python3/dist-packages/_pytest/python.py:137: in
pytest_generate_tests
metafunc.parametrize(*marker.args, **marker.kwargs)
/usr/lib/python3/dist-packages/_pytest/python.py:1004: in parametrize
function_definition=self.definition,
/usr/lib/python3/dist-packages/_pytest/mark/structures.py:130: in
_for_parametrize
if len(param.values) != len(argnames):
E   TypeError: object of type 'MarkDecorator' has no len()
__ ERROR collecting tests/test_dot.py
__
/usr/lib/python3/dist-packages/pluggy/hooks.py:289: in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:87: in _hookexec
return self._inner_hookexec(hook, methods, kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py:81: in 
firstresult=hook.spec.opts.get("firstresult") if hook.spec else False,
/usr/lib/python3/dist-packages/_pytest/python.py:234: in
pytest_pycollect_makeitem
res = list(collector._genfunctions(name, obj))
/usr/lib/python3/dist-packages/_pytest/python.py:410: in _genfunctions
self.ihook.pytest_generate_tests(metafunc=metafunc)
/usr/lib/python3/dist-packages/pluggy/hooks.py:289: in __call__
return self._hookexec(self, self.get_hookimpls(), kwargs)
/usr/lib/python3/dist-packages/pluggy/manager.py

Bug#942135: Have either synaptic removed or have it rebuilt with libgtk3-perl in it recommends.

2019-10-12 Thread shirish शिरीष

Dear all,

Dunno if this is the right place to discuss it or not. Integri asked
hence sharing.

There is also another package synaptic which still uses libgtk2-removal.

$ aptitude why libgtk2-perl
i   task-mate-desktop Recommends synaptic
i A synaptic  Recommends libgtk2-perl (>= 1:1.130)

I looked in the tracker and there doesn't seem to be any movement
about syanptic.

I looked at launchpad.net and saw that the last release they made in 2017.

So there seems to be 2-3 things which can be done.

a. Have synaptic be removed from the debian archive and have
mate-desktop use some other alternative for a GUI package manager.

b. Have synaptic rebuilt using libgtk3-perl and bump up the synaptic version.

3. Remove syanptic and whenever upgrading use  --without-recommends so
synaptic doesn't get pulled in in apt and others.

I would prefer b. and then a. if not possible.

I did see that  on popcon.debian.org synaptic does have a fair pull
although dunno whether it is due to the fact that it gets pulled via
task-mate-desktop or people download it.

https://qa.debian.org/popcon.php?package=synaptic

Looking forward to see whatever solution fo the problem is taken up.
Best of luck to those who are tackling it. Thank you for the work in
removing libgtk2-perl .

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

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

Bug#942232: maitreya: Should maitreya be removed from Debian?

2019-10-12 Thread Olly Betts

Source: maitreya
Version: 7.0.7-1
Severity: normal

I wonder if it's time to remove the maitreya package:

* Last uploaded 2014-08-16 - over 5 years ago
* Out of date compared to upstream (latest upstream is 8.0.1 released
  2017-10-03)
* Low popcon - maitreya inst:57 vote:11, fonts-maitreya inst:176 vote:0
* RC buggy:
  + Uninstallable in unstable (#940541)
  + Blocker for the current wxwidgets3.0-gtk3 transition (#934097)
* No reverse dependencies according to: dak rm -Rn maitreya
* Maintainer seems unresponsive - only one of the 6 open bugs has a
  maintainer response, and that was back in 2015.

If there are no objections within two weeks, I'll turn this into an RM
bug.

Cheers,
Olly

Bug#942234: gdm3: the button «Shutdown» does not work anymore

2019-10-12 Thread Jean-Marc

Package: gdm3
Version: 3.34.0-2
Severity: normal

Dear Maintainer,

Since the last upgrade to GDM 3.34, the shutdown button does not work anymore.

If I click on it, I get the popup window with the three buttons (Cancel, 
Reboot, Shutdown) but clicking on Reboot or Shutdown just close this popup 
window and does nothing more.

Looking in /var/log/daemon.log, I found this message each time I use the GDM 
Shutdown option:
Oct 12 20:43:19 machineName gnome-session-binary[11980]: WARNING: Shutdown 
failed: 
GDBus.Error:org.freedesktop.DBus.Error.InteractiveAuthorizationRequired: 
Interactive authentication required.

Moreover, I also notice this in the systemctl status gdm.service output:

● gdm.service - GNOME Display Manager
   Loaded: loaded (/lib/systemd/system/gdm.service; static; vendor preset: 
enabled)
   Active: active (running) since Sat 2019-10-12 15:00:24 CEST; 6h ago
  Process: 1008 ExecStartPre=/usr/share/gdm/generate-config (code=exited, 
status=0/SUCCESS)
 Main PID: 1020 (gdm3)
Tasks: 3 (limit: 4915)
   Memory: 11.2M
   CGroup: /system.slice/gdm.service
   └─1020 /usr/sbin/gdm3

oct 12 20:29:01 machineName gdm3[1020]: Child process -9036 was already dead.
oct 12 20:42:28 machineName gdm-launch-environment][11942]: 
pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm by 
(uid=0)
oct 12 20:43:09 machineName gdm-password][12188]: pam_unix(gdm-password:auth): 
Couldn't open /etc/securetty: Aucun fichier ou dossier de ce type
oct 12 20:43:25 machineName gdm-password][12196]: pam_unix(gdm-password:auth): 
Couldn't open /etc/securetty: Aucun fichier ou dossier de ce type
oct 12 20:43:31 machineName gdm-password][12196]: pam_unix(gdm-password:auth): 
Couldn't open /etc/securetty: Aucun fichier ou dossier de ce type
oct 12 20:43:31 machineName gdm-password][12196]: gkr-pam: unable to locate 
daemon control file
oct 12 20:43:31 machineName gdm-password][12196]: 
pam_unix(gdm-password:session): session opened for user jim by (uid=0)
oct 12 20:43:34 machineName gdm3[1020]: Child process -11964 was already dead.
oct 12 21:05:27 machineName gdm-launch-environment][14042]: 
pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm by 
(uid=0)
oct 12 21:05:44 machineName gdm3[1020]: Child process -14060 was already dead.

Maybe something missing since the last upgrade from 3.30.

Maybe it is because of the file /etc/securetty.

It was in the package login since Buster but it is not present in this package 
in Bullseye anymore.

Regards,

Jean-Marc


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

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

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.45-2
ii  adduser   3.118
ii  dconf-cli 0.34.0-1
ii  dconf-gsettings-backend   0.34.0-1
ii  debconf [debconf-2.0] 1.5.73
ii  gir1.2-gdm-1.03.34.0-2
ii  gnome-session [x-session-manager] 3.34.1-1
ii  gnome-session-bin 3.34.1-1
ii  gnome-settings-daemon 3.34.0-3
ii  gnome-shell   3.34.0-2
ii  gnome-terminal [x-terminal-emulator]  3.34.0-1
ii  gsettings-desktop-schemas 3.34.0-2
ii  libaccountsservice0   0.6.45-2
ii  libaudit1 1:2.8.5-2
ii  libc6 2.29-2
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.38.2+dfsg-1
ii  libgdm1   3.34.0-2
ii  libglib2.0-0  2.62.1-1
ii  libglib2.0-bin2.62.1-1
ii  libgtk-3-03.24.12-1
ii  libkeyutils1  1.6-6
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpam-systemd242-7
ii  libpam0g  1.3.1-5
ii  librsvg2-common   2.44.14-1
ii  libselinux1   2.9-2+b2
ii  libsystemd0   242-7
ii  libwrap0  7.6.q-28
ii  libx11-6  2:1.6.8-1
ii  libxau6   1:1.0.8-1+b2
ii  libxcb1   1.13.1-2
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  11.1.0
ii  mutter [x-window-manager] 3.34.0-4
ii  policykit-1   0.105-26
ii  procps2:3.3.15-2+b1
ii  ter

Bug#942233: ruby-selenium-webdriver: needs update for new version of ruby-childprocess

Source: ruby-selenium-webdriver
Version: 3.141.0+dfsg-1
Severity: important
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:ruby-childprocess

[X-Debbugs-CC: debian...@lists.debian.org,
ruby-childproc...@packages.debian.org]

Dear maintainers,

With a recent upload of ruby-childprocess the autopkgtest of
ruby-selenium-webdriver fails in testing when that autopkgtest is run
with the binary packages of ruby-childprocess from unstable. It passes
when run with only packages from testing. In tabular form:
 passfail
ruby-childprocessfrom testing3.0.0-1
ruby-selenium-webdriver  from testing3.141.0+dfsg-1
all others   from testingfrom testing

I copied some of the output at the bottom of this report. It seems to me
that you need to make your package (well, at least the autopkgtest) work
with the new version of ruby-childprocess.

Currently this regression is blocking the migration of ruby-childprocess
to testing [1].

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-selenium-webdriver/3146650/log.gz

GEM_PATH= ruby2.5 -e gem\ \"selenium-webdriver\"
/usr/lib/ruby/2.5.0/rubygems/dependency.rb:312:in `to_specs': Could not
find 'childprocess' (~> 0.5) - did find: [childprocess-3.0.0]
(Gem::MissingSpecVersionError)
Checked in
'GEM_PATH=/home/debci/.gem/ruby/2.5.0:/var/lib/gems/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0',
execute `gem env` for more information
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1469:in `block in
activate_dependencies'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1458:in `each'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1458:in
`activate_dependencies'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1440:in `activate'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:68:in `block
in gem'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in
`synchronize'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in `gem'
from -e:1:in `'



signature.asc
Description: OpenPGP digital signature

Bug#942231: ruby-blade-sauce-labs-plugin: needs update for new version of ruby-childprocess

Source: ruby-blade-sauce-labs-plugin
Version: 0.7.3+dfsg-1
Severity: important
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:ruby-childprocess

[X-Debbugs-CC: debian...@lists.debian.org,
ruby-childproc...@packages.debian.org]

Dear maintainers,

With a recent upload of ruby-childprocess the autopkgtest of
ruby-blade-sauce-labs-plugin fails in testing when that autopkgtest is
run with the binary packages of ruby-childprocess from unstable. It
passes when run with only packages from testing. In tabular form:
  passfail
ruby-childprocess from testing3.0.0-1
ruby-blade-sauce-labs-plugin  from testing0.7.3+dfsg-1
all othersfrom testingfrom testing

I copied some of the output at the bottom of this report. It seems to me
that you need to make your package (well, at least the autopkgtest) work
with the new version of ruby-childprocess.

Currently this regression is blocking the migration of ruby-childprocess
to testing [1].

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

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

Paul

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

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-blade-sauce-labs-plugin/3146649/log.gz

Invalid gemspec in [blade-sauce_labs_plugin.gemspec]: No such file or
directory - git
GEM_PATH= ruby2.5 -e gem\ \"blade-sauce_labs_plugin\"
/usr/lib/ruby/2.5.0/rubygems/dependency.rb:312:in `to_specs': Could not
find 'childprocess' (~> 0.5) - did find: [childprocess-3.0.0]
(Gem::MissingSpecVersionError)
Checked in
'GEM_PATH=/home/debci/.gem/ruby/2.5.0:/var/lib/gems/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0',
execute `gem env` for more information
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1469:in `block in
activate_dependencies'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1458:in `each'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1458:in
`activate_dependencies'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1440:in `activate'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1472:in `block in
activate_dependencies'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1458:in `each'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1458:in
`activate_dependencies'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1440:in `activate'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:68:in `block
in gem'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in
`synchronize'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in `gem'
from -e:1:in `'





signature.asc
Description: OpenPGP digital signature

Bug#942113: 3depict: FTBFS on PPC64EL - POWERPC macro not always defined

2019-10-12 Thread Olly Betts

Control: tag -1 + ftbfs
Control: severity -1 serious

Raising severity because this is a FTBFS on a release architecture where
the package has previously built.

On Fri, Oct 11, 2019 at 01:01:13PM +0200, Thierry fa...@linux.ibm.com wrote:
> Changing on file side is not enough as there a couple of file impacted
>  > g++ -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2
> -I/usr/include/freetype2 -I/usr/include/libpng16 -g -O2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security --std=gnu++11
> -I/usr/lib/powerpc64le-linux-gnu/wx/include/gtk3-unicode-3.0
> -I/usr/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__
> -I/usr/include  -I/usr/include/libxml2 -L/lib -fopenmp -D_GLIBCXX_PARALLEL
> -pipe  -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong
> -Wformat -Werror=format-security --std=gnu++11 -c -o
> backend/filters/algorithms/3Depict-spatial.o `test -f
> 'backend/filters/algorithms/spatial.cpp' || echo
> './'`backend/filters/algorithms/spatial.cpp
> > In file included from /usr/include/qhull/qhull_a.h:28,
> >  from backend/filters/algorithms/spatial.cpp:30:
> > /usr/include/qhull/libqhull.h:46:30: error: operator '&&' has no right 
> > operand
> >46 | #if __MWERKS__ && __POWERPC__
> >   |  ^
> 
> 
> and included files are not common !

I've Cc:-ed tille as his was the most recent upload.  Let me know if
you'd like me to NMU with a s/__POWERPC__/__powerpc__/.

Cheers,
Olly

Bug#942230: fromiso on a multi-device btrfs needs btrfs device scan

2019-10-12 Thread pk

Package: debian-live

Booting lxqt 10.1 live iso, stored on a multi-device btrfs, fails with
an infinite loop.

Workaround: boot with break, then:
modprobe btrfs
btrfs device scan
^D


In theory, another approach would be to pass the list of partitions as
a mount option, as done on installed distros that do not run the
device scan:
rootflags=device=/dev/sda2,...
However, this seems unapplicable to the boot parameter fromiso.

Bug#942229: llvm-toolchain-9: Fails to compile on i386

2019-10-12 Thread Matthew

Source: llvm-toolchain-9
Version: 1:9-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Trying to build the i386 llvm-9 packages in a chroot by typing "debuild" fails 
with:

make[5]: Leaving directory 
'/usr/local/src/test/stage/llvm-toolchain-9-9/build-llvm'
make -f tools/clang/CMakeFiles/stage2.dir/build.make 
tools/clang/CMakeFiles/stage2.dir/build
make[5]: Entering directory 
'/usr/local/src/test/stage/llvm-toolchain-9-9/build-llvm'
[100%] Performing configure step for 'stage2'
cd 
/usr/local/src/test/stage/llvm-toolchain-9-9/build-llvm/tools/clang/stage2-bins 
&& /usr/bin/cmake -DCMAKE_INSTALL_PREFIX=/usr/lib/llvm-9 "-DCMAKE_CXX_FLAGS= 
-fuse-ld=gold -fPIC -Wno-unused-command-line-argument 
-Wno-unknown-warning-option" "-DCMAKE_C_FLAGS= -fuse-ld=gold -fPIC 
-Wno-unused-command-line-argument -Wno-unknown-warning-option" 
-DCMAKE_INSTALL_PREFIX=/usr/lib/llvm-9 -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_BUILD_TYPE=RelWithDebInfo "-DCMAKE_CXX_FLAGS_RELWITHDEBINFO=-O2 
-DNDEBUG -g1" -DLLVM_LINK_LLVM_DYLIB=ON -DLLVM_INSTALL_UTILS=ON 
-DLLVM_VERSION_SUFFIX= -DLLVM_ENABLE_SPHINX=ON -DSPHINX_WARNINGS_AS_ERRORS=OFF 
-DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_ENABLE_RTTI=ON -DLLVM_ENABLE_FFI=ON 
-DLIBCLANG_LIBRARY_VERSION=1 -DENABLE_LINKER_BUILD_ID=ON 
-DPOLLY_BUNDLED_JSONCPP=OFF -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=AVR 
-DLLVM_USE_PERF=yes -DLLVM_ENABLE_ASSERTIONS=OFF 
-DLLVM_BINUTILS_INCDIR=/usr/include -DLLVM_HOST_TRIPLE=x86_64-pc-linux-gnu 
-DLLVM_COMPILER_CHECKED=ON -DCOMPILER_RT_BUILD_BUILTINS=ON 
-DLIBOMP_LIBFLAGS=-latomic "-DCMAKE_SHARED_LINKER_FLAGS=-latomic -Wl,-z,defs 
-Wl,-z,nodelete -flto=thin" -DPYTHON_EXECUTABLE=/usr/bin/python3 
-DPACKAGE_VERSION=9.0.0 -DLLVM_VERSION_MAJOR=9 -DLLVM_VERSION_MINOR=0 
-DLLVM_VERSION_PATCH=0 -DCLANG_VERSION_MAJOR=9 -DCLANG_VERSION_MINOR=0 
-DCLANG_VERSION_PATCHLEVEL=0 -DLLVM_VERSION_SUFFIX= 
-DLLVM_BINUTILS_INCDIR=/usr/include -DCLANG_REPOSITORY_STRING= 
-DCMAKE_MAKE_PROGRAM=/usr/bin/make -DLLVM_ENABLE_PROJECTS= -DCLANG_STAGE=stage2 
-DCMAKE_CXX_COMPILER=/usr/local/src/test/stage/llvm-toolchain-9-9/build-llvm/./bin/clang++
 
-DCMAKE_C_COMPILER=/usr/local/src/test/stage/llvm-toolchain-9-9/build-llvm/./bin/clang
 
-DCMAKE_ASM_COMPILER=/usr/local/src/test/stage/llvm-toolchain-9-9/build-llvm/./bin/clang
 -DCMAKE_ASM_COMPILER_ID=Clang -DCMAKE_VERBOSE_MAKEFILE=On 
-DCMAKE_AR=/usr/local/src/test/stage/llvm-toolchain-9-9/build-llvm/./bin/llvm-ar
 
-DCMAKE_RANLIB=/usr/local/src/test/stage/llvm-toolchain-9-9/build-llvm/./bin/llvm-ranlib
 "-GUnix Makefiles" /usr/local/src/test/stage/llvm-toolchain-9-9
Re-run cmake no build system arguments
-- Could NOT find Z3: Found unsuitable version "0.0.0", but required is at 
least "4.7.1" (found Z3_LIBRARIES-NOTFOUND)
CMake Error at cmake/config-ix.cmake:320 (message):
  libffi includes are not found.
Call Stack (most recent call first):
  CMakeLists.txt:618 (include)


-- Configuring incomplete, errors occurred!
See also 
"/usr/local/src/test/stage/llvm-toolchain-9-9/build-llvm/tools/clang/stage2-bins/CMakeFiles/CMakeOutput.log".
See also 
"/usr/local/src/test/stage/llvm-toolchain-9-9/build-llvm/tools/clang/stage2-bins/CMakeFiles/CMakeError.log".
make[5]: *** [tools/clang/CMakeFiles/stage2.dir/build.make:109: 
tools/clang/stage2-stamps/stage2-configure] Error 1
make[5]: Leaving directory 
'/usr/local/src/test/stage/llvm-toolchain-9-9/build-llvm'
make[4]: *** [CMakeFiles/Makefile2:46011: 
tools/clang/CMakeFiles/stage2.dir/all] Error 2
make[4]: Leaving directory 
'/usr/local/src/test/stage/llvm-toolchain-9-9/build-llvm'
make[3]: *** [CMakeFiles/Makefile2:46018: 
tools/clang/CMakeFiles/stage2.dir/rule] Error 2
make[3]: Leaving directory 
'/usr/local/src/test/stage/llvm-toolchain-9-9/build-llvm'
make[2]: *** [Makefile:14060: stage2] Error 2
make[2]: Leaving directory 
'/usr/local/src/test/stage/llvm-toolchain-9-9/build-llvm'
make[1]: *** [debian/rules:430: debian-full-build] Error 2
make[1]: Leaving directory '/usr/local/src/test/stage/llvm-toolchain-9-9'
make: *** [debian/rules:271: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2

Thanks,

Matthew

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

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

Bug#935914: kinit: Signal: Segmentation fault (11) after rebooting

2019-10-12 Thread Ralf Jung

After a big dist-upgrade I just did (and a reboot), I am not also experiencing
kdeinit5 crashes.  There's a notification popping up every now and then telling
me it crashed.  However it doesn't let me report a bug (looks like no bug
reporting URL is set, or so); so I am not sure how to even capture a stacktrace
of this.

; Ralf

Bug#923300: #923300 ITP: golang-github-openshift-imagebuilder -- Builds Dockerfile using the Docker client

2019-10-12 Thread Reinhard Tartler



On 10/12/19 9:06 AM, Dmitry Smirnov wrote:
> Hi Reinhard,
> 
> Nothing blocks "golang-github-openshift-imagebuilder" any more so perhaps now 
> would be a good time to upload?
> 
> Thanks.
> 

Thanks for the reminder, I've just 'dgit push'ed to experimental

-rt



signature.asc
Description: OpenPGP digital signature

Bug#830726: closed by Chris Lamb (Bug#830726: fixed in xtrlock 2.12)

2019-10-12 Thread Chris Lamb

Hi Antoine,

> Thanks for fixing this and pushing it! Is the final fix also supposed to
> address the case of an attacker plugging in a new USB multitouch device?

Alas not; I received no input from upstream after repeated pings so I
pushed ahead.

> If the latter -- should this be pointed out as a known limitation or
> vulnerability of the package?

Indeed. I did write that here:

  
https://salsa.debian.org/debian/xtrlock/commit/0254c8652b415263bebadbe1413e71b9ec12e741.diff

... but I would concede that is not very visible. I think I was
subconciously hoping that a deeper fix will be forthcoming.


Regards,

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

Bug#934754: upload geary 3.32 to unstable

2019-10-12 Thread Jeremy Bicha

On Wed, Aug 14, 2019 at 9:03 AM Pirate Praveen  wrote:
> mail client being a very important software for a desktop, I think geary
> should be available in buster backports. I was able to rebuild geary
> 3.32 on buster without any changes in dependencies. Please upload geary
> 3.32 to unstable so it can reach testing and backports.

Uploaded to unstable now.

I think at the moment we don't have people in the Debian GNOME team
maintaining backports. I guess you could give it a try if you commit
to maintaining the backported packages.

Note that geary's build tests fail on s390x (so we will be removing
geary/s390x from Bullseye). Also note that geary 3.34 requires
libhandy which is not available in Buster. There is a libhandy git
subproject available, but we remove it for Bullseye to avoid an
"embedded code copy".

Jeremy

Bug#942228: ITP: folium -- visualize geographic data in a Leaflet map

2019-10-12 Thread Georges Khaznadar

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 

* Package name: folium
  Version : 0.10.0
  Upstream Author : Rob Story 
* URL : https://python-visualization.github.io/folium
* License : MIT/X
  Programming Lang: Python
  Description : visualize geographic data in a Leaflet map

 folium builds on the data wrangling strengths of the Python ecosystem
 and the mapping strengths of the Leaflet.js library. Manipulate your
 data in Python, then visualize it in a Leaflet map via folium.


As a teacher of computer science for undergraduate students, I am
using th library folium to let them discover activities realted to
geographic maps, openstreetmap.org, and so on.

I shall maintain this package as part of my full time job.

Bug#942227: fish: "unreachable" state reached when redirecting to/from an unopenable file with `exec'

2019-10-12 Thread Asher Gordon

Package: fish
Version: 3.0.2-2
Severity: normal
Tags: upstream

Dear Maintainer,

I was running a program under GDB, and I needed to have it read from a
file which it is not permitted to read. So I typed

  (gdb) run < /dev/mem

GDB ran fish (since that is my $SHELL) to execute my program. But fish
was terminated by SIGABRT with the following stacktrace:

An error occurred while redirecting file '/dev/mem'
open: Permission denied
 fish: src/exec.cpp:1032: failed assertion: this should be unreachable
 fish: Backtrace:
 fish: 0   /usr/bin/fish(+0xb16e7) [0x556056e7]
 fish: 1   parse_execution_context_t::run_1_job(tnode_t, 
block_t const*) + 2101
 fish: 2   
parse_execution_context_t::run_job_conjunction(tnode_t,
 block_t const*) + 196
 fish: 3   parse_execution_result_t 
parse_execution_context_t::run_job_list(tnode_t,
 block_t const*) + 281
 fish: 4   parse_execution_context_t::eval_node(tnode_t, 
block_t const*, io_chain_t const&) + 1380
 fish: 5   int 
parser_t::eval_node(std::shared_ptr, 
tnode_t, io_chain_t const&, block_type_t, 
std::shared_ptr) + 777
 fish: 6   parser_t::eval(std::shared_ptr, io_chain_t 
const&, block_type_t) + 176
 fish: 7   parser_t::eval(std::__cxx11::basic_string, std::allocator >, io_chain_t const&, 
block_type_t) + 225
 fish: 8   run_command_list(std::vector, std::allocator >, 
std::allocator, 
std::allocator > > >*, io_chain_t const&) + 147
 fish: 9   main + 2200
 fish: 10  __libc_start_main + 235
 fish: 11  _start + 42

The first two lines are expected, but it then aborts because it reached
an "unreachable" state (how embarrassing!)

At first I thought that the problem was being run by GDB, but it is
actually `exec' that is the problem. For example:

  $ fish -c 'exec cat < /dev/mem'
  An error occurred while redirecting file '/dev/mem'
  open: Permission denied
   fish: src/exec.cpp:1032: failed assertion: this should be unreachable
   fish: Backtrace:
  [...]

Note the `exec' and the `<'. Without the `<', `cat' tries to open
/dev/mem, not `fish', so the bug does not appear.

This is not only specific to /dev/mem or special files. It can be any
unreadable file, for example /etc/shadow. It can even be a file that
does not exist. (Just remember to look for a file that does not exist
outside of your home directory, since you are sure to have created every
possible filename in your home directory if you are anything like me
(actually, I usually just shove it under ~/misc these days).)

Each time, it aborts in src/exec.cpp:1032. Fish should of course exit
with an error, but it should not reach an "unreachable" state.

This also happens if you redirect *to* an unwritable file even if it is
readable (such as /etc/passwd).

Also note that without the `exec', the bug does not appear:

  $ fish -c 'cat < /dev/mem'
  An error occurred while redirecting file '/dev/mem'
  open: Permission denied

This looks like an upstream bug (hence the "upstream" tag), but I'm not
sure because I haven't tried it with upstream fish yet. I'll send
another message with my findings if I do get around to trying it with
upstream.

Thanks,
Asher

-- 
A witty saying proves nothing, but saying something pointless gets
people's attention.

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

Kernel: Linux 5.2.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 fish depends on:
ii  bc  1.07.1-2+b2
ii  dpkg1.19.7
ii  elinks [www-browser]0.13~20190125-4
ii  epiphany-browser [www-browser]  3.32.1.2-3
ii  firefox-esr [www-browser]   60.8.0esr-1
ii  fish-common 3.0.2-2
ii  libc6   2.29-2
ii  libgcc1 1:9.2.1-8
ii  libncurses6 6.1+20190803-1
ii  libpcre2-32-0   10.32-5+b1
ii  libstdc++6  9.2.1-8
ii  libtinfo6   6.1+20190803-1
ii  links2 [www-browser]2.20.2-1
ii  lynx [www-browser]  2.9.0dev.4-1
ii  man-db  2.8.7-3
ii  netrik [www-browser]1.16.1-2+b2
ii  python3 3.7.5-1
ii  w3m [www-browser]   0.5.3-37+b1

Versions of packages fish recommends:
ii  xsel  1.2.0+git9bfc13d.20180109-3

Versions of packages fish suggests:
pn  doc-base  

-- no debconf information


signature.asc
Description: PGP signature

Bug#941237: transition: brltty

2019-10-12 Thread Samuel Thibault

Emilio Pozuelo Monfort, le sam. 12 oct. 2019 15:45:15 +0200, a ecrit:
> On 26/09/2019 23:20, Samuel Thibault wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Hello,
> > 
> > I'd like to upload brltty which introduces libbrlapi0.7 instead of
> > libbrlapi0.6. The only rdep is qemu, which builds fine against it.
> 
> Sure, please go ahead.

Thanks, it's now in!

Samuel

Bug#942226: ITP: branca -- library with non-map-specific features for folium

2019-10-12 Thread Georges Khaznadar

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 

* Package name: branca
  Version : 0.3.1
  Upstream Author : Martin Journois 
* URL : https://github.com/python-visualization/branca/tree/v0.3.1
* License : MIT/X
  Programming Lang: Python
  Description : library with non-map-specific features for folium

 folium builds on the data wrangling strengths of the Python ecosystem
 and the mapping strengths of the Leaflet.js library. Manipulate your
 data in Python, then visualize it in a Leaflet map via folium.
 .
 branca provides the features which are not specific to maps.



As a teacher of computer science for undergraduate students, I am using folium
to teach maps management, openstreetmap.org, and so on.

I shall maintain this package as part of my current job.

Bug#942225: vim: Looses editor alternative selection (due to move into /usr/libexec/vim/)

2019-10-12 Thread Salvatore Bonaccorso

Source: vim
Version: 2:8.1.2136-1
Severity: normal

Hi

On update to 2:8.1.2136-1 (possibly due to the /usr/libexec/vim move)
the editor selection for the alternatives is lost:

root@vim-test:/# update-alternatives --set editor /usr/bin/vim.basic
update-alternatives: using /usr/bin/vim.basic to provide /usr/bin/editor 
(editor) in manual mode
root@vim-test:/# update-alternatives --display editor
editor - manual mode
  link best version is /bin/nano
  link currently points to /usr/bin/vim.basic
  link editor is /usr/bin/editor
  slave editor.1.gz is /usr/share/man/man1/editor.1.gz
  slave editor.da.1.gz is /usr/share/man/da/man1/editor.1.gz
  slave editor.de.1.gz is /usr/share/man/de/man1/editor.1.gz
  slave editor.fr.1.gz is /usr/share/man/fr/man1/editor.1.gz
  slave editor.it.1.gz is /usr/share/man/it/man1/editor.1.gz
  slave editor.ja.1.gz is /usr/share/man/ja/man1/editor.1.gz
  slave editor.pl.1.gz is /usr/share/man/pl/man1/editor.1.gz
  slave editor.ru.1.gz is /usr/share/man/ru/man1/editor.1.gz
/bin/nano - priority 40
  slave editor.1.gz: /usr/share/man/man1/nano.1.gz
/usr/bin/vim.basic - priority 30
  slave editor.1.gz: /usr/share/man/man1/vim.1.gz
  slave editor.da.1.gz: /usr/share/man/da/man1/vim.1.gz
  slave editor.de.1.gz: /usr/share/man/de/man1/vim.1.gz
  slave editor.fr.1.gz: /usr/share/man/fr/man1/vim.1.gz
  slave editor.it.1.gz: /usr/share/man/it/man1/vim.1.gz
  slave editor.ja.1.gz: /usr/share/man/ja/man1/vim.1.gz
  slave editor.pl.1.gz: /usr/share/man/pl/man1/vim.1.gz
  slave editor.ru.1.gz: /usr/share/man/ru/man1/vim.1.gz
root@vim-test:/#

The update vim to 2:8.1.2136-1:

[...]
Setting up vim (2:8.1.2136-1) ...
update-alternatives: warning: alternative /usr/bin/vim.basic (part of link 
group vim) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/vim is dangling; it will be 
updated with best choice
update-alternatives: using /usr/libexec/vim/vim.basic to provide /usr/bin/vim 
(vim) in auto mode
update-alternatives: warning: alternative /usr/bin/vim.basic (part of link 
group vimdiff) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/vimdiff is dangling; it will be 
updated with best choice
update-alternatives: using /usr/libexec/vim/vim.basic to provide 
/usr/bin/vimdiff (vimdiff) in auto mode
update-alternatives: warning: alternative /usr/bin/vim.basic (part of link 
group rvim) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/rvim is dangling; it will be 
updated with best choice
update-alternatives: using /usr/libexec/vim/vim.basic to provide /usr/bin/rvim 
(rvim) in auto mode
update-alternatives: warning: alternative /usr/bin/vim.basic (part of link 
group rview) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/rview is dangling; it will be 
updated with best choice
update-alternatives: using /usr/libexec/vim/vim.basic to provide /usr/bin/rview 
(rview) in auto mode
update-alternatives: warning: alternative /usr/bin/vim.basic (part of link 
group vi) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/vi is dangling; it will be 
updated with best choice
update-alternatives: using /usr/libexec/vim/vim.basic to provide /usr/bin/vi 
(vi) in auto mode
update-alternatives: warning: alternative /usr/bin/vim.basic (part of link 
group view) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/view is dangling; it will be 
updated with best choice
update-alternatives: using /usr/libexec/vim/vim.basic to provide /usr/bin/view 
(view) in auto mode
update-alternatives: warning: alternative /usr/bin/vim.basic (part of link 
group ex) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/ex is dangling; it will be 
updated with best choice
update-alternatives: using /usr/libexec/vim/vim.basic to provide /usr/bin/ex 
(ex) in auto mode
update-alternatives: warning: alternative /usr/bin/vim.basic (part of link 
group editor) doesn't exist; removing from list of alternatives
update-alternatives: warning: /etc/alternatives/editor is dangling; it will be 
updated with best choice
update-alternatives: using /bin/nano to provide /usr/bin/editor (editor) in 
auto mode
[...]

But now

root@vim-test:/# update-alternatives --display editor
editor - auto mode
  link best version is /bin/nano
  link currently points to /bin/nano
  link editor is /usr/bin/editor
  slave editor.1.gz is /usr/share/man/man1/editor.1.gz
  slave editor.da.1.gz is /usr/share/man/da/man1/editor.1.gz
  slave editor.de.1.gz is /usr/share/man/de/man1/editor.1.gz
  slave editor.fr.1.gz is /usr/share/man/fr/man1/editor.1.gz
  slave editor.it.1.gz is /usr/share/man/it/man1/editor.1.gz
  slave editor.ja.1.gz is /usr/share/man/ja/man1/editor.1.gz
  slave editor.pl.1.gz is /usr/share/man/pl/man1/editor.1.gz
  slave editor.r

Bug#941855: dunst: Daily systemd errors: "Failed to start Dunst notification daemon."

2019-10-12 Thread Francois Marier

On 2019-10-12 at 09:25:20, Nikos Tsipinakis wrote:
> This is usually caused by not having exported the DISPLAY variable into the
> systemd environment, there has been extensive discussion about this in #347[1]
> upstream.
>
> How are you starting X11, are you using a custom xinitrc?

I've got this line in my ~/.config/i3/config:

  exec --no-startup-id /home/francois/devel/remote/user-scripts/startup

and that corresponds to a script [1] with these lines:

  /usr/bin/systemctl --user import-environment DISPLAY
  /usr/bin/systemctl status --user dunst

I looked at both of the following bugs before switching [2] to the systemd
service:

  https://github.com/dunst-project/dunst/issues/347
  https://github.com/dunst-project/dunst/issues/611

> However it is weird that systemd reports that dunst is running even though it
> obviously fails to start. I'm not sure what is going on there.

I don't think it fails to start because it works fine and it looks like
this:

  $ systemctl status --user dunst.service
  ● dunst.service - Dunst notification daemon
 Loaded: loaded (/usr/lib/systemd/user/dunst.service; enabled; vendor 
preset: enabled)
 Active: active (running) since Fri 2019-10-11 19:21:31 PDT; 15h ago
   Docs: man:dunst(1)
   Main PID: 5330 (dunst)
 Memory: 4.0M
 CGroup: /user.slice/user-1000.slice/user@1000.service/dunst.service
 └─5330 /usr/bin/dunst

  $ pgrep -a dunst
  5330 /usr/bin/dunst

The part that confuses me is that once a day (always almost exactly at the
same time) it tries to start or restart (and fails) even though it's already
running in my user session.

Is there a cron-like job that runs every morning?

Francois

[1] https://github.com/fmarier/user-scripts/blob/master/startup
[2] 
https://github.com/fmarier/user-scripts/commit/e8be9777cb7af012962408ba8f66ff19b13a485e

-- 
https://fmarier.org/

Bug#942193: dwz: dh_dwz freecad build regression: write_die: Assertion `value && refdcu->cu_kind != CU_ALT' failed.

2019-10-12 Thread Matthias Klose


Control: tags -1 + moreinfo
Control: severity -1 grave

please could you attach the binary, or put it somewhere on the web?

On 12.10.19 02:11, Kurt Kremitzki wrote:

Package: dwz
Version: 0.12-3
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

I'm not certain if critical is the correct severity, but it seems dwz is
causing a build regression in freecad. As part of Python 3 removal, I
dropped the Python 2 build and packages in a new upload This should
have  been uneventful, but somehow, the builds for i386, mipsel, and
s390x are all failing with essentially the same error, as follows:

```
make[1]: Leaving directory '/<>'
dh_dwz -a -O--buildsystem=cmake
dwz: /build/dwz-aS1MPf/dwz-0.13/dwz.c:9310: write_die: Assertion `value && 
refdcu->cu_kind != CU_ALT' failed.
dh_dwz: dwz 
-mdebian/libfreecad-python3-0.18/usr/lib/debug/.dwz/i386-linux-gnu/libfreecad-python3-0.18.debug
 -M/usr/lib/debug/.dwz/i386-linux-gnu/libfreecad-python3-0.18.debug -- 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/DraftUtils.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Drawing.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/DrawingGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Fem.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/FemGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/FreeCAD.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/FreeCADGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Image.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/ImageGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Import.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/ImportGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Inspection.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/InspectionGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Measure.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Mesh.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/MeshGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/MeshPart.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/MeshPartGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Part.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/PartDesignGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/PartGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Path.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/PathGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/PathSimulator.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Points.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/PointsGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/QtUnitGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Raytracing.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/RaytracingGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/ReverseEngineering.so
 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/ReverseEngineeringGui.so
 debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Robot.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/RobotGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Sketcher.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/SketcherGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Spreadsheet.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/SpreadsheetGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Start.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/StartGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Surface.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/SurfaceGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/TechDraw.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/TechDrawGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/Web.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/WebGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/_PartDesign.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/area.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libDriver.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libDriverDAT.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libDriverSTL.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libDriverUNV.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libFreeCADApp.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libFreeCADBase.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/libFreeCADGui.so 
debian/libfreecad-python3-0.18/usr/lib/freecad-python3/lib/lib

Bug#942224: asymptote: VIM addon cannot be managed with vim-addons and fails to enable syntax highlighting

2019-10-12 Thread Francesco Poli (wintermute)

Package: asymptote
Version: 2.53-1
Severity: normal
Tags: patch

Hello,
thanks for maintaining Asymptote in Debian!

I am giving it a try, but I wanted to see syntax highlighting in VIM.
It seems to me that a VIM addon is shipped in the package:

  $ dpkg -L asymptote | grep vim
  /usr/share/vim
  /usr/share/vim/addons
  /usr/share/vim/addons/ftdetect
  /usr/share/vim/addons/ftdetect/asy_filetype.vim
  /usr/share/vim/addons/ftplugin
  /usr/share/vim/addons/ftplugin/asy.vim

But there seem to be two issues: there's no registry file (hence
vim-addons does not find the addon and cannot manage it) and
the syntax file is placed in ftplugin/ (which looks wrong to me).

In order to enable VIM support for Asymptote I had to prepare
the following file:

  $ cat asymptote.yaml
  addon: asymptote
  description: "easier editing of Asymptote .asy files"
  files:
- syntax/asy.vim
- ftdetect/asy_filetype.vim

and to issue the following commands (as root):

  # mv /usr/share/vim/addons/ftplugin/asy.vim /usr/share/vim/addons/syntax/
  # cp asymptote.yaml /usr/share/vim/registry/
  # chown root:root /usr/share/vim/registry/asymptote.yaml
  # chmod 644 /usr/share/vim/registry/asymptote.yaml

After, I was finally able to manage the addon for my regular user
with:

  $ vim-addons install asymptote

which automatically set up the following symlinks:

  ~/.vim/syntax/asy.vim -> /usr/share/vim/addons/syntax/asy.vim
  ~/.vim/ftdetect/asy_filetype.vim -> 
/usr/share/vim/addons/ftdetect/asy_filetype.vim

Now, when I open a .asy file, VIM automatically enables the appropriate
syntax highlighting.


Please add file asymptote.yaml to package asymptote (so that it
is installed to /usr/share/vim/registry/asymptote.yaml )
and change file debian/asymptote.install so that file asy.vim
is installed to /usr/share/vim/addons/syntax/ (and not to
ftplugin/ ...).

Thanks for your time!
Bye.


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

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

Versions of packages asymptote depends on:
ii  freeglut32.8.1-3+b1
ii  ghostscript  9.27~dfsg-3.1
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b1
ii  install-info 6.6.0.dfsg.1-2
ii  libc62.29-2
ii  libfftw3-double3 3.3.8-2
ii  libgc1c2 1:7.6.4-0.4
ii  libgcc1  1:9.2.1-8
ii  libgl1   1.1.0-1+b1
ii  libglew2.1   2.1.0-4+b1
ii  libgsl23 2.5+dfsg-6+b1
ii  libreadline8 8.0-3
ii  libsigsegv2  2.12-2
ii  libstdc++6   9.2.1-8
ii  libtinfo66.1+20190803-1
ii  python3  3.7.5-1
ii  tex-common   6.12
ii  texlive-binaries 2019.20190605.51237-3
ii  texlive-latex-base   2019.20190930-1
ii  texlive-plain-generic2019.20190930-2
ii  texlive-pstricks 2019.20190930-2
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages asymptote recommends:
ii  asymptote-doc  2.53-1

Versions of packages asymptote suggests:
ii  asymptote-x11  2.53-1

-- no debconf information

Bug#940571: dpkg-buildflags should support an optimization area for things like lto and pgo

2019-10-12 Thread Matthias Klose


On 12.10.19 06:08, Guillem Jover wrote:

On Thu, 2019-10-10 at 10:39:23 +0200, Matthias Klose wrote:

On 09.10.19 20:28, Guillem Jover wrote:

I take you are requesting both adding this and also enabling LTO by
default?


the infrastructure should provide both, having the option to enable it by a
flag when it's not the default, and to disable it by default, when it's
enabled by default.


This is something provided for all supported features, but this does
not answer whether you are requesting this to be the default or not.


Not yet. But yes, it should be an option for bullseye.


Or is your plan to enable this by default in gcc instead of via flags
passed by dpkg-buildflags?


No, optimization flags are not turned on by default in GCC.


I'm fine with the former (even implementing that myself), but the latter
would need to go through [Q] first. And I see this can cause breakage [O]
according to the OpenSUSE people.

[Q] 

[O] 



well, yes, it breaks a few packages, more than a handful, but not the whole
archive, and you can name these packages.  The question for now is how to
name that option, and how to disable that on a per package basis. And we
probably want to enable that for a subset of architectures first, which have
been test built.  So the first thing is the name, so people can disable lto,
before we even consider making it the default.


If you are suggesting repeating the same disaster that we have with
pie, with the default set by gcc being arch opt-in, then I'm honestly
less than interested in doing the same here, and I'd consider this a
direct wontfix. :/


pgo doesn't directly translate into compiler flags, but almost always
requires upstream support in the build system.  pgo usually is enabled by
some configure options which are specific to the upstream build.  pgo
usually requires running a profiling task, so this optimization probably
should be disabled for cross builds, otoh, the cross build then is different
to the native build (although it should create a functional identical
package).


I don't see how dpkg can support PGO, so I'm excluding that from this
request, as it seems this would be pretty much unactionable.


The only thing it would do is to provide a common interface to
enable/disable it, not an implementation.


Ok, I guess, given that using unknown features for known areas emits
warnings (even though it seems weird and unexpected to support a feature
for which dpkg-buildflags will never be able to emit flags for, and some
other name could be used for this, but consistency would be nice).


CC'ing Holger here, as this came up with reproducible builds.  PGO and 
reproducible builds are currently a no-go.  So having a nopgo flag would enable 
testing reproducible builds without pgo, if they succeed or not.


Mathias

Bug#940973: libarchive-zip-perl breaks strip-nondeterminism autopkgtest: error: becoming Archive::Zip::DirectoryMember

2019-10-12 Thread tony mancill

On Sat, Oct 12, 2019 at 06:29:08PM +0200, gregor herrmann wrote:
> On Thu, 10 Oct 2019 06:30:52 -0700, tony mancill wrote:
> 
> error: No member named $memberName 
>  at /usr/share/perl5/Archive/Zip/Archive.pm line 411.
>   
> Archive::Zip::Archive::contents(Archive::Zip::Archive=HASH(0x5622c68d6100), 
> "META-INF/MANIFEST.MF") called at /usr/bin/jh_manifest line 297
>   
> main::update_jar("/build/libquartz2-java-2.3.0/debian/libquartz2-java/usr/share"...,
>  undef) called at /usr/bin/jh_manifest line 147
> Could not read manifest from 
> /build/libquartz2-java-2.3.0/debian/libquartz2-java/usr/share/java/quartz2-2.3.0.jar
>  (2):  at /usr/bin/jh_manifest line 298.
> 
> 
> So the same error as above. What jh_manifest is doing is:
> 
> sub update_jar{
> my $jar = shift;
> my $merge = shift;
> my $zip = Archive::Zip->new();
> my $con;
> my $manifest;
> my $stat;
> my $dirty = 0;
> my $main;
> my $new_manifest = 0;
> # stringify or $zip will make a call back that fails.
> $zip->read( "$jar" ) == AZ_OK or error("Could not read $jar: $!");
> ($con, $stat) = $zip->contents( 'META-INF/MANIFEST.MF' );
> die("Could not read manifest from $jar ($stat): $!")
> unless(!defined($stat) || $stat == AZ_OK);
> 
> i.e. it tries to return META-INF/MANIFEST.MF from the jar file.
> 
> But:
> 
> # unzip -l debian/libquartz2-java/usr/share/java/quartz2-2.3.0.jar | grep -c 
> MANIFEST
> 0

Thank you Gregor!  I'll start rooting around in the Java toolchain.

Cheers,
tony


signature.asc
Description: PGP signature

Bug#936146: archivemail: Python2 removal in sid/bullseye

2019-10-12 Thread Sean Whitton

Hello,

On Fri 30 Aug 2019 at 01:43PM -07, Sean Whitton wrote:

> I intend to take a shot at converting the package.

I'm no longer intending to do this, having rewritten the subset of
archivemail's functionality that I need using perl's Mail::Box module.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#935845: node-lodash._createRound calls deprecated root object

2019-10-12 Thread Jonas Smedegaard

reopen -1
retitle -1 lodash: node-lodash._createRound calls deprecated root object
reassign -1 lodash
thanks

The real bug is that node-lodash._createRound calls deprecated root object.

This was fixed upstream already, but mysteriously missed in debian:
https://github.com/lodash/lodash/commit/d73d82d#diff-a3f56cdc79b5cced4fb021ebed6d3255R1

 - Jonas

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

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


signature.asc
Description: signature

Bug#941928: RFS: scons-doc/3.1.1+repack-1 -- Documentation for SCons, a replacement for Make

2019-10-12 Thread Adam Borowski

On Mon, Oct 07, 2019 at 07:10:28PM +0200, Jörg Frings-Fürst wrote:
>  * Package name: scons-doc
>Version : 3.1.1+repack-1

> Changes since the last upload:
> 
>* New upstream release.
>  - Rewrite Files-Excluded.
>* Migrate to debhelper 12:
>  - Change debian/compat to 12.
>  - Bump minimum debhelper version in debian/control to >= 12.
>* Declare compliance with Debian Policy 4.4.1 (No changes needed).
>* debian/copyright: Add year 2019.

The actual changelog diff is:

-scons-doc (3.1.0+repack-1) unstable; urgency=medium
+scons-doc (3.1.1+repack-1) unstable; urgency=medium
 
   * New upstream release.
 - Rewrite Files-Excluded.
   * Migrate to debhelper 12:
 - Change debian/compat to 12.
 - Bump minimum debhelper version in debian/control to >= 12.
-  * Declare compliance with Debian Policy 4.4.0. (No changes needed).
+  * Declare compliance with Debian Policy 4.4.1 (No changes needed).
   * debian/copyright: Add year 2019.
 
- -- Jörg Frings-Fürst   Tue, 23 Jul 2019 17:04:59 +0200
+ -- Jörg Frings-Fürst   Mon, 07 Oct 2019 18:55:01 +0200

which has those "-" lines it shouldn't have.  The proper way is a contiguous
set of "+" in one piece at the start of the file.  In other words, please
don't delete changelog entries that were already in the archive.

Otherwise, looks good.

I hate hate hate your upstream's autogenerated timestamps, linestamps,
versionstamps, hashstamps, codenamestamps all around the source -- but
that's upstream's fault not yours.


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#942223: SATA Hot Plug Seagate disks problem

2019-10-12 Thread Сергей Фёдоров


Package: base
Severity: normal



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

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

I use Seagate hard drives.
Barracuda st2000dm008 drives do not support Hotplug, so they work fine.
Other Seagate drives that don't support Hot Plug work fine, too.
Discs Barracuda st2000dm001, Constellation ES3 st2000nm0033, st2000nc001
support Hotplug, so there are problems with Them.

Initially in BIOS Hot Plug support was turned off for Intel X79 Express Chipset,
but for Marvell 9128 SATA Controller there is no such option. Disks that support
Hotplug, were recognized at Linux loading and further worked. But, within a 
week,
if their not to switch every 2-2 days to other SATA ports, they started clicking
loudly excitedly, spoiling the information on the write, creating a failure when
reading files. And after a while the disks stopped working. So died 3 disks
for several years. When turned off in BIOS "Hot Plug" drives
Barracuda ST2000DM001, Constellation ES3 ST2000NM0033, ST2000NC001 are 
identified
only when booting Linux. If you connect them on the power line after booting
Linux, they are not available.

After enabling the "Hot Plug Enabled" option in the BIOS, drives that support
Hot Plug, after booting Linux began to be automatically recognized and connected
when feeding on them power supply . Then, these disks work fine until shutdown
computer's. But, if before booting Linux, such disks do not disconnect
from the power supply, then after a while they begin to click, which serves
the first sign of their imminent death, as already described above.

I attach a log file.  

messages_disk_error_my
Description: Binary data

Bug#942222: crash at startup, like #734405 (ValueError: numpy.dtype does not appear to be the correct type object)

2019-10-12 Thread pk

Package: seekwatcher
Version: 0.12+hg20091016-3
Severity: grave

In Debian 10 and current Debian 9:

# seekwatcher
Traceback (most recent call last):
  File "/usr/bin/seekwatcher", line 58, in 
from seekwatcher import rundata
  File "numpy.pxd", line 43, in seekwatcher.rundata (seekwatcher/rundata.c:7885)
ValueError: numpy.dtype does not appear to be the correct type object

Previous report:

Bug#940973: libarchive-zip-perl breaks strip-nondeterminism autopkgtest: error: becoming Archive::Zip::DirectoryMember

2019-10-12 Thread gregor herrmann

Control: forwarded -1 
https://github.com/redhotpenguin/perl-Archive-Zip/issues/68

On Tue, 24 Sep 2019 16:35:11 +0200, gregor herrmann wrote:

> #v+
> Reading ZIP archive failed: IO error: reading local extra field :  
> 
> error: becoming Archive::Zip::DirectoryMember 
> # Looks like your test exited with 29 just after 20.
> #v-

Forwarded upstream as a new issue with a minimal reproducer.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Kurt Ostbahn & Kombo: Da Talking Plachutta Blues


signature.asc
Description: Digital Signature

Bug#942172: clamav-daemon: After upgrade, clamd cannon create /var/run/clamav/clamd.ctl and stop.

2019-10-12 Thread Hugo Lefeuvre

Hi,

I did not notice this bug during my tests. I have just tried to reproduce
it by upgrading a jessie system from 0.100.3+dfsg-0+deb8u1 to
0.101.4+dfsg-0+deb8u1 and did not experience any issue restarting
clamav-daemon.

Furthermore, /var/run/clamav/ belonging to root:root or clamav:root does
not seem to change anything on my system. My understanding is that
/var/run/clamav/clamd.ctl is created by systemd, not by the daemon itself.

Also, I don't think chown clamav /var/run/clamav should survive a restart.

Filipe: did you also experience this bug?

Thanks.

regards,
Hugo

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C


signature.asc
Description: PGP signature

Bug#940973: libarchive-zip-perl breaks strip-nondeterminism autopkgtest: error: becoming Archive::Zip::DirectoryMember

2019-10-12 Thread gregor herrmann

On Thu, 10 Oct 2019 06:30:52 -0700, tony mancill wrote:

> > error: No member named $memberName 
> >  at /usr/share/perl5/Archive/Zip/Archive.pm line 411.
> > 
> > Archive::Zip::Archive::contents(Archive::Zip::Archive=HASH(0x55bbbdadedd0), 
> > "META-INF/MANIFEST.MF") called at /usr/bin/jh_manifest line 297
> > main::update_jar("/<>/debian/li"..., undef) called at 
> > /usr/bin/jh_manifest line 147
> > Could not read manifest from 
> > /<>/debian/libquartz2-java/usr/share/java/quartz2-2.3.0.jar 
> > (2):  at /usr/bin/jh_manifest line 298.
> > jh_classpath: jh_manifest -plibquartz2-java 
> > --classpath=/usr/share/java/slf4j-api.jar 
> > debian/libquartz2-java/usr/share/java/quartz2.jar returned exit code 255
> > make: *** [debian/rules:4: binary] Error 255
> 
> I don't know if this is the same issue but wanted to mention it here,
> since it seems potentially related.  I'd be glad to provide more
> debugging information or testing if that would help.  libquartz2-java is
> an example of a source package that exhibits this issue.

I tried with libquartz2-java now and found the following:

# jh_manifest -plibquartz2-java --classpath=/usr/share/java/slf4j-api.jar 
debian/libquartz2-java/usr/share/java/quartz2.jar
error: No member named $memberName 
 at /usr/share/perl5/Archive/Zip/Archive.pm line 411.

Archive::Zip::Archive::contents(Archive::Zip::Archive=HASH(0x5622c68d6100), 
"META-INF/MANIFEST.MF") called at /usr/bin/jh_manifest line 297

main::update_jar("/build/libquartz2-java-2.3.0/debian/libquartz2-java/usr/share"...,
 undef) called at /usr/bin/jh_manifest line 147
Could not read manifest from 
/build/libquartz2-java-2.3.0/debian/libquartz2-java/usr/share/java/quartz2-2.3.0.jar
 (2):  at /usr/bin/jh_manifest line 298.

So the same error as above. What jh_manifest is doing is:

sub update_jar{
my $jar = shift;
my $merge = shift;
my $zip = Archive::Zip->new();
my $con;
my $manifest;
my $stat;
my $dirty = 0;
my $main;
my $new_manifest = 0;
# stringify or $zip will make a call back that fails.
$zip->read( "$jar" ) == AZ_OK or error("Could not read $jar: $!");
($con, $stat) = $zip->contents( 'META-INF/MANIFEST.MF' );
die("Could not read manifest from $jar ($stat): $!")
unless(!defined($stat) || $stat == AZ_OK);

i.e. it tries to return META-INF/MANIFEST.MF from the jar file.

But:

# unzip -l debian/libquartz2-java/usr/share/java/quartz2-2.3.0.jar | grep -c 
MANIFEST
0
# unzip -l debian/libquartz2-java/usr/share/java/quartz2-2.3.0.jar | grep 
META-INF
0  2019-10-12 16:19   META-INF/
0  2019-10-12 16:19   META-INF/terracotta/
  142  2019-10-12 16:19   META-INF/terracotta/public-api-types
0  2019-10-12 16:19   META-INF/maven/
0  2019-10-12 16:19   META-INF/maven/org.quartz-scheduler/
0  2019-10-12 16:19   META-INF/maven/org.quartz-scheduler/quartz/
 6144  2019-10-12 16:19   META-INF/maven/org.quartz-scheduler/quartz/pom.xml
  101  2019-10-12 16:19   
META-INF/maven/org.quartz-scheduler/quartz/pom.properties

So there doesn't seem to be a META-INF/MANIFEST.MF file in this jar,
and Archive::Zip seems to do the right thing.

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Kurt Ostbahn & Kombo: Da Talking Plachutta Blues

signature.asc
Description: Digital Signature

Bug#933469: Solved

2019-10-12 Thread Jose Luis Blanco

This bug has been solved with the new uploaded version: mrpt 1:1.5.8-1

Already sent a mail to cont...@bugs.debian.org to mark it as solved.

Cheers,
JL

Bug#942221: openbox: padding next to the title

2019-10-12 Thread pk

Package: openbox
Version: 3.6.1-8
Severity: minor

NLIMC with Artwiz-boxed shows padding at the left. Same for any theme
with a title background different from the titlebar background.


This behavior differs from fedora 30, which has openbox 3.6.1 like
debian 10, and from debian 9.

Bug#859388: Issue still present in buster with dmsetup 1.02.155-3

2019-10-12 Thread Athanasius

Oct 12 14:53:49 tuesday blkdeactivate[5119]: Deactivating block devices:
Oct 12 14:53:49 tuesday blkdeactivate[5119]: /sbin/blkdeactivate: line 345: 
/bin/sort: No such file or directory

16:22:36 0$ grep sort /sbin/blkdeactivate 
SORT_MNT="/bin/sort -r -u -k 4"
16:24:07 0$ ls -l /bin/sort /usr/bin/sort
ls: cannot access '/bin/sort': No such file or directory
-rwxr-xr-x 1 root root 114120 Feb 28  2019 /usr/bin/sort
-- 
- Athanasius = Athanasius(at)miggy.org / https://miggy.org/
  GPG/PGP Key: https://miggy.org/gpg-key
   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME

Bug#939890: buster-pu: package rpcbind/1.2.5-0.3+deb10u1

2019-10-12 Thread Josue Ortega

On 2019-10-12 03:52, Julien Cristau wrote:
> Control: tag -1 - moreinfo
> Control: tag -1 + confirmed
> 
> On Thu, Oct 03, 2019 at 04:58:23PM -0700, Josue Ortega wrote:
>> Hi,
>>
>> I've included the recommended changes for the fix:
>>
>> rpcbind (1.2.5-0.3+deb10u1) buster; urgency=medium
>>
>>   * Add 00-rmt-calls.patch (Closes: #939877):
>> + Add command line option to enable remote calls at runtime
>> + Refresh debian/patches
>>   * debian/control: Update maintainer information
>>   * Add debian/README.debian explaining remote calls activation for
>> Debian systems
>>   * Add debian/NEWS
>>
> This looks reasonable to me, go ahead.
> 
> Cheers,
> Julien

Thanks, uploaded.

Cheers,

--Josue

Bug#942220: please move perl-modules-5.xx to section libs

2019-10-12 Thread Ivo De Decker

package: perl
severity: important
version: 5.30.0-6

Hi,

Currently, perl-modules-5.30 is in section perl. Please move it to section
libs.

Britney only allows 'smooth updates' for binaries in section libs (or
oldlibs). During a perl transition, this should allows the old libperl5.xx to
stay in testing when a newer perl migrates. This means only the packages that
depend on the api need to go in together.

This currently doesn't work, because libperl5.30 (section libs) depends on
perl-modules-5.30 (section perl). As the old perl-modules-5.xx isn't allowed
to stay in testing, libperl5.xx can't stay around either. Moving
perl-modules-5.30 to libs would fix that (for the next transition).

Thanks,

Ivo

P.S. For the transition that just finished, I worked around this by
temporarily changing the britney config.

Bug#934927: transition: libgit2

Control: tags -1 confirmed

On 16/08/2019 20:21, Jongmin Kim wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> Control: block -1 by 931697
> Control: block -1 by 931695
> Control: block -1 by 931693
> 
> Hello release team!
> 
> I'd like to request a transition slot for libgit2.
> 
> libgit2 0.28 is in experimental and ready to start the transition from
> 0.27 in unstable.
> 
> I've rebuilt the relevant reverse-build-dependencies from unstable. The
> following succeed and can be binNMU'd directly:
> 
>   calligra cargo fritzing gall geany-plugins gitg gnuastro horizon-eda
>   libgit2-glib ktexteditor kup-backup rust-libgit2-sys
> 
> The following packages have fixed versions in experimental:
> 
>   * python-pygit2
>   * ruby-rugged
> 
> The following fail, but probably just need to be bumped to the latest
> upstream version:
> 
>   * golang-gopkg-libgit2-git2go.v27 (#931697)
>   * libgit-raw-perl (#931695)
> 
> The following fail, and probably need more invasive changes such as
> upgrading to the new API:
> 
>   * julia (#931693)

With only libgit-raw-perl and julia remaining, which aren't key packages have
one and none (resp) rdeps, and with all the time that has passed since their
bugs were reported with no action from the maintainers so far, I think we can go
ahead with this and have those removed from testing if necessary.

Cheers,
Emilio

Bug#941027: transition: bullet

2019-10-12 Thread Markus Koschany



Am 12.10.19 um 15:46 schrieb Emilio Pozuelo Monfort:
> Control: tags -1 confirmed
[...]
> Please go ahead.
> 
> Emilio

Uploaded to unstable, thanks.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#942217: nmu: libapache2-mod-security2_2.9.3-1

2019-10-12 Thread Alberto Gonzalez Iniesta

On Sat, Oct 12, 2019 at 03:57:14PM +0100, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Sat, 2019-10-12 at 15:16 +0200, Alberto Gonzalez Iniesta wrote:
> > nmu libapache2-mod-security2_2.9.3-1 . amd64 . buster . -m "Build
> > with libapr-1.6.5"
> > 
> > Looks like my build environment wasn't up to date when I built this.
> > The amd64 package is linked with an older version of libapr1 than the
> > one in Buster.
> > Sorry for the mess.
> 
> What practical issues does this cause?
> 

It's probably just a warning, reported here:
https://github.com/SpiderLabs/ModSecurity/issues/2139

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Bug#941917: nginx: FTBFS on several architectures: luajit.h: No such file or directory

2019-10-12 Thread gregor herrmann

On Thu, 10 Oct 2019 23:46:26 +0200, gregor herrmann wrote:

> Any news here? This is the last blocker for the perl 5.30 transition.

The release team managed to binNMU nginx 1.14.2-3 in
testing-proposed-updates against perl 5.30, so this is not a blocker
anymore.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Der Junge mit der Gitarre: Nie wieder Grand Prix


signature.asc
Description: Digital Signature

Bug#942217: nmu: libapache2-mod-security2_2.9.3-1

2019-10-12 Thread Adam D. Barratt

Control: tags -1 + moreinfo

On Sat, 2019-10-12 at 15:16 +0200, Alberto Gonzalez Iniesta wrote:
> nmu libapache2-mod-security2_2.9.3-1 . amd64 . buster . -m "Build
> with libapr-1.6.5"
> 
> Looks like my build environment wasn't up to date when I built this.
> The amd64 package is linked with an older version of libapr1 than the
> one in Buster.
> Sorry for the mess.

What practical issues does this cause?

Regards,

Adam

Bug#863408: ITP: bibledit-cloud -- Bible editor server

2019-10-12 Thread Teus Benschop

Package: wnpp
Followup-For: Bug #863408
Owner: Teus Benschop 

I am intending to package the existing upstream tarball and create a proper 
Debian package from it.

It already exists in Ubuntu and works well there.

The plan is to base the Debian packaging on the existing Ubuntu packaging.

This is expected to speed all up.

Bug#860347: xserver-xorg-core: it's because sh is dash

2019-10-12 Thread Dario Niedermann


I stumbled into this bug today and, according to my findings, this is
due to `/bin/sh' being symlinked to `/bin/dash'.

If you replace `#!/bin/sh' with `#!/bin/bash', it works.

--
Dario Niedermann. Also on the Internet at:

gopher://darioniedermann.it/  <>  https://www.darioniedermann.it/

Bug#940595: transition: hypre

2019-10-12 Thread Drew Parsons


On 2019-10-12 22:19, Emilio Pozuelo Monfort wrote:

Control: tags -1 - confirmed

Hi Drew,

On 12/10/2019 16:08, Drew Parsons wrote:

On 2019-10-12 21:59, Emilio Pozuelo Monfort wrote:


I'd like to proceed with the hypre transition to 2.17.0.

I've tested that petsc and sundials build successfully with the new
hypre.


Please go ahead.


Thanks Emilio.  2.18.0 is now released, and waiting now in the new 
queue.
Perhaps we should hold on a bit and jump straight to 2.18.0.  That 
will save

having to process 2 transitions. What do you think?


Sure, that makes sense. Let us know once things are ready for 2.18.



Thanks again. I'll send the note once it's stabilised in experimental.

Drew

Bug#940595: transition: hypre

Control: tags -1 - confirmed

Hi Drew,

On 12/10/2019 16:08, Drew Parsons wrote:
> On 2019-10-12 21:59, Emilio Pozuelo Monfort wrote:
>>>
>>> I'd like to proceed with the hypre transition to 2.17.0.
>>>
>>> I've tested that petsc and sundials build successfully with the new
>>> hypre.
>>
>> Please go ahead.
> 
> Thanks Emilio.  2.18.0 is now released, and waiting now in the new queue.
> Perhaps we should hold on a bit and jump straight to 2.18.0.  That will save
> having to process 2 transitions. What do you think?

Sure, that makes sense. Let us know once things are ready for 2.18.

Cheers,
Emilio

Bug#940595: transition: hypre

2019-10-12 Thread Drew Parsons


On 2019-10-12 21:59, Emilio Pozuelo Monfort wrote:


I'd like to proceed with the hypre transition to 2.17.0.

I've tested that petsc and sundials build successfully with the new
hypre.


Please go ahead.


Thanks Emilio.  2.18.0 is now released, and waiting now in the new 
queue. Perhaps we should hold on a bit and jump straight to 2.18.0.  
That will save having to process 2 transitions. What do you think?


Drew

Bug#940595: transition: hypre

Control: tags -1 confirmed

On 17/09/2019 17:35, Drew Parsons wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> I'd like to proceed with the hypre transition to 2.17.0.
> 
> I've tested that petsc and sundials build successfully with the new
> hypre.

Please go ahead.

Emilio

Bug#940350: transition: libgweather

Control: tags -1 confirmed

On 16/09/2019 11:23, Dmitry Shachnev wrote:
> Hi Andreas,
> 
> On Sun, Sep 15, 2019 at 11:39:16PM +0200, Andreas Henriksson wrote:
>> Dear release team,
>>
>> I'm requesting a transition slot for libgweather on behalf of the
>> Debian GNOME Team.
> 
> Thanks for requesting this.
> 
>> From libgweather NEWS:
>>
>>> This version of the library bumps the soname after an ABI break in 3.28.0
>>> that went unnoticed. If you see strange crashes, make sure to bump the
>>> required version of libgweather to 3.28.0 or newer.
>>
>> In other words we should already be affected by the "new" ABI/API
>> and no issues should arise.
> 
> Upstream NEWS is incorrect. The ABI break happened in 3.31.91, so it has not
> reached Debian unstable (fortunately).
> 
> See https://gitlab.gnome.org/GNOME/libgweather/issues/17#note_546778.
> 
> I believe that still there will be no issues. According to codesearch no
> package is using the GWEATHER_LOCATION_ADM2 enum item that was removed.

Go ahead.

Emilio

Bug#942219: systemd-backlight@backlight:dell_backlight.service fails at boot for dell d600, d620, d820

2019-10-12 Thread Rado Q

Package: systemd
Version: 241-7~deb10u1

Dear Maintainer,
   * What led up to the situation?
Installation of debian10.

   * What exactly did you do (or not do) that was effective (or ineffective)?
Boot.

   * What was the outcome of this action?
Failed systemd-backlight@backlight:dell_backlight.service .

   * What outcome did you expect instead?
Startup without failure.


This happens with dell d600, d620, d820.
It works OK for dell vostro 1520.

How to get more info?

Bug#941078: transition: postgresql-12

Control: tags -1 confirmed

On 24/09/2019 12:49, Christoph Berg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> PostgreSQL 12 rc1 is due to be released this week. Ben patch attached.
> 
> As usual the transition will be done using sourceful uploads, so
> little release team interaction is expected to be needed.

Go ahead.

Emilio

Bug#941237: transition: brltty

Control: tags -1 confirmed

On 26/09/2019 23:20, Samuel Thibault wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> I'd like to upload brltty which introduces libbrlapi0.7 instead of
> libbrlapi0.6. The only rdep is qemu, which builds fine against it.

Sure, please go ahead.

Emilio

Bug#941289: transition: gpsd

Control: tags -1 confirmed

On 27/09/2019 23:44, Bernd Zeimetz wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> I'd (finally) like to start the gpsd transition to libgps25 and friends.
> 
> There reverse dependencies build well against the new version
> (thanks to Christian Ehrhardt for testing), with the only
> exception being collectd, which is RC buggy and not in testing
> right now anyway. The rc issues (and others) seem to be fixed in an
> upcoming upstream release - and I don't want to wait for that..
> 
> There were some other broken rdeps, but they are removed from the
> archive for good...
> 
> Please let me know when I should upload to unstable.

Go ahead.

Emilio

Bug#941027: transition: bullet