12:29 a.m.
buildbot(a)lidell.nu writes:
The Buildbot has detected a new failure on builder x86 gentoo cfg1
while building XEmacs. Full details are available at:
http://www.lidell.nu/xemacs-buildbot/builders/x86%20gentoo%20cfg1/builds/3
BUILD FAILED: failed test
I don't understand these failures at all. There are a bunch of void
function failures, a failure to find cat(1), and some weird Unicode
errors. All this from a patch to ./INSTALL and ./ChangeLog??
So I'm going to assume it wasn't me. But I would really like to hear
from anybody who sees similar failures when doing "make check".
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:17 p.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
I don't understand these failures at all.
No, neither do I. There is some problem with either make check or the
buildbot. Sometimes we get these make check failures seemingly
stochastic. The same build can when rerun pass the tests!? Very
strange.
It is not good of course. I have had a look at it but I have so far
not been able to understand what is happening. Maybe it is time to
look deeper into this.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:29 a.m.
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)xemacs.org>
writes:
> I don't understand these failures at all.
No, neither do I. There is some problem with either make check or the
buildbot. Sometimes we get these make check failures seemingly
stochastic. The same build can when rerun pass the tests!? Very
strange.
OK. (Of course the multiple failure later *was* my fault, just to be clear.)
It is not good of course. I have had a look at it but I have so far
not been able to understand what is happening. Maybe it is time to
look deeper into this.
As long is it only happens once in a while, it doesn't really bother
me now that I know it happens to "everybody". I don't mind explaining
on xemacs-beta if it comes up. From the project's point of view, as
one reviewer I'd rather have you working on code unless it gets worse.
OTOH, it could be hardware or even some sort of security issue.
Your call.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:28 a.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
As long is it only happens once in a while, it doesn't really
bother
me now that I know it happens to "everybody".
Well is bad if you get the feeling you can't rely on the buildbot. So
far it seem to only happen to the tests so any other failure seems to
be a true problem.
Could we have some threading problem in the tests where common
resources are used in such way that the tests break? Default is to run
all builds on the same build-slave in parallel. Maybe we need
configure them to line up in sequence?
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
2:59 p.m.
Mats Lidell writes:
Could we have some threading problem in the tests where common
resources are used in such way that the tests break? Default is to run
all builds on the same build-slave in parallel.
Sad to say, yes, that certainly could be a problem, even if each build
is run in its own directory. The C code is safe, I think, because all
objects and the link are done in the subdirectory. But build/lisp is
a symlink to src/lisp. This would mean that mule builds could share
.elcs with non-mule builds, which would be a Very Bad Thing, of
course. There might be other, more subtle, conflicts, too.
Instead of just symlinking build/lisp, we could build a link farm of
files, which probably would be OK. But we're not there yet.
I've been thinking about doing that anyway. For now, I think that's a
good enough explanation of the apparently nondeterministic anomolies
in testing.
Thanks, Mats!
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:30 a.m.
>>>> Stephen J Turnbull <stephen(a)xemacs.org> writes:
Sad to say, yes, that certainly could be a problem, even if each
build is run in its own directory.
Each build do run in its own checked out directory. So the are
separated in this respect.
The C code is safe, I think, because all objects and the link are
done in the subdirectory. But build/lisp is a symlink to src/lisp.
This would mean that mule builds could share .elcs with non-mule
builds, which would be a Very Bad Thing, of course.
Since each build is in its own checked out tree this should not be a
problem either or am I missing something here?
There might be other, more subtle, conflicts, too.
I'm more thinking of this. If there are say temporary files created
outside of the checked out tree, /tmp!?, we could get a conflict.
Yours
--
%% Mats
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:53 a.m.
Mats Lidell writes:
Since each build is in its own checked out tree this should not be a
problem either or am I missing something here?
Go take a look. The Lisp is built in the *source tree*.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4131
days inactive
4135
days old
6 comments
2 participants
participants (2)
-
Stephen J. Turnbull -
The XEmacs Package Smoketest