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

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

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

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

Bug#892156: xsl:number throws an exception

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

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

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

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

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

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

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 brows

Bug#859004: Let's remove BrowserLauncher from Stretch

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

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

rom 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/debia

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

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

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

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

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

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

Bug#859004: libbrowserlauncher-java has the wrong architecture

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

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

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

Bug#857921: Cache dir in Jython

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

Bug#857922: Jython cache dir in /usr/

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

Bug#857921: Unwritable cache for new jars

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'

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

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

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

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