Fwd: Processing of dcut.Michael_R__Crusoe__michael_crusoe_gmail_com_.1462615038.28130.commands

2016-05-07 Thread Michael Crusoe
Ugh, how do I re-upload a rejected package?
-- Mesaj redirecționat --
De la: "Debian FTP Masters" 
Dată: 7 mai 2016 11:59 a.m.
Subiect: Processing of
dcut.Michael_R__Crusoe__michael_crusoe_gmail_com_.1462615038.28130.commands
Către: 
Cc:

Log of processing your commands file
/dcut.Michael_R__Crusoe__michael_crusoe_gmail_com_.1462615038.28130.commands:

> rm --searchdirs mypy_0.4-1_source.changes
mypy_0.4-1_source.changes did not match anything
No files to delete
> rm --searchdirs mypy_0.4-1.dsc
mypy_0.4-1.dsc did not match anything
No files to delete
> rm --searchdirs mypy_0.4.orig.tar.gz
mypy_0.4.orig.tar.gz did not match anything
No files to delete
> rm --searchdirs mypy_0.4-1.debian.tar.xz
mypy_0.4-1.debian.tar.xz did not match anything
No files to delete

Greetings,

Your Debian queue daemon (running on host franck.debian.org)


Re: Processing of dcut.Michael_R__Crusoe__michael_crusoe_gmail_com_.1462615038.28130.commands

2016-05-07 Thread Mattia Rizzolo
If the package has been rejected you just need to upload it again (after
having fixed whatever problem leaded to the reject).  You don't have to
dcut anything.

On Sat, 7 May 2016, 12:00 p.m. Michael Crusoe, 
wrote:

> Ugh, how do I re-upload a rejected package?
> -- Mesaj redirecționat --
> De la: "Debian FTP Masters" 
> Dată: 7 mai 2016 11:59 a.m.
> Subiect: Processing of
> dcut.Michael_R__Crusoe__michael_crusoe_gmail_com_.1462615038.28130.commands
> Către: 
> Cc:
>
> Log of processing your commands file
> /dcut.Michael_R__Crusoe__michael_crusoe_gmail_com_.1462615038.28130.commands:
>
> > rm --searchdirs mypy_0.4-1_source.changes
> mypy_0.4-1_source.changes did not match anything
> No files to delete
> > rm --searchdirs mypy_0.4-1.dsc
> mypy_0.4-1.dsc did not match anything
> No files to delete
> > rm --searchdirs mypy_0.4.orig.tar.gz
> mypy_0.4.orig.tar.gz did not match anything
> No files to delete
> > rm --searchdirs mypy_0.4-1.debian.tar.xz
> mypy_0.4-1.debian.tar.xz did not match anything
> No files to delete
>
> Greetings,
>
> Your Debian queue daemon (running on host franck.debian.org)
>


Re: mypy_0.4-1_source.changes REJECTED

2016-05-07 Thread Sascha Steinbiss
Hi Michael,

> FYI, I responded to the activity poll for me Debian Developer
> application on April 25th but I haven't heard any reply.

Maybe FD haven't processed your reply yet, or there's no AM free at the
moment? As my application has been AM approved a week ago, I guess there should
be one free soon ;)

Cheers
Sascha

> On Fri, May 6, 2016 at 2:19 PM, Debian FTP Masters
>  > wrote:
> 
> 
> 
>ACL dm: not allowed to upload source package 'mypy'
> 
>===
> 
>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.
> 
> 
> 
> 
> --
> Michael R. Crusoe  michael.cru...@gmail.com
> 
> Community Engineer Common Workflow Language project
> _https://impactstory.org/u/-0002-2961-9670_   +32 (0) 2 808 25 52
>+1 480 627 9108


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: fails to build against htslib 1.3.1

2016-05-07 Thread Charles Plessy
Control: forwarded -1 https://github.com/samtools/htslib/issues/374

Le Wed, May 04, 2016 at 09:10:48PM +0900, Charles Plessy a écrit :
> Le Wed, May 04, 2016 at 11:29:27AM +0200, Andreas Tille a écrit :
> > 
> > that developers of quite important libs (important in terms of breaking
> > about 20 packages - probably way more unpackaged software) are not able
> > to craft a reliable interface.  I wonder whether we should try to
> > explain them the trouble they are creating with their release management
> > and whether we should upload any new version to experimental first and
> > test other packages against it.
> 
> let's not discard too quickly the possibility that this was really a bug
> and not a design decision.
> 
> I reported the problem at ;
> let's see the answer.

