Plan for updating the PPAs - gr3.7.10, soapy0.5


#1

Hey guys, I’ve been meaning to start an effort on this for a while now. The topic is updating the myriadrf PPAs to recent versions of GNURadio and soapysdr. There are quite a lot of interrelated packages, so I figure that we can do it at once in one simultaneous effort.

GNU Radio 3.7.10

The 3.7.10 release series is out. Updating this package also means rebuilding:

  • volk
  • gr-fcdproplus
  • gr-osmosdr (after soapy updated)
  • gr-iqbal
  • gqrx (on its gqrx ppa)

SoapySDR 0.5

SoapySDR 0.5 series has been out for a bit. And there are some useful API additions for per-channel settings among other things – which I would like to make use of more in the LimeSuite wrapper, so updating the PPA is important here.

  • soapysdr

SoapySDR modules

Not only do the support modules need to be updated as well, but there are some minor packaging changes to support multiple simultaneous version installations. Just like how a package can depend on a particular runtime version of the library which can coexist on the same filesystem as other versions of that library… each support module gets installed in a directory named for the ABI version of SoapySDR, and the names of the module packages are changed slightly to reflect this with appropriate meta-packages to get the latest version.

  • limesuite
  • soapyremote
  • other support modules…
  • pothos-sdr (on the framework ppa)

Ubuntu versions

Judging from the EOL chart. Ubuntu xenial, trusty, and precise are still relevant. Precise is so old that I don’t think there is any cause building for it. ubuntu wily actually EOL just a month ago it looks like, and its probably too early for YakketyYak. So I think that packaging updates for xenial and trusty makes sense.

Planning

In terms of updating the PPA, priority is getting soapysdr, volk, and gnuradio uploaded. The rest of the packages depend on these in one way or the other, but can otherwise be uploaded independently. @csete Let me know when you have some time so we can hopefully get through this in one single effort. Its on me to handle the soapy related stuff, but let me know your thoughts, and which gnuradio packages you can help with to split up the work.


#2

I can rebuild

  • gr-fcdproplus
  • gr-iqbal
  • gr-osmosdr
  • gqrx

I think these are the packages I built the last time also.


#3

@csete Alrighty… volk, gnuradio, and soapysdr are uploaded for xenial and trusty. For gnuradio and volk I was able to backport the packages from yakkety.

This time around for gnuradio on ubuntu trusty, rather than renaming some of the dependencies in the control file for the equivalent names in the trusty release, I added metapackages to the PPA. The metapackages match the missing names and install the trusty equivalent of that package. No funny business like back-porting newer versions of dependency libraries. Hopefully these will see their use into the next gr release and backports as well.

So with that done (hopefully) we can independently update packages. I will go after soapy modules and limesuite tomorrow. Best! -josh


#4

Hi Josh,

Thanks for the update. I have started updating the packages.


#5

Cool. I uploaded new drivers ppa support modules. The package naming convention changed slightly to reflect the upstream debian/ubuntu packages. The wiki documentation has been updated to match. More notes here: https://groups.google.com/forum/#!topic/pothos-users/IVR9Q67HPhM


#6

Unfortunately, something seems to be broken wrt. UHD. I got a report from someone who gets this runtime error:

darren@betty:~$ gqrx
gqrx: symbol lookup error:
/usr/lib/x86_64-linux-gnu/libgnuradio-uhd.so.3.7.10: undefined symbol:
_ZN3uhd4usrp10multi_usrp7ALL_LOSE

I checked gr-osmosdr build log and it is built against the right libuhd from Ettus PPA, so does libgnuradio-uhd. Perhaps he has some source installation of UHD.

Do you have a USRP?

Alex


#7

@csete do you have the uhd ppa added locally to your machine as well? My concern is that the PPA built against the ettus ppa, but there is some older stock package in (xenial?) thats on your machine. I will try to replicate this now…


#8

I don’t have any problem on my systems. I think this only comes when you actually use UHD.


#9

@csete Sorry, I misread. No problems here B200 with gqrx. My advice for darren would be to double check that all of those PPAs are added, remove all prior usrp/gnuradio/gqrx packages, and double check /usr/local/lib for gnuradio/usrp stuff. Then reinstall. The usrp packages arent particularly good with the soversion naming (they all use the same soname even when the ABI changes), so this could be a conflict with something locally installed. Crossing fingers that its something simple like that…


#10

Thanks for testing. I will pass this info along.


#11

Hi @joshblum

Hope you are doing well and not too busy :slight_smile:

Any chance you could press the button on your gnuradio packaging machine to rebuild GNU Radio? It looks like gr-uhd requires ABI compatibility at the micro-version level and UHD has been updated to 3.10.1.0, so now the PPA is broken.

I’m in the middle of moving but I’ll do my best to rebuild gr-osmosdr if it will be necessary.


#12

@csete Yea can do. I was updating SoapyUHD for similar reasons (I didnt know about the binary break, doh!) and packages for yackkety as well. I requested a yackkety package on the ettus ppa as well https://github.com/EttusResearch/uhd/issues/79


#13

Sounds good, thanks!

I wil lkeep an eye on it and update gr-osmosdr if necessary.


#14

Josh,

Thanks for the update. I am waiting for feedback from people who reported the ABI error to see if this is enough or if I have to rebuild gr-osmosdr.


#15

Sorry, I didnt mention it because I was waiting on the UHD ppa for yakkety, and then I was going to upload the same dependent packages for yakkety as well. So latest limesuite, soapysdr, gnuradio is up, at least for trusty and xenial and yakkety when possible.


#16

Yeah, I saw there was UHD for Yakkety for a short while but it seems Ettus have pulled it down again. I guess the problem with boost persists.

I have now got report back that the ABI compatibility issue is now gone, so I am not going to rebuild gr-osmosdr unless there is another reason for it?