On 13/02/2025 7:54 am, Jan Beulich wrote: > On 13.02.2025 01:51, Andrew Cooper wrote: >> On 12/02/2025 9:52 pm, Stefano Stabellini wrote: >>> On Wed, 12 Feb 2025, Oleksii Kurochko wrote: >>>> Hello everyone, >>>> >>>> During the installation of Xen on an ARM server machine from the source >>>> code, >>>> I found that the wrong release candidate (rc) is being used: >>>> $ make install >>>> install -m0644 -p xen //boot/xen-4.20-rc >>>> install: cannot remove ‘//boot/xen-4.20-rc’: Permission denied >>>> make[1]: *** [Makefile:507: _install] Error 1 >>>> My expectation is that it should be xen-4.20-rc4. >>>> >>>> I'm not sure if this behavior is intentional or if users are expected to >>>> set >>>> the XEN_VENDORVERSION variable manually to ensure the correct release >>>> candidate number. >>>> >>>> In my opinion, we should set the proper release candidate number after >>>> "xen-4.20-rc" automatically. >>>> >>>> Does anyone have any thoughts or suggestions on how to resolve this issue? >>> Hi Oleksii, >>> >>> I did a quick test and I see exactly the same on x86 as well. This patch >>> fixes it, but then it would need someone to update the RC number in >>> xen/Makefile every time a new RC is made. >>> >>> --- >>> xen: add RC version number to xen filename >>> >>> Signed-off-by: Stefano Stabellini <[email protected]> >> This is a direct consequence of the request to keep XEN_EXTRAVERSION at >> "-rc" throughout the release cycle. >> >> I'm having to manually edit that simply to create the tarballs >> correctly, which in turn means that the tarball isn't a byte-for-byte >> identical `git archive` of the tag it purports to be. > Just for my understanding - may I ask why this editing is necessary? > Other release technicians never mentioned the (indeed undesirable) > need to do so.
I did point it out. I also needed to get RC1 cut and everyone had left the office. xen.git$ make src-tarball-release && tar tf dist/xen-4.20-rc.tar.gz | head <snip> Source tarball in /home/andrew/xen.git/dist/xen-4.20-rc.tar.gz xen-4.20-rc/ xen-4.20-rc/.github/ xen-4.20-rc/.github/workflows/ xen-4.20-rc/.github/workflows/coverity.yml xen-4.20-rc/.gitarchive-info xen-4.20-rc/Makefile xen-4.20-rc/stubdom/ xen-4.20-rc/stubdom/Makefile xen-4.20-rc/stubdom/grub/ xen-4.20-rc/stubdom/grub/Makefile mktarball uses `$(MAKE) -C xen xenversion` which uses XEN_EXTRAVERSION. XEN_EXTRAVERSION needs both the .0 and the RC number in order to make the tarball with the correct name and correct top directory. What I didn't anticipate was that, while editing XEN_EXTRAVERSION locally gets a proper tarball, the contents within the tarball are nonspecific as to the RC, hence Oleksii's observation. It also means the tarball wasn't a straight `git archive` of the tree, which is one of the reasons behind taking out the sub-repos. >> I'd not twigged that it mean the builds from the tarballs reported false >> information too. >> >> While I appreciate the wish to not have a commit per RC bumping >> XEN_EXTRAVERSION, I think the avoidance of doing so is creating more >> problems than it solves, and we should revert back to the prior way of >> doing things. > Sure, if it truly is getting in the way, then it needs re-considering. > Just to mention it: Then the question is going to be though whether > really to merely adjust XEN_EXTRAVERSION, or whether instead to do > this consistently in all (three?) places. It's only XEN_EXTRAVERSION which needs to change (I think). I think README and SUPPORT.md are fine to say as they are, for generically -rc. Oleksii has asked for RC5, and we're overdue. I'm intending to commit: diff --git a/xen/Makefile b/xen/Makefile index 65b460e2b480..4e37fff92514 100644 --- a/xen/Makefile +++ b/xen/Makefile @@ -6,7 +6,7 @@ this-makefile := $(call lastword,$(MAKEFILE_LIST)) # All other places this is stored (eg. compile.h) should be autogenerated. export XEN_VERSION = 4 export XEN_SUBVERSION = 20 -export XEN_EXTRAVERSION ?= -rc$(XEN_VENDORVERSION) +export XEN_EXTRAVERSION ?= .0-rc5$(XEN_VENDORVERSION) export XEN_FULLVERSION = $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION) -include xen-version in order to make that happen properly, and finally have the tarball be a straight `git archive` invocation. Does this sound acceptable? ~Andrew
