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
>>
next prev parent 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