openQA.o.o is a machine running automated software tests all the time to decide if factory-tested can be updated. If you think, this was boring, you might find out that it is not, since every testrun generates a video of approx 4 minutes that can be conveniently viewed in firefox.

I have added testing of development repos, so that it is now possible to detect bugs before they even get into Factory (most of those tests have “devel” at the end of their name). In fact, this has already found two such bugs.

The test system’s hardware was upgraded with a sponsored SSD and the software adapted to allow running multiple tests in parallel (using make -j3)

I have updated the web-interface to use the nice Bento theme

And I found yet another cool use-case for automated testing: it allows to bisect bugs. I did a binary search in old results for a live-installer bug which made it really easy to find the causing commit. However, seeing how long such a bug went unnoticed, made me think, that it would be nice if more people would check the results for anomalies, since not all of those can easily be auto-detected. As this just needs a firefox and little time, this is pretty easy to do. Much easier than to actually setup a test-system in any case.

An IRC notification bot was added, keeping #opensuse-openqa updated with new test results

Then, I am looking for additional automatic test-scripts, that also work standalone on an openSUSE install. It is especially important to test high-impact things. Things that break often or block many users if they break. And it would be nice to have a small result range such as OK|fail|unknown or it should at least be mappable to such.

Jürgen Weigert has packaged sikuli, so it is easy to create GUI tests with it, that could then be included in the test-suite.

Then there are still some things on the ToDo list…

Hermes integration to get email alerts and RDF feeds for newsreaders

Have more test variants auto-scheduled (-live and -dup)

Find a way to have Add-On-Repos with custom priority (otherwise Factory packages might be used, as happened for kernel-default-2.6.37-rc7) – using linuxrc’s driverupdate feature could be one way.

Some brief updates about the ongoing work towards bringing Ayatana Project software into openSUSE:

1. Software Updates

Canonical recently released a batch of updates which bring new functionality (Indicators seem to respond faster now) and very nice improvements, some of them contributed by down-streamers. From my humble experience I would risk to claim that Canonical is doing an excellent job as an upstreamer. I’ve updated all packages to the latest versions. This allowed to remove some patches.

2. Unity

Unity is now one step closer. For Unity I’ve started to package Compiz git snapshots from the correct branches pointed by Unity documentation. This brought something new to me, cmake. I’ve done this very slowly, reading some docs meanwhile about cmake. My packaging around Compiz is mainly based on OBS X11:Compiz repository, so pretty much all the credits should be for the original project Packagers which done an awesome job. Currently I’m missing only 3 packages to test Unity. Recently with kernel and mesa updates some issues around ATI hardware seem to have fixed for openSUSE Factory users, which enabled in my case FireGL, therefore I can test properly Unity now and check for the integration into openSUSE.

Unity by default uses the Ayatana’s Indicators, and if they are not present, it will fallback to GNOME’s applets. This is very nice and I’m thankful Canonical made it this way. This brings non-Ubuntu users the Unity experience at almost no trouble, since there isn’t actually much patching required to implement Unity.

3. GNOME:Ayatana Repository

GNOME:Ayatana Repository will be populated during the next two weeks with the latest changes and will provide for the time being the Ayatana’s Indicators and Unity. I am currently working around libappindicator stack and it’s Indicators. Currently I’m testing the patches required on the GTK+ stack and this is pretty much the last barrier before going into #STAGE2, polishing and populating GNOME:Ayatana.

It’s not decided yet what packages are going to present on Factory. My wish is to push only Unity into Factory and it’s dependencies, this might not happen for 11.4 as I’m not sure about the freeze schedules and it might be too late already, but since we’re depending on Compiz upstream, we’ll see what happens. Even if Unity isn’t going to be available on Factory, I’m sure we can use KIWI or SUSE Studio to release a small openSUSE Unity Spin.

I’ve also decided that I (typo: previously would) wouldn’t like to see Unity available by openSUSE before the official release from Ubuntu, for which I wish all the success.

Since the very early start that I’ve been using pkg-config as much as I can. According to some information that I collected previously, this would be great for cross-distribution build. Depending on the time and work done, I might make the necessary modifications and enable cross-distribution building on this project, thus, making it available for other RPM distributions supported by OBS. This will require a bit of testing before, so it will be work to be done after 11.4 is released and during it’s lifecycle. Maybe by the time of openSUSE 12 gets released, we will have this project also available for other RPM based distributions. I have no knowledge on Debian packaging, but Ubuntu ships this software and Debian probably has it also available so… that won’t be a problem.

4. Artwork

I am providing on GNOME:Ayatana Ubuntu’s Light Themes (Ambiance and Radiance) and offering a patched version of Metacity that renders those themes perfectly. I’m not changing the original colors from the themes or modifying them in any way. So they might be a bit more of orange and not green.

I’ve contacted some people to ask if they would be willing to donate some artwork to make a small package with Wallpapers, some have answered yes, so I will make a small package with a couple of wallpapers for the traditional resolutions and distribute it alongside with this software as optional as always.

5. GTK2, GTK3 and QT

Implementation of GTK3 will be done within the next days, as I am also considering enabling QT support for KDE users (Indicators only for now).

That’s pretty much the result of the last days of work… more news to come in the nearby future.