-----BEGIN PGP SIGNED MESSAGE-----
On 26/10/17 16:17, Jakub Jirutka wrote:
> 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
> 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. 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. 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.
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 and I
know of more that were too difficult to patch. 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. (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. I have contact with most
of their reviewers and I am familiar with their code standards and
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
All the best,
: 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.
introduced by an error in qemu that I submitted a bug report for and
has since been rectified.
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.
: While fixing  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.
: See my comments starting at:
but note as above that I have not reviewed the new one yet.
: Starting with https://bugs.kde.org/show_bug.cgi?id=352627
can search their Phabricator and Bugzilla for more work we've done.
A. Wilcox (awilfox)
Project Lead, Adélie Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
Received on Thu Oct 26 2017 - 21:58:47 GMT