On Tue, May 22, 2018 at 9:17 AM, Cleber Rosa <cr...@redhat.com> wrote: > > > On 05/18/2018 02:16 PM, Alistair Francis wrote: >> On Fri, May 11, 2018 at 7:27 AM, Cleber Rosa <cr...@redhat.com> 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/ >> >> Is it possible to add something to the landing page at >> https://avocado-project.org ? >> > > Done!
Awesome! It looks good and this should help everyone behind a proxy. Alistair > - Cleber. > >> The Palo Alto Network routers block the avocado-project.org page as >> they classify it as blank. Something on the root URL would help fix >> this. >> >> Alistair >>
