Re: Wham aligner package name - just wham? wham-align?

[Afif Elghraoui]

Hello,

On May 30, 2019 5:51:05 AM EDT, Sascha Steinbiss  wrote:
>
>Hi Steffen,
>
>> I have no exact idea why alignment tools are all given such short
>names.
>> We have http://last.cbrc.jp/ as last-align with is. Should I do the
>same
>> for wham and name the package wham-align? 
>
>That's what I did for lambda [1] and lambda2 [2] as well. Keeps the
>namespace clean and users can still search for the name and pick the
>correct one.
>

I think that, especially if the package provides an executable named `wham`, 
the package should also be called just that. Someone might not bother searching 
and just directly try `apt install wham`.

>> I am not aware of any particular naming conflict.
>
>Not yet... ;)
>

If you're taking /usr/bin/wham already, why leave that package name available?

regards
Afif

Re: Co-mentors for Outreachy / GSoC urgently needed

[Afif Elghraoui]

Hi, Andreas

On May 6, 2019 10:48:07 AM EDT, Andreas Tille  wrote:
>Hi folks,
>
>as you might have noticed I have registered
>
>https://wiki.debian.org/SummerOfCode2019/Projects#SummerOfCode2019.2FApprovedProjects.2FCIforDebianMed.Continuous_Integration_for_biological_applications_inside_Debian
>
>It turned out that we have two promising students that could be
>accepted
>(and I really want to mentor both students).  However Debian Outreachy
>organisers insist on a 2:1 mentor to student ratio.  While Liubov
>volunteered to co-mentor we need to have two further co-mentors.  I
>estimate there is not much work to be done but it would really help if
>we could add two further names in **the** **next** **couple** **of**
>**hours**.
>

I'd like to volunteer if it's not a problem given my limited recent activity 
level in Debian Med. :)

>Thanks for volunteering
>

regards
Afif

Re: Uploaders orphaning packages / Conda (Was: Bug#921382: kineticstools: autopkgtest needs update for new version of h5py)

[Afif Elghraoui]

Hello,

على ٣٠‏/٥‏/١٤٤٠ هـ ‫٢:١٦ ص، كتب Andreas Tille:
> Hi Afif,
> 
> please lets move this to the list  I guess it is fine to quote your
> non-privat text here.

Fine with me.

> 
> On Tue, Feb 05, 2019 at 01:03:26AM -0500, Afif Elghraoui wrote:
>>
>> The
>> problem is I'm not sure how filing an RFA or orphaning a package works
>> within a team. I think what I should have done in the beginning is send
>> out a message on the debian-med list asking for someone to take over and
>> then formally orphan/remove the ones that didn't get adopted.
> 
> You could start with removing yourself as Uploader which is a clear sign
> that you will not work on this any more.

Can do.

>  I might consider adding myself
> to make sure we have at least one uploader in the team.  I do not see
> any reason to remove packages that are functional and not RC buggy (over
> several releases).
> 

Ok

>>>  I remember you
>>> said you are not using these any more but the same is true for me - I
>>> never ever used any of those packages and I spent a lot of time on these
>>> anyway>  I wonder whether you might be able to become active and deal
>>> with the issues on the packages where you are in the Uploaders field.
>>
>> I don't think you should spend time on the packages you have no interest
>> in, either.
> 
> What means "interest"?  If it is I should not spend time on packages I'm
> not using for my own work I can leave Debian Med since I'm not using a
> single one.  As a Debian maintainer I want to provide a useful system
> for my colleagues and the motivation to maintain also packages that are
> not used here is to possibly attract even more people to join the
> effort.  This attraction of people has worked to some extend (way better
> than in other teams but admittedly I was hoping for more active
> contributors).

Ok, that's another form of interest. My original interest was personal,
with the willingness to share work I was going to be doing for myself
anyway. Yours is a little bit different.

> 
>> What I would be willing to do is file for removal of the
>> packages where I'm listed as the sole uploader.
> 
> I do not think that we should remove packages with some popcon users
> that are not RC buggy.
>  

Ok

>> Even if I was still using the packages, it is much less motivating to
>> maintainer Debian packages for scientific software than something
>> vendor-neutral and user-installable like conda, which has become very
>> popular in bioinformatics. In fact, all these PacBio packages that I had
>> created for Debian are now packaged in conda by upstream itself.
> 
> Honestly, I think the conda-hype has some positive effects also for our
> packaging.  I realised that upstreams learned that release tags are a
> good idea, responding to issues of packagers is more frequent and so on.
> IMHO software that is fit for Conda packaging has increased chances to
> be not hard to package for Debian as well.

Sure.

>  I do not see Conda as a pure
> competitor to our efforts since there are also different areas where the
> different packaging efforts are differently suited.

I think it is a pure competitor for the bioinformatics packages; at
least the ones I worked on.

>  However, by all
> means we should force the effort to package the Conda tools themselves
> in any case.
>

I gave conda as an example. It has problems of its own, like unbearable
sluggishness [1,2], but the general idea of cross-platform, unprivileged
package management is what appeals to scientists.

regards
Afif


1. https://github.com/conda/conda/issues/7700
2. https://github.com/conda/conda/issues/7938

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Competing arrow tools in pbgenomicconsensus and unanimity

[Afif Elghraoui]

On October 11, 2018 11:14:35 AM EDT, Andreas Tille  wrote:
>Hi Afif,
>
>On Thu, Oct 11, 2018 at 09:27:16AM -0400, Afif Elghraoui wrote:
>> >
>> >#!/bin/sh
>> >variantCaller --algorithm=arrow $*
>> >
>> >while unanimity installs a compiled binary.  @Afif (or whoever is
>> >informed about this PB programs):  Do you have a sensible suggestion
>> >which arrow we should install?
>> >
>> 
>> At one point, I had read that unanimity was eventually going to
>supersede pbgenomicconsensus altogether. Looking at the source tree
>[3], it looks like genomicconsensus in unanimity is still marked
>experimental, so I would stick with pbgenomicconsensus' implementation.
>> 
>> As for the name, "arrow" succeeds "quiver", so there's a little theme
>going on. And quiver had some meaning as a Quality Value-aware variant
>caller.
>
>My conclusion from your answer is that it makes sense to ship arrow
>from
>unanimity while removing the little wrapper from pbgenomicconsensus.
>This can be explained in d/NEWS.Debian.
>
>Do you agree with this conclusion?
>

No, that's the opposite of what I said. The unanimity implementation looks like 
it's still experimental.

Afif

Re: Competing arrow tools in pbgenomicconsensus and unanimity

[Afif Elghraoui]

Hello,

On October 11, 2018 8:06:26 AM EDT, Andreas Tille  wrote:
>Hi,
>
>package unanimity[1] now builds and creates the binary package
>python-consensuscore2 which in turn is needed to build the latest
>version of pbgenomicconsensus[2].  I realised that both packages are
>installing a tool /usr/bin/arrow (shame on upstream for this generic
>name ;-)).  In pbgenomicconsensus its a simple script
>
>#!/bin/sh
>variantCaller --algorithm=arrow $*
>
>while unanimity installs a compiled binary.  @Afif (or whoever is
>informed about this PB programs):  Do you have a sensible suggestion
>which arrow we should install?
>

At one point, I had read that unanimity was eventually going to supersede 
pbgenomicconsensus altogether. Looking at the source tree [3], it looks like 
genomicconsensus in unanimity is still marked experimental, so I would stick 
with pbgenomicconsensus' implementation.

As for the name, "arrow" succeeds "quiver", so there's a little theme going on. 
And quiver had some meaning as a Quality Value-aware variant caller.

regards
Afif

>
>
>[1] https://salsa.debian.org/med-team/unanimity
>[2] https://salsa.debian.org/med-team/pbgenomicconsensus
[3] https://github.com/PacificBiosciences/unanimity/tree/develop/src

Re: Please consider a free license for tRNAscan-SE

[Afif Elghraoui]

Hi, all
There's still a problem with the bundled src/dbmalloc.h. I had emailed about 
this before--the summary is that I had tracked down the author of this file and 
he agreed to distribute it under the MIT license.

I had forwarded the correspondence with to you privately (since I don't think 
he wanted his email address revealed in public), so it would be best if you 
could update the license terms in that file's header as well when you make your 
next release.

If you need me to resend my previous message, please let me know.

Thanks and regards
Afif

On September 25, 2018 1:41:30 AM EDT, Andreas Tille  
wrote:
>Hi Todd,
>
>thanks a lot.  We'll try to package this new version as soon as it will
>be released (you might like to ping here if you want to make sure).
>
>Kind regards
>
>   Andreas.
>
>On Tue, Sep 25, 2018 at 03:46:29AM +0200, Todd Lowe wrote:
>> Hi Andreas,
>> 
>> Ok, we’ll GPL the next version — should be out in a month or so (with
>manual!!).
>> 
>> Best,
>> Todd
>> 
>> > On Aug 5, 2018, at 3:54 AM, Andreas Tille  wrote:
>> > 
>> > Hello,
>> > 
>> > I'm writing you on behalf of the Debian Med team which is a group
>inside
>> > Debian with the objective to package all free software that is used
>in
>> > medicine and life sciences for official Debian.  You might possibly
>know
>> > that also tRNAscan-SE is packaged[1].
>> > 
>> > Unfortunately the trnascan-se package does not belong to the
>official
>> > Debian distribution since this is not permitted by the licences of
>the
>> > single file src/trnascan.c has a license that has restrictions
>which are
>> > in conflict with the Debian Free Software Guidelines[2].  The
>"without
>> > charge" restriction moves the software out of any distribution
>medium a
>> > vendor might want to sell to users[item no. 1].  Its also lacking
>an
>> > explicit permission to modify the software.
>> > 
>> > It would be really nice if you would consider using some of the
>well
>> > established free licenses like GPL or BSD to enable us to provide
>> > tRNAscan-SE in official Debian.
>> > 
>> > Thanks for considering
>> > 
>> > Andreas.
>> > 
>> > [1] https://blends.debian.org/med/tasks/bio#trnascan-se
>> > [2] https://www.debian.org/social_contract#guidelines
>> > 
>> > -- 
>> > http://fam-tille.de
>> 
>
>-- 
>http://fam-tille.de

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

[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

Please allow smalr to migrate to testing

[Afif Elghraoui]

Hello,

We have one more case of an arch:all package held up in testing because
of installability issues on i386 due to a dependency on bwa. Can smalr
be allowed to migrate to Testing?

  https://qa.debian.org/excuses.php?package=smalr

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Removed duplicated / outdated repositories kmer-tools, falconkit

[Afif Elghraoui]

On April 2, 2018 5:19:36 PM EDT, Andreas Tille  wrote:
>Hi,
>
>when trying to fix UDD importer I stumbled upon duplicated repositories
>on salsa.  I removed the duplicates leaving the repository name
>matching
>the source package name.  I deleted
>
>   kmer-tools (and left the duplicate kmer)
>   falconkit (and left the more up to date falcon)
>

Great. Those two had their source packages renamed a while back. I had put 
symlinks on alioth to avoid breaking the VCS links in versions of the packages 
under the old names, but that shouldn't be a concern anymore since all 
available packages now should be referencing the current name.

regards
Afif

Re: Ensembl-core and ensembl-tools repositories on Salsa are empty

[Afif Elghraoui]

On March 13, 2018 1:28:49 PM EDT, Andreas Tille <andr...@an3as.eu> wrote:
>Hi Afif,
>
>On Tue, Mar 13, 2018 at 09:34:41AM -0400, Afif Elghraoui wrote:
>> >It seems these can be deleted since they never had any purpose on
>> >Alioth.  However, if you think that's a problem of the migration
>please
>> >be more verbose what you consider the problem for the empty results
>on
>> >Salsa.
>> >
>> 
>> Go ahead. I had wanted to package VEP,
>
>What is VEP?

It's an ensembl tool--variant effect predictor. It used to be in ensembl-tools, 
but now has its own upstream repository.

>
>> but didn't want to have to package and maintain Ensembl, so gave up
>there.
>
>OK, I've deleted the two empty repositories.  BTW, we had an ensembl
>package in Debian before and there is an non-empty but outdated
>repository[1].
>
>Kind regards
>
>  Andreas.
>
>PS: As a non-related issue:  I've just spent some time to build
>simpleitk
>and will do a source upload soon (just to prevent a race condizion).
>

Ok, thanks for letting me know.

regards
Afif

>[1] https://salsa.debian.org/med-team/ensembl

Re: Ensembl-core and ensembl-tools repositories on Salsa are empty

[Afif Elghraoui]

Hi, Andreas,

On March 13, 2018 4:20:23 AM EDT, Andreas Tille  wrote:
>Hi Afif,
>
>I'm currently busy to rewrite the Blends metadata gatherer to check the
>repositories on Salsa.  This seems to be a sensible check whether the
>migration from Alioth went properly.  So I have spotted some broken
>repositories but I'm think that these were even broken on Alioth in the
>first place.  Can you please check
>
>https://salsa.debian.org/med-team/ensembl-core
>and
>https://salsa.debian.org/med-team/ensembl-tools
>
>It seems these can be deleted since they never had any purpose on
>Alioth.  However, if you think that's a problem of the migration please
>be more verbose what you consider the problem for the empty results on
>Salsa.
>

Go ahead. I had wanted to package VEP, but didn't want to have to package and 
maintain Ensembl, so gave up there.

Afif

Re: RFS: simpleitk/1.0.1-2

[Afif Elghraoui]

على الأحد 11 آذار 2018 ‫16:04، كتب Afif Elghraoui:
> 
> 
> على الأحد 11 آذار 2018 ‫14:04، كتب Ghislain Vaillant:
>> Could someone upload simpleitk/1.0.1-2 [1], please?
> 
> I'll get it.
> 

I'm getting this lintian error:

E: simpleitk source: missing-notice-file-for-apache-license NOTICE
N:
N:The package appears to be licensed under the Apache 2.0 license and a
N:NOTICE file (or similar) exists in the source tree. However, no files
N:called NOTICE or NOTICE.txt are installed in any of the binary
packages.
N:
N:The Apache 2.0 license requires distributing of such files:
N:
N: (d) If the Work includes a "NOTICE" text file as part of its
N: distribution, then any Derivative Works that You distribute must
N: include a readable copy of the attribution notices contained
N: within such NOTICE file [..]
N:
N:Please include the file in your package, for example by adding
N:path/to/NOTICE to a debian/package.docs file.
N:
N:Refer to /usr/share/common-licenses/Apache-2.0 for details.
N:
N:Severity: serious, Certainty: possible
N:
N:Check: source-copyright, Type: source
N:

Since the source hasn't changed, this must have been detected by new
lintian rules. Can you please take a look?

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: RFS: simpleitk/1.0.1-2

[Afif Elghraoui]

على الأحد 11 آذار 2018 ‫14:04، كتب Ghislain Vaillant:
> Could someone upload simpleitk/1.0.1-2 [1], please?

I'll get it.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Fw: Bug#890112: ITP: porechop -- adapter trimmer for Oxford Nanopore reads

[Afif Elghraoui]

Hi, Cedric,

على الأحد 11 شباط 2018 ‫13:07، كتب Cédric Lood:
> fyi - forgot to cc: the list
> 

The owner automatically gets a copy, so now we got two :).

By the way, setting the owner to
debian-med-packag...@lists.alioth.debian.org is marginally better, since
that's the address we use for the Maintainer field and then all the BTS
interaction is with the same address. Not really a big deal in any case;
Others have put debian-med@l.d.o in Owner in the past.

Thanks for all your work

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Salsa migration of Debian Med team packages

[Afif Elghraoui]

على الأحد 11 شباط 2018 ‫13:22، كتب Sascha Steinbiss:
> Done. The first two are indeed very useful and now active on all current
> projects in the med-team space. I have also added email-on-push
> notifications to the traditional mailing list [1] on request of the
> sprinters.
> 

Many thanks, Sascha!

> Do we also want the automatic tag-pending assignment hook?

I would say so. I think the only reason we didn't have them before was
that nobody got around to adding it.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [git...@salsa.debian.org: Access to the Debian Med group was granted]

[Afif Elghraoui]

Hi, Andreas

On February 9, 2018 12:27:33 PM EST, Andreas Tille  wrote:
>Hi,
>
>I just createt the Debian Med team on Salsa to start the migration of
>our packages.
>
>Kind regards
>
>   Andreas.
>
>- Forwarded message from Debian GitLab 
>-
>
>Date: Fri, 09 Feb 2018 17:22:23 +
>From: Debian GitLab 
>To: ti...@debian.org
>Subject: Access to the Debian Med group was granted
>
>You have been granted Owner access to the Debian Med group.
>
>https://salsa.debian.org/groups/debian-med-team
>

Would it make sense to put it as just "med-team" to be consistent with how 
Debian Science and probably others are naming their groups on salsa?

regards
Afif

Re: RFS: dcm2niix/1.0.20171215-1

[Afif Elghraoui]

على الأحد  4 شباط 2018 ‫09:40، كتب Ghislain Vaillant:
> Hi team,
> 
> Could someone sponsor this update for dcm2niix [1]? Nothing much to
> report besides an update to the latest upstream release and version
> bumping for debhelper and standards.
> 
> It's already pushed and tagged to the packaging repository and has been
> validated on debomatic.
> 

Done.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: removing tophat from Debian

[Afif Elghraoui]

على الخميس 21 كانون الأول 2017 ‫08:10، كتب Steffen Möller:
> So, what could justify a deprecated piece of software in Debian. To mind 
> come:
> 
>   * an API change
>   * a well-established tutorial that was not yet updated

These two points can be summarized as inertia. I really try to avoid
accomodating that situation by keeping around deprecated
software--either I'd update the reverse-dependency to use the current
CLI/API myself, or leave it to upstream, otherwise keep it out of the
archive.

>   * historic landmarks achieved by that software that one wants to 
> compare new developments against

So should we also package something like the old Celera assembler
(wgs-assembler) despite it's being unmaintained and obsolete?

>   * pop-con

I wouldn't consider this reliable because, as the tophat developer
indicated, the program is still widely used despite being obsolete. I
think this is also because of inertia.

> 
> I have difficulties with the role of our distribution as some kind of 
> package-value police. My personal
> threshold for sponsoring is a peer-reviewed publication.

Here, you're already setting a package-value criterion.

> But I like the 
> role of our distribution as a communicator.
> And we should indeed collect ideas on how to spread the news on a better 
> alternative - any clear cut
> improvals are rare enough, though.
> 
> If upstream explicitly asks for a removal from our distribution, then I 
> am still hesitating. Do they also
> retract their publication? Most likely not since at some point in 
> history that previous version was just
> fine. It is a document that we do not want to lose. The same for the 
> software of that time. And I argue
> that I do not want to lose the package, either. I am afraid that when we 
> have it in snapshot.d.o, one or two
> releases down the road, the package will be forgotten. We would need 
> something in our task pages,
> then, to point to it, I suggest.

I think this is a good point, and valid for any Debian package. It's not
really trivial (at least as far as I know) to find out whether a package
used to be in Debian. I've always done it by URL hacking, trying
packages.debian.org/ and finding the package
history and finally the RoM bug report.

In any case, as far as tophat goes, I think the only reason we have a
problem here is because upstream renamed the program. If hisat is the
continuation of tophat and they just made tophat 3.x and 4.x, we'd right
now have the latest in the archive and the older versions would be in
snapshot.debian.org. This is a similar situation for wgs-assembler and
it's successor, canu.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: removing tophat from Debian

[Afif Elghraoui]

On December 20, 2017 5:17:20 AM EST, Michael Crusoe <michael.cru...@gmail.com> 
wrote:
>2017-12-16 10:18 GMT+02:00 Afif Elghraoui <a...@debian.org>:
>
>> Hi, all,
>>
>> Given the statement from the website [1]
>>
>> > Please note that TopHat has entered a low maintenance, low support
>> > stage as it is now largely superseded by HISAT2 which provides the
>> > same core functionality (i.e. spliced alignment of RNA-Seq reads),
>> > in a more accurate and much more efficient way
>>
>
>This statement is about TopHat 2, which is what is in the Debian
>package
>tophat
>
>
>> and a statement from one of its co-authors [2]
>>
>> > Please stop using Tophat. Cole and I developed the
>> > method in *2008*. It was greatly improved in TopHat2 then HISAT
>> > & HISAT2. There is no reason to use it anymore. I have been
>> > saying this for years yet it has more citations this year than last
>>
>
>This more strongly worded statement is about TopHat 1, which is not in
>Debian.
>

The summary of the statement is that hisat2 is the only one of those 4 that 
isn't obsolete, and therefore that it's the only one of those 4 that should be 
used.

>We should retain TopHat2, perhaps with a note about HISAT2.
>

I think tophat2 (and hisat1 if we have it) should also be removed. We should 
get upstream involved if you still disagree.

regards
Afif

Re: removing tophat from Debian

[Afif Elghraoui]

Hello,

On December 17, 2017 8:35:21 PM EST, "Steffen Möller" <steffen_moel...@gmx.de> 
wrote:
>Hello,
>
>On 16.12.17 22:15, Andreas Tille wrote:
>> Hi Afif,
>>
>> On Sat, Dec 16, 2017 at 12:31:28PM -0800, Afif Elghraoui wrote:
>>>> Since I'm not a user of all this software I do not have any
>objections.
>>>> However, I wonder whether we should provide kind of a sensible
>>>> "migration path" and add "Replaces: tophat" to hisat2 or something
>like
>>>> this.
>>> Ack. Although I don't believe Replaces: is correct here (looking at
>Debian policy).
>> Its definitely incorrect.
>
>> However, we need to make sure that users who
>> had installed tophat get hisat2 installed.
>
>I disagree.
>
>We are packaging software, not workflows (at the very moment, mostly). 
>Anybody
>requesting tophat shall get exactly that, however unfortunate that 
>decision may be.

I understood this proposition as installing both tophat amd hisat2 while also 
giving a warning whenever running tophat.

>
>I am happy with a post-inst warning, or a debian/NEWS entry, but what 
>the user gets has to be what the user asks for.

Yes.

>
[...]
>
>>
>>> Maybe a transitional package is needed, which would have to sit
>through another stable release cycle. That would also satisfy the
>concerns about notification time that the others brought up on this
>thread.
>> After reading this thread I think the better way to go is:
>>
>> 1. tophat Depends hisat2 (solves the issue that the replacement
>>will be installed
>You may suggest hisat2, or even recommend it, but you should not depend
>
>on it. And there is no need to enforce a replacement in the first
>place.
>> 2. provide instead of /usr/bin/tophat a shell script issuing
>>a warning first before the actual tophat call
>>
>> What about this?
>
>This would undermine the trust that our users have in our packages.
>
>Please not. It is better remove the package from the archive than to 
>disturb the integrity of the package.

I don't think having a warning message disturbs the integrity of the 
package--we are not changing its functionality. In fact, adding a warning 
message might even be welcomed upstream.

>
>I propose to discuss any general policy towards such desirable package 
>substitutions at our upcoming Sprint in Barcelona.
>

I won't be there. In any case, this is probably a more general problem than one 
in bioinformatics, so would probably best be discussed on debian-devel.

regards
Afif

Re: removing tophat from Debian

[Afif Elghraoui]

Hi, Andreas,

On December 16, 2017 1:15:16 PM PST, Andreas Tille <andr...@an3as.eu> wrote:
>Hi Afif,
>
>On Sat, Dec 16, 2017 at 12:31:28PM -0800, Afif Elghraoui wrote:
>> >Since I'm not a user of all this software I do not have any
>objections.
>> >However, I wonder whether we should provide kind of a sensible
>> >"migration path" and add "Replaces: tophat" to hisat2 or something
>like
>> >this.
>> 
>> Ack. Although I don't believe Replaces: is correct here (looking at
>Debian policy).
>
>Its definitely incorrect.  However, we need to make sure that users who
>had installed tophat get hisat2 installed.
>
>> Maybe a transitional package is needed, which would have to sit
>through another stable release cycle. That would also satisfy the
>concerns about notification time that the others brought up on this
>thread.
>
>After reading this thread I think the better way to go is:
>
>   1. tophat Depends hisat2 (solves the issue that the replacement
>  will be installed
>   2. provide instead of /usr/bin/tophat a shell script issuing
>  a warning first before the actual tophat call
>
>What about this?
>

That looks like a transitional package. I'm for it.

regards
Afif

Re: removing tophat from Debian

[Afif Elghraoui]

On December 16, 2017 1:31:01 AM PST, Andreas Tille <andr...@an3as.eu> wrote:
>Hi Afif,
>
>On Sat, Dec 16, 2017 at 03:18:05AM -0500, Afif Elghraoui wrote:
>> 
>> Are there any objections?
>
>Since I'm not a user of all this software I do not have any objections.
>However, I wonder whether we should provide kind of a sensible
>"migration path" and add "Replaces: tophat" to hisat2 or something like
>this.
>

Ack. Although I don't believe Replaces: is correct here (looking at Debian 
policy). Maybe a transitional package is needed, which would have to sit 
through another stable release cycle. That would also satisfy the concerns 
about notification time that the others brought up on this thread.

regards
Afif

removing tophat from Debian

[Afif Elghraoui]

Hi, all,

Given the statement from the website [1]

> Please note that TopHat has entered a low maintenance, low support
> stage as it is now largely superseded by HISAT2 which provides the
> same core functionality (i.e. spliced alignment of RNA-Seq reads),
> in a more accurate and much more efficient way.

and a statement from one of its co-authors [2]

> Please stop using Tophat. Cole and I developed the
> method in *2008*. It was greatly improved in TopHat2 then HISAT
> & HISAT2. There is no reason to use it anymore. I have been
> saying this for years yet it has more citations this year than last

I think we'd be doing users a favor by removing it from the archive. If
in the future anyone wants to replicate old results based on tophat,
they could build a container off of snapshot.debian.org.

Are there any objections?

regards
Afif

1. https://ccb.jhu.edu/software/tophat/index.shtml
2. https://twitter.com/lpachter/status/937055346987712512

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Afif Elghraoui]

On November 9, 2017 3:06:32 AM EST, Mattia Rizzolo  wrote:
>On Wed, Nov 08, 2017 at 04:58:49PM -0800, Diane Trout wrote:
>> > > I was wondering if we should split the cram headers into a
>> > > libhts-private-dev so we can at least track what is depending on
>> > > the
>> > > non-public api.
>
>Can I recommend dealing with the public/non-public API *after* adding
>the symbols file and doing other general stuff?

+1

>
>In general, I recommend against doing dozens of (possibly hard, like in
>this case) changes in a single huge upload, let's split them out :)
>
>Upstream kindly opened #881170 to track other issues as well, perahps
>clone that bug to track all those issues separately (as they all
>require
>changes to other packages, so need to be coordinated separately, and
>need not to be done at the same time either).

Also +1
>
>
>If you find issues getting stuff sponsored, please do point me to it
>privately (I know you are on IRC, that tends to often work best for
>me).

Diane's a DD.

thanks and regards
Afif

Re: [Debian-med-packaging] Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Afif Elghraoui]

On November 9, 2017 2:32:56 AM EST, Diane Trout <di...@ghic.org> wrote:
>On Thu, 2017-11-09 at 02:03 -0500, Afif Elghraoui wrote:
>> > - TODO Split private cram headers off into a new libhts-private-dev
>> > package
>> 
>> I'd rather be in favor of restoring the bundled htslib to seqlib as
>> the short term solution. Putting a private package in the archive may
>> exacerbate the problem and is odd nevertheless.
>
>The no convenience copies of libraries is a pretty strong rule of
>Debian, and there are good maintenance reasons for it.

Yes, I understand that, but we don't have good options right now. I don't see 
the maintenance advantages for seqlib as worth requiring a transition for every 
htslib update to make sure it doesn't break--in addition to putting a package 
in the archive and telling users/developers not to install it.

> Although I'm not
>opposed to it I'd like several people to agree that its the best option
>first.
>
>On the plus side overriding it would allow us to drop the patch that is
>making the cram symbols public, on the downside we'd have to remember
>that bugs involving htslib also impact libseqlib.

If this whole situation is primarily seqlib's problem, I think it's only fair 
for it to bear the kludges required for its approach. Otherwise, we have the 
kludge in htslib and the need for a htslib transition with every update, right?

In fact, lofreq never entered Debian because it needs to use samtools as a 
library and we were not going to bundle it [1]. I felt that would be an RC bug.

>
>I think we'd need to use the Built-Using tag? I haven't used that
>before.
>
>On the other hand upstream did suggest that the private-dev library was
>a viable temporary solution. (Though doing that would push htslib into
>NEW).

Well, I think they were saying that if we were going to go so far as to 
misrepresent htslib, we should at the very least make a division and distribute 
htslib proper as such. I read that as saying anything would be better than the 
current situation--not necessarily that they're equally better.

>
>> 
>> And there is another action item--
>> TODO update the htslib package to the latest release.
>
>Very true I did try building 1.6 and there was a problem with
>running tests that I haven't investigated yet.
>

Regards
Afif

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808895

Re: [Debian-med-packaging] Bug#879886: libhts2: libhts2 needs to handle ABI changes

[Afif Elghraoui]

Hi, Diane,

Thanks for working on this.


On November 8, 2017 7:58:49 PM EST, Diane Trout  wrote:
>One of the htslib developers filed a new bug,
>
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881170
>
>asking us to not make their private libraries public. His suggestions
>are fairly similar to whats Charles proposed.
>
>What I'm thinking is:
>
>- TODO Recommit symbols file

+1

>- TODO Split private cram headers off into a new libhts-private-dev
>package

I'd rather be in favor of restoring the bundled htslib to seqlib as the short 
term solution. Putting a private package in the archive may exacerbate the 
problem and is odd nevertheless.

And there is another action item--
TODO update the htslib package to the latest release.

>- WAITING Try to talk htslib & SeqLib developers to agree on a public
>cram api so we can drop the private-dev package.
>
>
> 
>[...]
>
>> 
>> > I was wondering if we should split the cram headers into a
>> > libhts-private-dev so we can at least track what is depending on
>> > the
>> > non-public api.

We would find this out anyway because the packages woukd break until either a 
dependency on such a package had to be added (most likely by our team anyway), 
or the library had to be rebundled.

>> 
>[...]
>
>> 
>> > I did realize that my thought about updating the SOVERSION might be
>> > wrong because I was just looking in the source tree for the removed
>> > functions but I should have been checking the public header files.
>> 
>> Indeed, packages using private functions need to have a tight
>> dependency
>> on the htslib (unless we are very confident that there are regression
>> tests that cover this area of the code).  Packages that are more
>> well-behaved can infer their dependency through the (to be re-added)
>> symbols file.
>
>
>
>So that implies packaging that uses -private-dev that implies they have
>an == dependency on a specific binary version of libhts?
>
>That should probably probably be documented in a README.Debian for the
>private-dev package.
>

