Hi, I've committed a few changes to 2to3.patch along with a test.patch file that I used to try and debug this. It reports the following errors while running test/runtest.py:
obj/binary/binary-random: error while loading shared libraries: libpll_binary.so.0: cannot open shared object file: No such file or directory obj/optimize/blopt-5states: error while loading shared libraries: libpll_optimize.so.0: cannot open shared object file: No such file or directory obj/tree/parsimony-tree: error while loading shared libraries: libpll_tree.so.0: cannot open shared object file: No such file or directory Any ideas about this? Regards, Pranav On Mon, Jun 8, 2020 at 3:21 PM Andreas Tille <[email protected]> wrote: > Hi Shayan, > > On Sun, Jun 07, 2020 at 07:00:01PM +0100, Shayan Doust wrote: > > I am having some issues with pll-modules[1], more specifically its test. > > The test is ran during the build process but unfortunately displays all > > unit tests as "fail" when using python3. However, using python2, only a > > very few out of the many unit test pass. > > > > I have a feeling some binaries are not getting invoked properly (run > > time for all the failed unit tests are identical (3 ms) whereas passed > > unit tests (when executing it via python2 as an experiment) take a good > > few hundred milliseconds to execute). > > > > Note that I have generated a 2to3 patch for runtest.py. > > > > Any help with this package is much appreciated as I'm not sure what is > > going wrong with the supplied test/runtest.py. > > I'm a bit occupied with other things this week so I wonder whether Nilesh > or Pranav will be able to have a look. > > Just one unrelated comment on your commit > 1d1c5c9f0486a9dfd19c772e28d68fcf430bec9b with the description: > > Add shlibs depends for libpll-modules-examples as these binaries rely > on dynamic linkage > > The original idea of these examples packages is to ship just the example > code and may be the source code and a build command / makefile. Since > libpll is a development library we want to test the *development* > process. Shipping readily build code does not really test whether the > development process with the installed library is working. Thus I'd > recommend to make sure the package is Arch: all and no Depends:shlibs > is needed and build the testing code instead. > > Kind regards and thanks for working on this package > > Andreas. > > -- > http://fam-tille.de > ᐧ
