Hi,
Here comes yet another status report from the project of converting to
GPLv3 or later.
There are two lists of files below. The first list contains all files
that are in an undecided state. Please inspect: Do we need to do anything
with them. If so what?
The second list contains all files that we can leave untouched and the
reason for that. Please inspect: Are all reasons OK and correct?
Are we getting close to the were an inspection of the xemacs-gplv3
repository could be performed? With the intent that it that is OK we
could merge back to trunk and go GPLv3 or later?
----------------------------------------------------------------------
"CHANGES-beta"
"ChangeLog"
"PROBLEMS"
"README"
"README.GPLv3"
"etc/ChangeLog"
"etc/Emacs.ad"
"etc/InstallGuide"
"etc/NEWS"
"etc/ONEWS"
"etc/OONEWS"
"etc/README"
"etc/editclient.sh"
"etc/emacskeys.sco"
"etc/emacsstrs.sco"
"etc/gtkrc"
"etc/package-index.LATEST.gpg"
"etc/sample.Xresources"
"etc/xemacs.1"
"lib-src/ChangeLog"
"lib-src/README"
"lisp/ChangeLog"
"lisp/README"
"lisp/mule/mule-locale.txt"
"man/ChangeLog"
"man/README"
"modules/ChangeLog"
"modules/base64/Makefile"
"modules/common/configure-post.ac"
"modules/common/configure-pre.ac"
"modules/zlib/Makefile"
"nt/ChangeLog"
"nt/Emacs.ad.h"
"nt/Installation.el"
"nt/README"
"nt/Win32.cf"
"nt/lisp.ico"
"nt/site.def"
"nt/xemacs.dsp"
"nt/xemacs.dsw"
"src/ChangeLog"
"src/README"
"src/README.kkcc"
"src/m/README"
"src/s/README"
"src/s/freebsd.h"
"src/s/irix6-0.h"
"src/s/netbsd.h"
"src/s/sol2.h"
"tests/ChangeLog"
"tests/Dnd/README"
"tests/automated/README"
"version.sh.in"
----------------------------------------------------------------------
These files below are the files that we might be able to leave as
they are. The reason for why they need not to be changed is listed
after each file: (Some reasons are taken verbatim from private
communication or the "GPL version 3 source survey")
----------------------------------------------------------------------
"INSTALL" -> old FSF Documentation license
"config.guess" -> Part of config which is still GPLv2 or later. See "http://savannah.gnu.org/projects/config"
"config.sub" -> Part of config which is still GPLv2 or later. See "http://savannah.gnu.org/projects/config"
"etc/ETAGS.ChangeLog" -> BSD and GPL v2 or later
"etc/VEGETABLES" -> Not copyrightable.
"etc/XKeysymDB" -> MIT
"etc/ctags.1" -> Part of the etags distribution, which is not part of XEmacs.
"etc/custom/example-themes/ex-custom-file" -> Generated(!?) or GPL V2 or later?
"etc/etags.1" -> Part of the etags distribution, which is not part of XEmacs.
"etc/gnuattach.1" -> simple man link to gnuserv.1
"etc/gnuclient.1" -> simple man link to gnuserv.1
"etc/gnudoit.1" -> simple man link to gnuserv.1
"etc/refcard.ps.gz" -> Generated from refcard..tex
"etc/sample.Xdefaults" -> It is deprecated, so it can be removed but is only a three line reference to .Xresources
"etc/xemacs-X.ico" -> GPLv2 or later but there is not meta data for the file where this can be documented.
"info/dir" -> Generated(?)
"install-sh" -> MIT-style "no advertising" license
"lib-src/b2m.c" -> This is the version from GNU Emacs, so should be OK.
"lib-src/config.values.in" -> Generated.
"lib-src/emacs.csh" -> I don't think this even works with XEmacs ("emacsclient"), so I believe we can just delete it.
"lib-src/insert-data-in-exec.c" -> Compatible license.
"lib-src/mmencode.c" -> Compatible license.
"lisp/dump-paths.el" -> Empty file. Not copyrightable.
"lisp/term/bobcat.el" -> Emacs version has no explicit license declaration
"lisp/term/vt102.el" -> Emacs version has no explicit license declaration
"lisp/term/vt125.el" -> Emacs version has no explicit license declaration
"lisp/term/vt200.el" -> Emacs version has no explicit license declaration
"lisp/term/vt201.el" -> Emacs version has no explicit license declaration
"lisp/term/vt220.el" -> Emacs version has no explicit license declaration
"lisp/term/vt240.el" -> Emacs version has no explicit license declaration
"lisp/term/vt300.el" -> Emacs version has no explicit license declaration
"lisp/term/vt320.el" -> Emacs version has no explicit license declaration
"lisp/term/vt400.el" -> Emacs version has no explicit license declaration
"lisp/term/vt420.el" -> Emacs version has no explicit license declaration
"lock/.precious" -> Not copyrightable.
"modules/canna/install-sh" -> MIT
"modules/ldap/install-sh" -> MIT
"modules/postgresql/install-sh" -> MIT
"modules/sample/external/install-sh" -> MIT
"modules/sample/internal/install-sh" -> MIT
"move-if-change" -> Identical to GPLv3 or later Emacs version
"nt/Xmd.patch" -> GPLv2 or later but only a few lines
"nt/file.ico" -> MIT
"nt/minitar.c" -> Public domain
"nt/paths.h" -> Generated
"nt/xemacs.ico" -> GPLv2 or later but there is not meta data for the file where this can be documented.
"src/alloca.c" -> Public domain.
"src/depend" -> Generated
"src/emacs-marshals.c" -> Generated.
"src/emacs-widget-accessors.c" -> Generated.
"src/intl-auto-encap-win32.c" -> Generated.
"src/intl-auto-encap-win32.h" -> Generated.
"src/libsst.c" -> Compatible license.
"src/libsst.h" -> Compatible license.
"src/libst.h" -> Compatible copyright.
"src/linuxplay.c" -> Compatible license. (MIT-like)
"src/miscplay.c" -> Compatible license. (MIT-like)
"src/miscplay.h" -> Compatible license. (MIT-like)
"src/nas.c" -> Compatible license. (MIT-like)
"src/paths.h.in" -> Generated.
"src/s/openbsd.h" -> Too short. (< 10 lines)
"src/s/usg5-4-2.h" -> Too short. (< 10 lines)
"src/sunplay.c" -> Compatible copyright.
"tests/gtk/UNIMPLEMENTED" -> Does notes need a license?
"tests/tooltalk/beeps.el" -> Too short. (< 10 lines)
----------------------------------------------------------------------
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
I had a need to run something on my Windows machine today which
required a newer version of Cygwin than the ancient one that was
installed there. After I upgraded to the current version (1.7.9) I
can't start a shell in XEmacs (via M-X shell) using Cygwin's version of
bash. When I try to do so I get
Process bash.exe exited abnormally with code 35584
3 [sig] bash 1168 exception::handle: Exception:
STATUS_ACCESS_VIOLATION
1556 [sig] bash 1168 open_stackdumpfile: Dumping stack trace to
bash.exe.stackdump
The stack dump is uninteresting except that the crash happens at offset
0x169220 in cygwin1.dll. It appears that this crash happens very early
on, before it's read /etc/profile. I see that I also have similar
stack dumps from other programs (find.exe and xargs.exe) in the XEmacs
directory all exactly the same.
I installed the latest Windows version of XEmacs from the installer at
<http://ftp.xemacs.org/pub/xemacs/binaries/win32/InnoSetup/XEmacs_Setup_21...>
and tried starting it with --vanilla. This didn't make any difference.
I also did a clean install of Cygwin 1.7.9 in case there was any crud
left around from the old version. This also didn't help. I'm running
on an old Dell with Windows XP Professional SP3. Perhaps that's the
problem. I probably should install Windows on my Mac under one of the
emulators, but that's more than I want to get into right now.
I've Googled around a bit and although others have seen this problem,
none of the solutions (mostly involving changing ownership of Cygwin
files and running rebaseall) did any good. The bash shell runs fine
when I start it using the .bat file installed by Cygwin, so it's
basically working, but it won't run in an XEmacs shell window.
Has anyone else seen this or know how to fix it? This little episode
reminds me why I avoid using Windows, but sometimes it's necessary.
Mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi, I compiled xemacs myself and installed into $HOME/xemacs-without-ipv6-cname
I then made a symlink of $HOME/xemacs-without-ipv6-cname/bin/xemacs to $HOME/bin/xemacs
I untarred the sumo tarball from http://ftp.xemacs.org/pub/xemacs/packages/xemacs-sumo-2009-02-17.tar.gz and untarred it into $HOME/xemacs-without-ipv6-cname/lib/xemacs, which made a directory called xemacs-packages there.
When I run xemacs, I am not able to update my packages.
I go to Tools -> Packages -> Set Download Site -> Official Releases -> US and choose US Main.
I then go "update package index" or any other command in the Tools menu about Packages and it complains: "symbol's value as variable is void: allow-remote-paths"
Can anyone help me with this? Thanks.
--
✐Richard Cook
✇ Lawrence Livermore National Laboratory
Bldg-453 Rm-4024, Mail Stop L-557
7000 East Avenue, Livermore, CA, 94550, USA
☎ (office) (925) 423-9605
☎ (fax) (925) 423-6961
---
Information Management & Graphics Grp., Services & Development Div., Integrated Computing & Communications Dept.
(opinions expressed herein are mine and not those of LLNL)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta
Hi, XEmacs.
My XEmacs cannot find its packages.
o - I configured the XEmacs build with a bare "./configure".
o - I ran "make install" as root, which moved the program to
/usr/local/bin/xemacs.
o - I put the sumo tarball in /usr/local/lib/xemacs as instructed by the
FM and gunzipped and tar -xf'd it there.
o - load-path is ("/usr/local/share/xemacs/site-lisp/"
"/usr/local/share/xemacs-21.5-b31/lisp/")
Why does this not work? Why can I not find the name of the variable
holding the pertinent directory?
Why can I find no documentation about how the package system works?
I've tried C-h v'ing just about every variable starting "package-", and
none of them fits the bill. Why does the doc string for
packages-load-path-depth not mention where it is going deep from?
This is frustrating.
Thanks in advance for the help.
--
Alan Mackenzie (Nuremberg, Germany).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi, XEmacs.
I would like to put functions into function-key-map as the bindings of a
key sequence, something like:
(define-key function-key-map [?\e ?\[ ?1 ?}] 'kn-prefix-control)
, the intention being that on receiving the key sequence ESC [ 1 },
the control modifier will be added to the next key received.
This works fine on another editor. I'm not having luck with it in
XEmacs. The documentation for function-key-map doesn't mention
functions as bindings. If there isn't the possibility of functions
here, is there some other way to do what I want?
--
Alan Mackenzie (Nuremberg, Germany).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Is there a document that shows what the requirements are to submit new
code to XEmacs?
And how to do it?
Working on new icons for XEmacs, we improved the xpm editing mode to
better make and edit icons.
Byrel and I have extended the xpm-mode to include many new features
(adding an alpha layer to .xpms, adding new tools to move the image
around on a canvas, gradient backgrounds, mirroring an image, added
rudimentary layering, brightening and dimming, added a toolbar as well
as made a menu for the new commands, and added keybindings for the new
commands, and more).
The code went from ~400 lines to ~1800 lines.
With that much changed, is a diff still the best way to submit this?
I don't know what standards of coding are expected, so I expect we will
need to make changes to make it acceptable to the reviewers. Where are
the guidelines for submitting new code?
Also, the existing xpm mode was a minor mode that required a major
mode, we changed that so xpm-mode starts as a derived mode from picture
mode. Will that affect how the code should be submitted?
Steve and Byrel Mitchell
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
What do you all think? We don't use autogen.sh, but we could create
one and/or adjust the Makefile. I'm pretty sure that the features
used in this GNUMakefile are all ancient in GNU Make.
---------- Original Message ----------
From: Paul Eggert <eggert(a)cs.ucla.edu>
To: Eli Zaretskii <eliz(a)gnu.org>
Subject: Re: New build process?
Date: Wed, 27 Jul 2011 13:27:31 -0700
In-Reply-To: <E1Qm0y2-0006jr-V1(a)fencepost.gnu.org>
References: <20110726184220.GA6390(a)acm.acm>
<87bowg6fre.fsf(a)fencepost.gnu.org> <E93EA1CB-E480-4A43-B7FF-C0BB9424683E(a)gmail.com> <4E2F2084.7070001(a)gmail.com>
<E1QluJt-0008SP-RQ(a)fencepost.gnu.org> <CAC=50j9Of-N3uvaw3O86WEuk_PZDL1=40CLiiAqVGxe=XJeHrA(a)mail.gmail.com> <E1QlwMa-0000og-3K(a)fencepost.gnu.org> <CAC=50j8z4X8N50boFr3-yo7RqYkkN=9UQxKMrJmAzGjL_dEDrQ(a)mail.gmail.com>
<E1Qm0y2-0006jr-V1(a)fencepost.gnu.org>
On 07/27/11 03:03, Eli Zaretskii wrote:
> ... the need to install,
> update, and use any additional commands before "./configure; make" is
> a nuisance whose justification is questionable at best. It's just
> that I gave up on talking people into catering to us dinosaurs
The *real* dinosaurs just type "make". The "./configure; make"
business is a relative latecomer.
It'd be nice if one could just type "make".
To help move in that direction, I installed the following patch.
It assumes GNU Make, but that's a reasonable assumption these
days for developers. Developers who insist on using non-GNU "make"
can use "./autogen.sh; ./configure; make" as before.
If there are any problems with this, please feel free to back it out
or improve it.
* GNUmakefile: New file.
This is for convenience, so that one can run GNU make in an
unconfigured source tree, and get a default build.
=== added file 'GNUmakefile'
--- GNUmakefile 1970-01-01 00:00:00 +0000
+++ GNUmakefile 2011-07-27 20:22:50 +0000
@@ -0,0 +1,77 @@
+# Build Emacs from a fresh tarball or version-control checkout.
+
+# Copyright 2011 Free Software Foundation, Inc.
+#
+# This file is part of GNU Emacs.
+#
+# GNU Emacs is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# GNU Emacs is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>.
+#
+# written by Paul Eggert
+
+
+# This GNUmakefile is for GNU Make. It is for convenience, so that
+# one can run 'make' in an unconfigured source tree. In such a tree,
+# this file causes GNU Make to first create a standard configuration
+# with the default options, and then reinvokes itself on the
+# newly-built Makefile. If the source tree is already configured,
+# this file defers to the existing Makefile.
+
+# If you are using a non-GNU 'make', or if you want non-default build
+# options, or if you want to build in an out-of-source tree, please
+# run "configure" by hand. But run autogen.sh first, if the source
+# was checked out directly from the repository.
+
+
+# If a Makefile already exists, just use it.
+
+ifeq ($(wildcard Makefile),Makefile)
+include Makefile
+else
+
+# If cleaning and Makefile does not exist, don't bother creating it.
+# The source tree is already clean, or is in a weird state that
+# requires expert attention.
+
+ifeq ($(filter-out %clean,$(or $(MAKECMDGOALS),default)),)
+
+$(MAKECMDGOALS):
+ @echo >&2 'No Makefile; skipping $@.'
+
+else
+
+# No Makefile, and not cleaning.
+# If 'configure' does not exist, Emacs must have been checked
+# out directly from the repository; run ./autogen.sh.
+# Once 'configure' exists, run it.
+# Finally, run the actual 'make'.
+
+default $(filter-out configure Makefile,$(MAKECMDGOALS)): Makefile
+ $(MAKE) -f Makefile $(MAKECMDGOALS)
+# Execute in sequence, so that multiple user goals don't conflict.
+.NOTPARALLEL:
+
+configure:
+ @echo >&2 'There seems to be no "configure" file in this directory.'
+ @echo >&2 'Running ./autogen.sh || autogen/copy_autogen ...'
+ ./autogen.sh || autogen/copy_autogen
+ @echo >&2 '"configure" file built.'
+
+Makefile: configure
+ @echo >&2 'There seems to be no Makefile in this directory.'
+ @echo >&2 'Running ./configure ...'
+ ./configure
+ @echo >&2 'Makefile built.'
+
+endif
+endif
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi,
I've stumbled on an issue when porting the go-mode (go-lang) to XEmacs
and needs some advice.
In the GNU code shell-command-on-region is called with 6
args. Actually the GNU version takes up to 7 args. (We don't have the
last two args. They are an error buffer, where output from stderr
goes, and a bool arg whether the error buffer should be displayed or
not. And yes, in my current solution I just ignore the separation of
stdout and stderr making the XEmacs version just slightly more user
unfriendly.)
One way of solving the issue for the go-mode is to sync our
shell-command-et-al-code with the GNU version. Maybe not that
difficult but there will be issues with asynchronous commands since we
use the background package for those. I guess we should go for
API-compatibility here so it ought to be a good thing, right?
On the other hand the functionality that is implemented is a call to
the program gofmt to reformat the current buffer and replace it. (Go
comes with a program that formats go code for you) This seems ideal to
call from call-process-region instead of using
shell-command-on-region!? (Am I missing something here, why fire of a
new shell just to run that process?)
To make things slightly worse it seems like GNUs call-process-region
is not compatible with ours so moving to call-process-region is only a
solution for XEmacs avoiding the missing features in our version of
shell-command-on-region.
Views, comments, appreciated!
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Mats Lidell writes:
> But will that be OK? I assume here that the other modes in
> prog-modes eventually will be GPLv3 or later due to syncing. Can
> they live side by side with a BSD-like licensed file?
Yes (there are a number of such variations in GNU Emacs, and the CMU
Mach code at the core of the HURD is all BSD-like, or maybe public
domain), but that's not the problem. The problem is whether anyone
may distribute an Elisp file under anything but the GPL. If the Elisp
file uses only typical Lisp constructs such as `car' and `let' and
`cond', there's no problem. But if it accesses Emacs features like
buffers, then according to the Honorary Dr. Stallman and his Leagle
Beagle, that's linking, and the GPL requires that that code be
distributed under the terms of the GPL or not at all, until there is
an implementation of Emacs Lisp that isn't derived from GNU Emacs.
(Aside to Mike: maybe it's time.... :)
I doubt the FSF would chase an individual author who just dumps such
code on a website with a BSD license. But I can't imagine they'd be
happy with us doing the same, since we also distribute a derivative of
Emacs under the GPL.
If the license is GPL-degradable, we really ought to just degrade to
GPL and add a pointer in the documentation to the distribution with a
more permissive license (as we did with Choi's Carbon port).
Hopefully the authors of go-lang mode will be more reasonable than
Choi was....
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta