The next thing to do was install some of the programs I use the most. NetBeans and Eclipse are right up there, so first stop was Java. I like the idea behind OpenJDK and recognize the push to use it, but I've been bitten many times in the past by performance and display, and outright broken issues (looking at you web start) that I go straight to the Oracle JDK. Sorry guys. I used the webupd8.org ppa to install it. Good stuff. One less thing to manage in /opt. Next came NetBeans, Eclipse, and the Arduino IDE, all Java based.
Since I was on a roll with Java based programs, I thought I'd stick FamilySearch Indexing back on. The Eclipse "unzip it where you want it" and the Netbeans and Arduino installers had gone well enough that I didn't expect any trouble, but that's what I got.
bin/unpack200: not foundAfter a few false starts, I found the best answer for this issue on the LDSTech forums where I was put onto the idea that it was a 32 bit compatibility issue on some 64 bit setups, and the work-around was to install the ia32-libs package. So I tried that:
Package ia32-libs is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source However the following packages replace it: lib32z1 lib32ncurses5 lib32bz2-1.0
Reading around I found more confirmation on the ia32-libs package going away. This seemed like a roadblock, except that the error had to do with decompressing. Maybe ia32-libs only included those three packages, so I tried the first, lib32z1, and that error went away, but another appeared.
How could java.awt.Container not be defined. This now sounded like a Java Runtime Environment (JRE) issue, but I know mine is fine. I just installed and tested three IDEs. It wasn't until this point that I noticed it was an install4j based install, so I started including that in my searches.java.lang.NoClassDefFoundError: java.awt.Container at com.install4j.runtime.installer.frontend.headless.AbstractHeadlessScreenExecutor.init(Unknown Source) at com.install4j.runtime.installer.frontend.headless.ConsoleScreenExecutor.(Unknown Source) at com.install4j.runtime.installer.frontend.headless.InstallerConsoleScreenExecutor.(Unknown Source) at com.install4j.runtime.installer.Installer.getScreenExecutor(Unknown Source) at com.install4j.runtime.installer.Installer.runInProcess(Unknown Source) at com.install4j.runtime.installer.Installer.main(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.exe4j.runtime.LauncherEngine.launch(Unknown Source) at com.install4j.runtime.launcher.Launcher.main(Unknown Source)
The problem wasn't unique to FamilySearch Indexing. I found someone trying to troubleshoot it for Visual Paradigm for UML among other things. Their solutions were the now obsolete ia32-libs or making sure their installed JRE was good.
Then I came across a post by Matthew O. Smith talking about Indexing and obsolete ia32-libs. He installed a number of extra libraries, including some i386 ones, and then installed using the headless option to get things going and save on installing a few more libraries. I felt like I had gone far enough with lib32z1 so I decided to try a different route, to try and run the Indexing software with my Oracle Java 7 environment. To do that I first leveraged the headless install tip Matthew gave, and then I modified a copy of the install4j shell script indexing launcher it created in $HOME/.FamilySearchIndexing/indexing.familysearch.org/
I copied the .desktop entry and tweaked it to point to my modified launcher instead and now I'm in business again.$ diff indexing indexing-jre7 4c4 < # INSTALL4J_JAVA_HOME_OVERRIDE= --- > INSTALL4J_JAVA_HOME_OVERRIDE=/usr/lib/jvm/java-7-oracle 114c114 < if [ "$ver_minor" -gt "6" ]; then --- > if [ "$ver_minor" -gt "7" ]; then