guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#50756] [PATCH] gnu: Add lttng-tools.


From: Xinglu Chen
Subject: [bug#50756] [PATCH] gnu: Add lttng-tools.
Date: Sun, 26 Sep 2021 11:42:18 +0200

On Fri, Sep 24 2021, Olivier Dion via Guix-patches via wrote:

> On Fri, 24 Sep 2021, Xinglu Chen <public@yoctocell.xyz> wrote:
>> On Thu, Sep 23 2021, Olivier Dion via Guix-patches via wrote:
>
>>> +(define-public lttng-tools
>>> +  (package
>>> +    (name "lttng-tools")
>>> +    (version "2.12.5")
>>
>> Version 2.13 is available; any reason for not using it?
>
> Would require to bump version of lttng-ust also I think.  I prefer to do all 
> of this
> in another patch.

Ah, OK.

>>> +    (arguments
>>> +     `(#:tests? #f
>>> +       #:parallel-tests? #f
>>
>> There is no need to set #:parallel-tests? if #:tests? is set to #f.
>
> During my testing, I noticed that test in parallel are not working
> because of how the lttng-daemon works.  So I disable the parallel option
> in order to not forget it when testing will work in the future.  I
> should probably add a comment to explain the rationale here.
>
>>> +    (propagated-inputs
>>> +     `(("libkmod" ,kmod)
>>> +       ("modprobe" ,module-init-tools)))
>>
>> Any reason for the labels not being the same as the package?
>
> I follow the naming convention in the description of the project's README
> so it's easier to map the dependencies described by it to Guix's
> packages.  I can change this, but I find it more clear that way.

The name of the label is usually the same as the package, so I would
change them to “kmod” and “module-init-tools” respectively.

>>
>>> +    (native-inputs
>>> +     `(("pkg-config" ,pkg-config)
>>> +       ("perl" ,perl)
>>> +       ("libpfm4" ,libpfm4)
>>> +       ("python" ,python-3)
>>
>> While running the configure script, I get
>>
>>   configure: You may configure with --enable-python-bindings if you want 
>> Python bindings.
>>
>> So you would have to pass the ‘--enable-python-bindings’ flag, and
>> Python would be needed during runtime as well.
>
> Does it tho?  Bindings can be generated at build time. While you would
> require python-3 at runtime to use the bindings, you don't require
> python-3 to use the other tools of the project.  I don't mind adding it
> to the inputs, I'm just asking.

True, the user can install always install Python in their profile
themselves.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]