KDE Plasma 5 Hits Testing!

Jeebizz · 11-07-2020, 08:50 PM

Keep in mind if you are running Vtown (or even Ktown) in --Current and even did not include KDE4 in your --Current install - the older Akonadi in L-Series is still installed unless you did an expert install or remembered to remove it later on. Also that brings up something interesting, if all the Plasma5 deps will go in L. I personally think the deps and KDE should just be in the KDE folder when it is merged (or VTown) - if Pat decides to just keep that name

.

chrisretusn · 11-07-2020, 09:01 PM

As far a akonadi is concerned. It matters not that is was an 'L' series package. It should have been over written by the newer vtown akonadi if the directions in the read me or from Eric's blog comments were followed. Which also has me wondering what other things @gargamel might have missed.

volkerdi · 11-07-2020, 10:41 PM

Quote:

Originally Posted by Jeebizz

Also that brings up something interesting, if all the Plasma5 deps will go in L. I personally think the deps and KDE should just be in the KDE folder when it is merged (or VTown) - if Pat decides to just keep that name

.

They'll probably go in L. Don't want anything in the KDE series (yes, it will keep that name) that might become a dependency of something else outside of it. Not that the whole series thing has ever guaranteed anything, but it's safer that way.

denydias · 11-08-2020, 02:01 AM

Quote:

Originally Posted by bassmadrigal

You could add a really simple command to the rc.local_shutdown to verify... something like:

Code:

touch /local_shutdown-works

This would create a text file in the root partition and you could verify whether or not it is there on the next startup.

Thanks! I knew the trick...

I left it there to touch /var/log/last_shutdown so I can keep track if it ever stop working by comparing with $(last) output.

I could confirm /etc/rc.d/rc.local_shutdown is running upon shutdown or restart with plasma, even that its output is not displayed in tty1. In fact, after X is gone, you could hit CTRL+ALT+F7 to bring tty7 up. If you're fast enough, rc.local_shutdown output (if any) will be there.

Thanks again, @ZhaoLin1457 for pointing that out.

walecha · 11-08-2020, 04:54 AM

Quote:

Originally Posted by drgibbon

I meant that doing `ntpdate pool.ntp.org` from a terminal should set your system time correctly, and Plasma should follow that.

Regardless, I think something must be borked with authenticating to superuser through Plasma, since the "Set date and time automatically" option does not work for me either.

I don't have ConsoleKit2 installed either, but the "Set date and time automatically" option fails for me too (not that I need it, but still).

It's because of systemd. As part of systemd, elogind still follows some of systemd rules and that is including time keeping service (https://www.freedesktop.org/wiki/Sof...emd/timedated/). Gentoo OpenRC fixed this by emulating the systemd-timesyncd using openrc-settingsd.

LuckyCyborg · 11-08-2020, 05:16 AM

Quote:

Originally Posted by walecha

It's because of systemd. As part of systemd, elogind still follows some of systemd rules and that is including time keeping service (https://www.freedesktop.org/wiki/Sof...emd/timedated/). Gentoo OpenRC fixed this by emulating the systemd-timesyncd using openrc-settingsd.

There's a standalone timedate1 service for Slackware: https://github.com/Dlackware/slack-timedate

However, I do not found the need to use it, at least in the past, 'till present.

BUT, if the times changes, maybe someone could maintain/improve it.

Alien Bob · 11-08-2020, 06:02 AM

Quote:

Originally Posted by walecha

It's because of systemd. As part of systemd, elogind still follows some of systemd rules and that is including time keeping service (https://www.freedesktop.org/wiki/Sof...emd/timedated/). Gentoo OpenRC fixed this by emulating the systemd-timesyncd using openrc-settingsd.

It's got nothing to do with systemd. If you look at the popup when your mouse hovers over the "set date and time automatically" you'll notice the message "can not find ntpdate". That is caused by ntpdate only being in root's $PATH.
I created a symlink /usr/bin/ntpdate which points to /usr/sbin/ntpdate and now the tool finds ntpdate. I can check that box and Plasma5 pops up a request for the root password. Done.

LuckyCyborg · 11-08-2020, 06:06 AM

Quote:

Originally Posted by Alien Bob

It's got nothing to do with systemd. If you look at the popup when your mouse hovers over the "set date and time automatically" you'll notice the message "can not find ntpdate". That is caused by ntpdate only being in root's $PATH.
I created a symlink /usr/bin/ntpdate which points to /usr/sbin/ntpdate and now the tool finds ntpdate. I can check that box and Plasma5 pops up a request for the root password. Done.

BUT, setting the system's date and time should be the exclusive business of root account, right?

I believe that Plasma5 shouldn't even present options to change date/time to unprivileged users.

gmgf · 11-08-2020, 06:25 AM

Quote:

Originally Posted by LuckyCyborg

BUT, setting the system's date and time should be the exclusive business of root account, right?

I believe that Plasma5 shouldn't even present options to change date/time to unprivileged users.

it's the case, because it use kdesu, here.

Jimmy Johnson · 11-08-2020, 06:35 AM

Quote:

Originally Posted by cwizardone

It's here!

Read all about it at,
http://slackware.oregonstate.edu/sla.../ChangeLog.txt

I've done the switch on three machines without any real problems, just followed Eric's instructions, thank you Eric for all the work you've put into this project.

