Jenkins git clone via SSH on Windows 7 x64

Install Windows 7 x64 (…um…duh…)

Download and install Git for Windows from

Download and install Jenkins for Windows from

Install the Git plugin:

  • Go to “Manage Jenkins” –> “Manage Plugins” –> “Available”

  • Check the box next to “Git Plugin”

  • Click “Download now and install after restart”

  • After the message “Downloaded Successfully…” check the box “Restart Jenkins…”

  • Click the link “ENABLE AUTO REFRESH” in the top right of the page

Now we need to configure Jenkins to know where the git cmd is located.

Go to “Manage Jenkins” –> “Configure System”

Under “git” change “Path to Git executable” to C:\Git\cmd\git.cmd (NOT C:\Git\bin\git.exe)

Click the “Save” button

By default, the Jenkins installer sets up Jenkins to run as a service, which runs as the “Local System account”, NOT your user account. Since the “Local System account” does not have SSH keys or known_hosts set up, “git clone” will fail.

We need to add your Jenkins build SSH keys (id_rsa and to the “Local System account” and we need to populate the known_hosts file with the remote server info.

IMPORTANT: make sure your ssh keys do NOT have a password! Jenkins will appear to hang when cloning the repository, but really it’s ssh blocking in the background waiting for you to input your password.

First, copy your Jenkins build SSH keys into C:\Git\.ssh so that ssh.exe can find them.

Open a normal cmd.exe shell and type the following:

c:\>"C:\Git\bin\ssh.exe" -T git@your.git.server

You should get a response that looks like:

The authenticity of host 'your.git.server (' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)?

Type yes and you should see something like:

Warning: Permanently added ',' (RSA) to the list of known hosts.

This has added the remote server to C:\Git\.ssh\known_hosts

Next, copy C:\Git\.ssh to C:\Windows\SysWOW64\config\systemprofile\.ssh (the “Local System account” home).

Now set up a new Jenkins job and you should be able to clone via SSH!

If you want to actually test running git commands AS the “Local System account”, you need to run cmd.exe as the “Local System account”, which requires PsTools.

Download and extract PsTools from

Open a normal cmd shell and run:

c:\>PsTools/PsExec.exe -i -s cmd.exe

This should open a new cmd prompt running as the “Local System account” and any SSH commands you run in this account will use the keys in C:\Windows\SysWOW64\config\systemprofile\.ssh

You can now test Git commands running as the same user as Jenkins.

Build the latest mspgcc toolchain on Mac OSX 10.7 Lion with Stow and MacPorts

UPDATE – 1/10/2011

  • I updated the script to build the latest mspgcc toolchain automatically (i.e. without having to update the revision numbers by hand in the script)

I wanted to try out the latest mspgcc toolchain (20111205) on OSX, but it appears that the osx-launchpad project is still using 20110716 (as of this time of this post).

Quick Robin! To the compile-mobile!

To keep my sanity, I usually use GNU Stow to install things that I compile myself (i.e. everything that doesn’t come nicely packaged from MacPorts). From the GNU website:

GNU Stow is a program for managing the installation of software packages, keeping them separate (/usr/local/stow/emacs vs. /usr/local/stow/perl, for example) while making them appear to be installed in the same place (/usr/local).

Here’s how to build mspgcc-20111205 on Mac OSX 10.7 Lion using packages from MacPorts and install the toolchain using Stow:

  1. Instruct MacPorts to update itself and sync:

    sudo port selfupdate
  2. Install wget

    sudo port install wget
  3. Install GNU Stow

    sudo port install stow
    1. Make the stow repository

      sudo mkdir -p /stow/repository
    2. Add this to ~/.profile

      export PATH=/stow/bin:/stow/sbin:$PATH
    3. Source ~/.profile

      source ~/.profile
       echo $PATH
  4. Install gcc45 and tell MacPorts to select it as the default compiler (I had issues compiling gcc below using gcc42 that were fixed by installing gcc45)

    sudo port install gcc_select gcc45
     sudo port select gcc mp-gcc45
  5. Install mspgcc dependencies

    sudo port install gmp mpfr libmpc libiconv dejagnu libusb-compat libelf
  6. I’ve adapted the script from the osx-launchpad source to configure all packages with PREFIX=/stow/repository/mspgcc-$TOOLCHAIN_VERSION (also removed the packaging stuff).

  7. Build the toolchain

  8. Stow the toolchain

    cd /stow/repository
     sudo stow msp430-uniarch-20111205
  9. Install srecord (for manipulating EPROM load files, i.e. srec_cat)

    sudo port install srecord
  10. Test the compiler (download the Makefile and null.c below into ~/some/test/dir)

    cd ~/some/test/dir

Running meld on OSX 10.7 Lion

Install meld via macports:

sudo port install meld

