Postings by Aleix Pol

Kamoso in KDE Applications

I'd like to move it there. It's in extragear/multimedia now and I keep
forgetting to release as often as I should.

But the application is working, maintained and developed.


Making Purpose part of KF5

I would like to include Purpose [1] into the frameworks umbrella.
It's been around for a while now, used by few applications and
reasonably stable.

Any thoughts?


[1] <a href="" title=""></a>

Flatpak Qt/KDE runtime

Recently flathub started building our runtime into their systems. I
recommend using the runtimes there. I updated the wiki to reflect the
<a href="" title=""></a>

You will possibly have to remove and add again the runtime, but other
than that everything should work as usual.


Flatpak KDE Nightlies

Just configured to have the server issue a new daily build (at 3am
UTC, if I cron'ed correctly). Shouldn't be a big strain on the server
and will be more useful to developers who are trying to make sure that
their application works.

Logs can be found here:
<a href="" title=""></a>


Snapping KDE

Hey Kubuntu,
At some point we should have the discussion regarding KDE Software
snaps. Who is going to create them and what's the adoption path. I
understand that the ultimate plan for Kubuntu would be able to build a
Plasma system on top of Ubuntu Core based on snaps.

Is this something you guys are looking into?
Is it something that you find desirable?


Something happened in Discover 5.6.2

In the recent days I've received a number of bug reports for Discover 5.6.2:
<a href="" title=""></a>

Could somebody take a look and see what's happening? It's especially
odd as it's the LTS version so we could expect these to keep coming


libdiscover/backends/PackageKitBackend: Expose software-properties-kde if present

Git commit 3e7dd188f9d0e452bdcba583ac46ef992a918e01 by Aleix Pol.
Committed on 22/11/2016 at 15:15.
Pushed by apol into branch 'Plasma/5.8'.

Expose software-properties-kde if present

As requested by santa, expose an action for software-properties-kde into
Discover so that kubuntu users can access this system-specific tool to
manage their repositories.
This opens the possibility for other platforms to offer their tooling there
as well.

CCMAIL: <a href="mailto:kubuntu- ... at lists dot">kubuntu- ... at lists dot</a>

M +4 -0 libdiscover/backends/PackageKitBackend/CMakeLists.txt
M +27 -0 libdiscover/backends/PackageKitBac

Can't release applications

There's a major blocker when trying to release applications nowadays.
To update the stable branch one needs to commit to the
kde:sysadmin/repo-metadata.git repository, which can't be accessed by
KDE Project maintainers.

How can we solve this?


Configuring a prefix

One of the weirdest tasks for newcomers is probably the setting up of
a new prefix. It requires setting quite some environment variables
that are often not trivial and it's always a really boring task.

At some point, out of such frustration, I created this little cmake
project that creates a file that can be "sourced" easily.

If anyone thinks it's useful, please use it. If changes are needed,
let's change it.
<a href="" title=""></a>

Happy hacking!

Review Request 126680: Rename muon-discover to plasma-discover

Review request for Kubuntu, Muon Package Management Suite and Matthias Klumpp.

Repository: discover

Renames everything as discussed in the mail thread.

This also renames `muon-updater` to `plasma-discover-updater`.

/: Use AppStream instead of appinstall-data in the QApt backend

Git commit 97f1426d5806beae0456566e1cf6653341d64afa by Aleix Pol.
Committed on 05/01/2016 at 15:08.
Pushed by apol into branch 'master'.

Use AppStream instead of appinstall-data in the QApt backend

It was deprecated and only available on Ubuntu.

kdesrc-build and include-dependencies

I've been testing kde-src-builder on a bare system (actually a docker
image) and I realized that --include-dependencies isn't doing what I
expected [1], which is to actually build and install the repository's

Can anybody point me out what am I missing?

Policy regarding QtWebKit and QtScript

Soon Qt 5.6 will be released and with it, 2 quite widely used
frameworks will disappear: QtWebKit and QtScript. Also QtQuick 1, but
I think this is much less of a problem.

I'd say we need a plan to figure out what to do with these
dependencies. I don't think assuming that they will stay around is
very wise, so I'd suggest to come up collectively or specifically on
each project how to deal with those.

