The Wizard’s Lab

I tried to clone a git repository located on my MacBook Pro today for testing purposes. I tried to access it from a Linux machine right next to it using the ssh scheme – and received a strange error:

bash: git-upload-pack: command not found
fatal: The remote end hung up unexpectedly

This puzzled me a little since both machines have a fairly new version of git installed, so I tried

ssh some.mac.host printev

to find out what is actually in my $PATH:

...
PATH=/Users/johndoe/bin:/usr/bin:/bin:/usr/sbin:/sbin
...

Looks like a vanilla $PATH, missing e.g. /opt/local/bin, where the MacPorts binaries live, which include my installation of git. To make a long story short, it is important to have a working $HOME/.bashrc, probably sourcing your $HOME/.profile:

if [ -f $HOME/.profile ]; then
. $HOME/.profile
fi

The reason for this is, that ssh-shells don’t evaluate your .profile, just your .bashrc, which most of you UNIX gurus know in an instant of course. Well, I keep forgetting that over and over again. If you can think of a more elegant solution, I’d be happy to receive feedback.
What still puzzles me a little: shells which evaluate both, .profile and .bashrc will evaluate the first one twice?

As I mentioned earlier, I recently got involved in amateur radio stuff. While learning for my test, I used the excellent open-source program AFU-Trainer (german version only afaik). The program is written in Qt so it’s pretty much cross-platform, although I had to fix zlib on Mac OSX (Snow Leopard in my case). Because I received some request on how I built it, I decided to write it once instead of mailing (possibly broken) binaries. The version numbers mentioned represent my installation by the time of this writing, you may succeed with something different, but don’t count on it and first of all, don’t blame me

You need:

• Mac OS X 10.6 Snow Leopard
• Xcode 3.2.2
• Qt 4.6

You do:

• Download the source
• Unpack the source
• Inside the source directory, fix the project file (afutrainer.pro) to link against zlib:

  win32 {
      TEMPLATE = vcapp
  } else {
      TEMPLATE = app
      LIBS += -lz
  }

• Create the Xcode project:

  qmake -macx

• Open the newly created project and click on Build

A few final remarks – I put the the external zlib dependency inside the non win32 branch of the project file. The source actually ships with zlib, which is necessary on Windows machines and is probably handled in the win32 branch (I can’t confirm that because I don’t care about win32). On any decent OS, zlib is available system-wide and can be linked against like any library, which is done Makefile-style when using qmake (see above).

… but I was busy afk the last few weeks. One of the nice results ist that I’m now a certified ham radio operator. My current call is DO1NGO (delta oscar one november golf oscar). Since I’m doing some ham stuff right now I decided to start a new wordpress installation (together with DO1NBD and DO2NFS) dedicated to that stuff. It should be available at http://do1ngo.dont-panic.org soon. It’s probably going to be in german though. That’s it for now … vy 73 DO1NGO

I finally found some time to fiddle around with Cocoa again and since I always wondered how these things work, I started looking around a bit. I finally ended up with this excellent screencast. This post was originally a lot longer and still not complete, so I’ll just post the link to have it published. There are minor tweaks concerning the differences on Xcode 3.2 but you are smart people and figure it out yourself.

So I finally decided to gift myself a full iPhone Developer membership for christmas this year. I applied for it about 16 hours ago and already received my “enrollment approval” … which fails because they “can’t verify my identity” … let’s see what happens next. I’ll keep you updated.

Update:

The moment I clicked “Publish”, I received an e-mail from Apple. The issue is resolved. That took less then 2 hours! I’m still not sure what exactly caused the problem, but my guess is the spelling of “Nürnberg” vs. “Nuernberg” (for all you foreigners: this is my hometown and it contains an Umlaut).

Anyway honest thumbs up to Apple!

I recently installed Ruby 1.9 using MacPorts. After finishing the install I found myself presented with a ruby19 binary living in /opt/local/bin (where MacPorts puts most of its stuff) and the same old ruby binary living in /usr/bin. A quick look at the supported variants of ruby19 revealed that it supports nosuffix, which removes the suffix 19 but conflicts with rb-rake and rb-rubygem – wtf!?

Fortunately I stumbled across this post indicating that this is ok, because gem and rake are now part of ruby. Batteries included ftw!

Just stumbled across the following article

http://www.cocoadevcentral.com/articles/000082.php

Didn’t solve my problem but is worth reading imho.

I’ve been fiddling around with some “web application frameworks” lately (I hope this is the correct term) – mostly by accident, because I was looking for a trac replacement at work. During that painful experience I run across redmine, which has e.g. the advantage of not depending on a local(!) svn repository. This was the first time though I dealt with a piece of web-foo which could not be served directly using apache. To be honest, it can be served using plain apache [cgi|fast-cgi] but this is even more painful than using trac. It turned out that mod_proxy is the way to go, connecting to some mongrel backend (when using apache) – but I’m losing the thread here. The point is – while searching for solutions to the above problems, I constantly read something about lighttpd … so I finally got curious …

to be continued …

or maybe not It’s been so long that I forgot what I did myself Sorry *fail*

This is the second time I upgraded my WordPress installation and I almost lost most of my entries again – but I got lucky this time. The key to success is not to change apache’s DocumentRoot while upgrading (i.e. the URL where WordPress will be available after the upgrade). WordPress saves its relative location in the MySQL database which you can’t access anymore. The right sequence is:

1. Upgrade WordPress (until you can log in again)
2. Change WordPress settings: Enter the URL that will be valid after you will have changed DocumentRoot
3. Actually change your apache configuration to match the above changes

This is probably one of the most redundant posting to be found on the web, so I keep it simple …

• Open the tunnel:

  ssh -N -L3306:127.0.0.1:3306 <remote>

• Connect MySQL Administrator to 127.0.0.1:3306

You’re done. No more phpmyadmin, no more forgotten commandline switches