What's it all about, Alfie?

This morning Apple released a new Software Update for Java on Mac OS X 10.5 and 10.4. For Leopard, Java is now updated to 1.6.0_07, 1.5.0_16, and 1.4.2_18 - all nice updates to their respective major versions. I haven't done any real code tests to see if it's that much faster, but it's an important development platform for me, so it's nice that they stay on top of the updates from Sun.

In the end - it's Java, what can you say?

"Necessary."

I like Twitter. It's an interesting async chat client. I like following the characters I follow. Interesting group. And I really wish I could tweet more. I really do. The problem is not that I can't, or don't have anything to say... it's as simple as the fear of retribution.

I work for some folks that would not appreciate that I'm talking from personal experience. Nope. Banks are funny that way. They aren't interested in your rights. They could not care less about what you think about the separation of work and personal life.

Nope. They like to get lawyers involved as soon as possible. We've got two of them on the same floor as I sit. It's sad, really. But in the end, I can't tweet because you can search tweets.

I'd think the government and shareholders would like to know about my tweets. Maybe there's something hiding under the covers here... maybe this place would want people to tweet to make sure the mere appearance of wrong-doing is ousted.

But they don't think that way. And I can't tweet.

Get a new job and maybe I can tweet.

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

It's a love/hate relationship with me and Comcast. On one hand, it's the fastest ISP I can get. On another, they are constantly trying to say they provide more on less infrastructure than anyone I know. If you can sell 100 homes 8Mbps speed and only have the infrastructure for 10Mbps - you're making a boatload of dough. But then you're not really providing what you're selling, are you?

Comcast is like this. Their latest round of "end user license agreement" changes says that they will shut you down if you hit 250GB/month. Now that's a lot - even for me - but the question is "Why?" If I bought a 12Mbps line from you - then you are making money on me to provide that level of service. Period. To say that's the "peak" is OK, as long as you say what the sustainable rate is. No different than cars and the Highway/City MPG numbers. Tell me the "best", but tell me the "actual" as well.

Also, Comcast is going to start putting lower priority on the packets of "bandwidth hogs" - not to stop them, but just slow them down. I'm with that - so long as it's over the purchased minimum bandwidth. But they don't do that. That is a hard cap at the cable modem, and it should be. No, this is for people they believe to be "too piggish" on their network.

Hey, Babe... you sold us something based on it's speed. You're making the money. Spend it on the infrastructure to actually provide the speed you're selling - schmucks.

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.

When people walk up to you before the markets open in the US and tell you to make sure everything is is tip-top shape because the day is going to get rough right out of the gate, you tend to think they are either hoping it'll be that way, or worried it'll be that way. Today things went up, but it's been a very hectic day.

The SEC suspending short-selling on 799 companies make it very clear that the 'free market' isn't free right now. The government has no plans on letting big banks file or consolidate to the point that it'll have anti-trust issues to deal with. Nope. And that makes people more optimistic about the stocks, and things go up. But I have to wonder how long the Administration is going to let this happen before things start to go bad because of the intervention?

Nixon's price freeze... I was a kid and I still remember that. Politicians are not good at running markets - they are too heavy handed and want immediate results. Confidence takes longer than that to build, as it took longer than that to erode it.

I just wonder where things are going to end. Wild times.

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.

As I was reading my Git Book this morning I noted that I was on v1.5.4.3 on my laptop, and it just occurred to me to check what the latest version of Git really is. I liked that this guy made an installer package that worked great as a Universal app on 10.5 (Leopard), but how far behind was he?

Turns out, a little bit.

I found that he had released a v1.5.5.0 Universal for Leopard that fixed the syncing over http, I think, but then I went to the source, and Git is really on 1.6.0.2 (stable), and that's a more significant version jump. Also, I saw that the Google Groups Git-OSX-Installer was on 1.6.0.1, and while it was Intel-only, that's all I've got for Leopard. So that seemed like a good move to make.

The first package deposited a lot of things in /usr/local/bin and such, whereas the Google Groups package is in /usr/local/git and everything is hanging off there (for the most part, we'll get to the exceptions in a minute). This looked like a cleaner uninstall as well, should Apple decide in Snow Leopard (10.6) to add in Git like they did Subversion for 10.5.

So I figured out how to get rid of the old package. Go into it's Contents directory and there should be a file called Archive.pax.gz where all the files are packed together. We can get a look at them with:

  gzip -d < Contents/Archive.pax.gz | pax -v | awk '{ print $9 }'

and all the files will be listed. Nice. I made a script to clear it all out and ran it. I then installed the new Git 1.6.0.1 package and it went in well, but the git commands like git-svn weren't in the /usr/local/git/bin directory, so they weren't going to be seen by the command line. I suppose that's not what this guy's doing, and that makes me a little nervous, but I'll go with it for now.

In order to get the paths right, I had to modify the installed file /etc/paths.d/git to look like:

  /usr/local/git/bin
  /usr/local/git/libexec/git-core

and then make use of the fact that in OS X 10.5, Leopard, the directories /etc/paths.d and /etc/manpaths.d are set up to take files listing directories to add to their respective paths if you know how to use it. So I added to my !/.tcshrc the lines:

  #
  # First, let's pick up all the paths from the system
  #
  if (-x /usr/libexec/path_helper) then
    eval `/usr/libexec/path_helper`
  endif

and we'll get the directories added to the path.

I then set up my Git global environment so that I should be ready to start working with it. I added my name and email... set up to use the colors on the commands... set up the ignore file... that kind of stuff. Nothing necessary, but all nice things to do before starting to use the tool. I think I'm ready.

Note: I like this logo for Git more as it seems to say to me the adding and deleting as well as the cycling nature of source control. And at the same time, like an emoticon, turn your head sideways and it's "Git". Sweet. Clever cats, these guys.

UPDATE: Interesting... it seems that as I read more, the commands like git-svn are really simply alternative ways of calling git commands directly. For example, git-svn is a direct command for git svn (no hyphen). This means that the Google Groups installer was right and I didn't need to add the /usr/local/git/libexec/git-core/ directory to my path! Very interesting. However, as you can imagine, if you want to call git-svn directly, then you need this directory in your path.

I've decided that the book I'm reading does not use the hyphenated commands, so I'm going to leave the install as-is and that's a big load off. It means that the guys building it are thinking the same as the author, and that's the kind of consistency I need in learning a tool like this.

I've been doing a lot of thinking this morning about what's important to me. I can't deny that the main reason I'm in the job I'm in is because of the amazing pay. I mean, it's amazing. And I have to admit that the development work is fun. But I can do that anywhere - I'm a developer, after all.

But that's the point. I want to develop. I don't want to mess with Jira tasks. Especially ones that are as poorly written and duplicate the same problem, cover multiple topics, used as email, etc. It's not what a bug tracking system is ment to be doing. It's a hack. Product itself is probably fine. It's the usage.

So I've been thinking about what I want to do. I want to code.

I heard about a job today that just mentioned Mac OS X as a "plus". That single fact was enough to get me interested in the job. Simple things like the platform you really like make all the difference. Heard about another doing more Java work - same thing in reverse. I can do Java, but it's not exciting to me anymore.

I'm reading about Git - sounds fun. Why? Because it's a new way of doing the same old thing, but getting around some of the problems I've had for ages. How to do a CVS check-in on the train in the evening? Can't. Can with Git. Cool. That kind of stuff.

So as I'm sitting here thinking about what I need to be doing next, I'm realizing that a new challenge really does sound like fun. Something new to do, not change for change's sake - something interesting. We'll see what comes up.