Remember when everybody was so excited that the KDE developers abandoned their “monolithic” release schedule where all the software was stamped with the same version number and released as a “Software Compilation”…
There have been a number of releases for the KDE Frameworks 5 and Plasma 5 (which depend on the Frameworks) in decoupled release schedules. To me it is clear that the developers are not (yet) ready for this. Their workflows appear to be such that they write code which depends on other modules’ code which only exists in a Git repository. With the old “Software Compilation” that was never an issue since all these sources would be released simultaneously. Nowadays we are facing independent release schedules and what is the (expected) result? Software starts breaking down because not all of the git code is being released at the time when the dependent code gets released.
Therefore I refuse to build and release Slackware packages for the latest/pending “KDE 5” software set, consisting of Frameworks 5.3.0 (in part 5.3.1 now, apparently) and Plasma 5.1.0. It is a freaking mess with updates, reverts and apologies all abound on the mailinglists. Get your act together! In emergency and disaster responce training, you’ll learn that it’s all about communication. IT is no different in software development. In the “bazaar” model, it is still required of people to coordinate the joint effort or else you’ll end up with a pile of loose sand instead of something solid and useful. Coordination is communication during, not after the events.
Knowing the KDE community, the future releases of the KDE 5 components will gradually reach mature levels again.
And hey! There still is the good old KDE4. A set of Slackware packages for KDE 4.14.2 is ready for you to download and install as of now. The source release was made public earlier today. As expected from KDE4, it is all about bugfixes and stability enhancements.
None of the dependencies I maintain for KDE 4 had to be upgraded in comparison with my previous release of KDE 4.14.1 packages. KDE 4.14.2 bundles the sources of kactivities-4.13.3 (taken from the KDE 4.13 major release) because no new tarball is being made available. For kde-workspace, an update to 4.11.13 was provided by the developers. I promise that I will have gstreamer-1 packages done for the KDE 4.14.3 release and build artikulate (fingers crossed)!
How to upgrade to KDE 4.14.2 ?
You will find all the installation/upgrade instructions that you need in the accompanying README file. That README also contains basic information for KDE recompilation using the provided SlackBuild script.
You are strongly advised to read and follow these installation/upgrade instructions! Note that this is only useful for you if you are running slackware-current, i.e. our development version. If you are running SLackware 14.1 then there’s still a fairly recent KDE 4.13.3 for you.
Where to find Slackware packages for KDE ?
Download locations are listed below.
You will find the KDE 4.14.2 sources in ./source/4.14.2/ and packages in /current/4.14.2/ subdirectories.
Note that I have symlinks in place (useful for users of a package manager and running slackware-current) so that ./current/latest/ will always point to the latest stable KDE release, and ./current/testing/ will always point to the most recent testing release (currently that’s Frameworks 5 and Plasma 5). Let’s hope there will be something fresh in that “testing” area soon.
Using a mirror is preferred because you get more bandwidth from a mirror and it’s friendlier to the owners of the master server!
- http://alien.slackbook.org/ktown/ (the master repository), rsync URI: rsync://alien.slackbook.org/alien/ktown/
- http://taper.alienbase.nl/mirrors/alien-kde/ (my fast US mirror), rsync URI: rsync://taper.alienbase.nl/mirrors/alien-kde/
- http://repo.ukdw.ac.id/alien-kde/ (willysr’s Indonesian mirror), rsync URI: rsync://repo.ukdw.ac.id/alien-kde/
- http://slackware.org.uk/people/alien-kde/ (fast UK based mirror, run by Darren Austin), rsync URI: rsync://slackware.org.uk/people/alien-kde/
Have fun! Eric
Thank you Eric!! Let’s hope the KDE 5 situation gets sorted out soon.
I admit I cringed when I read “good old KDE4”. I’m running a slightly modified KDE 4.10.5 on Slackware64 14.1 on my main workstation, and only recently did the thought cross my mind that KDE4 has at last reached the level of maturity and reliability that KDE 3.5.10 provided. Frankly, I wouldn’t mind using 4.x for at least the next five years or so, with incremental bugfixes published periodically until the whole thing is as virtually bug-free as, say, LaTeX.
http://www.phoronix.com/scan.php?page=news_item&px=MTgxNTI
relax, relax. Yes, there are some issues, but hey, we just started doing this. Sure we will get our act together, but can we have a little room for mistakes? Remember, without making mistakes, you can’t learn… Goes for communities as much as for individuals.
If you really don’t want to be bothered by learning processes, give something new at least half a year to mature – we started with this just a few months ago… I suggest to try again in 2015.
Hi Jos, I understand that people need to get used to the changes. I have high regard for KDE’s release management, but during the past weeks I saw what happens when eager programmers scratch their own itch instead of connecting to the bigger picture. The KDE PR needs to get a bit more focus to the inside. With Martin’s insistence to entangle KWin with systemd/logind even for X.Org platforms, I actually have my doubts about maintaining my own focus on KDE 5 for Slackware. It is timeconsuming for me, without a “pot of gold at the end of the rainbow” in the shape of a fully functional Slackware KDE5 desktop, the rewards are diminishing.
You know, I have problems taking your ranting serious as long as you bring up things like that I insist to entangle KWin with systemd. It’s so ridiculous who some people are allergic to everything of the systemd world, when all we want to use is one D-Bus interface which is not bound to logind.
Martin, Slackware is a small distro with a small support team and no actual developers on board. We use the software which is made available by free software developers like you. And we would not be able to deliver without the work of all those people.
And I do respect you for your work, as well as for who you are and your opinions. I just happen to disagree with some of the choices you make. And since I can not contribute to your code (I would not know where to begin) I either accept what you create, or find something else to fill the gap. There is still a world where systemd is not abundant, you know. Those are the choices that *I* make.
Like you, I listen to and answer to my audience, and mine is not per sé KDE minded. My perspective is a lot broader than a Window Manager.
You maintain your point of view that systemd is not needed for KWin, which is only partly correct. I would need systemd/logind and despite the fact that the systemd faction states that their software is not monolithic, the individual components can not be separated on a source code level nor on a binary level. That means, the door remains closed for systemd/logind in my house, and only if the BSD cleanroom implementation “systembsd” proves a viable alternative, will I be able to add a fully supported KWin in KDE 5. I am a KDE 4 fan (should be obvious) but to the extent that it can be offered to Slackware users uncrippled. I never was a KDE 3 fan (used Gnome 2 instead) and I do not want to have history repeat itself.
> I would need systemd/logind
no, you don’t. You need one subset of an interface from logind. There are currently to my knowledge 3 implementations of logind: logind as part of systemd, logind-shim as used by Ubuntu without systemd and now an independent implementation for the BSDs. Saying that KWin will require systemd is just wrong and I don’t want to hear that argument any more.
Also the interface we need is extremely small and one could implement a binary emulating it and I have already said that I’m open to take that into KWin source tree.
RE; KDE 4.14.2.
When re-starting rc.networkmanager in a Konsole, the console stays open, but the entire underlying screen goes black for several seconds, then returns and the following error message appears plasma shell “handler”:
******
Application: Plasma Desktop Shell (plasma-desktop), signal: Segmentation fault
[Current thread is 1 (process 1090)]
Thread 1 (process 1090):
#0 0x00007f7a2c45f6fd in ?? ()
#1 0x0000000000000000 in ?? ()
*****
Just FYI.
Hi cwizardone
Stopping and restarting the NetworkManager while you are inside an X session? That is asking for trouble. You are yanking the bottom from underneath lots of KDE network related services.
The init scripts should never be run in runlevel 4 or when running an X session.
Slackware + Cinnamon = A great system
However systemd everything breaks down. I don’t like Cinnamon systemd, however, it requires. Perhaps Slackware goes on BSD kernel, there is environment Bleu lumina graphics?
Alien Bob said,
>Stopping and restarting the NetworkManager while you >are inside an X session? That is asking for trouble. You >are yanking the bottom from underneath lots of KDE >network related services.
>The init scripts should never be run in runlevel 4 or when >running an X session.
Interesting as it has never been a problem with Xfce or previous versions of KDE.
Oh, well. Learn something new everyday.
🙂
So I’ve fact-checked Martin Gräßlin’s comment above: “There are currently to my knowledge 3 implementations of logind: logind as part of systemd, logind-shim as used by Ubuntu without systemd and now an independent implementation for the BSDs.”
And it turns out to be plain wrong.
There is no such thing as “logind-shim as used by Ubuntu without systemd”. If he means systemd-shim as used by Debian, it does not contain an implementation of logind. It merely allows the use of systemd’s logind without running systemd’s pid 1.
I should not need to point out that “and now an independent implementation for the BSDs” is no use for Linux until there is a Linux port; there is no Linux port, no roadmap for a Linux port, and in fact not even yet a roadmap for an OpenBSD release (it currently exists only on a personal cgit repo).
Does Martin promise that we will only ever need that “one subset of an interface from logind”? Does Martin promise that he will wait until the only other implementation of logind is actually available for Linux? If the answers are No and No, then “Saying that KWin will require systemd” is exactly right, even if he doesn’t want to hear that argument any more.
Geesh, I don’t see it! I just can’t see the problem. Slackware says they don’t develop, just use what’s out there, then have the nerve to say how SystemD ruins everything. How do you know? Have you installed it and ran it? I’m not what you call a “fan” of SystemD, but stop reading someone else’s opinion and then parroting it out as your own. Run it and report your REAL problems with it.
Oooo… an anonymous coward! I thought they only appeared on SlashDot?
It’s too silly to even answer this though. But I’ll bite:
I do not have to rebuild Slackware to put systemd at its core, to be able to judge it.
We do not develop software, but we are still developers! In fact, we are developing a stable OS here.
If you were a software developer yourself, you would realize that the implementation of any software starts with a requirements and specifications phase. You read the documented interface (API) of the software that matches your requirements and meets the specs, and then you start implementing.
What does that mean? We look at the things we want from Slackware and what we need to do to reach our goal. We look at “OS building blocks” that meet these requirements and we try to understand these building blocks’ interfaces to find how they match with our specs. And guess what? Systemd came out to the rubbish heap! It does not pass any of my evaluations. No need to build and implement it because it is a complete waste, savvy?
Hello,
I tested your kde-4.14.3 compilation.
I run it on 2 computers and each of them has got the same problem with konqueror.
On some pages it crashes (segfault) with khtml (www.wp.pl)
When I try webkit engine as default – web sites don’t load.
I don’t see any other problems with it.
I can confirm, that the problem is related to adblock option. When I deactivate it – khtml and webkit engines works without problems.
When I reset my filters and automatic filters lists – the problem exists (with adblock option active)
Hi y0g1 – time to create a bug report on bugs.kde.org then!
I have to do more tests.
I checked kde 4.14.3 on my wife’s archlinux installation and there is no problems.
Could you test your setup? Maybe something is wrong with my setup / drivers?
Was the 4.14.3 update the last we will see for KDE 4.14 series?
Hi cwizardone,
Yes, see https://techbase.kde.org/Schedules/KDE4/4.14_Release_Schedule#Tuesday.2C_November_11.2C_2014:_KDE_SC_4.14.3_release
If any critical bugs are discovered, they will probably take the shape of individual package updates.
^
Thanks for the information.
Greatly appreciated.
Merry Christmas to You and Yours!
First was Gnome to be dropped from “official support” (yes there are ways to get it working in Slackware), now with the increasing fiddling of systemd everywhere, will KDE get the ax too in the future?
Let’s say that KDE get’s entangled with systemd in the future, will Slackware dropp it’s support?
If maintaining KDE would become too much work, or if the philosophy behind KDE would deviate too much from Slackware’s, then it could be dropped.
But such a decision is not relevant today, and will not be relevant for years to come.
By the time Slackware is ready to move from KDE 4 to something newer, we will probably be two Slackware releases into the future. If by that time, BSD’s systembsd has seen a working release, adopting a KDE with systemd dependencies may be a lot easier for Slackware.