What's it all about, Alfie?

I saw today that HostMonster had the update from Fantastico for WordPress 2.6.2 - and I needed to upgrade. These upgrades have become very routine - but the first few were real nail-biters for me. Thankfully, the Fantastico guys know what to do and the upgrades have been flawless.

Now we're on the recent version of WordPress and that's good to know. I have to say that getting an account on HostMonster was an excellent move for me. I can't imagine having a better hosting experience.

This morning I got notice on the mailing list that the MacVim team has released Snapshot 36 to fix the problem in Snapshot 35 of dropped characters when they are input too quickly. Seems the developer was tinkering around with changing the input queueing of the keystrokes, and it ended up dropping things. He fixed that up and also took care of several memory leaks.

Excellent work. I continue to be amazed at the level of integration they are doing with Vim on the Mac. Love it.

This morning I saw that Perian 1.1.1 is out, and I tried to get it. First, through the auto-updater in Perian itself, and then directly from the Perian web site. I was stunned... it took me several hours to get the update, and in the end the auto-updater was the 'winner'.

I was stunned. I've never seen a web site under such load. I may be trying to infer causation in a correlational study, but if they are getting hit this badly from an update, they might need to get a better hoster - or maybe get more donations because this thing is big.

I'll admit, I probably never see it in action - QuickTime just works and the plugin is just that - a plugin. But I have to say I'm impressed. Go get 'em guys!

There was a minor bug in the saved passwords code that caused some users not to be able to retrieve them, and that caused the developers to release 3.0.3. If I were impacted, I'd have wanted a fix, but as it was, I wasn't and things were fine.

As an aside, I've gone back to using the straight Firefox as the guy building optimized versions for the different processors is at 3.0.1 and if he catches up I may try to compare the two, but I have a feeling that it's like the MacVim tests I've done - on my machine the difference might very well be next to zero.

This morning I got word that the MacVim maintainers released Snapshot 35 with several bug fixes and added features including faster drawing. I had to get it right away.

After some testing I'm still a bit surprised that the ATSUI renderer is not proving to be any faster on my MacBook Pro than the default renderer. My last theory that they are both being backed by the same Core Graphics methods would lend weight to the non-difference, and that might be effected by the graphics card being used. So maybe on a slower box or worse graphics card, the difference is clear, but on mine they are dead even.

Not bad... just interesting. I love Vim.

Different folks, I know, but a nice pair of updates from the Mozilla Camp - Firefox 3.0.2 and Camino 1.6.4. The Firefox update seems to be focused on the security angle - good enough, and the browser wasn't bad to begin with, but they seemed to have squeezed in a few nice things. Several additional languages have been added, some fixes for the right-to-left languages, and even some Mac-specific bugs fixed.

Gotta get it, folks. Great browser.

Camino 1.6.4 is really the surprise for me today... it's got the latest rendering engine and boy is it improved. The previous version wasn't even worth using for more than a few minutes. This is fast enough now on pages to actually use. I'll be playing with it in the weeks to come, but if they keep making progress like this, I may move from Firefox as my #2 to Camino. It's really kicked in the speed. Great work, guys!

After reading up a little more on Camino, I have to say it seems like I'd like these guys. They are serious about making nice Mac software on the Mozilla codebase. Can't beat that. They have tried to incorporate the Safari-like Find interface, and several other nice things I use to make it a natural conversion from Safari to Camino. Yes... if the speed holds up, I may switch to Camino as my #2. Nice work.

UPDATE: I'm sad to see that the buttons in Camino are a mess. Maybe it's just the few web sites I tried, but the text was horribly off-center and the buttons barely looked like buttons at all. Not good, sad to say. But getting better, little by little.

In a previous post I discussed getting Git running on Mac OS X 10.3.9 - which is what's running on frosty my Snow iMac G3 in my office. It would be running 10.4 if it had a DVD drive, but it's still fine and every now and then it's a hassle - like with installing Git, but in the end I have Git 1.6.0.2 running on it just fine, and that's what really matters.

This installment is about getting public and private access to the Git repositories that I'm planning on hosting on this box. While you don't have to have a central repository for team members to sync with, I will work this way as it also provides people with a way to anonymously get the repo and decide if it's got something for them.

Private Repository Access

While the traditional way to handle Private repo access is to have accounts on the machine for each team member, I'm going to use Gitosis. This is a neat little package that allows you to simply have the id_rsa.pub SSH public keys for the users and then have a single user (git) handle all the authentication and push/pull work with Git.

Let's get started. The first thing I did was to add the user 'git' to my Mac using the traditional System Preferences application. Just add them with a password, etc. that you know (it will not be visible to the team members) and then you're ready to go to the next step. Typically, this places the files for the account into /Users/git and that's OK with me as the repositories will be placed in a directory off this users' $HOME directory.

The Python that comes with OS X 10.3.9 is Python 2.3, and we're going to need a more up-to-date version - say 2.5. I got this from the PythonMac.org website. Install it and then make sure that /usr/local/bin is very near the beginning of your path (and the path for the 'git' user). Make sure that you have this in the right place by checking:

  $ python -V
  Python 2.5

If you get the right response, you're looking good.

Unfortunately, Gitosis is going to need a little more and that "little more" is the Python library 'setuptools'. We have to get that, and install it, which is pretty simple:

  curl -o setuptools-0.6c8-py2.5.egg \
      http://pypi.python.org/packages/2.5/s/setuptools/setuptools-0.6c8-\
              py2.5.egg#md5=1721747ee329dc150590a58b3e1ac95b
  sh setuptools-0.6c8-py2.5.egg

the URL in the second and third lines is really one line and you have to make sure to have the name of the file exactly as indicated as that's used by the installer to know what to do. Once this is done, we're ready for the next step - installing Gitosis.

While the Gitosis talks about the location of the install, I've found that it's good advice and there's only one little hitch on OS X 10.3.9 - that is, that the Gitosis commands are not deposited in the PATH. So, we need to get the package and install it:

  su - git
  git clone git://eagain.net/gitosis.git
  cd gitosis
  sudo python setup.py install

and then symlink the executables from their install locations on OS X 10.3.9 to the obvious - /usr/local/bin:

  cd /usr/local/bin
  sudo ln -s /Library/Frameworks/Python.framework/Versions/2.5/bin/gitosis-init .
  sudo ln -s /Library/Frameworks/Python.framework/Versions/2.5/bin/gitosis-run-hook .
  sudo ln -s /Library/Frameworks/Python.framework/Versions/2.5/bin/gitosis-serve .

At this point, we're ready to initialize Gitosis for the one user (me):

  su - git
  cd /Users/git
  gitosis-init < /Users/drbob/.ssh/id_rsa.pub
  chmod 755 repositories/gitosis-admin.git/hooks/post-update

where the SSH public key file (/Users/drbob/id_rsa.pub) can be from your other machine, or where ever - I just happened to already have all my public keys on this server, so it's easy.

A point worth mentioning is that the last chmod command is needed because the setuptools doesn't properly set the execute permissions on the file and they need to be set in order for Gitosis to work properly.

We're ready to us the private access! I have already set up the DNS entry for git.themanfromspud.com to point to the machine, and put a hole for port 9418 in my router/firewall for this guy, so I can say from any machine:

  git clone git@git.themanfromspud.com:gitosis-admin.git
  cd gitosis-admin

and I'm ready to go!

At this point, it seems reasonable to follow the outline of steps here to add groups and users based on their SSH RSA public key files. I haven't needed to do that yet - but certainly will as time goes on. Got all the notes I need in VoodooPad.

Public Repository Access

This doesn't look as bad as the other, but it took me a lot longer as I was stumped trying to figure out why it wasn't working. Basically, I wanted to add git:// as an xinetd service to the box, and I was getting a ton of errors like:

  $ git clone git://git.themanfromspud.com/gitosis-admin.git
  Initialized empty Git repository in /Users/drbob/gitosis-admin/.git/
  fatal: The remote end hung up unexpectedly

To start at the top, you need to make sure that we have the line for the protocol in /etc/services:

    git   9418/tcp       # Git Version Control Repo Viewer

and then in /etc/xinetd.d you need to create a file git-daemon which contains:

    # default: off
    # description: The git server offers access to git repositories
    service git
    {
        disable = no
        socket_type = stream
        wait = no
        user = git
        env = PATH=/bin:/usr/bin:/usr/local/bin:/usr/local/libexec/git-core
        server = /usr/local/libexec/git-core/git-daemon
        server_args = --base-path=/Users/git/repositories/ --export-all --inetd
        log_on_failure += USERID
    }

and then send a kill -HUP to the xinetd process. The tricky point for me was the env = PATH=... line - without it the xinetd process does not know the path to the executables even with the path specified! So make sure it's there. After this, you should have the protocol working so you can say:

  $ git clone git://git.themanfromspud.com/gitosis-admin.git
  Initialized empty Git repository in /Users/drbob/gitosis-admin/.git/
  remote: Counting objects: 5, done.
  remote: Compressing objects: 100% (4/4), done.
  remote: Total 5 (delta 0), reused 5 (delta 0)

I have an old(er) Snow iMac G3 at home that I use for my CVS pserver and I wanted to get it working as my Git repo hosting server as well. The problem was that I didn't have a working Git executable for 10.3.9, and so I needed to get it from source and build it from scratch. This is all the little work I had to do to get that to work. Later, I'll discuss getting the repo hosting going, but that's gotta wait until after I get this done.

I had to get a lot of packages to make this all work, but now that I have them, getting new versions of Git should be easy. Lots of up-front work, but worth it in the end. As a matter of personal preference, I put all the projects in my ~/Developer directory, but you can put them in /usr/local/src or some other place. It really doesn't matter. Also, while you can specify any PREFIX you want, I've chosen the traditional /usr/local so that everything is thrown in there - for all packages.

NOTE: if all you're interested in doing is getting Git running on OS X 10.3.9 - then skip to the section at the end about Git - that's all you need. The rest of this preamble is all about being able to generate the man pages (docs) for Git, and since I am planning on using this for a while, it seemed reasonable at the time (HA!) to do it. What a lot of work for a few man pages.

A Big Help was provided by this page where a lot of the steps were the same, but a lot had to be changed. It was a good place to start, and he clearly, like me, wanted to have it all with Git, and went through the effort to figure it all out. Kindred spirits...

gettext

The problem is a chain of dependencies that OS X 10.3.9 doesn't have. In order to make the build in a "no failure" stream (that means building the core components first, and then get to the successive ones later) we need to start at the bottom. The bottom in this case is gettext. We need it for getopt. We need getopt for xmlto. We need xmlto for building the Git docs. Simple, but a lot of tedious work.

In order to install gettext we need to get it, configure it, build it and install it. Like most good GNU projects, it's pretty clear (if not short and quick):

  curl -o gettext.tar.gz http://mirror.anl.gov/pub/gnu/gettext/gettext-0.17.tar.gz
  tar zxvf gettext.tar.gz
  cd gettext-0.17
  ./configure
  make
  make check

which should look OK on the outputs, and then install it with:

  sudo make install

getopt

The next piece of the puzzle is GNU getopt as it's got the support for the long options - as opposed to the single-character kind in the getopt on OS X 10.3.9. So to get this guy installed we needed to:

  curl -o getopt.tar.gz \
      http://software.frodo.looijaard.name/getopt/files/getopt-1.1.4.tar.gz
  tar zxvf getopt.tar.gz
  cd getopt-1.1.4

but there are a few edits that are needed to make this work on 10.3.9. The first is in the Makefile itself. Change:

    LIBCGETOPT=1

to:

    LIBCGETOPT=0

and then change:

    LDFLAGS=

to:

    LDFLAGS=-lintl

At this point, we can make it and install it:

  make
  sudo make install

There were still errors in the make, but they aren't a problem at this point.

DocBook (XML Catalog)

Because xmlto is the key player in this fiasco, and because OS X doesn't have the default DocBook XSL stylesheets and XML files, we need to create them. It's not too bad, just make room for them, download them, and install them:

  sudo mkdir /etc/xml
  sudo xmlcatalog --noout --create /etc/xml/catalog
 
  sudo mkdir -p /usr/local/share/docbook/xsl
  cd /usr/local/share/docbook/xsl
  sudo curl -o docbook.tar.gz \
     http://voxel.dl.sourceforge.net/sourceforge/docbook/docbook-xsl-1.74.0.tar.gz
  sudo tar zxvf docbook.tar.gz
  mv docbook-xsl-1.74.0 1.74.0
  sudo xmlcatalog --noout \
     --add 'nextCatalog' '' 'file:///usr/local/share/docbook/xsl/1.74.0/catalog.xml' \
     --create /etc/xml/catalog
 
  sudo mkdir -p /usr/local/share/docbook/xml
  cd /usr/local/share/docbook/xml
  sudo curl -o docbook4.2.zip \
     http://www.oasis-open.org/docbook/xml/4.2/docbook-xml-4.2.zip
  unzip docbook4.2.zip
  sudo mkdir 4.2
  cd 4.2
  sudo unzip ../docbook4.2.zip
  sudo xmlcatalog --noout \
     --add 'nextCatalog' '' 'file:///usr/local/share/docbook/xml/4.2/catalog.xml' \
     --create /etc/xml/catalog

Lot of work for something I don't plan on using, but that's the very nature of this exercise, it seems. Very time-consuming.

xmlto

Now that we have everything this guy needs, he's pretty simple (HA!) All we need to do is to get the package, configure, make and install:

  curl -o xmlto.tar.bz2 https://fedorahosted.org/xmlto/export/1/xmlto-0.0.21.tar.bz2
  tar --bzip2 -xvf xmlto.tar.bz2
  ./configure
  make
  make check
  sudo make install

AsciiDoc

The last requirement for the docs is to get asciidoc installed on your machine. So let's get the AsciiDoc project as a tarball from it's downloads page - or use curl, as I did:

  curl -o asciidoc.tar.gz http://www.methods.co.nz/asciidoc/asciidoc-8.2.7.tar.gz
  tar zxvf asciidoc.tar.gz
  cd asciidoc-8.2.7

In the INSTALL file in the project, it explains that you might need to edit a few of the directory locations, and sure enough, I did. The biggest one is the location of the Vim support files. To do this, change the line in the install.sh file to look like:

  VIM_CONFDIR=/usr/share/vim/vim62

which is where Vim's support files are for OS X 10.3.9.

There is a problem in asciidoc with regards to the usage of /etc on Mac OS X. The fact is on OS X, /etc is really /private/etc and so this bug was reported, and the fix is to change asciidoc.py line 127 (or thereabouts) from:

      directory = os.path.abspath(directory)

to:

      directory = os.path.realpath(directory)

At this point, you are ready to install asciidoc by simply following the INSTALL instructions:

  sudo ./install.sh

Git

If you're just interested in getting Git running - no docs, then you can start the process here. It's pretty simple - get, configure, make, and install:

  curl -o git.tar.gz http://www.kernel.org/pub/software/scm/git/git-1.6.0.2.tar.gz
  cd git-1.6.0.2
  ./configure
  make
  sudo make install

If you followed all this crazyness, and want to install the docs (man pages) as well, then you can type this:

  make all doc
  sudo make install-doc

and then make sure that you have /usr/local/share/man in your MANPATH to pick these guys up.

At this point, you're ready to use Git, and if you went through all the work I did, you can view the man pages as well. Took a couple of hours, but it's worth it in the long run - I plan on using Git for a while.

Now I need to get a server set up - which is what caused this detour in the first place...

I've gotten through most of my book on Git, and I have to say, for something that's so easy to use in a stand-alone mode, getting it going on a server for sharing is incredibly difficult. Now I see the point of Gitosis.

Gitosis is a open source project written in Python 2.5 to manage the Git repository scheme with a single account and supposedly make it easier to handle all the set-up issues of Git. Well... after digging through this all, I have to say it seems to make things easier. But 'easy'? Not in a million years. I've put up CVS servers in a few minutes - and Gitosis might make it easier, but it's still a serious pain in the neck. And this doesn't cover the git:// read-only access - this is just for the SSH-based uploading.

I'm going to have to take some time to work through all this, taking notes as I go, because there looks to be a ton of steps to get right in order to be able to host a Git repo. Then there's gitweb - the web viewing tool, and git-daemon - the read-only git:// server. This is going to take a while.

I was setting things up for Git and I came across the setting to have the Git 'merge' command actually pull up an external application - and in this case opendiff. I had always used FileMerge.app from my old NeXTSTEP days (it wasn't called that, back then, but it was the same tool), and loved the way it showed my differences in as concise a way as possible. It's really pretty impressive graphics work for a file diffing tool.

What I didn't know about was the fact that Apple had aliased the command-line opendiff to the FileMerge.app! Now I could easily use this diffing tool in all kinds of places. I was really jazzed. I do love working on this platform.