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. 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. ~Andrew
