Content-Type: multipart/signed; boundary="Apple-Mail=_D75703A5-06AD-40BD-B709-09CF2676418D"; protocol="application/pgp-signature"; micalg=pgp-sha384
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: [alpine-devel] KDE Plasma packaging in Alpine
From: Jakub Jirutka <jakub@jirutka.cz>
In-Reply-To: <3D888B6C-72A7-49F1-840F-82C3B7EC4876@jirutka.cz>
Date: Fri, 27 Oct 2017 14:53:08 +0200
Cc: alpine-dev <alpine-devel@lists.alpinelinux.org>
Message-Id: <1486CA1A-ECCD-43F8-AECD-6EB2EAB399FE@jirutka.cz>
References: <31b20754-2244-780f-8d98-9ed68478db30@bitmessage.ch> <3B2637BC-EC68-4BC5-85A6-D2700A2381ED@jirutka.cz> <59F2A0E7.1010804@adelielinux.org> <3D888B6C-72A7-49F1-840F-82C3B7EC4876@jirutka.cz>
To: "A. Wilcox" <awilfox@adelielinux.org>


--Apple-Mail=_D75703A5-06AD-40BD-B709-09CF2676418D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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=E2=80=99t have experience with linux desktops, but =
from what I=E2=80=99ve heard, KDE is quite a big and complex beast; it =
appears to be against Alpine=E2=80=99s philosophy simple and =
lightweight, isn=E2=80=99t it?

Jakub

> On 27. Oct 2017, at 14:03, Jakub Jirutka <jakub@jirutka.cz> wrote:
>=20
> Awilfox, thank you for very solid technical arguments!
>=20
> In the light of these arguments, I changed my mind =E2=80=93 I=E2=80=99d=
 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.
>=20
>> The entire team at Ad=C3=A9lie are dead serious about making sure =
that our packages are rock solid on varied hardware.
>>=20
>> 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=E2=80=99m trying to bring up =
PPC64.
>=20
>=20
> I think that this is good enough for adding them to the Alpine=E2=80=99s=
 testing repository right after releasing v3.7 (so we can now focus on =
release).
>=20
> Jakub
>=20
>> On 27. Oct 2017, at 4:58, A. Wilcox <awilfox@adelielinux.org> wrote:
>>=20
>> Signed PGP part
>> On 26/10/17 16:17, Jakub Jirutka wrote:
>>> Hi,
>>>=20
>>> I guess that there will be many packages depending on KDE
>>> Frameworks Tier 1, right? If so, then I=E2=80=99m 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=E2=80=99d be even =
worse.
>>=20
>>=20
>> 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=C3=A9lie.
>>=20
>>=20
>>> About LTS or non-LTS: I=E2=80=99d definitely vote for non-LTS, the =
version
>>> needed for postmarketOS.
>>=20
>>=20
>> I feel like this would be a mistake for Alpine.
>>=20
>> 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.
>>=20
>> 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].
>>=20
>> 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@, aerdan@, and emyers@ have at their houses.)  The entire team
>> at Ad=C3=A9lie are dead serious about making sure that our packages =
are
>> rock solid on varied hardware.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> We at Ad=C3=A9lie 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.
>>=20
>> 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.
>>=20
>> (Honestly, I have wondered for a while why postmarketOS does not want
>> to try and fork Ad=C3=A9lie 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.)
>>=20
>> All the best,
>> --arw
>>=20
>>=20
>>=20
>> [1]: For a few fun ones:
>>=20
>> https://bugs.gentoo.org/show_bug.cgi?id=3D570342#c5
>>=20
>> Note that this leak was only prevalent on Radeon GPUs using =
radeon.ko,
>> so I doubt postmarketOS would even notice that one.
>>=20
>> https://bugs.kde.org/show_bug.cgi?id=3D352951
>>=20
>> 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.)
>>=20
>> https://bugs.kde.org/show_bug.cgi?id=3D352548
>>=20
>> 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.
>>=20
>> [2]: https://code.foxkit.us/adelie/abuild/commit/9c4e4018
>>=20
>> [3]: https://infra.adelielinux.org/
>>=20
>> [4]: https://marc.info/?l=3Dfreebsd-current&m=3D142446699801424&w=3D2 =
was
>> introduced by an error in qemu that I submitted a bug report for and
>> has since been rectified.
>>=20
>> [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.
>>=20
>> [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.
>>=20
>> [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.
>>=20
>> [8]: Starting with https://bugs.kde.org/show_bug.cgi?id=3D352627 ; =
you
>> can search their Phabricator and Bugzilla for more work we've done.
>>=20
>> --
>> A. Wilcox (awilfox)
>> Project Lead, Ad=C3=A9lie Linux
>> http://adelielinux.org
>>=20
>>=20
>>=20
>> ---
>> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
>> Help:         alpine-devel+help@lists.alpinelinux.org
>> ---
>>=20
>=20


--Apple-Mail=_D75703A5-06AD-40BD-B709-09CF2676418D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCQAdFiEEwlgOtm6+gnC7W+06PZeHr2nsdbkFAlnzLDQACgkQPZeHr2ns
dblaxQf+NF7s6yXtqdR1qnw9O+1U2JmZMlKHxjmDAHT7ZIKqATPW0973lZUksI/v
4pQltU6VyH0c+9OkNNPtfT4MIXGXAs1mMzsmmMpRcgvgvhdmQwjx5rOovGr2YUQ3
egQZfpvulORV1jz1tOqbG2kI917fs1B44kJwWgHV2rFp1nBEWwAGuZPDxet9vYEU
ZUVRNMZreOqIaRNJHgzjJ0846CLyaG5pNM8a0hqB42fuZkhbnO5pmnmOA+Oxy8j1
tt4X6F7mbkDq8WoOhX9UxC16luAkFNCePApl4RPA+bRkab26D38BU0ZIQaru4aJH
p/EVrxq+kUAwPx9yWBmbYTgIAq/4xQ==
=A78s
-----END PGP SIGNATURE-----

--Apple-Mail=_D75703A5-06AD-40BD-B709-09CF2676418D--


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---