[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [BUG?] Wrong RC reported during 'make install'
On 13.02.2025 20:09, Stefano Stabellini wrote: > On Thu, 13 Feb 2025, 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 <stefano.stabellini@xxxxxxx> >>> >>> 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. > > This is not an answer to Jan's question, more me highlighting > priorities. > > While having the appropriate RC version in the Xen name during the RC > phase of the release process would be nice, I do not believe it is > mandatory. We do need it in the official release tarballs though. > > So the most important consideration for me is making the release > technician's job easier and less error-prone. Therefore, I believe we > should follow Andrew and Julien's recommendation on this. > > Andrew, just to be clear, are you recommending to go with a patch > similar to the one I posted, and then update the XEN_VENDORVERSION > with a new commit every time there is a new RC? Or are you suggesting > something else? I wasn't certain reading your reply. Just one point here: I don't think we ought to be playing with XEN_VENDORVERSION. If we switch, we ought to switch back to how it was long ago - the RC number being part of XEN_EXTRAVERSION. XEN_VENDORVERSION really should be left to vendors. Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |