|
March 26 2011
8:38 pm  Fedora, Food + Drink, Friends + Family, Linux, PulseCaster, Red Hat  Permalink  2   |
A fun day… for some hacking.Over the course of the day, I:
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:
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 done done 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. Enjoy! |
PulseCaster 0.1.8.1 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. Enjoy! |
Robocalls not appreciated.According to a robocall we received yesterday, our school system has just found out they can automate the process of calling a sizable chunk (if not all) of the schoolchildren’s parents in the county to alert us about “important news.” And the chirpy message from our county superintendent of schools notes that we can expect to hear from them repeatedly in the future. I was less than impressed. Now, I for one am happy that our school system thinks it’s worth their time (and our money) to keep us informed about current events that impact our kids’ school experience. However, they already provide numerous ways for us to receive this news, including email, websites, RSS feeds, as well as the standard news organizations around town. We take advantage of a number of those already, and it’s very helpful. For example, I love the fact that on a cold, wintry morning, my wife doesn’t have to tune into the radio and listen to 10 minutes of blather to find out whether schools are closed for icy roads. Since I work from home, I’m up anyway, and I can use my Web browser to consult the local news site or the school web page to find out closing information, and then let her know. (Or she can do the same with her smartphone, without getting out of bed.) What I don’t want is a 5:00am phone call that wakes the whole house, just to tell us schools are running late or closed. Nor do I want to be interrupted at work or dinner to hear that the school board has a public meeting next week. I can find these things out through email, which I read on my schedule, not the school system’s. You’d think our school system would have learned from this area brouhaha, which got some national media coverage too, if I recall correctly. Worse, neither the phone call, nor the copy of the same message via email (I told you we use their services already!) had details on whom to contact to opt out. They did provide the general phone number for the entire school superintendent’s office, which in my experience means calling and then being put on hold for some indeterminate length of time while someone is found who can get us removed from their system. No thank you! In this day and age it should be neither difficult, nor unreasonable, to provide an opt-out system that I can reach by email, or a Web page, or (gasp!) via the phone call itself. So this morning I sent the following inquiry to the administrative assistant for our superintendent, and copied the superintendent, his assistant, and our district’s school board member:
Hopefully that was cordial enough. We’re not tinfoil hat wearers in my house, we just like picking up the phone when it rings to find someone on the other end who’s (a) breathing, and (b) someone to whom we enjoy talking. What do you think? Am I being unreasonable? |
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. |
