freebsd-version , uname , point-release

Alain De Vos

Alain De Vos

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 ?
 
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).
 
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.
 
mer said:
If so I think that should relate to a git commit hash the kernel was built from.
Click to expand...
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
 
  • Like
Reactions: mer
Just as an example how it's helpful even for RELEASE versions when you have local branches, here's my output:
Code: 
$ 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.
 
Zirias said:
Just as an example how it's helpful even for RELEASE versions when you have local branches, here's my output:
Code: 
$ 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.
Click to expand...
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:
Code: 
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 ?
Click to expand...
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.
 
PMc said:
It is not an irreleveant question
Click to expand...
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
Click to expand...
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?
 
Zirias said:
I find the = (equals) a bit misleading for what's probably meant to be the nearest "parent revision" of an official branch,
Click to expand...
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?
Click to expand...
You're welcome.

<crap deleted>

The final part in the source tree is only this ($VCSDIR is provided by the findvcs function):
Code: 
--- 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.)
 
PMc said:
You noticed the "plus 22" at the end? (It's "equal" to the official commit plus 22 local patches).
Click to expand...
Ok, it makes sense like this, but to me, it was non-obvious...
PMc said:
You're welcome.
Click to expand...
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! :cool:
(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 ...)
 
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! :cool:
Click to expand...
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).
 
You must log in or register to reply here.
Back
Top