From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:52938) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gsEjT-0007kg-Kh for qemu-devel@nongnu.org; Fri, 08 Feb 2019 17:34:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gsEjR-0007ED-6z for qemu-devel@nongnu.org; Fri, 08 Feb 2019 17:34:50 -0500 References: <20190205001835.25660-1-philmd@redhat.com> <20190205001835.25660-2-philmd@redhat.com> <99509706-b027-bf45-b17b-e9f66943f86c@redhat.com> From: John Snow Message-ID: Date: Fri, 8 Feb 2019 17:34:30 -0500 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v3 1/8] ahci-test: Add dependency to qemu-img tool List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= , qemu-block@nongnu.org, Kevin Wolf , Max Reitz Cc: qemu-devel@nongnu.org, Cleber Rosa On 2/7/19 1:51 PM, Thomas Huth wrote: > On 2019-02-07 17:50, Philippe Mathieu-Daud=C3=A9 wrote: >> On 2/5/19 1:18 AM, Philippe Mathieu-Daud=C3=A9 wrote: >>> Since the ahci-test uses qemu-img, add a dependency to build it >>> before using it. >>> This fixes: >>> >>> $ gmake check-qtest V=3D1 >>> QTEST_QEMU_BINARY=3Dx86_64-softmmu/qemu-system-x86_64 QTEST_QEMU_IM= G=3Dqemu-img tests/ahci-test >>> Failed to execute child process "/tmp/qemu-test.19tMRF/qemu-img" (N= o such file or directory) >>> ERROR:tests/libqos/libqos.c:192:mkimg: assertion failed: (ret && !e= rr) >>> >>> Reviewed-by: John Snow >>> Signed-off-by: Philippe Mathieu-Daud=C3=A9 >>> --- >>> Slighly related is when vm-tests expect qemu-img available: >>> https://lists.gnu.org/archive/html/qemu-devel/2018-06/msg08415.html >>> >>> $ make vm-build-ubuntu.i386 >>> Traceback (most recent call last): >>> File "source/qemu/tests/vm/basevm.py", line 236, in main >>> return vm.build_image(args.image) >>> File "tests/vm/ubuntu.i386", line 67, in build_image >>> subprocess.check_call(["qemu-img", "resize", img_tmp, "50G"]) >>> OSError: [Errno 2] No such file or directory >>> tests/vm/Makefile.include:23: recipe for target 'tests/vm/ubuntu.i3= 86.img' failed >>> make: *** [tests/vm/ubuntu.i386.img] Error 2 >>> >>> A better fix would be checking those tools via ./configure... >>> --- >>> tests/Makefile.include | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/tests/Makefile.include b/tests/Makefile.include >>> index 75ad9c0dd3..679656b64a 100644 >>> --- a/tests/Makefile.include >>> +++ b/tests/Makefile.include >>> @@ -708,7 +708,7 @@ tests/prom-env-test$(EXESUF): tests/prom-env-test= .o $(libqos-obj-y) >>> tests/rtas-test$(EXESUF): tests/rtas-test.o $(libqos-spapr-obj-y) >>> tests/fdc-test$(EXESUF): tests/fdc-test.o >>> tests/ide-test$(EXESUF): tests/ide-test.o $(libqos-pc-obj-y) >>> -tests/ahci-test$(EXESUF): tests/ahci-test.o $(libqos-pc-obj-y) >>> +tests/ahci-test$(EXESUF): tests/ahci-test.o $(libqos-pc-obj-y) qemu-= img$(EXESUF) >> >> In [*] Cleber noticed if we configure using --disable-tools, qemu-img = is >> still built by when running "make check-block" due to this rule. >> >> I think this is OK because >> - at least a test requires it, so this test will run (which is what >> we want) >> - while the tool is available in the build directory, it still won't >> be installed by "make install" >=20 > I guess you could also introduce a CONFIG_TOOLS switch and only run the > ahci test for CONFIG_TOOLS=3Dy ? ... not that important, but in case yo= u > respin the series, maybe worth a try. >=20 > Thomas >=20 Is this necessary? You can run ahci-test by itself without building tools, but you need to export QTEST_QEMU_IMG yourself, which you can absolutely point to some other copy you have. If you run "make check" though, it's going to use the built copy of qemu-img no matter what, isn't it? so what's so great about preserving a configuration where you ask it not to build tools and then intentionally try to execute tests that will necessarily fail because they can't find the qemu-img binary? This seems fine the way it is, because you are asking the computer: 1. Not to build tools, please 2. Actually, please make the tools so I can run the tests Convince me otherwise? --js