3:10 p.m.
|--==> "UB" == Uwe Brauer <oub(a)ucmail.ucm.es>
writes:
UB> Hi The issue of *new* packages reminds me: I suggested to
UB> include x-symbol (which already is distributed in package form)
UB> in the main distribution.
UB> What is the state of art?
It's on my todo list. Just haven't got to it yet.
Any news on this?
Uwe
3:48 p.m.
|--==> "UB" == Uwe Brauer <oub(a)ucmail.ucm.es> writes:
>It's on my todo list. Just haven't got to it yet.
UB> Any news on this?
Still on my todo list. But now that you've reminded me perhaps I
should give it a boost in priority.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
3:50 p.m.
Steve Youngs <youngs(a)xemacs.org> writes:
|--==> "UB" == Uwe Brauer <oub(a)ucmail.ucm.es>
writes:
>>It's on my todo list. Just haven't got to it yet.
UB> Any news on this?
Still on my todo list. But now that you've reminded me perhaps I
should give it a boost in priority.
Recall it is already in pkg format (3rd party), however I have not
fully understood so far package theory in order to judge whether this
is enough.
11:55 p.m.
|--==> "UB" == Uwe Brauer <oub(a)ucmail.ucm.es> writes:
UB> Recall it is already in pkg format (3rd party), however I have not
UB> fully understood so far package theory in order to judge whether this
UB> is enough.
I vaguely remember that there was something about it that made not
quite a straight forward drop in. I'll see if I can get to it this
weekend.
A question for you, Uwe (which I've probably already asked you),
We'll be approaching the xsymbol author to see if he/she wants to
maintain the XEmacs package version, if they decline would you be
willing to step up to the plate?
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
4 p.m.
Steve Youngs <youngs(a)xemacs.org> writes:
I vaguely remember that there was something about it that made not
quite a straight forward drop in. I'll see if I can get to it this
weekend.
A question for you, Uwe (which I've probably already asked you), We'll
be approaching the xsymbol author to see if he/she wants to maintain
the XEmacs package version, if they decline would you be willing to
step up to the plate?
I have to discuss this with Christoph of course; in principle yes,
however I consider x-symbol as a rather sophisticate package quite
beyond my lisp knowledge and I am not sure that I am qualified for this.
3:01 a.m.
>>>> "Uwe" == Uwe Brauer
<oub(a)ucmail.ucm.es> writes:
Uwe> I have to discuss this with Christoph of course; in principle
Uwe> yes, however I consider x-symbol as a rather sophisticate
Uwe> package quite beyond my lisp knowledge and I am not sure that
Uwe> I am qualified for this.
I think you're misunderstanding the role of the third party maintainer
here.
XEmacs would prefer that there be _no_ changes from the upstream
distribution, that everything be done in the Makefile. So in theory
it should just be a matter of
cd $package
cvs update -A
cvs -d $UPSTREAM_CVSROOT update -j upstream_release
# edit Makefile to update AUTHOR_VERSION and maybe REQUIRES
# maybe resolve some conflicts in ChangeLogs and stuff.
cvs commit
In practice it's often necessary to maintain an upstream tree and an
XEmacs tree, but otherwise not much different.
So what do we need you for? To decide when this needs to be done!
Some packages change daily, and weekly XEmacs CVS updates are not out
of the question. Others haven't had an "official release" in years,
but the people who follow the package have been using the "beta"
version with no problems almost that long, and it is now significantly
divergent (this is the AUC-TeX situation AFAIK). You _care_ about
that package, you already know improvements are available, you know
what problems people have had. _You_ have a lot of expertise. To
acquire that would cost Ville or Rendhalver or me a _lot_ of time!
If there are problems with the code itself, either the upstream
maintainer or we can usually help with that. It's the stuff that is
_so obvious_ to you ("the need") that we don't have time to deal
with. It's also a big help if you do the routine merging (ie,
typically ChangeLogs have conflicts because the XEmacs version will
have XEmacs package release heralds in it, but of course upstream
doesn't).
Please consider it; it's not as hard as you think, I believe, and the
problems you are worried about are exactly the ones that we are best
at helping with.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7:13 p.m.
New subject: AUCTeX (was: Re xsymbol included in the SUMO tar ball)
Stephen J. Turnbull writes:
>>>>> "Uwe" == Uwe Brauer
<oub(a)ucmail.ucm.es> writes:
Uwe> I have to discuss this with Christoph of course; in principle
Uwe> yes, however I consider x-symbol as a rather sophisticate
Uwe> package quite beyond my lisp knowledge and I am not sure that
Uwe> I am qualified for this.
I think you're misunderstanding the role of the third party maintainer
here.
Hello
I already told Ville, that I would volunteer maintaining the AUCTeX
package since it is very outdated; concerning preview-latex and
x-symbol let us put them aside for the moment.
However I would, at least, partially understand what I am doing, so
here are a couple of questions, some are of technical, some of
'political' nature (some of my questions will be very basic, but I
never really worked for example with cvs)
1. The relation between 3rd party packages and offical one: You
already wrote that it is important were such package are generated,
however you said, a package could be installed in
/prefix/xemacs/xemacs-package
or
~/.xemacs/xemacs-package
or
/prefix/xemacs/site-packages
If so why does Christophs Makefile contain the line
PACKAGEDIR = $(HOME)/.xemacs/xemacs-packages
(his package is supposed to be installed in this directory)
but I could not find such a target in the Makefiles of the CVS, I
downloaded (see below)
Political question: suppose I generated a new AUCTeX package could
this also be put on the official AUCTeX page or is there a danger that
it will be considered as a 3rd party pkg and installed in
~/.xemacs/xemacs-packages
2. I tried first to built up the existing 1.33 AUCTeX package, based on
10g, before going to the 11.13 version, I want to be sure that I
did correctly
I first downloaded the cvs tree, by
cvs -d:pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs login
cvs -f -z3 -d:pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs checkout -P xemacsweb
cd xemacsweb/
cvs co packages
cvs co package-control
cd packages/
cvs co xemacs-base
cd xemacs-base/
make
cd ..
cd auctex/
make
It did not work for my 21.4.12 no mule version!!! I frequently download
and compile AUCTeX myself and never had this kind of problem. While
xsymbol detects whether a mule or no-mule version is used, I am not so
sure about AUCTeX, I have to ask David, but I want to know whether a
-with-no-mule compiled AUCTeX would run under mule and vice
versa. I expect that a -with-mule compiled AUCTeX would run with no
mule and *not* vice versa.
I personally don't use Mule, but think the AUCTeX should be compiled
such that it is usable for both.
3. The make process worked for xemacs-21.4.12 with mule, but no
binball was generated. I thought the generated binball would be in
/tmp/stagging??
4. Windows version. Can the generated AUCTeX package be used for the
Win9x/NT/2000/etc version of Xemacs or do I have to compile another
one??
Regards
Uwe
8:06 p.m.
New subject: AUCTeX (was: Re xsymbol included in the SUMO tar ball)
On Fri, 2003-01-31 at 21:13, Uwe Brauer wrote:
However I would, at least, partially understand what I am doing,
so
here are a couple of questions, some are of technical, some of
'political' nature (some of my questions will be very basic, but I
never really worked for example with cvs)
Fair enough :)
1. The relation between 3rd party packages and offical one: You
already wrote that it is important were such package are generated,
however you said, a package could be installed in
/prefix/xemacs/xemacs-package
That's $prefix/xemacs/xemacs-packages (note the 's' at the end)
or
~/.xemacs/xemacs-package
Ditto, ~/.xemacs/xemacs-packages
or
/prefix/xemacs/site-packages
If so why does Christophs Makefile contain the line
PACKAGEDIR = $(HOME)/.xemacs/xemacs-packages
(his package is supposed to be installed in this directory)
but I could not find such a target in the Makefiles of the CVS, I
downloaded (see below)
We don't use PACKAGEDIR, but XEMACS_INSTALLED_PACKAGES_ROOT and
NONMULE_INSTALLED_PACKAGES_ROOT in Local.rules are roughly equivalent.
For example, mine has this:
XEMACS_INSTALLED_PACKAGES_ROOT = $(HOME)/.xemacs
...(and NONMULE_... not changed) which causes "make install" from *my*
packages working tree to land the (non-Mule) packages under my
~/.xemacs/xemacs-packages. It doesn't have anything to do with where
people installing the binary packages will have them. PUI decides that
(or people can just extract the tarball to a valid package location of
their choice, see below).
Political question: suppose I generated a new AUCTeX package
could
this also be put on the official AUCTeX page or is there a danger that
it will be considered as a 3rd party pkg and installed in
~/.xemacs/xemacs-packages
I'm not sure what you mean here, but maybe my commentary above clarifies
this? The *_PACKAGES_ROOT in Makefiles will not end up in the binary
package; it can be installed in any standard location. See the
`early-packages', `late-packages' and `last-packages' variables. As for
including it on the auctex page, it's up to you and the upstream
maintainer, but I would recommend against it. To reduce confusion and
unnecessary maintenance tasks, it should be kept only in one place, in
the XEmacs packages distribution point.
2. I tried first to built up the existing 1.33 AUCTeX package, based
on
10g, before going to the 11.13 version, I want to be sure that I
did correctly
I first downloaded the cvs tree, by
cvs -d:pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs login
Looks good.
cvs -f -z3 -d:pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs checkout -P
xemacsweb
cd xemacsweb/
Huh? You don't need the xemacsweb module, it contains the XEmacs
website. See <http://www.xemacs.org/Develop/cvsaccess.html>;.
cvs co packages
Ok.
cvs co package-control
This was already checked out with "cvs co packages".
cd packages/
cvs co xemacs-base
Ditto, already checked out with "packages".
cd xemacs-base/
make
cd ..
cd auctex/
make
See packages/INSTALL. It would be a good idea to do (after "cvs co
packages"):
cd packages
make autoloads
...and then "cd xemacs-packages/auctex ; make". If this doesn't work,
it's a bug and needs to be fixed.
Based on the commands above, I think your current checkout is quite a
mess, and would suggest doing the checkout again.
Basically, it's just a
cvs -d :pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs login
cvs -z3 -d :pserver:cvs＠cvs.xemacs.org:/pack/xemacscvs checkout packages
cd packages
cp Local.rules.template Local.rules
[edit Local.rules as needed]
make autoloads
cd xemacs-packages/auctex
make install [or make bindist]
It did not work for my 21.4.12 no mule version!!! I frequently
download
and compile AUCTeX myself and never had this kind of problem. While
xsymbol detects whether a mule or no-mule version is used, I am not so
sure about AUCTeX, I have to ask David, but I want to know whether a
-with-no-mule compiled AUCTeX would run under mule and vice
versa. I expect that a -with-mule compiled AUCTeX would run with no
mule and *not* vice versa.
It is possible that there's a bug in the current auctex Makefile. Can
someone with a non-Mule XEmacs handy verify if the current package
builds ok?
I personally don't use Mule, but think the AUCTeX should be
compiled
such that it is usable for both.
Yep.
3. The make process worked for xemacs-21.4.12 with mule, but no
binball was generated. I thought the generated binball would be in
/tmp/stagging??
Depends where you have set the NONMULE_INSTALLED_PACKAGES_ROOT variable
in your Local.rules. Note also that you have to "make bindist" to get
the binary tarball.
Duh, I see packages/INSTALL has some leftovers from before Ben's recent
changes, need to fix it (there's no $STAGING in Local.rules any more,
just think $NONMULE_INSTALLED_PACKAGES_ROOT).
4. Windows version. Can the generated AUCTeX package be used for
the
Win9x/NT/2000/etc version of Xemacs or do I have to compile another
one??
Rendhalver will take care of building packages for distribution, you
won't have to do that. It's up to the upstream auctex package whether
it's platform-independent or not (it should be...). We only distribute
one binary tarball for any package, there are no platform-specific
ones. AFAICT Rendhalver uses a Mule XEmacs 21.4.12 on Gentoo Linux for
building the official ones.
HTH,
--
\/ille Skyttä
scop at xemacs.org
7:14 p.m.
On Fri, 2003-01-31 at 05:01, Stephen J. Turnbull wrote:
You _care_ about
that package, you already know improvements are available, you know
what problems people have had. _You_ have a lot of expertise. To
acquire that would cost Ville or Rendhalver or me a _lot_ of time!
Exactly.
(ie,
typically ChangeLogs have conflicts because the XEmacs version will
have XEmacs package release heralds in it, but of course upstream
doesn't).
Because of this, I'd appreciate if the upstream ChangeLog would be
renamed "ChangeLog.upstream" in XEmacs CVS and included in Makefile
(EXTRA_SOURCES). See eg. how the psgml package does this.
--
\/ille Skyttä
scop at xemacs.org
7:10 p.m.
On Thu, 2003-01-30 at 18:00, Uwe Brauer wrote:
> A question for you, Uwe (which I've probably already asked
you), We'll
> be approaching the xsymbol author to see if he/she wants to maintain
> the XEmacs package version, if they decline would you be willing to
> step up to the plate?
I have to discuss this with Christoph of course; in principle yes,
however I consider x-symbol as a rather sophisticate package quite
beyond my lisp knowledge and I am not sure that I am qualified for this.
I discussed about this possibility some time ago with Christoph but back
then he didn't think he has the necessary 'net connectivity to take over
the task. I don't know if the situation has changed since then, though.
--
\/ille Skyttä
scop at xemacs.org
7966
days inactive
7975
days old
9 comments
4 participants
participants (4)
-
Stephen J. Turnbull -
Steve Youngs -
Uwe Brauer -
Ville Skyttä