[Buildroot] [autobuild.buildroot.net] Build results for 2014-03-07

[Buildroot] [autobuild.buildroot.net] Build results for 2014-03-07

[Thomas Petazzoni]

Build statistics for 2014-03-07
===============================

        success : 71 
       failures : 22 
       timeouts : 1  
          TOTAL : 94 

Classification of failures by reason
====================================

                     wget-1.15 | 4 
                 cairo-1.12.10 | 3 
                    mpd-0.18.7 | 2 
                 lvm2-2.02.103 | 2 
zmqpp-36413487f05b165dfc82a... | 2 
                 mplayer-1.1.1 | 1 
                pulseaudio-4.0 | 1 
                  connman-1.21 | 1 
         host-python3-3.4.0rc1 | 1 
                   perl-5.18.2 | 1 
  CXX      Source/JavaScrip... | 1 
                directfb-1.6.3 | 1 
              host-scons-2.3.0 | 1 
             host-mysql-5.1.73 | 1 
                    crda-1.1.3 | 1 

Detail of failures
===================

      i686 |   CXX      Source/JavaScrip... | TIM | http://autobuild.buildroot.net/results/93a3e226f624bc389ad647014c070b66ac83de57/
      bfin |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/31e72c624dee761734b7a5abb784c44104118768/
       arm |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/7a3b43400e0189ae6c157e13ebb8d8dd2aa51db5/
       arm |                  cairo-1.12.10 | NOK | http://autobuild.buildroot.net/results/bc0fff0c4c19a39d78bf9057bf52480db414a95a/
       arm |                   connman-1.21 | NOK | http://autobuild.buildroot.net/results/41d6b62a58f38bccedab7baca6afe3b74b90ec9c/
      i686 |                     crda-1.1.3 | NOK | http://autobuild.buildroot.net/results/d8620d4c03d38bdb6564da62358788df0a88d655/
      bfin |                 directfb-1.6.3 | NOK | http://autobuild.buildroot.net/results/168f9cb06df2c3e3c267a840611c5ed0008918eb/
   powerpc |              host-mysql-5.1.73 | NOK | http://autobuild.buildroot.net/results/e094c4d05fa69155c449f09a384c191ab4b10c91/
       arm |          host-python3-3.4.0rc1 | NOK | http://autobuild.buildroot.net/results/656ae45d99d64bd61d2b4f85feb28497ea722a88/
      mips |               host-scons-2.3.0 | NOK | http://autobuild.buildroot.net/results/13dfd7fe17394bf006d24b52a56c7cf3cfb6acf2/
       arm |                  lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/60947cba5afdadaefb55b75aa600e598b3fac1b0/
       arm |                  lvm2-2.02.103 | NOK | http://autobuild.buildroot.net/results/85c55cfe574230351165ee32dfe285e3188807ff/
   powerpc |                     mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/e8ba18553e3e01df88fc9594873e9fa956cc56b8/
   powerpc |                     mpd-0.18.7 | NOK | http://autobuild.buildroot.net/results/c1d17df78cd27c55b532faf02f230b9b2d732de1/
       arm |                  mplayer-1.1.1 | NOK | http://autobuild.buildroot.net/results/e76389ef2ffe73f8e87740aa6cf06e7eafa7dc4d/
      bfin |                    perl-5.18.2 | NOK | http://autobuild.buildroot.net/results/ba71d0d532ccd8e16b727cddd5dcaa5521074945/
      bfin |                 pulseaudio-4.0 | NOK | http://autobuild.buildroot.net/results/0d2d6d2b0f2fe4dd4f8b2820a4fb03f7c772f80b/
      i686 |                      wget-1.15 | NOK | http://autobuild.buildroot.net/results/7de6e6158fbf8f52134707fcd91362b966d65dfd/
    x86_64 |                      wget-1.15 | NOK | http://autobuild.buildroot.net/results/47704bbb9e5344001a44116e7653080ef2f3e921/
   powerpc |                      wget-1.15 | NOK | http://autobuild.buildroot.net/results/96e4ca2bd68ff32747bf5da7d328a03d02326483/
       arm |                      wget-1.15 | NOK | http://autobuild.buildroot.net/results/40623a1c929643041ce65d8b4c6d98518fbe2e36/
   powerpc | zmqpp-36413487f05b165dfc82a... | NOK | http://autobuild.buildroot.net/results/ce8e7fd44b344dcdfd6b6b7320b15eb68bbc4d48/
   powerpc | zmqpp-36413487f05b165dfc82a... | NOK | http://autobuild.buildroot.net/results/04c397306ce4271a9ccefae0425fbe7858301169/


-- 
http://autobuild.buildroot.net

[Buildroot] [autobuild.buildroot.net] Build results for 2014-03-07

[Yann E. MORIN]

Thomas, All,

On 2014-03-08 08:30 +0100, Thomas Petazzoni spake thusly:
> Detail of failures
> ===================
> 
>       i686 |   CXX      Source/JavaScrip... | TIM | http://autobuild.buildroot.net/results/93a3e226f624bc389ad647014c070b66ac83de57/

This one had been running for 12663 seconds, which is 3h 31min 3s at the
moment it _started_ building webkit.

So, it looks like some of the random builds can run for more than the
limit of 4h.

Of course, I'm not saying we should bump the limit. But this is a good
example of why saving build-time.log is useful! ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [autobuild.buildroot.net] Build results for 2014-03-07

[Thomas Petazzoni]

Dear Yann E. MORIN,

On Sat, 8 Mar 2014 12:04:54 +0100, Yann E. MORIN wrote:

> On 2014-03-08 08:30 +0100, Thomas Petazzoni spake thusly:
> > Detail of failures
> > ===================
> > 
> >       i686 |   CXX      Source/JavaScrip... | TIM | http://autobuild.buildroot.net/results/93a3e226f624bc389ad647014c070b66ac83de57/
> 
> This one had been running for 12663 seconds, which is 3h 31min 3s at the
> moment it _started_ building webkit.
> 
> So, it looks like some of the random builds can run for more than the
> limit of 4h.

Yes, it seems like some builds can actually take more than 4 hours on
this machine. I would need to compare with Peter's configuration: my
script picks a random number between 1 and 35, and uses that for the
KCONFIG_PROBABILITY. So in some builds, it means that up to 35% of the
BR2_PACKAGE_<foo> options can be enabled. Maybe it's too much?

The Free Electrons build server runs 3 Buildroot builds in parallel
24/7, and during the night, a Jenkins instance builds all the Buildroot
defconfigs, which might load the machine even more. So for a given
configuration, the build time may vary quite significantly due to the
varying load of the machine.

> Of course, I'm not saying we should bump the limit. But this is a good
> example of why saving build-time.log is useful! ;-)

Have you had a look at generating the build time graphs from such longs
builds? They are completely unreadable :/

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [autobuild.buildroot.net] Build results for 2014-03-07

[Arnout Vandecappelle]

On 08/03/14 15:05, Thomas Petazzoni wrote:
> Dear Yann E. MORIN,
> 
> On Sat, 8 Mar 2014 12:04:54 +0100, Yann E. MORIN wrote:
> 
>> On 2014-03-08 08:30 +0100, Thomas Petazzoni spake thusly:
>>> Detail of failures
>>> ===================
>>>
>>>       i686 |   CXX      Source/JavaScrip... | TIM | http://autobuild.buildroot.net/results/93a3e226f624bc389ad647014c070b66ac83de57/
>>
>> This one had been running for 12663 seconds, which is 3h 31min 3s at the
>> moment it _started_ building webkit.
>>
>> So, it looks like some of the random builds can run for more than the
>> limit of 4h.
> 
> Yes, it seems like some builds can actually take more than 4 hours on
> this machine. I would need to compare with Peter's configuration: my
> script picks a random number between 1 and 35, and uses that for the
> KCONFIG_PROBABILITY. So in some builds, it means that up to 35% of the
> BR2_PACKAGE_<foo> options can be enabled. Maybe it's too much?

 35% may be a bit too much, but it's good to have high numbers in there
as well. Some packages have a 'depends on'; with a per-option probability
of 10%, these would have a probability of only 1% to be selected...

 Maybe the timeout can be made to depend on the number of packages
selected in the .config? Like 5 minutes per package (and a minimum of 1
hour)?

 Or you could add an hour to the timeout if Webkit is selected...

> 
> The Free Electrons build server runs 3 Buildroot builds in parallel
> 24/7, and during the night, a Jenkins instance builds all the Buildroot
> defconfigs, which might load the machine even more. So for a given
> configuration, the build time may vary quite significantly due to the
> varying load of the machine.
> 
>> Of course, I'm not saying we should bump the limit. But this is a good
>> example of why saving build-time.log is useful! ;-)
> 
> Have you had a look at generating the build time graphs from such longs
> builds? They are completely unreadable :/

 The time graphs are unreadable, but it's actually the build_time.log
itself that is interesting. It's easy enough to visually look for big
time jumps in there, and to check how long it was running at the last
step. (For that, however, you have to rely on the timestamp of the files
on the autobuild server, i.e. when it was uploaded, not when the build
was actually aborted. It would be nice if the end-of-build timestamp was
also saved somewhere in an "official" way.)

> 
> Thomas
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [autobuild.buildroot.net] Build results for 2014-03-07

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >  Maybe the timeout can be made to depend on the number of packages
 > selected in the .config? Like 5 minutes per package (and a minimum of
 > 1 hour)?

 >  Or you could add an hour to the timeout if Webkit is selected...

Does the build often get stuck? I don't recall seing it more than a few
times on "my" builders. In my (simplistic) autobuilder script I simply
do:

# ensure machine isn't DOS'ed
ulimit -S -t 4000 -v 2000000

E.G. limit memory and cpu time

-- 
Bye, Peter Korsgaard

[Buildroot] [autobuild.buildroot.net] Build results for 2014-03-07

[Arnout Vandecappelle]

On 10/03/14 13:12, Peter Korsgaard wrote:
>>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
> 
> Hi,
> 
>  >  Maybe the timeout can be made to depend on the number of packages
>  > selected in the .config? Like 5 minutes per package (and a minimum of
>  > 1 hour)?
> 
>  >  Or you could add an hour to the timeout if Webkit is selected...
> 
> Does the build often get stuck? I don't recall seing it more than a few
> times on "my" builders. In my (simplistic) autobuilder script I simply
> do:
> 
> # ensure machine isn't DOS'ed
> ulimit -S -t 4000 -v 2000000
> 
> E.G. limit memory and cpu time
> 

 The build doesn't really get stuck (at least, as far as we can see). It
just times out before it finishes. The cases I've looked at all end in
the middle of a Webkit build, and the webkit package is started something
like half an hour before the build is killed. Half an hour for webkit is
not exaggerated for a not-too-fast machine.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [autobuild.buildroot.net] Build results for 2014-03-07

[Thomas Petazzoni]

Dear Peter Korsgaard,

On Mon, 10 Mar 2014 13:12:21 +0100, Peter Korsgaard wrote:

>  >  Or you could add an hour to the timeout if Webkit is selected...
> 
> Does the build often get stuck? I don't recall seing it more than a few
> times on "my" builders. In my (simplistic) autobuilder script I simply
> do:

I recall adding the timeout because one particular external toolchain
had a bug in "ld" which lead to ld ending up into an infinite loop
consuming 100% of CPU time doing nothing.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com