Peter Czanik was caught in the middle of all of this at a recent FSF conference where he and others had an openSUSE booth. With no DVDs being shipped, due to the transition in the promo material shipping procedure (this has been announced) and no money available through TSP for local production of marketing materials due to a snafu (a temporary solution is in the works) there was basically no help from the resources where help should be coming from, sorry about that Peter.

Despite these obstacles Peter and the team showed up and made due with what was available to have great success. In Peter’s words:

“”"”
- distributed the last few remaining openSUSE 12.2 DVDs. Many people complained, that it’s not the latest and greatest, but also many were happy, as they have an old machine and older Linux versions usually have lower resource requirements.
- reused the posters we printed last autumn to decorate the booth (at the end of the day they were in a sorry state, so can’t be reused any more…)
- used the few remaining openSUSE brochures, stickers we printed last year (printing was contributed last year by somebody working at a printing company and our company printer…)

- used my ARM machines and a few borrowed mini PCs to demo openSUSE and make the booth eye catching (people asked about the machines and went away with openSUSE DVDs and brochures )

So, in short: last autumn we had local contributions from community members, this year we used what was last few bits of it and some creativity.

The good thing is, that I was told from multiple directions, that openSUSE had the best booth among software projects at the conference (and they did not know, that it was from a ZERO budget…).

The bad thing is, that we don’t have any marketing materials left. No DVDs, posters or brochures.

“”"”"

There is no need to rose color the situation, leaving community members trying to represent openSUSE at a conference stranded like this should not happen and there is no excuse for creating this situation in the first place. Work is proceeding to address these issue. However, I want to focus on the positive, and that is undoubtedly how determined Peter and the team were to make the conference a success and how they overcame the obstacles presented to them.

Thank you Peter and team fro being such dedicated representatives of our community and project. Also thank you for pointing out the shortcomings in our current transition period. This will allow us to address these, hopefully in short order.

As I mentioned, am am certain many of you have similar stories to tell. Thanks for your efforts as well.

I’m not going to osc13

Two days ago, I took the decision to not assist the certainly most fabulous openSUSE Conference next July in Thessaloniki.

A conjunction of several factors lead to that decision.
First what I regret was the chosen date. Damn July is the only expensive period to travel to Thessaloniki. The plane ticket never drop below the 800€ (hey! for sure I want to have Françoise with me), especially with the late announce of precise days. May, June, September would have been so cheaper…
I can understand the choice main sponsor SUSE do, and their need to spread osc and SUSECON at a 6 month delay in the year’s schedule, but sadly does not work for me this year.

Thessaloniki port

Another side, I already knew that a customer project will happen during that time-frame. As it concerns a lot of partner’s I’ve to take in account the availability of each of them. Unfortunately, after believing that it could be doable to free-up time for osc I decide to stop persecuting myself, and make a deal to live in peace and go ahead: no osc this year.

Maths have their say: statistically, more osc will be, more the chance to miss one will increase ( I know still not a real excuses)

I would like to share my deep apologizes to the whole Greek Community in charge of OSC13. You all know, how I was and still am a big found of your commitment and really appreciate each of you.
I will all miss you!

I really hope osc13 will stay in history as one of the ever greatest conference organized.

Don’t worry Thessaloniki, I know how great the place is, kind the people are, etc..
I’ll be back soon!

Αχ Θεσσαλονικη – Αντωνης Βαρδης

Factory is development version of openSUSE and it is where the next openSUSE is taking form. Hundreds of packagers send packages into Factory to be integrated as a part of the new release and many more use Factory for testing or for their daily work. Thus it is really important to keep Factory rolling and usable. Everybody knows that Coolo is the Factory master and he does everything to make next openSUSE be the best ever. But keeping factory in shape is really complicated and stressing task. There are dozens of request everyday and each one of them can potentially break something. So Factory can always use a pair of extra hands and for some time I have been one of them. I’d like to give you some insight in what we do, working on keeping Factory building and working.

Keep it building

With a constant influx of newer and cooler versions of libraries and tools it is easy to break existing applications with shiny new software. So we always have some build failures in Factory. Part of our job is to resolve them because if it doesn’t build, you can’t test nor ship it. As developer, you may have seen submit request in various projects in OBS fixing builds for Factory. Everyday I take a look at a number of build failures, investigate why they are not building in Factory and try to do something about it.

For example new version of the GNU C Compiler (GCC) is quite often more strict on includes, requiring developers to be more verbose about the exact internal and external libraries there applications require to be build. What used to build now doesn’t, because you are missing include files. The older GCC let you slip by, but now you have to fix it, build failure by build failure. Another example is GTK which keeps deprecating old API functions and you have to keep up and replace them with correct counterparts from the new API. Sometimes even the kernel changes API and third party modules stops building. All these errors will get eventually resolved upstream (if upstream is alive), but as we follow upstream quite closely before feature freeze, it may happen that we are first facing these issues because sometime we are the first ones who tried to compile this software using new GTK or the new GCC. Of course, we attempt to get these fixes back upstream and share them with other distributions where appropriate!

Image depicting the Factory Workflow

Test it

Another important part of working on a better Factory is testing. If everything builds, we’re happy. You might have heard the saying:

if it builds, ship it!

(un)fortunately, this isn’t Coolo’s idea of how the world works. In Factory, things not only have to build, but also work. Oh, AND conform to some stringent requirements. Here comes into play what most of our team was working on in the past months and what was described last week – openQA. openQA tests the latest builds of openSUSE Factory, tries to install them and run tests on some applications as well. But still, not all failures from automatic testing are real failures. Sometimes application just changed too much to be covered by test. So from time to time we go through failing openQA tests, try to reproduce them, figure out what went wrong and either fix it or report it via bugzilla to the corresponding maintainer.

Concluding

Each of these tasks is relatively small (check why this test failed, fix this package to build with new gcc) but what makes it hard is the number of packages we’ve got and the constant inflow of changes. Also, because the issue can be all over the place, each and every one requires you to dive into an entirely new package, with new and interesting quirks, build systems, languages and more. It is a great way of getting to know a wide variety of packages and applications, finding a gem every now and then. But also implies a lot of work.

Things will get slower and more stable after feature freeze when we will spend more time in the testing part, while today we mostly work on the build part. Still, Factory has to keep building, without that it becomes impossible to keep developing openSUSE. What we do, fixing these build errors, it might not be super visible, but it matters a lot.

Statistics

On a related note, we’d like to (re) introduce weekly Factory statistics! It has been a while since we had those, once upon a time courtesy of AJ and Guido. Now, Alberto provides them. Here you go, the top-fifteen contributors to openSUSE Factory last week (from Sunday June 2nd to to Sunday June 9th):

1. Dominique Leuenberger
2. Tobias Klausmann
3. Stefan Dirsch
4. Peter Varkoly
5. Stephan Kulow
6. Marcus Meissner
7. Michal Hrusecky
8. Cristian Rodríguez
9. Dirk Mueller
10. Sascha Peilicke
11. Kyrill Detinov
12. Dr. Werner Fink
13. Bjørn Lie
14. Tomáš Chvátal
15. Niels Abspoel

The last 12.3 release was important for the openSUSE team for a number of reasons. One reason is that we wanted to integrate QA (Quality Assurance) into the release process in an early stage. You might remember that this release had UEFI and Secure Boot support coming and everybody had read the scary reports about badly broken machines that can only be fixed replacing the firmware. Obviously openSUSE can’t allow such things to happen to our user base, so we wanted to do more testing.

Testing is hard

Testing a distribution seems easy at first sight:

1. Take the ISO of the last build and put it on the USB stick
2. Boot from the USB
3. Install and test
4. …
5. Profit!

testing in progress!

But look a bit further and you will see that, actually, only the installation process itself is already a combinatorial problem. In openSUSE we have different mediums (DVD, KDE and Gnome Live images, NET installation image and the new Rescue image), three official architectures (32 and 64 bits and ARMv7), a bunch of different file systems (Ext3 / Ext4, Btrfs, LVM with or without encryption, etc.), different boot loaders (GRUB 2, LILO, SHIM). Yeah… Even without doing the math you see that for only this small subset of variables we have hundreds of possible combinations. And this is just the installation process, we are not talking about the various desktops and applications or hardware like network interfaces or graphics cards here.

And we want continuous testing

And that is only the final testing round! If we want to be serious about QA and testing, we need to run the full test battery for every build that OBS generate for us, with extra attention to the Milestones, Betas and RC which are scheduled in the release road-map.

We can of course attempt to optimize our testing approach. For example, if I am the maintainer of a package and I sure that my last version is working perfectly in Factory (because I tested it in my system, of course), do I really need to test this application again and again when a new ISO build is released? Unfortunately, we can not take a shortcut here. As Distribution, our job is integration and so we need to test the entire product again for every build. A single change in an external library or in any other package which I depend on can break my package. The interdependencies for a integration project of the size of openSUSE are so intricate that is faster to run the full test again. With this approach we are avoiding regressions in our distribution, important during development. But also a lot of work – who has time for all this testing?

OpenQA as a solution

For us, there’s no doubt about it: openQA is the correct tool for this. openQA is already used to test certain parts of openSUSE, and has shown itself as a competent tool to test other distributions like Fedora or Debian.

To experiment with openQA, the openSUSE team decided to launch a local implementation of the tool and start feeding it with 12.3 builds. But we soon ran into some limitation in the way we can express desired test outcomes in openQA and we got ideas on how to improve the detection of failed and succeeded tests. We also discovered that some tests in openQA had the bad habit of starting to work in “monkey mode” by simply sending commands and events to the virtual machine without checking if those interaction have expected behavior or not, losing track of the test progress.

openQA has the great benefit of being open source so we can improve its usefulness for testing Factory. Moreover, the original author of openQA, Bernhard M. Wiedemann, is a very talented developer and works for SUSE so upstream is very close to us. So we decided to start hacking!

openQA work

After the 12.3 release we decided to spend some quality time improving openQA as a team project. This was managed using the public Chili (a Redmine fork) project management web application. We published all the milestones, tasks, goals and documentation in the “openQA improvement project”. The management side of this project perhaps needs a different post, but for now we can say that we tried to develop it as open as possible. Of course you can get the full code from the openSUSE github account.

Major changes

The main architectural changes implemented during our 10 weeks of coding on openQA can be summarized as follows:

• Integration with openCV
• Replacement of PPM graphic file format with PNG
• Introduced needles; test with better control of the state
• A proper job dispatcher for new test configurations
• Better internal scheduler, with snapshots and a way to skip tests
• Improvement in the communication between webUI and the virtual machine

The Needle editor in action

openCV brings robust testing

The tests in openQA need to check what is happening in the virtual (or real) machine to verify results, and the main source of information is the output of the screen. This information is usually a graphical information: we can instruct QEMU (or Vbox) to retry screenshots in a periodic basis. To properly evaluate a test outcome we need to find some kind of information in those pictures, and for that we use the computer vision library openCV.

With this library we can implement different methods to find relevant sections of the image, like buttons, error messages or text. These are then used for the test to get information about the actual environment of the installation process and to find out if the test passed or not. Previously, checksums on the images were used to determine outcomes. This led to many false positives (tests failing too often) due to simple theming and layout changes – a single pixel changing broke the test. openCV support was introduced earlier by Dominik Heidler to enable testing with noisy analogue VGA capture and we extended the usage of openCV matching to be more versatile, powerful and easier to use (both for test-module-writers and for maintainers).

Introducing needles

