ltp: update to 20140828 release

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%)

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

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

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

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

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

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

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

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