Bug #15460
Test suite broken with Java 9+
20%
Description
Related issues
History
#1 Updated by anonym 11 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 11 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 11 months ago
- Blocks Feature #13241: Core work 2018Q2 → 2019Q2: Test suite maintenance added
#8 Updated by lamby 10 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 10 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? :)
#12 Updated by intrigeri 10 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.
#14 Updated by lamby 10 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
#17 Updated by intrigeri 10 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 10 months ago
- File ruby-rjb_1.5.5-2_amd64.build added
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 10 months ago
(I've filed the FTBFS as https://bugs.debian.org/897664)
#21 Updated by intrigeri 10 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 10 months ago
- Assignee changed from lamby to intrigeri
Sure thing!
- Fixed in Debian, uploaded as 1.5.5-2
- Forwarded upstream here: https://github.com/arton/rjb/pull/63
- Also forwarded https://github.com/arton/rjb/pull/62
#24 Updated by intrigeri 10 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.
#27 Updated by lamby 9 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:
- Updated the severity of https://bugs.debian.org/897215 to
serious
.
- Asked the Java maintainers whether they would like me to update it.
#29 Updated by intrigeri 9 months ago
WIP SikuliX 1.1.2 packaging (broken at runtime according to the former maintainer): https://salsa.debian.org/java-team/sikuli
#31 Updated by intrigeri 9 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 pini@d.o 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 pini@d.o is talking of.
- What's the deal with Wayland? Note that Tails does not use it yet: #12213. pini@d.o 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 pini@d.o 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 pini@d.o 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 9 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)
#38 Updated by intrigeri 5 months ago
- Blocked by Bug #15953: Make our test suite survive changes in the surrounding environment added
#39 Updated by intrigeri 5 months ago
- Blocked by deleted (Bug #15953: Make our test suite survive changes in the surrounding environment)
#40 Updated by intrigeri 5 months ago
- Blocks Bug #15953: Make our test suite survive changes in the surrounding environment added
#42 Updated by intrigeri about 2 months ago
- Target version changed from Tails_3.12 to Tails_3.13