Maintenance

Sitting with K to debug an out-of-memory error with nVivo, I noticed that instead of closing nVivo to force it to write its file to disk, she was closing the VM. That would have the opposite effect: the file would not be written to the disk until the VM was restarted and nVivo, at some point, closed. That's a bit of a fragile situation, and we might want to look at a better approach to projects which depend on an app which doesn't actually save when it says it's saving.

Found some stuff had not got installed due to a couple of typos, and other things which used to be installed automatically as dependencies in the TEI Debian package now have to be explicitly installed. Updated the script. Finally got a successful job to run in Jenkins.

One remaining problem is kindlegen, which is proprietary and requires you to agree to terms before you can download it, so can't be installed from the command line. Still figuring out what to do about that.

Since we're now close to having a working Jenkins, I've written what we know into a build script, which I've been testing and tweaking. I've created a Jenkins3 server which is a plain Ubuntu server, fully updated, and I've set up a snapshot from which I can run the script. After several runs, it's pretty close to being complete and functional, but I haven't had a chance to test the Jenkins install itself yet.

No word from SR on what to do about this rather odd font, so I'm trying a simple install of the downloadable package to see if that'll do it:

cd /usr/share/fonts/truetype
mkdir hannom
cd hannom
wget -O hannom.zip http://downloads.sourceforge.net/project/vietunicode/hannom/hannom%20v2005/hannomH.zip?r=http%3A%2F%2Fsourceforge.net%2Fprojects%2Fvietunicode%2Ffiles%2Fhannom%2Fhannom%2520v2005%2F&ts=1305220899&use_mirror=cdnetworks-us-2
unzip hannom.zip
find . -iname "*.ttf" | rename 's/\ /_/g'
rm hannom.zip
fc-cache -f -v

Ran another build of P5-Documentation, but now it fails like this:

Wrote teip5.epub in /var/lib/jenkins/jobs/TEIP5-Documentation/workspace
mv teip5.epub Guidelines.epub
java -jar Utilities/epubcheck-1.1.jar Guidelines.epub
Epubcheck Version 1.1

ERROR: Guidelines.epub/OEBPS/ref-re.html(42): element "div" from namespace "http://www.w3.org/1999/xhtml" not allowed in this context

Check finished with warnings or errors!

make[1]: *** [epub.stamp] Error 1
make[1]: Leaving directory `/var/lib/jenkins/jobs/TEIP5-Documentation/workspace'
make: *** [dist-doc.stamp] Error 2
Archiving artifacts

The Jenkins process runs as the jenkins user, but when oXygen is invoked, it tries to read/write from /root/.com.oxygenxml, and since that directory is owned by root, it fails. I've chowned it to jenkins:root (jenkins appears to have no group), and I'm trying again. I've also created /root/.java, since oXygen seems to need that, and made it readable by the jenkins user.

I also discovered, from the remaining errors in the Stylesheets task, that there is no symbolic link trail for the Java jar executable. This is probably the result of my installing the Sun JDK manually instead of from the repos. So I did this, following the analogy of the java symbolic link:

sudo ln -s /usr/local/java/jdk1.6.0_25/bin/jar jar
sudo ln -s /etc/alternatives/jar jar

And now the Stylesheets task completes!

Now there's just the blasted Han Nom font issue.

From help I got from the oXygen forum, I've determined that the problem is that the JRE in the oXygen installation is 32-bit.

It was the teideb package repo that presumably gave me my oxygen install (I didn't do anything else to get oXygen installed). The package would seem to be: tei-oxygen_12.1-tei1_all.deb from here: http://tei.oucs.ox.ac.uk/teideb/binary/ which contains a complete oXygen package (in data.tar.gz) which does indeed include a JRE.

I just moved the JRE elsewhere, so now it's presumably using the installed Sun Java. But I'm getting another error now:

    using oXygen XML Editor stylesheet documentation generator.
    Exception in thread "main" java.lang.ExceptionInInitializerError
    at ro.sync.xsl.documentation.XSLStylesheetDocumentationGenerator.main(Unknown Source)
    Caused by: java.lang.RuntimeException: The preferences directory: /root/.com.oxygenxml
    cannot be accessed !/n Please check the read/write access on that folder and its ancestors !

There is no such directory, of course. The Jenkins process that's initiating the stylesheet script file is apparently running as root, so perhaps that's why it's looking there for preferences, but this is a headless server that doesn't need any GUI layout information. What would it be looking for in the preferences directory? I've posted for help on the oXygen forum.

Looking at the Jenkins interface this morning, I realized that I'd forgotten to give the anonymous user read access to jobs, so I've done that. I also tracked down the issue with the stylesheets to (I think) a permissions problem with the oXygen installation; it was installed via sudo, so all the files ended up owned by root, whereas the job is running under a different user. I've chowned everything to hcmc:hcmc, and we'll see if that solves it, but it might have to be chowned to whatever user Jenkins runs under. Running a stylesheet build now to see if it works.

EDIT: But it doesn't. The same error shows up even when java is world r-x. Posted on the oXygen forum for a possible solution, and also heard from SR that he remembers this but doesn't remember how he fixed it.

Looked at the logs for the first failed build, and found this:

(cd debian-tei-roma; debclean; debuild -i.svn -I.svn -uc -us)
/bin/sh: debclean: not found
/bin/sh: debuild: not found

These are in the package devscripts, so sudo apt-get install devscripts. I'll try the build again.

Looking at the stylesheet failure, we're missing xsltproc, so sudo apt-get install xsltproc. Then trying again, noticed I need debhelper, so sudo apt-get install debhelper.

The Jenkins configuration data is stored in /var/lib/jenkins; the config data for Jenkins1 is stored on the SVN server at http://tei.svn.sourceforge.net/viewvc/tei/trunk/Documents/Editing/Jenkins/. I imported the configurations from there, and I have builds going, but builds were failing at the end because the Log Parser plugin didn't seem to have any rules. SR let me know that the rules were in $SF/trunk/P5/Utilities/hudson-log-parse-rules, and I figured out from the configs that they needed to be in /var/lib/jenkins, so I copied them there. Trying a stylesheet build again...

For the security setup, I chose the "Standard security setup" which uses Jenkins's own database and matrix-based permissions. I let anonymous have read only, and created a tei user with full permissions.

I'm now installing plugins, based on the instructions in TEI SF. The following plugins were there by default:

• CVS Plugin
• Maven Integration plugin
• SSH Slaves plugin
• Jenkins Subversion Plug-in

I had to install these manually:

• Emotional Hudson Plugin
• Green Balls
• Copy Artifact Plugin
• JobConfigHistory Plugin (identified in TEI doc as "Hudson Job Configuration History Plugin")
• Plot Plugin
• Log Parser Plugin
• SCP plugin (identified in TEI doc as "Hudson SCP publisher plugin")
• WebSVN2 Plugin (identified in TEI doc as "Hudson WebSVN2 Plugin")