11:14 a.m.
Sorry Miro, I forgot to add that.
Has the library behaviour been modified?
The MPV back end to be
bundled with CMPlayer has been patched for use
with CMPlayer.
For those interested, the changes made to the bundled MPV can be viewed
at Github [1]
Why haven't the changes been pushed to the upstream library?
The developer for CMPlayer has stated that these patches are specific to
CMPlayer, and are incompatible with upstream.
Could we make the forked version the canonical version within Fedora?
Same answer as above: the CMPlayer patches are incompatible with
upstream and are specific to CMPlayer.
Are the changes useful to consumers other than the bundling
application?
No, these changes would only benefit CMPlayer users.
Is upstream keeping the base library updated or are they continuously
one or more versions behind the latest upstream release?
The CMPlayer developer is regularly merging upstream MPV commits into
his fork.
What is the attitude of upstream towards bundling?
The CMPlayer
developer has stated that the bundling of MPV is necessary
for CMPlayer to successfully build and run.
Does the maintainer of the Fedora package of the library being bundled
have any comments about this?
The maintainer of the MPV package, Miro Hrončok, suggested this bundling
exception.
Is there a plan for unbundling the library at a later time?
Not
currently.
Attached is an email reply from upstream concerning the bundling of MPV
with CMPlayer.
[1] https://github.com/xylosper/mpv/compare/mpv-player:master...master
10:33 a.m.
New subject: Bundling exception for CMPlayer
On 16/01/14 21:14, Ben Reedy wrote:
Sorry Miro, I forgot to add that.
>Has the library behaviour been modified?
The MPV back end to be bundled with CMPlayer has been patched for use
with CMPlayer.
For those interested, the changes made to the bundled MPV can be
viewed at Github [1]
>Why haven't the changes been pushed to the upstream library?
The developer for CMPlayer has stated that these patches are specific
to CMPlayer, and are incompatible with upstream.
>Could we make the forked version the canonical version within Fedora?
Same answer as above: the CMPlayer patches are incompatible with
upstream and are specific to CMPlayer.
>Are the changes useful to consumers other than the bundling application?
No, these changes would only benefit CMPlayer users.
>Is upstream keeping the base library updated or are they continuously
one or more versions behind the latest upstream release?
The CMPlayer developer is regularly merging upstream MPV commits into
his fork.
>What is the attitude of upstream towards bundling?
The CMPlayer developer has stated that the bundling of MPV is
necessary for CMPlayer to successfully build and run.
>Does the maintainer of the Fedora package of the library being
bundled have any comments about this?
The maintainer of the MPV package, Miro Hrončok, suggested this
bundling exception.
>Is there a plan for unbundling the library at a later time?
Not currently.
Attached is an email reply from upstream concerning the bundling of
MPV with CMPlayer.
[1] https://github.com/xylosper/mpv/compare/mpv-player:master...master
Hi all, would anyone like to comment on this bundling exception?
Thanks,
Ben.
11:47 a.m.
New subject: Bundling exception for CMPlayer
Hm... Really, one of the elderly should step in here. In their absence:
Basically, the root problem seem to be that the cmplayer dev hasn't really
tried to push his patches to the mpv upstream. Looking at how vital the
development at mpv [1] is, this looks like a mistake to me.
However, this is the cmplayers's devs decision. Question is how rpmfusion
should handle this. To me, merging the two versions (if at all possible) is
probably not a reasonable task for a packager - it's just looks too much
(?)
From a more formal POV: are these changes big enough to warrant an
exception? . A complete diff between the two versions, if only just to see
how big it actually is, might be helpful here - the git history is not
that easy to read.
--alec
[1] https://github.com/mpv-player/mpv/
On Sat, Jan 25, 2014 at 11:33 AM, Ben Reedy <thebenj88(a)gmail.com> wrote:
On 16/01/14 21:14, Ben Reedy wrote:
> Sorry Miro, I forgot to add that.
>
> >Has the library behaviour been modified?
> The MPV back end to be bundled with CMPlayer has been patched for use
> with CMPlayer.
> For those interested, the changes made to the bundled MPV can be viewed
> at Github [1]
>
> >Why haven't the changes been pushed to the upstream library?
> The developer for CMPlayer has stated that these patches are specific to
> CMPlayer, and are incompatible with upstream.
>
> >Could we make the forked version the canonical version within Fedora?
> Same answer as above: the CMPlayer patches are incompatible with upstream
> and are specific to CMPlayer.
>
> >Are the changes useful to consumers other than the bundling application?
> No, these changes would only benefit CMPlayer users.
>
> >Is upstream keeping the base library updated or are they continuously
> one or more versions behind the latest upstream release?
> The CMPlayer developer is regularly merging upstream MPV commits into his
> fork.
>
> >What is the attitude of upstream towards bundling?
> The CMPlayer developer has stated that the bundling of MPV is necessary
> for CMPlayer to successfully build and run.
>
> >Does the maintainer of the Fedora package of the library being bundled
> have any comments about this?
> The maintainer of the MPV package, Miro Hrončok, suggested this bundling
> exception.
>
> >Is there a plan for unbundling the library at a later time?
> Not currently.
>
> Attached is an email reply from upstream concerning the bundling of MPV
> with CMPlayer.
>
> [1] https://github.com/xylosper/mpv/compare/mpv-player:master...master
>
Hi all, would anyone like to comment on this bundling exception?
Thanks,
Ben.
12:37 p.m.
New subject: Bundling exception for CMPlayer
Dne 25.1.2014 12:47, Alec Leamas napsal(a):
From a more formal POV: are these changes big enough to warrant an
exception? . A complete diff between the two versions, if only just to
see how big it actually is, might be helpful here - the git history is
not that easy to read.
https://github.com/xylosper/mpv/compare/mpv-player:master...master.diff
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
12:38 p.m.
New subject: Bundling exception for CMPlayer
Sorry, I meant
https://github.com/xylosper/mpv/compare/mpv-player:master...master.patch
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
12:58 p.m.
New subject: Bundling exception for CMPlayer
Well, in my eyes this actually doesn't look that bad. All in all 37
lines gone, 130 added, including some whitespace changes.
My first reaction when seeing this that this does not warrant an
exception, at least not without a try to push things upstream. Note
the following in [1]:
---
Why haven't the changes been pushed to the upstream library? If no
attempt has been made to push the changes upstream, we shouldn't be
supporting people forking out of laziness.
---
--alec
[1] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
On 1/25/14, Miro Hrončok <mhroncok(a)redhat.com> wrote:
>
https://github.com/xylosper/mpv/compare/mpv-player:master...master.diff
Sorry, I meant
https://github.com/xylosper/mpv/compare/mpv-player:master...master.patch
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
1:05 p.m.
New subject: Bundling exception for CMPlayer
Sorry, first reply was based on first answer ie. e., first patch. The
new numbers (+124, -184) are definitely something else. That said, I
don't really think it changes my overall conclusion that a try to push
this upstream should be done.
On 1/25/14, Alec Leamas <leamas.alec(a)gmail.com> wrote:
Well, in my eyes this actually doesn't look that bad. All in all
37
lines gone, 130 added, including some whitespace changes.
My first reaction when seeing this that this does not warrant an
exception, at least not without a try to push things upstream. Note
the following in [1]:
---
Why haven't the changes been pushed to the upstream library? If no
attempt has been made to push the changes upstream, we shouldn't be
supporting people forking out of laziness.
---
--alec
[1] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
On 1/25/14, Miro Hrončok <mhroncok(a)redhat.com> wrote:
>> https://github.com/xylosper/mpv/compare/mpv-player:master...master.diff
>
> Sorry, I meant
> https://github.com/xylosper/mpv/compare/mpv-player:master...master.patch
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
1:34 p.m.
New subject: Bundling exception for CMPlayer
So 25. leden 2014, 14:05:08 CET, Alec Leamas napsal:
That said, I
don't really think it changes my overall conclusion that a try to push
this upstream should be done.
As a maintainer of mpv, I'd say the same thing.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3:18 p.m.
New subject: Bundling exception for CMPlayer
On 25/01/14 23:34, Miro Hrončok wrote:
So 25. leden 2014, 14:05:08 CET, Alec Leamas napsal:
> That said, I
> don't really think it changes my overall conclusion that a try to push
> this upstream should be done.
As a maintainer of mpv, I'd say the same thing.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
My concern is that even if these changes are successfully pushed
upstream, CMPlayer will still not build without an included MPV source tree.
Looking at the build-mpv script, MPV is first built and the resulting
object files are placed in an ar archive at ./build/lib/
libcmplayer_mpv.a, which is then used while building CMPlayer.
The CMPlayer developer mentioned this earlier, stating that this is
necessary as there is no libmpv shared library to link to while building.
--Ben
11:48 a.m.
New subject: Bundling exception for CMPlayer
Here a t least two possibilities:
- You could build using the upstream sources. This an accepted way in
a situation like this if there is no library.
- You could cooperate with upstream and make them release a library.
Miro: are you listening?
--alec
On 1/25/14, Ben Reedy <thebenj88(a)gmail.com> wrote:
On 25/01/14 23:34, Miro Hrončok wrote:
> So 25. leden 2014, 14:05:08 CET, Alec Leamas napsal:
>> That said, I
>> don't really think it changes my overall conclusion that a try to push
>> this upstream should be done.
>
> As a maintainer of mpv, I'd say the same thing.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
My concern is that even if these changes are successfully pushed
upstream, CMPlayer will still not build without an included MPV source
tree.
Looking at the build-mpv script, MPV is first built and the resulting
object files are placed in an ar archive at ./build/lib/
libcmplayer_mpv.a, which is then used while building CMPlayer.
The CMPlayer developer mentioned this earlier, stating that this is
necessary as there is no libmpv shared library to link to while building.
--Ben
2:01 p.m.
New subject: Bundling exception for CMPlayer
Dne 27.1.2014 12:48, Alec Leamas napsal(a):
Here a t least two possibilities:
- You could build using the upstream sources. This an accepted way in
a situation like this if there is no library.
- You could cooperate with upstream and make them release a library.
Miro: are you listening?
Yes I am listening.
I would like to see a real attempt to communicate with mpv upstream, to
release a library - if that fails, then go with the first option.
To be clear - I'm not doing this, that's up to Ben. I can provide help,
though.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
3:33 p.m.
New subject: Bundling exception for CMPlayer
On 28/01/14 00:01, Miro Hrončok wrote:
Dne 27.1.2014 12:48, Alec Leamas napsal(a):
> Here a t least two possibilities:
> - You could build using the upstream sources. This an accepted way in
> a situation like this if there is no library.
> - You could cooperate with upstream and make them release a library.
> Miro: are you listening?
Yes I am listening.
I would like to see a real attempt to communicate with mpv upstream,
to release a library - if that fails, then go with the first option.
To be clear - I'm not doing this, that's up to Ben. I can provide
help, though.
I've contacted one of the MPV developers [1], and they said that there
are plans for a shared library. However, they also re-iterated what the
CMPlayer developer stated:
But note that cmplayer is not really a frontend. It includes its own
video output and a bunch of other stuff instead of native mpv functionality.
They also mentioned that the use of the planned shared library wouldn't
work either:
No... just that cmplayer uses mpv in a way it probably won't be
able
to use the shared lib.
[1] https://github.com/mpv-player/mpv/issues/510
3:54 p.m.
New subject: Bundling exception for CMPlayer
Basically, here seems to be some work to to: the cmplayer dev(s) needs
to push the changes upstream. This is not something done is a haste,
it means producing a number of patches which could be justified
upstream, and probably also some modifications in cmplayer to adapt to
a more generic. upstream.
It might turn out that this is not possible. In that case, I think a
bundling exception could be discussed. However, so far no attempt has
been made, and according to the GL we should not grant an exception in
such cases.
Which admittedly is sad thing to say. Has anyone some way around here?
Perhaps by saying I'm plain wrong? In a way, it would be a relief ;)
--alec
On 1/27/14, Ben Reedy <thebenj88(a)gmail.com> wrote:
On 28/01/14 00:01, Miro Hrončok wrote:
> Dne 27.1.2014 12:48, Alec Leamas napsal(a):
>> Here a t least two possibilities:
>> - You could build using the upstream sources. This an accepted way in
>> a situation like this if there is no library.
>> - You could cooperate with upstream and make them release a library.
>> Miro: are you listening?
>
> Yes I am listening.
>
> I would like to see a real attempt to communicate with mpv upstream,
> to release a library - if that fails, then go with the first option.
>
> To be clear - I'm not doing this, that's up to Ben. I can provide
> help, though.
>
I've contacted one of the MPV developers [1], and they said that there
are plans for a shared library. However, they also re-iterated what the
CMPlayer developer stated:
> But note that cmplayer is not really a frontend. It includes its own
video output and a bunch of other stuff instead of native mpv
functionality.
They also mentioned that the use of the planned shared library wouldn't
work either:
> No... just that cmplayer uses mpv in a way it probably won't be able
to use the shared lib.
[1] https://github.com/mpv-player/mpv/issues/510
1:54 p.m.
New subject: Bundling exception for CMPlayer
Update from the CMPlayer developer [1]:
I can't be sure till I see the actual result. However, because
they
have very nice attitude to accept suggestions, if somethings are lacked
in the result, I think I can make acceptable patch that point once it is
released.
So it doesn't seem like anything's changing soon, but we may see a
resolution of this issue with the eventual release of the MPV shared
library.
[1] https://github.com/xylosper/cmplayer/issues/34#issuecomment-33585255
3950
days inactive
3963
days old
rpmfusion-developers@lists.rpmfusion.org
13 comments
3 participants
participants (3)
-
Alec Leamas -
Ben Reedy -
Miro Hrončok