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
New machine, trying 64-bit cygwin, but no joy so far in compiling from
latest sources.
Too soon to say if I've just not got my environment right yet - so at
this point just checking -- has anyone made this work yet?
ht
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht(a)inf.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi,
Didn't get any response to this posting but then I realized I sent it
of to black hole somewhere and not to the mailing list. :-(
Mean while, I think we have solved it to some extent in Gentoo by
setting EMACSLOADPATH during the compile phase and removed the
compression of the el-files. It is still not perfect but might work in
practice.
I include my original posting below. // Mats
------------------------------------------------------------
Hi,
Don't know if you remember this thread but I had an issue with that
the lisp files installed in "/usr/share/xemacs-21.5-b34/lisp" some how
managed to get there way into the xemacs dump due to that the load
path is changed when startup.el is loaded. This happens when you
rebuild xemacs, same version of course, for any reason.
This might be an obscure thing for someone installing xemacs from
sources. (In fact I haven't managed to recreate the problem when I
install from sources even if I set the prefix to /usr. Which makes
things even stranger.)
For the Linux distribution Gentoo where packages are installed from
building from sources rebuilding packages can happen. The fact that
files in /usr/share/xemacs-21.5-XXX is used within the build is not a
good thing.
What is worse is that if the el-files are gzipped, that is a target we
have to save some bytes on disc, the dump crasches because it can't
find the el-files. The crash happens just after loading, yes you
guessed it, startup.el because misc.el can't be found. It is now
compressed and dump does not know about compressed el-files, right?
It looks like this:
[...]
Loading modeline.el...
Loading cus-file.el...
Loading startup.el...
Load file misc: not found
Fatal error during load, aborting
make[1]: *** [NEEDTODUMP] Error 1
make[1]: Leaving directory `/var/tmp/portage/app-editors/xemacs-21.5.34-r3/work/xemacs-21.5.34/src'
make: *** [src] Error 2
* ERROR: app-editors/xemacs-21.5.34-r3::emacs failed (compile phase):
* emake failed
*
[...]
The best thing would of course be if there was some simple way to
invoked make so that this problem don't occur. But I don't know what
that would be. The load path stuff is deep within XEmacs as I get it.
I could delete the lisp files under /usr/share/xemacs-21.5-XXX before
building but that isn't ideal since that would ruin the current
install if the ongoing would fail for some reason. But at the moment
that seems to be my best option.
Ideas, suggestions are welcome.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
I mentioned this once before, months ago, then let it drop. We need a port
of button.el from Emacs if we are ever going to move up to the latest
version of CEDET. Now I have discovered that references to button.el
ALREADY show up in our packages, namely:
- xemacs-packages/calendar/cal-compat.el: has competing make-button and
insert-button functions (these will have to go once we introduce the
"real"
button.el).
- xemacs-packages/calendar/diary-lib.el: use of define-button-type, inside a
comment about how we don't have button.el
- xemacs-packages/viper/viper-cmd.el: checks for existence of button-at and
push-button functions
- xemacs-packages/xemacs-base/debug.el: uses of button-buffer-map and
push-button, both commented out, in the debugger-mode-map setup
The last time we discussed this, we talked about adding button.el to the
fsf-compat package. In light of the above (and the fact that I converted
it to use extents instead of overlays), is fsf-compat still the best place
for button.el? I admit that I don't see a package for which it is well
suited, but I wonder if it might not fit better somewhere else.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
[Originally sent 19 Mar and then again 27 Mar 2014, but I think I
accidentally sent HTML email, so both copies are probably sitting in
the spam trap.]
I just received a bug report for the Fedora build of XEmacs:
https://bugzilla.redhat.com/show_bug.cgi?id=1078159
What seems to have happened is that determine_real_coding_system
(file-coding.c) was called, and tried to read some data from the
lstream. However, Lstream_read encountered an error of some kind, I
don't know what. This resulted in an empty buffer, and nread == -1.
We then proceeded to pass the empty buffer and the count of -1 to
detect_coding_type, which used the count of -1 to justify walking off
the end of allocated memory, thereby triggering a segfault.
We need to notice the Lstream_read failure and bail out of
determine_real_coding_system. Would something like this be
appropriate?
diff -r 9fae6227ede5 src/ChangeLog
--- a/src/ChangeLog Thu Mar 27 08:59:03 2014 -0600
+++ b/src/ChangeLog Thu Mar 27 09:32:53 2014 -0600
@@ -1,3 +1,10 @@
+2014-03-27 Jerry James <james(a)xemacs.org>
+
+ * file-coding.c (encode_decode_coding_region): Bail out if
+ Lstream_read encounters an error (returns -1).
+ (determine_real_coding_system): Ditto.
+ (Ffind_coding_system_magic_cookie_in_file): Ditto.
+
2014-01-27 Michael Sperber <mike(a)xemacs.org>
* symbols.c (Fdefine_function): Allow optional `docstring'
diff -r 9fae6227ede5 src/file-coding.c
--- a/src/file-coding.c Thu Mar 27 08:59:03 2014 -0600
+++ b/src/file-coding.c Thu Mar 27 09:32:53 2014 -0600
@@ -2294,7 +2294,7 @@
Bytecount size_in_bytes =
Lstream_read (istr, tempbuf, sizeof (tempbuf));
- if (!size_in_bytes)
+ if (size_in_bytes <= 0)
break;
newpos = lisp_buffer_stream_startpos (istr);
Lstream_write (ostr, tempbuf, size_in_bytes);
@@ -3863,24 +3863,32 @@
make_opaque_ptr (st));
UExtbyte buf[4096];
Bytecount nread = Lstream_read (stream, buf, sizeof (buf));
- Lisp_Object coding_system
- = look_for_coding_system_magic_cookie (buf, nread, 1);
-
- if (NILP (coding_system))
+ Lisp_Object coding_system;
+
+ if (nread > 0)
{
- while (1)
+ coding_system = look_for_coding_system_magic_cookie (buf, nread, 1);
+
+ if (NILP (coding_system))
{
- if (detect_coding_type (st, buf, nread))
- break;
- nread = Lstream_read (stream, buf, sizeof (buf));
- if (nread == 0)
- break;
+ while (1)
+ {
+ if (detect_coding_type (st, buf, nread))
+ break;
+ nread = Lstream_read (stream, buf, sizeof (buf));
+ if (nread <= 0)
+ break;
+ }
+
+ coding_system = detected_coding_system (st);
}
- coding_system = detected_coding_system (st);
+ Lstream_rewind (stream);
}
-
- Lstream_rewind (stream);
+ else
+ {
+ coding_system = Qnil;
+ }
unbind_to (depth);
return coding_system;
@@ -4315,7 +4323,9 @@
Lstream_delete (XLSTREAM (lstream));
retry_close (fd);
- return look_for_coding_system_magic_cookie (buf, nread, 0);
+ return (nread > 0)
+ ? look_for_coding_system_magic_cookie (buf, nread, 0)
+: Qnil;
}
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Mats Lidell <matsl(a)xemacs.org> writes:
>>>>>> Michael Sperber <sperber(a)deinprogramm.de> writes:
>
>> It is intentional, to some degree: A long time ago, people screamed
>> bloody murder at me when the startup paths didn't give configure'd
>> paths precedence over those determined at run time. startup.el is just
>> the first file that knows about those paths. So there's no good
>> solution here that will make everybody happy, I'm afraid.
>
> But this happens while building the dump. What ever happens when you
> start your xemacs is another thing I think. Couldn't this behavior be
> controlled some how so that when building the dump we don't do this?
It could be done. My point is that, at least once upon a time, there
were people who didn't do it to be the way you want it to be. They do
have a point in that the already complicated behavior gets more
complicated when it's different at dump time.
--
Regards,
Mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
make[1]: Entering directory `/home/tom/src/xemacs/man'
/usr/bin/makeinfo -P lispref -o ../info/lispref.info
lispref/lispref.texi
/home/tom/src/xemacs/man/lispref//customize.texi:6: Next field of node
`Customization' not pointed to (perhaps incorrect sectioning?).
/home/tom/src/xemacs/man/lispref//loading.texi:6: This node (Loading)
has the bad Prev.
/home/tom/src/xemacs/man/lispref//customize.texi:6: Prev field of node
`Customization' not pointed to.
/home/tom/src/xemacs/man/lispref//macros.texi:6: This node (Macros) has
the bad Next.
makeinfo: Removing output file `../info/lispref.info' due to errors; use
--force to preserve.
make[1]: *** [../info/lispref.info] Error 1
make[1]: Leaving directory `/home/tom/src/xemacs/man'
make: *** [info] Fehler 2
Änderung: 5792:9fae6227ede5
Marke: tip
Nutzer: Jerry James <james(a)xemacs.org>
Datum: Thu Mar 27 08:59:03 2014 -0600
Zusammenfassung: Silence texinfo 5.2 warnings, primarily by adding next,
prev, and up
--
thomas
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
[Originally sent 19 Mar 2014, but I haven't seen it show up in the
archives.]
I just received a bug report for the Fedora build of XEmacs:
https://bugzilla.redhat.com/show_bug.cgi?id=1078159
What seems to have happened is that determine_real_coding_system
(file-coding.c) was called, and tried to read some data from the lstream.
However, Lstream_read encountered an error of some kind, I don't know
what. This resulted in an empty buffer, and nread == -1. We then
proceeded to pass the empty buffer and the count of -1 to
detect_coding_type, which used the count of -1 to justify walking off the
end of allocated memory, thereby triggering a segfault.
We need to notice the Lstream_read failure and bail out of
determine_real_coding_system. I'm not entirely sure of the right way to do
that. If one of you coding system master could suggest something, I'd
appreciate it.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
ACTIVITY SUMMARY (2014-03-18 - 2014-03-25)
XEmacs Issue Tracking System at http://tracker.xemacs.org/XEmacs/its/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
554 open ( +0) / 311 closed ( +0) / 865 total ( +0)
Open issues with patches: 13
Average duration of open issues: 1722 days.
Median duration of open issues: 1851 days.
Open Issues Breakdown
new 243 ( +0)
deferred 6 ( +0)
napping 3 ( +0)
verified 58 ( +0)
assigned 147 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 16 ( +0)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta