Re: python-pybedtools: fixing the failing tests
Hello,
On 7/17/18 8:52 PM, Andreas Tille wrote:
...
>> You are right: I got the
>> same errors after installing sid. The problem is that there are two
>> different versions of bedtools (2.26 in buster and 2.27 in sid).
>> Pybedtools' upstream is aware about the differences [1] and going to
>> update tests in the future. What can we do in this situation?
> We need to support the version in sid since we upload to sid - and for
> sure we need to deal with the reasons that 2.27 does not migrate to
> testing.
Sigh. Well done, Liubov.
> I admit I'd be delighted if more members of the Debian Med team would
> spent some time on this kind of QA work since it is very hard to keep
> track of all this more or less alone (this is not addressed to newbie's
> like Liubov but to those readers of this list who think they profit from
> a working software ecosystem for life sciences and want to keep it in
> that quality).
I am not sure about what my opinion is on this all. If I got this right
then there is an API change in bedtools that affects its Python wrapper.
Am I right? https://github.com/arq5x/bedtools2/issues/607
If so, then we should consider to introduce a package bedtools2.26 that
provides bedtools in its previous form and have pybedtools depend on that.
Actually, it was that issue that led to the removal of pybedtools from the
distribution.
>
> Regarding bedtools its also mostly a test issue. For instance looking
> at the build log for i386[2] there are quite some rounding issues like:
>
> ...
> coverage.t6...3,5c3,5
> < chr1 200 250 3 25 + 1.3200001
> < chr2 80 130 5 25 - 3.0799999
> < chr2 150 200 4 25 + 5.5599999
> ---
>> chr1 200 250 3 25 + 1.3200000
>> chr2 80 130 5 25 - 3.0800000
>> chr2 150 200 4 25 + 5.5600000
> fail
> coverage.t6b...3,5c3,5
> < chr1 200 250 3 25 + 1.3200001
> < chr2 80 130 5 25 - 3.0799999
> < chr2 150 200 4 25 + 5.5599999
> ---
>> chr1 200 250 3 25 + 1.3200000
>> chr2 80 130 5 25 - 3.0800000
>> chr2 150 200 4 25 + 5.5600000
> fail
> coverage.t7...ok
> ...
>
>
> but there is also something that might need investigation:
>
>
> ...
> intersect.t52...1,2d0
> < chr1 10 12 a1 1 +
> < chr2 10 12 a2 1 -
> fail
> intersect.t53...ok
> ...
>
>
> We need more people checking those issues and put testing migration of
> packages on their agenda since we are not always in the comfortable
> situation to throw things like this on the table of an Outreachy
> student.
While I agree, I also do not see these people. All we can do IMHO is to
have more tests and report problems to upstream.
> It should also be discussed whether it is really worth
> supporting other architectures than amd64 - but that should be some team
> decision.
You mean that we increase the complexity of tests and upstream will not
care when this is not about amd64. Hm. Right.
>
>
> But now back to Liubov's mail ...
>
>>> I wonder if it might be
>>> a good idea to implement some generic way to run the build
>>> time test as autopkgtest. This could solve the issue for
>>> several Python packages.
>> I would like to think about it someday!
> That would be probably very helpful
So, many, many, many thanks to Liubov for hunting this down for us.
As said above, my reaction for now would be to downgrade bedtools.
Please direct me with whatever you think is right. If we are really
nice, then we backport the change to the Makefile that is reported
in the changelog of bedtools.
Cheers,
Steffen
>> [1] https://github.com/daler/pybedtools/pull/234
>> <https://github.com/arq5x/bedtools2/issues/607>
> [2] https://buildd.debian.org/status/fetch.php?pkg=bedtools&arch=i386&ver=2.27.1%2Bdfsg-2&stamp=1527025121&raw=0
>
Reply to: