[ANNOUNCE] libtraceevent.git

[ANNOUNCE] libtraceevent.git

[Steven Rostedt]

I split out tools/lib/traceevent from the kernel tree using "git subtree",
which recreates all the commits of a directory and makes that directory a
stand alone. I then updated the Makefiles, and copied over some of the
header files used to build the library. I pushed this up to:

  https://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git/

My hope is that this will now be the source of all updates to the
libtraceevent library that can be used as a stand alone package that both
perf and tracecmd can use. I would also like powertop and rasdaemon to use
this as well.

-- Steve

Re: [ANNOUNCE] libtraceevent.git

[Jiri Olsa]

On Wed, Oct 07, 2020 at 01:07:50PM -0400, Steven Rostedt wrote:
> I split out tools/lib/traceevent from the kernel tree using "git subtree",
> which recreates all the commits of a directory and makes that directory a
> stand alone. I then updated the Makefiles, and copied over some of the
> header files used to build the library. I pushed this up to:
> 
>   https://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git/
> 
> My hope is that this will now be the source of all updates to the
> libtraceevent library that can be used as a stand alone package that both
> perf and tracecmd can use. I would also like powertop and rasdaemon to use
> this as well.

hi,
I'm adding this as fedora package, is there a source arhive somewhere
in git.kernel.org for libtraceevent that spec could download?

thanks,
jirka

Re: [ANNOUNCE] libtraceevent.git

[Zamir SUN]

On Mon, Oct 12, 2020 at 6:12 PM Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Wed, Oct 07, 2020 at 01:07:50PM -0400, Steven Rostedt wrote:
> > I split out tools/lib/traceevent from the kernel tree using "git subtree",
> > which recreates all the commits of a directory and makes that directory a
> > stand alone. I then updated the Makefiles, and copied over some of the
> > header files used to build the library. I pushed this up to:
> >
> >   https://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git/
> >
> > My hope is that this will now be the source of all updates to the
> > libtraceevent library that can be used as a stand alone package that both
> > perf and tracecmd can use. I would also like powertop and rasdaemon to use
> > this as well.
>
> hi,
> I'm adding this as fedora package, is there a source arhive somewhere
> in git.kernel.org for libtraceevent that spec could download?
>

Hi Jiri,

I was also working on it before. My way to get the source code is to
manually generate the tarball like what trace-cmd did before.

See my copr
https://copr.fedorainfracloud.org/coprs/zsun/test/build/1699358/
And the spec

https://download.copr.fedorainfracloud.org/results/zsun/test/fedora-rawhide-x86_64/01699358-libtraceevent/libtraceevent.spec

I haven't have time to follow-up Steven's reply of Oct 9th about the
document compiling yet. If you are willing to work on it now maybe you
can start on top of mine. Otherwise I'll follow-up the packaging
later.

HTH.

> thanks,
> jirka
>

Re: [ANNOUNCE] libtraceevent.git

[Jiri Olsa]

On Mon, Oct 12, 2020 at 06:19:14PM +0800, Zamir SUN wrote:
> On Mon, Oct 12, 2020 at 6:12 PM Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > On Wed, Oct 07, 2020 at 01:07:50PM -0400, Steven Rostedt wrote:
> > > I split out tools/lib/traceevent from the kernel tree using "git subtree",
> > > which recreates all the commits of a directory and makes that directory a
> > > stand alone. I then updated the Makefiles, and copied over some of the
> > > header files used to build the library. I pushed this up to:
> > >
> > >   https://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git/
> > >
> > > My hope is that this will now be the source of all updates to the
> > > libtraceevent library that can be used as a stand alone package that both
> > > perf and tracecmd can use. I would also like powertop and rasdaemon to use
> > > this as well.
> >
> > hi,
> > I'm adding this as fedora package, is there a source arhive somewhere
> > in git.kernel.org for libtraceevent that spec could download?
> >
> 
> Hi Jiri,
> 
> I was also working on it before. My way to get the source code is to
> manually generate the tarball like what trace-cmd did before.
> 
> See my copr
> https://copr.fedorainfracloud.org/coprs/zsun/test/build/1699358/
> And the spec
> 
> https://download.copr.fedorainfracloud.org/results/zsun/test/fedora-rawhide-x86_64/01699358-libtraceevent/libtraceevent.spec
> 
> I haven't have time to follow-up Steven's reply of Oct 9th about the
> document compiling yet. If you are willing to work on it now maybe you
> can start on top of mine. Otherwise I'll follow-up the packaging
> later.

we discussed on irc and Zamir will continue on this ;-)
plz let me know if I can help with something

thanks,
jirka

Re: [ANNOUNCE] libtraceevent.git

[Steven Rostedt]

On Mon, 12 Oct 2020 12:12:08 +0200
Jiri Olsa <jolsa@redhat.com> wrote:

> On Wed, Oct 07, 2020 at 01:07:50PM -0400, Steven Rostedt wrote:
> > I split out tools/lib/traceevent from the kernel tree using "git subtree",
> > which recreates all the commits of a directory and makes that directory a
> > stand alone. I then updated the Makefiles, and copied over some of the
> > header files used to build the library. I pushed this up to:
> > 
> >   https://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git/
> > 
> > My hope is that this will now be the source of all updates to the
> > libtraceevent library that can be used as a stand alone package that both
> > perf and tracecmd can use. I would also like powertop and rasdaemon to use
> > this as well.  
> 
> hi,
> I'm adding this as fedora package, is there a source arhive somewhere
> in git.kernel.org for libtraceevent that spec could download?
> 

Hi Jiri!

Once it's shown that it works for all the package maintainers, I will tag
it which should create the tarballs automatically on the above link. But I
wanted to fix all the packaging bugs before doing so. I hope this doesn't
make it into a catch-22. Where you can't package till there's a source
tarball, but I can't make a source tarball until I know you can package
it ;-)

-- Steve

Re: [ANNOUNCE] libtraceevent.git

[Sudip Mukherjee]

On Mon, Oct 12, 2020 at 4:19 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 12 Oct 2020 12:12:08 +0200
> Jiri Olsa <jolsa@redhat.com> wrote:
>
> > On Wed, Oct 07, 2020 at 01:07:50PM -0400, Steven Rostedt wrote:
> > > I split out tools/lib/traceevent from the kernel tree using "git subtree",
> > > which recreates all the commits of a directory and makes that directory a
> > > stand alone. I then updated the Makefiles, and copied over some of the
> > > header files used to build the library. I pushed this up to:
> > >
> > >   https://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git/
> > >
> > > My hope is that this will now be the source of all updates to the
> > > libtraceevent library that can be used as a stand alone package that both
> > > perf and tracecmd can use. I would also like powertop and rasdaemon to use
> > > this as well.
> >
> > hi,
> > I'm adding this as fedora package, is there a source arhive somewhere
> > in git.kernel.org for libtraceevent that spec could download?
> >
>
> Hi Jiri!
>
> Once it's shown that it works for all the package maintainers, I will tag
> it which should create the tarballs automatically on the above link. But I
> wanted to fix all the packaging bugs before doing so. I hope this doesn't
> make it into a catch-22. Where you can't package till there's a source
> tarball, but I can't make a source tarball until I know you can package
> it ;-)

For Debian I have raised https://bugs.debian.org/971976 but I will
package it locally today just to check there is no packaging bugs for
our packaging.


-- 
Regards
Sudip

Re: [ANNOUNCE] libtraceevent.git

[Tony Jones]

On Mon, Oct 12, 2020 at 11:19:50AM -0400, Steven Rostedt wrote:

> Once it's shown that it works for all the package maintainers, I will tag
> it which should create the tarballs automatically on the above link.

Hi.

It builds fine for me after manually creating the tarball from git.  
Once there is an official versioned tarball I'll push it into
openSUSE.

I presume some perf Makefile changes will be forthcoming to use it,
rather than continuing to force build it out of TRACE_EVENT_DIR

Tony

Re: [ANNOUNCE] libtraceevent.git

[Jiri Olsa]

On Mon, Oct 12, 2020 at 11:41:20AM -0700, Tony Jones wrote:
> On Mon, Oct 12, 2020 at 11:19:50AM -0400, Steven Rostedt wrote:
> 
> > Once it's shown that it works for all the package maintainers, I will tag
> > it which should create the tarballs automatically on the above link.
> 
> Hi.
> 
> It builds fine for me after manually creating the tarball from git.  
> Once there is an official versioned tarball I'll push it into
> openSUSE.
> 
> I presume some perf Makefile changes will be forthcoming to use it,
> rather than continuing to force build it out of TRACE_EVENT_DIR

right, we need to detect it in features like any other library
and use it if it's found

jirka

Re: [ANNOUNCE] libtraceevent.git

[Steven Rostedt]

On Mon, 12 Oct 2020 20:52:17 +0200
Jiri Olsa <jolsa@redhat.com> wrote:

> > I presume some perf Makefile changes will be forthcoming to use it,
> > rather than continuing to force build it out of TRACE_EVENT_DIR  
> 
> right, we need to detect it in features like any other library
> and use it if it's found

I need to do the same with trace-cmd.

-- Steve

Re: [ANNOUNCE] libtraceevent.git

[Steven Rostedt]

[ Removing the powertop mailing list because it's rejecting everything ]

On Mon, 12 Oct 2020 11:41:20 -0700
Tony Jones <tonyj@suse.de> wrote:

> On Mon, Oct 12, 2020 at 11:19:50AM -0400, Steven Rostedt wrote:
> 
> > Once it's shown that it works for all the package maintainers, I will tag
> > it which should create the tarballs automatically on the above link.  
> 
> Hi.
> 
> It builds fine for me after manually creating the tarball from git.  
> Once there is an official versioned tarball I'll push it into
> openSUSE.
> 
> I presume some perf Makefile changes will be forthcoming to use it,
> rather than continuing to force build it out of TRACE_EVENT_DIR
> 

Zamir found this issue with the Documentation man pages:

Note, I'm not sure the proper way to fix this. I think this is the last
issue I need to resolve before making the tag.

-- Steve


On Thu, 8 Oct 2020 17:50:19 +0800
Zamir SUN <sztsian@gmail.com> wrote:

> Hi,
> 
> When I try to compiling the document of libtraceevent with the fix I 
> mentioned in [1] applied, make doc-install fails with errors like
> 
> "/usr/bin/install: cannot stat 'libtraceevent-record_parse.3': No such 
> file or directory"
> 
> Checking the compiled documents I see a lot of tep_*.3 generated, and 
> some libtraceevent_*.html. However no libtraceevent_*.3.
> 
> $ ls Documentation/*3 | head
> Documentation/libtraceevent.3
> Documentation/tep_alloc.3
> Documentation/tep_clear_flag.3
> Documentation/tep_cmdline_pid.3
> Documentation/tep_data_comm_from_pid.3
> Documentation/tep_data_flags.3
> Documentation/tep_data_pid.3
> Documentation/tep_data_pid_from_comm.3
> Documentation/tep_data_preempt_count.3
> Documentation/tep_data_type.3
> ls Documentation/*html | head
> Documentation/libtraceevent-commands.html
> Documentation/libtraceevent-cpus.html
> Documentation/libtraceevent-endian_read.html
> Documentation/libtraceevent-event_find.html
> Documentation/libtraceevent-event_get.html
> Documentation/libtraceevent-event_list.html
> Documentation/libtraceevent-event_print.html
> Documentation/libtraceevent-field_find.html
> Documentation/libtraceevent-field_get_val.html
> Documentation/libtraceevent-field_print.html
> 
> I also tried to port the Makefile from trace-cmd/Documentation to the 
> document dir, and it still only generates tep_*.3 files, so I feel this 
> is not the issue with the patch from [1].
> 
> As for my local environment, I have xmlto and asciidoc installed[2], but 
> not asciidoctor. I expect asciidoc could generate the documentations 
> like what it did in trace-cmd before.
> 
> Any idea if this is issue with my environment or it's something that 
> need to be implemented in the Makefile?
>  

Hi Zamir,

Thanks a lot for looking into this. I took your advice and reverted my
blind copy of the Makefiles, scripts and include headers, and instead
copied over their full history from the Linux kernel Tools directory.

You can see that update no (which now includes the utilities.mak as well).

Can you see if this patch fixes your current issue?

-- Steve

diff --git a/Documentation/Makefile b/Documentation/Makefile
index edb8623..3a981be 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -157,7 +157,7 @@ endif
 do-install-man: man
 	$(call QUIET_INSTALL, Documentation-man) \
 		$(INSTALL) -d -m 755 $(DESTDIR)$(man3dir); \
-		$(INSTALL) -m 644 $(DOC_MAN3) $(DESTDIR)$(man3dir);
+		$(INSTALL) -m 644 $(OUTPUT)*.3 $(DESTDIR)$(man3dir);
 
 install-man: check-man-tools man do-install-man
 

Re: [ANNOUNCE] libtraceevent.git

[Sudip Mukherjee]

Hi Steve,

On Mon, Oct 12, 2020 at 8:17 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
>
> [ Removing the powertop mailing list because it's rejecting everything ]
>
> On Mon, 12 Oct 2020 11:41:20 -0700
> Tony Jones <tonyj@suse.de> wrote:
>
> > On Mon, Oct 12, 2020 at 11:19:50AM -0400, Steven Rostedt wrote:
> >
> > > Once it's shown that it works for all the package maintainers, I will tag
> > > it which should create the tarballs automatically on the above link.
> >

Works for me.

> Can you see if this patch fixes your current issue?
>
> -- Steve
>
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index edb8623..3a981be 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -157,7 +157,7 @@ endif
>  do-install-man: man
>         $(call QUIET_INSTALL, Documentation-man) \
>                 $(INSTALL) -d -m 755 $(DESTDIR)$(man3dir); \
> -               $(INSTALL) -m 644 $(DOC_MAN3) $(DESTDIR)$(man3dir);
> +               $(INSTALL) -m 644 $(OUTPUT)*.3 $(DESTDIR)$(man3dir);
>
>  install-man: check-man-tools man do-install-man
>

I faced the same problem and this patch worked for me.


-- 
Regards
Sudip

Re: [ANNOUNCE] libtraceevent.git

[Zamir SUN]

On Tue, Oct 13, 2020 at 3:17 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
>
> [ Removing the powertop mailing list because it's rejecting everything ]
>
> On Mon, 12 Oct 2020 11:41:20 -0700
> Tony Jones <tonyj@suse.de> wrote:
>
> > On Mon, Oct 12, 2020 at 11:19:50AM -0400, Steven Rostedt wrote:
> >
> > > Once it's shown that it works for all the package maintainers, I will tag
> > > it which should create the tarballs automatically on the above link.
> >
> > Hi.
> >
> > It builds fine for me after manually creating the tarball from git.
> > Once there is an official versioned tarball I'll push it into
> > openSUSE.
> >
> > I presume some perf Makefile changes will be forthcoming to use it,
> > rather than continuing to force build it out of TRACE_EVENT_DIR
> >
>
> Zamir found this issue with the Documentation man pages:
>
> Note, I'm not sure the proper way to fix this. I think this is the last
> issue I need to resolve before making the tag.
>

If anyone interested in, the discussion of this document compiling is
in the thread "libtraceevent: make doc-install tries different file
names than generated".

With the patch Steve mentioned, I can package this in RPM already. And
it's pending review in Fedora now.
https://bugzilla.redhat.com/show_bug.cgi?id=1887470

So, for me, there is no more issue for Fedora packaging.

Thanks.

Re: [ANNOUNCE] libtraceevent.git

[Steven Rostedt]

On Tue, 13 Oct 2020 11:06:16 +0800
Zamir SUN <sztsian@gmail.com> wrote:

> On Tue, Oct 13, 2020 at 3:17 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> >
> > [ Removing the powertop mailing list because it's rejecting everything ]
> >
> > On Mon, 12 Oct 2020 11:41:20 -0700
> > Tony Jones <tonyj@suse.de> wrote:
> >  
> > > On Mon, Oct 12, 2020 at 11:19:50AM -0400, Steven Rostedt wrote:
> > >  
> > > > Once it's shown that it works for all the package maintainers, I will tag
> > > > it which should create the tarballs automatically on the above link.  
> > >
> > > Hi.
> > >
> > > It builds fine for me after manually creating the tarball from git.
> > > Once there is an official versioned tarball I'll push it into
> > > openSUSE.
> > >
> > > I presume some perf Makefile changes will be forthcoming to use it,
> > > rather than continuing to force build it out of TRACE_EVENT_DIR
> > >  
> >
> > Zamir found this issue with the Documentation man pages:
> >
> > Note, I'm not sure the proper way to fix this. I think this is the last
> > issue I need to resolve before making the tag.
> >  
> 
> If anyone interested in, the discussion of this document compiling is
> in the thread "libtraceevent: make doc-install tries different file
> names than generated".
> 
> With the patch Steve mentioned, I can package this in RPM already. And
> it's pending review in Fedora now.
> https://bugzilla.redhat.com/show_bug.cgi?id=1887470
> 
> So, for me, there is no more issue for Fedora packaging.
> 

So should I just add that one patch and tag it?

-- Steve

Re: [ANNOUNCE] libtraceevent.git

[Sudip Mukherjee]

Hi Steve,

On Tue, Oct 13, 2020 at 2:02 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Tue, 13 Oct 2020 11:06:16 +0800
> Zamir SUN <sztsian@gmail.com> wrote:
>
> > On Tue, Oct 13, 2020 at 3:17 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> > >
<snip>
> > So, for me, there is no more issue for Fedora packaging.
> >
>
> So should I just add that one patch and tag it?

Just a thought, if you see
https://repology.org/project/linux-tools/versions then you will notice
that libtracevent has been packaged by the distros with a version of
v5.x+, and I will have the same problem for Debian also. Do you think
it makes sense to start  with a version of v6.x when you tag it? If
that is not possible then we will have to use epoch like we did for
libbpf.


-- 
Regards
Sudip

Re: [ANNOUNCE] libtraceevent.git

[Zamir SUN]

On 10/13/20 9:02 PM, Steven Rostedt wrote:
> On Tue, 13 Oct 2020 11:06:16 +0800
> Zamir SUN <sztsian@gmail.com> wrote:
> 
>> On Tue, Oct 13, 2020 at 3:17 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>>>
>>>
>>> [ Removing the powertop mailing list because it's rejecting everything ]
>>>
>>> On Mon, 12 Oct 2020 11:41:20 -0700
>>> Tony Jones <tonyj@suse.de> wrote:
>>>   
>>>> On Mon, Oct 12, 2020 at 11:19:50AM -0400, Steven Rostedt wrote:
>>>>   
>>>>> Once it's shown that it works for all the package maintainers, I will tag
>>>>> it which should create the tarballs automatically on the above link.
>>>>
>>>> Hi.
>>>>
>>>> It builds fine for me after manually creating the tarball from git.
>>>> Once there is an official versioned tarball I'll push it into
>>>> openSUSE.
>>>>
>>>> I presume some perf Makefile changes will be forthcoming to use it,
>>>> rather than continuing to force build it out of TRACE_EVENT_DIR
>>>>   
>>>
>>> Zamir found this issue with the Documentation man pages:
>>>
>>> Note, I'm not sure the proper way to fix this. I think this is the last
>>> issue I need to resolve before making the tag.
>>>   
>>
>> If anyone interested in, the discussion of this document compiling is
>> in the thread "libtraceevent: make doc-install tries different file
>> names than generated".
>>
>> With the patch Steve mentioned, I can package this in RPM already. And
>> it's pending review in Fedora now.
>> https://bugzilla.redhat.com/show_bug.cgi?id=1887470
>>
>> So, for me, there is no more issue for Fedora packaging.
>>
> 
> So should I just add that one patch and tag it?
> 

That would be great, at least for Fedora packaging.

Thanks!

-- 
Zamir SUN
Fedora user
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E

Re: [ANNOUNCE] libtraceevent.git

[Steven Rostedt]

On Wed, 14 Oct 2020 11:08:48 +0100
Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:

> Just a thought, if you see
> https://repology.org/project/linux-tools/versions then you will notice
> that libtracevent has been packaged by the distros with a version of
> v5.x+, and I will have the same problem for Debian also. Do you think
> it makes sense to start  with a version of v6.x when you tag it? If
> that is not possible then we will have to use epoch like we did for
> libbpf.

Grumble. This is another reason I wish this was not part of the kernel. It
should not have a versioning based on the kernel. Yeah, this may be an
issue, especially, since library versions have real meaning with respect
to compatibility, where the Linux kernel version numbers do not.

We may need to use the epoch on this, because 5.7 has no meaning compared
to 5.8 and 5.9. I didn't even realize this was being shipped yet.

Yeah, I want to make this 1.1.0 as I've been tracking changes internally
with this.

-- Steve

Re: [ANNOUNCE] libtraceevent.git

[Steven Rostedt]

On Wed, 14 Oct 2020 20:56:53 +0800
Zamir SUN <sztsian@gmail.com> wrote:

> > 
> > So should I just add that one patch and tag it?
> >   
> 
> That would be great, at least for Fedora packaging.

I'm going with version 1.1.0 and not following the kernel versioning, as
that would just add to the confusion.

Here's the tarball:

  https://git.kernel.org/pub/scm/libs/libtrace/libtraceevent.git/snapshot/libtraceevent-1.1.0.tar.gz

-- Steve