Hi Adam, On 9/28/23 19:09, Adam D. Barratt wrote: > On Thu, 2023-09-28 at 18:27 +0200, Hans van Kranenburg wrote: >> Xen 4.14 support (and security support) has ended upstream. The >> upstream >> stable branch for version 4.14 is frozen now, and a final maintenance >> release version 4.14.6 has been released. We'd like to put this final >> update into Bullseye, to properly finish the Xen work for Bullseye. >> Also, a few security fixes (regarding CVE-2023-20593 CVE-2023-20569 >> CVE-2022-40982) are included. >> >> https://xenbits.xen.org/docs/4.14-testing/SUPPORT.html#release-support >> > > --- xen-4.14.5+94-ge49571868d/automation/scripts/qemu-smoke-x86-64.sh > 2023-03-21 13:07:44.000000000 +0100 > +++ xen-4.14.6/automation/scripts/qemu-smoke-x86-64.sh 2023-08-07 > 14:11:14.000000000 +0200 > @@ -5,11 +5,6 @@ > # variant should be either pv or pvh > variant=$1 > > -# Install QEMU > -export DEBIAN_FRONTENT=noninteractive > -apt-get -qy update > -apt-get -qy install qemu-system-x86 > > I realise this is an upstream change, but is it really intended to stop > installing QEMU in a QEMU smoke test?
This particular change can be seen as the contents of the following commit, in this case for 4.14: ---- 8< ---- commit 98ec8ad2eeb96eb9d4b7f9bfd1ef3a994c63af17 Refs: RELEASE-4.14.5-103-g98ec8ad2eeb9 Author: Michal Orzel <michal.or...@amd.com> AuthorDate: Wed Apr 26 09:29:45 2023 +0200 Commit: Jan Beulich <jbeul...@suse.com> CommitDate: Wed Apr 26 09:29:45 2023 +0200 automation: Remove installation of packages from test scripts Now, when these packages are already installed in the respective containers, we can remove them from the test scripts. Signed-off-by: Michal Orzel <michal.or...@amd.com> Reviewed-by: Stefano Stabellini <sstabell...@kernel.org> master commit: 72cfe1c3ad1fae95f4f0ac51dbdd6838264fdd7f master date: 2022-12-09 14:55:33 -0800 ---- >8 ---- This is part of a change to the upstream test machinery. The commit that it's picked from (the 72cfe1c3ad1 thing) lockstep follows a previous change to the development / master branch: ---- 8< ---- commit 1ed7da301020ee1e16177cb3d9caa817f195a59a Author: Michal Orzel <michal.or...@amd.com> Date: Thu Nov 17 17:16:42 2022 +0100 automation: Install packages required by tests in containers Installation of additional packages from the test scripts when running the tests has some drawbacks. It is slower than cloning containers and can fail due to some network issues (apparently it often happens on x86 rackspace). This patch is adding the packages required by the tests to be installed when building the containers. >From qemu-alpine-x86_64.sh into debian:stretch: - cpio, - busybox-static. >From qemu-smoke-*-{arm,arm64}.sh into debian:unstable-arm64v8: - u-boot-qemu, - u-boot-tools, - device-tree-compiler, - curl, - cpio, - busybox-static. The follow-up patch will remove installation of these packages from the test scripts. This is done in order not to break the CI in-between. Signed-off-by: Michal Orzel <michal.or...@amd.com> Reviewed-by: Stefano Stabellini <sstabell...@kernel.org> ---- >8 ---- The Xen Project OSSTest machinery is used to run testing for the current development version of Xen, as well as for the stable branch lines that are still under active support. After building/compiling the source code, all kinds of test scenarios are executed, comprising tests for different virtualization modes, or different kinds of functionality, but also different kinds of actual hardware. AIUI, wanting to be able to do all of this quickly boils down to a 'feet in the mud' situation, which involves automating interaction with PDUs to be able to physically cut off power from a misbehaving piece of server hardware, or, capturing actual serial console cable output. I can understand that, at least for practical reasons, there is no desire to duplicate/replicate all of this for each supported Xen version. AIUI, The Xen source tree contains code/scripts to help setting up the test cases, as well as to be able to run them. For the first part, the current development code is used (the master branch), and for the second part, well, whatever is in a branch line needs to be able to behave correctly in that environment. This is the reason why we can find the change with title "automation: Install packages required by tests in containers" only once, committed to the master branch at the time the change took place, and why similar but possibly different variations on "automation: Remove installation of packages from test scripts" do exist in various other branches, such as stable-4.17 and stable-4.14 etc. Also, note that for Debian, we don't do anything with this part of the upstream source tree, or, at least, I mean, changes in there must not cause changes in the actual debs that we ship. Thanks for the question, it was a fun small exercise to go have a look at what's actually happening here, since we normally don't really have to interact with this stuff while doing the downstream Debian packaging work. Hans