Saturday, November 29, 2014

[solved] arch - update and java

Following Oracle's purchase of Java (2010), Java users can't be certain when Oracle attorneys or developers might make users' lives uncomfortable. If one wants Java functionality however, Oracle can't be avoided entirely. I am not a lawyer, but Oracle's open-source version of Java, OpenJDK, may be the most legally prudent Java option. That said, not every application plays nice with OpenJDK, of course, or Oracle wouldn't be able to profit from licensing its more user-friendly proprietary versions of Java.

What has the above meant to me operationally? When upgrading Arch with OpenJDK onboard, I've sometimes experienced conflicts which required a solution of, 1) uninstalling Java, 2) running the Arch update(s), and, 3) reinstalling or upgrading to the latest OpenJDK.

Arch update Java conflicts may look something like these (during pacman -Syu):
error: failed to commit transaction (conflicting files)
java-runtime-common: /usr/bin/java exists in filesystem
java-runtime-common: /usr/bin/keytool exists in filesystem
java-runtime-common: /usr/bin/orbd exists in filesystem
java-runtime-common: /usr/bin/pack200 exists in filesystem
java-runtime-common: /usr/bin/policytool exists in filesystem
java-runtime-common: /usr/bin/rmid exists in filesystem
java-runtime-common: /usr/bin/rmiregistry exists in filesystem
java-runtime-common: /usr/bin/servertool exists in filesystem
java-runtime-common: /usr/bin/tnameserv exists in filesystem
java-runtime-common: /usr/bin/unpack200 exists in filesystem
java-runtime-common: /usr/lib/jvm/default exists in filesystem
java-runtime-common: /usr/lib/jvm/default-runtime exists in filesystem
Errors occurred, no packages were upgraded.

The shortest path appears to be removing "java-common". Not so fast: OpenJDK requires java-common as a dependency; pacman typically will not allow its removal. The solution is to remove OpenJDK (at this writing version 7), update the system, and then reinstall OpenJDK:
# pacman -Rns jre7-openjdk
# pacman -Syu
# pacman -S jre7-openjdk

Applications (eg, geogebra, icedtea-web) that bark at this removal may also have to be removed prior to the Arch update, and then reinstalled (after jre).

location in system

$ ls -an /usr/bin/java
/usr/bin/java -> /usr/lib/jvm/default-runtime/bin/java

$ locate /bin/java
locate /bin/java
/usr/bin/java
/usr/bin/javaws
/usr/lib/jvm/java-8-openjdk/jre/bin/java
/usr/lib/libreoffice/ure/bin/javaldx
/usr/share/icedtea-web/bin/javaws

$ ls /usr/lib/mozilla/plugins
IcedTeaPlugin.so libflashplayer.so [missing java-plugin libnpjp2.so]

# find -name libjava.so
/usr/lib/jvm/java-8-openjdk/jre/lib/amd64/libjava.so
You can't find libnpjp2.so because you don't have normal java installed. Typically, you make a soft link between libnpjp2.so and the mozilla plugin directory. But in this case WITH OPEN JDK, our java soft link for mozilla (when we need it) is the icedtea plugin so we're actually set. All you have to do is go into "Add-Ons" in your browser and enable/disable it.


LibreOffice

After an Arch OpenJDK update, the LibreOffice portion sometimes still will notice you...
Optional dependencies for libreoffice-still
java-runtime: adds java support
java-environment: required by extension-wiki-publisher and extension-nlpsolver
...telling you for sure LibreOffice didn't detect OpenJDK. I opened LibreOffice -->Tools --> Options --> Advanced.



I selected the radio button for the Oracle option and then "OK". These actions seemed to activate Java.

Blackboard and Pipelight apps

Only Firefox has the stuff needed to process Moonlight, instead of Silverlight. Software must be installed that allows geolocating and so forth. These can be turned on and off by creating a softlink.

On the Blackboard account, also use Firefox (JRE).
ln -s /usr/lib/pipelight/libpipelight-silverlight5.1.so /usr/lib/mozilla/plugins/libpipelight-silverlight5.1.so

Sunday, November 16, 2014

[solved] xbacklight -- try to adjust your backlight to preserve it

I recently had an LCD display burn-out its backlight element and had the following consideration:
  • $60 (1.5 hrs) Replace screen and backlight combo
  • $12 (5 hrs) Replace backlight only
On my current schedule,I did the $60 but, since I was doing it for the backlight, I wanted to be sure I adjusted the backlight to a low setting going forward. The commands I'm aware of are
  • xgamma
  • xbacklight
  • xrandr
I've regularly used xgamma and xrandr in the past, but was never sure what I was adjusting -- the lcd, the backlight, or some blend. For example, with the new display, even when I set the gamma very low, eg
$ xgamma -gamma 0.1
...I would see what appeared to be a full-intensity backlight combined with a low contrast LCD setting. A similar problem appeared if I used xrandr, eg
$ xrandr --output LVDS --brightness 0.2
... which would give a bright haze (the backlight?) overlaying a barely visible display underneath. I wanted to definitively adjust the backlight so I could begin to untangle what was what. "Xbacklight" seemed the most logical choice. Murphy arrived immediately.

xbacklight problem

$ xbacklight
No outputs have backlight property
Checking the arch wiki on backlight control, we get the mysterious information:
All methods are exposed to the user through /sys/class/backlight and xrandr/xbacklight can choose one method to control brightness. It is still not very clear which one xbacklight prefers by default.
There is a note about how to fix the error message if one is using Debian, but of course Arch is not Debian. I did find the following directory however:
/sys/class/backlight/acpi_video0/
Based on what I read here from greengeek, I did the following with a nice dimming effect (required root)
# echo 1 > /sys/class/backlight/acpi_video0/brightness
Echoing a value obviously doesn't use an application (eg., xbacklight), but it appears to set the backlight effectively, and uses settings between 0 and 2.

final command combination

With the new LCD and backlight, a crisp setting appears to be
$ xgamma -gamma 0.4
# echo 0 > /sys/class/backlight/acpi_video0/brightness

xrandr and external displays or projectors

A person can get a printout of possible display settings for an external device attached to their desktop or laptop by simply typing $ xrandr. Using these, a person can set exact refresh settings for secondary displays, however, I haven't found backlight control of these displays. Still, xrandr is great to simply turn the display/projector on and off (with the proper screen resolution). Note the screen resolution of your laptop (eg. 1200x800)and send it to a projector...
$ xrandr --output VGA-0 --mode "1280x800" [initiates external video]
$ xrandr --output VGA-0 --off [terminates external video]

If I don't put the quotation marks around 1280x800, xrandr will bark at me that the resolution isn't found (most projectors don't natively have it).