Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 196852 - Keywording of >=media-video/totem-2.20 dependencies
Summary: Keywording of >=media-video/totem-2.20 dependencies
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All All
: High enhancement (vote)
Assignee: Gentoo Linux Gnome Desktop Team
URL:
Whiteboard:
Keywords: InVCS, KEYWORDREQ
Depends on:
Blocks: gnome2.20 218794 260063
  Show dependency tree
 
Reported: 2007-10-23 21:29 UTC by Gilles Dartiguelongue
Modified: 2010-11-14 17:53 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gilles Dartiguelongue gentoo-dev 2007-10-23 21:29:19 UTC
Hi archs,

this bug is for reminding you that galago use flag for totem is masked on your archs because dev-libs/libgalago isn't keyworded.

It is used for a plugin so it's not high priority. Thanks for considering.
Comment 1 Roy Marples (RETIRED) gentoo-dev 2007-10-24 11:24:38 UTC
Actually this was quite easy, fixed.
Comment 2 Gilles Dartiguelongue gentoo-dev 2007-10-24 11:32:06 UTC
erm there are other arches here :), thanks anyway
Comment 3 Gilles Dartiguelongue gentoo-dev 2008-03-30 18:40:46 UTC
arm, sh, ping ? If you are not interested, you can just unCC yourself from the bug, it's ok.
Comment 4 Rémi Cardona gentoo-dev 2008-08-25 22:16:10 UTC
I think 5 months is enough to prove arm and sh are indeed not interested.

Closing fixed
Comment 5 Mart Raudsepp gentoo-dev 2008-08-26 05:32:11 UTC
Please don't close arm/sh bugs with loosing the request. The plan was to gather all arm and all sh keywords into one bug and stablings into another before closing all the different bugs.
Comment 6 Raúl Porcel (RETIRED) gentoo-dev 2009-04-05 18:42:01 UTC
arm should be done now.

For sh, as I already mentioned to Mart, something along latest totem needs evolution-data-server, which needs xulrunner, which i'm not sure it works on superh, i'll have a look, but it would be cool if it didn't depend on it, tbh :)
Comment 7 Raúl Porcel (RETIRED) gentoo-dev 2009-04-05 21:18:08 UTC
(In reply to comment #6)
> For sh, as I already mentioned to Mart, something along latest totem needs
> evolution-data-server, which needs xulrunner, which i'm not sure it works on
> superh, i'll have a look, but it would be cool if it didn't depend on it, tbh
> :)
> 

Gilles was right, e-d-s doesn't need xulrunner, what needed xulrunner was yelp :P
Still...
Comment 8 Raúl Porcel (RETIRED) gentoo-dev 2009-04-28 18:21:14 UTC
So...

totem-pl-parser deps on e-d-s, which depends on nss, which is a no-go for SH. Suggestions? 
Comment 9 Mart Raudsepp gentoo-dev 2009-04-29 10:30:01 UTC
This is upstream bug http://bugzilla.gnome.org/show_bug.cgi?id=522639
It has a solution to make evolution-data-server optional through an unsupported configure option that drops certain playlists support (I think it was iPod related). The proper solution would be to get that parsing functionality without pulling in the whole of evolution-data-server.
In the future there will be libcamel separate from evolution-data-server, but that's probably quite hefty still. Another option would be to manage to get that parsing code imported alone.
Currently totem-pl-parser depends on evolution-data-server purely for calling one function out of libcamel.
Comment 10 Nirbheek Chauhan (RETIRED) gentoo-dev 2009-10-24 11:15:09 UTC
(In reply to comment #9)
> Currently totem-pl-parser depends on evolution-data-server purely for calling
> one function out of libcamel.
> 

totem-pl-parser 2.28 uses gmime instead of e-d-s now; but keywording totem itself for sh is more difficult due to the plethora of plugins that have been added.

Perhaps the patch for using gmime instead of e-d-s could be backported for sh? Would probably be nice for non-gnome users that want to use totem/rhythmbox too.
Comment 11 Gilles Dartiguelongue gentoo-dev 2010-11-14 17:53:32 UTC
It's been years this bug has been opened now. Multiple solutions could have been used by remaining arches if they had wished so, and the last supposed obstacle has been fixed last year by having an non-eds dependency. Closing.