Re: Backporting libguava-java to Jessie
Le 12/10/2016 à 18:12, Andreas Tille a écrit : > It would really help if you could upload guava-libraries to Jessie > backports. Done! Emmanuel Bourg
Re: Backporting libguava-java to Jessie
Hi Emmanuel, On Wed, Oct 12, 2016 at 03:05:41PM +0200, Emmanuel Bourg wrote: > > libplexus-compiler-java in stretch and jessie-backports installs generic > artifacts with the '2.x' version instead of 'debian'. Here > maven-bundle-plugin 2.5.4 requires the 'debian' version and can't find > it in the backported package. > > The real is why do you use maven-bundle-plugin 2.5.4 instead of the > version 2.3.7 in Jessie? I rebuilt guava-libraries on Jessie without > modification and it worked fine. Let me know if you want me to upload it. It would really help if you could upload guava-libraries to Jessie backports. Thanks a lot Andreas. -- http://fam-tille.de
Re: Backporting libguava-java to Jessie
Le 11/10/2016 à 14:02, Andreas Tille a écrit : > Any help would be welcome Hi Andreas, libplexus-compiler-java in stretch and jessie-backports installs generic artifacts with the '2.x' version instead of 'debian'. Here maven-bundle-plugin 2.5.4 requires the 'debian' version and can't find it in the backported package. The real is why do you use maven-bundle-plugin 2.5.4 instead of the version 2.3.7 in Jessie? I rebuilt guava-libraries on Jessie without modification and it worked fine. Let me know if you want me to upload it. Emmanuel Bourg
Backporting libguava-java to Jessie
Hi, I need to backport libguava-java to Jessie since version 19.0 is needed to enable backporting the Debian Med package mhap. When trying to build libguava-java version 19.0 under Jessie I noticed that some maven artifacts of some Build-Depends are missing in the Jessie versions. Thus I decided to backport to of libguava-java's Build-Depends. While plexus-compiler went fine I finally stumbled upon the backport of maven-bundle-plugin. When trying to build under Jessie I get: [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 0.913 s [INFO] Finished at: 2016-10-11T08:58:52+00:00 [INFO] Final Memory: 9M/148M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) on project maven-bundle-plugin: Execution default-compile of goal org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile failed: Plugin org.apache.maven.plugins:maven-compiler-plugin:2.5.1 or one of its dependencies could not be resolved: The following artifacts could not be resolved: org.codehaus.plexus:plexus-compiler-api:jar:debian, org.codehaus.plexus:plexus-compiler-manager:jar:debian, org.codehaus.plexus:plexus-compiler-javac:jar:debian: Cannot access central (https://repo.maven.apache.org/maven2) in offline mode and the artifact org.codehaus.plexus:plexus-compiler-api: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/PluginResolutionException dh_auto_build: /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/default-java/lib/tools.jar -Dmaven.home=/usr/share/maven -Dmaven.multiModuleProjectDirectory=/build/maven-bundle-plugin-2.5.4 -Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/build/maven-bundle-plugin-2.5.4/debian/maven.properties org.codehaus.plexus.classworlds.launcher.Launcher -s/etc/maven/settings-debian.xml -Ddebian.dir=/build/maven-bundle-plugin-2.5.4/debian -Dmaven.repo.local=/build/maven-bundle-plugin-2.5.4/debian/maven-repo package javadoc:jar javadoc:aggregate -DskipTests -Dnotimestamp=true -Dlocale=en_US returned exit code 1 debian/rules:6: recipe for target 'build' failed make: *** [build] Error 1 >From my naive point of view this looks as if plexus-compiler is the problematic bit here. I can confirm that the build was just using the backported libplexus-compiler-java_2.4-3~bpo8+1_all.deb which I kept in a local mirror. So the question is: How can I successfully build either maven-bundle-plugin_2.5.4-3 on Jessie or how can I build guava-libraries_19.0 directly on Jessie (without backporting the Build-Depends). Any help would be welcome Andreas. -- http://fam-tille.de
java for jessie
At least for past releases some support of java is available on every architecture, not only for release architectures. A big advantage is that you don't have to use architecture specific build dependencies, but usually packages building architecture specific binary packages just work. That did change for the hurd recently, but hopefully is fixable. I would like to keep it this way, because it makes the work for porters easier. GCJ still seems to be good enough to build jni bindings. Providing security updates for released versions is tedious, and not many people are working on getting these updates into the oldstable and stable releases. oldstable had only one openjdk version, stable unfortunately has two openjdk versions which need updates four times a year. For jessie there should be only one openjdk version in the release. Looking at the current state, this is openjdk-7, so what needs to be done, if we want to only ship openjdk-8? - build openjdk-8 on the architectures that openjdk-7 builds on. I don't think that dropping java support on some architecture for the release will be an option, this affects some more source packages in the archive. - have a test rebuild with openjdk-8, preferable using the zero interpreter so we may catch issues on the majority of release architectures. - make sure that at least the openjdk jtreg test results look reasonable and we don't see any regressions between 7 and 8. It would be interesting to compare test TCK results for those who have access to this testsuite. I would like to avoid having openjdk-8 in unstable until we have answers to these questions. It seems to be too easy to upload packages to unstable built using openjdk-8. I'll be at Debconf for the java BoF, but maybe most of the issues can be resolved even before Debconf. Matthias -- 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/53c54d31.2080...@debian.org
Re: java for jessie
Le 15/07/2014 17:48, Matthias Klose a écrit : Providing security updates for released versions is tedious, and not many people are working on getting these updates into the oldstable and stable releases. oldstable had only one openjdk version, stable unfortunately has two openjdk versions which need updates four times a year. For jessie there should be only one openjdk version in the release. I'd like to help with the openjkd-8 updates in Jessie. Looking at the current state, this is openjdk-7, so what needs to be done, if we want to only ship openjdk-8? openjdk-8 build depends on openjdk-7, how would we do if we want to ship only openjdk-8 in Jessie? We change openjdk-8 to build depend on itself and keep openjdk-7 in unstable only to bootstrap openjdk-8 on new architectures? - build openjdk-8 on the architectures that openjdk-7 builds on. I don't think that dropping java support on some architecture for the release will be an option, this affects some more source packages in the archive. - have a test rebuild with openjdk-8, preferable using the zero interpreter so we may catch issues on the majority of release architectures. We've done a rebuild on amd64 with Hotspot in April. I fixed several issues and filed bugs for the others: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openjdk-8-transition;users=debian-java@lists.debian.org We are now down to 36 packages failing to build with openjdk-8, 10 have a pending fix upstream. - make sure that at least the openjdk jtreg test results look reasonable and we don't see any regressions between 7 and 8. It would be interesting to compare test TCK results for those who have access to this testsuite. Did you get the TCK for Java 8 yet? I would like to avoid having openjdk-8 in unstable until we have answers to these questions. It seems to be too easy to upload packages to unstable built using openjdk-8. All maintainers here build packages with openjdk-7 in a clean chroot, I don't think that's an issue. And if someone uploads a package using the Java 8 class format Lintian will report it. So the risk to wreak havoc in the archive by uploading openjdk-8 to unstable is quite low. Emmanuel Bourg -- 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/53c5ca45.1000...@apache.org
