From: Alexey Gladkov <legion@kernel.org>
To: kbd@lists.linux.dev, Steffen Nurpmeso <steffen@sdaoden.eu>
Subject: Re: kbd 2.9.0: build error (under fakeroot(1) environment)
Date: Wed, 10 Sep 2025 11:59:58 +0200 [thread overview]
Message-ID: <aMFMHp57qTVOKSUv@example.org> (raw)
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
> <aMBGmTfQO-ukr9GP@example.org>:
> |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 <farkuhar> 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 <farkuhar> 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 <farkuhar> 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 <farkuhar> 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 <aMBGmTfQO-ukr9GP@example.org>
>
> 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
next prev parent reply other threads:[~2025-09-10 10:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-09 13:45 kbd 2.9.0: build error (under fakeroot(1) environment) Steffen Nurpmeso
2025-09-09 15:24 ` Alexey Gladkov
2025-09-09 21:18 ` Steffen Nurpmeso
2025-09-10 9:59 ` Alexey Gladkov [this message]
2025-09-10 12:37 ` Steffen Nurpmeso
2025-09-19 15:16 ` Alexey Gladkov
2025-09-20 15:57 ` Steffen Nurpmeso
2025-09-20 16:22 ` bug#79433: " Paul Eggert
2025-09-20 20:43 ` Steffen Nurpmeso
2025-09-21 16:57 ` Paul Eggert
2025-09-22 16:21 ` Steffen Nurpmeso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aMFMHp57qTVOKSUv@example.org \
--to=legion@kernel.org \
--cc=kbd@lists.linux.dev \
--cc=steffen@sdaoden.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.