On with the show.
After recompiling LibreOffice and VLC to compensate for the recent poppler update in Slackware-current, my next target was – naturally – my Plasma5 package set. The KDE-5_18.05 release of ‘ktown‘ for Slackware-current offers the latest KDE Frameworks (5.46.0), Plasma (5.12.5) and Applications (18.04.1) on top of Qt5 5.9.5 (I decided to wait with an update to Qt5 5.11.0).
You can and should check out the README file for more details and for installation/upgrade instructions.
News about this month’s refresh
- In the deps section I updated my poppler package so that it again matches the version in Slackware-current (my poppler package has support for Qt5 in addition to the Qt4 support in the Slackware original). I also rebuilt cryfs after that was reported broken.
- Frameworks, Plasma and Applications updates are focusing on improved stability and nothing exciting happened there.
- In applications-extra I have rebuilt calligra (was affected by the new poppler) and updated the alkimia, falkon, kdevelop, kdev-php, kdev-python, krita and krusader packages. I also added one new package: krename.
I think and hope that the shape of Slackware-current is getting to a point where Patrick feels comfortable with introducing the new Plasma5 into the core. To be honest, the waiting gets tedious. The first preview of Plasma5 for Slackware was introduced in my blog almost four years ago. I’d wager that it has matured quite sufficiently in the meantime.
If you want to read more about the history of Plasma5 development for Slackware, with lots more detail, check out my older blog posts. If you think a git log is easier to read, check out my ktown git repository instead 🙂
If you are using slackpkg with the slackpkg+ extension, don’t forget to run “slackpkg install ktown” to get any new packages installed, because “slackpkg install-new” will not catch new packages in 3rd-party repositories like ‘ktown’.
I am preparing a new PLASMA5 variant of the Slackware Live ISO image, so you can check out the new desktop in the safety of a non-invasive live environment. Hopefully before the weekend… depending on the workload tomorrow.
Congratulations for the release! 😀
Like butter, a usual, Eric. Thanks for all you do. Let’s hope the waiting doesn’t get *too* tedious.
Speaking about Plasma5 readiness, I am just curious if it learned meanwhile to handle its own configuration files, or still we should hack them manually to get the bold fonts displayed properly?
Thanks, working great. Is it just me? Startx from runlevel 3 seems to be a a whole lit faster. 🙂
Well Richard – at some point the level of tediousness will get to where I stop with my Plasma5 package releases. I mean, 4 years.
If Plasma5 is too complex or too high-maintenance for inclusion into Slackware then it’s going to stop for me as well and I’ll switch to XFCE.
All this ‘ktown’ work and recompiling packages that break in -current eats up a lot of my free time which I can no longer justify toward my wife. Many hours, every night. There’s no financial gain in return – the Adsense ads on this blog used to make 10 dollars per month but that has dwindled to only cents per month (I use adblockers myself, so understandable) and donations have all but stopped. Once the money to pay for the rent of the ‘bear’ server has dried up (within a couple of months) I’d have to ask for money and that is something I hate to do – I’d rather pay out of my own pocket.
There’s one kind person who sends me a monthly amount but even that does not cover the cost of the server rent.
End rant. End of the week blues I guess…
My last post I spell my name wrong. Hehe.
Noticed a package removed not mention in the README or ChangeLog.txt.
Took it for granted it should be removed.
Well thanks for that report. The “qqc2-desktop-style” should have been built but I notice only now that the build logfile told me it was skipped.
It looks like the reason for skipping it is that there are actually 3 source tarballs: 5.46.0, 5.46.1 and 5.46.2. My kde.SlackBuild could not handle the fact that there’s more than one source tarball and boo-booed…
I will compile this package ASAP and add it to the repository… again thanks for spotting and reporting!
Thank you Eric! I hope Plasma gets included in -current ASAP.
Thanks also for the inclusion of krename!
chrisretusn , I have uploaded the missing ‘qqc2-desktop-style’ package.
Thanks Eric. Will rsync after posting and update my install.
Thank you very much.
It seems that kile needs also to be recompiled
Pingback: Links 25/5/2018: OpenSUSE 15 Leap Released, PostgreSQL 11 Beta | Techrights
And even in this incarnation, the Plasma5 does known to write its own configuration files in a form which itself can read properly…
Same bold fonts issue in config files, even in this build. 🙁
And even in this incarnation, the Plasma5 does NOT known to write its own configuration files in a form which itself can read properly…
Sorry for typo, and for the second message, but there is no possibility to edit a message.
Darth, what is the number of the bug report you created to allow the developers to address and fix your issue?
Er is elke dag weer te weinig tijd, er is nog zo veel te doen!
I’ve been using the ktown packages for over two years now, and they’ve been nothing but solid for me. As far as I can tell, they were ready for inclusion in 14.2! 🙂
Thanks a lot for all the work you’ve put into Slackware, not only ktown, but all the packages (which I regard as “unofficially official”, a reliable extension of the base system), Slack Live (which I keep on my keyring alongside my house and car keys), and this blog (which has virtually become my only source of news concerning Slack, and has been quite informative). It all makes Slack so much more pleasant to use, and it’s very much appreciated.
Met vriendelijke groetjes,
I’m starting to think I must be a masochist. 🙂
About once a month I’ve downloaded and install kde5 and none, of the few problems I’ve seen, have been corrected.
kde5 doesn’t play well with others. It totally screws up my
Xfce settings. I found a file that said to go into the kde5 settings under “colors” and remove the check mark next to the box that says something along the line of “apply colors to non qt applications.” Didn’t do bit of good.
If you use virtual desktops you can no longer have different wallpaper for each desktop, but that does work for “activities.” Didn’t see any changes in the few kde applications I use that are noteworthy. Spent about 5 hours this time, 8 hours the last time, trying to tweak it. Just don’t care for it, but, then, it took about 6 years before I thought kde-4 was ready for daily, serious work.
Now I’m debating whether to delete kde5 and and re-install kde4, as I use Xfce most of the time, or leave kde5 installed and live with the mess it made of my Xfce setup. Which brings up the thought, would you know what I can do “undo” what kde5 has done to Xfce, and then I can just use the kde5 apps?
As always, thanks for all you hard work.
I forgot to mention I went to the kitchen for a few minutes and just as I was sitting back into my chair a light blue
screen appeared and locked the screen. Punched in the password and all was well, but I couldn’t find anywhere to turn that off and, yes, I had already turned off the “power saving” switch in the kde5 settngs.
Perhaps you should document somehow how Plasma5 messes up your XFCE. Without screenshots or other actual proof I can not imagine what is wrong on your XFCE desktop.
I think someone already told you that the GTK+ theme engine of Plasma5 writes a configuration file that XFCE might be using.
Perhaps if you just remove the kde-gtk-config package, that will be sufficient.
“I think someone already told you that the GTK+ theme engine of Plasma5 writes a configuration file that XFCE might be using…”
Yes, that is the same file that also give one instructions to removing the checked box next to “apply colors to non qt applications.”
I took the “easy” way out and did a fresh install of the most recent -current iso.
Problems solved… so to speak.
Oh it built. What about the user root.
Pat learned that years ago. unstable and the Icons still do not refresh. good luck
so root is unable to copy from one partition to another. root is a user. You have an Idea why your system does not see UUID per 0
I haven’t looked at the code to be honest. but to be able to to back up as root to another partition is a set back.
sure you can do it in command line I can. but we are working on gui. good luck. edit the code
Once finished with KDE, what do you say about Enlightenment? SlackE18 seems dead. I lack reliably packages for Slackware.
Marcus_777 – I installed Enlightenment once, found it ugly as hell and clumsy, and never touched it again. That will not change.
Drakeo sorry – I can’t follow you. Sorry. Explain why my packages are unstable or stop spilling your nefgative vibe on this blog. It is entirely unhelpful. I can not fix anything if you do not mention what needs fixing.
And if you complain about Plasma5 then this is not the place to post. Create KDE bug reports.
Surprisingly. For me it is pretties desktop environment. Light, fast, ergonimic and rock stabe. I respect your decision and don’t ask again 🙂
not directly related to ktown, but since it is an optional external dependency, openconnect needs to be recompiled due to the .so bump from libidn.
Thanks for you work.
I use Kate a lot. Been busy last few days written scripts. Has anyone experienced Kate freezing for several seconds? Happens perhaps once a day. It always comes back. I can see one of my CPU’s cruising at 100% sometime when this happens. It just a bit annoying and was wondering if it’s just me.
Aside from that, Ktown is running rock solid.
ArTourter – thanks, I will attend to a recompile of openconnect ASAP.
I look at your blog every day. To show my appreciation I gave you a few bucks via the donate button. Stay awesome.
JtotheD – much appreciated!
I released something new today (useful for followers of -current) and hope to write about it soon. If you search, you may find out what it is before I write that post… no bonus points though 🙂
It seems that dvdauthor needs also to be recompiled (in slackware64-current):
/usr/bin/spumux: libMagickCore-6.Q16HDRI.so.5 => not found
Helios yes indeed. I had not yet upgraded to the latest packages (also I never use dvdauthor myself) but now I see it. I’ll fix it with an updated package.
Just for the record, but currently vlc fails to build here because the libxkbcommon-0.8.0-x86_64-1alien.txz still contains a .la file that seems to refer to some XCB .la file that no longer exist. Not sure if I’m doing something wrong or if it’s a real issue, but vlc builds with XCB support if I remove the above package.
Strange because I just built it a day or so back and had no issue.
Perhaps if you had posted the errors…
Shared library .so-version bump.
libmysqld.so.19 was renamed to libmariadbd.so.19.
Anything linking to libmysqld.so.19 will need to be recompiled.
I suppose this impacts something in Plasma? Akonadi?
Akonadi is probably the only affected package. Pat rebuilt Amarok in -current but that’s not part of my ‘ktown’ repository.
I do not think that akonadi depends on mariadb 😉
Gérard indeed I came to the same conclusion when I updated my VM with Plasma5 and the latest -current. There are no library dependencies which would mandate a recompilation.
The latest -current updates seem to be causing a major increase in “idle” cpu usage with KDE5. Stopping cupsd solves the problem, though it is plasmashell that is affected worse. KDE4 isn’t affected. The whole saga is here:
These are the bug reports for the CUPS issue, since it is not just Slackware that suffers:
It seems to be a regression in cups-2.2.8. Reverting to 2.2.7 solves the high CPU load.
Hi Eric, yes, agreed – it looks like a cups issue, but strange that it only rears its head in kde5! Its still there in the latest beta release of cups (2.3b5) – I tried that too! Luckily, thanks to your new git repository, I was able to retrieve the build package for 2.2.7, and all is now working well.
Even though the bug is triggered by a change in CUPS, the solution is at least worked on in KDE’s print-manager software.
If they come up with a fix I’ll patch my package with it.
gmgf has pointed out that archlinux have a patch for cups-2.2.8 that appears to fix the issue:
I’ve tried it, and its all working fine, so far!
Another patch than
that Arch patch has been offered to the CUPS developers through a push request: https://github.com/apple/cups/pull/5330
So perhaps you should try this patch: https://github.com/heftig/cups/commit/455c52a027ab3548953372a0b7bdb0008420e9ba.patch
Yes, that seems to work fine too. As it has come from the cups developers, I guess that makes it the preferred option! 😉
Are you going to point this out to Pat, or should one of us do it? I know it only affects kde5 as far as we can tell, but if something is wrong, then it is wrong and needs correcting….
The patch has already been applied to the cups package in -current so after you upgrade it, all should be well.
Kde-connect and Kuser all work?
When attempting to build the new KDE Plasma 5.13 sources, I ran into the issue that a Plasma 5.13 requires a minimum version of Qt5 that is 5.10.0.
I.e. the qt5 package in my repository is too old.
I think I’ll have to make a decision here. Pat will likely not want to include a short-lived version of Qt5 in slackware-current.
Qt 5.9 is a LTS release with update support until 2020 while Qt 5.10 support will end later this year and Qt 5.11 will be supported to halfway 2019.
Therefore I estimate that Pat will add Qt 5.9 and Plasma 5.12 (which is also a LTS release) together with the newest versions of Frameworks and Applications that work with those.
Which means that I will stick with Qt 5.9 and Plasma 5.12 for a little while but I will upgrade Frameworks and Applications.
In parallel I will use my “testing” repository on ‘ktown’ to introduce Qt 5.11.0 (released 3 weeks ago) and Plasma 5.13.0 (to be released this week).
Wayland support will not be considered in that upcoming ‘testing’ update.
Eric, i use qt5-5.11.0, and i have installed the latest frameworks, plasma, and applications compiled with this qt5 version, it work correctly 😉
Gérard I have no doubt that the latest KDE would fail against Qt 5.11. I will put Qt 5.11 and Plasma 5.13 in ‘testing’ because I can not compile Plasma 5.13 against QT 5.9 and I don’t want to force Pat’s hand.
To be honest, I had not expected that in June 2018 I would still be maintaining Plasma 5 here in this repository, outside of the Slackware core.
>To be honest, I had not expected that in June 2018 I >would .still be maintaining Plasma 5 here in this >repository, outside of the Slackware core.
Really??!! It brings nothing but convoluted complexity to Slackware.
“Really??!! It brings nothing but convoluted complexity to Slackware.”
Unfortunately, many of the apps of which I make quite a lot of use are now only supported under Plasma5. Mostly multimedia stuff like kdenlive and kaffeine, but there are others too.
It would be really nice to see kde5 offered as an install option alongside kde4 and all the other window managers in Slackware. Then we could just install what we needed for our individual purposes.
Slackware was quite late adopting 64 bit, with Fred Emmot’s SLAMD64 offering a viable alternative until Slackware64 was deemed ready. Hopefully Pat and the Slackware team will finally offer kde5 as an option in the next release.
In the meantime, many thanks to Eric for his efforts here!
> Really??!! It brings nothing but convoluted complexity to Slackware
I’ll be blunt for once and hopefully this sets the record straight.
It’s not the software. It is your frankenstein computer which is the cause of all these issues you report on my blog about the use of my software packages.
And Plasma 5 is visually displeasing to your eyes, I respect that. But “convoluted” and “complex” ? You pull that out of your arse.
KDE4 has been un-maintained since even before the release of Slackware 14.2. Only the kdelibs sources received the occasional bug fix but that stopped at the end of 2017.
KDE4 is still a useful and stable desktop environment, but it is not something that should be carried as part of the distro ‘ad infinitum’. Like you said, KDE4 no longer supports new applications because its libraries are too old. Just like with KDE3, it will have to be replaced by the new development at some point. Plasma Desktop has been in development for several years now, it is stable, featureful, and consumes less resources than KDE4.
If KDE4 is removed from Slackware, someone could take over maintenance of the packages. But more likely, no one will want to commit to that, just like how it went with KDE3 – even when it was rebranded to Trinity Desktop. There’s no quality repository for KDE3/Trinity Slackware packages.
My apologies. I shouldn’t post after too many Heinekens, but still doesn’t change my opinion of kde5. I’ve never forgiven them for kde4.0 and won’t be using kde5. Each to their own.
BTW, the hardware is less than a year old. An Asus motherboard with a Ryzen CPU, a GeForce 740 graphics card, 16 gigs of ram and a name brand SSD.
> I’ve never forgiven them for kde4.0
You know that the hubbub about KDE 4.0 is exclusively the fault of certain distros? KDE 4.0 was released as a “tech preview” not meant to be included into distros and not meant for the average enduser. Yet some distros replaced their KDE3 with KDE 4.0 and public outrage followed.
This was, again, not the fault of the developers. Perhaps their PR department should have done a better job which would have prevented this distro failure, but don’t blame the code or the devs.
I started building KDE 4.2 packages when developing the 64bit port of Slackware (read https://alien.slackbook.org/blog/kde3-kde4-and-slackware-13-0/ to refresh your memory). Version 4.2.1 was the first KDE4 release to enter Slackware, replacing KDE3. That was 2009, and by then the KDE4 Desktop Environment had properly stabilized.
I think Plasma5 today is more stable than KDE 4 back then. I also think it’s more than overdue that after 9 years, there’s still a KDE 4 in -current.