Project

General

Profile

Bug #15460

Test suite broken with Java 9+

Added by intrigeri 8 months ago. Updated 3 months ago.

Status:
In Progress
Priority:
Elevated
Assignee:
Category:
Test suite
Target version:
Start date:
03/27/2018
Due date:
% Done:

20%

Estimated time:
14.00 h
QA Check:
Feature Branch:
Type of work:
Debian
Blueprint:
Starter:
Affected tool:

ruby-rjb_1.5.5-2_amd64.build (18 KB) lamby, 05/03/2018 03:02 AM


Related issues

Blocks Tails - Feature #13241: Core work 2018Q2 → 2019Q2: Test suite maintenance Confirmed 06/29/2017
Blocks Tails - Bug #15953: Make our test suite survive changes in the surrounding environment Confirmed 09/14/2018

History

#1 Updated by anonym 8 months ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

intrigeri wrote:

At least:

So this one we have a workaround for (copy-paster from the Debian bug):

    mkdir -p /usr/lib/jvm/jre/lib/amd64/server/
    ln -s /usr/lib/jvm/java-9-openjdk-amd64/lib/server/libjvm.so \
          /usr/lib/jvm/jre/lib/amd64/server/libjvm.so

This one requires packaging SikuliX 1.1.2 for Debian, so using Java 9 is still out of the question...


... so let's just Java 8 for now:

# When Java 8 is dropped from unstable, set to "stable" instead
DIST=unstable
sudo apt install openjdk-8-j{re,dk}{,-headless}/${DIST}
sudo update-java-alternatives -s java-1.8.0-openjdk-amd64

#3 Updated by intrigeri 8 months ago

Actually, regarding rjb at least: this could be a great opportunity for you (anonym) to get involved a bit in Debian: you're one of the few people who understand anything about this Java+Ruby thing and it might be more pleasurable for you to submit a fix than to find someone else to do it.

#4 Updated by intrigeri 7 months ago

  • Blocks Feature #13241: Core work 2018Q2 → 2019Q2: Test suite maintenance added

#5 Updated by intrigeri 7 months ago

  • Assignee deleted (anonym)

#6 Updated by intrigeri 7 months ago

  • Assignee set to lamby
  • Target version changed from Tails_3.7 to Tails_3.8

Wrt. rjb Lunar won't mind help and will not have time to work on this any time soon => NMU / team upload welcome.

#7 Updated by intrigeri 7 months ago

  • Estimated time set to 4.00 h

#8 Updated by lamby 7 months ago

  • Subject changed from Test suite is broken with Java 9 to ruby-rjb test suite broken with Java 9

I've fixed the FTBFS and testsuite failures here:

https://bugs.debian.org/874146#28

What are the next steps here?

#9 Updated by lamby 7 months ago

lamby wrote:

I've fixed the FTBFS and testsuite failures here:

https://bugs.debian.org/874146#28

What are the next steps here?

Should I be pushing this fix in Debian for an easier "merge" or shall I upload to Tails? :)

#10 Updated by lamby 7 months ago

Just let me know :)

#11 Updated by intrigeri 7 months ago

I've fixed the FTBFS and testsuite failures here:

\o/

What are the next steps here?

Announce your intent to NMU, wait a bit (I'll ask Lunar if he's fine with it) and then upload :)

#12 Updated by intrigeri 7 months ago

Should I be pushing this fix in Debian for an easier "merge" or shall I upload to Tails? :)

This package is only required for Tails developers who run the test suite on their sid system, so uploading to Debian makes much more sense here that uploading to a Tails-only repo.

#13 Updated by intrigeri 7 months ago

Just let me know :)

Pro tip: when asking someone's input here, assign to them and set "QA Check" to "Info Needed" :)

#14 Updated by lamby 7 months ago

Announce your intent to NMU

Thanks. Done here: https://bugs.debian.org/874146#35

Pro tip: when asking someone's input here, assign to them and set "QA Check" to "Info Needed" :)

Thanks! I guess I didn't know whom to assign to really, but I should have assigned to someone at the very least! :p

#15 Updated by intrigeri 7 months ago

I guess I didn't know whom to assign to really, but I should have assigned to someone at the very least! :p

Generally, for Foundations Team work, unless someone else (most likely anonym) is explicitly your team-mate/mentor, assigning to me is best.

#16 Updated by lamby 7 months ago

  • Status changed from In Progress to Fix committed
  • Assignee changed from lamby to intrigeri

ruby-rjb 1.5.5-2 uploaded that fixes this :)

#17 Updated by intrigeri 7 months ago

  • Subject changed from ruby-rjb test suite broken with Java 9 to Test suite broken with Java 9
  • Status changed from Fix committed to In Progress
  • % Done changed from 10 to 20
  • Type of work changed from Code to Debian

Thanks lamby!

So half of the problem (the part you committed to work on) is presumably fixed.

Now, two things.

First, I'm a bit confused. With Java 9 and this updated ruby-rjb (up-to-date sid) I still see the RuntimeError: Constants DL and Fiddle is not defined. error that we saw during the FTBFS on https://bugs.debian.org/874146:

$ ./run_test_suite --view  --iso ~/ftp/iso/tails/tails-amd64-3.6.2/tails-amd64-3.6.2.iso
Virtual X framebuffer started on display :1
VNC server running on: localhost:5900
Constants DL and Fiddle is not defined. (RuntimeError)
/usr/lib/ruby/vendor_ruby/rjb.rb:79:in `load'
/usr/lib/ruby/vendor_ruby/rjb.rb:79:in `load'
/srv/tails/git/features/support/helpers/sikuli_helper.rb:5:in `<top (required)>'
/usr/lib/ruby/vendor_ruby/cucumber/rb_support/rb_language.rb:96:in `load'
/usr/lib/ruby/vendor_ruby/cucumber/rb_support/rb_language.rb:96:in `load_code_file'
/usr/lib/ruby/vendor_ruby/cucumber/runtime/support_code.rb:142:in `load_file'
/usr/lib/ruby/vendor_ruby/cucumber/runtime/support_code.rb:84:in `block in load_files!'
/usr/lib/ruby/vendor_ruby/cucumber/runtime/support_code.rb:83:in `each'
/usr/lib/ruby/vendor_ruby/cucumber/runtime/support_code.rb:83:in `load_files!'
/usr/lib/ruby/vendor_ruby/cucumber/runtime.rb:253:in `load_step_definitions'
/usr/lib/ruby/vendor_ruby/cucumber/runtime.rb:61:in `run!'
/usr/lib/ruby/vendor_ruby/cucumber/cli/main.rb:32:in `execute!'
/bin/cucumber:7:in `<main>'

And indeed, the autopkgtests fail in just the same way: https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-rjb/225136/log.gz. So I wonder what's going on: it seems that lamby's patch fixed the problem for the package build but not at runtime.

But if I export JAVA_HOME=/usr/lib/jvm/java-9-openjdk-amd64 then rjb does load (confirmed by adding a few puts) but then SikuliX aborts the process:

./run_test_suite --view  --iso ~/ftp/iso/tails/tails-amd64-3.6.2/tails-amd64-3.6.2.iso
Virtual X framebuffer started on display :1
VNC server running on: localhost:5900
[error] RunTimeINIT:  *** terminating: Java version must be 1.7 or later!

… which is the symptom of the second problem I'm summing up below.

So it looks like rjb now needs JAVA_HOME to be set, otherwise it fails to load; OK, why not, we can do this (actually we used to). I suspect the autopkgtests should do the same.

Secondly, the remaining problem is that SikuliX 1.1.1 does not support Java 9. Apparently SikuliX 1.1.2 should support it: the Changelog version 1.1.2 --- final per March 10th 2018 reads "most JAVA 9 problems are fixed" => I've reported https://bugs.debian.org/897215. Next step here is to test if SikuliX 1.1.2 fixes this problem and if it does, get it into Debian… which might be non-trivial given the process seems quite involved and upstream has switched to another Git repo again. Let's give the maintainers a couple weeks to answer but if they don't I'll check with lamby whether this bonus task fit into the 4h budget (and if not, how much more is needed).

In passing, I've tried anonym's workaround (#15460#note-1) + export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 + sudo ln -s /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/server (to cope with the change lamby uploaded), and I see the Constants DL and Fiddle is not defined. (RuntimeError) error. So it looks like our workaround is not working anymore.

#18 Updated by lamby 7 months ago

Since I fixed the FTBFS, the toolchain has changed so the build is now failing:

https://gist.github.com/lamby/9bd4d19faeaad9eb17aef98a0eb5bd0f/raw (attached as ruby-rjb_1.5.5-2_amd64.build)

I just had a quick poke (looks like an OpenJDK9 vs OpenJDK10 issue wrt http://openjdk.java.net/jeps/313) but I'm going to be hitting my 4h on this issue alas. Go longer? :)

#19 Updated by lamby 6 months ago

(I've filed the FTBFS as https://bugs.debian.org/897664)

#20 Updated by intrigeri 6 months ago

  • Subject changed from Test suite broken with Java 9 to Test suite broken with Java 9+
  • QA Check set to Info Needed

#21 Updated by intrigeri 6 months ago

  • Assignee changed from intrigeri to lamby
  • Estimated time changed from 4.00 h to 6.00 h
  • QA Check deleted (Info Needed)

Can you please fix the ruby-rjb FTBFS in Debian (and submit a PR upstream)? I guess that 2 hours should be enough to replace the single call to javah. BTW, older build logs might be useful: there's been warnings in there for a while telling us that javah was deprecated and suggesting how to replace it :)

#22 Updated by lamby 6 months ago

  • Assignee changed from lamby to intrigeri

Sure thing!

#23 Updated by lamby 6 months ago

Fixed in Debian, uploaded as 1.5.5-2

I meant 1.5.5-3 here, sorry

#24 Updated by intrigeri 6 months ago

Great! So we're good wrt. ruby-rjb. Chris, please tell me how much of the 6 hours you've used and I'll validate your work in our accounting :)

The next steps (SikuliX) are documented on #15460#note-17. Let's wait a couple more weeks (until our next FT meeting) to give the maintainers the chance to address https://bugs.debian.org/897215 and then we'll see.

#25 Updated by lamby 6 months ago

please tell me how much of the 6 hours you've used and I'll validate your work in our accounting :)

Any objection if we do that in one "batch" with the other tickets to keep our overheads low? :)

#26 Updated by intrigeri 6 months ago

please tell me how much of the 6 hours you've used and I'll validate your work in our accounting :)

Any objection if we do that in one "batch" with the other tickets to keep our overheads low? :)

OK, let's try!

#27 Updated by lamby 6 months ago

intrigeri wrote:

The next steps (SikuliX) are documented on #15460#note-17. Let's wait a couple more weeks (until our next FT meeting) to give the maintainers the chance to address https://bugs.debian.org/897215 and then we'll see.

I have:

  • Asked the Java maintainers whether they would like me to update it.

#28 Updated by lamby 6 months ago

Noting RM bug #897333.

#29 Updated by intrigeri 6 months ago

WIP SikuliX 1.1.2 packaging (broken at runtime according to the former maintainer): https://salsa.debian.org/java-team/sikuli

#30 Updated by intrigeri 6 months ago

  • Priority changed from Normal to Elevated

#31 Updated by intrigeri 6 months ago

  • Assignee changed from intrigeri to lamby
  • QA Check set to Info Needed

Dear Chris,

sorry I forgot to raise this topic at the end of our FT meeting (while I had mentioned it earlier). I'd like us to assess the SikuliX situation so we can make a decision for Tails (and maybe for Debian). To start with I'd like to have an idea of:

  • How far is the current WIP packaging of 1.1.2 from working on testing/sid (according to it "is completely broken at
    runtime") in a X.Org environment? Maybe 1.1.3 fixes some of that?
  • What would the minimal maintenance cost of SikuliX in Debian would look like? I guess that importing upstream 1.1.3 could give an idea of the mess is talking of.
  • What's the deal with Wayland? Note that Tails does not use it yet: #12213. says that he has "tested version 1.1.1 currently in unstable and testing and it is broken as well, probably because of the migration to Wayland". But I'm running GNOME on Wayland on sid and SikuliX 1.1.1 worked just fine to run the Tails test suite before Java 9 became the default; I suspect that mixed up "SikuliX 1.1.1 does not support Java 9" with "Sikuli is broken with Wayland" or similar. But I've not tested Sikuli to exercise an OS that runs Wayland so I dunno, it may very well be that is correct! It would be interesting to know if we're using any part of Sikuli that rely on X.Org and will break on Wayland. I'm not even sure how exactly we wire Sikuli with the VM under test.

Upstream publishes no Git tag so I think I start to understand what Gilles is talking of…

Once we have this info it'll be easier to decide whether we take over maintenance of SikuliX in Debian, or we start maintaining it for Tails only (in case the previous option is too costly/crazy and we can live with a cheap crappy version for Tails), or we research alternatives to Sikuli.

Are you interested to look into this? Do you think you can answer these questions in 8 hours? (I would say just try, report back shortly before running out of time, and how much progress you'll have made in 8h will already teach us something.) IIRC you did not want more work in June, so: can you do this in July? (Rationale: I'd like us to make a decision in time for the Buster freeze :)

#32 Updated by lamby 6 months ago

  • Assignee changed from lamby to intrigeri

ACK all these difficult questions!

Are you interested to look into this? Do you think you can answer
these questions in 8 hours?

As I'm sure you can understand at this point, I simply can't tell
without jumping into packaging 1.1.3. :) Will indeed just try and
report back if/when running out of time. I should find time for this
in June.

My gut tells me we should look into alternatives given all these
problems we know about.

(pinging bug back and forth for visibility)

#33 Updated by lamby 6 months ago

  • Assignee changed from intrigeri to lamby

#34 Updated by intrigeri 6 months ago

  • Estimated time changed from 6.00 h to 14.00 h
  • QA Check deleted (Info Needed)

Great! (updating total budget => 6 + 8 = 14)

#35 Updated by intrigeri 5 months ago

  • Target version changed from Tails_3.8 to Tails_3.9

#36 Updated by lamby 3 months ago

During summit we roughly scheduled this as being targetted for Dec/Jan 2018/2019.

#37 Updated by intrigeri 3 months ago

  • Target version changed from Tails_3.9 to Tails_3.12

lamby wrote:

During summit we roughly scheduled this as being targetted for Dec/Jan 2018/2019.

Right, updating target version accordingly :)

#38 Updated by intrigeri 2 months ago

  • Blocked by Bug #15953: Make our test suite survive changes in the surrounding environment added

#39 Updated by intrigeri 2 months ago

  • Blocked by deleted (Bug #15953: Make our test suite survive changes in the surrounding environment)

#40 Updated by intrigeri 2 months ago

  • Blocks Bug #15953: Make our test suite survive changes in the surrounding environment added

Also available in: Atom PDF