Packaging review for the Elisa music player

[Aurélien COUDERC]

Hi Pino,

thanks for the additional review.

Le 13/01/2019 à 23:45, Pino Toscano a écrit :
> In data domenica 13 gennaio 2019 21:24:33 CET, Aurélien COUDERC ha scritto:
>> I’ve updated to the latest upstream version and made various cleanups so it
>> should be in a releasable state now.
>> I’ve become a DD in the meantime so I can do the upload myself. Still I’d
>> appreciate if you could give the repo a look and send me a quick ack.
> 
> I just committed the removal of two empty files, debian/patches/series,
> and debian/TODO.Debian (no point having them empty).

Thanks.

> Few of notes from my side:
> 
> - using the debian-qt-kde.mk makefile was generally considered
> "reserved" only for what in the past were "kde" packages, now
> kf5/plasma/applications; for extragear stuff, just using plain dh with
> the kf5 addon should be fine (remember to uncomment the as-needed
> linking)

Done.
As to why these 2 changes would be linked remains mysterious to me.
I’m not well versed in library linking but docs / explanation welcome if
the reason is reasonably understandable.

 
> - I see elisa has no command line options, and the debian/elisa.1 man
> page is just a stub generated by help2man; IMHO it is not useful, as
> it does not provide anything more than what --help says, and so I'd
> remove it; my position on man pages is that, if they are really
> needed/requested, then they should be requested upstream, so they can
> be maintained, translated, and shipped directly by packaging elisa;
> we had too many cases of local Debian man pages that were not updated
> after the initial commit, rotting for years...

Done.
I also silenced lintian if that’s ok.
 
> - elisa seems heavily based on QML, although there are no runtime
> dependencies on QML modules

Ah yes. :(
Fixed.

> - all the build dependencies are unversioned, even if the upstream
> requirements are sort of recent versions of ECM/Qt5/KF5; considering
> that from time to time there are people that try to backport packages
> in testing/unstable to stable for their own use, usually setting the
> right versions (if required) helps not wasting their time; personally,
> I do not set a minimum version of a build requirement if stable fulfils
> it already

Done.
I hadn’t considered backporting.

> - autopkgtest is meant to test packages as available in the archive,
> not to be a generic CI for running the test suite on a new package
> build; the current 'testsuite' autopkgtest does not test the in-archive
> package, and as such it is not a valid autopkgtest test (and it can
> even produce wrong results)

Right, I removed this.


I also bumped debhelper-compat to 12.


If nothing more pops up I’ll push it through NEW.


Cheers,
--
Coucouf