Created attachment 167236 [details] Patch to update multimedia/mlt - Update to 6.0.0 (no changes in multimedia/py-mlt) - Reorganize options helper (for KDE4) Upstream says it's bugfix and minor enhancement despite release versioning scheme.
Created attachment 167237 [details] Alternate patch with Qt5 support - Update to 6.0.0 - Add support of Qt5 - Reorganize options helper (for Qt toolkits)
Created attachment 167239 [details] Poudriere log on FreeBSD amd64 9.3
Created attachment 167240 [details] Poudriere log on FreeBSD amd64 9.3 with Qt5 enabled Qt5 support was tested with new non-linear video editor (Shotcut, Qt5 application. Currently too much unstable, often crashes) on FreeBSD amd64 10.2 machine.
Add 2 members (makc@ and araujo@) of the KDE team, because there's no response from Alberto (avilla@). These patches are based on bug #205439.
The first patch looks ok, you could have committed this patch long time ago with maintainer timeout. As for Qt5 support - I suggest to create a separate port for it, otherwise it ends up soon or later with two consumer ports, which requires mlt libraries compiled vs different Qt toolkits.
(In reply to Max Brazhnikov from comment #5) Agreed with the first patch. Maybe I didn't understand well your suggestion about the QT port, but sounds more clean have it as an option on mlt port instead have another qtISHI-mlt. If I'm wrong, please correct me :). NOTE: For me this port can be committed.
(In reply to Marcelo Araujo from comment #6) > Maybe I didn't understand well your suggestion about the QT port, but sounds > more clean have it as an option on mlt port instead have another qtISHI-mlt. > > If I'm wrong, please correct me :). It is fine to have toolkit options for the top level ports, but for libraries this leads to situation when one port wants Qt4 version of the library, and another one Qt5.
This patch to update multimedia/mlt to 6.0.0 also allows it to build against ffmpeg 3.0.x. The ports tree currently still has multimedia/ffmepg at version 2.8.6 because it is waiting for ports which depend on it to successfully build with the newer 3.0.x branch. Can we please mark this bug report as "blocks 207547", to allow each bug report fixing build issues with ffmpeg 3.0.x to be easily tracked?
Is there any progress on this?
A commit references this bug: Author: woodsb02 Date: Wed Jun 8 16:17:26 UTC 2016 New revision: 416546 URL: https://svnweb.freebsd.org/changeset/ports/416546 Log: multimedia/mlt: - Update to 6.2.0 - Mark KDE4 option as implying/requiring QT4 option - Move USE_KDE4=kdelibs to new options helpers - Add USE_GNOME=cairo as notified by new stage-qa error Changes this release: http://mltframework.blogspot.fr/2016/04/version-620-released.html http://mltframework.blogspot.fr/2016/02/version-600-released.html http://mltframework.blogspot.fr/2015/07/version-098-released.html This update also allows multimedia/mlt to build against ffmpeg 3.0.x. The ports tree currently still has multimedia/ffmepg at version 2.8.7, however this update is backwards compatible with ffmpeg 2.8.7. The update of multimedia/ffmpeg to 3.0.x branch is waiting for ports which depend on it to successfully build with the newer version of ffmpeg. PR: 207390 Submitted by: olivierd Approved by: avilla (maintainer timeout), mat (mentor), makc, araujo (with kde hat) Differential Revision: https://reviews.freebsd.org/D6754 Changes: head/multimedia/mlt/Makefile head/multimedia/mlt/distinfo head/multimedia/mlt/pkg-plist
Committed - thanks very much to olivierd for submitting the patch, to makc and araujo for the review on behalf of the KDE team, and to rakuco and Anton for triaging/reminding. I will mark this bug report as closed, and if someone wants to progress the qt5 port they can either re-open this bug or file a new one.