Re: Bug#988650: logol: broken symlink: /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar

[olivier sallou]

It appears than xalan2 (requires)-> xerces2 (requires)->
libxml-commons-external-java explicitly removes versioned jar in its build
(debian/libxml-commons-external-java.poms)

debian/xml-apis.xml --java-lib --usj-name=xml-apis --artifact=xml-apis.jar
--no-usj-versionless

Don't know why but it breaks logol.
Fix would be to symlink to versioned jar, but will break on next
libxml-commons-external-java update. Could certainly be scripted to get
related version and link to this version file.

Olivier

Le lun. 17 mai 2021 à 14:05, Andreas Tille  a écrit :

> Hi,
>
> I'd like to forward this to Debian Java list for comments.
>
> Kind regards
>
>   Andreas.
>
> On Mon, May 17, 2021 at 01:50:01PM +0200, olivier sallou wrote:
> > Issue seems to be related to xml-apis.jar not being symlinked itself
> >
> > /usr/share/java# ls *xml-api*
> > xml-apis-1.4.01.jar  xml-apis-ext-1.4.01.jar  xml-apis-ext.jar
> >
> > Usually, java libs have a versioned file and an unversionned file which
> is
> > a symlink to versioned one (see above).
> > xml-apis here is not available as unversioned (breaks previous versions)
> >
> > Logo requires xalan2 and xerces2, must be a sub-dependency,  should -ext
> be
> > used?
> >
> > Le lun. 17 mai 2021 à 13:33, Andreas Beckmann  a écrit
> :
> >
> > > Package: logol
> > > Version: 1.7.9-2
> > > Severity: serious
> > > User: debian...@lists.debian.org
> > > Usertags: piuparts
> > >
> > > Hi,
> > >
> > > during a test with piuparts I noticed your package ships (or creates)
> > > a broken symlink.
> > >
> > > From the attached log (scroll to the bottom...):
> > >
> > > 1m53.8s ERROR: FAIL: Broken symlinks:
> > >   /usr/share/logol/lib/xml-apis.jar -> ../../java/xml-apis.jar (logol)
> > >
> > > Is logol missing a dependency on libjaxp1.3-java ?
> > >
> > >
> > > cheers,
> > >
> > > Andreas
> > >
>
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@alioth-lists.debian.net
> >
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
>
>
> --
> http://fam-tille.de
>


-- 

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

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

Re: [Debian-med-packaging] Bug#973070: Help needed: Bug#973070: libsis-base-java: FTBFS: Could not delete the directory targets/unit-test-wd/ch.systemsx.cisd.base.unix.UnixTests because: 1 exceptions:

[olivier sallou]

On Wed, 2020-10-28 at 09:05 +0100, Andreas Tille wrote:
> Hi,
> 
> On Tue, Oct 27, 2020 at 10:55:43PM +0100, Markus Koschany wrote:
> > This appears to be caused by the recent upgrade of Apache commons-
> > io to
> > version 2.8.0 (we had 2.6), see also #973135. In version 2.7 they
> > removed a throws IOException in the method isSymlink()
> > 
> > https://issues.apache.org/jira/browse/IO-610
> > 
> > Could it be related to this change? It is probably necessary to
> > update
> > the testcase or disable it for a quick workaround.
> 
> I tried to implement this workaroung in this patch
> 
>
> https://salsa.debian.org/med-team/libsis-base-java/-/blob/master/debian/patches/skip_testGetLinkInfoSymLinkDanglingLink.patch
> 
> but unfortunately the test is executed anyway:
*dumb* patch would be to simply remove those tests from code...
> 
> ...
> Running testTouchSymLinkAndFile
> Running testGetLinkInfoSymLinkDanglingLink
> Running testGetLinkInfoNonExistent
> Could not delete the directory targets/unit-test-
> wd/ch.systemsx.cisd.base.unix.UnixTests because: 1 exceptions:
> [java.io.IOException: Unable to delete file: targets/unit-test-
> wd/ch.systemsx.cisd.base.unix.UnixTests/someDanglingLink]
> Could not delete the directory targets/unit-test-
> wd/ch.systemsx.cisd.base.unix.UnixTests in second try because: 1
> exceptions: [java.io.IOException: Unable to delete file:
> targets/unit-test-
> wd/ch.systemsx.cisd.base.unix.UnixTests/someDanglingLink]
> Exception in thread "main" org.apache.commons.io.IOExceptionList: 1
> exceptions: [java.io.IOException: Unable to delete file:
> targets/unit-test-
> wd/ch.systemsx.cisd.base.unix.UnixTests/someDanglingLink]
> ...
> 
> 
> Am I missing something?
> 
> Kind regards
> 
>Andreas.
> 
-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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

Re: Any hints about maven libs from Debian Java team (Was: IGV update - any takers?)

[Olivier Sallou]

On 11/14/19 2:10 PM, Markus Koschany wrote:
> Hi,
>
> Am 14.11.19 um 09:44 schrieb Andreas Tille:
>> Hi,
>>
>> I'd be very happy if Debian Java team could comment on the analysis
>> of libs done by Olivier to enable us upgrading IGV.
>>
>> On Thu, Nov 14, 2019 at 09:34:51AM +0100, Olivier Sallou wrote:
>>> I had a quick look at latest version. It seems to be have been rewritten
>>> a lot, a lots of dependency differences.
>>>
>>> Several java (maven) libs are not available in debian or older (may work
>>> or not):
>>>
>>>
>>>    Not available [group: 'org.campagnelab.goby', name: 'goby-io',
>>> version: '3.3.1']
>>>    Not available [group: 'org.campagnelab.icb', name: 'icb-utils',
>>> version: '2.0.2']
> Try to disable the build-dependency and analyze how much code is
> depending on it. Maybe it is not necessary to get a functional IGV
> package, otherwise someone ™ must package it.


the pb is to know what is "functional". We may patch code to remove deps
and see the final GUI but would not work for everythings And we
do not know software enough to validate it in such case

>
>>>   older version in debian (libjsap-java) [group:
>>> 'org.campagnelab.ext', name: 'jsap', version: '3.0.0']
>>>
>>>   older version in debian (libnb-absolutelayout-java) [group:
>>> 'org.netbeans.external', name: 'AbsoluteLayout', version: 'RELEASE110']
> I believe the current version of libnb-absolutelayout-java should just
> work, if not let me know, upgrading the package should be doable.
> libjsap-java hasn't been updated for three years now. The older version
> could still work, if not, the same applies as for org.campagnelab.*
>
>
>>>     Not available [group: 'software.amazon.awssdk', name:
>>> 'http-client-spi', version: '2.8.5'],
>>>     Not available [group: 'software.amazon.awssdk', name:
>>> 'cognitoidentity', version: '2.8.5'],
>>>     Not available [group: 'software.amazon.awssdk', name: 'sts',
>>> version: '2.8.5'],
>>>     Not available [group: 'software.amazon.awssdk', name: 's3',
>>> version: '2.8.5']
> That sounds like some cloud dependency. Do you really need it?

Amazon sdk for storage indeed. Do we need it ? Well it is part of code.
Removing it, again, would imply to also remove references in menu etc...
(or wherever is used).

Lots of work to remove features, or more difficult to maintain afterward.

>
> Regards,
>
> Markus
>
-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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




signature.asc
Description: OpenPGP digital signature

Re: Error with jh_build

[Olivier Sallou]

> De: "Cyril Richard" 
> À: "Debian Java List" 
> Envoyé: Vendredi 27 Septembre 2019 16:25:33
> Objet: Error with jh_build

> Dear you, I'm currently trying to build a debian package of a java 
> application.
> The application should be host here: [
> https://salsa.debian.org/science-team/spview |
> https://salsa.debian.org/science-team/spview  ] (I'm waiting for permission
> access to push the code).
> For now I'm facing to one issue:

> The structure of my sources is as follow:
> -- resources
> -- sources
> -- test
> -- debian

> I wrote the d/rules like that:

> #!/usr/bin/make -f
> # debian/rules for spview

> %:
> dh $@ --with javahelper --sourcedirectory=sources

> override_jh_build:
> jh_build --javacopts="-source 1.8 -target 1.8" spview.jar sources

looks to be javadoc related step, try 

jh_build --javacopts="-source 1.8 -target 1.8" --javadoc-opts="-source 1.8" 
. 

> And I have the following error:

