openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter kovacs <>
Subject Re: Build r1829228 on Linux-32 (gstreamer build problem)
Date Tue, 01 May 2018 12:53:51 GMT
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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message