7:28 p.m.
Hello,
Trying to build the latest sumo-tagged packages from CVS fails for me while
building auctex's preview.dvi. I have absolutely no clue about *tex, but
attached is the preview.log in case someone can tell from it what might be
wrong. This is with texinfo 4.11, texlive-texmf-latex 2007-24.fc9 on Fedora
9.
This looks to me like something that could be the problem, but I don't know
what to do about it:
----
! Use of \next doesn't match its definition.
\pr＠version ->s
umo-2009-02-17
l.33 ...nd\pr＠version{\expandafter\next\pr＠version
}}} \next \fi
If you say, e.g., `\def\a1{...}', then you must always
put `1' after `\a', since control sequence names are
made up of letters only. The macro here has not been
followed by the required stuff, so I'm ignoring it.
----
The build eventually fails with:
[...]
(see the transcript file for additional information)
Output written on preview.dvi (30 pages, 98244 bytes).
Transcript written on preview.log.
make[2]: Leaving directory
`/builddir/build/BUILD/xemacs-packages-extra-20090217/xemacs-packages/auctex'
make[1]: Leaving directory
`/builddir/build/BUILD/xemacs-packages-extra-20090217/xemacs-packages'
RPM build errors:
make[2]: *** [preview/latex/preview.dvi] Error 1
make[1]: *** [auctex/bytecompile.target] Error 2
make: *** [xemacs-packages/bytecompile.target] Error 2
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:29 p.m.
>>>> Ville wrote:
Ville> This looks to me like something that could be the problem, but
Ville> I don't know what to do about it:
The part:
...
\reserved＠a\pr＠version $Name: $ \ifx\pr＠version\＠empty
\reserved＠a\pr＠version CVS-$Revision: 1.1.2.1 $ \endgroup \else
\def\next release_{} \lccode`\_=`.
...
Seems to ensure that the co tag has the format "release_".
Not knowing at all what I'm doing I changed the line into the format
sumo-{}:
...
\reserved＠a\pr＠version $Name: $ \ifx\pr＠version\＠empty
\reserved＠a\pr＠version CVS-$Revision: 1.1.2.1 $ \endgroup \else
\def\next sumo-{} \lccode`\_=`.
\edef\next{\lowercase{\endgroup
...
Maybe, just maybe, this will make the date in the tag show up as the
version. If it really is so and if that is the right thing to do is
another thing. Hopefully this will help anyone who knows tex to figure
out the right thing to do.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:30 p.m.
Mats Lidell <matsl(a)xemacs.org> writes:
>>>>> Ville wrote:
Ville> This looks to me like something that could be the problem, but
Ville> I don't know what to do about it:
The part:
...
\reserved＠a\pr＠version $Name: $ \ifx\pr＠version\＠empty
\reserved＠a\pr＠version CVS-$Revision: 1.1.2.1 $ \endgroup \else
\def\next release_{} \lccode`\_=`.
...
Seems to ensure that the co tag has the format "release_".
Not knowing at all what I'm doing I changed the line into the format
sumo-{}:
...
\reserved＠a\pr＠version $Name: $ \ifx\pr＠version\＠empty
\reserved＠a\pr＠version CVS-$Revision: 1.1.2.1 $ \endgroup \else
\def\next sumo-{} \lccode`\_=`.
\edef\next{\lowercase{\endgroup
...
Maybe, just maybe, this will make the date in the tag show up as the
version. If it really is so and if that is the right thing to do is
another thing. Hopefully this will help anyone who knows tex to figure
out the right thing to do.
Quoting from the GPLv3 (under which AUCTeX currently is distributed,
your version probably still being under GPLv2)
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.
Putting a LaTeX style file into the search paths and letting it announce
a nonsensical version number not corresponding to any upstream version
is not exactly going to cause major enthusiasm.
So _please_ take the prominent notice stuff seriously.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:57 a.m.
David Kastrup wrote:
Mats Lidell <matsl(a)xemacs.org> writes:
>>>>>> Ville wrote:
> Ville> This looks to me like something that could be the problem, but
> Ville> I don't know what to do about it:
>
> The part:
> ...
> \reserved＠a\pr＠version $Name: $ \ifx\pr＠version\＠empty
> \reserved＠a\pr＠version CVS-$Revision: 1.1.2.1 $ \endgroup \else
> \def\next release_{} \lccode`\_=`.
> ...
>
> Seems to ensure that the co tag has the format "release_".
>
> Not knowing at all what I'm doing I changed the line into the format
> sumo-{}:
>
> ...
> \reserved＠a\pr＠version $Name: $ \ifx\pr＠version\＠empty
> \reserved＠a\pr＠version CVS-$Revision: 1.1.2.1 $ \endgroup \else
> \def\next sumo-{} \lccode`\_=`.
> \edef\next{\lowercase{\endgroup
> ...
>
> Maybe, just maybe, this will make the date in the tag show up as the
> version. If it really is so and if that is the right thing to do is
> another thing. Hopefully this will help anyone who knows tex to figure
> out the right thing to do.
Quoting from the GPLv3 (under which AUCTeX currently is distributed,
your version probably still being under GPLv2)
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.
Putting a LaTeX style file into the search paths and letting it announce
a nonsensical version number not corresponding to any upstream version
is not exactly going to cause major enthusiasm.
So _please_ take the prominent notice stuff seriously.
As the problem may show up elsewhere too:
It seems hardly possible to indicate maybe many hundred modifications as prominent
notices,
maybe its a solution to indicate the last changing date together with a link to the repo?
Andreas
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:45 p.m.
Andreas Roehler writes:
> a) The work must carry prominent notices stating that you
modified
> it, and giving a relevant date.
It seems hardly possible to indicate maybe many hundred
modifications as prominent notices, maybe its a solution to
indicate the last changing date together with a link to the repo?
Don't worry about "many hundred modifications". That clause is
revised from GPLv2, which used to require file-by-file notices.
Pretty clearly the intent is clarify that the requirement is simply to
notify the user that the work is different from the original. Without
imposing a burden far worse than the original BSD advertising clause!
I'm not sure what "a relevant date" might be; that's quite ambiguous
phrasing. I suppose date of last change is probably best, although
you could also imagine a notice "Proudly divergent since 1992".<wink>
I think your suggestion would go beyond what the GPLv3 requires, but
it would seem courteous to do at least that much.
Note that at the very least the Makefile has been replaced, though, so
*all* packages not original to XEmacs should bear a "this package was
changed" notice. It seems to me that due courtesy would demand that
we explain briefly that the functional code has been changed, as well
as the packaging.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:45 p.m.
David Kastrup writes:
You may convey a work based on the Program, or the modifications
to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.
What's this all about, David? A copyright notice is normally taken to
be sufficient.
In any case, adding kilobytes of comment and/or interactive notice to
explain that this is not David Kastrup's version will presumably not
solve the issue. Perhaps you could hazard a guess as to what's going
wrong here?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:32 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> You may convey a work based on the Program, or the modifications to
> produce it from the Program, in the form of source code under the
> terms of section 4, provided that you also meet all of these conditions:
>
> a) The work must carry prominent notices stating that you modified
> it, and giving a relevant date.
What's this all about, David? A copyright notice is normally taken to
be sufficient.
By whom? I am quoting the license conditions. It would appear that you
change the files around in order to fit XEmacs. That's certainly
permitted, but in the course of being able to properly identify bugs
reported to the AUCTeX team as a consequence of that, I am pointing out
that I have good cause that such changes are clearly marked as not being
the responsibility of upstream. I am aware that many terms of the GPL
are not usually taken very seriously, and am not usually trying to
bother people all too much.
In this particular case however, I would appreciate it if this
particular clause was heeded. Not because I am an unreasonable
troublemaker, but because the dissemination of incompatible versions is
worrisome for me. I can see where those changes appear technically
necessary for your version, but I want them clearly marked out. And it
happens that this is not too much to ask since the GPL conditions
support my desire.
If the LaTeX code were instead licensed under the LPPL (LaTeX project
public license), you would be required to change the file name before
changing the file, somewhat more of a hassle since that would require
changes in callers. So you see that this worry of incompatibility in
the context of LaTeX is not specific just to me.
The GPL, as opposed to the LPPL, does not reserve the file name space
for upstream. But it at least demands a prominent notice of the changes
done. I don't think that this is too much to ask, even if the license
did not spell it out.
In any case, adding kilobytes of comment and/or interactive notice
to
explain that this is not David Kastrup's version will presumably not
solve the issue. Perhaps you could hazard a guess as to what's going
wrong here?
CVS version tags are used for versioning the released files. Obviously,
the format of your version control system tags differs, as do the actual
versions. So when LaTeX tries parsing the version control tags, the
unforeseen format throws it off the track. The proposed changes (I have
not analyzed them thoroughly), would likely make the style file work.
However, I consider it likely that the resulting log file from the TeX
run (when using the \listfiles command, for example) would contain
absolutely no trace of this being a special version, but rather make it
appear like an upstream version with a strange version number.
That's not really satisfactory: typically, bug reports made on TeX
specific lists are made using the log output and including the output of
\listfiles. Version compatibility of LaTeX packages is usually assured
by demanding a file with at least a particular modification date. When
you use your own dates and CVS tags, this mechanism is broken.
It is important for diagnosing problems that the version is indicated as
not being the normal upstream version.
Why do I have to beg and rationalize to make you adhere to the license
conditions? I would consider it common courtesy to heed my request even
if you were not legally required to do so. What's the point in going
into confrontation mode about this?
As so often, I don't understand what you are trying to accomplish.
Fortunately, I am not dependent on my understanding in this case. Just
heed the license, mark the changes in the prescribed manner, and be
done. It is not like this would be onerous to do.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:32 p.m.
David Kastrup writes:
It would appear that you change the files around in order to fit
XEmacs. [...] I have good cause that such changes are clearly
marked as not being the responsibility of upstream.
You have no legal grounds at all. Neither GPL v2 nor v3 requires that
"changes" be marked. In v2, source files must "carry prominent
notices stating that you changed the files and the date of any
change", and that's all. We will do that in a way that conforms to
the GPL and is convenient for us. Unfortunately, I don't think that
is what you want, since it won't appear in the output.
However, I consider it likely that the resulting log file from the
TeX
run (when using the \listfiles command, for example) would contain
absolutely no trace of this being a special version, but rather make it
appear like an upstream version with a strange version number.
That does seem likely, which is unfortunate.
I can see where those changes appear technically necessary for your
version, but I want them clearly marked out.
That's reasonable, as a feature request. It will be implemented much
faster if you supply a patch, since nobody here seems to understand
what's going on with that code at all, while you attest that it's not
onerous for you.
If you don't plan to supply a patch, your request is less likely to
get lost if you file a feature request on the tracker:
http://tracker.xemacs.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:22 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
David Kastrup writes:
> It would appear that you change the files around in order to fit
> XEmacs. [...] I have good cause that such changes are clearly
> marked as not being the responsibility of upstream.
You have no legal grounds at all.
Shrug. I just love the way XEmacs treats upstream.
That's reasonable, as a feature request. It will be implemented
much
faster if you supply a patch, since nobody here seems to understand
what's going on with that code at all, while you attest that it's not
onerous for you.
If you don't plan to supply a patch, your request is less likely to
get lost if you file a feature request on the tracker:
http://tracker.xemacs.org/
I am neither XEmacs developer nor user and I won't register at the
websites of all people that think cooperation and courtesy towards
upstream is for wimps.
Sorry, I have neither time nor inclination to work for the benefit of
people that consider my contribution to their work an aggravation.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5:37 a.m.
David Kastrup writes:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Shrug. I just love the way XEmacs treats upstream.
[...]
I am neither XEmacs developer nor user and I won't register at
the
websites of all people that think cooperation and courtesy towards
upstream is for wimps.
Please calm down, David. My message was intended in all courtesy.
It's hard to respond courteously to an implied threat of legal action,
especially an empty one, but my response to your claim that we are
legally obliged to implement your request was not *dis*courteous.
As for the rest, I simply pointed out that we don't have the TeX
expertise to implement a version string that specifies XEmacs, as you
requested, and suggested that the fastest way to get it done is to do
it yourself, since the AUCTeX project is certainly overflowing with
TeX expertise. And it's true that submitting an issue to the tracker
makes our response more reliable and quicker. What's uncooperative or
discourteous about saying those things?
By the way, you or your users can submit bugs to the tracker by using
M-x report-xemacs-bug, which automatically registers a user for the
submitting email address. Since you don't use XEmacs, you can just
also insert "[issue]" as the first non-whitespace content in the
Subject field.[1] (The tracker monitors XEmacs Beta for issues and
reports generated by `report-xemacs-bug'.)
Footnotes:
[1] This creates a new issue; to respond to an old one, you'll need
supply the full issue tag such as [issue23456]. The tracker doesn't
understand email threads yet.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:32 p.m.
On Wednesday 25 February 2009, David Kastrup wrote:
CVS version tags are used for versioning the released files.
Obviously,
the format of your version control system tags differs, as do the actual
versions. So when LaTeX tries parsing the version control tags, the
unforeseen format throws it off the track.
Thanks for the tip. I suppose changing the CVS keyword expansion mode in
XEmacs packages CVS so that it doesn't do the expansion at all (now that
they're already in, can be IIRC done after the fact with "cvs admin -ko ... ;
cvs up") would fix it by keeping their values exactly as they were in the
files that were checked in. But if I understand you correctly, that wouldn't
satisfy this as I gather there might be some other differences in the
versions shipped with the version in XEmacs packages collection:
It is important for diagnosing problems that the version is indicated
as
not being the normal upstream version.
How would you prefer this to be indicated? Something like appending "-XEmacs"
to all relevant strings (see below) would be pretty easy to do, but I haven't
checked if it'd play well with how the strings are parsed in the code.
For reference, attached is the list of CVS keywords in auctex from my checkout
from the latest sumo tag. Based on a quick look, preview/latex/preview.dtx,
preview/preview.el, and style/prosper.el contain these keywords somewhere
else than in comments and would thus be primary candidates for -ko, but I
don't see any harm in doing that for all files in auctex (or actually pretty
much the whole packages CVS tree and making it the default for new files, but
that's another discussion, possibly moot if the packages are being moved to
another SCM in the nearish future).
$ grep -rP '\$[A-Z][a-z]*: .*\$' *
preview/latex/preview.dtx:\reserved＠a\pr＠version $Name: sumo-2009-02-17 $
\ifx\pr＠version\＠empty
preview/latex/preview.dtx:\reserved＠a\pr＠version CVS-$Revision: 1.1.2.1 $ \endgroup \else
preview/latex/preview.dtx:\reserved＠a\next $Date: 2008/09/09 21:47:21 $
preview/preview.el:;; $Id: preview.el,v 1.1.2.1 2008/09/09 21:45:58 matsl Exp $
preview/preview.el: (let ((name "$Name: sumo-2009-02-17 $")
preview/preview.el: (rev "$Revision: 1.1.2.1 $"))
preview/preview.el: (let ((date "$Date: 2008/09/09 21:45:58 $"))
style/book.el:;; $Id: book.el,v 1.1.2.1 2008/09/09 21:54:57 matsl Exp $
style/j-report.el:;; $Id: j-report.el,v 1.1.2.1 2008/09/09 21:55:05 matsl Exp $
style/scrlttr2.el:;; Version: $Id: scrlttr2.el,v 1.1.2.1 2008/09/09 21:55:12 matsl Exp $
style/dk.el:;; $Id: dk.el,v 1.1.2.1 2008/09/09 21:54:59 matsl Exp $
style/prosper.el: "$Id: prosper.el,v 1.1.2.1 2008/09/09 21:55:11 matsl Exp $"
style/scrbook.el:;; Version: $Id: scrbook.el,v 1.1.2.1 2008/09/09 21:55:12 matsl Exp $
style/latexinfo.el:;; Version: $Id: latexinfo.el,v 1.1.2.1 2008/09/09 21:55:07 matsl Exp
$
style/jsarticle.el:;; $Id: jsarticle.el,v 1.1.2.1 2008/09/09 21:55:05 matsl Exp $
style/harvard.el:;; Version: $Id: harvard.el,v 1.1.2.1 2008/09/09 21:55:03 matsl Exp $
style/jarticle.el:;; $Id: jarticle.el,v 1.1.2.1 2008/09/09 21:55:05 matsl Exp $
style/jsbook.el:;; $Id: jsbook.el,v 1.1.2.1 2008/09/09 21:55:06 matsl Exp $
style/report.el:;; $Id: report.el,v 1.1.2.1 2008/09/09 21:55:11 matsl Exp $
style/scrartcl.el:;; Version: $Id: scrartcl.el,v 1.1.2.1 2008/09/09 21:55:11 matsl Exp $
style/plhb.el:;; $Id: plhb.el,v 1.1.2.1 2008/09/09 21:55:10 matsl Exp $
style/plfonts.el:;; $Id: plfonts.el,v 1.1.2.1 2008/09/09 21:55:10 matsl Exp $
style/scrreprt.el:;; Version: $Id: scrreprt.el,v 1.1.2.1 2008/09/09 21:55:12 matsl Exp $
style/jreport.el:;; $Id: jreport.el,v 1.1.2.1 2008/09/09 21:55:05 matsl Exp $
style/letter.el:;; $Id: letter.el,v 1.1.2.1 2008/09/09 21:55:07 matsl Exp $
style/scrbase.el:;; Version: $Id: scrbase.el,v 1.1.2.1 2008/09/09 21:55:12 matsl Exp $
style/j-book.el:;; $Id: j-book.el,v 1.1.2.1 2008/09/09 21:55:04 matsl Exp $
style/j-article.el:;; $Id: j-article.el,v 1.1.2.1 2008/09/09 21:55:04 matsl Exp $
style/virtex.el:;; $Id: virtex.el,v 1.1.2.1 2008/09/09 21:55:14 matsl Exp $
style/foils.el:;; $Id: foils.el,v 1.1.2.1 2008/09/09 21:55:01 matsl Exp $
style/dutch.el:;; $Id: dutch.el,v 1.1.2.1 2008/09/09 21:55:00 matsl Exp $
style/article.el:;; $Id: article.el,v 1.1.2.1 2008/09/09 21:54:56 matsl Exp $
style/jbook.el:;; $Id: jbook.el,v 1.1.2.1 2008/09/09 21:55:05 matsl Exp $
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
11:41 p.m.
Ville Skyttä <scop(a)xemacs.org> writes:
On Wednesday 25 February 2009, David Kastrup wrote:
> CVS version tags are used for versioning the released files. Obviously,
> the format of your version control system tags differs, as do the actual
> versions. So when LaTeX tries parsing the version control tags, the
> unforeseen format throws it off the track.
Thanks for the tip. I suppose changing the CVS keyword expansion mode in
XEmacs packages CVS so that it doesn't do the expansion at all (now that
they're already in, can be IIRC done after the fact with "cvs admin -ko ... ;
cvs up") would fix it by keeping their values exactly as they were in the
files that were checked in. But if I understand you correctly, that wouldn't
satisfy this as I gather there might be some other differences in the
versions shipped with the version in XEmacs packages collection:
> It is important for diagnosing problems that the version is indicated as
> not being the normal upstream version.
How would you prefer this to be indicated? Something like appending
"-XEmacs" to all relevant strings (see below) would be pretty easy to
do, but I haven't checked if it'd play well with how the strings are
parsed in the code.
If it actually _is_ the same as the upstream version (and it sounds like
there is not really any change to it), then checking in the original
version and telling the version control system not to tamper with the
tags at all should be perfectly fine. Nothing is gained by marking a
version as changed which only differs by being marked as changed.
For reference, attached is the list of CVS keywords in auctex from
my
checkout from the latest sumo tag. Based on a quick look,
preview/latex/preview.dtx, preview/preview.el, and style/prosper.el
contain these keywords somewhere else than in comments and would thus
be primary candidates for -ko, but I don't see any harm in doing that
for all files in auctex (or actually pretty much the whole packages
CVS tree and making it the default for new files, but that's another
discussion, possibly moot if the packages are being moved to another
SCM in the nearish future).
It is probably not too hot an idea to have those Ids in comments at all,
but that is an upstream problem. I _think_ that the version parsing
folderol might have changed in AUCTeX 11.85 again, relying less (or
not?) on keyword expansion.
Probably -ko on everything is the sanest way to deal with it.
--
David Kastrup
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:37 p.m.
On Thursday 26 February 2009, David Kastrup wrote:
If it actually _is_ the same as the upstream version (and it sounds
like
there is not really any change to it), then checking in the original
version and telling the version control system not to tamper with the
tags at all should be perfectly fine.
Ok. I've applied tested this change locally to preview/latex/preview.dtx,
preview/preview.el, and style/prosper.el and it fixes the build for me. I
have no idea why it didn't fail in Norbert's official package sumo build
though.
Uwe, would you like me to take care of making these changes in XEmacs CVS?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:37 p.m.
>>>> David wrote:
David> Quoting from the GPLv3 (under which AUCTeX currently is distributed,
David> your version probably still being under GPLv2)
Please David I'm just trying to find what technical problem there is
behind the error we are seeing. Feel free to suggest what ever version
string you think is appropriate for the auctex version build in the
package tree.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
1:34 p.m.
>>>> "Mats" == Mats Lidell
<matsl(a)xemacs.org> writes:
>>>> David wrote:
David> Quoting from the
GPLv3 (under which AUCTeX currently is
David> distributed, your version probably still being under GPLv2)
Please David I'm just trying to find what technical problem
there
is behind the error we are seeing. Feel free to suggest what ever
version string you think is appropriate for the auctex version
build in the package tree.
Just to clarify (if this is not clear by now). Auctex 11.84 which we
tried to release as a xemacs pkg is still under GPLv2. The current 11.85
version, which now (after all the work) could be released quite easily
as a xemacs pkg, is under GPLv3, and therefore cannot be released :'(,
till this license problem is solved.[1].
Uwe Brauer
Footnotes:
[1] nor can the actual reftex version be upgraded!!!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
5530
days inactive
5534
days old
14 comments
6 participants
participants (6)
-
Andreas Röhler -
David Kastrup -
Stephen J. Turnbull -
The XEmacs Package Smoketest -
Uwe Brauer -
Ville Skyttä