Error message

User warning: The following module is missing from the file system: ldap_sso. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /srv/www/drupal7/drupal-7.56/includes/

Plasma Mobile in Randa(aaaaaaaa)

Bhushan Shah - Tue, 2017-09-19 05:30

Last week I had a chance to attend the Randa meetings 2017, my plan was to work on the Plasma Mobile during the sprint, improve the state of current images. A few things changed over the course of the week:

New shiny wallpaper and packages

Starting from 8 Sept, we started using the packages from KDE Neon buildsystem instead of building them on the Plasma Mobile CI, this provides few benefits,

  • No need to separately build the common things like Qt5, KDE Frameworks, Plasma
  • Always up-to-date packages, no need to manually re-trigger builds for common things

We also upgraded to newer version of Qt, Qt 5.9 from the older version of Qt 5.7.1, this aligns our stack with whatever KDE Neon dev unstable edition is using.

Shiny Plasma

Rootfs for non-nexus Qualcomm devices

Non-nexus Qualcomm devices use a modified version of the hwcomposer.h which is not ABI compatible with the generic version of the android API headers, so for them the libhybris and kwin need to be separately built. Previously our CI infrastructure didn’t support this workflow, however now we are able to create the rootfs for such devices. Below is an image of Plasma Mobile running on Xiomi Mi device.

Plasma Mobile on CAF device

Marble maps

At Randa, we had a chance to test the newer version of the Marble maps, which has much more improved performance when zooming out-in. We were able to happily search locate Randa in the Marble maps.

Marble maps on Plasma Mobile

QML based mobile friendly “konsole”

Previously we were using Konsole from the KDE Applications as a terminal emulator, however Konsole user interface was not mobile-friendly, and it was not possible to e.g, tab complete the command, go through history, etc. At Randa Emmanuel Lepage Vallee pointed us to qmltermwidget, which powers the terminal application in Ubuntu Touch and Cool-retro-term application. Marco Martin was able to write a simple QML application around qmltermwidget which can replace Konsole in Plasma Mobile.

QML based Terminal application

Kirigami based koko

During GSoC 2017 lot of work has been put to port the normal QtQuick based image viewer application Koko to kirigami2, you can follow the work of Student developer Atul Sharma on his blog. At the Randa Sprint, we were able to test this work on Plasma Mobile and it shows great improvements compared to the older version.

Koko, image gallery application

Improved window switching experience

Due to a bug in the Plasma Mobile shell, shell windows such as task switcher and shell itself were also appearing in the task switcher, as a result of that user was able to close the shell window which ultimately ends up crashing the plasmashell. We were able to fix this bug in the plasma-workspace and plasma-phone-components so that Plasma Mobile shell windows would not appear in the task switcher.

Task switching


Yes, that is Kube in the first picture, we were able to run the Kube on the Plasma Mobile, it works in theory on Plasma Mobile, however the user interface is not mobile-friendly and needs various fixes to be usable on mobile. We will work with the Kube team to fix the issues and then test them on Plasma Mobile in the future.


That is all for now, I would like to thank the all the donors who donated for the Randa Meetings 2017, and made it possible for me to travel to Randa, Switzerland.

If you liked the work done on Plasma Mobile during the Randa Sprint, please support us on Randa 2017 fundraiser to make events like Randa possible in the future.

Akademy 2017 - Recap

Bhushan Shah - Sun, 2017-08-13 05:30

Last month I had opportunity to visit the Almería, Spain for Akademy 2017. Akademy 2017 is KDE’s annual world summit. Akademy makes it possible to meet the felow KDE contributors, some of whom you only know with their IRC nicknames (Yes, I am not old enough to know every contributors yet :p). Here is few things I did at the Akademy 2017.

Plasma Mobile

On the 2nd day I presented a talk about Plasma Mobile, Slides for that talk is available here. This talk covers various topics,

  • Achievements of Plasma Mobile project for year 2017
  • Project Halium
  • New devices

In addition to all the good things, I also discussed about the areas where Plasma Mobile project needs improvement and where community can help.

  • Quality Assurance
  • Testing
  • Applications

There are several external factors which also matters for Plasma Mobile project,

  • Kernel version are too old, hard to maintain security
  • Lack of the open devices
  • Devices requires closed sources BSP to function to full extent

I also talked about the postmarketOS project which aims for the 10 year life-cycle of the phones, postmarketOS is currently using the weston as their reference user interface, and have interest in using Plasma Mobile as the reference user interface.

I also talked about various programs which are working towards the open devices,

  • Open devices program by Sony
  • Effort to support the devices by mainline kernel
  • Fairphone
  • Purism’s Linux Phone(?)

Video recording for this talk is not available yet, but it will be available at soon.

We also had scheduled a Plasma Mobile BoF, where we discussed about the Plasma Mobile Vision, Strategy, Convergence and more planning with rest of the Plasma Team.

Plasma BoF

KDE Student Programs BoF

In addition to being maintainer of Plasma Mobile project I am also the part of KDE Student Programs Adminstration team, on Tuesday we organized a BoF session where students, mentors and admins from various programs such as GSoC, GCI, SoK, OPW took part and discussed how we are doing in this year’s programs, Good or bad? Where we needs to improve? Overall this was quite productive discussion.


KDE Neon BoF

I also participated in the KDE Neon BoF, in KDE Neon BoF I mainly discussed the addition of ARM architecture in the Neon CI and also took lessons about how OpenQA is used on the KDE Neon CI. I do plan to use the OpenQA eventually for Plasma Mobile images.


Overall this was very productive Akademy, where we discussed various topics which are typically hard to discuss over the communication media like E-mail or IRC. I would like to thank the KDE e.V. for covering my flight and accomodation cost to attend the Akademy. I will have another chance to attend another event next month : Randa Meetings 2017. This year’s randa meetings main topic is Make KDE more accessible.

However to make Randa Meetings possible KDE community needs your help, Please donate at Randa Meetings 2017 Fundraising Campaign.

Neon CI was down, Why?

Bhushan Shah - Fri, 2017-08-04 05:30

This post is public service announcement regarding the KDE Neon infrastructure.

Earlier we KDE neon developers decided that we should build the armhf and/or arm64 packages on Neon CI itself instead of the different Plasma Mobile specific Jenkins Instance. First step to make this happen was the adding ARM architecture in the KDE Neon package archive. We are using the Aptly for serving the packages.

Aptly however have a limitation that if you have started with publishing the empty repository, then you need to specify the complete architectures list initally and that list can’t be updated after publishing. See quote from Aptly docs,

Empty local repos could be published as well (as placeholder, for subsequent updates using aptly publish update command). When publishing empty local repos it is important to specify complete architectures list (using -architectures flag), as it can’t be changed after publishing.

Due to this limitation, only solution we had was to drop and republish the repositories with new architectures added. I started working on this at 15:43:14 IST yesterday, following were the steps taken:

  • Suspended neon CI
  • Stopping the aptly service on the server
  • Create a staging public repository and symlink it to older path
  • Take a backup of the old aptly db at ~/aptly/db
  • Restart the aptly service and run a script to drop and republish the public repositories

At this point, script failed with cryptic 404 error instantly however, upon inspection we realized that it was failing for old wily repos, which are unused since we are using the Ubuntu 16.04 xenial nowadays. Since we are not doing any builds of wily currently, script was modified to skip the published repositories of wily distribution. However next run of script failed with 404 API error again. Cause for this error turned out to be different, it was design flow in the aptly REST API which is exposed when the publish Prefix have / or _ in it. To quote from Aptly docs,

if publishing prefix contains slashes /, they should be replaced with underscores (_) and underscores should be replaced with double underscore (__).

At this point checking state of aptly revealed that out of 10 publishing end points we had just 3 publishing endpoints present, At this point we reverted to older db backup and fixed the script, this time execution of script was sucessful. However I wanted someone to verify that everything is in order before making the new published repositories public. So today after inspection of both old and new repositories I’ve made the change final and also KDE Neon Jenkins is now back in service, running builds.

For users

This change affects the KDE Neon archive. I’ve done my best to verify that everything is in order but still if you face any errors while doing apt update or apt upgrade, please let us know by commenting here or in #kde-neon IRC channel. I will keep backup of old aptly db and public repositories for 1 week and then will clean it if no complaints are received.

Edit: Update URL to Mobile CI and update the description of bug which we hit

New Driver Manager for Kubuntu

Rohan Garg - Sun, 2014-02-09 23:49

Hola Kubuntu users

Ubuntu ‘recently’ deprecated jockey and moved to ubuntu-drivers-common. ubuntu-drivers-common is a python backend which will try to figure out which drivers are best suited to your system. Up till Kubuntu 13.10 we were still relying on the backend called Jockey which is python2 , however for the 14.04 cycle, one of our major tasks was to rehaul the driver manager interface and use the fancy new ubuntu-drivers-common backend which is python3 based.

By leveraging this new backend, we are now at feature parity with Ubuntu when it comes to driver handling. Packages are now available to trusty users and can be acquired by installing the ‘kubuntu-driver-manager’ package.

Once installed you’ll find it in your System Settings Menu under “Driver Manager for Kubuntu”


If you find any bugs , please report them here

Categories: Blogs