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
Dear XEmacs Developers,
I recently got a large roundtuit dropped in my lap (my startup company
imploded), so I've spent a few days working on XEmacs native Windows
setup kits.
On Fri, Oct 31, 2014 at 8:45 PM, Biswajit Khandai <b_khandai(a)yahoo.com> wrote:
> I was assuming that the stable channel native windows binary will be built
> by "someone".... If that assumption is right, then the same "someone" could
> build the beta channel native windows binary. It may not be you,
> necessarily.
Your assumption is correct, but I am the only someone who builds these
kits. I will try to make a setup kit for every release, but it is
difficult for me to know how much time I will have for making setup
kits in between releases.
> However, if that assumption is wrong, I would like you to know that a heck
> of a lot of people use xemacs on Windows - maybe you underestimate the
> number of such people.
Dear Biswajit - thank you for your kind words. They certainly made me
feel like my efforts in this area have been well worthwhile.
I have re-made setup kits for 21.4.22, 21.5.34 and 21.4 latest and
21.5 latest. I will upload them this afternoon to ftp.xemacs.org.
I will be sending a small patch to XEmacs-patches to work around a
couple of difficulties building without TLS on native Windows. I have
not attempted to build with TLS as of yet.
- Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Will everyone please try out the latest 21.4 as checked into source
control? I am particularly interested in people who maintain XEmacs
packages, i.e. netbsd, gentoo, cygwin, native Windows setup kit (oops
- that's me!), etc.
Here's what I'm hoping you'll do:
1. hg clone https://bitbucket.org/xemacs/xemacs-21.4
2. cd xemacs-21.4
3. apply whatever patches you want/need
4. configure [options]
5. make
And send your results to the xemacs-beta list.
Please also send the patches you apply to xemacs-beta, so I can review
those patches for general suitability.
My hope is to release 21.4.24 sometime in the near future and to
declare 21.4.24 as the final 21.4 release.
Thank you,
Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
A couple weeks ago I used the Bitbucket web page to add a note to the
xemacs-beta README. I now see that I introduced a couple problems. :-(
1. The README file is actually stored in the repo, which means I
introduced a divergence between xemacs and xemacs-beta.
2. The Bitbucket editor added a carriage return at the end of all the
lines.
I guess the best way to fix this is to push a fixed README to xemacs,
and then whoever next promotes changesets to xemacs-beta can handle the
merge (just take the xemacs version)...?
Sorry 'bout this.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
ACTIVITY SUMMARY (2015-02-17 - 2015-02-24)
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.
565 open ( +1) / 317 closed ( +0) / 882 total ( +1)
Open issues with patches: 13
Average duration of open issues: 2007 days.
Median duration of open issues: 2178 days.
Open Issues Breakdown
new 257 ( +1)
deferred 6 ( +0)
napping 3 ( +0)
verified 58 ( +0)
assigned 145 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 15 ( +0)
Issues Created Or Reopened (1)
______________________________
c-mode/font-lock hang on 21.5 beta34 x86_64-redhat-linux, Mule 2015-02-20
http://tracker.xemacs.org/XEmacs/its/issue884 created flachs
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Woo-hoo! Thank you, Henry and congratulations!
Let us know how testing goes!
- Vin
On Mon, Feb 23, 2015 at 5:32 PM, Henry S. Thompson <ht(a)inf.ed.ac.uk> wrote:
> The problem was that not enough room was being allocated in the
> Windows objects to store a (64-bit) frame pointer, so
> SetWindowsLongPtr was refusing to store it, hence the missing frame
> info.
>
> Attaching is a patch on top my earlier hg repo which allows xemacs
> -vanilla to get to first base, anyway.
>
> More testing needed, obviously. If I get time later in the week I'll
> put together a better announcement to the whole list.
>
> 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
ACTIVITY SUMMARY (2015-02-10 - 2015-02-17)
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.
564 open ( +0) / 317 closed ( +0) / 881 total ( +0)
Open issues with patches: 13
Average duration of open issues: 2003 days.
Median duration of open issues: 2173 days.
Open Issues Breakdown
new 256 ( +0)
deferred 6 ( +0)
napping 3 ( +0)
verified 58 ( +0)
assigned 145 ( +0)
committed 19 ( +0)
documented 3 ( +0)
done/needs work 15 ( +0)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Hi, Hauke -
On Sat, Feb 14, 2015 at 6:21 PM, Hauke Fath <hf(a)spg.tu-darmstadt.de> wrote:
>
> I didn't cc the list because of the attachment. If the tracker should
> be down for longer, I could put up the logs tarball for download.]
and I have added the list back because the attachment is not in this reply.
> On Sat, 14 Feb 2015 17:23:53 -0500, Vin Shelton wrote:
>
> > On Wed, Feb 4, 2015 at 11:28 AM, Hauke Fath <hf(a)spg.tu-darmstadt.de> wrote:
> >
> >> While it builds and runs fine on NetBSD/i386, I have xemacs SIGSEV
> >> during the build on amd64 while dumping. This happened off and on for
> >> 21.4.22, too. I will collect data, and open a ticket.
> >
> > Thanks. The tracker seems to be down. Can you summarize issue #883?
>
> Quoting my mail to the list,
>
> <snip>
> While it builds and runs fine on NetBSD/i386, I have xemacs SIGSEV
> during the build on amd64 while dumping. This happened off and on for
> 21.4.22, too.
> </snip>
>
> > Please include the contents of the INSTALLATION file.
>
> Hm - I only found an INSTALL file with the sources...
> I have attached the build log, and a gdb stacktrace with symbols.
> Please let me know if I can provide anything else.
The make log include the contents that gets captured in the
Installation file. For your reference, in the build directory, the
configuration process builds a file name "Installation" which
describes the configuration options used.
I suggest you configure with the --pdump option; in my experience that
path gets a lot more use these days than the old dumping code. I
thought, somehow, that "-z combreloc" required the portable dumper,
but it may not. In any case, try using --pdump and see if that clears
up your segv.
>
> > Also, I couldn't figure out how to get the NetBSD patches. Please let me
> > know if you still think there are NetBSD patches I should consider.
>
> My first mail on the subject had
>
> <snip>
> I am in the process of updating the pkgsrc editors/xemacs package, and
> I wonder whether you have ever looked at its patches?
>
> <http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/editors/xemacs/patches/?only_w...>
> <ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/editors/xemacs/patches/>
I downloaded all the patches from the ftp site.
Thanks,
Vin
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta