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

Re: RFS: mercurial-server

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

Many thanks for your response on this and your advice!

* Jakub Wilk <jwilk@debian.org>, Fri, 9 Sep 2011 00:34:55 +0200
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?

Why? Are they particularly hard to fix?

No, they're easy to fix and they're fixed in the trunk. I don't know why my local lintian run didn't detect them.

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.

 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.

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, but again if a sponsor requires it I'm happy to fix it.

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:


Thanks again for your help with this. I hope I've explained my reasons why I did things the way I did, but I don't mean to push back too hard against what you propose - I'm happy to make whatever changes to the Debian package a sponsor would like before approving it. Cheers!
  [][][] Paul Crowley
    [][] LShift Ltd
  []  [] www.lshift.net

Reply to: