April 2014 - XEmacs-Beta - XEmacs Mailing List Archives

GPLv3|L8R -- Status report - ready for inspection? 8 years

Mats Lidell

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

4 participants
3 comments

Cygwin 64-bit compilation experience? 10 years, 4 months

Henry S. Thompson

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

7 participants
35 comments

Change of load path during dump revisited 11 years, 1 month

The XEmacs Package Smoketest

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

3 participants
6 comments

Summary of XEmacs Issue Tracking System Issues 11 years, 1 month

XEmacs Issue Tracking System

ACTIVITY SUMMARY (2014-04-22 - 2014-04-29) 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: 1757 days. Median duration of open issues: 1886 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

1 participants
0 comments

button.el (again) 11 years, 1 month

Jerry James

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

3 participants
5 comments

Crash while determining coding system 11 years, 1 month

Jerry James

[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

3 participants
6 comments

Summary of XEmacs Issue Tracking System Issues 11 years, 1 month

XEmacs Issue Tracking System

ACTIVITY SUMMARY (2014-04-15 - 2014-04-22) 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: 1750 days. Median duration of open issues: 1879 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

1 participants
0 comments

Re: Cygwin 64-bit compilation experience? 11 years, 2 months

Henry S. Thompson

>> It's me FKtPp ;) writes: >> >> > When I try to compile XEmacs in mingw32 I notice that none of XEmacs >> > spawned subprocess could work. It was run-in-other-process that used to >> > emulate Unix signal that do not work in my end. >> > >> > I finally get a copy of XEmacs work by replace the run-in-other-process >> > thing with windows native stop process and control break event. >> > >> > Not sure if this is the same case in cygwin. > HST wrote: >> The advice from the Cygwin gurus is that mixing Windows and Cygwin >> process calls is . . . messy at best, but I'll have a look if you pass >> on your patches, please. Getting back to this. Struggling to remember what little I ever knew about debugging xemacs under Cygwin using gdb given the multiple threads involved. Anyone have any advice? There are some suggestions around that you have to run under a raw Windows console to avoid pty-related irrelevancies in the gdb-xemacs interactions -- true? What settings are recommended for the various gdb thread-related controls, such as non-stop scheduler-multiple scheduler-locking etc. ? Where do all these threads come from, anyway? If I try the same pattern of breakpoints (Fstart_process_internal, then send_process) on my Linux box, no threads involved. . . Thanks 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

2 participants
1 comments

Summary of XEmacs Issue Tracking System Issues 11 years, 2 months

XEmacs Issue Tracking System

ACTIVITY SUMMARY (2014-04-08 - 2014-04-15) 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: 1743 days. Median duration of open issues: 1872 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

1 participants
0 comments

Can we merge the auctex branch? 11 years, 2 months

Jerry James

Current mercurial head for the auctex package shows version 1.49 in the Makefile. There is a branch named auctex-11_84-import that contains a version 1.51, which we apparently released at some point: http://ftp.xemacs.org/pub/xemacs/packages/ That version even made it into the Fedora XEmacs packages package (get it?) at some time in the distant past. I'm trying to merge in the texinfo 5.x changes, but I don't want to touch this package since I don't know what's going on with the branches. Has it been around long enough that we can consider merging the branch to head? If not, please advise what I should do about the texinfo modifications. Thanks, -- Jerry James http://www.jamezone.org/ _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

2 participants
1 comments

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta April 2014