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 3DB4331355B for ; Wed, 10 Sep 2025 10:00:04 +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=1757498405; cv=none; b=XkG/u1S8QXL16FBI2crzNuFGd9xgiiZXV08m+MmQ71+kIFy/oozRdUwT0RGeVWC4uR3+cKpNecOB7jYSMWI9JddP3w9X998wmTL1xhzkXY2z2Mx4kOldtdKSIPYSnZd5AAGZPim4dJrsJrlSSfB8GdSK8T0QB9xGFBvmY9DPd3g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1757498405; c=relaxed/simple; bh=bW+rBCnhH5Py52y/zoKpTvD0Fi4FHeUwUO4e6SkP6ac=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=E/kJXzF2w+3juCJ8taSiZGAyAY54B0VJh8+8vjpQU9/cMoZMyq99pUPwEPiUq/pIsA1e4YGlK3qiYrvhiFYFSNTchjDpi0EcMLwnVW3O3bU9hO4h8g6+NjFuxdamncV0Q3lYqo1xJtBHQUYCAHqodj4y4PzQK1ofriNRsCytRDE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=e/Ae57sw; 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="e/Ae57sw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15FAFC4CEF8; Wed, 10 Sep 2025 10:00:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1757498404; bh=bW+rBCnhH5Py52y/zoKpTvD0Fi4FHeUwUO4e6SkP6ac=; h=Date:From:To:Subject:References:In-Reply-To:From; b=e/Ae57swg/l+/td6odMJlvkukkZM50fHh491xXqIL7W5ZALlTxjET8miTl799We9N n5FoJDPoPqEz+P5mkEkwL60brJmQzRYe6ETmkBBk3bufp/V6rgtJrV70/52HbkZmdN X3iWVFlZnXtBsq28Rrihk/74i+3oyGyaK7qT6yvCvJVJOCipFcttLAYuyJcBMQU9n7 ToF4VfDN5k0ygypDvpJKcfIvmQwH0maN5Tyc+V+nOmf/4gc15T+NFpH7tvJp9ed9Ua OkBfkh27M4IImyechi7FXMb2tyWnc5D5tOyCIRTQ2EnzHJUsiblGQk6otZt1PIdEWc L4GshxQ2Rkx+g== Date: Wed, 10 Sep 2025 11:59:58 +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> 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: <20250909211818.pSB8ayld@steffen%sdaoden.eu> On Tue, Sep 09, 2025 at 11:18:18PM +0200, Steffen Nurpmeso wrote: > Hello. > > 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/keym\ > |> 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 > |> Problem is also that the build system uses "set -e", and cp(1) will exit > |> error no matter what (-f etc) after the above. > |> > |> From my superficial BSD-style-simple-filesystem-usage point of > |> view symbolic links have no attributes to preserve, but that > |> sounds dick. Maybe it is a GNU coreutils cp(1) "exaggeration" to > |> say and fail for the above for a symbolic link, as it seems to be > |> only about ownership, not whatever attribute or security context, > |> however, still. > | > |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/commit/?id=db82eb6f86e6c0b8ac4260e88b88d66e1cd7c077 > The CRUX team said (especially first note, yet they not have > committed that yet) [1] > > 16:38 Regarding stenur's failed build of kbd 2.9.0 > (presumably using fakeroot rather than building as the real > root), it should be enough to insert this line just before > `make`: sed -i "s/cp -ar/cp -r/; s/cp -a/cp /" data/Makefile > > 16:49 cp(1) is notable for its brevity, saying little > about what the default action regarding symlinks will be, in the > absence of an explicit flag like --no-dereference. In my tests, > however, dropping the -a flag had no ill effects, and the > resulting package kbd#2.9.0-1.pkg.tar.gz had the expected > footprint. > > 20:36 cp(1p) goes into much more detail, but even the > POSIX programmer's manual offers less than definitive guidance > about what should be done for symbolic links. "If the -R option > was specified ... [and] none of the options -H, -L, nor -P were > specified, it is unspecified which of -H, -L, or -P will be used > as a default." > > 20:40 Notably absent in the POSIX programmer's > man-page is any indication that cp should behave differently > depending on $UID. So there should be no need to safeguard the > sed command on kbd-2.9.0/data/Makefile behind a test of $UID > = 0, the resulting package will have the correct footprint > regardless of whether fakeroot or real root was used for the > build. > > [1] https://libera.catirclogs.org/crux/2025-09-06# > > |> In data/Makefile.* a lot of work is done after these "cp -a"s, > |> i wonder why beyond $(IGNORE_KEYMAPS) anything that is a symbolic > |> link is not "simply" $(LN_S)d after $(DESTDIR) has been populated, > |> as it is cd(1) entered for work anyway? Ie, some kind of > |> $(SYMLINK_KEYMAPS) or something. > | > |I didn't understand your point. > | > |Among the keymaps, there are symlinks to change the keymap name. > |Previously, when compressing keymaps, symlinks were dereferenced and > |a copy of the keymap appeared instead of the symlink. > > Understandable you want to save that redundancy. > > |I don't want to create symlinks in Makefile at the time of install. This > |is really hard to maintain. > > I understand. > cp -dPr works here, the -p of tar(1) is not with busybox for > example, so > > (cd test; tar -cf - .) | (mkdir t2; cd t2; tar -xf -) > > is not portable, and otherwise a more expensive find(1) iteration > is all that comes to my mind immediately. But since cp -dPr > works, it seems overkill. > > --End of > > Ciao! > > --steffen > | > |Der Kragenbaer, The moon bear, > |der holt sich munter he cheerfully and one by one > |einen nach dem anderen runter wa.ks himself off > |(By Robert Gernhardt) > -- Rgrds, legion