KDE is a nice community, but we can do better!

Since a long time KDE.org has been referring to KDE as a team of people, a community, and not the software products we make.

I agree with this but sadly sometimes we struggle in being a nice community to live in.

There's a few things I think we can improve:

• Being better 'winners': We are a big community, at some point we have to take community-wide decisions, and it's impossible we will all agree on something. If you are part of the 'winning' group, be gentle with the people that 'lost', sure you think you are right, but they think the same and think the rest is doing a terrible mistake, so when you talk with them be polite and point out that the majority is going in the other direction, but that you still appreciate all the other stuff they do, etc. They already 'lost' so there's no need to put their head under your foot and do an evil laugh.
• Being better 'losers': We are a big community, at some point we have to take community-wide decisions, and it's impossible we will all agree on something. If you are part of the 'losing' group, be accepting that you 'lost' and try to carry on with the amazing work you do in other areas. Sure you are allowed to some venting, but it should be all within the limits of not trying to drag the discussion forever and not trying to destroy the project just because you disagree in one decision, so yes, you're allowed to some small complaining but understand that the majority decided different than what you think it's better, accept it and carry on, you'll be happier :)
• Assuming good by default: If a sentence can be read in two ways, do not assume it was said in the worse way, assume it was said in the good. Will help keeping the discussion sane and constructive.
• Not workarounding by default: If you find a bug or shortcoming in kdelibs, KF5, Qt or any other library, don't workaround it by default, please report it to the library people and try to work with them to fix it. Library code is not that hard and if you fix it in the source, everyone will benefit from the fix, not just the users of your software because you workarounded it and kept quiet about it to upper layers.
• Not caring enough for the global: We produce zillions of different projects of software. It's almost impossible to have a global overview of "what the bad bugs are", so if you know there is a bug that is bad, and it's affecting quite a bit of people, don't say "someone else will fix it" and ignore it, share it with the wider community and if the current maintainers are missing or overworked I'm pretty sure we can find someone to have a look and fix that bug that is making people sad.

This doesn't happen all the time, but it happens more than I would like, so I'm just raising it up so that people think about it and try to improve :)

Of course I'm not saying I'm not guilty of the things I mentioned, but as the wise-man said: "Don't do what i do, do what i say"

Web developer: Help KDE with a few hours of work

At KDE we're trying to get people to donate more (I hope I don't have to explain to this audience why), one of the ideas floating around is adding a small "impulse donate" button to kde.org similar to the one at http://www.videolan.org/ (only with euros and without a "why?" link for now)

I'm not a web devel by far (though have done my fair share of copy&pasting php, html and css for KDE and other personal projects) but I understand it should not be "that hard"™, it would be basically doing some modifications of the kde.org sources, the capacity framework and doing some reuse of the existing paypal donation page code.

Anyone up for the work? If so, please contact me!

Commit your approved Review Requests!

By looking at KDE git Review Board I realize we have over 4 pages of "ship it"-ed review requests that are still marked as not commited.

This is nuts!

I know some of them are still work in progress (yes, it sucks that reviewboard does not let you "unship it" when you find something wrong or when some newbie mistakenly gives himself a +1) but I am pretty sure at least 3 of those 4 pages are stuff that was coded, reviewed, approved and then no one committed it :/

So please go through your reviewboard changes and commit them, or ping the maintainer of the app if you don't have commit rights (and if the maintainer is unresponsive for some reason and it's obvious you had his "Ship it" just come to me and I'll commit it for you).

KDE Applications 4.13 released

Today we've released 4.13 which is probably the best KDE Applications release ever :)

It also marks the second release we do with a four months schedule instead of a six month one. I think we've ended up with a pretty nice cadence in which we are faster delivering features and bugfixes to users, which at the end is what is important, since the earlier people get the features the earlier they'll find the bugs (let's accept it, all software has bugs) and the earlier the bugs are found the earlier they can be fixed. So basically it's faster progress :)

We have also made good our promise to keep our tests passing, as you can see everything from this release is green (kde-workspace is not green but is not part of the 4.13 release). So kudos to all developers for being awesome in that regard too.

Let's all celebrate on this release but not forget we need to keep working full steam ahead on the releases of KDE Frameworks 5, Plasma 2014.06 and KDE Applications 4.14.

Finally I'd like to remind you that most of the people doing KDE development are volunteers and they invest their time in making this awesome software for you to use for free.

Lots of them even spend time to travel abroad to meet each other in Sprints were they do concentrated hacking for a few days, so if you appreciate the work they do in those Sprints please donate some money so we can actually help them travel and we can make more Sprints happen :-) http://www.kde.org/community/donations/

As anecdote, I had the pleasure of meeting the guys from the KTP Sprint this Friday and after dinner they went back to hacking instead of joining some of us for some beers. That is dedication!

ASAN and libraries (2nd part)

In ASAN and libraries I claimed you didn't need to compile a library with -fsanitize=address to get ASAN to work over it. Well it turns out that is only true in some cases and in some others like the one in this example you actually need it. So here comes a different example and the differences of using -fsanitize=address and not in the library code.

shared.cpp
#include "shared.h"

Foo::Foo()
{
int a[1];
a[2] = 3;
}



shared.h
class Foo
{
public:
Foo();
};



main.cpp
#include "shared.h"

int main(int, char **)
{
Foo f;
return 0;
}

Let's see what happens if we do

export ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-3.4
export ASAN_OPTIONS=symbolize=1
g++ -Wl,--no-undefined -shared -o libshared.so shared.cpp -g3
g++ -fno-omit-frame-pointer -fsanitize=address main.cpp -lshared -L . -g3
LD_LIBRARY_PATH=. ./a.out

As the suggested in the previous blog entry.

Nothing, no error detected.

But if we change to

export ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-3.4
export ASAN_OPTIONS=symbolize=1
g++ -fno-omit-frame-pointer -fsanitize=address -Wl,--no-undefined \
    -shared -o libshared.so shared.cpp -g3 -lasan -fPIC
g++ -fno-omit-frame-pointer -fsanitize=address main.cpp -lshared -L . -g3
LD_LIBRARY_PATH=. ./a.out

==13069== ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fffe74fafa8
at pc 0x7fb0ef71f792 bp 0x7fffe74faf60 sp 0x7fffe74faf58
WRITE of size 4 at 0x7fffe74fafa8 thread T0
    #0 0x7fb0ef71f791 in Foo::Foo() /home/tsdgeos/test/shared.cpp:6
    #1 0x40074a in main /home/tsdgeos/test/main.cpp:5
    #2 0x7fb0ef37aec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #3 0x400638 in _start (/home/tsdgeos/test/a.out+0x400638)
Address 0x7fffe74fafa8 is located at offset 40 in frame <__base_ctor> of T0's stack:

Boom! We get the error :-) So my conclusion that ASAN wasn't needed on libraries was bad. You need it. Thanks Zecke for pointing me to my wrongness :-)

ASAN and plugins

In ASAN and libraries Milian asked if the reasoning for libraries also applied for plugins. Since I had no idea, I had to try it.

Here comes the output

main.cpp

#include <QDebug>
#include <QLibrary>

int main(int, char **)
{
    QLibrary l("libshared");
    qDebug() << l.load();

    return 0;
}

shared.cpp

#include "shared.h"

static Foo f;

Foo::Foo()
{
    int *a = 0;
    *a = 33;
}

shared.h

class Foo
{
public:
    Foo();
};

export ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-3.4
export ASAN_OPTIONS=symbolize=1
g++ -shared -o libshared.so shared.cpp  -g3 -fPIC
g++ -fsanitize=address main.cpp -g3 -I /usr/include/qt4/QtCore/ \
    -I /usr/include/qt4/ -lQtCore

And then we run it!

$ LD_LIBRARY_PATH=. ./a.out 
ASAN:SIGSEGV
=================================================================
==7048== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
(pc 0x7f199c1326aa sp 0x7fff37e557c0 bp 0x7fff37e557c0 T0)
AddressSanitizer can not provide additional info.
 #0 0x7f199c1326a9 in Foo::Foo() /home/tsdgeos/test/shared.cpp:8
 #1 0x7f199c1326da in __static_initialization_and_destruction_0(int, int) 
    /home/tsdgeos/test/shared.cpp:3
 #2 0x7f199c1326ef in _GLOBAL__sub_I_shared.cpp /home/tsdgeos/test/shared.cpp:9
 #3 0x7f19a132b139 (/lib64/ld-linux-x86-64.so.2+0x10139)
 #4 0x7f19a132b222 (/lib64/ld-linux-x86-64.so.2+0x10222)
 #5 0x7f19a132fc6f (/lib64/ld-linux-x86-64.so.2+0x14c6f)
 #6 0x7f19a132aff3 (/lib64/ld-linux-x86-64.so.2+0xfff3)
 #7 0x7f19a132f3ba (/lib64/ld-linux-x86-64.so.2+0x143ba)
 #8 0x7f199d1a602a (/lib/x86_64-linux-gnu/libdl.so.2+0x102a)
 #9 0x7f19a132aff3 (/lib64/ld-linux-x86-64.so.2+0xfff3)
 #10 0x7f199d1a662c (/lib/x86_64-linux-gnu/libdl.so.2+0x162c)
 #11 0x7f199d1a60c0 (/lib/x86_64-linux-gnu/libdl.so.2+0x10c0)
 #12 0x7f199e0156b7 (/usr/lib/x86_64-linux-gnu/libQtCore.so.4+0x16e6b7)
 #13 0x7f199e010599 (/usr/lib/x86_64-linux-gnu/libQtCore.so.4+0x169599)
 #14 0x4011c0 in main /home/tsdgeos/test/main.cpp:8
 #15 0x7f199d5e8ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
 #16 0x401078 in _start (/home/tsdgeos/test/a.out+0x401078)
SUMMARY: AddressSanitizer: SEGV /home/tsdgeos/test/shared.cpp:8 Foo::Foo()
==7048== ABORTING

So it seems that "plugins are just libraries" applies here :)

ASAN and libraries

Yesterday we saw how to get line numbers in the stacktrace when using ASAN and gcc, today we're going to see how to deal with ASAN and libraries. For that we're going to use these three very simple files

shared.cpp

#include "shared.h"

Foo::Foo()
{
    int *a = 0;
    *a = 33;
}

shared.h

class Foo
{
public:
    Foo();
};

main.cpp

#include "shared.h"

int main(int, char **)
{
    Foo f;
    return 0;
}

We do the initial compilation:

g++ -Wl,--no-undefined -shared -o libshared.so shared.cpp -g3
g++ main.cpp -lshared -L . -g3
LD_LIBRARY_PATH=. ./a.out

and it segfaults :)

Now we want to use ASAN to find out what's wrong, where do we add the -fsanitize=address -fno-omit-frame-pointer? Logic would say that we add it to both places, but actually it's only necessary to add it to the final binary, i.e

g++ -Wl,--no-undefined -shared -o libshared.so shared.cpp -g3
g++ -fno-omit-frame-pointer -fsanitize=address main.cpp -lshared -L . -g3
LD_LIBRARY_PATH=. ./a.out

and we get

==10226== ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000
(pc 0x7f497563f66a sp 0x7fff77cc4310 bp 0x7fff77cc4310 T0)
AddressSanitizer can not provide additional info.
    #0 0x7f497563f669 in Foo::Foo() /home/tsdgeos/test/shared.cpp:6
    #1 0x40074a in main /home/tsdgeos/test/main.cpp:5
    #2 0x7f497529aec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #3 0x400638 in _start (/home/tsdgeos/test/a.out+0x400638)
SUMMARY: AddressSanitizer: SEGV /home/tsdgeos/test/shared.cpp:6 Foo::Foo()

There you go, no need to add the -fsanitize=address flag to the library compilation :)

Now, until a few minutes ago I did not know this, I actually was adding -fsanitize=address to the library itself; that comes with a few problems that i'll explain how i solved (just for completeness, since the above example shows you don't need it)

My logic was that by looking at main.cpp i knew nothing could be wrong there so i decided i wanted sanitize the library, my first attempt was:

g++ -Wl,--no-undefined -shared -o libshared.so shared.cpp -g3 \
-fno-omit-frame-pointer -fsanitize=address

which gives a linking error

/tmp/cc18Wen3.o: In function `Foo::Foo()':
/home/tsdgeos/test/shared.cpp:6: undefined reference to `__asan_report_store4'
/usr/bin/ld: /tmp/cc18Wen3.o: relocation R_X86_64_PC32 against undefined symbol
`__asan_report_store4' can not be used when making a shared object;
recompile with -fPIC
/usr/bin/ld: final link failed: Bad value

OK, so we are told to recompile with -fPIC, easy peasy

g++ -Wl,--no-undefined -shared -o libshared.so shared.cpp -g3 \
-fno-omit-frame-pointer -fsanitize=address -fPIC

Which still fails to link!

/tmp/ccNkpRZo.o: In function `Foo::Foo()':
/home/tsdgeos/test/shared.cpp:6: undefined reference to `__asan_report_store4'
/tmp/ccNkpRZo.o: In function `_GLOBAL__sub_I_00099_0_shared.cpp':
/home/tsdgeos/test/shared.cpp:7: undefined reference to `__asan_init_v1'
collect2: error: ld returned 1 exit status

OK, so if ASAN symbols are missing, let's just compile libasan in

g++ -Wl,--no-undefined -shared -o libshared.so shared.cpp -g3 \
-fno-omit-frame-pointer -fsanitize=address -fPIC -lasan

Links!

Next since I know nothing is wrong in main.cpp I don't need ASAN in there

g++  main.cpp -lshared -L . -g3

Compiles!

But when run it segfaults :-/ And if you debug it you'll see a stack trace like

#0  0x0000000000000000 in ?? ()
#1  0x00007ffff4894bf1 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.0
#2  0x00007ffff4894e32 in ?? () from /usr/lib/x86_64-linux-gnu/libasan.so.0
#3  0x00007ffff4895d9b in __asan_init_v1 () from /usr/lib/x86_64-linux-gnu/libasan.so.0
#4  0x00007ffff7bd8776 in _GLOBAL__sub_I_00099_0_shared.cpp(void) () at shared.cpp:7
#5  0x00007ffff7dea13a in call_init (l=, argc=argc@entry=1, argv=argv@entry=0x7fffffffde18, env=env@entry=0x7fffffffde28) at dl-init.c:78
#6  0x00007ffff7dea223 in call_init (env=, argv=, argc=, l=) at dl-init.c:36
#7  _dl_init (main_map=0x7ffff7ffe1c8, argc=1, argv=0x7fffffffde18, env=0x7fffffffde28) at dl-init.c:126
#8  0x00007ffff7ddb30a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#9  0x0000000000000001 in ?? ()
#10 0x00007fffffffe1ca in ?? ()
#11 0x0000000000000000 in ?? ()

So something weird in ASAN thing is going on, let's compile -lasan in also

g++  main.cpp -lshared -L . -g3 -lasan

Same crash :-/

Ok, so then you think, well, let's just add the fsanitize in. And then it works, but as demonstrated a few lines ago, the whole thing of adding -fsanitize=address and -lasan to the library was unneeded since all that was required was just adding -fsanitize=address to the binary when it's compiled and that's it :)

ASAN and gcc: How to get line numbers in the stacktrace

ASAN or Address Sanitizer is a nice project by Google that is a memory error detector for C/C++. According to their web it finds:

• Use after free (dangling pointer dereference)
• buffer overflow
• Stack buffer overflow
• Global buffer overflow
• Use after return
• Initialization order bugs

Also it's much faster than valgrind :-) Unfortunately it's not as easy to use as valgrind since it requires a rebuild of your code.

The basic instructions to use ASAN are:

Use the -fsanitize=address switch

together with the suggestion of

To get nicer stack traces in error messages add -fno-omit-frame-pointer.

As a simple example let's see what happens when we run

int main(int, char **)
{
    int a[3];
    a[3] = 4;
    return 0;
}

compiled with

g++ -fno-omit-frame-pointer -fsanitize=address main.cpp

The result:

==8403== ERROR: AddressSanitizer: stack-buffer-overflow
on address 0x7fffbe7c7d8c at pc 0x400779
bp 0x7fffbe7c7d40 sp 0x7fffbe7c7d38
WRITE of size 4 at 0x7fffbe7c7d8c thread T0
    #0 0x400778 (/home/tsdgeos_work/test/a.out+0x400778)
    #1 0x7f2f5cfa6ec4 (/lib/x86_64-linux-gnu/libc-2.19.so+0x21ec4)
    #2 0x400638 (/home/tsdgeos_work/test/a.out+0x400638)
Address 0x7fffbe7c7d8c is located at offset 44 in frame 
 of T0's stack:
  This frame has 1 object(s):
    [32, 44) 'a'

In this case it's pretty obvious what's wrong with just looking at the code and ASAN is even telling us it is a bad write just after the 'a' object, but note that we are not getting the line number of where the error happens. You'll say, that's why you didn't use the -g switch! So let's see what do we get after compiling with

g++ -g3 -fno-omit-frame-pointer -fsanitize=address main.cpp

The result:

==8467== ERROR: AddressSanitizer: stack-buffer-overflow
on address 0x7fff59ccaa2c at pc 0x400779
bp 0x7fff59cca9e0 sp 0x7fff59cca9d8
WRITE of size 4 at 0x7fff59ccaa2c thread T0
    #0 0x400778 (/home/tsdgeos_work/test/a.out+0x400778)
    #1 0x7f6f75601ec4 (/lib/x86_64-linux-gnu/libc-2.19.so+0x21ec4)
    #2 0x400638 (/home/tsdgeos_work/test/a.out+0x400638)
Address 0x7fff59ccaa2c is located at offset 44 in frame 
 of T0's stack:
  This frame has 1 object(s):
    [32, 44) 'a'

Same thing :-/

Here is where people may give up or think to switch to clang and try there, but since clang is sometimes more picky with the code (not bad per se) it may be a lot of work to get your code to compile under clang, if you keep digging you'll read some news about GCC not having a ASAN symbolizer [yet], but clang has one and you can still use it with GCC, so if you

export ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-3.4
export ASAN_OPTIONS=symbolize=1

and then run the binary again (the one we just compiled with -g3)

The result:

WRITE of size 4 at 0x7fff4f5f0ebc thread T0
    #0 0x400778 in main /home/tsdgeos_work/test/main.cpp:5
    #1 0x7f3d4dce2ec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
    #2 0x400638 in _start (/home/tsdgeos_work/test/a.out+0x400638)
Address 0x7fff4f5f0ebc is located at offset 44 in frame 
 of T0's stack:
  This frame has 1 object(s):
    [32, 44) 'a'

And now we have line numbers :-)

Akademy-es 2014 in Málaga

This year, the 9th Akademy-es will take place in Málaga from 16 to 18 May.

Málaga is the city that hosted Akademy 2005 and were a few few crazy people met and thought about doing Akademy-es 2006 next year in Barcelona, and after that, 9 years in a row. Not bad :-)

I'm definitely going and you should if you're interested in KDE too. And of course you should think about submitting a talk :-)
Finally if you have a company you may want to join and sponsor the event, have a look at the sponsor page.

Registration is still not open but will be in a few days/weeks.

Hope to see you there :-)

How to strike out text in Okular

We just had a user report a wish item in bugs.kde.org asking for Okular to come with a text strike-out annotation by default. I just closed the bug saying that he can create his own annotations by Settings -> Configure Okular -> Annotations -> Add ->
Text Markup -> Strike Out -> Set Color -> OK



Of course we could still ship it, but if you have a look at that "Add Annotations" dialogs there's lots of lots of possibilities so people should just create the ones they see the need for instead of us shipping lots that may not be that useful.

KDE Applications and Platform 4.13 Schedule

You can find the release schedule for KDE Applications and Platform 4.13 at http://techbase.kde.org/Schedules/KDE4/4.13_Release_Schedule

This schedule consolidates the changes made for 4.12 since it seems to have worked well.

Also remember that 4.13 will be applications and kdelibs only; KDE Workspace (aka Plasma) will be getting 4.11.x LTS releases until August 2015

Changes in Okular printing for 4.12

Since today, Okular master (i.e. 4.12) respects the margins specified in the printer setup dialog (which default to the hard-margins of the printer). This means that I'll be able to print in my printer without getting cropped stuff; yes, my printer has a default hard-dead margin of 1.5 cm at the bottom and usually files contain stuff in that area.

If your document does already contains the margins, you can get the old behaviour by simply setting the margins to 0. Also hopefully you don't have a printer that is as bad as mine and your default margins are just 0,0,0,0

KDEEdu sprint is over for me

I'm sitting at the Coruña airport waiting for my plane for Barcelona to leave. This means my three days at the KDEEdu Sprint 2013 are gone. It's been good to meet new people like Punit, get to know better people I had already met like Samikshan and meet old co-sprints like Sebastian and Andreas, and of course re-meeting my fellow KDE España friends Jose, Aleix and Santa. Sadly Oindrila could not make it due to visa problems :-(

In these three days we'd had time to talk about KDE Edu apps future on mobile, KF5 ports, libkdeedu splitting and lots of other stuff.

I tried to port Blinken over the BB10. Got stuck trying to compile stuff using cmake until I found KDE's own Laszlo Papp guide. Unfortunately other stuff got in the middle and I could not finish the port, but now I'm closer and if I can find a couple of free afternoons will probably have something in the BB10 store.

Unrelated to KDEEdu i finally got time to create a review request for a patch i worked a few weeks ago that will hopefully workaround one of the most hated crashes people are having in the KDE Plasma Desktop, let's see if that helps.

Finally, I'd like to thank GPUL and KDE e.V. for organizing and sponsoring the event. And specially thanks to Jose for his mad organizing skills, you're awesome :-)

KReversi master is now Qt Quick based!

Denis Kuplyakov worked on porting KReversi to QtQuick during this Google Summer of Code and his code has now been merged to master for the upcoming 4.12 release. The kdegames team has given the new code as much testing as we can, but it is a big re-work so it'd be great if you can give it a try and report any regression you may find compared to the old version.

4 weeks until KDE SC 4.12 Feature Freeze

Just a quick heads up that the KDE SC 4.12 Feature Freeze is now 4 weeks away.

Full schedule at http://techbase.kde.org/Schedules/KDE4/4.12_Release_Schedule.

Dine with the KDE e.V. board

Next weekend (September 28-29) the KDE e.V. board is going to have an in-person board meeting in Berlin.

As part of the board meeting we'll have food (geeks need to eat too) and since we like talking to other people besides ourselves we’d like to invite KDE people to come to the board dinner on Saturday at 19:00 (location still undecided).

We can talk about all things KDE, KDE e.V., Free Software and maybe even have a good time ;-). Please let me know as soon as possible if you’re coming as space is limited.

KNetwalk ported to QtQuick

Ashwin Rajeev has just commited his port of KNetwalk to use QtQuick to the master branch of the knetwalk git repository.

Ideally you should not notice any difference, but it would be awesome if you guys could give it a try and report to either Ashwin or to the kde-games-devel mailing list (if you do it here I'll try to pass the info, but I'm going to be off the web for a while so it may get lost when I come back and there's a ton of emails to read :D)

KDE SC 4.12 Release Schedule

After discussions at kde-core-devel, Akademy and release-team you can find the release schedule for KDE SC 4.12 at http://techbase.kde.org/Schedules/KDE4/4.12_Release_Schedule

The main change agreed by Release Team is that we have more simplified freezes (basically just one) and our betas/RC happen a bit more often (every week) so we have testers trying more up to date code. This also lead to a somewhat shorter cycle with a release mid December 2013.

Fixed: My Z10 automagically shutsdown at a random battery number (mine was around 33%)

Last week I hard a weird issue in which my Z10 was shutting down when the battery was around 33%, I thought the battery had gone wrong, but it seems the problem lies somewhere in the OS that gets confused, in my case i think it was because i pulled/put different batteries in a very short time span.

After some digging I found http://forums.crackberry.com/blackberry-z10-f254/blackberry-z10-shuts-down-30-battery-807279/index6.html#post8755531 that helped me make the OS "reset" according to battery handling.

Basically it boilds down to "make sure you really really run out of battery and it'll fix itself"

Adding here in case someone has the same issue.

KDE 4.11 releases are around the corner. Let's cellebrate!

At KDE España we have started the ball rolling to cellebrate the release for 4.11 by starting the organization of the Barcelona event. Right now it feels pretty lonely at http://community.kde.org/Promo/Events/Release_Parties/4.11.

If you are interested in attending the Barcelona event don't hesitate voting at the doodle to decide the day!