On Fri, Feb 19, 2021 at 7:24 PM Philippe Mathieu-Daudé <phi...@redhat.com> wrote:
> Hi Niek, > > On 2/17/21 9:57 PM, Niek Linnenbank wrote: > > Hi Daniel, Philippe, > > > > Op di 16 feb. 2021 10:49 schreef Daniel P. Berrangé <berra...@redhat.com > > <mailto:berra...@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 <http://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 > > < > https://dl.armbian.com/orangepipc/archive/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz > > > > > > Connecting to dl.armbian.com <http://dl.armbian.com> > > (dl.armbian.com <http://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/ > > <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. > > I hope you understand the concern I have is not with you in particular, > and I used your case to start a discussion with the QEMU community. > Hi Philippe, Yeah I understand. I agree as well we should try to find a long-term general solution. > > FWIW I missed the URL change because I still have the image cached in > Avocado so my testing ran fine. Which makes me wonder... > > Cleber, Willian, should Avocado display information about cached > artifacts? Such "Using artifact downloaded 7 months ago". > > > 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) > > Until there is better solutions, this is the option I prefer. > Allright, I'll prepare a reworked patch soon that uses github and re-send it. Kind regards, Niek > > > - 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 > > -- Niek Linnenbank
