Re: Bug#851756: RFS: telegram-desktop/1.0.0-2

2017-01-20 Thread Andrey Rahmatullin 
On Fri, Jan 20, 2017 at 11:00:05PM +0100, Adam Borowski wrote:
> While I don't intend to sponsor it -- I don't trust Telegram and believe
> that we should instead promote messaging that's known to respect your
> privacy; 
You should start with removing other messaging clients from the archive.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#851756: RFS: telegram-desktop/1.0.0-2

2017-01-20 Thread Adam Borowski 
On Wed, Jan 18, 2017 at 04:46:46PM +0300, Коля Гурьев wrote:
>   I am looking for a sponsor for my package "telegram-desktop"
> 
>  * Package name: telegram-desktop
>Version : 1.0.0-2~rc2
>Upstream Author : John Preston 
>  * URL : https://desktop.telegram.org/

> telegram-desktop - official telegram messaging app

While I don't intend to sponsor it -- I don't trust Telegram and believe
that we should instead promote messaging that's known to respect your
privacy; also, Mattia is already handling this; but with my x32 porter hat
on, this made me curious:

>   * Made x32 build, but only inside chroot jail

I've built your package both in sbuild and on a native x32 installation, and
it succeeded in either case.  So, what's the problem you're having?


> dget -x 
> https://mentors.debian.net/debian/pool/contrib/t/telegram-desktop/telegram-desktop_1.0.0-2~rc2.dsc

The dsc and .orig don't match.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#852036: RFS: puppet-module-puppetlabs-haproxy/1.5.0-1 [ITP]

2017-01-20 Thread Gustavo Soares de Lima 
Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "puppet-module-puppetlabs-haproxy"

 * Package name: puppet-module-puppetlabs-haproxy
   Version : 1.5.0-1
   Upstream Author : Puppet Labs, Inc.
 * URL : https://github.com/puppetlabs/puppetlabs-haproxy
 * License : Apache
   Section : admin

  It builds those binary packages:

puppet-module-puppetlabs-haproxy - Module to configure and manage
HAProxy with Puppet

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

  https://mentors.debian.net/package/puppet-module-puppetlabs-haproxy


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/puppet-module-puppetlabs-haproxy/puppet-module-puppetlabs-haproxy_1.5.0-1.dsc


  Regards,
   Gustavo Soares de Lima

Bug#851884: RFS: fdkaac/0.6.3-1

2017-01-20 Thread Sean Whitton 
control: tag -1 +moreinfo

Dear Marius,

On Fri, Jan 20, 2017 at 02:02:34PM +, Marius Gavrilescu wrote:
> Sean Whitton  writes:
> 
> > One small nitpick about your changelog: you bumped the standards
> > version, but didn't indicate whether this required making any changes.
> > It's conventional to write "no changes required".  Please add this, and
> > I can upload.
> 
> I wasn't aware of that convention. I've modified the changelog, the new
> version is on mentors (and in the repo).

Seems not:

iris ~/rfs/fdkaac % git pull
Already up-to-date.
iris ~/rfs/fdkaac % git log -1
commit c7da92702d4b4c4d7b63d50f7c29654e210c38ef
Author: Marius Gavrilescu 
Date:   Thu Jan 19 18:00:43 2017 +0200

Undo addition of XS-Autobuild: yes

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Build-Depends issue between matplotlib and basemap on anything but amd64

2017-01-20 Thread Sandro Tosi 
work is already in progress, no need to prod or write stuff like
"Don't do that." is not helping anyone

On Fri, Jan 20, 2017 at 3:31 PM, Andreas Tille  wrote:
> [Sandro Tosi  in CC]
>
> On Fri, Jan 20, 2017 at 11:05:44PM +0500, Andrey Rahmatullin wrote:
>> On Fri, Jan 20, 2017 at 05:53:04PM +0100, Andreas Tille wrote:
>> > matplotlib build-depends on:
>> > - python3-mpltoolkits.basemap:arm64
>> > python3-mpltoolkits.basemap depends on:
>> > - python3-matplotlib:arm64
>> > python3-matplotlib depends on:
>> > - python-matplotlib-data:arm64 (>= 2.0.0~rc2-1)
>> > matplotlib build-depends on:
>> > - python3-mpltoolkits.basemap:arm64
>> > python3-mpltoolkits.basemap depends on:
>> > - python3-matplotlib:arm64
>> > python-matplotlib-data conflicts with:
>> > - python3-matplotlib:arm64 (< 2.0.0)
>> So it looks like matplotlib transitively B-D on itself. And because the
>> maintainer uploaded the arch:all and arch:amd64 packages directly, no
>> architectures except amd64 have the same version of arch:all and arch:!all
>> subpackages.
>> Don't do that.
>
> Can this be fixed please?
>
> Thanks
>
>   Andreas.
>
> --
> http://fam-tille.de



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

Re: Build-Depends issue between matplotlib and basemap on anything but amd64

2017-01-20 Thread Andreas Tille 
[Sandro Tosi  in CC]

On Fri, Jan 20, 2017 at 11:05:44PM +0500, Andrey Rahmatullin wrote:
> On Fri, Jan 20, 2017 at 05:53:04PM +0100, Andreas Tille wrote:
> > matplotlib build-depends on:
> > - python3-mpltoolkits.basemap:arm64
> > python3-mpltoolkits.basemap depends on:
> > - python3-matplotlib:arm64
> > python3-matplotlib depends on:
> > - python-matplotlib-data:arm64 (>= 2.0.0~rc2-1)
> > matplotlib build-depends on:
> > - python3-mpltoolkits.basemap:arm64
> > python3-mpltoolkits.basemap depends on:
> > - python3-matplotlib:arm64
> > python-matplotlib-data conflicts with:
> > - python3-matplotlib:arm64 (< 2.0.0)
> So it looks like matplotlib transitively B-D on itself. And because the
> maintainer uploaded the arch:all and arch:amd64 packages directly, no
> architectures except amd64 have the same version of arch:all and arch:!all
> subpackages.
> Don't do that.

Can this be fixed please?

Thanks

  Andreas.

-- 
http://fam-tille.de

Bug#851973: marked as done (RFS: patat/0.4.7.0-1)

2017-01-20 Thread Debian Bug Tracking System 
Your message dated Fri, 20 Jan 2017 21:00:15 +0100
with message-id <20170120200015.bxnupjsscmkkv...@angband.pl>
and subject line Re: Bug#851973: RFS: patat/0.4.7.0-1
has caused the Debian Bug report #851973,
regarding RFS: patat/0.4.7.0-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
851973: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851973
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

  patat - Terminal-based presentations using Pandoc

Package: patat
Version: 0.4.7.0-1
Upstream Author: Jasper Van der Jeugt 
Homepage: http://github.com/jaspervdj/patat
License: GPL-2
Section: haskell


Download with dget:

dget -x 
https://mentors.debian.net/debian/pool/main/p/patat/patat_0.4.7.0-1.dsc

Or build it with gbp:

gbp clone --pristine-tar https://git.gueux.org/patat.git
cd patat
gbp buildpackage

Thanks.


signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
On Fri, Jan 20, 2017 at 02:44:04PM +0100, Félix Sipma wrote:
> Package: patat
> Version: 0.4.7.0-1

✓

-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11--- End Message ---

Bug#851948: marked as done (RFS: groonga/6.1.4-1)

2017-01-20 Thread Debian Bug Tracking System 
Your message dated Fri, 20 Jan 2017 20:46:42 +0100
with message-id <20170120194642.34dxf4pdcxylq...@angband.pl>
and subject line Re: Bug#851948: RFS: groonga/6.1.4-1
has caused the Debian Bug report #851948,
regarding RFS: groonga/6.1.4-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
851948: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851948
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: groonga
  Version : 6.1.4-1
  Upstream Author : Groonga Project 
* Url : http://groonga.org/
* Licenses: LGPL-2.1
  Section : database

It builds those binary packages:

  * groonga
  * groonga-server-common
  * groonga-server-gqtp
  * libgroonga-dev
  * libgroonga0
  * groonga-tokenizer-mecab
  * groonga-token-filter-stem
  * groonga-plugin-suggest
  * groonga-bin
  * groonga-httpd
  * groonga-doc
  * groonga-examples
  * groonga-munin-plugins

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

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

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/g/groonga/groonga_6.1.4-1.dsc


More information about groonga can be obtained from
http://groonga.org/

Changes since last upload:

  * New upstream release.
  * debian/patches/fix-a-bug-that-AND-optimization-may-skip-matched-rec.patch
debian/patches/really-fix-a-bug-that-AND-optimization-may-skip-matc.patch
- Apply patches to fix an index search bug that index search may
  not return records that should be matched.


pgp0IoUVgHGyp.pgp
Description: PGP signature
--- End Message ---
--- Begin Message ---
On Fri, Jan 20, 2017 at 06:56:09PM +0900, Kentaro Hayashi wrote:
> * Package name: groonga
>   Version : 6.1.4-1

