This is a big thank you, a thank you to all the people who made the Randa Meeting 2014 possible, the people who invested their time and their energy to go there and work on free software, and the people who made donations to support this.

Tons of things happened at Randa this year. Among other things there was lot of porting work to KDE Frameworks 5 done on kdevplatform, KMyMoney, Gwenview, KMix, Artikulate, and Kig. KDevelop got QML and Javascript support, the API docs got some love, Phonon 4.8 Beta was released, KStars tools got polishing, Kdenlive got a roadmap, and the first alpha of the Inqlude tool was released. We wrote a book, and made a movie:


It can't be overestimated what kind of magic place Mario created at Randa. It is such a focused and supportive environment, that it's hard to not be productive. It generates a sense of community which reaches way beyond the meeting itself, and fuels so much of future work. I have written about what makes this special spirit. But I suspect that the real secret is that Mario runs us on Swiss cheese and chocolate for a week.

So thanks again to the donors, to the sponsors, to the people who wrote code, or text, or took photos, or brought their kids, or organized, or simply provided happiness, or helped in any other way. It was an awesome event.

As it has taken an extra ordinary amount of time for LSB to move forward a predicament has developed for many distributions, including openSUSE. Many of the requirements for LSB 4.1 can no longer be met and thus while the lsb package still builds it is not installable, see . The technically correct solution would be to drop the lsb package from the distribution, Factory now and thus 13.2 when it is released) as we can no longer be LSB compliant. However, the negative side effect is that some applications we do not and cannot package will no longer install, probably most notably google-chrome. Thus, having no lsb package, or no package that provides “lsb”, is a problem and has negative effects on many users. Therefore, the only way forward is to have an “lsb” package which provides LSB on a best effort basis.

Since LSB 4.1 and previous releases is a monolithic requirement, i.e. if you depend on lsb you depend/get everything that is in the standard, whether you want it or not, it is very likely that many applications depend on lsb while needing only a subset of the features. Thus, while we do not know all of those applications and cannot provide a list of “this will work and that will not“, there is a good chance that many external packages depending on lsb will not only install, but the payload they deliver will work with an lsb best effort approach. For those applications that are broken there is pretty much nothing we can do, sorry.

At a meeting last week at LinuxCon NA the goal was set to have LSB 5.0 released by the end of October. LSB 5.0 is incompatible with LSB 4.1 and prior releases. Thus, even if we provide an lsb 5.0 compliant package in short order after LSB 5.0 is released we still have the same risk as we do with the best effort approach. Basically some application packages that depend on “lsb” will deliver a payload that is broken. Exactly the opposite of what the LSB is trying to achieve, but hey one cannot hang on to Qt3 forever. Therefore, our “lsb best effort” approach to cover the gap does not create any additional pain.

Moving forward the LSB working group decided that the current approach, while providing value, has significant drawbacks. Predominantly there are not enough fingers on the keyboard to continue releases of such extensive “accepted standard” documentation. This is what we presently experience with the non installable lsb package. A for the LSB is being worked out. As this next/new LSB develops we will have to see how application providers deal with this. Without a formal LSB specification in the future, this problem will recur in a few years if application packages depend on a package named “lsb” which at some point may need to seize to exist. We will see how this plays out as the world we create keeps evolving.

Когда требуется локально пересобрать пакет под одну из архитектур ARM, например для тестирования сборки, можно воспользоваться следующим медленным подходом.

osc build --clean --alternative-project openSUSE:Factory:ARM qemu armv7l name.spec

Здесь указывается, что используется альтернативный проект для сборки — openSUSE:Factory:ARM (версию подставить по желанию), используется репозиторий qemu, который есть в этом проекте. Поэтому и указывается этот альтернативный проект.

Несмотря на то, что в данном примере указана архитектура armv7l, технически, это x86_64. В среду сборки будет установлен бинарный транслятор qemu, работающий через подсистему ядра binfmt. При инициализации ядро настраивается таким образом, что при виде сигнатуры ELF для архитектуры ARM вызывает бинарик как qemu-arm /usr/bin/..., подобно тому, как при виде символов "#!" в начале исполняемого файла вызывается указанный интерпретатор. Работает поэтому достаточно медленно.

К сожалению, с пакетами kiwi такое не проходит.

#1: openSUSE Factory Rolling Release Distribution

Over the course of the last several months a lot of changes were made to the development process for openSUSE Factory. Meaning it’s no longer a highly experimental testing dump, but it’s now a viable rolling release distribution in its own right. You can read all about the details here. I installed openSUSE Factory in a virtual machine yesterday and it seems to run pretty great. Of course to really judge a rolling release distribution you need to run it for a sustained period of time.

No rolling release distribution will ever be my preferred day-to-day operating system, but nevertheless I’m pretty excited about the “new” openSUSE Factory. I think the changes will enable version whores and bleeding edge explorers to finally have a truly symbiotic relationship with the users who value productivity and predictability in their PC operating system.

#2: KDE Frameworks 5 and Plasma 5

Since I was already testing openSUSE Factory it was a great opportunity to finally get my feet wet with the new KDE Frameworks 5 and Qt5 based KDE Plasma 5 workspace, initially released about a month ago. Obviously it’s still lacking some features and polish, but it’s already usable for forgiving users who know what they’re doing and showing great promise.

#3: 4G on the Jolla

My provider enabled 4G on my subscription and offered to send me a new SIM Card gratis. So now my Jolla is sporting 4G. Unfortunately it only took about 5-10 minutes of speed testing (peaking at 12 MB/s, averaging about 10 MB/s) to use all my available bandwidth for the month, so for the rest of August I’ve been speed dropped to 64 Kbps, but hey, it’s still 4G!

#4: Richard Stallman presenting with a slideshow

Who’d have ever thought they’d see the day that Stallman would do a presentation with accompanying slides? Well it happened, and I think this great use of slides helps him communicate more effectively. Watch the video and judge for yourselves (27 MB, 13 minutes).

Motivations

What is a team blog for me? 

• It is a team effort. Each post should be led by a person, an author, but created by the team.
• It focuses on what the team/group do, not on what they will do, what they think or what they want. Why? because a team blog is way more than a promo tool, it is also a reporting one.
• It is supported by a communication expert as editor, not just to increase the quality and potential impact of every content, but to increase the team skills as writers in a practical way.
• It is management driven because it requires to embed it in the team processes and group dynamics. So it requires analysis, a clear goal, follow up and activation energy, specially during those moments in which the team workload is high, so writing is not perceived as a high priority. 
• In order to ease the identification of the team with the blog and vice-versa, the promo aspects should serve the team and not the other way around. This is a key difference between this action and other common marketing efforts done by every organization.
• Selecting the right topics to write about is not a question since, as mentioned before, the team blog is about what the team is working on. The question is about when to publish, together with the approach used to create the articles. Again, a management point of view is essential here. That view can come from different areas of the organization or within the team, but has to be there to take full advantage of the effort.
• It feeds engineering reports. It saves time on this task in the long run.
• If the goal of the action and the vision brought up by the editor are set up correctly, the team blog should also feed the technical marketing and customer engagement efforts of the organization/business unit. 
• In the mid term, the blog serves as input for evaluating the performance/accomplishments of the team as a group, when associated with the key objectives previously defined. This is true not just from a management or customers perspective. What is more important, the team blog serves as evaluation input for the team itself too. The retrospective that this action can provide is essential for the growth of any team. 

Core Dump

Because it is still reported that the ownCloud Client has an increasing memory footprint when running for long time I am trying to monitor the QObject tree of the client. Valgrind does not report any memory problems with it so my suspicion was that somewhere QObjects are created with valid parent pointers referencing a long living object. These objects might accumulate unexpectedly over time and waste memory.

So I tried to investigate the app with Qt Inspector of Robert Knight. That’s a great tool, but it does not yet completely do what I need because it only shows QWidget based objects. But Robert was kind enough to put me on the right track, thanks a lot for that!

I tried this naive approach:

In the clients main.cpp, I implemented these both callback functions:

[code language=“cpp”] QSet<QObject*> mObjects;

extern “C” Q_DECL_EXPORT void qt_addObject(QObject *obj) { mObjects.insert(obj); }

extern “C” Q_DECL_EXPORT void qt_removeObject(QObject *obj) { mObjects.remove(obj); } [/code]

Qt calls these callbacks whenever a QObject is created or deleted respectively. When the object is created I add it’s pointer to the QSet mObjects, and if it is deleted, it is removed from the QSet. My idea was that after the QApp::exec() call returns, I would have to see which QObjects are still in the mObjects QSet. After a longer run of the client, I hoped to see an artificial amount of objects being left over.

Well, what should I say… No success so far: After first tests, it seems that the amount of left-over objects is pretty constant. Also, I don’t see any objects that I would not kind of expect.

So this little experiment left more questions than answer: Is the suspicion correct that QObjects with a valid parent pointer can cause the memory growth? Is my test code as I did it so far able to detect that at all? Is it correct to do the analysis after the app.exec() call returned?

If you have any hints for me, please let me know! How would you tackle the problem?

Thanks!

This is the link to my modified main.cpp: https://github.com/owncloud/mirall/blob/qobject_monitor/src/main.cpp

When inviting to the Randa 2014 meeting, Mario had the idea to write a book about KDE Frameworks. Valorie picked up this idea and kicked off a small team to tackle the task. So in the middle of August, Valorie, Rohan, Mirko, Bruno, and me gathered in a small room under the roof of the Randa house and started to ponder how to accomplish writing a book in the week of the meeting. Three days later and with the help of many others, Valorie showed around the first version of the book on her Kindle at breakfast. Mission accomplished.


Mission accomplished is a bit of an exaggeration, as you might have suspected. While we had a first version of the book, of course there still is a lot to be added, more content, more structure, more beautiful appearance. But we had quickly settled on the idea that the book shouldn't be a one-time effort, but an on-going project, which grows over time, and is continuously updated as the Frameworks develop, and people find the time and energy to contribute content.

So in addition to writing initial content we spend our thoughts and work on setting up an infrastructure, which will support a sustained effort to develop and maintain the book. While there will come more, having the book on the Kindle to show it around indeed was the first part of our mission accomplished.

Content-wise we decided to target beginning and mildly experienced Qt developers, and present the book in some form of cook book, with sections about how to solve specific problems, for example writing file archives, storing configuration, spell-checking, concurrent execution of tasks, or starting to write a new application.



There already is a lot of good content in our API documentation and on techbase.kde.org, so the book is more a remix of existing documentation spiced with a bit of new content to keep the pieces together or to adapt it to the changes between kdelibs 4 and Frameworks 5.

The book lives in a git repository. We will move it to a more official location a bit later. It's a combination of articles written in markdown and compiling code, from which snippets are dragged into the text as examples. A little bit of tooling around pandoc gives us the toolchain and infrastructure to generate the book without much effort. We actually intend to automatically generate current versions with our continuous integration system, whenever something changes.

While some content now is in the book git repository, we intend to maintain the examples and their documentation as close to the Frameworks they describe. So most of the text and code is supposed to live in the same repositories where the code is maintained as well. They are aggregated in the book repository via git submodules.

Comments and contributions are very welcome. If you are maintaining one of the Frameworks or you are otherwise familiar with them, please don't hesitate to let us know, send us patches, or just commit to the git repository.



I had fun writing some example code and tutorials for creating new applications and how to use KPlotting and KConfig. The group was amazing, and after some struggling with tools, network, and settling on what path to take, there was a tremendous amount of energy, which carried us through days and nights of writing and hacking. This is the magic of KDE sprints. There are few places where you can experience this better than in Randa.

Update: Many people are involved with creating the book, and I'm grateful to everybody who is contributing, even if I haven't mentioned you personally. There is one guy I should have mentioned, though, and that is Bruno Friedmann who made the wonderful cover and always is a source of energy and inspiration.

Three years ago, at Randa 2011, the idea and first implementation of Inqlude, the Qt library archive, was born. So I'm particularly happy today to announce the first alpha release of the Inqlude tool, live from Randa 2014.

Picture by Bruno Friedmann

I use the tool for creating the web site since quite a while and it works nicely for that. It also can create and check manifest files, which is handy when you are creating or updating these for publication on the web site.

The handling of download and installation of packages of libraries listed on Inqlude is not ready yet. There is some basic implementation, but the meta data needed for it, is not there yet. This is something for a future release.

I put down the plan for the future into a roadmap. This release 0.7 is the first alpha. The second alpha 0.8 will mostly come with some more documentation about how to contribute. Then there will be a beta 0.9, which marks the point where we will keep the schema for the manifest stable. Release 1.0 will then be the point where the Inqlude tool will come with support for managing local packages, so that it's useful for developers writing Qt applications as end users. This plan is not set in stone, but it should provide a good starting point. Longer term I intend to have frequent releases to address the needs reported by users.

You will here more in my lightning talk Everything Qt at Akademy.

Inqlude is one part of the story to make the libraries created by the KDE community more accessible to Qt developers. With the recent first stable release of Frameworks 5, we have made a huge step towards that goal, and we just released the first update. A lot of porting of applications is going on here at the meeting, and we are having discussion about various other aspects how to get there, such as a KDE SDK, how to address 3rd party developers, documentation of frameworks, and more. This will continue to be an interesting ride.

Core Development Group

• Kernel
• Power Management
• Security
• Virtualization

Linaro Connect

Factory as a rolling release: openSUSE development version

Personal challenges

LinuxCon Europe

Akademy 2014

TEDxLaLaguna