Is available a new version of clementine. Thanks ago Reproducible: Always
I see '12 hours ago' there. Please do not file 0-day version bump request. Delaying assignment.
Created attachment 248167 [details] working ebuild removed xine (0.5 does not support xine) and made gstreamer mandatory (confirmed necessary). Also removed the Makeopts line and the src_prepare (unnecessary).
(In reply to comment #2) > Created an attachment (id=248167) [details] > working ebuild > > removed xine (0.5 does not support xine) and made gstreamer mandatory > (confirmed necessary). Also removed the Makeopts line and the src_prepare > (unnecessary). > Matthew, thanks for your updated ebuild. A few thoughts tough: - Xine/engines other than GStreamer are not supported in 0.5, nor were they supported in 0.4 - anyway, upstream stills ships the source with the xine engine, which is easy to compile with some light ebuild patching (and one need to invoke clementine on the cmdline with "-e xine"). And I can confirm that xine does play the music here ! - any thoughts on how to get rid of wiimote stuff ? (I am not a CMake guru, nor do I follow upstream closely enough)
(In reply to comment #3) > (In reply to comment #2) > > Created an attachment (id=248167) [details] [details] > > working ebuild > > > > removed xine (0.5 does not support xine) and made gstreamer mandatory > > (confirmed necessary). Also removed the Makeopts line and the src_prepare > > (unnecessary). > > > Matthew, thanks for your updated ebuild. > A few thoughts tough: > - Xine/engines other than GStreamer are not supported in 0.5, nor were they > supported in 0.4 > - anyway, upstream stills ships the source with the xine engine, which is easy > to compile with some light ebuild patching (and one need to invoke clementine > on the cmdline with "-e xine"). And I can confirm that xine does play the music > here ! > - any thoughts on how to get rid of wiimote stuff ? (I am not a CMake guru, nor > do I follow upstream closely enough) > Because xine is not supported I would not want it in the ebuild (personal preference but certainly not default +xine). Upstream says that the wiimote stuff only depends on dbus, so we are good there. With this in mind, I don't think there is any need to change the ebuild as it stands (2010-09-20 14:52 0000).
Ok sound, thanks. Sounds reasonable for the wiimote stuff. For the xine backend, of course, as an unsupported on it should probably not be a +xine flag. (I am however experiencing a single segfault each time I quit clementine, I have yet to find it this is xine related).
(In reply to comment #5) > Ok sound, thanks. Sounds reasonable for the wiimote stuff. For the xine > backend, of course, as an unsupported on it should probably not be a +xine > flag. > (I am however experiencing a single segfault each time I quit clementine, I > have yet to find it this is xine related). > I haven't had an issue with segfaults on quit, but I am having an issue with web streams ( http://techno.fm/m3u/live.mp3.m3u for instance ). I am trying to sort this out.
Created attachment 248179 [details] fixes http streaming via added gstreamer plugin (=media-plugins/gst-plugins-soup-0.10)
(In reply to comment #7) > Created an attachment (id=248179) [details] > fixes http streaming via added gstreamer plugin > (=media-plugins/gst-plugins-soup-0.10) > Package as gst-plugins-* not be included in the ebuild
(In reply to comment #8) > (In reply to comment #7) > > Created an attachment (id=248179) [details] [details] > > fixes http streaming via added gstreamer plugin > > (=media-plugins/gst-plugins-soup-0.10) > > > > Package as gst-plugins-* not be included in the ebuild > What do you mean? I packaged as >=media-plugins/gst-plugins-soup-0.10 It seems to have been cut off though.
If xine is still available, it will stay default. No separate gstreamer plugins will be added to the dep list, like the postinst message says it's up to use to install whatever plugins he wants, or gst-plugins-meta (bug 300986) Futhermore in the attached ebuild: "ENGINE_GSTREAMER_ENABLED" is invalid, missing -D to pass it to cmake double definition of -DENABLE_VISUALISATIONS, one with forced OFF and second later on with cmake-utils_use_enable somehow all the depends are wrong too, as opposed to being correct in the ebuild in portage, like gst-plugins-meta being moved as build-time depend... how can a meta-package be a build-time depend? huh i'll see if I can add a proper ebuild to portage tomorrow
Comment on attachment 248179 [details] fixes http streaming via added gstreamer plugin (=media-plugins/gst-plugins-soup-0.10) invalid
Ok, I can understand the gstreamer stuff and the rest, the only thing I do not get is why you wish to keep xine as default when upstream said that it is deprecated and unsupported?
Created attachment 248185 [details] updated for https://bugs.gentoo.org/show_bug.cgi?id=338129#c10 Fixed cmake (missing -D) Fixed confused Schrödinger's variable (VISUALISATIONS) Fixed dependencies (needs gstreamer to build, removed all but >=media-libs/gstreamer-0.10)
Comment on attachment 248185 [details] updated for https://bugs.gentoo.org/show_bug.cgi?id=338129#c10 still invalid, missing gst-plugins-meta from RDEPEND (and only RDEPEND). missing gst-plugins-base (the gst-plugins packages in media-libs/ provide headers, and are actually mandatory for building). and xine will stay default long as gentoo gstreamer maintainers refuse to migrate away from the broken split setup (just search gentoo's bugzilla for gstreamer@gentoo.org to get the picture)
Created attachment 248189 [details] updated rdepend I feel like I've wondered into a holy war. I've updated the ebuild again but I'll leave adding the xine back to you.
Comment on attachment 248189 [details] updated rdepend sorry but still wrong, gstreamer and gst-plugins-base is both DEPEND and RDEPEND, and therefore goes into COMMON_DEPEND, otherwise --depclean will remove them
this a a short list of things that will break if using xine (confirmed upstream). visualizations, analyzer, crossfading, transcoder, playlist loader, and the equalizer
Created attachment 248192 [details] update for https://bugs.gentoo.org/show_bug.cgi?id=338129#c16
Matthew, It's not a holy war but getting it right. This requires checking every source file for #include lines, all CMakeLists.txt's, all .cmake files, `cmake ; ccmake .` output, testing all the USE flag combinations and so forth. I don't want fix the ebuild several times over after it's already been committed to Portage for something simple as wrong dependencies. That's just major waste of time. But I think users will appericiate your work on the bugzilla here if they want it now and not later, so thanks for that :)
No problem, I know that I'm somewhat new to this (only worked on two other ebuilds). I just don't know what we will do what we'd do when they take out xine. Upstream offered to take it out just so that we'd use gstreamer (xine is that bad it seems). I actually like xine, brings back memories, it used to be the only real media player for linux (I think mplayer might have been around the same time).
(In reply to comment #17) > this a a short list of things that will break if using xine (confirmed > upstream). > > visualizations, analyzer, crossfading, transcoder, playlist loader, and the > equalizer > I confirm that on my system: - crossfading is broken with xine backend - (the transcoder features uses gstreamer, and there is no Gstreamer switch to disable it at compile time) - clementine segfaults when exiting if xine is the backend of choice (using "-e xane" at runtime Haven't tested other features.
Created attachment 248269 [details] ebuild, works for me http://gitorious.org/gentoo-multimedia/gentoo-multimedia/commit/b793b6bfa36146ec0c8187e119f5ce079953a13d Fixed automagic, updated deps, linguas. make -j8, different USE combinations and projectm work fine now.
Created attachment 248271 [details, diff] cmake fix
in portage, with Nikoli as new maintainer now (proxy maintainership)
