[MoM] Tomorrow a new Month and thus a new mentoring period will start

[Andreas Tille]

Hi,

there was no student for July MoM period[1].  Is there anybody up for
August to spend a certain amount of time to learn some Debian packaging?

Kind regards

Andreas.

[1] https://wiki.debian.org/DebianMed/MoM

-- 
http://fam-tille.de


-- 
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/20120731065451.ga26...@an3as.eu

Re: soapdenovo packaging

[Olivier Sallou]

Le 7/30/12 10:11 PM, Andreas Tille a écrit :
> Hi again,
>
> after sending this mail I just noticed that you just took action even
> before - that's great!  One thing I would like to see if you could find
> some publication data and inject these in debian/upstream file.
Sure,
I will check.
Package is ready for upload. Once upstream data is set I will upload it.
>
> Thanks for your work on this
>
>Andreas.
>
> On Mon, Jul 30, 2012 at 10:06:12PM +0200, Andreas Tille wrote:
>> Hi Olivier,
>>
>> On Mon, Jul 30, 2012 at 04:23:25PM +0200, Olivier Sallou wrote:
>>> I have seen some previous mail exchanges by Andreas in Fed 2011 [0].
>>> As license is GPL 3+ now, is there anything that prevented packaging ?
>>> Or should I simply go with an ITP?
>> Sure - just go on.
>>
>> Kind regards
>>
>>Andreas.
>>
>> -- 
>> http://fam-tille.de

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438


-- 
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/50178077.6080...@irisa.fr

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

[Andreas Tille]

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.

-- 
http://fam-tille.de


-- 
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/20120731061437.ga26...@an3as.eu

Re: OSCAR 10.12 has been packaged

[Andreas Tille]

On Mon, Jul 30, 2012 at 04:47:11PM -0400, Peter Hutten-Czapski wrote:
> I confess that I build debs manually by just compressing a file structure

I really wished that the descriptions to do it that way would vanish
from the internet for good. :-( 
These are always tricking beginners who for some reason I will never
understand failed in finding

http://www.debian.org/doc/manuals/maint-guide/

I will have a look what I can do to at least enable you to redo the same
result but using the proper way.  We might see what the next steps might
be.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
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/20120731055342.ga25...@an3as.eu

Re: Comments regarding cnrun_1.1.12-1_amd64.changes; sponsor upload 1.1.13-1

[Yaroslav Halchenko]

1.
On Tue, 31 Jul 2012, andrei zavada wrote:
> state in... oops...  For some reason, even after I did as instructed on
> http://wiki.debian.org/Alioth/Git#Repository_maintenance, this URL
> http://anonscm.debian.org/gitweb/?p=users/hmmr-guest/cnrun.git points to
> nowhere, and
> http://anonscm.debian.org/gitweb/?p=pkg-exppsy/cnrun.git;a=summary is still an
> empty repository, even after I did 'git branch -m master debian'.  Sorry if I
> forgot something yet.

wasn't the plan to keep it under pkg-exppsy? but I see

 Vcs-Git: git://git.debian.org/users/hmmr-guest/cnrun.git
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=users/hmmr-guest/cnrun.git
+Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-exppsy/cnrun.git;a=summary

ie Vcs-Git is still your personal repo... also nothing was pushed to the 
pkg-exppsy one


2.

why

diff -Nru cnrun-1.1.12/debian/upstream cnrun-1.1.13/debian/upstream
--- cnrun-1.1.12/debian/upstream2012-07-27 18:52:14.0 -0400
+++ cnrun-1.1.13/debian/upstream1969-12-31 19:00:00.0 -0500
@@ -1,12 +0,0 @@
-Reference:
-  Author: Zavada A, Buckley CL, Martinez D, Rospars J-P, Nowotny T.
-  Title: Competition-based model of pheromone component ratio detection in the 
moth
-  Journal: PLoS ONE
-  Year: 2011
-  Volume: 6
-  Number: 2
-  Pages: e16308
-  DOI: oi:10.1371/journal.pone.0016308
-  PMID: 21373177
-  URL: http://johnhommer.com/academic/code/cnrun
-  eprint: 


? got lost? ;)

