Re: Bug#975016: Python 2 / OpenJDK 15 support state for Bullseye

* Matthias Klose: > As background: OpenJDK 12 can only be built with 11, 13 with 12, 14 with 13, > 15 > with 14, 16 with 15. Only having 11 in bullseye would make backports more > "interesting". All recent OpenJDK releases can be built by themselves, right? That's good enough for backports, I t

JDK Mission Control

Is anyone working on packaging this tool? Upstream is here:

Re: Help needed for calling Java class from R

* Andreas Tille: > On Tue, Apr 14, 2020 at 06:52:56PM +0200, Florian Weimer wrote: >> * Andreas Tille: >> > ERROR: loading failed >> > * removing >> > '/build/r-cran-rcdk-3.5.0/debian/r-cran-rcdk/usr/lib/R/site-library/rcdk' >> > dh_auto_in

Re: Help needed for calling Java class from R

* Andreas Tille: > Hi, > > in the COVID-19 packaging effort I need r-cran-rcdk as a predependency. > I have injected it into r-pkg-team Git[1]. It is using the rjava interface > and depends from r-cran-rcdklibs (which has a dependency from libcdk-java). > When I try to build I get: > > > ** insta

Re: Blocked testing migration

* Mechtilde: > I saw this information: > https://tracker.debian.org/pkg/jax-maven-plugin > > I look through the log but don't understand what happens. What can I fix > therr? > > I saw that there is something not uninstallable. > > Can someone give me a hint where I can find some more information

Re: to build "JVerein"

* Mechtilde Stehmann: > In > "/usr/share/maven-repo/joda-time/joda-time/2.10.3/joda-time-2.10.3.pom" > I found the notice "Build does not work on Java 9 or later". Does it > mean I can't use it under Java-11? Would it be possible to port the software to java.time (available since 1.8)?

Re: Mystery meat OpenJDK builds strike again

* Martijn Verburg: > On Mon, 27 May 2019 at 11:13, Florian Weimer wrote: > > * Gil Tene: > > > root@020dc36b9046:/# java -version > > openjdk version "1.8.0_212" > > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) > > Ope

Re: Mystery meat OpenJDK builds strike again

* Gil Tene: > root@020dc36b9046:/# java -version > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01) > OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode) > root@020dc36b9046:/# I wonder if the core technical issue is this: Debian stretch curre

Re: debian/patches/jdk-freetypeScaler-crash.diff causes a memory leak

* Heikki Aitakangas: > Based on history of > https://salsa.debian.org/java-team/openjdk-8/commits/master/debian/patches/jdk-freetypeScaler-crash.diff > the patch was added during OpenJDK 6 era. > > It would be good to know what problem the patch was supposed to fix, as > that would tell if the p

Re: Jackrabbit security update

* Markus Koschany: > On 26.09.2016 21:01, Florian Weimer wrote: >> * Florian Weimer: >> >>> * Markus Koschany: >>> >>>> I have prepared a security update for Jackrabbit to fix CVE-2016-6801. >>> >>> Hi Markus, >>> >>&g

Re: Jackrabbit security update

* Florian Weimer: > * Markus Koschany: > >> I have prepared a security update for Jackrabbit to fix CVE-2016-6801. > > Hi Markus, > > thanks, this looks good to me packaging-wise. Have you tested this > update in some way? If yes, please update to security-master. W

Re: Jackrabbit security update

* Markus Koschany: > I have prepared a security update for Jackrabbit to fix CVE-2016-6801. Hi Markus, thanks, this looks good to me packaging-wise. Have you tested this update in some way? If yes, please update to security-master. Florian

Re: Tomcat 7 security update

* Markus Koschany: > Am 16.04.2016 um 16:14 schrieb Florian Weimer: > [...] >> Packaging-wise, the changes look okay. Could you please upload? > > Uploaded to security-master. Have you tested these packages by running some real-world web application? Are they ready for release? Thanks.

Re: Tomcat 7 security update

* Markus Koschany: > Am 28.03.2016 um 18:07 schrieb Markus Koschany: >> [first e-mail failed, attachment is compressed now] >> >> Hello Security Team, hello Java Team >> >> I have prepared security updates for Tomcat 7 fixing 9 CVEs in Wheezy >> and 7 CVEs in Jessie. > > Hi, > > since I haven't

Re: guava-libraries 18?

* Thorsten Glaser: > On Tue, 28 Oct 2014, Emmanuel Bourg wrote: > >> like to highlight that in Java you can't have two incompatible versions >> of the same library on the classpath. So if elasticsearch pulls another >> library that depends on guava but is incompatible with the version 18, >> it's

Re: Tomcat 6 removal

* Emmanuel Bourg: > I've just uploaded an update of the tomcat6 package that builds only the > Servlet API (libservlet2.5-java) and no longer the server packages > (tomcat6, libtomcat6-java, etc). So even if the src:tomcat6 package is > still part of Jessie we won't have to support the security up

Re: Comments regarding relaxngcc_1.12-1_amd64.changes

* Timo Aaltonen: >> We have a bootstrapping issue with this.. upstream CVS repo ships with >> 'lib/bootstrap-relaxngcc.jar' which is used to generate the files for >> the parser. And since the source tarball can't include that relaxngcc >> has no way to enter Debian? >> >> Fedora doesn't seem to

Re: Runtime JVM != compile time JDK - acceptable?

* Joachim Zobel: > An obvious workaround for > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720684 > > would be to set the runtime jvm to java-7-openjdk while keeping the > compile time JVM at java 6. Is this acceptable or does it violate any > policies? Is this a bug in Netbeans or OpenJD

Re: Java 613 Threads limit: unable to create new native thread

t;> > > I'm sorry but I don't understand. My server is already running in a 64 > bit architecture. What does "java -version" show? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-

Re: Java 613 Threads limit: unable to create new native thread

ss option when you start the JVM. > I have done it and it changes nothing. Okay, then you need to provide more details: the exact way how you start the JVM, and how the JVM crashes. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 t

Re: Java 613 Threads limit: unable to create new native thread

ys my changes were accounted, but how to > be sure the default stack size is what I said ? I think you need to pass a suitable -Xss option when you start the JVM. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1

Re: Java 613 Threads limit: unable to create new native thread

* Keyja Keyja: > On my server, the program crashes after 613 threads. Is this on i386? Have you reduced the default stack size? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsr

Re: Backporting Eclipse

* Niels Thykier: > On 2011-11-10 11:48, Florian Weimer wrote: >> * Niels Thykier: >> >>> That being said - that line is only a warning as I recall, so that >>> cannot be reason for a failure. Also, this is not OSGi, but >>> eclipse-build's OSGi c

Re: Switching default-java to OpenJDK7

r from OpenJDK 7. > Is anyone in the team making Java 7 transition plans for Debian? Or > indeed does anyone have any opinion on whether this release of Debian is > the right point in time to switch default-java to openjdk-7? wheezy will be released after mid-2012, so the Java 7 tr

Re: Backporting Eclipse

t which appears to be working. 8-) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subj

Re: update-java-alternatives in postinst

several of the postinst scripts for JVM packages use roughly equivalent code for setting alternatives, hence my question. It's true that changing this is likely not worth the hassle. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100

update-java-alternatives in postinst

thout switching between manual and automatic mode? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debia

Re: [SECURITY] [DSA 2311-1] openjdk-6 security update

* Simon McVittie: > Would it be possible to provide some sort of empty transitional package for > those Hotspot variants in order to get rid of them? I don't think we use transitional packages for this purpose. I think adding a Replaces: icedtea-6-jre-cacao to openjdk-6-jre-headless (on i386 and

Backporting Eclipse

is I would appreciate pointers why OSGi is doing this, and how I can disable those hash-based checks. (I assume that minor Lucene versions are actually binary-compatible.) This OSGi behavior is reminiscent of bootloaders which verify digital signatures. 8-/ -- Florian Weimer BF

Re: Symbols/shlibs files for Java

r of a method to a derived class. These are source-compatible changes, but not binary-compatible. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- To UNSUB

OpenJDK security updates

Hi, I'd like to release IcedTea 1.8.7 as a security update for both squeeze and lenny. In order to keep the version numbering sane, I'd like to see it in unstable first. Do you plan to upload 1.8.7 soon? Florian -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

* tony mancill: > On 01/14/2011 11:46 AM, Florian Weimer wrote: >> * tony mancill: >> >>> As per Section 5.8.5 of the Developer's Reference, I'd like to get >>> confirmation from the Security Team that they are anticipating and >>> approve of

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

* Florian Weimer: > AFAICT, Debian is actually shipping IcedTea releases, but those are > re-rebranded as IcedTea. Sorry, "re-rebranded as OpenJDK". -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact l

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

* Torsten Werner: > Hi, > > On Sun, Jan 16, 2011 at 11:09 AM, Julien Cristau wrote: >> How does that follow?  These kinds of updates are sort of allowed for >> sun-java6 because it's non-free so there's no choice.  That does not >> apply to openjdk, as far as I know. > > I think that openjdk is n

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

* Matthias Klose: > get the files from testing/unstable && touch debian/control.in && > debian/rules debian/control I end up with this: mkdir -p /tmp/buildd/openjdk-6-6b18-1.8.3/build/plugin/icedteanp && \ cd /tmp/buildd/openjdk-6-6b18-1.8.3/build/plugin/icedteanp && \ x86_64-lin

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

* tony mancill: > As per Section 5.8.5 of the Developer's Reference, I'd like to get > confirmation from the Security Team that they are anticipating and > approve of the upload of the new source version. (My apologies if this > has already been covered; I joined the thread already in progress.)

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

* Philipp Kern: > Florian, > > On 08/08/2010 11:21 AM, Florian Weimer wrote: >> Cool, it's based on OpenJDK 6b18. However, we can't upload it as-is >> because the version number is greater than the one in testing. >> > > apart from the fact that

Re: OpenJDK / default JDK for squeeze / issues on mips / open security issues for lenny

* Matthias Klose: > Or does everybody see openjdk as an alibi for Debian to build things > and then use the sun-java packages from non-free? I know folks who use it in production, admittedly with compiler excludes to work around some C2 bugs. > For those who are interested in an openjdk-6 update

Re: java-problem in lenny

* Claudia Neumann: > The programmer's answer was: > Ich habe auch herausgefunden, an > welcher Stelle das Programm abbricht. Zum Verschlüsseln der Daten wird > ein Session-Key generiert. Dies geschieht mit einer Standard-Java > Funktion( Die Klasse KeyGenerator). Innerhalb dieses Aufrufs ko

Re: Circular build dependency in maven-plugin-tools

* Vincent Fourmond: > Imagine there is a huge security hole in this package. Do you really > think the security team will want to use the *problematic* package to > build a *clean* one ? The machines we use for building have no untrusted local users, and only restricted networking. Of course,

OpenJDK build attempts on the testing security infrastructure

Here are the results of building some OpenJDK packages on the security buildd infrastructure (with the test suites disabled). First, for openjdk-6 6b11-6+lenny1, we have: Successes: amd64, armel, i386, ia64, mips, mipsel, powerpc, sparc Failures: alpha, s390 The s390 failure may be due to too li

Re: freeze exception for cacao-oj6

* Matthias Klose: > unfortunately the -2 build did fail on s390 and armel. > > - s390: rebuilt by hand on raptor/unstable without problems. >Bastian pointed to #479952 as a possible reason. would it >be possible to do a test-rebuild on the machine which is >used security updates? I'm

Re: freeze exception for cacao-oj6

* Matthias Klose: > - s390: rebuilt by hand on raptor/unstable without problems. >Bastian pointed to #479952 as a possible reason. would it >be possible to do a test-rebuild on the machine which is >used security updates? I think we can apply a real security patch to all the Sun-base

Re: freeze exception for cacao-oj6

* Matthias Klose: >> Well, you know that there is a T2000 available and if the security team >> needs a faster buildd they have to ask. > > the estimate is wrong. I what sense? I quoted the actual build time on lebrun. Is spontini really faster than that? > the openjdk-6 package runs the tests

Re: freeze exception for cacao-oj6

* Luk Claes: > Matthias Klose wrote: >> proposing a freeze exception for cacao-oj6 for testing. cacao-oj6 is a >> copy of the openjdk-6 package with the cacao sources >> included. Compared to openjdk-6 on architectures without the Hotspot >> JIT support, cacao-oj6 (including a JIT) is a much faste

Re: OpenJDK for lenny

* Matthias Klose: > So, we are late with OpenJDK for lenny. I still think lenny would > benefit from having OpenJDK. I'm proposing the following steps, > realizing that not all of them probably can be realized. Is there upstream security support for OpenJDK 6? I'm asking because the DLJ stuff us

Re: openfire debian package

* Matthew Johnson: > Oh sure, if the _source_ is distributed from upstream together then it > can and probably should be a single source package. I was assuming that > these were external libraries which were being distributed as jars with > the source for this program. However, the sources shoul

Re: Autobuilding packages depending on sun-java6-jdk

* Matthias Klose: > Florian Weimer writes: >> This does not work in a pristine build environment (such as one set up >> by pbuilder) because the DLJ has to be accepted, which can't work in a >> non-interactive environment. >> >> How do you cope with that?

Autobuilding packages depending on sun-java6-jdk

This does not work in a pristine build environment (such as one set up by pbuilder) because the DLJ has to be accepted, which can't work in a non-interactive environment. How do you cope with that? Use a patched version of sun-java6-jdk installed in a local archive? -- To UNSUBSCRIBE, email to

Re: eclipse and junit4

* Timo Aaltonen: > I've got a notice from a java-class teacher that the Debian/Ubuntu > packaged eclipse doesn't include junit4 -support (junit 3.8.1 being > too old), which was probably due to junit4 not being available? junit4 requires Java 5 for its annotation, and the free toolchain only re

Re: Package com.sun.tools.javac in Java 6

* Benjamin Mesing: > I am packaging UMLet and it compiles fine with Sun Java 5. However, > starting from Sun Java 6 it complains that "package com.sun.tools.javac > does not exist". Have you put tools.jar on the classpath? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubs

Re: high system cpu load while running several java machines on 2.6 kernels

* Alexander Burnos: > Could anybody point me where I have to look for the reasons of this > issue? You should try to get thread dumps from the VMs while this is happening, to discover what they are doing. The autoconfiguration code might pick different parameters on 2.4 or 2.6 kernels (for insta

Re: java dependency substvars and native compilation

* Arnaud Vandyck: > On 5/11/07, Matthew Johnson <[EMAIL PROTECTED]> wrote: >> On Fri May 11 07:19, Michael Koch wrote: >> > On Thu, May 10, 2007 at 02:11:27PM +0100, Matthew Johnson wrote: >> > > OK, so as an alternative, I have a version which reads the Class-Path: >> > > variable from the jar. >

Re: OpenJDK and the Free Java Packaging Roadmap

* Tom Marble: > Following up one's own post is rarely a good idea, but in this > case... please find today's slides here: > > deb-openjdk.odp > https://penta.debconf.org/file/event_attachment/38 deb-openjdk.odp > > deb-openjdk.pdf > https://penta.debconf.org/file/event_attachment/39 deb-openjd

Re: GNU/Linux Java Policy and Packaging

* Tom Marble: > 10. Filesystem conventions (FHS) for runtimes (e.g. /usr/lib/jvm) > and libraries (e.g. /usr/share/java). I think we also need to decide if we want to ship something under /usr/share/java which can be ripped out and redistributed outside the system, or if we follow the usual r

Re: Getting Maven Into Main - What Next?

* Paul Cager: >> This is a bit tricky. Theoretically, you are supposed to bootstrap >> from an installed version (IOW, a self-depdency). > > So we couldn't use bootstrapping to get the *first* version into Debian? If there are architecture-dependent binary packages, they need to built and upload

Re: Getting Maven Into Main - What Next?

* Paul Cager: > Now that we are making progress with packaging Maven's > Build-Dependencies, I'm beginning to wonder what happens next. I've > noticed from the JavaCC packaging that it seems to be all right to > include a "bootstrap jar" in the upstream source. Is this right? I guess > to be valid

Re: Java policy and ABI changes

* Marcus Better: > I think the Java policy needs to be tweaked to allow for multiple versions > of the same library. The problem is much easier than for C libraries, since > we don't have a dynamic linker, so the user is responsible for adding the > correct library to the classpath. Not quite tru

Re: java dependency substvars and native compilation

* Matthew Johnson: > It also makes sense for libraries; Java recursively adds the > classpath, so a library which depended on other libraries would have > one so that applications don't have to guess what libraries their > libraries may use. Looking at the spec, this doesn't seem to be required.

Re: java dependency substvars and native compilation

* Michael Koch: > On Thu, May 03, 2007 at 03:51:11AM +0200, Florian Weimer wrote: >> * Matthew Johnson: >> >> > Two subjects to this mail. Firstly, I had a go at writing a dh_javadeps >> > which will search for jar files, find the classes they reference and &

Re: java dependency substvars and native compilation

* Matthew Johnson: > Two subjects to this mail. Firstly, I had a go at writing a dh_javadeps > which will search for jar files, find the classes they reference and > find the packages they are in. This can be found at > http://mjj29.matthew.ath.cx/dh_javadeps It updates $package.substvars so > you

Re: Attempt at packaging StringTemplate

* Michael Koch: > Don't depend on this fact. We are thinking of switching away from gjdoc > to sinjdoc perhaps. Or javadoc from SUN. Yes, makes sense. > (Yes, I have seen that you added it). Thanks again. Shall I upload the package? Do you think it would be generally useful? >> Hmm. I don'

Re: Attempt at packaging StringTemplate

* Michael Koch: > - You dont need to Build-Depend on ant. ant-optional already Depends on > it. > > - You should Build-Depend on antlr when build.properties references it > and its used. Okay, although it's pulled in by gjdoc already. > - You should call the binary package either stringtempl

Attempt at packaging StringTemplate

Would anyone familiar with Java packaging please review my attempt at packaging StringTemplate? $ git clone http://git.enyo.de/fw/debian/stringtemplate.git I'm not quite sure about the build dependencies, and how to force ant to use a particularly Java compiler if multiple ones are installed. -

Re: TagSoup - new upstream files, no license.

* Paul Cager: > In the mean time I have sent an email to the author (see below). Is the > author's statement below sufficient to allow the inclusion of the files > in Debian? It's sufficient, IMNSHO. Just summarize your communication with the author in the debian/copyright file. -- To UNSUBSC

Re: Selecting a javac which supports at least Java5

* Marcus Better: > Yes, that is the only correct way. We must be sure that the package > builds with identical results on different systems, It's not so much that we need identical results, but the result must use the same ABI, which isn't true across major Java versions. -- To UNSUBSCRIBE, em

Re: Bits from the FOSDEM

* Petter Reinholdtsen: > [Florian Weimer] >> "can be built" or "are built"? AFAICS, only the latter complies >> with the letter of the policy and the spirit of the DFSG. > > How are you to see the difference? debian/rules actually compiles the source

Re: [Debian-Java] Bits from the FOSDEM

* Arnaud Vandyck: >We have some proposals about the Debian-Java policy changes that > includes: > - java libraries can go to main if they can be built with free VM; "can be built" or "are built"? AFAICS, only the latter complies with the letter of the policy and the spirit of the DFSG. --

Re: Java Threading

* Matt Mason: > [loading ./Thread.class] You seem to have a compiled Thread class in the current directory. Don't do that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: JCE Code Signing Certificate

* Charles Fry: >> In the meantime, it occurred to me that the certified key (including >> the private key) would have to be included in the source package, >> otherwise the package would fail to build from source. >> >> While I see nothing in Sun's form that requires us to keep the private >> key

Re: JCE Code Signing Certificate

* Michael Koch: > This is a big field which needs even bigger investigation. The free > runtimes can load them but signed jars are still not supported (or was > this fixed lately...). Your best action would be to just test it with > kaffe or gcj or whatever and report any bugs you find. In the me

Re: JCE Code Signing Certificate

* Charles Fry: > Well, I may not entirely understand your question, but here is my > understanding of the situation, as supported by the document How to > Implement a Provider for the JavaTM Cryptography Extension[1]. Unfortunately, this document doesn't explain why the certificate is needed. >

Re: JCE Code Signing Certificate

* Charles Fry: > I should also point out that this JCE Code Signing Certificate is > necessary not only to allow libbcprov-java to be used as a trusted > security provider, but also for me to package bcmail, bctsp, and bcpg > which are also part of Bouncy Castle. I can currently build all of them,