Processed: your mail
Processing commands for cont...@bugs.debian.org:
unarchive 730133
Bug #730133 {Done: Sylvestre Ledru sylves...@debian.org} [src:java-common]
java-common: policy vs lintian: needless-dependency-on-jre
Unarchived Bug 730133
reopen 730133
Bug #730133 {Done: Sylvestre Ledru sylves...@debian.org} [src:java-common]
java-common: policy vs lintian: needless-dependency-on-jre
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions java-common/0.50.
End of message, stopping processing here.
Please contact me if you need assistance.
--
730133: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730133
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
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/handler.s.c.140542728031190.transcr...@bugs.debian.org
Bug#754876: Virtual packages for the new Java runtimes
Package: debian-policy Severity: wishlist Hi, The list of virtual packages [1] contains only two packages for the Java runtimes (java1-runtime and java2-runtime), but new virtual packages have been in use since at least 2008 when sun-java and openjdk started to be packaged [2]. Could you please add the following packages to reflect the current practices of the Java Team? java5-runtime, java5-runtime-headless, java6-runtime, java6-runtime-headless, java7-runtime, java7-runtime-headless, java8-runtime, java8-runtime-headless, java9-runtime, java9-runtime-headless Thank you, Emmanuel Bourg [1] https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt [2] https://bugs.launchpad.net/ubuntu/+source/sun-java5/+bug/160016 -- 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/53c523c6.2000...@apache.org
Bug#730133: fixed in java-common 0.50
Reopening, java-common/0.50 removed the required runtime for Java programs instead of Java libraries. 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/53c52510.6020...@apache.org
Re: RFS: openjdk-8/8u5-b13-1 (NEW)
Am 11.07.2014 22:47, schrieb Emmanuel Bourg: Le 11/07/2014 20:09, Matthias Klose a écrit : To be clear, there was nothing restarted. It is done the way I recommended Emmanuel before he did start, and which he did ignore. Matthias again I don't understand what you are referring to. You recommended to start from the openjdk-7 package and not from scratch and that's exactly what I've done. You can check it from the change history: http://anonscm.debian.org/gitweb/?p=pkg-java/openjdk-8.git;a=shortlog;pg=1 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. 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. It contains all your openjdk-7 commits up to 2014-03-05, and I even tracked and merged the changes you made later like the GCC 4.9 switch. 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. 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. There is still a lot of work to do, - build tzdata using openjdk-8 - update the ARM assembler interpreter to work with 8 (maybe something you don't want to start). - get the remaining linux zero ports working (and tested). Note that your sponsors are able to get you access to Debian porter machines. See https://dsa.debian.org/doc/guest-account/ It may be easier to default to zero on amd64, and start testing there. - look at the jtreg test results, decide which tests need fixes, which can be ignored (and added to the exclude list). The info for the failing tests is found in the -jdk package. - get the kfreebsd patches updated (Steven Chamberlain is currently working on this). - once kfreebsd is working, keep hotspot and jdk tarballs for kfreebsd, so that further updates won't break things without updating the patches. submit the kfreebsd patches upstream. Thanks, 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/53c54861.3040...@debian.org
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: Bug#754876: Virtual packages for the new Java runtimes
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 ?
Cheers,
--
Bill. ballo...@debian.org
Imagine a large red swirl here.
--
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/20140715183024.GA9657@yellowpig
Java 9 dropping support for source/target level 1.5
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. 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/53c5983d.1060...@apache.org
Re: Java 9 dropping support for source/target level 1.5
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. 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/53c5a351.3090...@debian.org
Re: Java 9 dropping support for source/target level 1.5
On Tue, Jul 15, 2014 at 11:08:13PM +0200, Emmanuel Bourg wrote: So if you update a package and see these settings please bump them to 1.6. This is nonsense. Not yet - not as long we want/need gcj (on some archs). And changing that now for jessie is not feasible. 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/20140715220713.gp23...@rene-engelhard.de
Re: Java 9 dropping support for source/target level 1.5
Le 15/07/2014 23:55, Matthias Klose a écrit : 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. Ok, but could you say it nicely please? I just came across this info and brought it on the list for discussion because it'll impact us at some point. So don't shoot the messenger. Changing the source/target is often a trivial modification. I'm not asking for actively updating all the Java packages, but just modifying the packages a maintainer may come across. Considering the time it takes to transition to a new Java release this will smooth the transition process when we get serious about Java 9 post Jessie. 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/53c5a909.3010...@apache.org
Re: Trying to compile a package that depends on bouncycastle
Hi all, 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; Look, I've installed plenty of programs from source before. Dozens. Now, I don't expect every program ever to be quite as simple as ./configure; make; make install, but this is getting ridiculous. For pretty much every other program I've ever installed, I've never needed to know much about what language it was written in, or any of the internal details of that language environment. Provided I've got the right compiler and/or runtime installed, I've just downloaded the source, checked the README or INSTALL file or doc/ directory, and then done something like ./configure; make; make install. Maybe it was cp makefile.unix makefile; make; make install. Oh, sure, sometimes programs have had dependencies. But installing a dependency is just apt-get install libdependency-dev. Or, wget ftp://dependency.com/latest/dependency.tgz; tar -xf depencency.tgz; cd dependency; ./configure; make; make install; And once that's done, I can go straight to the program I actually want to use, and the configuration/build step will *automatically* find the dependency, and make me a program which will *automatically* use the dependency. That's it. I'm not trying to hack on these java programs. I'm don't want to study the code for its own sake, or track down a bug, or submit a patch upstream. I just want to *build* and *run* them. That's all. Nothing more, nothing less. Now, I've got these three repos. And none of them have README files. Anywhere. (OK, platform_system_core does, but it doesn't actually contain anything worth reading.) Or INSTALL files. Or doc/ directories. Or configure scripts. Or makefiles. They do have what look like makefile fragments, with comments, but no help as to how to actually use them - and all of the Java build processes I've briefly looked at seem to use either XML or JSON as their build description format. platform_build has an envsetup.sh, but it's bonkers. First, it tells you to invoke it as build/envsetup.sh, even though it's not in a directory called build. Then, you don't *run* it, you *source* it into your shell and it does a whole bunch of violence to your environment, like creating function/alias called m to build the tree. Because you probably didn't have m aliased to anything you wanted to use yourself, did you? And that's just platform_build. The other repos don't have an equivalent, at all. So, after all of this, I'm left with 4 theories about what's going on here. 1) Google is ignoring all industry standard best practices for writing and packaging simple command-line apps in Java. 2) There are no industry standard best practices for writing simple command- line apps in Java, because Java is so uniquely unsuited to the task that practically no-one ever even tries.[0] 3) Google is actually following industry standard best practices for writing and packaging simple command-line apps in Java, and everyone in the Java industry thinks that the issues I'm seeing are a perfectly acceptable state of affairs, and not, you know, bug-nuts insane. 4) James Gosling read the spoof interview with Bjarne Stroustrup about how [C++] was only supposed to be a joke, I never thought people would take the book seriously, thought it would be a good laugh to do for real, and is trolling me 20-odd years later. Of these, 1) seems unlikely on the face of it. That just doesn't seem like how Google would get things done. On the other hand, if 2) were the case, why in the softly-spoken name of the Elder Things would Google have picked Java to write them at all, rather than Python, Ruby, Perl, shell, C, Go, DOS batch files, or one the many thousands of other programming languages ever created which seem much better suited to the task, by virtue of not needing to be compiled, or, once compiled, can automatically locate both themselves and their dependencies and can just be, well, run? But then that only leaves 3) and 4), which are the most terrifying of all... Or, there is an option 5), which is that all of the above isn't actually that complicated, and I am actually really gorram stupid for not understanding it. I'm certainly *feeling* pretty stupid after a couple of days of banging my head against this particular brick wall, and it's not doing much for my perpetual case of imposter syndrome either. Whatever. You can keep your Java. I've had it. Adam [0] Re-specifiying dependencies on the command line every time you *run* a program? Really? As if anyone would do ls --link acl,attr,pcre,selinux every time they wanted to list the files in a directory. And have you *seen* the dependencies for something like a text editor? Try it - ldd /usr/bin/vim - especially if you
Re: Java 9 dropping support for source/target level 1.5
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. What are the Java applications we want/need on these archs? We should probably document them and ensure their dependencies are not updated in a way that renders them incompatible with gcj. And when the transition to Java 9 starts these packages could be compiled with the Eclipse compiler instead of javac. 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/53c5b844.3000...@apache.org
Re: RFS: openjfx/8u5-b13-1
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. 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/53c5bdf2.7070...@apache.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
Re: RFS: felix-main 4.4.0-1 [RC] [UPLOADED]
Uploaded. Cheers, tony signature.asc Description: OpenPGP digital signature
Re: Bug#754876: Virtual packages for the new Java runtimes
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.
Cheers,
tony
signature.asc
Description: OpenPGP digital signature
Re: RFS: felix-framework 4.4.0-1 [UPLOADED]
On 07/14/2014 03:56 AM, Markus Koschany wrote: Hello, here is the second part of the felix-* update. I updated felix-framework to version 4.4.0 and I'm looking for a sponsor now. Changelog: * Team upload. * Imported Upstream version 4.4.0. * Drop 01-java8-compatibility.patch. Fixed upstream. * Update debian/copyright to copyright format 1.0. * Fix lintian warning description-synopsis-starts-with-article. Mentors: http://mentors.debian.net/debian/pool/main/f/felix-framework/felix-framework_4.4.0-1.dsc or Git: http://git.debian.org/?p=pkg-java/felix-framework.git Uploaded. Cheers, tony signature.asc Description: OpenPGP digital signature