> Changes since last upload:
> 
>   * New upstream release.
>   * debian/patches/fix-a-bug-that-AND-optimization-may-skip-matched-rec.patch
> debian/patches/really-fix-a-bug-that-AND-optimization-may-skip-matc.patch
> - Apply patches to fix an index search bug that index search may
>   not return records that should be matched.

✓

-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11--- End Message ---

Re: Build-Depends issue between matplotlib and basemap on anything but amd64

2017-01-20 Thread Andrey Rahmatullin 
On Fri, Jan 20, 2017 at 05:53:04PM +0100, Andreas Tille wrote:
> matplotlib build-depends on:
> - python3-mpltoolkits.basemap:arm64
> python3-mpltoolkits.basemap depends on:
> - python3-matplotlib:arm64
> python3-matplotlib depends on:
> - python-matplotlib-data:arm64 (>= 2.0.0~rc2-1)
> matplotlib build-depends on:
> - python3-mpltoolkits.basemap:arm64
> python3-mpltoolkits.basemap depends on:
> - python3-matplotlib:arm64
> python-matplotlib-data conflicts with:
> - python3-matplotlib:arm64 (< 2.0.0)
So it looks like matplotlib transitively B-D on itself. And because the
maintainer uploaded the arch:all and arch:amd64 packages directly, no
architectures except amd64 have the same version of arch:all and arch:!all
subpackages.
Don't do that.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Build-Depends issue between matplotlib and basemap on anything but amd64

2017-01-20 Thread Andreas Tille 
Hi,

I intend to update python-biopython but got BD-Uninstallable in the
build logs[1] for anything but amd64:

python-biopython build-depends on:
- python3-matplotlib:arm64
python3-matplotlib depends on:
- python-matplotlib-data:arm64 (>= 2.0.0~rc2-1)
python-biopython build-depends on:
- python3-matplotlib:arm64
python-matplotlib-data conflicts with:
- python3-matplotlib:arm64 (< 2.0.0)

Looking at matplotlib logs[2] it looks like:

matplotlib build-depends on:
- python3-mpltoolkits.basemap:arm64
python3-mpltoolkits.basemap depends on:
- python3-matplotlib:arm64
python3-matplotlib depends on:
- python-matplotlib-data:arm64 (>= 2.0.0~rc2-1)
matplotlib build-depends on:
- python3-mpltoolkits.basemap:arm64
python3-mpltoolkits.basemap depends on:
- python3-matplotlib:arm64
python-matplotlib-data conflicts with:
- python3-matplotlib:arm64 (< 2.0.0)


Since basemap seems fine I'm a bit confused what's wrong here and
how to fix this.

Kind regards

 Andreas.


[1] https://buildd.debian.org/status/package.php?p=python-biopython
[2] https://buildd.debian.org/status/package.php?p=matplotlib

-- 
http://fam-tille.de

Bug#851996: RFS: puppet-module-puppetlabs-java/1.6.0-1 [ITP]

2017-01-20 Thread Gustavo Soares de Lima 
Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "puppet-module-puppetlabs-java"

 * Package name: puppet-module-puppetlabs-java
   Version : 1.6.0-1
   Upstream Author : Jeff McCune 
 * URL : https://github.com/puppetlabs/puppetlabs-java
 * License : apache
   Section : admin

  It builds those binary packages:

puppet-module-puppetlabs-java - Puppet module for install the
correct Java package

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

  https://mentors.debian.net/package/puppet-module-puppetlabs-java


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

dget -x 
https://mentors.debian.net/debian/pool/main/p/puppet-module-puppetlabs-java/puppet-module-puppetlabs-java_1.6.0-1.dsc




  Regards,
   Gustavo Soares de Lima

Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors

2017-01-20 Thread Etienne Dysli-Metref 
On 20/01/17 12:31, Ferenc Wágner wrote:
> https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html says:
> 
> The postrm script is called after the package's files have been
> removed or replaced. The package whose postrm is being called may
> have previously been deconfigured and only be "Unpacked", at which
> point subsequent package changes do not consider its dependencies.
> Therefore, all postrm actions may only rely on essential packages
> and must gracefully skip any actions that require the package's
> dependencies if those dependencies are unavailable.
> 
> This is exactly what happens.  Shibboleth-sp2-utils is removed, then
> init-system-helpers is removed, then shibboleth-sp2-utils is purged, but
> it can't use init-system-helpers to fully clean up after itself.

