At some point we should deprecate and then drop gstreamer 0.10 support. The gstreamer (what is built, etc) support has been the same since 2012-10-19 at least when configure.ac was committed. Currently it's build_gstreamer_0_10=yes for: Solaris (currently only see 0.10 - http://pkg.oracle.com/solaris/release/en/search.shtml?token=gstreamer&action=Search) linux-gnu| k*bsd*-gnu Debian https://packages.debian.org/search?suite=all&searchon=names& keywords=libgstreamer1.0) Only in Jesse (testing) proper, not in stable. Gst 1.0 is not in Ubuntu 12.04. Is in newer versions. freebsd - Has gstreamer1 (1.2) http://www.freebsd.org/cgi/ports.cgi?query=gstreamer1-plugins-core&stype=all&sektion=all netbsd - seems to have gstreamer1 (http://www.netbsd.org/cgi-bin/pkgsrc-search.cgi?q=gstreamer) dragonfly (can't find online package search). By my reading of the configure.ac file, it seems that all of these have gstreamer1.0 enabled on them anyway. My suggestion would be to set build_gstreamer_0_10=no for 4.4 release. Then drop in 4.5. Thoughts?
gstreamer 1.0 is not available on the Linux base line system -> we need to keep support for 0.10 because that is the only one available for our official Linux builds.
@ David Tardon AFAICT all the LibreOffice builds in the last 2 years are enabled with both gstreamer 1.0 and 0.10 support. It appears that RHEL/centos 6 does not have any gstreamer1 packages. While RHEL/centos 7 does. Is that you're concern, building LO 4.4 for RHEL 6? >Linux base line system The LSB cert?
(In reply to comment #2) > It appears that RHEL/centos 6 does not have any gstreamer1 packages. While > RHEL/centos 7 does. Is that you're concern, building LO 4.4 for RHEL 6? No, my concern is building the official release packages with gstreamer support. > > >Linux base line system > The LSB cert? Linux base line system is the system on which we build the release packages. Unless something changed during the last year, it is RHEL 5. You can see the configure options used for the release builds in distro-configs/LibreOfficeLinux.conf.
Thanks for the clarification. So we need to track turning on gstreamer1 first.. (and build machine upgrade possibilities)..
(In reply to comment #4) > (and build machine upgrade possibilities).. It is not as easy as that. We want the release packages to be runnable on as wide spectrum of linux systems as possible. So the base line system must be the least common denominator for various system libraries -> it must be relatively old.
Right. Of course. Is there already a plan when to move to a newer distro? At some point it's going to be hard to get gstreamer0.10 support in new distros..
(In reply to comment #6) > Right. Of course. Is there already a plan when to move to a newer distro? > > At some point it's going to be hard to get gstreamer0.10 support in new > distros.. Is this going to be a problem in 6 months, or will it be closer to 2 years?
For keeping gstreamer0.10 on LiveCDs it *could* happen in 6 months (I would say likely in 1 year): Fedora - the only blocker is building pidgin (used by empathy) against gstreamer1 (https://bugzilla.redhat.com/show_bug.cgi?id=962028) Ubuntu - the pidgin move (used by empathy) (https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1295207) And bluez needs an update (https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1162781) For keeping in archives likely looking at 2+ years as their all still 30 or so apps dependent on gst0.10 in Ubuntu Utopic.
So for now - moving this to WONTFIX - if the time comes where it's actually possible, feel free to set to UNCONFIRMED again. Having the bug sit as UNCONFIRMED for years isn't useful, setting it to NEW isn't good either because we're not prepared to move forward.