Even though I caught a bad cold (luckily, it was not the flu as I feared at first) I managed to do a lot of prepping for new KDE 5 packages (Frameworks, Plasma, Applications) since last week.
The way I tackled KDE updates in the past, was to update the sources, check the continued need of patches used for prior releases, and then start compiling and checking the build logs for errors – and responding to errors with fixes to the scripts, new patches or even new or updated dependencies. The core of the KDE.SlackBuild framework would remain largely unchanged, and it never took lots of going back and forth to recompile packages and get rid of errors or missing dependencies. KDE 4 has always been very easy to update (well, easy – experience helps a lot, plus the fact that I wrote the KDE.SlackBuild framework and know its ins and outs).
Working with the first test release of KDE 5, last summer, was a bit of a challenge, but I took it like I did with every change to a new release cycle of KDE 4 (4.11 -> 4.12 etc…): finding all available documentation on the available sources, their inter-dependencies as well as their other needs, and reading the comments and patch proposals on the KDE packagers mailing list. Going from KDE 4 to 5 was a heck of a lot more work than I initially anticipated (the hardest part was figuring out the tiering concept of the Frameworks, and of course there was a lot of cursing at the immaturity of the Plasma sources) but I considered that first release for Slackware as nothing more than a play-test. The preview packages were designed not to mess up your existing KDE 4 configuration, and easily un-installable. For me the important thing with this proof of concept was to convince myself that the updates to the KDE.SlackBuild framework were sound and I understood and was able to respond to the new reality of fragmented release cycles.
This last week, I have been targeting a more serious outcome. The upcoming KDE 5 packages for Slackware which I will be releasing sometime later this month, are meant to replace your good old KDE 4 installment, and therefore I need to deliver something that you can work with on a daily basis – a full set of applications in a functional Desktop Environment.
For that reason, I decided to call upon git to guide me through the process of making changes to the build framework. I needed to be able to reproduce my previous build environments in order to back-track after encountering errors or dead ends, and take a fork from there and try again. Putting the whole KDE.SlackBuild tree in a git repository was something I did in advance – see my previous post on KDE 5 – and since then, I have been pushing my changes to the repository continuously.
Definitely, this has saved me from finding myself in a dead end. What sometimes happened was that some application would compile into a package one time, and fail to compile the next iteration. Usually the cause would be an update of a dependency, the introduction of a patch to another package and more of that vague stuff. My git updates enabled me to inspect all updates I had done since a previous compilation attempt, and revert or adapt some of the changes I had made. In some other cases, the changes I could track graphically in the ktown cgit web interface showed cause and effect with more ease than back in the time when I would keep multiple directory trees of past attempts. A time saver!
I am currently compiling the last couple of packages that are part of the Applications. If they succeed, it means that the KDE.SlackBuild is ready and I have a full set of packages. If you ask whether they produce a wonderful Desktop Environment… I do not know yet 🙂 That will be the next step: when all packages are conceptually OK, I will fire up an X session in the virtual machine and see if the stuff I compiled works at all. If I get into a functional KDE 5 environment, that will be cause for celebration. But I expect that I will have issues in the VM (with sddm and/or kwin). If I see failure, I will try installing the packages on a real computer and see how it fares there.
I won’t release any packages until I am fully satisfied, but feel free to tinker with the KDE.SlackBuild in advance.
Eric
I’m getting excited about KDE-5 – and I did get the flu. 🙁
I’m on day 3, on Tamiflu, and doing better. I hope that tomorrow is near normal. Having chills in the winter with colder than normal temps is a b**ch.
Thank you Eric! The more I use git the more I like it, cannot wait to see the finished KDE packages. 😉
That’s a lot (and a hell) of work! I’m sure that besides the issues with all that 5 in KDE products, we’re going to receive just the best from you and your testers.
Oh! A question: is this a good time to uninstall the soon to be old ktwon-testing packages?
Good news Eric, thanks for your time with kde5.
Can you tell me if amarok from KDE5 will work with Replay Gain mode? In kde4 I can’t use phonon-gstreamer that this mode needs and phonon-vlc does not support Replay Gain mode.
It would be perfect if in kde5 it works.
I want just to say “thank you” for everything .
I appreciate really really much your work.
Michelino
Hi Deny Dias
If you are no longer using the KDE 5 “preview” it is safe to un-install all the KDE packages that came with it. You can leave the “deps” packages. They will be upgraded anyway when you install my future KDE 5 packages.
Hi y0g1,
I really never use Amarok, so there is nothing I can tell you about it. There is not going to be an Amarok update in my future set of packages, but if you compile an update yourself and report your findings, I will see if I can include an updated Amarok later on.
Interesting read, and a bit sad. KDE4 was relatively nice and clean (I remember this from having “backported” 4.10.5 to Slackware 14.0). After a talk with a KDE developer on the Linux Summit last summer in Montpellier, I’ve been enthusiastic about the future of KDE. He announced more code-correctness and a more “enterprise-like” approach (more bugfixing, less new features). Reading your post above, I’m not so sure. If I had to do this, it wouldn’t be long before I felt a strong urge to yell at the developers to get their act together.
:o)
I just hope that by the time Plasma 5.2 is available, I won’t get bit by the Wayland/logind dependencies of KWin which will really be taking off in that release. The only other worry I have is SDDM which I could not get to work the last time (a few months ago) when I tried updating it, combined with the fact that its developers (like with KWin) are fairly hostile to non-systemd distros.
Back to KDE 5:
The Frameworks seem pretty stable, and the fact that they are basically all Qt5 modules means, that they can be used outside KDE. It would be great if other people started adopting them.
Plasma seems to get there slowly, and while I am packaging 5.1.2, I think that the real improvement will not come until 5.2 (for which the Beta was just released).
The Applications are for the most part still the same ones as shipped with KDE 4.14, and only a small (but growing) number has been ported to Frameworks 5. The good news about Applications 14.12.1 (new incremental release on the road to 15.04) is that the set of sources contains the KDE 4 bits that are still needed, in the form of LTS (Long Term Support) tarballs: kdelibs, kdepim, kdepimlibs, kdepim-runtime, kde-workspace. When I began with Applications 14.12 last week, those LTS tarballs were not shipped and I had to grab then from a KDE 4.14.3 source tree.
The status early morning (before I went to work) is that 3 applications failed to compile: okular, step, kalgebra. I have not had time to check the build log for the reasons. Okular is important, I could live with the other two having permanent failures.
Great news Eric! Thanks for the work. I look forward to play with the new KDE.
If it’s any consolation: I’m back to Xfce as main desktop environment, and after (quite) a bit of beefing it up, it works great without getting in the way. So if one day KDE doesn’t build anymore on Slackware due to the odd unnamed dependency, the fallback perspective is not bad at all.
Thanks for the work. Great news Eric!
The Arch Linux KDE5 Plasma-Next 5.1.2 is integrated with systemd 🙁
Good Luck Eric
What are you basing your slackBuild current or 14.1. If 14.1 does it have all updates installed? If current as of what date?
I am sure I won’t be able to solve any of the problems you are having but when I have time I will set up a spare partition and take a shot at a build.
John
Hi John Yost
I am using the most recent slackware-current as my baseline for KDE 5 development. A Slackware 14.1 will probably not be enough even with all the available patches applied, because slackware-current has had some library updates which are not in a patched Slackware 14.1.
Thanks for your work, and writing down the process. I have a spare desktop ready to test when ready, glad to be interested again. Cheers!
Some notes from my build based on your KF5 test SlackBuild:
– Since KF5 using latest harfbuzz library, I think you need to rebuild LibreOffice and GIMP (and probably another GTK apps which is using harfbuzz) against it, undefined symbol error.
– I’m also building KF5 wayland support (rebuilt/upgrade mesa, xorg-server, xorg-drivers). Some non-X11-linked KF5 apps works just fine with wayland (with some glitches). And yes, it needs PAM for weston 😛
– I did not use login manager (display manager), so I did not use PAM for login, just for weston auth only (to use KMS/DRM).
Well, right now I’m back to KDE4 and waiting for your packages instead 😀
Eric, I again send my invitation if you need some more raw compiling power. I have all those i7 just sitting there…
Hi Amit
Thanks for the offer. I do all my compilation inside my own home, to ensure that nothing leaks out before it is time to release.
If anything, I would use a distcc server or servers to offload some of the compilations. Using distcc is what I already do when I need to compile ARM packages… my ARM computer is too weak for a speedy compilation.
HI Widya,
Were you able to actually start a KDE 5 desktop? When I try to use my compiled packages, I get errors that indicate that the Qt5 libraries picked up Qt4 dependencies and as a result their applications refuse to start (error: Failed to load platform plugin “xcb”. Available platforms are: linuxfb minimal offscreen xcb)
Have you tried compiling Qt5 in the VM or using a pre made package? I had an xcb error with LxQt cause I upgraded libxcb and the other xcb packages to current and nothing in Qt5 would launch. I had to revert back to the packages my Qt5 was compiled against. I’m on a fresh install now and I recompiled Qt5 for current . Qt5 doesnt seem to wanna be moved/relocated for me, might just be the way i compilied I don’t know.
Thank you very much! I decided to fully switch to Plasma on my laptop. I had to install plasma 5.2beta because the 5.1.2 one had a problem with Klauncher. The big trouble is that it’s still an hybrid system with both 4 and 5, but it’s doing its dirty job.
Hi Thorn Inurcide,
I rebuilt Qt5 and now the Plasma 5 desktop will start properly. I’ll be polishing the script files a bit more and then start a rebuild of everything when I have time, and afterwards install it to my laptop.
Hi Davide, what was your issue with klauncher?
It was something like “preparing to launch kdeinit5_klauncher” and nothing more (no other message logged), that was only on a normal user, as root i was able to login through sddm or launch startx; I upgraded to plasma 5.1.95 and the problem is gone. Alea iacta est 🙂
That’s great news =]
Sorry for late response. Seems that you have already resolve the Qt5 problem 🙂 . I think that upgrading Xorg to 1.16 would be best to use KF5 since some of its component requires a newer Xorg proto and libs. Another issues from my installation in a hybrid gpu (intel+radeon) system were an excessive GPU switching and some glitches in a Qt5-based UI. Maybe a newer XCB would solves it?
Hi Widya,
Possibly the Plasma 5 desktop could benefit from updates in X.Org, but that is way beyond the scope of my ‘ktown’ project. We’ll have to wait for Patrick for those kind of updates.
Hi Davide
I did not have those issues, but I do have some issues with plasmashell crashing very often, with the error message “the x11 connection broke: unsupported extension used (code 2)” and I think that has to do with the limitations of the virtualized graphics in my QEMU image. A pity, because KWin in KDE 4 was not trying to use unsupported extensions.
I switched my build to Plasma 5.2.0 (to be released next tuesday but I have access to the source tarballs) and that is looking good. I will update the git repository with the required changes – including a wayland package in “deps/” which was required for KWin to compile.
To anyone who already compiled packages and is using them, does polkit work for you?
For instance, in System Settings, if you try to change the data/time settings, you should be prompted for the root password. It is polkit that provides the prompt window and allows you to update these system settings.
However, instead of a password prompt window to appear, the SystemSettings window stops accepting mouse/keyboard input. It is probably waiting for the Polkit window to pop up and you to provide input… but in fact, no Polkit window appears.
I can not find anything missing or wrongly compiled, and I do not know what is causing this.
I want to release packages next week (Plasma 5.2.0 release date) but I am a bit worried about this broken functionality.
I had that problem, both with plasma 5.1 and 5.2beta (5.1.95), but now I’ve seen that 5.2b has more packages than 5.1 (i simply put new sources in the same dir), added them to modules/plasma and modularize, ./KDE.Slackbuild plasma et voila’, systemsettings asks for password, and the whole system start in a full KDE 5 way; while before I had splashscreen, window borders, etc coming from kde4
I would point to package polkit-kde-agent-1
Davide… damn!
I am rebuilding all of frameworks and plasma tonight, because I found a discrepancy. The files in /usr/share/dbus-1/system-services/ are pointing to files in /usr/lib64/kde4/libexec/ whereas these are in fact being installed to /usr/lib64/libexec/kauth/ … no idea why, and also I have no idea why you did not suffer from that.
I added a LIBEXEC_INSTALL_DIR to cmake/frameworks in the hope I can fix that.
On a different note, I have added several packages which add support for the systray, for GTK and Qt4 applications. That leaves only SCIM whose systemtray icon does not show up unless you install wmsystemtray.
In my VM, I could pinpoint the crashes of plasmashell to the moment where i move my mouse pointer into an application button in the status bar at the bottom. I suspect that the plasmashell error “unsupported extension used” is connected to the fact that KWin wants to show a miniature of the application window when you move the mouse over the application button.
Did not yet find how to disable that. Also, I do not yet know what to report in a bugreport.
The files in /usr/share/dbus-1/system-services pointing to /usr/lib64/kde4/libexec comes from kde-workspace-4.11.15, while the ones pointing to /usr/lib64/libexec/kauth comes from plasma-workspace-5; I did a full recompile of plasma and those files were overwritten; I think the next time I’ll recompile and install kde-workspace-4 the bug will reappear
I’m wrong, kcmclock.service comes from plasma-desktop
Could be that I forgot to re-install plasma-workspace after I found out I still had a kde-workspace package installed. I have removed kde-workspace from the package set for that reason: it clashes in a big way with plasma-workspace.
If I get the polkit/kauth stuff to work right, then the only annoying bug is the plasmashell crash in the virtual machine. But if that crash does not occur on real hardware, then there is nothing holding me back from releasing a set of packages next week.
Still need to compile the 32-bit packages though… will take another day.
I wonder… how many people reading the blog and using my KDE packages are actually using the 32-bit version?
Hallo Eric,
May be you should change your README file in git repository, replacing the
“SKIP: step (don’t understand where the compilation error comes from)”
with
“DONE: step (_whatever you want_)”
According to the eigen2 update.
Michelino