Creating an RPM of geda-xgsch2pdf for Scientific Linux 6 (RHEL6)

So lately I’ve wanted to consolidate all of my EDA work that has been scattered over several workstations. I’ve created a new VM, running Scientific Linux 6 that I plan to use as my EDA “workstation” from now on. Adding the EPEL repository allowed me to install all of the gEDA tools, except geda-xgsch2pdf. That’s not a big deal, but I wanted to be able to continue using it for some projects. A quick search revealed no el6 RPM currently existed, so I was going to have to create one from scratch.

Creating a spec file for the application was easy enough, but once I actually tried to build the RPM, one of the tests in the configure script was failing. After a little investigation, I found that the failing test was for the GTK python module. The python test was just attempting to execute ‘import gtk’. However, that module requires that the DISPLAY environment variable is set, in order for the module to import. Since rpmbuild will explicitly unset DISPLAY, that’s what was causing the module import to fail.

As a quick hack, I started an X display using vncserver and then exported the DISPLAY variable in the spec file, just before the call to configure… problem solved. The RPM was created successfully. I copied it over to the EDA VM, installed it, and fired it up.

Below are the RPM and SRPM that I compiled for Scientific Linux 6/RHEL6 (x86_64):

geda-xgsch2pcb-0.1.3-1.el6.x86_64.rpm

geda-xgsch2pcb-0.1.3-1.el6.src.rpm

 

Because of my hack, if you plan to build from the source RPM you’ll need to start an X session on display :7, before executing rpmbuild. You can use vncserver to do that:

$ vncserver :7
You will require a password to access your desktops.
Password:
Verify:

New 'scilin66401:7 (swbuild)' desktop is scilin66401:7
Starting applications specified in /home/swbuild/.vnc/xstartup
Log file is /home/swbuild/.vnc/scilin66401:7.log

After that, the rpmbuild process will complete successfully.

 

The real issue

So, after looking at the problem a little longer, it seems the configure script was calling the AC_PYTHON_MODULE autoconf macro, to test for the module’s existence. As was stated before, the test was just attempting to perform an ‘import gtk’ and if any exception occurred, that was taken to mean that the module didn’t exist. In reality the module was installed, it was just returning a RuntimeException because of the lack of an X display to use. A more robust way to perform the check might be something like this:

import sys
try:
  import gtk
except Exception, e:
  if str(e) == "could not open display":
    sys.exit(0)
 print "Exception: %s" % str(e)
 sys.exit(1)

If an exception occurs, we check to see if it was simply a display issue, and if so, return a successful result. Otherwise, we print the string representation of the exception and exit with a failure value. Not complicated by any means, but it gets the job done.

If you’re curious about xgsch2pdf, then you can find more information on it’s home page: http://www.gpleda.org/

 

This entry was posted in Software and tagged . Bookmark the permalink.

Leave a Reply