Category Archives: Fedora

Things I write for Planet FedoraProject consumption

Upcoming travel.

It’s going to be a busy couple of weeks for me. I’m leaving tomorrow to attend and speak at EXPOSOL in Costa Rica. I’ll be discussing cultivation of cummunities and how companies and communities can learn to work together for the benefit of both. I’ve never been to CR before and I hear it’s beautiful. Only problem is I have but two days to be there before I head back to the USA!

Next week I’ll be going to the Red Hat Summit in Boston, where I’ll be working as a volunteer staff member. Unfortunately this year I won’t be hanging out at the Fedora booth nonstop, although I’m certain I’ll be by from time to time.

Instead, I’ll be working at the information desk, helping to marshal at session rooms, and stuffing bags at our “Red Hat gives back” charity area, where we’re donating time and effort to Crayons to Cradles. I’m really looking forward to that one. The Summit is always a fantastic event, but I think putting a charitable drive in the middle of the proceedings is a great way to show people that they really can make a difference, whether it’s in open source or not.

You can still register for the Summit — it is always an incredible value, packed with learning, fun, and the ability to engage directly with engineers and open source luminaries. This will be my sixth Summit (I’ve been to every event since the second one in Nashville) and I always look forward to them. See you there!

SELF pimping.

Once again this year I’ll be traveling down to the Southeast Linux Fest for a weekend full of informative talks, social fun, and exceptional collaboration opportunities with fellow Linux geeks from around the region and the nation. SELF has been an enormous hit since its inaugural outing in 2009. I’ll be joined by fabulous people from across the Fedora friendsphere, and of course there will be lots of free goodies at the Fedora booth for everyone. I hear tell of a tasty grilling event that will honor our favorite meaty champion of free software, and I expect to catch up with wonderful friends from all around the open source world.

My presentation on Friday is going to be on PyGObject, making the transition from PyGTK to the new world of introspection awesomeness, and what that means to people who do programming as a hobby and not for their bread and butter. I promise to keep things down to earth and accessible by newbies and hopefully not make those of higher skill levels cringe often. Except for bad jokes, those are pretty much a given, as those of you who’ve been to some of my other talks can attest.

By the time you read this, or shortly thereafter, the SELF schedule should be appearing on the web site, and you can see for yourself how valuable a trip to the conference can be. Linux community events like SELF are booming in popularity because they feature great speakers, invaluable learning opportunities, and fantastic social networking outlets for a pittance.

A big thank you to my employer, Red Hat, for giving me the time and funding to make it to the event, as well as being a Platinum sponsor of SELF 2011. (By the way, Linode, a Diamond sponsor this year, is where I run this blog… Did I mention how happy I am with their service?)

But no matter how many sponsors there are, it takes a lot of fine people dedicating a huge amount of time, expertise, and effort to put on any community event like SELF. That this event has become so popular so quickly shows not only that SELF is filling a necessary gap in the Southeast region of the US, but that it’s done so with style, ambition, and the sure, guiding hand of great volunteers. Hats off to you guys and best of luck for another incredible event at SELF 2011!

UPDATE: Unfortunately, previously mentioned grilling event was contingent upon Our Meaty Champion becoming the Fedora 16 namesake. So, no dice. But there may yet be hope for a related outing, stay tuned while at SELF. ūüôā

Truer words, no. 54.

Good article by my buddy John Poelstra with which I vehemently agree. I’ve been doing something similar with email for a couple years now using offlineimap, synchronizing a few times a day rather than keeping an app open all day or making myself the slave of instant notifications about new email. It’s made a huge difference in my productivity. I’m not perfectly disciplined about this, but more often than not these days, I tend to ask myself before syncing my email, “Is there something coming that you need in order to make progress on your most important task right now?” Often the answer is no.

Sometimes I might be tempted to pull email out of habit, or because I need a break from my current task, or because I’m procrastinating. In all these cases there are better remedies available. Habits can be an indicator of not thinking through what you’re doing, and I’m trying to get better at that in general — so breaking this habit is something I work at constantly. If I need a break, I try to just switch tasks instead, or in the case of overall fatigue, I leave my office for a few minutes to get some perspective. Sometimes a short walk or playing with the family dog lets me come back refreshed and ready to focus. Procrastinating is a special problem that I just try to meet head on, although again I’m not the epitome of doing that well.

