Re: mpgrafic - mpirun test program as root in automatic build

[Paul Wise]

On Wed, Jan 18, 2017 at 3:37 PM, Boud Roukema wrote:

> I guess by "both of these" you mean "most of the build steps (apart from
> the 'debian/rules install' step)"?

What I wrote wasn't clear and wasn't strictly true, sorry!

When manually building from source:

You always build/test as a normal user.
You install as either root or normal user, depending on the install prefix.

When doing Debian package builds:

You always build/test as a normal user.
You always install using fakeroot.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: mpgrafic - mpirun test program as root in automatic build

[Boud Roukema]

On Wed, 18 Jan 2017, Paul Wise wrote:


On Wed, Jan 18, 2017 at 5:13 AM, Boud Roukema wrote:


I've looked a bit at buildd.debian.org, but it's not completely
trivial to decide which is correct - do the buildd builds on the
debian build machines run dh_auto_tests as (i) root, as (ii) an unprivileged
user running fakeroot, or as (iii) an unprivileged user?


(iii) an unprivileged user

fakeroot is only used at `debian/rules install` time.

Both of these are the same as if you were building manually from source.


I guess by "both of these" you mean "most of the build steps (apart from
the 'debian/rules install' step)"?

cheers
boud

Re: mpgrafic - mpirun test program as root in automatic build

[Paul Wise]

On Wed, Jan 18, 2017 at 5:13 AM, Boud Roukema wrote:

> I've looked a bit at buildd.debian.org, but it's not completely
> trivial to decide which is correct - do the buildd builds on the
> debian build machines run dh_auto_tests as (i) root, as (ii) an unprivileged
> user running fakeroot, or as (iii) an unprivileged user?

(iii) an unprivileged user

fakeroot is only used at `debian/rules install` time.

Both of these are the same as if you were building manually from source.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#851696: RFS: python-qtpy/1.2.0-1

[Ghislain Vaillant]

Hi Fred,

On Tue, 2017-01-17 at 19:30 +, PICCA Frederic-Emmanuel wrote:
> Hello Ghislain.
> 
> do you know if this version is compatible with the reverse dependencies 
> already in Debian ?

First of, the upstream changelog did not mention any API breakage, only
fixes and new features (support for qtmultimedia).

> python-qtpy
> Reverse Depends:
>   python-spyder
>   python-ginga
>   python-qtawesome
>   python-glue

Both qtpy 1.1.2 and qtpy 1.2.0 works with spyder 3.0.2 (tested in a
venv). Since qtpy was designed for spyder, it is probably the best
possible test we have in hand.

> We are close from the freeze and I do not want to end up with a bunch of 
> autorm packages due to this kind of upload.

I know, and there is still roughly a week to go. Since I use the
packaged spyder, pyzo and git-cola quite extensively, I should be able
to catch potential breakage quite quickly.

> BUT if you can show that there is no problem I am ok to sponsorize this 
> package.

Your call.

Ghis

Bug#851696: RFS: python-qtpy/1.2.0-1

[Ghislain Vaillant]

Hi Fred,

On Tue, 2017-01-17 at 19:30 +, PICCA Frederic-Emmanuel wrote:
> Hello Ghislain.
> 
> do you know if this version is compatible with the reverse dependencies 
> already in Debian ?

First of, the upstream changelog did not mention any breakage, only
fixes and new features (support for qtmultimedia). Upstream has had a
good track record at keeping these in check so far.

> python-qtpy
> Reverse Depends:
>   python-spyder
>   python-ginga
>   python-qtawesome
>   python-glue

Both qtpy 1.1.2 and qtpy 1.2.0 works with spyder 3.0.2 (tested in a
venv). Since qtpy was designed for spyder in the first place, it is
probably the best
possible test we have in hand.

In addition, I have checked pyzo and git-cola. Both works fine with
qtpy 1.1.2 and 1.2.0.

> We are close from the freeze and I do not want to end up with a bunch of 
> autorm packages due to this kind of upload.

Based on my initial testing, I am confident this is safe. I'd still
have a week to fix things if disaster strikes, but I'd be really
suprised.

> BUT if you can show that there is no problem I am ok to sponsorize this 
> package.

Your call.

Ghis

Re: mpgrafic - mpirun test program as root in automatic build

[Boud Roukema]

On Tue, 17 Jan 2017, James Cowgill wrote:


I'm not sure I follow. Debhelper runs the testsuite during the build
target so it shouldn't be run as root anyway. I don't think you need any
workarounds at all for this.


I agree in terms of principles :), but I don't know what actually happens
on the buildd machines.

I've looked a bit at buildd.debian.org, but it's not completely
trivial to decide which is correct - do the buildd builds on the
debian build machines run dh_auto_tests as (i) root, as (ii) an unprivileged
user running fakeroot, or as (iii) an unprivileged user?

Looking at git://git.debian.org/buildd-tools/sbuild.git it looks like
the user is "buildd" - but this is just a guess.

The mpirun exit-if-root mechanism is in

openmpi-2.0.2~git.20161225/orte/orted/orted_submit.c

Isolating this to lines 319-335, this is easy to test as a standalone
main program (see snippet.c below) - the exit-if-root test is triggered either 
(i) using
root directly, or (ii) as ordinary user running fakeroot.

Even as fakeroot, both geteuid() and getuid() in the snippet below
report an identity of 0.

My own pbuilder setup - closely following the maint-guide.en.txt advice -
appears *not* to run "make check" as fakeroot or root, since I
do not see the error and exit due to running as root.

The snippet below can be tested:

user$ ./snippet
user$ fakeroot ./snippet
root# ./snippet

Cheers
Boud

--

/* inspired by openmpi-2.0.2~git.20161225/orte/orted/orted_submit.c root 
detection */

/* (C) 2017 GPL-3+ B. Roukema if copyright is needed */

#include 
#include 
#include 

int main(void)
{
  int uid = 77 , euid = ;
  euid = geteuid();
  uid = getuid();
  if (0 == euid){
printf("WARNING: You are effectively root.\n");
  };
  if (0 == uid){
printf("WARNING: You are really root.\n");
  };
  if (0 != uid && 0 != euid){
printf("You are not running as root :).\n");
  }
  return 0;
}

--

Re: mpgrafic - mpirun test program as root in automatic build

[Ole Streicher]

James Cowgill  writes:
> On 16/01/17 23:58, Boud Roukema wrote:
>> Since, in general, there is no reason for mpirun to run as root,
>> the sid version of mpirun (from openmpi) apparently refuses to run as root.
>> (I have not reproduced this behaviour myself - Ole Streicher
>> has warned me about it.) The openmpi developers provide an option
>> --allow-run-as-root.
>
> I'm not sure I follow. Debhelper runs the testsuite during the build
> target so it shouldn't be run as root anyway. I don't think you need any
> workarounds at all for this.

I (as Bouds sponsor) have the problem that in my cowbuilder the build is
done as root, leading to the questioned error message and a failure of
the test and the build. Maybe in my setup something is wrong?

Best regards

Ole

Bug#851696: RFS: python-qtpy/1.2.0-1

[PICCA Frederic-Emmanuel]

Hello Ghislain.

do you know if this version is compatible with the reverse dependencies already 
in Debian ?

python-qtpy
Reverse Depends:
  python-spyder
  python-ginga
  python-qtawesome
  python-glue

We are close from the freeze and I do not want to end up with a bunch of autorm 
packages due to this kind of upload.

BUT if you can show that there is no problem I am ok to sponsorize this package.

Cheers

Fred

Bug#851696: RFS: python-qtpy/1.2.0-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "python-qtpy"

* Package name: python-qtpy
  Version : 1.2.0-1
  Upstream Author : The Spyder Development Team
* URL : https://github.com/spyder-ide/qtpy
* License : Expat
  Section : python

It builds those binary packages:

  python-qtpy - abtraction layer for PySide/PyQt4/PyQt5 (Python 2)
  python3-qtpy - abtraction layer for PySide/PyQt4/PyQt5 (Python 3)

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

   https://mentors.debian.net/package/python-qtpy

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-qtpy/python-qtpy_1.2.0-1.dsc

Successful build on debomatic:

  
http://debomatic-amd64.debian.net/distribution#unstable/python-qtpy/1.2.0-1/buildlog

Changes since the last upload:

   * Switch to git-dpm
   * New upstream release
   * Bump minimum Python versions (2.7, 3.3)
   * Add new dependency on pyqt5.qtmultimedia
   * Simplify setup for tests in pybuild
   * Drop superfluous Testsuite field
   * Upgrade packaging to debhelper 10
   * Support the nocheck build profile
 - Add versioned dependency on dpkg-dev
 - Mark test dependencies as !nocheck
 - Disable tests if nocheck requested
   * Fix whitespaces in rules file

Regards,
Ghislain Vaillant

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

[Niels Thykier]

Etienne Dysli-Metref:
> Hello mentors,
> 
> Since shibboleth-sp2 2.6.0+dfsg1-4 migrated to testing during the
> holidays, I'm now backporting it to jessie. So far there is nothing to
> change, however piuparts gives me the following error (which does not
> appear on stretch):
> 
>> [...]
> 
> So I bumped the build-dep up a bit to: dh-systemd (>= 9.20160709). But
> then a get a lintian error
> 
>> E: libshibsp7: postinst-must-call-ldconfig 
>> usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0
> 
> [...]
> 
> So hmm... any clues? Who's wrong? me, piuparts, lintian or debhelper?
> 
> [...]
> 
>   Etienne
> 

This lintian error:

 * is aimed at stretch or later, and
 * should be ignored for stable and stable-backports

Thanks,
~Niels

Re: mpgrafic - mpirun test program as root in automatic build

[James Cowgill]

Hi,

On 16/01/17 23:58, Boud Roukema wrote:
> hi Debian-mentors,
> 
> Is it reasonable to override the mpirun (openmpi_2.0.2~git.20161225-8)
> default preference of refusing to run as root?
> 
> I've started packaging mpgrafic for debian - this is my first
> debianisation, apart from minor private hacks after extracting debian
> source packages:
> 
> https://anonscm.debian.org/cgit/debian-astro/packages/mpgrafic.git/
> 
> I've added regression-test-0.3.7.sh to the upstream version of
> mpgrafic. This is a "reproducible run" test. The test runs the main
> binary, mpgrafic, with a frontend "mpirun", which, in general, allows
> a program to run on many different machines, without shared memory.
> This test runs explicitly on exactly one processor, for reproducibility.
> 
> Since, in general, there is no reason for mpirun to run as root,
> the sid version of mpirun (from openmpi) apparently refuses to run as root.
> (I have not reproduced this behaviour myself - Ole Streicher
> has warned me about it.) The openmpi developers provide an option
> --allow-run-as-root.
> 
> In version 0.3.7.4-1, the debian-only, openmpi-only use of this option in
> debian/rules + regression-test-0.3.7.sh
> 
> https://anonscm.debian.org/cgit/debian-astro/packages/mpgrafic.git/tree/debian/rules
> 
> https://anonscm.debian.org/cgit/debian-astro/packages/mpgrafic.git/tree/regression-test-0.3.7.sh
> 
> 
> should presumably allow debian automatic builds to pass "make check".

I'm not sure I follow. Debhelper runs the testsuite during the build
target so it shouldn't be run as root anyway. I don't think you need any
workarounds at all for this.

James



signature.asc
Description: OpenPGP digital signature

