Bug#870388: animal-sniffer: FTBFS

[Emmanuel Bourg]

Hi Andreas, this is a duplicate of #870339

Bug#870339: animal-sniffer FTBFS: recipe for target 'clean' failed

[Emmanuel Bourg]

Le 1/08/2017 à 11:11, Adrian Bunk a écrit :

> Lots of Java packages started to FTBFS the same way last night in the 
> reproducible builds.

It should affect all packages built with maven-debian-helper + DH, so
about 400 packages.


> I just tried downgrading debhelper to 10.7 and that fixed it,
> so this is actually a 10.7 -> 10.7.1 regression in debhelper.

I confirm this. I managed to work around the issue by replacing a call
to doit_in_builddir with complex_doit_in_builddir in maven-debian-helper
[1]. I don't mind patching maven-debian-helper if needed, but I thought
the compatibility would have been preserved at least until the version 11.


[1]
https://anonscm.debian.org/cgit/pkg-java/maven-debian-helper.git/tree/share/perl/maven.pm#n136

Bug#870339: animal-sniffer FTBFS: recipe for target 'clean' failed

[Emmanuel Bourg]

Thank you for the report Adrian. I admit I don't understand why the
clean target fails on the builder. The package just uses the default
dh_auto_clean from maven-debian-helper with no other customization (no
override, no debian/clean), and it works well for many other packages.

Emmanuel Bourg

Bug#869996: RM: maven-embedder -- ROM; No longer used, moved to libmaven3-core-java

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the maven-embedder package, it is no longer used
and its content is now provided by libmaven3-core-java.

Thank you,

Emmanuel Bourg

Bug#869985: ITP: maven-reporting-exec -- Apache Maven Reporting Executor

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg <ebo...@apache.org>

* Package name: maven-reporting-exec
  Version : 1.3
  Upstream Author : The Apache Software Foundation
* URL : http://maven.apache.org/shared/maven-reporting-exec/
* License : Apache-2.0
  Programming Lang: Java
  Description : Apache Maven Reporting Executor

This library provides classes to manage report plugin executions with Maven 3.
It is required to upgrade the maven-site-plugin and will be maintained by the
Java Team.

Bug#869944: RM: doxia-maven-plugin -- ROM; Not used, discontinued

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the doxia-maven-plugin package. This Maven plugin is never
used in Debian and upstream stopped updating it 6 years ago.

Thank you,

Emmanuel Bourg

Bug#635964: Newest version is now 3.3.2

[Emmanuel Bourg]

Le 27/07/2017 à 11:37, Wouter Verhelst a écrit :

> If so, it would have been helpful if the bug report showed that.

You could have inquired politely about the state of package too.


> That's not how Debian works, sorry.

Blaming maintainers is certainly not how Debian works.

Bug#869867: RM: plexus-compiler-1.0 -- ROM; Transitional package, no longer used

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the plexus-compiler-1.0 package, it was required
for the transition to Maven 3 but it is no longer used.

Thank you,

Emmanuel Bourg

Bug#869866: RM: maven-compiler-plugin-2.5 -- ROM; Transitional package, no longer used

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the maven-compiler-plugin-2.5 package, it was required
for the transition to Maven 3 but it is no longer used.

Thank you,

Emmanuel Bourg

Bug#869862: RM: plexus-component-api -- ROM; No longer used, replaced by plexus-containers

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the plexus-component-api package, it has been replaced
by plexus-containers/plexus-containers1.5 and is no longer used.

Thank you,

Emmanuel Bourg

Bug#869861: RM: plexus-active-collections -- ROM; Obsolete, no longer used

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the the plexus-active-collections package, this is an obsolete
library from the Plexus/Maven ecosystem that is no longer used.

Thank you,

Emmanuel Bourg

Bug#869839: ITP: maven-reporting-api -- Maven Reporting API

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg <ebo...@apache.org>

* Package name: maven-reporting-api
  Version : 3.0
  Upstream Author : The Apache Software Foundation
* URL : http://maven.apache.org/shared/maven-reporting-api/
* License : Apache-2.0
  Programming Lang: Java
  Description : Maven Reporting API

This library contains the base API for Maven plugins generating code reports.
It was originally part of libmaven2-core-java but was spun off in the latest
release. This package is required to upgrade the maven-invoker-plugin to the
latest release.

This package will be maintained by the Java Team.

Bug#635964: Newest version is now 3.3.2

[Emmanuel Bourg]

Le 26/07/2017 à 21:10, Wouter Verhelst a écrit :

> this is getting ridiculous.

Do you realize that there is an ongoing effort to upgrade pdfsam and
that this kind of comment is rather demotivating? If you don't help you
are not allowed to complain.

Emmanuel Bourg

Bug#869716: libplexus-containers-java: Wrong scope for junit dependency

[Emmanuel Bourg]

Le 25/07/2017 à 22:45, Mykola Nikishov a écrit :

> Upgrade to 1.0~beta3.0.7-9 will drag junit. Please change default
> scope [1] to the test one.
> 
> [1] 
> https://anonscm.debian.org/cgit/pkg-java/plexus-containers.git/tree/pom.xml#n32

Actually in this case the scope is correct, because the jar generated
contains the PlexusTestCase class extending the TestCase class from
junit. Changing the scope to test would thus break the build.

That said, we may consider changing the scope to 'provided' as it is in
more recent versions of plexus-containers. That may break a few packages
where the pom only declares a dependency on plexus-container-default and
not junit, but that would avoid pulling junit for packages that don't
need it.

Bug#869361: maven-bundle-plugin: FTBFS after maven-archive 3.1.1 update

[Emmanuel Bourg]

Le 23/07/2017 à 03:34, tony mancill a écrit :

> Thank you for the guidance - much appreciated!  I'm working on the patch
> for maven-bundle-plugin 2.5.4 now, since it's just a simple signature
> change to add the MavenSession [1].

Thank you for the fix Tony!

Bug#869279: hdrhistogram FTBFS: java.lang.NoSuchMethodError: org.apache.maven.archiver.MavenArchiver.getManifest

[Emmanuel Bourg]

Hi Adrian,

Thank you for the report. No need to report more "NoSuchMethodError"
related to MavenArchiver, this is a toolchain issue with
maven-bundle-plugin which affects all its rdeps (~160 packages). I'll
look into this shortly.

Emmanuel Bourg

Bug#869361: maven-bundle-plugin: FTBFS after maven-archive 3.1.1 update

[Emmanuel Bourg]

Le 22/07/2017 à 19:04, tony mancill a écrit :

> Shall we go ahead and update maven-bundle-plugin to 3.3.0, or are there
> advantages to patching the 2.5.x package to work with the newer
> maven-archiver?

Yes we should update maven-bundle-plugin but this one is tricky because
it's tied to bnd. I suggest fixing the compatibility with maven-archiver
without upgrading the plugin yet, and later upgrade it when the new
version of bnd is ready.

Emmanuel Bourg

Bug#869216: Patches for 0.62 and 0.56

[Emmanuel Bourg]

Le 21/07/2017 à 23:11, Tiago TT a écrit :

> For example, the package for 8u141 would be called: oracle-java8u141-jdk
> And the resulting DEB file: oracle-java8u141-jdk_8u141_amd64.deb

Thank you for the example, I like the idea. I'm not sold on the name of
the '--multi' parameter though, something more explicit would be nice.


> Please find attached the full console output from the modified version
> based on tag 0.62.
> The only possible downside I see is that --revision parameter will also
> get into the package name, which may or may not be desired.

I confirm this isn't desired. The revision shouldn't appear in the
package name nor in the install path.

Bug#869216: Patches for 0.62 and 0.56

[Emmanuel Bourg]

Hi Tiago,

Thanks a lot for the patches! Could you give an example of the package
name and installation path generated with the --multi option?

Emmanuel Bourg

Bug#869087: devscripts: [uscan] Files excluded without a matching pattern in debian/copyright's Files-Excluded

[Emmanuel Bourg]

Package: devscripts
Version: 2.17.9
Severity: normal

Hi,

While updating plexus-archiver I noticed that uscan filters more files
than expected.

The watch file is:

  version=3
  opts=uversionmangle=s{-alpha-}{~alpha} \
  https://github.com/codehaus-plexus/plexus-archiver/tags 
.*/plexus-archiver-(.*).tar.gz

The file downloaded is:

  
https://github.com/codehaus-plexus/plexus-archiver/archive/plexus-archiver-3.5.tar.gz

And debian/copyright contains:

  Files-Excluded: jira

In this case the file 
plexus-archiver-plexus-archiver-3.5/src/test/resources/zeroFileMode/foobar.zip
and a few others are removed from the tarball. It doesn't happen
if the Files-Excluded field is removed.

Bug#868881: ITP: maven-artifact-transfer -- Apache Maven Artifact Transfer

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg <ebo...@apache.org>

* Package name: maven-artifact-transfer
  Version : 0.9.1
  Upstream Author : The Apache Software Foundation
* URL : http://maven.apache.org/shared/maven-artifact-transfer/
* License : Apache-2.0
  Programming Lang: Java
  Description : Apache Maven Artifact Transfer

