public inbox for dtrace@lists.linux.dev
 help / color / mirror / Atom feed
From: Eugene Loh <eugene.loh@oracle.com>
To: Kris Van Hees <kris.van.hees@oracle.com>
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH] Bump up the version to 2.0.4
Date: Sat, 25 Oct 2025 15:02:34 -0400	[thread overview]
Message-ID: <9d62707e-595c-975d-3674-cbc172ccd32c@oracle.com> (raw)
In-Reply-To: <aPxPZG4QJkAwS7fu@oracle.com>

On 10/25/25 02:05, Kris Van Hees wrote:

> On Fri, Oct 24, 2025 at 11:44:46PM -0400, eugene.loh@oracle.com wrote:
>> From: Eugene Loh <eugene.loh@oracle.com>
>>
>> Note that test/unittest/preprocessor/tst.predefined.sh checks that the
>> __SUNW_D_VERSION preprocessor symbol is consistent with the "dtrace -vV"
>> message, and both of them simply use the last entry of versions.list and
>> therefore will be consistent for in-tree builds.
>>
>> When RPM packages are built from the .spec file, however, _DT_VERSION,
>> used for the "dtrace -vV" "This is" message, comes from the .spec file.
> This is actually not correct.  THe value of _DT_VERSION is always provided
> by the GNUmakefile, which takes it from its own VERSION macro, which in fact
> is set to the highest (most current) version of DTrace based on versions.list.
>
> So, the version that DTrace reports is always provided by the highest version
> listed in versions.list.
>
> The version that is specified in the spec file is only used as version of the
> RPMs that are built from it.

I'm confused.  E.g., with the 2.0.4 RPMs we're testing:

$ sudo /usr/sbin/dtrace -vV
dtrace: D 2.0.3
This is DTrace 2.0.4
dtrace(1) version-control ID: 1ac1d4aaf8fb2ffa21187eb9e5227a487f7fcd40
libdtrace version-control ID: 1ac1d4aaf8fb2ffa21187eb9e5227a487f7fcd40

The "2.0.3" is _dtrace_version, which is DT_VERS_STRING, which is the 
highest version mkvers finds in versions.list.

The "2.0.4" is _DT_VERSION, which, um, okay, yeah, is set by 
GNUmakefile, which I guess gets it from "mkvers -vcurrent=t versions.list".

So if versions.list was missing 2.0.4, then how in the world could the 
RPM build report 2.0.4?  Where does that value come from?

>> Append a 2.0.4 entry to versions.list.
>>
>> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
>> ---
>>   libdtrace/versions.list | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/libdtrace/versions.list b/libdtrace/versions.list
>> index 8986d2007..8d858f0bd 100644
>> --- a/libdtrace/versions.list
>> +++ b/libdtrace/versions.list
>> @@ -65,3 +65,4 @@
>>   2.0.1	D API 2.0.1 Linux (BPF)
>>   2.0.2	D API 2.0.2 Linux (BPF)
>>   2.0.3	D API 2.0.3 Linux (BPF)
>> +2.0.4	D API 2.0.4 Linux (BPF)
>> -- 
>> 2.47.3
>>

  reply	other threads:[~2025-10-25 19:02 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-25  3:44 [PATCH] Bump up the version to 2.0.4 eugene.loh
2025-10-25  6:05 ` Kris Van Hees
2025-10-25 19:02   ` Eugene Loh [this message]
2025-10-26  2:42     ` Kris Van Hees
2025-10-27  2:27       ` Eugene Loh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9d62707e-595c-975d-3674-cbc172ccd32c@oracle.com \
    --to=eugene.loh@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=kris.van.hees@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox