There are some area’s we need some further work, like the spam setup and we see some bounces which could be valid or not valid. Seems like the bounce processing of mailman in the previous setup might not have been working correctly, so we see an above average of automatic unsubscribes from mailinglists to catch up with that.

The old server was qmail based, a small mail server, which has enormous speed and it served us well for the last ~decade, but it showed its age. We have now switched to Postfix, a modern mail server, which gives us a bit more control to the queues, better logging and it’s well known, so easy to get support for.

Enjoy the new mail server, and if there are any problems, file a sysadmin bugreport as usual. Dirk did the work on the new server, so hug him when you see him.

KTown was a multi-function server, it performed a whole range of services, ranging from serving some sites, being the main mailserver for all kde.org traffic, being a stealth nameserver and serving the master source tarballs for everything we produce.

Once we decided to decommission the server we drafted a plan to move all the services around and organize them better. We moved the sites to our master webserver and rethought about the nameserver setup. Historically domain names were mostly registered by individuals, we have transferred most of those now to the KDE e.V.. Registering domainnames privately is just a bad idea. Times change, people come and go. In the end getting changes done from people who have been inactive for years already is no fun. I’m happy we have solved this now. Last week we even transferred kde.org, it was registered by Trolltech in the past. Though it was in good hands with the sysadmins of Nokia, we felt it was better to keep everything together.

For all those domains we need nameservers. bytemark.co.uk was kind enough to provide us some nameservers we can use.

Another server we worked on was Immanuel. The hosting arrangement is a bit dodgy, so we can not rely on it being repaired quickly after it crashes. That means we can not put mission critical stuff on there anymore. That means we needed to move stuff around. That means bugzilla had to move, we originally planned that to happen while upgrading to bugzilla4, but we had to move it before that was ready. Immanuel also served some websites which we moved around.

Next to that some remarkable things are: move of kdedevelopers.org, including a new layout, usual drupal updates and the update of the mediawiki version on our wiki’s.

Since that’s all done, we are looking towards new things. We have two somewhat bigger wishes: deal with api.kde.org / ebn and we want to start building a build farm, not for our own pleasure, but to have continuous builds of our repository and have reports when the unit tests breaks.

Call for a server

But I first want to start with api.kde.org, Allen Winter is currently maintaining it, but I think he needs some help to get it in a better shape. For that to happen, I would like a new server. It needs to have some hard disk space (like 120GB, as it needs to have a full copy of the svn repo + everything in git), a somewhat powerful processor and some memory.

If you are a hosting company and want to donate something like that to us, drop us a mail at sysadmin@kde.org or talk to us on #kde-sysadmin at freenode…

We have three mirrors for both. One not located in europe and two are. If you are europe you want to use the ones in europe and if you are physically closer to the third mirror, you want to use that. That improves everyones latency and probably makes anongit/anonsvn a bit faster, as you should always get the server which is close to you.

We have not heard anyone complaining about this change, so I figure that the best compliment you can get. It also means that we are now able to take out mirrors and add new mirrors within some minutes. In the previous setup it took us 2-3 hours for the nameservers to spread the news. Which sucks if a mirror suddenly has dropped out. This is now solved.

Another option we have is to push load info to the system, the system can then adapt and traffic some more visitors to a server with lesser load. We have not yet implemented that, but it’s nice that we have this option.

We will also explore the possibility to use this system for the ftp-mirrors, so ftp.kde.org will return automatically a mirror close to you. But if that’s going to happen remains to be seen.

Anyhow, you can do a quick test how far away you are from a anongit/anonsvn mirror by executing dig -t txt anonsvn.local-kde.org @ns1.geoscaling.com, this will return the city you are in and the mirror you will be using. Please note that in many cases the city is a bit off, but that does not really matter as we don’t have so much mirrors that it would really make a difference. Enjoy.

This service was kindly donated by GeoScaling. They are providing such a service for free currently. The support was awesome and fast. They even started to chat with me on the site while I was setting up the system, asking if I had any problems. I wish all companies would be like this.

In 6 months to a year we can expect the first users who only have IPv6 who want to contribute to KDE. This is due to the fact that we have contributors from all over the world, it can be expected that we run into someone like that as one of the first. IPv6 only users can not approach IPv4 only servers. That means all our servers need to be dual stack. They need to talk IPv4 and IPv6.

Today I heard people say that users should not care, they should buy new hardware which is IPv6 capable and get an address automatically. Well, forget it. It won’t happen. It is highly unlikely that father and mother will buy a new ADSL modem before there are servers which can only talk IPv6, which means those servers won’t be accessible for them.

The other way around is even more problematic. IPv6-only users can not access any server which only talk IPv4, which will be a lot. I would not like to be in that position. Sure there will be NAT like constructions for it, but those will have their own set of problems.

I tried to buy a IPv6 capable ADSL modem 2 weeks ago. I could not find a suitable one. Hardware vendors should be kicked into action now, now, now.

I’ve connected some KDE servers to IPv6 recently. Most providers and hosters do not provide native IPv6 connections yet. Those should be kicked into action yesterday.

Back in 1999 people were scared about the millennium bug. People had all kind of doom scenario’s what would happen when the year would end and a new millennium would start. That did not happen, this will happen. And you should be scared too, time is ticking.

The current switch to IPv6 is many times more scary than the millennium bug. The thing is, the press conference given today gave a much more positive image than the currently reality is. I admit immediately that the IPv6 technology is proven and works. Most of the applications and operating systems are ready too. But the hardware vendors, which sell things like ADSL-modems are not ready and most hosters and providers are not ready to deliver IPv6 to the consumer.

For KDE, we are in good shape. Pretty much all our main servers are IPv6 capable or even talking it already. Some servers are connected, but the services are not yet connected to it. Just a matter of sitting down and fixing it. We have a good overview of what needs to be done and we can be ready for IPv6-only contributors before they appear.

We have several hooks. There is one that checks the end of line signs, one that checks for invalid licenses, but also the ones that deal with keywords, like the one for closing bugs, or CC’ing someone. That brings us to another set of hooks, the ones that sent out mails to CIA.vc and the commit mailinglist.

In the past months we have worked with the hooks written in the past for gitorious, if I’m correct. In the meanwhile we have detected multiple problems, which began to build up in the last few months. For example keeping the whole diff in memory for all the processing is convenient, and also very possible in projects like Amarok and Konversation, but now kdepim is also using it, we reached the memory limit quite often, which broke stuff. We have solved that now, and used a quite intensive set of kdepim commits from the past to make sure the new hooks were up to the task.

We also tried to match the existing mail layout as we use it for svn. The git repo mails where a bit messy, and that’s been cleaned up now. We have added new headers, like X-Commit-Ref, X-Commit-Project and X-Commit-Folders, so that makes it possible for commitfilter to be able to support kde repos natively. Especially the lack of X-Commit-Folders broke many people’s filters.

The keywords syntax has been improved, some of the syntax that was supported for svn commits did not work for git, we hope to have corrected them, so they work now. And we moved from bash+ruby+perl tangled mess to pure python, which makes it way better maintainable for everyone.

I’m writing ‘we’, but as usual, I did not do much. All credits go to Ben Cooksley, so all comments should go to his first blog. He is one of the people that works pretty silently, but does amazing work. If I could propose someone for an Akademy Award, I would definitively put him on the short list. Luca Beltrame (or we rather know him as einar77) also helped, so give him a beer if you see him and sent the bill to me. Hmm. I might take that back.

Anyhow, enjoy the new hooks, and if you spot regressions, feel free to contact us.

For the last couple years, I ran KDE from trunk from svn. That meant that I only had a need for a basic Linux OS. Debian was fine for that. Combined with Equives I could still use some distro packages while compiling most of it myself. But there were problems. Mostly these were caused by my own lazyness in configuring the right stuff in the right way.

Dealing with Virtuoso, Mysql embedded, OSS, Phonon, packagekit, consolekit, hal, udisk, polkit and all that stuff became a boring and silly exercise, I never got it all right, which meant working with no sound for a while, having no permission to change the time from within KDE and that kind of little annoying setup bugs. Compiling the stuff became harder too, as you sometimes only noticed when compiling kdebase that a kdesupport lib had moved to git and you had to fix that.

But my life has changed too. I no longer hack on various stuff, I’m happy to work as a KDE sysadmin with a great group of people. The only thing I want to keep working on now and then is RSIBreak, but for that I don’t exactly need the whole of KDE from SVN. But I also do some work for the Release Team, so I can not be running to behind with the KDE version I’m running.

That made me decide to switch away from Debian. They are doing great work on KDE and I’m sad to move away, but they just don’t provide bleeding edge packages currently. Which is absolutely understandable as they have focus on a rock solid stable experience for users. I choose Fedora because I was told they rock in packaging KDE and are providing packages days after releases.

And I’m so happy so far. Installing it was kind of hard as I ended up in GNome, without having indication how to switch to KDM and KDE. But after solving that, I’m pretty happy. There is stuff to explore, like those SELinux warnings (yes, this time I did not disable it right after installing the distro) and there is stuff that just works. Like sound. I’ve no idea if I’m running OSS or PulseAudio, or which phonon backend I’m using. And I don’t care, it just works. Just like polkit, which I never ever got to work.

So up to now, big compliments to the Fedora team. Nice job, and that needs to be said too sometimes!

This blog is a call to find someone who wants to implement this for us. The basics are there, there is a REST API for reviewboard which should allow this.

We also have hooks in place for git and svn so those can be extended. Some things that needs to be resolved by the one doing the work:

• write the script to fire the api call to reviewboard
• find a way around the fact that it looks like you have to be logged in before you can close the request.
• make sure the script is non-blocking, that means the one committing or pushing should not have to wait untill the results of the api call have completed, should happen in the background
• there is a reviewboard for git and svn, both need to work, so the hook for each need to be adjusted.

If you are interested in implementing it, come to the #kde-sysadmin channel, and I’ll add you to the relevant bug report!

I can see from closeby how much work is involved with making all this happen in the first place, all the coordination involved, making sure no translations are lost, former svn locations cleaned up, review requests can be filed and kde-commits mailinglists does not get flooded on the initial push, with or without tags. I take my hat of for all the people that are doing all this work silently, and professionally.

For now only reasonably small projects have converted, but it won’t be long before this will change. I slowely see requests for whole modules come in. kdeplasma-addons and kdepim, all have concrete plans to move to git. I also saw some test conversions for kdelibs, so that will happen too. So, be prepared :). I guess it won’t be long before most KDE modules will switch.

We’ve been kept a bit to busy with all these conversions, we’ve failed to generate xml-files up to now for example. That would make it easier for tools to fetch repo’s, or hook in lxr and scripty into that. For example that would enable developers to turn of scripty for a while for their project by using a switch in the projects.kde.org site. Also applying consistent theming to all the sites has failed. We seriously need more people in #kde-www. I’m sure we will get to all this some day…

For example, with the amount of projects increasing, you can also see the fun bits, like the news page http://projects.kde.org/news, which is an aggregation of news items of all the projects. Think it’s about time this feed gets added to dot.kde.org or finds a place on www.kde.org.

Also improved this week is the project overview page, see http://projects.kde.org/projects. Not only has the hierarchy in modules returned, but the page itself has been pimped beyond recognition. The hierarchy required Ben Cooksley to hack on Redmine, we will feed those modifications back upstream. Impressive work there.

Now the hierarchy has returned, some interesting pages have appeared, like http://projects.kde.org/projects/extragear/activity. On this page you can see all activity which happened in extragear today. You can also add ‘/multimedia’ before ‘/activity’ to only see the activity in the multimedia section of extragear. This gives interesting opportunities for, for example, extragear.kde.org to integrate the RSS feed, to make it somewhat more dynamic.

This also is the start of the next step, which is to write software which will automatically create a XML-file describing all the projects. This XML-file will be used by Scripty, LXR, EBN to know the location of the different projects. Also kdesrc-build can use this file. So, if you want to know how that will look like, talk to us (well, Eike Hein (Sho_), he is on a mission) on #kde-sysadmin on Freenode.

For example in the future, it will be possible to turn Scripty on and off via a setting in projects.kde.org. Or indicate which branch is the stable branch, so translators know which branch has to be translated as well. Something that is kind of messy right now for extragear applications.

Another page that is interesting is when you click on your own name on the top right navigation. It will show you in which projects you are involved, and shows your recent activity (OMG, was my last commit in kdesupport/akonadi really on 2008-06-18???). Again, everyone with an account on http://identity.kde.org has access with the those credentials.