Re: New package of GWAMA
Hi all, I finished my package of gwama [1]. I put some upstreams examples files (which are provides outside the source archive) in debian/upstream.docs/ , I don't know if it's the good way to integrate them. Could you check the package and if it's ok, upload it? Best regards, Dylan [1] http://anonscm.debian.org/cgit/debian-med/gwama.git
Re: r-cran-ape updated with the last upstream version - Need a sponsor to upload it
Hi Andreas, 2014-12-12 15:46 GMT+01:00 Andreas Tille : > > > Uploaded to experimental (due to freeze policy). Thanks for your work > on this > Thank you. Dylan
Re: ImageJ plugin for Orthanc
> > So, there would be a global CLASSPATH that is shared across all the > > JVMs available in Debian, and that is implicitly used by the > > ImageJ package? Anyone could confirm this? > > As far as I know any JAR that's found in /usr/share/java will be > included in CLASSPATH. (Please correct me if I'm wrong). After some inspection, the launch script for imagej (/usr/bin/imagej) overrides the default classpath at line 225 [1]. As a consequence, having the JAR package of json-simple in "/usr/share/java" is unfortunately insufficient. I finally managed to "dynamically link" against the libjson-simple-java package by creating a symbolic link from "/usr/share/java/json-simple.jar" to "/usr/share/imagej/plugins" using dh_link. I think this is a better solution than patching the /usr/bin/imagej script. As discussed previously, I have also removed the source code of json-simple by introducing "Files-Excluded" in d/copyright. Both lintian and pbuilder are OK with the new version of the package [2]. Andreas, please would you kindly give another look at the package? Thanks, Sébastien- [1] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/imagej/trunk/debian/imagej.sh?revision=16435&view=markup [2] http://anonscm.debian.org/viewvc/debian-med?view=revision&revision=18540 -- 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/1272276775.7185447.1418659096078.javamail.r...@chu.ulg.ac.be
Re: Gimias status
Hi Mathieu, On Mon, Dec 15, 2014 at 02:31:53PM +0100, Mathieu Malaterre wrote: > [CC me please] > > Does anyone knows what happen to gimias in Debian ? > > I see some interest in the past: > > https://wiki.debian.org/DebianMed/Meeting/Southport2012 > > but nothing since... I'm reading "Packaging CSnake which is the build system for Gimias. Almost finished. Patches ready to push to upstream (Martin, Tim) " that packaging *CSnake* is almost finished. If you want to know more I'd suggest CCing Tim Booth since he is not following the list closely. 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: https://lists.debian.org/20141215140549.ge...@an3as.eu
Gimias status
[CC me please] Does anyone knows what happen to gimias in Debian ? I see some interest in the past: https://wiki.debian.org/DebianMed/Meeting/Southport2012 but nothing since... Thx for updates, -- 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/ca+7wuswslg545dw1z1ksqt2-cx4pyjps75z-8aguardyjcy...@mail.gmail.com
Re: Bug#772949: RFS: imageio/1.0-1 [ITP] -- Library for reading and writing a wide range of image formats
On Mon, Dec 15, 2014 at 11:47:18AM +, Ghislain Vaillant wrote: > I have added this package to the debian-science imageanalysis and > debian-med imaging-dev tasks. Cool. Thanks a lot 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: https://lists.debian.org/20141215121948.gd...@an3as.eu
Re: Bug#772949: RFS: imageio/1.0-1 [ITP] -- Library for reading and writing a wide range of image formats
I have added this package to the debian-science imageanalysis and debian-med imaging-dev tasks. Cheers, - Ghis
Re: unstable/experimental freeze policy
Hi Sascha, On Mon, Dec 15, 2014 at 10:01:26AM +, Sascha Steinbiss wrote: > > You always need to outweight policy with sane reasons / common sense. > > If you think GenomeTools and its dependencies will pretty surely not > > feature any RC bug we will probably not need to keep new versions out of > > unstable. But how can you surely know this? > > Well, I cannot prove it... but as there is currently only one package > depending on it and I'm both its upstream author and maintainer, I think > I'm fairly sure ;) There is no reason to assume that RC bugs can only occure in upstream code. There are a lot of chances that packaging issues and cross package problems occure even if the upstream code is perfectly fine. > > I think by waiting a certain time to see whether some QA tools have > > run once or twice which is probably in a one month time frame. > > Oh, I didn't know these tools also run on experimental. In this case I > completely agree! Well, this is a misunderstanding. The QA tools are running on testing and unstable and I would wait a bit to be sure that several runs will not show anything problematic. If this is the case we could think about "violating" freeze policy and upload to unstable. > > So if you are sure the Debian import Freeze for Ubuntu will be Feb > > 2015 it might be the best compromise to upload GenomeTools (and its > > dependencies) in mid January which should be sufficient to a) reach > > Ubuntu and b) uncover any RC bugs in testing. > > Absolutely! The Ubuntu import freeze for vivid is on Feb 19th > (https://wiki.ubuntu.com/VividVervet/ReleaseSchedule) so mid January > definitely sounds good. So we can agree upon uploading mid January (latest at our sprint :-)). See you 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: https://lists.debian.org/20141215113047.gc...@an3as.eu
Re: unstable/experimental freeze policy
Hi Andreas, >> I have just uploaded a new version of a package (new GenomeTools >> upstream version) to experimental [...] >> do you see much in the way of uploading this package to unstable as well? > > You always need to outweight policy with sane reasons / common sense. > If you think GenomeTools and its dependencies will pretty surely not > feature any RC bug we will probably not need to keep new versions out of > unstable. But how can you surely know this? Well, I cannot prove it... but as there is currently only one package depending on it and I'm both its upstream author and maintainer, I think I'm fairly sure ;) > I think by waiting a certain time to see whether some QA tools have > run once or twice which is probably in a one month time frame. Oh, I didn't know these tools also run on experimental. In this case I completely agree! > So if you are sure the Debian import Freeze for Ubuntu will be Feb > 2015 it might be the best compromise to upload GenomeTools (and its > dependencies) in mid January which should be sufficient to a) reach > Ubuntu and b) uncover any RC bugs in testing. Absolutely! The Ubuntu import freeze for vivid is on Feb 19th (https://wiki.ubuntu.com/VividVervet/ReleaseSchedule) so mid January definitely sounds good. Thanks and best regards, Sascha -- The Wellcome Trust Sanger Institute is operated by Genome Research Limited, a charity registered in England with number 1021457 and a company registered in England with number 2742969, whose registered office is 215 Euston Road, London, NW1 2BE. -- 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/548eb176.9020...@steinbiss.name
Re: Help required for webapp on Tomcat8
On 12/15/2014 10:18 AM, Emmanuel Bourg wrote: > Le 15/12/2014 10:00, Olivier Sallou a écrit : > >> Caused by: java.lang.NullPointerException >> at >> org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:291) > Hi Olivier, > > This looks like this bug: > > https://issues.apache.org/bugzilla/show_bug.cgi?id=56923 > > If you have symlinks in WEB-INF/lib you have to add allowLinking="true"/> in your context. Correct. In fact I had in a first step removed the allowLinking, and "of course" , there were missing jar files for the webapp (I forgot about a few libs). Anyway, the deploy error message was not really clear :-( Anyway, thanks for the hint, this was the issue. Olivier > > Emmanuel Bourg > -- 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: https://lists.debian.org/548eaac6.7090...@irisa.fr
Re: ImageJ plugin for Orthanc
On Mon, Dec 15, 2014 at 10:00:09AM +0100, s.jodo...@chu.ulg.ac.be wrote: > > I admit I know to less about Java but the "merge" you are mentioning > > in a) is not clear to me. If you Build-Depend on libjson-simple-java > > the JAR which is in Debian's CLASSPATH will be available as well for > > the installed package if you Depend from libjson-simple-java. So > > I see no reason for patching. > > > > Any more educated Java programmer will be explain better most > > probably. > > So, there would be a global CLASSPATH that is shared across all the JVMs > available in Debian, and that is implicitly used by the ImageJ package? > Anyone could confirm this? As far as I know any JAR that's found in /usr/share/java will be included in CLASSPATH. (Please correct me if I'm wrong). 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: https://lists.debian.org/20141215091853.gb...@an3as.eu
Re: Help required for webapp on Tomcat8
Le 15/12/2014 10:00, Olivier Sallou a écrit : > Caused by: java.lang.NullPointerException > at > org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:291) Hi Olivier, This looks like this bug: https://issues.apache.org/bugzilla/show_bug.cgi?id=56923 If you have symlinks in WEB-INF/lib you have to add in your context. Emmanuel Bourg -- 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/548ea74b.6040...@apache.org
Re: ImageJ plugin for Orthanc
> I admit I know to less about Java but the "merge" you are mentioning > in a) is not clear to me. If you Build-Depend on libjson-simple-java > the JAR which is in Debian's CLASSPATH will be available as well for > the installed package if you Depend from libjson-simple-java. So > I see no reason for patching. > > Any more educated Java programmer will be explain better most > probably. So, there would be a global CLASSPATH that is shared across all the JVMs available in Debian, and that is implicitly used by the ImageJ package? Anyone could confirm this? Thanks, Sébastien- -- 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/1297900209.7049289.1418634009506.javamail.r...@chu.ulg.ac.be
Help required for webapp on Tomcat8
Hi, after receiving a bug to switch biomaj-watcher to Tomcat8, I made the required updates, but my webapp has deployment error on Tomcat 8. I ask here for help to ease the switch to v8 (from v6). I define a context xml with a docBase. I do not understand why it fails now any help would be appriciated to help package kept in Jessie. My context XML is like: .. (only other parameters) Here is Catalina log: 15-Dec-2014 09:46:54.081 SEVERE [localhost-startStop-1] org.apache.catalina.core.ContainerBase.addChildInternal ContainerBase.addChild: start: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/BmajWatcher]] at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:724) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:700) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:714) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:581) at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1685) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NullPointerException at org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:291) at org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java:158) at org.apache.catalina.startup.ContextConfig.processJarsForWebFragments(ContextConfig.java:1855) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1119) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:771) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:305) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5120) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) ... 10 more 15-Dec-2014 09:46:54.092 SEVERE [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDescriptor Erreur lors du déploiement du descripteur de configuration /etc/tomcat8/Catalina/localhost/BmajWatcher.xml java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/BmajWatcher]] at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:727) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:700) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:714) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:581) at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1685) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) 15-Dec-2014 09:46:54.093 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDescriptor Deployment of configuration descriptor /etc/tomcat8/Catalina/localhost/BmajWatcher.xml has finished in 613 ms
Re: ImageJ plugin for Orthanc
Hi Sébastien, On Mon, Dec 15, 2014 at 09:14:15AM +0100, s.jodo...@chu.ulg.ac.be wrote: > > which should be avoided. Could you imagine to rather "link" (I think > > linking is not the proper term in the Java world) against this > > library > > rather than using the code copy. > > I see 2 possibilities at this point: > (a) Build-Depends (without Depends) on libjson-simple-java and "merge" the > content of its JAR into the orthanc-imagej package during the build, or > (b) Build-Depends + Depends on libjson-simple-json, and modify ImageJ's > internal CLASSPATH to point to the libsjon-simple-java's JAR. > > I do see how to implement option (a) by myself, but not option (b), as it > involves patching a configuration file during installation/removal. Do you > think that option (a) is sufficient wrt. Debian package policy? I admit I know to less about Java but the "merge" you are mentioning in a) is not clear to me. If you Build-Depend on libjson-simple-java the JAR which is in Debian's CLASSPATH will be available as well for the installed package if you Depend from libjson-simple-java. So I see no reason for patching. Any more educated Java programmer will be explain better most probably. 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: https://lists.debian.org/20141215085346.ga...@an3as.eu
Re: ImageJ plugin for Orthanc
Hi Andreas, > sorry for my silence for longer than usual. I'm recovering slowly > from > my vacation (basically for the sake of OpenStreetMap work after the > trip > ;-)). :) > I had a look into the package. It builds fine and is lintian clean > and > I simply assume that it is working (I have no idea how I could > personally test). However, the source contains a code copy of the > package > >libjson-simple-java I hadn't spotted this Debian package! > which should be avoided. Could you imagine to rather "link" (I think > linking is not the proper term in the Java world) against this > library > rather than using the code copy. I see 2 possibilities at this point: (a) Build-Depends (without Depends) on libjson-simple-java and "merge" the content of its JAR into the orthanc-imagej package during the build, or (b) Build-Depends + Depends on libjson-simple-json, and modify ImageJ's internal CLASSPATH to point to the libsjon-simple-java's JAR. I do see how to implement option (a) by myself, but not option (b), as it involves patching a configuration file during installation/removal. Do you think that option (a) is sufficient wrt. Debian package policy? Thanks, Sébastien- -- 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/1292254558.7023374.1418631255576.javamail.r...@chu.ulg.ac.be
