GPLv3|L8R -- Status report - ready for inspection?
7 years, 5 months
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
Crash running Cygwin bash shell under XEmacs
12 years, 2 months
Mike Alexander
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
symbol's value as variable is void: allow-remote-paths
12 years, 10 months
Richard Cook
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
Re: [Bug: 21.5-b31] Crash on customize
13 years, 2 months
Raymond Toy
On Wed, Aug 17, 2011 at 12:26 AM, Stephen J. Turnbull <stephen(a)xemacs.org>wrote:
>
> Do you have a plan that this question blocks you from following up?
>
Some additional information. This is easily reproduced using M-x
customize-variable user-mail-address (for want of a better variable). There
is a problem when customize is creating the push-button. It's crashing in
(widget-apply widget :create) when the widget is a push-button. There's no
problem creating the info-link widget.
Ray
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: Persian joining and Pango.
13 years, 2 months
Aidan Kehoe
Hi Behdad,
Ar an naoú lá is fiche de mí Lúnasa, scríobh Behdad Esfahbod:
> Can you point me to the code using Pango?
Sure:
https://bitbucket.org/kehoea/xemacs-gtk/src/97df8ecdf78e/src/redisplay-gt...
> I doubt Pango beiing involved in that shaping process.
:-) .
Here are a couple of screenshots, the first of XEmacs with font Monospace 10,
the second of pango-view with the same font and the same (copied and pasted)
text:
http://www.parhasard.net/images/xemacs-gtk-with-persian-alphabet-20110829...
http://www.parhasard.net/images/pango-view-with-persian-alphabet-20110829...
Thanks for your attention.
Best,
Aidan
> behdad
>
> On 08/28/11 09:42, Aidan Kehoe wrote:
> >
> > Hello there,
> >
> > I’m one of the XEmacs developers. Our GTK version, available here:
> > http://anonscm.debian.org/hg/xemacs/xemacs-gtk/ , uses Pango. Joining for
> > Arabic-specific characters works fine, but joining for Persian-specific
> > characters doesn’t. So when I type:
> >
> > الف به په ته ثه
> >
> > alef, beh, teh and theh appear with no problems (well, the bidi is
> > iffy, but one step at a time), while peh doesn’t join to heh. On the
> > same machine, pango-view with the same text joins with no problems.
> >
> > I’ve tried setting the GTK language to Persian; this doesn’t work because
> > the system locale doesn’t support it, but as far as I can see it shouldn’t
> > be necessary anyway. It’s not immediately obvious to me where to look next;
> > any pointers would be welcome.
> >
> > Some version info:
> >
> > $ pango-view --version
> > pango-view (pango) 1.28.4
> > Pango module interface version: 1.6.0
> > $ pkg-config --modversion pango
> > 1.28.4
> > $ pkg-config --modversion gtk+-2.0
> > 2.22.1
> > $ pkg-config --modversion fontconfig
> > 2.8.0
> > $ pkg-config --modversion freetype2
> > 12.2.6
> > $
--
‘Iodine deficiency was endemic in parts of the UK until, through what has been
described as “an unplanned and accidental public health triumph”, iodine was
added to cattle feed to improve milk production in the 1930s.’
(EN Pearce, Lancet, June 2011)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Moving the packages repo and converting to Mercurial
13 years, 2 months
Michael Sperber
OK, I now have the CVS repository massaged to the point where cvs2hg
will accept it. There's a basic decision to be made wrt. the
conversion:
#1 I can convert everything to one big Mercurial repo. (About
230MBytes.)
#2 I can convert every individual package into a Mercurial repo, and
arrange them as subrepositories to an umbrella repo.
#1 has the advantage that it's easy to do: However, there are various
import branches in CVS, which create a seriously mangled revision graph.
#2 is more attractive from a design perspective, and it's what I'd like
to do. It has a dowside, however:
There's still central content (the various build files etc.) that
needs to be in sync with the invidual packages. Mercurial handles
this just fine, but I don't know how to create a consistent set of
repositories from CVS. If you want to actually build an old version
of a package, you'll have to look up the revision of the central stuff
that matches it manually. This won't be necessary for revisions after
the move.
OK? Comments?
PS: If you have commit access to the Alioth Mercurial repository, please
get an account on Bitbucket (which is where we'll move the XEmacs
repositories in the near future) and e-mail me its name.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Re: Moving the packages repo and converting to Mercurial
13 years, 2 months
Michael Sperber
Alan Mackenzie <acm(a)muc.de> writes:
> I hardly know Mercurial at all, but one question: would strategy #2 cause
> any fragmentation? I.e., are there any operations one can perform on a
> single repository (perhaps some sort of searching) that would be awkward
> or impractical on strategy #2 (requiring, maybe, a shell for loop)?
Not in normal operation. Most of the time, it's pretty much transparent.
However, I guess "hg grep" will probably not span subrepos. But is that
important?
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
Persian joining and Pango.
13 years, 2 months
Aidan Kehoe
Hello there,
I’m one of the XEmacs developers. Our GTK version, available here:
http://anonscm.debian.org/hg/xemacs/xemacs-gtk/ , uses Pango. Joining for
Arabic-specific characters works fine, but joining for Persian-specific
characters doesn’t. So when I type:
الف به په ته ثه
alef, beh, teh and theh appear with no problems (well, the bidi is iffy, but
one step at a time), while peh doesn’t join to heh. On the same
machine, pango-view with the same text joins with no problems.
I’ve tried setting the GTK language to Persian; this doesn’t work because
the system locale doesn’t support it, but as far as I can see it shouldn’t
be necessary anyway. It’s not immediately obvious to me where to look next;
any pointers would be welcome.
Some version info:
$ pango-view --version
pango-view (pango) 1.28.4
Pango module interface version: 1.6.0
$ pkg-config --modversion pango
1.28.4
$ pkg-config --modversion gtk+-2.0
2.22.1
$ pkg-config --modversion fontconfig
2.8.0
$ pkg-config --modversion freetype2
12.2.6
$
Best,
Aidan
--
‘Iodine deficiency was endemic in parts of the UK until, through what has been
described as “an unplanned and accidental public health triumph”, iodine was
added to cattle feed to improve milk production in the 1930s.’
(EN Pearce, Lancet, June 2011)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
[PATCH] XEmacs Xt dont recognize SHIFT F10 in linux
13 years, 3 months
FKtPp
Dear all,
I've just come out a patch for the XEmacs don't recognize shift
Function key issue.
please help review.
Thanks,
Kai
src/ChangeLog addition:
2011-08-25 It's me FKtPp ;) <m_pupil(a)yahoo.com.cn>
Fix issue in event-Xt so function keys can have shift bit set.
* event-Xt.c (x_event_to_emacs_event): make use of XConvertCase,
instead of hardcoded keysym lookup, to determind if a key is
subject to case convertion or not.
XEmacs source patch:
Diff command: hg diff --git
Files affected: src/event-Xt.c
diff --git a/src/event-Xt.c b/src/event-Xt.c
--- a/src/event-Xt.c
+++ b/src/event-Xt.c
＠＠ -1227,9 +1227,9 ＠＠
if (modifiers & XEMACS_MOD_SHIFT)
{
- int Mode_switch_p = *state & xd->ModeMask;
- KeySym bot = XLookupKeysym (ev, Mode_switch_p ? 2 : 0);
- KeySym top = XLookupKeysym (ev, Mode_switch_p ? 3 : 1);
+ KeySym sym = XLookupKeysym (ev, 0);
+ KeySym top, bot;
+ XConvertCase (sym, &top, &bot);
if (top && bot && top != bot)
modifiers &= ~XEMACS_MOD_SHIFT;
}
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