> > * other notes
> >   - The deb contains the examples under /usr/share/doc/cnrun, mixed in with
> > the rest of the documentation. You could consider moving them to
> > /usr/share/doc/cnrun/examples instead (cfr. Policy §12.6).
> Fixed.

;-) well -- you probably didn't have to do that in upstream organization of
docs -- Luca meant using dh_installexamples... but whatever reaches the
target

-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik


-- 
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/20120731012424.gm16...@onerussian.com

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

[Charles Plessy]

> On Mon, Jul 30, 2012 at 02:49:36PM +0200, Alex Mestiashvili wrote:
> > 
> > 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)
 
Le Mon, Jul 30, 2012 at 04:17:14PM +0200, Andreas Tille a écrit :
> 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 $?
> 
> There are people who do not like epochs - but this is the clean way.

Hi Alex and Andreas,

indeed, I think that using an epoch is a bit too much at the moment.  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.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
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/20120730232457.ga10...@falafel.plessy.net

Re: Comments regarding cnrun_1.1.12-1_amd64.changes; sponsor upload 1.1.13-1

[andrei zavada]

Hi Luca, Yaroslav,

Thanks for the bunch of pertinent remarks.  I really learned a thing or two
about Debian process as I went through them one by one.  Here's hoping the way
I dealt with them is satisfactory.  For details, you can check the current
state in... oops...  For some reason, even after I did as instructed on
http://wiki.debian.org/Alioth/Git#Repository_maintenance, this URL
http://anonscm.debian.org/gitweb/?p=users/hmmr-guest/cnrun.git points to
nowhere, and
http://anonscm.debian.org/gitweb/?p=pkg-exppsy/cnrun.git;a=summary is still an
empty repository, even after I did 'git branch -m master debian'.  Sorry if I
forgot something yet.

So I pushed to my own, unpublished repository on alioth.debian.org, and also
on (the hateful) github, for you to inspect my last changes.

Due to changes in the sources, upstream has decided to make it cnrun-1.1.13.
I'm posting the latest dsc here:
http://johnhommer.com/academic/code/cnrun/source/deb/cnrun_1.1.13-1.dsc

On Sun, 29 Jul 2012 21:19:39 +
Luca Falavigna  wrote:

> * debian/README.Debian
>   - Such information should belong to debian/copyright instead.
Now this file contains information on what options cnrun was configured with
for Debian.

> * debian/control
>   - Why build-depending on g++-4.6 | g++-4.7, when that is already
> satisfied by build-essential, along with libstdc++6?
Removed these deps.

>   - Regarding the last paragraph of the long description: such credits
> belong to debian/copyright instead.
Chopped off last sentence.
 
> * debian/rules
>   - It uses DEB_BUILD_HARDENING=1 and dpkg-buildflags, without
> build-depending on the appropriate dpkg version. Please follow hardening
> guide closely.
Updated debian/rules and debian/control accordingly.

> * debian/copyright
>   - The Files: * section, is, I believe, too broad; Thomas Nowotny wrote the
> original upstream library, but has nothing to do with the Debian
> packaging.
Fixed.

>   - License is a bit unclear, upstream tarball contains GPL files, COPYING
> states they're licensed under GPL-3+, while copyright file states it's
> GPL-2+.
Fair point.  All source files are now clearly marked GPL-2+.
 
> * other notes
>   - The deb contains the examples under /usr/share/doc/cnrun, mixed in with
> the rest of the documentation. You could consider moving them to
> /usr/share/doc/cnrun/examples instead (cfr. Policy §12.6).
Fixed.


--
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/20120731015154.4323947f@ra

Re: OSCAR 10.12 has been packaged

[Peter Hutten-Czapski]

I confess that I build debs manually by just compressing a file structure


Peter Hutten-Czapski
Haileybury Ontario

"The attitude that ‘if rural people want these services they’ll have
to come to the city to get them’ is simply not acceptable…” (Newbery,
1999)

Before printing, think about the environment. Avant d' imprimer,
pensez à l'environnement.


On 30 July 2012 14:55, Andreas Tille  wrote:
> Hi Peter,
>
> On Mon, Jul 30, 2012 at 10:09:22AM -0400, Peter Hutten-Czapski wrote:
>> Thank you for your kind words and encouragement
>
> No specific thanks for this is needed - we try to entertain a warm and
> welcoming voice here in the Debian Med team. :-)
>
>> Our source is in GIT and we reveal the source of our trunk stable (not
>> really but not badly unstable) and releases on Sourceforge
>> (we use a different repository for submission and vetting of code)
>> I have not packaged the source, and would have to look up the meaning
>> and content of the files you speak of in
>
> When I did mention the "source package" I was rather refering to the
> process how you builded the *.deb file.  You most probably have created
> a debian/ directory and then you didt domething like dpkg-buildpackage
> or debuild.  Could you somehow confirm this?  What I would need is the
> location of this debian/ directory (which is also contained in the
> source package files I was mentioning in my last mail - it is not
> unusual that those technical terms are not really familiar to people
> who do some packaging outside of Debian.)
>
>> but really I am not ready
>> I am a country doctor who does this in his "spare" time
>
> That's actually no excuse - several people are doing interesting things
> in their spare time.  It depends a bit how much time you might be able
> to spend on this.  We have some good tradition of mentoring new people
> (I guess in case you have watched my talk you will have hear about
> Mentoring of Month.)
>
>> there is no one else interested in doing the work (for the reasons implicit)
>
> Taht's not fully true - we, the Debian Med team are also interested as
> well.  But our manpower is split over several projects and we need to
> find some reasonable compromise to get everything covered to some
> extend.  From my perspective in your situation it is definitely worth
> joining our team to do your contribution inside the team rather than
> outside - IMHO your share of spare time could be spent more effectively.
>
>> As mentioned I am preparing to package our next release which will be
>> alpha in just a few days
>> AND
>> Equally importantly the project isn't grown up enough (or has grown up
>> without thinking about these things until recently)
>
> It is never to late to start here. ;-)
>
>> Among other faults, to my understanding a unforgivable sin for your
>> purposes, is that we have a number of jars that we do not reference
>> from the source but provide with unknown or forgotten lineage (I would
>> have to check with the programmers, the number has dropping
>> dramatically from over a 100 but was not 0 at the last reckoning)
>
> I would not call this an unforgivable sin - it is not fit for official
> Debian for sure - but we could work on this step by step together right.
> We have some tradition of splitting out JARs into separate packages with
> clean source step by step.  It could ba a long stony read but there is
> no point in not starting at some point.
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>
>
> --
> 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/20120730185520.ga9...@an3as.eu
>
>


--
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/CAHNNH=htofyd5kilxk3m3_dbjzawjfzrqa37bp7rv6daetc...@mail.gmail.com

Re: soapdenovo packaging

[Andreas Tille]

Hi again,

after sending this mail I just noticed that you just took action even
before - that's great!  One thing I would like to see if you could find
some publication data and inject these in debian/upstream file.

Thanks for your work on this

   Andreas.

On Mon, Jul 30, 2012 at 10:06:12PM +0200, Andreas Tille wrote:
> Hi Olivier,
> 
> On Mon, Jul 30, 2012 at 04:23:25PM +0200, Olivier Sallou wrote:
> > I have seen some previous mail exchanges by Andreas in Fed 2011 [0].
> > As license is GPL 3+ now, is there anything that prevented packaging ?
> > Or should I simply go with an ITP?
> 
> Sure - just go on.
> 
> Kind regards
> 
>Andreas.
> 
> -- 
> http://fam-tille.de

-- 
http://fam-tille.de


-- 
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/20120730201140.gc12...@an3as.eu

Re: soapdenovo packaging

[Andreas Tille]

Hi Olivier,

On Mon, Jul 30, 2012 at 04:23:25PM +0200, Olivier Sallou wrote:
> I have seen some previous mail exchanges by Andreas in Fed 2011 [0].
> As license is GPL 3+ now, is there anything that prevented packaging ?
> Or should I simply go with an ITP?

Sure - just go on.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
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/20120730200612.gb12...@an3as.eu

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

[Andreas Tille]

On Mon, Jul 30, 2012 at 05:08:36PM +0200, Alex Mestiashvili wrote:
> >   $ 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 ?

The warning will vanish because the version including epoch is higher.

Kind regards

   Andreas. 

-- 
http://fam-tille.de


-- 
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/20120730200427.ga12...@an3as.eu

Re: OSCAR 10.12 has been packaged

[Andreas Tille]

Hi Peter,

On Mon, Jul 30, 2012 at 10:09:22AM -0400, Peter Hutten-Czapski wrote:
> Thank you for your kind words and encouragement

No specific thanks for this is needed - we try to entertain a warm and
welcoming voice here in the Debian Med team. :-)

> Our source is in GIT and we reveal the source of our trunk stable (not
> really but not badly unstable) and releases on Sourceforge
> (we use a different repository for submission and vetting of code)
> I have not packaged the source, and would have to look up the meaning
> and content of the files you speak of in

When I did mention the "source package" I was rather refering to the
process how you builded the *.deb file.  You most probably have created
a debian/ directory and then you didt domething like dpkg-buildpackage
or debuild.  Could you somehow confirm this?  What I would need is the
location of this debian/ directory (which is also contained in the
source package files I was mentioning in my last mail - it is not
unusual that those technical terms are not really familiar to people
who do some packaging outside of Debian.)
 
> but really I am not ready
> I am a country doctor who does this in his "spare" time

That's actually no excuse - several people are doing interesting things
in their spare time.  It depends a bit how much time you might be able
to spend on this.  We have some good tradition of mentoring new people
(I guess in case you have watched my talk you will have hear about
Mentoring of Month.)

> there is no one else interested in doing the work (for the reasons implicit)

Taht's not fully true - we, the Debian Med team are also interested as
well.  But our manpower is split over several projects and we need to
find some reasonable compromise to get everything covered to some
extend.  From my perspective in your situation it is definitely worth
joining our team to do your contribution inside the team rather than
outside - IMHO your share of spare time could be spent more effectively.

> As mentioned I am preparing to package our next release which will be
> alpha in just a few days
> AND
> Equally importantly the project isn't grown up enough (or has grown up
> without thinking about these things until recently)

It is never to late to start here. ;-)

> Among other faults, to my understanding a unforgivable sin for your
> purposes, is that we have a number of jars that we do not reference
> from the source but provide with unknown or forgotten lineage (I would
> have to check with the programmers, the number has dropping
> dramatically from over a 100 but was not 0 at the last reckoning)

I would not call this an unforgivable sin - it is not fit for official
Debian for sure - but we could work on this step by step together right.
We have some tradition of splitting out JARs into separate packages with
clean source step by step.  It could ba a long stony read but there is
no point in not starting at some point.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
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/20120730185520.ga9...@an3as.eu

ITP: soapdenovo -- short-read assembly method that can build a de novo draft assembly for the human-sized genomes

[olivier sallou]

-- Forwarded message --
From: Debian Bug Tracking System 
Date: 2012/7/30
Subject: Bug#683291: Acknowledgement (ITP: soapdenovo -- short-read
assembly method that can build a de novo draft assembly for the human-sized
genomes)
To: Olivier Sallou 


Thank you for filing a new Bug report with Debian.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

As you requested using X-Debbugs-CC, your message was also forwarded to
  debian-de...@lists.debian.org
(after having been given a Bug report number, if it did not have one).

Your message has been sent to the package maintainer(s):
 w...@debian.org

If you wish to submit further information on this problem, please
send it to 683...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

--
683291: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683291
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)

Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

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

[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

Re: Anyone using latest micromanager ?

[Johan Henriksson]

it rings a bell; I think it happen when it was not stored in a directory
called trunk?

/Johan

On Fri, Jul 27, 2012 at 10:56 PM, Mathieu Malaterre <
mathieu.malate...@gmail.com> wrote:

> Hi,
>
>   I am trying to compile micromanager 1.4.10/1.4.11 but it keeps on
> failing with:
>
>
> Compiling org.micromanager.browser.plugin to DataBrowser/classes
> Exception in thread "main" java.io.FileNotFoundException: Could not
> locate clojure/data/json__init.class or clojure/data/json.clj on
> classpath: , compiling:(core.clj:15)
> at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3390)
> at clojure.lang.Compiler.compile1(Compiler.java:7038)
> at clojure.lang.Compiler.compile1(Compiler.java:7028)
> at clojure.lang.Compiler.compile(Compiler.java:7100)
> at clojure.lang.RT.compile(RT.java:387)
> at clojure.lang.RT.load(RT.java:427)
> at clojure.lang.RT.load(RT.java:400)
> at clojure.core$load$fn__4890.invoke(core.clj:5415)
> at clojure.core$load.doInvoke(core.clj:5414)
> at clojure.lang.RestFn.invoke(RestFn.java:408)
> at clojure.core$load_one.invoke(core.clj:5227)
> at clojure.core$load_lib.doInvoke(core.clj:5264)
> at clojure.lang.RestFn.applyTo(RestFn.java:142)
> at clojure.core$apply.invoke(core.clj:603)
> at clojure.core$load_libs.doInvoke(core.clj:5298)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.core$apply.invoke(core.clj:605)
> at clojure.core$use.doInvoke(core.clj:5392)
> at clojure.lang.RestFn.invoke(RestFn.java:408)
> at
> org.micromanager.browser.plugin$loading__4784__auto__.invoke(plugin.clj:16)
> at clojure.lang.AFn.applyToHelper(AFn.java:159)
> at clojure.lang.AFn.applyTo(AFn.java:151)
> at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3385)
> at clojure.lang.Compiler.compile1(Compiler.java:7038)
> at clojure.lang.Compiler.compile1(Compiler.java:7028)
> at clojure.lang.Compiler.compile(Compiler.java:7100)
> at clojure.lang.RT.compile(RT.java:387)
> at clojure.lang.RT.load(RT.java:427)
> at clojure.lang.RT.load(RT.java:400)
> at clojure.core$load$fn__4890.invoke(core.clj:5415)
> at clojure.core$load.doInvoke(core.clj:5414)
> at clojure.lang.RestFn.invoke(RestFn.java:408)
> at clojure.core$load_one.invoke(core.clj:5227)
> at clojure.core$compile$fn__4895.invoke(core.clj:5426)
> at clojure.core$compile.invoke(core.clj:5425)
> at clojure.lang.Var.invoke(Var.java:415)
> at clojure.lang.Compile.main(Compile.java:81)
> Caused by: java.io.FileNotFoundException: Could not locate
> clojure/data/json__init.class or clojure/data/json.clj on classpath:
> at clojure.lang.RT.load(RT.java:432)
> at clojure.lang.RT.load(RT.java:400)
> at clojure.core$load$fn__4890.invoke(core.clj:5415)
> at clojure.core$load.doInvoke(core.clj:5414)
> at clojure.lang.RestFn.invoke(RestFn.java:408)
> at clojure.core$load_one.invoke(core.clj:5227)
> at clojure.core$load_lib.doInvoke(core.clj:5264)
> at clojure.lang.RestFn.applyTo(RestFn.java:142)
> at clojure.core$apply.invoke(core.clj:603)
> at clojure.core$load_libs.doInvoke(core.clj:5298)
> at clojure.lang.RestFn.applyTo(RestFn.java:137)
> at clojure.core$apply.invoke(core.clj:605)
> at clojure.core$use.doInvoke(core.clj:5392)
> at clojure.lang.RestFn.invoke(RestFn.java:457)
> at
> org.micromanager.browser.core$loading__4784__auto__.invoke(core.clj:15)
> at clojure.lang.AFn.applyToHelper(AFn.java:159)
> at clojure.lang.AFn.applyTo(AFn.java:151)
> at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3385)
> ... 36 more
> make[2]: *** [DataBrowser.jar] Error 1
> make[2]: Leaving directory
>
> `/home/mathieu/debian/debian-med/trunk/packages/micromanager/trunk/micromanager-1.4.11/plugins'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
>
> `/home/mathieu/debian/debian-med/trunk/packages/micromanager/trunk/micromanager-1.4.11'
> dh_auto_build: make -j1 returned exit code 2
> make: *** [build] Error 2
>
>
> Anyone seen this before ?
>
> Thanks
> --
> Mathieu
>
>
> --
> 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/ca+7wusx+0_untslitigh+k0oo5pf4cgfu-yykdh14778i7d...@mail.gmail.com
>
>


-- 
-- 
---
Johan Henriksson, PhD
Karolinska Institutet
Ecobima AB - Custom solutions for life sciences
http://www.ecobima.se   http://mahogny.areta.org
http://www.endrov.net

Re: OSCAR 10.12 has been packaged

[Adrian Midgley]

On 30 July 2012 15:09, Peter Hutten-Czapski  wrote:


OSCAR is an excellent project and a model of development of such
things over the years.

I'd say the natural tendency should be toward the standard system for
debs, as a built-in part of the system that produces releases for Red
Hat etc if it still does, not because that is the only way to do
things, but because convergence rather than divergence is the Linux
and Open Source way, and because standardisation is on the whole a
good thing, and because over decades converging on the standards and
thus reducing the amount of work that needs to be redone or breakages
from other changes is A Good Thing.

But I'm just an urban doctor, and would not wish to urge a timetable
or a rush in this, just to hope the compass needle points that way and
guides navigation a bit.




-- 
Adrian Midgley   http://www.defoam.net/


-- 
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/CAN2jWyjwHkP7guK=ePjBGADC=qyek06xlukg0vqku5qxqph...@mail.gmail.com

soapdenovo packaging

[Olivier Sallou]

Hi,
I plan to package soapdenovo, hwich is in DebianMed tasks.

I have seen some previous mail exchanges by Andreas in Fed 2011 [0].
As license is GPL 3+ now, is there anything that prevented packaging ?
Or should I simply go with an ITP?


[0] http://lists.debian.org/debian-med/2011/02/msg00094.html

Olivier

-- 

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438


-- 
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/501698dd.1020...@irisa.fr

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

[Andreas Tille]

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).
 
> 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.

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 $?

There are people who do not like epochs - but this is the clean way.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
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/20120730141714.gd27...@an3as.eu

Re: OSCAR 10.12 has been packaged

[Peter Hutten-Czapski]

Thank you for your kind words and encouragement
Our source is in GIT and we reveal the source of our trunk stable (not
really but not badly unstable) and releases on Sourceforge
(we use a different repository for submission and vetting of code)
I have not packaged the source, and would have to look up the meaning
and content of the files you speak of in

but really I am not ready
I am a country doctor who does this in his "spare" time
there is no one else interested in doing the work (for the reasons implicit)
As mentioned I am preparing to package our next release which will be
alpha in just a few days
AND
Equally importantly the project isn't grown up enough (or has grown up
without thinking about these things until recently)
Among other faults, to my understanding a unforgivable sin for your
purposes, is that we have a number of jars that we do not reference
from the source but provide with unknown or forgotten lineage (I would
have to check with the programmers, the number has dropping
dramatically from over a 100 but was not 0 at the last reckoning)


Peter Hutten-Czapski
Haileybury Ontario

"The attitude that ‘if rural people want these services they’ll have
to come to the city to get them’ is simply not acceptable…” (Newbery,
1999)

Before printing, think about the environment. Avant d' imprimer,
pensez à l'environnement.


On 30 July 2012 03:55, Andreas Tille  wrote:
> Hi Peter,
>
> On Sun, Jul 29, 2012 at 09:24:24AM -0400, Peter Hutten-Czapski wrote:
>> ...
>> The vast majority of end users have someone that they depend on to
>> install and maintain Oscar (in our parlance Oscar Service Providers).
>
> That's an interesting bit.  May be you are interested in my recent talk
> at Libre Software Meeting in Geneva:
>
>http://people.debian.org/~tille/talks/20120711_vista-in-debian
>
> which is also available as video recording
>
>http://video.rmll.info/videos/integration-of-vista-into-debian/
>
> and you might specifically interested in slide 26 / 29 (and this
> specific slide gained also some interest in the article from European
> Commission "Joinup" (which is linked at the bottom of the first link).
>
>> The OSP's in a way are our chief "customer" and do not need a deb as
>> they can follow our instructions for compiling from source, and/or
>> make their own deployment scripts.
>
> Having a Debian package is not about the ability to follow installation
> instructions but rather to effectively roll-out a system effectively.
> While it is perfectly true that specifically due Ubuntu nowadays you can
> find software on some private computers at home of people who where not
> able to install this set of software otherwise this is not the only
> usage of Debian packages.
>
> I have no idea what those deployment scripts you are mentioning above
> are doing and of which nature these might be but to some extend the
> wording smells like some custom solution of issues which were also
> solved inside Debian packaging techniques.  If the OSP's (which I
> personally consider the main target audience of Debian Med if it comes
> to medical record applications) would consider implementing their
> deployment scripts as Debian packages I would see some potential to save
> time in the long run.
>
>> McMaster University actually has a
>> course and auditing standards for OSP's to ensure deployments are
>> secure and functional which a deb cannot do.
>
> Your way of quality control is somehow orthogonal what Debian might
> provide.  We surely can not run extensive tests in practice (even if
> running a technical test suite is part of the build process).  The
> quality is rather on a technical level to verify the compatibility with
> other components of the system, there are automatic build which
> guarantee that the software builds without problems etc.  And finally
> you might have some additional eyeballs looking at the source from
> a different angle which sometimes is a good thing to have.
>
>> So for the moment and the near future our poor man's debification of
>> Oscar will have to do.  I am interested in getting it cleaned up so
>> that it would be eligible to enter a repository, its just too much for
>> me right now.
>
> I do not think that you are really bound to what you call "poor man's
> debification".  It depends from your estimation whether the advantages I
> mentioned above are worth spending some extra time into it - depending
> from the current status (which I could estimate if you would provide the
> source package I was asking in my previous mail) it might be not that
> much.  My suggestion would be to inject your current packaging stuff
> into our package development platform alioth.debian.org in the Debian
> Med area.  This process is described in the Debian Med policy
> document[1] and I'd volunteer to do this technical process as some kind
> of kick off.  Considering that you mentioned Git in the beginning of
> your other mail I assume that you will prefer Git over SVN.
>
> 

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