Re: Looking for sponsoring/menthoring : openmeca package [ITP: #850590]

[Ghislain Vaillant]

On Tue, 2017-01-17 at 11:06 +0100, dada wrote:
> Le 2017-01-17 10:41, Mattia Rizzolo a écrit :
> > On Tue, Jan 17, 2017 at 10:27:45AM +0100, dada wrote:
> > > ** What I have already done for packaging openmeca **
> > > 
> > >  - open an ITP (see
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850590).
> > >Andreas Tille (from debian-science) tell me that the soft fit 
> > > well with
> > > the debian-science field.
> > 
> > good.
> > 
> > >  - open a git repository for openmeca on alioth :
> > > 
> > > https://anonscm.debian.org/cgit/debian-science/packages/openmeca.git/
> > >post a first version of the openmeca package on this git 
> > > repository.
> > >This package seems to be right on my personal computer (Ubuntu 
> > > 16.04.1
> > > LTS and checked with "gbp buildpackage")
> > 
> > good.  (although you really should build it in Debian unstable, and
> > test it there too).
> > 
> > >  - post an intent on the debian science list (see
> > > https://lists.debian.org/debian-science/2017/01/msg00093.html)
> > >but I have no answer.
> > 
> > That's not an "intent" really, it's a forward of your ITP with "some"
> > added text.
> > 
> > > As I have no answer from the debian-science list (probably they have 
> > > no
> > > time), I post my request on this list.
> > 
> > 1) consider that 4 days are really little, also considering a week 
> > end
> >was in the middle
> > 2) the subject was really poor: most of use receive *a lot* of emails
> >and subjects are important; I probably skipped that email thinking 
> > it
> >was just a "FYI" of an ITP related to -science.
> > 
> > > I am not used with the Debian policy so... please tell me if I am 
> > > wrong,
> > > impatient, or something else
> > 
> > The usual procedure (especially if the team have nothing else in 
> > place)
> > is to open a RFS bug.  I invite you to read
> > https://mentors.debian.net/intro-maintainers especially from point 5
> > onward; mentors.d.n also gives you a template for the RFS bug (see 
> > point

If you seek sponsorship via the Debian Science Team, just file an RFS
and fill in an entry in the SoB page.

https://wiki.debian.org/DebianPureBlends/SoB


> > 4). (note that even if you'll have to upload a source packages to
> > mentors.d.n, several of us still prefer to review using a git
> > repository, so please include that too in the request).
> > The reason to prefer an RFS bug over emails is that they don't get 
> > lost:
> > several of us look at https://bugs.debian.org/sponsorship-requests 
> > from
> > time to time and take care of pending request, whereas emails in a
> > mailing list are much harder to keep track of.

Also, please keep in mind that we are currently focusing on getting
Stretch out in the next few months, so new packages have much lower
priority at the moment.


> Hello Matia, Thank you for your detailed and quick reply.
> I am going to : 1) wait and 2) read the intro-maintainers.
> 
> > Now, you don't have any package already in the archive, so my 
> > personal
> > policy (https://people.debian.org/~mattia/sponsoring.html) "forbids" 
> > me
> > to sponsoring the package, but I trust there are several other
> > developers willing to do so :)  I just wanted to explain better the
> > usual procedure ^^
> 
> I understand your position for sponsoring, no problem !
> Best regards, Damien.
> 

Re: Looking for sponsoring/menthoring : openmeca package [ITP: #850590]

[dada]

Le 2017-01-17 10:41, Mattia Rizzolo a écrit :

On Tue, Jan 17, 2017 at 10:27:45AM +0100, dada wrote:

** What I have already done for packaging openmeca **

 - open an ITP (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850590).
   Andreas Tille (from debian-science) tell me that the soft fit 
well with

the debian-science field.


good.


 - open a git repository for openmeca on alioth :

https://anonscm.debian.org/cgit/debian-science/packages/openmeca.git/
   post a first version of the openmeca package on this git 
repository.
   This package seems to be right on my personal computer (Ubuntu 
16.04.1

LTS and checked with "gbp buildpackage")


good.  (although you really should build it in Debian unstable, and
test it there too).


 - post an intent on the debian science list (see
https://lists.debian.org/debian-science/2017/01/msg00093.html)
   but I have no answer.


That's not an "intent" really, it's a forward of your ITP with "some"
added text.

As I have no answer from the debian-science list (probably they have 
no

time), I post my request on this list.


1) consider that 4 days are really little, also considering a week 
end

   was in the middle
2) the subject was really poor: most of use receive *a lot* of emails
   and subjects are important; I probably skipped that email thinking 
it

   was just a "FYI" of an ITP related to -science.

I am not used with the Debian policy so... please tell me if I am 
wrong,

impatient, or something else


The usual procedure (especially if the team have nothing else in 
place)

is to open a RFS bug.  I invite you to read
https://mentors.debian.net/intro-maintainers especially from point 5
onward; mentors.d.n also gives you a template for the RFS bug (see 
point

4). (note that even if you'll have to upload a source packages to
mentors.d.n, several of us still prefer to review using a git
repository, so please include that too in the request).
The reason to prefer an RFS bug over emails is that they don't get 
lost:
several of us look at https://bugs.debian.org/sponsorship-requests 
from

time to time and take care of pending request, whereas emails in a
mailing list are much harder to keep track of.






Hello Matia, Thank you for your detailed and quick reply.
I am going to : 1) wait and 2) read the intro-maintainers.

Now, you don't have any package already in the archive, so my 
personal
policy (https://people.debian.org/~mattia/sponsoring.html) "forbids" 
me

to sponsoring the package, but I trust there are several other
developers willing to do so :)  I just wanted to explain better the
usual procedure ^^


