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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 19 Feb 2025, Andrew Cooper wrote:
> 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@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.
> 
> 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?

Yes, looks fine. Please go ahead.