date:20191006

Package: ftp.debian.org
X-Debbugs-Cc: pytag...@packages.debian.org
Affects: src:pytagsfs

pytagsfs was last uploaded in 2012. It has been unmaintained upstream
just as long.

It has very low popcon and no reverse-dependencies. Without
maintainers or users, it doesn't look like it will be ported away from
Python2.

Please remove pytagsfs from Debian.

Thanks,
Jeremy Bicha

Bug#941882: pytagsfs: Please remove python-gamin from Build-Depends

Source: pytagsfs
Version: 0.9.2-6
Severity: serious
Tags: bullseye sid

Please remove python-gamin from the Build-Depends for pytagsfs.

As part of the Python2 removal, I would like to remove the
python-gamin binary package and that Build-Depends is the only reverse
dependency.

Thanks,
Jeremy Bicha

Bug#941881: dillo: HTTPS + IPv6 doesn't work (download stalling forever)

2019-10-06 Thread Axel Beckert

Package: dillo
Version: 3.0.4-2
Severity: important
Tags: upstream ipv6
Control: found -1 3.0.5-5
Control: found -1 3.0.5-3
Control: forwarded -1 
http://lists.dillo.org/pipermail/dillo-dev/2019-October/07.html

While I can use Dillo without problems to connect to IPv4 HTTPS sites as
well as to IPv6 HTTP sites, connections to IPv6-only HTTPS sites appear
like stalled.

It seems as if dillo can cope well with IPv6, but its HTTPS helper
"dpid" can't. Given that HTTPS moves from the dpid into the browser with
the upcoming 3.1 version, I assume that this won't be fixed in the 3.0.x
series anymore.

I can reproduce this on Debian 8 Jessie (package 3.0.4-2+b1), Debian 9
Stretch (3.0.5-3), Debian 10 Buster (3.0.5-5) as well as on Debian Sid
as of now (package 3.0.5-5+b1).

Example hostnames to test:

Works: https://sym.noone.org/ (Dualstack + HTTPS)
Works: http://sym6.noone.org/ (IPv6-only)
Doesn't work: https://sym6.noone.org/ (IPv6-only + HTTPS)

(All three examples are the same host, but while sym.noone.org has an A
and  record, sym6.noone.org only has a  record for testing
purposes.)

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

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

Versions of packages dillo depends on:
ii  libc62.29-2
ii  libfltk1.3   1.3.4-9
ii  libgcc1  1:9.2.1-8
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libpng16-16  1.6.37-1
ii  libssl1.11.1.1d-1
ii  libstdc++6   9.2.1-8
ii  libx11-6 2:1.6.8-1
ii  wget 1.20.3-1+b1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages dillo recommends:
ii  perl  5.28.1-6

dillo suggests no packages.

-- no debconf information

Bug#940461: [PATCH v2] Add imap-dl, a simple imap downloader

Hello,

On Sun 06 Oct 2019 at 02:18PM -04, Daniel Kahn Gillmor wrote:

> i'm using imap-dl on a daily basis now, and will happily report back
> then too.  the last changes i made were supplying more debugging details
> on october 2nd, so i suppose the new year is ~3 months if you want to
> start the clock from my last changes :)
>
> I'd really love to have the integration stuff working, but i don't know
> when i'll get to that.

Cool -- please drop the moreinfo tag if no nontrivial changes in that
period.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

Hello,

On Sat 05 Oct 2019 at 07:30PM -04, David Steele wrote:

> I'm going to drop my objection, and assume that this is saying I don't need to
> write init scripts for my special case.

Okay -- perhaps you'd like to second Dmitry's patch, then, if you think
it reflects project consensus?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#940461: [PATCH v2] Add imap-dl, a simple imap downloader

control: tag -1 +moreinfo

Hello,

On Sat 05 Oct 2019 at 04:04PM -03, David Bremner wrote:

> FWIW I'm already using imap-dl daily, so I guess ask me in a few months
> if I noticed any problems.

Cool -- tagging moreinfo to reflect this.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#941330: undocumented limitation/dependency in dh_elpa_test

Hello,

On Sat 05 Oct 2019 at 02:01PM -04, Nicholas D Steeves wrote:

> Sean Whitton  writes:
>
>> control: tag -1 +pending
>>
>> Hello,
>>
>> On Sat 28 Sep 2019 at 04:50PM -04, Nicholas D Steeves wrote:
>>
>>> dh-elpa-test appears to have an undocumented hard dependency on
>>> (ert-run-test-batch-and-exit), specifically "-and-exit", and this
>>> one-function expression must appear as the final line of the defined
>>> ert_helper.
>>
>> Per the existing documentation of ert_helper, it would not be correct to
>> set ert_helper to run code that does some work, and then ends by calling
>> (ert-run-test-batch-and-exit).  That's what ert_eval is for.
>>
>
> In this case it's more: run a second round of tests using a different
> upstream provided method, and output how long each test took, plus time
> for garbage collection, and of a course a PASS||FAIL.

I think that the correct way to do this would be

override_dh_elpa_test:
dh_elpa_test
other_upstream_thing

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#933548: transition: gnome-desktop3

According to my reading of this britney run, the last 2 blockers were
removing gnome-shell-extension-easyscreencast and bumping the age for
eweouz. Both have been done now.

Thanks,
Jeremy

Bug#941880: gnome-shell-extension-easyscreencast: Depends on gnome-shell << 3.33

Source: gnome-shell-extension-easyscreencast
Version: 1.0.2-2
Severity: serious

gnome-shell-extension-easyscreencast depends on gnome-shell << 3.33
but gnome-shell 3.34 is in Unstable.

Thanks,
Jeremy Bicha

Bug#941481: kalarm: The Akonadi personal information management service is not running

2019-10-06 Thread Sandro Knauß

Control: tags -1 moreinfo

Hey,

> When installing kalarm on mate desktop environment, program is not working.
> It shows just message
> "The Akonadi personal information management service is not running. This
> application cannot be used without it". Pressing button Start does nothing.
> In console there is output
> 
> $ LC_ALL=C kalarm
> org.kde.pim.kidentitymanagement: IdentityManager: There was no default
> identity. Marking first one as default.
> org.kde.pim.akonadicore: Unable to execute akonadi_control, falling back to
> D-Bus auto-launch
> [...]
> 
> There are probably missing dependencies for kalarm package - when I install
> also package kontact with its dependencies, kalarm starts working well.

can you try if this is fixed, if you only install akoandiserver or do you need 
kdepim-runtime, too?

hefee



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

Bug#941853: crypt(3) should be provided by libxcrypt

2019-10-06 Thread Marco d'Itri

On Oct 07, Aurelien Jarno  wrote:

Dear debian-boot: for the benefit of the ftpmasters, please confirm that 
you have no objections to src:libxcrypt generating a libcrypt1-udeb 
package (initially in experimental) which will provide crypt(3) 
currently in the libc udeb.

> I guess we should keep building libcrypt1 for the bi/tri-arch packages.
What do I need to do about this?

> > (Also, do not forget about the man pages in the -dev packages.)
> The man page was not provided by the -dev package but by manpages-dev.
Actually I see that it automatically stopped shipping crypt(3) and 
crypt_r(3) in 5.01-1, so I will add Breaks+Replaces.

> We must build the libcrypt1 udeb, and add a depends from libc6-deb to
> libcrypt1-udeb, otherwise we might break d-i. At some point we might
OK, I will start again building the udeb with the next upload.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#935945: refreshed patch

2019-10-06 Thread Niv Sardi

I have refreshed the fedora mentioned patch for current debian TOT:
https://salsa.debian.org/xaiki/linux/commit/ff2ec75144fd87586a4206d394c6ebe6d7f79b4d

Bug#941827: Acknowledgement (module loading fails with error: "Lockdown: modprobe: Loading of unsigned module is restricted; see https://wiki.debian.org/SecureBoot")

2019-10-06 Thread Niv Sardi

merge 941827 935945
thanks

Bug#941848: RFS: ukui-control-center/2.0.0-1 -- utilities to configure the UKUI desktop

2019-10-06 Thread Adam Borowski

On Sun, Oct 06, 2019 at 10:06:45PM +0800, handsome_feng wrote:
>  * Package name: ukui-control-center
>Version : 2.0.0-1

> Changes since the last upload:
> 
>[ He Bing ]
>* New upstream release.
>  - Migrate from gtk3.0 to Qt5.
>  .
>[ handsome_feng ]
>* Debian:
>  - Bump standard version to 4.4.1.
>  - Bump compat level to 12.
>  - Fix some lintian warnings.

Dies when trying to start it:

[/tmp]$ ukui-control-center
qt.svg: link g5692 hasn't been detected!
qt.svg: link g5692 hasn't been detected!
qt.svg: link g5692 hasn't been detected!
qt.svg: link g5692 hasn't been detected!
qt.svg: link g5692 hasn't been detected!
qt.svg: 
/usr/share/icons/hicolor/scalable/status/xfce4-power-manager-settings.svg:5520: 
Could not resolve property: radialGradient4319
qt.svg: link g5692 hasn't been detected!
qt.svg: link g5692 hasn't been detected!
qt.svg: link g5692 hasn't been detected!
qt.svg: link g5692 hasn't been detected!
qt.svg: link g5692 hasn't been detected!
qt.svg: 
/usr/share/icons/hicolor/scalable/status/xfce4-power-manager-settings.svg:5520: 
Could not resolve property: radialGradient4319
qt.svg: link g5692 hasn't been detected!
qt.svg: link g5692 hasn't been detected!
qt.svg: link g5692 hasn't been detected!
qt.svg: link g5692 hasn't been detected!
qt.svg: link g5692 hasn't been detected!
qt.svg: 
/usr/share/icons/hicolor/scalable/status/xfce4-power-manager-settings.svg:5520: 
Could not resolve property: radialGradient4319

(ukui-control-center:19077): GLib-GIO-ERROR **: 00:13:27.296: Settings schema 
'org.ukui.panel.indicator.calendar' is not installed
Trace/breakpoint trap (core dumped)

(This is on XFCE, thus a good part of dependencies you assume but don't
specify are probably missing.)

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#941853: crypt(3) should be provided by libxcrypt

2019-10-06 Thread Aurelien Jarno

On 2019-10-07 00:00, Marco d'Itri wrote:
> On Oct 06, Aurelien Jarno  wrote:
> 
> > Ah this doesn't match the version in unstable, it's only in NEW for now.
> > I guess we need to wait for it to get out of there first.
> For reasons which I do not understand, the ftpmasters obliquely let me 
> know that they will not accept libxcrypt from NEW until the libc 
> maintainers will explicitly confirm that we have agreed on a plan to use 
> it. Do you mind confirming this?

AFAIK, the glibc team have never been asked about that.

For the ftpmasters: I confirm we'll replace libcrypt.so.1 from libc6 by
the one from libxcrypt. Therefore please accept the package.

> > > So I think that libc6 should have Depends/Replaces on libcrypt1.
> > Agreed for the Depends. I don't get why it needs a Replaces. On the
> > other hand libcrypt1 needs a Replaces: libc6, libc6.1, libc0.1, libc0.3
> > with the correct version.
> Yes, this is what I meant. So:
> 
> Package: libcrypt1
> Breaks: libc6 (<< 2.29-X)
> Replaces: libc6 (<< 2.29-X)
> 
> Package: libcrypt1-dev
> Breaks: libc6-dev (<< 2.29-X)
> Replaces: libc6-dev (<< 2.29-X)
> 
> Package: libc6
> Depends: libcrypt1
> 
> Package: libc6-dev
> Depends: libcrypt1-dev
> 
> And all the architecture-specific variations which I will figure out.

This is libc0.1, libc0.3, libc6 and libc6.1 for the library package. 
This is libc0.1-dev, libc0.3-dev, libc6-dev and libc6.1-dev for the
library packages.

I guess we should keep building libcrypt1 for the bi/tri-arch packages.

> (Also, do not forget about the man pages in the -dev packages.)

The man page was not provided by the -dev package but by manpages-dev.

> There is also a libcrypt1 udeb: do you prefer to start building it now 
> or deal with it later?

We must build the libcrypt1 udeb, and add a depends from libc6-deb to
libcrypt1-udeb, otherwise we might break d-i. At some point we might
want to rebuild all udebs (at least by hand to detect the affected
udebs) and drop that dependency.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

signature.asc
Description: PGP signature

Bug#885353: bumping severity of pygtk bugs

2019-10-06 Thread Thomas Ross

Since upstream for this project is dead, I intent on porting mirage to
Python 3 myself when time allows.

As soon as Py3 mirage is ready, I will try to get the new version uploaded.

Thanks,
Thomas.

On Sun, 06 Oct 2019 17:09:30 -0400 Jeremy Bicha  wrote:
> Control: severity -1 serious
> Control: tags -1 -buster
> 
> 
> As part of the Python2 removal, it is our intent that pygtk will be removed 
> from Testing before the release of Debian 11
> "Bullseye". Therefore, I am bumping the severity of this bug to Serious to 
> ensure that there is plenty of warning before
> the Debian 11 release and to make the eventual removal of pygtk as smooth as 
> possible.
> 
> 
> On behalf of the Debian GNOME team,
> Jeremy Bicha



signature.asc
Description: OpenPGP digital signature

Bug#941839: tcp-wrappers: DECLS replacement (musl, rebootstrap) (PATCH 2)

2019-10-06 Thread Davor Ocelic


Replacing the previous patch with an improved one which contains both changes
needed to build the package with musl.

diff -ru tcp-wrappers-7.6.q/debian/rules tcp-wrappers-7.6.q,musl/debian/rules
--- tcp-wrappers-7.6.q/debian/rules	2017-10-29 23:10:56.0 +
+++ tcp-wrappers-7.6.q,musl/debian/rules	2019-10-06 20:51:56.47200 +
@@ -22,7 +22,11 @@
 ifeq ($(filter-out hurd-%,$(DEB_BUILD_ARCH)),)
   build_target := gnu
 else
-  build_target := linux
+  ifeq ($(DEB_HOST_ARCH_LIBC),musl)
+build_target := musl
+  else
+build_target := linux
+  endif
 endif
 
 
diff -ru tcp-wrappers-7.6.q/Makefile tcp-wrappers-7.6.q,musl/Makefile
--- tcp-wrappers-7.6.q/Makefile	2019-10-06 20:53:43.0 +
+++ tcp-wrappers-7.6.q,musl/Makefile	2019-10-06 20:52:20.78000 +
@@ -154,6 +154,12 @@
 	NETGROUP="-DNETGROUP" TLI= VSYSLOG= BUGS= \
 	EXTRA_CFLAGS="-DSYS_ERRLIST_DEFINED -DHAVE_STRERROR -DHAVE_WEAKSYMS -DINET6=1 -Dss_family=__ss_family -Dss_len=__ss_len" all
 
+musl:
+	@make REAL_DAEMON_DIR=$(REAL_DAEMON_DIR) STYLE=$(STYLE) \
+	LIBS= RANLIB=ranlib ARFLAGS=rv AUX_OBJ=weak_symbols.o \
+	NETGROUP= TLI= VSYSLOG= BUGS= \
+	EXTRA_CFLAGS="-DSYS_ERRLIST_DEFINED -DHAVE_STRERROR -DHAVE_WEAKSYMS -DINET6=1 -Dss_family=__ss_family -Dss_len=__ss_len" all
+
 gnu:
 	@make REAL_DAEMON_DIR=$(REAL_DAEMON_DIR) STYLE=$(STYLE) \
 	LIBS=-lnsl RANLIB=ranlib ARFLAGS=rv AUX_OBJ=weak_symbols.o \
diff -ru tcp-wrappers-7.6.q/tcpd.h tcp-wrappers-7.6.q,musl/tcpd.h
--- tcp-wrappers-7.6.q/tcpd.h	2019-10-06 20:53:43.0 +
+++ tcp-wrappers-7.6.q,musl/tcpd.h	2019-10-06 20:20:16.7 +
@@ -11,7 +11,9 @@
 #include 
 #include 
 
-__BEGIN_DECLS
+#ifdef __cplusplus
+extern "C" {
+#endif
 
 /* Structure to describe one communications endpoint. */
 
@@ -252,6 +254,8 @@
 extern char *my_strtok();
 #endif
 
-__END_DECLS
+#ifdef __cplusplus
+}
+#endif
 
 #endif

Bug#937828: python-ijson: diff for NMU version 2.3-2.1

Control: tags 937828 + patch
Control: tags 937828 + pending


Dear maintainer,

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

Regards.

