Created attachment 583686 [details, diff] pass TMPDIR into build sanbox sys-kernel/genkernel-4.0.0_beta6 don't pass TMPDIR into build sanbox, eltpatch use /tmp. (I run genkernel in ebuild, checked with top-level sandbox). Simple add TMPDIR into envvars sanitize it.
Did you really encounter an error or did you only read code and reported? I am asking becaust eltpatch patch shouldn't use TMPDIR because we set ELT_LOGDIR in https://gitweb.gentoo.org/proj/genkernel.git/tree/worker_modules/gkbuild.sh?h=v4.0.0_beta6#n654
I now understand the problem. PS: Curious, is this the only problem you encounter? I am currently adding --no-sandbox to allow running within portage where already a sandbox process is running.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=306dd3f2f8c5eb1638a419f691781b68eeaf8d58 commit 306dd3f2f8c5eb1638a419f691781b68eeaf8d58 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2019-07-20 22:03:27 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2019-07-21 16:02:00 +0000 gen_funcs.sh: gkbuild(): Export $TMPDIR Some portage programs like eltpatch depend on $TMPDIR. Bug: https://bugs.gentoo.org/690264 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> gen_funcs.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Released with >=sys-kernel/genkernel-4.0.0_beta8.
Yes, no more true sandbox-related problems ;). Near this area was problems with config-order, so logfile & tempdur/tmpdir from cmdline was always ignored to (to sandbox [un]pleasure), but I move everything into config file and keep bug reporting to future - as I don't figure out precise case. IMHO priority of cmdline must be strictly on top, so cmdline values must be always respected.
PS But I keep in mind to try all packages. Now was only basic (busybox, etc) + mdadm.
(In reply to Denis Kaganovich from comment #5) > Yes, no more true sandbox-related problems ;). Near this area was problems > with config-order, so logfile & tempdur/tmpdir from cmdline was always > ignored to (to sandbox [un]pleasure), but I move everything into config file > and keep bug reporting to future - as I don't figure out precise case. IMHO > priority of cmdline must be strictly on top, so cmdline values must be > always respected. I noticed this as well while working on your bug report and it should be already resolved in >=sys-kernel/genkernel-4.0.0_beta8.
Strange: on most rare updated systems, disabling second sandbox required. On never - just warning happened. On rare - emerged (updated) "system" and genkernel (-DuN option), so still unknown true reason. Thanks for option to disable sanbox...