Does this imply a transition for each htslib update?

Many thanks and regards
Afif

Re: RFS: simpleitk/1.0.1-1 [ITP]

[Afif Elghraoui]

على الخميس  2 تشرين الثاني 2017 ‫04:59، كتب Ghislain Vaillant:
> Hi Afif, thanks for taking care of the review (and uploading dcm2niix).
>

No problem. I'm sorry I couldn't do it sooner.

> On 02/11/17 02:05, Afif Elghraoui wrote:
>> Based on the Python policy, the python3-dev build-dependency should be
>> either python3-all-dev, or specific to a minor version of python3 (like
>> python3.5-dev) [2].
> 
> Since the build system does not let me easily build against all 
> supported Python 3 versions, a dependency on python3-dev makes more 
> sense than python3-all-dev. I have seen this done many times in other 
> CMake-based build of packages.

Makes sense.

> 
>> My reading of the BuildProfileSpec wiki page suggests to me that the
>> `googletest` build dependency should be qualified as `googletest
>> `. And I'm not sure that there is need to wrap the
>> override_dh_auto_test rule to look for `nocheck` in `DEB_BUILD_OPTIONS`,
>> but I've posted a question about this to -devel [3] since I've seen
>> similar code get added to python-pysam as well [4].
> 
> You are absolutely correct. I have updated the repository accordingly.
> 
> Although guarding the override is not always superfluous, depending on 
> your build system. For pybuild or CMake though, it should not be needed.
> 

I turned out to be wrong about the guard [5], so I restored d/rules to
the way you had it before and uploaded. Even if the build system
currently in use doesn't need it, it's probably best to have it for the
sake of uniformity.

regards
Afif

>>
>> 2.
>> https://www.debian.org/doc/packaging-manuals/python-policy/build_dependencies.html
>> 3. https://lists.debian.org/debian-devel/2017/11/msg3.html
>> 4.
>> https://anonscm.debian.org/cgit/debian-med/python-pysam.git/tree/debian/rules?id=5897693255ab6a36fb69cfc5bc096c65973f5f47#n25

5. https://lists.debian.org/debian-devel/2017/11/msg5.html

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: RFS: simpleitk/1.0.1-1 [ITP]

[Afif Elghraoui]

Hi, Ghislain,

على الثلاثاء 31 تشرين الأول 2017 ‫15:04، كتب Ghislain Vaillant:
> Hi all,
> 
> Could someone from the team sponsor the initial upload for simpleitk 
> [1]. Perhaps Gert (cc'd), since he is also involved with packaging ITK?
> 

Based on the Python policy, the python3-dev build-dependency should be
either python3-all-dev, or specific to a minor version of python3 (like
python3.5-dev) [2].

My reading of the BuildProfileSpec wiki page suggests to me that the
`googletest` build dependency should be qualified as `googletest
`. And I'm not sure that there is need to wrap the
override_dh_auto_test rule to look for `nocheck` in `DEB_BUILD_OPTIONS`,
but I've posted a question about this to -devel [3] since I've seen
similar code get added to python-pysam as well [4].


Thanks and regards
Afif

> [1] https://anonscm.debian.org/cgit/debian-med/simpleitk.git
> 

2.
https://www.debian.org/doc/packaging-manuals/python-policy/build_dependencies.html
3. https://lists.debian.org/debian-devel/2017/11/msg3.html
4.
https://anonscm.debian.org/cgit/debian-med/python-pysam.git/tree/debian/rules?id=5897693255ab6a36fb69cfc5bc096c65973f5f47#n25

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Preprint about bioconda/conda package manager

[Afif Elghraoui]

Hi, all,

This just came out. It's about the bioconda project, which packages 
bioinformatics software for the cross-platform, user-managed conda package 
manager.

https://www.biorxiv.org/content/early/2017/10/21/207092

regards
Afif

Re: Sponsored upload (maybe): odil 0.8.0-4

[Afif Elghraoui]

Hi, Julien,

على الثلاثاء 17 تشرين الأول 2017 ‫05:48، كتب Julien Lamy:
> Dear all,
> I've fixed bug #878426 in the Git repository of odil (and similar
> not-yet-existing bugs for future Python transitions). I was however too
> slow and an NMU was performed a few hours ago: what is the policy
> regarding the upload to unstable in this kind of case?
> 

I would just merge the changes from the NMU into the git repository. If
the packaging changes are the same as what you already have, then just
include the changelog entry. Then make your new changes follow it.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Python-pysam 0.12 released, could someone please care?

[Afif Elghraoui]

Hi, Andreas,

On September 3, 2017 11:50:05 PM PDT, Andreas Tille  wrote:
>Hi Afif,
>
>I noticed that you commited some promising changes.  They are depending
>from bcftools 1.5 which is only in experimental.  From my point of view
>it makes sense to move bcftools 1.5 to unstable to enable building
>python-pysam in unstable as well.  Any reason to be more carefully and
>stick to experimental?
>

Well, the build is still not successful. I've filed an issue upstream for one 
set of test failures [1] and there is another test failure due to a 
segmentation fault that needs some investigation.

If I move bcftools to Unstable now, we'd need to file an RC bug against it to 
prevent its migration and breaking of the current pysam version in Testing.

regards
Afif

1. https://github.com/pysam-developers/pysam/issues/534

Re: Python-pysam 0.12 released, could someone please care?

[Afif Elghraoui]

On August 29, 2017 2:05:50 PM PDT, Andreas Tille  wrote:
>
>Could someone please care since I'm a bit offline-ish this week.
>

I'll take a look maybe tonight or tomorrow. Thanks for the ping--I hadn't been 
watching the releases.

regards
Afif

Re: CI for bamtools [Outreachy]

[Afif Elghraoui]

على الثلاثاء  8 آب 2017 ‫10:17، كتب Andreas Tille:
> Hi Nadiya,
> 
> On Mon, Aug 07, 2017 at 11:06:09AM -0700, Nadiya Sitdykova wrote:
>> test-suite for bamtools package is ready.
> 
> Thanks for working on this.
> 
> Afif, yesterday you said you are working on bamtools.  Will you take
> over the sponsoring for the package?  If not, please ping me.
> 

No, I think that was Sascha who said that (or implied it). I said I was
working on bcftools. I will go ahead and sponsor anyway.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [Help] Failed to upgrade bcftools to version 1.5

[Afif Elghraoui]

Hi, Graham,

[adding ticket log to Cc]

على الإثنين  7 آب 2017 ‫10:40، كتب Graham Inggs:
> Python-pysam 0.11.2.2+ds-3 migrated to testing on 2017-08-06, completing 
> the htslib/samtools/bcftools 1.4.1 transition.
> 
> Now htslib 1.5-1 and samtools 1.5-1 have been uploaded and python-pysam 
> FTBFS again (see #871083):
> ValueError: versions of pysam.samtools and samtools differ: 1.4.1 != 1.5
> 
> Should RC bugs be filed against htslib and samtools to prevent them from 
> migrating to testing?

samtools/bcftools/htslib/pysam generally need to be in sync, regardless
of soname changes. I'm currently preparing bcftools 1.5, but there's
still no corresponding pysam release.

Maybe RC bugs are a good idea. They probably should have been uploaded
to experimental to begin with until pysam caught up. I'll upload
bcftools there once I'm done barring any objection.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [Help] Failed to upgrade bcftools to version 1.5

[Afif Elghraoui]

على الإثنين 24 تـمـوز 2017 ‫03:18، كتب Graham Inggs:
> Also, the htslib 1.4.1 is almost complete at 85%.
> https://release.debian.org/transitions/html/auto-htslib.html
> I think it would be better to finish that transition before starting
> another one, otherwise some packages may get auto-removed from
> testing.

Oh, my mistake. I misremembered the 1.4 transition as 1.5.

regards
Afif
-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [Help] Failed to upgrade bcftools to version 1.5

[Afif Elghraoui]

I was under the impression that htslib 1.5, required for bcftools 1.5,
has a soname bump. There is no pysam release yet to wrap htslib 1.5, so
I think upgrading bcftools/samtools/htslib right now to 1.5 will just
make it impossible to use pysam until a new release comes out, right?

I did not get through updating pysam since my time became scarce and the
time I did spend on it was not so effecient with a slow laptop.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Getting user-space containers with Singularity - works

[Afif Elghraoui]

Hi,

Thanks for bringing this up, Steffen.

على الأحد 23 تـمـوز 2017 ‫11:30، كتب Steffen Möller:
[...]
> 
> Our pals from neuro.debian.net are already actively using this
> technology and kindly nurture backports.d.o with it.

I think the Neurodebian group only maintains backports in their own
neurodebian repositories. Singularity's development is moving rather
quickly and the freeze kind of made the official Debian backports of
singularity uselessly outdated for those several months. Now, of course,
we can use jessie-backports-sloppy and stretch-backports, but
singularity there is still outdated at the moment.

> I have also seen
> Roland in the changelog. Many thanks! With feedback from Yaroslav I
> created a quick introduction to get you started at
> https://wiki.debian.org/singularity.  It is quite an eye opener. Enjoy!
> 

Thanks, Steffen. Our group at the US NIH HPC has also a guide and
tutorial for our users:

https://hpc.nih.gov/apps/singularity.html
https://github.com/NIH-HPC/Singularity-Tutorial

My old colleague who wrote those actually ended up moving on to a job as
a singularity developer.

I think a very successful Debian example would make use of
snapshot.debian.org as a mirror in the definition file in order to be
able to regenerate exactly the same container at any time.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: permission error

[Afif Elghraoui]

Hi, Kerim and Andreas,

على الجمعـة 17 آذار 2017 ‫15:58، كتب Andreas Tille:
> Hi Kerim,
> 
> On Fri, Mar 17, 2017 at 08:30:03AM +0200, Kerim Ölçer wrote:
>> i'm pushed yesterday.Thank you for the help
> 
> I admit I have seen the commit but its totally incomprehensible.  The
> commit description should explain what you really did.  A single commit
> of large upstream data and changes inside debian/ does not help anybody
> else in the team.
> 
> Moreover there is no pristine-tar information:
> 
> $ gbp build
> gbp:info: Tarballs 'emperor_1.0.0-beta.5.orig.tar.gz' not found at 
> '../tarballs/'
> gbp:error: Pristine-tar couldn't checkout "emperor_1.0.0-beta.5.orig.tar.gz": 
> fatal: Path 'emperor_1.0.0-beta.5.orig.tar.gz.delta' does not exist in 
> 'refs/heads/pristine-tar'
> pristine-tar: git show 
> refs/heads/pristine-tar:emperor_1.0.0-beta.5.orig.tar.gz.delta failed
> 
> Please do as advised in Debian Med policy via
> 
> gbp import-orig --pristine-tar emperor_1.0.0-beta.5.orig.tar.gz
> 
> to enable others easily reproduce the package.
> 

Kerim, I had mentioned this git repository layout issue in the beginning
of the MoM discussion and also gave detailed directions. If you are
still having trouble at this point, please review those emails.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Status of python-pysam

[Afif Elghraoui]

Many thanks for helping with this. At least for pbcore, there is a new release 
that hasn't been tagged upstream. Upstream's CI testing passes and I verified 
that it's using pysam 0.10.0.
I previously looked at pysam 0.10.0's release notes and didn't see anything 
about API changes. Maybe if would be faster to test the reverse-dependencies 
with rebuild-all-the-things.
I can see what I can do tonight (currently morning here)
RegardsAfif
Sent from my T-Mobile 4G LTE Device Original message From: 
Andreas Tille  Date: 1/25/2017  06:28  (GMT-08:00) To: 
debian-med@lists.debian.org Subject: Re: Status of python-pysam 
... and again,

On Wed, Jan 25, 2017 at 02:44:00PM +0100, Andreas Tille wrote:
> Hi again,
> 
> in addition to my mail below:  I do not get any rpath issue when droping
> the rpath patch completely.  The test failure does not happen as well. I
> commited the current status with adapted lintian overrides leaving it
> with spelling issues only.
> 
> I'd welcome if somebody can confirm that an upload of this status is OK.

I've tested some builds with the new pysam:

> > $ apt-cache rdepends python-pysam | grep -v med-bio-dev
> > python-pysam
> > Reverse Depends:
> >   pbhoney, python-pbsuite-utils  - source is pbsuite

Builds ... but does not Build-Depends python-pysam - so this is
no effective test.

> >   python-pbalign

OK.

> >   sga

OK

> >   python-pbcore

Does NOT build ...


==
ERROR: Failure: ImportError (libchtslib.so: cannot open shared object file: No 
such file or directory)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/loader.py", line 418, in 
loadTestsFromName
    addr.filename, addr.module)
  File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 47, in 
importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 94, in 
importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/build/python-pbcore-1.2.10+dfsg/tests/test_pbcore_io_FastaTable.py", 
line 3, in 
    from pbcore.io import FastaReader, FastaWriter, IndexedFastaReader
  File "/build/python-pbcore-1.2.10+dfsg/pbcore/io/__init__.py", line 38, in 

    from .align   import *
  File "/build/python-pbcore-1.2.10+dfsg/pbcore/io/align/__init__.py", line 32, 
in 
    from BamIO  import *
  File "/build/python-pbcore-1.2.10+dfsg/pbcore/io/align/BamIO.py", line 35, in 

    from pysam import AlignmentFile
  File "/usr/lib/python2.7/dist-packages/pysam/__init__.py", line 6, in 
    from pysam.libcutils import *
ImportError: libchtslib.so: cannot open shared object file: No such file or 
directory


... this is due to the fact that libchtslib.so is actually not
*installed* inside the resulting python-pysam package.  I'll try
to manually copy and report here about success.

> >   gasic

OK (does not Build-Depends python-pysam)

> >   fitgcp

OK

> >  $ apt-cache rdepends python3-pysam | grep -v med-bio-dev
> > python3-pysam
> > Reverse Depends:
> >   circlator

OK

> >   ariba

OK

> >   iva

OK.


I'll try to fix the missing libchtslib.so issue and report here.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Please check med-bio-ngs, med-bio-phylo and med-cloud

[Afif Elghraoui]

Hi, Andreas,

على الثلاثاء 24 كانون الثاني 2017 ‫00:59، كتب Andreas Tille:
> Hi Afif,
> 
> On Sat, Jan 07, 2017 at 02:38:32PM -0800, Afif Elghraoui wrote:
>>
>> Ok, so I will plan to move things out of med-bio into the more specific ones
>> in the next few days.
> 
> I think it is a bit late now but I do not see any harm done.

Yes, I'm sorry about that. When I looked at this, I started getting
distracted by why we are maintaining med-bio-* separately instead of
directly adding to science-bio-*. Even though we as Debian Med are
maintaining it, I don't think that presenting this sort of
"implementation detail" to users/administrators is worth any confusion.

Right now we have science-bio depending on med-bio. If I moved on, we
would have had science-bio > med-bio > med-bio-ngs, med-bio-phylo. When
I saw previous discussions of this science-bio/med-bio situation on list
archives, it was that it doesn't matter because the dependency resolver
considers them all the same.

Since all these tasks packages are part of the Blends group anyway, is
there any advantage for us to put all these scientific packages into
med-bio-* vs science-bio-*? There are technically differences between
biological software and biomedical software which I think get blurred
and might cause confusion.

