shibboleth-sp2: how to get rid of bug/xmltooling? and future
wferi at niif.hu
Wed Sep 10 20:10:47 UTC 2008
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.
>> 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.
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
> 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
> 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
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