For which package are you getting this error message?
all 4 packages. however, if you don't see these errors, this is
probably a false-positive, and is likely caused by my pbuilder
settings, I will ignore them for now. everything else looks good.
I am not sure about which files are you referring to. You are perhaps making a confusion between the signed tarball file and the keyring file containing the signing key.
The signed tarball is obtained by running the command (for zmat, for instance):
gpg --detach-sign --armor some-package-0.1.tgz
This will produce a some-package-0.1.tgz.asc file, that you may, if you wish, rename it to some-package-0.1.tgz.sig and upload it to your github download area, along with the tarball some-package-0.1.tgz.
The debian/upstream/signing-key.asc file contains, as its name indicates, the public signing key used for signing the tarball. The recipe for obtaining it is given in the web page that you indicated above.
thanks for explaining - so the .sig file is basically a renamed
.asc file.
as I mentioned previously, the orig.tar.gz are "restructured"
upstream release (by creating octave-specific file, such as inst/,
INDEX, COPYING etc). if I upload a .sig file, I will also need to
manually upload the signed orig.tar.gz file - and repeat so for
all future releases. if this is the case, let's skip it for now
and I will think about how to do this more efficiently in the
future (a big portion of existing users are MATLAB users). thanks
for letting me know about this option.
According to the FHS [*], binaries like those, that are expected to be run by other programs (and not by users) should be put in /usr/libexec. You should change your *.m files such that the executables are searched in this directory (or in a subdirectory specific to iso2mesh).
At any rate, Lintian yields the following for your package:
One potential solution is to separate the executables into an iso2mesh-external subpackage and install those to the system path (/usr/bin), the only concern is that cork (https://github.com/gilbo/cork)/meshfix (https://github.com/MarcoAttene/MeshFix-V2.1) are currently not packaged in debian, and the version used in iso2mesh are modified forks (https://github.com/fangq/cork, https://github.com/fangq/meshfix <https://github.com/fangq/cork>), I am not sure providing those binaries in debian is too intrusive.
let me know what you think
after reading the web pages and I am leaning towards creating a binary-only sub-package, iso2mesh-tools, and install these meshing utilities into system's default binary folder, like the gdf-tools subpackage in libgdf. here are my thinking:
1. the meshing utilities used in iso2mesh/bin, i.e. cgalmesh,
cgalsurf, cgalsimp2, cork, meshfix, jmeshlib, are indeed general
purpose mesh generation/processing tools, and do not depend on
iso2mesh, or specific to iso2mesh.
2. cgal* binaries are not part of any existing packages, and do
not have the risk of future file name conflict
3. cork/meshfix are derived from existing projects, but both
upstream projects have been inactive, and my github forks contain
the latest commits and are compatible with the upstream software
feature wise.
4. another utility used in iso2mesh, tetgen, has already been done
in a similar way, i.e. adding tetgen as dependency and call from
$PATH
5. no code change or patch needed for iso2mesh upstream files
please let me know if you agree with this.
I have one more questions for this package - I have not added matlab-iso2mesh subpackage yet, because it shares identical .m files to octave-iso2mesh. I am wondering if it is possible to create the /usr/share/matlab/site/m/iso2mesh folder as a symbolic link to /usr/share/octave/packages/iso2mesh-1.9.5? this way we can avoid some redundancy - any thoughts on this?
thanks again
Rafael