From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 7EDF41382C5 for ; Thu, 29 Mar 2018 15:04:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D502AE08E2; Thu, 29 Mar 2018 15:04:14 +0000 (UTC) Received: from mail-qt0-f193.google.com (mail-qt0-f193.google.com [209.85.216.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6D59DE084A for ; Thu, 29 Mar 2018 15:04:14 +0000 (UTC) Received: by mail-qt0-f193.google.com with SMTP id z23so5846577qti.5 for ; Thu, 29 Mar 2018 08:04:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:references:in-reply-to :message-id:mime-version:content-disposition :content-transfer-encoding; bh=iYPHaUjzWfuRRDAXBSjBgMrox1TXshGhfPzhbmsAad8=; b=oppYnHSnAWz313sqHwEEeLjg3SPao1WoE/c8s9ov/fxWJaB+TrX5KsqMPGrcfe3YkR PRxfCXMjJi0ogpYQB0awzqHedEm2EtS/VcnLegClM8OBFxkbIDBFmlpIqQbSOmaVwiCZ mBXlPe346sCDKsZlFDb7lc3KRNshD7n+JYYa1Khm6BySkVrDlVvfCMt0TcmFWRbQIgMu g+HsfaNRnqZnogO1ivgKAW6Owp85gQ2Su8rgFYp+Oh8DtPocF3ZurcyieCNYs280ppAa KFhCT024DhXx74/sBsBPkpwvl+AVW8qE0kqKoHCN88PaHKPNXe09tf231JG2CTjG8Oab slMQ== X-Gm-Message-State: AElRT7GwU3aYf3Myaqtv2EdPNcX4uJVA1sMtj/k7acFUF3l/9tb6wVz4 wnmjdXVq4WuCJu25VJUwU26fPCbL X-Google-Smtp-Source: AIpwx4/gfkEl1Nd0z/zkhiln0JJUVAQ7hmS9YOy+d50qJtrYDgBRdWOUPgmJI8IjSSav32GpiIZaOg== X-Received: by 10.237.37.129 with SMTP id x1mr11741376qtc.78.1522335853474; Thu, 29 Mar 2018 08:04:13 -0700 (PDT) Received: from ffortso4 (c-76-23-130-96.hsd1.ct.comcast.net. [76.23.130.96]) by smtp.gmail.com with ESMTPSA id t36sm4656285qtd.69.2018.03.29.08.04.12 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 29 Mar 2018 08:04:13 -0700 (PDT) Date: Thu, 29 Mar 2018 11:04:11 -0400 From: Jack Subject: Re: [gentoo-user] sys-libs/e2fsprogs-libs causing sandbox violation in /root/.ccache? To: gentoo-user@lists.gentoo.org References: In-Reply-To: (from plevine457@gmail.com on Thu Mar 29 00:33:06 2018) X-Mailer: Balsa 2.5.3a-288-gcbc3eaab Message-Id: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 68bcf0b8-927b-467f-aa0d-2843ce1a6aed X-Archives-Hash: b7afc232db07ea941b5b1dce7519d26f On 2018.03.29 00:33, P Levine wrote: > Th > =E2=80=8Bis has been going on for the last few months. It only seems to = =20 > happen for > sys-libs/e2fsprogs-libs. I haven't filed a bug yet as I'm unsure if =20 > there > is something I'm overlooking on my end. I can delete /root/.ccache =20 > and > remerge and it seems to be fine after that, but while updating the =20 > world a > few weeks later it sporadically returns. >=20 > The relevant part of the build: >=20 > make[1]: 'compile_et' is up to date. > > make[1]: Leaving directory > > =20 > '/var/tmp/portage/sys-libs/e2fsprogs-libs-1.44.1/work/e2fsprogs-libs-1.44= .1-ab > > i_x86_64.amd64/lib/et' > > making all in lib/et > > * ACCESS DENIED: utimes: /root/.ccache > > * ACCESS DENIED: mkdir: /root/.ccache/3 > > make[1]: Entering directory > > =20 > '/var/tmp/portage/sys-libs/e2fsprogs-libs-1.44.1/work/e2fsprogs-libs-1.44= .1-a > > bi_x86_64.amd64/lib/et' > > make[1]: Nothing to be done for 'all'. > > make[1]: Leaving directory > > =20 > '/var/tmp/portage/sys-libs/e2fsprogs-libs-1.44.1/work/e2fsprogs-libs-1.44= .1-ab > > i_x86_64.amd64/lib/et' >=20 >=20 > =E2=80=8BAnd the sandbox report:=E2=80=8B >=20 > * --------------------------- ACCESS VIOLATION SUMMARY > > --------------------------- > > * LOG FILE: "/var/log/sandbox/sandbox-28430.log" > > * > > 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: utimes > > S: deny > > P: /root/.ccache > > A: /root/.ccache > > R: /root/.ccache > > C: x86_64-pc-linux-gnu-gcc -x c -v -c /dev/null -o /dev/null > > F: mkdir > > S: deny > > P: /root/.ccache/3 > > A: /root/.ccache/3 > > R: /root/.ccache/3 > > C: x86_64-pc-linux-gnu-gcc -x c -v -c /dev/null -o /dev/null > > * > > =20 > -------------------------------------------------------------------------= ------- >=20 >=20 > Has anyone else run into sporadic build failures like this? >=20 I've had similar issues with various ebuilds, for me most commonly =20 nodejs. It's because of some XDG... environment variable. Before you =20 do the emerge, either do "su -" or something else to clear the environment. It's not really anything =20 specific to the ebuild, other than emerge not sanitizing the =20 environment first. Also, what I have sometimes done as a temporary workaround to save =20 redoing the compile is to manually go to the build directory and type =20 "make" to complete the compile, then complete the remaining ebuild =20 steps (install and qmerge, I think - from memory). Jack=