# freebsd-version , uname , point-release



## Alain De Vos (Jul 23, 2022)

Currently i am running FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212
Is there a point release which relates to this , or how can i know which point-release is clossest, or is this an irrelevant question ?


----------



## eternal_noob (Jul 23, 2022)

Maybe i get something wrong, but would not 13.1 be the closest point release? (Unless you can look into the future and know exactly the number of commits to follow (if any), of course).


----------



## mer (Jul 23, 2022)

How are you getting that version?  Is that from "uname -a"  If so I think that should relate to a git commit hash the kernel was built from.  

If you run "freebsd-version -kru" what do you get?
I get 
`freebsd-version -kru
13.1-RELEASE
13.1-RELEASE
13.1-RELEASE
uname -a
FreeBSD FBSDNUC 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC amd64`

I am not running a custom or built kernel, everything updated from pkg/freebsd-update.


----------



## zirias@ (Jul 23, 2022)

mer said:


> If so I think that should relate to a git commit hash the kernel was built from.


It is. That's a convenient way to check what the sources were in presence of e.g. local branches, and of course it's pretty relevant on "constantly moving" branches like stable/x and main (-CURRENT). The `nXXXX..` part is actually `git rev-list --count` output, for those nostalgics who need consecutive revision numbers like with subversion.

For "vanilla" release versions (including patchlevels), it's mostly meaningless (will always be exactly the same for the same version).

Here, we see exactly the commit hash of the commit that was actually tagged release/13.1.0: https://cgit.freebsd.org/src/commit/?h=releng/13.1&id=fc952ac2212b121aa6eefc273f5960ec3e0a466d


----------



## zirias@ (Jul 23, 2022)

Just as an example how it's helpful even for RELEASE versions when you have local branches, here's my output:

```
$ uname -v
FreeBSD 13.1-RELEASE config-n250149-602a75898a5 DESKTOP
```
I have a local branch namend `config` where I maintain my different kernel configurations. This tells me the kernel was built with the config named `DESKTOP` as present in git commit `602a75898a5`.


----------



## PMc (Jul 23, 2022)

Zirias said:


> Just as an example how it's helpful even for RELEASE versions when you have local branches, here's my output:
> 
> ```
> $ uname -v
> ...


I don't find that one in my repo 
I haeked a bit into newvers.sh to make things more clear below my local patches:

```
FreeBSD 13.1-RELEASE n250170-0b22bbb95ee[0b22bbb95ee=fc952ac2212+22] D6R13V1
```



Alain De Vos said:


> how can i know which point-release is clossest, or is this an irrelevant question ?


It is not an irreleveant question - but a genuine algorithm that would identify the closest point release, starting from any arbitrary commit, is not trivial because git allows for octopus merges and the like, so there may be more than one parent and the term "closest" is not defined anymore.
For my uname line I am walking backwards through the commit history until I find a commit that is contained in a public branch, but even with the full repo available this seems to work only iteratively.


----------



## zirias@ (Jul 23, 2022)

PMc said:


> It is not an irreleveant question


It is not, but it has a plain simple answer: As long as you either install binary releases/updates or build straight from releng/*, there's no need to know. And even if you build from a local branch on top of releng/* (with local modifications), the version string will still contain everything (major, minor, patchlevel) of what's "nearest" to what you built from 



PMc said:


> I haeked a bit into newvers.sh


I find the `=` (equals) a bit misleading for what's probably meant to be the nearest "parent revision" of an official branch, guess I would have preferred for example `<-` or something like that. But in general, pretty nice idea! Would you mind to share that hack?


----------



## PMc (Jul 23, 2022)

Zirias said:


> I find the `=` (equals) a bit misleading for what's probably meant to be the nearest "parent revision" of an official branch,


You noticed the "plus 22" at the end? (It's "equal" to the official commit plus 22 local patches).



Zirias said:


> guess I would have preferred for example `<-` or something like that. But in general, pretty nice idea! Would you mind to share that hack?


You're welcome.

<crap deleted>

The final part in the source tree is only this ($VCSDIR is provided by the findvcs function):

```
--- a/sys/conf/newvers.sh
+++ b/sys/conf/newvers.sh
@@ -285,12 +285,16 @@ if [ -n "$hg_cmd" ] ; then
        fi
 fi
 
+if findvcs .p23b; then
+    p23b="[`cat ${VCSDIR}/rev 2>/dev/null`]"
+fi
+
 [ ${include_metadata} = "if-modified" -a ${modified} = "yes" ] && include_metadata=yes
 if [ ${include_metadata} != "yes" ]; then
-       VERINFO="${VERSION}${svn}${git}${gitup}${hg} ${i}"
+       VERINFO="${VERSION}${svn}${git}${gitup}${hg}${p23b} ${i}"
        VERSTR="${VERINFO}\\n"
 else
-       VERINFO="${VERSION} #${v}${svn}${git}${gitup}${hg}: ${t}"
+       VERINFO="${VERSION} #${v}${svn}${git}${gitup}${hg}${p23b}: ${t}"
        VERSTR="${VERINFO}\\n    ${u}@${h}:${d}\\n"
 fi
```

<crap deleted>

This patch requires that the desired string to add to the $VERINFO is placed into /usr/src/.p23b/rev. And this one here is probably the function that creates it. (I tend to forget I finally fixed this by going into the low-level plumbing stuff; it was more complicated and slow high-level commands earlier.)


----------



## zirias@ (Jul 23, 2022)

PMc said:


> You noticed the "plus 22" at the end? (It's "equal" to the official commit plus 22 local patches).


Ok, it makes sense like this, but to me, it was non-obvious...


PMc said:


> You're welcome.


Thanks for the code. It sure looks useful, so I'll probably add something similar (I guess it has a free license? ) to my own local branch! 
(although it _currently_ only has kernel configs and is therefore named "config", it _had_ some cherry-picked and backported patches from -CURRENT in the past, and who knows when this will be necessary again ...)


----------



## PMc (Jul 24, 2022)

Zirias said:


> Ok, it makes sense like this, but to me, it was non-obvious...
> 
> Thanks for the code. It sure looks useful, so I'll probably add something similar (I guess it has a free license? ) to my own local branch!


Sure, do so. Grab what You want and use what You can. Just don't sue me for publishing it (I don't think it has a copyright at all).


----------



## zirias@ (Jul 24, 2022)

PMc said:


> Grab what You want and use what You can. Just don't sue me for publishing it


That's btw a great paraphrasing of the BSD 2-clause license. Or the good old rules in the (C64) scene 
(edit: all that's missing is "please give credit ...")


----------

