3 days to sends your talks to Linux App Summit 2020!

Head to https://linuxappsummit.org/cfp/ and talk about all those nice [Linux] Apps you're working on!

Call for paper ends in 3 days (September 15th)

Flathub stats for KDE applications [that are part of the release service]

I just discovered https://gitlab.gnome.org/Jehan/gimp-flathub-stats that tells you the download (including updates) stats for a given flathub application.

Ran it over the KDE applicatitions that are part of the release service that we have in flathub.

The results are somewhat surprising:

org.kde.kdenlive
Total:   22649 downloads in 8 days
org.kde.kalzium
Total:   16571 downloads in 9 days
org.kde.kgeography
Total:   16343 downloads in 9 days
org.kde.kbruch
Total:   15744 downloads in 9 days
org.kde.kapman
Total:   15473 downloads in 9 days
org.kde.kblocks
Total:   15426 downloads in 9 days
org.kde.katomic
Total:   15385 downloads in 9 days
org.kde.khangman
Total:   15370 downloads in 9 days
org.kde.kbounce
Total:   15280 downloads in 9 days
org.kde.kdiamond
Total:   15242 downloads in 9 days
org.kde.kwordquiz
Total:   15173 downloads in 9 days
org.kde.ksudoku
Total:   15155 downloads in 9 days
org.kde.kigo
Total:   15125 downloads in 9 days
org.kde.kgoldrunner
Total:   15062 downloads in 9 days
org.kde.knetwalk
Total:   15030 downloads in 9 days
org.kde.palapeli
Total:   14939 downloads in 9 days
org.kde.klickety
Total:   14917 downloads in 9 days
org.kde.klines
Total:   14866 downloads in 9 days
org.kde.knavalbattle
Total:   14848 downloads in 9 days
org.kde.kjumpingcube
Total:   14831 downloads in 9 days
org.kde.ksquares
Total:   14829 downloads in 9 days
org.kde.killbots
Total:   14772 downloads in 9 days
org.kde.kubrick
Total:   14696 downloads in 9 days
org.kde.ktuberling
Total:   14652 downloads in 9 days
org.kde.kontact
Total:   3728 downloads in 458 days
org.kde.kolourpaint
Total:   2542 downloads in 9 days
org.kde.okular
Total:   2304 downloads in 3 days
org.kde.kpat
Total:   1203 downloads in 8 days
org.kde.ktouch
Total:   880 downloads in 9 days
org.kde.kate
Total:   638 downloads in 9 days
org.kde.ark
Total:   571 downloads in 9 days
org.kde.dolphin
Total:   566 downloads in 3 days
org.kde.elisa
Total:   387 downloads in 3 days
org.kde.minuet
Total:   103 downloads in 9 days
org.kde.kwrite
Total:   84 downloads in 9 days
org.kde.kcachegrind
Total:   35 downloads in 9 days
org.kde.kcalc
Total:   23 downloads in 4 days
org.kde.lokalize
Total:   10 downloads in 3 days

kdenlive is the clear winner.

After that there's a compact block of games/edu apps that i think were/are part of the Endless default install and that shows, since after that the next app has like 6 times less downloads.

"New" (in the flathub sense) apps like lokalize or kcalc are the ones with less downloads, i guess people haven't seen them there yet.

Book your BoF for Akademy 2020 now!

BoF sessions are an integral part of Akademy, it's the "let's discuss and plan how to make things happen" oriented part after the more "this is what we've done" oriented part of the talks.

So go to https://community.kde.org/Akademy/2020/AllBoF and book a session to discuss with the rest of the community about something you're passionate! :)

20.08 releases branches created

Make sure you commit anything you want to end up in the 20.08 releases to them

We're already past the dependency freeze.

The Feature Freeze and Beta is this Thursday 16 of July.

More interesting dates
    July 30, 2020: 20.08 RC (20.07.90) Tagging and Release
  August  6, 2020: 20.08 Tagging
  August 13, 2020: 20.08 Release

https://community.kde.org/Schedules/release_service/20.08_Release_Schedule

Cheers,
  Albert

20.08 releases schedule finalized

It is available at the usual place https://community.kde.org/Schedules/release_service/20.08_Release_Schedule

Dependency freeze is in four weeks (July 9) and Feature Freeze a week after that, make sure you start finishing your stuff!

Racism is bad - a Barcelona centered reflection

I hope most of people reading this will not find "Racism is bad" to be controversial.

