On Mon, Mar 11, 2013 at 6:56 PM, Jeroen Massar <jer...@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 -- 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/caktje6f6-lu3azpg2kmyhok2yetq_vucuaybv1nyxryjdgr...@mail.gmail.com
