Updating the PPA to SoapySDR 0.7

Projects Packaging
1

So I tagged SoapySDR release 0.7 a few months ago, and many of the device support projects while I was at it. This release basically means API additions, some device factory speedups and parallelization, some new command line options, and also SoapyRemote supporting mDNS for discovery.

I have been really lucky with ubuntu having a recent release of SoapySDR (0.6) in mainline thus far, so I haven’t had too much to do in this regard. But since the release, I have not yet updated the PPA, because this is basically an ABI change to everything compiled against SoapySDR, and there is quite a lot to build, and people are pinging me about it now :slight_smile:

So I am going to try and get started this weekend, it might be a disruptive change until I get things finished. I have to upload

  • SoapySDR itself
  • SoapyRemote
  • And all hardware support modules
  • Reupload/rebuid limesuite
  • Reupload/rebuid gr-osmosdr
  • Debian-ization for new support modules like AirspyHF, PlutoSDR…

A few questions though:

  • Is there any interest in PPAs for arm64 architecture? I think launchpad can build for it now, I couldnt certainly use it myself (ex on a zynqMP ultrascale), just curious for any community interest in arm64. @andrewback I suppose you could enable this, there may be an actual web option on the PPA now for various build architectures (or so I think that I have seen).

  • @IgnasJ I made a modification to LimeSuite for SoapySDR0.7 (just in the debian/ directory), but this was not in any release tag as of yet. What do you think I should do? Wait for a LimeSuite release tag? Re-upload recent LimeSuite tag with the 0.7 modification? Or just upload the latest LimeSuite master.

  • Ubuntus to build for: 18.10, 18.04, 16.04. Thats the last two LTSs and the current release. @csete Does that sound about right?

Thanks!

1 Like
2

Enabled ARMv8 (arm64) builds for all 3x PPAs.

Pleased that I somehow resisted the temptation to enable IBM System z (s390x) builds also.

1 Like
3

Hi Josh

Sounds good to me! I assume you will be using the gr-osmosdr source package from the PPA because it includes patches that are not yet merged upstream.

Alex

1 Like
4

Thanks, its building for arm64, this is great.

Looks like a few things will not build for now until I get the dependencies also built for arm64, but thats ok:

Sure, I will reupload the same source packages to just get it to rebuild.

1 Like
5

I uploaded everything to drivers. So that’s SoapySDR and friends. Also new SoapySDR support packages for PlutoSDR, SkylarkIris, and AirspyHF.

Mostly everything is built for arm64, except a few packages because the dependencies were missing since I need to rebuild a few of those dependency packages to get arm64 binaries for them.

I will probably leave this alone for now, since its probably a narrow use case for arm64 anyway.

@csete I don’t want to mess this up and I need a hint. Do you remember the incantation for downloading the source off the PPA and reuploading it? I know I need to edit the changelog and re-sign it. – I’m going to bash/python script it since it looks like this keeps coming in handy for simple rebuilds.

6

arm64 is raspberry pi3 isnt it?

7

Thanks @joshblum for all the work.
Looks like only one annoying issue still needs some work for Pluto support, opening same device source and sink from different processes, but this probably means sharing the context from libiio first. I’ll see if I can take some time to look into this. AFAIK this is not a problem for Lime?

Regards,
Adrian

8

Looks like Raspbian has raspberry pi3 in armhf.

9

Looks like only one annoying issue still needs some work for Pluto support, opening same device source and sink from different processes, but this probably means sharing the context from libiio first. I’ll see if I can take some time to look into this. AFAIK this is not a problem for Lime?

Most of the devices do not handle being opened from multiple processes very well. All of the USB based devices have that limitation, I suppose pluto does too (though I thought not since its a network device). But I didnt write the driver and I know nothing about it :slight_smile: One work around is to use soapy remote, the server opens it once, and the clients can be on multiple processes, multiple computers.

But if you find something wrong, dont hesitate to open an issue, make a pull request, etc.

10

armhf isnt arm64 :slight_smile:

11

Hi, I am not sure if my problem can be related to this update:

I am working with a LimeSDR on Ubuntu18.04. I was able to run the VNA example from https://github.com/myriadrf/pyLMS7002Soapy with out problems before. A few weeks ago I received and update from many LimeSuite packages and from SOAPY packages.
Today I tried to run again the VNA example and I got this error:

mauro@ln:~/pyLMS7002Soapy/examples$ python2 measureVNA.py test
Searching for LimeSDR… Traceback (most recent call last):
File “measureVNA.py”, line 159, in
limeSDR = pyLMS7002Soapy(0)
File “build/bdist.linux-x86_64/egg/pyLMS7002Soapy/pyLMS7002Soapy.py”, line 16, in init
File “/usr/lib/python2.7/dist-packages/SoapySDR.py”, line 1846, in new
return cls.make(*args, **kwargs)
RuntimeError: SoapySDR::Device::make() no match

Is this error related to the update?

Regards
Mauro

12

Does it see lms7support in it module path?

python -c "import SoapySDR; print(SoapySDR.__file__); print(SoapySDR.getRootPath()); print(SoapySDR.listModules())"

/usr/lib/python2.7/dist-packages/SoapySDR.py
/usr
('/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/libLMS7Support.so',)

If not, maybe something isnt installed. If yes, maybe its a permissions issue w/ udev for example.

13

This is the output I’ve got:

mauro@ln:~$ python -c “import SoapySDR; print(SoapySDR.file); print(SoapySDR.getRootPath()); print(SoapySDR.listModules())”
/usr/lib/python2.7/dist-packages/SoapySDR.py
/usr
()

I don’t see the directory “/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.7/” in my system:

mauro@ln:/usr/lib/x86_64-linux-gnu/SoapySDR$ ls -lrt
total 48
-rw-r–r-- 1 root root 43016 oct 26 2017 libSoapyOsmoSDR.so.0.6
drwxr-xr-x 2 root root 4096 dic 25 21:44 modules0.6

mauro@ln:/usr/lib/x86_64-linux-gnu/SoapySDR$ cd modules0.6/
mauro@ln:/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6$ ls -lrt
total 1188
-rw-r–r-- 1 root root 92176 ago 6 2017 librtlsdrSupport.so
-rw-r–r-- 1 root root 67600 ago 6 2017 libairspySupport.so
-rw-r–r-- 1 root root 276512 ago 11 2017 libremoteSupport.so
-rw-r–r-- 1 root root 170000 oct 26 2017 libosmosdrSupport.so
-rw-r–r-- 1 root root 96976 nov 5 2017 libaudioSupport.so
-rw-r–r-- 1 root root 88080 nov 23 2017 libHackRFSupport.so
-rw-r–r-- 1 root root 116744 ene 24 2018 libbladeRFSupport.so
-rw-r–r-- 1 root root 161808 feb 9 2018 libuhdSupport.so
-rw-r–r-- 1 root root 129960 oct 4 06:51 libLMS7Support.so
mauro@ln:/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.6$

14

Thanks for the answer @joshblum
The issue was solved by reinstalling the soapysdr-module-lms7 package.

It seems that the update only upgraded some of the packages and left some packages without upgrading:

mauro@ln:~$ sudo apt list --installed | grep -i lime
liblimesuite-dev/now 18.10.0-myriadrf1~bionic amd64 [installed,upgradable to: 18.10.0.41.2172a18-myriadrf1~ubuntu18.04]
liblimesuite18.10-1/now 18.10.0-myriadrf1~bionic amd64 [installed,upgradable to: 18.10.0.41.2172a18-myriadrf1~ubuntu18.04]
limesuite/now 18.10.0-myriadrf1~bionic amd64 [installed,upgradable to: 18.10.0.41.2172a18-myriadrf1~ubuntu18.04]
limesuite-images/bionic,now 18.10.0.41.2172a18-myriadrf1~ubuntu18.04 amd64 [installed]
limesuite-images18.10/bionic,now 18.10.0.41.2172a18-myriadrf1~ubuntu18.04 amd64 [installed,automatic]
limesuite-udev/bionic,now 18.10.0.41.2172a18-myriadrf1~ubuntu18.04 amd64 [installed]

mauro@ln:~$ sudo apt list --installed | grep -i soapy
libsoapysdr-dev/bionic,now 0.7.0.1.33be191-myriadrf1~ubuntu18.04 amd64 [installed]
libsoapysdr0.6/bionic,now 0.6.1-2 amd64 [installed,automatic]
libsoapysdr0.7/bionic,now 0.7.0.1.33be191-myriadrf1~ubuntu18.04 amd64 [installed,automatic]
python-soapysdr/bionic,now 0.7.0.1.33be191-myriadrf1~ubuntu18.04 amd64 [installed]
python3-soapysdr/bionic,now 0.7.0.1.33be191-myriadrf1~ubuntu18.04 amd64 [installed]
soapyosmo-common0.6/bionic,now 0.2.5-1build1 amd64 [installed,automatic]
soapysdr-module-lms7/bionic,bionic,now 18.10.0-myriadrf1~bionic all [installed,upgradable to: 18.10.0.41.2172a18-myriadrf1~ubuntu18.04]
soapysdr-tools/bionic,now 0.7.0.1.33be191-myriadrf1~ubuntu18.04 amd64 [installed]
soapysdr0.6-module-airspy/bionic,now 0.1.1-1 amd64 [installed,automatic]
soapysdr0.6-module-all/bionic,now 0.6.1-2 amd64 [installed,automatic]
soapysdr0.6-module-audio/bionic,now 0~git20160607-3build1 amd64 [installed,automatic]
soapysdr0.6-module-bladerf/bionic,now 0.3.4-1 amd64 [installed,automatic]
soapysdr0.6-module-hackrf/bionic,now 0.3.2-1 amd64 [installed,automatic]
soapysdr0.6-module-lms7/bionic,now 18.10.0-myriadrf1~bionic amd64 [installed,automatic]
soapysdr0.6-module-osmosdr/bionic,now 0.2.5-1build1 amd64 [installed,automatic]
soapysdr0.6-module-redpitaya/bionic,now 0.1.1-myriadrf1~ubuntu18.04 amd64 [installed,automatic]
soapysdr0.6-module-remote/bionic,now 0.4.2-1 amd64 [installed,automatic]
soapysdr0.6-module-rtlsdr/bionic,now 0.2.4-1 amd64 [installed,automatic]
soapysdr0.6-module-uhd/bionic,now 0.3.4-1build1 amd64 [installed,automatic]

After forcing the reinstallation of “soapysdr-module-lms7” all the packages were upgraded.