Re: kbd 2.9.0: build error (under fakeroot(1) environment)
Alexey Gladkov <[email protected]> Fri, 19 Sep 2025 17:16:39 +0200
| Newsgroups | dev.linux.lists.kbd |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Sep 10, 2025 at 02:37:24PM +0200, Steffen Nurpmeso wrote: > Alexey Gladkov wrote in > <[email protected]>: > |On Tue, Sep 09, 2025 at 11:18:18PM +0200, Steffen Nurpmeso wrote: > |> 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/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