shibboleth-sp2: how to get rid of bug/xmltooling? and future

Ferenc Wagner wferi at
Wed Sep 10 20:10:47 UTC 2008

Russ Allbery <rra at> writes:

> Ferenc Wagner <wferi at> writes:
>> I'm left with a question massaging the SP package: as the fix included
>> in bug/xmltooling isn't needed for XMLTooling-C version 1.1, what's the
>> best way to get rid of it?  I reverted the single patch in that branch
>> and then merged it into master, which worked, but maybe it isn't the
>> best solution.  Shall I just push it, or is there a preferred way?
> You do that first, and then delete the branch with:
>     git branch -d bug/xmltooling
>     git push :bug/xmltooling
> The final merge makes sure that there aren't any other lingering changes.

Done, thanks.

>> I noticed (after some hours banging my head into the wall) that you
>> deleted the obsolete bug branches from the xmltooling and opensaml2
>> repos, I guess something similar would be the best here, too.
> Yup.

I didn't touch bug/gcc-4.3, should it also get reverted, or did you
leave that out when you imported the new upstream so it can be simply

>> (By the way, how do you notice when a remote branch is deleted?  git
>> pull did not inform me any way, only push insisted it was a new
>> branch...)
> git remote prune

If only I knew it some hours earlier...  At least I won't forget it. :)

>> That change included I could build the whole stack.  Thank you again for
>> doing the merge, you did a perfect job!  Now what should we do?  I'd
>> push for some Etch backports now.  We've got a public repository (deb
>> [sid|etch-backports] main) which also contains
>> the UNRELEASED 2.1 packages btw.  Should we just use that (it also
>> carries some unrelated packages we use internally) or setup something
>> else?
> Well, only the 2.0 packages are eligible for, but if it
> would be useful to upload a backport of what's currently in testing to
>, I'm willing to do that.

We sort of already decided not to do that, if I remember correctly.
Nobody needs 2.0 backports now that 2.1 is released.  If that means
there'll be no official backports for Etch, then be it...  Reading the
homepage I can't tell whether etch-backports will be open again after
the release of Lenny, or only lenny-backports will receive packages
from the post-lenny testing.  What's the case?

> I'd prefer if someone else could do the merge into the etch branch
> and the testing, since I don't have an etch system to use easily for
> testing.

Sure, I'll do that.  Does that consist of merging master into the etch
branch and start from there?

> If you specifically want 2.1, it's probably best to stick with your
> existing repositories for the time being, until after the lenny release.


More information about the Pkg-shibboleth-devel mailing list