10 p.m.
Hi,
This is a status report from the project of moving from GPLv2 or later
to GPLv3 to later license. I enclose below the list of files yet to be
handled. These might be anything from difficult or not even needing a
change. The only thing they have in common is that they are not
handled yet at least according to me and my support script,
If you look carefully you'll see that I need to filter out things that
the script doesn't handle at the moment (and possibly never will). The
reasoning behind the filters are (in the order of the "egrep
-v"-filters in the command line below)
1. all files that the script matches as gplv3. Files that match "?!!"
is on a special ignore list. These are files that I think should
not be touch for different reasons. (Don't worry. We'll come back
to those. They are few anyway.)
2. Then all png is filtered out cause I think they are fixed (and the
script can't identify those.)
Out goes also all texi-files cause they seem to be under a license
that we can't easily change but at the same time isn't in the way
for going GPLv3 or later.
3. Out goes folders:
unicode - think it is fixed
lispref - see texi-file comment above
new-users-guide - see above
man/xemacs - see above
lwlib - fixed but the script won't identify that at the moment.
4. Finally all TUTORIAL goes out because of the same license situation
as for the general texi files.
This leaves this list!! Only 78 files!
- unknown(C): means there is a copyright in the file but it is not
identifiable by the script to something that can be substituted
into GPLv3 or later
- ?: means that there is nothing that looks like a copyright
notice in the file.
--- working directory: "/src/xemacs/gplv3.d/gplv3-work/"
% [...]/matsl/gplv3/substgplv2 | egrep -v '^(gplv3|\?!!):' | egrep -v
'*\.(png|texi)' | egrep -v
'/(unicode|lispref|new-users-guide|man/xemacs|lwlib)/' | egrep -v TUTORIAL
?: "./lock/.precious"
unknown(C): "./etc/photos/change.sh"
?: "./etc/editclient.sh"
?: "./etc/sample.Xresources"
?: "./etc/xemacs.1"
?: "./etc/ctags.1"
?: "./etc/gnuserv.1"
?: "./etc/VEGETABLES"
?: "./etc/gnuattach.1"
?: "./etc/emacskeys.sco"
?: "./etc/sample.Xdefaults"
unknown(C): "./etc/etags.1"
?: "./etc/gnuserv.README"
unknown(C): "./etc/refcard.tex"
?: "./etc/gnudoit.1"
?: "./etc/gnuclient.1"
?: "./etc/custom/example-themes/ex-custom-file"
?: "./etc/gtkrc"
unknown(C): "./etc/XKeysymDB"
?: "./etc/HELLO"
?: "./etc/emacsstrs.sco"
?: "./etc/Emacs.ad"
?: "./etc/InstallGuide"
?: "./tests/gtk/UNIMPLEMENTED"
?: "./tests/tooltalk/beeps.el"
?: "./lisp/term/bobcat.el"
?: "./lisp/dump-paths.el"
?: "./lisp/mule/mule-locale.txt"
?: "./modules/zlib/Makefile"
?: "./modules/common/configure-pre.ac"
?: "./modules/common/configure-post.ac"
?: "./modules/base64/Makefile"
unknown(C): "./modules/postgresql/postgresql.c"
unknown(C): "./modules/postgresql/postgresql.h"
?: "./SUBST"
unknown(C): "./src/miscplay.c"
?: "./src/alloca.c"
?: "./src/emacs-marshals.c"
?: "./src/intl-auto-encap-win32.h"
?: "./src/intl-auto-encap-win32.c"
unknown(C): "./src/libst.h"
unknown(C): "./src/sunplay.c"
unknown(C): "./src/linuxplay.c"
?: "./src/paths.h.in"
unknown(C): "./src/miscplay.h"
?: "./src/s/irix6-0.h"
?: "./src/s/usg5-4-2.h"
?: "./src/s/sol2.h"
?: "./src/s/openbsd.h"
?: "./src/s/freebsd.h"
?: "./src/s/netbsd.h"
?: "./src/emacs-widget-accessors.c"
unknown(C): "./src/nas.c"
unknown(C): "./src/libsst.h"
unknown(C): "./src/libsst.c"
?: "./xemacs-build-report.err"
?: "./version.sh.in"
unknown(C): "./CHANGES-beta"
unknown(C): "./man/texinfo.tex"
?: "./xemacs-make-all.err"
?: "./xemacs-make-check.err"
?: "./nt/paths.h"
?: "./nt/config.inc.samp"
?: "./nt/Xmd.patch"
?: "./nt/xemacs.dsp"
?: "./nt/site.def"
?: "./nt/xemacs.dsw"
?: "./nt/Installation.el"
?: "./nt/minitar.c"
?: "./nt/Win32.cf"
?: "./nt/Emacs.ad.h"
unknown(C): "./PROBLEMS"
unknown(C): "./lib-src/mmencode.c"
unknown(C): "./lib-src/insert-data-in-exec.c"
unknown(C): "./lib-src/b2m.c"
?: "./lib-src/config.values.in"
?: "./lib-src/emacs.csh"
unknown(C): "./lib-src/gnuserv.h"
Done 22:46:10
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:38 a.m.
Most of the files below were discussed several months ago, I think.
A few I can dispose of off the top of my head; maybe you can special
case them in your script.
Mats Lidell writes:
--- working directory: "/src/xemacs/gplv3.d/gplv3-work/"
% [...]/matsl/gplv3/substgplv2 | egrep -v '^(gplv3|\?!!):' | egrep -v
'*\.(png|texi)' | egrep -v
'/(unicode|lispref|new-users-guide|man/xemacs|lwlib)/' | egrep -v TUTORIAL
?: "./lock/.precious"
Not copyrightable.
unknown(C): "./etc/photos/change.sh"
This is yours, or something you imported. It's not part of XEmacs (hg
manifest | grep -F changes.sh => nothing).
?: "./etc/editclient.sh"
?: "./etc/sample.Xresources"
?: "./etc/xemacs.1"
?: "./etc/ctags.1"
I believe this is part of the etags distribution, which is not part of
XEmacs.
?: "./etc/gnuserv.1"
?: "./etc/VEGETABLES"
Not copyrightable.
?: "./etc/gnuattach.1"
?: "./etc/emacskeys.sco"
?: "./etc/sample.Xdefaults"
I think we can remove this one now, even if people use .Xdefaults
personally it's been 10 years or more since it was deprecated by the
X11 developers.
unknown(C): "./etc/etags.1"
I believe this is part of the etags distribution, which is not part of
XEmacs.
?: "./etc/gnuserv.README"
unknown(C): "./etc/refcard.tex"
?: "./etc/gnudoit.1"
?: "./etc/gnuclient.1"
?: "./etc/custom/example-themes/ex-custom-file"
?: "./etc/gtkrc"
unknown(C): "./etc/XKeysymDB"
?: "./etc/HELLO"
Replace this with GNU's HELLO file.
?: "./etc/emacsstrs.sco"
?: "./etc/Emacs.ad"
?: "./etc/InstallGuide"
?: "./tests/gtk/UNIMPLEMENTED"
?: "./tests/tooltalk/beeps.el"
?: "./lisp/term/bobcat.el"
?: "./lisp/dump-paths.el"
?: "./lisp/mule/mule-locale.txt"
?: "./modules/zlib/Makefile"
?: "./modules/common/configure-pre.ac"
?: "./modules/common/configure-post.ac"
?: "./modules/base64/Makefile"
unknown(C): "./modules/postgresql/postgresql.c"
unknown(C): "./modules/postgresql/postgresql.h"
These two files can be made GPLv3.
?: "./SUBST"
Something's not clean here. That's not part of XEmacs.
unknown(C): "./src/miscplay.c"
?: "./src/alloca.c"
?: "./src/emacs-marshals.c"
This file is either generated or Copyright Bill Perry.
?: "./src/intl-auto-encap-win32.h"
?: "./src/intl-auto-encap-win32.c"
These two are generated, I believe.
unknown(C): "./src/libst.h"
unknown(C): "./src/sunplay.c"
unknown(C): "./src/linuxplay.c"
?: "./src/paths.h.in"
unknown(C): "./src/miscplay.h"
?: "./src/s/irix6-0.h"
?: "./src/s/usg5-4-2.h"
?: "./src/s/sol2.h"
?: "./src/s/openbsd.h"
?: "./src/s/freebsd.h"
?: "./src/s/netbsd.h"
?: "./src/emacs-widget-accessors.c"
This file is either generated or Copyright Bill Perry.
unknown(C): "./src/nas.c"
unknown(C): "./src/libsst.h"
unknown(C): "./src/libsst.c"
?: "./xemacs-build-report.err"
Something's not clean here. That's not part of XEmacs.
?: "./version.sh.in"
unknown(C): "./CHANGES-beta"
Something's busted in your script; that file doesn't have a copyright
notice AFAIK.
unknown(C): "./man/texinfo.tex"
?: "./xemacs-make-all.err"
?: "./xemacs-make-check.err"
Something's not clean here. Those two are not part of XEmacs.
?: "./nt/paths.h"
?: "./nt/config.inc.samp"
That's surely the work of Ben Wing, plus maybe Adrian Aichner, Andy
Piper, and Vin Shelton. GPLv3 it.
?: "./nt/Xmd.patch"
?: "./nt/xemacs.dsp"
?: "./nt/site.def"
?: "./nt/xemacs.dsw"
?: "./nt/Installation.el"
?: "./nt/minitar.c"
?: "./nt/Win32.cf"
?: "./nt/Emacs.ad.h"
unknown(C): "./PROBLEMS"
That file doesn't have a copyright notice.
unknown(C): "./lib-src/mmencode.c"
unknown(C): "./lib-src/insert-data-in-exec.c"
unknown(C): "./lib-src/b2m.c"
?: "./lib-src/config.values.in"
?: "./lib-src/emacs.csh"
unknown(C): "./lib-src/gnuserv.h"
Done 22:46:10
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:55 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> Most of the files below were discussed several months ago, I
Stephen> think.
Probably. It is just a list of the files not yet handled in the
xemacs-gplv3 branch. I haven't even checked Jerrys gplv3-analysis-page
thoroughly when it comes to these files.
Stephen> A few I can dispose of off the top of my head;
That is very appreciated. Thanks.
> unknown(C): "./etc/photos/change.sh"
Stephen> This is yours, or something you imported. It's not part of XEmacs (hg
Stephen> manifest | grep -F changes.sh => nothing).
OOPS! Yes I used the script on my workspace where there are some files
that is not part of XEmacs at all. Sorry.
> ?: "./SUBST"
Stephen> Something's not clean here. That's not part of XEmacs.
Same thing here. A temporary file left in the workspace.
> ?: "./xemacs-build-report.err"
and
> ?: "./xemacs-make-all.err"
> ?: "./xemacs-make-check.err"
Stephen> Something's not clean here. Those two are not part of XEmacs.
Temporaries from by build-report script. See xemacs-builds for it! I
tried to build XEmacs as I go along so that I don't break anything.
So the strange files can all be acounted for. I'll be more careful
next time. Hopefully I don't have to produce so many yet-to-be-handled
lists. There seems to be light in the tunnel.
As for the rest of your input I take that into the process of
completing the task. I hope I could say be right back but it will
probably take some days before we are done. Stay tuned.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:56 a.m.
Mats Lidell writes:
So the strange files can all be acounted for. I'll be more
careful
next time. Hopefully I don't have to produce so many yet-to-be-handled
lists. There seems to be light in the tunnel.
I suggest you don't try to account for strange files. Instead, check
only files produced by "hg manifest".
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:28 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> I suggest you don't try to account for strange files.
Stephen> Instead, check only files produced by "hg manifest".
Point taken ;-) New version of the script uses hg manifest. There
seems to have been some other faults in the script as well. Not all
files were accounted(!) for.
After doing many of the conversions you and Michael suggested from my
earlier list I now have this list. (Replacing files by getting the
sources from Emacs still remains.)
(Note: unknown(C) means there is an unknown copyright notice in the
file. A copyright notice is assumed if the single word copyright is
found. So it might not be a copyright notice at all.)
----------------------------------------------------------------------
?: ".hgignore"
?: ".hgtags"
unknown(C): "ChangeLog"
?: "README"
unknown(C): "etc/ChangeLog"
?: "etc/ETAGS.ChangeLog"
?: "etc/Emacs.ad"
?: "etc/InstallGuide"
?: "etc/NEWS"
?: "etc/ONEWS"
?: "etc/OONEWS"
?: "etc/README"
unknown(C): "etc/XKeysymDB"
?: "etc/custom/example-themes/ex-custom-file"
?: "etc/editclient.sh"
?: "etc/emacskeys.sco"
?: "etc/emacsstrs.sco"
?: "etc/gnuattach.1"
?: "etc/gnuclient.1"
?: "etc/gnudoit.1"
?: "etc/gnuserv.1"
?: "etc/gnuserv.README"
?: "etc/gtkrc"
?: "etc/package-index.LATEST.gpg"
?: "etc/refcard.ps.gz"
unknown(C): "etc/refcard.tex"
?: "etc/sample.Xresources"
?: "etc/xemacs-X.ico"
?: "etc/xemacs.1"
?: "info/dir"
unknown(C): "lib-src/ChangeLog"
?: "lib-src/README"
unknown(C): "lisp/ChangeLog"
?: "lisp/ChangeLog.GTK"
?: "lisp/README"
?: "lisp/dump-paths.el"
?: "lisp/mule/mule-locale.txt"
?: "lisp/term/README"
?: "lisp/term/bobcat.el"
unknown(C): "man/ChangeLog"
?: "man/README"
unknown(C): "man/texinfo.tex"
?: "modules/ChangeLog"
?: "modules/README"
?: "modules/base64/Makefile"
unknown(C): "modules/canna/install-sh"
?: "modules/common/configure-post.ac"
?: "modules/common/configure-pre.ac"
unknown(C): "modules/ldap/install-sh"
unknown(C): "modules/postgresql/install-sh"
unknown(C): "modules/sample/external/install-sh"
unknown(C): "modules/sample/internal/install-sh"
?: "modules/zlib/Makefile"
unknown(C): "nt/ChangeLog"
?: "nt/Emacs.ad.h"
?: "nt/Installation.el"
?: "nt/README"
?: "nt/Win32.cf"
?: "nt/Xmd.patch"
?: "nt/file.ico"
?: "nt/lisp.ico"
?: "nt/minitar.c"
?: "nt/paths.h"
?: "nt/site.def"
?: "nt/xemacs.dsp"
?: "nt/xemacs.dsw"
?: "nt/xemacs.ico"
unknown(C): "src/ChangeLog"
?: "src/ChangeLog.GTK"
?: "src/README"
?: "src/README.kkcc"
?: "src/depend"
?: "src/m/README"
?: "src/s/README"
?: "src/s/freebsd.h"
?: "src/s/irix6-0.h"
?: "src/s/netbsd.h"
?: "src/s/sol2.h"
unknown(C): "tests/ChangeLog"
?: "tests/Dnd/README"
?: "tests/automated/README"
?: "tests/gtk/UNIMPLEMENTED"
?: "version.sh.in"
----------------------------------------------------------------------
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:44 p.m.
As to src/ and lib-src/, here's my analysis:
Executive summary:
- Need to copy a bunch of files in src/s from GNU Emacs.
- lib-src/gnuserv.h is GPLv2 or later, just needs to be bumped.
(Sorry, not quite enough time to actually do it today.)
Mats Lidell <matsl(a)contactor.se> writes:
unknown(C): "./src/miscplay.c"
The copyrights on this I read as compatible with GPLv3.
?: "./src/alloca.c"
Public domain.
?: "./src/emacs-marshals.c"
Generated.
?: "./src/intl-auto-encap-win32.h"
Generated.
?: "./src/intl-auto-encap-win32.c"
Generated.
unknown(C): "./src/libst.h"
Compatible copyright.
unknown(C): "./src/sunplay.c"
Compatible copyright.
unknown(C): "./src/linuxplay.c"
Compatible copyright.
?: "./src/paths.h.in"
Generated.
unknown(C): "./src/miscplay.h"
Compatible copyright.
?: "./src/s/irix6-0.h"
?: "./src/s/usg5-4-2.h"
Too short to need copyrighting, I think. (< 10 lines)
?: "./src/s/sol2.h"
?: "./src/s/openbsd.h"
Too short.
?: "./src/s/freebsd.h"
?
?: "./src/s/netbsd.h"
?
But we can get those from GNU Emacs.
?: "./src/emacs-widget-accessors.c"
Generated.
unknown(C): "./src/nas.c"
Compatible license.
unknown(C): "./src/libsst.h"
unknown(C): "./src/libsst.c"
Compatible license.
unknown(C): "./lib-src/mmencode.c"
unknown(C): "./lib-src/insert-data-in-exec.c"
Compatible license.
unknown(C): "./lib-src/b2m.c"
This is the version from GNU Emacs, so should be OK.
?: "./lib-src/config.values.in"
Automatically generated.
?: "./lib-src/emacs.csh"
I don't think this even works with XEmacs ("emacsclient"), so I believe
we can just delete it.
unknown(C): "./lib-src/gnuserv.h"
GPLv2 or later.
--
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
11:08 p.m.
>>>> Michael Sperber <sperber(a)deinprogramm.de>
writes:
Michael> As to src/ and lib-src/, here's my analysis:
Great. Seems like we have covered most of the files on paper anyway.
Michael> [...]
Michael> (Sorry, not quite enough time to actually do it today.)
No problem. I need to take a brake today too and who knows about
tomorrow ;-) It would be nice to compete the job now when we are
close. We'll see what we can swing.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:44 p.m.
>>>> Michael Sperber <sperber(a)deinprogramm.de>
writes:
> ?: "./src/s/freebsd.h"
> ?: "./src/s/netbsd.h"
Michael> But we can get those
from GNU Emacs.
The versions in GNU Emacs seems to be completely different files. Not
many #defines are the same if any. Not very likely that a substitution
will work. I don't think we have any regular netbsd nor freebsd user
that builds the system and no access to such a system to try out a
build anyway. So we are lost!?
IMHO, If we can't check that we are reasonably close to a working
system we should change the files to scream during configuration or
compilation that _this OS isn't supported at the moment_. In the
GPLv3|L8R release notes we could also declare what OSs have been
tested to build at the time of the switch. That will probably be Linux
and Windows.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:18 a.m.
On Fri, 05 Nov 2010 23:44:37 +0100, Mats wrote:
I don't think we have any regular netbsd nor freebsd user that
builds
the system and no access to such a system to try out a build anyway.
So we are lost!?
Isn't at least the access part solved by just setting up a few virtual
machines?
In this day and age installing Virtualbox on your favourite system and
creating virtual FreeBSD and NetBSD "machines" is close to trivial.
Best regards,
Adam
--
"You have to photosynthesize" Adam Sjøgren
asjo(a)koldfront.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:17 p.m.
Mats Lidell writes:
will work. I don't think we have any regular netbsd nor freebsd
user
that builds the system and no access to such a system to try out a
build anyway. So we are lost!?
I'm pretty sure that both NetBSD pkgsrc and FreeBSD ports provide
XEmacs. Talk to their maintainers and see if they're interested in
helping.
GPLv3|L8R release notes we could also declare what OSs have been
tested to build at the time of the switch. That will probably be Linux
and Windows.
I run Mac OS X daily; I think Mike S does too. Mac OS X will
definitely be tested for the release, as I'll probably release from
that machine.
I can probably resurrect my NetBSD system and test there (probably
limited to build + automated test suite, but that's plenty for this
purpose).
I thought Mike used to use FreeBSD. Anyway, I'm sure a call for
volunteers here will scare up at least one.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:27 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> I thought Mike used to use FreeBSD.
Yes, he does. (So again I stand corrected. Nice!) And Adam has set up
build slaves. This is looking great.
Stephen> Anyway, I'm sure a call for volunteers here will scare up at
Stephen> least one.
I hope so. I don't want to hold the GPLv3 or later release because of
some system we can't build for. But then again we are not there yet.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:02 a.m.
Mats Lidell writes:
I don't want to hold the GPLv3 or later release because of some
system we can't build for.
I don't understand what you're worried about. We haven't worried
about building any systems other than those the core developers or
noisy testers use in a decade. Why would we start now?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:43 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> I don't understand what you're worried about. We haven't
Stephen> worried about building any systems other than those the core
Stephen> developers or noisy testers use in a decade. Why would we
Stephen> start now?
Well, oh, that if fine by me. I just thought that ... well never mind
what I thought.
Besides thanks to Adam Sjøgren we will soon have build slaves for
netbsd and freebsd.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:51 a.m.
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
Stephen> I don't understand what you're worried about. We haven't
Stephen> worried about building any systems other than those the core
Stephen> developers or noisy testers use in a decade. Why would we
Stephen> start now?
Well, oh, that if fine by me. I just thought that ... well never mind
what I thought.
Well, there was some discussion (and action) toward getting rid of
some platforms that really are probably extinct. But that list was
based on the GNU removal of support for those platforms and consensus
that they are extinct for all practical purposes.
If we get a request about one of those, something can be done. But
for platforms like *BSD, recently work has been done on them, and
they're known to be in active development even if we're not following
them in our core work.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:10 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> But for platforms like *BSD, recently work has been done on
Stephen> them, and they're known to be in active development even if
Stephen> we're not following them in our core work.
Thanks to Adam Sjøgren we now have three new build slaves in the
xemacs-buildbot. The slaves build netbsd, openbsd and
freebsd. (Unfortunately they don't build cleanly so please check them
out in order to help fix the builds to go from red to green!)
"http://lidell.nu/xemacs-buildbot/"
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:44 p.m.
New subject: FreeBSD, NetBSD and OpenBSD buildslaves added (was: GPLv3/L8R -- status report)
On Mon, 08 Nov 2010 22:10:59 +0100, Mats wrote:
Thanks to Adam Sjøgren we now have three new build slaves in the
xemacs-buildbot. The slaves build netbsd, openbsd and
freebsd. (Unfortunately they don't build cleanly so please check them
out in order to help fix the builds to go from red to green!)
Some/all of the problems may be due to me not configuring something on
the three newly created and installed virtual machines - so don't
hesitate to tell me what I have done wrong/should try.
The compilation failures fall in these categories:
,----[ NetBSD cfg0, NetBSD cfg2, OpenBSD cfg0, OpenBSD cfg2 ]
| Dumping under the name xemacs
|
| XEmacs: fatal error: Couldn't find segment next to .bss in
/home/buildbot/asjo_netbsd_cfg0/build/src/temacs
`----
,----[ NetBSD cfg3, OpenBSD cfg3 ]
| unexelf.c:489:5: warning: "__GNU_LIBRARY__" is not defined
| unexelf.c: In function 'int unexec(Extbyte*, Extbyte*, __uintptr_t, __uintptr_t,
__uintptr_t)':
| unexelf.c:696: error: cast from 'void*' to 'Elf32_Addr' loses precision
`----
,----[ FreeBSD cfg2 ]
| Dumping under the name xemacs
| ./xemacs -no-packages -batch -no-autoloads -l update-elc-2.el -f batch-update-elc-2
/usr/home/buildbot/asjo_freebsd_cfg2/build/src/../lisp
| gmake[1]: *** [update-elc-2] Segmentation fault: 11 (core dumped)
`----
,----[ FreeBSD cfg3 ]
|
EmacsFrame.o(.eh_frame+0x12):/usr/home/buildbot/asjo_freebsd_cfg3/build/src/lrecord.h:1850:
more undefined references to `__gxx_personality_v0' follow
| gmake[1]: gmake[1]: Leaving directory
`/usr/home/buildbot/asjo_freebsd_cfg3/build/src'
| *** [temacs] Error 1
`----
,----[ OpenBSD cfg1 ]
| /usr/include/gmp.h:2182: error: declaration of C function 'std::istream&
operator>>(std::istream&, __mpf_struct*)' conflicts with
| /usr/include/gmp.h:2181: error: previous declaration 'std::istream&
operator>>(std::istream&, __mpq_struct*)' here
| gmake[1]: *** [abbrev.o] Error 1
`----
Details on Mats' buildbot site: http://lidell.nu/xemacs-buildbot/builders
Any tips and pointers are much appreciated.
I will add an OpenSolaris buildslave as well, soonish.
Best regards,
Adam
--
"Angels can fly because they take themselves lightly." Adam Sjøgren
asjo(a)koldfront.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:08 p.m.
On Mon, Nov 8, 2010 at 2:10 PM, Mats Lidell <matsl(a)xemacs.org> wrote:
Thanks to Adam Sjøgren we now have three new build slaves in the
xemacs-buildbot. The slaves build netbsd, openbsd and
freebsd. (Unfortunately they don't build cleanly so please check them
out in order to help fix the builds to go from red to green!)
"http://lidell.nu/xemacs-buildbot/"
Yours
--
%% Mats
Well, randomly choosing the first failing build, I see that it is a
64-bit OpenBSD build. The error that halts the build is this:
unexelf.c: In function 'int unexec(Extbyte*, Extbyte*, uintptr_t,
uintptr_t, uintptr_t)':
unexelf.c:696: error: cast from 'void*' to 'Elf32_Addr' loses precision
gmake[1]: *** [unexelf.o] Error 1
gmake[1]: Leaving directory `/home/buildbot/asjo_openbsd_cfg3/build/src'
gmake: *** [src] Error 2
Notice that is "Elf32" instead of "Elf64". Somehow, we managed to
get
the wrong word size in our definition of ElfW. Is sys/exec_elf.h
supposed to provide that definition? See lines 477 to 499 in
unexelf.c.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:26 p.m.
On Mon, 8 Nov 2010 16:08:40 -0700, Jerry wrote:
unexelf.c: In function 'int unexec(Extbyte*, Extbyte*,
uintptr_t,
uintptr_t, uintptr_t)':
unexelf.c:696: error: cast from 'void*' to 'Elf32_Addr' loses precision
[..]
gmake[1]: Leaving directory
`/home/buildbot/asjo_openbsd_cfg3/build/src'
[..]
Notice that is "Elf32" instead of "Elf64".
Somehow, we managed to get
the wrong word size in our definition of ElfW. Is sys/exec_elf.h
supposed to provide that definition? See lines 477 to 499 in
unexelf.c.
It doesn't seem to do so on the OpenBSD I am running¹:
$ grep ElfW /usr/include/sys/exec_elf.h
$ grep -Ri ElfW /usr/include/
$ head -1 /usr/include/sys/exec_elf.h
/* $OpenBSD: exec_elf.h,v 1.48 2010/06/07 09:41:16 sthen Exp $ */
$
Best regards,
Adam
¹ OpenBSD 4.8 (GENERIC) #182: Mon Aug 16 09:02:40 MDT 2010
--
"Grr. Very annoyingly non-obvious." Adam Sjøgren
asjo(a)koldfront.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:05 p.m.
On Thu, 11 Nov 2010 21:26:40 +0100, Adam wrote:
> Notice that is "Elf32" instead of "Elf64".
Somehow, we managed to get
> the wrong word size in our definition of ElfW. Is sys/exec_elf.h
> supposed to provide that definition? See lines 477 to 499 in
> unexelf.c.
_LP64 is 1, so perhaps OpenBSD should be somehow included in lines
481-487, to take care of it?
Maybe something like this:
--- a/src/unexelf.c Tue Nov 02 20:19:39 2010 +0100
+++ b/src/unexelf.c Thu Nov 11 23:00:20 2010 +0100
＠＠ -478,7 +478,7 ＠＠
# include <sys/exec_elf.h>
#endif
-#if defined(__FreeBSD__) && (defined(__alpha__) || defined(_LP64))
+#if (defined(__FreeBSD__) && (defined(__alpha__) || defined(_LP64))) ||
(defined(__OpenBSD__) && defined(_LP64))
# ifdef __STDC__
# define ElfW(type) Elf64_##type
# else
(I am merely guessing; I have no clue, so don't hesitate to hit me with
a cluebat.)
Best regards,
Adam
--
"Grr. Very annoyingly non-obvious." Adam Sjøgren
asjo(a)koldfront.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:50 p.m.
New subject: Building on 64 bit OpenBSD; ElfW
So, previously¹ I suggested this change, to make the OpenBSD builds²
progress a little further:
On Thu, 11 Nov 2010 22:05:58 +0100, Adam wrote:
-#if defined(__FreeBSD__) && (defined(__alpha__) ||
defined(_LP64))
+#if (defined(__FreeBSD__) && (defined(__alpha__) || defined(_LP64))) ||
(defined(__OpenBSD__) && defined(_LP64))
[...]
(I am merely guessing; I have no clue, so don't hesitate to hit
me with
a cluebat.)
Didn't quite gather any comments. So maybe this is more like it:
--- a/src/unexelf.c Tue Nov 02 20:19:39 2010 +0100
+++ b/src/unexelf.c Tue Nov 16 21:40:23 2010 +0100
＠＠ -491,10 +491,18 ＠＠
#endif
#ifndef ElfW
-# ifdef __STDC__
-# define ElfW(type) Elf32_##type
+# ifdef _LP64
+# ifdef __STDC__
+# define ElfW(type) Elf64_##type
+# else
+# define ElfW(type) Elf64_/**/type
+# endif
# else
-# define ElfW(type) Elf32_/**/type
+# ifdef __STDC__
+# define ElfW(type) Elf32_##type
+# else
+# define ElfW(type) Elf32_/**/type
+# endif
# endif
#endif
?
Best regards,
Adam
¹ http://article.gmane.org/gmane.emacs.xemacs.beta/33925
² http://lidell.nu/xemacs-buildbot/builders/amd64%20openbsd%20cfg3/builds/3
--
"Right. Why waste time learning, Adam Sjøgren
when ignorance is instantaneous?" asjo(a)koldfront.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:01 p.m.
New subject: Building on 64 bit OpenBSD; ElfW
Hi Adam
You wrote:
Adam> So, previously¹ I suggested this change, to make the OpenBSD
Adam> builds² progress a little further:
I suggest that you provide a patch, eg. changeset, with ChangeLog and
all to possibly get some more attention. If you can, use patcher to
construct the mail. Send it to xemacs-patches. Mark is with [AC21.5].
This has two positive effects as I see it:
1. The patch stands out as just a little more serious (not that I
find that your current mail should not be taken seriously. (Huh
double negations, read with care.))
2. Is easy to apply locally for testing and possibly commit and push
by someone with rights to do that. (With the support of the
current build slaves it should be quite OK to commit and push just
using inspection of this type of patch IMHO since there will be
feedback.)
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:27 a.m.
New subject: Building on 64 bit OpenBSD; ElfW
Mats Lidell writes:
I suggest that you provide a patch, eg. changeset, with ChangeLog
and
all to possibly get some more attention. If you can, use patcher to
construct the mail. Send it to xemacs-patches. Mark is with
[AC21.5].
Just "[21.5]"; Adam isn't on the Review Board yet. Applications and
recommendations may be sent to xemacs-review(a)xemacs.org, as usual,
though.:-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:03 a.m.
New subject: Building on 64 bit OpenBSD; ElfW
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> Just "[21.5]"; Adam isn't on the Review Board yet.
Of course.
This conversation triggered me to search xemacs.org for docs and I
found them! :-) I enclose the link below as a reminder to myself to
actually read the docs sometime and possibly as pointer to anyone else
who wonders about these annotations used with the patches.
http://www.xemacs.org/Documentation/sources/xemacs-packages/packages/xema...
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
12:38 p.m.
New subject: Building on 64 bit OpenBSD; ElfW
On Wed, 17 Nov 2010 00:01:04 +0100, Mats wrote:
I suggest that you provide a patch, eg. changeset, with ChangeLog
and
all to possibly get some more attention. If you can, use patcher to
construct the mail. Send it to xemacs-patches. Mark is with [AC21.5].
I understand that it is nice to have people use your specialized tools
and workflows to submit patches.
But you are also creating a barrier to contribution with them.
I could probably have read about how to find/install/configure patcher,
figured out the preferred way to write ChangeLog messages for XEmacs,
that I should mark the email with [21.5], and send it to xemacs-patches
- if I thought I was ready to actually send patches that I would have
committed myself had I had a commit-bit.
But I am not at that stage in contributing yet - I am basically learning
to crawl before I walk. The two patches I sent was me trying to start a
discussion: "Is this the right way to fix this problem? Or maybe this
is?"
By including a patch in my question, I hoped to indicate that I actually
took the time to try a fix for the problem, and that I did try to
configure+compile with the change - that I wasn't just randomly making
stuff up.
I had hoped for one of two outcomes: Someone either says "Yeah, that's a
good fix", or says "No, it should be done in this way instead", and
either commits it with the appropriate extra bits and bobs, or says I
should submit the suggested, corrected solution through the proper channels.
As a green newcomer, I don't want to learn - and go through - all the
hoops to send a patch only to have someone say that it should have been
fixed in a slightly different way.
Maybe I am too lazy to contribute, I don't know :-)
Best regards,
Adam
--
"Right. Why waste time learning, Adam Sjøgren
when ignorance is instantaneous?" asjo(a)koldfront.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:47 p.m.
New subject: Building on 64 bit OpenBSD; ElfW
Adam Sjøgren writes:
On Wed, 17 Nov 2010 00:01:04 +0100, Mats wrote:
> I suggest that you provide a patch, eg. changeset, with ChangeLog and
> all to possibly get some more attention. If you can, use patcher to
> construct the mail. Send it to xemacs-patches. Mark is with [AC21.5].
I understand that it is nice to have people use your specialized tools
and workflows to submit patches.
Patcher is not a specialized tool. It's a generic tool that (I
imagine) was developed with XEmacs in mind, but it works for *any*
diff-and-patch-based workflow.
The requirements are
(1) context diffs (diff -c is OK, diff -u is better, hg diff is best)
(2) except for ChangeLogs, where plain text or diff -U 0 is required
(otherwise you're almost guaranteed a failed patch application)
(3) send it to xemacs-patches(a)xemacs.org if the patch works for you,
unless you know there's a good reason it should *not* be applied
(patches sent to xemacs-beta are assumed to be not ready to be
applied; when in doubt, send to xemacs-patches or both).
I don't see anything unusual or difficult there, unless you've never
contributed to any project on the 'net before. The suggestion to use
patcher is because that after you configure it for XEmacs once, (1),
(2), and (3) are automatic. You don't have to use patcher, though (I
don't, at the moment, my configurations all broke when I rearranged my
home directory a few months ago; OK, so some dummies like me have to
configure it twice :-).
I had hoped for one of two outcomes: Someone either says "Yeah,
that's a
good fix", or says "No, it should be done in this way instead", and
either commits it with the appropriate extra bits and bobs, or says I
should submit the suggested, corrected solution through the proper channels.
That's a reasonable hope, and what normally happens with Linux-
oriented or platform-independent contributions. But in this case
perhaps a bit optimistic, as this is a rather technical detail, and we
don't have active OpenBSD-based developers at this point. I know that
Aidan did some work on it years ago, but I don't think it's a usual
platform for him.
That is, you're probably the best expert we've got. :-) And yes, I
know what I'm saying. :-)
As a green newcomer, I don't want to learn - and go through - all
the
hoops to send a patch only to have someone say that it should have been
fixed in a slightly different way.
You don't have to learn them. The only folks who *have* to learn them
are the reviewers.
But if the patch is undocumented (minimum of a ChangeLog entry), or it
doesn't apply, or it is directed to the wrong list, it is less likely
to get the attention it deserves. And every project I've ever worked
on works that way; some are much more formal. We're not going to
deliberately ignore your patch, but with no expertise on that
platform, everybody is hoping for somebody else to do something. I
know I'm hoping Aidan will, because I don't expect to have time to
work on code I don't understand until Christmastime. :-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:40 p.m.
New subject: Building on 64 bit OpenBSD; ElfW
On Thu, 18 Nov 2010 01:47:46 +0900, Stephen wrote:
> I understand that it is nice to have people use your specialized
tools
> and workflows to submit patches.
Patcher is not a specialized tool.
Ok; I have never heard of it outside XEmacs, and I have been running
GNU/Linux exclusively since autumn 1994.
Granted, I have only contributed with very teeny tiny couple-of-lines
patches to various things (Gnus, DBD::Pg, BioPerl, XEmacs, PostgreSQL).
Now that I am whining anyway: I find the emails in xemacs-patches wholly
confusing; often the same patch is posted multiple times, and then
months later with a different prefix in the Subject header, and so on.
[... How to make patches ...]
I don't see anything unusual or difficult there, unless
you've never
contributed to any project on the 'net before.
I agree, but you are missing my point entirely.
Every project has different ways to receive contributions (this or that
option to diff, this or that mailing list, patches inline, in
attachments, uploaded to a bugtracker, pull requests, etc. etc.).
I am lazy, so I don't care to study those requirements _until_ I think
what I am contributing is good enough to go straight in without any
checking (which it of course will get anyway) or modification. Until
then, I am merely discussing and suggesting on the mailinglist for
discussions.
I can see now that it was a mistake to include a patch as part of my
discussion here. Other places a patch signifies "At least he is serious
enough to try fixing it himself, he isn't only whining".
[... hoping for feedback ...]
But in this case perhaps a bit optimistic, as this is a rather
technical detail, and we don't have active OpenBSD-based developers at
this point.
Perhaps it is optimistic, but is the solution really to submit the patch
in exactly the right way? Does thath magically activate experts in this
technical area?
Anyway, I don't think it requires a lot of specific OpenBSD insight to
answer - the change basically takes the observation by Jerry James (Hey,
ElfW ends up being 32-bit) and tries to remedy it by looking at a
compiler-define. _LP64 is a generic define that gcc sets if the platform
is 64 bit - there is no esoteric OpenBSD-specific stuff in the question.
That is, you're probably the best expert we've got. :-) And
yes, I
know what I'm saying. :-)
I know the changes I suggested make the build continue further on
OpenBSD, that isn't what I am asking (maybe I am also being unclear on
that); what I was trying to say was: "Does this change look reasonable
seen from an XEmacs-codebase perspective?"
> As a green newcomer, I don't want to learn - and go through -
all the
> hoops to send a patch only to have someone say that it should have been
> fixed in a slightly different way.
You don't have to learn them. The only folks who *have* to learn
them
are the reviewers.
It seems I do, because the only reply to my attempts to move this build
along has been suggestions to follow the rules to make my patch look
less unserious (which isn't what I aimed for, but anyway).
But if the patch is undocumented (minimum of a ChangeLog entry), or
it
doesn't apply, or it is directed to the wrong list, it is less likely
to get the attention it deserves. And every project I've ever worked
on works that way; some are much more formal. We're not going to
deliberately ignore your patch, but with no expertise on that
platform, everybody is hoping for somebody else to do something. I
know I'm hoping Aidan will, because I don't expect to have time to
work on code I don't understand until Christmastime. :-)
I must have been very unclear. I wasn't trying to ask for an OpenBSD
developer to jump up from under a rock, I was trying to ask whether the
change illustrated makes sense seen through the eyes of anyone who
usually hacks on XEmacs.
And I am pretty sure that any one of you commit-bit-wielders could have
thought about _LP64 and either answered "nah, not good" or committed the
change in a fraction of the time it took to read this thread.
Best regards,
Adam
--
"Vilken sanning, Måns, är sann?" Adam Sjøgren
asjo(a)koldfront.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:37 p.m.
New subject: Building on 64 bit OpenBSD; ElfW
Adam Sjøgren writes:
Now that I am whining anyway: I find the emails in xemacs-patches
wholly
confusing; often the same patch is posted multiple times,
xemacs-patches is primarily part of the review workflow. Patches
submitted with intent to commit will be reviewed there, but design
discussion before submission (including proof-of-concept patches)
takes place on xemacs-beta. So given the intention you describe,
posting to xemacs-beta was the right thing to do. However, Mats is
also right; if there is a working patch, and nobody's doing anything
right away, xemacs-patches is where it will be found later.
The only time a non-reviewer needs to follow xemacs-patches is when
they have a patch actively in consideration, and then the normal
practice is to leave you in the Cc list, so you probably don't need to
subscribe.
Regarding duplicates, among other things, the commit notices get
posted there, as well as review notices (approvals and commits) etc.
I trim; the commit bot and lots of people don't, so you'll see the
same patch multiple times. We also have three more-or-less active
branches (21.4, 21.5, and carbon2); patches will often be submitted
for one of the above and only later determined to be relevant to
others. carbon2 also gets synched to the mainline on a fairly
irregular basis.
Perhaps it is optimistic, but is the solution really to submit the
patch
in exactly the right way? Does thath magically activate experts in this
technical area?
No and no. You are not required to submit patches in exactly the
right way. Your submissions are not moderated, and they will be
considered when somebody has the time to do so, regardless of whether
you follow the formatting recommendation. That is, if they are found
in the place where we looking for unreviewed patches: our
xemacs-patches folders.
We don't have any experts on OpenBSD or 64-bit-cleanness AFAIK;
therefore no magic will activate them.
> You don't have to learn them. The only folks who *have* to
learn them
> are the reviewers.
It seems I do, because the only reply to my attempts to move this build
along has been suggestions to follow the rules to make my patch look
less unserious (which isn't what I aimed for, but anyway).
You misunderstand the situation, then. Jerry dropped the ball; after
making some comments on the original report, he's been silent on the
subject. That happens; we are all volunteers, after all, and
sometimes real life takes precedence. When Mats recognized that, he
stepped in to try to ensure that the patch stays on our radar,
although he apparently doesn't have the expertise to review the patch
himself. Isn't that the way things *should* work?
And I am pretty sure that any one of you commit-bit-wielders could
have
thought about _LP64 and either answered "nah, not good" or committed the
change in a fraction of the time it took to read this thread.
I assure that is not true in my case. I do a build and test run
before committing, which in this case means finding a place to install
OpenBSD and installing it. Heck, before that, I'd need to find an
installable distribution. (I don't expect that would be hard, but
these little details add up to quite a time commitment.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:03 p.m.
New subject: Building on 64 bit OpenBSD; ElfW
On Thu, 18 Nov 2010 04:37:05 +0900, Stephen wrote:
You misunderstand the situation, then. Jerry dropped the ball;
after
making some comments on the original report, he's been silent on the
subject.
In my eyes Jerry James provided valuable insight into what the problem is.
I don't know how that is dropping the ball.
That happens; we are all volunteers, after all, and sometimes real
life takes precedence. When Mats recognized that, he stepped in to try
to ensure that the patch stays on our radar, although he apparently
doesn't have the expertise to review the patch himself. Isn't that the
way things *should* work?
I apologize to Mats if that was his intent - I read his email as good
advice on how to get someone to comment on the question posed.
> And I am pretty sure that any one of you commit-bit-wielders
could
> have thought about _LP64 and either answered "nah, not good" or
> committed the change in a fraction of the time it took to read this
> thread.
I assure that is not true in my case. I do a build and test run
before committing, which in this case means finding a place to install
OpenBSD and installing it. Heck, before that, I'd need to find an
installable distribution. (I don't expect that would be hard, but
these little details add up to quite a time commitment.)
I see that I have been totally unable to convey my message to you at
all.
I am NOT asking you to commit the patch, nor to try it on an OpenBSD
system. I am just, and only, asking: DOES IT LOOK SANE?
If it does, I'll be happy to read up on any procedures and submit it for
test and approval. If it doesn't, just let me know, and I will try and
adjust it.
That is the way contribution by newcomers works most places, I have
found.
Heck, I have even used it before for XEmacs:
* First attempt: http://article.gmane.org/gmane.emacs.xemacs.beta/33413
* Second attempt: http://article.gmane.org/gmane.emacs.xemacs.beta/33415
* Comment: http://article.gmane.org/gmane.emacs.xemacs.beta/33416
* Commit: http://article.gmane.org/gmane.emacs.xemacs.patches/12360
Maybe I was just lucky :-)
Best regards,
Adam
--
"They didn't care. They didn't care that they'd seen Adam
Sjøgren
it work in practise, because they already knew it asjo(a)koldfront.dk
couldn't work in theory."
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:12 p.m.
New subject: Building on 64 bit OpenBSD; ElfW
>>>> Adam Sjøgren <asjo(a)koldfront.dk> writes:
Adam> I see that I have been totally unable to convey my message to
Adam> you at all. I am NOT asking you to commit the patch, nor to try
Adam> it on an OpenBSD system. I am just, and only, asking: DOES IT
Adam> LOOK SANE?
As a set of preprocessor directives it looks quite OK but I assumed
that it was not that level of inspection you wanted? I though the
question you wanted answered was does this do the right thing?
As Stephen points out I haven't got the knowledge to answer that.
But you have tested it to some extent at least I think(?), we have
build slaves for it, why not apply and let the tests do their thing?
Adam> That is the way contribution by newcomers works most places, I
Adam> have found.
Yes, and I think it does so here too but not always. The number of
active developers does have an impact on the responsiveness.
The OS environments you have set up build slaves for is quite likely
such an area where there might not be that much response. In those
cases I suggest we try to find some way to handle it. Applying the
patches is my suggestions.
In the future I'll try to be more verbose when it comes to patches
since silence is a bad thing for a contributor. Please be patient and
stubborn and keep those patches coming.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:51 a.m.
New subject: Building on 64 bit OpenBSD; ElfW
Adam Sjøgren writes:
On Thu, 18 Nov 2010 04:37:05 +0900, Stephen wrote:
> You misunderstand the situation, then. Jerry dropped the ball; after
> making some comments on the original report, he's been silent on the
> subject.
In my eyes Jerry James provided valuable insight into what the problem is.
I don't know how that is dropping the ball.
Because in a project operated by volunteers, all work is done by
individual decision. Normally, when someone comments on an issue,
others assume he has interest *and will follow up*. They will not go
out of their to work on the issue unless they have a specific
interest. That is why we use the metaphor "pick up the ball";
typically only one person works on reviewing a given issue. If they
stop working or commenting without saying "hey, I don't have time to
work on this, will somebody pick up the slack?", that is "dropping the
ball"; somebody else needs to notice it and pick it up or nothing will
get done.
Note that I'm not criticizing Jerry; he probably looks at your message
every day thinking "I'm going to get to that later, well, tomorrow...".
But that leaves you out in the cold, so after a few days Mats stepped
up.
I see that I have been totally unable to convey my message to you at
all.
No, I understand exactly what you're saying. I'm simply explaining
why things work (or don't work, if you prefer) the way they do.
I am NOT asking you to commit the patch, nor to try it on an OpenBSD
system. I am just, and only, asking: DOES IT LOOK SANE?
I know that, and you are ignoring my answer: I myself will reserve
judgment until I know more about the problem, and can properly test
the proposal and see what happens in reality. Other reviewers work
differently, perhaps, but unfortunately none of them seems to be
available and interested in continuing work on your patch.
Since you feel it necessary to shout, I'll be more specific. My
knee-jerk response is "this kind of logic belongs in configure.ac (or
perhaps config.h.in), not in a .c file, or even .h". But that's just
my initial reaction, where I would *start* the review. Making that
judgment is not trivial for me because I know the unexec code is very
special, and because it likely implies a lot of extra work for
somebody, preferably you. Since you keep emphasizing how lazy you
are, *I* hesitate to ask. :-) Jerry can probably answer a lot more
quickly and authoritatively, but he's not posting at the moment.
If it does, I'll be happy to read up on any procedures and submit
it for
test and approval. If it doesn't, just let me know, and I will try and
adjust it.
That is the way contribution by newcomers works most places, I have
found.
You are clearly not getting *my* message, which is that most of the
time that is the way things work here.
Since you don't want to do it yourself, I have reposted your patches
with a ChangeLog to XEmacs Patches. It is, of course, better from our
point of view if you do it. That saves us a bit of time and in some
sense increases your attachment to XEmacs. That's why Mats asked you
to do that. But it's not a big deal for me to do it, of course.
However, the rest of the thread is not responding to your patch; it's
responding to your comments about the workflow. If you think our
workflow is broken, I want to explain how it really works. Even
though I would like to improve it, changing workflows in a project
with a history as long as ours takes quite a long time and much
effort; it probably won't happen quickly enough to make you happy.
Heck, I have even used it before for XEmacs:
Maybe I was just lucky :-)
No, that is normal. *This time* you are unlucky.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:04 p.m.
New subject: Building on 64 bit OpenBSD; ElfW
On Thu, 18 Nov 2010 12:51:21 +0900, Stephen wrote:
Normally, when someone comments on an issue, others assume he has
interest *and will follow up*.
[...]
Ok, I guess I am just not used to this kind of "onemanship" in Free
Software.
I am more used to "everybody pitches in with whatever they have time for
to keep the ball moving forward", rather than "if anybody has responded
at all, it is their responsibility to take it all the way".
> I see that I have been totally unable to convey my message to you
at
> all.
No, I understand exactly what you're saying. I'm simply
explaining
why things work (or don't work, if you prefer) the way they do.
I am sorry, but we will have to disagree on this.
If I had been able to express myself clearly, you would never have
mailed the patches I sent here to xemacs-patches.
[...]
Since you feel it necessary to shout, I'll be more specific. My
knee-jerk response is "this kind of logic belongs in configure.ac (or
perhaps config.h.in), not in a .c file, or even .h". But that's just
my initial reaction, where I would *start* the review. Making that
judgment is not trivial for me because I know the unexec code is very
special, and because it likely implies a lot of extra work for
somebody, preferably you. Since you keep emphasizing how lazy you
are, *I* hesitate to ask. :-) Jerry can probably answer a lot more
quickly and authoritatively, but he's not posting at the moment.
Thank you for elaborating on your thoughts.
The above was in no way obvious to me; especially since the .c file
already has special cases for other operating systems (FreeBSD, for
instance).
This is the closest you have been to answering the question I was trying
to ask.
[...]
Since you don't want to do it yourself, I have reposted your
patches
with a ChangeLog to XEmacs Patches.
And with this, my communication has failed totally and utterly.
I shall refrain from trying any more - apparantly I am simply unable to
communicate clearly in this context.
Best regards,
Adam
--
"I myself have spent many an enjoyable hour in my Adam Sjøgren
spare time not collecting stamps." asjo(a)koldfront.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:52 a.m.
New subject: Building on 64 bit OpenBSD; ElfW
On Wed, Nov 17, 2010 at 1:03 PM, Adam Sjøgren <asjo(a)koldfront.dk> wrote:
On Thu, 18 Nov 2010 04:37:05 +0900, Stephen wrote:
> You misunderstand the situation, then. Jerry dropped the ball; after
> making some comments on the original report, he's been silent on the
> subject.
In my eyes Jerry James provided valuable insight into what the problem is.
I don't know how that is dropping the ball.
Looks like I misunderstood the question, too. I also thought you were
proposing a final ready-to-commit patch. So my intent was to install
an OpenBSD virtual machine so I could try the patch out where it
matters. However, I have consistently failed to come up with the
necessary amount of free time since then, which is why I've remained
silent. Real Life has been keeping me away from my hobbies pretty
consistently for the last several months.
I echo what Mats had to say about all this, too.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:52 p.m.
On 11/ 7/10 03:02 AM, Stephen J. Turnbull wrote:
I don't understand what you're worried about. We haven't
worried
about building any systems other than those the core developers or
noisy testers use in a decade. Why would we start now?
I hope that I have been noisy enough for the last decade about
Solaris to add that to the list. I will do the testing, but, for
various reasons, I'd like to wait until after the release if that's OK.
Thanks.
Rodney
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:25 a.m.
Rodney Sparapani writes:
I hope that I have been noisy enough for the last decade about
Solaris to add that to the list. I will do the testing, but, for
various reasons, I'd like to wait until after the release if that's OK.
Well, that's up to you, but that means that any fixes needed for
Solaris won't appear in a released version until the next release.
You personally will have to either patch locally or use a Mercurial
checkout to get a working XEmacs.
So what it amounts to is a bet that there won't be any Solaris-related
issues in XEmacs 21.5.30. Wanna bet? :-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:49 p.m.
On 11/ 9/10 03:25 AM, Stephen J. Turnbull wrote:
Well, that's up to you, but that means that any fixes needed for
Solaris won't appear in a released version until the next release.
You personally will have to either patch locally or use a Mercurial
checkout to get a working XEmacs.
So what it amounts to is a bet that there won't be any Solaris-related
issues in XEmacs 21.5.30. Wanna bet? :-)
I understand the risks. It has more to do with our local setup
here than anything XEmacs related. But, I would be willing to
bet $0.02 that there are no Solaris-related bugs. With the
approaching deflation $0.02 might be a lot of money some day :o)
--
Rodney Sparapani Center for Patient Care and Outcomes Research
Sr. Biostatistician http://www.mcw.edu/pcor
4 wheels good, 2 wheels better! Medical College of Wisconsin (MCW)
WWLD?: What Would Lombardi Do? Milwaukee, WI, USA
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:33 p.m.
Rodney Sparapani writes:
I understand the risks.
OK, just wanted to make sure. I hope you understood from the phrasing
that I don't think you owe XEmacs anything; you've done your share in
the past, and I know you'd step up to the plate if needed.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:23 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> So what it amounts to is a bet that there won't be any
Stephen> Solaris-related issues in XEmacs 21.5.30. Wanna bet? :-)
We'll soon see. Adam has plans on starting a build slave running open
solaris. That should provide some answers! And at the rate he is
working it is soon time to stop the betting ;-)
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:05 p.m.
On Tue, 09 Nov 2010 22:23:04 +0100, Mats wrote:
We'll soon see. Adam has plans on starting a build slave running
open
solaris. That should provide some answers! And at the rate he is
working it is soon time to stop the betting ;-)
It is running now:
* http://lidell.nu/xemacs-buildbot/buildslaves/asjo-amd64-opensolaris
:-),
Adam
--
"This whole business of Santa rewarding good kids and Adam Sjøgren
neglecting bad kids really bugs me." asjo(a)koldfront.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:45 p.m.
Hi Adam
You wrote:
Adam> It is running now:
Adam> * http://lidell.nu/xemacs-buildbot/buildslaves/asjo-amd64-opensolaris
Thanks Adam for setting them up and providing the CPU-cycles!
Do you have any more build slaves up your sleeve or can I get back to
the GPLv3 or later conversion now? ;-)
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:20 p.m.
On Thu, 11 Nov 2010 22:45:06 +0100, Mats wrote:
Thanks Adam for setting them up and providing the CPU-cycles!
Do you have any more build slaves up your sleeve
I think that is basically it - I don't think I can run any of the
remaining platforms mentioned on http://www.xemacs.org/Download/index.html :-)
or can I get back to the GPLv3 or later conversion now? ;-)
Ah, bugger, I certainly didn't mean to slow you down in doing that!
Best regards,
Adam
--
"I'm not sure it never causes any harm to all users." Adam Sjøgren
asjo(a)koldfront.dk
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:01 p.m.
On 11/ 8/10 09:52 AM, Rodney Sparapani wrote:
I hope that I have been noisy enough for the last decade about
Solaris to add that to the list. I will do the testing, but, for
various reasons, I'd like to wait until after the release if that's OK.
Thanks.
Rodney
Promises, promises. After 20 years on UNIX, mostly on Solaris, we are
in the process of moving to, <gasp>, Linux. Therefore, I am afraid
that I have to retract my earlier promise to test on Solaris. However,
I am willing to test on RHEL. Thanks.
Rodney
Go Packers!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5396
days inactive
5481
days old
40 comments
7 participants
participants (7)
-
Adam Sjøgren -
Jerry James -
Mats Lidell -
Michael Sperber -
Rodney Sparapani -
Stephen J. Turnbull -
The XEmacs Package Smoketest