Re: Tomcat 6 removal
On Thu, Oct 23, 2014 at 08:33:38PM -0700, tony mancill wrote: > On 10/23/2014 01:28 PM, Moritz Mühlenhoff wrote: > > On Wed, Oct 22, 2014 at 02:41:55PM +0200, Emmanuel Bourg wrote: > >> Hi all, > >> > >> 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 updates. > >> > >> This change will break two packages: > >> - libjboss-remoting-java: removal pending with jbossas4 (#764250) > >> - tomcat-maven-plugin: no rdeps, low popcon. To be removed or upgraded > >> to the version 2.x to fix the build failure. > >> > >> All the other packages which were relying on tomcat6 have been updated > >> to use tomcat7 or tomcat8. > > > > Thanks, but wasn't the outcome of the discussion in April "Subject: > > Tomcat version for jessie" to only ship tomcat8? > > > > Cheers, > > Moritz > > > > Hello Moritz, > > Yes, this was discussed at one point. However, there was some > subsequent discussion about this during DebConf and as part of this > thread [1]. The conclusion from the Java Team is that tomcat7 is the > right choice for users given the relative newness of tomcat8 and that it > is currently under development. Ok, but then we should remove tomcat8 from testing, so that we don't have two versions of Tomcat in stable again. Cheers, Moritz -- 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/20141025134342.GA5187@pisco.westfalen.local
Re: Tomcat 6 removal
On 10/25/2014 06:43 AM, Moritz Mühlenhoff wrote: > On Thu, Oct 23, 2014 at 08:33:38PM -0700, tony mancill wrote: >> On 10/23/2014 01:28 PM, Moritz Mühlenhoff wrote: >>> On Wed, Oct 22, 2014 at 02:41:55PM +0200, Emmanuel Bourg wrote: Hi all, 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 updates. This change will break two packages: - libjboss-remoting-java: removal pending with jbossas4 (#764250) - tomcat-maven-plugin: no rdeps, low popcon. To be removed or upgraded to the version 2.x to fix the build failure. All the other packages which were relying on tomcat6 have been updated to use tomcat7 or tomcat8. >>> >>> Thanks, but wasn't the outcome of the discussion in April "Subject: >>> Tomcat version for jessie" to only ship tomcat8? >>> >>> Cheers, >>> Moritz >>> >> >> Hello Moritz, >> >> Yes, this was discussed at one point. However, there was some >> subsequent discussion about this during DebConf and as part of this >> thread [1]. The conclusion from the Java Team is that tomcat7 is the >> right choice for users given the relative newness of tomcat8 and that it >> is currently under development. > > Ok, but then we should remove tomcat8 from testing, so that we don't have > two versions of Tomcat in stable again. As I understand it, the rationale for excluding tomcat8 would be to minimize the surface area for security updates. And maybe that's the right thing to air for from a security perspective, but I'm not sure that it's right for users. tomcat8 includes libraries that support the latest servlet and JSP specifications, so excluding it from jessie seems akin to telling users that "Debian stable is for running (this one version of) tomcat, but not for developing software." However, I'm no longer running or developing on tomcat like I used to, so I might have a skewed perspective on it. My aim is only to have that conversation in the open. It feels like we should include software in the distribution that is being widely used, or will be widely used during the lifetime of the release. Given the timing of jessie and the current state of tomcat7 (mature, stable, mainstream), tomcat8 (the canonical implementation of the next servlet spec), we should consider both. Regards, tony signature.asc Description: OpenPGP digital signature
Re: Request for review: jackson-datatype-guava packaging
Hi Tim, On 24.10.2014 04:09, Potter, Tim (Cloud Services) wrote: [...] > I managed to get all of this done, including the unit tests but ended up > trashing my old repo and overwriting it with a new one. I made a huge > mess of the original sources and redid everything using the upstream > tar.gz file you pointed to. > > If there are any checkouts they will need to be deleted and recreated from > scratch. > > Hey that was actually fun, and I think I've figured out a lot about how > Java packaging works now. > I just noticed a small typo in debian/copyright. Somehow the first word "Format:" got reduced to "t:" and the whole file won't be recognized as a machine-readable copyright file anymore. I believe libjackson2-datatype-guava-java-doc.doc-base.api should be renamed to libjackson2-datatype-guava-java-doc.doc-base because I don't recall that such a file is processed by any helper script. I might be wrong though. You can also rename libjackson2-datatype-guava-java-doc.install to libjackson2-datatype-guava-java-doc.javadoc since you build-depend on javahelper. Javahelper will then automatically register the Java Api documentation with doc-base for you and you could save one file. I suggest to change the subject of this thread to RFS: jackson-datatype-guava 2.4.2-1 [ITP] and ask for sponsorship, so that a DD knows the package is ready and should be uploaded. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: RFS: libjchart2d-java 3.2.2+dfsg-1 [ITP]
On 23.10.2014 12:46, Markus Koschany wrote: [...] > On 23.10.2014 06:10, tony mancill wrote: >> On 10/13/2014 06:32 AM, Markus Koschany wrote: > [...] >> Hi Markus, >> >> Things look pretty good with this package. There are a total of (3) >> files that don't carry a license, and all of them are by the same >> upstream author except for this one: >> >> ./jchart2d/src/info/monitorenter/gui/chart/demos/VerticalStackedChartsWithParametricSpirals.java >> >> which is possibly by another author: Hi tony, The upstream developer replied to my e-mail [1] and clarified that VerticalStackedChartsWithParametricSpirals.java was a demo file sent in by a user and AffineTransformBug.java is obsolete but was written by him. He removed both files from his Git repository at sourceforge.net [2] and I did the same for the Debian package. The last file, TestChartOperationsVisual.java, is still relevant but was written by him. I clarified that in debian/copyright. I've pushed the repacked source tarball and the updated copyright file to our Git repository. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626243#79 [2] http://sourceforge.net/p/jchart2d/code/ci/a95c5c978d426ffd742b86a187b405e030c73fdb/ Thanks for pointing this out. Cheers, Markus signature.asc Description: OpenPGP digital signature
Re: RFS: libjchart2d-java 3.2.2+dfsg-1 [ITP] [UPLOADED]
On Sat, Oct 25, 2014 at 09:37:41PM +0200, Markus Koschany wrote: > Hi tony, > > The upstream developer replied to my e-mail [1] and clarified that > > VerticalStackedChartsWithParametricSpirals.java was a demo file sent in > by a user and > > AffineTransformBug.java is obsolete but was written by him. He removed > both files from his Git repository at sourceforge.net [2] and I did the > same for the Debian package. > > The last file, TestChartOperationsVisual.java, is still relevant but was > written by him. I clarified that in debian/copyright. > > I've pushed the repacked source tarball and the updated copyright file > to our Git repository. Thank you for the update. Uploaded. Cheers, tony signature.asc Description: Digital signature