>  Today I
> will upload the current status to make a "legal" upload to unstable that
> will reach testing automatically.  I'm perfectly fine if we do the
> restructuration in Stretch+1.
> 

Sure. Reads like a plan.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Status of python-pysam

[Afif Elghraoui]

Hi, Andreas,

على الأربعاء 25 كانون الثاني 2017 ‫00:12، كتب Andreas Tille:
> Hi Afif,
> 
> I noticed some commits of yours for python-pysam version 0.10.0 which
> was released yesterday.  I also noticed that you did not added a new
> changelog entry for this.

I actually meant to commit an intermediate changelog this time, but
forgot. I did it after seeing your message come through.

>  Is this because you are sharing my suspicion
> that it might be the wrong point in time to upload this new version?
> 

On the contrary-- this release wraps htslibe 1.3.2, which is what we
have in unstable now. This version also fixes issues building with the
version of cython we have in unstable as well, so I think it's quite
important to update it. I meant to do it tonight, but I did not get a
chance. I have just enough time probably to update python-cobra, which
also had a new release very recently.

If anybody would like to beat me to pysam, the current quilt patch
(rpath.patch) is causing a build failure. If you drop the patch, the
build succeeds, but you get the lintian error for package setting rpath.
Perhaps only some parts of the patch are unnecessary. Or a lintian
override is in order. I think the rpath is only needed for the private
library module it builds (libchtslib).

Otherwise, I think I can get to this tomorrow.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: test mismatches expected output in signalp 4.1c

[Afif Elghraoui]

Hello,

I didn't get any response to this message of mine from last May. There
are two points there: one is the output of the test suite and the other
is the request to consider less restrictive licensing.

Thanks and regards
Afif

على الخميس  5 أيار 2016 ‫15:25، كتب Afif Elghraoui:
> Hello,
> I ran the tests on my copy of signalp 4.1c and the output does not 
> exactly match the expected output for two cases. I'm not sure whether 
> the differences are significant, but here are the results from my test 
> run anyway:
> 
> afif@saam:~/sysadmin/alborz/apps/signalp$ make -k -f debian/tests/Makefile
> signalp -t euk -f short test/euk10.fsa | diff -u test/euk10.fsa.short_out -
> signalp -t euk -f long test/euk10.fsa | diff -u test/euk10.fsa.long_out -
> --- test/euk10.fsa.long_out2013-01-04 03:27:22.0 -0800
> +++ -2016-05-05 15:07:26.697420248 -0700
> @@ -744,7 +744,7 @@
>  45   D   0.110   0.113   0.270
>  46   Y   0.098   0.115   0.251
>  47   E   0.100   0.116   0.250
> -   48   D   0.100   0.111   0.244
> +   48   D   0.101   0.111   0.244
>  49   Y   0.106   0.117   0.244
>  50   A   0.099   0.112   0.228
>  51   S   0.096   0.111   0.218
> debian/tests/Makefile:8: recipe for target 'euk10.fsa.long_out' failed
> make: *** [euk10.fsa.long_out] Error 1
> signalp -t euk -f all test/euk10.fsa | diff -u test/euk10.fsa.all_out -
> --- test/euk10.fsa.all_out2013-01-04 03:23:57.0 -0800
> +++ -2016-05-05 15:07:27.307406112 -0700
> @@ -764,7 +764,7 @@
>   45   D0.1100.1130.1090.1130.109
>   46   Y0.0980.1150.1000.1190.109
>   47   E0.1000.1160.1010.1200.111
> -48   D0.1000.1110.1030.1140.112
> +48   D0.1010.1110.1030.1140.112
>   49   Y0.1060.1170.1050.1160.114
>   50   A0.0990.1120.1010.1160.114
>   51   S0.0960.1110.0990.1150.112
> debian/tests/Makefile:8: recipe for target 'euk10.fsa.all_out' failed
> make: *** [euk10.fsa.all_out] Error 1
> signalp -t euk -f summary test/euk10.fsa | diff -u 
> test/euk10.fsa.summary_out -
> 
> 
> My operating system is Debian 8. Do you think this discrepancy would 
> cause any problems? Also, I was wondering whether you would consider 
> less restrictive licensing. That would allow for redistribution in 
> platforms like Debian and give your program greater exposure to users 
> and contributors.
> 
> Many thanks and regards
> Afif
> 

Re: support for software liberation

[Afif Elghraoui]

على الأحد 22 كانون الثاني 2017 ‫13:22، كتب Andreas Tille:
> Hi,
> 
> On Sun, Jan 22, 2017 at 12:34:52PM -0800, Afif Elghraoui wrote:
>>> Is there any public record of this we couly add to the Wiki page?
>>> I could add another mail.
>>
>> No, this was just a direct email to the authors.
> 
> May be you can bounce this mail (or resend it to upstream and send this
> as CC).  I'd like to repeat here that all such mails should be forwarded
> here to get some public record.
> 

I agree in general, but I was using it at work and sent it from my work
email--not having my Debian hat on or discussing packaging at all. If
they had a public issue tracker, I would have posted there. I suppose I
could still have Cc'd the debian-med list.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: support for software liberation

[Afif Elghraoui]

على الأحد 22 كانون الثاني 2017 ‫09:13، كتب Andreas Tille:
>> I've tried before with signalp or rnammer and got no response.
> Is there any public record of this we couly add to the Wiki page?
> I could add another mail.
> 

No, this was just a direct email to the authors.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: support for software liberation (was: New version of fast5 does not build)

[Afif Elghraoui]

Hi, Andreas,

على الجمعـة 20 كانون الثاني 2017 ‫00:30، كتب Andreas Tille:
> Hi Afif,
> 
> On Thu, Jan 19, 2017 at 09:13:20PM -0800, Afif Elghraoui wrote:
>>
>> See https://github.com/thegenemyers/DALIGNER/issues/35
> 
> I've added a comment.
> 

Thanks

> BTW, I could need similar help for contacting authors about freeing
> their code:
> 
>https://lists.debian.org/debian-med/2016/09/msg00068.html
>https://lists.debian.org/debian-med/2016/07/msg00083.html
> 
> Any reader of our list might step in here and write to the authors
> showing that I'm not the only one who is interested.
> 

I've tried before with signalp or rnammer and got no response. I could
try here in the case of TRF, but it will take me some time to draft a
thoughtful message.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Autopkgtest for falcon

[Afif Elghraoui]

Hi, Andreas,

على الخميس 19 كانون الثاني 2017 ‫05:08، كتب Andreas Tille:
> On Thu, Jan 19, 2017 at 12:44:31AM -0800, Afif Elghraoui wrote:
[...]
>>
>> I'm fine with the idea, but it's not something I would do. This seems to
>> me like something that is better implemented within autopkgtest itself
>> (like for tests that don't specify the "breaks-testbed" restriction) or
>> something rather than on a per-package basis.
> 
> I fully agree here.
> 
>> I generally prefer to keep
>> the packaging simple, which is why I haven't manually set hardening
>> flags on every individual package (dpkg-buildflags could globally set it
>> if it is appropriate),
> 
> Seems you can read my mind:  I was always wondering why hardening=+all
> would not be the default and individual maintainers should take some
> means if the package does not build with this setting.  I admit I took
> the wimpy approach to not ask for this since if you ask for such
> features it takes some time to discuss and just copying a single line
> to the rules file takes less time in the very moment ...
> 

I think there were two additional flags and one of them has already
become default. I was planning to ignore the lintian infos until they
went away on their ownl.

>> why I don't change default compression methods
>> without good reason,
> 
> I think there is no need for this any more (if I get your question
> right).
> 

I meant about the upstream tarballs (like when repacking, I use default
options unless the package is very big and can benefit from changing it)

>> and why I don't put the dummy watch line for
>> upstreams that don't tag releases (maybe there is a possibility to have
>> uscan not fail if there is no watch line to process) and such.
> 
> I admit when inventing a new watch file version (version=4) it would
> have been cheap to define extra metadata to express the upstream status
> properly instead of doing dirty tricks like I'm doing currently.  The
> thing is if you have this kind of "good ideas" you should be up to also
> implement these - at least a proof of concept.  I did so with the
> Files-Excluded feature which I wanted so urgently that I was up to
> spending my time on it.  I think I have my turn on time investment in
> this very topic but I was hesitating with the watch file thingy.  For me
> its now important to keep my developers dashboard free from noise which
> I can approach by some copy-n-pasting - I don't mind whether its a hack
> or a field ... as long as I do not need to spend extra time on it.
>  

I guess this uscan exit code doesn't bother since I'm generally checking
my own DDPO rather than the developer's dashboard (though I agree the
latter is more concise for looking at all Debian Med packages).


>> I won't revert this kind of change-- I just won't initiate it or go out
>> of my way to maintain it.
> 
> That's perfectly fine.

Great

>  
>>> ...
>>> 2017-01-18 13:21:44,348[ERROR] Task Node(1-preads_ovl/m_1) failed with 
>>> exit-code=256
[...]
>>> makefile:21: recipe for target 'full-test' failed
>>>
>>>
>>> Is this the same issue you was talking about?  I admit I have no good
>>> idea how to fix it but just want to make sure that we are in sync here.
>>>
>>
>> That looks about right. Don't worry about this one. I've requested
>> upstream (a while ago) to document how to debug failed runs and they've
>> accepted my bug report. I may go back and ask about this specific case,
>> though ours is not a supported installation.
> 
> But possibly not for Stretch any more, right?  (Which is fine - just
> asking whether I can ignore this and focus on other things.)
>  

I might be able to get it figured out in time, but you can feel free to
ignore it.

regards

Afif
-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: New version of fast5 does not build

[Afif Elghraoui]

على الخميس 19 كانون الثاني 2017 ‫05:14، كتب Andreas Tille:
> On Wed, Jan 18, 2017 at 11:59:36PM -0800, Afif Elghraoui wrote:
>>>
>>>> daligner/dazzdb/dascrubber probably have new upstream snapshots that need 
>>>> to
>>>> be packaged.
>>>
>>> OK, these do not create any singnal on my dashboard so I'll leave this
>>> for now.
>>
>> That is because upstream doesn't make releases. I've just updated them now.
> 
> Yes, I know.  BTW, I have usccessfully requested release tags for
> pbbarcode.  So I personally will open an issue for any Github project
> I'm stumbling upon since it has no tags.  I have heard about that these
> developers are a bit stubborn about tags but I'll try my own luch
> anyway.
>  

See https://github.com/thegenemyers/DALIGNER/issues/35
I did not get any response to this ticket until I tried pinging the
author via email. It was still not a positive response.

I don't think I've ever managed to convince anybody of making release
tags, so I've somewhat given up.

>>> Sure.  That's for most of us the normal situation.  I did not intended
>>> to create any pressure - just wanted to coordinate a bit.  We do what we
>>> manage to do and if some newer version is not ready than be it so.  I
>>> just wanted to prevent that I might have used some spare cycles to
>>> polish old software if some new might have pending tasks I could have
>>> easily done.
>>>
>>
>> In case you are referring to pbbarcode, that upstream has deprecated some
>> software while people are still relying on it, so I don't consider this a
>> waste.
> 
> Yes, upstream of pbbarcode confirmed its deprecated but its now tagged
> and thus does not create any noise any more in our QA tools.  BTW, I
> restricted the test suite to some tests since the second part took
> *incredibly* long (so long that I even stopped the process on my
> laptop).  I'm not sure whether this is "*intended operation* or whether
> this is a sign of a failure.
> 

I remember there was this test that took a while, but I'd go do
something else while I ran it.

> But no, I was not refering to any specific package in my paragraph above.
> 

Ok

>> pbh5tools is in a similar situation.
> 
> I left it untouched since it did not raised any signal in the QA tools.
> 

It is in good shape. I just pointed out that this is another one that
upstream will tell you is deprecated.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Autopkgtest for falcon

[Afif Elghraoui]

Hi, Andreas,

على الأربعاء 18 كانون الثاني 2017 ‫05:33، كتب Andreas Tille:
> Hi again,
> 
> On Wed, Jan 18, 2017 at 11:34:44AM +0100, Andreas Tille wrote:
>> Hi Afif,
>>
>> On Wed, Jan 18, 2017 at 01:33:55AM -0800, Afif Elghraoui wrote:
>>>
>>> falcon's new release fails autopkgtest, which I have not gotten around to
>>> debugging, so I have not uploaded it.
>>
>> I'll have a look and let you know.
> 
> As promised I had a look.  I'm usually providing the test that is runned
> as autopkgtest also as user runnable script.  To see what I mean I
> commited a change to Git and hope you like it.  For me this has two
> advantages:
> 
>   1. Users can easily reproduce what is tested by just doing
>   sh /usr/share/doc/falcon/run-unit-test
>   2. The developer can run this script on the local machine sparing
>  the overhead of creating the virtual environment which is a
>  quicker approach to finding errors inside the test suite (even
>  no final guarantee that the test will succeede in the sandbox).
> 
> I hope you like this change.

I'm fine with the idea, but it's not something I would do. This seems to
me like something that is better implemented within autopkgtest itself
(like for tests that don't specify the "breaks-testbed" restriction) or
something rather than on a per-package basis. I generally prefer to keep
the packaging simple, which is why I haven't manually set hardening
flags on every individual package (dpkg-buildflags could globally set it
if it is appropriate), why I don't change default compression methods
without good reason, and why I don't put the dummy watch line for
upstreams that don't tag releases (maybe there is a possibility to have
uscan not fail if there is no watch line to process) and such.

I won't revert this kind of change-- I just won't initiate it or go out
of my way to maintain it.


>  With this script I get:
> 
> ...
> 2017-01-18 13:21:44,348[ERROR] Task Node(1-preads_ovl/m_1) failed with 
> exit-code=256
> 2017-01-18 13:21:44,348[INFO] recently_satisfied: set([])
> 2017-01-18 13:21:44,348[INFO] Num satisfied in this iteration: 0
> 2017-01-18 13:21:44,348[INFO] Num still unsatisfied: 2
> 2017-01-18 13:21:44,348[ERROR] Some tasks are recently_done but not 
> satisfied: set([Node(1-preads_ovl/m_1)])
> 2017-01-18 13:21:44,348[ERROR] ready: set([])
> submitted: set([])
> Traceback (most recent call last):
>   File "/usr/lib/falcon/bin/fc_run.py", line 4, in 
> __import__('pkg_resources').run_script('falcon-kit==0.7', 'fc_run.py')
>   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
> 719, in run_script
> self.require(requires)[0].run_script(script_name, ns)
>   File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 
> 1504, in run_script
> exec(code, namespace, namespace)
>   File 
> "/usr/lib/falcon/pylib/falcon_kit-0.7-py2.7-linux-x86_64.egg/EGG-INFO/scripts/fc_run.py",
>  line 5, in 
> main(sys.argv)
>   File 
> "/usr/lib/falcon/pylib/falcon_kit-0.7-py2.7-linux-x86_64.egg/falcon_kit/mains/run1.py",
>  line 461, in main
> main1(argv[0], args.config, args.logger)
>   File 
> "/usr/lib/falcon/pylib/falcon_kit-0.7-py2.7-linux-x86_64.egg/falcon_kit/mains/run1.py",
>  line 136, in main1
> input_fofn_plf=input_fofn_plf,
>   File 
> "/usr/lib/falcon/pylib/falcon_kit-0.7-py2.7-linux-x86_64.egg/falcon_kit/mains/run1.py",
>  line 414, in run
> wf.refreshTargets(exitOnFailure=exitOnFailure)
>   File 
> "/usr/lib/falcon/pylib/pypeflow-1.0.0-py2.7.egg/pypeflow/simple_pwatcher_bridge.py",
>  line 226, in refreshTargets
> self._refreshTargets(updateFreq, exitOnFailure)
>   File 
> "/usr/lib/falcon/pylib/pypeflow-1.0.0-py2.7.egg/pypeflow/simple_pwatcher_bridge.py",
>  line 297, in _refreshTargets
> failures, len(unsatg)))
> Exception: We had 1 failures. 2 tasks remain unsatisfied.
> makefile:4: recipe for target 'run-synth0' failed
> make[1]: *** [run-synth0] Error 1
> make[1]: Leaving directory '/tmp/falcon-test.0Rc93v'
> makefile:21: recipe for target 'full-test' failed
> 
> 
> Is this the same issue you was talking about?  I admit I have no good
> idea how to fix it but just want to make sure that we are in sync here.
> 

That looks about right. Don't worry about this one. I've requested
upstream (a while ago) to document how to debug failed runs and they've
accepted my bug report. I may go back and ask about this specific case,
though ours is not a supported installation.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: New version of fast5 does not build

[Afif Elghraoui]

Hi, Andreas,

On الأربعاء 18 كانون الثاني 2017 02:34, Andreas Tille wrote:

Hi Afif,

On Wed, Jan 18, 2017 at 01:33:55AM -0800, Afif Elghraoui wrote:


I guess it should be not to hard to fix the clean target but I'm
wondering whether you might intend to continue on this.


This new version, if I remember correctly, has made the example program into
a production program, but that now has an additional dependency which is not
packaged. I think this is the only difference from the current release. To
feasibly handle this, I think we would need to make a multi-orig tarball
with this new dependency (since it is from the same upstream and I believe
no other program uses it anyway) and put this program into a new binary
package.


OK, seems like something we want to do later (I'd prefer a separate
package for a separate download tarball since in the end this might be
easier to maintain - but nothing to do here for the moment whatever we
do).



I agree. Multi-orig tarballs are a pain in the neck to maintain, at 
least with gbp.



It would be
also nice to know which of the packages you are Uploader will be
uploaded in the next couple of days and where you would like to get
help.




[...]



pbbam needs a patch to be reworked. This was a patch that I forwarded
upstream, but was ignored, and the files were modified differently.


SO I'll leave it for you.


sprai has a new release, but I wanted to include the autopkgtest with it in
the next upload.


Seems you know better than me whet to do here as well.


daligner/dazzdb/dascrubber probably have new upstream snapshots that need to
be packaged.


OK, these do not create any singnal on my dashboard so I'll leave this
for now.



That is because upstream doesn't make releases. I've just updated them now.


I only really have time to work on these on weekends and I worked on some
non-DebianMed packages last weekend.


Sure.  That's for most of us the normal situation.  I did not intended
to create any pressure - just wanted to coordinate a bit.  We do what we
manage to do and if some newer version is not ready than be it so.  I
just wanted to prevent that I might have used some spare cycles to
polish old software if some new might have pending tasks I could have
easily done.



In case you are referring to pbbarcode, that upstream has deprecated 
some software while people are still relying on it, so I don't consider 
this a waste. pbh5tools is in a similar situation.



I will try to work on the onces I
consider worth uploading this weekend. I was considering working on sprai a
little earlier tonight, but that didn't happen.


That's fine.  Just ping here if you need assistance.



Thanks and regards
Afif

--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: New version of fast5 does not build

[Afif Elghraoui]

Hi, Andreas,

On الأربعاء 18 كانون الثاني 2017 00:50, Andreas Tille wrote:

Hi Afif,

I'm currently trying to update all our packages to latest upstream
(according to developers dashboard[1]) since January 25 might be the
last one to get new versions inzo next stable release.  I was stumbling
upon fast5 which you commited to Git.  The Build fails with:

I: pybuild base:184: python2.7 setup.py clean
/usr/lib/x86_64-linux-gnu: could not find Boost Python library file; use 
BOOST_DIR or BOOST_LIB_DIR/BOOST_PYTHON_LIB
E: pybuild pybuild:276: clean: plugin distutils failed with: exit code=1: 
python2.7 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p 2.7 --dir python returned 
exit code 13
debian/rules:26: recipe for target 'override_dh_auto_clean' failed
make[1]: *** [override_dh_auto_clean] Error 25


I guess it should be not to hard to fix the clean target but I'm
wondering whether you might intend to continue on this.


This new version, if I remember correctly, has made the example program 
into a production program, but that now has an additional dependency 
which is not packaged. I think this is the only difference from the 
current release. To feasibly handle this, I think we would need to make 
a multi-orig tarball with this new dependency (since it is from the same 
upstream and I believe no other program uses it anyway) and put this 
program into a new binary package.



 It would be
also nice to know which of the packages you are Uploader will be
uploaded in the next couple of days and where you would like to get
help.



falcon's new release fails autopkgtest, which I have not gotten around 
to debugging, so I have not uploaded it.


python-avro's new release is a release candidate, which I do not 
consider suitable for Stable.


python-cobra's new release has no user-visible changes and I do not 
consider it worth uploading. I believe I documented this in the 
UNRELEASED changelog.


pbbam needs a patch to be reworked. This was a patch that I forwarded 
upstream, but was ignored, and the files were modified differently.


sprai has a new release, but I wanted to include the autopkgtest with it 
in the next upload.


daligner/dazzdb/dascrubber probably have new upstream snapshots that 
need to be packaged.


I only really have time to work on these on weekends and I worked on 
some non-DebianMed packages last weekend. I will try to work on the 
onces I consider worth uploading this weekend. I was considering working 
on sprai a little earlier tonight, but that didn't happen.




[1] 
https://udd.debian.org/dmd/?email1=debian-med-packag...@lists.alioth.debian.org=html



regards
Afif

--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: pbcommand new upstream

[Afif Elghraoui]

Hi, Sascha,

على الإثنين 16 كانون الثاني 2017 ‫01:37، كتب Sascha Steinbiss:
> 
> BTW, I've seen that you updated and uploaded kineticstools -- I just
> finished getting its autopkgtests to work again when I had to leave the
> sprint ;)
> Thanks for taking care of this!

Sure (and thank you and Andreas for working on it). I mostly wanted to
fix the issue with the package version and make sure some other
touch-ups made it into the upload.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: pbcommand new upstream

[Afif Elghraoui]

على السبت 14 كانون الثاني 2017 ‫21:42، كتب Sascha Steinbiss:
> OK, thanks for the confirmation. I’ll update to the latest version of 
> pbcommand then.

Many thanks for updating pbcommand--but don't forget to push the final
changes and tag. :)

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: pbcommand new upstream

[Afif Elghraoui]

Hi, Sascha,

على السبت 14 كانون الثاني 2017 ‫05:20، كتب Sascha Steinbiss:
> Hi Afif,
> 
> at the sprint I’m currently trying to update kineticsTools to a recent 
> version. However, it also requires a newer version of pbcommand, which we 
> missed to keep up-to-date as upstream are not tagging their GitHub releases 
> [1]. It is possible to manually track the upstream versions by watching the 
> history of pbcommand/__init__.py in the repo [2], which contains the version 
> number that is used in the setup.py. They're currently at 0.5.4 while we only 
> carry 0.3.x.
> 
> What would you suggest, package the current version now that we need it? You 
> have got more experience with the PB tools and how likely they are to break 
> APIs across versions — do you think it’s a good idea?
> 

Yes, I think it should be safe to use the latest versions of the
different PacBio tools together. If it breaks anything, then that just
points out something else that should be updated.

Thanks and regards
Afif

> 
> [1] https://github.com/PacificBiosciences/pbcommand/issues/116
> [2] 
> https://github.com/PacificBiosciences/pbcommand/commits/master/pbcommand/__init__.py
> 

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name



signature.asc
Description: OpenPGP digital signature

Re: Please check med-bio-ngs, med-bio-phylo and med-cloud

[Afif Elghraoui]

On السبت  7 كانون الثاني 2017 03:48, Andreas Tille wrote:

Hi Afif,

On Sat, Jan 07, 2017 at 12:51:26AM -0800, Afif Elghraoui wrote:

Metapackages are an exception here anyway.  While we should not try to
move too much around the Blends metapackages are re-uploaded short
before the final release.  The rationale is that dependencies might
have been removed in the freeze process.  But for sure the release
team wants *small* changes at that time so we should really hurry up
in changing things.



Ok


If that's the case, can we make bio-ngs and others into real packages
and have med-bio depend on them? Then I can start reorganizing things
more enthusiastically.


I'm fine with this.  In the past I made several attempts to make med-bio
more fine grained but it was not actively supported by others and I'm
personally lacking the required detailed knowledge.



Ok, so I will plan to move things out of med-bio into the more specific 
ones in the next few days.



Is there a way to group things within tasks? For example, in bio-ngs, I 
think it would be appropriate to have some sections, like "aligners" and 
"genome assemblers".


Thanks and regards
Afif

--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Please check med-bio-ngs, med-bio-phylo and med-cloud

[Afif Elghraoui]

على السبت  7 كانون الثاني 2017 ‫00:45، كتب Afif Elghraoui:
> The
> problem here is making the leap to actually releasing a bio-ngs
> metapackage (which is too late now anyway).

Maybe it's not too late [1]. I think new binary packages are still
allowed into testing--just not new source packages.

If that's the case, can we make bio-ngs and others into real packages
and have med-bio depend on them? Then I can start reorganizing things
more enthusiastically.


regards
Afif

1. https://lists.debian.org/debian-devel-announce/2016/12/msg0.html

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Please check med-bio-ngs, med-bio-phylo and med-cloud

[Afif Elghraoui]

Hi, Andreas,

على الخميس  5 كانون الثاني 2017 ‫08:39، كتب Andreas Tille:
> Hi,
> 
> we are in preparation of the next stable release and thus we should
> verify that our metapackages are up to date.  I admit I'm regularly
> checking med-bio and med-bio-dev to contain everything it needs but we
> have those three subsets that need some more detailed knowledge about
> the packages.  Specifically med-cloud will be released as metapackage
> (bio-ngs and bio-phylo are just rendered as tasks pages - no
> metapackages with dependencies and thus not effectively affecting the
> release).  It would be great if those who feel competent would check
> the according tasks files and edit them if necessary.
> 

I did express an interest in this before and started working on that,
but it's a little difficult to keep track of progress in distributing
from bio to the more specific ones without removing them from bio. The
problem here is making the leap to actually releasing a bio-ngs
metapackage (which is too late now anyway).

Is there a way to make subgroups without having them be subtasks? For
example, if on bio-ngs, we want to group aligners, how would we do that?


Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: cme tickets filed (was: cme and stylistic changes in team uploads)

[Afif Elghraoui]

For whoever's interested:

على الأحد 25 كانون الأول 2016 ‫15:51، كتب Afif Elghraoui:
>> IMHO we should consider two things:
>>
>>   1. File bug to not mess up comments

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849500

> 
>>   2. File wishlist bug "please provide options for different style"
> Or maybe the "fix" command should only fix actual problems and not make
> unnecessary rearrangements and spacing changes. Maybe there could be a
> command like `cme rewrite` to do what "fix" currently does.
> 

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849498

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: cme and stylistic changes in team uploads

[Afif Elghraoui]

On الإثنين 26 كانون الأول 2016 06:50, Ghislain Vaillant wrote:

On 25/12/16 23:51, Afif Elghraoui wrote:

I think it's enough consistency that people are either using dh_make,
debmake, or the debian-med packaging template and just adding to that.
If people were writing these packaging files from scratch, there would
be real consistency issues.


Come on, I am sure most people just copy an existing debianization that
is close enough to the package they intend to work on, despite our best
efforts to advise against doing so.


Either way, it's not written from scratch. This is beside the point 
anyway and I think there's been too much digression.



[...]

I'd definitely not request the cme style while I'm recommending it to
newcommers for the said reasons.  I'm usually doing it in team uploads
since up to now nobody expressed that its not wanted.  I'd not use it
for instance on packages where you are Uploader and I know that you do
not like it.


Place yourself as a newcomer for a minute. You were advised to use cme
because whatever changes you make, you are guaranteed a well-formed
d/control or d/copyright, or else the software will scream at you.

You are now happy with your contribution and get it uploaded, only to be
publicly shamed on the team's mailing list for not respecting the main
uploader's custom style.

Now let me ask you this, does this sound like a great packaging
experience to you?



I agree with you 100% that it isn't and also made exactly the same point 
in my previous message that you are making now. Please see the last part 
of my previous message (not snipped from this reply).




[...]
I agree that can be helpful, but to me it's outweighed by the problems I
have with it.


The problem here is you putting comments in d/control to categorize
dependencies. This is highly non-standard. If you really want to do such
thing, then you should be using build profiles [1] which would bring
additional benefits.

[1] https://wiki.debian.org/BuildProfileSpec

Otherwise, your comments in d/control are just plain noise, I am afraid.



As I said, I'm not going to dispute particular points of style here. 
This is a digression. I only named a couple of my problems with it here 
to avoid derailing this thread. I think the specific issues are better 
discussed with the cme developers.



[...]


I never observed this.  Could you please give an example?  That could
also be a topic for a bug report.


This is really not a big deal, but I was referring to something like:


[...]

where in the latter case, both lists are aligned. Again, not a very big
deal.


Not a very big deal indeed!



I didn't want to go deep into details, but I merely provided an answer 
to a question I was asked.



[...]


-1. I think that requiring everyone to have to remember everyone else's
quirks will create huge barriers to teamwork over time, with the brunt
of the problems coming to newcomers who have enough to learn aside from
getting inside everyone's head. I'd like to agree with everyone on a
standard procedure.


We should all just "take one for the team" and stop this madness of
imposing one's style over a consistent one.



I would say "preserving" rather than "imposing", but sure. I'm sure you 
would agree, though, that if I'm just making a team upload to fix a 
problem in one of your packages, it wouldn't be a good idea for me to 
also go through and change all your variable assignments from "A = B" to 
"A=B" or vice versa or whatever.


I'm trying to make exactly this point. It's just that in this case, cme 
fixes problems while also changing style. Because it's not the packager 
actively changing these things as it is in my example with d/rules, it's 
clear that my issues should have been taken up with the cme people and 
not here.


Thanks and regards
Afif

--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: cme and stylistic changes in team uploads

[Afif Elghraoui]

Hello,

