from:"Alex Mestiashvili"

this one got bounced, one more is following :)

Alex

Please choose a free license for fasta3 components

Hi,

I'm writing you on behalf of the Debian Med team which is a group inside
Debian with the objective to package free software with relevance in
biology and medicine for official Debian. We are about to create a
debian package from fasta3 as you can see on our so called tasks biology
page[1].

According to the Debian Free Software Guidelines[2] which are widely
accepted as Open Source definition the current license of some files
such as src/smith_waterman_sse2.c and src/glo[bc]al_sse2.[ch] is not
free since it forbids free use of the software in commercial products.

I wonder whether you might consider changing the licensing to some free
license like GPL, BSD or MPL - just anything that has no such
restriction to non-commercial use and use of modified code.  You might
like to know that several other authors of biologic software recently
switched to free licenses (may be most prominently phylib).  The
advantage for you inside Debian would be a higher visibility of fasta3
(since we distribute it with metapackages) and a way better quality
assurance since Debian is running several tools to automatically detect
problems inside the distributed software.


Kind regards and thanks for your cooperation

Alex

[1] http://blends.debian.org/med/tasks/bio#fasta3
[2] https://www.debian.org/social_contract#guidelines

Please choose a free license for fasta3 components

Hi,

I'm writing you on behalf of the Debian Med team which is a group inside
Debian with the objective to package free software with relevance in
biology and medicine for official Debian. We are about to create a
debian package from fasta3 as you can see on our so called tasks biology
page[1].

According to the Debian Free Software Guidelines[2] which are widely
accepted as Open Source definition the current license of some files
such as src/smith_waterman_sse2.c and src/glo[bc]al_sse2.[ch] is not
free since it forbids free use of the software in commercial products.

I wonder whether you might consider changing the licensing to some free
license like GPL, BSD or MPL - just anything that has no such
restriction to non-commercial use and use of modified code.  You might
like to know that several other authors of biologic software recently
switched to free licenses (may be most prominently phylib).  The
advantage for you inside Debian would be a higher visibility of fasta3
(since we distribute it with metapackages) and a way better quality
assurance since Debian is running several tools to automatically detect
problems inside the distributed software.


Kind regards and thanks for your cooperation

Alex

[1] http://blends.debian.org/med/tasks/bio#fasta3
[2] https://www.debian.org/social_contract#guidelines

Re: Freeing fasta3 (Was: fasta3_36.3.8g-1_amd64.changes is NEW)

On 04/19/2018 02:44 PM, Steffen Möller wrote:
> 
> On 4/19/18 1:43 PM, Andreas Tille wrote:
>> Hi,
>>
>> On Thu, Apr 19, 2018 at 10:19:31AM +, Debian FTP Masters wrote:
>>> binary:fasta3 is NEW.
>>> binary:fasta3-doc is NEW.
>>> binary:fasta3-doc is NEW.
>>> binary:fasta3 is NEW.
>>> source:fasta3 is NEW.
>>>
>>> Your package has been put into the NEW queue, which requires manual action
>>> from the ftpteam to process. The upload was otherwise valid (it had a good
>>> OpenPGP signature and file hashes are valid), so please be patient.
>> nice.  Did anybody checked the only reason for making this package non-free:
>>
>>
>> Files: src/glo[bc]al_sse2.[ch]
>>src/smith_waterman_sse2.c
>> Copyright: 2006,2010 Michael Farrar 
>> License: Academics-only
>>  This program may not be sold or incorporated into a commercial product,
>>  in whole or in part, without written consent of Michael Farrar.  For
>>  further information regarding permission for use or reproduction, please
>>  contact: Michael Farrar at farrar.mich...@gmail.com.
>>
>>
>> I think chances to get 8 year old software freed from the restriction
>> are worth trying.  It would be nice if you could do so and record your
>> attempt here[1].
>>
>> [1] https://wiki.debian.org/DebianMed/SoftwareLiberation
> 
> I agree, Andreas. It should be well in the interest of the other authors
> to have
> that "academics only" constraint removed. They may even not be aware of it.
> 
> Alex kindly helped out (and nicely improved the packaging!) with his
> sponsoring.
> I had asked for it since it was nagging badly on the bottom of a long
> todo list
> and do not want open any extra mental slot for it. So, someone else please
> address such follow-ups.
> 
> Many thanks,
> 
> Steffen
> 
> 

Hi Steffen and Andreas,

Wouldn't it be better to dcut it now (if not too late), try to resolve
the issue and re-upload ?

Thanks,
Alex





signature.asc
Description: OpenPGP digital signature

Re: Please choose a free license for gmap

2018-02-28 Thread Alex Mestiashvili

Dear Thomas,

Taking into account the major rewrite of GMAP and GSNAP, I wonder if you
could consider the license change as well?

Thank you,
Alex, on behalf of Debian-Med.

On 09/05/2017 10:51 PM, Andreas Tille wrote:
> Hi Thomas,
> 
> thanks for you fast and positive response.  Feel free to contact our
> mailing list in case you might face problems.  We have some experience
> in licensing questions.
> 
> Kind regards
> 
>   Andreas.
> 
> On Tue, Sep 05, 2017 at 10:01:40AM -0700, Thomas Wu wrote:
>>
>> Hi Alex,
>>
>> Thanks for your note.  It's something I will consider.  In fact, our
>> previous department head, Robert Gentleman, was the author of the R
>> statistical package, and thought we should do this.  However, he left
>> our company some time ago, and we are still looking for a department
>> head.
>>
>> I would also have to consult with our legal department, since the
>> software was built using company resources and on company time.
>>
>> Regards,
>>
>> Tom
>>
>> -- 
>> Thomas D. Wu, M.D., Ph.D.
>> Principal Scientist, Bioinformatics & Computational Biology
>> Genentech, Inc., 1 DNA Way, South San Francisco, CA 94080
>> Phone: 650-225-5672, Fax: 650-225-5389
>> E-mail: t...@gene.com
>>
>>
>>
>> On Mon, Sep 04, 2017 at 04:25:50PM +0200, Alex Mestiashvili wrote:
>>> Hi,
>>>
>>> I'm writing you on behalf of the Debian Med team which is a group inside
>>> Debian with the objective to package free software with relevance in
>>> biology and medicine for official Debian.  As you might possibly know we
>>> have created packages also from gmap as you can see on our so
>>> called tasks biology page[1].
>>>
>>> According to the Debian Free Software Guidelines[2] which are widely
>>> accepted as Open Source definition the current license is not free since
>>> it forbids the use and distribution of modified copy under some
>>> conditions and also forbids free use of the software in commercial products.
>>>
>>> I wonder whether you might consider changing the licensing to some free
>>> license like GPL, BSD or MPL - just anything that has no such
>>> restriction to non-commercial use and use of modified code.  You might
>>> like to know that several other authors of biologic software recently
>>> switched to free licenses (may be most prominently phylib).  The
>>> advantage for you inside Debian would be a higher visibility of gmap
>>> (since we distribute it with metapackages) and a way better quality
>>> assurance since Debian is running several tools to automatically detect
>>> problems inside the distributed software.
>>>
>>>
>>> Kind regards and thanks for your cooperation
>>>
>>> Alex
>>>
>>> [1] http://blends.debian.org/med/tasks/bio#gmap
>>> [2] https://www.debian.org/social_contract#guidelines
>>>
>> End of quote
>>
>>
>

Re: RFS: bowtie/1.2.1.1+dfsg-1

2017-12-16 Thread Alex Mestiashvili

Hi All,

>> A new version has been released.
>> https://github.com/BenLangmead/bowtie/releases
>>
>> Please also note the license change.
> 
> Thanks a lot for both hints.  You can feel free to update the packaging
> in Git yourself if you want to.  Or Alex?  Please throw ENOTIME or
> something like this if you will not manage.
> 
> Kind regards
> 
>Andreas.
> 

the updated version of bowtie is in repository.

Best regards,
Alex

Re: [Debian-med-packaging] Bug#880347: bug squashing target: Probably bowtie 1.2.1.1 issue (Was: Bug#880347: bioperl-run: FTBFS: Test failures)

2017-12-07 Thread Alex Mestiashvili

On 12/07/2017 07:26 PM, Andreas Tille wrote:
> Hi Alex,
> 
> On Thu, Dec 07, 2017 at 06:12:05PM +0100, Alex Mestiashvili wrote:
>>
>> That's a trivial one, s/reads processed: 1000/reads processed: 2000/
>> I'll take care.
> 
> Cool!  Thanks a lot.
> 
> BTW, there are *lots* if easy ones - just in case this will keep
> motivation of all team members higher. ;-)
> 
> Kind regards
> 
>  Andreas. 
> 

Hi Andreas,
The fix is in the repository.
Bug usually look easy after, but not before the fix:)
I'll have another look.

Best regards,
Alex

Re: RFS: bowtie/1.2.1.1+dfsg-1

2017-10-21 Thread Alex Mestiashvili

On 10/20/2017 06:46 PM, Dominique Belhachemi wrote:
> On Thu, Oct 19, 2017 at 12:16 PM, Alex Mestiashvili <
> ames...@rsh2.donotuse.de> wrote:
> 
>> Hello,
>>
>> I've worked a bit on bowtie in git [0] and think that it is ready for
>> upload. It also presumably closes #864439. One of the issues I run
>> during package building is that bowtie unit tests fail on example6 and
>> exmaple9.
>> Could somebody who uses bowtie please comment on this ? Not sure if this
>> is something I should report upstream.
>>
>>
> Let's see what upstream has to say about this issue.
> 
> https://github.com/BenLangmead/bowtie/issues/66
> 

Thank you for opening the issue.
I didn't know that the test are actually the part of manual.

As this issue supposed to be fixed in the next release according the
answer on github, I guess it's ok to upload the package now as it solves
a FTBFS bug for mips64el.

Best regards,
Alex

RFS: bowtie/1.2.1.1+dfsg-1

2017-10-19 Thread Alex Mestiashvili

Hello,

I've worked a bit on bowtie in git [0] and think that it is ready for
upload. It also presumably closes #864439. One of the issues I run
during package building is that bowtie unit tests fail on example6 and
exmaple9.
Could somebody who uses bowtie please comment on this ? Not sure if this
is something I should report upstream.

bowtie -a --best --strata -v 2 --suppress 1,5,6,7 e_coli -c
ATGCATCATGCGCCAT > example6.out

bowtie 1.1.2-6

cat example6.out
-   gi|110640213|ref|NC_008253.1|   2852852 8:T>A

bowtie 1.2.1.1+dfsg-1

cat example6.out
-   gi|110640213|ref|NC_008253.1|   2852852 8:T>A
-   gi|110640213|ref|NC_008253.1|   148810  10:A>G,13:C>G
+   gi|110640213|ref|NC_008253.1|   1093035 2:T>G,15:A>T
-   gi|110640213|ref|NC_008253.1|   905664  6:A>G,7:G>T
-   gi|110640213|ref|NC_008253.1|   4930433 4:G>T,6:C>G

bowtie -a -m 3 --best --strata -v 2 e_coli --suppress 1,5,6,7 -c
ATGCATCATGCGCCAT  > example9.out

bowtie 1.1.2-6

cat example9.out
-   gi|110640213|ref|NC_008253.1|   2852852 8:T>A

bowtie 1.2.1.1+dfsg-1

produces empty example9.out

Thank you,
Alex

[0] https://anonscm.debian.org/git/debian-med/bowtie.git

Re: RFS: indelible

2017-10-02 Thread Alex Mestiashvili

On 10/02/2017 05:52 PM, Fabian Klötzl wrote:
> Hi,
> 
> On 02.10.2017 17:03, Alex Mestiashvili wrote:
>> A few notes to the package - lintian complains about non-https VCS
>> fields, a couple of typos and a hardening issue -
>>  indelible: hardening-no-bindnow usr/bin/indelible
> 
> Fixed the VCS URL, some typos (my lintian doesn't actually complain) and
> enabled hardening. Hope this is more to your liking.
> 
> Best,
> Fabian
> 

That was quick! Unfortunately I can not sponsor the upload as I am not a DD.

Best,
Alex

Re: RFS: indelible

2017-10-02 Thread Alex Mestiashvili

On 10/02/2017 04:09 PM, Fabian Klötzl wrote:
> Hi all,
> 
> indelible has accumulated some changes. It would be great if someone
> could tag + sponsor a new update.
> 
> Thanks,
> Fabian
> 
> https://anonscm.debian.org/cgit/debian-med/indelible.git/tree/
> 

Hi Fabian,

A few notes to the package - lintian complains about non-https VCS
fields, a couple of typos and a hardening issue -
 indelible: hardening-no-bindnow usr/bin/indelible

I usually run lintian this way:
 lintian -Iivc --pedantic $pkg.changes

Best regards,
Alex

Re: Help needed for #871234 FTBFS with GCC-7: error: type/value mismatch

2017-09-05 Thread Alex Mestiashvili

On Tue, Sep 5, 2017 at 8:44 PM, Jeff Epler <jep...@unpythonic.net> wrote:

> On Tue, Sep 05, 2017 at 01:55:58PM +0200, Alex Mestiashvili wrote:
> > GHash.hh:91:44: error: type/value mismatch at argument 1 in template
> > parameter list for 'template struct std::hash'
> >  while (pos
> Nothing in this line is intended to be a template parameter list, but it
> looks like gcc has decided something is; maybe it's "hash", which the
> compiler treats as std::hash due to e.g., an earlier "using" statement.
>
> If so, consider trying
>while (pos^ parenthesize ^
> so that the "<" can't introduce a template parameter list.
>
> My mental model of the C++ grammar doesn't explain to me why the
> compiler thinks this "<" can introduce a template parameter list, but
> that sure seems to be what the compiler states it is doing.  Usually
> when g++ and I disagree about C++ grammar, g++ is right...
>
> Jeff
>

Great! this solved the problem. Thank you very much!

Alex

Help needed for #871234 FTBFS with GCC-7: error: type/value mismatch

2017-09-05 Thread Alex Mestiashvili

Any help is greatly appreciated,
here it the gcc's complain:

In file included from gff.h:12:0,
 from gtf_tracking.h:12,
 from bundles.h:22,
 from replicates.h:10,
 from common.cpp:28:
GHash.hh: In member function 'GHash::GHashEntry*
GHash::NextEntry()':
GHash.hh:91:44: error: type/value mismatch at argument 1 in template
parameter list for 'template struct std::hash'
 while (pos

Please choose a free license for gmap

2017-09-04 Thread Alex Mestiashvili

Hi,

I'm writing you on behalf of the Debian Med team which is a group inside
Debian with the objective to package free software with relevance in
biology and medicine for official Debian.  As you might possibly know we
have created packages also from gmap as you can see on our so
called tasks biology page[1].

According to the Debian Free Software Guidelines[2] which are widely
accepted as Open Source definition the current license is not free since
it forbids the use and distribution of modified copy under some
conditions and also forbids free use of the software in commercial products.

I wonder whether you might consider changing the licensing to some free
license like GPL, BSD or MPL - just anything that has no such
restriction to non-commercial use and use of modified code.  You might
like to know that several other authors of biologic software recently
switched to free licenses (may be most prominently phylib).  The
advantage for you inside Debian would be a higher visibility of gmap
(since we distribute it with metapackages) and a way better quality
assurance since Debian is running several tools to automatically detect
problems inside the distributed software.


Kind regards and thanks for your cooperation

Alex

[1] http://blends.debian.org/med/tasks/bio#gmap
[2] https://www.debian.org/social_contract#guidelines

fisher_exact_test code, public-domain ?

2016-06-03 Thread Alex Mestiashvili

Hi All,

I am about to upload the new version of subread package, but not sure
what to do with a new file with unclear copyright.

I've already tried to contact both authors ( Kadosawa and Hopwood ) but
both emails don't exist anymore ..

Taking into account that the code is not too complicated, can I consider
it public-domain or just the same license as the source of subread ?

https://anonscm.debian.org/cgit/debian-med/subread.git/tree/src/test-fisher.c


Thanks,
Alex

Re: Aw: Re: sponsorship request for plip

2016-03-28 Thread Alex Mestiashvili

Hi Steffen,

On 03/28/2016 05:07 PM, "Steffen Möller" wrote:
> Hi Alex,
>
>> On 03/24/2016 06:18 PM, Andreas Tille wrote:
>>> time to follow other members of the team to become a DD? ;-)
>> Well, seeing that you trust in me is really motivating :)
> Well, your packages are typically brainless to sponsor.
> I tend to agree - you should already be a DD. Mind being
> advocated?
>
>

Thank you for the support! I'll give it a high priority in my todo list :)

Alex

Re: sponsorship request for plip

2016-03-24 Thread Alex Mestiashvili

Hi Andreas!

On 03/24/2016 06:18 PM, Andreas Tille wrote:
> Hi Alex,
> 
> time to follow other members of the team to become a DD? ;-)

Well, seeing that you trust in me is really motivating :)

> 
> Uploaded - thanks for your work, Andreas.

Thank you, that was really fast!
Alex

> 
> On Thu, Mar 24, 2016 at 05:50:27PM +0100, Alex Mestiashvili wrote:
>> Hi All,
>>
>> I am looking for sponsorship for plip package [0].
>> The previous version of the package was rejected by ftpmasters due to
>> unclear license of PDB files.
>> This time the pdb files are removed with Files-Excluded in d/copyright,
>> so I hope it will make through.
>>
>> Thank you,
>> Alex
>>
>> [0] http://anonscm.debian.org/cgit/debian-med/plip.git
>>
>>
>

sponsorship request for plip

2016-03-24 Thread Alex Mestiashvili

Hi All,

I am looking for sponsorship for plip package [0].
The previous version of the package was rejected by ftpmasters due to
unclear license of PDB files.
This time the pdb files are removed with Files-Excluded in d/copyright,
so I hope it will make through.

Thank you,
Alex

[0] http://anonscm.debian.org/cgit/debian-med/plip.git

Re: how to get list of debianmed packages

2016-03-14 Thread Alex Mestiashvili

Hi,

On 03/14/2016 04:38 PM, Olivier Sallou wrote:
> Hi,
> how can I get a programmatic list of debianmed packages, possibly by
> section (bioinformatics ,...) ?
> 
> Thanks
> 
> Olivier
> 

May be something like that ?

 aptitude search "?maintainer(debian-med-packag...@lists.alioth.debian.org)"

