Up and running again

[Stephen J. Turnbull]

Mats Lidell writes:
 > >>>>> Stephen J Turnbull <stephen at xemacs.org> writes:
 > 
 > Stephen> This is a bug of some kind in XEmacs or the OS.  However, it
 > Stephen> looks like you could workaround with this patch to the
 > Stephen> Makefile in the apel package:
 > 
 > Something that should be checked in permanently? I don't fancy
 > patching the sources in the smoketest. (Or are you suggesting that I
 > test this and then we check it in?)

I'm suggesting you test it.  In theory it shouldn't help, but if
XEmacs is buggy, it might.

 > Somewhat related: Some how I have got the impression that the apel
 > package is on its way out?

Not really.  Use of APEL is not recommended because of installations
that share packages among XEmacs versions.  The problem is that it
optimizes for the version building the APEL package at build time,
while compiling APEL.  However, packages that currently use APEL are
pretty dependent on it for backward compatibility.

 > Stephen> Lather, rinse, repeat for any further packages that load
 > Stephen> xemacs-base autoloads before fsf-compat autoloads.
 > 
 > ... and then update all packages?

You mean, submit patches and commit?  Yes, I think.  I'm more
interested in the TTY-related bug, but I see your point -- the smoke
test should be a straight checkout.  No patches.

 > Stephen> As far as the 21.5 builds go, it appears that your XEmacs
 > Stephen> doesn't know about the 'x specifier tag.  What does
 > Stephen>     xemacs -batch -eval "(memq 'x (specifier-tag-list))" -kill
 > Stephen> say?
 > 
 > Hmm... Well it seems to know about the tag alright but the machine is
 > a pure server, no X installed. Could that have something to do with
 > it?

It shouldn't, but it easily could.  In the past, the tag wasn't
defined if X support was not present in XEmacs (IIRC, Aidan fixed
that, thanks Aidan) but it's quite possible that the missing tag has
been hiding a bug, which now bites you (or at least bites the smoke
test).