Migrate to farsight 0.2* / gstreamer 1.0

We would like to complete the gstreamer 1.0 transition and get rid of gstreamer 0.10 from the live cd entirely. libpurple is one of the remaining obstacles to reaching this goal.

https://developer.pidgin.im/ticket/15386 has a patch to port pidgin to 1.0

Ping, action on this would be greatly appreciated. We'd like to stop shipping two gstreamer stacks on the live image where space is limited.

I don't see any gstreamer-1.0 built anywhere. Also, the upstream patch is completely untested and the actual committed patch is totally different.

Created attachment 794596
[Patch] backport of gstreamer-1.0 patch

Backport of https://developer.pidgin.im/ticket/15386.

I have *not* tested the patch. Also, there is no gstreamer-1.0 built in rawhide so I didn't check if it actually builds correctly with gstreamer-1.0. It seems to build ok with gstreamer-0.10.

(In reply to Jan Synacek from comment #2)
> I don't see any gstreamer-1.0 built anywhere. Also, the upstream patch is
> completely untested and the actual committed patch is totally different.

gstreamer1-devel and friends. basically you just need to change the build requires by 's/gstreamer/gstreamer1/g'.

I looked at the openSUSE piding package a few weeks ago and they have a gst-1.0 patch there. Might be worth using the same patch to be able the share the maintenance efforts.

https://build.opensuse.org/package/show/openSUSE:Factory/pidgin

(In reply to Kalev Lember from comment #5)
> https://build.opensuse.org/package/show/openSUSE:Factory/pidgin

Good to know, thanks.

So, I took the patch, appended additional configure.ac diff that checks for farstream-0.2 and attempted to build the package.

I'm getting this:

Making all in example
make[4]: Entering directory `/home/jsynacek/pidgin-gstreamer1/pidgin/pidgin-2.10.7/libpurple/example'
  CC nullclient.o
  CCLD nullclient
../../libpurple/.libs/libpurple.so: undefined reference to `gst_video_overlay_set_window_handle'
../../libpurple/.libs/libpurple.so: undefined reference to `gst_video_overlay_get_type'
collect2: error: ld returned 1 exit status
make[4]: *** [nullclient] Error 1

I don't get it. The library is now correctly linked against gstreamer-1.

# ldd pidgin-2.10.7/libpurple/.libs/libpurple.so
 linux-vdso.so.1 => (0x00007fffd532b000)
 libdbus-glib-1.so.2 => /lib64/libdbus-glib-1.so.2 (0x00007f0eb8e9a000)
 libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f0eb8c54000)
 libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x00007f0eb8a4f000)
 libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007f0eb884d000)
 libxml2.so.2 => /lib64/libxml2.so.2 (0x00007f0eb84e4000)
 libfarstream-0.2.so.2 => /lib64/libfarstream-0.2.so.2 (0x00007f0eb82ce000)
 libgstbase-1.0.so.0 => /lib64/libgstbase-1.0.so.0 (0x00007f0eb8075000)
 libgstreamer-1.0.so.0 => /lib64/libgstreamer-1.0.so.0 (0x00007f0eb7d70000)
 libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f0eb7b1d000)
 libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f0eb77f1000)
 libidn.so.11 => /lib64/libidn.so.11 (0x00007f0eb75be000)
 libutil.so.1 => /lib64/libutil.so.1 (0x00007f0eb73ba000)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0eb719c000)
 libm.so.6 => /lib64/libm.so.6 (0x00007f0eb6e95000)
 libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f0eb6c7a000)
 libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f0eb6a5f000)
 libc.so.6 => /lib64/libc.so.6 (0x00007f0eb6695000)
 libgio-2.0.so.0 => /lib64/libgio-2.0.so.0 (0x00007f0eb6324000)
 librt.so.1 => /lib64/librt.so.1 (0x00007f0eb611c000)
 libdl.so.2 => /lib64/libdl.so.2 (0x00007f0eb5f18000)
 libz.so.1 => /lib64/libz.so.1 (0x00007f0eb5d01000)
 liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f0eb5adc000)
 libffi.so.6 => /lib64/libffi.so.6 (0x00007f0eb58d3000)
 /lib64/ld-linux-x86-64.so.2 (0x00000035d6200000)
 libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f0eb56af000)
 libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f0eb5448000)

The only thing that comes to mind is that those symbols are simply missing in libgstreamer-1.0.so.

I spent the whole day trying to get it to compile. I *didn't* know about the farstream02 and I think that it's a huge mess. It's not enough to link against gstreamer-1 only, because farstream-0.1 is still linked against gstreamer-0.1.
So, there is gstreamer1, farstream02, gstreamer1-plugins-.... It's a mess and it's frustrating.

Created attachment 795901
[Patch] gstreamer-1.0 patch

Created attachment 795902
[Patch] spec

This is how the spec is patched, I'm not sure if I miss anything else.

This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

(In reply to Jan Synacek from comment #6)
> So, I took the patch, appended additional configure.ac diff that checks for
> farstream-0.2 and attempted to build the package.

It would appear that the openSUSE package is built with the the voice and video support disabled (--disable-vv) and this is why they can get away without the farstream-0.2 fix.

> ../../libpurple/.libs/libpurple.so: undefined reference to
> `gst_video_overlay_set_window_handle'
> ../../libpurple/.libs/libpurple.so: undefined reference to
> `gst_video_overlay_get_type'
> collect2: error: ld returned 1 exit status
> make[4]: *** [nullclient] Error 1
>
> I don't get it. The library is now correctly linked against gstreamer-1.

These symbols are from the libgstreamer-video-1.0 library. The easiest way get it to link with it would be to change
PKG_CHECK_MODULES(GSTREAMER, [gstreamer-1.0] ...
to
PKG_CHECK_MODULES(GSTREAMER, [gstreamer-1.0 gstreamer-video-1.0] ...

This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.

Ping? More than one year later, libpurple still pulls in GStreamer 0.10. This now also affects the KDE spin (which has moved to GStreamer 1 for Fedora 21), through @kde-telepathy → telepathy-haze → libpurple → gstreamer and through … → libpurple → farstream → gstreamer (so yes, it also needs to use the new farstream). In addition, this dependency chain can result in mixed GStreamer 0.10 and 1.0 in kde-telepathy's ktp-call-ui, causing crashes.

One month later, still waiting for an answer.

Shall we start the nonresponsive maintainer process?

(In reply to Kevin Kofler from comment #14)
> Shall we start the nonresponsive maintainer process?

Am I nonresponsive? You should check the changelogs, really...

I still keep pidgin alive and running, but don't have time to fight the build system anymore, sorry.

The issue is that it took 1 month to get this answer, and we missed the F21 Final freeze because of that. :-(

I can help out (I'm a provenpackager), but it's probably too late to get GStreamer 0.10 off the F21 Final live images.

What is the status on this? This bug has been open coming up 2 years :-(

To make comment 15 even clearer: I took the package to keep it alive and update it to the latest versions, and perhaps even to fix urgent bugs that keep it from functioning, which I still do. I did it because the original maintainer hadn't been updating it for some time. I spent some time on this bug, found out that it really wasn't easy and then moved on to more prioritized things. This bug is in no way critical and trivial to get right and I don't have time to solve it anymore. It's not even ASSIGNED.

So the status is: this bug needs to be fixed by somebody willing to spend their time to fight the build system and different gstreamer versions.

This patch should fix it. I've tested this with pidgin-sipe, with voice calls as well as the file transfer and screen sharing added in later patches.

https://pidgin.im/pipermail/devel/2015-March/023645.html