Hi,
one of our packages (htsjdk) introduced scalatest dependency with
graddle build file to make their tests.
Anyone working on packaging it (did not find it in Debian) ? Or having
an easy way to patch the build file to use *regular* graddle testing (I
never used graddle) instead of scaltest.
up
Hi Olivier,
Le 12/10/2017 à 10:05, Olivier Sallou a écrit :
> Anyone working on packaging it (did not find it in Debian) ? Or having
> an easy way to patch the build file to use *regular* graddle testing (I
> never used graddle) instead of scaltest.
I'm not aware of anyone working on it. scalate
Fyi,
Forwarded Message
Subject: A lot of packages fixed to build with jdk9
Date: Thu, 12 Oct 2017 08:42:29 +0200
From: Fridrich Strba
To: IcedTea
Hello, good people,
In openSUSE Tumbleweed, our rolling distribution, we switched to
OpenJDK9 as a default Java since a week befor
Hi Fridrich,
Thanks a lot for sharing your work. FYI in Debian we opted for bumping
the source/target level directly at the Ant [1] and Maven [2] level
instead of patching the packages individually. So far we still have ~140
packages to fix [3] before switching the default JRE to OpenJDK 9.
Emman
Le 30/09/2017 à 17:09, Thorsten Glaser a écrit :
> IMHO consistency within Debian is *much* more important.
>
> I would be seriously fucked off if I could connect to a host
> using something like wget but not a Java™ application, after
> installing the custom CA into /etc/ssl/certs or similar, or
Le 12/10/2017 à 11:58, Emmanuel Bourg a écrit :
> 2. ca-certificates-java still generates a keystore from the Debian
> certificates but with a different name (cacerts-debian for example).
> 3. Patch openjdk to use cacerts-debian in priority if it exists, and
> default to cacerts otherwise.
Anothe
Le 2/10/2017 à 23:16, Tiago Daitx a écrit :
> To give an overview of the issue, this happens during install time
> when both openjdk and ca-certificates are being installed because
> /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/jvm.cfg is a symlink
> to /etc/java-8-openjdk/jvm-amd64.cfg (on amd
Hi all,
I started working on OpenJFX 9 this week. The good news is that it
builds fine in Debian now [1]. The bad news is that it's going to be
significantly more challenging to integrate it with our OpenJDK package.
With OpenJDK 8 the integration was just a matter of installing extra jar
files a
Le 10/10/2017 à 13:35, Hideki Yamane a écrit :
> Can someone review below change, please?
Hi Hideki,
This looks good but unfortunately the package dependencies won't help
ensuring that the right version of libjaxb-java is installed to satisfy
the symlink.
Maybe this issue should be addressed i
Hi Emmanuel,
> Similarly I would be seriously fucked off if the application I developed
> on another OS would behave differently once deployed on my Debian server
> with the same version of Java ;)
>
> Both use cases are valid I think, maybe we could have it both ways with
with an upstream hat o
Am 12.10.2017 um 01:12 schrieb Emmanuel Bourg:
[...]
> Could we keep the --has-package-version flags please? If we change the
> behavior of maven-debian-helper in a near future putting them back in
> all packages is going to take a lot of time. There is really no harm
> keeping them for now.
First
> Le 30/09/2017 à 17:09, Thorsten Glaser a écrit :
>
>> IMHO consistency within Debian is *much* more important.
>>
>> I would be seriously fucked off if I could connect to a host
>> using something like wget but not a Java™ application, after
>> installing the custom CA into /etc/ssl/certs or si
Le 12/10/2017 à 13:21, Emmanuel Bourg a écrit :
> Maybe this issue should be addressed in libjaxb-java instead, by adding
> a symlink from /usr/share/java/jaxb-impl.jar to jaxb1-impl.jar. I
> haven't checked if the content of the jars matches.
I checked the package and the right replacement for j
13 matches
Mail list logo