[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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!)


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:


I see. This kind of bugs beg for a test-suite. :)

Jakub Wilk

Reply to: