[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Status of libsonlib



Hello Andreas,

Some problems. Unfortunately, [https://github.com/ArtRand/sonLib] is
what is in the watch file for sonlib. The original author's library is
located here [https://github.com/benedictpaten/sonLib], which is
substantially more updated (I am going through issues of missing
references due to them not existing in the packaged version of sonLib).

I realised you traversed to this version of dependency because of
signalalign, so we hit a bit of a conflict here.

I realise you may be busy, but if you do have time, please can you check
whether the newer sonLib by benedictpaten satisfies signalalign?
Although, if not, I can always do this tomorrow.

Kind regards,
Shayan Doust



On 22/06/2020 18:07, Shayan Doust wrote:
> 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


Reply to: