Hello Andreas, > I think the way to finalise libsonlib would be to find out whether > there are any sensible binaries in /usr/bin and leave these (if > they are not just tests) and may be write some manpage (using > help2man - no real effort to write it manually!) None of these binaries are useful other than for the context of the test suite (that gets invoked by dh_auto_test). Tests as these are also denoted within a variable in C/Makefile called "testProgs". They get linked to cuTest.a (which gets installed under /usr/lib although I found out that marginphase's test suite uses cuTest.a too so removing it might not be suitable in this case). > I stopped for the reason that my original target signalalign needs a further dependency: > > https://salsa.debian.org/med-team/python-servicecourse > > This should be a proper Python Module but upstream has just thrown > three files into the root dir of the archive. > > Possibly this can be fixed by some simple setup.py to profit from > pybuild - but may be moving those files manually might be possible as > well. I simply stoped here and since my final target signalalign > seemed to complex I left sonlib as well since I was not sure whether > the packaging finally works that way. Ahh, I see. A bit of a nuisance :/. > If you have some other target that needs libsonlib it would make > perfectly sense to continue that effort and check whether that > target builds with the current libsonlib - if not fix it. ;-) Thanks! Kind regards, Shayan Doust On 22/06/2020 15:12, Andreas Tille wrote: > Hi Shayan, > > you asked about the packaging status of libsonlib since you need it for > marginphase. I pushed something which somehow creates some binary > package containing some header files and a static library. > > It builds if you uncomment the building of libquicktree-dev[1] > (or just checkout commit fe426a6598742190616d848b8a06773b570106f1) > > However, the libsonlib packaging is not yet "sensible" in the > following ways: > > 1. There are installed some binaries under /usr/bin which seem to be tests only. > > While the build time test works the autopkgtest is just a pure > boilerplate == non-functional. > > I think the way to finalise libsonlib would be to find out whether > there are any sensible binaries in /usr/bin and leave these (if > they are not just tests) and may be write some manpage (using > help2man - no real effort to write it manually!) > > 2. Inside the autopkgtest reproduce compiling the test tools and run > the tests. > > > I stopped for the reason that my original target signalalign needs a further dependency: > > https://salsa.debian.org/med-team/python-servicecourse > > This should be a proper Python Module but upstream has just thrown > three files into the root dir of the archive. > > Possibly this can be fixed by some simple setup.py to profit from > pybuild - but may be moving those files manually might be possible as > well. I simply stoped here and since my final target signalalign > seemed to complex I left sonlib as well since I was not sure whether > the packaging finally works that way. > > > If you have some other target that needs libsonlib it would make > perfectly sense to continue that effort and check whether that > target builds with the current libsonlib - if not fix it. ;-) > > Kind regards > > Andreas. > > > [1] https://salsa.debian.org/med-team/quicktree >
Attachment:
0x6D7D441919D02395.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature