This issue is forced at the tinderbox by making: export XDG_DESKTOP_DIR="/root/Desktop" export XDG_DOCUMENTS_DIR="/root/Documents" export XDG_DOWNLOAD_DIR="/root/Downloads" export XDG_MUSIC_DIR="/root/Music" export XDG_PICTURES_DIR="/root/Pictures" export XDG_PUBLICSHARE_DIR="/root/Public" export XDG_TEMPLATES_DIR="/root/Templates" export XDG_VIDEOS_DIR="/root/Videos" export XDG_RUNTIME_DIR="/root/run" export XDG_CONFIG_HOME="/root/config" export XDG_CACHE_HOME="/root/cache" export XDG_DATA_HOME="/root/share" pls see bug #567192 too VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: mkdir S: deny ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: gnome_20170525-085524 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-6.3.0 * Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7 (fallback) [3] pypy3 (fallback) [4] jython2.7 (fallback) Available Ruby profiles: [1] ruby21 (with Rubygems) [2] ruby22 (with Rubygems) * java-config: The following VMs are available for generation-2: *) IcedTea JDK 7.2.6.10 [icedtea-bin-7] 2) IcedTea JDK 3.4.0 [icedtea-bin-8] Available Java Virtual Machines: [1] icedtea-bin-7 system-vm [2] icedtea-bin-8
Created attachment 475532 [details] emerge-info.txt
Created attachment 475534 [details] config.log.tbz2
Created attachment 475536 [details] dev-lang:fsharp-4.1.18:20170607-194535.log
Created attachment 475538 [details] emerge-history.txt
Created attachment 475540 [details] environment
Created attachment 475542 [details] etc.portage.tbz2
Created attachment 475544 [details] sandbox-17668.log
Created attachment 475546 [details] temp.tbz2
any suggestions how should that be fixed? should XDG_DATA_HOME and friends be added with addwrite?
(In reply to Cynede from comment #9) no, I think there's now an eclass function for that. - pls ask mgorny for details
Failing packages need to use xdg.eclass or, at least, xdg_environment_reset from xdg-utils.eclass
Removed from the tree