Re: Help packaging an octave toolbox

[Qianqian Fang <fangqq@gmail.com>]

hi Rafael

I just CCed you a reply to Bouyuan Yang on the zmat's RFS bug (#962640). 
> From the build-log he provided, I found the build-arch target was not 
executed, I will read more about that and hopefully find a fix.


In the meantime, I am working on a new package - iso2mesh, and hope to 
get your suggestions. the RFS can be found at

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963230


iso2mesh is the "parent" project of jsonlab/jnifti. In the upstream 
repo, iso2mesh contains a full copy of jsonlab and jnifti.

in the rules file of octave-iso2mesh, I delete the overlapping functions 
to avoid duplicates

https://salsa.debian.org/fangq/octave-iso2mesh/-/blob/master/rules#L35-41

in the meantime, add octave-jsonlab and octave-jnifti as Depends of 
octave-iso2mesh


Now the issue is that iso2mesh contains arch-dependent executable 
(private binaries), so I install the toolbox at

/usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/iso2mesh

similar to the mex-based toolbox like zmat and libgdf, but 
octave-jsonlab and octave-jnifti are installed as a regular octave 
package (use with pkg load).

I found that after installing octave-iso2mesh, octave-jsonlab and 
octave-jnifti, if one starts octave, iso2mesh is automatically loaded, 
but both jsonlab and jnifti are not, unless one types pkg load.

do you have any suggestion for this? can I install a .m based toolbox to 
an arch-dependent folder so that it can be found automatically by other 
toolboxes that depend on it?


Qianqian



On 6/20/20 3:22 PM, Qianqian Fang wrote:
> On 6/20/20 2:13 PM, Rafael Laboissière wrote:
> > With my changes, now in the Git repository, octave-jsonlab seems 
> > ready for upload (but debhelper compat level could be bumped to 13 
> > and unit testing would be a real improvement).
> >
> > As regards, octave-jnifti, package jnifti-demos is empty.
>
>
> this is now fixed, see
>
> https://salsa.debian.org/pkg-octave-team/octave-jnifti/-/commit/ae29d2d5f7bd796ff17505208b8f3afe772fbdf1 
>
>
>
> > Finally, zmat does not build at all for me:
> >
> >     mv: cannot stat 'lib/libzmat.a': No such file or directory
>
>
> I suspect that there is a missing dependency - did you see any error 
> when compiling the source code (such as library does not exist etc)? a 
> dump of the log would be helpful.
>
> I just pulled the latest packaging file and the building was fine on 
> my computer (log attached) - two errors showed up at the end, I 
> suspect it is related to the removal of debhelper?
>
>
> Qianqian
>
>
> >     make[1]: *** [debian/rules:27: override_dh_auto_install] Error 1
> >     make[1]: Leaving directory 
> > '/var/data/rlaboiss/debian/PKGS/zmat/zmat'
> >     make: *** [debian/rules:7: binary] Error 2
> >     dpkg-buildpackage: error: fakeroot debian/rules binary subprocess 
> > returned exit status 2
> >     debuild: fatal error at line 1182:
> >     dpkg-buildpackage -us -uc -ui failed
> >
> > After commenting this line in debian/rules:
> >
> >     mv lib/libzmat.a debian/libzmat1/usr/lib/$$arch/libzmat.a;
> >
> > Then, there is a further error:
> >
> >     chmod -x zipmat.mex
> >     chmod: cannot access 'zipmat.mex': No such file or directory
> >     make[1]: *** [debian/rules:29: override_dh_auto_install] Error 1
> >     make[1]: Leaving directory 
> > '/var/data/rlaboiss/debian/PKGS/zmat/zmat'
> >     make: *** [debian/rules:7: binary] Error 2
> >     dpkg-buildpackage: error: fakeroot debian/rules binary subprocess 
> > returned exit status 2
> >     debuild: fatal error at line 1182:
> >     dpkg-buildpackage -us -uc -ui failed
> >
> > Best,
> >
> > Rafael