Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

[Stefan Monnier]

I have some questions about copyright in your latest AUCTeX update.

What is the copyright status of the following new files:

- psfig.el, epsf.el, latexinfo.el (Gemis is not found in copyright.list)?
- dinbrief.el (Werner Fink is not found in copyright.list)?
- prosper.el (Philippe Lord has papers on file for Emacs, but Nevin
  Kapur only for Gnus)?

Also why change copyright from FSF to Hidenobu Nabetani in tex-jp.el:

   -;; Copyright (C) 1999, 2001-2007, 2012  Free Software Foundation, Inc.
   +;; Copyright (C) 1999, 2001 Hidenobu Nabetani <nabe@debian.or.jp>
   +;; Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation


-- Stefan "Who just shortened some copyright year ranges in `elpa'"

Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

[Tassilo Horn]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> I have some questions about copyright in your latest AUCTeX update.
>
> What is the copyright status of the following new files:
>
> - psfig.el, epsf.el, latexinfo.el (Gemis is not found in copyright.list)?
> - dinbrief.el (Werner Fink is not found in copyright.list)?
> - prosper.el (Philippe Lord has papers on file for Emacs, but Nevin
>   Kapur only for Gnus)?

Oh, sorry.  I'll investigate on those and try to get the CAs.  I didn't
check the status for them, because we only accept contributions
including CAs nowadays, but maybe those are old leftovers...

For the time being, I've delete the files from the elpa branch.

> Also why change copyright from FSF to Hidenobu Nabetani in tex-jp.el:
>
>    -;; Copyright (C) 1999, 2001-2007, 2012  Free Software Foundation, Inc.
>    +;; Copyright (C) 1999, 2001 Hidenobu Nabetani <nabe@debian.or.jp>
>    +;; Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007 Free Software Foundation
>
> -- Stefan "Who just shortened some copyright year ranges in `elpa'"

I didn't really merge elpa/packages/auctex with the auctex CVS
repository (which is not so easy because the directory layout differs)
but just copied over the files from the new auctex release tarball.  But
now I'm going to merge your copyright header changes back to the auctex
CVS.

Bye,
Tassilo

Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

[Stefan Monnier]

> I didn't really merge elpa/packages/auctex with the auctex CVS
> repository (which is not so easy because the directory layout differs)
> but just copied over the files from the new auctex release tarball.  But
> now I'm going to merge your copyright header changes back to the auctex
> CVS.

Why still use the CVS repository?  It seems more trouble than anything.


        Stefan

Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I didn't really merge elpa/packages/auctex with the auctex CVS
>> repository (which is not so easy because the directory layout
>> differs) but just copied over the files from the new auctex release
>> tarball.  But now I'm going to merge your copyright header changes
>> back to the auctex CVS.
>
> Why still use the CVS repository?  It seems more trouble than
> anything.

Do you have a better idea?  We are planning to migrate to some DVCS
anytime soon, but since AUCTeX is expected to work with all Emacs
versions >= 21.x plus XEmacs >= 21.4.x, there's no way to develop it
only as a part of emacs in its bzr repo, although that would be very
nice from a maintenance point of view.

Bye,
Tassilo

Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

[Stefan Monnier]

> Do you have a better idea?

Use elpa/packages/auctex as the official upstream.

> We are planning to migrate to some DVCS anytime soon, but since AUCTeX
> is expected to work with all Emacs versions >= 21.x plus XEmacs >=
> 21.4.x, there's no way to develop it only as a part of emacs in its
> bzr repo, although that would be very nice from a maintenance point
> of view.

I don't see what prevents it.  AFAICT it still contains all the backward
compatibility code that's in CVS and nobody asked to remove it.
If there are a couple more xemacs-specific files, I have no objection to
you adding them.  The only remaining problem I can imagine is for those
few files which aren't FSF-copyright and hence aren't in the ELPA
package, but IIUC these are obsoletish and could just be dropped (noone
complained about them missing from the ELPA version).


        Stefan

Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

I've added the auctex-devel list to the Cc.

>> Do you have a better idea?
>
> Use elpa/packages/auctex as the official upstream.
>
>> We are planning to migrate to some DVCS anytime soon, but since
>> AUCTeX is expected to work with all Emacs versions >= 21.x plus
>> XEmacs >= 21.4.x, there's no way to develop it only as a part of
>> emacs in its bzr repo, although that would be very nice from a
>> maintenance point of view.
>
> I don't see what prevents it.  AFAICT it still contains all the
> backward compatibility code that's in CVS and nobody asked to remove
> it.  If there are a couple more xemacs-specific files, I have no
> objection to you adding them.

I'd welcome this but David and Ralf are more qualified to judge about
feasibility.  Especially, there's much complexity in auctex's build
system in order to compile XEmacs packages, and that's a bit more than
just an auctex-compat.el.

> The only remaining problem I can imagine is for those few files which
> aren't FSF-copyright and hence aren't in the ELPA package, but IIUC
> these are obsoletish and could just be dropped (noone complained about
> them missing from the ELPA version).

Yes, these 5 or 6 files are only addons for some special latex styles.
They are not important for auctex, and they could be dropped or easily
rewritten by someone else with CA by just looking at the corresponding
latex style but not the current code.

Bye,
Tassilo

Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

[David Kastrup]

Tassilo Horn <tsdh@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> Hi Stefan,
>
> I've added the auctex-devel list to the Cc.
>
>>> Do you have a better idea?
>>
>> Use elpa/packages/auctex as the official upstream.
>>
>>> We are planning to migrate to some DVCS anytime soon, but since
>>> AUCTeX is expected to work with all Emacs versions >= 21.x plus
>>> XEmacs >= 21.4.x, there's no way to develop it only as a part of
>>> emacs in its bzr repo, although that would be very nice from a
>>> maintenance point of view.
>>
>> I don't see what prevents it.  AFAICT it still contains all the
>> backward compatibility code that's in CVS and nobody asked to remove
>> it.  If there are a couple more xemacs-specific files, I have no
>> objection to you adding them.
>
> I'd welcome this but David and Ralf are more qualified to judge about
> feasibility.  Especially, there's much complexity in auctex's build
> system in order to compile XEmacs packages, and that's a bit more than
> just an auctex-compat.el.

The XEmacs package building is sort of an aggravation.  An XEmacs
package contains all necessary files plus info source files in a rigid
directory layout, possibly not unsimilar to what ELPA or any other
package would do.

Now XEmacs will only distribute package files that have been assembled
by XEmacs tools in the XEmacs package tree.  So the XEmacs packages that
AUCTeX provides will work fine, but you'll have to find, download and
install them manually instead of relying on the XEmacs packaging system.

What will be provided in the XEmacs package repositories consequently is
something massaged manually to the necessary layout, commonly with
mistakes and several years behind.

So it is not clear to me who the customers for the XEmacs packages we
compile actually are.  Smart people, most likely.  XEmacs itself
boycotts our packaging efforts since we don't arrive at the right layout
in the canonical way.

The XEmacs compatibility code in the Lisp files itself is peanuts in
comparison.  No point in removing that as far as I can see.  However,
preview-latex has a somewhat more extensive compatibility setup.  It
would be arguable not to place the prv-xemacs.el files in the ELPA
packaging at least.  Removing it from the source distribution would be
seriously unfair since it is technically complex enough that starting it
from scratch would be quite hard: that would be several man-months at
least from an experienced XEmacs programmer, and there are none as far
as I can see interested in AUCTeX.

>> The only remaining problem I can imagine is for those few files which
>> aren't FSF-copyright and hence aren't in the ELPA package, but IIUC
>> these are obsoletish and could just be dropped (noone complained
>> about them missing from the ELPA version).
>
> Yes, these 5 or 6 files are only addons for some special latex styles.
> They are not important for auctex, and they could be dropped or easily
> rewritten by someone else with CA by just looking at the corresponding
> latex style but not the current code.

Also possible to go assignment-shopping for them once again.

-- 
David Kastrup

Re: [AUCTeX-devel] [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

[Uwe Brauer]

>> On Wed, 05 Dec 2012 15:24:50 +0100, David Kastrup <dak@gnu.org> wrote:

   > Tassilo Horn <tsdh@gnu.org> writes:



[snip]


   > Now XEmacs will only distribute package files that have been assembled
   > by XEmacs tools in the XEmacs package tree.  
This is correct. I wish it were different, that there
existed a debian-like-alien tool which allowed to convert
one package into another one, like deb-->rpm

   > So the XEmacs packages that AUCTeX provides will work
   > fine, but you'll have to find, download and install
   > them manually instead of relying on the XEmacs
   > packaging system.

You can unpack it in ~/.xemacs/packages
or in 
prefix/xemacs/site-packages

   > What will be provided in the XEmacs package
   > repositories consequently is something massaged
   > manually to the necessary layout, commonly with
   > mistakes and several years behind.

Well if their package manager were faster it should be a
question of days not years :'(


[snip]


   > The XEmacs compatibility code in the Lisp files itself is peanuts in
   > comparison.  No point in removing that as far as I can see.  However,
   > preview-latex has a somewhat more extensive compatibility setup.  It
   > would be arguable not to place the prv-xemacs.el files in the ELPA
   > packaging at least.   

That is your call to make.

   > Removing it from the source distribution would be
   > seriously unfair since it is technically complex enough that starting it
   > from scratch would be quite hard: that would be several man-months at
   > least from an experienced XEmacs programmer, and there are none as far
   > as I can see interested in AUCTeX.

Yes, please, do *not* remove it, that would be real nightmare
for Xemacs users.



Uwe Brauer 

Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

[Stefan Monnier]

> The XEmacs package building is sort of an aggravation.  An XEmacs
> package contains all necessary files plus info source files in a rigid
> directory layout, possibly not unsimilar to what ELPA or any other
> package would do.

Can you describe how does the XEmacs-package-building relates to the
VCS repository?  Is it that the CVS layout was chosen specifically to
match the XEmacs package requirements?  Are those requirements
incompatible with the ones for ELPA packages?

> So it is not clear to me who the customers for the XEmacs packages we
> compile actually are.

I'll let the AUCTeX maintainer(s) decide whether it's important to
support this.

> However, preview-latex has a somewhat more extensive compatibility
> setup.  It would be arguable not to place the prv-xemacs.el files in
> the ELPA packaging at least.

If a file is in `elpa/packages/auctex' then it will be in the ELPA
package (which is little more than a tarball of that directory).
But I don't see why including prv-xemacs.el in the ELPA package would be
a problem.  It's arguably wasteful, but I doubt anybody cares.

This said, we could tweak the GNU ELPA build scripts so that some files
are removed from the tarball.


        Stefan

Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

[David Kastrup]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> The XEmacs package building is sort of an aggravation.  An XEmacs
>> package contains all necessary files plus info source files in a rigid
>> directory layout, possibly not unsimilar to what ELPA or any other
>> package would do.
>
> Can you describe how does the XEmacs-package-building relates to the
> VCS repository?  Is it that the CVS layout was chosen specifically to
> match the XEmacs package requirements?

No.  XEmacs was supported after the CVS layout had been established.  An
XEmacs package is assembled in a target directory hierarchy separate
from the source tree.

> Are those requirements incompatible with the ones for ELPA packages?

No idea.

-- 
David Kastrup

Re: [AUCTeX-devel] [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

[Didier Verna]

David Kastrup wrote:

> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Can you describe how does the XEmacs-package-building relates to the
>> VCS repository?  Is it that the CVS layout was chosen specifically to
>> match the XEmacs package requirements?

> No.  XEmacs was supported after the CVS layout had been established.  An
> XEmacs package is assembled in a target directory hierarchy separate
> from the source tree.

>> Are those requirements incompatible with the ones for ELPA packages?
>
> No idea.

  Not sure how this would work for a complex thing such as AUCTeX, but
  most of the time, it's not so difficult to support all those
  installation schemes from a single source tree.

  The key to packaging for XEmacs is that you need to provide a specific
  Makefile (sort of imposed by the infrastructure) with some predefined
  variables that you need to fill in. But the underlying organization of
  your source tree is pretty much what you want.

  Because the Makefile is specific, it's better to export your source
  tree to another directory (as David says) for XEmacs packaging. For my
  own packages, I have a generic infrastructure that does this. Every
  project contains a file named Makefile.pkg which is the XEmacs package
  one. I use 'hg convert' to export the tree to the appropriate place
  (XEmacs packages are under Mercurial) with a special .hgfilemap
  containing essentially this:

rename Makefile.pkg Makefile

  but the rest of the source tree remains mostly the same. I like to
  organize my tree with lisp/*.el doc/*.texi etc/stuff etc., but you
  could also be plain flat of whatever.

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

[Stefan Monnier]

>> Can you describe how does the XEmacs-package-building relates to the
>> VCS repository?  Is it that the CVS layout was chosen specifically to
>> match the XEmacs package requirements?
> No.  XEmacs was supported after the CVS layout had been established.  An
> XEmacs package is assembled in a target directory hierarchy separate
> from the source tree.

So it should be easy to adapt the script doing this assembly to work
from the layout in the elpa/paclages/auctex directory.


        Stefan

Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

[Stephen J. Turnbull]

Stefan Monnier writes:

 > Can you describe how does the XEmacs-package-building relates to the
 > VCS repository?

It doesn't restrict the repository in any way.  The XEmacs package
build system puts the packages into a specific layout (basically
similar to an installed GNU Emacs of 19.x vintage, without the bin
directory and with no libraries in the top level of the lisp/
directory, only subdirectories containing packaged libraries).  The
build system has sufficient flexibility to handle the AUCTeX source
layout, and any future variation of it that I can imagine without
hallucinogens.  Updating it to handle future changes to AUCTeX's
source layout is *purely* our problem.

AUCTeX's build system does the same job in a different way.  The two
systems have different purposes.  AUCTeX's is to avoid a requiring
that its users and developers maintain a specific build environment
just for XEmacs packages.  Ours is to guarantee that our distributed
packages are built in a controlled environment.

As far as I can see, neither of these should affect GNU Emacs or GNU
ELPA for quite a while.  I think the Emacs maintainers should be
vaguely aware of the build environment issue, because there's a
possibility that as ELPA expands and becomes widely used,
inconsistencies among packages distributed stand-alone may arise.

However, since Emacs has a policy of eschewing support for non-GNU
systems when that conflicts with the optimal support for GNU, I think
ELPA will find it much easier to support AUCTeX's build system
directly.  It's difficult for us because it depends on utilities that
are normally not present on Windows, for example.

Re: [AUCTeX-devel] [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

[Ralf Angeli]

* Tassilo Horn (2012-12-05) writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Use elpa/packages/auctex as the official upstream.
>>
>>> We are planning to migrate to some DVCS anytime soon, but since
>>> AUCTeX is expected to work with all Emacs versions >= 21.x plus
>>> XEmacs >= 21.4.x, there's no way to develop it only as a part of
>>> emacs in its bzr repo, although that would be very nice from a
>>> maintenance point of view.

Since we want to make standalone releases for older Emacsen and XEmacs,
we'd also have to keep the build system.

>> I don't see what prevents it.  AFAICT it still contains all the
>> backward compatibility code that's in CVS and nobody asked to remove
>> it.  If there are a couple more xemacs-specific files, I have no
>> objection to you adding them.
>
> I'd welcome this but David and Ralf are more qualified to judge about
> feasibility.  Especially, there's much complexity in auctex's build
> system in order to compile XEmacs packages, and that's a bit more than
> just an auctex-compat.el.

Another reason to keep the build system is the possibility to install
preview.sty and its documentation in a TeX system tree.  You can do this
with `preview-install-styles' as well, but only for your user, unless
you have sudo or root access.  So I dunno if a site-wide install of
AUCTeX and preview would be easily feasible with just the Emacs package
system.

>> The only remaining problem I can imagine is for those few files which
>> aren't FSF-copyright and hence aren't in the ELPA package, but IIUC
>> these are obsoletish and could just be dropped (noone complained about
>> them missing from the ELPA version).
>
> Yes, these 5 or 6 files are only addons for some special latex styles.
> They are not important for auctex, and they could be dropped or easily
> rewritten by someone else with CA by just looking at the corresponding
> latex style but not the current code.

If we don't get the CAs I wouldn't mind either deleting those files.

-- 
Ralf

Re: [ELPA-diffs] /srv/bzr/emacs/elpa r312: Update AUCTeX ELPA package to the new 11.87 release.

[Tassilo Horn]

David Kastrup <dak@gnu.org> writes:

>>> The only remaining problem I can imagine is for those few files
>>> which aren't FSF-copyright and hence aren't in the ELPA package, but
>>> IIUC these are obsoletish and could just be dropped (noone
>>> complained about them missing from the ELPA version).
>>
>> Yes, these 5 or 6 files are only addons for some special latex
>> styles.  They are not important for auctex, and they could be dropped
>> or easily rewritten by someone else with CA by just looking at the
>> corresponding latex style but not the current code.
>
> Also possible to go assignment-shopping for them once again.

Did that now, and all four are going to assign copyright to the FSF.

Bye,
Tassilo