Home Home > 2009 > 02
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 February, 2009

{lizards,news,zonker}.opensuse.org updated to WordPress 2.7.1

February 26th, 2009 by

Our WordPress instances have been updated to the latest release.  For readers of {news,zonker,lizards}.o.o nothing should be different.  People blogging will now see a new and improved interface which should  “take fewer clicks and be faster”.  Full details are available at the WordPress blog

I’d like to say a big “THANK YOU” to Stephan Binner for his continued maintenance of these services and for the flawless update to the new version.  He drove this with some help from the Novell IS&T folks whom I’d like to thank as well!

openSUSE-like update repositories for third party projects

February 22nd, 2009 by

Starting with 11.0, the openSUSE-Education project hosts it’s own, separate update repository. This is our solution for the strategic decision not to use the openSUSE Build Service as repository for endusers but for development only.

So for production purposes, we always recommend to use our frozen repositories on http://download.opensuse-education.org/. But as “frozen” implies, the repositories there are frozen at the time, the openSUSE-Education team declares them as “Goldmaster” (which is the case for all except the 11.1 repo at the moment) – and no package update or changes happens for this repositories.

The openSUSE-Education team has relatively long development and testing cycles – but as everywhere, shi* happens, and so it might be that some of the packages in the frozen repository are broken or need a security fix. For this, we have created update repositories (for at least 11.0 and the upcomming 11.1 Edu-Release) which are disabled per default, but added to the system during installation of the openSUSE-Education-release  package. (Reason behind this decision: if an administrator installs openSUSE-Education in a school, he wants to “mirror” the update repositories and not point every client to the official ones. All a user has to do is to enable this update repository via YaST or via “zypper mr -e ‘openSUSE-Education Updates'”.

We’re using the “updateinfo.xml” file formal described in the openSUSE-Wiki. Currently, we’ve 5 package updates/fixes for 11.0 in the update repository – and this might grow over the time. The updates are shown in the current online-update-applets as “normal” updates like the openSUSE ones. Interestingly, the user can’t see if an update is from the official openSUSE or the openSUSE-Education update repository – even if we use a different “from” tag. Perhaps we have to “play” with the “release” or other tags: testing is needed as it looks like nobody tries this before…

Status russian mirrors

February 19th, 2009 by

Some times ago Russian and Ukrainian users noticed strange connection drops from Yandex. I can’t solve this problem, because I’m not Yandex employee.

Russian mirrors problems are mostly solved by introducing new mirror (Thanks to Yuri xnu!! Tsarev). This mirror have all openSUSE related stuff, 100 Mbit connection, 1Tb storage drive. After testing period now we can see that mirror is ready for main workload. So we adjust priorities and if you are try to access download.opensuse.org from Russian IP you should be redirected to this new mirror.

Due problems with foreign bandwidth we can’t serve Ukrainian users with Peter Poeml help we switch they directly to German mirrors.

If you have problems with Russian mirror accessing via download.opensuse.org please contact me directly. I’ll try to solve this

Why the Buildservice is currently not for endusers

February 19th, 2009 by

Everytime, when I hear people rendering homage to the openSUSE Build Service as “nice tool for endusers to get packages”, I’m a bit confused. From my point of view, the Build Service in it’s current state is not really usable for endusers.

Here are some reasons why:

  1. No displayed License before adding the repository (have a look at the Non-OSS or Education Repositories to get an idea how this works) – this might be important if people crash their hardware after adding a repository with special kernel modules without being informed about possible problems…
  2. No package groups called “patterns” – so people can’t get an easy overview about the various software areas a project provides (using YaST -> Software -> RPM Groups is not usable for me since someone decided to show just a plain structure there).
  3. No package translations (sometimes I like to see the Summary and Description of a package translated in my own language to understand the real area of application for this package).
  4. As the Repositories change over and over again (sometimes just because a dependend package in another project has changed), you need to download at least the metadata of a project again and again. For the Education repository in the Build Service this means: transfering 4MB of data each time you call “zypper”. Not really nice for people with a low bandwith.
  5. Endusers will “upgrade” their installed packages again and again – without knowing the real reason for this upgrade until they can have a look at the package changelog (hoping the developer has added some informations there). Not even the Factory distribution has this problem with automatic rebuilds (resulting just in increased release numbers) and no information for endusers why they had to download tons of MB each week…
  6. Real Packagers use their Build Service repositories for development and testing – so some packages will likely be broken during this phase – and just the packager knows when it will be really “stable”. (I’m talking about “real packagers” as I often see people using their home projects in the Build Service just to create an own repository containing packages they use – just by linking packages from other projects without any changes. But this is another topic…)

Projects like KDE or GNOME try to balance some of this problems by using the “publish disabled” option until they want to release a new version of their project. But this makes testing for developers and testers harder: with publish disabled, developers and testers can’t easily download and test new packages via the synced, public repositories – they have to download their packages via the API of the Build Service one by one.

With the upcomming releases of the Build Service, this will hopefully change. Up with 1.5 project admins can create a “full featured YaST Repository” for their projects covering the points 1, 2 and perhaps 3. But I think we also need more or less “frozen” repositories beside the current project repositories to cover 4, 5 and 6.

These “frozen” repositories should IMO be placed in separate directories (like the official openSUSE distribution directories) to make it clear to everyone that these repositories have an “enduser focus” and not a “developer focus”. This way, a project like KDE or GNOME could:

  • use the current repositories below download.opensuse.org/repositories as their “bleeding edge”  development repos for packagers and testers.
  • have a separate enduser repository with additional features like patterns and translations using the “ftp tree generation” feature.

…and thats the reason why the summary of this blog contains the word “currently” – I think the Build Service is on a good way to be a really good solution for developers and endusers. But we should find a final solution for the open issues mentioned above before we point endusers to this tool.

How developers see openSUSE

February 19th, 2009 by

You probably know that a lot of openSUSE developers are sitting in the SUSE office in Prague, Czech Republic. They are also openSUSE users.

The whole story started by a flame on a mailing list why some of us are not happy with the current state of openSUSE. It turned out there is a lot of different issues. So, we’ve met on a raining winter Friday 3 weeks ago to collect those issues as well as things that people consider to be good about openSUSE.

The result of the hours-long discussion is a list of positive and negative things about openSUSE, very subjective view of the group of developers in Prague. Go, look at the list. There is a lot of problems that I personally see lurking in our community, spelled out loud. The range is wide, from basic community issues to very technical problems that are basically missing features in the distribution.

So, we have collected the feedback. But the question is, what to do with it?

Firstly, I believe the lists are great food for thought. You might not agree with everything, but still, there is some truth in it. At least, those are problems that people consider important enough to try to solve them – encouraging.

Secondly, consider this blog as call for contribution. If you believe some of the areas are really worth improving, get in touch with people listed on the wiki, improve the description  in the wiki, propose solutions. One restriction though – please, do not add additional items to the page. We want to keep the ideas where they belong – features eventually to end up in openFate, project-related problems on the mailing lists, …Also, this is not a general list of issues the openSUSE project needs to address. As I’ve written above – the page is a subjective view of a group of people. If you think we need a more general approach, please, bring the idea on openSUSE mailing lists.

Looking forward to your feedback!

Why Ant Sucks (Somehow)

February 16th, 2009 by

What is Ant?

According to Ant’s webpage:

“Ant is a Java-based build tool. In theory, it is kind of like Make, without Make’s wrinkles and with the full portability of pure Java code.”

Sounds nice, isn’t it? But XML design problems make Ant nearly unusable which this post becomes kind of a rant…


Writing first YCP program

February 13th, 2009 by

Hi folks!

It was a long time since my last blog. 😉

Today, i will show you my first program, it`s a simple test program which shows basic functions of YCP

Let`s start!!

first of all, you need all core development YaST and QT packages

(All mentioned bottom steps, can be made with normal user )

second , you must create a  symlink to /usr/lib/YaST2/bin/y2base

$ ln -s <destination> <linkname>

(In my case name of symlink is y2base.)

third , you need two console`s , one for program writing and one for monitoring .y2log (where you can see all debug messages)

if you wish more detailed debug output during root session, than type in console following :

$ su

$ export Y2DEBUG=1

$ exit

(switching back to normal user)

Ok, lets see the code of PushButton.ycp !

// Build a dialog with one button and two labels.
// Wait until that button is clicked,
// then close the dialog and terminate.

UI::OpenDialog( `VBox(
`Label(`opt(`boldFont),”PushButton TEST!!!!!!!!”),
`PushButton( “&OK” ),
`Label(`opt(`boldFont),”JUST SIMPLE TEST”)



$ chmod 765 PushButton.ycp

After you have written the program  , type in the console:

$ ./y2base ./PushButton.ycp qt

You will get following window:


What is amazing at YCP, that this code can be interpreted into ncurses

Try following command:

$ ./y2base ./PushButton.ycp ncurses


You have written only one code , which can be used in two different gui environments graphical and  text mode!

In my next blog i will write about creating own SCR Agent.

Zypper: Improved bash completion and practical usage

February 12th, 2009 by

Because no one reported any bugs to perl-Bootloader, I have some free time. I use it to improve bash completion for zypper, because I find current one have some really annoying things. In short now completion work also for zypper global options, hint also for short version of commands and help name of repo, service and lock, if you use command which takes that as argument. Next few paragraphs contain practical examples how it help improve your command line productivity, how to get it to your system and also some notes how I implement it. (more…)

Product Creation with the openSUSE Build Service

February 11th, 2009 by


First of all, what is a “Product”? The openSUSE Wiki has the following statement on the Product Definition Article:

“A product is a defined set of packages plus extra information”

In the most simple interpretation this means a set of RPM files plus a set of metadata which contains the installation kernel, information about the installation work flow, hardware detection, languages, licenses, slide shows and the like.

Thus the most simple product imaginable is a basic set of RPM files for the system to be installed and a minimum set of metadata: an installation system consisting of kernel, initrd and the packages necessary for installation.


Font: Lavoisier

February 11th, 2009 by

I’m very intersted in typography and as such also in fonts. Some days ago, I’ve found a very interesting sans-serif OpenType font, called Lavoisier. It is rather complete, with lots of characters, diacritics and other useful symbols.