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


Am 02.03.2016 um 21:08 schrieb GitHub:
> 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
>
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


Am 02.03.2016 um 21:08 schrieb GitHub:
>  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
>
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


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
>
>
> Am 02.03.2016 um 21:08 schrieb GitHub:
> > Branch: refs/heads/master
> > Home: https://github.com/mltframework/mlt
> > Commit: 19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
> >
> https://github.com/mltframework/mlt/commit/19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
> > Author: Brian Matherly <***@brianmatherly.com
> <mailto:***@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
> >
> 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 <mailto:Mlt-***@lists.sourceforge.net>
> 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


Am 02.03.2016 um 21:08 schrieb GitHub:
>  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
>
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.

On Fri, Jul 8, 2016, 7:06 PM Brian Matherly <***@brianmatherly.com> wrote:

> 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/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
>
>
> ------------------------------
> *From:* Patrick MatthÀi <***@debian.org> <***@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
>
>
> Am 02.03.2016 um 21:08 schrieb GitHub:
> > Branch: refs/heads/master
> > Home: https://github.com/mltframework/mlt
> > Commit: 19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
> >
> https://github.com/mltframework/mlt/commit/19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
> > Author: Brian Matherly < <***@brianmatherly.com>***@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
> >
> 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
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
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!).


Am 09.07.2016 um 04:09 schrieb 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.
>
>
> On Fri, Jul 8, 2016, 7:06 PM Brian Matherly <***@brianmatherly.com
> <mailto:***@brianmatherly.com>> wrote:
>
> 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
> <mailto:***@debian.org>>
> *To:* Brian Matherly <***@brianmatherly.com
> <mailto:***@brianmatherly.com>>; "mlt-***@lists.sourceforge.net
> <mailto:mlt-***@lists.sourceforge.net>"
> <mlt-***@lists.sourceforge.net
> <mailto: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>
>> <mailto:***@debian.org>
>> *To:* mlt-***@lists.sourceforge.net
>> <mailto: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
>>
>>
>> Am 02.03.2016 um 21:08 schrieb GitHub:
>> > Branch: refs/heads/master
>> > Home: https://github.com/mltframework/mlt
>> > Commit: 19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
>> >
>> https://github.com/mltframework/mlt/commit/19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
>> > Author: Brian Matherly <***@brianmatherly.com
>> <mailto:***@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
>> >
>> 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
>> <mailto:Mlt-***@lists.sourceforge.net>
>> 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
> Mlt-***@lists.sourceforge.net
> <mailto:Mlt-***@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>
Sebastian Ramacher
2016-07-22 23:14:43 UTC
Permalink
Raw Message
Hi

On 2016-07-22 19:32:48, Patrick MatthÀi wrote:
> (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).

Adding Jan to the loop.

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

Cheers

> @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!).
>
>
> Am 09.07.2016 um 04:09 schrieb 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.
> >
> >
> > On Fri, Jul 8, 2016, 7:06 PM Brian Matherly <***@brianmatherly.com
> > <mailto:***@brianmatherly.com>> wrote:
> >
> > 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
> > <mailto:***@debian.org>>
> > *To:* Brian Matherly <***@brianmatherly.com
> > <mailto:***@brianmatherly.com>>; "mlt-***@lists.sourceforge.net
> > <mailto:mlt-***@lists.sourceforge.net>"
> > <mlt-***@lists.sourceforge.net
> > <mailto: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>
> >> <mailto:***@debian.org>
> >> *To:* mlt-***@lists.sourceforge.net
> >> <mailto: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
> >>
> >>
> >> Am 02.03.2016 um 21:08 schrieb GitHub:
> >> > Branch: refs/heads/master
> >> > Home: https://github.com/mltframework/mlt
> >> > Commit: 19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
> >> >
> >> https://github.com/mltframework/mlt/commit/19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
> >> > Author: Brian Matherly <***@brianmatherly.com
> >> <mailto:***@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
> >> >
> >> 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
> >> <mailto:Mlt-***@lists.sourceforge.net>
> >> 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
> > Mlt-***@lists.sourceforge.net
> > <mailto:Mlt-***@lists.sourceforge.net>
> > 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


On 7/22/2016 6:14 PM, Sebastian Ramacher wrote:
> Hi
>
> On 2016-07-22 19:32:48, Patrick Matthäi wrote:
>> (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).
> 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.

>> @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!).
>>
>>
>> Am 09.07.2016 um 04:09 schrieb 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.
>>>
>>>
>>> On Fri, Jul 8, 2016, 7:06 PM Brian Matherly <***@brianmatherly.com
>>> <mailto:***@brianmatherly.com>> wrote:
>>>
>>> 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
>>> <mailto:***@debian.org>>
>>> *To:* Brian Matherly <***@brianmatherly.com
>>> <mailto:***@brianmatherly.com>>; "mlt-***@lists.sourceforge.net
>>> <mailto:mlt-***@lists.sourceforge.net>"
>>> <mlt-***@lists.sourceforge.net
>>> <mailto: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>
>>>> <mailto:***@debian.org>
>>>> *To:* mlt-***@lists.sourceforge.net
>>>> <mailto: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
>>>>
>>>>
>>>> Am 02.03.2016 um 21:08 schrieb GitHub:
>>>> > Branch: refs/heads/master
>>>> > Home: https://github.com/mltframework/mlt
>>>> > Commit: 19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
>>>> >
>>>> https://github.com/mltframework/mlt/commit/19b2fb8bc13ff561367d4bf6927ba7809f6b23dd
>>>> > Author: Brian Matherly <***@brianmatherly.com
>>>> <mailto:***@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
>>>> >
>>>> 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
Am 01.02.2017 um 15:07 schrieb 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)
> Am 01.02.2017 um 15:07 schrieb 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.

At bug#850840 (arguably similar) a release manager states this:

> 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
On 2/1/2017 8:33 AM, Patrick Matthäi wrote:
> Am 01.02.2017 um 15:07 schrieb 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
Am 21.02.2017 um 04:15 schrieb Brian Matherly:
> 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...