Language Selection

English French German Italian Portuguese Spanish

Kde Planet

Syndicate content
Planet KDE -
Updated: 3 hours 6 min ago

Usability & Productivity Sprint 2019

Tuesday 9th of July 2019 01:09:30 PM

In June 2019 I went to Usability & Productivity Goal Sprint in the beautiful city of Valencia! As I’m a relatively new KDE contributor this was my very first sprint experience and it was awesome. At the same time the Plasma Sprint took place and it felt more like one big sprint than two separate events. We were kindly hosted by Slimbook which also organized a bus that took us to their office in the morning and back to the hotel in the evening. A big thank you to them!

In the first part of the sprint I mainly worked on continuing to improve Spectacle. You don’t know Spectacle? It is our screenshotting application with many settings: for example to control what should be captured, if you want to include your mouse cursor or to simply set a delay from when you press the button until the actual screenshot is taken.

> Showing the remaining time in the taskmanager

The first feature I worked on is based on a cool idea by Felix Ernst. Spectacle now shows the time remaining until a screenshot is taken in the taskmanager like when you copy a file in Dolphin or download a file. Now you don’t have to wonder anymore how much time you have left to arrange everything for your screenshot or if Spectacle is still running or crashed somewhere in the background (even if that does not happen very often).

Configuring shortcuts inside Spectacle

Together David Edmundson and I finished porting the Shortcuts configuration of Spectacle from KHotkeys infrastructure to KGlobalAccel. This means, the shortcuts aren’t located in the Custom Shortcuts part of the system settings and duplicated under KDE Daemon in Global Shortcuts but reside in their own Spectacle category in the global shortcut settings. Even more important, we can now show a configuration dialog for the shortcuts inside Spectacle! You don’t have to fear that your carefully assigned hotkeys are reverted to default ones during this transition - they are carefully migrated to the new system. The migration program is longer than the actual required code changes and is run automatically when you receive the update thanks to kconf_update.

Continuing to work with David we investigated why persistent copy to clipboard of screenshots didn’t work - it was supposed to work after recent changes in Spectacle and Klipper after all. It turned out that there was a bug in Klipper but you can now paste screenshots into your favorite image editor or chat prorgam after closing Spectacle. Even if your clipboard history is set to ignore images (of course they will not appear in the history in this case) !

The last days of the sprint I spent on adding the possibility to have your wallpaper slideshow in a particular order in addition to the current random sequence. For now, I implemented sorting in alphabetical order and based on the time the pictures were modified but extending it with others is straightforward. In doing so I simplified the code a bit (it wasn’t touched in a long time) and reduced some duplication by using the same model to show the images in the configuration dialog and in the actual slideshow (before this was done in two different code paths). I didn’t quite finish it up during the sprint but you can have a sneak peek at it over at Phabricator.

Another bigger change I started is porting Spectacle from it’s hand-rolled configuration-managing class to a KConfig XT based approach. You write a XML file and it generates the code for you that manages the settings and their defaults (notice that currently Spectacle has only an OK and Cancel button but no Defaults or Apply button). The main settings already work but I still need to wire some things up like the new shortcuts settings for example.

Aside from that I also worked on investigating and fixing some bugs as always. For example the action buttons now fit into their respective list elements inside the virtual desktop settings, and you can’t get trapped inside Spectacle’s Region Selection anymore.

However the great thing about a sprint is that is not all hacking but you can discuss bigger changes and directions for the future, share ideas and brainstorm together in person. We had a big discussion about discoverability of widget settings and agreed on having a global edit mode where everything on your desktop will be configurable. Other points of discussions were the right click menu of the plasmoids in your panel that can be confusing when they include multiple very similar entries, the behavior of the taskmanager or the multi-screen configuration. One last thing we talked about is the future of the usability goal. We have awesome news to share so stay tuned and have an eye on Nate Graham’s blog as always.

But a Sprint is not only working with others but also meeting the people whose names you know and maybe interacted with textually, talking to them and getting to know each other. And I had a great time, starting from the first day hacking together in a single hotel room with slow wifi, to the last one when we four with the latest flights walked to the beach. So thank you to KDE e.V. that made this possible for me, Slimbook again, Aleix Pol who organized it and lastly to all the nice people who attended and made this a great experience. See you soon.

Plasma Sprint 2019 in Valencia

Tuesday 9th of July 2019 12:00:30 PM

Last month the Plasma team met in Spain for their annual developer sprint. It was kindly hosted by Slimbook in their offices on the outskirts of Valencia. This time it was co-located with the Usability sprint and it was great to meet so many new faces there.

View from the rooftop bar at the hotel Continued improvements in notifications

On 11 June we released Plasma 5.16 with a completely redesigned notification center. In the weeks since I received numerous suggestions on how to improve the system even further and I started working on them. Since this technology is relatively new there’s also a lot of activity and changes being made to the “stable” branch of notification code, i.e. the one feeding subsequent 5.16 bugfix releases. Let’s talk about some of those changes:

  • Fixed job progress reporting when using Latte Dock: in the old system, there was a dedicated process kuiserver managing job tracking (the info popup when you copy a file) forwarding the information to every interested party. However, apart from plasmashell there was nobody else making use of it and it seemed like a huge waste to duplicate the DBus traffic happening while copying a file. Or so I thought :) I killed kuiserver and moved its logic into plasmashell. However, since Latte Dock also uses Task Manager progress reporting, it became random who claimed the service on login. This is resolved now using some clever DBus magic. If you still have issues with progress reporting in conjunction with Latte Dock with latest updates installed, please let me know!
  • More reliable popup placement: the popup should no longer fly all over the place on Wayland.
  • Ignore duplicates: When an application sends the same notification multiple times in quick succession, the additional requests are ignored.
  • Improved notifications for app bundles: notification center identifies applications based on the desktop-entry hint they send. However, in case of bundled apps, such as Flatpak and Snap, the desktop file in the bundle might be different from the one it originally got built with. To address this, I now also take into account the X-Flatpak-RenamedFrom key and BAMF_DESKTOP_FILE_HINT environment variable when trying to identify an application.
  • No unidentified apps in history: another side-effect of a failure to identify an application is that we cannot relate any user preferences to it. This means that you cannot prevent an application from flooding your history. Since 5.16.2 unidentified applications no longer show up in history. This is admittedly a stark behavior change for a stable release and I do apologize for breaking someone’s workflow. However, I needed a quick mitigation for the spam problem and will consider making it an option in Plasma 5.17.

Do not disturb while screens are mirrored

Speaking of Plasma 5.17, I worked on additional notification features for the October Plasma feature release: since we had a projector in the meeting room and I got tasked to run through the agenda in the mornings, I realized that having a way to automatically enter do not disturb mode when mirroring screens could be useful. Since I already used our KScreen library before in PowerDevil (which by default will not suspend your laptop when you close the lid with an external monitor connected), a patchset was quickly created.

Quick reply. Application gets to choose placeholder text and submit button appearance

For a long time I’ve been craving for a quick reply feature where you get a text field inside the notification. In fact, this has been on the notification master plan since 2016. While implementing the feature itself was relatively straight-forward, keyboard focus is an issue still to be resolved, especially on Wayland: notification windows never get focus so they can’t steal it away from other applications. However, conditionally granting focus in this particular case is a lot harder than it sounds.

Shaping up the next Plasma Browser Integration release

Plasma Browser Integration is one of the projects I’m most proud of. In case you didn’t know, there’s a browser extension for Firefox and Chromium-based browsers that bridges the gap between browser and desktop. It lets you share links, find browser tabs in KRunner, and control music and video playback anytime from Plasma, or even your phone using KDE Connect!

A crossed icon indicates it’s not running and the popup gives some advice about it

For the next feature release I first of all worked on better error handling. Right now, when the bridge application acts up or isn’t installed, a popup is shown. This is especially annoying when you have the extension synced across devices to computers that may not be able to run it. I now make use of a so-called browser action to place an icon in the toolbar that indicates status.

WebShare API in action

Furthermore, I added support for the Web Share API so websites can trigger a share dialog from Purpose, our content sharing framework used throughout our applications. This feature also got added to the context menu, so you can not only send links to your phone via KDE Connect but to any registered application. What I’d love to see is a Purpose plug-in for KDE Itinerary so I could store boarding passes directly from the airline booking pages. :)

Automatic dark mode, maybe?

I also toyed around with Media Queries Level 5 to support “dark mode” CSS media queries. While I managed to have it query the current system color scheme to determine dark or light mode, the media queries are currently applied by tampering with the website CSS and installing new rules with the media query unset. This seems to work well but is not something I feel very confident in shipping. Let’s hope this feature request for letting extensions enforce a color scheme goes anywhere or maybe they could just start reading the gtk-application-prefer-dark-theme setting in the future.

Finally, the plan is to enable enhanced media controls by default now that I made it less invasive and more resilient. With this you’ll get more detailed track information, album covers, and more playback controls for websites using the Media Session API. Luckily, more and more websites are starting to make use of that API.

Please do me a favor and enable “Enhanced Media Controls” in the extension settings right now and report any websites that might misbehave, so we can fix that!

GammaRay 2.11.0 Release

Tuesday 9th of July 2019 08:40:32 AM

We have released version 2.11.0 of our Qt application monitoring tool GammaRay. GammaRay allows you to observe behavior and data structures of Qt code inside your program live at runtime.

GammaRay 2.11 comes with a new inspection tool for Qt’s event handling, providing even more insights into the inner working of your application. Besides looking at the events and their properties as they occur the event monitor visualizes event propagation as it happens for Qt Quick or Qt Widgets input handling.

GammaRay event monitor log view

Additionally the event monitor provides statistics on how often which type of event occurred, as well as fine-grained filtering options to find the events interesting for you even in a huge dataset.

GammaRay event type view

Another major new feature is the network operation inspector. This allows you to observe the HTTP operations triggered via QNetworkAccessManager and helps to optimize network interactions, identify leaked QNetworkReply objects and ensure that all operations are encrypted.

GammaRay network operation inspector

Next to this, GammaRay 2.11 got support for more data types (such as the QJson* classes), a new thread affinity checker for the problem reporter, and of course compatibility with the just released Qt 5.13. Behind the scenes we also did some work on performance, improving the responsiveness on large and/or busy inspected applications.

GammaRay 2.11 is available as part of the just released Qt Automotive Suite 5.13 including QtCreator integration and professional support, or GPL-licensed on Github.

About KDAB

KDAB is a consulting company offering a wide variety of expert services in Qt, C++ and 3D/OpenGL and providing training courses in:

KDAB believes that it is critical for our business to contribute to the Qt framework and C++ thinking, to keep pushing these technologies forward to ensure they remain competitive.

The post GammaRay 2.11.0 Release appeared first on KDAB.

OpenExpo 2019 After Dark

Monday 8th of July 2019 07:22:26 PM

OpenExpo is an event aimed at businesses and the public sector. Top topics usually revolve around cloud computing, big and open data, IoT, and as of late, blockchain technologies. 2019 was its sixth edition, held on the 20th of June in “La Nave” on the outskirts of Madrid.

Organisers tell us that 2800 visitors attended this year’s event. There were about 120 speakers and 70 exhibitors with booths. From what we could garner, most visitors were representatives of public institutions, consulting companies, and software development companies, especially from the field of cloud computing.

The Booth

KDE’s booth was right next to the entrance; on the right as you went in, in an area called the “Innovation & Community Village”. We were one of five exhibitors in the area. On our right was the FSFE. I happened to know one of the people staffing, which was nice.

KDE’s booth at OpenExpo 2019.

Behind us was a father-and-son outfit showing 3D printers. Apart from owning a shop, they apparently run courses in their neighbourhood, and that is what earned them a spot in the “Community Village”.

Then there were some people with a DIY go-kart/scooter/tricycle thingy (?). They opened a big, colourful box full of interesting-looking pieces, didn’t do anything with them, and then left.

Finally, on the other side of our table was a company/community that virtualised desktops in the browser. Interesting stuff.

There were six tables and it was first come, first served. I was first, so I picked a front-facing table. Each table was 180 by 80 cm, which is big compared to what we often get in other events, and gave us plenty of space to set up our things. There was a space for our banner in a corner, as you can see in the photograph. We added a screen on a stand behind us that ran videos showcasing Plasma, Plasma Mobile (PlaMo), Kirigami and Applications on a loop. You can see the screen in the background of the photo.

On the table, we laid out the following items:

From left to right, a Nexus5X phone running Plasma Mobile, a Raspberry Pi with a touch screen also running Plasma Mobile, the Pinebook 14” $99 netbook, and a KDE Slimbook II.

We also had 100 stickers: 50 stickers of Katie using a phone and with the Plasma Mobile URL, and 50 Konqi stickers with URL. The Konqi ones ran out first.

Katie and Konqi stickers.

The aim of our table spread was three-fold. First, we wanted to show people “shopping” for software that Plasma and other KDE applications are “end-user ready”. Secondly, we intended to show how Plasma is light and can work on a wide variety of devices, including devices usually used in setups where embedded electronics are required (the Raspberry PI); low-powered, ARM-based netbooks (the Pinebook); and as a potential mobile environment (the Nexus 5X). Finally, we wanted to demonstrate how applications, thanks to Kirigami, can adapt to different hardware and screen configurations.

The overarching aim was to see if we could convince administrators of large deployments (for example, schools) that Plasma and KDE Applications would be a good choice for their users. We were also seeking contributors and sponsors for KDE, and looking to convince companies that KDE has good solutions for developing graphical applications.

What I did

To attract and engage visitors, I used several tactics I had used in the past, and that seem to work well. I stood outside the booth and approached visitors that showed interest in our spread.

I found out where the visitors were coming from and adapted my spiel to that. I demoed Plasma on laptops for administrators of large deployments, showing off features and pointing out how it was fast and snappy even on low-spec hardware.

I showed the proof-of-concepts of Plasma Mobile on Yocto (Raspberry Pi) and on postmarketOS (Nexus 5) to managers of companies that developed for several platforms. They could check for themselves how Kirigami could let them create cross-platform applications, including for Android (I had my own phone on hand for this), and how it would allow them to create applications that would adapt to different sizes of screens.

At the end of each demonstration, I encouraged visitors to scan the QRs so they could leave with more information they could research for themselves.

The thing that most attracted the visitors’ attention was the Pinebook – when they read it cost 99 USD. That sparked interest in the underlying hardware, and in what software would run on an underpowered device. A lot of people also picked up the SBC for some reason. The Pine64 I had brought along was only there to show what kind of hardware was in the Pinebook, but it seems that… er… naked electronics are inherently fascinating to visitors at these kinds of events.

After the Pinebook, the most popular devices where the phone and the Raspberry Pi with its touchscreen. A lot of visitors asked if the phone was already for sale, thinking that a pure GNU + Linux phone was already a thing and they had somehow missed it. Even though I had to burst their bubble, they were satisfied that at least some progress was going on, both in the realms of mobile phones and vehicle infotainment systems.


The scanning application provided by the organisers of the event was very useful, and I scanned 54 people in total, but, of course, I talked to more than that. By my calculations, about 50% more one-to-one, which puts the number of people I interacted one-on-one with between 75 and 80. Four or five times while I was delivering my spiel, a small crowd of 5 to 10 people congregated around me, so a conservative total number of people I talked to would be around 100.

Many of them were system administrators specialised in cloud computing, one of the main topics of the event. Others managed large networks of end-user machines for schools, libraries and other public institutions. There were also plenty of CEOs, CTOs and other C*Os, both attending for the talks and “shopping” for new open source development software. They are the people who found things like Kirigami interesting.

There were Linux desktop end-users in the mix, too. Many of them did not use Plasma (a few did), and they were under the impression that Plasma was heavy. The Pinebook disproved that, but this (that KDE software is bloated) is something we have seen before, and we clearly must continue to work towards dispelling this notion.

I tried to make sure that visitors to the booth walked away with something to remember us by. Stickers with URLs on them until they run out; my card, in case they needed more information; or at the very least, the links to more information in the browsers on their phones, as I encouraged people to scan the QRs associated with each item on the table.

Mission(s) Accomplished?

One of the things I set out to do was to generate some publicity for KDE in the mainstream media, since it was announced that journalists from some big Spanish newspapers, radios and TVs would be there. Unfortunately, I did not see them.

However, I was not disappointed with the day, since we achieved other things on the list. We made contacts within several Madrilian institutions, like the leaders of the MAX Linux distribution, deployed in many Madrilian schools. They are currently using MATE for their desktop, but after reviewing our spread, the said they would give Plasma a try. I will be following up with them.

Continuing with public institutions, we also talked to the people who manage the libraries in Alcorcón, sysadmins from the Congreso de los Diputados and the Ministerio de Economía and Hacienda, and developers from Correos, the Spanish post office. There were representatives from several universities, both students and professors. All visitors were impressed by Plasma’s feature set, performance and flexibility, and were excited about trying it out at work and at home.

The students from the LibreLabUCM of the Universidad Complutense de Madrid later wrote to me and asked how they could contribute. They were especially interested in contributing to Plasma Mobile.

We had a mixed bag when it came to visitors from private enterprises. There were both coders and managers among the people who came to the booth, as well as freelancing consultants. Many of the managers, including CEOs, CTOs and product managers, and all the consultants seemed to be “shopping” for FLOSS to boost productivity (the former) or to add to their portfolio (the latter). Although they were mainly after infrastructure-like software, like cloud management systems, they would often become interested when I demoed Kirigami-based software and showed them it was possible to create good-looking, graphical applications for most platforms that would adapt to different screen sizes and shapes.

From the bigger, more recognisable companies, we had visitors from IBM, Oracle, BT, Atos, Allfunds Bank and Wacom. From smaller, Spanish joints we met people from VASS, Zylk, Zendata and Certelia.

Lessons Learnt

The first lesson I learnt was not to try and do this alone again. Over twelve hours of standing and greeting visitors is not good for an unfit, overweight 53-year-old. Being alone also meant I had to rely on the kindness of the people in the FSFE booth when I had to go foraging for water and food, or for when I needed a bathroom break — thanks Pablo and Erik!

But, seriously, next time we should show off some “naked” electronics. This fascinates attendees for some reason. We should maybe acquire the RISC-V board we showed in FOSDEM. These kinds of things attract visitors like a magnet.

I noticed many visitors looking over the booth from afar, trying to figure out who we were before approaching. As the roll-up banner was to one side, it was not always obvious that it was associated with us. A solution would be to always make sure we have a tablecloth or a prominent flag with our logo, name, and URL handy. We had both at the booth at FOSDEM, and I’m pretty sure that helped.

The stickers ran out rather quickly. By two o’clock there were none left. It wasn’t a big issue, because the event wasn’t the type that attracted merch scavengers, and most people were more interested in what we had on display than in stockpiling goodies. But it would still have been nice to have had more. Also, vinyl die-cut stickers are expensive: 60 euros for 100 stickers.

Speaking of printed merch, maybe we should make attractive flyers with coloured pictures, snappy explanatory bites, shortened URLs and no marketing speak, relevant to what is on show at the booth. Not everybody has QR scanning software on their phones, and a printed guide explaining what we were showing at the booth would’ve helped and served as a reminder if attendees could’ve taken it with them.

Was it worth it?

Yes. We made a lot of contacts with companies and institutions that would have been difficult to get in touch with any other way. We also heard about problems they have, and we can use that to see what solutions we can offer. Both things will ultimately help grow the number of companies that use KDE technologies (like Kirigami) in their products, as well as help us convince institutions to deploy our software (like Plasma and Applications) for their users.

Updates on Krita on android

Monday 8th of July 2019 07:11:43 PM


It has been a long time since I posted a blog (1 month+). In fact it might even seem the Krita ran on Android and now GSoC is done. Well, not quite. There’s still a lot to be done.

Let’s see what we worked on :)


First and foremost was managing the build. If you have a look at, you will see that’s a bunch of environment variables and few steps. If you look at underlying code, it was even uglier with lots of boiler plate. So, we had to refactor it and we did and made the build system a bit pleasant. (4467ad274)

OpenGL Canvas

Next, was a bug in the OpenGL canvas, when we enabled hardware acceleration, the canvas would turn black. QPainter being painfully slow, so it certainly isn’t the option, so we really rely on OpenGL ES.
So we had to fix this, it took me quite some time to fix and the solution was simple in the end.
Results? We can draw on OpenGL canvas now!


If you have played any heavy game on Android, then there is one thing which you might know. If you leave the app and come back after a few minutes all the progress is lost or the connection to the server is terminated (it happens less often with new devices having a lot of memory).
This could happens with Krita as well, so now as soon as we get Activity#onPause(), we call the JNI wrapper Java_org_krita_android_JNIWrappers_saveState to save the state synchronously.
I did try to save it asynchronously (which uses slots and signal), but I found out, as soon as the main Qt thread was paused, the entire queued connection mechanism was brought to halt.

Touch events

For past week, I have been working on adding touch support to the canvas. What I mean by touch support is, to handle “finger paint” events and we’ve been successful in doing so. We can now draw on canvas now, using our fingers, not just a pen!

To do this we simply consider the touch events with one touch point as mouse click/update/release events (the same way we do this for tablet events).

But… there is a difference!

Krita did support touch drawing on touch screen windows/linux laptops. So, why didn’t it work for android devices? In windows, if QTouchEvent wasn’t handled, Qt would automatically generate QMouseEvent for it. But the same wasn’t true for android.
There is a way, however, to simply ignore touch events and use mouse events, even for android (by manipulating Qt::WA_AcceptTouchEvents flag). This wouldn’t work for Krita because we still use touch events to rotate/zoom/move canvas. So, we now explicitly handle touch events.


We can now rotate the canvas using gestures! A small clip: rotation-canvas

It was pretty simple as well. First the way KisTouchShortcut::match worked, wouldn’t allow both zooming and rotation to co-exist, because it distinguishes the different KisTouchShortcuts based on number of minimum and maximum touch points. For both zooming and rotating, it was two.

So, for them to work in harmony, I created another class, KisZoomAndRotateAction, which delegates the call to KisZoomAction and KisRotateAction.

Secondly, in KisRotateAction, we just find out the angle between the lines. Line being, “the line” passing through the two touchpoints on the canvas.
So, the two lines are:

  1. Initial position of fingers
  2. Final position of fingers

(this is a bit hard to explain, please look at code).

Anything else?
Yes, this.

That's all! Thank you for reading, I’ll try to be more regular with my blog now :)

Kaidan 0.4.0 released!

Monday 8th of July 2019 01:00:00 PM

It’s finally here!

After more than one and a half years there finally is a new release. Kaidan 0.4.0 is the biggest update until now and apart from some bug-fixes and many minor and major features increasing the usability, Kaidan now has multiplatform-support for all common operating systems like Linux, Windows, Android and macOS.

But have a look at the changelog yourself:


Build system:

  • Support for Android (ilyabizyaev)
  • Support for Ubuntu Touch (jbb)
  • Support for macOS (ilyabizyaev)
  • Support for Windows (ilyabizyaev)
  • Support for iOS (ilyabizyaev)
  • Add KDE Flatpak (jbb)
  • Switch Android builds to CMake with ECM (ilyabizyaev)
  • Improve Linux AppImage build script (ilyabizyaev)
  • Add additional image formats in AppImage (jbb)

New features:

  • Show proper notifications using KNotifications (lnj)
  • Add settings page for changing passwords (jbb, lnj)
  • Add XEP-0352: Client State Indication (gloox/QXmpp) (lnj)
  • Add media/file (including GIFs) sharing (lnj, jbb)
  • Full back-end rewrite to QXmpp (lnj)
  • Implement XEP-0363: HTTP File Upload and UploadManager for QXmpp (lnj)
  • Use XEP-0280: Message Carbons from QXmpp (lnj)
  • Use XEP-0352: Client State Indication from QXmpp (lnj)
  • Check incoming messages for media links (lnj)
  • Implement XEP-0308: Last Message Correction (lnj, jbb)
  • Make attachments downloadable (lnj)
  • Implement XEP-0382: Spoiler messages (xavi)
  • Kaidan is now offline usable (lnj)
  • Kaidan is able to open xmpp: URIs (lnj)
  • New logo (ilyabizyaev)
  • Show presence information of contacts (lnj, melvo)
  • Add EmojiPicker from Spectral with search and favorites functionality (jbb, fazevedo)
  • Highlight links in chat and make links clickable (lnj)
  • New about dialog instead of the about page (ilyabizyaev)
  • Add image preview in chat and before sending (lnj)
  • Send messages on Enter, new line on Ctrl-Enter (ilyabizyaev)
  • ‘Add contact’ is now the main action on the contacts page (lnj)
  • Elide contact names and messages in roster (lnj)
  • Chat page redesign (ilyabizyaev)
  • Display passive notifications when trying to use online actions while offline (lnj)
  • Automatically reconnect on connection loss (lnj)
  • Contacts page: Display whether online in title (lnj)
  • Add different connection error messages (jbb)
  • Use QApplication when building with QWidgets (notmart)
  • Ask user to approve subscription requests (lnj)
  • Remove contact action: Make JIDs bold (lnj)
  • Add contact sheet: Ask for optional message to contact (lnj)
  • Add empty chat page with help notice to be displayed on start up (jbb)
  • Redesign log in page (sohnybohny)
  • Add Copy Invitaion URL action (jbb)
  • Add ‘press and hold’ functionality for messages context menu (jbb)
  • Add copy to clipboard function for messages (jbb)
  • Add mobile file chooser (jbb)
  • Highlight the currently opened chat on contacts page (lnj)
  • Remove predefined window sizes (lnj)
  • Use new Kirigami application header (nicofee)
  • Make images open externally when clicked (jbb)
  • Use QtQuickCompiler (jbb)
  • Display upload progress bar (lnj)
  • Add text+color avatars as fallback (lnj, jbb)
  • Remove diaspora log in option (lnj)


  • Forget passwords on log out (lnj)
  • Append four random chars to resource (lnj)
  • Save passwords in base64 instead of clear text (lnj)
  • Generate the LICENSE file automatically with all git authors (lnj)
  • Store ubuntu touch builds as job artifacts (lnj)
  • Add GitLab CI integration (jbb)


  • Fix blocking of GUI thread while database interaction (lnj)
  • Fix TLS connection bug (lnj)
  • Don’t send notifications when receiving own messages via. carbons (lnj)
  • Fix timezone bug of message timestamps (lnj)
  • Fix several message editing bugs (lnj)
  • Fix black icons (jbb)
  • Fix rich text labels in Plasma Mobile (lnj)
  • Small Plasma Mobile fixes (jbb)

Bug reports go to our issue tracker as always and translations are managed on Weblate.


PS: We’re searching for someone with an iPhone who can build & test Kaidan for iOS: contact us!

Interview with Enrique Gan

Monday 8th of July 2019 09:46:11 AM
Could you tell us something about yourself?

My name is Enrique Gan. I live in California and I’m currently a computer science student.

Do you paint professionally, as a hobby artist, or both?

I’m definitely just a hobbyist artist but I’d like to start making money eventually. But, it’s been a while since I studied art for an extended period of time but I’d like to get back into it.

What genre(s) do you work in?

I like concept art and anime a lot, but I like to try out different genres and see what I can learn from each one.

Whose work inspires you most — who are your role models as an artist?

When I first committed a lot of my time to art, it was in 2014 and it was coincidentally also the time when I found a youtube channel of an artist named Sinix. I always thought art was for geniuses only, but after learning about Sinix and his art, I was convinced that anyone can be an artist. His work didn’t conform completely to mainstream appeal but I was profoundly captivated by how he draws. Other artists I like included Sachin Teng, Andrew Hem, Kim Jung Gi, Shirow Miwa, Richard Schmidt, and countless others.

How and when did you get to try digital painting for the first time?

I tried digital painting later in 2014 when I heard that GIMP was a free program and that some artists like CT Chrysler used it. So I tried it out with a mouse but I couldn’t do much with it because I was still pretty new to digital painting.

What makes you choose digital over traditional painting?

It lets me store a lot of paintings and export with ease. Also, it’s a lot cheaper since I already have a computer and an entry level graphics tablet isn’t too expensive compared to buying a lot of paint.

How did you find out about Krita?

Sycra Yasin posted a video showcasing Krita back in 2013 and I ended up trying it out some time in the summer of 2015. I think I got my first and current drawing tablet a month after and started churning out digital art with Krita since.

What was your first impression?

It was a lot more art orientated than GIMP was and it looked very professional like Photoshop.

What do you love about Krita?

I really like the brush engine and I’m really impressed that software of this quality is completely free and open source. I’ve always had a soft spot for open source.

What do you think needs improvement in Krita? Is there anything that really annoys you?

I think there are some UI things that confuse just me because I never really read the manual aside from the brush making portion. I don’t think I do anything wild either so I haven’t had the opportunity to find many bugs.

What sets Krita apart from the other tools that you use?

It’s free and is catering towards artists. Other free art programs are very simple or restrained but Krita is the whole package.

If you had to pick one favourite of all your work done in Krita so far, what would it be, and why?

I’ve really liked some of my more recent work like the red girl portrait I did.

What techniques and brushes did you use in it?

I use the most basic brushes imaginable. This includes a horizontal flat brush that doesn’t rotate, and another one that rotates. Sometimes I paint with a circle brush that has opacity on pressure. Recently I started using a simple color blending brush called the palette knife. It comes with Krita by default..

Where can people see more of your work?

I have an instagram, twitter, and artstation all under the name pitganart, as well as a website called I also have a twitch account where I stream often called PitEG.

Anything else you’d like to share?

I’m really happy to have been interviewed

Kate LSP Client Restart

Sunday 7th of July 2019 01:10:00 PM

Since my last post about the LSP client progress in May I didn’t work on that project at all I think.

But the good news is, somebody else did scratch that itch on his own ;=)

We have now a prototype plugin in kate.git master, see lspclient in the addons directory.

It is not compiled per default, you can turn it on via:

cmake -DCMAKE_INSTALL_PREFIX=“your prefix” -DENABLE_LSPCLIENT=ON “kate src dir”

It shares no code with my initial prototype. The author started this without knowing of my work. This might actually be not that bad, as this plugin is composed of a much smaller code base. This allows to get familiar with the code easier as with the code I copied over from Qt Creator for my initial try.

But, even nicer, it does actually work a lot better than my variant, already now!

What does work (tested with clangd and kate.git/work projects) at the moment:

  • Auto completion: you get the proper LSP server provided completion items

  • Outline view: Get an extra tool view with the symbols of your current view

  • Document highlight: highlight all occurrences of a variable/… inside the current view

  • Code navigation: jump to the definition/declaration

There is still a lot of stuff missing and this is all prototype quality. For example the document highlight implementation I added has no way to clear the highlighting at the moment beside document reload.

But given I just needed one hour to add the document highlight support, I would say the code base is easy to adjust.

=> If you have time and want a good LSP client, now you can join the fun and have direct results.

As the author was kind enough to move his work on the plugin to the KDE infrastructure, feel welcome to show up on and help out! All development discussions regarding this plugin happen there. We are happy to accept patches, too, if you are a new contributor!

KDE Usability & Productivity: Week 78

Sunday 7th of July 2019 04:01:57 AM

It’s time for week 78 in KDE’s Usability & Productivity initiative! This week I think people have been taking a breather following a super intense sprint, and some are even on vacation–myself included. So this week’s report is going to ba a bit light, but it’s still got a few cool goodies!

New Features Bugfixes & Performance Improvements User Interface Improvements

Next week, your name could be in this list! Not sure how? Just ask! I’ve helped mentor a number of new contributors recently and I’d love to help you, too! You can also check out, and find out how you can help be a part of something that really matters. You don’t have to already be a programmer. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!

If you find KDE software useful, consider making a tax-deductible donation to the KDE e.V. foundation.

I am going to Akademy 2019!

Sunday 7th of July 2019 02:48:18 AM

This year I will be going to my second Akademy to meet my KDE friends again, discuss about future plans for the community during BoF sessions, participate in workshops, code and learn more about free software, KDE projects and Qt! One more interesting thing is that this time I am going to present a talk … Continue reading I am going to Akademy 2019!

A week in Valencia

Friday 5th of July 2019 09:52:15 AM

From 19th to 25th of June, all the Plasma team gathered in Valencia, graciously hosted by the Slimbook people in their office. This was a special sprint, as it was co-located with the Usability sprint together with some VDG members. While some of the time each team was occupied in their own discussions, there were a big margin of overlap, allowing us to have a lot of discussions about the design and usability of our beloved Plasma desktop shell.

We now have plans in the coming months for several improvements across the board, including further improvements on the new shiny notification framework by Kai Uwe.

Also, we talked (and worked on) plans for further improving our Wayland support, including middle mouse button clipboard, and screen rotation for phone, tablets and 2 in 1 laptops).

On my end, a big part of this sprint was dedicated to an encompassing plan to refactor and redesign how desktop plasmoids work and are managed. I had there both UI discussions with the VDG and loong coding sessions on it.

The Desktop/FolderView containments use a big infrastructure written in Javascript which has some problems and isn’t touched much since a lot of time.

Some time ago I set myself the task of making the management of desktop plasmoids more touchscreen-friendly, so i started modifying that code, until.. I started to design a complete reimplementation written in C++

This new implementation is much more robust, is faster and a bit leaner on the memory. Most important, is now a separate QML plugin, so is not anymore an implementation internal in the standard desktop, but if somebody wants to write his/her own containment for personalized plasma shells (for instance for a particular embedded device which is not a traditional desktop/laptop: we want plasma more and more usable as a set of construction blocks for the main UI of any kind of device).

In fact, it’s planned for Plasma Mobile to use the same layout manager component, to make the user experience “similar but different” and have less code duplication, while maintaining the UI very distinct between the two very different device types.

UI-wise in the desktop it doesn’t change much for now. the most notable difference is visible resize handles that make managing the layout and moving/resizing the plasmsoids much easier and more intuitive. Especially with touchscreen: now while manipulating plasmoids via touch, the resize handles become way bigger, and is possible to move and resize via a pinch gesture as well.

Lastly (for now!) the behavior during screen resolution switch improved a lot: if you connect a projector with a smaller resolution that relayouts your desktop, or play a fullscreen game at a tiny resolution, when the resolution is restored, everything gets back to normal, no more applets all over the place after changing resolution

All of this should make it into Plasma 5.17.

Implementing a derivated class of kis_brushes_pipe <2019-07-05 Fri>

Friday 5th of July 2019 06:32:00 AM

I've been working all week, instead of trying to deliver a feature I tried to write and organize the whole class, and then slowly write all the small functions Read More...

Calamares CVE

Thursday 4th of July 2019 10:00:00 PM

Well, it seems I got my blog back online just in time to write about security vulnerabilities. Well, let’s call it a security weakness in Calamares and the initramfs tools in a lot of distributions.


Two CVE’s were files against Calamares this week, but I’ll only write about lax file permissions on initramfs images here. See the CVE database for more details.

The issue comes down to this: when creating an initramfs (which is done as root), a sensitive file is read. The initramfs file (a cpio archive) is created with lax permissions, and so any user who can read the initramfs file can then extract the contents of the sensitive file.

From the point of view of Calamares, the solution is to make sure that the initramfs is created with less lax file permissions. Simple, hey?

In principle, the umask is responsible for masking out file permissions bits, so a umask of 077 (octal!) would prevent group and other users (i.e. all the non-privileged users) from reading the initramfs. So all Calamares needs to do is set up a good umask before calling the tools, right?

If only it were that simple.


There’s a lot of distro’s out there. Calamares serves them without discriminating on toolset, language, or target audience. I’m really happy to have downstreams that write careful bug reports, who join on IRC to describe problems, who coach users about reporting problems. But there’s a lot of them, and there’s lots of different tools used to create initramfs out there.

Here are the tools I know about:

  • dracut (Fedora derivatives) doesn’t seem to be vulnerable, it has had a safer umask since 2012 (with a CVE and fix for a special case in 2016). So dracut does the right thing, always: sets umask 077 and the initramfs is not world-readable.
  • update-initramfs (Debian derivatives) has a configuration item for the umask in initramfs.conf, but this isn’t set in the Calamares-using Debian derivatives I looked at. Setting umask in the environment has no effect, because the tool actively resets the umask, to a lax value unless configured otherwise.
  • mkinitcpio (Arch derivatives) doesn’t seem to have anything at hand. It obeys umask, but only when the initramfs file doesn’t exist yet; it does not reset file permissions on an overwritten file.

Personally I feel the tools need to be fixed. Debian derivatives should install an initramfs.conf that sets UMASK=077. Users of mkinitcpio should make sure the umask is set right when generating the initramfs for the first time.

But what I think, personally, doesn’t directly affect distro’s, so Calamares is getting another (security-oriented) release today, with the following changes which are very unusual for an installer that doesn’t have many opinions:

  • Distro’s that use the initramfs module in Calamares will get a configuration snippet that sets UMASK=077.
  • Distro’s that use the initcpio module in Calamares will get all their initramfs’es set to safe permissions during installation.

After installation there’s not much I can do; those that have a safer configuration snippet will keep using it, while mkinitcpio users are dependent on having a safe umask when a kernel update happens.


Three distro’s I used for testing things for this work – and I needed a variety, to see all the initramfs variations – were Chakra and ArcoLinux and Lubuntu.

These distro’s have a very very different approach to a Live CD and what ends up installed; Chakra gives you a full and wonderful KDE Plasma experience with all the bells and whistles (and latte dock too). ArcoLinux gives you a minimal XFCE-based Live experience, even as it installs a KDE Plasma environment to your hard disk. Lubuntu is fast and light-weight but I notice it’s not-Plasma all the time because I have so many KDE Plasma shortcuts in my muscle memory. So it’s a nice place to visit, but I wouldn’t want to live there.

I can heartily recommend some distro-shopping every now and then.

.. and after that I can get back to KDE-on-FreeBSD.

Look for a new Calamares release friday the 5th, with fixes, but it will take a while for that to get through to distro’s.

2019 Plasma and Usability & Productivity sprint

Thursday 4th of July 2019 05:15:55 PM

From 19.6. to 25.6. I attended this year’s combined Plasma and Usability & Productivity sprint in the beautiful city of Valencia.

It was a great opportunity to meet old and new friends, drink beer and sangria on the rooftop and of course do some hacking.

First we discussed about the future development of Plasma, especially the Wayland experience. I was particularly interested in how we can solve the two missing pieces in KDE Connect on Wayland, Keyboard input and clipboard synchronization.

We did not only discuss things but got our hands dirty as well tough. I took the opportunity to work on several components, most of which I haven’t worked on much before:

  • I’ve reworked the system tray settings to be more concise and usable. Furthermore I worked on hiding certain system tray elements when they are not in a useful state, making the system tray less cluttered. I also fixed the appearance of the disk quota icon in the system tray settings and the system tray itself when using a dark theme.
  • After I cleaned the code and polished the export menu I worked on integrating an image annotator in Spectacle. Kudos to Damir Porobic for doing the hard part of it by providing kImageAnnotator.
  • I implemented a more human friendly sort order description in Dolphin.
  • I improved the user experience of Purpose, the framework used for sharing stuff. Cancelling a share doesn’t show an error any more. The share dialogs for KDE Connect and bluetooth got a huge makeover. The share menu now shows ellipsis where semantically appropriate.
  • Next to polishing the menus I implemented sharing via Purpose in Gwenview.

The sprint was generously hosted by Slimbook. Thank you very much for that!

Sprints like this are only possible due to the donations KDE e.V. is getting. Please consider donating if you want us to be able to further improve our software.

KIOFuse: June in Review

Wednesday 3rd of July 2019 11:52:38 PM

The coding period has now extended over a month and quite a few improvements have been merged into KIOFuse. In my last post I mentioned the development of a KIO error to FUSE error mapping and 32 bit support.

However, interestingly enough it took quite a long time for the 32-bit support branch to be merged. This was because of a test that didn’t fail nor pass – it froze. The test suite would never finish and the process would only respond to SIGKILL. After days of debugging it was determined that fuse_notify_inval_* functions don’t play well when writeback caching is enabled and hence there is now a patch to disable it. Of course this will incur a performance hit as writes will go straight to KIOFuse, and hence straight to disk (although the kernel may cache our write requests to our own cache). Whilst this is unfortunate, seeming as most KIO slaves are network based, switching from a writeback caching policy to a writethrough one is unlikely to hamper performance too much.

In other news, KIOFuse can now handle SIGTERM, SIGINT and SIGHUP signals. Signal handlers can only call async-signal-safe functions. However in Qt there is a bit of hack one can perform, as inspired by this tutorial. Hence, in response to these signals, KIOFuse will flush all dirty nodes to disk, meaning no sudden data loss!

Mounts can now have their password changed.

The lookup function has now been optimised. Previously a lookup would call KIO::listDir, which was totally unnecessary – a KIO::stat would suffice and this is what the patch has switched to. It also increased the data buffer from 1MB to 14MB.

Unmount support has currently been postponed. It is proving problematic to implement reliably and unmounting only really provides a marginal benefit, so it is yet to be seen if we will implement it at all. The current WIP patch can be found here.

It has been decided that slaves that do not implement KIO::stat will not be supported. It’s a bit of a hassle to implement with extremely marginal benefit. There are only a few slaves that don’t implement KIO::stat, such as fonts and thumbnails.

An issue with KDE Connect not working properly has been fixed upstream. I haven’t 100% confirmed which patch has fixed this for us, but I’m placing my bets on this one.

Currently, the Google Drive API reports a size of zero for files that are not supported by GDrive, such as odt files , and their proprietary formats – i.e. Google Docs. Whilst we can update the size quite easily by downloading the file, the file turns out corrupted, and is only openable if the program has a repair option (such as LibreOffice). Unfortunately, I’ve not been able to find out why exactly this is happening, and have not come up with a fix. Currently this is being shelved and I hope to revisit it at a later date with a fresher mind.

We’d welcome anyone to use and test KIOFuse. Feel free to notify us on any bugs or performance issues by opening an issue and you can even contribute a patch if you wish!

Ngrx Entities and One to Many Relationships

Wednesday 3rd of July 2019 07:59:14 PM

When I started with Ngrx the Entity module didn't exist. My state consisted of arrays of objects. The reducers and selectors were array manipulations. It worked well but if the state had a large number of objects, the filter and maps were expensive and required lots of code.
The Entity library made it much simpler. My reducers are much less code and dramatically simple in comparison. The selectors are about half the length. It all works quickly, is easy to set up.

Essentially the data is stored as an entity object. { [id: string|number]: dataobj} There is a list of id's, which can be sorted. You access a specific object using the id as a property. entity[id]. If you have a list of id's, => entity[i] will give you a list of objects. The Entity can sort the ids, extract whatever key you want from your data. But what if you have a relational data structure?

For example, you have a contact list.
interface Contact {
  id: string;
  name: string;
  note: string;

You also have an email address list. Each contact may have one or many email addresses.
interface Email {
  id: string;
  email: string;
  note: string;
  contactid: string;

For each contact, the email addresses would have the contact id to relate them.

A selector on the email Entity would have to do something like this to get the related emails for the selected contact.

export const getSelectedEmails = createSelector(
   ( entities, ids, contact) => {
      return ids.filter(i => entities[i].contactid === true: false)

Right back to filtering long arrays to extract a few matching items.

That is a pretty simple situation. In real life it gets complicated quickly. Maybe you have an attribute property on the email, where the email address is tagged various ways; receive only, business, personal, project specific, etc. You might want to filter on those attributes as well. You might want to do a many to many relation where the same email address belongs to many people.

This is what I needed. So I came up with another property of the Entity State.
interface Keys {
   [key: string]: { [id: string| number]: ids[] }

This is how the keys are extracted. It looks similar to the stock Entity
export const adapter: EntityRelationAdapter<InventoryData> = createEntityRelationAdapter<InventoryData>({ selectId: Inventorydata => Inventorydata.tid, selectKey: { item: InventoryData => InventoryData.itemtid, vendoritem: InventoryData => InventoryData.vendorinvoice, resourcetype: InventoryData => InventoryData.resourcetype, } });  selectKey has functions that extract keys, which creates a list of keys. So in your selector you would do something like keys['item'][itemid] to get a list of ids that are related to the item data.

As with the Entity the array of ids is created as each item is added to the entity state. I haven't implemented a sort function, mostly because I don't need it, and typically the related lists are short and easy to sort in a selector.

Take a look. It is useful to me.

SMC Malayalam fonts updated in Fedora 30

Wednesday 3rd of July 2019 07:02:57 AM

The Fedora package smc-fonts has a set of Malayalam fonts (AnjaliOldLipi, Kalyani, Meera, Rachana, RaghuMalayalamSans and Suruma) maintained by SMC. We used to package all these fonts as a single zip file hosted at These fonts were last updated in 2014 for Fedora, leaving them at version 6.1.

Since then, a lot of improvements were made to these fonts — glyph additions/corrections, opentype layout changes, fontTools based build system and separate source repository for each font etc.. There were lengthy discussions on the release management of the fonts, and it was partially the reason fonts were not updated in Fedora. Once it was agreed to follow different version number for each font, and a continuous build+release system was put in place at Gitlab, we could ensure that fonts downloaded from SMC website were always the latest version.

To reflect the updates in Fedora, we had to decide how to handle the monolithic source package at version 6.1 versus the new individual releases (e.g. Rachana is at version 7.0.1 as of this writing). In a discussion with Pravin Satpute, we agreed to obsolete the existing fonts package and give each font its own package.

Vishal Vijayaraghavan kindly stepped up and did the heavy lifting of creating the new packages, and we now even build the ttf font file from the source. See RHBZ#1648825 for details.

With all that in place, in Fedora 30, all these fonts are in latest version — for instance, see Rachana package. The old package smc-fonts no longer exists, instead each individual package such as smc-rachana-fonts or smc-meera-fonts can be installed. Our users will now be able to enjoy the improvements made over the years — including updated Unicode coverage, new glyphs, improved existing glyphs, much better opentype shaping etc.

Topsy-turvy 5th Week

Tuesday 2nd of July 2019 02:02:50 PM

Finally, I can write myself as a professional developer, cause for the first time I got paid, that also by cash, for writing code. So after the boost battle of last month, it was time to test the algorithm out in the wild and not limit it to the confined boundary of the tests.

Usability & Productivity Sprint 2019

Monday 1st of July 2019 10:44:33 PM

I [partially, only 2 days out of the 7] attended the Usability & Productivity Sprint 2019 in Valencia two weekends ago.

I was very happy to meet quite some new developer blood, which is something we had been struggling a bit to get lately, so we're starting to get on the right track again :) And I can only imagine it'll get better and better due to the "Onboarding" goal :)

During the sprint we had an interesting discussion about how to get more people to know about usability, and the outcome is that probably we'll try to get some training to members of KDE to increase the knowledge of usability amongst us. Sounds like a good idea to me :)

On the more "what did *you* actually do" side:
* worked on fixing a crash i had on the touchpad kded, (already available on the latest released Plasma!)
* finished part of the implementation for Optional Content Group Links support in Okular (i started that 3 years ago and i was almost sure i had done all the work, but i clearly had not)
* Did some code reviews on existing okular phabricator merge requests (so sad i'm still behind though, we need more people reviewing there other than me)
* Together with Nicolas Fella worked on allowing extra fields from json files to be translated, we even documented it!
* Changed lots of applications released on KDE Applications to follow the KDE Applications versioning scheme, the "winner" was kmag, that had been stuck in version 1.0 for 15 years (and had more than 440 commits since then)
* Fixed a small issue with i18n in kanagram

I would like to thank SLIMBOOK for hosting us in their offices (and providing a shuttle from them to the hotel) and the KDE e.V. for sponsoring my attendance to the sprint, please donate to KDE if you think the work done at sprints is important.

[bobulate] lives!

Monday 1st of July 2019 10:00:00 PM

Well, it’s been a long six-to-eight months. But [bobulate] is back, and some of the pent-up blogging needs are ready to be unleashed on Planet KDE and wherever else.

Late last year there were some hiccups with my hosting provider, which led to SSL issues. Those were solved, and I carried on with the existing hosting. Then in february or so the MySQL server at the hosting provider went down, and I filed some tickets, grumbled a bit, and figured it would resolve itself. After all, this blog isn’t a staggeringly important piece of internet infrastructure, and I could let off notifications through the Calamares announcements for my major work, and through Twitter for KDE packaging on FreeBSD.

And february dragged on into april, may, with no resolution of the issues in sight, and then a letter arrived from the Dutch internet authority saying that my hoster was no longer an official registry and that my domains were now floating around.

That’s when some form of panic struck – although in the end I only lost one of them to a domain-hijacker in Hong Kong. I’ve switched hosting to another Free-Software-friendly place, switched out Wordpress for the much easier-to-manage Jekyll, and will be re-building the archives as I go along.

Free Software Stuff

To justify having this on the Planet, let’s talk a little about Free Software.

  • Calamares, a Linux system installer used by a bunch of boutique (specialized) distro’s, continues chugging along. I decided this spring to try to stick to a two-week release cycle, in order to get things out the door – any things – rather than grind though a set milestone. That’s worked pretty well, getting small and incremental improvements out the door much faster – although the big stuff still takes a long time to work out. I’ll be sticking to this schedule after summer vacations.
  • KDE-FreeBSD continues to hum along, Tobias is doing most of the work while I’m busy, but together we manage to keep the packaing up-to-date with all the latest releases.
  • I wrote a little meeting-management bot for Matrix, based on what I remember from the IRC channel #koffie from EFnet long, long ago.

Summer vacation’s been mentioned. After those vacations, it’s september, and so

More in Tux Machines

LWN: Spectre, Linux and Debian Development

  • Grand Schemozzle: Spectre continues to haunt

    The Spectre v1 hardware vulnerability is often characterized as allowing array bounds checks to be bypassed via speculative execution. While that is true, it is not the full extent of the shenanigans allowed by this particular class of vulnerabilities. For a demonstration of that fact, one need look no further than the "SWAPGS vulnerability" known as CVE-2019-1125 to the wider world or as "Grand Schemozzle" to the select group of developers who addressed it in the Linux kernel. Segments are mostly an architectural relic from the earliest days of x86; to a great extent, they did not survive into the 64-bit era. That said, a few segments still exist for specific tasks; these include FS and GS. The most common use for GS in current Linux systems is for thread-local or CPU-local storage; in the kernel, the GS segment points into the per-CPU data area. User space is allowed to make its own use of GS; the arch_prctl() system call can be used to change its value. As one might expect, the kernel needs to take care to use its own GS pointer rather than something that user space came up with. The x86 architecture obligingly provides an instruction, SWAPGS, to make that relatively easy. On entry into the kernel, a SWAPGS instruction will exchange the current GS segment pointer with a known value (which is kept in a model-specific register); executing SWAPGS again before returning to user space will restore the user-space value. Some carefully placed SWAPGS instructions will thus prevent the kernel from ever running with anything other than its own GS pointer. Or so one would think.

  • Long-term get_user_pages() and truncate(): solved at last?

    Technologies like RDMA benefit from the ability to map file-backed pages into memory. This benefit extends to persistent-memory devices, where the backing store for the file can be mapped directly without the need to go through the kernel's page cache. There is a fundamental conflict, though, between mapping a file's backing store directly and letting the filesystem code modify that file's on-disk layout, especially when the mapping is held in place for a long time (as RDMA is wont to do). The problem seems intractable, but there may yet be a solution in the form of this patch set (marked "V1,000,002") from Ira Weiny. The problems raised by the intersection of mapping a file (via get_user_pages()), persistent memory, and layout changes by the filesystem were the topic of a contentious session at the 2019 Linux Storage, Filesystem, and Memory-Management Summit. The core question can be reduced to this: what should happen if one process calls truncate() while another has an active get_user_pages() mapping that pins some or all of that file's pages? If the filesystem actually truncates the file while leaving the pages mapped, data corruption will certainly ensue. The options discussed in the session were to either fail the truncate() call or to revoke the mapping, causing the process that mapped the pages to receive a SIGBUS signal if it tries to access them afterward. There were passionate proponents for both options, and no conclusion was reached. Weiny's new patch set resolves the question by causing an operation like truncate() to fail if long-term mappings exist on the file in question. But it also requires user space to jump through some hoops before such mappings can be created in the first place. This approach comes from the conclusion that, in the real world, there is no rational use case where somebody might want to truncate a file that has been pinned into place for use with RDMA, so there is no reason to make that operation work. There is ample reason, though, for preventing filesystem corruption and for informing an application that gets into such a situation that it has done something wrong.

  • Hardening the "file" utility for Debian

    In addition, he had already encountered problems with file running in environments with non-standard libraries that were loaded using the LD_PRELOAD environment variable. Those libraries can (and do) make system calls that the regular file binary does not make; the system calls were disallowed by the seccomp() filter. Building a Debian package often uses FakeRoot (or fakeroot) to run commands in a way that appears that they have root privileges for filesystem operations—without actually granting any extra privileges. That is done so that tarballs and the like can be created containing files with owners other than the user ID running the Debian packaging tools, for example. Fakeroot maintains a mapping of the "changes" made to owners, groups, and permissions for files so that it can report those to other tools that access them. It does so by interposing a library ahead of the GNU C library (glibc) to intercept file operations. In order to do its job, fakeroot spawns a daemon (faked) that is used to maintain the state of the changes that programs make inside of the fakeroot. The libfakeroot library that is loaded with LD_PRELOAD will then communicate to the daemon via either System V (sysv) interprocess communication (IPC) calls or by using TCP/IP. Biedl referred to a bug report in his message, where Helmut Grohne had reported a problem with running file inside a fakeroot.

Flameshot is a brilliant screenshot tool for Linux

The default screenshot tool in Ubuntu is alright for basic snips but if you want a really good one you need to install a third-party screenshot app. Shutter is probably my favorite, but I decided to give Flameshot a try. Packages are available for various distributions including Ubuntu, Arch, openSuse and Debian. You find installation instructions on the official project website. Read more

Android Leftovers

IBM/Red Hat and Intel Leftovers

  • Troubleshooting Red Hat OpenShift applications with throwaway containers

    Imagine this scenario: Your cool microservice works fine from your local machine but fails when deployed into your Red Hat OpenShift cluster. You cannot see anything wrong with the code or anything wrong in your services, configuration maps, secrets, and other resources. But, you know something is not right. How do you look at things from the same perspective as your containerized application? How do you compare the runtime environment from your local application with the one from your container? If you performed your due diligence, you wrote unit tests. There are no hard-coded configurations or hidden assumptions about the runtime environment. The cause should be related to the configuration your application receives inside OpenShift. Is it time to run your app under a step-by-step debugger or add tons of logging statements to your code? We’ll show how two features of the OpenShift command-line client can help: the oc run and oc debug commands.

  • What piece of advice had the greatest impact on your career?

    I love learning the what, why, and how of new open source projects, especially when they gain popularity in the DevOps space. Classification as a "DevOps technology" tends to mean scalable, collaborative systems that go across a broad range of challenges—from message bus to monitoring and back again. There is always something new to explore, install, spin up, and explore.

  • How DevOps is like auto racing

    When I talk about desired outcomes or answer a question about where to get started with any part of a DevOps initiative, I like to mention NASCAR or Formula 1 racing. Crew chiefs for these race teams have a goal: finish in the best place possible with the resources available while overcoming the adversity thrown at you. If the team feels capable, the goal gets moved up a series of levels to holding a trophy at the end of the race. To achieve their goals, race teams don’t think from start to finish; they flip the table to look at the race from the end goal to the beginning. They set a goal, a stretch goal, and then work backward from that goal to determine how to get there. Work is delegated to team members to push toward the objectives that will get the team to the desired outcome. [...] Race teams practice pit stops all week before the race. They do weight training and cardio programs to stay physically ready for the grueling conditions of race day. They are continually collaborating to address any issue that comes up. Software teams should also practice software releases often. If safety systems are in place and practice runs have been going well, they can release to production more frequently. Speed makes things safer in this mindset. It’s not about doing the “right” thing; it’s about addressing as many blockers to the desired outcome (goal) as possible and then collaborating and adjusting based on the real-time feedback that’s observed. Expecting anomalies and working to improve quality and minimize the impact of those anomalies is the expectation of everyone in a DevOps world.

  • Deep Learning Reference Stack v4.0 Now Available

    Artificial Intelligence (AI) continues to represent one of the biggest transformations underway, promising to impact everything from the devices we use to cloud technologies, and reshape infrastructure, even entire industries. Intel is committed to advancing the Deep Learning (DL) workloads that power AI by accelerating enterprise and ecosystem development. From our extensive work developing AI solutions, Intel understands how complex it is to create and deploy applications for deep learning workloads. That?s why we developed an integrated Deep Learning Reference Stack, optimized for Intel Xeon Scalable processor and released the companion Data Analytics Reference Stack. Today, we?re proud to announce the next Deep Learning Reference Stack release, incorporating customer feedback and delivering an enhanced user experience with support for expanded use cases.

  • Clear Linux Releases Deep Learning Reference Stack 4.0 For Better AI Performance

    Intel's Clear Linux team on Wednesday announced their Deep Learning Reference Stack 4.0 during the Linux Foundation's Open-Source Summit North America event taking place in San Diego. Clear Linux's Deep Learning Reference Stack continues to be engineered for showing off the most features and maximum performance for those interested in AI / deep learning and running on Intel Xeon Scalable CPUs. This optimized stack allows developers to more easily get going with a tuned deep learning stack that should already be offering near optimal performance.