Summary: | [gnome-overlay] =media-video/totem-2.26.0 sandbox issue | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Kobboi <gentoo> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED WORKSFORME | ||
Severity: | major | CC: | chrissicool, magowiz, maxbritov, pacho |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 263083 | ||
Attachments: |
Build log from Totem
this works My /etc/gconf files and filesystem properties |
Description
Kobboi
2009-03-16 21:43:19 UTC
same at me :( no one whos interested to fix it? Created attachment 186241 [details]
Build log from Totem
i found this in the ebuild src_compile() { # FIXME: why does it need write access here, probably need to set up a fake # home in /var/tmp like other pkgs do addpredict "$(unset HOME; echo ~)/.gconf" addpredict "$(unset HOME; echo ~)/.gconfd" addpredict "$(unset HOME; echo ~)/.gnome2" gnome2_src_compile } try to do an patch Created attachment 186242 [details, diff]
this works
This ebuild works and the finish compiled totem works fine =) have fun with it
I got this today. But... /me re-emerged gnome-session-2.26.0 and sandbox-1.6 And "completed emerge (1 of 1) media-video/totem-2.26.0-r1" without any patches. should be fixed now. I moved the addpredict to src_configure. *** Bug 265611 has been marked as a duplicate of this bug. *** *** Bug 265611 has been marked as a duplicate of this bug. *** Bug not fixed, or pops up again with 2.26.1 I thought I did the right thing by creating another bug report, since we're talking about a different version of the software and possibly a totally different family (-r*) of ebuilds. I apologize for the trouble. please provide a build.log The log is at the bug that was marked as a duplicate of this one. Are attachments meant to be duplicated as well? hum no it's ok. Do you have mandatory/default settings set in your gconf system-wide configuration ? Created attachment 187887 [details]
My /etc/gconf files and filesystem properties
$ cat /etc/gconf/2/path # This file stores the addresses of config sources for GConf # When a value is stored or requested, the sources are scanned from top to # bottom, and the first one to have a value for the key (or the first one # to be writeable) is used to load/store the data. # See the GConf manual for details # Look first in systemwide mandatory settings directory xml:readonly:/etc/gconf/gconf.xml.mandatory # To read in any mandatory settings that the Sys Admin may have created # prior to a desktop system upgrade. The SysAdmin can stick read-only system # wide sources in this file. include /etc/gconf/2/local-mandatory.path # Now see where users want us to look - basically the user can stick arbitrary # sources in a ~/.gconf.path file and they're inserted here include "$(HOME)/.gconf.path" # Give users a default storage location, ~/.gconf xml:readwrite:$(HOME)/.gconf # Location for system-wide settings that are set by the defaults mechanism xml:readonly:/etc/gconf/gconf.xml.system # To read in any defaults settings that the Sys Admin may have created # prior to a desktop system upgrade. The SysAdmin can stick default values # system-wide in this file. include /etc/gconf/2/local-defaults.path # Finally, look at the systemwide defaults xml:readonly:/etc/gconf/gconf.xml.defaults If someone can still reproduce this bug, please provide a config.log and reopen this bug. Thanks. I had that exact same issue since totem-2.24.something until now. Today I enabled "policykit" USE flag, ran "emerge -uvDN gnome" and totem installed without a problem. I hope this helps. the duplicated bugs look like older gconf not creating some needed directories in early 2.26 move to the tree. Since I can't trigger sandbox issues even by running commands configure does by hand and cleaning up root's home, I'm closing this worksforme. Please reopen with a config.log and ls -l /root if you can reproduce with up to date ~arch box. This is probably useless information (since I can't provide you with anything more), but just fyim I had the same problemn again, upgrading to 2.27.2. A second emerge attempt went without a problem. Maybe something in the first emerge's pkg_postinst or something allowed the second emerge to succeed? |