Home Home > Distribution
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for the ‘Distribution’ Category

Proprietary AMD/ATI Catalyst fglrx 13.12 (13.251-3) rpm get a new build release

January 27th, 2014 by

Just a small note about a new build (-3) of the 13.251 fglrx version.

Changelog

AMD has changed /etc/ati/amdpcsdb.default database in its tarball

The packages have just been published on geeko.ioda.net, so next time you zypper up the new build should appear as a proposed update

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 openSUSE 12.3 or above.
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.
For 12.3 and especially 13.1 the free radeon often offer a better experience than the old fglrx-legacy.

Have fun!

openSUSE Education Li-f-e 13.1 x86_64 with UEFI boot support

January 21st, 2014 by

openSUSE Education Li-f-e 13.1 x86_64 with UEFI boot support is now here. Create bootable USB stick using dd_rescue, dd or Imagewriter GUI, select UEFI USB at boot device selection and make sure that GRUB2-EFI is selected under Bootloader in final installation summary screen. Select normal GRUB2 for legacy boot(machines without UEFI boot support).

Li-f-e x86_64 is mostly identical to i686 edition, selection of packages and versions will differ a bit.

Download

Unterstanding the nvidia driver process

January 15th, 2014 by

Nvidia pic from Muktware
The NVIDIA drivers for openSUSE 13.1 took a while to appear. Many users have asked why this was and we’d like to explain what happened and what we plan to do to prevent this in the future. This post was written with input from the openSUSE developers who maintain these drivers at SUSE and work with NVIDIA to make them available for our users.

How it should work

Legally, the Linux kernel GPLv2 license leaves proprietary binary drivers in a bit of a tangle. While some claim it should be OK, others say not – and that is what most distributions currently assume: one can not ship a Linux distribution with proprietary, binary drivers. NVIDIA has agreed that our users can grab their drivers from the official NVIDIA servers. They are packaged by SUSE engineers however. They take care of both SLE and openSUSE proprietary driver packaging for NVIDIA hardware, and have contacts at NVIDIA who get the drivers up on their ftp mirrors.
Nvidia-1click
The packages are build on a dedicated system, but the package spec (skeleton for building) is in OBS – for example, G03 is here. Anybody could use these to build the nvidia driver locally (the nvidia binary driver is grabbed from the nvidia driver during building). The command sequence for local building can be found in the README.

Once the packages are build, they are send to NVIDIA, which signs the packages with their key and generates and signs repositories, making them available to the public.

To note is the fact that this is all manual and takes a while on NVIDIA’s side (and ours). This of course is part of the reason why we don’t offer NVIDIA packages for Factory, our fast-rolling development repository.

What happened

What occurred for 13.1 is a typical case of “everything went wrong”.

Up until a few weeks before the release, the driver did not build against the Linux Kernel version 3.11. NVIDIA warned against the use of a patch for this problem created by third parties so the driver team did not have a running build. Due to a holiday, it took a while to get the packages build and pushed to NVIDIA. Unfortunately, by the time this was done, the holiday period at NVIDIA blocked progress for another week. Once the package was signed, it took the webteam at NVIDIA another week to get the repository published. It all added up to almost a month and brought quite some inconvenience for users eager to use their latest NVIDIA cards with the latest openSUSE.

About a week later, the openSUSE 13.1 NVIDIA drivers disappeared again from the nvidia servers for a day or so. We don’t know exactly what happened there, it might have simply been a server issue.

What we will do

The first and most obvious thing to change would be to improve coordination. The developers taking care of the NVIDIA packages should be made aware as early as possible about the release planning and a replacement in case for holidays should be available. We noted this in our 13.1 release report and will make sure that there will be a task in our task tracker for this for the next release. We also need to talk to NVIDIA about this to make sure that there, too, somebody can fill in for SUSE’s contacts.

But there are also thoughts on how to improve further. Some of the current ideas:

  • To get drivers for Factory the process needs more automation as the driver may break on kernel or X changes
  • We could try to open the process and work with community members to secure the process in case the SUSE folks are unavailalbe
  • It would be nice if we could make NVidia to see benefit of working more on the driver in openSUSE, e.g. by doing some testing
  • We could write some scripts that check regularly whether repo and packages are still available and in a valid state (meta data matches available RPMs)

We’ll have to see which of these we can implement, when and how. But rest assured that we will do what we can to prevent this in the future!

statistics with Geeko inside

And the stats!

After a bit of a hiatus, we’re back with the numbers. Development has slowed down around new year and isn’t back to speed yet so the 10th spot is shared by quite a big group of people…

Spot Name
1 Stephan Kulow
2 Denisart Benjamin
3 Tomáš Chvátal, Dirk Mueller, Michal Vyskocil
4 Hrvoje Senjan
5 Ciaran Farrell
6 Petr Gajdos
7 Lars Vogdt, Pascal Bleser
8 Jan Engelhardt, Charles Arnold
9 Andreas Stieger, Michal Marek, Niels Abspoel, Kyrill Detinov
10 Dinar Valeev, Bjørn Lie, Ulrich Weigand, Tobias Klausmann, Marcus Meissner, Alexander Graf, Robert Schweikert, Martin Vidner

Announcing openSUSE Education Li-f-e 13.1

December 17th, 2013 by

Get Li-f-e from here : Direct Download | Torrents | Metalinks | md5sum

openSUSE Education community is proud to bring you an early Christmas and New Year’s present: openSUSE Education Li-f-e. It is based on the recently released openSUSE 13.1 with all the official online updates applied.

We have put together a nice set of tools for everyone including teachers, students, parents and IT administrators.  It covers quite a lot of territory: from chemistry, mathematics to astronomy and Geography. Whether you are into software development or just someone looking for Linux distribution that comes with everything working out of the box, your search ends here.

Edit: We now also have x86_64 version supporting UEFI boot available for download.

(more…)

Discussing about the future of openSUSE

December 11th, 2013 by

This week, the openSUSE team blog is written by Agustin, talking about the proposals the team has done for openSUSE development.

A few months ago the openSUSE Team started a journey that achieved an important milestone last Tuesday, Nov 26th 2013. We have worked on creating a picture of relevant areas of the project in 2016 together with some of the actions we think should be taken during the following months to achieve it. To stop working and raise your head once in a while to analyze what is around you and setting a direction is a very good exercise.

The process we followed

The first step was working on data mining. After many hours of analysis, we identified some clear trends that helped us to establish a solid starting point to begin to work with. Once that phase was over (this is an ongoing process, in fact), we worked for a few weeks/months in trying to define that future picture interviewing several dozens of people. We refined that first attempt through several iterations, including many of those who participated in the original round and others who didn’t. Susanne Oberhauser-Hirschoff was the person who drove that process with Agustin.

We soon realized that discussing high level ideas in a community used to “Get shit done” was going to be easier if we complement them with some more down to earth proposals, specially in technical aspects. We cannot forget that, after all, openSUSE is a technical (and very pragmatic) focused community.

So, in parallel with the already mentioned refinement of the big picture, we started discussing within the team the actions needed to take to make the big picture a reality, the openSUSE development version a.k.a Enhanced/New Factory. After many hours of (sometimes never ending) discussions, we agreed on the ideas we are currently being published, together with the motivations behind them.

Another aspect we tried to bring to the discussion has been a strong dose of realism, trying to ensure that whatever we came up to was compatible with the nature of the project. We have also put focus on making sure that the initial proposal is achievable. So as part of community, we understand very well we cannot succeed alone. We need to work with you. So we just opened with the community a process analogous to what we went through within the team. It might be different in form but similar in principles and goals.

What are we going through these days?

These days the proposals are being discussed in different mailing lists. We are collecting feedback, discussing it, summarizing it, adapting the proposal to it … trying to reach agreements before defining what to do next.

What the proposal looks like?

