Mail archive
alpine-devel

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

From: Jakub Jirutka <jakub_at_jirutka.cz>
Date: Fri, 27 Oct 2017 14:53:08 +0200

I was thinking about desktop environments and I wonder, why did you choose KDE and not Xfce4, LXDE or some other more lightweight alternative? I don’t have experience with linux desktops, but from what I’ve heard, KDE is quite a big and complex beast; it appears to be against Alpine’s philosophy simple and lightweight, isn’t it?

Jakub

> On 27. Oct 2017, at 14:03, Jakub Jirutka <jakub_at_jirutka.cz> wrote:
>
> 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).
>
> Jakub
>
>> On 27. Oct 2017, at 4:58, A. Wilcox <awilfox_at_adelielinux.org> 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:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=570342#c5
>>
>> Note that this leak was only prevalent on Radeon GPUs using radeon.ko,
>> so I doubt postmarketOS would even notice that one.
>>
>> https://bugs.kde.org/show_bug.cgi?id=352951
>>
>> 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.)
>>
>> https://bugs.kde.org/show_bug.cgi?id=352548
>>
>> 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]: https://code.foxkit.us/adelie/abuild/commit/9c4e4018
>>
>> [3]: https://infra.adelielinux.org/
>>
>> [4]: https://marc.info/?l=freebsd-current&m=142446699801424&w=2 was
>> introduced by an error in qemu that I submitted a bug report for and
>> has since been rectified.
>>
>> [5]: http://lists.openwall.net/linux-kernel/2015/07/08/1045 <
>> 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:
>> https://github.com/alpinelinux/aports/pull/2495#issuecomment-336684141
>> but note as above that I have not reviewed the new one yet.
>>
>> [8]: Starting with https://bugs.kde.org/show_bug.cgi?id=352627 ; you
>> can search their Phabricator and Bugzilla for more work we've done.
>>
>> --
>> A. Wilcox (awilfox)
>> Project Lead, Adélie Linux
>> http://adelielinux.org
>>
>>
>>
>> ---
>> Unsubscribe: alpine-devel+unsubscribe_at_lists.alpinelinux.org
>> Help: alpine-devel+help_at_lists.alpinelinux.org
>> ---
>>
>





---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Fri Oct 27 2017 - 14:53:08 GMT