 Well, good morning everybody! I think we've waited long enough to see if anyone else is going to come out of bed. I'm really happy to see this place so full and you've all made it here despite the early hour of the morning. My name is Will Stepneson. My name is Steve Wما. Ac we hear to tell you about the KD4 presence on the next version of OpenSuzer. So, we're going to talk a little bit about KD's presence on OpenSuzer in general. We're going to talk specifically about KD4 on OpenSuzer 11.0. And then we're going to give you a brief demo of how you can start developing KD software yourself using scripting languages. And if you get time, we're going to talk about the OneCD process, which is the changes that we, the KD team, have made to the build system, to package management to make it possible to get the OneCD that holds KD3 and KD4 in the case of 10.3. So, OpenSuzer's KD presence. Here's our little mind map of what we do. Four major areas, packaging, upstream work with KD.org, product work and specific applications. All of these, of course, feed into one another, but these are general discussions. So, packaging, we package KD, we make sure that on OpenSuzer we always have the freshest KD packages with patches from upstream where we can. So, you're really getting, when you get KD3.x.y or 4.3.q, you're not just getting the tables, you're also getting the improvements that have been selected from the KD upstream repository by ourselves as experts. We provide build savers repositories, which give you access to a wide variety of different KD versions, stable, unstable, grouped in various ways, and customized versions of Acute. So, no matter what you need, you can always get variations of KD software that fits your needs. We work on a variety of applications. I'm going to go into a little bit of detail, but network manager, car power side, carry system settings, we all hack on those. And we're also very active upstream. We're members of the release team of KD. We set up release schedules. We make decisions about whether software is of sufficient quality to go for a release. And another example there is Dashboard, which is an application, a web application of Dirkroats that allows KD developers to see what the status of the repository is by constantly rebuilding all the KD software direct from SDM using the Open2Z build service, using our packages. And then all that comes together, that goes into Open2Z products, which is Open2Z level, which is led, which is a live CD, everything which is something you can take with it. So, what's a live CD? It is a live CD built using Kiwi, built using packages that come out of the build service, and we make sure it's really regularly updated. I mean, during the KD4 release cycle, we were updating that like twice a week. So you can always get the freshest possible KD packages if you want to try them out. And even install that now. And with the way things are going, we've got more and more tools which make it possible to create customized images. So if you have a need for an Open2Z KD-based distribution, you can take the scripts that generate the live CD and customize those to produce applications CDs that do what you want. So one example here would be to make a KD SDK CD, which you could boot, develop KD with and then install and really say to someone, look, discover KD development, this is all you need. It could also be useful for testing a data speak, for example, if there's a bug report that is very hard to reproduce by us and can only be reproduced by a report that you can just download the new live CD. But the new packages can start to pull it up and see if there's a problem with that, for example. The URL, if you have anything similar to KD, you've probably heard Stefan Binner's blogs, read Stefan Binner's blogs about this, but there once again is the URL where we store the live CDs. So built service packages, we have a range of different repositories. At the moment, these are probably the two most important ones. We've spent some time deciding how to divide up or software into repositories, so you get the benefits of a wide range of things and familiar structure, but also split it up so it's modular, so that if you want to just to get the pure KD core packages, you can say it goes KD4 stable, that's KD4.0 and install the desktop repository, which gives you the basic KD release cycle packages. If you want something more than that, you can add the extra applications, which is KD extra gear, and some other applications which are following the KD release cycle, so K office, but not part of the KD core modules. To go beyond that, add the community repo, and then you also get the community maintain packages. I don't know if any of you are interested and if you come to any of our IOC meetings, but we have a vacancy in the community. We're looking for a module maintainer, somebody who would maintain this build service module, and he would select the cream of the best new KD4 applications and add them to our repository. What we forgot to mention is that each of those repositories also define patterns, which we can just browse in your just or a super way, and they provide a basic installation, a default selection, which we suggest to use, and the same thing could be done for a community repository, which is currently lacking any patterns. I think we have to, we should provide patterns for the community repository so that we can, if you have to select several applications, you can just install the pattern if you want to. And then we have the same structure repeated for KD4.1, which is the development branch, so that gets you a weekly snapshot of the KD4 branch, all built, all packaged, and all tested using the dashboard as well, so that we know it actually builds clearly. So, if you want to track KD development, but don't want to build it yourself, that's the way to do it. If you're interested in packaging, interested in opportunities in KD, we're having some packaging days where you can come along and work with us, other experts, learn how to use the build service, and get yourself an account set up, and really get led through that process of making packages with as much handholding as you need to make it really easy for you to get into that. So, coming on to that, that's in April, 4th and 5th Friday in Saturday, so plenty of opportunities there for you to come and meet us. And, as it says there, the build service is not just about open service, we provide it, but we're so big and generous that we make it possible for you to package your software for the distributions as well. So, I was just talking last night with the guys from GnuStack, who are a desktop environment foundation, and they're a really big, really positive about coming in packaging for all the distributions that they target using the open service build service to provide the build horse power. So, you could do that too if you're into packaging software itself. And that brief overview of the things that we've done in the KDE team, and I don't know if you know this, but OpenSUSE employs the most KDE developers full-time to work on KDE. So, if you were here last year, you would have heard about Kickoff, which I presented at, which is the start menu. We developed that inside Sousa. We did that using usability experts, and then that's since gone out and been taken over by the community. It's now a part of KDE 4. And we take the KDE 4 community version and do a bit of improvements. So, we have to say, if you look at the bottom here, there's a user and host name and a little openSUSE logo there. So, just little improvements, patching things like making the highlights here more interesting, more wider, sorry, which makes it easier to use and more usable, which we feel. So, you always get a benefit of improved RMPs. K network manager, that's the old screenshot. It's the control applet for the network manager demon. And again, that's developed and maintained by OpenSUSE and every distribution used in benefits from it. And we're working on versions of that to cover both KDE 4, at the moment where you can use the KDE 3, I've learned the KDE 4, but when by the time KDE 4.1 comes out or 11.0, we will have a KDE 4 based applet. And that will cover both network manager 0.6. So, for other distributions, which are still using network manager 0.6, you can benefit from that, or 0.7, which we're going with. In K PowerSafe, it's the application which does your suspended disk to resume managers, your brightness managers across Brooklyn. Danny Kukufkin, the mobile devices team, he mentions that. And that's going to become the standard power management tool for KDE 4. System settings, it's used by all of KDE 4. We put time into that before the KDE 4 release to make that usable, to make that stable. And generally brings up the standards that people demand about such a core piece of functionality. It's probably worth mentioning that we're not going to demo that much because there's another KDE talk just after this talk in the first desktop room, which will show all the new improvements of KDE 4 by demoing it. So we're just more or less quickly giving an overview of all the specific stuff. But if you're interested in KDE 4 in general, then you're very much invited to the subject talk just afterwards. And whatever you see in the general talk, remember, you'll see it best produced on KDE 4. So Kerry, it's the desktop search tool for Beagle. That is being extended down to Striggy for KDE 4, like I'm working on that. And that means that you'll be able to use the same search tool using either a Beagle or a Striggy search backend. So all the high-performance searching you've heard about, the Striggy office will be supported by Kerry. You could actually use any other search engine as well. It's not in any way a respect to any one. We will just implement a specification of the data on which of Beagle and Arthrawites and Striggy implement some. You could have another backend for another search engine if you want to. OK. So, I'm going to hand over to Derek now, who's going to tell you a bit about applying for KDE 4's presence on the next release. It's our current spectrum. It opens on the Level.0 where it will be released this year too. And we will maintain it at least for two years, which also means that the KDE version we are going to ship is the one that we will maintain for that time. So there's no saying that we will maintain it for half a year or something like that. We will maintain it for a full period of time. We have a problem that we want to meet the expectations of our users and our customers, which means they're used to a very visual and stable KDE code base. But we also want to provide proof that KDE 4 is already ready for an enterprise platform, which means that we are in a bit of a difficult district situation that we want to prove. Then it is ready on the other side. We are a little bit unsure or we are concerned about the future regression, which we have in KDE 4.0. My main motivation is that we want to ship the same card in KDE and we want to make sure that OpenSuser is the primary KDE platform. So what we are doing right now is within the alpha phase of the 11.0 series, we ship KDE 4.0.1 or the 4.0.2 version as soon as it is released. We do a little bit of backports of applications that are currently only developed for KDE 4.0.1 and another part of KDE 4.0 is the V-Series up-screen. So we have, for example, improved the backport improvements in Plasma, which are essential for the user to be able to use KDE as a primary desktop. We do this for Falturi since once, the first reason is that we want your feedback. We want to know what are your problems, what are your concerns, what would you want to have improved for KDE 4.0. I would like to point out that we use the same code base for the 10.3 packages in desktop as well as for 11.0. So if you don't want to try installing 11.0 alpha or beta, you can still give us useful feedback by using 10.3 packages. As I mentioned, we target a feature in quality parity with KDE 3.0, which is carrying out our main concern. So we are maintaining a proper list and slowly drawing through the proper list and fix the problems as they come up. So if you have things that you consider to block out these deepest inputs, that's very important for us. An alternative plan is because in case we are not happy enough with KDE 4.0 or what KDE 4.0 provides, we might ship a 4.0 beta because we are quite close to the upstream schedule for KDE 4.0. So we would have to clear the project so that we can ship many more features and improvements and polishing that is currently being done on the other side, we are a little bit more concerned that as we have to ship a beta, it's obviously not final and we might have some stability problems. If that was the case, if we did ship a beta, then we would ship a 4.1 final via online updates as soon as the 4.1 final was released. We would maintain the great table of situations equally and in the second case, we would provide an online update to the final version as soon as it comes out. A couple of open topics which we are currently investigating is what pin notifications we really want to ship. As you might know, the upstream didn't release the pin notifications for 4.0, so we have two options. We either ship the KDE 3 versions, which has been improved for quite a long time to Rackle-Lyden and has been extended in the enterprise branch with new features and a lot of enterprise-ready goodies. This is basically a very stable code base which we could use as we currently ship, but the other option would be as the porting of this enterprise application suite was already finished to KDE 4.0. Therefore, we have shipped the new KDE pin from KDE 4.1. So even if we ship a 4.0-based KDE, we may then ship 4.1-based PIMs so that you get KML2, Cognis 2, Hampton 2, Contact 2. It would be very exciting. So right now there are no packages of the pin packages from KDE 4.1, but we have planned to provide them within next week, so we haven't had a news engine about them, so if you want to try them out, don't try them with your live data for the first time, maybe. And please give us feedback, so we will probably announce that separately. We are also currently very much discussing internally and with the community, especially which applications ship by default because many applications is not quite clear. There's a KDE 3 version and a KDE 4 version. A KDE 3 version is often as good to maintain as the KDE 4 version, so we have to basically say, do we want to go with the newer version or do we want to go with the more stable version? I'm mentioning Amorak 2 here because we really like it. It's a big improvement over Amorak 1. On the other side, the upstream developers are currently, I think, not that interested in us shipping it because they would get a lot of packages for us and a lot of feedback that they don't want that they don't appreciate at the moment because there are so many things that haven't decided upon yet. We use the opportunity here to meet with them and talk to them and see what their input is. Another open topic is what level of meaning is the person who is going to provide to our KDE. This is mostly a time issue, I think. KDE is made in material enough that it can just change any look and feel you want. But we would still like to have an obviously touch on it, so we want to do a little bit of extra and we are currently thinking about that here and how to do that. We've got little things like the start menu we showed you and like window decoration that has a little pico in it, but it's not really functional but it reminds you of the default set level 3. The open topic is the backward compatibility or the upgrade path, which is more or less the same thing. We want to provide users the possibility to be able to upgrade from 33 to 34, which is currently not that much focus from upstream, so we are really investigating and making sure that you don't break your KDE installation by a cluster store in KDE 4 or you don't break your KDE real-estate installation by just starting it out from one spot. That means adding things like making sure that session management to KDE 3 applications works in KDE 4. We haven't gone so far as to importing configuration yet because we want to make sure that people's KDE 3 configuration remains compatible, that's not a different thing. I think the idea we have here is to implement it in such a way that it will import the configuration from KDE 3 if it's available, but won't override the KDE 3 configuration. You always have the choice to go back into one tool but it will automatically get to all the configuration and import it as soon as possible. A little bit about how to write a KDE 4 configuration in 99.90 code. I mean it's a very stupid idea and often enough we face a problem that we have to automate some process but you're sure you are familiar with this problem that you do in a certain job a lot of times during the day and you're just annoyed by the tools that are available so you write your own script and improve it just for your personal use case. So one use case we have pretty frequently is to watch the build status in the open to the build service but we have, as we said earlier, a lot of packages in the build service infrastructure so we want to monitor then and see as soon as possible when one of the packages is fan to build so that you can fix the problem. Which you want to write as well because you want to see when the latest re-sync of the packages comes with the upstream repository and then you can install those packages, right? So this is the kind of thing that's useful to you too. So we won't show you that it's just as easy as writing a little bash script that you could use in the command line. It's just as easy to write that as a GUI script and I inscribe it. We also give you a clear advantage and the advantage we show by just showing how much the tools we use right now are not up to our task but we just show the two possibilities you have right now for watching how the build status of your process is. There's one as a command line tool or C which is used for command line access to the open to the build service. You can follow this command line or C project to see an overview about your packages in a separate repository and there's also a web front end which you can also use for doing the same thing as we did. You just show it to you. This is the output of project results if you have more than two packages. I don't know if you can see this but find a failing package please. On the diagonal you have all the packages and on the vertical you have all the distributions that builds for and then you have these lines and these dots and you have these CTS that are in part of it. So we tried to figure out which package failed for which resolution and I think it's not very obvious and it's even worse because it's just that over again it's a place for it so you have a lot of trees. So you're going to start at K ruler at this point and trying to look and line things up using K ruler. But that's a good next alternative. So we think oh yeah there's a web front end that is a pool. You can use that. So we start it up and watch the monitor and see oh it's all green so it's green. It has to work right. So we scroll a little bit more and then we see this there's a package that failed. You can see it over there and right on. Which package is it? The problem is that for some reason the web UI is going to see the package and the repository at the same time so it has this little supply at the bottom and you can either see which the package names which is on the forum on the left side or you can see the build state but you can't see both at the same time so you're always going this and that way. Obviously build from web service is an open source program. You could download it and fix it but by the time you've got it that's the project you can deploy it on the server so this is a quick way. So obviously as we said already we're really lazy when we don't have time we just want to have something now so we just set out and let's see how fast we can get something that's more useful just a little bit more useful and the target was to be faster than the time you need to set the size so in addition how we require this we have no idea how the build service works and we have no idea how the build service can be accessed over the API interface which is very very documented but we still don't want to be a couple of pages of documentation just want to have a very quick result. We do know a little bit of Python and we've used it for very small common flying script in the forum and we also have a web protocol to see the forum so we thought we can combine with all of that. First of all we will just sketch out a little bit why it's a TT interface designer which is a very useful tool to just design the interface I've cut off the actual toolbars and stuff where you can track in your widgets and just align them but this is what we came up with it's a very simple interface that we want to show and this is just the overview which we fill in with later It's a table widget so it's kind of like a spreadsheet you'll see that in a minute Now we have an interface where we only need this implementation so as we use Python we realize OSC is also written in Python so instead of learning how the build service API works it's just going to use OSC for that trying to run it in polythine and try to parse the output we saw before and try to figure out how to present it nicely because it's important because it's written in Python so we can just import it so what we're doing here is actually over there we just import the OSC tool in our new Python script and initialize it this is the only metric line we have to figure out it took a few minutes to figure that out and we import also the user interface which is just designed in the place designer so we are not actually writing any code so far we only decided why and we import just set up the basic things and import the OSC for doing the actual work and we import the user interface which is just designed there's no code written in any way so far So running designer is a Python model called overview which has a class nick called UI name window you'll see that in a minute So this is the slide you probably can't read the interesting thing is that this is the whole script it's not really routinely written anywhere but this is all that we have to do what we're doing here basically is to just fetch a result we have the OSC interface which is given up to us as an XML document and then just run through the XML tree and figure out which names and why we want to keep up and keep them in the list and over here we're doing a specific and simple thing which is just the output into the table which we designed in the app designer Is anyone here a real Python wizard? I mean if you look at this you'd probably say these guys really don't know Python because they've written a nested for loop that you probably could have written with basic on a Commodore 64 As we said before we are not a Python wizard so we can trust that there are probably many more hidden ways to express what we did but this is just work for us but the important thing is we go through this table and build results and for each one we create a table widget item which is a box that's spreadsheet which we'll now show you but this is the result and maybe 20 minutes or something like that as you can see we improved on all the things that are discussed before we can see at the same time which package failed for which distribution and we can quickly switch through if you want to So you've got this combo box here you can select different repositories you can type in your own repository and it'll go away for a section or even though it's a very new release we already have pretty much complete bind links in Ruby and in C-sharp as well as Python and when it comes to pure Qt we also have Java bind links KD for Java bind links not there yet but coming to it Just want to tell you I'm not sure how well it's working so this is the potential item you can see I can scroll up and down here you scroll left and right and you don't have enough to scroll up and you don't have enough to scroll up Make the window smaller because it's a tail widget the headers stay in one place while the content scrolls we solved our little artificial problem that we set for ourselves at the beginning to make something that we could see the results and see the headers Does anyone have a business repository? Okay Once you check it, what's your business at home Funky Tangle Funky Tangle, big-ass big thing? Big-ass big thing Funky Tangle Watch it this morning and you can hear it Oh Sorry It's fascinating to prove that it's not a scary thing if it's just words but we are happy about it except for Okay You might find it useful We just wanted to show you what it is to write it And if we had more than 20 minutes we would set up a couple of KD notification events so that when your repository changes and a package goes from failing to building you'd get a nice little pop-up standard KD pop-up saying KD base 3 plasma has now been updated It's pretty easy We only have 5 minutes left so We have two options I don't go into too many words at the moment It's probably just two yes and a question The question be on the front Yeah You've got the binding and I'm using the one pretty good but are they packaged in the built-in? Almost They have a couple of problems but they will be packaged very soon I was presently working on them last week but I don't have enough time so it's pretty easy to do There are stable bindings of the Python-KD4 Okay Any more questions back? Your prescription table item Is that released as a package or is it just that script? We've just packed out something just that script If you want to improve it then you can just I just want to use it It will get a lot more useful if we didn't have to concentrate that it had to fit on one slide so we've got a lot more things to fix There are so many options we can add a filter for example you can only filter for failed packages it will be useful if you want to improve it if you want to improve it failed packages it will be useful for really big repositories but yeah our maker shape was we want to get it done just now we don't want to spend half a day on improving and a lot more features Just want to show that this is really possible with very very little effort You don't want to? Okay I just skip over a few slides so what you probably already know if you used the table 3 version is that we changed the way you have to install the user but previously you needed just this stack of pile to install the user before that's a little bit too much so we did one to be installed our target was download one to be and get something that is roughly complete it should be compared to the default install of the DVD media the DVD media is obviously a lot larger it has a lot more implications but not all of them are installed but essentially a very small set of the DVD is installed by default but you can always select more packages so we want to make sure that the default set hits on one to be to achieve that we had to cut down a couple of features the main feature we had to cut down is the language support we have relationships with internationalisation for a lot of languages which don't fit on one to be so we have to decide for one language with the possibility to create new one to be version for another language to select a talk it's not hard for one to a one specific language but it's just hard for one language if that's a big problem you can just expand the installation process by adding one language packages to start installation so as soon as you add online repositories during installation you will automatically get new features if you select a country different in the US you will automatically get the language translation for your country so the problem which I said at the beginning was the default set was roughly 1g but we only have 700g so how do we make that work we came up with a list of things we can do we remove optional parts of the distribution which are not that much required so this was quite a bit of effort to find out what do the users want and what do they need not so much just still something which is unknowing in a way that might improve the set of packages so you have feedback about that things that you are missing from the ones that you need here just a big chunk of the package set before was actually the selection of fonts so we could reduce the amount of data was to just reduce the amount of fonts to ship by default we also changed all of the way our distribution was built to split out languages from the packages previously languages they are usually part of the main package so we installed the package and also installed the translation at the same time we set up a simple mechanism to be able to automatically split out the translations and also be able to provide them automatically again so this is what we came up with, we created language bundles language bundles basically provide you with all the translations you need for the ones you need here but they are just packages for one language so you install one bundle basically per language so what you are doing is if you are installing one to keep but you want a French version you will just add the French bundle and get your French translation to the ECB so this just the most interesting thing I just sketched all the sizes on the CD is wasted sorry or how it is banned you can see that the care about the stuff is actually just a basic how to boot your system the basic system call it like tool so it is not the stripped down system you have pretty much the complex stuff still available you can also see that open office is a big chunk on the one CD version and only this is less important it is actually a tiny specific part one thing to remember is that we are doing that so we can get KDCD out but the improvement of the distribution that that causes available to every other desktop to the base distribution to DVD means you get a smaller distribution you get more applications you get faster downloads thank you for coming