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

[Matthias Klumpp]

2017-09-05 12:10 GMT+02:00 Jonathan Riddell <jr at jriddell.org>:
> On Mon, Sep 04, 2017 at 10:56:12PM +0200, Matthias Klumpp wrote:
>> > 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.
>
> There's nobody much watching over neon's copyright analysis so I often
> don't spend much time writing long copyright files. It's more
> important to me that the code KDE releases has clear and valid
> licences and I frequently make changes in KDE directly when it doesn't,
> as well as ensuring KDE projects actually make releases so they can
> get picked up by distros and that those releases follow a licence
> policy and best release practice plus defining those policies and best
> practice.

That makes complete sense for a project like Neon, which is
KDE-centric and wants to ship new version of KDEs software as soon as
possible.
Debian has a different focus there and treats all upstreams equal, in
equally not blindly trusting their license claims. That's why
copyright reviews are made and documented in d/copyright. Of course,
that's a pointless excercise if you *are* the upstream project :D

>> 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.
>
> I'm a bit lost here. epochs are typically set to keep package sets
> consistent with each other, you can blame stephan coolo for packaging
> KDE in debian in the 1990s. I'd love to have more sharing between
> kubuntu, neon and Debian. The neon packaging automatically merges in
> debian packaging for frameworks and makes it easy for everything else
> so I merge whenever there's a benefit.

I was specifically thinking about e.g. Muon getting an epoch although
it was a completely new package, etc. It's not really an obstacle for
collaboration though.

>> 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.
>
> Why thank you, I think :)

>From just very briefly looking at the things, the Neon packaging is
often times better/more complete. I did not expect Neon to have a
better d/copyright file, so that was very surprising :-D

> We like to automate things in neon so the automated QA tools will moan
> about some thing which get fixed. It would be great if Debian and/or
> kubuntu would merge these back but I suspect it doesn't happen much.
>
> Stuff gets packaged on different schedules of course so updates happen at different times.

Right - with Neon being faster, adopting changes in Debian would make
a lot of sense though, instead of duplicating effort.

>> 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.
>
> Thanks for your bug reports, we also accept patches or bugs on
> bugs.kde.org or KDE devs can commit directly :)

Hehe ^^ - I think I'll fix that one directly then :-)

>> [...]
>> 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).
>
> Doing merges between neon/kubuntu/debian would be super awesome

I would love that! I am a member of the Debian KDE team, but the
majority of packaging work is not done by me, so I don't have that
much of a say about anything. But I could probably bring that up. The
primary person of contact about Debian KDE stuff would be maxy, I
think.
I think one of the best ways for collaboration would be merging the
Neon packaging autmatically into a branch of the corresponding Debian
packaging, so Debian can pick changes from there and ideally also send
patches back. Kubuntu was using a similar approach, but that was
stopped, so figuring out what went wrong there would likely be one of
the first things to do.

In any case, I think there is something we could do about making Neon
and KDE work better together. And also, I've put a task to investigate
fixing the Debian KDE task onto my todo list, because that one is
indeed not the best selection of packages (first thing: find out who
is actually maintaining the list).

Cheers,
    Matthias