Re: [PATCH 1/4] Acceptance tests: use an available kernel image package for arm

[Alex Bennée]

Philippe Mathieu-Daudé <philmd@redhat.com> writes:

> On 9/7/20 11:39 AM, Daniel P. Berrangé wrote:
>> On Mon, Sep 07, 2020 at 10:06:13AM +0200, Philippe Mathieu-Daudé wrote:
>>> [Cc'ing Daniel who usually have good ideas for that
>>> kind if project-wide problem]
>>>
>>> On 9/7/20 6:19 AM, Cleber Rosa wrote:
>>>> Which means a newer kernel version.  Expected output was changed
>>>> to match the new kernel too.
>>>
>>> Nack.
>>>
>>> Acceptance tests are not to test the latest Linux kernel,
>>> they aim to assert a specific kernel tested by some developer
>>> still works while QEMU evolves.
>>> QEMU doesn't have to adapt to the latest kernel;
>>> QEMU should keep boot an old kernel.
>>>
>>> Testing new kernels is good, you are adding coverage. But
>>> this break the acceptance testing contract "keep testing
>>> the same thing over time".
>>>
>>> The problem you are trying to fix is the "where to keep
>>> assets from public locations where they are being removed?"
>>> one. Two years ago [*] you suggested to use some storage on
>>> the avocado-project.org:
>>>
>>>   For Avocado-VT, there are the JeOS images[1], which we
>>>   keep on a test "assets" directory.  We have a lot of
>>>   storage/bandwidth availability, so it can be used for
>>>   other assets proven to be necessary for tests.
>>>
>>>   As long as distribution rights and licensing are not
>>>   issues, we can definitely use the same server for kernels,
>>>   u-boot images and what not.
>>>
>>>   [1] - https://avocado-project.org/data/assets/
>> 
>> If I look at stuff under that directory I see a bunch of "Jeos" qcow2
>> images, and zero information about the corresponding source for the
>> images, nor any information about the licenses of software included.
>> IOW what is stored their right now does not appear to comply with the
>> GPL licensing requirements for providing full and corresponding source.
>> 
>>> It is time to have QEMU assets managed the same way.
>> 
>> I'd rather we didn't do anything relying on binary blobs with no
>> info about how they were built. Pointing to the 3rd party download
>> URLs was the easy way to ensure we don't have to worry about licensing
>> problems.
>
> I tried to be very strict including the recipe about how to rebuild
> and description of the source (for licensing) in each commits (Alex
> Bennée once said Debian/Fedora based was OK):

Debian and Fedora both have good project hygiene for tracking sources
for their binary packages and extensive archives which we can work with.
These other projects seem to be more of a moving feast which I think is
proving we can't rely on them as a CI test and at best best efforts for
developer testing.

It seems Armbian do document their build process but it's not quite as
easy as just downloading the source deb.

>
<snip>
>
>> 
>> IIUC, the majority of our acceptance tests needs should be satisfied
>> with a combination of a Linux kernel and busybox tools. We already
>> use cross-compilers to build TCG test cases.
>> 
>> I'd like to see us provide a minimal "config" file for each Linux
>> kernel combo we need to test. We should be able to define a fairly
>> simple script that do the Linux build, busybox build and then puts
>> the combination of them into a disk image.  Something 100% automated
>> and reviewable.
>
> For Debian/Fedora this config is available in their package (or source
> package).
>
>> 
>> Even a minimal linux build takes some time, so we would need to cache
>> the binary result in some suitable manner. At least this way we have
>> a clear record of what we're building & how and can thus satisfy the
>> license rules.
>
> Yes, but if the Debian/Fedora build farms already build/published
> their packages, it is easier to use it directly.
>
> QEMU developers are very reluctant to add tests. I suppose we prefer
> to develop or fix bugs rather than write tests. If we ask full build
> recipe for each tests, I doubt we'll have much testing.

I've pondered this before and while it might have a place for random
weird machines with no mainline distro support it's not a path I'm keen
to go down. This goes especially for some of the more esoteric ARM
hardware where you start relying on hacked up vendor trees with very
specific toolchain requirements.

<snip>

-- 
Alex Bennée