Bug#799615: RFS: netmask/2.4.2-1 [ITA] - helps determine network masks

[Guilhem Moulin]

On Tue, 29 Sep 2015 at 11:21:29 +0200, Paul Wise wrote:
> For the uscan OpenPGP support to work, upstream needs to release
> tarballs (using make distcheck), upload detached OpenPGP signatures
> and debian/watch needs to contain an pgpsigurlmangle= option. The
> github releases feature can be used to store the tarballs and detached
> OpenPGP signatures.

Yes I know, I do that on dropbear already :-)  Also in my first mail to
upstream I asked them to consider publishing detached signatures along
with the tarballs (although I didn't know it was possible to do it with
GitHub).  In the meantime I added d/upstream/signing-key.asc so the
world can check signatures on upstream's Git tags against the same key
that I use.  Signed Git tags is so much better than no signature at all
;-)

-- 
Guilhem.


signature.asc
Description: PGP signature

Re: systemd service unit causing lintian init issues

[Matt Zagrabelny]

Hi Tino,

On Tue, Sep 29, 2015 at 3:41 AM, Tino Mettler  wrote:
> On Wed, Sep 23, 2015 at 16:36:42 -0500, Matt Zagrabelny wrote:
>> Greetings,
>>
>> I'm packaging up a firewall script that ships with a systemd service
>> unit file. lintian is complaining about an init script:
>>
>> % lintian fw-skel_0.06-1_all.deb
>> W: fw-skel: init.d-script-not-marked-as-conffile etc/init.d/fw-skel
>> E: fw-skel: init.d-script-not-included-in-package etc/init.d/fw-skel
>
> Hi,
>
> I had a similar issue in the past. How does your debian/rules file look
> like? I'll try to remember what I did wrong.

I had a minimalistic rules file:

#!/usr/bin/make -f

%:
dh $@

After sending out the initial email to d-mentors, I changed it to:

#!/usr/bin/make -f

%:
dh $@ --with systemd

override_dh_installinit:
dh_installinit --noscripts

With a Build-Depends on dh-systemd. Those tweaks seemed to fix it. I
also submitted a wishlist documentation bug:

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

Thanks!

-m

RE:python-fabio circular dependency

[PICCA Frederic-Emmanuel]

> https://wiki.debian.org/PackageTransition

I know about this wiki page (very valuable), but my case is not described in 
here.


Cheers

Fred

Re: python-fabio circular dependency

[Gianfranco Costamagna]

Hi, 


Does this page help you?

https://wiki.debian.org/PackageTransition

unfortunately I don't know how to best solve this issue


cheers,

Gianfranco

Re: python-fabio circular dependency

[Jakub Wilk]

* PICCA Frederic-Emmanuel , 
2015-09-28, 20:12:
I want during the upgrade (python-fabio N)  -> python-fabio N+1 to 
install also the fabio_viewer. this way the user has the same amount of 
services on it system.

(python-fabio n contains also the scripts)

so I added a DEpends on fabio_viewer to pyton-fabio (n+1)

and now I have

fabio_viewer -> python-fabio -> fabio_viewer  and I got a bug report :)


This is #794153.


So what is the best way to solve my problem.

upgrade with same functionnality but without this circulardependency.
Indeed fabio_viewer MUST depends on python-fabio.


Demote the python-fabio -> fabio-viewer dependency to Recommends.

--
Jakub Wilk

Re: systemd service unit causing lintian init issues

[Tino Mettler]

On Tue, Sep 29, 2015 at 10:41:12 +0200, Tino Mettler wrote:
> On Wed, Sep 23, 2015 at 16:36:42 -0500, Matt Zagrabelny wrote:
> > Greetings,
> > 
> > I'm packaging up a firewall script that ships with a systemd service
> > unit file. lintian is complaining about an init script:
> > 
> > % lintian fw-skel_0.06-1_all.deb
> > W: fw-skel: init.d-script-not-marked-as-conffile etc/init.d/fw-skel
> > E: fw-skel: init.d-script-not-included-in-package etc/init.d/fw-skel
> 
> Hi,
> 
> I had a similar issue in the past. How does your debian/rules file look
> like? I'll try to remember what I did wrong.

