Bug#836370: transition: shibboleth

[Emilio Pozuelo Monfort]

On 04/09/16 16:18, Ferenc Wágner wrote:
> Do you think there's anything else to do (but wait for testing
> migration) with this transition?

Just wait. It all seems fine at this point.

> I don't understand why opensaml2 and
> shibboleth-sp2 are "partial" on all arches except the hurd, could you
> please give me a hint?  It's the first time I look at such tables...

Because the old binaries were still around. Those have been decrufted now as the
binNMUs have caused packages to depend on the new binaries, and that's why they
are no longer "partial" but "good".

Cheers,
Emilio

Bug#836370: transition: shibboleth

[Ferenc Wágner]

Emilio Pozuelo Monfort  writes:

> On 03/09/16 15:58, Ferenc Wágner wrote:
>
>> I'm finished with the uploads.  Xmltooling, opensaml2 and shibboleth-sp2
>> all built on the testing architectures.  Please trigger rebuilds of
>> shibboleth-resolver and moonshot-gss-eap
>
> Scheduled.

Thanks.  They looks mostly good on the transition trackers.  The build
logs don't explain the "bad" shibboleth-resolver states on amd64 and
i386 (to me), I hope it's just some transient.

>> (possibly also opensaml2 on powerpcspe, if you handle ports).
>
> That failed to build. A binnmu makes no sense. Perhaps you meant a
> give back? Why do you think that would help?

Yes, the powerpcspe and sh4 builds should be tried again.  They failed
because they somehow overtook the new xmltooling builds and thus met a
pre-C++11 libxmltooling.

Do you think there's anything else to do (but wait for testing
migration) with this transition?  I don't understand why opensaml2 and
shibboleth-sp2 are "partial" on all arches except the hurd, could you
please give me a hint?  It's the first time I look at such tables...
-- 
Thanks,
Feri

Bug#836370: transition: shibboleth

[Emilio Pozuelo Monfort]

On 03/09/16 15:58, Ferenc Wágner wrote:
> I'm finished with the uploads.  Xmltooling, opensaml2 and shibboleth-sp2
> all built on the testing architectures.  Please trigger rebuilds of
> shibboleth-resolver and moonshot-gss-eap

Scheduled.

> (possibly also opensaml2 on powerpcspe, if you handle ports).

That failed to build. A binnmu makes no sense. Perhaps you meant a give back?
Why do you think that would help?

Cheers,
Emilio

Bug#836370: transition: shibboleth

[Ferenc Wágner]

I'm finished with the uploads.  Xmltooling, opensaml2 and shibboleth-sp2
all built on the testing architectures.  Please trigger rebuilds of
shibboleth-resolver and moonshot-gss-eap (possibly also opensaml2 on
powerpcspe, if you handle ports).
-- 
Thanks,
Feri

Processed: Re: Bug#836370: transition: shibboleth

[Debian Bug Tracking System]

Processing control commands:

> tags -1 confirmed
Bug #836370 [release.debian.org] transition: shibboleth
Added tag(s) confirmed.

-- 
836370: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836370
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#836370: transition: shibboleth

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 02/09/16 10:28, Ferenc Wágner wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> xmltooling 1.6, opensaml2 2.6 and shibboleth-sp2 2.6 each change their SONAME
> in this new version of this software stack.  The new stack is already in
> experimental, and the two external depending packages (shibboleth-resolver
> and moonshot-gss-eap) build successfully against the new stack without any
> source change.  The auto-xmltooling, auto-opensaml2 and auto-shibboleth-sp2
> trackers look good, but here's a unified ben file:
> 
> title = "shibboleth";
> is_affected = .depends ~ "libxmltooling6v5" | .depends ~ "libsaml8v5" | 
> .depends ~ "libshibsp6v5" | .depends ~ "libxmltooling7" | .depends ~ 
> "libsaml9" | .depends ~ "libshibsp7";
> is_good = .depends ~ "libxmltooling7" | .depends ~ "libsaml9" | .depends ~ 
> "libshibsp7";
> is_bad = .depends ~ "libxmltooling6v5" | .depends ~ "libsaml8v5" | .depends ~ 
> "libshibsp6v5";

Go ahead.

Emilio

Bug#836370: transition: shibboleth

[Ferenc Wágner]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

xmltooling 1.6, opensaml2 2.6 and shibboleth-sp2 2.6 each change their SONAME
in this new version of this software stack.  The new stack is already in
experimental, and the two external depending packages (shibboleth-resolver
and moonshot-gss-eap) build successfully against the new stack without any
source change.  The auto-xmltooling, auto-opensaml2 and auto-shibboleth-sp2
trackers look good, but here's a unified ben file:

title = "shibboleth";
is_affected = .depends ~ "libxmltooling6v5" | .depends ~ "libsaml8v5" | 
.depends ~ "libshibsp6v5" | .depends ~ "libxmltooling7" | .depends ~ "libsaml9" 
| .depends ~ "libshibsp7";
is_good = .depends ~ "libxmltooling7" | .depends ~ "libsaml9" | .depends ~ 
"libshibsp7";
is_bad = .depends ~ "libxmltooling6v5" | .depends ~ "libsaml8v5" | .depends ~ 
"libshibsp6v5";

These packages will also be part of the openssl transition, but they are
incompatible with OpenSSL-1.1.  Upstream is already working on that on a
separate branch.  This internal SONAME transition, on the other hand, is
very self-contained and should finish before that in my opinion.