على السبت 24 كانون الأول 2016 ‫22:51، كتب Andreas Tille:
> Hi,
> 
> On Sat, Dec 24, 2016 at 10:00:07PM -0800, Afif Elghraoui wrote:
>>> On 24/12/16 15:41, Afif Elghraoui wrote:
>>>> I'm admittedly no fan of cme's styling. While I have my own style that I
>>>> prefer to use in d/control,
> 
> I admit before I started cme I had a different style as well.  I decided
> that the advantages cme had regarding content are way superior over
> keeping my own style.  Moreover I consider it a feature to have a common
> style inside a team.
>  There is another "styling" tool with different
> formating style (I always forget its name since I'm not using it).

I think you mean devscripts' `wrap-and-sort`.

>  I
> know that style is something (like color of web pages, names of
> projects) people can be quite opinionated about.  I personally try to
> save my own time and adapt to something that could be potentionally a
> common agreement since I'm convinced that some common style has some
> value.  Its not really necessary but helps others to step in.


I think it's enough consistency that people are either using dh_make,
debmake, or the debian-med packaging template and just adding to that.
If people were writing these packaging files from scratch, there would
be real consistency issues.


> 
>>>> I don't impose this on anyone--I would not
>>>> force people requesting sponsorship to use it, nor would I change it
>>>> while making a team upload.
> 
> I'd definitely not request the cme style while I'm recommending it to
> newcommers for the said reasons.  I'm usually doing it in team uploads
> since up to now nobody expressed that its not wanted.  I'd not use it
> for instance on packages where you are Uploader and I know that you do
> not like it.
> 
>>> cme introduces some consistency in the formatting that is definitely 
>>> welcome.
> 
> Its not *only* the formatting its also a defined sequence of fields
> which I consider a helpful standard.
> 
>>> It also helps you flag things like non-secure VCS URIs and 
>>> out-of-date standards fairly easily.
> 
> Its not just flagging it - its fixing it and by doing so it saves
> time.
>  
>> Flagging is what lintian does.
> 
> Yes, lintian is *only* flagging and I need to rebuild the package
> after manual work.  Cme does things in advance and saves me another
> build which is very convenient.


I agree that can be helpful, but to me it's outweighed by the problems I
have with it.


> 
>> While cme also makes those changes for
>> you, it removes trailing commas from listings (making for noisier diffs)
> 
> I admit I was considering a bug report against cme about this but
> somehow never took the time.  In the past I learned that cme authors are
> quite sensible and if you have good reasons are responsive about this.
> So if this really concerns you I'd try a bug report if I would be in
> your shoes.
> 
>> and misaligns all itemized lists.
> 
> I never observed this.  Could you please give an example?  That could
> also be a topic for a bug report.

This is really not a big deal, but I was referring to something like:

Build-Depends: A,
   B,
   C
...
Depends: D,
 E,

versus

Build-Depends:
A,
B,
C
...
Depends:
D,
E

where in the latter case, both lists are aligned. Again, not a very big
deal.

>  
>> I'm not trying to convince anyone because I'm not really interested in
>> disputing style; all I'm saying is that if someone wants to make a team
>> upload, I don't think that making stylistic changes should be part of it.
> 
> It depends.  If I know that the team member does not like it I agree.
> However, in the past I touched so many packages of team members who in
> the beginning were not aware about cme and its features and who were
> happy about the change or team members who somehow stopped caring for
> the package in question or left the team at all that the overall style
> consistence became a feature of the Debian Med packages which I do not
> want to miss today.  That's the reason we have even put
> 
>... simply call
> 
>cme fix dpkg-control
> 
>to get a properly formated, sanity checked debian/control file.
> 
> in our team policy[1].
> 

Although in the case of someone leaving the team or stopping work on a
package, presumably someone else has joined the uploaders list, in which
case subsequent changes are no longer Team uploads. My suggestion was
only to not change style as part of Team uploads.


>>> That being said, like any other tools, it should not be used blindly and 
>>> whoever messed with your comment should have inspect

Re: cme and stylistic changes in team uploads

[Afif Elghraoui]

Hi, Ghislain,

على السبت 24 كانون الأول 2016 ‫08:12، كتب Ghislain Vaillant:
> On 24/12/16 15:41, Afif Elghraoui wrote:
>> Hi, all,
>>
>> I'm admittedly no fan of cme's styling. While I have my own style that I
>> prefer to use in d/control, I don't impose this on anyone--I would not
>> force people requesting sponsorship to use it, nor would I change it
>> while making a team upload.
> 
> cme introduces some consistency in the formatting that is definitely 
> welcome. It also helps you flag things like non-secure VCS URIs and 
> out-of-date standards fairly easily.
> 

Flagging is what lintian does. While cme also makes those changes for
you, it removes trailing commas from listings (making for noisier diffs)
and misaligns all itemized lists.

I'm not trying to convince anyone because I'm not really interested in
disputing style; all I'm saying is that if someone wants to make a team
upload, I don't think that making stylistic changes should be part of it.

> That being said, like any other tools, it should not be used blindly and 
> whoever messed with your comment should have inspected the diff before.
> 
> That being said?
> 
>> Is there a reason to apply cme systematically to packages as part of any
>> upload? Besides my dislike for what it does to the file, it has in one
>> case moved a Depends line away from the comment that describes it (so
>> the comment ends up being next to something else).
> 
> Comments in d/control, what is this practice? Why do we have 
> README.Debian and README.source then?
> 

I mostly do it to set aside build-dependencies that are needed for tests
and perhaps a few other things that are not really appropriate in README.*.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [MoM] deepnano getting info from maintainer

[Afif Elghraoui]

Hi, Çağrı,

على الجمعـة 16 كانون الأول 2016 ‫21:06، كتب Çağrı ULAŞ:
> I push some changes for deepnano. Used a few poretools data for the
> deepnano-data because poretools use pybuild for packaging. When I create
> new package in control file (for split packaging) poretools package
> created with empty package. I dont want to change the way this package
> builded. Didn't find any useful example for python split packaging. Any
> ideas?

I just made this change and will upload poretools with a data package
shortly.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Bug#832391: consensuscore2: Any news?

[Afif Elghraoui]

Whoa, wait a minute. Consensuscore2 hasn't been deprecated yet--it's just been 
bundled with other things in the unanimity suite.
The reason I don't support removal of this source package is that we might find 
the best solution to be extracting consensuscore2 from unanimity and using that 
for the orig tarball here. We will likely run into fhe same or worse problems 
trying to package everything from one unanimity source package.
I can elaborate when I get off work, but please do not remove this source 
package.
Afif
Sent from my T-Mobile 4G LTE Device Original message From: 
Andreas Tille  Date: 12/6/2016  06:48  (GMT-08:00) To: 
Ghislain Vaillant , 832...@bugs.debian.org Cc: Debian Med 
Project List  Subject: Re: Bug#832391: 
consensuscore2: Any news? 
Hi,

On Tue, Dec 06, 2016 at 11:23:36AM +, Ghislain Vaillant wrote:
> > 
> > I should have posted an update. Upstream has moved consensuscore2 into a
> > new source package, unanimity [1]. The packaging issues I was having are
> > due to building the mixed-language code base. I have not found a good
> > solution for this with debhelper, and the upstream build system was also
> > very unconventional in order to handle it (which did not help
> > debhelper's latching onto it). I think what needs to be done is to just
> > package unanimity and have consensuscore2 be one of its binary packages.
> > I'll have to see whether this problem will come up again after that.
> 
> I confirm Afif's reporting. This project is deprecated in favour of a larger
> one.
> 
> We should just request an RM for this package, since we won't be getting any
> support for it from upstream in the future, and focus on the new project. This
> should also clear the current RC bug affecting it.

So I wonder whether we should turn this into an ITP unanimity[1].  The
first stumbling stone is that they do not add release tags but have
somehow switched of reporting this as an issue on Github (at least I
can't find any contact to ask them for tags :-().

I'm personally fine with removing consensuscore2 package from Debian.

Afif, could you push your preliminary work how rudimentary / non-working
it might be?  It just helps to display the current state on the tasks
pages as prospective package in VCS (in case somebody is seeking for an
interesting job ...)

Kind regards

   Andreas.

PS: I'll reassign #832391 to ftp.debian.org and turn it into a ROM request.

[1] https://github.com/PacificBiosciences/unanimity

-- 
http://fam-tille.de

Re: RFS: qtltools -- Tool set for molecular QTL discovery and analysis

[Afif Elghraoui]

على الجمعـة  2 كانون الأول 2016 ‫01:33، كتب Dylan:
>> * I've been told by ftpmasters before that, if the authors simply say
>> > "GPL" or provide no explicit GPL license statement besides simply
>> > bundling the text of GPL-3, the license is to be recorded as /any/ GPL
>> > version, i.e., GPL-1+. If we upload in the current state, we might get a
>> > rejection for this reason.
>> >
> Maybe, I miss something but the authors specify in the header of each
> file that the license is GPL-3+:
> "...either version 3 of the License, or (at your option) any later 
> version...".
> 
> 

Ah, you're right. I thought I did this particular check yesterday and so
made the comment from memrory, but I must have been looking at another
package or something.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: RFS: qtltools -- Tool set for molecular QTL discovery and analysis

[Afif Elghraoui]

Hi, Dylan,

على الثلاثاء 29 تشرين الثاني 2016 ‫14:01، كتب Dylan:
> Hi,
> 
> Package name: qtltools
> URL: https://qtltools.github.io/qtltools/
> License: GPL-3+
> Description: Tool set for molecular QTL discovery and analysis
>  QTLtools is a tool set for molecular Quantitative Trait Loci (QTL) discovery
>  and analysis. It allows user to go from the raw sequence data to collection 
> of
>  molecular QTL in few easy-to-perform steps. QTLtools contains multiple 
> methods
>  to prepare the data, to discover proximal and distal molecular QTL and to
>  finally integrate them with GWAS variants and functional annotations of the
>  genome.
> 
> 
> The package is ready for the review and the upload.
> 

Many thanks for preparing this package. My comments:

* Rather than patch the include statements for libeigen in the source,
it is more sustainable to append -I/usr/include/eigen3 to CPPFLAGS in
debian/rules (using DEB_CPPFLAGS_MAINT_APPEND). This will save you
maintenance of a patch and provide more flexibility.

* I've been told by ftpmasters before that, if the authors simply say
"GPL" or provide no explicit GPL license statement besides simply
bundling the text of GPL-3, the license is to be recorded as /any/ GPL
version, i.e., GPL-1+. If we upload in the current state, we might get a
rejection for this reason.

* very minor: the folder debian/upstream.docs has data inside it rather
than documentation. Would you clarify this in README.source or use a
more intuitive name?

the build is taking a bit too long on the computer I'm using now, so I
would have to try on a more resourceful machine to fully test it out.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: New upstream version available type bugs for advent calendar use

[Afif Elghraoui]

Hi, Andreas,

على الخميس  1 كانون الأول 2016 ‫01:16، كتب Andreas Tille:
>  I'll file a series of "New version available"
> bugs here and will CC the list to enable everybody picking from the
> list.  I'll also give comments whether its an easy upgrade (for
> beginners!) or whether its a hard one.

I think the "newcomer" BTS tag would be appropriate for the easy ones,
so I wanted to advertise the use of that. :)

Many thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: pyBigWig

[Afif Elghraoui]

Hello,

على الخميس  1 كانون الأول 2016 ‫16:32، كتب Diane Trout:
> And instead of building a shared library, they just add the C files to
> the python C extension. See:
> https://github.com/dpryan79/pyBigWig/blob/master/setup.py#L14
> 
> I believe this is a violation of Debian packaging policy, but this
> seems useful, what should one do in this case?

I don't think this is a problem. Policy 4.13 [1] says

~~~
Debian packages should not make use of these convenience copies unless
the included package is explicitly intended to be used in this way.
~~~

which I think matches the situation here.

Thanks and regards
Afif

1. https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [MoM] Bug#843022: ITP: emperor -- analysis and visualization of large microbial ecology datasets

[Afif Elghraoui]

Hi,

على الأحد 27 تشرين الثاني 2016 ‫00:10، كتب Kerim Ölçer:
> Hi Afif
> i posted
> i hope its true 

It's ok. I retitled the bug report so that the short description appears
properly at <https://bugs.debian.org/843022>.

Let's continue on with the packaging. When you imported the source
before, it looks like you manually copied the tarball contents over the
existing source. You should do it using the instructions in the Debian
Med policy:

http://debian-med.alioth.debian.org/docs/policy.html#updating-git-package

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [MoM] Bug#843022: ITP: emperor -- new version

[Afif Elghraoui]

Hi, Kerim,

Any update? This part should be really quick.

Thanks and regards
Afif

على السبت 19 تشرين الثاني 2016 ‫20:40، كتب Afif Elghraoui:
> 
> 
> على السبت 19 تشرين الثاني 2016 ‫05:07، كتب Kerim Ölçer:
>> i'm unterstand, shall i do make itp again 
> 
> Don't file it in the BTS again. Just forward the ITP email to
> debian-de...@lists.debian.org. While you do that, you can make some of
> the corrections, especially the subject line.
> 
> regards
> Afif
> 

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [MoM] Bug#843022: ITP: emperor -- new version

[Afif Elghraoui]

على السبت 19 تشرين الثاني 2016 ‫05:07، كتب Kerim Ölçer:
> i'm unterstand, shall i do make itp again 

Don't file it in the BTS again. Just forward the ITP email to
debian-de...@lists.debian.org. While you do that, you can make some of
the corrections, especially the subject line.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [MoM] deepnano getting info from maintainer

[Afif Elghraoui]

Hello,

على الأربعاء 16 تشرين الثاني 2016 ‫01:50، كتب Çağrı ULAŞ:
> 
> I finally find fast5 files from poretools which is an utility for
> converting fast5 to fasta/fastq file. There are fast5 examples on
> poretools' github page. Is there any thing we need to specify for this
> data in debian directory?

I created the poretools Debian package, but the data files are not part
of any binary package. Do you two think it would be a good idea to make
a poretools-data package? Then you could build-depend on it to get
access to these files.

Çağrı, perhaps you can see whether those files are useful for you. If
they are, we can arrange to get them packaged and you can pull it in as
a dependency.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [MoM] Bug#843022: ITP: emperor -- new version

[Afif Elghraoui]

Hi, Kerim,

just some comments about this.

email subject: Instead of "new version", you should put the package's
short description.

على الخميس  3 تشرين الثاني 2016 ‫00:44، كتب Kerim Ölçer:
> Subject: ITP: emperor -- new version
> Package: wnpp
> Owner: "Kerim ÖLÇER" <debian-med@lists.debian.org

The owner name here would more correctly be Debian Med Packaging Team
rather than your name. You'll still be linked to this ITP as the submitter.

> <mailto:debian-med@lists.debian.org>>
> Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org
^
You would need this line in order for the ITP to be copied to
debian-devel, as mentioned in the Debian Developer's reference [1]. When
reportbug is used with an MTA, it will add this line in the email header
automatically (and you won't see it in the message body), but since you
had to copy this into an email body, you can use the first block to add
pseudo-headers like this one and have the same effect.

You should forward the ITP email to debian-de...@lists.debian.org since
it didn't get automatically sent there by the BTS.

> 
> * Package name: emperor
>   Version : 1.0.0beta5
>   Upstream Author : Vazquez-Baeza Y, Pirrung M, Gonzalez A, Knight R.
> * URL : https://github.com/biocore/emperor
> * License : (MIT)
>   Programming Lang: (Python, Javascript, etc.)

You don't need parentheses here for these fields.

>   Description : Emperor is a next-generation tool for the analysis
> and visualization of large microbial ecology datasets; amongst many
> features Emperor provides a modern user interface that will rapidly
> adjust to your daily workflow.
> 

Looks good.

regards
Afif

1.
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#newpackage

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [MoM]-Emperor package issue

[Afif Elghraoui]

Hi, Kerim,

Is there any news on this packaging? Let me know if you are stuck on
anything.

regards
Afif

على الثلاثاء  1 تشرين الثاني 2016 ‫23:55، كتب Afif Elghraoui:
> Hi, Kerim,
> 
> على الثلاثاء  1 تشرين الثاني 2016 ‫11:56، كتب Kerim Ölçer:
>>
>> I made an ITP give lists mail adress to it i am waiting for reply mail now.
>>
> 
> It doesn't look like it has gone through... If you haven't configured a
> mail transfer agent on your machine, reportbug cannot automatically send
> the report. You can instead have it print out the text to paste into an
> email and send it to sub...@bugs.debian.org.
> 


-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: python-bx, upload ok? Re: galaxy dependency - current state

[Afif Elghraoui]

Hi, Steffen,

على الأحد 13 تشرين الثاني 2016 ‫14:21، كتب Steffen Möller:
> @Afif, you did the work on the python-bx package. Do you mind me
> uploading it?

I don't mind. It's just that I was using an obsolete upstream
repository--the one on bitbucket rather than the one on github (which I
wasn't aware of at the time)--so the packaging might need a little tweaking.

> A web search also found me
> https://github.com/detrout/debian-bx-python which is inferior to your
> work, but it would be nice to get/stay in touch for a possible
> co-maintenance, possibly.

It looks like that repository belongs to a DD, but it's a couple years
old. She's listed as a Debian Med member according to
<https://wiki.debian.org/DebianMed/Developers>, but I have never heard
of her working in our team, so it was surely before my time.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [Mom] Varmatch package situation

[Afif Elghraoui]

على الأربعاء  2 تشرين الثاني 2016 ‫00:45، كتب Ghislain Vaillant:
> On 02/11/16 07:18, Afif Elghraoui wrote:
>> Varmatch is a pretty new software package and they haven't yet made
>> their first official release. I saw the preprint article, thought it was
>> interesting, and made this start in packaging it as a result.
>>
>> Being unreleased yet, the major concern is for it to produce accurate
>> results, so you should make sure that it can reproduce the results they
>> claim that it can with their test data.
> 
> Not to mention upstream might not be happy to have unreleased software 
> officially packaged.
> 

I do not think this is the case here, although some upstreams are never
happy to have their software packaged at all. The varmatch developers
have written and posted an article that has presumably already been
submitted to a journal, so it looks to be in a beta stage.

Of course, if anyone has a doubt, contacting upstream won't hurt. I
anticipated that might be necessary anyway to figure out how to validate
the program's output based on the test data.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [Mom] Varmatch package situation

[Afif Elghraoui]

Hi, Ali,

على الثلاثاء  1 تشرين الثاني 2016 ‫20:12، كتب Ali güven Odabaşıoğlu:
> 
> I start to work on Varmatch Debian package i know you don't have much
> time if you have some time can you help some questions of me please ?

Always feel free to ask away. In the worst case, your message would just
remain unanswered until someone has time to reply.

> I will make an ITP soon do you have any advices.
> 

Varmatch is a pretty new software package and they haven't yet made
their first official release. I saw the preprint article, thought it was
interesting, and made this start in packaging it as a result.

Being unreleased yet, the major concern is for it to produce accurate
results, so you should make sure that it can reproduce the results they
claim that it can with their test data.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [MoM]-Emperor package issue

[Afif Elghraoui]

Hi, Kerim,

على الثلاثاء  1 تشرين الثاني 2016 ‫11:56، كتب Kerim Ölçer:
> 
> I made an ITP give lists mail adress to it i am waiting for reply mail now.
> 

It doesn't look like it has gone through... If you haven't configured a
mail transfer agent on your machine, reportbug cannot automatically send
the report. You can instead have it print out the text to paste into an
email and send it to sub...@bugs.debian.org.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [MoM]-Emperor package issue

[Afif Elghraoui]

Hi, Kerim,

على الجمعـة 28 تشرين الأول 2016 ‫11:05، كتب Kerim Ölçer:
> Hi Afif
> finaly i uploaded

Just a word about Debian and VCS slang-- when we talk about uploading
here, we mean the uploading of the package to the Debian archive. When
talking about uploading commits, we would rather say that you pushed. It
will get confusing later if you gain upload privileges because then we
wouldn't be able to tell which of the two you mean.

> i changed ssh_config #GSSAPIAuthentication yes
>  GSSAPIDelegateCredentials
> no>#GSSAPIDelegateCredentials no> and fixed
> 

great

> want to look ?

It looks to me like you manually unpacked the latest release into the
repository. While this could work, it cuts some corners and is not our
standard procedure.

Let's first go back to the steps I outlined a couple messages ago. I
talked about first filing the intent to package (ITP) ticket in the
Debian BTS and then pointed you to git-buildpackage, which is the
primary tool we're using to manage the git packaging (and handles things
like importing new releases into the packaging repository).

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [MoM]-Emperor package issue

[Afif Elghraoui]

Hello,

على الأربعاء 26 تشرين الأول 2016 ‫12:38، كتب Andreas Tille:
> Hi,
> 
> On Wed, Oct 26, 2016 at 08:35:47PM +0300, Kerim Ölçer wrote:
>> hi Afif
>> ---
>> git push origin master
>> fatal: remote error: access denied or repository not exported:
>> /debian-med/emperor.git
>> ---
>> I'm getting this type of error
>> what should i do ?
> 
> Hmm, we had recently some cases where the group membership was not
> propagated to UNIX groups on git.debian.org.  Please login to this host
> and check with `groups` whether you are a member of scm_debian-med.  If
> not as far as I know you need to contact Alioth admins.  Some people
> here on this list should have experience with this issue. :-(
> 

I checked and the permissions on the repository are ok. Kerim, did you
set up an ssh key for Alioth? That is the only way to connect to the
server. Take a look at <https://wiki.debian.org/Alioth/SSH> if you
haven't already.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [MoM]-Emperor package issue

[Afif Elghraoui]

Hi, Kerim,

على الأربعاء 19 تشرين الأول 2016 ‫12:14، كتب Kerim Ölçer:
> 
> https://anonscm.debian.org/cgit/debian-med/emperor.git/
> the package version is old version 0.9.x
> 
> in the github package version is  1.x

Yes, we should target the latest upstream release. What is in the
repository currently is just what Andreas had done a couple years ago.

> i packed the github version of emperor if you want to look i can commit
> new version to alioth what should we do ?  
> 

I think you should first file the ITP. You would use

$ reportbug wnpp --no-query-bts

Then, to update the packaging, you should use uscan(1) to retrieve the
latest upstream source in order to make sure that the debian/watch file
is configured properly (the format of this file is described in the
uscan manpage). The downloaded tarball can then be incorporated into the
packaging using the `gbp import-orig --pristine-tar` command from
git-buildpackage.

If you already did this, go ahead and push to alioth. Make sure to push
all branches and tags.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Sponsoring request: plink and galileo

[Afif Elghraoui]

Hello,

على الأحد 16 تشرين الأول 2016 ‫14:26، كتب Dylan:
> Hi,
> I have updated plink and galileo. Could someone upload them to unstable?
> 

Upload permissions have been granted for these two. Just wait for the
notification email that permissions have taken effect before you proceed
with uploading.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [MoM] Emperor license

[Afif Elghraoui]

Hi, Kerim,

Please keep in mind putting "[MoM]" at the beginning of the email
subject as I have just added. I also put something more informative as
the subject line.

على الأحد 16 تشرين الأول 2016 ‫07:53، كتب Kerim Ölçer:
> Hello Andreas, I looked at Emperors liscences. Some of them use
> copyright liscences ( no MIT,GPL etc.). You looked it before is this a
> problem if it is what should i do ?

Are you talking about the contents of
<https://github.com/biocore/emperor/blob/new-api/LICENSE.md>? I looked
through it just now and I don't see any problems. Is there anything
specific that confused you (I'm not sure what you mean by a copyright
license)

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [MoM] packaging emperor

[Afif Elghraoui]

Hello,

على الخميس 13 تشرين الأول 2016 ‫00:15، كتب Andreas Tille:
> Hi,
> 
> On Wed, Oct 12, 2016 at 11:39:44PM -0700, Afif Elghraoui wrote:
>>
>> Thanks for pointing this out, Andreas. I went ahead and did this
>> conversion. Even if Kerim is comfortable with SVN, I am not so much. The
>> repository URL is now:
>>
>> ssh://git.debian.org/git/debian-med/emperor.git
> 
> Perfect.  I removed the remainings from SVN.  Usually I drop a
> README.status but this package was never released so nobody will really
> miss it there. :-)

Thanks for doing that.

>  
>> Kerim, I would suggest now that you file an intent to package emperor.
>> See <http://debian-med.alioth.debian.org/docs/policy.html#itp>. Andreas
>> likes to do this after packaging is completed, but I think it helps to
>> have it early in order to log progress of the packaging, even if it does
>> not get completed anytime soon.
> 
> Just a note: Its perfectly correct to teach newcomers the right
> behaviour to ITP soon.  There is no point in sticking to my personal
> decision to ITP quite late in the packaging process.
>  

Great.

>> Once that is up, I can look for old discussion threads regarding
>> Andreas' previous packaging effort and post them to the log for reference.
> 
> I think there is not much left.  I'd rather start with the new upstream
> version (which is not reported by d/watch since letters in "beta" are not
> checked for - which might be right or wrong depending from your decision
> whether we intend to package those beta version or not). 
> 

Of course. I just transferred the packaging the way it was, so I needed
to include the old release to match.

> Afif, thanks for volunteering to mentor.
> 

No problem.

regards
Afif


-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [MoM] packaging emperor

[Afif Elghraoui]

Hi, Kerim and Andreas,

على الأربعاء 12 تشرين الأول 2016 ‫12:34، كتب Andreas Tille:
> Hi Kerim,
> 
> On Wed, Oct 12, 2016 at 09:37:43PM +0300, Kerim Ölçer wrote:
>> Hi Afif
> 
> I do not want to stop Afif but meanwhile I have some hints:
> 
>> i chose emperor https://github.com/biocore/emperor/

Great!

>> where can i find example for python packaging
> 
> I think there is quite some packaging stuff for emperor in Debian Med
> SVN[1].  I once converted several projects from SVN to Git since Canberk
> was not comfortable with SVN.  Since I was doing something on emperor
> in the past I'd volunteer to do this conversion if needed.  Just ask me
> to do so.
> 

Thanks for pointing this out, Andreas. I went ahead and did this
conversion. Even if Kerim is comfortable with SVN, I am not so much. The
repository URL is now:

ssh://git.debian.org/git/debian-med/emperor.git

> I admit I do not remember why I stoped with the packaging of emperor.
> It might be there were some compressed JavaScript files with no
> uncompressed source.  In any case it would be a quite interesting
> project.
> 
>> what should i do now
> 
> As I said add a row to the MoM Wiki page (and add Afif as mentor if he
> volunteers to do so).

I'm fine with this.

>  Than please follow the Debian Med policy document
> (linked from the MoM Wiki page) to get an account at alioth.debian.org
> to get commit permissions to Git (or SVN).
> 

This looks done.

Kerim, I would suggest now that you file an intent to package emperor.
See <http://debian-med.alioth.debian.org/docs/policy.html#itp>. Andreas
likes to do this after packaging is completed, but I think it helps to
have it early in order to log progress of the packaging, even if it does
not get completed anytime soon.

Once that is up, I can look for old discussion threads regarding
Andreas' previous packaging effort and post them to the log for reference.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: MoM Application

[Afif Elghraoui]

Hi, all,

على الإثنين 10 تشرين الأول 2016 ‫12:21، كتب Andreas Tille:
> I hope you three will be
> able to find some arangement about the monthes because I do not feel
> able to work with three MoM students at the same time (at least not
> currently with some vacation backlog)

I'm willing to step in and do a mentorship. This way, two people can
start at the same time.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: If you need students for small bioinformatics projects

[Afif Elghraoui]

على السبت 10 أيلول 2016 ‫15:24، كتب merlettaia:
> Hi Afif,
> 
> There is no need to apologize - It's ok.
> I've told Bioinformatics Institute mentors about Debian Med Team and
> told you about them. I think it would be good if you'll write them - to
> ensure they'll mail you when they'll search for mentors next time, and
> it might happen that you'll have enough time and they'll have student
> who will be glad to work on your project.
> Thank you for your project idea link, I'll forward your letter to them
> if you don't mind - to let them know that you might be interested next
> term (or next year - or at least somewhen :)).

Great!

> 
> BTW, I was not precise in my previous letter - they are non-profit
> organization and they don't charge any fees from students or mentors -
> except time consumption :)
> 

