Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Russ Allbery]

Ferenc Wagner  writes:

> That's great!  Let's start with log4shib, another immediate BD of
> OpenSAML2, which also has a not-yet-packaged upstream release.  I
> applied the DEP-14 transformation (branch renaming) to the Alioth repo,
> and did some streamlining, similarly to xmltooling.  The result is
> available at https://mentors.debian.net/package/log4shib.  Please review
> and upload if suitable.  I'm doing OpenSAML itself tomorrow.

Uploaded log4shib.  We're going to need to ask for a binNMU for xmltooling
as well to pick up the new dependency.  I forgot about that until just
after I uploaded it.

I'll open a bug against release.debian.org for the mini-transition.

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

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Ferenc Wagner]

Russ Allbery  writes:

> Ferenc Wagner  writes:
>
>> Thanks.  Regarding xmltooling, We could as well do a regular upload
>> replacing the liblog4cpp5-dev dependency of libxmltooling-dev with
>> liblog4shib-dev.  I only noticed this yesterday when building opensaml
>> pulled in log4cpp, sorry.
>
> I think I was just confused and everything is fine, since the transition
> already happened after the previous NMU.  There's still a transition for
> opensaml2 and shibboleth-sp2, I think, but that's tiny and not a big deal.

Do you mean the library name transition (+v5), of which this bug is
about?

> It's probably fine to upload opensaml2 right away, but I'll wait until
> log4shib propagates everywhere just in case.

Looks like it won't, the builds fail everywhere.  At first sight the
problem seems to be that on amd64:

checking if gcc static flag -static works... no

which leads to liblog4shib.la being created, while on other arches:

checking if gcc static flag -static works... yes

and liblog4shib.la is not created, leading to an error when debian/rules
tries to remove it.  While this would be easy to work around, I really
wonder what's going on.  Looking at my older build logs, the -static
flag occasionally worked on amd64, but most of the it does not work
(according to configure).  Why does this happen?
-- 
Thanks,
Feri.

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Ferenc Wagner]

Russ Allbery  writes:

> Ferenc Wagner  writes:
>
>> That's great!  Let's start with log4shib, another immediate BD of
>> OpenSAML2, which also has a not-yet-packaged upstream release.  I
>> applied the DEP-14 transformation (branch renaming) to the Alioth repo,
>> and did some streamlining, similarly to xmltooling.  The result is
>> available at https://mentors.debian.net/package/log4shib.  Please review
>> and upload if suitable.  I'm doing OpenSAML itself tomorrow.
>
> Uploaded log4shib.  We're going to need to ask for a binNMU for xmltooling
> as well to pick up the new dependency.  I forgot about that until just
> after I uploaded it.
>
> I'll open a bug against release.debian.org for the mini-transition.

Thanks.  Regarding xmltooling, We could as well do a regular upload
replacing the liblog4cpp5-dev dependency of libxmltooling-dev with
liblog4shib-dev.  I only noticed this yesterday when building opensaml
pulled in log4cpp, sorry.
-- 
Regards,
Feri.

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Russ Allbery]

Ferenc Wagner  writes:

> Thanks.  Regarding xmltooling, We could as well do a regular upload
> replacing the liblog4cpp5-dev dependency of libxmltooling-dev with
> liblog4shib-dev.  I only noticed this yesterday when building opensaml
> pulled in log4cpp, sorry.

I think I was just confused and everything is fine, since the transition
already happened after the previous NMU.  There's still a transition for
opensaml2 and shibboleth-sp2, I think, but that's tiny and not a big deal.

It's probably fine to upload opensaml2 right away, but I'll wait until
log4shib propagates everywhere just in case.

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

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Russ Allbery]

Ferenc Wagner  writes:
> Russ Allbery  writes:

>> I think I was just confused and everything is fine, since the
>> transition already happened after the previous NMU.  There's still a
>> transition for opensaml2 and shibboleth-sp2, I think, but that's tiny
>> and not a big deal.

> Do you mean the library name transition (+v5), of which this bug is
> about?

I got confused and thought that we were uploading liblog4shib1v5 for the
first time, which would mean that everything would need to be rebuilt
against it so that the old library could be removed.  I'd missed that was
just incorporating an NMU, and liblog4shib1v5 had already been introduced.

We're still going to rename (+v5) opensaml2 per this bug, yeah, but that
only affects two packages, so it's not that big of a deal.

> Looks like it won't, the builds fail everywhere.  At first sight the
> problem seems to be that on amd64:

> checking if gcc static flag -static works... no

> which leads to liblog4shib.la being created, while on other arches:

> checking if gcc static flag -static works... yes

> and liblog4shib.la is not created, leading to an error when debian/rules
> tries to remove it.  While this would be easy to work around, I really
> wonder what's going on.  Looking at my older build logs, the -static
> flag occasionally worked on amd64, but most of the it does not work
> (according to configure).  Why does this happen?

The rm command for removing liblog4shib.la hard-coded the multiarch path
for amd64.  I just uploaded a new version of the package that should fix
it.

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

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Ferenc Wagner]

Ferenc Wagner  writes:

> I'm doing OpenSAML itself tomorrow.

I converted the Alioth repository to DEP-14 and pushed all my changes.
Please review and upload if it's suitable.  Preferably after
log4shib_1.0.9-1 is in, I guess, so that it builds against that version.
-- 
Thanks,
Feri.

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Ferenc Wagner]

Luca BRUNO  writes:

>> On Tue, 01 Sep 2015 10:48:28 +0200 Ferenc Wagner  wrote:
>>
>>> I'll package new upstream versions of the whole Shibboleth stack to
>>> fix the outstanding OpenSAML security bug in unstable.
>>> This will change the SO version of xml-security-c and
>>> probably all other library packages in the stack.  Does this change the
>>> big picture somehow?  I don't understand the interdependencies of this
>>> transition.
>
> I had a quick look at this, and I think that libsaml is not getting any
> soname bump in latest upstream version: 
> https://git.shibboleth.net/view/?p=cpp-opensaml.git;a=commitdiff;h=390147dc17687e900bf6a50f3577ccc611a0a7cd;hp=ec145bf31d59d23bbf63cdc39ffeb172ed29d67d
>
> As such, I think we can just proceed with a NMU introducing libsaml8v5.
> This will also remove the last blocker for libshibsp.

Please wait a little, I'm packaging the new upstream anyway and will
introduce this change soon (I'll need a sponsor, though).
-- 
Thanks,
Feri.

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Luca BRUNO]

> On Tue, 01 Sep 2015 10:48:28 +0200 Ferenc Wagner  wrote:

> > I'll package new upstream versions of the whole Shibboleth stack to
> > fix the outstanding OpenSAML security bug in unstable.
> > This will change the SO version of xml-security-c and
> > probably all other library packages in the stack.  Does this change the
> > big picture somehow?  I don't understand the interdependencies of this
> > transition.

I had a quick look at this, and I think that libsaml is not getting any
soname bump in latest upstream version:
https://git.shibboleth.net/view/?p=cpp-opensaml.git;a=commitdiff;h=390147dc17687e900bf6a50f3577ccc611a0a7cd;hp=ec145bf31d59d23bbf63cdc39ffeb172ed29d67d

As such, I think we can just proceed with a NMU introducing libsaml8v5.
This will also remove the last blocker for libshibsp.

Cheers, Luca 

-- 
 .''`.  ** Debian GNU/Linux **  | Luca Bruno (kaeso)
: :'  :   The Universal O.S.| lucab (AT) debian.org
`. `'`  | GPG: 0xBB1A3A854F3BBEBF
  `- http://www.debian.org  | Debian GNU/Linux Developer


signature.asc
Description: This is a digitally signed message part.

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Ferenc Wagner]

Russ Allbery  writes:

> Ferenc Wagner  writes:
>
>> Please wait a little, I'm packaging the new upstream anyway and will
>> introduce this change soon (I'll need a sponsor, though).
>
> I should be able to help with sponsorship.

That's great!  Let's start with log4shib, another immediate BD of
OpenSAML2, which also has a not-yet-packaged upstream release.  I
applied the DEP-14 transformation (branch renaming) to the Alioth repo,
and did some streamlining, similarly to xmltooling.  The result is
available at https://mentors.debian.net/package/log4shib.  Please review
and upload if suitable.  I'm doing OpenSAML itself tomorrow.
-- 
Thanks,
Feri.

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Russ Allbery]

Ferenc Wagner  writes:

> Please wait a little, I'm packaging the new upstream anyway and will
> introduce this change soon (I'll need a sponsor, though).

I should be able to help with sponsorship.

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

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Andreas Beckmann]

Control: block 797770 with -1

On Tue, 01 Sep 2015 10:48:28 +0200 Ferenc Wagner  wrote:
> Hi,
> 
> Thanks for the detailed report.  Right now I'm doing urgent work on HA
> packages, but once that's done, I'll package new upstream versions of
> the whole Shibboleth stack to fix the outstanding OpenSAML security bug
> in unstable.  This will change the SO version of xml-security-c and
> probably all other library packages in the stack.  Does this change the
> big picture somehow?  I don't understand the interdependencies of this
> transition.  Anyway, feel free to NMU these packages if that helps
> unblocking other stuff, just don't be too concerned about the fate of
> the current versions in unstable, expect new upstream versions after a
> couple of weeks.

A couple of months later: What's the status?


Andreas

Processed: Re: Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Debian Bug Tracking System]

Processing control commands:

> block 797770 with -1
Bug #797770 [src:shibboleth-sp2] shibboleth-sp2: library transition needed with 
GCC 5 as default
797770 was not blocked by any bugs.
797770 was not blocking any bugs.
Added blocking bug(s) of 797770: 797623

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

Bug#797623: opensaml2: transition needed for g++-5 ABIs

[Simon McVittie]

Source: opensaml2
Version: 2.5.3-2.1
Severity: serious
Justification: breaks reverse-dependencies
Tags: patch

Background[1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

In the case of opensaml2, std::string appears in header files that
get installed, so it seems very likely that a transition is needed.
The transition consists of renaming the library package, adding a
v5 suffix. A patch is available in Ubuntu,
.

These follow-up transitions for libstdc++ are not going through exactly
the normal transition procedure, because many entangled transitions are
going on at the same time, and the usual ordered transition procedure
does not scale that far. When all the C++ libraries on which this library
depends have started their transitions in unstable if required, this
library should do the same, closing this bug; the release team will deal
with binNMUs as needed.

In the case of opensaml2:

* boost has started its transition
* liblog4shib has started its transition
* libxml-security-c-dev has started its transition
* libxerces-c-dev is not believed to need a transition
* xmltooling is believed to need a transition but has not started yet
  (I haven't got as far through the alphabet as filing a similar
  xmltooling bug yet)

so I think you need to wait for xmltooling before proceeding.
However, the maintainers are the same; please consider this advance
warning of a similarly RC xmltooling bug, and if you fix xmltooling
before I get that far with mass-bug-filing, please check this package
next.

The package is likely to be NMU'd when it becomes ready if there is no
maintainer response, with a patch based on the one in Ubuntu. The
release team have declared a 2 day NMU delay[2] for packages involved
in the libstdc++ transition, in order to get unstable back to a usable
state in a finite time.

S

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
[2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html