Build r1829228 on Linux-32

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Build r1829228 on Linux-32

Kay Schenk-2
The latest output build I installed --
rpm_en-US_2018-04-15_22_15_10_1829228

on my 32-bit CentOS 6.9 is non-functioning. Errors attached.

--
----------------------------------------------------------------------
MzK

"Less is MORE."


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Build r1829228 on Linux-32

Matthias Seidel

Hi Kay,

Am 21.04.2018 um 19:25 schrieb Kay Schenk:
The latest output build I installed --
rpm_en-US_2018-04-15_22_15_10_1829228

Assuming you downloaded from buildbot, can you try:
https://ci.apache.org/projects/openoffice/install/linux32/Apache_OpenOffice_4.2.0_Linux_x86_install-rpm_en-US_2018-04-20_19%3A57%3A49_1829676.tar.gz


on my 32-bit CentOS 6.9 is non-functioning. Errors attached.

I see nothing attached?

Regards,
   Matthias


--
----------------------------------------------------------------------
MzK

"Less is MORE."


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Build r1829228 on Linux-32

Kay Schenk-2


On 04/21/2018 10:40 AM, Matthias Seidel wrote:

> Hi Kay,
>
> Am 21.04.2018 um 19:25 schrieb Kay Schenk:
>> The latest output build I installed --
>> rpm_en-US_2018-04-15_22_15_10_1829228
>
> Assuming you downloaded from buildbot, can you try:
> https://ci.apache.org/projects/openoffice/install/linux32/Apache_OpenOffice_4.2.0_Linux_x86_install-rpm_en-US_2018-04-20_19%3A57%3A49_1829676.tar.gz
>
>>
>> on my 32-bit CentOS 6.9 is non-functioning. Errors attached.
>
> I see nothing attached?
>
> Regards,
>    Matthias
HI -- same results with this build r1829676.

I attached the error file again -- with an extension to "txt" that may help.

Basically, I think there needs to be a discussion concerning the changes
in requirements (system libraries, etc.) for 4.2.0 as it pertains to
Linux, and maybe Windows and Mac as well. I'd need to go to CentOS 7 to
meet the execution requirements for 4.2.0 in its current state. That's
not a huge hurdle for me but it might be for others.

>
>>
>> --
>> ----------------------------------------------------------------------
>> MzK
>>
>> "Less is MORE."
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
--
------------------------------------------
MzK

"Less is MORE."


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

soffice_errors2.txt (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Build r1829228 on Linux-32

Matthias Seidel

Hi Kay,

Am 21.04.2018 um 23:38 schrieb Kay Schenk:

On 04/21/2018 10:40 AM, Matthias Seidel wrote:
Hi Kay,

Am 21.04.2018 um 19:25 schrieb Kay Schenk:
The latest output build I installed --
rpm_en-US_2018-04-15_22_15_10_1829228
Assuming you downloaded from buildbot, can you try:
https://ci.apache.org/projects/openoffice/install/linux32/Apache_OpenOffice_4.2.0_Linux_x86_install-rpm_en-US_2018-04-20_19%3A57%3A49_1829676.tar.gz

on my 32-bit CentOS 6.9 is non-functioning. Errors attached.
I see nothing attached?

Regards,
   Matthias
HI -- same results with this build r1829676.

I attached the error file again -- with an extension to "txt" that may help.

Basically, I think there needs to be a discussion concerning the changes
in requirements (system libraries, etc.) for 4.2.0 as it pertains to
Linux, and maybe Windows and Mac as well. I'd need to go to CentOS 7 to
meet the execution requirements for 4.2.0 in its current state. That's
not a huge hurdle for me but it might be for others.

The problem may be that the buildbot is running on Ubuntu 14.04.
Normally we build releases on CentOS (5 for 4.1.x, 6 for 4.2.x).

Have you tried Jims builds?
http://home.apache.org/~jim/AOO-builds/4.3.0-dev-r1827250/en-US/

They are a bit older, but I think he used CentOS.
(And yes, it is 4.2.0 *not* 4.3.0)

Regards,
   Matthias



        
-- 
----------------------------------------------------------------------
MzK

"Less is MORE."


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

      

      

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Build r1829228 on Linux-32

Andrea Pescetti-2
Matthias Seidel wrote:
> The problem may be that the buildbot is running on Ubuntu 14.04.
> Normally we build releases on CentOS (5 for 4.1.x, 6 for 4.2.x).

That's the issue indeed. CentOS 6 has glibc 2.12, Ubuntu 12.04 has 2.15,
Ubuntu 14.04 has 2.19.

Your errors show that glibc >= 2.15 is expected by the build you used.

But the release (as per current plans) will be built on CentOS 6, so it
will work on CentOS 6 and all "newer" (to keep it simple) Linux-based
systems, which means on virtually all commonly used distributions.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Build r1829228 on Linux-32

Matthias Seidel
Am 22.04.2018 um 21:57 schrieb Andrea Pescetti:

> Matthias Seidel wrote:
>> The problem may be that the buildbot is running on Ubuntu 14.04.
>> Normally we build releases on CentOS (5 for 4.1.x, 6 for 4.2.x).
>
> That's the issue indeed. CentOS 6 has glibc 2.12, Ubuntu 12.04 has
> 2.15, Ubuntu 14.04 has 2.19.
>
> Your errors show that glibc >= 2.15 is expected by the build you used.
>
> But the release (as per current plans) will be built on CentOS 6, so
> it will work on CentOS 6 and all "newer" (to keep it simple)
> Linux-based systems, which means on virtually all commonly used
> distributions.
I was under the impression that Jim built with CentOS 6:
https://svn.apache.org/repos/asf/openoffice/devtools/build-scripts/4.2.0-dev/unxlngi6/build_aoo32bit_on_centos6.sh

So I would have expected his build to run on Kays machine...

Regards,
   Matthias

>
> Regards,
>   Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Build r1829228 on Linux-32

Andrea Pescetti-2
Matthias Seidel wrote:
> I was under the impression that Jim built with CentOS 6

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.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Build r1829228 on Linux-32

Matthias Seidel
Am 23.04.2018 um 00:15 schrieb Andrea Pescetti:
> Matthias Seidel wrote:
>> I was under the impression that Jim built with CentOS 6
>
> 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

>
> Regards,
>   Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Build r1829228 on Linux-32

Andrea Pescetti-2
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.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Build r1829228 on Linux-32

Kay Schenk-2
On Sun, Apr 22, 2018, 15:47 Andrea Pescetti <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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

Peter Kovacs-2
Does the build work without gstreamer activated?

Am 23. April 2018 03:09:49 MESZ schrieb Kay Schenk <[hidden email]>:

>On Sun, Apr 22, 2018, 15:47 Andrea Pescetti <[hidden email]>
>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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Kay Schenk-2
On Mon, Apr 23, 2018 at 1:50 AM, Peter Kovacs <[hidden email]>
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 <[hidden email]>:
> >On Sun, Apr 22, 2018, 15:47 Andrea Pescetti <[hidden email]>
> >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: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
----------------------------------------------------------------------
MzK

"Less is MORE."
Reply | Threaded
Open this post in threaded view
|

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Peter Kovacs-3
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Kay Schenk-2

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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
------------------------------------------
MzK

"Less is MORE."


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Jim Jagielski
In reply to this post by Peter Kovacs-3
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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Peter Kovacs-3
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 <[hidden email]>:

>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 <[hidden email]> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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_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 <[hidden email]> 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 <[hidden email]>:
> >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 <[hidden email]> 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: [hidden email]
> >>> For additional commands, e-mail: [hidden email]
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [hidden email]
> >For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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

Kay Schenk-2
​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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
> > >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 <[hidden email]> 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: [hidden email]
> > >>> For additional commands, e-mail: [hidden email]
> > >>>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: [hidden email]
> > >For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>



--
----------------------------------------------------------------------
MzK

"Less is MORE."
Reply | Threaded
Open this post in threaded view
|

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

Don Lewis-2
In reply to this post by Peter Kovacs-3
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: [hidden email]
For additional commands, e-mail: [hidden email]