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 …
[View More]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.
[View Less]
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", …
[View More]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?
[View Less]
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.
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 …
[View More]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.
[View Less]
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.
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 …
[View More]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.
[View Less]
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-…
[View More]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)
[View Less]
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 …
[View More]-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
[View Less]
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..…
[View More].
> ...
> 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.
[View Less]
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.
…
[View More]:-) 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? ;-)
[View Less]