Ah I see! thanks for the reference :)
Since init-system-helpers is not marked as essential in jessie and is
installed as a dependency during the piuparts test, it gets removed.

> But we'd still need the functionality of dh-systemd in our backport.
> I'll look through #822670 and #837585 for hints.

Just keeping dh-systemd (without version, like I added in commit
518aa2b) in the build dependencies is enough I think. piuparts with
--warn-on-leftovers-after-purge does not report other problems. Will
this piuparts error block the package from getting into jessie-backports?

  Etienne



signature.asc
Description: OpenPGP digital signature

Bug#851884: RFS: fdkaac/0.6.3-1

2017-01-20 Thread Marius Gavrilescu 
Sean Whitton  writes:

> One small nitpick about your changelog: you bumped the standards
> version, but didn't indicate whether this required making any changes.
> It's conventional to write "no changes required".  Please add this, and
> I can upload.

I wasn't aware of that convention. I've modified the changelog, the new
version is on mentors (and in the repo).

Thank you,
-- 
Marius Gavrilescu


signature.asc
Description: PGP signature

Bug#851973: RFS: patat/0.4.7.0-1

2017-01-20 Thread Félix Sipma 
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

  patat - Terminal-based presentations using Pandoc

Package: patat
Version: 0.4.7.0-1
Upstream Author: Jasper Van der Jeugt 
Homepage: http://github.com/jaspervdj/patat
License: GPL-2
Section: haskell


Download with dget:

dget -x 
https://mentors.debian.net/debian/pool/main/p/patat/patat_0.4.7.0-1.dsc

Or build it with gbp:

gbp clone --pristine-tar https://git.gueux.org/patat.git
cd patat
gbp buildpackage

Thanks.


signature.asc
Description: PGP signature

Bug#851884: RFS: fdkaac/0.6.3-1

2017-01-20 Thread Sean Whitton 
control: tag -1 +moreinfo
control: owner -1 !

