After using this combination for a while (running ‘offlineimap’ in ‘screen’, with ‘mutt’ running in one or more ‘screen’ windows), I ran in to some problems with ‘offlineimap’ when it was run continuously.  I could set the sync interval in the configuration just fine, but inevitably a few things happened.  It would be syncing, using CPU, memory, and bandwidth when I had other ideas for how to use those resources.  It would be in between a scheduled sync when I wanted to check for an email just sent, causing me to quit and restart it.  It would occasionally suck up all my memory, requiring a kill and restart (that was probably an older, buggier version?)  It also didn’t like it if I suspended the laptop or lost network during a sync, which seemed to be the main trigger for the memory-sucking-error.

Finally, Paul suggested to me that I try just running it manually when I wanted to get my email.  This was part of a larger discussion on how to not let email run your life.  If you know the email is constantly being refreshed, it’s easy to “just go see if there is something new”, thereby procrastinating on what you are really supposed to be doing.  By making mail poll/sync a manual task, I could eliminate most of the first problems, and fresh messages were always just moments away.  (If I’m anxious to get an email NOW, I’m usually interested in the main inbox, since my email is filtered server-side.)

All that leads me to this very simple ‘bash’ script that runs ‘offlineimap’ one time, and before exiting puts a nice visible timestamp on the console for me.  I find this really helpful to let me know when I last ran ‘offlineimap’.  Sometimes it shows me it’s only been twenty minutes, and my checking email is a sign to me that I am procrastinating.  Other times it shows me that I haven’t checked since last night!

#!/bin/bash
/usr/bin/offlineimap -o;
echo "****************************"
echo "vvvvvvvvvvvvvvvvvvvvvvvvvvvv"
/bin/date
echo "^^^^^^^^^^^^^^^^^^^^^^^^^^^^"
echo "****************************"

That is such a simple script that I don’t think it warrants copyright, but just in case I am wrong, consider it under the GPL v3+ (yes, I trust the FSF with improvements to the GPL more than I trust that GPL v3 is so perfect that it never needs improving.)

For ‘mutt’ goodness, check out Paul’s configuration directory for his ‘mutt’ wrapper script (which I use), as well as his ‘mutt’ and ‘offlineimap’ configuration files (which I also modified to use.)  You might notice that Paul has contributed a ton more to my ‘offlineimap’/'mutt’ experience than the reverse, but I try.

The below how-to information is copied directly from http://fedoraproject.org/wiki/How_to_install_Moblin, and is used here thanks to the CC BY SA 3.0 Unported it is licensed under:

Moblin is a lightweight Linux desktop environment especially suited for small form computers (netbooks et al).

Installation is straightforward.

Using the command line

1. Open a terminal (shell).
2. Install the Moblin group: su -c 'yum install @moblin-desktop'

Using the graphical package manager

1. Go to System > Administration > Add/Remove Software.
   • Note: the name of the Add/Remove Software application is PackageKit.
2. In the left side pane choose Moblin desktop.
3. Click Apply to install the package set.

This Wednesday I was helping Mel with the POSSE class in Singapore.  Basically, I covered what open source content in Fedora does (technical docs, process docs, community self-knowledge docs), the common tools and styles we try to propagate, and then walked the class through how to contribute to the release notes.  The exercise was focused on editing to the wiki.  I explained the rest of the process in the abstract with lots of links (scroll down for the sections “4. Documentation” and “5. Activity: become a release notes writer”.)

The process was made easier when one of the teacher-students noticed that a desktop environment he enjoys, LXDE, didn’t have any noted changes in the release notes source on the wiki.  Suddenly there was a clear reason to edit the wiki derived from their personal interests beyond just learning.  This is what we call the, “Ah, ha!” moment.  Now they knew i) why to bother contributing to the release notes, and ii) how easy it is.

The class were all instructors in polytechnical or business schools in APAC – Singapore, Shangai, and so forth. Ideally, they take back the “how to be an active contributor in an open source community” training to their classes.  Even better, if they do classes where part of the student work is being active in FLOSS communities.

You may find the IRC log interesting, but Mel did a good job capturing the basics in that screencast.  It is useful for showing to anyone who drops by #fedora-docs.  We’ll try to get an OGG version to grab from somewhere so we can have it in the /topic on #fedora-docs.

1. Rip out whatever logic you have in ~/.bashrc for displaying the git branch at your command prompt.
2. Copy the script supplied by the git package to where you can make it an executable, such as ~/bin :
   • cp /etc/bash_completion.d/git ~/bin/git-completion.sh
3. Make the script executable :
   • chmod 700 ~/bin/git-completion.sh
4. Add these two lines to ~/.bashrc :
   • source ~/bin/git-completion.sh
   • export PS1=”[\u@\h \W"'$(__git_ps1 " (%s)")'"]\$ “
5. Reload your bashrc file :
   • . ~/bashrc

Enjoy having a peek at where you are in your git directory:

[kwade@calliope lookatgit (debug)]$ git branch
* debug
  help
  master
[kwade@calliope lookatgit (debug)]$

The signs are a small brilliancy that came from (I think) the mind of Clint Savage (herlo).  It’s a good example of a smaller thing that was relatively easy to execute making a memorable conference experience.

As I walked up to the MIT building with Xavier, we spotted the same signs in the glass stairwell, clearly illuminating the presence of FUDCon

Standing out in a window, the signs are 28 cm (11 in) by 43 cm (17 in), with a blue Fedora logo centered.  Clint and whoever helped him applied small pieces of clear double-sided tape to the four corners of the face of the sign.  You apply it facing outward to your hotel window.  Where it really helps is when you and a group of people are sharing a hotel.  We have a large number at this same hotel, I don’t know how many but more than 30 I can reckon from what I’ve seen.  The work was all done at a name-brand full-service print-shop.

I’m not sure if there is a page of similar tricks for Ambassadors.  Sadly, the Ambassador wiki pages are many with categorization and old-style page naming working against it.  At least, my search for ‘ambassador tricks’ turned up nothing. (Hoping some folks who want to learn how to do that effectively come to the wiki talk today.)

So I created these pages, and hope someone else is sparked by Clint’s idea to make a similar impact at one of your events.  Don’t forget to share and document your experience:

https://fedoraproject.org/wiki/Tricks_for_Ambassadors_from_Ambassadors

https://fedoraproject.org/wiki/Category:Ambassador_tips_and_tricks

Sure, it’s cool to work entirely offline, do granular commits, and merge perfectly with the codebase when I’ve reconnected later. That’s all good. What has been a real gift from the gods the last 48 hours is how fast it is. Especially the operations via the network; I see very little bandwidth used and it goes by very quickly. No more ‘cvs ci’ and wait.

Another great aspect is how a DVCS such as git supports a distributed team working in real and non-real time. Unlike with old VCS, it is much easier to work divergently and still have it merge together. For example, after I do a number of changes, I make granular commits, which occur only in my local repo (clone.) I can do a commit per file, so I have a specific changelog tied to the actions, and it is easier to undo or manipulate from that commit, which has it’s own UUID. Then I only have to run ‘git-pull –rebase’, which pulls down any changes pushed by other collaborators, updates my local repo, and replays my changes on top of this new copy of HEAD. Then I can ‘git push’ without any conflicts arising.

In a VCS, if you find yourself out of sync with the latest from HEAD, you either have to sync and deal with potentially spurious merge errors, or do a manual version of what git does. How many times have you copied your changes from out of a Subversion or CVS directory locally, reverted back to HEAD from the central repository, then manually reapplied your changes?

If anyone is making them … I want a t-shirt that says “praise git”.

Naturally I said, “I can take care of that,” and I woke my machine from sleep while getting out a USB flash drive. Unfortunately, in packing, the extended battery had moved a bit and the machine was powered down. I booted, where I faced the usual sight of Compiz (aka “Desktop Effects”) not started, except this time it won’t start manually.  Not wanting to waste their time (or mine), I switched to a virtual console. I could get them the live USB of Fedora 9 Preview in a few seconds that way, too, straight from memory without referring to the Fedora Live USB How To.

Plugged in the USB drive and typed:

sudo livecd-iso-to-disk /home/iso/Fedora-9-Preview-i686-Live.iso /dev/sda1

The copy started, and we commented on how fast it was going. But after it reached a small percentage, it complained the disk was full. That seemed odd, but I figured I would reboot and see if it worked; maybe the media was bad?

OK, some of you have figured it out already. Can you guess what happened when I rebooted?

I got told “No operating system.” Hmm, guess the live USB didn’t take, right? No, reboot again and see what happened. No operating system found for the laptop itself.

Oh! The USB key first partition was /dev/sdb1. My laptop’s hard drive /boot partition, that was the one on /dev/sda1. That was the one I filled up. At the same time, the MBR must have been overwritten, so GRUB wouldn’t boot.

Naturally, I had no rescue media on me and couldn’t recover quickly and get these gentlemen on their way. I had to send them off disappointed, and myself home, speeding down the peninsula, with a thrashed MBR.

Lesson? Well, sure, be careful. But we are telling people it is so easy to make these Live USB keys, yet … if they get one letter incorrect in the wrong direction, they hose their system and ability to recover easily when they do reboot. It’s a hidden problem, too; it could be weeks until they reboot and have no recollection of the chain of events.

Not sure where to focus for a fix. Is it in using the sd* namespace? Having all media be in such a similar path is a bit scary, since some media is treated destructively (CD and DVD writables, flash media) where others are not.

We certainly need to educate people who are going to be making these drives to very carefully check what the device path is for their mounted media before proceeding. We don’t typically direct normal users to do things so close to their /boot, or, well, any other partition. The fact that this happened to me, a fairly experienced Linux sysadmin, could either be a clear case of PEBCAK and moving too fast, or it could be a sign of warning about spreading these tools to people.

Perhaps I should make a feature request of livecd-tools to do a check that the partition about to be written to doesn’t happen to have a system label, such as /boot or /home.

Doing this fsck was a bit needlessly complicated, especially as it was not at all like what I’ve done before nor what the boot shell recommended, which was to run fsck without -a or -p. I couldn’t find enough pieces to figure it out from Google. I eventually got pretty far but was stuck in something weird that Red Hat’s helpdesk helped me figure out. Note that world — Red Hat has a helpdesk that actually helps people.

Skipping all the false pathways I took, here are the steps that worked:

1. You need a better environment than the Fedora 8 rescue CD. The rescue CD does not have the kernel modules to handle the LUKS decryption. I used an F8 live CD.  (This sounds like it’s fixed in the rescue mode currently in rawhide.)
2. Decrypt the partition at the command line, for example: cryptsetup openLuks /dev/mapper/ VolGroup00-LogVol02 home
   • Note that you have given the name of ‘home’ to the decrypted partition; a name is required by cryptsetup
   • The unlocked volume is now /dev/mapper/home
3. Run fsck on the unlocked volume: fsck.ext3 /dev/mapper/home

Ah, three simple steps … that took more than 3 hours to figure out. But all is good now.

;;; First version; has bugs!
(defun count-words-region (beginning end)
  "Print number of words in the region.
Words are defined as at least one word-constituent
character followed by at least one character that
is not a word-constituent.  The buffer's syntax
table determines which characters these are."
  (interactive "r")
  (message "Counting words in region ... ")

;;; 1. Set up appropriate conditions.
  (save-excursion
    (goto-char beginning)
    (let ((count 0))

;;; 2. Run the while loop.
      (while (< (point) end)
        (re-search-forward "\\w+\\W*")
        (setq count (1+ count)))

;;; 3. Send a message to the user.
      (cond ((zerop count)
             (message
              "The region does NOT have any words."))
            ((= 1 count)
             (message
              "The region has 1 word."))
            (t
             (message
              "The region has %d words." count))))))

Do a quick byte-compile-file to make your ~/.emacs.elc file, restart Emacs, you are ready to count.