Re: [BUG?] Wrong RC reported during 'make install'

[Andrew Cooper <andrew.cooper3@citrix.com>]

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 <stefano.stabellini@amd.com>
>> 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