lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <914630853.739773.1680701145159@office.mailbox.org>
Date:   Wed, 5 Apr 2023 15:25:45 +0200 (CEST)
From:   torvic9@...lbox.org
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [Question] Restore previous "local tag" behaviour


> Masahiro Yamada <masahiroy@...nel.org> hat am 01.04.2023 06:22 GMT geschrieben:
> 
>  
> On Tue, Mar 28, 2023 at 2:44 AM Tor Vic <torvic9@...lbox.org> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