Richard Fearn

Updated History Flow Subversion plugin

Richard — Mon, 30 Aug 2010 14:33:10 +0000

Back in 2006, I wrote a Subversion plugin for History Flow, a visualisation tool that lets you examine graphically the history of a text file. (I also wrote about the API that History Flow uses.)

Unfortunately the plugin had stopped working, and JavaSVN (which I used to access Subversion repositories from Java) had been renamed to SVNKit.

I originally provided a ready-to-run plugin JAR, plus a ZIP containing the source code. Today I found the old Subversion repository that I used when originally writing the plugin.

So I’ve converted the Subversion repository to a git repository, and you can find all the code – with fixes to get it using SVNKit instead of JavaSVN – in the historyflow-subversion repository on GitHub.

In doing this I’ve learnt a few things about writing good commit messages and converting from Subversion to git.

Enjoy!

Chainloading from one grub to another

Richard — Fri, 14 Mar 2008 20:21:17 +0000

If you install two (or more) Linux distributions on one machine, then by default they both install grub to the master boot record (MBR). The second distribution’s grub menu therefore overwrites the first.

For example, on my laptop, I have Windows on /dev/sda2, Fedora 8 on /dev/sda5 and Debian 4.0 (etch) on /dev/sda7. Having installed them in that order, I ended up with Debian’s grub menu, allowing me to boot into Debian or Windows.

It’s tempting to copy all the Fedora grub entries into Debian’s grub menu file to regain access to Fedora, but if the Fedora kernel gets updated, you have to manually update the Debian grub menu file to include the new Fedora entries. Fortunately, there is a better way: have two grub installations, and allow them to chainload each other.

The idea is to install each distribution’s grub into the boot record of its own partition, in addition to also having grub installed in the MBR (this is the one that you see first when the machine is switched on). The reconfiguration can all be done by booting into one distribution (because you can access the other distribution’s grub menu file by mounting its partition from the distribution you boot into). I booted into Debian and setup Fedora first:

grub> root (hd0,4)
 Filesystem type is ext2fs, partition type 0x83

grub> setup (hd0,4)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0,4)"... failed (this is not fatal)
 Running "embed /boot/grub/e2fs_stage1_5 (hd0,4)"... failed (this is not fatal)
 Running "install /boot/grub/stage1 (hd0,4) /boot/grub/stage2 p /boot/grub/grub.conf "... succeeded
Done.

Then Debian:

grub> root (hd0,6)
 Filesystem type is ext2fs, partition type 0x83

grub> setup (hd0,6)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0,6)"... failed (this is not fatal)
 Running "embed /boot/grub/e2fs_stage1_5 (hd0,6)"... failed (this is not fatal)
 Running "install /boot/grub/stage1 (hd0,6) /boot/grub/stage2 p /boot/grub/grub.conf "... succeeded
Done.

If you want to change the “main” grub menu (the one that comes up when you first switch on the machine), you can do that too. Notice that this time grub gets installed to the MBR due to the (hd0):

grub> root (hd0,4)
 Filesystem type is ext2fs, partition type 0x83

grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  16 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+16 p (hd0,4)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded
Done.

Now you need to add the appropriate entries to each distribution’s grub menu file. For Fedora edit /boot/grub/grub.conf:

title Debian grub
    root (hd0,6)
    chainloader +1

For Debian, edit /boot/grub/menu.lst:

title           Fedora grub
root            (hd0,4)
chainloader     +1

Now I get a “Debian grub” option in the Fedora grub menu, and a “Fedora grub” option in the Debian grub menu. Whenever I update either distribution, any new grub entries are added to the appropriate grub menu and I don’t need to tinker with the menu files.

Booting the Fedora installer with PXE

Richard — Sat, 02 Feb 2008 17:41:27 +0000

Launching the Fedora installer over the network, as well as having a local mirror of the Fedora repository, means you don’t need to burn a CD or DVD. It’s a convenient way of trying out a new distro.

I’ve done this for Fedora 8. I have a local Fedora repository on my Fedora 7 gateway. You need a working DHCP server, which I won’t cover here. To get the network boot working I did this:

install tftp-server. Ensure it’s enabled (chkconfig tftp-server on).
install syslinux. Copy /usr/lib/syslinux/pxelinux.0 into /tftpboot.
create the directory /tftpboot/fedora8 and copy the contents of Fedora/i386/os/images/pxeboot into it.
create the directory /tftpboot/pxelinux.cfg and put this default file in that directory.
add the following options to your dhcpd.conf (change 111.222.333.444 to your server’s IP address):
```
next-server 111.222.333.444;
filename "pxelinux.0";
```

If you boot the client machine, it should automatically boot the Fedora installer.

Building pssh using Cygwin

Richard — Thu, 04 Oct 2007 19:06:09 +0000

This is how I build pssh on Windows XP, using Cygwin and prc-tools.

Install Cygwin

Firstly install Cygwin. When asked for the Download Site, enter http://prc-tools.sourceforge.net/install and click “Add”. Now choose this new site, and also choose a mirror close to you (Ctrl-click to select multiple sites in the list).

I find it easier to click the “View” button to get the “Full” listing of packages – a flat list, ordered alphabetically by package name. In addition to the packages that are installed by default, you will also need:

gcc-g++
make
pilrc
prc-tools
prc-tools-arm

Palm SDK

I’ve always used a slightly older copy of the SDK, palmos-sdk-5.0r3-1.tar.gz. I’m not sure if this file is still available. An SDK is still available from Palm Developer Network, but I don’t think pssh can be built with it – not without modifying the code, anyway.

Create a directory in the Cygwin root called PalmDev, and unpack the SDK in there (which will create a directory called sdk-5r3).

Now you need to type palmdev-prep to make the dev tools find the SDK:

Checking SDKs in /PalmDev
  sdk-5r3       headers in 'include', libraries in 'lib'

When GCC is given no -palmos options, SDK '5r3' will be used by default

Writing SDK details to configuration files...
...done

Build pssh

Next you need to download:

the pssh source code, from http://www.sealiesoftware.com/pssh/
the peal source code, from http://www.sealiesoftware.com/peal/
libc.a and libgcc.a

Unpack the two zip files somewhere. You’ll have two directories, pssh-source-2005_06_23 and peal-2005_4_14. Put the two .a files in the same directory.

pssh expects peal to be in a directory called peal, so rename peal-2005_4_14 to peal.

Go into peal/postlink, and build peal-postlink by typing make.

Now go into the pssh-source-2005_06_23 directory and build pssh by typing make. This should create pssh.prc, the Palm application.

Don’t worry about the final error:

open pssh.prc
make: open: Command not found
make: [install] Error 127 (ignored)

As long as you have pssh.prc, the build was successful.

Pre-queue content-filter connection overload

Richard — Fri, 24 Aug 2007 18:54:28 +0000

Ever since updating my gateway to Fedora 7, I’ve been getting messages like this in my daily Logwatch:

84 *Warning: Pre-queue content-filter connection overload

Worrying that I might be losing mail, I looked at the logwatch script for postfix in /usr/share/logwatch/scripts/services/postfix, and discovered that this message refers to lost connections from clients whose IP addresses are unknown – in other words, entries in the postfix log that look like this:

Aug 24 19:44:17 gateway postfix/smtpd[29089]: lost connection after CONNECT from unknown[unknown]

This happens when postfix doesn’t know the IP address of the client, probably because the client is “disconnecting” before the connection to postfix is properly established.

Making the brightness keys work on a VAIO VGN-FE31H

Richard — Mon, 23 Apr 2007 20:17:56 +0000

After installing Windows XP on the VGN-FE31H, the screen brightness keys (Fn-F5 and Fn-F6) no longer work. To make them work again you need to install some of the utilities that ship with the laptop, which are also available in the FE3_Utilities.zip download from the Sony web site.

The three utilities are:

Utils Installer 1 SonyUtils DLL
Utils Installer 2 Sony Shared Library (this one needs a reboot)
Utils Installer VAIO Event Service

The “VAIO Event Service” needs to be running for the keys to work.

Passing reference data to the success view

Richard — Sat, 17 Mar 2007 12:14:51 +0000

When using Spring’s SimpleFormController, the default behaviour is to pass reference data to the form view, but not to the success view. However it’s very easy to override this behaviour, and access the reference data from the success view as well.

To do this, override the 4-argument onSubmit method like this:

protected ModelAndView onSubmit(HttpServletRequest request, HttpServletResponse response, Object command, BindException errors) throws Exception {
    ModelAndView mav = onSubmit(command, errors);
    Map refData = referenceData(request, command, errors);
    mav.getModel().putAll(refData);
    return mav;
}

If you’ve only implemented the 1-argument referenceData method, don’t worry; the default 3-argument referenceData just delegates to the 1-argument method, so your implementation will be called.

If you’re interested, you can see the code for SimpleFormController.

Case insensitive constraint names in MySQL

Richard — Mon, 12 Mar 2007 21:32:26 +0000

By default, MySQL takes advantage of case-sensitive filenames on Linux, with lower_case_file_system = OFF and lower_case_table_names = 0 (i.e. the filesystem is case-sensitive, therefore database names are case sensitive; and table names aren’t forced to lower case). In this situation it’s possible to have two different databases whose names differ only in case – for example, Photos and photos – although this should probably be avoided wherever possible!

The “FOREIGN KEY Constraints” section of the MySQL manual has this to say about constraint names:

If the CONSTRAINT symbol clause is given, the symbol value must be unique in the database. If the clause is not given, InnoDB creates the name automatically.

This isn’t completely accurate. Internally, InnoDB stores foreign key constraint names as case-insensitive, with the database name prepended. So although onedatabase.b_ibfk_1 is treated as different to anotherdatabase.b_ibfk_1, Photos.b_ibfk_1 and photos.b_ibfk_1 are treated as the same.

So if database names that only differ in case are to be avoided, why might this be a problem? Well, if you want to follow the advice in the MySQL manual, and use lower_case_table_names = 1, you need to change all database names to lower case before using the new setting.

Say you have this database:

CREATE DATABASE Photos; USE Photos; CREATE TABLE a (one INT PRIMARY KEY) TYPE=InnoDB; CREATE TABLE b (one INT PRIMARY KEY, FOREIGN KEY (one) REFERENCES a(one)) TYPE=InnoDB;

Notice the constraint on table b. Now you want to change the database name to photos, so you create a new database with that name, dump the tables and data from the old database with mysqldump, and then try to import them into the new database. You’ll get this error:

ERROR 1005 (HY000) at line 42: Can't create table './photos/b.frm' (errno: 121)

This slightly cryptic message is telling you that table b can’t be created in database photos – because the constraint name you’re trying to use in photos (lower case) is already used in Photos (upper case). The full details of the error can be seen in the output from SHOW INNODB STATUS:

070312 21:31:27 Error in foreign key constraint creation for table `photos/b`. A foreign key constraint of name `photos/ba_ibfk_1` already exists. (Note that internally InnoDB adds 'databasename/' in front of the user-defined constraint name). Note that InnoDB's FOREIGN KEY system tables store constraint names as case-insensitive, with the MySQL standard latin1_swedish_ci collation. If you create tables or databases whose names differ only in the character case, then collisions in constraint names can occur. Workaround: name your constraints explicitly with unique names.

There are a number of ways to get around this:

drop the old database before importing into the new one;
remove the constraints from the old database before importing into the new one;
manually change the constraint names in the export file before running the import.

Since MySQL 5.0 doesn’t allow a database to be renamed, it’s worth bearing this is in mind if you’re going through the mysqldump and import procedure to rename a database, where the old and new database names differ only in their case.

Building MySQL from source

Richard — Sun, 25 Feb 2007 14:45:22 +0000

After the introduction of the MySQL Enterprise Server, and the subsequent source-only release of Community Server 5.0.33, there was concern that MySQL would no longer provide official binary builds of the free Community Server. Fortunately, these concerns have now been addressed, but we will have to wait longer for binary releases.

In the meantime, you can either find an unofficial build, or build MySQL yourself. I decided to try and build it myself using the free edition of Visual C++.

The MySQL Reference Manual contains instructions for building from source on Windows. All you need is Visual C++ 2005 Express Edition, and the Platform SDK. Don’t use the links in the MySQL instructions; just follow steps 1 to 4 on this page: Using Visual C++ 2005 Express Edition with the Microsoft Platform SDK.

Now just follow the instructions for building using VC++, bearing in mind the following:

although the instructions refer to Visual Studio 7.1, they also apply to Visual C++ 2005 Express Edition;
when opening the .sln file, allow the Visual Studio Conversion Wizard to convert the solution.

The solution should build and you should end up with mysqld-nt.exe and mysql.exe (the server and client respectively) in SRC/client_release.

Read only and read/write NFS mounts on Fedora

Richard — Sat, 24 Feb 2007 15:18:00 +0000

I share several directories from my Debian server to other machines on the network using NFS. On one of these machines, which runs Fedora Core, some of the directories are mounted read-only, whereas others are mounted read/write. After upgrading to FC6 recently, I noticed that they’d all become read-only.

After looking into this I discovered that starting with 2.6.19, NFS groups directories from the same filesystem on the server, and treats them as the same filesystem on the client. Trond Myklebust, the maintainer of the NFS client, explained in this post to the Linux Kernel Mailing List:

“The new NFS mount code will put those in the same superblock, and whichever directory gets mounted first will determine whether or not the superblock is marked as read-only.”

If you’re interested in the full details, the change was made in commit 54ceac4515986030c2502960be620198dd8fe25b, entitled “NFS: Share NFS superblocks per-protocol per-server per-FSID”. This change isn’t mentioned on the KernelNewbies changelog for 2.6.19, but is of course in the official 2.6.19 changelog.

Here’s what happens on a new install of FC6:

[root@fc6test ~]# uname -a Linux fc6test 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:54:20 EDT 2006 i686 athlon i386 GNU/Linux [root@fc6test ~]# mkdir /mnt/{music,tmp} [root@fc6test ~]# mount 10.2.1.1:/data/music /mnt/music -r [root@fc6test ~]# mount 10.2.1.1:/data/tmp /mnt/tmp -w [root@fc6test ~]# touch /mnt/music/xxx touch: cannot touch `/mnt/music/xxx': Read-only file system [root@fc6test ~]# touch /mnt/tmp/xxx touch: cannot touch `/mnt/tmp/xxx': Read-only file system

Both mounts are read-only, despite the second one being mounted read/write. Also, while the output from mount and the contents of /etc/mtab say that music is read-only and tmp is read/write, the contents of /proc/mounts says that both are read-only.

Fedora Core 6 originally came with the 2.6.18-1.2798 kernel when it was released in October. This NFS problem affected FC6 from the beginning (despite the 2.6.18 kernel) because Red Hat backported the NFS change to their 2.6.18 kernel package.

Fedora Core 5 also exhibits this behaviour if you upgrade it to the latest kernel (2.6.19-1.2288 at present).

Several other people have reported this (see Red Hat bug 207670, this LKML post and Launchpad bug #75729).