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

[Alexey Gladkov <legion@kernel.org>]

On Wed, Sep 10, 2025 at 02:37:24PM +0200, Steffen Nurpmeso wrote:
> Alexey Gladkov wrote in
>  <aMFMHp57qTVOKSUv@example.org>:
>  |On Tue, Sep 09, 2025 at 11:18:18PM +0200, Steffen Nurpmeso wrote:
>  |> 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/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 <sys/types.h>
>              #include <unistd.h>
>              #include <pwd.h>
>              #include <grp.h>
>   #include <errno.h>
>   #include <string.h>
>   #include <stdio.h>
>   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