Mail archive

Re: [alpine-devel] KDE Plasma packaging in Alpine

From: Jakub Jirutka <>
Date: Fri, 27 Oct 2017 14:03:05 +0200

Awilfox, thank you for very solid technical arguments!

In the light of these arguments, I changed my mind – I’d prefer LTS version of KDE to non-LTS. Also I support adding KDE packages to Alpine, if Awilfox will help us maintaining them in long-term.

> The entire team at Adélie are dead serious about making sure that our packages are rock solid on varied hardware.
> The reason that we have not already upstreamed our KDE work is that we are still ensuring that it works *everywhere*. We have a few people volunteering to try it out on ARM, and I’m trying to bring up PPC64.

I think that this is good enough for adding them to the Alpine’s testing repository right after releasing v3.7 (so we can now focus on release).


> On 27. Oct 2017, at 4:58, A. Wilcox <> wrote:
> Signed PGP part
> On 26/10/17 16:17, Jakub Jirutka wrote:
> > Hi,
> >
> > I guess that there will be many packages depending on KDE
> > Frameworks Tier 1, right? If so, then I’m against including
> > multiple versions in aports, because it would most likely start a
> > domino effect (adding two variants even for some/all depending
> > packages). And before someone suggest it, adding LTS to community
> > and latest only to testing is NOT a solution, it’d be even worse.
> Pretty much all KDE applications, and all Tier 2/3 frameworks, will
> depend on Tier 1 frameworks. That's over 300 packages right now in
> Adélie.
> > About LTS or non-LTS: I’d definitely vote for non-LTS, the version
> > needed for postmarketOS.
> I feel like this would be a mistake for Alpine.
> First of all, I'm not sure how happy Alpine users would be at `apk
> upgrade` breaking their desktop regularly. Non-LTS releases of KDE
> are known to be wildly unstable. I have been dealing with dot
> releases causing startup issues, graphical glitches, and segmentation
> faults since the 5.2 release cycle when I was working with the Gentoo
> KDE team trying to stablise Plasma 5[1]. It has not gotten any better
> as of 5.11. LTS branches have significant resources devoted to them
> and have other distro maintainers watching for bugs as well. Non-LTS
> releases should be considered the same as 'nightly' releases.
> We already have a working KDE desktop running right now. Our copy of
> abuild calls 'die' if check() is not defined[2]. I personally run
> tests across all architectures that we support (right now, x86_64,
> x86_32, and ppc32) for each desktop package before they are pushed to
> the mirror. And those tests are on real hardware, with different
> GPUs; in fact, we have a list of computers that we test on[3].
> With the exception of 'blair', 'dha', and 'kelsey', all of the listed
> machines are in my house. (I have yet to add the test machines that
> horst_at_, aerdan@, and emyers@ have at their houses.) The entire team
> at Adélie are dead serious about making sure that our packages are
> rock solid on varied hardware.
> The reason that we have not already upstreamed our KDE work is that we
> are still ensuring that it works *everywhere*. We have a few people
> volunteering to try it out on ARM, and I'm trying to bring up PPC64.
> Meanwhile, postmarketOS seems to think that qemu passes for testing.
> It's a decent enough smoke-test when you are dealing with bootloaders
> or you don't have hardware for a niche architecture. However,
> especially when you are dealing with desktop / graphical packages,
> qemu is not going to show you problems with Mesa or OpenGL or X11
> properly. It also has a great deal of bugs in its CPU core
> emulations; I've personally patched two in the x86 core[4][5] and I
> know of more that were too difficult to patch[6]. Additionally, the
> PR needed a lot of fixes and showed a lack of familiarity not only
> with APK/abuild but also with the frameworks themselves[7]. (I have
> yet to review the second version of the PR and therefore cannot
> comment on its quality.) Everyone's new once, and I fully understand
> that and support their willingness to learn and grow. However, I feel
> that an Alpine Desktop would be better served by people who are
> *already* familiar with abuild, KDE, and contributing to Alpine. Then
> the postmarketOS developers can continue to learn, and they will be
> ready to become contributors.
> We at Adélie are working upstream with KDE to make their codebase
> ready for musl and have been since 2015[8]. I have contact with most
> of their reviewers and I am familiar with their code standards and
> processes.
> I want to bring all of these resources to Alpine upstream and provide
> Alpine with a solid, 'fancy' desktop environment beyond XFCE. And it
> would pain me greatly to see both the Alpine and postmarketOS teams
> needlessly suffer trying to maintain this large package set when we
> already have the experience and the deliverables needed.
> (Honestly, I have wondered for a while why postmarketOS does not want
> to try and fork Adélie instead of Alpine. Since KF5 is ABI stable, we
> are always tracking the current version of that anyway. They would
> only need to worry about Plasma Next. This would lower their expended
> effort so that they could focus on what makes them different. It
> would also greatly reduce the amount of code with which they need to
> become familiar.)
> All the best,
> --arw
> [1]: For a few fun ones:
> Note that this leak was only prevalent on Radeon GPUs using radeon.ko,
> so I doubt postmarketOS would even notice that one.
> This isn't even marked fixed, but was shortly before the 5.6
> announcement. 5.4 broke it. (5.8 was the first LTS release.)
> Let's not forget about this fun little show, at least all the
> corruption bugs got fixed before 5.8 LTS. (And the option to switch
> GLX <-> EGL was removed entirely.) 5.4 was truly a bad release, heh.
> [2]:
> [3]:
> [4]: was
> introduced by an error in qemu that I submitted a bug report for and
> has since been rectified.
> [5]: <
> somewhere in this thread is a patch to qemu that I sent to lkml that
> allows one to experience this bug in qemu. qemu was not emulating CR4
> correctly based on the -cpu switch, and the kernel bug wasn't caught
> because kernel devs were testing older hardware support using qemu
> instead of real CPUs.
> [6]: While fixing [5] I found a number of deficiencies in qemu's CRx
> and MSR support that would have required a significant overhaul to fix
> properly. I never bothered, opting instead of refurbish my Pentium II
> system and use it as a crash test dummy for i686 compat. That same
> Pentium II is the computer I first contributed to Alpine with - I
> authored the original py-django APKBUILD on it back in 2011.
> [7]: See my comments starting at:
> but note as above that I have not reviewed the new one yet.
> [8]: Starting with ; you
> can search their Phabricator and Bugzilla for more work we've done.
> --
> A. Wilcox (awilfox)
> Project Lead, Adélie Linux
> ---
> Unsubscribe:
> Help:
> ---

Received on Fri Oct 27 2017 - 14:03:05 UTC