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 ;)
Thursday, May 28, 2020
Monday, May 25, 2020
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.
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.
Sunday, May 03, 2020
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
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
Friday, April 17, 2020
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?
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?
Sunday, March 29, 2020
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
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
Sunday, March 15, 2020
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
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
Monday, March 09, 2020
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
March 12: 20.04 Dependency Freeze
March 19: 20.04 Freeze and Beta (20.03.80) tag & release
Monday, February 10, 2020
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.
Ok, at this point we have clone the upstream Okular repository, we can see we only have one remote, called origin
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)
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
After doing the changes and doing the typical
What this does is push the local branch master to the branch named adding_since_to_function of the aacid_fork remote
and then change to work on that branch
After doing the changes and doing the typical
What this does is push the local branch adding_since_to_function to a branch with the same name of the aacid_fork
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
Then we would need to tell git, hey listen, please go and read the branches that remote i just added has
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
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
After doing the changes and doing the typical
Every time you want to get changes from a remote, remember to
When git pushing the syntax is
You can simply do
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_functionWhat 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 isgit branch adding_since_to_functionand then change to work on that branch
git switch adding_since_to_functionAfter doing the changes and doing the typical
git commit now we have to push the changes to our aacid_fork, so we dogit push aacid_fork adding_since_to_functionWhat 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_forkNext 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_numberFormatThis 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 dogit push joliveira_fork gsoc2019_numberFormatWhat 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_nameBonus 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 dogit push joliveira_fork mr/20:gsoc2019_percentFormat
Sunday, February 09, 2020
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!
Dependency freeze is in ~five weeks (March12) and Feature Freeze a week after that, make sure you start finishing your stuff!
Thursday, February 06, 2020
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!
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!
Sunday, February 02, 2020
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.
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.
Tuesday, January 28, 2020
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.
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.
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.
Sunday, January 26, 2020
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
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
if you want to locally test https://invent.kde.org/kde/okular/merge_requests/80
That is *horrible*
Enter
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.
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.
Thursday, January 16, 2020
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?
That makes for a quite a few applications from KDE already in flathub
Which one do you think we should add next?
Sunday, November 10, 2019
19.12 releases branches created
The branch naming has changed to try to accommodate for the stopping of the "KDE Applications" brand, it's now called
release/19.12
Make sure you commit anything you want to end up in the 19.12 releases to them
We're already past the dependency freeze.
The Freeze and Beta is this Thursday 14 of November.
More interesting dates
November 28, 2019: KDE Applications 19.12 RC (19.11.90) Tagging and Release
December 5, 2019: KDE Applications 19.12 Tagging
December 12, 2019: KDE Applications 19.12 Release
https://community.kde.org/Schedules/Applications/19.12_Release_Schedule
Cheers,
Albert
P.S: Yes, this release unfortunately falls in the middle of the debranding of "KDE Applications" and there's still a few things called "KDE Applications" here and there
[*] There's a small issue with kwave we're working on figuring it out
release/19.12
Make sure you commit anything you want to end up in the 19.12 releases to them
We're already past the dependency freeze.
The Freeze and Beta is this Thursday 14 of November.
More interesting dates
November 28, 2019: KDE Applications 19.12 RC (19.11.90) Tagging and Release
December 5, 2019: KDE Applications 19.12 Tagging
December 12, 2019: KDE Applications 19.12 Release
https://community.kde.org/Schedules/Applications/19.12_Release_Schedule
Cheers,
Albert
P.S: Yes, this release unfortunately falls in the middle of the debranding of "KDE Applications" and there's still a few things called "KDE Applications" here and there
[*] There's a small issue with kwave we're working on figuring it out
Thursday, November 07, 2019
You can use a C++11 range for loop over a static array
void DeviceListing::populateListing(const show showStatus)
{
const Solid::DeviceInterface::Type needHardware[] = {
Solid::DeviceInterface::Processor,
Solid::DeviceInterface::StorageDrive,
Solid::DeviceInterface::Battery,
Solid::DeviceInterface::PortableMediaPlayer,
Solid::DeviceInterface::Camera
};
clear();
for (unsigned int i = 0; i < (sizeof(needHardware)/sizeof(Solid::DeviceInterface::Type)); i++) {
QTreeWidgetItem *tmpDevice = createListItems(needHardware[i]);
deviceMap[needHardware[i]] = static_cast(tmpDevice);
if ((tmpDevice->childCount() > 0) || (showStatus == ALL)) {
addTopLevelItem(tmpDevice);
}
}
}
in C++11 you can rewrite it in the much easier to read
void DeviceListing::populateListing(const show showStatus)
{
const Solid::DeviceInterface::Type needHardware[] = {
Solid::DeviceInterface::Processor,
Solid::DeviceInterface::StorageDrive,
Solid::DeviceInterface::Battery,
Solid::DeviceInterface::PortableMediaPlayer,
Solid::DeviceInterface::Camera
};
clear();
for (const Solid::DeviceInterface::Type nh : needHardware) {
QTreeWidgetItem *tmpDevice = createListItems(nh);
deviceMap[nh] = static_cast(tmpDevice);
if ((tmpDevice->childCount() > 0) || (showStatus == ALL)) {
addTopLevelItem(tmpDevice);
}
}
}
Wednesday, October 30, 2019
Akademy Guest Post: Some thoughts regarding discussion culture
First of all I want to say thanks for hosting me on your blog and letting me write this guest post!
I am Florian Müller from Germany, working as a Sysadmin at a small tech collective. I have been a KDE user for years, but I am quite new to the KDE community. This years Akademy was my first and I am looking forward to dive in deeper and contribute more to KDE.
I had a really good time at Akademy in Milano, got to know so many cool people and learned a lot about the KDE community and KDE in general. Thanks a lot to everyone organizing this unique event! I am sure it won't be the last time I'll attend Akademy.
I want to share some things I noticed about discussion culture, please feel free to criticize/discuss/comment, so maybe we can work out some guidelines for that in the future.
First of all some words about discussion culture in general. Because all people are different, we need technics to allow everyone to participate in group discussions. When people are not that confident in general, they tend to not raise their voices in bigger groups, also if they have opponent opinions to the main stream. So in order to have a greater culmination of creativity and ideas, we need to create an atmosphere to make it easier for everyone to participate.
One thing would be the setup of the room the discussion will be held in. Do you want to have a central speaker in the front leading the discussion or do you want to setup the chairs and tables in a circle so everyone is on the same level. Sometimes there are mostly lecture halls available, so time to plan in advance and ask for a different room has to be taken in accountance. The advantage of a circle is that everybody is able to see everyone else. We can also think about forming smaller discussion groups when possible and a topic can be split up into smaller parts.
Another point you can think about is how you organize the turn keeping. One could appoint a person who only deals with turn keeping. We could alternate the job of turn keeping from one discussion to the next. At the beginning of the discussion we should make it transparent on how turn keeping will work. For example we could have a rule that people who want to say something the first time, move to the top of the speakers list to make sure that rare voices will be heard. We could also have a speakers list alternated by gender. There could be a maximum time for speakers so that single people don’t dominate the whole discussion by simply talking others out.
There are many other aspect we can think about when we want to make group discussions more inclusive. With this post, I just wanted to get the discussion started, so we can improve on that in the future.
Here are some links to continue reading:
https://www.workingdigital.de/en/blog/post/respectful-culture-of-discussion
https://www.wikihow.com/Be-Good-at-Group-Discussion
You can reach me directly at mail@flo-mue.de.
I am Florian Müller from Germany, working as a Sysadmin at a small tech collective. I have been a KDE user for years, but I am quite new to the KDE community. This years Akademy was my first and I am looking forward to dive in deeper and contribute more to KDE.
I had a really good time at Akademy in Milano, got to know so many cool people and learned a lot about the KDE community and KDE in general. Thanks a lot to everyone organizing this unique event! I am sure it won't be the last time I'll attend Akademy.
I want to share some things I noticed about discussion culture, please feel free to criticize/discuss/comment, so maybe we can work out some guidelines for that in the future.
First of all some words about discussion culture in general. Because all people are different, we need technics to allow everyone to participate in group discussions. When people are not that confident in general, they tend to not raise their voices in bigger groups, also if they have opponent opinions to the main stream. So in order to have a greater culmination of creativity and ideas, we need to create an atmosphere to make it easier for everyone to participate.
One thing would be the setup of the room the discussion will be held in. Do you want to have a central speaker in the front leading the discussion or do you want to setup the chairs and tables in a circle so everyone is on the same level. Sometimes there are mostly lecture halls available, so time to plan in advance and ask for a different room has to be taken in accountance. The advantage of a circle is that everybody is able to see everyone else. We can also think about forming smaller discussion groups when possible and a topic can be split up into smaller parts.
Another point you can think about is how you organize the turn keeping. One could appoint a person who only deals with turn keeping. We could alternate the job of turn keeping from one discussion to the next. At the beginning of the discussion we should make it transparent on how turn keeping will work. For example we could have a rule that people who want to say something the first time, move to the top of the speakers list to make sure that rare voices will be heard. We could also have a speakers list alternated by gender. There could be a maximum time for speakers so that single people don’t dominate the whole discussion by simply talking others out.
There are many other aspect we can think about when we want to make group discussions more inclusive. With this post, I just wanted to get the discussion started, so we can improve on that in the future.
Here are some links to continue reading:
https://www.workingdigital.de/en/blog/post/respectful-culture-of-discussion
https://www.wikihow.com/Be-Good-at-Group-Discussion
You can reach me directly at mail@flo-mue.de.
Tuesday, October 08, 2019
Linux App Summit 2019 schedule is out!
We published the Linux App Summit 2019 schedule last week.
We have a bunch of interesting talks (sadly we had to leave almost 40 almost as interesting talks out, we had lots of awesome submissions!) ranging from flatpak and snaps to how product management is good for Free Software projects with some thought provoking talks thrown in to make us think what's the future of our platform.
I am going and you should totally come too!
The attendance is free but please register at https://events.linuxappsummit.org/
We have a bunch of interesting talks (sadly we had to leave almost 40 almost as interesting talks out, we had lots of awesome submissions!) ranging from flatpak and snaps to how product management is good for Free Software projects with some thought provoking talks thrown in to make us think what's the future of our platform.
I am going and you should totally come too!
The attendance is free but please register at https://events.linuxappsummit.org/
Wednesday, October 02, 2019
2 years since Catalan Independence Referendum, an update
Note 1: This is not KDE or Free Software related, if you're not interested, stop reading, no one is forcing you to read
Note 2: Yes, this is still going to Planet KDE, KDE friends and colleagues ask me about it almost every time we met, so there's definitely interest
Note 3: You're more than welcome to comment, but remember this blog is my house, so don't complain when i don't tolerate stuff i wouldn't tolerate at my home
You may remember Catalonia held an Independence referendum 2 years ago, lots of things have happened since then, I'm going to try to summarize, if you're interested in my initial reaction read my blog from that very same day.
On October 27 2017, following the referendum results, the Parliament of Catalonia declared Independence by a majority of 70 out of 135 MPs. That was mostly ignored by every single country in the world. A few hours later the Spanish government used bigger-army-diplomacy (AKA article 155 of Spanish Constitution) to decide that the Parliament of Catalonia would be suspended and new elections would happen in Catalonia on December 21.
On November 2nd 2017, a judge put most of the Catalan government in jail with the charges of "you've been terribly bad".
They still remain in jail awaiting for trial results (trial finished a few months ago).
Notable exceptions of government officials not in jail are president Carles Puigdemont and Ministers Clara Ponsatà and Toni ComÃn, that exiled themselves to other European countries. Spain has tried several times to get European countries to extradite them to Spain because "they've been terribly bad", but that has failed every single time, so they ended up revoking the extradition requests.
Elections happened on December 21 2017, and to shocking surprise of no one, almost virtually the same results happened if you count the pro-independence vs anti-independence blocks.
Since then the Catalan pro-independence government has been basically very low-key in their actions.
Meanwhile, Spain had a its own elections in April this year. They did this nice thing of letting the jailed (but still not sentenced to anything, so innocent) Catalan politicians run, and several of them won Congress seats. Then they said "oh but you know, you're a very dangerous person, so we're not going to let you attend Congress sessions". Not that it matters now, since Spain is unable to govern itself and is having it's 4th election in 4 years this November.
We also had elections in the European Union, and you know what? The same happened! They let catalan-jailed politicians run but then they decided they would not let them take the seats. Actually, this time is even worse since Carles Puigdemont and Toni ComÃn, that are living in Brussels without any extradition petition (i.e. they're basically free citizens of Europe), have also been rejected from taking their seats for some esoteric reason.
As a "fun fact", in late 2018 some Spanish regions had elections. Andalucia was one of them and the current government is a coalition of PP+C+VOX, i.e. right wing conservatives, right wing liberals and ultra right wing nut-jobs. One of their first decisions was to put away 100000 euros for grants to teach Spanish to Spanish born people (not for helping immigrants, they're right wing crazies after all) living in Catalonia that don't know how speak Spanish. I'm 99.99% sure the number of people that matches that description is very close to 0 people. You heard well, the poorest region of Spain decided to subsidize the 4th richest region for something that is virtually useless. Thanks!
Much less "fun fact", last week Monday, the Spanish police decided to detain 9 pro-independence people (later to be 7 since 2 were let go) with terrorism charges. The investigation is on-going and technically it should be secret, but we've seen pictures all over the news of what the cops say to be material to make bombs, and all i can see is a pressure cooking pot and some fireworks used typically for Ball de diables.
I don't want to 100% rule out this people having actual plans to do something nasty, but Spanish police/judges/state history of just fabricating charges against people they don't like is so long (An anarchist recently spent *18* months in jail awaiting trial for tweeting stuff "Goku lives, the fight continues" to be then just found innocent after trial) that i would not be surprised either if this is just Spain doing bigger-army-diplomacy again.
TL;DR: Everything is fucked up and I can't really see a way out at this point.
Note 2: Yes, this is still going to Planet KDE, KDE friends and colleagues ask me about it almost every time we met, so there's definitely interest
Note 3: You're more than welcome to comment, but remember this blog is my house, so don't complain when i don't tolerate stuff i wouldn't tolerate at my home
You may remember Catalonia held an Independence referendum 2 years ago, lots of things have happened since then, I'm going to try to summarize, if you're interested in my initial reaction read my blog from that very same day.
On October 27 2017, following the referendum results, the Parliament of Catalonia declared Independence by a majority of 70 out of 135 MPs. That was mostly ignored by every single country in the world. A few hours later the Spanish government used bigger-army-diplomacy (AKA article 155 of Spanish Constitution) to decide that the Parliament of Catalonia would be suspended and new elections would happen in Catalonia on December 21.
On November 2nd 2017, a judge put most of the Catalan government in jail with the charges of "you've been terribly bad".
They still remain in jail awaiting for trial results (trial finished a few months ago).
Notable exceptions of government officials not in jail are president Carles Puigdemont and Ministers Clara Ponsatà and Toni ComÃn, that exiled themselves to other European countries. Spain has tried several times to get European countries to extradite them to Spain because "they've been terribly bad", but that has failed every single time, so they ended up revoking the extradition requests.
Elections happened on December 21 2017, and to shocking surprise of no one, almost virtually the same results happened if you count the pro-independence vs anti-independence blocks.
Since then the Catalan pro-independence government has been basically very low-key in their actions.
Meanwhile, Spain had a its own elections in April this year. They did this nice thing of letting the jailed (but still not sentenced to anything, so innocent) Catalan politicians run, and several of them won Congress seats. Then they said "oh but you know, you're a very dangerous person, so we're not going to let you attend Congress sessions". Not that it matters now, since Spain is unable to govern itself and is having it's 4th election in 4 years this November.
We also had elections in the European Union, and you know what? The same happened! They let catalan-jailed politicians run but then they decided they would not let them take the seats. Actually, this time is even worse since Carles Puigdemont and Toni ComÃn, that are living in Brussels without any extradition petition (i.e. they're basically free citizens of Europe), have also been rejected from taking their seats for some esoteric reason.
As a "fun fact", in late 2018 some Spanish regions had elections. Andalucia was one of them and the current government is a coalition of PP+C+VOX, i.e. right wing conservatives, right wing liberals and ultra right wing nut-jobs. One of their first decisions was to put away 100000 euros for grants to teach Spanish to Spanish born people (not for helping immigrants, they're right wing crazies after all) living in Catalonia that don't know how speak Spanish. I'm 99.99% sure the number of people that matches that description is very close to 0 people. You heard well, the poorest region of Spain decided to subsidize the 4th richest region for something that is virtually useless. Thanks!
Much less "fun fact", last week Monday, the Spanish police decided to detain 9 pro-independence people (later to be 7 since 2 were let go) with terrorism charges. The investigation is on-going and technically it should be secret, but we've seen pictures all over the news of what the cops say to be material to make bombs, and all i can see is a pressure cooking pot and some fireworks used typically for Ball de diables.
I don't want to 100% rule out this people having actual plans to do something nasty, but Spanish police/judges/state history of just fabricating charges against people they don't like is so long (An anarchist recently spent *18* months in jail awaiting trial for tweeting stuff "Goku lives, the fight continues" to be then just found innocent after trial) that i would not be surprised either if this is just Spain doing bigger-army-diplomacy again.
TL;DR: Everything is fucked up and I can't really see a way out at this point.
Sunday, September 22, 2019
Akademy 2019
It's 10 days already since Akademy 2019 finished and I'm already missing it :/
Akademy is a week-long action-packed conference, talks, BoFs, daytrip, dinner with old and new friends, it's all a great combination and shows how amazing KDE (yes, the community, that's our name) is.
On the talks side i missed some that i wanted to attend because i had to extend my time at the registration booth helping fellow KDE people that had forgotten to register (yes, our setup could be a bit easier, doesn't help that you have to register for talks, for travel support and for the actual conference in three different places), but I am not complaining, you get to interact with lots of people in the registration desk, it's a good way to meet people you may not have met otherwise, so please make sure you volunteer next year ;)
One of the talks i want to highlight is Dan Vrátil's talk about C++, I agree with him that we could do much better in making our APIs more expressive using the power of "modern" C++ (when do we stop it calling modern?). It's a pity that the slides are not up so you'll have to live with Kévin Ottens sketch of it for now.
My talk was sadly not very well attended since i was sharing time with the more interesting talk by Marco and Bhushan about Plasma in embedded devices (i would have gone there if it wasn't because i had a talk) so if you're interested in fuzzing please read my slides and give me a shout if you want to volunteer to help us fuzz all the things!
On the BoFs side one of the hardest but most interesting we had was the one about KDE Applications (the N things we release monthly in one go) vs KDE applications (all applications made by us), and i think we may be on the right track there, there's a plan, needs finishing out, but I'm confident it may actually work :)
One of the things that shows how amazing this conference is and how many interesting things are happening is the fact that i made a small list of bugs i wanted to work on if i ever got bored of the talks or the BoFs, i don't think i even started on any of them ^_^
Akademy 2020
Akademy is a core event for KDE and we need to find people to help us organising it every year. If you think you can help, please have a look at the call for hosts document.
Thanks
I would like to thank the UnixMiB friends for hosting us, i know it's lots of work and i hope you know we all very much appreciate the effort you put in.
I would like to thank the Akademy-team on KDE's side too, you are amazing and pull out great work year after year, keep it up!
I would like to thank the KDE e.V. for partially sponsoring my attendance to Akademy, please donate to KDE if you think the work done at Akademy is important.
Saturday, August 10, 2019
Order your Akademy t-shirt *NOW*
If you want an Akademy 2019 t-shirt you have until Monday 12th Aug at 1100CEST (i.e. in 2 days and a bit) to order it.
Head over to https://akademy.kde.org/2019/akademy-2019-t-shirt and get yourself one of the exclusive t-shirts with Jen's awesome design :)
Head over to https://akademy.kde.org/2019/akademy-2019-t-shirt and get yourself one of the exclusive t-shirts with Jen's awesome design :)
Sunday, July 28, 2019
My KDE Onboarding Sprint 2019 report
This week I took part on the KDE Onboarding Sprint 2019 (part of what's been known as Nuremberg Megasprint (i.e. KDEConnect+KWin+Onboarding) in, you guessed it, Nuremberg.
The goal of the sprint was "how do we make it easier for people to start contributing". We mostly focused on the "start contributing *code*" side, though we briefly touched artists and translators too.
This is *my* summary, a more official one will appear somewhere else, so don't get annoyed at me if the blog is a bit opinionated (though i'll try it not to)
The main issues we've identified when trying to contribute to KDE software is:
* Getting dependencies is [sometimes] hard
* Actually running the software is [sometimes] hard
Dependencies are hard
Say you want to build dolphin from the git master branch. For that (at the time of writing) you need KDE Frameworks 5.57, this means that if you run the latest Ubuntu or the latest OpenSUSE you can't build it because they ship older versions.
Our current answer for that is kdesrc-build but it's not the most easy to use script, and sometimes you may end up building QtWebEngine or QtWebKit, which as a newbie is something you most likely don't want to do.
Running is hard
Running the software you have just built (once you've passed the dependencies problem) is not trivial either.
Most of our software can't be run uninstalled (KDE Frameworks are a notable exception here, but newbies rarely start developing KDE Frameworks).
This means that you may try to run make install, which if you didn't pass -DCMAKE_INSTALL_PREFIX pointing somewhere in your home you'll probably have to run make install as root since it defaults to /usr/local (this will be fixed in next extra-cmake-modules release to point to a somewhat better prefix) that isn't that useful either since none of your software is looking for stuff in /usr/local. Newbies may be tempted to use -DCMAKE_INSTALL_PREFIX=/usr but that's *VERY* dangerous since it can easily mess up your own system.
For applications, our typical answer is use -DCMAKE_INSTALL_PREFIX=/home/something/else at cmake stage, run make install and then set the environment variables to pick up things from /home/something/else, a newbie will say "which variables" at this stage probably (and not newbies too, I don't think i remember them all). To help with that we generate a prefix.sh in the build dir and after the next extra-cmake-release we will tell the users that they need to run it for things to work.
But still that's quite convoluted and I know from experience answering people in IRC that lots of people get stuck there. It's also very IDE unfriendly since IDEs don't usually have the "install" concept, it's run & build for them.
Solutions
We ended up focusing on two possible solutions:
* Conan: Conan "the C/C++ Package Manager for Developers" (or so they say) is something like pip in the python world but for C/C++. The idea is that by using Conan to get the dependencies we will solve most of the problems in that area. Whether it can help or not with the running side is still unclear, but some of our people involved in the Conan effort think they may either be able to come up with a solution or get the Conan devs to help us with it. Note Conan is not my speciality by far, so this may not be totally correct.
* Flatpak: Flatpak is "a next-generation technology for building and distributing desktop applications on Linux" (or so they say). The benefits of using flatpak are multiple, but focusing on onboarding are. "Getting dependencies is solved", dependencies are either part of the flatpatk SDK and you have them or the flatpak manifest for the application says how to get and build them and that will automagically work for you as it works for everyone else using the same manifest. "Running is solved" because when you build a flatpak it gets built into a self contained artifact so running it is just running it, no installing or environment variable fiddling is needed. We also have [preliminary] support in KDevelop (or you can use Gnome Builder if you want a more flatpak-centric experience for now). The main problem we have with flatpak at this point is that most of our apps are not totally flatpak-ready (e.g. Okular can't print). But that's something we need to fix anyway so it shouldn't be counted as a problem (IMHO).
Summary
*Personally* i think Flatpak is the way to go here, but that means that collectively we need to say "Let's do it", it's something we all have to take into account and thus we have to streamline the manifest handling/updating, focus on fixing the Flatpak related issues that our software may have, etc.
Thanks
I would like to thank SUSE for hosting us in their offices 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.
The goal of the sprint was "how do we make it easier for people to start contributing". We mostly focused on the "start contributing *code*" side, though we briefly touched artists and translators too.
This is *my* summary, a more official one will appear somewhere else, so don't get annoyed at me if the blog is a bit opinionated (though i'll try it not to)
The main issues we've identified when trying to contribute to KDE software is:
* Getting dependencies is [sometimes] hard
* Actually running the software is [sometimes] hard
Dependencies are hard
Say you want to build dolphin from the git master branch. For that (at the time of writing) you need KDE Frameworks 5.57, this means that if you run the latest Ubuntu or the latest OpenSUSE you can't build it because they ship older versions.
Our current answer for that is kdesrc-build but it's not the most easy to use script, and sometimes you may end up building QtWebEngine or QtWebKit, which as a newbie is something you most likely don't want to do.
Running is hard
Running the software you have just built (once you've passed the dependencies problem) is not trivial either.
Most of our software can't be run uninstalled (KDE Frameworks are a notable exception here, but newbies rarely start developing KDE Frameworks).
This means that you may try to run make install, which if you didn't pass -DCMAKE_INSTALL_PREFIX pointing somewhere in your home you'll probably have to run make install as root since it defaults to /usr/local (this will be fixed in next extra-cmake-modules release to point to a somewhat better prefix) that isn't that useful either since none of your software is looking for stuff in /usr/local. Newbies may be tempted to use -DCMAKE_INSTALL_PREFIX=/usr but that's *VERY* dangerous since it can easily mess up your own system.
For applications, our typical answer is use -DCMAKE_INSTALL_PREFIX=/home/something/else at cmake stage, run make install and then set the environment variables to pick up things from /home/something/else, a newbie will say "which variables" at this stage probably (and not newbies too, I don't think i remember them all). To help with that we generate a prefix.sh in the build dir and after the next extra-cmake-release we will tell the users that they need to run it for things to work.
But still that's quite convoluted and I know from experience answering people in IRC that lots of people get stuck there. It's also very IDE unfriendly since IDEs don't usually have the "install" concept, it's run & build for them.
Solutions
We ended up focusing on two possible solutions:
* Conan: Conan "the C/C++ Package Manager for Developers" (or so they say) is something like pip in the python world but for C/C++. The idea is that by using Conan to get the dependencies we will solve most of the problems in that area. Whether it can help or not with the running side is still unclear, but some of our people involved in the Conan effort think they may either be able to come up with a solution or get the Conan devs to help us with it. Note Conan is not my speciality by far, so this may not be totally correct.
* Flatpak: Flatpak is "a next-generation technology for building and distributing desktop applications on Linux" (or so they say). The benefits of using flatpak are multiple, but focusing on onboarding are. "Getting dependencies is solved", dependencies are either part of the flatpatk SDK and you have them or the flatpak manifest for the application says how to get and build them and that will automagically work for you as it works for everyone else using the same manifest. "Running is solved" because when you build a flatpak it gets built into a self contained artifact so running it is just running it, no installing or environment variable fiddling is needed. We also have [preliminary] support in KDevelop (or you can use Gnome Builder if you want a more flatpak-centric experience for now). The main problem we have with flatpak at this point is that most of our apps are not totally flatpak-ready (e.g. Okular can't print). But that's something we need to fix anyway so it shouldn't be counted as a problem (IMHO).
Summary
*Personally* i think Flatpak is the way to go here, but that means that collectively we need to say "Let's do it", it's something we all have to take into account and thus we have to streamline the manifest handling/updating, focus on fixing the Flatpak related issues that our software may have, etc.
Thanks
I would like to thank SUSE for hosting us in their offices 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.
Monday, July 15, 2019
KDE Applications 19.08 branches created
Make sure you commit anything you want to end up in the KDE Applications 19.08 release to them
We're already past the dependency freeze.
The Freeze and Beta is this Thursday 18 of July.
More interesting dates
August 1, 2019: KDE Applications 19.08 RC (19.07.90) Tagging and Release
August 8, 2019: KDE Applications 19.08 Tagging
August 15, 2019: KDE Applications 19.08 Release
https://community.kde.org/Schedules/Applications/19.08_Release_Schedule
We're already past the dependency freeze.
The Freeze and Beta is this Thursday 18 of July.
More interesting dates
August 1, 2019: KDE Applications 19.08 RC (19.07.90) Tagging and Release
August 8, 2019: KDE Applications 19.08 Tagging
August 15, 2019: KDE Applications 19.08 Release
https://community.kde.org/Schedules/Applications/19.08_Release_Schedule
Wednesday, July 10, 2019
Beware of some of the Qt 5.13 deprecation porting hints
QComboBox::currentIndexChanged(QString) used to have (i.e. in Qt 5.13.0) a deprecation warning that said "Use currentTextChanged() instead".
That has recently been reverted since both are not totally equivalent, sure, you can probably "port" from one to the other, but the "use" wording to me seems like a "this is the same" and they are not.
Another one of those is QPainter::initFrom, which inits a painter with the pen, background and font to the same as the given widget. This is deprecated, because it's probably wrong ("what is the pen of a widget?") but the deprecation warning says "Use begin(QPaintDevice*)" but again if you look at the implementation, they don't really do the same. Still need to find time to complain to the Qt developers and get it fixed.
Anyhow, as usual, when porting make sure you do a correct port and not just blind changes.
That has recently been reverted since both are not totally equivalent, sure, you can probably "port" from one to the other, but the "use" wording to me seems like a "this is the same" and they are not.
Another one of those is QPainter::initFrom, which inits a painter with the pen, background and font to the same as the given widget. This is deprecated, because it's probably wrong ("what is the pen of a widget?") but the deprecation warning says "Use begin(QPaintDevice*)" but again if you look at the implementation, they don't really do the same. Still need to find time to complain to the Qt developers and get it fixed.
Anyhow, as usual, when porting make sure you do a correct port and not just blind changes.
Tuesday, July 02, 2019
Usability & Productivity Sprint 2019
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.
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.
Thursday, June 27, 2019
KDE Applications 19.08 Schedule finalized
It is available at the usual place https://community.kde.org/Schedules/Applications/19.08_Release_Schedule
Dependency freeze is two weeks (July 11) and Feature Freeze a week after that, make sure you start finishing your stuff!
P.S: Remember last day to apply for Akademy Travel Support is this Sunday 30 of June!
Dependency freeze is two weeks (July 11) and Feature Freeze a week after that, make sure you start finishing your stuff!
P.S: Remember last day to apply for Akademy Travel Support is this Sunday 30 of June!
Saturday, June 08, 2019
I'm going to Akademy!
And you should too!
Akademy is free to attend however you need to register to reserve your space, so head to https://akademy.kde.org/2019/register and press the buttons.
Akademy is very important to meet people, discuss future plans, learn about new stuff and make friends for life!
Note this year the recommended accomodations are a bit on the expensive side, so you may want to hurry and apply for Travel support. The last round is open until July 1st.
Akademy is free to attend however you need to register to reserve your space, so head to https://akademy.kde.org/2019/register and press the buttons.
Akademy is very important to meet people, discuss future plans, learn about new stuff and make friends for life!
Note this year the recommended accomodations are a bit on the expensive side, so you may want to hurry and apply for Travel support. The last round is open until July 1st.
Friday, June 07, 2019
Akademy-es 2019 talks announced!
Akademy-es 2019 will be happening this June 28-30 in Vigo.
The talks were just announced recently.
Check them out at https://www.kde-espana.org/akademy-es-2019/programa-akademy-es-2019 it has lots of interesting talks so if you understand Spanish and are interested in KDE or Free Software in general I'd really recommend to attend!
The talks were just announced recently.
Check them out at https://www.kde-espana.org/akademy-es-2019/programa-akademy-es-2019 it has lots of interesting talks so if you understand Spanish and are interested in KDE or Free Software in general I'd really recommend to attend!
Friday, May 17, 2019
[Some] KDE Applications 19.04.1 also available in flathub
Thanks to Nick Richards we've been able to convince flathub to momentarily accept our old appdata files as still valid, it's a stopgap workaround, but at least gives us some breathing time. So the updates are coming in as we speak.
Thursday, May 16, 2019
No KDE Applications 19.04.1 available in flathub
The flatpak and flathub developers have changed what they consider a valid appdata file, so our appdata files that were valid last month are not valid anymore and thus we can't build the KDE Applications 19.04.1 packages.
Tuesday, April 23, 2019
[Some] KDE Applications 19.04 also available in flathub
The KDE Applications 19.04 release announcement (read it if you haven't, it's very complete) mentions some of the applications are available at the snap store, but forgets to mention flathub.
Just wanted to bring up that there's also some of the applications available in there https://flathub.org/apps/search/org.kde.
All the ones that are released along KDE Applications 19.04 were updated on release day (except kubrick that has a compilation issue and will be updated for 19.04.1 and kontact which is a best and to be honest i didn't particularly feel like updating it)
If you feel like helping there's more applications that need adding and more automation that needs to happen, so get in touch :)
Just wanted to bring up that there's also some of the applications available in there https://flathub.org/apps/search/org.kde.
All the ones that are released along KDE Applications 19.04 were updated on release day (except kubrick that has a compilation issue and will be updated for 19.04.1 and kontact which is a best and to be honest i didn't particularly feel like updating it)
If you feel like helping there's more applications that need adding and more automation that needs to happen, so get in touch :)
Thursday, February 07, 2019
KDE Applications 19.04 Schedule finalized
It is available at the usual place https://community.kde.org/Schedules/Applications/19.04_Release_Schedule
Dependency freeze is March 14 and Feature Freeze a week after that, make sure you start finishing your stuff!
Dependency freeze is March 14 and Feature Freeze a week after that, make sure you start finishing your stuff!
Friday, January 11, 2019
Okular: PDF Signature + Certificate support has landed
As of a few minutes ago, i merged the code from Chinmoy Ranjan Pradhan's GSOC to support showing PDF Signatures and Certificates in Okular.
Signature handling is a big step for us, but it's also very complex, so i expect it to have bugs and things that can be improved so testers more than welcome.
Compiling is a bit "hard" since it requires poppler 0.73 that was released a few days ago.
But thanks to flatpak, there's no need to compile it, you can run the KDE Okular Nightly on your system to try it
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak remote-add --if-not-exists kdeapps --from https://distribute.kde.org/kdeapps.flatpakrepo
flatpak install kdeapps org.kde.okular
Note: if you have okular installed from another flatpak repo (for example flathub) this will switch you to the KDE Nightlies, you may want to switch back after testing.
And then you can try the adobe sample pdf
flatpak run --share=network org.kde.okular https://blogs.adobe.com/security/SampleSignedPDFDocument.pdf
And you should get stuff like this
Signature handling is a big step for us, but it's also very complex, so i expect it to have bugs and things that can be improved so testers more than welcome.
Compiling is a bit "hard" since it requires poppler 0.73 that was released a few days ago.
But thanks to flatpak, there's no need to compile it, you can run the KDE Okular Nightly on your system to try it
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak remote-add --if-not-exists kdeapps --from https://distribute.kde.org/kdeapps.flatpakrepo
flatpak install kdeapps org.kde.okular
Note: if you have okular installed from another flatpak repo (for example flathub) this will switch you to the KDE Nightlies, you may want to switch back after testing.
And then you can try the adobe sample pdf
flatpak run --share=network org.kde.okular https://blogs.adobe.com/security/SampleSignedPDFDocument.pdf
And you should get stuff like this
Thursday, January 03, 2019
sjfonts 2.1 released
More than 11 years after sjfonts 2.0.2 was released today I'm announcing sjfonts 2.1
It contains two enhacements contributed by Yuri Chornoivan
* Delphine font now has the Euro sign
* Steve font now has "basic" Cyrillic characters
If by any chance your distribution is packaging them, update!
https://sourceforge.net/projects/sjfonts/files/sjfonts/sjfonts-2.1/
Yes, it's on sourceforge ;)
It contains two enhacements contributed by Yuri Chornoivan
* Delphine font now has the Euro sign
* Steve font now has "basic" Cyrillic characters
If by any chance your distribution is packaging them, update!
https://sourceforge.net/projects/sjfonts/files/sjfonts/sjfonts-2.1/
Yes, it's on sourceforge ;)
Friday, November 09, 2018
KDE Applications 18.12 branches created
Make sure you commit anything you want to end up in the 18.12 release to them
We're already past the dependency freeze.
The Freeze and Beta is this Thursday 15 of November.
More interesting dates
November 29: KDE Applications 18.12 RC (18.11.90) Tagging and Release
December 6: KDE Applications 18.12 Tagging
December 13: KDE Applications 18.12 Release
https://community.kde.org/Schedules/Applications/18.12_Release_Schedule
We're already past the dependency freeze.
The Freeze and Beta is this Thursday 15 of November.
More interesting dates
November 29: KDE Applications 18.12 RC (18.11.90) Tagging and Release
December 6: KDE Applications 18.12 Tagging
December 13: KDE Applications 18.12 Release
https://community.kde.org/Schedules/Applications/18.12_Release_Schedule
Wednesday, October 24, 2018
KDE Applications 18.12 Schedule finalized
It is available at the usual place https://community.kde.org/Schedules/Applications/18.12_Release_Schedule
Dependency freeze is in 2 weeks and Feature Freeze in 3 weeks, so hurry up!
Dependency freeze is in 2 weeks and Feature Freeze in 3 weeks, so hurry up!
Monday, September 24, 2018
Libre Application Summit 2018
Earlier this month i attended Libre Application Summit 2018 in Denver.
Libre Application Summit wants to be a place for all people involved in doing Free Software applications to meet and share ideas, though being almost organized by GNOME it had a some skew towards GNOME/flatpak. There was a good presence of KDE, but personally I felt that we would have needed more people at least from LibreOffice, Firefox and someone from the Ubuntu/Canonical/Snap field (don't get annoyed at you if I failed to mention your group).
The Summit was kicked off by a motivational talk on how to make sure we ride the wave of "Open Source has won but people don't know it". I felt the content of the talk was nice but the speaker was hit by some issues (not being able to have the laptop in front of her due to the venue being a bit weirdly layouted) that sadly made her speech a bit too stumbly.
Then we had a bunch of flatpak related talks, ranging from the new freedesktop-sdk runtime, from very technical stuff about how ostree works and also including a talk by our own Aleix Pol on how KDE is planning to approach the release of flatpaks. Some of us ended the day having BBQ at the house the Codethink people were staying. Thanks for the good time!
I kicked off the next day talking about how we (lately mostly Christoph) are doing the KDE Applications releases. We got appreciation of the good work we're doing and some interesting follow up questions so I think people were engaged by it.
The morning continued with talks about how to engage the "non typical" free software people, designers, students, professors, etc.
After lunch we had a few talks by the Elementary people and another talk with Aleix focused on which apps will run on your Plasma devices (hint: all of them).
The day finished with a quizz sponsored by System 76, it was fun!
The last day of talks started again with me speaking, this time about how amazing Qt is and why you should use it to build your apps. There I had some questions about people worrying if QtWidgets was going to die, I told them not to worry, but it's clear The Qt Company needs to improve their messaging in that regard.
After that we had a talk about a Fedora project to create a distro based exclusively in flaptaks, which sounds really interesting. The last talks of LAS 2018 were about how to fight vandalism in crowdsourced data, the status of Librem 5 (it's still a bit far away) and a very interesting one about the status of Free Software in Research.
All in all i think the conference was interesting, still a bit small and too GNOME controlled to appeal to the general crowd, but it's the second time it has been organized, so it will improve.
I want to thank the KDE e.V. for sponsoring my flight and hosting to attend this conference. Please Donate! so we can continue attending conferences like this and spreading the good work of KDE :)
Check out the great group photo at #LASGNOME! Thank you for all the participant and speakers for posing for us :-) pic.twitter.com/v7pPmcCBV1
— LAS GNOME (@LASGNOME) 8 de setembre de 2018
Libre Application Summit wants to be a place for all people involved in doing Free Software applications to meet and share ideas, though being almost organized by GNOME it had a some skew towards GNOME/flatpak. There was a good presence of KDE, but personally I felt that we would have needed more people at least from LibreOffice, Firefox and someone from the Ubuntu/Canonical/Snap field (don't get annoyed at you if I failed to mention your group).
The Summit was kicked off by a motivational talk on how to make sure we ride the wave of "Open Source has won but people don't know it". I felt the content of the talk was nice but the speaker was hit by some issues (not being able to have the laptop in front of her due to the venue being a bit weirdly layouted) that sadly made her speech a bit too stumbly.
Then we had a bunch of flatpak related talks, ranging from the new freedesktop-sdk runtime, from very technical stuff about how ostree works and also including a talk by our own Aleix Pol on how KDE is planning to approach the release of flatpaks. Some of us ended the day having BBQ at the house the Codethink people were staying. Thanks for the good time!
Soon, @tsdgeos tells us all about KDE Applications releases in @LASGNOME. @kdecommunity pic.twitter.com/ODnxEZ77xv
— Aleix Pol (@AleixPol) 7 de setembre de 2018
I kicked off the next day talking about how we (lately mostly Christoph) are doing the KDE Applications releases. We got appreciation of the good work we're doing and some interesting follow up questions so I think people were engaged by it.
The morning continued with talks about how to engage the "non typical" free software people, designers, students, professors, etc.
The @kdecommunity and @Codethink people having interesting discussions over sushi at #LAS2018 pic.twitter.com/O5lH1hPTlk
— Albert Astals Cid (@tsdgeos) 7 de setembre de 2018
After lunch we had a few talks by the Elementary people and another talk with Aleix focused on which apps will run on your Plasma devices (hint: all of them).
The day finished with a quizz sponsored by System 76, it was fun!
The KDE spies team wasn't very successful at #LASGNOME trivial, but had lots of fun :) @tsdgeos @AleixPol @maru161803399 @albertvaka pic.twitter.com/k0172A3Vk1
— Albert Astals Cid (@tsdgeos) 8 de setembre de 2018
The last day of talks started again with me speaking, this time about how amazing Qt is and why you should use it to build your apps. There I had some questions about people worrying if QtWidgets was going to die, I told them not to worry, but it's clear The Qt Company needs to improve their messaging in that regard.
Learning about Qt in the @LASGNOME from @tsdgeos @qtproject pic.twitter.com/Vr5Raj10Su
— Aleix Pol (@AleixPol) 8 de setembre de 2018
After that we had a talk about a Fedora project to create a distro based exclusively in flaptaks, which sounds really interesting. The last talks of LAS 2018 were about how to fight vandalism in crowdsourced data, the status of Librem 5 (it's still a bit far away) and a very interesting one about the status of Free Software in Research.
All in all i think the conference was interesting, still a bit small and too GNOME controlled to appeal to the general crowd, but it's the second time it has been organized, so it will improve.
I want to thank the KDE e.V. for sponsoring my flight and hosting to attend this conference. Please Donate! so we can continue attending conferences like this and spreading the good work of KDE :)
Monday, September 03, 2018
Come meet KDE in Denver - September 6-9
This week, Aleix (KDE eV Vice Predisdent), Albert Vaca (KDE Connect maintainer) and me will be in Denver to attend the Libre Application Summit 2018.
Libre Application Summit is unfortunately not free to attend so even if i'd urge you to come and see the amazing talks we're going to give I can see why not everyone would want to come.
So I'm going to say that if you're in the Denver area and are a KDE fan, write a comment here and maybe we can meet for drinks or something :)
Libre Application Summit is unfortunately not free to attend so even if i'd urge you to come and see the amazing talks we're going to give I can see why not everyone would want to come.
So I'm going to say that if you're in the Denver area and are a KDE fan, write a comment here and maybe we can meet for drinks or something :)
Thursday, August 09, 2018
PSA: Use SASL in konversation
You probably have seen that Freenode has been getting lots of spam lately.
To protect against that some channels have activated a flag that only allows authenticated users to enter the channel.
If you're using the regular "nickserv" authentication way as I was doing, the authentication happens in parallel to entering the channels and you'll probably be rejected from joining some.
What you want is use SASL, that is a "new IRC" protocol that will first authenticate and then join the server/channels.
More info at https://userbase.kde.org/Konversation/Configuring_SASL_authentication.
Thanks Fuchs on #kde-devel for enlightening me :)
And of course, I'm going to Akademy ;)
To protect against that some channels have activated a flag that only allows authenticated users to enter the channel.
If you're using the regular "nickserv" authentication way as I was doing, the authentication happens in parallel to entering the channels and you'll probably be rejected from joining some.
What you want is use SASL, that is a "new IRC" protocol that will first authenticate and then join the server/channels.
More info at https://userbase.kde.org/Konversation/Configuring_SASL_authentication.
Thanks Fuchs on #kde-devel for enlightening me :)
And of course, I'm going to Akademy ;)
Monday, July 16, 2018
KDE Applications 18.08 branches created
Make sure you commit anything you want to end up in the KDE Applications 18.08 release to them :)
We're already past the dependency freeze.
The Freeze and Beta is this Thursday 19 of July.
More interesting dates
August 2: KDE Applications 18.08 RC (18.07.90) Tagging and Release
August 9: KDE Applications 18.08 Tagging
August 16: KDE Applications 18.08 Release
https://community.kde.org/Schedules/Applications/18.08_Release_Schedule
We're already past the dependency freeze.
The Freeze and Beta is this Thursday 19 of July.
More interesting dates
August 2: KDE Applications 18.08 RC (18.07.90) Tagging and Release
August 9: KDE Applications 18.08 Tagging
August 16: KDE Applications 18.08 Release
https://community.kde.org/Schedules/Applications/18.08_Release_Schedule
Thursday, June 21, 2018
Qt Contributor Summit 2018
About two weeks ago i attended Qt Contributor Summit 2018, i did so wearing my KDAB hat, but given that KDE software is based heavily on Qt I think I'll give a quick summary of the most important topic that was handled at the Summit: Qt 6
On a community related note, Tero Kojo the Community Manager for The Qt Company is leaving and doesn't seem a replacement is on sight
Of course, note that these are all plans, and as such they may be outdated already since the last 10 days :D
- Qt 6 is planned for a November 2020 release
- Qt 5 releases will continue with the current cadence as of now with 5.15 being the last release (and also LTS)
- The work branch for Qt 6 will be branched soon after Qt 5.12
- Qt 6 has to be easy to migrate from Qt 5
- Qt 6 will use C++17
- Everything to be removed in Qt 6 should be marked as deprecated in 5.15 (ideally sooner)
- What can be done in Qt 5 should be done to Qt 5
- Qt 6 should be a "boring" release user feature wise, mostly cleanup and preparing for the future
- Qt 6 should change things that break at compile time, those are easy to fix, silent runtime changes are scarier
- Qt 6 will not use qmake as build system
- The build system for Qt 6 is still not decided, but there's people working on a qbs build and noone working on any other alternative
On a community related note, Tero Kojo the Community Manager for The Qt Company is leaving and doesn't seem a replacement is on sight
Of course, note that these are all plans, and as such they may be outdated already since the last 10 days :D
Wednesday, June 06, 2018
Call for distros: Patch cups for better internationalization
If you're reading this and use cups to print (almost certainly you do if you're on Linux), you may want to contact your distribution and ask them to add this patch.
It adds translation support for a few keyword found in some printers PPD files. The CUPS upstream project has rejected with not much reason other than "PPD is old", without really taking into account it's really the only way you can get access to some advanced printer features (see comments in the same thread)
Anyhow they're free to not want that code upstream but i really think all distros should add it since it's very simple and improves the usability for some users.
It adds translation support for a few keyword found in some printers PPD files. The CUPS upstream project has rejected with not much reason other than "PPD is old", without really taking into account it's really the only way you can get access to some advanced printer features (see comments in the same thread)
Anyhow they're free to not want that code upstream but i really think all distros should add it since it's very simple and improves the usability for some users.
Friday, April 13, 2018
Akademy 2018 hotel and flight booked!
I just booked my flights and hotel for Akademy 2018.
If you're planning to come you should too! [1]
You can find information about the recommended accommodation here.
See you in Viena!
[1] unless you're applying for sponsored travel+accommodation
If you're planning to come you should too! [1]
You can find information about the recommended accommodation here.
See you in Viena!
[1] unless you're applying for sponsored travel+accommodation
Monday, March 19, 2018
KDE Applications 18.04 branches created
Make sure you commit anything you want to end up in the KDE Applications 18.04 release to them :)
We're already past the dependency freeze.
The Freeze and Beta is this Thursday 22 of March.
More interesting dates
April 5: KDE Applications 18.04 RC (18.03.90) Tagging and Release
April 12: KDE Applications 18.04 Tagging
April 19: KDE Applications 18.04 Release
https://community.kde.org/Schedules/Applications/18.04_Release_Schedule
We're already past the dependency freeze.
The Freeze and Beta is this Thursday 22 of March.
More interesting dates
April 5: KDE Applications 18.04 RC (18.03.90) Tagging and Release
April 12: KDE Applications 18.04 Tagging
April 19: KDE Applications 18.04 Release
https://community.kde.org/Schedules/Applications/18.04_Release_Schedule
Akademy-es 2018 in Valencia - 11-13 May
This years Akademy-es will be happening in Valencia from 11 to 13 of May. The call for papers is still open so if speak Spanish and have something interesting to share with your fellow KDE people send a talk :)
We'll open registration shortly, be sure to attend and say hi!
We'll open registration shortly, be sure to attend and say hi!
Friday, February 23, 2018
Okular gains some more JavaScript support
Andre Heinecke did some patches [1][2][3][4][5] over the last few weeks that finally got landed this week.
With it we support recalculation of some fields based on others. An example that calculates sum, average, product, minimum and maximum of three numbers can be found in this youtube video.
This code will be available for the Okular version that will ship with KDE Applications 18.04
With it we support recalculation of some fields based on others. An example that calculates sum, average, product, minimum and maximum of three numbers can be found in this youtube video.
This code will be available for the Okular version that will ship with KDE Applications 18.04
Wednesday, February 07, 2018
KDE Applications 18.04 Schedule finalized
It is available at the usual place https://community.kde.org/Schedules/Applications/18.04_Release_Schedule
Dependency freeze is in 5 weeks and Feature Freeze in 6 weeks, so hurry up!
Dependency freeze is in 5 weeks and Feature Freeze in 6 weeks, so hurry up!
Wednesday, November 01, 2017
Akademy 2018 site visit
Last week I was part of the expedition by KDE (together with Kenny and Petra) to visit the local team that is helping us organize Akademy 2018 in Vienna.
I can say that I'm very happy :)
The accommodation that we're probably going to recommend is 15 minutes away by train from the airport, 20 minutes on foot from the Venue (10 on metro) so kind of convenient.
The Venue is modern and centrally located in Vienna (no more "if you miss the bus you're stranded")
Vienna itself seems to be also a nice city for late evening sight-seeing (or beers :D)
Hopefully "soon" we will have confirmation of the dates and we'll be able to publish them :)
I can say that I'm very happy :)
The accommodation that we're probably going to recommend is 15 minutes away by train from the airport, 20 minutes on foot from the Venue (10 on metro) so kind of convenient.
The Venue is modern and centrally located in Vienna (no more "if you miss the bus you're stranded")
Vienna itself seems to be also a nice city for late evening sight-seeing (or beers :D)
Hopefully "soon" we will have confirmation of the dates and we'll be able to publish them :)
Thursday, October 19, 2017
KDE Edu sprint 2017 in Berlin
I had the privilege to attend the KDE Edu sprint in Berlin that happened from the 6th to the 9th of October.
There i mostly worked in the KTuberling port to Android. If you have children (or maybe if you want to feel like one for a few minutes) and an Android device please try it and give some constructive feedback ;)
Though of course that's not all we did, we also had important discussions about "What is kde edu", about how we should be involved in the "Making KDE software the #1 choice for research and academia" KDE goal and other organization stuff like whether we want a phabricator rule to send email to the kdeedu mailing list for a set of projects, etc.
Thanks go to all the people that donate to KDE e.V. that made sponsoring the trip possible, and to Endocode for hosting us and sponsoring all kind of interesting drinks and pizza on Sunday :)
There i mostly worked in the KTuberling port to Android. If you have children (or maybe if you want to feel like one for a few minutes) and an Android device please try it and give some constructive feedback ;)
Though of course that's not all we did, we also had important discussions about "What is kde edu", about how we should be involved in the "Making KDE software the #1 choice for research and academia" KDE goal and other organization stuff like whether we want a phabricator rule to send email to the kdeedu mailing list for a set of projects, etc.
Thanks go to all the people that donate to KDE e.V. that made sponsoring the trip possible, and to Endocode for hosting us and sponsoring all kind of interesting drinks and pizza on Sunday :)
Sunday, October 01, 2017
Sorry for Spain
Today the Spanish police has committed in Catalonia what can only be described as barbarism.
Beware of the videos, they may hurt your feelings.
They have hit people on the street and fought catalan police over it https://twitter.com/jaumeclotet/status/914484855450333184
They have hit people sitting on stairs https://twitter.com/LaVanguardia/status/914447807754448896
They have hit old ladies https://twitter.com/asiercorc/status/914395993193504768
They have hit people standing on the street https://twitter.com/julia_otero/status/914466508570595329
Did i mention they hit people on the street? https://twitter.com/isaacfcorrales/status/914508531654676480
They also hit someone that was already injured and walking away https://twitter.com/Ulldebou1/status/914497525033390080
They have broken (on purpose) all the fingers of a woman that was already on the floor https://twitter.com/hectorjuanatey/status/914538706299707392
They have hit some more people https://twitter.com/QuicoSalles/status/914504909508218880
They have hit firefighters https://twitter.com/Jorfs_/status/914482953954177024
Currently we're officially speaking of more than 800 injured people https://twitter.com/emergenciescat/status/914584719060275200 but i wouldn't be surprised if the count was much higher.
Meanwhile a dude voting wrapped in a spanish+bull flag gets a round of clapping https://twitter.com/JoseJPriego/status/914485977158209536
And I'm saying sorry for Spain, because it's obvious that after today Catalonia will leave Spain, sooner or later but it's going to happen, but the rest of Spain will have to live with these beasts ingrained in their police and politics.
Sorry and good luck.
Beware of the videos, they may hurt your feelings.
They have hit people on the street and fought catalan police over it https://twitter.com/jaumeclotet/status/914484855450333184
They have hit people sitting on stairs https://twitter.com/LaVanguardia/status/914447807754448896
They have hit old ladies https://twitter.com/asiercorc/status/914395993193504768
They have hit people standing on the street https://twitter.com/julia_otero/status/914466508570595329
Did i mention they hit people on the street? https://twitter.com/isaacfcorrales/status/914508531654676480
They also hit someone that was already injured and walking away https://twitter.com/Ulldebou1/status/914497525033390080
They have broken (on purpose) all the fingers of a woman that was already on the floor https://twitter.com/hectorjuanatey/status/914538706299707392
They have hit some more people https://twitter.com/QuicoSalles/status/914504909508218880
They have hit firefighters https://twitter.com/Jorfs_/status/914482953954177024
Currently we're officially speaking of more than 800 injured people https://twitter.com/emergenciescat/status/914584719060275200 but i wouldn't be surprised if the count was much higher.
Meanwhile a dude voting wrapped in a spanish+bull flag gets a round of clapping https://twitter.com/JoseJPriego/status/914485977158209536
And I'm saying sorry for Spain, because it's obvious that after today Catalonia will leave Spain, sooner or later but it's going to happen, but the rest of Spain will have to live with these beasts ingrained in their police and politics.
Sorry and good luck.
Thursday, August 24, 2017
How to check if your touch screen is really sending touch events
I've had this problem twice in the last year, I'm testing something related to touch in my laptop and I'm stuck trying to figure out if it's my code that is wrong or if my screen is misconfigured and it's only sending mouse events.
Thanks to Shawn of Qt fame for having helped me the two times and explained me how to test if my screen is sending touch events, I'm writing this blog so i don't forget and ask him a third time :D
First step is figuring out the xinput id of the touch screen of my laptop
tsdgeos@yoga:~:$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Wacom Co.,Ltd. Pen and multitouch sensor Finger id=9 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech TrackPoint id=13 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech Touchpad id=14 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Sleep Button id=8 [slave keyboard (3)]
↳ Wacom Co.,Ltd. Pen and multitouch sensor Pen id=10 [slave keyboard (3)]
↳ Integrated Camera id=11 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
↳ ThinkPad Extra Buttons id=15 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
In this case would be id=9
Then you can do
tsdgeos@yoga:~:$ xinput test-xi2 9
and if the output contains RawTouchBegin and RawTouchEnd events, it means that the screen is correctly sending touch events :)
Next you probably want to check if Qt actually is seeing those events, for that there's a few ready to use demos in the qtdeclarative source code, so I would do
tsdgeos@yoga:~:$ qml qt5/qtdeclarative_58/examples/quick/touchinteraction/multipointtouch/multiflame.qml
And after putting my five fingers on the screen I would see
So all is good, the bug is my code and not in Qt or the configuration of my touch screen :D
Thanks to Shawn of Qt fame for having helped me the two times and explained me how to test if my screen is sending touch events, I'm writing this blog so i don't forget and ask him a third time :D
First step is figuring out the xinput id of the touch screen of my laptop
tsdgeos@yoga:~:$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Wacom Co.,Ltd. Pen and multitouch sensor Finger id=9 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech TrackPoint id=13 [slave pointer (2)]
⎜ ↳ ETPS/2 Elantech Touchpad id=14 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Sleep Button id=8 [slave keyboard (3)]
↳ Wacom Co.,Ltd. Pen and multitouch sensor Pen id=10 [slave keyboard (3)]
↳ Integrated Camera id=11 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)]
↳ ThinkPad Extra Buttons id=15 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
In this case would be id=9
Then you can do
tsdgeos@yoga:~:$ xinput test-xi2 9
and if the output contains RawTouchBegin and RawTouchEnd events, it means that the screen is correctly sending touch events :)
Next you probably want to check if Qt actually is seeing those events, for that there's a few ready to use demos in the qtdeclarative source code, so I would do
tsdgeos@yoga:~:$ qml qt5/qtdeclarative_58/examples/quick/touchinteraction/multipointtouch/multiflame.qml
And after putting my five fingers on the screen I would see
So all is good, the bug is my code and not in Qt or the configuration of my touch screen :D
Tuesday, August 01, 2017
Big day in poppler-land
Today in Poppler:
* Poppler 0.57 got released
* We agreed to stop supporting openjpeg 1.x at the end of the year
* We agreed to stop supporting Qt 4.x at the end of the year
* We merged the better_object branch
The last one is the one that is really big, since it introduces a big rework of the Object class, a central component to Poppler. Object is much used like a QVariant, i.e. it can hold various kind of data inside and you can pass it around.
Unfortunately the Object implementation we inherited from xpdf was kind of hard to use, having to basically do the memory management by hand. i.e. destroying the object was not enough to free the memory, you had to call free() on it.
Thanks to C++11 now we have an implementation with move semantics that greatly simplifies the use of Object and will hopefully make for less memory management mistakes.
Let's hope we didn't break anything in the process though :D
* Poppler 0.57 got released
* We agreed to stop supporting openjpeg 1.x at the end of the year
* We agreed to stop supporting Qt 4.x at the end of the year
* We merged the better_object branch
The last one is the one that is really big, since it introduces a big rework of the Object class, a central component to Poppler. Object is much used like a QVariant, i.e. it can hold various kind of data inside and you can pass it around.
Unfortunately the Object implementation we inherited from xpdf was kind of hard to use, having to basically do the memory management by hand. i.e. destroying the object was not enough to free the memory, you had to call free() on it.
Thanks to C++11 now we have an implementation with move semantics that greatly simplifies the use of Object and will hopefully make for less memory management mistakes.
Let's hope we didn't break anything in the process though :D
Thursday, June 15, 2017
KDE Applications 17.08 Schedule finalized
It is available at the usual place https://community.kde.org/Schedules/Applications/17.08_Release_Schedule
Dependency freeze is in 4 weeks and Feature Freeze in 5 weeks, so hurry up!
Dependency freeze is in 4 weeks and Feature Freeze in 5 weeks, so hurry up!
Thursday, April 20, 2017
Okular 1.1 released!
Today KDE Applications 17.04 was released.
It includes Okular 1.1, it contains a nice set of features:
* Add annotation resize functionality
* Add support for auto-calculation of form contents via JavaScript
* Allow to rotate the page view using two-finger pinches on a touchscreen
* Change pages in presentation mode by swiping on touch screen
* Added support for Links that change the Optional Content visibility status
* Allow to disable automatic search while typing
* Allow to create bookmarks from the Table Of Contents
This release was brought to you by Albert Astals Cid, Oliver Sander, Luigi Toscano, Martin T. H. Sandsmark, Tobias Deiminger, Antonio Rojas, Burkhard Lück, Christoph Feck, Elvis Angelaccio, Gilbert Assaf, Heiko Becker, Hrvoje Senjan, Marco Scarpetta, Miklós Máté, Pino Toscano, Yuri Chornoivan.
It includes Okular 1.1, it contains a nice set of features:
* Add annotation resize functionality
* Add support for auto-calculation of form contents via JavaScript
* Allow to rotate the page view using two-finger pinches on a touchscreen
* Change pages in presentation mode by swiping on touch screen
* Added support for Links that change the Optional Content visibility status
* Allow to disable automatic search while typing
* Allow to create bookmarks from the Table Of Contents
This release was brought to you by Albert Astals Cid, Oliver Sander, Luigi Toscano, Martin T. H. Sandsmark, Tobias Deiminger, Antonio Rojas, Burkhard Lück, Christoph Feck, Elvis Angelaccio, Gilbert Assaf, Heiko Becker, Hrvoje Senjan, Marco Scarpetta, Miklós Máté, Pino Toscano, Yuri Chornoivan.
Tuesday, April 04, 2017
Akademy 2017 Call for Papers deadline is in a week!
The Akademy 2017 Call for Papers ends April 10th at 23:59:59 CEST.
Surely you have interesting stuff to share with the community, so go to https://akademy.kde.org/2017/cfp and submit a proposal!
Surely you have interesting stuff to share with the community, so go to https://akademy.kde.org/2017/cfp and submit a proposal!
Tuesday, March 07, 2017
Okular table selection mode is amazing
I case you didn't know ;)
Okular has a amazing table select mode where you select an area and Okular will auto detect rows and columns on it (you can fine-tune it afterwards) and then you can directly copy&paste to a spreadsheet :)
It's mostly tested on PDF files, but should work the same on any of the formats we support text extraction.
Update: This feature is not new, just i got to use it today ;) Video at https://www.youtube.com/watch?v=E8XWI06tltY
Okular has a amazing table select mode where you select an area and Okular will auto detect rows and columns on it (you can fine-tune it afterwards) and then you can directly copy&paste to a spreadsheet :)
It's mostly tested on PDF files, but should work the same on any of the formats we support text extraction.
Update: This feature is not new, just i got to use it today ;) Video at https://www.youtube.com/watch?v=E8XWI06tltY
Wednesday, March 01, 2017
Okular Form Field auto-updating (Work In Progress)
You can see it in https://www.youtube.com/watch?v=fCLFkpaW3Ug
As the description of the YouTube video says:
Form 14 updates from Form 13 values as defined by the PDF file.
There's a few bugs left:
* To make the page contents update i need to edit another form in the page of the form that is being auto updated
* The contents of the "editable" Form are not updated. (The form is actually not editable since it's readonly)
And also a pile of uncommited and unreviewed patches, and probably only works for very simple files like this one, but it's a start :)
Update: It works fine now and everything has been commited :) https://www.youtube.com/watch?v=S-zmHc3WUhs
As the description of the YouTube video says:
Form 14 updates from Form 13 values as defined by the PDF file.
There's a few bugs left:
* To make the page contents update i need to edit another form in the page of the form that is being auto updated
* The contents of the "editable" Form are not updated. (The form is actually not editable since it's readonly)
And also a pile of uncommited and unreviewed patches, and probably only works for very simple files like this one, but it's a start :)
Update: It works fine now and everything has been commited :) https://www.youtube.com/watch?v=S-zmHc3WUhs
Thursday, February 16, 2017
KDE Applications 17.04 Schedule finalized
It is available at the usual place https://community.kde.org/Schedules/Applications/17.04_Release_Schedule
Dependency freeze is in 4 weeks and Feature Freeze in 5 weeks, so hurry up!
Dependency freeze is in 4 weeks and Feature Freeze in 5 weeks, so hurry up!
Thursday, December 15, 2016
KDE Applications 16.12.0 just out!
See https://www.kde.org/announcements/announce-applications-16.12.0.php for the announcement and https://www.kde.org/announcements/fulllog_applications.php?version=16.12.0 for the reaaaaaaaaally long changelog.
Well done everyone :)
Well done everyone :)
Wednesday, December 07, 2016
The dangers of stable/LTS/supported versions
Ubuntu 14.04 LTS is supported until April 2019 and ships poppler 0.24.5 http://packages.ubuntu.com/search?suite=trusty&searchon=names&keywords=libpoppler-dev
RHEL 7.3 ships poppler 0.26.5 (I may be wrong, https://git.centos.org/summary/?r=rpms/poppler is the best info i could find, Red Hat does not make easy to know what you're buying)
Debian stable (Jessie) ships poppler 0.26.5 https://packages.debian.org/search?suite=jessie&searchon=names&keywords=libpoppler-dev
Current release is poppler 0.49 https://poppler.freedesktop.org/releases.html
This means that people are running stable versions and thinking they are secure, but if we trust security specialists, [almost] every crash can be exploited, and I'm almost sure neither Ubuntu nor RedHat nor Debian have backported all of the crash fixes of the more than 20 releases and 2 years of development behind those *very old* versions they are shipping.
I don't know how/if this can be fixed, but i honestly think we're giving users a false sense of security by letting them run those versions.
RHEL 7.3 ships poppler 0.26.5 (I may be wrong, https://git.centos.org/summary/?r=rpms/poppler is the best info i could find, Red Hat does not make easy to know what you're buying)
Debian stable (Jessie) ships poppler 0.26.5 https://packages.debian.org/search?suite=jessie&searchon=names&keywords=libpoppler-dev
Current release is poppler 0.49 https://poppler.freedesktop.org/releases.html
This means that people are running stable versions and thinking they are secure, but if we trust security specialists, [almost] every crash can be exploited, and I'm almost sure neither Ubuntu nor RedHat nor Debian have backported all of the crash fixes of the more than 20 releases and 2 years of development behind those *very old* versions they are shipping.
I don't know how/if this can be fixed, but i honestly think we're giving users a false sense of security by letting them run those versions.
No one "works" on Poppler
I thought that was obvious, but today someone thought that i was "working" as "paid working" on it.
No, I don't get paid for the work i do on Poppler.
It's my computing hobby, and on top of that it's not even my "primary" computing hobby, lots of KDE stuff take precedence over it, and i guess Gnome stuff may also take precedence for Carlos (second top commiter according to the git shortlog)
Aside a few paid contributions and some patches that may have come from people that use the software on their business (and we could file them under "paid" since they did the fix as part of their job) no one has a paid job that is mainly "work on poppler".
I guess we've done a good enough job as hobbyist :)
Obviously we could do better, so if you have lots of money and are interested in making free software PDF rendering beter please hire someone to help us (no, this is not me asking for money, I've a good enough job already).
And if you don't have money but you have some free time and like to help, join us :)
And if you really really have some free time or lots of money you could port Okular, Evince et al to pdfium and see if it's actually better/worse than poppler.
No, I don't get paid for the work i do on Poppler.
It's my computing hobby, and on top of that it's not even my "primary" computing hobby, lots of KDE stuff take precedence over it, and i guess Gnome stuff may also take precedence for Carlos (second top commiter according to the git shortlog)
Aside a few paid contributions and some patches that may have come from people that use the software on their business (and we could file them under "paid" since they did the fix as part of their job) no one has a paid job that is mainly "work on poppler".
I guess we've done a good enough job as hobbyist :)
Obviously we could do better, so if you have lots of money and are interested in making free software PDF rendering beter please hire someone to help us (no, this is not me asking for money, I've a good enough job already).
And if you don't have money but you have some free time and like to help, join us :)
And if you really really have some free time or lots of money you could port Okular, Evince et al to pdfium and see if it's actually better/worse than poppler.
Tuesday, November 15, 2016
Finding a valid build order for KDE repositories
KDE has been lately been growing quite a bit in repositories, and it's not always easy to tell what needs to be build before, do i build first kdepim-apps-libs or pimcommon?
A few days ago i was puzzled by the same question and realized we have the answer in the dependency-data-* files from the kde-build-metadata repository.
They define what depends on what so what we need to do is just build a graph with those dependencies and get a valid build order from it.
Thankfully python already has a module for graphs and stuff so build-order.py was not that hard to write.
So say you want to know a valid build order for the stable repositories based on kf5-qt5
Here it is
Note i've been saying *a* valid build order, not *the* valid build order, since there are various orders that are valid since not every repo depends other repos.
Now i wonder, does anyone else find this useful? And if so to which repository do you think i should commit such script?
A few days ago i was puzzled by the same question and realized we have the answer in the dependency-data-* files from the kde-build-metadata repository.
They define what depends on what so what we need to do is just build a graph with those dependencies and get a valid build order from it.
Thankfully python already has a module for graphs and stuff so build-order.py was not that hard to write.
So say you want to know a valid build order for the stable repositories based on kf5-qt5
Here it is
Note i've been saying *a* valid build order, not *the* valid build order, since there are various orders that are valid since not every repo depends other repos.
Now i wonder, does anyone else find this useful? And if so to which repository do you think i should commit such script?
KDE Applications 16.12 branches created
The dependency freeze for KDE Applications 16.12 is on since November 10
For all repositories part of the KDE Applications 16.12 release the Applications/16.12 branch has been created.
The list of modules+branches that will be part of the release is at https://cgit.kde.org/sysadmin/release-tools.git/tree/modules.git?h=Applications/16.12
Please make sure the list is correct. If it's not please email release-team at kde.org *NOW*
From now on master is open for feature changes, but remember that all your fixes also should get to the Applications/16.12 branch (my suggestion, commit fixes to Applications/16.12 and then merge that branch to master)
KDE Applications 16.12 Beta (version number 16.11.80) will be tagged November 17 at 23:59 UTC
Once the Beta is tagged no more features can be added.
For all repositories part of the KDE Applications 16.12 release the Applications/16.12 branch has been created.
The list of modules+branches that will be part of the release is at https://cgit.kde.org/sysadmin/release-tools.git/tree/modules.git?h=Applications/16.12
Please make sure the list is correct. If it's not please email release-team at kde.org *NOW*
From now on master is open for feature changes, but remember that all your fixes also should get to the Applications/16.12 branch (my suggestion, commit fixes to Applications/16.12 and then merge that branch to master)
KDE Applications 16.12 Beta (version number 16.11.80) will be tagged November 17 at 23:59 UTC
Once the Beta is tagged no more features can be added.
Sunday, October 23, 2016
KDE Applications 16.12 Schedule finalized
It is available at the usual place https://community.kde.org/Schedules/Applications/16.12_Release_Schedule
Dependency freeze is in 2.5 weeks and Feature Freeze in 3.5 weeks, so hurry up!
Dependency freeze is in 2.5 weeks and Feature Freeze in 3.5 weeks, so hurry up!
Tuesday, August 30, 2016
I'm going to Akademy :)
I'm coming back home on Tuesday afternoon-ish so if you want to catch me for something be sure to make it before then :)
See you in Berlin!
Saturday, July 02, 2016
KDE Applications 16.08 Schedule finalized
It is available at the usual place https://community.kde.org/Schedules/Applications/16.08_Release_Schedule
Dependency freeze is in 2 weeks and Feature Freeze in 3 weeks, so hurry up!
Dependency freeze is in 2 weeks and Feature Freeze in 3 weeks, so hurry up!
Tuesday, May 03, 2016
Akademy 2016 travel support
If you want to attend Akademy 2016 but are a bit short on money, that is no excuse :)
Read https://mail.kde.org/pipermail/kde-community/2016q2/002758.html for more info on how the KDE e.V. can help you!
Read https://mail.kde.org/pipermail/kde-community/2016q2/002758.html for more info on how the KDE e.V. can help you!
Friday, March 11, 2016
Workaround for trouble with updating akonadi tables
I was just updating the Kubuntu packages that move from akonadi 15.08 to 15.12.1 and sadly akonadi failed to migrate with this error
Adding new foreign key constraints
"ALTER TABLE PimItemFlagRelation ADD FOREIGN KEY (PimItem_id) REFERENCES PimItemTable(id) ON UPDATE CASCADE ON DELETE CASCADE"
Updating index failed:
Sql error: Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`#sql-6ea8_3`, CONSTRAINT `#sql-6ea8_3_ibfk_1` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) QMYSQL: Unable to execute query
Query: ALTER TABLE PimItemFlagRelation ADD FOREIGN KEY (PimItem_id) REFERENCES PimItemTable(id) ON UPDATE CASCADE ON DELETE CASCADE
""
Unable to initialize database.
Bug 354536 will be fixed with the akonadi 15.12.3 release next week.
Lucky meanwhile amazing Dan was ready to help me workaround the issue.
You need to start mysql (if that's what you're using as akonadi backend)
mysqld --defaults-file=$HOME/.local/share/akonadi/mysql.conf --datadir=$HOME/.local/share/akonadi/db_data --socket=/tmp/akonadi-mysql.socket
then connect to it
mysql -S /tmp/akonadi-mysql.socket
And run a series of sql commands
http://paste.ubuntu.com/15344766/
After that shut down mysql
mysqladmin -S /tmp/akonadi-mysql.socket shutdown
And start akonadi and you should be golden again
akonadictrl start
Adding new foreign key constraints
"ALTER TABLE PimItemFlagRelation ADD FOREIGN KEY (PimItem_id) REFERENCES PimItemTable(id) ON UPDATE CASCADE ON DELETE CASCADE"
Updating index failed:
Sql error: Cannot add or update a child row: a foreign key constraint fails (`akonadi`.`#sql-6ea8_3`, CONSTRAINT `#sql-6ea8_3_ibfk_1` FOREIGN KEY (`PimItem_id`) REFERENCES `pimitemtable` (`id`) ON DELETE CASCADE ON UPDATE CASCADE) QMYSQL: Unable to execute query
Query: ALTER TABLE PimItemFlagRelation ADD FOREIGN KEY (PimItem_id) REFERENCES PimItemTable(id) ON UPDATE CASCADE ON DELETE CASCADE
""
Unable to initialize database.
Bug 354536 will be fixed with the akonadi 15.12.3 release next week.
Lucky meanwhile amazing Dan was ready to help me workaround the issue.
You need to start mysql (if that's what you're using as akonadi backend)
mysqld --defaults-file=$HOME/.local/share/akonadi/mysql.conf --datadir=$HOME/.local/share/akonadi/db_data --socket=/tmp/akonadi-mysql.socket
then connect to it
mysql -S /tmp/akonadi-mysql.socket
And run a series of sql commands
http://paste.ubuntu.com/15344766/
After that shut down mysql
mysqladmin -S /tmp/akonadi-mysql.socket shutdown
And start akonadi and you should be golden again
akonadictrl start
Wednesday, February 10, 2016
KDE Applications 16.04 Schedule finalized
It is available at the usual place https://techbase.kde.org/Schedules/Applications/16.04_Release_Schedule.
Dependency freeze is in 4 weeks and Feature Freeze in 6 weeks, so hurry up!
Dependency freeze is in 4 weeks and Feature Freeze in 6 weeks, so hurry up!
Sunday, September 27, 2015
KDE dinner in Berlin - October 3
This weekend the KDE e.V. board is going to have an in-person board meeting in Berlin.
We would like you to join us for dinner on Saturday 3 around 19:00 (location still undecided, suggestions accepted).
If you are interested in talking about KDE, KDE e.V., Free Software, Open Source, today's elections in Catalonia or any other random talk and want to have a good time let me know that you're coming (latest by Wednesday night).
We would like you to join us for dinner on Saturday 3 around 19:00 (location still undecided, suggestions accepted).
If you are interested in talking about KDE, KDE e.V., Free Software, Open Source, today's elections in Catalonia or any other random talk and want to have a good time let me know that you're coming (latest by Wednesday night).
Saturday, September 26, 2015
September 26: SystemSettings and KCMs bug triaging day!
Today/Tomorrow September 26 is SystemSettings and KCMs bug triaging day.
As described by Jeremy in this post in the KDE Gardening mailing list the purpose is:
1. Triage all bugs in the systemsettings product (and maybe the kcm product too).
2. If a bug is reproducible still, comment on it and find someone that knows how to fix it and convince them to do so.
3. Find maintainers for as many of the kcms as we can.
This is something anyone with a relatively new Plasma installed can help with so join us on September 26 at the #kde-devel IRC channel!
Personally I'll be on from 10am Spanish time until around 4pm with some lunch time in between.
More info at the gardening wiki for SystemSettings
As described by Jeremy in this post in the KDE Gardening mailing list the purpose is:
1. Triage all bugs in the systemsettings product (and maybe the kcm product too).
2. If a bug is reproducible still, comment on it and find someone that knows how to fix it and convince them to do so.
3. Find maintainers for as many of the kcms as we can.
This is something anyone with a relatively new Plasma installed can help with so join us on September 26 at the #kde-devel IRC channel!
Personally I'll be on from 10am Spanish time until around 4pm with some lunch time in between.
More info at the gardening wiki for SystemSettings
Tuesday, August 18, 2015
Using git the proper way for correct release changelogs
If you look at kdenlive's changelog for KDE Applications 15.08 and for KDE Applications 15.04.3 you'll see that "Fix autosave not working when opening project file from command line or click in file browser" shows up in both.
On the other hand if you have a look at gwenview, in 15.04.3 it shows "Make saving thumbnails work again" while it's not part of 15.08.
Does that mean that this bug got lost?
No, gwenview is actually the correct thing, we should not mention a bug again for 15.08 if it was released in 15.04.3, since well it's been released already :D
So why does kdenlive, marble and others show commits in the two places?
Because their developers are not doing the proper git-thing of commiting to the oldest supported branch and then merging up to master, so for git it's two different commits instead of the same (in case of the kdenlive commit in question it'd be https://quickgit.kde.org/?p=kdenlive.git&a=commit&h=cc55a9cea5c2f029744f8aba79a362fd302ec0bb and https://quickgit.kde.org/?p=kdenlive.git&a=commit&h=28b3cc7b5141fcc2fed84433b9fe9851c35b7e08).
Commiting the fix to the oldest supported branch and then merging up has lots of other benefits (like making sure you never forget a fix in master), but maybe this is the one that finally convinces more devs to switch to it, nicer changelogs ;)
On the other hand if you have a look at gwenview, in 15.04.3 it shows "Make saving thumbnails work again" while it's not part of 15.08.
Does that mean that this bug got lost?
No, gwenview is actually the correct thing, we should not mention a bug again for 15.08 if it was released in 15.04.3, since well it's been released already :D
So why does kdenlive, marble and others show commits in the two places?
Because their developers are not doing the proper git-thing of commiting to the oldest supported branch and then merging up to master, so for git it's two different commits instead of the same (in case of the kdenlive commit in question it'd be https://quickgit.kde.org/?p=kdenlive.git&a=commit&h=cc55a9cea5c2f029744f8aba79a362fd302ec0bb and https://quickgit.kde.org/?p=kdenlive.git&a=commit&h=28b3cc7b5141fcc2fed84433b9fe9851c35b7e08).
Commiting the fix to the oldest supported branch and then merging up has lots of other benefits (like making sure you never forget a fix in master), but maybe this is the one that finally convinces more devs to switch to it, nicer changelogs ;)
Sunday, August 09, 2015
KDE Workspaces 4.11 End of Life this August
Back in August 2013 we promised to do Long Term Support for kde-workspace for 2 years.
This means this August is the last release for kde-workspace (coming with KDE Applications 15.08.0).
Of course, we can extend the releases if anyone has a strong reason.
If you do, head to the release-team mailing list!
This means this August is the last release for kde-workspace (coming with KDE Applications 15.08.0).
Of course, we can extend the releases if anyone has a strong reason.
If you do, head to the release-team mailing list!
Sunday, August 02, 2015
rsibreak port to KF5 started!
I just started the port of rsibreak to KF5.
Contributions at http://quickgit.kde.org/?p=rsibreak.git
Contributions at http://quickgit.kde.org/?p=rsibreak.git
Saturday, August 01, 2015
Akademy 2015 and Akademy-es 2015 recap
I'm back home after more than a week of talks and hacking in the beautiful city of A Coruña.
There I attended Akademy, the international conference of the KDE Community, and Akademy-es, it's Spanish counterpart.
First off I'd like to thank the local organization, GPUL, that as always has done an amazing job in hosting us, repeating the success of Guademy, Akademy-es 2008, KDE-EDu sprint, etc.
Also kudos to the Scottish-Kenny duo, top notch organizing work as always.
Finally thanks to the both Akademy and Akademy-es sponsors. Specially Qindel, that sponsored us for the first time, hope we can continue the relationship in the future.
The talks this year were specially interesting, I attended some good BoFs on releasing and translation infrastructure, hopefully some improvements coming your way soon :)
Of course not everything is perfect and my biggest pain point this year was that we did not have as much people in Akademy-es as we expected. Akademy-es happened the 2 days before Akademy and this meant that lots of local people from the organization team were helping set up the place instead of attending the talks; also on Friday some of us (I count at least 8) were attending the KDE e.V. General Assembly so couldn't attend Akademy-es either. Definitely something to think about and improve next time Akademy and Akademy-es happen at the same place.
But all in all pretty positive experience as always, nice to meet so many KDE people :)
There I attended Akademy, the international conference of the KDE Community, and Akademy-es, it's Spanish counterpart.
First off I'd like to thank the local organization, GPUL, that as always has done an amazing job in hosting us, repeating the success of Guademy, Akademy-es 2008, KDE-EDu sprint, etc.
Also kudos to the Scottish-Kenny duo, top notch organizing work as always.
Finally thanks to the both Akademy and Akademy-es sponsors. Specially Qindel, that sponsored us for the first time, hope we can continue the relationship in the future.
The talks this year were specially interesting, I attended some good BoFs on releasing and translation infrastructure, hopefully some improvements coming your way soon :)
Of course not everything is perfect and my biggest pain point this year was that we did not have as much people in Akademy-es as we expected. Akademy-es happened the 2 days before Akademy and this meant that lots of local people from the organization team were helping set up the place instead of attending the talks; also on Friday some of us (I count at least 8) were attending the KDE e.V. General Assembly so couldn't attend Akademy-es either. Definitely something to think about and improve next time Akademy and Akademy-es happen at the same place.
But all in all pretty positive experience as always, nice to meet so many KDE people :)
Subscribe to:
Posts (Atom)