Plasma Mobile on the Librem 5 (please ignore previous two mails)

[Matthias Klumpp]

2017-09-04 22:29 GMT+02:00 Martin Flöser <mgraesslin at kde.org>:
> Am 2017-09-04 19:51, schrieb Zlatan Todoric:
>>
>> I had pretty unstable experience with KDE in Debian, so I assume that
>> KDE community will improve that in future (we need more Debian KDE
>> maintainers!) ;)
>
> Personal opinion as a long time Debian testing user (~10 years) and KDE
> contributor following:
>
> The packaging of Debian is really not great and questionable. As an example:
> currently testing ships Qt 5.9 in combination with KWin 5.8. KWin 5.8 does
> not compile against Qt 5.9, patches exist in master and I refused to
> backport them to the 5.8 branch as that is untested. Debian shipped that
> without even consulting with upstream developers. I think that is extremely
> bad practice from a distribution. They know me, they know they could ask for
> my opinion.

That is definitely a problem. It could be that the team is overworked
though (I don't know enough here). In any case, a good relation with
upstream is key for any package maintainer, it looks like there is
definitely something lacking here.

> The task-kde does a really bad default package selection. As an example: it
> installs Konqueror as the default browser in the favorites section of the
> launcher while at the same time warning against QtWebKit based browsers in
> the release announcement.

Agreed! The KDE task interestingly isn't maintained by the KDE team
though, and last time I asked that there was no influence on it. I
doubt that. Sending a patch would definitely be accepted by the task
maintainers.
When we made Tanglu, people were amazed how well the distro was
working, and how quickly. When I looked into that, it turned out that
the more lightweight package selection was the biggest cause for that
perception.

> [...]
> And honestly I don't think it's something the Debian team cares about: it's
> much more important to have the "perfect" package.

Yes, that is required for getting things into the distribution. The
copyright analysis must be done and be good to even get into Debian,
which is something Neon was lacking last time I checked. The Kubuntu
packaging oftentimes was mediocre too (bumping epochs without reason
comes to my mind, even for new packages) - *but* that is no reason to
take the Neon packaging, fix the problems and submit the changes back
to Neon and the package to Debian. That workflow would actually help
both projects and reduce work for Debian.
But I think this is getting into a highly political area, and I don't
feel qualified to comment about why things are the way they are or
what has been tried in the past.

> After all they constantly
> re-invent the wheel instead of using the already packaged software by
> Kubuntu or KDE Neon (hopefully that improved, but looking at the recent
> commits it doesn't look like it:
> https://anonscm.debian.org/git/pkg-kde/plasma/kwin.git/commit/?id=1cf72f55228a59fb37649c8f8a29cc509a8881b1
> ).

That got me curious, and I diff'ed the Neon vs. Debian packaging.
Surprisingly, the packaging is completely disjoint. Sometimes, Debian
is better, sometimes Neon is. And it looks like Neon does take care of
the copyright file afterall, in some packages it is even *better* than
in Debian.
Also, fun bits happen, for example Debian updated your copyright in
the kwin package, Neon forgot to do that, but instead added other
copyright holders Debian missed. Also, Neon adds
"KF5IdleTimeKWinWaylandPrivatePlugin.so" to the kwin-common package,
while in Debian it's in kwin-wayland (where it belongs, I guess?).
Debian also builds proper debugsymbols using the dbgsym support in
Debian, while Neon is using legacy stuff.

> Just my 2 cents as someone who has been annoyed by the lack of collaboration
> between Kubuntu and Debian for years

>From briefly looking over it, I have to agree - this is not only slightly mad...
I know at some point, Kubuntu packaging was in Debian Git, but then it
was abandoned (I think someone in Debian complained, but I am not
certain).

Anyway, this is something PureOS and Purism could actually resolve or
help resolving (in the ideal case directly on Debian, in the worst
case only for PureOS).

Cheers,
    Matthias