The problem is even if most (i'd hope to say all) of us think racism is bad, some of us are still consciously or unconsciously racist.

I am not going to speak about the Black Lives Matters movement, because it's mostly USA centered (which is kind of far for me) and there's much better people to listen than me, so go and listen to them.

In this case I'm going to speak about the Romani/Roma/gypsies in Barcelona (and from what i can see in this Pew Research article, most of Europe).

Institutionalized hate against them is so deep that definition 2 of 6 in the Catalan dictionary for the Romani word (gitano) is "those that act egoistically and try deceive others" and definition 5 of 8 in the Spanish dictionary is "those that with wits and lies try to cheat someone in a particular matter"

Here it is "common" to hear people say "don't be a gitano" meaning to say "don't cheat/play me" and nobody bats an eye when hearing that phrase.

It's a fact that this "community" tends to live in ghettos and has a higher percent crime ratio. I've heard people that probably think themselves as non racist say "that's just the lifestyle they like".

SARCASM: Sure, people love living in unsafe neighbourhoods and crappy houses and risking going to jail just to be able to eat.

The thing is when 50% of the population has an unfavourable view of you just because of who your parents are, or your surname is, it's hard to get a [nice] job, a place to live outside the ghetto, etc.

So please, in addition to saying that you're not a racist (which is a good first step), try to actually not be racist too.

Send your talks for Akademy 2020 *now*

The Call for Participation is still open for two weeks more, but please make us a favour and send yours *now*.

This way we don't have to panic thinking if we are going to need to go chasing people or not, or if we're going to have too few or too many proposals.

Also if you ask the talks committee for review, we can review your talk early, give you feedback and improve it, so it's a win-win.

So head over to https://akademy.kde.org/2020/cfp, find the submit link in the middle of that wall of text and click it ;)

chmk a simple CHM viewer

Okular can view CHM files, to do so it uses KHTML, makes sense CHM is basically HTML with images all compressed into a single file.

This is somewhat problematic since KHTML is largely unmaintained and i doubt it'll get a Qt6 port.

The problem is that the only other Qt based HTML rendering engine is QtWebEngine and while great it doesn't support stuff we would need to use it in Okular, since Okular needs to access to the rendered image of the page and also to the text since it uses the same API for all formats, be it CHM, PDF, epub, wathever.

The easiest plan to move forward is probably drop CHM from Okular, but that means no more chm viewing in KDE software, which would be a bit sad.

So I thought, ok maybe I can do a quick CHM viewer just based in QtWebEngine without trying to fit it into the Okular backend to support different formats.

And ChmK was born https://invent.kde.org/aacid/chmk.

It's still very simple, but the basics work, if you give it a file in the command line, it'll open it and you'll be able to browse it.



As you can see it doesn't have *any* UI yet, so Merge Requests more than welcome.

kwallet-pam >= 5.18.4 and ecryptfs homes

If you are using kwallet-pam to unlock your kwallet wallets *and* have a encryptfs home, the automatic unlocking probably stopped working for you with Plasma 5.18.4 and you are getting a "Wallet failed to get opened by PAM, error code is -9" in the system log.

Why?

kwallet-pam uses something called a salt file.

Before Plasma 5.18.4 the salt file was read (or created if not existing) in the "authenticate" step of pam. Now that happens on the "open_session" step of pam.

This is very important because on the open_session the encrypted home is already mounted while in the authenticate step it is not.

What that means is that before Plasma 5.18.4 there was a /home/youruser/.local/share/kwalletd/kdewallet.salt *outside* your encrypted home (that was created/read on the "authenticate" step).

Now with Plasma >= 5.18.4 the /home/youruser/.local/share/kwalletd/kdewallet.salt is created/read correctly inside your encrypted home like the rest of your files.

This is all nice for new users, but if you have an existing user, the kwallet auto unlocking will stop to work.

Why?

Because your wallet was salted with the file that was outside your encrypted home folder, now since kwallet-pam can no longer read that, it fails.

How to fix it?

* Reboot your system
* Login as root (or as a different user)
* See that there is a /home/youruser/.local/share/kwalletd/kdewallet.salt (FILE_A)
* Copy that file somewhere safe
* Now login as the youruser user
* If you have a /home/youruser/.local/share/kwalletd/kdewallet.salt copy it somewhere else safe too (you shouldn't need it but just in case)
* Copy the FILE_A you stashed somewhere safe to /home/youruser/.local/share/kwalletd/kdewallet.salt
* Reboot your system and now everything should work

Should KDE fork CHMLib?

CHMLib is a library to handle CHM files.

It is used by Okular and other applications to show those files.

It hasn't had a release in 11 years.

It is packaged by all major distributions.

A few weeks ago I got annoyed because we need to carry a patch in Okular flathub because the code is not great and it defines it's own int types.

I tried contacting the upstream author, but unsurprisingly after 11 years he doesn't seem to care much and got no answer.

Then i looked saw that various distributions carry different random set of patches, not great.

So I said, OK, maybe we should just fork it, and emailed 14 people listed at repology as package maintainers for CHMLib saying how they would react to KDE forking CHMLib in an effort to do some basic maintenance, i.e. get it to compile without need for patches, make sure all the patches different distributions has are in the same place, etc.

1 packager answered saying "great"
1 packager answered "nah we want to follow upstream" (... which part of upstream is dead did they not understand?)
1 person answered saying "i haven't been packaging for $DISTRO for ages" (makes sense given how old the package is)
1 person answered saying "not a maintainer anymore but i think you should not break API/ABI of CHMLib" (which makes sense, never said that was planned)

And that's it, so only 4 out of 14 answers and only one of them encouraging.

So I'm asking *YOU*, should we push for a fork or I should stop this crazyness and do something more productive?

RSIBreak 0.12.12 released!

All of you that are in using a computer for a long time should use it!

https://userbase.kde.org/RSIBreak

Changes from 0.12.11:
* Don't reset pause counter on very short inputs that can just be accidental.
* Improve high dpi support
* Translation improvements
* Compile with Qt 5.15 beta
* Minor code cleanup

http://download.kde.org/stable/rsibreak/0.12/rsibreak-0.12.12.tar.xz

20.04 releases branches created

Make sure you commit anything you want to end up in the 20.04 releases to them

We're already past the dependency freeze.

The Feature Freeze and Beta is this Thursday 19 of March.

More interesting dates
April 2: 20.04 RC (20.03.90) Tagging and Release
April 16: 20.04 Tagging
April 23: 20.04 Release

https://community.kde.org/Schedules/Applications/20.04_Release_Schedule

20.04 releases dependency freeze this thursday

Next interesting dates:

March 12: 20.04 Dependency Freeze

March 19: 20.04 Freeze and Beta (20.03.80) tag & release

Working with different remotes in git

One of the things that is typical when working with gitlab/github is work with different git remotes.

This is sometimes because you don't have commit access to the original repository so you fork it into your own repository and work over there, but you still want to have the original repository around so you can rebase your changes over it.

In this blog we will see how to do that with the okular repository.

First off, we start by cloning the original repository

Since we don't know the URL by memory, we go to https://invent.kde.org/kde/okular/ and press the Clone button to get a hint, if we have commit access we can use both urls, otherwise we have to use the https one, for the sake of this let's assume we do not have commit access.


$ git clone https://invent.kde.org/kde/okular.git
$ cd okular


Ok, at this point we have clone the upstream Okular repository, we can see we only have one remote, called origin


$ git remote -v
origin https://invent.kde.org/kde/okular.git (fetch)
origin https://invent.kde.org/kde/okular.git (push)


Now we want to do some fixes, since we can't commit into the main repository, we need to fork, for that we press the fork button in https://invent.kde.org/kde/okular/. Once done we end up in the fork of Okular under our name, e.g. https://invent.kde.org/aacid/okular.

Now what we want is to add our remote to the existing one, so we press the blue button (here we use the git@ one since we can always commit to our fork)


$ git remote add aacid_fork git@invent.kde.org:aacid/okular.git
$ git remote -v
aacid_fork git@invent.kde.org:aacid/okular.git (fetch)
aacid_fork git@invent.kde.org:aacid/okular.git (push)
origin https://invent.kde.org/kde/okular.git (fetch)
origin https://invent.kde.org/kde/okular.git (push)


So now we have a remote called aacid_fork that points to url fork, aacid_fork is the name i chose because it's easy to remember, but we could have used any name we wanted there.

Now there's several things one may want to do

Do changes in master and push them to your fork

This is really not the recommended way but since it's what i do and it'll explain how to push from one branch name to another i'll explain it.

After doing the changes and doing the typical git commit now we have to push the changes to our aacid_fork, so we do

git push aacid_fork master:adding_since_to_function

What this does is push the local branch master to the branch named adding_since_to_function of the aacid_fork remote

Create a branch and then push that to your fork

This is what you should be doing, so what you should do is

git branch adding_since_to_function

and then change to work on that branch

git switch adding_since_to_function

After doing the changes and doing the typical git commit now we have to push the changes to our aacid_fork, so we do

git push aacid_fork adding_since_to_function

What this does is push the local branch adding_since_to_function to a branch with the same name of the aacid_fork

Get a branch from someone else's remote and push to it

Sometimes some people say "hey let's work on my branch together", so you need to push not to origin, not to your fork but to someone else's fork.

Let's say you want to work on joliveira's gsoc2019_numberFormat branch, so you would need to add his remote


$ git remote add joliveira_fork git@invent.kde.org:joliveira/okular.git
$ git remote -v
aacid_fork git@invent.kde.org:aacid/okular.git (fetch)
aacid_fork git@invent.kde.org:aacid/okular.git (push)
joliveira_fork git@invent.kde.org:joliveira/okular.git (fetch)
joliveira_fork git@invent.kde.org:joliveira/okular.git (push)
origin https://invent.kde.org/kde/okular.git (fetch)
origin https://invent.kde.org/kde/okular.git (push)


Then we would need to tell git, hey listen, please go and read the branches that remote i just added has

git fetch joliveira_fork

Next we have to tell git to actually give us the gsoc2019_numberFormat branch, there's lots of ways to do that, one that works is

git checkout --track joliveira_fork/gsoc2019_numberFormat

This will create a local gsoc2019_numberFormat from the contents of the remote branch joliveira_fork/gsoc2019_numberFormat and that also "tracks" it, that means that if someone else does changes to it and you do git pull --rebase while on your local gsoc2019_numberFormat, you'll get them.

After doing the changes and doing the typical git commit now we have to push the changes to the joliveira_fork, so we do

git push joliveira_fork gsoc2019_numberFormat

What you don't want to do

Don't push to the master branch of your remote, it's weird, some people do, but it's note really recommended.

Things to remember

A git remote is another repository, it just so happens that it has "similar" code, but it's a fork, so you can push to it, checkout branches from it, etc.

Every time you want to get changes from a remote, remember to git fetch remote_name otherwise you're still on the "old" snapshot form your last fetch.

When git pushing the syntax is git push remote_name local_branch_name:remote_branch_name

Bonus track: Using git mr

As shown in my previous blog post you can use git mr to easy download the code of a mr. Let's use as example Okular's MR #20 https://invent.kde.org/kde/okular/merge_requests/20.

You can simply do git mr 20 and it will create a local branch named mr/20 with the contents of that MR. Unfortunately, if you want to commit changes to it, you still need to use the original remote and branch name name, so if you do some changes, after the git commit you should do

git push joliveira_fork mr/20:gsoc2019_percentFormat

20.04 releases schedule finalized

It is available at the usual place https://community.kde.org/Schedules/release_service/20.04_Release_Schedule

Dependency freeze is in ~five weeks (March12) and Feature Freeze a week after that, make sure you start finishing your stuff!

New help porting to Go >= 1.12

At KDE we have a GitHub mirror. One of the problems about having a mirror is that people routinely try to propose Pull Requests over there, but no one is watching, so they would go stale, which is not good for anyone.

What no one? Actually no, we have kdeclose, a bot that will go over all Pull Requests and gracefully close them suggesting people to move the patch over to KDE infrastructure where we are watching.

The problem is that I'm running that code on Google AppEngine and they are cutting support for the old Go version that it's using, so I would need someone help me port the code to a newer Go version.

Anyone can help me?

P.S: No, I'm not the original author of the code, it's a fork of something else, but that has not been updated either.

Update: This is now done, thanks to Daniele (see first comment). Mega fast, thanks community!

QCA cleanup spree

The last few weeks I've done quite a bit of QCA cleanup.

Bit of a summary:
* Moved to KDE's gitlab and enable clazy and clang-tidy continuous integration checks
* Fixed lots of crashes when copying some of the classes, it's not a normal use case, but it's supported by the API so make it work :)
* Fixed lots of crashes because we were assuming some of the backend libraries had more features than they actually do (e.g. we thought botan would support always support a given crypto algorithm, but some versions don't, now we check if the algorithm it's supported before saying it is)
* Made all the tests succeed :)
* Dropped Qt4 support
* Use override, nullptr (Laurent), various of the "sanity" QT_* defines, etc.
* botan backend now requires botan2
* Fixed most of the compile warnings

What I probably also did is maybe break the OSX and Windows builds, so if you're using QCA there you should start testing it and propose Merge Requests.

Note: My original idea was to actually kill QCA because i started looking at it and lot of the code looked a bit fishy, and no one wants crypto fishy code, but then i realized we use it in too many places in KDE and i'd rather have "fishy crypto code" in one place than in lots of different places, at least this way it's easier to eventually fix it.

The Qt Company is stopping Qt LTS releases. We (KDE) are going to be fine :)

Obvious disclaimer, this is my opinion, not KDE's, not my employer's, not my parents', only mine ;)

Big news today is that Qt Long-term-supported (LTS) releases and the offline installer will become available to commercial licensees only.

Ignoring upcoming switch to Qt6 scenario for now, how bad is that for us?

Let's look at some numbers from our friends at repology.

At this point we have 2 Qt LTS going on, Qt 5.9 (5.9.9 since December) and Qt 5.12 (5.12.6 since November).

How many distros ship Qt 5.9.9? 0. (there's macports and slackbuilds but none of those seem to provide Plasma packages, so I'm ignoring them)

How many distros ship Qt 5.12.6? 5, Adélie Linux, Fedora 30, Mageia 7, OpenSuse Leap 15.2, PCLinux OS (ALT Linux and GNU Guix also do but they don't seem to ship Plasma). Those are some bigger names (I'd say specially Fedora and OpenSuse).

On the other hand Fedora 28 and 29 ship some 5.12.x version but have not updated to 5.12.6, Opensuse Leap 15.1 has a similar issue, it's stuck on 5.9.7 and did not update to 5.9.9 and so is Mageia 6 which is stuck on Qt 5.9.4

Ubuntu 19.04, 19.08 and 20.04 all ship some version of Qt 5.12 (LTS) but not the lastest version.

On the other a few of other "big" distros don't ship Qt LTS, Arch and Gentoo ship 5.14, our not-distro-distro Neon is on 5.13 and so is flatpak.

As I see it, the numbers say that while it's true that some distros are shipping the latest LTS release, it's not all of them by far, and it looks more like an opportunistic use, the LTS branch is followed for a while in the last release of the distro, but the previous ones get abandoned at some point, so the LTS doesn't really seem to be used to its fully potential.

What would happen if there was no Qt LTS?

Hard to say, but I think some of the "newer" distros would actually be shipping Qt 5.13 or 5.14, and in my book that's a good thing, moving users forward is always good.

The "already released" distros is different story, since they would obviously not be updating from Qt 5.9 to 5.14, but as we've seen it seems that most of the times they don't really follow the Qt LTS releases to its full extent either.

So all in all, I'm going to say not having Qt LTS releases is not that bad for KDE, we've lived for that for a long time (remember there has only been 4 Qt LTS, 4.8, 5.6, 5.9 and 5.12) so we'll do mostly fine.

But What about Qt 5.15 and Qt 6 you ask!

Yes, this may actually be a problem, if all goes to plan Qt 5.15 will be released in May and Qt 6.0 in November, that means we will likely get up to Qt 5.15.2 or 5.15.3 and then that's it, we're moving to Qt 6.0

Obviously KDE will have to move to Qt 6 at some point, but that's going to take a while (as example Plasma 5 was released when Qt was at 5.3) so for let's say that for a year or two we will still be using Qt 5.15 without any bugfix releases.

That can be OK if Qt 5.15 ends being a good release or a problem if it's a bit buggy. If it's buggy, well then we'll have to figure out what to do, and it'll probably involve some kind of fork somewhere, be it by KDE (qt already had that for a while in ancient history with qt-copy) or by some other trusted source, but let's hope it doesn't get to that, since it would mean that there's two set of people fixing bugs in Qt 5.15, The Qt Company engineers and the rest of the world, and doing the same work twice is not smart.

git mr: easily downloading gitlab merge requests

With KDE [slowly] moving to gitlab you may probably find yourselves reviewing more gitlab based patches.

In my opinion the web UI in gitlab is miles better, the fact that it has a "merge this thing" button makes it a game changer.

Now since we are coming from phabricator you have probably used the arc patch DXXX command to download and locally test a patch.

The gitlab web UI has a a link named "You can merge this merge request manually using the command line" that if pressed tells you to


git fetch "git@invent.kde.org:sander/okular.git" "patch-from-kde-bug-415012"
git checkout -b "sander/okular-patch-from-kde-bug-415012" FETCH_HEAD


if you want to locally test https://invent.kde.org/kde/okular/merge_requests/80

That is *horrible*

Enter git mr a very simple script that makes it so that you only have to type


git mr 80




P.S: If you're an archlinux user you can get it from AUR https://aur.archlinux.org/packages/git-mr

P.P.S: Unfortunately it does not support pushing, so if you want to push to that mr you'll have to do some work.

KPatience added to flathub. Which app should be next?

This week we added KPatience to flathub.

That makes for a quite a few applications from KDE already in flathub



Which one do you think we should add next?