Greetings,
Today I have updated the gr-osmosdr packages to the latest git snapshot, so that it now includes support for Red Pitaya SDR transceiver and the new gain modes for the Airspy. It’s API/ABI compatible with the previous package and so the other packages do not need upgrade for this reason.
Alex
Thanks @csete. It looks like we need another big round of updates for recent release:
If I had to figure out the order of things to build to get the dependencies first:
Its quite the build matrix, so I was waiting to have some extra free time before going after it 
Ok, go ahead. I’m hoping this will not affect existing gqrx packages, only the future builds.
Sort-of… I think all of the shared libraries go into unique packages based off of their so version. That should just mean that GQRX pulls in the old libraries, and there wont be any ABI compatibility issues.
But I think what happens is that a hardware driver gets installed with the latest bin/ apps, latest library, and then also the slightly older library. Recently built apps use the newer library, but previously built apps use the older library. Problem is the older library for the hardware expects a different FPGA image or something vs the newer one.
I know its horrible, but the only sure way to have everything working is to carefully rebuild the dependency tree from bottom to top…
Update: volk and gnuradio 3.7.9 are up. Next on the list:
I forgot about the first two, gr-osmosdr depends on them
@csete I was thinking. There has to be a more automated way to do this. Rebuilding packages because the dependencies have updated comes up a lot. Especially when the dependent projects have not changed.
The script should be simple to use like ubuntu’s backportpackage, but instead it would
Ever heard of something like this? I was curious what you were using to automate/upload/script these builds. Or if you know of a smarter way to handle this.
If not, I wrote a PPA helper script in python that is specific to git projects with debian/ directories in them. It basically automates modifying the changelog, building with git-buildpackage, and uploading to a specified ppa. I can probably modify it for manually adding a debian/ directory, and then it can be used for this purpose. Also, I can share this script if you are interested.
Hi Josh,
I don’t have any automated script and I don’t mind doing things manually since most of the time goes with waiting for a build to finish.
This current update is not good 
It seems we have got gsl2 now, which wants to uninstall the GSL that comes with Ubuntu. This in turn will remove applications that depend on it. I’m not just talking about gqrx but also for example inkscape.
IMO, if a new version of gnuradio requires adding new packages to the PPA, we should seriously consider whether we really want the upgrade. We can’t just randomly replace Ubuntu packages without consequences. Every time we add a new package that replaces a package in Ubuntu we increase the complexity and the risk of breaking the system.
I also noted that the libvolk 1.2 package actually installs libvolk.so.1.1 - is that intentional?
I assumed that gsl2 runtime would not conflict. But instead it looks like the libcblas sonames are the same, so the gsl2 is marked to conflict with the stock gsl packages. They probably could have been made to coexist. What a mess.
So I think I can delete gsl2 from the PPA and rebuilt gnuradio against the stock gsl. I have to check if gnuradio really needed newer gsl or this was just a change of package names in the build depends.
I’m not sure why its like that. Its backported from xenial. So if it gets fixed upstream I guess I will re-backport. In any case its not a problem as ffar as I can tell.
Ok, understood.
It looks like GSL dependency only affects people who have the full gnuradio SDK installed, and those who only have gqrx + necessary runtime installed will not notice. So, it might not be as bad as I feared when I saw it.
Well, still wasnt quite my intention. It should be fixed now. It looks like gnuradio builds fine against stock gsl. I just needed to adjust the build depends.
That’s great news!
Hi Josh,
Are you waiting for me to update the remaining packages (gr-iqbal, gr-fcdproplus and gr-osmosdr)? I can do that later today, I just need to know 
Alex
Sorry for the delay. I wasn’t waiting for you to handle those packages (also I need to adjust the notification settings…). But if you are ready to handle them now, I would appreciate if you can update the others. Otherwise I can get around to it this weekend.
Hi Josh,
No problem. I have updated the packages and will also make a new gqrx package.
Awesome! At some point I should email the osmocom list about the updated packages.
If you have a summary of the updates I could announce these in a short blog post that we can share via Twitter etc. also.
For the most part
If its also of interest, I updated my PothosSDR environment for gr 3.7.9 as well. New binaries will be available pretty soon: https://github.com/pothosware/PothosSDR/wiki/GNURadio
@csete For kicks I added GQRX to the build. It builds with the following patch, but no idea if it works yet since the VM doesnt have any devices: https://github.com/pothosware/PothosSDR/blob/master/patches/gqrx_msvc_fixes.diff
Hi Josh,
It’s quite amazing that you could build it on windows
I have applied your patch and pushed it into my master. Thanks.
Alex