Re: python-pybedtools: fixing the failing tests

2018-07-19 Thread Steffen Möller 
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.321
> < chr2 80 130 5 25 - 3.079
> < chr2 150 200 4 25 + 5.559
> ---
>> chr1 200 250 3 25 + 1.320
>> chr2 80 130 5 25 - 3.080
>> chr2 150 200 4 25 + 5.560
> fail
> coverage.t6b...3,5c3,5
> < chr1 200 250 3 25 + 1.321
> < chr2 80 130 5 25 - 3.079
> < chr2 150 200 4 25 + 5.559
> ---
>> chr1 200 250 3 25 + 1.320
>> chr2 80 130 5 25 - 3.080
>> chr2 150 200 4 25 + 5.560
> 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
>> 
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=bedtools=i386=2.27.1%2Bdfsg-2=1527025121=0
>

Re: Delly is on salsa Re: bcbio is on salsa

2018-07-19 Thread Steffen Möller 
Should we have a "dh_commonwl" tool, possibly?

This would possibly allow to prepare for some consistent post-processing
(indexing?) or other feats that we are not aware of, yet. Autogenerated
man pages come to mind. This sounds like something for our next Sprint.

Best,

Steffen

On 7/18/18 11:34 PM, Michael Crusoe wrote:
> CWL documents go in /use/share/commonwl/
>
> As
> per 
> https://www.commonwl.org/v1.0/CommandLineTool.html#Discovering_CWL_documents_on_a_local_filesystem
>
> mie., 11 iul. 2018, 10:27 Andreas Tille  > a scris:
>
> On Tue, Jul 10, 2018 at 10:41:11PM +0200, Steffen Möller wrote:
> > Delly is on the TODO list for bcbio (next to a few other tools
> that may
> > be of interest to us). The packaging is lintian-clean and
> inspectable on
> > https://salsa.debian.org/med-team/delly. I would not mind a
> review and
> > if that individual can upload - please ;o)
>
> I've fixed
>
> I: delly source: quilt-patch-missing-description
> minimal_makefile.patch
>
> and uploaded.
>
> > Delly ships with a cwl description of itself. I found that
> remarkable.
> > Do we have a policy where to store these files? I forgot. Michael?
>
> Good question.  May be this should be documented in some README.Debian
> of cwl package (or some better place?)
>
> > Also interesting is the Dockerfile it ships. Somehow we need to
> do a bit
> > more of marketing for all the -dev packages we offer also for
> biological
> > software.
>
> Feel free to do so. :-)
>
> Kind regards
>
>      Andreas.
>
> -- 
> http://fam-tille.de
>

Re: Who will go to DebConf 18 in Taiwan?

2018-07-19 Thread Steffen Möller 


On 7/19/18 8:02 PM, Olivier Sallou wrote:
> - Andreas Tille  a écrit :
>> Hi,
>>
>> I'll be there.  Who else from the team?
> Won't be there sorry
Me neither.
>> A Debian Med BoF with life stream is scheduled
>>
>> https://debconf18.debconf.org/talks/39-debian-med-bof/
>>
>> Looking forward to see you there or in IRC.

Ping me if you like me to contribute slides or so.

Cheers,

Steffen

Re: Who will go to DebConf 18 in Taiwan?

2018-07-19 Thread Olivier Sallou 


- Andreas Tille  a écrit :
> Hi,
> 
> I'll be there.  Who else from the team?
Won't be there sorry
> 
> A Debian Med BoF with life stream is scheduled
> 
> https://debconf18.debconf.org/talks/39-debian-med-bof/
> 
> Looking forward to see you there or in IRC.
> 
> Kind regards
> 
>Andreas.
> 
> 
> -- 
> http://fam-tille.de
>

Re: Please clarify relation of code copy of daligner and dazzdb in package pbdagcon

2018-07-19 Thread Afif Elghraoui 
Hi, Andreas

On July 19, 2018 5:36:15 AM EDT, Andreas Tille  wrote:
>Hi Afif,
>
>in my attempt to fix Vcs-fields and other issues in packages that were
>not uploaded a long time I stumbled upon pbdagcon[1].  In my latest
>commit[2] I managed to convert d/watch to git mode.  However, git mode
>does not support submodules and thus the dirs DALIGNER and DAZZ_DB are
>not included into the fetched upstream source tarball.  This could mean
>we need to keep the get-orig-source script.
>
>However, I've checked these submodules[3] and realised that these are
>outdated versions of the packaged code inside daligner and dazzdb[4].
>The upstream author just moved to a different repository and has left
>[3] alone which means pbdagcon is using outdated code.  Is there any
>good reason to keep this situation (like incompatibilities with new
>code
>etc.)?
>

One of pbdagcon's binaries (dazcon) needs that code to build. Anyway, the 
included daligner/dazzdb code [3] was modified from the original [4] and is not 
just an exact copy of an older verion.

regards
Afif

>
>[1] https://salsa.debian.org/med-team/pbdagcon
>[2]
>https://salsa.debian.org/med-team/pbdagcon/commit/439fc65a84f142570223a477914d403ece9f2354
>[3] https://github.com/PacificBiosciences/DALIGNER
>https://github.com/PacificBiosciences/DAZZ_DB
>[4] https://github.com/thegenemyers/DALIGNER
>https://github.com/thegenemyers/DAZZ_DB
>
>-- 
>http://fam-tille.de

Who will go to DebConf 18 in Taiwan?

2018-07-19 Thread Andreas Tille 
Hi,

I'll be there.  Who else from the team?

A Debian Med BoF with life stream is scheduled

https://debconf18.debconf.org/talks/39-debian-med-bof/

Looking forward to see you there or in IRC.

Kind regards

   Andreas.


-- 
http://fam-tille.de

Please clarify relation of code copy of daligner and dazzdb in package pbdagcon

2018-07-19 Thread Andreas Tille 
Hi Afif,

in my attempt to fix Vcs-fields and other issues in packages that were
not uploaded a long time I stumbled upon pbdagcon[1].  In my latest
commit[2] I managed to convert d/watch to git mode.  However, git mode
does not support submodules and thus the dirs DALIGNER and DAZZ_DB are
not included into the fetched upstream source tarball.  This could mean
we need to keep the get-orig-source script.

However, I've checked these submodules[3] and realised that these are
outdated versions of the packaged code inside daligner and dazzdb[4].
The upstream author just moved to a different repository and has left
[3] alone which means pbdagcon is using outdated code.  Is there any
good reason to keep this situation (like incompatibilities with new code
etc.)?

Kind regards

   Andreas.

[1] https://salsa.debian.org/med-team/pbdagcon
[2] 
https://salsa.debian.org/med-team/pbdagcon/commit/439fc65a84f142570223a477914d403ece9f2354
[3] https://github.com/PacificBiosciences/DALIGNER
https://github.com/PacificBiosciences/DAZZ_DB
[4] https://github.com/thegenemyers/DALIGNER
https://github.com/thegenemyers/DAZZ_DB

-- 
http://fam-tille.de