Robert Berger wrote:
> Are your scripts available somewhere to give it a try? Do they integrate
> into autobuilder?
The scripts are hardcoded for our environment and our modified autobuilder and
are therefore not published anywhere.
While I could see us publishing these or similar snippets, I th
Paul Eggleton wrote:
> Right, that's what we would be aiming for. Perhaps you could talk a little
> bit about how you manage your hardware testing and any additional software
> and scripts you make use of there?
We run our tests from buildbot, using an expect script to allocate the right
serial p
Paul Eggleton wrote:
> We do definitely want automated testing on real hardware; it's just that
> that it presents a number of problems that need solving:
>
> * How do you deploy the image/kernel/bootloader onto the board in an
> automated manner? To different kinds of boards?
> * How do you ma
Hi.
I was reminded during the last YPTM call that it would probably be good to
write something about ptest in the manual before release.
I have written a page in the wiki about it
(https://wiki.yoctoproject.org/wiki/Ptest) but I'm not sure how to go about
adding a chapter to the manual. Are yo
Signed-off-by: Björn Stenberg
---
diff --git a/scripts/runqemu b/scripts/runqemu
index fb7ac56..fc7d749 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -155,7 +155,7 @@ while true; do
;;
"kvm")
KVM_ENABLED="yes"
-KVM_CAPABL
Signed-off-by: Björn Stenberg
---
diff --git a/scripts/runqemu b/scripts/runqemu
index fb7ac56..fc7d749 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -155,7 +155,7 @@ while true; do
;;
"kvm")
KVM_ENABLED="yes"
-KVM_CAPABL
Richard Purdie wrote:
> Would a ptest.bbclass containing the above make more sense? How
> widespread do we think these tests will be?
Most source packages include some form of test suite that we want to make into
a -ptest package. I would guesstimate the number to be somewhere between the
number
Paul Eggleton wrote:
> > +DEPCHAIN_POST = "-dev -dbg -ptest"
>
> Is this really what you want? Surely the tests for a particular piece of
> software are mostly independent of those of its dependencies?
You're right, that change is not necessary. I misunderstood the purpose of
DEPCHAIN_POST.
--
Burton, Ross wrote:
> What is this generic output format? From your patch to bash I suspect
> it's at least inspired by the automake "make check" output.
Yes, I used the automake-style "(PASS|FAIL): " format.
In addition to that, before/after each package test suite is started,
"(BEGIN|END): "
Patch Makefile.in to allow test programs be built on host and ran on
target.
Patch tests/run-all to output PASS/FAIL for each testcase.
Patch recipe to build and install test programs and test suite.
---
.../bash/bash-4.2/build-tests.patch| 29
meta/recipes-
This package contains the top-level script that seeks out and starts all
package tests.
---
.../ptest-runner/files/ptest-runner| 16 +++
.../ptest-runner/ptest-runner_1.0.bb | 21
2 files changed, 37 insertions(+), 0 deletions(-)
This patch creates a new package group -ptest to contain the tests for
each package.
---
meta/classes/distutils-common-base.bbclass |5 -
meta/classes/image.bbclass |6 --
meta/classes/package.bbclass |8 ++--
meta/classes/task.bbclass
included
an example patch for bash that does just that.
I have also included "ptest-runnner", a simple script to find and run
all installed ptests.
Björn Stenberg (3):
Add -ptest package group
New recipe: ptest-runner
Enabled bash-ptest
meta/classes/distutils-common-ba
Burton, Ross wrote:
> The problem with that is that you can only test the external
> interfaces, not the inner state (black box vs white box). i.e. DBus
> has test cases for each C file inside that C file, so it can exercise
> both the external API and internal state.
I haven't examined dbus in d
Richard Purdie wrote:
> > c) (-ptest) Install all test files to /opt/ptest/${PN}-${PV} (for
> > example). Make a package "ptest-runner" that has a
> > script /opt/ptest/run-all-tests to iterate over all installed tests
> > and run them. This is our suggestion.
>
> Can we suitably extract the tests
Fredrik Hugosson wrote:
> I think you both might be missing some cases here. The problem is
> that 'make check' does not have a standardized meaning.
Even if there was a standardized meaning to "make check", there are lots of
packages that use completely differents systems for their building and
Frans Meulenbroeks wrote:
> a run-all-tests.sh script is somewhat problematic as
> different systems have different packages installed so different tests.
The idea is that the top level run-all script looks in the /opt/ptest directory
and runs all package tests that are installed there. It has no
Hi.
Many source packages include their own package test suites. We are looking at
running these tests on target in a structured way, and I would like a
discussion about how to best fit this into the Yocto framework.
The actions that need to be performed for a package test are roughly:
1) Build
Darren Hart wrote:
> Right, gnuplot likes evenly spaced values of BB and PM. So you could
> have done: 8,12,16,24,28,32
I did that, and uploaded it to the wiki:
https://wiki.yoctoproject.org/wiki/Build_Performance#parallelism
Looks like 24/32 is the sweet spot for this system, for this build.
Darren Hart wrote:
> One thing that comes to mind is the parallel settings, BB_NUMBER_THREADS
> and PARALLEL_MAKE. I noticed a negative impact if I increased these
> beyond 12 and 14 respectively. I tested this with bb-matrix
> (scripts/contrib/bb-perf/bb-matrix.sh). The script is a bit fickle, but
Darren Hart wrote:
> /dev/md0/build ext4
> noauto,noatime,nodiratime,commit=6000
A minor detail: 'nodiratime' is a subset of 'noatime', so there is no need to
specify both.
> I run on a beast with 12 cores, 48GB of RAM, OS and sources on a G2
> Intel SSD, with two Seagate Barrac
Saul Wold wrote:
> After getting some final patches yesterday, we made it to 100% with
> patch Upsteam-Status.
Who sets the Upstream-Status? Are there guidelines how to do it?
I spoke to the author of curl and mentioned the two patches in Yocto against
it, both of which are marked as "Upstream-S
22 matches
Mail list logo
