From: Alistair Francis <alistair23@gmail.com>
To: Cleber Rosa <crosa@redhat.com>
Cc: "Eduardo Habkost" <ehabkost@redhat.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Peter Maydell" <peter.maydell@linaro.org>,
"Thomas Huth" <thuth@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
"Alexander Graf" <agraf@suse.de>,
"Michael Roth" <mdroth@linux.vnet.ibm.com>,
avocado-devel@redhat.com,
"Hervé Poussineau" <hpoussin@reactos.org>,
"Marcel Apfelbaum" <marcel@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"David Gibson" <david@gibson.dropbear.id.au>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines)
Date: Fri, 18 May 2018 11:16:25 -0700 [thread overview]
Message-ID: <CAKmqyKMWgGHackdiiaC-e4yU9h4-OKsc2c3s6RevxZetrb8jQw@mail.gmail.com> (raw)
In-Reply-To: <4e72cde3-8475-2964-b834-f74d15d66cae@redhat.com>
On Fri, May 11, 2018 at 7:27 AM, Cleber Rosa <crosa@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 ?
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
>
> --
> Cleber Rosa
> [ Sr Software Engineer - Virtualization Team - Red Hat ]
> [ Avocado Test Framework - avocado-framework.github.io ]
> [ 7ABB 96EB 8B46 B94D 5E0F E9BB 657E 8D33 A5F2 09F3 ]
>
next prev parent reply other threads:[~2018-05-18 18:16 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-08 2:28 [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Philippe Mathieu-Daudé
2017-11-08 2:28 ` [Qemu-devel] [RFC PATCH 1/6] machine: add a deprecated_reason property Philippe Mathieu-Daudé
2017-11-08 10:23 ` Thomas Huth
2017-11-08 10:27 ` Daniel P. Berrange
2017-11-08 20:29 ` Eduardo Habkost
2018-01-22 2:10 ` Philippe Mathieu-Daudé
2018-01-22 6:21 ` Thomas Huth
2017-11-08 2:28 ` [Qemu-devel] [RFC PATCH 2/6] hw/arm: deprecate the EP108 board Philippe Mathieu-Daudé
2017-11-08 9:17 ` Daniel P. Berrange
2017-11-08 2:28 ` [Qemu-devel] [RFC PATCH 3/6] hw/arm: deprecate the Gumstix boards Philippe Mathieu-Daudé
2017-11-08 2:28 ` [Qemu-devel] [RFC PATCH 4/6] hw/ppc: deprecate the PReP machine Philippe Mathieu-Daudé
2017-11-08 2:28 ` [Qemu-devel] [RFC PATCH 5/6] hw/i386: deprecate the pc-0.10 and pc-0.11 machines Philippe Mathieu-Daudé
2017-11-08 2:48 ` Alexey Kardashevskiy
2017-11-08 3:28 ` Philippe Mathieu-Daudé
2017-11-08 9:13 ` Daniel P. Berrange
2017-11-08 10:43 ` Thomas Huth
2017-11-08 9:16 ` Daniel P. Berrange
2017-11-08 10:15 ` Thomas Huth
2017-11-08 11:36 ` Thomas Huth
2017-11-08 2:28 ` [Qemu-devel] [RFC PATCH 6/6] hw/i386: deprecate the "isapc" machine Philippe Mathieu-Daudé
2017-11-08 3:29 ` Philippe Mathieu-Daudé
2017-11-08 9:09 ` Daniel P. Berrange
2017-11-08 9:44 ` Gerd Hoffmann
2017-11-08 10:05 ` Thomas Huth
2017-11-08 9:10 ` [Qemu-devel] [RFC PATCH 0/6] generic way to deprecate machines Daniel P. Berrange
2018-05-04 17:15 ` Thomas Huth
2018-05-08 15:47 ` Philippe Mathieu-Daudé
2018-05-11 13:55 ` [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines) Eduardo Habkost
2018-05-11 14:27 ` Cleber Rosa
2018-05-18 18:16 ` Alistair Francis [this message]
2018-05-22 16:17 ` Cleber Rosa
2018-05-22 16:34 ` Alistair Francis
2019-06-17 5:17 ` [Qemu-devel] Publishing binary images for testing Philippe Mathieu-Daudé
2019-08-16 10:51 ` Philippe Mathieu-Daudé
2019-08-19 13:10 ` Cleber Rosa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKmqyKMWgGHackdiiaC-e4yU9h4-OKsc2c3s6RevxZetrb8jQw@mail.gmail.com \
--to=alistair23@gmail.com \
--cc=agraf@suse.de \
--cc=alex.bennee@linaro.org \
--cc=avocado-devel@redhat.com \
--cc=crosa@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=ehabkost@redhat.com \
--cc=f4bug@amsat.org \
--cc=hpoussin@reactos.org \
--cc=marcel@redhat.com \
--cc=mdroth@linux.vnet.ibm.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).