you can also customize the search, see

http://algebraicthunk.net/~dburrows/projects/aptitude/doc/en/ch02s03s05.html

Best,
Alex

Can "PDB" license be considered free ?

2016-03-07 Thread Alex Mestiashvili

Hi All,

I am going to package a software with pdb files in the test suite and
I wonder if the license below can be considered free.

 ftp://ftp.wwpdb.org/pub/pdb/advisory.txt

 
http://www.rcsb.org/pdb/static.do?p=general_information/about_pdb/policies_references.html

Thank you,
Alex

Re: Source of SubreadUserGuide

2015-09-05 Thread Alex Mestiashvili

On 09/05/2015 03:46 PM, Andreas Tille wrote:
> Hi Alex,
>
> On Sat, Sep 05, 2015 at 01:38:08PM +0200, Alex Mestiashvili wrote:
>>> Yes, that's comparable to compressed JS files:  You can provide the
>>> sources in debian/ dir.  I think it is not even mandatory to rebuild the
>>> PDF - but the user should be *enabled* to recreate the PDF.  At least
>>> this is what I understood.  If you have easy access to the source for
>>> now it would most probably the cheapest way to pass the NEW queue.
>>> Thorsten might insist if I'm wrong.
>> with the new upstream version of subread, I have the tex sources for the
>> pdf file.
> Good.
>  
>> The problem now is the images in the png format.
>> Can we distribute them without having the sources ?
>> ( I guess in most cases there are no sources for images ).
> You can edit PNG files with Gimp and thus there are easy ways to change.
> Decalring even PNGs as binary without source would be not sensible IMHO.

I see. According the exiftool output the images were created/edited on a
mac.
That's all I know.

>  
>> I've pushed the new package to the repository.
> So this can be uploaded?

Yes, but I can do it myself too, just wanted to ask before.

Thank you,
Alex

Re: Not able to build my package

2015-09-01 Thread Alex Mestiashvili

On 09/01/2015 02:10 PM, Andreas Tille wrote:
> On Tue, Sep 01, 2015 at 12:44:53PM +0200, Corentin Desfarges wrote:
>> I get this error :
>> The following packages have unmet dependencies:
>>  libvtk5.8v5 : Conflicts: libvtk5.8 but 5.8.0-17.5+b1 is to be
>> installed.
>> Unable to resolve dependencies!  Giving up...
>>
>> I guess it comes from the vtk transition, but do you see any way to fix it ?
> Currently I do not see a sensible way to deal with this.  You will break
> your testing system by installing packages from unstable and if you
> upgrade to unstable you will most probably also break your system.  I
> have created an unstable chroot if I need to do manual intervention into
> the build process - may be this is a way to solve your problem.
>
> Kind regards
>
>  Andreas.
>

I do the same, but use a LXC for my unstable build environment.
Linux containers are way more flexible than a chroot and provide enough
isolation from the host system.

may be an alternative way would be this ( not tested ):

* https://lists.debian.org/debian-mentors/2015/08/msg00390.html*

Regards,
Alex

sponsorship for plip

2015-07-17 Thread Alex Mestiashvili


Hello,

I am looking for sponsor for plip package:
Fully automated protein-ligand interaction profiler
 http://anonscm.debian.org/cgit/debian-med/plip.git

Currently it is available only as python2 version, but probably in the 
future a python3 compatible version will be available too.


Thank you,
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55a8e0d6.6050...@biotec.tu-dresden.de

Re: looking for sponsor for plip package

2015-06-19 Thread Alex Mestiashvili


On 06/19/2015 03:18 PM, Olivier Sallou wrote:

On 06/19/2015 02:54 PM, Alex Mestiashvili wrote:

Dear Debian Med folks,

I am looking for review and sponsorship for the
package plip - fully automated protein-ligand interaction profiler.

  http://anonscm.debian.org/cgit/debian-med/plip.git

Hi,
Python team asks that new packages are Python 2 AND 3 compatible.

So code should be compatible and package built with python2 and python3
helpers.

Olivier

Hi Oliver,

I'll check if I can make it python3 compatible.
Btw, do you know how can I name a python3 package if the name is not 
prefixed with 'python-' ?
Like if it would be python-plip, I would name it python3-plip in the 
d/control.

What would be the way to do it for 'plip'? plip3 ?

Thank you,
Alex





--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55841f2c.1020...@biotec.tu-dresden.de

Re: looking for sponsor for plip package

2015-06-19 Thread Alex Mestiashvili


On 06/19/2015 04:00 PM, Olivier Sallou wrote:


On 06/19/2015 03:54 PM, Alex Mestiashvili wrote:

On 06/19/2015 03:18 PM, Olivier Sallou wrote:

On 06/19/2015 02:54 PM, Alex Mestiashvili wrote:

Dear Debian Med folks,

I am looking for review and sponsorship for the
package plip - fully automated protein-ligand interaction profiler.

   http://anonscm.debian.org/cgit/debian-med/plip.git

Hi,
Python team asks that new packages are Python 2 AND 3 compatible.

So code should be compatible and package built with python2 and python3
helpers.

Olivier

Hi Oliver,

I'll check if I can make it python3 compatible.

you can try to use futurize to be python 2 and 3 compatible (expecting
that your dependencies are compatible for both too...)



That is interesting, thank you.

I am afraid that plip won't work with python3 because one of the
main dependency - pymol is python2 only. ( updated the repository right 
now )


Best regards,
Alex



--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/558424af.8030...@biotec.tu-dresden.de

looking for sponsor for plip package

2015-06-19 Thread Alex Mestiashvili


Dear Debian Med folks,

I am looking for review and sponsorship for the
package plip - fully automated protein-ligand interaction profiler.

 http://anonscm.debian.org/cgit/debian-med/plip.git


Thank you,
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/558410ea.1020...@biotec.tu-dresden.de

Re: subread: limit architectures

2015-05-19 Thread Alex Mestiashvili


On 05/16/2015 07:28 AM, Andreas Tille wrote:

Hi Alex,

On Fri, May 15, 2015 at 09:56:39PM +0200, Alex Mestiashvili wrote:

The problem is that the code builds but tests fail in some strange way.

Well, if I understand things correctly the test is part of the package
build process and thus in the case of a failed test no package is build,
right?


I think in order to fix that, one would need to understand the algorithm..
I even can not form the question to narrow the possible field of problem...

I admit I have a bit strange gut feeling about algorithms that work on
some but not all architectures.


agree, but the fact remains - it doesn't work on ARM/Powerpc, but 
perfectly works on Intell..


I've installed armel and powerpc qemu images ( thanks to aurel32 
https://people.debian.org/~aurel32/qemu/ )
and  did more tests for the other tools of the subread suite and 
unfortunately subread-buildindex - one of

the core tools also fails in some strange way.
So I assume that there is more work need to be done to get subread in 
shape for these architectures.


Best regards,
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/555b3716.1060...@biotec.tu-dresden.de

Re: Source of SubreadUserGuide

2015-05-07 Thread Alex Mestiashvili

On 05/07/2015 09:22 PM, Andreas Tille wrote:
 Hi Alex,

 On Thu, May 07, 2015 at 09:06:11PM +0200, Alex Mestiashvili wrote:
 BTW, it would be possible to add the download from some URL and
 add it as additional file(s) in debian/ dir.
 Do you mean that I can add the source files to debian directory and use
 these files to build the pdf, so there will be no need to wait for the
 next releases ?
 Yes, that's comparable to compressed JS files:  You can provide the
 sources in debian/ dir.  I think it is not even mandatory to rebuild the
 PDF - but the user should be *enabled* to recreate the PDF.  At least
 this is what I understood.  If you have easy access to the source for
 now it would most probably the cheapest way to pass the NEW queue.
 Thorsten might insist if I'm wrong.

 Kind regards

   Andreas.


No, I do not have the sources, but I've already prepared the +dfsg
version in the repository.

Can you please have a look and upload it ?

Thank you,
Alex


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/554bc921.3050...@biotec.tu-dresden.de

Re: Source of SubreadUserGuide

2015-05-07 Thread Alex Mestiashvili

On 05/07/2015 05:00 PM, Andreas Tille wrote:
 Hi Alex,

 On Thu, May 07, 2015 at 03:24:04PM +0200, Alex Mestiashvili wrote:
 I work on packaging of subread for Debian/Ubuntu distributions. In
 order to ship the doc/SubreadUserGuide.pdf we need the source code
 for the documentation.
 Would it be possible to ship the source code of the user guide in
 the next releases?
 BTW, it would be possible to add the download from some URL and
 add it as additional file(s) in debian/ dir.

 Kind regards

  Andreas.


Sorry Andreas,  I haven't undertstood this.

Do you mean that I can add the source files to debian directory and use
these files to build the pdf, so there will be no need to wait for the
next releases ?

Thank you,
Alex


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/554bb7a3.3020...@biotec.tu-dresden.de

Source of SubreadUserGuide

2015-05-07 Thread Alex Mestiashvili


Dear Dr Wei Shi,

I work on packaging of subread for Debian/Ubuntu distributions. In order 
to ship the doc/SubreadUserGuide.pdf we need the source code for the 
documentation.
Would it be possible to ship the source code of the user guide in the 
next releases?


