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

Re: [MoM] simka package status and bedops



Hello Andreas,

> Uploaded.  I ignored the mathjax privacy lintian issue for the moment -
> to lazy to track this down this time.  A nice feature for the package
> would be if we could finally get rid of the cshell dependency.  I checked
> one of the scripts and these are *really* cshell scripts (not just one
> where upstream simply has put its favourite shell into the shebang line).

:). For sure, it's something to look at and make redundant.

> For simka my build fails:

Uh oh. I assume you ran this through sid pbuilder as I reproduced this.
This happens with the upstream clone too. What is weird is that it only
seems to affect pbuilder from what I have tested, and my initial
packaging environment of buster runs successfully. I am not sure if this
is a pbuilder limitation with addresses or if this is compiler specific.

I assume that it could be a permissive compiler flag doing this but I am
not too sure. I will see what I can do.

Kind regards,
Shayan Doust

On 16/09/2019 09:37, Andreas Tille wrote:
> Hi Shayan,
> 
> On Sun, Sep 15, 2019 at 03:09:59PM +0100, hello@shayandoust.me wrote:
>>
>> For bedops[1], I have converted python2 to python3. I also put together an autopkgtest to which runs successfully although there is a slight upstream issue with the final test which is expected to "fail" but "passes" resulting in an error code. I've just enforced this as true as the tests are still successful for the majority of things.
> 
> Uploaded.  I ignored the mathjax privacy lintian issue for the moment -
> to lazy to track this down this time.  A nice feature for the package
> would be if we could finally get rid of the cshell dependency.  I checked
> one of the scripts and these are *really* cshell scripts (not just one
> where upstream simply has put its favourite shell into the shebang line).
> 
> Thanks a lot - its uploaded.
>  
>> For simka, this is a software that contains a subproject called simkamin within the same repository. I have hence split off simka and simkamin as two packages. Their differences are that simkamin uses a rough approximation and runs on a greater significance which uses less resources and executes quicker than simka itself. I am not sure if simka and simkamin are dependent to each other but I will test this. If you could inspect the package[2] for feedback, that would be great.
> 
> For simka my build fails:
> 
> ...
> In file included from /build/simka-1.5.1/src/SimkaPotara.cpp:21:
> /build/simka-1.5.1/src/SimkaPotara.hpp: In instantiation of ‘void SimkaPotaraAlgorithm<span>::count() [with long unsigned int span = 32]’:
> /build/simka-1.5.1/src/SimkaPotara.hpp:263:3:   required from ‘void SimkaPotaraAlgorithm<span>::execute() [with long unsigned int span = 32]’
> /build/simka-1.5.1/src/SimkaPotara.cpp:123:2:   required from ‘void Functor<span>::operator()(Parameter) [with long unsigned int span = 32]’
> /usr/include/gatb/tools/math/Integer.hpp:463:47:   required from ‘static void gatb::core::tools::math::IntegerTemplate<IntegerList>::Apply<Functor, Parameter, T, false>::execute(size_t, Parameter) [with        Functor = Functor; Parameter = Parameter; T = boost::mpl::vector4<mpl_::int_<32>, mpl_::int_<64>, mpl_::int_<96>, mpl_::int_<128> >; IntegerList = boost::mpl::vector4<mpl_::int_<32>, mpl_::int_<64>, mpl_::     int_<96>, mpl_::int_<128> >; size_t = long unsigned int]’
> /usr/include/gatb/tools/math/Integer.hpp:84:71:   required from ‘static void gatb::core::tools::math::IntegerTemplate<IntegerList>::apply(size_t, Parameter) [with Functor = Functor; Parameter = Parameter;      IntegerList = boost::mpl::vector4<mpl_::int_<32>, mpl_::int_<64>, mpl_::int_<96>, mpl_::int_<128> >; size_t = long unsigned int]’
> /build/simka-1.5.1/src/SimkaPotara.cpp:140:56:   required from here
> /build/simka-1.5.1/src/SimkaPotara.hpp:905:16: error: taking address of temporary array
>   905 |       nanosleep((const struct timespec[]){{0, 100000000L}}, NULL);
>       |       ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> 
> Kind regards and thanks for your work anyway
> 
>      Andreas.
> 

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: