Recently I found myself with shell access on a host without a git client installed, and also without the necessary build tools to compile it (gcc, make, etc…).  However, I did have access to a machine with the same processor architecture (in fact, the same exact processor).  If you mange to find yourself in this situation, what you need to do is compile git statically on the machine which does have gcc and make installed.

What’s static mean?

In the compilation process, the compiler usually must link in shared dynamic libraries.  In Windows, these are called .dll files, and in linux they are usually .so files.  These libraries are simply collections of compiled functions that can be reused for many different programs that require them to do a specific task.  By sharing these libraries, the computer can save RAM and hard drive space by only requiring one copy of a specific library to be present for many programs that have been compiled for it.

In order to avoid unexpected behavior, a program must sometimes be compiled with a specific version of a dynamic library in mind.  This isn’t always true, but in order to ensure portability and expected behavior it’s important.  In linux, your package manager takes care of making sure these version dependencies are satisfied correctly.  However, this can be a problem when you’re stuck on a machine for which you have no control over.  You can’t know for sure what version of a specific library is installed, or when it will be upgraded.  You could build your program on another machine with the same processor architecture, and with the same libraries and then just copy it over, but that leaves room for breakage down the line in case your target machine’s libraries are upgraded, or if any of the libraries on the target machine are compromised or replaced by malicious versions.  Here’s where statically building comes in handy.

How to build git with static linking

This example assumes you already have access to a machine with build tools already installed.  This build machine is also assumed to have the same processor architecture as your target machine.  You can find the latest stable release of git at: http://git-scm.com

Here are the steps to take:

1) On your build machine, get the source code for git, unpack it, and go into the source directory:

$ wget http://kernel.org/pub/software/scm/git/git-1.7.2.2.tar.bz2
$ tar -jxvf git-1.7.2.1.tar.bz2
$ cd git-1.7.2.2

2) Configure git to install to a predetermined directory, with static linking.  (Replace /home/myuser/git-static
with whatever path you want):

$ mkdir /home/myuser/git-static
$ ./configure --prefix=/home/myuser/git-static CFLAGS="${CFLAGS} -static"

3) Make git and install it to your directory

$ make
# Optional: make man pages and documentation
# Assumes you have asciidoc and other required programs on your build machine
$ make doc
# Install to your target directory
$ make install

4) Assuming all went well, now you can pack it up into a tarball for transfer to your target machine.

$ cd /home/myuser/git-static/
$ tar -cjvf git-static.tar.bz2 ./*

5) Copy it over to your target machine however you can, and unpack it to your home directory there with tar:

$ cd ~
$ tar -jxvf git-static.tar.bz2

# Check that you can use git.
# If you can't, make sure that your ~/bin directory exists in your environment's $PATH
$ git --version

6) Enjoy!

I finally got my home development server completely updated, including a freshly compiled Gentoo hardened kernel!  Now that I’ve got my server setup and working smoothly again, I started looking into the IDE side of the equation so I could do PHP web development on my laptop.

So after looking around a bit, I stumbled upon the idea of using Eclipse to do PHP development.  In the past I have disliked Eclipse due to it’s tendency to have problems with it’s workspace “.metadata” files over time, along with it’s slowdowns and/or freezing.  However, after seeing a presentation about Mylyn I reconsidered.  After looking up some other plugins, I was convinced that Eclipse is definitely worthy of a second look.  What’s Mylyn you ask?  In a nutshell: Mylyn is a task oriented plugin to Eclipse, giving you the benefit of saving what files & tabs you have open in Eclipse for a specific task.  A task can be anything, a bug report in Bugzilla that you’re working on, or simply a powerpoint presentation (An example given in the presentation with Tasktop Pro, the fully featured task oriented desktop app from Tasktop Technologies).

Why am I reconsidering Eclipse?  Well for starters:

1. It’s built on Java, so I won’t be tied to using Windows for my laptop forever (Eventually I’m looking into getting a Mac)
2. Mylyn allows integration with Bugzilla, along with a solution to my constant “too many tasks with too many tabs” problem.
3. It includes built-in task scheduling features, perfect to start training myself to do better time management.
4. Allows for developers to share “contexts” for each task (or bug) with one another, allowing for easy views on what parts of the code a bug/feature affects.  Collaboration is made that much easier!
5. The PHP Development Tools (PDT) project gives PHP code completion, PHP debugging (once you install an apache server library), and all the other nice standard features of Eclipse.  For the Apache module, you’ve got the choice of either the free & open source XDebug or the binary blob Zend Debugger.
6. The Subclipse plugin allows for nice integration with SVN (although I prefer git, I am forced to use for a couple projects).  I was also familiar with using this plugin in my college’s Software Development class, where we used Eclipse & SVN to do Agile Java programming with many different teams over the course.
7. The Ajax Tools Framework (ATF) gives many of the features that the FireBug plugin for Firefox supports including: DOM Inspector, JavaScript Debugging, live CSS style editor, and all that good stuff.  It does this by embedding Mozilla into Eclipse!

I’m really excited to start debugging PHP code on the server.  Previously I’d been using jEdit, an SSH terminal, and Firefox to develop.  This upgrade should improve my productivity a lot.

On Friday & had a quite eventful day involving a bunch of lucky and happy coincidences, along with an amazing spurt of ultra-productivity!  Although it was an interesting day, that’s not what this post is about.

At one point, I was working on creating a CUE sheet for episode 004 and realized that GoldWave was clobbering all the PERFORMER attributes for every track in the original CUE sheet I imported!  That was definitely no good, and really irritated me at the time.

My current workflow for CUE-ing a mix is as follows:

1. Export tracks from Traktor to a directory (ie: “~/Music/LyraPhase/004″), then make sure tracks are in order & named in the format: 01 – Artist – Trackname.mp3
2. Make a tracklist text file:
   ~/Music/LyraPhase/004$ ls -l --color=never > LyraPhase_004.txt
3. Run my magical script to generate a CUE file with empty INDEX points:
   ~/Music/LyraPhase/004$ tracklist2cue.pl LyraPhase_004.txt
NOTE: all tracks have initial cutpoints of 00:00:00
Opening tracklist file: LyraPhase_004.txt
Writing cue file to: ./LyraPhase_004.cue
4. Import the blank CUE file into GoldWave, listen, do audio processing stuff, then edit the track INDEX points.
5. Save the wav & CUE files.
6. Find out some extra stuff is gone after GoldWave got through with it

Enter perl:

So since I really like GoldWave otherwise, I decided to go dust off my monk robes & dive into perl again.  The initial goal was to be able to read in the 2 CUE sheets, copy INDEX points from one to the other, and then save it again.  I also have been thinking about other things in the future I may want to do with CUE sheets, so I decided to try to find some perl code to do what I wanted.

After a search, I found a module on CPAN called Audio::Cuefile::Parser which really didn’t do everything I wanted, or fully support the entire CUE file specification as per the documentation here.

After 1.5 days worth of hacking at it, I’ve successfully got 1/2 of the problem solved.  So far my Audio::Cuefile::ParserPlus module will happily read in CUE sheets and print out the track information for you.  The next step is to make a file output method, which should be simple now that the hard part of parsing in things via regex is finished ^_^

Current code snapshot can be found at my GitHub Repository
Happy Hacking  ^_^

- DJ Phasic

Thanks to the local dev server setup I have, along with svn and git, I’ve successfully and painlessly updated to wordpress 2.8.5.  Pushing changes to the wordpress_base branch on my site is quite simple, as I don’t really plan on modifying the core wordpress code that much.  Any changes to the code made by an svn update will only change files that I probably haven’t ever touched, so merging branches should be painless.  Plus, the core wordpress code is tracked by svn, while both the core code and my changes are tracked by git.  That way, I’ve got my own local branches that incorporate any updates made by svn, plus everything else.

In case you’re really interested and wondering how this is all done, see the following links:

http://codex.wordpress.org/Installing/Updating_WordPress_with_Subversion#Tracking_Stable_Versions

http://blog.zobie.com/2008/12/managing-wordpress-updates-with-git/

Basically all you have to do is follow the wordpress update instructions from the 2nd link, but replace the svn switch command with the one found at the 1st link.  The way to update in git is pretty smart, since all core wordpress code changes are tracked in the main wordpress_base branch, then updated via svn, put the changes into a new integration branch, then rebase the master branch onto that one & checkout the merged changes to the master branch.

Originally it seemed stupid to use svn to track the remote wordpress repo, however I tried using git’s svn capabilities and found that the only supported way to switch svn tags within git broke everything, so it’s actually better and more painless to use both CVS systems.