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

Steffen Nurpmeso <[email protected]>
Newsgroups gmane.comp.gnu.core-utils.bugs
Message-ID <20250922231015.Cg_cr7vP@steffen%sdaoden.eu>
Paul Eggert wrote in
 <[email protected]>:
 |On 2025-09-22 09:21, Steffen Nurpmeso wrote:
 |> By the way, was this bug ever reported to OpenBSD?
 |
 |I don't know.
 |
 |I've not had good luck reporting OpenBSD bugs and gave up trying to do 
 |that decades ago. As I recall, Theo criticized me for reporting bugs 
 |without also supplying patches. A tough crowd, eh?

Well .. i am not a kernel hacker, but i see their dovutimens()
(in sys/kern/vfs_syscalls.c) does

                error = VOP_SETATTR(vp, &vattr, p->p_ucred, p);
        vput(vp);

and their chown series (multiple) does

                error = VOP_SETATTR(vp, &vattr, p->p_ucred, p);

.. me and kernel .. however, in their UFS filesystem for example
ufs_chown() does

  if (ouid != uid || ogid != gid)
    ip->i_flag |= IN_CHANGE;

and this causes ufs_itimes() later to update ctime.
Looks like the condition is not right, or, at least, not according
to POSIX which says

  Upon successful completion, chown( ) shall mark for update the
  last file status change timestamp of the file, except that if
  owner is (uid_t)−1 and group is (gid_t)−1, the file status
  change timestamp need not be marked for update.

It is however kernel and macros and very complex, so...
I'll forward that one too, Bcc: was explicitly disallowed.

And yes, legendary "attitude", available for example as
a fortune(1) file for the Plan9 successor 9front:

  https://git.9front.org/plan9front/plan9front/64f1977d15c91ceb2babab9348b052665c9a277c/lib/theo/f.html

And it contains

  We'll be waiting for your fix then.

 --End of <[email protected]>

--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)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.