Project

General

Profile

Actions

Bug #3542

closed

Conflicting Debian packages: soapysdr0.5-module-lms7 and soapysdr0.6-module-lms7

Added by osmith over 5 years ago. Updated over 5 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
09/10/2018
Due date:
% Done:

0%

Spec Reference:

Description

During the implementation of #3176 I have discovered the following conflict when installing both packages:

Unpacking soapysdr0.5-2-module-lms7:amd64 (16.12.0+dfsg-1) ...
dpkg: error processing archive
/tmp/apt-dpkg-install-MovoKD/351-soapysdr0.5-2-module-lms7_16.12.0+dfsg-1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.5-2/libLMS7Support.so',
which is also in package soapysdr0.6-module-lms7:amd64 18.06.0-1

Note that the conflicting file has modules0.5-2 in the path in both the 0.5 and the 0.6 version. My guess is, that in the 0.6 version, this path should be modules0.6-...?


Related issues

Related to OsmoBSC - Bug #3540: Conflicting Debian packages: osmocom-bsc-sccplite and osmo-bsc-mgcpClosedosmith09/10/2018

Actions
Related to Cellular Network Infrastructure - Bug #3809: Osmocom-Debian-install-test fails since February 9Resolvedosmith02/20/2019

Actions
Actions #1

Updated by osmith over 5 years ago

  • Project changed from Cellular Network Infrastructure to SDR (Software Defined Radio)
Actions #2

Updated by osmith over 5 years ago

  • Blocks Bug #3176: osmocom debian packages are not install / upgrade tested added
Actions #3

Updated by osmith over 5 years ago

I could not set this as a subtask of #3176 after creating the issue, probably because I don't have the rights in the SDR project. So I set it as blocker for the other issue, now they are linked together that way.

Actions #4

Updated by laforge over 5 years ago

On Mon, Sep 10, 2018 at 02:05:43PM +0000, osmith [REDMINE] wrote:

I could not set this as a subtask of #3176 after creating the issue, probably because I don't have the rights in the SDR project. So I set it as blocker for the other issue, now they are linked together that way.

I don't think the redmine UI can do this. If you find some documentation, I'd be interested.

The only way how I have so far created subtasks is directly from the master issue, never by
later somehow attaching any other tickets.

Actions #5

Updated by neels over 5 years ago

about subtasks, I used to use them a lot, but the complex relations between them often made me regret that. These days all I do is just set "Related to".

Actions #6

Updated by neels over 5 years ago

  • Status changed from New to Feedback
  • Assignee set to osmith

Hmm, are we really packaging soapysdr from the Osmocom opensuse builds?
Are the differing soapy versions dependencies pulled in by Osmo packages?

About the modules of 0.5 and 0.6 conflicting, I'm not sure that this is related, but the LIBVERSION markers of .so files does not at all correspond to major.minor.patch software version tags.
This modules-0.5-2 looks like it isn't related to LIBVERSION either. Not sure what to make of this.

Actions #7

Updated by neels over 5 years ago

  • Related to Bug #3540: Conflicting Debian packages: osmocom-bsc-sccplite and osmo-bsc-mgcp added
Actions #8

Updated by osmith over 5 years ago

neels wrote:

Hmm, are we really packaging soapysdr from the Osmocom opensuse builds?

This is a good question. We have the following packages in the OBS repo (directory listing), as found by aptitude:

soapysdr-module-lms7   
soapysdr0.6-module-lms7
soapysdr0.6-module-lms7-dbgsym

So no soapysdr0.5 there.

Are the differing soapy versions dependencies pulled in by Osmo packages?

Yes, they are. I'm figuring out where they come from. What I can tell so far is, that they still get pulled in, even after blacklisting packages coming from the obsolete openbsc.git.

EDIT: It might also be that soapysdr-module-lms7 pulls in the 0.5 package for some reason.

Actions #9

Updated by laforge over 5 years ago

On Tue, Sep 11, 2018 at 07:01:59PM +0000, neels [REDMINE] wrote:

Hmm, are we really packaging soapysdr from the Osmocom opensuse builds?

we used to do, but now that we have osmo-trx-lms, we should deprecate that.

Actions #10

Updated by osmith over 5 years ago

we used to do, but now that we have osmo-trx-lms, we should deprecate that.

That was a very useful clue! I've created a blacklist.txt for the cronjob with packages from the repository, that it will not try to install (originally to blacklist all openbsc.git derived packages). Now I've added the following packages, and the apt install runs through successfully!

# SoapySDR is not used anymore (see OS#3542)
soapysdr-module-lms7
soapysdr0.6-module-lms7
soapysdr0.6-module-lms7-dbgsym

This issue can now be closed (I don't get the UI to change the status here, probably because of missing rights).

I am not really sure where the soapysdr packages come from (they don't seem to be in osmocom-latest-packages.sh). If somebody could give me a pointer, I could look into removing the binary soapysdr packages from the Debian package repository if that is desired.

Actions #11

Updated by osmith over 5 years ago

  • Blocks deleted (Bug #3176: osmocom debian packages are not install / upgrade tested)
Actions #12

Updated by laforge over 5 years ago

  • Project changed from SDR (Software Defined Radio) to OsmoTRX

This is due to the fact that #3542 is a different osmocom sub-project.
OsmoSDR and/or its child projects rtl-sdr, gr-osmosdr, osmo-fl2k, gr-gsm
are all projects in which sysmocom is not involved, and where sysmocom
developers do not automatically get 'developer' privileges.
https://osmocom.org/projects/sdr will show you that the sysmocom
developers / employees are only listed in the 'Reporters' category.

Should sysmocom get involved in related projects, we could change that,
but I think in general it would be awkward to those projects and their
maintainers if employee status at sysmocm would automatically introduce
some role there.

I think the key problem is that this particular issue #3542 was filed in
the "Osmocom SDR" project. Sure, it affects SDR hardware or drivers,
but not the Osmocom SDR software projects, which I've listed above.
Sorry for the confusion :).

I'm moving it now.

Actions #13

Updated by osmith over 5 years ago

  • Status changed from Feedback to Rejected
Actions #14

Updated by osmith about 5 years ago

  • Related to Bug #3809: Osmocom-Debian-install-test fails since February 9 added
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)