| Message ID | 20210211220055.19047-1-nieklinnenbank@gmail.com |
|---|---|
| Headers | show |
| Series | Allwinner H3 fixes for EMAC and acceptance tests | expand |
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. Regards, Phil.
Op vr 12 feb. 2021 15:10 schreef Philippe Mathieu-Daudé <philmd@redhat.com>: > 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. Hi Philippe, I see your point. How about I simply upload the artifacts to github instead? There are already multiple tests right now that use artifacts stored on github. And github is available to everyone. For me that would work fine. If you agree, I can respin the patch. Regards Niek 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. > Regards, > > Phil. > >
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. Regards, Daniel
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 :| > >
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é <berrange@redhat.com > <mailto: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 <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. 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. > - 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
On Fri, Feb 19, 2021 at 07:24:01PM +0100, Philippe Mathieu-Daudé wrote: > > 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. > > 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". > As of Avocado 85.0 (currently used in QEMU), it's possible to set the "expire" parameter to "fetch_asset", see: https://avocado-framework.readthedocs.io/en/85.0/api/test/avocado.html#avocado.Test.fetch_asset In this case, if we want assets to not be used if they're are 30 days or older, that could be set to 86400. The expired asset not being used, and then not being able to be fetched again, would cause a test to be canceled. Cache browsing/listing/manipulation using the "avocado assets" command is planned for Avocado 86.0, see: https://github.com/avocado-framework/avocado/issues/4311 > > 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. > +1. Regards, - Cleber.
On Fri, Feb 19, 2021 at 7:24 PM Philippe Mathieu-Daudé <philmd@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é <berrange@redhat.com > > <mailto: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 <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 > >
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. The second patch is a fix for the EMAC that is used by the Allwinner H3 / Orange Pi PC machine. Kind regards, Niek Niek Linnenbank (2): tests/acceptance: replace unstable apt.armbian.com URLs for orangepi-pc, cubieboard hw/net/allwinner-sun8i-emac: traverse transmit queue using TX_CUR_DESC register value hw/net/allwinner-sun8i-emac.c | 58 ++++++++++++++------------ tests/acceptance/boot_linux_console.py | 46 +++++++------------- tests/acceptance/replay_kernel.py | 6 +-- 3 files changed, 50 insertions(+), 60 deletions(-)