GNU bug report logs - #17971
24.3.92; Patch to fix el compression on RHEL/CentOS 7

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17971 in the body.
You can then email your comments to 17971 AT debbugs.gnu.org in the normal way.

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

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

From: Stephen Hassard <steve <at> hassard.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Mon, 7 Jul 2014 22:05:02 -0700

[Message part 1 (text/plain, inline)]

Hi there,

The current alpha builds are failing during 'make install' while
performing the .elc compression on CentOS 7.

I've cleaned up the find command in the Makefile and have a patch that
fixes the problem while retaining function on Ubuntu/Debian. Please find
it attached.

Thanks,
Steve


In GNU Emacs 24.3.92.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2014-07-07 on gorgon
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description: Ubuntu 14.04 LTS

Configured using:
 `configure --prefix=/home/shassard/opt/emacs'

Important settings:
  value of $LANG: en_CA.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e <backspace> <backspace> e m <tab> a c s - r
e <tab> p <tab> <backspace> <backspace> <backspace>
b u <help-echo> <tab> g <tab> C-g C-g <help-echo> M-x
r p e o <tab> <backspace> <backspace> <backspace> e
p o <tab> r t <tab> <return>

Recent messages:
Wrote /home/shassard/.emacs.d/.cask/
24.3.92.2/bootstrap/package-build-20140706.955/package-build-pkg.elc
Checking /home/shassard/.emacs.d/.cask/
24.3.92.2/bootstrap/package-build-20140706.955...
Compiling /home/shassard/.emacs.d/.cask/
24.3.92.2/bootstrap/package-build-20140706.955/package-build.el...done
Wrote /home/shassard/.emacs.d/.cask/
24.3.92.2/bootstrap/package-build-20140706.955/package-build.elc
Checking /home/shassard/.emacs.d/.cask/
24.3.92.2/bootstrap/package-build-20140706.955...
Done (Total of 2 files compiled, 1 skipped)
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
Quit [2 times]
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail help-mode cask cask-bootstrap
package-build shut-up epl git commander easy-mmode edmacro kmacro json
rx cl-macs f cl-loaddefs cl-lib dash s gv warnings compile comint
ansi-color ring autoload lisp-mnt finder-inf mm-archive message
format-spec rfc822 mml easymenu mml-sec mailabbrev gmm-utils mailheader
mm-decode mm-bodies mm-encode mail-utils network-stream starttls
url-http tls mail-parse rfc2231 rfc2047 rfc2045 ietf-drums url-gw
url-cache url-auth url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util mailcap url-handlers
url-parse auth-source eieio byte-opt bytecomp byte-compile cconv
eieio-core gnus-util mm-util help-fns mail-prsvr password-cache url-vars
package time-date tooltip electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
gfilenotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 124994 39416)
 (symbols 48 25119 0)
 (miscs 40 97 226)
 (strings 32 29278 12603)
 (string-bytes 1 760605)
 (vectors 16 21219)
 (vector-slots 8 1203781 180334)
 (floats 8 80 348)
 (intervals 56 510 0)
 (buffers 960 16)
 (heap 1024 50698 1163))

[Message part 2 (text/html, inline)]

[0001-Fix-.el-compression-on-CentOS7.patch (text/x-patch, attachment)]

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

From: Glenn Morris <rgm <at> gnu.org>
To: Stephen Hassard <steve <at> hassard.net>
Cc: 17971 <at> debbugs.gnu.org
Subject: Re: bug#17971: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Tue, 08 Jul 2014 02:04:26 -0400

Stephen Hassard wrote:

> The current alpha builds are failing during 'make install' while
> performing the .elc compression on CentOS 7.

Please tell us how it fails.

> I've cleaned up the find command in the Makefile and have a patch that
> fixes the problem while retaining function on Ubuntu/Debian. Please find
> it attached.

Sadly I don't think -execdir is portable.

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

From: Stephen Hassard <steve <at> hassard.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 17971 <at> debbugs.gnu.org
Subject: Re: bug#17971: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Tue, 8 Jul 2014 08:50:52 -0700

[Message part 1 (text/plain, inline)]

Here's the relevant output from the 'make install' on CentOS 7:

----
[ -z "/usr/bin/gzip" ] || { \
  echo "Compressing *.el ..." && \
  cd "/home/shassard/opt/emacs/share/emacs/24.3.92/lisp" && \
  find . -name '*.elc' -exec /bin/sh -c \
    '/usr/bin/gzip -9n `expr "$1" : "\\(.*\\)c"`' dummy '{}' ';'; \
}
Compressing *.el ...
find: ‘./progmodes/make-mode.el’: No such file or directory
find: ‘./progmodes/m4-mode.el’: No such file or directory
find: ‘./progmodes/cc-fonts.el’: No such file or directory
find: ‘./progmodes/cc-engine.el’: No such file or directory
find: ‘./progmodes/idlw-complete-structtag.el’: No such file or directory
find: ‘./progmodes/meta-mode.el’: No such file or directory
find: ‘./progmodes/bat-mode.el’: No such file or directory
find: ‘./progmodes/gud.el’: No such file or directory
find: ‘./progmodes/simula.el’: No such file or directory
find: ‘./progmodes/autoconf.el’: No such file or directory
find: ‘./progmodes/prog-mode.el’: No such file or directory
----

make immediately fails after this point.

I've attached a revised patch that adds the -9n flag to the gzip command
and switch back to -exec for find.


On Mon, Jul 7, 2014 at 11:04 PM, Glenn Morris <rgm <at> gnu.org> wrote:

> Stephen Hassard wrote:
>
> > The current alpha builds are failing during 'make install' while
> > performing the .elc compression on CentOS 7.
>
> Please tell us how it fails.
>
> > I've cleaned up the find command in the Makefile and have a patch that
> > fixes the problem while retaining function on Ubuntu/Debian. Please find
> > it attached.
>
> Sadly I don't think -execdir is portable.
>

[Message part 2 (text/html, inline)]

[0001-Fix-.el-compression-on-CentOS-7.patch (text/x-diff, attachment)]

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

From: Glenn Morris <rgm <at> gnu.org>
To: Stephen Hassard <steve <at> hassard.net>
Cc: 17971 <at> debbugs.gnu.org
Subject: Re: bug#17971: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Tue, 08 Jul 2014 21:10:22 -0400

Stephen Hassard wrote:

> Here's the relevant output from the 'make install' on CentOS 7:
>
> ----
> [ -z "/usr/bin/gzip" ] || { \
>   echo "Compressing *.el ..." && \
>   cd "/home/shassard/opt/emacs/share/emacs/24.3.92/lisp" && \
>   find . -name '*.elc' -exec /bin/sh -c \
>     '/usr/bin/gzip -9n `expr "$1" : "\\(.*\\)c"`' dummy '{}' ';'; \
> }
> Compressing *.el ...
> find: './progmodes/make-mode.el': No such file or directory

Do you know why this happens?
What has changed since RHEL6, where it works fine?

> I've attached a revised patch that adds the -9n flag to the gzip command
> and switch back to -exec for find.

This fails if DESTDIR contains spaces.

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

From: Stephen Hassard <steve <at> hassard.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 17971 <at> debbugs.gnu.org
Subject: Re: bug#17971: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Tue, 8 Jul 2014 21:07:04 -0700

[Message part 1 (text/plain, inline)]

It's definitely a regression in CentOS7 vs 6.5. I've built a new 6.5 VM and
have confirmed that it compresses the .el files without problem.

It seems to be a regression in the bundled findutils. I've pulled in the
find binary from CentOS 6.5 onto my CentOS 7 VM and the 'make install'
process completed without problems with the old find.

The version are:

CentOS 7:
findutils-4.5.11-3

CentOS 6.5:
findutils-4.4.2-6




On Tue, Jul 8, 2014 at 6:10 PM, Glenn Morris <rgm <at> gnu.org> wrote:

> Stephen Hassard wrote:
>
> > Here's the relevant output from the 'make install' on CentOS 7:
> >
> > ----
> > [ -z "/usr/bin/gzip" ] || { \
> >   echo "Compressing *.el ..." && \
> >   cd "/home/shassard/opt/emacs/share/emacs/24.3.92/lisp" && \
> >   find . -name '*.elc' -exec /bin/sh -c \
> >     '/usr/bin/gzip -9n `expr "$1" : "\\(.*\\)c"`' dummy '{}' ';'; \
> > }
> > Compressing *.el ...
> > find: './progmodes/make-mode.el': No such file or directory
>
> Do you know why this happens?
> What has changed since RHEL6, where it works fine?
>
> > I've attached a revised patch that adds the -9n flag to the gzip command
> > and switch back to -exec for find.
>
> This fails if DESTDIR contains spaces.
>

[Message part 2 (text/html, inline)]

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

From: Stephen Hassard <steve <at> hassard.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 17971 <at> debbugs.gnu.org
Subject: Re: bug#17971: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Tue, 8 Jul 2014 21:16:50 -0700

[Message part 1 (text/plain, inline)]

For fun I built a copy of findutils-4.5.12 from alpha.gnu.org and found
that it's suffering the same regression as CentOS's bundled find.


On Tue, Jul 8, 2014 at 9:07 PM, Stephen Hassard <steve <at> hassard.net> wrote:

> It's definitely a regression in CentOS7 vs 6.5. I've built a new 6.5 VM
> and have confirmed that it compresses the .el files without problem.
>
> It seems to be a regression in the bundled findutils. I've pulled in the
> find binary from CentOS 6.5 onto my CentOS 7 VM and the 'make install'
> process completed without problems with the old find.
>
> The version are:
>
> CentOS 7:
> findutils-4.5.11-3
>
> CentOS 6.5:
> findutils-4.4.2-6
>
>
>
>
> On Tue, Jul 8, 2014 at 6:10 PM, Glenn Morris <rgm <at> gnu.org> wrote:
>
>> Stephen Hassard wrote:
>>
>> > Here's the relevant output from the 'make install' on CentOS 7:
>> >
>> > ----
>> > [ -z "/usr/bin/gzip" ] || { \
>> >   echo "Compressing *.el ..." && \
>> >   cd "/home/shassard/opt/emacs/share/emacs/24.3.92/lisp" && \
>> >   find . -name '*.elc' -exec /bin/sh -c \
>> >     '/usr/bin/gzip -9n `expr "$1" : "\\(.*\\)c"`' dummy '{}' ';'; \
>> > }
>> > Compressing *.el ...
>> > find: './progmodes/make-mode.el': No such file or directory
>>
>> Do you know why this happens?
>> What has changed since RHEL6, where it works fine?
>>
>> > I've attached a revised patch that adds the -9n flag to the gzip command
>> > and switch back to -exec for find.
>>
>> This fails if DESTDIR contains spaces.
>>
>
>

[Message part 2 (text/html, inline)]

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

From: Stephen Hassard <steve <at> hassard.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 17971 <at> debbugs.gnu.org
Subject: Re: bug#17971: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Wed, 9 Jul 2014 06:56:27 -0700

[Message part 1 (text/plain, inline)]

Here's another update to the patch that more closely follows the behaviour
of the original Makefile and now works with a prefix that includes a space.

This is tested and works with gnu findutils 4.5.11.


On Tue, Jul 8, 2014 at 9:16 PM, Stephen Hassard <steve <at> hassard.net> wrote:

> For fun I built a copy of findutils-4.5.12 from alpha.gnu.org and found
> that it's suffering the same regression as CentOS's bundled find.
>
>
> On Tue, Jul 8, 2014 at 9:07 PM, Stephen Hassard <steve <at> hassard.net> wrote:
>
>> It's definitely a regression in CentOS7 vs 6.5. I've built a new 6.5 VM
>> and have confirmed that it compresses the .el files without problem.
>>
>> It seems to be a regression in the bundled findutils. I've pulled in the
>> find binary from CentOS 6.5 onto my CentOS 7 VM and the 'make install'
>> process completed without problems with the old find.
>>
>> The version are:
>>
>> CentOS 7:
>> findutils-4.5.11-3
>>
>> CentOS 6.5:
>> findutils-4.4.2-6
>>
>>
>>
>>
>> On Tue, Jul 8, 2014 at 6:10 PM, Glenn Morris <rgm <at> gnu.org> wrote:
>>
>>> Stephen Hassard wrote:
>>>
>>> > Here's the relevant output from the 'make install' on CentOS 7:
>>> >
>>> > ----
>>> > [ -z "/usr/bin/gzip" ] || { \
>>> >   echo "Compressing *.el ..." && \
>>> >   cd "/home/shassard/opt/emacs/share/emacs/24.3.92/lisp" && \
>>> >   find . -name '*.elc' -exec /bin/sh -c \
>>> >     '/usr/bin/gzip -9n `expr "$1" : "\\(.*\\)c"`' dummy '{}' ';'; \
>>> > }
>>> > Compressing *.el ...
>>> > find: './progmodes/make-mode.el': No such file or directory
>>>
>>> Do you know why this happens?
>>> What has changed since RHEL6, where it works fine?
>>>
>>> > I've attached a revised patch that adds the -9n flag to the gzip
>>> command
>>> > and switch back to -exec for find.
>>>
>>> This fails if DESTDIR contains spaces.
>>>
>>
>>
>

[Message part 2 (text/html, inline)]

[0001-Fix-regression-in-findutils-4.5.patch (text/x-diff, attachment)]

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

From: Glenn Morris <rgm <at> gnu.org>
To: Stephen Hassard <steve <at> hassard.net>
Cc: 17971 <at> debbugs.gnu.org
Subject: Re: bug#17971: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Wed, 09 Jul 2014 12:34:59 -0400

Stephen Hassard wrote:

> For fun I built a copy of findutils-4.5.12 from alpha.gnu.org and found
> that it's suffering the same regression as CentOS's bundled find.

Thanks for investigating.
Do you understand why new find is failing?
Is it a bug in find, or ...?

After it says:

> find: './progmodes/make-mode.el': No such file or directory

does make-mode.el.gz exist (meaning it somehow got exec'd twice, which
seems like a find bug); or was find somehow in a different directory
(which also would seem like a find bug)?

Since today's RHEL is yesterday's Fedora, I'm a bit surprised this
hasn't been reported before. I looked in RH bugzilla but did not see
anything relevant.

BTW, I'm surprised to see that RHEL7 (long-term enterprise release) has
ended up with a findutils version from the 4.5 series, which looks like
a development branch. Even Debian unstable still has 4.4*.

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

From: Stephen Hassard <steve <at> hassard.net>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 17971 <at> debbugs.gnu.org
Subject: Re: bug#17971: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Wed, 9 Jul 2014 10:29:32 -0700

[Message part 1 (text/plain, inline)]

Strangely it looks like find 4.5 builds have been in Fedora since at least
FC18.

Testing the behaviour, it appears that the .el file is successfully
compressed to make-mode.el.gz, but find errors out. It seems like it might
be doing a stat on the .el file after gzip does it's work.

It appears that Emacs 24.3 has a different find command for the compression
which doesn't seem to exacerbate the regression in find 4.5.


On Wed, Jul 9, 2014 at 9:34 AM, Glenn Morris <rgm <at> gnu.org> wrote:

> Stephen Hassard wrote:
>
> > For fun I built a copy of findutils-4.5.12 from alpha.gnu.org and found
> > that it's suffering the same regression as CentOS's bundled find.
>
> Thanks for investigating.
> Do you understand why new find is failing?
> Is it a bug in find, or ...?
>
> After it says:
>
> > find: './progmodes/make-mode.el': No such file or directory
>
> does make-mode.el.gz exist (meaning it somehow got exec'd twice, which
> seems like a find bug); or was find somehow in a different directory
> (which also would seem like a find bug)?
>
> Since today's RHEL is yesterday's Fedora, I'm a bit surprised this
> hasn't been reported before. I looked in RH bugzilla but did not see
> anything relevant.
>
> BTW, I'm surprised to see that RHEL7 (long-term enterprise release) has
> ended up with a findutils version from the 4.5 series, which looks like
> a development branch. Even Debian unstable still has 4.4*.
>

[Message part 2 (text/html, inline)]

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

From: Glenn Morris <rgm <at> gnu.org>
To: Stephen Hassard <steve <at> hassard.net>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 17971 <at> debbugs.gnu.org
Subject: Re: bug#17971: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Thu, 10 Jul 2014 12:06:37 -0400

My inclination is to revert install-arch-indep to how it used to be
before 2014-02-13. This has the virtue of having had more testing. It
was changed to avoid some unexplained HP make problem, which frankly I
don't think matters much (eg we require GNU make anyway in Emacs trunk
now).

Does this work for you:

*** Makefile.in	2014-02-14 08:05:18 +0000
--- Makefile.in	2014-07-10 15:59:29 +0000
***************
*** 614,622 ****
  	  ${write_subdir} || true
  	[ -z "${GZIP_PROG}" ] || { \
  	  echo "Compressing *.el ..." && \
! 	  cd "$(DESTDIR)${lispdir}" && \
! 	  find . -name '*.elc' -exec $(SHELL) -c \
! 	    '${GZIP_PROG} -9n `expr "$$1" : "\\(.*\\)c"`' dummy '{}' ';'; \
  	}
  	-chmod -R a+r "$(DESTDIR)${datadir}/emacs/${version}" ${COPYDESTS}
  
--- 614,624 ----
  	  ${write_subdir} || true
  	[ -z "${GZIP_PROG}" ] || { \
  	  echo "Compressing *.el ..." && \
! 	  cd "$(DESTDIR)${lispdir}" || exit 1 ; \
! 	  for f in `find . -name "*.elc" -print`; do \
! 	    f_el=`echo "$$f" | sed 's/.elc$$/.el/'`; \
! 	    ${GZIP_PROG} -9n "$$f_el" ; \
! 	  done ; \
  	}
  	-chmod -R a+r "$(DESTDIR)${datadir}/emacs/${version}" ${COPYDESTS}
  

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Glenn Morris <rgm <at> gnu.org>, Stephen Hassard <steve <at> hassard.net>
Cc: 17971 <at> debbugs.gnu.org
Subject: Re: bug#17971: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Thu, 10 Jul 2014 10:14:43 -0700

Glenn Morris wrote:

> My inclination is to revert install-arch-indep to how it used to be
> before 2014-02-13.

The patch you proposed is a simplification of the pre-2014-02-13 code, a 
simplification that should also avoid the HP-UX problm.  (HP-UX make is 
still relevant for the emacs-24 branch, I guess.)

> ! 	  cd "$(DESTDIR)${lispdir}" || exit 1 ; \
> ! 	  for f in `find . -name "*.elc" -print`; do \
> ! 	    f_el=`echo "$$f" | sed 's/.elc$$/.el/'`; \
> ! 	    ${GZIP_PROG} -9n "$$f_el" ; \
> ! 	  done ; \

This has the problem that 'make' can succeed even if a 'gzip' fails 
(e.g., due to being out of disk space).  Also, it can be simplified a 
bit.  How about something like this instead?

	  cd "$(DESTDIR)${lispdir}" && \
 	  for f in `find . -name '*.elc' -print | sed 's/.elc$$/.el/'`; do \
	    ${GZIP_PROG} -9n "$$f" || exit; \
	  done; \

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

From: Glenn Morris <rgm <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Stephen Hassard <steve <at> hassard.net>, 17971 <at> debbugs.gnu.org
Subject: Re: bug#17971: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Thu, 10 Jul 2014 14:06:17 -0400

Paul Eggert wrote:

> (HP-UX make is still relevant for the emacs-24 branch, I guess.)

In theory yes; in practice I doubt it, since we seem to have
accidentally broken non-GNU makes so many times, I guess everyone just
uses GNU make anyway (like the person who reported the HP make issue did
before even reporting it).

> This has the problem that 'make' can succeed even if a 'gzip' fails
> (e.g., due to being out of disk space).

We survived this far without checking for that.
Some gzips return non-zero if compression did not reduce the file size,
which should not happen with any of the .el files, but you never know.
So perhaps this is something to save for trunk.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Stephen Hassard <steve <at> hassard.net>, 17971 <at> debbugs.gnu.org
Subject: Re: bug#17971: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Thu, 10 Jul 2014 11:49:10 -0700

Glenn Morris wrote:
> So perhaps this is something to save for trunk.

Sure, that'd be fine.

By the way, I still test emacs-24 with non-gnu 'make' on Solaris, where 
typically 'make' gets you Solaris 'make' and 'gmake' gets you GNU 
'make', and I'm just in the habit of typing 'make' (a habit I suppose I 
must learn to get out of....).

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stephen Hassard <steve <at> hassard.net>
Cc: Glenn Morris <rgm <at> gnu.org>, 17971 <at> debbugs.gnu.org
Subject: Re: bug#17971: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Thu, 10 Jul 2014 23:37:48 -0700

Strange -- I cannot reproduce the problem with findutils 4.5.12 alpha, 
on either Fedora 20 or on Ubuntu 14.04 (both x86-64).

Stephen, can you do an 'strace' of the failing 'find' invocation? 
Something like this, where the files are not yet compressed:

cd "/home/shassard/opt/emacs/share/emacs/24.3.92/lisp"
strace -f -o /tmp/tr find . -name '*.elc' -exec /bin/sh -c \
    '/usr/bin/gzip -9n `expr "$1" : "\\(.*\\)c"`' dummy '{}' ';'

(/tmp/tr will be fairly large, alas) and look in /tmp/tr just before 
'find' issues its first complaint.

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

From: Stephen Hassard <steve <at> hassard.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Glenn Morris <rgm <at> gnu.org>, 17971 <at> debbugs.gnu.org
Subject: Re: bug#17971: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Fri, 11 Jul 2014 07:52:25 -0700

[Message part 1 (text/plain, inline)]

I've attached the trace.

Since 'make install' was succeeding in compressing the .el files, I had to
manually uncompress them before running the test.

find errored as expected on my CentOS7 machine, so hopefully the strace
should show the same behaviour.

Thanks,
Steve


On Thu, Jul 10, 2014 at 11:37 PM, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> Strange -- I cannot reproduce the problem with findutils 4.5.12 alpha, on
> either Fedora 20 or on Ubuntu 14.04 (both x86-64).
>
> Stephen, can you do an 'strace' of the failing 'find' invocation?
> Something like this, where the files are not yet compressed:
>
> cd "/home/shassard/opt/emacs/share/emacs/24.3.92/lisp"
> strace -f -o /tmp/tr find . -name '*.elc' -exec /bin/sh -c \
>
>     '/usr/bin/gzip -9n `expr "$1" : "\\(.*\\)c"`' dummy '{}' ';'
>
> (/tmp/tr will be fairly large, alas) and look in /tmp/tr just before
> 'find' issues its first complaint.
>

[Message part 2 (text/html, inline)]

[find_trace.txt.gz (application/x-gzip, attachment)]

Message #52 received at 17971-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stephen Hassard <steve <at> hassard.net>
Cc: Glenn Morris <rgm <at> gnu.org>, 17971-done <at> debbugs.gnu.org
Subject: Re: bug#17971: 24.3.92; Patch to fix el compression on RHEL/CentOS 7
Date: Fri, 11 Jul 2014 10:36:16 -0700

On 07/11/2014 07:52 AM, Stephen Hassard wrote:
> I've attached the trace.

Thanks, I now see the problem; it's a readdir race, where 'find' uses 
readdir to get a batch of directory entries, then execs 'gzip' which 
removes one of them, and then 'find' later complains when it gets around 
to processing the now-removed entry.  'find' traditionally ignored that 
sort of thing; I don't know why GNU 'find' changed this (for some reason 
it's fstatatting the file twice? why?).  I still cannot reproduce the 
problem, so I expect it's OS- or filesystem-dependent.

Anyway, Glenn's patch should avoid the problem, so I installed it (with 
a few minor simplifications) as emacs-24 bzr 117370, and am marking this 
as done.  This version of the patch does not look for gzip failures; 
that can be done on the trunk later.

Previous Next

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