I had already finished compiling KDE-5_19.10 and was waiting for the Plasma 5.17 public release announcement, when Pat upgraded libdvdread in slackware-current. That could mean trouble because of the dreaded ‘Shared library .so-version bump‘ message.
But he added the older libdvdread.so.4 library to aaa_elflibs so that the k3b program in Plasma5 does not break, and hopefully it remains in there until after I recompile k3b (which ultimately happens for the Plasma5 November release).
Unfortunately the earlier update of the ‘icu4c’ package broke some other stuff in Plasma5 as well. Be sure to install my ‘icu4c-compat‘ package, which contains the libraries from several older icu4c packages. Read my older article on ‘shared library .so version bumps‘ if you have not already done so, to understand the causes for this breakage.
The packages for KDE-5_19.10 are available for download from my ‘ktown‘ repository. As always, these packages are meant to be installed on a full installation of Slackware-current which has had its KDE4 removed first. These packages will not work on Slackware 14.2.
What’s new in the October 2019 release
This month’s KDE Plasma5 for Slackware contains the KDE Frameworks 5.63.0, Plasma 5.17.0 and Applications 19.08.2. All this on top of Qt 5.13.1.
Deps:
The ‘cracklib’ package got a version bump, and the latest ‘phonon’ and ‘phonon-vlc’ releases have been packaged.
The telepathy dependencies have been removed completely. Indeed, the feedback on my question in the README for last month’s ‘ktown’ release made clear that no one uses KDE Telepathy. For me it never worked anyway, so this month we say good-bye to KDE Telepathy and its dependencies.
Note that ‘qt5’ and ‘qt5-webkit’ should really be recompiled to fix the icu4c broken dependency, but I do not have the time right now, and the icu4c-compat package will take care of this anyway. Soon, though.
Frameworks:
Frameworks 5.63.0 is a regular update release. See: https://www.kde.org/announcements/kde-frameworks-5.63.0.php, but there is something worth mentioning still: the packages ‘kcalcore’ and ‘kcontacts’ which were part of KDE Applications and which you would find in the kde/kdepim section of my ‘ktown’ repository, have moved to the KDE Frameworks. As part of this move, ‘kcalcore’ was also renamed to ‘kcalendarcore’.
Plasma:
Plasma 5.17.0 is the start of a new release cycle of the Desktop part of KDE. See https://www.kde.org/announcements/plasma-5.17.0.php. Some take-aways from the release notes: the Plasma startup script (/usr/bin/startkde) which was traditionally a bash script has been replaced with a C++ program which is faster than the interpreted shell script code, and also starts the various services in parallel. The devs claim that Plasma5 desktop starts up a lot faster as a result. Do you feel the same?
Chrome/Chromium should blend in more with the Breeze theme and GTK applications should have the KDE color scheme applied. There’s more to read, just follow the above link.
Plasma-extra;
I updated ‘latte-dock’ which is my default application launcher here on the laptop for a couple of months now.
Note that ‘sddm-qt5’ should really be recompiled against the new icu4c in slackware-current, but like with qt5, my ‘icu4c-compat’ package will fix the breakage for now. This one is on my TODO list for next week.
Applications;
Applications 19.08.2 is a stability and bug-fix update for the 19.08 cycle. For more information, see https://www.kde.org/announcements/announce-applications-19.08.2.php and you may still want to visit the original release notes for 19.08.0 as well.
Applications-extra:
I upgraded ‘digikam’, ‘libktorrent’, ‘ktorrent’, ‘alkimia’, ‘kmymoney’, ‘kpmcore’, ‘krita’, ‘okteta’, and the development suite ‘kdevelop’, ‘kdev-php’ and and ‘kdev-python’ to their latest releases.
Telepathy:
KDE Telepathy is no longer part of my ‘ktown’ distribution of KDE Plasma5.
Where to get it
Download the KDE-5_19.10 from the usual location at https://slackware.nl/alien-kde/current/latest/ . Check out the README file in the root of the repository for detailed installation or upgrade instructions.
Development of Plasma5 is tracked in git: https://git.slackware.nl/ktown/ .
A new Plasma5 Live ISO has been uploaded and you will find it at https://slackware.nl/slackware-live/latest/ (rsync://slackware.nl/mirrors/slackware-live/latest/)
Have fun! Eric
Using run level 4 in /etc/inittab. Wayland-Plasma5 works! Hurray! I like the Night Color feature.
Now, if I can only figure out how to disable the laptop touchpad when the usb wireless mouse is plugged in…. Tracked down the touchpad to /dev/input/event6. Working on finding the qdbus path to turn it off. (Don’t tell me, having fun learning stuff along the way.)
Here’s hoping we can drop X11 by Slackware 15.
Great job, Master Hameleers!
Solved the touchpad issue. I can get by without the Cube Animation when switching desktops.
I began reading the stack of X11 manuals in 1991. Now I can forget everything and start learning wayland. Forgetting is getting a lot easier after I retired.
Hi Eric,
I’m getting an xkbcomp error – X11 can’t support keycodes above 255 : ) It’s saying Unsupported high keycode 372 for name ignored….X / Plasma won’t start.
After installing KDE-5_19.10 , I stupidly ran ‘slackpkg clean-system’, and allowed it to uninstall ‘libKF5CalendarCore’. I thought it would be in either akonadi-calendar or akonadi-calendar-tools. Tried reinstalling both of them, didn’t work. So I said, let’s do a ‘slackpkg remove ktown’, and reinstall. Did that, and now I have the same problem as Owen, plus startx can’t find startkde. I haven’t given up yet. 😉
“Couldn’t exec startkde: No such file or directory”. Xfce runs fine, of course.
I also apologize for missing “As part of this move, ‘kcalcore’ was also renamed to ‘kcalendarcore’. I guess that’s what slackpkg must have missed as well, which is probably why libKF5CalendarCore went missing after I ran ‘slackpkg clean-system’. If I had read the above, I wouldn’t have let slackpkg remove the “missing” package. Whew, what a night.
K. Setting initdefault to 4 in /etc/inittab, and replacing startkde with startplasma-x11 in /etc/X11/xinit/xinitrc.plasma has me back in KDE. Don’t know why running ‘startx’ from runlevel 3 tells me it can’t find startkde. Anyway, at least I can sleep tonight. 😉
Last one, I promise. When KDE *does* start, it starts a lot faster. By a factor of 2, I’d guess. Maybe three. 😉
Howdy Kids!
I followed Richards path of changing initdefault to 4, also changed the xinitrc.plasma file to startplasma-x11. That by itself did not bring up KDE….I did however, comment out three lines in the evdev file, which can be found in /etc/X11/xkb/keycodes/evdev
I commented out three lines near the bottom of the file:
Rebooted, and KDE came up, so far no problems.
ARGH! It removed the three lines because of Brackets….the three lines in the evdev file are:
I372 = 372 KEY_Favorites
I382 = 382 KEY_KEYBOARD
I569 = 569 KEY_ROTATE_LOCK_TOGGLE
Are you folks making sure you install all the packs that are needed? Assuming y’all are using slackpkg+…
I find sometimes it’s best to run “slackpkg install ktown” after upgrade-all, and if new packages are selected, only deselect them if you’re certain they aren’t required for something you need.
Thanks for the update AlienBob! I’ll try tomorrow. I can’t say I’m sad to see telepathy go… Now I can clean out my greylist file a wee bit!
Poprocks – I install ktown by hand by downloading it via rsync and running the upgradepkg commands in the README file. I also use slackpkg+, but mostly for upgrading the slackware64-current and alienbob repositories, and any post-monthly-release updates to ktown. Most of my problems came from uninstalling kcalcore (or was it kcalendarcore), and the changes that were required to point xinitrc.plasma to startplasma-x11 instead of startkde. Way too late now to start any more investigations; I already lost my ability to read. 😉
I should also mention, I also install Eric’s icu4u-compat to mske the other error go away : )
Ahh, I figured maybe the script (err binary now) filename had changed. That makes sense. I’ll look out for it tomorrow. You’d think they’d keep startkde as a symlink though.
Hi Eric.
Thanks again for all this updates and your great contribution to slackware.
I only found a problem regarding shared lib: libicui18n.so.64 not found. startkde also was not found.
I looked for a package containing that library:
slackpkg file-search libicui18n.so.64
and installed:
slackpkg install icu4c-compat-65.1-x86_64-1alien
Everything seems normal now… happy having the latest kde!.
Thanks again Eric.
Hi Eric
Thanks as usual for a fantastic release. I have 1 small issue where GTK apps does not respect the GTK themes settings. I use breeze dark for my global theme but set GTK apps to breeze only. But somehow, GTK apps always stay on breeze dark. This only started with the latest kde update. Any ideas.
Thanks, Robby
Eric: Under VirtualBox 6.0.14 your 191014 live-plasma5-current ISO boots asis OK — as does the 191014 live-mate -current ISO.
Alas the 191014 live-current ISO fails here: ‘Starting up X11 session manager…’ (10x) followed by ‘INIT: Id “x1” respawning too fast: disabled for 5 minutes’.
Kind regards, Dick
In addition to my above report I can state that the 190612 of the live-current ISO boots asis OK under VirtualBox 6.0.14.
Under VirtualBox 6.0.12 I see the same results: 190612 OK, 191014 failure.
I then dd’ed the 101014 live-current ISO to a USB stick. Booting that stick showed the same problem.
Regards, Dick
😀
And don’t forget to run xwmconfig as your normal user after correcting /etc/X11/xinit/xinitrc.plasma. This way, ~/.xinitrc will be updated with the correct parameters (startplasma-x11), and you’ll be able to run startx from the command line in runlevel 3 to launch KDE. I agree that keeping startkde as a symlink would have been a good idea, at least in the short term.
Don’t need startkde.
As root, `vim /etc/inittab`, change
id:3:initdefault:
to id:4:initdefault:
Reboot and log in. Before logging in, the upper left pull-down menu lets you choose
plasma-wayland
If you need a runlevel 3 environment, press Ctl-Alt-F2 and log in, or just open konsole full-screen in another virtual desktop.
Hi Eric, and thanks for all your hard work. The latest update runs perfectly on my two desktop machines – thanks to the contributors here, I installed a symlink to “startplasma-x11” from “startkde”.
However, my laptop is proving slightly more problematic. It starts fine, but when I try and shutdown or reboot from kde5 (using the widget for the panel), I get the shutdown chime, running programs close, but then everything just stops. My desktop is there, but not doing anything, and the mouse cursor moves, but can’t activate anything.
Using ctl-alt-backspace gets me back to sddm from where I can shutdown normally.
It has only done this since the latest update. The only difference between the laptop and desktop machines is that I was unable to load Slackware64-current onto the laptop from the Slackware media. It wouldn’t boot. I had to install your Slack-live on the drive, and then point slackpkg plus at Slackware64-current and kde5 and “upgrade”.
As I understand it, this *should* have made my install effectively the same as from Slackware media, other than a few additions. However, it looks as if something is slightly different, and has broken the shutdown/logout icon on the latest release.
Not critical, but any hints much appreciated!
—
Pete
Thanks to the OP in this thread, who traced the problem to skypeforlinux: https://www.linuxquestions.org/questions/showthread.php?p=6048821#post6048821
Also, thanks to Eric for providing an alternative way of accessing skype, further down the same thread!
🙂
—
Pete
Bother! Spoke too soon! Skype for Web doesn’t support chromium – only chrome, so it won’t work with Eric’s Chromium packages.
—
Pete
When you know you aren’t the only one …
https://bugs.archlinux.org/task/64139
I am maintaining two *64-current installs now. One with KDE5/Plasma5 and one still running KDE4 which I did a total upgrade on last night. FYI I needed to install the new icu4c-compat-65.1-x86_64-1alien. This fixed my Teamviewer app which broke after the upgrade as you predicted it might. I may hold off on upgrading Plasma5 -current till I read through and understand all the above issues a bit more. Looks like Poprocks and Richard H have it figured it out though. Thanks all for the comments everyone!
I did a full upgrade of my *64-current with Plasma5 (slackpkg+) and everything went smoothly. Thanks to previous posts I was keen to fix the issue with xinitrc (still pointing to xinitrc.kde which went bye-bye) –> xinitrc.plasma. I also pre-installed your icu4c-compat-65.1-x86-64-1alien package. This system hadn’t been updated since late September 22 and it was running with the kernel 4.19.73.
Not sure why the inittab gets rewritten and reverts to run level 3??? Did you do this knowing xinitrc was broken?
Thanks Eric for your great work keeping Plasma5/KDE5 updated. If and when Slackware 15 is released will it ship with ktown install option? I guess this will be something you will work out with Pat.
Hi Steve,
/etc/inittab is part of sysvinit-scripts-2.1-noarch-27 on my -current system, I don’t think Eric has fiddled with it 🙂
In my system at least, /etc/inittab didn’t get rewritten but I did get a /etc/inittab.new.
Maybe you inadvertently overwritten it when slackpkg asked about it?
Thanks for your input Recardo.
I don’t recall my slackpkg manager inquiring about this package but others here had commented about the same issue (Henry Pfiel and Richard Hebert) having to revert back to run level 4.
My sysvinit-scripts-2.1-noarch-27 wasn’t touched and this package only installs inittab.new *not* inittab. The mystery regarding inittab changing remains I am afraid.
Just for the sake of “historical accuracy”, my /etc/inittab wasn’t overwritten; I modified it to set inidefault to 3 because KDE wasn’t starting (after the startkde –> startplasma-x11 thingy), and I wanted to do some troubleshooting. I apologize for not being more specific about that in an earlier post. I never had an inittab.new because I replied R (remove) when slackpkg+ asked me what I wanted to do with it.
Eric – You wondered a few days ago in Linuxquestions if anyone was running Slackware-current and Plasma. WE are, the ones who are more than ready for it. So very much appreciated.
Upgraded to latest today on my desktop. No issues at all thus far. Thanks AlienBob!
Re: the starkde/startplasma-x11 kerfuffle – the .desktop files that ship with plasma-workspace in /usr/share/xsessions (for use with SDDM etc.) do contain the right exec lines to start Plasma 5.17. The problem is xinitrc.plasma (which I believe is a slackware-specific file) has not yet been updated to use the new startplasma-x11 binary. So either go ahead and change that xinitrc script by hand, or use SDDM for now until the xinitrc script gets updated.
Poprocks- Please see previous discussions about the possible (future) inclusion of KDE Plasma in Slackware. For the moment, xinitrc.plasma is Plasma-specific. It’s part of the Ktown packages.
Yes sorry – I just meant, it’s specific to Slackware/ktown and is not officially bundled with plasma-workspace or any other official KDE5 cruft.
Good to see that all of you are helping one another to get back on the rails.
Yes, the startkde -> startplasma-x11 switch was something I had fixed in my source tree, but this was accidentally reverted when I discarded some other research.
I will fix the plasma-workspace package to use the proper program (startplasma-x11) and will also recompile qt5, qt5-webkit and sddm-qt5 to pick up the new icu4c. That will take a while though, since free time is scarce.
Upgrading now… Thanks for this batch, Eric. I also thanks for others here who have figure out the initial issues.
I was wondering that you can add your build number id somewhere, maybe in kinfocenter dialog where we can read ‘packages by AlienBOB’. This will make very easy to us to identify what ktown build we’re running, which is something I can’t find at a glance right now. Or I’m looking in the wrong places.
My posts about ktown alwaqys mention something like:
“This month’s KDE Plasma5 for Slackware contains the KDE Frameworks 5.63.0, Plasma 5.17.0 and Applications 19.08.2. All this on top of Qt 5.13.1.”
Yeah, yeah! You mention that in your posts.
But the way it’s today, I open kinfocenter to check Plasma, Frameworks and Qt versions, then come here on your blog to compare those versions with the previous ktown announcement posts to declare “right, I’m in KDE-5_19.09 and need to upgrade to KDE-5_19.10”.
What I mean is to have a way to know which ktown version we’re running on our boxes, e.g.: “KDE-5_19.10 packages by AlienBOB” in kinfocenter. Easy peasy, right? 😉
It’s just as easy-peasy to check the versions of the packages that are installed locally!
Perhaps consider installing slackpkg+ if it is hard to track the state otherwise.
I already use slackpkg+. It does show me that I have things to update, including ktown (via ‘slackpkg upgrade ktown’).
I’m telling about a way to identify at a glance what ktown’s build number we are running. I’m sure you have already see that, but as you keep pointing out alternative solutions for this, I can understand there is no interest in the feature. I’ll refrain for more comments on this subject. Thanks anyway.
Thank you Eric. Upgraded here and no issues so far.
Thanks for the update Eric.
Found 2 bugs so far.
1. Audio setup in Kmix (or “configure phonon” in Amarok) does not launch.
2. SDDM theme can’t be changed. and it will be reset to its old default them, when you restart it.
Anyone else experiencing these problems?
There was a GSoC project to sync the user’s and SDDM’s themes.
IIRC it has to be user initiated (from system settings), but you might want to look into it.
Or maybe it’s a bug of the new implementation?
https://forum.kde.org/viewtopic.php?f=309&t=162576&p=422876&hilit=amarok#p422876
third post says “q4 phonon support was removed in the latest Phonon version…. Only Qt5 support remains”
Thank you for this new release. I think that a recompilation of calligra is also needed (/usr/lib64/qt5/plugins/calligrasheets/extensions/sheetssolver.so still uses libgsl.so.23)
It looks I am the only one (trying) to run the 191014 live-current (*non* plasma5 !) ISO.
Refer to my October 16, 2019 at 12:14 post.
😀
Hi burdi01,
I see the same issue – I have no idea what causes this but after I have finished building the Plasma5 packages that need a recompile, I will try to find the root cause and generate a new ISO.
In the meantime, I think it is best to just remove this ISO from the server.
I rebuilt the Slackware Live ISO yesterday and have uploaded it today. This ISO loads X properly. I have no idea what went wrong with the previous ISO; the new one was created in exactly the same way.
Downloaded and tested: OK !
Hartelijk dank, Dick
😀
All work here,Eric, just one think, Pat has updated sip in current 4.19.19 now, and libass can be updated too
https://github.com/sass/libsass/releases
Yeah I’ll upgrade my sip package too, so it is in sync again with Slackware’s version.
I think I found something too.
GTK2 apps do not seem to theme properly after the upgrade.
This is especially evident when using dark themes.
If anyone knows a workaround or solution I would be grateful.
Meanwhile, I’m stuck with using light theming.
Got a workaround, but It seems like there’s a bug in Plasma 5.17.
loks like systemsettings writes to ~/.gtkrc-2.0 and somehow amidst all of its customizations, it left an include file for a light teme which wreaked havoc on dark themes.
Since systemsettings did not clean up properly that file, it is a bug. Going to file now.
Hi @Eduardo I mentioned this earlier as an issue on my side as well. I’ve installed another GTK3 theme from Settings (mojave-light) which allows me have global dark theme but light for GTK apps … works fine.
FIled the bug. If you or anyone can comment confirming the bug it would be helpful:
https://bugs.kde.org/show_bug.cgi?id=413107
Thanks!
Done : )
Broken since upgrade icu4
If you mean, Plasma5 desktop is broken since the icu4c upgrade, why didn’t you install my icu4c-compat package then?
Hi Guys,
I stumbled across a head scratch’r…Dolphin will not show ANY Workgroups – I have the most dummied down smb.conf – I changed the Workgroup name & just one share. Smbtree reveals nothing – puzzled this old man is.
Thought I would share my finding in the latest update.
Owen
I would have to check on an older release of Slackware with Plasma5 but in the latest & greatest, I do not see my Samba server’s workgroup or shares either.
Since the release of KDE 5_19.10 I have rebuilt a number of packages to fix library incompatibilties and the missing startplasma-x11 references. Please update your local installation.
They are: qt5, qt5-webkit, sip, plasma-workspace, sddm-qt5, calligra, calligraplan, krita.
I just saw your post this morning. It appears I timed my upgrade perfectly! Curiously calligraplan was not updated. It must have been one of your last updates. The mirror I use for ktown is:
MIRRORPLUS[‘ktown’]=http://slackware.uk/people/alien-kde/current/latest/x86_64/
Eric,
It appears a few things have changed with Samba, SMB1 is gone, so the default is SMB2 – which breaks viewing shares and workgroups in File Managers – I can get to shares if I manually enter IP and folder name, or see shared folders with just smb://IP address.
Windows machines don’t / can’t see my Slackware machines but I can access Windows machines via the manual process mentioned above. Extra steps to see and get what you want.
Owen
Bit of confusion–on October 16, your log for ktown says that qt5 was rebuilt against the icu4c changes. This is the one for use with KDE5, not the qt5 here? http://www.slackware.com/~alien/slackbuilds/qt5/pkg64/current/
Yeah I still need to replace that one with a recompiled version. Same with qt5-webkit.
Oh wow, thanks for the qt5 package! Should I keep the icu4c-compat package installed? (Assuming all packages compiled against the old qt5 will need to be recompiled.)
Answered my own question. It can be removed. 🙂 No recompile of obs or the like needed.
Thanks Eric, for all your continuing efforts!
Did the upgrade to newer version having installed before the *compat* packages. Earlier today, i upgraded any rebuilt package too.
My impression is that new plasma starts noticeably faster. I can say that even gwenview loads faster than before – cannot guess why, maybe i am wrong here but in previous plasma versions, gwenview was a slow starter and now, definitely cannot say this.
Welcome back, yakuake! And latte dock is my new favourite!
Glad to see that amarok plays as fine as ever. It’s the only qt4 application i am still using and i cannot think of any good qt5 alternative.
Kmixer doesn’ t start for me either – so i click on the volume icon and select from there to open the whole window.
And a problem in Desktop View: left click on the destop is not working. But in Folder View, left click works. Then i created a new user, but the same problem exists. I just wonder if anyone else experiences this.
Hi , first of all, thanks for new packages to testing.
I see some breakage under 14.2 , some slackware stock packages broken with poppler and gpgme , i suggest rename poppler to poppler-qt5 , and build only the qt5 binding…. for no touch the original poppler fron slackware.
In a second “suggest” , i like to see , ALL PLASMA SHARE , under something like
/usr/share/plasma/* , exactly like the kde4 does , because plasma put big number of folder under share , with individual apps separately , for better control i request configure the build to go all plasma share under dedicated folder.
Sorry for my bad english , i hope understand what im saying.
Have a good day!
nobita, these packages are *not* compiled to run on 14.2, only on -current, so breakage is expected.
From this very article (end of third paragraph):
“As always, these packages are meant to be installed on a full installation of Slackware-current which has had its KDE4 removed first. These packages will *not* work on Slackware 14.2.”
First: my Plasma packages are for -current, not for 14.2. You should know that, right? Since your LQ nick is USUARIONUEVO. Also, I specifically mention in the README that I replace some of the Slackware packages.
Second, if you have an issue with the applications creating directories in /usr/share then you should create a bugreport on https://bugs.kde.org/ . Do not bother me with questions like this because I will not start patching all of KDE to satisfy a single-user request which does not add value.
If packages are only for current , why are under 14.2 folder ktown ? … ha ?
https://alien.slackbook.org/ktown/14.2/latest/x86_64
Arround /usr/share … if you downt know how configure options OK ,but not bother me ,arround go report to kde developers.
I UNDERSTAND NOW WHY ARE NOT AS OFFICIAL PACKAGES … thats a dissater.
I see , only change the .txt files date time, but packages not , … at this point , let me say , “need recompiled” , cause 14.2 gets some patches , and some things not working now , but no bther , dont do for me, im not use plasma.
good luck!
Well, I think your responses are a bit offensive, don’t you think so too? I will not accept the usual “english is not my native language” because you’ve been around long enough.
If you do not read the articles that accompany my KDE packages, and are not interested in their history, then that is just fine. But in that case, do not use my packages, alright? And do not bother me when you ignore my written instructions and things go south.
I ran into the first glitch. I came back to my screen after several hours of idle time and saw the below message on the console:
“The screen locker is broken and unlocking is not possible anymore. In order to unlock switch to a virtual terminal (e.g. Ctrl+Alt+F2), log in as root and execute the command:
# ck-unlock-session ”
I was able to log in remotely but it wasn’t clear to me what the “”. After several attempts at guessing the session name I finally just ran a “shutdown -r now” command. This was running under an old kernel (4.19.73). One which I thought had been pretty stable under the previous Plasma5 release. I rebooted with kernel version 4.19.80. Will keep monitoring this for a while.
@steve – I’m getting a lot of these as well. You can switch to a console and do ‘ck-unlock-session’ and it will show you what sessions are currently available. Then do ‘ck-session-unlock ‘ … Going to try another compositor method.
Thanks Robby. This is annoying enough that I am going to try downgrading kscreenlocker to the previous release. If the screenlocker crash still happens I will then downgrade plasma-workspace as well. I suspect someone has already submitted a bug. I will look through the base and if I don’t see anything I will submit one. Please let me know if you come up with a compositor that resolves this.
I’m not sure if this is related but when I try to set desktop backgrounds for my individual screens (2), at the time of selecting the folders of images to use, the desktop background goes black and it appears that kwin crashes. Not always but sometimes …
Someone else reported this as https://bugs.kde.org/show_bug.cgi?id=405219 but a long time ago and for older releases of KDE software. Seems to be some upgrade related race condition.
Thanks Eric,
Correct me if I’m wrong here but it seems you are implying the act of ‘upgrading’ (i.e. employing ‘upgradepkg’ versus a fresh install) might be creating a race condition with the screenlocker module? So maybe instead of downgrading I should try removing the packages in question (i.e. kscreenlocker, plasma-workspace, etc.) and reinstalling them?
–Steve
Yes, removing/re-installing could help, it’s at least something which is easy to do.
Having said that, my Plasma5 laptop has been continuously been upgraded with the latest -current for the past three years and I am not seeing this behaviour.
I just wanted to point out that this kind of issue has been reported before Plasma 5.17.
Update: I haven’t tried removing/reinstalling yet but I did revert kscreenlocker to the previous version i.e. kscreenlocker-5.16.5-x86_64-1alien and this appears to have fixed the issue.
I looked at the bug report above and the MO is slightly different. The screenlocker crash doesn’t happen on my system for several hours whereas it only took about an hour of idle time on the bug reporter’s system. I will try the complete removal and reinstall of the kscreenlocker package as you suggest. If I replicate the crash I will invoke the debugging version (kscreenlocker_greet –testing) to see if I can get the requisite log file they asked for in the bug report.
I really hope the removal/reinstall fixes this as the bug reporting process is a little tedious 😉
That said if it *does* fix it this might imply an issue with upgradepkg or perhaps slackpkg.
I’ve disabled compositing completely and that seems to have solved the issue with kscreenlocker however my plasma is now segfaulting:
[17915.185248] plasmashell[4970]: segfault at 1802c92570 ip 00007efea1ab7e00 sp 00007ffe54e8cdf0 error 4 in libQt5Core.so.5.13.1[7efea18e8000+2d3000]
[17915.185254] Code: 49 89 45 00 4a 8d 14 b8 48 03 50 10 44 89 32 48 8d 53 01 4c 39 e3 74 42 48 8b 4d 00 48 89 d3 48 8d 14 99 48 03 51 10 41 89 de 63 3a 8b 00 83 f8 01 49 8b 45 00 76 cc 8b 70 08 81 e6 ff ff ff
I posted the following bug this morning: https://bugs.kde.org/show_bug.cgi?id=413442
I spoke too soon – kscreenlocker continued to segfault. Reinstalling the package (actually the whole of ktown) did not make any difference. I switched to xscreensaver and no more segfaults …
@Steve I’ve confirmed your bug report.
I am not sure if I am missing a dependency but Breeze-GTK3 looks a little bit strange since the last release:
https://i.imgur.com/DPROZK8.png
I have opened a bug report on that: https://bugs.kde.org/show_bug.cgi?id=413266
The 5.16 version still works without any issues: https://github.com/KDE/breeze-gtk/tree/Plasma/5.16 – I have just cloned the git repository and ran src/build_theme.sh as my regular user and the ‘old’ (but working) theme got installed to .local/share/themes/Breeze
Greetings
Lioh
Seems you’re not the only one who noticed this strange behaviour. Your bug report was folded into another bug: https://bugs.kde.org/show_bug.cgi?id=412078
I can not get Wayland session to start. I can select from the drop down, and log in. I get a blank screen with just a cursor in the upper left corner. If I do a Ctrl + Alt + f2, log in as a regular user, and startx, I get a X11 session. This is the case on the two current systems I have. Am I missing something? This is not critical, just wanted to try it out.
I did look at ~/.xinitrc file after selecting Plasma-wayland session, and I don’t see any change there. I thought I should see startplasma-waylandsession, but its on in .xinitrc. Thoughts?
Cliff, there is no Wayland support in my KDE Plasma5 packages. A lot more needs to be done to get a functional Wayland session, and it starts with recompiling xorg-server and mesa in Slackware against wayland, but that’s only the beginning. Adding systemd-logind (or its derivative elogind) is a requirement to make Wayland work in Plasma5.
Read here if you want to know more: https://alien.slackbook.org/blog/plasma5-wayland-works-on-slackware/ – the article describes the status of two years ago.
Thank-you for your response, and all your hard work on KDE Plasma 5 packages.
Hi Eric,
I’m loving KDE5/Plasma! Thank you for putting it together and sharing. I might have run across either a bug or misconfig. When I run Konqueror it fires up fine the 1st time. If I close it then try to run it again it doesn’t appear. Task Manager says it’s still running so if I kill it off then it runs the next time. Run, close, kill, run , close, kill… I use Konqueror infrequently so it’s not a big deal, just reporting what I found.
Stu
I have that too, and I consider it a bug. Konqueror by default keeps an instance pre-loaded in memory so even if you close the window, the process continues living. A next call of konqueror will not bring up a new window.
An old bug report for this issue ( from 2010!) was recently updated by someone saying it’s still not fixed: https://bugs.kde.org/show_bug.cgi?id=258124
The workaround is to go into “Settings > Configure Konqueror > Performance” and there, uncheck “Always try to have one preloaded instance”. This will work for all Konqueror startups after changing this setting, but you still have to kill the original Konquerer’s process manually this one time.
The workaround is totally fine. I should have figured there was a Konqueror setting to tweak. Thanks again Eric!
I assumed that the plasmashell segfaults I was having were related to the kscreenlocker issue however these have continued after moving to xscreensaver:
Oct 21 08:47:46 googly kernel: [207710.602822] plasmashell[17482]: segfault at 180365ccd3 ip 00007fda46622e00 sp 00007ffeb07a0ca0 error 4 in libQt5Core.so.5.13.1[7fda46453000+2d3000]
Oct 21 19:10:34 googly kernel: [35799.279651] plasmashell[9478]: segfault at 10284a648 ip 00007f2e2de3ae00 sp 00007ffd4eeb5560 error 4 in libQt5Core.so.5.13.1[7f2e2dc6b000+2d3000]
Oct 22 12:55:19 googly kernel: [17918.269605] plasmashell[9433]: segfault at 5040f34b3 ip 00007f73d5795e00 sp 00007fff19c3a1b0 error 4 in libQt5Core.so.5.13.1[7f73d55c6000+2d3000]
Oct 22 18:06:06 googly kernel: [17915.185248] plasmashell[4970]: segfault at 1802c92570 ip 00007efea1ab7e00 sp 00007ffe54e8cdf0 error 4 in libQt5Core.so.5.13.1[7efea18e8000+2d3000]
Oct 22 21:07:56 googly kernel: [28824.095779] plasmashell[21787]: segfault at 1802471a81 ip 00007f965e692e00 sp 00007ffcb4029b70 error 4 in libQt5Core.so.5.13.1[7f965e4c3000+2d3000]
Oct 23 07:34:17 googly kernel: [66405.182359] plasmashell[11407]: segfault at 303d97311 ip 00007f0b5d7d9e00 sp 00007ffebdbbf6c0 error 4 in libQt5Core.so.5.13.1[7f0b5d60a000+2d3000]
Oct 23 08:34:15 googly kernel: [ 34.496933] plasmashell[2225]: segfault at 1802953bc3 ip 00007f5e3a4e1e00 sp 00007ffd4bc20c30 error 4 in libQt5Core.so.5.13.1[7f5e3a312000+2d3000]
Oct 23 23:30:20 googly kernel: [53798.623127] plasmashell[22368]: segfault at 1027f70d8 ip 00007f0752ae4e00 sp 00007ffc5d9b2ca0 error 4 in libQt5Core.so.5.13.1[7f0752915000+2d3000]
Oct 24 20:19:05 googly kernel: [128722.789156] plasmashell[20477]: segfault at 103bfe108 ip 00007f759016fe00 sp 00007ffea46d1fc0 error 4 in libQt5Core.so.5.13.1[7f758ffa0000+2d3000]
Oct 25 08:45:41 googly kernel: [173518.099568] plasmashell[31371]: segfault at 18024355e3 ip 00007fcb3927ee00 sp 00007ffd344ec6d0 error 4 in libQt5Core.so.5.13.1[7fcb390af000+2d3000]
Oct 25 12:17:27 googly kernel: [ 8973.193756] plasmashell[22812]: segfault at 1802de8860 ip 00007fab276eae00 sp 00007ffe0c9fe370 error 4 in libQt5Core.so.5.13.1[7fab2751b000+2d3000]
Oct 26 06:19:46 googly kernel: [44734.886974] plasmashell[8121]: segfault at 402d2bd08 ip 00007f2878891e00 sp 00007fff7ee55ec0 error 4 in libQt5Core.so.5.13.1[7f28786c2000+2d3000]
My system is updated as of yesterday however the most recent segfault is from today. Anyone else having these?
Some more info from this segfault:
KCrash: Attempting to start /usr/bin/plasmashell from kdeinit
sock_file=/tmp/xdg-runtime-rpedrica/kdeinit5__0
KCrash: crashing… crashRecursionCounter = 2
KCrash: Application Name = plasmashell path = /usr/bin pid = 3087
KCrash: Arguments: /usr/bin/plasmashell
KCrash: Attempting to start /usr/lib64/drkonqi from kdeinit
sock_file=/tmp/xdg-runtime-rpedrica/kdeinit5__0
QSocketNotifier: Invalid socket 8 and type ‘Read’, disabling…
QSocketNotifier: Invalid socket 10 and type ‘Read’, disabling…
QSocketNotifier: Invalid socket 12 and type ‘Read’, disabling…
Am I the only one having this issue?
I am not seeing the above ‘KCrash’ but I am not running xscreensaver. I am still running kscreenlocker from the previous release (5.16.5). It appears xscreensaver wants to run (initialize) inside /usr/bin/plasmashell which is part of the base package plasma-workspace-5.17.0*
If you were not seeing these crashes with the previous Plasma release I would try rolling back (downgrading) to the previous workspace package (plasma-workspace-5.16.5-x86_64-1alien.txz) just to see if this eliminates the crashing.
BTW Yesterday I added a comment to the bug I submitted that I did get another kscreenlocker crash from the previous package. It makes me suspect that there was a bug introduced in one of the other package upgrades because I saw no such crashes in the previous release. My first suspect is the workspace package.
Hrmm, something new since 15 Oct ineed broke kwin-wayland. It was working fine a couple of weeks ago. Back to x11, since plasma/wayland is still in beta, no need to fix it. Fun while it lasted, tho.
kwin-wayland can never have worked for you. The neccessary wayland support is not present in xorg-server or mesa. And I do not ship elogind. What you will have been running is the regular kwin-x11.
Thanks for the clarification, Eric. SDDM has a Plasma-Wayland menu item, which did sort-of work at first. Verified by `ps ax | grep wayland`. Didn’t use it more than once, it hosed the cube desktop switcher and wouldn’t shut off the keypad with a usb wireless mouse. Had to rebuild all of the .config/plasma* option files before x11 worked again. Can’t say when sddm’s plasma-wayland went dark. Only way to get that was from `init 4` and sddm. I’ll wait for the kde.org announcement. Meanwhile, gnome-wayland works as advertised, but I’m not gnome-ish.
Hello Eric/alienbob
I send this with no context nor digging to see if this has been addressed pardon in advance if so….
this is just a statement” for me the last 2 versions for me of Live have had similar issues to the snippet below:
—–
live@darkstar:~$ qbittorrent
qbittorrent: error while loading shared libraries: libboost_system.so.1.70.0: cannot open shared object file: No such file or directory
______
root@darkstar:~# find / -name libboost_system*
/usr/lib64/cmake/boost_system-1.71.0/libboost_system-variant-shared.cmake
/usr/lib64/libboost_system.so
/usr/lib64/libboost_system.so.1
/usr/lib64/libboost_system.so.1.71
/usr/lib64/libboost_system.so.1.71.0
/mnt/liveslakfs/usr/lib64/cmake/boost_system-1.71.0/libboost_system-variant-shared.cmake
/mnt/liveslakfs/usr/lib64/libboost_system.so
/mnt/liveslakfs/usr/lib64/libboost_system.so.1
/mnt/liveslakfs/usr/lib64/libboost_system.so.1.71
/mnt/liveslakfs/usr/lib64/libboost_system.so.1.71.0
/mnt/live/modules/0010-slackware_l-current-x86_64/usr/lib64/cmake/boost_system-1.71.0/libboost_system-variant-shared.cmake
/mnt/live/modules/0010-slackware_l-current-x86_64/usr/lib64/libboost_system.so
/mnt/live/modules/0010-slackware_l-current-x86_64/usr/lib64/libboost_system.so.1
/mnt/live/modules/0010-slackware_l-current-x86_64/usr/lib64/libboost_system.so.1.71
/mnt/live/modules/0010-slackware_l-current-x86_64/usr/lib64/libboost_system.so.1.71.0
____
sorry if the wrong place for this … just wanted you to know.
i did attempt a daft write 🙂 on non-persistent media… how daft of me ::
root@darkstar:/mnt/liveslakfs/usr/lib64# ln -s libboost_system.so.1.71.0 libboost_system.so.1.70.0
ln: failed to create symbolic link ‘libboost_system.so.1.70.0’: Read-only file system
root@darkstar:/mnt/liveslakfs/usr/lib64# ln -fs libboost_system.so.1.71.0 libboost_system.so.1.70.0
ln: failed to create symbolic link ‘libboost_system.so.1.70.0’: Read-only file system
root@darkstar:/mnt/liveslakfs/usr/lib64# ln -nfs libboost_system.so.1.71.0 libboost_system.so.1.70.0
ln: failed to create symbolic link ‘libboost_system.so.1.70.0’: Read-only file system
respectfully
Hi _metic
The qbittorrent package needs a recompiliation against the newer boost package in Slackware-current. But until I do that (it is on my TOTO but I never get around to actually do), the easiest fix is to install my ‘boost-compat’ package which contains the boost lbraries of several older boost releases.
On a persistent Slackware Live you can install packages using slackpkg or the pkgtools (installpkg) just like any other Slackware.
thank you kindly for the response.
I tried slackware64-live-xfce-current.iso (2019-10-15 21:02) and boot menu says:
Non-US … selection
After you select something from the submenus it says:
Non-@ULANG@ … selection
Hi scootergrisen, I will have a look at that. I have not touched the boot menus for a while so this bug is not new – apparently no one uses the feature.
The timestamp you mention (2019-10-15 21:02) belongs to the 32bit ISO, not the 64bit ISO you referenced in your comment.
I can reproduce the issue you reported with both the 64bit and the 32bit ISO.
And I think I found the bug: https://git.slackware.nl/liveslak/commit/?id=9a33e778f7e5a4e40eed3606e47f9a1e2dc4533a
Hey Eric,
I really appreciate your work and am enjoying -current with Plasma 5. I have a question about KMyMoney. I am just starting to use it and am trying to figure out how to get GPG encryption working. Based on the docs (http://kmymoney2.sourceforge.net/kde4/online-manual/details.settings.html), I think there should be an entry under Settings -> Configure KMyMoney -> Encryption, but I don’t see it when I run the program. Is it possible that it was not built with GPG support? If so, would you be so kind as to do that for the next release?
Thanks very much.
Actually, sorry, that link was for KMyMoney4. In the handbook for 5 (https://docs.kde.org/trunk5/en/extragear-office/kmymoney/kmymoney.pdf), I see that you are supposed to be able to encrypt the file, but I still don’t know how. It says in section 22.3.2 that there is supposed to be an encryption entry under settings, but it doesn’t appear, and it’s not even there in the handbook. Strange. Maybe this is an upstream issue.
I use kMymoney on Plasma5 on my laptop and actually I am using GPG encryption. You do need a GPG key-pair of course. And use the XML backend, I do not know whether the SQL backend supports GPG encryption.
Go to Settings > Configure kmymoney > Plugins and click on the configurator icon for the XML backend. There you can enable GPG encryption and select a GPG key.
Ah, thanks. That was it. That setting is really buried in there. Encryption is working fine now.