2:29 a.m.
The XEmacs Packages CVS repository has been restructured. And as of
midnight (GMT+10), Sunday July 8th, 2001, the old packages tree will
no longer be open for commits.
The new tree can be checked out of CVS with:
cvs -d :pserver:xemacs＠cvs.xemacs.org:/usr/CVSroot login
(password is zawinski)
And then:
cvs -d :pserver:xemacs＠cvs.xemacs.org:/usr/CVSroot co packages
(to grab everything)
cvs -d :pserver:xemacs＠cvs.xemacs.org:/usr/CVSroot co package-standard
(to grab all the standard (aka non-Mule) packages)
cvs -d :pserver:xemacs＠cvs.xemacs.org:/usr/CVSroot co package-mule
(to grab all the mule packages)
Individual packages can be checked out with:
cvs -d :pserver:xemacs＠cvs.xemacs.org:/usr/CVSroot co <packagename>
For example, to check out a copy of Gnus:
cvs -d :pserver:xemacs＠cvs.xemacs.org:/usr/CVSroot co gnus
The way things were:
./xemacs-packages/
|
|---/comm/
| |---/gnus/
|
|---/libs/
| |---/efs/
| |---/xemacs-base/
|
|---/mule/
|---/mule-base/
The *NEW* layout:
./packages/
|
|---/mule-packages/
| |---/mule-base/
|
|---/xemacs-packages/
|---/gnus/
|---/efs/
|---/xemacs-base/
So, basically, if it is a Mule package it will be under
./mule-packages/ and if it's not, it'll be under ./xemacs-packages/
If you have any problems or questions, feel free to contact me
directly.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
6:59 a.m.
Steve Youngs <youngs(a)xemacs.org> writes:
Hi Steve!
The XEmacs Packages CVS repository has been restructured. And as of
midnight (GMT+10), Sunday July 8th, 2001, the old packages tree will
no longer be open for commits.
The new tree can be checked out of CVS with:
Is the new procedure supposed to be working out of CVS? I see the
following error after a fresh checkout
nk＠lamia:packages$ gmake install
xemacs -vanilla -batch -l package-clean.el
Cannot open load file: package-clean.el
xemacs exiting
.
gmake: *** [elcclean] Error 255
Thanks,
norbert.
--
When you said ``HEAVILY FORESTED'' it reminded me of an overdue
CLEANING BILL.. Don't you SEE? O'Grogan SWALLOWED a VALUABLE
COIN COLLECTION and HAD to murder the ONLY MAN who KNEW!!
2:51 p.m.
|--==> "viteno" == Norbert Koch <nk(a)LF.net> writes:
viteno> Is the new procedure supposed to be working out of CVS? I see the
viteno> following error after a fresh checkout
viteno> nk＠lamia:packages$ gmake install
viteno> xemacs -vanilla -batch -l package-clean.el
viteno> Cannot open load file: package-clean.el
viteno> xemacs exiting
viteno> .
viteno> gmake: *** [elcclean] Error 255
Hi Norbert,
Yes it is supposed to be working. Do a 'cvs update' and see if you
get the file 'package-clean.el'.
I have fixed the CVS modules file so that this doesn't happen anymore.
Thanks very much for letting me know about this.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
8:22 p.m.
Steve Youngs <youngs(a)xemacs.org> writes:
Hi Steve,
Yes it is supposed to be working. Do a 'cvs update' and see
if you
get the file 'package-clean.el'.
I have fixed the CVS modules file so that this doesn't happen anymore.
Thanks, this seems to work. Now, I see the following error:
Wrote
/usr/local/users/support/nk/cvs/packages/xemacs-packages/eicq/custom-load.elc
Done
xemacs -batch -l ./infohack.el -f batch-makeinfo eicq.texi
Cannot open load file: texinfmt
xemacs exiting
.
gmake[2]: *** [texinfo] Error 255
gmake[2]: Leaving directory
`/usr/local/users/support/nk/cvs/packages/xemacs-packages/eicq'
gmake[1]: *** [eicq/bytecompile.target] Error 2
gmake[1]: Leaving directory
`/usr/local/users/support/nk/cvs/packages/xemacs-packages'
gmake: *** [xemacs-packages/bytecompile.target] Error 2
I'm not sure why it's using xemacs to create this info file, because
most of the rest is done using makeinfo (GNU texinfo) 4.0.
If I leave my old installed packages installed (make install from
older CVS sources) I don't see this error, ietexinfmt is found as
../lib/xemacs/xemacs-packages/lisp/texinfo/texinfmt.elc
but no new packages are installed (the symlinks are pointing to the
old location).
I don't even want eicq [a] (I'm running on FreeBSD anyway), thus I
wonder why it's build at all.
norbert.
Footnotes:
[a] please forgive as you are the maintainer, AFAIK ;-)
12:55 a.m.
|--==> "viteno" == Norbert Koch <nk(a)LF.net> writes:
viteno> Thanks, this seems to work. Now, I see the following error:
viteno> Wrote
viteno>
/usr/local/users/support/nk/cvs/packages/xemacs-packages/eicq/custom-load.elc
viteno> Done
viteno> xemacs -batch -l ./infohack.el -f batch-makeinfo eicq.texi
viteno> Cannot open load file: texinfmt
viteno> xemacs exiting
Fixed in CVS.
viteno> I'm not sure why it's using xemacs to create this info file, because
viteno> most of the rest is done using makeinfo (GNU texinfo) 4.0.
Two reasons:
1) makeinfo barfs on eicq.texi
2) I'd rather XEmacs do it.
viteno> I don't even want eicq [a] (I'm running on FreeBSD anyway), thus I
viteno> wonder why it's build at all.
Which make target are you using? A 'make bindist' from ./packages/
will build all packages because it doesn't look at
[XEMACS|MULE]_PACKAGES in Local.rules.
Only 'make install' looks at those vars. This is definitely something
that needs to be addressed.
viteno> Footnotes:
viteno> [a] please forgive as you are the maintainer, AFAIK ;-)
I'll forgive you, just this once. :-) Seriously though, if you'd like
to try Eicq, there's a FreeBSD patch available. I can't attest to
it's workability (don't have access to a FreeBSD box).
Contact me if you want the patch.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
6:35 a.m.
Steve Youngs <youngs(a)xemacs.org> writes:
Hi!
viteno> xemacs -batch -l ./infohack.el -f batch-makeinfo
eicq.texi
viteno> Cannot open load file: texinfmt
viteno> xemacs exiting
Fixed in CVS.
Hmm, I still get the same error. I see, you've added the
dependency. Hmm.... does xemacs know where to look for the load file,
ie do you append newly built package subtrees to the load-path?
viteno> I'm not sure why it's using xemacs to create this
info
Two reasons:
1) makeinfo barfs on eicq.texi
2) I'd rather XEmacs do it.
Point taken :-)
Only 'make install' looks at those vars. This is definitely
something
that needs to be addressed.
I'm trying to perform a make install. This should override all
existing links (I'm using symlink = t), shouldn't it?
I'll forgive you, just this once. :-) Seriously though, if
you'd like
to try Eicq, there's a FreeBSD patch available. I can't attest to
it's workability (don't have access to a FreeBSD box).
Presently, I don't have need for it, but if you want I can test your
patch.
norbert.
8:04 a.m.
|--==> "viteno" == Norbert Koch <nk(a)LF.net> writes:
viteno> Steve Youngs <youngs(a)xemacs.org> writes:
viteno> Hi!
viteno> xemacs -batch -l ./infohack.el -f batch-makeinfo eicq.texi
viteno> Cannot open load file: texinfmt
viteno> xemacs exiting
>
>Fixed in CVS.
viteno> Hmm, I still get the same error.
It's really fixed this time, honest. :-)
>Only 'make install' looks at those vars. This is
definitely something
>that needs to be addressed.
viteno> I'm trying to perform a make install. This should override all
viteno> existing links (I'm using symlink = t), shouldn't it?
If I'm reading you right, yes. I'll look into it after the Sumo
release this weekend.
>I'll forgive you, just this once. :-) Seriously though, if
you'd like
>to try Eicq, there's a FreeBSD patch available. I can't attest to
>it's workability (don't have access to a FreeBSD box).
viteno> Presently, I don't have need for it, but if you want I can test your
viteno> patch.
Thanks for the offer, I'll keep it in mind.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
8333
days inactive
8334
days old
6 comments
2 participants
participants (2)
-
Norbert Koch -
Steve Youngs