From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Package informations, online and updated
Date: Sat, 4 Aug 2012 17:36:21 +0200 [thread overview]
Message-ID: <20120804173621.58fb2a87@skate> (raw)
In-Reply-To: <CAHXCMM+wipC3PvGyav=VyWVrKg5WrQvw-Ztjo+qDZaXbAE3QQg@mail.gmail.com>
Le Sat, 4 Aug 2012 14:53:28 +0200,
Samuel Martin <s.martin49@gmail.com> a ?crit :
> You're right.
> In such a case, it would be good to know that packages B, C, D has
> successfully been built at that time; package E will cause a
> build-failure, so, will trigger the "alarm" (aka, email/bug tracker
> entry/...) :).
Well, packages B, C and D have been successfully built with *that*
toolchain, or with any toolchain?
Really, because of the fact that each build is based on a random
toolchain and then a random set of packages, it's really hard to draw
definitive conclusions about when a package got broken and when it was
working.
I would rather suggest that we work towards having a 100% build success
rate, so that any build failure is considered as something to fix. Of
course, we can decide on a case by case basis to exclude certain build
scenarios from the autobuilders.
> My point is that sometimes, making some cleanup, some packages do not
> build. So, it would be useful to know if it has been built recently
> (so, in such a case the problem may be a dirty-worktree or the host
> configuration), or if there is a deeper problem due to the upgrade of
> some other packages, change in the infrastructure or anything else.
See above. A package may build successfully once, but then the next
time it doesn't build successful not because of the package being
upgraded, but because the selection of sub-options for that package is
different, because the libraries that have been built before that
package are different, etc. So defining "a package builds" is much,
much more complicated than it sounds in the first place.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
prev parent reply other threads:[~2012-08-04 15:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-31 19:37 [Buildroot] Package informations, online and updated Thomas Petazzoni
2012-08-01 18:55 ` Thomas De Schampheleire
2012-08-01 18:58 ` Thomas Petazzoni
2012-08-02 14:19 ` Alex Bradbury
2012-08-02 14:31 ` Thomas Petazzoni
2012-08-02 14:53 ` Alex Bradbury
2012-08-02 14:56 ` Thomas Petazzoni
2012-08-04 12:04 ` Samuel Martin
2012-08-04 12:30 ` Thomas Petazzoni
2012-08-04 12:53 ` Samuel Martin
2012-08-04 15:36 ` Thomas Petazzoni [this message]
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=20120804173621.58fb2a87@skate \
--to=thomas.petazzoni@free-electrons.com \
--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