Discussion:
[mltframework/mlt] 19b2fb: Update internal libebur128 to version 1.1.0
(too old to reply)
GitHub
2016-03-02 20:08:17 UTC
Permalink
Raw Message
Branch: refs/heads/master
Home: https://github.com/mltframework/mlt
Commit: 19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
https://github.com/mltframework/mlt/commit/19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
Author: Brian Matherly <***@brianmatherly.com>
Date: 2016-03-02 (Wed, 02 Mar 2016)

Changed paths:
M src/modules/plus/Makefile
M src/modules/plus/ebur128/ebur128.c
M src/modules/plus/ebur128/ebur128.h
R src/modules/plus/ebur128/queue.h
A src/modules/plus/ebur128/queue/sys/queue.h

Log Message:
-----------
Update internal libebur128 to version 1.1.0
Patrick Matthäi
2016-07-08 10:55:58 UTC
Permalink
Raw Message
Hi
Post by GitHub
Branch: refs/heads/master
Home: https://github.com/mltframework/mlt
Commit: 19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
https://github.com/mltframework/mlt/commit/19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
Date: 2016-03-02 (Wed, 02 Mar 2016)
M src/modules/plus/Makefile
M src/modules/plus/ebur128/ebur128.c
M src/modules/plus/ebur128/ebur128.h
R src/modules/plus/ebur128/queue.h
A src/modules/plus/ebur128/queue/sys/queue.h
-----------
Update internal libebur128 to version 1.1.0
Will the next mlt version then have the option to link against the
system libebur version?
Brian Matherly
2016-07-08 13:21:34 UTC
Permalink
Raw Message
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


From: Patrick MatthÀi <***@debian.org>
To: mlt-***@lists.sourceforge.net
Sent: Friday, July 8, 2016 5:55 AM
Subject: Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update internal libebur128 to version 1.1.0

Hi
  Branch: refs/heads/master
  Home:  https://github.com/mltframework/mlt
  Commit: 19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
      https://github.com/mltframework/mlt/commit/19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
  Date:  2016-03-02 (Wed, 02 Mar 2016)
    M src/modules/plus/Makefile
    M src/modules/plus/ebur128/ebur128.c
    M src/modules/plus/ebur128/ebur128.h
    R src/modules/plus/ebur128/queue.h
    A src/modules/plus/ebur128/queue/sys/queue.h
  -----------
  Update internal libebur128 to version 1.1.0
Will the next mlt version then have the option to link against the
system libebur version?
Patrick Matthäi
2016-07-08 18:39:19 UTC
Permalink
Raw Message
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
Post by Brian Matherly
No.
MLT uses additional features which have not yet been merged into
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
------------------------------------------------------------------------
*Sent:* Friday, July 8, 2016 5:55 AM
*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update internal
libebur128 to version 1.1.0
Hi
Post by GitHub
Branch: refs/heads/master
Home: https://github.com/mltframework/mlt
Commit: 19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
https://github.com/mltframework/mlt/commit/19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
Post by GitHub
Date: 2016-03-02 (Wed, 02 Mar 2016)
M src/modules/plus/Makefile
M src/modules/plus/ebur128/ebur128.c
M src/modules/plus/ebur128/ebur128.h
R src/modules/plus/ebur128/queue.h
A src/modules/plus/ebur128/queue/sys/queue.h
-----------
Update internal libebur128 to version 1.1.0
Will the next mlt version then have the option to link against the
system libebur version?
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Mlt-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mlt-devel
Brian Matherly
2016-07-09 02:05:38 UTC
Permalink
Raw Message
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.

~Brian

From: Patrick MatthÀi <***@debian.org>
To: Brian Matherly <***@brianmatherly.com>; "mlt-***@lists.sourceforge.net" <mlt-***@lists.sourceforge.net>
Sent: Friday, July 8, 2016 1:39 PM
Subject: Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update internal libebur128 to version 1.1.0

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


From: Patrick MatthÀi <***@debian.org>
To: mlt-***@lists.sourceforge.net
Sent: Friday, July 8, 2016 5:55 AM
Subject: Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update internal libebur128 to version 1.1.0

Hi
  Branch: refs/heads/master
  Home:  https://github.com/mltframework/mlt
  Commit: 19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
      https://github.com/mltframework/mlt/commit/19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
  Date:  2016-03-02 (Wed, 02 Mar 2016)
    M src/modules/plus/Makefile
    M src/modules/plus/ebur128/ebur128.c
    M src/modules/plus/ebur128/ebur128.h
    R src/modules/plus/ebur128/queue.h
    A src/modules/plus/ebur128/queue/sys/queue.h
  -----------
  Update internal libebur128 to version 1.1.0
Will the next mlt version then have the option to link against the
system libebur version?

------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Mlt-devel mailing list
Mlt-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
Dan Dennedy
2016-07-09 02:09:42 UTC
Permalink
Raw Message
You do not need to abide by their policy. This is a clear fork of
libebur128. Let them figure out what they want to do about it. Debian can
simply disable that module if they feel the need.
Post by Brian Matherly
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.
~Brian
------------------------------
*Sent:* Friday, July 8, 2016 1:39 PM
*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update internal
libebur128 to version 1.1.0
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
No.
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/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
------------------------------
*Sent:* Friday, July 8, 2016 5:55 AM
*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update internal
libebur128 to version 1.1.0
Hi
Post by GitHub
Branch: refs/heads/master
Home: https://github.com/mltframework/mlt
Commit: 19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
https://github.com/mltframework/mlt/commit/19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
Post by GitHub
Date: 2016-03-02 (Wed, 02 Mar 2016)
M src/modules/plus/Makefile
M src/modules/plus/ebur128/ebur128.c
M src/modules/plus/ebur128/ebur128.h
R src/modules/plus/ebur128/queue.h
A src/modules/plus/ebur128/queue/sys/queue.h
-----------
Update internal libebur128 to version 1.1.0
Will the next mlt version then have the option to link against the
system libebur version?
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Mlt-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mlt-devel
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape_______________________________________________
Mlt-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mlt-devel
Patrick Matthäi
2016-07-22 17:32:48 UTC
Permalink
Raw Message
Hi,

(I have added the libebur128 Debian package maintainers to CC)

@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 to
hide the library would be quite ugly and I should detect it. I can
understand your frustration, but using embedded libraries produces tons
of new problems (always!).
Post by Dan Dennedy
You do not need to abide by their policy. This is a clear fork of
libebur128. Let them figure out what they want to do about it. Debian
can simply disable that module if they feel the need.
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.
~Brian
------------------------------------------------------------------------
*Sent:* Friday, July 8, 2016 1:39 PM
*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update
internal libebur128 to version 1.1.0
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
Post by Brian Matherly
No.
MLT uses additional features which have not yet been merged into
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
------------------------------------------------------------------------
*Sent:* Friday, July 8, 2016 5:55 AM
*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update
internal libebur128 to version 1.1.0
Hi
Post by GitHub
Branch: refs/heads/master
Home: https://github.com/mltframework/mlt
Commit: 19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
https://github.com/mltframework/mlt/commit/19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
Post by GitHub
Date: 2016-03-02 (Wed, 02 Mar 2016)
M src/modules/plus/Makefile
M src/modules/plus/ebur128/ebur128.c
M src/modules/plus/ebur128/ebur128.h
R src/modules/plus/ebur128/queue.h
A src/modules/plus/ebur128/queue/sys/queue.h
-----------
Update internal libebur128 to version 1.1.0
Will the next mlt version then have the option to link against the
system libebur version?
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has
something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Mlt-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mlt-devel
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has
something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape_______________________________________________
Mlt-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mlt-devel
Sebastian Ramacher
2016-07-22 23:14:43 UTC
Permalink
Raw Message
Hi
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 at
https://github.com/jiixyj/libebur128/pull/49?

Cheers
Post by Patrick Matthäi
It is disabled, but I am also not happy about it. Renaming all files to
hide the library would be quite ugly and I should detect it. I can
understand your frustration, but using embedded libraries produces tons
of new problems (always!).
Post by Dan Dennedy
You do not need to abide by their policy. This is a clear fork of
libebur128. Let them figure out what they want to do about it. Debian
can simply disable that module if they feel the need.
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.
~Brian
------------------------------------------------------------------------
*Sent:* Friday, July 8, 2016 1:39 PM
*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update
internal libebur128 to version 1.1.0
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
Post by Brian Matherly
No.
MLT uses additional features which have not yet been merged into
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
------------------------------------------------------------------------
*Sent:* Friday, July 8, 2016 5:55 AM
*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update
internal libebur128 to version 1.1.0
Hi
Post by GitHub
Branch: refs/heads/master
Home: https://github.com/mltframework/mlt
Commit: 19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
https://github.com/mltframework/mlt/commit/19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
Post by GitHub
Date: 2016-03-02 (Wed, 02 Mar 2016)
M src/modules/plus/Makefile
M src/modules/plus/ebur128/ebur128.c
M src/modules/plus/ebur128/ebur128.h
R src/modules/plus/ebur128/queue.h
A src/modules/plus/ebur128/queue/sys/queue.h
-----------
Update internal libebur128 to version 1.1.0
Will the next mlt version then have the option to link against the
system libebur version?
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Mlt-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mlt-devel
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape_______________________________________________
Mlt-devel mailing list
https://lists.sourceforge.net/lists/listinfo/mlt-devel
--
Sebastian Ramacher
Brian Matherly
2017-02-01 14:07:16 UTC
Permalink
Raw Message
I can provide an update on this.

With the 1.2.0 release of libebur128, the upstream library should be
compatible with MLT. The only thing that would be needed is for someone
to modify the Makefile/configure script in MLT to be able to use either
external or internal libebur128. I think that it would be acceptable for
the script to always use the external library if it is present and its
version is >= 1.2.0 - and then fall back to the internal library. One
could use the rtaudio module as an example of how to do this. This isn't
a high priority for me, but I may get around to it eventually. If anyone
wants to submit a patch (pull request), I would be happy to help test
and sponsor it.


As an aside, I would just mention that I had previously suggested that I
just rename the internal library to make the fork more blatant. I
included the quote below for context. It seems that FFMpeg has done just
that 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 FFMpeg
3.3 is released. Will you convince them to also use the external
library, or disable the features that use it, or make an exception in
that case?


Cheers,

~Brian
Post by Sebastian Ramacher
Hi
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 at
https://github.com/jiixyj/libebur128/pull/49?
Cheers
Not necessary since that PR was merged. Thanks for doing that, Jan. It
is much appreciated.
Post by Sebastian Ramacher
Post by Patrick Matthäi
It is disabled, but I am also not happy about it. Renaming all files to
hide the library would be quite ugly and I should detect it. I can
understand your frustration, but using embedded libraries produces tons
of new problems (always!).
Post by Dan Dennedy
You do not need to abide by their policy. This is a clear fork of
libebur128. Let them figure out what they want to do about it. Debian
can simply disable that module if they feel the need.
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.
~Brian
------------------------------------------------------------------------
*Sent:* Friday, July 8, 2016 1:39 PM
*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update
internal libebur128 to version 1.1.0
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
Post by Brian Matherly
No.
MLT uses additional features which have not yet been merged into
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
------------------------------------------------------------------------
*Sent:* Friday, July 8, 2016 5:55 AM
*Subject:* Re: [Mlt-devel] [mltframework/mlt] 19b2fb: Update
internal libebur128 to version 1.1.0
Hi
Post by GitHub
Branch: refs/heads/master
Home: https://github.com/mltframework/mlt
Commit: 19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
https://github.com/mltframework/mlt/commit/19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
Post by GitHub
Date: 2016-03-02 (Wed, 02 Mar 2016)
M src/modules/plus/Makefile
M src/modules/plus/ebur128/ebur128.c
M src/modules/plus/ebur128/ebur128.h
R src/modules/plus/ebur128/queue.h
A src/modules/plus/ebur128/queue/sys/queue.h
-----------
Update internal libebur128 to version 1.1.0
Will the next mlt version then have the option to link against the
system libebur version?
Patrick Matthäi
2017-02-01 14:33:25 UTC
Permalink
Raw Message
Post by Brian Matherly
I can provide an update on this.
With the 1.2.0 release of libebur128, the upstream library should be
compatible with MLT. The only thing that would be needed is for
someone to modify the Makefile/configure script in MLT to be able to
use either external or internal libebur128. I think that it would be
acceptable for the script to always use the external library if it is
present and its version is >= 1.2.0 - and then fall back to the
internal library. One could use the rtaudio module as an example of
how to do this. This isn't a high priority for me, but I may get
around to it eventually. If anyone wants to submit a patch (pull
request), 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 the
next release.

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

Blog: http://www.linux-dev.org/
E-Mail: ***@debian.org
***@linux-dev.org
*/
Jonas Smedegaard
2017-02-01 15:03:24 UTC
Permalink
Raw Message
Quoting Patrick MatthÀi (2017-02-01 15:33:25)
Post by Patrick Matthäi
Post by Brian Matherly
I can provide an update on this.
With the 1.2.0 release of libebur128, the upstream library should be
compatible with MLT. The only thing that would be needed is for
someone to modify the Makefile/configure script in MLT to be able to
use either external or internal libebur128. I think that it would be
acceptable for the script to always use the external library if it
is present and its version is >= 1.2.0 - and then fall back to the
internal library. One could use the rtaudio module as an example of
how to do this. This isn't a high priority for me, but I may get
around to it eventually. If anyone wants to submit a patch (pull
request), 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 the
next 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 release
team with grant an exception - if the patch is reasonably small.
Post by Patrick Matthäi
If the changes are not too invasive and happen soon, I will strongly
consider it.
So please consider trying to get this change included now, not later.


- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private
Brian Matherly
2017-02-05 21:52:05 UTC
Permalink
Raw Message
Post by Patrick Matthäi
Post by Brian Matherly
I can provide an update on this.
With the 1.2.0 release of libebur128, the upstream library should be
compatible with MLT. The only thing that would be needed is for
someone to modify the Makefile/configure script in MLT to be able to
use either external or internal libebur128. I think that it would be
acceptable for the script to always use the external library if it is
present and its version is >= 1.2.0 - and then fall back to the
internal library. One could use the rtaudio module as an example of
how to do this. This isn't a high priority for me, but I may get
around to it eventually. If anyone wants to submit a patch (pull
request), 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 the
next release.
I would be happy to see support in the configure script for it :)
I went ahead and updated the MLT internal libebur128 source files to
match the upstream source files. Everything works. So MLT is compatible
with libebur128 1.2.0.

Then, I looked into detecting the installed version of libebur128.
Unfortunately, the debian package for libebur128 does not provide a
pkg-config file:
https://packages.debian.org/sid/amd64/libebur128-1/filelist
MLT does not use autotools to generate the makefiles. So detecting the
installed 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-config
2) Update MLT to perform the detection

~Brian
Patrick Matthäi
2017-02-22 09:31:33 UTC
Permalink
Raw Message
Please test this PR and report back.
https://github.com/mltframework/mlt/pull/196
~Brian
Hey,

much thanks it looks good! I will upload the changes to Debian today
--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer

Blog: http://www.linux-dev.org/
E-Mail: ***@debian.org
***@linux-dev.org
*/
Loading...