When I tried to run meld, I got this error:

Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!
Traceback (most recent call last):
  File "/opt/local/bin/meld", line 123, in 
  File "/opt/local/bin/meld", line 115, in main
    app = meld.meldapp.MeldApp()
  File "/opt/local/lib/meld/meld/", line 136, in __init__
    self.prefs = preferences.MeldPreferences()
  File "/opt/local/lib/meld/meld/", line 289, in __init__
    super(MeldPreferences, self).__init__("/apps/meld", self.defaults)
  File "/opt/local/lib/meld/meld/util/", line 92, in __init__
    self._gconf.add_dir(rootkey, gconf.CLIENT_PRELOAD_NONE)
glib.GError: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See for information. (Details -  1: Failed to get connection to session: Not enough memory)

This is because dbus isn't running (

To fix the issue, run:

$ sudo port notes dbus
dbus has the following notes:
  # Startup items have been generated that will aid in
  # starting dbus with launchd. They are disabled
  # by default. Execute the following command to start them,
  # and to cause them to launch at startup:
  # sudo launchctl load -w /Library/LaunchDaemons/org.freedesktop.dbus-system.plist
  # launchctl load -w /Library/LaunchAgents/org.freedesktop.dbus-session.plist
$ sudo launchctl load -w /Library/LaunchDaemons/org.freedesktop.dbus-system.plist
$ launchctl load -w /Library/LaunchAgents/org.freedesktop.dbus-session.plist

git + gitolite + git-daemon + gitweb setup on Ubuntu 11.10 server

UPDATE – 02/10/2012

  • No need for sudo for the couple commands after sudo su - gitolite (thanks @SSK)

UPDATE – 11/05/2011

  • Fixed typo in git-daemon section from older Ubuntu versions (thanks @adrian)

UPDATE – 10/26/2011

  • Fixed ssh key typos (thanks @David)

UPDATE – 10/17/2011

  • Updated everything to work on Ubuntu 11.10 server and fixed a couple wrong/missing steps in the process

UPDATE – 10/16/2011

(thanks to @Elena and @admin in comments for catching my goofs)

  • Fixed typo (changed chmod 666 /tmp/ to chmod 644 /tmp/
  • Replaced the bits about restarting

UPDATE – 5/8/2011

  • This works on Ubuntu Server 11.04 as well.

  • Fixed the section at the bottom about editing /etc/sv/git-daemon/run because I forgot to include the bits about changing the base-path and directory. Sorry bout that…

  • Added bits about setting gitweb owner and description

  • Added url rewrite bits

  • Added optional bits for /etc/gitweb.conf

  • Added gitweb theme

So here’s the skinny on getting git, gitolite, git-daemon, and gitweb set up on your Ubuntu 11.10 server using the packages from apt.

Make sure to read this entirely and follow every step!

git setup

Install git and doc:

sudo apt-get install git-core git-doc

Setup your username and email:

git config --global "Your Name"
git config --global

gitolite setup

gitolite uses ssh keys to manage access to the git repositories. In the following steps, we set up gitolite to initialize its admin repository with your public key.

Copy over your pubkey from your local machine to the git server:

scp ~/.ssh/ git.server:/tmp/

Create gitolite group and gitolite user:

sudo addgroup gitolite
sudo adduser --disabled-password --home /home/gitolite --ingroup gitolite gitolite

Install gitolite:

sudo apt-get -y install gitolite

Append www-data to gitolite group so gitweb can access the repos:

sudo usermod -a -G gitolite www-data

and make sure that groups are updated for apache:

sudo service apache2 restart

Run the gitolite setup:

sudo su - gitolite
gl-setup /tmp/

Setup will allow you to modify gitolite config umask settings so that new repos are given permissions to enable gitweb and git-daemon export:

# change $REPO_UMASK = 0077; to $REPO_UMASK = 0027; # gets you 'rwxr-x---'

If for some reason you weren’t able to edit .gitolite.rc during the gl-setup phase, edit .gitolite.rc and fix permissions so that gitolite group has read access to repositories:

emacs /home/gitolite/.gitolite.rc
# change $REPO_UMASK = 0077; to $REPO_UMASK = 0027; # gets you 'rwxr-x---'
chmod g+r /home/gitolite/projects.list
chmod -R g+rx /home/gitolite/repositories

Exit out of gitolite user session and return to your normal user account:


You should now be able to clone the gitolite-admin.git repository that’s created automatically by the gitolite setup script:

git clone gitolite@git.server:gitolite-admin.git

Edit gitolite.conf to enable gitweb and git-daemon export for testing:

cd gitolite-admin
emacs conf/gitolite.conf
# change to:
repo    testing
      RW+     =   @all
      R       =   daemon
testing "Owner" = "Test repo"
git add conf/gitolite.conf
git commit -m "Enabled gitweb and git-daemon export for testing repo"
git push
cd ..

Setting the repo owner and description automatically gives read access to gitweb so you don’t have to specify it explicitly.

Clone testing and add a file (so it’s not empty):

git clone gitolite@git.server:testing.git
cd testing
git add README
git commit -m "Added README"
git push origin master

gitweb setup

Install gitweb:

sudo apt-get install highlight gitweb

Change the gitweb configuration to use the gitolite repo paths:

sudo emacs /etc/gitweb.conf
# change $projectroot to /home/gitolite/repositories
# change $projects_list to /home/gitolite/projects.list

Now you should be able to see the testing repository in gitweb at:


git-daemon setup

sudo apt-get install git-daemon-run

Now we need to change the sv config for git-daemon so that it runs as the gitdaemon user and gitolite group (since gitolite group has read access to the repositories)

sudo emacs /etc/sv/git-daemon/run


exec 2>&1
echo 'git-daemon starting.'
exec chpst -ugitdaemon \
  "$(git --exec-path)"/git-daemon --verbose --base-path=/var/cache /var/cache/git


IMPORTANT: notice the change from -ugitdaemon to -ugitdaemon:gitolite

exec 2>&1
echo 'git-daemon starting.'
exec chpst -ugitdaemon:gitolite \
  "$(git --exec-path)"/git-daemon --verbose --base-path=/home/gitolite/repositories /home/gitolite/repositories

Restart git-daemon:

sudo sv restart git-daemon

You should now be able to clone the testing repo via the git protocol:

git clone git://git.server/testing.git

Pretty URLs

To enable pretty gitweb urls (http://git.server instead of http://git.server/gitweb/ as explained in;f=gitweb/README):

Open /etc/apache2/conf.d/gitweb:

sudo emacs /etc/apache2/conf.d/gitweb

and comment out everything.

Enable rewrites in apache:

sudo a2enmod rewrite
sudo service apache2 restart

Add a new ‘git’ virtual host:

sudo emacs /etc/apache2/sites-available/git

and add the following:

Enable the new ‘git’ virtual host:

sudo a2ensite git
sudo service apache2 reload

Enable pretty urls in /etc/gitweb.conf:

sudo emacs /etc/gitweb.conf

and add the following:

# Enable PATH_INFO so the server can produce URLs of the
# form:
# This allows for pretty URLs *within* the Git repository, where
# my Apache rewrite rules are not active.
$feature{'pathinfo'}{'default'} = [1];

gitweb extras

To enable other optional features of gitweb, add the following:

$projects_list_description_width = 100;

# Enable blame, pickaxe search, snapshop, search, and grep
# support, but still allow individual projects to turn them off.
# These are features that users can use to interact with your Git trees. They
# consume some CPU whenever a user uses them, so you can turn them off if you
# need to. Note that the 'override' option means that you can override the
# setting on a per-repository basis.
$feature{'blame'}{'default'} = [1];
$feature{'blame'}{'override'} = 1;

$feature{'pickaxe'}{'default'} = [1];
$feature{'pickaxe'}{'override'} = 1;

$feature{'snapshot'}{'default'} = [1];
$feature{'snapshot'}{'override'} = 1;

$feature{'search'}{'default'} = [1];

$feature{'grep'}{'default'} = [1];
$feature{'grep'}{'override'} = 1;

$feature{'show-sizes'}{'default'} = [1];
$feature{'show-sizes'}{'override'} = 1;

$feature{'avatar'}{'default'} = ['gravatar'];
$feature{'avatar'}{'override'} = 1;

$feature{'highlight'}{'default'} = [1];
$feature{'highlight'}{'override'} = 1;

Custom Theme

To add a customized theme (from

sudo mv /usr/share/gitweb/static/gitweb.js /usr/share/gitweb/static/gitweb.js.orig
sudo mv /usr/share/gitweb/static/gitweb.css /usr/share/gitweb/static/gitweb.css.orig
cd /tmp
git clone git://
cd gitweb-theme
sudo cp gitweb.css gitweb.js /usr/share/gitweb/static/

Fix VMware Workstation "VMCI" error in Fusion enabled Bootcamp XP partition

I installed Windows XP using Apple’s Bootcamp and then enabled “Launching your Boot Camp partition in VMware Fusion

Then I installed VMware workstation in Windows XP on the Bootcamp partition.

However, when I tried to set up a new VM, I got this error:

Unable to open kernel device “\.\vmci”: The system cannot find the file specified.

Boo hoo.

Turns out you can fix this by disabling VMCI in the VM config file. 

FIX: Quit VMware Workstation, open up <your virtual machine>.vmx and change the line that reads:

vmci0.present = "TRUE"


vmci0.present = "FALSE"

and then start VMware Workstation again.  You should be able to start the VM.

Anybody have a definitive answer why this works?  Is it because Fusion’s VMware tools installed in Bootcamp don’t play nice with VMCI in Workstation?