|
From: Tom H. <th...@cy...> - 2004-02-25 03:01:44
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-02-25 03:00:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow make[3]: Entering directory `/tmp/valgrind.17591/valgrind/coregrind/arch' make[3]: Nothing to be done for `check-am'. make[3]: Leaving directory `/tmp/valgrind.17591/valgrind/coregrind/arch' make[2]: Leaving directory `/tmp/valgrind.17591/valgrind/coregrind/arch' Making check in . make[2]: Entering directory `/tmp/valgrind.17591/valgrind/coregrind' source='vg_scheduler.c' object='vg_scheduler.o' libtool=no \ depfile='.deps/vg_scheduler.Po' tmpdepfile='.deps/vg_scheduler.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include -I./x86 -DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -Winline -Wall -Wshadow -O -fno-omit-frame-pointer -mpreferred-stack-boundary=2 -g -DELFSZ=32 -c `test -f 'vg_scheduler.c' || echo './'`vg_scheduler.c In file included from vg_scheduler.c:1286: /usr/include/pthread.h:163: parse error before "__thread" /usr/include/pthread.h:165: `pthread_create' declared as function returning a function /usr/include/pthread.h:166: parse error before "void" /usr/include/pthread.h:591: storage class specified for parameter `type name' make[2]: *** [vg_scheduler.o] Error 1 make[2]: Leaving directory `/tmp/valgrind.17591/valgrind/coregrind' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.17591/valgrind/coregrind' make: *** [check-recursive] Error 1 |
|
From: Ashley P. <as...@pi...> - 2004-02-25 11:12:11
|
On Wed, 2004-02-25 at 03:00, Tom Hughes wrote: > Nightly build on standard ( Red Hat 7.2 ) started at 2004-02-25 03:00:00 GMT > > Checking out source tree ... done > Configuring ... done > Building ... done > Running regression tests ... done > > Last 20 lines of log.verbose follow Is there a way to automatically filter these build logs into a different folder, I know I could do it on the subject line but I want replies to them to be handled correctly. Ideally there would be some extra header information that the autobuilders add but I can't see any. The relevant parts of my .forward file are: elif $h_to: contains kd...@kd... then save Maildir/.Lists.valgrind.cvs/ elif $h_list-post: contains val...@li... then save Maildir/.Lists.valgrind.devel/ elif $h_list-post: contains val...@li... then save Maildir/.Lists.valgrind.users/ Ashley, |
|
From: Tom H. <th...@cy...> - 2004-02-25 11:16:58
|
In message <1077707442.642.99.camel@ashley>
Ashley Pittman <as...@pi...> wrote:
> On Wed, 2004-02-25 at 03:00, Tom Hughes wrote:
>> Nightly build on standard ( Red Hat 7.2 ) started at 2004-02-25 03:00:00 GMT
>>
>> Checking out source tree ... done
>> Configuring ... done
>> Building ... done
>> Running regression tests ... done
>>
>> Last 20 lines of log.verbose follow
>
> Is there a way to automatically filter these build logs into a different
> folder, I know I could do it on the subject line but I want replies to
> them to be handled correctly. Ideally there would be some extra header
> information that the autobuilders add but I can't see any.
There aren't any special header on my autobuilder at the moment but I
could add something although I'd have to change how I send the mail.
I don't know about Julian's as I wrote my own script in the end and
his seem to have stopped at the moment anyway...
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-02-25 11:23:30
|
On Wed, 25 Feb 2004, Ashley Pittman wrote: > On Wed, 2004-02-25 at 03:00, Tom Hughes wrote: > > Nightly build on standard ( Red Hat 7.2 ) started at 2004-02-25 03:00:00 GMT > > > > Checking out source tree ... done > > Configuring ... done > > Building ... done > > Running regression tests ... done > > > > Last 20 lines of log.verbose follow > > Is there a way to automatically filter these build logs into a different > folder, I know I could do it on the subject line but I want replies to > them to be handled correctly. Ideally there would be some extra header > information that the autobuilders add but I can't see any. We need a general way to handle these regression test messages. Nightly tests are a great idea, but it's a mess at the moment, because people have only just started doing it. The test script should go into CVS, and there should be a minimal wrapper that checks out the HEAD and launches the test script (so that changes to the test script propagate to everyone's machines; hopefully the wrapper could be so simple that people could have their own local copies that wouldn't need updating). The script could also give a bit more info about the machine (eg. use uname -a, find the glibc version). And it would be nice if specifying the per-machine info was simpler. And spamming vg-dev with all the failures every day maybe isn't the best way to do it? But I can't think of anything better... N |
|
From: Ashley P. <as...@pi...> - 2004-02-25 11:50:37
|
On Wed, 2004-02-25 at 11:22, Nicholas Nethercote wrote: > On Wed, 25 Feb 2004, Ashley Pittman wrote: > > Is there a way to automatically filter these build logs into a different > > folder, I know I could do it on the subject line but I want replies to > > them to be handled correctly. Ideally there would be some extra header > > information that the autobuilders add but I can't see any. > > We need a general way to handle these regression test messages. Nightly > tests are a great idea, but it's a mess at the moment, because people have > only just started doing it. > The script could also give a bit more info about the machine (eg. use > uname -a, find the glibc version). And it would be nice if specifying the > per-machine info was simpler. And spamming vg-dev with all the failures > every day maybe isn't the best way to do it? But I can't think of > anything better... I don't mind them coming to vg-dev, we already have the CVS commits coming to this list and procmail manages to stash them out the way for me quite nicely. I find it comforting to know that things are ticking over and I know how easy it is to break code for different platforms. (I'm not a valgrind developer but live in hope that I might one day be able to use it so lurk on this list) I'm am happy with just the distribution name and version as Tom included in his header. I did find it hard to tell if some of Toms builds had passed or failed though, it looks like they passed as they don't have any of the Make: footer but in this case they probably shouldn't include the tail of the log file. Ideally procmail could filter the failed and successful ones too without having to grub inside the message contents but if there was a header to say build-log this would just be putting something in the subject which would be a good idea anyway. Ashley, |
|
From: Tom H. <th...@cy...> - 2004-02-25 12:03:47
|
In message <1077709751.657.153.camel@ashley>
Ashley Pittman <as...@pi...> wrote:
> I'm am happy with just the distribution name and version as Tom included
> in his header. I did find it hard to tell if some of Toms builds had
> passed or failed though, it looks like they passed as they don't have
> any of the Make: footer but in this case they probably shouldn't include
> the tail of the log file.
It doesn't try and work out pass/fail at the moment - it just sends
the last 20 lines of the output ;-) Strictly speaking none of them
pass as they all fail at least one regression test at the moment.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Julian S. <js...@ac...> - 2004-02-25 12:56:52
|
On Wednesday 25 February 2004 03:00, Tom Hughes wrote: > Nightly build on standard ( Red Hat 7.2 ) started at 2004-02-25 03:00:00 > `test -f 'vg_scheduler.c' || echo './'`vg_scheduler.c In file included from > vg_scheduler.c:1286: > /usr/include/pthread.h:163: parse error before "__thread" Any idea what happened here? Is it that the 7.2 pthread.h has a variable called __thread, and you are using a newer gcc which regard it as a keyword? J |
|
From: Tom H. <th...@cy...> - 2004-02-25 13:05:08
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> On Wednesday 25 February 2004 03:00, Tom Hughes wrote:
>> Nightly build on standard ( Red Hat 7.2 ) started at 2004-02-25 03:00:00
>
>> `test -f 'vg_scheduler.c' || echo './'`vg_scheduler.c In file included from
>> vg_scheduler.c:1286:
>> /usr/include/pthread.h:163: parse error before "__thread"
>
> Any idea what happened here? Is it that the 7.2 pthread.h
> has a variable called __thread, and you are using a newer gcc
> which regard it as a keyword?
Exactly. The gcc on that box had been updated to 3.2.2 but the glibc
is still an old one that uses __thread as a formal parameter name in
one of the prototypes in pthread.h.
I fixed it this morning by changing the header file to avoid the use
of __thread given that it is now a reserved word in gcc.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Julian S. <js...@ac...> - 2004-02-25 13:03:44
|
> It doesn't try and work out pass/fail at the moment - it just sends > the last 20 lines of the output ;-) Strictly speaking none of them > pass as they all fail at least one regression test at the moment. We could do with better logic for figuring out the text to be mailed to the list. What I would like to see is: - if the build failed before regression tests, the last 20 or so lines of build log, so we can see why it failed. As per last night's failed R H 7.2 build. - if the build succeeds, then I'd like to see the entire summary results of the regression tests, not just the last 20 lines. That is, I'd want to see the line == N tests, N stderr failures, N stdout failures ============= and everything thereafter. Another shortcoming of the existing code is that it doesn't stop if something breaks, eg if the cvs co fails, it keeps going anyway. This should be fixed. My only slight hesitation about putting this stuff in cvs is that anybody can run tests and so swamp the list with messages. But I guess we can deal with that if it happens. Re filtering (Ashley's original question) things we could do are: * set up a new mail list "val...@li..." and send all autobuild messages there. I'd prefer not to do this as it would require new potential contributors to be aware of, and subscribe to, the list. * include a phrase like "valgrind-nightly" in the message header or body, which can easily be spotted by mail clients? I would prefer this. J |
|
From: Ashley P. <as...@pi...> - 2004-02-25 13:20:10
|
On Wed, 2004-02-25 at 13:07, Julian Seward wrote: > My only slight hesitation about putting this stuff in cvs is that > anybody can run tests and so swamp the list with messages. But I > guess we can deal with that if it happens. The best way I can think of doing this would be to add the report generating script to CVS with a default email of `whoami`@`hostname` and just have override this yourselves in your crontab files. > Re filtering (Ashley's original question) things we could do are: > > * set up a new mail list "val...@li..." > and send all autobuild messages there. I'd prefer not to do this > as it would require new potential contributors to be aware of, > and subscribe to, the list. > > * include a phrase like "valgrind-nightly" in the message header > or body, which can easily be spotted by mail clients? I would > prefer this. This was what I was thinking of but it would also be possibly to set up a specific from address which could be filtered on if adding headers proved to be to difficult. Ashley, |