Tails

intrigeri wrote:

At least:

• https://bugs.debian.org/874146

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

• https://github.com/RaiMan/SikuliX-2014/issues/288

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

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

I've fixed the FTBFS and testsuite failures here:

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

What are the next steps here?

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

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.

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? :)

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 :)

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

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 :)

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)

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

lamby wrote:

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

Right, updating target version accordingly :)