openSUSE

• old action items
• KDE repository splitting (remove :Extra-Apps?)
• KDE3 to KDE4 migration for openSUSE 11.1
• Add your ideas to http://en.opensuse.org/KDE/Ideas for 11.1.

Stephan Binner's openSUSE KDE 4.1 Alpha1 Live has been uploaded and is there for you to try. It is the first real release of the KDE 4.1 branch after almost 45000 commits and is the result of 4 months of steady KDE development. It has rough edges, but it is a nice preview of things shaping up to become usable and ready for the KDE loving user. It has almost no openSUSE customizations, so any bug you see there is probably worth a bugreport. Visit the KDE 4.1 Alpha1 Info Page for source download instructions and links to binary packages available for installation as we know of.

One thing I really like with Qt4: It is so damn easy to interact with DBus. Just with a couple of hours of playing, I was able to write a small KDE4 based PolicyKit authentication agent:

Of course the dialog looks a bit clumsy, and it is not based on KPasswordEdit (which I just learned about..) and it is not yet installing itself as a kded service module so that it is available all the time, but it is a start. The code is in playground/base/PolicyKit-kde if you want to look.

Weekly round of quickies:

• Initial KDE4 port of the opensuse-updater started and available for testers in the KDE:KDE4:STABLE:Extra-Apps repository. It is currently not installed by default via the 'KDE 4 Default' pattern, as I first have to talk with the maintainer and make sure that it does not break your system. Feedback is appreciated though, the sooner the kinks are ironed out the sooner we can switch to it for openSUSE Factory. Note that openSUSE-Updater is not really openSUSE specific anymore, there is a PackageKit backend coming up, which means that it will then run and work fine on any decent Linux distribution.
• The new KDE 4.1 weekly snapshot was finally released yesterday. It took me much more time than usual because there were some build system issues to be fixed first, and then I run into an unstable phase of /trunk where kuiserver was refactored. Anyway, r785500 compiled fine and seems to start up, so thats what it is, and it is 3000 revisions more than the last snapshot. Development speed is truly amazing these days. I know that plasma has improved, but there are surely lots of other nice things hidden in there, so check it out!
• The video recordings and slides from the openSUSE dev room at FOSDEM2008 are finally up: http://en.opensuse.org/FOSDEM2008. You'll find some openSUSE KDE 4 slides there as well as many other interesting talks. Have a look there

So it is Thursday again, the time for the weekly KDE 4.1 snapshot. openSUSE packages are already trickling down the line on the KDE:KDE4:UNSTABLE:Desktop channel in the buildservice, and except for kdevelop things seem to build and run just fine.

Given that the Qt 4.4.0 beta1 was delayed again, Thiago and I decided that it would be a good chance to update to a snapshot and use the remaining time for pre-beta testing Qt 4.4. This has already paid off: quite a few issues were already fixed and many are still to be fixed. The most pressing problem at the moment is the incompatibility with kwin of KDE 4. As a workaround for now, the following can be added to your ~/.xsession:

export QT_USE_NATIVE_WINDOWS=1

I'm sure we'll find a solution for that soon.

It has been a long day yesterday, but we finished building, bugfixing and testing openSUSE KDE 4.0.0 packages, including a bugfixed version of KDE 4.0.0 as Live CD and one Click Install. We've even tested and added workarounds for running KDE 4.0.0 on openSUSE 10.2. Factory updates were submitted this morning

I hope that our users realize that KDE 4.0.0 is not the end of KDE4 - it is the beginning of KDE 4. I'm really happy about the release because it is a big milestone and I anticipate that the KDE contributors will be glad that we reached this goal. It is a tremendously big motivation factor for all of us: To know that it is there. It might not be as shiny and feature-rich and configurable as the KDE 3.5.x series was, but it is real, you can see and use it, and you can find new ways to improve it. We've started to schedule 4.0.x bugfix releases on a monthly basis starting end of this month, and we will continue to regularly ship new fixes while we head for our new milestone: KDE 4.1, which is targetted to be a much more complete and configurable, KDE-ified experience. KDE is a truly free and open source project, so I especially like the new

From the KDE.org side, we've upgraded bandwidth and server power to anticipate the release announcement storm. So far everything still runs. Of course I'm watching the download numbers and so far I'm quite happy that the live CD is frequently fetched. But we can be better than the RC1 download numbers can't we?