I understand your position for sponsoring, no problem !
Best regards, Damien.

Re: Looking for sponsoring/menthoring : openmeca package [ITP: #850590]

[Mattia Rizzolo]

On Tue, Jan 17, 2017 at 10:27:45AM +0100, dada wrote:
> ** What I have already done for packaging openmeca **
> 
>  - open an ITP (see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850590).
>Andreas Tille (from debian-science) tell me that the soft fit well with
> the debian-science field.

good.

>  - open a git repository for openmeca on alioth :
> https://anonscm.debian.org/cgit/debian-science/packages/openmeca.git/
>post a first version of the openmeca package on this git repository.
>This package seems to be right on my personal computer (Ubuntu 16.04.1
> LTS and checked with "gbp buildpackage")

good.  (although you really should build it in Debian unstable, and
test it there too).

>  - post an intent on the debian science list (see
> https://lists.debian.org/debian-science/2017/01/msg00093.html)
>but I have no answer.

That's not an "intent" really, it's a forward of your ITP with "some"
added text.

> As I have no answer from the debian-science list (probably they have no
> time), I post my request on this list.

1) consider that 4 days are really little, also considering a week end
   was in the middle
2) the subject was really poor: most of use receive *a lot* of emails
   and subjects are important; I probably skipped that email thinking it
   was just a "FYI" of an ITP related to -science.

> I am not used with the Debian policy so... please tell me if I am wrong,
> impatient, or something else

The usual procedure (especially if the team have nothing else in place)
is to open a RFS bug.  I invite you to read
https://mentors.debian.net/intro-maintainers especially from point 5
onward; mentors.d.n also gives you a template for the RFS bug (see point
4). (note that even if you'll have to upload a source packages to
mentors.d.n, several of us still prefer to review using a git
repository, so please include that too in the request).
The reason to prefer an RFS bug over emails is that they don't get lost:
several of us look at https://bugs.debian.org/sponsorship-requests from
time to time and take care of pending request, whereas emails in a
mailing list are much harder to keep track of.



