ccache does not work with FEATURES="userpriv" due to wrong permissions of /var/tmp/ccache subdirectories. Reproducible: Always Steps to Reproduce: 1. emerge ccache 2. set "FEATURES=userpriv usersandbox" in /etc/make.conf 3. emerge something 4. run "CCACHE_DIR=/var/tmp/ccache ccache -s" 5. emerge something 6. run "CCACHE_DIR=/var/tmp/ccache ccache -s" Actual Results: ccache is not used due to incorrect permissions. Running "chown -R portage:portage /var/tmp/ccache" fixes that. References: - Bug 16664 - Bug 22125 - Bug 33162 All these bugs are marked as fixed but they are not fixed. It still does not work even with portage 2.0.51.19. Expected Results: Portage should use ccache with FEATURES="userpriv usersandbox". emerge info Portage 2.0.51.19 (default-linux/x86/2004.3, gcc-3.3.5, glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r13 i686) ================================================================= System uname: 2.6.9-gentoo-r13 i686 AMD Athlon(tm) XP 2200+ Gentoo Base System version 1.6.9 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#2, Feb 7 2005, 10:01:40)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=athlon-xp -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/glftpd/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=athlon-xp -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache collision-protect distlocks makecheck sandbox sfperms userpriv usersandbox" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow acpi apache2 apm arts avi bash-completion berkdb bitmap-fonts crypt curl emboss encode f77 fbcon firebird font-server foomaticdb fortran gd gd-external gdbm gif gpm gtk2 imap imlib innodb java jpeg junit libg++ libwww mad maildir mikmod mmx motif mpeg mysql ncurses nls nptl odbc oggvorbis opengl oss pam pdflib perl png pnp postgres python quicktime readline sasl sdl slang snmp socks5 spell sqlite sse ssl svga tcpd tiff truetype truetype-fonts type1-fonts unicode xml xml2 xmms xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS
There should also be a loud warning when someone adds userpriv and usersandbox to FEATURES, which already has ccache because the old cache gets abandonned.
Created attachment 56162 [details, diff] Patch that hopefully does enough This will do the complete chmod/chgrp -R when switching between userpriv and non-userpriv only. In either case, it'll be a chmod -R ug+rw $CCACHE_DIR. Then portage:portage for userpriv and root:portage non-userpriv. I can't see a way to fix already "broken" installations other than "fixing" the permissions at every turn, but that would be a major performance disadvantage with very little gain.
Why not a chown -1:(portage_gid) -R ; find ${CCACHE_DIR} -type d -print0 | xargs --null chmod 04775 If required, a find ${CCACHE_DIR} -type f -print0 | xargs -null chmod 775 also...?
When? At every run?
Jason, does this fix Bug 85085 as well?
Bug 85085 is completely separate. That is in relation to a large overhaul of the relevant code. It's not going to be released as stable any time soon. Had a thought with regard to Brian's suggestion though.. How about looking at the owner of CCACHE_DIR? If the permissions on that dir aren't correct, adjust underneath CCACHE_DIR as -1:portage with ug+rw and then adjust CCACHE_DIR, where: userpriv -> portage:portage -userpriv -> root:portage
Reworked for this logic and fixed some bugs in my untested code, tested ;), and it works. Flicking userpriv on and off still utilizes the cache.
Fixed on or before 2.0.51.22-r1
Looking through the batch of bugs, I'm not sure that some of these are actually fixed in stable. Others, the requirements have possibly changed after the initial fix was committed. If you think this bug has been closed incorrectly, please reopen or ask that it be reopened.
(In reply to comment #9) > Looking through the batch of bugs, I'm not sure that some of these are > actually fixed in stable. Others, the requirements have possibly changed after > the initial fix was committed. Yes, it is fixed, I can confirm that it changes the permissions back and forth when switching between userpriv/-userpriv (portage 2.0.51.22-r1).