Thank you,
Alex Mestiashvili ( on behalf of Debian Med 
https://wiki.debian.org/DebianMed )



--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/554b6774.3090...@biotec.tu-dresden.de

Re: (formal) Debian Med Howto?

2015-05-06 Thread Alex Mestiashvili

On 05/06/2015 10:05 AM, Steffen Möller wrote:

Quite some of us may visit on researchgate.net from time to time, or seqanswers.com, .. or .. put
your favorite community site here ... and mentally follow the one or other question. While I am far
from always knowing the answer, I find it nonetheless often inspiring to think along. With Debian
Med, and other Debian blends, we by now have quite an infrastructure available to solve myriads of
problems in computational biology. If you combine that with knowing many of us (partially) employed
for teaching, I thought that it may be worthwhile to collect a series of exercises in a how
to or workflow manner. I thought of some triplets like:

Problems: How do I investigate this or that with constraints M and N?
Answer:
a) you need to first solve the following problems: X, Y, Z
b) install the following packages from Debian Med: A, B, C
c) execute the following: command -param1 M -param2 N

Search engines hopefully pick those up and thus render Debian Med more visible.
Are there any immediate ideas on how to implement any such thing? The folks
behind MyExperiment.org are doing very much what I thought this should at some
point look alike, but it is difficult to edit with a mere combination of a text
editor and git, which I sense it should be. I was myself involved in a
respective effort from 2008 that influenced the Taverna command line
integration at http://taverna.nordugrid.org/sharedRepository/index.php. And I
know about quite some readers of this list are contributing to
https://groups.google.com/forum/#!forum/common-workflow-language . But this may
all be a bit too remote to our routine to be embraced any quickly and to
immediately appeal to our community. We would already get quite far with just
describing that something can be done, and possibly already listing caveats and
alternatives to overcome those, which is well beyond what a workflow is about.

You may have some more ideas.

Best,

Steffen

Hi Steffen,

From technical point of view a git powered wiki hosted on Debian's
infrastructure would work.

I just found this link: https://wiki.debian.org/Alioth/ikiwiki

Can we make use of it ?

Best,
Alex

--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/554a27eb.2030...@biotec.tu-dresden.de

tophat: embedded samtools copy

2015-03-25 Thread Alex Mestiashvili


Dear Maintainer,

Tophat 2.0.13 started to include a convience copy of samtools 0.1.18, 
I believe
this is technically a violation of Debian policy. Though I'm not sure 
how hard

it would be properly fix the issue.

Diane Trout


Hi Diane,

Please see this thread for more details:
 https://lists.debian.org/debian-med/2014/10/msg4.html

Until we have a solution we need to ship samtools 0.1.18 with tophat.

Regards,
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5512bcdb.4000...@biotec.tu-dresden.de

Bug#779014: ITP: subread -- toolkit for processing next-gen sequencing data

2015-02-23 Thread Alex Mestiashvili


Package: wnpp
Severity: wishlist
Owner: Alexandre Mestiashvili mailatgo...@gmail.com
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-med@lists.debian.org

* Package name: subread
  Version : 1.4.6-p1
  Upstream Author : shi at wehi dot edu dot au
* URL : http://subread.sourceforge.net/
* License : GPL3
  Programming Lang: C
  Description : toolkit for processing next-gen sequencing data

Subread aligner can be used to align both gDNA-seq and RNA-seq reads.
Subjunc aligner was specified designed for the detection of exon-exon
junction. For the mapping of RNA-seq reads, Subread performs local
alignments and Subjunc performs global alignments.


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54eaf8db.9020...@biotec.tu-dresden.de

Re: Aw: tophat FTBFS on mips, mipsel and hurd-i386

2014-07-09 Thread Alex Mestiashvili


On 07/08/2014 12:25 PM, Steffen Möller wrote:

Hello Alex,


Gesendet: Dienstag, 08. Juli 2014 um 11:25 Uhr
Von: Alex Mestiashvili a...@biotec.tu-dresden.de
An: Debian Med Project List debian-med@lists.debian.org
Betreff: tophat FTBFS on mips, mipsel and hurd-i386

Hi,

the last version of tophat fails to build on mips, mipsel and hurd-i386.
The build errors look fixable, but still does it really makes sense to
build tophat for this architectures?
As far as I see the minimum requirements for tophat are at least 4Gb of
RAM, so hurd-i386 as well as other i386 builds are not needed I think.

Not sure about mips/mipsel archs, are there any use cases for tophat ?

Thank you,
Alex


https://buildd.debian.org/status/package.php?p=tophat


Hi Steffen,


There is also a missing build dependency on libbam-dev for armel and sparc.
Sigh. This is truly tedious, just, it is really helpful should this help
indicate the one or other programming issue. It seems a bit like it.



as far as I can see, libbam-dev ( samtools ) doesn't build on sparc and 
armel:

https://buildd.debian.org/status/package.php?p=samtoolssuite=sid



I do not truly know about what to suggest. There is no direct wire to
upstream from my side. You do not have access to the developer machines,
yet, right? Any help from anyone else?

Best,

Steffen




No I don't have, though I've never asked for it.
I can test on armel and powerpc,  but not on mips or sparc.

Best,
Alex




--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53bd4584.9080...@biotec.tu-dresden.de

tophat FTBFS on mips, mipsel and hurd-i386

2014-07-08 Thread Alex Mestiashvili


Hi,

the last version of tophat fails to build on mips, mipsel and hurd-i386.
The build errors look fixable, but still does it really makes sense to 
build tophat for this architectures?
As far as I see the minimum requirements for tophat are at least 4Gb of 
RAM, so hurd-i386 as well as other i386 builds are not needed I think.


Not sure about mips/mipsel archs, are there any use cases for tophat ?

Thank you,
Alex


https://buildd.debian.org/status/package.php?p=tophat






--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53bbb8f9.9060...@biotec.tu-dresden.de

Re: pyscanfcs, ITP:#751846

2014-06-18 Thread Alex Mestiashvili


Hi Andreas,

On 06/18/2014 04:01 PM, Andreas Tille wrote:

Hi Alex,

could you please consider fixing this:

$ lintian pyscanfcs_0.2.2-1_amd64.changes
I: pyscanfcs: capitalization-error-in-description python Python


I thought it is because of wxPython, but it was the lower case python 
who caused the complain.. fixed.



I: pyscanfcs: possible-documentation-but-no-doc-base-registration


Done.



I used

   dcut dm --uid Alexandre Mestiashvili --allow pyscanfcs

to grant upload permission for you - just tell me if this might
not work for the first upload.

Thanks for your work on this

Andreas.




Thanks !
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53a1b3f0.3020...@biotec.tu-dresden.de

pyscanfcs, ITP:#751846

2014-06-17 Thread Alex Mestiashvili


Hello,

I am looking for review and upload of my package - pyscanfcs, ITP:#751846.
If everything is fine could you please also grant me the upload privilege?

Thank you,
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53a04cc9.8020...@biotec.tu-dresden.de

Re: pyscanfcs, ITP:#751846

2014-06-17 Thread Alex Mestiashvili


Hi Andreas,

On 06/17/2014 06:52 PM, Andreas Tille wrote:

Hi Alex,

On Tue, Jun 17, 2014 at 04:12:25PM +0200, Alex Mestiashvili wrote:

I am looking for review and upload of my package - pyscanfcs, ITP:#751846.
If everything is fine could you please also grant me the upload privilege?

Without having the time to have a thorough look I see to things:

   1. I doubt that debian/compat with content 9 will fit to
   debhelper (= 7.4.3)
  lintian will surely blame this.


My bad, that was the last commit which I didn't check :)
Fixed in the repository.



   2. python-wxgtk2.8 - we recieved some bug reports where people want
  to bump to wx3.0.  Any chance to try this?


I would be glad to try it, but I couldn't find python bindings for wx3.0
as far as I see there are only 3 packages: wx3.0-headers, examples and 
localization.




Thanks for your work on this, real check later (if nobody else would
beat me for sure)

   Andreas.



Last time I used cme fix dpkg-control to fix the control file.
It seems that it doesn't work anymore, did you experience any problems 
with it lately ?


Thanks,
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53a08a04.5090...@biotec.tu-dresden.de

Re: help needed for #733352


On 04/11/2014 12:29 AM, Diane Trout wrote:

On Thursday, April 10, 2014 15:30:21 Alex Mestiashvili wrote:

Dear mentors,

I would greatly appreciate if somebody would help with the #733352, I've
spent a couple of hours trying to resolve the issue but my cpp skills
are rather poor.

Thank you,
Alex

The patch below deals with one of the compile errors. I don't know if just
hiding the const modifier is better than pushing const-ness further into
tophat.

Unfortunately the next const error I get is even worse. Const-ness seems to
get flipped between appendValue and trying to create a seqan::Gaps...

Diane


diff --git a/src/segment_juncs.cpp b/src/segment_juncs.cpp
index e3acc46..d73e0d6 100644
--- a/src/segment_juncs.cpp
+++ b/src/segment_juncs.cpp
@@ -2056,8 +2056,8 @@ void juncs_from_ref_segs(RefSequenceTable rt,
  
  MotifMap ims;
  
-seqan::DnaStringReverseComplement rev_donor_dinuc(donor_dinuc);

-seqan::DnaStringReverseComplement rev_acceptor_dinuc(acceptor_dinuc);
+seqan::DnaStringReverseComplement
rev_donor_dinuc(const_castDnaString(donor_dinuc));
+seqan::DnaStringReverseComplement
rev_acceptor_dinuc(const_castDnaString(acceptor_dinuc));
  
  if (talkative)

  fprintf(stderr, Collecting potential splice sites in islands\n);





Hi Diane,

Cool, thank you a lot, we are one step further!
Still I think that the upstream should try to fix it or we should 
reintroduce back SeqAn-1.3.


Best regards,
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5347b9a7.1020...@biotec.tu-dresden.de

can't push to cufflinks git repository: access denied or repository not exported:


Hi All,

I've prepared update for cufflinks [0], but when I try to push the 
changes I get the following message:


 fatal: remote error: access denied or repository not exported: 
/debian-med/cufflinks.git


Does it matter if remote is
 git://anonscm.debian.org/debian-med/cufflinks.git
or
git://git.debian.org/debian-med/cufflinks.git  ?

Also I can access git.debian.org with my key (malex-guest).

Do you have any hints?

Thank you,
Alex

[0] http://anonscm.debian.org/gitweb/?p=debian-med/cufflinks.git


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53481216.7020...@biotec.tu-dresden.de

Re: can't push to cufflinks git repository: access denied or repository not exported:


Hi Andreas,

I updated origin to ssh://git.debian.org/git/debian-med/cufflinks.git
and after that I could push the changes.
Something must be wrong with git setup there.
In all other git repositories  I have git protocol ( 
git://git.debian...) both for push and pull.


Anyway, thanks for the idea with ssh !

Alex

On 04/11/2014 06:32 PM, Andreas Tille wrote:

Hi Alex,

you need to use

git+ssh://git.debian.org/git/debian-med/cufflinks.git

(or simpler

ssh://git.debian.org/git/debian-med/cufflinks.git  )

I think it is sufficient to change remote origin url in your repository
- but I'm not sure about this.




Hope this helps

Andreas.

On Fri, Apr 11, 2014 at 06:02:30PM +0200, Alex Mestiashvili wrote:

Hi All,

I've prepared update for cufflinks [0], but when I try to push the
changes I get the following message:

  fatal: remote error: access denied or repository not exported:
/debian-med/cufflinks.git

Does it matter if remote is
  git://anonscm.debian.org/debian-med/cufflinks.git
or
git://git.debian.org/debian-med/cufflinks.git  ?

Also I can access git.debian.org with my key (malex-guest).

Do you have any hints?

Thank you,
Alex

[0] http://anonscm.debian.org/gitweb/?p=debian-med/cufflinks.git


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53481216.7020...@biotec.tu-dresden.de





--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53486286.2090...@biotec.tu-dresden.de

Re: help needed for #733352


On 04/11/2014 11:52 PM, Andreas Tille wrote:

Hi Alex,

On Fri, Apr 11, 2014 at 11:45:11AM +0200, Alex Mestiashvili wrote:

Cool, thank you a lot, we are one step further!

Perhaps it makes sense to contact upstream and propose the patch (in
Git) and ask for further help.  Would you volunteer to do this?


Done:
 https://groups.google.com/forum/#!topic/tuxedo-tools-users/TCyKinjd2Wc
though my English skills for a polite message are not very good :)
Forgot to CC to debian-med, but if there will be any activity I'll forward.




Still I think that the upstream should try to fix it or we should
reintroduce back SeqAn-1.3.

This should be the last resort - but yes, if nothing else helps
we should probably do this.

Kind regards

Andreas.



but may be than we simply can leave seqan-1.3 in the tophat's source ?
I think at some point tophat will switch to seqan-1.4 too ( probably 
when seqan devs vill release 1.6 :) ), but we can win the time and have 
working tophat in the distribution before this happens.


Best regards,
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53486fe2.2010...@biotec.tu-dresden.de

Re: force bowtie2 transition to testing

2014-04-10 Thread Alex Mestiashvili


On 04/09/2014 10:56 PM, Andreas Tille wrote:

Hi Thorsten,

On Wed, Apr 09, 2014 at 10:18:02PM +0200, Thorsten Alteholz wrote:

May be also pinging our ftpmaster assistant? ;-)

Hmm, sorry, but I don't do rm's. They are far too exciting for my
poor heart.

:-)


But you might ask on #debian-ftp for a more robust person ...

I was not aware that simple arch-specific deletes at maintainer request
need a robust mandate ... but anyway.

Meanwhile Alex might consider fixing tophat's C++ problem (#733352)
since nobody seems to fel really responsible and I failed fixing it.

Kind regards

Andreas.


Hi Andreas,

I've played a bit with tophat, but couldn't resolve the issue.
I've asked for the help on mentors list, let's see if it helps :)

Best regards,
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53469e4e.9050...@biotec.tu-dresden.de

force bowtie2 transition to testing

2014-04-09 Thread Alex Mestiashvili


Hello,

bowtie2 has stuck in unstable because of change in supported architectures.
I've opened #742614, but haven't received any reaction so far.

Is there anything else one can do to force the transition ?

Thank you,
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53456a5e.8000...@biotec.tu-dresden.de

RM: bowtie2 [i386 hurd-i386 kfreebsd-i386] -- ANAIS; new release does not build on architectures other than amd64

2014-03-25 Thread Alex Mestiashvili


X-Debbugs-Cc: a...@biotec.tu-dresden.de

Package: ftp.debian.org
Severity: normal

Dear FTP Masters,

New upstream release of bowtie2 doesn't build on mentioned in the 
subject architectures.
In order to force transition from unstable to testing could you please 
consider removal of packages in testing with non amd64 architectures ?
Also even if we could provide i386 builds in the past, it seems that 
nobody is using it on i386 because normally it requires big amounts of 
memory.


Thank you,
Alex

Note: this was a request for a partial removal from testing, converted 
in one for unstable



--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53318bb3.8000...@biotec.tu-dresden.de

RM: bowtie2 [i386 hurd-i386 kfreebsd-i386] -- ANAIS; new release does not build on architectures other than amd64

2014-03-25 Thread Alex Mestiashvili


Package: ftp.debian.org
Severity: normal

Dear FTP Masters,

New upstream release of bowtie2 doesn't build on mentioned in the 
subject architectures.
In order to force transition from unstable to testing could you please 
consider removal of packages in testing with non amd64 architectures ?
Also even if we could provide i386 builds in the past, it seems that 
nobody is using it on i386 because normally it requires big amounts of 
memory.


Thank you,
Alex

Note: this was a request for a partial removal from testing, converted 
in one for unstable



--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53318ed2.4010...@biotec.tu-dresden.de

Re: [Debian-med-packaging] bowtie2-2.2.0 no 32bit builds anymore

2014-02-21 Thread Alex Mestiashvili


On 02/21/2014 02:17 PM, Olivier Sallou wrote:

On 02/21/2014 02:11 PM, Alex Mestiashvili wrote:

Hi All,

The new version of bowtie2 was released recently and it seems that it
works only on 64 bit platforms.

http://anonscm.debian.org/gitweb/?p=debian-med/bowtie2.git;a=blob;f=Makefile


lines 141-143.

If program is coded to support only 64 bits arch, this may require to
limit the available archs.
Most computers are 64bits now and it is a difficulty to code programs to
manage both when you are looking at managing large data.


Hi Olivier,

Sure I can limit the archs, just want to be sure that I am not missing 
anything.




Could anybody please have a look or try to build for i386 the source
to confirm/disprove the sentence above ?

I see it also uses sse, with no test condition, so it will fails on some
architectures.


we had this problem in the past too, the previous version was built only 
for:


 amd64 i386 hurd-i386 kfreebsd-amd64 kfreebsd-i386

now it seem to get limited to amd64 only.


Best regards,
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53076c92.6030...@biotec.tu-dresden.de

Re: Aw: Fwd: pycorrfit_0.8.0-2~beta-2_amd64.changes REJECTED

2014-01-07 Thread Alex Mestiashvili


Hi Steffen,

I refreshed now - here is the thread:
https://lists.debian.org/debian-devel-announce/2012/09/msg8.html
I am also not sure if Andreas has done it already or not.

Anyway, thanks a lot.
Alex

On 01/07/2014 08:19 AM, Steffen Möller wrote:

Hi Alex,
the Debian Maintainer scheme has seen a change such that one needs to 
explicitly allow every individual uploader - separately from the 
package upload. I presume this package to have not been on the radar 
before. I can address this ... back home in a couple of  hours.

Steffen
*Gesendet:* Montag, 06. Januar 2014 um 16:45 Uhr
*Von:* Alex Mestiashvili a...@biotec.tu-dresden.de
*An:* Debian Med Project List debian-med@lists.debian.org
*Betreff:* Fwd: pycorrfit_0.8.0-2~beta-2_amd64.changes REJECTED
happy New Year to All Debian Med folks  :)

I wanted to upload the new release of pycorrfit, but it seems that I 
don't have permission for that.


Do you know if I will be able to do it after the previous one is 
migrated to testing, or do I need to ask the permission in a some 
special way?


Actually I tried to upload the second version 0.8.1 shortly after the 
0.8.0-2~beta-2, but before I noticed the reject...

So most probably the 0.8.1 will be rejected too.

Thank you,
Alex


 Original Message 
Subject:pycorrfit_0.8.0-2~beta-2_amd64.changes REJECTED
Date:   Mon, 06 Jan 2014 15:25:43 +
From:   Debian FTP Masters ftpmas...@ftp-master.debian.org
To: 	Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org, Alexandre Mestiashvili 
a...@biotec.tu-dresden.de


ACL dm: not allowed to upload source package 'pycorrfit'

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Fwd: pycorrfit_0.8.0-2~beta-2_amd64.changes REJECTED

2014-01-06 Thread Alex Mestiashvili


happy New Year to All Debian Med folks  :)

I wanted to upload the new release of pycorrfit, but it seems that I 
don't have permission for that.


Do you know if I will be able to do it after the previous one is 
migrated to testing, or do I need to ask the permission in a some 
special way?


Actually I tried to upload the second version 0.8.1 shortly after the 
0.8.0-2~beta-2, but before I noticed the reject...

So most probably the 0.8.1 will be rejected too.

Thank you,
Alex


 Original Message 
Subject:pycorrfit_0.8.0-2~beta-2_amd64.changes REJECTED
Date:   Mon, 06 Jan 2014 15:25:43 +
From:   Debian FTP Masters ftpmas...@ftp-master.debian.org
To: 	Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org, Alexandre Mestiashvili 
a...@biotec.tu-dresden.de




ACL dm: not allowed to upload source package 'pycorrfit'

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.

Re: Please be prepared for a move of tasks files for Debian Med from SVN to Git (Was: looking for a review for pycorrfit)

2013-12-17 Thread Alex Mestiashvili




btw, how do I update the tasks page?

I was looking for it in debian-med policy and checkout the
debian-med tasks from svn,
but the link in README seem to be broken:
http://blends.alioth.debian.org/blends/ch-sentinel.en.html

Hmmm, from what README, did you got this link.


The README in the root of debian-med from svn.


   It definitely needs
fixing.  The reason are two migration steps.  The first one was from
SGML to XML in the documentation which changed the file names which was
not backed up by some symlinks.  The next transition was done from
blends.alioth.debian.org to blends.debian.org.  While I installed
redirects to the new location the old file names of the doc where not
regarded.  I now just installed symlinks at the old locations so the
old links should work again (at least the one you posted above) but
all those old READMEs should be fixed in any case.

Just let me know if you have any trouble with updating the tasks files.
Since you either need to be a DD or a member of the blends team you
will perhaps face permission problems.  On the other hand:  What do you
want to change?

$ grep pycorrfit *
bio:Depends: pycorrfit


I see, in that I case I don't need to change anything.



So the package is included and the framework will atomatically notice
that it migrated from Vcs to NEW queue.  Just watch the sentinel page
tomorrow. :-)


Cool, I didn't know that it works this way!


As the subject of this mail says it is planed to move Debian Med tasks
files from SVN to Git in the not so far future.  I just did the
migration for Debian Science and Debian Med will follow in the beginn
of next year.  I'm just announcing this to enable you to rise your
voice if there are strong reasons against this move.


I see, thanks for the information.


Kind regards

Andreas.





Best regards,
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52b02786.1090...@biotec.tu-dresden.de

Re: looking for a review for pycorrfit


Hi Andreas,

Also I am not sure what to do with png images in doc-src/Images directory.
There are svg files as well, but I haven't managed to correctly
convert the svg files to png.
It would be great if you would give me ideas or examples.

I'm not sure what upstream is intending with these files but I would
trust that the install mechanism does reasonable things.  When starting
the program at least the help menu displays an image.  There are several
different image sizes under

/usr/share/icons/hicolor

which are used by various desktop systems (which I not use).

Kind regards

   Andreas.


Thanks for looking on it.

It seems that my question is misleading, there are number of pictures in 
png and svg formats.

the ones with png extensions are used in the documentation.
I wanted to know if there is a way to convert the svg pictures to png ( 
svg are the source images) during package build.
I tried that with rsvg-convert, but then the png images look quite 
different from the original png.


Thanks,
Alex





--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52aebeaf.2010...@biotec.tu-dresden.de

Re: looking for a review for pycorrfit


Hi Simon,

Hi!

The manpage mentions documentation it at

/usr/share/doc/pycorrfit/PyCorrFit_doc.pdf.gz

which is not true.


skainz@foo:~$ dpkg -L pycorrfit |grep pdf
/usr/share/pyshared/pycorrfit_doc/PyCorrFit_doc.pdf
/usr/lib/python2.7/dist-packages/pycorrfit_doc/PyCorrFit_doc.pdf

Please fix that.


Fixed in git, thanks a lot for spotting the problem.



Regards,

Simon





--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52aebf14.9040...@biotec.tu-dresden.de

Re: looking for a review for pycorrfit


On 12/16/2013 10:33 AM, Andreas Tille wrote:

Hi Alex,

On Mon, Dec 16, 2013 at 09:49:51AM +0100, Alex Mestiashvili wrote:

It seems that my question is misleading, there are number of
pictures in png and svg formats.
the ones with png extensions are used in the documentation.
I wanted to know if there is a way to convert the svg pictures to
png ( svg are the source images) during package build.
I tried that with rsvg-convert, but then the png images look quite
different from the original png.

According to my experience it is not needed to *re*create the pngs.  The
same is true for PDFs.  The important thing is that the TeX source is
provided but sometimes it makes no sense to add a bunch of Build-Depends
and bother autobuilders just to recreate what is just delivered.  The
main point is that the source *exists*.  So if it causes trouble to you
to create the PNG in a reasonable way at commandline comparable to what
most probably was done in InkScape (or something like this) I'd simply
use the existing PNG files and be done with it.

Kind regards

Andreas.

I see, I've just asked the upstream and he use Inkscape to convert the 
images.

Also He is going to release the new version in a couple of weeks.
Do you think we should wait and upload the new version or is it ok to 
upload the current one?


Best regards,
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52aedd1a.4040...@biotec.tu-dresden.de

Re: looking for a review for pycorrfit


On 12/16/2013 01:34 PM, Andreas Tille wrote:

On Mon, Dec 16, 2013 at 11:59:38AM +0100, Alex Mestiashvili wrote:

Also He is going to release the new version in a couple of weeks.
Do you think we should wait and upload the new version or is it ok
to upload the current one?

If you just prepared the current one I think uploading is fine.
Do you need a sponsor?


Yes, please, I need a sponsor for the very first time at least.
Should I place the package on mentors? if it saves your time ..


Kind regards and thanks for your work on this

 Andreas.


Best regards,
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52af1cb7.1050...@biotec.tu-dresden.de

Re: looking for a review for pycorrfit


On 12/16/2013 05:16 PM, Andreas Tille wrote:

Hi Alex,

On Mon, Dec 16, 2013 at 04:31:03PM +0100, Alex Mestiashvili wrote:

Yes, please, I need a sponsor for the very first time at least.

Done.


Great!


Should I place the package on mentors? if it saves your time ..

No.  I personally totally ignore mentors.d.o and only consider VCS for
sponsering.

Thanks for your work on this

  Andreas.

PS: You might like to consider becoming a DD ...


I think about it, but I am afraid I still need to learn a lot :)

btw, how do I update the tasks page?

I was looking for it in debian-med policy and checkout the debian-med 
tasks from svn,

but the link in README seem to be broken:
http://blends.alioth.debian.org/blends/ch-sentinel.en.html

Thanks,
Alex


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52af2a44.4060...@biotec.tu-dresden.de

looking for a review for pycorrfit

2013-12-13 Thread Alex Mestiashvili


Hi All,

I am looking for a review for my package pycorrfit [0], ITP #730640.
Lintian is clear, but I am pretty sure there are hidden issues :)

Also I am not sure what to do with png images in doc-src/Images directory.
There are svg files as well, but I haven't managed to correctly convert 
the svg files to png.

It would be great if you would give me ideas or examples.

Thanks,
Alex


[0] http://anonscm.debian.org/gitweb/?p=debian-med/pycorrfit.git;a=summary


--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52ab2a57.1040...@biotec.tu-dresden.de

Re: [Debian-med-packaging] Processed: These errors are caused by bug in libboost1.49-dev

2013-05-16 Thread Alex Mestiashvili

On 05/16/2013 09:34 AM, Debian Bug Tracking System wrote:
 Processing commands for cont...@bugs.debian.org:
 
 reassign 708439 libboost1.49-dev
 Bug #708439 [src:autodock-vina] autodock-vina: FTBFS: xtime.hpp:23:5: error: 
 expected identifier before numeric constant
 Bug reassigned from package 'src:autodock-vina' to 'libboost1.49-dev'.
 No longer marked as found in versions autodock-vina/1.1.2-2.
 Ignoring request to alter fixed versions of bug #708439 to the same values 
 previously set
 reassign 708443 libboost1.49-dev
 Bug #708443 [src:dc-qt] dc-qt: FTBFS: xtime.hpp:23:5: error: expected 
 identifier before numeric constant
 Bug #708445 [src:dc-qt] dc-qt: FTBFS: xtime.hpp:23:5: error: expected 
 identifier before numeric constant
 Bug reassigned from package 'src:dc-qt' to 'libboost1.49-dev'.
 Bug reassigned from package 'src:dc-qt' to 'libboost1.49-dev'.
 No longer marked as found in versions dc-qt/0.2.0.alpha-4.1.
 No longer marked as found in versions dc-qt/0.2.0.alpha-4.1.
 Ignoring request to alter fixed versions of bug #708443 to the same values 
 previously set