IIRC the culprit was that I used an override for dh_installinit to
install multiple services using dh_installinit --name.

Regards,
Tino

Bug#800403: marked as done (RFS: node-util-deprecate/1.0.1-1 [ITP])

[Debian Bug Tracking System]

Your message dated Tue, 29 Sep 2015 10:52:05 + (UTC)
with message-id <1427830434.3513303.1443523925915.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#800403: RFS: node-util-deprecate/1.0.1-1 [ITP]
has caused the Debian Bug report #800403,
regarding RFS: node-util-deprecate/1.0.1-1 [ITP]
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.)


-- 
800403: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800403
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 "node-util-deprecate"

* Package name: node-util-deprecate
  Version : 1.0.1-1
  Upstream Author : Nathan Rajlich 
* URL : https://github.com/TooTallNate/util-deprecate
* License : Expat
  Section : web

It builds this binary package:

node-util-deprecate - Node.js's `util.deprecate()` function with browser
support

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

http://mentors.debian.net/package/node-util-deprecate


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

dget -x http://mentors.debian.net/debian/pool/main/n/node-util-deprecate/node-
util-deprecate_1.0.1-1.dsc

Packaging can be found in the Javascript Team repository at:
http://anonscm.debian.org/cgit/pkg-javascript/node-util-deprecate.git/

