Re: RFS: zkt -- A tool to manage keys and signatures for DNSSEC-zones
On Mon, Mar 11, 2013 at 6:56 PM, Jeroen Massar <jeroen@massar.ch> wrote:
I note your email address puts you in Switzerland, if that is true I
hope you plan to join us at DebConf13:
http://debconf13.debconf.org/
> That was done because there is an existing bug[1] and I wanted to avoid
> creating a new bug, which then had to be duped etc.
>
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481898
Hmm, OK. Maybe you should have mailed the bug then, which would have
reached here too.
> The official/original upstream is at http://www.hznet.de/dns/zkt/
> and that is 1.1.2.
> ...
So, in essence you are packaging your own fork of zkt and making that
a native package.
The original release wasn't that long ago, so I would suggest that you
work on getting your patches included in the original version and a
new 1.1.3 or similar release made. Probably in the process you will
get access to the project yourself.
That is a separate topic to native or not though. Native is not
appropriate in this case either way.
I personally avoid using version control at all for Debian packaging
stuff (unless there is a team involved). My workflow is to do
development in the upstream version control repository (or send
upstream patches/pull requests), make releases (or convince upstream
to do so) and package those. That said, there are lots of folks use
git for packaging in Debian, so I'm sure someone else will reply.
Looking at your git repo, it seems you just imported the latest
release and went with that. When you get access to the original
project, I would encourage you to find out if there is an existing VCS
and if not, import all of the releases into git, not just the latest
one.
git format-patch sounds like a reasonable way to make a non-native
package in the meantime.
> But the Debian way is easy, sleek and very clear about what happens...
>
> If changing it, at the moment one would have to call 'make install-man'
> to get them, which requires a dh_override, or is there a nicer way?
Either an override_dh_auto_install or patch the upstream Makefile.in
to add install-man to the deps of the install target.
>> I would suggest running wrap-and-sort -sa.
>
> Over which files / with which tool?
Just run "wrap-and-sort -sa" (from devscripts) in the directory
containing the debian/ dir, then run git diff and you will see the
changes.
>> The source package is missing a watch file.
>
> Of course, this as it is, at the moment, a native package.
>
> Lintian would complain if it was not. If we change it to a quilt'ed
> package then the watch could simply be the SF style one.
Right, please change to a non-native one and add the watch file.
> The source package is the original upstream tarball, that is why they
> are included. These would not be there for a quilted version.
In Debian we use pristine upstream tarballs, unless they contain
non-free things like RFCs, then we have to repack them since we
promised[1] not to do that. We also like to push things upstream,
including removing non-free things.
1. http://www.debian.org/social_contract
> While the popen calls indeed "don't look nice" they don't seem harmful
> to me and actually are part of the core functionality of the code.
I was thinking here of shell-metacharacter injection rather than
buffer overflows, which I didn't look at.
> Why is that long list of checks not in Lintian? ;)
> Very useful tests!
A lot of them use too much CPU or IO. Others are of questionable
utility (like grepping for hack/todo/xxx).
> Interesting, I did not get these. The dependency was for ncurses was
> missing. Resolved.
I expect you didn't build in a clean chroot using sbuild/pbuilder/cowbuilder.
> Would it not be debhelper's job to add these?
>
> Note that debhelper 9 is used and that should enable all the hardening
> options for that architecture.
Try this in debian/rules:
DEB_BUILD_MAINT_OPTIONS=hardening=+all
> Well, they are examples that is why the might be similar.
Their contents are the same (same bytes).
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: