[LU-10558] bad lnetctl in Ubuntu builds Created: 24/Jan/18  Updated: 04/Apr/18  Resolved: 29/Mar/18

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Bob Glossman (Inactive) Assignee: Bob Glossman (Inactive)
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Related
is related to LU-10569 Include proper Lustre header files in... Resolved
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

This appears to be strictly a packaging problem in our Ubuntu builds. On some branches shared library .so files aren't packaged into any .deb packages at all. On others they are packaged into a different .deb package than the tools that use them.

lnetctl is in the lustre-utils .deb package. Our shared libs used by our own tools should be in that same package, but they are not. When lustre-utils is installed on Ubuntu lnetctl won't run because the liblnetconfig.so it is linked with is not there.
I will push a small patch to fix this.



 Comments   
Comment by Gerrit Updater [ 24/Jan/18 ]

Bob Glossman (bob.glossman@intel.com) uploaded a new patch: https://review.whamcloud.com/30995
Subject: LU-10558 build: put shared libs in lustre-utils .deb package
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 7d8fb101acb8f66c117fa1b755fa1e154db17a89

Comment by James A Simmons [ 24/Jan/18 ]

What do you mean by some branches?

Comment by James A Simmons [ 26/Jan/18 ]

Another one of those we don't know how to package on Ubuntu. For devian/Ubuntu we pretend we know how to package and on RHEL we don't even try to pretend, i.e no devel package. If we are going to have separate devel and utilies packages we need to find out the real rules.

Comment by Gerrit Updater [ 15/Feb/18 ]

Bob Glossman (bob.glossman@intel.com) uploaded a new patch: https://review.whamcloud.com/31323
Subject: LU-10558 build: put shared libs in lustre-utils .deb package
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 9eb9b61d6f027ac544872bb3b85ca2763c53359a

Comment by James A Simmons [ 15/Feb/18 ]

So I looked at the keyutils packages to see how this is done. We have the following packages:

libkeyutils1   :  This contains the shared libraries (libkeyutils.so.1 and libkeyutils.so.1.5) and /usr/share/docs

llibkeyutils-dev : This contains static library and libkeyutils.so which points to libkeyutils.so.1. This depends on libkeyutils1 package

keyutils :  man pages, binaries etc. It depends on libkeyutils1.

So we need to model this.

 As a extra note we are missing various dependencies as well like libyaml. libyaml is missing from the spec file as well.

Comment by James A Simmons [ 19/Feb/18 ]

I have a patch that resolves these issues.

Comment by James A Simmons [ 20/Feb/18 ]

https://review.whamcloud.com/#/c/31348 shoudl resolve these issues

Comment by Peter Jones [ 29/Mar/18 ]

Believed to be a duplicate of LU-10569

Generated at Sat Feb 10 02:36:09 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.