Email and communication are vitally important in my job, but they are not the only important thing I need to do in my job. It’s important to keep your tools in perspective and remember that the thing that makes you valuable to your employer is not just your ability to communicate — it’s the ability to communicate something worthwhile. And communicating something worthwhile often requires you to be able to focus and think clearly without yielding to the distraction of your communication tools.

Who’s up late polishing the blade.

My blogging mojo has been lackluster of late, but that’s because work has been so terribly busy lately. Over the last couple of weeks I’ve been working on putting together a departmental team presentation for the upcoming Red Hat Summit. Wrangling a multi-presenter session isn’t easy and I have a lot of respect for people who are able to do it well.

Lately I’ve been spending a lot of quality time with Inkscape to get the slides into something resembling a coherent theme. In the process I’ve learned a few tricks such as as the optional switches for scaling elements, which let you decide whether or not to also scale properties (such as their gradients or the rounding of corners on rectangles). If I sat around for a few hours with Inkscape just playing around, I don’t think I would have discovered nearly as much. Having a concrete goal — in this case, completing a specific diagram for a specific purpose — really has helped me focus on what I needed to get the job done.

But it hasn’t all been bullet-wrangling and drawing. Plenty of other work all has to keep going on in the meantime. For instance, next week I’m headed to Westford for some meetings in the office, first time back since right before Thanksgiving of last year (jeez, how time flies). Then back home for a week, then the next week I’ll be traveling to Costa Rica to speak at a conference, followed by a short couple of days home and then the Red Hat Summit in Boston.

I’ll also definitely be attending the upcoming Southeast Linux Fest 2011, and I couldn’t be more thrilled. I love that particular conference and have been at both previous years. I expect this one will be just as incredible. If you are in the southeast region of the USA, you really should make it¬† a point to attend. It’s very inexpensive, and a great way to learn and soak up all the goodness of the free software community from luminaries living almost in your back yard. Come join the fun June 10-12!

I’ve been working with the Fedora Insight team as well. We’re working out some cosmetic changes that will make the site a little easier to navigate as we add further features. We’re also planning some next phase deliverables and as always invite comment, but especially assistance. One of my recent proposals to the team was a change process that will help us manage site development in a collaborative but careful way. I also put up some additional Drupal module packages for review here:

I also did my part by finishing up the review for Drupal 7, which is in updates-testing now for Fedora 15 and EPEL. Andrea Veri is securing a development host that we can break as needed while we get new features working on Insight. And Robyn Bergeron is working on a SOP that will show Marketing team participants how to promote selected Planet posts for the feed on Insight.

It’s a very exciting (and exhausting) time right now with so much going on, and it’s been a lot of working weekends to try and stay caught up, but the results make me happy. I’ll try to get more and shorter updates coming to this blog over the next month. And I am going to get back to work on PulseCaster as well, as soon as time allows.

A fun day… for some hacking.

Over the course of the day, I:

  • Tweaked the package complement on my workstation where last night I did an installation of the Fedora 15 pre-release tree
  • Identified some weirdness in my local Eclipse environment and got things in better shape for later work
  • Got a good start on some user documentation for PulseCaster
  • Took my daughter to the skate rink, and managed to skate for at least a little while before realizing I was having a rough time because my kingpin bolts are just way too freakin’ tight
  • Figured out how to adjust said kingpin bolts and made a note to take care of that before next week
  • Took my son out for some errands and lunch — a nice trip and a good chance to exercise my patience muscles
  • As a reward, bought some beer and a couple decent malbecs
  • After returning home, cleared out some obsolete packages hanging around in Bodhi and begging for death
  • Built and pushed a new update of PulseCaster to fix some bugs
  • Built and pushed a refreshed upstream version of xmlstarlet
  • Played with the dog
  • Came back and turned up a French trance station I got into recently (for some reason, monotonous, non-vocal electronica seems to help me work more efficiently… probably since there are few lyrics to listen to and digest mentally)
  • Went through some email to reduce backlog for Monday
  • Triaged a crummy gnome-system-monitor bug affecting people with more than 4 CPU cores (like me)
  • Had dinner with the family (Eleya made a fabulous corned beef, first timer but it was pretty much perfect!)
  • Came back to the desk to find that the superhuman Matthias Clasen had fixed the gnome-system-monitor bug in question, and built and pushed an update out
  • Installed said update with many thanks to Matthias, tested, and provided feedback

So of course, my definition of hacking is not nearly what some of my colleagues manage daily. But I feel like attacking some of this stuff on weekends and working on my own GNOME-ish projects are starting to give me a better fundamental understanding of some of the plumbing at work in the desktop. And of course, it gives me a wh0le new appreciation for it as well. I’m now rocking GNOME 3.0 pre-releases on both my main systems here at home, my laptop and my big workstation, and loving it.

I’ve contributed a few bug reports and to a small portion of the GNOME 3.0 user documentation for this release. It was lots of fun and made me feel connected with the release process for something I use every day that will be an intrinsic part of Fedora 15 when it arrives. It’s a great feeling to be just cranking on some little bits to help others, and just as much as ever, I know that if everyone does the same, free software has a future that is even brighter than the (already well-lit) present.

Upstream release monitoring for Drupal modules.

Today I added a couple examples to the Fedora wiki’s upstream release monitoring page that will allow maintainers to track new releases of Drupal modules. You can simply follow the template to add yours.

The upstream release monitoring system is provided through the courtesy of long-time Fedora contributor Till Maas, whose cnucnu software informs participating maintainers by filing a bug when the upstream releases a new copy of their software. Although most if not all maintainers monitor feeds and mailing lists, the bug is a reminder of what’s left to do, and doesn’t require the maintainer to stop what they’re doing when they get an email or RSS notification. Instead, they can trust their bug list.

As we are finishing up our last steps on the Insight project, we wanted to make sure that, since we packaged quite a number of Drupal modules to do our development and staging, we continued to keep on top of maintenance duties. Having the upstream releases monitored with automatic bugs was a natural next step. Of course, it also helps when you have a willing team of people who sign on for co-maintenance, or at least watch Bugzilla for those packages to pitch in when needed.

Thanks to Peter Borsa, Sven Lankes, Eric Christensen, and the seemingly omnipotent Jon Ciesla for their help maintaining these useful packages. It wouldn’t be possible without you guys.

Help for the hapless.

I often make typos, and sometimes I hit a key combo when I don’t mean to. (That never happens to you right? Right?) One of my most common goof s is hitting several of the same key combination in a row, such as Ctrl+D to exit shells. I might find myself in a situation where I’m running a secure shell session in a terminal, and after I exit out of several subshells or a screen session with Ctrl+D, I inadvertently hit Ctrl+D one extra time,¬†and exit the shell I wanted to keep.

Now ordinarily this wouldn’t be a problem — just run ssh to get back into the box, and Bob’s your uncle. But every once in a while it can be disastrous, for instance when you’re piddling around with the network on a remote box, or if the SSH session in question is providing a tunnel for some other applications in progress.

I do a couple things to avoid this problem. The first is to use the ControlMaster option with my SSH sessions (the shorthand option is -M). More than one instance can share the same connection. The first instance acts as a master, and you can configure where to store the socket it’s using. Additional sessions you start on the same host and port will share the connection.

This has a couple effects, and one of them is fast startups for the second and following connections — since the connection has already been made and you’ve authenticated, all that remains is to start up the session (such as a login shell). Another effect is that you can shut all the connections down (somewhat forcibly) by shutting down the master session!

Take my situation for example. I set this option in my personal configuration file (~/.ssh/config), because¬†I often have multiple connections open from different applications to the same host. Sometimes those connections aren’t all obvious. For example, my music library is on a remote host that I access with¬†Rhythmbox via SFTP (FTP over SSH). The SFTP connection will open automatically when I start up Rhythmbox — I get prompted for the passphrase, of course, because I don’t like to store that anywhere — and the volume is mounted via Nautilus, the GNOME file manager.

Now imagine later on, I open a secure shell to the same system for other work. If I unmount the share for some reason, having forgotten it was the first thing that started a SSH connection and thus inherited the title of “master,” boom! My other SSH session gets disconnected. Yikes. And the reverse sometimes happens too — I might stop the SSH session I started in the morning, and if it’s the master for the music library connection from Rhythmbox, my music might stop cold.

So obviously, I like the positive side effects of this setting, but not so much that last, negative one. Especially when I have a ¬†habit of shutting down the master carelessly. Recently I’ve started using is the -N option to help solve this problem, which doesn’t execute anything on the remote side after authenticating. I think I saw this hint elsewhere, and found it intriguing.

You don’t get a shell or anything else after login, just an open socket. So at this point you can background the job (Ctrl+Z in the bash shell), and close the terminal it’s in. The SSH socket stays open peacefully and invisibly in the background like a Zen master, waiting to do your bidding.¬†Now you can open up additional sessions on that system with ssh remote-host-name, and they pop up quickly. No matter what interactive shell session you close, things keep humming right along. (If you really need to close the entire connection and all shared sessions with it, you can just kill the master connection that’s still in the background.)

Since I use a variety of SSH tunnels for different stuff, the¬†-N switch has made it much easier for me to keep my tunnels alive and working even if I have to logout of my GNOME session.¬†If you’re more trusting with keeping your SSH passphrases in the GNOME Keyring, you could start up lots of these background connections with minimal keyboard interaction. If you wanted to be slightly more¬†clever, you could even set up a notification that would inform you if one of the background sessions failed (that will still generate an error condition on your end, the client end).

This is not the only way to use SSH more effectively, but this method solved my problem and I hope you find it useful, and that it helps you complete your work a little more efficiently.¬†I’ve started a category for hints like this on my blog, and I’ll continue to send useful tidbits here for your reading pleasure. If this information helped you, or if you want to make an additional suggestion, please feel free to use the comment form, or trackback from your own helpful blog entry.

Eager beaver, no. 38.

I was really eager to get my laptop onto the branch that will become Fedora 15. A recently uncovered bug (possibly in glibc), along with another unrelated problem (in pygobject?), are preventing installs via the nightly composed ISO images of the pre-release. So if you’re on Fedora 14, and want to get on the new branch, you could do this:

  1. Back up your data and at least your /etc directory. You never know what you might wish you’d kept!
  2. Also run the following command to save the names of your installed packages: rpm -qa –qf ‘%{NAME}\n’ > /home/rpmnames-old.txt
  3. Download the Fedora 15 Alpha release, Desktop Live spin, in your choice of 32- or 64-bit, and install. In a moment you’ll update everything.
  4. After you start up and run through the normal setups, don’t bother logging in at the GUI yet. Hit Ctrl+Alt+F2 to switch to a text terminal. Login as root, or else use sudo with the following commands.
  5. Install any -release type repository RPMs you may want. I keep copies of these hanging around for just such occasions.
  6. Get the names of the newly installed packages: rpm -qa –qf ‘%{NAME}\n’ > /home/rpmnames-new.txt
  7. Run: yum –skip-broken install `diff -u /home/rpmnames-old.txt /home/rpmnames-new.txt | tail -n +4 | grep ‘^-‘ | cut -c 2-`

Note this is not a perfect solution. Releases change, and some packages may not be available in the new release that were in the old one. You may want to rerun steps 6 and 7 a couple days later if there are any broken dependencies that foil you from installing everything you wanted. Or alternately, you might want to stick in a step 6.5, which runs a few yum groupinstall commands to make step 7 shorter. This isn’t a panacea, it’s just a quick way to get up and running if you want to try out the new hotness but are stymied by the bugs listed above.

And of course, you could just download the entire Alpha DVD and point it at ¬†so you won’t have to twiddle as much afterward; quite a few services that run by default in a DVD install, like sshd, aren’t necessarily enabled by default in an installation from the Live image. The above is just a quick way to get started if you know you’ll be doing further installation testing or other hackery later anyway. And it will give you a good flavor for the awesome new GNOME environment.

What if you want recapture your user account and password? Just refer back to your backup you made. Do not simply restore it over the new /etc files. You could really get hosed that way. Instead do something like this. I’m going to assume you only have a couple of users on your system, starting with userid 500 per normal:

mkdir /tmp/restore && cd /tmp/restore
tar xf /path/to/etc-backup.tar.gz   # Got backup?
for i in $(grep ':50[0-9]:' etc/passwd | cut -d: -f1); do
  for f in passwd shadow group gshadow; do
    grep ^$i etc/$f >> /etc/$f

Here’s something I also recommend: move your user’s ~/.gconf directory to a backup before you login the first time. Try the spiffy new GNOME 3 out in its default settings. If you need to tweak or restore, you still have the old settings to which you can refer. But it’s worth trying everything as it was intended out of the box. I’m totally excited to run the pre-release so I can rock the new GNOME Shell. Pretty soon I’ll start working on a new branch of PulseCaster that will use the new PyGObject available in Fedora 15, and maybe a few of the cool new GTK+ 3 bits I’ve seen might be helpful in the ¬†new UI.


PulseCaster released!

Yup, a new release of PulseCaster is finally out with some real improvements. Iffy design? You betcha. Ugly code? Don’t even get me started. Pernicious bugs lurking? Bring it on. But I’m still happy, and you know why?

Working VU meters. That’s right, it took me forever to find the answer that was right under my nose all the time: the GStreamer “level” element. Why build a bunch of bindings to PulseAudio, even if I love it, when I can just set up a GStreamer pipeline with a couple quick Python commands? It seemed to me I pored over the GStreamer docs constantly when I started working on this project, but somehow I just kept missing “level,” when it was all I needed.

The recording guts haven’t changed at all — PulseCaster is currently designed to do just one thing, which is allow you to record two sides of an audio conversation supported by a PulseAudio server to an Ogg Vorbis file you can immediately publish. So if you want to interview someone using a SIP application, you just dial them up, run PulseCaster and set the inputs, and hit the record button.

That being said, this is a 0.1.x series and is nowhere near what I want the interface to look like eventually. I have plans for that, <evil_laugh>mwahahaha</evil_laugh>. But it’s at least the teeny-tiniest bit useful as is, and because it’s Python, it’s eminently hackable if you have the inclination. Just wear shades when you read the code so you’re not blinded by the horror.

The git repo has a TODO list currently, but I’m going to make an effort to transfer its contents soon to Trac tickets at the upstream site, and do a better job at release management. You know, in my copious spare time.


Defaulting to open.

One of the fundamental principles I think our community expects from Fedora is that we default to open wherever possible. In other words, unless carrying out a process in an open and transparent way would be impossible (legal reasons, for example), we should do it. And by and large, we really do.

The primary tool for that openness is communication. You can’t be open without talking with people — in advance, to encourage discussion, debate, and an informed decision; during the process, so everyone involved knows the status, tunes expectations properly, and has an opportunity to contribute; and after the work is done, so the community understands and appreciates it.

In any large organization, it’s easy to miss opportunities for better communication. The less open the organization is by nature, of course, the more often that happens. But it’s a reasonable expectation that a collaborative project like Fedora with the levels of openness and transparency we embrace shouldn’t suffer from this problem too often.

If your team is working on an issue that affects another team, by default your modus operandi should include communicating with that team. The best time to do that is when you’re trying to decide how to move forward. If you’ll indulge some business-speak, making your stakeholders’ or customers’ concerns part of your decision making process is important no matter what business you’re in — even if you’re not a business that defaults to open. In a business that does default to open, even though your list of stakeholders or customers may be a bigger list, it’s still an imperative.

Got a question about why a team works the way they do? Wondering why something happened the way it did? Ask them directly, or cc: their list. Mailing lists are tough animals with which to wrestle, especially if you add several to a thread. But that’s not a reason not to have the conversation. Set a followup or reply-to list, and let people know in the opening message where you expect the further discussion to happen.

Contemplating making a change that affects other teams? Get their thoughts early in the process, to avoid the appearance of throwing something over the wall. (Throwing things over walls is for closed or non-collaborative groups, not us!)

Sure, there’s a gray area between consulting enough people early, and trying to achieve unanimous consensus. Unanimity is great when you can achieve it, but it’s not strictly necessary for everything that needs to happen in a project, especially one that needs to move boldly forward as we like Fedora to do. But that¬†gray area is a wide one, and there’s a good distance you can cover without overly inflicting stop energy on a good idea.

Speaking as a fellow contributor, I’d like to see every team in Fedora continuing to make a concerted effort to talk across team lines. That communication needs to start with your own team of course: minimizing private discussions wherever appropriate; keeping teammates engaged in daily and long-term work; and moving discussions where you need more input and discussion off of IRC and onto your mailing list, just to name a few examples. But just as importantly, when necessary let’s renew our efforts to communicate with our fellow teams, to make sure we’re making good decisions, and that overall we are having a positive effect on each other’s contributions in Fedora.

This post was prompted by a couple instances recently where I saw teams not reaching out for each other to ask questions or give information. I haven’t seen evidence of any widespread trends; in general, Fedora team members do a great job of communicating across teams. These instances were exceptions to the rule, but it would be fantastic if those exceptions never happened at all. (Zero may be an unattainable goal, but that doesn’t make it the wrong goal.) I’m not calling out specifics simply because they wouldn’t change the value of the ideas and practices discussed here.