Packaging and License feedback

[Matthieu Gallien]

Hello Aurélien,

On jeudi 27 septembre 2018 15:35:06 CEST Aurélien COUDERC wrote:
> Le 26/09/2018 à 22:43, Matthieu Gallien a écrit :
> > Hello Aurélien,
> 
> Hi Matthieu,
> 
> > On vendredi 14 septembre 2018 00:05:27 CEST Coucouf wrote:
> >> Regarding the license headers I was in fact doing the same in parallel
> >> but
> >> have more files in my diff than you do (163 vs. 155).
> >> It may well be du to the commits that landed since I branch but you may
> >> still want to have a look at [1].
> >> At least src/qml/PassiveNotification.qml has a slightly different header
> >> is
> >> definitely missing the fix.
> > 
> > Yes, this file and maybe some others are coming from other projects and
> > thus are under LGPL v2+ that is compatible with the license of Elisa as a
> > whole.
> Ah indeed I may have overseen files that were actually LGPLv2(+) where "GNU
> Library General Public License" was the correct license naming.
> But there still a couple files in current master that have "GNU Library" +
> v3 : - autotests/elisaqmltestplugin.cpp
> - src/upnp/didlparser.cpp
> - src/upnp/upnpcontentdirectorymodel.cpp
> - src/upnp/upnpcontrolconnectionmanager.cpp
> - src/upnp/upnpcontrolcontentdirectory.cpp
> - src/upnp/upnpcontrolmediaserver.cpp
> - src/upnp/upnpdiscoverallmusic.cpp
> - src/upnp/upnplistener.cpp

Some of those files are not compiled currently. This is why I had forgotten 
them.
I should have fixed autotests/elisaqmltestplugin.cpp but somehow forgot. 
Sorry.

> > Please let me know if there are other issues preventing proper inclusion
> > in
> > Debian.
> 
> I think we’re good for an upstream point of view.
> On the Debian side there was unfortunately a previous package called "elisa"
> with a version number bigger than this project so I’m not clear yet what
> I’m going to do.
> I liked the idea of the package being just "elisa" but to avoid any version
> conflict with the older package I should version it 1.1+really0.2.1 in
> Debian and carry the +really until we catch up with the former project’s
> version. Or use another name like elisa-music-player which I find a bit
> cumbersome but would at least avoid any version conflict.

Is the epoch version number something supposed to allow to handle this ?

> 
> On another topic, I’ve made a patch to improve cover detection at [0] which
> you may want to have a look at.
> Maybe my music library is organized like crap but the current code was much
> too restrictive to find most of my covers. ;-)
> I don’t think there were unit tests for that particular code but if you want
> me to add some, directions are welcome.
> 
> Regarding cover detection I noticed while adding additional logs that Elisa
> was always trying to find covers for all sound files (probably due to the
> fact that they are known to baloo). It looks like T9082 [1] but I thought I
> would mention here in case it’s something different.

Yes, please submit it as a review request via phabricator. I have noticed that 
you now have an account. This way, we can review your patch and integrate it 
properly in Elisa repository.

> 
> 
> Lastly I’ve opened an application for a developer account on the KDE
> identity website and put you as a reference, I hope that’s fine with you.
> This would let me contribute into phabricator directly in the future.

It would be better that some patches from you get integrated in KDE projects 
before getting a KDE developper account (see https://community.kde.org/
Infrastructure/
Get_a_Developer_Account#Who_Can_Apply_For_a_KDE_Developer_Account.3F ).

Apart from this request, this is really nice to get packagers onboard.

> [0] https://framagit.org/Coucouf/elisa/tree/relax-cover-files-constraints
> [1] https://phabricator.kde.org/T9082
> 
> 
> Cheers,
> --
> Aurélien

Best regards

--
Matthieu Gallien