Some packages do some version detection magic calling invoking git from within the build system. Release tarballs often lack the .git repository data and the stdout of the git command is empty. But if the system is using any kind of git repository above the PORTAGE_TEMPDIR, like a /.git, these call to git trigger an read access to /.git resulting in a sandbox violation like 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: open_wr S: deny P: /.git/index.lock A: /.git/index.lock R: /.git/index.lock C: git update-index --refresh Solutions: - quick'n'dirty: temporarily rename the /.git to /.git_ - mid term solution: place a decoy empty git repo inside $PORTAGE_TEMPDIR - long term: eliminate the git call from the build system
Another option, just setting any GIT_DIR and GIT_WORK_TREE within the sandbox allowed area /etc/portage/package.env net-misc/spice-gtk decoy-git /etc/portage/env/decoy-git GIT_WORK_TREE=${WORKDIR} GIT_DIR=${WORKDIR}
media-libs/opencv-3.0.0:0/3.0::gentoo is affected, too.
net-misc/rabbitmq-server-3.6.1::gentoo as well.
sys-cluster/ceph-9.2.1-r2, too
sys-cluster/ceph-10.2.2-r1
Couldn't all these bugs be fixed by setting GIT_CEILING_DIRECTORIES to something sensible?
(In reply to Felix Janda from comment #6) > Couldn't all these bugs be fixed by setting GIT_CEILING_DIRECTORIES to > something sensible? Thanks for the hint! # less /etc/portage/env/git-root.conf GIT_CEILING_DIRECTORIES=${PORTAGE_TMPDIR} # less /etc/portage/package.env sys-cluster/ceph git-root.conf works smooth!
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aa48765f6497dd0443a7bfb747386e7c15e80d90 commit aa48765f6497dd0443a7bfb747386e7c15e80d90 Author: Michael Weber <xmw@gentoo.org> AuthorDate: 2018-01-28 19:49:10 +0000 Commit: Michael Weber <xmw@gentoo.org> CommitDate: 2018-01-28 19:49:28 +0000 dev-lang/vala: Limit errornous git invocation to ${WORKDIR} by exporting GIT_CEILING_DIRECTORIES. Bug: https://bugs.gentoo.org/558556 Closes: https://bugs.gentoo.org/483134 Package-Manager: Portage-2.3.20, Repoman-2.3.6 dev-lang/vala/vala-0.32.1.ebuild | 5 ++++- dev-lang/vala/vala-0.34.9.ebuild | 5 ++++- dev-lang/vala/vala-0.36.7.ebuild | 3 +++ 3 files changed, 11 insertions(+), 2 deletions(-)}
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=adc72bb8a7dcdd0866e9030ff4610e9c13cce08b commit adc72bb8a7dcdd0866e9030ff4610e9c13cce08b Author: Michael Weber <xmw@gentoo.org> AuthorDate: 2018-01-28 20:21:05 +0000 Commit: Michael Weber <xmw@gentoo.org> CommitDate: 2018-01-28 20:21:05 +0000 app-accessibility/speech-dispatcher: Limit errornous git invocation to ${WORKDIR} by exporting GIT_CEILING_DIRECTORIES. Closes: https://bugs.gentoo.org/573732 Bug: https://bugs.gentoo.org/558556 Package-Manager: Portage-2.3.20, Repoman-2.3.6 app-accessibility/speech-dispatcher/speech-dispatcher-0.8.3.ebuild | 5 ++++- app-accessibility/speech-dispatcher/speech-dispatcher-0.8.7.ebuild | 3 +++ 2 files changed, 7 insertions(+), 1 deletion(-)}
Why are non-maintainer commits done for this without any ACKs or work towards fixing upstream? Some hacks added without discussion and maintainer agreement NOT appreciated.
sys-devel/clang-6.0.1 as well
short addition: dev-lang/vala-0.42.7 still/again has the issue
Has the same ussue with: >[ebuild rR ] sys-devel/llvm-8.0.1
