Project

General

Profile

Bug #2481

osmo-bts with broken dependency in latest nightly

Added by msuraev about 1 year ago. Updated 9 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
-
Start date:
09/01/2017
Due date:
% Done:

100%

Spec Reference:

Description

/usr/bin/osmo-bts-sysmo
/usr/bin/osmo-bts-sysmo: error while loading shared libraries: libosmotrau.so.1: cannot open shared object file: No such file or directory

The version is osmo-bts 0.4.3+git1+5932ff04a1-rfab4efdaf5-r20.18.2 and libosmo-abis 0.3.2+gitr0+d3292913ac-r2.18.1.2.

Possible fix is pushed to user/max/nightly-fix branch and is similar to b58904accd730b8505320d62e0c198274b422d7f.

I'm not 100% sure though as I do not yet understand how PV works in OE. Nevertheless, we should try to automate it's sync with upstream releases.

History

#1 Updated by msuraev about 1 year ago

  • Subject changed from osmo-bsc with broken dependency in latest nightly to osmo-bts with broken dependency in latest nightly
  • Status changed from New to Resolved

Fixed in latest nightly.

#2 Updated by zecke about 1 year ago

That indicates a packaging issue.. wasn't there a libosmotrau1 package? If not we need to split some lib* packages properly.

#3 Updated by laforge about 1 year ago

  • Status changed from Resolved to New
  • Assignee set to msuraev

#4 Updated by msuraev about 1 year ago

  • Status changed from New to Feedback

Indeed, there's no such package:

opkg list |grep libosmotrau

comes up empty on latest nightly. Not sure how further split would have helped with PV variables though.

#5 Updated by laforge 11 months ago

  • Assignee changed from msuraev to zecke

msuraev wrote:

Indeed, there's no such package:
[...]
comes up empty on latest nightly. Not sure how further split would have helped with PV variables though.

zecke: Can you please sched some light on this? Would having a separate libosmotrau package have solved/avoided this problem?

#6 Updated by zecke 11 months ago

On 3. Dec 2017, at 11:16, laforge [REDMINE] <> wrote:

Issue #2481 has been updated by laforge.

Assignee changed from msuraev to zecke

msuraev wrote:

Indeed, there's no such package:
[...]
comes up empty on latest nightly. Not sure how further split would have helped with PV variables though.

zecke: Can you please sched some light on this? Would having a separate libosmotrau package have solved/avoided this problem?

Same as before? e.g. SYS#3685. The libosmo-abis package is packaging multiple libraries into the same package. This way "osmo-bts" depends against "libosmo-abis" and not "libosmo-abis23 && libosmotrau1"

=> Add a dedicated libosmotrau package (PACKAGES += and split the files)?

#7 Updated by laforge 11 months ago

  • Status changed from Feedback to In Progress
  • Assignee changed from zecke to msuraev

#8 Updated by zecke 11 months ago

I think just doing PACKAGES += "libosmotrau" and then putting FILES_libosmotrau = "../libosmotrau" should be enough. It should rebuild osmo-bts but if it doesn't you can increase META_TELEPHONY_OSMO_INC in meta-telephony to force a rebuild.

"libosmotrau" should just vanish.. but maybe opkg upgrade needs to be called twice. If not we can cheat a bit and put a RREPLACES_libosmotrau = "libosmo-abis". So that the unspecific package will be replaced by libosmotrau. This is because there is a bug where RREPLACES_libosmo-abis = "libosmo-abis" will be ignored by packaging. Confused? Then just try the above and we can solve the rest.

#9 Updated by msuraev 11 months ago

  • Status changed from In Progress to Stalled

zecke wrote:

Confused?

Definitely. Pau, I recall you're did some work on automating PV update. Could you comment on this?

#10 Updated by pespin 11 months ago

  • Status changed from Stalled to Feedback
  • Assignee changed from msuraev to pespin

If I understood correctly, the problem is that if we have more than 2 .so files in a package, then OE cannot apply its magic to name packages depending on the version of the .so file inside (appending the version to the package name), as debian does. As then osmo-bts depends on generic "libosmo-abis" package, if the .so version changes the package is still the same and then I suspects it doesn't recompile osmo-bts to match against the new so version?

I sent a patch to fix it in gerrit: https://gerrit.osmocom.org/#/c/5169

I confirm that after building it, packages are named correctly with the version appended:

deploy-ipks/armv5te/libosmoabis-dbg_0.4.0+gitr0+01543a1ea3-r3.18.0.0_armv5te.ipk
deploy-ipks/armv5te/libosmotrau-dev_0.4.0+gitr0+01543a1ea3-r3.18.0.0_armv5te.ipk
deploy-ipks/armv5te/libosmotrau2_0.4.0+gitr0+01543a1ea3-r3.18.0.0_armv5te.ipk
deploy-ipks/armv5te/libosmoabis-dev_0.4.0+gitr0+01543a1ea3-r3.18.0.0_armv5te.ipk
deploy-ipks/armv5te/libosmoabis6_0.4.0+gitr0+01543a1ea3-r3.18.0.0_armv5te.ipk

Regarding the automatic PV version, there's a different task for that and it's in progress as we need to do some development in a new bbclass to support it.

#11 Updated by zecke 11 months ago

On 4. Dec 2017, at 15:35, pespin [REDMINE] <> wrote:

Issue #2481 has been updated by pespin.

If I understood correctly, the problem is that if we have more than 2 .so files in a package, then OE cannot apply its magic to name packages depending on the version of the .so file inside (appending the version to the package name), as debian does. As then osmo-bts depends on generic "libosmo-abis" package, if the .so version changes the package is still the same and then I suspects it doesn't recompile osmo-bts to match against the new so version?

Right. So we can have libosmoabis5 and libosmoabis6 installed in parallel. You are right that if two .so files the renaming will/can't not be done.

I confirm that after building it, packages are named correctly with the version appended:

> deploy-ipks/armv5te/libosmoabis-dbg_0.4.0+gitr0+01543a1ea3-r3.18.0.0_armv5te.ipk
> deploy-ipks/armv5te/libosmotrau-dev_0.4.0+gitr0+01543a1ea3-r3.18.0.0_armv5te.ipk
> deploy-ipks/armv5te/libosmotrau2_0.4.0+gitr0+01543a1ea3-r3.18.0.0_armv5te.ipk
> deploy-ipks/armv5te/libosmoabis-dev_0.4.0+gitr0+01543a1ea3-r3.18.0.0_armv5te.ipk
> deploy-ipks/armv5te/libosmoabis6_0.4.0+gitr0+01543a1ea3-r3.18.0.0_armv5te.ipk

#12 Updated by pespin 10 months ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

#13 Updated by laforge 9 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)