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

[Ferenc Wagner]

Russ Allbery <rra at debian.org> writes:

> Ferenc Wagner <wferi at niif.hu> 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
deleted?

>> (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
>> http://apt.niif.hu/debian [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 backports.org, but if it
> would be useful to upload a backport of what's currently in testing to
> backports.org, 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.

OK.
-- 
Thanks,
Feri.