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'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. Jan
