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

2017-01-23 Thread Etienne Dysli-Metref 
On 21/01/17 09:32, Ferenc Wágner wrote:
> Shall I upload the backport, or do you plan to add anything else?

Yes, please upload it. :) I updated the debian/jessie-backports branch
with the contents of the package on mentors.

  Etienne



signature.asc
Description: OpenPGP digital signature

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

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

> 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.

Yes, a straightforward merge into debian/jessie-backports should work.
That's what I did for testing this.  I don't think we could reasonably
fix this problem in the Shibboleth package.  Possibly worth reporting to
piuparts, though, so they can work out a general solution if necessary.

> piuparts with --warn-on-leftovers-after-purge does not report other
> problems. Will this piuparts error block the package from getting into
> jessie-backports?

No, it won't, because nobody watches, as far as I know.  Packages aren't
migrated into jessie-backports like they are into testing.  Shall I
upload the backport, or do you plan to add anything else?
-- 
Regards,
Feri

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

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

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

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

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

> 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.servicenot owned
>
> It looked like dh-systemd wasn't properly cleaning up despite
> shibboleth-sp2-utils's postrm script looking like it would: [...]

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.

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

Why?  I mean, where did this version number come from?
-- 
Feri

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

2017-01-18 Thread Niels Thykier 
Etienne Dysli-Metref:
> On 17/01/17 18:30, Niels Thykier wrote:
 E: libshibsp7: postinst-must-call-ldconfig 
 usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0
>>
>> This lintian error:
>>
>>  * is aimed at stretch or later, and
>>  * should be ignored for stable and stable-backports

Correction; I was wrong - this lintian error is correct for a lintian
from stable (I confused it with a newer lintian tag).

This occurs because you are using debhelper from backports, which uses a
trigger instead of maintscript to call ldconfig.  The end result is the
same for you though - ignore the warning. :)

> 
> After having overridden this lintian error, it turns out it was a bit of
> a red herring: piuparts still reports files left after purging.
> 
> [...]

Correct, this lintian warning is completely unrelated to your piuparts
issue.

> 
> So is the postrm script from shibboleth-sp2-utils not executed?
> 

It is definitely called - if it wasn't, almost everything would be
failing on piuparts.d.o and dpkg in stable would completely an utterly
broken with us drowning in RC bugs. :)

Most likely, there is an issue with either the postrm script OR the
helpers used in it.  I am not an expert on the helpers, so I cannot help
there.

Thanks,
~Niels

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

2017-01-18 Thread Etienne Dysli-Metref 
On 17/01/17 18:30, Niels Thykier wrote:
>>> E: libshibsp7: postinst-must-call-ldconfig 
>>> usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0
>
> This lintian error:
> 
>  * is aimed at stretch or later, and
>  * should be ignored for stable and stable-backports

After having overridden this lintian error, it turns out it was a bit of
a red herring: piuparts still reports files left after purging.

> 0m39.2s 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

So is the postrm script from shibboleth-sp2-utils not executed?



signature.asc
Description: OpenPGP digital signature

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

2017-01-18 Thread Etienne Dysli-Metref 
On 17/01/17 18:30, Niels Thykier wrote:
>>> E: libshibsp7: postinst-must-call-ldconfig 
>>> usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0
> 
> This lintian error:
> 
>  * is aimed at stretch or later, and
>  * should be ignored for stable and stable-backports

Thanks Niels! :)

That's a bit strange though because I'm running lintian from stable
(2.5.30+deb8u4). It wouldn't surprise me if I were running a more recent
version. I'll create an override for this test in jessie-backports then.

Cheers,
  Etienne



signature.asc
Description: OpenPGP digital signature

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

2017-01-17 Thread 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