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
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: ?xml version=1.0 encoding=UTF-8? Context path=/BmajWatcher docBase=/usr/share/java/webapps/biomaj-watcher reloadable=false Parameter name=ADMIN_LOGIN value=admin override=false/ .. (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
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
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 Resources allowLinking=true/ 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
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
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 Resources 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: 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: 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: 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
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: 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
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=16435view=markup [2] http://anonscm.debian.org/viewvc/debian-med?view=revisionrevision=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: 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 andr...@an3as.eu: Uploaded to experimental (due to freeze policy). Thanks for your work on this Thank you. Dylan
