Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Don Lewis]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Kay Schenk]

​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  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_JAVABASEDsal_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_JAVABASEDsal_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_JAVABASEDsal_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  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 :
> > >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  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-unsubscr...@openoffice.apache.org
> > >>> For additional commands, e-mail: dev-h...@openoffice.apache.org
> > >>>
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> > >>
> > >
> > >
> > >-
> > >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > >For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> >
>



-- 
--
MzK

"Less is MORE."

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Damjan Jovanovic]

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_JAVABASEDsal_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_JAVABASEDsal_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_JAVABASEDsal_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  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 :
> >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  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-unsubscr...@openoffice.apache.org
> >>> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >
> >
> >-
> >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> >For additional commands, e-mail: dev-h...@openoffice.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Peter kovacs]

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 :
>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  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-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
>
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>For additional commands, e-mail: dev-h...@openoffice.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Jim Jagielski]

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  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-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Kay Schenk]

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-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-- 
--
MzK

"Less is MORE."


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Peter Kovacs]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Jim Jagielski]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Build r1829228 on Linux-32 (gstreamer build problem)

[Kay Schenk]

On Mon, Apr 23, 2018 at 1:50 AM, Peter Kovacs 
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 :
> >On Sun, Apr 22, 2018, 15:47 Andrea Pescetti 
> >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-unsubscr...@openoffice.apache.org
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
--
MzK

"Less is MORE."