> make[1]: Entering directory '/build/spview-2.0.0~beta1'
> jh_build --javacopts="-source 1.8 -target 1.8" spview.jar sources
> warning: [options] bootstrap class path not set in conjunction with -source 8
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> 1 warning
> sources/org/spview/preferences/WindowHandler.java:29: error: lambda 
> expressions
> are not supported in -source 7
> CoalescedEventUpdater updater = new CoalescedEventUpdater(400, () ->
> updatePref(frame, prefs));
> ^
> (use -source 8 or higher to enable lambda expressions)
> sources/org/spview/preferences/CoalescedEventUpdater.java:10: error: lambda
> expressions are not supported in -source 7
> timer = new Timer(delay, e -> {
> ^
> (use -source 8 or higher to enable lambda expressions)
> 2 errors
> jh_build: find sources -name '*.java' -and -type f -print0 | xargs -s 512000 
> -0
> /usr/lib/jvm/default-java/bin/javadoc -locale en_US -classpath
> :debian/_jh_build.spview -d debian/_jh_build.javadoc/api -quiet -encoding
> ISO8859-1 -source 1.7 -notimestamp returned exit code 123
> make[1]: *** [debian/rules:8: override_jh_build] Error 255
> make[1]: Leaving directory '/build/spview-2.0.0~beta1'
> make: *** [debian/rules:5: build] Error 2
> dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

> Could you please explain me what I am doing wrong?

> Cheers,

> Cyril RICHARD - Ingénieur de Recherche CNRS

> Equipe Spectroscopie Moléculaire, Processus Collisionnels et Applications
> Département Interactions et Contrôle quantiques (ICQ)

> Laboratoire Interdisciplinaire Carnot de Bourgogne, UMR 6303 CNRS-Univ.
> Bourgogne Franche-Comté
> 9 Avenue Alain Savary, BP 47 870, F-21078 DIJON Cedex FRANCE

> Tel. : +33 (0)3 80 39 59 96 / Fax : +33 (0)3 80 39 59 71
> E-mail : cyril.rich...@u-bourgogne.fr
> Web : http://icb.u-bourgogne.fr

Re: [Debian-med-packaging] Bug#923756: libhac-java: FTBFS in buster/sid

[Olivier Sallou]

- Andreas Tille  a écrit :
> Hi Debian Java team,
> 
> On Tue, Mar 05, 2019 at 12:19:40AM +, Santiago Vila wrote:
> > jh_build -J hac.jar src
> > find src -name *.java -and -type f -print0 | xargs -s 512000 -0 
> > /usr/lib/jvm/default-java/bin/javac -g -cp :debian/_jh_build.hac -d 
> > debian/_jh_build.hac -source 1.7 -target 1.7 -encoding ISO8859-1
> > warning: [options] bootstrap class path not set in conjunction with -source 
> > 7
> > 1 warning
> > find src -name *.java -and -type f -print0 | xargs -s 512000 -0 
> > /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link 
> > /usr/share/doc/default-jdk-doc/api -link 
> > /usr/share/doc/default-jre-headless/api -classpath :debian/_jh_build.hac -d 
> > debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp 
> > -source 1.7
> > Creating destination directory: "debian/_jh_build.javadoc/api/"
> > javadoc: error - The code being documented uses packages in the unnamed 
> > module, but the packages defined in /usr/share/doc/default-jdk-doc/api/ are 
> > in named modules.
> > javadoc: error - The code being documented uses packages in the unnamed 
> > module, but the packages defined in 
> > /usr/share/doc/default-jre-headless/api/ are in named modules.
> > 2 errors
> > make[1]: *** [debian/rules:9: override_dh_auto_build] Error 123
> 
> Any idea how to fix this?

Short term workaround would be to disable javadoc generation and related package

Found many related bugs but no quick resolution and patching code may be a long 
task

Olivier
> 
> Kind regards
> 
> Andreas.
> 
> -- 
> http://fam-tille.de
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

Re: New version has switched build system to Maven - any hint how to resolve dependencies?

[Olivier Sallou]

- Mail original -
> De: "andreas" 
> À: "Debian Java List" 
> Cc: "debian-med" , "Afif Elghraoui" 
> 
> Envoyé: Mardi 29 Janvier 2019 10:20:48
> Objet: Re: New version has switched build system to Maven - any hint how to 
> resolve dependencies?

> Hi Emmanuel,
> 
> On Mon, Jan 28, 2019 at 09:15:49PM +0100, Emmanuel Bourg wrote:
>> No no no it has to work, otherwise you'll run into many other issues...
> 
> Ahhh, another very helpful hint.  I was running mh_make now and was
> merging its results in.  That was very enlightening and saved me some
> stupid patches I did before just since I was to stupid to understand
> maven-helper.
> 
>> > [ERROR] Failed to execute goal on project artemis: Could not resolve
>> > dependencies for project uk.ac.sanger:artemis:jar:18.0.1: The following
>> > artifacts could not be resolved: 
>> > org.apache.xmlgraphics:batik-codec:jar:1.9.1,
>> > org.apache.xmlgraphics:batik-dom:jar:1.9.1,
>> > org.apache.xmlgraphics:batik-ext:jar:1.9.1,
>> > org.apache.xmlgraphics:batik-svggen:jar:1.9.1,
>> > org.apache.xmlgraphics:batik-util:jar:1.9.1, 
>> > com.ibatis:ibatis:jar:2.3.4.726,
>> > cglib:cglib-nodep:jar:2.2, com.sshtools:j2ssh-core:jar:0.2.9,
>> > org.emboss:jemboss:jar:1.0, org.biojava:biojava:jar:1.6,
>> > com.github.broadinstitute:picard:jar:2.18.14,
>> > org.evosuite:evosuite-standalone-runtime:jar:1.0.6,
>> > org.mockito:mockito-core:jar:2.23.0: Cannot access central
>> > (https://repo.maven.apache.org/maven2) in offline mode and the artifact
>> > org.apache.xmlgraphics:batik-codec:jar:1.9.1 has not been downloaded from 
>> > it
>> > before. -> [Help 1]
>> 
>> ...like this one :)
> 
> On the other hand I think there are some remaining packages that are
> not featuring proper maven helper.  So I'm now remaining with:
> 
> 
> [INFO] < uk.ac.sanger:artemis 
> >
> [INFO] Building Artemis 18.0.1
> [INFO] [ jar 
> ]-
> [WARNING] The POM for com.ibatis:ibatis:jar:debian is missing, no dependency
> information available
> [WARNING] The POM for com.sshtools:j2ssh-core:jar:debian is missing, no
> dependency information available
> [WARNING] The POM for org.emboss:jemboss:jar:debian is missing, no dependency
> information available
> [WARNING] The POM for org.biojava:biojava:jar:debian is missing, no dependency
> information available
> [WARNING] The POM for com.github.broadinstitute:picard:jar:debian is missing, 
> no
> dependency information available
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  0.450 s
> [INFO] Finished at: 2019-01-29T08:29:42Z
> [INFO] 
> 
> [ERROR] Failed to execute goal on project artemis: Could not resolve
> dependencies for project uk.ac.sanger:artemis:jar:18.0.1: The following
> artifacts could not be resolved: com.ibatis:ibatis:jar:debian,
> com.sshtools:j2ssh-core:jar:debian, org.emboss:jemboss:jar:debian,
> org.biojava:biojava:jar:debian, com.github.broadinstitute:picard:jar:debian:
> Cannot access central (https://repo.maven.apache.org/maven2) in offline mode
> and the artifact com.ibatis:ibatis:jar:debian has not been downloaded from it
> before. -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> 
> 
> which are less issues but the according JARs are definitely inside Debian:
> 
> com.ibatis:ibatis:jar:debian -> libibatis-java
> com.sshtools:j2ssh-core:jar:debian -> libj2ssh-java
> org.emboss:jemboss:jar:debian -> jemboss
> org.biojava:biojava:jar:debian -> libbiojava-java
> com.github.broadinstitute:picard:jar:debian -> picard-tools

last 2 are build respectivly with ant and gradle, not maven, reason why they do 
not expose any maven stuff. Nothing done by build-system.
But indeed we can manually (debian side) add some maven stuff to make it maven 
compliant.
We need to add some pom related files and copy files to usr/share/maven 
directories. Don't know what maven-helper can do to help us with this.
I think I will need to read maven-helper doc to see what can be done.


> 
> While the latter three are in possession of the Debian Med team and I'm
> willing to add proper maven metadata to enable correct detection for the
> future, I think there are some replacement rules which would let the
> package build.  Unfortunately I never have understand these
> substitutions done in debian/maven.rules and I wonder whether some kind
> 

Re: Attempt to upgrade libjsonp-java - help needed

[Olivier Sallou]

On 1/25/19 9:45 AM, Andreas Tille wrote:
> Hi Olivier,
>
> On Thu, Jan 24, 2019 at 10:59:33PM +0100, Olivier Sallou wrote:
>>>> should be able to add in pom.xml
>>>>
>>>> 
>>>>     true
>>>> 
>>> This works (Emmanuel, just leaving out the -doc package is not
>>> sufficient in this case).
>>>
>>> Unfortunately I'm running into the next issue now:
>>>
>>> ...
>>> [WARNING] Failed to retrieve plugin descriptor for 
>>> org.codehaus.mojo:build-helper-maven-plugin:3.0.0: Plugin 
>>> org.codehaus.mojo:build-helper-maven-plugin:3.0.0
>>
>> org.codehaus.mojo:build-helper-maven-plugin:3.0.0 is missing (i suppose, i 
>> cannot read code for the moment) in the build deoendencies. Looks to be 
>> https://packages.debian.org/source/jessie/build-helper-maven-plugin
>>
>>  or one of its dependencies could not be resolved: Cannot access central 
>> (https://repo.maven.apache.org/maven2) in offline mode and the artifact 
>> org.codehaus.mojo:build-helper-maven-plugin:jar:3.0.0 has not been 
>> downloaded from it before.
> I confirm this warning goes away with the following patch
>
> $ git diff
> diff --git a/debian/control b/debian/control
> index acd672c..b7e9449 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -10,7 +10,8 @@ Build-Depends-Indep: libmaven-bundle-plugin-java,
>   libmaven-dependency-plugin-java,
>   libmaven-javadoc-plugin-java,
>   libmaven-source-plugin-java,
> - default-jdk-doc
> + default-jdk-doc,
> + libbuild-helper-maven-plugin-java
>  Standards-Version: 4.3.0
>  Vcs-Browser: https://salsa.debian.org/java-team/libjsonp-java
>  Vcs-Git: https://salsa.debian.org/java-team/libjsonp-java.git
>
>
> ... but this does not lead to a successful build and most of the
> issues - specifically the remaining error - remain.
>
> Any further hints?
>
> Kind regards
>
> Andreas.
>
>>> [INFO] 
>>> [INFO] --- maven-source-plugin:3.0.1:jar-no-fork (attach-sources) @ json ---
>>> [INFO] 
>>> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ json ---
>>> [INFO] Installing /build/libjsonp-java-1.1.2/pom.xml to 
>>> /build/libjsonp-java-1.1.2/debian/maven-repo/org/glassfish/json/1.1.2/json-1.1.2.pom
>>> [INFO] 
>>> [INFO] --- maven-javadoc-plugin:3.0.1:jar (default-cli) @ json ---
>>> [INFO] Skipping javadoc generation
>>> [INFO] 
>>> [INFO] -< javax.json:javax.json-api 
>>> >--
>>> [INFO] Building JSR 374 (JSON Processing) API 1.1.2   
>>> [2/4]
>>> [INFO] ---[ bundle 
>>> ]---
>>> [INFO] 
>>> [INFO] --- maven-resources-plugin:3.1.0:resources (default-resources) @ 
>>> javax.json-api ---
>>> [WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy 
>>> filtered resources, i.e. build is platform dependent!
>>> [INFO] skip non existing resourceDirectory 
>>> /build/libjsonp-java-1.1.2/api/src/main/resources
>>> [INFO] 
>>> [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @ 
>>> javax.json-api ---
>>> [INFO] Changes detected - recompiling the module!
>>> [WARNING] File encoding has not been set, using platform encoding 
>>> ANSI_X3.4-1968, i.e. build is platform dependent!
>>> [INFO] Compiling 34 source files to 
>>> /build/libjsonp-java-1.1.2/api/target/classes
>>> [WARNING] 
>>> /build/libjsonp-java-1.1.2/api/src/main/java/javax/json/spi/JsonProvider.java:[97,40]
>>>  newInstance() in java.lang.Class has been deprecated
>>> [INFO] 
>>> [INFO] --- maven-resources-plugin:3.1.0:testResources 
>>> (default-testResources) @ javax.json-api ---
>>> [WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy 
>>> filtered resources, i.e. build is platform dependent!
>>> [INFO] skip non existing resourceDirectory 
>>> /build/libjsonp-java-1.1.2/api/src/test/resources
>>> [INFO] 
>>> [INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @ 
>>> javax.json-api ---
>>> [INFO] No sources to compile
>>> [INFO] 
>>> [INFO] --- maven-surefire-plugin:2.22.1:test (default-test) @ 
>>> javax.json-api ---
>>> [INFO] Tests are skipped.
>>> [INFO] 
>>> [INFO] --- maven-bundle-plugin:3

Re: Attempt to upgrade libjsonp-java - help needed

[Olivier Sallou]

- Andreas Tille  a écrit :
> Hi Olivier,
> 
> On Thu, Jan 24, 2019 at 05:54:54PM +0100, Olivier Sallou wrote:
> > 
> > should be able to add in pom.xml
> > 
> > 
> >     true
> > 
> 
> This works (Emmanuel, just leaving out the -doc package is not
> sufficient in this case).
> 
> Unfortunately I'm running into the next issue now:
> 
> ...
> [WARNING] Failed to retrieve plugin descriptor for 
> org.codehaus.mojo:build-helper-maven-plugin:3.0.0: Plugin 
> org.codehaus.mojo:build-helper-maven-plugin:3.0.0


org.codehaus.mojo:build-helper-maven-plugin:3.0.0 is missing (i suppose, i 
cannot read code for the moment) in the build deoendencies. Looks to be 
https://packages.debian.org/source/jessie/build-helper-maven-plugin

 or one of its dependencies could not be resolved: Cannot access central 
(https://repo.maven.apache.org/maven2) in offline mode and the artifact 
org.codehaus.mojo:build-helper-maven-plugin:jar:3.0.0 has not been downloaded 
from it before.
> [INFO] 
> [INFO] --- maven-source-plugin:3.0.1:jar-no-fork (attach-sources) @ json ---
> [INFO] 
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ json ---
> [INFO] Installing /build/libjsonp-java-1.1.2/pom.xml to 
> /build/libjsonp-java-1.1.2/debian/maven-repo/org/glassfish/json/1.1.2/json-1.1.2.pom
> [INFO] 
> [INFO] --- maven-javadoc-plugin:3.0.1:jar (default-cli) @ json ---
> [INFO] Skipping javadoc generation
> [INFO] 
> [INFO] -< javax.json:javax.json-api 
> >--
> [INFO] Building JSR 374 (JSON Processing) API 1.1.2   
> [2/4]
> [INFO] ---[ bundle 
> ]---
> [INFO] 
> [INFO] --- maven-resources-plugin:3.1.0:resources (default-resources) @ 
> javax.json-api ---
> [WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy filtered 
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory 
> /build/libjsonp-java-1.1.2/api/src/main/resources
> [INFO] 
> [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @ 
> javax.json-api ---
> [INFO] Changes detected - recompiling the module!
> [WARNING] File encoding has not been set, using platform encoding 
> ANSI_X3.4-1968, i.e. build is platform dependent!
> [INFO] Compiling 34 source files to 
> /build/libjsonp-java-1.1.2/api/target/classes
> [WARNING] 
> /build/libjsonp-java-1.1.2/api/src/main/java/javax/json/spi/JsonProvider.java:[97,40]
>  newInstance() in java.lang.Class has been deprecated
> [INFO] 
> [INFO] --- maven-resources-plugin:3.1.0:testResources (default-testResources) 
> @ javax.json-api ---
> [WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy filtered 
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory 
> /build/libjsonp-java-1.1.2/api/src/test/resources
> [INFO] 
> [INFO] --- maven-compiler-plugin:3.8.0:testCompile (default-testCompile) @ 
> javax.json-api ---
> [INFO] No sources to compile
> [INFO] 
> [INFO] --- maven-surefire-plugin:2.22.1:test (default-test) @ javax.json-api 
> ---
> [INFO] Tests are skipped.
> [INFO] 
> [INFO] --- maven-bundle-plugin:3.5.1:bundle (default-bundle) @ javax.json-api 
> ---
> [INFO] 
> [INFO] --- maven-javadoc-plugin:3.0.1:jar (attach-javadocs) @ javax.json-api 
> ---
> [INFO] Skipping javadoc generation
> [INFO] 
> [INFO] --- maven-source-plugin:3.0.1:jar-no-fork (attach-sources) @ 
> javax.json-api ---
> [INFO] Building jar: 
> /build/libjsonp-java-1.1.2/api/target/javax.json-api-1.1.2-sources.jar
> [INFO] 
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
> javax.json-api ---
> [INFO] Installing 
> /build/libjsonp-java-1.1.2/api/target/javax.json-api-1.1.2.jar to 
> /build/libjsonp-java-1.1.2/debian/maven-repo/javax/json/javax.json-api/1.1.2/javax.json-api-1.1.2.jar
> [INFO] Installing /build/libjsonp-java-1.1.2/api/pom.xml to 
> /build/libjsonp-java-1.1.2/debian/maven-repo/javax/json/javax.json-api/1.1.2/javax.json-api-1.1.2.pom
> [INFO] Installing 
> /build/libjsonp-java-1.1.2/api/target/javax.json-api-1.1.2-sources.jar to 
> /build/libjsonp-java-1.1.2/debian/maven-repo/javax/json/javax.json-api/1.1.2/javax.json-api-1.1.2-sources.jar
> [INFO] 
> [INFO] --- maven-bundle-plugin:3.5.1:install (default-install) @ 
> javax.json-api ---
> [INFO] Writing OBR metadata
> [INFO] Installing javax/json/javax.json-api/1.1.2/javax.json-api-1.1.2.jar
> [INFO] Writing OBR metadata
> [INFO] 
> [INFO] --- maven-javadoc-plugin:3.0.1:jar (default-cli) @ javax.json-api ---
> [INFO] Skipping javadoc generation
> [INFO] 
> [INFO] --< org.glassfish:java

Re: Attempt to upgrade libjsonp-java - help needed

[Olivier Sallou]

On 1/24/19 5:47 PM, Andreas Tille wrote:
> Hi Markus,
>
> On Thu, Jan 24, 2019 at 12:27:35PM +0100, Markus Koschany wrote:
>> If the documentation is not super important to you, I recommend to just
>> drop the -doc package.
> Doc is absolutely not important - its just a predependency of one of my
> packages.  Do you have a hint where to poke to get rid of the doc
> creation.  I fiddled around a bit with the pom.xmls but failed. :-(


should be able to add in pom.xml


    true



else can be specified via mvn cmdline -Dmaven.javadoc.skip=true but as
mvn is executed by maven debhelper I don't know hwo to add this argument

>
> Kind regards
>
>   Andreas.
>
-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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

Re: Bug#893409: pixelmed FTBFS with openjdk-9

[Olivier Sallou]

On 12/19/18 11:46 AM, Andreas Tille wrote:
> Hi,
>
> On Wed, Dec 19, 2018 at 10:39:55AM +0100, Olivier Sallou wrote:
>>> The missing class is in libjaxb-api-java. Just make sure it's on the
>>> CLASSPATH.
>> yeap, an other issue at java migration to openjdk 10/11
>>
>> Adding this lib to deps should fix the pb

- I have fixed the problem, updating patch (lib needed to be added to
other Makefile)

- There were some other issues with an old jdk package moved to an other
location, from JDK 9 in 2016, which is not exported [0]. Surprisingly it
compiles anyway, but does it work as expected?? It seems there is a
new API (java.lang.ref.Cleaner) but I'm not sure it could be replaced as
easily (and without knowing side effects), it should be updated by upstream

In the meanwhile I renamed the related package in patch.

- vecmath needed to be added as well in Makefile (done)

- javadoc generation classpath needed to be updated as well (done)

- I think that vecmath and jaxb-api jars will need to be added in
runtime classpath (debian/DicomXX etc..) as well   (NOT done)

- 4 tests are failing (surprisingly, packaging continues)

- lintian: some errors, documentation is not in correct directory
(libpixelmed-java-doc expects files in
/usr/share/doc/libpixelmed-java-doc but doc is in
/usr/share/doc/libpixelmed-java) (NOT fixed)



I have pushed my updates to git (file not found , certainly a result not
generated, but no additional info)


[0] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8148117

Olivier

> Thanks for the quick help.  I tried:
>
>
> diff --git a/debian/control b/debian/control
> index e0548ee..3f8b86c 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -14,7 +14,8 @@ Build-Depends-Indep: default-jdk,
>   libjmdns-java,
>   libvecmath-java,
>   libpixelmed-codec-java,
> - libjsonp-java
> + libjsonp-java,
> + libjaxb-api-java
>  Standards-Version: 4.2.1
>  Vcs-Browser: https://salsa.debian.org/med-team/pixelmed
>  Vcs-Git: https://salsa.debian.org/med-team/pixelmed.git
> diff --git a/debian/patches/fixdoc.patch b/debian/patches/fixdoc.patch
> index 752b78c..1737f5f 100644
> --- a/debian/patches/fixdoc.patch
> +++ b/debian/patches/fixdoc.patch
> @@ -11,7 +11,7 @@ Index: pixelmed-20140326/Makefile
> rm -rf docs/javadoc
> javadoc \
>  -  -classpath 
> .:lib/additional/excalibur-bzip2-1.0.jar:lib/additional/hsqldb.jar:lib/additional/vecmath1.2-1.14.jar:lib/additional/commons-codec-1.3.jar:lib/additional/commons-net2.jar:lib/additional/jmdns.jar:lib/additional/jpedalSTD.jar:lib/junit/junit-4.8.1.jar
>  \
> -+  -classpath 
> .:/usr/share/java/excalibur-bzip2-1.0.jar:/usr/share/java/hsqldb.jar:/usr/share/java/vecmath.jar:/usr/share/java/commons-codec.jar:/usr/share/java/commons-net2.jar:/usr/share/java/jmdns.jar:/usr/share/java/jpedalSTD.jar:/usr/share/java/junit4.jar
>  \
> ++  -classpath 
> .:/usr/share/java/excalibur-bzip2-1.0.jar:/usr/share/java/hsqldb.jar:/usr/share/java/vecmath.jar:/usr/share/java/commons-codec.jar:/usr/share/java/commons-net2.jar:/usr/share/java/jmdns.jar:/usr/share/java/jpedalSTD.jar:/usr/share/java/junit4.jar:/usr/share/java/jaxb-api.jar
>  \
> -link http://download.oracle.com/javase/1.5.0/docs/api/ \
> -link http://jpedal.org/javadoc/ \
> -link http://www.hsqldb.org/doc/src/ \
> diff --git a/debian/patches/jaxb-api.patch b/debian/patches/jaxb-api.patch
> new file mode 100644
> index 000..85760dd
> --- /dev/null
> +++ b/debian/patches/jaxb-api.patch
> @@ -0,0 +1,16 @@
> +Description: For OpenJDK 11 jaxb needs to be in classpath
> +Bug-Debian: https://bugs.debian.org/893409
> +Author: Andreas Tille 
> +Last-Update: Wed, 19 Dec 2018 08:53:43 +0100
> +
> +--- a/Makefile.common.mk
>  b/Makefile.common.mk
> +@@ -65,7 +65,7 @@ JAVACOPTIONS = -O ${JAVACTARGETOPTIONS}
> + 
> + .java.class:
> +   export JAVAVERSIONTARGETJARFILE=${JAVA_HOME}/jre/lib/rt.jar; javac 
> ${JAVACOPTIONS} \
> +-  -classpath 
> ${PATHTOROOT}:${DICOMADDITIONALJARS}:${VIEWERADDITIONALJARS}:${FTPADDITIONALJARS}:${JUNITJAR}
>  \
> ++  -classpath 
> ${PATHTOROOT}:${DICOMADDITIONALJARS}:${VIEWERADDITIONALJARS}:${FTPADDITIONALJARS}:${JUNITJAR}:/usr/share/java/jaxb-api.jar
>  \
> +   -sourcepath ${PATHTOROOT} $<
> + 
> + .png.ico:
> diff --git a/debian/patches/series b/debian/patches/series
> index 10286d4..6abfc45 100644
> --- a/debian/patches/series
> +++ b/debian/patches/series
> @@ -16,3 +16,4 @@ set_java_home.patch
>  imageio.patch
>  no_Xdiags_verbose.patch
>  do_not_set_bootclasspath.

Re: Bug#893409: pixelmed FTBFS with openjdk-9

[Olivier Sallou]

On 12/19/18 11:46 AM, Andreas Tille wrote:
> Hi,
>
> On Wed, Dec 19, 2018 at 10:39:55AM +0100, Olivier Sallou wrote:
>>> The missing class is in libjaxb-api-java. Just make sure it's on the
>>> CLASSPATH.
>> yeap, an other issue at java migration to openjdk 10/11
>>
>> Adding this lib to deps should fix the pb
> Thanks for the quick help.  I tried:
>
>
> diff --git a/debian/control b/debian/control
> index e0548ee..3f8b86c 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -14,7 +14,8 @@ Build-Depends-Indep: default-jdk,
>   libjmdns-java,
>   libvecmath-java,
>   libpixelmed-codec-java,
> - libjsonp-java
> + libjsonp-java,
> + libjaxb-api-java
>  Standards-Version: 4.2.1
>  Vcs-Browser: https://salsa.debian.org/med-team/pixelmed
>  Vcs-Git: https://salsa.debian.org/med-team/pixelmed.git
> diff --git a/debian/patches/fixdoc.patch b/debian/patches/fixdoc.patch
> index 752b78c..1737f5f 100644
> --- a/debian/patches/fixdoc.patch
> +++ b/debian/patches/fixdoc.patch
> @@ -11,7 +11,7 @@ Index: pixelmed-20140326/Makefile
> rm -rf docs/javadoc
> javadoc \
>  -  -classpath 
> .:lib/additional/excalibur-bzip2-1.0.jar:lib/additional/hsqldb.jar:lib/additional/vecmath1.2-1.14.jar:lib/additional/commons-codec-1.3.jar:lib/additional/commons-net2.jar:lib/additional/jmdns.jar:lib/additional/jpedalSTD.jar:lib/junit/junit-4.8.1.jar
>  \
> -+  -classpath 
> .:/usr/share/java/excalibur-bzip2-1.0.jar:/usr/share/java/hsqldb.jar:/usr/share/java/vecmath.jar:/usr/share/java/commons-codec.jar:/usr/share/java/commons-net2.jar:/usr/share/java/jmdns.jar:/usr/share/java/jpedalSTD.jar:/usr/share/java/junit4.jar
>  \
> ++  -classpath 
> .:/usr/share/java/excalibur-bzip2-1.0.jar:/usr/share/java/hsqldb.jar:/usr/share/java/vecmath.jar:/usr/share/java/commons-codec.jar:/usr/share/java/commons-net2.jar:/usr/share/java/jmdns.jar:/usr/share/java/jpedalSTD.jar:/usr/share/java/junit4.jar:/usr/share/java/jaxb-api.jar
>  \
> -link http://download.oracle.com/javase/1.5.0/docs/api/ \
> -link http://jpedal.org/javadoc/ \
> -link http://www.hsqldb.org/doc/src/ \
> diff --git a/debian/patches/jaxb-api.patch b/debian/patches/jaxb-api.patch
> new file mode 100644
> index 000..85760dd
> --- /dev/null
> +++ b/debian/patches/jaxb-api.patch
> @@ -0,0 +1,16 @@
> +Description: For OpenJDK 11 jaxb needs to be in classpath
> +Bug-Debian: https://bugs.debian.org/893409
> +Author: Andreas Tille 
> +Last-Update: Wed, 19 Dec 2018 08:53:43 +0100
> +
> +--- a/Makefile.common.mk
>  b/Makefile.common.mk
> +@@ -65,7 +65,7 @@ JAVACOPTIONS = -O ${JAVACTARGETOPTIONS}
> + 
> + .java.class:
> +   export JAVAVERSIONTARGETJARFILE=${JAVA_HOME}/jre/lib/rt.jar; javac 
> ${JAVACOPTIONS} \
> +-  -classpath 
> ${PATHTOROOT}:${DICOMADDITIONALJARS}:${VIEWERADDITIONALJARS}:${FTPADDITIONALJARS}:${JUNITJAR}
>  \
> ++  -classpath 
> ${PATHTOROOT}:${DICOMADDITIONALJARS}:${VIEWERADDITIONALJARS}:${FTPADDITIONALJARS}:${JUNITJAR}:/usr/share/java/jaxb-api.jar
>  \
> +   -sourcepath ${PATHTOROOT} $<
> + 
> + .png.ico:
> diff --git a/debian/patches/series b/debian/patches/series
> index 10286d4..6abfc45 100644
> --- a/debian/patches/series
> +++ b/debian/patches/series
> @@ -16,3 +16,4 @@ set_java_home.patch
>  imageio.patch
>  no_Xdiags_verbose.patch
>  do_not_set_bootclasspath.patch
> +jaxb-api.patch
>
>
>
> I've pushed these changes but unfortunately it does not help. :-(


I'm looking at the issue

>
> Any further hints?
>
> Kind regards
>
>   Andreas.
>
>
-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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

Re: Bug#893409: pixelmed FTBFS with openjdk-9

[Olivier Sallou]

On 12/19/18 10:03 AM, Markus Koschany wrote:
> Hi,
>
> Am 19.12.18 um 09:58 schrieb Andreas Tille:
> [...]
>> Any hint how to fix this?
> The missing class is in libjaxb-api-java. Just make sure it's on the
> CLASSPATH.

yeap, an other issue at java migration to openjdk 10/11

Adding this lib to deps should fix the pb


> Regards,
>
> Markus
>
>
>
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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



signature.asc
Description: OpenPGP digital signature

Re: [Debian-med-packaging] Bug#906371: Changes in alter-sequence-alignment break build of jmodeltest (Was: Bug#906371: jmodeltest: FTBFS in buster/sid)

[Olivier Sallou]

On 12/17/18 11:07 AM, Andreas Tille wrote:
> Hi,
>
> after I tried to follow the initial hint of Emmanuel I admit I was not
> successful to finally build the package:
>
> On Wed, Oct 17, 2018 at 10:32:58AM +0200, Andreas Tille wrote:
>>> Good catch.  The latest upstream version of alter-sequence-alignment has
>>> split these to an additional alter-lib.jar and the time of the build
>>> failure of jmodeltest correlates with the upload of
>>> alter-sequence-alignment 1.3.4-1.  But now the question is:  How to
>>> teach the jmodeltest build system to use alter-lib.jar.  I think adding
>>> it to debian/manifest[1] is needed to *run* jmodeltest but it surely
>>> does not help at build time.  I have not found any place where the
>>> build system specifies the needed jars. :-(
>> I tried to add alter-lib.jar to build.xml[1].  Unfortunately this does
>> not help to fix the issue
>>
>> [javac] 
>> /build/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/ModelTestService.java:28:
>>  error: package parser does not exist
>> [javac] import parser.ParseException;
>> [javac]  ^
>> [javac] 
>> /build/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/ModelTestService.java:29:
>>  error: package converter does not exist
>> [javac] import converter.Converter;
>> [javac] ^
>> [javac] 
>> /build/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/ModelTestService.java:30:
>>  error: package converter does not exist
>> [javac] import converter.DefaultFactory;
>> [javac] ^
>> [javac] 
>> /build/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/ModelTestService.java:31:
>>  error: package converter does not exist
>> [javac] import converter.Factory;
>>
>> Any hint how to get the classes in alter-lib.jar found?

I fixed the issue and pushed to git my patch d/patches/fix_alter-lib.patch

The lib was used but the package name in alter-lib.jar is different.
ModelTestService is patched to use correct package name

>> Moreover I get lots of
>>
>> [javac] 
>> /build/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/exe/Distributor.java:23:
>>  warning: [deprecation] Observable in java.util has been deprecated
>> [javac] import java.util.Observable;
>> [javac] ^
> Any more hints?
>
> Kind regards
>
>Andreas. 
>
-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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

Re: biojava-live (1.7) does not build with OpenJDK 11: package com.sun.corba.se.spi.legacy.connection does not exist

[Olivier Sallou]

- Andreas Tille  a écrit :
> Hi,
> 
> I tried to polish the packaging of biojava-live and was running into:


Biojava is quite old (recent is biojava 4), and kept mainly for compatibility i 
think.

As suggested by emmanuel, maybe easiest would be to patch out corba related 
stuff (is there any corba service still running in real world? )

Deprecated stuff won't be easy to adapt to recent jdks.

Olivier


> 
> ...
> [javac] 
> /build/biojava-live-1.7.1/src/org/biojava/bio/structure/PDBHeader.java:10: 
> error: package com.sun.corba.se.spi.legacy.connection does not exist
> [javac] import 
> com.sun.corba.se.spi.legacy.connection.GetEndPointInfoAgainException;
> [javac]  ^
> [javac] Note: Some input files use or override a deprecated API.
> 
> 
> Any hint how to fix this?
> 
> Kind regards
> 
> Andreas.
> 
> -- 
> http://fam-tille.de
> 

Re: Bug#912385: rdp-classifier FTBFS with OpenJDK 11

[Olivier Sallou]

- Mail original -
> De: "andreas" 
> À: 912...@bugs.debian.org, "Debian Java List" 
> Envoyé: Mercredi 31 Octobre 2018 07:07:36
> Objet: Re: Bug#912385: rdp-classifier FTBFS with OpenJDK 11

> Control: tags -1 help
> 
> Hi,
> 
> I'm afraid I need help for this bug from the Debian Java team.
> 
> Kind regards
> 
>   Andreas.
> 
> On Wed, Oct 31, 2018 at 04:56:52AM +0200, Adrian Bunk wrote:
>> Source: rdp-classifier
>> Version: 2.10.2-3
>> Severity: serious
>> Tags: ftbfs
>> 
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/rdp-classifier.html
>> 
>> ...
>> junit:
>> [javac] /build/1st/rdp-classifier-2.10.2/tmp-junit.xml:13: warning:
>> 'includeantruntime' was not set, defaulting to build.sysclasspath=last; 
>> set to
>> false for repeatable builds
>> [javac] Compiling 18 source files
>> [javac] warning: [options] bootstrap class path not set in conjunction 
>> with
>> -source 8
>> [javac] Note: Some input files use unchecked or unsafe operations.
>> [javac] Note: Recompile with -Xlint:unchecked for details.
>> [javac] 1 warning
>>  [echo] Using java version 11.0.1
>> [junit] Error occurred during initialization of boot layer
>> [junit] java.lang.module.FindException: Module java.se.ee not found


think this needs to be forwarded to upstream (if any...)

According to javadoc [0]

@Deprecated(since="9", forRemoval=true)

Module java.se.ee
Deprecated, for removal: This API element is subject to removal in a future 
version.



In the meanwhile, adding --add-module java.se.ee should do the job

Some module that were removed from jdk and need the --add-module option:

java.xml.ws (JAX-WS, plus the related technologies SAAJ and Web Services 
Metadata)
java.xml.bind (JAXB)
java.activation (JAF)
java.xml.ws.annotation (Common Annotations)
java.corba (CORBA)
java.transaction (JTA)

Related modules in Java SE 9 are also deprecated for removal:

java.se.ee (Aggregator module for the six modules above)
jdk.xml.ws (Tools for JAX-WS)
jdk.xml.bind (Tools for JAXB)



[0] https://docs.oracle.com/javase/9/docs/api/java.se.ee-summary.html



>> [junit] Running edu.msu.cme.rdp.classifier.rrnaclassifier.ClassifierTest
>> [junit] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 
>> 0 sec
>> 
>> BUILD FAILED
>> /build/1st/rdp-classifier-2.10.2/tmp-junit.xml:31: Test
>> edu.msu.cme.rdp.classifier.rrnaclassifier.ClassifierTest failed (crashed)
>> 
>> Total time: 3 seconds
>> make[1]: *** [debian/rules:26: override_dh_auto_test] Error 1
>> 
>> ___
>> Debian-med-packaging mailing list
>> debian-med-packag...@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 
> --
> http://fam-tille.de

Re: Unresolved ${java:Depends} (Was: IGV)

[Olivier Sallou]

On 10/19/18 1:47 PM, Andreas Tille wrote:
> Hi,
>
> On Fri, Oct 19, 2018 at 01:26:30PM +0200, Emmanuel Bourg wrote:
>> Le 19/10/2018 à 13:20, Andreas Tille a écrit :
>>
>>> Any comment from the Debian Java team?
>> If I remember well ${java:Depends} is inferred from the Class-Path
>> attribute in the MANIFEST.MF file of the jars installed in the package.
>> Could you check the manifest of the jar generated?


I have added d/igv.manifest, and jar MANIFEST gets updated as well as
java:Depends.


but file needs to be updates with package if new deps are added (did
not check that all deps are ok)


Olivier

> When looking inside
>
> igv-2.4.6.jar: META-INF/MANIFEST.MF
> Manifest-Version: 1.0
> Permissions: all-permissions
> Application-Name: IGV
> Main-Class: org.broad.igv.ui.Main
>
>
> igv-2.4.14+dfsg.jar: META-INF/MANIFEST.MF
> Manifest-Version: 1.0
> Permissions: all-permissions
> Application-Name: IGV
> Main-Class: org.broad.igv.ui.Main
>
>
> I can not see any difference.  Is there any other place to look?
>
> Kind regards
>
>Andreas.
>
-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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

Re: Continued build issues with IGV: Could not resolve org.apache.logging.log4j:log4j:debian

[Olivier Sallou]

On 10/16/2018 02:51 PM, Andreas Tille wrote:
> Hi Olivier,
>
> thanks a lot for looking into this.
I pushed missing d/control dep liblog4j2-java
>
> On Tue, Oct 16, 2018 at 10:45:08AM +0200, Olivier Sallou wrote:
>>
>>> sorry for the private ping, but may be you have an idea how to
>>> build igv?
>> Hi,
>> after lots of fixes, I could get igv build (and had to make a few
>> updates to d/bin/igv too)
>>
>> however, I removed the Java 9 module support for igv itself.. Could not
>> make it build to provide igv as a module, only as a "old" lib/bin
>>
>> could not test due to x11 pb, but it builds and do not complain on
>> missing libs.
>>
>> I pushed all my updates
> I tried to build your latest commit (eaa95f1c [1]) but I get:
>
> ...
> Passing through xalan:serializer:jar:debian
> Passing through commons-logging:commons-logging:jar:debian
> :compileJava FAILED
> :compileJava (Thread[Daemon worker,5,main]) completed. Took 0.64 secs.
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Could not resolve all files for configuration ':compileClasspath'.
>> Could not resolve org.apache.logging.log4j:log4j:debian.
>   Required by:
>   project :
>> No cached version of org.apache.logging.log4j:log4j:debian available for 
> offline mode.
>> Could not resolve org.apache.logging.log4j:log4j-api:debian.
>   Required by:
>   project :
>> No cached version of org.apache.logging.log4j:log4j-api:debian available 
> for offline mode.
>> Could not resolve org.apache.logging.log4j:log4j-1.2-api:debian.
>   Required by:
>   project :
>> No cached version of org.apache.logging.log4j:log4j-1.2-api:debian 
> available for offline mode.
>> Could not resolve org.apache.logging.log4j:log4j-core:debian.
>   Required by:
>   project :
>> No cached version of org.apache.logging.log4j:log4j-core:debian 
> available for offline mode.
>
> * Try:
> Run with --debug option to get more log output. Run with --scan to get full 
> insights.
>
> * Exception is:
> org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration$ArtifactResolveException:
>  Could not resolve all files for configuration ':compileClasspath'.
> at 
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.rethrowFailure(DefaultConfiguration.java:918)
> at 
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.access$1600(DefaultConfiguration.java:116)
> at 
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.getFiles(DefaultConfiguration.java:892)
> at 
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getFiles(DefaultConfiguration.java:404)
> ...
> at 
> org.gradle.api.internal.artifacts.ivyservice.ivyresolve.ComponentMetaDataResolveState.resolve(ComponentMetaDataResolveState.java:58)
> at 
> org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainComponentMetaDataResolver.findBestMatch(RepositoryChainComponentMetaDataResolver.java:138)
> at 
> org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainComponentMetaDataResolver.findBestMatch(RepositoryChainComponentMetaDataResolver.java:119)
> at 
> org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainComponentMetaDataResolver.resolveModule(RepositoryChainComponentMetaDataResolver.java:92)
> ... 143 more
>
>
> * Get more help at https://help.gradle.org
>
> BUILD FAILED in 7s
> 1 actionable task: 1 executed
> dh_auto_build: gradle --info --console plain --offline --stacktrace 
> --no-daemon --refresh-dependencies --gradle-user-home .gradle -Duser.home=. 
> -Duser.name=debian -Ddebian.package=igv -Dfile.encoding=UTF-8 --parallel 
> --max-workers=4 jar returned exit code 1
>
>
> in a recent pbuilder chroot.
>
> I would love to test igv, but it seems it does not build reliably. :-(
>
> Kind regards
>
> Andreas.
>
>
> [1] 
> https://salsa.debian.org/med-team/igv/commit/eaa95f1c5d56003c91984f1e2036bbf8bae7fec0
>

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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

Re: Continued build issues with IGV: Could not resolve org.apache.logging.log4j:log4j:debian

[Olivier Sallou]

On 10/16/2018 02:51 PM, Andreas Tille wrote:
> Hi Olivier,
>
> thanks a lot for looking into this.
>
> On Tue, Oct 16, 2018 at 10:45:08AM +0200, Olivier Sallou wrote:
>>
>>> sorry for the private ping, but may be you have an idea how to
>>> build igv?
>> Hi,
>> after lots of fixes, I could get igv build (and had to make a few
>> updates to d/bin/igv too)
>>
>> however, I removed the Java 9 module support for igv itself.. Could not
>> make it build to provide igv as a module, only as a "old" lib/bin
>>
>> could not test due to x11 pb, but it builds and do not complain on
>> missing libs.
>>
>> I pushed all my updates
> I tried to build your latest commit (eaa95f1c [1]) but I get:
>
> ...
> Passing through xalan:serializer:jar:debian
> Passing through commons-logging:commons-logging:jar:debian
> :compileJava FAILED
> :compileJava (Thread[Daemon worker,5,main]) completed. Took 0.64 secs.
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Could not resolve all files for configuration ':compileClasspath'.
>> Could not resolve org.apache.logging.log4j:log4j:debian.
certainly some missing deps I gonna check
>   Required by:
>   project :
>> No cached version of org.apache.logging.log4j:log4j:debian available for 
> offline mode.
>> Could not resolve org.apache.logging.log4j:log4j-api:debian.
>   Required by:
>   project :
>> No cached version of org.apache.logging.log4j:log4j-api:debian available 
> for offline mode.
>> Could not resolve org.apache.logging.log4j:log4j-1.2-api:debian.
>   Required by:
>   project :
>> No cached version of org.apache.logging.log4j:log4j-1.2-api:debian 
> available for offline mode.
>> Could not resolve org.apache.logging.log4j:log4j-core:debian.
>   Required by:
>   project :
>> No cached version of org.apache.logging.log4j:log4j-core:debian 
> available for offline mode.
>
> * Try:
> Run with --debug option to get more log output. Run with --scan to get full 
> insights.
>
> * Exception is:
> org.gradle.api.internal.artifacts.ivyservice.DefaultLenientConfiguration$ArtifactResolveException:
>  Could not resolve all files for configuration ':compileClasspath'.
> at 
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.rethrowFailure(DefaultConfiguration.java:918)
> at 
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.access$1600(DefaultConfiguration.java:116)
> at 
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration$ConfigurationFileCollection.getFiles(DefaultConfiguration.java:892)
> at 
> org.gradle.api.internal.artifacts.configurations.DefaultConfiguration.getFiles(DefaultConfiguration.java:404)
> ...
> at 
> org.gradle.api.internal.artifacts.ivyservice.ivyresolve.ComponentMetaDataResolveState.resolve(ComponentMetaDataResolveState.java:58)
> at 
> org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainComponentMetaDataResolver.findBestMatch(RepositoryChainComponentMetaDataResolver.java:138)
> at 
> org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainComponentMetaDataResolver.findBestMatch(RepositoryChainComponentMetaDataResolver.java:119)
> at 
> org.gradle.api.internal.artifacts.ivyservice.ivyresolve.RepositoryChainComponentMetaDataResolver.resolveModule(RepositoryChainComponentMetaDataResolver.java:92)
> ... 143 more
>
>
> * Get more help at https://help.gradle.org
>
> BUILD FAILED in 7s
> 1 actionable task: 1 executed
> dh_auto_build: gradle --info --console plain --offline --stacktrace 
> --no-daemon --refresh-dependencies --gradle-user-home .gradle -Duser.home=. 
> -Duser.name=debian -Ddebian.package=igv -Dfile.encoding=UTF-8 --parallel 
> --max-workers=4 jar returned exit code 1
>
>
> in a recent pbuilder chroot.
>
> I would love to test igv, but it seems it does not build reliably. :-(
>
> Kind regards
>
> Andreas.
>
>
> [1] 
> https://salsa.debian.org/med-team/igv/commit/eaa95f1c5d56003c91984f1e2036bbf8bae7fec0
>

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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

Re: Suspect bug in javahelper (Was: Problems building latest version of htsjdk)

[Olivier Sallou]

On 09/18/2018 03:52 PM, Andreas Tille wrote:
> Hi Olivier,
>
> On Tue, Sep 18, 2018 at 03:16:07PM +0200, Andreas Tille wrote:
>>  
>> I now know where to look for other ftp/http access attempts (there are way
>> more.)
> I've now worked down all remote access tests in htsjdk and thought I would
> be through all hassle but now I'm facing the following:
>
>
>debian/rules override_jh_installlibs
> make[1]: Entering directory '/build/htsjdk-2.16.1+dfsg'
> jh_installlibs --version-strip='[+]dfsg[.0-9]*'
> jh_installlibs: copy(build/libs/htsjdk-*.jar, 
> debian/libhtsjdk-java/usr/share/java/htsjdk-*-2.16.1.jar): No such file or 
> directory
> install -d debian/libhtsjdk-java/usr/share/java
> install -p -m0644 build/libs/htsjdk-\*.jar 
> debian/libhtsjdk-java/usr/share/java/htsjdk-\*-2.16.1.jar
> make[1]: *** [debian/rules:22: override_jh_installlibs] Error 2
>
>
> The overide in d/rules is:
>
> override_jh_installlibs:
>   jh_installlibs --version-strip='[+]dfsg[.0-9]*'
well, when I built htsjdk, it did with the same override, I faced no issue.
I just pulled your updates and tried to build with gbp, again it works
for me.
So could be related to pbuilder build.
>
> and
>
> $ cat debian/*jlibs
> build/libs/htsjdk-*.jar
>
>
> Inside the pbuilder chroot it looks like this:
>
> /build/htsjdk-2.16.1+dfsg# ls build/libs/htsjdk-*.jar
> build/libs/htsjdk-2.16.1.jar
> /build/htsjdk-2.16.1+dfsg# ls debian/libhtsjdk-java/usr/share/java/
> /build/htsjdk-2.16.1+dfsg# cp -a build/libs/htsjdk-\*.jar 
> debian/libhtsjdk-java/usr/share/java/htsjdk-\*-2.16.1.jar
> cp: cannot stat 'build/libs/htsjdk-*.jar': No such file or directory
>
>
> I tried to get rid of the override in d/rules but the result is the same:
>
>
>jh_installlibs -O--buildsystem=gradle
> jh_installlibs: copy(build/libs/htsjdk-*.jar, 
> debian/libhtsjdk-java/usr/share/java/htsjdk-*-2.16.1+dfsg.jar): No such file 
> or directory
> install -d debian/libhtsjdk-java/usr/share/java
> install -p -m0644 build/libs/htsjdk-\*.jar 
> debian/libhtsjdk-java/usr/share/java/htsjdk-\*-2.16.1\+dfsg.jar
> make: *** [debian/rules:12: binary] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 
> 2
>
>
> I could work around this by simply overriding jh_installlibs by a copy
> statement but I'd love to avoid this kind of hacks.
>
> Any idea what might be wrong here?
>
> Kind regards
>
>   Andreas.
>

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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

Re: How to upgrade code from batik 1.8 to 1.10 which is lacking XMLConstants [Was: cgview.jar does not find class from batik-util]

[Olivier Sallou]

On 08/22/2018 09:38 AM, Andreas Tille wrote:
> Hi Olivier,
>
> On Wed, Aug 22, 2018 at 09:18:12AM +0200, Olivier Sallou wrote:
>> looking at batik-util.jar, I see no org/apache/batik/util/XMLConstants
>> inside
>>
>>
>> I can see it in batik  source code version 1.8 [0], but in 1.10 (debian
>> version)  [1], XMLConstants is not here
>>
>>
>> [0]
>> https://github.com/apache/batik/tree/batik-1_8/sources/org/apache/batik/util
>>
>> [1]
>> https://github.com/apache/batik/tree/trunk/batik-util/src/main/java/org/apache/batik/util
> Thanks for this analysis.
>  
>> so cgview is not up-to-date with current batik version. package needs to
>> be updated to batik 1.10 (if possible..)
> CGView was not updated since 2010 but I keep upstream Paul Stothard in
> this conversation.  I'm pretty sure that he would be happy to have some
> patch for the issue.  However, as you know, usually JAR's are included
> into the downloadable archive and thus the issue we are facing in Debian
> when using system libraries exclusively does not exist for the general
> user and thus the motivation at upstream site might be low to migrate to
> a more recent batik version.
>  
> Since I personally have no idea how to replace XMLConstants when using
> batik 1.10 (and I also failed with a web search for a migration path) I'd
> be really happy about a patch.

will have a look, however is strange I do not find any XMLConstants
reference in cgview code

>  
> Kind regards
>
>   Andreas.
>
>  
>> On 08/22/2018 07:53 AM, Andreas Tille wrote:
>>> I checked package cgview[1] since it is needed for some other
>>> package (to be packaged).  When I try
>>>
>>> $ /usr/bin/cgview
>>> Error: Unable to initialize main class ca.ualberta.stothard.cgview.CgviewIO
>>> Caused by: java.lang.NoClassDefFoundError: 
>>> org/apache/batik/util/XMLConstants
>>>
>>>
>>> The class that is not found is in /usr/share/java/batik-util.jar which
>>> belongs to package libbatik-java which is in the list of Depends.  The
>>> JAR batik-util.jar is mentioned in debian/manifest Class-Path field.  I
>>> wonder why that class is not found anyway.
>>>
>>> Any help is appreciated
>>>
>>>   Andreas.
>>>
>>>
>>> [1] https://salsa.debian.org/med-team/cgview
>>>

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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

Re: Probable new default version of Java issue: Bug#906371: jmodeltest: FTBFS in buster/sid

[Olivier Sallou]

;> [javac] 
>> /<>/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/utilities/MyTableCellRenderer.java:61:
>>  warning: [deprecation] Integer(int) in Integer has been deprecated
>> [javac]  whichValue = new 
>> Integer(ModelTest.getMinDT().getId());
>> [javac]   ^
>> [javac] 
>> /<>/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/utilities/MyTableCellRenderer.java:63:
>>  warning: [deprecation] Integer(int) in Integer has been deprecated
>> [javac]  whichValue = new Integer(0);
>> [javac]   ^
>> [javac] 
>> /<>/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/gui/Frame_Progress.java:60:
>>  warning: [deprecation] Observer in java.util has been deprecated
>> [javac] public class Frame_Progress extends JModelTestFrame implements 
>> Observer,
>> [javac]^
>> [javac] 
>> /<>/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/gui/Frame_Progress.java:368:
>>  warning: [deprecation] Observable in java.util has been deprecated
>> [javac]  public synchronized void update(Observable o, Object arg) {
>> [javac]  ^
>> [javac] 
>> /<>/jmodeltest-2.1.10+dfsg/src/main/java/es/uvigo/darwin/jmodeltest/io/HtmlReporter.java:111:
>>  warning: [deprecation] Integer(int) in Integer has been deprecated
>> [javac]  datamodel.put("isTopologiesSummary", summary!=null ? 
>> new Integer(1) : new Integer(0));
>> [javac]   ^
>> [javac] Note: Some input files additionally use or override a deprecated 
>> API.
>> [javac] 8 errors
>> [javac] 100 warnings
>>
>> BUILD FAILED
>> /<>/jmodeltest-2.1.10+dfsg/build.xml:37: Compile failed; see the 
>> compiler error output for details.
>>
>> Total time: 3 seconds
>> dh_auto_build: ant -Duser.name debian returned exit code 1
>> make[1]: *** [debian/rules:14: override_dh_auto_build] Error 2
>> make[1]: Leaving directory '/<>/jmodeltest-2.1.10+dfsg'
>> make: *** [debian/rules:11: build-indep] Error 2
>> dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
>> status 2
>> 
>>
>> The build was made with "dpkg-buildpackage -A" in my autobuilder.
>> Most probably, it also fails here in reproducible builds:
>>
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jmodeltest.html
>>
>> where you can get a full build log if you need it.
>>
>> If this is really a bug in one of the build-depends, please use reassign and 
>> affects,
>> so that this is still visible in the BTS web page for this package.
>>
>> Thanks.
>>
>> ___
>> Debian-med-packaging mailing list
>> debian-med-packag...@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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

Re: Help needed for change of build system to gradle of package libsis-jhdf5-java

[olivier sallou]

Le dim. 19 août 2018 à 16:17, Bernd Rinn  a écrit :

> On 08/19/2018 04:02 PM, olivier sallou wrote:
> >
> >
> > Le dim. 19 août 2018 à 15:23, Bernd Rinn  > <mailto:br...@ethz.ch>> a écrit :
> >
> > Hi Andreas,
> >
> > I have no idea why the classes are missing for you as they are all
> > present in our ivy-repository which we use for dependency resolution.
> > Maybe there is an issue with your gradle build environment?
> >
> >
> > In debian, all deps must be availlable as debian packages, they are not
> > downloaded from remote repos.
> > So i think 'problem' is those dependencies are not packaged in debian
> >  They should be packaged first, then added as package build dependencies.
>
> The old build procedure involved Ivy with a publicly accessible ivy
> repository, the new build procedure is self-contained. Putting this into
> Debian packages in a form compliant with Debian policies is your task at
> Debian.
>
Agree :-) just explaining what the issue is.

Olivier

>
> Bernd
>
> > Anyway, I have now simplified the build process by removing automatic
> > dependency resolution via ivy altogether. Can you please check
> whether
> > the build works for you now when you use the build procedure on HEAD?
> >
> > All the best,
> > Bernd
> >
> > On 08/16/2018 06:46 AM, Andreas Tille wrote:
> > > Hi Bernd,
> > >
> > > could you give some hints about the missing classes?
> > >
> > > On Tue, Aug 14, 2018 at 12:23:22PM +0200, olivier sallou wrote:
> > >> Le mar. 14 août 2018 à 11:32, Andreas Tille  > <mailto:andr...@an3as.eu>> a écrit :
> > >>
> > >>> A problem occurred evaluating root project 'libsis-jhdf5-java'.
> > >>>> Could not resolve all dependencies for configuration ':runtime'.
> > >>>> Could not resolve cisd:cisd-args4j:+.
> > >>>  Required by:
> > >>>  project :
> > >>>   > No cached version listing for cisd:cisd-args4j:+
> > available for
> > >>> offline mode.
> > >>>> Could not resolve cisd:cisd-base:+.
> > >>>  Required by:
> > >>>  project :
> > >>>   > No cached version listing for cisd:cisd-base:+ available
> for
> > >>> offline mode.
> > >>>> Could not resolve rinn:restrictions:+.
> > >>>  Required by:
> > >>>  project :
> > >>>   > No cached version listing for rinn:restrictions:+
> > available for
> > >>> offline mode.
> > >>>
> > >>>
> > >> I do not see in build deps things related to:
> > >>cisd:cisd-args4, cisd:cisd-base, rinn:restrictions
> > >
> > > I have no idea what these are. :-(
> > >
> > > Kind regards
> > >
> > >   Andreas.
> > >
> > >>> [1] https://salsa.debian.org/med-team/libsis-jhdf5-java
>
>

Re: Help needed for change of build system to gradle of package libsis-jhdf5-java

[olivier sallou]

Le dim. 19 août 2018 à 15:23, Bernd Rinn  a écrit :

> Hi Andreas,
>
> I have no idea why the classes are missing for you as they are all
> present in our ivy-repository which we use for dependency resolution.
> Maybe there is an issue with your gradle build environment?
>

In debian, all deps must be availlable as debian packages, they are not
downloaded from remote repos.
So i think 'problem' is those dependencies are not packaged in debian
 They should be packaged first, then added as package build dependencies.

Olivier




> Anyway, I have now simplified the build process by removing automatic
> dependency resolution via ivy altogether. Can you please check whether
> the build works for you now when you use the build procedure on HEAD?
>
> All the best,
> Bernd
>
> On 08/16/2018 06:46 AM, Andreas Tille wrote:
> > Hi Bernd,
> >
> > could you give some hints about the missing classes?
> >
> > On Tue, Aug 14, 2018 at 12:23:22PM +0200, olivier sallou wrote:
> >> Le mar. 14 août 2018 à 11:32, Andreas Tille  a écrit
> :
> >>
> >>> A problem occurred evaluating root project 'libsis-jhdf5-java'.
> >>>> Could not resolve all dependencies for configuration ':runtime'.
> >>>> Could not resolve cisd:cisd-args4j:+.
> >>>  Required by:
> >>>  project :
> >>>   > No cached version listing for cisd:cisd-args4j:+ available for
> >>> offline mode.
> >>>> Could not resolve cisd:cisd-base:+.
> >>>  Required by:
> >>>  project :
> >>>   > No cached version listing for cisd:cisd-base:+ available for
> >>> offline mode.
> >>>> Could not resolve rinn:restrictions:+.
> >>>  Required by:
> >>>  project :
> >>>   > No cached version listing for rinn:restrictions:+ available for
> >>> offline mode.
> >>>
> >>>
> >> I do not see in build deps things related to:
> >>cisd:cisd-args4, cisd:cisd-base, rinn:restrictions
> >
> > I have no idea what these are. :-(
> >
> > Kind regards
> >
> >   Andreas.
> >
> >>> [1] https://salsa.debian.org/med-team/libsis-jhdf5-java
>
>

Re: Help needed for change of build system to gradle of package libsis-jhdf5-java

[olivier sallou]

Le mar. 14 août 2018 à 11:32, Andreas Tille  a écrit :

> Hi,
>
> upstream of libsis-jhdf5-java[1] has switched to gradle in its new
> version that is compatible with HDF5 1.10.  I tried to adapt debian/rules
> from previous manual build to buildsystem=gradle but got:
>
> ...
> Parallel execution is an incubating feature.
> Evaluating root project 'libsis-jhdf5-java' using build file
> '/build/libsis-jhdf5-java-18.08~pre+git20180805.da55947+dfsg/build.gradle'.
> Compiling build file
> '/build/libsis-jhdf5-java-18.08~pre+git20180805.da55947+dfsg/build.gradle'
> using SubsetScriptTransformer.
> Compiling build file
> '/build/libsis-jhdf5-java-18.08~pre+git20180805.da55947+dfsg/build.gradle'
> using BuildScriptTransformer.
> Compiling script
> '/build/libsis-jhdf5-java-18.08~pre+git20180805.da55947+dfsg/javaproject.gradle'
> using SubsetScriptTransformer.
> Compiling script
> '/build/libsis-jhdf5-java-18.08~pre+git20180805.da55947+dfsg/repository.gradle'
> using SubsetScriptTransformer.
> Compiling script
> '/build/libsis-jhdf5-java-18.08~pre+git20180805.da55947+dfsg/repository.gradle'
> using BuildScriptTransformer.
> Creating new cache for metadata-2.23/module-versions, path
> /build/libsis-jhdf5-java-18.08~pre+git20180805.da55947+dfsg/.gradle/caches/modules-2/metadata-2.23/module-versions.bin,
> access org.gradle.cache.internal.DefaultCacheAccess@350dec85
>
> FAILURE: Build failed with an exception.
>
> * Where:
> Build file
> '/build/libsis-jhdf5-java-18.08~pre+git20180805.da55947+dfsg/build.gradle'
> line: 1
>
> * What went wrong:
> A problem occurred evaluating root project 'libsis-jhdf5-java'.
> > Could not resolve all dependencies for configuration 'classpath'.
>> Could not resolve cisd:cisd-ant-tasks:+.
>  Required by:
>  unspecified:unspecified:unspecified
>   > No cached version listing for cisd:cisd-ant-tasks:+ available for
> offline mode.
>
> * Try:
> Run with --debug option to get more log output.
>
> * Exception is:
> org.gradle.api.GradleScriptException: A problem occurred evaluating root
> project 'libsis-jhdf5-java'.
> at
> org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:92)
> ...
> at
> org.gradle.api.internal.artifacts.ivyservice.ivyresolve.DynamicVersionResolver.resolve(DynamicVersionResolver.java:67)
> ... 104 more
>
>
> BUILD FAILED
>
> Total time: 5.829 secs
> Received result Failure[value=org.gradle.initialization.ReportedException:
> org.gradle.internal.exceptions.LocationAwareException: Build file
> '/build/libsis-jhdf5-java-18.08~pre+git20180805.da55947+dfsg/build.
>  gradle' line: 1
> A problem occurred evaluating root project 'libsis-jhdf5-java'.] from
> daemon DaemonInfo{pid=26176, address=[01070135-56e1-461a-92ea-35d94d1e1ee5
> port:41021, addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]],
> state=Busy, lastBusy=1534230750655,
> context=DefaultDaemonContext[uid=37bdd18f-143d-4071-ab24-f17f8d67fb44,javaHome=/usr/lib/jvm/java-10-openjdk-amd64,daemonRegistryDir=/build/libsis-jhdf5-java-18.08~pre+
>
> git20180805.da55947+dfsg/.gradle/daemon,pid=26176,idleTimeout=12,daemonOpts=-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]}
> (build   should be done).
>
>
>
> Since I had no idea how to fix this I simply tried to remove this
> dependency definition (ant is installed as Build-Dependency anyway) and
> thus I tried the following quilt patch:
>
>
> $ git diff
> diff --git a/debian/patches/fix_build_dir.patch
> b/debian/patches/fix_build_dir.patch
> index 1d652b2..163553c 100644
> --- a/debian/patches/fix_build_dir.patch
> +++ b/debian/patches/fix_build_dir.patch
> @@ -4,7 +4,7 @@ Description: Do not make wrong assumptions about directory
> name
>
>  --- a/javaproject.gradle
>  +++ b/javaproject.gradle
> -@@ -50,7 +50,7 @@ sourceSets {
> +@@ -50,13 +50,9 @@ sourceSets {
>   buildDir = 'targets/gradle'
>
>   buildscript {
> @@ -12,4 +12,10 @@ Description: Do not make wrong assumptions about
> directory name
>  +apply from: 'repository.gradle'
>
>   repositories repositoryConfig
> -
> +-
> +-dependencies {
> +-classpath 'cisd:cisd-ant-tasks:+'
> +-}
> + }
> +
> + repositories repositoryConfig
>
>
> This leads to:
>
>
> ...
> FAILURE: Build failed with an exception.
>
> * Where:
> Build file
> '/build/libsis-jhdf5-java-18.08~pre+git20180805.da55947+dfsg/build.gradle'
> line: 40
>
> * What went wrong:
> A problem occurred evaluating root project 'libsis-jhdf5-java'.
> > Could not resolve all dependencies for configuration ':runtime'.
>> Could not resolve cisd:cisd-args4j:+.
>  Required by:
>  project :
>   > No cached version listing for cisd:cisd-args4j:+ available for
> offline mode.
>> Could not resolve cisd:cisd-base:+.
>  Required by:
>  project :
>   > No cached version listing for cisd:cisd-base:+ available for
> offline mode.
>> 

Re: Help needed for libapfloat-java

[Olivier Sallou]

- Andreas Tille <andr...@an3as.eu> a écrit :
> On Wed, May 16, 2018 at 05:21:44PM +0200, Olivier Sallou wrote:
> > 
> > I updated repo with a few fixes, but lib needs additional external
> > dependencies not in Debian. I added info to d/changelog
> > 
> > missing dependency com.aparpi.aparapi:1.3.4 (for apfloat-aparapi) and
> > org.jscience.jscience:4.3.1 (for apfloat-jscience)
> 
> Thanks a lot!
>  
> > com.aparpi has however some kind of restrictive license [0]
> 
> You mean the last paragraph saying:
> 
> 
> If you use the software (in whole or in part), you shall adhere to all 
> applicable U.S., European, and other export
> laws, including but not limited to the U.S. Export Administration Regulations 
> ("EAR"), (15 C.F.R. Sections 730 through
> 774), and E.U. Council Regulation (EC) No 1334/2000 of 22 June 2000.  
> Further, pursuant to Section 740.6 of the EAR,
> you hereby certify that, except pursuant to a license granted by the United 
> States Department of Commerce Bureau of 
> Industry and Security or as otherwise permitted pursuant to a License 
> Exception under the U.S. Export Administration 
> Regulations ("EAR"), you will not (1) export, re-export or release to a 
> national of a country in Country Groups D:1,
> E:1 or E:2 any restricted technology, software, or source code you receive 
> hereunder, or (2) export to Country Groups
> D:1, E:1 or E:2 the direct product of such technology or software, if such 
> foreign produced direct product is subject
> to national security controls as identified on the Commerce Control List 
> (currently found in Supplement 1 to Part 774
> of EAR).  For the most current Country Group listings, or for additional 
> information about the EAR or your obligations
> under those regulations, please refer to the U.S. Bureau of Industry and 
> Security’s website at http://www.bis.doc.gov/.
> 
> 
> I wonder whether we start with a packaging attempt anyway and if
> ftpmaster considers this a blocker we could try to negotiate with
> the authors about this part of the license.


For me it is blocking with the 'you will not (1) export, re-export or release ' 
part...

We may ask upstream, but seems wa released by a company, and it may be forced 
to follow some us regulations


Olivier


> 
> Kind regards
> 
>  Andreas.
> 
>  
> > [0] https://github.com/aparapi/aparapi/blob/master/LICENSE.TXT
> 
> -- 
> http://fam-tille.de
> 

Re: Help needed for libapfloat-java

[Olivier Sallou]

On 05/16/2018 05:04 PM, Olivier Sallou wrote:
>
> On 05/16/2018 03:34 PM, Andreas Tille wrote:
>> On Wed, May 16, 2018 at 02:40:31PM +0200, Emmanuel Bourg wrote:
>>> Le 16/05/2018 à 14:30, Andreas Tille a écrit :
>>>
>>>> but my naive attempt to fire up mh_make and expect that it results
>>>> in something that builds was again to naive to work.
> you need following build depends:
>
> libmaven-antrun-plugin-java
> libmaven-shade-plugin-java
> libbuild-helper-maven-plugin-java
> junit
>
> I updated d/control in repo
>
> compilation starts with this.
> It then ends up with errors due to dependencies on self generated jar.

I updated repo with a few fixes, but lib needs additional external
dependencies not in Debian. I added info to d/changelog

missing dependency com.aparpi.aparapi:1.3.4 (for apfloat-aparapi) and
org.jscience.jscience:4.3.1 (for apfloat-jscience)

com.aparpi has however some kind of restrictive license [0]

[0] https://github.com/aparapi/aparapi/blob/master/LICENSE.TXT

Olivier
>>> What error did you get?
>> No error but javac is not fired up at all and thus no JARs are created.
>>
>> Kind regards
>>
>>  Andreas. 
>>

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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

Re: Help needed for libapfloat-java

[Olivier Sallou]

On 05/16/2018 03:34 PM, Andreas Tille wrote:
> On Wed, May 16, 2018 at 02:40:31PM +0200, Emmanuel Bourg wrote:
>> Le 16/05/2018 à 14:30, Andreas Tille a écrit :
>>
>>> but my naive attempt to fire up mh_make and expect that it results
>>> in something that builds was again to naive to work.

you need following build depends:

libmaven-antrun-plugin-java
libmaven-shade-plugin-java
libbuild-helper-maven-plugin-java
junit

I updated d/control in repo

compilation starts with this.
It then ends up with errors due to dependencies on self generated jar.
>> What error did you get?
> No error but javac is not fired up at all and thus no JARs are created.
>
> Kind regards
>
>  Andreas. 
>

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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

Re: request for help: jhove

[Olivier Sallou]

On 05/13/2018 05:08 PM, Jeff Breidenbach wrote:
> I've tried and can't figure out how to make this package either build
> at the current release, or update to latest release. This is one last 
> desperate call for help.
looking at logs, you only need to patch to remove non ascii chars at
specified locations.

where are hosted package source? salsa, forge ? which team?

Olivier

>
> >jhove 1.6+dfsg-1 is marked for autoremoval from testing on 2018-05-14
> >
> >It is affected by these RC bugs:
> >895761: jhove: FTBFS with java 9
>

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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

Re: java9 javadoc errors (package htsjdk debianmed)

[olivier sallou]

Le lun. 16 avr. 2018 à 18:05, olivier sallou <osal...@debian.org> a écrit :

> Hi,
>
> I face several javadoc errors (ending with NullPointerException) with
> openjdk 9 while updating package htsjdk.
>
> I saw on internet several bugs related to javadoc.
>
> Error ends with :
>
> javadoc: error - An exception occurred while building a component:
> TagInfo
>  (java.lang.NullPointerException)
>
> If I delete impacted files from doc, I go further but many files are
> impacted.
>
> Anyone faced and could solve this?
> It used to work on JDK8.
>
> Example impacted "doc":
>
> /**
>  * Calls close() on all elements of objs that implement
> Closeable
>  *
>  * @param objs   A list of potentially closeable objects
>  *
>  * NOTE: This method must take a List, not
> List, otherwise the overload above will be selected
>  * if the argument is not exactly List.
>  */
>
> Removing the last 2 lines part works.
>

It also occured on other files after a warning (not error):

/opt/debian/build-area/htsjdk-2.14.3+dfsg/src/main/java/htsjdk/samtools/util/BlockGunzipper.java:104:
warning - Parameter "compressedBlock" is documented more than once.


Removing duplicate declaration works. But javadoc should not fail on a
warning... (with an exception).

I am using opensjdk-9-jdk 9.0.4+12-4




>
> Last option would be to remove javadoc package or patch all files... :-(
>
>
> Olivier
>

java9 javadoc errors (package htsjdk debianmed)

[olivier sallou]

Hi,

I face several javadoc errors (ending with NullPointerException) with
openjdk 9 while updating package htsjdk.

I saw on internet several bugs related to javadoc.

Error ends with :

javadoc: error - An exception occurred while building a component:
TagInfo
 (java.lang.NullPointerException)

If I delete impacted files from doc, I go further but many files are
impacted.

Anyone faced and could solve this?
It used to work on JDK8.

Example impacted "doc":

/**
 * Calls close() on all elements of objs that implement
Closeable
 *
 * @param objs   A list of potentially closeable objects
 *
 * NOTE: This method must take a List, not
List, otherwise the overload above will be selected
 * if the argument is not exactly List.
 */

Removing the last 2 lines part works.

Last option would be to remove javadoc package or patch all files... :-(

Olivier

Re: Bug#895765: igv: FTBFS with java 9

[Olivier Sallou]

On 04/16/2018 04:38 PM, Andreas Tille wrote:
> Hi Olivier,
>
> could you provide a patch assumed we'll stick to Java 9 and higher?

I tried to add module, but javafx module is not found on system.
In debian package, I found only openjfx8, no port available for java9 ?
There is a bug [0] requesting version for jdk9 but it seems it is not
yet available

javafx is used for user interface, don't think we can remove it


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850921
>
> (Could you also have a look into artemis, htsjdk and picard-tools
> if your time permits?)
>
> Kind regards
>
>   Andreas.
>
> On Mon, Apr 16, 2018 at 10:17:57AM +0200, Olivier Sallou wrote:
>>
>> On 04/16/2018 09:32 AM, Bas Couwenberg wrote:
>>> On 2018-04-16 08:18, Andreas Tille wrote:
>>>> it seems something has changed with openfx since the errors below are
>>>> all mentioning something like "import javafx. ...".  Do you have any
>>>> hint how this can be fixed?
>>> There is no OpenJFX for OpenJDK 9, see:
>>>
>>>  https://lists.debian.org/debian-java/2018/04/msg3.html
>> indeed Java 9 removed some packages from *core* java and were moved to
>> additional modules to add at compilation/runtime.
>> Problem is this is not transparent/compatible with java <= 8.
>> So, to support java 9 AND below, you need specific scripts that detect
>> java version and act accordingly. This is not really cool to do and
>> maintain.
>>
>> As proposed, either javafx can be removed from code, either we shoud
>> stick to Java 9 and superior and add the javafx module.
>> there is an example in biojava4 for a build.xml:
>>
>>
>>        
>>           
>>           
>>   .
>>
>> this example used java.se.ee module.
>>
>> For javafx, there are several modules [0]:
>>
>> * Base APIs for JavaFX UI Toolkit — javafx.base
>> * JavaFX APIs for UI Controls — javafx.controls
>> * JavaFX APIs for FXML — javafx.fxml
>> * JavaFX APIs for various Graphics Tools— javafx.graphics
>> * JavaFX APIs for Multimedia — javafx.media
>> * JavaFX APIs for Swing-JavaFX Interoperability — javafx.swing
>> * JavaFX APIs for WebView Functionality — javafx.web
>>
>>
>> To add multiple modules, one need to separate them with comma.
>>
>> [0]
>> https://medium.com/@afinlay/whats-new-in-java-fx-java-9-updates-a90dd3d4dbba
>>
>>
>>
>>> If the package works without JavaFX you should consider disabling that
>>> for the time being.
>>>
>>> You can also explicitly build with OpenJDK 8, but that will just get
>>> you a different RC bug because openjdk-8 will not be in buster.
>>>
>>> Kind Regards,
>>>
>>> Bas
>>>
>> -- 
>> Olivier Sallou
>> Univ Rennes, Inria, CNRS, IRISA
>> Irisa, Campus de Beaulieu
>> F-35042 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
>>
>>
>>

-- 
Olivier Sallou
Univ Rennes, Inria, CNRS, IRISA
Irisa, Campus de Beaulieu
F-35042 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

Move of gradle from expiremental to sid

[olivier sallou]

Hi,
is there a plan to move soon Gradle from expiremental to sid ?
Experimental version fixes some issues related to tests that would be
useful for some of our packages (debianmed)

Thanks

Olivier

Re: Help needed: gradle + testng

[Olivier Sallou]

On 10/31/2017 05:47 PM, Markus Koschany wrote:
> I'm subscribed to debian-java. No need to CC me.
sorry, was a reply all instead of reply...
>
> Am 31.10.2017 um 17:44 schrieb Olivier Sallou:
>> the version I downloaded/tested with is gradle 4.3.
>> Do you want I try with a an older version ? (3.4.1, 3.5, ??)
> Updating Gradle can be a very painful experience. I assume updating to
> 4.3 will be complicated at best hence I'd prefer to take smaller steps.
> You could try with 3.4 again. According to some upstream bug reports
> either this version or even 3.3 should already work for you.
testing with 3.4 which launches the tests, no error.

What I did:

gbp buildpackage 

after failure, go to build-area for package and execute manually the
command normally executed by debhelper:

gradle --debug --console plain  --stacktrace --no-daemon
--refresh-dependencies --gradle-user-home .gradle -Duser.home=.
-Dusere=debian -Ddebian.package=picard-tools -Dfile.encoding=UTF-8
--parallel --max-workers=4 test

=> failure as during gbp buildpackage

install gradle 3.4 and add to path

copy in .m2 dependencies from /usr/share/java/maven-repo
reexecute command using "new" gradle

gradle --debug --console plain  --stacktrace --no-daemon
--refresh-dependencies --gradle-user-home .gradle -Duser.home=.
-Dusere=debian -Ddebian.package=picard-tools -Dfile.encoding=UTF-8
--parallel --max-workers=4 test

=> success, tests are executed


so v3.4 should be ok
maybe going to 3.4.1 would be nicer (just some fixed issues on 3.4,
should be no different)

Olivier

>

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




signature.asc
Description: OpenPGP digital signature

Re: Help needed: gradle + testng

[Olivier Sallou]

On 10/31/2017 05:15 PM, Olivier Sallou wrote:
>
> On 10/31/2017 04:53 PM, Markus Koschany wrote:
>> Am 31.10.2017 um 15:40 schrieb olivier sallou:
>> [...]
>>
>>> any idea of what is wrong?
>> Maybe it's a race condition. Have you tried building with --no-parallel
> I tried debhelper directly, removing some arguements, to test manually,
> but the same
>
> Tested:
> gradle --debug --offline --stacktrace --no-daemon --refresh-dependencies
> --gradle-user-home .gradle -Duser.home=. -Duser.name=debian
> -Ddebian.package=picard-tools -Dfile.encoding=UTF-8  test
>
> vs original:
>
> gradle --info --console plain --offline --stacktrace --no-daemon
> --refresh-dependencies --gradle-user-home .gradle -Duser.home=.
> -Duser.name=debian -Ddebian.package=picard-tools -Dfile.encoding=UTF-8
> --parallel --max-workers=4 test
>
> same result.
 if I download gradle, and recompile/test using the new gradle, it works
fine (but keeping everything offline and copying
/usr/share/java|maven-repo related stuff manually to .m2 directory)

so either this is a debian gradle issue, either it is gradle helper issue.
>> in case you use compat level 10? It might also be a bug in Gradle itself
>> according to some information on the web.
>>
>> Regards,
>>
>> Markus
>>

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




signature.asc
Description: OpenPGP digital signature

Re: Help needed: gradle + testng

[Olivier Sallou]

On 10/31/2017 04:53 PM, Markus Koschany wrote:
> Am 31.10.2017 um 15:40 schrieb olivier sallou:
> [...]
>
>> any idea of what is wrong?
> Maybe it's a race condition. Have you tried building with --no-parallel
I tried debhelper directly, removing some arguements, to test manually,
but the same

Tested:
gradle --debug --offline --stacktrace --no-daemon --refresh-dependencies
--gradle-user-home .gradle -Duser.home=. -Duser.name=debian
-Ddebian.package=picard-tools -Dfile.encoding=UTF-8  test

vs original:

gradle --info --console plain --offline --stacktrace --no-daemon
--refresh-dependencies --gradle-user-home .gradle -Duser.home=.
-Duser.name=debian -Ddebian.package=picard-tools -Dfile.encoding=UTF-8
--parallel --max-workers=4 test

same result.
> in case you use compat level 10? It might also be a bug in Gradle itself
> according to some information on the web.
>
> Regards,
>
> Markus
>

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




signature.asc
Description: OpenPGP digital signature

Re: Help needed: gradle + testng

[Olivier Sallou]

On 10/31/2017 04:43 PM, Emmanuel Bourg wrote:
> Le 31/10/2017 à 15:40, olivier sallou a écrit :
>
>> any idea of what is wrong?
> I've seen this error too with another package and I had to disable the
> tests. No idea what is causing this.
well, this is what I plan to do in a first step.

It occurs in several gradle+testng packages. Do not know if debian
gradle /  testng / helper issue  .
> Emmanuel Bourg
>

-- 


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

Help needed: gradle + testng

[olivier sallou]

Hi,

when using testng with gradle on some packages (get same issue on multiple
projects),

test step fails with error:


Executing task ':test' (up-to-date check took 0.0 secs) due to:

  Task.upToDateWhen is false.

Cannot nest operations in the same thread. Each nested operation must run
in its own thread.

java.lang.UnsupportedOperationException: Cannot nest operations in the same
thread. Each nested operation must run in its own thread.

at
org.gradle.internal.operations.DefaultBuildOperationWorkerRegistry.doStartOperation(DefaultBuildOperationWorkerRegistry.java:65)

and this message is repeat a large number of times (per test?)

any idea of what is wrong?

I tried with debian testng jar file and also tried to get a more recent one
(just in case), but same issue.

Thanks
Olivier

scalatest + graddle

[Olivier Sallou]

Hi,

one of our packages (htsjdk) introduced scalatest dependency with
graddle build file to make their tests.

Anyone working on packaging it (did not find it in Debian) ? Or having
an easy way to patch the build file to use *regular* graddle testing (I
never used graddle) instead of scaltest.

upstream makes use of tags to filter some tests.


Thanks


Olivier





On Wed, Oct 11, 2017 at 12:05:28PM +0200, Olivier Sallou wrote:
> 
>  Failure seems related to not finding the *tags* extension to Test.
>  Seems introduced by scalatest , one of the plugins loaded by graddle.
>  scalatest does not seem to be available in debian.
>  the *tag* element seems to be used to filter tests.
>  
>  One temp option would be to disable tests, at least to check compilation
>  etc... this scalatest has been introduced in this release, was not present
>  in previous one.

Htsjdk seems to be a moving target regarding changes in need of new
dependencies.  I'd say if we can "test" by getting its rdependencies and
thier tests working disabling buildtime tests as long as scalatest might
be packaged (did you contacted debian-java list about this) might be an
acceptable solution in the short run.

Kind regards

  Andreas.

-- 
http://fam-tille.de

___
Debian-med-packaging mailing list
debian-med-packag...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging

Help needed with jdk9 and javac add-modules

[olivier sallou]

Hi,
with JDK 9 transition, the biojava4-live package fails to compile. It is
linked to the javax.xml.bind module.
To fix this I know I need to add to javac commands the java.se.ee module.
However, as an Ant build.xlm file is used for compilation etc. , I do not
find how to add this module in javac xml description.
Without this, I have NoClassDefFoundErrors on javax.xml.bind.

My current definition is:



Anyone already did this ?

Thanks

Olivier

Re: Help needed for tn-seqexplorer Java package

[Olivier Sallou]

On 05/09/2017 01:20 PM, Andreas Tille wrote:
> Hi Olivier,
>
> On Tue, May 09, 2017 at 11:46:51AM +0200, Olivier Sallou wrote:
>>> $ tn-seqexplorer 
>>> Exception in thread "main" java.lang.NullPointerException
>>> at sun.awt.SunToolkit.getImageFromHash(SunToolkit.java:725)
>>> at sun.awt.SunToolkit.getImage(SunToolkit.java:759)
>>> at GUI.LegalDisclaimer.(LegalDisclaimer.java:24)
>>> at essgenes.Main.main(Main.java:43)
>> It seems it does not find in jar file the file
>> /resources/legaldisplaimer.png
>>
>> A resource file has not been included in the jar file. You can check
>> with jar -tf yourjarfile to see if it is present (but I don't think so
>> as I see no resource not png file in src)
>> As it is an icon, you could simply comment line 24 of
>> src/GUI/LegalDisplaimer.java, line 24 to fix the issue
> Hmmm, I think I've got it wrong.  The needed files are now inside the
> upstream tarball (+Git archive) and I installed the files into the
> package and fixed the explicite PATH.  However, you said the resources
> need to be inside the JAR and I have no idea how to approach this by
> using jh_build.
>
> Any idea how to include the resources into the JAR instead just into
> the file system?
I do not know how to include resources in jar with jh_build, never did
it before, but Java team should be able to answer this
>
> Kind regards
>
>  Andreas.
>
>>>> [1] https://anonscm.debian.org/git/debian-med/tn-seqexplorer.git

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

Re: Help needed for tn-seqexplorer Java package

[Olivier Sallou]

On 05/08/2017 01:08 PM, Andreas Tille wrote:
> Hi again,
>
> On Sat, May 06, 2017 at 09:23:27AM +0200, Andreas Tille wrote:
>> I intend to package tn-seqexplorer[1].  I have removed all JAR files
>> upstream included into the sources and managed to replace several by
>> Debian packages.  I also packaged libexternalsortinginjava-java[2] which
>> is used by tn-seqexplorer and uploaded it to new.
> Meanwhile libexternalsortinginjava-java was accepted in unstable (thanks
> to ftpmaster for fast processing).  I also somehow managed to work around
> the other build issues.  Now I'm stumbling upon the fact that the program
> does not run:
>
> $ tn-seqexplorer 
> Exception in thread "main" java.lang.NullPointerException
> at sun.awt.SunToolkit.getImageFromHash(SunToolkit.java:725)
> at sun.awt.SunToolkit.getImage(SunToolkit.java:759)
> at GUI.LegalDisclaimer.(LegalDisclaimer.java:24)
> at essgenes.Main.main(Main.java:43)

It seems it does not find in jar file the file
/resources/legaldisplaimer.png

A resource file has not been included in the jar file. You can check
with jar -tf yourjarfile to see if it is present (but I don't think so
as I see no resource not png file in src)
As it is an icon, you could simply comment line 24 of
src/GUI/LegalDisplaimer.java, line 24 to fix the issue


Olivier

>
>
> Any hint what might be wrong here?
>
> Kind regards
>
>  Andreas.
>  
>
>> [1] https://anonscm.debian.org/git/debian-med/tn-seqexplorer.git
>> [2] https://anonscm.debian.org/git/pkg-java/libexternalsortinginjava-java.git

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

Re: Help needed for tn-seqexplorer Java package

[Olivier Sallou]

- Mail original -
> De: "Andreas Tille" 
> À: "Debian Med Project List" , "Debian Java 
> List" 
> Envoyé: Samedi 6 Mai 2017 09:23:27
> Objet: Help needed for tn-seqexplorer Java package
> 
> Hi,
> 
> I intend to package tn-seqexplorer[1].  I have removed all JAR files
> upstream included into the sources and managed to replace several by
> Debian packages.  I also packaged libexternalsortinginjava-java[2] which
> is used by tn-seqexplorer and uploaded it to new.
> 
> I have not found any replacement for the two jars poi-3.9-20121203.jar
> and jtstand-desktop-1.2.1.jar.  I'm not sure whether the resulting
> errors are connected to these:
> 
> 
> src/CompareUtilities/Compare.java:25: error: cannot find symbol
> import com.jgoodies.forms.factories.FormFactory;


it does not find a class that should come from a libjgoodies-XX-java package, 
did you include jgoodies packages in your package (and added it to your java 
build path) ?

>^
>   symbol:   class FormFactory
>   location: package com.jgoodies.forms.factories
> src/CustomGUIComponent/FolderChooser.java:11: warning: FilePane is internal
> proprietary API and may be removed in a future release
> import sun.swing.FilePane;
> ^
> src/GUI/PlotViewer.java:23: error: cannot find symbol
> import com.jgoodies.forms.factories.FormFactory;
>^
>   symbol:   class FormFactory
>   location: package com.jgoodies.forms.factories
> src/GUI/MainFrame.java:59: error: package org.apache.commons.math3.util does
> not exist
> import org.apache.commons.math3.util.Pair;

jgoodies seems to need libcommons-math3-java, so 
/usr/share/java/commons-math3.jar should be added in your build path

Olivier


> ^
> src/essgenes/StatisticsHelper.java:12: error: package
> org.apache.commons.math3.stat.descriptive.moment does not exist
> import org.apache.commons.math3.stat.descriptive.moment.Mean;
>^
> src/essgenes/StatisticsHelper.java:13: error: package
> org.apache.commons.math3.stat.descriptive.summary does not exist
> import org.apache.commons.math3.stat.descriptive.summary.Sum;
> ^
> 
> I think I simply did something wrong with the packaging and wonder if
> anybody could lead me on the right track.
> 
> Kind regards
> 
> Andreas.
> 
> 
> [1] https://anonscm.debian.org/git/debian-med/tn-seqexplorer.git
> [2] https://anonscm.debian.org/git/pkg-java/libexternalsortinginjava-java.git
> 
> --
> http://fam-tille.de
> 
> 

Re: Default Java version for jar file in Debian

[Olivier Sallou]

On 08/24/2016 10:18 AM, Ioan Eugen Stan wrote:
> Hello,
>
>
>
> I don't think that is possible since you can't build Java 8 code to
> target a lower JVM. You probably could if you used only those API's, but
> I believe you can't make that kind of assumption for all libraries.
certainly not all java libs are 1.5 compatible indeed, this would
suppose that they only use quite old Java core API.
But why 1.5 ? we should  target , when possible (if not depends on JDK
>= 1.8), the minimal Java version available in Debian (1.7 ?).

Olivier
>
> I think this link might be more helpfull:
>
> http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html
>
>
> Disclaymer: I hope I understood your question right. I'm a developer,
> and don't know a lot of internals related to packaging and policies
> around Java on Debian.
>
>
> On 24.08.2016 08:59, Mathieu Malaterre wrote:
>> [CC me please]
>>
>> Hi there,
>>
>> Could someone please confirm that all jar files should be compiled
>> with source and target version number set to 1.5 ?
>>
>> I am starring at the following:
>>
>> https://anonscm.debian.org/cgit/debian-med/gdcm.git/commit/?id=673e34b58867471a90e2fd70b30d442ecd16f505
>>
>> and I believe the value should be set to 1.5 for all archs
>>
>> Right ?
>>
>> Thanks
>>

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

Re: Autopkgtest fails when executable is link to JAR

[Olivier Sallou]

- Mail original -
> De: "Andreas Tille" 
> À: "Debian Java List" 
> Envoyé: Vendredi 29 Avril 2016 17:11:44
> Objet: Autopkgtest fails when executable is link to JAR
> 
> Hi,
> 
> I noticed that the autopkgtest for artfastqgenerator fails[1] with
> 
> ...
> emoving adt-satdep (0) ...
> adt-run [03:53:30]: test run-unit-test: [---
> /usr/bin/artfastqgenerator: 1: /usr/bin/artfastqgenerator: Syntax error: ")"
> unexpected
> adt-run [03:53:30]: test run-unit-test: ---]
> adt-run [03:53:30]: test run-unit-test:  - - - - - - - - - - results - - - -
> - - - - - -
> run-unit-testFAIL non-zero exit status 2
> adt-run [03:53:31]:  summary
> run-unit-testFAIL non-zero exit status 2
> ...
> 
> 
> I guess this is the case since the executable is just a symlink to the
> JAR file:
> 
> $ readlink /usr/bin/artfastqgenerator
> ../share/java/artfastqgenerator.jar
> 
looks strange, trying to execute a jar file directly. Should be something like 
java -jar  .../artfastqgenerator.jar

I do not understand why a jar file (well its symlink) is in /usr/bin. Should be 
a wrapper shell calling java command.

Olivier

> 
> and inside the lxc container that is used by debci this fails.  Is there
> any default solution to make the autopkgtest functional?
> 
> Kind regards
> 
>Andreas.
> 
> 
> [1]
> https://ci.debian.net/data/packages/unstable/amd64/a/artfastqgenerator/20160429_035231.autopkgtest.log.gz
> 
> --
> http://fam-tille.de
> 
>

Fwd: How to propagate mvn options to debhelper (Was: Need help to upgrade libnetlib-java package)

[Olivier Sallou]

- Mail transféré -
> De: "Andreas Tille" <andr...@an3as.eu>
> À: "Debian Java List" <debian-java@lists.debian.org>
> Cc: "Debian Med Packaging Team" <debian-med-packag...@lists.alioth.debian.org>
> Envoyé: Vendredi 22 Avril 2016 21:25:43
> Objet: How to propagate mvn options to debhelper (Was: Need help to upgrade 
> libnetlib-java package)
> 
> On Fri, Apr 22, 2016 at 05:46:30PM +0200, Olivier Sallou wrote:
> > >> I think this plugin is used in the maven "workflow", at install time
> > >> only, which should not be needed or required in Debian build workflow.
> > >> Maybe adding property in mvn command "-Dmaven.install.skip=true" would
> > >> help skipping this.
> > > Sounds promising - but how do I specify this?
> > Do you use mvn command in d/rules or only debian helpers? If you use
> > mvn, just add this after mvn, else I do not know how to specify extra
> > parameters for Debian java helpers.
> 
> I'm using plain javahelper.  The following failed:
> 
> diff --git a/debian/rules b/debian/rules
> index bde0193..eadfd0b 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -8,5 +8,5 @@
> dh $@ --buildsystem=maven --with javahelper
>  
>  override_dh_auto_build:
> -   dh_auto_build -- install
> +   dh_auto_build -- install -Dmaven.install.skip=true
>  
> 
> 
> Any better hint how to propagate mvn options

Looking at code of maven-debian-helper [0] it seems we can set some mvn cmd 
line args with env variable DEB_MAVEN_ARGS
However I never used it, nor found any doc for this (and expected workaround 
option is good...)


[0] 
https://github.com/Debian/maven-debian-helper/blob/master/share/cdbs/1/class/maven-vars.mk

> 
>  Andreas.
> 
> --
> http://fam-tille.de
> 
>

Re: Need help to upgrade libnetlib-java package

[Olivier Sallou]

On 04/21/2016 09:47 PM, Andreas Tille wrote:
> On Wed, Apr 20, 2016 at 07:03:31AM +0200, Olivier Sallou wrote:
>>> No, not really. My gut feeling too is, that packing oss-parent is not
>>> required. To me it looks like something in the Debian specific setup of
>>> the maven dependencies of libnetlib-java is missing, but I do not see
>>> what. You probably need to figure out the root cause, why installing
>>> maven-install-plugin does not help in finding the maven-plugin. Maybe
>>> it is some setup here that is missing somewhere.
>> I think this plugin is used in the maven "workflow", at install time only, 
>> which should not be needed or required in Debian build workflow.
>> Maybe adding property in mvn command "-Dmaven.install.skip=true" would help 
>> skipping this.
> Sounds promising - but how do I specify this?
Do you use mvn command in d/rules or only debian helpers? If you use
mvn, just add this after mvn, else I do not know how to specify extra
parameters for Debian java helpers.

Olivier
>
> Sorry for my ignorance
>
>Andreas.
>

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

Re: Need help to upgrade libnetlib-java package

[Olivier Sallou]

- Mail original -
> De: "Benjamin Mesing" 
> À: "Andreas Tille" , "Debian Java List" 
> , "Debian Med Packaging Team"
> 
> Envoyé: Mardi 19 Avril 2016 22:29:12
> Objet: Re: Need help to upgrade libnetlib-java package
> 
> Hi Andreas,
> 
> > >     [WARNING] The POM for org.apache.maven.plugins:maven-install-
> > > plugin:jar:2.5.2 is missing, no dependency information
> > > available
> > > and later on
> > > [ERROR] Plugin org.apache.maven.plugins:maven-install-plugin:2.5.2
> > > or one of its dependencies could not be resolved: Cannot access
> > > central (https://repo.maven.apache.org/maven2) in offline
> > > mode and
> > > the artifact org.apache.maven.plugins:maven-install-plugin:jar:2.5.2
> > > has not been downloaded from it before. -> [Help 1]
> > > This happens, even after I installed maven-install-plugin which I find
> > > rather strange.
> > > 
> > > Maybe this brings you a step closer and you have an idea how to go on.
> > This sounds like a probable alternative.  If there is no better idea I
> > might start with packaging it from here[1].  However, it also might be
> > avoidable according to this mail[2] - so there might be a way to
> > circumvent packaging more and more stuff I do not really understand.
> > 
> > Any further hint?
> 
> No, not really. My gut feeling too is, that packing oss-parent is not
> required. To me it looks like something in the Debian specific setup of
> the maven dependencies of libnetlib-java is missing, but I do not see
> what. You probably need to figure out the root cause, why installing
> maven-install-plugin does not help in finding the maven-plugin. Maybe
> it is some setup here that is missing somewhere.

I think this plugin is used in the maven "workflow", at install time only, 
which should not be needed or required in Debian build workflow.
Maybe adding property in mvn command "-Dmaven.install.skip=true" would help 
skipping this.

Olivier

> 
> Good Luck
> 
> Benjamin
> 
> 
> --
> Please do not send any email to ben...@gmx.net -- all email not
> originating from the mailing list will be deleted. Use the reply to
> address instead.
> 
> 
>

Re: [Help]: Bug#808593: htsjdk: FTBFS: [testng] FAILED: testHTTPNotExist

[Olivier Sallou]

- Mail original -
> De: "Vincent Danjean" 
> À: "Emmanuel Bourg" , "Andreas Tille" , 
> "Debian Java List"
> , 808...@bugs.debian.org
> Envoyé: Lundi 14 Mars 2016 21:20:11
> Objet: Re: [Help]: Bug#808593: htsjdk: FTBFS: [testng] FAILED: 
> testHTTPNotExist
> 
> Le 11/02/2016 21:50, Emmanuel Bourg a écrit :
> > Le 11/02/2016 21:01, Andreas Tille a écrit :
> > 
> >> any hint why this test that worked before might fail since end of
> >> December?
> > 
> > I got a quick look and I can't explain this test failure. It doesn't
> > seem very important though, you could just disable this test.
> 
> I just upgraded htsjdk (required for picard-tools). It does not seem to
> FTBFS anymore (pushed in git).

yeap, I checked this with Andreas some time ago, and could not reproduce either.

>   I plan to upload it when picard-tools will be ready but if someone
> can take a look at it before, I would be pleased. In particular,
> there is in debian/control:
> ===
> Build-Depends: openjdk-8-jre-headless, openjdk-8-jdk, ...
> Build-Conflicts: openjdk-7-jre-headless
> ===
> 
> And, in debian/rules:
> ===
>   dh_auto_build -- -Dant.build.javac.source=1.8 -Dant.build.javac.target=1.8
>   ...
> ===
> 
> Is it the correct way to build a package that requires java 8?

as long as target is not specifically set in build.xml that's the way.

Olivie

> 
> I do not change this part myself and did not check the requirement,
> but I just saw with picard-tools (same upstream authors) that java 8
> is also required ( <> operator (>=7) and lambda expressions (>=8) )
> so I would like to be sure to do the correct thing.
> 
>   Regards,
> Vincent
> 
> > Emmanuel Bourg
> > 
> 
> 
> --
> Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
> GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
> Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
> APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main
> 
> 

lombok packaging with Ivy

[olivier sallou]

Hi,
has anyone already build package using Ivy (manage ant dependencies etc...)
?

mk-origtargz chokes on files other than tar or zip archives

[olivier sallou]

Hi,
I tried to package a freehep (freehep-graphics-base) library based on
freehep-export debian repo.

I tried to download the source based on watch and debian/orig-tar.sh (to
get from svn based tag), but it fails with uscan about file not being a zip
(and yes it isn't, it is a single file with release version).

I found a corresponding bug (see below) that says it is fixed.

Debian Bug report logs - #748462
uscan: mk-origtargz chokes on files other than tar or zip archives

However, it does not work for me. I am working on up-to-date sid.

I do a uscan --verbose --force-download.

Has anyone still the issue, or am I missing something?

Thanks

Olivier

Bug 770608 on maven: planned upload date?

[olivier sallou]

Hi,
do you have a planned date to upload fix on maven (bug #770608):

maven: FTBFS: maven-install-plugin or one of its dependencies could not be
resolved

This bug has as consequence that some other packages are marked for
autoremoval due to dependencies.

I had a way to override this on some of my packages marked for autoremoval
beginning of January, but release team asked me to wait for the fix of this
package instead of re-uploading my packages with modification. If fix is
not planned very soon, I will have to ask again to release team to accept
my packages modifications to avoid removal.

Thanks

Olivier

Help required for webapp on Tomcat8

[Olivier Sallou]

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: Help required for webapp on Tomcat8

[Olivier Sallou]

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-java-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: Please help with Java lib

[Olivier Sallou]

On 09/25/2014 10:19 PM, Andreas Tille wrote:
 Hi Debian Java folks,

 it seems there is no real progress in this issue.  Do you have any hint
 what to do.  BTW (as in other cases): if you prefer maintaining
 libsnappy-java in Debian Java team I'd happily move the packaging into
 your Git repository.
From my last post, I think that issue is (after patch is applied) that
snappy lib is too old. Seems that Java lib is using a more recent version:

SnappyTests Exception in thread main java.lang.UnsatisfiedLinkError:
org.xerial.snappy.SnappyNative.maxCompressedLength(I)I
at org.xerial.snappy.SnappyNative.maxCompressedLength(Native Method)
at org.xerial.snappy.Snappy.maxCompressedLength(Snappy.java:316)
at org.xerial.snappy.Snappy.rawCompress(Snappy.java:329)
at org.xerial.snappy.Snappy.compress(Snappy.java:88)
at SnappyTests.main(SnappyTests.java:12)

Tje maxCompressedLength sould be available in a new version


Olivier
 Kind regards

Andreas.


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

Re: Please help with Java lib

[Olivier Sallou]

On 09/26/2014 09:48 AM, Andreas Tille wrote:
 Hi Olivier,

 On Fri, Sep 26, 2014 at 09:23:47AM +0200, Olivier Sallou wrote:
 On 09/25/2014 10:19 PM, Andreas Tille wrote:
 Hi Debian Java folks,

 it seems there is no real progress in this issue.  Do you have any hint
 what to do.  BTW (as in other cases): if you prefer maintaining
 libsnappy-java in Debian Java team I'd happily move the packaging into
 your Git repository.
 From my last post, I think that issue is (after patch is applied) that
 snappy lib is too old. Seems that Java lib is using a more recent version:

 SnappyTests Exception in thread main java.lang.UnsatisfiedLinkError:
 org.xerial.snappy.SnappyNative.maxCompressedLength(I)I
 at org.xerial.snappy.SnappyNative.maxCompressedLength(Native Method)
 at org.xerial.snappy.Snappy.maxCompressedLength(Snappy.java:316)
 at org.xerial.snappy.Snappy.rawCompress(Snappy.java:329)
 at org.xerial.snappy.Snappy.compress(Snappy.java:88)
 at SnappyTests.main(SnappyTests.java:12)

 Tje maxCompressedLength sould be available in a new version
 Sorry, I might miss the point of your mail.  This means exactly what for
 the package?
In a post in the bug, I provided a patch to fix the Native library loading.

The problem is at execution, where the Java lib tries to use some
methods in the native lib.
Those methods are not available in the native lib currently in Debian. I
think there is a newer upstream release for the native library that
integrates them.
But I do not know if the Java lib upstream team uses official releases.

For what I understood, once patch is applied, is that the Java lib
version needs to match a specific version (newer?) of the native lib.

Olivier

 Kind regards

 Andreas.


-- 
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-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54255616.9040...@irisa.fr

Re: cofoja vs libcofoja-java

[olivier sallou]

2014-04-15 17:40 GMT+02:00 Andreas Tille ti...@debian.org:

 Hi Tony,

 On Mon, Apr 14, 2014 at 09:09:51PM -0700, tony mancill wrote:
   So if there are Debian Java team members who have some preference why
   not recommending this in a policy document?  For people who are
 seldomly
   touching Java packages strict rules would be simply helpful.
  
   I guess there is a lack of consensus to turn this into a policy. That
   sound like an excellent bikeshedding topic that could keep us busy
   during the freeze :)
 
  My preference aligns with Emmanuel's - that is, use the upstream name
  for the source package, provided that it isn't so generic so as to be
  confusing or conflicting with other packages in the archive.
 
  However, I'm reluctant to suggest that we need a policy for this,
  because I don't want us to spend time renaming packages just so the
  source package names conform to an arbitrary policy.  (However,
  documenting a recommendation would be nice.)

 +1

 It is just to give uneducated Java packagers (like me) a helping hand
 for best practices.  I would not start renaming existing packages.

  Having a policy for the
  library binary packages seems sufficient to catch most potential
  duplicates.  If you want to want package foo.jar, you can start by
  looking for an existing libfoo-java.
 
  In any event, it's great that DebianMed is lending a helping hand.
  Continue to let us know what could be done better, and don't be shy
  about asking for pkg-java commit rights/Java Team membership.

 The point is that I feel quite incompetent with Java packaging.
 However, we have some members in the Java team.  Regarding the Debian
 Med Java packages:  Sometimes you need to decide where a package should
 go to:  If the application fits the Debian Med team and the programming
 language is just Java you have to make a decision.  In any case ACLs for
 the Debian Med repository are set that any DD has commit permissions.


I have put several packages in Debian Java though working for Debian Med.
I usually go to Debian Java for Java libraries (even if med related), to
get better support, later on, on JDK issues etc...

Olivier


 In general we have never fight to keep a package in our repository
 (there are similar cases for Perl, Python, Ruby etc.)  So if you
 think we could enhance something - please let us know.

 Kind regards

   Andreas.

 --
 http://fam-tille.de




-- 

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

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

Re: cofoja vs libcofoja-java

[olivier sallou]

2014-04-10 0:30 GMT+02:00 Diane Trout di...@ghic.org:

 That was my mistake. I wonder why I didn't find the java team package?

 Is there a way to retract my package in favor of the java teams?

Hi,
I packaged it  for Java team because it was (is) a Java library but I made
it on behalf of the DebianMed team... ;-)

I have seen this duplication yesterday. You packaged latest libcofoja
version and it replaced mine, that's fine for me, and if everyone agree,
let's remove cofoja in favor of libcofoja-java as it is a matter of source
package only, binary package is the same (but version) and as such will not
impact dependent packages.

Olivier


 Diane

 On Thursday, April 10, 2014 00:13:49 Emmanuel Bourg wrote:
  Hi all,
 
  I just noticed that cofoja has been packaged twice. There are two source
  packages, cofoja [1] and libcofoja-java [2], that both create a
  libcofoja-java binary package.
 
  - cofoja has been packaged last year by Olivier Sallou for the Debian
  Java Team
  - libcofoja-java has been packaged last month by Diane Trout and Andreas
  Tille for the Debian Med Team
 
  What is the proper way to resolve this conflict?
 
  Emmanuel Bourg
 
  [1] http://packages.qa.debian.org/c/cofoja.html
  [2] http://packages.qa.debian.org/libc/libcofoja-java.html




-- 

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

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

Re: [Debian-med-packaging] Bug#715530: jai-core: Please build explicitly with OpenJDK 6

[Olivier Sallou]

On 07/10/2013 09:40 AM, Andreas Tille wrote:
 Hi Niels,

 I perfectly agree that we should not try to keep OpenJDK-6 alive for
 ages.  However, jai-core is packaged as precondition for other packages
 that are quite important (for Debian Med).  The problem is that as you
 probably know all these Java programs just include a jai-core.jar which
 is unacceptable for a package in main.  So we tried to package this code
 that is orphaned since sic years if you look at their SVN

https://java.net/projects/jai-core/sources/svn/show

 The question ist now, whether we as in Debian are able to maintain this
 code (which also has a non-free license (JRL)) or whether there is some
 replacement.  I simply can not believe that there is no free library for
 Java to do image operations. 
There are a few of course, ut with different APIs that may highly impact
the code.
 We could however have a look

Olivier


  Otherwise our chances to package our final
 targets in medical imaging are close to zero.

 Kind regards

Andreas.

 On Wed, Jul 10, 2013 at 08:56:43AM +0200, Niels Thykier wrote:
 Hi,

 I am not the maintainer, but I think this might not be the best
 solution.  We want to get rid of OpenJDK-6 in Debian (in Jessie), so
 this is at best a temporary solution.
   I would highly recommend porting the package to (also) work with
 OpenJDK-7 instead.

 ~Niels

-- 
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-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51dd1a92.80...@irisa.fr

junit issue

[Olivier Sallou]

Hi,
one of my packages (biojava3-live) fails to build after a dependency
update (which one?).

What is strange is it fails at junit time (via ant task) with error: 
java.lang.NoClassDefFoundError: junit/framework/JUnit4TestAdapterCache

[junit] Running org.biojava3.core.sequence.DNATest
[junit] Testsuite: org.biojava3.core.sequence.DNATest
[junit] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
elapsed: 0 sec
[junit] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
elapsed: 0 sec
[junit]
[junit] Caused an ERROR
[junit] junit/framework/JUnit4TestAdapterCache
[junit] java.lang.NoClassDefFoundError:
junit/framework/JUnit4TestAdapterCache
[junit] at java.lang.ClassLoader.defineClass1(Native Method)
[junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
[junit] at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)

I looked at Junit4.jar content and JUnit4TestAdapterCache is still there
(and biojava code does not call it).
Looks like the noclassdeffounderror hides the name of the class it is
looking for.

Any idea what's going on  or how I could debug this?

Thanks

Olivier

-- 
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-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c04051.9010...@irisa.fr

Re: junit issue

[Olivier Sallou]

On 06/18/2013 03:06 PM, James Page wrote:
 Hi Olivier

 On 18/06/13 12:11, Olivier Sallou wrote:
 What is strange is it fails at junit time (via ant task) with error:
 java.lang.NoClassDefFoundError: junit/framework/JUnit4TestAdapterCache

  [junit] Running org.biojava3.core.sequence.DNATest
  [junit] Testsuite: org.biojava3.core.sequence.DNATest
  [junit] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
 elapsed: 0 sec
  [junit] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
 elapsed: 0 sec
  [junit]
  [junit] Caused an ERROR
  [junit] junit/framework/JUnit4TestAdapterCache
  [junit] java.lang.NoClassDefFoundError:
 junit/framework/JUnit4TestAdapterCache
  [junit] at java.lang.ClassLoader.defineClass1(Native Method)
  [junit] at
 java.lang.ClassLoader.defineClass(ClassLoader.java:634)
  [junit] at
 java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)

 I looked at Junit4.jar content and JUnit4TestAdapterCache is still there
 (and biojava code does not call it).
 Looks like the noclassdeffounderror hides the name of the class it is
 looking for.

 Any idea what's going on  or how I could debug this?

 I think I just fixed something similar in commons-compress; could you
 check that you have ant-junit4.jar on your classpath for ant?  without
 this the ant junit task appears to struggle detect JUnit4 test stuff.
ant-junit4 is in ant path. My build.xml has not changed since last
successful build (not source), only my system (dependencies update).

I just tried to set fork=true to junit, and it worked. But I do not
know why? What is the difference with previous versions.

Olivier

 Cheers

 James



-- 
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-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51c05fce.4020...@irisa.fr

Re: Please help with Java issue where it seems to make a difference where JAR is installed

[Olivier Sallou]

On 06/05/2013 01:34 PM, Andreas Tille wrote:
 Hi,

 according to a hint on debian-mentors it seems to be a good idea to drop
 a note here if Java is involved.  Please CC me, because I'm not
 subscribed.
Hi,
sorry I missed previous mails about this. I should need a deeper look
but indeed ClassLoader.getSystemResource
will load in wrong location for you. It gonna search within the virtual
directory of the jar file, not in the other jar files set in the classpath.


I do not know how to search within an other jar, but if issue is only an
icon matter, the package could copy the
/usr/share/fastqc/Templates/Icons directory (from Templates in fact) in
the package structure. This is a duplication but not a big deal for a
few icons (and no security issue).

Olivier


 Kind regards

Andreas.

 - Forwarded message from Andreas Tille andr...@an3as.eu -

 Date: Thu, 23 May 2013 16:36:37 +0200
 From: Andreas Tille andr...@an3as.eu
 To: cont...@bugs.debian.org, Debian Mentors List 
 debian-ment...@lists.debian.org
 Subject: Please help with Java issue where it seems to make a difference 
 where JAR is installed

 tags 697604 help
 thanks

 Hi,

 I'm a bit lost with my bit of Java knowledge if it comes to internals.
 I can only confirm that I can perfectly reproduce the problem using the
 data file submitted in [1] for testing and one reporter states in [2]:

   I downloaded upstream FastQC and there was no such problem. The only
   difference that I see is that in Debian a fastqc.jar is used while in
   upstream it's unpacked in the root directory. My conclusion is that this
   specific way with getSystemResource searches only the location where
   main class resides. In Debian's case it's fastqc.jar and in upstream
   it's FastQC directory.

 Any help is really welcome

 Andreas.


 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697604#15
 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697604#5


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

Re: Please help with Java issue where it seems to make a difference where JAR is installed

[Olivier Sallou]

On 06/05/2013 04:27 PM, Olivier Sallou wrote:

 On 06/05/2013 01:34 PM, Andreas Tille wrote:
 Hi,

 according to a hint on debian-mentors it seems to be a good idea to drop
 a note here if Java is involved.  Please CC me, because I'm not
 subscribed.
 Hi,
 sorry I missed previous mails about this. I should need a deeper look
 but indeed ClassLoader.getSystemResource
 will load in wrong location for you. It gonna search within the
 virtual directory of the jar file, not in the other jar files set in
 the classpath.


 I do not know how to search within an other jar, but if issue is only
 an icon matter, the package could copy the
 /usr/share/fastqc/Templates/Icons directory (from Templates in fact)
 in the package structure. This is a duplication but not a big deal for
 a few icons (and no security issue).

 Olivier
Maybe something like:

ClassFromFastQ.class.getClassLoader().getResource(Templates/Icons)

could work

 Kind regards

Andreas.

 - Forwarded message from Andreas Tille andr...@an3as.eu -

 Date: Thu, 23 May 2013 16:36:37 +0200
 From: Andreas Tille andr...@an3as.eu
 To: cont...@bugs.debian.org, Debian Mentors List 
 debian-ment...@lists.debian.org
 Subject: Please help with Java issue where it seems to make a difference 
 where JAR is installed

 tags 697604 help
 thanks

 Hi,

 I'm a bit lost with my bit of Java knowledge if it comes to internals.
 I can only confirm that I can perfectly reproduce the problem using the
 data file submitted in [1] for testing and one reporter states in [2]:

   I downloaded upstream FastQC and there was no such problem. The only
   difference that I see is that in Debian a fastqc.jar is used while in
   upstream it's unpacked in the root directory. My conclusion is that this
   specific way with getSystemResource searches only the location where
   main class resides. In Debian's case it's fastqc.jar and in upstream
   it's FastQC directory.

 Any help is really welcome

 Andreas.


 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697604#15
 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697604#5


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


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

libcommons-jexl2-java

[Olivier Sallou]

Hi Emmanuel,
I just tried to upload libcommons-jexl2-java from experimental to
unstable now that maven-debian-helper has been updated on unstable.

However I have a build error now during unit tests:

Tests in error:
  testCalculations(org.apache.commons.jexl2.ArithmeticTest):
org.apache.commons.jexl2.junit.Asserter.assertExpression@83![0,5]: '3 /
0;' divide error

I am still testing v2.1.1, no modification from previous build.

So it seems there is a regression related to a package update (which one?).

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-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51a89801.1010...@irisa.fr

maven-debian-helper 1.6.1 to unstable

[Olivier Sallou]

Hi,
when do you plan to move maven-debian-helper 1.6.1 from experimental to
unstable ?
I need it for an other package to put it in unstable.

Thanks

Olivier

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

Re: libcommons-jexl2-java

[Olivier Sallou]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 04/26/2013 08:24 PM, Emmanuel Bourg wrote:
 Le 26/04/2013 17:29, Olivier Sallou a écrit :

 I have updated from repo but it ends with an error with your update of
 rules.

 Is it any better if you update to maven-debian-helper 1.6.1 from
 experimental?
Indeed, upgrading to experimental solves the issue.
This means that Build-Depends must be updated to reflect the need of
maven-debian-helper = 1.6.1

Package content is fine. Once versioning is fixed, I should be able to
upload the package. Thanks for your work.

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRfhrmAAoJEHjcaNsybYQ44+kP/AyicF99zWmtou/XUiyAoIuU
uMs1aIGt+B3Pc20PRE6cnBiuiknykXbQQoPDAv6cSzL/L5RYIJeSSLGHGPRlJZE1
4SxaLFywkBQ53+Hf3iVWGQbRjqDipRFeIux8foHaiOBR1mM8AJloa/hxAgMeSAnc
NXwwqkZce+Dp2V9KDDPRaWzDPQ2Oy/0dDiRLy8uCPWRqmqBa22moKItpLATs8LH/
MYKL/hQ+VgSEEGl8tUnZ/JXnpJ0MZCR4ICoStr1zgT3VX+IfungHX/9bLEvFPRml
ByuW9w+r0WnVCOc3si2P5YEfQyNUMYuJSdpH+QSKUD9UNQJUeEdhtjvk2Yn1Skpe
yjleT8KfWAJyvasYfncMu17XUM6ITEHar37Lt5avPeIIiCiFMb+2zJtjBQCyCooC
pMTv97K1UGbetQVZY6/ds6aOeIIF5wfuCsi7X/loBtn+2DYSpBwq8mrb86+ljN8l
AACOVoqSsYl6rx4IxeAgl5utlhVZe7UDD1rZZKe+t0UwlyTVo/V/hJepSYZ/ppeD
8leh+w95Ogswi8x4KKHbsovE9Xqjdg79T2vubmSVTcqDUOFsHXMnA0ph453gYkrF
JHdIThI9kDpDBhlQDJiUXKNL8L9VsbD4tpqDU7JAu6sca0eNTi7F9jIDGLN+kTY2
oZLGvuMGnerLhlwF0Z5E
=QQiW
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/517e1ae6.2070...@irisa.fr

Re: libcommons-jexl2-java

[Olivier Sallou]

On 04/25/2013 02:45 PM, Emmanuel Bourg wrote:
 Le 25/04/2013 12:53, Olivier Sallou a écrit :
 Hi Emmanuel,
 did you progress on jexl2 ? I did not see it on mentors.debian.net

 Hi Olivier,

 I uploaded the package on mentors, let me know how it works for you. Do
 you want to sponsor it?
I am ok to sponsor it. I will have a look at the package soon.
I see however in lintian warnings that classpath is not set in jar
manifest. Could you please fix this?

Olivier


 http://mentors.debian.net/package/libcommons-jexl2-java


 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

Re: libcommons-jexl2-java

[Olivier Sallou]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 04/26/2013 09:56 AM, Emmanuel Bourg wrote:
 Hi Olivier,

 Le 26/04/2013 09:50, Olivier Sallou a écrit :

 I am ok to sponsor it. I will have a look at the package soon.
 I see however in lintian warnings that classpath is not set in jar
 manifest. Could you please fix this?

 Thank you. I don't know how to do that with Maven helper. But
 commons-jexl2.jar is not executable, I don't think the classpath is
needed.
I do not use maven helper usually but java helper, so I can't help.
Could be a patch on pom to add manifest.

Needed, not really indeed. However Java policy [0] specifies, even for
library that classpath should be set.

By the way I tried a first build and it failed on clean target with
svn-buildpackage (see below).
It works I build the package directly.

osallou@debiansid:~/Desktop/DEBIAN-JAVA/libcommons-jexl2-java/trunk$
svn-buildpackage -rfakeroot
Complete layout information:
trunkDir=/home/osallou/Desktop/DEBIAN-JAVA/libcommons-jexl2-java/trunk
trunkUrl=svn://svn.debian.org/svn/pkg-java/trunk/libcommons-jexl2-java
dpkg-checkbuilddeps
fakeroot debian/rules clean || die
test -x debian/rules
dh_testroot
mkdir -p .
mh_patchpoms -plibcommons-jexl2-java --debian-build --keep-pom-version
--maven-repo=/home/osallou/Desktop/DEBIAN-JAVA/libcommons-jexl2-java/trunk/debian/maven-repo
--ignore-rules=debian/maven.ignoreRules
--clean-ignore-rules=debian/maven.cleanIgnoreRules
cp: cannot stat ?pom.xml?: No such file or directory
make: *** [debian/stamp-poms-patched] Error 1
sh: 1: die: not found






[0] http://www.debian.org/doc/packaging-manuals/java-policy/x104.html:
All jar files /must/ have a well-documented CLASSPATH, so that
developers should know what to add to their wrappers.



 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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRejpjAAoJEHjcaNsybYQ4UWkP/1nqabvqvps8ObiW/RH/tGsz
Qa6d0sLQnP66sTDM3IqNhjRmvuwkl20zjqdFybH/dMA8ZnwjQIl2VKthk2+Mhmdm
XInpP4n6OfArJnuk4InWZ6f6zzMgnd5lvshCmCOoFyWjl4sAZz6GBSirRo+PB07A
ha4f345kjRP03sJjSapTW3ZI1TD0qBaBq0oZuASH0XoPzzrG4z1LI8isyhYA80VX
53f/KsFDapk3ygJSkRTGwSJYh6iS6AsSkZzqL67a4wPCUF/r8R8B9BVb0IxQn2N5
pc9wPYvwF4SzWKMVfPhW/Cc9+3j51C7vVeuCS1AphSg9R41YmvHsBKH4Sijg54l9
jpykxHb0X0ON09CtBkviIzf0lvNQJh2Vrm8n1Y3MqTJ1zrMT2QQvRW0l3qy7rnOE
hA1t4hRm7Pt56SKVer5EezPxebAnp3IM2ApasqWgblXqZ01uorS+12QbnqWz00zx
AD/8eQ3dVbfkEj+6Z9Uns+OCVKtWr1GUa7BSVlmMUFWjgSgPgIr13ZjF4xlPA1zt
QZnA7P6ZZAJaMFKjbM84uNiKDeTXy5pUn/3eDtabOXhQ2G2uJ26h7ib1Nh85Max6
hoIqVHM3EnC9mf3BxudjOK53l7MWX0zRPrcegIOSCMBgi5qbXxKSEvFUXdwmRmXQ
Zb2KuU6oTtRcmXau0k4G
=WlT7
-END PGP SIGNATURE-

Re: libcommons-jexl2-java

[Olivier Sallou]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 04/26/2013 10:24 AM, Emmanuel Bourg wrote:
 Le 26/04/2013 10:16, Eugene Zhukov a écrit :

 To fix this warning you can patch pom.xml with maven-jar-plugin and
 addClasspathtrue/addClasspath flag.
 http://maven.apache.org/shared/maven-archiver/examples/classpath.html

 Thank you Eugene, I wasn't aware of this feature.

 However will that really work in our case? It seems the jars are
 specified in the Class-Path attribute with the version. We want
 version-less jars, that is:

 Class-Path: plexus-utils.jar commons-lang.jar

 instead of:

 Class-Path: plexus-utils-1.1.jar commons-lang-2.1.jar
Seems something like

  build
plugins
  plugin
 artifactIdmaven-war-plugin/artifactId
 configuration
   archive
 manifest
   addClasspathtrue/addClasspath
   classpathLayoutTypecustom/classpathLayoutType
  
customClasspathLayout$${artifact.artifactId}-$${artifact.version}.$${artifact.extension}/customClasspathLayout
 /manifest
   /archive
 /configuration
  /plugin
/plugins
  /build

is possible
(http://maven.apache.org/shared/maven-archiver/examples/classpath.html#aCustom).
So you could remove version





 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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRelDAAAoJEHjcaNsybYQ4K+wP/37QAxh69vomg3xLnWesxQql
BWTGWCdiRjGJ/ID6ZsInn/2xKgJhj6rAAKIDVK+IAymD6ru8V926u8mGaccCwUpj
8bP/15ee8tWUhZkN5KXSwLkaVq9HNHf76/JCrXBLTh4OeEGZs5SeK4yeTtRq0KQO
ih5E8fk8eeWyQqvLmoYnXiKgBj8GdQS/vwyeHiiU6Q64cvI29vOnD9CfOKXakELb
gYYt19DRap976v4N49ZUCGwbCYxT6rZ2GjQP5tzouRDdqFPZ3RKR0I7+AdynUrY+
AgSZAFfu3K/RGM3s4U875sOG1wuibvV0jDIzuG1d90cyiv8D9xQXYRRSS61aeFEB
GrHEf/2bQzHLQvFDxtkcK9NJeVZ1tyq08KZT2PMy2yI8utBK1tYY9L4dcGpoZeLB
ZyaAR6pUMvZbd9GzZeVINewDCssA2puY2Qk4p9YklbqL7IQqYly+ArNTCxSOxCG4
/9bHI4wYkINcXNq0I2IG7GLL0g43OuHrEQLfNSo+Cz5UbdK3dF71eimL82OHgz8E
wTiGjSWzPB2hkBX4sqvSrFgcAQ3zD8iZNX2lG2m9gNpEXlrWWKzR2Sw6oYA6Pgt3
esxNypJbsSQMa0gWWCcSV91hFwe6eSn5vTuxpffXAem8pA2OuLFwmUAmIi3MkaIG
QAZlV38DU0L1PW8Lso39
=ErJo
-END PGP SIGNATURE-

Re: libcommons-jexl2-java

[Olivier Sallou]

On 04/26/2013 12:13 PM, Niels Thykier wrote:
 On 2013-04-26 11:58, Olivier Sallou wrote:
 I have the latest version on SVN for debian dir.

 Olivier
 Which version of the maven helpers are you using?  There was a bug in
 one of the maven helpers where it didn't deploy jars to /usr/share/java
 by default for lib*-java packages (which may be related to this problem).
maven-debian-helper   1.5.1  from  unstable

 ~Niels




-- 
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-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/517a55fe.3000...@irisa.fr

Re: libcommons-jexl2-java

[Olivier Sallou]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 04/26/2013 12:38 PM, Emmanuel Bourg wrote:
 Le 26/04/2013 12:28, James Page a écrit :

 Maybe try this as an alternative approach - its a little manual but does
 work:


https://javacruft.wordpress.com/2011/06/03/avoiding-missing-classpath-lintian-warnings-with-maven-based-packages/

 I added javahelper.mk to debian/rules but nothing changed. Did I miss
 something?


 #!/usr/bin/make -f

 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/maven.mk
 include /usr/share/cdbs/1/class/javahelper.mk

 JAVA_HOME := /usr/lib/jvm/default-java

 get-orig-source:
 uscan --download-version $(DEB_UPSTREAM_VERSION)
 --force-download --rename
You may have missed the debian/libcommons-jexl2-java.classpath



 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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJReltTAAoJEHjcaNsybYQ4RPMP/jbLmfEdHmK2FtFM3OPLh5g8
R/wEQbYIoNu/t8EbwanVwEwoeEQDIJ6NtqRRKwcA17MQX5yPocZuSgQsZjSKu3wp
cREGwB5IeIgcM00gJED4KWTYco3zDjbi8T7x5DCthZhS663qGlcR8+EdioJKMyYO
WJBYJUpBmrLLY6mNfe0Mmf9serbm0zwS6Q519ieCJWx4/dCxvYwmbROoD/dW8ggW
/UpJAMHri/2evYzrxKVstyZOP50OYCAhqyRu+Lx2J29kmV4BjNwzv9LF5iismim7
80yPFLAkt1lkarseCXh9uXC+5unQ/FLXkVfo8nAVikNE+Ot1IuW8SgfHHb1k0wO8
9tEC4UwyapHsssakP9/21HrFHsQpkz45cNyEk8RPyASPwHNASxEYmoRStu76WZ1a
ry/L9GMGFhqNrstzUKwIxEBOrX1am3UXYhcgbIectC5XXS4sdkdzQE0+TNTP/kjA
Bz7NGugi9RIeBBNlZTn/rn8btBqvH+IsAQfkh0VXBIlWu+NDFxSlX/pJ9zGym4Ph
Ibo//Jsrdco+xTcbhQtSwNnG1jM85N2F/A18AIM8/vQIiHCFzesOOng78ABK4o12
p3jLzZyX0G7iRxFdxhM8zQYKqe/6WS/zfB/ntZPoOugPH07dzuKBitP1Lv8m53AD
oGWUuzhZ8alKHqaAQU24
=79SB
-END PGP SIGNATURE-

Re: libcommons-jexl2-java

[Olivier Sallou]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 04/26/2013 01:20 PM, Emmanuel Bourg wrote:
 Le 26/04/2013 12:47, Olivier Sallou a écrit :

 You may have missed the debian/libcommons-jexl2-java.classpath

 Indeed, thank you. It works now.

 Do we want absolute or relative references?

 Class-Path: commons-logging.jar

 or

 Class-Path: /usr/share/java/commons-logging.jar
I don't know what is usal usage for this. I would tend to use absolute path



 Both are accepted by Lintian.


 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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRemPUAAoJEHjcaNsybYQ40woP/1JJnkcs+3LY/GuMDjYTe5Gb
+wijjYbMFdNNSpX3pTTd35dSr8gR+mafCDz05RiJUHcyce+fn6cC/S0FOfnEKYJl
14+kmGJ4hpAsLk0ob5rDpRGHWAL8k1LUll6fnLvTRY/eqxbsdy4aVg4xzMkOT9sd
ydYisLPnfq0xZCszZZ7OJV0xNLPLPULydiXRlzuFaY34rqpe2/L2EPZwwb98PQZx
kJvbT0bZ7fXNkamIHk3aetRlJCW46tp/GdLwtfeXSGJ51LFNBISNtsFvc2VU9hEe
pzCfAKUtv7d+BwD6YecHksisJ6kWV4BjOnlXV1k6fAjyTM6Zsjr/H7YigS6TPpYC
LPLuvtFKL+o5XlCKyUIZ01RxCxreHVKiESRUNIU+wfp2tjVU1EMq/M1Zf53+iNNo
MplH27dW+acxpFi0A9yIBGh0CvQzgnoWjxdMcs5OaXFcZEHeiXCh9l0p1mHPvM0g
UKQVXhdTUXVTYzj47UY9hz8fHC0FPGnzCswbUvnCREKnncfwFDJIHHBqTJJQwXhh
c0dd8ZhCnNe2oJFXnEmgeiT6CZptNr2uZWSngymtlk+TPaoRNsZ3q0FkXWtdSRWs
gTQn7zvCCl0kbrk3kN9baZPzgmjTX3xwoZBlZogi31mmYYrY7N+axCxsYiaaL13H
5jmHpHEeNtr+dQk2ozIl
=+k1i
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/517a63d4.5000...@irisa.fr

Re: libcommons-jexl2-java

[Olivier Sallou]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 04/26/2013 01:59 PM, Emmanuel Bourg wrote:
 Le 26/04/2013 13:39, Niels Thykier a écrit :

 It has not been standardized.  Lintian accepts anything Class-Path entry
 that either points to an existing file in the same package or points to
 an entry in /usr/share/java.

 I scanned quickly the jars in my /usr/share/java directory. Out of 596
 jars (symlinks excluded) there are 71 files with a manifest, 23 use an
 absolute path and 48 a relative path.

 Considering the low amount of jars with a Class-Path I wonder if the
 burden of maintaining it is really justified.
Well, this is in Policy. Maybe Policy did not required it before.
I would let Debian Java team answer for this.

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRenYtAAoJEHjcaNsybYQ4xIAP/3kQTxYurnZqLfd7K/q9mb1K
xccozMEBq6dhwBoBjz8/0GHye7rsLnPSDAyUHq6X8LALpbaWiZ4xOkBwQqz6jV2l
T24bvMec2OsQa+VG6nKSb2unKnKoglPN00dkVut7+mPbeSobcRKNn+8ZWbx8qT9C
UgnpPr2kL73LIURB+ceBXwuBhvL749qCGesmMNnyb0rw8lU0h65fg9bviPU7rmgB
yatj5FOpjMUDGOH3Ks52jRe5uAJKrD6lvl9FwGMTtiBOgPmKFURz24pWd3LUoss6
8Qr8jYu+UoJsABEBqPLbU3K07kOah5EwXXI0sjL4Q2/sdN6+rJZY/Zz7mpo22IHQ
LJcITUJ/Hr+NjLCG7HsFN8ftBi3+OcSu6qwV9EtpwMeTVh2oabJ2ayJ/YL84n1NC
eRx44gEfA9cJKIswdlZnAavCjK4vjzIZsgZpn8rLdEYzduOzg7r48/IMIhdU5kjd
6JDnNiIWoUMHyJBe6/9LNX8WVdyM0qcQls2no61c71mXgC0OIKQr7pMAqq/lI9Vc
p6HmLevfXFglOuaYzID4uP/f98Il6WkKmh74JJhTVadrIcoJMcny0Oroxp7UqimT
jdlqshOcENXRvQiO7/Z3gBlqxQWBNtqEF1GwW/09WtflA+xpU4blWFT3yjJSfVXO
xRY4doSMXAPzLYDj+pG4
=HKDP
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/517a762d.8000...@irisa.fr

Re: libcommons-jexl2-java

[Olivier Sallou]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 04/26/2013 05:09 PM, Emmanuel Bourg wrote:
 Olivier,

 Please update your working copy, I've fixed the issues we identified
 (the missing classpath and the wrong jar in /usr/share/java). I've also
 uploaded a new version on mentors.debian.net.
I have updated from repo but it ends with an error with your update of
rules.

mh_installjar -plibcommons-jexl2-java -l pom.xml -ncommons-jexl2
target/commons-jexl-2.1.1.jar
rm debian/libcommons-jexl2-java/usr/share/java/commons-jexl.jar
rm: cannot remove
?debian/libcommons-jexl2-java/usr/share/java/commons-jexl.jar?: No such
file or directory
make: *** [binary-post-install/libcommons-jexl2-java] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
status 2



 Let me know how it works for you.

 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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRep1iAAoJEHjcaNsybYQ47hcP/ihidZlAdmxPQlLnh66YCKvR
NhGg5G5um3DLdkQCjR/DaLzLMuSh+zKnVmqzMSrQoWg0jDkM/YeSi8lZYeQRLBBU
bqMDCfmmvuFUCuINJorHm7/K9POoL1xdODRNjsYw9hKWxdYp8snlEpIUVcD3vuWp
7YlJpDmxCbhlZKB5+dNXj8bJgT2m04zpTEr11rA/8Z7imQx5G8cSxGuOvsDuIFqs
N8uV5+YAKz+IAwAavksmJZ/DqKKhJwN6pRtnqYrRzrMTXoso/gQFy1K+7ffosgr+
ulXZfS1CoNHRleGR7XYOwEQ+8MMoOakiSm4mGU7ADr7b9LyV/idX62yCt50ixp36
X+saV5xmhSV7vXuc4yJ2qmWCiZTPK6YDACGPHzdgJE2pEy64luIEc5W1yDZi/dl5
+knTlJZEdjZy7XVzRe8hfrguuwb/nxNIgnNOkOShb0VVwnbuclIkgGyIhENd03ad
JxkxkXxNX+9+eQDGrJrWs/n7+1/ZaMnRhvdsN+m7mtFUoB4qsDoXHew91V63oxyX
gA1mWCnyERX0s2J/L+FJKT5hhaoQR40DYPD3jSk9b+s/Ctsqi7eAmqX3IHftCsu5
t67dnfM4bX0Jfwh1W+w5Z4ZQBQA66MZY++316zTd/lWlYV6zRJkrP8FArAOwxe4V
p7Y2qCLyTdFtdTqX+DO4
=4+lN
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/517a9d62.9000...@irisa.fr

Re: libcommons-jexl2-java

[Olivier Sallou]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


On 04/26/2013 05:29 PM, Olivier Sallou wrote:


 On 04/26/2013 05:09 PM, Emmanuel Bourg wrote:
  Olivier,

  Please update your working copy, I've fixed the issues we identified
  (the missing classpath and the wrong jar in /usr/share/java). I've also
  uploaded a new version on mentors.debian.net.
 I have updated from repo but it ends with an error with your update of
 rules.
The error is after your rename of jexl to jexl2. You do not remove the
correct file.

 mh_installjar -plibcommons-jexl2-java -l pom.xml -ncommons-jexl2
 target/commons-jexl-2.1.1.jar
 rm debian/libcommons-jexl2-java/usr/share/java/commons-jexl.jar
 rm: cannot remove
 ?debian/libcommons-jexl2-java/usr/share/java/commons-jexl.jar?: No such
 file or directory
 make: *** [binary-post-install/libcommons-jexl2-java] Error 1
 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
 status 2



  Let me know how it works for you.

  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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJRep4sAAoJEHjcaNsybYQ4TyMP/0XgMh2MbE/ddMM2HVB3V4pD
wYANUGHSoxkKls3B6sx5bgM8TvQ5oXzTlxQZGnES5gNkkFoB1w4MmCJ1N7qNYyjI
GYscBrtL+637cFopnCTn6IuT1z2sAbJWb8pdf0ejQMzMJLaQ0Aqc5elc555zRMyl
eiqAgaEy6pROWeiDlVsrig9uBIERPV2cxl3uBcJQGUclVnYP7FbPcCQE3cQVOksG
4JlrR09F2aPwjMv2E0CLMFcQOB1QVPy4hxVXdtBuYcXgI2MhkAAVvkklHWk9buCp
sMIcHTDJdTZqnv+8c+eDosmuGwDMUaaoLrfiu6/EA6fqoHmT4ARW9AhcntVfCUyn
XJEHBwUaafy/HgzDgwiRk8bE9fNKnrtYyq2PLQZBAL44bwFo4hfFNgIBNhDeSkzI
SZcnYIHBR70x5GtSHBkq8cHAEAAnTVDjjm7v6fyuc6+mB67zG6r1z6YE51X+ECID
2FYGRwrOfTYs5mTcfDcelLfEGZrMFIIMDWyywLfvykBYPllhdk1mEqMiCESaflcz
iQg98SVgV1i+fhq/TxlyvOP+Bg+6nbe3TvD6b1rdzcMaQ+tXwGKmt+5/ZX3Wwe6Z
y82TEe7pbixFQWBMlIh2KhvKdPy8Jyb2757938VM0oVkdpIukKudKweHC0Dee2+l
ha01F8oKCGZyODbJD53x
=1xWw
-END PGP SIGNATURE-

libcommons-jexl2-java

[Olivier Sallou]

Hi,
do you know if there is someone working on libcommons-jexl2-java ?

I saw a recent mail talking about it [0] and I need it for picard-tools
package.

[0] http://www.mail-archive.com/debian-java@lists.debian.org/msg17794.html

thanks

Olivier

-- 


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

Re: Java packaging tools in Fedora?

[Olivier Sallou]

Le 10/30/12 1:32 PM, Thomas Koch a écrit :
 Hi,

 does anybody know how java packaging is done on the other side? What tools, 
 policies does Fedora has? Could you point me to the related websites?

 Thank you,

 Thomas Koch, http://www.koch.ro
One bad point for Java packaging on Fedora is many Java packages are
in JPackage repository instead of Fedora official repo.
This leads to many issues on dependencies, often not present in Fedora repo.

Olivier



-- 
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-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/508fcce6.6080...@irisa.fr

Clojure package missing

[Olivier Sallou]

Hi,
when looking at sid page for clojure [0], page exists but refer no
binary nor source. It does not either specify maintainers etc...
clojure1.4 is correct and specifies that debian-java are the maintainers
for this package, so I suppose that you are also the maintainers for
closure (which may not exist or be a virtual resource).

In squeeze, package is correct.

I don't know if this is a mirroring/update/removal issue, or an upload issue

[0] http://packages.debian.org/sid/clojure


Olivier

-- 
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-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507bf4e6.2050...@irisa.fr

Re: Clojure package missing

[Olivier Sallou]

Le 10/15/12 1:41 PM, Niels Thykier a écrit :
 On 2012-10-15 13:35, Olivier Sallou wrote:
 Hi,
 when looking at sid page for clojure [0], page exists but refer no
 binary nor source. It does not either specify maintainers etc...
 clojure1.4 is correct and specifies that debian-java are the maintainers
 for this package, so I suppose that you are also the maintainers for
 closure (which may not exist or be a virtual resource).

 In squeeze, package is correct.

 I don't know if this is a mirroring/update/removal issue, or an upload issue

 [0] http://packages.debian.org/sid/clojure


 Olivier

 Hi,

 I suspect it is because clojure was renamed to clojure1.4 (in
 sid/Wheezy) and the website is not probably handling packages only
 available in Stable.
Probably, I see other packages having the same issue.
Should this be raised as a bug against website (or forwarded to
Debian-devel) ? This is confusing when looking for a package.

Olivier

 Accoriding to dak:
 $ dak ls -S clojure clojure1.4
clojure | 1.1.0+dfsg-1 |stable | source, all
 clojure1.4 | 1.4.0+dfsg-2 |   testing | source, all
 clojure1.4 | 1.4.0+dfsg-2 |  unstable | source, all

 (actually there is also a clojure1.2 in unstable and testing).

 ~Niels



-- 
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-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/507bfc4e.8020...@irisa.fr

Re: need help with maven helper

[Olivier Sallou]

Le 9/3/12 8:43 PM, Ludovic Claude a écrit :
 Hello,

 After reading again the original question, I think that it would be
 better to keep snappy-java as the artifact id, but pin the version
 number to 1.0.3. You would achieve it with this rule:

 org.xerial.snappy snappy-java jar s/1\.0\.3.*/1.0.3/ * *

We (debianmed) gonna keep artifact id different to avoid the generic
debian link to be linked to snappy-java.
snappy1.0.3-java must not conflict with snappy-java, we need to use this
specific version (old) for a package.

Your tip worked fine, thanks for your help.

 Ludovic

 On 09/01/2012 12:42 PM, Ludovic Claude wrote:
 Hello,

 The packaging in Maven is jar, not bundle, so you need to use this value
 to get a match:

 org.xerial.snappy s/snappy-java/snappy1.0.3-java/ jar s/.*/debian/ * *

 Ludovic

 On 08/31/2012 09:15 AM, olivier.sal...@codeless.fr wrote:
 Le 8/31/12 1:12 AM, Ludovic Claude a écrit :
 Hello,

 You should use this rule instead. It's a substitution you want to do,
 and the format use is similar to standard Unix sed command.

 org.xerial.snappy s/snappy-java/snappy1.0.3-java/ bundle s/.*/debian/ * *
 Unfortunatly, this does not work.
 My generated pom by maven helper is still like:

 ^ImodelVersion4.0.0/modelVersion
 ^IgroupIdorg.xerial.snappy/groupId
 ^IartifactIdsnappy-java/artifactId
 ^Iversion1.0.3-rc3/version
 ^Ipackagingjar/packaging
 ^I
 ^InameSnappy for Java/name
 ^IdescriptionCompression/decompression library/description
 ^Iproperties
 ^I^Iproject.build.sourceEncodingUTF-8/project.build.sourceEncoding
 ^I^Idebian.mavenRulesorg.xerial.snappy snappy-java jar 1.0.3-rc3 *
 */debian.mavenRules
 ^I^Idebian.originalVersion1.0.3-rc3/debian.originalVersion
 ^I^Idebian.packagelibsnappy1.0.3-java/debian.package
 ^I/properties
 

 The artifact id is not modified. And files are installed in
 /usr/share/maven-repo/org/xerial/snappy/snappy-java/...

 Olivier

 Ludovic

 On 08/29/2012 11:07 AM, Olivier Sallou wrote:
 Hi,
 I need some help with maven helper.
 I need to rename the artifact id of the package library.
 In pom.xml, artifactId is snappy-java, and I need to rename it to
 snappy1.0.3-java (with version 1.0.3-rc3)

 What I expect is to get maven data in
 /usr/share/maven-repo/org/xerial/snappy/snappy1.0.3-java/

 However I fail to do so. I updated maven.rules (see below) but file name
 is correct only in /usj.

 I tried to patch the pom.xml to set correct artifactid but in this case,
 I have a build error when trying to unset patches as maven helper
 modifies the pom.xml

 Any hint on how I could do that?

 Thanks

 Olivier

 In my maven.rules:
 org.xerial.snappy snappy1.0.3-java bundle s/.*/debian/ * *

 Package content:
 drwxr-xr-x root/root 0 2012-08-29 09:43
 ./usr/share/maven-repo/org/xerial/snappy/snappy-java/
 drwxr-xr-x root/root 0 2012-08-29 09:43
 ./usr/share/maven-repo/org/xerial/snappy/snappy-java/1.0.3-rc3/
 -rw-r--r-- root/root  1287 2012-08-29 09:43
 ./usr/share/maven-repo/org/xerial/snappy/snappy-java/1.0.3-rc3/snappy-java-1.0.3-rc3.pom
 -rw-r--r-- root/root 23781 2012-08-29 09:43
 ./usr/share/maven-repo/org/xerial/snappy/snappy-java/1.0.3-rc3/snappy-java-1.0.3-rc3.jar
 drwxr-xr-x root/root 0 2012-08-29 09:43
 ./usr/share/maven-repo/org/xerial/snappy/snappy-java/debian/
 -rw-r--r-- root/root  1284 2012-08-29 09:43
 ./usr/share/maven-repo/org/xerial/snappy/snappy-java/debian/snappy-java-debian.pom
 drwxr-xr-x root/root 0 2012-08-29 09:43 ./usr/share/java/
 lrwxrwxrwx root/root 0 2012-08-29 09:43
 ./usr/share/maven-repo/org/xerial/snappy/snappy-java/debian/snappy-java-debian.jar
 - ../1.0.3-rc3/snappy-java-1.0.3-rc3.jar
 lrwxrwxrwx root/root 0 2012-08-29 09:43
 ./usr/share/java/snappy1.0.3-java.jar -
 ../maven-repo/org/xerial/snappy/snappy-java/1.0.3-rc3/snappy-java-1.0.3-rc3.jar
 


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




-- 
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-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5045ad28.2060...@irisa.fr

need help with maven helper

[Olivier Sallou]

Hi,
I need some help with maven helper.
I need to rename the artifact id of the package library.
In pom.xml, artifactId is snappy-java, and I need to rename it to
snappy1.0.3-java (with version 1.0.3-rc3)

What I expect is to get maven data in
/usr/share/maven-repo/org/xerial/snappy/snappy1.0.3-java/

However I fail to do so. I updated maven.rules (see below) but file name
is correct only in /usj.

I tried to patch the pom.xml to set correct artifactid but in this case,
I have a build error when trying to unset patches as maven helper
modifies the pom.xml

Any hint on how I could do that?

Thanks

Olivier

In my maven.rules:
org.xerial.snappy snappy1.0.3-java bundle s/.*/debian/ * *

Package content:
drwxr-xr-x root/root 0 2012-08-29 09:43
./usr/share/maven-repo/org/xerial/snappy/snappy-java/
drwxr-xr-x root/root 0 2012-08-29 09:43
./usr/share/maven-repo/org/xerial/snappy/snappy-java/1.0.3-rc3/
-rw-r--r-- root/root  1287 2012-08-29 09:43
./usr/share/maven-repo/org/xerial/snappy/snappy-java/1.0.3-rc3/snappy-java-1.0.3-rc3.pom
-rw-r--r-- root/root 23781 2012-08-29 09:43
./usr/share/maven-repo/org/xerial/snappy/snappy-java/1.0.3-rc3/snappy-java-1.0.3-rc3.jar
drwxr-xr-x root/root 0 2012-08-29 09:43
./usr/share/maven-repo/org/xerial/snappy/snappy-java/debian/
-rw-r--r-- root/root  1284 2012-08-29 09:43
./usr/share/maven-repo/org/xerial/snappy/snappy-java/debian/snappy-java-debian.pom
drwxr-xr-x root/root 0 2012-08-29 09:43 ./usr/share/java/
lrwxrwxrwx root/root 0 2012-08-29 09:43
./usr/share/maven-repo/org/xerial/snappy/snappy-java/debian/snappy-java-debian.jar
- ../1.0.3-rc3/snappy-java-1.0.3-rc3.jar
lrwxrwxrwx root/root 0 2012-08-29 09:43
./usr/share/java/snappy1.0.3-java.jar -
../maven-repo/org/xerial/snappy/snappy-java/1.0.3-rc3/snappy-java-1.0.3-rc3.jar


-- 
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-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/503ddbcb.5000...@irisa.fr

Re: Fwd: any idea how to move dir in SVN?

[Olivier Sallou]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Le 7/10/12 7:59 AM, tony mancill a écrit :
 On 07/09/2012 02:31 AM, Niels Thykier wrote:
 On 2012-07-09 11:25, Olivier Sallou wrote:

 Hi,
 the package libbzip2-java is wrongly named libjbib2-java in SVN.
 Any idea on how to rename it on SVN ?

 The svn mv would need to get the whole trunk/packages section, which I
 dont have and don't really want to download.
 Or if someone already has the whole section downloaded, would you mind
 renaming the directory?

 Thanks

 Olivier


 Hi,

 I think svn move URL1 URL2 should do (see svn help move)

 ~Niels


 Hi Olivier,

 Niels' solution is the best in this situation, but another way to go
 about it is to use the --depth immediates option to check out just the
 trunk and the first level of directories underneath it. That would be
 useful if you wanted to rename a number of directories as part of a
 single commit.
This is perfect, thanks !



 Cheers,
 tony




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



-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJP+84rAAoJEHjcaNsybYQ4Ye8P/iPnXdr1FlRwtEKrREwLP0EJ
u7ScKzAkQuxlVxuU1p9hgejzgBmZeiXH6XCGpOVuAz41DQ+Dx2ZewMIIacManPdI
gj4KYasYmj/MsgoOvGTHrKuVr1SChfpBe+G8gHJRR3VsF8Q2DpMNB12jUxTa16KO
nrsOpt163OsMEXP2L5xs1e7ucuGH3zzmpl0VPG/HKQKgwogpkrRGXB3tEQDGHKwc
wlVzcClgslKa7iqQJx/Kr9UpgzfyxduYgS3ZlxIp+vd76+nh1yH8YkU30z3lkwsT
zPcosYtXP5D68ZkPPzIz5+0OvXpa/ELu4pa7UujDsKVa+qoBvrOIqevomvgOPmf2
mVa3ZxY/FmmIWRXa24k04uN+Ggh1uwPS9ddBd2eJXAwadf9/GHIm2wtl4VukSv2V
Urkkk5vf9+1b4Vl9F8RxGUYpFcOaDft0j/gh3XeVOxQbWvW0hq634RnArtfIK5Ho
p1UNiS+9Cte/1bk56fVzr3I81We5MpV9MzZg6knpwL72nmWoIetiAa/YpVh8vFtn
ueMz2i+i/oOIoe31+F9QTskMLMF3CC89SU9sb+fIPqtnLJ5u4rBWiYpibStq+52l
Nco2Mdtki0xlmwoc35N5lqstNsxNLcnqYMCCbes54EWXWaRhbCxgdxgdB3KXprg/
wsLAGzmrtMn/uyvojAdM
=PJSD
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ffbce2c.1040...@irisa.fr

Fwd: any idea how to move dir in SVN?

[Olivier Sallou]

Hi,
the package libbzip2-java is wrongly named libjbib2-java in SVN.
Any idea on how to rename it on SVN ?

The svn mv would need to get the whole trunk/packages section, which I
dont have and don't really want to download.
Or if someone already has the whole section downloaded, would you mind
renaming the directory?

Thanks

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-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ffaa389.8060...@irisa.fr

use of json.org in biojava3-ws

[Olivier Sallou]

Hi,
biojava3 makes use of json.org library.
this library is not packaged in  Debian. After a google, I saw old posts
saying that library is (was?) not compliant regarding its license [0].
Though, after a quick look on their web site I do not see any restriction.

Can anyone tell me is something wrong with their code for not being
packaged?



[0] http://www.json.org/license.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-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fc4ba36.8090...@irisa.fr

libquartz-java switch to libquartz2-java

[Olivier Sallou]

Hi Mathieu,
do you plan to switch libquartz-java to libquartz2-java to solve API
incompatibility issue ? And if yes when do you plan to do so?
I see library has already switched to testing, maybe I should have
created a blocking bug after my first mail to prevent this, waiting to
decide what to do.

Thanks

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-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f9508c7.8030...@irisa.fr

Re: libquartz-java v2 has incomptabilities with previous version

[olivier sallou]

2012/4/16 Mathieu Malaterre mathieu.malate...@gmail.com

 [CC me please]

 Dead Java-gurus,

   Could someone please let me know how can I check whether or not a
 java jar is compatible with a past version ?

   Apparently libquartz-java 2.x is not compatible with 1.x version. Am
 I reading the following correctly:

 http://mvnrepository.com/artifact/org.quartz-scheduler/quartz

   Shouldn't all version ve compatible ?


You can find migration info in upstream site only...
http://quartz-scheduler.org/documentation/quartz-2.x/migration-guide

But even backward compatibiliy jar file provided with new version does not
solve all issues. And it also requires additional jar files in the path
(the backward one and slf4j-api too).

Olivier



 Thanks !

 On Mon, Apr 16, 2012 at 6:23 PM, olivier.sal...@codeless.fr
 olivier.sal...@codeless.fr wrote:
 
  Hi Mathieu,
  I am forwarding this email to you directly as you are the one who
 uploaded latest release of libquarzt-java.
  I sent the mail first to pkg-java-maintainers mailing.
 
  Thanks
 
  Olivier
 
   Message original 
  Sujet: libquartz-java v2 has incomptabilities with previous version
  Date : Fri, 13 Apr 2012 15:13:52 +0200
  De : Olivier Sallou olivier.sal...@irisa.fr
  Répondre à : osal...@debian.org
  Pour : pkg-java-maintain...@lists.alioth.debian.org
 
 
  Hi,
  recent upload of quartz v2.1.4 in sid created some issue in one of my
  package and will certainly impact many other packages.
  The change from v1.x to 2.x introduced some incompatibilities in APIs.
  There is a backward compatibility jar but it does not solve all problems.
 
  This result in failure even in common usages.
 
  Shouldn't package be named  libquartz2-java to keep compatibility with
  packages depending on previous version ? and as such supporting dual
  versions ?
 
 
  Olivier
 
 
  --
 
  gpg key id: 4096R/326D8438  (keyring.debian.org)
  Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438
 
 



 --
 Mathieu




-- 

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

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

Re: Help with java package (beast-mcmc) needed

[Olivier Sallou]

Le 1/10/12 10:59 AM, Andreas Tille a écrit :
 Hi Sylvestre,

 On Tue, Jan 10, 2012 at 06:09:53AM +0100, Sylvestre Ledru wrote:
 Exception in thread main java.lang.NoClassDefFoundError: 
 jam/console/ConsoleApplication
 Usually, this kind of problem is due to the CLASSPATH not containing
 jam.jar
 $ grep jam debian/rules
 export CLASSPATH := 
 $(DEBJAR)/itext.jar:lib/beagle.jar:lib/mpj.jar:lib/org.boehn.kmlframework_20090320.jar:$(DEBJAR)/junit4.jar:$(DEBJAR)/figtree.jar:lib/colt.jar:lib/options.jar:lib/mtj.jar:$(DEBJAR)/jam.jar:$(DEBJAR)/jdom1.jar:$(DEBJAR)/jebl.jar:$(DEBJAR)/commons-math.jar

 As far as I understood you do not need to explicitely set CLASSPATH at
 runtime (and it would not explain why the other executables are
 perfectly finding the needed jars.

For classpath, at runtime, all depends on how jar is generated. If it
contains a MANIFEST file with the classpath defined, it will be able to
find the JARS (supposing that libraries path are the same). If it dies
not contains the classpath in the MANIFEST file, classpath must be set
explicitly to each jar file in the command line (usually via a wrapper
shell)

Olivier
 Any further hints?

 Kind regards and thanks anyway

  Andreas.


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

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



-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f0c1aa5.5090...@irisa.fr

Re: Help with maven based package needed (dcm4che)

[Olivier Sallou]

Hi,
pom should be patched I think to specify yourself the Manifest data.
Unfortunatly, this week I am not at home/work, I can't have a look 
(intermittent internet access).

I can have a look next week if you want.

Olivier

- Mail original -
 De: Andreas Tille andr...@an3as.eu
 À: Debian Med Project List debian-...@lists.debian.org
 Cc: Debian Java List debian-java@lists.debian.org
 Envoyé: Mardi 19 Avril 2011 18:12:28
 Objet: Re: Help with maven based package needed (dcm4che)
 Hi Olivier,
 
 On Tue, Apr 19, 2011 at 06:00:16PM +0200, Olivier Sallou wrote:
  In the maven Jar creation step, a Manifest description should be
  present. Maybe it refers a Manifest file instead of specifying its
  contents dynamically. Either Manifest file is not present at all, or
  it is in src but not copied in target dir (compilation copies only
  java classes, not other files).
 
 Your analysis makes sense because I at first created the packaging
 stuff
 using maven_helper. Afterwards I fetched an independent source archive
 via uscan which was not prepared with maven_helper and thus might be
 missing those files.
 
 But what will be the solution for this problem? I'd consider the uscan
 method to get the source as my prefered way to go. Is it possible to
 tweak this Manifest file in via a quilt patch somehow?
 
 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/20110419161228.gd22...@an3as.eu


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2075866926.1880790.1303232260166.javamail.r...@zmbs1.inria.fr

Re: How to apply maven build system (Was: How to use Debian packaged freehep instead of upstream provided freehep.jar)

[Olivier Sallou]

Hi,
the plugin must be under other tags.
Example:
build
plugins

plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
configuration
source1.5/source
target1.5/target
/configuration
/plugin


So your pom should look like:

?xml version=1.0 encoding=UTF-8?
project xmlns=http://maven.apache.org/POM/4.0.0; 
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd;

modelVersion4.0.0/modelVersion
groupIdpatristic/groupId
artifactIdpatristic/artifactId
version1.0.0-SNAPSHOT/version
namePatristic/name

build
plugins

   plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-compiler-plugin/artifactId
   version2.1/version
   configuration
   source1.5/source
   target1.5/target
   /configuration
   /plugin

/plugins
/build


dependencies
dependency
groupIdorg.freehep/groupId
artifactIdfreehep-graphics2d/artifactId
version2.1.3/version
/dependency
/dependencies
/project

Olivier

Le 2/18/11 8:55 AM, Andreas Tille a écrit :

Hi,

On Thu, Feb 17, 2011 at 07:49:52PM +0100, Thomas Zeeman wrote:

It means the application is using two features of java (annotations and 
generics to be precise) which are only supported in Java 5+. To fix this you 
need to set the source property of the maven-compiler-plugin in the build 
section of the pom to 1.5. It might also be necessary to set the target to 1.5 
in this case. I.e like this:

plugin
groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-compiler-plugin/artifactId
 version2.1/version
 configuration
 source1.5/source
 target1.5/target
 /configuration
 /plugin

Please excuse for my ignorance but it seems that I need more detailed
advise.  I applied this to the previosely suggested pom.xml (see
attachment) but now I get

$ $ mvn package
[INFO] Scanning for projects...
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] Error building POM (may not be this project's POM).


Project ID: unknown
POM Location: 
/home/tillea/debian-maintain/todo/0_debian-med_todo/0phylogeny/patristic/maven/patristic-20100817/pom.xml

Reason: Parse error reading POM. Reason: Unrecognised tag: 'plugin' (position: START_TAG 
seen .../name\n\nplugin... @10:13)  for project unknown at 
/home/tillea/debian-maintain/todo/0_debian-med_todo/0phylogeny/patristic/maven/patristic-20100817/pom.xml



Or update to a more recent version of maven or the compiler plugin. They've 
updated the default for source and target to 1.5 for some time now.

I also have no idea how to follow this hint:

$ apt-cache policy maven2
maven2:
   Installiert: 2.2.1-5
   Kandidat:2.2.1-5
   Versionstabelle:
  *** 2.2.1-5 0
 501 http://debian.tu-bs.de/debian/ testing/main amd64 Packages
  50 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
 100 /var/lib/dpkg/status

What more recent version do you mean?

Thanks for your patience

   Andreas.



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