GNU bug report logs -
#53534
28.0.91; on netbsd 'gmake install' outputs 'find: chown: No such file or directory'
Previous Next
To reply to this bug, email your comments to 53534 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
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):
[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):
> 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):
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: 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):
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):
> 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):
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):
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):
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):
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: 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):
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):
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: 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: 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 338 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.