diff -Nru python-ijson-2.3/debian/changelog python-ijson-2.3/debian/changelog
--- python-ijson-2.3/debian/changelog	2019-01-12 08:01:32.0 -0500
+++ python-ijson-2.3/debian/changelog	2019-10-06 18:01:24.0 -0400
@@ -1,3 +1,10 @@
+python-ijson (2.3-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937828
+
+ -- Sandro Tosi   Sun, 06 Oct 2019 18:01:24 -0400
+
 python-ijson (2.3-2) unstable; urgency=medium
 
   * d/rules: looks nicer
diff -Nru python-ijson-2.3/debian/control python-ijson-2.3/debian/control
--- python-ijson-2.3/debian/control	2019-01-12 08:01:32.0 -0500
+++ python-ijson-2.3/debian/control	2019-10-06 18:01:12.0 -0400
@@ -5,8 +5,6 @@
 Build-Depends: debhelper (>= 11),
debhelper-compat (= 12),
dh-python,
-   python,
-   python-setuptools,
python3,
python3-setuptools
 Standards-Version: 4.3.0
@@ -14,18 +12,6 @@
 Vcs-Git: https://salsa.debian.org/debian/python-ijson.git
 Homepage: https://github.com/isagalaev/ijson
 
-Package: python-ijson
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}
-Suggests: libyajl2
-Description: event-driven JSON parser (Python 2 version)
- Ijson is an iterative, event-driven JSON parser with a standard
- Python iterator interface. The principle is similar to Java SAX
- parser: the user can parse a document on-line, without storing the
- whole object in memory.
- .
- This package installs the library for Python 2.
-
 Package: python3-ijson
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
diff -Nru python-ijson-2.3/debian/rules python-ijson-2.3/debian/rules
--- python-ijson-2.3/debian/rules	2019-01-12 08:01:32.0 -0500
+++ python-ijson-2.3/debian/rules	2019-10-06 18:01:21.0 -0400
@@ -4,4 +4,4 @@
 export PYBUILD_NAME = ijson
 
 %:
-	dh $@ --buildsystem=pybuild --with=python3,python2
+	dh $@ --buildsystem=pybuild --with=python3

Bug#885507: radiotray: Depends on unmaintained python-glade2

Control: severity -1 serious
Control: tags buster sid patch
Control: user pkg-gnome-maintain...@lists.alioth.debian.org
Control: usertag oldlibs pygtk

Please drop the unused dependency on python-glade2.

We are working to remove pygtk from Debian.

Thanks,
Jeremy Bicha

Bug#941853: crypt(3) should be provided by libxcrypt

2019-10-06 Thread Marco d'Itri

On Oct 06, Aurelien Jarno  wrote:

> Ah this doesn't match the version in unstable, it's only in NEW for now.
> I guess we need to wait for it to get out of there first.
For reasons which I do not understand, the ftpmasters obliquely let me 
know that they will not accept libxcrypt from NEW until the libc 
maintainers will explicitly confirm that we have agreed on a plan to use 
it. Do you mind confirming this?

> > So I think that libc6 should have Depends/Replaces on libcrypt1.
> Agreed for the Depends. I don't get why it needs a Replaces. On the
> other hand libcrypt1 needs a Replaces: libc6, libc6.1, libc0.1, libc0.3
> with the correct version.
Yes, this is what I meant. So:

Package: libcrypt1
Breaks: libc6 (<< 2.29-X)
Replaces: libc6 (<< 2.29-X)

Package: libcrypt1-dev
Breaks: libc6-dev (<< 2.29-X)
Replaces: libc6-dev (<< 2.29-X)

Package: libc6
Depends: libcrypt1

Package: libc6-dev
Depends: libcrypt1-dev

And all the architecture-specific variations which I will figure out.

(Also, do not forget about the man pages in the -dev packages.)

There is also a libcrypt1 udeb: do you prefer to start building it now 
or deal with it later?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#890168: python-gasp: Please switch to python-gobject-2/python-gi

Control: severity -1 serious
Tags: fixed-upstream

It looks to me like upstream has ported gasp to Python3 and GObject
Introspection.

https://launchpad.net/gasp-core

Thanks,
Jeremy Bicha

Bug#941879: RFS: planner/0.14.6-8 [QA] -- project management application

2019-10-06 Thread Yavor Doganov

Package: sponsorship-requests
Severity: normal

Dear mentors,

I'm looking for a sponsor for a QA upload of the package "planner".

 * Package name: planner
   Version : 0.14.6-8
   Upstream Author : CodeFactory AB, Imendio AB + others
 * URL : http://live.gnome.org/Planner
 * License : GPL-2+
 * Vcs : None
   Section : gnome

It builds these binary packages:

planner - project management application
planner-dev - Planner development library
planner-doc - Documentation for planner
planner-data - Data files for planner

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/planner/planner_0.14.6-8.dsc

