Re: RFS: mercurial-server
* Paul Crowley <paul@lshift.net>, 2011-09-09, 11:12:
(I'm afraid I'm not subscribed to debian-mentors - I'm checking the
mailing list archives - please could you Cc: me in responses? Thanks!)
(Done!)
Do you mean your package doesn't work at all in unstable? Why there's
no RC bug in the BTS then?
I don't know - I take it I should file one?
Since we surely cannot release mercurial-server in such a state, yes,
filing it would be in order.
format-3.0-but-debian-changes-patch is a no-go for me, and will make
the Release Team hate you if you ever need to ask them for freeze
exception.
The problem is that I added someone to the CREDITS file in the Debian
code and forgot to add them in the trunk, so the patch adds that
person.
Moreover, the contents of debian-changes-1.2-1 (renamed from
debian-changes-1.1-1, sigh...) is really odd. Why isn't this patch
applied upstream?
The patch is now applied upstream; I just don't want to make a
release_1.2.1 which fixes only the CREDITS file.
Perhaps the right fix is the quick-and-dirty one: remove them from the
CREDITS on the Debian side and make sure they're added in the next
revision. Again, I'm happy to defer to anyone who offers to sponsor.
(renamed from debian-changes-1.1-1, sigh...)
I don't understand - what are you seeing here? Just fetched the
files on mentors.debian.net and looked for what you might be
referring to but can't see it.
mercurial-server 1.1-1 (currently in the archive) had also this patch,
but it's name was debian-changes-1.1-1. BTW, you should always read
carefully debdiff between the current and to-be-sponsored version
*before* requesting sponsorship.
The problem with this patch is that:
- it has autogenerated, unhelpful name;
- it has autogenerated, misleading patch header.
Fix for the other one, out-of-date-standards-version should be
trivial.
Yes, and again it's fixed in the trunk sources. It didn't quite seem
worth making a new release for that, but obviously if a sponsor
requires it I certainly will.
I don't quite understand. Is preparing a new version somehow
particularly costly?
Why debian/watch is empty? Upstream seems to be providing versioned
tarballs, so that should be easy to write.
I am upstream ;-) When I wrote that I was using the "archive" facility
of Mercurial to provide the tarballs, and there was no way for uscan to
scan that. However these days I make a special tarball that excludes
some cruft from the sources, so uscan could scan for that. Naturally
it will never be useful since usually send the Debian files to the
sponsor before I even upload that tarball,
That's an odd work-flow...
but again if a sponsor requires it I'm happy to fix it.
Well, it's not like I'm asking for something that'd take hours of hard
works...
Where can we learn more about this "error in security code"?
I'm afraid I haven't written this up anywhere yet - I wanted to get the
new revision into people's hands first. The changesset that fixes the
problem is here - it removes an order dependency in the way we process
the rules:
http://hg.opensource.lshift.net/mercurial-server/diff/9875791ab421/src/mercurialserver/ruleset.py
I see. This kind of bugs beg for a test-suite. :)
--
Jakub Wilk
Reply to: