[PATCH] Bump up the version to 2.0.4

[PATCH] Bump up the version to 2.0.4

[eugene.loh]

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.

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

Re: [PATCH] Bump up the version to 2.0.4

[Kris Van Hees]

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.

> 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
> 

Re: [PATCH] Bump up the version to 2.0.4

[Eugene Loh]

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
>>

Re: [PATCH] Bump up the version to 2.0.4

[Kris Van Hees]

On Sat, Oct 25, 2025 at 03:02:34PM -0400, Eugene Loh wrote:
> 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?

I think that the issue is found in the following line in GNUmakefile:

INVARIANT_CFLAGS := -std=gnu99 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 $(if $(NATIVE_BITNESS_ONLY),-DNATIVE_BITNESS_ONLY) -D_DT_VERSION=\"$(VERSION)\"

For regular builds, that seems to be taking its value from

VERSION := $(shell ./libdtrace/mkvers -vcurrent=t libdtrace/versions.list)

whereas for rpm builds, it seems to take its value from

make -j $(getconf _NPROCESSORS_ONLN) VERSION=%{version} \
        %{bpfc} %{maybe_use_fuse2}

That is the only explanation I can come up with.

This seems (to me) another case where versioning cleanup is needed.  I think
that the version string should be defined by the build rather than the
spec file.  The version in the spec file should not be anything but the
version of the packaging.  The version of the implementation really ought to
be handled by the source code tree itself.

Re: [PATCH] Bump up the version to 2.0.4

[Eugene Loh]

On 10/25/25 22:42, Kris Van Hees wrote:

> On Sat, Oct 25, 2025 at 03:02:34PM -0400, Eugene Loh wrote:
>> 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?
> I think that the issue is found in the following line in GNUmakefile:
>
> INVARIANT_CFLAGS := -std=gnu99 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 $(if $(NATIVE_BITNESS_ONLY),-DNATIVE_BITNESS_ONLY) -D_DT_VERSION=\"$(VERSION)\"
>
> For regular builds, that seems to be taking its value from
>
> VERSION := $(shell ./libdtrace/mkvers -vcurrent=t libdtrace/versions.list)
>
> whereas for rpm builds, it seems to take its value from
>
> make -j $(getconf _NPROCESSORS_ONLN) VERSION=%{version} \
>          %{bpfc} %{maybe_use_fuse2}
>
> That is the only explanation I can come up with.

Right.  So that version number *IS* coming from the .spec file.

> This seems (to me) another case where versioning cleanup is needed.  I think
> that the version string should be defined by the build rather than the
> spec file.  The version in the spec file should not be anything but the
> version of the packaging.  The version of the implementation really ought to
> be handled by the source code tree itself.

Okay.  So, the .spec file *shouldn't* be specifying VERSION in that make 
line.  I'll go with that understanding and post a v2.