Re: kbd 2.9.0: build error (under fakeroot(1) environment)

On Tue, Sep 09, 2025 at 11:18:18PM +0200, Steffen Nurpmeso wrote:
> Hello.
> 
> Alexey Gladkov wrote in
>  <[email protected]>:
>  |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 <[email protected]>
> 
> 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