It's just been announced that Jared Smith will be the new Fedora Project Leader - congratulations to him. I've come across his work in various contexts and he seems like a really smart choice. I'm also happy that RH has again taken on someone who was not an existing RH employee to be the project leader, I think it demonstrates great commitment to the wider Fedora community. Many thanks of course also to Paul Frields, outgoing FPL, who did a fantastic job in every way. Except possibly his FUDCon Toronto closing speech ;) Only kidding, Paul!

Yes, Flash sucks. But many of us need it for one site or another. And lots of us are running 64-bit Linux these days, where Adobe has famously refused (so far) to update the plugin for the recent serious vulnerabilities in Flash, leaving us between a rock and a hard place. Just a quick reminder - the bad old way of doing things still works...that is, nspluginwrapper. First, get a copy of the Flash plugin from the Adobe web site. Don't use the yum repo, as it pulls in Adobe Reader as a dependency of Flash (classy move, Adobe) which will result in even more 32-bit crap getting installed on your system than necessary. Just get the .tar.gz, and extract it into /usr/lib/mozilla/plugins (not /usr/lib64). Now do: yum install nspluginwrapper.i686 (you'll also need to install the x86-64 package, for most people it should be installed already, but check - thanks Hansvon!) and it should do its stuff. Remove gnash if you installed it, then restart Firefox, and you should be good to go. If not, use about:plugins in Firefox, and mozilla-plugin-config (useful parameters - -l, -v) at the console as root to diagnose.

So Fedora's awesome design team is looking for ideas for Fedora 14's release theme, and feedback on already-submitted concepts. Here's a crazy story - I met Luya Tshimbalanga at FUDCon Toronto. After the whole first day, I finally realized he was the same guy as Finalzone, who I knew from the forums was also from Vancouver. But it was only after we both got back to Vancouver that we realized he works at the Safeway right up the street from me and I'd been buying groceries off him for years! It's funny how, if you encounter someone in sufficiently different contexts, you just don't twig that it's the same person... Anyway, Luya has a blog post about the release theme concepts. The team would love feedback on the design mailing list, and if you have a design concept to contribute, go ahead and post it to the wiki page. Martin Sourada also has a post up on the topic. Here's your chance to help make sure Fedora 14 looks as good as it feels (we hope!)

You may have noticed the blog has been a bit light on QA news lately. I attribute this to the sudden outbreak of tennis- and golf-friendly weather. ;) No, really, it's mostly because we're in the Post-Release Lull where we do a lot of planning and little Exciting Stuff. But there are a few things happening! Of course, work on AutoQA continues apace, with new hooks and watchers and code improvements coming in thick and fast. I'm not really well up on the gory details, but it's very obvious that this is moving along nicely and we should be able to start really using it in anger for F14 and F15. One particularly notable development is that the AutoQA team is now offering package maintainers the chance to be notified of rpmlint, rpmguard and (when available) initscript LSB compliance test failures for all Koji builds of their packages. This is something of an interim system, but the fact that the AutoQA infrastructure is already capable of running these tests against each Koji build and providing the results to the package maintainers is great. What's this 'initscript LSB compliance' testing, then? The AutoQA team is implementing tests to check whether initscripts in Fedora packages comply with LSB guidelines. The tests need to be customized to each individual initscript, so this is a lot of work. Josef Skladanka put out a call for help in implementing the actual tests and reviewing the tests to make sure they're working correctly. There's a wiki page which describes the whole effort and the various ways you can get involved and help out. The Bugzappers group has also seen some great developments lately. A new member, Jeff Raber, has heroically taken on the mantle of the triage metrics project. We've long wanted to have some way of measuring progress with triage, so we can know how many bugs we're triaging, how many components we're covering, and so forth. We're now taking a new, simplified approach to this, based around simply coming up with some canned Bugzilla queries we can run manually every so often to generate some basic statistics. This should allow us to get up and running with at least some information in a manageable timescale. Jeff's already come up with a few queries and some small modifications to python-bugzilla to produce the type of output we need, so that's looking very promising! We've also been working on kernel triage again, with the coolly-nicknamed 'JP' (tcpip4000 on IRC) revising the stock responses on the old kernel triage wiki page to be more in line with the rest of the Bugzappers stock responses. I'm also supposed to be talking to the kernel team to get a current list of distinctly-maintained kernel subsystems out of them, as part of our plan to effectively split the kernel bugs in Bugzilla up by kernel subcomponent, using tracker bugs. James has been working hard on the Fedora 13 QA retrospective, which we'll use to identify various areas we can improve on for Fedora 14. Many members of the QA group have chipped in with ideas and suggestions here. And finally, I'm working on my big Sekrit Project for F14, which will be to try and extend the desktop validation testing we did for the default desktop (GNOME) in Fedora 13 to all the major desktops Fedora ships - KDE, LXDE and Xfce. I'd like us to be able to ship F14 with the same level of confidence in basic desktop functionality for all four main desktops. Even though they happen not to be the default desktop, they're still significant parts of the Fedora project which many of our users take advantage of. I'm hoping to work this into the validation process starting right from the first pre-releases, and I'm already working with the KDE, LXDE and Xfce SIGs to try and make it a reality. Of course, Fedora 14 Test Days will be coming soon, and it won't be long before we have an initial snapshot and then an Alpha release, and then we'll be well on our way to Beta and then Final. Lots to look forward to!

I've long wanted something like Mozilla Sync, so it came as something of a surprise to me that it exists in fairly polished and working form. I haven't seen much news about it, which is surprising, especially from such a well-oiled project as Mozilla; is it in some kind of stealth mode? Anyway, Mozilla Sync does something very useful in a very good way. It synchronizes your browsing history, bookmarks, tabs, stored passwords (if you have any) and so on across multiple Firefox instances (or other supported apps, I think Seamonkey works too, didn't really look). This is just great if you rely heavily on the awesomebar history like I do - I can be sure all the latest pages I've visited will be stored no matter which system I'm using. Also nice to be able to see what tabs I had open on my desktop when I'm using my laptop. An equally nice thing about Sync is that it demonstrates how well the Mozilla project has its head screwed on when it comes to openness and privacy. Sync is based on something called Weave, which is a fairly ambitious system for allowing Mozilla products to store data into 'the cloud' (ptooie). Now, imagine if, oh, Google - no, worse, Apple - was providing this service. You can bet you'd get exactly one choice of server - Apple's server. The protocol wouldn't be open, so you couldn't write your own server. If you actually bothered to read the terms of service before signing up, it'd be full of disclaimers about how Apple or Google could use the info on the sites you visit and so on to spam you with ads. It'd probably have a worryingly vague privacy policy that made ambiguous references to 'anonymising' data. Not with Mozilla. Nope. When you set up Sync, it asks you for an account username and password then for a *separate* passphrase, which it uses to encrypt all the data before sending it to the server. If you choose to use Mozilla's server, all they get is an encrypted blob of data. They haven't a clue what's in it. They couldn't use it to profile you if they tried. If you still want to run your own server, you can install Weave on your own server. If you really wanted to, you could write your own separate implementation, since they're very careful to document how everything works. The full-fat Weave is a big complex thing, so one Mozilla guy - Toby Elliott - has even created a minimal Weave server implementation which is a tiny little thing you can run on just about any web server which provides enough functionality for a basic Sync setup. Huge kudos to the Mozilla folks. It's great to have a big body in the rough and tumble online services world that really Gets It.

I was rather tickled by the cartoon in this post. I noticed the same problem with gwibber in the Ubuntu 10.04 screenshots; it's not entirely clear what it does until you try it!

Yesterday morning, my virtual machine host system gave up the ghost. It was working fine, I did an upgrade on it which included a new kernel, went to reboot it, and it never powered on again. Various tricks up to and including percussive maintenance wouldn't convince it to come back from beyond the grave. Ah, well - it had a reasonably good run, five years for a Shuttle shoebox ain't bad. So off to Netlink I went, for the components for a new virtual machine host box. The case and PSU I bought turned out to be a waste of money as it didn't quite fit in my cabinet (curse you, wobbly tape measures), and I realized I had an old Shuttle-type case which takes generic mATX motherboards in the basement...so I just used that instead. Its custom PSU has the old 20-pin ATX power connector not the new 24-pin eATX one, but it still seems to work okay; the motherboard manual says this is okay as long as it can supply sufficient power over +12V, which it claims to. The components I went with - Asus M2N68-AM Plus motherboard (I'd have got the M4N68T-M but they were out of stock), Athlon II X2 250 CPU, Kingston HyperX RAM - went together without problems and work fine. The combo isn't exactly optimized for raw speed (you'd want a motherboard with a newer chipset and DDR-3 RAM for that) but it should be more than fast enough for the purpose, and the motherboard was nice and cheap. Here I am with my new box, then, and unlike the old one it's a 64-bit CPU with virt support. And now I work for Red Hat. Naturally, it gets to run Fedora 13 (could've used RHEL, but c'mon, where's the fun in that?!) and use libvirt / kvm. The old box ran Mandriva and VMware Server, so I have some work to put in. I'm amazed, though, at how much work it turned out not to be! I did a minimal install of F13, installed the 'Virtualization' package group, and set up normal network stuff, including key-based ssh login for root (no reason to create a user account on such a system). Know how much work it is to set up an F13 machine to be a virtualization host that you can manage from virt-manager running on another system? EXACTLY THAT MUCH WORK, that's how much. Just run virt-manager on your other system, add a connection, set Connection to 'Remote tunnel over SSH', and enter the hostname. As long as you have key-based login for root, that's all you need. Converting my VMware VMs to libvirty qemu/kvm ones turned out to be equally, surprisingly, simple. This doesn't give optimal performance as it doesn't use virtio, but it seems more than good enough for my modest needs. Use vmware2libvirt (thanks Ubuntu land for that one) to convert the VMware .vmx file into a libvirt XML machine definition. Use 'qemu-img convert filename.vmdk -O qcow2 filename.qcow2' to convert the virtual disk file from VMware to qemu format (this is optional, as it can use the VMware disk image format directly, but it won't be able to do snapshots then, so conversion is recommended). Both of these steps create new files, so the old VMware machine still exists completely unaltered if you need to go back to it. Edit the .xml file slightly to point to the qcow2 file instead of the vmdk one, and to change the qemu executable from /usr/bin/qemu to /usr/bin/qemu-kvm (on Ubuntu it's the former, on Fedora it's the latter). Then import the .xml file into libvirt with 'virsh -c qemu:///system define filename.xml' . That's it: the entire process. If you look at your shiny remotely-connected virt-manager session now, you'll see the VM all ready to be booted up. Very very neat stuff! I actually had to do one more step, to set up bridged networking for libvirt, which you only need to do if you need to use bridged networking for your VMs, obviously. That's simple too - just follow the libvirt wiki instructions, and when using vmware2libvirt , use the -b (interface) parameter to tell it you want to use bridged networking and what interface to use. With just an hour or so's work, including all the research, I've converted all three of my server VMs from VMware machines running on VMware Server on Mandriva to qemu/kvm machines running on libvirt on Fedora. Huge kudos to all the virtualization folks for their amazing work on this, the libvirt stack is very very impressive these days. Of course, if you're wondering where this blog went for the last day or so, the above is the answer :) Yesterday was all spent in planning and doing the hardware build, today was setting up the software. Sorry for the inconvenience, believe me it's worse for me than it is for you when this happens!

This is quite a quiet time for QA as we're just sitting around waiting for F13 to come out and writing up some documentation, so I took the opportunity to work on my packaging stuff. I've sent a new navit build to the review request bug, so that may _finally_ make it into the repos soon. On my private repos, some good news, some bad. The good news - I've updated the video-experimental repo with the latest builds of libva, vdpau-video and mplayer-accelerated. I've also added the shiny new gstreamer-vaapi. Unfortunately that doesn't work on my current test system (a laptop with NVIDIA graphics, the proprietary driver, and vdpau-video); mplayer-accelerated works just fine in that setup, but Totem barfs when I try and play any video. I'll be in touch with Gwenole to see what he thinks about that. It'd be interesting to hear from anyone else who's playing with these packages whether gstreamer-vaapi works; all you have to do to test it is install it and then try and play a video in totem. The bad news is on the Poulsbo front. I decided to just say 'screw it', updated the Vaio P to Fedora 13, and tried it out with psb, with Olivier's patches from Mandriva. Unfortunately, it don't work. The kernel module loads okay, X starts up, it loads Xpsb.so and then X just stops. The system's up, hitting power gives a clean shutdown, but the screen is blank and can't see even the virtual consoles any more. I'll try and figure out what the problem is, but it's looking tricky at the moment. Since I jumped straight to F13 I actually didn't get a chance to test F12, so I don't know whether that works! It's a bit tricky to set it up so I can test, but if I get the free time I might try.

I noticed this morning that the Firefox 'awesomebar' - the feature where it suggests pages you're probably looking for as you type in the location bar - just wasn't working any more. It didn't pop up any suggestions at all, no matter what I typed. I remember when this was first introduced I moaned about it quite publicly, but they made it lots better, and now losing it feels more or less like having my arms cut off - I don't have bookmarks any more, I just remember tiny snippets of URLs or page names and Awesomebar does the rest (to add this blog entry I just type 'happ' and the admin interface of my blog pops up as the first link). A quick trip to the error console (" Error: Places AutoComplete: [xpconnect wrapped mozIStorageError] Source File: file:///usr/lib64/xulrunner-1.9.2/components/nsPlacesAutoComplete.js Line: 496") and a moan at Red Hat's Mozilla maintainer led me to suspect that the places.sqlite file in my Firefox profile - which stores the browsing history - was somehow problematic, though it clearly wasn't entirely broken as I could browse History / Show All History just fine, and sqlite3 didn't seem to have problems with it. I confirmed that moving this file and letting Firefox generate a new one made the feature itself work again, but of course it didn't have my actual browsing history, so that was no good. Finally, with a bit of GoogleHelp, I got it sorted. Back up the 'broken' places.sqlite to places.sqlite.bak, run Firefox to get a fresh places.sqlite generated, quit Firefox again, and do: echo ".dump" | sqlite3 places.sqlite.bak | sqlite3 places.sqlite re-run Firefox, and the feature's working and my actual browsing history is in it. Phew!

I've written about various geeky bits I use to streamline some things I do a lot of - bip and bitlbee for proxying IRC and IM conversations, having my own mail and groupware servers and so on. I just set up another one this morning: Tiny Tiny RSS (thanks to Leonardo Fontenelle for the tip). This is a pretty humdrum one, and I imagine I'm a long way behind many people on this, but ah well. It's just a feed reader implemented as a webapp - so it's like using liferea only it runs on your web server (you, uh, DO have a web server, right?) so you can access it from anywhere. Or, it's like using Bloglines or something similar, except you run the server yourself, so Google doesn't get to add 'what blogs you read' to the already worryingly long and juicy list of information it has on you. I wasn't using any kind of aggregator before this - I spent...er...rather a long time per day reading umpteen different sites (Engadget, The Register, Planet Fedora, Planet GNOME, BBC and CBC News, OS News, Linux Today, TuxMachines, and Slashdot, if you must know) via Firefox's bookmark toolbar, and compulsively checking a dozen or so others for very periodic updates (comic sites, a couple of git changelogs, you get the picture). This is just vastly better. The only downside is that it's seriously affected my procrastination capabilities. I need to figure out some whole new thing to do when I want to avoid some particularly tedious work-related hoop jumping exercise. Damn it!