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

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

[Oleksii Kurochko]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

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?

Thanks in advance.

Best regards,
  Oleksii




[-- Attachment #2: Type: text/html, Size: 1280 bytes --]

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

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

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>

commit 319ac724748f2f03a5cc6e9648c9151f519eaeac
diff --git a/xen/Makefile b/xen/Makefile
index 65b460e2b4..3b395e1ead 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -6,6 +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_VENDORVERSION = 4
 export XEN_EXTRAVERSION ?= -rc$(XEN_VENDORVERSION)
 export XEN_FULLVERSION   = $(XEN_VERSION).$(XEN_SUBVERSION)$(XEN_EXTRAVERSION)
 -include xen-version

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

[Andrew Cooper]

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.

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

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

[Jan Beulich]

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

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

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]

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@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.

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.

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

[Jan Beulich]

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@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.
> 
> 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

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

[Andrew Cooper]

On 14/02/2025 7:15 am, Jan Beulich wrote:
> 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@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.
>> 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.

Release tarballs are fine, because they are always tagged on a commit
editing the micro version in XEN_EXTRAVERSION.

It's only RC tarballs that go wrong.

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

Hopefully the other email is clear and covers everything, but tl;dr, I
suggest we do edit XEN_EXTRAVERSION (and not XEN_VENDORVERSION) for each
RC tarball.

~Andrew

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

[Andrew Cooper]

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

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

[Stefano Stabellini]

[-- Attachment #1: Type: text/plain, Size: 4636 bytes --]

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@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?

Yes, looks fine. Please go ahead.

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

[Jan Beulich]

On 19.02.2025 19:04, Andrew Cooper wrote:
> 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. It's not optimal that the file then needs touching for every RC, but
then again it's also no different from what we do on every stable release.

Jan