I'd say it's especially pressing on KDE Frameworks where Qt5::Script
is still quite widely used (kio, ki18n, ktexteditor,


AppStream, Discover and metadata

Hi Kubuntu (and Debian KDE, that also applies there),
If you were at Akademy in Brno you might remember a guy blabbing on
about how important it was to adopt AppStream. That was me.

Now we have AppStream on Ubuntu, so I've been asking myself what's the
correct path to take. It's not entirely trivial to go forward, so I'd
like to know your opinion.

- Kubuntu 15.10 has Plasma 5.4.

Each toolchain with their file

Here's a packaging match for KConfig: <a href="" title=""></a>

The idea is that, when cross-compiling, together with
kconfig_compiler_kf5, we need to install the cmake file that points to
it. Otherwise we end up with a file that points to the armhf (or any
target platform) and then a poor kconfig_compiler_kf5 file that cannot
be found.

Rohan says that the patch makes sense. :D


Kubuntu & openQA

Hi Kubuntu people at Akademy,
I'd recommend you to get by the Suse booth and ask Douglas about
openQA. I think it's a really cool technology and maybe it could be
used for neon and even stable releases.


Kubuntu upgrade available glitch

Somebody reported this, could somebody take a look and maybe confirm?
<a href="" title=""></a>


Help testing muon package manager

I just went through a refactoring session in Muon. Everything should
be the same, but sometimes shit happens.

I would really appreciate it if somebody could give me a hand by
checking that everything works as it used on his system.


apt-listbugs usage in Kubuntu

I was looking into some functionality and just realized kubuntu
doesn't provide an apt-listbugs executable, that was introduced for
better integration with Debian.

Anybody here knows what's the status on it?
I'll change some code so it's still possible to use without
apt-listbugs for now, but I wonder if it should become a dependency on
Kubuntu as well.


Minimum password length

Yesterday I was creating a new user for my Kubuntu system, apparently
anything under 9 characters is too few. Anybody knows why?

<a href="" title=""></a>


KPeople part of KDE Frameworks

I would like to submit KPeople for review process so it can join the
KF5 family in the next 5.8 release.

KPeople is a tier 3 framework (because of KService, which will be
dropped eventually, without breaking ABI) and it offers cross-source
contact aggregation. More information about it can be read on the

Your reviews will be welcome.


[1] <a href="" title=""></a>

Regarding building QML modules

I received this bug report [1], I guess this should be figured out. It
suggests using add_library(MODULE) instead of add_library(SHARED) for
QML modules, as they are not meant to be linked to.

I think it makes sense, I would have done it like that since the
beginning if it wasn't because Qt requires a lib* prefix to the QML
plugins (only on linux?).

Any feedback will be welcome. Thanks!!


[1] <a href="" title=""></a>

/: Remove muon-installer

Git commit 5326151f7ef09aa356ea09089cc7816f98d06583 by Aleix Pol.
Committed on 14/01/2015 at 17:30.
Pushed by apol into branch 'master'.

Remove muon-installer

Muon Discover does the same things and it's more actively maintained.
It wasn't ported to KF5.
It was still muonapt-dependent.
It has a bunch of bugs nobody really knows how to fix.

CCMAIL: <a href="mailto:kubuntu- ... at lists dot">kubuntu- ... at lists dot</a>

M +0 -1 CMakeLists.txt
M +0 -1
D +0 -53 installer/AbstractViewBase.cpp
D +0 -50 installer/AbstractViewBase.h
D +0 -98 installer/AbstractView

libmuon/backends/ApplicationBackend/tests: Introduce a new test within the SourcesTest for APT

Git commit 88433b3fd9ad816f1ac05d6f5205cc03165eac84 by Aleix Pol.
Committed on 14/01/2015 at 04:04.
Pushed by apol into branch 'master'.

Introduce a new test within the SourcesTest for APT

Tries to ensure that the origins of the packages maps to one of the offered
Problem is, it doesn't work well, many packages provide an empty origin "".
CC'ing kubuntu-devel, hoping they will know how to fix this.

CCMAIL: <a href="mailto:kubuntu- ... at lists dot">kubuntu- ... at lists dot</a>

M +34 -5 libmuon/backends/ApplicationBackend/tests/SourcesTest.cpp
M +4 -0 libmuon/backends/ApplicationBackend/tests/SourcesTest.h


Review Request 122023: Expose the site apt property in QApt::Package::site()

Review request for Kubuntu, Michael Stemle and Harald Sitter.

Repository: libqapt

This exposes public API in apt, to QApt.

kdepimlibs splitting done

I have performed the first round of kdepimlibs splitting tonight, as we agreed.
Below you can see the for reference how the splitting was performed.

Dan, Laurent, can you give me the ok?