Home Home > 2013 > 04
Sign up | Login

Archive for April, 2013

Proprietary AMD/ATI fglrx 12.104 Catalyst 13.4 rpm released

April 29th, 2013 by

Proprietary AMD/ATI Catalyst fglrx 13.4 (12.104-1) rpm released


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
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)


Apache Subversion 1.8 preview packages

April 15th, 2013 by

RPM packages of what will become Apache Subversion 1.8 fairly soon are now available for testing on all current releases of openSUSE and SLE 11.

Note that in this release, serf will replace neon as the default HTTP library, to the extend that the latter is removed completely. I wrote about ra_serf before and added support for it in recent packages. You can test this now with either 1.7 or 1.8 if you are concerned about performance in your network. Please note that for servers running httpd and mod_dav_svn, increasing MaxKeepAliveRequests is highly recommended.

Update: Apache Subversion 1.8 is now released. You can find maintained packages via the software search in the devel:tools:scm:svn project. This will be part of the next release of openSUSE.

hackweek9: Lightweight KDE Desktop project

April 11th, 2013 by

It’s Hack Week 9 at SUSE, and I’m working on a cracking project this time around. I’ve codenamed it ‘KLyDE’, for K Lightweight Desktop Environment, and it’s an effort to point KDE at the lightweight desktop market.  Surely some mistake, you say?  KDE and lightweight kan’t fit in the same sentence.  I think they can.

This project has been bouncing around my head for a couple of years now, starting on a train ride back from the KDE PIM meeting in Osnabrück in 2010, then I presented it at COSCUP 2012 in Taiwan last August. But work commitments and family always got in the way of completing/finishing it.  SUSE’s hack week gives me 40 hours to throw at it and this time I wasn’t going to tackle it alone, so I enlisted my bro(grammer)s Jos and Klaas.

As has been repeated on Planet KDE over the past decade, KDE is not intrinisically bloated.  At its core, it jumps through a lot of hoops for memory efficiency and speed, and is modular to a fault. But most packagings of KDE take a kitchen sink approach, and when you install your KDE distribution you get a full suite of desktop, applets and applications.  The other major criticism of KDE is that it is too configurable.  The KlyDE project applies KDE’s modularity and configurability to the challenge of making a lightweight desktop.  However, what I don’t want to do is a hatchet job where functionality is crudely chopped out of the desktop to fit some conception of light weight.

We’re approaching problem from 3 sides:

Minimal footprint

The first method of attacking this is by packaging. It involves factoring optional components of the KDE desktop out of the base installation into subpackages that the main packages only have weak dependencies upon, allowing a minimal installation without them.  This targets big lumps of ram/cpu usage and objects of user hatred like Nepomuk and Akonadi, but also smaller items like Activities and Attica (social desktop support) and non-core window decorations/styles/etc.  The actual KDE build includes everything; the optional components are always available, so those who do need one of them can just add the package and start using it.

The second approach is by configuration.  This allows different profiles of KDE desktop with the same installed packages.  We’ve collected sets of configs that represent these profiles, but I’m not entirely sure how to package this yet.  One way would be to ship default profiles as X sessions.  Another would be a first run wizard or KCModule so users can select profile and apply it to their configuration after login.

Simple config
Is a mixture of usability and perception.  A simplified configuration presents fewer choices and is therefore easier to understand.  It also looks faster and more lightweight, because people equate visual simplicity with efficiency.  This is incorrect, of course, but I’m not above exploiting this fallacy to give people what they want. For this aspect, we’re providing an alternate set of System Settings metadata to give it a cut down tree.  The full set remains available, if needed.

Fast startup

Is the most high-risk-for-reward effort.  It’s mostly a perception/first impression thing.  A working desktop shouldn’t need to be started up all the time.  But for people trying out KLyDE for the first time, a fast startup supports the claim to minimalism.  The interesting thing I note so far is that the package splitting and configuration in 1) makes very little different to startup time.  The optional components of KDE are already highly optimised to not affect startup time.  So I’m investigating alternate startup systems; refactoring startkde, Dantti’s systemk, Plasma Active’s startactive, and a systemd-managed startup.


The packaging effort is mostly done; we have packages in an Open Build Service project, that give you a bare Plasma Workspace when installed on top of a minimal X SUSE 12.3 installation with –no-recommends.

Jos has put a great effort into understanding System Settings and has produced a simple layout, I just need to complete my patch to allow it to use the alternative metadata scheme at runtime.  If we have time, we’ll also customise some KCMs to provide a simple way to control KDE’s theming.

I’ve been busy converting systemd, kdeinit and ksmserver into a native systemd startup by defining systemd unit files.  It’s a steep learning curve as it exposes a number of assumptions on both sides, but I’m getting there.  The unoptimised systemdkde.target starts up in 4s here, vs 6s for the same .kde4 started by startkde.  That might be due to legacy/fault tolerance parts of startkde being left out, so I won’t give more detailed numbers yet.

Next steps

You can see the state of the project on Trello. I’d like to see if there is a startup time  win by parallelizing kded and ksmserver starting modules and apps. I’d like to make an openSUSE pattern for existing installations, and an iso or a disk image for testers.  I’ve also submitted a talk on the subject for Akademy, so I’d like to work on that and get some real data to support this work.


Tidy home, tidy Build Service

April 6th, 2013 by

Anyone using the Open Build Service in the last couple of weeks will notice how hopelessly overloaded it is.  I blame the ARM lads ;).  But there is something that we should all do as responsible community members: delete or disable your old stuff.

I’ve just spent 15 minutes going through my Open Build Service home:wstephenson project, deleting unfinished works in progress, finished branches that were never deleted, inherited repositories in branched projects that aren’t relevant to the tweaks I’m making, and I think I’ve saved about 100 repositories for the OBS scheduler to recalculate and look at publishing.

Time for you to spring clean too?