Date: Fri, 27 Oct 2017 18:01:08 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Jakub Jirutka <jakub@jirutka.cz>
Cc: "A. Wilcox" <awilfox@adelielinux.org>, alpine-dev
 <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] KDE Plasma packaging in Alpine
Message-ID: <20171027180108.678254fc@ncopa-desktop.copa.dup.pw>
In-Reply-To: <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>
	<3D888B6C-72A7-49F1-840F-82C3B7EC4876@jirutka.cz>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, 27 Oct 2017 14:03:05 +0200
Jakub Jirutka <jakub@jirutka.cz> wrote:

> Awilfox, thank you for very solid technical arguments!

+1

>=20
> 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.

I prefer LTS too if possible.

We could maybe have the next version of KDE in edge/testing? similar to
what we do with firefox and firefox-esr?

Needs be done carefully though. We did have some confusion with php7 in
community and testing.

> > The entire team at Ad=E9lie 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
>=20
>=20
> 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).

I agree that we should focus on the v3.7 release now.

A. Wilcox: What is the current state of 5.8? Do you think it is
realistic to merge it now and have it working without delaying the v3.7
release too much?

Are you ok to wait til after Alpine 3.7 release and aim for KDE 5.12 in
Alpine v3.8?

-nc

>=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: =20
> > > 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. =20
> >=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=E9lie.
> >=20
> >  =20
> > > About LTS or non-LTS: I*d definitely vote for non-LTS, the version
> > > needed for postmarketOS. =20
> >=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=E9lie 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=E9lie 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=E9lie 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 w=
as
> > 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=E9lie Linux
> > http://adelielinux.org
> >=20
> >=20
> >=20
> > ---
> > Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> > Help:         alpine-devel+help@lists.alpinelinux.org
> > ---
> >  =20
>=20



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---