On Thu, Jan 19, 2017 at 04:50:33PM +, Marius Gavrilescu wrote:
> My Vcs-Git ( https://git.ieval.ro/git/fdkaac.git ) already has the new
> version.

Thanks for updating your repo!

One small nitpick about your changelog: you bumped the standards
version, but didn't indicate whether this required making any changes.
It's conventional to write "no changes required".  Please add this, and
I can upload.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors

2017-01-20 Thread Ferenc Wágner 
Etienne Dysli-Metref  writes:

> On 19/01/17 23:46, Ferenc Wágner wrote:
>
>> I couldn't reproduce this on a real jessie system, only in a piuparts
>> chroot.  I think the reason is that piuparts removes init-system-helpers
>> (the home of deb-systemd-helper) before the shibboleth-sp2-utils postrm
>> could instruct it to clean up.  I'm not sure what we could do about
>> this.
>
> Indeed piuparts does remove init-system-helpers before
> shibboleth-sp2-utils. I hadn't noticed before but it's in the log:
> [...]
> Why would puiparts do it in this order? shibboleth-sp2-utils depends on
> init-system-helpers!

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html says:

The postrm script is called after the package's files have been
removed or replaced. The package whose postrm is being called may
have previously been deconfigured and only be "Unpacked", at which
point subsequent package changes do not consider its dependencies.
Therefore, all postrm actions may only rely on essential packages
and must gracefully skip any actions that require the package's
dependencies if those dependencies are unavailable.

This is exactly what happens.  Shibboleth-sp2-utils is removed, then
init-system-helpers is removed, then shibboleth-sp2-utils is purged, but
it can't use init-system-helpers to fully clean up after itself.

>>> So I bumped the build-dep up a bit to: dh-systemd (>= 9.20160709).
>> 
>> Why?  I mean, where did this version number come from?
>
> The version comes from debhelper's changelog in jessie-backports [1].
> It's when dh-systemd was moved to debhelper.

Got it, thanks.

> Since adding this version constraint was motivated by piuparts's report,
> it may not be necessary in the end...

But we'd still need the functionality of dh-systemd in our backport.
I'll look through #822670 and #837585 for hints.
-- 
Regards,
Feri

Bug#851948: RFS: groonga/6.1.4-1

2017-01-20 Thread Kentaro Hayashi 
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name: groonga
  Version : 6.1.4-1
  Upstream Author : Groonga Project 
* Url : http://groonga.org/
* Licenses: LGPL-2.1
  Section : database

It builds those binary packages:

  * groonga
  * groonga-server-common
  * groonga-server-gqtp
  * libgroonga-dev
  * libgroonga0
  * groonga-tokenizer-mecab
  * groonga-token-filter-stem
  * groonga-plugin-suggest
  * groonga-bin
  * groonga-httpd
  * groonga-doc
  * groonga-examples
  * groonga-munin-plugins

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

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

Alternatively, one can download the package with dget using this command:
dget -x 
https://mentors.debian.net/debian/pool/main/g/groonga/groonga_6.1.4-1.dsc


More information about groonga can be obtained from
http://groonga.org/

Changes since last upload:

  * New upstream release.
  * debian/patches/fix-a-bug-that-AND-optimization-may-skip-matched-rec.patch
debian/patches/really-fix-a-bug-that-AND-optimization-may-skip-matc.patch
- Apply patches to fix an index search bug that index search may
  not return records that should be matched.


pgpgA0VF2WvII.pgp
Description: PGP signature

Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors

2017-01-20 Thread Etienne Dysli-Metref 
On 19/01/17 23:46, Ferenc Wágner wrote:
> I couldn't reproduce this on a real jessie system, only in a piuparts
> chroot.  I think the reason is that piuparts removes init-system-helpers
> (the home of deb-systemd-helper) before the shibboleth-sp2-utils postrm
> could instruct it to clean up.  I'm not sure what we could do about
> this.

Indeed piuparts does remove init-system-helpers before
shibboleth-sp2-utils. I hadn't noticed before but it's in the log:

> 0m33.9s DEBUG: Command ok: ['chroot', '/tmp/tmpH_vjLg', 'dpkg', '--purge', 
> 'libxerces-c3.1:amd64', 'libcurl4-openssl-dev:amd64', 'libshibsp-dev:amd64', 
> 'librtmp1:amd64', 'libgssapi-krb5-2:amd64', 'libssh2-1:amd64', 
> 'libxml-security-c17:amd64', 'libaprutil1:amd64', 'libk5crypto3:amd64', 
> 'libfcgi0ldbl', 'libxml-security-c-dev:amd64', 'libkeyutils1:amd64', 
> 'zlib1g-dev:amd64', 'libshibsp-plugins:amd64', 'init-system-helpers', 
> 'libaprutil1-dbd-sqlite3:amd64', 'libapr1:amd64', 'libicu-dev:amd64', 
> 'libldap-2.4-2:amd64', 'liblog4shib1:amd64', 'libxmltooling-dev:amd64', 
> 'libssl1.0.0:amd64', 'libnettle4:amd64', 'icu-devtools', 'liblua5.1-0:amd64', 
> 'libssl-dev:amd64', 'libtasn1-6:amd64', 'libxmltooling7:amd64', 
> 'libkrb5-3:amd64', 'libsasl2-modules-db:amd64', 'libexpat1:amd64', 
> 'libltdl7:amd64', 'libsaml9:amd64', 'libaprutil1-ldap:amd64', 
> 'libodbc1:amd64', 'libicu52:amd64', 'libxml2:amd64', 'libidn11:amd64', 
> 'apache2-bin', 'libsaml2-dev:amd64', 'liblog4shib-dev', 'libshibsp7:amd64', 
> 'libmemcached11:amd64', 'libffi6:amd64', 'libgnutls-deb0-28:amd64', 
> 'libcurl3:amd64', 'libkrb5support0:amd64', 'opensaml2-schemas', 
> 'libsasl2-2:amd64', 'libxerces-c-dev', 'xmltooling-schemas', 
> 'libhogweed2:amd64', 'libp11-kit0:amd64']
> 0m33.9s DEBUG: Starting command: ['chroot', '/tmp/tmpH_vjLg', 'dpkg', 
> '--purge', 'libshibsp-doc', 'shibboleth-sp2-common', 'shibboleth-sp2-utils', 
> 'libapache2-mod-shib2']

Why would puiparts do it in this order? shibboleth-sp2-utils depends on
init-system-helpers!

>> So I bumped the build-dep up a bit to: dh-systemd (>= 9.20160709).
> 
> Why?  I mean, where did this version number come from?

The version comes from debhelper's changelog in jessie-backports [1].
It's when dh-systemd was moved to debhelper.

Since adding this version constraint was motivated by piuparts's report,
it may not be necessary in the end...

  Etienne

[1]
http://metadata.ftp-master.debian.org/changelogs/main/d/debhelper/debhelper_10.2.2~bpo8+1_changelog




signature.asc
Description: OpenPGP digital signature