This Friday and Saturday, the openSUSE KDE team will be hosting an openSUSE Packaging Day. It will happen from Friday, 30 November until Saturday, 1st December, from any timezone to any timezone. We will help new packagers to create high-quality packages for KDE for all kinds of distributions, like openSUSE, Fedora, Mandriva, Ubuntu or Debian via the openSUSE Build Service, so that other KDE users can benefit from it. Even better, all the sweat and tears might be rewarded by some openSUSE merchandising stuff!

If you`re interested in learning how to create binary packages, learn about all the openSUSE specific features that make your life easier or just want to help others in learning how to build software from source, please pop up in #opensuse-kde or #opensuse-buildservice. See ya!

One of the major new features of openSUSE 10.3 was the one CD install and live media solution. It was a long journey and a lot of work to make everything we want to fit on only one CD.

So, been there, done that. Unfortunately, now after the 10.3 release, the development for 11.0 has started, and that means: Version updates, more features, new applications. You can watch that here:

This is just the size of the base system, but it is more or less the same with any pattern. 10.3 release was beginning of October, and what you can see since then is more than linear growth.

You might ask: why?

• Incorrect splitting of library packages led to a huge increase in the number of packages. Each rpm package has a fixed size overhead, and many small packages use more space than one bigger package containing both. So for example libfoo was split in a libfoo5 and a libfoo package, where libfoo contains README's and libfoo5 the actual library. There is no point in splitting away the documentation if it is really small - it does not conflict with the Shared Library Policy. A rough estimation showed that this added about 0.5MB. Not too bad yet, but I fear that this will become worse over time, as more packages are split in that braindead way.
• The Gimp recently added better printing support, and for that it needs GutenPrint. Nothing wrong with that, except that GutenPrint is one huge 10MB package. So that adds another 10MB to the One CD selection.
• The GCC update to the 4.3 prerelease brought a lot of new trouble. We had to fix over 300 packages that failed to build with GCC 4.3. After fixing the build failures, the resulting binary code increased by 3% on average. That means the same set of packages suddenly became 2-3% bigger. Doesn't sound too bad, but when we fight about every Kilobyte to get everything on one CD, another 12MB added bloat doesn't make that a whole lot easier.
• The GCC 4.3 update added Java 1.5 compatibility and a much improved class library: 6MB more data.
• Our RPM changelogs grow, as we never remove entries (normally). For a number of reasons, those changelog entries are uncompressed within the rpm file. In addition, changelogs are duplicated for each subpackage of a source package.

  I wrote a script to figure out what we're talking about here: the sum of changelogs for the one CD KDE version is whopping 11MB. For example, the kernel-default package contains a 880KB (!) long uncompressed RPM Changelog. Most of those changelog entries are more than two years old and probably noone ever cares about them again.

So, unsurprisingly, for the reasons above we don't have one CD install media anymore that would fit on any buyable CD media.

Is there a solution?

I've spent my innovation Friday afternoon on finding solutions for our space problems. Here's what I found after a couple of hours:

• OpenOffice can make use of the gcj-gij java environment instead of the classpath/java-1.4.2 compat that we ship in addition. So we can just drop 12MB of data from the CD. Hurray!
• Andreas Schwab has recently added lzma support to our RPM. lzma sounds promising: it is much faster than bzip2 and testing claims that it can compress roughly 10% better than bzip2, which is what we use right now for rpm payload compression. That means we would free 55MB of space (!) by using lzma. As a drawback, nobody else would be able to unpack openSUSE rpms anymore, and according to discussions on the rpm-devel mailing list the whole stuff isn't bug-free yet. So I didn't do anything here yet.
• I wrote a small patch to our RPM that cuts changelogs to only include the last 2 years. This will chop off 4.8MB of data with little drawback.
• Currently, we have two squashfs images on our installation CD: one for the installation system (67MB), and one for the rescue system (22MB). There is a huge overlap in the content of those two images. So for the fun of it I recompressed them into one image, where the installation system conains the rescue image under /rescue. Combining both into one image saves a lot, because squashfs automatically hardlinks duplicate data in the filesystem, transparently to the user space. The result is astonishing: for a one liner change in linuxrc, we're freeing another 16MB of space on the CD!
• Recompiling selected libraries with -Bsymbolic-functions. For libgcj alone this saves one MB of relocation data.

So, with just two hours of work the CD set size got reduced by 23MB. Is that enough to compensate for the added bloat? I don't know yet, I'm eagerly waiting for the weekly Factory rebuild to see what the overall result is