Bug 176171 - update emacs to 22.0.50 from 21.4
update emacs to 22.0.50 from 21.4
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: emacs (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Chip Coldwell
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-19 15:06 EST by dann
Modified: 2007-11-30 17:11 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-12 10:10:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
updated spec file for emacs-22.0.50 (45.58 KB, text/plain)
2006-02-05 14:12 EST, dann
no flags Details
spec file for emacs 22.0.50 (49.85 KB, patch)
2006-04-06 02:35 EDT, dann
no flags Details | Diff

  None (edit)
Description dann 2005-12-19 15:06:58 EST
I am suggesting that instead of using emacs-21.4 for FC5 it would be better
to use the current CVS version of emacs: emacs-22.0.50

Nobody knows when is emacs-22 going to be released, but the
number of things remaining to be fixed before a release is quite
small (see emacs/admin/FOR-RELEASE). It is quite conceivable that
emacs-22 will be released during the FC5 lifetime and before
FC6. So it would be better to integrate the new emacs version
now, rather than after the FC5 release.

emacs-22 is a significant release, it has a large number of very
useful features and fixes to the existing features, so it would
be good for the FC5 users to be able to use it.
Comment 1 dann 2006-01-17 16:18:55 EST
More info: switching to emacs-22 would simplify the SRPM, as AFAICT most of the
source patches won't be needed, the latest version of the cc-mode and tramp
packages is included by default, as is the elisp manual.

The dotemacs.el file can be simplified by not turning on syntax highlighting as
it is now done by default. 

I can help with packaging/testing if that is needed.
Comment 2 Jens Petersen 2006-01-19 02:14:32 EST
Yeah, basically the current spec file is already Emacs 22 ready...
Comment 3 dann 2006-01-19 16:47:40 EST
(In reply to comment #2)
> Yeah, basically the current spec file is already Emacs 22 ready...

I took a look at the spec file included in your emacs-22.0.50-0.20050630.src.rpm.
Here are some possible improvements:
1. In dotemacs.el
remove:
(when (fboundp 'global-font-lock-mode)
  (global-font-lock-mode t))
global-font-lock-mode is now turned on by default in emacs22.

2. In emacs-21.2-s390.patch
a.the ibms390.h part of the patch is not needed in emacs22
b. Is there any reason that the ibms390x.h patch is not submitted upstream?
There's no reason to carry such a patch in FC... I can commit it in CVS, but I
don't have a way to test if it works... 

3.Source33:http://download.sourceforge.net/cc-mode/cc-mode-%{cc_mode_ver}.tar.gzc-mode
can be omitted for emacs22, the latest version is included.

4.Patch28 and none of the SETARCH="setarch i386" stuff in emacs.spec are not
needed. The make + configure take care of running setarch when needed.

I can provide patches for all these if it would help getting emacs-22 in FC5.
Comment 4 dann 2006-01-19 18:50:29 EST
More data about the spec file for emacs22:

emacs-21.2-alloc-blockinput-83600.patch is not needed anymore, the code is
already present in emacs22.

emacs-21.3-gud-libtool-fix.patch seems to not be needed, I could not reproduce
the problem in bug #130955 with emacs22.

emacs-21.3-lisp-textmodes-ispell-languages.patch seems to not be needed, I could
not reproduce the problem in bug #122618 with emacs22.
Comment 5 dann 2006-02-05 14:12:34 EST
Created attachment 124221 [details]
updated spec file for emacs-22.0.50

Attached is an updated spec file that seems to create working emacs-22.0.50
rpms on x86. 

The spec file was derived from the spec file in:
http://people.redhat.com/petersen/emacs/SRPMS/emacs-22.0.50-0.20050630.src.rpm
Comment 6 dann 2006-02-14 14:00:23 EST
As of today the s390 patches are not needed anymore for emacs-22.
So Patch2 and Patch5 in emacs.spec can be moved inside an %if %{emacs21}
We are down to 2 patches needed for emacs-22: patch11 and patch14

Is there any chance that emacs-22.0.50 will be in FC5?
Comment 7 GeekPoet 2006-02-14 14:18:45 EST
Sorry if you all already know this, but I have an emacs-22 rpm set from the
following link:

http://nicku.org/software/emacs/

It works great with my FC4. May be we can derive the spec files for FC5 from the
src.rpm here?

Thanks,
GP
Comment 9 dann 2006-03-28 14:32:08 EST
The po-compat.el file can be eliminated from the spec file.

Here is what po-compat.el says:

;; Emacs 21.2 and newer already contain this file, under the name po.el,
;; and without portability hassles.
Comment 10 dann 2006-03-28 19:05:03 EST
(In reply to comment #7)
> It works great with my FC4. May be we can derive the spec files for FC5 from the
> src.rpm here?

The spec is not not the main issue here, a policy decision is needed. 
If whoever is in charge decides to support emacs 22, then the spec file can be 
fixed...
Comment 11 dann 2006-04-06 02:35:18 EDT
Created attachment 127390 [details]
spec file for emacs 22.0.50

Merged the spec file with the one from emacs-21.4-14.src.rpm
It builds rpms for emacs-22.0.50 on x86
Comment 12 dann 2006-05-31 12:37:51 EDT
Can we please have a comment from the emacs rpm maintainer if emacs will be
updated to 22.0.50 ? 
The FC6 deadline is not that far away, so it would be nice to know what is the plan.
Thanks!
Comment 13 Chip Coldwell 2006-06-05 09:24:20 EDT
(In reply to comment #12)
> Can we please have a comment from the emacs rpm maintainer if emacs will be
> updated to 22.0.50 ? 
> The FC6 deadline is not that far away, so it would be nice to know what is the
plan.

I prefer emacs-22 myself but I'm a bit hesitant to put it in FC6 before it is an
official release from gnu.org.    I'm exploring ways we could include an emacs22
 package in Fedora Extras, although that might make for more work in the future.

I'll try building the src rpm from comment #11 in our new build system and see
what happens.  

Chip

Comment 14 Jonathan Underwood 2006-06-29 13:38:43 EDT
I am considering putting in the work to bring emacs22 to FE - Chip, could you
comment on what you think the issues are that make for more work in the future?

Comment 15 Leo 2006-11-14 07:19:08 EST
There has been a discussion of this in devel mailing list.

http://thread.gmane.org/gmane.linux.redhat.fedora.devel/45150/focus=45150
Comment 16 Chip Coldwell 2006-11-14 09:33:53 EST
22.0.90 (pretest) RPMs are available from

http://people.redhat.com/coldwell/bugs/emacs/176171/

Chip
Comment 17 Leo 2006-11-24 14:37:13 EST
The progress of the pretest seems very promising.

"ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.91.tar.gz

The various build problems in 22.0.90 should be resolved.  We should
now make the pretest announcement, if Richard has finished updating
the pretesters list." -- http://thread.gmane.org/gmane.emacs.devel/62434
Comment 19 Frank Schmitt 2006-12-27 18:47:29 EST
I see binary rpms on http://people.redhat.com/coldwell/bugs/emacs/176171/ but no
srpms, which is both inconvenient for users trying to rebuild with a newer
snapshot and a violation of the GPL...
Comment 20 Jonathan Underwood 2006-12-28 04:31:52 EST
tonne24: relax a little bit, I'm sure Chip isn't intentionally breaking the GPL,
and as stated earlier in the thread, theemacs 21.4 spec file can be used to
build emacs 22 with a minor bit of tweaking.

That said, it would be nice to see emacs rebased to the 22 pre-releases in the
development tree, which would also make the source rpms available. That way FE
emacs add on packagers (like myself) can have plenty of time to check
compatibility with emacs 22. 
Comment 21 Frank Schmitt 2006-12-28 05:23:41 EST
I really didn't want to sound offending, I just stated a fact. And BTW: I'm
Frank, no tonne24
Comment 22 Chip Coldwell 2007-01-02 14:10:15 EST
(In reply to comment #19)
> I see binary rpms on http://people.redhat.com/coldwell/bugs/emacs/176171/ but no
> srpms, which is both inconvenient for users trying to rebuild with a newer
> snapshot and a violation of the GPL...

The issue here (believe it or not) was that I was exceeding my disk quota on
people.redhat.com.  I had to get some test kernels up for another bug, so the
emacs src rpm was sacrificed.

Apropos the spec file, right now my thinking is that it would be nice to start
with a clean slate for emacs-22.  A lot of cruft has accumulated in the emacs-21
spec file, and so much if-deffery is required to use the same spec for -21 and
-22 that it hardly seems worth it.

I'm going to post a new package with emacs-22.0.92 ASAP, hopefully today.  I'll
try to squeeze a src.rpm on there if it will fit; otherwise I'll post it
elsewhere with a link.

Chip

Comment 23 Chip Coldwell 2007-01-02 17:22:22 EST
OK, the new rpms for 22.0.92 are up at

http://people.redhat.com/coldwell/bugs/emacs/176171/

I got my disk quota increased, so the .src.rpms are there also, for those of you
who like doing CVS snapshots.

I only had time to do some superficial testing, so let me know if there are
problems.

Chip
Comment 24 David Woodhouse 2007-01-02 17:25:15 EST
PPC packages seem to be missing.
Comment 25 Leo 2007-01-02 17:42:04 EST
"As someone who participates in Emacs pretests since v19.30, I
cannot in good faith say that the official version is so much
more stable than the pretest one." --
http://permalink.gmane.org/gmane.emacs.help/40106

Maybe it is time to add Emacs 22 to rawhide to get it properly tested.
Comment 26 David Woodhouse 2007-01-02 18:05:22 EST
BuildRequires: sendmail is surely bogus.

Perhaps it should be /usr/lib/sendmail, which alternative MTAs like Exim would
satisfy?
Comment 27 David Woodhouse 2007-01-02 18:12:58 EST
BR for cairo would be good though
Comment 28 Chip Coldwell 2007-01-02 19:20:27 EST
(In reply to comment #26)
> BuildRequires: sendmail is surely bogus.
> 
> Perhaps it should be /usr/lib/sendmail, which alternative MTAs like Exim would
> satisfy?

Perhaps.  I added that for bug 213813, but clearly any local MTA would work.

Chip


Comment 29 David Woodhouse 2007-01-03 04:19:18 EST
Lacking BR for freetype-devel too, although that's arguably something that
cairo-devel itself should require...

checking for gtk+-2.0 >= 2.4 glib-2.0 >= 2.4... no
Package fontconfig was not found in the pkg-config search path. Perhaps you
should add the directory containing `fontconfig.pc' to the PKG_CONFIG_PATH
environment variable Package 'fontconfig', required by 'cairo', not found
configure: error: Library requirements (gtk+-2.0 >= 2.4 glib-2.0 >= 2.4) not
met; consider adjusting the PKG_CONFIG_PATH environment variable if your
libraries are in a nonstandard prefix so pkg-config can find them.
error: Bad exit status from /var/tmp/rpm-tmp.56328 (%build)

Comment 30 David Woodhouse 2007-01-03 04:34:49 EST
Having fixed all the missing BuildRequires (cf. bug 221250) it builds fine on PPC.
Comment 31 dann 2007-01-03 05:11:17 EST
(In reply to comment #23)
> I only had time to do some superficial testing, so let me know if there are
> problems.

I looked at emacs.spec and I have a few observations.

1. "setarch" is used when building. Do you have any evidence that it's still
needed? The emacs build system should take care of that by default. If it
doesn't it's a bug. 

2. emacs.png is the old emacs icon. There's a new icon now, see
emacs/etc/images/icon/*.png

3. Is emacs-xim-status-under-window-125413.patch still needed? (I am not
familiar with XIM, so I can't tell). If yes, then this would be a very good time
to submit it upstream (i.e. emacs-pretest-bug@gnu.org). to. 

Comment 32 Chip Coldwell 2007-01-03 09:43:52 EST
(In reply to comment #30)
> Having fixed all the missing BuildRequires (cf. bug 221250) it builds fine on PPC.

Can you attach your spec file to the BZ?  I'll turn a rev on the .src.rpm using
your version.

Chip
Comment 33 Chip Coldwell 2007-01-03 10:09:32 EST
(In reply to comment #26)
> BuildRequires: sendmail is surely bogus.
> 
> Perhaps it should be /usr/lib/sendmail, which alternative MTAs like Exim would
> satisfy?

This is actually a deeper problem.  /usr/lib/sendmail will exist on machines
with Exim installed, but in order to build emacs in a mock root, we need to
specify a specific MTA package.  In fact, for purposes of fixing the original
problem (bug 213813), an MSA would be sufficient.

Anyway, it's all moot since the bug doesn't exist in emacs-22. 
lisp/mail/sendmail.el has 

(defcustom sendmail-program
  (cond
    ((file-exists-p "/usr/sbin/sendmail") "/usr/sbin/sendmail")
    ((file-exists-p "/usr/lib/sendmail") "/usr/lib/sendmail")
    ((file-exists-p "/usr/ucblib/sendmail") "/usr/ucblib/sendmail")
    (t "fakemail"))                     ;In ../etc, to interface to /bin/mail.
  "Program used to send messages."
  :group 'mail
  :type 'file)

N.B. "defcustom" instead of "defconst" as in emacs-21.  So I think we can just
drop the BR: sendmail.

Chip
Comment 34 David Woodhouse 2007-01-03 10:21:28 EST
(In reply to comment #32)
> (In reply to comment #30)
> > Having fixed all the missing BuildRequires (cf. bug 221250) it builds fine
on PPC.
> 
> Can you attach your spec file to the BZ?  I'll turn a rev on the .src.rpm using
> your version.

When I say 'fixed' I just mean that I installed them all. There's a list in bug
#221250, although I'd suggest that those should possibly by required by other
packages rather than by emacs directly.

Comment 35 Frank Schmitt 2007-01-03 11:21:49 EST
From the NEWS file:

** Emacs now supports new configure options `--program-prefix',
`--program-suffix' and `--program-transform-name' that affect the names of
installed programs.

wouldn't using this simplify the specfile regarding build of with and without X?
Comment 36 Chip Coldwell 2007-01-03 11:44:18 EST
(In reply to comment #31)
> 
> 1. "setarch" is used when building. Do you have any evidence that it's still
> needed? The emacs build system should take care of that by default. If it
> doesn't it's a bug. 

It seems to build without setarch -R now.  They must have adapted to virtual
address randomization in the dumper.

> 2. emacs.png is the old emacs icon. There's a new icon now, see
> emacs/etc/images/icon/*.png

I, for one, will miss the gnu.  But I suppose we should stay in step with
upstream here.

> 3. Is emacs-xim-status-under-window-125413.patch still needed? (I am not
> familiar with XIM, so I can't tell). If yes, then this would be a very good time
> to submit it upstream (i.e. emacs-pretest-bug@gnu.org). to. 

I'll check.

Chip
Comment 37 Chip Coldwell 2007-01-03 12:32:15 EST
(In reply to comment #31)
 
> 3. Is emacs-xim-status-under-window-125413.patch still needed? (I am not
> familiar with XIM, so I can't tell). If yes, then this would be a very good time
> to submit it upstream (i.e. emacs-pretest-bug@gnu.org). to. 


It's actually a very good question since the specfile has

%configure --with-pop --with-sound --with-gtk --without-xim

so if we're building --without-xim who cares about the xim configuration?

Chip
Comment 38 Chip Coldwell 2007-01-03 12:53:05 EST
(In reply to comment #35)
> From the NEWS file:
> 
> ** Emacs now supports new configure options `--program-prefix',
> `--program-suffix' and `--program-transform-name' that affect the names of
> installed programs.
> 
> wouldn't using this simplify the specfile regarding build of with and without X?

Maybe not.  The suffix is appended to the names of all the installed programs
... so you get

emacsclient-nox
etags-nox
ctags-nox

etc. when really all you wanted was emacs-nox.

Chip

Comment 39 dann 2007-01-05 12:44:16 EST
(In reply to comment #23)

More comments on the src.rpm 

1. Given that the variables changed in browse-url-htmlview-84262.patch are
customizable, it might be better to not patch the file but just set them in
site-start.el 

What is htmlview? Is this something specific to FC/RHEL or it is something that
other distributions use? If yes then this could be fixed upstream. 

2. Is the emacs-21.3-no-rpath.patch still needed? I did not see any rpath on the
command line when building emacs from CVS on FC5... 

3. po-compat.el should not be needed, emacs/lisp/textmodes/po.el does that job.

4. is lang-coding-systems-init.el still needed? Things have changed a lot in
that area since 21.x... (no idea here...)
Comment 40 Chip Coldwell 2007-01-22 15:26:46 EST
Some new FC-6 rpms are up at

http://people.redhat.com/coldwell/bugs/emacs/176171/FC-6

I've tried to incorporate most of the suggestions, which boils down to: this is
an unpatched version of the pretest emacs.  All the src.rpm does is add some
elisp files for things like rpm-spec-mode, etc. (and the gnu icon -- yes I know
it will have to go).

Chip
Comment 41 David Woodhouse 2007-01-23 00:45:55 EST
Please consider running createrepo. It'd make it easier for people to use yum to
test these packages when you update them.
Comment 42 dann 2007-01-23 03:00:34 EST
(In reply to comment #40)
> Some new FC-6 rpms are up at
> 
> http://people.redhat.com/coldwell/bugs/emacs/176171/FC-6
> 
> I've tried to incorporate most of the suggestions, which boils down to: this is
> an unpatched version of the pretest emacs.  All the src.rpm does is add some
> elisp files for things like rpm-spec-mode, etc. (and the gnu icon -- yes I know

Here's more stuff to get rid off:
1. from dotemacs.el:
(when (fboundp 'global-font-lock-mode)
  (global-font-lock-mode t))
global-font-lock-mode is on by default now, even with emacs -q, no need to worry
about it here.

2. default.el
  (mwheel-install)
mouse-wheel-mode is on by default on X11, so no need to do this.

3. default.el
(auto-compression-mode t)
This is also on by default. 

4. I would say move (setq focus-follows-mouse nil) from default.el to
site-start.el so that the user can override it in a less awkward way in his .emacs






Comment 43 Chip Coldwell 2007-01-23 13:42:45 EST
(In reply to comment #25)
> "As someone who participates in Emacs pretests since v19.30, I
> cannot in good faith say that the official version is so much
> more stable than the pretest one." --
> http://permalink.gmane.org/gmane.emacs.help/40106
> 
> Maybe it is time to add Emacs 22 to rawhide to get it properly tested.

FC-7 test 1 freezes today; I'm going to try to sneak in emacs-22.

Chip


Comment 44 Chip Coldwell 2007-01-23 13:56:30 EST
(In reply to comment #42)

> Here's more stuff to get rid off:
> 1. from dotemacs.el:
> (when (fboundp 'global-font-lock-mode)
>   (global-font-lock-mode t))
> global-font-lock-mode is on by default now, even with emacs -q, no need to worry
> about it here.

Done.

> 2. default.el
>   (mwheel-install)
> mouse-wheel-mode is on by default on X11, so no need to do this.

Done

> 3. default.el
> (auto-compression-mode t)
> This is also on by default. 

Done

> 4. I would say move (setq focus-follows-mouse nil) from default.el to
> site-start.el so that the user can override it in a less awkward way in his .emacs

N.B., the upshot of 2,3,4 is that default.el is now empty (except for comments).

Chip
Comment 45 Chip Coldwell 2007-01-23 16:41:42 EST
It looks like we're going to make it.  emacs-22.0.93 (latest pretest) will go in
FC-7 test1.

Chip
Comment 46 Frank Schmitt 2007-01-24 02:23:52 EST
You did a great job, thanks.
Comment 47 Jonathan Underwood 2007-01-24 06:48:05 EST
Yes - I'd like to join Frank in thanking you for your work on this chip, great job.
Comment 48 Chip Coldwell 2007-01-24 09:57:05 EST
(In reply to comment #47)
> Yes - I'd like to join Frank in thanking you for your work on this chip, great
job.

The congratulations may be a bit premature.  I'm having build issues on s390
(always the mainframes) that may keep -22 out of test1.  But I'm doing
everything I can (including calling in favors that aren't owed) to get it in.

Chip
Comment 49 Chip Coldwell 2007-01-24 16:51:35 EST
(In reply to comment #41)
> Please consider running createrepo. It'd make it easier for people to use yum to
> test these packages when you update them.

OK, done (for FC-6, anyway).  You can download

http://people.redhat.com/coldwell/emacs/emacs-22.repo

into /etc/yum.repos.d.

There's no need for an FC-7/rawhide repo since emacs-22.0.93-3 will be in FC-7
(Yay!).  I'll try to set up an FC-5 repo as well.

Chip
Comment 50 Laurent Rineau 2007-01-25 09:11:34 EST
(In reply to comment #45)
> It looks like we're going to make it.  emacs-22.0.93 (latest pretest) will 
go in
> FC-7 test1.

Thank you ! The current Rawhide src.rpm compiles finely on FC-5.
Comment 51 Chip Coldwell 2007-01-25 10:06:50 EST
(In reply to comment #50)
> (In reply to comment #45)
> > It looks like we're going to make it.  emacs-22.0.93 (latest pretest) will 
> go in
> > FC-7 test1.
> 
> Thank you ! The current Rawhide src.rpm compiles finely on FC-5.

I've set up fedora repos for FC-5 and FC-6.  You can get the repo config file here

http://people.redhat.com/coldwell/emacs/fedora/emacs-22.repo

That's my proposed solution for FC-5/6 users who want emacs-22.  The alternative
 would be to create an "emacs22" extras package.

Chip

Comment 52 Tom Tromey 2007-02-08 19:54:34 EST
Emacs 22 includes a python mode.
I haven't compared it to the mode that is installed in site-lisp,
but perhaps the upstream ought to be preferred.
Comment 53 dann 2007-02-08 20:24:49 EST
(In reply to comment #52)
> Emacs 22 includes a python mode.
> I haven't compared it to the mode that is installed in site-lisp,
> but perhaps the upstream ought to be preferred.

There was some discussion about the relative capabilities of the 2 packages on
the emacs mailing list a few months ago. I don't remember if there was any
conclusion about that. You might want to reopen the discussion....
Comment 54 Tom Tromey 2007-02-09 18:10:49 EST
I found this thread from last August:

http://thread.gmane.org/gmane.emacs.devel/58258/

.. but the result just seems to be the FSF asking for an assignment
of the other python mode.  Do you know of a more recent thread?
Comment 55 dann 2007-02-10 16:57:04 EST
(In reply to comment #54)
> I found this thread from last August:
> 
> http://thread.gmane.org/gmane.emacs.devel/58258/
> 
> .. but the result just seems to be the FSF asking for an assignment
> of the other python mode.  Do you know of a more recent thread?

No, that is the one I was thinking about. 
There were some patches posted there to add some missing capabilities to the
builtin python package (wrt debugging or something of the sort). 
Are the differences big enough to warrant carrying an extra package? No idea...
FWIW I am personally quite happy with the builtin package.
Comment 56 dann 2007-02-10 17:09:53 EST
Should the Fedora package continue to include igrep?
The new builtin commands rgrep (for recursive grep) and lgrep seem to satisfy
most needs... 
Comment 57 Chip Coldwell 2007-02-12 10:10:09 EST
Most of the recent discussions on this bug have nothing to do with adding the
pretest emacs-22 to the Fedora distribution ... I would prefer if issues with
python mode, etc. were in separate bugs.  So I am going to close this bug and
invite everyone to factor their discussions into new bugs.

Thanks,

Chip
Comment 58 Chip Coldwell 2007-02-26 15:31:19 EST
Another pretest was (prematurely) released:

ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.94.tar.gz

but the discussion on the mailing list indicates that there will be one coming
up again on March 1, so I am going to hold off until then.

Chip
Comment 59 Chip Coldwell 2007-03-07 13:25:09 EST
I built packages for emacs-22.0.95, the latest pretest release.  Rawhide
packages should be available through the usual channels, and FC-5/6 packages are
up on my private repo at

http://people.redhat.com/coldwell/emacs/fedora/

This version still suffers from bug 224611 (which is starting to look like an
ATK bug), unfortunately.

Chip
Comment 60 Chip Coldwell 2007-05-18 08:51:52 EDT
(In reply to comment #3)
> 
> 4.Patch28 and none of the SETARCH="setarch i386" stuff in emacs.spec are not
> needed. The make + configure take care of running setarch when needed.

Can you point me to where this is implemented?  I see this in the changelog:

2004-09-24  Jan Djärv  <jan.h.d@swipnet.se>

	* config.in: Rebuild.

	* Makefile.in: Run setarch i386 ./temacs if exec-shield is present.

2004-10-20  Jan Djärv  <jan.h.d@swipnet.se>

	* xterm.h (XSync): If USE_GTK, define XSync as process_all and then
	XSync.

	* emacs.c (my_heap_start, heap_bss_diff, MAX_HEAP_BSS_DIFF):
	New variables and constant.
	(main): Calculate heap_bss_diff.  If we are dumping and the
	heap_bss_diff is greater than MAX_HEAP_BSS_DIFF, set PER_LINUX32
	and exec ourself again.
	(Fdump_emacs): If heap_bss_diff is greater than MAX_HEAP_BSS_DIFF
	print a warning.

	* lastfile.c: Make my_endbss and my_endbss_static available on all
	platforms.

	* Makefile.in (RUN_TEMACS): Remove @SETARCH@.
	* config.in (HAVE_PERSONALITY_LINUX32): Regenerate.

So it looks like it went in and then was taken back out again because of some
changes to the dumper.  However, when I try to run unexelf.c:unexec outside of
emacs (with a little test program), I find that setarch is still needed.

??

Chip
Comment 61 Frank Schmitt 2007-05-18 09:27:33 EDT
After updating under FC6 to emacs-22.0.99-1.fc6 from your repository, the
symlink from /usr/bin/emacs to /usr/bin/emacs-22.0.99 has gone missing. previous
versions didn't have this problem.
Comment 62 Frank Schmitt 2007-05-18 09:29:24 EDT
BTW: I see that there are some problems with the dumper under FC7. It's urgent
that you report them to Emacs devel, as the release is getting really close now.
Comment 63 Chip Coldwell 2007-05-18 09:34:51 EDT
(In reply to comment #61)
> After updating under FC6 to emacs-22.0.99-1.fc6 from your repository, the
> symlink from /usr/bin/emacs to /usr/bin/emacs-22.0.99 has gone missing. previous
> versions didn't have this problem.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239745
Comment 64 dann 2007-05-18 11:49:59 EDT
(In reply to comment #60)
> (In reply to comment #3)
> > 
> > 4.Patch28 and none of the SETARCH="setarch i386" stuff in emacs.spec are not
> > needed. The make + configure take care of running setarch when needed.
> 
> Can you point me to where this is implemented?  I see this in the changelog:

etc/PROBLEMS states that setarch is run by configure, but it seems that it has
been taken out in preference of using "personality (PER_LINUX32)" (see the
top-level configure.in and ChangeLog). Hope this helps. 

Note You need to log in before you can comment on or make changes to this bug.