Draft: test-cases: Add LTP test case for syscalls testing

LTP project offers test for each Linux Kernel syscall.

This commits adds support to launch ltp syscalls test on Apertis test framework.

Since the job description is given in the kernelci repository, there is no run step. see https://github.com/kernelci/test-definitions/blob/staging.kernelci.org/automated/linux/ltp/ltp.yaml

Also dependent packages are installed manually in the template, it looks like there is some convenient macros to do the same things.

example test jobs is here https://lava.collabora.co.uk/scheduler/job/6153858 This work has been done as part of https://phabricator.apertis.org/T8760.

Are these tests something specific for OSTree? Why did you choose OSTree instead of APT?

Hi, no there is no specific thing to ostree I can choose apt.

I noticed that you created a new group, which might be helpful in some cases. Usually that is done to avoid repeating stuff used by several tests, but in this case there is only one test-case. Is there any reason to have a new group? If not maybe you can use the default one, which is automatically use if the the name does not match with other group (at least that is what I understand but @detlev can confirm).

What I had in mind is to not add this test by default because it will make job running for too long, and we only want to test the BSP kernel and not really an apertis image.

Yes, I can confirm that the default template is used if the group name doesn't match any template. But creating a new group is useful when a test (or a group of tests) need specific setups and variables, which seems to be the case here.

If You don't want to test all apertis images, I wonder if the test should be manual, because all tests in this repository will be run on the images they support (architecture, type) unless they are manual.

@jmassot In what exact conditions should the test be run ?

That's still open for discussion, but most likely only useful in case we are evaluating a vendor kernel for inclusion in an Apertis userland, checking for possible conflicts in syscall numbers.

Yes, maybe we need to support some kind of test cases to be run under specific circumstances. I guess what is exactly needed for this task should be discussed with the rest of the team.

I'm not sure what are the plans here, I'm reviewing this without exactly known them. As you mentioned, this test is time consuming, so at the beginning I would only run it on armhf for which we have more boards in our LAVA lab.

Maybe something to think is to run it on a different schedule than the rest of the test...

Ok, on imx6 it makes the device busy for almost 2h I noticed there are 6 of them in the lab, It's also why I choosed the imx6 to test this job.

Perfect. I just wanted to open this thread in case this is intended to be merged.

The pipeline is complaining about not having "run", so there is no actual test (in this step) to work with. Probably after discussing around the "group" we can decide what should be inside "run".

Also it is a good practice to add a link to the Phabricator task in the MR, this helps to have the context of the task and to be able to log the time for the review to the right place.

Hi, just added the ticket link. Thanks Walter !

Thank you! BTW, if you put the full URL it is easier for everybody, you just copy the whole text from the browser, and we just click the link to have the full context.

changed the description

changed target branch from apertis/v2023dev2 to apertis/v2023dev3