GNU bug report logs - #53534
28.0.91; on netbsd 'gmake install' outputs 'find: chown: No such file or directory'

Previous Next

Package: emacs;

Reported by: Van Ly <van.ly <at> sdf.org>

Date: Tue, 25 Jan 2022 23:05:01 UTC

Severity: normal

Found in version 28.0.91

To reply to this bug, email your comments to 53534 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#53534; Package emacs. (Tue, 25 Jan 2022 23:05:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Van Ly <van.ly <at> sdf.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 25 Jan 2022 23:05:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.91; on netbsd 'gmake install' outputs 'find: chown: No such
 file or directory'
Date: Tue, 25 Jan 2022 23:03:51 +0000 (UTC)
[Message part 1 (text/plain, inline)]
Hello,

Running the command 'gmake install' as normal user on netbsd, there 
are many of these lines

> find: chown: No such file or directory

See line spans in gmake-install--find-chown-messages.text

* line span 1160 - 2112
* line span 5244 - 8339

Running the command 'gmake install' as root user does not produce 
those lines.

-- 
vl
[bug-gnu-emacs-28.0.91--netbsd-amd64.text (text/plain, attachment)]
[gmake-install--find-chown-messages.text (text/plain, attachment)]
[gmake-install--root-user.text (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53534; Package emacs. (Wed, 26 Jan 2022 03:34:01 GMT) Full text and rfc822 format available.

Message #8 received at 53534 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Van Ly <van.ly <at> sdf.org>
Cc: 53534 <at> debbugs.gnu.org
Subject: Re: bug#53534: 28.0.91;
 on netbsd 'gmake install' outputs 'find: chown: No such file or
 directory'
Date: Wed, 26 Jan 2022 05:32:55 +0200
> Date: Tue, 25 Jan 2022 23:03:51 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> 
> Running the command 'gmake install' as normal user on netbsd, there 
> are many of these lines
> 
> > find: chown: No such file or directory
> 
> See line spans in gmake-install--find-chown-messages.text
> 
> * line span 1160 - 2112
> * line span 5244 - 8339
> 
> Running the command 'gmake install' as root user does not produce 
> those lines.

Users on NetBSD cannot invoke the 'chown' command?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53534; Package emacs. (Wed, 26 Jan 2022 04:27:01 GMT) Full text and rfc822 format available.

Message #11 received at 53534 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Van Ly <van.ly <at> sdf.org>, 53534 <at> debbugs.gnu.org
Subject: Re: bug#53534: 28.0.91;
 on netbsd 'gmake install' outputs 'find: chown: No such file or
 directory'
Date: Tue, 25 Jan 2022 23:26:36 -0500
Eli Zaretskii wrote:

> Users on NetBSD cannot invoke the 'chown' command?

Presumably it is not in the default PATH of non-root users;
eg perhaps it is /sbin/chown.

On GNU/Linux, non-root users normally cannot chown things (to other
users).

It's not obvious to me that these venerable chowns in the Makefile are
useful.

Apart from them being no-ops for non-root installs (apart from possible
group changes), LOGNAME (which is the first choice for setting
$installuser) has different values in `su` and `su -`. So the ownership
of the emacs installation will vary according to how su was invoked.

I guess they are to deal with tar defaulting to --same-owner for root.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53534; Package emacs. (Wed, 26 Jan 2022 12:49:02 GMT) Full text and rfc822 format available.

Message #14 received at 53534 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: van.ly <at> sdf.org, 53534 <at> debbugs.gnu.org
Subject: Re: bug#53534: 28.0.91;
 on netbsd 'gmake install' outputs 'find: chown: No such file or
 directory'
Date: Wed, 26 Jan 2022 14:47:47 +0200
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Van Ly <van.ly <at> sdf.org>,  53534 <at> debbugs.gnu.org
> Date: Tue, 25 Jan 2022 23:26:36 -0500
> 
> Eli Zaretskii wrote:
> 
> > Users on NetBSD cannot invoke the 'chown' command?
> 
> Presumably it is not in the default PATH of non-root users;
> eg perhaps it is /sbin/chown.
> 
> On GNU/Linux, non-root users normally cannot chown things (to other
> users).

Isn't it customary to use sudo when installing stuff?

> I guess they are to deal with tar defaulting to --same-owner for root.

Most probably.

In any case, I don't see any serious problem in the reported behavior,
those are just warnings AFAIU.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53534; Package emacs. (Wed, 26 Jan 2022 15:07:02 GMT) Full text and rfc822 format available.

Message #17 received at 53534 <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 53534 <at> debbugs.gnu.org
Subject: Re: bug#53534: 28.0.91; on netbsd 'gmake install' outputs 'find:
 chown: No such file or directory'
Date: Wed, 26 Jan 2022 15:06:18 +0000 (UTC)
On Wed, 26 Jan 2022, Eli Zaretskii wrote:

>
> Isn't it customary to use sudo when installing stuff?
>

Taking GNU Screen as an example, the settings for the system go in 
/etc/screenrc, which would need chown to install in the first place, 
the user can install their settings in ~/.screenrc, without use of 
chown.

>> I guess they are to deal with tar defaulting to --same-owner for root.
>
> Most probably.
>
> In any case, I don't see any serious problem in the reported behavior,
> those are just warnings AFAIU.
>

I hesistated before reporting this bug, thinking my storage device 
had wornout and was spewing the error.  I got around to fscking then 
reported this.  A better looking log trace collapses and counts the 
repeating line and explains chown is not on the path is a help to 
know.  The autogen.sh script can detect chown is not on the path, 
right?

-- 
vl





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53534; Package emacs. (Wed, 26 Jan 2022 15:15:02 GMT) Full text and rfc822 format available.

Message #20 received at 53534 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Van Ly <van.ly <at> sdf.org>
Cc: rgm <at> gnu.org, 53534 <at> debbugs.gnu.org
Subject: Re: bug#53534: 28.0.91; on netbsd 'gmake install' outputs 'find:
 chown: No such file or directory'
Date: Wed, 26 Jan 2022 17:14:37 +0200
> Date: Wed, 26 Jan 2022 15:06:18 +0000 (UTC)
> From: Van Ly <van.ly <at> sdf.org>
> cc: Glenn Morris <rgm <at> gnu.org>, 53534 <at> debbugs.gnu.org
> 
> > In any case, I don't see any serious problem in the reported behavior,
> > those are just warnings AFAIU.
> >
> 
> I hesistated before reporting this bug, thinking my storage device 
> had wornout and was spewing the error.  I got around to fscking then 
> reported this.  A better looking log trace collapses and counts the 
> repeating line and explains chown is not on the path is a help to 
> know.  The autogen.sh script can detect chown is not on the path, 
> right?

That won't help, because AFAIU when you use sudo, it changes your PATH
accordingly.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53534; Package emacs. (Wed, 26 Jan 2022 17:53:02 GMT) Full text and rfc822 format available.

Message #23 received at 53534 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Van Ly <van.ly <at> sdf.org>, 53534 <at> debbugs.gnu.org
Subject: Re: bug#53534: 28.0.91;
 on netbsd 'gmake install' outputs 'find: chown: No such file or
 directory'
Date: Wed, 26 Jan 2022 12:51:51 -0500
Eli Zaretskii wrote:

> That won't help, because AFAIU when you use sudo, it changes your PATH
> accordingly.

It might, or it might not. It depends on how sudo is configured.

Alternative suggestions for fixing the various issues that exist here:

1) Don't use tar.
2) Use tar --no-same-owner (if tar doesn't have this option, then it
won't have the issue that chown seeks to fix).
3) Only run chown if UID = 0, and use chown root:root rather than the
current installuser logic, which seems broken (I notice now that most of
my emacs installations in /usr/local/share are owned by my user account
instead of root).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53534; Package emacs. (Wed, 26 Jan 2022 18:03:01 GMT) Full text and rfc822 format available.

Message #26 received at 53534 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Van Ly <van.ly <at> sdf.org>, 53534 <at> debbugs.gnu.org
Subject: Re: bug#53534: 28.0.91;
 on netbsd 'gmake install' outputs 'find: chown: No such file or
 directory'
Date: Wed, 26 Jan 2022 13:02:19 -0500
Glenn Morris wrote:

> 3) Only run chown if UID = 0, and use chown root:root rather than the
> current installuser logic, which seems broken (I notice now that most of
> my emacs installations in /usr/local/share are owned by my user account
> instead of root).

PS Also, prepend /usr/sbin:/sbin to PATH when running chown.
The whole tar+chown business seems rather ugly.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53534; Package emacs. (Wed, 26 Jan 2022 18:05:02 GMT) Full text and rfc822 format available.

Message #29 received at 53534 <at> debbugs.gnu.org (full text, mbox):

From: Van Ly <van.ly <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, 53534 <at> debbugs.gnu.org
Subject: Re: bug#53534: 28.0.91; on netbsd 'gmake install' outputs 'find:
 chown: No such file or directory'
Date: Wed, 26 Jan 2022 18:04:51 +0000 (UTC)
On Wed, 26 Jan 2022, Eli Zaretskii wrote:

>
> That won't help, because AFAIU when you use sudo, it changes your PATH
> accordingly.
>

I went from normal user to

* doas
* su -

The netbsd I have uses doas in place of sudo, and doas failed to 
proceed given 'gmake install'.  What if chown is used only 
when the following options are given to configure?

* --installuser
* --installgroup

-- 
vl





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53534; Package emacs. (Thu, 27 Jan 2022 02:24:01 GMT) Full text and rfc822 format available.

Message #32 received at 53534 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Van Ly <van.ly <at> sdf.org>, 53534 <at> debbugs.gnu.org
Subject: Re: bug#53534: 28.0.91;
 on netbsd 'gmake install' outputs 'find: chown: No such file or
 directory'
Date: Wed, 26 Jan 2022 21:22:54 -0500
Here's a patch to use cp -R in preference to tar+chown+chmod.


--- i/Makefile.in
+++ w/Makefile.in
@@ -576,6 +576,12 @@ INSTALL_ARCH_INDEP_EXTRA = @INSTALL_ARCH_INDEP_EXTRA@
 
 ## https://lists.gnu.org/r/emacs-devel/2007-10/msg01672.html
 ## Needs to be the user running install, so configure can't set it.
+## This is only used if we use tar to copy rather than cp -R.
+## I think it is buggy, eg if you 'su' to root LOGNAME etc do not change,
+## whereas if you 'su -' they do.  Since the need to run chown only
+## occurs for root, it would probably be better to only chown if UID
+## is 0, and just chown to root.  But the entire tar branch is
+## obsolete and unlikely to be used in practice.
 set_installuser=for installuser in $${LOGNAME} $${USERNAME} $${USER} \
 	  `(id -u) 2> /dev/null`; do \
 	  [ -n "$${installuser}" ] && break ; \
@@ -613,12 +619,15 @@ set_installuser=for installuser in $${LOGNAME} $${USERNAME} $${USER} \
 ## but not add subdirs.el to them.  This was a strange halfway house.
 ## Nowadays we do not create non-default directories.
 
-## Note that we use tar instead of plain old cp -R/-r because the latter
-## is apparently not portable (even in 2012!).
+## Historically this used tar, possibly due to portability concerns with cp -R.
+## Using tar introduces issues with ownership and permission when run as root.
+## Hence the chowns and chmods, the latter because "umask 022; tar
+## ..." is not guaranteed to do the right thing if we are root and tar
+## is preserving source permissions.
+##
+## It seems highly likely that cp -R works on all relevant platforms,
+## so in 2022 the tar fallback is probably unnecessary.  Refs:
 ## https://lists.gnu.org/r/emacs-devel/2012-05/msg00278.html
-## I have no idea which platforms Emacs supports where cp -R does not
-## work correctly, and therefore no idea when tar can be replaced.
-## See also these comments from 2004 about cp -r working fine:
 ## https://lists.gnu.org/r/autoconf-patches/2004-11/msg00005.html
 install-arch-indep: lisp install-info install-man ${INSTALL_ARCH_INDEP_EXTRA}
 	umask 022 && $(MKDIR_P) "$(DESTDIR)$(includedir)"
@@ -637,9 +646,14 @@ install-arch-indep: lisp install-info install-man ${INSTALL_ARCH_INDEP_EXTRA}
 	  rm -rf "$${dest}" ; \
 	  umask 022; ${MKDIR_P} "$${dest}" ; \
 	  printf 'Copying %s to %s...\n' "$$dir" "$$dest" ; \
-	  (cd $${dir}; tar -chf - . ) \
-	    | (cd "$${dest}"; umask 022; \
-	       tar -xvf - && cat > /dev/null) || exit 1; \
+	  dotar= ; \
+	  destbase=`echo "$${dest}" | sed 's,/[^/]*$$,,'`; \
+	  if ! cp -R "$$dir" "$$destbase"; then \
+	    dotar=t; \
+	    (cd $${dir}; tar -chf - . ) \
+	      | (cd "$${dest}"; umask 022; \
+	         tar -xvf - && cat > /dev/null) || exit 1; \
+	  fi; \
 	  if [ "$${dir}" = "${srcdir}/etc" ]; then \
 	      rm -f "$${dest}/DOC"* ; \
 	      rm -f "$${dest}/refcards"/*.aux "$${dest}/refcards"/*.dvi; \
@@ -648,7 +662,7 @@ install-arch-indep: lisp install-info install-man ${INSTALL_ARCH_INDEP_EXTRA}
 	  fi; \
 	  (cd "$${dest}" || exit 1; \
 	    for subdir in `find . -type d -print` ; do \
-	      chmod a+rx $${subdir} ; \
+	      [ -z "$$dotar" ] || chmod a+rx $${subdir} ; \
 	      rm -f $${subdir}/.gitignore ; \
 	      rm -f $${subdir}/.arch-inventory ; \
 	      rm -f $${subdir}/.DS_Store ; \
@@ -660,7 +674,8 @@ install-arch-indep: lisp install-info install-man ${INSTALL_ARCH_INDEP_EXTRA}
 	      [ "$${dir}" != "${srcdir}/etc" ] && \
 	        rm -f $${subdir}/[mM]akefile*[.-]in $${subdir}/[mM]akefile ; \
 	    done ); \
-	  find "$${dest}" -exec chown $${installuser} {} ';' ;\
+	  [ -z "$$dotar" ] || \
+	    find "$${dest}" -exec chown $${installuser} {} ';' ;\
 	done
 	-rm -f "$(DESTDIR)${lispdir}/subdirs.el"
 	umask 022; $(srcdir)/build-aux/update-subdirs "$(DESTDIR)${lispdir}"
@@ -678,9 +693,7 @@ install-arch-indep: lisp install-info install-man ${INSTALL_ARCH_INDEP_EXTRA}
 	}
 	-chmod -R a+r "$(DESTDIR)${datadir}/emacs/${version}" ${COPYDESTS}
 
-## The above chmods are needed because "umask 022; tar ..." is not
-## guaranteed to do the right thing; eg if we are root and tar is
-## preserving source permissions.
+## Final chmod above is not needed if we did not use tar.
 
 ## Note that install-arch-indep deletes and recreates the entire
 ## installed etc/ directory, so we need it to run before this does.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53534; Package emacs. (Thu, 27 Jan 2022 07:13:01 GMT) Full text and rfc822 format available.

Message #35 received at 53534 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: van.ly <at> sdf.org, 53534 <at> debbugs.gnu.org
Subject: Re: bug#53534: 28.0.91;
 on netbsd 'gmake install' outputs 'find: chown: No such file or
 directory'
Date: Thu, 27 Jan 2022 09:12:01 +0200
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Van Ly <van.ly <at> sdf.org>,  53534 <at> debbugs.gnu.org
> Date: Wed, 26 Jan 2022 21:22:54 -0500
> 
> Here's a patch to use cp -R in preference to tar+chown+chmod.

Why "cp -R" and not ${INSTALL_DATA}, per conventions?

(Is the -R switch to cp even portable enough nowadays?  IMO we should
verify that, not just assume that since 10 years have passed, the
problem doesn't exist anymore.  The Autoconf manual still has some
caveats about using "cp -R", for example.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53534; Package emacs. (Wed, 02 Feb 2022 18:22:01 GMT) Full text and rfc822 format available.

Message #38 received at 53534 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: van.ly <at> sdf.org, 53534 <at> debbugs.gnu.org
Subject: Re: bug#53534: 28.0.91;
 on netbsd 'gmake install' outputs 'find: chown: No such file or
 directory'
Date: Wed, 02 Feb 2022 13:21:04 -0500
Eli Zaretskii wrote:

> Why "cp -R" and not ${INSTALL_DATA}, per conventions?

INSTALL_DATA doesn't recurse.

> (Is the -R switch to cp even portable enough nowadays? 

I believe it is, but in case it isn't, the patch continues to fall back
to tar.

> IMO we should verify that,

How do you propose to verify it?

> not just assume that since 10 years have passed, the problem doesn't
> exist anymore.

It's 14 years since cp -R was added to POSIX.
In 2022, I am ok with assuming that recursive copy is a solved problem.

> The Autoconf manual still has some caveats about using "cp -R", for
> example.)

What are the relevant caveats?
Literally the only possible one I can see is:

  "AIX 5.3 'cp -R' may corrupt its own memory with some directory
  hierarchies and error out or dump core"

Does Emacs support that platform? If it does and this issue happens, the
fall-back to tar will handle it.


I point out once again that the current code is buggy and leads to files
being installed with the wrong owner.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53534; Package emacs. (Wed, 02 Feb 2022 18:35:02 GMT) Full text and rfc822 format available.

Message #41 received at 53534 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: van.ly <at> sdf.org, 53534 <at> debbugs.gnu.org
Subject: Re: bug#53534: 28.0.91;
 on netbsd 'gmake install' outputs 'find: chown: No such file or
 directory'
Date: Wed, 02 Feb 2022 13:34:29 -0500
Actually, on second thought, just cp -R might not preserve the relative
ages of .el and .elc.

I hope someone will at least fix the tar implementation.
See eg suggestions 2 and 3 from https://debbugs.gnu.org/53534#23




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53534; Package emacs. (Wed, 02 Feb 2022 18:58:01 GMT) Full text and rfc822 format available.

Message #44 received at 53534 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: van.ly <at> sdf.org, 53534 <at> debbugs.gnu.org
Subject: Re: bug#53534: 28.0.91;
 on netbsd 'gmake install' outputs 'find: chown: No such file or
 directory'
Date: Wed, 02 Feb 2022 20:57:34 +0200
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: 53534 <at> debbugs.gnu.org,  van.ly <at> sdf.org
> Date: Wed, 02 Feb 2022 13:21:04 -0500
> 
> I point out once again that the current code is buggy and leads to files
> being installed with the wrong owner.

Only if the user installs it using the wrong procedure.  E.g., the
installed files don't have the wrong owner in my installations.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#53534; Package emacs. (Wed, 02 Feb 2022 19:23:01 GMT) Full text and rfc822 format available.

Message #47 received at 53534 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: van.ly <at> sdf.org, 53534 <at> debbugs.gnu.org
Subject: Re: bug#53534: 28.0.91;
 on netbsd 'gmake install' outputs 'find: chown: No such file or
 directory'
Date: Wed, 02 Feb 2022 21:22:42 +0200
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: 53534 <at> debbugs.gnu.org,  van.ly <at> sdf.org
> Date: Wed, 02 Feb 2022 13:34:29 -0500
> 
> See eg suggestions 2 and 3 from https://debbugs.gnu.org/53534#23

I don't mind doing both, but they will only help if "make install" is
run by root?  (Which is TRT, IMO, but it sounds like many people don't
do that nowadays.)




This bug report was last modified 2 years and 104 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.