[OE-core] [PATCH] ltp: getrlimit03: adjust-a-bit-of-code-to-compatiable-with mips32

[Richard Purdie]

Hi Petr,

On Thu, 2019-07-18 at 23:51 +0200, Petr Vorel wrote:
> I have to say I prefer policy when only build fixes are backported /
> added. (approach which e.g. buildroot has). Having many patches (25
> atm) makes updating a bit difficult (ok, not that much, 'Upstream-
> Status: Backport' shows what has been merged since last release) and
> sometimes brings users patches which weren't accepted by upstream
> (your mips patch [1] was not accepted [2]).
> 
> But I understand that LTP 3 months release cycle can be to
> slow for some LTP users.

FWIW our policy does vary a lot depending on the upstream. Where we can
have an open dialog with active projects I'm very keen to figure out
how to get our patch set to zero, we really don't want patches.

Backports don't worry me so much because as you say, we clearly mark
them and those are easy to drop upon upgrade.

I see we have an ltp upgrade which looks to remove 50% of the patches
which is a good start. 

That leaves 12 of them, of which 6 are musl and 6 appear to be other
test 'fixes' of various kinds.

Of the other 6, 3 say they're backports, one submitted and two pending.
Figuring out the two pending and the submitted would set us up for a
cleaner upgrade in future outside of musl.

> Kind regards,
> Petr
> 
> PS: I'm slowly working on fixing all musl issues in LTP upstream.
> It's a long term run but were moving towards that goal. Patch "build:
> Add option to select libc implementation" [3] is a nota good
> approach.  Instead it's needed to find for each failure why it's not
> presented in musl.  Mostly because it uses non POSIX features or
> deprecated API, which needs to be avoided or used kernel headers
> where it's available.

This sounds great, I think what we have right now can only be described
as a bit of a hack. It lets us build and run tests but clearly isn't
appropriate to merge upstream. We can at the very least help with
testing and certainly want to drop our patch if/as/when we can.

Also, I'm not sure if you've seen it but our "full" builds now run ltp
for x86 and arm under qemu and report the results:

https://autobuilder.yocto.io/pub/non-release/20190712-13/testresults/testresult-report.txt

(see the Ltp and Ltp Posix sections)

I'm actually quite worried about the numbers of failures we see there.
Up to now I've been focusing on sorting out our ptest results but ltp
would be something we need to focus on next.

There should be more raw log data in 
https://autobuilder.yocto.io/pub/non-release/20190712-13/testresults/qemux86-64-ltp/
and
https://autobuilder.yocto.io/pub/non-release/20190712-13/testresults/qemuarm64-ltp/testresults.json
but I've not had a chance to look at the ltp side of things at all
myself, Armin has done the integration work so far.

Cheers,

Richard