Sunday, May 29, 2011

Frustrated with migrating to Rails 3...

One of the biggest frustrations with mixing dependency management and packaging in Linux is when an upgrade to one forces an upgrade to the other. Or more specifically, when upgrading to a more recent release of Fedora forces an upgrade to the version of Rails installed.

With Fedora 14 we had Rails 2.3.8. Now, with Fedora 15, we have Rails 3.0.5. And, sadly, it's not a simple task to just upgrade a Rails app since quite a bit has changed between 2.3 and 3.0. Enough that it almost feels like it would make more sense to just start over the project by creating a new Rails app and then moving the existing controllers, models, etc. over to the new app.

But that just sounds like a copout. There has to be a way to easily migrate from 2.3 to 3.0.

So guess what I'm doing this weekend?

Wednesday, May 25, 2011

Fedora 15, Gnome 3 and closing your laptop's lid...

I upgraded my system today from Fedora 14 to 15 using the preupgrade tool. Everything went VERY smoothly. My nVidia card (Quadro FX 880M) is completely supported with full hardware acceleration, which is awesome!

But the first thing I noticed once I booted into Gnome 3 was that, when I closed my laptop lid, the system went into suspend mode. Not what I want to have happen: unless I'm on battery, I want the system to just blank the screen when I close the lid.

I went into power settings and could not find a setting for what to do when the lid is closed. Something that was very easy to find in past, but now is not obvious.

So a quick google search turned up this solution:

To set the action when the laptop lid is closed, simply enter the following commandline:

gsettings set org.gnome.settings-daemon.plugins.power lid-close-MODE-action “ACTION

where you replace MODE with either ac or battery depending on which mode you're setting, and replace ACTION with blank, suspend, hibernate or shutdown.

Friday, May 20, 2011

Migrating a Subversion repository to Git...

For years now I've been using Subversion to maintain history on a lot of documents for me (my resume, my writings, various configuration files for mutt and offlineimap, etc...).

I love Git, though.

So I decided to migrate my Subversion repo to Git. And I wanted to keep all of my history. And I leaned heavily on John Albin's work to do it.

Step 1: Map Subversion users to Git users.

The key goal here is to keep the history intact, which includes the names used (though in this case it's always me, but it's the principle, right?). To do that I created a text file that maps the Subversion account to an email account.

svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > users.txt

Now edit this file, which looks like:

mcpierce = mcpierce

and change it like this:

mcpierce = Darryl L. Pierce

Step 2: Clone the Subversion repo using Git.

This step is the crucial one, since it's here that we'll take all of that history out of Subversion and put it into a brand new Git repository.

Well, WE won't. Git will.

git svn clone [my Subversion repository] -A users.txt ~/temp

This took a while since it's going to migrate that history into the new repository. But, when it completes, you should be able to go to the repository and see all of that history.


cd ~/temp
git log

commit 50f06a699973bcd954fb1e61dc50deafee6a085f
Author: Darryl L. Pierce
Date: Fri May 20 14:13:43 2011 +0000

Updated my email configurations for home and work.

offlineimap can pull both work and home email down.

esmtp can send both work and home email.


git-svn-id: https://mcpierce.dyndns.org/repos/home/personal@659 7533b618-34f6-46d8-b546-5fbeb33e39a2

commit 00fb86a7314ec754108e0931d59a30464dce8510
Author: Darryl L. Pierce
Date: Thu May 19 19:47:59 2011 +0000
...


and you should see all of the commit author's names properly mapped over.

Step 3: Create the new remote Git repo and push the content

This step I'm not going to describe in a lot of detail. Specifically, I'm not going to tell you how to create a remote repository and access it. Instead, that's an exercise for you.

But, one you've created that remote repo and can access it, simple go to your new local repo and add that remote one and push your changes:

cd ~/temp
git remote add home [the remote git repository]
git fetch home
git push home HEAD:master


Now your Subversion repository history is in that remote repository.

Tuesday, May 3, 2011

Getting Picasa To Work On Fedora 14 (x86_64)

My cubemate, Mike, just came back from a two week European vacation and work trip. He was showing me photos from Vienna and Brno on his laptop using Google's Picasa photo library. I also keep my photos on Picasa but use our home Windows 7 machine to do the synching just out of habit.

But after seeing his pictures I decided to install Google's Picasa Linux build on my laptop running Fedora 14 64bit.

The first issue I had was with the only version available being 32bit. I'm not sure why software companies are still pushing only 32bit versions when 64bit is available and growing in adoption. But that's another story.

So after downloading and install the Picasa RPM (available here) the software didn't start but had some errors:

(mcpierce@mcpierce-laptop:~)$ picasa
/usr/bin/picasa: line 139: 12417 Segmentation fault      (core dumped) "$PIC_BINDIR"/wrapper check_dir.exe.so
/usr/bin/picasa: line 175: 12528 Segmentation fault      (core dumped) "$PIC_BINDIR/wrapper" regedit /E $registry_export HKEY_USERS\\S-1-5-4\\Software\\Google\\Picasa\\Picasa2\\Preferences\\

So, obviously, out of the box this doesn't work. The build for Linux is actually the Windows build packaged up with Wine to run on Linux rather than a native build. So to solve the loading issues I had to dirty my nice 64bit environment by installing a series of 32bit packages and then copy some of those files over into the Picasa install location:

[root@mcpierce-laptop ~]# cp /usr/bin/wine-preloader /opt/google/picasa/3.0/wine/bin/wine-preloader
cp: overwrite `/opt/google/picasa/3.0/wine/bin/wine-preloader'? y

This fixes the segmentation faults that popped up initially and allows Picasa to actually finish loading under Wine.

The next problem is that the Wine implementation Picasa installs was unable to access the internet so that I could download my existing albums from Picasa. To fix that I had to replace the wininet.dll.so file that Picasa installed.

[root@mcpierce-laptop ~]# cp /usr/lib/wine/wininet.dll.so /opt/google/picasa/3.0/wine/lib/wine/wininet.dll.so
cp: overwrite `/opt/google/picasa/3.0/wine/lib/wine/wininet.dll.so'? y

Once that was done then Picasa was able to login as me and synch my web albums to my laptop.

So now I can keep my pictures on my Linux laptop. One less reason to have a Windows machine at home.

But, still I have one more thing to say:

HEY! GOOGLE! How about a NATIVE LINUX VERSION of Picasa? If you support free and open source software then indulge us with an open source copy of your free tool!