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

[Niek Linnenbank <nieklinnenbank@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4784 bytes --]

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



> Regards,
> Daniel
> --
> |: https://berrange.com      -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-
> https://www.instagram.com/dberrange :|
>
>

[-- Attachment #2: Type: text/html, Size: 6915 bytes --]