Those that were at either CampKDE or FOSDEM might already know, so for those this is a status update, for the rest: I've been working on a tool that makes it quite easy to create packages in the openSUSE build service, which despite the name can create binary packages also for other distributions than openSUSE. If you've ever gotten a mail asking for a binary package of your application or help with a compile problem, this could make your life easier.

For example, imagine Joe Developer, who has written his KFoo application, uploaded it to http://kde-apps.org and is now watching what happens. But, alas, instead of thanks and praise, what often happens is that the first comment is something like "I get this compile error, can you help?" or "Are there packages for Kubuntu?".

It may be quite easy for Joe to see that the compile error is caused by libbar-devel not being installed, but how is he to know what the package is called in other distributions? The same way, how is he to provide binary packages for distributions he does not use? And that's far from all things that can go wrong in such case - Joe may be running KDE workspace 4.4, but somebody may be still on 4.3, where the application would nicely compile and run, if only one #ifdef would be added to the right place. But will Joe really downgrade his installation just in order to fix that, and again each time he does a release of KFoo? And then maybe somebody else will try to compile it on openSUSE Factory, which already uses GCC 4.5, and will get compile errors because the latest compiler is more strict than previous versions and rejects invalid code that however compiles just fine on Joe's computer. And so on and on.

Joe, of course, is a smart guy (after all, he's written this great KFoo app that everybody wants to run if only they could compile it ). He can get the idea to use VirtualBox and install other distros he could care about, and test in all of them. The question is how long he'd be really willing to do that, since it certainly sounds like a lot of fun (and lot of disk space, and work). And that still means that all those potentional users would have to compile KFoo from source.

Maybe distributions would eventually include KFoo, but there's this tricky loop 'nobody uses it' -> 'why should a distro include it' -> 'no distro ships it' -> 'nobody uses it'. Maybe Joe gets lucky, maybe he does not.

Sometimes other people may provide binary packages for the distribution they use, so if somebody likes KFoo enough (and knows how to do it), Joe may find a comment on kde-apps.org pointing to this package and can add it to the list of packages to download. Except this may and also may not work, depending on how well those packagers keep up. Having a binary package of KFoo-0.3 when the latest source tarball is KFoo-1.5 is probably worse than no binary package at all.

So Joe can go back to the VirtualBox installations and try to package KFoo for all those distributions. But Joe is a developer, not a packager, so first of all he'd have to learn how to actually do that (e.g. creating a .deb is quite different from .rpm, and even .rpm packages for different distros are not created exactly the same way). Worse, he is a developer, and, honestly, developers just love packaging, especially for multiple distributions, riiiiiight?

Now here comes the openSUSE build service (OBS), which as already said is not only used for creating the openSUSE distribution, but also provides the ability to create repositories providing additional software, also for non-openSUSE distributions. That almost looks like the solution for all the above problems, doesn't it? No need to install the distributions and do the builds locally, the OBS itself will do the building. New packages would be available very soon after updating the sources in the OBS. And kde-apps.org has even direct OBS support, so packages can have direct download links there.

There's still the problem of actually having to know how to do the packaging, but that is exactly what kde-obs-generator should help with. KDE applications in general happen to be simple to build, and thus quite simple to package (in fact, compared to some other pieces of software, KDE apps happen to be remarkably simple to package ). So a lot of that could be automated. In the best case, creating a KDE package in the OBS can be now a couple of clicks in the web interface, few osc commands (osc is the CLI tool for OBS) and running kde-obs-generator in the directory with the source tarball. I've already tested the tool with some packagers and they even started using it for real, because even for experienced people it saves work.

I still consider the tool to be experimental and work in progress, but it's already pretty usable. Currently it can handle Plasma themes, KDM themes, KPlash themes, wallpapers and generic KDE/Qt CMake-based builds. It tries to automatically figure out all the needed build dependencies (which however means the list of mappings from cmake to package names for all supported distributions needs to be extended as necessary). Also kde-obs-generator itself is packaged using kde-obs-generator. The biggest thing I've built so far is the whole of kdeutils, that's of course not how something like kdeutils should be packaged, but that shows it can handle quite a lot.

So, in case you'd like your application to reach more of its posible users, you'd like to ease your testing, or you're just curious, the documentation is in the openSUSE wiki. I'd especially like to point out the tutorial, which is really step by step and includes also things like how to create an account for the OBS, so maybe even a monkey could now create a package (well, assuming it can read and write and is pretty bright for a monkey - this still cannot be as simple as just hitting Enter repeatedly). If there are any questions or a problem, see the feedback section (mail the opensuse-kde mailing list, or just ping me (llunak) in #opensuse-kde on Freenode).

PS: I'd appreciate if people using other distributions could edit the wiki page on how to actually install the binary packages in some easier way than going to http://download.opensuse.org, navigating to the right .rpm/.deb file and clicking on it. It's pretty easy with openSUSE so I assume there must be something simpler on other distributions too, but I can't find it.

New KDE Four Live CDs with KDE 4.4.1, and much more are up.

They were built with openSUSE Build Service's KDE:Medias project and SUSE Studio and consist of openSUSE 11.2 plus all updates, KDE 4.4.1, upstream branding, Nepomuk enabled and Strigi disabled (because it's a Live CD).

They can be used as Live USB sticks too, see these instructions if you don't know how to dd a file to a device.

You can also install to disk and use it as a normal distribution using the installer on the desktop. Once installed, the first update will pull in all the packages that are normally on an openSUSE KDE install that do not fit on a single CD.

If you've been paying attention at the back there, you'll know that openSUSE started using a new community-driven online update administration process for 11.2. As well as Novell employees, community people are taking care of the workflow of examining and approving online updates to buggy packages. Now I have a favour to ask of you - the online updates that are ready to go out need testing to make sure they don't inflict gross mischief on users' systems.

KNetworkManager has an online update sitting in this queue awaiting testing. As anyone who has read http://bugzilla.novell.com/show_bug.cgi?id=553908 knows, I forgot to initialise 2 bools added to KNetworkManager just before 11.2 shipped, causing the settings that control whether DNS and routing settings from DHCP to be applied to be set randomly, so the update team wants someone more reliable's opinion on whether my fix for that is any good.

If you want to test it out and take part, add the 11.2 update test repo (or manually browse this URL and install all the NetworkManager-kde4 packages yourself) - http://download.opensuse.org/update/11.2-test . NB that due to a process bug the release number is the same so you will have to --force the install. If it works for you, please comment on bnc#553908 to that effect.

So, openSUSE 11.2 is out, and that means a lot of people start using it and, well, occassionally run into bugs and sometimes even report them. As much as 11.2 appears to be a fine release, this is bound to happen now too, and that means that the number of KDE bugreports for openSUSE in the Novell bugzilla will grow again and will need to be handled.

And now it seems to be a good time to do some housekeeping there. Many of the bugreports there are old by now, for older KDE releases, or even for openSUSE releases that are no longer supported (bye bye openSUSE 10.3). Having too many bugreports means a lot of effort needs to be spent just managing them - if developers and packages are supposed to fix problems, they first need to know which ones are important and should be worked on first. For this reason we have guidelines for sorting KDE bugreports, however, with the recent the release of 11.2, there hasn't been time to review all recent bugreports, and many of other bugreports are not valid anymore.

This is exactly the time when you can help KDE in openSUSE. If you like the 11.2 release and would like to contribute back, if you've already wanted to contribute but didn't know how or thought that you don't have the required knowledge, or even if there is a bug you'd like to see fixed and would want to help the developers and packagers to have more time to concentrace on it, this is the chance. We are starting another KDE bug squashing session, with the aim to review and sort all KDE bugreports for openSUSE. And it is not difficult - all you need is openSUSE 11.2 installed, the ability to use Bugzilla, and the howto describing all the details.

So if you want to be part of the openSUSE KDE team, come (today, tomorrow, this week, whenever you want) to #opensuse-kde IRC channel on FreeNode, ask if you have any questions, consult the howto and you can pick from the prepared groups of bugreports and let's squash some of those bugs.

Since it seems it will turn up quite often, I would like to answer the question 'Will openSUSE 11.2 include KDE 4.3.2?'. The short answer is no and yes .

The 4.3.2 release of KDE came too late to be included in openSUSE 11.2. As the distribution release gets closer, there is a certain point after which only reviewed changes should be allowed in, in order to reduce the possibility of these changes causing unexpected breakages that might go unnoticed within the relatively short time until the release. This can happen and it wouldn't be very good to fix something small and break something bigger for the release because of some unnoticed mistake. So openSUSE 11.2 will not officially include KDE 4.3.2.

As can be probably seen from the 'officially' in the previous sentence , this is not all, as openSUSE 11.2 will, in practice, almost include KDE 4.3.2. We were updating from the 4.3 branch until few days before KDE 4.3.2, and were still including bugfixes that were important enough even after that. So if you care more about how it works than what sticker is slapped on top of it, then you shouldn't need to worry.

And additionally, of course, it is possible to install 4.3.2 from the KDE:43 repository, where new stable KDE releases are packaged as long as KDE:KDE4:Factory:Desktop is frozen for openSUSE 11.2.

The decision on the matter of the (not)preselected desktop in openSUSE has been made. You can read about it in the mail announcing the decision, I would like to just offer a KDE view, from Will and me.

What happens now is that in the desktop selection screen during installation there will be the KDE radio button preselected. That's all, folks. Nothing more, nothing else. It doesn't mean KDE gets better somewhere else, no new KDE developers are going to magically appear on the KDE team, this means nothing for SLED, and it means nothing for other parts of openSUSE. Therefore, in case you feel a strange urge to start publically shouting "Victory!" or saying something about GNOME getting dumped, do yourself a favour and don't bother trying to look like a pyromaniac (besides, I think there still will be enough of those and you'd just get lost in the crowd). The openSUSE distribution wants to be a distribution for all and this means that KDE is one part of openSUSE alongside GNOME, Xfce, Firefox, OpenOffice.org and others. If KOffice one days gets more popular in openSUSE than OpenOffice.org, it becomes the default. If GNOME one day becomes more popular in openSUSE than KDE, it becomes the default. As simple as that.

However, I believe that even this small change can achieve a lot for KDE. Some people, when supporting the openFATE feature, expressed their opinion that making openSUSE focus on KDE would make openSUSE the best KDE distribution. But openSUSE is not some magic creature that gestures and makes things happen, it is the community that does that, and there is nothing preventing you from taking a part in making KDE in openSUSE even better. Since that is how you can also look at this whole issue - I hope this is enough to show that openSUSE really wants to be a community distribution open to all. So if you have doubted that for whatever reason, you might try to look again and reconsider. Or, of course, even if you are just looking for a distro with good KDE, you could check out openSUSE too .

A few technical details ... er, a shameless plug ... well, simply , in case you want to give it a try right now, a couple of things that could help you. First of all, the latest openSUSE release is 11.1, which includes KDE 4.1.3, and openSUSE 11.2 with KDE 4.3 is in development. Don't faint, the fix is simple - you can try either installing from a 11.1-based LiveCD with KDE 4.3 created by Stephan Binner, or you can upgrade KDE in 11.1 using either zypper or 1-Click (note you will have to confirm vendor changes because of switching to a different repository). More information about KDE in openSUSE, including the mailing list, IRC channel, build service (you'll hear about that one again) can be found in the openSUSE Wiki. So, all those of you who wanted openSUSE to be the best KDE distribution out there, let's see about it.

If you look at for example kde-apps.org or kde-look.org, there are numbers of various KDE applications, utilities, styles, decorations and what not. Various contributors post there their work for others to try and use. This is the place where new software or other contributions often look for their first users.

However, if you look closer, you may notice one problem - most of them are only provided as the source tarball, with no, few or old binary packages. Sadly, here the old jokes about how difficult it is to install software on Linux are still valid - it is not difficult to find applications with comments along the lines of "I tried to compile it, it said <whatever error>, what do I need to do, help". The difference between providing or not providing a simple way to install your newest creation can be the difference between users using it or not.

This may not seem to be that simple to solve though. There are probably only very few people who have all the major KDE distributions installed, let alone actually know how to create packages for all of them and have the time to do that. There are other community members who sometimes provide binary packages, but those only do it for a selected range, and they have to update them as new versions are released. More lucky contributions get picked up and packaged by distributions, but that can be difficult for new ones, since simply they are new and not many users know about them. So it looks like the usual kde-apps/kde-look/whatever contributor needs to depend also on luck to actually even reach the potential users.

Well, for those who still don't know it, let me introduce you: KDE contributors, meet the openSUSE build service; openSUSE build service, this big bunch of people are KDE contributors.

The openSUSE build service is a tool that is used to build the openSUSE distribution, but it can be also used to build additional software for openSUSE (such as the additional KDE repositories that provide various KDE versions). And, what many people might not know, it can be also used to build software for other distributions.

In fact, I've been looking into the possibilities recently, and, in the process of it, I have packaged a bunch of random kde-apps/kde-look stuff in my home repository. And, right now, I have packages for various openSUSE versions and SLED 11, Fedora 10, Fedora 11, Mandriva 2009, Mandriva 2009.1 Spring, Kubuntu 8.10 and Kubuntu 9.04. There are some more distributions supported, for example Debian, but those do not yet have a stable release containing KDE4, so tough luck there.

And I tried to cover various possibilities of what gets posted on kde-apps/kde-look:

• I was probably the first one to package the KWin Aurorae SVG decoration engine by Martin Graesslin soon after he had announced it there, as soon as the necessary KDE4.3 beta2 release entered the KDE4:UNSTABLE repository. I also packaged the Nitrogen KWin decoration, just to have a decoration that builds on more distributions.
• I packaged a set of the Glassified KDM, Plasma and splashscreen themes. The themes were actually just tarballs containing the files (and that actually gave me a hard time when trying to package that for Ubuntu) that need to be uncompressed into the right place, but still, there is the convenience of just installing a package and be done with it.
• I miss the ability switch using keyboard shortcuts between taskbar entries like it was possible with Kicker. There was feature freeze, so instead of providing a patch for Plasma I went for a temporary solution and wrote a simple KDED module hacks that does it. And from the moment I uploaded it to kde-apps as TaskbarSwitch there were also binaries.
• I packaged KShutdown, Ksshaskpass and Kvkbd as examples of various applications. Together with Ksshaskpass I also created a local modification of the openSSH package and sent a request to its maintainer to include a change that enables openSSH to use Ksshaskpass. Kvkbd needed a patch fixing it to work with the XDM/KDM setup on openSUSE.

And the best part about it is that it was actually quite simple and easy. I just took a template for .rpm and .deb packaging, filled it in, tweaked a bit if needed and submitted to the buildservice. Then checked the results after a while, fixed problems and now it is all in home:llunak:kde, ready to be used. Anybody who can code a small KDE application shouldn't have a problem to do the same and then say that the package is in the repository home:<whoever> and that the installation instructions are at http://en.opensuse.org/KDE/Build_Service.

Of course, it was simple and easy for the Lubos Lunak who wanted to package those things, as that was the point. The other Lubos Lunak, the one trying to ensure it was that way, had it a bit harder. The openSUSE Wiki has a lot of information, but it was necessary to read it and try it out. Some work was needed for building from one .spec file for all RPM distributions (really just one .spec, the only package that needed conditionals was Ksshaskpass, and only because I knew the special handling needed to fit with openSUSE's openSSH). It is of course possible to build for each distribution using their .spec syntax, but I wanted the possibility of having just one syntax that would be mapped automatically as necessary using macros and package renames. Some work was (and still is) needed to help making .deb packaging as shared with .rpm packaging as possible (I think I can forget generating it automatically from the .spec, but for example Debian/Kubuntu build system accepts only .tar.gz tarballs, so there is a build service patch from me pending to make the possible conversion automatic).

That work is going to be only mine, though, the plan is still to make it easy for you. Well, ok, I wouldn't mind if at least somebody added better details to the distribution-specific pages linked from the main page, because I e.g. haven't managed to find out how to easily add a new custom repository on other distributions. So if you are waiting now for a howto, this will need to wait for a while, until it is prepared and cleaned up. You can however try to bribe me at Akademy into demoing it personally .

Yesterday I learnt about two new options for my xorg.conf :

I must thank the X Strike Force guys from Debian for that knowledge . Yesterday I tried the latest Xorg packages (7.4) that are available for sid, and my keyboard and mouse stopped working. It seems that Xorg now relies more on what HAL tells it about the available input devices than on its own configuration (as explained here, thanks Ana for the link), and those two options together force X to continue using the input devices configuration from xorg.conf instead of using HAL.

I know the solution would be to configure HAL correctly, but that would take longer and yesterday I didn't have the time for that (I have a very custom mouse configuration for my trackball marble fx, that I guess it won't be easy to write in HAL).

Hope it helps everyone who find that same problem when upgrading their X servers.

PS: Yes, I know it's been a long time since I don't write anything here, but I'll pretend I do, and write as if nothing happened instead of garnish the post with the typical "I'm going to try to write more often" that I will probably not fulfill anyway (and not because I wouldn't want to)

Martin Schlander already said the most important things but repetition never hurt a good message:

• KDE 4.3 is coming to KDE:KDE4:Factory:Desktop<. If you do nothing and use this repo you will get KDE 4.3beta1 installed soon!
• The stable KDE 4.2 packages will continue to be available in the new KDE:42 repo.
• The Extra-Apps repo is gone, its packages merged into Desktop, Community or Playground according to their level of support and release readiness.
• App packages which have both KDE 3 and KDE 4 versions are being renamed to show that KDE 4 is the default. Eg for digikam, we have kde3-digikam and digikam-kde4. This will cause a package upgrade to the new stable version. If you want to keep the KDE 3 version, install the kde3- package instead of the new KDE 4 based package.
• The Geeko is a quiet and stealthy animal. It doesn't make a lot of noise. But it produces solid, well engineered Linux distros year after year. Stephan 'Unstoppable Force Beineri' Binner has produced a respin installation CD of openSUSE 11.1 containing the latest and greatest KDE 4.2.2, and all the online updates since 11.1 came out in December. Is the longer openSUSE release cycle making you twitchy for a hit of something new? Do you want a rock solid openSUSE with the best KDE has to offer and none of this repo-fiddling nonsense? Get the respin from: http://download.opensuse.org/repositories/KDE:/Medias/images/iso/.

Yes, sounds strange. Why should i did it ?
Well, first is known among the distros that qt-creator in first release is not the most friendly to packaging.
Not only beacuse qmake, but because some distros rely on things like splitted packages or 32/64 bits coexistent libs and plugins.
Second, was quite a challenge for me do this, because i need to learn some new tricks ( thanks dfaure for automoc4 help ).
Third, dressing my packager hat, i would love to see qt-creator been in the main Mandriva distro, compliant with our policies, and been adopted as well i expect for kdevelop4 when be released. Qt Creator is one of the amazing IDE's around and i thought that worth the effort to give some love in buildsystem to have it in a full Mandriva way, including our flags and standard cmake build.
During the process, i could manage to fix all bugs open in our bugzilla about packaging, and at same time enable the "most wanted" feature here, the designer plugin, which for some reason was not enabled in our qmake previous compilation.

To summarize what i did:
- Write whole cmake buildsystem
- Backported icons and mime and desktop files from upstream binary Qt Software package ( as same as Kubuntu did )
- Make the plugin standard dir be the Qt plugins standard dir, which make possible have 64 and 32 bits plugins instalable
- Make qt-creator easily compliant to /usr linux install
- Splitted libraries in subpackages as usual, and installed in our standard libdir instead of a subdir
- Reenabled designer plugin.

So, now i'm totally happy with all the changes, barely minimal in code ( most moc include additions and add standard Qt plugin path ).

For who is interested, our svn repository is Qt Creator Package Repos
For who wants to try our marvelous distro, today we will be releasing RC1 from Mandriva 2009 Spring, so you will be able to see how hard we are working to make a better distro for you...