ltp: update to 20140828 release

Message ID 1414571901-17418-1-git-send-email-fathi.boudra@linaro.org
State Accepted
Commit a1dacd52d8bad948dcea3c39278da1d87e3167af
Headers show

Commit Message

Fathi Boudra Oct. 29, 2014, 8:38 a.m.
bump SRCREV to 20140828 tag
drop automake-foreign patch - fixed upstream (commit 18594de and edbae29)
update realtime tests fixes upstream status from submitted to backported - merged upstream

Signed-off-by: Fathi Boudra <fathi.boudra@linaro.org>
---
 ...tests-Fix-bad-priority-inheritance-conditio.patch |  2 +-
 ...ealtime-tests-Fix-robust-mutex-conditionals.patch |  2 +-
 meta/recipes-extended/ltp/ltp/automake-foreign.patch | 20 --------------------
 .../ltp/{ltp_20140422.bb => ltp_20140828.bb}         |  3 +--
 4 files changed, 3 insertions(+), 24 deletions(-)
 delete mode 100644 meta/recipes-extended/ltp/ltp/automake-foreign.patch
 rename meta/recipes-extended/ltp/{ltp_20140422.bb => ltp_20140828.bb} (98%)

Comments

Ross Burton Oct. 31, 2014, 9:44 a.m. | #1
On 29 October 2014 08:38, Fathi Boudra <fathi.boudra@linaro.org> wrote:

> bump SRCREV to 20140828 tag
> drop automake-foreign patch - fixed upstream (commit 18594de and edbae29)
> update realtime tests fixes upstream status from submitted to backported -
> merged upstream
>

This doesn't build on the autobuilders, see for example
https://autobuilder.yoctoproject.org/main/builders/minnow/builds/84/steps/BuildImages/logs/stdio

There are hundreds of compiler warnings, and a missing header.

Ross
Richard Purdie Oct. 31, 2014, 10:58 a.m. | #2
On Fri, 2014-10-31 at 09:44 +0000, Burton, Ross wrote:
> On 29 October 2014 08:38, Fathi Boudra <fathi.boudra@linaro.org>
> wrote:
>         bump SRCREV to 20140828 tag
>         drop automake-foreign patch - fixed upstream (commit 18594de
>         and edbae29)
>         update realtime tests fixes upstream status from submitted to
>         backported - merged upstream
>
> This doesn't build on the autobuilders, see for
> example https://autobuilder.yoctoproject.org/main/builders/minnow/builds/84/steps/BuildImages/logs/stdio
>
> There are hundreds of compiler warnings, and a missing header.

Now, since I've heard complaints that we don't merge patches quickly, I
want to highlight what this means.

We tried this patch, we found it had issues, therefore whenever we see
similar patches from similar authors, we now have a nagging doubt about
how much testing they've had. This means we when we aggregate those
patches there is more risk to the build, we need a clean build before we
merge patches so it can delay other people's patches. This is a bit of a
vicious circle and its why you see some of the behaviour we get
complaints about.

So I'd remind people that if they send things which don't work, it does
have an impact. There is also something you can do to influence this.

Cheers,

Richard
Fathi Boudra Oct. 31, 2014, 12:46 p.m. | #3
On 31 October 2014 12:58, Richard Purdie <richard.purdie@linuxfoundation.org
> wrote:

> On Fri, 2014-10-31 at 09:44 +0000, Burton, Ross wrote:
> > On 29 October 2014 08:38, Fathi Boudra <fathi.boudra@linaro.org>
> > wrote:
> >         bump SRCREV to 20140828 tag
> >         drop automake-foreign patch - fixed upstream (commit 18594de
> >         and edbae29)
> >         update realtime tests fixes upstream status from submitted to
> >         backported - merged upstream
> >
> > This doesn't build on the autobuilders, see for
> > example
> https://autobuilder.yoctoproject.org/main/builders/minnow/builds/84/steps/BuildImages/logs/stdio
> >
> > There are hundreds of compiler warnings, and a missing header.
>
> Now, since I've heard complaints that we don't merge patches quickly, I
> want to highlight what this means.
>

I'm one them and I guess it's the stick I asked for, for complaining ;)


>
> We tried this patch, we found it had issues, therefore whenever we see
> similar patches from similar authors, we now have a nagging doubt about
> how much testing they've had.


fwiw, it has been built and tested on armv7 and armv8 architectures, both
successfully.
Now I'm lokking why this issue is triggered on x86:

/home/pokybuild/yocto-autobuilder/yocto-worker/minnow/build/build/tmp/sysroots/minnow/usr/include/tirpc/rpc/rpc.h:74:61:
fatal error: rpc/rpcb_clnt.h: No such file or directory



> This means we when we aggregate those
> patches there is more risk to the build, we need a clean build before we
> merge patches so it can delay other people's patches. This is a bit of a
> vicious circle and its why you see some of the behaviour we get
> complaints about.
>
> So I'd remind people that if they send things which don't work, it does
> have an impact. There is also something you can do to influence this.
>
> Cheers,
>
> Richard
>
>
>
br,

Fathi
Ross Burton Oct. 31, 2014, 8:09 p.m. | #4
On 31 October 2014 12:46, Fathi Boudra <fathi.boudra@linaro.org> wrote:

> fwiw, it has been built and tested on armv7 and armv8 architectures, both
> successfully.
> Now I'm lokking why this issue is triggered on x86:
>
> /home/pokybuild/yocto-autobuilder/yocto-worker/minnow/build/build/tmp/sysroots/minnow/usr/include/tirpc/rpc/rpc.h:74:61: fatal error: rpc/rpcb_clnt.h: No such file or directory
>
>
Have a failure on ARM then:

https://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/85/steps/BuildImages/logs/stdio

Presumably you didn't do a build from a clean tmp, whereas the autobuilder
always does.  It's amazing how many missing build dependencies this picks
up, which is precisely why the autobuilder does it.

Ross
Fathi Boudra Nov. 4, 2014, 3:10 p.m. | #5
Hi Ross, Richard,

On 31 October 2014 22:09, Burton, Ross <ross.burton@intel.com> wrote:

>
> On 31 October 2014 12:46, Fathi Boudra <fathi.boudra@linaro.org> wrote:
>
>> fwiw, it has been built and tested on armv7 and armv8 architectures, both
>> successfully.
>> Now I'm lokking why this issue is triggered on x86:
>>
>> /home/pokybuild/yocto-autobuilder/yocto-worker/minnow/build/build/tmp/sysroots/minnow/usr/include/tirpc/rpc/rpc.h:74:61: fatal error: rpc/rpcb_clnt.h: No such file or directory
>>
>>
> Have a failure on ARM then:
>
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-arm/builds/85/steps/BuildImages/logs/stdio
>
> Presumably you didn't do a build from a clean tmp, whereas the autobuilder
> always does.  It's amazing how many missing build dependencies this picks
> up, which is precisely why the autobuilder does it.
>
> Ross
>

after a lot of finger-pointing and implying we don't test our changes or do
our homework or do clean builds:
* I've built ltp for armv7a and armv8 on our builders and it works fine
* I've built poky for x86 and it built fine

here's my steps:
$ git clone git://git.yoctoproject.org/poky
$ cd poky
$ source oe-init-build-env
$ patch -p1 < 0001-ltp-update-to-20140828-release.patch
$ bitbake ltp

$ ls -l tmp/deploy/rpm/i586/ltp-*
-rw-r--r-- 2 user user 55929600 Nov  4 16:28
tmp/deploy/rpm/i586/ltp-20140828-r0.i586.rpm
-rw-r--r-- 2 user user     3080 Nov  4 16:28
tmp/deploy/rpm/i586/ltp-dbg-20140828-r0.i586.rpm
-rw-r--r-- 2 user user     3264 Nov  4 16:28
tmp/deploy/rpm/i586/ltp-dev-20140828-r0.i586.rpm
-rw-r--r-- 2 user user    31884 Nov  4 16:28
tmp/deploy/rpm/i586/ltp-doc-20140828-r0.i586.rpm

afaict, the failure isn't related to the changes submitted. Could you be
kind enough to try to reproduce the build failure outside of the yocto
autobuilders? or give me the exact steps to reproduce the failure?

Cheers,
Fathi
Richard Purdie Nov. 4, 2014, 3:54 p.m. | #6
On Tue, 2014-11-04 at 17:10 +0200, Fathi Boudra wrote:
> after a lot of finger-pointing and implying we don't test our changes
> or do our homework or do clean builds:
> * I've built ltp for armv7a and armv8 on our builders and it works
> fine
> * I've built poky for x86 and it built fine
>
> here's my steps:
> $ git clone git://git.yoctoproject.org/poky
> $ cd poky
> $ source oe-init-build-env
> $ patch -p1 < 0001-ltp-update-to-20140828-release.patch
> $ bitbake ltp
>
> $ ls -l tmp/deploy/rpm/i586/ltp-*
> -rw-r--r-- 2 user user 55929600 Nov  4 16:28
> tmp/deploy/rpm/i586/ltp-20140828-r0.i586.rpm
> -rw-r--r-- 2 user user     3080 Nov  4 16:28
> tmp/deploy/rpm/i586/ltp-dbg-20140828-r0.i586.rpm
> -rw-r--r-- 2 user user     3264 Nov  4 16:28
> tmp/deploy/rpm/i586/ltp-dev-20140828-r0.i586.rpm
> -rw-r--r-- 2 user user    31884 Nov  4 16:28
> tmp/deploy/rpm/i586/ltp-doc-20140828-r0.i586.rpm
>
> afaict, the failure isn't related to the changes submitted. Could you
> be kind enough to try to reproduce the build failure outside of the
> yocto autobuilders? or give me the exact steps to reproduce the
> failure?

