Archives for: May 2011


Permalink 05:03:08 pm, by mholmes, 64 words, 126 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 60

Jenkins3 enhanced, tested again, docs updated

SY from the TEI Council sent some comments and suggestions on the script, so I added two new features and fixed a bug, ran another full test, and updated the documentation on the TEI wiki. The changes were: checking that you're running Lucid; checking that nothing else is already running on port 8080; and removing some pointless chmods I was doing, that had no effect.


Permalink 04:24:29 pm, by mholmes, 106 words, 124 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 150

Jenkins3 tested again, script complete, instructions written...

Ran the whole process from script to completed builds again on Jenkins3 this morning, and all worked well, so I figure we're ready for the next stage. Wrote up the instructions and provided the script on the TEI Wiki, then set about preparing to build our proper VM for deployment. Initially we thought we'd do this using Remastersys to create an ISO for the full server install, but that failed -- the ISO wouldn't boot -- so we're going to take the same approach on our proper VM as is detailed in the wiki page. GN is arranging with sysadmin for the VM to be provisioned.

Permalink 09:13:22 am, by mholmes, 40 words, 120 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 40

Jenkins3: Changing default port

It looks like the place to change the default port is /etc/default/jenkins. Tried to change it to port 80, but it wasn't having any of it, so gave up. We can map 8080 from the VM through the AJP connector.


Permalink 07:14:08 am, by mholmes, 190 words, 290 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 60

Jenkins4: port forwarding on older VirtualBox

My home install of VirtualBox is older than my work one, and the instructions for port forwarding elsewhere in this blog don't work on it. This is how to port-forward Jenkins on an older VirtualBox.

  • Shut down both the VM and VirtualBox.
  • Open the XML file for the VM.
  • Add these lines to the <ExtraData> section:
          <ExtraDataItem name="VBoxInternal/Devices/e1000/0/LUN#0/Config/jenkins/GuestPort" value="8080"/>
          <ExtraDataItem name="VBoxInternal/Devices/e1000/0/LUN#0/Config/jenkins/HostPort" value="9494"/>
          <ExtraDataItem name="VBoxInternal/Devices/e1000/0/LUN#0/Config/jenkins/Protocol" value="TCP"/>
  • Restart VB and the VM. If you get this error:
    Configuration error: Failed to get the "MAC" value (VERR_CFGM_VALUE_NOT_FOUND).
    then you have the wrong value for the virtual network adapter (i.e. "e1000" above should be something else). Search the logs to find lines like this:
    00:00:01.104 [/Devices/e1000/0/Config/] (level 4)
    00:00:01.104   AdapterType    <integer> = 0x0000000000000000 (0)
    00:00:01.104   CableConnected <integer> = 0x0000000000000001 (1)
    00:00:01.104   LineSpeed      <integer> = 0x0000000000000000 (0)
    00:00:01.104   MAC            <bytes>   = "08 00 27 27 01 f8" (cb=6)
    which will tell you the correct name of the device.

Jenkins4 (my home VM) is now running builds... fingers crossed...


Permalink 02:35:49 pm, by mholmes, 90 words, 1783 views   English (CA)
Categories: Announcements; Mins. worked: 30

Jenkins3: Deja Vu fonts were missing!

After TEIP5-Documentation and TEIP5 failed to build again, I went in and looked at the logs more closely. I think the failure is caused by the absence of the Deja Vu fonts, which would of course be installed by default on a desktop but are not there on the headless server. I've installed them, and added them to the script, and I'm running TEIP5 again. There may be other common fonts missing, so we might have to go through this process a few times, but this is definitely progress.


Permalink 05:21:07 pm, by mholmes, 941 words, 226 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 120

Jenkins3 and Jenkins5: progress

Made some progress today after discovering that installing some XML tools before the Sun JDK caused the OpenJDK to get installed, so I switched the order of some items. Also figured out a better way of enabling the partner repo that will work with other distros than Lucid, and made a couple of other tweaks. The full script is below (since our backup server is down at the moment). I've also built Jenkins4 as a Natty 11.04 server, and I'm testing the script on that to see if it might work there too. It seems to be running fine, and I've got as far as a working Jenkins once before retreating to create a useful restore point and fix some bugs. It's quite plausible it might work perfectly well on any Ubuntu between Lucid and Natty.

#The Mighty Jenkins Builder Script.
#Note that this should be run as root (with sudo).
echo "Entering the Mighty Jenkins Builder Script."

uid=$(/usr/bin/id -u) && [ "$uid" = "0" ] ||
{ echo "This script must be run as root."; exit 1; }

echo "Running as root: good."

#First do updates.
echo "Doing system updates before starting on anything else."
apt-get update
apt-get upgrade

#Now add the repositories we want.
echo "Backing up repository list."
cp /etc/apt/sources.list /etc/apt/sources.list.bak

#Uncomment partner repos.
echo "Uncommenting partner repositories on sources list, so we can get Sun Java."
#Note: this is very crude, and also enables the CD-ROM source, which results in 
#errors. We need to make this more precise.
#sed -i -e "s/# deb/deb/g" /etc/apt/sources.list
#This is a better replacement:
sed -i -re '/partner/ s/^#//' /etc/apt/sources.list

#First Jenkins
echo "Adding Jenkins repository."
wget -q -O - | apt-key add -
echo "deb binary/" > /etc/apt/sources.list.d/jenkins.list

#Next TEI.
echo "Adding TEI Debian repository."
gpg --keyserver --recv-keys FEA4973F86A9A497
apt-key add ~/.gnupg/pubring.gpg
echo "deb ./" > /etc/apt/sources.list.d/tei.list

#Now we can start installing packages.
echo "Updating for new repositories."
apt-get update

echo "Installing Sun Java JDK."
apt-get install sun-java6-jdk &&
echo "Installing core packages we need."
apt-get install openssh-server libxml2 libxml2-utils devscripts xsltproc debhelper subversion trang &&

#TEI packages
echo "Installing TEI packages."
apt-get install psgml xmlstarlet debiandoc-sgml linuxdoc-sgml jing jing-trang-doc libjing-java rnv texlive-xetex &&
apt-get install trang-java tei-p5-doc tei-p5-database tei-p5-source tei-schema tei-emacs saxon nxml-mode-tei tei-p5-xsl tei-p5-xsl2 tei-roma onvdl tei-oxygen zip &&

#I don't believe the following step is necessary, so it's been commented out for the moment.
#Waiting for info from SR and SY about why it was in the instructions.
#echo "Removing things that cause problems for TEI."
#apt-get remove `apt-cache search gcj | grep gcj | awk '{print $1}'`

#Setting up configuration for oXygen
mkdir /root/.com.oxygenxml
chown jenkins /root/.com.oxygenxml
chmod a+x /root/.com.oxygenxml
mkdir /root/.java
chown jenkins /root/.java
chmod a+x /root/.java
echo "Don't forget to put your licensekey.txt file in the folder /usr/share/oxygen so that oXygen is registered."

#More packages needed
echo "Installing packages needed for building TEI source."

#Various fonts and the like.
echo "Installing fonts we need."
apt-get install msttcorefonts ttf-arphic-ukai ttf-arphic-uming ttf-baekmuk ttf-junicode ttf-kochi-gothic ttf-kochi-mincho
echo "The Han Nom font is not available in repositories, so we have to download it from SourceForge."
cd /usr/share/fonts/truetype
mkdir hannom
cd hannom
wget -O
find . -iname "*.ttf" | rename 's/\ /_/g'
fc-cache -f -v

apt-get install jenkins

#Configuration for Jenkins
echo "Starting configuration of Jenkins."
echo "Getting the Hudson log parsing rules from TEI SVN."
cd /var/lib/jenkins
svn export
chown jenkins hudson-log-parse-rules
echo "Getting all the job data from TEI SVN."
#Don't bring down the config.xml file for now; that contains security settings specific to 
#Sebastian's setup, and will prevent anyone from logging in. We leave the server unsecured,
#and make it up to the user to secure it.
#svn export
#chown jenkins config.xml
svn export --force jobs
chown -R jenkins jobs
echo "Installing Jenkins plugins."
cd plugins
wget --no-check-certificate
chown jenkins copyartifact.hpi
wget --no-check-certificate
chown jenkins emotiosudnal-hudson.hpi
wget --no-check-certificate
chown jenkins greenballs.hpi
wget --no-check-certificate
chown jenkins jobConfigHistory.hpi
wget --no-check-certificate
chown jenkins plot.hpi
wget --no-check-certificate
chown jenkins log-parser.hpi
wget --no-check-certificate
chown jenkins scp.hpi
wget --no-check-certificate
chown jenkins WebSVN2.hpi

echo "Restarting Jenkins server, so that it finds and initializes all the new plugins."
/etc/init.d/jenkins restart

echo "OK, we should be done. Now you have to:"
echo "1. Put your oXygen licence key in a file called licensekey.txt in the oXygen directory (/usr/share/oxygen/)."
echo "2. Go to the Jenkins interface on http://localhost:8080, and set up authentication. Read the Jenkins docs."
echo "That's it!"


Permalink 02:04:51 pm, by mholmes, 230 words, 147 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 30

Jenkins2 (now Jenkins4): things learned today

Went through the process a couple more times at home, and I have some questions still to be answered, and some additions to the script:

When it got to this line:

apt-get remove `apt-cache search gcj | grep gcj | awk '{print $1}'`

apt reported that it was uninstalling jing. I'd previously been puzzled about the absence of jing at the end of the script, because it's explicitly installed before this point, but it looks like this is the reason. I'm just wondering what that line is actually doing. I got it from the wiki:

and it looks like SY added that line in July last year:

I can add another line to my script to reinstall jing, so it's no problem, but I've written to ask him why he did that. Perhaps it's not necessary to remove all that stuff, because installing jing just brings a lot of it back anyway.

If we don't delete that stuff, the addition would be:

echo "Reinstalling jing, which just got removed by the previous line."
apt-get install jing

We can also restart Jenkins at the end of the script, so the user doesn't have to:

echo "Restarting Jenkins server, so that it finds and initializes all the new plugins."
/etc/init.d/jenkins restart


Permalink 02:25:58 pm, by mholmes, 9 words, 131 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 120

Jenkins2: (Jenkins3 actually)

The full install script now seems to be working.

Permalink 10:47:28 am, by mholmes, 90 words, 140 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 20

Found a source of nVivo problems

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.

Permalink 10:44:43 am, by mholmes, 83 words, 143 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 90

Latest builds: nearly working

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.


Permalink 05:01:14 pm, by mholmes, 74 words, 121 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 120

Wrote a build script

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.

Permalink 11:14:40 am, by mholmes, 170 words, 127 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 60

Jenkins2: Trying a fix for the Han Nom font

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
find . -iname "*.ttf" | rename 's/\ /_/g'
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 "" 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
Permalink 08:01:38 am, by mholmes, 151 words, 145 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 90

Jenkins2: oXygen prefs and .java directory; and Stylesheets now working!

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.


Permalink 03:26:59 pm, by mholmes, 121 words, 1885 views   English (CA)
Categories: Announcements; Mins. worked: 90

Fixes for 32-bit JRE

SR is rebuilding the TEI deb now, presumably with an oXygen that has no JRE with it. I've removed the JRE in my Jenkins oXygen, and also placed a key file in the oXygen directory (which I hope will prevent it from trying to read /root/.com.oxygenxml to find the key). Running the file at the command line now does not fail -- well, it does, but with an error about number of arguments required -- so I ran a test build of it through Jenkins to see if the actual thing worked, and the build did start successfully, but failed with what looks like an XSLT problem during a test. Waiting for feedback from SR about that.


Permalink 03:43:40 pm, by mholmes, 213 words, 137 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 120

Jenkins2: problem is 32-bit JRE

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: 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.


Permalink 08:23:47 am, by mholmes, 143 words, 2032 views   English (CA)
Categories: R & D, Activity log, Notes; Mins. worked: 45

Configuration change, and permissions issue

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.


Permalink 11:38:53 am, by mholmes, 73 words, 1981 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 45

Jenkins2: Build problems are from missing packages

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.

Permalink 11:04:52 am, by mholmes, 102 words, 1924 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 60

Jenkins2: Copying Jenkins job setup from SVN

The Jenkins configuration data is stored in /var/lib/jenkins; the config data for Jenkins1 is stored on the SVN server at 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...

Permalink 09:29:44 am, by mholmes, 113 words, 1921 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 60

Security setup and plugins on Jenkins2

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")


Permalink 01:32:58 pm, by mholmes, 1366 words, 256 views   English (CA)
Categories: R & D, Activity log, Documentation; Mins. worked: 300

Building Jenkins2

Started my first attempt at building Jenkins2 with my desktop VirtualBox. Steps:

  • Created a new Ubuntu 64-bit VM with 2GB of RAM and an expanding 25GB HD.
  • Booted and installed from a downloaded 64-bit PC (AMD64) server install CD ISO.
  • Let the installer determine the partitioning (it used LVM and created three partitions).
  • ERRONEOUSLY chose the "Tomcat Java Server" option to start with. Note that this is not necessary; in fact Tomcat gets in the way, and I had to uninstall it later.
  • Rebooted after install, did updates, and then installed curl.
  • Downloaded and installed the Oracle JDK (downloaded it locally, put it on a server, and curled it to the VM). NOTE: There are Sun Java packages in the repos, I think; it would probably be better to install them, but I couldn't quite figure out how and I was in a rush. I think I could have done sudo apt-get install sun-java6-jre and sudo apt-get install sun-java6-jdk.
  • Created /usr/local/java, copied the JDK binary there, made it executable and executed it.
  • Added the following to /etc/profile:
    • JAVA_HOME=/usr/local/java/jdk1.6.0_25
    • PATH=$PATH:$HOME/bin:$JAVA_HOME/bin
    • export JAVA_HOME
    • export PATH
  • Configured Java through update-alternatives:
    • sudo update-alternatives --install "/usr/bin/java" "java" "/usr/local/java/jre1.6.0_25/bin/java" 1
    • sudo update-alternatives --set java /usr/local/java/jre1.6.0_25/bin/java
  • Rebooted and tested with java -version that the JDK is now default the Java VM.
  • Tried to do waiting updates with apt-get, but they were held back, so did them with aptitude. Why is this necessary?
  • Couldn't find Tomcat, so did sudo apt-get install tomcat6, and installed it. This seemed to update the openjdk too, but it didn't mess with the configuration of the Oracle Java.
  • After reading around a bit, I decided I'd rather use Tomcat7, so I created /usr/local/apache-tomcat-7.0.12, and used wget to download the tar.gz file, and then did tar xvzf to unwrap it.
  • Added my usual
  • Ran Tomcat and confirmed it was working by curling

Next I wanted to find a convenient way to access the VM's Tomcat from the host, so I ran this in a terminal on the host, after shutting down the vm:

VBoxManage modifyvm "Jenkins2" --natpf1 "tomcat,tcp,,9090,,8080"

This should set up port forwarding between the host desktop port 9090 and the Tomcat running on port 8080 in the VM.

The port-forwarding worked like a charm, but in the process I discovered that Tomcat 6 is set to run as a service. So I have Tomcat 7 available, but I'll stick with Tomcat 6 from the repos for the moment, unless I find a reason to abandon it.

NOTE: All of the Tomcat stuff was unnecessary, but the Sun/Oracle Java is required.

  • Added the Jenkins key and repo as explained here, and installed Jenkins.
  • Having done that, I realized that it's actually starting by itself on port 8080; it doesn't need to run inside Tomcat. So I edited its script in /etc/init.d/jenkins to add this to the arguments: --httpPort=8081. This should make it start on 8081 and not conflict with Tomcat.
  • Then I shut down the VM and ran this on the host:
    VBoxManage modifyvm "Jenkins2" --natpf1 "jenkins,tcp,,9091,,8081"
    which should let me see Jenkins on 9091 on the host, without having to turn off Tomcat for the moment. However, in future, we should probably just leave Tomcat out of it.
  • Despite my re-configuration, Jenkins kept trying to start on 8080. Meanwhile, I got sick of the limited terminal available in the headless vm, so I did sudo apt-get install openssh, and tested it, then shut down the VM and ran this:
    VBoxManage modifyvm "Jenkins2" --natpf1 "guestssh,tcp,,2222,,22"
    Now I can connect to the VM using:
    ssh -l hcmc -p 2222 localhost
    which means I can easily copy/paste from browsers, use a larger terminal, etc.
  • So then I went back and got rid of Tomcat (sudo apt-get remove --purge tomcat6), and then copied my backup of the /etc/init.d/jenkins back over the edited one to remove the attempt to reconfigure the httpPort. Then a restart gave me.... A WORKING JENKINS on port 8080.

Next, install texlive and friends:

Texlive installed. Then I had to do sudo apt-get install subversion, because I'll be needing that.

Next, I followed my own instructions to get TEI installed.

Then in trunk/P5 I did make dependencies, and then sudo apt-get install [the list of dependencies].

However, an attempt to build P5 failed:

Checking you have running XML tools and Perl before trying to run transform...
xmllint:make: *** [check.stamp] Error 1

Turns out xmllint is in libxml2-utils, so had to sudo apt-get install libxml2-utils. Now a make is proceeding as expected.

Next, I wanted to do some cleanup -- on login, there was a message to the effect that there were packages available for upgrade, but the message was wrong (see discussion here). So I did sudo rm /etc/motd.tail.

Next, I tried make pdf, which is one of the targets that failed for me on my desktop due to the absence of TeXLive 2010. It failed again for the same reason; although I've installed TeXLive 2010, the system has at least one symbolic link (from /usr/bin/xelatex to /usr/bin/xetex) which are from the old Debian 2009 Tex package.

So the instruction on the TEI wiki page for installing packages, which includes texlive, is wrong; that shouldn't be installed. I've now removed it (sudo apt-get remove texlive). Then I added the install location of the 2010 to my path, by doing sudo nano /etc/profile, and adding PATH=$PATH:/usr/local/texlive/2010/bin/x86_64-linux to it.

Then I tried make pdf again, and got the same error, so it's not caused by the texlive version after all. Although the error message suggests that the error is caused by a space in a font name, I think it's actually caused by the absence of the font. Reported this to SR, who modified the source so that the Minion Pro and Myriad Pro fonts are no longer required (they're proprietary anyway). Now I can build a PDF, but I'm still getting an error at the end.

Looking in job$.log (after deleting it, and re-running the make pdf to be sure it's fresh), I see that it still starts with this:

hcmc@Jenkins2:~/tei/trunk/P5$ more job\$.log
kpathsea: Invalid fontname `Myriad Pro', contains ' '
kpathsea: Invalid fontname `Myriad Pro', contains ' '
kpathsea: Invalid fontname `Myriad Pro', contains ' '
kpathsea: Invalid fontname `Myriad Pro', contains ' '
kpathsea: Invalid fontname `Myriad Pro/B', contains ' '
kpathsea: Invalid fontname `Myriad Pro', contains ' '
kpathsea: Invalid fontname `Myriad Pro/I', contains ' '
kpathsea: Invalid fontname `Myriad Pro', contains ' '
kpathsea: Invalid fontname `Myriad Pro/BI', contains ' '
kpathsea: Invalid fontname `Myriad Pro:', contains ' '

The rest of the file consists mainly of

** WARNING ** Failed to convert input string to UTF16...

but there are two more Myriad Pro errors towards the end, and finally there's this:

kpathsea: Invalid fontname `HAN NOM A', contains ' '
kpathsea: Invalid fontname `HAN NOM A', contains ' '
kpathsea: Invalid fontname `HAN NOM A', contains ' '
kpathsea: Invalid fontname `HAN NOM A/B', contains ' '
kpathsea: Invalid fontname `HAN NOM A', contains ' '
kpathsea: Invalid fontname `HAN NOM A/I', contains ' '
kpathsea: Invalid fontname `HAN NOM A', contains ' '
kpathsea: Invalid fontname `HAN NOM A/BI', contains ' '
kpathsea: Invalid fontname `HAN NOM A:', contains ' '

with lots more instances of the same thing. So I suspect there are still references to Myriad Pro in the code, and there's also this other font, which I've never heard of. It doesn't seem to be available in the repos either, as far as I can tell (there's no ttf-hannom, although Arch Linux seems to have one). Waiting to hear from SR where he got it from.


Permalink 05:14:24 pm, by mholmes, 176 words, 270 views   English (CA)
Categories: R & D, Activity log; Mins. worked: 60

Building eXist trunk and deploying locally

After JN had to check out the current source and build to get around a recent bug, I took the opportunity to go through the same process, create an eXist war file:

  • mkdir exist_trunk
  • cd exist_trunk
  • svn co .
  • ./ clean
  • ./ download-additional-jars
  • cd extensions
  • cp
  • [Edit to turn on FOP.]
  • cd ../
  • ./
  • ./ -f build/scripts/jarsigner.xml
  • ./ dist-war
  • mkdir [tomcat]/webapps/exist
  • cp dist/exist-1.5....war [tomcat]/webapps/exist
  • jar xfv [tomcat]/webapps/exist/exist-1.5...war

Then I started Tomcat 6.0.26, but eXist failed to start. So I installed the latest Tomcat (7.0.12). It took me a while to get this going, but I eventually figured out that all the .sh and all the .jar files in the bin directory need to be executable. I used my usual file to start it up, and exist came up working fine. So the latest eXist seems to prefer the latest Tomcat.


This blog is the location for all work involving software and hardware maintenance, updates, installs, etc., both routine and urgent, in the server room, the labs and the R&D rooms.



May 2011
Sun Mon Tue Wed Thu Fri Sat
 << < Current> >>
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

XML Feeds