openQA has been modified to use PNG instead of PPM files to store images to test against, improving performance but also enabling openQA to store certain meta-data within the images. This brings us to the most important improvement in openQA: the introduction of the needle. A needle is an PNG image with some meta-data associated (a JSON document). This meta-data describes one or multiple ‘regions of interest’ (RoI) in the original image which can be used by the test to match the current screenshot. For example, if the installation is in the partition manager and we send the expected keystrokes to set Btrfs as our default file system, we can assert that this option is currently set using a needle where the RoI has the correct check box marked. In other words: we create a needle with an area covering the check box. The system will search this area in the current screen to assert that there is, somewhere, a check box with this label correctly marked. And will use openCV to make sure that slight changes in theming or layout will not result in a failed test.

The needle concept is really powerful. When a test uses needles with multiple RoI’s, the system will try to match every area in the current screenshot, in whatever position. There are areas that can be excluded, and areas that can be processed using an OCR (Tesseract) to extract and match text from them.

Thanks to needles we can now create tests that are always in a known state and they can inform complex decisions about the next step to take. For example, we can have tests that can detect and respond correctly when a sudo prompt appears suddenly, or where an error dialog appears when is not expected. More important, we can detect errors more quickly, aborting the installation process and pointing the developer to the exact error.

Faster testing with snapshots

Test result overview

We also implemented a way to create snapshots of the virtual machine status. This is useful if we want to retry some tests, or start the test-set from a specific test. For example, if we are testing the Firefox web browser, we want to avoid all the installation tests, and maybe some of the tests related with other applications. With this snapshot feature, we can load the virtual machine in the state where Firefox can be tested immediately.

Improved web UI

The final major area of focus has been on the web interface. We designed a set of dialogs to create and edit needles. Using this editor we can also see why the current tests are failing, comparing the current screenshot with the different expected needles from the tests.

Also, from the web interface we can control the execution of the virtual machine: signaling to stop or continue the execution. This is a feature that is useful when we want to create needles in an interactive way.

Upstream

We’re very happy that Bernhard has helped us, both with work and advice, to get these changes implemented. Several improvements were integrated in the current production version of openQA and most of the more invasive ones are part of the V2 branch of openQA. We plan to sit together with Bernhard to see about deploying V2 to openqa.opensuse.org for testing factory as soon as possible.

There is still work to be done. For example, for full integration testing we need to expand on the current ability which allows to run the tests on real hardware. This will for example allow testing graphics and network cards. Also, writing proper documentation is on the todo list. For those interested in helping out putting openQA to work and keeping the quality of our distribution high, the openSUSE Conference will feature a workshop on creating tests for Factory.

I discovered it 6 months ago, after starting to be more and more annoyed by the way the bacula’s community edition was driven and developed. Even if I was using it since version 1.32 … First of all, I wish to be clear and shout out my respect to all the work done by Kern on Bacula or any other contributor. We have a really nice working software. We even have a nice build packages for it on OBS.
But it’s stalled …

My personal frustration started with the creation of Bacula Enterprise, which has until now never (from what I’ve seen) reversed an Enterprise feature back to the community. Which in my sense would have been a clear statement & commitment from the Bacula Enterprise to the community.
A Free Software is free once it has been paid once. And more the time pass, more the community edition look like abandoned (windows client binary, bweb, …) Okay I can understand the enterprise’s edition arguments, the point is not there according to me.

So at the end of last year, I’ve started looking what else could replace Bacula for my own usage, and the small/medium customers I serve. Digging on github (my favorite source forge) I discovered bareos project. Basically Bareos is a fork of bacula community edition. With active contribution, and look like what I was looking for. Bareos is a compatible (at the time of writing) drop’in replacement which offers a bunch of nice feature I was waiting for. Especially high quality windows clients. The whole being cooked on a private obs instances, tested with jenkins, travis …

Okay I was disappointed about the fact it was a fork, but their website explains the why for those who wish to know.

I’ve then started to use it (easy to try with the number of supported platforms) and ready to use package. (Thanks to open build service [2]) Some installations were kept in a compatible way, other in native bareos way. The transition was really easy for anybody knowing how bacula works. After 3 months of production, including full restore, virtual machine backup, etc, I qualified it to be really production ready. Hey the base code and the way patches have been handled certainly explain those results. I also appreciate the effort to make bareos almost ready to use after installation. Trying to reduce the entry level ticket.

The remaining concerns I’ve found:
- The community behind will have to grow and success in a truly transparent way.
- Get new contributors (challenge is the same for bacula, but forking and propose request merge on github is really more cool than email patches)
- The full remake of the documentation (work in progress)
- Get a perfect web bconsole
My best hope:
- Make sustainable, the business plan associated with bareos.com and thus continue to produce quality community software

So did some of you already test it?
What’s your own feedback, your thoughts about it?

Regards.
[1] http://www.bareos.org
[2] http://openbuildservice.org

I think that it was a good request. The openSUSE Team at SUSE have been working on tasks that will bring some noticeable results for the project. But most of those tasks are not visible to many in our community. This blog can help mitigate that.

Team blog

The fact that much of what we have been doing lately is not very visible has a lot to do with the nature of our current focus. We felt there was a need for going back to basics in some areas, in order to re-structure them in a way that makes us stronger in the future. We have been planning (like the merchandising program), improving and building openSUSE tools (openQA, TSP site), focusing on the release and in short – preparing. This new approach reinforces the commitment SUSE has in openSUSE, not the opposite.

To communicate what we are working on, both in terms of planning as well as building and developing, we returned an idea we discussed several months ago, the creation of a team blog focused on describing our actions.

Changes

As you probably know by now, SUSE decided almost a year ago to make internal changes to better address new challenges around openSUSE. The openSUSE Team at SUSE is one of the results of such changes. Currently it is formed by Alberto Planas Domínguez, Ancor González Sosa, Christopher Hofmann, Ludwig Nussel,  Jos Poortvliet, Max Lin (temporary assigned to other department), Michal Hrusecky, Stephan Kulow, and myself. Another engineer will join us in July and we have two openings, a senior KDE developer and a graphical designer. Hopefully, together, we can make a real difference and get some great things done!

If you are interested in what we are doing we hope you enjoy reading this blog. We will put a sustained and collective effort on it the following months. There are other teams in openSUSE doing great things that will benefit from more visibility. We hope some of them follow our example!

Agustin Benito Bethencourt
openSUSE Team Lead at SUSE

Note: Comments on our blog will be moderated following the project Code of Conduct.

openSUSE Multimedia 32bit x86 based on openSUSE 12.3 with default desktop Gnome3 http://en.opensuse.org/openSUSE:GNOME_3.0

download :http://susestudio.com/a/haHwG8/opensuse-multimedia

Thanks to openSUSE Indonesia, KPLI Kendari

Instructions to run it are same as mentioned earlier. In addition to those you can also use LinuxonAndroid app with patched bootscript.sh. Replace /data/data/com.zpwebsites.linuxonandroid/files/bootscript.sh on your device with the patched one and follow the directions shown here(last 3 images):

openSUSE on android

Get it from here:Direct Download | Torrents | Metalinks | md5sum

As this edition is based on openSUSE 12.3, all the official 12.3 updates, repositories from build service and Packman can be used to install additional softwares and keep it up to date.

Minimum hardware requirement is 1GB of RAM and 15GB free disk space. Installation from USB stick will take about 40 minutes to complete, from a DVD it takes much longer. Check this howto for creating live USB stick on vfat partition or other GUI and terminal ways.

Here is the sampling of some of the softwares available on the iso. Complete list of packages with versions here.

This time, we also have an openSUSE Edu Li-f-e 12.3 64bit version in SUSE Studio – if you want to give it a try, just download the ISO image or log in and run the image via “Testdrive” in your local browser! (Please note that 64bit edition has not gone through rigorous QA.)

Test reports are always welcome – if you encounter any problems, feel free to contact us via any way mentioned in our wiki or write a bugreport.

Have a lot of fun…

Your openSUSE Education Team

Notice

This release concern only owners of radeon HD5xxx or above.
For older gpu, the fglrx-legacy is still 13.1, and thus didn’t work with Kernel 3.6, 3.7, 3.8 nor openSUSE 12.3 and xorg 1.13
SDB:AMD_fgrlx_legacy
Beware of that, and prefer the free open-source radeon driver which came out of the box from your openSUSE distribution.

Release note about 13.4

This Catalyst fglrx version support openSUSE version from 11.4 to 12.3 (new repository) and also Tumbleweed (thus also kernel 3.8x series).

Release Note

A release note is available on AMD website

Fixed issues

    [370253]: Serious Sam 3 - Color of Objects turning into be red when enabling separate shader object
    [371937]: Team Fortress 2 - Screen black issue while entering the game screen under cinnamon desktop environment
    [371374]: Team Fortress 2 - Screen random flickering and corruptions in Lakeside Map
    [354777]: Maya 2012 Benchmark - Benchmark falling out of TIMMO
    [372137]: NX8.0 - Severe flickering is observed while playing animation in manufacturing mode
    [373561]: Mari crashes at startup on Ubuntu only
    [374371]: Severe corruption occurs in Unigine Heaven 4.0 on Saturn XT when running at extremely high settings
    [373787]: Softimage fails to refresh properly
    [372918]: Maxon - Wrong shading when UBOs are used to store light parameters

 Known Bugs

    [373836]: Vsync application shows corruption filed
    [373772]: Team Fortress 2 – Game could not be loaded in “High Performance GPU” mode
    [373909]: Driver install via .deb package will cause OS desktop corruption
    [371372]: SCQA - Anti-Aliasing does not work

Sebastien Siebert making script

Sebastian Siebert post about 13.4

If you have any problems with the driver, don’t be afraid to report to Sebastian (German and English bugreports are gladly accepted).
he will try, as far as I am able to reproduce the bug. Together with the necessary system information, he will go directly to the right place at AMD to have the bug fixed in the next driver release.
Thank you very much, Sebastian.

See below what to do in case of troubles.

Or you can also ping him on irc (freespacer)

Quick overview

For openSUSE version 11.3 and above

Have a radeon hd5xxx and above
1. You have to use the standard fglrx
2. Use the new repository http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_VERSION
3. SDB:AMD_fgrlx

Have a radeon between hd2xxx and hd4xxx
1. You have to use the legacy fglrx version
2. Use the new repository http://geeko.ioda.net/mirror/amd-fglrx-legacy//openSUSE_VERSION
3. SDB:AMD_fgrlx_legacy

Note that legacy has not yet been updated, and so can’t be use on kernel 3.6+ (Tumbleweed, 12.3 or kotd)

or have a look at the previous article which describe also step by step the procedure
lizards.opensuse.org/?p=8888

Debugging troubles

I recommend in case of trouble the use of his script which can collect the whole informations needed to help you. then you just have to issue a simple commande in console to collect all informations, you can review them, and finally transmit them.
Check the website to get the latest.

su -c 'sh makerpm-amd-13.4.sh -ur'
The system report 'amd-report.txt' was generated.                                                                                                          [ OK ]
Do you want to read the system report 'amd-report.txt' now? yes/no [y/n]: y
Are you sure to upload the above-named system report to sprunge.us? yes/no [y/n]: y

The report was uploaded to sprunge.us.
   The link is:  http://sprunge.us/eMEB

Copy paste the link in the comment zone of Sebastian post

Mirror Statistics

Total Statistics

That’s all for this release, Pictures will follow once I’ve rebuild the 12.3 amd crash test computer