Created attachment 197437 [details] svn diff of the changes Upstream is producing its own binaries now in an effort to close some of the source code. As upstream packager, the current maintainer has agreed that I take over the package updates on behalf of upstream from now on.
(In reply to Maxime Gauduin from comment #0) Since this maintained by another person, the current maintainer will need to ok for you to adopt the port, or work with each other; unless the possibility that current maintainer doesn't respond to this request for some time. Usually two weeks or greater.
Hi Maxime, Thanks for your submission, and sorry for the delay. It looks like quite good quality work, but I have a few comments/questions on this before we commit this change. -# Created by: Ben Woods <woodsb02@FreeBSD.org> These lines typically remain as a record of the person that initially created the port in the FreeBSD repository. But I am ok if you want to remove this. -COMMENT= Home media server built using mono and other open source technologies +COMMENT= Emby Server Please ensure the comment explains a little about what this program does -LICENSE= GPLv2 -LICENSE_FILE= ${WRKSRC}/LICENSE.md +LICENSE= UNKNOWN +LICENSE_NAME= custom +LICENSE_FILE= ${WRKSRC}/license.docx +LICENSE_PERMS= dist-mirror no-dist-sell pkg-mirror no-pkg-sell auto-accept Is emby no longer open source? The GitHub repo still seems to suggest it is released under GPLv2: https://github.com/MediaBrowser/Emby/blob/master/LICENSE.md +NO_BUILD= true My preference is to download the source code and have the FreeBSD packaging servers compile it. This way users can be sure the binaries were compiled from the source code, and not some modified version of the code. That said, if emby really want to build their own binaries, that is ok too. - @${MKDIR} ${STAGEDIR}${PREFIX}/lib/emby-server + @${MKDIR} ${STAGEDIR}${PREFIX}/opt/emby-server Please do not install programs under ${PREFIX}/opt/ by default, as this doesn't follow hier(7) https://man.freebsd.org/hier. The "PREFIX" variable is one that the end-user gets to define whether they want it to be the default /usr/local or whether they want it to be /opt/. --- multimedia/emby-server/pkg-descr (revision 480602) +++ multimedia/emby-server/pkg-descr (working copy) @@ -1,9 +1, @@ -Emby Server is a home media server built on top of other popular -open source technologies such as Service Stack, jQuery, jQuery mobile, -and Mono. - -It features a REST-based api with built-in documention to facilitate -client development. We also have client libraries for our api to enable -rapid development. - -WWW: https://emby.media/ +Emby Server is a personal media server with apps on just about every device Please keep a good description of the product in pkg-descr, and ensure it references the website with a WWW link. --- multimedia/emby-server/pkg-plist (revision 480602) +++ multimedia/emby-server/pkg-plist (working copy) +opt/emby-server/bin/ffmpeg +opt/emby-server/bin/ffprobe Is it really necessary to bundle your own version of ffmpeg and ffprobe? This makes it very difficult for pkg-audit(8) to describe if users have vulnerabilities with their installed software. It also puts the ownous on the emby team to ensure they release updates for the ffmpeg bundled with emby whenever a new ffmpeg vulnerability is announced. Instead, we can just try making a case for the additional compile-time options to be enabled in the version of ffmpeg delivered by FreeBSD packages by default - can you please describe what these are? I believe LAME might be the only challenge, but we can work on the others.
(In reply to Ben Woods from comment #2) Hi Ben, I didn't mean to delete the credits line, I'm awfully sorry, we do the same thing on Arch Linux, I understand its importance very well. Indeed, emby is no longer open source, the mono code is, but the .NET core code this new package is based upon is stored on a private repository. This is why I went with the NO_BUILD approach. The rationale behind shipping our own ffmpeg binaries is twofold: we are no longer using vanilla ffmpeg but our own fork with enhancements tailored to our use (of course the source code is available on request), and we need the package to be fully working out of the box for the official FreeNAS plugin. I am personally pushing for always having the latest and greatest and will make sure that ffmpeg is always up to date. Being the ffmpeg maintainer over at Arch Linux I'm aware of potential vulnerabilities early in the process. As for /opt, thanks for the link to the HIER. Coming from the linux, I was more familiar with the FHS standard, I will change opt back to lib. I'll also update the comment and pkg-descr with something more verbose. I will submit a new diff soon.
Created attachment 198307 [details] new svn diff of the changes Please find attached the new svn diff. I realized I forgot to diff my changes to the service file last time, apologies.
A commit references this bug: Author: woodsb02 Date: Sun Oct 28 14:57:53 UTC 2018 New revision: 483303 URL: https://svnweb.freebsd.org/changeset/ports/483303 Log: multimedia/emby-server: Update to 3.5.3.0 - Change license details, as emby is no longer open source - No longer compiles from source, instead downloads pre-built binaries - Change maintainer to submitter PR: 231669 Submitted by: Maxime Gauduin <alucryd@archlinux.org> Changes: head/multimedia/emby-server/Makefile head/multimedia/emby-server/distinfo head/multimedia/emby-server/files/emby-server.in head/multimedia/emby-server/pkg-descr head/multimedia/emby-server/pkg-plist
Committed (with some minor changes to satisfy portlint). Thanks!