From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C13ED3191A4 for ; Fri, 19 Sep 2025 15:16:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758295004; cv=none; b=KaztA+PTKa//mmou9hDpoA3g9tbHRzS2Y6bJ1gnMR2wmVFS2o76vtnGZp73gI8EF5uRqy5DoBYytEdnjgVnqPHjPSGeubsIowotVcsBS0TJ4J0zQlNw0zp22KP2r8RAJlaUxyzNXj3c9MN+h1BfIFDsX7tO2UQf18wUCHc5AQWA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758295004; c=relaxed/simple; bh=eNb1+V2qa2o9Lou2Af5WYe0Q2ocBVnBGkn3eZ2KzYHY=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Wibt5AEyrpnWrdAz/iULClQpWzVmiJ7Sux60Aqn+/b+kg/IL+AxpQbHqHhCBRYTQ3yLkxkXcfYxXHclC7f9sE33wrAe7vEsQ3yHW7ChRIStLuasn1MANiOTOxxfUsBk5aT63SjozxAI6QvoAqho5mRudYMtdJkLi4XBcZ5EFGN0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ah8B8cUO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ah8B8cUO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7FD07C4CEF1; Fri, 19 Sep 2025 15:16:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1758295004; bh=eNb1+V2qa2o9Lou2Af5WYe0Q2ocBVnBGkn3eZ2KzYHY=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Ah8B8cUOqRFkNFPEVsCMDlDFSVnxfgnBgcn0qVRXoNKH306rWgkjYXlSXFcMnzJ7P vOEZwXD1Hxq6oGQ6ogRDxQP+IgkDDv+KPp6UMzRuITiPrsxIbWs4PDBT4K5G4xj8mo OIDYpdISri1X+54kAttG45tM/194OHsW9K2qbej5fYTYOz77/wf28COzYeD2cuJgOd /ghUjdwcnjRYVUfvqe8UPFuH9HRgH6nJJw5I9Z7ECM3cOZ6wAjYbOHjjE6dwiyXynw 3EKAEPMzLbp453KRFZIG64r63SbgPOmW9XOgLMTJnesIubsSv298EhveMu5ZPYZoVf C6xZsSgwCFiMw== Date: Fri, 19 Sep 2025 17:16:39 +0200 From: Alexey Gladkov To: kbd@lists.linux.dev, Steffen Nurpmeso Subject: Re: kbd 2.9.0: build error (under fakeroot(1) environment) Message-ID: References: <20250909134533._bzZjw_N@steffen%sdaoden.eu> <20250909211818.pSB8ayld@steffen%sdaoden.eu> <20250910123724.s2uU6eVo@steffen%sdaoden.eu> Precedence: bulk X-Mailing-List: kbd@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250910123724.s2uU6eVo@steffen%sdaoden.eu> On Wed, Sep 10, 2025 at 02:37:24PM +0200, Steffen Nurpmeso wrote: > Alexey Gladkov wrote in > : > |On Tue, Sep 09, 2025 at 11:18:18PM +0200, Steffen Nurpmeso wrote: > |> Alexey Gladkov wrote in > |> : > |>|On Tue, Sep 09, 2025 at 03:45:33PM +0200, Steffen Nurpmeso wrote: > |>|> My distribution (CRUX) updated to 2.9.0, and the build failed via > |>|> > |>|> cp: failed to preserve ownership for /tmp/.pkgmk/pkg/usr/share/kbd/ke\ > |>|> ym\ > |>|> aps/i386/qwertz/sr-latin.map.gz: Operation not supported > |>|> > |>|> Thing is that this seems to only work for real root user, but that > |>|> is not who is doing it, really. > |>| > |>|cp -a is used in the makefile. The -a means no dereference and preserve > |>|links and other attributes. This should not be a problem if you have > |>|the same user. > |> > |> GNU coreutils 9.7 cp(1) is of a different opinion: > |> > |> $ touch xa > |> $ ln -s xa xb > |> $ cp -a xb xc > |> cp: failed to preserve ownership for xc: Operation not supported > | > |No. This is security settings on your system. > | > |On my laptop: > | > |$ touch xa > |$ ln -s xa xb > |$ cp -a xb xc > > |$ ls -la > |total 8 > |drwxr-xr-x 2 legion legion 4096 Sep 10 11:30 . > |drwxr-xr-x 15 legion legion 4096 Sep 10 11:30 .. > |-rw-r--r-- 1 legion legion 0 Sep 10 11:30 xa > |lrwxrwxrwx 1 legion legion 2 Sep 10 11:30 xb -> xa > |lrwxrwxrwx 1 legion legion 2 Sep 10 11:30 xc -> xa > > |$ cp --version | head -1 > |cp (GNU coreutils) 9.7 > > This is really strange; i have no "security setting", actually, > only the fs.protected_* sysctls are set. > I get the failure in the "sticky" /tmp/ as well as as myself in my > home directory. Looking at coreutils cp.c the error comes from > > if (x->preserve_ownership) > { > if (lchownat (dst_dirfd, relname, p->st.st_uid, p->st.st_gid) > != 0) > ... > error (0, errno, _("failed to preserve ownership for %s"), > quoteaf (dst_name)); > > Here there is no lchownat(3/2), and if i do (copied from manual > and made runnable) > > #include > #include > #include > #include > #include > #include > #include > int main(void){ > struct passwd *pwd; > struct group *grp; > int x; > > pwd = getpwnam("steffen"); > grp = getgrnam("steffen"); > x = lchown("xb", pwd->pw_uid, grp->gr_gid); > fprintf(stderr, "x=%d errno=%s\n", x, strerror(errno)); > return 0; > } > > i get > > #?148|kent:x$ fakeroot tcc -run t.c > x=0 errno=Success > #?0|kent:x$ tcc -run t.c > x=0 errno=Success > > wherever i try, and so it seems to me the GNU coreutils > lib/fchownat.c fallback implementation of lchownat() is bogus > thus?? > > ... > |>|You can try to change "cp -a" by "cp -dPR". Maybe this will help with > |>|fakeroot. > |> > |> Yes, it does. > | > |Good. Thanks! > | > |https://web.git.kernel.org/pub/scm/linux/kernel/git/legion/kbd.git/commi\ > |t/?id=db82eb6f86e6c0b8ac4260e88b88d66e1cd7c077 > > Ah, and the kernel.org "you are not a robot check" is totally > bogus. If i go directly to > > https://git.kernel.org/pub/scm/linux/kernel/git/legion/kbd.git/commit/?id=db82eb6f86e6c0b8ac4260e88b88d66e1cd7c077 Sorry for delay. You can use the mirror: https://github.com/legionus/kbd/commit/db82eb6f86e6c0b8ac4260e88b88d66e1cd7c077 > i get over it, but if i follow your link i get in an endless loop > that tries and restarts and tries and restarts. Some lwn.net > article link i followed (on git and rust, led to still running > FreeBSD bikeshed "Re: Git haas gone wild (Rust), freebsd-update" > thread on freebsd-hackers@) always ends up as "Noes!" or > something. Just in case .. (Luckily with lynx(1) direct access > is possible without that script mess.) > > So anyway the commit message of yours is not right ;) Well, the message reflects my understanding of the situation. Perhaps I am wrong. >, and, do you > know people of coreutils, or is this worth a bug report? No, I don't know anyone from coreutils. But perhaps they should be informed about this behavior. -- Rgrds, legion