Good news, the answer is that the "incompatibility" is only in the test suite
of samtools, which took into account a failure caused by a bug present in
htslib 1.3 and fixed in htslib 1.3.1.

I expect that it applies to bcftools as well.

Have a nice week-end,

-- 
Charles



Re: Packging jModelTest for Debian and versioning

2016-05-07 Thread Andreas Tille
Hi Diego,

I wonder whether I missed something but I have not found any new
protest3 version which is not using netbeans.  May be you simply
forgot to tag it on Github?

Kind regards and thanks for your cooperation

Andreas.

On Mon, Jan 18, 2016 at 01:45:59PM +0100, Andreas Tille wrote:
> Hi Diego,
> 
> On Sat, Jan 16, 2016 at 02:30:58AM +0100, Diego Darriba López wrote:
> > I though I have already answered. Sorry for that. Effectively, that is the 
> > project for BrowserLauncher.
> 
> OK, I've packaged this and uploaded to the Debian new queue.
>  
> > I will upload the next release for ProtTest in the next days. The 
> > dependency has been removed, but there is also a recently found bug I need 
> > to fix.
> 
> Sounds good!
> 
> Thanks for your kind cooperation
> 
>   Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de



Fwd: [Debian-med-packaging] Bug#823673: samtools: FTBFS in testing

2016-05-07 Thread Olivier Sallou
Hi Charles,
seems that we have cross bugs/mails with samtools.

Has samtools been updated accordingly to match  libhts >= 1.3.1 ? I understand 
that yes from previous emails, but is described bug linked to the otherbug?


Thanks

Olivier

- Mail transféré -
> De: "Santiago Vila" 
> À: "Debian BTS" 
> Envoyé: Samedi 7 Mai 2016 15:03:45
> Objet: [Debian-med-packaging] Bug#823673: samtools: FTBFS in testing
> 
> Package: samtools
> Version: 1.3.1-1
> Severity: serious
> 
> Dear maintainer:
> 
> This package currently fails to build from source in stretch.
> 
> 
> === Testing mpileup.reg regressions ===
> 
> UNEXPECTED FAIL: Output mismatch for $samtools mpileup -x -d 8500 -B -f
> mpileup.ref.fa deep.sam|awk '{print $4}'
> See FAIL-47.out.1 vs expected/47.out
> 
> 
> The full build log is attached.
> 
> I see that this package required a change recently for htslib 1.3.1.
> However, if this only builds now with libhts >= 1.3.1, then the
> Build-Depends field should be updated accordingly.
> 
> Thanks.
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging

samtools_1.3.1-1_amd64-20160507-1455.gz
Description: GNU Zip compressed data


Re: Processing of dcut.Michael_R__Crusoe__michael_crusoe_gmail_com_.1462615038.28130.commands

2016-05-07 Thread Michael Crusoe
Okay, thanks!

On Sat, May 7, 2016 at 12:31 PM, Mattia Rizzolo  wrote:

> If the package has been rejected you just need to upload it again (after
> having fixed whatever problem leaded to the reject).  You don't have to
> dcut anything.
>
> On Sat, 7 May 2016, 12:00 p.m. Michael Crusoe, 
> wrote:
>
>> Ugh, how do I re-upload a rejected package?
>> -- Mesaj redirecționat --
>> De la: "Debian FTP Masters" 
>> Dată: 7 mai 2016 11:59 a.m.
>> Subiect: Processing of
>> dcut.Michael_R__Crusoe__michael_crusoe_gmail_com_.1462615038.28130.commands
>> Către: 
>> Cc:
>>
>> Log of processing your commands file
>> /dcut.Michael_R__Crusoe__michael_crusoe_gmail_com_.1462615038.28130.commands:
>>
>> > rm --searchdirs mypy_0.4-1_source.changes
>> mypy_0.4-1_source.changes did not match anything
>> No files to delete
>> > rm --searchdirs mypy_0.4-1.dsc
>> mypy_0.4-1.dsc did not match anything
>> No files to delete
>> > rm --searchdirs mypy_0.4.orig.tar.gz
>> mypy_0.4.orig.tar.gz did not match anything
>> No files to delete
>> > rm --searchdirs mypy_0.4-1.debian.tar.xz
>> mypy_0.4-1.debian.tar.xz did not match anything
>> No files to delete
>>
>> Greetings,
>>
>> Your Debian queue daemon (running on host franck.debian.org)
>>
>


