qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 0/2] Allwinner H3 fixes for EMAC and acceptance tests


From: Niek Linnenbank
Subject: Re: [PATCH 0/2] Allwinner H3 fixes for EMAC and acceptance tests
Date: Wed, 17 Feb 2021 21:57:00 +0100

Hi Daniel, Philippe,




Op di 16 feb. 2021 10:49 schreef Daniel P. Berrangé <berrange@redhat.com>:
On Fri, Feb 12, 2021 at 03:10:00PM +0100, Philippe Mathieu-Daudé wrote:
> Hi Niek and QEMU community,
>
> On 2/11/21 11:00 PM, Niek Linnenbank wrote:
> > The following are maintenance patches for the Allwinner H3. The first patch
> > is a proposal to relocate the binary artifacts of the acceptance tests away
> > from the apt.armbian.com domain. In the past we had problems with artifacts being
> > removed, and now the recently added Armbian 20.08.1 image has been removed as well:
> >
> > $ wget https://dl.armbian.com/orangepipc/archive/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz
> > Connecting to dl.armbian.com (dl.armbian.com)|2605:7900:20::5|:443... connected.
> > ...
> > HTTP request sent, awaiting response... 404 Not Found
> > 2021-02-11 22:34:45 ERROR 404: Not Found.
> >
> > I've now added the artifacts to a server maintained by me. The machine has a stable
> > uptime of several years, ~100Mbit bandwidth and plenty of available storage.
> > Also for other artifacts if needed. I'm open to discuss if there is a proposal
> > for a better location for these artifacts or a more generic qemu location.
>
> Thanks for trying to fix this long standing problem.
>
> While this works in your case, this doesn't scale to the community,
> as not all contributors have access to such hardware and bandwidth /
> storage.
>
> While your first patch is useful in showing where the artifacts are
> stored doesn't matter - as long as we use cryptographic hashes - I
> think it is a step in the wrong direction, so I am not keen on
> accepting it.
>
> My personal view is that any contributor should have the same
> possibilities to add tests to the project. Now I am also open to
> discuss with the others :) I might be proven wrong, and it could
> be better to rely on good willing contributors rather than having
> nothing useful at all.

There aren't many options here

 1. Rely on a vendor to provide stable download URLs for images

 2. QEMU host all images we use in testing

 3. Contributor finds some site to upload images to


For the armbian images we rely on (1), but the URLs didn't turn out to be
stable. In fact no OS vendor seems to have guaranteed stable URLs forever,
regardless of distro, though most eventually do have an archive site that
has good life. Armbian was an exception in this respect IIUC.

(2) would solve the long term stability problem as QEMU would be in full
control, and could open it up for any images we need. The big challenge
there is that QEMU now owns the license compliance problem. Merely uploading
binary images/packages without the corresponding source is generally a license
violation. QEMU could provide hosting, but we need to be clear about the fact
that we now own the license compliance problem ourselves. Many sites hosting
images simply ignore this problem, but that doesn't make it right.


This series is proposing (3), with a site the contributor happens to control
themselves, but using a free 3rd party hosting site is no different really.
Again there is a the same need for license compliance, but it is now the
responsibility of the user, not QEMU project.

In this http://www.freenos.org/pub/qemu/cubieboard/ site I can't even see a
directory listing, so even if corresponding source does exist in this server,
I can't find it.

The isn't really a problem for QEMU CI to consume the images, but as a free
software developer I don't like encouraging practices that are not compliant
with licensing reuqirement.

It is an open question whether the (3) is really better than (1) in terms
of URL stability long term, especially if running off a user's personal
server.

I understand your concerns. My goal here was to be able to re-activate the orangepi tests, so we can capture bugs early on. So what I can do instead is:

  - update the patch to use github to store the artifacts, and their licenses (other tests also use github)
  - or change the patch to use updated armbian links that work (for now)

If we can agree on either of these solutions, so the orangepi tests can be re-activated, that would be great. 

Kind regards,
Niek



reply via email to

[Prev in Thread] Current Thread [Next in Thread]