Home Home > 2015 > 10
Sign up | Login

Archive for October, 2015

Proprietary AMD/ATI Catalyst fglrx rpms released for LEAP 42.1

October 31st, 2015 by

Since the last few months, we all know that the new openSUSE Leap 42.1 is on its road.

But fglrx drivers were missing. Even with the 15.9 release in September.


There’s really no warranties the drivers will work, for you!

If you are satisfied with the open-source radeon drivers, don’t risk to break your computer

All the trouble present in 15.9 will be there, like the failing gnome3 gdm start, see previous article from Sebastian, his scripts also available on the raw-src directory on the mirror, allow you to apply a quirk patch.

I’m considering the release of thoses rpms as experimental, they work for some, and sometimes are convenient. But they can also create kernel segfault on some configurations.
If you are in trouble start your openSUSE in rescue mode with nomodeset on boot line, and then zypper rm fglrx related packages, reboot and you should safely return to free radeon.


Today, while packing my stuff for the SUSECON15 in Amsterdam, I was pleased on irc to have feedback of users
who were able to run fglrx Tumbleweed packages on their Leap 42.1

I’ve then start a Leap vm and hack a bit Sebastian Siebert’s script for 15.9 to add support for Leap.
The drivers build, and install correctly. I’ve also updated the one-click installer for people using this

Leap being available only for x86_64 bit plateform, the driver follow the same available arch.

Links to the new repository openSUSE_Leap_42

Have fun!

Cleanup on OBS – Bacula packages to adopt

October 25th, 2015 by

I was one of the creator and maintainers of bacula packages on obs (Story started 4 years ago).
Since then (+3 years) I’m using another tool called Bareos, and have no more interest
nor time to maintain those packages.

Since sometimes, bacula project has released two main major version. (7.0 and 7.2).
Nobody has taken care of the packages available on obs Archiving:Backup, nor have
proposed an update. [1]

Those packages have never been submitted to Factory, and proposed to any released openSUSE version.
From one of the last upstream announcement Bacula project will deliver directly prebuild packages for major distributions.

So if you’re interested to take ownership of those, raise your hands now (ask maintainer status with obs interface).
I will let a grace period of one month before sending a delete request.

Have fun!

targitter project – about OBS, tars and git

October 5th, 2015 by

In OBS we use source tarballs everywhere to build rpms (and debs) from.

This has at least two major downsides:

  1. Storing all old tar files takes up a lot of disk space
  2. OBS workflows with .tar files and patches are rather different and somewhat disconnected from the git workflows we usually use everywhere else these days. E.g. for the SUSE OpenStack Cloud team we have a “trackupstream” jenkins job, that pulls the latest git version into a tarball once every day.

Fedora already keeps their metadata in git, but only a hash of the tarball.

So as one first step, I used two rather different projects to see how different the space usage would be. On the slow side I used 20 gtk2 tarballs from the last 5 years and on the fast side, I used 31 openstack-nova tarballs from Cloud:OpenStack:Master project from the last 5 months.
I used scripts that uncompressed each tarball, added it to a git repo and used git gc to trigger git’s compression.

Here are the resulting cumulative size graphs:

gtk2 size graph
nova size graph

The raw numbers after 20 tarballs: for nova the ratio is 89772:7344 = 12.2 and for gtk2 the ratio is 296836:53076 = 5.6

What do you think: would it be worth the effort to use more git in our OBS workflows?

Do we care about being able to reproduce the original tarballs? While this is possible, it has some challenges in differing file-ordering, timestamps, file-ownerships and compression levels.
Or would it be enough if OBS converted a tarball into a signed commit (so it cannot be forged without people being able to notice)?

Do you know of a tool that can uncompress tarballs in a way that allows to track the content as single files, and allows to later re-create the original verbatim tarball, such that upstream signatures would still match?