Re: Simka package
Hi Shayan, On Mon, Nov 18, 2019 at 01:33:34AM +, Shayan Doust wrote: > Apologies for the heavy inactivity. Simka has some excuses [1] to which the > new bug was rectified. Additionally, there have been some build issues with > some architectures not detecting the static python files[2]. I'm not sure if > I have fixed this without trying, but maybe this is sufficient for another > upload. No need to apologize. I've uploaded after some `routine-update --force` Thanks for your work on this, Andreas. -- http://fam-tille.de
Simka package
Hello, Apologies for the heavy inactivity. Simka has some excuses [1] to which the new bug was rectified. Additionally, there have been some build issues with some architectures not detecting the static python files[2]. I'm not sure if I have fixed this without trying, but maybe this is sufficient for another upload. Kind regards, Shayan Doust [1]: https://qa.debian.org/excuses.php?package=simka [2]: https://buildd.debian.org/status/package.php?p=simka
Re: [MoM] simka package status and bedops
Hi Shayan, On Wed, Sep 18, 2019 at 09:31:26PM +0100, Shayan Doust wrote: > Thanks for the heads-up. I will use the sed alternative in the future. > > Inspecting the autopep8 output I do not see any red flags. Also, the > autopkgtest runs successfully so that should be a more concrete basis of > success. OK. I've uploaded metastudent. Thanks for your thorough work on this. Adding autopkgtest is always very welcome. > > Moreover currently I think the more valuable task is bug #905206 of > > profnet. Will you be able to have a look at this (in case you are > > comfortable with gdb a bit)? > > I will make this my next task to look at. Very cool! Thanks again for all your contributions Andreas. -- http://fam-tille.de
Re: [MoM] simka package status and bedops
Hi Shayan, On Wed, Sep 18, 2019 at 07:15:13PM +0100, Shayan Doust wrote: > In the meantime while I find a solution for FAST, I believe metastudents > patch-work is complete (autopep8 used again because upstream tabbing / > spacing). Meanwhile I have meanwhile learned that autopep8 can really do dangerous things like reordering imports: https://lists.debian.org/debian-python/2019/09/msg00086.html It really left non-functional code behind. So for me personally this program is on a black list and I rather use sed -P -i 's/\t//g' *.py to fix spacing. Can you confirm that your autopep8 call just fixed spacings and did not do anything else what might be potentially harmful? Moreover currently I think the more valuable task is bug #905206 of profnet. Will you be able to have a look at this (in case you are comfortable with gdb a bit)? Kind regards Andreas. -- http://fam-tille.de
Re: [MoM] simka package status and bedops
Hi again, > Also metastudent package migrated to python3 and some other subtle changes. Ignore this. Some spontaneous errors with the transition when testing apt installation of the package and I will fix these once I get back. Kind regards, Shayan Doust On 17/09/2019 17:35, Shayan Doust wrote: > Hello Andreas, > >> BTW, if you confirm that you do not plan any changes to fast I might >> upload this as well. Than we'll wait what users report once it has >> passed new queue. > > No changes. I assume the best people to find out are eventually upstream > interested in testing out the debian package. > > Also metastudent package migrated to python3 and some other subtle changes. > > Kind regards, > Shayan Doust > > On 17/09/2019 17:18, Andreas Tille wrote: >> Hello Shayan, >> >> On Tue, Sep 17, 2019 at 03:55:09PM +0100, Shayan Doust wrote: >>> Thanks for the recommendation. I have appended the ITP bug number to >>> changelog and seems ready. >> >> Uploaded. >> >> BTW, if you confirm that you do not plan any changes to fast I might >> upload this as well. Than we'll wait what users report once it has >> passed new queue. >> >> Kind regards >> >> Andreas. >> >> > signature.asc Description: OpenPGP digital signature
Re: [MoM] simka package status and bedops
Hello Andreas, > BTW, if you confirm that you do not plan any changes to fast I might > upload this as well. Than we'll wait what users report once it has > passed new queue. No changes. I assume the best people to find out are eventually upstream interested in testing out the debian package. Also metastudent package migrated to python3 and some other subtle changes. Kind regards, Shayan Doust On 17/09/2019 17:18, Andreas Tille wrote: > Hello Shayan, > > On Tue, Sep 17, 2019 at 03:55:09PM +0100, Shayan Doust wrote: >> Thanks for the recommendation. I have appended the ITP bug number to >> changelog and seems ready. > > Uploaded. > > BTW, if you confirm that you do not plan any changes to fast I might > upload this as well. Than we'll wait what users report once it has > passed new queue. > > Kind regards > > Andreas. > > signature.asc Description: OpenPGP digital signature
Re: [MoM] simka package status and bedops
Hello Shayan, On Tue, Sep 17, 2019 at 03:55:09PM +0100, Shayan Doust wrote: > Thanks for the recommendation. I have appended the ITP bug number to > changelog and seems ready. Uploaded. BTW, if you confirm that you do not plan any changes to fast I might upload this as well. Than we'll wait what users report once it has passed new queue. Kind regards Andreas. -- http://fam-tille.de
Re: [MoM] simka package status and bedops
On Mon, Sep 16, 2019 at 04:53:07PM +0100, Shayan Doust wrote: > Hello Andreas, > > > For the packaging result: Lintian claims duplicated short description. > > This should be probably fixed. > > Done. > > > I also noticed that the executable /usr/bin/simkaMinCore is in package > > simka (not simkamin). This looks somehow suspicious to me. Please > > check and if you realise it belongs to the other package Architecture > > needs to be set back to any. > > I know, the name itself is misleading. simkaMinCore in fact belongs to > the simka c++ project and not simkamin itself. > > Reverified this by cloning from upstream, removing simkaMin folder and > watching for binary generation. OK. > Also, do I need to file for two ITP bugs (simka and simkamin) as lintian > reports missing ITP bugs for both simka and simkamin? I think maybe that > one bug report to simka should satisfy any subprojects under the same > repository. ITPs will be files per source package. I'd recommend https://salsa.debian.org/r-pkg-team/dh-r/blob/master/scripts/itp_from_debian_dir It just does what you want. ;-) Kind regards Andreas. -- http://fam-tille.de
Re: [MoM] simka package status and bedops
Hello Andreas, > For the packaging result: Lintian claims duplicated short description. > This should be probably fixed. Done. > I also noticed that the executable /usr/bin/simkaMinCore is in package > simka (not simkamin). This looks somehow suspicious to me. Please > check and if you realise it belongs to the other package Architecture > needs to be set back to any. I know, the name itself is misleading. simkaMinCore in fact belongs to the simka c++ project and not simkamin itself. Reverified this by cloning from upstream, removing simkaMin folder and watching for binary generation. Also, do I need to file for two ITP bugs (simka and simkamin) as lintian reports missing ITP bugs for both simka and simkamin? I think maybe that one bug report to simka should satisfy any subprojects under the same repository. Kind regards, Shayan Doust On 16/09/2019 16:06, Andreas Tille wrote: > Hi Shayan, > > On Mon, Sep 16, 2019 at 03:26:28PM +0100, Shayan Doust wrote: >> I can no longer reproduce the issue and build successfully in my sid >> build server. > > I can confirm your means also works for me. :-) > > For the packaging result: Lintian claims duplicated short description. > This should be probably fixed. > > I also noticed that the executable /usr/bin/simkaMinCore is in package > simka (not simkamin). This looks somehow suspicious to me. Please > check and if you realise it belongs to the other package Architecture > needs to be set back to any. > > Since the test suite runs fine I think the package should be OK for > an upload once the two items above are OK. > > Thanks for your work on this > > Andreas. > signature.asc Description: OpenPGP digital signature
Re: [MoM] simka package status and bedops
Hi Shayan, On Mon, Sep 16, 2019 at 03:26:28PM +0100, Shayan Doust wrote: > I can no longer reproduce the issue and build successfully in my sid > build server. I can confirm your means also works for me. :-) For the packaging result: Lintian claims duplicated short description. This should be probably fixed. I also noticed that the executable /usr/bin/simkaMinCore is in package simka (not simkamin). This looks somehow suspicious to me. Please check and if you realise it belongs to the other package Architecture needs to be set back to any. Since the test suite runs fine I think the package should be OK for an upload once the two items above are OK. Thanks for your work on this Andreas. -- http://fam-tille.de
Re: [MoM] simka package status and bedops
Hello Andreas, > I guess its the newer gcc which is usuall more picky. Might be, but I read the source and managed to solve the issue by separating the arrays into their separate defined structs otherwise they're temporary and GCC doesn't seem to like this. I can no longer reproduce the issue and build successfully in my sid build server. Kind regards, Shayan Doust On 16/09/2019 10:12, Andreas Tille wrote: > On Mon, Sep 16, 2019 at 09:54:49AM +0100, Shayan Doust wrote: >> >> 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 guess its the newer gcc which is usuall more picky. > >> 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. > > :-) > > Thanks for your work anyway > > Andreas. > signature.asc Description: OpenPGP digital signature
Re: [MoM] simka package status and bedops
On Mon, Sep 16, 2019 at 09:54:49AM +0100, Shayan Doust wrote: > > 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 guess its the newer gcc which is usuall more picky. > 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. :-) Thanks for your work anyway Andreas. -- http://fam-tille.de
Re: [MoM] simka package status and bedops
Hi Shayan,
On Sun, Sep 15, 2019 at 03:09:59PM +0100, he...@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::count() [with long unsigned int span = 32]’:
/build/simka-1.5.1/src/SimkaPotara.hpp:263:3: required from ‘void
SimkaPotaraAlgorithm::execute() [with long unsigned int span = 32]’
/build/simka-1.5.1/src/SimkaPotara.cpp:123:2: required from ‘void
Functor::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::Apply::execute(size_t, Parameter) [withFunctor =
Functor; Parameter = Parameter; T = boost::mpl::vector4,
mpl_::int_<64>, mpl_::int_<96>, mpl_::int_<128> >; IntegerList =
boost::mpl::vector4, 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::apply(size_t, Parameter)
[with Functor = Functor; Parameter = Parameter; IntegerList =
boost::mpl::vector4, 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, 1L}}, NULL);
| ~^~
Kind regards and thanks for your work anyway
Andreas.
--
http://fam-tille.de
[MoM] simka package status and bedops
Hello Andreas, Just an update with regards to these two packages. 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. 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. Kind regards, Shayan Doust [1]: https://salsa.debian.org/med-team/bedops [2]: https://salsa.debian.org/med-team/simka
