If you are planning to maintain Debian package, then I strongly recommend that you to build them in a Debian unstable environment. Otherwise, there are chances that your packages will face all kind of problems in the Debian autobuilders.
You could install a schroot with a clean unstable Debian distribution installed in it. I use pbuilder (but there are other systems available, as cowbuilder and sbuild): https://wiki.debian.org/PbuilderTricks
I actually had previously installed pbuilder, but by default it
pulls from ubuntu's mirrors.
After using --mirror and --distribution with pbuilder create and setting "pbuilder = True;dist = unstable" in ~/.gbp.conf, I was able to build the packages using compat-13. This is a much better solution than a virtual machine, thanks!
just one minor thing - when compiling with pbuilder with
unstable, I verified that compat13 is used, but I got the below
two errors from 'lintian -iIE --pedantic --profile debian':
E: octave-... source:
package-uses-debhelper-but-lacks-build-depends
E: octave-... source: missing-build-dependency debhelper
should I worry about these?
These are two different things. Debian packages must be signed in order to be uploaded to unstable (or to mentors) and this is what you did.
However, I was mentioning the signing of the upstream tarball, done by the upstream author or maintainer. All you have to do is to provide a *.sig file along with your tarball.
...
In the Debian package for Octave, we added the public key with which the upstream author signed the tarball (in debian/upstream/signing-key.asc). We also added to debian/watch the appropriate option, such that uscan can retrieve the signature file:
opts=pgpsigurlmangle=s/$/.sig/ http://ftpmirror.gnu.org/octave/octave-([\d\.]+)\.tar\.bz2
The goal of this is to prevent malicious coding being introduced in Debian.
I googled a bit and found this page:
https://narfation.org/2013/06/23/signed-upstream-tarballs-in-debian
and was able to create a .asc file from my orig tarball. according to the above link, such .asc file can be placed as debian/upstream/signing-key.asc, but it has a different suffix than .sig.
do you know how to convert from .asc to .sig? happy to add these for all the packages I am working on.
I have set up the Salsa repository for octave-iso2mesh: https://salsa.debian.org/pkg-octave-team/octave-iso2mesh
thanks, the files are uploaded
Your current implementation of the octave-iso2mesh package looks a bit strange. You heave a DESCRIPTION file, but the files are not installed using the pkg system. Besides, it is strange to put the *.m files in the architecture-dependent directory /usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/iso2mesh/
At any rate, the Depends field in the DESCRIPTION should be sufficient to get the correct behavior, such that "pkg load iso2mesh" would automatically load jsonlab and jnifti.
iso2mesh contains 7-8 private executables (cgal*, cork, meshfix,
jmeshlib and tetgen). It looks for these binaries inside the bin
sub-folder next to the .m files, or if not found, look for those
in the $PATH env var. see
https://github.com/fangq/iso2mesh/blob/master/mcpath.m#L29-L37
because of this search sequence, and the executables are arch-dependent in nature, I placed both bin/* and all the .m files inside the arch-dependent folder. However, I am open to other suggestions for file organization.
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), I am not sure providing those binaries in debian is too intrusive.
let me know what you think
Anyway, there is a serious problem with your current implementation of octave-iso2mesh, since it does not build against version 5.0.2-3+b1 of libcgal-dev, the version which is currently in unstable. It fails with this message:
I was able to reproduce this problem using pbuilder on my machine, and solved it by dropping -lCGAL -lCGAL_ImageIO in the command, see
my only concern is that if I would like to backport this to
stable releases, such setup will be a problem again. The current
cmake-based compilation scripts in iso2mesh/src is broken on
unstable (but does work on Fedora/Ubuntu 16.04).
alternatively, I can add a command to detect cgal's version to
decide whether the libraries are needed.
Qianqian