Bug#934111: jython: add explicit dependency on openjdk-11-jre-headless

2019-08-24 Thread Andreas Beckmann
Followup-For: Bug #934111

Hi,

I've opened a buster-pu request to get this fix into buster:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935465


Andreas



Bug#934111: jython: add explicit dependency on openjdk-11-jre-headless

2019-08-08 Thread Emmanuel Bourg
Le 07/08/2019 à 12:08, Andreas Beckmann a écrit :

> jython bumped the java dependency to >= 9 which is not satisfiable in
> stretch, while other packages seem to still work with java 8
> 
> There are no other packages triggering this problem in piuparts.
> Given that noone reacted to #929685, I'm trying to find a minimal
> workaround suitable for stable.

Ok understood. The right solution in this case is to rebuild jython with
the --release=7 compiler option. This will generate a binary that still
works with previous JREs and the >= 9 constraint can be dropped.

I'll upload a fix shortly, please reopen if piuparts is still not happy.

If it works I think this should be proposed for a stable point update.

Emmanuel Bourg



Bug#934111: jython: add explicit dependency on openjdk-11-jre-headless

2019-08-07 Thread Andreas Beckmann
On 07/08/2019 10.02, Emmanuel Bourg wrote:
> Hi Andreas,
> 
> Le 07/08/2019 à 08:08, Andreas Beckmann a écrit :
> 
>> in order to fix some upgrade issues from stretch to buster due to the
>> dependency cycle between default-jre-headless, openjdk-11-jre-headless
>> and ca-certificates-java (#929685), please add an explicit dependency on
>> openjdk-11-jre-headless to jython as a workaround.
> 
> Could you elaborate a bit on the upgrade issue you encountered? It looks

see #929685 for details

configuration order is

  ca-certificates-java
  default-jre-headless
  jython
  jython-stilts (FAILS)
  openjdk-11-jre-headless

> a bit arbitrary to change the JRE dependency on jython to work around
> the ca-certificates-java dependency cycle, and not on the other
> applications depending on the JRE.

jython bumped the java dependency to >= 9 which is not satisfiable in
stretch, while other packages seem to still work with java 8

There are no other packages triggering this problem in piuparts.
Given that noone reacted to #929685, I'm trying to find a minimal
workaround suitable for stable.

> How did you get this exception? This was triggered by running Java 11
> compiled code on Java 8, it's another issue we have to fix.

default-jre-headless being configured, providing java-9,
while the openjdk links still point to java-8

Andreas



Bug#934111: jython: add explicit dependency on openjdk-11-jre-headless

2019-08-07 Thread Emmanuel Bourg
Hi Andreas,

Le 07/08/2019 à 08:08, Andreas Beckmann a écrit :

> in order to fix some upgrade issues from stretch to buster due to the
> dependency cycle between default-jre-headless, openjdk-11-jre-headless
> and ca-certificates-java (#929685), please add an explicit dependency on
> openjdk-11-jre-headless to jython as a workaround.

Could you elaborate a bit on the upgrade issue you encountered? It looks
a bit arbitrary to change the JRE dependency on jython to work around
the ca-certificates-java dependency cycle, and not on the other
applications depending on the JRE.


> I'm attaching a patch and the piuparts log showing the failure.
> The relevant diff of the upgrade test with the fixed package available
> is:
> 

> @@ -22494,23 +22486,6 @@
>Removing obsolete conffile 
> /etc/dbus-1/system.d/org.freedesktop.resolve1.conf ...^M
>Removing obsolete conffile 
> /etc/dbus-1/system.d/org.freedesktop.systemd1.conf ...^M
>Removing obsolete conffile 
> /etc/dbus-1/system.d/org.freedesktop.timedate1.conf ...^M
> -  Setting up jython-stilts (3.1.5-1) ...^M
> -  Exception in thread "main" java.lang.NoSuchMethodError: 
> java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;^M
> -   at org.python.core.io.BufferedReader.clear(BufferedReader.java:147)^M
> -   at org.python.core.io.BufferedReader.(BufferedReader.java:27)^M

How did you get this exception? This was triggered by running Java 11
compiled code on Java 8, it's another issue we have to fix.

Emmanuel Bourg