Re: [Openembedded-architecture] Y2038 proposal

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2022-12-01 at 11:27 +0100, Alexander Kanavin wrote:
> On Wed, 30 Nov 2022 at 14:15, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > * We need to have a 32 bit ptest run on the autobuilder (qemux86 should
> > work, not sure we can make qemuarm fast). Whether this is manually
> > triggered, not sure. We could have a smaller set of ptests to run for
> > it?
> 
> I just ran qemux86 full ptest locally. It took 4h:10m (same as
> qemuarm64 ptest on an arm worker). The fails were:
> 
> {'python3': ['test_deterministic_sets'],
>  'valgrind': ['gdbserver_tests/hgtls',
>               'gdbserver_tests/mcblocklistsearch',
>               'gdbserver_tests/mcbreak',
>               'gdbserver_tests/mcclean_after_fork',
>               'gdbserver_tests/mchelp',
>               'gdbserver_tests/mcinfcallRU',
>               'gdbserver_tests/mcinfcallWSRU',
>               'gdbserver_tests/mcinvokeRU',
>               'gdbserver_tests/mcinvokeWS',
>               'gdbserver_tests/mcleak',
>               'gdbserver_tests/mcmain_pic',
>               'gdbserver_tests/mcsignopass',
>               'gdbserver_tests/mcsigpass',
>               'gdbserver_tests/mcvabits',
>               'gdbserver_tests/mcwatchpoints',
>               'gdbserver_tests/mssnapshot',
>               'gdbserver_tests/nlcontrolc',
>               'gdbserver_tests/nlgone_abrt',
>               'gdbserver_tests/nlgone_exit',
>               'gdbserver_tests/nlgone_return',
>               'gdbserver_tests/nlpasssigalrm',
>               'gdbserver_tests/nlsigvgdb',
>               'gdbserver_tests/nlvgdbsigqueue',
>               'memcheck/tests/linux/memfd_create',
>               'memcheck/tests/linux/timerfd-syscall',
>               'memcheck/tests/origin5-bz2',
>               'massif/tests/mmapunmap']}
> 
> So I think we could as well fix these, and add full qemux86 ptest to
> a-full? It is not heavy on the builder machine (mostly just runs a
> single qemu thread), it's just long.

I think we should fix those and we should add the target to the
autobuilder but I'm reluctant to add a long test to a-full. The fact it
is relatively clean suggests it doesn't regress that often. We could do
something like a once a month trigger for it?

Cheers,

Richard