7:34 p.m.
win32.o: In function `mswindows_read_link_1':
/home/esj/xemacs-beta/src/win32.c:515: undefined reference to `_IID_IPersistFile'
/home/esj/xemacs-beta/src/win32.c:573: undefined reference to `_IID_IPersistFile'
Suggestions?
(Building under cygwin)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
7:41 p.m.
"Eric S. Johansson" <esj(a)harvee.org> writes:
/home/esj/xemacs-beta/src/win32.c:515: undefined reference to
`_IID_IPersistFile'
Suggestions?
Add to win32.c:
const GUID IID_IPersistFile;
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
8:59 p.m.
On 4/28/2011 2:41 PM, Karl Kleinpaste wrote:
"Eric S. Johansson"<esj(a)harvee.org> writes:
> /home/esj/xemacs-beta/src/win32.c:515: undefined reference to
`_IID_IPersistFile'
> Suggestions?
Add to win32.c:
const GUID IID_IPersistFile;
bug report also?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:47 p.m.
>>>> Eric S Johansson <esj(a)harvee.org> writes:
Eric> win32.o: In function `mswindows_read_link_1':
Eric> /home/esj/xemacs-beta/src/win32.c:515: undefined reference to
`_IID_IPersistFile'
Eric> /home/esj/xemacs-beta/src/win32.c:573: undefined reference to
`_IID_IPersistFile'
Eric> Suggestions?
Eric> (Building under cygwin)
Hmm... what configuration do you use? The cygwin builds in the
buildbot does not find this. (But one stumbles on another error.)
Maybe you can send a build report?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:55 p.m.
On 4/28/2011 5:47 PM, Mats Lidell wrote:
>>>>> Eric S Johansson<esj(a)harvee.org> writes:
Eric> win32.o: In function `mswindows_read_link_1':
Eric> /home/esj/xemacs-beta/src/win32.c:515: undefined reference to
`_IID_IPersistFile'
Eric> /home/esj/xemacs-beta/src/win32.c:573: undefined reference to
`_IID_IPersistFile'
Eric> Suggestions?
Eric> (Building under cygwin)
Hmm... what configuration do you use? The cygwin builds in the
buildbot does not find this. (But one stumbles on another error.)
Maybe you can send a build report?
what do you need in a build report?
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:53 p.m.
>>>> Eric S Johansson <esj(a)harvee.org> writes:
Eric> what do you need in a build report?
* Short answer:
The "Installation"-file from your build and the part of the build that
fails. Look in the root folder of your xemacs sources for the
Installation-file. Cut and Paste the relevant error messages from the
build. Send the mail to xemacs-buildreports with the subject starting
with [Failure]. Look in the archives for earlier postings.
* Longer answer for the true way:
There is a package, build, in the package tree that provides the
command build-report. So equipped with that you should be able to do
M-x built-report and be guided trough the process to create a
build-report.
* Even longer answer for a semi true way:
Unfortunately the build-report command fails for me at the moment and
have done so in the past too at occasions. And if you haven't the
packages, which can be the situation when setting up XEmacs to begin
with, your lost. For this situation, and for some other reasons, I
have created two python scripts that produces a report that is similar
to the build-report. You can browse them here:
"http://hg.debian.org/hg/xemacs/xemacs-builds/file/4c98a8044dec/matsl/build_report/"
I use them daily when building different versions of XEmacs and find
it very convenient. YMMW.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:10 p.m.
On 4/29/2011 10:53 AM, Mats Lidell wrote:
have created two python scripts that produces a report that is similar
to the build-report. You can browse them here:
"http://hg.debian.org/hg/xemacs/xemacs-builds/file/4c98a8044dec/matsl/build_report/"
I use them daily when building different versions of XEmacs and find
it very convenient. YMMW.
esj＠jumper ~/xemacs-beta
$ ./build-report
rm -f core
rm -f core lisp/auto-autoloads.el* lisp/custom-load.el*
rm -f lisp/mule/auto-autoloads.el* lisp/mule/custom-load.el*
rm -f modules/auto-autoloads.el* modules/custom-load.el*
rm -f etc/PROBLEMS
rm -f TAGS .sbinit lock/* lisp/finder-inf.el*
rm -f config.status config.log confdefs.h config-tmp-* build-install Installation
rm -f GNUmakefile Makefile Makefile.in
rm -f Installation.el Installation.elc
for d in lib-src lwlib src man ; do (cd ./$d && make distclean); done
make[1]: Entering directory `/home/esj/xemacs-beta/lib-src'
rm -f *.o *.i core
rm -f gnuclient ellcc winclient etags ctags b2m ootags gnuserv fakemail profile
make-docfile digest-doc sorted-doc movemail cvtmail hexl mmencode make-path
make-dump-id insert-data-in-exec *.exe
rm -f DOC *.tab.c *.tab.h TAGS ellcc.h blessmail config.values
rm -f GNUmakefile Makefile Makefile.in
make[1]: Leaving directory `/home/esj/xemacs-beta/lib-src'
make[1]: Entering directory `/home/esj/xemacs-beta/lwlib'
rm -f liblw.a liblw_pure_*.a *.o *.i core
rm -f config.h TAGS
rm -f GNUmakefile Makefile Makefile.in
make[1]: Leaving directory `/home/esj/xemacs-beta/lwlib'
make[1]: Entering directory `/home/esj/xemacs-beta/src'
rm -f *.o *.i *.rtl *.ln core \
temacs puremacs quantmacs covmacs rtcmacs temacs.exe \
sheap-adjust.h dump-id.c dump-size ./NEEDTODUMP SATISFIED \
../lib-src/*.po ../lib-src/*.mo
rm -f temacs.exe xemacs xemacs.dmp ../lib-src/DOC
rm -f libextcli* /home/esj/xemacs-beta/src/../lisp/auto-autoloads.el*
/home/esj/xemacs-beta/src/../lisp/custom-load.el* \
/home/esj/xemacs-beta/src/../lisp/mule/auto-autoloads.el*
/home/esj/xemacs-beta/src/../lisp/mule/custom-load.el* \
/home/esj/xemacs-beta/src/../modules/auto-autoloads.el*
/home/esj/xemacs-beta/src/../modules/custom-load.el*
rm -f config.h paths.h Emacs.ad.h /home/esj/xemacs-beta/src/../lisp/finder-inf.el* \
TAGS xemacs.def xemacs.def.in
rm -f GNUmakefile Makefile Makefile.in
make[1]: Leaving directory `/home/esj/xemacs-beta/src'
make[1]: Entering directory `/home/esj/xemacs-beta/man'
rm -f *.toc *.aux *.log *.op *.cp *.cps *.fn *.fns
rm -f *.ky *.kys *.pg *.pgs *.tp *.tps *.vr *.vrs
rm -f core *.dvi *.pdf
make[1]: Leaving directory `/home/esj/xemacs-beta/man'
sh: CONFIG: No such file or directory
make: *** No rule to make target `all'. Stop.
make: *** No rule to make target `check'. Stop.
make: Nothing to be done for `install'.
cat: Installation: No such file or directory
esj＠jumper ~/xemacs-beta
$
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:53 p.m.
>>>> Eric S Johansson <esj(a)harvee.org> writes:
Eric> esj＠jumper ~/xemacs-beta
Eric> $ ./build-report
Eric> rm -f core
[...]
Ah. Sorry. There is a README that goes with the scripts. It reads:
----------------------------------------------------------------------
Place your favorite configure variation in the file CONFIG in the
build directory. The "build-report" script will build XEmacs saving
all, or at least tries to get some, relevant details in the file
"xemacs-build-report.err". The file is possible to use as a base for
sending a build report to build-reports(a)xemacs.org.
It isn't perfect. The filter scripts requires python and sh. You may
also need to edit the line pointing out where the filter script is
placed. See "build-report" for details. It doesn't handle the multi
line patterns that the build report XEmacs package support.
----------------------------------------------------------------------
So the file "CONFIG" should look something like this: (My standard
configuration used as example. Use your own favorite configure
options)
./configure --prefix=/src/xemacs \
--with-package-path=~/.xemacs:/src/xemacs/xemacs-packages:/src/xemacs/mule-packages:/src/xemacs/site-packages\
--with-mule\
--with-newgc\
--with-xft=all
and place the file in the root folder of your XEmacs sources.
Then you run the built-report script and the build report will be in
the file xemacs-build-report.err.
Hope that helps.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:59 p.m.
On 5/1/2011 5:53 PM, Mats Lidell wrote:
>>>>> Eric S Johansson<esj(a)harvee.org> writes:
Eric> esj＠jumper ~/xemacs-beta
Eric> $ ./build-report
Eric> rm -f core
[...]
Ah. Sorry. There is a README that goes with the scripts. It reads:
----------------------------------------------------------------------
Place your favorite configure variation in the file CONFIG in the
build directory. The "build-report" script will build XEmacs saving
all, or at least tries to get some, relevant details in the file
"xemacs-build-report.err". The file is possible to use as a base for
sending a build report to build-reports(a)xemacs.org.
It isn't perfect. The filter scripts requires python and sh. You may
also need to edit the line pointing out where the filter script is
placed. See "build-report" for details. It doesn't handle the multi
line patterns that the build report XEmacs package support.
----------------------------------------------------------------------
So the file "CONFIG" should look something like this: (My standard
configuration used as example. Use your own favorite configure
options)
./configure --prefix=/src/xemacs \
--with-package-path=~/.xemacs:/src/xemacs/xemacs-packages:/src/xemacs/mule-packages:/src/xemacs/site-packages\
--with-mule\
--with-newgc\
--with-xft=all
and place the file in the root folder of your XEmacs sources.
Then you run the built-report script and the build report will be in
the file xemacs-build-report.err.
Hope that helps.
Yours
here are all the error files
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:30 p.m.
"Eric S. Johansson" <esj(a)harvee.org> writes:
win32.o: In function `mswindows_read_link_1':
/home/esj/xemacs-beta/src/win32.c:515: undefined reference to
_IID_IPersistFile'
/home/esj/xemacs-beta/src/win32.c:573: undefined reference to
_IID_IPersistFile'
I solved this one a while ago, but forget to make an official patch.
Try this and if it works I'll make one.
diff --git a/configure b/configure
--- a/configure
+++ b/configure
＠＠ -13776,7 +13776,7 ＠＠
fi
install_pp="$srcdir/lib-src/installexe.sh"
- libs_system="$libs_system -limm32 -lshell32 -lgdi32 -luser32 -lcomdlg32
-lcomctl32 -lole32 -luuid -lwinspool -lmpr" && if test "$verbose"
= "yes"; then echo " Appending \"-limm32 -lshell32 -lgdi32 -luser32
-lcomdlg32 -lcomctl32 -lole32 -luuid -lwinspool -lmpr\" to \$libs_system"; fi
+ libs_system="$libs_system -L/usr/lib/w32api -limm32 -lshell32 -lgdi32 -luser32
-lcomdlg32 -lcomctl32 -lole32 -luuid -lwinspool -lmpr" && if test
"$verbose" = "yes"; then echo " Appending \"-limm32
-lshell32 -lgdi32 -luser32 -lcomdlg32 -lcomctl32 -lole32 -luuid -lwinspool -lmpr\" to
\$libs_system"; fi
if test "$with_dragndrop" != no; then
dragndrop_proto="$dragndrop_proto msw" && if test
"$verbose" = "yes"; then echo " Appending \"msw\" to
\$dragndrop_proto"; fi
with_dragndrop=yes
diff --git a/configure.ac b/configure.ac
--- a/configure.ac
+++ b/configure.ac
＠＠ -3246,7 +3246,7 ＠＠
fi
install_pp="$srcdir/lib-src/installexe.sh"
- XE_APPEND(-limm32 -lshell32 -lgdi32 -luser32 -lcomdlg32 -lcomctl32 -lole32 -luuid
-lwinspool -lmpr, libs_system)
+ XE_APPEND(-L/usr/lib/w32api -limm32 -lshell32 -lgdi32 -luser32 -lcomdlg32 -lcomctl32
-lole32 -luuid -lwinspool -lmpr, libs_system)
if test "$with_dragndrop" != no; then
XE_APPEND(msw, dragndrop_proto)
with_dragndrop=yes
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:02 p.m.
On Fri, Apr 29, 2011 at 10:30 AM, Jeff Sparkes <jsparkes(a)gmail.com> wrote:
"Eric S. Johansson" <esj(a)harvee.org> writes:
> win32.o: In function `mswindows_read_link_1':
> /home/esj/xemacs-beta/src/win32.c:515: undefined reference to
> _IID_IPersistFile'
> /home/esj/xemacs-beta/src/win32.c:573: undefined reference to
> _IID_IPersistFile'
I solved this one a while ago, but forget to make an official patch.
Try this and if it works I'll make one.
This was also independently reported and patched as
http://tracker.xemacs.org/XEmacs/its/issue745
I committed the patch to configure.ac so you may have to run autoconf.
I marked the bug as committed. Let me know if it works and I will close it.
--
Jeff Sparkes
jsparkes(a)gmail.com
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:33 p.m.
On 5/2/2011 9:02 AM, Jeff Sparkes wrote:
On Fri, Apr 29, 2011 at 10:30 AM, Jeff
Sparkes<jsparkes(a)gmail.com> wrote:
This was also independently reported and patched as
http://tracker.xemacs.org/XEmacs/its/issue745
I committed the patch to configure.ac so you may have to run autoconf.
I marked the bug as committed. Let me know if it works and I will close it.
What
revision? When I update using all the defaults, it says I'm up-to-date
$ hg update
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:33 a.m.
Eric S. Johansson wrote:
On 5/2/2011 9:02 AM, Jeff Sparkes wrote:
> On Fri, Apr 29, 2011 at 10:30 AM, Jeff Sparkes<jsparkes(a)gmail.com> wrote:
>
> This was also independently reported and patched as
> http://tracker.xemacs.org/XEmacs/its/issue745
> I committed the patch to configure.ac so you may have to run autoconf.
> I marked the bug as committed. Let me know if it works and I will close it.
What revision? When I update using all the defaults, it says I'm up-to-date
$ hg update
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
Did you do "hg pull" before doing "hg update"? Both steps are needed
with Mercurial. (Details below.)
Also, which repository are you pulling from: xemacs-beta or xemacs?
Pushes to xemacs age for a bit before being pushed to xemacs-beta. You
can use "hg path default" to get the answer.
Here's why "pull" and "update" are separate: every Mercurial
workspace
is actually a complete repository (with history, etc). The "pull"
command updates your repository, copying over new stuff from the
repository you specified (or from the "default" repository). The
"update" command updates your "working directory" -- the snapshot you
work in, like you'd get with "cvs co" -- from your repository.
cheers,
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:29 a.m.
On 5/2/2011 8:33 PM, Mike Kupfer wrote:
Also, which repository are you pulling from: xemacs-beta or xemacs?
Pushes to xemacs age for a bit before being pushed to xemacs-beta. You
can use "hg path default" to get the answer.
$ hg path default
http://hg.debian.org/hg/xemacs/xemacs-beta
Here's why "pull" and "update" are separate:
every Mercurial workspace
is actually a complete repository (with history, etc). The "pull"
command updates your repository, copying over new stuff from the
repository you specified (or from the "default" repository). The
"update" command updates your "working directory" -- the snapshot
you
work in, like you'd get with "cvs co" -- from your repository.
cheers,
mike
That makes sense. in a case, I'm getting the same error
win32.o: In function `mswindows_read_link_1':
/home/esj/xemacs-beta/src/win32.c:513: undefined reference to `_IID_IPersistFile'
/home/esj/xemacs-beta/src/win32.c:571: undefined reference to `_IID_IPersistFile'
collect2: ld returned 1 exit status
Error reports attached
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:19 a.m.
Eric S. Johansson wrote:
$ hg path default
http://hg.debian.org/hg/xemacs/xemacs-beta
Okay, I'm not seeing any recent changesets from Jeff in either the
xemacs or xemacs-beta repos. The latest is 4486ba63476b, dated April
17th.
Jeff, did you push your change after committing it?
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:13 p.m.
Mike Kupfer <mike.kupfer(a)xemacs.org> writes:
Eric S. Johansson wrote:
> $ hg path default
> http://hg.debian.org/hg/xemacs/xemacs-beta
Okay, I'm not seeing any recent changesets from Jeff in either the
xemacs or xemacs-beta repos. The latest is 4486ba63476b, dated April
17th.
Jeff, did you push your change after committing it?
I pushed to another local repository by mistake.
It should be in the xemacs one now.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:02 a.m.
Mike Kupfer writes:
Also, which repository are you pulling from: xemacs-beta or xemacs?
Pushes to xemacs age for a bit before being pushed to xemacs-beta. You
can use "hg path default" to get the answer.
We'll see if Ben is going to produce enough churn to make it worth
maintaining xemacs-beta. For now using the xemacs branch is
recommended, until you actually experience unacceptable breakage.
Here's why "pull" and "update" are separate:
This is actually a UI bug, IMO. It makes a lot of sense for *push*
and update to be separate, because that allows a workspace-less repo
on servers. But there's very little point in making pull and update
separate, since the common case is "hg pull; hg update", not "hg pull;
manipulate revisions vs. the existing workspace; hg update". What's
even weirder is that the "hg fetch" extension does this (plus some
frills), giving hg commands nearly the exact opposite of git's.
I use "hg pull -u" ("pull and update if clean") as a matter of habit.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:55 a.m.
Jeff Sparkes writes:
This was also independently reported and patched as
http://tracker.xemacs.org/XEmacs/its/issue745
I committed the patch to configure.ac so you may have to run autoconf.
Please run autoconf yourself and commit both configure.ac and
configure in such cases for the convenience of the testers.
I marked the bug as committed. Let me know if it works and I will
close it.
As Mike K points out, I don't think you have pushed it.
Technically speaking, you're not a reviewer and you shouldn't be
pushing patches until a reviewer OKs it. This one looks reasonable to
me (as non-Windows user, though), fixes a serious build problem, and
won't be hard to back out or repair if necessary, so you may as well
push it now.
If you think you're ready for it, feel free to apply for reviewer
status (at xemacs-review(a)xemacs.org). FWIW, I won't veto it if others
are enthusiastic, but IMO the history of a couple of your recent
patches doesn't make a strong case that you have a reviewer's judgment
skills combined with the knowledge of XEmacs best practices that is
needed yet. If given that caveat you still think you're ready, go for
it. (Also, even if we decide to wait and see *now*, your name is on
my short list of candidates for the near future, and probably others'
lists as well.)
An alternative to being a reviewer is to publish your patches in a
branch at alioth. That makes it easy for beta testers to incorporate
them in their builds and test them (vs. downloading and applying
patches), but of course is somewhat greater burden on you.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:27 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
If you think you're ready for it, feel free to apply for
reviewer
status (at xemacs-review(a)xemacs.org). FWIW, I won't veto it if others
are enthusiastic, but IMO the history of a couple of your recent
patches doesn't make a strong case that you have a reviewer's judgment
skills combined with the knowledge of XEmacs best practices that is
needed yet. If given that caveat you still think you're ready, go for
it. (Also, even if we decide to wait and see *now*, your name is on
my short list of candidates for the near future, and probably others'
lists as well.)
I don't have the confidence for anything but tiny patches.
There are too many larger details I don't know yet. I'd
rather have my changes reviewed.
An alternative to being a reviewer is to publish your patches in a
branch at alioth. That makes it easy for beta testers to incorporate
them in their builds and test them (vs. downloading and applying
patches), but of course is somewhat greater burden on you.
Do you mean a branch in /hg/xemacs/xemacs? I'm kind of afraid of hg
branches; I've made a few mistakes in the xemacs-gtk repo.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:54 p.m.
Jeff Sparkes writes:
Do you mean a branch in /hg/xemacs/xemacs? I'm kind of afraid of
hg
branches; I've made a few mistakes in the xemacs-gtk repo.
Somewhere in that neighborhood, yes.
But I hear you. This is Golden Week here (several national holidays
happen to occur in the space of a week), so I'll investigate making
personal branches and add the information to
http://www.xemacs.org/Develop/hgaccess.html (or wherever it is).
In any case if you make a mistake in a separate repo, it is (at least
in theory) impossible to screw up anybody else beyond repair. :-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:34 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Stephen> so I'll investigate making personal branches and add the
Stephen> information to http://www.xemacs.org/Develop/hgaccess.html
Stephen> (or wherever it is).
I'm not sure I understand the benefits of personal branches.
Why not embrace distributed version control? Changes can be put to
review either by exporting the changeset and mail it privately or mail
it to xemacs-patches, "hg server" can be used for temporary sharing
using the built in webserver and you can even set up a repo at
BitBucket for more longterm branches. I'm sure that branch repos also
can be set up at Alioth much in the same way as for the GPLV3+-work if
the branch needs to live longer.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:14 p.m.
ClamAV 0.96
Mats Lidell writes:
I'm sure that branch repos also can be set up at Alioth much in
the
same way as for the GPLV3+-work if the branch needs to live longer.
This can be done under your alioth login ("personal") as well as in
the xemacs area. That's all I meant by "personal" (also that it
doesn't require review).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:49 p.m.
Ar an triú lá de mí Bealtaine, scríobh Jeff Sparkes:
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> An alternative to being a reviewer is to publish your patches in a
> branch at alioth. That makes it easy for beta testers to incorporate
> them in their builds and test them (vs. downloading and applying
> patches), but of course is somewhat greater burden on you.
Do you mean a branch in /hg/xemacs/xemacs? I'm kind of afraid of hg
branches; I've made a few mistakes in the xemacs-gtk repo.
Don’t use branches, there is no advantage to them over using separate
repositories, and separate repositories are a whole lot less confusing.
--
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
-- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4742
days inactive
4747
days old
22 comments
7 participants
participants (7)
-
Aidan Kehoe -
Eric S. Johansson -
Jeff Sparkes -
Karl Kleinpaste -
Mike Kupfer -
Stephen J. Turnbull -
The XEmacs Package Smoketest