www.michael-jansen.biz

Version 0.4.0 is available for update from rubygems.org. Have a look at the changelog

There are two features. Colorized output for better readability and a progressbar when compiling/installing.

The release lays the groundwork to work around the cmake issue with rpath handling when installing in different prefixes i mentioned in my last blog post. I will push the necessary changes to the receipe today. The solution is set -rpath-link correctly. It's done like this (from my setup):

CMAKE_EXE_LINKER_FLAGS

-Wl,-rpath-link,/kde/trunk/support/lib64

CMAKE_MODULE_LINKER_FLAGS

-Wl,-rpath-link,/kde/trunk/support/lib64

CMAKE_SHARED_LINKER_FLAGS

-Wl,-rpath-link,/kde/trunk/support/lib64

Mike

I just released the version 0.3.3 of build-tool. Have a look at the changelog.

I'm currently thinking about a new minor version. The next feature i would like to add is to automate the after installation stuff. When building and installing packages as a non root user one often misses out on some important features because of some not as setuid root installed scripts programms. build-tool has currently rudimentary support for it with the finish_installation.sh file. But i would like to have the support more automatic. Like it is currently done with qts syncqt script. Which is automatically called after each rebase.

The idea is to allow for some kind of after installation hooks in recipes. Those should be scripts that are automatically run whenever an installation happened. The script should have two modes. First the "is something to do mode". The script for kdelibs for workspace for example checks if the installed kcheckpass script is setuid root (that one is needed for relogin after locking you screen). build-tool runs all the scripts and collects the ones which signal there is something to do. When all modules were build and installed it will run those with sudo in the 'do it' mode. The reason why it is done at the end is because if not one would have to sit in front of the terminal in case the script wants the admin password.

I even think about installing scripts like /usr/share/xsession/kdetrunk.session from workspaces after installation script. Which would allow for automatic inclusion of the kde trunk session into your existing login manager.

On the recipe front i added kupdateapplet (but there are some merge request pending before it is usable) and dbus. The dbus versions before 1.3 have a bug that makes krunner crash very often. And 1.3 is not available for most distros. So it's now possible to compile dbus yourself and enjoy an more stable kde. But to be on the safe side you would have to reconfigure and recompile most of your self compiled packages. So beware.

On the negative side i found out about a limitation of cmake that makes the setup i currently use in build-tool to build kde not always work (or more preicisely to accidently work). The link interface changes mean that sometimes not all needed directories will be picked up and added to a linker command. Effectively meaning your distro libraries or in case of phonon the qt phonon packages will be picked up instead. In case of additions to the abi that means the linking can fail. The kdesupport phonon for example has a new method added so the qt lib will not satisfy all symbols. To be clear. This is only a problem on linking not on compiling so it is not enough to remove devel packages.

So the minute i found out how to activate the full linker interface again i will push that change. Google did not help me yet.

I have just released build-tool v0.3.1. It contains only small changes. The only new feature is qmake support which is needed for qt/qoauth support.

There are many changes to the recipe because of all the svn -> gitorious -> git.kde.org moves. Fetch them with kde-build incoming -f and review them carefully. There is manually intervention needed. Have a preview here kde-trunk-recipe activities. I hope i catched them all but who knows. If someting is not working ping me.

I have released version 0.3 of build-tool. As promised last time this release makes it possible to maintain the recipes separately from the code. Build-Tool comes without recipes starting with this release.

Upgrading

To upgrade use sudo gem update build-tool. If you are currently using the kde recipe issue build-tool recipe add git://gitorious.org/build-tool/kde-trunk-recipe.git kde after the update. This will install the kde recipe from the given git repository under the name kde - which is the name it used when bundled with build-tool.

The recipes from now on are just directories under ~/.build-tool/recipes . Check now because you have to manually update the recipe from now on to be up to date. Whenever something changes in kde land i will adapt the recipe and push the changes to gitorious. The command recipe incoming will show you if there are changes available. But you have to update/rebase the recipe manually. You have to carefully review the changes for steps you have to do manually.

To fetch the latest changes to the recipe without making them active issue kde-build recipes incoming -f. This does git fetch origin behind the scene in ~/.build-tool/recipes/kde. An example output:

f70d9c762d9f72c8759cfc32ed882694a9240bbc
Author: Michael Jansen
Date:   Tue Jun 22 15:11:57 2010 +0200

    Konversation moved to git.kde.org.
    
    NEEDS ACTION: Edit .git/config . Change to
    
    ...
    [remote "origin"]
        url = git@git.kde.org:/konversation/konversation.git
        fetch = +refs/heads/*:refs/remotes/origin/*
    ...

commit aaaae3c563ecb022a5bdce7032899ca19194589c
Author: Michael Jansen
Date:   Tue Jun 22 15:10:17 2010 +0200

    Amarok moved to git.kde.org.
    
    NEEDS ACTION: Edit .git/config . Change to
    
    ...
    [remote "origin"]
        url = git@git.kde.org:amarok/amarok.git
        fetch = +refs/heads/*:refs/remotes/origin/*
    ...

To just review the pending changes without fetching omit the -f(fetch) option.

To make the changes active go to ~/.build-tool/recipes/kde and issue git rebase origin/master. Make sure you have done all manually needed steps when doing that. Remember this is a developer tool.

We have done it. Just lay back and glow in what we achieved: Kontact/khtml are on par with Outlook/Internet Explorer

That looks SOOOO convincing.

It's about time to pencil my two cents about the gran canaria desktop summit into the great notebook called world wide web.

I'm contributing to kde since January 2008. This years akademy was my first ever conference of any kind. I knew noone and my hotel was flooded with gnomies. Nice guys really. And they didn't even bite. Who would have thought of that :).

Had two nice weeks. But i suspect beeing part of some of the greater kde communities like plasma, kate, marble, koffice ... makes it even more interesting. I even had to explain why i chose to mostly work on kdelibs stuff :). Interesting question but i'm not quite sure my answer helps in attracting more people to work there.

I met my favorite kate developer ... anyone working on a vi mode HAS TO BE a great person. I even tried to motivate him by offering a crate of beer for a working vi command line mode. Erlend ... don't forget about that. Beer has a drink-by date here in germany and in eager anticipation i already bought the crates. Yes i make it two crates :-) . I'm waiting!

Met some nice local guys and prompty forget their name. Guys if you are out there reading this please contact me. I'm the tall one with curls. And i want to have that picture you guys made.

We made a nice picture showcasing that in kde we grow with our projects. Blauzahl has the better version were you have a standard of comparison (chani iirc) but since she failed to post it yet i will have to do it. Update: Daniel posted a link to the image in the comments. Thanks.

Andre Wöbeking, myself, Volker Krause, Lubos Lunak and David Faure with Chani in front.

And i have never seen any of the pictures showcasing that kde people know how to party. I mean those drinking two beers simultanuously. The dancing adventures of mr. knut. claudia, erlend, andreas, casper, me and ... dancing.

Have a look at my galleries at smugmug. Thanks to ervin for pointing out the site. But he could have posted about the referal program. So if someone out there wants to have it's own smugmug gallery please contact ervin or me.

• Gran Canaria - Las Palmas. Not desktop summit related pictures of the city.
• Gran Cararia - Desktop Summit

See you all next year.

See Bug 190412 for an explanation. The problem is a little broader than the bug reports. See Bug 193085 for a more detailed explanation of the problem.

The problem was me fixing khotkeys without completely adapting it to the new global shortcuts framework in place for kde 4.x . I just didn't realize the consequences. Khotkeys in 3.x ungrabbed the shortcut if the condition was not met or the khotkeys was inactive. In other word whenever the focus was not on an konqueror window ctrl-w was freed. With 4.2 that important bit of functionality was lost. ctrl-w was grabbed all the time. My fault.

If you are on kde 4.2 and want to have your keys back then go to the input actions kcm (kcmshell4 keys) and remove all shortcuts associated with inactive hotkeys. Or go to the global shortcuts kcm (kcmshell4 keys) and disable all khotkeys shortcuts you don't like.

With 4.3 inactive global shortcuts are not grabbed anymore. I made the change last weekend. if you get your hands on the next snapshot and still have problem with that ping me.

That is some kind of unexpected comeback from a classic out of the pre kde 4.0 development time. I once managed to break the 'e' key for all when working on khotkeys. Me fixing khotkeys exposed a qt bug. Qt did parse the "Win+e" string from kde 3.x as 'e' because it didn't recognize the Win modifier. It is called Meta in qt. We fixed the symptom because we couldn't fix the cause and everything went smoothly for some time.

Then reports about that problem having a comeback started to creep in but i couldn't get my hand on someone experiencing it. Not everybody looks my way when having keyboard problems. The last days comawhite - a irc regular - had the problem and we could pinpoint the cause.

The problem this time appeared because of a different reason. comawhite is a gentoo user and his x11 setup didn't provide a modifier usable as the meta key. You can check that with xmodmap -pm. I get: xmodmap: up to 4 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 Alt_L (0x40), Meta_L (0x9c) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x73), Super_R (0x74), Super_L (0x7f), Hyper_L (0x80) mod5 Mode_switch (0x8), ISO_Level3_Shift (0x71), ISO_Level3_Shift (0x7c) The next sentences are a cross simplification. Since the invention of xkb things got better but much more complicated. X11 has the concept of modifiers. You can see 8 modifiers in the output: Shift, Lock, Control and Modifiers 1-5. Only the first three have predefined meanings. An application has to look at the associated keys to see which effect a modifier is supposed to trigger. As you can see my mod1 modifier is mapped to the meta and alt key. In this case alt wins and meta is unusable because it is hidden behind alt. So we use the super key as meta key on my keyboard. That's the one with the redmond symbol on it.

For comawhite mod4 was as empty as mod3. Some kde code didn't care and still grabbed the shortcuts with meta in it globally. Meta was just dropped. So for 'Meta+E' only e was grabbed, for 'Meta+X' only x was grabbed. Makes up for a pretty messed up session. And you couldn't notice the reason because the code didn't trigger the action. So the key was just eaten.

I fixed the kde code and comawhite fixed his setup by adding xmodmap -e "add mod4 Super_L" xmodmap -e "keycode 115 = Super_L" to /etc/X11/Xmodmap. The 115 was retrieved by xev and pressing his win key.

And qt having some problems with parsing QKeySequences from String. Since nokia opened the qt repository to external contribution i will try again to fix it. See my Qt Patches.

Update 20.05.2009

I just found out that there is another problem having this effect. See Bug 193150: can't type 'e' key. After starting amarok it get's even uglier. Best idea is to skip current snapshot and use the one from next week.

That's because on some keyboards Alt+PrintScrn is used as Sysreq. You can use xmodmap -pke | grep -i print to check if you are affected. If you get something along the lines of keycode 111 = Print Sys_Req Print Sys_Req Print Sys_Req there is no alt+printscrn for you.

Someone managed to put a really bad hack into kde hardcoding keycode 111 to the printscrn key so it worked if you changed the shortcut manually in the config file. That code managed to be there since 3.x. So much to the many eyeballs theory :-) : I removed that hack so it will stop working with 4.3 because it breaks keyboards where 111 is mapped to some other key.

Just a short note that i commited a change to kdebase reenabling shortcut support in kmenuedit. It's now possible again to assign a global shortcut to an application in kmenuedit. It was possible for some time in kshortcuts but it looks like no one noticed.

Please tell me if you have problem with that feature.

The gui side in khotkeys is not yet finished but i'm working on it. If someone would like to help polish that contact me.