As already mentioned, I have this certain tool in works that can do various magic when it comes to creating packages, especially for people who have no idea how to do them themselves. And since

too, and on Wednesday I have scheduled a slot for demoing the tool and helping people who'd like to create packages of their software, I've worked on implementing and improving various features that make it more interesting:

• Besides the obvious CMake support, there is now also support for autotools-based software. Autotools stuff is harder to process then CMake (funny, I remember not being very impressed by the move to CMake, but going back now made me wince here and there), but it's already pretty usable.
• Which means that even though the tools is called kde-obs-generator it can handle non-KDE stuff too. For example I have GEdit, Gnumeric or GOffice (why aim low, right?) in my testing project, and while none of that finish the build completely yet, it just needs handling more of the autofoo trickery. I guess the tool is about to need a better name.
• There's QMake support too, kind of. However, if you use QMake, you probably want to switch to CMake anyway.
• The recommended way of use is setting the build service project in a way that presents a more unified build environment, with macros and package name substitutions automatically taking care of distribution differences. This results in the .spec files being quite clean and easy to read. But there is also a mode that doesn't require this setup and builds directly in normal openSUSE, Mandriva and Fedora repositories (and Ubuntu, but that's already different enough from the rest). It means of course that the .spec may have a bunch of %ifdef's and manually written macros at the top, but it works.
• A consequence of this is that it is also usable for creating normal openSUSE packages. If the project build only for openSUSE, the resulting .spec is more or less a normal openSUSE .spec file. I've already watched few times Pavol and Michal explaining packaging to people who would like to learn it, and I couldn't help wondering how scary it has to be for some of them, getting a full .spec file explained line by line on how they need to write it manually. Well, for the next time the introduction part can be greatly reduced to just "run this tool, if it works and you're happy with the result, that's all then".
• There is also the bonus even for somebody who knows how to create packages. It's still nice to have the .spec generated automatically, including all the build requirements (if they are already in the database), the file list and so on. Everything I have posted at kde-apps.org for the last several months has up-to-date binary packages too, and it's almost boring to create them.

So, whoever would be interested, just talk to me at Akademy or come to the Wednesday session and I'll try to help you getting your stuff built and answer any questions (except for the two questions about blue hair - really, people, I've heard both of them already enough times, can't you get at least a bit innovative :) ?).

It is interesting to notice what is sometimes seen as difficult. "It's too hard for me, I can't do that." "I'll never be able to do that, that's nothing for me." Like if most things could be done instantly just by snapping one's fingers. They instead require all these tedious things like effort, trying, learning, practicing and so on. The funny thing is, figuring out things in the IT area is not really that demanding. Wanna write a Plasma applet? There's a step-by-step tutorial at Techbase, just follow it blindly and with a decent skill in reading and typing, tadda, there's a Plasma applet. Wanna a package in the build service? You can use another one as a template, find a tutorial on the wiki or just google for it, and if you'll be just a little lucky, a tool can even do the work for you.

For getting a good comparison of what can difficult actually mean, let me show you something I consider to be pretty hard to learn. To have a better contrast, let's go in some completely different area that has absolutely nothing to do with computers. So if you think something is difficult, instead of doing this whatever something, try doing for example the Salchow jump. And since I expect many people here have no idea what that is, it looks like this, performed by yours truly:

That's roughly it. I assume it looks quite unimpressive to anyone who's never tried it or anything close (and, possibly, in this specific case it probably looks quite unimpressive even to whose who have). Yet this thing was bloody hard to learn for me. I probably learnt coding with Qt quite decently with much less effort (although, that's one of Qt's selling points, isn't it). Writing .spec files and creating packages? Nah, eeeasy. Even getting into Xlib programming was probably less effort, and I read a good part of the Xlib manual as a part of that. I admit getting into compositing effects and adding them to KWin might have been harder than the Salchow though :). Still, for somebody whose reaction to the idea of writting an alternative KDE workspace shell was 'how hard can that be?', the Salchow proved to be an unexpectedly difficult matter.

I was first shown and explained the Salchow about 9 months ago. I think I needed about 2 or 3 months just to perform it in the most lame way that'd technically qualify, about as much as x = 1 qualifies for a math equation. The video is from April, i.e. more than 3 months on top. Today I can perform it somewhat higher and at slightly faster speed, but it still hardly qualifies for anything better than 'decent'. And while I hope it'll one day get to something I'd consider good, I'll probably never ever get to those crazy things like multiple rotations or anything even remotely close to what you can see on the TV, no matter how much and how hard I'd try. Do you still think that e.g. creating and maintaining a package is hard, compared to this? And don't even get me started on the next jumps ... the Salchow is actually easy. Try to think of this next time when you'd want to do something but would consider it too difficult (besides, take this from me, trying difficult things is actually much more interesting than the easy ones).

PS: Come to think of this, I've never thanked Danimo and Scott Wheeler, who happen to be ultimately reponsible for me starting with skating and having a lot of fun, as I'd probably never come across any such idea myself. So, well, thank you.