Content-Type: multipart/signed; boundary="Apple-Mail=_3F59D229-27C0-41BA-BC98-DB845E12CEC2"; 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: <59F2A0E7.1010804@adelielinux.org>
Date: Fri, 27 Oct 2017 14:03:05 +0200
Cc: alpine-dev <alpine-devel@lists.alpinelinux.org>
Message-Id: <3D888B6C-72A7-49F1-840F-82C3B7EC4876@jirutka.cz>
References: <31b20754-2244-780f-8d98-9ed68478db30@bitmessage.ch> <3B2637BC-EC68-4BC5-85A6-D2700A2381ED@jirutka.cz> <59F2A0E7.1010804@adelielinux.org>
To: "A. Wilcox" <awilfox@adelielinux.org>


--Apple-Mail=_3F59D229-27C0-41BA-BC98-DB845E12CEC2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Awilfox, thank you for very solid technical arguments!

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.

> 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.


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).

Jakub

> 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,
> >
> > 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


--Apple-Mail=_3F59D229-27C0-41BA-BC98-DB845E12CEC2
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+06PZeHr2nsdbkFAlnzIHkACgkQPZeHr2ns
dbkVywf8DVcCIrHPj7o7OObTIs6lmrKrPoB0Bj/oNjojgOetPAv6e0yZ7KGUotv7
T1k9jTu1jJbSCEiwHk1s/uizQnNyaOfQmZ9UYOk1tSzz4X5LjvBwYbPXEYZRC1Jj
wYr0on/bhnHzmew9G2LptWRqIugMVfPBjZIDSdo+Ry1c7HC1wqBjM5LmUdw9t1kX
UipxlLnjvGYSYlZGkpfOzQsr3ifuDfKpBZ1lwrwWovEyHTZ320VzjvybSiiQkeJc
d96lTRxoTWgsq/g9IJXdTBNE9PT9SQXZ1HYV4Az84A20DpLTgcdJqU/e0jRQ8oVd
2Jy7jaJ1XyJdxV0mZ67WL3rochhVYg==
=2hak
-----END PGP SIGNATURE-----

--Apple-Mail=_3F59D229-27C0-41BA-BC98-DB845E12CEC2--


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---