(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 <jw...@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:
http://hg.opensource.lshift.net/mercurial-server/diff/9875791ab421/src/mercurialserver/ruleset.py
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
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e69e6a4.10...@lshift.net