We divided the proposal in a series of smaller proposals we are publishing in the project mailing list, where the general community topics in openSUSE are discussed, and/or factory ML, where the more technical discussions take place.

  1. openSUSE 2016: taking a picture of openSUSE today
    This mail summarizes the analysis phase we went through. We have tried to provide a simple picture of openSUSE today so the following articles can be justified to some extend.
  2. openSUSE 2016 picture
    This text summarizes the proposed picture for the end of 2016 (in three years). The goal is to set a direction for openSUSE

  3. openSUSE Development Workflow

  4. O Factory – Where art Thou?
    Stephan Kulow summarizes the Action Plan for the first aspect pointed in the previous picture: the new Development process (Factory).

The following articles describe in more detail some relevant (also new) elements pointed in the previous article, since they are new or modify the current process significantly. Some of the articles are in the queue to be published.

  1. One of the options for staging projects
    In this mail Michal Hrusecky provides some details and examples on how the new staging projects might work in the future.
  2. openQA in the new proposal
    This text, written by Ludwig Nussel, explains the principles that should drive the inclusion of openQA in the Factory development process, according with the proposed workflow.
  3. Karma for all
    This mail, written by Ancor González, summarizes our ideas to include a social feature in the process to help achieving Factory goals.
  4. Policies, or why it’s good to know how to change things
    The new process needs to be adaptive. Antonio Larrosa proposed a way, taking what other projects do in this regard as reference.

There might be an eighth article describing some smaller, still relevant, ideas. After publishing the “content”, we will release one last article providing a information about how to achieve these ideas, describing also our compromise in terms of effort and pointing out the challenges we perceive in the plan from the execution point of view.

We would like to invite you to the debate if you haven’t raised your opinions yet.

Only for the brave, Proprietary AMD/ATI Catalyst fglrx 13.10 BETA2 (13.20.11-1) rpm released

October 6th, 2013 by

Only for the brave, Proprietary AMD/ATI Catalyst fglrx 13.10 BETA2 (13.20.11-1) rpm released

Notice

This release concern only owners of radeon HD5xxx or above. And adventurous users who know how to deal with troubles.
The majority could easily wait the final release, expected somewhat later even if it take a long time 🙂

This is experimental & BETA software, it could fix issues you encountered, but also can eat your kittens. You’ve been warned !
flgrx build for 3.11 series kernel ( Tumbleweed & 13.1 ).
But this time I’ve to update the Sebastian script myself, so I consider also the package as beta stage.

Installing the new repository

Admitting you’ve the normal repository named FGLRX, (use zypper lr -d to find the number or name you give it). You have to start by disabling it
so you could fallback to it quickly. Open a root console or add sudo at your convenience and issue the following command:

zypper mr -dR FGLRX

The beta driver is available for 11.4 (evergreen kernel), 12.1, 12.2, 12.3, 13.1, Tumbleweed (12.3 based + kernel 3.11) at amd-fglrx-beta

To add another repository in the same console as root issue the following command which will install normally the right repository for your distribution

zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/mirror/amd-fglrx-beta/openSUSE_`lsb-release -r | awk '{print $2}'` FGLRX-BETA

If you are using Tumbleweed use this one

zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/mirror/amd-fglrx-beta/openSUSE_Tumbleweed FGLRX-BETA

Now the update/upgrade process

zypper dup -r FGLRX-BETA

Let the system upgrade the package, and try to enjoy the new beta

(more…)

New Raspberry Pi Image

September 7th, 2013 by

update: new image with kernel-3.6 and minimal X11/icewm http://www.zq1.de/~bernhard/linux/opensuse/raspberrypi-opensuse-20130911x.img.xz (103MB)

We got a new armv6 based image for the Raspberry Pi.
This one is only 82MB compressed, so pretty minimalistic.
http://www.zq1.de/~bernhard/linux/opensuse/raspberrypi-opensuse-20130907.img.xz

The exciting new thing is that this was created using an alternative image building automatism which I wrote from scratch in three hours this morning.
The scripts can be found at
https://build.opensuse.org/package/show/devel:ARM:Factory:Contrib:RaspberryPi/altimagebuild
and are also embedded within the image under /home/abuild/rpmbuild/SOURCES/

