Installing Caffeine 2.4.1 on Fedora 16

Regular readers probably know that I am a big fan of the Caffeine project (https://launchpad.net/caffeine). I even contributed the Gnome Shell patches to it (http://www.lucidelectricdreams.com/2011/06/disabling-screensaverlock-screen-on.html). After a fresh install of Fedora 16 "Verne", I attempted to install the latest version of Caffeine from the project page - which at the moment is 2.4.1 - and ran into a few problems. So for anyone interested, here's how to install the latest version from source.

1. Download the tarball from Launchpad and extract it:
   

   wget http://launchpad.net/caffeine/2.4/2.4.1/+download/caffeine_2.4.1%2B419~oneiric1.tar.gz
   mkdir caffeine 
   tar xvf caffeine_2.4.1%2B419~oneiric1.tar.gz --strip-components 1 -C caffeine
   cd caffeine
   

2. Run the setup scripts:
   

   python setup.py build
   sudo python setup.py install
   

3. Update the icon cache and GSetting schemas:
   

   sudo gtk-update-icon-cache /usr/share/icons/hicolor/
   sudo glib-compile-schemas /usr/share/glib-2.0/schemas/
   

4. Correct the permissions:
   

   sudo chmod 744 /usr/share/caffeine/images/*
   sudo chmod 744 /usr/share/caffeine/glade/*
   

5. To add Caffeine to startup items, run the following command and click the "Add" button. The path to the executable is /usr/bin/caffeine
   

   gnome-session-properties
   

Gnome Shell Cheat Sheet

Some very handy tips here. I particularly wasn't aware that I could use the scroll wheel to zoom in on windows in the overview mode.

https://live.gnome.org/GnomeShell/CheatSheet

GTIN Validation with Python

GTINs (Global Trade Item Number) are ubiquitous. We commonly see them as barcodes on products. They come in several different types and names such as EAN, UPC or ISBN etc.

Recently, I needed to validate a set of GTINs stored in a file. To my surprise (unless my Google-fu is getting weak), I could not find any libraries written in Python for doing this. The algorithm (http://www.gs1.org/barcodes/support/check_digit_calculator) is simple enough to knock together in a few minutes, but I think the requirement is common enough to warrant a ready-made library.

My first attempt at this can be found at https://github.com/charithe/gtin-validator. This module can validate GTIN-8, GTIN-12, GTIN-13 and GTIN-14 codes in either numeric or string forms. Dashes in the code (as is common with ISBN numbers) are supported.

I have never worked on a publicly available Python module before. Neither am I a professional Python developer. The chances are that there are certain parts in the code that do not conform to conventions. However, it's fully open source - so anybody can contribute to make it better.

Windows 8 Developer Preview

Microsoft has just released the Developer Preview of Windows 8 - which can be grabbed from http://msdn.microsoft.com/en-us/windows/home/.

I had a gander by installing it on a VM. The Metro UI looks quite good and I think it's great that most vendors are moving towards HTML5, CSS and Javascript based apps. (well.. at least they are mostly standardised and for once many giants of the industry are on common grounds). It's a shame that there is no common OS interface standard though. I would quite like to have my Gnome shell extensions work with little or no modifications on Windows 8. One could only dream I suppose.

One thing that drives me up the wall is the trend that OS developers seem to follow; not all users are high school kids who spend their whole time on social networks. Think of the power users dammit! I can't imagine having a very productive work flow on Windows 8. Hopefully I won't ever be forced to use it extensively - I have only just grudgingly gotten used to Gnome shell.

Yes, I am getting old.

Using System.getProperty() with Jenkins builds

One of my recent projects needed to be able to manipulate file paths according to a set of rules and read and process files directly from the file system. When it came to writing unit tests for this module, I was faced with a dilemma. My usual approach for this kind of system is to use the "Test Double" pattern to hide environment specific details from the tests to make them portable across different platforms and different developer environments. However, the module was about 80% file processing code - which made that approach impractical. So I ended up with a suite of tests that required absolute file paths to work properly.

At this point I should mention how it's near impossible to obtain an absolute file path in Java - specially if you are trying to be portable as possible. All my test data was in the src/test/resources/testjobs directory of the project. The absolute path to this was: /home/charithe/workspace/mercury/src/test/resources/testjobs. Obviously, when somebody else checks out this code, the first part of this path would be something else entirely. I played around quite a bit with ClassLoader.getResource et al, but had no luck whatsoever in making the path portable. In desperation, I even tried accessing Maven properties like project.source.directory - which didn't work out as is to be expected.

With time running out, I did the quickest hack imaginable. I added a custom JVM property named testdata.path to the run configuration and the test suite was changed to call System.getProperty("testdata.path") to retrieve the first half of the path, which was then prepended to the unchanging portion of the path to get the full absolute path. This worked out quite well. I could run the tests successfully from within Eclipse by adding the property definition to the run configuration and ditto for maven with the command:

mvn test -Dtestdata.path=/home/charithe/workspace/mercury

It was a short reprieve though. Once my code was checked-in, the Jenkins build failed miserably. My custom property was resolving to null even though I had added it explicitly to the maven command line of the Jenkins job configuration. After doing a quick Google search, it turns out that this is a known bug/feature of Jenkins (http://jenkins.361315.n4.nabble.com/System-properties-hidden-by-hudson-while-test-execution-td380285.html)

The fix was quite simple. In fact, it was so simple, when I found it out, I had to bang my head against the desk for not figuring that out earlier. The Maven sure-fire plugin has the ability to pass properties to the unit tests. This can be done through the plugin configuration section of the pom. (http://maven.apache.org/plugins/maven-surefire-plugin/examples/system-properties.html). The relevant section of my pom.xml looks as follows:

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-surefire-plugin</artifactId>
	<version>2.5</version>
	<configuration>
		<systemPropertyVariables>
		  <testdata.path>${basedir}/src/test/resources</testdata.path>
		</systemPropertyVariables>
	</configuration>
</plugin>

Oracle client 11g installation under wine

I am a steadfast Fedora user both at home and at work. However, most of my colleagues tend to use Ubuntu and one of the problems I have come across a few times is the inability to install the Oracle client software under wine in Ubuntu. It all works fine under Fedora, so why does it fail on Ubuntu with the error message "java.lang.NullPointerException at oracle.sysman.oii.oiin.OiinNetOps.addNICInfo(OiinNetOps.java:109)"? I set out to find out.

After verifying that the installation error is reproducible and not just caused by a weird configuration specific to a single machine, I poked around the Oracle installation files to try to get an idea about how this error was occurring. Turns out that it is quite easy to reproduce. The following Java class does exactly that:

import java.net.InetAddress;
import java.net.NetworkInterface;

public class Test
{
	public static void main(String[] args)
	{
		try 
		{			
			InetAddress ia = InetAddress.getLocalHost();			
			NetworkInterface nic = NetworkInterface.getByInetAddress(ia);			
			String nicName = nic.getDisplayName();			
                        System.out.println(nicName);
		} 
		catch (Exception e) 
		{			
			e.printStackTrace();
		}	
	}
}

The above code runs perfectly fine on a Fedora installation but generates a NullPointerException on an Ubuntu installation at the point where nic.getDisplayName() method is called. This is caused by an oddity in network configuration of Debian based distributions. To avoid problems with fully qualified domain name resolution, Debian based workstations automatically get an entry in /etc/hosts of the form:

127.0.1.1  localhost.localdomain

Note that this is not the loopback address 127.0.0.1. Therefore, the localhost IP address ends up resolving to 127.0.1.1 - a valid "non-special" IP address. This in turn causes the above Java snippet to fail because quite correctly, it cannot detect a NIC bound to 127.0.1.1 on the local machine.
The solution is to either delete the above line from /etc/hosts or to add a new line as follows:

echo `hostname -i` "  "  `hostname -f` >> /etc/hosts

The Java code now runs without any exceptions natively, but under wine, it still causes the NPE. It appears that whatever native library used by Java (javanet.dll?) is not functioning properly under wine. In fact, under wine, Java cannot see any network interfaces at all. This can be proven by running the following piece of Java code under wine:

public class Test 
{
	public static void main(String[] args)
	{
		Enumeration nicList;
		try 
		{
			nicList = NetworkInterface.getNetworkInterfaces();		
		    while(nicList.hasMoreElements())
		    {
		    	NetworkInterface nic = nicList.nextElement();
		    	Enumeration ipList = nic.getInetAddresses();
		    	while(ipList.hasMoreElements())
		    	{
		    		System.out.println(nic.getName() + "-" + ipList.nextElement());
		    	}	    	
		    }
		} 
		catch (SocketException e) 
		{			
			e.printStackTrace();
		}
	}
}

So how does the Oracle installer run fine under Fedora and not under Ubuntu? I can't find a logical explanation for it. The only difference seems to be that the version of wine in the Ubuntu repositories is 1.2.x while Fedora ships with 1.3.x. (As always, Fedora ships with the bleeding edge development version of wine whilst Ubuntu ships with the stable release). To test whether version makes a difference, I uninstalled the stock wine installation from Ubuntu, downloaded the latest wine source (1.3.22) and compiled it as follows:

sudo apt-get -y remove wine && sudo apt-get autoremove
rm -rf ~/.wine
sudo apt-get -y install flex bison libx11-6 libx11-dev libfreetype6 libfreetype6-dev
wget http://ibiblio.org/pub/linux/system/emulators/wine/wine-1.3.22.tar.bz2
tar xvf wine-1.3.22.tar.bz2
cd wine-1.3.22/tools
./wineinstall

On my dual core Laptop with 2GB of RAM, compilation took about 1 hour.
Trying to run the Oracle client installer with the newly compiled version of wine still generates the old NPE, BUT, the installer doesn't crash there like before and actually continues to work! There's no logical explanation that I can think of for this strange behaviour, and frankly I am not too bothered about it. The important point is that I can finally mark this problem as solved and get some closure. :)

Reading and writing GSettings from Python

Here's the class I wrote to read/write the screensaver settings from GSettings. It's probably not in the best Python style, but it illustrates the idea.

from gi.repository import Gio,GLib

class GnomeScreenLock:

  IDLE_DELAY_SCHEMA = 'org.gnome.desktop.session'
  IDLE_DELAY_KEY = 'idle-delay'

  IDLE_ACTIVATION_SCHEMA = 'org.gnome.desktop.screensaver'
  IDLE_ACTIVATION_KEY = 'idle-activation-enabled'

  def getIdleDelay(self):
        gsettings = Gio.Settings.new(self.IDLE_DELAY_SCHEMA)
        return gsettings.get_value(self.IDLE_DELAY_KEY).get_uint32()

  def setIdleDelay(self,delaySeconds):
        gsettings = Gio.Settings.new(self.IDLE_DELAY_SCHEMA)
        gsettings.set_value(self.IDLE_DELAY_KEY,GLib.Variant.new_uint32(delaySeconds))

  def isIdleActivationEnabled(self):
        gsettings = Gio.Settings.new(self.IDLE_ACTIVATION_SCHEMA)
        return gsettings.get_boolean(self.IDLE_ACTIVATION_KEY)

  def setIdleActivationStatus(self,activation):
        gsettings = Gio.Settings.new(self.IDLE_ACTIVATION_SCHEMA)
        gsettings.set_boolean(self.IDLE_ACTIVATION_KEY,activation)