Hi Andrey, Thanks for looking over this. I've replied to your concerns in line and created a new build which (hopefully) addresses most of them.
> 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. It also gets rid of the lintian info tag "hardening-no-fortify-functions". The docs for D_FORTIFY_SOURCE state it won't break anything (compared to D_F_S=2). From my own testing, there's no issues with the binary. I've added a comment, and documented in Readme.debian (That is the correct place to document, right?) > - commented out -Wl,--as-needed looks strange, if it doesn't work/isn't > needed you shouldn't include this line at all > - "dh_make generated override targets" sounds strange. "This is example > for Cmake (See https://bugs.debian.org/641051 )" sounds even strange, > especially when looking at that bug. That commented out > dh_auto_configure is strange too, especially the -DCMAKE_LIBRARY_PATH > part. These are all comments that came from the debian/rules template from using dh_make (which is why they make no sense). I've removed them in the latest build. > - 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? > README.source even says "You WILL either need to modify or delete this > file" Oops. Removed. > d/control: > - commented out Vcs-* fields should be either removed or uncommented and > edited Removed in the latest build. > - 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. > 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. > - 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/? Is there a list of recommended licenses? > d/install is empty Oops. I had used it for something prior and forgot to remove it. Removed in the latest build. > iroffer-dinoex.lintian-overrides: > - you shouldn't override P tags Which P tag did I override? no-upstream-changelog should be an I tag. > - 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? Thanks, Weilu