Re: Trying to compile a package that depends on bouncycastle
On Tue, 15 Jul 2014 23:20:32 +0100, Adam Spragg wrote: Well, thanks for all the help, but now I'm stuck on step the 9th, trying to compile SignApk.java. And I think I'm just going to give up. I'm getting compile errors of the form: SignApk.java:20: error: cannot find symbol import org.bouncycastle.asn1.ASN1ObjectIdentifier; (No java expert here but ...) This BouncyCastle stuff has changed classnames and whatnot between 1.46 and 1.47 or something: http://www.bouncycastle.org/wiki/display/JA1/Porting+from+earlier+BC+releases+to+1.47+and+later To me it looks like your program wants the new stuff, and you've installed the older versions of bc. -- At least that's where I'd be looking further :) Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- BOFH excuse #174: Backbone adjustment -- 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/20140716072833.ge16...@colleen.colgarra.priv.at
Re: Java 9 dropping support for source/target level 1.5
On Wed, 16 Jul 2014, Emmanuel Bourg wrote: Le 16/07/2014 00:07, Rene Engelhard a écrit : This is nonsense. Not yet - not as long we want/need gcj (on some archs). Fair enough. But we already have a lot of packages incompatible with gcj in Jessie. Ugh. If you have time, can you work on getting OpenJDK to work on m68k (using a VM, for easy hacking)? Doko said that there is already code for m68k in OpenJDK itself, but my previous attempts at bootstrapping it all failed, so… (It really would help if one were able to crosscompile the JDK, using .class/.jar files from a native build and needing only the C++ compiler for crossbuilding. Or even, building only the C++ part and copying the .class/.jar part from another system.) As for dropping -target 1.X FSVO X: I know of not-quite-JRE systems that require this for low X, for example Ewe (a runtime for PocketPC, mostly, but also works on Debian and even MirBSD… although there’s still licence for a few files to figure out, so I have not yet packaged it). I would like to know how they could still do that… meh, gcj, probably… bye, //mirabilos -- [16:04:33] bkix: veni vidi violini [16:04:45] bkix: ich kam, sah und vergeigte... -- 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.1407160934140.25...@tglase.lan.tarent.de
Re: Trying to compile a package that depends on bouncycastle
On Wednesday 16 Jul 2014 08:28:33 gregor herrmann wrote: On Tue, 15 Jul 2014 23:20:32 +0100, Adam Spragg wrote: Well, thanks for all the help, but now I'm stuck on step the 9th, trying to compile SignApk.java. And I think I'm just going to give up. I'm getting compile errors of the form: SignApk.java:20: error: cannot find symbol import org.bouncycastle.asn1.ASN1ObjectIdentifier; (No java expert here but ...) This BouncyCastle stuff has changed classnames and whatnot between 1.46 and 1.47 or something: http://www.bouncycastle.org/wiki/display/JA1/Porting+from+earlier+BC+releas es+to+1.47+and+later To me it looks like your program wants the new stuff, and you've installed the older versions of bc. -- At least that's where I'd be looking further :) ABI-incompatible changes without bumping the major version number? And people *use* software from upstreams who work in this way? Well, that makes me feel better about giving up and not looking any further into this at all. I like my eyes in the non-bleeding state they are currently in. Bugs-nuts insane. Fricking Java, man. Adam -- 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/201407160841.32403.a...@spra.gg
Re: Java 9 dropping support for source/target level 1.5
On 15/07/2014 23:55, Matthias Klose wrote: Am 15.07.2014 23:08, schrieb Emmanuel Bourg: This was expected but now it's effective, Java 9 no longer supports source/target level 1.5: http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-July/000972.html So if you update a package and see these settings please bump them to 1.6. It might be interesting to add a Lintian warning when a jar with the class format = 49 is detected, that would mean the package was compiled with a target = 1.5 and will probably fail to build with Java 9. No. Don't do it. This is complete bullshit for Debian at this point. We are trying to prepare a release, working on a possible update to Java 8, and we don't have the resources to work on Java 9 at this time. You seem to have your own agenda, but it doesn't seem to match Debian's agenda. I think that is unfair statement against Emmanuel (especially when adding d-d d-r to the cc list). I sponsored a lot of packages for Emmanuel. He has been doing an impressive work in the Java team [1]. He has been doing most of the maintenance work in the team over the past year and Debian would be a better (technical) place if we had 10 clones of Emmanuel. OpenJDK being a key package in the Java world, it is only fair for him (to try) to be involved in its packaging and to make sure we are as good and fast as some other distros. I think that is his agenda. If he is willing to work on the packaging of 9, so be it. AFAIK, he is a volunteer and it was never on the table to perform this work for Jessie. By the way, I think you should relax about Emmanuel. He just has been trying to help you with OpenJDK 8 packaging when it was stuck. Even if you disagree with his initial approach, he wasn't trying to undermine your work on this package. And please, stop using his ecj mistake to blame him. That is unfair compared to all the work he has done. Cheers, Sylvestre [1] https://qa.debian.org/developer.php?login=ebo...@apache.org Btw, I wish we had to way to list all of his contributions. -- 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/53c62ed6.3020...@debian.org
Re: RFS: openjdk-8/8u5-b13-1 (NEW)
Le 15/07/2014 17:27, Matthias Klose a écrit : Even before you did start, I was telling you on irc that I'll keep the openjdk-8 package as one package, and not splitting it up into different source packages depending on the hotspot version specific for that architecture. You did continue your own way. The hotspot for ppc64 and ppc64el is now integrated in 8u20, that's the reason you don't see a separate hotspot for these architectures. I didn't intend to drop the ppc64 port, I was just unaware of it. Otherwise I'd have tried to support it with a separate tarball just like aarch64. If you remember well I sent you a mail in April to get your feedback on what I had achieved so far, I also called for review on debian-java but you never commented on my work. So I'm a bit stunned to learn 3 months later that you got highly annoyed by the lack of ppc64 support. Asking please give my VCS write access so that I can commit my remaining changes is not going to work for me, giving the history of this packaging and the current situation with ecj. What is going to work to get commit access then? I've done hundreds of updates over the past year and it went well, I find it a bit unfair to be judged on the one update that failed. I did walk though the committ diffs and applied relevant patches. If I did miss any patches, please submit these as bug reports (preferred) or send these as email. I sent a pull request for icedtea-web, is this an acceptable contribution format for you? https://code.launchpad.net/~ebourg/openjdk/icedtea-web/+merge/225908 I don't mind setting up a review process between us, but please don't leave my requests unanswered for weeks, that's very difficult to contribute in this condition. Please don't send any patches which drop the build support for squeeze or wheezy, or any Ubuntu LTS. Please don't drop disabled build support which isn't yet re-enabled for openjdk-8. Please don't drop the icedtea-sound tarball, which makes backporting this package to earlier releases just easier. Regarding icedtead-sound, if the same version is used for all JDKs why not using an independent package? I created the libpulse-java package with this in mind (that was before Andrew split the driver into a separate icedtead-sound project, so I'll probably rename the package to match the upstream name). - build tzdata using openjdk-8 I'll make a proposal for this. 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/53c63431.9030...@apache.org
Re: Trying to compile a package that depends on bouncycastle
Le 16/07/2014 09:41, Adam Spragg a écrit : ABI-incompatible changes without bumping the major version number? And people *use* software from upstreams who work in this way? Unfortunately the BouncyCastle project is known for badly breaking the compatibility between releases, and this is an important component that can't be ignored. Hopefully that's the exception and not the rule (the other well know case being Guava). Well, that makes me feel better about giving up and not looking any further into this at all. I like my eyes in the non-bleeding state they are currently in. Bugs-nuts insane. Fricking Java, man. This has nothing to do with Java. Upstream should have provided a proper build script, try asking them. With Maven, Ant, or Gradle you dot not have to care about the dependencies and the javac syntax. 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/53c6369d.4060...@apache.org
Re: Java 9 dropping support for source/target level 1.5
On Wed, Jul 16, 2014 at 01:24:52AM +0200, Emmanuel Bourg wrote: Le 16/07/2014 00:07, Rene Engelhard a écrit : This is nonsense. Not yet - not as long we want/need gcj (on some archs). Fair enough. But we already have a lot of packages incompatible with gcj in Jessie. Bad, but other packages broken is not a reason to break more. What are the Java applications we want/need on these archs? We should *any* Java application which is built on/for kfreebsd-* (which has native stuff) or _all (where it's available on kfreebsd-*, too) probably document them and ensure their dependencies are not updated in a way that renders them incompatible with gcj. And when the transition You man Conflicts: gcj, gcj-jdk? :) to Java 9 starts these packages could be compiled with the Eclipse compiler instead of javac. The problem is not (only) compilation, but also runtime. Lo for example has stuff disabled on gcj-builds because it does not work and some Java commons libs now need 1.6 to build and run etc... Anyway, I *do* see your point but not *now*, so short before the freeze. A loads of packages probably need changes to disable Java, get binary packages removed, etc. 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/20140716092424.gq23...@rene-engelhard.de
Re: Java 9 dropping support for source/target level 1.5
Le 16/07/2014 11:24, Rene Engelhard a écrit : Bad, but other packages broken is not a reason to break more. *any* Java application which is built on/for kfreebsd-* (which has native stuff) or _all (where it's available on kfreebsd-*, too) I understand that would be ideal but that's unrealistic. Java 5 is ten years old, upstreams are increasingly dropping support for Java 5 and 6, we can't fight that. Tomcat 7 requires Java 6, Tomcat 8 requires Java 7, and there is more with every update. You man Conflicts: gcj, gcj-jdk? :) Defining a conflict would be a bit strong. I was rather thinking about a wiki page listing the essential Java packages that must remain compatible with gcj (like Ant, LibreOffice and their dependencies). We could then schedule a periodic rebuild of these packages with gcj to ensure we are not regressing. The problem is not (only) compilation, but also runtime. Lo for example has stuff disabled on gcj-builds because it does not work and some Java commons libs now need 1.6 to build and run etc... If these disabled features are important we could fork the libs into separate packages compatible with gcj (something like libcommons-foo-java5backport-java). Thus we could more forward and preserve the gcj compatibility where it matters. Anyway, I *do* see your point but not *now*, so short before the freeze. A loads of packages probably need changes to disable Java, get binary packages removed, etc. Ok let's shelve my suggestion for now. Thank you for your input Rene. 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/53c64b3f.2050...@apache.org
Re: Bug#754876: Virtual packages for the new Java runtimes
On Tue, Jul 15, 2014 at 09:39:33PM -0700, tony mancill wrote:
On 07/15/2014 11:30 AM, Bill Allombert wrote:
On Tue, Jul 15, 2014 at 04:57:18PM +0200, Emmanuel Bourg wrote:
Le 15/07/2014 16:22, Bill Allombert a écrit :
Could you please write the definition for each of them, and determine
whether
java1-runtime and java2-runtime should be kept ?
Hi Bill,
Here is the definition of these packages:
java5-runtime a Java runtime environment, Java version 5
java6-runtime a Java runtime environment, Java version 6
java7-runtime a Java runtime environment, Java version 7
java8-runtime a Java runtime environment, Java version 8
java9-runtime a Java runtime environment, Java version 9
java5-runtime-headless a non graphical Java runtime environment, Java
version 5
java6-runtime-headless a non graphical Java runtime environment, Java
version 6
java7-runtime-headless a non graphical Java runtime environment, Java
version 7
java8-runtime-headless a non graphical Java runtime environment, Java
version 8
java9-runtime-headless a non graphical Java runtime environment, Java
version 9
java1-runtime and java2-runtime are still provided by gcj-jre and
openjdk-{6,7,8} but they are obsolete. We remove them from the
dependencies as we update the packages.
java9-runtime isn't used yet but is likely to appear in Jessie+1,
feel free to remove it if you prefer keeping only the packages currently
used.
Fine! Could you get someone from the Java team double check and second this
?
Hello Bill,
Seconded. java5 is our minimum supported runtime (I believe since
squeeze), so I don't see any need for java1 or java2 as virtual package
names.
I have a preference for non-graphical over non graphical in the
description of the -headless variants, but it appears that both usages
are common.
OK, so I offer the following patch. Is it fine ?
Cheers,
--
Bill. ballo...@debian.org
Imagine a large red swirl here.
diff --git a/virtual-package-names-list.txt b/virtual-package-names-list.txt
index 2c2a175..ac98261 100644
--- a/virtual-package-names-list.txt
+++ b/virtual-package-names-list.txt
@@ -161,8 +161,16 @@ Graphics and MultiMedia
Java and virtual machines
-
- java1-runtime a Java runtime environment, Java version 1
- java2-runtime a Java runtime environment, Java version 2
+ java5-runtime a Java runtime environment, Java version 5
+ java6-runtime a Java runtime environment, Java version 6
+ java7-runtime a Java runtime environment, Java version 7
+ java8-runtime a Java runtime environment, Java version 8
+ java9-runtime a Java runtime environment, Java version 9
+ java5-runtime-headless a non-graphical Java runtime environment, Java ver. 5
+ java6-runtime-headless a non-graphical Java runtime environment, Java ver. 6
+ java7-runtime-headless a non-graphical Java runtime environment, Java ver. 7
+ java8-runtime-headless a non-graphical Java runtime environment, Java ver. 8
+ java9-runtime-headless a non-graphical Java runtime environment, Java ver. 9
Scheme and interpreters
-
@@ -329,3 +337,7 @@ Bill Allombert:
Charles Plessy:
03 Aug 2013 Removed mp3-encoder
17 Aug 2013 Removed mp3-decoder
+
+Bill Allombert:
+ 16 Jul 2014 Added java{5,6,7,8,9}-runtime{,-headless}
+ Removed java1-runtime, java2-runtime
Bug#754958: basex: FTBFS with Java 8: reference to Base64 is ambiguous
Source: basex
Version: 7.8.2-1
Severity: important
User: debian-java@lists.debian.org
Usertags: openjdk-8-transition
Hi,
During a rebuild of all Java packages in sid with OpenJDK 8,
this package failed to build with the following error:
[INFO]
[INFO] Building BaseX Core
[INFO]task-segment: [package]
[INFO]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 63 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 947 source files to
/«PKGBUILDDIR»/basex-core/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/«PKGBUILDDIR»/basex-core/src/main/java/org/basex/query/util/http/HTTPClient.java:[199,25]
error: reference to Base64 is ambiguous
[INFO] 1 error
[INFO] -
This issue can be fixed by upgrading to the version 7.9 or applying these
patches:
https://github.com/BaseXdb/basex/commit/ea622d
https://github.com/BaseXdb/basex/commit/705ce9
OpenJDK 8 packages are available for testing here:
http://87.98.165.193/debian/openjdk-8u5-b13/
--
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/53c65e46.1030...@apache.org
Bug#754964: proguard: Unable to process Java 8 bytecode
Package: proguard Version: 4.11-1 Severity: important User: debian-java@lists.debian.org Usertags: openjdk-8-transition proguard is unable to process the bytecode produced by Java 8. This breaks the build of the mobile-atlas-creator package with OpenJDK 8: http://87.98.165.193/debian/openjdk8-rebuild/logs-failed-jdk8/mobile-atlas-creator_1.9.16+dfsg1-1_unstable_jdk8.log shrink: [proguard] ProGuard, version 4.8 [proguard] Reading program jar [/«BUILDDIR»/mobile-atlas-creator-1.9.16+dfsg1/Mobile_Atlas_Creator.jar] [proguard] Reading library jar [/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] BUILD FAILED /«BUILDDIR»/mobile-atlas-creator-1.9.16+dfsg1/build.xml:203: Can't read [/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar] (Can't process class [com/oracle/net/Sdp$1.class] (Unsupported class version number [52.0] (maximum 51.0, Java 1.7))) -- 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/53c65642.2030...@apache.org
Bug#754971: gluegen2: FTBFS with Java 8: package com.jogamp.junit.util does not exist
Source: gluegen2
Version: 2.1.5-2
Severity: important
User: debian-java@lists.debian.org
Usertags: openjdk-8-transition
Hi,
During a rebuild of all Java packages in sid with OpenJDK 8,
this package failed to build with the following error:
java.build:
[echo] - - - compiling all java files - - -
[echo] test.base.dir ../src/junit
[echo] build_t.gen ../build/test/build/gensrc
[javac] Compiling 1 source file to
/«PKGBUILDDIR»/build/test/build/classes
[javac] warning: [options] bootstrap class path not set in conjunction
with -source 1.6
[javac] CStruct: @com.jogamp.gluegen.structgen.CStruct(name=_default_,
header=TestStruct01.h), package com.jogamp.gluegen.test.junit.structgen, header
TestStruct01.h
[javac] CStruct.0: user.dir: /«PKGBUILDDIR»/make
[javac] CStruct.0: element: config0, .simpleName config0
[javac] CStruct.0: enclElement:
com.jogamp.gluegen.test.junit.structgen.TestStructGen01, .simpleName
TestStructGen01, .package com.jogamp.gluegen.test.junit.structgen
[javac] CStruct.locateSource.0: p
com.jogamp.gluegen.test.junit.structgen, r TestStruct01.h
[javac] Catched FileNotFoundException:
com.jogamp.gluegen.test.junit.structgen/TestStruct01.h
[javac] CStruct.locateSource.0: p , r TestStruct01.h
[javac] CStruct.locateSource.1: h
file:/«PKGBUILDDIR»/src/junit/com/jogamp/gluegen/test/junit/structgen/TestStruct01.h
[javac] CStruct:
/«PKGBUILDDIR»/src/junit/com/jogamp/gluegen/test/junit/structgen/TestStruct01.h,
abs: true, root /«PKGBUILDDIR»/src/junit/..
[javac] CStruct: OutputDir: ../build/test/build/gensrc/classes, is-abs
false
[javac] CStruct: OutputPath:
/«PKGBUILDDIR»/src/junit/../../build/test/build/gensrc/classes
[javac] CStruct: ConfigFile:
/«PKGBUILDDIR»/src/junit/../../build/test/build/gensrc/classes/TestStruct01.h.cfg
[javac] generating struct accessor for struct: RenderingConfig
[javac]
/«PKGBUILDDIR»/src/junit/com/jogamp/gluegen/test/junit/structgen/TestStructGen01.java:4:
error: package com.jogamp.junit.util does not exist
[javac] import com.jogamp.junit.util.JunitTracer;
[javac] ^
[javac]
/«PKGBUILDDIR»/src/junit/com/jogamp/gluegen/test/junit/structgen/TestStructGen01.java:13:
error: cannot find symbol
[javac] public class TestStructGen01 extends JunitTracer {
[javac] ^
[javac] symbol: class JunitTracer
[javac]
/«PKGBUILDDIR»/src/junit/com/jogamp/gluegen/test/junit/structgen/TestStructGen01.java:22:
error: cannot find symbol
[javac] RenderingConfig config0;
[javac] ^
[javac] symbol: class RenderingConfig
[javac] location: class TestStructGen01
[javac] 3 errors
[javac] generating - Camera
[javac] generating - Vec3f
[javac] generating - RenderingConfig
This issue can be fixed by upgrading to the version 2.2.0 or applying these
changes:
https://github.com/sgothel/gluegen/commit/1e53a38
The full build log is available from:
http://87.98.165.193/debian/openjdk8-rebuild/logs-failed-jdk8/gluegen2_2.1.5-1_unstable_jdk8.log
OpenJDK 8 packages are available for testing here:
http://87.98.165.193/debian/repo
--
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/53c67783.5050...@apache.org
RFS: mvel/2.0.18-4
Hi all, I updated the mvel package to fix a build failure with Java 8 and I'm looking for a sponsor to upload it. Here is the changelog: * Fixed a compilation error with Java 8 * Fixed the OptimizerFactory class and the unit tests to work with the system version of ASM * Added d/maven.ignoreRules to avoid patching the pom for disabling plugins * debian/watch: Updated to watch the release tags on Github https://mentors.debian.net/package/mvel Thank you, 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/53c6b501.8070...@apache.org
Re: Trying to compile a package that depends on bouncycastle
On Wednesday 16 Jul 2014 09:23:57 Emmanuel Bourg wrote: Bugs-nuts insane. Fricking Java, man. This has nothing to do with Java. Upstream should have provided a proper build script, try asking them. With Maven, Ant, or Gradle you dot not have to care about the dependencies and the javac syntax. Crap. Sorry, you're totally right. That rant doesn't belong on this list, and it certainly shouldn't have been directed at you lot. My frustration got the better of me, and I should know better by now. Still, the first time I need to use a Java project, it doesn't have a build system, and its only dependency is a library maintained by complete cowboys. How unlucky am I? But yeah, I can't justify even projecting that onto the Java community (whatever the hell that is), let alone debian-java. Apologies again, I'll go vent somewhere else now, and stop wasting everyone's time here. Regards, Adam -- 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/201407161857.20999.a...@spra.gg
Re: RFS: openjfx/8u5-b13-1
On Wed, Jul 16, 2014 at 01:49:06AM +0200, Emmanuel Bourg wrote: Le 14/07/2014 03:53, Miguel Landaeta a écrit : openjfx is FTBFS due to a missing dependency on antlr3. Thank you for spotting this issue Miguel. I think I got caught by a dependency caching mechanism in Gradle, I had another non fatal error related to antlr instead. After deleting ~/.gradle I got the same error. I pushed a fix in Git, let me know how it works for you. Hi Emmanuel, I was able to start the build but it failed after a while with some errors like this one: ../../../plugins/av/mpegtsdemuxer.h:30:34: fatal error: libavformat/avformat.h: No such file or directory I'm attaching my failed build log. Cheers, -- 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 openjfx_8u5-b13-1_amd64.build.gz Description: Binary data signature.asc Description: Digital signature
Re: RFS: mvel/2.0.18-4
On Wed, Jul 16, 2014 at 07:23:13PM +0200, Emmanuel Bourg wrote: Hi all, I updated the mvel package to fix a build failure with Java 8 and I'm looking for a sponsor to upload it. I'll take care of it. -- 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
Re: Java 9 dropping support for source/target level 1.5
On Wed, Jul 16, 2014 at 09:50:46AM +0200, Sylvestre Ledru wrote: I think that is unfair statement against Emmanuel (especially when adding d-d d-r to the cc list). Totally agree with Sylvestre on this. I also have sponsored many packages for Emmanuel in the Java team. Frankly, I don't get the hostility level reached with this OpenJDK packaging contribution attempt. It's totally normal to have technical disagreements, especially on a non-trivial packages like that one. What I really dislike is to see epithets like bullshit or own agenda in a technical discussion. Cheers, -- 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
How to start if upstream source contains pom.xml
Hi, I intend to package imeji[1] in Debian Science team. Unfortunately I'm not that skilled with Java packaging. For maven based packages I found MavenBuilder[2] but this page looks quite outdated refering to debhelper (= 5), cdbs, openjdk-6-jdk which lloks somehow ancient. I wonder if somebody could give some helpful hint how to continue from this very rough debian/ I temporary moved to http://people.debian.org/~tille/packages/imeji/ Any hint would be really welcome. Kind regards Andreas. [1] http://demo.imeji.org/imeji/ [2] https://wiki.debian.org/Java/MavenBuilder -- http://fam-tille.de -- 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/20140716203416.ga14...@an3as.eu
Re: How to start if upstream source contains pom.xml
Le 16/07/2014 22:34, Andreas Tille a écrit : Any hint would be really welcome. Hi Andreas, When dealing with a Maven project you just have to checkout the code and run mh_make. If all goes well this will create the packaging files and match the dependencies with the Debian packages. I took a quick look at the project, the structure is simple that's a good news. The bad news is the huge dependency list, many of them aren't packaged yet (I see Apache Tika in the pom, I'm finalizing this one and will post a RFS soon). Feel free to ping me on IRC if you need some help with mh_make. 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/53c6e984.1010...@apache.org
