Hi,
When I'm building my kernels, I used to tag my personal releases with a
similar annotated tag commit as with vanilla kernel, just appending
"-tv" or similar to it, i.e. "v6.3-rc4" becomes "v6.3-rc4-tv".
This has worked just fine so far, but...
Since commit 6ab7e1f95e96f0c688ae132b0e9a16c0f206689d ("setlocalversion:
use only the correct release tag for git-describe"), this is not taken
into account anymore, it uses the "git describe" tag instead of using
the actually tagged commit as "kernelrelease".
Is there a way to restore the previous behaviour without having to
revert this (and preceding) commits?
I know that we can disable CONFIG_LOCALVERSION_AUTO=y and append
directly to CONFIG_LOCALVERSION, but maybe someone knows how to use the
"old" way of using tags...?
In other words, when I have a local tag, I want "kernelrelease" to use
just that tag, and when I don't tag anything, it should just use the
standard "git describe" tag.
For the moment I have just reverted the related commits as they don't
serve any purpose for my needs.
Cheers,
Tor Vic
On Tue, Mar 28, 2023 at 2:44 AM Tor Vic <[email protected]> wrote:
>
> Hi,
>
> When I'm building my kernels, I used to tag my personal releases with a
> similar annotated tag commit as with vanilla kernel, just appending
> "-tv" or similar to it, i.e. "v6.3-rc4" becomes "v6.3-rc4-tv".
I do not understand what you want to achieve.
Let's say you wanted to release "v6.0-rc4-tv",
which consists of v6.0-rc4 with 331 extra commits.
$ git checkout v6.0-rc5^
HEAD is now at 4ed9c1e971b1 Merge tag 'kbuild-fixes-v6.0-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
$ git describe
v6.0-rc4-331-g4ed9c1e971b1
$ make kernelrelease
6.0.0-rc4-00331-g4ed9c1e971b1
Then, you released it as "v6.0-rc4-tv".
$ git tag -a v6.0-rc4-tv -m "Linux v6.0-rc4-tv"
$ make kernelrelease
6.0.0-rc4
Then, kernelrelease becomes clean '6.0.0-rc4'.
Is this what you want?
It is apparently wrong since there are
331 commits between v6.0-rc4 and v6.0-rc4-tv.
That is what 6ab7e1f95e96 _fixed_.
The behavior is now clearer and correct.
$ git describe
v6.3-rc4-174-g2bac7dc169af
$ git tag -a v6.3-rc4-tv -m "Linux v6.3-rc4-tv"
$ make kernelrelease
6.3.0-rc4-00174-g2bac7dc169af
If you wanted to make a "-tv" release,
you would want to change the version field in Makefile
before tagging.
diff --git a/Makefile b/Makefile
index da2586d4c728..8639036f5095 100644
--- a/Makefile
+++ b/Makefile
@@ -2,7 +2,7 @@
VERSION = 6
PATCHLEVEL = 3
SUBLEVEL = 0
-EXTRAVERSION = -rc4
+EXTRAVERSION = -rc4-tv
NAME = Hurr durr I'ma ninja sloth
# *DOCUMENTATION*
Then, kernelrelease shows it is a "-tv" release.
$ make kernelrelease
6.3.0-rc4-tv
> This has worked just fine so far, but...
>
> Since commit 6ab7e1f95e96f0c688ae132b0e9a16c0f206689d ("setlocalversion:
> use only the correct release tag for git-describe"), this is not taken
> into account anymore, it uses the "git describe" tag instead of using
> the actually tagged commit as "kernelrelease".
>
> Is there a way to restore the previous behaviour without having to
> revert this (and preceding) commits?
>
> I know that we can disable CONFIG_LOCALVERSION_AUTO=y and append
> directly to CONFIG_LOCALVERSION, but maybe someone knows how to use the
> "old" way of using tags...?
>
> In other words, when I have a local tag, I want "kernelrelease" to use
> just that tag, and when I don't tag anything, it should just use the
> standard "git describe" tag.
Again, I do not understand.
git tag is not stable information.
If you call it "a release",
you would want to work in the same way with/without git
even if most kernel developers are working in a git tree.
The mainline kernel, stable-kernel, linux-next are
released in https://kernel.org/
(and GitHub allows users to download a tarball of
a tagged commit.)
A released tarball (of course, there is no tag there),
produces the same kernelrelease as the git tree does.
You are requiring the kernelrelease be different
with/without the *-tv tag.
That is not what the release would look like.
The mainline kernel and stable kernel increment
the version field in Makefile.
linux-next has "localversion-next" at the top of the tree.
> For the moment I have just reverted the related commits as they don't
> serve any purpose for my needs.
>
> Cheers,
>
> Tor Vic
--
Best Regards
Masahiro Yamada
> Masahiro Yamada <[email protected]> hat am 01.04.2023 06:22 GMT geschrieben:
>
>
> On Tue, Mar 28, 2023 at 2:44 AM Tor Vic <[email protected]> wrote:
> >
> > Hi,
> >
> > When I'm building my kernels, I used to tag my personal releases with a
> > similar annotated tag commit as with vanilla kernel, just appending
> > "-tv" or similar to it, i.e. "v6.3-rc4" becomes "v6.3-rc4-tv".
>
> I do not understand what you want to achieve.
>
>
>
> Let's say you wanted to release "v6.0-rc4-tv",
> which consists of v6.0-rc4 with 331 extra commits.
>
>
> $ git checkout v6.0-rc5^
> HEAD is now at 4ed9c1e971b1 Merge tag 'kbuild-fixes-v6.0-2' of
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
> $ git describe
> v6.0-rc4-331-g4ed9c1e971b1
> $ make kernelrelease
> 6.0.0-rc4-00331-g4ed9c1e971b1
>
>
> Then, you released it as "v6.0-rc4-tv".
>
> $ git tag -a v6.0-rc4-tv -m "Linux v6.0-rc4-tv"
> $ make kernelrelease
> 6.0.0-rc4
>
>
> Then, kernelrelease becomes clean '6.0.0-rc4'.
> Is this what you want?
>
> It is apparently wrong since there are
> 331 commits between v6.0-rc4 and v6.0-rc4-tv.
>
> That is what 6ab7e1f95e96 _fixed_.
>
>
> The behavior is now clearer and correct.
>
> $ git describe
> v6.3-rc4-174-g2bac7dc169af
> $ git tag -a v6.3-rc4-tv -m "Linux v6.3-rc4-tv"
> $ make kernelrelease
> 6.3.0-rc4-00174-g2bac7dc169af
>
>
> If you wanted to make a "-tv" release,
> you would want to change the version field in Makefile
> before tagging.
>
>
> diff --git a/Makefile b/Makefile
> index da2586d4c728..8639036f5095 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2,7 +2,7 @@
> VERSION = 6
> PATCHLEVEL = 3
> SUBLEVEL = 0
> -EXTRAVERSION = -rc4
> +EXTRAVERSION = -rc4-tv
> NAME = Hurr durr I'ma ninja sloth
>
> # *DOCUMENTATION*
>
>
>
> Then, kernelrelease shows it is a "-tv" release.
>
> $ make kernelrelease
> 6.3.0-rc4-tv
>
Hi,
sorry for the late reply, and my explanation was not very clear indeed.
The above suggestion is what I'm looking for, but without modifying the source.
Let me try to give an example:
1. In sourcedir; source is at a tagged release:
$ git describe HEAD
v6.3-rc5-tv
2. Copy the kernel config which has LOCALVERSION_AUTO=y and LOCALVERSION="":
$ cp /path/to/config ./config
3. Run oldconfig:
$ make oldconfig
4. Run kernelrelease:
$ make -s kernelrelease
6.3.0-rc5-0071-g0f69b90f
Expected: 6.3-rc5-tv (or maybe 6.3.0-rc5-tv?).
I tried adding the exact tag to the 'localversion' file, but then I get this
concatenated string:
6.3.0-rc5v6.3-rc5-tv
And only adding "-tv" I at least get something better:
6.3.0-rc5-tv-0071-g0f69b90f
I do agree that the new behaviour is more correct, I'm just trying to find a clean way
to have my tag as kernel version for "releases".
If there is no other way, then I'm going to use your suggestion of changing Makefile,
which I assume can be done with a simple sed command.
Sorry I'm confused in a very "noob" way....
Cheers,
Tor Vic
>
>
>
>
>
>
> > This has worked just fine so far, but...
> >
> > Since commit 6ab7e1f95e96f0c688ae132b0e9a16c0f206689d ("setlocalversion:
> > use only the correct release tag for git-describe"), this is not taken
> > into account anymore, it uses the "git describe" tag instead of using
> > the actually tagged commit as "kernelrelease".
> >
> > Is there a way to restore the previous behaviour without having to
> > revert this (and preceding) commits?
> >
> > I know that we can disable CONFIG_LOCALVERSION_AUTO=y and append
> > directly to CONFIG_LOCALVERSION, but maybe someone knows how to use the
> > "old" way of using tags...?
> >
> > In other words, when I have a local tag, I want "kernelrelease" to use
> > just that tag, and when I don't tag anything, it should just use the
> > standard "git describe" tag.
>
>
> Again, I do not understand.
>
> git tag is not stable information.
>
> If you call it "a release",
> you would want to work in the same way with/without git
> even if most kernel developers are working in a git tree.
>
>
> The mainline kernel, stable-kernel, linux-next are
> released in https://kernel.org/
> (and GitHub allows users to download a tarball of
> a tagged commit.)
>
>
> A released tarball (of course, there is no tag there),
> produces the same kernelrelease as the git tree does.
>
> You are requiring the kernelrelease be different
> with/without the *-tv tag.
> That is not what the release would look like.
>
> The mainline kernel and stable kernel increment
> the version field in Makefile.
> linux-next has "localversion-next" at the top of the tree.
>
>
>
>
>
>
> > For the moment I have just reverted the related commits as they don't
> > serve any purpose for my needs.
> >
> > Cheers,
> >
> > Tor Vic
>
>
>
> --
> Best Regards
> Masahiro Yamada
> [email protected] hat am 05.04.2023 13:25 GMT geschrieben:
>
>
> > Masahiro Yamada <[email protected]> hat am 01.04.2023 06:22 GMT geschrieben:
> >
> >
> > On Tue, Mar 28, 2023 at 2:44 AM Tor Vic <[email protected]> wrote:
> > >
> > > Hi,
> > >
> > > When I'm building my kernels, I used to tag my personal releases with a
> > > similar annotated tag commit as with vanilla kernel, just appending
> > > "-tv" or similar to it, i.e. "v6.3-rc4" becomes "v6.3-rc4-tv".
> >
> > I do not understand what you want to achieve.
> >
> >
> >
> > Let's say you wanted to release "v6.0-rc4-tv",
> > which consists of v6.0-rc4 with 331 extra commits.
> >
> >
> > $ git checkout v6.0-rc5^
> > HEAD is now at 4ed9c1e971b1 Merge tag 'kbuild-fixes-v6.0-2' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
> > $ git describe
> > v6.0-rc4-331-g4ed9c1e971b1
> > $ make kernelrelease
> > 6.0.0-rc4-00331-g4ed9c1e971b1
> >
> >
> > Then, you released it as "v6.0-rc4-tv".
> >
> > $ git tag -a v6.0-rc4-tv -m "Linux v6.0-rc4-tv"
> > $ make kernelrelease
> > 6.0.0-rc4
> >
> >
> > Then, kernelrelease becomes clean '6.0.0-rc4'.
> > Is this what you want?
> >
> > It is apparently wrong since there are
> > 331 commits between v6.0-rc4 and v6.0-rc4-tv.
> >
> > That is what 6ab7e1f95e96 _fixed_.
> >
> >
> > The behavior is now clearer and correct.
> >
> > $ git describe
> > v6.3-rc4-174-g2bac7dc169af
> > $ git tag -a v6.3-rc4-tv -m "Linux v6.3-rc4-tv"
> > $ make kernelrelease
> > 6.3.0-rc4-00174-g2bac7dc169af
> >
> >
> > If you wanted to make a "-tv" release,
> > you would want to change the version field in Makefile
> > before tagging.
> >
> >
> > diff --git a/Makefile b/Makefile
> > index da2586d4c728..8639036f5095 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -2,7 +2,7 @@
> > VERSION = 6
> > PATCHLEVEL = 3
> > SUBLEVEL = 0
> > -EXTRAVERSION = -rc4
> > +EXTRAVERSION = -rc4-tv
> > NAME = Hurr durr I'ma ninja sloth
> >
> > # *DOCUMENTATION*
> >
> >
> >
> > Then, kernelrelease shows it is a "-tv" release.
> >
> > $ make kernelrelease
> > 6.3.0-rc4-tv
> >
>
> Hi,
>
> sorry for the late reply, and my explanation was not very clear indeed.
> The above suggestion is what I'm looking for, but without modifying the source.
>
> Let me try to give an example:
>
> 1. In sourcedir; source is at a tagged release:
> $ git describe HEAD
> v6.3-rc5-tv
>
> 2. Copy the kernel config which has LOCALVERSION_AUTO=y and LOCALVERSION="":
> $ cp /path/to/config ./config
>
> 3. Run oldconfig:
> $ make oldconfig
>
> 4. Run kernelrelease:
> $ make -s kernelrelease
> 6.3.0-rc5-0071-g0f69b90f
>
> Expected: 6.3-rc5-tv (or maybe 6.3.0-rc5-tv?).
>
> I tried adding the exact tag to the 'localversion' file, but then I get this
> concatenated string:
> 6.3.0-rc5v6.3-rc5-tv
> And only adding "-tv" I at least get something better:
> 6.3.0-rc5-tv-0071-g0f69b90f
>
> I do agree that the new behaviour is more correct, I'm just trying to find a clean way
> to have my tag as kernel version for "releases".
> If there is no other way, then I'm going to use your suggestion of changing Makefile,
> which I assume can be done with a simple sed command.
>
> Sorry I'm confused in a very "noob" way....
>
> Cheers,
> Tor Vic
>
>
Hi again,
You don't need to reply.
I've decided to change my build script according to your suggestion of using
EXTRAVERSION in Makefile, which seems to be the easiest and cleanest way of getting
the desired result.
Thanks for your help!
> >
> >
> >
> >
> >
> >
> > > This has worked just fine so far, but...
> > >
> > > Since commit 6ab7e1f95e96f0c688ae132b0e9a16c0f206689d ("setlocalversion:
> > > use only the correct release tag for git-describe"), this is not taken
> > > into account anymore, it uses the "git describe" tag instead of using
> > > the actually tagged commit as "kernelrelease".
> > >
> > > Is there a way to restore the previous behaviour without having to
> > > revert this (and preceding) commits?
> > >
> > > I know that we can disable CONFIG_LOCALVERSION_AUTO=y and append
> > > directly to CONFIG_LOCALVERSION, but maybe someone knows how to use the
> > > "old" way of using tags...?
> > >
> > > In other words, when I have a local tag, I want "kernelrelease" to use
> > > just that tag, and when I don't tag anything, it should just use the
> > > standard "git describe" tag.
> >
> >
> > Again, I do not understand.
> >
> > git tag is not stable information.
> >
> > If you call it "a release",
> > you would want to work in the same way with/without git
> > even if most kernel developers are working in a git tree.
> >
> >
> > The mainline kernel, stable-kernel, linux-next are
> > released in https://kernel.org/
> > (and GitHub allows users to download a tarball of
> > a tagged commit.)
> >
> >
> > A released tarball (of course, there is no tag there),
> > produces the same kernelrelease as the git tree does.
> >
> > You are requiring the kernelrelease be different
> > with/without the *-tv tag.
> > That is not what the release would look like.
> >
> > The mainline kernel and stable kernel increment
> > the version field in Makefile.
> > linux-next has "localversion-next" at the top of the tree.
> >
> >
> >
> >
> >
> >
> > > For the moment I have just reverted the related commits as they don't
> > > serve any purpose for my needs.
> > >
> > > Cheers,
> > >
> > > Tor Vic
> >
> >
> >
> > --
> > Best Regards
> > Masahiro Yamada