Category Archives: Tips

Irssi in Terminal on GNOME 3.12 in Fedora 20.

A lot of people I know like running the Irssi IRC client in a terminal, whether in a terminal multiplexer like tmux or GNU Screen. Me too!

I also love running the latest GNOME releases. So when GNOME 3.12 was released and available for Fedora 20, I followed these simple instructions, courtesy of Fedora Magazine and Ryan Lerch, to install it on my system.

I discovered a new feature in the GNOME Terminal is that keys Alt+1 through Alt+0 are mapped to allow you to quickly navigate to the first ten tabs in Terminal. This is super-useful, but because those keys also happen to map to the shortcuts in Irssi for switching to your first ten IRC windows, I couldn’t use them in Irssi. Since I use that function a lot more often, here’s how I fixed it:

  1. Open a GNOME Terminal, and from the quick menu in GNOME Shell’s top bar, choose Preferences.
  2. Under the Shortcuts tab, locate the Tabs list.
  3. For each shortcut from “Switch to Tab 1” to “Switch to Tab 10,” click the shortcut to select it. Then click the entry under Shortcut Key. Hit the Backspace key to remove the existing shortcut.

Now you can use your Alt key combinations as before in Irssi. Have fun!


Changing font size in GNOME 3.4 on Fedora 17.

Someone asked me a few weeks ago whether I knew how to change the default font size in GNOME 3 on Fedora. I have all my boxes on Fedora 17 since before the release, with GNOME 3.4. I had to admit that I’d never looked for how to change the font size in GNOME, but it seemed like something you might want to do, especially on extremely small or large displays. I hadn’t bothered to write this up, but I thought given a news story this morning that it might be useful to others.

I had no clue where to start. So how did I find it? I went to the Overview mode by hitting the super key (you could also use the Activities hot spot or Alt+F1). Then I started typing: f o n t. The first thing that comes up in the menu is the Universal Access setting. I opened it up (I just hit Enter, but you could mouse to it just as easily), and sure enough, under the “Seeing” tab there’s a setting for the default font size!

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.

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? ūüėČ

On burnout.

Bruce Byfield has published an article on burnout in community projects, to which I was happy to contribute some thoughts. Overall I believe the thoughts people shared in that article, while not surprising or radical, can help people avoid putting themselves in a burnout situation. Moreover, they can potentially help someone realize that a friend may need a helping hand before they run smack-dab into burnout themselves.

One of the striking (but again, not surprising) bits Bruce wrote in the article was this:

The stress may be increased because the first generations of community members are now well into middle-age, and some are starting to have trouble working the hours to which they are accustomed, either because of reduced stamina or family obligations.

This statement really hit home with me, because in a very time-compressed way I went through a seismic shift in my work/life balance twice in just the space of a couple years. I was feeling somewhat in a confessional mood today, so I figured I’d try and write about my brush with burnout in an honest and not overly edited way. Like Linus, I don’t think I ever really hit a wall. Whether by luck or conscious introspection, I was able to avoid that disaster. But I did see it approaching in the distance, and maybe an explanation of what I did about it will help someone else who sees a reflection in my story.

I started in FOSS long after the very early, pioneering days. I joined the Fedora Project in 2003, by which point my wife and I were already expecting our second child. Since I was more of a homebody by that point, I found it convenient to work in a community software project. I was already hanging around the house more than I used to, but now I could plop down with a laptop and do something extra for my fellow man at night or on the weekend. Meanwhile, my day job was fairly regular, and no remote work was possible, so my work ended when I left the office.

Taking a job with Red Hat made open source the focus for most of my waking hours starting in 2008. By then my son was 4, my daughter was almost 7, and there was plenty to get done every single day on both the home and work fronts. During the next two and a half years, my work schedule became radically different. 12-14 hour days were the norm, and still there was always more to do. I would say that working from home made it easy for me to focus too much on work, and not enough on other important things, like my family. My wife, thankfully and far beyond the call of duty, took up the slack at home.

I joke sometimes to others that one of my purposes in life is to be a cautionary tale, and that definitely applies to my work/life balance problems my first 18 months at Red Hat. I only saw my kids for a small amount of time daily, and to this day I worry that I don’t have enough memories of my daughter’s early grade school or my son as a preschooler. I made it to the obligatory stuff, of course, but it wasn’t real quality time. Mostly when I wasn’t working, I was thinking or worrying about work. Breakfast, lunch and dinner were rushed events after which I’d practically sprint back to the computer, fearing about all the things I wasn’t getting done. It was a very unhealthy approach to work.

At some point partway through my job as FPL, I came to a realization: One day I’d wake up and my kids would be going off to college, and I’d be thinking, “Wait, you can’t go yet, I’m not ready.” Something had to change, and that something was me. But it couldn’t be as simple as just working less. There were lots of people counting on me for different things in Fedora, and many of them were giving their precious spare time for our project. So I had to figure out not how to work less, but how to work smarter.

I ended up overhauling a lot of my tools, for one thing. I tried to find more efficient ways of getting things done, so I could maximize my output per hour. I changed physical and network setup of my office so I had more flexibility and fewer interruptions. I also tried to refocus my work on critical path topics — for instance, trying to spend the majority of my day working on problems that would allow volunteers to get things done. And I started hitting the gym almost every weekday so I could energize the rest of my day. (I’ve fallen off the wagon the last couple of months, but I’m heading back this fall, since I’ve definitely noticed the difference in my mental attitude and energy without it.)

But that’s all mechanical, and not really as difficult as the psychological aspects. I also had to confront my own focus on trying to get everything right, and learn to forgive myself for making mistakes. (Especially since I tend to make so many.) Rather than spend a lot of time each day trying to make everything 95% correct, I needed to spend far less time to get things 75% or 80% correct, and trust other people to help me figure out the rest. When you think about it, that’s part of the open source way, really. We often say “Don’t let perfect be the enemy of good,” and I found that was equally applicable to several parts of my life, including my approach to working in an open source oriented job. Amber Graner talks about “letting go” in Bruce’s article, which I think accurately describes the conscious approach I had to take.

There’s an old saying that you’ll never hear someone on his deathbed say, “I wish I’d spent more time at the office.” I agree with that — in general, I don’t want to have regrets about how I live my life. After all, that’s why I came to Red Hat when the opportunity of chairing the Fedora Project arose. I didn’t want to look back and think, “If only….” Now I realize for me to be at my best for open source, I’ve got to be better at balancing my obligations. I have to let go of the things I can’t do, or can’t do well, and focus on the areas where I can make a difference.

Not all those areas are in work, either. I can make a big difference in my family’s quality of life by doing a better job focusing on the important parts of being a parent. Over the last couple of years, and especially this past year, I’ve started to take better advantage of opportunities to be off the keyboard and building experiences with my family. That might mean going to historical sites or museums, traveling to visit friends, or just doing fun things together, but I feel it’s made me better equipped to deal with job stress when I know I’m doing well by my family.

Of course, it’s not like I’m doing this perfectly. I still have problems with balance, but at least I feel like I have the experience now to identify them and hopefully deal with them. As I mentioned, this is somewhat a confessional article, but I’m not looking for pep talk (or, obviously, the opposite). Rather, I just wanted to share something I care deeply about, which is that I want you, Gentle Reader, to be happy in what you do and find a balance that suits you. I’d love to hear your story about how you’ve found balance, or the challenges you face in doing that. Feel free to write a comment, but I’d love to see trackback posts where you don’t feel constrained by a little comment box.

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.

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.

Making the most of the planet.

With a title like that, I could go two ways with this blog post, right? One way would be to encourage people to do stuff that’s good for the Earth, like recycling and so forth. There are probably lots of people who could do that better than me. Instead, this post is going to be about making the most of the Fedora Planet, which carries information about contributors and their work to each other and to audiences outside the Fedora Project.

I personally like to see a mixture of information on the Planet that tells me about our contributors, their work, and the things they’re doing in Fedora. Often I see stuff appearing on the Planet that isn’t really relevant to any of those topics though. When I reached out to a couple different Fedora contributors recently to ask them about posts, I found they didn’t know they could aggregate part of their blogs, based on a category or tagging, as opposed to the feed of all their content. The contributors in question were both interested in how they could do this properly, and I found that reaching out to them directly, with an offer to help, was a great way to discuss this topic in a constructive and educational way for both parties.

Why is that a helpful feature of blogging? Because it allows the writer to express themselves however they like on their blog without worrying which aggregators the content will end up feeding. A single writer may be feeding content to several different planets or other aggregators, and should have the option of where their content ends up. By having a category that maps to an aggregator, it’s easy for the author to declare where they want their content will be carried. It also gives the author a chance, when publishing, to be thoughtful about their content and where it’s most pertinent.¬†This is also¬†helpful for the community, because category specific feeds keep each aggregator (the Fedora Planet is just one example) more useful for everyone reading it.

I’ve been using WordPress for a long time for my blogging, and WordPress has ¬†a very easy way to set up categories for content, and provide a specific feed for each one. Interestingly though, both of the contributors I helped in the past week were using Blogspot. As I found out when I made a test Blogspot blog later, Blogspot does not make this process quite as simple or straightforward, although the feature does exist and work fine.

So, armed with that knowledge, I set up a couple extra wiki pages with instructions for how to set up category specific feeds for a WordPress blog, and how to do the same thing for a Blogspot (or Blogger) blog. I also linked these pages to the general instruction page for the Planet. Hopefully, these pages will be useful to contributors adding themselves to the Fedora Planet. Even if you’re already on the Planet, if you’re not familiar with the process of categorization or labeling, you might find these pages helpful.

Note that none of the above information is meant to stop people from discussing topics relevant to our community, but not specific to Fedora, on our Planet. My hope is that using categorization like this will continue to improve the quality of content on the feed, and even help bloggers contribute information to more aggregators.