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

Re: pll-modules tests failing



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 <andreas@an3as.eu> 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

Reply to: