2017-09-05 12:10 GMT+02:00 Jonathan Riddell <j...@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