xmltooling patches for 2.5 versions?

[Cantor, Scott]

> I have SP's on both rhel 7.4 and SLES12SP2.  The RHEL servers have the latest
> shibboleth package (2.6.1-3.1), but when I check for the xmltooling library, I
> see version 1.6.3:
> libxmltooling7-1.6.3-3.1.x86_64

The build service has the updated packages. Whatever you're looking at may be out of date, but they are there in all the repositories.
 
> Is it "Upgrade to V1.6.4 AND The latest RPM packages?" or "Upgrade to
> V1.6.4 OR the latest RPM packages [that already include a fix]"?

It's upgrade to 1.6.4, period if you're using packages we provide. You need to know, absolutely, whether that's the case.

> Is building from source the only option for the SLES machines?  SUSE has
> V2.5.5 in their repo's; when I try the official repo they're only available as
> source packages.

I stopped building packages for newer 13.x versions when they decided to start packaging the SP in it, something I had no idea they did until recently. I wouldn't have advised that they do that, but somebody did. So they are responsible for those platforms and eventually SUSE will be off the list for us.

The platforms I package are listed on the web site and extend from SUSE 10-12 and openSUSE 13.1 and 13.2. I was going to add 13.3+ and that's when I found out they were already doing it, so I really didn't see that it would be beneficial to add to the chaos, particularly because of the risk of my build pulling in something they packaged, and ending up with a mix.

2.5.5 is unsupported by the project, no ifs/ands/buts. Packaging something means you own it, and they own it.
In practice that just means we don't do backporting of patches. Now that support is officially something the members are paying for, the actual response to support issues in JIRA will tend to be more than just "upgrade or go away", most issues aren't going to be version-dependent. On the list, you can infer that when I see an unsupported version, I will simply delete and move on.

-- Scott