The big news this week is definitely that Fedora 22 Alpha is released! We even managed to ship this one on time, though as it's an Alpha, it is of course not bug-free. For me the nicest thing about Fedora 22 is all the improvements in GNOME 3.16, which Alpha has a pre-release of. The new notification system is a huge improvement. I'm fighting some bugs in Evolution's new composer, but mostly it's working out.
We also have the next Fedora 22 Test Day coming up tomorrow, Ipsilon Test Day. This is one of those pretty specialized events that requires some interest in and probably knowledge of a specialist area; it also requires a fairly powerful test system with a decent amount of spare disk space.
Ipsilon provides SSO services together with separate identity management systems; it's being implemented into Fedora's identity/authentication system to replace Fedoauth (or this may have already happened, I'm not quite sure on the timelines!). It's one of those things where you go to some website, and you need to log in, and you get redirected through an authentication system that might be shared with lots of other websites - like when you log in to various Fedora sites through the shared Fedora authentication process.
If you're already interested in FreeIPA and might be interested in looking at web application-focused SSO on top of it, you may well be interested in this Test Day. So come join us in #fedora-test-day on Freenode IRC and help out!
Personally, I've been working on our openQA-based automated install testing system for the last few days.
Waaaaaaaaait, I hear you say, Fedora has an automated install testing system?
Well, it does now. We are still expecting Taskotron to be our long-term story in this area, but after the awesome Richard Brown demonstrated the feasibility of getting a quick-and-dirty Fedora deployment of openQA running, some of the Red Hat folks working on Fedora QA in our Brno office - Jan Sedlak and Josef Skladanka - threw together an implementation in literally a few days, as a stopgap measure until Taskotron is ready.
The original couple of deployments of the system are behind the Red Hat firewall, just because it works out easier for the devs that way, but I now have my own instance which is running on my own servers and is entirely public; you can look in on all my experiments there. (Please don't download any really huge files from it - all the images I'm testing are available from the public Fedora servers and mirrors, and I have limited bandwidth).
The Fedora tests and the dispatcher and other miscellaneous bits are available, and there's a deployment guide - click on InstallGuide.txt, I'm not giving a direct link because BitBucket doesn't seem to make it possible to do a direct link to the current master revision of an individual file - if you're feeling adventurous and want to set up your own deployment. We are running our instances on openSUSE at the moment, because packaging openQA for Fedora and making any necessary adjustments to its layout would sort of defeat the object of a quick-and-dirty system. And hey, openSUSE is a pretty cool distro too! We're all friends.
The first thing I did was make the system use fedfind for locating, downloading and identifying (in terms of version and payload) images. This had the benefit of making it work for builds other than Rawhide nightlies.
I have my own forks of the tests and tools where I'm keeping topic branches for the work I'm doing. Currently I'm working on the live branches, where I'm implementing testing of live images (and really just uncoupling the system from some expectations it has about only testing one image per build per arch in general). It's mostly done, and I'm hoping to get it merged in soon. After that I'm probably going to work on getting the system to report bugs when it encounters crashes. It's painful sometimes figuring out how to do stuff in perl, but mostly it's been pretty fun working with the system; you can argue that a test system based on screenshot recognition is silly, but really, just about any form of automated testing for interactive interfaces is silly in some way or another, and at least this one's out there and working.
The openQA devs have been very open to questions and suggestions, so thanks to them! I have a couple of trivial commits upstream to fix issues I noticed while running the development packages on my instance.
When you look at Fedora 22 (and later?) release validation pages, results you see from 'coconut' and 'colada' are from the openQA instances - 'coconut' results are from the deployments managed by the main devs, and 'colada' results are from my deployment.
Finally, before I dived into openQA I did find a bit of time to work on ownCloud. I got ownCloud 8 into good enough shape (I think!) to go in Rawhide and Fedora 22: it's now in Rawhide, and there's an update pending for Fedora 22.
The other distro which gets a major update is EPEL 6; there's an update pending for 7.0.4 (current stable for EPEL 6 is OC 6).
7.0.4-3 is also pending as an update for the stable Fedora releases and EPEL 7; for those releases it's a minor update which mostly tweaks the Apache HTTP configuration file handling. I came up with a new layout which, as well as making the App Store actually work, should make it easier to 'fire and forget' a typical ownCloud deployment's HTTP configuration; after you do the initial setup, you can run ln -s /etc/httpd/conf.d/owncloud-access.conf.avail /etc/httpd/conf.d/z-owncloud-access.conf to open up access from anywhere, and you won't have to manually check config files on future upgrades, because I'll keep owncloud-access.conf.avail up to date with any directory/path changes that crop up in future releases. If you have an existing ownCloud install and you'd like to 'migrate', I recommend:
/etc/httpd/conf.d/z-owncloud-local.conf/etc/httpd/conf.d/owncloud.confln -s /etc/httpd/conf.d/owncloud-access.conf.avail /etc/httpd/conf.d/z-owncloud-access.conf (assuming you want to allow access from any host!).inc and .avail file(s)), always do customizations in override filesHappy Clouding!