• Configuration file (.zypperrc).
  
• Nice overall install progress.
• Much improved install summary (options to view version/vendor/arch changes, changelog, ...).
• More options to handle patterns (remove, install suggested, ...).
  
• Advanced media error handling with options like eject DVD drive, select DVD drive, edit failed URI, enable/disable medium specific options.
• Fixed or removed zypper shell (can it be useful enough to be worth to maintain it?)
  
• Interface to new libzypp functionality like 'download only'.
• and more...
  

I am using Kubuntu in Vmware just to play arround with it, so I decided to upgrade from 7.10 to 8.10, and this means that I will have as well KDE4. The upgrade process has been very easy, but I needed to upgrade first to 8.04 and finally to 8.10, so, here are the steps:

7.10 to 8.04

$ sudo apt-get update
$ sudo apt-get upgrade
$ kdesudo "adept_manager --dist-upgrade" # (using ALT+F2 in KDE)

8.04 to 8.10

$ kdesudo "adept_manager --dist-upgrade" # (using ALT+F2 in KDE)

That's all.

I needed an overview of all zypper's commands and options, so i created this little script that prints all the help texts. It can be used to search for options through all commands, or to create a reference sheet for printing like this:

todo: fix some inconsistencies in option names (see this thread for discussion)

todo: wrap the help texts at 79th column, bug #423007 (no more need for 'fold -s' in the command above)

YaST is one of the cornerstones of openSUSE. It is developed for openSUSE and is released as part of openSUSE. There never was a release of YaST independent of openSUSE. Even the versioning of YaST is tied to openSUSE – the versions are 2.X.Y, where X is increased for every openSUSE release (17 for 11.1) and Y is simply a patch level, whenever a new fix or feature is added. Even more, every YaST package has its own versioning, so the only way to ensure you have a consistent set of YaST packages is via dependencies set in the .spec file of the YaST packages.

But in principle, YaST is a tool that can be used across distributions and there are people interested in this to happen. There are technical barriers to do releases independent of openSUSE (e.g. a lot of openSUSE-specific knowledge and behavior coded in YaST) as well as procedural. During past years, a lot of these non-technical issues has been addressed as we opened up the YaST development (re-licensing the code under GPL, opening up source control system and mailing lists, etc).

But still, there is one big thing left: YaST packages are released in concert with openSUSE. Yes, it is very convenient for openSUSE, but it makes it almost impossible to track the development during for people outside of our great distribution.

If one looks at the way the YaST packages are updated during the hotphase of an openSUSE release, the core parts of YaST (yast2-devtools, yast2-core, libyui, …) are rarely updated, they get a bug fix here and there. However, the distribution specific parts (yast2-pkg-bindings, yast2 common libraries, bootloader, storage, networking, …) get a fast flow of patch-level releases, typically several between openSUSE milestones.

Thus, the way forward I like the most right now is a compromise: a core YaST system should be released independently of the openSUSE release cycle while specific modules could keep their crescendo during openSUSE hot phase. How to do that?

For core YaST packages (a list to be defined) would be released independently of openSUSE and during hot phase, they would be handled the way other FOSS parts of openSUSE are – by patching the code in the package. The rest of the YaST, current practice would stay untouched.

There are clearly advantages – the YaST developers can do a proper release management of the core code and it is much more predictable how the core part of YaST will be released. On the other hand, people would need to be aware of the split.

However, I can imagine there is a lot of I did not realize. I’m definitely interested in comments about this topic.

Since openSUSE 11.0. we have some basic speech support in our bootloader. This enables visually impaired people to use the bootloader as there is usually no other output device available at that time (BIOS doesn’t really support braille displays).

It uses the PC-speaker for output (which has the benefit that you don’t need specialized sound drivers for every hardware).

If you didn’t try it yet: press F9 at the boot screen.

I’ve reworked that a good deal in openSUSE 11.1 RC1 (2MB sound samples) and now it reads all menus and dialogs to you and spells all chars you enter in input dialogs (actually it speaks the char left from cursor).

The sound samples are pre-generated with espeak. But you are of course free to replace them with your own voice if you like that more.

In order to realize a project of mine I started looking for a Qt library for mapping JSON data to Qt objects.

I came over a couple of solutions but none of them made me happy. So in the last weekend I wrote my own library : QJson The library is based on Qt toolkit and converts JSON data to QVariant instances. JSON arrays will be mapped to QVariantList instances, while JSON’s objects will be mapped to QVariantMap. The JSON parser is generated with Bison, while the scanner has been coded by me.

Usage

Converting JSON’s data to QVariant instance is really simple:

{% codeblock [] [lang:cpp ] %} // create a JSonDriver instance JSonDriver driver; bool ok; // json is a QString containing the data to convert QVariant result = driver.parse (json, &ok); {% endcodeblock %}

Suppose you’re going to convert this JSON data:

{% codeblock [JSON data] [lang:json ] %} { “encoding” : “UTF-8”, “plug-ins” : [ “python”, “c++”, “ruby” ], “indent” : { “length” : 3, “use_space” : true } } {% endcodeblock %}

The following code would convert the JSON data and parse it:

{% codeblock [] [lang:cpp ] %} JSonDriver driver; bool ok; QVariantMap result = driver.parse (json, &ok).toMap(); if (!ok) { qFatal(“An error occured during parsing”); exit (1); } qDebug() << “encoding:” << result[“encoding”].toString(); qDebug() << “plugins:“; foreach (QVariant plugin, result[“plug-ins”].toList()) { qDebug() << “\t-” << plugin.toString(); } QVariantMap nestedMap = result[“indent”].toMap(); qDebug() << “length:” << nestedMap[“length”].toInt(); qDebug() << “use_space:” << nestedMap[“use_space”].toBool(); {% endcodeblock %}

The output would be:

encoding: "UTF-8" plugins: - "python" - "c++" - "ruby" length: 3 use_space: true

Requirements

QJson requires:

• cmake
• Qt

Obtain the source

Actually QJson code is hosted on KDE subversion repository. You can download it using a svn client:

svn co svn://anonsvn.kde.org/home/kde/trunk/playground/libs/qjson

For more informations visit QJson site

I put the post “10 Things …” into the wiki. I rearranged the order a little bit, but basicly it’s the same page. If you have suggestions how to expand it, feel free to do it. The main intention was to write down things that users always ask me on events, of course it could be extended to a general “Tips and Tricks for openSUSE users”. But keep in mind that we already have the Users FAQ. Thanks for the comments, i will start writing an article or chapter how to buy new hardware for Linux soon.