Bug 103813 - juk links to gstreamer if it is found
Summary: juk links to gstreamer if it is found
Status: RESOLVED FIXED
Alias: None
Product: juk
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Scott Wheeler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-13 20:39 UTC by Piotr Szymański
Modified: 2006-10-24 11:53 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Szymański 2005-04-13 20:39:04 UTC
Version:            (using KDE KDE 3.4.0)
Installed from:    Compiled From Sources
Compiler:          gcc version 3.4.3 (PLD Linux)
 
OS:                Linux

Juk links to to gstreamer instead of having a separate module that would link with it that way juk gets a compile-time dependency on gstreamer when it is installed on the machine juk is built.

This is improper behaviour, because it  makes kdemultimedia juk packages that are built on distribution's builders, dependant on gstreamer which is not exactly what the user always wants (ex. user uses arts).

Please dont link juk directly to gstreamer.
Comment 1 Scott Wheeler 2005-04-14 05:25:16 UTC
Uhm, this isn't a bug, you'd just prefer to have it that way...
Comment 2 W-J van Dinter 2006-04-02 03:53:46 UTC
Ok, perhaps another scenario would mark it as a bug ... (somehow) ?

I recently updated to Fedora Core 5 with the latest gstreamer packages (0.10.x)

But now Juk won't start because it requires libgstreamer-0.8.so.x instead of libgstreamer-0.10.so.x, however, I use arts.

Or are there any other solutions that I haven't thought about ?
Comment 3 Michael Pyne 2006-04-02 09:17:37 UTC
W-J: You upgraded Fedora Core, and the upgrade removed your gstreamer-0.8 packages?  That's mean. ;)

I would recommend upgrading JuK to the version Fedora Core 5 is using as well.  If you are using a self-compiled JuK from KDE SVN, you can simply update the JuK source (the 3.5 branch has support for gstreamer 0.10 now) and make clean, reconfigure, and build again.

If you are using Fedora Core 5's JuK and it links to gstreamer-0.8, it is a packaging bug which you should file at the Fedora Core bug tracker.
Comment 4 Carsten Lohrke 2006-04-06 18:51:40 UTC
> Uhm, this isn't a bug, you'd just prefer to have it that way...

No. From a distributors point of view, non-determinisic, "automagic" dependency detection does suck badly. This is real a problem.



I can reprouce that juk is broken with gstreamer 0.10(.4) as well.


(juk:8856): GStreamer-CRITICAL **: gst_element_get_bus: assertion `GST_IS_ELEMENT (element)' failed

(juk:8856): GStreamer-CRITICAL **: gst_bus_set_sync_handler: assertion `GST_IS_BUS (bus)' failed

(juk:8856): GLib-GObject-CRITICAL **: g_object_set: assertion `G_IS_OBJECT (object)' failed

(juk:8856): GStreamer-CRITICAL **: gst_element_get_state: assertion `GST_IS_ELEMENT (element)' failed

(juk:8856): GStreamer-CRITICAL **: gst_element_get_state: assertion `GST_IS_ELEMENT (element)' failed
kio (KDirListerCache): [void KDirListerCache::slotEntries(KIO::Job*, const KIO::UDSEntryList&)] new entries for file:///home/carsten/a
kio (KDirListerCache): [void KDirListerCache::slotResult(KIO::Job*)] finished listing file:///home/carsten/a

(juk:8856): GStreamer-CRITICAL **: gst_element_set_state: assertion `GST_IS_ELEMENT (element)' failed

(juk:8856): GStreamer-CRITICAL **: gst_element_get_state: assertion `GST_IS_ELEMENT (element)' failed

(juk:8856): GStreamer-CRITICAL **: gst_element_get_state: assertion `GST_IS_ELEMENT (element)' failed

(juk:8856): GStreamer-CRITICAL **: gst_element_set_state: assertion `GST_IS_ELEMENT (element)' failed

(juk:8856): GLib-GObject-CRITICAL **: g_object_set: assertion `G_IS_OBJECT (object)' failed

(juk:8856): GStreamer-CRITICAL **: gst_element_set_state: assertion `GST_IS_ELEMENT (element)' failed

(juk:8856): GStreamer-CRITICAL **: gst_element_get_state: assertion `GST_IS_ELEMENT (element)' failed
juk: WARNING: Unable to play /home/carsten



file:///home/carsten/a   is the compilation base.

/home/carsten  is the directory I started Juk in. No idea why juk tries to play it, instead the song I selected.
Comment 5 W-J van Dinter 2006-04-08 22:28:36 UTC
Ok, I have to be fair now and tell you guys I made a mistake.
When I started synaptic to filter and view broken dependencies, all gestreamer08 and 0.8 packages displayed.
I removed them manually with rpm -e --no-deps ... but I shouldn't remove the gstreamer08 package.
That package must be installed to use Juk, and it won't collide with the gstreamer 0.10 packages.

If you have the same problems on fc5, install package gstreamer08-0.8.12-4.fc5 from the fedora-extras-development repos.

On a sidenote, perhaps an option with arguments like juk (-arts|-gstreamer) would solve such problems and avoid dependency issues ;)
Comment 6 Tim Beaulen 2006-10-24 11:52:41 UTC
This will not be a problem anymore for JuK as JuK will make use of Phonon (already in SVN trunk).

Phonon will deal with the ugly side of keeping the backends working and up to date.
Comment 7 Tim Beaulen 2006-10-24 11:53:51 UTC
*** Bug has been marked as fixed ***.