Understood.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: If you need students for small bioinformatics projects

[Afif Elghraoui]

على السبت 10 أيلول 2016 ‫14:23، كتب Afif Elghraoui:
> It is a very nice idea and I
> hope we could take advantage of it.

Too many vague pronouns-- The program looks like a very nice idea and I
hope that Debian Med could take advantage of it sometime.

apologies for the ambiguity
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: If you need students for small bioinformatics projects

[Afif Elghraoui]

Hi, Tanya,

Many thanks for taking the time to write this message. I do have at
least one idea [1] that might fit well for this, but I wouldn't be able
to participate--at least for this cycle. It is a very nice idea and I
hope we could take advantage of it.

Thanks and regards
Afif

1. https://lists.debian.org/debian-med/2016/07/msg00088.html

على السبت  3 أيلول 2016 ‫17:03، كتب merlettaia:
> Hi All,
> 
> I’m writing you in case if someone has a small research
> bioinformatics-related project to this academic term and wishes to find
> some smart student (or students) to do it.
> 
> Our St.Petersburg’s local bioinformatics school (named Bioinformatics
> Institute) provides 1-year study program in bioinformatics for
> biologists and software developers (this year ~40 students applied). It
> is additional education program, and combines lectures every Saturday
> (except holidays) with 1 course project for fall and spring terms +
> summer internship.
> 
> For now they are looking mentors, who could provide projects and guide
> students to do them.
> 
> Project supervising  can be done remotely, for example, via Skype or
> email. It would be good if you could provide 1 hour per week. For
> student study project should take approximately 10 hours per week. This
> semester they start learning bioinformatics, and probably couldn’t do
> too complex tasks (of course, it depends on student personality).
> 
> 
> I should also mention that at my university (named “Academic
> University”) this 1-year course is included to Master degree education
> program. It means that some of this year’s students are studying at this
> program now.
> 
> Since this is a part of main education for them, this course project
> means *a lot*. They'll be expelled if they do nothing useful. And that's
> why they will do their best not too fail (there is also a very tough
> selection to this MSc program and a very saturated program in fall
> semester in 1st year of education - so please don't push too hard! 2nd
> MSc program students are also interested in course projects - since in
> fall they are usually starting to write their thesis and look for thesis
> mentor - you may provide project for them also).
> 
> Other students should be also good and most probably could communicate
> in English (but you can interview them to be sure).
> 
> Here are basic projects requirements:
> 
>   *
> 
> for 1 student, or for a team (1 student with biological + 1 with
> software development or CS background)
> 
>   *
> 
> project can be done for 3 months
> 
>   *
> 
> not very difficult project where you can guide
> 
>   *
> 
> educational :)
> 
> I believe there is no fee for mentoring, scholarship for students is
> fully optional (in most cases there is no scholarships). But I may be
> wrong, because I haven’t tried mentoring before - for sure it is never
> mentioned in registration forms for mentors or elsewhere :)
> 
> Projects will be announced at September, 17th. Mentors wish to see them
> by September, 10th.
> 
> If you are interested, you can write to team (at)
> bioinformaticsinstitute.ru <http://bioinformaticsinstitute.ru> to ask
> for details and describe your project. They have a Google Doc for
> project descriptions, but for now it is available only in Russian, I
> think if you’ll just write them and describe your project it will be ok
> (or I can give you a link to it).
> 
> 
> I could also help you while mentoring since I live in St.Petersburg and
> can go at that school at Saturday to find your student and try to
> persuade him/her not to be lazy :) Or even I can help them with some
> basic knowledge and/or coding - if you’ll decide to provide something
> related to structural bioinformatics, I’ll be happy to be involved =)
> 
> 
> -- 
> Regards,
> Tanya.
> 
> P.S. - I've also told this school's mentors about Outreachy internships
> program, but not sure if they'll decide to mention it. Some of my
> friends know about it and they are interested in bioinformatics-related
> projects. Andreas, I hope you are reading and will use this knowledge
> for a great good :)
> P.-P. S. - I just thought that it might help some of you to accelerate
> your work or research. That's why I finally decided to write this.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Updated gwama and plink1.9

[Afif Elghraoui]

Hello,

على الجمعـة 26 آب 2016 ‫15:06، كتب Dylan:
> Hi,
> I have updated gwama. Could someone upload it to unstable?
> 

Done.

> I have also updated plink1.9 but it is always unreproducible. So if
> someone can give me a tip to find why it is not reproducible, it would
> be great.
> 

Also uploaded, though I couldn't help you with the reproducibility
issue. Maybe it can be resolved for the next upload.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Updated galileo

[Afif Elghraoui]

على السبت 13 آب 2016 ‫15:18، كتب Dylan:
> Hi Afif,
> 
> Le 13 août 2016 7:08 AM, "Afif Elghraoui" <a...@debian.org> a écrit :
>>
>> Your d/watch file is not working properly with uscan. Is there a
>> particular reason that you have it pointing to the downloads page rather
>> than the tags?
>>
> 
> It was the recommended watch file for bitbucket projects which worked
> fine until some changes from upstream.
> I just updated the watch file to point it to the tags page, uscan works now.
> 
> Thanks for your review ;-)
> 

You're welcome. Thanks for preparing the package! It's been uploaded.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Updated galileo

[Afif Elghraoui]

Hi, Dylan,

على الجمعـة 12 آب 2016 ‫13:32، كتب Dylan:
> Hi,
> I have updated galileo. Could someone upload it to unstable?
> 

Your d/watch file is not working properly with uscan. Is there a
particular reason that you have it pointing to the downloads page rather
than the tags?

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: linuxbrew with homebrew/science - works!

[Afif Elghraoui]

Hello and apologies for the delay

[adding Tim to Cc since he was addressed in Steffen's last message]

على الأحد 31 تـمـوز 2016 ‫15:07، كتب Steffen Möller:
> 
> 
> On 30/07/16 10:15, Afif Elghraoui wrote:
>> Hi, all,
>>
>> على الخميس 28 تـمـوز 2016 ‫03:54، كتب Sascha Steinbiss:
>>>> I do not know what this means for Debian Med. It is a competition. And,
>>>>> with some early brain wash from the homebrew on the Mac I am now using
>>>>> on my desk, it also feels natural.
>> I personally would prefer a way to adapt our Debian packages for this
>> purpose. Surely, some of the effort for the packaging is duplicated
>> between us, the linuxbrew, and the conda people (not to mention just
>> other Linux distributions in general). If we can make Debian packages
>> installable without root permissions into user-specified directories,
>> our packages will have much more utility both in Debian and in other
>> operating systems.
> I basically see two possible forms of a transition:
>  A) dotdeb2bottle - so we would have some generic formula that takes a
>  .deb, unpacks it in #{prefix} and hopes that the symlinks just work
>  or does some post-processing.
>  @Tim, are you listening? The _old_ pre-2010 Bio-Linux way was to
>  basically create its debs by taking a Brew-like bottle and wrap it up
>  as a .deb. So, a formula doing it all backwards should be fine.

I don't think Tim follows the list, but is Cc'd here now.

>  B) debian2formula - This is a bit more tricky. We have the download URL,
>  preferably via watch, the one-lined description, the doi, the
> bioinformatics
>  tag, the install instructions, the dependencies ... maybe we have a bit
>  too many binary and arch-indep packages ...  but one could for
> quite some
>  packages find rewrites, I presume.
> 
>  What if we just changed debhelper install to the Formula's #{prefix}
>  instead of debian/?  
>>

I like your suggestion A best. I think extracting the package contents
to the installation location would be better than building the package
directly into it.

>>>
>>> Something I personally find interesting about Homebrew-science (but
>>> others here may disagree) is that they apparently have a more relaxed
>>> way of embracing upstream's way of distribution and building, which
>>> seems to accelerate turnover time for packaging a lot. For example,
>>> there is no requirement to build in a non-networked environment using
>>> already packaged dependencies only. While I am aware of the security and
>>> long-term maintainability considerations, this is difficult to beat for
>>> the pure purpose of distribution and easy installability, and indeed I
>>> have often seen their list of recipes contain new tools much earlier
>>> than Debian.
>> Indeed. One of my strongest motivations for being involved in Debian is
>> the integration that we do. While we can't have official packages that
>> follow such relaxed requirements, we might keep up in this regard with
>> some unofficial ([semi-]auto-generated? [1]) packages, but I think our
>> main problem is lack of support for unprivileged installation.
> I am with you, here. Avoiding redundant libraries is a major contributor
> to bring in scientific progress early. One is tempted to I think that as
> soon as developers recognize that with homebrew everyone can (even
> OS-independently) get the library installed, the motivation to redistribute
> external sources will weaken. But IMO the problem is less a matter of
> commodity
> than with a distrust in stable APIs.
> 

That sounds about right, but I'm not sure what to say to that.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: linuxbrew with homebrew/science - works!

[Afif Elghraoui]

Hi, all,

على الخميس 28 تـمـوز 2016 ‫03:54، كتب Sascha Steinbiss:
>> I do not know what this means for Debian Med. It is a competition. And,
>> > with some early brain wash from the homebrew on the Mac I am now using
>> > on my desk, it also feels natural.

I personally would prefer a way to adapt our Debian packages for this
purpose. Surely, some of the effort for the packaging is duplicated
between us, the linuxbrew, and the conda people (not to mention just
other Linux distributions in general). If we can make Debian packages
installable without root permissions into user-specified directories,
our packages will have much more utility both in Debian and in other
operating systems.


>> > Kind of nice is that the package
>> > names seem to be kept in sync with ours, e.g. I just noticed that STAR,
>> > our NGS aligner, is also called rna-star. And any such sync would be
>> > really nice to have so we can benefit from each other.
> I think keeping package names in sync is indeed very thoughtful and a
> good idea to do to reduce the amount of confusion and/or surprise to the
> end user, who basicallu only has to use 'brew install' on one machine
> and 'apt-get install' on the other.
> 
> Something I personally find interesting about Homebrew-science (but
> others here may disagree) is that they apparently have a more relaxed
> way of embracing upstream's way of distribution and building, which
> seems to accelerate turnover time for packaging a lot. For example,
> there is no requirement to build in a non-networked environment using
> already packaged dependencies only. While I am aware of the security and
> long-term maintainability considerations, this is difficult to beat for
> the pure purpose of distribution and easy installability, and indeed I
> have often seen their list of recipes contain new tools much earlier
> than Debian.

Indeed. One of my strongest motivations for being involved in Debian is
the integration that we do. While we can't have official packages that
follow such relaxed requirements, we might keep up in this regard with
some unofficial ([semi-]auto-generated? [1]) packages, but I think our
main problem is lack of support for unprivileged installation.

regards
Afif


1. https://wiki.debian.org/AutomaticPackagingTools

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: source-only uploads to new (was: Sponsoring request: ITK-4.10 (addendum))

[Afif Elghraoui]

Hello,

على الجمعـة 15 تـمـوز 2016 ‫04:35، كتب Gert Wollny:
> Am Donnerstag, den 14.07.2016, 19:44 -0500 schrieb Steve M. Robbins:
>> On Thursday, July 14, 2016 8:04:28 AM CDT Andreas Tille wrote:
>> It's too bad that source-only is not an option.  That seems an
>> arbitrary limitation and the wiki doesn't shed any light on it.  
> 
> I would guess that the mechanism to detect whether an upload carries
> new binary packages is based on the changes file, and in the source-
> changes it is not directly visible what binary packages are build.
> 

I'm not really sure about this. New binaries in source-only uploads are
somehow detected because they get automatically rejected for this reason
specifically.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: A common test-data package for genome assemblers

[Afif Elghraoui]

Hi, Sascha, and apologies for the delay

على الخميس 14 تـمـوز 2016 ‫08:57، كتب Sascha Steinbiss:
> 
>> I've had a couple packages that indicate the availability of data
>> outside of the source distribution that can be used to try out the
>> software (and make sure that it actually runs). I didn't think it was a
>> good idea to bundle the data in with the actual package since it doesn't
>> change between releases and would take up too much space on the archive
>> if it was bundled with every upstream tarball.
> 
> +1, and also it would be nice to know that there is actually something
> to assemble and one is not hitting corner cases with simulated reads
> (i.e. generating not enough coverage trying to keep the size down).
> For my autopkgtests that always required some fiddling.
> 
>> For example, at <http://canu.readthedocs.io/en/stable/quick-start.html>,
>> there are a few reduced datasets that can be used to run assemblies for
>> PacBio and Nanopore sequencing data. Those files can also be used for
>> tests of the sprai package, and possibly also for other long-read genome
>> assemblers. There's also the option of packaging the Assemblathon data
>> for this purpose, or using simulators to generate datasets for testing.
>>
>> Does anyone have suggestions or thoughts on this?
> 
> I've previously used pbsim, wgsim, GenomeTools' simreads (packaged) or
> Flux Simulator (not packaged) to generate very small read sets for
> reasonably sized reference chromosomes, small enough to distribute with
> the source tarballs of the packages to be tested or alternatively
> generating them on-the-fly as part of the test run. For me these were
> miniasm, rna-star and snpomatic.

That seems to be the best option given the current situation. I've just
been manually running tests before uploading to avoid having to
duplicate the data with every new upstream release, but that obviously
has many downsides.

> 
> I'd welcome a package containing known good test sets that would avoid
> duplication. One could also generate separate sets for genomic reads,
> RNA-seq reads, different sequencing platforms etc. What do you think?

Yes, I think this would be good. Pacific Biosciences has created a
package along these lines [1] to reduce duplication within their own
suite of software, but it's of course only for their own sequencing
platform.

The ones that Canu's developers suggest are genomic reads for PacBio and
Oxford Nanopore bacterial genome assembly, but they take significant
resources to run (so probably not a good idea for debci). I don't think
it would be too hard to make such a package for phage assembly, for
example, but I think this would just test the program to see if it
works. Getting a minimal dataset that would test assemblers in corner
cases would take some more work. I think we should reach out to the
upstream developers of these tools to try to pool efforts for such a
resource.

> For someone with little practical NGS experience to pick 'good' test
> sets (like me) this will be a huge help for adding tests where upstream
> doesn't provide test data.
> 

The problem of duplication and shared corner cases to test (for programs
that serve similar purposes) is also a very worthy reason.

Thanks and regards
Afif

1. https://github.com/PacificBiosciences/PacBioTestData

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: A common test-data package for genome assemblers

[Afif Elghraoui]

على الأربعاء 13 تـمـوز 2016 ‫22:57، كتب Charles Plessy:
> yes, this is an excellent idea.  Discussions about data packages
> spark from time to time (see https://wiki.debian.org/DataPackages
> for instance), and it would be exciting to see this happening in
> one way or the other !

Thanks for the link. Looks like one more for the to-do list..

Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: using `alternatives` for aligners and assemblers and promoting common interfaces

[Afif Elghraoui]

على الأربعاء 13 تـمـوز 2016 ‫10:58، كتب Michael Crusoe:
> You may be interested in the http://nucleotid.es/ & http://bioboxes.org/
> efforts.

Those do look interesting, but I was referring to a finer kind of
standardization. Many of these tools can take some of the same
parameters, so I was thinking of pushing to standardize that interface.
For example, PacBio's pbalign program defines such an interface and can
wrap blasr, bowtie, or gmap.

I do think it's probably too much effort for too little gain, though, so
I probably won't pursue it.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

using `alternatives` for aligners and assemblers and promoting common interfaces

[Afif Elghraoui]

Hi, all,

Another thought that has been floating around in my head: we have many
read aligners, variant/consensus callers, genome assemblers, and other
such tools that do the same job with different algorithms. I think it
makes sense to try to  manage them as alternatives[1] and work towards
standardizing their interfaces.

I also think that the variation in interfaces for these similar tools is
not because of any developer's attachment to them, but because there's
no real guideline for what to do (like, how to pass the reference
sequence-- some say -r while others might say --referenceFile).

On the other hand, besides better organization and potentially more
intuitive interfaces, I'm not sure whether undertaking this is worth the
effort. Are there any strong feelings about this?

regards
Afif


1. https://wiki.debian.org/DebianAlternatives


-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

A common test-data package for genome assemblers

[Afif Elghraoui]

Hi, all,

I've had a couple packages that indicate the availability of data
outside of the source distribution that can be used to try out the
software (and make sure that it actually runs). I didn't think it was a
good idea to bundle the data in with the actual package since it doesn't
change between releases and would take up too much space on the archive
if it was bundled with every upstream tarball.

For example, at <http://canu.readthedocs.io/en/stable/quick-start.html>,
there are a few reduced datasets that can be used to run assemblies for
PacBio and Nanopore sequencing data. Those files can also be used for
tests of the sprai package, and possibly also for other long-read genome
assemblers. There's also the option of packaging the Assemblathon data
for this purpose, or using simulators to generate datasets for testing.

Does anyone have suggestions or thoughts on this?

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: [ftpmas...@ftp-master.debian.org: mypy_0.4.1-2_amd64.changes REJECTED]

[Afif Elghraoui]

Hello,

على الإثنين 11 تـمـوز 2016 ‫11:10، كتب Michael Crusoe:
>> Hmmm, is there any need for a new build?  If the package builds now fine
>> as is (which I did not tested) I would write this insied the bug report
>> (not reproducible any more).
> 
> Yes a new build is needed, there are no binary packages; I did a source
> only upload.
> 
> It builds for me in an updated pbuilder chroot but I don't know how to
> trigger the build daemons to try again.
> 

You'd have to contact the corresponding buildd admin(s) and ask them to
requeue the package for building.

"""
The admins responsible for buildd's for a particular arch can be reached
at a...@buildd.debian.org, for example i...@buildd.debian.org.
""" https://www.debian.org/devel/buildd/

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Galaxy project producing their own Debian packages

[Afif Elghraoui]

Hello,

على الإثنين 27 حزيران 2016 ‫12:04، كتب Michael Crusoe:
> Python packages that need packaging:
> 
> bx-python
[...]

I had started some packaging work on bx-python as a dependency for
pbtranscript, but that seems not to be a dependency anymore, so I didn't
pursue it. In any case, bx-python development looks to me to have
stopped. I didn't find upstream very responsive either [1] (based on a
communication attempt and lack of activity on bitbucket). I started some
packaging, but it will need some hacking to work. I can push what I have
if anyone is interested in it.


> 
> This should a complete list, Nate promises that there are no hidden sub
> dependencies.
> 
> They also use a custom fork of pysam

What's the plan for this? Integrate the patches upstream or packaging
the fork?

regards
Afif

1.
https://bitbucket.org/james_taylor/bx-python/issues/59/tagged-releases-corresponding-to-those-on


-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name