Hi Gianfranco
I don't know which remaining issues you are talking about...
http://debomatic-amd64.debian.net/distribution#unstable/eviacam/2.0.1-5/lintian See below:
W: eviacam source: dep5-copyright-license-name-not-unique (paragraph at line 68) W: eviacam source: dep5-copyright-license-name-not-unique (paragraph at line 92) W: eviacam: old-fsf-address-in-copyright-file
Solved. Thanks Alex for your patch! :-)
I: eviacam: desktop-entry-lacks-keywords-entry usr/share/applications/eviacam.desktop I: eviacam: spelling-error-in-binary usr/bin/eviacam appropiate appropriate I: eviacam: spelling-error-in-binary usr/bin/eviacam Allows to Allows one to
Fixed.
W: eviacam: binary-without-manpage usr/bin/eviacam W: eviacam: binary-without-manpage usr/bin/eviacamloader
I will try the help2man approach
I: eviacam: hardening-no-fortify-functions usr/bin/eviacam I: eviacam: hardening-no-fortify-functions usr/bin/eviacamloader
about fortify you need to be sure the code doesn't override CPPFLAGS CFLAGS and LDFLAGS (or uses them indeed) IIRC that warning is about CPPFLAGS
The code overrides the CPPFLAGS thus, not sure if I have to change anything. I: eviacam: arch-dep-package-has-big-usr-share 6205kB 84% Could you provide some hints on how to split the package.
P: eviacam source: debian-watch-may-check-gpg-signature
I'll take a look
anyway I can find one for you: rm ../eviacam_2.0.1.orig.tar.gz uscan --debug --force-download dpkg-buildpackage -S -sa "dpkg-source: error: cannot represent change to po/ar.gmo: binary file contents changed dpkg-source: error: add po/ar.gmo in debian/source/include-binaries if you want to store the modified binary in the debian tarball [...] dpkg-source: error: cannot represent change to po/zh_TW.gmo: binary file contents changed dpkg-source: error: add po/zh_TW.gmo in debian/source/include-binaries if you want to store the modified binary in the debian tarball dpkg-source: error: unrepresentable changes to source dpkg-buildpackage: error: dpkg-source -b eviacam-2.0.1 gave error exit status 2 " you seem to have a different tarball from the upstream one.
Right
I suggest you to use the exact tarball as the one you download from sf website, and add patches with debian/patches.
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?
In this case since they are because of translation issues you might just remove them in clean target, and recreate them on build. (dpkg-source gives a warning on deletion, but not an error). Moreover recreating from source is the preferred Debian way of doing things. (being able to recreate is mandatory, recreating is preferred).
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? Regards, Cesar
