No.MLT uses additional features which have not yet been merged into libebur128:https://github.com/jiixyj/libebur128/pull/49https://github.com/jiixyj/libebur128/pull/51We will have to keep using our own fork until the changes are merged and released in libebur128.Is there any way to get an exception to the Debian rule and allow the internal ebur128 to be used until the features are released by libebur1238?~Brian

Thanks for your update, I thought a merge TO mlt is missing. Since it"just" provides additonal features I do not see a good chance to providethe fork within Debian (and Ubuntu and so on pulls from Debian) :( I maybe forced later to remove it again.

In oct/nov we will freeze our testing/stretch, so I hope libebur willmerge the pull requests in the next time so that I still can providethese features for stretch

Post by Brian MatherlyNo.MLT uses additional features which have not yet been merged intohttps://github.com/jiixyj/libebur128/pull/49https://github.com/jiixyj/libebur128/pull/51We will have to keep using our own fork until the changes are mergedand released in libebur128.Is there any way to get an exception to the Debian rule and allow theinternal ebur128 to be used until the features are released bylibebur1238?~Brian------------------------------------------------------------------------*Sent:* Friday, July 8, 2016 5:55 AM*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update internallibebur128 to version 1.1.0Hi

Will the next mlt version then have the option to link against thesystem libebur version?------------------------------------------------------------------------------Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in SanFrancisco, CA to explore cutting-edge tech and listen to tech luminariespresent their vision of the future. This family event has something foreveryone, including kids. Get more information and register today.http://sdm.link/attshape_______________________________________________Mlt-devel mailing listhttps://lists.sourceforge.net/lists/listinfo/mlt-devel

Hmm. Ok. I don't really understand the policy. I feel like it unnecessarily withholds valuable features from the users. What if I rename the files and reorganize the code so that it no longer resembles libebur128 - and there is no hope of ever merging changes between the two code bases? Then, would the policy no longer apply? After 6 months I am tired of waiting for libebur128 to accept (or reject) the pull requests.

Thanks for your update, I thought a merge TO mlt is missing. Since it "just" provides additonal features I do not see a good chance to provide the fork within Debian (and Ubuntu and so on pulls from Debian) :( I may be forced later to remove it again. In oct/nov we will freeze our testing/stretch, so I hope libebur will merge the pull requests in the next time so that I still can provide these features for stretch

Am 08.07.2016 um 15:21 schrieb Brian Matherly:

No.MLT uses additional features which have not yet been merged into libebur128: https://github.com/jiixyj/libebur128/pull/49 https://github.com/jiixyj/libebur128/pull/51 We will have to keep using our own fork until the changes are merged and released in libebur128.Is there any way to get an exception to the Debian rule and allow the internal ebur128 to be used until the features are released by libebur1238?~Brian

Will the next mlt version then have the option to link against thesystem libebur version?

------------------------------------------------------------------------------Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in SanFrancisco, CA to explore cutting-edge tech and listen to tech luminariespresent their vision of the future. This family event has something foreveryone, including kids. Get more information and register today.http://sdm.link/attshape_______________________________________________Mlt-devel mailing listMlt-***@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/mlt-devel

You do not need to abide by their policy. This is a clear fork oflibebur128. Let them figure out what they want to do about it. Debian cansimply disable that module if they feel the need.

Post by Brian MatherlyHmm. Ok. I don't really understand the policy. I feel like itunnecessarily withholds valuable features from the users. What if I renamethe files and reorganize the code so that it no longer resembles libebur128- and there is no hope of ever merging changes between the two code bases?Then, would the policy no longer apply? After 6 months I am tired ofwaiting for libebur128 to accept (or reject) the pull requests.~Brian------------------------------*Sent:* Friday, July 8, 2016 1:39 PM*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update internallibebur128 to version 1.1.0Thanks for your update, I thought a merge TO mlt is missing. Since it"just" provides additonal features I do not see a good chance to providethe fork within Debian (and Ubuntu and so on pulls from Debian) :( I may beforced later to remove it again.In oct/nov we will freeze our testing/stretch, so I hope libebur willmerge the pull requests in the next time so that I still can provide thesefeatures for stretchNo.MLT uses additional features which have not yet been merged into<https://github.com/jiixyj/libebur128/pull/49>https://github.com/jiixyj/libebur128/pull/49<https://github.com/jiixyj/libebur128/pull/51>https://github.com/jiixyj/libebur128/pull/51We will have to keep using our own fork until the changes are merged andreleased in libebur128.Is there any way to get an exception to the Debian rule and allow theinternal ebur128 to be used until the features are released by libebur1238?~Brian------------------------------*Sent:* Friday, July 8, 2016 5:55 AM*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update internallibebur128 to version 1.1.0Hi

Will the next mlt version then have the option to link against thesystem libebur version?------------------------------------------------------------------------------Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in SanFrancisco, CA to explore cutting-edge tech and listen to tech luminariespresent their vision of the future. This family event has something foreveryone, including kids. Get more information and register today.http://sdm.link/attshape_______________________________________________Mlt-devel mailing listhttps://lists.sourceforge.net/lists/listinfo/mlt-devel------------------------------------------------------------------------------Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in SanFrancisco, CA to explore cutting-edge tech and listen to tech luminariespresent their vision of the future. This family event has something foreveryone, including kids. Get more information and register today.http://sdm.link/attshape_______________________________________________Mlt-devel mailing listhttps://lists.sourceforge.net/lists/listinfo/mlt-devel

@Andrew and Sebastian:May you contact upstream to merge/discuss/solve both issues with Brian?There is not so much time anymore to solve this for our Stretch release(a few months).

@Dan and Brian:It is disabled, but I am also not happy about it. Renaming all files tohide the library would be quite ugly and I should detect it. I canunderstand your frustration, but using embedded libraries produces tonsof new problems (always!).

Post by Dan DennedyYou do not need to abide by their policy. This is a clear fork oflibebur128. Let them figure out what they want to do about it. Debiancan simply disable that module if they feel the need.Hmm. Ok. I don't really understand the policy. I feel like itunnecessarily withholds valuable features from the users. What ifI rename the files and reorganize the code so that it no longerresembles libebur128 - and there is no hope of ever mergingchanges between the two code bases? Then, would the policy nolonger apply? After 6 months I am tired of waiting for libebur128to accept (or reject) the pull requests.~Brian------------------------------------------------------------------------*Sent:* Friday, July 8, 2016 1:39 PM*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Updateinternal libebur128 to version 1.1.0Thanks for your update, I thought a merge TO mlt is missing. Sinceit "just" provides additonal features I do not see a good chanceto provide the fork within Debian (and Ubuntu and so on pulls fromDebian) :( I may be forced later to remove it again.In oct/nov we will freeze our testing/stretch, so I hope libeburwill merge the pull requests in the next time so that I still canprovide these features for stretch

Post by Brian MatherlyNo.MLT uses additional features which have not yet been merged intohttps://github.com/jiixyj/libebur128/pull/49https://github.com/jiixyj/libebur128/pull/51We will have to keep using our own fork until the changes aremerged and released in libebur128.Is there any way to get an exception to the Debian rule and allowthe internal ebur128 to be used until the features are releasedby libebur1238?~Brian------------------------------------------------------------------------*Sent:* Friday, July 8, 2016 5:55 AM*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Updateinternal libebur128 to version 1.1.0Hi

Will the next mlt version then have the option to link against thesystem libebur version?------------------------------------------------------------------------------Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in SanFrancisco, CA to explore cutting-edge tech and listen to tech luminariespresent their vision of the future. This family event hassomething foreveryone, including kids. Get more information and register today.http://sdm.link/attshape_______________________________________________Mlt-devel mailing listhttps://lists.sourceforge.net/lists/listinfo/mlt-devel

------------------------------------------------------------------------------Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in SanFrancisco, CA to explore cutting-edge tech and listen to tech luminariespresent their vision of the future. This family event hassomething foreveryone, including kids. Get more information and register today.http://sdm.link/attshape_______________________________________________Mlt-devel mailing listhttps://lists.sourceforge.net/lists/listinfo/mlt-devel

Post by Patrick Matthäi(I have added the libebur128 Debian package maintainers to CC)May you contact upstream to merge/discuss/solve both issues with Brian?There is not so much time anymore to solve this for our Stretch release(a few months).

Adding Jan to the loop.

Jan, could you please take a look athttps://github.com/jiixyj/libebur128/pull/49?

Cheers

Post by Patrick MatthäiIt is disabled, but I am also not happy about it. Renaming all files tohide the library would be quite ugly and I should detect it. I canunderstand your frustration, but using embedded libraries produces tonsof new problems (always!).

Post by Dan DennedyYou do not need to abide by their policy. This is a clear fork oflibebur128. Let them figure out what they want to do about it. Debiancan simply disable that module if they feel the need.Hmm. Ok. I don't really understand the policy. I feel like itunnecessarily withholds valuable features from the users. What ifI rename the files and reorganize the code so that it no longerresembles libebur128 - and there is no hope of ever mergingchanges between the two code bases? Then, would the policy nolonger apply? After 6 months I am tired of waiting for libebur128to accept (or reject) the pull requests.~Brian------------------------------------------------------------------------*Sent:* Friday, July 8, 2016 1:39 PM*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Updateinternal libebur128 to version 1.1.0Thanks for your update, I thought a merge TO mlt is missing. Sinceit "just" provides additonal features I do not see a good chanceto provide the fork within Debian (and Ubuntu and so on pulls fromDebian) :( I may be forced later to remove it again.In oct/nov we will freeze our testing/stretch, so I hope libeburwill merge the pull requests in the next time so that I still canprovide these features for stretch

Post by Brian MatherlyNo.MLT uses additional features which have not yet been merged intohttps://github.com/jiixyj/libebur128/pull/49https://github.com/jiixyj/libebur128/pull/51We will have to keep using our own fork until the changes aremerged and released in libebur128.Is there any way to get an exception to the Debian rule and allowthe internal ebur128 to be used until the features are releasedby libebur1238?~Brian------------------------------------------------------------------------*Sent:* Friday, July 8, 2016 5:55 AM*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Updateinternal libebur128 to version 1.1.0Hi

Will the next mlt version then have the option to link against thesystem libebur version?------------------------------------------------------------------------------Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in SanFrancisco, CA to explore cutting-edge tech and listen to tech luminariespresent their vision of the future. This family event has something foreveryone, including kids. Get more information and register today.http://sdm.link/attshape_______________________________________________Mlt-devel mailing listhttps://lists.sourceforge.net/lists/listinfo/mlt-devel

------------------------------------------------------------------------------Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in SanFrancisco, CA to explore cutting-edge tech and listen to tech luminariespresent their vision of the future. This family event has something foreveryone, including kids. Get more information and register today.http://sdm.link/attshape_______________________________________________Mlt-devel mailing listhttps://lists.sourceforge.net/lists/listinfo/mlt-devel

With the 1.2.0 release of libebur128, the upstream library should becompatible with MLT. The only thing that would be needed is for someoneto modify the Makefile/configure script in MLT to be able to use eitherexternal or internal libebur128. I think that it would be acceptable forthe script to always use the external library if it is present and itsversion is >= 1.2.0 - and then fall back to the internal library. Onecould use the rtaudio module as an example of how to do this. This isn'ta high priority for me, but I may get around to it eventually. If anyonewants to submit a patch (pull request), I would be happy to help testand sponsor it.

As an aside, I would just mention that I had previously suggested that Ijust rename the internal library to make the fork more blatant. Iincluded the quote below for context. It seems that FFMpeg has done justthat as can be seen here:

https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/ebur128.h

https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/ebur128.c

So I guess Debian will be confronted with the same problem when FFMpeg3.3 is released. Will you convince them to also use the externallibrary, or disable the features that use it, or make an exception inthat case?

Post by Patrick Matthäi(I have added the libebur128 Debian package maintainers to CC)May you contact upstream to merge/discuss/solve both issues with Brian?There is not so much time anymore to solve this for our Stretch release(a few months).

Adding Jan to the loop.Jan, could you please take a look athttps://github.com/jiixyj/libebur128/pull/49?Cheers

Not necessary since that PR was merged. Thanks for doing that, Jan. Itis much appreciated.

Post by Patrick MatthäiIt is disabled, but I am also not happy about it. Renaming all files tohide the library would be quite ugly and I should detect it. I canunderstand your frustration, but using embedded libraries produces tonsof new problems (always!).

Post by Dan DennedyYou do not need to abide by their policy. This is a clear fork oflibebur128. Let them figure out what they want to do about it. Debiancan simply disable that module if they feel the need.Hmm. Ok. I don't really understand the policy. I feel like itunnecessarily withholds valuable features from the users. What ifI rename the files and reorganize the code so that it no longerresembles libebur128 - and there is no hope of ever mergingchanges between the two code bases? Then, would the policy nolonger apply? After 6 months I am tired of waiting for libebur128to accept (or reject) the pull requests.~Brian------------------------------------------------------------------------*Sent:* Friday, July 8, 2016 1:39 PM*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Updateinternal libebur128 to version 1.1.0Thanks for your update, I thought a merge TO mlt is missing. Sinceit "just" provides additonal features I do not see a good chanceto provide the fork within Debian (and Ubuntu and so on pulls fromDebian) :( I may be forced later to remove it again.In oct/nov we will freeze our testing/stretch, so I hope libeburwill merge the pull requests in the next time so that I still canprovide these features for stretch

Post by Brian MatherlyNo.MLT uses additional features which have not yet been merged intohttps://github.com/jiixyj/libebur128/pull/49https://github.com/jiixyj/libebur128/pull/51We will have to keep using our own fork until the changes aremerged and released in libebur128.Is there any way to get an exception to the Debian rule and allowthe internal ebur128 to be used until the features are releasedby libebur1238?~Brian------------------------------------------------------------------------*Sent:* Friday, July 8, 2016 5:55 AM*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Updateinternal libebur128 to version 1.1.0Hi

Post by Brian MatherlyI can provide an update on this.With the 1.2.0 release of libebur128, the upstream library should becompatible with MLT. The only thing that would be needed is forsomeone to modify the Makefile/configure script in MLT to be able touse either external or internal libebur128. I think that it would beacceptable for the script to always use the external library if it ispresent and its version is >= 1.2.0 - and then fall back to theinternal library. One could use the rtaudio module as an example ofhow to do this. This isn't a high priority for me, but I may getaround to it eventually. If anyone wants to submit a patch (pullrequest), I would be happy to help test and sponsor it.

Thanks for your update. "Unhappily" Debian will freeze on this sunday,so this change comes a few days too late, but this will be part of thenext release.

I would be happy to see support in the configure script for it :)--/*Mit freundlichem Gruß / With kind regards,Patrick MatthäiGNU/Linux Debian Developer

Post by Brian MatherlyI can provide an update on this.With the 1.2.0 release of libebur128, the upstream library should becompatible with MLT. The only thing that would be needed is forsomeone to modify the Makefile/configure script in MLT to be able touse either external or internal libebur128. I think that it would beacceptable for the script to always use the external library if itis present and its version is >= 1.2.0 - and then fall back to theinternal library. One could use the rtaudio module as an example ofhow to do this. This isn't a high priority for me, but I may getaround to it eventually. If anyone wants to submit a patch (pullrequest), I would be happy to help test and sponsor it.

Thanks for your update. "Unhappily" Debian will freeze on this sunday,so this change comes a few days too late, but this will be part of thenext release.I would be happy to see support in the configure script for it :)

libebur128 1.2.0 is already in testing.

Given that embedded code copies is a pain for stable maintenance (e.g.for scurity tracking), I believe it is not unlikely that the releaseteam with grant an exception - if the patch is reasonably small.

Post by Brian MatherlyI can provide an update on this.With the 1.2.0 release of libebur128, the upstream library should becompatible with MLT. The only thing that would be needed is forsomeone to modify the Makefile/configure script in MLT to be able touse either external or internal libebur128. I think that it would beacceptable for the script to always use the external library if it ispresent and its version is >= 1.2.0 - and then fall back to theinternal library. One could use the rtaudio module as an example ofhow to do this. This isn't a high priority for me, but I may getaround to it eventually. If anyone wants to submit a patch (pullrequest), I would be happy to help test and sponsor it.

Thanks for your update. "Unhappily" Debian will freeze on this sunday,so this change comes a few days too late, but this will be part of thenext release.I would be happy to see support in the configure script for it :)

Then, I looked into detecting the installed version of libebur128.Unfortunately, the debian package for libebur128 does not provide apkg-config file:https://packages.debian.org/sid/amd64/libebur128-1/filelistMLT does not use autotools to generate the makefiles. So detecting theinstalled version is not trivial.

I think the next steps to get where you want to be are:1) Update the libebur128 .deb to include .pc files for pkg-config2) Update MLT to perform the detection