Le 28/03/2018 à 22:29, Markus Koschany a écrit :
> I'm just wondering, we never had 3.0.0-3 of maven-bundle-plugin in
> Debian. How did it get fixed and what does maven-bundle-plugin do now to
> make those Java modules accessible? I thought this was an issue of the
> application build system and
Control: tags -1 + patch
Here is a patch fixing this issue.
--- a/src/SelectedSubsetsStructure.java
+++ b/src/SelectedSubsetsStructure.java
@@ -257,7 +257,7 @@
OneLeg ol = (OneLeg)tn.getUserObject();
if (btransitivesubset)
target level to 1.7 in anticipation
of the 1.6 removal in Java 11
* Added activation.jar to the build classpath to fix
the empty ant-javamail jar with Java 9
Emmanuel Bourg
Control: fixed -1 1.9.10-2
Control: close -1
This was fixed by Matthias' NMU.
Le 25/03/2018 à 23:29, Andreas Tille a écrit :
> I'm fine with moving libjbzip2-java (which I uploaded today) once
> pkg-java has moved to Salsa (or did I missed the move?)
I'm working on the migration, I haven't finalized the notification hooks
yet.
now java-team on Salsa) is always
granted.
Emmanuel Bourg
Hi Andreas,
These are quite generic non-med related libraries, I'd prefer keeping them
under the Java Team umbrella.
Emmanuel Bourg
wonder if it's really worth upgrading Axis, or
if we should try to remove it.
Emmanuel Bourg
in failed to honor the compile
> classpath.
The javadoc is useless for Maven plugins anyway, nobody codes against
their API. I suggest removing it.
Emmanuel Bourg
Le 08/03/2018 à 13:29, 殷啟聰 | Kai-Chung Yan a écrit :
> I tried building Maven Dependency Tree 2.2 against Maven 3.x and found that
> it uses removed APIs, and that patching it would make a huge code change.
> Maybe someone else would have a better skill than me to do the job, but I
> simply
Le 10/03/2018 à 10:42, Emilio Pozuelo Monfort a écrit :
> Yes, this is not listed in the cruft report, so needed a bug report and manual
> action. I have filed the bug, #892542.
Thank you for the help.
Emmanuel Bourg
Le 10/03/2018 à 09:58, po...@debian.org a écrit :
> libxerces2-java depends or build-depends on GCJ. GCJ has been dropped
> upstream since GCC 7, so we are dropping it from Debian. Thus please
> either drop support for GCJ if you are just building an alternative
> package with GCJ support (e.g.
, thank you. I'll add the client path.
Emmanuel Bourg
Le 08/03/2018 à 22:50, Nicolas Braud-Santoni a écrit :
> Given that this is the last activity and the package, that the last upload
> is almost 2 years old, and that no progress has been made towards fixing the
> RC bugs (esp. the issues wrt. security), should we ask ftp-masters to remove
> this
Le 03/03/2018 à 14:50, Markus Koschany a écrit :
> If it helps with upgrading bnd to a more recent version I'm in favor of it.
Well, no objection unless it pulls a herd of Maven 2 dependencies :/
Le 01/02/2018 à 23:02, Markus Koschany a écrit :
> This issue was caused by commons-httpclient due to the switch from Ant
> to Maven in version 3.1-13. The OSGi metadata is currently missing in
> the Manifest file. The data that is added by the 05_osgi_metadata patch
> is overridden by Maven
Thank you Adrian. This is caused by a regression in
maven-javadoc-plugin/3.0.0. Other packages are probably affected.
https://issues.apache.org/jira/browse/MJAVADOC-504
1. I'll take care of it.
Emmanuel Bourg
Thank you Adrian, I didn't remember I reported this issue upstream
earlier this year:
https://github.com/qmx/jitescript/issues/15
A simple cast to List in MethodDefinition and FieldDefinition should fix
this.
Emmanuel Bourg
Le 05/12/2017 à 18:48, Andreas Tille a écrit :
> So either I'm doing this CLASSPATH definition wrong or it does not help.
I think you have to use "export CLASSPATH" in debian/rules
Le 05/12/2017 à 14:09, Andreas Tille a écrit :
> Hmmm, the lib/batik*.jar files removed from the upstream tarball contain
> files from 2008 - one of these has version 1.7 in the file name while I
> was building against 1.9.
>
> Should I approach upstream about this issue? I'm not sure whether
Le 05/12/2017 à 11:31, Andreas Tille a écrit :
> A, thanks a lot for reading aloud the docs for me (and sorry for
> bothering you about this :-( ).
No need to be sorry, this wasn't obvious ;)
> Any hint how to solve this one?
I don't know, maybe it needs a more recent version of Batik?
e openjfx package"
Emmanuel Bourg
Good catch. Actually it should depend on maven-resolver, eclipse-aether is
about to be removed.
Emmanuel Bourg
Le 15/11/2017 à 17:56, Emmanuel Bourg a écrit :
> I suspect we build the aspectj eclipse plugin but don't even install it
> in the binary package. I'll see if this can be disabled.
Long story short, it can't. aspectj deeply depends on eclipse jdt. Also
upgrading to the latest version
I'll see if this can be disabled.
Emmanuel Bourg
Control: reassign -1 aether-ant-tasks
Control: affects -1 scala
This is indeed an issue with aether-ant-tasks which is missing a
classpath entry for sisu-plexus.jar.
aether-ant-tasks. I'll look into this.
Emmanuel Bourg
Le 21/10/2017 à 00:33, Markus Koschany a écrit :
> Please claim this bug or tell me when you start to work on something
> related to Eclipse or Tycho, so that we avoid double work.
For now I'm just working on swt4-gtk. I'll ping the list if I feel ready
for some tycho/eclipse action.
Le 20/10/2017 à 23:52, Jeremy Bicha a écrit :
> Never mind. I tried doing the dak queries and I eventually got more
> than 500 reverse-depends before I gave up. (Attached)
Funny, I never realized that src:eclipse was basically holding most of
the Java packages. Maybe this package deserves some
Le 20/10/2017 à 21:40, Jeremy Bicha a écrit :
> I see a similar issue with Help>Documentation with tuxguitar 1.2-23
> (from unstable). Installing libwebkitgtk-3.0-0 fixes it. It does not
> seem to recognize libwebkit2-gtk-4.0-37. But please fix it to not need
> libwebkitgtk-3.0-0 since we are
Le 20/10/2017 à 20:41, Jeremy Bicha a écrit :
> Hopefully, this one can be fixed by just having
> libswt-webkit-gtk-4-jni depend on libwebkit2gtk-4.0-37
Thank you for the hint Jeremy, this might even fix the embedded browser
issue I noticed with Azureus/Vuze. I'll give it a try.
Emmanuel Bourg
(Zeppelin, Atlas, Ranger and Knox).
Emmanuel Bourg
[1] https://github.com/kohsuke
[2] https://github.com/kohsuke/libpam4j/issues/18
I ran the Oracle JavaFX demos with the new version and it worked fine
(except the media player but this isn't a regression, something is
probably misconfigured on my machine).
Should I proceed with the upload, or do you want to do it directly?
Emmanuel Bourg
Le 14/10/2017 à 00:30, Markus Koschany a écrit :
> However since we don't have any
> consumers for it at the moment, we could also live with just removing
> it.
+1, let's remove it.
Emmanuel Bourg
Hi,
Quick update on openjfx: the package is back on track, as of version
8u141-b14-3 I eventually managed to get it to build on both amd64 and
i386 in unstable for the first time since January. If the tests go well
I'll prepare the security update next week.
Emmanuel Bourg
-Wl,--no-keep-memory to the linker flags
but it didn't help either (I'm not sure I configured cmake properly though).
Any help would be highly appreciated.
Emmanuel Bourg
w when I'm
ready for a stable-security update.
Emmanuel Bourg
never was?). But if it was tested and it improves the
situation that's fine. We can still do better later.
Emmanuel Bourg
ase? The latest nmu needs to be merged too.
Emmanuel Bourg
this for me.
I share your feelings wrt to pom patching. Removing the
--has-package-version flag is fine until maven-debian-helper learns to
better handle these suffixes.
Emmanuel Bourg
Control: reassign -1 libsejda-io-java
Control: affects -1 libsambox-java
Control: tags -1 + patch
Le 9/09/2017 à 19:53, Markus Koschany a écrit :
> thanks for the patch. However we can just remove the
> --has-package-version option in libsambox-java.poms which will have the
> same effect. This
e version of the package when --has-package-version is
specified (actually the pom version must be less than the package
version, this allows some divergences such as a package with the version
1.2.3+ds1 and the pom with the version 1.2.3). This will allow us to
easily identify and fix the packages affected.
Emmanuel Bourg
Le 6/09/2017 à 14:51, Matthias Klose a écrit :
> rebuilding libsambox-java generates unmet dependency on libsejda-io-java (>=
> 1.1.3.RELEASE)
>
> $ dpkg -I ../libsambox-java_1.0.34-1_all.deb | grep Depends
> Depends: libcommons-io-java, libfontbox2-java (>= 2.0.7), libsejda-io-java
> (>=
>
Le 6/09/2017 à 18:56, Matthias Klose a écrit :
>> - remove the suffix from the version in the pom
>
> doesn't work
>
>> - remove the --has-package-version flag
>
> doesn't work
You did that on libsejda-io-java right?
more.
Emmanuel Bourg
ROR] Earlier versions of assembly-plugin will silently destroy your
file. Fix your descriptor
Emmanuel Bourg
The build currently fails with another error:
[INFO] --- exec-maven-plugin:1.6.0:exec (install gems) @ ruby-tools ---
LoadError: no such file to load -- rubygems/installer
require at org/jruby/RubyKernel.java:961
at
This issue was caused by the update of libqdox2-java. Reverting to the
version 2.0~M3-3 in stretch fixes this issue.
control: reassign -1 libhtmlparser-java 1.6.20060610.dfsg0-6
control: affects -1 jakarta-jmeter
Thank you for the report Lucas. This is a regression introduced
libhtmlparser-java/1.6.20060610.dfsg0-6, I mistakenly renamed the jar
installed in /usr/share/java. This also caused a conflict with
eue.
Emmanuel Bourg
Le 4/08/2017 à 06:20, Andreas Beckmann a écrit :
> Here is a list of files that are known to be shared by both packages
> (according to the Contents file for sid/amd64, which may be
> slightly out of sync):
>
> usr/share/java/htmlparser.jar
Thank you Andreas. I think the /usr/share/java jar
Hi Andreas, this is a duplicate of #870339
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,
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
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!
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
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
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
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
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
). 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
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
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
specify a default encoding. ISO-8859-1 should be a good choice
because any one byte character is considered valid.
Emmanuel Bourg
erefore, 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
Hi Tony,
You are right, thank you for investigating this issue.
Emmanuel
intentional, that's two different packages with different fixes.
Emmanuel Bourg
rtificates-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
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?
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
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
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
a isn't used
in jessie, this CVE can be ignored there.
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.libr
amed 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
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
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
-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
stallation, 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
there is
no need to declare the dependencies on the package.
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
e 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)
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
Control: severity -1 important
Thank you for the report Breno. I'm lowering the severity, I don't think
this is critical to the point the package should be removed from Stretch.
Emmanuel Bourg
moving it.
Emmanuel Bourg
tional mapper (glassfish-toplink-essentials) that is never
used at runtime.
Emmanuel Bourg
, and then compiles them.
There are still a few jar files with compiled classes (junit, saxon,
jsr173, oldxbean) but they aren't used to build the package. So this is
more a matter of cleaning the upstream tarball of unnecessary files than
fixing a severe policy violation.
Emmanuel Bourg
Control: reassign -1 netty 1:4.1.7-1
Control: affects -1 projectreactor
Thank you for spotting this Santiago. This is caused by a regression in
netty 1:4.1.7-1, the Maven pom for the netty-all artifact has incorrect
dependency information.
Emmanuel Bourg
Hi Santiago,
I think this is a duplicate of #851037, it'll be fixed today once
libkryo-java/2.20-6 migrates to testing.
Emmanuel Bourg
ink he should make this decision.
I had a velleity to do something about jspwiki but it hasn't
materialized. I don't use jspwiki nor plan to use it, nobody has
enquired about the package for years and there are good alternatives. I
think it's preferable to remove it until someone really motivated s
this kind of
serialization issue, the real issue is applications relying on
serialization and not sanitizing the input data (i.e. applications
should whitelist the classes allowed to be deserialized, it's impossible
to use Java serialization securely otherwise).
Emmanuel Bourg
Le 13/01/2017 à 09:55, Santiago Vila a écrit :
> My autobuilders do not work that way (with arbitrary build-dependencies).
>
> Please tell me if those versions are in testing, in unstable, or
> something else (I hope it's not experimental, I don't have a chroot
> setup for it).
They are both in
It looks like jalview was broken by the switch from jmol 12.2 to 14.6 in
December. There is a new version in the Git repository (2.10) but it
doesn't build yet.
Emmanuel Bourg
Hi Santiago,
Could you please try again with the latest version of gradle (3.2.1-1
instead of 3.1-2) and gradle-debian-helper (1.5.1 instead of 1.4.4) ?
Emmanuel Bourg
packages are potentially affected.
I plan to revert the modification in Ant and make the field non final.
Emmanuel Bourg
[1] https://github.com/apache/ant/commit/984a03d
[2]
https://github.com/eclipse/eclipse.platform/blob/R4_6_maintenance/ant/org.eclipse.ant.core/src_ant/org/eclipse/ant
control: reassign -1 libminlog-java
The groupId of minlog changed in libminlog-java/1.3.0, the pom in
libkryo-java must be updated.
Emmanuel Bourg
control: reassign -1 libminlog-java
Thank you for the report Lucas.
The groupId of minlog changed in libminlog-java/1.3.0, the pom in
libkryo-java must be updated.
Emmanuel Bourg
control: severity -1 normal
The build failure caused by JFlex has been fixed. I don't think there is
a license issue with the rsc files but for clarity it would be good to
explain this in debian/copyright.
,
Emmanuel Bourg
401 - 500 of 774 matches
Mail list logo
