w/o pulseaudio flag:
unpack gnome-settings-daemon-2.30.0-gst-vol-control-support.patch: file format not recognized. Ignoring.
[test-media-keys] Error 1
building volume media keys using Pulseaudio
and ebuild succeeds
pulseaudio should never be obligatory. This ebuild needs to be fixed, no?
Attach build log.
here is what I pasted from the build log to a pastebin. Build log is gone, since I succeeded to build.
LC_ALL=C /usr/bin/intltool-merge -d -u -c ../../po/.intltool-merge-cache ../../po media-keys.gnome-settings-plugin.in media-keys.gnome-settings-plugin
Found too-old cached translation database
Generating and caching the translation database
Merging translations into media-keys.gnome-settings-plugin.
../../plugins/media-keys/cut-n-paste/.libs/libgvc.a(gvc-gstreamer-acme-vol.o): In function `acme_volume_open':
gvc-gstreamer-acme-vol.c:(.text+0x40): undefined reference to `gconf_client_get_string'
gvc-gstreamer-acme-vol.c:(.text+0x193): undefined reference to `gconf_client_get_list'
../../plugins/media-keys/cut-n-paste/.libs/libgvc.a(gvc-gstreamer-acme-vol.o): In function `acme_volume_init':
gvc-gstreamer-acme-vol.c:(.text+0xe24): undefined reference to `gconf_client_get_default'
collect2: ld returned 1 exit status
Anyway, not sure what the need is. I told you what happened, why, and suggest what needs to change in the ebuild -- if not actually fixed to remove the dependency. If you don't believe me, then... test it yourself. ;-)
As for gnome-3 isms, I hear the gnome-shell folks have decided pulseaudio is non-removable. So, somewhere ebuilds should die with a message
if the flag isn't set.
Given no build log, just such snippet, I'd say the best resolution would be INVALID.
Looking at that snippet, I'd say that for no good reason it was linking to a static lib - from casual look at the sources, the problem may lie in the fact, that the person, that wrote the patch used gconf, but failed to add the requirement to configure.ac.
And your comment already says, that Gnome upstream disagrees with your opinion
- in fact, I think the disagreement goes at very least back to 2.30.
Anyway, even if the bug is valid, the quality of this bug report is questionable at best.
In summary, looks like an updated gst-vol-control-support.patch is needed for gnome3 cycle
Pacho, given what I said in comment 3, could this be the reason for as-needed problem from bug 327609 comment 5 ?
(In reply to comment #5)
> Pacho, given what I said in comment 3, could this be the reason for as-needed
> problem from bug 327609 comment 5 ?
That was an old problem only affecting Jory that, later, was unable to reproduce and solved in his system
(In reply to comment #4)
> In summary, looks like an updated gst-vol-control-support.patch is needed for
> gnome3 cycle
Does this mean you can *fix* the dependency on pulseaudio? That would be *extremely* cool. I chatted briefly with a gnome-shell dev who feels no modern desktop should be without multiple concurrent access to the soundcard and too many variable configurations too difficult to support. So, pulseaudio.
(In reply to comment #3)
> Given no build log, just such snippet, I'd say the best resolution would be
Well, I agree, but the summary does state the situation in order to catch a potential problem devs might not see. It's an overlay, not ready for release kind of stuff, so not critical. Just trying to give some user experience.
> Looking at that snippet, I'd say that for no good reason it was linking to a
> static lib [8<]
No idea about that. Seemed like the patch failed and libraries were missing so the build, or linking, or whatever failed.
> And your comment already says, that Gnome upstream disagrees with your opinion
> - in fact, I think the disagreement goes at very least back to 2.30.
Well, there you go. So it should perhaps die with a warning to add the flag unless the flag is enabled. Unless this can be fixed by gentoo "downstream"...
> Anyway, even if the bug is valid, the quality of this bug report is
> questionable at best.
Yep. I'm rusty. Sorry!
That probably depends on your definition of "fixed".
GStreamer won't provide same functionality as pulseaudio, so Gnome apps expecting that functionality will break in unpredictable ways.
Anyway, while I'm not a fan of pulseaudio, I really don't what's the big deal about it.
Well, there is a usecase, were pulseaudio breaks for me, but I don't run into it often (and from a modern desktop POV it's probably invalid).
Pulseaudio is now a hard dependency of GNOME 3, so USE=pulseaudio on g-s-d is quite useless. I've removed it for now. We can decide whether we can support non-pulseaudio setups after we've got GNOME 3 working.
Closing fixed since the compilation problems are now fixed. Thanks for reporting!
I guess, pulseaudio is still a hard dep for Gnome3, in that case, we will probably need to document it in upgrade guide to let people enable pulseaudio without too much problems (looks like http://www.pulseaudio.org/wiki/PerfectSetup is outdated and, then, I don't know what guide should we follow to have a working pulseaudio setup)
(In reply to comment #10)
> I guess, pulseaudio is still a hard dep for Gnome3, in that case, we will
> probably need to document it in upgrade guide to let people enable pulseaudio
> without too much problems (looks like
> http://www.pulseaudio.org/wiki/PerfectSetup is outdated and, then, I don't know
> what guide should we follow to have a working pulseaudio setup)
Will CC pulseaudio people for that as I still don't run pulseaudio and I am unsure about what could break if not updating properly (problems with games, flash...)
*** Bug 391911 has been marked as a duplicate of this bug. ***
Anything we need to do on this?
(In reply to comment #13)
> Anything we need to do on this?
I think nothing is needed since almost all work auto-magically since media-plugins/alsa-plugins-1.0.25-r1 :)