All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Philippe Mathieu-Daudé" <philmd@redhat.com>
To: Cleber Rosa <crosa@redhat.com>, Eduardo Habkost <ehabkost@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Thomas Huth" <thuth@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"Michael Roth" <mdroth@linux.vnet.ibm.com>,
	qemu-devel@nongnu.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>,
	"David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] Publishing binary images for testing
Date: Mon, 17 Jun 2019 07:17:45 +0200	[thread overview]
Message-ID: <fb3237cd-002b-528b-32cf-4e7675ef27f7@redhat.com> (raw)
In-Reply-To: <4e72cde3-8475-2964-b834-f74d15d66cae@redhat.com>

Hi Cleber,

On 5/11/18 4:27 PM, Cleber Rosa 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/

1/ How do we check for distribution rights?

Is it OK for:
- a Debian/Fedora image
- a compiled Linux kernel (for a Debian/Fedora release)

2/ Who to ask to add files to this assets directory?

3/ Can we use a 'webarchive' directory structure?

Such /site/date/original_site_path/file

4/ What are the chances that this website disappears? :S

(Someone has to pay for it, and the bandwidth...)

Thanks,

Phil.


  parent reply	other threads:[~2019-06-17  5:18 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
2018-05-22 16:34             ` Alistair Francis
2019-06-17  5:17         ` Philippe Mathieu-Daudé [this message]
2019-08-16 10:51           ` [Qemu-devel] Publishing binary images for testing 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=fb3237cd-002b-528b-32cf-4e7675ef27f7@redhat.com \
    --to=philmd@redhat.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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.