Changes since the last upload:

  * Initial release (Closes: #796365)


Regards,
Ross Gammon




-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), 
(100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-28-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
Built, thanks for your contribution to Debian!

cheers,

Gianfranco




Il Lunedì 28 Settembre 2015 22:45, Ross Gammon  ha scritto:
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "node-util-deprecate"

* Package name: node-util-deprecate
  Version : 1.0.1-1
  Upstream Author : Nathan Rajlich 
* URL : https://github.com/TooTallNate/util-deprecate
* License : Expat
  Section : web

It builds this binary package:

node-util-deprecate - Node.js's `util.deprecate()` function with browser
support

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

http://mentors.debian.net/package/node-util-deprecate


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

dget -x http://mentors.debian.net/debian/pool/main/n/node-util-deprecate/node-
util-deprecate_1.0.1-1.dsc

Packaging can be found in the Javascript Team repository at:
http://anonscm.debian.org/cgit/pkg-javascript/node-util-deprecate.git/

Changes since the last upload:

  * Initial release (Closes: #796365)


Regards,
Ross Gammon




-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), 
(100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Re: systemd service unit causing lintian init issues

[Tino Mettler]

On Wed, Sep 23, 2015 at 16:36:42 -0500, Matt Zagrabelny wrote:
> Greetings,
> 
> I'm packaging up a firewall script that ships with a systemd service
> unit file. lintian is complaining about an init script:
> 
> % lintian fw-skel_0.06-1_all.deb
> W: fw-skel: init.d-script-not-marked-as-conffile etc/init.d/fw-skel
> E: fw-skel: init.d-script-not-included-in-package etc/init.d/fw-skel

Hi,

I had a similar issue in the past. How does your debian/rules file look
like? I'll try to remember what I did wrong.

Regards,
Tino

Bug#799615: RFS: netmask/2.4.2-1 [ITA] - helps determine network masks

[Paul Wise]

On Tue, Sep 29, 2015 at 2:05 AM, Guilhem Moulin wrote:

> Moreover upstream has been super reactive on this one and has already
> released a new version with some of the fixes you suggested, which also
> allowed me to further simplify debian/rules.  I just finished the
> packaging and uploaded it to d.m.n:

Great :)

>   dget -x 
> http://mentors.debian.net/debian/pool/main/n/netmask/netmask_2.4.2-1.dsc

I assume you sent the patches upstream.

For the uscan OpenPGP support to work, upstream needs to release
tarballs (using make distcheck), upload detached OpenPGP signatures
and debian/watch needs to contain an pgpsigurlmangle= option. The
github releases feature can be used to store the tarballs and detached
OpenPGP signatures.

The upstream autogen script can be replaced with two lines:

#!/bin/sh
exec ${AUTORECONF-autoreconf} --install --symlink --force

aclocal.m4 is copied in by autotools, so it should be removed from upstream git.

$ codespell --quiet-level=3
./ChangeLog:13: agressively  ==> aggressively

$ fdupes -q -r . | grep -vE
'/(\.(git|svn|bzr|hg|sgdrawer)|_(darcs|FOSSIL_)|CVS)(/|$)' | cat -s
./tests/bounds_dq2
./tests/bounds_dq6

./tests/subset_skip
./tests/subset_clean

$ licensecheck --check=. --recursive --copyright . | grep -F incorrect
./errors.h: GPL (v2 or later) (with incorrect FSF address)
./main.c: GPL (v2 or later) (with incorrect FSF address)
./errors.c: GPL (v2 or later) (with incorrect FSF address)
./netmask.c: GPL (v2 or later) (with incorrect FSF address)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: systemd service unit causing lintian init issues

[Arturo Borrero Gonzalez]

On 23 September 2015 at 23:36, Matt Zagrabelny  wrote:
> Greetings,
>
> I'm packaging up a firewall script that ships with a systemd service
> unit file. lintian is complaining about an init script:
>

Could please point to the complete source package?

thanks.

-- 
Arturo Borrero González

How to determine when being packaged under Debian?

[Jeffrey Walton]

Hi Everyone,

I work with the Crypto++ project. Debian carries the project and makes
it available through the package
https://packages.debian.org/source/libcrypto++.

We have specific recommendations for packaging Crypto++ for
distribution (cf., http://cryptopp.com/wiki/Config.h#Recommendations).
Soon to be released Crypto 5.6.3 introduces two new defines, and we
feel distros should enable them by default. The defines are
CRYPTOPP_NO_UNALIGNED_DATA_ACCESS and CRYPTOPP_INIT_PRIORITY.

When being packaged for distribution, we want to fail the compile
unless the defines are in effect. However, we only want it to apply to
distros at this point (and not the general user community). We are not
trying to be rude; rather we are trying to ensure the library is in
the best state it can be to avoid problems on a mass scale.

(In Crypto++ 6.0, they will be in effect, and this wrinkle will go
away. But we can't make the breaking change on a patch-level revision
bump).

Is there a way I can detect when Debian is building the library for
packaging and distribution? Crypto++ does not use Autotools, so we
need to detect it in the Makefile or preprocessor.

Or, are there any other thoughts on strategy that we should consider?

Jeff

Re: "not-binnmuable-all-depends-any" problem exists for Multi-Arch: foreign, too?

[Jens Reyer]

On 09/29/2015 10:13 PM, Christoph Biedl wrote:
> Jakub Wilk wrote...
> 
>> * Christoph Biedl , 2015-09-29, 
>> 20:09:
>>> A Source package builds two "Architecture: any" packages, one "Multi-Arch:
>>> same", the other "Multi-Arch: foreign". The first has a strict versioned
>>> relationship on the second:
>>>
>>> | Package: ma_same
>>> | Architecture: any
>>> | Multi-Arch: same
>>> | Depends: ma_foreign (= ${Source-Version})
>>
>> Don't use ${Source-Version}. This variable is deprecated, because the name
>> is misleading. It is actually equivalent to ${binary:Version}.
> 
> *ouch* Of course. I always use ${binary:Version}. Sorry for the mess,
> must have picked this string from some weird place when preparing the
> message.
> 
>>> Now I remember lintian's "not-binnmuable-all-depends-any" warning where
>>> it's recommended to relax a strict dependency all->any in order to allow
>>> binNMUs ... and I think this is basically the same scenario: ma_foreign
>>> might be installed in a different architecture than ma_same, and then any
>>> binNMU will cause havoc.
>>
>> Well, MA:same packages have to be binNMUed in sync preserve their cross-arch
>> co-installability, so the dependency is not an issue in this case.
> 
> I don't follow. Assuming the following installation:
> 
> Name VersionArchitecture
> +++--==-
> ii  ma_same:amd645.25-3 amd64
> ii  ma_foreign   5.25-3 i386
> 
> Now if the package gets binNMU'd in i386, ma_foreign:i386 is available
> in version 5.25-3+b1 only. The resolver could kick ma_foreign:i386 and
> install ma_foreign:amd64 instead then, so no havoc. Appearently apt
> does this when using "apt-get dist-upgrade" - but is this desirable?

Is the ma_foreign package available on every arch (it should be if it is
a real Architecture: any package) and is amd64 your native arch? Then,
in your example, ma_foreign:amd64 should have been installed in the
first place. See the spec[1]. In this case you could use:
  Package: ma_same
  Depends: ma_foreign (= ${binary:Version})

What Jakub said (MA:same packages have to be binNMUed in sync preserve
their cross-arch co-installability) relates to bug #758616 (dpkg:
support installing M-A:same packages with different binNMU version).
This means that if ma_same is binNMUed in one arch, it should be
binNMUed in all other archs too. Otherwise they can't be co-installed
currently. So you should end up with the same (binary) version on all
archs anyway.

But first, AFAIK this binNMU-in-sync isn't done always. Further, as I
understand the bug log, there's a chance for this to be fixed for
stretch. On the other side, we might end up with something completely
else which makes special binNMU handling obsolete, see "binNMU or
reproducible builds (choose only one)"-thread at debian-devel this month.

So if you assume that different binary versions might exist for the
ma_same package and
a) if ma_foreign is not built on the same archs like ma_same, or
b) if there is a valid use case with ma_same from a non-native
architecture installed, or
c) (basically the same, but currently not possible, see above) if
multiple versions of ma-same might be installed ("same" also means
co-installable, and 2 co-installed versions imply different architectures),
then you should indeed go with:
  Depends:
ma_foreign (>= ${source:Version})
ma_foreign (<< ${source:Version}.1~)

About b) the spec only has a "should" prefer-native-arch, so this
"should" not be a hard reason. But I doubt that any automatic conflict
resolution would find the solution to install the non-native ma_foreign.

Greets
jre


[1] https://wiki.ubuntu.com/MultiarchSpec:

Multi-Arch: same
This package is co-installable and it must not be used to satisfy the
dependency of any package of another architecture than its own.
Often used for library packages.

Multi-Arch: foreign
The package is not co-installable and should be allowed to satisfy the
dependencies of a package of another architecture than its own.
*If a package is declared Multi-Arch: foreign, preference should be
given to a package for the native architecture if available;* if it is
not available, the package manager may automatically install any
available package, regardless of architecture, or it may choose to make
this an option controlled by user configuration.

Re: How to determine when being packaged under Debian?

[Russ Allbery]

Jeffrey Walton  writes:

> We have specific recommendations for packaging Crypto++ for distribution
> (cf., http://cryptopp.com/wiki/Config.h#Recommendations).  Soon to be
> released Crypto 5.6.3 introduces two new defines, and we feel distros
> should enable them by default. The defines are
> CRYPTOPP_NO_UNALIGNED_DATA_ACCESS and CRYPTOPP_INIT_PRIORITY.

> When being packaged for distribution, we want to fail the compile unless
> the defines are in effect. However, we only want it to apply to distros
> at this point (and not the general user community). We are not trying to
> be rude; rather we are trying to ensure the library is in the best state
> it can be to avoid problems on a mass scale.

> (In Crypto++ 6.0, they will be in effect, and this wrinkle will go
> away. But we can't make the breaking change on a patch-level revision
> bump).

> Is there a way I can detect when Debian is building the library for
> packaging and distribution? Crypto++ does not use Autotools, so we
> need to detect it in the Makefile or preprocessor.

We would really, really prefer that you not do this, and instead work with
whoever is packaging the library for Debian to add a test to the packaging
rules themselves to be sure that they're built correctly.

The reason for this is that Debian's packaging tools, by design, work
exactly the same way when run by an individual user to build a package for
their own personal purposes as when we use them to build packages for the
distribution.  This is in the spirit of open source: there shouldn't
really be anything special about Debian as a distribution that any
individual can also do.  But as a result, it's pretty hard to distinguish
between a Debian build and an individual build.

Also, I would question the assumption a bit: if this is important for
distributions, wouldn't it be important for all builds?

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

Re: systemd service unit causing lintian init issues

[Andrey Rahmatullin]

On Tue, Sep 29, 2015 at 03:12:18PM -0500, Matt Zagrabelny wrote:
> A quick look at the source for dh_installinit doesn't show much about
> the '-p', nor '--remaining' options. Can you elaborate or point to
> further docs?
FWIW those are common debhelper options and so found in debhelper(7).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

"not-binnmuable-all-depends-any" problem exists for Multi-Arch: foreign, too?

[Christoph Biedl]

Hello,

as there are still many surprises for me in the multiarch area, I
preferred *not* to file a wishlist against lintian. I might be wrong
with the following observation:

A Source package builds two "Architecture: any" packages, one
"Multi-Arch: same", the other "Multi-Arch: foreign". The first has a
strict versioned relationship on the second:

| Package: ma_same
| Architecture: any
| Multi-Arch: same
| Depends: ma_foreign (= ${Source-Version})
| 
| Package: ma_foreign
| Architecture: any
| Multi-Arch: foreign

Now I remember lintian's "not-binnmuable-all-depends-any" warning
where it's recommended to relax a strict dependency all->any in order
to allow binNMUs ... and I think this is basically the same scenario:
ma_foreign might be installed in a different architecture than
ma_same, and then any binNMU will cause havoc.

Question: Should I write the above dependency rather as below, just in
the way lintian suggests for mentioned warning?

| Depends: 
|   ma_foreign (>= ${Source-Version}),
|   ma_foreign (<< ${Source-Version}.1~)

Regards,

Christoph


signature.asc
Description: Digital signature

Re: "not-binnmuable-all-depends-any" problem exists for Multi-Arch: foreign, too?

[Jakub Wilk]

* Christoph Biedl , 2015-09-29, 20:09:
A Source package builds two "Architecture: any" packages, one 
"Multi-Arch: same", the other "Multi-Arch: foreign". The first has a 
strict versioned relationship on the second:


| Package: ma_same
| Architecture: any
| Multi-Arch: same
| Depends: ma_foreign (= ${Source-Version})


Don't use ${Source-Version}. This variable is deprecated, because the 
name is misleading. It is actually equivalent to ${binary:Version}.



| Package: ma_foreign
| Architecture: any
| Multi-Arch: foreign

Now I remember lintian's "not-binnmuable-all-depends-any" warning where 
it's recommended to relax a strict dependency all->any in order to 
allow binNMUs ... and I think this is basically the same scenario: 
ma_foreign might be installed in a different architecture than ma_same, 
and then any binNMU will cause havoc.


Well, MA:same packages have to be binNMUed in sync preserve their 
cross-arch co-installability, so the dependency is not an issue in this 
case.


It would be a more interesting example if the source package didn't 
build any MA:same packages. In such case, yes, ${binary:Version} 
dependency on MA:foreign package doesn't sound right.


Question: Should I write the above dependency rather as below, just in 
the way lintian suggests for mentioned warning?


| Depends:
|   ma_foreign (>= ${Source-Version}),
|   ma_foreign (<< ${Source-Version}.1~)


Here you want ${source:Version}, not ${Source-Version}. :)

