On Tue, Feb 28, 2023 at 10:43:57AM +0000, Teo Couprie Diaz wrote:
Hi Beata, Kevin, (Not sure if it's correct etiquette to reply to both people from a down-thread reply ?)
On 28/02/2023 08:00, Kevin Brodsky wrote:
On 27/02/2023 19:25, Beata Michalska wrote:
On Mon, Feb 27, 2023 at 05:03:44PM +0100, Kevin Brodsky wrote:
On 24/02/2023 13:58, Beata Michalska wrote:
> > diff --git a/runtest/syscalls_musl.skip b/runtest/syscalls_musl.skip > > new file mode 100644 > > index 000000000..92c952dac > > --- /dev/null > > +++ b/runtest/syscalls_musl.skip > > @@ -0,0 +1,16 @@ > > +# All the following tests from the syscalls test list are failing in a standard > > +# Aarch64 Musl-based distribution (Alpine Linux). Thus they depend on Musl > Is Alpine Linux a standard distribution? I would say it is quite well known: it's the second most downloaded Docker image for a Linux distribution (Behind Ubuntu) and a lot of others use it as a base, for example. It's also somewhat supported by LTP as it's part of the build CI. But I guess it really depends on what you consider standard ?
I think I got caught up with exactly that. Note I am not debating that Alpine is a well-established distribution. How about rephrasing it a bit as of: "are failing on standard Aarch64 Linux Musl-based distribution' and skipping the mentioning of Alpine at all ? Those are to be affected by Musl implementation, in the end ?
Might be worth pointing out the existence of ci/alpine.sh, linked from doc/supported-kernel-libc-versions.txt. So I'd say mentioning Alpine is relevant, though indeed it is really about Musl in the end.
The list of tests from that file does not actually overlap with the skip list proposed (?),[...]
Indeed, ci/alpine.sh lists tests that _do not compile_, rather than tests that fail. I had to remove them manually for my testing on Alpine as they did fail to compile, but interestingly they build fine for us.
[...] so I am not convinced that it is a good argument to mention Alpine explicitly. Also there seems to be no trace (?) of those tests failing on a setup Alpine + Musl (which is why I was wondering if there are any reports). If Musl is the culprit for those failures than why attributing that to any specific distribution ? Especially that Alpine is not the only one being used for testing , and not the only one (?) where those tests fail ?
You're right that it also clearly fails on our Debian distribution using Musl, which is the whole point of having this list in the first place. My reasoning for mentioning it was more in the lines of "This is what we used to make sure this wasn't just our kernel having issues", but it might not be necessary, as you highlight.
I do not mind keeping mentioning Alpine, but I'd rather make the message clear. Or am I completely missing the point here which might very much be the case, so bare with me , please.
No strong opinion either way, I'm just saying that LTP being influenced by a number of factors besides the libc (as we've figured out with the cgroup config for instance), it is completely possible that some failures may be different on another Musl-based distro. Ideally we would know exactly why all of these fail and mentioning the environment would be irrelevant, but since we precisely haven't investigated these failures (yet) more information doesn't seem to hurt.
To be clear, I'm fine either way as well ! I just tried to have as much information as possible, but maybe it's too much, or maybe it's not clear enough.
Maybe being explicit on the mention would help then ? Something explaining that this test failures are shared between our Debian+PCuABI kernel+Musl system and a regular Alpine system, which is based on Musl. Would it be relevant for me to build LTP with Musl on my own machine (Ubuntu, will have to statically link the tests otherwise they would call into glibc) and check if the failures are consistent with what I already observed ? I don't feel like it would be very useful but if you want an extra layer of validation I'll take care of it.
I do not think it is necessary to perform yet another validation. Let's make a compromise here and mention both Alpine and Debian so that it is obvious the failures are not directly related to the first (just toss Debian next to Alpine in the brackets in your comment)
--- BR B.
In any case this really doesn't matter in the grand scheme of things so I'll be happy when this is merged, whether Alpine is mentioned or not :)
Kevin
Thanks both for the discussion, Téo _______________________________________________ linux-morello-ltp mailing list -- linux-morello-ltp@op-lists.linaro.org To unsubscribe send an email to linux-morello-ltp-leave@op-lists.linaro.org