[Avocado-devel] Publishing binary images for testing (was Re: [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines)

[Eduardo Habkost]

(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?

-- 
Eduardo