--
Jakub Wilk

Re: systemd service unit causing lintian init issues

[Niels Thykier]

Niels Thykier:
> [...]
> 

Sorry, I somehow managed to confuse it with "--onlyscripts", which needs
that treatment.  Please ignore my previous mail. :)

~Niels

Re: "not-binnmuable-all-depends-any" problem exists for Multi-Arch: foreign, too?

[Christoph Biedl]

Jakub Wilk wrote...

> * Christoph Biedl , 2015-09-29, 
> 20:09:
> >A Source package builds two "Architecture: any" packages, one "Multi-Arch:
> >same", the other "Multi-Arch: foreign". The first has a strict versioned
> >relationship on the second:
> >
> >| Package: ma_same
> >| Architecture: any
> >| Multi-Arch: same
> >| Depends: ma_foreign (= ${Source-Version})
> 
> Don't use ${Source-Version}. This variable is deprecated, because the name
> is misleading. It is actually equivalent to ${binary:Version}.

*ouch* Of course. I always use ${binary:Version}. Sorry for the mess,
must have picked this string from some weird place when preparing the
message.

> >Now I remember lintian's "not-binnmuable-all-depends-any" warning where
> >it's recommended to relax a strict dependency all->any in order to allow
> >binNMUs ... and I think this is basically the same scenario: ma_foreign
> >might be installed in a different architecture than ma_same, and then any
> >binNMU will cause havoc.
> 
> Well, MA:same packages have to be binNMUed in sync preserve their cross-arch
> co-installability, so the dependency is not an issue in this case.