Who ever ports a fixed and working "KDF" to KDE5 will become a Jedi Rock Star.

But a broken kdf is better than none.

And yes, I know we can mount using dolphin, but as a linux tester I have a dozen partitions all the same size and it seems that size is the only description dolphin gives and a pain it is.

May the Force be with you!

LuckyCyborg · 11-08-2020, 06:49 AM

Quote:

Originally Posted by Alien Bob

It's got nothing to do with systemd. If you look at the popup when your mouse hovers over the "set date and time automatically" you'll notice the message "can not find ntpdate". That is caused by ntpdate only being in root's $PATH.
I created a symlink /usr/bin/ntpdate which points to /usr/sbin/ntpdate and now the tool finds ntpdate. I can check that box and Plasma5 pops up a request for the root password. Done.

Well, I've just asked some friends of mine to take a quick look on this possible wrong behavior, and they said that Slackware have the ntpdate tool in an, let's say... uncommon path.

Also they suggested a quick patch for plasma-desktop v5.20, as in to change plasma-desktop-5.20.2/kcms/dateandtime/helper.cpp on line 71, from:

Code:

    QString ntpUtility = QStandardPaths::findExecutable(QStringLiteral("ntpdate"));

to:

Code:

    QString ntpUtility = QStandardPaths::findExecutable(QStringLiteral("ntpdate"), exePath.split(QLatin1Char(':')));

This will make the helper to look for ntpdate also into /sbin and /usr/sbin and most likely will find it.

This is the patch:

Code:

diff -urN plasma-desktop-5.20.2.orig/kcms/dateandtime/helper.cpp plasma-desktop-5.20.2/kcms/dateandtime/helper.cpp
--- plasma-desktop-5.20.2.orig/kcms/dateandtime/helper.cpp      2020-10-27 14:23:48.000000000 +0200
+++ plasma-desktop-5.20.2/kcms/dateandtime/helper.cpp   2020-11-08 14:52:13.812091405 +0200
@@ -68,7 +68,7 @@
     config.writeEntry("servers", ntpServers );
     config.writeEntry("enabled", ntpEnabled );
 
-    QString ntpUtility = QStandardPaths::findExecutable(QStringLiteral("ntpdate"));
+    QString ntpUtility = QStandardPaths::findExecutable(QStringLiteral("ntpdate"), exePath.split(QLatin1Char(':')));
     if (ntpUtility.isEmpty()) {
         ntpUtility = QStandardPaths::findExecutable(QStringLiteral("rdate"));
     }

Maybe also "rdate" should get the same way of looking for.

PS. I've just built the plasma-desktop package with this patch applied and looks like Plasma5 finds the ntpdate as unprivileged user, even from /usr/sbin .

gargamel · 11-08-2020, 07:24 AM

Quote:

Originally Posted by chrisretusn

akonadi-1.13.0-i586-16 should have been replace by akonadi-20.08.2-i586-1_vtown_1.txz
kde-runtime-4.14.3-i586-8 is still part of the slackware tree and should have been removed when you removed kde from slackware.

Ah, thanks, right. I guess manually deleting akonadi before installing vtown wasn't necessary, then.
Regarding kde-runtime, I see that there are also some other KDE4 packages left over in vtown, e.g. qtruby and, of course, qt4. I didn't check that, because I thought everything qt4 and KDE4 had been eliminated already after reading the changelog of 3rd Nov., 2020:

"...Qt4 won't even be sticking around..."

So, I could have known the above, if I just hadn't been too lazy to check out... Thanks again!

sombragris · 11-08-2020, 10:24 AM

Quote:

Originally Posted by Jimmy Johnson

Not happy with kpat missing.

Me neither and I suspect many others feel that way, also. But it's Pat call and I respect and trust his judgment.

However, this shouldn't detract us from stepping forward and providing the relevant SlackBuilds. Speaking generically, the ideal way forward would be to have something like SBo but for Plasma5 packages. We can't use SBo since it's based on stable 14.2 which do not have Plasma5, so there are lots of applications which can not be included there. In my case, I have working SlackBuilds for ksnip, which is a great screenshoot app, but whose inclusion in Slackware would be very doubtful since it also carries two additional dependencies.

Eric did a superb job including most applications needed for daily use with Plasma5, so this need was not as acute before as it is now

It would be very nice and, as I said, I would be willing to contribute a SlackBuild of a very interesting app with its dependencies.

walecha · 11-08-2020, 10:43 AM

Quote:

Originally Posted by Alien Bob

It's got nothing to do with systemd. If you look at the popup when your mouse hovers over the "set date and time automatically" you'll notice the message "can not find ntpdate". That is caused by ntpdate only being in root's $PATH.
I created a symlink /usr/bin/ntpdate which points to /usr/sbin/ntpdate and now the tool finds ntpdate. I can check that box and Plasma5 pops up a request for the root password. Done.

In my case, it's not about using ntp* to sync the clock (I'm using ntpd to keep the clock sync), but to change timezone from the desktop.

gmgf · 11-08-2020, 11:02 AM

Quote:

Originally Posted by walecha

In my case, it's not about using ntp* to sync the clock (I'm using ntpd to keep the clock sync), but to change timezone from the desktop.

this work perfectly here