Re: New oldstable-proposed-updates diff: tomcat6 6.0.45+dfsg-1~deb7u1
Am 29.03.2016 um 23:01 schrieb Moritz Mühlenhoff: > On Tue, Mar 29, 2016 at 10:03:56PM +0200, Markus Koschany wrote: >> The Security Team decided to mark the issues in Jessie as no-dsa because >> we only ship the servlet API and documentation in this release which >> can't be affected by security vulnerabilities at all. I wouldn't mind >> uploading the 6.0.45+dfsg-1~deb8u1 to Jessie but I think we can safely >> ignore the version number skew in this case. All Wheezy users who update >> to Jessie will keep 6.0.45+dfsg-1~deb7u1 for the servlet API and Jessie >> only users will continue to use 6.0.41. They will not be placed in a >> worse position. >> >> If you feel more comfortable with an updated source package in Jessie, I >> will gladly upload this one to Jessie. > > I missed the wheezy > jessie version skew aspect. In that case let's also > upgrade tomcat6 in jessie even though it's a NOP. > > But all those rdeps of libservlet2.5-java should really be upgraded > to libservlet3.1-java. > > Cheers, > Moritz [putting debian-java in the loop] I will upload a Jessie update of Tomcat 6 tomorrow. Please note that changing the rdeps of libservlet2.5-java to libservlet3.1-java is one of our goals for Stretch. [1] This is sometimes not an easy task because we also ship packages with specifications like osgi-compendium that support the Java servlet 2.5 API and above. See [2] for user voiced concerns. I don't think that libservlet2.5-java poses any security risk, so we should safely ignore this one in the future. Regards, Markus [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-java-maintain...@lists.alioth.debian.org;tag=libservlet2.5-java [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801026 signature.asc Description: OpenPGP digital signature
Re: Making OpenJDK 7 the default in Wheezy-LTS
Am 29.03.2016 um 12:58 schrieb Andrew Haley: > On 24/03/16 19:03, Markus Koschany wrote: >> Wheezy-LTS is going to start next month and there is the intention to >> switch the default-jre|jdk from OpenJDK 6 to OpenJDK 7 because the >> latter can be supported until Wheezy reaches EOL in 2018-05-31. > > Yes! Good call. > > While we are still supporting OpenJDK 6 and making security releases, > it is always the last in the queue when there is urgent work to be > done, and for this reason may be subject to delays. > > Andrew. > > (OpenJDK 6 project lead.) Thanks for all your work on supporting older OpenJDK releases. We all very much appreciate that. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: Making OpenJDK 7 the default in Wheezy-LTS
Am 29.03.2016 um 09:00 schrieb Emmanuel Bourg: > Le 28/03/2016 18:05, Markus Koschany a écrit : > >> Emmanuel, could you outline again what needs to be done to address your >> concerns? As far as dependencies goes this looks sane to me. > > The issue is the init script of Tomcat [1], it uses > /usr/lib/jvm/default-java first if available. The same goes for Jetty. > > Switching the default JRE will affect any application using > /usr/lib/jvm/default-java directly instead of /usr/bin/java. Also if I'm > not mistaken openjdk-6 could get autoremoved by APT and the alternative > then switched to openjdk-7. It seems you picked Tomcat 7 in Jessie but nevermind, although the version in Wheezy [2] looks different it would use default-java as JAVA_HOME too. I don't know why we wrote the find_openjdks() function in the first place.. The admin could also override the init script with /etc/default/tomcat7. I think this case highlights the importance of supporting one and only one Java runtime per release, if we don't want to invest a lot of time in fixing those corner cases. I think we could upload new packages of Tomcat and Jetty that warn the users about the upcoming switch to OpenJDK 7 and recommend to explicitly set JAVA_HOME in /etc/default/tomcat7. I will also document this on https://wiki.debian.org/LTS/Wheezy. I'm not sure about the autoremoval of OpenJDK 6. On my Wheezy system nothing got removed and I had to use update-alternatives manually. > So my suggestion would be to push an update of java-common first with a > NEWS file stating that we'll stop maintaining openjdk-6 in months > and switch the default JRE. This will let enough time to the LTS users > to anticipate the change. I like this suggestion. I will also add NEWS files to Tomcat and Jetty when Wheezy-LTS starts. My current plan is to change default-java two months later. Cheers, Markus > > Emmanuel Bourg > > [1] https://sources.debian.net/src/tomcat7/7.0.56-3/debian/tomcat7.init/#L56 > [2] https://sources.debian.net/src/tomcat7/7.0.28-4%2Bdeb7u2/debian/tomcat7.init/ signature.asc Description: OpenPGP digital signature
Re: API changes tracker for Java libraries
26.03.2016, 18:45, "Emmanuel Bourg": > Hi Andrey, > > Le 26/03/2016 16:15, Ponomarenko Andrey a écrit : > >> I've just opened the new API changes tracker for Java libraries: >> http://abi-laboratory.pro/java/tracker/ >> >> As the first step I've prepared reports for a random set of libraries: >> Android, Berkeley DB JE, Commons Collections, Hadoop, log4j and SLF4J. >> >> The reports are generated by the new 1.5 version of the >> japi-compliance-checker tool. It's a big and useful update and it's highly >> recommended to update the tool if you are using it in your project: >> https://github.com/lvc/japi-compliance-checker >> >> I'd like to ask the community what other libraries would you like to see in >> the tracker? > > Thank you for japi-compliance-checker, I often use it to check the > compatibility when upgrading sensitive libraries. The Apache Commons > libraries aren't very interesting to track because they almost never > break the compatibility by policy (note that you should split > commons-collections and commons-collections4, these are two distinct > APIs that can coexist in the same classpath). Some libraries I'd like to > see in the tracker are BouncyCastle, ASM, CGLIB, Guava, Jetty, ICU4J, JNA. > Added report for ASM library: http://abi-laboratory.pro/java/tracker/timeline/asm/ I need some time to add others. Seems that there are a lot of critical issues in the basic japi-compliance-checker tool that should be fixed first (performance, RAM usage, size of the report for big sets of changes, separating the code into modules, etc.). Thank you.
Re: Possible problematic terms of use of OSGi library
On Tue, 2015-12-08 at 12:16 +, Ghislain Vaillant wrote: > On 08/12/15 12:01, Arnaud Vandyck wrote: > > > > Hi, > > > > I was on my way trying to package org.osgi.core 6 and before > > downloading I have to agree with this page: > > > > https://www.osgi.org/developer/downloads/release-6/release-6-no-for > > m/ > > > > In the "License Grant", it seems that it could be problematic to > > package osgi in Debian. Am I right? > > > > Any thoughts? > > > > Cheers, > > > From the copyright notice you linked: > > "Implementation of certain elements of the OSGi Alliance > Specification > may be subject to third party intellectual property rights." > > The latter elements would need to be stripped out of the source > tarball. > Question is whether the software is still useful without these > patented > components. Clarification from https://twitter.com/nbartlett/status/705909830314299392 and the sources with the license http://mvnrepository.com/artifact/org.osgi/org.osgi.core/6.0.0 It's an Apache License 2.0. Cheers -- Arnaud Vandyck
Re: Making OpenJDK 7 the default in Wheezy-LTS
On 24/03/16 19:03, Markus Koschany wrote: > Wheezy-LTS is going to start next month and there is the intention to > switch the default-jre|jdk from OpenJDK 6 to OpenJDK 7 because the > latter can be supported until Wheezy reaches EOL in 2018-05-31. Yes! Good call. While we are still supporting OpenJDK 6 and making security releases, it is always the last in the queue when there is urgent work to be done, and for this reason may be subject to delays. Andrew. (OpenJDK 6 project lead.) signature.asc Description: OpenPGP digital signature
Re: Making OpenJDK 7 the default in Wheezy-LTS
Le 28/03/2016 18:05, Markus Koschany a écrit : > Emmanuel, could you outline again what needs to be done to address your > concerns? As far as dependencies goes this looks sane to me. The issue is the init script of Tomcat [1], it uses /usr/lib/jvm/default-java first if available. The same goes for Jetty. Switching the default JRE will affect any application using /usr/lib/jvm/default-java directly instead of /usr/bin/java. Also if I'm not mistaken openjdk-6 could get autoremoved by APT and the alternative then switched to openjdk-7. So my suggestion would be to push an update of java-common first with a NEWS file stating that we'll stop maintaining openjdk-6 in months and switch the default JRE. This will let enough time to the LTS users to anticipate the change. Emmanuel Bourg [1] https://sources.debian.net/src/tomcat7/7.0.56-3/debian/tomcat7.init/#L56