[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: bowtie2 messed up git repository

[Andreas Tille]

On Mon, Jul 30, 2012 at 11:06:14AM +0200, Alex Mestiashvili wrote:
> Would it be acceptable to remove this tag and commit a new one with the
> same name?

In our team as well as Debian as a whole usually the doer decides
(Do-O-cracy).  If you are obviosely working on this to a large extend
just fix it to enable you working properly with it.  Other people will
adapt if they will work on this repository.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
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/20120730095612.gc27...@an3as.eu

bowtie2 messed up git repository

[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

Re: OSCAR 10.12 has been packaged

[Andreas Tille]

Hi Peter,

On Sun, Jul 29, 2012 at 09:24:24AM -0400, Peter Hutten-Czapski wrote:
> ...
> The vast majority of end users have someone that they depend on to
> install and maintain Oscar (in our parlance Oscar Service Providers).

That's an interesting bit.  May be you are interested in my recent talk
at Libre Software Meeting in Geneva:

   http://people.debian.org/~tille/talks/20120711_vista-in-debian

which is also available as video recording

   http://video.rmll.info/videos/integration-of-vista-into-debian/

and you might specifically interested in slide 26 / 29 (and this
specific slide gained also some interest in the article from European
Commission "Joinup" (which is linked at the bottom of the first link).

> The OSP's in a way are our chief "customer" and do not need a deb as
> they can follow our instructions for compiling from source, and/or
> make their own deployment scripts.

Having a Debian package is not about the ability to follow installation
instructions but rather to effectively roll-out a system effectively.
While it is perfectly true that specifically due Ubuntu nowadays you can
find software on some private computers at home of people who where not
able to install this set of software otherwise this is not the only
usage of Debian packages.

I have no idea what those deployment scripts you are mentioning above
are doing and of which nature these might be but to some extend the
wording smells like some custom solution of issues which were also
solved inside Debian packaging techniques.  If the OSP's (which I
personally consider the main target audience of Debian Med if it comes
to medical record applications) would consider implementing their
deployment scripts as Debian packages I would see some potential to save
time in the long run.

> McMaster University actually has a
> course and auditing standards for OSP's to ensure deployments are
> secure and functional which a deb cannot do.

Your way of quality control is somehow orthogonal what Debian might
provide.  We surely can not run extensive tests in practice (even if
running a technical test suite is part of the build process).  The
quality is rather on a technical level to verify the compatibility with
other components of the system, there are automatic build which
guarantee that the software builds without problems etc.  And finally
you might have some additional eyeballs looking at the source from
a different angle which sometimes is a good thing to have.
 
> So for the moment and the near future our poor man's debification of
> Oscar will have to do.  I am interested in getting it cleaned up so
> that it would be eligible to enter a repository, its just too much for
> me right now.

I do not think that you are really bound to what you call "poor man's
debification".  It depends from your estimation whether the advantages I
mentioned above are worth spending some extra time into it - depending
from the current status (which I could estimate if you would provide the
source package I was asking in my previous mail) it might be not that
much.  My suggestion would be to inject your current packaging stuff
into our package development platform alioth.debian.org in the Debian
Med area.  This process is described in the Debian Med policy
document[1] and I'd volunteer to do this technical process as some kind
of kick off.  Considering that you mentioned Git in the beginning of
your other mail I assume that you will prefer Git over SVN.

In short:  If you unreveal the source of your Debian packaging I would
inject it into our packaging VCS and will see whether I could do some
simple enhancements.  You can perfectly keep on releasing "poor man's
packages" but you can base it as a first step on the status of this
VCS which is group maintained by the Debian Med team.

Kind regards

  Andreas.

[1] debian-med.alioth.debian.org/docs/policy.html

-- 
http://fam-tille.de


-- 
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/20120730075549.gb27...@an3as.eu

Re: OSCAR 10.12 has been packaged

[Andreas Tille]

Hi Peter,

thanks for the short update about Oscar development.

On Sun, Jul 29, 2012 at 08:26:45AM -0400, Peter Hutten-Czapski wrote:
> ...
> For now I release things that look like debs at sourceforge.
> (apologies to any conventions slurred in the process)
> https://sourceforge.net/projects/oscarmcmaster/files/

I noticed from the changelog file inside oscar-mcmaster_12-1.6.final.deb
that you are the author of these debs.  Would you be able to provide the
*.dsc file and the according debian.tar.gz (or diff.tar.gz depending
what source format you are using).  If you have no idea what I'm talking
about:  These are the two files that beling to the Debian package source
in addition to plain oskar upstream source which will be createt in the
package building process.

> On 29 July 2012 05:22, Adrian Midgley  wrote:
> > On 29 July 2012 08:22, Sebastian Hilbert  wrote:
> >
> >> I would love to see Oscar packaged in Debian proper.
> >
> > So would I.

As Sebastian and Adrian mentioned there is some interest in having oskar
integratet straight into official Debian distribution and the Debian Med
project exists to make things like this happen.  In the past we had some
success with other medical record software and as far as I would see
this in all cases this was also for the profit of the upstream project.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
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/20120730070305.ga27...@an3as.eu