Wednesday, April 2, 2014

Installing git for the pharo-vm - shit just happens

Nothing technical after this long interrupt, just some unoriginal IT experience that we're often exposed to, much too often!

I wanted to feel how good it would be to develop with github, so participating to pharo-vm was an excellent occasion; I first forked it from my github account in the browser, then cloned the pharo-vm repository on my mac:
$ cd /opt/git; git clone --depth=1

In preamble instead of developping directly in Pharo image, I begun the opposite way: I installed filetree in my COG VM development image (Squeak trunk based). First i wanted to test filetree for some time, what a great occasion, and I must report here that installing/using filetree in Squeak is an easy task.

The second reason was for browsing differences between VMMaker.oscog (Eliot's) and VMMaker-oscog (Pharo's) branches.
I'm very productive with the Squeak Monticello merge tool and I rapidly spotted a few easy contributions that I could master. The Pharo 2.0 tool on the other side is good looking but unusable - some features disappeared (apply/revert), failed to appear (browsing diff across history) and it is dead slow as soon as a few hundreds of changes are pending. Pharo 3.0 tools have greatly improved, but not this one, and VM production is still based on 2.0 anyway...

After a good beginning in an almost perfect world, came my mistake: I missread a tip on github help page telling that git >= 1.7.10 was recommended. Mine was 1.7.4, two years old or more... So I decided to upgrade. The github links brought me to release 1.9.0, with a MacOSX installer. Une faute de carre dès la troisième porte qui va dévier ma trajectoire loin des pistes.

Once git 1.9.0 installed, all my git commands suddenly and magically raised an
$ git --version
Illegal Instruction

Thanks! I learned on SO that binaries created from MoutainLion without appropriate compatibility flags could lead to such mess. My fault, I'm on obsolete hardware Core 2 duo macmini, and obsolete OS SnowLeopard 10.6.8. The fact that the installer distribution was stamped SnowLeopard cannot be a guaranty, only buying new hard/soft every year or so is :(. Or is it?

No problem, git is available in source form, so you won't get another penny from me, I like the challenges. I downloaded the source via a svn co (git was broken of course). I choosed the trunk under the assumptions it would be the latest and greatest (the broken or not yet ready features should be in some separate branches, not in the trunk, hey this is git, ain't it?).
Sure, make does not compile as is on my mac, I haven't installed much gnu support, but digging few minutes in the Makefile lead me to the right invocation that would set the install prefix to /usr/local and disbale gettext. Et voilà, time versus money, it's just another couple of hours lost.

After generating the pharo VM (I will explain how in a future post), I begun with fogbugz issue 13154 which I duplicated from Squeak mantis 7247 . It is just 1 method change, an easy start in the image, not that hard in git world either:
$ git branch issue13154
$ git checkout issue13154
$ git add mc
$ git commit -m "Fix issue 13154 alphaSourceBlendBits8"

But when time came to push back my changes to github, here is what happened to me:
$ git push origin issue13154
Username for '': nicolas-cellier-aka-nice
Password for '':
Counting objects: 11, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 1.15 KiB | 0 bytes/s, done.
Total 11 (delta 10), reused 0 (delta 0)

Nothing... it did not complete after 20 minutes...
Hmm, I had ssh configured two years ago, so why not just try that...
$ git remote set-url origin
$ git push origin issue13154
Warning: Permanently added the RSA host key for IP address '' to the list of known hosts.
Counting objects: 11, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 1.15 KiB | 0 bytes/s, done.
Total 11 (delta 10), reused 0 (delta 0)
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly

Unexpectedly... git developers can't be blamed for that, they used the right word.
From this point, I lost the rest of the day digging into git FAQ, SO, internet forae...
Yes, I was correctly recognized
$ ssh -T  Hi nicolas-cellier-aka-nice! You've successfully authenticated, but GitHub does not provide shell access.

No, my repository was not read only, no, increasing the buffer size would not solve anything for me, I only have 1.15 KiB to transmit... 
$ git config http.postBuffer 524288000

An old email from github told me that I should have validated my ssh keys because they found a vulnerability, nice find? No, my keys were validated already.

I even tried insane things like configuring the DMZ of my internet box and disabling my firewall. Pensée magique. No more, no less efficient than lighting a candle and pray...

Maybe installing the native github for Mac GUI in last resort... Neither, OS >= 10.7 is required.

Only a night of sleep drove me to a much simpler solution: on Mac it's often easier to be a dumb consumer. It was time to recognize my defeat, and retreat. I erased every trace of git, used the MacOSX git installer for an older version, and bingo, it worked!

Was it a problem of the svn HEAD revision, or a broken mixture of uncompatible paths and libraries? Who knows...

It's just a good reminder: in IT, be humble, shit just happens!
Also, the silver bullets (if any) are sometimes expensive, even the most mainstream ones...

No comments:

Post a Comment