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

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

[Steffen Nurpmeso]

Hello.

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/keymaps/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.  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.

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.

Thank you!!
And Ciao! from Germany,

--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)

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

[Alexey Gladkov]

On Tue, Sep 09, 2025 at 03:45:33PM +0200, Steffen Nurpmeso wrote:
> Hello.
> 
> 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/keymaps/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.

> 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.
 
> 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.

I don't want to create symlinks in Makefile at the time of install. This
is really hard to maintain.

> 
> Thank you!!
> And Ciao! from Germany,
> 
> --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

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

[Steffen Nurpmeso]

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

 |> 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.
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)

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

[Alexey Gladkov]

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

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

[Steffen Nurpmeso]

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

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 ;), and, do you
know people of coreutils, or is this worth a bug report?

  ...

Ciao -- and thanks for the fast fix!

--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)

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

[Alexey Gladkov]

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

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

[Steffen Nurpmeso]

Hello Alexey!

Alexey Gladkov wrote in
 <aM1z1wErMKbNTAZP@example.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:
 ...
 |>|No. This is security settings on your system.
 |>|
 |>|On my laptop:
 ...
 |> This is really strange; i have no "security setting", actually,
 ...
 |> 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!
 ...
 |Sorry for delay. You can use the mirror:
 |
 |https://github.com/legionus/kbd/commit/db82eb6f86e6c0b8ac4260e88b88d66e1\
 |cd7c077

Ah oh thanks thanks, i was happy with the normal git view.  -dPR
is ok!

  ...
 |> So anyway the commit message of yours is not right ;)
 |
 |Well, the message reflects my understanding of the situation.
 |Perhaps I am wrong.

Sorry to not come back to you after the smoke cleared...

 |>, 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.

So it is a multifold bug in coreutils for sure:

- they check for a "CHOWN_CHANGE_TIME_BUG" in their autoconf
  thing, which seems to derive from some OpenBSD behaviour
  according to source file comments (i have not looked at git
  history).

- The according check is flaky as it uses sleep(1) in between
  stat / chown+stat calls, without potential to specify
  a different sleep time that <small>could</small> be necessary.
  But regardless that..

- Since fakeroot fails the chown(), but ignores the EPERM error,
  the file's timestamp is not updated, causing the autoconf test
  to fail thus, causing above mentioned _BUG flag to be set.

- The fallback implementation that is then chosen is in my
  opinion broken as it says

        so we are required to update ctime.  Since lchown succeeded,
        we assume that lchmod will do likewise.  But if the system
        lacks lchmod and lutimes, we are out of luck.  Oh well.  */

  and it then simply uses the return value of l?chmod()
  (whatever *that* implementation actually is).

  I think it is broken because the actual chown(), which is what
  the operation is about, has succeeded.

  Due to filesystems like NFS or fuse-based network filesystems
  the implementation is inherently racy.

  I proposed to simply ignore the result of the chmod() that is
  used to cause a change time update -- it should be a best-effort
  approach instead:

  -      result = lchmod (file, st.st_mode & (S_IRWXU | S_IRWXG | S_IRWXO
  +      /*result =*/ lchmod (file, st.st_mode & (S_IRWXU | S_IRWXG | S_IRWXO
                                            | S_ISUID | S_ISGID | S_ISVTX));

  (Maybe i in person would even solely use utimes, as i *think* in
  the code path there is a current stat buffer available anyway.)

- Given it seems i have problems with Paul Eggert, for example

   |> (Just wondering, the final cp(1) should work for all
   |> configurable cases if config succeeds;
   |
   |That sounds pretty ambitious! The main goal here is merely for coreutils
   |to work on practical platforms.

  i cannot imagine coreutils gets a fix, however.
  I could be mistaken.

- I proposed to the fakeroot maintainer, whom i place in Bcc,
  a granted a little bit fragile change that would cause a change
  time update, in that if a stat buffer is known to fakeroot, and
  the file belongs the user who runs fakeroot, but the desire is
  to make it owned by root:root, .. you know.  Let the running
  user do with the file what the coreutils fallback does above
  (fakeroot yet no utimens at all, so configure mess ahead
  otherwise) in the EPERM case (that fakeroot ignores otherwise).
  (I think "raciness" and fakeroot do not go together at all,
  anyway.)

  (To me changing the fakeroot approach would be a real problem
  since the build system of my Linux distribution only uses
  a build() function to configure, build and install a package.
  The approach works for about five years, which likely means
  thousands of updates of hundreds of packages, without
  a problem.)

Thanks again for your quick kbd fix!!!

Ciao, and greetings from Germany (Hasta la Victoria siempre!)

--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)

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

[Paul Eggert]

On 2025-09-20 08:57, Steffen Nurpmeso wrote:
> - Given it seems i have problems with Paul Eggert, for example

That wording could be interpreted differently from what you intended. :-)

Anyway, I'm looking into a Gnulib workaround for the fakeroot bug - and 
it is a bug, in that fakeroot chown does not conform to POSIX here. That 
should fix coreutils as well. It's not a bug in coreutils itself.

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

[Steffen Nurpmeso]

Paul Eggert wrote in
 <314bfbd3-e56a-4840-82fc-e3d2188e6654@cs.ucla.edu>:
 |On 2025-09-20 08:57, Steffen Nurpmeso wrote:
 |> - Given it seems i have problems with Paul Eggert, for example
 |
 |That wording could be interpreted differently from what you intended. :-)

I thus better come to the conclusion that i do not have a problem
with Paul Eggert.

 |Anyway, I'm looking into a Gnulib workaround for the fakeroot bug - and 
 |it is a bug, in that fakeroot chown does not conform to POSIX here. That 
 |should fix coreutils as well. It's not a bug in coreutils itself.

Thank you!

 --End of <314bfbd3-e56a-4840-82fc-e3d2188e6654@cs.ucla.edu>

And a nice Sunday i wish everybody, if at all possible,
Ciao from Germany,

--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)

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

[Paul Eggert]

On 2025-09-20 13:43, Steffen Nurpmeso wrote:
>   |Anyway, I'm looking into a Gnulib workaround for the fakeroot bug - and
>   |it is a bug, in that fakeroot chown does not conform to POSIX here. That
>   |should fix coreutils as well. It's not a bug in coreutils itself.
> 
> Thank you!

I pushed what I hope is a workaround for the fakeroot bug into Gnulib, here:

https://cgit.git.savannah.gnu.org/cgit/gnulib.git/commit/?id=162ce0b783ba837e5e690a5bde812341853e109b
https://cgit.git.savannah.gnu.org/cgit/gnulib.git/commit/?id=12171837a9f94971bb0c91de193543145ef68e65

These patches also fix unlikely security races in OpenBSD.

Fixes along these lines should appear in a future coreutils release. 
It's not clear whether this will be the next release (which is due 
shortly), but at least by the release after that.

You should be able to test the fix now by doing something along these 
lines (but it may take a while):

git clone https://git.savannah.gnu.org/git/coreutils.git
cd coreutils
./bootstrap
git checkout -b testbranch
git submodule foreach git pull origin master
git commit -m 'build: update gnulib submodule to latest' gnulib
./bootstrap --skip-po
./configure
make check

Closing the coreutils bug report.

PS. Any word on fixes for the actual bug here? The bug that's in 
fakeroot *ch(mod|own)* emulation?

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

[Steffen Nurpmeso]

Paul Eggert wrote in
 <0a091808-7434-4f87-b387-36ae93d1244c@cs.ucla.edu>:
 |On 2025-09-20 13:43, Steffen Nurpmeso wrote:
 |>|Anyway, I'm looking into a Gnulib workaround for the fakeroot bug - and
 |>|it is a bug, in that fakeroot chown does not conform to POSIX here. That
 |>|should fix coreutils as well. It's not a bug in coreutils itself.
 |> 
 |> Thank you!
 |
 |I pushed what I hope is a workaround for the fakeroot bug into Gnulib, \
 |here:
 |
 |https://cgit.git.savannah.gnu.org/cgit/gnulib.git/commit/?id=162ce0b783b\
 |a837e5e690a5bde812341853e109b

That is great!  Yes.

 |https://cgit.git.savannah.gnu.org/cgit/gnulib.git/commit/?id=12171837a9f\
 |94971bb0c91de193543145ef68e65
 |
 |These patches also fix unlikely security races in OpenBSD.
 |
 |Fixes along these lines should appear in a future coreutils release. 
 |It's not clear whether this will be the next release (which is due 
 |shortly), but at least by the release after that.
 |
 |You should be able to test the fix now by doing something along these 
 |lines (but it may take a while):
 |
 |git clone https://git.savannah.gnu.org/git/coreutils.git
 |cd coreutils
 |./bootstrap
 |git checkout -b testbranch
 |git submodule foreach git pull origin master
 |git commit -m 'build: update gnulib submodule to latest' gnulib
 |./bootstrap --skip-po
 |./configure
 |make check
 |
 |Closing the coreutils bug report.
 |
 |PS. Any word on fixes for the actual bug here? The bug that's in 
 |fakeroot *ch(mod|own)* emulation?

I had Bcc'd him several times (maybe too often even), and now
place him in Cc.  I have heard nothing back until now; i think the
"if user owns, and chowns to root, and EPERM happens, updating
timestamp" would not be too fragile; it, however, is only
a guess whether it would succeed without fakeroot, so...

By the way, was this bug ever reported to OpenBSD?
I do not see anything alike in since 2013?
  https://marc.info/?l=openbsd-bug
I Bcc: bugs@openbsd.org and ensure it gets posted (somehow), maybe
just a miss that chown() does not update the file change time.

 --End of <0a091808-7434-4f87-b387-36ae93d1244c@cs.ucla.edu>

Thank you!

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)