Maven Artifact Transfer is a shared component intended as an API to install,
deploy and resolving artifacts in Maven 3.

This is a new dependency of maven-dependency-plugin.
This package will be maintained by the Java Team.

Bug#868676: RM: maven-ear-plugin -- ROM; No longer used

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the maven-ear-plugin package. It's never used in Debian
(and probably never will).

Thank you,

Emmanuel Bourg

Bug#868660: ITP: maven-mapping -- Apache Maven Mapping

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg <ebo...@apache.org>

* Package name: maven-mapping
  Version : 3.0.0
  Upstream Author : The Apache Software Foundation
* URL : https://maven.apache.org/shared/maven-mapping/
* License : Apache-2.0
  Programming Lang: Java
  Description : Apache Maven Mapping

Maven Mapping is a shared component to assist in interpolating file names
using properties from a Maven project.

This library is a new dependency of maven-war-plugin.
It'll be maintained by the Java Team.

Bug#865117: [pkg-db-devel] Bug#865117: db5.3: GCJ package removal

[Emmanuel Bourg]

Here is a patch, only build tested on amd64, that's the best I can do.
diff --git a/debian/control b/debian/control
index 369594d98..3ff9f1b76 100644
--- a/debian/control
+++ b/debian/control
@@ -6,16 +6,14 @@ Uploaders: Ondrej Surý , Dmitrijs Ledkovs 

 Standards-Version: 3.9.6
 # For cross building one also needs tcl8.4:native (ie. such that it
 # can be executed to pre-process sqlite3 components).
-# For DEB_STAGE=stage1 build tcl-dev, javahelper, default-jdk,
-# gcj-native-helper can be dropped
+# For DEB_STAGE=stage1 build tcl-dev, javahelper, default-jdk can be dropped
 Build-Depends: debhelper (>= 9.20141221~),
   autotools-dev (>= 20100122.1),
   dh-autoreconf,
   tcl-dev,
   procps [!hurd-i386],
   javahelper [!m68k],
-  default-jdk [!m68k],
-  gcj-native-helper [!m68k]
+  default-jdk [!m68k]
 Homepage: 
http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/overview/index.html
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-db/db5.3.git
 Vcs-Git: git://anonscm.debian.org/pkg-db/db5.3.git
@@ -158,25 +156,11 @@ Depends: libdb5.3-java-jni (>= ${source:Version}),
 ${shlibs:Depends},
 ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
-Suggests: libdb5.3-java-gcj
 Multi-Arch: foreign
 Description: Berkeley v5.3 Database Libraries for Java
  This package provides the Java interface for the Berkeley v5.3 database
  library.

-Package: libdb5.3-java-gcj
-Architecture: any
-Section: java
-Priority: optional
-Depends: libdb5.3-java (= ${source:Version}),
-${shlibs:Depends},
-${misc:Depends}
-Description: Berkeley v5.3 Database Libraries for Java (native code)
- This package provides the Java interface for the Berkeley v5.3 database
- library.
- .
- This package contains the natively compiled code for use by gij.
-
 Package: libdb5.3-java-dev
 Architecture: any
 Section: libdevel
diff --git a/debian/libdb5.3-java-gcj.dirs b/debian/libdb5.3-java-gcj.dirs
deleted file mode 100644
index 38c8e1b77..0
--- a/debian/libdb5.3-java-gcj.dirs
+++ /dev/null
@@ -1,2 +0,0 @@
-usr/lib/gcj
-usr/share/gcj
diff --git a/debian/rules b/debian/rules
index b512d2a5c..3cfa59431 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,32 +13,21 @@ export DH_ALWAYS_EXCLUDE=.arch-ids
 include /usr/share/dpkg/architecture.mk

 # Don't try to build this file if missing
-/usr/share/gcj/debian_defaults /usr/share/javahelper/java-vars.mk:
+/usr/share/javahelper/java-vars.mk:
:

--include /usr/share/gcj/debian_defaults
 -include /usr/share/javahelper/java-vars.mk

 JAVA_BROKEN_ARCHS = m68k
-GCJ_BROKEN_ARCHS =
-GCJ_NATIVE_ARCHS = $(filter-out $(GCJ_BROKEN_ARCHS), $(gcj_native_archs))

 ENABLE_JAVA=no
-ENABLE_GCJ=no

 ifeq (,$(filter $(DEB_HOST_ARCH), $(JAVA_BROKEN_ARCHS)))
   ENABLE_JAVA=yes
-ifneq (,$(filter $(DEB_HOST_ARCH), $(GCJ_NATIVE_ARCHS)))
-  ENABLE_GCJ=yes
-else
-  # work around bug #719842 in javahelper
-  ENABLE_JAVA=no
-endif
 endif

 ifeq ($(DEB_STAGE),stage1)
   ENABLE_JAVA=no
-  ENABLE_GCJ=no
   ENABLE_TCL=no
 else
   ENABLE_TCL=yes
@@ -98,11 +87,7 @@ CONFIGURE_SWITCHES += --enable-java
 DH_PLUGINS += --with=javahelper
 else
 CONFIGURE_SWITCHES += --disable-java
-DH_OPTIONS += -Nlibdb5.3-java -Nlibdb5.3-java-dev -Nlibdb5.3-java-gcj 
-Nlibdb5.3-java-jni
-endif
-
-ifeq (no,$(ENABLE_GCJ))
-DH_OPTIONS += -Nlibdb5.3-java-gcj
+DH_OPTIONS += -Nlibdb5.3-java -Nlibdb5.3-java-dev -Nlibdb5.3-java-jni
 endif

 ifeq (no,$(ENABLE_SQL))
@@ -269,6 +254,3 @@ override_jh_installlibs:
 ifeq (yes,$(ENABLE_JAVA))
jh_installlibs
 endif
-ifeq (yes,$(ENABLE_GCJ))
-   dh_nativejava
-endif

Bug#863337: visualvm: Typos in launcher script - does not start anymore

[Emmanuel Bourg]

Le 5/07/2017 à 13:07, Erich Schubert a écrit :

> To me, these appear to be obvious typos; independent of whether you can
> reproduce them, or not...

This was changed by upstream in the latest version:

  https://github.com/visualvm/visualvm/commit/d6026fc5

These options are passed to nbexec, and the -L flag stands for "Launcher
options". So I'm not convinced this is a typo. See:


http://sources.debian.net/src/netbeans/8.1%2Bdfsg3-2/o.n.bootstrap/launcher/unix/nbexec/?hl=99#L143

If this really causes a problem on your system I suggest reporting this
to upstream. If they confirm the error we'll backport the fix.

Emmanuel Bourg

Bug#866845: libidw-java FTBFS: PropertyMapImpl.java:383: error: unmappable character for encoding ASCII

[Emmanuel Bourg]

Le 4/07/2017 à 20:21, Markus Koschany a écrit :

> I understand what you intend to say. Even if UTF-8 was the default,
> libidw-java would require an override with ISO-8859-1 encoding. However
> we are talking about the general case. What is more likely that a Java
> project contains an UTF-8 encoded character or ISO-8859-1 character in
> 2017?

UTF-8 is certainly more prevalent in 2017, but the packages lacking a
build system and thus using jh_build are often old projects more likely
to have ASCII or ISO-8859-1 encoded source files.


> I hope tony will read this and find some better arguments
> because he is also in favor of UTF-8. :)

I wish I could find the right argument to spare you the trouble of
updating old packages for nothing, but if you think it's better go for
it. That would still be an opportunity to refresh old packages, migrate
them to Git, etc.


> By the way how are people supposed to override the JH_JAVAC_OPTS
> variable. I just tried
> 
> export JH_JAVAC_OPTS="-encoding UTF-8" in libidw-java but this doesn't
> really seem to work.

You are right, I misread the jh_build code sorry. The jh_build options
are either specified with the JH_BUILD_ARGS variable for the CDBS
packages (never used according to codesearch.debian.net), or by adding
the --javacopts option to dh_auto_build for DH packages (used by
osgi-core, libcds-moc-java and rdp-readseq to set the encoding).


> To be honest I didn't expect that much resistance against using UTF-8.

I'm not against UTF-8, I use and recommend UTF-8 everyday, whenever
possible. But here it isn't about using UTF-8, it is about selecting a
default encoding expected by the compiler to parse the source files. I'm
just arguing that the best choice is the one that works out of the box
for a majority of javahelper based packages. Changing the default in
javahelper will do nothing to spread the use of UTF-8.

Bug#866845: libidw-java FTBFS: PropertyMapImpl.java:383: error: unmappable character for encoding ASCII

[Emmanuel Bourg]

Le 4/07/2017 à 17:45, Markus Koschany a écrit :

> I think it is very important that the encoding is handled consistently
> by all build tools. I wanted to fix this for a while now because too
> many times I had to specify UTF-8 explicitly and the build system tried
> to use ASCII. UTF-8 is the de-facto standard encoding in Debian and
> should be a first class citizen in Debian Java too. Thus said I don't
> want to force this on you. Just give me some hints where I have to look
> in the javahelper package and I experiment with the available options
> myself.

I'm all for consistency and UTF-8 everywhere, but in this case it brings
absolutely no benefit. This will just result in package updates
reverting the encoding to ISO-8859-1. In the end this will not really
advance the UTF-8 cause.

This is where the default encoding is specified for jh_build if you want
to modify it:

  https://sources.debian.net/src/javatools/0.61/jh_build/#L54
  https://sources.debian.net/src/javatools/0.61/jh_build/#L74

> Lately I haven't discovered any issues in Maven, so the above might be
> true. Though I still don't understand why there is an ASCII fallback in
> Maven and maybe other Java tools. It appears to be completely
> anachronistic.

Maven doesn't fallback to ASCII, it just uses the default platform
encoding, and on the builders it's ASCII. The day the builders switch to
UTF-8 Maven will also use it by default.

Bug#866845: libidw-java FTBFS: PropertyMapImpl.java:383: error: unmappable character for encoding ASCII

[Emmanuel Bourg]

Le 4/07/2017 à 14:08, Markus Koschany a écrit :

> Maybe let's start with an upload to
> experimental and we try it on some guinea pig javahelper packages first.

Why not but it looks like a lot of efforts for no gain (besides the
satisfaction of compiling with a modern encoding, but that's not a
feature with a visible impact for our users or on the maintenance). I'd
rather focus on fixing the Java 9 issues.


> Maybe the logic should be: IF NOT EXIST property encoding in pom.xml or
> (IF EXIST debian/maven.properties AND debian/maven.properties CONTAINS
> STRING project.build.sourceEncoding) SET encoding to UTF-8

For Maven projects this will fix nothing. If the project has UTF-8
encoded files and doesn't define project.build.sourceEncoding, the
package already FTBFS on the builders and we should be aware of it.

I think our Maven based packages are fine, they either have:
- the source encoding defined in pom.xml
- the source encoding defined in debian/maven.properties
- no encoding specified but have only ASCII source files
Setting a default encoding at the maven-debian-helper level will make no
difference.

Bug#866929: "Unable to find javadoc command:" on openjdk-9

[Emmanuel Bourg]

Le 2/07/2017 à 21:19, Chris West a écrit :

> I couldn't find an upstream issue for this, which suggests it may be an
> issue with openjdk-9 itself... or that everyone else is just setting
> JAVA_HOME. Setting JAVA_HOME does fix it, but it may be easier to fix
> the plugin than all the various build scripts?

I got a look and I think this is an upstream bug. The plugin attempts
to locate the javadoc executable [1] by first using the java.home
property and then the JAVA_HOME environment variable. When using the
java.home property it searches for the bin directory in the parent
directory. With OpenJDK 8 the value of java.home is
/usr/lib/jvm/java-8-openjdk-amd64/jre and it works fine. But with
OpenJDK 9 the jre directory no longer exist and java.home points to
/usr/lib/jvm/java-9-openjdk-amd64, so the plugin checks if
/usr/lib/jvm/bin/javadoc exists and fails.

[1]
http://sources.debian.net/src/maven-javadoc-plugin/2.10.4-1/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java/?hl=1949#L3673

Bug#866845: libidw-java FTBFS: PropertyMapImpl.java:383: error: unmappable character for encoding ASCII

[Emmanuel Bourg]

Le 3/07/2017 à 10:02, Markus Koschany a écrit :

> shouldn't we be more consistent with the other helpers and choose UTF-8
> too? I'm not sure anymore which helper has already been fixed (I
> remember Kai-Chung sent in a patch for Gradle). I'm glad to help with
> this if there is more work required.

maven-debian-helper at least doesn't have a default encoding, each
project defines its encoding by setting the project.build.sourceEncoding
property.

I'd prefer using UTF-8 too, but it will trigger unmappable character
errors on many packages (it does with libidw-java for example). Using
ISO-8859-1 is roughly equivalent to the behavior we had before changing
the language level to 1.7. Since this mostly affects comments in the
code it isn't very important.

I'm fine if someone wants to use UTF-8, but he has to be prepared to
also fix the packages built with jh_build.

Emmanuel Bourg

Bug#866845: libidw-java FTBFS: PropertyMapImpl.java:383: error: unmappable character for encoding ASCII

[Emmanuel Bourg]

Le 3/07/2017 à 11:48, Markus Koschany a écrit :

> So if I understand correctly all pure javahelper packages are safe as
> long as they have defined the encoding already?

Yes, but I'm under the impression that no javahelper based package does
so (a code search on "JH_JAVADOC_OPTS" returns only javatools).


> I don't understand the maven-debian-helper case though. The
> project.build.sourceEncoding in my maven.properties file won't override
> the new default UTF-8 value anymore?

I'm not sure about that. I just know that the command line parameter
overrides the property in pom.xml.

Note that if maven.properties could override the property set by
maven-debian-helper, we would have many cases where maven-debian-helper
sets the encoding to UTF-8, the pom.xml sets the encoding to ISO-8859-1
(but is ignored), and we would have to add the encoding in
debian/maven.properties to ensure it still compiles. That would be
counter-productive since upstream already configured the encoding properly.

Bug#866845: libidw-java FTBFS: PropertyMapImpl.java:383: error: unmappable character for encoding ASCII

[Emmanuel Bourg]

Le 3/07/2017 à 11:19, Markus Koschany a écrit :

> Don't we have a way to say javahelper and maven-debian-helper default to
> UTF-8 but existing overrides like project.build.sourceEncoding (Maven)
> or export _JAVA_OPTIONS (javahelper) still continue to work and take
> precedence over them?

For maven-debian-helper setting the project.build.sourceEncoding
property from the command line will override the encoding specified by
the pom.xml, so it isn't a good option.

For javahelper, jh_build only adds the encoding to the command line if
it isn't defined in JH_JAVAC_OPTS, so the package can still override the
default.

Bug#866845: libidw-java FTBFS: PropertyMapImpl.java:383: error: unmappable character for encoding ASCII

[Emmanuel Bourg]

Control: reassign -1 javahelper 0.60
Control: affects -1 libidw-java

Thank you Adrian. This issue was introduced by javahelper 0.60 that now
uses the source/target level 1.7 by default. At this level the compiler
becomes picky about the character encoding. javahelper must be modified
to also specify a default encoding. ISO-8859-1 should be a good choice
because any one byte character is considered valid.

Emmanuel Bourg

Bug#866855: libgettext-commons-java FTBFS: Gettext Commons build failure

[Emmanuel Bourg]

Le 2/07/2017 à 18:35, tony mancill a écrit :

> All of these build failures have libmaven-assembly-plugin-java in
> common, and after a rebuild of libmaven-assembly-plugin-java against the
> newer libplexus-interpolation-java, I'm able to build
> libgettext-commons-java locally.  Therefore, I'm going to reassign this
> bug and hopefully address it with an upload of maven-assembly.

I'd add that most of the time maven-assembly-plugin isn't required for
building our packages. So this could probably be solved by ignoring this
plugin.

Emmanuel Bourg

Bug#864768: libquartz2-java: Disable the update checker

[Emmanuel Bourg]

Hi Tony,

You are right, thank you for investigating this issue.

Emmanuel

Bug#865627: ITP: gmavenplus -- Maven plugin to build Groovy source files

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg <ebo...@apache.org>

* Package name: gmavenplus
  Version : 1.5
  Upstream Author : Keegan Witt
* URL : http://groovy.github.io/GMavenPlus/
* License : Apache-2.0
  Programming Lang: Java, Groovy
  Description : Maven plugin to build Groovy source files

GMavenPlus Plugin is a rewrite of GMaven, a Maven plugin that allows
one to integrate Groovy into Maven projects.

This package will be maintained by the Java team.

Bug#865499: gradle fails to start in unstable after plexus-containers update

[Emmanuel Bourg]

Le 22/06/2017 à 06:01, tony mancill a écrit :

> I'm not yet sure whether the problem lies with gradle or
> plexus-containers, but perhaps we should reassign this bug to
> plexus-containers1.5 (or create a new one) to temporarily prevent the
> migration.  I'm opening the bug against gradle in case others run into
> the same issue.

As a temporary workaround I'll add a symlink in
libplexus-component-annotations-java to avoid this error. But this is
clearly a packaging bug in gradle, the classpath has to be built with
the versionless jar (i.e.
/usr/share/java/plexus-component-annotations-1.5.jar).

Emmanuel Bourg

Bug#863606: vlc: Unable to play DVDs after upgrading to Stretch

[Emmanuel Bourg]

Le 21/06/2017 à 13:34, Sebastian Ramacher a écrit :

> Sorry, I categorized the vdpau driver incorrectly. It looks more like
> mesa-vdpau-drivers. Could you please install vdpauinfo, run it and attached 
> its
> output?

I attached the output of vdpauinfo to this message.


> The issues could be a variant of #847012 or #765967.

It looks more like #847012 than #765967 since I don't get a green screen.


> Please try selecting on of the XCB or OpenGL outputs instead of automatic or 
> the
> VDPAU one. (I thought there was one for VA-API, but I remembered incorrectly.)

I tried theses options:
* VDPAU output -> scrambled
* XVideo output (XCB) -> video doesn't play
* OpenGL GLX video output -> scrambled
* X11 video output (XCB) -> scrambled
* DirectFB video output -> video doesn't play
* GNU/Linux framebuffer video output -> video doesn't play
* Color ASCII art video output -> works :)
* Video memory output -> video doesn't play
* OpenGL video output (experimental) -> scrambled
* YUV video output -> video doesn't play
* ASCII-art video output -> works
* OpenGL for Embedded Systems video output -> scrambled
* OpenGL for Embedded Systems 2 video output -> scrambled
* Dummy video output -> video doesn't play
* Statistics video output -> video doesn't play

Bug#865354: java.lang.NoClassDefFoundError: org/apache/tomcat/InstanceManager

[Emmanuel Bourg]

Le 20/06/2017 à 21:48, Joe Pfeiffer a écrit :

> So...  should this bug be reported against eclipse (or, I suppose,
> eclipse-platform-data)?  And can you suggest a workaround?

Considering that InstanceManager is properly built by tomcat8 I think
this is indeed an eclipse issue and the bug should be reassigned (I'm
not sure about the right package to target though).

I'm not familiar enough with eclipse to suggest a workaround
unfortunately, sorry.

Bug#865405: protobuf: Add protobuf-javanano to libprotobuf-java

[Emmanuel Bourg]

Source: protobuf
Severity: normal

Hi,

Could you build javanano and install it in libprotobuf-java please?
It is required to upgrade netty (>= 4.1.9).

Thank you,

Emmanuel Bourg

Bug#865354: java.lang.NoClassDefFoundError: org/apache/tomcat/InstanceManager

[Emmanuel Bourg]

Thank your for the report Joe. The InstanceManager class is in
/usr/share/java/tomcat8-api.jar. It looks like this jar is missing from
the classpath used by Eclipse. Did you use the version of eclipse
currently in testing/unstable?

Emmanuel Bourg

Bug#865281: RM: cglib3 -- ROM; No longer used, replaced by cglib

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the src:cglib3 package, it has been replaced by src:cglib
and is no longer used.

Thank you,

Emmanuel Bourg

Bug#865119: docbook-xsl-saxon-gcj: GCJ package removal

[Emmanuel Bourg]

Package: docbook-xsl-saxon-gcj
Severity: important


Hi,

GCJ will go away in Buster with GCC 7, could you stop building
the docbook-xsl-saxon-gcj package and remove the build dependency
on gcj-native-helper please?

Thank you,

Emmanuel Bourg

Bug#865117: db5.3: GCJ package removal

[Emmanuel Bourg]

Source: db5.3
Severity: important

Hi,

GCJ will go away in Buster with GCC 7, could you please stop building
the libdb5.3-java-gcj package and remove the build dependency
on gcj-native-helper?

Thank you,

Emmanuel Bourg

Bug#792130: Version 1.2 is out

[Emmanuel Bourg]

Control: fixed -1 1.2-1
Control: close -1

The package is misnamed, the version 1.1 is hardcoded in the name but
the actual version is more recent. The version 1.2 was packaged in 2008.

Emmanuel Bourg

Bug#864769: Duplicate bug reports?

[Emmanuel Bourg]

Le 15/06/2017 à 17:16, John Paul Adrian Glaubitz a écrit :

> Is there a reason why you filed the same bug report twice? One against
> src:libquartz-java (#864768) and one against libquartz-java (#864769)?
> 
> Otherwise I'd suggest merging both bug reports.

Hi Adrian,

That was intentional, that's two different packages with different fixes.

Emmanuel Bourg

Bug#864597: upgrade-reports: jessie -> stretch: gnome fails to upgrade: cycle found while processing triggers

[Emmanuel Bourg]

Le 15/06/2017 à 18:09, Cyril Brulebois a écrit :

> If all succeed, I intend to NMU ca-certificates-java with the attached
> changes. I could have reintroduced the old package, but I chose to retain
> the svn to git changes, and to drop the version for the openjdk-7 case,
> since even jessie had a higher version. Attached debdiffs against current
> version, and previous one.

Is this the only solution? That's a bit odd to retain the openjdk-7
dependency on ca-certificates-java and potentially stick with it
forever. Maybe we should simply remove the JRE dependency on
ca-certificates-java and move the keystore generation to openjdk-8. That
would also solve the circular dependency (#864657).

If you upload a NMU could you please push the changes to the Git repository?

Emmanuel Bourg

Bug#864769: libquartz-java: Disable the update checker

[Emmanuel Bourg]

Source: libquartz-java
Version: 1:1.8.6-3
Severity: important

Quartz has a mechanism to automatically check for updates, it phones home
and transmits data such as the local IP, the OS version, and the JVM used.
This is enabled by default. The Debian package should disable it by default
to preserve the user's privacy (i.e. change the value of runUpdateCheck
to false in QuartzSchedulerResources.java).

Emmanuel Bourg

Bug#864768: libquartz2-java: Disable the update checker

[Emmanuel Bourg]

Package: libquartz2-java
Version: 2.2.3-1
Severity: important

Quartz has a mechanism to automatically check for updates, it phones home
and transmits data such as the local IP, the OS version, and the JVM used.
This is enabled by default. The Debian package should disable it by default
to preserve the user's privacy.

Emmanuel Bourg

Bug#864767: ehcache: Disable the update checker

[Emmanuel Bourg]

Package: libehcache-java
Version: 2.6.11-3
Severity: important

ehcache has a mechanism to automatically check for updates, it phones home
and transmits data such as the local IP, the OS version, and the JVM used.
This is enabled by default. The Debian package should disable it by default
to preserve the user's privacy (i.e. change the value of DEFAULT_UPDATE_CHECK
to false in Configuration.java).

Emmanuel Bourg

Bug#863606: vlc: Unable to play DVDs after upgrading to Stretch

[Emmanuel Bourg]

Control: tag -1 - moreinfo

Le 12/06/2017 à 21:31, Sebastian Ramacher a écrit :

> Looks like you have libvdpau-va-gl1 installed and use a Intel GPU. As this
> combination caused problems in the past, could you please try to disable
> hardware decoding, or force vlc to use VA-API or unsinstalling libvdpau-va-gl1
> completely?
> 
> (This might be totally unrelated to your issue, but I am not aware of any
> changes between jessie and stretch that could have caused regressions in DVD
> support.)

Thank you for the hint Sebastian. libvdpau-va-gl1 isn't installed, and
after disabling the hardware acceleration (in Tools -> Preferences ->
Video -> Accelerated video output) I get the same result.

Since my initial report I observed the same scrambled output with a .ts
file not from a DVD, so that's probably not a dvdcss issue.

The laptop is a Thinkpad T60p with an Intel Core 2 Duo T2600 and an ATI
Mobility FireGL V5200 video card.

Is there a way to force the use of VA-API with this setup? In Output
combobox of the video settings I saw nothing related to VA-API.

Emmanuel Bourg



signature.asc
Description: OpenPGP digital signature

Bug#864631: unblock: jetty9/9.2.22-1

[Emmanuel Bourg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi,

This is a pre-upload request to unblock jetty9/9.2.22-1. This update fixes
a timing attack in a class checking passwords (no CVE ID has been assigned yet)
and removes a broken symlink (#857217).

Note that Jetty 9.2.x is in maintenance mode and receives only critical fixes
from upstream, that's why I'm suggesting to upload a new version (it mostly
consists in the security fix anyway).

Thank you,

Emmanuel Bourg
diff --git a/VERSION.txt b/VERSION.txt
index 5257d881..5ae8c45c 100644
--- a/VERSION.txt
+++ b/VERSION.txt
@@ -1,3 +1,10 @@
+jetty-9.2.22.v20170531 - 31 May 2017
+ + 920 no main manifest attribute, in jetty-runner-.jar
+ + 1108 Please improve logging in SslContextFactory when there are no approved
+   cipher suites
+ + 1523 Update ALPN support for Java 8u131
+ + 1556 A timing channel in Password.java
+
 jetty-9.2.21.v20170120 - 20 January 2017
  + 592 Support no-value Host header in HttpParser
  + 1229 ClassLoader constraint issue when using NativeWebSocketConfiguration
diff --git a/aggregates/jetty-all/pom.xml b/aggregates/jetty-all/pom.xml
index 2e21ad21..41b2f86c 100644
--- a/aggregates/jetty-all/pom.xml
+++ b/aggregates/jetty-all/pom.xml
@@ -2,7 +2,7 @@
   
 org.eclipse.jetty
 jetty-project
-9.2.21.v20170120
+9.2.22.v20170531
 ../../pom.xml
   
   4.0.0
diff --git a/apache-jsp/pom.xml b/apache-jsp/pom.xml
index 41c59d9c..b4114897 100644
--- a/apache-jsp/pom.xml
+++ b/apache-jsp/pom.xml
@@ -2,7 +2,7 @@
   
 org.eclipse.jetty
 jetty-project
-9.2.21.v20170120
+9.2.22.v20170531
   
   4.0.0
   apache-jsp
diff --git a/apache-jstl/pom.xml b/apache-jstl/pom.xml
index 0a4f3463..cc7566a9 100644
--- a/apache-jstl/pom.xml
+++ b/apache-jstl/pom.xml
@@ -2,7 +2,7 @@
   
 org.eclipse.jetty
 jetty-project
-9.2.21.v20170120
+9.2.22.v20170531
   
   4.0.0
   apache-jstl
diff --git a/debian/changelog b/debian/changelog
index 4470c642..46ffe734 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+jetty9 (9.2.22-1) unstable; urgency=medium
+
+  * Team upload.
+  * New upstream release
+  * No longer create a link to jetty-overlay-deployer (Closes: #857217)
+
+ -- Emmanuel Bourg <ebo...@apache.org>  Sun, 11 Jun 2017 23:23:14 +0200
+
 jetty9 (9.2.21-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/jetty9.install b/debian/jetty9.install
index ae122cb4..58aa01b3 100644
--- a/debian/jetty9.install
+++ b/debian/jetty9.install
@@ -6,7 +6,6 @@ jetty-distribution/src/main/resources/etc/*  etc/jetty9
 jetty-jaas/src/main/config/etc/* etc/jetty9
 jetty-jmx/src/main/config/etc/*  etc/jetty9
 jetty-monitor/src/main/config/etc/*  etc/jetty9
-jetty-overlay-deployer/src/main/config/etc/* etc/jetty9
 jetty-plus/src/main/config/etc/* etc/jetty9
 jetty-proxy/src/main/config/etc/*etc/jetty9
 jetty-quickstart/src/main/config/etc/*   etc/jetty9
@@ -39,7 +38,6 @@ jetty-jaspi/src/main/config/modules/*.mod 
  usr/share/je
 jetty-jmx/src/main/config/modules/*.mod 
usr/share/jetty9/modules
 jetty-jndi/src/main/config/modules/*.mod
usr/share/jetty9/modules
 jetty-monitor/src/main/config/modules/*.mod 
usr/share/jetty9/modules
-jetty-overlay-deployer/src/main/config/modules/*.mod
usr/share/jetty9/modules
 jetty-plus/src/main/config/modules/*.mod
usr/share/jetty9/modules
 jetty-proxy/src/main/config/modules/*.mod   
usr/share/jetty9/modules
 jetty-quickstart/src/main/config/modules/*.mod  
usr/share/jetty9/modules
diff --git a/debian/jetty9.links b/debian/jetty9.links
index 0608047b..95e92111 100755
--- a/debian/jetty9.links
+++ b/debian/jetty9.links
@@ -25,7 +25,6 @@ usr/share/java/jetty9-jaspi.jar 
usr/share/jetty9/lib/jetty-jaspi
 usr/share/java/jetty9-jmx.jar   
usr/share/jetty9/lib/jetty-jmx-${VERSION}.jar
 usr/share/java/jetty9-jndi.jar  
usr/share/jetty9/lib/jetty-jndi-${VERSION}.jar
 usr/share/java/jetty9-monitor.jar   
usr/share/jetty9/lib/monitor/jetty-monitor-${VERSION}.jar
-usr/share/java/jetty9-overlay-deployer.jar  
usr/share/jetty9/lib/jetty-overlay-deployer-${VERSION}.jar
 usr/share/java/jetty9-plus.jar  
usr/share/jetty9/lib/jetty-plus-${VERSION}.jar
 usr/share/java/jetty9-proxy.jar 
usr/share/jetty9/lib/jetty-proxy-${VERSION}.jar
 usr/share/java/jetty9-quickstart.jar
usr/share/jetty9/lib/jetty-quickstart-${VERSION}.jar
diff --git a/debian/libjetty9-java.poms b/debian/libjetty9-java.poms
index 488baacf..8bff1950 100644
--- a/debian/libjetty9-java.poms
+++ b/debian/libjetty9-java.poms
@@ -38,7 +38,6 @@ jetty-http/pom.xml  
--java-lib --us

Bug#864630: unblock: tomcat8/8.5.14-2

[Emmanuel Bourg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package tomcat8, the version 8.5.14-2 contains a fix
for CVE-2017-5664 (#864447).

Thank you,

Emmanuel Bourg
diff --git a/debian/changelog b/debian/changelog
index 363623db..9045d407 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+tomcat8 (8.5.14-2) unstable; urgency=high
+
+  * Team upload.
+  * Fixed CVE-2017-5664: Static error pages can be overwritten if the
+DefaultServlet is configured to permit writes (Closes: #864447)
+
+ -- Emmanuel Bourg <ebo...@apache.org>  Thu, 08 Jun 2017 12:28:34 +0200
+
 tomcat8 (8.5.14-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/patches/CVE-2017-5664.patch 
b/debian/patches/CVE-2017-5664.patch
new file mode 100644
index ..44476c9b
--- /dev/null
+++ b/debian/patches/CVE-2017-5664.patch
@@ -0,0 +1,56 @@
+Description: CVE-2017-5664: Static error pages can be overwritten
+ if the DefaultServlet is configured to permit writes.
+Origin: backport, https://svn.apache.org/r1793469
+  https://svn.apache.org/r1793488
+--- a/java/org/apache/catalina/servlets/DefaultServlet.java
 b/java/org/apache/catalina/servlets/DefaultServlet.java
+@@ -407,6 +407,18 @@
+ }
+ 
+ 
++@Override
++protected void service(HttpServletRequest req, HttpServletResponse resp)
++throws ServletException, IOException {
++
++if (req.getDispatcherType() == DispatcherType.ERROR) {
++doGet(req, resp);
++} else {
++super.service(req, resp);
++}
++}
++
++
+ /**
+  * Process a GET request for the specified resource.
+  *
+@@ -794,7 +806,7 @@
+ return;
+ }
+ 
+-boolean isError = response.getStatus() >= 
HttpServletResponse.SC_BAD_REQUEST;
++boolean isError = DispatcherType.ERROR == request.getDispatcherType();
+ 
+ boolean included = false;
+ // Check if the conditions specified in the optional If headers are
+--- a/java/org/apache/catalina/servlets/WebdavServlet.java
 b/java/org/apache/catalina/servlets/WebdavServlet.java
+@@ -30,6 +30,7 @@
+ import java.util.TimeZone;
+ import java.util.Vector;
+ 
++import javax.servlet.DispatcherType;
+ import javax.servlet.RequestDispatcher;
+ import javax.servlet.ServletContext;
+ import javax.servlet.ServletException;
+@@ -315,6 +316,11 @@
+ return;
+ }
+ 
++if (req.getDispatcherType() == DispatcherType.ERROR) {
++doGet(req, resp);
++return;
++}
++
+ final String method = req.getMethod();
+ 
+ if (debug > 0) {
diff --git a/debian/patches/series b/debian/patches/series
index 1b369897..fe0ccaef 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -8,3 +8,4 @@
 0018-fix-manager-webapp.patch
 0019-add-distribution-to-error-page.patch
 0021-dont-test-unsupported-ciphers.patch
+CVE-2017-5664.patch

Bug#863803: ca-certificates-java: depends on obsolete openjdk-7-jre-headless

[Emmanuel Bourg]

Thank you for the report Andreas. The upgrade problem is odd because
ca-certificates-java expects openjdk-7-jre-headless *or*
java7-runtime-headless which is provided by openjdk-8-jre-headless.
openjdk-8 isn't pulled automatically in this case?

Bug#863131: unblock: tomcat-native/1.2.12-2

[Emmanuel Bourg]

Control: tags -1 - moreinfo

Thanks a lot, uploaded.

Bug#863272: unblock: tomcat7/7.0.78-1

[Emmanuel Bourg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package tomcat7. The version 7.0.78-1 has no modification
compared to the one in testing (in stretch the package now only builds
the Servlet API 3.0 and it never changes), but this update will allow us
to refresh the backports for jessie and wheezy.

Thank you,

Emmanuel Bourg

Bug#863235: RM: libgnuinet-java -- ROM; no longer used

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the libgnuinet-java package, this library is only used
as a build dependency of libgnumail-java which is about to be removed.

Thank you,

Emmanuel Bourg

Bug#863234: RM: libgnumail-java -- ROM; no longer used, replaced by libmail-java

[Emmanuel Bourg]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove the libgnumail-java package, it has been replaced by libmail-java
and is no longer used.

Thank you,

Emmanuel Bourg

Bug#862601: libmaven3-core-java: Version upgrade request to 3.5.0

[Emmanuel Bourg]

Hi Elana,

Maven 3.5.0 with the new maven-resolver replacing eclipse-aether is now
in experimental. Let me know how it works for you with pomegranate.

Emmanuel Bourg

Bug#863223: maven-plugin-tools: FTBFS: maven/tools/plugin/generator/PluginHelpGenerator.java:[300,61] unreported exception java.io.IOException; must be caught or declared to be thrown

[Emmanuel Bourg]

Control: reassign -1 plexus-utils2 3.0.24-1
Control: affects -1 maven-plugin-tools

Thank you for the report Chris. This issue was introduced with the
upload of plexus-utils2/3.0.24-1 in unstable (should have been in
experimental, sorry). The PropertyUtils.loadProperties() method now
throws an IOException that must be caught. It may affect a few other
maven related libraries. I'll fix that in plexus-utils2 by replacing the
IOException with an unchecked runtime exception.

Emmanuel Bourg

Bug#862529: uncommons-watchmaker-doc: Rename the documentation package to lib*-java-doc

[Emmanuel Bourg]

On 05/18/2017 06:48 PM, 殷啟聰 wrote:
> The reason behind this package name is that it provides the Javadoc
> for both of the 2 library packages
> (libuncommons-watchmaker-framework-java &
> libuncommons-watchmaker-swing-java). If I split their Javadocs, there
> will be dead hyperlinks (or in fact the class fullname instead of
> hyperlinks) throughout the Javadoc of
> libuncommons-watchmaker-swing-java.

I agree this is a tricky case. I'm not even sure maven-debian-helper is
able to wire properly the javadocs of different modules from the same
package. In this case I'd suggest basing the name of the javadoc package
on the main binary package, so here that would be
libuncommons-watchmaker-framework-java-doc.


> pkg:gradle-doc follows the same reason, I guess. Besides, I fail to
> find a javadoc package naming rule in the current Debian Java Policy.

gradle is a bit different, it's a command line tool and not a library.

You are right to point out this isn't specified in the policy. The
lib*-java-doc pattern is commonly used though and for consistency it
would be good to stick to it.

Bug#862894: maven-debian-helper: Installed poms are missing the debian.hasPackageVersion property when --has-package-version is specified

[Emmanuel Bourg]

Package: maven-debian-helper
Version: 2.1.3
Severity: normal

When the --has-package-version options is used in the debian/.poms
file the corresponding pom should have a  property
once installed in the package. That's how mh_installpom works in
maven-repo-helper, but this behavior wasn't replicated in the SysInstallMojo
of maven-debian-helper.

As a consequence, the libraries packaged without the debian.hasPackageVersion
property can never be versioned in the ${maven:Depends} variable of packages
depending on them. This is annoying because it's impossible to automatically
enfore versioned dependencies in binary packages.

Emmanuel Bourg

Bug#862601: libmaven3-core-java: Version upgrade request to 3.5.0

[Emmanuel Bourg]

Le 15/05/2017 à 19:08, Elana Hashman a écrit :

> Do you know how long it will be until the stretch release is done and this 
> will 
> be picked up? I'm just curious for a rough estimate, to see if the plan above 
> makes sense. I'd also be interested in your feedback on that.

I don't know when Stretch will be released, but I can upload Maven 3.5.0
to experimental. I got a look and the upgrade seems straightforward.

Emmanuel Bourg

Bug#862703: ITP: maven-resolver -- Library to handle Java artifact repositories

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg <ebo...@apache.org>

* Package name: maven-resolver
  Version : 1.0.3
  Upstream Author : Apache Software Foundation
* URL : https://maven.apache.org/resolver/
* License : Apache-2.0
  Programming Lang: Java
  Description : Library to handle Java artifact repositories

Apache Maven Artifact Resolver is a library for working with artifact
repositories and dependency resolution. Maven Artifact Resolver deals
with the specification of local repository, remote repository, developer
workspaces, artifact transports and artifact resolution.

This library is basically the successor of Eclipse Aether which was
migrated from Eclipse to the ASF. It is required to upgrade Maven
to the version 3.5. Like eclipse-aether the maven-resolver package will
be maintained by the Java Team.

Bug#862601: libmaven3-core-java: Version upgrade request to 3.5.0

[Emmanuel Bourg]

Le 15/05/2017 à 03:38, Elana Hashman a écrit :

> To facilitate packaging leiningen2, this package needs an upgrade to
> version 3.5.0.
> 
> This is because its dependency libpomegranate-clojure currently depends
> on a version of maven much older than available in unstable. We are
> working to upgrade that upstream, and would prefer to use version 3.5.0
> over 3.3.9, as the latter has a dependency (libaether-java) that has
> been orphaned. Maven 3.5.0 imports aether directly into its codebase.
> See #862233 for more info.

Hi Elana,

I plan to start working on Maven 3.5 after the Stretch release.

Did you try building pomegranate with libaether-java? If it works we can
keep it in Debian even if it is abandoned upstream.

Emmanuel Bourg

Bug#862529: uncommons-watchmaker-doc: Rename the documentation package to lib*-java-doc

[Emmanuel Bourg]

Package: uncommons-watchmaker-doc
Version: 0.7.1-1
Severity: minor

The uncommons-watchmaker-doc package contains the Java API documentation
of libuncommons-watchmaker-framework-java but its name doesn't match the
lib*-java-doc pattern for such packages.

I recommend renaming the package, or considering its low popcon, removing it.

Emmanuel Bourg

Bug#859001: libbrowserlauncher-java: No jar file without version number

[Emmanuel Bourg]

Control: severity -1 important

This library was last updated 10 years ago, the probability of a new
release and a subsequent breakage of the reverse dependencies building
their classpath with the versioned jar is rather low.

Emmanuel Bourg

Bug#861707: unblock: mysql-connector-java/5.1.42-1

[Emmanuel Bourg]

Control: tags -1 - moreinfo

Le 7/05/2017 à 19:02, Niels Thykier a écrit :

> Ack, please go ahead and remove the moreinfo tag once the upload has
> been accepted.

Thank you, uploaded.

Bug#861681: unblock: tomcat8/8.5.14-1

[Emmanuel Bourg]

Le 7/05/2017 à 19:49, Niels Thykier a écrit :

> ASSUMING that nothing in Debian stretch relies on the servlet4 preview
> parts, then ack, please go ahead.  Please remove the moreinfo tag once
> the upload has been processed.

Thank you Niels. I confirm that the Servlet 4 preview isn't used in
Debian yet.

Emmanuel Bourg

Bug#861903: groovy: Do not depend on junit4

[Emmanuel Bourg]

Hi Mykola,

Le 5/05/2017 à 17:33, Mykola Nikishov a écrit :

> It seems junit4 is not required for package to function correctly, Recommends 
> or Suggests should be fine (like with dependency on testng).

The groovy-test artifact depends on junit, so the dependency on the
junit4 package must be preserved (unless we split the groovy package).

testng is never used at runtime, so we could drop it from the
recommended dependencies.

Emmanuel Bourg

Bug#861872: Tomcat fails to serve png images

[Emmanuel Bourg]

Hi,

Could you try with the version 7.0.56-1~bpo70+3 available from the
wheezy-backports repository?

Emmanuel Bourg

Bug#861521: libxstream-java: CVE-2017-7957

[Emmanuel Bourg]

Thank you Salvatore. Here is the upstream commit that has to be backported:

https://github.com/x-stream/xstream/commit/b3570be

Emmanuel Bourg

Bug#858016: unblock: tomcat8/8.5.12-1

[Emmanuel Bourg]

Contro: tags -1 - moreinfo

Le 12/04/2017 à 18:41, Ivo De Decker a écrit :

> Please go ahead once the security upload currently in unstable migrated to
> testing (that should happen in a few days, I just unblocked and aged it).
> Please remove the moreinfo tag from this bug once the new upload is in
> unstable and built on the relevant architecture.

Hi,

Thanks a lot, tomcat8/8.5.12-1 is now in unstable. This version contains
the fix for CVE-2017-5648 which was backported in 8.5.11-2. If time
allows I'll probably propose a last update to include the fixes for the
other CVEs.

Emmanuel Bourg

Bug#860650: zookeeper: FTBFS on i386: java.io.FileNotFoundException: /home/user42/.ant/cache/resolved-org.apache.zookeeper-zookeeper-3.4.9-2.xml (No such file or directory)

[Emmanuel Bourg]

Good catch, thank you Lucas. There is an i386 specific test override in
debian/rules:

  ifeq (i386, $(DEB_BUILD_ARCH))
  override_dh_auto_test-indep:
# Run core Java test suite against zookeeper
ant -Dversion=$(DEB_UPSTREAM_VERSION) -DlastRevision=-1 test-core-java
  endif

The Ant settings of the main build aren't use there, and ivy-2.4.0.jar
is downloaded from http://repo2.maven.org. I guess this explains the
failure.

Emmanuel Bourg

Bug#860489: apache-log4j2: CVE-2017-5645: socket receiver deserialization vulnerability

[Emmanuel Bourg]

Le 17/04/2017 à 21:20, Salvatore Bonaccorso a écrit :

> the following vulnerability was published for apache-log4j2.
> 
> CVE-2017-5645[0]:
> Apache Log4j socket receiver deserialization vulnerability

Hi Salvatore,

The vulnerability has been fixed in unstable. liblog4j2-java isn't used
in jessie, this CVE can be ignored there.

Emmanuel Bourg

Bug#858876: libjna-jni: causes NoClassDefFoundError

[Emmanuel Bourg]

Le 18/04/2017 à 00:07, Emmanuel Bourg a écrit :

> I'll get another look.

I wrote a simple test case:

import com.sun.jna.platform.unix.X11;
public class JNATest {
public static void main(String[] args) throws Exception {
System.setProperty("jna.boot.library.name", "jnidispatch.foo");
System.out.println("XAllocSizeHints: " + 
X11.INSTANCE.XAllocSizeHints());
}
}

Compiled and executed with the system JNA jar:

java -cp .:/usr/share/java/jna.jar:/usr/share/java/jna-platform.jar JNATest

And this always works, even if the jna.boot.library.name property
contains a bogus name.

Renaming libjnidispatch.system.so to libjnidispatch.so triggers
an UnsatisfiedLinkError.

I checked again the JNA code and there is no other occurrence of
jna.boot.library.* besides the ones removed in 4.2.2-3.

This issue really looks like an embedded jar. If it isn't in netbeans
directly, it could be in one of its dependencies.

Bug#858876: libjna-jni: causes NoClassDefFoundError

[Emmanuel Bourg]

Le 17/04/2017 à 17:45, YOSHINO Yoshihito a écrit :

> I have upgraded this package, while this error still persists.
> Exactly the same error message appears in the netbeans log.
> Creating the symlink works around this error.

Thank you for the feedback. That's odd because the renamed path of the
library is now hardcoded and can't be changed by a system property.
Creating a symlink should have no effect. Could this be caused by an
embedded jar in netbeans ?

Emmanuel Bourg

Bug#858876: libjna-jni: causes NoClassDefFoundError

[Emmanuel Bourg]

Le 17/04/2017 à 23:55, Markus Koschany a écrit :

> I'm quite sure that we don't use an embedded jar of JNA somewhere in
> Netbeans.

Could you try removing the jna jar manually from /usr/share/java to
confirm that?


> I suspect that Netbeans' System.setProperty does something differently
> and not what we expect or the patch for libjna-jni was incomplete.

I'll get another look.

Bug#858876: libjna-jni: causes NoClassDefFoundError

[Emmanuel Bourg]

On 04/11/2017 11:28 PM, Markus Koschany wrote:

> I'm sure the upstream developers of Netbeans are all ears for your
> proposal. They had set the jna.boot.library.name property to
> jnidispatch-410, so I had to change it to jnidispatch to get it working
> with Debian's system jar. [1]

The Netbeans developers basically did the same thing we did in
libjna-java/4.2.2-1: they renamed the library to avoid conflicts. But
Debian packages don't have to set jna.boot.library.name directly, it
seems libnb-platform18-java and netbeans are the only packages doing
this in Debian [1].


> I beg to differ. I think we should expect that people read the
> documentation. I think we are mainly responsible to ensure that all
> packages in Debian are working well together. It is nearly impossible to
> cover all use cases especially if you take customized local user
> packages into account.

This isn't a matter of reading the documentation. Imagine a end user,
not a developer, installing a third party application using JNA.
Initially it works fine. Then he installs an unrelated Debian package
depending on libjna-java, for example gradle. This breaks the third
party application, he might not even see the relevant stacktrace or
understand what it means. Fixing this could involve modifying the launch
parameters inside a shell script or a .desktop file. It isn't reasonable
to expect non technical users to do this, and we should shield our users
from these troubles.


> Yes, I could try to remove the jna.boot.library.name property completely
> from Netbeans or more precisely libnb-platforms-java which is actually
> the package in use here. However it doesn't feel right to me to diverge
> from upstream JNA and other distributions if we don't have to.

This isn't a significant divergence from upstream. The API and the
behavior are unchanged, the modification is invisible. We simply
adjusted the location of the library to avoid conflicts.


> I just checked Fedora and they don't rename the library name. They seem
> to enforce the system library under all circumstances instead. Is this
> something we could use in Debian too? [2]

Fedora doesn't rename the library but relocates it under a 'jna'
directory (the full path is /usr/lib64/jna/libjnidispatch.so). Thus the
library isn't directly on the JVM library path and doesn't conflict with
third party applications. This is roughly equivalent to our solution.

Fedora also dropped support for the jna.boot.library.name property. This
is probably a good idea, any package using libjna-java, even those like
netbeans redefining jna.boot.library.name would work without
modification. This is a functional divergence though.

I can implement this. The netbeans patch can later be simplified since
tweaking jna.boot.library.name will be no longer necessary.

Emmanuel Bourg

[1] https://codesearch.debian.net/search?q=jna.boot.library.name



signature.asc
Description: OpenPGP digital signature

Bug#858876: libjna-jni: causes NoClassDefFoundError

[Emmanuel Bourg]

On 04/11/2017 08:12 PM, Markus Koschany wrote:

> This issue could be resolved by changing the libary name to
> jnidispatch.system in Netbeans. However I don't understand why we had to
> change the name in the first place.

Actually Netbeans shouldn't have to specify the library name at all.
libjna-java has been patched to use the system library by default, so
any package using it has no need to fiddle with the library loading
mechanism.


> In my opinion LP #1065253 is not a bug because Debian's system JNA works
> as expected and for custom projects you just have to set
> -Djna.nosys=true. We can't provide multiple versions of JNA due to the
> usual reasons (code duplication, security impact).

The point of LP #1065253 is that our JNA library gets in the way of
third party applications using their own incompatible version of JNA. We
can't expect users to understand and fix this on their own by tweaking
the invocation parameters.


> Ways to resolve this bug
> 
> a) Revert the fix for LP #1065253
> b) Reassign to Netbeans and rename the library name in
> netbeans-platform-nojnabinaries.patch

I think this is a netbeans issue, netbeans-platform-nojnabinaries.patch
should be changed such that the jna.boot.library.name property is no
longer set. This will use the default library wired in libjna-java.

Emmanuel Bourg



signature.asc
Description: OpenPGP digital signature

Bug#631991: libmaven-ant-tasks-java is missing all its dependencies.

[Emmanuel Bourg]

On 04/05/2017 05:00 PM, Adrian Bunk wrote:

> Can a user use the generated jar after
>   apt-get install libmaven-ant-tasks-java
> when installing nothing else?
> 
> Does e.g. libthrift-java in experimental work when libclassworlds-java 
> is not installed?

I think so considering the output of the following command:

$ jar -tf /usr/share/java/maven-ant-tasks.jar | grep classworld

META-INF/maven/classworlds/
META-INF/maven/classworlds/classworlds/
META-INF/maven/classworlds/classworlds/pom.properties
META-INF/maven/classworlds/classworlds/pom.xml
org/codehaus/classworlds/
org/codehaus/classworlds/BytesURLConnection.class
org/codehaus/classworlds/BytesURLStreamHandler.class
org/codehaus/classworlds/ClassRealm.class
org/codehaus/classworlds/ClassWorld.class
org/codehaus/classworlds/ClassWorldException.class
org/codehaus/classworlds/ConfigurationException.class
org/codehaus/classworlds/Configurator$1.class
org/codehaus/classworlds/Configurator$2.class
org/codehaus/classworlds/Configurator.class
org/codehaus/classworlds/DefaultClassRealm.class
org/codehaus/classworlds/DuplicateRealmException.class
org/codehaus/classworlds/EmbeddedLauncher.class
org/codehaus/classworlds/Entry.class
org/codehaus/classworlds/Launcher.class
org/codehaus/classworlds/NoSuchRealmException.class
org/codehaus/classworlds/RealmClassLoader.class
org/codehaus/classworlds/RealmDelegatingClassLoader.class
org/codehaus/classworlds/UberJarRealmClassLoader.class
org/codehaus/classworlds/UrlUtils.class
org/codehaus/classworlds/uberjar/
org/codehaus/classworlds/uberjar/boot/
org/codehaus/classworlds/uberjar/boot/Bootstrapper.class
org/codehaus/classworlds/uberjar/boot/InitialClassLoader.class
org/codehaus/classworlds/uberjar/protocol/
org/codehaus/classworlds/uberjar/protocol/jar/
org/codehaus/classworlds/uberjar/protocol/jar/Handler.class
org/codehaus/classworlds/uberjar/protocol/jar/JarUrlConnection.class

Emmanuel Bourg

Bug#859004: Bug#859001: Let's remove BrowserLauncher from Stretch

[Emmanuel Bourg]

On 03/30/2017 04:30 PM, Ole Streicher wrote:


One question here: the tutorial [1] says

"Use the isDesktopSupported() method to determine whether the Desktop
API is available. On the Solaris Operating System and the Linux
platform, this API is dependent on Gnome libraries. If those libraries
are unavailable, this method will return false. After determining that
the Desktop API is supported, that is, the isDesktopSupported() returns
true, the application can retrieve a Desktop instance using the static
method getDesktop()."

So, on a random (minimal) Debian (Jessie/Stretch) installation, how safe
is it to assume that this works when default-jre is installed? And do I
need to check if Desktop.Action.BROWSE is available or can I safely
assume it?


Excellent question, this needs some testing with various desktop 
environments.


Emmanuel Bourg

Bug#631991: libmaven-ant-tasks-java is missing all its dependencies.

[Emmanuel Bourg]

On 04/03/2017 08:26 PM, Adrian Bunk wrote:


Missing dependencies are considered RC.

Adding ${maven:Depends} to Depends adds dependencies that look correct,
but someone should double-check whether this is the correct fix.


Actually the dependencies are embedded in the jar generated, so there is 
no need to declare the dependencies on the package.


Emmanuel Bourg

Bug#859005: Bug#859001: Let's remove BrowserLauncher from Stretch

[Emmanuel Bourg]

Le 30/03/2017 à 14:21, Ole Streicher a écrit :

> IMO that makes the BrowserLauncher package *really* obsolete here.

I agree, BrowserLauncher was interesting before Java 6, but the Desktop
API is good enough for most usages now.

Emmanuel Bourg

Bug#859001: Let's remove BrowserLauncher from Stretch

[Emmanuel Bourg]

Le 30/03/2017 à 13:47, Ole Streicher a écrit :

> Since there is only one dependency (jmodeltest), I recommend to remove
> the package from Stretch and to patch out the dependency with a minimal
> implementation of browserlauncher that uses xdg-open (see attachment).

What about using the JDK API for launching the browser instead (the
browse(URI) method in the java.awt.Desktop class [1]) ?

Emmanuel Bourg

[1]
http://docs.oracle.com/javase/7/docs/api/java/awt/Desktop.html#browse(java.net.URI)

Bug#858876: libjna-jni: causes NoClassDefFoundError

[Emmanuel Bourg]

Le 28/03/2017 à 07:41, YOSHINO Yoshihito a écrit :

> Workaround: Creating a symlink libjnidispatch.so -> libjnidispatch.system.so
> fixes this error.

Hi,

Thank you for the report. The symlink was in the same directory? What
JRE did you use?

Emmanuel Bourg

Bug#852251: libregex-clojure: Version upgrade request to 1.1.0

[Emmanuel Bourg]

Hi Elana,

Le 28/03/2017 à 05:34, Elana Hashman a écrit :

> I've taken a look at the packaging of the current version and it appears
> to use maven. I'd like to help upgrade it, but I've never made a maven
> package before.

Thank you fo offering your help. I got a look at the package and it
seems it's already built with javahelper. It simply uses
maven-repo-helper to install the Maven artifacts in the
/usr/share/maven-repo directory. So if you'd like to upgrade the package
you just have to update the Maven pom in debian/maven-meta


> This looks a bit more complicated than using just javahelper, so I'm
> wondering if you would accept a package upload with version 1.1.0 as a
> non-maven package. I'd do this similarly to what I've done for some
> other clojure packages, e.g.
> https://packages.debian.org/sid/libclasslojure-clojure

libclasslojure-clojure is missing the Maven artifacts, it would be a
good idea to add them in a future update.


> Otherwise, maybe someone could help me update the source with the
> current packaging?

Let us know if you need any help. You can contact the members of the
Java Team on the debian-java mailing list or on IRC, they'll be happy to
guide you.

Emmanuel Bourg

Bug#858561: maven needs to have a metapackage to install all the libraries

[Emmanuel Bourg]

Le 23/03/2017 à 15:20, shirish शिरीष a écrit :

> There doesn't seem to be a metapackage to install all maven library
> packages and have to install them manually which is time-consuming.
> 
> Could something be done about it ?

Hi Shirish,

What do you mean by "install all maven library packages" ? 'apt-get
install maven' will install everything necessary to run the mvn executable.

Emmanuel Bourg

Bug#858561: maven needs to have a metapackage to install all the libraries

[Emmanuel Bourg]

Le 23/03/2017 à 16:11, shirish शिरीष a écrit :

> Just $ sudo aptitude install maven or $ sudo apt-get install maven
> install maven only, I meant the libraries and plugin like -
> 
> I wish all those plugins could be installed by a metapackage or is
> there and perhaps I'm not aware of it ?

These libraries are only used to build other packages without an
internet connectivity as required by the Debian policy. But in a normal
use case, the libraries are downloaded from the Maven Central repository
as usual. You are free to use the plugins packaged by Debian of course,
but you'll have to install them manually as you did. A metapackage would
be too broad and would probably pull all the Java library packages in
Debian, that doesn't seem desirable.

Emmanuel Bourg

Bug#857939: [libtcnative-1] Does not work without symlink

[Emmanuel Bourg]

Le 16/03/2017 à 14:44, g...@leonde.de a écrit :

> After install libtcnative-1 and enabling the AprLifecycleListener, tomcat 
> reported that the native library could not be loaded. This was apparently 
> because libtcnative was not in its library path.
> 
> Symlinking libtcnative-1.so to /usr/lib fixed the issue, which is also 
> reported here: https://bugs.launchpad.net/ubuntu/+source/tomcat-native/+bug/
> 1326255

Hi,

If you aren't using the Debian JRE (i.e. the OpenJDK package pulled by
default-jre-headless) the native libraries installed in a multiarch path
(/usr/lib/x86_64-linux-gnu/) aren't on the default library path. In this
case you have to specify the library path in the JAVA_OPTS variable
defined in /etc/default/tomcat8. See #769167 for more information.

Emmanuel Bourg

Bug#857128: unblock: mysql-connector-java/5.1.41-1

[Emmanuel Bourg]

Control: tags -1 - moreinfo

Le 15/03/2017 à 21:34, Emilio Pozuelo Monfort a écrit :

> Go ahead, and remove the moreinfo tag once the package is accepted.

Thank you, the package has been uploaded.

Emmanuel Bourg

Bug#852342: patch proposal add --no-strip parameter

[Emmanuel Bourg]

Le 15/03/2017 à 17:01, Sven Hoexter a écrit :

> Would that be something you'd be willing to accept?

If the stripping breaks jmap, I guess it might be better to disable it
completely. Is there a good reason to keep it?

Bug#857847: java-package: proposal to add a --no-deps flag to make-jpkg

[Emmanuel Bourg]

Le 15/03/2017 à 17:05, sven a écrit :

> Is there a general willingness to adopt such a patch? My internal
> diff is attached.

Thank you for the patch Sven. This looks like a reasonable compromise to
support multiple releases. Regarding the implementation, I wonder if
this could be achieved with an override_dh_shlibdeps in the rules file
used to generate the package.

Emmanuel Bourg

Bug#856996: libjacoco-java: Where is the jacoco agent located?

[Emmanuel Bourg]

Le 11/03/2017 à 20:00, Martin Quinson a écrit :

> thanks for this build log. It seems that we need to package 
> org.apache.maven.plugins:maven-gpg-plugin and it seems that no ITP is
> filled yet. This, in turn have other dependencies, as shown here:
> http://svn.apache.org/viewvc/maven/plugins/tags/maven-gpg-plugin-1.6/pom.xml?view=markup

maven-gpg-plugin is used for upstream deployment, it's probably not
necessary to build the agent.

Bug#857343: liblogback-java: logback < 1.2.0 has a vulnerability in SocketServer and ServerSocketReceiver

[Emmanuel Bourg]

Hi Fabrice,

Thank you for the report. Do you know if there is a CVE ID assigned to
this vulnerability?

Emmanuel Bourg

Bug#857123: lintian: warning about missing classpath is confusing

[Emmanuel Bourg]

Le 8/03/2017 à 10:19, Markus Koschany a écrit :

> I suggest to remove this Lintian tag or lower the severity from
> warning to info.

+1 for lowering the severity to info.

Emmanuel Bourg

Bug#857034: Please update openjdk-8-jre-dcevm in jessie-backports

[Emmanuel Bourg]

Hi Christian,

Thank you for the report, I'll upload openjdk-8-jre-dcevm/8u112-1 to
jessie-backports shortly. Let me know if it works for you.

Emmanuel Bourg

Bug#856693: Drop ant dependency

[Emmanuel Bourg]

The ant dependency is only used for the excelant tasks [1] (which are
never used in Debian [2]). Any use of these tasks implicitly means Ant
is already on the classpath. In this context Ant can be seen as a
runtime, much like the Servlet API for web based stuff. So I think it
makes sense to remove the dependency from the binary package.

Splitting ant into ant+libant-java is a good idea, but this can probably
wait for the Buster development cycle.

Emmanuel Bourg

[1] https://poi.apache.org/spreadsheet/excelant.html
[2] https://codesearch.debian.net/search?q=excelant

Bug#856602: postinst sed delimiter causes failure

[Emmanuel Bourg]

Le 3/03/2017 à 23:07, Markus Koschany a écrit :

> I think we could reassign this bug report to tomcat8 which is also affected.

Or merged with #770911 which has been fixed 3 months ago.

Bug#856602: postinst sed delimiter causes failure

[Emmanuel Bourg]

Hi Joshua,

The tomcat7/7.0.75-1 package no longer exist in unstable/testing. Did
you mean to report this issue against the Jessie backport?

Emmanuel Bourg