Unity, hardware failures, and F15 QA

So, I bet everyone's just dying to hear what's going on with Unity, right?! Well, I've been co-ordinating with various people both Fedora-side and Ubuntu-side to resolve the various roadblocks to getting it done. I'm happy to say that, tentatively, I think we've done that now. The major issues were problems with various probably-trademarked images in Nux; a patch to glib which is used by Bamf and has not been accepted by upstream; and Unity's reliance on Compiz 0.9 with some extra changes which aren't currently the main upstream branch. All the Ubuntu / Canonical folks I've talked to about this have been super friendly, helpful and enthusiastic about the prospect of Unity running on Fedora, which is really awesome. They've genuinely been bending over backwards to help make it possible, so a big thanks to Neil Patel, Mikkel Erlandsen, Jason Smith, Sam Spilsbury and others. After I asked about the problematic files in Nux they worked very quickly to remove them (they're not needed anyway); they were also very helpful in discussing the glib/bamf issue, and Sam's been great with pointers on Compiz. So, this is (roughly) the plan: the Nux issue is resolved upstream and a new release should be done soon (if not, I'll just package a snapshot). bamf doesn't actually need the glib patch; it can be built without it just by excluding one directory entirely from the build. I'll probably submit a patch to add a configure parameter to do this, to make it a bit cleaner and more discoverable. Then we can package bamf for Fedora without worrying about the glib patch. It'll result in slightly reduced accuracy in application matching, but apparently it still works pretty well even without the glib patch. Long term, upstream wants to take a different approach to solving the larger issue here (application matching), so they won't be taking the patch as submitted; Colin Walters will be working on implementing that, the Canonical developers may be able to help out, and once it gets done, bamf can be changed to use the new framework instead of the extension point implemented by the current patch. I'll be helping the Fedora compiz maintainer to package the upstream compiz 0.9 branch which includes the changes necessary for Unity; Sam says that this will be merged to master upstream in the medium term, it's just not quite ready for it yet, but it is definitely The Future, so we won't be diverging from upstream in the long term. We haven't totally decided yet whether to just do this as the main Fedora compiz package for F15+ or have it as a variant package used only by Unity, but one way or the other, we'll do it. The remaining issue is likely to be support for the Ayatana indicators framework which Unity prefers to use; many apps require patches to support this, and most of those aren't upstreamed. I'll look at that when I get to it, but probably those will just be left out for now. If anyone can think of a better approach, do let me know. :) The Unity stuff is fun but it does come after my Real Work stuff in my priority list; so help is greatly appreciated, if anyone wants to get involved and take one or more of the necessary packaging jobs, or help with the Compiz stuff, let me know. And speaking of Real Work! I've got two interesting big projects for the F15 cycle. The first is implementing a framework for specific test cases for critical path package updates. It's been widely noted on devel and test lists that the critical path update testing process could be improved if we have specific test cases for some or all critical path packages, providing explicit testing steps to help ensure that the vital functionality of each package can actually be tested. I'm working to set up an overall framework for these tests so they can easily integrated with tools like Bodhi and fedora-easy-karma to keep the testing process nice and streamlined. Of course, once the framework is in place, we have to create as many tests as we can; I'm hoping that both QA and development group members can co-ordinate on that, with maintainers of critpath packages helping outline the testing that will be required for their packages. The second is to help plan the Test Day calendar for Fedora 15; this will be a bit more involved with the landing of two major features, GNOME 3 and systemd. We need to ensure we have comprehensive test day coverage for these to make sure they're reasonably robust for the final release. I've been doing some preliminary planning with Matthias Clasen for the GNOME 3 Test Days, and we'll start pencilling in dates and developing test plans soon. I would probably have got the Real Work stuff done earlier this week if all my hardware hadn't decided to go wonky on me at the same time. On Monday my TinyBook (that's what I call the Vaio P, these days) started behaving very weirdly, which I quickly traced back to some of the memory having gone bad. Unfortunately, the tinyness of the P is aided by the RAM being soldered directly onto the motherboard, rather than using any kind of DIMM, so it's not replaceable. Fortunately, this proved another great distraction-based education opportunity, and I learned about the memmap parameter, which allows you to tell the kernel to ignore certain areas of system memory - perfect for this case. So that got the system mostly up and running again at the cost of 100MB of RAM. I think the bad RAM may also be causing it not to suspend properly, but I'm not entirely sure. That took a lot of Monday to sort out (I had to reinstall as the bad RAM had caused a bunch of packages to get corrupted during a big update operation), and then on Tuesday my HTPC (which also serves as my NAS) went equally wiggy, the desktop suddenly crashing when I exited freevo, and any attempt to run anything via an ssh connection causing an input/output error. This one I'm pretty sure is down to the system hard disk (the NAS bit is a 1GB RAID-5 array of three 500GB disks), which was a 2004-vintage Seagate 7200.7 160GB antique. It had been throwing intermittent errors in the system logs for a while, so I figured this was my cue to replace it. Fortunately I had a spare 500GB on hand (when one of the disks in the RAID array goes bad I RMA it, but usually I buy another while waiting for the RMA swap disk to arrive, as running a degraded array for any length of time really ain't a great idea), so I could just do a straight swap. This also turned out to be another great distraction-based learning opportunity, as I found a very nice no-hassle way to completely perfectly clone the disk: ddrescue. I just ran about the simplest case - ddrescue -B -v /dev/sda dev/sdb /media/usb/ddrescue_logfile.log - and fortunately it managed to clone the ailing drive without hitting any errors. This results in an absolutely perfect clone on the new disk, with the partition table, boot sector, and even the UUID of each partition intact - so you can just take out the old drive and boot the machine without any kind of tinkering with the boot configure or fstab required. After the clone and reboot everything just worked, except for MythTV, which I eventually figured was due to the initial disk fail having resulted in the MythTV MySQL database being a bit messed up; a quick mysqlrepair solved that. So both of those failures proved interesting and educational in their own ways, but I could really do with not having any more this week. Here's hoping!