On Sat, May 21, 2016 at 02:02:49PM -0700, optix2000@teitoku.net wrote: > > d/rules: > > - why -D_FORTIFY_SOURCE=1? Such things should be documented > > For security reasons, as this is an internet accessible daemon that > accepts user input. What I've meant was "you replaced stronger default flag with a weaker one". As you know about dpkg-buildflags you should know that the 'fortify' option is enabled by default and that it adds -D_FORTIFY_SOURCE=2. > It also gets rid of the lintian info tag > "hardening-no-fortify-functions". If you have this tag then something is wrong. If it's also fixed by adding -D_FORTIFY_SOURCE to CFLAGS then your upstream build system doesn't handle CPPFLAGS correctly. It should be fixed to handle them. > > - you can probably replace override_dh_auto_clean with debian/clean > > I can't seem to find any documentation regarding debian/clean in the > maint-guide [https://www.debian.org/doc/manuals/maint-guide/dother.en.html] > How is debian/clean supposed to be used? man dh_clean To remove files not removed by dh_auto_clean. > > - why this package not only Conflicts but Replaces iroffer? Do you know > > how will apt handle this relationship? Do you intend to do anything with > > the iroffer package itself (it's orphaned ATM)? If you want to replace > > it completely then the replacing procedure is different, see > > https://wiki.debian.org/Renaming_a_Package > > iroffer-dinoex is intended to be a drop-in replacement for the original > iroffer. The binaries have the same name, and the config formats are > unchanged. > Based on what I could tell from the docs (correct me if I'm wrong) > [www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces], > this is the correct way to have a package be an alternative drop in > replacement (ie how MTA's are managed). > I do not intend to take over the iroffer package completely. This is merely > an alternative to the original iroffer that can be a drop in > upgrade/replacement. Just Conflicts could be enough but it won't uninstall the other package. I don't know how Conflicts+Replaces will work, you'll need to test this. Note that you still won't be able to install iroffer without manually removing iroffer-dinoex (at least that's what I think). > > d/copyright: > > - it says "GPL-2" and "LGPL-2.1" in the short names but "or (at your > > option) any later version" in the texts > I assumed "or (at your option) any later version" meant that the upstream > author could (at their discretion) upgrade the license to a newer version > of GPL. > Not that an end-user (me) could upgrade to a newer version at my > descretion. I'm not a lawyer, so I chose to leave it untouched. You seem to be confusing several things here. The upstream authors can do anything they want but the license clauses say what can other people do instead. "License: GPL-2" means "you can use GPL 2", "License: GPL-2+" means "you can use GPL 2 or (at your option) any later version". And the upstream LICENSE doesn't say about "any later version", so you didn't "leave it untouched". Actually, the upstream LICENSE includes the OpenSSL linking exception for some files and tells to look into the files to find out which of them have what licenses so your d/copyright should be more fine-grained than now. > > - using GPL for debian/ while having MIT and LGPL in the upstream source > > is discouraged and may cause problems if debian/ contains e.g. patches > What's the correct way to resolve this, choose a less restrictive license > for debian/? Yes. > Is there a list of recommended licenses? I think the currently recommended simple non-copyleft license (fir anything, not just debian/) is Expat. > no-upstream-changelog should be an I tag. Why do you think so? > > - manpage-has-bad-whatis-entry override says "Upstream manpage" which > > doesn't sound like a valid cause to me > Should I just leave the lintian warning as-is until it's fixed upstream? > Or should I be patching the manpage until it's fixed upstream? The second option is preferable, note that the tag is W. But the first one is better than overriding it (you should override only things that are not problems, not things that are currently hard/impossible to fix problems) -- WBR, wRAR
Attachment:
signature.asc
Description: PGP signature