Package: maven-debian-helper
Version: 2.3.2
Severity: serious
I introduced a regression in maven-debian-helper/2.3 when I modified
the Maven mojos to use the plugin annotation. A copy/paste error in
SysInstallMojo caused the ignore rules to be added to the installed
poms instead of the publish
Le 11/09/2018 à 00:54, Emmanuel Bourg a écrit :
> I haven't figured out the origin of these rules yet
The rules added are the surefire own ignore rules.
Still looking for what triggered their addition to the pom.
Package: libsurefire-java
Version: 2.21.0-2
Severity: serious
When libsurefire-java/2.21.0-2 was built last week extra rules were
automatically added to the pom of the Maven plugin:
--- maven-surefire-plugin-2.21.0-1.pom 2018-09-11 00:24:27.213383006 +0200
+++ maven-surefire-plugin-2.21.0-2.pom
> [ERROR] Failed to execute goal on project bookkeeper-server: Could not
> resolve dependencies for project
> org.apache.bookkeeper:bookkeeper-server:jar:4.4.0: Cannot access central
> (https://repo.maven.apache.org/maven2) in offline mode and the artifact
> io.netty:netty:jar:debian has not
Control: reassign -1 libsimple-xml-java
Control: affects -1 carrotsearch-randomizedtesting
Control: retitle -1 libsimple-xml-java: Missing dependency on libstax-java
This is an issue with libsimple-xml-java which has a pom depending on
stax-api but the package doesn't depend on libstax-java. It
Control: block -1 908023
Control: tags -1 + pending
I've prepared the upgrade of async-http-client to the version 2.5.3
which uses Netty 4.1, but it requires a new dependency (see #908023).
The update is ready in the Salsa repository.
Le 03/09/2018 à 17:29, Markus Koschany a écrit :
> Just updating libequinox-osgi-java would have been
> a straightforward solution.
I agree this is mostly a change in the name of the binary package. I
could have kept the libequinox-osgi-java name with some contortions and
avoid updating the
eam vs
Eclipse Git repository, different naming convention, different build
system, no upstream version tracking). That's why I think it's more
consistent to replace libequinox-osgi-java now.
Emmanuel Bourg
[1] https://lists.debian.org/debian-java/2018/07/msg00020.html
Control: reassign -1 libeclipse-osgi-java
Control: affects -1 libequinox-osgi-java
libeclipse-osgi-java will replace libequinox-osgi-java. I forgot to add
the proper Breaks/Replaces fields.
On 28/08/2018 21:31, Jochen Sprickerhof wrote:
> As a quick fix we could probably hack around the visibility modifiers of
> Marshaller, but I guess that would be rather ugly. Just mentioning it
> for completeness.
+1 for adjusting the xml-security API.
Emmanuel Bourg
On 25/08/2018 17:44, Andreas Tille wrote:
> No, it is different:
> [ERROR] The project com.itextpdf:itextpdf:5.5.13
> (/build/libitext5-java-5.5.13/itext/pom.xml) has 1 error
> [ERROR] Non-resolvable parent POM for com.itextpdf:itextpdf:5.5.13:
> Cannot access central
On 25/08/2018 09:00, Andreas Tille wrote:
> I realised that there is a new upstream version, fixed the watch file in
> Git and tried to build the package. Unfortunately the build fails as
> well.
Do you get the same build failure with the new version?
Emmanuel Bourg
or collecting RC bugs.
I agree. Not all CVEs are equally important though, here simple-xml is
just a test dependency of another package and has a very low popcon, the
vulnerability has no real impact on the Debian users.
Emmanuel Bourg
nished once that was
reverted in ant/1.10.4-2.
Emmanuel Bourg
xml is a dependency of carrotsearch-randomizedtesting.
The fix should be trivial, it's just a matter of disabling external
entities parsing on the underlying XML parser. And maybe we've already
fixed the XML parser used by default.
Emmanuel Bourg
go/darwin/jmodeltest/ModelTestService.java:31:
error: package converter does not exist
[javac] import converter.Factory;
[javac] ^
There is an issue with a dependency (alter-sequence-alignment maybe?),
the Java version isn't to blame here.
Emmanuel Bourg
Control: tag -1 pending
Hello,
Bug #877706 in jakarta-jmeter reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:
Control: tag -1 pending
Hello,
Bug #905145 in jakarta-jmeter reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:
Source: jakarta-jmeter
Version: 2.13-3
Severity: serious
User: debian-j...@lists.debian.org
Usertags: default-java9
jakarta-jmeter fails to build with Java 9 due to the generification
of the javax.swing.JTable constructors:
compile-jorphan:
[mkdir] Created dir:
Control: reopen -1
Control: severity -1 important
I'm reopening the bug because ultimately this issue will have to be
fixed, but I'm lowering the severity to prevent the autoremoval.
Control: tag -1 pending
Hello,
Bug #905139 in apache-log4j2 reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:
Source: apache-log4j2
Version: 2.10.0-2
Severity: serious
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java10
apache-log4j2 currently fails to build with Java 10, the build breaks
with the following javadoc error:
[ERROR] javadoc: error - An internal exception has
Control: reassign -1 testng
Control: affects -1 dom4j
Control: forcemerge 895886 891437
This issue is actually a duplicate of #895886.
Control: tag -1 pending
Hello,
Bug #905013 in libquartz2-java reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:
Package: libquartz2-java
Version: 2.2.3-3
Severity: serious
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java10
libquartz2-java fails to build with Java 10 due to a change in the signature
of the getPrefixes() method in javax.xml.namespace.NamespaceContext:
[ERROR]
Control: tag -1 pending
Hello,
Bug #898952 in libnative-platform-java reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:
Control: reopen -1
Control: severity -1 important
I'm reopening the bug because ultimately this issue will have to be
fixed, but I'm lowering the severity to prevent the autoremoval.
Control: tag -1 pending
Hello,
Bug #893250 in libapache-poi-java reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:
Control: tags -1 + pending
Control: block -1 by 903617 903658 903653 903645 903632 903575 903559
The packaging of AspectJ 1.9 which supports Java 9 and later is ready in
the Git repository on Salsa. New Eclipse packages are required before
uploading though.
Le 07/07/2018 à 23:16, Sebastiaan Couwenberg a écrit :
> Control: severity -1 serious
>
> jts (1.15.1+ds-1) has been uploaded to unstable.
Hi Sebastiaan, do you think you could provide a patch fixing the reverse
dependencies please?
Emmanuel Bourg
Control: tag -1 pending
Hello,
Bug #902895 in ant reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below, and you can check the diff of the fix at:
Le 02/07/2018 à 14:51, Emmanuel Bourg a écrit :
> axis fails to build with Java 10 due to the removal of the com.sun.net.ssl
> API:
>
>
> ./axis/src/org/apache/axis/components/net/SunFakeTrustSocketFactory.java:24:
> error: package com.sun.net.ssl does no
Source: axis
Severity: serious
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java10
axis fails to build with Java 10 due to the removal of the com.sun.net.ssl API:
./axis/src/org/apache/axis/components/net/SunFakeTrustSocketFactory.java:24:
error: package
Le 13/06/2018 à 23:01, Adrian Bunk a écrit :
> The /usr/share/doc/default-jdk symlink is shipped in the default-jdk
> package that is not installed by the build dependencies of
> libgpars-groovy-java.
Ok, because libgpars-groovy-java build-depends on default-jdk-headless
instead of default-jdk
or years
is still valid.
I wonder if this is a regression in the javadoc tool which would no
longer be able to follow symlinks.
Emmanuel Bourg
Le 11/06/2018 à 15:10, peter green a écrit :
> Debdiff for what I uploaded to raspbian is available at
> http://debdiffs.raspbian.org/main/o/openjfx/openjfx_8u141-b14-3%2brpi1.debdiff
Thanks a lot for the help Peter!
It looks like JSStringRef.cpp was eventually fixed upstream (at least in
Control: tags -1 + patch
Here is a patch fixing the build failure with Java 9 & 10:
--- a/src/java/Makefile.am
+++ b/src/java/Makefile.am
@@ -47,11 +47,9 @@
$(CEPH_PROXY): $(JAVA_SRC)
export CLASSPATH=java/ ; \
- $(JAVAC) -classpath java -source 1.5 -target 1.5 -Xlint:-options
Control: retitle -1 jayway-jsonpath FTBFS: Cannot set the value of read-only
property 'displayName'
Control: user debian-j...@lists.debian.org
Control: usertag -1 - default-java9
Le 28/03/2018 à 14:14, Adrian Bunk a écrit :
>> Cannot set the value of read-only property 'displayName' for project
Control: tags -1 + patch
I haven't been able to reproduce the error reported, but I got two
other errors due to the use of the now removed source/target level 1.5
in Java 9, and due to the removal of javah in Java 10. This simple
modification of JAVACFLAGS in debian/rules fixed these issues:
---
Le 02/06/2018 à 12:21, Christoph Berg a écrit :
> @java-team: comments?
It looks like the scope of the com.ongres.scram:client dependency in the
pom of org.postgresql:postgresql wasn't changed to 'provided' as
intended. I installed libpostgresql-jdbc-java/42.2.2-2 and got this in
Control: severity -1 important
Control: close -1
Le 03/06/2018 à 16:46, Markus Koschany a écrit :
> Control: reopen -1
>
> jaxb 2.3.0.1-2 fails to build from source. Reopening.
The build failure isn't related to jaxb/2.3.0.1-2 addressing this bug,
but to the upload of jaxb-api/2.3.0-1 which
Control: tags -1 + fixed-upstream
Control: severity -1 important
The issue has been fixed upstream but hasn't been backported to the
2.3.0 branch yet. I'm lowering the severity since a workaround seems to
exist (by forking the JVM at the task level).
low to
achieve the SBT packaging? I'm sure people will jump in and help if the
steps are clearly identified and with someone coordinating the packaging
effort.
Emmanuel Bourg
Source: jaxrs-api
Severity: serious
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java9
jaxrs-api has a test failing with Java 9 and later
due to the removal of the javax.xml.bind package:
[ERROR] Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.163
s
Package: libjgoodies-looks-java
Version: 2.7.0-2
Severity: serious
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java10
libjgoodies-looks-java fails to build with Java 10 because the Windows L
classes are no longer available:
[INFO]
Package: libnative-platform-java
Version: 0.14-3
Severity: serious
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java10
libnative-platform-java fails to build with Java 10 due to the removal of javah:
javac -source 1.7 -target 1.7 -encoding UTF-8 -d debian/out/classes
Source: libgpars-groovy-java
Severity: serious
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java10
libgpars-groovy-java fails to build with Java 10 due to a javadoc issue:
Starting process 'command '/usr/lib/jvm/java-10-openjdk-amd64/bin/javadoc''.
Working directory:
Control: forwarded -1 https://github.com/nhatminhle/cofoja/issues/52
The IllegalArgumentException thrown by ASM can be fixed either
by upgrading ASM or setting the source/target level on the task.
There is another issue hidden behind this one though. Cofoja uses
internal JDK classes and it now
Source: objenesis
Severity: serious
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java10
Forwarded: https://github.com/easymock/objenesis/issues/59
objenesis fails to build with Java 10 due to test errors:
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed:
Source: maven-plugin-tools
Severity: serious
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java10
Forwarded: https://issues.apache.org/jira/browse/MPLUGIN-339
maven-plugin-tools fails to build with Java 10 due to the removal
of the com.sun.tools.doclets API:
[INFO]
Source: icu4j
Severity: serious
icu4j fails to build with Java 10 due to a buggy JDK detection logic:
Buildfile: /build/1st/icu4j-60.2/build.xml
BUILD FAILED
/build/1st/icu4j-60.2/build.xml:125: The JDK version is too old or unknown.
It also fails to compile due to changes to the
Source: java3d
Severity: serious
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java10
java3d fails to build with Java 10 due to the removal of javah:
dependencyCheck:
[echo] javahBuild.notRequired = ${javahBuild.notRequired}
[echo]
Le 13/05/2018 à 16:58, 殷啟聰 | Kai-Chung Yan a écrit :
> I would say this is not the fault of Gradle itself, but it the tricks can be
> provided by `gradle-debian-helper`. We shouldn't modify the behavior of the
> build tools too much.
I don't know if this can be addressed at the
Le 10/05/2018 à 05:52, Thorsten Glaser a écrit :
> You summoned?
Thank you for the quick help! It works perfectly.
@Andreas: I pushed the fixes, could you complete the upload please?
Package: libjna-java
Severity: serious
Tags: sid buster
User: debian-j...@lists.debian.org
Usertags: default-java10
libjna-java fails to build with Java 10 due to the removal of javah:
compile:
[javac] Using javac -source 1.6 is no longer supported, switching to 1.7
[javac] Using
Control: tags -1 + patch
Le 06/05/2018 à 02:13, James McCoy a écrit :
> It looks like that will do the right thing. Now I just need to figure
> out the larger issue of adapting upstream's build system.
I've managed to patch the EZT Make template to use 'javac -h' instead of
javah. A few
st script is
probably broken, it checks if files are equal... but fails on equal
files. I tried replacing "diff -u" with "cmp" but that didn't help. We
need some help from a make/shell expert.
Emmanuel Bourg
Source: libpulse-java
Severity: serious
User: debian-j...@lists.debian.org
Usertags: default-java10
libpulse-java fails to build with Java 10 due to the removal of javah:
compile:
[mkdir] Created dir: /build/1st/libpulse-java-2.4.7/target/classes
[javac] Using javac -source 1.6 is
Control: retitle -1 xz-java: FTBFS with Java 10 due to javadoc changes
This is actually caused by the replacement of the package-list file with
element-list which combines the package names with the module names.
Source: xz-java
Severity: serious
User: debian-j...@lists.debian.org
Usertags: default-java10
xz-java fails to build with Java 10 because javadoc is unable
to find the package-list file from the JDK documentation at
the usual path:
jar:
[mkdir] Created dir:
Source: jffi
Severity: serious
User: debian-j...@lists.debian.org
Usertags: default-java10
jffi fails to build with Java 10 due to the removal of javah:
-generate-version-source:
[echo] Generating Version.java
[mkdir] Created dir: /build/1st/jffi-1.2.7/build/java/com/kenai/jffi
Source: jblas
Severity: serious
User: debian-j...@lists.debian.org
Usertags: default-java10
jblas fails to build with Java 10 due to the removal of javah:
prepare:
[mkdir] Created dir: /build/1st/jblas-1.2.4/target/classes
javah:
[javac] /build/1st/jblas-1.2.4/build.xml:142:
Source: jinput
Severity: serious
User: debian-j...@lists.debian.org
Usertags: default-java10
jinput fails to build with Java 10 due to the removal of javah:
jar:
[jar] Building jar:
/build/1st/jinput-20100502+dfsg/plugins/linux/bin/linux.jar
createJNIHeaders:
BUILD FAILED
Source: java-gnome
Severity: serious
User: debian-j...@lists.debian.org
Usertags: default-java10
java-gnome fails to build with Java 10 due to the removal of javah.
The configure script is unable to detect javah and the build stops:
...configuring Java projects to build and run on Linux &
Package: junit4
Version: 4.12-6
Severity: serious
User: debian-j...@lists.debian.org
Usertags: default-java10
junit4 fails to build with Java 10 due to the removal of several methods
from the java.lang.SecurityManager class:
[INFO] -
Source: javamail
Version: 1.6.1-2
Severity: serious
User: debian-j...@lists.debian.org
Usertags: default-java10
javamail fails to build with Java 10 due to the deprecation of the
Object.finalize() method and the use of the -Werror compilation flag:
[WARNING]
Control: fixed -1 3.7-1
Control: close -1
Control: reassign -1 libcommons-lang3-java
Control: affects -1 access-modifier-checker
This is actually a Java 10 incompatibility in libcommons-lang3-java.
It's fixed in the version 3.7.
Subversion.
Looking at the build log it seems javah is invoked 5 times and the
headers are all generated into the subversion/bindings/javahl/include
directory. Did you try disabling the calls to javah and adding '-h
subversion/bindings/javahl/include/' to the javac parameters?
Emmanuel Bourg
Le 01/05/2018 à 10:43, nicolas.patr...@gmail.com a écrit :
> Why not upgrading Geogebra to the latest version?
There is a licensing issue with the new version, see #692728.
packages depending on libtablelayout-java will keep working).
Emmanuel Bourg
Control: tags -1 + wontfix
Le 13/04/2018 à 15:55, Markus Koschany a écrit :
> Should this package be removed?
Yes, I already filed the removal request (#895328)
Le 13/04/2018 à 15:22, Markus Koschany a écrit :
> I had a look at this package. Despite the fact that we use the magic
> --ignore-source-errors option we get a ClassCastException from OpenJDK
> 9. I wonder if this is rather a bug in OpenJDK 9 than in libhibernate3-java.
This is a JDK bug. We
Control: tags -1 + patch
Here is a patch fixing this issue.
--- a/java/Makefile
+++ b/java/Makefile
@@ -5,7 +5,7 @@
svm_train.class svm_predict.class svm_toy.class svm_scale.class
#JAVAC = jikes
-JAVAC_FLAGS = -target 1.5 -source 1.5
+JAVAC_FLAGS = -target 1.8 -source 1.8
Le 08/04/2018 à 12:57, Niels Thykier a écrit :
> I had a go and it failed (presumably because I do not have write access)
You have to join back the team then ;)
o the Git
repository (still on Alioth).
Emmanuel Bourg
Control: tags -1 + patch
Here is a patch fixing this issue.
--- a/Makefile
+++ b/Makefile
@@ -22,12 +22,12 @@
SocketFactory.java HTTPConnectSocketFactory.java \
HTTPConnectSocket.java ReloginPanel.java
-OPTS = -source 1.3
+OPTS = -source 1.8
all: $(CLASSES) $(ARCHIVE)
Control: tags -1 + patch
Here is a patch fixing this issue.
--- a/makefile
+++ b/makefile
@@ -17,12 +17,12 @@
vncCanvas.java optionsFrame.java clipboardFrame.java \
animatedMemoryImageSource.java DesCipher.java
-OPTS = -source 1.3
+OPTS = -source 1.8
all: $(CLASSES)
Control: tags -1 + patch
Here is a patch fixing this issue.
--- a/src/com/cburch/logisim/gui/log/ComponentSelector.java
+++ b/src/com/cburch/logisim/gui/log/ComponentSelector.java
@@ -279,7 +279,7 @@
return true;
}
- public Enumeration
ugh.
Emmanuel Bourg
[1] https://anonscm.debian.org/cgit/pkg-java/tomcat8.git/commit/?id=4e00f55
Le 06/04/2018 à 13:45, Andreas Tille a écrit :
> [javac] error: package org.fest.util does not exist
fest-util.jar?
0-2 that should work with Java 8.
Could you give it a try?
Emmanuel Bourg
Hi Andreas,
Le 06/04/2018 à 09:35, Andreas Tille a écrit :
> error: package org.antlr.v4.runtime.dfa does not exist
I think you have to add antlr4-runtime.jar to the classpath.
Emmanuel Bourg
orward with the transition to openjdk-{9,10,11}. Did you
consider changing the JFLAGS variable as suggested by Markus?
Emmanuel Bourg
xed as soon as possible.
Emmanuel Bourg
Le 31/03/2018 à 00:39, gregor herrmann a écrit :
> BTW, do you have an idea why 0.63-1 and 0.64-1 don't build on armel?
Sorry I can't see. Is there a way to have more details on the test
failures ?
Emmanuel Bourg
Control: tags -1 + patch
This is easily fixed by modifying the javac arguments in debian/rules:
--- a/debian/rules
+++ b/debian/rules
@@ -13,7 +13,7 @@ build-arch: build-stamp
build-indep: build-stamp
-JAVA_ARGS=-source 1.5 -target 1.5
+JAVA_ARGS=-source 1.8 -target 1.8 -encoding ISO-8859-1
Control: tags -1 + patch
This is easily fixed by adding a debian/ant.properties files containing:
source.encoding=ISO-8859-1
Control: fixed -1 0.63-1
Control: close -1
I confirm this is now fixed in unstable.
ckage javax.xml.ws is not visible
> import javax.xml.ws.*;
> ^
>
> seems to make not much difference
That's slightly better since it no longer complains about the invalid
module name.
I wonder if this could be a javadoc error this time. Could you try
adding the same --add-modules option to VBOX_JAVADOC_OPTS?
Emmanuel Bourg
Le 30/03/2018 à 09:41, Felix Natter a écrit :
> Is the following ok for getting rid of the -java-doc package
> (I don't think it makes sense to keep an older doc package)?
>
> Package: libknopflerfish-osgi-framework-java
> Architecture: all
> Depends: ${misc:Depends}
> -Suggests:
xml.ws
instead of:
--add-modules javax.xml.ws
This will work for OpenJDK 9 and 10. For OpenJDK 11 we'll have to
package the JAX-WS API separately, I'll look into this.
Emmanuel Bourg
> even the --add-modules or similar keyword didn't fix the javax missing
> package.
Could you post the build log with openjdk-9? I'll get a look.
Emmanuel Bourg
Le 24/03/2018 à 15:05, Santiago Vila a écrit :
> Is this still an issue with gettext 0.19.8.1-5?
I confirm it works with gettext 0.19.8.1-6. Many thanks for the quick fix.
Emmanuel Bourg
Control: tags -1 + patch
msgfmt has been fixed in gettext/0.19.8.1-6.
Now the build issue can be fixed with this change to debian/rules:
--- a/debian/rules
+++ b/debian/rules
@@ -9,7 +9,7 @@ VERSION=$(shell dpkg-parsechangelog | sed -n
'/^Version/s/Version: \(.*\)-[^-]*$
Control: tags -1 + patch
msgfmt has been fixed in gettext/0.19.8.1-6.
Now the build issue can be fixed wit this change to debian/rules:
--- a/debian/rules
+++ b/debian/rules
@@ -11,7 +11,7 @@ override_dh_auto_test:
override_dh_auto_build:
# Add here commands to compile the package.
-
Control: block -1 by 873705
The msgfmt issue has been fixed in gettext/0.19.8.1-6,
but there is now an issue related to Scala:
compile:
[mkdir] Created dir: /home/ebourg/packaging/plm/site/bin
[scalac] Compiling 136 scala and 570 java source files to
/home/ebourg/packaging/plm/site/bin
gain in the future.
I suggest simply removing the -java-doc package, it has a low popcon and
no reverse dependencies.
Emmanuel Bourg
a
package.
Emmanuel Bourg
Le 28/03/2018 à 22:39, Markus Koschany a écrit :
> Ah, I see. Forgive my ignorance but wasn't --ignore-source-errors some
> kind of internal developer hack which can be removed at anytime?
You are right, I'm just crossing my fingers that it will happen after
Java 11 (so far our openjdk-11
301 - 400 of 774 matches
Mail list logo
