[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATC
Re: [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines)
Tue, 22 May 2018 12:17:06 -0400
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
On 05/18/2018 02:16 PM, Alistair Francis wrote:
> On Fri, May 11, 2018 at 7:27 AM, Cleber Rosa <address@hidden> 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
>>>> 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
>>> 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, 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.
>>  - https://avocado-project.org/data/assets/
> Is it possible to add something to the landing page at
> https://avocado-project.org ?
> 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