/. Large Codebase and Perl

Thanks, /. :-P I'm glad I didn't get into Perl either. Especially with gas costs the way they are now.

Brain-dump: Bzr and Bzr-Explorer with Launchpad account

Since it was more than a couple of weeks ago that I got bzr and Bzr-Explorer working on my old Acer laptop, as usual I forgot the salient steps, and spent the better part of half a day futzing around a new install, trying to get it to let me pull down the latest revisions (bzr pull) of Acire. 

So, here's a brain-dump for (sighh) the next time I have to get a bzr-based setup working with a Launchpad account:

• Bzr needs command-line init before you can go GUI: If you plan to upload code, or to pull/merge/update an existing branch on your computer, the first two bzr commands you should run in your new installation are:
  bzr whoami your_name_and_email_address   
  bzr launchpad-login your_launchpad_username
  where the info in the first command should ideally be your handle and a real email address, and in the second, the username for your Launchpad account.
  While Bzr-Explorer has a Settings > Credentials menu option, that only opens the bzr authentication.conf file in your chosen editor - and before I ran the two bzr commands above, the file simply did not exist. Apparently there's no way (yet) to do this initial config via Bzr-Explorer.
• New SSH key for a new hostname: I'd created my SSH key in Ubuntu 9.04 on my Dell laptop, whose hostname remained the Ubuntu-installer-default primary-username-laptop (in my case, "edgar-laptop"). So when I copied it across to my Karmic install on my Acer lappy, it worked - because once again, I accepted the default 'edgar-laptop' hostname. Duh.
  I was beginning to get a major crick in the neck, typing on the Dell keyboard but looking at the Acer screen, where Synergy was funneling my keystrokes - so I decided to create a Virtualbox VM with Karmic on my Dell, under Ubuntu 9.04. In a fit of appositeness, while installing 9.10 I chose a more relevant hostname - 'vm910'. Yay, me! :-/ Ha!
  I rsynced over a goodly bit of stuff from the Acer laptop into the VM, including apt's package cache (which did save a ton of time and bandwidth), and my SSH keys - forgetting that I had a different hostname in my VM :-(
  Long story short: for several attempts at pulling updates for an existing branch on my HDD, I kept getting public-key-access-denied errors.
  Fix 1: Moved the unusable SSH keys out of the way, generated new ones in the VM. Uploaded the new public key text to my Launchpad account's SSH keys page.
  Result 1: New error message "Agent admits it is unable to sign the request" (or words to that effect).
  Fix 2: Restarting Bzr-Explorer had no effect, I guessed probably it was the GNOME keyring that had the wrong key cached, or was heavily confused. Well, Winduhs-style... just reboot the VM! Heh heh...

This sorted out the issue; I could pull down the latest revision of Acire without issues.

Acire - browse Python code snippets

If you use Ubuntu Karmic, and are a Python programmer, or learning Python, then do check out Acire - it's a sweet way to browse Python snippets, run them, edit them in Acire itself, test again, and then copy the edited code into your project. 

N.B.: To get the latest changes that enable edit-and-run, get a local branch of the project (bzr branch lp:acire) instead of downloading the 0.2 release; my changes to enable this haven't been package-released yet. The 0.3 release, when it comes out, should have these features built in.

See the project announcement by Jono Bacon for background info. Also see his blog for version 0.2, including the need to install dependency packages:
sudo apt-get install python-gtksourceview python-gnomeprint

The same advice as for Acire applies for the snippets - use bzr branch lp:python-snippets instead of installing from the PPA, so you can get the latest contributions. To get Acire to use your branch folder as the snippet store, use the SNIPPETS_DIR environment variable to specify the location:

SNIPPETS_DIR="snippets_dir" path/to/acire

edgar@vm910:~$ SNIPPETS_DIR="launchpad/python-snippets/" launchpad/acire/trunk/bin/acire

Do consider submitting code snippets to the python-snippets project, as Jono requests. 

Ubuntu Karmic in Virtualbox VM failed to resume after Hibernate

Resume from hibernation failed with cryptic error messages in the dmesg log:

[    4.816045] PM: Starting manual resume from disk
[    4.816046] PM: Resume from partition 8:5
[    4.816048] PM: Checking hibernation image.
[    4.816092] PM: Resume from disk failed.

I'd created the VM with an initial 1024 MB of RAM, and accepted the Ubuntu installer's automatic partitioning of the 15 GB VDI I'd created for the VM. Apparently the installer isn't smart enough to consider allotting enough swap space for hibernation while creating the swap partition, because it created a 768 MB swap partition. 

Although I didn't see any log messages about running out of swap space to dump memory image while hibernating, I wondered if this might be the problem. After shutting down the VM, I reduced RAM allocation to 512 MB, and restarted the VM. Hibernation and resume worked fine. I repeated this procedure, bumping the allocated RAM up to 768 MB - still worked.

So, if for some reason you need hibernation working with Ubuntu 9.10 inside your Virtualbox VM, and have taken the auto-partitioning scheme, like I did, this is one point to check.

I also discovered that the Virtualbox Guest Additions go crazy after a hibernate/resume inside the VM; the shared X11 clipboard no longer works (can't copy text in the VM and paste in in the host OS); mouse capture and uncapture reverts to the manual mode instead of automatic capture/uncapture; host CPU utilization for an apparently idle VM hits the roof (keeps one core at 100%). 

This means that Virtualbox's own close-window-and-save-VM-state method of suspending a VM is the best. I wound up poking into the guest OS' suspend and hibernate because Virtualbox failed to resume the VM properly - it just discarded state and booted the VM from scratch, which puzzled me. After I reduced the RAM assigned to the VM, apparently Virtualbox's own save-state seems to have started working as well. At least, a couple of tries succeeded. Also, the save-state and resume-state operations seem to have sped up drastically (but maybe disk cache has something to do with that).

Ah, well - just a small brain-dump for the next time I find a VM save-state and resume fails.

UPDATE 28 Feb 2010: That was NOT the end of it... subsequent attempts to use VBox's save-state again gave me problems, at which point I began some determined Googling because this was really pissing me off. Turns out that VBox 3.1.0 onwards has a new bug, where save-state locations other than the default ~/.VirtualBox/Machines/$VMNAME/Snapshots are ignored when looking for saved state while resuming. I added a confirmation of the problem at the Virtualbox Forums, and confirmed that "if the saved-state file is created in the default location (as mentioned above) then resume from saved state works. If it is created in a custom location, the saved-state file is ignored by VB 3.1.x and the VM is booted from scratch. The saved-state file created in the custom location is left there, and not deleted after switching back to the default Snapshot Folder."