Created attachment 204487 [details] add multimedia/makemkv Unfortunately, this port leaves out the MakeMKV GUI. Although the GUI can be built with a few patches on FreeBSD, it's useless because makemkvcon (the closed source Linux binary) won't run in "guiserver" mode. See <https://www.makemkv.com/forum/viewtopic.php?f=3&t=19486> for my attempt to get upstream help with that. Still, after being on the wanted ports list for so long, I think console-only usage is better than nothing, and it works quite well for me.
Created attachment 204545 [details] add multimedia/makemkv Small improvements: - add hint to pkg-message about needed permissions of /compat/linux/tmp, so makemkvcon runs as non-root - linted manpage
Created attachment 204939 [details] add multimedia/makemkv Update to new upstream version 1.14.4 I also noticed poudriere testport issues > Warning: you need USES=ssl This is probably bogus, the port only links OpenSSL from the linux-c7 ports.
Hi Felix, so pretty impressive job, thanks very much for sharing this! I've got next question when I've done with my review of your job, it is related to '/opt' the port uses. Can we avoid this by moving needful binaries to another location? FreeBSD Handbook basically recommends to use ${PREFIX} for most cases, so that would be great to improve the port. Please let me know if you have any questions. Again, well done! Thanks very much!
Hello Sergey, The "makemkvcon" binary uses /sys/bus/scsi (which isn't provided by linsysfs) to find optical drives. Therefore I included a script to fake the relevant structure based on camcontrol output. I can't do that in the original location, because that wouldn't work on machines that have linsysfs mounted. The pathname used must not be longer than the original because I'm patching it into the makemkvcon binary with sed. /opt/makemkv looked like an obvious choice, as I could put almost everything right there and people will know it's a software package with its own directory. Maybe /compat/linux/opt/makemkv would be a better choice, but I'm not sure it's a good idea to put files there that don't come from a linux-c* port? I could also separate the linux binaries and libs (putting them in their "standard" dirs) from the faked sysfs parts. But then, where to put the latter? /etc/makemkv would be short enough, but the generated files neither are really "configuration" nor do they belong to base ... I'll gladly try to incorporate better ideas of course :) thank you very much. Best regards Felix
Created attachment 205124 [details] add multimedia/makemkv After some brief email discussion about using /opt (which definitely isn't an ideal solution), I think I came up with the best alternative here. The faked sysfs entries are now created in ${LINUXBASE}/etc/makemkv, everything else goes to its normal destination in ${LOCALBASE}. The libraries are installed to ${LOCALBASE}/lib/makemkv, to avoid cluttering the normal lib dir with "foreign" (Linux) libs. This also allows for easy migration away from "faking" sysfs stuff, once linsysfs(5) supports the files needed for makemkvcon.
Created attachment 205127 [details] add multimedia/makemkv Sorry for the noise, accidentally uploaded a patch missing my last bugfix. This one is fine and works.
Any news on this? If there's anything else I could (or should) improve, please let me know, thanks! BR, Felix
Hi Felix, I've looked through the attachment a bit and have some questions: * Why do you bundle OpenSSL -- twice, once with 1.0.1e (available in ports, security/linux-c6-openssl within the CentOS 6 userland) and once with 1.0.2k (available in ports, security/linux-c7-openssl within the CentOS 7 userland)? * Related: Have you considered submitting ports for ffmpeg (based on the CentOS RPMs in "EPEL") and fdk-aac (maybe via RpmFusion) ? Now, to the Makefile. I'm a bit wormed by calling configure three times in pre-configure, and even calling `make` there. This will probably go away once the prerequisites are outsourced, right? Cheers Johannes
- OpenSSL is NOT bundled, it's just downloaded and extracted, so the correct headers can be used during compilation. The libraries provided by linux ports are linked. - for the same reason, providing packages for ffmpeg / fdk-aac would only complicate things. they would be in different versions, depening on the linux port version installed, ffmpeg would not link fdk-aac (as recommended by makemkv), of course they would not include headers either and makemkv is typically tested against the latest versions of ffmpeg. I think static linking is pretty appropriate here.
Created attachment 206736 [details] add multimedia/makemkv build was broken by r506352, so here's an updated patch. BR, Felix
Created attachment 207137 [details] add multimedia/makemkv I received a report that building fails with linux-c6, this is because the gcc in linux-c6 doesn't understand -fstack-protector-strong. So, here's another update fixing this, also changed the rules to use the CFLAGS for the static libs as well and build everything verbose. BR, Felix
Created attachment 207714 [details] add multimedia/makemkv Update to new upstream version 1.14.5 Tested building in poudriere and ripping with my own bluray discs, works fine.
Hi Felix, The MAKEMKV and FDK licenses looks very restrictives but I can't get the reason why. Apparently some Linux distributions has available packages for this port. * https://aur.archlinux.org/packages/makemkv/ * https://packages.gentoo.org/packages/media-video/makemkv It will be nice if we can clarify the situation, because right now, by default, poudriere doesn't build the package.
Hi Rodrigo, The MakeMKV EULA is even linked in the gentoo package: https://gitweb.gentoo.org/repo/gentoo.git/plain/licenses/MakeMKV-EULA There's one sentence that may allow building a package for binary redistribution: > In addition, as a special exception, you may extract and repackage > Linux-specific part of the Software for the purpose of creating a > distribution-specific package, as long as program files and this license > remain unchanged. I'm not sure whether this is applicable to FreeBSD as well, I'm not a lawyer... but I assume it isn't because I have to patch the Linux binary in order to make it work on FreeBSD: ${PATCHELF_CMD} --set-rpath ${PREFIX}/lib/makemkv \ ${STAGEDIR}${PREFIX}/bin/makemkvcon ${REINPLACE_CMD} -e 's:/sys/bus/scsi:/etc/makemkv/:' \ ${STAGEDIR}${PREFIX}/bin/makemkvcon At least this second patch is inevitable right now, as FreeBSD's sysfs emulation doesn't have /sys/bus/scsi (therefore the port includes a script to generate a fake tree in /etc/makemkv). As of now, the GENERIC FreeBSD kernel doesn't include emulation of Linux 'sg' devices, so you have to build your own kernel to use MakeMKV anyways. Therefore, I don't think having to build the port yourself is a relevant burden. As for the fdk-aac license, it's possible to build MakeMKV without fdk-aac, but it's needed for the full featureset. I didn't implement an option so far. As far as I understand it, *this* license would allow distribution of binary packages, just not selling them. > right now, by default, poudriere doesn't build the package. I guess you mean because of the MakeMKV EULA restrictions? There's also a build problem when some other packages are installed, so I should add some BUILD_CONFLICTS, see here: https://github.com/Zirias/zfbsd-ports/issues/1 I still have to identify what exactly to put there. But this shouldn't affect building in poudriere. BR, Felix
Created attachment 212721 [details] add multimedia/makemkv New upstream version 1.15.0 This one brought a new problem: The closed-source makemkvcon utility now needs a C++ library providing CXXABI_1.3.9, which the libstdc++ from linux-c7 packages doesn't. At the moment, the only workaround is to compile a libstdc++ from GCC sources, which requires building of a whole temporary GNU toolchain targeting Linux. This requires some more ugly hacks, so I'd understand if the port in the current state can't be accepted. Unfortunately, unless either makemkv (by providing a FreeBSD binary) or the Linuxulator ports move, there's no other solution to have makemkv work on FreeBSD.
I just installed the last version in an FreeBSD 12.1-RELEASE amd64, and I have the following issues: - All commands with makemkvcon ends with a cor dump - I didn't find the correct way to access the /dev/cd0 disk I try: disc:0, dev:/dev/cd0 - after mounting /dev/cd0 in /mnt/cd I try `makemkvcon info dev:/mnt/cd` returns the following: > MakeMKV v1.15.0 linux(x64-release) started > Profile parsing error: default profile missing, using builtin default > The program can't find any usable optical drives. > Opening files on harddrive at /mnt/video_ts/ > Opening files on harddrive at /mnt/video_ts/ > Calculated BUP offset for VTS #2 does not match one in IFO header. > Calculated BUP offset for VTS #3 does not match one in IFO header. > Calculated BUP offset for VTS #5 does not match one in IFO header. > Calculated BUP offset for VTS #6 does not match one in IFO header. > Complex multiplex encountered - 13 cells and 528 VOBUs have to be scanned. This may take some time, please be patient - it can't be avoided. > Title #1 was added (80 cell(s), 1:55:08) > Complex multiplex encountered - 13 cells and 525 VOBUs have to be scanned. This may take some time, please be patient - it can't be avoided. > Angle #2 was added for title #1 > Complex multiplex encountered - 13 cells and 522 VOBUs have to be scanned. This may take some time, please be patient - it can't be avoided. > Angle #3 was added for title #1 > Title #8 has length of 1 seconds which is less than minimum title length of 120 seconds and was therefore skipped > Error 'Posix error - Input/output error' occurred while reading '/mnt/video_ts/VTS_04_4.VOB' at offset '4096' > .... > Failed to open disc > Total 0 titles > Segmentation fault (core dumped) When /mnt/cd has multiple video_ts.bup vts_*.bup vts_*.vob. I also found this page useful https://www.makemkv.com/developers/usage.txt
There's a manpage included with this port ;) makemkvcon always dumps core, at least only after finishing its work. Try the following for info about the current disk: makemkvcon info disc:0 and the following to backup title 0: makemkvcon mkv disc:0 0 . Of course, your kernel must be compiled with `device sg` -- the included `update-makemkv-drives` script will tell you so if necessary.
(In reply to Felix Palmen from comment #17) Thanks for your quick reply, I will rebuilding my kernel and try again.
and then re-run `update-makemkv-drives` -- this script is the "magic trick" to create the necessary sysfs-entries for makemkvcon to find the drive, and it's run automatically on install and *should* give a meaningful diagnostic if the kernel misses sg devices. Of course this is pretty cumbersome right now, maybe I'll try to contact the author again about an official FreeBSD version soon.
(In reply to Felix Palmen from comment #19) Ok now it works fine, I probably will come back to you today with some suggestions and improvements to better help and guide our fellow users. Thanks for your support. -- rodrigo
Hi Felix, In response to your PM, here a few things I think we can change to help future makemkv FreeBSD users: * Switch the license flag from no-auto-accept to auto-accept if you wanna have makemkv available in the pkg official repos. Otherwise people have to build the package on their own poudrière. * Indicate that a custom kernel is required in the pkg-descr file, to avoid back an forth when running the tool for the first time. Something like the following will be sufficient to me: Known issues: To find a drive on FreeBSD, part of Linux' sysfs must be faked. The script `update-makemkv-drives'has to be used to fake it. Requirements: A custom FreeBSD kernel with sg devices is required to use makemkv. See https://www.freebsd.org/doc/handbook/kernelconfig-building.html to know how to build your kernel end add the "device sg" line. Something like this can be also added to the manpage. * Maybe like other tools who has pre-run conditions we can install makemkvcon in /usr/local/share/makemkvcon/ and have a /usr/local/bin/makemkvcon shell script who calls update-makemkv-drives when required. This is _not_ mandatory but could helps. Apart from that I have no objections to commit the port.
(In reply to Rodrigo Osorio from comment #21) Thanks Rodrigo. Unfortunately, the only bullet point I can do something about is your second one. I agree it would be helpful to learn about the requirement to compile a custom kernel before building and installing the port :) Give me some time to update my patch please! As for the license, this was already discussed earlier in this PR. The current terms of the MakeMKV EULA wouldn't allow distributing the package, as it contains a modified version of the makemkvcon binary (We need rpath to find libraries, this could still be considered ok as it only modifies the ELF header, but we also need to patch the path where makemkvcon looks for the sysfs entries to detect drives ...) So IMHO, this can, at this time, only be a "build-it-yourself" port. About your final suggestion, `update-makemkv-drives` needs root privileges to write the fake sysfs entries to ${LINUXBASE}/etc/makemkv. We're not free to choose a user-writable path here, because the path (as seen by a Linux binary) must be no longer than the original `/sys/bus/scsi`, so binary patching of makemkvcon works correctly, plus it must be the same path for all users as it is hardcoded into the makemkvcon binary. Therefore I think that running `update-makemkv-drives` during installation is the best option (and telling the local admin to re-run it manually when the optical drive configuration changes).
Created attachment 213053 [details] add multimedia/makemkv Here's my take on better user guidance as suggested. The diff to the previous patch can also be found at https://github.com/Zirias/zfbsd-ports/commit/316a88763511181314de9e8fe83dbb2d2c5acaa3 which might be easier to read.
Committed, thanks.
A commit references this bug: Author: rodrigo Date: Sun Apr 5 15:09:58 UTC 2020 New revision: 530792 URL: https://svnweb.freebsd.org/changeset/ports/530792 Log: New port: multimedia/makemkv a CLI video converter from DVD This port is CLI only and leaves out the MakeMKV GUI, because makemkvcon (closed source Linux binary) won't run in guiserver mode. Also, as described in the pkg-message, it requires a custom FreeBSD kernel with the Linux SCSI generic drivers and has to be build by the final user to comply with the license terms. Work is ongoing with the author to have a FreeBSD native version of this port in the future. PR: 238004 Submitted by: Felix Palmen <felix@palmen-it.de> Changes: head/LEGAL head/multimedia/Makefile head/multimedia/makemkv/ head/multimedia/makemkv/Makefile head/multimedia/makemkv/distinfo head/multimedia/makemkv/files/ head/multimedia/makemkv/files/makemkvcon.1 head/multimedia/makemkv/files/update-makemkv-drives.in head/multimedia/makemkv/pkg-descr head/multimedia/makemkv/pkg-message head/multimedia/makemkv/pkg-plist