From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.seebs.net (mail.seebs.net [162.213.38.76]) by mail.openembedded.org (Postfix) with ESMTP id 55A05788D4 for ; Fri, 23 Mar 2018 17:23:20 +0000 (UTC) Received: from seebsdell (unknown [24.196.59.174]) by mail.seebs.net (Postfix) with ESMTPSA id 3D9ED2E8974; Fri, 23 Mar 2018 12:23:22 -0500 (CDT) Date: Fri, 23 Mar 2018 12:23:17 -0500 From: Seebs To: "Burton, Ross" Message-ID: <20180323122317.02bcb2b9@seebsdell> In-Reply-To: References: <20180323112820.12bc94a4@seebsdell> <20180323114939.218c0607@seebsdell> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Cc: Enrico Scholz , OE-core Subject: Re: pseudo: host user contamination X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 17:23:21 -0000 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 23 Mar 2018 16:56:16 +0000 "Burton, Ross" wrote: > On 23 March 2018 at 16:49, Seebs wrote: > > On Fri, 23 Mar 2018 16:30:55 +0000 > > "Burton, Ross" wrote: > > > >> Because in GNU's infinite wisdom they're using renameat2() to do > >> atomic renames in the mv command, and as renameat2 isn't in the > >> headers for F27 it just does a syscall directly. This is in > >> upstream coreutils so once they make a release, everyone gets it. > > > > UGH. > > > > I... am really unsure whether it's possible to catch that, because > > I really, really, don't want to try to intercept raw syscall() > > calls. I don't think that ends well. > > > > I wonder if they can be persuaded to, you know, NOT use a syscall > > directly when it's not in the system headers, on the grounds that > > the system headers define the exported interface, and bypassing > > them is almost certainly a very bad idea. > > Just chatting to the fakeroot maintainer now, as this is presumably > going to break the entire Debian build infrastructure when they get > the coreutils upgrade. He isn't massively thrilled either. They have > the option of just reverting these changes to coreutils though. It's *possible* that there's a workaround, but I think realistically the right answer is probably "yell at coreutils not to do that". -s