This means that everyone can now easily build his own images the way he likes and even branch and do submit requests for changes that are useful for others.
The way to use this is simple.
If you have 6GB RAM, you can speed things up with export OSC_BUILD_ROOT=/dev/shm/arm before you do
osc co devel:ARM:Factory:Contrib:RaspberryPi altimagebuild
cd devel:ARM:Factory:Contrib:RaspberryPi/altimagebuild
bash -x main.sh

This pseudo-package does not easily build within OBS or osc alone because it needs root permissions for some of the steps (chroot, mknod, mount), which could only be workarounded with User-Mode-Linux or patching osc.
The build consists of three steps that can be seen in main.sh:

  1. First, osc build is used to pull in required packages and setup the armv6 rootfs.
  2. Second, mkrootfs.sh modifies a copy of the rootfs under .root to contain all required configs
  3. And finally, mkimage.sh takes the .root dir and creates a .img from it that can be booted

This can build an image from scatch in three minutes. And my Raspberry Pi booted successfully with it within 55 seconds.

There are some remaining open issues:

  • the repo key is initially untrusted
  • still uses old 3.1 kernel – solved
  • build scripts have no error handling

Compared to the old image, this one has some advantages:

  • It is easier to resize because the root partition is the last one
  • Compressed image is much smaller
  • Reproducible image build, so easy to customize
  • It is armv6 with floating point support, so could be faster
  • We have over 5200 successfully built packages from openSUSE:Factory:ARM
    so for example you can install a minimalistic graphical environment with zypper install xauth twm xorg-x11-server xinit and start it with startx

So if you wanted to play with openSUSE on RPi, you can do so right now and have a lot of fun.

More on Statistics

August 23rd, 2013 by

Shortly before the openSUSE Conference, we featured a post about openSUSE statistics. It mostly talked about where we got the numbers, teasing that we’d share the details at the openSUSE Conference. And Alberto did. Today we’ll bring you the numbers Alberto did digested in images and text.

Downloads and users

The simplest statistics for a Linux distribution are of course the numbers of downloads and users, so let’s start there.

ISO downloads

The methodology used to count downloads is easy to understand: we count every IP address that hit the server or is redirected to one of the mirrors, and express the intention to start downloading one of the ISO images available for the distribution. In this way, we count independently every download that uses the same proxy and every different product downloaded by the same IP. We can group the downloads by weeks or by month. In both images we can see that we started counting in 2010 and we covered openSUSE 11.0 to 12.3. Also, in both graphs we can see what events explain the peaks, like the release of the distribution.

Downloads per month

Downloads per month

Downloads per week

Downloads per week

To make a more detailed analysis we need to concentrate on the monthly graph. For this plot we calculated a linear regression model using the monthly data (41 samples). In the graph you can see a slight growth but decreasing impact of releases. Extrapolating, we can expect about 560K downloads per month in 2014. Note that this is downloads, not installs! Let’s talk about those next.

Installations

To get a more reliable estimation of persistent installations we count systems that regularly update. A count of the encountered unique systems per week or per month is a fair estimator of the number of active installations (see details on the counting).
updates per month

updates per week

Updates per week

Here you see many interesting things. For example, the red trace on top of the plot in 2010 and 2011 are Factory users. If you look closely, you also see that usage of a particular version already starts before it is out – that is due to testers checking out milestones, Beta and RC versions. And you notice how long it takes some users to move over to new versions of openSUSE – not only has over half of our users not moved to the latest 12.3 yet, but about 140.000 users happily still run releases from before 12.2, most of which (except 11.4) receive no security updates!

When we plot a linear regression model on this data, we see a less encouraging picture compared to the downloads: on average, we lose around 300 users per month. On the size of our installed base this is not huge, but worrying nonetheless.

More data

There are more things that we can learn from the data. We can analyze the behavior of users according to the installation medium or the architecture used and in time we can perhaps analyse how repositories are used and which are popular.

Medium and Architecture per week

Medium and Architecture per week

The Open Build Service

The Open Build Service is what openSUSE uses to build and distribute packages. It is a very integral part of our infrastructure and how we work, and its server logs contain a wealth of information on the work done on openSUSE. For example, mining the list of Submit Requests that go into Factory and devel projects, we created the graph below to give an idea of the development of the number of contributors working on openSUSE, with the total (blue) per month going nicely up as you can see.

OBS Contributor Data

Social media

Thanks to the help of Athanasios-Ilias Rousinopoulos (that is a link to his presentation at oSC13) we’re regularly gathering statistics on our social media, a summary you can see in the graph below. Yes, we’re doing well getting our message to people, thank you all for your part in that!

social media data

Let’s compare: openSUSE vs. Fedora

Numbers are useless if you can’t compare. We searched for data from other distributions like Ubuntu, Gentoo, Arch or Debian, but only Fedora provides real numbers with the methodology used to generate them. Kudos to our friends at Fedora for being open and transparent!

Now, they use a different way of gathering data on downloads: counting the number of different IPs seen per day. To count users, they count the number of different IPs seen for this release since the release date. This complicated matters on our side but we’ve made it work. However, one variable was a bit harder: both distributions have different release cycles and dates. As you see in the graphs, we tried our best to make the comparison as direct as possible. The plots below are in the same scale of time and number of downloads.

openSUSE and Fedora Users

openSUSE and Fedora Users

openSUSE and Fedora Downloads

openSUSE and Fedora Downloads

As you can see, Fedora has more downloads than openSUSE. Looking at the users, the situation is reverse: openSUSE has quite a bit more users than Fedora according to this measurement. How is this possible? The explanation is most likely that most openSUSE users upgrade with a ‘zypper dup’ command to the new releases, while Fedora users tend to do a fresh installation. Note that, like everybody else, we’re very much aware of the deceptive nature of statistics: there is always room for mistakes in the analysis of data. To at least provide a way to detect errors and follow the commendable example set by Fedora, here are our data analysis scripts in github.

statistics dister inside close-up

Contributor Statistics for week 33

All these statistics and still we’re not done! Here is the top-10 of contributors to Factory last week. As you can see, Stephan ‘Coolo’ Kulow is on vacation, freeing up a spot in the table 😉

Spot Name
1 Raymond Wooninck
2 Dominique Leuenberger
3 Sascha Peilicke
4 Hans-Peter Jansen
5 Bjørn Lie
6 Dirk Mueller
7 Ladislav Slezak
8 Ismail Donmez
9 Stefan Dirsch, Jan Engelhardt
10 Hrvoje Senjan

Proprietary AMD/ATI Catalyst fglrx 13.8 BETA1 (13.20.5-1) rpm released

August 15th, 2013 by

Notice

This release concern only owners of radeon HD5xxx or above. And adventurous users who know how to deal with troubles.
The majority could easily wait the final release, expected somewhat later.

This is experimental & BETA sofware, it could fix issues you encountered, but also can eat your kitten. You’ve been warned !
But good reports have been collected around, especially with never 3.10x kernel series.

Installing the new repository

Admitting you’ve the normal repository named FGLRX, (use zypper lr -d to find the number or name you give it). You have to start by disabling it, so you could fallback to it quickly. Open a root console or add sudo at your convenience and issue the following command:

zypper mr -dR FGLRX

The beta driver is available for 11.4 (evergreen kernel), 12.1, 12.2, 12.3, 13.1, Tumbleweed (12.3 based + kernel 3.10) at amd-fglrx-beta

To add another repository in the same console as root issue the following command which will install normally the right repository for your distribution

zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/amd-fglrx-beta/openSUSE_`lsb-release -r | awk '{print $2}'` FGLRX-BETA

If you are using Tumbleweed use this one

zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/amd-fglrx-beta/openSUSE_Tumbleweed FGLRX-BETA

Now the update/upgrade process

zypper dup -r FGLRX-BETA

Let the system upgrade the package, and try to enjoy the new beta

(more…)

Keeping Factory in shape

June 13th, 2013 by

Michal Hrušecký has been helping out on maintaining Factory in shape and shares his experiences.

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. (more…)