From: Cleber Rosa <crosa@redhat.com>
To: Alistair Francis <alistair23@gmail.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Thomas Huth" <thuth@redhat.com>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"qemu-devel@nongnu.org Developers" <qemu-devel@nongnu.org>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Alexander Graf" <agraf@suse.de>,
avocado-devel@redhat.com,
"Hervé Poussineau" <hpoussin@reactos.org>,
"Marcel Apfelbaum" <marcel@redhat.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Richard Henderson" <rth@twiddle.net>,
"Alex Bennée" <alex.bennee@linaro.org>,
"Michael Roth" <mdroth@linux.vnet.ibm.com>,
"David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines)
Date: Tue, 22 May 2018 12:17:06 -0400 [thread overview]
Message-ID: <13e9e7c3-08e3-f876-07f3-b8db5e8ad39c@redhat.com> (raw)
In-Reply-To: <CAKmqyKMWgGHackdiiaC-e4yU9h4-OKsc2c3s6RevxZetrb8jQw@mail.gmail.com>
On 05/18/2018 02:16 PM, Alistair Francis wrote:
> 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 ?
>
Done!
- 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
>
next prev parent reply other threads:[~2018-05-22 16:17 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
2018-05-22 16:17 ` Cleber Rosa [this message]
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=13e9e7c3-08e3-f876-07f3-b8db5e8ad39c@redhat.com \
--to=crosa@redhat.com \
--cc=agraf@suse.de \
--cc=alex.bennee@linaro.org \
--cc=alistair23@gmail.com \
--cc=avocado-devel@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).