...


Hello,

Should I reassign the Bug#707416: tophat: FTBFS:

as it was done with bugs above ?

Or should I simply close it ?

The problem with tophat is solved with the new libboost1.49-dev.

Thanks,
Alex


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5194b139.9080...@biotec.tu-dresden.de

Re: Bowtie2 ready for upload?

2012-11-05 Thread Alex Mestiashvili

On 11/04/2012 05:38 AM, Charles Plessy wrote:
 Le Fri, Nov 02, 2012 at 11:25:54PM -0400, Carlos Borroto a écrit :

 I uploaded latest upstream version for Bowtie2, which dropped the beta
 tag. The package seems ready, but I haven't worked in this package
 before. Alex, could you please take a look and see if things look
 good.
 
 Hi Carlos and Alex,
 
 Bowtie 2.0.2 looks good to me.  I pushed two minor commits to remove obsoleted
 Lintian overrides and use pristine-tar by default.
 
 I recommend to upload directly to Unstable.  In case a RC bug were found in
 2.0.0-beta6-3, it would not make much sense spending time correcting this beta
 version anyway.
 
 Lastly, have you considered adding regression tests using the example data ?
 You can see http://dep.debian.net/deps/dep8/ for one framework available in
 Debian and Ubuntu.
 
 Have a nice Sunday,
 
Hi,

After all job is done it also looks good for me :).
Just a few questions:

I've uploaded 2.0.0-beta7-1 to unstable, but the notice of that has
vanished from debian/changelog, I updated the changelog to reflect this
change.

Regarding the regression tests, I've tried to create one, but I couldn't
see at which state the test is executed.
The lintian complains:
W: bowtie2 source: unknown-field-in-dsc testsuite
could it be that lintian is not in sync so far ? or am I doing it wrong ?

Thank you,
Alex


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/509792b2.9070...@biotec.tu-dresden.de

Re: Bowtie2 ready for upload?

2012-11-05 Thread Alex Mestiashvili

On 11/05/2012 04:01 PM, Carlos Borroto wrote:
 On Mon, Nov 5, 2012 at 5:19 AM, Alex Mestiashvili
 a...@biotec.tu-dresden.de wrote:
   
 I've uploaded 2.0.0-beta7-1 to unstable, but the notice of that has
 vanished from debian/changelog, I updated the changelog to reflect this
 change.

 
 Odd, I replaced 2.0.0-beta7-1 with 2.0.2-1, cause it was marked as
 UNRELEASED. See commit:
 http://anonscm.debian.org/gitweb/?p=debian-med/bowtie2.git;a=commitdiff;h=c1ba6b64379ca8d55db8852e825904f7cf194110
   
Yes, you are right. Probably I forgot to push the changes.
 And raw changelog before the commit:
 http://anonscm.debian.org/gitweb/?p=debian-med/bowtie2.git;a=blob_plain;f=debian/changelog;hb=b4d4b3dcd68198cb373e2b7ca79a74b8b6069138

 However you are correct,  2.0.0-beta7-1 was already uploaded to
 unstable. I thought in order to upload, the changelog would have to be
 properly marked for the right Debian release. I also like merging
 unreleased version after updating to a new upstream version, as I
 don't see the point of keeping the changelog clutter with unreleased
 stuffs.
   
Agree, it makes more sense.
 Cheers,
 Carlos
   

Regards,
Alex


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5097d8fa.3010...@biotec.tu-dresden.de

Re: fixing rc-version-greater-than-expected-version

2012-08-14 Thread Alex Mestiashvili

On 07/31/2012 10:21 AM, Andreas Tille wrote:
 On Tue, Jul 31, 2012 at 10:01:53AM +0200, Alex Mestiashvili wrote:
   
 I would like to avoid adding the epoch in the middle of the minor
 releases, i.e. -betaX.
 Because the only reason is lintian's warning and not a significant
 change in the software.

 And I also agree with Charles that it is better to wait until we really
 need to add the epoch.
 If we will need to do so at all.
 
 Well, you are the person who is actively working on this package and if
 you have your way to make sure

   1. you will notice new upstream releases
   2. users will detect new package version

 this is fine for me whatever method you choose.

 Kind regards

   Andreas. 

   
Hi Andreas,
first of all sorry for the delay.
I'll go with overriding for 2.0.0-beta7 now and switch to epoch with the
next release -beta8.
Thank you and Charles for the useful discussion,
Alex


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/502a109d.3020...@biotec.tu-dresden.de

Re: fixing rc-version-greater-than-expected-version

2012-08-14 Thread Alex Mestiashvili

On 08/14/2012 11:23 AM, Andreas Tille wrote:
 On Tue, Aug 14, 2012 at 10:47:25AM +0200, Alex Mestiashvili wrote:
   
 I'll go with overriding for 2.0.0-beta7 now and switch to epoch with the
 next release -beta8.
 
 If I were you I would simply leave the warning - there is no point in
 overriding anything that should be changed later anyway.

 Kind regards

 Andreas. 

   
This definitely makes sense, but what if the package will be rejected
because of this warning?

Regards,
Alex


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/502a1aa0.3010...@biotec.tu-dresden.de

Re: fixing rc-version-greater-than-expected-version

2012-07-31 Thread Alex Mestiashvili

On 07/31/2012 08:14 AM, Andreas Tille wrote:
 On Tue, Jul 31, 2012 at 08:24:57AM +0900, Charles Plessy wrote:
   
   $ dpkg --compare-versions 2.0.0-beta6-1 gt 1:2.0.0  echo $?

 There are people who do not like epochs - but this is the clean way.
   
 indeed, I think that using an epoch is a bit too much at the moment.
 
 Could you please explain why you consider epoch as a bit too much?

   
 For
 instance, we do not know how long 2.0.0 will last, as sometimes minor
 corrections are released very shortly after a release, and packages with
 version numbers like 2.0.1 would solve our problem.

 I would recommend to ignore the warning until 2.0.0 is released.
 
 In this case version 2.0.0-beta6 users will not notice the final
 release.  I fail to see your problem in using a technique which was
 invented exactly for this purpose.
  
 Kind regards

 Andreas.

   

Hi Andreas,

I would like to avoid adding the epoch in the middle of the minor
releases, i.e. -betaX.
Because the only reason is lintian's warning and not a significant
change in the software.

And I also agree with Charles that it is better to wait until we really
need to add the epoch.
If we will need to do so at all.

Best regards,
Alex


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/501790f1.2020...@gmail.com

bowtie2 messed up git repository

2012-07-30 Thread Alex Mestiashvili

Hi All,

Could you please suggest what is better in the following case:
2 weeks ago I imported the new upstream (2.0.0-beta7) version of bowtie2
to the repository, but than I decided to revert back to the old commit.
Here is the discussion why I decided so [0].
After all I used push --force to revert to the old commit, but it seems
that I forgot to revert tags.
Now the commit is 13 days old and there is tag 2.0.0-beta7 which doesn't
allow me to import the same version again.
Would it be acceptable to remove this tag and commit a new one with the
same name?

[0] http://lists.debian.org/debian-med/2012/07/msg00179.html

Thank you,
Alex


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50164e86.1030...@gmail.com

fixing rc-version-greater-than-expected-version

2012-07-30 Thread Alex Mestiashvili

Hi All,

I just imported the new upstream version for bowtie2 and now lintian
gives me the following warning:

N: Processing binary package bowtie2 (version 2.0.0-beta7-1, arch i386) ...
W: bowtie2: rc-version-greater-than-expected-version 2.0.0-beta7  2.0.0
(consider using 2.0.0~beta7)

In general the message is totally clear  2.0.0-beta7 is higher than
2.0.0, but if I consider using 2.0.0~beta7 then my updated version will
become lower than any previous version.
Ffor example:

dpkg --compare-versions 2.0.0-beta6-1 gt 2.0.0~beta7-1 echo $?

returns 0 exit code...

What should I do in such case? override the warning?

Thank you,
Alex


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/501682e0.5000...@gmail.com

Re: fixing rc-version-greater-than-expected-version

2012-07-30 Thread Alex Mestiashvili

On 07/30/2012 04:17 PM, Andreas Tille wrote:
 On Mon, Jul 30, 2012 at 02:49:36PM +0200, Alex Mestiashvili wrote:
   
 I just imported the new upstream version for bowtie2 and now lintian
 gives me the following warning:

 N: Processing binary package bowtie2 (version 2.0.0-beta7-1, arch i386) ...
 W: bowtie2: rc-version-greater-than-expected-version 2.0.0-beta7  2.0.0
 (consider using 2.0.0~beta7)

 In general the message is totally clear  2.0.0-beta7 is higher than
 2.0.0, but if I consider using 2.0.0~beta7 then my updated version will
 become lower than any previous version.
 Ffor example:

 dpkg --compare-versions 2.0.0-beta6-1 gt 2.0.0~beta7-1 echo $?

 returns 0 exit code...
 
 Well, at some point in time you somehow did a bad choice for the RC
 versions (and to prevent this the lintian check was invented - probably
 to late for your case).
  
   
True, you read my mind :)
 What should I do in such case? override the warning?
 
 I'd call this a dangerous way because it will close your eyes in such
 cases in the future.  You should decide about your plan how to number
 the real bowtie 2.0.0 release because also

   $ dpkg --compare-versions 2.0.0-beta6-1 gt 2.0.0 echo $?
   0

 is the case.  If you simply override the warning users of 2.0.0-beta6-1
 do not see any upgrade path on their machines before, say 2.0.1~alpha1.
   
I see, thank you for the hint.
 The proper way to deal with such problems is using an epoch:

   $ dpkg --compare-versions 2.0.0-beta6-1 gt 1:2.0.0  echo $?

   
this depend on the way upstream will call the non-beta version.
In case of version clash it is fine for me to start use epochs.
But what to do if I want to upload the package ?
Will it be fine to upload it with the warning ?
 There are people who do not like epochs - but this is the clean way.

 Kind regards

Andreas.

   

Thank you,
Alex


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5016a374.1030...@gmail.com

bowtie2 rc-version-greater-than-expected-version

2012-07-17 Thread Alex Mestiashvili

Hello,

I just imported a new upstream version of bowtie2 and lintian gives me
the following warning:

 bowtie2 source: rc-version-greater-than-expected-version 2.0.0-beta7 
2.0.0 (consider using 2.0.0~beta7)

How should I continue now ? change imported and following beta versions
to 2.0.0~betaX or leave it like it is ?
There are already bowtie2-2.0.0-beta6 in the distribution and I am
afraid that uploading 2.0.0~beta7 will mix up versions order.

Thank you,
Alex


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50053103.7030...@gmail.com

Re: bowtie2 rc-version-greater-than-expected-version

2012-07-17 Thread Alex Mestiashvili

On 07/17/2012 11:56 AM, Charles Plessy wrote:
 Le Tue, Jul 17, 2012 at 11:31:47AM +0200, Alex Mestiashvili a écrit :
   
 I just imported a new upstream version of bowtie2 and lintian gives me
 the following warning:

  bowtie2 source: rc-version-greater-than-expected-version 2.0.0-beta7 
 2.0.0 (consider using 2.0.0~beta7)

 How should I continue now ? change imported and following beta versions
 to 2.0.0~betaX or leave it like it is ?
 There are already bowtie2-2.0.0-beta6 in the distribution and I am
 afraid that uploading 2.0.0~beta7 will mix up versions order.
 
 Hi Alex,

 given that the changes have stayed in our repositories for less than a day, 
 and given
 that our audience is not that broad, I am tempted to suggest to simply reset 
 or rebase.

 To push with --force, you will need to log in git.debian.org, and temporarly
 disable the denyNonFastforwards configuration option, which is currently set 
 to
 'true'.

 Have a nice day,

   

Hi Charles,
Done.
I hope people who have checked it out already also read debian-med.l.d.o
...

Thank you,
Alex




-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50057cfb.1050...@biotec.tu-dresden.de

Re: bowtie2 rc-version-greater-than-expected-version

2012-07-17 Thread Alex Mestiashvili

On 07/17/2012 04:55 PM, Alex Mestiashvili wrote:
 On 07/17/2012 11:56 AM, Charles Plessy wrote:
   
 Le Tue, Jul 17, 2012 at 11:31:47AM +0200, Alex Mestiashvili a écrit :
   
 
 I just imported a new upstream version of bowtie2 and lintian gives me
 the following warning:

  bowtie2 source: rc-version-greater-than-expected-version 2.0.0-beta7 
 2.0.0 (consider using 2.0.0~beta7)

 How should I continue now ? change imported and following beta versions
 to 2.0.0~betaX or leave it like it is ?
 There are already bowtie2-2.0.0-beta6 in the distribution and I am
 afraid that uploading 2.0.0~beta7 will mix up versions order.
 
   
 Hi Alex,

 given that the changes have stayed in our repositories for less than a day, 
 and given
 that our audience is not that broad, I am tempted to suggest to simply reset 
 or rebase.

 To push with --force, you will need to log in git.debian.org, and temporarly
 disable the denyNonFastforwards configuration option, which is currently set 
 to
 'true'.

 Have a nice day,

   
 
 Hi Charles,
 Done.
 I hope people who have checked it out already also read debian-med.l.d.o
 ...

 Thank you,
 Alex




   

And returning back to the problem:
as far as I understand changing version from let's say 2.0.0-beta6 to
2.0.0~beta6 makes the version 2.0.0~beta6 lower that the original.
for example:
$dpkg --compare-versions 2.0.0-beta6-1 gt 2.0.0~beta7-1  echo $?
0
What can we do with that ? the only solution I see is to keep the old
versions format and do not change to ~ as lintian suggests.

Best regards,
Alex














-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50058524.6050...@biotec.tu-dresden.de

Re: new software ready for inspection: situs

2012-07-16 Thread Alex Mestiashvili

On 07/16/2012 09:49 AM, Mickaël Canévet wrote:
 On Fri, 2012-07-13 at 15:22 +0200, Alex Mestiashvili wrote:
   
 On 07/13/2012 03:02 PM, Mickaël Canévet wrote:
 
 On Fri, 2012-07-13 at 14:54 +0200, Andreas Tille wrote:
   
   
 Hi,

 On Fri, Jul 13, 2012 at 02:52:34PM +0200, Alex Mestiashvili wrote:
 
 
 On 07/13/2012 02:41 PM, Mickaël Canévet wrote:
   
   
 Is it better now ?

   
 
 
 Yes, now it looks better,
   
   
 It might be just me, but 

 $ git pull
 remote: Counting objects: 4, done.
 remote: Compressing objects: 100% (3/3), done.
 remote: Total 4 (delta 0), reused 0 (delta 0)
 Unpacking objects: 100% (4/4), done.
 From git+ssh://git.debian.org/git/debian-med/situs
  * [new branch]  pristine-tar - origin/pristine-tar
  * [new branch]  upstream   - origin/upstream
 Already up-to-date.
 $ git branch
 * master

 ... just another Git secret to me that git pull claims to have pulled
 the new branches but a git branch does not show these???

 
 
 but it seems that debian directory is missing from the master branch...
   
   
 I can confirm that this is the case.

 
 
 OK, then I made something wrong. I created then debian folder with a
 patch for the Makefile that remove the linking toward the included
 libfftw, but forgot to add it to git.

 Is it better after 'git add debian; git push' ?
   
   
 You also can tag it (or git push --tags)

 I haven't build it so far but:

 - debian/changelog you'll need to open the ITP bug
 
 Fixed

   
 - debian/rules - no need in commented text.( dh-make template)
 
 Fixed

   
 - debian/copyright should follow DEP5 guidelines [0]
 
 Fixed

   
Thanks!
 - debian/patches/Makefile.patch should have a DEP3 header [1]
 
 I'm not sure how quilt will react if I modify by hand the .patch file...
   
I think the correct way is to use combination of quilt pop; quilt -e header

Best regards,
Alex


   
 I also included .pc directory. I think it belongs to quilt. I don't know
 if I had to add it.

   
   
 you can add it to ~/.gitignore
 *.pc/


 
 Cheers

   
   
 Kind regards

   Andreas.

 -- 
 http://fam-tille.de

 
 
   
   
 Best regards,
 Alex

 [0] http://dep.debian.net/deps/dep5/#examples
 [1] http://dep.debian.net/deps/dep3/


 
   


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5003ccb5.3010...@biotec.tu-dresden.de

Re: No top level Makefile.

On 07/13/2012 11:20 AM, Mickaël Canévet wrote:
 Hello,

 I have a small newbie packaging question.

 The program I'm trying to package has no top level Makefile, the
 Makefile and the source is located in a 'src' subfolder.

 Should I create a patch that creates a top level Makefile or customize
 the debian/rules file so that it goes to 'src' subfolder to run make ?

 If so, what should be then modification to put in the rules file ?

 Thanks a lot.

 Mickaël
   

Hi Mickaël,

Try to change debian/rules like that:
 
dh $@ --sourcedirectory=src


Best regards,
Alex


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fffe9bd.7020...@biotec.tu-dresden.de

Re: new software ready for inspection: situs

On 07/13/2012 02:24 PM, Mickaël Canévet wrote:
 Dear all,

 I just uploaded my first package to alioth: situs.

 I choose this one because one of my users just asked me to install it on
 his machine and it seamed to be easy to package, so I did it.

 Could you review it and tell me how I could improve it.

 Cheers,
 Mickaël
   

Hi Mickaël,

I see that pristine-tar and upstream brunches are missing .
have you forgotten to push all branches?
git push --all ?

In case you haven't seen DebianMed's  policy page, it's here:
http://debian-med.alioth.debian.org/docs/policy.html

Best regards,
Alex


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5000175e.5070...@biotec.tu-dresden.de

Re: new software ready for inspection: situs

On 07/13/2012 02:41 PM, Mickaël Canévet wrote:
 Is it better now ?

   
Yes, now it looks better,
but it seems that debian directory is missing from the master branch...

Also could you please do not top-post.
http://wiki.debian.org/FAQsFromDebianUser#What_is_top-posting_.28and_why_shouldn.27t_I_do_it.29.3F
Thanks,
Alex


-- 
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50001a12.3000...@biotec.tu-dresden.de

Re: new software ready for inspection: situs