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 11:02:02 +0200 [thread overview]
Message-ID: <5357818A.4090104@mind.be> (raw)
In-Reply-To: <435816036.13835416.1398243362765.JavaMail.root@openwide.fr>
On 23/04/14 10:56, Jeremy Rosen wrote:
>
>>
>>>
>>> Also, by having a much smaller percentage, I'm wondering if we have
>>> a
>>> lot less chances to trigger cases that require a fairly significant
>>> combination of options to be produced.
>>
>> Do we actually have examples of such a situation, that a combination
>> of
>> packages leads to an error? It's more likely to lead to runtime
>> errors I
>> expect.
>>
>
>
> on a side note, if the autobuilder has selected a high number of packages
> so far, there are probably many "low number of packages" type of bug
> that it could find. it might be interesting to temporarly set it to a
> low number of packages...
No, the number of packages is randomly selected between 1% and 30/35%.
So about 1 out of 6 builds has less than 5%, i.e. 30 packages. With such
a small percentage, it's extremely likely that the selected packages are
completely unrelated.
However, this makes me realize that with the lower percentages, most
likely all the sub-options of a package will be set to no. With 30%,
there's a decent chance that at least some sub-options are selected, and
at least there is some chance that all of them are selected (though for a
package with 4 suboptions the chance that all are selected is already
less than 1%). Yet another reason not to reduce the percentage any further.
It would probably be a lot better if the configurations would not use
randconfig, but rather a more customised was of selecting a random
configuration. But as usual, that's a lot of work...
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
next prev parent reply other threads:[~2014-04-23 9:02 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
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 [this message]
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=5357818A.4090104@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.