It ain’t always what it’s supposed to be.

Lately I’ve found that I really miss playing music regularly. When I first joined Red Hat in 2008, the plan was for me to move up to New England so I could join most of my coworkers in the Westford office. As a result, I gracefully exited the musical projects I was involved in at the time, so they wouldn’t be hampered by my sudden move. However, a plummeting housing market in the DC area and my mother’s struggles with her spinal problems put the kibosh on my move, and circumstances led to me basically just working from home. That has continued to work out pretty well for both me and Red Hat, so I don’t see it changing any time in the near future.

The unfortunate result, though, is that I haven’t been playing music regularly now for several years. And that gets me right where it hurts — in my work/life balance. Anyone who knows me knows I put a high value on that balance. I’ve been better at achieving it over the past couple of years. But the question I’ve asked myself lately is “to what end?”. Sure, I get to spend more time with my family, but it’s not like we are busy every second of every night or weekend. So the question is, am I doing the best with that non-work time that I could? And the answer to myself was no. I was missing the fun of being creative, and that’s what music does for me.

So I decided to challenge myself to get back into the music scene in the local area. I wouldn’t say that Fredericksburg, Virginia is a bustling music marketplace, but we do have our share of venues and bands. There are some limitations: most of what people are playing around here is bar music, i.e. classic rock, country, and/or blues (or hard metal, which is just not my bag, baby). That means I have to do away somewhat with my predisposition, which is singer/songwriter stuff in the folk/rock/pop genre. Because when you’re playing professionally, you are working in a marketplace, and rule number one is, the customer is always right. And if the customer wants to hear “Gimme Three Steps” for the eight thousandth frickin’ time, then I’m going to do my best to chew it up — dig?

Letting go of my personal feelings about tunes I like (or don’t), though, has been easier to solve than another issue: finding great people to play with. I’ve done auditions for a while now, and I’ve discovered — or maybe rediscovered, since I probably knew this long ago the last time I was auditioning — that auditions are a two-way street. When I show up for an audition with a group, they’re not just seeing whether I’m good for them, I’m determining whether they’re good for me. So far the second half of that equation has been missing. So I’m trying to branch out beyond just answering ads, and try to meet other musicians who maybe aren’t actively looking. It stands to reason that many great musicians in the area are already hooked up with a group, simply because they’re great and everyone knows it.

Fortunately I’ve found there are worthwhile open mic sessions in the area. I’ve never done these before — I found all my previous work through referrals and recommendations, working with a series of steadily excellent musicians. Not being a born extrovert, I also found that I had some trepidation about attending an open mic. What if I didn’t know the tunes? What if no one wanted me on stage? What if none of the other players was any good? Then I realized all these what-if’s were basically killing any positive outcome before it even had a chance. If I went, sure, there was a chance it might not end up having value. But if I didn’t, then there was a 100% chance it wouldn’t have any value. So it’s pretty simple — just go, already!

It’s turned out pretty well so far — I’ve found that there are some truly great musicians around this area. Sure, they may all be in good bands already, but they also tend to know each other, and the way I look at it, if they start to know who I am, they’ll be able to give me or someone else a heads-up for a situation that might be good for me. The open mic is just as much a networking opportunity as a musical one. So by embracing that opportunity my hope is to get more wired into the local scene, make some new friends, and maybe find a referral to play with some great musicians again. I think the key is not just to go, but to keep going. That’s reinvigorated me, so that I’m practicing more on my own again — and it’s helped me shake the rust and dust off.

So today, I’m going out again to an open mic that was fun last Sunday, after which I’m headed off to another audition. And while the other guys are certainly going to audition me, I’m also going to audition them. So don’t just wish me luck — wish them luck too!

Discoveries, no. 577.

This past week I discovered the following awesome things:

• Moving from a 10-year-old DOCSIS 2.0 modem to a DOCSIS 3.0 modem, assuming your cable ISP is remotely in tune with the times, will make your bandwidth better.
• Moving from a 7-year-old (?) Linksys WRT54GL a/b/g wireless router to a new Netgear WNR3500L b/g/n wireless router, assuming you have a laptop with wireless-N, is well worth the investment (and the Netgear is equally hackable with open firmware).
• If you had a stressful day, playing Rancor Rampage on Kinect Star Wars with your kids is a great way to take the edge off.

Ichi-go, ichi-e.

Finding old test packages in Koji.

After I answered a question on the devel list today about getting one’s hands on an old testing package for Fedora that had been obsoleted or removed, Josh Boyer one-upped me by providing some easy instructions. I figured I would tip my fedora to him by building a blog post on his work. Nice one, Josh!

When someone builds an official Fedora package, whether it ultimately gets moved to stable or not, there’s a record for it in Koji, the Fedora package build system. You can use the search bar on the Koji website to find the package or build you’re inerested in. In the resulting page, you’ll find the build is labeled with the git commit from which the build came — it’s the long checksum in the “Task” line.

The package may not be there anymore, but that git label is all you need. It represents the position in the repository history from which the packager built that package. You can find that point in history and re-execute the same steps. You can then clone the package’s git repository, reset the HEAD to the proper commit, and send a scratch build to the Koji builder. Once the build is done, you can download the results.

Caveat: It’s possible that other package changes in Fedora might make a build of that exact point in history difficult later. Be aware this solution isn’t perfect, and you may simply want to find an alternate build in Koji that still exists and suits your purpose, or use the latest updates-testing or stable package instead. But in the hopes people find it useful, here are the commands, assuming the package name is “foobar” on Fedora 16 and the git commit of interest in starts with “0123abcd” (and let’s hope I do better than in the last post in which I gave tips):

su -c 'yum install fedora-packager'
cd /tmp
fedpkg clone foobar
cd foobar
fedpkg switch-branch f16
git reset --hard 0123abcd
fedpkg scratch-build

The URL that comes back to your console is the task for that build, and you can use that to drill down into the individual package build tasks as needed later. Remember, scratch builds are not retained for very long, so if you want the package, try to download it relatively soon after you build it.

Here’s another hint: the git reset command above rewrites your index and your working tree, so essentially you “lose” the later history of the repository. However, git is so awesome that this is not a permanent condition. If you really need to reset the git repository back to its original path, you can use git reflog to find the reference to the checkout you did of the “f16″ branch, and reset to it (probably something like this):

git reset --hard HEAD@{1}

Once again, it’s important to point out that the above is not for the faint of heart. If you don’t understand the ramifications of trying withdrawn, obsolete, or deleted packages on your Fedora machine, or packages intended for testing, don’t use them. That being said, testing packages is a really helpful activity, and there are all sorts of easy ways to keep testing contained on your system, such as using virtual guest machines. So the intrepid needn’t be shy!

Autotitles in screen.

This comes in really handy in ~/.screenrc:

shelltitle '$ |bash'

Then add this in ~/.bashrc:

export PROMPT_COMMAND='[ "$TERM" == "screen" ] && echo -n -e "\033k\033\\"'

Restart screen in a fresh bash session and enjoy.

UPDATE: I stupidly screwed up the screenrc line because I did it from memory instead of copypasta. No cookie for me!

UPDATE #2: Aha, found that something in the innards of my blog software was removing an extra backslash that was needed in the export command above. Sorry for the mess.

Snake for great justice.

I took some time last night to make a couple additional fixes and changes to the irssi-libnotify project I posted about a few days ago.

Among other things, I changed the upstream VCS from Subversion to git, which ended up being pretty simple. I’m much happier keeping the code at Google when I know the entire history resides with me, too. That way, I can move the upstream elsewhere if it becomes necessary. Thankfully, git-svn makes it incredibly easy to migrate, and there’s a helpful wiki page to help with the migration.

I did find that the site docs left out an important part (to me) of the process, which is migrating the authorship information properly. This page was useful to find a quick recipe to use with the SVN log.

For some reason, though, I was still on a hacking (or more precisely, “flailing”) kick. I was happy to have made some fixes to my project, but I’m not a big fan of Perl, so I checked out the current state of irssi-python. This project, as you might expect, provides a Python scripting interface for irssi.

Unfortunately, the project hasn’t kept up with irssi, so it isn’t easy to build. I found a patch for 0.8.15, which applied cleanly and got most of the way there. However, I found for some reason that upstream irssi doesn’t install some of the development header files needed to build irssi-python. I created a patch and a new SRPM that will allow the project to build properly, and also put my work in a git repo with a README file that will help you build it if you’re interested.

Once you install the plugin, you can do the following to experiment so you can build your own scripts:

/load python /py exec import irssi

Have fun!

You can ring my bell.

I’ve been using xchat-gnome on Fedora for quite a while. It’s been my default chat client because the way it notifies about private or channel messages fits well with my workflow. However, recently I’ve wanted more often to encapsulate my chat in a screen session along with my other work. Of course, the obvious answer to this is Irssi, a popular text-based client.

I still tend to also have a web browser open often in a GNOME session, though, so notifications are very useful to me. For a while I used Irssi with a simple plugin script that calls notify-send to create popup notifications. However, I hadn’t used it since the GNOME 2.30-2.32 days, and I found this script had developed drawbacks as it aged against the new GNOME 3 environment.

For example, the notifications would fill up the notification tray over the course of the day. Clearing them required an action for each individual notification, which was tedious to say the least. Also, the --timeout argument to notify-send seemed to no longer work for me to make the notification leave the notice area after a specific length of time.

What I really wanted was a solution that would act more like many of the other native GNOME applications. Appointment notifications or email in Evolution, for instance, “stack” in the notification area into a single icon, with a number that tells you how many notices have been received. Thankfully a few GNOME folks — Marina, Matthias, and Ray — kindly gave me some advice on solutions.

First, there’s a hint called transient for notifications that lets them evaporate from the notification area after a specific time. (You can find the full notification spec here if you want to dig a little deeper; I found it really educational.) This was a step forward because it kept the notices from piling up in the notification area ad infinitum. For instance:

notify-send --hint transient:1 'subject' 'message'

Unfortunately, just using transient meant I’d likely miss some notices if I was away when they came in. I wouldn’t know someone was looking for me unless I switched to my Irssi window to look — which is precisely the thing that notifications should prevent. Nevertheless, it’s a really useful hint, so file that away for later reference.

Never fear though, because again the GNOME folks passed on some good advice. The stacking effect is handled automatically by GNOME Shell if the notifications are issued from the same PID. Aye, there’s the rub! The Irssi plugin I was using made this impossible, because it called the notify-send executable for each message, meaning a new process for each instance. What I really needed was a single process listening on the session D-Bus that could kick off a notification.

So what I came up with can be found here. If you want to just test the listener, maybe because you don’t use Irssi, try this command with the listener running:

dbus-send --session /org/irssi/Irssi org.irssi.Irssi.IrssiNotify string:'subject' string:'message'

The listener is just a dead-simple (or maybe I should say brain-dead, given the quality of code) Python script. I put it in ~/bin with the executable bit set on, added it to my list of applications that launch with my GNOME session using gnome-session-properties, and added the new notify Perl plugin for Irssi to my ~/.irssi/scripts/ folder, with a symlink from ~/.irssi/scripts/autorun/ so it starts whenever I run Irssi. The stacking of notifications makes them very easy to clear with one user action — aaah, much better!

Future thoughts:

• One flaw with this method (I’m sure there are many!) is you’ll get notifications even if you’re actively looking at or talking in the IRC channel where a message comes in. It’s easy to add logic to alter the behavior based on that, but what complicates matters considerably would be trying to make this script understand when Irssi was in the active screen window — or when the screen was the foreground window in GNOME.
• It might not be kosher for me to have used org.irssi.Irssi as a service name in D-Bus. After all, this isn’t official or part of the Irssi project at all. But as I understand it, you could use whatever name you liked, as long as you weren’t trying to claim a service name already in use.
• You could make this work system-wide by packaging a real .service file for D-Bus along with the Irssi script.
• When we were discussing the technical issues above, Ray told me he was actually looking for something similar. With any luck, he’ll find something annoying in my stupid solution he can’t live with, and he’ll add some magic GNOME-ishness to make it awesome. See what I did there?

Manners matters.

I was checking out this fabulous new book called Open Advice after seeing a link on a mailing list. The book is a collection of reflections by experienced (and often well-known) free and open source software contributors on things they wish they’d known when they started in FOSS.

I found a particularly wonderful section among a wealth of other wonderful text. In fact, I probably could have opened the book at random and found something just as quotable and insightful. But this piece struck a sympathetic nerve, probably because one of my pet issues is treating each other with kindness. This excerpt is from the chapter called “Good Manners Matter” by the amazing Rich Bowen, and I’ll reproduce it here, thanks to the author’s and editors’ enlightened use of the CC BY-SA 3.0 license:

I had been doing technical support, particularly on mailing lists, for about two years, when I first started attending technical conferences. Those first few years were a lot of fun. Idiots would come onto a mailing list, and ask a stupid question that a thousand other losers had asked before them. If they had taken even two minutes to just look, they would have found all the places the question had been answered before. But they were too lazy and dumb to do that.

Then I attended a conference, and discovered a few things.

First, I discovered that the people asking these questions were people. They were not merely a block of monospaced black text on a white background. They were individuals. They had kids. They had hobbies. They knew so much more than I did about a whole range of things. I met brilliant people for whom the technology was a tool to accomplish something non-technical. They wanted to share their recipes with other chefs. They wanted to help children in west Africa learn how to read. They were passionate about wine, and wanted to learn more. They were, in short, smarter than I am, and my arrogance was the only thing between them and further success.

When I returned from that first conference, I saw the users mailing list in an entirely different light. These were no longer idiots asking stupid questions. These were people who needed just a little bit of my help so that they could get a task done, but, for the most part, their passions were not technology. Technology was just a tool. So if they did not spend hours reading last year’s mailing list archives, and chose instead to ask the question afresh, that was understandable.

And, surely, if on any given day it is irritating to have to help them, the polite thing to do is to step back and let someone else handle the question, rather than telling them what an imbecile they are. And, too, to remember all of the times I have had to ask the stupid questions.

Well said, Rich. Any of us helping users or newcomers to any endeavor, whether it’s Fedora, some other FOSS project, or a volunteer organization in your town, can learn from Rich’s experience above, assuming that we haven’t already lived it ourselves. Any user can be the contributor of tomorrow. It pays real dividends to extend them a helping hand.

I do highly recommend you check out Open Advice at the website. It’s chock full of insight, anecdotes, and lessons about the powerful, transformational, and exciting journey of free and open source software. The book is a free download, but you can also purchase a copy from Lulu (and, according to the site, from Amazon soon).

FUDCon Blacksburg, days 2-3.

Saturday was the BarCamp session at FUDCon Blacksburg. This year there were workshops scheduled at the same time as BarCamp, which was different than usual. I wasn’t at any of the workshops so I’d be interested to know from those who held them whether they felt this was useful. I do know that most of the BarCamp sessions I attended had good attendance.  The sessions I attended:

• Spot’s talk on making Fedora packaging easier — featured not just what could be a replacement for the current pkgdb, but also a cool new app called Tagger that makes improving package search part of an achievement/trophy oriented game, for maximum  fun
• Katello — a next generation system environment management platform that helps manage content and deployment
• Pam Chestek’s session on the new draft of Fedora trademark guidelines — with extra tweaks to make guidance clearer for publishers, hosting providers, cloud, and spins/remixes
• Chris Tyler’s talk on Raspberry Pi — which was packed! A great update on this affordable ARM hardware for hacking, and what’s needed from the Fedora community to take it to the next level
• OpenShift — Mike McGrath showed off the latest capabilities of OpenShift, a PaaS (platform as a service) offering by Red Hat that makes it dead-simple to for developers to get an entire OS and framework operational in the cloud in just a couple of minutes

Overall, this year’s BarCamp was one of the best in terms of depth of technical content. It also had an excellent spread in terms of technical complexity — meaning there was plenty for new hackers to sink their teeth into, as well as stuff that appealed to more experienced folks. We had the usual assortment of great speakers from all around the community and they all delivered impressive presentations. You should be seeing a lot of these on blogs through the Fedora Planet with downloadable content. (If you delivered a presentation, make sure you make it available widely!)

Saturday evening was the world-famous FUDPub. I was only around for a little while — since I was still trying to shake off the illness that had been dogging me since the middle of the week, I didn’t want to make things worse on my immune system by celebrating too much. Plus, it started to snow while we were enjoying the food, drink, bowling, and billiards, so I wanted to move my car back to the hotel before the roads got too dangerous. (Virginia is not known for its rapid and rational response to adverse weather conditions.) Later in the evening we gathered for poker at the “mezzanine” level of the hotel’s conference center. A few people played well into the wee hours but I headed to bed about 1:00am.

Unfortunately, the medication I took caused me to oversleep a bit, but I still managed to get over to day 3 of FUDCon by 9:00am. Once there, I got together with Peter Borsa, Pascal Calarco, and Maria ‘tatica’ Leandro to talk Insight, our Drupal installation, which the team is trying to branch out into new and useful functions. Jared Smith and Robyn Bergeron also stopped by to give some input on our calendar project. We took notes throughout the session on Gobby, and will post them on the wiki shortly along with some additional context and plans. I feel like the Insight project is starting to take on a little more life, with a designer involved and some solid ideas about functionality that will help the project.

For instance, we discussed the events calendar being able to automatically notify event owners or FAmSCo about milestones or other necessary activity, to promote better communication and awareness. A content management system makes it possible to build some fairly robust workflows around information — making the system not just another place to deposit information, but a facilitator in the process. The team has yet to figure out exactly how this should look but thankfully Maria is on the case and will help figure this out over the next few weeks. My day job is making it harder for me to lead this team, but the other members are committed to working on some exciting new features, and I’ll continue to find ways to contribute, and wherever possible remove roadblocks and continue to scale out access, privileges, and empowerment to the rest of the team.

By this time, it was close to noon. I started saying goodbyes to various people, and made sure I had picked up as many riders as I could to drop off at the airport on the way out. I ended up taking Máirín Duffy to the airport, as well as Jared’s son with me (since they live within a half hour of me). It was good to finally get home at about dinnertime. My daughter was hosting a sleepover with a friend so it was pretty boisterous at our house, but nice to see my family again.

All in all, it was a great FUDCon. I could have done without the illness the first few days, but I managed to pull through, doing a good portion of what I intended at the event. To everyone who was there, I hope you had a fantastic time and were able to really use the event as a jumpstart for collaborations of your own. Now, make sure you spread the word on what you’re doing, and carry some of that energy and ingenuity into our discussion lists and other venues! I hope everyone has or had safe travels home and we’ll see each other soon online.

FUDCon Blacksburg, Day 1.

Yesterday was a hackfest/workshop day at FUDCon Blacksburg. I spent a little time listening in on secondary arch work going on around Fedora. It sounds like there is a lot of effort going into keeping secondary arches rolling really smoothly through Fedora 17 and beyond. There were some folks from IBM and Red Hat in attendance as well as other interested community members. This workshop went most of the day, but I wasn’t able to attend the whole thing.

I had to prep a short deck for my workshop on Drupal internals, which I managed after lunch. The idea behind this session was to start walking through internals of Drupal modules and the Drupal API. The goal was to convince the attendees that not only is Drupal fairly easy to customize, but you don’t have to be too skilled to start writing a Drupal module.

To reach that goal, we walked through a fairly simple module I wrote that allows Fedora Insight to authenticate users and map roles via the Fedora Account System (FAS). he great thing about the workshop was there were a couple of Drupal professionals in attendance! So as a bonus I got some excellent suggestions about my module as we went through it.

Isn’t that what open source is supposed to be about? Yes, Dear Readers, it is — more eyes on my code, live in a session, meant a bunch of shallower bugs for me to fix. So, needless to say, the workshop went quite well.

I visited the “Try My Keyboard” workshop that Toshio set up, along with the Das Keyboard Silent Professional that I use at home. I tried several there, and one of them was a model based on Cherry MX Blues (like the non-silent Das Keyboard I considered) I really liked. It was fun to try out each unit in a really discriminating way and compare feel in terms of stroke, feedback, and effort.

I then attended the Board session which was a review of 2011 and how to move from the level of very high-level strategic goals to actually fixing some problems in Fedora and improving life for contributors. The consensus seemed to be that the Board members will champion specific fixes themselves — by contributing directly to the solutions. In other words, they’ll roll up their sleeves and get involved, which is always an approach that works well in a community like Fedora.

The only suggestion I offered, which I hope the Board will take to heart, is that as they think about what they want to accomplish for 2012, they should consider how they will know their fix works (measure it in some way). The Board is made up of fantastic individuals and I’m sure they will come up with worthwhile initiatives and bring their formidable skills to bear on helping the community work through them as a team. We’ll be hearing more about this at the beginning of February from what I understand.

Finally, I got together with Red Hat trademark attorney (and my buddy) Pam Chestek, Spot, Jared, and Ian Weller to go through the Fedora trademark guidelines with a fine toothed comb in advance of the session to cover those revisions on Saturday. We were able to tease out a lot of additional bug fixes and extra clarity and it was time well spent.

Unfortunately, by the time we finished, around 7:45pm, I was starting to feel pretty low. I’d been teetering on the edge of a cold (or some sort of bug) for a few days, but I actually became a bit feverish in the evening — feeling cold in rooms that were clearly not, even when I dressed too warmly, and so forth. But there was more to do; no rest for the wicked as they say.

I caught a quick but tasty dinner with Pam, and we enjoyed discussing the adventure of buying a car. I’m sure I was not as chipper as usual and hopefully wasn’t bad company — sorry if I flagged a little, Pam! After that I met briefly with Spot and Robyn to go over logistics for the next morning’s BarCamp and keynote activities. Robyn, being the saint she is, brought me a couple doses of NyQuil. So immediately after that, I headed to my room to burrow under covers and try and sleep off the fever.

Unfortunately, that meant I missed the Fedora Insight hacking I’d suggested for Friday night with Peter Borsa and Pascal Calarco. It was awful to feel so sick I couldn’t take advantage of having a wonderful team of collaborators in one place — especially since Peter was here from overseas. (Fortunately they generously forgave me!) Thankfully, though, I got a full night’s sleep and in the morning I felt better than I had in a couple days, so I could be up early and help get ready for BarCamp.

I’ll post more about the BarCamp and Day 2 tonight or tomorrow!