May 1999 - XEmacs-Beta - XEmacs Mailing List Archives

SL Baur

Peter B West <p.west(a)uq.net.au> writes in xemacs-beta(a)xemacs.org: > Once upon a time in the mythological past, I could `make distclean; make > bindist' in my xemacs-packages directory, and a directory structure with > all of the files and the gzipped packages would appear in my staging > directory. This is not now working. Is this to be expected, or do I > have some kind of configuration problem with my packages, possibly > related to the fact that I do not have a complete set of the packages, > and so I do not habitually do a `cvs update -d -P', which restores > everything I have carefully blown away? It is working (I use that target to populate the packages directory on ftp.xemacs.org), but I only use it on a package-by-package basis. The package build scripts were intended to support your kind of configuration -- eg. missing packages should be skipped and not cause anything to fail. It's possible that isn't working now. Do you recall the last time this worked for you? Also, what exactly do you mean by "not working"? > Is there, btw, a way to say "just get any new directories and files > within the packages that already exist here"? I don't think so. There ought to be an easy script to do it though.

2 participants
1 comments

Re: cvs access for XEmacs 21.2.* 25 years, 6 months

SL Baur

Hrvoje Niksic <hniksic(a)srce.hr> writes in xemacs-beta(a)xemacs.org: > tor(a)spacetec.no (Tor Arntsen) writes: >> On May 2, 21:36, Hrvoje Niksic wrote: >> >This is quite strange -- it is customary for the unstable code to be >> >HEAD, with the stable releases tagged as branches, so I hope it will >> >be changed in the future. >> >> What practice to use varies wildly. > By "customary" I meant "in use in other free software projects", at > least those I know of. GNOME, for instance. GNOME used branch as stable, then switched it to default as stable when too many people got confused -- this was around last December/January. Have they changed this around again?

2 participants
1 comments

probable bug in avoid.el 25 years, 6 months

Kyle Jones

This is an avoid.el bug report, ubfortunately it's for 20.3. Needs to be verified for the current XEmacs version and maybe fixed. Posted here for tracking and maybe sparking the interest of a volunteer.

1 participants
0 comments

Re: inconsistency in iso-acc.el 25 years, 6 months

SL Baur

This change is O.K. with me. Tudor Hulubei <tudor(a)cs.unh.edu> writes in xemacs-beta(a)xemacs.org: > Hi, > The following 3 lines should be added to iso-acc.el in the "latin-2" > mapping in order to fix an inconsistency in the way characters with a > cedilla under them are inserted. The affected characters are the > romanian "s" and "t" (with a cedilla). > Currently, these characters can be inserted by prefixing them with a > backquote, even though they should be prefixed with a comma, just like > the french "c" with a cedilla is. > (?, (?S . ?\252) (?T . ?\336) > (?s . ?\272) (?t . ?\376) > (?\ . ?,)) > I would suggest leaving the backquote based sequences in place, for > those people who already got used to them.

1 participants
0 comments

Re: XEmacs 21.1.2 "20 Minutes to $BF|8w(B" is released 25 years, 6 months

SL Baur

Soren Dayton <csdayton(a)cs.uchicago.edu> writes in xemacs-beta(a)xemacs.org: > I'm not quite understanding. is this meant to be a "stable" release > that is not beta? Yes. > Is this going to be announced on comp.emacs.xemacs? Yes.

1 participants
0 comments

Re: package-get & md5 25 years, 6 months

SL Baur

Petr Konecny <pekon(a)ams.sunysb.edu> writes in xemacs-beta(a)xemacs.org: ... > I wonder what this is supposed to do: > xemacs -vanilla -eval ' > (progn > (set-language-environment "Latin-2") > (with-temp-file "/tmp/apel-copy" > (insert-file-contents-internal "/tmp/apel-1.11-pkg.tar.gz")) > (save-buffers-kill-emacs))' Read in the tar file and assume Latin-2[1] encoding? > For me the created file (/tmp/apel-copy) is bigger than the > original. Maybe insert-file-contents-internal is broken, because > with insert-file-contents-literally the copies are same. insert-file-contents-internal is supposed to do encoding and insert-file-contents-literally is not, so I think this behavior is O.K. Compare this: $ xemacs -vanilla -eval ' (progn (set-language-environment "Latin-2") (with-temp-file "/tmp/apel-copy" (set-buffer-file-coding-system (quote binary)) (insert-file-contents-internal "/tmp/apel.tar.gz")) (save-buffers-kill-emacs))' Footnotes: [1] Whatever the default encoding of /tmp/apel-copy is supposed to be.

1 participants
0 comments

Re: Core Dump Using Gnus 25 years, 6 months

SL Baur

Gunnar Evermann <ge204(a)cus.cam.ac.uk> writes in xemacs-beta(a)xemacs.org: > On Mon, 10 May 1999, Gunnar Evermann wrote: >> On Mon, 10 May 1999, Alastair Burt wrote: >> >> > When reading an article with Gnus, XEmacs (21.0 - beta(?)67) dumps core >> >> This bug has probably been fixed recently by tomo's patch. > Alas I spoke too soon. both 21.0 and the latest and greatest > 21.2.13-as-of-yesterday [1] crash. > try this: > (decode-coding-string " \232 " 'koi8-r) O.K. Good, we have a short and sweet test case. This isn't fixed by Moriokasan's patch. XEmacs 21.2.14 doesn't crash for me, but it goes into a hard uninterruptible loop. 21.1.2 crashes as you describe it. > the old crash which tomo fixed had a \207 in that place. > I get: > Fatal error: assertion failed, file > /home/tigger3/ge204/src/XEmacs/xemacs/src/insdel.c, line 364, > VALID_CHARPTR_P (ptr)

1 participants
0 comments

New mailcrypt status -- GNUPG-0.9.6 is broken 25 years, 6 months

SL Baur

I will be replacing the old mailcrypt with the new mailcrypt just as soon as I have working GNUPG binaries. I need it to compile on DEC Alpha running OSF 4.0 and BSDI 3.0, unfortunately the latest GNUPG seems to be broken on both of those platforms. The error messages in case anyone can offer me some advise are attached. In both cases I did a default ./configure; make. The Alpha is using egcs-1.1.1, and the BSDI box is using gcc-2.7.2.1. Dec Alpha: gcc -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -o gpg g10.o build-packet.o compress.o free-packet.o getkey.o delkey.o pkclist.o skclist.o ringedit.o kbnode.o mainproc.o armor.o mdfilter.o textfilter.o cipher.o misc.o openfile.o keyid.o trustdb.o tdbdump.o tdbio.o hkp.o parse-packet.o passphrase.o pubkey-enc.o seckey-cert.o seskey.o import.o export.o comment.o status.o sign.o plaintext.o encr-data.o encode.o revoke.o keylist.o sig-check.o signal.o helptext.o verify.o decrypt.o keyedit.o dearmor.o keygen.o ../cipher/libcipher.a ../mpi/libmpi.a ../util/libutil.a ../intl/libintl.a -lc -lz /usr/bin/ld: Unresolved: _OtsMove calloc collect2: ld returned 1 exit status make[2]: *** [gpg] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 BSDI 3.0: ... gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../intl -g -O2 -Wall -Wcast-align -Wshadow -Wstrict-prototypes -DIS_MODULE -shared -fPIC -lc -o rndlinux ./rndlinux.c rndlinux.c:183:invalid character '[' in first operand rndlinux.c:190:invalid character '＠' in first operand rndlinux.c:197:invalid character '＠' in first operand rndlinux.c:199:invalid character '＠' in first operand rndlinux.c:202:invalid character '＠' in first operand rndlinux.c:204:invalid character '＠' in first operand rndlinux.c:211:invalid character '＠' in first operand rndlinux.c:216:invalid character '＠' in first operand rndlinux.c:218:invalid character '＠' in first operand rndlinux.c:221:invalid character '＠' in first operand rndlinux.c:223:invalid character '＠' in first operand rndlinux.c:232:invalid character '＠' in first operand rndlinux.c:234:invalid character '＠' in first operand rndlinux.c:287:invalid character '[' in first operand rndlinux.c:296:invalid character '＠' in second operand rndlinux.c:300:invalid character '＠' in first operand rndlinux.c:302:invalid character '＠' in first operand rndlinux.c:303:invalid character '＠' in second operand rndlinux.c:307:invalid character '＠' in first operand rndlinux.c:313:invalid character '＠' in second operand rndlinux.c:317:invalid character '＠' in first operand rndlinux.c:319:invalid character '＠' in first operand rndlinux.c:320:invalid character '＠' in second operand rndlinux.c:324:invalid character '＠' in first operand rndlinux.c:340:invalid character '＠' in first operand rndlinux.c:362:invalid character '＠' in first operand rndlinux.c:371:invalid character '＠' in first operand rndlinux.c:373:invalid character '＠' in first operand rndlinux.c:374:invalid character '＠' in first operand rndlinux.c:387:invalid character '＠' in first operand rndlinux.c:389:invalid character '＠' in first operand rndlinux.c:391:invalid character '＠' in first operand rndlinux.c:393:invalid character '＠' in first operand rndlinux.c:394:invalid character '＠' in first operand rndlinux.c:413:invalid character '＠' in first operand rndlinux.c:423:invalid character '＠' in first operand rndlinux.c:425:invalid character '＠' in first operand rndlinux.c:435:invalid character '＠' in first operand rndlinux.c:441:invalid character '＠' in first operand rndlinux.c:443:invalid character '＠' in first operand rndlinux.c:445:invalid character '＠' in first operand rndlinux.c:469:invalid character '＠' in first operand rndlinux.c:529:invalid character '[' in first operand rndlinux.c:548:invalid character '＠' in first operand rndlinux.c:551:invalid character '＠' in first operand rndlinux.c:555:invalid character '＠' in first operand make[2]: *** [rndlinux] Error 1 make[2]: Leaving directory `/usr2/home/steveb/gnupg-0.9.6/cipher' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr2/home/steveb/gnupg-0.9.6' make: *** [all-recursive-am] Error 2

1 participants
0 comments

Re: [Failure] 21.2b14 25 years, 6 months

SL Baur

I (still) don't see this. nbecker <nbecker(a)fred.net> writes in xemacs-beta(a)xemacs.org: > 21.2b14 --no-mule i686-pc-linux-gnu > Even manually fixing the scripts so that mule is detected as NIL, > removing all .elc's from the source directory and rebuilding from > scratch, C-x m gives: > Symbol's value as variable is void: mime-charset-coding-system-alist > Loading message... > PGP version set to GPG. > Loading mc-setversion...done > Loading mc-setversion... > ... > Where is the mime-charset... coming from? Is this mule-related? Sort of, it's defined in a file that states it requires an XEmacs with Mule, although I don't see it referenced any place else. How did you install APEL? Did you install it from the -pkg.tar.gz on ftp.xemacs.org, or did you build it yourself? Could you please get a lisp stack backtrace by doing (setq debug-on-error t) and reproducing the error? Thanks.

1 participants
0 comments

Re: 21.2.14 and the future 25 years, 6 months

SL Baur

P E Jareth Hein <jareth(a)camelot.co.jp> writes in xemacs-beta(a)xemacs.org: > On Fri, May 14, 1999 at 03:43:28PM +0100, nic(a)niss.ac.uk scribbled: >> Am I just being dense here, or is the clock on Steve's computer a day ahead? >> >> gristle $ ls -l info/internals.info >> -rw-r--r-- 1 ccsnjd ccsnjd 6186 May 14 15:52 info/internals.info >> gristle $ date >> Fri May 14 15:34:35 BST 1999 >> nic - who gets a bit confused by timezones. :-) Me too. > Nope. He is now over on my side of the puddle, That's the Pacific puddle, not the Atlantic, btw. > instead of yours... JST (Japan Standard Time) is GMT-9. (UT +0900) To add further confusion, cvs.xemacs.org is in California (UT -0700) but its system clock is about eight hours (~7 hours, 40 minutes) fast. ftp.xemacs.org is on the east coast of the US (UT -0400). Clear now? ;-)

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta May 1999