You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Peter Kovacs <pe...@posteo.de> on 2018/04/23 08:50:56 UTC
Re: Build r1829228 on Linux-32 (gstreamer build problem)
Does the build work without gstreamer activated?
Am 23. April 2018 03:09:49 MESZ schrieb Kay Schenk <ka...@gmail.com>:
>On Sun, Apr 22, 2018, 15:47 Andrea Pescetti <pe...@apache.org>
>wrote:
>
>> Matthias Seidel wrote:
>> > Am 23.04.2018 um 00:15 schrieb Andrea Pescetti:
>> >> Correct. Jim's builds (not only releases) are done with CentOS 6,
>so
>> >> they will work on CentOS 6 too, and Kay can try with the latest
>link
>> >> you gave. Only buildbots builds won't.
>> > And that's the problem, even Jim's build won't run! ;-)
>> > https://bz.apache.org/ooo/show_bug.cgi?id=127738
>>
>> This is because those specific builds, as an exceptional case, were
>done
>> on Ubuntu: https://s.apache.org/Jwr0
>>
>> Regards,
>> Andrea.
>>
>
>One final note on this. Jim had built 4.2.0 on CentOS6 a while back
>before
>the gstreamer 1.0 update and that one DID work for me.
>
>We'll see how things go from here.
>
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build r1829228 on Linux-32 (gstreamer build problem)
Posted by Don Lewis <tr...@apache.org>.
On 1 May, Peter kovacs wrote:
> I think we do have the pain only with Linux. Since some distributions
> move slower then others.
>
> We could bundle the only 1.0.0 with Windows and Mac I think. For Linux
> we would need some logic, that identifies the right gstreamer
> available on the distribution. Maybe we could even reduce the effort
> to one certain package.
Does Windows even use gstreamer?
> I do not know about OS/2 or BSD. Maybe the appropiate volunteers could
> answer that. But imho it should not be a problem to create an
> additional port for this on BSD and integrate the right extention on
> OS/2.
I switched the FreeBSD port over to 1.0.0. Both versions of gstreamer
are available, though.
> A complete different approach could be not to bundle the extention. It
> would give us the option for Windows user to add the gstreamer into
> the extention, providing them a simplified access.
>
> For Linux a integration into the distribution would be the way. But I
> do not know how we can do that. We need maintainers for that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build r1829228 on Linux-32 (gstreamer build problem)
Posted by Kay Schenk <ka...@gmail.com>.
Thanks for this info, Damjan. It would be very useful if we could identify
the Linux media player that would likely be used -- as DirectX is for WNT
and QuickTime for Mac. Maybe VLC? This would mean defining a new
AVMEDIA_MANAGER_SERVICE_NAME, right?
On Tue, May 1, 2018 at 6:51 AM, Damjan Jovanovic <da...@apache.org> wrote:
> In main/avmedia/source/inc/mediamisc.hxx, the media player is chosen with
> the following code. Note how GStreamer is only used on non-Windows non-Mac
> platforms.
>
> #ifdef WNT
>
> #define AVMEDIA_MANAGER_SERVICE_NAME
> "com.sun.star.comp.avmedia.Manager_DirectX"
> #define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED sal_False
>
> #define AVMEDIA_MANAGER_SERVICE_NAME_FALLBACK1 ""
> #define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED_FALLBACK1 sal_False
>
> #else
> #ifdef QUARTZ
>
> #define AVMEDIA_MANAGER_SERVICE_NAME
> "com.sun.star.comp.avmedia.Manager_QuickTime"
> #define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED sal_False
>
> #define AVMEDIA_MANAGER_SERVICE_NAME_FALLBACK1
> "com.sun.star.comp.avmedia.Manager_MacAVF"
> #define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED_FALLBACK1 sal_False
>
> #else
>
> #define AVMEDIA_MANAGER_SERVICE_NAME
> "com.sun.star.comp.avmedia.Manager_GStreamer"
> #define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED sal_False
>
> #define AVMEDIA_MANAGER_SERVICE_NAME_FALLBACK1
> "com.sun.star.comp.avmedia.Manager_Java"
> #define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED_FALLBACK1 sal_True
>
> #endif
> #endif
>
>
> On Tue, May 1, 2018 at 3:01 PM Peter kovacs <pe...@apache.org> wrote:
>
> > I think we do have the pain only with Linux. Since some distributions
> move
> > slower then others.
> >
> > We could bundle the only 1.0.0 with Windows and Mac I think. For Linux we
> > would need some logic, that identifies the right gstreamer available on
> the
> > distribution.
> > Maybe we could even reduce the effort to one certain package.
> >
> > I do not know about OS/2 or BSD. Maybe the appropiate volunteers could
> > answer that. But imho it should not be a problem to create an additional
> > port for this on BSD and integrate the right extention on OS/2.
> >
> > A complete different approach could be not to bundle the extention. It
> > would give us the option for Windows user to add the gstreamer into the
> > extention, providing them a simplified access.
> >
> > For Linux a integration into the distribution would be the way. But I do
> > not know how we can do that. We need maintainers for that.
> >
> > Am 1. Mai 2018 13:57:50 MESZ schrieb Jim Jagielski <ji...@jaguNET.com>:
> > >So that would mean that our 'official' community builds would
> > >not longer bundle/include it by default? Would we have 2 different
> > >versions of the extension (0.10 and 1.0) or just one?
> > >
> > >I like the idea, btw :)
> > >
> > >> On Apr 26, 2018, at 1:14 AM, Peter Kovacs <pe...@Apache.org> wrote:
> > >>
> > >> Does it make sense to reorg the gstreamer module into an extention?
> > >> We could then have multiple versions of it.
> > >>
> > >> I mean after all this is only a optional feature, thats important to
> > >some not all.
> > >>
> > >> On 25.04.2018 16:18, Jim Jagielski wrote:
> > >>> I think this shows that we need to come to *some* consensus on
> > >>> how to handle the gstreamer stuff. Either we provide both CentOS6
> > >>> and Ubuntu builds to our community or we fold in the proposed
> > >>> gstreamer "work-around" which makes it a purely runtime
> > >>> concern.
> > >>>
> > >>> I would love to see how far we can go with the latter, but I am
> > >>> loath to volunteer someone else to "do the work" since I am
> > >>> unsure what the exact status of the patch is, how to fold it
> > >>> into trunk and how to handle building with the patch folded in.
> > >>>
> > >>> I know that there are other issues related to being at the stage
> > >>> to branch AOO420 from trunk but this, to me, seems like the
> > >>> priority at this point.
> > >>>
> > >>>
> > >---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > >>> For additional commands, e-mail: dev-help@openoffice.apache.org
> > >>>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > >> For additional commands, e-mail: dev-help@openoffice.apache.org
> > >>
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > >For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
>
--
----------------------------------------------------------------------
MzK
"Less is MORE."
Re: Build r1829228 on Linux-32 (gstreamer build problem)
Posted by Damjan Jovanovic <da...@apache.org>.
In main/avmedia/source/inc/mediamisc.hxx, the media player is chosen with
the following code. Note how GStreamer is only used on non-Windows non-Mac
platforms.
#ifdef WNT
#define AVMEDIA_MANAGER_SERVICE_NAME
"com.sun.star.comp.avmedia.Manager_DirectX"
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED sal_False
#define AVMEDIA_MANAGER_SERVICE_NAME_FALLBACK1 ""
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED_FALLBACK1 sal_False
#else
#ifdef QUARTZ
#define AVMEDIA_MANAGER_SERVICE_NAME
"com.sun.star.comp.avmedia.Manager_QuickTime"
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED sal_False
#define AVMEDIA_MANAGER_SERVICE_NAME_FALLBACK1
"com.sun.star.comp.avmedia.Manager_MacAVF"
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED_FALLBACK1 sal_False
#else
#define AVMEDIA_MANAGER_SERVICE_NAME
"com.sun.star.comp.avmedia.Manager_GStreamer"
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED sal_False
#define AVMEDIA_MANAGER_SERVICE_NAME_FALLBACK1
"com.sun.star.comp.avmedia.Manager_Java"
#define AVMEDIA_MANAGER_SERVICE_IS_JAVABASED_FALLBACK1 sal_True
#endif
#endif
On Tue, May 1, 2018 at 3:01 PM Peter kovacs <pe...@apache.org> wrote:
> I think we do have the pain only with Linux. Since some distributions move
> slower then others.
>
> We could bundle the only 1.0.0 with Windows and Mac I think. For Linux we
> would need some logic, that identifies the right gstreamer available on the
> distribution.
> Maybe we could even reduce the effort to one certain package.
>
> I do not know about OS/2 or BSD. Maybe the appropiate volunteers could
> answer that. But imho it should not be a problem to create an additional
> port for this on BSD and integrate the right extention on OS/2.
>
> A complete different approach could be not to bundle the extention. It
> would give us the option for Windows user to add the gstreamer into the
> extention, providing them a simplified access.
>
> For Linux a integration into the distribution would be the way. But I do
> not know how we can do that. We need maintainers for that.
>
> Am 1. Mai 2018 13:57:50 MESZ schrieb Jim Jagielski <ji...@jaguNET.com>:
> >So that would mean that our 'official' community builds would
> >not longer bundle/include it by default? Would we have 2 different
> >versions of the extension (0.10 and 1.0) or just one?
> >
> >I like the idea, btw :)
> >
> >> On Apr 26, 2018, at 1:14 AM, Peter Kovacs <pe...@Apache.org> wrote:
> >>
> >> Does it make sense to reorg the gstreamer module into an extention?
> >> We could then have multiple versions of it.
> >>
> >> I mean after all this is only a optional feature, thats important to
> >some not all.
> >>
> >> On 25.04.2018 16:18, Jim Jagielski wrote:
> >>> I think this shows that we need to come to *some* consensus on
> >>> how to handle the gstreamer stuff. Either we provide both CentOS6
> >>> and Ubuntu builds to our community or we fold in the proposed
> >>> gstreamer "work-around" which makes it a purely runtime
> >>> concern.
> >>>
> >>> I would love to see how far we can go with the latter, but I am
> >>> loath to volunteer someone else to "do the work" since I am
> >>> unsure what the exact status of the patch is, how to fold it
> >>> into trunk and how to handle building with the patch folded in.
> >>>
> >>> I know that there are other issues related to being at the stage
> >>> to branch AOO420 from trunk but this, to me, seems like the
> >>> priority at this point.
> >>>
> >>>
> >---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >For additional commands, e-mail: dev-help@openoffice.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Build r1829228 on Linux-32 (gstreamer build problem)
Posted by Peter kovacs <pe...@apache.org>.
I think we do have the pain only with Linux. Since some distributions move slower then others.
We could bundle the only 1.0.0 with Windows and Mac I think. For Linux we would need some logic, that identifies the right gstreamer available on the distribution.
Maybe we could even reduce the effort to one certain package.
I do not know about OS/2 or BSD. Maybe the appropiate volunteers could answer that. But imho it should not be a problem to create an additional port for this on BSD and integrate the right extention on OS/2.
A complete different approach could be not to bundle the extention. It would give us the option for Windows user to add the gstreamer into the extention, providing them a simplified access.
For Linux a integration into the distribution would be the way. But I do not know how we can do that. We need maintainers for that.
Am 1. Mai 2018 13:57:50 MESZ schrieb Jim Jagielski <ji...@jaguNET.com>:
>So that would mean that our 'official' community builds would
>not longer bundle/include it by default? Would we have 2 different
>versions of the extension (0.10 and 1.0) or just one?
>
>I like the idea, btw :)
>
>> On Apr 26, 2018, at 1:14 AM, Peter Kovacs <pe...@Apache.org> wrote:
>>
>> Does it make sense to reorg the gstreamer module into an extention?
>> We could then have multiple versions of it.
>>
>> I mean after all this is only a optional feature, thats important to
>some not all.
>>
>> On 25.04.2018 16:18, Jim Jagielski wrote:
>>> I think this shows that we need to come to *some* consensus on
>>> how to handle the gstreamer stuff. Either we provide both CentOS6
>>> and Ubuntu builds to our community or we fold in the proposed
>>> gstreamer "work-around" which makes it a purely runtime
>>> concern.
>>>
>>> I would love to see how far we can go with the latter, but I am
>>> loath to volunteer someone else to "do the work" since I am
>>> unsure what the exact status of the patch is, how to fold it
>>> into trunk and how to handle building with the patch folded in.
>>>
>>> I know that there are other issues related to being at the stage
>>> to branch AOO420 from trunk but this, to me, seems like the
>>> priority at this point.
>>>
>>>
>---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build r1829228 on Linux-32 (gstreamer build problem)
Posted by Jim Jagielski <ji...@jaguNET.com>.
So that would mean that our 'official' community builds would
not longer bundle/include it by default? Would we have 2 different
versions of the extension (0.10 and 1.0) or just one?
I like the idea, btw :)
> On Apr 26, 2018, at 1:14 AM, Peter Kovacs <pe...@Apache.org> wrote:
>
> Does it make sense to reorg the gstreamer module into an extention?
> We could then have multiple versions of it.
>
> I mean after all this is only a optional feature, thats important to some not all.
>
> On 25.04.2018 16:18, Jim Jagielski wrote:
>> I think this shows that we need to come to *some* consensus on
>> how to handle the gstreamer stuff. Either we provide both CentOS6
>> and Ubuntu builds to our community or we fold in the proposed
>> gstreamer "work-around" which makes it a purely runtime
>> concern.
>>
>> I would love to see how far we can go with the latter, but I am
>> loath to volunteer someone else to "do the work" since I am
>> unsure what the exact status of the patch is, how to fold it
>> into trunk and how to handle building with the patch folded in.
>>
>> I know that there are other issues related to being at the stage
>> to branch AOO420 from trunk but this, to me, seems like the
>> priority at this point.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build r1829228 on Linux-32 (gstreamer build problem)
Posted by Kay Schenk <ka...@gmail.com>.
On 04/25/2018 10:14 PM, Peter Kovacs wrote:
> Does it make sense to reorg the gstreamer module into an extention?
> We could then have multiple versions of it.
>
> I mean after all this is only a optional feature, thats important to
> some not all.
I think this idea is very good and deserves serious consideration.
Thanks for bringing it up.
>
> On 25.04.2018 16:18, Jim Jagielski wrote:
>> I think this shows that we need to come to *some* consensus on
>> how to handle the gstreamer stuff. Either we provide both CentOS6
>> and Ubuntu builds to our community or we fold in the proposed
>> gstreamer "work-around" which makes it a purely runtime
>> concern.
>>
>> I would love to see how far we can go with the latter, but I am
>> loath to volunteer someone else to "do the work" since I am
>> unsure what the exact status of the patch is, how to fold it
>> into trunk and how to handle building with the patch folded in.
>>
>> I know that there are other issues related to being at the stage
>> to branch AOO420 from trunk but this, to me, seems like the
>> priority at this point.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
--
------------------------------------------
MzK
"Less is MORE."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build r1829228 on Linux-32 (gstreamer build problem)
Posted by Peter Kovacs <Pe...@Apache.org>.
Does it make sense to reorg the gstreamer module into an extention?
We could then have multiple versions of it.
I mean after all this is only a optional feature, thats important to
some not all.
On 25.04.2018 16:18, Jim Jagielski wrote:
> I think this shows that we need to come to *some* consensus on
> how to handle the gstreamer stuff. Either we provide both CentOS6
> and Ubuntu builds to our community or we fold in the proposed
> gstreamer "work-around" which makes it a purely runtime
> concern.
>
> I would love to see how far we can go with the latter, but I am
> loath to volunteer someone else to "do the work" since I am
> unsure what the exact status of the patch is, how to fold it
> into trunk and how to handle building with the patch folded in.
>
> I know that there are other issues related to being at the stage
> to branch AOO420 from trunk but this, to me, seems like the
> priority at this point.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build r1829228 on Linux-32 (gstreamer build problem)
Posted by Jim Jagielski <ji...@jaguNET.com>.
I think this shows that we need to come to *some* consensus on
how to handle the gstreamer stuff. Either we provide both CentOS6
and Ubuntu builds to our community or we fold in the proposed
gstreamer "work-around" which makes it a purely runtime
concern.
I would love to see how far we can go with the latter, but I am
loath to volunteer someone else to "do the work" since I am
unsure what the exact status of the patch is, how to fold it
into trunk and how to handle building with the patch folded in.
I know that there are other issues related to being at the stage
to branch AOO420 from trunk but this, to me, seems like the
priority at this point.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Build r1829228 on Linux-32 (gstreamer build problem)
Posted by Kay Schenk <ka...@gmail.com>.
On Mon, Apr 23, 2018 at 1:50 AM, Peter Kovacs <pe...@posteo.de>
wrote:
> Does the build work without gstreamer activated?
>
Yes, without gstreamer as part of the my config, I can build without
issue.
>
> Am 23. April 2018 03:09:49 MESZ schrieb Kay Schenk <ka...@gmail.com>:
> >On Sun, Apr 22, 2018, 15:47 Andrea Pescetti <pe...@apache.org>
> >wrote:
> >
> >> Matthias Seidel wrote:
> >> > Am 23.04.2018 um 00:15 schrieb Andrea Pescetti:
> >> >> Correct. Jim's builds (not only releases) are done with CentOS 6,
> >so
> >> >> they will work on CentOS 6 too, and Kay can try with the latest
> >link
> >> >> you gave. Only buildbots builds won't.
> >> > And that's the problem, even Jim's build won't run! ;-)
> >> > https://bz.apache.org/ooo/show_bug.cgi?id=127738
> >>
> >> This is because those specific builds, as an exceptional case, were
> >done
> >> on Ubuntu: https://s.apache.org/Jwr0
> >>
> >> Regards,
> >> Andrea.
> >>
> >
> >One final note on this. Jim had built 4.2.0 on CentOS6 a while back
> >before
> >the gstreamer 1.0 update and that one DID work for me.
> >
> >We'll see how things go from here.
> >
> >
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
----------------------------------------------------------------------
MzK
"Less is MORE."