Ubuntu, Eclipse, Subclipse

Subclipse 1.6.18 installed on Eclipse 3.7 on Ubuntu didn't work complaining about:

org.tigris.subversion.javahl.ClientException: svn: REPORT of '$FILENAME_REMOVED': 400 Bad Request ($REPO_URL_REMOVED)

Installing 'libsvn-java' package and changing 'SVN Interface' in Eclipse ('Window -> Preferences -> SVN') to JavaHL (JNI) helps.

If your Node Manager complains during start-up that it cannot read its state:

java.io.IOException: Invalid state file format. State file contents:
at weblogic.nodemanager.common.StateInfo.load(StateInfo.java:135)
at weblogic.nodemanager.server.ServerMonitor.loadStateInfo(ServerMonitor.java:475)
at weblogic.nodemanager.server.ServerMonitor.isCleanupAfterCrashNeeded(ServerMonitor.java:139)
at weblogic.nodemanager.server.ServerManager.recoverServer(ServerManager.java:255)
at weblogic.nodemanager.server.DomainManager.initialize(DomainManager.java:103)
at weblogic.nodemanager.server.DomainManager.(DomainManager.java:55)
at weblogic.nodemanager.server.NMServer.initDomains(NMServer.java:219)
at weblogic.nodemanager.server.NMServer.start(NMServer.java:199)
at weblogic.nodemanager.server.NMServer.main(NMServer.java:355)
at weblogic.NodeManager.main(NodeManager.java:31)

then you need to remove the following file:

d:\bea\user_projects\domains\$DOMAIN_NAME\servers\C_0-S0\data\nodemanager\C_0-S0.state

So i upgraded ATI drivers

... and all I got was this lousy, corrupted display in Google Earth. Sigh.
 
Thankfully, it's usable, ie. it flickers briefly and only becomes very annoying when there are lots of lines (roads, borders) on the screen. But still: sigh.

ATI proprietary drivers on Debian

1) get binary package from ATI


2) generate packages:


$ ./ati-driver-installer-8-5-x86.x86_64.run --buildpkg Debian/etch


3) install generated packages


$ wajig install fglrx-driver_8.493-1_i386.deb fglrx-amdcccle_8.493-1_i386.deb fglrx-driver-dev_8.493-1_i386.deb fglrx-kernel-src_8.493-1_i386.deb

If you installed fglrx-glx from official Debian repos before (like my experimentally inclined self) you may get an error with clashing diversions (see bug475007):

dpkg-divert: `diversion of /usr/lib/libGL.so.1.2 to /usr/lib/fglrx/diversions/libGL.so.1.2 by fglrx-driver' clashes with `diversion of /usr/lib/libGL.so.1.2 to /usr/lib/fglrx/diversions/libGL.so.1.2 by fglrx-glx'

Remove the offending diversion then:

$ dpkg-divert --remove /usr/lib/libGL.so.1.2
Removing `diversion of /usr/lib/libGL.so.1.2 to /usr/lib/fglrx/diversions/libGL.so.1.2 by fglrx-glx'



4) compile kernel module

After installing fglrx-kernel-src you should have module source tarball under /usr/src:

$ ls -la fgl*
-rw-rw-r-- 1 root root 1228049 2008-05-22 16:04 fglrx.tar.bz2

Make sure this is the right one, module-assistant by default operates on source found under /usr/src. You can change this behavior via MOD_SRCDIR environment variable. Now build it (do not m-a update or m-a auto-install because it would download source from repo):

$ m-a build,install fglrx-kernel-src



5) Hold packages

Put manually generated packages on hold so they won't get auto-updated during your usual update routine

$ wajig hold fglrx-amdcccle fglrx-kernel-src fglrx-driver fglrx-driver-dev

or, if you don't use wajig:

$ echo "fglrx-amdcccle hold" | dpkg --set-selections
$ echo "fglrx-kernel-src hold" | dpkg --set-selections
$ echo "fglrx-driver hold" | dpkg --set-selections
$ echo "fglrx-driver-dev hold" | dpkg --set-selections



6. update xorg.conf

If you don't have proper entries in your xorg.conf yet, create them using

$ aticonfig --initial



7. reboot

Multiple versions of Java on Debian

Goal: To install both Java6 and Java7 from Sun and configure a simple way to change which one is used as system default.

Procedure:

I. Install Java6.

After Sun went GPL with Java, Debian started to include it in the repos, but it usually seriously lags behind, so we will install Java from Sun binary packages which can be downloaded from Sun's website. For this we will need two packages: fakeroot and java-package. The whole process is described here and in short looks like:

1) as a non-root user copy *.bin file to the directory where you have write permission
2) still as a non-root:
$ fakeroot make-jpkg $name_of_java_binary_package
3) accept licence, wait a while when .deb builds
4) as a root install .deb created in pt.3

Remember though that there are some packages that depend explicitly on 'sun-jre-1.6' (package provided by java from Debian repositories), while java created with java-package provides more general 'j2re1.6'. There are also packages that depend specifically on GNU Java (scala for example) so installing those will pull whole new Java stacks. Did anyone say 'dependency mess'?
 

II. Install java7.

Above works like charm for java6, but will fail with java7 because java-package knows nothing about java7 yet. We will have to prepare the configuration ourselves. Basing on info found here that's what we're going to do:

1) use the configuration for java6 as the basis:
$ cp -a /usr/share/java-package/sun-j2sdk1.6 /usr/share/java-package/sun-j2sdk1.7

2) Edit 'install' and 'remove' scripts:
a) update line starting with 'suffix': suffix=j2sdk1.7-sun
b) as of beta26 java7 constains the same list of binaries as java6, so we can leave 'update-alternatives' configuration unchanged

3) update 'sun-j2sdk.sh', add the following to the case statement responsible for handling your architecture:

#jdk-7-ea-bin-b26-linux-i586-24_apr_2008.bin
# WARNING: change following when beta numbers > 99
  "jdk-7-ea-bin-b"[0-9][0-9]"-linux-i586"*)
  j2se_version=1.7+beta${archive_name:14:2}${revision}
  j2se_expected_min_size=130
  found=true
  ;;


Now .deb should build without problems, just like with java6. Install it using your package management software of choice (wajig in my case):

banshee:/usr/src/java# wajig install sun-j2sdk1.7_1.7+beta26_i386.deb

At this point, basically everything is configured, you may use update-alternatives to set which java will be used across the system:

banshee:/etc/alternatives# update-alternatives --config java

There are 4 alternatives which provide `java'.
Selection Alternative
-----------------------------------------------
+ 1 /usr/lib/jvm/java-gcj/jre/bin/java
* 2 /usr/lib/j2sdk1.6-sun/bin/java
  3 /usr/lib/j2sdk1.7-sun/bin/java
  4 /usr/bin/gij-4.3

Press enter to keep the default[*], or type selection number: 3
Using '/usr/lib/j2sdk1.7-sun/bin/java' to provide 'java'.


III. A bit more fun with update-alternatives

To avoid having to manually switch all binaries that come with Java (like javac, javap etc) you can write two simple scripts which will automate the process:

banshee:/etc/alternatives# cat /usr/bin/switch_to_java6
#! /bin/sh
for i in $(ls /usr/lib/j2sdk1.6-sun/bin/); do
  update-alternatives --set $i /usr/lib/j2sdk1.6-sun/bin/$i;
done;

banshee:/etc/alternatives# cat /usr/bin/switch_to_java7
#! /bin/sh
for i in $(ls /usr/lib/j2sdk1.7-sun/bin/); do
  update-alternatives --set $i /usr/lib/j2sdk1.7-sun/bin/$i;
done;


You will see some warnings like:

Using '/usr/lib/j2sdk1.7-sun/bin/jconsole' to provide 'jconsole'.
update-alternatives: Cannot find alternative `/usr/lib/j2sdk1.7-sun/bin/jcontrol'.

That's because not everything contained in jdk's bin/ directory is provided as an alternative. Those warnings are harmless.

javac -XD-printflat

As a self-remainder, extremely useful 'hidden' javac option I found here:

$ javac -XD-printflat

Copying EXIF tags

Somewhere along my image processing worklow (RAW -> ufraw -> tiff -> GIMP -> jpg -> flickr) I lost EXIF data. Probably it'd been stripped during conversion to tiff using ufraw. Hmm, how to automagically copy EXIF meta-data from CR2 RAW files to post-processed jpgs? Exiftool to rescue!

/home/banshee# wajig install libimage-exiftool-perl
/home/banshee# cd $ImagesDir
$ImagesDir# exiftool -tagsfromfile %d%f.CR2 -r -ext jpg .

From exiftool manpage: exiftool -tagsfromfile %d%f.CRW -r -ext JPG dir
*Recursively* rewrite all "JPG" images in "dir" with information copied from the corresponding "CRW" images in the same directories.