qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	qemu-devel@nongnu.org
Cc: qemu-arm@nongnu.org, Cleber Rosa <crosa@redhat.com>,
	Wainer dos Santos Moschetta <wainersm@redhat.com>,
	Beraldo Leal <bleal@redhat.com>
Subject: Re: [RFC PATCH] tests/avocado: use new rootfs for orangepi test
Date: Wed, 23 Nov 2022 12:26:45 +0100	[thread overview]
Message-ID: <8f6f531f-3ed9-6a14-9ad6-8c0ff6b32c22@redhat.com> (raw)
In-Reply-To: <8c4b6387-450d-88af-c1d4-3171a9c3067b@linaro.org>

On 23/11/2022 12.15, Philippe Mathieu-Daudé wrote:
> On 18/11/22 12:33, Alex Bennée wrote:
>> The old URL wasn't stable. I suspect the current URL will only be
>> stable for a few months so maybe we need another strategy for hosting
>> rootfs snapshots?
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> ---
>>   tests/avocado/boot_linux_console.py | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/tests/avocado/boot_linux_console.py 
>> b/tests/avocado/boot_linux_console.py
>> index 4c9d551f47..5a2923c423 100644
>> --- a/tests/avocado/boot_linux_console.py
>> +++ b/tests/avocado/boot_linux_console.py
>> @@ -793,8 +793,8 @@ def test_arm_orangepi_sd(self):
>>           dtb_path = 
>> '/usr/lib/linux-image-current-sunxi/sun8i-h3-orangepi-pc.dtb'
>>           dtb_path = self.extract_from_deb(deb_path, dtb_path)
>>           rootfs_url = 
>> ('http://storage.kernelci.org/images/rootfs/buildroot/'
>> -                      'kci-2019.02/armel/base/rootfs.ext2.xz')
>> -        rootfs_hash = '692510cb625efda31640d1de0a8d60e26040f061'
>> +                      'buildroot-baseline/20221116.0/armel/rootfs.ext2.xz')
>> +        rootfs_hash = 'fae32f337c7b87547b10f42599acf109da8b6d9a'
> If Avocado doesn't find an artifact in its local cache, it will fetch it
> from the URL.
> The cache might be populated with artifacts previously downloaded, but
> their URL is not valid anymore (my case for many tests).
> We can also add artifacts manually, see [1].
> 
> I'd rather keep pre-existing tests if possible, to test older (kernel / 
> user-space) images. We don't need to run all the tests all the time:
> tests can be filtered by tags (see [2]).
> 
> My preference here is to refactor this test, adding the "kci-2019.02"
> and "baseline-20221116.0" releases. I can prepare the patch if you /
> Thomas don't object.

IMHO we shouldn't keep tests in the upstream git repository where the 
binaries are not available in public anymore. They won't get run by new 
contributors anymore, and also could vanish from the disks of the people who 
previously downloaded it, once they wipe their cache or upgrade to a new 
installation, so the test code will sooner or later be bitrotting. But if 
you want to keep the tests around on your hard disk, you could also stick 
the test in a local branch on your hard disk instead.

The other possibility is to upload the binaries to a new public location in 
the web ... but for software that contains GPLed software, you should then 
also make sure to provide the source code to comply with the license.

  Thomas



  reply	other threads:[~2022-11-23 11:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-18 11:33 [RFC PATCH] tests/avocado: use new rootfs for orangepi test Alex Bennée
2022-11-18 14:18 ` Thomas Huth
2022-11-23 10:03   ` Thomas Huth
2022-11-23 11:15 ` Philippe Mathieu-Daudé
2022-11-23 11:26   ` Thomas Huth [this message]
2022-11-23 14:12     ` Alex Bennée
2022-11-23 18:13       ` Philippe Mathieu-Daudé
2022-11-23 18:49         ` Cédric Le Goater
2022-11-23 23:06           ` Philippe Mathieu-Daudé
2022-11-24  9:32             ` Daniel P. Berrangé
2022-11-24  8:20         ` Thomas Huth
2022-11-24  9:24           ` Daniel P. Berrangé
2022-11-24  9:20         ` Daniel P. Berrangé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8f6f531f-3ed9-6a14-9ad6-8c0ff6b32c22@redhat.com \
    --to=thuth@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=bleal@redhat.com \
    --cc=crosa@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=wainersm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).