Dear alpine-devel,
two derivatives of Alpine Linux, Adélie and postmarketOS, are working on
getting KDE Plasma upstreamed for Alpine. From the discussions in
#alpine-devel, it seems clear that Alpine developers are not against
including it and both groups are currently working together on
upstreaming KDE Frameworks Tier 1[1] (which is basically the first group
of packages, that makes sense to be upstreamed before the next group
etc.).
However, Adélie needs the LTS version (which makes sense to ship a
stable experience for desktop users), while postmarketOS needs the
latest stable (because plasma mobile[2] is still in development and
depends on that). For some context, I'm involved in the latter project.
This topic came up in #alpine-devel yesterday, and we were told, that we
should take this to the mailing list to get more opinions from Alpine
developers, especially from ncopa.
The question is: Does it make sense for Alpine to ship both versions?
In theory we could implement this by shipping the latest greatest
packages with a "-current" suffix. But then again, KDE Plasma is not
that small and means quite a lot of maintenance effort. The derivatives
would maintain the packages, but for a package or update to land in
Alpine, Alpine devs need to review and approve them, so this means
additional work for Alpine, too.
In case the answer to the question above is "no, let's do LTS only!",
kaniini suggested yesterday, that it could be possible to use Alpine's
building infrastructure to provide builds for the "-current" versions as
unsupported packages. I would also be very interested in opinions
regarding that statement. (Related alpine-infra post[3].)
Thanks for reading!
Oliver Smith
[1]: https://github.com/alpinelinux/aports/pull/2495
[2]: https://plasma-mobile.org/
[3]: https://lists.alpinelinux.org/alpine-infra/0184.html
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hello,
On Thu, Oct 26, 2017 at 4:17 PM, Jakub Jirutka <jakub@jirutka.cz> 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.>> I’m very glad that there’s someone trying to bring clean Linux distribution to mobile phones. However, we’re already quite overwhelmed and adding more and more desktop packages is a huge maintenance load. So I hope that you will also help us with maintenance.
I think that it is a very interesting project.
But they have not yet proven that it is a sustainable project, and we
shouldn't preference projects that have no actual plan to make the
project sustainable.
There has been no progress on things that seem very critical, like
making phone calls, and now the discussion seems to be shifting toward
tablets instead of phones.
> About LTS or non-LTS: I’d definitely vote for non-LTS, the version needed for postmarketOS.
Adelie will be using LTS branches.
We can upstream those in Alpine, if wanted, or not.
If the pmOS packages are accepted, we will simply continue to use our
own KDE packages.
> As I know, postmarketOS is purely OSS project not backed by any company; Adélie is backed by a company in advertisement business, so they can invest more resources to maintain it themselves.
This needs clarification.
Adelie is not backed by any pre-existing company, either.
It is however, something we are looking to run in a sustainable way,
which does mean commercial deals that make sense, because revenue
helps fund the work we are doing in Alpine (we have to pay the bills
after all).
But, the business around Adelie is pre-revenue (kinda need a finished
product and a full business plan first you know), and nobody is being
paid to work on it.
We are still figuring that out.
Only some work on Alpine is sponsored, which relates largely to
packaging required to run the business that you're talking about.
But that money is entirely separate, and that business holds no
financial interest in Adelie.
It may, in the future, use Adelie instead of Alpine, but we may use
Fedora or Debian or ArchLinux in the future on those servers.
Who knows.
Adelie both as a company, and as a project, is definitely *Alpine first*.
We want to be good actors in the Alpine community and provide Alpine
with high quality, sustainable work that brings no new technical debt
with it.
To me, and perhaps I am mistaken, but that seems like the exact
opposite of what pmOS is bringing.
They are bringing more technical debt, as you recognize yourself when
you wrote, "So I hope that you will also help us with maintenance."
Finally: I am not sure why it is the responsibility of Alpine to give
pmOS special treatment.
They are a downstream derivative, like Adelie, and they should play by
the same rules.
If you are having to hope that they stick around, that doesn't seem
like a very confident call to be making.
> postmarketOS needs aarch64 builders, right?
Seems to me they need: builders, mirrors, and skilled developers.
We haven't come forward with our KDE packaging for merge yet, to
ensure that the pmOS crew gets full opportunity for review, but it
exists and is working today in Adelie.
I would ask pmOS these questions:
* Are they willing to support the entire KDE desktop in Alpine?
* Will they fix the bugs?
* Do they actually have the capability to deliver on this?
Everyone knows where we stand, and everyone knows that the people
involved all have a proven track record.
With pmOS, it is not yet known.
I suggest reviewing their packages and seeing if they are something
you are willing to sign off on.
William
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hi,
> I’m very glad that there’s someone trying to bring clean Linux distribution to mobile phones. However, we’re already quite overwhelmed and adding more and more desktop packages is a huge maintenance load. So I hope that you will also help us with maintenance.
Yes, that would be the plan! craftyguy even volunteered to take the path of becoming an Alpine developer, and kaniini offered to be his mentor (in fact, to anyone from postmarketOS who wants to become an Alpine developer).
> As I know, postmarketOS is purely OSS project not backed by any company
True.
> postmarketOS needs aarch64 builders, right?
Binary packages for x86_64, armhf and aarch64 actually (I've learned, that not all aarch64 builders can produce armhf packages).
PS: Right now we only have packaged plasma mobile related components from KDE plasma. AFAIK we would need a few more components to get the full desktop working.
Oliver
Jakub Jirutka:
> 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.> > I’m very glad that there’s someone trying to bring clean Linux distribution to mobile phones. However, we’re already quite overwhelmed and adding more and more desktop packages is a huge maintenance load. So I hope that you will also help us with maintenance.> > About LTS or non-LTS: I’d definitely vote for non-LTS, the version needed for postmarketOS. As I know, postmarketOS is purely OSS project not backed by any company; Adélie is backed by a company in advertisement business, so they can invest more resources to maintain it themselves.> > postmarketOS needs aarch64 builders, right?> > Jakub> >> On 26. Oct 2017, at 20:57, Oliver Smith <ollieparanoid@bitmessage.ch> wrote:>>>> Dear alpine-devel,>>>> two derivatives of Alpine Linux, Adélie and postmarketOS, are working on>> getting KDE Plasma upstreamed for Alpine. From the discussions in>> #alpine-devel, it seems clear that Alpine developers are not against>> including it and both groups are currently working together on>> upstreaming KDE Frameworks Tier 1[1] (which is basically the first group>> of packages, that makes sense to be upstreamed before the next group>> etc.).>>>> However, Adélie needs the LTS version (which makes sense to ship a>> stable experience for desktop users), while postmarketOS needs the>> latest stable (because plasma mobile[2] is still in development and>> depends on that). For some context, I'm involved in the latter project.>>>> This topic came up in #alpine-devel yesterday, and we were told, that we>> should take this to the mailing list to get more opinions from Alpine>> developers, especially from ncopa.>>>> The question is: Does it make sense for Alpine to ship both versions?>>>> In theory we could implement this by shipping the latest greatest>> packages with a "-current" suffix. But then again, KDE Plasma is not>> that small and means quite a lot of maintenance effort. The derivatives>> would maintain the packages, but for a package or update to land in>> Alpine, Alpine devs need to review and approve them, so this means>> additional work for Alpine, too.>>>> In case the answer to the question above is "no, let's do LTS only!",>> kaniini suggested yesterday, that it could be possible to use Alpine's>> building infrastructure to provide builds for the "-current" versions as>> unsupported packages. I would also be very interested in opinions>> regarding that statement. (Related alpine-infra post[3].)>>>> Thanks for reading!>> Oliver Smith>>>> [1]: https://github.com/alpinelinux/aports/pull/2495>> [2]: https://plasma-mobile.org/>> [3]: https://lists.alpinelinux.org/alpine-infra/0184.html>>>>>>>> --->> Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org>> Help: alpine-devel+help@lists.alpinelinux.org>> --->>> > > > ---> Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org> Help: alpine-devel+help@lists.alpinelinux.org> ---> >
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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@, 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJZ8qDYAAoJEMspy1GSK50U/BEP/A2IZyWGbBeEwvtbHKsgwe4m
ZojwPmWNMSwRjTRt2Y2BahoPNgFYGz0VswgB4eh+0CRgZWhMVsqqM/6eKkowXNFH
JC0dCtLvjMVGE7/gEzR2PUBZtkffOfWfvEKINHtBjVCBkPVEORmvtEikNUawUY1V
FKMaYcXvNf+ifsotzmIWsnUo2pyhautUMtVbfvbEvl2VoW0JsabFY14K0tihTJFg
IgY4L5GyQAAgDXtN/5l9E3nTPk1NyuIcrKmVxkqBPK14dPE5/kTR+j74LcpGHrpV
/IW3UEiGX+ZFzjeUYXLr3mkLDW4fHjwNYachk2hV1/HgFaUkQ/N3WtObZEfo+lJg
WPZq8tPHvobqmjFej82LPngsuf0XSaGojEePGNbVJ3XeevSMW7uoZ9YQOuAM8NEQ
S9gj8BXvoCy3kYNxD5P1FdyhceDBBrg81K8B9MbZKLbqiMhqUAKFWSelv6lsXgGS
iwFRYmflqoq7ST1T94CAQavs0ii6mY7CFCmmenFFFtpJ+HzYK+8DGagM97hmpyKp
THNH4pe3aD3avIvbHbwCQYEtgPjddyncsQaNH3lsTqL/lnXgGtswXfdDn6e+2/xm
UN73iRR/R5Yvp+AKg94/rzbpj/OrGfPpnU6wV9PKh7c4pjBjW6SPVOcP0+e3Or6O
YjNzBoxnco3R1LUA6U4B
=YMhN
-----END PGP SIGNATURE-----
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
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.
I’m very glad that there’s someone trying to bring clean Linux distribution to mobile phones. However, we’re already quite overwhelmed and adding more and more desktop packages is a huge maintenance load. So I hope that you will also help us with maintenance.
About LTS or non-LTS: I’d definitely vote for non-LTS, the version needed for postmarketOS. As I know, postmarketOS is purely OSS project not backed by any company; Adélie is backed by a company in advertisement business, so they can invest more resources to maintain it themselves.
postmarketOS needs aarch64 builders, right?
Jakub
> On 26. Oct 2017, at 20:57, Oliver Smith <ollieparanoid@bitmessage.ch> wrote:> > Dear alpine-devel,> > two derivatives of Alpine Linux, Adélie and postmarketOS, are working on> getting KDE Plasma upstreamed for Alpine. From the discussions in> #alpine-devel, it seems clear that Alpine developers are not against> including it and both groups are currently working together on> upstreaming KDE Frameworks Tier 1[1] (which is basically the first group> of packages, that makes sense to be upstreamed before the next group> etc.).> > However, Adélie needs the LTS version (which makes sense to ship a> stable experience for desktop users), while postmarketOS needs the> latest stable (because plasma mobile[2] is still in development and> depends on that). For some context, I'm involved in the latter project.> > This topic came up in #alpine-devel yesterday, and we were told, that we> should take this to the mailing list to get more opinions from Alpine> developers, especially from ncopa.> > The question is: Does it make sense for Alpine to ship both versions?> > In theory we could implement this by shipping the latest greatest> packages with a "-current" suffix. But then again, KDE Plasma is not> that small and means quite a lot of maintenance effort. The derivatives> would maintain the packages, but for a package or update to land in> Alpine, Alpine devs need to review and approve them, so this means> additional work for Alpine, too.> > In case the answer to the question above is "no, let's do LTS only!",> kaniini suggested yesterday, that it could be possible to use Alpine's> building infrastructure to provide builds for the "-current" versions as> unsupported packages. I would also be very interested in opinions> regarding that statement. (Related alpine-infra post[3].)> > Thanks for reading!> Oliver Smith> > [1]: https://github.com/alpinelinux/aports/pull/2495> [2]: https://plasma-mobile.org/> [3]: https://lists.alpinelinux.org/alpine-infra/0184.html> > > > ---> Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org> Help: alpine-devel+help@lists.alpinelinux.org> --->
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 27/10/17 07:53, Jakub Jirutka wrote:
> I was thinking about desktop environments and I wonder, why did you> choose KDE and not Xfce4, LXDE or some other more lightweight > alternative?
We are working on packaging LXQt, which is the spiritual successor to
LXDE. aerdan@ has been successful at making 0.11.x mostly work, but
their latest 0.12 release has proven to be much more tricky. We are
hopeful that LXQt may be able to be merged in Alpine 3.8 as well.
Note that LXQt does use a few KDE tier 1 frameworks, so that would
need to be merged first.
I have sent some XFCE 4 fixes on to Alpine, but I know that end users
prefer "shiny" and XFCE 4 is not very "shiny".
Additionally, we offer the Alpine fluxbox and openbox packages for
lighter weight window managers.
> 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?
KDE 4 was definitely big and complex. The entire package set of KF5
was a single package, kdelibs4. They split them up for
maintainability and size reduction. Now instead of single monolithic
.so or .a taking up resident memory / disk space, the applications can
choose only what they need. Unfortunately the cost tradeoff is: more
maintainable, better code, but more work for packagers because there
are so many.
I have a 256 MB RAM computer and Plasma 5 runs happily on it. The
total RAM usage for the entire environment including udisks, upower,
and such: ~ 185 MB RAM. Not a lot of room left for heavyweights like
a Web browser, but you can certainly fit AbiWord and such.
This is certainly much more bloated than say fluxbox, which I can
squeeze in to 64 MB RAM if I really try, but that is the price you pay
for shiny :)
Overall I feel that KDE (and Qt, to a point) really are unfairly
judged for the sins of their past. The desktop environment has become
a lot better these days, especially with 5.8 LTS.
Best,
- --arw
- --
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJZ83EKAAoJEMspy1GSK50UXP8P/0bBMKUd7bRdt+gLM7MAsZrX
gnIM94k7yc6tbAjc+bih2+07YGdVR/Ga1DyQnULne99167pZ6CQDc+o3IIxWhJYm
vpRGeI0MNh9CdI5zgCeJONJfWxZAL9of8dcYuAFBhE4V10cbVVeiN8snW4nMriia
dRfTSwLOHQ7ZjmLPo6VQ4MWLJUWqWOdIrTIw58y1uNmnJhT2sAWt1tE727hzguN6
K8YJ8y11aUTcYbceNjFt6v/+3U9lLZWS+M3MBo3gFAXb1NUy2arMw1DXBF3zGTWK
UGgc0tTUmUCP25SqLHyAhPp41c11/ZsRCjNbPwlVHVdXTYNCGRZeJrw3HS/PjrbU
2GRLTcMmXg4kntKfZSPHpVIHvjnsLMJP6IQA1A9HrzOZayBaKFcaZb5EjabokDvZ
QFoy3+TdsJMpyroJOXNmL5dMYYGD2X9AmOhIOzw44z/nLmdgfaDtTvJ+cKWn/dVz
xjO+Pvhos2Gu+8P1k0j/ZKjyI3Juv5CaNFnhdWizc107UvLcsYllIiz9Pel5H8KV
m384D5EWRG/gWVRhEsOM6x2Kdvret9PYOAAPjg60V1Wsm3be/+UsFq6SBvUIvtXQ
YixVvn8r0teJzPE2wCvOaOqn1X8kOcp6dMLHBCxMN0emDaIzFiUg0pk91Wl7i0Wv
54pBumljBvpfoZia/4MA
=0Bib
-----END PGP SIGNATURE-----
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 27/10/17 11:01, Natanael Copa wrote:
> On Fri, 27 Oct 2017 14:03:05 +0200 Jakub Jirutka <jakub@jirutka.cz>> wrote:>> 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?
I'm not sure what you mean by that, but edge/testing is definitely
where I would want KDE to land until it is known to work well on Alpine.
> Needs be done carefully though. We did have some confusion with> php7 in community and testing.> >>> 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).> > 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?
The frameworks are ready. They're ABI stable and they work flawlessly
on musl. I have no doubt that they would be fine in v3.7. However,
that doesn't include the Plasma desktop, just the frameworks... which
may not be very useful without the desktop itself. See below.
> Are you ok to wait til after Alpine 3.7 release and aim for KDE> 5.12 in Alpine v3.8?
My main concern is that we still don't have any display manager
capable of launching a KDE session. So you would need to have
.xinitrc with:
exec ck-launch-session dbus-launch --exit-with-session startkde
This doesn't seem like a very nice way to do things. I highly doubt
I'll be able to get sddm to work with ConsoleKit2 before v3.7 is done
and released. After one week of work I have it communicating with CK2
but not yet creating sessions or reading the seats properly.
I can't really speak for 5.12 yet. We of course feel confident that
it will be a great release, and they have integrated a lot of our work
upstream for it. However, there's always the chance for some breakage
as there is with any package release.
I don't know when Alpine 3.8 would be shipping and I don't know when a
version freeze would happen and so on. There's not a lot of
information that I can find that talks about Alpine's release
schedule. It looks like, based on past releases, the next one would
be in May 2018? If that is the case KDE 5.12 should be very ready by
then.
FWIW, at the current rate of progress, Adélie 1.0 is probably due for
a release around January 2018. We plan to bump to kernel 4.14 and KDE
5.12 and then release Adélie 1.5 somewhere in the summer. That looks
like it would line up pretty cleanly to being based on Alpine 3.8.
No guarantees, obviously, but assuming everything I have said in this
message turns out to happen, we would probably be looking at
upstreaming KDE Plasma 5.12 in to Alpine some time in February.
As I said, I am willing to work on KDE Frameworks (KF5) integration
now but I don't know how useful those would be without something using
them.
All the best,
- --arw
- --
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJZ83RnAAoJEMspy1GSK50Uv9wP/29uF5OYS83kA8wsLSl8s43y
j0vQjSQ9b+kaK70sOV6tcIRZqUjjFP2X+WUMGDYyzIqercq2D0Wf/7cTYV4ROazP
sM5JB5fazMzPD3HQH4hyN4ZIRXKGS3pfjVDVfuEqsIk6FT96ntWvHpxqOKTsahwt
GZtyeSfVAsQCLIcmi1FjyKVQRiN2vj52P27s2EeIBljgfah31kmGISo6kD5umQwc
Uc6XLD6euOO2C3j7BYRtnrlPICuI+2ClX5ZCjoguuht26Dv5oehlt1n9gD0h2R7F
pwbFhVh3KdG5meWhWMLSEXwZ6vbJfeodS0ezJrAIsp3tV4fKNOGCul8mtgvj9toP
zwBwImdCPyzLHLwrNwKxSNP/iE1cm3Is9hW3uQAjxJPK6kAiNfg7EA8bzU45/NF0
GQVkdR6d0ETJBCN0EdJf6dRDmLHD2/6GCOc5X9NpfBCVxemB/HfO30PsSP6Nd51h
vYNI8lTp1O6/DKf2PFgG7Sr20Na7dGnDWif2IA4T7gUx+q34WHVV8CMPWbnzWega
qUVmP4RX9chu7Tdzv2j+vbBvVirNab/ar2oz/Cab8cykLnByW1bQ3gsc+RKrB3q9
N8OQsgFLBv8IgaG0QI11oWnn1HLAH9I6jDgOZQ6jU75ULRQkO6GY42t7yn2EqIBW
HY4BE8vG5iQaDLQB8N/8
=HyRa
-----END PGP SIGNATURE-----
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
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@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@, 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@lists.alpinelinux.org> Help: alpine-devel+help@lists.alpinelinux.org> --->
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@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@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@, 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@lists.alpinelinux.org>> Help: alpine-devel+help@lists.alpinelinux.org>> --->> >
On Thu, 26 Oct 2017 18:57:00 +0000
Oliver Smith <ollieparanoid@bitmessage.ch> wrote:
> Dear alpine-devel,> > two derivatives of Alpine Linux, Adélie and postmarketOS, are working on> getting KDE Plasma upstreamed for Alpine. From the discussions in> #alpine-devel, it seems clear that Alpine developers are not against> including it and both groups are currently working together on> upstreaming KDE Frameworks Tier 1[1] (which is basically the first group> of packages, that makes sense to be upstreamed before the next group> etc.).
I am very happy to see that people find Alpine useful for derivative
work. I want try my best to make things easier for both as much
possible.
> However, Adélie needs the LTS version (which makes sense to ship a> stable experience for desktop users), while postmarketOS needs the> latest stable (because plasma mobile[2] is still in development and> depends on that). For some context, I'm involved in the latter> project.
I am more worried about the maintenance work that the initial work
adding new stuff. We ship stable releases and provide bug fixes and
security fixes. To reduce the workload I would think that it makes more
sense to try aim for LTS releases.
> This topic came up in #alpine-devel yesterday, and we were told, that> we should take this to the mailing list to get more opinions from> Alpine developers, especially from ncopa.
Thank you for bringing it up. This is sort of a classic problem of
conflict of interest: you have some users that want latest and greatest
features and you have users who wants stability and rock solid.
This the reason why we do the stable releases every 6 months. People
who wants latest and greatest can use 'edge' and people who wants
stability can use stable branch.
I looked at the KDE release history[1] and it looks like:
- current LTS is 5.8 (from October 2016)
- latest stable is 5.11 (October 2017)
- next planned LTS is 5.12 (January 2018)
We have a 3.7-stable just around the corner and I think it may make
sense to wait with the KDE stuff til after the 3.7-stable release and
branch, unless the KDE 5.8 LTS is in a state where it is ready to merge.
Would it make sense to aim for KDE 5.12 for alpine v3.8?
I think I would prefer that.
> The question is: Does it make sense for Alpine to ship both versions?
We ship a main/nodejs (LTS) and a community/nodejs-current.
We ship a testing/firefox and a community/firefox-esr
This adds some extra maintenance work so I would really like to avoid
it if possible.
> In theory we could implement this by shipping the latest greatest> packages with a "-current" suffix. But then again, KDE Plasma is not> that small and means quite a lot of maintenance effort. The derivatives> would maintain the packages, but for a package or update to land in> Alpine, Alpine devs need to review and approve them, so this means> additional work for Alpine, too.
I don't think it is realistic for us to maintain both. We simply don't
have resources for that.
> In case the answer to the question above is "no, let's do LTS only!",> kaniini suggested yesterday, that it could be possible to use Alpine's> building infrastructure to provide builds for the "-current" versions as> unsupported packages. I would also be very interested in opinions> regarding that statement. (Related alpine-infra post[3].)
I want help if we have the resources. I'll followup in that thread.
Thanks!
-nc
> > Thanks for reading!> Oliver Smith> > [1]: https://github.com/alpinelinux/aports/pull/2495> [2]: https://plasma-mobile.org/> [3]: https://lists.alpinelinux.org/alpine-infra/0184.html> > > > ---> Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org> Help: alpine-devel+help@lists.alpinelinux.org> --->
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
On Fri, 27 Oct 2017 14:03:05 +0200
Jakub Jirutka <jakub@jirutka.cz> wrote:
> Awilfox, thank you for very solid technical arguments!
+1
> > 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é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).
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
> > Jakub> > > On 27. Oct 2017, at 4:58, A. Wilcox <awilfox@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@, 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@lists.alpinelinux.org> > Help: alpine-devel+help@lists.alpinelinux.org> > ---> > >
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
Hi there,
I am sorry that awilfox and kaniini had to explain themselves in lengthy posts. I didn't understand the polite pointers you were already giving, which pointed in the direction that the LTS version is suited better for Alpine.
But with all the facts on the table, it is obvious now, that Adelie's team are the experts for getting KDE into Alpine, way beyond what we could have learned about both KDE and Alpine in such a short time. There's no doubt that the LTS version is the better choice.
awilfox wrote:
> (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.)
We're not forking any distribution, we want to be an (ideally thin) layer on top and directly use and contribute to the binary packages provided by upstream. To be honest, I didn't know about the ABI stability yet. Basing on Adelie's KF5 packaging does sounds like a good idea and I'll bring it up in the postmarketOS community.
Thanks for all the answers to this thread, I have read them all multiple times and learned a lot!
Best regards,
Oliver
A. Wilcox:
> On 27/10/17 11:01, Natanael Copa wrote:>> On Fri, 27 Oct 2017 14:03:05 +0200 Jakub Jirutka <jakub@jirutka.cz>>> wrote:>>> 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?> > > I'm not sure what you mean by that, but edge/testing is definitely> where I would want KDE to land until it is known to work well on Alpine.> > >> Needs be done carefully though. We did have some confusion with>> php7 in community and testing.> >>>> 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).> >> 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?> > > The frameworks are ready. They're ABI stable and they work flawlessly> on musl. I have no doubt that they would be fine in v3.7. However,> that doesn't include the Plasma desktop, just the frameworks... which> may not be very useful without the desktop itself. See below.> > >> Are you ok to wait til after Alpine 3.7 release and aim for KDE>> 5.12 in Alpine v3.8?> > > My main concern is that we still don't have any display manager> capable of launching a KDE session. So you would need to have> .xinitrc with:> > exec ck-launch-session dbus-launch --exit-with-session startkde> > This doesn't seem like a very nice way to do things. I highly doubt> I'll be able to get sddm to work with ConsoleKit2 before v3.7 is done> and released. After one week of work I have it communicating with CK2> but not yet creating sessions or reading the seats properly.> > I can't really speak for 5.12 yet. We of course feel confident that> it will be a great release, and they have integrated a lot of our work> upstream for it. However, there's always the chance for some breakage> as there is with any package release.> > I don't know when Alpine 3.8 would be shipping and I don't know when a> version freeze would happen and so on. There's not a lot of> information that I can find that talks about Alpine's release> schedule. It looks like, based on past releases, the next one would> be in May 2018? If that is the case KDE 5.12 should be very ready by> then.> > FWIW, at the current rate of progress, Adélie 1.0 is probably due for> a release around January 2018. We plan to bump to kernel 4.14 and KDE> 5.12 and then release Adélie 1.5 somewhere in the summer. That looks> like it would line up pretty cleanly to being based on Alpine 3.8.> > No guarantees, obviously, but assuming everything I have said in this> message turns out to happen, we would probably be looking at> upstreaming KDE Plasma 5.12 in to Alpine some time in February.> > As I said, I am willing to work on KDE Frameworks (KF5) integration> now but I don't know how useful those would be without something using> them.> > > All the best,> --arw> > > > > ---> Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org> Help: alpine-devel+help@lists.alpinelinux.org> ---> >
On 10/27/2017 06:23 PM, Jakub Jirutka wrote:
> 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
Would suggest following if really going forward with it,
1. use separate folder in aports tree, eg aports/desktop or aports/kde.
M
2. have its priority lower than aports/testing (only edge build)
3. tag it as a perpetual testing folder
4. this edge build would serve as base for other spins-offs to test and
enhance, thereby giving them market selling point
Try to hold on to Alpine philosophy, but development should progress.
Funny analogy would be Alpine being raw/dark chocolate and Adélie being
Cadbury/Kit-kat/Lindt or... :-)
--
Regards,
V.Krishn
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---