We already need it for cheese, sound-juicer and rhythmbox. Is there any case when setting GST_INSPECT to true is harmful? Adding this to the eclass with help to prevent users from getting random sandbox failures when a package calls gst-inspect (or starts to do that) What do you think? Thanks
not sure its place should be in gnome2.eclass. Also, not all packages respect this variable, a few I had to actively patch for them to respect it and leave the PM do the job.
Well, the idea would be to at least try to cover the packages honoring that variable. Regarding the place, I always doubt if PMs should pass some variables/options for "cleaning" purposes (like exporting HOME and so), but that suggestions always get stalled (like bug 444568)
Just saw bug #508096, imho this is not the solution for it (and iirc it does not look that variable up). The solution is to report upstream what plugin tries to open this device while simply scanning the available plugins. When I last spoke to upstream about this, they said it was a bug and needed to be reported.
Will try to report then if I figure out how to find that offending plugins ;)
I would still export it to at least cover the packages that respect that variable instead of waiting them to randomly break and come after fixing/workarounding them one by one
Done, for the packages not respecting it we will still need to figure out about how to handle them in bug 570624 (that will likely be harder as upstream think we are wrong preventing that accesses... please note that using addpretend for them and, then, still forbidding the access but not dying on our side, makes the packages happy)
