Bug #2481
closedosmo-bts with broken dependency in latest nightly
Added by msuraev over 6 years ago. Updated about 6 years ago.
100%
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.
Updated by msuraev over 6 years 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.
Updated by zecke over 6 years ago
That indicates a packaging issue.. wasn't there a libosmotrau1 package? If not we need to split some lib* packages properly.
Updated by laforge over 6 years ago
- Status changed from Resolved to New
- Assignee set to msuraev
Updated by msuraev over 6 years 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.
Updated by laforge over 6 years 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?
Updated by zecke over 6 years ago
On 3. Dec 2017, at 11:16, laforge [REDMINE] <redmine@lists.osmocom.org> 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)?
Updated by laforge over 6 years ago
- Status changed from Feedback to In Progress
- Assignee changed from zecke to msuraev
Updated by zecke over 6 years 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.
Updated by msuraev over 6 years 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?
Updated by pespin over 6 years 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.
Updated by zecke over 6 years ago
On 4. Dec 2017, at 15:35, pespin [REDMINE] <redmine@lists.osmocom.org> 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
Updated by pespin over 6 years ago
- Status changed from Feedback to Resolved
- % Done changed from 0 to 100
