Upload to Debian

[infinity0]

Hi, I'm a Debian Developer (with upload rights) and am interested in sponsoring or maintaining this package. I see you already have some Debian packaging files. Would you be interested in working with me to get this into Debian officially?

[godly-devotion]

That would be awesome. Although I did attempt to create Debian packages I'm not sure if it needs to be fixed.

[infinity0]

Great! I have filed an Intent-To-Package and will go about reviewing the existing packaging soon, hopefully in the next few days.

[godly-devotion]

Thanks.

[infinity0]

Hey I just had a look and (with some tweaks) it builds well. Thanks! Some things that should be fixed upstream before I can upload it to Debian are:

• the translation files mention things like "Material Design icons" "Retro Cassette image" where the copyright belongs to other people, however I can't find these resources in the actual baka repo. The text seems to be copied from mpv; if it's not applicable to baka can you please just remove it to be less confusing?

• you have etc/fonts/Noto* belonging to Google but it doesn't seem you're actually installing it to the end user's system. Is it possible to just get rid of it?

• I also get these:

  dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/baka-mplayer/usr/bin/baka-mplayer was not linked against libpthread.so.0 (it uses none of the library's symbols)
  dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/baka-mplayer/usr/bin/baka-mplayer was not linked against libQt5Svg.so.5 (it uses none of the library's symbols)
  dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/baka-mplayer/usr/bin/baka-mplayer was not linked against libGL.so.1 (it uses none of the library's symbols)
  

  which means you're linking against unnecessary libraries in the build. You can try removing -l flags, which would result in a smaller dependency burden for your users.

• The build process changes the src/translation/baka-mplayer_*.ts source files. This is not vital to fix, but could make it annoying for people to debug the Debian package, because it is built outside of any VCS system that lets the builder see what the files looked like previously.

• It makes it easier for Debian if you remove the debian/ directory from the master branch, as well as release tarballs. Then either:

  • You can have a debian branch in this git repo, and you be the sole point-of-contact for Debian-related bugs, or
  • We can maintain it in a separate repo on Debian infrastructure (like what I've done for gnome-mpv) and other Debian maintainers can have access to it to fix things, as well as you - you just need to create an account on Alioth.

• There are also various other changes needed to the Debian packaging files, but I have already fixed them locally, and it would be easier for me to show you guys once the previous issue (wrt debian/) is resolved.

[infinity0]

Oh another thing, please could you clarify if the license is "GPL-2 only" or "GPL-2 or later"?

[infinity0]

One more minor thing that I missed:

• The Makefile should remove src/translations/*.qm when doing clean, since it gets created by it too.

[infinity0]

https://mentors.debian.net/package/baka-mplayer - preliminary package here and once we've resolved the above, we can upload.

[godly-devotion]

Thanks for getting back to us.

• Some svgs I used originated from Google's Material Design icon repo (albeit modified by me). Retro Cassette image refers to /src/img/album-art.png.
• I guess that could be removed. I did code the UI (css) with Noto Sans font in consideration (ex. the index numbers on next/previous buttons). I'm not sure whether we should install it for the user, set it as optional (?), or just remove it. What would be "best practice" in your opinion?
• (skip for @u8sand)
• (also for @u8sand)
• I can create an account for Alioth.

Also we are doing a large code base refractoring and plan to change the name to mochi-player as soon as the refractoring is done and uploaded. We plan to upload it to the https://github.com/mochi-player/mochi-player repository.

@u8sand Approximately when do you think the refractored and renamed project can be uploaded to https://github.com/mochi-player/mochi-player? @infinity0 Do you recommend we wait until that's done or will it be ok to go ahead now?

[infinity0]

• svgs / other resources: whoops, yes I was a bit slack in looking for those, thanks for the pointers.
• noto sans font: Debian has a noto-fonts package so I will just use that and ignore the copy here. IMO best practise would be to remove the embedded copy and tell your users to install it like any other dependency - just like how you list youtube-dl as optional in README. (Google changed the license from Apache 2.0 to OFL recently too, so if you keep it embedded you have some extra things to track.)

Depends on the time frame - I'd rather not have to do packaging twice in a short period of time. :p How much work is there left for the rename, and is the structure significantly different from this one?

For Debian, it is quite important to know the license exactly - is this GPL-2, or GPL-2-or-later?

[godly-devotion]

Code structure is not radically different, just trying to decrease dependency between classes. As for license, I'm not actually sure. We chose GPLv2 just because of the fact that it allows it to be always distributed as FOSS.

[godly-devotion]

Also I spoke with @u8sand and it seems it's going to take a while because we're both busy. Honestly speaking I don't mind if Baka isn't packaged as I find mochi-player to be much superior.

[jbeich]

As for license, I'm not actually sure. We chose GPLv2 just because of the fact that it allows it to be always distributed as FOSS.

Without "or (at your option) any later version" clause documented somewhere the code is incompatible with GPLv3 or whatever version FSF issues later. Not sure if it applies to libavcodec, as used by libmpv, which may contain GPLv3 codecs (see --enable-version3). However, adding the clause now is probably the same as changing license i.e., it requires agreement from all past contributors[1]. IANAL, of course.

[1] example: https://github.com/mpv-player/mpv/issues/2033

[u8sand]

@jbeich I don't believe either me or @godly-devotion are very familiar with the licenses. In the root directory we've had the LICENSE file, is that not enough to comply (also fyi https://github.com/u8sand/Baka-MPlayer/blob/master/LICENSE#L243 has that particular clause)? If we're missing something in particular, please point it out to us. We want to be in compliance with the licenses.

[infinity0]

@u8sand in terms of publishing source code, you are in compliance. However, a "GPL-2 only" license prevents people (including yourselves) from linking[*] your code against certain codecs - e.g. see see libavcodec-extra as @jbeich earlier pointed out. If you want to fix this you need to re-license to "GPL-2 or later" (which includes GPL-3, which is compatible with those other Apache 2.0 codecs).

The sentence in the GPL that you pointed to starts "if the Program specifies". But Baka-MPlayer hasn't specified this. The LICENSE file is just the GPL-2 as a list of conditions, but there is no statement that this list of conditions actually applies to Baka-MPlayer - so we (as outsiders) have to assume "GPL-2 only". So yes, to make this "GPL-2 or later" you would have to repeat what mpv did with that re-licensing.

[*] more specifically, linking and then redistributing this. The GPL doesn't stop you doing what you want with private copies. I'm not sure of the legal situation if we build against a libavcodec (w/o extra codecs) that is GPL-2+ but then allow users to themselves link against libavcodec-extra. Possibly this is a way of bypassing the requirement of being compatible with Apache 2.0. But it's still nice not to have to play such tricks, and it's unclear if distributions other than Debian make this possible for users - so I still recommend re-licensing to "GPL-2 or later".

[godly-devotion]

@infinity0 Between making it "version 2 or later" or just "version 3", what do you recommend? Baka MPlayer's license will probably not change but we can change its successor mochi-player's license.

[infinity0]

@godly-devotion I'd recommend "version 2 or later" because it's more flexible for the future and also matches mpv - but this is just an initial thought, I haven't looked too closely at the details of this situation.