Re: Timberland nvme-cli/libnvme upstream merge - dbus dependency.

Re: Timberland nvme-cli/libnvme upstream merge - dbus dependency.

[John Meneghini]

I have a question for the upstream nvme maintainers.

Why does libnvme, as v1.3, now have a dependency on dbus?

I thought the goal was to keep the nvme management plane as streamline and daemon free as possible.  We already have a 
dependency on the udev daemon. Isn't that enough?

/John

On 2/3/23 08:47, John Meneghini wrote:
> Everyone should note that I have updated the timberland-sig repositories and re-based these pull requests onto nvme-cli v2.3 and 
> libnvme v1.3 before pushing these change upstream.
> 
> As a part of the re-base I noticed that the meson tool chain was updated in v2.3/v1.3 so I was no longer able to compile this 
> stuff on my standard RHEL 8 dev plaform.  I has to switch to Fedora 37, which seems to have the needed updated tool chain to 
> compile everything. 
 >
> Everything was there on my fedora 37 machine except for dbus.
> 
> Executing subproject libnvme:dbus
> 
> dbus| Project name: dbus
> dbus| Project version: 1.15.3
> dbus| C compiler for the host machine: cc (gcc 12.2.1 "cc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)")
> dbus| C linker for the host machine: cc ld.bfd 2.37-37
> dbus| Program python3 found: YES (/usr/bin/python3)
> dbus| Message: Detected platform : Unix (linux)
> ...
> nvme-cli 2.3
> 
>    Subprojects
>      dbus   : YES 5 warnings
>      libnvme: YES

On 2/3/23 05:08, Martin Wilck wrote:
 > On Thu, 2023-02-02 at 17:38 -0500, John Meneghini wrote:
 >> Please see the pull requests:
 >>
 >> https://github.com/linux-nvme/libnvme/pull/572
 >>
 >> https://github.com/linux-nvme/nvme-cli/pull/1791
 >>
 >> /John
 >
 > I have followed up with
 >
 > https://github.com/dracutdevs/dracut/pull/2184
 >
 > Martin

Re: Timberland nvme-cli/libnvme upstream merge - dbus dependency.

[Daniel Wagner]

On Fri, Feb 03, 2023 at 10:43:04AM -0500, John Meneghini wrote:
> I have a question for the upstream nvme maintainers.
> 
> Why does libnvme, as v1.3, now have a dependency on dbus?

libnvme-mi uses a D-Bus service for discovering devices. Initially libnvme-mi
used libsystemd as D-Bus library. libsystemd is only available as shared
library, thus we can't build the library statically (yes, some people want to do
this). We switch the implementation to use libdbus. I made usre that it can
be consumed as suprojects. New library, old optional dependency.

> I thought the goal was to keep the nvme management plane as streamline and
> daemon free as possible.

Yes and it is optional. The new feature is that you can compile it
as static dependency and this is what you currently see.

The current nvme-cli meson.build configuration for libnvme is always pulling the
fallback. A workaround is to build libnvme as separate step as you would do when
packaging.

> We already have a dependency on the udev daemon.

Not on code level (no library). I don't see how we can avoid this and I don't
understand why this is now a problem.

Concerning meson version: We always used features from 0.50.0 hence the min
version of 0.47.0 was wrong. We just updated this.

Daniel

RE: Timberland nvme-cli/libnvme upstream merge - dbus dependency.

[Belanger, Martin]

> On Fri, Feb 03, 2023 at 10:43:04AM -0500, John Meneghini wrote:
> > I have a question for the upstream nvme maintainers.
> >
> > Why does libnvme, as v1.3, now have a dependency on dbus?
> 
> libnvme-mi uses a D-Bus service for discovering devices. Initially libnvme-mi
> used libsystemd as D-Bus library. libsystemd is only available as shared library,
> thus we can't build the library statically (yes, some people want to do this). We
> switch the implementation to use libdbus. I made usre that it can be consumed
> as suprojects. New library, old optional dependency.
> 
> > I thought the goal was to keep the nvme management plane as streamline
> > and daemon free as possible.
> 
> Yes and it is optional. The new feature is that you can compile it as static
> dependency and this is what you currently see.
> 
> The current nvme-cli meson.build configuration for libnvme is always pulling
> the fallback. A workaround is to build libnvme as separate step as you would
> do when packaging.
> 
> > We already have a dependency on the udev daemon.
> 
> Not on code level (no library). I don't see how we can avoid this and I don't
> understand why this is now a problem.
> 
> Concerning meson version: We always used features from 0.50.0 hence the
> min version of 0.47.0 was wrong. We just updated this.
> 
> Daniel

In meson_options.txt we find the build option libdbus. Maybe the dependency can be disabled simply as follows:

$ meson .build -Dlibdbus=disabled
$ make

Martin

Internal Use - Confidential

Re: Timberland nvme-cli/libnvme upstream merge - dbus dependency.

[Keith Busch]

On Fri, Feb 03, 2023 at 05:22:13PM +0100, Daniel Wagner wrote:
> On Fri, Feb 03, 2023 at 10:43:04AM -0500, John Meneghini wrote:
> > I have a question for the upstream nvme maintainers.
> > 
> > Why does libnvme, as v1.3, now have a dependency on dbus?
> 
> libnvme-mi uses a D-Bus service for discovering devices. Initially libnvme-mi
> used libsystemd as D-Bus library. libsystemd is only available as shared
> library, thus we can't build the library statically (yes, some people want to do
> this). We switch the implementation to use libdbus. I made usre that it can
> be consumed as suprojects. New library, old optional dependency.
> 
> > I thought the goal was to keep the nvme management plane as streamline and
> > daemon free as possible.
> 
> Yes and it is optional. The new feature is that you can compile it
> as static dependency and this is what you currently see.
> 
> The current nvme-cli meson.build configuration for libnvme is always pulling the
> fallback. A workaround is to build libnvme as separate step as you would do when
> packaging.

I'm just trying to build this right now on an embedded system, and my goodness,
it is fucking painful. It's a bare-bones busybox enviroment with no internet
connection. Just getting meson on there was unpleasant, and now the build just
gives up with the failed dependencies.

Re: Timberland nvme-cli/libnvme upstream merge - dbus dependency.

[John Meneghini]

To provide an update: I got my rhel-8 machine to compile everything with the provided rhel-8.6 stock tool chain. I just needed 
to update and then install the dbus-devel package.

  sudo dnf update -y
  sudo dnf install -y dbus-devel

inline:

On 2/3/23 11:22, Daniel Wagner wrote:
> On Fri, Feb 03, 2023 at 10:43:04AM -0500, John Meneghini wrote:
>> I have a question for the upstream nvme maintainers.
>>
>> Why does libnvme, as v1.3, now have a dependency on dbus?
> 
> libnvme-mi uses a D-Bus service for discovering devices. Initially libnvme-mi
> used libsystemd as D-Bus library. libsystemd is only available as shared
> library, thus we can't build the library statically (yes, some people want to do
> this). We switch the implementation to use libdbus. I made usre that it can
> be consumed as suprojects. New library, old optional dependency.

Wasn't aware that libnvme-mi uses dbus.  So this is really a dependency for the nvme-mi utility?

Are we talking about:

   https://github.com/Intel-BMC/nvme-mi

???

>> I thought the goal was to keep the nvme management plane as streamline and
>> daemon free as possible.
> 
> Yes and it is optional. The new feature is that you can compile it
> as static dependency and this is what you currently see.

Ok, so there's no aversion to supporting utilities that use systemd in libnvme, you simply added the new static compile/link 
feature.

> The current nvme-cli meson.build configuration for libnvme is always pulling the
> fallback. A workaround is to build libnvme as separate step as you would do when
> packaging.

Yes, got that.  The dbus-1 fallback/compile feature has some bugs.  I worked around the problem by installing the dbus-devel 
package.  No more fall back.

>> We already have a dependency on the udev daemon.
> 
> Not on code level (no library). I don't see how we can avoid this and I don't
> understand why this is now a problem.

It's not a problem at all. I'm just trying to understand what all of the dependencies are and what's the attitude towards 
systemd.  As we've talked about this in the past the idea was we don't want any dbus dependencies in nvme-cli, but apparently 
there's no problem with supporting systemd in libvnme.

> Concerning meson version: We always used features from 0.50.0 hence the min
> version of 0.47.0 was wrong. We just updated this.

Yes. got that. After updating rhel-8.6 my meson is ok.

jmeneghi:nvme-cli(master) > meson --v
0.55.3

Thanks,

/John

> Daniel

Re: Timberland nvme-cli/libnvme upstream merge - dbus dependency.

[John Meneghini]

On 2/3/23 12:30, Keith Busch wrote:
>> The current nvme-cli meson.build configuration for libnvme is always pulling the
>> fallback. A workaround is to build libnvme as separate step as you would do when
>> packaging.
> I'm just trying to build this right now on an embedded system, and my goodness,
> it is fucking painful. It's a bare-bones busybox enviroment with no internet
> connection. Just getting meson on there was unpleasant, and now the build just
> gives up with the failed dependencies.
> 

Here's how I solved the problem on my redhat platforms: fedora36, centos9 and rhel-8.6

$ sudo dnf update -y
$ sudo dnf install -y meson cmake dbus-devel libuuid libuuid-devel libuuid-debuginfo json-c-devel json-c-debuginfo json-c \
        json-c-doc libhugetlbfs libhugetlbfs-devel libhugetlbfs-lib clang openssl openssl-devel dbus-devel
                                                                                                 ^^^^^^^^

Every time I find a missing library or package I add it to my tool chain because the meson fallback/compile stuff is always 
broken and full of bugs.

This is what you want to see:


Build targets in project: 21

nvme-cli 2.3

   Subprojects
     libnvme: YES

Found ninja-1.10.2 at /usr/bin/ninja
Configuration located in: .build
-------------------------------------------------------
ninja -C .build
ninja: Entering directory `.build'
[119/119] Linking target nvme

/John

Re: Timberland nvme-cli/libnvme upstream merge - dbus dependency.

[Daniel Wagner]

On Fri, Feb 03, 2023 at 04:27:25PM +0000, Belanger, Martin wrote:
> In meson_options.txt we find the build option libdbus. Maybe the dependency can be disabled simply as follows:
> 
> $ meson .build -Dlibdbus=disabled

Good point, this just need to subproject prefix to make it work:

meson .build -Dlibnvme:libdbus=disabled

Re: Timberland nvme-cli/libnvme upstream merge - dbus dependency.

[Daniel Wagner]

On Fri, Feb 03, 2023 at 10:30:13AM -0700, Keith Busch wrote:
> I'm just trying to build this right now on an embedded system, and my goodness,
> it is fucking painful. It's a bare-bones busybox enviroment with no internet
> connection. Just getting meson on there was unpleasant, and now the build just
> gives up with the failed dependencies.

I am sorry to causing pain. Let's see what how I can help you to make it less
hurt.

Is there a reason why you want to build it directly in a busybox environment and
not using a cross build?

I agree Meson itself is pretty anyoying in this scenario, though it should be
possible to use the alternative implementation. Meson is a specification with
more than one implementation. muon and samurai are written in plain C99 and only
use a compiler to work. Though I haven't tested this in a while. Let me give it
a quick test. I suppose it makes sense to add these to our CI build.

About the dependencies: There are only two non-optional dependencies:

  libnvme: json-c
  nvme-cli: json-c and zlib

and on closer inspection, I think we could ditch zlib as we only use the crc32
function from there. I'm preparing a PR for this.

I can look into making json-c optional again if you really don't want the JSON
related functionallity.

https://github.com/annacrombie/muon
https://github.com/michaelforney/samurai

Re: Timberland nvme-cli/libnvme upstream merge - dbus dependency.

[Daniel Wagner]

On Fri, Feb 03, 2023 at 12:43:32PM -0500, John Meneghini wrote:
> On 2/3/23 12:30, Keith Busch wrote:
> > > The current nvme-cli meson.build configuration for libnvme is always pulling the
> > > fallback. A workaround is to build libnvme as separate step as you would do when
> > > packaging.
> > I'm just trying to build this right now on an embedded system, and my goodness,
> > it is fucking painful. It's a bare-bones busybox enviroment with no internet
> > connection. Just getting meson on there was unpleasant, and now the build just
> > gives up with the failed dependencies.
> > 
> 
> Here's how I solved the problem on my redhat platforms: fedora36, centos9 and rhel-8.6
> 
> $ sudo dnf update -y
> $ sudo dnf install -y meson cmake dbus-devel libuuid libuuid-devel libuuid-debuginfo json-c-devel json-c-debuginfo json-c \
>        json-c-doc libhugetlbfs libhugetlbfs-devel libhugetlbfs-lib clang openssl openssl-devel dbus-devel
>                                                                                                 ^^^^^^^^

FWIW, the libuuid depenency is gone. The dependencies on hugetablefs and OpenSSL
should be autodected and not break the build if they are missing.

The dbus build can fail when an older version of Meson is used. The D-Bus'
meson.build fail is using a feature which is only present in newer version of
Meson. I've send a bug fix to the D-Bus project to address this. Though you
can explicitly disable the libdbus build as Martin has pointed out.

> Every time I find a missing library or package I add it to my tool chain
> because the meson fallback/compile stuff is always broken and full of bugs.

What is the problem? 'always broken and full of bugs' is a very generic complain.

Also you are not fored to use the subproject feature of Meson. This is optional
and if you don't like it just build the libnvme library as it was previously as
seperate step. Overall, the Meson tools chains very flexible to use.

Anyway, it is possible to add additional CI build targets to catch build bugs
early.

Re: Timberland nvme-cli/libnvme upstream merge - dbus dependency.

[Daniel Wagner]

:On Mon, Feb 06, 2023 at 11:03:44AM +0100, Daniel Wagner wrote:
> On Fri, Feb 03, 2023 at 10:30:13AM -0700, Keith Busch wrote:
> > I'm just trying to build this right now on an embedded system, and my goodness,
> > it is fucking painful. It's a bare-bones busybox enviroment with no internet
> > connection. Just getting meson on there was unpleasant, and now the build just
> > gives up with the failed dependencies.
> 
> I am sorry to causing pain. Let's see what how I can help you to make it less
> hurt.
> 
> Is there a reason why you want to build it directly in a busybox environment and
> not using a cross build?
> 
> I agree Meson itself is pretty anyoying in this scenario, though it should be
> possible to use the alternative implementation. Meson is a specification with
> more than one implementation. muon and samurai are written in plain C99 and only
> use a compiler to work. Though I haven't tested this in a while. Let me give it
> a quick test. I suppose it makes sense to add these to our CI build.

The project builds almost out of the box with muon and samurai. There was just
one tiny little problem with the syspathdir which I send out a PR shortly.

Here are the all steps to get this build going with those two tools. It still
depends on json-c being installed previously.



#/bin/bash

if [ ! -d build-tools ]; then

    mkdir build-tools
    pushd build-tools
    git clone --depth 1 https://git.sr.ht/~lattis/muon
    cd muon

    export CC=gcc
    ./tools/bootstrap_ninja.sh build
    ninja=build/samu
    ./bootstrap.sh build
    build/muon setup -Dlibcurl=disabled -Dlibarchive=disabled -Ddocs=disabled -Dsamurai=disabled build
    $ninja -C build
    build/muon -C build test
    popd
fi

export PATH=$(pwd)/build-tools/muon/build:$PATH

if [ ! -d libnvme ]; then
    git clone --depth 1 https://github.com/hreinecke/libnvme.git
fi

if [ ! -d nvme-cli ]; then
    git clone --depth 1 https://github.com/linux-nvme/nvme-cli.git
fi

rm -rf libnvme/build-libnvme nvme-cli/build-nvme-cli

pushd libnvme
muon setup -Dprefix=/tmp/nvme-cli-muon -Dpython=false -Dopenssl=disabled -Dlibdbus=disabled build-libnvme
samu -C build-libnvme
cd build-libnvme
muon install
popd

export PKG_CONFIG_PATH=/tmp/nvme-cli-muon/lib/pkgconfig

pushd nvme-cli
muon setup -Dprefix=/tmp/nvme-cli-muon build-nvme-cli
samu -C build-nvme-cli
cd build-nvme-cli
muon install
popd