bitbake libtirpc; bitbake ltp

seems to reliably reproduce for me.

Cheers,

Richard
Fathi Boudra Nov. 5, 2014, 10:20 a.m. | #7
On 4 November 2014 17:54, Richard Purdie <richard.purdie@linuxfoundation.org
> wrote:

> On Tue, 2014-11-04 at 17:10 +0200, Fathi Boudra wrote:
> > after a lot of finger-pointing and implying we don't test our changes
> > or do our homework or do clean builds:
> > * I've built ltp for armv7a and armv8 on our builders and it works
> > fine
> > * I've built poky for x86 and it built fine
> >
> > here's my steps:
> > $ git clone git://git.yoctoproject.org/poky
> > $ cd poky
> > $ source oe-init-build-env
> > $ patch -p1 < 0001-ltp-update-to-20140828-release.patch
> > $ bitbake ltp
> >
> > $ ls -l tmp/deploy/rpm/i586/ltp-*
> > -rw-r--r-- 2 user user 55929600 Nov  4 16:28
> > tmp/deploy/rpm/i586/ltp-20140828-r0.i586.rpm
> > -rw-r--r-- 2 user user     3080 Nov  4 16:28
> > tmp/deploy/rpm/i586/ltp-dbg-20140828-r0.i586.rpm
> > -rw-r--r-- 2 user user     3264 Nov  4 16:28
> > tmp/deploy/rpm/i586/ltp-dev-20140828-r0.i586.rpm
> > -rw-r--r-- 2 user user    31884 Nov  4 16:28
> > tmp/deploy/rpm/i586/ltp-doc-20140828-r0.i586.rpm
> >
> > afaict, the failure isn't related to the changes submitted. Could you
> > be kind enough to try to reproduce the build failure outside of the
> > yocto autobuilders? or give me the exact steps to reproduce the
> > failure?
>
> bitbake libtirpc; bitbake ltp
>

It explains... the issue is triggered only if libtirpc is built before ltp.
It isn't the case when, on a clean build, you do only bitbake ltp or even
when you build core-image-minimal before ltp, without mentioning our
builders don't pull libtirpc either.

Patch v2 on its way. libtirpc wasn't detected until this latest release,
hence network/rpc test cases haven't been built until now and they are
broken upstream. Until, it's fixed upstream, I added a knob to disable
tirpc on configure like it's already done for numa. Fixing properly the
issue upstream might take a bit longer unfortunately.


>
> seems to reliably reproduce for me.
>

yes, in a particular configuration so I don't think we deserved your rant
from last week. Obviously, we've done the testing that would have been
expected from us. It's nice that the autobuilders caught this issue but
from a developer point of view, I don't build world but only the recipe
modified and that's a problem to not have a deterministic chain of build
dependencies when you use different configurations...


>
> Cheers,
>
> Richard
>
>
>
Cheers,
Fathi
Ross Burton Nov. 5, 2014, 10:33 a.m. | #8
Hi,

On 5 November 2014 10:20, Fathi Boudra <fathi.boudra@linaro.org> wrote:

> It explains... the issue is triggered only if libtirpc is built before ltp.
> It isn't the case when, on a clean build, you do only bitbake ltp or even
> when you build core-image-minimal before ltp, without mentioning our
> builders don't pull libtirpc either.
>
> Patch v2 on its way. libtirpc wasn't detected until this latest release,
> hence network/rpc test cases haven't been built until now and they are
> broken upstream. Until, it's fixed upstream, I added a knob to disable
> tirpc on configure like it's already done for numa. Fixing properly the
> issue upstream might take a bit longer unfortunately.
>

Thanks Fathi - the autobuilder builds so much (and fails in testing runs so
often) that unless the fix is blazingly obvious it's a far better use of
time to pull the patch and tell the submitter that it's breaking.  I'll
pull V2 into my next run (which has two failures without an obvious
culpript, annoyingly).

Ross

Patch

diff --git a/meta/recipes-extended/ltp/ltp/0001-Realtime-tests-Fix-bad-priority-inheritance-conditio.patch b/meta/recipes-extended/ltp/ltp/0001-Realtime-tests-Fix-bad-priority-inheritance-conditio.patch
index fa20b08..631f926 100644
--- a/meta/recipes-extended/ltp/ltp/0001-Realtime-tests-Fix-bad-priority-inheritance-conditio.patch
+++ b/meta/recipes-extended/ltp/ltp/0001-Realtime-tests-Fix-bad-priority-inheritance-conditio.patch
@@ -9,7 +9,7 @@  both referenced a non-existent autoconf configuration setting variable.
 Replaced the invalid variable name with the variable actually created
 by autoconf.
 
-Upstream-Status: Submitted
+Upstream-Status: Backported
 
 Signed-off-by: Gary S. Robertson <gary.robertson@linaro.org>
 ---
diff --git a/meta/recipes-extended/ltp/ltp/0001-Realtime-tests-Fix-robust-mutex-conditionals.patch b/meta/recipes-extended/ltp/ltp/0001-Realtime-tests-Fix-robust-mutex-conditionals.patch
index ccdd4d0..1fdd281 100644
--- a/meta/recipes-extended/ltp/ltp/0001-Realtime-tests-Fix-robust-mutex-conditionals.patch
+++ b/meta/recipes-extended/ltp/ltp/0001-Realtime-tests-Fix-robust-mutex-conditionals.patch
@@ -9,7 +9,7 @@  which were not generated by autoconf in order to configure tests
 for robust mutexes.  Changed these conditionals to use the config
 variables actually generated in the autoconf process.
 
-Upstream-Status: Submitted
+Upstream-Status: Backported
 
 Signed-off-by: Gary S. Robertson <gary.robertson@linaro.org>
 ---
diff --git a/meta/recipes-extended/ltp/ltp/automake-foreign.patch b/meta/recipes-extended/ltp/ltp/automake-foreign.patch
deleted file mode 100644
index c3dd891..0000000
--- a/meta/recipes-extended/ltp/ltp/automake-foreign.patch
+++ /dev/null
@@ -1,20 +0,0 @@ 
-Use foreign strictness to avoid automake errors.
-
-Upstream-Status: Submitted (https://github.com/linux-test-project/ltp/issues/16)
-Signed-off-by: Ross Burton <ross.burton@intel.com>
-
-diff --git a/configure.ac b/configure.ac
-index 9f397e7..fc57957 100644
---- a/configure.ac
-+++ b/configure.ac
-@@ -4 +4 @@
--AM_INIT_AUTOMAKE
-+AM_INIT_AUTOMAKE([foreign])
---- a/utils/ffsb-6.0-rc2/configure.in
-+++ b/utils/ffsb-6.0-rc2/configure.in
-@@ -2,2 +2,3 @@ dnl Process this file with autoconf to produce a configure script.
--AC_INIT(main.c)
--AM_INIT_AUTOMAKE(ffsb, 6.0-RC2)
-+AC_INIT([ffsb], [6.0-RC2])
-+AC_CONFIG_SRCDIR([main.c])
-+AM_INIT_AUTOMAKE([foreign])
diff --git a/meta/recipes-extended/ltp/ltp_20140422.bb b/meta/recipes-extended/ltp/ltp_20140828.bb
similarity index 98%
rename from meta/recipes-extended/ltp/ltp_20140422.bb
rename to meta/recipes-extended/ltp/ltp_20140828.bb
index 5deaabf..844d0a3 100644
--- a/meta/recipes-extended/ltp/ltp_20140422.bb
+++ b/meta/recipes-extended/ltp/ltp_20140828.bb
@@ -20,12 +20,11 @@  LIC_FILES_CHKSUM = "\
 "
 
 DEPENDS = "attr libaio libcap acl openssl zip-native"
-SRCREV = "f4c3bfe1eab51eb72caeb0f3336d2790c9a8bd1b"
+SRCREV = "2c341ad9177f36d9b953e84dee8cf88498286fe5"
 
 SRC_URI = "git://github.com/linux-test-project/ltp.git \
     file://0001-Rename-runtests_noltp.sh-script-so-have-unique-name.patch \
     file://ltp-Do-not-link-against-libfl.patch \
-    file://automake-foreign.patch \
     file://make-setregid02-work.patch \
     file://add-knob-for-numa.patch \
     file://0001-Realtime-tests-Fix-bad-priority-inheritance-conditio.patch \