Bug 11254 - xemacs segfaults immediately after launch
Summary: xemacs segfaults immediately after launch
Status: RESOLVED WONTFIX
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard: MGA5TOO
Keywords:
: 13856 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-09-18 12:17 CEST by Juergen Harms
Modified: 2016-02-13 10:18 CET (History)
14 users (show)

See Also:
Source RPM: xemacs-21.4.22-26.mga6, xemacs-21.4.22-26.mga5
CVE:
Status comment:


Attachments
output when xemacs is launched from a console (2.37 KB, text/plain)
2013-09-18 12:20 CEST, Juergen Harms
Details
backtrace (10.95 KB, text/plain)
2013-09-19 00:30 CEST, Dave Hodgins
Details
fixed Mandriva-customized initialisation file (4.62 KB, text/x-emacs-lisp)
2013-11-12 12:38 CET, Juergen Harms
Details
lisp backtrace (1.19 KB, text/plain)
2015-10-12 17:55 CEST, Dave Hodgins
Details

Description Juergen Harms 2013-09-18 12:17:15 CEST
Description of problem:
I have installed xemacs from cauldron (fully updated Alpha 2) (along with xemacs-extra, xemacs-el, xemacs-mule + dependencies) - no customisation. When I launch xemacs, it immediately fails with a seg fault


Version-Release number of selected component (if applicable):

xemacs-21.4.22

How reproducible:
always


Steps to Reproduce:
1. install xemacs
2. launch xemacs
3.


Reproducible: 

Steps to Reproduce:
Comment 1 Juergen Harms 2013-09-18 12:20:07 CEST
Created attachment 4359 [details]
output when xemacs is launched from a console
Jani Välimaa 2013-09-18 15:41:32 CEST

Attachment 4359 mime type: application/octet-stream => text/plain

Comment 2 Dave Hodgins 2013-09-19 00:30:46 CEST
Created attachment 4362 [details]
backtrace

CC: (none) => davidwhodgins

Dave Hodgins 2013-09-19 00:31:53 CEST

Assignee: bugsquad => nanardon

Comment 3 Juergen Harms 2013-11-07 11:53:57 CET
Investing efforts on fixing a bug on such a 5-year-old release looks like a loss of time.
 
To avoid duplication of efforts: I have now done a local build of xemacs-21.5.34. Quite a lot of changes (essentially evident) in the spec file: now builds correctly, nothing dramatic in rmplint. There is though a series of issues to be pursued:

- the newly built xemacs runs nicely, the present bug is gone, but has a successor: xemacs segfaults when I do Edit -> Find when Xemacs tries to pop up a window (saw nothing on this looking at what Fedora and Opensuse have done -> might be Mageia-specific?)

- so far, I have thrown out all patches that were in 21.4.22 - still need to review which of them should be re-diffed into 21.5.34

- I needed to do the build with "with-mule=yes" - otherwise the build fails due to missing Quail (xemacs-leim package) - need to verify the consequences and consistency with policy

- so far, I run the out-of-the-box xemacs, still need to find out why xemacs does not find my customization packages.

I should find some, but rather limited, time to pursue this (and my skills are - more than rather - limited). If / once it works, I guess there should no problem to get xemacs-21.5.34 into Mageia 4 in spite of version freeze since the current xemacs is broken - right?

Is this the right place to discuss building the new version? - looks too specific to go into the dev mailing list.
Comment 4 Juergen Harms 2013-11-08 09:44:42 CET
I have now locally built an xemacs-21.5.34 that does all I need and allows me - finally - to use Mageia-4 pre-releases as my production system.

However the transition from 21.4.22 to 21.5.34 implies changes (at least with respect to customisation (and the typical xemacs user uses xemacs because of customisation) that are non-transparent to the user / to the site. This requires decisions / discussions which go beyond my "xemacs culture" and where the maintainer needs to be involved - for the moment, I will therefore not continue towards a cauldron build.

Using my local build is also a lazy work-around for the find-segfault problem: I have my own menubar, and do not use the vanilla Find button. My principal difficulty looking at this problem is that I did not manage to convince xemacs that I need a core dump - without that, the Find button problem is difficult to tackle.
Comment 5 Juergen Harms 2013-11-12 12:38:26 CET
Created attachment 4503 [details]
fixed Mandriva-customized initialisation file

The bug is due to obsolete statements in the customised initialisation file from Mandriva. Two lines need to be commented out (in this attachment marked as ;;fixed ) - they are the reason for the core dump and are not necessary
Comment 6 Juergen Harms 2013-12-10 12:34:56 CET
Will this bug be fixed before Mageia-4 is released?

In comparison to other distros, a broken xemacs would be a black mark (my local workaround is not fit for general use).
Remco Rijnders 2014-02-05 12:21:18 CET

CC: (none) => remco

Comment 7 David Walser 2014-08-04 17:22:10 CEST
*** Bug 13856 has been marked as a duplicate of this bug. ***

CC: (none) => steve

Comment 8 Marja Van Waes 2015-10-12 15:52:38 CEST
There was no action in this report since over a year ago, is it still valid?

If so, in which Mageia version do you still see it in cauldron and Mageia 5 or only Mageia 5?

re-assigning to BugSquad, because nobody maintains xemacs now.

Not yet CC'ing xemacs-committers, that can still be done if it's still valid

CC: (none) => marja11
Assignee: nanardon => bugsquad
Whiteboard: (none) => NEEDINFO

Comment 9 Dave Hodgins 2015-10-12 17:54:17 CEST
Still valid in Mageia 5 x86_64. I get a lisp backtrace and a segfault. If I
run it under gdb, it doesn't crash, but the editor does not respond to any
mouse or keyboard events.
Comment 10 Dave Hodgins 2015-10-12 17:55:07 CEST
Created attachment 7118 [details]
lisp backtrace
Comment 11 Marja Van Waes 2015-10-13 10:47:38 CEST
(In reply to Dave Hodgins from comment #9)
> Still valid in Mageia 5 x86_64. I get a lisp backtrace and a segfault. If I
> run it under gdb, it doesn't crash, but the editor does not respond to any
> mouse or keyboard events.

(In reply to Dave Hodgins from comment #10)
> Created attachment 7118 [details]
> lisp backtrace

Assuming it still valid for cauldron, too, because nothing happened to xemacs there since long before Mga5 got branched.
http://svnweb.mageia.org/packages/cauldron/xemacs/current/SPECS/xemacs.spec?view=log

Otoh, I don't understand how we can have a mga6 xemacs package in cauldron, if there wasn't even a rebuild after Mga5 was branched.
The packages differ in size, too, on my local mirror:

24592476 Oct 18  2014 xemacs-21.4.22-26.mga5.i586.rpm
24582604 Jul  2 12:51 xemacs-21.4.22-26.mga6.i586.rpm

24632044 Oct 18  2014 xemacs-21.4.22-26.mga5.x86_64.rpm
24631200 Jul  2 12:51 xemacs-21.4.22-26.mga6.x86_64.rpm

What do I miss?

CC'ing some xemacs committers

CC: (none) => fundawang, luigiwalser, mageia, olav, pterjan, thierry.vignaud
Hardware: i586 => All
Source RPM: xemacs-21.4.22-22.mga4.src.rpm => xemacs-21.4.22-26.mga6, xemacs-21.4.22-26.mga5
Whiteboard: NEEDINFO => MGA5TOO

Comment 12 Marja Van Waes 2015-10-13 11:02:16 CEST
found it:

Name        : xemacs                       Relocations: (not relocatable)
Version     : 21.4.22                           Vendor: Mageia.Org
Release     : 26.mga6                       Build Date: Thu Jul  2 12:41:11 2015
Install Date: (not installed)               Build Host: sucuk.mageia.org
Group       : Editors                       Source RPM: (none)
Size        : 41011508                         License: GPLv2+
Signature   : (none)
Packager    : joequant <joequant>

but the only message was:

umeabot <umeabot> 21.4.22-26.mga5:
+ Revision: 742216
- Second Mageia 5 Mass Rebuild

:-(

@ Joseph

What did you push it for?

CC: (none) => joequant

Comment 13 Thierry Vignaud 2015-10-13 11:13:50 CEST
IMHO we should drop xemacs (ake make emacs obsolete it) as it's no more maintained. This is a dead project.
The latest stable version (which we package) is 6+ years old...
Even the latest unstable version is near 3 years old

Or else, do like FC & update to a snapshot:
http://pkgs.fedoraproject.org/cgit/xemacs.git/commit/?id=eac4eb5a41b5d5bdb4c5f7e9f3b198844cd4004c
Comment 14 David Walser 2015-10-13 13:19:28 CEST
Joseph wanted to rebuild it, but abused the fact that the disttag changed and didn't bump the release tag.

I agree with Thierry.  The emacs package should have obsoleted xemacs years ago, when it finally added syntax highlighting by default (22.1?).
Comment 15 Marja Van Waes 2015-10-13 18:18:45 CEST
Well, if no one really wants to grab maintainership and fix it (it does indeed crash in cauldron, too), then I fully agree with obsoleting it.

(Just for the record, when installing it in cauldron, it gives the following error:

      3/4: xemacs                ###################################################################################################
install-info: No such file or directory for /usr/share/info/texinfo.info.xz
install-info: warning: no info dir entry in `/usr/share/info/emodules.info.xz')

btw, when obsoleting it, should _all_ the xemacs packages be obsoleted by emacs?
So:
Obsoletes:      xemacs < 21.4.23
Obsoletes:      xemacs-devel < 21.4.23
Obsoletes:      xemacs-el < 21.4.23
Obsoletes:      xemacs-ess < 12.04.5
Obsoletes:      xemacs-extras < 21.4.23
Obsoletes:      xemacs-mule < 21.4.23
Obsoletes:      xemacs-mule-el < 21.4.23

or should some of them be obsoleted by task-obsolete?
Comment 16 David Walser 2015-10-13 18:23:35 CEST
They should be obsoleted by the appropriate emacs subpackages.  The ones without a match can be obsoleted by the main package or emacs-common.
Comment 17 Marja Van Waes 2015-10-14 10:03:15 CEST
(In reply to David Walser from comment #16)
> They should be obsoleted by the appropriate emacs subpackages.  The ones
> without a match can be obsoleted by the main package or emacs-common.

Thanks, David

@ Shlomi

I'd like to do this next week, _if_ no one grabs maintainership of xemacs with the intention to fix it before Monday, October 19, 00:00h UTC.

However, it looks complicated to my unexperienced packaging mind. 
* There's xemacs-mule, which is for Asian languages and multi-language support, and emacs-leim, for input methods for various international character scripts. I'm not sure leim fully "covers" mule
* the gcl spec, should e.g. the "%if %($(pkg-config xemacs) ; echo $?)", "%package xemacs" etc. parts be removed, or commented out with #s before all lines in those parts?
* I'm not sure either what, apart from letting emacs-ess obsolete xemacs-ess, should be done with all the xemacs-ess related lines in the emacs-ess specfile (it was used to build xemacs-ess, too, until xemacs-ess got its own source package).
* I don't find an equivalent for xemacs-devel, but cannot imagine there are no emacs-devel files

Would you like to help me do it right?

CC: (none) => shlomif

Comment 18 Shlomi Fish 2015-10-14 10:59:31 CEST
Hi Marja,

(In reply to Marja van Waes from comment #17)
> (In reply to David Walser from comment #16)
> > They should be obsoleted by the appropriate emacs subpackages.  The ones
> > without a match can be obsoleted by the main package or emacs-common.
> 
> Thanks, David
> 
> @ Shlomi
> 
> I'd like to do this next week, _if_ no one grabs maintainership of xemacs
> with the intention to fix it before Monday, October 19, 00:00h UTC.
> 

Sounds good - go for it.

> However, it looks complicated to my unexperienced packaging mind. 
> * There's xemacs-mule, which is for Asian languages and multi-language
> support, and emacs-leim, for input methods for various international
> character scripts. I'm not sure leim fully "covers" mule

Well, it is possible that it is covered by the core emacs package.

> * the gcl spec, should e.g. the "%if %($(pkg-config xemacs) ; echo $?)",
> "%package xemacs" etc. parts be removed, or commented out with #s before all
> lines in those parts?

They should be removed. Note that I tried upgrading gcl recently and ran into problems including the fact that I was unable to compile the vanilla source release of GCL on my x86-64 Mageia Cauldron system.

> * I'm not sure either what, apart from letting emacs-ess obsolete
> xemacs-ess, should be done with all the xemacs-ess related lines in the
> emacs-ess specfile (it was used to build xemacs-ess, too, until xemacs-ess
> got its own source package).

I'll have to investigate that.

> * I don't find an equivalent for xemacs-devel, but cannot imagine there are
> no emacs-devel files
> 

maybe there are not.


> Would you like to help me do it right?

sure!
Comment 19 Martin Ward 2015-12-15 21:41:50 CET
The fix for the crash is very simple: add this line to the top of the file ~/.xemacs/init.el (create the file and .xemacs directory if necessary):

  (setq progress-feedback-use-echo-area t)

I have used xemacs with a customised x-symbol package for editing LaTeX files for many years. Please don't remove it from Mageia!

Thanks.

Status: NEW => RESOLVED
CC: (none) => martin
Resolution: (none) => FIXED

Comment 20 Pascal Terjan 2015-12-15 21:45:50 CET
This is not fixed if it crashes when people start it.
If this needs to be disabled it should be done in the package.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Comment 21 Juergen Harms 2015-12-15 23:28:58 CET
Thank you - that is good news.

But I agree, suggesting users to modify their .xemacs/init.el is a workaround, not a fix.

Why not patch the statement suggested in comment #19 into the file 

/etc/emacs/site-start.d/xemacs-init.el

That is where it logically belongs to. It avoids xemacs breaking without requiring users to edit their home directory; and it also works if you launch xemacs as root. Easy to implement as a bug fix: this file comes from source #5 of the xemacs package (site-start-mdk-el), a file that can be directly patched.

And I join your plea for keeping xemacs on board - like probably most old hands using xemacs, I have added lisp functions which I do not want to miss (a compare feature that is much easier to use than diff3). But I am training my fingers to become expert with kwrite, and have an item on my todo list to see whether my  elisp goodies can be made work with plain emacs)
Olav Vitters 2015-12-16 10:32:40 CET

CC: olav => (none)

Comment 22 Martin Ward 2015-12-16 13:55:29 CET
I was a bit premature in declaring the problem "fixed", but Juergen's suggestion to add the line to a system startup file in /etc/emacs/ is a good one!
Comment 23 Juergen Harms 2015-12-24 17:58:13 CET
I withdraw my recommendation to keep xemacs in the Mageia repositories: emacs is now the more mature and flexible tool (beyond the negative arguments re mainting xemacs). Migrating an elisp library from xemacs takes time (2 days for my overly complex library) but is not a major problem. I stopped using my patched xemacs.
Comment 24 Shlomi Fish 2015-12-25 09:38:07 CET
(In reply to Juergen Harms from comment #23)
> I withdraw my recommendation to keep xemacs in the Mageia repositories:
> emacs is now the more mature and flexible tool (beyond the negative
> arguments re mainting xemacs). Migrating an elisp library from xemacs takes
> time (2 days for my overly complex library) but is not a major problem. I
> stopped using my patched xemacs.

Thanks for letting us know. I also think that xemacs should be removed.
Comment 25 Zoltan Balaton 2015-12-29 04:27:14 CET
+1 for keeping and fixing if possible. Here's a backtrace in case it helps:

#0  XDrawLine (dpy=0x176a110, d=20971649, gc=0x2800000014, x1=1, y1=10, x2=248, y2=10) at DrLine.c:50
#1  0x0000000000580e89 in GaugeExpose (w=0x2085980, event=0x1400081, region=0x2800000014) at /usr/src/debug/xemacs-21.4.22/lwlib/xlwgauge.c:427
#2  0x00007ffff6bd5ca4 in SendExposureEvent (event=event@entry=0x7fffffffc020, widget=widget@entry=0x2085980, pd=0x1779178) at Event.c:1128
#3  0x00007ffff6bd7886 in CompressExposures (widget=0x2085980, event=0x7fffffffc020) at Event.c:967
#4  XtDispatchEventToWidget (widget=widget@entry=0x2085980, event=event@entry=0x7fffffffc020) at Event.c:821
#5  0x00007ffff6bd7ddb in _XtDefaultDispatcher (event=0x7fffffffc020) at Event.c:1344
#6  0x00007ffff6bd7f19 in XtDispatchEvent (event=0x7fffffffc020) at Event.c:1423
#7  0x00007ffff6be33e7 in XtAppProcessEvent (app=0x952030, mask=140737488338976) at NextEvent.c:1397
#8  0x0000000000558bc1 in drain_X_queue () at /usr/src/debug/xemacs-21.4.22/src/event-Xt.c:2992
#9  emacs_Xt_event_pending_p (user_p=0) at /usr/src/debug/xemacs-21.4.22/src/event-Xt.c:3117
#10 0x00000000004b2ee4 in event_stream_event_pending_p (user=0) at /usr/src/debug/xemacs-21.4.22/src/event-stream.c:438
#11 Fdispatch_non_command_events () at /usr/src/debug/xemacs-21.4.22/src/event-stream.c:2369
#12 0x000000000047a5ec in Feval (form=form@entry=140737283962872) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3335
#13 0x000000000047697d in condition_case_1 (handlers=<optimized out>, bfun=bfun@entry=0x479ca0 <Feval>, barg=140737283962872, 
    hfun=hfun@entry=0x47b180 <run_condition_case_handlers>, harg=140737283660848) at /usr/src/debug/xemacs-21.4.22/src/eval.c:1652
#14 0x0000000000476a27 in condition_case_3 (bodyform=<optimized out>, var=<optimized out>, handlers=<optimized out>)
    at /usr/src/debug/xemacs-21.4.22/src/eval.c:1730
#15 0x00000000004528a4 in execute_rare_opcode (stack_ptr=0x7fffffffc458, stack_ptr@entry=0x7fffffffc468, 
    program_ptr=program_ptr@entry=0x15c2e94 "\207", opcode=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:1273
#16 0x0000000000453dac in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x7ffff3dba2f8)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:658
#17 0x00000000004541d1 in funcall_compiled_function (fun=140737285618296, nargs=0, args=<optimized out>)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517
#18 0x00000000004785e5 in Ffuncall (nargs=1, args=0x7fffffffc618) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572
#19 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x7ffff3da9438)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748
#20 0x00000000004541d1 in funcall_compiled_function (fun=140737285598376, nargs=4, args=<optimized out>)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517
#21 0x00000000004785e5 in Ffuncall (nargs=5, args=0x7fffffffc7e8) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572
#22 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x7ffff3da9688)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748
#23 0x00000000004541d1 in funcall_compiled_function (fun=140737285598472, nargs=3, args=<optimized out>)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517
#24 0x00000000004785e5 in Ffuncall (nargs=4, args=0x7fffffffc9c8) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572
#25 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x7ffff3d9c410)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748
#26 0x00000000004541d1 in funcall_compiled_function (fun=140737285587384, nargs=4, args=<optimized out>)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517
#27 0x00000000004785e5 in Ffuncall (nargs=5, args=0x7fffffffcb98) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572
#28 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x178fcf0)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748
#29 0x00000000004541d1 in funcall_compiled_function (fun=26043128, nargs=3, args=<optimized out>)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517
#30 0x00000000004785e5 in Ffuncall (nargs=4, args=0x7fffffffcd68) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572
#31 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x179fc10)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748
#32 0x00000000004541d1 in funcall_compiled_function (fun=26042936, nargs=3, args=<optimized out>)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517
#33 0x00000000004785e5 in Ffuncall (nargs=4, args=0x7fffffffcf38) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572
#34 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x17caab0)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748
#35 0x00000000004541d1 in funcall_compiled_function (fun=26042984, nargs=0, args=<optimized out>)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517
#36 0x00000000004785e5 in Ffuncall (nargs=1, args=0x7fffffffd118) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572
#37 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x179fe80)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748
#38 0x00000000004541d1 in funcall_compiled_function (fun=26042792, nargs=0, args=<optimized out>)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517
#39 0x00000000004785e5 in Ffuncall (nargs=1, args=0x7fffffffd2c8) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3572
#40 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x1791460)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748
#41 0x00000000004541d1 in funcall_compiled_function (fun=fun@entry=26042456, nargs=nargs@entry=0, args=args@entry=0x7fffffffd400)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517
#42 0x000000000047a3f7 in Feval (form=24439064) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3392
#43 0x000000000047a6c1 in Fprogn (args=args@entry=24438848) at /usr/src/debug/xemacs-21.4.22/src/eval.c:775
#44 0x000000000047829a in funcall_lambda (fun=24438800, nargs=0, args=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3863
#45 0x000000000047851e in Ffuncall (nargs=1, args=0x7fffffffd6a8) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3580
#46 0x0000000000453aea in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x7ffff3dbf210)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:748
#47 0x00000000004541d1 in funcall_compiled_function (fun=fun@entry=140737285624536, nargs=nargs@entry=0, args=args@entry=0x7fffffffd7d0)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517
#48 0x000000000047a3f7 in Feval (form=form@entry=140737283989536) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3392
#49 0x000000000047697d in condition_case_1 (handlers=<optimized out>, bfun=bfun@entry=0x479ca0 <Feval>, barg=140737283989536, 
    hfun=hfun@entry=0x47b180 <run_condition_case_handlers>, harg=140737283623648) at /usr/src/debug/xemacs-21.4.22/src/eval.c:1652
#50 0x0000000000476a27 in condition_case_3 (bodyform=<optimized out>, var=<optimized out>, handlers=<optimized out>)
    at /usr/src/debug/xemacs-21.4.22/src/eval.c:1730
#51 0x00000000004528a4 in execute_rare_opcode (stack_ptr=0x7fffffffda98, stack_ptr@entry=0x7fffffffdaa8, 
    program_ptr=program_ptr@entry=0x15000c1 "\210\314\r!\025\016.\253\016\332\323\341\016.\342 \343 $!\026\067\344\345!\210\016&\253\005\344\346!\21
0\334\026&\347 \210\016(\253\005\344\350!\210\334\026(\t\253\b\351\t@\tA\"\210)\016\070\255\003\352 \207", opcode=<optimized out>)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:1273
#52 0x0000000000453dac in execute_optimized_program (program=<optimized out>, stack_depth=<optimized out>, constants_data=0x7ffff3dbffa8)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:658
#53 0x00000000004541d1 in funcall_compiled_function (fun=fun@entry=140737285625976, nargs=nargs@entry=0, args=args@entry=0x7fffffffdbd0)
    at /usr/src/debug/xemacs-21.4.22/src/bytecode.c:517
#54 0x000000000047a3f7 in Feval (form=form@entry=140737283836200) at /usr/src/debug/xemacs-21.4.22/src/eval.c:3392
#55 0x000000000047697d in condition_case_1 (handlers=<optimized out>, bfun=0x479ca0 <Feval>, barg=140737283836200, 
    hfun=hfun@entry=0x45c650 <cmd_error>, harg=140737283664160) at /usr/src/debug/xemacs-21.4.22/src/eval.c:1652
#56 0x000000000045c26d in top_level_1 (dummy=dummy@entry=140737283664160) at /usr/src/debug/xemacs-21.4.22/src/cmdloop.c:206
#57 0x00000000004753cc in internal_catch (tag=<optimized out>, func=func@entry=0x45c240 <top_level_1>, arg=140737283664160, threw=threw@entry=0x0)
    at /usr/src/debug/xemacs-21.4.22/src/eval.c:1318
#58 0x000000000045c7c0 in initial_command_loop (load_me=<optimized out>) at /usr/src/debug/xemacs-21.4.22/src/cmdloop.c:285
#59 0x0000000000473976 in xemacs_21_4_22_x86_64_mageia_linux (argc=1, argv=0x7fffffffe198, envp=<optimized out>, restart=restart@entry=0)
    at /usr/src/debug/xemacs-21.4.22/src/emacs.c:2460
#60 0x0000000000444a6d in main (argc=<optimized out>, argv=<optimized out>, envp=0x7fffffffe1a8) at /usr/src/debug/xemacs-21.4.22/src/emacs.c:2829

It seems to crash in an X call during updating the progress bar while fontifying the buffer. (There was a progress bar displayed at the bottom previously when it worked.)

CC: (none) => balaton

Comment 26 Shlomi Fish 2015-12-29 11:44:13 CET
Hi Zoltan,

(In reply to Zoltan Balaton from comment #25)
> +1 for keeping and fixing if possible. Here's a backtrace in case it helps:
> 

-1 for keeping xemacs, because the upstream project is unmaintained. Please either switch to GNU Emacs or alternatively build a working xemacs snapshot locally which you can maintain (and use it at your own risk).

Regards,

-- Shlomi Fish
Comment 27 Juergen Harms 2016-01-03 18:13:06 CET
After consulting the documentation group, I am starting to write a short summary of what I (re-)learned on customization of elisp warts. While it is being drafted, it can be found (and commented on) at 

https://wiki.mageia.org/en/User:Jharms/Migrating_from_Xemacs_to_Emacs

Hopefully that will help to minimise the effort needed for porting customization code from xemacs to emacs.
Comment 28 Shlomi Fish 2016-01-03 18:38:50 CET
(In reply to Juergen Harms from comment #27)
> After consulting the documentation group, I am starting to write a short
> summary of what I (re-)learned on customization of elisp warts. While it is
> being drafted, it can be found (and commented on) at 
> 
> https://wiki.mageia.org/en/User:Jharms/Migrating_from_Xemacs_to_Emacs
> 
> Hopefully that will help to minimise the effort needed for porting
> customization code from xemacs to emacs.

that's great! Many thanks for your effort!
Comment 29 Juergen Harms 2016-01-12 22:09:31 CET
The page is now ready - still in my user space at

https://wiki.mageia.org/en/User:Jharms/Quick_guide_to_customizing_Emacs

will be moved to the official pages in a couple of days. It has become a guide to customization rather then a migration guide, but that is what such a document needs to be.
Comment 30 Shlomi Fish 2016-01-13 20:28:54 CET
(In reply to Juergen Harms from comment #29)
> The page is now ready - still in my user space at
> 
> https://wiki.mageia.org/en/User:Jharms/Quick_guide_to_customizing_Emacs
> 
> will be moved to the official pages in a couple of days. It has become a
> guide to customization rather then a migration guide, but that is what such
> a document needs to be.

Many thanks!
Comment 31 Marja Van Waes 2016-02-09 08:20:52 CET
(In reply to Juergen Harms from comment #29)
> The page is now ready - still in my user space at
> 
> https://wiki.mageia.org/en/User:Jharms/Quick_guide_to_customizing_Emacs
> 
> will be moved to the official pages in a couple of days. It has become a
> guide to customization rather then a migration guide, but that is what such
> a document needs to be.

Juergen moved the page to where it belongs:

https://wiki.mageia.org/en/Guide_to_customizing_Emacs

:-D

Sorry for not yet having worked on obsoleting Xemacs, as I said I would. Overestimating how much time I have is a trap I keep falling in :-(
Comment 32 Remco Rijnders 2016-02-09 08:26:45 CET
Of interest here, irt the status of xemacs, might be the following message and its assorted follow-ups: http://list-archive.xemacs.org/pipermail/xemacs-beta/2015-November/025919.html
Comment 33 ben mcmonagle 2016-02-09 20:02:46 CET
(In reply to Shlomi Fish from comment #24)
> (In reply to Juergen Harms from comment #23)
> > I withdraw my recommendation to keep xemacs in the Mageia repositories:

> 
> Thanks for letting us know. I also think that xemacs should be removed.

Currently Xemacs crashes on launch in Cauldron [Mga6-dev1], both x86 and i586.
The x86 .iso is in excess of 4Gb
As this package is no longer receiving support, please remove it.

CC: (none) => westel

Comment 34 Marja Van Waes 2016-02-11 07:04:09 CET
(In reply to Remco Rijnders from comment #32)
> Of interest here, irt the status of xemacs, might be the following message
> and its assorted follow-ups:
> http://list-archive.xemacs.org/pipermail/xemacs-beta/2015-November/025919.
> html

Thanks, Remmy, there were indeed many replies (which I won't read, though)

I'll work on letting emacs obsolete xemacs today, but won't remove things from spec files that are or might be needed again if we decide xemacs is good enough to reimport.

Question 1, wrt the obsoleting:
Why is xemacs-ess still here http://svnweb.mageia.org/packages/cauldron/xemacs-ess/
when emacs-ess already obsoleted it
http://svnweb.mageia.org/packages/cauldron/emacs-ess/current/SPECS/emacs-ess.spec?revision=892500&view=markup 

(If if umeabot bumps xemacs-ess release, the obsoletes will no longer work.... or can that not happpen?)
Comment 35 Rémi Verschelde 2016-02-11 09:50:17 CET
Obsoleting packages in the spec file removed them from the mirrors, but does not touch the SVN repo.

You need to move it manually to the obsolete section:

$ svn mv svn+ssh://svn.mageia.org/svn/packages/cauldron/xemacs-ess svn+ssh://svn.mageia.org/svn/packages/obsolete/xemacs-ess
Comment 36 Marja Van Waes 2016-02-13 10:18:32 CET
xemacs and all related packages are obsolete in cauldron, now, so closing as WONTFIX.

However, this decision isn't cut in stone: if a Mageia packager finds that upstream revives the project well, and if he wants to import a new working version and _maintain_ it, then it is unlikely that we'll stop him.

Status: REOPENED => RESOLVED
Resolution: (none) => WONTFIX


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