Re: Bug#786895: lintian: incompatible-java-bytecode-format warning needs update for Java 1.7
On Tue, May 26, 2015 at 05:45:46PM +0200, Emmanuel Bourg wrote: Le 26/05/2015 16:52, Rene Engelhard a écrit : I think we should decide what our Java baseline is and how it affects release archs_before_ changing this. The best we can do I think is to identify the applications that should work with GCJ (Ant and LibreOffice for example) and ensure their dependencies are still compatible with the Java 5 API. But as Niels Well, for some LO subpackages it's already too late (*commons* used b -report-builder apparently does use 1.6+-only now), but yeah. stated it's impossible to keep the Java 5 compatibility everywhere (Java 9 will even be unable to generate Java 5 bytecode [1]). I know, there at least we need to kill gcj support. But until then. Or we decide we don't care ab out 1.5/gcj now. Explicitely. Regards, Rene -- 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/20150527094158.gd31...@rene-engelhard.de
Re: ITP: kafka -- Distributed, partitioned, replicated commit log service
On Thu, 21 May 2015 15:56:44 -0500 Brandon Bradley bradleytas...@gmail.com wrote: Package: wnpp Owner: Brandon Bradley bradleytas...@gmail.com Severity: wishlist * Package name: kafka Version : 0.8.2.1 * URL : http://www.example.org/ * License : Apache 2.0 Programming Lang: Java, Scala Description : Distributed, partitioned, replicated commit log service Hi Brandon, I'm cross-posting your ITP for kafka to the debian-java list. I believe there may be interest in helping and/or co-maintaining the package. Cheers, tony signature.asc Description: OpenPGP digital signature
Re: Bug#786895: lintian: incompatible-java-bytecode-format warning needs update for Java 1.7
On Wed, 27 May 2015, Rene Engelhard wrote: I know, there at least we need to kill gcj support. But until then. Or we decide we don't care ab out 1.5/gcj now. Explicitely. On Wed, 27 May 2015, Markus Koschany wrote: Niels and Emmanuel have already pointed out the most important facts why we can't support GCJ forever. My Java baseline is: OK, let me rephrase my intent again. I think it’s fair to drop GCJ support. But please do not so for as long as doing that breaks GCJ architectures. That means, for all affected packages, do maintainer uploads or NMUs *first* that: - change the B-D to require default-jdk only on an architecture whitelist (do not use a blacklist, that makes bootstrapping new architectures impossible_) - change d/rules, d/control to only build the *-java packages on those architectures - ensure these changes are in sid *first* Thanks! bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general -- 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/alpine.deb.2.11.1505271502540.12...@tglase.lan.tarent.de
Re: Bug#786895: lintian: incompatible-java-bytecode-format warning needs update for Java 1.7
Le 27/05/2015 15:41, Jan Henke a écrit : I think gcj serves one single purpose only at this point in time: Bootstrapping during the OpenJDK build. This is no longer true with OpenJDK 8 unfortunately, Java 7 is now required. -- 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/5565cf4a.4040...@apache.org
Re: Bug#786895: lintian: incompatible-java-bytecode-format warning needs update for Java 1.7
Am 27.05.2015 um 15:04 schrieb Thorsten Glaser: On Wed, 27 May 2015, Rene Engelhard wrote: I know, there at least we need to kill gcj support. But until then. Or we decide we don't care ab out 1.5/gcj now. Explicitely. On Wed, 27 May 2015, Markus Koschany wrote: Niels and Emmanuel have already pointed out the most important facts why we can't support GCJ forever. My Java baseline is: OK, let me rephrase my intent again. I think it’s fair to drop GCJ support. But please do not so for as long as doing that breaks GCJ architectures. That means, for all affected packages, do maintainer uploads or NMUs *first* that: - change the B-D to require default-jdk only on an architecture whitelist (do not use a blacklist, that makes bootstrapping new architectures impossible_) - change d/rules, d/control to only build the *-java packages on those architectures - ensure these changes are in sid *first* Thanks! bye, //mirabilos Hi, even with just being someone lurking on the ML for some time I still would like to voice my opinion on this matter. I think gcj serves one single purpose only at this point in time: Bootstrapping during the OpenJDK build. I concur with the voiced opinion, that gcj is from a piratical perspective not a working JVM any more. As unfortunate it is for the architectures without OpenJDK, I also think gcj does not work as default-jdk either on those architectures. As much as it is sad to write this, I fully agree at this point Java should be dropped from those architectures without an OpenJDK build. It is better to have no installable default-jdk, than a silently broken JVM that is not really usable with current Java applications. Best regards, Jan Henke signature.asc Description: OpenPGP digital signature
Re: Bug#786895: lintian: incompatible-java-bytecode-format warning needs update for Java 1.7
On 27.05.2015 11:41, Rene Engelhard wrote: On Tue, May 26, 2015 at 05:45:46PM +0200, Emmanuel Bourg wrote: Le 26/05/2015 16:52, Rene Engelhard a écrit : I think we should decide what our Java baseline is and how it affects release archs_before_ changing this. I think changing the Lintian warning does not affect the current Java situation on ports where GCJ is the default JDK. The bug report is a mere request to sync Lintian with reality again. Most people will just override the tag or ignore it because they have no other choice. Newer applications and libraries will introduce new Java features. The answer to that is to move with the times and to present Debian as a modern operating system which still cares about backwards compatibility. Niels and Emmanuel have already pointed out the most important facts why we can't support GCJ forever. My Java baseline is: * Everyone should try to use the defaults and compile to Java 1.5 bytecode whenever possible. Some packages even work with Java 1.3 like cup. Don't frivolously change that as long as the package works as expected with OpenJDK. * We should communicate loud and clearly that all architectures where OpenJDK is not the default JDK are no primary Java platforms. Applications and libraries may be broken. There are already a number of packages which are and this number will increase over time. Java should be treated as experimental there. I don't believe this issue can be solved on a distribution level. Either a miracle happens and GCJ will be revived or someone has to port OpenJDK to that platform, which seems to be the only viable and reasonable alternative. It is easier than to convince every Java developer out there to support GCJ. * Ensure that packages can be backported to the current stable release, so that they work with the default OpenJDK. Hence my request to change the Lintian warning because Java 1.7 is supported in stable. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: Bug#786895: lintian: incompatible-java-bytecode-format warning needs update for Java 1.7
Am 27.05.2015 um 16:06 schrieb Emmanuel Bourg: Le 27/05/2015 15:41, Jan Henke a écrit : I think gcj serves one single purpose only at this point in time: Bootstrapping during the OpenJDK build. This is no longer true with OpenJDK 8 unfortunately, Java 7 is now required. You can still bootstrap OpenJDK 7 and use that one to bootstrap OpenJDK8. I agree it is getting more difficult to port OpenJDK to architectures without any existing JVM. signature.asc Description: OpenPGP digital signature
Re: Bug#786895: lintian: incompatible-java-bytecode-format warning needs update for Java 1.7
On 05/27/2015 03:41 PM, Jan Henke wrote: Am 27.05.2015 um 15:04 schrieb Thorsten Glaser: On Wed, 27 May 2015, Rene Engelhard wrote: I know, there at least we need to kill gcj support. But until then. Or we decide we don't care ab out 1.5/gcj now. Explicitely. On Wed, 27 May 2015, Markus Koschany wrote: Niels and Emmanuel have already pointed out the most important facts why we can't support GCJ forever. My Java baseline is: OK, let me rephrase my intent again. I think it’s fair to drop GCJ support. But please do not so for as long as doing that breaks GCJ architectures. That means, for all affected packages, do maintainer uploads or NMUs *first* that: - change the B-D to require default-jdk only on an architecture whitelist (do not use a blacklist, that makes bootstrapping new architectures impossible_) - change d/rules, d/control to only build the *-java packages on those architectures - ensure these changes are in sid *first* Thanks! bye, //mirabilos Hi, even with just being someone lurking on the ML for some time I still would like to voice my opinion on this matter. I think gcj serves one single purpose only at this point in time: Bootstrapping during the OpenJDK build. No. It's a direct build dependency for pdftk (but doesn't affect jdk-default). It is used to provide a natively compiled ecj (and I think still ant) to speed up builds on OpenJDK architectures. It is used for bootstrapping, however the replacement to build openjdk on a new architecture without having gcj on that architecture isn't yet implemented: cross-building of openjdk-8 (help would be welcome, it's a packaging task and supposed to be supported upstream). I concur with the voiced opinion, that gcj is from a piratical perspective not a working JVM any more. As unfortunate it is for the architectures without OpenJDK, I also think gcj does not work as default-jdk either on those architectures. As much as it is sad to write this, I fully agree at this point Java should be dropped from those architectures without an OpenJDK build. It is better to have no installable default-jdk, than a silently broken JVM that is not really usable with current Java applications. sure, then please let's drop the mips and mipsel binaries too. These are currently not built anymore for openjdk-8, and I don't see any feedback to improve the situation. The next question is how to define OpenJDK build. There are the Hotspot VM's, the Zero VM and JamVM. The Hotspot VM's and Zero are upstream, however being upstream doesn't mean that these are always buildable (e.g. sparc HotSpot became unbuildable in 7, looks buildable in 8 now; e.g. mips/mipsel based on Zero doesn't build/work). Learning from the attempt to keep a Hotspot port in the packaging (KFreeBSD), it's required to have this maintained upstream. Things rot too fast in the packaging. Other release architectures based on the Zero port are armel, armhf, powerpc, s390x. So the bigger question is, which Zero ports should be removed. From my point of view these are mips and mipsel, and probably others. In any case we will end up with release architectures having no java support -- which is fine, other languages don't provide this either). I didn't look at JamVM for a long time, so maybe somebody else could figure out if this is an option for the current Zero ports. 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/55660174.4000...@debian.org
Re: ITP: kafka -- Distributed, partitioned, replicated commit log service
On 28 May 2015, at 12:06 am, tony mancill tmanc...@debian.org wrote: On Thu, 21 May 2015 15:56:44 -0500 Brandon Bradley bradleytas...@gmail.com wrote: Package: wnpp Owner: Brandon Bradley bradleytas...@gmail.com Severity: wishlist * Package name: kafka Version : 0.8.2.1 * URL : http://www.example.org/ * License : Apache 2.0 Programming Lang: Java, Scala Description : Distributed, partitioned, replicated commit log service Hi Brandon, I'm cross-posting your ITP for kafka to the debian-java list. I believe there may be interest in helping and/or co-maintaining the package. Hi Tony and Brandon. It’s great to hear you are keen on doing some packaging! I’m interested in Kafka as well, but didn’t want to take on another ridiculously large packaging project just yet, in addition to JRuby . There’s been some recent packaging activity on Scala, but I think Gradle is currently broken or requiring a lot of work. Tim. smime.p7s Description: S/MIME cryptographic signature
Bug#787027: ITP: jruby-openssl -- gem for JRuby that emulates the Ruby OpenSSL native library
Package: wnpp Severity: wishlist Owner: Miguel Landaeta nomad...@debian.org * Package name: jruby-openssl Version : 0.9.7 Upstream Author : The JRuby Team * URL : https://github.com/jruby/jruby-openssl * License : EPL-1.0/GPL-2/LGPL-2.1 Programming Lang: Java/Ruby Description : add-on gem for JRuby that emulates the Ruby OpenSSL native library JRuby-OpenSSL is an add-on gem for JRuby that emulates the Ruby OpenSSL native library. . Under the hood uses the Bouncy Castle Crypto APIs. -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. Faith means not wanting to know what is true. -- Nietzsche signature.asc Description: Digital signature
