gstreamer status for 4.2.0-dev?

gstreamer status for 4.2.0-dev?

Subj line sez it all... where are we? There was a proposal to make it a run-time dependency but afaict there hasn't been any effort yet it doing that.

I know we have a handful of other things TODO re: 4.2.0 but this seems to be an inflection point for the Linux builds and so I really think we need to resolve this if we have any intent in getting a 4.2.0 beta out in a reasonable time frame.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]For additional commands, e-mail: [hidden email]

Re: gstreamer status for 4.2.0-dev?

Hopefully I will not intrude, but...

On Wed, May 23, 2018 at 5:35 AM, Jim Jagielski <[hidden email]> wrote:
>
> Subj line sez it all... where are we? There was a proposal to make it a run-time dependency but afaict there hasn't been any effort yet it doing that.

>
> I know we have a handful of other things TODO re: 4.2.0 but this seems to be an inflection point for the Linux builds and so I really think we need to resolve this if we have any >intent in getting a 4.2.0 beta out in a reasonable time frame.

In my build I experienced no issues opening previous ODT entities nor
creating new ones. On the other hand, after testing a multimedia .mp4
clip (which plays excellently) if I click, i.e., select, an empty area
ApacheOO simply crashes. Here is a small screen recording of the
issue.

Re: gstreamer status for 4.2.0-dev?

On 05/23/2018 05:35 AM, Jim Jagielski wrote:
> Subj line sez it all... where are we? There was a proposal to make it a run-time dependency but afaict there hasn't been any effort yet it doing that.
>
> I know we have a handful of other things TODO re: 4.2.0 but this seems to be an inflection point for the Linux builds and so I really think we need to resolve this if we have any intent in getting a 4.2.0 beta out in a reasonable time frame.

What would happen if we simply stopped including the --with-gstreamer
option in the build? Mac and Windows builds don't use it, and it only
applies to Linux.

I haven't investigated the code much to see how the gstreamer libraries
are used. The Linux distros now mostly use Freedesktop lower level
interfaces except I don't know what Unity uses. Is building with
gstreamer still needed/compliant with this? In short, how are video
applications determined in Linux now? Do we need a different approach
for integration of video objects in Linux?

If anyone knows the history of this, it would be very helpful to this
discussion.

Re: gstreamer status for 4.2.0-dev?

Imho the gstreamer libs are still the method of choice for doing multimedia.

The current state is that trunk can utilize the gstreamer API 1.0.0

We have the issue not resolved the issue to provide gstreamer for different Distributions. (Main issue: centos6 is to old to support the new gstreamer 1.0.0 API)
We have 2 suggestions to solve the issue:
1) implement 0.1.0 and 1.0.0 API.
2) move the implementation into an optional extention.

>On 05/23/2018 05:35 AM, Jim Jagielski wrote:
>> Subj line sez it all... where are we? There was a proposal to make it
>a run-time dependency but afaict there hasn't been any effort yet it
>doing that.
>>
>> I know we have a handful of other things TODO re: 4.2.0 but this
>seems to be an inflection point for the Linux builds and so I really
>think we need to resolve this if we have any intent in getting a 4.2.0
>beta out in a reasonable time frame.
>
>What would happen if we simply stopped including the --with-gstreamer
>option in the build? Mac and Windows builds don't use it, and it only
>applies to Linux.
>
>I haven't investigated the code much to see how the gstreamer libraries
>are used. The Linux distros now mostly use Freedesktop lower level
>interfaces except I don't know what Unity uses. Is building with
>gstreamer still needed/compliant with this? In short, how are video
>applications determined in Linux now? Do we need a different approach
>for integration of video objects in Linux?
>
>If anyone knows the history of this, it would be very helpful to this
>discussion.

> Imho the gstreamer libs are still the method of choice for doing
> multimedia.
>
> The current state is that trunk can utilize the gstreamer API 1.0.0
>
> We have the issue not resolved the issue to provide gstreamer for
> different Distributions. (Main issue: centos6 is to old to support the new
> gstreamer 1.0.0 API)
> We have 2 suggestions to solve the issue:
> 1) implement 0.1.0 and 1.0.0 API.
> 2) move the implementation into an optional extention.
>
> Both solutions have currently not followed up.
>
> All the best
> Peter
>
> Am 26. Mai 2018 18:53:46 MESZ schrieb Kay Schenk <[hidden email]>:
> >On 05/23/2018 05:35 AM, Jim Jagielski wrote:
> >> Subj line sez it all... where are we? There was a proposal to make it
> >a run-time dependency but afaict there hasn't been any effort yet it
> >doing that.
> >>
> >> I know we have a handful of other things TODO re: 4.2.0 but this
> >seems to be an inflection point for the Linux builds and so I really
> >think we need to resolve this if we have any intent in getting a 4.2.0
> >beta out in a reasonable time frame.
> >
> >What would happen if we simply stopped including the --with-gstreamer
> >option in the build? Mac and Windows builds don't use it, and it only
> >applies to Linux.
> >
> >I haven't investigated the code much to see how the gstreamer libraries
> >are used. The Linux distros now mostly use Freedesktop lower level
> >interfaces except I don't know what Unity uses. Is building with
> >gstreamer still needed/compliant with this? In short, how are video
> >applications determined in Linux now? Do we need a different approach
> >for integration of video objects in Linux?
> >
> >If anyone knows the history of this, it would be very helpful to this
> >discussion.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]> For additional commands, e-mail: [hidden email]>
>

Re: gstreamer status for 4.2.0-dev?

On 05/28/2018 12:05 AM, Peter kovacs wrote:
> Imho the gstreamer libs are still the method of choice for doing multimedia.

This is ONLY for Linux. So, how is multimedia "integrated" in AOO for
Mac and Windows? Can someone point us to the applicable code areas for this?

I have a feeling gstreamer was integrated long ago when no other
multi-media standard/app for Linux existed. Now it seems VLC seems to
the standard for the most part. (This is a dated web page but I think
it's still a good reference:
http://www.yolinux.com/TUTORIALS/LinuxTutorialMimeTypesAndApplications.html).
Basically, we are supplying gstreamer as a multimedia app to Linux when
maybe this isn't really needed.

>
> The current state is that trunk can utilize the gstreamer API 1.0.0
>
> We have the issue not resolved the issue to provide gstreamer for different Distributions. (Main issue: centos6 is to old to support the new gstreamer 1.0.0 API)
> We have 2 suggestions to solve the issue:
> 1) implement 0.1.0 and 1.0.0 API.
> 2) move the implementation into an optional extention.
>
> Both solutions have currently not followed up.
>
> All the best
> Peter
>
> Am 26. Mai 2018 18:53:46 MESZ schrieb Kay Schenk <[hidden email]>:
>> On 05/23/2018 05:35 AM, Jim Jagielski wrote:
>>> Subj line sez it all... where are we? There was a proposal to make it
>> a run-time dependency but afaict there hasn't been any effort yet it
>> doing that.
>>> I know we have a handful of other things TODO re: 4.2.0 but this
>> seems to be an inflection point for the Linux builds and so I really
>> think we need to resolve this if we have any intent in getting a 4.2.0
>> beta out in a reasonable time frame.
>>
>> What would happen if we simply stopped including the --with-gstreamer
>> option in the build? Mac and Windows builds don't use it, and it only
>> applies to Linux.
>>
>> I haven't investigated the code much to see how the gstreamer libraries
>> are used. The Linux distros now mostly use Freedesktop lower level
>> interfaces except I don't know what Unity uses. Is building with
>> gstreamer still needed/compliant with this? In short, how are video
>> applications determined in Linux now? Do we need a different approach
>> for integration of video objects in Linux?
>>
>> If anyone knows the history of this, it would be very helpful to this
>> discussion.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]> For additional commands, e-mail: [hidden email]>

> On 05/28/2018 12:05 AM, Peter kovacs wrote:
> > Imho the gstreamer libs are still the method of choice for doing
> multimedia.
>
> This is ONLY for Linux. So, how is multimedia "integrated" in AOO for
> Mac and Windows? Can someone point us to the applicable code areas for
> this?
>
> I have a feeling gstreamer was integrated long ago when no other
> multi-media standard/app for Linux existed. Now it seems VLC seems to
> the standard for the most part. (This is a dated web page but I think
> it's still a good reference:
> http://www.yolinux.com/TUTORIALS/LinuxTutorialMimeTypesAndApplications.html> ).
> Basically, we are supplying gstreamer as a multimedia app to Linux when
> maybe this isn't really needed.
>
> >
> > The current state is that trunk can utilize the gstreamer API 1.0.0
> >
> > We have the issue not resolved the issue to provide gstreamer for
> different Distributions. (Main issue: centos6 is to old to support the new
> gstreamer 1.0.0 API)
> > We have 2 suggestions to solve the issue:
> > 1) implement 0.1.0 and 1.0.0 API.
> > 2) move the implementation into an optional extention.
> >
> > Both solutions have currently not followed up.
> >
> > All the best
> > Peter
> >
> > Am 26. Mai 2018 18:53:46 MESZ schrieb Kay Schenk <[hidden email]>:
> >> On 05/23/2018 05:35 AM, Jim Jagielski wrote:
> >>> Subj line sez it all... where are we? There was a proposal to make it
> >> a run-time dependency but afaict there hasn't been any effort yet it
> >> doing that.
> >>> I know we have a handful of other things TODO re: 4.2.0 but this
> >> seems to be an inflection point for the Linux builds and so I really
> >> think we need to resolve this if we have any intent in getting a 4.2.0
> >> beta out in a reasonable time frame.
> >>
> >> What would happen if we simply stopped including the --with-gstreamer
> >> option in the build? Mac and Windows builds don't use it, and it only
> >> applies to Linux.
> >>
> >> I haven't investigated the code much to see how the gstreamer libraries
> >> are used. The Linux distros now mostly use Freedesktop lower level
> >> interfaces except I don't know what Unity uses. Is building with
> >> gstreamer still needed/compliant with this? In short, how are video
> >> applications determined in Linux now? Do we need a different approach
> >> for integration of video objects in Linux?
> >>
> >> If anyone knows the history of this, it would be very helpful to this
> >> discussion.
> > ---------------------------------------------------------------------
> > 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]>
>

>On 05/28/2018 12:05 AM, Peter kovacs wrote:
>> Imho the gstreamer libs are still the method of choice for doing
>multimedia.
>
>This is ONLY for Linux. So, how is multimedia "integrated" in AOO for
>Mac and Windows? Can someone point us to the applicable code areas for
>this?
>
>I have a feeling gstreamer was integrated long ago when no other
>multi-media standard/app for Linux existed. Now it seems VLC seems to
>the standard for the most part. (This is a dated web page but I think
>it's still a good reference:
>http://www.yolinux.com/TUTORIALS/LinuxTutorialMimeTypesAndApplications.html).
>Basically, we are supplying gstreamer as a multimedia app to Linux when
>maybe this isn't really needed.
>
>>
>> The current state is that trunk can utilize the gstreamer API 1.0.0
>>
>> We have the issue not resolved the issue to provide gstreamer for
>different Distributions. (Main issue: centos6 is to old to support the
>new gstreamer 1.0.0 API)
>> We have 2 suggestions to solve the issue:
>> 1) implement 0.1.0 and 1.0.0 API.
>> 2) move the implementation into an optional extention.
>>
>> Both solutions have currently not followed up.
>>
>> All the best
>> Peter
>>
>> Am 26. Mai 2018 18:53:46 MESZ schrieb Kay Schenk
><[hidden email]>:
>>> On 05/23/2018 05:35 AM, Jim Jagielski wrote:
>>>> Subj line sez it all... where are we? There was a proposal to make
>it
>>> a run-time dependency but afaict there hasn't been any effort yet it
>>> doing that.
>>>> I know we have a handful of other things TODO re: 4.2.0 but this
>>> seems to be an inflection point for the Linux builds and so I really
>>> think we need to resolve this if we have any intent in getting a
>4.2.0
>>> beta out in a reasonable time frame.
>>>
>>> What would happen if we simply stopped including the
>--with-gstreamer
>>> option in the build? Mac and Windows builds don't use it, and it
>only
>>> applies to Linux.
>>>
>>> I haven't investigated the code much to see how the gstreamer
>libraries
>>> are used. The Linux distros now mostly use Freedesktop lower level
>>> interfaces except I don't know what Unity uses. Is building with
>>> gstreamer still needed/compliant with this? In short, how are video
>>> applications determined in Linux now? Do we need a different
>approach
>>> for integration of video objects in Linux?
>>>
>>> If anyone knows the history of this, it would be very helpful to
>this
>>> discussion.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]>> For additional commands, e-mail: [hidden email]>>

Re: gstreamer status for 4.2.0-dev?

> The implementation can be found at avmedia/source/
>
> I think we use native API / libs for Windows and Mac.
>
>
> Am 28. Mai 2018 19:18:34 MESZ schrieb Kay Schenk <[hidden email]>:
> >On 05/28/2018 12:05 AM, Peter kovacs wrote:
> >> Imho the gstreamer libs are still the method of choice for doing
> >multimedia.
> >
> >This is ONLY for Linux. So, how is multimedia "integrated" in AOO for
> >Mac and Windows? Can someone point us to the applicable code areas for
> >this?
> >
> >I have a feeling gstreamer was integrated long ago when no other
> >multi-media standard/app for Linux existed. Now it seems VLC seems to
> >the standard for the most part. (This is a dated web page but I think
> >it's still a good reference:
> >
> http://www.yolinux.com/TUTORIALS/LinuxTutorialMimeTypesAndApplications.html> ).
> >Basically, we are supplying gstreamer as a multimedia app to Linux when
> >maybe this isn't really needed.
> >
> >>
> >> The current state is that trunk can utilize the gstreamer API 1.0.0
> >>
> >> We have the issue not resolved the issue to provide gstreamer for
> >different Distributions. (Main issue: centos6 is to old to support the
> >new gstreamer 1.0.0 API)
> >> We have 2 suggestions to solve the issue:
> >> 1) implement 0.1.0 and 1.0.0 API.
> >> 2) move the implementation into an optional extention.
> >>
> >> Both solutions have currently not followed up.
> >>
> >> All the best
> >> Peter
> >>
> >> Am 26. Mai 2018 18:53:46 MESZ schrieb Kay Schenk
> ><[hidden email]>:
> >>> On 05/23/2018 05:35 AM, Jim Jagielski wrote:
> >>>> Subj line sez it all... where are we? There was a proposal to make
> >it
> >>> a run-time dependency but afaict there hasn't been any effort yet it
> >>> doing that.
> >>>> I know we have a handful of other things TODO re: 4.2.0 but this
> >>> seems to be an inflection point for the Linux builds and so I really
> >>> think we need to resolve this if we have any intent in getting a
> >4.2.0
> >>> beta out in a reasonable time frame.
> >>>
> >>> What would happen if we simply stopped including the
> >--with-gstreamer
> >>> option in the build? Mac and Windows builds don't use it, and it
> >only
> >>> applies to Linux.
> >>>
> >>> I haven't investigated the code much to see how the gstreamer
> >libraries
> >>> are used. The Linux distros now mostly use Freedesktop lower level
> >>> interfaces except I don't know what Unity uses. Is building with
> >>> gstreamer still needed/compliant with this? In short, how are video
> >>> applications determined in Linux now? Do we need a different
> >approach
> >>> for integration of video objects in Linux?
> >>>
> >>> If anyone knows the history of this, it would be very helpful to
> >this
> >>> discussion.
> >> ---------------------------------------------------------------------
> >> 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]>
>

Re: gstreamer status for 4.2.0-dev?

> On May 28, 2018, at 3:05 AM, Peter kovacs <[hidden email]> wrote:
>
> Imho the gstreamer libs are still the method of choice for doing multimedia.
>
> The current state is that trunk can utilize the gstreamer API 1.0.0
>
> We have the issue not resolved the issue to provide gstreamer for different Distributions. (Main issue: centos6 is to old to support the new gstreamer 1.0.0 API)
> We have 2 suggestions to solve the issue:
> 1) implement 0.1.0 and 1.0.0 API.
> 2) move the implementation into an optional extention.
>
> Both solutions have currently not followed up.
>

Re: gstreamer status for 4.2.0-dev?

I think the hope is to continue using CentOS5 for our official AOO community builds. If not, then this becomes much easier, but it is, IMO, a major policy decision to do that. recall that gstreamer-1.x is incompatible w/ CentOS5.

I have no idea how to do #2 but #1 looks like simple brute force. Certainly not elegant but if that's what it takes to get past this holding pattern, then that's what we have to do.

> On May 28, 2018, at 3:12 AM, Damjan Jovanovic <[hidden email]> wrote:
>
> 3. Build on a newer CentOS or other distro.
> 4. Link to 1.0.0 using run-time dynamic linking, using that patch I made,
> and only require the gstreamer-1.0.0 tarball at compile time to find the
> headers.
>
> Damjan
>
> On Mon, May 28, 2018 at 9:06 AM Peter kovacs <[hidden email]> wrote:
>
>> Imho the gstreamer libs are still the method of choice for doing
>> multimedia.
>>
>> The current state is that trunk can utilize the gstreamer API 1.0.0
>>
>> We have the issue not resolved the issue to provide gstreamer for
>> different Distributions. (Main issue: centos6 is to old to support the new
>> gstreamer 1.0.0 API)
>> We have 2 suggestions to solve the issue:
>> 1) implement 0.1.0 and 1.0.0 API.
>> 2) move the implementation into an optional extention.
>>
>> Both solutions have currently not followed up.
>>
>> All the best
>> Peter
>>
>> Am 26. Mai 2018 18:53:46 MESZ schrieb Kay Schenk <[hidden email]>:
>>> On 05/23/2018 05:35 AM, Jim Jagielski wrote:
>>>> Subj line sez it all... where are we? There was a proposal to make it
>>> a run-time dependency but afaict there hasn't been any effort yet it
>>> doing that.
>>>>
>>>> I know we have a handful of other things TODO re: 4.2.0 but this
>>> seems to be an inflection point for the Linux builds and so I really
>>> think we need to resolve this if we have any intent in getting a 4.2.0
>>> beta out in a reasonable time frame.
>>>
>>> What would happen if we simply stopped including the --with-gstreamer
>>> option in the build? Mac and Windows builds don't use it, and it only
>>> applies to Linux.
>>>
>>> I haven't investigated the code much to see how the gstreamer libraries
>>> are used. The Linux distros now mostly use Freedesktop lower level
>>> interfaces except I don't know what Unity uses. Is building with
>>> gstreamer still needed/compliant with this? In short, how are video
>>> applications determined in Linux now? Do we need a different approach
>>> for integration of video objects in Linux?
>>>
>>> If anyone knows the history of this, it would be very helpful to this
>>> discussion.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]>> For additional commands, e-mail: [hidden email]>>
>>

Re: gstreamer status for 4.2.0-dev?

> This is ONLY for Linux. So, how is multimedia "integrated" in AOO for
> Mac and Windows? Can someone point us to the applicable code areas for this?
>
> I have a feeling gstreamer was integrated long ago when no other
> multi-media standard/app for Linux existed. Now it seems VLC seems to
> the standard for the most part. (This is a dated web page but I think
> it's still a good reference:
> http://www.yolinux.com/TUTORIALS/LinuxTutorialMimeTypesAndApplications.html).
> Basically, we are supplying gstreamer as a multimedia app to Linux when
> maybe this isn't really needed.

The using of gstreamer multimedia backend of OpenOffice was anounced in Oracle OpenOffice.org 3.4 Beta
in April 2010 and the first release with it was the Apache OpenOffice 3.4.0 in May 2012.

Re: gstreamer status for 4.2.0-dev?

29.05.2018, 21:30, "Jim Jagielski" <[hidden email]>:
> I think the hope is to continue using CentOS5 for our official AOO community builds. If not, then this becomes much easier, but it is, IMO, a major policy decision to do that. recall that gstreamer-1.x is incompatible w/ CentOS5.
>
> I have no idea how to do #2 but #1 looks like simple brute force. Certainly not elegant but if that's what it takes to get past this holding pattern, then that's what we have to do.
>

Some packages provides builds both for old and new systems.
E.g. here ( https://www.onlyoffice.com/en/download-desktop.aspx ) presented
packages both for old Debian and Ubuntu (Debian 7, Ubuntu 12.04 ) and their new releases (Debian 8, Ubuntu 14.04, 16.04, 18.04 ).

Re: gstreamer status for 4.2.0-dev?

>
> 28.05.2018, 20:19, "Kay Schenk" <[hidden email]>:
>
>> This is ONLY for Linux. So, how is multimedia "integrated" in AOO for
>> Mac and Windows? Can someone point us to the applicable code areas for this?
>>
>> I have a feeling gstreamer was integrated long ago when no other
>> multi-media standard/app for Linux existed. Now it seems VLC seems to
>> the standard for the most part. (This is a dated web page but I think
>> it's still a good reference:
>> http://www.yolinux.com/TUTORIALS/LinuxTutorialMimeTypesAndApplications.html).
>> Basically, we are supplying gstreamer as a multimedia app to Linux when
>> maybe this isn't really needed.
> The using of gstreamer multimedia backend of OpenOffice was anounced in Oracle OpenOffice.org 3.4 Beta
> in April 2010 and the first release with it was the Apache OpenOffice 3.4.0 in May 2012.
>
> Previously to play multimedia content in OpenOffice the Java Media Framework (JMF) was used
> ( https://wiki.openoffice.org/wiki/Java/Java_Media_Framework ).
> The JMF wasn't updated since 2003 and supported too small amount of formats in contrast to gstreamer.

Thank you for this information, it is useful. I understand the need for
a standardized AV app in some ways, but, assuming an end user's
preferred AV app supports a wide variety of formats, I think it would be
better for AOO (in non-Win, non-Mac) implementations to try to determine
the the end user's AV application, and use that rather than providing a
new AV app. But...a much longer discussion not on this thread.

Re: gstreamer status for 4.2.0-dev?

I am setup to be able to provide both CentOS5 Linux builds, for "old" systems (and gstreamer 0.10), and Ubuntu-or-CentOS6 Linux builds for newer ones (and gstreamer 1.x), so if that is the decision, that's fine w/ me. It increases, substantially, the total volume of releases we need to do, which is a factor, so we need to make sure our distro channel is aware.

I just don't like the one "making" that decision... but that's the only one I'm qualified to make since that's the only one I'm qualified to adjust trunk to represent (that is, pull the gstreamer-0.10 stuff from 4.1.5 and reincorporate it into trunk to exist in parallel w/ the new gstreamer-1.x stuff in there now).

FWIW, our inability to follow-through on this single issue is quite bothersome to me...

> On May 30, 2018, at 6:19 PM, Torokhov Sergey <[hidden email]> wrote:
>
>
>
> 29.05.2018, 21:30, "Jim Jagielski" <[hidden email]>:
>> I think the hope is to continue using CentOS5 for our official AOO community builds. If not, then this becomes much easier, but it is, IMO, a major policy decision to do that. recall that gstreamer-1.x is incompatible w/ CentOS5.
>>
>> I have no idea how to do #2 but #1 looks like simple brute force. Certainly not elegant but if that's what it takes to get past this holding pattern, then that's what we have to do.
>>
>
> Some packages provides builds both for old and new systems.
> E.g. here ( https://www.onlyoffice.com/en/download-desktop.aspx ) presented
> packages both for old Debian and Ubuntu (Debian 7, Ubuntu 12.04 ) and their new releases (Debian 8, Ubuntu 14.04, 16.04, 18.04 ).
>
> Could it be a solution to prepare separate packages?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]> For additional commands, e-mail: [hidden email]>

Re: gstreamer status for 4.2.0-dev?

> I am setup to be able to provide both CentOS5 Linux builds, for "old"
> systems (and gstreamer 0.10), and Ubuntu-or-CentOS6 Linux builds for newer
> ones (and gstreamer 1.x), so if that is the decision, that's fine w/ me. It
> increases, substantially, the total volume of releases we need to do, which
> is a factor, so we need to make sure our distro channel is aware.
>

>
> I just don't like the one "making" that decision... but that's the only
> one I'm qualified to make since that's the only one I'm qualified to adjust
> trunk to represent (that is, pull the gstreamer-0.10 stuff from 4.1.5 and
> reincorporate it into trunk to exist in parallel w/ the new gstreamer-1.x
> stuff in there now).
>
> FWIW, our inability to follow-through on this single issue is quite
> bothersome to me...

> > On May 30, 2018, at 6:19 PM, Torokhov Sergey <[hidden email]>
> wrote:
> >
> >
> >
> > 29.05.2018, 21:30, "Jim Jagielski" <[hidden email]>:
> >> I think the hope is to continue using CentOS5 for our official AOO
> community builds. If not, then this becomes much easier, but it is, IMO, a
> major policy decision to do that. recall that gstreamer-1.x is incompatible
> w/ CentOS5.
> >>
> >> I have no idea how to do #2 but #1 looks like simple brute force.
> Certainly not elegant but if that's what it takes to get past this holding
> pattern, then that's what we have to do.
> >>
> >
> > Some packages provides builds both for old and new systems.
> > E.g. here ( https://www.onlyoffice.com/en/download-desktop.aspx )
> presented
> > packages both for old Debian and Ubuntu (Debian 7, Ubuntu 12.04 ) and
> their new releases (Debian 8, Ubuntu 14.04, 16.04, 18.04 ).
> >
> > Could it be a solution to prepare separate packages?
> >
> > ---------------------------------------------------------------------
> > 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]>
>

>I am setup to be able to provide both CentOS5 Linux builds, for "old"
>systems (and gstreamer 0.10), and Ubuntu-or-CentOS6 Linux builds for
>newer ones (and gstreamer 1.x), so if that is the decision, that's fine
>w/ me. It increases, substantially, the total volume of releases we
>need to do, which is a factor, so we need to make sure our distro
>channel is aware.
>
>I just don't like the one "making" that decision... but that's the only
>one I'm qualified to make since that's the only one I'm qualified to
>adjust trunk to represent (that is, pull the gstreamer-0.10 stuff from
>4.1.5 and reincorporate it into trunk to exist in parallel w/ the new
>gstreamer-1.x stuff in there now).
>
>FWIW, our inability to follow-through on this single issue is quite
>bothersome to me...
>
>> On May 30, 2018, at 6:19 PM, Torokhov Sergey <[hidden email]>
>wrote:
>>
>>
>>
>> 29.05.2018, 21:30, "Jim Jagielski" <[hidden email]>:
>>> I think the hope is to continue using CentOS5 for our official AOO
>community builds. If not, then this becomes much easier, but it is,
>IMO, a major policy decision to do that. recall that gstreamer-1.x is
>incompatible w/ CentOS5.
>>>
>>> I have no idea how to do #2 but #1 looks like simple brute force.
>Certainly not elegant but if that's what it takes to get past this
>holding pattern, then that's what we have to do.
>>>
>>
>> Some packages provides builds both for old and new systems.
>> E.g. here ( https://www.onlyoffice.com/en/download-desktop.aspx )
>presented
>> packages both for old Debian and Ubuntu (Debian 7, Ubuntu 12.04 ) and
>their new releases (Debian 8, Ubuntu 14.04, 16.04, 18.04 ).
>>
>> Could it be a solution to prepare separate packages?
>>
>> ---------------------------------------------------------------------
>> 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]

Re: gstreamer status for 4.2.0-dev?

Those who need to support older versions of Centos with newer versions of Openoffice should come forward and do the work!

Sent from my iPhone

> On Jun 4, 2018, at 10:59 PM, Peter Kovacs <[hidden email]> wrote:
>
> How about we ask the community if we need to support centOS6?
> If no one uses CentOS6 maybe we make a fuzz for nothing. I am not aware that another distro is using that old versions.
>
> The important thing is how much users we say we need to extend the support to CentOS 6?
>
> I would also include the symbolic patch that Damjan provided. So we can build gstreamer support in general, but do not have to deliver it.
>
> Am 4. Juni 2018 21:09:52 MESZ schrieb Jim Jagielski <[hidden email]>:
>> I am setup to be able to provide both CentOS5 Linux builds, for "old"
>> systems (and gstreamer 0.10), and Ubuntu-or-CentOS6 Linux builds for
>> newer ones (and gstreamer 1.x), so if that is the decision, that's fine
>> w/ me. It increases, substantially, the total volume of releases we
>> need to do, which is a factor, so we need to make sure our distro
>> channel is aware.
>>
>> I just don't like the one "making" that decision... but that's the only
>> one I'm qualified to make since that's the only one I'm qualified to
>> adjust trunk to represent (that is, pull the gstreamer-0.10 stuff from
>> 4.1.5 and reincorporate it into trunk to exist in parallel w/ the new
>> gstreamer-1.x stuff in there now).
>>
>> FWIW, our inability to follow-through on this single issue is quite
>> bothersome to me...
>>
>>> On May 30, 2018, at 6:19 PM, Torokhov Sergey <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> 29.05.2018, 21:30, "Jim Jagielski" <[hidden email]>:
>>>> I think the hope is to continue using CentOS5 for our official AOO
>> community builds. If not, then this becomes much easier, but it is,
>> IMO, a major policy decision to do that. recall that gstreamer-1.x is
>> incompatible w/ CentOS5.
>>>>
>>>> I have no idea how to do #2 but #1 looks like simple brute force.
>> Certainly not elegant but if that's what it takes to get past this
>> holding pattern, then that's what we have to do.
>>>>
>>>
>>> Some packages provides builds both for old and new systems.
>>> E.g. here ( https://www.onlyoffice.com/en/download-desktop.aspx )
>> presented
>>> packages both for old Debian and Ubuntu (Debian 7, Ubuntu 12.04 ) and
>> their new releases (Debian 8, Ubuntu 14.04, 16.04, 18.04 ).
>>>
>>> Could it be a solution to prepare separate packages?
>>>
>>> ---------------------------------------------------------------------
>>> 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]>

Re: gstreamer status for 4.2.0-dev?

> On Mon, Jun 4, 2018 at 12:09 PM, Jim Jagielski <[hidden email]> wrote:
>
>> I am setup to be able to provide both CentOS5 Linux builds, for "old"
>> systems (and gstreamer 0.10), and Ubuntu-or-CentOS6 Linux builds for newer
>> ones (and gstreamer 1.x), so if that is the decision, that's fine w/ me. It
>> increases, substantially, the total volume of releases we need to do, which
>> is a factor, so we need to make sure our distro channel is aware.
>>
>
> ​I think we'd need to go up to CentOS7 for gstreamer 1.x. Anyway...point
> taken.

CentOS5 is done [1]. We can try to upgrade to CentOS6 as our new base
platform. Or do some effort to jump directly to CentOS7.

>> I just don't like the one "making" that decision... but that's the only
>> one I'm qualified to make since that's the only one I'm qualified to adjust
>> trunk to represent (that is, pull the gstreamer-0.10 stuff from 4.1.5 and
>> reincorporate it into trunk to exist in parallel w/ the new gstreamer-1.x
>> stuff in there now).
>>
>> FWIW, our inability to follow-through on this single issue is quite
>> bothersome to me...
>
>
>>> On May 30, 2018, at 6:19 PM, Torokhov Sergey <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> 29.05.2018, 21:30, "Jim Jagielski" <[hidden email]>:
>>>> I think the hope is to continue using CentOS5 for our official AOO
>> community builds. If not, then this becomes much easier, but it is, IMO, a
>> major policy decision to do that. recall that gstreamer-1.x is incompatible
>> w/ CentOS5.
>>>>
>>>> I have no idea how to do #2 but #1 looks like simple brute force.
>> Certainly not elegant but if that's what it takes to get past this holding
>> pattern, then that's what we have to do.
>>>>
>>>
>>> Some packages provides builds both for old and new systems.
>>> E.g. here ( https://www.onlyoffice.com/en/download-desktop.aspx )
>> presented
>>> packages both for old Debian and Ubuntu (Debian 7, Ubuntu 12.04 ) and
>> their new releases (Debian 8, Ubuntu 14.04, 16.04, 18.04 ).
>>>
>>> Could it be a solution to prepare separate packages?

Re: gstreamer status for 4.2.0-dev?

Am 05.06.2018 um 08:14 schrieb Dave Fisher:
> Those who need to support older versions of Centos with newer versions of Openoffice should come forward and do the work!

also a valid argument. ;-)

Marcus

>> On Jun 4, 2018, at 10:59 PM, Peter Kovacs <[hidden email]> wrote:
>>
>> How about we ask the community if we need to support centOS6?
>> If no one uses CentOS6 maybe we make a fuzz for nothing. I am not aware that another distro is using that old versions.
>>
>> The important thing is how much users we say we need to extend the support to CentOS 6?
>>
>> I would also include the symbolic patch that Damjan provided. So we can build gstreamer support in general, but do not have to deliver it.
>>
>> Am 4. Juni 2018 21:09:52 MESZ schrieb Jim Jagielski <[hidden email]>:
>>> I am setup to be able to provide both CentOS5 Linux builds, for "old"
>>> systems (and gstreamer 0.10), and Ubuntu-or-CentOS6 Linux builds for
>>> newer ones (and gstreamer 1.x), so if that is the decision, that's fine
>>> w/ me. It increases, substantially, the total volume of releases we
>>> need to do, which is a factor, so we need to make sure our distro
>>> channel is aware.
>>>
>>> I just don't like the one "making" that decision... but that's the only
>>> one I'm qualified to make since that's the only one I'm qualified to
>>> adjust trunk to represent (that is, pull the gstreamer-0.10 stuff from
>>> 4.1.5 and reincorporate it into trunk to exist in parallel w/ the new
>>> gstreamer-1.x stuff in there now).
>>>
>>> FWIW, our inability to follow-through on this single issue is quite
>>> bothersome to me...
>>>
>>>> On May 30, 2018, at 6:19 PM, Torokhov Sergey <[hidden email]>
>>> wrote:
>>>>
>>>>
>>>>
>>>> 29.05.2018, 21:30, "Jim Jagielski" <[hidden email]>:
>>>>> I think the hope is to continue using CentOS5 for our official AOO
>>> community builds. If not, then this becomes much easier, but it is,
>>> IMO, a major policy decision to do that. recall that gstreamer-1.x is
>>> incompatible w/ CentOS5.
>>>>>
>>>>> I have no idea how to do #2 but #1 looks like simple brute force.
>>> Certainly not elegant but if that's what it takes to get past this
>>> holding pattern, then that's what we have to do.
>>>>>
>>>>
>>>> Some packages provides builds both for old and new systems.
>>>> E.g. here ( https://www.onlyoffice.com/en/download-desktop.aspx )
>>> presented
>>>> packages both for old Debian and Ubuntu (Debian 7, Ubuntu 12.04 ) and
>>> their new releases (Debian 8, Ubuntu 14.04, 16.04, 18.04 ).
>>>>
>>>> Could it be a solution to prepare separate packages?