-- 
Michael R. Crusoe  michael.cru...@gmail.com
Community Engineer Common Workflow Language project
https://impactstory.org/u/-0002-2961-9670   +32 (0) 2 808 25 58
+1 480 627 9108


Re: Open-source MRI hardware initiative project

2016-05-07 Thread Yaroslav Halchenko
I just want to complement (inlined with original email below) to
already good responses, and hope that you Broche would continue the
discussion by providing your feedback to our feedback ;)

On Sat, 09 Apr 2016, Broche, Lionel wrote:
> Hello Debian-Med team,

> I am a researcher in MRI hardware at the University of Aberdeen,
> Scotland. I am currently working on the development of a completely new
> type of MRI system (see ffc-mri.org), but I would like to avoid the
> traditional route of commercialisation as I see many problems with it.
> Instead, I have been thinking for a while of preparing an initiative for
> the development of open-source hardware in MRI.

> The aim of this initiative would be, in a first stage, to pool the
> technical solutions already in the public domain together so as to help
> small research labs like mine and, in a second stage, to create a rally
> point for these labs to share knowledge, resources and to organise
> collective work. If this proves successful, it may expand into a
> complete open source MRI hardware platform but that would be in the far
> future. I already approached several research groups who expressed their
> enthusiasm about this idea so there would be several academic
> participants to start with (at least 3, probably 5 to 8), and some of
> them are already willing to provide some designs.

> I would like to get some advices from the Debian Med community regarding
> several aspects:
> - What solution would you think is the most appropriate to organise a
> community portal? I do not have any IT help from my University on this
> project but I am willing to put a bit of my own money to get a server
> somewhere if necessary. Bear in mind that I have little training on how
> to maintain a website, though I can take some time to learn.

since no IT/$ support ATM, the best way IMHO would be to effectively use
available "Free" infrastructure:  

- github.com  -- create project organization, push your code there,
  provide source downloads for releases (so don't forget to tag them etc),
  use bug tracker system, ...

- travis-ci.org -- to the degree applicable, enable automatic
  testing/building/upload of your content (code, docs, ...)

- http://readthedocs.org -- if you develop documentation in rest/sphinx
  or even markdown -- could provide you automatic docs builds etc
  Very easy and efficient way to bootstrap documentation-oriented
  website

- if you need mailing list or forum, you could create a project on
  http://nitrc.org/, which is although specific to neuroinformatics,
  could still be useful.

> - I know there is an active part of Debian Med that works on MRI
> software (and make great things, actually!), would any of them be
> interested in this initiative? If yes, what would you expect from it, or
> what would you be willing to provide at this stage? Also, would you have
> some recommendations so that open-sourced MRI hardware would easily
> interface with the already existing open-source software?

other recommendations were already expressed, but I guess

- you might still want it to interface with existing PAC system be it
  open-source (orthanc, xnat, ...) or proprietary

- depending on your target "consumer" you might want to provide "out of
  box" options for export of data in data formats which neuroimaging
  analysis toolkits can consume, e.g. nifti

- in the long run, providing some kind of programmable interface to
  control the beast and obtain the data "online" for real-time
  acquisition "closed loop" systems could be a neat feature

- would be nice if there was a simulator... have you looked at 
  http://od1n.sourceforge.net
  Then interested folks could assess some kind of "applicability" I
  guess.


> - Would you have any suggestions regarding the conduct of such a
> project? I have no experience in the management of open source projects
> and I am actively looking for documentation about it. In particular, how
> can I organise this project so as to avoid bottlenecks in the future?

shameless ad: as per http://www.gigasciencejournal.com/content/4/1/31
make sure you asap clear out copyright/license for your work and choose
a DFSG-compatible free and open source license for your code, data,
documentation.  That could help to guarantee that you yourself
would have access to your work in the future, happen you change your
employer ;)

> - Can you see any funding bodies that could be interested in this
> initiative, in the short to medium term?

may be  https://www.incf.org/resources/funding-support, depending on
what kind of support you are looking for...  But according to
http://www.ffc-mri.org/funding.html you have already gotten various
grants in the past... so pursuing with the same agencies could be an
option.  So it all again depends I guess on what funds you are
looking for?

> - Do you know of organisations that would be interested to know of this
> project or to provide guidance? I already plan to contact OSHWA and the
> CERN Ope