I suggested to repack the tarball through uscan because you have said, if I remember correctly, that you were repacking the upstream tarball, anyway. I have perhaps misunderstood something.
hi Rafael,
I recreated 3 of the packages:
for zmat:
https://salsa.debian.org/fangq/zmat-pristine
for octave-jsonlab:
https://salsa.debian.org/fangq/jsonlab-pristine
for octave-jnifti:
https://salsa.debian.org/fangq/jnifti-pristine
for zmat, I adopted the repack script and used import-orig --uscan to create the repository (debian/ folder are the latest version, same for other packages)
for jsonlab and jnifti, I directly used the upstream tarballs, and used override_dh_auto_configure to reorganize files for octave packaging. I've tested all 3 with gbp buildpackage, and the output packages look fine.
Can you take a look and let me know if you are ok with these? I
will be happy to do a push --force to overwrite the
corresponding pkg-octave-team/* repos (or delete the current repo
and re-import)
For octave-iso2mesh, I will also recreate the repo using repack, but I want to ask your suggestion on use of multiple sources.
Basically, iso2mesh contains several external tools that linked
to iso2mesh source code via submodules, see
https://github.com/fangq/iso2mesh/tree/master/tools
in such case, the github upstream tarball does not contain the
submodule codes, so in my previous "repacking" script, I
downloaded 3 tarballs and merged them before building the package,
see
https://salsa.debian.org/fangq/octave-iso2mesh/-/blob/master/README.md
I am wondering how does this work for the debian/repack workflow?
In RPM packaging, one can use multiple sources for a single
package:
https://src.fedoraproject.org/rpms/octave-iso2mesh/blob/master/f/octave-iso2mesh.spec#_17
Once I get an idea on multiple source merging, I will create a
new repo for you to review.
thanks
Qianqian
Best,
Rafael