Changes since the last upload:

   * QA upload.
   * debian/patches/gsettings-port.patch: Remove GConf migration code.
   * debian/patches/glibc-2.29.patch: New; fix GTK critical errors with
 glibc/2.29.
   * debian/patches/python3.patch: New; port to Python 3 and PyGI
 (Closes: #937299).
   * debian/patches/series: Update.
   * debian/compat: Bump to 12.
   * debian/control: Run wrap-and-sort -ast.
 (Build-Depends): Remove desktop-file-utils, dh-python, gnome-pkg-tools
 and libncurses5-dev; unnecessary.  Require debhelper >= 12.  Replace
 python-gtk2-dev and python-dev with python-gi-dev and python3-dev.
 (Depends): Remove ${python:Depends}, add python3-gi and
 gir1.2-gtk-2.0.
 (Recommends): Remove gconf2.
 (planner-doc) : Set to "foreign".
 (Rules-Requires-Root): Set to "no".
 (Standards-Version): Bump to 4.4.1; no changes needed.
   * debian/python-demo.py: Add an example script from upstream's
 repository, modified for Python 3 and the dynamic bindings.
   * debian/planner-doc.examples: Add debian/python-demo.py.
   * debian/planner-data.install: Remove usr/share/GConf.
   * debian/planner.install: Remove Python extensions, add *.typelib.
   * debian/rules: Remove --with python2 argument to dh.
 (LDFLAGS): Remove; not needed with GCC 9.
 (override_dh_makeshlibs): Remove the python extensions.
 (override_dh_autoreconf): Remove override; unnecessary.
   * debian/NEWS: New file; warn users about incompatibility woes.
   * debian/copyright: Update copyright years.

Bug#941878: RM: vusb-analyzer -- RoQA; unmaintained, depends on Python2 and pygtk

Package: ftp.debian.org
X-Debbugs-Cc: vusb-analy...@packages.debian.org
Affects: src:vusb-analyzer

vusb-analyzer was orphaned in 2011 and has had basic packaging fixes since then.

The packaging itself is fine. The problem is that it uses Python2 and
pygtk and both are in the process of being removed from Debian. There
hasn't been an active upstream in a long time and popcon is low.

Please remove vusb-analyzer from Debian.

Orphaning bug: https://bugs.debian.org/655266

Thanks,
Jeremy Bicha

Bug#941877: volti: Depends on unmaintained pygtk

Source: volti
Version:  0.2.3-7
Severity: serious
Control: block 885135 by -1
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs pygtk
Tags: sid bullseye

pygtk is unmaintained upstream. It has not had a release since GNOME 3
was released in 2011. Also, it uses Python2 and Python2 is being removed
from Debian.

The way forward is to port your app to use GObject Introspection
bindings.

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Debian 11 "Bullseye" release as
we're going to remove pygtk this cycle.

If you have any question don't hesitate to ask.

[1] https://wiki.gnome.org/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/Projects/PyGObject

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#941876: pyspread: Please remove unused dependency on python-gtk2

Source: pyspread
Version: 1.1.3-4
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs pygtk
Tags: sid bullseye patch

The Debian GNOME team is working to remove pygtk from Debian. pygtk is
a set of Python 2 bindings for GTK2.

It looks like pyspread has already been ported to python-wxgtk3.0
which uses GTK3 All you have left to do for the pygtk removal is to
remove python-gtk2 from pyspread's Depends.

(I'm not actually attaching a patch here but this seems like an easy fix.)

Thanks,
Jeremy Bicha

Bug#941875: gpxviewer: Please remove unused dependency on python-gtk2

Source: gpxviewer
Version: 0.5.2-2
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs pygtk
Tags: sid bullseye patch

The Debian GNOME team is working to remove pygtk from Debian. pygtk is
a set of Python 2 bindings for GTK2.

It looks like gpxviewer has already been reported to GObject
Introspection and GTK3. All you have left to do for the pygtk removal
is to remove python-gtk2 from gpxviewer's Depends.

(I'm not actually attaching a patch here but this seems like an easy fix.)

Thanks,
Jeremy Bicha

Bug#885280: bumping severity of pygtk bugs

Control: severity -1 serious
Control: tags -1 -buster
Control: block 885135 by -1


As part of the Python2 removal, it is our intent that pygtk will be
removed from Testing before the release of Debian 11 "Bullseye".
Therefore, I am bumping the severity of this bug to Serious to ensure
that there is plenty of warning before the Debian 11 release and to
make the eventual removal of pygtk as smooth as possible.


On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#941870: RM: fwupdate-amd64-signed -- ROM; fwupdate is merged into fwupd, transitioning all fwupdate packages to fwupd

Package: ftp.debian.org
Severity: normal

Bug#941871: RM: fwupdate-i386-signed -- ROM; fwupdate is merged into fwupd, transitioning all fwupdate packages to fwupd

Package: ftp.debian.org
Severity: normal

Bug#941874: RM: gmail-notify -- RoQA; unmaintained, removed from Testing in 2015

Package: ftp.debian.org
X-Debbugs-Cc: gmail-not...@packages.debian.org
Affects: src:gmail-notify

gmail-notify was removed from Testing in 2015. In addition to being
unmaintained in Debian, it appears to have been abandoned upstream for
many years.

It is blocking a future removal of pygtk from Debian (part of the
Python2 removals).

Please remove gmail-notify from Debian.

Testing removal bug: https://bugs.debian.org/787614

Thanks,
Jeremy Bicha

Bug#941873: RM: fwupdate-arm64-signed -- ROM; fwupdate is merged into fwupd, transitioning all fwupdate packages to fwupd

Package: ftp.debian.org
Severity: normal

Bug#941872: RM: fwupdate-armhf-signed -- ROM; fwupdate is merged into fwupd, transitioning all fwupdate packages to fwupd

Package: ftp.debian.org
Severity: normal

Bug#941869: cherrytree: Depends on unmaintained pygtk

Source: cherrytree
Version:  0.37.6-1.1
Severity: serious
Control: block 885135 by -1
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs pygtk
Tags: sid bullseye

pygtk is unmaintained upstream. It has not had a release since GNOME 3
was released in 2011. Also, it uses Python2 and Python2 is being removed
from Debian.

The way forward is to port your app to use GObject Introspection
bindings.

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Debian 11 "Bullseye" release as
we're going to remove pygtk this cycle.

If you have any question don't hesitate to ask.

[1] https://wiki.gnome.org/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/Projects/PyGObject

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#937683: python-cymruwhois: diff for NMU version 1.6-3.2

Control: tags 937683 + patch
Control: tags 937683 + pending


Dear maintainer,

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

Regards.

diff -Nru python-cymruwhois-1.6/debian/changelog python-cymruwhois-1.6/debian/changelog
--- python-cymruwhois-1.6/debian/changelog	2018-12-28 13:07:06.0 -0500
+++ python-cymruwhois-1.6/debian/changelog	2019-10-06 17:12:33.0 -0400
@@ -1,3 +1,10 @@
+python-cymruwhois (1.6-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937683
+
+ -- Sandro Tosi   Sun, 06 Oct 2019 17:12:33 -0400
+
 python-cymruwhois (1.6-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru python-cymruwhois-1.6/debian/control python-cymruwhois-1.6/debian/control
--- python-cymruwhois-1.6/debian/control	2018-07-24 11:06:43.0 -0400
+++ python-cymruwhois-1.6/debian/control	2019-10-06 17:11:39.0 -0400
@@ -4,14 +4,8 @@
 Priority: optional
 Build-Depends: debhelper (>= 11),
dh-python,
-   python,
-   python-all,
-   python-setuptools,
python3-all,
python3-setuptools,
-   python-docutils,
-   python-sphinx,
-   python-nose,
python3-nose,
python3-docutils,
python3-sphinx
@@ -20,17 +14,6 @@
 Vcs-Git: https://salsa.debian.org/ineteng-team/python-cymruwhois.git
 Homepage: https://pythonhosted.org/cymruwhois/
 
-Package: python-cymruwhois
-Architecture: all
-Depends: ${python:Depends},
- ${misc:Depends}
-Suggests: python-cymruwhois-doc
-Description: Python library for interfacing with the whois.cymru.com service (Python 2)
- Perform lookups by ip address and return ASN,
- Country Code, and Netblock Owner.
- .
- This package installs the library for Python 2.
-
 Package: python3-cymruwhois
 Architecture: all
 Depends: ${python3:Depends},
diff -Nru python-cymruwhois-1.6/debian/python-cymruwhois.manpages python-cymruwhois-1.6/debian/python-cymruwhois.manpages
--- python-cymruwhois-1.6/debian/python-cymruwhois.manpages	2018-07-24 05:48:03.0 -0400
+++ python-cymruwhois-1.6/debian/python-cymruwhois.manpages	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-docs/python-cymruwhois.1
diff -Nru python-cymruwhois-1.6/debian/python-cymruwhois.postinst python-cymruwhois-1.6/debian/python-cymruwhois.postinst
--- python-cymruwhois-1.6/debian/python-cymruwhois.postinst	2018-07-24 05:48:03.0 -0400
+++ python-cymruwhois-1.6/debian/python-cymruwhois.postinst	1969-12-31 19:00:00.0 -0500
@@ -1,11 +0,0 @@
-#!/bin/sh
-# postinst script for python-cymruwhois
-
-set -e
-if [ $1 = 'configure' ]; then
-	update-alternatives --install /usr/bin/cymruwhois cymruwhois /usr/bin/python-cymruwhois 300 --slave /usr/share/man/man1/cymruwhois.1.gz cymruwhois.1.gz /usr/share/man/man1/python-cymruwhois.1.gz
-fi
-
-#DEBHELPER#
-
-exit 0
diff -Nru python-cymruwhois-1.6/debian/python-cymruwhois.prerm python-cymruwhois-1.6/debian/python-cymruwhois.prerm
--- python-cymruwhois-1.6/debian/python-cymruwhois.prerm	2018-07-24 05:48:03.0 -0400
+++ python-cymruwhois-1.6/debian/python-cymruwhois.prerm	1969-12-31 19:00:00.0 -0500
@@ -1,13 +0,0 @@
-#!/bin/sh
-# prerm script for python-cymruwhois
-
-set -e
-
-if [ $1 = 'remove' ]; then
-update-alternatives --remove cymruwhois /usr/bin/python-cymruwhois 
-fi
-
-#DEBHELPER#
-
-exit 0
-
diff -Nru python-cymruwhois-1.6/debian/rules python-cymruwhois-1.6/debian/rules
--- python-cymruwhois-1.6/debian/rules	2018-12-28 13:05:45.0 -0500
+++ python-cymruwhois-1.6/debian/rules	2019-10-06 17:12:12.0 -0400
@@ -5,17 +5,15 @@
 export PYBUILD_NAME=cymruwhois
 
 %:
-	dh $@  --with python2,python3,sphinxdoc --buildsystem=pybuild
+	dh $@  --with python3,sphinxdoc --buildsystem=pybuild
 
 override_dh_auto_build:
 	PYTHONPATH=. http_proxy='127.0.0.1:9' sphinx-build -N -bhtml docs/ docs/_build/html # HTML generator
-	sed "s/command\./command (Python 2)/" docs/cymruwhois.1>docs/python-cymruwhois.1
 	sed "s/command\./command (Python 3)/" docs/cymruwhois.1>docs/python3-cymruwhois.1
 	dh_auto_build
 
 override_dh_auto_install:
 	dh_auto_install
-	mv $(CURDIR)/debian/python-cymruwhois/usr/bin/cymruwhois $(CURDIR)/debian/python-cymruwhois/usr/bin/python-cymruwhois
 	mv $(CURDIR)/debian/python3-cymruwhois/usr/bin/cymruwhois $(CURDIR)/debian/python3-cymruwhois/usr/bin/python3-cymruwhois
 
 override_dh_auto_test:

Bug#941868: gextractwinicons: Depends on unmaintained pygtk

Source: gextractwinicons
Version:  0.3.1-1.1
Severity: serious
Control: block 885135 by -1
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs pygtk
Tags: sid bullseye

pygtk is unmaintained upstream. It has not had a release since GNOME 3
was released in 2011. Also, it uses Python2 and Python2 is being removed
from Debian.

The way forward is to port your app to use GObject Introspection
bindings.

For more information on GObject Introspection see [1] and [2].

Please try to do this before the Debian 11 "Bullseye" release as
we're going to remove pygtk this cycle.

If you have any question don't hesitate to ask.

[1] https://wiki.gnome.org/Projects/GObjectIntrospection
[2] https://wiki.gnome.org/Projects/PyGObject

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#941867: qt-gstreamer FTBFS: error: invalid cast from type ‘const CapsPtr’ to type ‘GstMiniObject*’

2019-10-06 Thread Helmut Grohne

Source: qt-gstreamer
Version: 1.2.0-5
Severity: serious
Tags: ftbfs

qt-gstreamer fails to build from source in unstable on amd64. A build in
sbuild ends with:

| [ 22%] Building CXX object src/QGst/CMakeFiles/Qt5GStreamer.dir/caps.cpp.o
| cd /<>/obj-x86_64-linux-gnu/src/QGst && /usr/bin/c++  
-DGST_DISABLE_LOADSAVE -DGST_DISABLE_XML 
-DQTGLVIDEOSINK_NAME=\"qt5glvideosink\" -DQTVIDEOSINK_NAME=\"qt5videosink\" 
-DQT_CORE_LIB -DQT_NO_DEBUG -DQT_NO_KEYWORDS 
-DQWIDGETVIDEOSINK_NAME=\"qwidget5videosink\" -DQt5GStreamer_EXPORTS 
-I/<>/obj-x86_64-linux-gnu/src/QGst -I/<>/src/QGst 
-I/<>/obj-x86_64-linux-gnu/src/QGst/Qt5GStreamer_autogen/include 
-I/<>/src -I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -isystem 
/usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra 
-Wformat-security -Wundef -Wpointer-arith -fno-common -fvisibility=hidden 
-fvisibility-inlines-hidden -std=c++0x -O2 -g -DNDEBUG -fPIC   -pthread 
-I/usr/include/gstreamer-1.0 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -fPIC -std=gnu++11 -o 
CMakeFiles/Qt5GStreamer.dir/caps.cpp.o -c /<>/src/QGst/caps.cpp
| In file included from /usr/include/gstreamer-1.0/gst/gstbuffer.h:30,
|  from /usr/include/gstreamer-1.0/gst/gstpad.h:70,
|  from /usr/include/gstreamer-1.0/gst/gstelement.h:87,
|  from /usr/include/gstreamer-1.0/gst/gstbin.h:27,
|  from /usr/include/gstreamer-1.0/gst/gst.h:35,
|  from /<>/src/QGst/caps.cpp:22:
| /<>/src/QGst/caps.cpp: In member function ‘void 
QGst::Caps::append(const CapsPtr&)’:
| /usr/include/gstreamer-1.0/gst/gstminiobject.h:33:65: error: invalid cast 
from type ‘const CapsPtr’ {aka ‘const QGlib::RefPointer’} to type 
‘GstMiniObject*’ {aka ‘_GstMiniObject*’}
|33 | #define GST_MINI_OBJECT_CAST(obj)  ((GstMiniObject*)(obj))
|   | ^
| /usr/include/gstreamer-1.0/gst/gstcaps.h:35:47: note: in definition of macro 
‘GST_CAPS_CAST’
|35 | #define GST_CAPS_CAST(obj)((GstCaps*)(obj))
|   |   ^~~
| /usr/include/gstreamer-1.0/gst/gstcaps.h:249:29: note: in expansion of macro 
‘GST_CAPS’
|   249 | #define gst_caps_copy(caps) GST_CAPS (gst_mini_object_copy 
(GST_MINI_OBJECT_CAST (caps)))
|   | ^~~~
| /usr/include/gstreamer-1.0/gst/gstcaps.h:249:61: note: in expansion of macro 
‘GST_MINI_OBJECT_CAST’
|   249 | #define gst_caps_copy(caps) GST_CAPS (gst_mini_object_copy 
(GST_MINI_OBJECT_CAST (caps)))
|   | 
^~~~
| /<>/src/QGst/caps.cpp:57:40: note: in expansion of macro 
‘gst_caps_copy’
|57 | gst_caps_append(object(), gst_caps_copy(caps2));
|   |^
| make[4]: *** [src/QGst/CMakeFiles/Qt5GStreamer.dir/build.make:122: 
src/QGst/CMakeFiles/Qt5GStreamer.dir/caps.cpp.o] Error 1
| make[4]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[3]: *** [CMakeFiles/Makefile2:352: 
src/QGst/CMakeFiles/Qt5GStreamer.dir/all] Error 2
| make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| make[2]: *** [Makefile:144: all] Error 2
| make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| dh_auto_build: cd obj-x86_64-linux-gnu && make -j1 all returned exit code 2
| make[1]: *** [debian/rules:18: override_dh_auto_build-arch] Error 255
| make[1]: Leaving directory '/<>'
| make: *** [debian/rules:36: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Reproducible by reproducible builds:

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/qt-gstreamer_1.2.0-5.rbuild.log.gz

Helmut

Bug#885136: bumping severity of pygtk bugs

Control: severity -1 serious
Control: tags -1 -buster


As part of the Python2 removal, it is our intent that pygtk will be removed 
from Testing before the release of Debian 11
"Bullseye". Therefore, I am bumping the severity of this bug to Serious to 
ensure that there is plenty of warning before
the Debian 11 release and to make the eventual removal of pygtk as smooth as 
possible.


On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#940135: libuhd-dev: uhd.pc missing -lboost_system produces build failures

2019-10-06 Thread Harald Welte

Is there anything that we can do to help resolving this issue?  

osmo-trx builds are FTBFS for more than three weeks now, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939974

Thanks a lot!

Regards,
Harald
-- 
- Harald Welte http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#941745: Tomb 2.6 provides an important fix

2019-10-06 Thread Sven Geuer

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: severity -1 wishlist

Regarding 'whitespace bug in KDF passwords':
This issue does not apply to Tomb 2.5 in Debian as it does not support
KDF passwords at all, see [1].

Regarding 'important fix for usage of Tomb with cryptsetup 2.1':
This seems to refer to [2], 'Issue opening tombs with cryptsetup >
2.0', which is an annoying bug but not a security issue.

As both topics already has been dealt with by version 2.6+dfsg1-1 and
above in testing and sid the only thing missing is a backport to
buster. I therefore reduce the severity to wishlist. 

An upload to buster-backports is in preparation. 

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924043
[2] https://github.com/dyne/Tomb/blob/master/KNOWN_BUGS.md

Am Freitag, den 04.10.2019, 19:00 +0300 schrieb Dmitry Elmanov:
> Package: tomb
> Version: 2.5+dfsg1-2
> Severity: important
> 
> Version 2.6 of the Tomb provides an important fix for usage of Tomb
> with cryptsetup 2.1 and future versions; it also fixes a whitespace 
> bug in KDF passwords that could drastically reduce the strength of
> encryption. So, updating Tomb debian package to version 2.6 will be
> logical via the security updates to the stable release.
> 
> 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEPfXoqkP8n9/QhvGVrfUO2vit1YUFAl2aUfQACgkQrfUO2vit
1YX5exAAtH+wj817GubSqGEh7qtJNQqrwWls+bOzGhioFnrvWKaiYA0K2OkDSTYc
vLJclfV6cRkX69QyKSwTofQvkSzF7stS+bFr4D22R2H2Th2a+RI9cnMg0CwIZBN8
WYJxD9E/BSqCrSCZFaWA+Q6AZUETVO8EU+ik4KbNrK9cViEybNSzRfSBGPQqWlwN
TM+bZ20BqeSn6l28hfW5lOCQiW4drSOqAdLs20mGZhBZUWd6EjVX1BfXk4vBfYl6
hFYUslOeYED3vLtPMkTxH+DIYba4BEuWdr+W2AN2oek9NB1zQ0pl/qnELbulr7Yw
A1SF2PBZa6ZxVlsiVdMRgECI1SbEw/bNVqpp057O0d38yW15gw3pSBICo7a5xCfr
oSTX9rN8hW5MC4scren+FDQUFN5BBx9uGvTmT8heRj2R0bjP9A7rACpfOUKEgy5I
P62eYWwn7VABdMS6frt5lNP2qTzf5JpPgaZYluwvbMfBx/7A8+hAQUnifjUcJkE6
l0Rv09hZ9fqe54RZQrVodadCoIIAjcAWLMNpNQeHWEqPfkw04zuHvxHOfMJ75Og+
7XUWmzsqbixOKzk6qlKhPFhgzX8gf0bZUYIgtO+w+YMJ9IOmhlg1jIO1l2GjRlYF
bG7POFD4qXHUzOcaiZwZtI/7NqAzao0bD0dwBCRe9nMxEDznSQo=
=4VTk
-END PGP SIGNATURE-

Bug#940870: ITP: libspotbugs-annotation-java -- Annotations the SpotBugs tool supports

2019-10-06 Thread Emmanuel Bourg

On Sat, 21 Sep 2019 07:21:13 +0200 Mechtilde Stehmann
 wrote:

> This is a revers dependency chain
> 
> spotbugs-annotation -> junit-dataprovider ->
> ThreeTen-Extra -> Jollyday (ITP #939617) -> JVerein (#929477.

Did you try using the existing libfindbugs-annotations-java package? It
should be compatible, so this ITP may be unnecessary.

Emmanuel Bourg

Bug#937112: natsort: diff for NMU version 6.0.0-1.1

> Yay, that's cool. Thank you for pushing the update! I would prefer using
> -2 instead of 1.1 but it's ok.

that's how NMUs are versioned

> Please open a MR in salsa with your changes to keep it synced.

i dont care about attribution of the changes, if you want just go
ahead and upload a -2, and my NMU will be rejected (as its version is
gonna be lower than -2)

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#941853: crypt(3) should be provided by libxcrypt

2019-10-06 Thread Aurelien Jarno

On 2019-10-06 22:04, Marco d'Itri wrote:
> On Oct 06, Aurelien Jarno  wrote:
> 
> > The libxcrypt implementation is indeed source backward compatible,
> > however doesn't seem binary backward compatible. libc6 provides
> > libcrypt.so.1 while libxcrypt provides libcrypt.so.2.
> It provides both, but currently I am not even building libcrypt.so.2 
> since I do not see the point.

Ah this doesn't match the version in unstable, it's only in NEW for now.
I guess we need to wait for it to get out of there first.

> md@bongo:/USR3/src/P/libxcrypt$ dpkg-deb -c libcrypt1_4.4.8-1_amd64.deb
> drwxr-xr-x root/root 0 2019-09-01 22:04 ./
> drwxr-xr-x root/root 0 2019-09-01 22:04 ./lib/
> drwxr-xr-x root/root 0 2019-09-01 22:04 ./lib/x86_64-linux-gnu/
> -rw-r--r-- root/root202680 2019-09-01 22:04 
> ./lib/x86_64-linux-gnu/libcrypt.so.1.1.0
> drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/
> drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/share/
> drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/share/doc/
> drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/share/doc/libcrypt1/
> -rw-r--r-- root/root  6476 2019-09-01 21:03 
> ./usr/share/doc/libcrypt1/NEWS.gz
> -rw-r--r-- root/root  4052 2019-03-06 00:02 
> ./usr/share/doc/libcrypt1/README.md.gz
> -rw-r--r-- root/root   799 2019-09-01 22:04 
> ./usr/share/doc/libcrypt1/changelog.Debian.gz
> -rw-r--r-- root/root  5628 2019-09-01 22:04 
> ./usr/share/doc/libcrypt1/copyright
> lrwxrwxrwx root/root 0 2019-09-01 22:04 
> ./lib/x86_64-linux-gnu/libcrypt.so.1 -> libcrypt.so.1.1.0
> lrwxrwxrwx root/root 0 2019-09-01 22:04 
> ./usr/share/doc/libcrypt1/TODO -> TODO.md
> 
> So I think that libc6 should have Depends/Replaces on libcrypt1.

Agreed for the Depends. I don't get why it needs a Replaces. On the
other hand libcrypt1 needs a Replaces: libc6, libc6.1, libc0.1, libc0.3
with the correct version.

> I suggest that we make a pass in experimental to be sure to not leave 
> unstable uninstallable for days.

Fine for me.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#937524: pyrlp: diff for NMU version 0.5.1-1.1

Control: tags 937524 + patch
Control: tags 937524 + pending


Dear maintainer,

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

Regards.

diff -Nru pyrlp-0.5.1/debian/changelog pyrlp-0.5.1/debian/changelog
--- pyrlp-0.5.1/debian/changelog	2017-07-14 15:25:42.0 -0400
+++ pyrlp-0.5.1/debian/changelog	2019-10-06 16:35:18.0 -0400
@@ -1,3 +1,10 @@
+pyrlp (0.5.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937524
+
+ -- Sandro Tosi   Sun, 06 Oct 2019 16:35:18 -0400
+
 pyrlp (0.5.1-1) unstable; urgency=medium
 
   * The “Zuhair Kutbi” release.
diff -Nru pyrlp-0.5.1/debian/control pyrlp-0.5.1/debian/control
--- pyrlp-0.5.1/debian/control	2017-07-14 15:25:42.0 -0400
+++ pyrlp-0.5.1/debian/control	2019-10-06 16:34:19.0 -0400
@@ -9,11 +9,6 @@
 python3-pytest,
 python3-pytest-runner,
 python3-all,
-python-sphinx,
-python-setuptools,
-python-pytest,
-python-pytest-runner,
-python-all (>= 2.7~),
 dh-python,
 debhelper (>= 10~)
 Homepage: https://github.com/ethereum/pyrlp/
@@ -36,20 +31,6 @@
  .
  This package installs the library for Python 3.
 
-Package: python-rlp
-Architecture: all
-Depends:
-${python:Depends},
-${misc:Depends}
-Suggests:
-python-rlp-doc
-Description: Recursive Length Prefix (RLP) library — Python 2
- The purpose of RLP (Recursive Length Prefix) is to encode arbitrarily
- nested arrays of binary data, and RLP is the main encoding method
- used to serialize objects in Ethereum.
- .
- This package installs the library for Python 2.
-
 Package: python-rlp-doc
 Architecture: all
 Section: doc
diff -Nru pyrlp-0.5.1/debian/rules pyrlp-0.5.1/debian/rules
--- pyrlp-0.5.1/debian/rules	2017-07-14 15:25:42.0 -0400
+++ pyrlp-0.5.1/debian/rules	2019-10-06 16:34:42.0 -0400
@@ -25,7 +25,7 @@
 
 
 %:
-	dh $@ --with python3,python2,sphinxdoc --buildsystem=pybuild
+	dh $@ --with python3,sphinxdoc --buildsystem=pybuild
 
 
 .PHONY: get-packaged-orig-source
diff -Nru pyrlp-0.5.1/debian/tests/control pyrlp-0.5.1/debian/tests/control
--- pyrlp-0.5.1/debian/tests/control	2017-07-14 15:25:42.0 -0400
+++ pyrlp-0.5.1/debian/tests/control	2019-10-06 16:35:00.0 -0400
@@ -2,11 +2,6 @@
 # Control file for Debian ‘autopkgtests’.
 # Documentation: ‘/usr/share/doc/autopkgtest/README.package-tests.rst.gz’.
 
-Tests: smoke-python2
-Depends:
-python-pkg-resources,
-python-rlp
-
 Tests: smoke-python3
 Depends:
 python3-pkg-resources,
diff -Nru pyrlp-0.5.1/debian/tests/smoke-python2 pyrlp-0.5.1/debian/tests/smoke-python2
--- pyrlp-0.5.1/debian/tests/smoke-python2	2017-07-14 15:25:42.0 -0400
+++ pyrlp-0.5.1/debian/tests/smoke-python2	1969-12-31 19:00:00.0 -0500
@@ -1,40 +0,0 @@
-#! /bin/bash
-#
-# debian/tests/smoke-python2
-# Part of Debian ‘pyrlp’ package.
-#
-# Copyright © 2016–2017 Ben Finney 
-# This is free software: you may copy, modify, and/or distribute this work
-# under the terms of the GNU General Public License as published by the
-# Free Software Foundation; version 3 of that license or any later version.
-# No warranty expressed or implied.
-#
-# Smoke test for package in Python 2 environments.
-
-set -o errexit
-set -o errtrace
-set -o nounset
-
-DISTRIBUTION_NAME=rlp
-MODULE_NAMES=(
-rlp
-)
-
-test_opts="--distribution=$DISTRIBUTION_NAME"
-for mod in ${MODULE_NAMES[@]} ; do
-# Accumulate the module names.
-test_opts="$test_opts --module=$mod"
-done
-
-for py in $(pyversions -i) ; do
-printf "Python command: %s\n" $py
-$py debian/tests/smoke_test.py $test_opts
-printf "\n"
-done
-
-
-# Local variables:
-# coding: utf-8
-# mode: shell-script
-# End:
-# vim: fileencoding=utf-8 filetype=sh :

Bug#939091: ITP: libcore-java -- Core barcode encoding/decoding library

2019-10-06 Thread Emmanuel Bourg

On Sun, 1 Sep 2019 10:06:31 +0200 Mechtilde Stehmann
 wrote:
> Package: wnpp
> Severity: wishlist
> * Package name: libcore-java
>   Version : 3.4.0
>   Upstream Author : Jeremias Maerki, ZXing authors
> * URL : http://central.maven.org/maven2/com/google/zxing/core
> * License : Apache-2.0
>   Programming Lang: Java
>   Description : Core barcode encoding/decoding library
> 
> Core barcode encoding/decoding library
> 
> Please also include as much relevant information as possible.
>It is a dependency for jverein (ITP #929477). I want to package
> jverein. I'm
> working on it.
>It should be maintained inside the Java team

Like javase this package name is way too generic. Could you rename it to
zxing-core please?

Emmanuel Bourg

Bug#937112: natsort: diff for NMU version 6.0.0-1.1

2019-10-06 Thread Agustin Henze


Hi Sandro,

On 10/6/19 10:02 PM, Sandro Tosi wrote:

Control: tags 937112 + patch
Control: tags 937112 + pending


Dear maintainer,

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


Yay, that's cool. Thank you for pushing the update! I would prefer using 
-2 instead of 1.1 but it's ok.


Please open a MR in salsa with your changes to keep it synced.

Thanks!

--

Agustin Henze

Bug#941853: crypt(3) should be provided by libxcrypt

2019-10-06 Thread Aurelien Jarno

Hi,

On 2019-10-06 17:55, Marco d'Itri wrote:
> Package: glibc
> Version: 2.29-2
> Severity: normal
> 
> The libc implementation of crypt(3) has been deprecated since 2.28.
> libxcrypt is needed to support modern hashing algorithms.
> 
> How do you want to coordinate switching to libxcrypt?
> 
> The libxcrypt implementation is source and binary backward compatible, 
> so no transitions are needed. I think that we only need to coordinate 
> Replaces/Depends.

The libxcrypt implementation is indeed source backward compatible,
however doesn't seem binary backward compatible. libc6 provides
libcrypt.so.1 while libxcrypt provides libcrypt.so.2.

It is therefore not possible to build glibc with --disable-crypt. I
guess what we can do is to remove crypt.h, libcrypt.a and libcrypt.so
from libc6-dev and add a depends on libcrypt2-dev to libc6-dev. On its
side, libcrypt2-dev should break and replace libc6-dev with the right
version.

There should be no need to add a depends from libc6 to libcrypt2 as the
two libraries have a different soname and thus are co-installable.

If that sounds ok, I guess we can do that in the next glibc upload.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

signature.asc
Description: PGP signature

Bug#939638: ITP: javase -- Java SE-specific extensions to core ZXing library

2019-10-06 Thread Emmanuel Bourg

On Sat, 7 Sep 2019 09:37:56 +0200 Mechtilde Stehmann
 wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: libjavase-java
>   Version : 3.4.0
>   Upstream Author : ZXing authors
> * URL : https://repo1.maven.org/maven2/com/google/zxing/javase/
> * License : Apache 2.0
>   Programming Lang: Java
>   Description : Java SE-specific extensions to core ZXing library
> 
> Java SE-specific extensions to core ZXing library.
> 
> This is a dependency for JVerein (ITP: #929477)
> 
> It should be maintained in the Java-Team.


The name "libjavase-java" is too generic for a Java library ("javase"
stands for "Java Standard Edition"). Could you name it "zxing-javase"
instead please?

Emmanuel Bourg

Bug#941866: gtrayicon: Intent to remove from Debian

Source: gtrayicon
Version: 1.1-1
Severity: serious

As part of a major effort to reduce the amount of GTK2 software in
Debian, I or someone else will be requesting the removal of gtrayicon
from Debian.

It has very low popcorn and hasn't been updated upstream or in Debian
in more than a decade.

If you object, please comment here before the package is removed from
Debian. Or better yet, convert it to gtk3 if you can. See
https://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html

Thanks,
Jeremy Bicha

Bug#941865: libevent: Symbols fix for musl (rebootstrap) (PATCH)

2019-10-06 Thread Davor Ocelic

Source: libevent
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Patch for debian/*.symbols to allow building with musl.
diff -ru libevent-2.1.8-stable/debian/libevent-2.1-6.symbols 
libevent-2.1.8-stable,musl/debian/libevent-2.1-6.symbols
--- libevent-2.1.8-stable/debian/libevent-2.1-6.symbols 2017-07-31 
16:13:49.0 +
+++ libevent-2.1.8-stable,musl/debian/libevent-2.1-6.symbols2019-10-06 
19:15:19.23200 +
@@ -362,7 +362,7 @@
  event_set_mem_functions@Base 2.1.8-stable
  event_sock_err@Base 2.1.8-stable
  event_sock_warn@Base 2.1.8-stable
- event_strlcpy_@Base 2.1.8-stable
+ (arch=!musl-linux-any)event_strlcpy_@Base 2.1.8-stable
  event_warn@Base 2.1.8-stable
  event_warnx@Base 2.1.8-stable
  evhttp_accept_socket@Base 2.1.8-stable
diff -ru libevent-2.1.8-stable/debian/libevent-core-2.1-6.symbols 
libevent-2.1.8-stable,musl/debian/libevent-core-2.1-6.symbols
--- libevent-2.1.8-stable/debian/libevent-core-2.1-6.symbols2017-07-31 
16:13:49.0 +
+++ libevent-2.1.8-stable,musl/debian/libevent-core-2.1-6.symbols   
2019-10-06 19:15:25.91200 +
@@ -306,7 +306,7 @@
  event_set_mem_functions@Base 2.1.8-stable
  event_sock_err@Base 2.1.8-stable
  event_sock_warn@Base 2.1.8-stable
- event_strlcpy_@Base 2.1.8-stable
+ (arch=!musl-linux-any)event_strlcpy_@Base 2.1.8-stable
  event_warn@Base 2.1.8-stable
  event_warnx@Base 2.1.8-stable
  evmap_check_integrity_@Base 2.1.8-stable

Bug#941853: crypt(3) should be provided by libxcrypt

2019-10-06 Thread Marco d'Itri

On Oct 06, Aurelien Jarno  wrote:

> The libxcrypt implementation is indeed source backward compatible,
> however doesn't seem binary backward compatible. libc6 provides
> libcrypt.so.1 while libxcrypt provides libcrypt.so.2.
It provides both, but currently I am not even building libcrypt.so.2 
since I do not see the point.

md@bongo:/USR3/src/P/libxcrypt$ dpkg-deb -c libcrypt1_4.4.8-1_amd64.deb
drwxr-xr-x root/root 0 2019-09-01 22:04 ./
drwxr-xr-x root/root 0 2019-09-01 22:04 ./lib/
drwxr-xr-x root/root 0 2019-09-01 22:04 ./lib/x86_64-linux-gnu/
-rw-r--r-- root/root202680 2019-09-01 22:04 
./lib/x86_64-linux-gnu/libcrypt.so.1.1.0
drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/
drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/share/
drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/share/doc/
drwxr-xr-x root/root 0 2019-09-01 22:04 ./usr/share/doc/libcrypt1/
-rw-r--r-- root/root  6476 2019-09-01 21:03 
./usr/share/doc/libcrypt1/NEWS.gz
-rw-r--r-- root/root  4052 2019-03-06 00:02 
./usr/share/doc/libcrypt1/README.md.gz
-rw-r--r-- root/root   799 2019-09-01 22:04 
./usr/share/doc/libcrypt1/changelog.Debian.gz
-rw-r--r-- root/root  5628 2019-09-01 22:04 
./usr/share/doc/libcrypt1/copyright
lrwxrwxrwx root/root 0 2019-09-01 22:04 
./lib/x86_64-linux-gnu/libcrypt.so.1 -> libcrypt.so.1.1.0
lrwxrwxrwx root/root 0 2019-09-01 22:04 ./usr/share/doc/libcrypt1/TODO 
-> TODO.md

So I think that libc6 should have Depends/Replaces on libcrypt1.

I suggest that we make a pass in experimental to be sure to not leave 
unstable uninstallable for days.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#941850: clamav: inconsistent results with "better zip bomb" reproducers

2019-10-06 Thread Sebastian Andrzej Siewior

On 2019-10-06 16:14:15 [+0200], Hugo Lefeuvre wrote:
> * Inconsistent results with zbsm.zip:
> 
> clamdscan returns different results when run different times. The first
> time the file is considered sane, the second time as "infected".
> 
> It looks like clamdscan doesn't always hit the OverlappingFiles heuristic.
> 
> $ clamdscan /tmp/zbsm.zip
> /tmp/zbsm.zip: OK
> 
> --- SCAN SUMMARY ---
> Infected files: 0
> Time: 120.771 sec (2 m 0 s)
> $ clamdscan /tmp/zbsm.zip
> /tmp/zbsm.zip: Heuristics.Zip.OverlappingFiles FOUND
> 
> --- SCAN SUMMARY ---
> Infected files: 1
> Time: 51.885 sec (0 m 51 s)

I don't understand the difference between the first run vs the second.
Please note that that clamdscan uses the daemon for scanning which *may*
cache the last result. A fresh started daemon:

|$ clamdscan zbsm.zip
|/home/bigeasy/zbsm.zip: Heuristics.Zip.OverlappingFiles FOUND
|
|--- SCAN SUMMARY ---
|Infected files: 1
|Time: 119.048 sec (1 m 59 s)
|$ clamdscan zbsm.zip 
|/home/bigeasy/zbsm.zip: Heuristics.Zip.OverlappingFiles FOUND
|
|--- SCAN SUMMARY ---
|Infected files: 1
|Time: 0.367 sec (0 m 0 s)

So the first scan was *really* performed, the second one used the
previous result. The odd-part is "OK" vs "FOUND" for the daemon and I
can't pin point the 51secs.

> * zbxl.zip
> 
> clamdscan returns OK for zbxl.zip after 0.000 sec. clamscan needs more than
> one minute. This difference is surprising to me.
> 
> $ clamdscan /tmp/zbxl.zip
> /tmp/zbxl.zip: OK
> 
> --- SCAN SUMMARY ---
> Infected files: 0
> Time: 0.000 sec (0 m 0 s)
> $ clamscan /tmp/zbxl.zip
> /tmp/zbxl.zip: OK
> 
> --- SCAN SUMMARY ---
> Known viruses: 6354861
> Engine version: 0.101.4
> Scanned directories: 0
> Scanned files: 1
> Infected files: 0
> Data scanned: 0.00 MB
> Data read: 43.75 MB (ratio 0.00:1)
> Time: 66.032 sec (1 m 6 s)
> 
> This is reproducible with 0.101.4 in unstable (not a VM), stretch and
> jessie (both VMs).

zbxl.zip is a different story. It says "Data scanned: 0.00 MB" which
means it didn't do anything. My guess is that your file limit is 25MiB
while the file is ~40MiB. That time here is just load the database. Take
a look at this:
|$ clamscan --max-filesize 50M zbxl.zip
|zbxl.zip: OK
|
|--- SCAN SUMMARY ---
|Known viruses: 6354861
|Engine version: 0.101.4
|Scanned directories: 0
|Scanned files: 1
|Infected files: 0
|Data scanned: 44.16 MB
|Data read: 43.75 MB (ratio 1.01:1)
|Time: 34.947 sec (0 m 34 s)
|$ clamscan  zbxl.zip
|zbxl.zip: OK

"Data scanned" > 0.

|--- SCAN SUMMARY ---
|Known viruses: 6354861
|Engine version: 0.101.4
|Scanned directories: 0
|Scanned files: 1
|Infected files: 0
|Data scanned: 0.00 MB
|Data read: 43.75 MB (ratio 0.00:1)
|Time: 28.061 sec (0 m 28 s)

"Data scanned" == 0 so ~28secs to load the data base.

|$ clamscan  /etc/ssl/openssl.cnf
|/etc/ssl/openssl.cnf: OK
|
|--- SCAN SUMMARY ---
|Known viruses: 6354861
|Engine version: 0.101.4
|Scanned directories: 0
|Scanned files: 1
|Infected files: 0
|Data scanned: 0.02 MB
|Data read: 0.01 MB (ratio 2.00:1)
|Time: 28.566 sec (0 m 28 s)

Here it scanned something and you see the time it needed is almost the
same as in the previous example where it did just load its database.

So far I don't see anything wrong.

> cheers,
> Hugo

Sebastian

Bug#937112: natsort: diff for NMU version 6.0.0-1.1

Control: tags 937112 + patch
Control: tags 937112 + pending


Dear maintainer,

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

Regards.

diff -Nru natsort-6.0.0/debian/changelog natsort-6.0.0/debian/changelog
--- natsort-6.0.0/debian/changelog	2019-02-11 02:07:09.0 -0500
+++ natsort-6.0.0/debian/changelog	2019-10-06 16:00:20.0 -0400
@@ -1,3 +1,10 @@
+natsort (6.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #937112
+
+ -- Sandro Tosi   Sun, 06 Oct 2019 16:00:20 -0400
+
 natsort (6.0.0-1) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru natsort-6.0.0/debian/control natsort-6.0.0/debian/control
--- natsort-6.0.0/debian/control	2019-02-11 02:07:09.0 -0500
+++ natsort-6.0.0/debian/control	2019-10-06 15:59:15.0 -0400
@@ -7,8 +7,6 @@
  debhelper (>= 11),
  dh-python,
  help2man,
- python-all,
- python-setuptools,
  python3-all,
  python3-setuptools,
  python3-sphinx,
@@ -17,33 +15,6 @@
 Vcs-Git: https://salsa.debian.org/debian/natsort.git
 Vcs-Browser: https://salsa.debian.org/debian/natsort
 
-Package: python-natsort
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Recommends: python-natsort-doc
-Breaks: python-naturalsort
-Conflicts: python-naturalsort
-Replaces: python-naturalsort
-Description: Natural sorting for Python
- natsort lets you apply natural sorting to your sequences easily, for example:
- .
-  >>> from natsort import natsorted
-  >>> a = ['a2', 'a9', 'a1', 'a4', 'a10']
-  >>> data = [['a1', 'a5'], ['a1', 'a40'], ['a10', 'a1'], ['a2', 'a5']]
-  >>> natsorted(a)
-  ['a1', 'a2', 'a4', 'a9', 'a10'
-  >>> natsorted(data)
-  [['a1', 'a5'], ['a1', 'a40'], ['a2', 'a5'], ['a10', 'a1']]
- .
- natsort identifies the numbers and sorts them separately from strings.
- .
- natsort comes with a shell script to use natural sorting in shell scripts. You
- can also execute natsort from the command line with Python -m natsort.
- .
- There exists another natural sorting package for Python called
- python-naturalsort. You may prefer that package if you wish to only sort
- version numbers.
-
 Package: python3-natsort
 Architecture: all
 Recommends: python-natsort-doc
@@ -71,7 +42,6 @@
  .
  This is the Python 3 version of the package.
 
-
 Package: python-natsort-doc
 Architecture: all
 Section: doc
diff -Nru natsort-6.0.0/debian/rules natsort-6.0.0/debian/rules
--- natsort-6.0.0/debian/rules	2019-02-11 02:07:09.0 -0500
+++ natsort-6.0.0/debian/rules	2019-10-06 15:59:58.0 -0400
@@ -9,7 +9,7 @@
 export PYBUILD_NAME=$(DEB_SOURCE)
 
 %:
-	dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
+	dh $@ --with python3,sphinxdoc --buildsystem=pybuild
 
 override_dh_auto_clean:
 	dh_auto_clean
diff -Nru natsort-6.0.0/debian/tests/control natsort-6.0.0/debian/tests/control
--- natsort-6.0.0/debian/tests/control	2019-02-11 02:07:09.0 -0500
+++ natsort-6.0.0/debian/tests/control	2019-10-06 16:00:16.0 -0400
@@ -3,5 +3,4 @@
  tox,
  locales-all,
  build-essential,
- python2-dev,
  python3-dev,
diff -Nru natsort-6.0.0/debian/tests/unittests natsort-6.0.0/debian/tests/unittests
--- natsort-6.0.0/debian/tests/unittests	2019-02-11 02:07:09.0 -0500
+++ natsort-6.0.0/debian/tests/unittests	2019-10-06 16:00:09.0 -0400
@@ -1 +1 @@
-tox -e "py27, py37, docs"
+tox -e "py37, docs"

Bug#941864: cups: pxlmono fails to print on Samsung ML-2250 with 9.28rc

2019-10-06 Thread Johannes Stezenbach

Package: ghostscript
Version: 9.28~~rc4~dfsg-1
Severity: important
Tags: upstream

Dear Maintainer,

my Samsung ML-2250 printer stopped to work, it outputs a page with
this error message:

  PCL6 ERROR - sb_count != -128
POSITION : 0xbc8 (3016)
SYSTEM   : XLPGP/xl_pattern
LINE : 890
VERSION  : PCL6 3.34 05-01-2004

It took me a while to figure out what part of the printing system
caused the failure, but after downgrading ghostscript to
9.27~dfsg-3.1 printing worked again.

For fun I decided to dig into it:

- I used "gs -sDEVICE=pxlmono -sOutputFile=t.raw -r300x300 foo.pdf"
  to generate output for 9.27 and 9.28

- I used ghostpdl/pcl/tools/pxldis.py tool from ghostscript
  source to convert it to something readable and compared it

  -> the only difference is the use of RLE compression with 9.28

- I checked the RLE encoding and it is correct
  (pcl_xl_2_0_technical_reference_rev2_2.pdf appendix Q)

Then it dawned on me that ghostscript's 0x80 "EOD" marker
is rejected by the Samsung printer firmware.

Ghostscript adds the (apparently useless, at least for PCL6)
EOD marker as the last byte of RLE compressed data.  According to
spec, 0x80 bytes have no meaning and should be ignored
("A control byte of -128 is ignored and is not included in the
decompressed data. The byte following a control byte of 128 is
treated as the next control byte.").  But the error message from
my printer reads like a failed assertion for this case, i.e. the
printer firmware is buggy.

To test my theory I made the following change:

--- ghostscript-9.28~~rc4~dfsg.orig/base/srle.c
+++ ghostscript-9.28~~rc4~dfsg/base/srle.c
@@ -329,11 +329,13 @@ run_len_0_n0_read:
 *++q = n0;
 }
 case state_eod_unmarked:
+#if 0
 if (wlimit - q < 1) {
 ss->state = state_eod_unmarked;
 goto no_output_room;
 }
 *++q = 128; /* EOD */
+#endif
 case state_eod:
 ss->run_len = 0;
 ss->state = state_0;

Success!  It make my printer work again.


Best Regards,
Johannes


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

Kernel: Linux 5.2.15 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages ghostscript depends on:
ii  libc6   2.29-2
ii  libgs9  9.28~~rc4~dfsg-1

ghostscript recommends no packages.

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.28~~rc4~dfsg-1

-- no debconf information

Bug#941863: XDamage events are intermingled with GetImage response

2019-10-06 Thread Petr Vandrovec

Package: xserver-xorg-core
Version: 2:1.20.4-1

For over a year vino-server is crashing on me on startup, complaining
that unknown sequence was received from X server:

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been 
called
[xcb] Aborting, sorry about that.
vino-server: ../../src/xcb_io.c:260: poll_for_event: Assertion 
`!xcb_xlib_threads_sequence_lost' failed.
Aborted (core dumped)

vino-server does not use X session from multiple threads, and no amount of
added locking solved the problem.  Only thing that worked was running
vino-server under strace - if strace is attached, there is no crash.

So I added logging everywhere, to find that just before bogus sequence
is detected, client makes GetImage call - and data returned for that call
are corrupted (assert for len != 1976 is added to stop process in its tracks
when GetImage with corrupted response arrives):

(gdb) bt
#0  0x7fb954978081 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7fb954963535 in __GI_abort () at abort.c:79
#2  0x7fb95496340f in __assert_fail_base
(fmt=0x7fb954ac5710 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
assertion=0x7fb953bf1260 "len != 1976", file=0x7fb953bf121c 
"../../src/xcb_in.c", line=413, function=)
at assert.c:92
#3  0x7fb954970b92 in __GI___assert_fail
(assertion=assertion@entry=0x7fb953bf1260 "len != 1976", 
file=file@entry=0x7fb953bf121c "../../src/xcb_in.c", line=line@entry=413, 
function=function@entry=0x7fb953bf12d0 <__PRETTY_FUNCTION__.11208
> "read_block") at assert.c:101
#4  0x7fb953be0ddc in read_block (len=, buf=0x557810253fd0, 
fd=3) at ../../src/xcb_in.c:413
#5  0x7fb953be0ddc in _xcb_in_read_block (c=c@entry=0x55780ffe0e60, 
buf=buf@entry=0x557810253fb0, len=len@entry=2008) at ../../src/xcb_in.c:1087
#6  0x7fb953be110f in read_packet (c=0x55780ffe0e60) at 
../../src/xcb_in.c:268
#7  0x7fb953be110f in _xcb_in_read (c=c@entry=0x55780ffe0e60) at 
../../src/xcb_in.c:1042
#8  0x7fb953bdef7f in _xcb_conn_wait (c=c@entry=0x55780ffe0e60, 
cond=cond@entry=0x7fffe9524360, vector=vector@entry=0x0, count=count@entry=0x0) 
at ../../src/xcb_conn.c:515
#9  0x7fb953be061f in wait_for_reply (c=c@entry=0x55780ffe0e60, 
request=request@entry=467, e=e@entry=0x7fffe9524420) at ../../src/xcb_in.c:525
#10 0x7fb953be0792 in xcb_wait_for_reply64 (c=c@entry=0x55780ffe0e60, 
request=467, e=e@entry=0x7fffe9524420) at ../../src/xcb_in.c:569
#11 0x7fb955183e38 in _XReply (dpy=dpy@entry=0x55780ffdfba0, 
rep=rep@entry=0x7fffe9524480, extra=extra@entry=0, discard=discard@entry=0) at 
../../src/xcb_io.c:609
#12 0x7fb9551691dc in XGetImage (dpy=0x55780ffdfba0, d=1001, x=1465, 
y=1162, width=26, height=38, plane_mask=18446744073709551615, format=2) at 
../../src/GetImage.c:76
#13 0x7fb95516946a in XGetSubImage
(dpy=, d=, x=x@entry=1465, y=y@entry=1162, 
width=width@entry=26, height=height@entry=38, plane_mask=18446744073709551615, 
format=2, dest_image=0x5578101502e0, dest_x=
1465, dest_y=1162) at ../../src/GetImage.c:138
#14 0x55780fe076fa in vino_fb_xdamage_idle_handler (vfb=0x55781017cd00 
[VinoFB]) at server/vino-fb.c:602
#15 0x7fb955881d8e in g_main_dispatch (context=0x55781000fc40) at 
../../../glib/gmain.c:3179
#16 0x7fb955881d8e in g_main_context_dispatch 
(context=context@entry=0x55781000fc40) at ../../../glib/gmain.c:3844
#17 0x7fb955882140 in g_main_context_iterate (context=0x55781000fc40, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:3917
#18 0x7fb955882413 in g_main_loop_run (loop=0x557810056210) at 
../../../glib/gmain.c:4111
#19 0x55780fe06f7d in main (argc=, argv=) at 
server/vino-main.c:319


Received response header says that image with 494 dwords should be received:

(gdb) frame 5
#5  _xcb_in_read_block (c=c@entry=0x55780ffe0e60, buf=buf@entry=0x557810253fb0, 
len=len@entry=2008) at ../../src/xcb_in.c:1087
1087int ret = read_block(c->fd, (char *) buf + done, len - done);
(gdb) print *(xcb_generic_event_t*) buf
$1 = {response_type = 1 '\001', pad0 = 16 '\020', sequence = 467, pad = {494, 
33, 0, 0, 0, 0, 0}, full_sequence = 30605658}

But image data do not look anything like image data.  Instead they look like 
XDamage event
(xdpyinfo confirms that 90 is XDAMAGE event):

(gdb) frame 4
#4  0x7fb953be0ddc in read_block (len=, buf=0x557810253fd0, 
fd=3) at ../../src/xcb_in.c:413
413 assert(len != 1976);
(gdb) x /10bx buf
0x557810253fd0: 0x5a0x010xd30x010xe90x030x000x00
0x557810253fd8: 0x060x00
(gdb) print *(xcb_generic_event_t*) buf
$2 = {response_type = 90 'Z', pad0 = 1 '\001', sequence = 467, pad = {1001, 
37748742, 1583889968, 76678587, 1441814, 0, 78644800}, full_sequence = 
4156487614}

So somehow XDamage event got inserted between GetImage response header, and 
image data.  Note that drawable
returned by XDamage (1001)

Bug#936563: frozen-flask: diff for NMU version 0.11-3.1

Control: tags 936563 + patch
Control: tags 936563 + pending


Dear maintainer,

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

Regards.

diff -Nru frozen-flask-0.11/debian/changelog frozen-flask-0.11/debian/changelog
--- frozen-flask-0.11/debian/changelog	2015-08-15 03:44:17.0 -0400
+++ frozen-flask-0.11/debian/changelog	2019-10-06 15:43:03.0 -0400
@@ -1,3 +1,10 @@
+frozen-flask (0.11-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #936563
+
+ -- Sandro Tosi   Sun, 06 Oct 2019 15:43:03 -0400
+
 frozen-flask (0.11-3) unstable; urgency=medium
 
* Fixes test suite error by exporting locale to utf8
diff -Nru frozen-flask-0.11/debian/control frozen-flask-0.11/debian/control
--- frozen-flask-0.11/debian/control	2015-07-14 11:52:10.0 -0400
+++ frozen-flask-0.11/debian/control	2019-10-06 15:42:52.0 -0400
@@ -4,11 +4,8 @@
 Priority: extra
 Build-Depends: debhelper (>= 9),
dh-python,
-   python-setuptools,
python3-setuptools,
-   python-all (>= 2.6.6-3~),
python3-all, 
-   python-flask (>= 0.7),
python3-flask (>= 0.7)
 Standards-Version: 3.9.6
 X-Python-Version: >= 2.6
@@ -17,17 +14,6 @@
 Vcs-browser: https://github.com/SimonSapin/Frozen-Flask/
 Vcs-Git: https://github.com/SimonSapin/Frozen-Flask.git
 
-Package: python-frozen-flask
-Architecture: all
-Multi-Arch: foreign
-Depends: ${misc:Depends}, ${python:Depends}, python-flask (>= 0.7)
-Description: Freezes a Flask application into a set of static files 
- Frozen-Flask freezes a Flask application into a set of static files. 
- The result can be hosted without any server-side software other than a 
- traditional web server.
- .
- This is a python2 package.
-
 Package: python3-frozen-flask
 Architecture: all
 Multi-Arch: foreign
@@ -37,4 +23,4 @@
  The result can be hosted without any server-side software other than a 
  traditional web server.
  .
- This is a python3 package.
\ No newline at end of file
+ This is a python3 package.
diff -Nru frozen-flask-0.11/debian/rules frozen-flask-0.11/debian/rules
--- frozen-flask-0.11/debian/rules	2015-08-15 07:01:47.0 -0400
+++ frozen-flask-0.11/debian/rules	2019-10-06 15:43:00.0 -0400
@@ -5,4 +5,4 @@
 export PYBUILD_NAME=frozen-flask
 export LC_ALL=C.UTF-8
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild

Bug#941731: appstream-util: unable to create directory '/sbuild-nonexistent/.cache/dconf'

Jérémy, I think the actual error is this:

FAILED:
• tag-missing   :  required [use
https://odrs.gnome.org/oars]
• tag-missing   :  required
Validation of files failed

appstream-glib 0.7.16 made the validation requirements stricter.
Therefore, I believe this isn't an appstream-glib bug and this bug
report should be closed.

The warnings you see about the directory permission denied were also
present in your last experimental upload. I am attaching a patch you
can apply if you don't want to see those warnings in your build log.
Applying the patch would have made it a lot easier for you to see
where the failure was in this case.

Thanks,
Jeremy Bicha
From 783bb73d90a2ce5a11128d8e248521f8cad5a8bc Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Sun, 6 Oct 2019 15:19:11 -0400
Subject: [PATCH] Set $XDG_RUNTIME_DIR to clean up some build log noise

---
 debian/rules | 8 
 1 file changed, 8 insertions(+)

diff --git a/debian/rules b/debian/rules
index 324bc86..34adb0e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,6 +3,8 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+CHECK_HOME = $(CURDIR)/debian/tmp/home
+
 CONFFLAGS := 	--with-systemduserunitdir=/usr/lib/systemd/user \
 		--enable-introspection \
 		--enable-appstream-util \
@@ -27,3 +29,9 @@ endif
 override_dh_clean:
 	dh_clean
 	rm -f po/Makefile.in.in m4/intltool.m4 config.log
+
+override_dh_auto_test:
+ifeq (, $(filter nocheck, $(DEB_BUILD_OPTIONS)))
+	mkdir -p -m0700 $(CHECK_HOME)
+	XDG_RUNTIME_DIR=$(CHECK_HOME) dh_auto_test
+endif
-- 
2.20.1

Bug#941810: buster-pu: package openssh/1:7.9p1-10

2019-10-06 Thread Salvatore Bonaccorso

Hi Colin,

On Sun, Oct 06, 2019 at 08:03:19PM +0100, Colin Watson wrote:
> On Sun, Oct 06, 2019 at 04:22:23PM +0200, Salvatore Bonaccorso wrote:
> > On Sat, Oct 05, 2019 at 10:39:29PM +0100, Colin Watson wrote:
> > > https://bugs.debian.org/941663 reports an OpenSSH regression on old
> > > kernels prompted by the interaction between an OpenSSL update and a
> > > seccomp filter; https://bugs.debian.org/941665 and
> > > https://github.com/openssh/openssh-portable/pull/149 have more details.
> > > The patch is an easy one to cherry-pick, and I've attached the resulting
> > > diff.  I'd like approval to upload it.
> > > 
> > > I'm not sure where's best to upload this to.  Although I've filed this
> > > as a stable update request, there's an argument that perhaps it should
> > > be issued through the same channels as the OpenSSL update
> > > (stable-security and then copied to stable-proposed-updates, according
> > > to https://tracker.debian.org/pkg/openssl), so I've CCed team@security.
> > > Any advice?
> > 
> > Okay let's be on the safe side and update openssh for this functional
> > regression via buster-security.
> > 
> > Can you adjust the changelog accordingly and upload to
> > security-master? (Make sure to build with -sa, and to not include a
> > _{arch}.buildinfo file in case you perform a source only upload).
> 
> Done.  I usually get something wrong in the mechanics of doing security
> uploads, but maybe I got it right for once.

Looks good so far!

> I don't have a pre-3.19 system around to test this on, but I at least
> made sure that an ordinary buster system (with 4.19) is fine.

I was able to reproduce the issue in a buster LXC container running on
a host with < 3.19 kernel (specifically reproduced with a jessie
host). Will double check the fixed packages as well in that setup.

Regards,
Salvatore

Bug#941779: aiscm: FTBFS on amd64

2019-10-06 Thread Jan Wedekind


Hi Andrey,
I have disabled building of "mirror.jpg" which seems to fail on the Debian 
build server. Can you upload the new version [1,2]? Thanks in advance.


Regards
Jan

[1]: https://mentors.debian.net/package/aiscm
[2]: https://mentors.debian.net/debian/pool/main/a/aiscm/aiscm_0.19.2-1.dsc

On Sat, 5 Oct 2019, Graham Inggs wrote:


Source: aiscm
Version: 0.19.1-1
Severity: serious
Tags: ftbfs

Hi Maintainer

A recent rebuild of aiscm failed to build from source [1].
I've copied what I hope is the relevant part of the log below.

Regards
Graham


[1] 
https://buildd.debian.org/status/fetch.php?pkg=aiscm=amd64=0.19.1-1%2Bb1=1569355414=0


[swscaler @ 0x5630f9beb680] Warning: data is not aligned! This can
lead to a speed loss
LD_LIBRARY_PATH=../aiscm/.libs: GUILE_AUTO_COMPILE=0 /usr/bin/guile -L
.. ../tests/integration/gauss_gradient.scm
LD_LIBRARY_PATH=../aiscm/.libs: GUILE_AUTO_COMPILE=0 /usr/bin/guile -L
.. ../tests/integration/harris_stephens.scm
make[3]: *** [Makefile:672: mirror.jpg] Aborted
make[3]: *** Waiting for unfinished jobs
[swscaler @ 0x55a25dc74340] Warning: data is not aligned! This can
lead to a speed loss
[swscaler @ 0x55777063f340] Warning: data is not aligned! This can
lead to a speed loss
rm convolution.tmp index.tmp operation.tmp io.tmp array.tmp
assembler.tmp installation.tmp
make[3]: Leaving directory '/<>/doc'
make[2]: *** [Makefile:472: all-recursive] Error 1
make[2]: Leaving directory '/<>'
make[1]: *** [Makefile:404: all] Error 2
make[1]: Leaving directory '/<>'
dh_auto_build: make -j4 returned exit code 2
make: *** [debian/rules:10: build-arch] Error 255

Bug#936331: construct.legacy: diff for NMU version 2.5.3-2.1

Control: tags 936331 + patch
Control: tags 936331 + pending


Dear maintainer,

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

Regards.

diff -Nru construct.legacy-2.5.3/debian/changelog construct.legacy-2.5.3/debian/changelog
--- construct.legacy-2.5.3/debian/changelog	2017-12-09 18:55:47.0 -0500
+++ construct.legacy-2.5.3/debian/changelog	2019-10-06 14:38:10.0 -0400
@@ -1,3 +1,10 @@
+construct.legacy (2.5.3-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #936331
+
+ -- Sandro Tosi   Sun, 06 Oct 2019 14:38:10 -0400
+
 construct.legacy (2.5.3-2) unstable; urgency=medium
 
   * Remove bogus -doc package suggestion
diff -Nru construct.legacy-2.5.3/debian/control construct.legacy-2.5.3/debian/control
--- construct.legacy-2.5.3/debian/control	2017-12-09 18:54:15.0 -0500
+++ construct.legacy-2.5.3/debian/control	2019-10-06 14:38:02.0 -0400
@@ -3,9 +3,9 @@
 Priority: optional
 Maintainer: Hilko Bengen 
 Build-Depends: debhelper (>= 10), dh-python,
- python-all, python3-all,
- python-setuptools, python3-setuptools,
- python-six, python3-six,
+ python3-all,
+ python3-setuptools,
+ python3-six,
 Standards-Version: 4.1.2
 Homepage: https://pypi.python.org/pypi/construct-legacy
 X-Python-Version: >= 2.6
@@ -13,23 +13,6 @@
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/construct.legacy.git
 Vcs-Browser: https://anonscm.debian.org/git/collab-maint/construct.legacy.git
 
-Package: python-construct.legacy
-Architecture: all
-Depends: ${python:Depends}, ${misc:Depends}
-Description: legacy fork of declarative binary data parser/builder (Python 2)
- Construct is a Python library for parsing and building of data
- structures (binary or textual).
- .
- It is based on the concept of defining data structures in a declarative
- manner, rather than procedural code: more complex constructs are composed of
- a hierarchy of simpler ones. It's the first library that makes parsing
- fun, instead of the usual headache it is today.
- .
- This is a legacy fork of the original construct 2.5.3 repackaged for
- compatibility purposes.
- .
- This package installs the library for Python 2.
-
 Package: python3-construct.legacy
 Architecture: all
 Depends: ${python3:Depends}, ${misc:Depends}
diff -Nru construct.legacy-2.5.3/debian/rules construct.legacy-2.5.3/debian/rules
--- construct.legacy-2.5.3/debian/rules	2017-11-26 18:08:23.0 -0500
+++ construct.legacy-2.5.3/debian/rules	2019-10-06 14:38:09.0 -0400
@@ -3,4 +3,4 @@
 export PYBUILD_NAME=construct.legacy
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild

Bug#941677: fixed in master branch

2019-10-06 Thread Andreas Schwarz



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Helmut,

thx for your contribution.

I've fixed this issue upstream with commit
32e6636fd55aa261ab69f1a2c2ab72728fc75c8e
and I'm planning a new package release around New Year's or at least
january.
-BEGIN PGP SIGNATURE-

iQJKBAEBCAA0FiEEL4PLpYeMC2AyT/wjC5HWhKNuIr8FAl2aO00WHGEuc2Nod2Fy
el9kZXZAZG50dy5kZQAKCRALkdaEo24iv9GzEACFL85XpwX41jNh5r/e63mRzCAz
8wxd4PER60G+QEkmCpv5gy9Kt0hNbBrUEq4D/ycs2FulCiaU9jW9Kdz2zNHC1aY4
xQLsqUwdqOL1ONIOW9LvJYdty96hwYlJ9dWG0Wz7x+YQc2Yr5eMkIvaY46L0lKfc
yc5Qs6KsUHRGD4/2v1/FlinI7stV70o9/EV3C/xgyp9kiJ/YHWSIzmwaCvXMHy5Y
1hMQ7jEcvmTNmsvd6i94Z3DWpgn7LUjZfFhcNOkhSDszb1q4zfqzkoDZV/4W4xK5
3MSFq2Dz5GR5gO1aySO+8qIs/+ALS06YKKk+mEegPXbOxuxc2LopaoeMkFV6f0XR
2l4qVhnVL3KTs0tjgRdG8GUFUf9EGpasnwKrhtI3brSlGh3dQOia7A+Lzzxv0HU5
xkHDhgafosPSWWDJ/Gc3kzaxHyzkjLrnnvd7UkXh/zQZhCPkdTdvSwTtv6WHRYKx
i8eLfTM7f9VcozSOgnxEfpd/sZaAcQ0mr4K4kfnb5xIiuiV7zkoJElCLA3qqwAe+
7MmTRB/cR+Aj83YXcnNttsm9eaQ+cOHjE1reEb7f7SiUxZVlZ0mB3hWG2zn0xSbM
vf5whE3/nDtiWNVinchBqvA0S0NeQkM7+aBqTdGOcxroNIftsDAPiPYQcVbWyUq3
U/OgGOttNHSI18st/g==
=11sj
-END PGP SIGNATURE-

Bug#941823: tabu: cell background colours broken

2019-10-06 Thread Thorsten Glaser

Hi Hilmar,

>Is this https://github.com/tabu-issues-for-future-maintainer/tabu/issues/13

looks like it; note it is a regression against earlier versions.

bye,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Bug#941640: gnome-session: Gnome 3.34 fails to start showing grey screen "Oh no, something has gone wrong"

On Sun, Oct 6, 2019 at 11:12 AM Michael Biebl  wrote:
> I'm still getting the fail-whale for the GNOME Classic session.
> Tried with a fresh user account, just to be sure.
>
> Should this bug report be reopened or should I file a new one?

Please file a new bug.

smcv and I are thinking that gnome-session 3.34 may be required to
finish up the big GNOME 3.34 transition. As bad as breaking GNOME
Classic is, breaking all of GNOME in Testing (
https://bugs.debian.org/941782 ) is worse. So please file as Important
and we can bump to Serious afterwards.

I did confirm that I was unable to log in to GNOME Classic on Ubuntu
19.10 too. Ubuntu killed the fail whale, but it feels like the same
bug to me.

Thanks,
Jeremy Bicha

Bug#774415: #774415: devscripts: please add the srebuild wrapper for reproducible builds

2019-10-06 Thread Holger Levsen

hi,

so I thought I'd be bold and add the srebuild wrapper to src:devscripts
in git this weekend...

So I re-read https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774415
rather completly and noticed, that

- the branch devscripts-srebuild from https://salsa.debian.org/yadd/devscripts
for a long time used the 2014 srebuild script from josch and was only
'recently' based on the 2016 debrebuild script from josch.
(The last 4 commits on this branch have all this history and thus are
easy to grasp.)

- the NYU rebuilders OTOH use a by now quite modified version of the
2014 srebuild script (with support for in-toto etc), see

https://salsa.debian.org/reproducible-builds/debian-rebuilder-setup/blob/master/builder/srebuild

- the authoritive source/git repo for josch script(s) is the #774415 bug
report? Or yadd's repo? ;)

- the 2016 debrebuild script doesn't do a rebuild by itself but produces
a command which is to be run with sudo, so we need another wrapper
here.

- there is also
https://salsa.debian.org/reproducible-builds/attic/reprobuild/blob/master/repro-build.pl
from Steven Chamberlain...

- for the sake of presenting a complete picture of this discussion I
want to state that I also thought about packaging $name (srebuild,
debrebuild, repro-build, whatever) as a seperate package, not part of
devscripts. I've decided, at least for now, to first try to make it
usable as part of the devscripts packages. Maybe however we want more
configurability (like the in-toto support or other stuff which was
added to NYU's srebuild fork) and this wont work in the long term.

- I think I'd like "something working most or even half the time"
installable in Debian unstable by the end of the month. This is long
overdue. (tm)
(Only halfworking would be fine (for a start) for me cause there are
quite some special cases, like binNMUs or support for unclean build
envs or whatever.)

- I think I want(ed) to package the debrebuild script, as this is josch's
reimplementation of the same problem. And I thought NYU had some
patches on top of this and I was thinking to sort out this fork later
(eg by making some of their features optional), but now I've seen that
they forked the old srebuild script and I'm unsure what to do.

Comments, suggestions or any other feedback much welcome!

--
cheers,
Holger

---
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc
Description: PGP signature

Bug#941810: buster-pu: package openssh/1:7.9p1-10

2019-10-06 Thread Colin Watson

On Sun, Oct 06, 2019 at 04:22:23PM +0200, Salvatore Bonaccorso wrote:
> On Sat, Oct 05, 2019 at 10:39:29PM +0100, Colin Watson wrote:
> > https://bugs.debian.org/941663 reports an OpenSSH regression on old
> > kernels prompted by the interaction between an OpenSSL update and a
> > seccomp filter; https://bugs.debian.org/941665 and
> > https://github.com/openssh/openssh-portable/pull/149 have more details.
> > The patch is an easy one to cherry-pick, and I've attached the resulting
> > diff.  I'd like approval to upload it.
> > 
> > I'm not sure where's best to upload this to.  Although I've filed this
> > as a stable update request, there's an argument that perhaps it should
> > be issued through the same channels as the OpenSSL update
> > (stable-security and then copied to stable-proposed-updates, according
> > to https://tracker.debian.org/pkg/openssl), so I've CCed team@security.
> > Any advice?
> 
> Okay let's be on the safe side and update openssh for this functional
> regression via buster-security.
> 
> Can you adjust the changelog accordingly and upload to
> security-master? (Make sure to build with -sa, and to not include a
> _{arch}.buildinfo file in case you perform a source only upload).

Done.  I usually get something wrong in the mechanics of doing security
uploads, but maybe I got it right for once.

I don't have a pre-3.19 system around to test this on, but I at least
made sure that an ordinary buster system (with 4.19) is fine.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#941803: debian-policy: dependencies on font packages

2019-10-06 Thread Russ Allbery

Guillem Jover  writes:
> On Sat, 2019-10-05 at 21:44:25 +0200, Stephen Kitt wrote:

>> It’s common for packages to strongly depend on non-X fonts they need;
>> see for example the reverse dependencies of fonts-dejavu. While lintian
>> objects to X font depencencies
>> (),
>> it doesn’t have anything to say about non-X fonts (rightly so).
>> 
>> Wouldn’t it make sense to relax the constraints on X font
>> dependencies?

> Looks like it to me, yes.

Thank you for raising this, Stephen!  I use remote display of X
applications all the time and noticed a while back that fonts were being
loaded on the local machine instead of on the machine hosting the X
server, but never had a chance to dig into what had changed.

This change looks right to me as well.  Do you have time to propose a
diff?

-- 
Russ Allbery (r...@debian.org)

Bug#941862: buster-pu: packages ember/0.7.2+dfsg-3 and cegui-mk2/0.8.7-3

2019-10-06 Thread Olek Wojnar

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

Stable Release Team,

I would like to add the ember package [1] to proposed-updates. This package
did not make it into buster before release due to problems with one of its
dependencies, CEGUI [2]. I have worked with the CEGUI maintainer to fix the
problems, transition maintenance to the Debian Games Team, and add myself as
an uploader to help with future updates. 

Both  ember and CEGUI are currently in oldstable and all other dependencies are
already in buster. Since ember is the package that several of these
dependencies ultimately exist to support, I would really like to see it in the
stable distribution.

Please let me know if you need any additional information regarding my
request. Thanks in advance!

-Olek


[1] https://tracker.debian.org/pkg/ember
[2] https://tracker.debian.org/pkg/cegui-mk2

Bug#941731: appstream-util: unable to create directory '/sbuild-nonexistent/.cache/dconf'

Control: severity -1 serious

gpaste 3.34.0-2 (from git) builds in Ubuntu 19.10 which still has
appstream-glib 0.7.14-1. So I'm going to bump this bug's priority to
keep appstream-glib from migrating to Testing tonight.

Thanks,
Jeremy Bicha

Bug#935210: python-nbxmpp: diff for NMU version 0.6.10-1.1

Control: tags 935210 + patch
Control: tags 935210 + pending


Dear maintainer,

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

Regards.

diff -Nru python-nbxmpp-0.6.10/debian/changelog python-nbxmpp-0.6.10/debian/changelog
--- python-nbxmpp-0.6.10/debian/changelog	2019-02-19 03:46:41.0 -0500
+++ python-nbxmpp-0.6.10/debian/changelog	2019-10-06 14:33:39.0 -0400
@@ -1,3 +1,10 @@
+python-nbxmpp (0.6.10-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #935210
+
+ -- Sandro Tosi   Sun, 06 Oct 2019 14:33:39 -0400
+
 python-nbxmpp (0.6.10-1) unstable; urgency=medium
 
   * New upstream bug fix release
diff -Nru python-nbxmpp-0.6.10/debian/control python-nbxmpp-0.6.10/debian/control
--- python-nbxmpp-0.6.10/debian/control	2019-02-19 03:44:29.0 -0500
+++ python-nbxmpp-0.6.10/debian/control	2019-10-06 14:33:19.0 -0400
@@ -4,24 +4,13 @@
 Maintainer: Debian XMPP Maintainers 
 Uploaders: Tanguy Ortolo ,
 W. Martin Borgert 
-Build-Depends: debhelper (>= 11), dh-python, python-all, python3-all, python3-gi
+Build-Depends: debhelper (>= 11), dh-python, python3-all, python3-gi
 Standards-Version: 4.1.4
 Rules-Requires-Root: no
 Homepage: https://dev.gajim.org/gajim/python-nbxmpp
 Vcs-Git: https://salsa.debian.org/xmpp-team/python-nbxmpp.git
 Vcs-Browser: https://salsa.debian.org/xmpp-team/python-nbxmpp
 
-Package: python-nbxmpp
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends}
-Recommends: python-openssl
-Description: Non blocking Jabber/XMPP Python library
- python-nbxmpp is a Python library that provides a way for Python applications
- to use Jabber/XMPP networks in a non-blocking way. This library is initialy a
- fork of xmpppy one, but using non-blocking sockets.
- .
- This is the Python 2 version of this library.
-
 Package: python3-nbxmpp
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}, python3-gi
diff -Nru python-nbxmpp-0.6.10/debian/rules python-nbxmpp-0.6.10/debian/rules
--- python-nbxmpp-0.6.10/debian/rules	2019-02-19 03:44:29.0 -0500
+++ python-nbxmpp-0.6.10/debian/rules	2019-10-06 14:33:38.0 -0400
@@ -9,7 +9,7 @@
 export PYBUILD_NAME=nbxmpp
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_installdocs:
 	dh_installdocs -ppython-nbxmpp-doc --doc-main-package=python-nbxmpp-doc

Bug#933548: transition: gnome-desktop3

2019-10-06 Thread Paul Gevers

Hi,

On 06-10-2019 18:46, Simon McVittie wrote:
> On Wed, 02 Oct 2019 at 21:00:29 +0200, Paul Gevers wrote:
>> If my view of things is
>> up-to-date and correct, it's the last piece of the puzzle together with
>> the samba situation (assuming LO will just build on mips64el).
> 
> If I'm reading the log correctly, we have the remaining issues still
> blocking this transition:
> 
> * gnome-session is too young (3 of 5 days) due to the fix for #941640
>   having been uploaded; perhaps it can be fast-tracked?

That package wasn't on my radar. Thanks for informing us. What about the
last comment in that bug?

> * some packages become uninstallable on mipsel:
> 
>> trying: glib2.0 mutter -libgnome-desktop-3-17/armhf 
>> gsettings-desktop-schemas gnome-settings-daemon -libgnome-desktop-3-17/armel 
>> gdk-pixbuf -libgnome-desktop-3-17/arm64 -libgnome-desktop-3-17/amd64 
>> -libgnome-desktop-3-17/s390x -libgnome-desktop-3-17/i386 
>> -libgnome-desktop-3-17/mips64el -libgnome-desktop-3-17/ppc64el 
>> -libgnome-desktop-3-17/mipsel gnome-control-center samba talloc tevent ldb 
>> sssd tdb gvfs gnome-shell gnome-shell-extensions 
>> gnome-shell-extension-caffeine evolution-data-server 
>> gnome-phone-manager/s390x gnome-phone-manager/mips64el abiword/armhf 
>> gnome-panel libreoffice/i386 gnome-contacts folks glabels/amd64 abiword/i386 
>> gnome-phone-manager/armhf glabels/mips64el glabels/i386 gnome-todo 
>> gnome-phone-manager/arm64 gnome-phone-manager/amd64 glabels/armel 
>> gnome-phone-manager/armel abiword/armel abiword/mips64el abiword/s390x 
>> evolution-ews evolution evolution-rss abiword/mipsel libreoffice/mips64el 
>> libreoffice/amd64 bijiben glabels/mipsel libreoffice/ppc64el 
>> libreoffice/armhf libreoffice/mipsel abiword/arm64 glabels/arm64 
>> glabels/s390x gnome-phone-manager/mipsel gnome-phone-manager/ppc64el 
>> gnome-calendar glabels/armhf abiword/amd64 libreoffice/armel almanah 
>> glabels/ppc64el gnome-phone-manager/i386 abiword/ppc64el libreoffice/arm64 
>> libreoffice/s390x gnome-shell-extension-top-icons-plus 
>> gnome-shell-extension-workspaces-to-dock budgie-desktop
>> skipped: glib2.0 mutter -libgnome-desktop-3-17/armhf 
>> gsettings-desktop-schemas gnome-settings-daemon -libgnome-desktop-3-17/armel 
>> gdk-pixbuf -libgnome-desktop-3-17/arm64 -libgnome-desktop-3-17/amd64 
>> -libgnome-desktop-3-17/s390x -libgnome-desktop-3-17/i386 
>> -libgnome-desktop-3-17/mips64el -libgnome-desktop-3-17/ppc64el 
>> -libgnome-desktop-3-17/mipsel gnome-control-center samba talloc tevent ldb 
>> sssd tdb gvfs gnome-shell gnome-shell-extensions 
>> gnome-shell-extension-caffeine evolution-data-server 
>> gnome-phone-manager/s390x gnome-phone-manager/mips64el abiword/armhf 
>> gnome-panel libreoffice/i386 gnome-contacts folks glabels/amd64 abiword/i386 
>> gnome-phone-manager/armhf glabels/mips64el glabels/i386 gnome-todo 
>> gnome-phone-manager/arm64 gnome-phone-manager/amd64 glabels/armel 
>> gnome-phone-manager/armel abiword/armel abiword/mips64el abiword/s390x 
>> evolution-ews evolution evolution-rss abiword/mipsel libreoffice/mips64el 
>> libreoffice/amd64 bijiben glabels/mipsel libreoffice/ppc64el 
>> libreoffice/armhf libreoffice/mipsel abiword/arm64 glabels/arm64 
>> glabels/s390x gnome-phone-manager/mipsel gnome-phone-manager/ppc64el 
>> gnome-calendar glabels/armhf abiword/amd64 libreoffice/armel almanah 
>> glabels/ppc64el gnome-phone-manager/i386 abiword/ppc64el libreoffice/arm64 
>> libreoffice/s390x gnome-shell-extension-top-icons-plus 
>> gnome-shell-extension-workspaces-to-dock budgie-desktop (182, 5108, 124)
>> got: 37+0: a-1:a-0:a-0:a-0:i-24:m-0:m-11:p-0:s-1
>> * mipsel: budgie-core, eweouz, freeipa-client, gdm3, gnome, gnome-core, 
>> gnome-flashback, gnome-session-bin, libebook-1.2-19, libedata-book-1.2-25, 
>> nautilus-share
> 
> I'm not sure what is going on there.
> 
> freeipa-client is not obviously related to this transition (or at least
> it isn't obvious to me). It comes from src:freeipa, which can't migrate
> because it depends on dogtag-pki, which is RC-buggy.

freeip comes in via the samba transition. I have hinted its removal just
now. Are all the other packages moving with gnome?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#938833: wsgicors: diff for NMU version 0.4.1-1.1

Control: tags 938833 + patch
Control: tags 938833 + pending


Dear maintainer,

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

Regards.

diff -Nru wsgicors-0.4.1/debian/changelog wsgicors-0.4.1/debian/changelog
--- wsgicors-0.4.1/debian/changelog	2015-03-25 04:15:46.0 -0400
+++ wsgicors-0.4.1/debian/changelog	2019-10-06 14:25:37.0 -0400
@@ -1,3 +1,10 @@
+wsgicors (0.4.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938833
+
+ -- Sandro Tosi   Sun, 06 Oct 2019 14:25:37 -0400
+
 wsgicors (0.4.1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru wsgicors-0.4.1/debian/control wsgicors-0.4.1/debian/control
--- wsgicors-0.4.1/debian/control	2015-03-25 04:15:46.0 -0400
+++ wsgicors-0.4.1/debian/control	2019-10-06 14:24:09.0 -0400
@@ -8,23 +8,11 @@
 Build-Depends:
   debhelper (>= 9),
   dh-python,
-  python-all,
   python3-all,
-  python-setuptools,
   python3-setuptools,
 Standards-Version: 3.9.5
 X-Python-Version: >= 2.7
 
-Package: python-wsgicors
-Architecture: all
-Depends:
-  ${python:Depends},
-  ${misc:Depends},
-Description: WSGI middleware to handle CORS preflight requests
- This is a WSGI middleware that answers CORS preflight
- requests and adds the needed header to the response. For CORS
- see: http://www.w3.org/TR/cors/.
-
 Package: python3-wsgicors
 Architecture: all
 Depends:
diff -Nru wsgicors-0.4.1/debian/python3-wsgicors.install wsgicors-0.4.1/debian/python3-wsgicors.install
--- wsgicors-0.4.1/debian/python3-wsgicors.install	2015-03-25 04:15:46.0 -0400
+++ wsgicors-0.4.1/debian/python3-wsgicors.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python3*
diff -Nru wsgicors-0.4.1/debian/python-wsgicors.docs wsgicors-0.4.1/debian/python-wsgicors.docs
--- wsgicors-0.4.1/debian/python-wsgicors.docs	2015-03-25 04:15:46.0 -0400
+++ wsgicors-0.4.1/debian/python-wsgicors.docs	1969-12-31 19:00:00.0 -0500
@@ -1,3 +0,0 @@
-README.rst
-AUTHORS.rst
-CHANGES.rst
diff -Nru wsgicors-0.4.1/debian/python-wsgicors.install wsgicors-0.4.1/debian/python-wsgicors.install
--- wsgicors-0.4.1/debian/python-wsgicors.install	2015-03-25 04:15:46.0 -0400
+++ wsgicors-0.4.1/debian/python-wsgicors.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-usr/lib/python2.*
diff -Nru wsgicors-0.4.1/debian/rules wsgicors-0.4.1/debian/rules
--- wsgicors-0.4.1/debian/rules	2015-03-25 04:15:46.0 -0400
+++ wsgicors-0.4.1/debian/rules	2019-10-06 14:24:23.0 -0400
@@ -4,6 +4,6 @@
 #export DH_VERBOSE=1
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_test:

Bug#938474: sgp4: diff for NMU version 1.4-1.1

Control: tags 938474 + patch
Control: tags 938474 + pending


Dear maintainer,

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

Regards.

diff -Nru sgp4-1.4/debian/changelog sgp4-1.4/debian/changelog
--- sgp4-1.4/debian/changelog	2016-05-27 15:04:01.0 -0400
+++ sgp4-1.4/debian/changelog	2019-10-06 14:19:56.0 -0400
@@ -1,3 +1,10 @@
+sgp4 (1.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop python2 support; Closes: #938474
+
+ -- Sandro Tosi   Sun, 06 Oct 2019 14:19:56 -0400
+
 sgp4 (1.4-1) unstable; urgency=medium
 
   * New upstream release (Closes: #844426). 
diff -Nru sgp4-1.4/debian/control sgp4-1.4/debian/control
--- sgp4-1.4/debian/control	2016-05-27 15:04:01.0 -0400
+++ sgp4-1.4/debian/control	2019-10-06 14:19:42.0 -0400
@@ -5,30 +5,10 @@
 Homepage: https://github.com/brandon-rhodes/python-sgp4
 Build-Depends: debhelper (>= 9),
  dh-python,
- python-all,
- python-setuptools,
- python-all-dev,
  python3-all,
  python3-setuptools
 Standards-Version: 3.9.8
 
-Package: python-sgp4
-Architecture: all
-Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends},
-Description: Track earth satellite TLE orbits using up-to-date 2010 version of sgp4
- This Python package computes the position and velocity of an earth-orbiting
- satellite, given the satellite’s TLE orbital elements from a source like 
- Celestrak.
- .
- It implements the most recent version of SGP4, and is regularly run against
- the SGP4 test suite to make sure that its satellite position predictions agree
- to within 0.1 mm of the predictions of the standard C++ implementation of 
- the algorithm. This error is far less than the 1-3 km/day by which satellites
- themselves deviate from the ideal orbits described in TLE files.
- .
- The C++ function names have been retained, since users may already be familiar
- with this library in other languages
-
 Package: python3-sgp4
 Architecture: all
 Depends: ${python3:Depends}, ${shlibs:Depends}, ${misc:Depends},
diff -Nru sgp4-1.4/debian/rules sgp4-1.4/debian/rules
--- sgp4-1.4/debian/rules	2016-05-27 15:04:01.0 -0400
+++ sgp4-1.4/debian/rules	2019-10-06 14:19:51.0 -0400
@@ -6,6 +6,6 @@
 export PYBUILD_NAME = sgp4
 
 %:
-	dh $@ --with python2,python3 --buildsystem=pybuild
+	dh $@ --with python3 --buildsystem=pybuild
 
 override_dh_auto_test:

Bug#941861: dgit: push to -security fails

2019-10-06 Thread Colin Watson

Package: dgit
Version: 8.5
Severity: normal

I tried to push an openssh upload to buster-security using dgit.  This
failed (well, admittedly only a damp run failed, but I assume that this
means a real attempt would have done too):

  $ dgit -L push-source
  DAMP RUN - WILL MAKE LOCAL (UNSIGNED) CHANGES
  Format `3.0 (quilt)', need to check/update patch stack
  Get:1 http://security-cdn.debian.org/debian-security buster/updates InRelease 
[39.1 kB]
  Get:2 http://security-cdn.debian.org/debian-security buster/updates/main 
Sources [75.4 kB]
  Fetched 114 kB in 1s (77.2 kB/s)
  Reading package lists... Done
  canonical suite name is buster-security
  examining quilt state (multiple patches, linear mode)
  gzip: warning: GZIP environment variable is deprecated; use an alias or script
  dgit: base trees orig=bb75b213f3789184bcb2 o+d/p=c2a57993ad9bcf9ded8e
  dgit: quilt differences: src:  ## orig ## gitignores:  == orig ==
  dgit: quilt differences:  HEAD == o+d/p   HEAD == o+d/p
  starting quiltify (multiple patches, linear mode)
  quiltify linearisation planning successful, executing...
  nothing quilty to commit, ok.
  dpkg-source: info: using source format '3.0 (quilt)'
  dpkg-source: info: building openssh using existing ./openssh_7.9p1.orig.tar.gz
  dpkg-source: info: building openssh using existing 
./openssh_7.9p1.orig.tar.gz.asc
  dpkg-source: info: using patch list from debian/patches/series
  dpkg-source: info: building openssh in openssh_7.9p1-10+deb10u1.debian.tar.xz
  dpkg-source: info: building openssh in openssh_7.9p1-10+deb10u1.dsc
  W: Unable to locate package openssh
  package seems new, not specifying -v
  dpkg-genchanges: info: not including original source code in upload
  unknown distro (debian-security)
  dgit: failed command: ssh 'd...@push.dgit.debian.org' ': dgit debian-security 
git-check openssh ; set -e; cd /dgit/debian/repos; if test -d openssh.git; then 
echo 1; else echo 0; fi'
  
  dgit: error: subprocess failed with error exit status 2
  ! Push failed, while checking state of the archive.
  ! You can retry the push, after fixing the problem, if you like.

I'm not sure whether this is currently within dgit's power to fix, but I
thought it should at least be documented in the bug list.  Thanks.

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

Kernel: Linux 4.15.0-64-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: unable to detect

Versions of packages dgit depends on:
ii  apt1.8.4
ii  ca-certificates20190110
ii  coreutils  8.30-3+b1
ii  curl   7.66.0-1
ii  devscripts 2.19.6
ii  dpkg-dev   1.19.7
ii  dput   1.0.3
ii  git [git-core] 1:2.23.0-1
ii  git-buildpackage   0.9.15
ii  libdigest-sha-perl 6.02-1+b1
ii  libdpkg-perl   1.19.7
ii  libjson-perl   4.02000-1
ii  liblist-moreutils-perl 0.416-1+b4
ii  liblocale-gettext-perl 1.07-3+b4
ii  libtext-csv-perl   2.00-1
ii  libtext-glob-perl  0.10-1
ii  libtext-iconv-perl 1.7-6
ii  libwww-curl-perl   4.17-5
ii  perl [libdigest-sha-perl]  5.28.1-6

Versions of packages dgit recommends:
ii  distro-info-data 0.42
ii  liburi-perl  1.76-1
ii  openssh-client [ssh-client]  1:8.0p1-6

Versions of packages dgit suggests:
ii  cowbuilder  0.88
ii  pbuilder0.230.4

-- no debconf information

-- 
Colin Watson   [cjwat...@debian.org]

Bug#940461: [PATCH v2] Add imap-dl, a simple imap downloader

2019-10-06 Thread Daniel Kahn Gillmor

On Sat 2019-10-05 10:21:05 -0700, Sean Whitton wrote:

> As an alternative to adding the integration tests, how about you use
> imap-dl on a daily basis for ~3 months with (I assume) a standard IMAP
> server, and if you don't have to make any nontrivial changes to the
> script during that time, we can ship it in mailscripts?

i'm using imap-dl on a daily basis now, and will happily report back
then too.  the last changes i made were supplying more debugging details
on october 2nd, so i suppose the new year is ~3 months if you want to
start the clock from my last changes :)

I'd really love to have the integration stuff working, but i don't know
when i'll get to that.

  --dkg

Bug#941856: Oops

2019-10-06 Thread Askar Safin


Oops, s/eproxy/epoxy/. And it is already packaged

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

2019-10-06 Thread Andreas Messer

I have been reading on this bug for a while now. 

On Tue, Sep 24, 2019 at 07:28:29AM +0800, Ian Campbell wrote:
> Would it be any help at all of the "dbus client-ish" bits and the
> "direct API-ish" bits of the two libraries were split up into two
> separate libraries? i.e. would that allow the c/r/p replacement of one
> of the two libraries (AIUI the API one is the more problematic) to be
> pushed further up the dependency stack?
> 
> (my impression is no, but I thought I'd ask)
> 
> > The only way I have got all of these components to work together on an 
> > elogind
> > systemd is to ensure everything uses libelogind0.
> 
> Has anyone investigated late dynamic binding using a stub library which
> merely determines which init is running and then dlopens the
> appropriate libsystemd0 of libelogind0 library and forwards the calls
> to it?
> [...]

While this would be a possible approach, this would also require that
all applications currently linking with libsystemd need to link with
something different, e.g liblogind. I think there was already some
discussion about this general logind stuff a while ago.

However, my personal feeling is, all the issues we have with packaging
and dependencies now raise from a single source, namely that libsystemd
integrates lots of - in my opinion completely - orthogonal functions
in a single binary. E.g.: 

- Managing system init and services
- Managing sessions
- Managing temporary files
- Managing devices
...

This is the reason why libelogind has been massively stubbed to become
api compatible and this is the reason why it is not possible to simply
replace a function like "session management" with another solution.

As of my thinking, the only proper solution here would be to kindly, well
forcefully insist on systemd upstream to split their library by function
and enforce them to link their own binaries properly with these libs. 
E.g.

- libsystemd -> system init and services
- libsystem-login -> sessino management
- libsystem-udev -> 
...

Andreas

signature.asc
Description: PGP signature

Bug#941860: ITP: ruby-statistics -- ruby gem for statistics inspired by the jStat js library

2019-10-06 Thread Sruthi Chandran

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

* Package name: ruby-statistics
  Version : 2.1.1
  Upstream Author : Esteban Zapata Rojas
* URL : https://github.com/estebanz01/ruby-statistics
* License : Expat
  Description : ruby gem for statistics inspired by the jStat js library
 This gem is intended to accomplish the same purpose as jStat js
library: to provide ruby with statistical capabilities without the need
of a statistical programming language like R or Octave. Some functions
and capabilities are an implementation from other authors and are
referenced properly in the class/method.









signature.asc
Description: OpenPGP digital signature

Bug#941608: RFS: python-panflute/1.11.3~git20190912.0.6df0a34-4 [ITP] -- Idiomatic Python interface for writing Pandoc filters

2019-10-06 Thread Branen Salmon

Hello, all--

I've packaged python-panflute, an Pythonic API for writing Pandoc
filters.  It's similar to python-pandocfilters, which is already
maintained by the Python Module Team, so I wanted to bring it to the
team's attention before I filed a general RFS.  (If the team decides to
adopt it, I'd still be happy to help maintain it, of course.)

The justification for adding this package is that it offers a much nicer
and more Pythonic interface than pandocfilters.  For example, here are
the respective pandocfilters and panflute expressions for a paragraph
containing a single image:

  pandocfilters: Para([Image(['', [], []], [], [url, title])])
   panflute: Para(Image(url=url, title=title))

(You can find more comparisons in upstream's examples/panflute and
examples/pandocfilters directories.)

I've uploaded my packaging to Salsa (in the gbp style) and Mentors:

  https://salsa.debian.org/branen-guest/python-panflute/tree/debian/master
  https://mentors.debian.net/package/python-panflute

The changelog still specifies the "UNRELEASED" distribution, pending
review, but I believe it otherwise complies with Debian and Python
Module Team policy.  (Upstream's "releases" are a little odd--see
README.source for details.)

This is my first time packaging for Debian, so constructive feedback is
welcome.  :)

Finally, although I'm not a DD, I've read
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
and accept it, and the ITP for the package is here:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941608

Thanks,
Branen

Bug#941803: debian-policy: dependencies on font packages

2019-10-06 Thread Guillem Jover

Hi!

On Sat, 2019-10-05 at 21:44:25 +0200, Stephen Kitt wrote:
> Package: debian-policy
> Version: 4.4.1.1
> Severity: normal

> Policy section 11.8.5, point 1 says
> 
> > If one or more of the fonts so packaged are necessary for proper
> > operation of the package with which they are associated the font
> > package may be Recommended; if the fonts merely provide an
> > enhancement, a Suggests relationship may be used. Packages must not
> > Depend on font packages.
> 
> The associated footnote explains that
> 
> > This is because the X server may retrieve fonts from the local file
> > system or over the network from an X font server; the Debian package
> > system is empowered to deal only with the local file system.
> 
> While this is still technically true,

Actually, I don't think this is true nowadays. Font server support was
disabled in libxfont 1:1.4.7-1 (in 2014-01-07).

> it seems rather irrelevant
> nowadays: most GUI programs directly render fonts obtained locally,
> and even for “traditional” X fonts, the vast majority of systems will
> obtain the fonts locally. Debian hasn’t had xfs for 5.5 years
> (); there is another font server
> available, xfstt, but that only handles TrueType fonts.

I've kept xfstt in the archive mostly for two reasons:

  - sentimental; it's the first package I adopted in Debian (at the
same time of taking over as upstream :).
  - remote usage; external non-Debian systems where their X server
still has font server support can still use these.

 But it has crossed my mind few times already, dropping it from Debian
 and probably also from upstream.

> It’s common for packages to strongly depend on non-X fonts they need;
> see for example the reverse dependencies of fonts-dejavu. While
> lintian objects to X font depencencies
> (),
> it doesn’t have anything to say about non-X fonts (rightly so).
> 
> Wouldn’t it make sense to relax the constraints on X font
> dependencies?

Looks like it to me, yes.

Thanks,
Guillem

Bug#941823: tabu: cell background colours broken

2019-10-06 Thread Hilmar Preuße


On 10/6/19 2:52 AM, Thorsten Glaser wrote:

Hi,

> Cell background colours are broken in tabu. When I change
> the MWE to use the tabular environment…
> 
>  \begin{tabular}{|l|l|l|}
> 
> … things look as expected. Building on stretch (don’t have
> texlive in buster handy) is also expected.
> 
> Large actual use case:
> https://edugit.org/mirabilos/teckidscal-standalone
> 
Is this https://github.com/tabu-issues-for-future-maintainer/tabu/issues/13

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#941857: Z3 4.8.4 contains cache bugs and should not be packaged

2019-10-06 Thread Fabian Wolff

Hi Roman,

> Dear maintainer.
> It is good to see Z3 4.8.4 finally being packaged in Debian!
> 
> As i have personally just encountered, that version contains some bugs,
> that result in incorrect modelling, which effectively renders the whole
> library unusable. Upstream developer, Nuno Lopes, notes:
>> https://github.com/AliveToolkit/alive2/issues/122
>> https://github.com/AliveToolkit/alive2/issues/123#issuecomment-538761842
>> BTW, it's important to have a recent Z3 so you can get the counterexample
>> above. I fixed a bug a while ago in Z3's model cache (I don't remember which
>> release it integrated).
> 
> I have manually rebuilt z3-4.8.6 from salsa and `sudo dpkg -i` it.
> That resolved the bugs i was observing.
> 
> I personally consider these bugs to be fatal to the package,
> as in it would be better to unpackage said package version.
> Given that 4.8.6 is ready to be packaged thanks to the work of
> Fabian Wolff, it may be good to proceed with that.

thanks for pointing this out to me.

4.8.6 is ready and uploaded, but because it introduced the new python3-z3 
package,
it's still hanging in the NEW queue, which seems to be moving quite slowly 
recently:

  https://ftp-master.debian.org/new/z3_4.8.6-1.html

Unfortunately, all I can do at this point is to wait for someone from the FTP 
team
to review and, hopefully, accept the package, but I do not know when this is 
going
to happen (the package has been in the queue for about a week now).

Best regards,
Fabian

Bug#941858: kpat high cpu usage and show log repeatedly

2019-10-06 Thread Antonio

Package: kpat
Version: 4:19.08.1-1
Severity: normal

Dear Maintainer,
after updating kpat, at startup there is a high cpu usage for about a
minute and some log info are repeatedly showed (when run the
application from konsole).

Thanks,
Antonio


--- INFO SHOWED ---

print-layout-end
moves 7
  move 0 from 2 to 0 (-1) Prio: 9
  move 1 from 2 to 0 (-1) Prio: 4
  move 0 from 9 to 0 (-1) Prio: 4
  move 0 from 8 to 5 (-1) Prio: 17
  move 0 from 7 to 0 (-1) Prio: 4
  move 0 from 3 to 2 (-1) Prio: 13
  move 0 from 6 to 8 (-1) Prio: 16
print-layout-begin
Play0:
Play1: 4C
Play2: |JD |JC |9S 4D 3C 2C AC QH
Play3: |9H |8H 3S 2S AC 3H AD 6H 5S 4H 3D 2H
Play4: |KS KC QS JS TS 9S 8S 7S 6S AH 8C 7S 6S 5S 4D 3D 2D AD 6H 5D 4H
Play5: TD 9D 8D 7D 6C 5C AH KH QS JD
Play6: KD QC JH TC 9D 8D 7D
Play7: |JS |8S |5H |KD 4S 3S 2S AS KH QC JC TS 9H 8H
Play8: KC QD JH TH 9C
Play9: |4S |TC |KS |3H TH 9C 8C 7H 6D 6C 6D 5C 4C 3C 2C AS
Deal0:
Deal1:
Deal2:
Deal3:
Deal4: |TD |2H |2D |QH |QD |5H |7C |5D |7H |7C
Off:
print-layout-end


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

Kernel: Linux 5.3.4-custom (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=it_IT, LC_CTYPE=it_IT (charmap=ISO-8859-1) (ignored:
LC_ALL set to it_IT), LANGUAGE=it (charmap=ISO-8859-1) (ignored:
LC_ALL set to it_IT)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kpat depends on:
ii  kdegames-card-data-kf5  4:19.08.1-2
ii  kio 5.62.1-1
ii  libc6   2.29-2
ii  libfreecell-solver0 5.0.0-2+b1
ii  libkf5completion5   5.62.0-1
ii  libkf5configcore5   5.62.0-1
ii  libkf5configgui55.62.0-1
ii  libkf5configwidgets55.62.0-1
ii  libkf5coreaddons5   5.62.0-1
ii  libkf5crash55.62.0-1
ii  libkf5dbusaddons5   5.62.0-1
ii  libkf5guiaddons55.62.0-1
ii  libkf5i18n5 5.62.0-1
ii  libkf5kdegames7 4:19.08.1-1
ii  libkf5kiocore5  5.62.1-1
ii  libkf5newstuff5 5.62.0-1
ii  libkf5widgetsaddons55.62.0-1
ii  libkf5xmlgui5   5.62.0-1
ii  libqt5core5a5.11.3+dfsg1-4
ii  libqt5gui5  5.11.3+dfsg1-4
ii  libqt5svg5  5.11.3-3
ii  libqt5widgets5  5.11.3+dfsg1-4
ii  libqt5xml5  5.11.3+dfsg1-4
ii  libstdc++6  9.2.1-8

Bug#941859: zfs-dkms: Apt upgrade procedure does not trigger 'update-initramfs'

2019-10-06 Thread John Daktylidis

Package: zfs-dkms
Version: 0.8.2-2~bpo10+1
Severity: normal

Dear Maintainer,

during the upgrade procedure to install the new '0.8.2-2' version from 
stable-bpo I had to manually trigger 'update-initramfs' after the installation 
in order to update the zfs version.
(or at least the version reported by /sys/module/zfs/version)
Note that I use zfs on root.

It would make sense to add a DpkgTrigger to call 'update-initramfs' 
automatically during the update procedure.



-- 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/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=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 zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  dkms   2.6.1-4
ii  file   1:5.35-4
ii  libc6-dev [libc-dev]   2.28-10
ii  libpython3-stdlib  3.7.3-1
ii  lsb-release10.2019051400
ii  perl   5.28.1-6
ii  python3-distutils  3.7.3-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  4.19.67-2+deb10u1
ii  zfs-zed 0.8.2-2~bpo10+1
ii  zfsutils-linux  0.8.2-2~bpo10+1

zfs-dkms suggests no packages.

-- debconf information:
  zfs-dkms/stop-build-for-32bit-kernel: true
  zfs-dkms/stop-build-for-unknown-kernel: true
* zfs-dkms/note-incompatible-licenses:

Bug#938425: 938425

2019-10-06 Thread JCF Ploemen

Control: block 938425 by 941489 941490 941491 941722

The development version of sabnzbdplus that switches the application to
python3 adds a number of new dependencies (python-gntp, -portend,
-tempora, and -jaraco.functools). The related ITP bugs are marked as
blocking a fix for this bug.

The packaging for all of the above is complete and awaiting sponsorship.
If you want to help move things forward, check out the debian python
modules team git repository on salsa or visit #debian-python on irc
(oftc).


pgpWjWqsHhish.pgp
Description: OpenPGP digital signature

Bug#941857: Z3 4.8.4 contains cache bugs and should not be packaged

2019-10-06 Thread Roman Lebedev

Package: z3
Version: 4.8.4-1
Severity: serious
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer.
It is good to see Z3 4.8.4 finally being packaged in Debian!

As i have personally just encountered, that version contains some bugs,
that result in incorrect modelling, which effectively renders the whole
library unusable. Upstream developer, Nuno Lopes, notes:
> https://github.com/AliveToolkit/alive2/issues/122
> https://github.com/AliveToolkit/alive2/issues/123#issuecomment-538761842
> BTW, it's important to have a recent Z3 so you can get the counterexample
> above. I fixed a bug a while ago in Z3's model cache (I don't remember which
> release it integrated).

I have manually rebuilt z3-4.8.6 from salsa and `sudo dpkg -i` it.
That resolved the bugs i was observing.

I personally consider these bugs to be fatal to the package,
as in it would be better to unpackage said package version.
Given that 4.8.6 is ready to be packaged thanks to the work of
Fabian Wolff, it may be good to proceed with that.

Roman.

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

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

Versions of packages z3 depends on:
ii  libc6   2.29-2
ii  libgcc1 1:9.2.1-8
ii  libstdc++6  9.2.1-8

z3 recommends no packages.

z3 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEjkF6151RK40WXe2HCDw+u0oWieAFAl2aIgcACgkQCDw+u0oW
ieDzoA//XwAtgmtGsnsK6siLKlGmpnDw3kMrNVwNx7HgBAyBc87q/ag0OuoZ5HdY
iEi302NPH84dAcF8xLK0XgrPAMiBYHnm5AerRzVV7hiZ9x1nbBrW9Ueo4pItBZKv
vf38PQpXdiMf7oXyn9vaarmAJXpOM/aenfjqit+8gBz1c0UobdIDNhY2/ZZ3xEG7
Ca3xFzqVvIwCJRuGiFwqr1zlP1opvEkLaTZ2N77/9bkYArAs36vJfISSyUpMztLJ
6nvFNKhROLUrEVIQzr97QojjWC57PLVpiYkGuLriDKkCi5gSLcVLzgTevh2aNKkW
dEZCoWjEFyMRi1HXqorgBZSoOKqI850rAtx58EE9MA7eiu+rHrHSuezFSGYPKI8W
RQoMBMXiTBPDZ7cKG6QvQ2J3ITscwqE6Oc0w3VYpK57eGjdQ8hWCRJagdBpEyzTv
/xfJHOisTFMwz7SH179EuavnYvS2I0IWcHuS0/pHkra0P4cweaQ4tw0qrQhbdJsu
GEh98u6/qHO0A2vIi+0/Q5b1I5h6ViwDlipv7o57q60+hSqKzanzdchg3vg/A65S
MuoJM7WoD7OkxBUThiFgHSjJCjMGGhF/XWLLseKOmM7FHQgZVhmnEDZPgqKqnDnS
kGQsa0tpt6w1IJfvFUWpnZfUNLS119ncphLrW0h7tL7K2WfICHA=
=SmuQ
-END PGP SIGNATURE-

Bug#941720: linux-headers-4.19.0-0.bpo.6-amd64 depends on linux-headers-4.19.0-0.bpo.6-common=4.19.67-2+deb10u1~bpo9+1 but only linux-headers-4.19.0-0.bpo.6-amd64=4.19.67-2~bpo9+1 is available.

2019-10-06 Thread Ben Hutchings

On Sun, 2019-10-06 at 15:35 +, Scott Kitterman wrote:
> The reason it's still there is in the cruft report:

Sorry, I didn't realise that was something I could look up.

>   - broken Build-Depends:
> user-mode-linux: linux-source-4.19
> 
> Is user-mode-linux maintained?  This seems to come up somewhat
> regularly.

It is, but not by the kernel team.  There is a long-term goal of
building UML packages directly from src:linux, but it's not a trivial
change.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that
there are so many of them.

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

Bug#941856: xdg-desktop-portal-kde: Please enable screen casting

2019-10-06 Thread Askar Safin

Package: xdg-desktop-portal-kde
Version: 5.14.5-1
Severity: normal

This package is build with SCREENCAST_ENABLED as false. Thus screencast 
functionality is currently disabled. Please,
fix this. It seems this would require packaging libeproxy for debian

-- 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/1 CPU core)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xdg-desktop-portal-kde depends on:
ii  libc6 2.29-2
ii  libkf5coreaddons5 5.62.0-1
ii  libkf5i18n5   5.62.0-1
ii  libkf5notifications5  5.62.0-1
ii  libkf5widgetsaddons5  5.62.0-1
ii  libkf5windowsystem5   5.62.0-2
ii  libqt5core5a [qtbase-abi-5-11-3]  5.11.3+dfsg1-4
ii  libqt5dbus5   5.11.3+dfsg1-4
ii  libqt5gui55.11.3+dfsg1-4
ii  libqt5printsupport5   5.11.3+dfsg1-4
ii  libqt5widgets55.11.3+dfsg1-4
ii  libstdc++69.2.1-8

xdg-desktop-portal-kde recommends no packages.

xdg-desktop-portal-kde suggests no packages.

-- no debconf information

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

2019-10-06 Thread Francois Marier

Package: dunst
Version: 1.4.1-1
Severity: normal

Once a day, at exactly the same time (+/- a couple of minutes), I get the
following errors in my logs:

  Oct  6 07:39:49 akranes dunst[28243]: CRITICAL: Cannot open X11 display.
  Oct  6 07:39:49 akranes systemd[28227]: dunst.service: Main process exited, 
code=exited, status=1/FAILURE
  Oct  6 07:39:49 akranes systemd[28227]: dunst.service: Failed with result 
'exit-code'.
  Oct  6 07:39:49 akranes systemd[28227]: Failed to start Dunst notification 
daemon.
  Oct  6 07:40:23 akranes dunst[28332]: CRITICAL: Cannot open X11 display.
  Oct  6 07:40:23 akranes systemd[28315]: dunst.service: Main process exited, 
code=exited, status=1/FAILURE
  Oct  6 07:40:23 akranes systemd[28315]: dunst.service: Failed with result 
'exit-code'.
  Oct  6 07:40:23 akranes systemd[28315]: Failed to start Dunst notification 
daemon.

Here's how I start dunst when I start my Xorg session:

  /usr/bin/systemctl status --user dunst

The service does seem to be running fine despite the errors in the logs:

$ systemctl --user status 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-04 11:05:36 PDT; 1 day 22h ago
 Docs: man:dunst(1)
 Main PID: 5046 (dunst)
   Memory: 3.9M
   CGroup: /user.slice/user-1000.slice/user@1000.service/dunst.service
   └─5046 /usr/bin/dunst

Francois

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

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

Versions of packages dunst depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-2
ii  dbus-x11 [dbus-session-bus]   1.12.16-2
ii  init-system-helpers   1.57
ii  libc6 2.29-2
ii  libcairo2 1.16.0-4
ii  libgdk-pixbuf2.0-02.38.2+dfsg-1
ii  libglib2.0-0  2.62.0-3
ii  libpango-1.0-01.42.4-7
ii  libpangocairo-1.0-0   1.42.4-7
ii  libx11-6  2:1.6.8-1
ii  libxext6  2:1.3.3-1+b2
ii  libxinerama1  2:1.1.4-2
ii  libxrandr22:1.5.1-1
ii  libxss1   1:1.2.3-1

Versions of packages dunst recommends:
ii  sensible-utils  0.0.12

dunst suggests no packages.

-- no debconf information

-- 
https://fmarier.org/

Bug#921263: Thunar ignores dark theme

2019-10-06 Thread Norman Ramsey

I'm seeing similar issues.  Using lxappearance or the lxde/xfce desktop
tool to change the theme has no affect on Thunar's appearance.  Checking
both .gtkrc-2.0 and .config/gtk-3.0/settings.ini shows that the them is set
correctly.

Bug#938034: python-plumbum: diff for NMU version 1.6.7-1.1

> thx, looks fine, so if possible feel free to reduce/remove the delay.

Thanks! I've rescheduled and it has now been ACCEPTED

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#938173: python-sigmavirus24-urltemplate: diff for NMU version 3.0.0+git20181031.68064e2-1.1