On 9/7/20 12:28 PM, Daniel P. Berrangé wrote: > On Mon, Sep 07, 2020 at 11:59:18AM +0200, Philippe Mathieu-Daudé wrote: >> On 9/7/20 11:39 AM, Daniel P. Berrangé wrote: >>> On Mon, Sep 07, 2020 at 10:06:13AM +0200, Philippe Mathieu-Daudé wrote: >>>> [Cc'ing Daniel who usually have good ideas for that >>>> kind if project-wide problem] >>>> >>>> On 9/7/20 6:19 AM, Cleber Rosa wrote: >>>>> Which means a newer kernel version. Expected output was changed >>>>> to match the new kernel too. >>>> >>>> Nack. >>>> >>>> Acceptance tests are not to test the latest Linux kernel, >>>> they aim to assert a specific kernel tested by some developer >>>> still works while QEMU evolves. >>>> QEMU doesn't have to adapt to the latest kernel; >>>> QEMU should keep boot an old kernel. >>>> >>>> Testing new kernels is good, you are adding coverage. But >>>> this break the acceptance testing contract "keep testing >>>> the same thing over time". >>>> >>>> The problem you are trying to fix is the "where to keep >>>> assets from public locations where they are being removed?" >>>> one. Two years ago [*] you suggested to use some storage on >>>> the avocado-project.org: >>>> >>>> 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/ >>> >>> If I look at stuff under that directory I see a bunch of "Jeos" qcow2 >>> images, and zero information about the corresponding source for the >>> images, nor any information about the licenses of software included. >>> IOW what is stored their right now does not appear to comply with the >>> GPL licensing requirements for providing full and corresponding source. >>> >>>> It is time to have QEMU assets managed the same way. >>> >>> I'd rather we didn't do anything relying on binary blobs with no >>> info about how they were built. Pointing to the 3rd party download >>> URLs was the easy way to ensure we don't have to worry about licensing >>> problems. >> >> I tried to be very strict including the recipe about how to rebuild >> and description of the source (for licensing) in each commits (Alex >> Bennée once said Debian/Fedora based was OK): > > ..snip... > > Well that looks better than what is done for the JEOS images currently > on avocado-project.org, as I can't tell what distro those came from > at all. > > If we're hosting images built by some 3rd party, and we intend to rely > on the 3rd party to satisfy source availability, then we need to be sure > that the 3rd party is themselves still distributing the same images. > > IIUC, from Cleber's commit here the original images we're pointing to > are now 404s. If the URLs moved, we just need to update to fix the URLs > to point the new location. If the content was entirely removed though, > we shouldn't mirror it ourselves, because we can't rely on the original > vendor to be providing the source at that point.
Having backups and the SHA1 of the files already commited in our repository, this is the outcome I prefer. Let see what other think on this topic. Thanks for your insights :) > > Regards, > Daniel >