Bug#893547: ant: please do not emit --ignore-source-errors on Java 9

[Ole Streicher]

Hi Tony,


On 20.03.2018 05:20, tony mancill wrote:
> I'm in the midst of preparing an update for ant.  Is there any context
> in which we want to add "--ignore-source-errors" to the ant javadoc
> task, or should this patch [1] be removed entirely?
>

I am not familar with ant, so I can't recommend here. The failure seems
to not generally appear, but only on specific targets.

This is the snippet that produces the error:

    

while this one (from another package, starjava-pal) works fine:

    

So, it may have something to do with the doclet.

Best

Ole

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#893547: ant: please do not emit --ignore-source-errors on Java 9

[Ole Streicher]

Package: ant
Version: 1.9.9-6
Severity: serious

Dear maintainer,

to fix #884187, ant added the option "--ignore-source-errors" to
javadoc. This option is however not available on Java 9, which leads to
FTBFS on some packages: starjava-topcat, starjava-tools. I will merge
the relevant bug reports.

Best regards

Ole

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#892156: xsl:number throws an exception

[Ole Streicher]

Package: libsaxonhe-java
Version: 9.8.0.8+dfsg+1-1
Severity: serious
Control: reassign 892119 libsaxonhe-java
Control: forcemerge -1 892119
Control: affects -1 src:starjava-topcat
Control: reassign 892120 libsaxonhe-java
Control: forcemerge -1 892120
Control: affects -1 src:starjava-ttools

When using xsl:number in an xslt script, saxon throws an exception:

$ cat sheet.xsl

http://www.w3.org/1999/XSL/Transform;>

  

  

$ java -jar /usr/share/java/Saxon-HE.jar sheet.xsl sheet.xsl
Exception in thread "main" java.lang.ExceptionInInitializerError
at
net.sf.saxon.expr.number.NumberFormatter.(NumberFormatter.java:124)
at net.sf.saxon.style.XSLNumber.prepareAttributes(XSLNumber.java:159)
at 
net.sf.saxon.style.StyleElement.processAttributes(StyleElement.java:634)
at
net.sf.saxon.style.StyleElement.processAllAttributes(StyleElement.java:579)
at
net.sf.saxon.style.StyleElement.processAllAttributes(StyleElement.java:584)
at
net.sf.saxon.style.XSLTemplate.processAllAttributes(XSLTemplate.java:397)
at
net.sf.saxon.style.PrincipalStylesheetModule.processAllAttributes(PrincipalStylesheetModule.java:609)
at
net.sf.saxon.style.PrincipalStylesheetModule.preprocess(PrincipalStylesheetModule.java:386)
at net.sf.saxon.style.Compilation.compilePackage(Compilation.java:288)
at
net.sf.saxon.style.StylesheetModule.loadStylesheet(StylesheetModule.java:258)
at
net.sf.saxon.style.Compilation.compileSingletonPackage(Compilation.java:106)
at net.sf.saxon.s9api.XsltCompiler.compile(XsltCompiler.java:739)
at net.sf.saxon.Transform.doTransform(Transform.java:709)
at net.sf.saxon.Transform.main(Transform.java:81)
Caused by: java.lang.RuntimeException: Unable to read categories.xml file
at net.sf.saxon.regex.charclass.Categories.build(Categories.java:116)
at 
net.sf.saxon.regex.charclass.Categories.getCategory(Categories.java:206)
at net.sf.saxon.regex.charclass.Categories.(Categories.java:180)
... 14 more


This is an regression and did not happen with version 9.7. It leads to
FTBFS in the topcat and ttools packages; therefore the severity.

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Ole Streicher]

For me as well...

On 16.10.2017 15:59, Andreas Tille wrote:
> On Mon, Oct 16, 2017 at 03:12:38PM +0200, Markus Koschany wrote:
>> I am just cleaning up a bit. Is there any reason why we should keep
>> libbrowserlauncher-java in Debian? Apparently its features are provided
>> by the JDK nowadays and it seems to have no r-deps anymore.
>>
>> If I don't hear anything from you, I'm going to reassign this package to
>> ftp.debian.org and ask for its removal.
> 
> Fine for me, Andreas.
> 
> 

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Ole Streicher]

Hi Emmanuel,

Am 04.04.2017 um 10:52 schrieb Emmanuel Bourg:
> Excellent question, this needs some testing with various desktop
> environments.

I wrote a short test script and run it under Stretch and Jessie chroots,
right after

(jessie)oles@donar:~$ sudo apt install default-jre

---8<--
import java.awt.Desktop;
import java.net.URI;

class DesktopTest {
public static void main(String[] args) throws Exception {
System.out.println("isDesktopSupported()="
   + Desktop.isDesktopSupported());
Desktop d = Desktop.getDesktop();
System.out.println("Desktop=" + d);
System.out.println("Browse supported="
   + d.isSupported(Desktop.Action.BROWSE));
d.browse(new URI("https://www.debian.org;));
}
}
---8<--

with the following output:

(jessie)oles@donar:~$ java Desktop
isDesktopSupported()=true
Desktop=java.awt.Desktop@669e9a07
Browse supported=true
Exception in thread "main" java.io.IOException: Failed to show
URI:https://www.debian.org
at sun.awt.X11.XDesktopPeer.launch(XDesktopPeer.java:114)
at sun.awt.X11.XDesktopPeer.browse(XDesktopPeer.java:98)
at java.awt.Desktop.browse(Desktop.java:386)
at Desktop.main(Desktop.java:9)

So, on a default (not headless) Java installation, Java claims to both
isDesktopSupported() and isSupported(Desktop.Action.BROWSE).

The exception may be due to the fact that my Browser was running outside
of the schroot, that the dbus was not started ("xdg-open" shows this as
error), or that some other required component is not there.

Desktop#browse() calls the native function gnome_url_show() in
XDesktopPeer.java:

https://developer.gnome.org/libgnome/stable/libgnome-gnome-url.html

Best regards

Ole

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Ole Streicher]

Am 30.03.2017 um 14:14 schrieb 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)

That is even better. I didn't know that, thanks for the hint. IMO that
makes the BrowserLauncher package *really* obsolete here.

For #859107, I will prepare another patch.

Cheers

Ole

__
This is the maintainer address of Debian's Java team
<http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#859004: Let's remove BrowserLauncher from Stretch

[Ole Streicher]

Tags: affects -1 jmodeltest

I submitted fixes for all three bugs to the git repository. However,
even after applying them libbrowserlauncher does not work:

$ java -classpath /usr/share/java/BrowserLauncher2.jar \
 edu.stanford.ejalbert.BrowserLauncher https://www.debian.org

should display a web page in the default browser, but does nothing.

The package is also unfortunate since it establishes a secondary browser
selection and is not conform to the freedesktop.org specification
("xdg-open").

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).

Best regards

Ole
package edu.stanford.ejalbert;

import java.io.IOException;

/*
 * Simple replacement for the BrowserLauncher, which is compatible to the
 * Free Desktop Consortium.
 */
public class BrowserLauncher {
public void openURLinBrowser(String url)  {
	try {
	Runtime.getRuntime().exec(new String[] { "xdg-open", url } );
	} catch (IOException e) {
	}
}
public void setNewWindowPolicy(boolean b) {
}
}
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#859005: libbrowserlauncher-java: properties file not included

[Ole Streicher]

The properties file also contains a bug the prevents from using
IceWeasel even when it would be included. So, when fixing this, the
attached patch should be applied as well.

I can't do this myself since I just realized that I am not in the
java-maintainers group.

Cheers

Ole
>From 69e74fe6a26e7ce4a3716607b2330d5fbe8b76b2 Mon Sep 17 00:00:00 2001
From: Ole Streicher <oleb...@debian.org>
Date: Wed, 29 Mar 2017 15:41:52 +0200
Subject: [PATCH] Fix typo for browser start

---
 debian/patches/browser_choice.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/patches/browser_choice.patch b/debian/patches/browser_choice.patch
index 3c90687..bf5539b 100644
--- a/debian/patches/browser_choice.patch
+++ b/debian/patches/browser_choice.patch
@@ -12,7 +12,7 @@ Last-Update: Wed, 11 May 2016 13:31:20 +0200
 -browser.mozilla=Mozilla;mozilla; ; -remote openURL()
 -browser.netscape=Netscape;netscape; ; -remote openURL()
  browser.firefox=FireFox;firefox; ; -new-tab ; -new-window 
-+browser.ceweasel=IceWeasel;iceweasel; ; -new-tab ; -new-window 
++browser.iceweasel=IceWeasel;iceweasel; ; -new-tab ; -new-window 
  browser.mozilla-firefox=FireFox;mozilla-firefox; ; -remote openURL(); -new-window 
  browser.konqueror=Konqueror;kfmclient; openURL ; newTab ; openURL 
  browser.opera=Opera;opera; ; -newpage ; -newwindow 
-- 
2.11.0

__
This is the maintainer address of Debian's Java team
<http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Ole Streicher]

Hi Markus,

Am 29.03.2017 um 15:46 schrieb Markus Koschany:
> In the case of backports you would probably backport jmodeltest as well,
> so both could be easily kept in sync. AFAICT both packages seem to work
> well together and librowserlauncher-java was only packaged to build
> jmodeltest from source.

Not necessarily. I am currently preparing another dependency (topcat,
#855797) and plan to backport it later to Stretch -- this is why I look
into browserlauncher2.

Cheers

Ole

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Ole Streicher]

Hi Markus,

Am 29.03.2017 um 15:15 schrieb Markus Koschany:
>> There is no jar without a version number. This makes it impossible to
>> add the jar to the CLASSPATH of other packages,
> 
> This is not true. You can add such jar files to your CLASSPATH.
>> since the file name will change silently with the next version.
> 
> This is true.

This is my point: we cannot rely on it.

>> Therefore, please include also a versionless jar file
>> BrowserLauncher2.jar. This is also requested by Java policy.
> 
> Java Policy is more like Parley from Pirates of the Caribbean and
> incomplete by the way. I suggest to downgrade the bug to "important"
> because it does not affect jmodeltest, the only reverse-dependency at
> the moment and a missing symlink is not release critical in this case
> and can be trivially worked around.

It affects the package: in the moment when a new version is uploaded (my
it be via backports), it will silently break jmodeltest. It will also
silently break local usage, even if the new version would be otherwise
compatible. Both is not acceptable for a release, hence the RC status.

Best regards

Ole

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#859005: libbrowserlauncher-java: properties file not included

[Ole Streicher]

Package: libbrowserlauncher-java
Version: 1.3+dfsg-1
Severity: serious

When using the package, I get the following exception:

edu.stanford.ejalbert.exception.BrowserLaunchingInitializingException:
  unable to find config file: 
/edu/stanford/ejalbert/launching/misc/linuxUnixConfig.properties
 at 
edu.stanford.ejalbert.launching.misc.UnixNetscapeBrowserLaunching.initialize(UnixNetscapeBrowserLaunching.java:171)
 at 
edu.stanford.ejalbert.BrowserLauncher.initBrowserLauncher(BrowserLauncher.java:240)
 at edu.stanford.ejalbert.BrowserLauncher.(BrowserLauncher.java:216)
 at edu.stanford.ejalbert.BrowserLauncher.(BrowserLauncher.java:153)
 at 
uk.ac.starlink.topcat.BrowserHelpAction.createBrowserLauncher(BrowserHelpAction.java:62)
[...]

It seems that the properties are not included in the package,
which makes it quite useless:

$ unzip -l /usr/share/java/BrowserLauncher2-1_3.jar |fgrep properties

Please include at least the properties relevant for Debian here.

Cheers

Ole

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#859004: libbrowserlauncher-java has the wrong architecture

[Ole Streicher]

Package: libbrowserlauncher-java
Version: 1.3+dfsg-1
Severity: important

The package is Arch: any, but since it is pure Java, it should be Arch:all.

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Ole Streicher]

Package: libbrowserlauncher-java
Version: 1.3+dfsg-1
Severity: serious

The package contents are (mainly):

/usr/share/java/BrowserLauncher2-1_3-1.3.jar
/usr/share/java/BrowserLauncher2-1_3.jar -> BrowserLauncher2-1_3-1.3.jar

There is no jar without a version number. This makes it impossible to
add the jar to the CLASSPATH of other packages, since the file name will
change silently with the next version.

Therefore, please include also a versionless jar file
BrowserLauncher2.jar. This is also requested by Java policy.

Best regards

Ole

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#857921: Cache dir in Jython

[Ole Streicher]

One remark here for both bugs: IMO, the cache implementation and setup
in Jython as it is now is quite useless for Debian: If a normal user
runs Jython without setting python.cachedir to a user-writable location,
he will get warnings that he can't update the cache. If he is doing so,
he will not profit from the central cache.

The solution often found in the net (making the cache read/writable for
all users) is probably a security problem, since then anyone can
compromise the cache.

So, I would propose just to switch off the caching
(python.cachedir.skip=true), and let it up to the user to re-enable it
(with proper settings for his problem) if required. Anyway, two
modifications shold be done to resolve #857922 independent of this:

* change the cache dir to /var/cache/jython or similar, even if disabled
* clean up this cache when the package is removed/purged

Any thoughts here?

Best regards

Ole

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#857922: Jython cache dir in /usr/

[Ole Streicher]

Package: jython
Version: 2.5.3-15
Severity: serious

The (system) Jython cache dir is in /usr/share/jython/Cache, while the
FHS wants to have it in /var/cache/.

This is problematic, since the cache may tend to be filled by the
installation of Jython packages or by other Jython invocations as root,
but is never cleaned up explicitely.

Best regards

Ole

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#857921: Unwritable cache for new jars

[Ole Streicher]

Package: jython
Version: 2.5.3-15
Severity: normal

when I use jython to import from a jar as a user, I get the following
messages:

>>> import sys
>>> sys.path.append('/usr/share/java/adql.jar')
>>> import adql
*sys-package-mgr*: processing new jar, '/usr/share/java/adql-1.3.jar'
*sys-package-mgr*: can't write cache file for '/usr/share/java/adql-1.3.jar'
*sys-package-mgr*: can't write index file

since the cache dir is not writeable for the ordinary user.
Maybe this should have been set to the user's home dir if started by a user?

Best regards

Ole

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#855689: jython.jar does not provide a Class-Path

[Ole Streicher]

Hi Gilles,

Am 21.02.2017 um 22:09 schrieb Gilles Filippini:
> Would the attached patch do the trick?

yes, I can confirm that this works well for me. Thank you for the quick fix.

Best regards

Ole

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#855689: jython.jar does not provide a Class-Path

[Ole Streicher]

Package: jython
Version: 2.5.3-14
Severity: serious

There is no classpath for the dependencies of jython.jar defined in its
manifest:

$ unzip -p /usr/share/java/jython.jar META-INF/MANIFEST.MF | \
  grep Class-Path
$

This leads to the problem that dependent packages need to specify the
classpath themself, which is difficult since it is not documented in
/usr/share/docs/jython. Also, it requires tracking internal changes of
jython, since some of the dependent jar names are version dependent;
namely antlr3-runtime-3.2.jar, which makes it difficult to handle for
the dependencies over long time (f.e. for backports).

Java policy requires to have the classpath documented. I would ask you
to do this in the manifest (at least for the strong dependencies), since
this makes the usage much easier.

Thank you very much

Best regards

Ole

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.