Now, you don't have any package already in the archive, so my personal
policy (https://people.debian.org/~mattia/sponsoring.html) "forbids" me
to sponsoring the package, but I trust there are several other
developers willing to do so :)  I just wanted to explain better the
usual procedure ^^

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Looking for sponsoring/menthoring : openmeca package [ITP: #850590]

[dada]

Hello all,
My name is Damien André, I am french and I am looking for 
menthoring/sponsoring for

the openmeca software (see https://gitlab.com/damien.andre/openmeca).

Openmeca is a graphical application for building multibody dynamics 
simulations.
It may be usefull for learning and teaching mechanics, kinematics and 
dynamics.


Some screencast are available on Youtube (sorry for gg inside)
at the url : 
https://www.youtube.com/watch?v=N9Wy5MHmnJQ=PLjFD44HqZ1diZN45FSLO82NyuIgpu4Lml


I develop this soft since 8 years and I think that the program has a 
sufficient level

of quality for being included in the Debian distrib.

** Technical informations about openmeca **

 - URL : https://gitlab.com/damien.andre/openmeca
 - License : GPL v3
 - Programming Lang: C++
 - Main Dependences: Qt5


** What I have already done for packaging openmeca **

 - open an ITP (see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850590).
   Andreas Tille (from debian-science) tell me that the soft fit well 
with the debian-science field.


 - open a git repository for openmeca on alioth : 
https://anonscm.debian.org/cgit/debian-science/packages/openmeca.git/

   post a first version of the openmeca package on this git repository.
   This package seems to be right on my personal computer (Ubuntu 
16.04.1 LTS and checked with "gbp buildpackage")


 - post an intent on the debian science list (see 
https://lists.debian.org/debian-science/2017/01/msg00093.html)

   but I have no answer.

As I have no answer from the debian-science list (probably they have no 
time), I post my request on this list.
I am not used with the Debian policy so... please tell me if I am 
wrong, impatient, or something else


Please feel free to contact me for any further information.

Damien André
http://www.unilim.fr/pages_perso/damien.andre/

RE:watch file with multiple download url

[PICCA Frederic-Emmanuel]

> This has nothing to do with that you have multiple download URLs.

> You are simply missing to replace - with ~ to sort RCs before final versions.

> uversionmangle=s/-rc/~rc/


I will do this change and see if with two URL, uscan upload only one .tar.gz.
I do not want to download two times the same pacakge from the two URL.

thansk

Fred

Re: git-p4 package?

[Luke Diamand]

[+Gerrit Pape's correct email address]

On 17 January 2017 at 00:17, Sean Whitton  wrote:
> Dear Luke,
>
> On Mon, Jan 16, 2017 at 11:27:22PM +, Luke Diamand wrote:
>> I put in a patch to add a git-p4 package, here:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773245
>>
>> I was wondering what I need to do next for this to be merged? Or if
>> I've done it wrong somehow?
>
> I haven't looked at the patch, but you haven't done anything wrong with
> regard to Debian procedures.  It's simply a matter of waiting for a
> response from the maintainers of the git package.
>
> You could prepare an NMU of the git package and submit a request for
> sponsorship to DEFERRED, but that would be unusual for a bug of wishlist
> severity.  Please read up on NMUs in the Debian Developer's Reference,
> so that you are properly informed of your options.


Thanks - an NMU seems to be a bit drastic!

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

[Etienne Dysli-Metref]

Hello mentors,

Since shibboleth-sp2 2.6.0+dfsg1-4 migrated to testing during the
holidays, I'm now backporting it to jessie. So far there is nothing to
change, however piuparts gives me the following error (which does not
appear on stretch):

> 0m34.6s ERROR: FAIL: Package purging left files on system:
>   /etc/systemd/system/multi-user.target.wants/shibd.service -> 
> /lib/systemd/system/shibd.service   not owned
>   /etc/systemd/system/shibd.service -> /dev/null   not owned
>   /var/lib/systemd/deb-systemd-helper-enabled/ not owned
>   /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/
>  not owned
>   
> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/shibd.service
> not owned
>   /var/lib/systemd/deb-systemd-helper-enabled/shibd.service.dsh-also   not 
> owned
>   /var/lib/systemd/deb-systemd-helper-masked/  not owned
>   /var/lib/systemd/deb-systemd-helper-masked/shibd.service not owned

It looked like dh-systemd wasn't properly cleaning up despite
shibboleth-sp2-utils's postrm script looking like it would:

> #!/bin/sh
> 
> set -e
> 
> if [ "$1" = purge ]; then
> for dir in /var/cache/shibboleth /var/log/shibboleth; do
> if dpkg-statoverride --list "$dir" >/dev/null 2>&1; then
> dpkg-statoverride --remove "$dir"
> fi
> rm -rf "$dir"
> done
> fi
> 
> # Automatically added by dh_installinit
> if [ "$1" = "purge" ] ; then
> update-rc.d shibd remove >/dev/null
> fi
> 
> 
> # In case this system is running systemd, we make systemd reload the unit 
> files
> # to pick up changes.
> if [ -d /run/systemd/system ] ; then
> systemctl --system daemon-reload >/dev/null || true
> fi
> # End automatically added section
> # Automatically added by dh_systemd_enable
> if [ "$1" = "remove" ]; then
> if [ -x "/usr/bin/deb-systemd-helper" ]; then
> deb-systemd-helper mask shibd.service >/dev/null
> fi
> fi
> 
> if [ "$1" = "purge" ]; then
> if [ -x "/usr/bin/deb-systemd-helper" ]; then
> deb-systemd-helper purge shibd.service >/dev/null
> deb-systemd-helper unmask shibd.service >/dev/null
> fi
> fi
> # End automatically added section

So I bumped the build-dep up a bit to: dh-systemd (>= 9.20160709). But
then a get a lintian error

> E: libshibsp7: postinst-must-call-ldconfig 
> usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0

that I don't understand because the postinst script in
libshibsp7_2.6.0+dfsg1-4~bpo8+1_amd64.deb contains:

> #!/bin/sh
> set -e
> # Automatically added by dh_makeshlibs
> if [ "$1" = "configure" ]; then
>   ldconfig
> fi
> # End automatically added section

So hmm... any clues? Who's wrong? me, piuparts, lintian or debhelper?

My source package is available at
https://mentors.debian.net/package/shibboleth-sp2 if you want to take a
look at it.

  Etienne



signature.asc
Description: OpenPGP digital signature