I don't follow. Assuming the following installation:

Name VersionArchitecture
+++--==-
ii  ma_same:amd645.25-3 amd64
ii  ma_foreign   5.25-3 i386

Now if the package gets binNMU'd in i386, ma_foreign:i386 is available
in version 5.25-3+b1 only. The resolver could kick ma_foreign:i386 and
install ma_foreign:amd64 instead then, so no havoc. Appearently apt
does this when using "apt-get dist-upgrade" - but is this desirable?

Christoph



signature.asc
Description: Digital signature

Re: systemd service unit causing lintian init issues

[Matt Zagrabelny]

Hi Niels,

On Tue, Sep 29, 2015 at 2:44 PM, Niels Thykier  wrote:
 [...]
>>
>> With a Build-Depends on dh-systemd. Those tweaks seemed to fix it. I
>> also submitted a wishlist documentation bug:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800043
>>
>> Thanks!
>>
>> -m
>>
>
> Use:
>
> override_dh_installinit:
> dh_installinit -p --noscripts
> dh_installinit --remaining

A quick look at the source for dh_installinit doesn't show much about
the '-p', nor '--remaining' options. Can you elaborate or point to
further docs?

Thanks!

-m

Re: systemd service unit causing lintian init issues

[Niels Thykier]

Matt Zagrabelny:
> Hi Tino,
> 
> On Tue, Sep 29, 2015 at 3:41 AM, Tino Mettler  wrote:
>> On Wed, Sep 23, 2015 at 16:36:42 -0500, Matt Zagrabelny wrote:
>>> Greetings,
>>>
>>> I'm packaging up a firewall script that ships with a systemd service
>>> unit file. lintian is complaining about an init script:
>>>
>>> % lintian fw-skel_0.06-1_all.deb
>>> W: fw-skel: init.d-script-not-marked-as-conffile etc/init.d/fw-skel
>>> E: fw-skel: init.d-script-not-included-in-package etc/init.d/fw-skel
>>
>> Hi,
>>
>> I had a similar issue in the past. How does your debian/rules file look
>> like? I'll try to remember what I did wrong.
> 
> I had a minimalistic rules file:
> 
> [...]
> 
> With a Build-Depends on dh-systemd. Those tweaks seemed to fix it. I
> also submitted a wishlist documentation bug:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800043
> 
> Thanks!
> 
> -m
> 

Use:

override_dh_installinit:
dh_installinit -p --noscripts
dh_installinit --remaining

Thanks,
~Niels