Re: [Qemu-devel] Publishing binary images for testing

[Philippe Mathieu-Daudé]

ping? :)

On 6/17/19 7:17 AM, Philippe Mathieu-Daudé wrote:
> Hi Cleber,
> 
> On 5/11/18 4:27 PM, Cleber Rosa wrote:
>> On 05/11/2018 09:55 AM, Eduardo Habkost wrote:
>>> (CCing Cleber and avocado-devel in case they have suggestions)
>>>
>>> On Tue, May 08, 2018 at 12:47:52PM -0300, Philippe Mathieu-Daudé wrote:
>>> [...]
>>>> Ironically I have been using the Gumstix machines quite a lot for the SD
>>>> 'subsystem' refactor, using the MMC commands in U-Boot (I am unable to
>>>> reach the Linux userland since the kernel crashes), and plan to add SD
>>>> integration tests via Avocado.
>>>>
>>>> This raises:
>>>>
>>>> - What will happens if I add tests downloading running on their compiled
>>>> u-boot
>>>> (https://downloads.gumstix.com/images/angstrom/developer/2012-01-22-1750/u-boot.bin)
>>>> and the company decides to remove this old directory?
>>>> Since sometimes old open-source software are hard to rebuild with recent
>>>> compilers, should we consider to use a public storage to keep
>>>> open-source (signed) blobs we can use for integration testing?
>>>
>>> I think a maintained repository of images for testing would be
>>> nice to have.  We need to be careful to comply with the license
>>> of the software being distributed, though.
>>>
>>> If the images are very small (like u-boot.bin above), it might be
>>> OK to carry them in qemu.git, just like the images in pc-bios.
>>>
>>>>
>>>> Avocado has a 'vmimage library' which could be extended, adding support
>>>> for binary url + detached gpg signatures from some QEMU maintainers?
>>>
>>> Requiring a signature makes the binaries hard to replace.  Any
>>> specific reason to suggest gpg signatures instead of just a
>>> (e.g.) sha256 hash?
>>>
>>>>
>>>> (I am also using old Gentoo/Debian packaged HPPA/Alpha Linux kernel for
>>>> Avocado SuperIO tests, which aren't guaranteed to stay downloadable
>>>> forever).
>>>
>>> Question for the Avocado folks: how this is normally handled in
>>> avocado/avocado-vt?  Do you maintain a repository for guest
>>> images, or you always point to their original sources?
>>>
>>
>> For pure Avocado, the vmimage library attempts to fetch, by default, the
>> latest version of a guest image directly from the original sources.
>> Say, a Fedora image will be downloaded by default from the Fedora
>> servers.  Because of that, we don't pay too much attention to the
>> availability of specific (old?) versions of guest images.
>>
>> 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/
> 
> 1/ How do we check for distribution rights?
> 
> Is it OK for:
> - a Debian/Fedora image
> - a compiled Linux kernel (for a Debian/Fedora release)
> 
> 2/ Who to ask to add files to this assets directory?
> 
> 3/ Can we use a 'webarchive' directory structure?
> 
> Such /site/date/original_site_path/file
> 
> 4/ What are the chances that this website disappears? :S
> 
> (Someone has to pay for it, and the bandwidth...)
> 
> Thanks,
> 
> Phil.