My recent change to the sanity class to warn users when they don't have R/W permission to their SSTATE_CACHE directory has caused at least a couple of users trouble, including the Yocto project autobuilder.
I have been unable to reproduce the issue but after discussionwith Elizabeth and Chris on #yocto I came up with the following series. The series includes a revert my original change as it seems the simple logic has severla edge cases. I replace it later in the series with a simple piggy-back on the existing check_create_long_filename() call, where I make the suggestion of using SSTATE_MIRRORS if that call fails with "Permission denied" when called against SSTATE_DIR. This check has been in use for some time and, to the best of my knowledge, doesn't trigger invalid failures. Thanks to Chris and Elizabeth for pointers as to why this was failing. Cheers, Joshua The following changes since commit e6333825c3482a559a0c0499e17f8f48d3042ddf: tune-mips64.inc: Add new tune file for mips64 big-endian (2012-05-20 20:24:37 -0700) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib josh/sanity http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=josh/sanity Joshua Lock (7): Revert "sanity.bbclass: check user can read and write to SSTATE_DIR" sanity.bbclass: copy the data store and finalise before running checks sanity.bbclass: data.getVar(VAR, obj, exp) -> obj.getVar(VAR, exp) sanity.bbclass: add newline to check_create_long_filename failure message sanity.bbclass: add extra information when SSTATE_CACHE unusable sanity.bbclass: catch an extra exception in check_create_long_filename sanity.bbclass: check sanity at BuildStarted rather than ConfigParsed meta/classes/sanity.bbclass | 153 ++++++++++++++++++++++--------------------- 1 files changed, 78 insertions(+), 75 deletions(-) -- 1.7.7.6 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
