Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] Analysis of build results for 2014-04-19
Date: Wed, 23 Apr 2014 00:14:26 +0200	[thread overview]
Message-ID: <5356E9C2.9050900@mind.be> (raw)
In-Reply-To: <20140422221958.6240077e@skate>

On 22/04/14 22:19, Thomas Petazzoni wrote:
> Dear Arnout Vandecappelle,
> 
> On Tue, 22 Apr 2014 18:41:34 +0200, Arnout Vandecappelle wrote:
> 
>>  I think there should be two changes to the autobuilders.
>>
>> - Reduce the % yes. With the growing number of packages, the number of
>> selected packages is also becoming unrealistically large.
> 
> True. Currently the KCONFIG_PROBABILITY is chosen between 1% and 35%.
> Should I reduce that to 30% ? 25% ?

 25% still means 300 packages, and I think that that doesn't even include
their dependencies. Isn't that exaggerated? I think that any defconfig
with more than 50 packages is not very realistic anymore...

 Also, the interesting failures (with missing dependencies) are more
likely to fall out when less packages are selected, right?

 So my suggestion is to reduce the probability to 15% (still 180 packages
in the defconfig...).

>> - If webkit is selected, increase the timeout with an hour. I don't know
>> how easy that is, though.
> 
> Not easy with the current horrible script, because the timeout is
> chosen in a shell script that runs the Python script that actually
> generates the configuration and runs the build.
> 
> So let's say that I'll reduce the KCONFIG_PROBABILITY on one side, and
> increase the timeout for all builds by an hour on the other side. How
> does that look?

 The timeout is already 4 hours, isn't it? That's already quite long IMHO.


 Regards,
 Arnout

> 
>>  It would of course be even better if the autobuilder would calculate the
>> timeout based on historical information from build-time.log, but I guess
>> that's a bit too ambitious :-)
> 
> Hmmm, sounds fun! But I'd prefer to keep the autobuilder logic smaller
> in size than Buildroot itself, if possible :-)
> 
> 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

  reply	other threads:[~2014-04-22 22:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-20  6:30 [Buildroot] [autobuild.buildroot.net] Build results for 2014-04-19 Thomas Petazzoni
2014-04-20  8:48 ` [Buildroot] Analysis of build " Thomas Petazzoni
2014-04-20 13:09   ` Mike Zick
2014-04-21 17:35   ` Luca Ceresoli
2014-04-22 20:25     ` [Buildroot] php / snmp / iconv problem Thomas Petazzoni
2014-04-23  1:17       ` Gustavo Zacarias
2014-04-22 16:41   ` [Buildroot] Analysis of build results for 2014-04-19 Arnout Vandecappelle
2014-04-22 20:19     ` Thomas Petazzoni
2014-04-22 22:14       ` Arnout Vandecappelle [this message]
2014-04-23  7:22         ` Thomas Petazzoni
2014-04-23  8:51           ` Arnout Vandecappelle
2014-04-23  8:56             ` Jeremy Rosen
2014-04-23  9:02               ` Arnout Vandecappelle
2014-04-23  9:05               ` Thomas Petazzoni
2014-04-23  8:59             ` Thomas Petazzoni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5356E9C2.9050900@mind.be \
    --to=arnout@mind.be \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox