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
Subscribe to:
Posts (Atom)
