Hi,
Please cherry-pick this patch:
http://svn.apache.org/viewvc?view=revision=1805148
Also note that upstream has a 1.9.1 release that apparently fixes the poms.
Regards,
Erich
__
This is the maintainer address of Debian's Java team
reopen 875322
thanks
Two issues still persist:
1. A dependency on org.python:jython, that either should be optional, or
that must be a debian dependency, too.
It appears to work (for ELKI) without Jython - but this dependency does
exist in mavencentral, so it may be necessary to add a
Hi,
I will try to double-check this, but I'm constantly short on time these
days.
I didn't modify visualvm.conf
But by any means, by looking at the source don't you think it should be -J
rather than -L?
Even if e.g. the bug only appears because Java 9 fails to start with -L,
whereas maybe java 8
Package: visualvm
Version: 1.3.9-1
Severity: grave
Justification: renders package unusable
visualvm does not start anymore with the error:
Unknown option -L-XX:PermSize=32m
This is caused by a trivial typo in the start script, which supposedly
should use -J (like "Java options") instead of -L
Package: maven-debian-helper
Version: 2.0.1
Severity: normal
Maven 3 allows specifying minimum and maximum version dependencies.
For example, it is possible to specify a junit dependency "[4.8,)" as
"4.8 and later".
maven-debian-helper does not appear to understand this syntax:
---
Resolving
Maven plugins are
re-uploaded to include a "debian" version.
Best regards,
Erich
On Sun, Jan 3, 2016 at 4:31 PM, Emmanuel Bourg <ebo...@apache.org> wrote:
> Le 3/01/2016 15:51, Erich Schubert a écrit :
>
>> Maven 3 allows specifying minimum and maximum version dependencies
Hello Mathieu,
The annoying part is that even the Batik documentation still contains
the old package name:
https://xmlgraphics.apache.org/batik/using/dom-api.html
It is well possible that many of the dependencies do not use this
class. I'm not sure if there might be indirect dependencies that
Hello,
The next ELKI version will be compatible with Batik 1.8 and 1.7.
Please, if uploading batik to unstable, add a
Breaks: elki (= 0.6.5)
to the control file. ELKI 0.7.0 will be compatible with both batik versions.
Regards,
Erich
__
This is the maintainer address of Debian's Java team
Unfortunately, Batik 1.8 appears to be incomatible to Batik 1.7
Therefore, upgrading the package without bumping the name will cause
many applications to break.
E.g. for ELKI I had to limit Batik to the latest 1.7 version in the pom.
See:
severity 774745 important
thanks
According to
https://issues.apache.org/jira/browse/BIGTOP-1476
Maven 3.0 cannot build Hadoop. Maven 3.2 is reported to fix the issues.
It seems maven 3.0 fails to correctly resolve some dependencies?
Regards,
Erich
__
This is the maintainer address of Debian's
Hello Luca,
some files have the following license header:
// Copyright (c) 1999 CERN - European Organization for Nuclear Research.
// Permission to use, copy, modify, distribute and sell this software and
// its documentation for any purpose is hereby granted without fee,
// provided that
Hello Java team,
Reject Reasons:
'dpkg-source -x' failed for trove3_3.0.2-1.dsc. (Command '('dpkg-source',
'--no-copy', '--no-check', '-q', '-x', 'trove3_3.0.2-1.dsc',
'/srv/ftp-master.debian.org/tmp/tmpEWgHjK/root')' returned non-zero exit
status 9)
Any idea what might be causing this?
tag 671295 + patch
thanks
As a quick followup:
According to apt-cache rdepend libtrove-java, there are no packages
depending on trove.
So we can probably just upgrade the package to Trove 3 without
breaking too much.
(Well, there could be third party packages. But most of the time,
third parties
Package: libtrove-java
Version: 2.1.0-2
Severity: important
Dear Maintainers,
For updating the ELKI package, I'd need an updated trove 3 package,
as ELKI does not build against Trove 2.
I believe that Trove 2 and 3 do not have the same API, but deliberately can
coexist. Therefore, it may be
Hi all,
GNU Trove3 packaging requires only slight changes to the trove 2 package.
You can find my efforts at:
http://people.debian.org/~erich/trove3/
The build patch needs refreshing only, I did a small change to the
tarball creation script (as it contains a folder named just 3.0.2
instead of
Package: java-wrappers
Version: 0.1.24
Severity: normal
Weka 3.7.5 (but with the Debian launcher script, using java-wrappers) would not
start for me, with some NullPointerException after a long startup time. Looking
at the command run, it invokes this:
/usr/lib/jvm/java-6-openjdk-i386/bin/java
Hi,
In case you are interested, I've prepared a Weka 3.7.5 package (i.e.
current development version) at
http://www.cip.ifi.lmu.de/~schubert/weka/
The move from 3.6 to 3.7 required some changes to the build process,
as it was relying on a precompiled .jar for the package manager (which
doesn't
; eclipse won't open or parse ant build.xml
files. (Note that I still have ant 1.7 on my system as well).
I also tried the merging trick mentioned, neither helped.
Error is:
java.lang.NoClassDefFoundError: org.apache.tools.ant.Main
just as with the other submitters of this bug.
best regards,
Erich
OR java1-runtime |
OR java2-runtime |
libxerces2-java | 2.9.1-2
best regards,
Erich Schubert
--
erich@(vitavonni.de|debian.org)--GPG Key ID: 4B3A135C(o_
This one's tricky. You have to use imaginary numbers, like
19 matches
Mail list logo
