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