Hi everyone, About the `hardening-no-fortify-functions' lintian warning, I use the `debian/rule' template generated by dh_make and merges it with the original `debian/rule' file. Now the warning goes away with the new `debian/rule' file, which is in the attachment. Please try to see if it works! I will search the net and see if it is easy to separate the documentation into another package. Cheers, Alex 2015-09-25 23:23 GMT+08:00, Gianfranco Costamagna <costamagnagianfranco@yahoo.it>: > Hi > >>I will try the help2man approach > > > this is a string I used recently for another package > help2man -N -n "enhanced HTTPS support for httplib and urllib2 using > PyOpenSSL" /usr/bin/ndg_httpclient --version-string=v0.4.0 > > ndg_httpclient.1 > >>The code overrides the CPPFLAGS thus, not sure if I have to change >> anything. > > > I see > > #CPPFLAGS="$CPPFLAGS $COMPFLAGS" > CPPFLAGS="$COMPFLAGS" > #CXXFLAGS="$CXXFLAGS $COMPFLAGS" > CXXFLAGS="$COMPFLAGS" > > commit fc42432855a02c6881199ff09eef95e84db43345 > Author: Cesar Mauri <cesar@crea> > Date: Tue Mar 8 20:29:04 2011 +0100 > > Fixed compilation flags to produce a debuggable in debug mode > > > well, I guess maybe you didn't apply correctly the patch? > > I would like to understand the rationale for that commit! > >>>I: eviacam: arch-dep-package-has-big-usr-share 6205kB 84% >> >>Could you provide some hints on how to split the package. > > > maybe by providing an eviacam-doc package, because I bet the > 6MB are because of the documentation. > > But well, it isn't too much, you can also just don't care > > (just think about small systems, where space matters, but I'm not > sure they will run a webcam) > > >>> P: eviacam source: debian-watch-may-check-gpg-signature >> >>I'll take a look > > > this is about gpg signing the releases, but I'm not sure sf supports > that > >>Being the upstream developer I would prefer to avoid having to patch the >> tarball. >>Perhaps I could fix the remaining issues, bump the upstream version number >> and >>then upload the (right) tarball. What do you think? > > > yes, but I hope you will considering having the Debian packaging in a > different branch > that way you are not forced to do a new upstream release at each Debian > upload. > (that might be just because of a packaging issue) > > > also other linux distros might not like the Debian directory :) > > >>I completely agree with this, much better if I don't need to distribute >>auto-generated files. However, I tried removing the .gmo files from the >>tarball but after that, the .mo files were missing in the binary package. >> >>Could you please provide some hint here? > > > I guess override_dh_auto_build: > dh_auto_build > and here generate them > # for i in `ls po`; do \ > # msgfmt -o "po/$$i.mo" \ > # "po/$$i.po"; \ > > # fi; \ > # done; \ > > > or just generate them in your Makefile.am or whatever > > you can also use pocompile if needed, just add the required > build-dependency. > > > > last two issues: > "Recommends: wx3.0-i18n" > > can you please clarify? is that required or not? does the build work with or > without? > does it increase the user experience? > > and... what about having a dbg package too? > > cheers, > > G. >
Attachment:
rules
Description: Binary data