22 Sep 2017

feedPlanet Ubuntu

Ubuntu Insights: Canonical Distribution of Kubernetes: Dev Summary (Sept 22 2017)

This article originally appeared on Tim Van Steenburgh's blog

September 15th concluded our most recent development sprint on the Canonical Distribution of Kubernetes (CDK). Here are some highlights:

Canal Bundle

Our new Canal bundle is published! If you need network policy support in your cluster, try it out:

juju deploy canonical-kubernetes-canal

In the future you'll be able to choose between Flannel and Calico when deploying Kubernetes via conjure-up.

Blogs and Demos

In case you missed them, check out some new blog posts and demos of CDK from members of the CDK engineering team:


We added more tests for RBAC and updated CI to start testing an RBAC-enabled cluster. Our remaining task for RBAC is to plan and test the upgrade path for old clusters once we make RBAC on-by-default.


We built and published an s390x nginx-ingress-controller image and an e2e snap, and started testing a lxd CDK cluster on s390x. Since then we've gotten access to more hardware and are now testing on s390x vms using the Juju manual provider.


In our current sprint we've started testing 1.8.0 in anticipation of the upstream release at the end of this month. We're also testing with docker 1.13.1, which will soon become the default in CDK.

If you'd like to follow along more closely with CDK development, you can do so in the following places:

Until next time!

22 Sep 2017 8:13pm GMT

Sebastian KŘgler: The Evolution of Plasma Mobile

Plasma MobilePlasma Mobile

Back around 2006, when the Plasma project was started by Aaron Seigo and a group of brave hackers (among which, yours truly) we wanted to create a user interface that is future-proof. We didn't want to create something that would only run on desktop devices (or laptops), but a code-base that grows with us into whatever the future would bring. Mobile devices were already getting more powerful, but would usually run entirely different software than desktop devices. We wondered why. The Linux kernel served as a wonderful example. Linux runs on a wide range of devices, from super computers to embedded systems, you would set it up for the target system and it would run largely without code changes. Linux architecture is in fact convergent. Could we do something similar at the user interface level?

Plasma Netbook

In 2007, Asus introduced the Eee PC, a small, inexpensive laptop. Netbooks proved to be all the rage at that point, so around 2009, we created Plasma Netbook, proving for the first time that we could actually serve different device user interfaces from the same code-base. There was a decent amount of code-sharing, but Plasma Netbook also helped us identifying areas in which we wanted to do better.

Plasma Mobile (I)

Come 2010, we got our hands on an N900 by Nokia, running Maemo, a mobile version of Linux. Within a week, during a sprint, we worked on a proof-of-concept mobile interface of Plasma:

Well, Nokia-as-we-knew-it is dead now, and Plasma never materialized on Nokia devices.

Plasma Active

Plasma Active was built as a successor to the early prototypes, and our first attempt at creating something for end-users. Conceived in 2011, the idea was not just to produce a simple Plasma user interface for a tablet device, but also deliver on a range of novel ideas for interaction with the device, closely related to the semantic desktop. Interlinked documents, contacts, sharing built right into the core, not just a "dumb" platform to run apps on, but a holistic system that allows users to manage their digital life on the fly. While Plasma Active had great promise and a lot of innovative potential, it never materialized for end-users in part due to lack of interest from both, the KDE community itself, but also from people on the outside. This doesn't mean that the work put into it was lost, but thanks to a convergent code-base, many improvements made primarily with Plasma Active in mind have improved Plasma for all its users and continue to do so today. In many ways, Active proved valuable as a playground, as a clean slate where we want to take the technology, and how we can improve our developemnt process. It's not a surprise that Plasma 5 today is developed in a process very similar to how we approached Plasma Active back then.

Plasma Mobile (II)

Learning from the Plasma Active project, in 2015 we regrouped and started to build a rather simple smartphone user interface, along with a reference software stack that would allow us not only to develop Plasma Mobile further, but to allow us to run on a growing number of devices. Plasma Mobile (II)'s goal wasn't to get the most innovative of interfaces out, but to create a bread-and-butter platform, a base to develop applications on. From a technology point of view, Plasma is actually very small. It shares approximately 95% of the code with its desktop companion, widgets, and increasingly applications are interchangeable between the two.

Plasma Mobile (in any shape or form) has never been this close to actually making it into the hands and pockets of end users. A collaboration project with Purism, a company bringing privacy and software freedom to end-users, we may create the first Plasma phone for end users and have it on the market as soon as januari 2019. If you want to support this project, the crowdfunding campaign has just passed the 40% mark, and you can be part of it - either by joining the development crew, or by pre-ordering a device and thereby funding the development.

22 Sep 2017 3:19pm GMT

Ubuntu Insights: Ubuntu Desktop Weekly Update: September 22, 2017

We're less than a week away from Final Beta! It seems to have come round very quickly this cycle. Next week we're at the Ubuntu Rally in New York City where we will be putting the finishing touches to the beta. In the meantime, here's a quick rundown on what happened this week:



We've been working on a Platform Snap for GNOME 3.26 to allow you to run the latest GNOME apps on Xenial as well as making Snaps for the new apps. This should be ready for testing soon and we'd appreciate some feedback.

Some desktop specific updates to snapd are also in the going to be rolling out soon; Snaps using the new Desktop interface will automatically get access to host system fonts and font caches.


In The News

22 Sep 2017 1:45pm GMT

21 Sep 2017

feedPlanet Ubuntu

Ubuntu Podcast from the UK LoCo: S10E29 ÔÇô Adamant Terrible Hammer - Ubuntu Podcast

This is Le Crossover Ubuntu Mashup Podcast thingy recorded live at UbuCon Europe in Paris, France.

It's Season Ten Episode Twenty-Nine of the Ubuntu Podcast! Alan Pope, Martin Wimpress, Marius Quabeck, Max Kristen, Rudy and Tiago Carrondo are connected and speaking to your brain.

In this week's show:

That's all for this week! If there's a topic you'd like us to discuss, or you have any feedback on previous shows, please send your comments and suggestions to show@ubuntupodcast.org or Tweet us or Comment on our Facebook page or comment on our Google+ page or comment on our sub-Reddit.

21 Sep 2017 8:10pm GMT

Ante Karamati─ç: Ime odbijeno

Nakon 8-9 dana i poslanog maila, danas sam dobio obavijest o tome što se dešava s mojom prijavom. Pa prenosim u cijelosti:

dana 12.09.2017 poslano je rezervacija u TS Zagreb (e - tvrtka). i poštom je poslana dok. i RZ obrazac u Hitro.hr Zagreb
Papirna dokumentacija je predana na sud 13.09.2017.Rezevacija imena nije prošla . .Obavijest je predignuta sa suda 18.09.2017(.Hirto.hr - Zagreb)
Obavijest je poštom danas stigla u Hitro.hr - Šibenik (21.09.2017.). Zvala sam Vas na mobitel da bi mogli predigniti potvrdu ,ali mi se niko ne javlja.
Stoga Vas obavje┼ítvam da mo┼żete predignuti obavijest u HITRO:HR ┼áibenik.

Dakle, eTvrtka je jedno veliko ni┼íta; obi─Źna la┼ż i prijevara. I dalje se dokumenti ┼íalju po┼ítom. Da se razumijemo, ovo nije problem slu┼żbenika koji su bili sustretljivi. Ovo je problem organizacije dr┼żave, odnosno Vlade. Slu┼żbenici su tu ┼żrtve isto kao i mi, koji poku┼íavamo ne┼íto stvoriti.

Dakle, ime je odbijeno.

U Republici Hrvatskoj je potrebno pro─çi 10 dana kako biste saznali mo┼żete li pokrenuti tvrtku s odre─Ĺenim imenom. U drugim dr┼żavama ovakve stvari ni ne postoje, ve─ç se tvrtke pokre─çu unutar jednog dana. Ako ┼żelimo biti plodno tlo za poduzetni┼ítvo, hitro.hr treba ukinuti (potpuno je besmislen) i uvesti suvremene tehnologije; algoritmi mogu pregledavati imena i to treba biti samo web stranica. Nikakvi protokoli, pla─çanja, stajanja u redu.

21 Sep 2017 3:47pm GMT

The Fridge: Ubuntu Community Council 2017 election under way!

The Ubuntu Community Council election has begun and ballots sent out to all Ubuntu Members. Voting closes September 27th at end of day UTC.

The following candidates are standing for 7 seats on the council:

Please contact the community-council@lists.ubuntu.com list if you are an Ubuntu Member but did not receive a ballot. Voting instructions were sent to the public address defined in Launchpad, or your launchpad_id@ubuntu.com address if not. Please also make sure you check your spam folder first.

We'd like to thank all the candidate for their willingness to serve in this capacity, and members for their considered votes.

Originally posted to the ubuntu-news-team mailing list on Tue Sep 12 14:22:49 UTC 2017 by Mark Shuttleworth

21 Sep 2017 3:30pm GMT

Scarlett Clark: KDE: Randa 2017! KDE Neon Snappy and more

Another successful Randa meeting! I spent most of my days working on snappy packaging for KDE core applications, and I have most of them done!

Snappy Builds on KDE Neon

We need testers! Please see Using snappy to get started.

In the evenings I worked on getting all my appimage work moved into the KDE infrastructure so that the community can take over.

I learned a great deal about accessibility and have been formulating ways to improve KDE neon in this area.

Randa meetings are crucial to the KDE community for developer interaction, brainstorming, and bringing great new things to KDE.
I encourage all of you to please consider a donation at https://www.kde.org/fundraisers/randameetings2017/

21 Sep 2017 12:54pm GMT

20 Sep 2017

feedPlanet Ubuntu

Jamie Strandboge: Easy ssh into libvirt VMs and LXD containers

Finding your VMs and containers via DNS resolution so you can ssh into them can be tricky. I was talking with St├ęphane Graber today about this and he reminded me of his excellent article: Easily ssh to your containers and VMs on Ubuntu 12.04.

These days, libvirt has the `virsh dominfo` command and LXD has a slightly different way of finding the IP address.

Here is an updated `~/.ssh/config` that I'm now using (thank you St├ęphane for the update for LXD):

Host *.lxd
#User ubuntu
#StrictHostKeyChecking no
#UserKnownHostsFile /dev/null
ProxyCommand nc $(lxc list -c s4 $(echo %h | sed "s/\.lxd//g") %h | grep RUNNING | cut -d' ' -f4) %p

Host *.vm
#StrictHostKeyChecking no
#UserKnownHostsFile /dev/null
ProxyCommand nc $(virsh domifaddr $(echo %h | sed "s/\.vm//g") | awk -F'[ /]+' '{if (NR>2 && $5) print $5}') %p

You may want to uncomment `StrictHostKeyChecking` and `UserKnownHostsFile` depending on your environment (see `man ssh_config`) for details.

With the above, I can ssh in with:

$ ssh foo.vm uptime
16:37:26 up 50 min, 0 users, load average: 0.00, 0.00, 0.00
$ ssh bar.lxd uptime
21:37:35 up 12:39, 2 users, load average: 0.55, 0.73, 0.66


Filed under: canonical, ubuntu, ubuntu-server

20 Sep 2017 9:39pm GMT

Serge Hallyn: Namespaced File Capabilities

Namespaced file capabilities

As of this past week, namespaced file capabilities are available in the upstream kernel. (Thanks to Eric Biederman for many review cycles and for the final pull request)


Some packages install binaries with file capabilities, and fail to install if you cannot set the file capabilities. Such packages could not be installed from inside a user namespace. With this feature, that problem is fixed.


What are they?

POSIX capabilities are pieces of root's privilege which can be individually used.

File capabilites are POSIX capability sets attached to files. When files with associated capabilities are executed, the resulting task may end up with privilege even if the calling user was unprivileged.

What's the problem

In single-user-namespace days, POSIX capabilities were completely orthogonal to userids. You can be a non-root user with CAP_SYS_ADMIN, for instance. This can happen by starting as root, setting PR_SET_KEEPCAPS through prctl(2), and dropping the capabilities you don't want and changing your uid. Or, it can happen by a non-root user executing a file with file capabilities. In order to append such a capability to a file, you require the CAP_SETFCAP capability.

User namespaces had several requirements, including:

  1. an unprivileged user should be able to create a user namespace
  2. root in a user namespace should be privileged against its resources
  3. root in a user namespace should be unprivileged against any resources which it does not own.

So in a post-user-namespace age, unprivileged user can "have privilege" with respect to files they own. However if we allow them to write a file capability on one of their files, then they can execute that file as an unprivileged user on the host, thereby gaining that privilege. This violates the third user namespace requirement, and is therefore not allowed.

Unfortunately - and fortunately - some software wants to be installed with file capabilities. On the one hand that is great, but on the other hand, if the package installer isn't able to handle the failure to set file capabilities, then package installs are broken. This was the case for some common packages - for instance httpd on centos.

With namespaced file capabilities, file capabilities continue to be orthogonal with respect to userids mapped into the namespace. However they capabilities are tagged as belonging to the host uid mapped to the container's root id (0). (If uid 0 is not mapped, then file capabilities cannot be assigned) This prevents the namespace owner from gaining privilege in a namespace against which they should not be privileged.


The opinions expressed in this blog are my own views and not those of Cisco.

20 Sep 2017 3:37pm GMT

Didier Roche: Ubuntu GNOME Shell in Artful: Day 13

Now that GNOME 3.26 is released, available in Ubuntu artful, and final GNOME Shell UI is confirmed, it's time to adapt our default user experience to it. Let's discuss how we worked with dash to dock upstream on the transparency feature. For more background on our current transition to GNOME Shell in artful, you can refer back to our decisions regarding our default session experience as discussed in my blog post.

Day 13: Adaptive transparency for Ubuntu Dock

GNOME Shell 3.26 excellent new release ships thus some dynamic panel transparency by default. If no window is next to the top panel, the bar is itself is translucent. If any windows is next to it, the panel becomes opaque. This feature is highlighted on the GNOME 3.26 release note. As we already discussed this on a previous blog post, it means that the Ubuntu Dock default opacity level doesn't fit very well with the transparent top panel on an empty desktop.

Previous default Ubuntu Dock transparency

Even if there were some discussions within GNOME about keeping or reverting this dynamic transparency feature, we reached out the Dash to Dock guys during the 3.25.9x period to be prepared. Started then some excellent discussions on the pull request which was already rolling full speed ahead.

The first idea was to have dynamic transparency. Having one status for the top panel, and another one for the Dock itself. However, this gives some weirds user experience after playing with it a little bit:

We can feel there are too much flickering, having both parts of the UI behaving independently. The idea I raised upstream was thus to consider all Shell UI (which is, in the Ubuntu session the top panel and Ubuntu Dock) as a single entity. Their opacity status is thus linked, as one UI element. Fran├žois agreed and had the same idea on his mind, before implementing it. The results is way more natural:

Those options are implemented as options in Dash to Dock settings panel, and we just set this last behavior as the default in Ubuntu Dock.

We made sure that this option is working well with the various dock settings we expose in the Settings application:

In particular, you can see that intelli-hide is working as expected: dock opacity changing while the Dock is vanishing and when forcing it to show up again, it's at the maximum opacity that we set.

The default with no application next to the panel or dock is now giving some good outlook:

Default empty Ubuntu artful desktop

The best part is the following: as we are getting closer to release and there is still a little bit of work upstream to get everything merged in Dash to Dock itself for options and settings UI which doesn't impact Ubuntu Dock, Michele has prepared a cleaned up branch that we can cherry-pick from directly in our ubuntu-dock branch that they will keep compatible with master for us! Now that the Feature Freeze and UI Freeze exceptions have been approved, the Ubuntu Dock package is currently building in the artful repository alongside other fixes and some shortcuts improvements.

As usual, if you are eager to experiment with these changes before they migrate to the artful release pocket, you can head over to our official Ubuntu desktop team transitions ppa to get a taste of what's cooking!

It's really a pleasure to work with Dash to Dock upstream, I'm using this blog opportunity to thank them again for everything they do and the cooperation they ease out for our use case.

20 Sep 2017 11:25am GMT

James Page: OpenStack Charms @ Denver PTG

Last week, myself and a number of the OpenStack Charms team had the pleasure of attending the OpenStack Project Teams Gathering in Denver, Colorado.

The first two days of the PTG where dedicated to cross project discussions, with the last three days focused on project specific discussion and work in dedicated rooms.

Here's a summary of the charm related discussion over the week.

Cross Project Discussions

Skip Level Upgrades

This topic was discussed at the start of the week, in the context of supporting upgrades across multiple OpenStack releases for operators. What was immediately evident was this was really a discussion around 'fast-forward' upgrades, rather than actually skipping any specific OpenStack series as part of a cloud upgrade. Deployments would still need to step through each OpenStack release series in turn, so the discussion centred around how to make this much easier for operators and deployment tools to consume than it has been to-date.

There was general agreement on the principles that all steps required to update a service between series should be supported whilst the service is offline - i.e. all database migrations can be completed without the services actually running; This would allow multiple upgrade steps to be completed without having to start services up on interim steps. Note that a lot of projects all ready support this approach, but its never been agreed as a general policy as part of the 'supports-upgrade' tag which was one of the actions resulting from this discussion.

In the context of the OpenStack Charms, we already follow something along these lines for minimising the amount of service disruption in the control plane during OpenStack upgrades; with implementation of this approach across all projects, we can avoid having to start up services on each series step as we do today, further optimising the upgrade process delivered by the charms for services that don't support rolling upgrades.

Policy in Code

Most services in OpenStack rely on a policy.{json,yaml} file to define the policy for role based access into API endpoints - for example, what operations require admin level permissions for the cloud. Moving all policy default definitions to code rather than in a configuration file is a goal for the Queens development cycle.

This approach will make adapting policies as part of an OpenStack Charm based deployment much easier, as we only have to manage the delta on top of the defaults, rather than having to manage the entire policy file for each OpenStack release. Notably Nova and Keystone have already moved to this approach during previous development cycles.

Deployment (SIG)

During the first two days, some cross deployment tool discussions where held for a variety of topics; of specific interest for the OpenStack Charms was the discussion around health/status middleware for projects so that the general health of a service can be assessed via its API - this would cover in-depth checks such as access to database and messaging resources, as well as access to other services that the checked service might depend on - for example, can Nova access Keystone's API for authentication of tokens etc. There was general agreement that this was a good idea, and it will be proposed as a community goal for the OpenStack project.

OpenStack Charms Devroom

Keystone: v3 API as default

The OpenStack Charms have optionally supported Keystone v3 for some time; The Keystone v2 API is officially deprecated, so we had discussion around approach for switching the default API deployed by the charms going forwards; in summary

At some point in time, we'll have to automatically switch v2 deployments to v3 on OpenStack series upgrade, but that does not have to happen yet.

Keystone: Fernet Token support

The charms currently only support UUID based tokens (since PKI was dropped from Keystone); The preferred format is now Fernet so we should implement this in the charms - we should be able to leverage the existing PKI key management code to an extent to support Fernet tokens.

Stable Branch Life-cycles

Currently the OpenStack Charms team actively maintains two branches - the current development focus in the master branch, and the most recent stable branch - which right now is stable/17.08. At the point of the next release, the stable/17.08 branch is no longer maintained, being superseded by the new stable/XX.XX branch. This is reflected in the promulgated charms in the Juju charm store as well. Older versions of charms remain consumable (albeit there appears to be some trimming of older revisions which needs investigating). If a bug is discovered in a charm version from a inactive stable branch, the only course of action is to upgrade the the latest stable version for fixes, which may also include new features and behavioural changes.

There are some technical challenges with regard to consumption of multiple stable branches from the charm store - we discussed using a different team namespace for an 'old-stable' style consumption model which is not that elegant, but would work. Maintaining more branches means more resource effort for cherry-picks and reviews which is not feasible with the currently amount of time the development team has for these activities so no change for the time being!

Service Restart Coordination at Scale

tl;dr no one wants enabling debug logging to take out their rabbits

When running the OpenStack Charms at scale, parallel restarts of daemons for services with large numbers of units (we specifically discussed hundreds of compute units) can generate a high load on underlying control plane infrastructure as daemons drop and re-connect to message and database services potentially resulting in service outages. We discussed a few approaches to mitigate this specific problem, but ended up with focus on how we could implement a feature which batched up restarts of services into chunks based on a user provided configuration option.

You can read the full details in the proposed specification for this work.

We also had some good conversation around how unit level overrides for some configuration options would be useful - supporting the use case where a user wants to enable debug logging for a single unit of a service (maybe its causing problems) without having to restart services across all units to support this. This is not directly supported by Juju today - but we'll make the request!

Cross Model Relations - Use Cases

We brainstormed some ideas about how we might make use of the new cross-model relation features being developed for future Juju versions; some general ideas:

We'll look to use the existing relations for some of these ideas, so as the implementation of this feature in Juju becomes more mature we can be well positioned to support its use in OpenStack deployments.

Deployment Duration

We had some discussion about the length of time taken to deploy a fully HA OpenStack Cloud onto hardware using the OpenStack Charms and how we might improve this by optimising hook executions.

There was general agreement that scope exists in the charms to improve general hook execution time - specifically in charms such as RabbitMQ and Percona XtraDB Cluster which create and distribute credentials to consuming applications.

We also need to ensure that we're tracking any improvements made with good baseline metrics on charm hook execution times on reference hardware deployments so that any proposed changes to charms can be assessed in terms of positive or negative impact on individual unit hook execution time and overall deployment duration - so expect some work in CI over the next development cycle to support this.

As a follow up to the PTG, the team is looking at whether we can use the presence of a VIP configuration option to signal to the charm to postpone any presentation of access relation data to the point after which HA configuration has been completed and the service can be accessed across multiple units using the VIP. This would potentially reduce the number (and associated cost) of interim hook executions due to pre-HA relation data being presented to consuming applications.

Mini Sprints

On the Thursday of the PTG, we held a few mini-sprints to get some early work done on features for the Queens cycle; specifically we hacked on:

Good progress was made in most areas with some reviews already up.

We had a good turnout with 10 charm developers in the devroom - thanks to everyone who attended and a special call-out to Billy Olsen who showed up with team T-Shirts for everyone!

We have some new specs already up for review, and I expect to see a few more over the next two weeks!


20 Sep 2017 10:51am GMT

Ante Karamati─ç: Cvr─Źci


Veli hitro.hr kako se rezervacija imena rje┼íava u 3 (tri) radna dana. Zahtjev je podnesen u utorak, 12.9. Danas je 20.9. ─îuju se samo cvr─Źci.

20 Sep 2017 8:05am GMT

Mohamad Faizul Zulkifli: APRX On Ubuntu Repository

Good news! i just noticed that aprx packages already listed on Ubuntu repository.

Aprx is a software package designed to run on any POSIX platform (Linux/BSD/Unix/etc.) and act as an APRS Digipeater and/or Internet Gateway. Aprx is able to support most APRS infrastructure deployments, including single stand-alone digipeaters, receive-only Internet gateways, full RF-gateways for bi-directional routing of traffic, and multi-port digipeaters operating on multiple channels or with multiple directional transceivers.

For more info visit:-

If you want to know more about aprs and ham radio visit:-

20 Sep 2017 8:01am GMT

The Fridge: Ubuntu Weekly Newsletter 519

Welcome to the Ubuntu Weekly Newsletter. This is issue #519 for the weeks of September 5 - 18, 2017, and the full version is available here.

In this issue we cover:

The issue of The Ubuntu Weekly Newsletter is brought to you by:

If you have a story idea for the Weekly Newsletter, join the Ubuntu News Team mailing list and submit it. Ideas can also be added to the wiki!

Except where otherwise noted, content in this issue is licensed under a Creative Commons Attribution 3.0 License BY SA Creative Commons License

20 Sep 2017 4:11am GMT

Kubuntu General News: Call for design: Artful Banner for Kubuntu.org website

Kubuntu 17.10 - code-named Artful Aardvark - will be released on October 19th, 2017. We need a new banner for the website, and invite artists and designers to submit designs to us based on the Plasma wallpaper and perhaps the mascot design.

The banner is 1500├Ś385 SVG.

Please submit designs to the Kubuntu-devel mail list.

20 Sep 2017 2:25am GMT

18 Sep 2017

feedPlanet Ubuntu

Kubuntu General News: Plasma 5.11 beta available in unofficial PPA for testing on Artful

Adventurous users and developers running the Artful development release can now also test the beta version of Plasma 5.11. This is experimental and can possibly kill kittens!

Bug reports on this beta go to https://bugs.kde.org, not to Launchpad.

The PPA comes with a WARNING: Artful will ship with Plasma 5.10.5, so please be prepared to use ppa-purge to revert changes. Plasma 5.11 will ship too late for inclusion in Kubuntu 17.10, but should be available via backports soon after release day, October 19th, 2017.

Read more about the beta release: https://www.kde.org/announcements/plasma-5.10.95.php

If you want to test on Artful: sudo add-apt-repository ppa:kubuntu-ppa/beta && sudo apt-get update && sudo apt full-upgrade -y

The purpose of this PPA is testing, and bug reports go to bugs.kde.org.

18 Sep 2017 11:12pm GMT